1

Chap 1.
An Introduction to Software
Engineering
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 1

Objectives
 To introduce software engineering and to

explain its importance
 Know the answers to key questions that provide
an introduction to software engineering;
 Understand some ethical (moral) and professional
issues that are important for software engineers.

Topics covered
 FAQ (Frequently Asked Questions ) about software

engineering
 Professional and ethical responsibility

Software engineering
 The economies of ALL developed nations are

dependent on software.
 More and more systems are software controlled
 Software engineering is concerned with theories,
methods and tools for professional software
development.
 Expenditure on software represents a
significant fraction of GNP (Gross National Product) in
all developed countries.

Rely on computer-based systems
 Mostly all countries now depend on complex

computer-based systems
• National infrastructures (foundation or basic framework) and
public utilities rely (trust) on computer-based systems
and most electrical products include a computer and
controlling software.
• Industrial manufacturing and distribution is completely
computerized. Same is the financial system.
• Therefore, producing and maintaining software cost-
effectively is essential for the functioning of national and
international economics.

New techniques to control complexity
software
 Early experience in building these systems showed that
informal (casual) software development was not good
enough.
• Major projects were sometimes years late.
• The software cost much more than predicted (that it was planed).
• Was unreliable, was difficult to maintain and performed poorly.
• Although Hardware cost were keep fall down, but software
costs were rising rapidly.
• New techniques and methods were needed to control the
complexity in large software systems.
• This techniques have become part of software Engineering.

Software produce ability increased but
same to his complexity.
 However, as our ability to produce software has
increased, so too has the complexity of the
software systems that we need.
• For instance, new technologies resulting from the
merge of computers and communication systems
and complex graphical user interfaces .
• As many companies still do not apply software
engineering techniques effectively (efficient).
• too many companies still produce software that is
unreliable, delivered late and over budget.

No single “perfect” approach
 We know now that there is no single “perfect”

approach to software engineering.
• The wild diversity (variety) of different types of
systems and have variety organizations (company) that
use these systems means that we need a software
development in variety of approaches.
• However, fundamental notions (conception) of system
process and system organization underlie all of
these techniques, and these are the essence of
software engineering.

Software engineers can proud of their
achievements
 Software engineers can be rightly proud of their

achievements.
• Without complex software we could not have
explored (travel in and discover) space, would not have
the internet and modern telecommunications, and all
forms of travel would be more dangerous and
expensive. (air craft need complex computer control)
• Software engineering has contributed a great deal,
and I am convinced (believe) that, depend to the
technologies is more matures, its contributions in the
21st century will be even greater.

Software costs
 Software costs often dominate (control) computer

system costs. The costs of software on a PC are
often greater than the hardware cost.
 Software it costs more in maintain system than it
does to develop. For systems with a long life,
maintenance costs may be several times
development costs.
 Software engineering is concerned with cost-
effective software development.

1.1 FAQ about software engineering
 This section is designed to answer some fundamental

questions about software engineering and to give you
some impression of the views of the discipline.
 (FAQ) Frequently Asked Questions
1. What is software?
2. What is software engineering?
3. What is the difference between software engineering and
computer science?
4. What is the difference between software engineering and system
engineering?

FAQs about software engineering
• What is a software process?

• What is a software process model?
• What are the costs of software engineering?
• What are software engineering methods?
• What is CASE (Computer-Aided Software Engineering)
• What are the attributes of good software?
• What are the key challenges facing software
engineering?

1.1.1 What is software?
 Software system is not equate with computer

programs:
• Which usually consists of a number of separate
programs, configuration or data files, which are used
to set up these programs, system documentation,
which describes the structure of the system, and
user documentation (user menu), which explains how to
use the system and web sites for users to download
recent product information.

1.1.1 two fundamental types of software
product
 There are two fundamental types of software product:
• Generic (general) products: these are stand-alone (solitary)
system that are produced by a development organization and
sold on the open market to any customer who is able to buy
them. Example, word processors, Excel, Access, databases,
drawing packages tools etc...
• Customize products: these are systems which are
commissioned (ordered) by a particular customer. Example,
control systems for electronic devices systems written to
support a particular business process, like as customer order
system, university of administration system.

