Software Engineering

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 1
Software Engineering
• Software Engineering is the science and art of
building significant software systems that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation.

 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.
 Software engineering expenditure represents a
significant fraction of the GNP of developed
countries.
Software Engineering

 Software costs often dominate system costs. The
costs of software on a PC are often greater than
the hardware cost.
 Software costs more to maintain than it does to
develop.
 Software engineering is concerned with cost-
effective software development.
Software Costs

Software Products
 Generic products:
– Stand-alone systems which are produced by a development
organization and sold on the open market to any customer.
 Customized products:
– Systems which are commissioned by a specific customer and
developed specially by some contractor.

Software Product Attributes
 Maintainability
 Dependability
 Efficiency
 Usability

Importance of Product Characteristics
 The relative importance of these characteristics
depends on the product and the environment in
which it is to be used.
 In some cases, some attributes may dominate
– In safety-critical real-time systems, key attributes may be
dependability and efficiency.
 Costs tend to rise exponentially if very high
levels of any one attribute are required.

Efficiency Costs
Co st
Ef ficiency

The Software Process
 Structured set of activities required to develop a
software system
– Specification
– Design
– Validation
– Evolution
 Activities vary depending on the organization
and the type of system being developed.
 Must be explicitly modeled if it is to be
managed.

Engineering Process Model
 Specification: Set out the requirements and
constraints on the system.
 Design: Produce a model of the system.
 Manufacture: Build the system.
 Test: Check the system meets the required
specifications.
 Install: Deliver the system to the customer and
ensure it is operational.
 Maintain: Repair faults in the system as they
are discovered.

Software Engineering is Different
 Normally, specifications are incomplete.
 Very blurred distinction between specification,
design and manufacture.
 No physical realization of the system for testing.
 Software does not wear out - maintenance
does not mean component replacement.

Generic Software Process Models
 Waterfall
– Separate and distinct phases of specification and development
 Evolutionary
– Specification and development are interleaved
 Formal Transformation
– A mathematical system model is formally transformed to an
implementation
 Reuse-based
– The system is assembled from existing components

Waterfall Process Model
R equ irem ents
d efinition
S y stem and
so ftw are d es ig n
Im plem entatio n
and u nit testin g
Integr atio n an d
s ys tem testin g
O p eratio n an d
m ain ten ance

Evolutionary Process Model
V alidatio n
F inal
v ersion
D evelo pm ent
Interm ediate
v ersion s
S p ecification
Initial
v ersion
O u tline
d es crip tion
C o ncurr ent
activ ities

Process Model Problems
 Waterfall
– High risk for new systems because of specification and
design problems.
– Low risk for well-understood developments using familiar
technology.
 Prototyping
– Low risk for new applications because specification and
program stay in step.
– High risk because of lack of process visibility.
 Transformational
– High risk because of need for advanced technology and
staff skills.

Hybrid Process Models
 Large systems are usually made up of several
sub-systems.
 The same process model need not be used for
all subsystems.
 Prototyping for high-risk specifications.
 Waterfall model for well-understood
developments.

Spiral Process Model
R isk
a na lys is
R isk
a na lys is
R isk
a na lys is
Risk
anal ysis P rot o-
ty pe 1
P rot otyp e 2
P rot otyp e 3
O pe ra -
ti ona l
prot oyp e
C onc e pt o f
O pe ra ti on
S im ul ati ons, m ode ls, b en ch m a rks
S /W
re qui re m e nt s
R e qui re m e nt
va lid ati on
D e si gn
V & V
P rod uc t
de si gn D e ta il e d
de si gn
C ode
U ni t t es t
Inte gr ati on
te st
A c c ep ta nc e
te st
S e rv ic e D e ve lop, v e rify
ne xt -l e ve l p rod uc t
E v a luate a lt e rn a tive s
id en tify, re sol ve risk s
D e te rm ine ob je c tiv e s
a lte rna tive s a nd
c ons tra int s
P la n ne xt p has e
Inte gra ti on
a nd t e st p la n
D e ve lop m e nt
pl an
R e qui re m e nt s pl a n
L i fe -c yc le pl an
R E V IE W

Spiral Model Advantages
 Focuses attention on reuse options.
 Focuses attention on early error elimination.
 Puts quality objectives up front.
 Integrates development and maintenance.
 Provides a framework for hardware/software
development.

Spiral Model Problems
 Contractual development often specifies
process model and deliverables in advance.
 Requires risk assessment expertise.

Process Visibility
 Software systems are intangible so managers
need documents to assess progress.
 Waterfall model is still the most widely used
model.

Waterfall Model Documents
Activity Output documents
Requirementsanalysis Feasibility study,Outlinerequirements
Requirementsdefinition Requirementsdocument
System specification Functional specification, Acceptancetestplan
Draft user manual
Architecturaldesign Architecturalspecification,Systemtestplan
Interface design Interface specification,Integration testplan
Detailed design Design specification,Unit testplan
Coding Program code
Unittesting Unittestreport
Moduletesting Moduletest report
Integration testing Integration testreport,Finaluser manual
System testing System test report
Acceptancetesting Finalsystem plus documentation

Process Model Visibility
Process model Process visibility
Waterfall model Goodvisibility,each activity produces some
deliverable
Evolutionary
development
Poorvisibility,uneconomic to produce
documents during rapid iteration
Formal
transformations
Good visibility,documents mustbe produced
fromeach phase fortheprocess to continue
Reuse-oriented
development
Moderatevisibility,itmay beartificial to
producedocuments describing reuse and
reusablecomponents.
Spiralmodel Goodvisibility, each segment and each ring
of the spiralshould producesome document.

Professional Responsibility
 Software engineers should not just be concerned
with technical considerations. They have wider
ethical, social and professional responsibilities.
 No clear rights and wrongs about many of these
issues:
– Development of military systems
– Whistle blowing

Ethical Issues
 Confidentiality
 Competence
 Intellectual property rights
 Computer misuse

Software Engineering

More Related Content

Similar to Software Engineering

Recently uploaded

Software Engineering