Waterfall Model

Reading time: 40 minutes

The most popular way of developing software is ‘THE CLASSICAL WATERFALL’ model. It is the first Software Development Life Cycle (SDLC) model, introduced to describe the software development, in late 1950 and became popular in the 1970s by the first formal description of the waterfall model cited in an article by Winston W. Royce the term “waterfall” was coined by Bell and Thayer in 1976.

One of the main requirements of the Software development process is the non-iterative sequential WATERFALL MODEL. The entire software development process undergoes different phases, namely requirement details/analysis, design, coding & testing, system testing & integration and maintenance respectively.

A team of experts and trained people in each department handle different phases of the Waterfall model e.g., business and requirements analysis department, software engineering department, development and programming department, quality assurance (QA) department, and technical support department.

Explanation of Classical Model of Waterfall

In the “The Waterfall” approach, the whole process of software development is divided into separate phases. The outcome of one phase acts as the input for the next phase sequentially. This means that any phase in the development process begins only if the previous phase is complete. The waterfall model is a sequential design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

As the Waterfall Model illustrates the software development process in a linear sequential flow; hence it is also referred to as a Linear-Sequential Life Cycle Model.

1. The first and foremost stage is the study of resources, technical & financial feasibility.
2. Requirement Analysis and specification design
3. Design Phase
4. Coding and Unit testing
5. Integration and system testing
6. Maintenance

First Stage – Feasibility Study

The following activities are covered during the feasibility study phase.

1. Financial Feasibility
2. Technical Feasibility
3. Client Visit
4. Study Of Input-output Data
5. Case Study

The main aim of the feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or teams, leaders figure out a rough understanding of what is required to be done by visiting the client. They study different input and output data to be produced by the system. They study the required processing to be done on these data and look at the various constraints and effects on the behavior of the system. After understanding the problem(if any) they investigate the different available solutions.

Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution.

Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the product and whether they have sufficient technical expertise in the area of development. The following is an example of a feasibility study undertaken by an organization. It is intended to give you a feel for the activities and issues involved in the feasibility study phase of a typical software project.

Second Stage: Requirements Analysis & Specification Design

The following activities are carried out during the requirements analysis and specification design phase.

1. Requirements gathering and analysis
2. Requirements specification

The requirements analysis and specification phase aims to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities-

• Requirements gathering and analysis
• Requirements specification

The aim of ‘requirements gathering’ is to collect all relevant information from the customer regarding the product to be developed. Once this is done and a clear understanding of the customer requirements is available then the incompleteness and inconsistencies are removed. The requirements analysis activity is started by collecting all the relevant data related to the product to be developed from the users of the product and from the customer through interviews and discussions.
E.g., to analyze a business accounting software required by an organization, the analyst should interview all the accountants of the organization to assess their requirements and expectations.

It is necessary to identify all ambiguities and contradictions in the requirements as there is a possibility that the data collected may contain several contradictions and ambiguities since each user typically has only a partial and incomplete view of the system. Therefore to resolve them through further discussions with the customer.
Once all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements/ expectations have been properly understood, the requirements specification activity can start.

This activity includes the steps to systematically capture and organize the user requirements into a ‘’Software/hardware Requirements Specification’’(SRS) document.
The customer requirements identified during the requirements gathering and analysis activity are organized into an SRS document. The important components of this document are functional requirements, the nonfunctional requirements, and the goals of implementation.

Third Stage: Design Phase

The following activities are covered during the design phase.

1. Creation of system design as per the requirements gathered during the previous phase.
2. Definition of overall system architecture
3. Documentation of design The two Design Phases:
   • High-level design
   • Low-level design

The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming languages. In technical terms, during the design phase, the software architecture is derived from the SRS document.

The two phases of design are:

1. High-level design

High-Level Design (HLD) includes disintegrating a framework into modules and speaking to the interfaces and invocating connections among modules. An HLD is alluded to as programming engineering. An HLD report will normally incorporate a high-level design graph delineating the parts, interfaces, and systems that should be additionally determined or created. The archive may likewise portray or generally allude to work processes and additionally information streams between part frameworks.

2. Low-level design

LLD, also known as detailed design, is used to design the internals of the individual modules identified during HLD i.e. data structures and algorithms of the modules are designed and documented. Program specifications are covered under LLD. LLD elaborately describes every module so that the programmer can directly code the program based on it. There will be at least one document for each module. The LLD will contain

• a detailed functional logic of the module in pseudocode
• database tables with all elements including their type and size
• all interface details with complete API references (both requests and responses)
• all dependency issues error message listings
• complete inputs and outputs for a module.

Fourth Stage: Coding and Unit Testing

The following activities are covered during the code and unit testing phase.

1. Implementation Phase
2. Developing Source Code
3. Program Modules
4. Testing Of Modules
5. Debug The Errors

This stage is also called the implementation phase. This stage involves the coding and unit testing of software development and to translate the software design into source code. Each component of the design is applied as a program module. The end-product of this phase is a set of program modules that have been being tested individually to ensure the correct working of all the individual modules. The testing of each module in isolation is the most ideal way to debug the errors at this stage.

