1. Aug 19, 2003BITSC461/IS341 Software Engineering Software Development Process: Life Cycle Models Last Update: Tuesday August 19, 2003 Aditya P. Mathur Purdue University, West Lafayette Department of Computer Science

2. Aug 19, 2003BITSC461/IS341 Software Engineering2 Objectives What is a process? What is Software Development Process (SDP) ? How is SDP organized (life cycle models)? How is process maturity measured? What are the benefits of a “good” process ?

3. Aug 19, 2003BITSC461/IS341 Software Engineering3 Process Step InputOutput Step 1 Input Step 2 Output Input Sequential or linear process

4. Aug 19, 2003BITSC461/IS341 Software Engineering4 Concurrent Process Input Step 3 Output Input Step 2 Input Output Step 1 Input Output Parallel or concurrent process

5. Aug 19, 2003BITSC461/IS341 Software Engineering5 Iterative Process Input Step 3 Output Input Step 2 Input Output Step 1 Input Output Iterative process

6. Aug 19, 2003BITSC461/IS341 Software Engineering6 Features of a process One or more steps. Each step is well defined. Input and output of each step is well defined and observable. Start and end of a step can be identified.

7. Aug 19, 2003BITSC461/IS341 Software Engineering7 Process model: Linear An arrangement of process steps. Step 1 Input Step 2 Output Input Linear model

8. Aug 19, 2003BITSC461/IS341 Software Engineering8 Process model: Concurrent Input Step 3 Output Input Step 2 Input Output Step 1 Input Output Concurrent

9. Aug 19, 2003BITSC461/IS341 Software Engineering9 Process model: Iterative Input Step 3 Output Input Step 2 Input Output Step 1 Input Output Iterative

10. Aug 19, 2003BITSC461/IS341 Software Engineering10 Software Development Process Steps correspond to one or more tasks related to software development. Tasks: o Requirements gathering o Requirements analysis o Design o Coding o Integration o Test o Delivery o Maintenance o Training Software life cycle: Software Life Cycle consists of all phases from its inception until its retirement. These are: Inception, elaboration, construction, transition.

11. Aug 19, 2003BITSC461/IS341 Software Engineering11 Models of Software Life Cycle Build and fix Waterfall (classic) Rapid prototyping Incremental Spiral Unified

12. Aug 19, 2003BITSC461/IS341 Software Engineering12 Build and fix model [1] Modify until client satisfied Operations mode Retirement Development Maintenance Idea or client request Build first version

13. Aug 19, 2003BITSC461/IS341 Software Engineering13 Build and fix model [2] Product is constructed without specifications. There is no explicit design. However, a design will likely evolve in the mind of the developer. The approach might work for small programming projects [TA 162/252].

14. Aug 19, 2003BITSC461/IS341 Software Engineering14 Build and fix model [3] Cost of fixing an error increases as one moves away from the phase in which the error was injected. There is a good chance that many errors will be found in the operations phase thereby leading to high cost of maintenance. Rarely used in commercial projects.

15. Aug 19, 2003BITSC461/IS341 Software Engineering15 Waterfall model [1] Design phase Implementation phase Integration phase Development Maintenance Requirements phase Specification phase Operations mode Retirement Verification done at the end of each phase.

16. Aug 19, 2003BITSC461/IS341 Software Engineering16 Waterfall model [2] Popular in the 70’s. Requirements are determined and verified with the client and members of the SQA group. Project management plan is drawn, cost and duration estimated, and checked with the client and the SQA group Then the design (i.e. “How is the product going to do what it is supposed to do.”) begins and the project proceeds as in the figure.

17. Aug 19, 2003BITSC461/IS341 Software Engineering17 Waterfall model [3] Each phase terminates only when the documents are complete and approved by the SQA group. Maintenance begins when the client reports an error after having accepted the product. It could also begin due to a change in requirements after the client has accepted the product. Notice the feedback loop between the Design phase and the Specifications phase.

18. Aug 19, 2003BITSC461/IS341 Software Engineering18 Waterfall model: Advantages Disciplined approach Testing in each phase. Careful checking by the Software Quality Assurance Group at the end of each phase. Documentation available at the end of each phase.

19. Aug 19, 2003BITSC461/IS341 Software Engineering19 Waterfall model: Disdvantages Documents do not always convey the entire picture. Feedback from one phase to another might be too late and hence expensive. Specification documents are detailed and difficult to read/understand for the client.

20. Aug 19, 2003BITSC461/IS341 Software Engineering20 Rapid prototyping model A working model of the product is developed (quickly, 1-3 months). Serves to elicit requirements. Subsequent phases, design, coding etc., follow. Feedback loops less likely and fewer. Client interacts with the prototype; specifications are developed. Should the prototype be discardded or refined ?

21. Aug 19, 2003BITSC461/IS341 Software Engineering21 Incremental model [1] Architectural Design For each build: Detailed design, coding, Integration, test, delivery. Development Maintenance Requirements phase Specification phase Operations mode Retirement Verification done at the end of each phase.