1.1.1 difference between Generic and
Customer products
 An important difference between these types of software
is that,
• In generic products: the organization (company) that develops
the software controls the software specification.
• For customer products: the specification is usually developed
and controlled by the buyer (or market).
• However, the line between these types of products is becoming
increasingly blurred (indistinct). And more software companies
are starting with a generic system and customizing it to the
needs of a particular customer. Enterprise Resource Planning
(ERP) systems is a good examples.

1.1.2 What is software engineering?
 Software engineering is an engineering discipline

that is concerned with all aspects of software
production from the early stages of system
specification to maintaining the system after it
has gone into use.

1.1.2 Two key fundamental types
 In the definition, there are two key fundamental types:

• Engineering discipline:
• Engineers make things work. They apply appropriately theories,
methods and tools to try to discover solutions to problems even
when there are no applicable theories and methods.
• Engineers also understand that they must followed the company
financial constraints, so they look for solutions within these
constraints (ex. financial budget).
• All aspects of software production:
• Software engineering is not just concerned with the technical
processes of software development, but also with activities such as
software project management and with the development of tools,
methods and theories to support software production.

1.1.2 What is software engineering?
 Software engineering is an engineering discipline

that is concerned with all aspects of software
production.
 Software engineers should adopt (accept and do) a
systematic and organised approach (method) to
their work and use appropriate tools and
techniques depending on the problem to be
solved, as this often the most effective way to
produce high-quality software.

1.1.3 What is the difference between software
engineering and computer science?
 Computer science is concerned with theory and

fundamentals (primary principle); software engineering is
concerned with the practicalities of developing and delivering
(produce) useful software.
 Some knowledge of computer science is essential for
software engineers. In the same way that some knowledge
of physics is essential for electrical engineers.
 Ideally, all of software engineering should be supported by
theories of computer science, but in reality this is not the
case. Computer science theories are still insufficient to act
as a complete underpinning (supported) for software
engineering (unlike e.g. physics and electrical engineering).

1.1.4 What is the difference between software
engineering and system engineering?
 System engineering is concerned with all aspects of

computer-based systems development including
hardware, software and process engineering.
• Software engineering is part of this process concerned with
developing the software infrastructure (foundation), control,
applications and databases in the system.
• System engineers are involved in system specification,
architectural design, integrating the different parts to create the
finished system and deployment (spread out).
• System engineering are less concerned with the engineering of the
system components (hardware, software, etc.)

1.1.5 What is a software process ?
 A software process is the set of activities to produce

software products.
 Four fundamental process activities in all software
processes are:
1. Specification – Customers or engineers define the software’s
specification to be produced and the constraints on its operation.
2. Development - Production of the software system, as structure or
programmed.
3. Validation - checking that the software is what the customer
requires.
4. Evolution - changing the software in response to changing
demands (from customer or market requirements).

1.1.5 Need different development
processes
 Different types of systems need different
development processes.
• In e-commerce systems, the specification and the

program are usually developed together.
• However, use of an inappropriate software process may
reduce the quality or cause usefulless software product
to be developed and increase the development costs.

1.1.6 What is a software process model?
 A simplified representation of a software process,

presented from a specific perspective.
 Examples of types of software process model that may
be produced as followed:
1. Workflow model or process model – shows the sequence of
activities in the process along with their inputs, outputs and
dependencies, the activities in this model represent human
actions. (figure 8.2)
2. Data-flow or activity model – it shows how the input to the
process, such as specification, is transformed to an output,
such as design. The activities here may represent
transformations carried out by people or by computers. (figure
8.3)

Equipment procurement (obtain) process
Figure 8.2 process model of equipment procurement

Order processing DFD
Figure 8.3 Data flow diagrams

1.1.6 waterfall approach
 Most software process models are based on one

of three general models : (Generic process
models)
1. Waterfall approach;
• Represents process as separate process phases such as
requirements specification, software design,
implementation, testing, and operation and
maintenance, after each stage is defined and ‘signed off’,
(have signed) then development goes on to the following
stage. (figure 4.1)

