Software Life Cycle Models | jody@acm.org |
Primary functions of a software process model
- Determine the order of the stages involved in software development and evolution
What shall we do next?
- Establish the transition criteria for progressing from one stage to the next
How long shall we continue to do it?
Why are software process models important?
- They provide guidance on the order in which a software development project should carry out its major tasks.
Life Cycle Models
Code & Fix (1950s+) [AKA: Code & Go or Cut & Run]
Difficulties
- Problems to be solved were becoming more complex; harder to visualize without a lot more advance work in the thinking or design stage
- Managers and users were becoming disenchanted with late delivery dates of promised code
- Users were dissatisfied with the quality of the delivered products
- Code was expensive to fix -- poor preparation for testing and modification
Design -- Code -- Test -- Maintenance (1960s)
Problems
- Limited viewpoint
- User requirements that are missed or misinterpreted
- Delivery of a product the user does not want
- Cost overruns
Waterfall (1970+)
Model Phases
- Each phase is required
- Each phase ends with a verification, validation, or test activity to ensure that the objectives of each phase are satisfied
- The product goes through each phase sequentially and produces ever improving baselines or intermediate products
- Interactions within a phase occur until it is verified or validated to be satisfactory
- The baseline, once achieved, is put under formal change control process
(No changes are made to the baseline unless all interested parties agree.)
Economic Rationales:
- In order to achieve a successful software product, must achieve all of the subgoals within each phase at some stage anyway.
- Any different ordering of the phases will produce a less successful software product.
(It costs more to remove defects later in the development cycle.)Problems
"Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision -- revision that provides for iterative development and specification of prototypes and products." --Brooks
- A sequential approach to building a product in which iteration is not visibly evident.
- Emphasis on fully elaborated documents as completion criteria for early requirements and design phases does not work well for many classes of software, particularly interactive end-user applications.
Intermediate Models:
Evolutionary Development Model
Transform Model
Spiral Model
Model Cycles
Major distinguishing feature:
It creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process, thereby hoping toThe Spiral Development Model is a model generator (or meta-model). The risk-driven subsetting of the spiral model steps accommodate any mixture of specification-oriented, prototype-oriented, and simulation-oriented approaches to software development.
- minimize risk of failure
- improve estimation
- reduce overruns
- reduce cost-to-fix
- reduce generation of useless products
WinWin Spiral Model
Model Cycles
Major distinguishing feature:
Adds three activities to the front end of each spiral cycle:The additional activities account for where the elaborated objectives, constraints, and alternatives come from (a noted difficulty with the spiral model as originally proposed). This more clearly identifies the rationale involved in negotiating the "win" conditions for the product.
- Identify the system or subsystem's key stakeholders
- Identify the stakeholders' win conditions for the system or subsystem
- Negotiate win-win reconciliations of the stakeholders' win conditions
(See: Boehm, B. et al., "Using the WinWin Spiral Model: A Case Study." IEEE Computer, July 1998, pp. 33-44.)