Software Life Cycles

1. TUM Software Life Cycles Prof. Bernd Brügge, Ph.D Technische Universität München Institut für Informatik Lehrstuhl für Angewandte Softwaretechnik http://wwwbruegge.in.tum.de 7 June 2005

2. Outline of Today’s Lecture • Problems of Software Development • Software Development as Application Domain • Modeling the software lifecycle • IEEE Standard for Software Lifecycles • Modelling the Software Life cycle • Waterfall model and its problems • Pure Waterfall Model • V-Model • Sawtooth Model • Alternative process models • Boehm’s Spiral Model • Issue-based Development Model • If time permits: Capability Maturity Model

3. Miscellanous • No exercise tomorrow, June 8 • No lecture/exercise next week, Jun 14-15 • Next lectures • June 21: Unified Process • June 28: Methodologies / ( With Scrum Exercise) • July 5: Rationale Management (With Maven Exercise) • July 12: Writing Successful Project Proposals (Frank Mang, Accenture) • July 19: Exam

4. Inherent Problems with Software Development • Requirements are constantly changing • The client might not know all the requirements in advance • Frequent changes are difficult to manage • Identifying checkpoints for planning and cost estimation is difficult • There is more than one software system • New system must often be backward compatible with existing system (“legacy system”)

5. Adulthood Childhood Retirement Post- Development Pre- Development Development Software Life Cycle • The term “Lifecycle” is based on the metaphor of the life of a person: Conception

6. Typical Software Life Cycle Questions • Which activities should I select for the software project? • What are the dependencies between activities? • How should I schedule the activities? • For finding activities and dependencies we can use the same modeling techniques we used for software development: • Functional Modeling • Scenarios • Use Case Model • Structural modeling: • Object identification • Class Diagrams • Dynamic Modeling: • Activity Diagrams

7. Identifying Software Development Activities • Questions to ask: • What is the problem? • What is the solution? • What are the mechanisms that best implement the solution? • How is the solution constructed? • Is the problem solved? • Can the customer use the solution? • How do we deal with changes that occur during the development? Are enhancements needed?

8. Software Development Activities (Example 1) Requirements Analysis What is the problem? Application Domain What is the solution? System Design What are the mechanisms Detailed Design that best implement the solution? Solution Domain How is the solution constructed? Program Implementation Testing Is the problem solved? Delivery Can the customer use the solution? Maintenance Are enhancements needed?

9. Software Development Activities (Example 2) Application Domain What is the problem? Requirements Analysis System Design What is the solution? What is the solution in the context of an existing system or set of components? Object Design Solution Domain How is the solution constructed? Implementation

10. Definitions • Software life cycle: • Set of activities and their relationships to each other to support the development of a software system • Software development methodology: • A collection of techniques for building models - applied across the software life cycle

11. Software development <<include>> <<include>> <<include>> Problem definition System development System operation Client Project manager Developer Administrator End user Functional Model of a simple life cycle model

12. Activity diagram for the same life cycle model Software development goes through a linear progression of states called software development activities

13. Another simple life cycle model System Development and Market creation can be done in parallel and Must be done before the system upgrade activity

14. Two Major Views of the Software life cycle • Activity-oriented view of a software life cycle • all the examples so far • Entity-oriented view of a software life cycle

15. Entity-centered view of software development Software development consists of the creation of a set of deliverables

16. Combining activities and entities in one view

17. Process Group Process IEEE Std 1074: Standard for Software Life Cycle Activities IEEE Std 1074 Develop- ment Pre- Development Project Management Post- Development Cross- Development (Integral Processes) > Project Initiation >Project Monitoring &Control > Software Quality Management > Requirements > Design > Implemen- tation > V & V > Configuration Management > Documen- tation > Training > Installation > Operation & Support > Maintenance > Retirement > Concept Exploration > System Allocation

18. Processes, Activities and Tasks • Process Group: Consists of a Set of Processes • Process: Consists of Activities • Activity: Consists of sub activities and tasks Development Process Group Process Design Activity Design Database Task Make a Purchase Recommendation

19. Example • The Design Process is part of Development • The Design Processconsists of the following Activities • Perform Architectural Design • Design Database (If Applicable) • Design Interfaces • Select or Develop Algorithsm (If Applicable) • Perform Detailed Design (= Object Design) • The Design Database Activity has the following Tasks • Review Relational Databases • Review Object-Oriented Databases • Make a Purchase recommendation • ....

20. Object Model of the IEEE 1074 Standard Software Life Cycle Money * Process Group Time Participant * Process * Resource * Work Unit consumed by * * Activity Task Work Product produces

21. Life Cycle Modeling • Many models have been proposed to deal with the problems of defining activities and associating them with each other • The first model proposed was the waterfall model [Royce 1970]

22. Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process The Waterfall Model of the Software Life Cycle adapted from [Royce 1970]

23. DOD Standard 2167A • Example of a waterfall model with the following software development activities • System Requirements Analysis/Design • Software Requirements Analysis • Preliminary Design and Detailed Design • Coding and CSU testing (CSU = Computer Software Unit) • CSC Integration and Testing (CSC = Computer Software Component, can be decomposed into CSC's and CSU's) • CSCI Testing (CSCI = Computer Software Configuration Item) • System integration and Testing • Required by the Department of Defense for all software contractors in the 1980-90s