Waterfall model
Figure 4.1
the software life cycle

1.1.6 Iterative development
2. Iterative (repeating) development; (Evolutionary

development); (figure 4.2)
• This approach is repeating the activities of specification,
development and validation.
• An initial system is rapidly developed from abstract
specifications.
• Then refined with customer required to produce a system
that satisfies customer’s required, then delivered.

Evolutionary development
Figure 4.2
Evolutionary development
1.1.6 Component-based software
3. Component-based software engineering.

 This approach is based on the existence of reusable
components. The system development process focuses on
integrating these components into a system rather than
developing them from scratch (beginning). (figure 4.3)

Reuse-oriented development
Figure 4.3
component-based software engineering
CBSE : Component-based software engineering

1.1.7 What are the costs of software
engineering?
 There is no simple answer to this question

• as the distribution of costs depends on the different
software process used and the type of software that
is being developed.
• For example: real-time software usually requires
more extensive (comprehensive) validation and testing
than web-based systems.
• Different software development has a different cost
across the software process activities.

1.1.7 costs of waterfall approach
 We can assume that the total cost of developing

a complex software system is 100 cost units
then figure 1.2 illustrates how these are spent
on different process activities.
1. In the waterfall approach, the costs of specification,
design, implementation and integration are
measured separately.
• The system integration and testing is the most expensive
development activity, normally, this is about 40% of the
total development costs but will at least 50% for some
critical system.

Activity cost distribution
Waterfall mo del
0 25 50 75 100
Specificatio n Design Develo pment In tegratio n an d testing
Iterative develo pment
0 25 50 75 1 00
Specificatio n Iterative develo pment Sy stem testin g
Co mpo nent-based software eng in eering
0 25 50 75 1 00
Specificatio n Develo pment In tegratio n an d testing
Figure 1.2 Develo pment an d evo lution costs for lon g-lifetime syst ems
0 10 20 0 30 400
software engineering
activity cost distribution
Sy stem develo pment Sy stem ev olutio n

1.1.7 cost of iterative approach
2. In the iterative approach, there is no hard line

between specification, design and development.
• Specification costs are reduced because only a high-level
(roughly) specification is produced before development.
• All the activities, specification, design, implementation,
integration and testing are carried out in parallel within a
development activity.
• However, you still need and independent system testing
activity once the initial implementation is complete.

1.1.7 cost of Component-based software
3. Component-based software engineering has only

been widely used for a short time.
• We don’t have accurate figures for the costs of different
software development activities in this approach.
• Development costs are reduced, because we can use exist
component .
• But integration and testing costs are increased because
you have to ensure that the components that you use
actually meet their specification and work as expected
required.

1.1.7 Cost of long-lifetime software
 On top of development costs, costs are also

incurred in changing the software after it has
gone into use.
• For long-lifetime software systems, such as command
and control systems that may be used for 10 years or
more, these costs are likely to exceed the development
costs by 3 or 4 times. (figure 1.2)

1.1.7 Cost of PC software products
 Above cost distributions hold for customized software

that is specified by a customer and developed by a
contractor.
 For software products that are sold for PCs, the cost
profile is likely to be different.
• Usually developed from an outline specification using an
evolutionary development approach.
• So specification costs are relatively low, however, because
intended for use on a range of different configurations, so must
be extensively tested.
• Figure 1.3 shows the type of costs profile.

Product development costs
0 25 50 75 100
Specificatio n Develo pment Sy stem testin g
Figure 1.3
Pc software product development costs

1.1.8 What are software engineering methods?
• is a structured approach to software development

• whose aim is to facilitate (easy) to produce the high-quality
software in a cost-effective way.
• 1970s, methods such as Structured Analysis have been
issued by (DeMarco,1978) and (Jackson, 1983), these
methods attempted to identify the basic functional components
of a system. Is called Function-oriented methods.
• 1980s and 1990s Function-oriented methods were
supplemented by Object-oriented (OO) methods such as those
proposed.
• These different approaches have now been integrated into a
single unified (form into one) approach, call the Unified Modeling
Language (UML).

