UNIT 3 – Incremental Models

As discussed above, the major drawbacks of the waterfall model are due to
the fact that the entire product is developed and delivered to the client in
one package. This results in delayed feedback from the client. Because of
the long elapsed time, a huge new investment of time and money may be
required to fix any errors of omission or commission or to accommodate
any new requirements cropping up during this period.

In the incremental models, as opposed to the waterfall model, the product is

partitioned into smaller pieces which are then built and delivered to the client in
increments at regular intervals. Since each piece is much smaller than the whole,
it can be built and sent to the client quickly. This results in quick feedback from
the client and any requirement related errors or changes can be incorporated at a
much lesser cost. It is therefore less traumatic as compared to the waterfall
model. It also required smaller capital outlay and yield a
rapid return on investment. However, this model needs and open architecture to
allow integration of subsequent builds to yield the bigger product. A number of
variations are used in object-oriented life cycle models.

There are two fundamental approaches to the incremental development. In the

first case, the requirements, specifications, and architectural design for the whole
product are completed before implementation of the various builds commences.

In a more risky version, once the user requirements have been elicited, the
specifications of the first build are drawn up. When this has been completed, the
specification team

turns to the specification of the second build while the design team designs the
first build. Thus the various builds are constructed in parallel, with each team
making use of the information gained in the all the previous builds. This approach
incurs the risk that the resulting build will not fit together and hence requires
careful monitoring.
Rapid Application Development (RAD)
Rapid application development is another form of incremental model. It is a high
speed adaptation of the linear sequential model in which fully functional system
in a very short time (2-3 months). This model is only applicable in the projects
where requirements are well understood and project scope is constrained.
Because of this reason it is used primarily for information systems.

Synchronize and Stabilize Model

This is yet another form of incremental model adopted by Microsoft. In this
model, during the requirements analysis interviews of potential customers are
conducted and requirements document is developed. Once these requirements
have been captured, specifications are drawn up. The project is then divided into
3 or 4 builds. Each build is carried out by small teams working in parallel. At the
end of each day the code is synchronized (test and debug) and at the end of the
build it is stabilized by freezing the build and removing any remaining defects.
Because of the synchronizations, components always work together. The
presence of an executable provides early insights into operation of product.

Spiral Model
This model was developed by Barry Boehm. The main idea of this model is to
avert risk as there is always an element of risk in development of software. For
example, key personnel may resign at a critical juncture, the manufacturer of the
software development may go bankrupt, etc.
In its simplified form, the Spiral Model is Waterfall model plus risk analysis. In this
case each stage is preceded by identification of alternatives and risk analysis
and is then followed by evaluation and planning for the next phase. If risks
cannot be resolved, project is immediately terminated. This is depicted in the
following diagram.
As can be seen, a Spiral Model has two dimensions. Radial dimension
represents the cumulative cost to date and the angular dimension represents the
progress through the spiral. Each phase begins by determining objectives of that
phase and at each phase a new process model may be followed.

A full version of the Spiral Model is shown below:

The main strength of the Spiral Model comes from the fact that it is very sensitive
to the risk. Because of the spiral nature of development it is easy to judge how
much to test and there is no distinction between development and maintenance.
It however can only be used for large-scale software development and that too
for internal (in-house) software only.