1 / 59

Software Development Process: Life Cycle Models

Software Development Process: Life Cycle Models. Aditya P. Mathur. Department of Computer Science. Purdue University, West Lafayette. Last Update: Tuesday August 19, 2003. Objectives. What is a process?. What is Software Development Process (SDP) ?.

reid
Download Presentation

Software Development Process: Life Cycle Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 ? BITSC461/IS341 Software Engineering

  3. Input Output Output Input Output Input Input Process Step Step 1 Step 2 Sequential or linear process BITSC461/IS341 Software Engineering

  4. Output Input Input Step 1 Step 3 Output Input Step 2 Output Input Concurrent Process Parallel or concurrent process BITSC461/IS341 Software Engineering

  5. Output Input Input Step 1 Step 3 Output Input Step 2 Output Input Iterative Process Iterative process BITSC461/IS341 Software Engineering

  6. 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. BITSC461/IS341 Software Engineering

  7. Output Input Output Input Step 1 Step 2 Linear model Input Process model: Linear • An arrangement of process steps. BITSC461/IS341 Software Engineering

  8. Concurrent Output Input Input Step 1 Step 3 Output Input Step 2 Output Input Process model: Concurrent BITSC461/IS341 Software Engineering

  9. Output Input Input Output Step 1 Step 3 Input Step 2 Output Input Iterative Process model: Iterative BITSC461/IS341 Software Engineering

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

  11. Models of Software Life Cycle • Build and fix • Waterfall (classic) • Rapid prototyping • Incremental • Spiral • Unified BITSC461/IS341 Software Engineering

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

  13. 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]. BITSC461/IS341 Software Engineering

  14. 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. BITSC461/IS341 Software Engineering

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

  16. 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. BITSC461/IS341 Software Engineering

  17. Waterfall model [3] • Each phase terminates only when the documents are complete and approved by the SQA group. • Notice the feedback loop between the Design phase and the Specifications phase. • 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. BITSC461/IS341 Software Engineering

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

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

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

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

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

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

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

  25. 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. BITSC461/IS341 Software Engineering

  26. Unified Development Process [3] BITSC461/IS341 Software Engineering

  27. 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 BITSC461/IS341 Software Engineering

  28. 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 This is what makes the Unified process Unique 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 BITSC461/IS341 Software Engineering

  29. The Unified Process User’s requirements Software Development Process Software System BITSC461/IS341 Software Engineering

  30. 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? BITSC461/IS341 Software Engineering

  31. 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 BITSC461/IS341 Software Engineering

  32. 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 BITSC461/IS341 Software Engineering

  33. The Unified Process • Look at the whole process • Life cycle • Artifacts • Workflows • Phases • Iterations BITSC461/IS341 Software Engineering

  34. 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 BITSC461/IS341 Software Engineering

  35. The Life of the Unified Process Time Inception Elaboration Construction Transition Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration 1 1 1 1 Release 1 A cycle with its phases and its iterations BITSC461/IS341 Software Engineering

  36. 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. • Rapid prototyping: Ensures that delivered product meets client needs; might become a build-and-fix model. • Incremental: Maximizes early return on investment; requires open architecture; may degenerate into build-and-fix. BITSC461/IS341 Software Engineering

  37. 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. BITSC461/IS341 Software Engineering

  38. 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 ? BITSC461/IS341 Software Engineering

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

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

  41. 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% BITSC461/IS341 Software Engineering

  42. 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% BITSC461/IS341 Software Engineering

  43. 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% BITSC461/IS341 Software Engineering

  44. Standish Report: Success Profile [1] Project Success Factors % of Responses User Involvement 5.9% Executive Management Support 13.9% Clear Statement of Requirements 13.0% Proper Planning 9.6% Realistic Expectations 8.2% BITSC461/IS341 Software Engineering

  45. Standish Report: Success Profile [2] Project Success Factors % of Responses Smaller Project Milestones 7.7% Competent Staff 7.2% Ownership 5.3% Clear Vision & Objectives 2.9% Hard-Working, Focused Staff 2.4% Other 13.9% BITSC461/IS341 Software Engineering

  46. 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 BITSC461/IS341 Software Engineering

  47. Standish Report: Success Potential Success Criteria Points 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) 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) TOTAL 100 1029 100 85 BITSC461/IS341 Software Engineering

  48. Capability Maturity Model (CMM) 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. Purpose: To assess and help improve process in software development organizations. BITSC461/IS341 Software Engineering

  49. Capability Maturity Model (CMM) • Capability maturity levels: • Level 1: Initial Worst • Level 2: Repeatable • Level 3: Defined • Level 4: Managed • Level 5: Optimizing Best BITSC461/IS341 Software Engineering

  50. 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. BITSC461/IS341 Software Engineering

More Related