24. Decision point: The next activity is initiated only if the review is successful System Requirements Preliminary Analysis Design System Requirements Review Preliminary Design Review System Design Detailed Design System Design Review Critical Design Review (CDR) Software Requirements Analysis Software Specification Review CSC Coding & Integration CSU Testing & Testing … Activity Diagram of MIL DOD-STD-2167A

25. Acceptance System Testing Integration Testing Unit Testing Unit Testing Integration Testing System Testing From the Waterfall Model to the V Model Requirements Engineering Requirements Analysis System Design Object Design Implemen- tation

26. Activity Diagram of a V Model Is validated by precedes Problem with the V-Model: Developers Perception = User Perception

27. Sawtooth Model distinguishes between client and developers

28. Properties of Waterfall -based Models • Managers love waterfall models: • Nice milestones • No need to look back (linear system) • Always one activity at a time • Easy to check progress during development: 90% coded, 20% tested • However, software development is nonlinear • While a design is being developed, problems with requirements are identified • While a program is being coded, design and requirement problems are found • While a program is tested, coding errors, design errors and requirement errors are found

29. The Alternative: Allow Iteration Escher was the first:-)

30. Physical Construction of Escher’s Waterfall Model http://www.cs.technion.ac.il/~gershon/EscherForReal/

31. Spiral Model • The spiral model proposed by Boehm is an iterative model with the following activities • Determine objectives and constraints • Evaluate Alternatives • Identify risks • Resolve risks by assigning priorities to risks • Develop a series of prototypes for the identified risks starting with the highest risk. • Use a waterfall model for each prototype development (“cycle”) • If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round • If a certain risk cannot be resolved, terminate the project immediately

32. Concept of Operations Software Requirements Software Product Design Detailed Design Code Unit Test Integration and Test Acceptance Test Implementation For each round go through these activities Define objectives, alternatives, constraints Evaluate alternative, identify and resolve risks Develop, verify prototype Plan next round Rounds in Boehm’s Spiral Model Insert: Prototyping

33. Diagram of Spiral Model

34. Project Start Cycle 1, Quadrant IV: Determine Objectives, Alternatives and Constraints

35. Risk Analysis Cycle 1, Quadrant I: Evaluate Alternatives, Identify, resolve risks

36. Concept of Operation Activity Cycle 1, Quadrant II: Develop and Verify

37. Requirements and Life cycle Planning Cycle 1, Quadrant III: Prepare for Next Activity

38. Start of Round 2 Cycle 2, Quadrant IV: Software Requirements Activity

39. Project P1 Project P2 Spiral Model

40. Comparing two Projects Project P1 Project P3 Project P2

41. Limitations of Waterfall and Spiral Models • Neither of these model deals well with frequent change • The Waterfall model assume that once you are done with a phase, all issues covered in that phase are closed and cannot be reopened • The Spiral model can deal with change between phases, but once inside a phase, no change is allowed • What do you do if change is happening more frequently? • “The only constant is the change”

42. An Alternative: Issue-Based Development • A system is described as a collection of issues • Issues are either closed or open • Closed issues have a resolution • Closed issues can be reopened (Iteration!) • The set of closed issues is the basis of the system model SD.I1:Closed I1:Open A.I1:Open SD.I3:Closed I3:Closed I2:Closed A.I2:Open SD.I2:Closed Planning Requirements Analysis System Design

43. Waterfall Model: Analysis Phase I1:Open A.I1:Open I2:Open I3:Open A.I2:Open SD.I1:Open Analysis Analysis SD.I3:Open SD.I2:Open

44. Waterfall Model: Design Phase I1:Closed A.I1:Open I2:Closed I3:Open A.I2:Open SD.I1:Open Analysis Analysis SD.I3:Open SD.I2:Open Design

45. Waterfall Model: Implementation Phase I1:Closed A.I1:Closed I2:Closed I3:Closed A.I2:Closed SD.I1:Open Analysis SD.I3:Open SD.I2:Open Design Implementation

46. Waterfall Model: Project is Done I1:Closed A.I1:Closed I2:Closed I3:Closed A.I2:Closed SD.I1:Open Analysis SD.I3:Open SD.I2:Open Design Implementation

47. Issue-Based Model: Analysis Phase I1:Open D.I1:Open I2:Open I3:Open Imp.I1:Open Analysis:80% Design: 10% Implemen-tation: 10%

48. Analysis:40% Design: 60% Implemen-tation: 0% Issue-Based Model: Design Phase I1:Closed SD.I1:Open I2:Closed I3:Open SD.I2:Open Imp.I1:Open Imp.I3:Open Imp.I2:Open

49. Analysis:10% Design: 10% Implemen-tation: 60% Issue-Based Model: Implementation Phase I1:Open A.I1:Open I2:Closed I3:Closed A.I2:Closed SD.I1:Open SD.I3:Open SD.I2:Closed

50. Issue-Based Model: Prototype is Done I1:Closed A.I1:Closed I2:Closed I3: Pending A.I2:Closed SD.I1:Open SD.I3:Closed SD.I2: Unresolved