How Waterfall Model Works


The waterfall model is a traditional way of creating an application where systems development life cycle (SDLC) is managed. It is a classical approach considering sequential development method. It has predefined phases to manage SDLC. Let’s consider how Waterfall looks like in real world. Water falls from the cliff or from some height and it never goes back (In normal scenario it is not possible right?). In similar manner, each phase has predefined goal to achieve and it can’t go back to fix it. Output of each phase is Input of next phase. Hence, it is very significant that each phase has an effective outcome else next phase will be affected.

 

The waterfall model is a traditional way of creating an application where systems development life cycle (SDLC) is managed. It is a classical approach considering sequential development method. It has pre-defined phases to manage SDLC. Let’s consider how Waterfall looks like in real world. Water falls from the cliff or from some height and it never goes back (In normal scenario it is not possible right?). In siilar manner, each phase has pre-defined goal to achieve and it can’t go back to fix it. Output of each phase is Input of next phase. Hence, it is very significant that each phase has an effective outcome else next phase will be affected.
It has following phases and there is no iterative process. What it means? It means if something is broken then we can’t go back and fix it.
1) Requirement Analysis: All requirement analysis is done by Business Analysts and it is documented and signed by different stakeholders. This phase an outcome in the form of What needs to be done?
2) Design: This phase an outcome in the form of What is the best way to implement requirements specified in the Requirement Analysis phase? Often Technical Architecture is decided by Solution Architects and Technical Architects by involving all Leads of Teams who are going to be in implementation phase. E.g. Sharepoint Development Team, Database Team, Testing Team, Infrastructure Team, UI Team etc. In Case of Testing,
3) Implementation: Application is actually developed in this phase in modules or units or components. This phase an outcome in the form of “Real implementation or Development of Artifacts”.
4) Testing: Each modules or units or components are tested and verified individually based on its functionality and integrated to form overall application behavior. This phase an outcome in the form of whether Artifacts are working properly as desired?
5) Deployment: After all testing and integration, application can be released for end users. This phase an outcome in the form of deployment of Artifacts in Production Environment.
6) Maintenance: This phase an outcome in the form of maintenance activities if required.
The problem with this model is that it doesn’t allow to go back and forth in case something is broken. However, this model is used if requirements are fixed and well documented. Nowadays, it is a the rarest of rare to have fixed requirements as it is dynamic world having Cloud computing and other new disruptive innovation in place.
What if Project definition changes and technology is not fixed due to dynamic nature of Project in initial phase? In such situation it won’t work. In my experience, project was of long duration and resources were not fixed as technology was also not fixed due to various issues. Requirement were also changing as per the discussions going on and hence it was more dynamic and not fixed. In such scenarios, Waterfall Model doesn’t work as it doesn’t support revision or reflection. In addition, we can’t get feel of an application until all phases are completed.
However, it is easy understand, control, manage Project in case of Waterfall model. Fixed responsibility, predefined structure, and predefined milestones brings lot of transparency.

Leave a comment

Your email address will not be published. Required fields are marked *