Page 65 -

36 PART ONE THE PRODUCT AND THE PROCESS

The incremental process model, like prototyping (Section 2.5) and other evolu-
tionary approaches, is iterative in nature. But unlike prototyping, the incremental
When you encounter a model focuses on the delivery of an operational product with each increment. Early
difficult deadline that increments are stripped down versions of the final product, but they do provide capa-
cannot be changed, bility that serves the user and also provide a platform for evaluation by the user.
the incremental model
is a good paradigm to Incremental development is particularly useful when staffing is unavailable for a
consider. complete implementation by the business deadline that has been established for the
project. Early increments can be implemented with fewer people. If the core product
is well received, then additional staff (if required) can be added to implement the next
increment. In addition, increments can be planned to manage technical risks. For
example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial
functionality to be delivered to end-users without inordinate delay.

2.7.2 The Spiral Model

The spiral model, originally proposed by Boehm [BOE88], 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, soft-
ware 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
6
regions. Typically, there are between three and six task regions. Figure 2.8 depicts a
spiral model that contains six task regions:
• Customer communication—tasks required to establish effective communi-
cation between developer and customer.
• Planning—tasks required to define resources, timelines, and other project-
related information.
• Risk analysis—tasks required to assess both technical and management
Framework activities risks.
apply to every
software project you • Engineering—tasks required to build one or more representations of the
undertake, regardless application.
of size or complexity.
• Construction and release—tasks required to construct, test, install, and
provide user support (e.g., documentation and training).

6 The spiral model discussed in this section is a variation on the model proposed by Boehm. For
further information on the original spiral model, see [BOE88]. More recent discussion of Boehm’s
spiral model can be found in [BOE98].