University of Toronto

Department of Computer Science

University of Toronto

Department of Computer Science

Lecture 4: Software Lifecycles

Waterfall Model
Source: Adapted from Dorfman, 1997, p7 see also: van Vliet 1999, p50

The Software Process

Waterfall model Rapid Prototyping Cycle Phased Models:
Incremental Development Evolutionary Development Spiral Model

requirements design code test integrate maintain

V-model and Systems Engineering The essential software process

Verification and Validation

2001, Steve Easterbrook

2001, Steve Easterbrook

University of Toronto

Department of Computer Science

University of Toronto

Department of Computer Science

Source: Adapted from van Vliet 1999, p53

Why not a waterfall?

Waterfall model describes a process of stepwise refinement

Based on hardware engineering models Widely used in defense and aerospace industries

Source: Adapted from Blum 1992, pp28-31 see also: van Vliet 1999, p50-1

Prototyping lifecycle
requirements design prototype build prototype test prototype

But software is different:

No fabrication step
Program code is just another design level Hence, no commit step - software can always be changed!

document requirements

design

code

test

integrate

No body of experience for design analysis (yet)

Most analysis (testing) is done on program code Hence, problems not detected until late in the process

Prototyping is used for:

understanding the requirements for the user interface examining feasibility of a proposed design approach exploring system performance issues

Waterfall model takes a static view of requirements

ignores changing needs Lack of user involvement once specification is written

Problems:
users treat the prototype as the solution a prototype is only a partial specification

Unrealistic separation of specification from design Doesnt accommodate prototyping, reuse, etc.
2001, Steve Easterbrook

2001, Steve Easterbrook

University of Toronto

Source: Adapted from Dorfman, 1997, p10

Phased Lifecycle Models

code test code
release 3

Department of Computer Science

Source: Adapted from Dorfman, 1997, p10 see also: van Vliet 1999, p56

University of Toronto

The Spiral Model

ain s tr con s con
es
3

Department of Computer Science

Source: Adapted from Pfleeger, 1998, p57 see also: van Vliet 1999, p63

Release 1

design Requirements
version 1

integrate test code

release 4

O&M integrate test code

release 2

design

O&M

Incremental development (each release adds more functionality)

O&M integrate O&M

Determine goals, alternatives, constraints

ts 4

ris k ris k
r ana isk lys is 2

ints 3 tr a str Con ts 2 ain

ana lys i s3

s4

Evaluate alternatives and risks

rn at iv

rn at iv

design

integrate test

ana lys i

es

design

budget4

budget3

budget2

s ive s ris at rn int ana k lysis lte stra a n 1 o c

Al at tern ive s2

alt e

alt e

budget1 prototype1
concept of operation

prototype2

prototype3 prototype4
det ai des led ign
co de
it un t s te

reqts

design

code
version 2

test

integrate
lessons learnt

O&M

dev e
int egr ati on a

lop me

nt p

lan

reqts

design
version 3

code

test

integrate
lessons learnt

O&M

nd

tes t

ated valid ents em equir r

pla

Evolutionary development (each version incorporates new requirements)

2001, Steve Easterbrook

Plan
integrate

reqts

design

code

test

implemen

tation pl an

ed, n dat vali d desig e rifi ve em syst test acceptance test

re sof qu tw ire ar me e nt s so ft de wa sig re n

requ ir lifec ements, ycle plan

Develop and test

6

2001, Steve Easterbrook

University of Toronto

Department of Computer Science

University of Toronto

Department of Computer Science

Comments on phased models

Level of abstraction

V-Model
system requirements

Source: Adapted from Forsberg & Mooz 1997

Incremental development
avoids big bang implementation but:
assumes all requirements known up-front

system integration

Evolutionary development
allows for lessons from each version to be incorporated into the next but
hard to plan for versions beyond the first; lessons may be learnt too late

software requirements preliminary design

acceptance test software integration component test unit test

Spiral model
incorporates prototyping and risk analysis but
cannot cope with unforeseen changes (e.g. new business objectives) not clear how to analyze risk

analyse and design

detailed design code and debug

test and integrate

time
2001, Steve Easterbrook

2001, Steve Easterbrook

University of Toronto

Department of Computer Science

University of Toronto

Department of Computer Science

The essential software process

Source: Adapted from Blum, 1992, p32 see also: van Vliet p11

Verification and Validation

Source: Adapted from Jackson, 1995, p170-171

Application Domain

Machine Domain

Real World

Correspondence

Correctness

Verification

Implementation Statement

Validation

Problem Statement

For V&V, we need to worry about:

The The The The The properties of the computer hardware (C) properties of the program (P) properties of the machine in the application domain (the specification, S) properties of the domain, independent of the machine (D) requirements for the machine (R)

Demonstrating that P satisfies R is then a two step process:

Do C and P imply S? (Verification) Do S and D imply R? (Validation)

System
2001, Steve Easterbrook

2001, Steve Easterbrook

10

University of Toronto

Department of Computer Science

University of Toronto

Department of Computer Science

Validation Example
Source: Adapted from Jackson, 1995, p172

Summary

Requirement R:
Reverse thrust shall only be enabled when the aircraft is moving on the runway

Software is different
many assumptions from other engineering models dont apply there is no fabrication step the underlying science of software behaviour is not well developed (software engineering is still an immature discipline)

Domain Properties D:
Wheel pulses on if and only if wheels turning Wheels turning if and only if moving on runway

Many different views of the software process

waterfall model is too rigid (doesnt allow for change) other models incorporate prototyping, evolution, risk, etc. no lifecycle model is perfect

Specification S:
Reverse thrust enabled if and only if wheel pulses on

S + D imply R
But what if the domain model is wrong?

Essential process:
describe the problem describe the solution verify (does the solution solve the stated problem?) validate (did we solve the right problem?)

2001, Steve Easterbrook

11

2001, Steve Easterbrook

12

University of Toronto

Department of Computer Science

References
van Vliet, H. Software Engineering: Principles and Practice (2nd Edition) Wiley, 1999.
Chapter 3 provides a very good overview of lifecycle models.

Blum, B. Software Engineering: A Holistic View. Oxford University Press, 1992. Dorfman, M. Requirements Engineering. In Thayer, R. H and Dorfman, M. (eds.) Software Requirements Engineering, Second Edition. IEEE Computer Society Press, 1997, p7-22 Forsberg, K and Mooz, H. System Engineering Overview. In Thayer, R. H and Dorfman, M. (eds.) Software Requirements Engineering, Second Edition. IEEE Computer Society Press, 1997, p44-72 Jackson, M. Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices. Addison-Wesley, 1995. Pfleeger, S. Software Engineering: Theory and Practice. Prentice Hall, 1997.
2001, Steve Easterbrook

13