The specifics differ from one formulation to another, but generally speaking the process looks something like this:
As shown in the diagram above, the software process is broken into distinct stages, usually including:
It’s likely that the Waterfall-Style methodologies were inspired by the construction industry, wherein we try to Design Up Front in order to avoid the cost of re-work: once concrete is poured, it’s expensive to change it again, compared to the cost of updating the design in a diagram.
Also, when Waterfall was originally conceived, automated testing techniques were not well established. If you expect to perform a large manual testing cycle for each release, then clearly, doing fewer releases looks cheaper on paper.
But, while in principle, Waterfall aims to contain the cost of implementation. However, in practice, because of Requirements Drift, Student Syndrome and Complexity Risk, the schedules get more inaccurate the larger the project.
In any construction project, there are likely to be lots of stakeholders - landowners, neighbours, government, clients and so on.
Waterfall tries to mitigate this risk by getting Sign-Offs as it goes along.
Additionally, by putting in the work at the planning and design stage, hopefully this means lots of staff can work together and not interfere with each other when the time for construction comes.
Because of its step-wise delivery and reduction in visibility risk, Waterfall documentation can be used as the basis for contracted delivery, and this is useful in situations where you are employing 3rd parties or putting work to tender.
Where projects can get tied up in lots of red tape, a Waterfall process can supply enough gravitas in the form of documentation and ceremony in order to appease bureaucracy, in a way that Lean or Agile methods do not.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.