Waterfall

First structured approach to software development Introduced the concepts of phases, tasks, roles, and deliverables

The waterfall approach to software development is so named because it has distinct phases that are meant to be done in order, and high-level project objectives and requirements “fall” through from one phase to the next. The waterfall methodologies also introduced the concepts of team roles, deliverables, and sign-offs. The roles of team leader, programmer, and user were the first specified. Deliverables or software design documentation was introduced as a method of getting user agreement on work before the work was done. Sign-offs were introduced to get user “buy-in” to the work.

All other software development methodologies are based on the waterfall. Most of the concepts of the waterfall are still important and are included in subsequent methodologies. Figure 5.1 shows the classic waterfall approach.

Figure 5.1: Waterfall Approach to Software Development

In the waterfall approach, each activity or phase is dealt with once and completed for the entire system before the next phase is started (e.g., all analysis activities are completed before the design phase is started). This structured, sequential approach is the one aspect of the waterfall approach that limited its success. Teams often spent too much of the project time in early phases and then had to rush through the rest of the process. It is unfortunate that the waterfall approach has suffered from negative publicity because the tasks and deliverables recommended by the approach are necessary and useful. The fundamental idea behind the waterfall approach—analyzing before designing and designing before coding—is still the most effective route to success (Royce, 1998).

Methodologies that were built around the waterfall approach acknowledge the importance of first planning the work, gathering/understanding requirements, and laying out a software design plan before starting to write code. Early developers did all of this work themselves. Prior to the concept of a software development life cycle or methodology, developers spoke with subject matter experts briefly and then began coding. This approach is often still used on maintenance projects. As projects became more complex, software became more complex. Coding without an overall design plan was problematic, like trying to build a house without a blueprint.

Planning Phase

The planning phase is intended to help the IT team ask high-level questions of the executive sponsor to determine the true project objectives. This was the first formalization of setting customer expectations for the IT work that would be done. It is also intended to help IT people understand business needs and priorities.

Analysis Phase

Definition of the analysis phase was really the beginning of business analysis work. The waterfall approach recommended that software requirements be written down and reviewed. This was a radical idea in the 1970s, when most developers only wrote code. This phase was created because developers had been creating software that didn’t really perform functions the way that subject matter experts needed. Initial requirements were very brief and were all functional—they described what the software should do.