Prior to SCRUM and other popular Agile methodologies, the Waterfall Methodology was widely used to organize and deliver software projects. The Software Development Life Cycle (SDLC) in Waterfall Model flows from one phase to another similar to the movement of water in a waterfall. That’s how the name “Waterfall Methodology or Waterfall Model” came into being. The process flow in Watefall Model is only in one direction ( just like water in a waterfall that flows only from top to bottom). The Waterfall Software Development life Cycle is also called V Model Software Development Life Cycle.
V Model or Waterfall Software Development Life Cycle
Below are the phases in a V Model Software Development Life Cycle or Software SDLC :
- Analysis Phase – An Analyst usually, gathers the requirements.
- Requirements Phase – Requirements are finalized.
- Design Phase – Code and other artifacts of the deliverables are modeled in this phase.
- Development Phase – Designs are put into practice to build the product.
- Testing & Integration Phase – testers make sure that the products meet the requirements to a high degree of quality
- Operations and Maintenance Phase – After testing the product is released to the customer. Further, there will be ongoing maintenance and support to the product in a live environment, and this is also considered a phase.
The Waterfall model is seen as an industry standard for running software projects for decades. However, there are some fundamental flaws with this model.
Fundamental flaws with the Waterfall model or Disadvantages of Waterfall Model
- The Principle flaw with the waterfall model is that it doesn’t accept changes to requirements once the Requirements phase is completed. On the other hand, in a business, things can change rapidly, consequently, the ability to implement changes as and when needed and a better change management approach is always key to success. So, this rigid nature of the Waterfall model towards requirement changes is a major flaw.
- Most of the defects are not found until the test phase, this often delays launch as more time is needed to fix bugs.
- The number of defects can never be forecast perfectly, so this often leads to overtime. This results in low morale and last-minute scrambles in the project.
In the real world software projects, requirements rarely remain fixed for the long term. So, there are only 2 ways to deal with requirement changes in the Waterfall model
- The Delivery team accepts changes in requirements even after the requirements phase (violation of the waterfall model), consequently, there are delays, an increase in cost, and also an annoyance to the team.
- The client should agree and stick to it that there shall be no requirements changes after the completion of the requirements phase. Thus the Project runs smoothly without delays.
Option 1:- In reality, most businesses go for this. Changes are inevitable in any business, so they can’t risk losing business at the cost of sticking to a delivery model.
Option 2:- Changes in requirements are viewed as bad. But the truth is, Change is often a reaction to market conditions and is often a good thing. Changing requirements can increase the business’s return on investment, which usually has a good knock-on effect on the company and the employees.
However, Neither of these situations is good.
Apart from these problems, the Waterfall model has to deal with other obstacles as any development model would such as
- Unclear requirements,
- unrealistic deadlines,
- inaccurate estimates,
- number and caliber of people working on the project can change eg: People Pinching delays.
- etc
These issues that we discussed and other issues are known as Impediments or blockers. Collectively these blockers can cause chaos on projects if allowed to.
In business, things can change rapidly, so change management is always key to success. In the Waterfall model, changes to requirements cannot be made at a later phase. After decades of running projects on the Waterfall model, it was clear that many companies needed a change in the delivery model and a better change management approach in order to keep projects running smoothly.
Recognizing these blockers, a group of thought leaders joined forces to create new iterative Agile Methods of working such as LEAN, FDD, DSDM, RUP, XP, KANBAN, CRYSTAL, SCRUM, SCRUM OF SCRUMS, LESS, DAD, DSDM, AUP, OpenUP etc.
