2.3. What About the Waterfall Lifecycle?
In a waterfall (or sequential) lifecycle process there is an attempt to define (in detail) all or most of the requirements before programming. And often, to create a thorough design (or set of smodels) before programming. Likewise, an attempt to define a "reliable" plan or schedule near the startnot that it will be.
Warning: Superimposing Waterfall on Iterative If you find yourself on an "iterative" project where most of the requirements are written before development begins, or there is an attempt to create many thorough and detailed specifications or UML models and designs before programming, know that waterfall thinking has unfortunately afflicted the project. It is not a healthy iterative or UP project, regardless of claims. |
Guideline: Don't Let Waterfall Thinking Invade an Iterative or UP Project
I need to emphasize that "waterfall thinking" often incorrectly still invades a so-called iterative or UP project. Ideas such as "let's write all the use cases before starting to program" or "let's do many detailed OO models in UML before starting to program" are examples of unhealthy waterfall thinking incorrectly super imposed on the UP. The creators of the UP cite this misunderstandingbig up-front analysis and modelingas a key reason for its failed adoption [KL01].
Why is the Waterfall so Failure-Prone?
There isn't one simple answer to why the waterfall is so failure-prone, but it is strongly related to a key false assumption underlying many failed software projectsthat the specifications are predictable and stable and can be correctly defined at the start, with low change rates. This turns out to be far from accurateand a costly misunderstanding. A study by Boehm and Papaccio showed that a typical software project experienced a 25% change in requirements [BP88]. And this trend was corroborated in another major study of thousands of software projects, with change rates that go even higher35% to 50% for large projectsas illustrated in Jones97].
Figure 2.3. Percentage of change on software projects of varying sizes.
The Need for Feedback and Adaptation
In complex, changing systems (such as most software projects) feedback and adaptation are key ingredients for success.
- Feedback from early development, programmers trying to read specifications, and client demos to refine the requirements.
- Feedback from tests and developers to refine the design or models.
- Feedback from the progress of the team tackling early features to refine the schedule and estimates.
- Feedback from the client and marketplace to re-prioritize the features to tackle in the next iteration.