Introduction to Waterfall Process Model

Overview

In the 1970s, Winston Royce (director of Lockheed’s Software Technology Center) was the first to describe the Waterfall process model in his whitepaper, “Managing the development of large software systemsDr.Winston W. Royce(1970). Managing the development of large software systems. IEEE WESCON.” Although this paper is seen as the first Waterfall methodology, Royce himself was not a supporter of the model. On the contrary, Royce used the Waterfall process model as an example of a process that didn’t work properly.

The characteristics of the Waterfall model

The Waterfall model is a sequential process in which all activities toward building the software are carried out one after the other.

Royce sees these activities as the minimum necessity to successfully implement and maintain a software. Even today, many organizations are hierarchically organized according to this model. For example, there is a department for requirements or business analysis, a department for information analysis, and one for functional and technical design. Then, there are developers and testers. There’s a department with functional and technical maintenance staff. And of course, there are project managers who keep the other roles in check.

Even though Royce doesn’t use the term, the Waterfall model is derived directly from this picture from 1970. The Waterfall model is characterized as follows:

• Phases: Each project consists of phases as depicted in this illustration. Once: Each phase is performed once and in a fixed sequence.
• Roles: Each phase has its own specific role. Analysts analyze, developers develop, and testers test.
• Deliverables: At the end of each phase, a final product is completed. It’s signed, sealed, and delivered. These are the so-called milestones. Consider information analysis or functional design, for example.
• Fully: The next phase only starts when the product from the previous phase is fully completed. Software development doesn’t start until the design is completed. Only once the software is fully developed does testing start.
• Fixed: Projects are usually performed with a fixed budget, date, and scope.

The problem with the Waterfall

Since 1970, most projects have been carried out according to (variations on) the Waterfall model. Most are unsuccessful. Almost everyone is familiar with working on projects that went far over budget, didn’t meet the agreed deadlines, implemented only part of the agreed requirements, or ended prematurely, possibly after several restarts.

Considering the characteristics of these traditional projects, we can see very clear reasons for this. Let’s explore the most common ones.

• The disappearance of knowledge: Each phase is carried out by a specific role. Once a phase’s final product is completed, the role is removed from the project. A lot of knowledge is lost after each phase of the project in this way. After all, it’s impossible to document everything.

• Progressive insight: During each phase of a project, the team learns more about the scope of the project, user needs, and the (im)possibilities of the chosen technology. This is called progressive insight. However, because the end products of earlier phases are fixed, this insight can no longer be taken into account.

• Changing requirements: On average, 20 to 25 percent of a project’s requirements change while it’s underway. New requirements are found and existing requirements change or become obsolete. Because all requirements were already detailed at an earlier phase, however, a portion of this work becomes redundant or needs to be performed again. This is inefficient and expensive.

• Complete and thorough: Because the end product of an earlier phase can’t change, it’s important to complete each phase, especially during analysis and design. If new requirements are discovered during the next phase, they’re treated as imperfections of previous phases.

Due to this, analysts and designers in particular find that it’s difficult to deliver their final end products. Early phases of the project are often seriously delayed as a result.

• Too much documentation: Though documentation is important for thoroughness, too much can make it impossible to ever build the software, let alone test it.

• **Difficulty estimating: ** Each phase contains a different type of work and thus has its own pace. As a result, it’s difficult to give good estimates. If the analysis takes six months, what does this say about the project’s total duration?

• Late risks: In Waterfall, the software is actually developed in a late phase of the project. Several years can sometimes pass before the first code is written. This brings great risks with it. The proposed technology could be outdated. Software testing often only starts after the code is fully completed. No matter how great the analysts, designers, and developers are, testers will always find imperfections.

With the passing of a project’s phases, more and more work has been performed. The cost of resolving errors in a project grows exponentially. This is known as the Law of Boehm.