Figure 2-2 Waterfall
While this approach has worked successfully over the
years, a number of shortcomings have become
weaknesses in this approach. First, the serial nature of
Waterfall, while easy to understand, means that the
scope of a software project is fixed at the design phase. In
construction, making changes to the first floor of a
building after you have begun the fifth floor is extremely
difficult—and may even be impossible unless you knock
down the building and start from scratch. In essence, the
Waterfall approach does not handle change well at all.
When you finally get to the coding phase of the
application development process, you might learn that
the feature you are building isn’t needed anymore or
discover a new way of accomplishing a design goal;
however, you cannot deviate from the predetermined
architecture without redoing the analysis and design.
Unfortunately, it is often more painful to start over than
to keep building. It is similar to being stuck building a
bridge over a river that no one needs anymore.
The second aspect of Waterfall that is challenging is that
value is not achieved until the end of the whole process.
We write software to automate some business function
or capability—and value is only realized when the
software is in production and producing results. With the
Waterfall approach, even if you are halfway done with a
project, you still have no usable code or value to show to
the business. Figure 2-3 shows this concept.