Software Engineering
COMP 201
Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
Lecture 2 – Software Processes
COMP201 - Software Engineering
1
What is a Process … ?
 When we provide a service or create a product we always
follow a sequence of steps to accomplish a set of tasks
 You do not usually
 put up the drywall before the wiring for a house is installed or
 bake a cake before all the ingredients are mixed together
 We can think of a series of activities as a process
 During this lecture we shall see some examples of software
development processes that are used to ensure software is
developed in a systematic way using tried and tested
techniques
COMP201 - Software Engineering
2
What is a Process … ?
 Any process has the following characteristics
 It prescribes all of the major activities
 It uses resources and produces intermediate and
final products
 It may include sub-processes and has entry and exit
criteria
 The activities are organized in a sequence
 Constraints or controls may apply to activities
(budget constraints, availability of resources , etc.)
COMP201 - Software Engineering
3
Process
Building development
Architect
Design
house
(re)Draw plans
(re)Specify build
Site survey
Get
Planning
permission
Secure
funding
Plans/
specifications
COMP201 - Software Engineering
4
Software Processes
When the process involves the building of some product
we refer to the process as a life cycle
Software development process – software life cycle
Coherent sets of activities for
 Specifying,
 Designing,
 Implementing and
 Testing software systems
COMP201 - Software Engineering
5
Processes and software
 Software (unlike buildings/bridges etc.)
 Can be changed at anytime
 Is often required to change often after construction
 Benefits
 Software can be improved almost without limit
 Leading to problems
 Software often gets faults as it evolves
 Software cost is hard to manage
 Problems with user’s experience and expectations
COMP201 - Software Engineering
6
The Software Process
 The Software Process is a structured set of activities
required to develop a software system consisting of
 Specification
 Design
 Validation
 Evolution
 A software process model is an abstract representation of
a process
 It presents a description of a process from some particular
perspective
COMP201 - Software Engineering
7
Generic Software Process Models
 The Waterfall Model (classic engineering, example bridge
building)
 Separate and distinct phases of specification and development
 Evolutionary Development (more like product engineering)
 Specification and development are interleaved
 Formal Systems Development (example - ASML)
 A mathematical system model is formally transformed to an
implementation
 Reuse-Based Development
 The system is assembled from existing components
COMP201 - Software Engineering
8
Waterfall Model
The drawback of the
waterfall model is the
difficulty of
accommodating change
after the process is
underway
R equ irem ent s
d efi ni ti on
S y st em and
so ftware d es ig n
Im pl em ent at io n
and u ni t t est in g
Int egr at io n an d
s ys tem t est in g
Op erat io n an d
m ain ten ance
COMP201 - Software Engineering
9
Waterfall Model Problems
 Inflexible partitioning of the project into distinct stages
 This makes it difficult to respond to changing customer
requirements
 Therefore, this model is only appropriate when the (final)
requirements are well-understood (rare in software)
 Waterfall model describes a process of stepwise refinement
• Based on hardware engineering models
• Widely used in military and aerospace industries
COMP201 - Software Engineering
10
Reality check!
 Practically no one in industry follows the waterfall
method as shown here to produce software
 Why bother, then?
 Each stage is an important step in software development
 It’s easy to remember
 The sequence is important


Spec. before Design
Design before coding etc.
 Many industry practises could do with improvement!
COMP201 - Software Engineering
11
Why Not a Waterfall
• But software is different from hardware :
• No fabrication step
• Program code is another design level
• Hence, no “commit” step – software can always be changed…!
• No body of experience for design analysis (yet)
• Most analysis (testing) is done on program code
• Hence, problems are often not detected until late in the process
• Waterfall model takes a static view of requirements
• It ignores changing needs
• Lack of user involvement once specification is written
• Unrealistic separation of specification from the design
• Doesn’t accommodate prototyping, reuse, etc.
COMP201 - Software Engineering
12
Evolutionary Development
 Rather than using the waterfall model we may use
evolutionary development which is based upon the idea
of developing an initial implementation , exposing it to
the user and refining it based upon their response.
 Exploratory development
- Objective is to work with customers and to evolve a final
system from an initial outline specification.
- Should start with well-understood requirements.
- The system evolves by adding new features as they are
proposed by customer.
COMP201 - Software Engineering
13
Evolutionary Development
 Throw-away prototyping
 Objective is to understand the system requirements. Should
start with poorly understood requirements



Develop “quick and dirty” system quickly;
Expose to user comment;
Refine;
Until an adequate system is developed.
 Particularly suitable where:
-
detailed requirements not possible;
powerful development tools (e.g. GUI) available
COMP201 - Software Engineering
14
Evolutionary Development
C o ncurr ent
acti v it ies
Ou t li ne
d es crip ti on
S p eci ficat ion
Ini ti al
v ersi on
Develo pm ent
Int erm edi at e
v ersi on s
Vali dat io n
F i nal
v ersi on
COMP201 - Software Engineering
15
Evolutionary Development
 Problems
 Lack of process visibility
 Systems are sometimes poorly structured
 Special skills (e.g. in languages
prototyping) may be required
 Applicability
 All types of system but rare in safety critical
