Waterfall methodology
IONOS editorial team9 mins
The waterfall model is defined as a sequential process model with which developments can be mapped on the basis of successive phases.
- Free website protection with SSL Wildcard included
- Free private registration for greater privacy
- Free 2 GB email account
What is the waterfall method?
The waterfall model is a linear process model that divides development processes into successive project phases. In contrast to iterative models, each phase is run through only once. The results of each preceding phase are used as assumptions in the subsequent phase. The waterfall model is used especially in software development.
How does the waterfall method work?
The development of the classical waterfall model is attributed to the computer scientist Winston W. Royce. But Royce is not the inventor. Instead, his essay “Managing the Development of Large Software Systems,” published in 1970, contains a critical examination of linear process models. As an alternative, Royce presents an iterative-incremental model in which each phase reverts to the previous phase and verifies its results.
Royce proposes a model with seven phases, which is run through in several iterations:
- System requirements
- Software requirements
- Analysis
- Design
- Implementation
- Test
- Operation
The procedure model known as the waterfall model is based on the phases defined by Royce – but the term itself has come about since then. In the essay written by Royce, the term “waterfall” does not even appear.
The waterfall model became widely known through the US standard DoD-STD-2167, which is based on a simplified form of the procedure model developed by Royce, which was not sufficiently understood by the authors. The reason for this was the lack of understanding of iterative-incremental models, as David Maibor – one of the authors – later admitted.
In practice, different versions of the waterfall model are used. Models that divide development processes into five phases are common. The phases 1, 2, and 3 defined by Royce are sometimes combined in a project phase as a requirements analysis.
- 1st analysis: planning, requirements analysis, and specification
- Design: system design and specification
- Implementation: programming and module tests
- System integration: system and integration tests
- Operation: delivery, maintenance, improvement
The following figure illustrates why the linear process model is referred to as the "waterfall model."
Extensions of the simple waterfall model supplement the basic model with iterative functions – for example, with rebounds that make it possible to compare the results of each phase with the assumptions made in the previous phase and thus verify them.
What are the phases of the waterfall model?
In the waterfall model, the individual phases of a development process are arranged in a cascade. Each phase concludes with an intermediate result (milestone) – for example with a catalogue of requirements in the form of a requirement specification, with the specification of a software architecture or with an application in the alpha or beta stage.
Analysis
Every software project begins with an analysis phase that includes a feasibility study and a requirements definition. In the feasibility study, the software project is assessed in terms of costs, revenue, and feasibility. The feasibility study provides a requirement specification (a rough description of the requirements), a project plan and the project calculation, as well as an offer for the client, if applicable.
This is followed by a detailed definition of the requirements, which includes an analysis of the current situation and a target concept. While as-is analyses outline the problem area, the target concept defines which functions and properties the software product must offer in order to meet the requirements. The results of the requirements’ definition include, for example, a requirement specification, a detailed description of how the project requirements are to be met, and a plan for acceptance testing.
Finally, the first phase of the waterfall model provides for an analysis of the requirements’ definition, in which complex problems are broken down into small subtasks and appropriate solution strategies are developed.
Design
The design phase serves to develop a concrete solution concept based on the previously determined requirements, tasks, and strategies. In this phase, software developers develop the software architecture and a detailed construction plan for the software, concentrating on specific components such as interfaces, frameworks, or libraries. The result of the design phase comprises a draft document with a software construction plan and test plans for individual components.
Implementation
The software architecture designed in the design phase is implemented in the implementation phase, which includes software programming, troubleshooting, and module testing. In the implementation phase, the software design is implemented in the desired programming language. Individual components are developed separately, checked within the framework of module testing, and integrated step by step into the overall product. The result of the implementation phase is a software product that is tested for the first time as a complete product in the subsequent phase (alpha test).
Testing
The test phase includes the integration of the software into the desired target environment. As a rule, software products are initially delivered as beta versions to selected end users (beta tests). The acceptance tests developed in the analysis phase can be used to determine whether the software meets the previously-defined requirements. A software product that has successfully completed beta testing is ready for release.
Maintenance
After successful completion of the test phase, the software is released for productive use. The final phase of the waterfall model includes delivery, maintenance, and improvement of the software.
Evaluation of the waterfall model
The waterfall model offers a clear organisational structure for development projects, in which the individual project phases are clearly separated from each other. Since each phase concludes with a milestone, the development process is easy to follow. The model focuses on the documentation of the process steps. The knowledge acquired is recorded in requirement or draft documents.
In theory, the waterfall model should create the prerequisites for a fast and cost-effective implementation of projects through careful planning in advance. The benefit of the waterfall model for practical use, however, is controversial. On the one hand, project phases in software development are rarely clearly defined. Especially in complex software projects, developers are often confronted with the fact that the different components of an application are in different development phases at the same time. On the other hand, the linear sequence of the waterfall model often does not correspond to the real conditions.
Strictly speaking, no adjustments are planned for the waterfall model in the course of the project. However, a software project in which all details of the development are already defined at the beginning of the project can only be successfully completed if a lot of time and costs are invested in analysis and conception at the beginning. In addition, large software projects sometimes extend over several years and without regular adaptation to current developments, producing results that are outdated at the time of implementation.
Pros and cons of the waterfall methodology
| Pros | Cons |
|---|---|
| Simple structure through clearly defined project phases | Complex or multi-shift projects can rarely be divided into clearly defined project phases |
| Good documentation of the development process thanks to clearly defined milestones | Little scope for adjustments to the project process due to changing requirements |
| Costs and workload can be estimated at the start of the project | Final user is only integrated into the production process after programming |
| Projects structured according to the waterfall model can be easily mapped on the time axis | Errors are sometimes only recognized at the end of the development process |
Waterfall models are used above all for projects where requirements and processes can be precisely described as early as the planning phase and where it can be assumed that the assumptions will change only slightly during the course of the project. Strictly linear process models are therefore primarily suitable for small, simple, and clearly-structured software projects. Royce came to this conclusion in the 1970s. His proposed an alternative to the linear process model, which would later become known as the waterfall model, and included three major enhancements:
Verification after each project phase
According to Royce, the results of each phase of a project should be immediately compared and verified with the previously prepared documents – for example, after the development of a module, it should be ensured that it meets the previously defined requirements and not just at the end of the development process.
At least two iterations
According to Royce, the waterfall model should be run at least twice: first for the development of a prototype and then for the development of the actual software product.
Tests involving the end user
As the third extension of the waterfall model, Royce called in his essay for a measure that is now standard practice in product development: the involvement of the end user in the production process. Royce suggests involving the user in the software development process at three points: During software planning in the analysis phase, between software design and implementation, and in the test phase before software release.
Alternatives to the waterfall methodology
Due to the strictly linear sequence of the sequentially successive project phases, the waterfall model is suitable – if at all – only for small software projects. Complex, multi-layered processes, on the other hand, cannot be mapped. Over time, various alternative approaches have been developed.
While models such as the spiral model or the V-model are regarded as further developments of the classic waterfall model, concepts such as extreme programming, agile software development, or iterative prototyping follow a completely different approach and usually allow more flexible adaptation to current changes and new requirements.
