daniel | 
08 25th, 2008| 
The following is a digested excerpt from the book “Scaling Software Agility” by Dean Leffingwell. Read the complete chapter here. Order the book via Amazon here.
(…)
Throughout the 1980s and into the 1990s, most DoD projects were mandated to follow a waterfall cycle of development as documented in the published standard DoD STD 2167. A report on failure rates in one sample concluded that 75 percent of the projects failed or were never used [Larman2004]. Consequently, a task force was convened. Chaired by Dr. Frederick Brooks, a well-known software engineering expert, the report recommended replacing the waterfall with iterative and incremental development:
DOD STD 2167 likewise needs a radical overhaul to reflect modern best practice. Evolutionary development is best technically, it saves time and money.
Statistical evidence and several authors’ experience [Larman2004],[Boehm1988],[Tomas2001] leads to conclude that the waterfall model does not work. By looking deeper into the assumptions of the waterfall model, it is possible to understand why it fails.
ASSUMPTIONS UNDERLYING THE WATERFALL MODEL
In retrospect, it appears that we made at least four key assumptions with the model that simply turned out to be incorrect:
1. There exists a reasonably well-defined set of requirements if we only take the time to understand them.
2. During the development process, changes to requirements will be small enough that we can manage them without substantially rethinking or revising our plans.
3. System integration is an appropriate and necessary process, and we can reasonably predict how it will go based upon architecture and planning.
4. Software innovation and the research and development that is required to create a significant new software application can be done on a predictable schedule.
Let’s look at these assumptions in light of what we have learned over the last few decades of building enterprise class systems.