What is Waterfall Model?

Waterfall Model is the first model introduced in Software Development Life Cycle. The term was first introduced in a paper published in 1970 by Dr. Winston W. Royce and continues to be used in software development processs of industry. This model is similar to the water flows direction from top to bottom (current phase to next phase) and can't go back in reverse direction to the previous phase. Waterfall Model is very simple to understand, use and has distinct endpoints or goals at each phase.

The waterfall model is first linear, sequential approach is popular in software engineering and product development.

The waterfall model whole process is divided into separate phases. In the waterfall model, the current phase should be completed to move to the next phase and current phase input is the output of the previous phase. The model works in a sequential way and absolutely no overlapping in the phases.The waterfall model is a sequential design process through the phases of Requirements, Analysis, Design, Construction, Testing, Deploymment, and Maintenance.

Why Waterfall Model?

Waterfall model is first development model in Software Development Life Cycle and mostly no other model exists at the time of this model. Waterfall Model got popular in short spam of time and fits to the any size(small, medium or large) project.

When to use Waterfall Model?

Waterfall model is used when -

• All the requirements are clearly defined at the begining.
• No ambiguous requirements.
• Client doesn't want to involve more in development and reviews only output.
• Key constraint is on development side, but not financial.
• Working technology is clearly understandable.
• Having clear idea on what is the end product.

Phases -

Waterfall Model has seven predefined phases and those are -

• Planning and Requirement Phase.
• Analysis Phase.
• Design Phase.
• Development or Implementation Phase.
• Testing Phase.
• Deployment Phase.
• Maintenance Phase.

Below diagram represents the pictorial representation of each phase and the predefined order of them.

Planning and Requirements Phase -

Planning is the first and foremost phase in Waterfall model. The senior members of the project like Manager, Delivery Manager, Domain Experts, Sales Managers etc involves in this phase. At the first step, the requirement idea and the inputs explains the overview of the estimates to everyone. Based on the inputs, the project execution approach, model used to develop the system would be decided. It also helps to do feasibility study economic and other operational aspects. In this, the overall project planning, resource planning, risk identification and overall project execution planning discussed and finalized. Risk identifying is generally done in this phase. A feasibility study is conducted on the Technical aspects which help to decide and describe the approach which could be followed to implement the project successfully with a low risk.

Requirement Gathering is the most important and first phase of watefall model. In this phase, business analyst and project manager participate in the meetings with client to gather the requirements.

• Client is the owner of the product and provides the information about what to build, who will use it or purpose of it to all the participants.
• Business analyst is the person who gathers the high level requirements from the client and document them in the form of business requirements
• Project Manager can located at onshore/offshore who is going to handle the project.

• Input - New requirement or idea or issue to improve the business.
• Outcome - Business requirements/BRS.
• Who invloves - Client, Business Analyst, Project Manager and all Stake holders.

Business requirements are generally documented in Business Requirement Document (BRS). Note that the BRS document name may gets changed based on the naming conventions defined in the project and name varies from project to project.

Examples - Business Specification (BS), Customer Requirement Specification (CRS), etc, and many more.

Analysis Phase -

Once the requirements gathering phase completed, Business Analyst (BA) converts the business requirements into technical requirements with the help senior team members like SMEs (Subject-matter experts) and team leads. The technical requirements documented in a document called SRS (Software Requirement Specification) document. SRS consists of all the technical requirements for all system involved (that includes cross-applications if exists). SRS document should send for approval from the client or SMEs from client side to proceed with the next phases.

Note that SRS document name varies from project to project based on the naming standard defined. Examples - Requirement Specification Document (RSD), Project Specification Document (PSD), etc, and many more.

• Input - Business requirements/BRS.
• Outcome - Technical requirements/SRS.
• Who invloves - BA and senior team members like SMEs (Subject-matter experts) and team leads.

Design Phase -

Design phase turns the requirements from SRS into a design plan called the Design Document Specification (DDS). Developers takes the requirements from SRS and creates their rough designs, working models, specifies how the software works, how the new design looks, how the control flow from screen to screen etc,. Design phase also models the design that includes - architecture, user interface, platforms, programming, communications and security etc,. In another words, overall system architecture is designed by defining their functionality of each module that includes their interaction with cross-systems.

The Design Document Specifications that are two types based on their level of design. Those are -

• High-level Design (HLD) - HLD contains the high-level architecture changes or design changes. Senior developers or architects creates HLD.
• Low-level Design (LLD) - LLD constans very detailed level architecture or design changes. Senior developers or developers creates LLD.

