The “Waterfall model” for software development is a relatively linear sequential approach for developing software. The idea is that progress flows in largely one direction ("downwards" like a waterfall) through individual phases from conception through later steps (such as analysis, design, and construction). There may be some feedback, but the waterfall model assumes that feedback from any one step is limited and mostly back to only the previous step.
The waterfall model traces back primarily to Winston Royce’s 1970 paper, "Managing the Development of Large Software Systems". Royce didn’t call it the “waterfall” – he called it the “simpler method”. But what Royce described early in his paper is clearly the waterfall model - work progresses in a single sequence of steps, possibly with some iteration between adjacent steps.
However, many people did not read Royce's paper, even if they cited it. Royce describes the simple (waterfall) approach, but then explains that the waterfall model is “risky and invites failure” and that “in my experience, the simpler method has never worked on large software development efforts”. Indeed, he emphasizes that various changes to the waterfall model must be applied, such as using iteration, to have a reasonable chance of success in a larger project. The bottom line is that Royce recommended against using the simple waterfall model, even though later authors referred to his paper when arguing for using it.
I should add that in my own experience, Royce is right saying that the waterfall model is a risky approach to software development. In the vast majority of cases I strongly recommend against a waterfall. A waterfall model can work well in small projects where everything is completely known ahead-of-time and the requirements never change, but such projects are rare. The waterfall model looks simpler and more rigorous on paper, and those are two reasons why people keep trying to use it. But many people have failed when they try to apply it, or at least found it to be especially costly. In practice, some sort of incremental or iterative approach is usually much less risky.
Unfortunately, many people just looked at the easiest-to-read pretty figures in the paper, and didn't notice the text that explained why the waterfall model was risky. The text and some of the key figures are right next to each other, on the same page! But people still ignored the warnings. Since many people just looked at the earlier figures, and skipped the more complicated later figures, they totally misunderstood Royce's paper. This is discussed further in “Don't draw diagrams of wrong practices – or: Why people still believe in the Waterfall model” by Tarmo Toikkanen (2005-09-09).
Once the pictures became widespread, they became fossilized in various organizations and standards. For example, the US Department of Defense (DoD) developed the standards DOD-STD-2167 (4 June 1985), later revised to DOD-STD-2167A (29 Feb 1988), aka "Defense System[s] Software Development". Technically you could iterate in 2167A, but a variety of factors made that difficult in practice. Those standards are officially no longer required, but the practices remain. The Final Report of the Defense Science Board (DSB) Task Force on the"Design and Acquisition of Software for Defense Systems" (February 14, 2018) explains that the DoD "still largely buys and develops software developed using the slower traditional Waterfall approach that was mostly abandoned by commercial companies years ago." Once something becomes entrenched, it is hard to change.
There are several lessons to be learned here:
In short, beware of using the waterfall model, and try to learn from past fads to protect yourself from the current fads.
Feel free to see my home page at https://dwheeler.com. You may also want to look at my paper Why OSS/FS? Look at the Numbers! and my book on how to develop secure programs.
(C) Copyright 2018 David A. Wheeler. Released under Creative Commons Attribution-ShareAlike version 3.0 or later (CC-BY-SA-3.0+).