Lecture 4: Software Lifecycles Waterfall Model Why Not a Waterfall?

Home , Waterfall model

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Waterfall Model Lecture 4: Source: Adapted from Dorfman, 1997, p7 Software Lifecycles see also: van Vliet 1999, p50

➜ The Software Process requirements Waterfall model Rapid Prototyping Cycle design Phased Models: Incremental Development Evolutionary Development code Spiral Model V-model and Systems Engineering test The ‘essential’ software process

➜ Verification and Validation integrate

maintain

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Source: Adapted from Why not a waterfall? Prototyping lifecycle van Vliet 1999, p53 Source: Adapted from Blum 1992, pp28-31 see also: van Vliet 1999, p50-1 ➜ Waterfall model describes a process of stepwise refinement require- design build test ments prototype prototype prototype Based on hardware engineering models Widely used in defense and aerospace industries

➜ document But software is different: require- design code test integrate No fabrication step ments Program code is just another design level Hence, no ‘commit’ step - software can always be changed…! ➜ No body of experience for design analysis (yet) Prototyping is used for: Most analysis (testing) is done on program code understanding the requirements for the user interface Hence, problems not detected until late in the process examining feasibility of a proposed design approach Waterfall model takes a static view of requirements exploring system performance issues ignores changing needs ➜ Problems: Lack of user involvement once specification is written users treat the prototype as the solution Unrealistic separation of specification from design a prototype is only a partial specification Doesn’t accommodate prototyping, reuse, etc.

© 2001, Steve Easterbrook 3 © 2001, Steve Easterbrook 4 University of Toronto Source: Adapted from Dorfman, 1997, p10 Department of Computer Science University of Toronto Department of Computer Science Source: Adapted from Source: Adapted from Dorfman, 1997, p10 Pfleeger, 1998, p57 Phased Lifecycle Models see also: van Vliet 1999, p56 The Spiral Model see also: van Vliet 1999, p63

Release 1 Incremental development Determine goals, Evaluate design code test integrate O&M alternatives, (each release adds more ints 4 r alternatives Requirements tra isk constraints ons an functionality) c aly and risks sis release 2 design code test integrate O&M nts 3 4 rai r nst isk co an 4 a s ly e si 3 - s iv s tr 3 t e ns design code test integrate O&M a v Co r n i s 2 is r t int an k e a - a al t n n ys l r r es is release 3 a e s 2 iv 2 t e at s risk l lt e rn int a iv e a ana design code test integrate O&M A t alt tr lysis a ns 1 co budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4

e s concept of r t d re a n e qu e l n release 4 ir w i em g l e operation t m a i version 1 ife nts f e e cyc , o r r t s le i a e e p s u d lan w n d d ev q t ig reqts design code test integrate O&M elo e f s pm r o e en ted s d int t p lida eg la va nts e lessons learnt ra n me d ti uire o on req c an d t es ed, t reqts design code test integrate O&M t p dat n ni la vali esig u t n d d s ifie te Develop version 2 ver em Evolutionary development Plan syst and st implem cceptance te (each version incorporates reqts design code test integrate entation a test plan test new requirements) lessons learnt

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Source: Adapted from Comments on phased models V-Model Forsberg & Mooz 1997

➜ Incremental development avoids ‘big bang’ implementation system system requirements integration but: assumes all requirements known up-front software acceptance ➜ Evolutionary development requirements test allows for lessons from each version to be incorporated into the next abstraction of Level but… preliminary software design integration hard to plan for versions beyond the first; lessons may be learnt too late “analyse “test and detailed component and ➜ Spiral model design” design test integrate” incorporates prototyping and risk analysis but… code and unit debug test cannot cope with unforeseen changes (e.g. new business objectives) not clear how to analyze risk time

© 2001, Steve Easterbrook 7 © 2001, Steve Easterbrook 8 University of Toronto Department of Computer Science University of Toronto Department of Computer Science The “essential” software process Verification and Validation Source: Adapted from Jackson, 1995, p170-171 Source: Adapted from Blum, 1992, p32 see also: van Vliet p11 Application Domain Machine Domain Real World

➜ Problem For V&V, we need to worry about: Statement The properties of the computer hardware (C) The properties of the program (P) The properties of the machine in the application domain (the specification, S) The properties of the domain, independent of the machine (D) Validation Correctness The requirements for the machine (R) Implementation Verification Correspondence Statement ➜ Demonstrating that P satisfies R is then a two step process: Do C and P imply S? (Verification) System Do S and D imply R? (Validation)

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Validation Example Summary Source: Adapted from Jackson, 1995, p172 ➜ Requirement R: ➜ Software is different “Reverse thrust shall only be enabled when the aircraft is moving on the many assumptions from other engineering models don’t apply runway” there is no fabrication step ➜ Domain Properties D: the underlying science of software behaviour is not well developed (software engineering is still an immature discipline) 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 ➜ Specification S: waterfall model is too rigid (doesn’t allow for change) other models incorporate prototyping, evolution, risk, etc. Reverse thrust enabled if and only if wheel pulses on no lifecycle model is perfect ➜ S + D imply R ➜ Essential process: But what if the domain model is wrong? describe the problem describe the solution verify (does the solution solve the stated problem?) validate (did we solve the right problem?)

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.