The spiral model, originally proposed by Boehm , is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model. It provides the potential for rapid
development of incremental versions of the software. Using the spiral model, software
is developed in a series of incremental releases. During early iterations, the
incremental release might be a paper model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a number of framework activities, also called task
regions.6 Typically, there are between three and six task regions. A spiral model
that contains six task regions:
• Customer communication—tasks required to establish effective communication
between developer and customer.
• Planning—tasks required to define resources, timelines, and other projectrelated
information.
• Risk analysis—tasks required to assess both technical and management
risks.
• Engineering—tasks required to build one or more representations of the
application.
• Construction and release—tasks required to construct, test, install, and
provide user support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback based
on evaluation of the software representations created during the engineering
stage and implemented during the installation stage.
Each of the regions is populated by a set of work tasks, called a task set, that are
adapted to the characteristics of the project to be undertaken. For small projects, the
number of work tasks and their formality is low. For larger, more critical projects,
each task region contains more work tasks that are defined to achieve a higher level
of formality
.
As this evolutionary process begins, the software engineering team moves around
the spiral in a clockwise direction, beginning at the center. The first circuit around
the spiral might result in the development of a product specification; subsequent
passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software. Each pass through the planning region
results in adjustments to the project plan. Cost and schedule are adjusted based on
feedback derived from customer evaluation. In addition, the project manager adjusts
the planned number of iterations required to complete the software.
Unlike classical process models that end when software is delivered, the spiral
model can be adapted to apply throughout the life of the computer software. An alternative
view of the spiral model can be considered by examining the project entry point
axis. Each cube placed along the axis can be used to represent
the starting point for different types of projects. A “concept development
project” starts at the core of the spiral and will continue (multiple iterations occur
along the spiral path that bounds the central shaded region) until concept development
is complete. If the concept is to be developed into an actual product, the process
proceeds through the next cube (new product development project entry point) and
a “new development project” is initiated. The new product will evolve through a number
of iterations around the spiral, following the path that bounds the region that has
somewhat lighter shading than the core. In essence, the spiral, when characterized
in this way, remains operative until the software is retired. There are times when the
process is dormant, but whenever a change is initiated, the process starts at the appropriate
entry point .
The spiral model is a realistic approach to the development of large-scale systems
and software. Because software evolves as the process progresses, the developer and
customer better understand and react to risks at each evolutionary level. The spiral model
uses prototyping as a risk reduction mechanism but, more important, enables the developer
to apply the prototyping approach at any stage in the evolution of the product. It
maintains the systematic stepwise approach suggested by the classic life cycle but incorporates
it into an iterative framework that more realistically reflects the real world. The
spiral model demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be difficult to
convince customers (particularly in contract situations) that the evolutionary approach
is controllable. It demands considerable risk assessment expertise and relies on this
expertise for success. If a major risk is not uncovered and managed, problems will
undoubtedly occur. Finally, the model has not been used as widely as the linear
sequential or prototyping paradigms. It will take a number of years before efficacy of
this important paradigm can be determined with absolute certainty.