1.1.8 What are software engineering
methods?
 These is no ideal method, and different methods have

different areas where they are applicable.
• For example, object-oriented methods are often appropriate for
interactive systems but not for stringent (strict) real-time
requirements.
 All methods that be represented graphically and using
these models as a system specification or design.
 Methods include a number of different components;
System model descriptions, Rules, Recommendations,
Process Guidance. (figure 1.4)

Figure 1.4
Component Description Example
System model 1. Descriptions of the system models Object models, data-
descriptions which should be developed flow models, state
2. and the notation used to define these machine models, etc
models. (Chat 8, p176)
Rules Constraints which always apply to system Every entity in the system
models. model must have a
unique name.
Recommendatio Experience advice on good design No object should have
ns (design) practice. Followed these recommendation more than seven sub-
should lead to a well-organized system objects associated with
model. it.
Process Descriptions of the activities in the system Object attributes should
guidance model and organization of these activities. be documented before
defining the operations
associated with an object.
1.1.8 Conclusion
 Structured approaches to software development which

include system models, rules, design advice and process
guidance.
 Model descriptions
• Descriptions of graphical models (notation) which should be
produced;
 Rules
• Constraints applied to system models;
 Recommendations (Design)
• Advice on good design practice;
 Process guidance
• What activities to follow.

1.1.9 What is CASE (Computer-Aided
Software Engineering)
 Software systems that are intended to provide automated support for
software process activities.
 CASE systems are often used to support software process activities
such as requirements analysis, system modelling, debugging and
testing.
 All methods now come with associated CASE technology such as:
• Editors for the notations used in the method.
• Analysis modules which check the system model according to the
method rules.
• Report generators to help create system documentation
• Code generators that automatically generates source code.
• Some process guidance for software engineers.

1.1.9
 Upper-CASE
• Tools to support the early process activities of
requirements and design;
 Lower-CASE
• Tools to support later activities such as programming,
debugging and testing.

1.1.10 What are the attributes of good
software?
 The software should deliver the required

functionality and performance to the user.
 Some other attributes are not directly concerned
with what the software does. We call these kind
of attributes is non-functional attributes, example:
• Software’s response time to a user query.
• Understandability of the program code.
• Banking system must be 100% security.
• Interactive game must be real-time responsive.
• Telephone switching system must be reliable.

1.1.10 What are the attributes of good
software?
 The essential characteristics of a well-designed software

system can be generalized into the set of attributes show
as followed;
1. Maintainability
• Software should be written in such a way that it may develop to meet
the changing needs of customers.
• This is a critical attribute because software change is an inevitable
(unavoidable) consequence of a changing business environment.
2. Dependability (reliable)
• Software dependability has a range of characteristics, including
reliability, security (avoid hacker) and safety.
• Dependable software should not cause physical or economic
damage in the event of system failure.

1.1.10
3. Efficiency
• Software should not make wasteful use of system
resources such as memory and processor cycles.
• Efficiency therefore includes responsiveness, processing
time, memory utilization (useful) rate, budget control, etc.
4. Usability (Acceptability)
• Software must be usable and accepted by the users for
which it was designed. This means it must be
understandable (adequate documentation), usable and
compatible with other systems (appropriate user interface).

1.1.11 What are the key challenges facing
software engineering?
 Software engineering in the 21st century faces three key

challenges : Heterogeneity (different in kind), delivery
(production time) and trust.
1. Heterogeneity Challenge (dissimilarity)
• The software system are become as distributed system across
networks that include different types of computer.
• It is often necessary to integrate new software with older exist
systems that written in different programming languages.
• The heterogeneity challenge is to build up a dependable
software that is flexible enough to cope with this heterogeneity.

1.1.11
2. Delivery Challenge (production time)

• Traditional software engineering techniques are
time-consuming, the reason for time taken is
required to achieve software quality.
• However, businesses today must be responsive and
change very rapidly, so their supporting software
must change equally rapidly.
• The delivery challenge is how to shorten delivery
times for large and complex systems without
compromising system quality.

