While the Waterfall Model presents a straightforward view of the software life cycle, this view is only appropriate for certain classes of software development. Specifically, the Waterfall Model works well when the software requirements are well understood (e.g., software such as compilers or operating systems) and the nature of the software development involves contractual agreements. The Waterfall Model is a natural fit for contract-based software development since this model is document driven; that is, many of the products such as the requirements specification and the design are documents. These documents then become the basis for the software development contract.
According to Boehm, however, this model "does not work well for many classes of software, particularly interactive end-user applications." Specifying the requirements for such applications is notoriously difficult since interface design is highly subjective and clients rarely ever understand the real needs the software should meet. As a result, "document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision-support functions, followed by the design and development of large quantities of unusable code" [Boehm 1988]. The problem is that a contract is signed before the real requirements of the system are properly understood.
In addition to this shortcoming, the Waterfall model provides no means for risk assessment and management during the life cycle. Consider the case of the baggage-handling system at the Denver International Airport (DIA) again. Initially, DIA had intended that each individual airline would be responsible for building its own baggage-handling system. However, when American Airlines (AA) decided to use DIA as its second-largest hub airport, AA commissioned BAE Automatic Systems to develop an automated baggage-handling system efficient enough to allow AA to turn aircraft around in under thirty minutes. As the construction of the airport progressed, a larger vision emerged "for the inclusion of an airport-wide integrated baggage-handling system that could provide a major improvement in the efficiency of luggage delivery." To accommodate the vision, DIA negotiated a new contract with BAE to develop the airport-wide baggage system. This new plan, however, "underestimated the high complexity of the expanded system, the newness of the technology, and the high level of coordination required among the entities housed at DIA that were to be served by the system" [Montealegre 1996]. Despite the enormous change in the specifications of the project, no one gave any thought to risk assessment. Had the developers considered the risks involved with changing the system requirements radically at a late stage of development, they may have concluded that the expanded plan was infeasible. In the end, DIA had to settle with a much less ambitious plan, and Montealegre reports that "six months after the de-scaling of the system, the airport was able to open and operate successfully."
|Objectives||The goals of the software project||
Significantly improve software quality
|Constraints||Limitations which the project must meet||
|Alternatives||Possible ways to achieve the objectives||
|Risks||Potential risks for this phase||
No cost effective
quality improvement possible
|Strategies for reducing the risks||
Literature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars
|Results||Results of applying risk resolution strategies||
formal methods is limited - very hard to quantify improvements
|Plans||Development plans for the next phase||
option in more detail
|Commitment||Resources needed to achieve the plans||
Fund further 18-month study phase
|Spiral Model Template|
In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.
The animation below illustrates how the eight management elements of the Spiral Model template are organized in each phase. Click "Start Tutorial" to view the animation.
The final phase of the Spiral Model is analogous to the Waterfall Model. At this point in the project, the software requirements should be well-understood through the development of several prototypes. The project should also have resolved the major risks involved with building the final version of the software. With these issues resolved, the detailed design of the software enters the last three processes of the Waterfall Model, and the software is created. Although some of the labels in the Spiral Model are different, the same processes are represented. The table below shows the correspondence between the final phase of the Spiral Model and the Waterfall model.
Notice, however, that the maintenance process which appeared as dashed lines in the complete Waterfall Model seems to be missing from the Spiral Model. What happened to this process? Boehm  explains: "The answer to [this question] involves an observation that the spiral model applies equally well to development or [maintenance] efforts. In either case, the spiral gets started by a hypothesis that a particular operational mission could be improved by a software effort." Thus maintenance simply becomes another spiral or phase in the life cycle of the software. Like the previous phase, the maintenance efforts undergo risk assessment to evaluate whether changes are feasible.
- Boehm, B. (1988), "A Spiral Model of Software Development and Enhancement," IEEE Computer 21, 5, 61-72.
- Frankovich, J. (1998), "Synopsis of the Carnegie Mellon University course on Requirements Engineering," http://sern.ucalgary.ca/courses/seng/621/W97/johnf/reqeng.htm.
- Montealegre, R. (1996), "What Can We Learn from the Implementation of the Automated Baggage-Handling System at the Denver International Airport," In Proceedings of the Association for Information Systems Americas Conference.
- Schach, R. (1999), Software Engineering, Fourth Edition, McGraw-Hill, Boston, MA.
- Sommerville, I. (1996), Software Engineering, Fifth Edition, Addison-Wesley, Reading, MA, pp. 14.