The waterfall model was one of the first project management methodologies that came into being. Originating in manufacturing and construction, the model also inherited the highly structured approach and rigidity of these industries.
Later, for lack of better alternatives, the waterfall development methodology was adapted to software engineering. Dr. Winston W. Royce is often cited as the first who formally described the model in his paper called Managing the Development of Large Software Systems back in 1970.
In software development, waterfall describes a phased progression of activities. This is a linear and sequential approach that allows the team to break the project into understandable and explainable phases with clearly defined deliverables. The team proceeds to the next phase only when the previous phase is completed and everything is approved.
The process itself can be divided into different phases, depending on the IT project or other product development requirements.
In this stage, the development team methodically gathers project requirements — from the customer’s business context to the product performance level — and captures the results in a requirements specification. Well-documented requirements serve a foundation and guarantee a smooth software development process.
The team further analyzes functional and nonfunctional requirements, outlines the project scope and constraints, identifies the stakeholders, and develops the business logic. The phase is critical for obtaining a clear vision of the end product.
Using the output from the previous stage, the team proceeds to work on the system’s design, including the software and hardware architecture, database tables, and user interface mockups. The resulting design specification describes how the project will be executed from a technical standpoint.
Once the design is approved, the engineers commence the actual coding according to the project specifications. The coding process runs smoothly provided that the project design phase has been properly executed.
During this stage, the testing and quality control team performs all testing activities, including functional, system, and acceptance testing to find bugs, errors, or flaws. Testers also make sure that the product is built as per the requirements specification and that it functions as required. Any bugs found in the software mean that the development team needs to go back to the coding stage to fix them.
Sometimes referred to as the implementation phase, this is the final stage of the software development life cycle that covers the software deployment to a live environment. It also includes maintenance and subsequent support of the product to ensure it is functioning properly at all times.
In common practice, waterfall methodologies result in a project schedule with 20-40% of the time invested for the first two phases, 30-40% of the time to coding, and the rest dedicated to testing and implementation. The actual project organization needs to be highly structured. Most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project.
Often considered the classic approach to software development, the waterfall model became a staple of executing highly-predictable projects with rigid budget planning and well-defined, rarely changing requirements. The methodology is a good match for building applications in the military, healthcare, banking and finances sectors, as well as control systems for industrial processes.
But software development projects come in all shapes and sizes. And the heavyweight, plan-driven waterfall methodology doesn’t always cut it for aggressive time-sensitive projects with no clear-cut requirements. Alongside waterfall, there is a need for a more flexible approach ensuring faster time to market and accommodating the ever changing user requirements.
A host of new agile methodologies — eXtreme programming (XP), Lean, Scrum, and Kanban, to name a few — have sprung up within the last decade to embrace the new values of the changing business landscape. Being iterative in nature, these design philosophies encourage the testing activities early on to improve the product quality, speed up the product release process, and make communication more transparent.
That said, one might think the waterfall methodology has become completely obsolete, but it’s not quite true. The waterfall model has its advantages and can be successfully used for mission-critical projects where the requirements are unlikely to change.
The major Waterfall’s advantages include:
The major Waterfall’s disadvantages are as follows:
Like any other methodology, the waterfall software development model works best when put in the right context. With its inherent stability and linear development process, it can be a viable option for the projects with a fixed scope, a strict budget, and clear-cut requirements.
So if you have a clear picture of your end product and the time to market is not your first priority, the waterfall model may be the effective choice for you. Have you tried doing waterfall for any of your projects? Share your experience in the comments.