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."
 In 1988, Barry Boehm
proposed a more
comprehensive life
cycle model called the
Spiral Model to address
the inadequacies of the
Waterfall Model.
According to Boehm,
"the major
distinguishing feature
of the Spiral Model is
that it creates a risk-
driven approach to the
software process rather
than a primarily
document-driven or
code-driven process. It
incorporates many of
the strengths of other
models and resolves
many of their
difficulties"
[Boehm 1988]. Software projects encompass many different areas of risk such as project
cost overruns, changed requirements (e.g., the DIA baggage system), loss of key project
personnel, delay of necessary hardware, competition from other software developers,
technological breakthroughs which obsolete the project, and many others. The essential
concept of the Spiral Model is "to minimize risks by the repeated use of prototypes
[emphasis added] and other means. Unlike other models, at every stage risk analysis is
performed... The Spiral Model works by building progressively more complete versions
of the software by starting at the center of the spiral and working outwards. With each
loop of the spiral, the customer evaluates the work and suggestions are made for its
modification. Additionally, with each loop of the spiral, a risk analysis is performed
which results in a 'go / no-go' decision. If the risks are determined to be too great then the
project is terminated" [Frankovich 1998]. Thus, the Spiral Model addresses the problem
of requirements engineering through development of prototypes, and it addresses the need
for risk management by performing risk analysis at each step of the life cycle.

In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the
spiral), Boehm [1988] used the template below for risk assessment during the
development of a software productivity tool. The rows of the template represented various
management elements of the project. For each new phase, he created a new instance of the
template to review the status of the project and decided whether the risks were too great to
continue. To illustrate the use of the template, the rows have been filled with a fictitious
example phase [Sommerville 1996].
Template Explanation Example Phase
The goals of the software
Objectives Significantly improve software quality
project
 Within three years
Limitations which the
Constraints Without large-scale capital investment
project must meet
Without radical change to company standards
Reuse existing certified software
Possible ways to achieve
Alternatives Introduce formal specification and verification
the objectives
Invest in testing and validation tools
No cost effective quality improvement possible
Potential risks for this
Risks Quality improvements may increase costs excessively
phase
New methods might cause existing staff to leave
Risk Strategies for reducing the Literature survey, Pilot project, Survey of potential reusable components, Assessment
Resolution risks of available tool support, Staff training and motivation seminars
Experience of formal methods is limited - very hard to quantify improvements
Results of applying risk
Results Limited tool support available for company standard development system
resolution strategies
Reusable components available but little reuse tool support
Explore reuse option in more detail
Development plans for the
Plans Develop prototype reuse support tools
next phase
Explore component certification scheme
Resources needed to
Commitment Fund further 18-month study phase
achieve the plans
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.

[View in New Window]

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.
 Waterfall Model Spiral Model
Design Specifications Detailed design
Programming Code, Unit test
Integration Integration and test
Acceptance test,
Delivery
Implementation

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 [1988] 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.

References

• 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.