COMP201 - Software Engineering
16
Formal Systems Development
 Based on the transformation of a mathematical
specification through different representations to an
executable program
 Transformations are ‘correctness-preserving’ so it is
straightforward to show that the program conforms to its
specification
Embodied in the ‘Cleanroom’ approach (which was
originally developed by IBM) to software development
COMP201 - Software Engineering
17
Formal Systems Development
R equ irem en ts
d efi ni ti on
Fo rm al
s pecifi cati on
COMP201 - Software Engineering
Fo rm al
t ran sfo rm ati on
Int egrat io n and
s ys tem t est in g
18
Formal Transformations
Fo rma l tra n sfo rma tio n s
T1
Fo rm al
s pecifi cat io n
T2
R1
P1
T3
R2
P2
T4
Ex ecut able
p ro g ram
R3
P3
P4
Pro ofs of tra n sfo rma tio n co rrectn ess
COMP201 - Software Engineering
19
Example code (in Z)
COMP201 - Software Engineering
20
Formal Systems Development
 Problems
 Need for specialised skills and training to apply the
technique (Higher initial cost)
 Difficult to formally specify some aspects of the system such
as the user interface
 Can be more time consuming than other approaches
(increased time to market)
 Many stake holders cannot understand the specification
 Applicability
 Critical systems especially those where a safety or security
case must be made before the system is put into operation
COMP201 - Software Engineering
21
Reuse-Oriented Development
 Based on systematic reuse where systems are integrated
from existing components or COTS (Commercial-off-theshelf) systems
 Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
COMP201 - Software Engineering
22
Process Iteration
 Modern development processes take iteration as
fundamental, and try to provide ways of managing, rather
than ignoring, the risk
 System requirements ALWAYS evolve in the course of a
project so process iteration where earlier stages are
reworked is always part of the process for large systems
 Iteration can be applied to any of the generic process
models
 There are two (related) approaches:
 Incremental development
 Spiral development
COMP201 - Software Engineering
23
Incremental Development
(example Scrum)
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality
 User requirements are prioritised and the highest
priority requirements are included in early increments
 Once the development of an increment is started,
the requirements are frozen though requirements for
later increments can continue to evolve
COMP201 - Software Engineering
24
Incremental Development Advantages
 Customer value can be delivered with each increment
so system functionality is available earlier
 Early increments act as a prototype to help elicit
requirements for later increments
 Lower risk of overall project failure
 The highest priority system services tend to receive
the most testing
COMP201 - Software Engineering
25
Spiral Development
(Barry Boehm 1986)
 Process is represented as a spiral rather than as a
sequence of activities with backtracking
 Each loop in the spiral represents a phase in the
process.
 No fixed phases such as specification or design -
loops in the spiral are chosen depending upon what is
required
 Risks are explicitly assessed and resolved throughout
the process
COMP201 - Software Engineering
26
Spiral Model of the Software Process
De te rm ine ob je c tiv e s
a lte rna tive s a nd
c ons tra int s
R isk
a na lys is
Ev a luate a lt e rn a tive s
id en tify, re sol ve risk s
R isk
a na lys is
R isk
a na lys is
R EVIEW
Re qui re me nt s pl a n
Li fe -c yc le pl an
De ve lop me nt
pl an
P la n ne xt p has e
Ope ra ti ona l
prot oyp e
P rot otyp e 3
P rot otyp e 2
Risk
anal ys is P rot oty pe 1
S im ul ati ons, m ode ls, b en ch ma rks
C onc e pt o f
Ope ra ti on
S /W
re qui re me nt s
P rod uc t
de si gn
Re qui re me nt
va lid ati on
De si gn
V& V
Inte gra ti on
a nd t e st p la n
S e rv ic e
COMP201 - Software Engineering
Ac c ep ta nc e
te st
De ta il e d
de si gn
C ode
Uni t t es t
Inte gr ati on
te st
De ve lop, v e rify
ne xt -l e ve l p rod uc t
27
Spiral Model Sectors
 Objective setting
 Specific objectives for the phase are identified
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the
key risks
 Development and validation
 A development model for the system is chosen which can
be any of the generic models
 Planning
 The project is reviewed and the next phase of the spiral is
planned
COMP201 - Software Engineering
28
In Reality
 Most software processes involve
 Prototyping
 Iterative building
 Why
 It reduces risk of making the wrong product
 It allows the software to undergo more testing
 It produces working product as we go along, so less chance
of inventory loss
COMP201 - Software Engineering
29
Lecture Key Points
 Software processes are the activities involved in
producing and evolving a software system. They are
represented in a software process model
 General activities are specification, design and
implementation, validation and evolution
 Generic process models describe the organisation of
software processes
 Iterative process models describe the software process as
a cycle of activities
COMP201 - Software Engineering
30