Waterfall Model

This section presents the approach of the Waterfall Model. It describes how it deals with requirements. The Waterfall Model is in stark contrast to agile methods.

Wasserfall-1-02-E.jpg

Diagram 3: Waterfall Model

Diagram 3 shows the Waterfall Model. It is a linear process model in software development, whereby the software development process is organized into individually fixed phases and the phase results are always considered to be binding standards for the next phase. Each phase must be completely concluded in order to begin the next. Each phase also produces a detailed document or program.

Wasserfall-2-E-01.jpg

Diagram 4: Waterfall Model according to Royce

 

In the basic model, a return to a previous phase is not possible. Diagram 4 shows the advanced Waterfall Model according to Royce – returns are allowed here. In doing so however, all of the work from the current phase must be discarded in most cases.

The Waterfall Model represents the course of a real, physical project, e.g. building a house. Initially, the foundations are laid, following which the walls are built and finally the roof is put in place. It is clear with this example: The later an incorrect specification is identified, the more difficult and expensive the correction becomes. Should false assumptions or ambiguities become apparent in the later stages during the analysis phase, a project break-off is often the only option in order to limit the damage. This is particularly problematic in larger developments since a complete iteration of the model in these instances can take several years. At the latest, on completion of the design phase, it is virtually impossible to respond to changed requirements.

In terms of the flexibility of the requirements, the Waterfall Model can be categorized as follows:

  • The individual phases must be clearly defined and may only be processed sequentially one after the other.
  • Due to the very limited possibility to change the results of phases already completed afterwards, little flexibility with regard to changed requirements is possible. This is especially problematic in long-term projects with the changes in requirements and framework conditions.
  • The model is “document driven” and places great emphasis on the documentation of the processes and results. This can require considerable effort.

Conclusion on the use of the Waterfall Model

The Waterfall Model is generally suitable for projects where requirements, performance and processes can be described relatively accurately in the planning phase and also need few changes in the course of development. If the requirements change in one of the later stages, one either obtains a product that does not meet those requirements or the entire development must be abandoned and started again from scratch.

This is contrary to modern developments in IT and enterprises in general, where flexible reactions to rapidly changing events are often crucial and essential for survival.

As far back as 1970, Winston Royce explicitly described his Waterfall Model as only being suitable for simple projects.

Source: Winston Royce, Managing the development of large software systems, Proceedings of IEEE Westcon, 1970