1. University of Toronto Department of Computer Science CSC444 Lec04- 1 Lecture 4: Software Lifecycles The Software Process Waterfall model Rapid Prototyping Cycle Phased Models: Incremental Development Evolutionary Development Spiral Model V-model and Systems Engineering The ‘essential’ software process Verification and Validation © 2001, Steve Easterbrook

2. University of Toronto Department of Computer Science CSC444 Lec04- 2 wild west approach waterfall model prototyping (incremental, throwaway) incremental development rapid application development spiral model agile/lightweight methods systems development -common steps planning analysis design development implementation maintenance systems development methodologies

3. University of Toronto Department of Computer Science CSC444 Lec04- 3 Waterfall Model requirements design code integrate test Source: Adapted from Dorfman, 1997, p7 see also: van Vliet 1999, p50 maintain © 2001, Steve Easterbrook

4. University of Toronto Department of Computer Science CSC444 Lec04- 4 Why not a waterfall? Waterfall model describes a process of stepwise refinement Based on hardware engineering models Widely used in defense and aerospace industries But software is different: No fabrication step Program code is just 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 not detected until late in the process Waterfall model takes a static view of requirements ignores changing needs Lack of user involvement once specification is written Unrealistic separation of specification from design Doesn’t accommodate prototyping, reuse, etc. Source: Adapted from Blum 1992, pp28-31 see also: van Vliet 1999, p50-1 © 2001, Steve Easterbrook

5. University of Toronto Department of Computer Science CSC444 Lec04- 5 Prototyping is used for: understanding the requirements for the user interface examining feasibility of a proposed design approach exploring system performance issues Problems: users treat the prototype as the solution a prototype is only a partial specification Source: Adapted from van Vliet 1999, p53 document require- ments designcodetestintegrate require- ments design prototype build prototype test prototype © 2001, Steve Easterbrook Prototyping lifecycle

6. University of Toronto Department of Computer Science CSC444 Lec04- 6 evolutionary prototyping throw-away prototyping Sommerville fig 8.3 and 8.5

7. University of Toronto Department of Computer Science CSC444 Lec04- 7 Phased Lifecycle Models Source: Adapted from Dorfman, 1997, p10 Incremental development (each release adds more functionality) Requirements designcodetestintegrateO&MdesigncodetestintegrateO&M designcodetestintegrateO&MdesigncodetestintegrateO&M Release 1 release 2 release 3 release 4 Source: Adapted from Dorfman, 1997, p10 see also: van Vliet 1999, p56 © 2001, Steve Easterbrook

8. University of Toronto Department of Computer Science CSC444 Lec04- 8 designcodetestintegrateO&Mreqts designcodetestintegrateO&Mreqts designcodetestintegratereqts version 1 version 2 version 3 lessons learnt Evolutionary development (each version incorporates new requirements)

9. University of Toronto Department of Computer Science CSC444 Lec04- 9 The Spiral Model Determine goals, alternatives, constraints Evaluate alternatives and risks Plan Develop and test budget 1 budget 2 budget 3 budget 4 prototype 1 prototype 2 prototype 3 prototype 4 alternatives 4 alternatives 3 Altern- atives 2 constraints 4 constraints 3 Constr- aints 2 alternatives constraints risk analysis 4 risk analysis 3 risk analysis 2 risk analysis 1 concept of operation software requirements validated requirements software design validated, verified design detailed design code unit test system test acceptance test requirements, lifecycle plan development plan integration and test plan implementation plan Source: Adapted from Pfleeger, 1998, p57 see also: van Vliet 1999, p63 © 2001, Steve Easterbrook

10. University of Toronto Department of Computer Science CSC444 Lec04- 10 Comments on phased models Incremental development avoids ‘big bang’ implementation but: assumes all requirements known up-front 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 Spiral model incorporates prototyping and risk analysis but… cannot cope with unforeseen changes (e.g. new business objectives) not clear how to analyze risk © 2001, Steve Easterbrook

11. University of Toronto Department of Computer Science CSC444 Lec04- 11 V-Model system requirements software requirements preliminary design detailed design code and debug unit test component test software integration acceptance test system integration “analyse and design” “test and integrate” time Level of abstraction Source: Adapted from Forsberg & Mooz 1997 © 2001, Steve Easterbrook

12. University of Toronto Department of Computer Science CSC444 Lec04- 12 The “essential” software process Source: Adapted from Blum, 1992, p32 see also: van Vliet p11 Problem Statement Implementation Statement System Correspondence Correctness Validation Verification Real World © 2001, Steve Easterbrook

13. University of Toronto Department of Computer Science CSC444 Lec04- 13 Verification and Validation For V&V, we need to worry about: 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) The 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) Application Domain Machine Domain Source: Adapted from Jackson, 1995, p170-171 © 2001, Steve Easterbrook

14. University of Toronto Department of Computer Science CSC444 Lec04- 14 Validation Example Requirement R: “Reverse thrust shall only be enabled when the aircraft is moving on the runway” Domain Properties D: Wheel pulses on if and only if wheels turning Wheels turning if and only if moving on runway Specification S: Reverse thrust enabled if and only if wheel pulses on S + D imply R But what if the domain model is wrong? Source: Adapted from Jackson, 1995, p172 © 2001, Steve Easterbrook

15. University of Toronto Department of Computer Science CSC444 Lec04- 15 Summary Software is different many assumptions from other engineering models don’t apply there is no fabrication step the underlying science of software behaviour is not well developed (software engineering is still an immature discipline) Many different views of the software process waterfall model is too rigid (doesn’t allow for change) other models incorporate prototyping, evolution, risk, etc. no lifecycle model is perfect 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

16. University of Toronto Department of Computer Science CSC444 Lec04- 16 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