22. Aug 19, 2003BITSC461/IS341 Software Engineering22 Incremental model [2] Product is designed, implemented, and integrated as a series of incremental builds. A new build integrates code from previous build and new code. A build contains code from various modules to provide the desired functionality. Product architecture is designed. It serves as the main driver of the development process. Features are prioritised and increments defined.

23. Aug 19, 2003BITSC461/IS341 Software Engineering23 Incremental model [3] Client pays in increments; financial benefit. Should we construct builds in parallel? Design of the initial architecture is a difficult step. Poor architecture may lead to lots of changes in builds. Client can begin using the first build. Facilitates early adoption by the client.

24. Aug 19, 2003BITSC461/IS341 Software Engineering24 Unified Development Process [1] Each iteration produces a working, executable, product that might not be a deliverable. No rush to code. Aslso, not a long drwan design process. Key features: Iterative development; OO analysis and design. Development organized as a series of short iterations Lots of visual modeling aids. Unified Modeling Language (UML) used.

25. Aug 19, 2003BITSC461/IS341 Software Engineering25 Unified Development Process [2] Architecture is built during early iterations. Early iterations seek feedback from the customer. Risk and value to customer is managed through early feedback. Customer is engaged continuously in evaluation and requirements gathering.

26. Aug 19, 2003BITSC461/IS341 Software Engineering26 Unified Development Process [3]

27. Aug 19, 2003BITSC461/IS341 Software Engineering27 The Unified Process Why a Process? Software projects are large, complex, sophisticated time to market is key many facets involved in getting to the end Common process should integrate the many facets provide guidance to the order of activities specify what artifacts need to be developed offer criteria for monitoring and measuring a project

28. Aug 19, 2003BITSC461/IS341 Software Engineering28 The Unified Process Component based - meaning the software system is built as a set of software components interconnected via interfaces Uses the Unified Modeling Language (UML) Use case driven Architecture-centric Iterative and incremental Component: A physical and replaceable part of a system that conforms to and provides realization of a set of interfaces. Interface: A collection of operations that are used to specify a service of a class or a component This is what makes the Unified process Unique

29. Aug 19, 2003BITSC461/IS341 Software Engineering29 The Unified Process User’s requirements Software Development Process Software System

30. Aug 19, 2003BITSC461/IS341 Software Engineering30 The Unified Process Use Case driven A use case is a piece of functionality in the system that gives a user a result of value Use cases capture functional requirements Use case answers the question: What is the system supposed to do for the user?

31. Aug 19, 2003BITSC461/IS341 Software Engineering31 The Unified Process Architecture centric similar to architecture for building a house Embodies the most significant static and dynamic aspects of the system Influenced by platform, OS, DBMS etc. Primarily serves the realization of use cases

32. Aug 19, 2003BITSC461/IS341 Software Engineering32 The Unified Process Iterative and Incremental commercial projects continue many months and years to be most effective - break the project into iterations Every iteration - identify use cases,create a design, implement the design Every iteration is a complete development process

33. Aug 19, 2003BITSC461/IS341 Software Engineering33 The Unified Process Look at the whole process Life cycle Artifacts Workflows Phases Iterations

34. Aug 19, 2003BITSC461/IS341 Software Engineering34 The Life of the Unified Process Unified process repeats over a series of cycles Each cycle concludes with a product release Each cycle consists of four phases: inception elaboration construction transition

35. Aug 19, 2003BITSC461/IS341 Software Engineering35 The Life of the Unified Process ElaborationInceptionConstructionTransition Iteration Release 1 1 1 11 Time A cycle with its phases and its iterations

36. Aug 19, 2003BITSC461/IS341 Software Engineering36 Life Cycle Models: Summary [1] Build and fix: Acceptable for short programs that do not require maintenance. Waterfall: Disciplined approach, document driven; delivered product may not meet client needs. Incremental: Maximizes early return on investment; requires open architecture; may degenerate into build- and-fix. Rapid prototyping: Ensures that delivered product meets client needs; might become a build-and-fix model.

37. Aug 19, 2003BITSC461/IS341 Software Engineering37 Life Cycle Models: Summary [2] Spiral: Risk driven, incorporates features of the above models; useful for very large projects UDP: Iterative, supports OO analysis and design; may degenerate into code-a-bit-test-a-bit.

38. Aug 19, 2003BITSC461/IS341 Software Engineering38 Objectives Why do software projects fail/succeed? How is process maturity measured ? Key Process Areas? How to do requirements analysis? What are UML, use cases, domain model, actors ?

39. Aug 19, 2003BITSC461/IS341 Software Engineering39 Standish Report [1995] Large company: >$500M Medium company: $200-500M Small comp;any: $100-200M Company categorization by revenue: Sample size: 365 respondants, 8380 applications.

40. Aug 19, 2003BITSC461/IS341 Software Engineering40 Standish Report: Project categorization: Success/failure Resolution Type 1: On time, on budget, all features. Resolution Type 2: Completed, over time, over budget, fewer features. Resolution Type 3: Cancelled during the development cycle. 16.2% 52.7% 31.1%