Fifth Stage: Integration and System Testing

The following activities are covered during the integration and system testing phase.

1. Integration in Planned Manner
2. Steps of Integration
3. Addition of Modules
4. System Testing

Once the modules have been coded and unit tested, the Integration of different modules is undertaken. During the integration and system testing phase, The modules are integrated in a planned manner. The different modules making up a software product are rarely integrated into one shot. Integration is normally carried out progressively over several steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out to ensure that the developed system conforms to its requirements laid out in the SRS document.

This is a level of software testing where a complete and integrated software is tested. The various tests may include

1. Alpha (α ) - Testing (Development team)

2. Beta (β) - Testing (set of customers)

3. Acceptance Testing (customers)

System testing usually comprises of three different kinds of testing activities:

1. α testing: It is the system testing carried out by the development team.

2. β testing: It is the system testing carried by a friendly set of customers.

3. acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan document.

The system test plan identifies all testing related activities to be performed, mentioning the schedule of testing, and defining the resources. This step also includes all the test cases and the expected outputs for each test case. After integrating the unit tested code, it is made sure that it works well, as expected and error-free. All the functional and non-functional testing activities are performed to check whether the system meets the requirement perfectly.
The progress on testing is tracked through tools like traceability metrics, ALM. Finally, the progress report of testing activities is prepared.

Sixth Stage: System Deployment and Maintenance

The following activities are covered during the system deployment and maintenance phase.

1. Product Deployment
2. Development and Maintenance Maintenance: Corrective Maintenance

Once the functional and non-functional testing is completed, the product is deployed in the customer environment or released in the market.

Maintenance of any software product requires many efforts than the efforts put in to develop the product. Researches confirm that the relative effort of the development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.

Maintenance involves performing any one or more of the following three kinds of activities:

a) Corrective maintenance: Correcting errors which were left undiscovered during the product development phase is the part of maintenance
b) Perfective maintenance: Improving the implementation of the system and enhancing the functionalities of the system according to the customer’s requirements. This is done to alter attributes or improve performance.
c) Adaptive maintenance: Porting the software to work in a new environment. For example, ports may be required for the smooth running of the software to work on a new computer system or with a new operating system. The defects uncovered during the live use of the software are also taken care of in the maintenance stage.

Advantages Of Waterfall Model

The central idea of the waterfall model is to spend the majority of time, money and effort upfront: 20-40% in the first two phases, 30-40% on coding/development, and the rest during implementation and maintenance.

1. Discipline: Every phase has a defined start and endpoint. The progress can be distinctly identified by both, the client and the software developer, through the use of milestones.

2. Time and cost-effective: The emphasis on requirement and design, before writing the codes/ programs ensures the minimal wastage of time, effort and cost and decreases the risk of slipping off schedule.

3. Quality improvement: The flaws can be easily caught and taken care of at the Design stage, much earlier than the Testing stage.

Shortcomings of waterfall model

It is assumed that no developmental error is ever committed by the engineers during any of the life cycle phases in the classical waterfall model. However, in practical development environments, a large number of errors are committed in almost every phase of the life cycle.

The source of the defects can be many: due to oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers, etc.

• In waterfall model, bugs/errors are usually detected much later in the life cycle. E.g., a defect might have gone unnoticed until the coding or testing phase. Once a defect is detected, the engineers need to go back and rectify some of the work done during that phase and the subsequent phases. Therefore, in any practical software development work, it is not possible to strictly follow the classical waterfall model.

• This model is not good for those projects where the requirements keep changing.

• Implicit assumptions that the design can be translated into a product can be lead to the roadblock at a very later stage.

• Lack of adaptability across all stages of development is the most daunting disadvantage of the waterfall model. When a test in the fifth stage reveals a fundamental flaw in the design of the system, it requires a dramatic leap backward in stages of the process. In the worst case, it leads to a devastating realization regarding the legitimacy of the entire system. While most experienced teams and developers would argue that such revelations shouldn’t occur if the system was properly designed in the first place, not every possibility can be accounted for, especially when stages are so often delayed until the end of the process.

• Due to the strict incremental process that the waterfall model enforces, the user or client feedback is received only during the later stages of the development cycle. While project managers can enforce a process to step back to a previous stage due to an unforeseen requirement or change coming from a client, it will be both costly and time-consuming, for both the development team and the client.

• Waterfall strictly introduces testing quite late into the cycle. Most bugs or even design issues won’t be discovered until very late into the process, but it also encourages poor coding practices that lack enthusiasm and determination, since testing is only an afterthought.

• The waterfall is based on steps that keep the teams strictly moving in a forward direction, there’s no room for unplanned changes or updates. If the team has strictly followed the waterfall model nearly to the end of the project and faces a sudden and unexpected change in terms of goals or scope, pivoting will become mighty difficult. Much of the work done so far may go useless.

• Perfective Maintenance: Maintenance to manage the project perfectly to reduce bug reports.

• Adaptive Maintenance: Maintenance according to current state of project, review, customer feedback and more.

With this, you have the complete idea of Waterfall model of Development. Enjoy.