The Waterfall Methodology

The waterfall model originated in 1970 largely through the efforts of Dr. Winston Royce who developed this model as an aid to software development. It worked well at the time and has undergone many subsequent changes and revisions. From 1974 to 1976, Dr. Barry Boehm, a knowledgeable expert in his field, further developed the waterfall model into other project phases to better reflect current development best practices. The methodology, currently one of the most widely used, gets its name from the analogy of water falling downward.

The waterfall model is a diagrammatical representation depicting the main phases of software development (see Figure 4.7). The first phase and its associated action are shown at the top left-hand corner of the diagram, and all subsequent project phases are placed toward the bottom right of the diagram. Each phase is called a work product . At the end of each phase, the result is either documents or deliverables, which in turn are used to proceed to the next phase.






Thiaq t on

Figure 4.7: Waterfall development methodology.

Note that the model in Figure 4.7 does not adequately allow for fixing any defects. It also does not address how to revisit previous project phases and go up the waterfall again when defects need to be corrected. This poses problems for some design and development groups. Although a great methodology, the waterfall model is difficult to use because it is incomplete in its original framework and structure. Revisions to the waterfall methodology have been made to accommodate project feedback, such as testing and quality assurance. However, the most commonly used version available today includes a corrective feedback mechanism. Figure 4.7 shows a remarkable difference between the two models. Some of the phases that should be used in the waterfall methodology follow:

Requirements analysis.


Code and unit testing.

Subsequent testing.

System testing.

There are three main types of waterfall methodologies to consider when assigned a project. These three waterfall approaches depend entirely on a project's target date. These categories are:

No overlap. This is a purely sequential waterfall methodology where no phases overlap. Phases are completed before another phase starts. Usually, deliverables such as phase sign-offs and reviews are indicators of such a methodology.

One phase overlap. Adjacent phases are allowed to overlap by one phase only. This kind of overlapping often happens on a waterfall project.

Overlapping phases. Extensive overlap is present, with each phase overlapping the other. It does prove substantially more difficult to coordinate the deliverables and tasks and requires a competent project manager with the appropriate experience to undertake such an approach. If you run into trouble here, it is difficult to get back on track and requires rescheduling.

The disadvantage of the waterfall methodology in general is that it can be largely documentation-driven, which consumes time. The waterfall methodology makes it easier on the project manager and difficult on the client. For example, in a typical construction project, the specifications are usually detailed and take considerable time to complete. The first time a client actually sees the finished product is when the product has been built. (However, in construction, CAD software can simulate large projects.) Thus, if the client has changes, it is either usually too late or the changes are too complex.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment