Waterfall Methodology

Waterfall Methodology

What Is Waterfall?

Waterfall methodology follows a sequential, linear process and is the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects. It is sometimes planned using a Gantt chart, a type of bar chart that shows the start and end dates for each task. Once one of the eight stages are complete, the development team moves onto the next step. The team can’t go back to a previous stage without starting the whole process from the beginning. And, before the team can move to the next stage, requirements may need to be reviewed and approved by the customer.

The Waterfall model originated in the manufacturing and construction industries, both highly structured environment where changes can be too expensive or sometimes impossible. The first formal description of Waterfall is attributed to Winston W. Royce in a 1970 article where he described a flawed software model.

Advantages of Waterfall

Waterfall is best used for simple, unchanging projects. Its linear, rigid nature makes it easy to use and allows for in-depth documentation.

The advantages of Waterfall include:

• Easy to use and manage: Because the Waterfall model follows the same sequential pattern for each project, it is easy to use and understand. The team doesn’t need any prior knowledge or training before working on a Waterfall project. Waterfall is also a rigid model; each phase has specific deliverables and review, so it’s easy to manage and control.
• Discipline is enforced: Every phase in Waterfall has a start and end point, and it’s easy to share progress with stakeholders and customers. By focusing on requirements and design before writing code, the team can reduce the risk of a missed deadline.
• Requires a well documented approach: Waterfall requires documentation for every phase, resulting in better understanding of the logic behind the code and tests. It also leaves a paper trail for any future projects or if stakeholders need to see more detail about a certain phase.

Disadvantages of Waterfall

The biggest drawback of Waterfall is how it handles change. Because Waterfall is a linear, sequential model, you can’t bounce between phases, even if unexpected changes occur. Once you’re done with a phase, that’s it.

Here’s more information on the disadvantages of Waterfall:

• Changes can’t be easily accommodated: Once the team completes a phase, they can’t go back. If they reach the testing phase and realize that a feature was missing from the requirements phase, it is very difficult and expensive to go back and fix it.
• Software isn’t delivered until late: The project has to complete two to four phases before the coding actually begins. As a result, stakeholders won’t see working software until late in the life cycle.
• Gathering accurate requirements can be challenging: One of the first phases in a Waterfall project is to talk to customers and stakeholders and identify their requirements. However, it can be difficult to pinpoint exactly what they want this early in the project. Often times, customers don’t know what they want early on and instead, learn and identify requirements as the project progresses.

Stages of Waterfall

There are eight stages in Waterfall and they must all happen in sequential order. For example, the development team can’t go back to the analysis phase if they are in the testing phase.

• Conception: This phase starts with an idea. The concept phase involves a rough assessment of the project, why it’s beneficial, and looks at any initial cost estimates.
• Initiation: Once the idea is formed, you need to hire the project team, and define objectives, scope, purpose, and deliverables.
• Requirement Gathering and Analysis: Requirements are gathered and analyzed to see if the project is actually feasible. All this information is documented in a requirement specification document.
• Design: The design specifications created in this phase are used in the coding phase to actually write the code. The requirements are studied and evaluated, and the design of the system is prepared. The team’s goal is to understand what actions need to be taken and what they should look like.
• Implementation/Coding: The actual coding of the software begins. Any flowcharts or algorithms created in the design phase are translated into a programming language.
• Testing: Once the code is complete, the software needs to be tested for any errors. When the testing is finished, the software is delivered to the customer. Some teams may choose to include user acceptance testing (UAT), where users test the software before it is deployed to the general public.
• Maintenance: Once customers have been using the software in the real world, they may find additional problems. The development team will need to resolve, change, or modify the software to continue to be effective.

Iterative Waterfall Development

In the traditional Waterfall model, the team goes through each phase for the entire project. For example, they do the analysis for the entire project, then they do the design for the entire project, etc.

In an iterative Waterfall model, there is still a lot of upfront planning required. Once the plan is in place, the team follows the same pattern as traditional Waterfall but does it for each story. They do the analysis for one story, then all the design for one story, then all the coding and testing for one story. Then they repeat the process for another story. The work is broken up into chunks that benefit the development team.

How Waterfall Deals with Software Requirements

Waterfall projects define all software requirements upfront. The project cannot proceed unless these requirements have been identified and documented.

Some Waterfall projects may have a dedicated team to capture, collect, and gather these requirements. They may use questionnaires, face-to-face or phone interviews, white boards, and modeling tools to capture stakeholder and customer requirements.

Once the initial requirements are defined, the team should produce a requirements specification document (sometimes they may create more than one). This document defines what needs to be delivered so everyone understands the scope of the project.