Waterfall Model

When a company develops a new computer program, it must decide in what order the work will proceed. The waterfall model is the oldest widespread answer to this question. It divides the work into fixed phases: first, what the program should be able to do is written down. Then it is planned how it will be structured internally. Only then is the actual programming done, followed by testing, and finally delivery to customers. The name comes from the image of a waterfall: the water flows from one level down to the next and never back up again.

Why companies planned for it and yet feared it

The waterfall model makes a project predictable. Because everything is written down at the start, costs and deadlines can be stated early on. Clients like this because they get a contract with clear commitments. Public authorities and industry, too, often require this kind of predictability.

The price for this is rigidity. A planning error only comes to light at the end, during testing. By then, months of work have already been done, and the correction becomes very expensive. An often-cited rule of thumb states: the later an error is discovered, the more expensive it becomes — in extreme cases by a factor of a hundred.

This is exactly what has caused many large software projects to fail. Customers only realized upon delivery that they actually wanted something different. Starting in the 1990s, agile methods emerged as a counter-model. There, small, usable pieces are built in short cycles of a few weeks, with constant requests for feedback.

The stages of the waterfall in detail

In the first phase, requirements analysis, specialists gather all the client’s wishes. The result is a document, often called a requirements specification. In the second phase, design, developers determine what building blocks the program should consist of and how they work together. Only in the third phase is actual program code written.

This is followed by the testing phase. Here it is checked whether the finished program actually does what was stated in the first document. Finally comes delivery and ongoing operation, during which errors are fixed after the fact. A characteristic feature is that each phase ends with a written result that is formally signed off.

A common misconception is that going back a step is forbidden in the waterfall model. Even the earliest descriptions allowed stepping back into the previous phase. In practice, however, such steps back are unpopular because they blow deadlines and budgets. This is why the model appears harsher than it was meant to be.

Waterfall in government agencies, cars, and AI projects

You encounter the model everywhere errors are dangerous or contracts are strict. Control units in cars, medical technology, and aircraft software are often developed in this form. Public tenders, too, frequently require a complete description in advance. In Germany, there is even a dedicated standard for this, the V-Modell XT.

In the news, the term usually appears as criticism. When a major IT project comes in years late, it is often said that work proceeded for too long according to the waterfall principle. Conversely, consulting firms advertise helping clients switch from waterfall to agile ways of working.

The model fits particularly poorly with artificial intelligence projects. Whether a model will turn out good enough is only known once it has been trained and tried out on real data. Such results cannot be written into a requirements specification in advance. This is why AI teams almost always work in short loops of trying things out, measuring, and refining. Many companies mix both approaches: the rough framework is planned according to waterfall, while the actual development runs agile.