Waterfall model

from Wikipedia, the free encyclopedia
Steps of the waterfall model (example)

A waterfall model is a linear (non- iterative ) process model that is used in particular for software development and that is organized in successive project phases . As with a waterfall with several cascades, the results of one level "fall" down into the next and are binding specifications there.

In a waterfall model, each phase has predefined start and end points with clearly defined results. The model usually also describes individual activities that have to be carried out to produce the results. At certain milestones and at the end of each phase, the planned development documents are adopted as part of project management .

The name waterfall comes from the often chosen graphic representation of the project phases arranged as a cascade . In operational practice, it is traditionally a widely used procedure model of which there are many variants.

Extensions of the simple model (waterfall model with return) introduce iterative aspects and allow the cascade to run upwards step by step. A deviation from the strict predecessor-successor principle is also necessary if there is a need for action in the current phase that is generally assigned to an earlier phase, e.g. B. Adjustments in the system design or in the user manual based on findings during testing.

Waterfall models are generally used to advantage where requirements, services and processes in the planning phase can be described relatively precisely.


The waterfall model originally comes from the construction and production process , highly structured processes for tasks in which late changes are prohibitively expensive or even impossible. Since no formal software development process existed when the waterfall model was first described, the processes used in construction and production were simply adapted for software development.

The first known description of the waterfall model in software development was given by Herbert D. Benington at the Symposium on advanced programming methods for digital computers on June 29, 1956 as part of a lecture on the development of software for SAGE . In 1983 the lecture was reissued, with a foreword by Benington, in which he describes that the process was not strictly worked through from top to bottom, but was based on a prototype.

The first formal description of the waterfall model is attributed to Winston W. Royce, although the latter did not use the name waterfall in his 1970 article . He described the model as could be improved and suggested the following changes:

  • Insertion of a design phase that precedes the analysis phase, in which an early simulation ( prototype ) of the final product is also implemented and documented using the same model.
  • Planning, measuring and monitoring the test to ensure that the test is doing its job.
  • Formal and ongoing involvement of the customer in the form of reviews.


  1. Requirements analysis and specification ( English Requirement analysis and specification ) results in specifications
  2. System design and specification ( English system design and specification ) results in the software architecture
  3. Programming and unit testing ( English Coding and module testing ) results in the actual software
  4. Integration and system test ( English Integration and system testing )
  5. Delivery, use and maintenance ( English delivery, deployment and maintenance )

Another variant makes six steps out of it:

  1. Planning (with creation of the specification sheet , project calculation and project plan ) ( English systems engineering )
  2. Definition (with creation of the specification sheet , product model , GUI model and possibly already user manual ) ( English analysis )
  3. Draft ( UML , structograms ) ( English design )
  4. Implementation ( English coding )
  5. Test ( English Testing )
  6. Use and maintenance ( English Maintenance )

"Definition and draft" correspond roughly to the subdivided point "System design and specification" in the first variant, while the second variant combines the two possible levels of software testing (on module and overall system level).


  1. Activities are to be carried out completely in the specified order and in full.
  2. At the end of each activity there is a completed document, i. H. the waterfall model is a "document-driven" model.
  3. The development process is sequential; d. H. each activity must be finished before the next one begins.
  4. It is based on the so-called top-down procedure.
  5. It's simple and understandable.
  6. User participation is planned in the initial phase, after which the design and implementation take place without the participation of the user or client. Further changes then represent new orders.


  • Clear demarcation of the phases
  • Easy planning and control options
  • Clear estimate of costs and scope with stable requirements

Problems and disadvantages

  • Demarcation problem: Clearly demarcated phases are often unrealistic - the transition between them is fluid: Parts of a system can still be in the planning stage while others are already being implemented or in use.
  • Sequence problem: In theory, the individual phases take place one after the other, but in practice, steps backwards are often unavoidable.
  • Inflexible to changes and in the procedure (phases have to be processed sequentially)
  • Establishing the requirements early is often problematic as it may lead to expensive changes (repeated running through the process for changes)
  • Introduction of the system very late after the start of the development cycle, therefore a later return on investment
  • By introducing the complete system at a certain point in time ( big bang ) , errors may not be recognized until late and must be removed with considerable effort.

Since it is difficult to determine everything definitively and in detail at the start of the project, there is a risk that the final result (e.g. software) will not meet the actual requirements. In order to counter this, a disproportionately high effort is often made in the analysis and conception phase. In addition, the waterfall model does not allow changes to be made in the course of the project, or only to a limited extent. The finished result therefore does not reflect the current status, but the requirement status at the start of the project. Since larger software projects usually have a very long runtime, it can happen that the content of the new software is already out of date at the time it is introduced.

Other procedural models

Because of the sometimes serious disadvantages of the waterfall model with sometimes considerable economic consequences, the IT industry has developed a variety of alternative or complementary approaches, software technologies , suggestions and tools. Examples for this are:

See also


  • Karl Pfetzing, Adolf Rohde: Holistic project management . 5th edition. Giessen 2014, ISBN 978-3-921313-90-9 .

Web links

Individual evidence

  1. ^ Herbert D. Benington: Production of Large Computer Programs . In: IEEE Educational Activities Department (Ed.): IEEE Annals of the History of Computing . tape 5 , no. 4 , October 1, 1983, p. 350–361 , doi : 10.1109 / MAHC.1983.10102 (English, usc.edu [PDF; accessed on June 13, 2013]).
  2. United States Navy Mathematical Computing Advisory Panel (Ed.): Symposium on advanced programming methods for digital computers . June 26, 1956, OCLC 10794738 (English).
  3. ^ Herbert D. Benington: Production of Large Computer Programs . In: IEEE Annals of the History of Computing . tape 5 , no. 4 . IEEE Educational Activities Department, October 1, 1983, p. 350–361 , doi : 10.1109 / MAHC.1983.10102 (English, usc.edu [PDF; accessed on June 13, 2013]).
  4. ^ Winston Royce: Managing the Development of Large Software Systems . Ed .: Proceedings, IEEE WESCON. 26th edition. Institute of Electrical and Electronics Engineers, August 1970, p. 328–338 (English, typepad.com [PDF; accessed June 13, 2013]).