These two documents contain only design and sometimes code as well. The architects usually provide more than one approach in a Design Document Specification. This DDS sent for review to all the stakeholders and the best approach would be selected based on the features such as robustness, budget and timing constraints.

Once the architecture is selected, the stakeholders would then propose the modules design, data flow diagrams etc.

• Input - Technical requirements/SRS.
• Outcome - Design Document Specifications (DDS).
• Who invloves - Senior team members like SMEs (Subject-matter experts) and team leads.

Development or Implementation Phase -

Once the DDS gets approved, Development phase gets started. Developers start programming with the code by following organization coding standards. Once coding completed, the programmers uses the programming tools to compile and debug the programs to verify weather new code is working or not.

Developers from all levels in the team involves in this phase. The code is documented as Source Code Document (SCD). Developers has many responsibilities in this phase namely - coding and compilation of source code to make error free.

• Input - Design Document Specifications (DDS).
• Outcome - Source Code Document (SCD) and developed product.
• Who invloves - Developement team member from all levels.

Testing Phase -

Once the coding completed, the code gets tested to check whether it is working as expected or not. The developer performs the initial testing that are unit testing (UT) and/or Application Integration Testing (AIT) before handover the code to the testing team. If everything is fine, code gets migrated to the testing environment. Testing team will perform the testing from that point. The various testings the testing team performs are - quality testing, system testing, acceptance testing and approval testing.

In this phase, testing team follows the BRS document to verify the new changes or working fine or not. If anything not working, testing team raises the defect and development team has to fix it before the specified time.

Testing team thoroughly tests for the defects by follwing the process defined in STLC (Software Testing Life Cycle) to make sure that each and every component or module is working fine.

• Input - Developed Product.
• Outcome - Defect free Product and Testing Articrafts.
• Who invloves - Developement and Testing teams.

Deployment Phase -

Once the software is fully tested and has no defects or errors, then the test results and articrafts gor reviewed by the client and provides approval for deployment. Once the software got deployed to production, then the new functionality available to the end-users who are currently using the system.

Deployement might be complex based on the system design if it is integrated with multiple systems.

• Input - Defect free Product.
• Outcome - Usable product available to end-users.
• Who invloves - Deployement Team.

Maintenance Phase –

Once the end-user starts using the newly deployed sofotware, there might be a possibility that the real-time issues starts coming up. The team has to fix these issues to avoid the loss in business if the issue has less priority or less impact. If the issue has high priority and has huge impact, client can take a decision to roll out or backout new changes and refine the functionalities as required. This process of taking care for the finished product is called as maintenance.

Advantages –

• Clearly defined phases.
• Requirements are clear to everyone at the beginning of the project. So no confusions.
• Simple and easily understandable.
• Each phase is completely done one at a time.
• Works well for the smaller projects and gets complicated for large projects.
• Uses clear structure.
• High and detailed documentation that is useful for understanding the system by the team in future.
• Easy to manage and control.
• High visibility.
• Clear planning of project team structure reduces the problematic issues.
• Goals are defined clearly.
• Well defined and long quality assurance tests.
• No overlapping of the phases as it is a step by step process.
• Client interaction is very less.
• Release date and final cost will be calculated before starting the project.
• Reinforces the good habbits - define-before-design, design-before-code.
• Longer delivery time.
• Every phase has its own outcome.
• As a systematic approach, every phase has the transparency in the completion status.
• Best suitable for small projects as the requirements are clearly stated.
• Client intervention is hardly required.

Disadvantages –

• If the application requires some requirement changes that findout during the testing phase, it is not easy to goback and fix it.
• Does not allow much revision.
• No intermediate deliveries until the deployment of full product. End-users has to wait until the deployment even it is urgent requirement.
• High changes of risk and uncertainity.
• Not good for complex, object-oriented, long and on-going projects.
• Changes in requirements or change requests are difficult to handle.
• Not suitable for projects which has a chance to change the requirements based on the results.
• Excludes the client/ end-user.
• All the requirements are cleary known before the project kickoff.
• Difficult to measure the progress with the phases.
• No feedback path until the end of the project.
• If there is any mistake in middle, then the entire process has to be started from beginning.
• Lack of adoptability.
• Lack of flexibility.
• Longer delivery time.
• Testing phase will come late during the development process.
• Documentation process is time consuming for both the developers and testers.
• Tiny errors which are caused in the system would create a big mess.
• Measuring the progress for every stage is a real difficult.
• Not recommended for the projects which are already started.