This article explains the Waterfall method in a practical way. After reading this article, you’ll understand the basics of this powerful tool for software development and internet technology.
What is the Waterfall Method?
The Waterfall method is a project approach where the project is divided into linear successive phases. Each phase must be successfully completed before the next phase can be started. The method is often used in projects with a technical design and is a version of Systems Development Life Cycle (SDLC).
When applied in software development, the model is an iterative and flexible approach where progress, like the water of a waterfall, is largely in a single downward flow through the stages. The phases are: conception, initiation, analysis, design, construction, testing, implementation and maintenance.
The waterfall method is the first process model (SDLC) that was introduced. Originally, the waterfall method started in the construction industry. Highly structured and physical environments meant that design changes during construction resulted in sky-high costs. Subsequently, when the demand for software increased, there was no recognized alternative to managing these projects. Today, there are some very well-developed alternatives, such as Rapid Application Development (RAD), Joint Application Program (JAD), Agile Project Management (APM) and the spiral model.
Origin of the Waterfall Method
The first formal introduction and description of the Waterfall method is attributed to an article by Winston W. Royce in 1970. However, Royce himself does not use the word waterfall yet. The term Waterfall was first used in 1976 in an article by Bell and Thayer. From 1985, for example, the US Department of Defense adapted the method for their contractors working on software.
The phases of the Waterfall method
In Royce’s original model the following phases are described.
1. System and software requirements
The first phase involves understanding what exactly needs to be developed, what the purpose is, the function, etc. It is in this phase that the requirements, deadlines, guidelines and other matters are established. The result is mostly a document in which the requirements are listed (Requirements Understanding Document).
- Establishing requirements
- Viability test
The information gathered in the first phase is used here to generate product models and logic. This is very important for the management of production. A feasibility test is also done at the end of this phase. This applies to the financial and technical resources.
The third phase is the design phase. During this phase, the specifications from the first phase are studied and a system design is prepared. The system design helps with establishing the system- and hardware requirements. Thereafter it helps with the definition of the general system architecture. This phase must be completed before going ahead with the coding phase. The code that will be developed in the next phase is in fact being prepared now. The result of this phase is a High-Level Design Document (HLD), or a Low-Level Design Document (LLD).
- Design development in consideration of all requirements
- Establishing system requirements
- Documenting designs
In the fourth phase, the code is developed using the product models, logic and requirements from the previous phases.
After coding is completed the system design is tested. This is to ensure that there are no errors in the system when the client starts using it. A variety of tests are applied depending on the project. Think of quality assurance, system tests, beta tests or unit tests. If the system passes all the tests, the waterfall will continue to descend. The result of this phase is usually a test report, but in some cases also consists of a User Acceptance Test (UAT). The system is tested by a large number of users before the system becomes available to the general public.
- Integration of code
- Test activities
- Report in case of deviations
- Track progress
6. Implementation (installation, migration, support and maintenance)
The last phase consists of installing, migrating and maintenance of the new software (components). implementation can take place in different ways. Sometimes smaller units are integrated into an existing system first. In that case, every unit is individually tested and developed. This is also called Unit Testing.
Once the functional and non-functional tests from the previous phase have been successfully completed, the product is brought into the client environment. Although errors and bugs are prevented by testing, maintenance of the system is desirable. In this phase, maintenance includes making minor changes to the system or to small parts of the system to improve performance. These changes are either the result of client- or system developers requests. The result of this phase is usually a user manual.
Waterfall method vs. Agile
While both methods are applied in project management, the Waterfall method is very different from an Agile project management approach. First, Agile is a continuous cycle and the Waterfall method consists of sequential phases. The focus of the Waterfall method is on the design phase of the project, while with Agile, little time is spent on the design phase. The Waterfall method also requires much longer periods to build and test new software components than Agile. One of the strengths of Agile is that the software can be constantly tested and developed during the project.
As discussed, the Waterfall method is a methodology where the start of a new phase is dependent on the completion of tasks from the previous phase. Before a phase has been fully completed, a new phase cannot and may not be started. Where with the waterfall method the results go down like a straight stream, Agile is seen as a movement in which a large number of derivative methods are added that make optimal use of the values of Agile and flexibility.
The Waterfall method is ideal for use on projects that have a variety of dependencies between tasks and actions. Agile is better suited to projects in which the client is not sure about the desired result or is dependent on future factors. In general, Agile projects have a shorter delivery time than Waterfall projects. When choosing between the different methods a trade-off must be made between quality and speed.
Examples of Waterfall method
Until the turn of the century, the method was mainly used for software development. Even after the publication of the Agile manifesto in 2001, the Waterfall method was still used by many organisations. Today, the Waterfall method is not very popular. Often, projects follow an Agile approach or another iterative model, depending on the project requirements.
Successful Waterfall method projects
After the Waterfall method was introduced to the construction industry, it took some time for it to be adopted in the business world. First, the method was used to develop business applications such as Customer Relationship Management (CRM) systems, Human Resource Management (HRM) systems, Supply Chain Management systems, Inventory Management Systems and sales systems for shops and wholesalers.
Advantages and disadvantages of the Waterfall method
Using the waterfall method has some advantages over other project approaches.
Advantages of the Waterfall method
- The method is simple to understand and implement.
- For smaller projects the Waterfall method works well and produces good quality results.
- The waterfall method is a relatively easy approach to manage because the stages are performed one by one.
- The criteria for both the entry and the exit of the project are well defined, so it is easier to guarantee good quality.
- Results and progress are accurately documented with the Waterfall method.
- The Waterfall method reinforces good coding habits by defining them in advance.
- The Waterfall method clearly defines milestones and deadlines.
- The Waterfall method facilitates management control based on schedule and deadlines.
Disadvantages of the Waterfall method
Obviously, using the waterfall method also has some drawbacks compared to other project approaches.
- The design of the Waterfall method is not adaptive. If an error is found in a later phase, the whole process has to start again. That is time-consuming and costly.
- The Waterfall method ignores the opportunity to receive and process user and client feedback and input midway through the development process.
- The Waterfall process doesn’t start with testing until the end of the whole process.
- The Waterfall process does not account for the correction of errors.
- The Waterfall method lessens efficiency by not letting processes overlap.
- A working product is only available at the end of the development process.
- The Waterfall method is less suited to complex and risky projects.
Criticism of the Waterfall method
A major disadvantage of the Waterfall method is that clients do not know exactly what and how is being developed, and so when their requirements change, the entire project will need redesign, redevelopment, new tests and higher costs. On the other hand, the designers who work on the system may not be fully aware of future problems when designing a software system. In that case, it is better to design a new product than to persist in a design that does not take into account new limitations, requirements or problems.
One way to address this is to employ systems analysts. Analysing existing systems to determine how they can be replaced or developed. In practice, however, it is very difficult to separate system analysis and programming. That’s because implementing a system almost inevitably leads to problems that the analyst has not considered beforehand.
In response to the above criticisms, modified Waterfall methods were introduced. Examples are Sashimi (Waterfall with overlapping phases), Waterfall methods with sub-projects and Waterfall methods with an emphasis on risk reduction. Some organisations still value Waterfall method, such as the US Department of Defense. This is mainly because the control level is higher than with project approach alternatives.
Proponents of flexible systems development argue that the Waterfall method is very ineffective for software development. Others argue that the Waterfall method is used purely to market alternative development methods for commercial gain. A hybrid, comparable form of software development is the method of the Rational Unified Process (RUP). This method recognises the need and necessity of milestones in a project to keep it on track, but at the same time encourage iteration across different phases. This method is also called Waterfall-like.
Summary of the Waterfall method
The Waterfall method is a project approach for system- and design projects. The method is divided into five phases, with each phase required to be completed before the team starts with the next phase. An alternative term for the management of this kind of project is Systems Development Life Cycle (SDLC).
The first phase consists of the gathering of system requirements. The result is a document in which all requirements are listed. After that, the project team starts to analyse these requirements to generate product models and logic. At the end of this phase a feasibility test is done. In the third phase the design specification takes place. The complete design is taken into account with integration of all the requirements. In the following phase, coding of the new system is worked on. After codes have been completed, the system is tested after which its implemented and maintained.
In contrast to the Agile approach, the Waterfall method is a sequential process. This means that there is no overlap between the different phases. While this leads to inefficiencies, delays and additional costs according to some, there are also companies and organisations that prefer the Waterfall method. This mainly concerns organisations and projects in which control plays an important role. Another point of criticism is the fact that with the Waterfall method the client plays a very minor role. It is only at the end of the entire development process that the client will receive information and manuals about the new system for the first time. If the system then has to be revised, there is a chance that the entire process will have to be performed again.
To limit this risk, many projects us a hybrid form of the Waterfall method and Agile. An example of this is the Rational Unified Process (RUP). In contrast to the Waterfall method, this method does integrate milestones and iterative processes.
Now it is your turn
What do you think? Do you recognise yourself in the explanation of the Drill Down method? Is this tool used in your own working environment? If not, do you think this could be valuable in your work? What other helpful troubleshooting methods and tools do you know? What do you believe are pros and cons of the Drill Down technique? Do you have any tips or solutions?
Share your experience and knowledge in the comments box below.
- Alshamrani, A., & Bahattab, A. (2015). A comparison between three SDLC models waterfall model, spiral model, and Incremental/Iterative model. International Journal of Computer Science Issues (IJCSI), 12(1), 106.
- Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26-30.
- Laplante, P. A., & Neill, C. J. (2004). The demise of the waterfall model is imminent. Queue, 1(10), 10-15.
How to cite this article:
Janse, B. (2020). Waterfall Method. Retrieved [insert date] from toolshero: https://www.toolshero.com/information-technology/waterfall-method/
Add a link to this page on your website:
<a href=”https://www.toolshero.com/information-technology/waterfall-method/”>toolshero: Waterfall Method</a>
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?