1.1.11
3. Trust
• As software is beside us with all aspects of our lives:
• It is essential that we can trust that software.
• This is especially true for remote software systems
accessed through a web page or web service interface.
• The trust challenge is to develop techniques that
demonstrate that software can be trusted by its users.

1.2 Professional and ethical responsibility
 Software engineering is carried out within a legal

and social framework.
• Accept that their job involves wider responsibilities
than simple application of technical skills.
• Must behave in an ethical and morally responsible
way if they are to be respected as professionals.
• You should always own normal standards of honesty
and integrity (uprightness, honesty ).
• You should not use your skills and abilities to behave
in a dishonest way or in a way that will bring
disrepute (loss of good reputation) to your profession area.

1.2
 There are some areas where standards of

acceptable behavior are not bounded by laws
but by the more tenuous (unclear) area of
professional responsibility. There are :
1. Confidentiality
2. Competence (ability)
3. Intellectual property rights
4. Computer misuse

1.2 Issues of professional responsibility
 Confidentiality
• Engineers should normally respect the confidentiality
of their employers or clients, doesn’t matter whether
or not a formal confidentiality agreement has been
signed.
 Competence (ability)
• Engineers should not misrepresent their level of
competence. They should not accept work which is
outside their competence. (Mean’s sometime you
talk too big).

1.2 Issues of professional responsibility
 Intellectual (intelligence) property rights

• Engineers should be aware of local laws governing the use of
intellectual property such as patents (sole right to make), copyright,
etc. They should be careful to ensure that the intellectual
property of employers and clients is protected.
 Computer misuse
• Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (little important) (game playing on an
employer’s machine) to extremely serious (spread of viruses).

1.2 ACM/IEEE Code (regulation) of Ethics
 Professional societies and institutions have an important

role to play in setting ethical standards.
 ACM, and IEEE ( Institute of Electrical and Electronic
Engineers) and British Computer Society publish a code
of professional conduct (behave) or code of ethics.
 Members of these organizations undertake to follow that
code when they sign up for membership.
 These codes of conduct (behavior) are generally concerned
with fundamental ethical behavior.

ACM/IEEE Code of Ethics
 The Code contains eight Principles related to the

behaviour of and decisions made by professional
software engineers, including practitioners,
educators, managers, supervisors and policy
makers, as well as trainees and students of the
profession.

ACM/IEEE Code of Ethics
 ACM/IEEE-CS Joint Task Force on Software
Engineering Ethics and professional Practices
 Preamble (introduction)
• The short version of the code summarizes aspirations (desire for
something better or higher, ambition) at a high level of the abstraction;
the clauses that are included in the full version give examples
and details of how these aspirations change the way we act as
software engineering professionals. Without the aspirations, the
details can become legalistic (according to letter rather than the spirit)
and tedious (tiresome); without the details, the aspirations can
become high sounding but empty; together, the aspirations and
the details form a cohesive (stick together) code.

Code of ethics - principles
• Software engineers shall commit (pledge) themselves to making the
analysis, specification, design, development, testing and maintenance
of software a beneficial and respected profession. In accordance with
their commitment (promise) to the health, safety and welfare of the
public, software engineers shall adhere (devote) to the following Eight
Principles:
1. PUBLIC
• Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER
• Software engineers shall act in a manner that is in the best interests of
their client and employer consistent (unchanging) with the public interest.
3. PRODUCT
• Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.

4. JUDGMENT
• Software engineers shall maintain integrity (honesty) and
independence in their professional judgment.
5. MANAGEMENT
• Software engineering managers and leaders shall support and
promote an ethical approach to the management of software
development and maintenance.
6. PROFESSION
• Software engineers shall promote the integrity and reputation
of the profession consistent (unchanging) with the public interest.

7. COLLEAGUES
• Software engineers shall be fair to and supportive of
their colleagues.
8. SELF
• Software engineers shall participate in lifelong
learning regarding the practice of their profession
and shall promote an ethical approach to the
practice of the profession.

