1

When people talk about a true “Waterfall” approach, they’re typically talking about an approach that
looks something like this.

• It typically starts by defining all of the requirements for the entire project upfront, and

• Some form of change control is typically implemented to manage and limit changes to the
requirements of the project once those requirements have been approved

The general approach is based on defining and stabilizing the requirements upfront before the
project starts to achieve a level of predictability and control over the project cost and schedule.

2
In addition, the project may be broken up into sequential phases that may have phase gates to
approve the transition from one phase to the next.
It’s called “Waterfall” because the results of the previous phase generally flow sequentially into the
next phase like a “Waterfall”.

3
There were a number of serious problems inherent in the original Waterfall process that even Dr.
Royce who originally created it in 1970 recognized.

The first big problem was that any problem in the requirements or design of the solution are many
times not discovered until final testing and the process for correcting errors found at that point
could be very long and expensive.

4
An equally serious problem is that attempting to control requirements of the project in order to
manage the scope to stay within budgeted cost and schedule estimates can create a very inflexible
approach that isn’t responsive to changes. That might work well if you’re in a highly predictable
environment with a low level of uncertainty but it doesn’t work well in environments that are much
more uncertain where it is difficult or impossible for users to fully define the requirements of what
they need in detail prior to the start of the project.

There are also very limited opportunities for customer feedback and input until final user
acceptance testing at the very end of the project. In fact, in many cases, the customer doesn’t even
see what is being designed until the design and testing are already complete and by that time it is
very difficult or impossible to make any significant changes.

The impact of these problems is that there are many software development projects that may have
met their cost and schedule goals but failed to deliver the required business value.

5
As I’ve mentioned, the Waterfall approach has some significant inherent problems associated with
it that even Dr. Royce recognized when he create it in 1970. More iterative project methodologies
that broke up the project into incremental functionality for delivery such as the Rational Unified
Process (RUP) and its variants became more widely used in the 1980’s and 1990’s. These iterative
methodologies replaced the use of the original Waterfall model in many software projects because
they solved many of the problems in the original Waterfall approach.

6
It’s ironic that iterative software development processes largely replaced the use of pure Waterfall
methodologies in the 1980’s and 1990’s and a true Waterfall approach isn’t widely used any more
in many application areas, yet people still continue to use the term “Waterfall”.

That can be very misleading because it implies that there is a single discrete approach called
“Waterfall” that is still in wide use today and that is not the case. In most cases, the term
“Waterfall” is used very loosely for any process that is not totally Agile.

7
The term “Agile” has been almost as widely misused as the term “Waterfall”. In the next
section we’re going to discuss how the definition of the word “Agile” has evolved and how
it is commonly used today.
Thanks for taking the time to do this lecture and I’ll look forward to working with you in the
rest of the course.