41. Aug 19, 2003BITSC461/IS341 Software Engineering41 Standish Report: Failure Statistics Success rate: Large companies: 9% Medium: 16.2% Small: 28% Resolution type 2: Large: 61.5% Medium: 46.7% Small: 50.4% Resolution type 3: Medium: 37.1%, Large: 29.5% Small: 21.6%

42. Aug 19, 2003BITSC461/IS341 Software Engineering42 Standish Report: Cost Overruns Cost Overruns % of Responses Under 20% 15.5% 21 - 50% 31.5% 51 - 100% 29.6% 101 - 200% 10.2% 201 - 400% 8.8% Over 400% 4.4%

43. Aug 19, 2003BITSC461/IS341 Software Engineering43 Standish Report: Time Overruns Time Overruns % of Responses Under 20% 13.9% 21 - 50% 18.3% 51 - 100% 20.0% 101 - 200% 35.5% 201 - 400%11.2% Over 400% 1.1%

44. Aug 19, 2003BITSC461/IS341 Software Engineering44 Standish Report: Success Profile [1] Project Success Factors% of Responses 1. User Involvement 5.9% 2. Executive Management Support 13.9% 3. Clear Statement of Requirements 13.0% 4. Proper Planning 9.6% 5. Realistic Expectations 8.2%

45. Aug 19, 2003BITSC461/IS341 Software Engineering45 Standish Report: Success Profile [2] Project Success Factors% of Responses 6. Smaller Project Milestones7.7% 7. Competent Staff 7.2% 8. Ownership 5.3% 9. Clear Vision & Objectives 2.9% 10. Hard-Working, Focused Staff 2.4% 11. Other 13.9%

46. Aug 19, 2003BITSC461/IS341 Software Engineering46 Standish Report: Failure stories California DMV: Started 1987. Project cancelled: 1993. Cost:$45M American airlines: 1994 Settled lawsuit with Hilton/Marriott/Budget-rent-a car CONFIRM car rental project failed

47. Aug 19, 2003BITSC461/IS341 Software Engineering47 Standish Report: Success Potential Success CriteriaPoints DMV CON HYATT ITAMARATI 1. User Involvement 19 NO ( 0) NO ( 0) YES (19)YES (19) 2. Management Support 16 NO ( 0) YES (16) YES (16) YES (16) TOTAL 100 10 29 100 85 3. Clear Requirements 15 NO ( 0) NO ( 0) YES (15) NO ( 0) 5. Realistic Expectations 10 YES (10) YES (10) YES (10) YES (10) 10. Hard-Working Staff 3 NO ( 0) YES ( 3) YES ( 3) YES ( 3)

48. Aug 19, 2003BITSC461/IS341 Software Engineering48 Capability Maturity Model (CMM) Purpose: To assess and help improve process in software development organizations. Process maturity is a measure of the discipline used by an organization during the development of a software product. CMM assists in determining how mature a process is.

49. Aug 19, 2003BITSC461/IS341 Software Engineering49 Capability Maturity Model (CMM) Capability maturity levels: Level 1:InitialWorst Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: OptimizingBest

50. Aug 19, 2003BITSC461/IS341 Software Engineering50 CMM Levels [1] Initial The software process is characterized as ad hoc, and occasionally even as chaotic. Few processed are defined, and success depends on individual effort. Lacks: Reasonable process.

51. Aug 19, 2003BITSC461/IS341 Software Engineering51 CMM Levels [2] Repeatable Basic project management processes are established to track cost, schedule and functionality. the necessary process discipline is in place to repeat earlier successes on projects with similar applications. Lacks: Complete process.

52. Aug 19, 2003BITSC461/IS341 Software Engineering52 CMM Levels [3] Defined The software process for both management and engineering activities is documented, standardized and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. Lacks: Predictable outcomes.

53. Aug 19, 2003BITSC461/IS341 Software Engineering53 CMM Levels [4] Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. Lacks: Mechanism for process improvement.

54. Aug 19, 2003BITSC461/IS341 Software Engineering54 CMM Levels [4] Optimized Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

55. Aug 19, 2003BITSC461/IS341 Software Engineering55 Key Process Areas [1] Optimizing Defect prevention Technology change management Process change management Managed: Quantitative process management Software quality management

56. Aug 19, 2003BITSC461/IS341 Software Engineering56 Key Process Areas [2] Defined Organization process focus Training programs Integrated software management Peer reviews Repeatable Requirements management Software project planning Software quality assurance Software configuration management

57. Aug 19, 2003BITSC461/IS341 Software Engineering57 Maturity and product quality [1] Results from 34Motorola Government Electronics Division(GED)projects -------------------------------------------------------------- --------------------------------------------------------------------- CMM Level# ProjectsRelativeFaults/M/MEASLRelative DecreaseinProductivity Duration ------- 131---- 293.28901.0 352.74110.8 485.02052.3 597.81262.8 --------------------------------------------------------------------- MEASL: MillionEquivalent AssemblerSource Lines

58. Aug 19, 2003BITSC461/IS341 Software Engineering58 Maturity and product quality [2]

59. Aug 19, 2003BITSC461/IS341 Software Engineering59 CMM Documents ? http://www.sei.cmu.edu/cmm/cmms/cmms.html