Ethical dilemmas
 Disagreement in principle with the policies of senior
management.
• Your employer acts in an unethical way and releases a safety-
critical system, because of time-pressure, the safety validation
records. without finishing the testing of the system.
• Your responsibility to maintain confidentiality or alert the customer,
in some way, that delivered system may be unsafe?
• The system may actually operate safely throughout its lifetime. It is
also the case that, even when properly validated, a system may
fail and cause an accident.
• Early disclosure of problems may result in damage to the employer
and other employees; failure to disclose problems may result in
damage to others.

Ethical dilemmas
 Participation in the development of military

weapons systems or nuclear systems.
• In this situation it is important that both employers
and employees should make their views known to
each other in advance.

Key points
 Software engineering is an engineering discipline that is

concerned with all aspects of software production.
 Software products consist of developed programs and
associated documentation. Essential product attributes
are maintainability, dependability, efficiency and usability.
 The software process consists of activities that are
involved in developing software products. Basic activities
are software specification, development, validation and
evolution.

Key points
 Methods are organised ways of producing software. They

include; (figure 1.4)
• System model descriptions;
• To description the system model by notation way to define these
model.
• Rules;
• Constraints which always apply to system models.
• Recommendations;
• Followed experience and good recommendation should lead to a
well-organized system model.
• Process guidance.
• Descriptions of the activities in the system model and organization
of these activities.

Key points
 CASE tools are software systems which are designed to

support routine activities in the software process such as
editing design diagrams, checking diagram consistency
and keeping track of program tests which have been run.
 Software engineers have responsibilities to the
engineering profession and society. They should not
simply be concerned with technical issues.
 Professional societies publish codes of conduct which set
out the standards of behaviour expected of their
members. (ACM/IEEE-CS joint Task Force on Software
Engineering Ethics and Professional Practices)

Exercise 1.2
 What are the differences between generic

software product development and custom
software development?

1.2 Answer
 The essential difference is that in generic

software product development, the specification
is owned by the product developer. For custom
product development, the specification is owned
by the customer. (p5)

Exercise 1.3
 what are the four important attributes which all

good software products should have? Suggest
four other attributes that may sometimes be
significant. (p13)

1.3 Answer
 For important attributes are maintainability,

dependability, efficiency and usability (p13). Other
attributes that may be significant could be
1. reusability (can it be reused in other applications),
2. distributability (can it be distributed over a network of
processors),
3. portability (can it operate on multiple platforms, ie different
operation system)
4. inter-operability (can it work with a wide range of other software
systems, ie different program language).

Exercise 1.4
 what are the difference between a software

process model and a software process? Suggest
two ways in which a software process model
might be helpful in identifying possible process
improvements.

1.4 Answer (a)
 A software process is what actually goes on when

software is developed for produce a software
product, there are four fundamental process
activities : (1.1.5 p8)
• Software specification: Customer requirement.
• Software development: designed and programmed.
• Software validation: check and make sure it is customer
require
• Software evolution: adapt (make suitable) for changing
customer and market require

1.4 Answer (b)
 A software process model is an abstraction and

simplification of a process. Process models can
be used to help understand real processes and
to identify which aspects of these processes
model could be supported by CASE tools. For
examples as : (1.1.6 p9)
• Workflow model, Dataflow model, Role model.
• They are based on three general models, as :
• Waterfall approach, Iterative development,
Component-based software engineering.

Exercise 1.6
 Software engineering methods became widely
used only when CASE technology became
available to support them. Suggest five types of
method support that can be provided by CASE
tools. (1.1.9)

1.6 Answer
 Method support provided by CASE tools: (1.1.9)

• Editors for specific graphical notations used
• Checking of the 'rules' and guidelines of the method
• Advice to tool users on what to do next
• Maintenance of a data dictionary - all names used in
the system
• Automatic generation of skeleton code from the
system models
• Generation of reports documentation on the design
(p12)

Exercise 1.7
 Apart from the challenges of heterogeneity,
rapid delivery and trust, identify other problems
and challenges that software engineering is likely
to face in the 21st century. (1.1.11)

