Yeah! You must be thinking why learn about waterfall methodology when the world is fast moving towards agile. But! Waterfall Methodology for Software development, introduced in 1970 by Winston Royce, is the pioneer of the SDLC processes. In fact it was the first model which was widely used in the software industry. Despite many new models being introduced, the Waterfall methodology is still the dominant process model. Additionally it is important to learn the know-how of Waterfall model in order to fully understand the emergence of Agile development methodology.
Waterfall methodology is a sequential model divided into different phases wherein each phase is designed for performing specific activity. The output of one phase becomes input for the next phase, i.e. it is mandatory for a phase to be completed before the next phase starts. Progress is seen as flowing steadily downwards (like a waterfall) through the phases.
Waterfall Methodology Phases
The sequential phases in Waterfall model are:
- Requirements gathering and Analysis: the requirements are defined, discussed, analyzed, clarified and documented. Result – Requirement Specification document.
- Design: With requirements as input, specify hardware and software requirements and define the overall system architecture
- Implementation (Code and Unit Test): With inputs from system design, develop-unit test-integrate the software.
- Testing: Testing of individual components, integration and complete system for the systematic discovery and debugging of defects.
- Deployment: After testing-fixing-retest, the software/application is deployed in the production environment for use by end-users
- Maintenance: Support and maintenance to fix production issues (if any), provide user trainings, release minor enhancements or defect patches.
The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name Waterfall Methodology.
Note: Waterfall methodology places emphasis on documentation such as Requirements document, Design documents, Test reports, Deployment guides, etc. If a fully working design document is present, new team members or even entirely new teams should be able to familiarize themselves by reading the documents.
Why prefer Waterfall Methodology?
The waterfall methodology provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily identifiable milestones in the development process. It is perhaps for this reason that the waterfall methodology is used as a beginning example of a development model in many software engineering texts and courses.
- Simple and easy to understand and implement.
- Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
- Suited to projects where requirements and scope are very well documented and fixed, the product itself is firm and stable, and the technology is clearly understood.
- The entry and exit criteria are well defined, so it easy and systematic to proceed with quality.
- Results are well documented including technical documentation.
- Easier to measure progress by reference to clearly defined milestones.
- Quality is the focus from the first phase itself since rework is costly in subsequent phases.
- Testing is easier as it can be done with reference to the scenarios defined based on the functional specification.
- The total cost of the project can be accurately estimated after the requirements have been defined.
When Waterfall Methodology doesn’t fit? Agile vs Waterfall
Or when to prefer Agile? 🙂 What if a client doesn’t exactly know the requirements before they see working software? What if client wants certain changes to be incorporated at the end of release? After all, to stay relevant, you need to readjust. You need to be swift & responsive to the client demands, changing technology and flexible workplace. Since waterfall is a rigid model with phased approach, it is not at all easy to incorporate any changes in the current release. And next release would be too late for some clients. What to do then? Simple! As in life – Develop >> Review >> Feedback >> Change >> Adjust >> Next development. In response to the perceived shortcomings with the pure waterfall methodology, modified waterfall models and finally Agile was introduced.
- Requirements are not fixed (moderate to high risk of changing) and Client can propose few changes during development – it is very difficult to go against the flow and change something in waterfall.
- Client wants a product demo as soon as possible and then decide on the future course of action. In waterfall, delivery of the final product is late and there is no prototype which can be demonstrated intermediately.
- Actual Testing starts only after development is complete, so more chances of late defect identification & rework.
- Client wants flexibility with the requirements and product design.
- When client doesn’t want the risk & uncertainty of what will be delivered at the end of the release.
- Since there is no prototype, a project can often take substantially longer to deliver than when developed with an iterative methodology.
Every software is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Selection of a particular type of life-cycle model depends largely on your project scope and stakes. As of today most of the projects are moving to Agile but still Waterfall methodology holds good for smaller projects. If requirements are straightforward and testable, Waterfall model will yield the best results.
While advocates of agile software development argue the waterfall methodology is an ineffective process for developing software, some skeptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies. What are your thought? Please share in comments…