The "Waterfall" Process
The waterfall process is essentially a linear process as shown in Figure
Figure 1: The Waterfall Life Span (Royce 1998)
To explain this phenomenon we can hardly do better than to quote Murray Cantor
Software development may seem to have a lot in common with construction
or engineering projects, such as building a bridge. A set of activities must be
carried out in what seems to be a natural order: requirements gathering, design,
building, testing, and finally putting the bridge into general service. From then
on, the bridge goes into operation and maintenance. For software, the usual activities
are recast as requirements analysis, architecture, design, code and unit test,
integration, and system test.
Tasks are serialized in construction projects. For example, you cannot lay
the foundation for a building until the excavation is completed and approved.
The flooring task must not begin until the joists are inspected and signed off.
Early approaches to software development tried to follow the same discipline.
- The analysis team captured and documented the requirements.
- When the requirements were approved, the design started.
- When the design was approved, coding began.
- Each line of code was inspected. If it was approved, it was allowed to be
integrated into the product.
This is the dreaded waterfall process. It was once touted as a way to make
software development cost-effective. The thought was that if coding began before
the design was approved, some coding effort would probably be wasted. In practice,
... the construction mentality inherent in the waterfall process has led
to some spectacular software development failures.
The first problem with this approach is that the software development tasks
are not as easily planned and assessed as those of a construction project. It
is simple to know what it means to be half done with painting a bridge. It is
difficult to know when you are half done with writing code. The amount of time
it takes to paint each part of a bridge is easy to estimate, but no one really
knows how large the final code will be, and no one knows exactly how long it will
take to write and debug any particular piece of code.
A second problem is caused by the serialization of the activities: completing
one activity before starting the next. To complete an activity implies that the
outcome is perfect and that the staff assigned to the activity can move on to
the next project [but] you cannot be sure whether, say, the requirements document
is finished. In fact, experience has shown that you can be sure it is not finished.
Over the life of the project, shortfalls in the requirements document will be
discovered [or in the requirements or design specifications.] ... Each time the
documents are reviewed, new problems arise, doubts are raised, gaps discovered,
and questions are asked that cannot be answered. Management is disciplined, insisting
on quality and holding to standards. They want flawless documents that describe
inhumanly complex systems. Their expectations cannot be met and, in the end, a
lot of money is spent with no useful results. There is plenty of blame to go around.
- The waterfall approach has been around for a long time, and many people are
familiar and comfortable with it.
- It is simple and easily understood.
- It does recognize the need to move one stage at a time and recycle back to
the previous stage to validate the stage outcome
Not so good features
- The waterfall approach does not satisfy the requirement for executive control
that we described in our introduction.
- It is very difficult to manage under conditions of complexity.
- In the waterfall approach, integration and testing is generally left until
the end. That's when "all the chickens come home to roost", with disastrous
effect on project schedule and cost.
As Shelley Doll puts it:
- "Another potential danger is that you won't know if the solution is successful
until very close to launch, leaving little time and room for correction. Oversights
and flawed design work can seriously affect your launch date.
- "Other criticisms of this model include the fact that there's no room
for feedback anywhere in the process, except at the end of a phase.
- "Also, there's no room for changes once development has begun.
- "Finally, if system testing shows that capacity or performance isn't
up to snuff, it may be impossible to correct."
In short, the waterfall approach may be fine for smaller projects but not for
projects of any size requiring effective executive control.
6. Murray Cantor, Software
Leadership: A Guide to Successful Software Development, Addison-Wesley, NY, 2002,
Appendix A.2, p153
7. Shelley Doll, Waterfall for new managers http://builder.com.com/ July 24, 2002