Selecting Software Development Life Cycles Adapted from Chapter 4, Futrell
Examples of Software Life Cycle Models Classical Waterfall Waterfall with feedback V-Shaped Prototyping Incremental Spiral Rapid Application Development Combination
Classic Waterfall Model Systems engineering Analysis Design Code Classical engineering approach Associated with DOD-STD-2167A Explicit start and end points to phases Clearly defined milestones Testing Maintenance
Waterfall Model with Feedback System Requirements V&V Activities Software Requirements V&V Activities Preliminary Design V&V Activities Detailed Design V&V Activities Code and Debug Developmental Test Test and Preoperations V&V Activities Operations and Maintenance V&V Activities
Strengths of the Waterfall Model It is easy to understand It is easy to use (when applied to a project for which it is suited) It is easy to track the progress of the project using a timeline or Gantt chart -- the completion of each phase is used as a milestone Allows for tight control -- defines quality control procedures The model is well known by non-software customers and end-users and is used by other organizations to track projects not related to software development
Weaknesses of the Waterfall Model It does not easily handle concurrent events -- development teams are delayed waiting on others It does not handle iterations among phases-- the sequential flow is not always realistic The user is involved only in the beginning of the process, while gathering requirements, and at the end, during acceptance testing Customers can rarely state all requirements at the beginning of the project The customer does not get to see the product until late in the life cycle The model is not equipped to handle dynamic changes in requirements over the life cycle -- deliverables are frozen
V-Shaped Model Project Requirements and Planning Production, Operation, and Maintenance Product Requirements and Specification Analysis System Testing Architectural or High-Level Design Integration and Testing Detailed Design Unit Testing Coding
Strengths of the V-Shaped Model The model is easy to understand It is easy to use (when applied to a project for which it is suited) It is easy to track the progress of the project using a timeline or Gantt chart -- the completion of each phase is used as a milestone The model emphasizes planning for verification and validation of the product in the early stages of product development The model encourages verification and validation of the requirements and design, not just the code of the product
Weaknesses of the V-Shaped Model The model does not easily handle concurrent events It does not handle iterations of phases The model is not equipped to handle dynamic changes in requirements throughout the life cycle The model is not equipped to handle dynamic changes in requirements over the life cycle The requirements are tested too late in the cycle to make changes without affecting the schedule for the project The V-Shaped model may be modified to overcome these weaknesses by including iteration loops to handle the changing of requirements beyond the Analysis phase.
Prototyping Model Plan to throw one away In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, starting but smarter, and build a redesigned version The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to deliver a throwaway to customers. - Fred Brooks, The Mythical Man-Month, 1975 p. 116 Promising Attacks on the Conceptual Essence The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system If done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. - Fred Brooks, No Silver Bullet, 1986
Evolutionary Rapid Prototyping Model Design Derivation Prototype Iteration User Approval Functions Rapid Analysis Project Plan Database Creation Tuning User Interface Operation and Maintenance
Strengths of the Rapid Prototyping Model The end user can see the system requirements as they are being gathered by the project team -- customers get early interaction with system There is less room for confusion, miscommunication or misunderstanding in the definition of the system requirements, leading to a more accurate end product -- customer and developer have a baseline to work against The model allows for flexible design and development
Weaknesses of the Rapid Prototyping Model If the users cannot be involved during the rapid prototype iteration phase of the life cycle, this can have adverse effects on the final product The rapid prototype is a partial system during the prototype iteration phase. If the project is risky and may not be completed, the end user will be left with only a partial system The customer may expect look and feel of the prototype The customer may want to have prototype delivered rather than waiting for full, well engineered version If the prototyping language or environment is not consistent with the production language or environment, there can be delays in full implementation of the production system Quality can suffer
Planning Spiral Model Risk analysis Initial requirements gathering and project planning Planning based on customer comments Risk analysis based on initial requirements Risk analysis based on customer reaction Go, no go decision Customer evaluation Customer evaluation Partitions process into four distinct quadrants Emphasizes evolutionary development Accommodates 1980s paradigms Stresses formal risk analysis Toward a completed system Initial software prototype Next level prototype Engineered system Engineering
Evolutionary Spiral Model Commit to Proceed 1. Understand Context Update Spiral Plan Review Progress 5. Manage and Plan Develop/Update Estimate of the Situation Define/Refine Approach - Stakeholders - Objectives - Alternatives - Constraints Place Product Under Change Control Review Context Review Technical Product Perform Risk Analysis Review Risk Analysis Source: Software Productivity Consortium Evolutionary Spiral Process Model Guidebook 2. Analyze Risks Plan Risk Aversion Evaluate Risk Aversion Develop and Verify Product Monitor and Review Review Alternative Plan and Schedule Commit to Risk Aversion Strategy Commit to Plan 4. Develop Product 3. Plan Development
Strengths of the Spiral Model The model embraces the waterfall model while allowing for iteration throughout the phases of that model It is driven by risk analysis and is ideal for those projects which represent a medium to high risk The users see the product early, via the proof of concept and rapid prototypes in the development life cycle The users are closely tied to the development efforts All of the money needed for the project need not be allocated up front The model handles changes in requirements by allowing for iteration through the Analysis & Design phase and Execute Phase
Weaknesses of the Spiral Model If the project is low risk, this model can be an expensive life cycle model -- much time is spent evaluating the risk after each iteration within the model and considerable risk assessment expertise is required It may require unrealistic overhead for small projects The creation of a prototype may not always be the appropriate type of product development It hasn t been used as widely as linear sequential The lack of a good prototyping tool or technique can make this model clumsy to use Adaptations of the model include: Replacement of the prototypes with an increment of a product Iteration within one of the spirals of the model illustrated by a two headed arrow Replacement of the prototypes with rapid application development product iteration
Rapid Application Development (RAD) Model User Community Development Effort Requirement s Planning User Description Construction Cut Over TIME
RAD Model TIME business modeling data data modeling process modeling Team 1 Deadline business modeling data data modeling process modeling Team 2 application application generation generation testing & testing & turnover turnover
Strengths of the RAD Model The model has shown reduced cycle time due to the use of powerful development tools The end user is involved throughout the life cycle The system is developed by a project team familiar with the problem domain; thus it continues to build upon this expertise can deliver a full product in a short time period
Weaknesses of the RAD Model If the users cannot be involved consistently throughout the life cycle, this can have adverse effects on the final product This model requires highly skilled and well-trained developers in the use of the chosen development tools to achieve the rapid turnaround time It can require more people It requires a system that can be properly modularized It can fail if reusable components are not available
Incremental Model One of the Evolutionary Models Combines elements of the linear sequential model and prototyping Requirements of the system are prioritized The first increment is the delivery of the core product, providing only the highest priority requirements Subsequent iterations expand on this core (enhancement maintenance)
Incremental Model System/information engineering analysis analysis design design code code test test delivery of 1st increment analysis analysis design design code code test test delivery of 2nd increment analysis analysis design design code code test test TIME delivery of 3rd increment
Strengths of the Incremental Model The costs of developing a system can be reduced by defining smaller incremental releases with reduced function The duration of the development cycle can be reduced with this model, allowing the product to be released quicker, perhaps in response to a market window Delivers a usable working product quickly Keeps all teams working The use of this model on a project with new technology can allow the user to adjust to the system in smaller incremental steps rather than leaping to a major new product This model is often combined with other models, such as the spiral model.
Weaknesses of the Incremental Model The model does not allow for iteration within each increment The definition of a complete, fully functional system must be done early in the life cycle to allow for the definition of the increments Allow you to design yourself into a corner It works best with an even distribution of different priority features It requires good planning and design
Microsoft Product Release using Combined Models Virus Backup Outside Procurement and Integration Fixes V-Shaped Disk Doublespace Waterfall File Recovery Spiral Memory Management Prototype Release Vxx.xx Incremental
Combination Model Preliminary requirements gathering Requirements analysis Prototyping 4GT Spiral model Design Prototyping: n-th iteration 4GT Coding Spiral model n -th iteration 4GT Testing Operational system Maintenance
Selecting a Life Cycle Model Examine project characteristic categories: Uncertainty of Requirements Requirements, Functional needs of the application Project Team, Availability of Resources User Community Project Type, complexity of project Cost of Application Cost of Future Upgrades Discrete / Gradual Requirements Change, Volume Ease of Use of life cycle, Reuse Longevity of the application Product technology Risk
Selecting a Life Cycle Model Project Characteristic Category Matrix Requirements Requirements Waterfall V-Shaped Prototype Spiral RAD Incremental Are the requirements easily defined and/or well known? Can the requirements be defined early in the cycle? Will the requirements change often in the cycle? Yes Yes No No Yes No Yes Yes No No Yes Yes No No Yes Yes No No Is there a need to demonstrate the requirements to achieve definition? No No Yes Yes Yes No Is a prrof of concept required to demonstrate capability? No No Yes Yes Yes No
Selecting a Life Cycle Model Project Characteristic Category Matrix Project Team Project Team Waterfall V-Shaped Prototype Spiral RAD Incremental Are the majority of team members new to the problem domain for the project? Are the majority of team members new to the technology domain for the project? Are the majority of team memebers new to the tools to be used on the project? Are the team members subject to reassignment during the life cycle? Is there training available for the project team if required? No No Yes Yes No No Yes Yes No Yes No Yes Yes Yes No Yes No No No No Yes Yes No Yes No Yes No No Yes Yes
Selecting a Life Cycle Model Project Characteristic Category Matrix User Community User Community Will the availability of the user representatives be restriced, or limited during the life cycle? Are the user representatives new to system definition? Are the user representatives experts in the problem domain? Do the users want to be involved in all phases of the life cycle? Waterfall V-Shaped Prototype Spiral RAD Incremental Yes Yes No Yes No Yes No No Yes Yes No Yes No No Yes No Yes Yes No No Yes No Yes No
Selecting a Life Cycle Model Project Characteristic Category Matrix Project Type and Risk Project Type & Risk Waterfall V-Shaped Prototype Spiral RAD Incremental Does the project identify a new product direction for the organization? Is the project a system integration project? Is the project an enhancement to an existing system? Is the funding for the project expected to be stable throughout the life cycle? Is the product expected to have a long life in the organization? No No Yes Yes No Yes No Yes Yes Yes Yes Yes No Yes No No Yes Yes Yes Yes Yes No Yes No Yes Yes No Yes No Yes
Selecting a Life Cycle Model Whole Class Exercise #1 A company is rewriting its payroll system to move it from an old batch-type mainframe to a distributed mini-computer/pc-based networked setup. No new functionality will be added. The statement of work calls for a conversion as is. Only the input and output subsystems will be altered for the new environment. Since it is a payroll application, testing and verification will be emphasized within the development activities. The schedule allows five months for the project, with two people working on it. What do you think is the most Appropriate Life Cycle Approach? What is the advantage of this approach for this project?
Selecting a Life Cycle Model Whole Class Exercise #2 A company, an electronics giant, has recently decided to venture into a related small business area developing wristwatch communicators. The device would be similar to a two-way radio and would be expected to work over a 50-mile radius. The company has considerable previous experience on product lines similar to this, and believes that a cheaper price could present a value-added challenge to the cellular market. It would like to have a working model to present at a national electronics fair coming up six months from now. What do you think is the most Appropriate Life Cycle Approach? What is the advantage of this approach for this project?
Selecting a Life Cycle Model Whole Class Exercise #3 A company has recently completed a 3-year process to develop a cellular infrastructure switching system to compete with industry leaders such as Motorola and Ericsson. It is now ready to move into the next phase where new releases will be issued approximately every four months. An average of 15 new features and an appropriate number of bug fixes will be included in each release spread across teams composed of one to three engineers. Development times for the new features can range from one to five months. Some features can require multiple releases for full implementation. What do you think is the most Appropriate Life Cycle Approach? What is the advantage of this approach for this project?
Selecting a Life Cycle Model Whole Class Exercise #4 A company has created a new small business division to develop a specialized communications system. Approximately 15 persons will be transferred from key areas of the company to form the base for the venture. Some 28 additional people will be hired from the outside, the bulk of which are engineers. It has already been decided that Object-Oriented tools and approaches will be used with C++ as the language. None of the participants has any prior knowledge of these techniques, but will go through ten days of training when they come on board. In addition, a consortium-partner of the company has just released a new workstation platform (its first). Due to these alliances, the consortium platform will be the development platform of choice. Training is also being scheduled for the new workstation. The primary satellite supplier, OO Aerospace, has been having major financial difficulties due to military cutbacks and has laid off about 35 percent of its work force. What do you think is the most Appropriate Life Cycle Approach? What is the advantage of this approach for this project?
Customizing the Life Cycle Model Become familiar with the various models Review, analyze the type of work: development, enhancement, maintenance, etc. Review project criteria Identify a minimum set of phases Identify phase activities Establish a minimum set of deliverables Define templates and content guides for deliverables Evaluate progress and effectiveness of the life cycle framework Implement improvements
Preliminary Object-Oriented Analysis Models Used to Develop Initial Prototype Demonstrate to User User Provides Feedback for Provides Feedback for Demo to Used to Develop Expanded & Refined Prototype Expanded & Refined OOA Models Latest Version Becomes Approves Used to Develop Final Requirements Specification Final Version of Prototype
Iterate More Specs Rapid OOA More Objects Create Services More Services Demo Feedback Create Controls Iterate Create Objects More Controls Feedback = Approval? No Yes User Operation & Maintenance Performance Testing & Tuning
Software Life Cycles Summary There are many models or representations of the software life cycle Each model has its peculiar strengths and weaknesses The model selected for a project or the models used by an organization should meet the needs of the organization, the type of work to be done, and the skills and tools of the software practitioners using the model(s)