<< Introduction | Interactive Waterfall Model >>

Different Models of Software Development

<< Introduction | Interactive Waterfall Model >>

The Waterfall Model

Making something can be thought of as a linear sequence of events. You start at A, you do B and
then go to C and eventually end up at Z. This is extremely simplistic but it does allow you to
visualise the series of events in the simplest way and it emphasises the importance of delivery with
steps being taken towards a conclusion.

Below is the "Waterfall Model" which shows typical development tasks flowing into each other.
Early in the history of software development it was adapted from engineering models to be a
blueprint for software development.

The five steps outlined are :

Analyse the requirements of the project and decide what it is supposed to do

Design a solution to meet these requirements

Implement the design into a working product

Verify the finished product against the design (and requirements)

Maintain the project as necessary

The Waterfall Model was widely adopted in the early days of software development and a lot of
blame has been laid at its door.

Critics argue that many problems in software development stem from this model. Early
development projects that followed this model ran over budget and over schedule and the blame
was attributed to the linear, step-wise nature of the model.

It is very rare that requirements analysis can be entirely completed before design and design
before development and so on. It is far more likely that each phase will have interaction with each
of the other phases.

In a small project this is not a problem since the span from "analyse" to "implement" may be a
period of weeks or even days. For a large scale project which span months or even years the gap
becomes significant. The more time that passes between analysis and implementation, the more a
gap exists between the delivered project and the requirements of end-users.

Think about a finance system which is `analysed' one year, designed the next year and developed
and implemented the following year. That's three years between the point at which the
requirements are captured and the system actually reaches its end users. In three years its likely
that the business, if not the whole industry, will have moved considerably and the requirements will
no longer be valid. The developers will be developing the wrong system! Software of this scale is
not uncommon either.

Figure 1: Waterfall Model

Requirements

Implementation

Design

Verification

Maintenance