What is the Problems of Waterfall Model?

The waterfall model is a relatively linear sequential design approach for certain areas of engineering design.

In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction downwards, like a waterfall, through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. Used in software development projects, the phases typically look like this:

1. Requirements

If you are into software development or any type of project creation team, you would want to know the business context of what you are trying to create — you want to define what kind of problems you are trying to resolve and how people would react to your finished product. After you define all these “requirements”, you have the input that you need to move on to the next step.

2. Designing

This step is made up of all the steps that you need to satisfy all the requirements that you have determined earlier. In software development, this is the part where you define all the software and hardware architecture, programming language, data storage, etc. This is also the part wherein you determine how the project would be useful to its end user.

3. Implementation

In this step, you begin to construct what you have designed in your plan. This part of the Waterfall method is dedicated to meeting the standards that you have made in the previous steps. This is the part where people from the development team come in and make all the things discussed in the previous steps happen.

4. Verification

This is the part of the method where quality assurance people enter to ensure that the development team did not make any mistakes. This is also most likely the part where people realize what is working or not working in their plan.

Note That

When all things are satisfied by the project developers, the client or the end user comes in and makes the final call if the project is ready to be launched.

The Waterfall method makes it a point that when something goes wrong in a particular stage, people can go back to the previous one to see what went wrong. For example, if there is a problem in the Plan Implementation and people know that they simply followed the blueprint that has been handed over to them, then managers look at their plan and make their revisions from there.

What is the Problem of Waterfall?

Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs.

Developers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems.

Thus, there is no guarantee that the requirements that the organization has thought of would actually work. From here, you would realize that the Waterfall model has the following problems:

1. People blindly follow plans.

In the traditional method, people pay more attention to how things will happen during the right moment without being mindful if things are really falling into place. While planning is important, it is also important that developers and quality checkers understand how things should happen, especially with the client or the end-user. It is also important that all people involved in the project can immediately say how a particular step in project fulfillment can fall apart without having to wait for the testing stage.

2. Sequential process and changes become costly

This approach does not make allowance for the change of defined requirements as the project progresses. Thus there is a big potential that the software will not fully meet the requirement of the user, it will be inefficient and have poor functionality.

It is inadequate as developers cannot just go back and change something in a previous phase as the consumers requirement change but the developer has to go back to where the requirement needs to change and start that phase all over. Not until that phase is complete can he move on to the next phase.

3. End-users do not know what they want.

Most times a end users mind is constantly changing and most persons have a vague idea of their software requirements and its as the software develops that they specify their requirements.

When it is time to hand over the finished product to a client, it is likely that they will not like how it turned out, despite deliberately saying otherwise during the initial stages. It is easy for clients and end-users to change what they want over time. The Waterfall system does not have a way to resolve that yet, without having to revise plans and redoing the entire project altogether.

4. Testing for quality may suffer.

It is impossible to accurately predict the outcomes of a project, and when the entire team is pressed for time, it is possible to cut the testing stage short in order to meet the deadline.

5. You’ll never know what stage you really are on.

Since the product that you are trying to create will not be produced until the very end, you are not really sure if you are still on planning or you are already on developing stage. That means that it is also likely for you to spend more time on a stage than what you have expected because of this poor visibility.

In the end, the Waterfall method can be too risky since it is too rigid. In order for you to make you produce a product that works and would be flexible enough to help you figure out what is working or not.

Related Resources

• Agile & Scrum — Software Development Articles (English) (Chinese) (Japanese)