[This blog is Part Two of a three part series. Check you may also want to check out our blogs Agile vs. Waterfall Methodology - Which one is right for you? and The Agile Methodology.]
The Waterfall methodology represents the first modern approach to systems analysis and large scale software development. It was developed by Dr. Winston W. Royce in 1970 and emphasized a logical progression of steps through the software development life cycle, much like a series of cascading steps down a waterfall.
Dr. Royce proposed the methodology as a way of transforming the high risk development process into a more linear process that could provide a desired outcome at lower risk levels.
Although the popularity of the approach has declined somewhat in recent years, the logical and sequential nature of the approach has been validated over many decades and is still a common design process in the IT industry.
In this blog we will dive into the core features of the Waterfall methodology and the types of scenarios it is best suited to.
Depending on its application across organisations and industries, there can be some minor differences in the naming conventions used but at its core, the Waterfall approach is relatively straightforward and relies on 6 steps:
In this initial phase, the project requirements are established between the development team and client/customer.
The project requirements are carefully considered and written up in a specification document that serves as the basis for all future development work. It provides one consistent set of documentation that all team members will follow.
Once the requirements have been documented, the team can transition to the design stage. This will include such details as what coding language will be used and outlines how the business logic covered during the Analysis step will be technically implemented. The design stage involves the team thinking about what solutions will be required to deliver the final product. It also incorporates how to best address the needs of the customer.
It is not until Step 4 that the actual work commences. This reflects the methodical and planning-heavy nature of the Waterfall approach. Code is written and business logic, models, and service integrations are implemented as specified in the previous stages.
During the testing stage, QA, beta, and other testers look to identify any problems or issues with the product. Where major defects are found, it is necessary to move back several steps to address them, however if the faults are only minor they are noted as areas where improvements can be made so that the team can progress onto the next step.
In the final step, the product is deployed into a live environment. However, this does not signal the end of the project, as Step 6 also includes support and maintenance of the product to address any minor issues or necessary changes to keep it functional. This may include patches and updates to address security concerns or additional features to keep it up to date.
Due to its more methodical and logical approach, Waterfall is well suited to projects that need to be rigorously documented such as for government clients or projects with high transparency requirements.
While in some cases it can be seen as a detriment, the Waterfall methodology essentially forces a project team to establish a detailed scoping and design structure. This favours projects where team members may come and go across the whole life cycle of the project, enabling the burden of design and a greater share of risk to be placed on the project documentation itself, rather than on any individual team member.
Waterfall is also ideally matched to project teams that for whatever reason cannot be located in the same geographical area or space. Waterfall therefore provides a viable alternative to relying on the Agile approach which tends to require close and constant communication.
Not sure if Waterfall is the right approach for you? Check out our blogs Agile vs. Waterfall Methodology - Which one is right for you? and The Agile Methodology.