1.7 Answer
 Problems and challenges for software engineering (p13)

• Developing systems for multicultural use
• Developing systems that can be adapted (make suitable) quickly
to new business needs (or market requirement)
• Designing systems for outsourced development (maybe Oral)
• Developing systems that are resistant to attack (information
security)
• Developing systems that can be adapted and configured by
end-users (user can design or assemble what they want)

Exercise 1.9
 For each of the clauses in the ACM/IEEE code of
Ethics shown in Figure 1.6, suggest an
appropriate example that illustrates that clause.

1.9 Answer
Advantages of certification
 Certification is a signal to employers of some minimum level of
competence. (2,3)
 Certification improves the public image of the profession. (1,5)
 Certification generally means establishing and checking educational
standards and is therefore a mechanism for ensuring course quality.
(3,8)
 Certification implies responsibility in the event of disputes (argue). (4)
 Certifying body is likely to be accepted at a national and international
level as ‘speaking for the profession’. (6)
 Certification may increase the status of software engineers and
attract particularly able people into the profession. (1)

1.9 Answer
Disadvantages of certification
 Certification tends to lead to protectionism where certified
members tend not to protect others from criticism.
 Certification does not guarantee competence merely that
a minimum standard was reached at the time of
certification.
 Certification is expensive and will increase costs to
individuals and organisations.
 Certification tends to failure change. This is a particular
problem in an area where technology developments are
very rapid.

Exercise 1.10
 To help counter terrorism, many countries are
planning the development of computer systems
that track large numbers of their citizens and
their actions. Clearly this has privacy implications
(twist together) , discuss the ethics of developing this
type of system.

End

Test 1 (for week 1)
 There are two fundamental types of software

product, Generic and Customer products. Please
explain what important difference between these
two types of products?
 And why the line between these two types of
products is becoming increasingly blurred?

Ans: difference between Generic and
Customer products
 An important difference between these types of software
is that,
• In generic products: the organization (company) that develops
the software controls the software specification.
• For customer products: the specification is usually developed
and controlled by the buyer (or market).
• However, the line between these types of products is becoming
increasingly blurred (indistinct). And more software companies
are starting with a generic system and customizing it to the
needs of a particular customer. Enterprise Resource Planning
(ERP) systems is a good examples.

Test 2 (for week 2)
 Please give three type of software process

model? And what the software development
model that most software process models are
base on ?

Ans:
1. Workflow model, dataflow/activity model and

role/action model.
2. Waterfall approach, Iterative development, and
Component-based software engineering.

End

1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1

Uploaded by

Copyright:

Available Formats

Chap 1.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 1

 To introduce software engineering and to

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 2

 FAQ (Frequently Asked Questions ) about software

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 3

 The economies of ALL developed nations are

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 4

 Mostly all countries now depend on complex

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 5

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 6

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 7

 We know now that there is no single “perfect”

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 8

 Software engineers can be rightly proud of their

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 9

 Software costs often dominate (control) computer

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 10

 This section is designed to answer some fundamental

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 11

• What is a software process?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 12

 Software system is not equate with computer

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 13

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 14

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 15

 Software engineering is an engineering discipline

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 16

 In the definition, there are two key fundamental types:

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 17

 Software engineering is an engineering discipline

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 18

 Computer science is concerned with theory and

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 19

 System engineering is concerned with all aspects of

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 20

 A software process is the set of activities to produce

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 21

• In e-commerce systems, the specification and the

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 22

 A simplified representation of a software process,

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 23

Figure 8.2 process model of equipment procurement

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 24

Figure 8.3 Data flow diagrams

 Most software process models are based on one

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 26

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 27

2. Iterative (repeating) development; (Evolutionary

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 28

3. Component-based software engineering.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 30

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 31

 There is no simple answer to this question

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 32

 We can assume that the total cost of developing

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 33

Specificatio n Design Develo pment In tegratio n an d testing

Iterative develo pment

Specificatio n Iterative develo pment Sy stem testin g

Co mpo nent-based software eng in eering

Specificatio n Develo pment In tegratio n an d testing

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 34