Waterfall method­ol­o­gy

The waterfall model is defined as a se­quen­tial process model with which de­vel­op­ments can be mapped on the basis of suc­ces­sive phases.

The waterfall model is a linear process model that divides de­vel­op­ment processes into suc­ces­sive project phases. In contrast to iterative models, each phase is run through only once. The results of each preceding phase are used as as­sump­tions in the sub­se­quent phase. The waterfall model is used es­pe­cial­ly in software de­vel­op­ment.

The de­vel­op­ment of the classical waterfall model is at­trib­uted to the computer scientist Winston W. Royce. But Royce is not the inventor. Instead, his essay “Managing the De­vel­op­ment of Large Software Systems,” published in 1970, contains a critical ex­am­i­na­tion of linear process models. As an al­ter­na­tive, Royce presents an iterative-in­cre­men­tal 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 it­er­a­tions:

1. System re­quire­ments
2. Software re­quire­ments
3. Analysis
4. Design
5. Im­ple­men­ta­tion
6. Test
7. 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.

Ex­ten­sions of the simple waterfall model sup­ple­ment the basic model with iterative functions – for example, with rebounds that make it possible to compare the results of each phase with the as­sump­tions made in the previous phase and thus verify them.

In the waterfall model, the in­di­vid­ual phases of a de­vel­op­ment process are arranged in a cascade. Each phase concludes with an in­ter­me­di­ate result (milestone) – for example with a catalogue of re­quire­ments in the form of a re­quire­ment spec­i­fi­ca­tion, with the spec­i­fi­ca­tion of a software ar­chi­tec­ture or with an ap­pli­ca­tion in the alpha or beta stage.

Every software project begins with an analysis phase that includes a fea­si­bil­i­ty study and a re­quire­ments de­f­i­n­i­tion. In the fea­si­bil­i­ty study, the software project is assessed in terms of costs, revenue, and fea­si­bil­i­ty. The fea­si­bil­i­ty study provides a re­quire­ment spec­i­fi­ca­tion (a rough de­scrip­tion of the re­quire­ments), a project plan and the project cal­cu­la­tion, as well as an offer for the client, if ap­plic­a­ble.

This is followed by a detailed de­f­i­n­i­tion of the re­quire­ments, 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 prop­er­ties the software product must offer in order to meet the re­quire­ments. The results of the re­quire­ments’ de­f­i­n­i­tion include, for example, a re­quire­ment spec­i­fi­ca­tion, a detailed de­scrip­tion of how the project re­quire­ments are to be met, and a plan for ac­cep­tance testing.

Finally, the first phase of the waterfall model provides for an analysis of the re­quire­ments’ de­f­i­n­i­tion, in which complex problems are broken down into small subtasks and ap­pro­pri­ate solution strate­gies are developed.

The design phase serves to develop a concrete solution concept based on the pre­vi­ous­ly de­ter­mined re­quire­ments, tasks, and strate­gies. In this phase, software de­vel­op­ers develop the software ar­chi­tec­ture and a detailed con­struc­tion plan for the software, con­cen­trat­ing on specific com­po­nents such as in­ter­faces, frame­works, or libraries. The result of the design phase comprises a draft document with a software con­struc­tion plan and test plans for in­di­vid­ual com­po­nents.

The software ar­chi­tec­ture designed in the design phase is im­ple­ment­ed in the im­ple­men­ta­tion phase, which includes software pro­gram­ming, trou­bleshoot­ing, and module testing. In the im­ple­men­ta­tion phase, the software design is im­ple­ment­ed in the desired pro­gram­ming language. In­di­vid­ual com­po­nents are developed sep­a­rate­ly, checked within the framework of module testing, and in­te­grat­ed step by step into the overall product. The result of the im­ple­men­ta­tion phase is a software product that is tested for the first time as a complete product in the sub­se­quent phase (alpha test).

The test phase includes the in­te­gra­tion of the software into the desired target en­vi­ron­ment. As a rule, software products are initially delivered as beta versions to selected end users (beta tests). The ac­cep­tance tests developed in the analysis phase can be used to determine whether the software meets the pre­vi­ous­ly-defined re­quire­ments. A software product that has suc­cess­ful­ly completed beta testing is ready for release.

After suc­cess­ful com­ple­tion of the test phase, the software is released for pro­duc­tive use. The final phase of the waterfall model includes delivery, main­te­nance, and im­prove­ment of the software.

The waterfall model offers a clear or­ga­ni­za­tion­al structure for de­vel­op­ment projects, in which the in­di­vid­ual project phases are clearly separated from each other. Since each phase concludes with a milestone, the de­vel­op­ment process is easy to follow. The model focuses on the doc­u­men­ta­tion of the process steps. The knowledge acquired is recorded in re­quire­ment or draft documents.

In theory, the waterfall model should create the pre­req­ui­sites for a fast and cost-effective im­ple­men­ta­tion of projects through careful planning in advance. The benefit of the waterfall model for practical use, however, is con­tro­ver­sial. On the one hand, project phases in software de­vel­op­ment are rarely clearly defined. Es­pe­cial­ly in complex software projects, de­vel­op­ers are often con­front­ed with the fact that the different com­po­nents of an ap­pli­ca­tion are in different de­vel­op­ment phases at the same time. On the other hand, the linear sequence of the waterfall model often does not cor­re­spond to the real con­di­tions.

Strictly speaking, no ad­just­ments are planned for the waterfall model in the course of the project. However, a software project in which all details of the de­vel­op­ment are already defined at the beginning of the project can only be suc­cess­ful­ly completed if a lot of time and costs are invested in analysis and con­cep­tion at the beginning. In addition, large software projects sometimes extend over several years and without regular adap­ta­tion to current de­vel­op­ments, producing results that are outdated at the time of im­ple­men­ta­tion.

Waterfall models are used above all for projects where re­quire­ments and processes can be precisely described as early as the planning phase and where it can be assumed that the as­sump­tions will change only slightly during the course of the project. Strictly linear process models are therefore primarily suitable for small, simple, and clearly-struc­tured software projects. Royce came to this con­clu­sion in the 1970s. His proposed an al­ter­na­tive to the linear process model, which would later become known as the waterfall model, and included three major en­hance­ments:

According to Royce, the results of each phase of a project should be im­me­di­ate­ly compared and verified with the pre­vi­ous­ly prepared documents – for example, after the de­vel­op­ment of a module, it should be ensured that it meets the pre­vi­ous­ly defined re­quire­ments and not just at the end of the de­vel­op­ment process.

According to Royce, the waterfall model should be run at least twice: first for the de­vel­op­ment of a prototype and then for the de­vel­op­ment of the actual software product.

As the third extension of the waterfall model, Royce called in his essay for a measure that is now standard practice in product de­vel­op­ment: the in­volve­ment of the end user in the pro­duc­tion process. Royce suggests involving the user in the software de­vel­op­ment process at three points: During software planning in the analysis phase, between software design and im­ple­men­ta­tion, and in the test phase before software release.

Due to the strictly linear sequence of the se­quen­tial­ly suc­ces­sive 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 al­ter­na­tive ap­proach­es have been developed.

While models such as the spiral model or the V-model are regarded as further de­vel­op­ments of the classic waterfall model, concepts such as extreme pro­gram­ming, agile software de­vel­op­ment, or iterative pro­to­typ­ing follow a com­plete­ly different approach and usually allow more flexible adap­ta­tion to current changes and new re­quire­ments.