Waterfall Model in Software Engineering

Waterfall Model in Software Engineering

The waterfall model in Software Engineering is the primary software development life cycle model. It is straightforward but idealistic. Earlier, this model was prevalent, but nowadays, it is not used. However, it is essential because all the other software development life cycle models are based on the classical waterfall model.

Why Do We Use the Waterfall Model in Software Engineering?

The waterfall software development model is used in large, complex projects, typically in information technology. A structured, sequential approach to project management and software development characterizes it.

The waterfall model is useful when the project requirements are well-defined, and the project goals are clear. It is often used for large-scale projects with long timelines, where there is little room for error, and the project stakeholders need to have high confidence in the outcome.

Features of the Waterfall Model in Software Engineering

Sequential Approach: The waterfall model involves a sequential approach to software development, where each project phase is completed before moving on to the next one.

Document-Driven: The waterfall model relies heavily on documentation to ensure the project is well-defined and the project team works towards a clear set of goals.

Quality Control: The waterfall model emphasizes quality control and testing at each phase of the project to ensure that the final product meets the requirements and expectations of the stakeholders.

Rigorous Planning: The waterfall model involves a thorough planning process, where the project scope, timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.

Overall, the waterfall model is used when there is a need for a highly structured and systematic approach to software development. It ensures that large, complex projects are completed on time and within budget, with high quality and customer satisfaction.

Phases of Classical Waterfall Model

The Waterfall Model is a classical software development methodology introduced by Winston W. Royce in 1970. It is a linear and sequential software development approach consisting of several phases that must be completed in a specific order. The phases include:

Requirements Gathering and Analysis: The first phase involves gathering requirements from stakeholders and analyzing them to understand the scope and objectives of the project.

Design: Once the requirements are understood, the design phase begins. This involves creating a detailed design document that outlines the software architecture, user interface, and system components.

Implementation: The implementation phase involves coding the software based on the design specifications. This phase also includes unit testing to ensure each software component works as expected.

Testing: In the testing phase, the software is tested to ensure it meets the requirements and is free from defects.

Deployment: Once the software has been tested and approved, it is deployed to the production environment.

Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing any issues that arise after the software has been deployed and ensuring that it continues to meet the requirements over time.

The classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can be started after the completion of the previous phase. That is, the output of one phase will be the input to the next phase. Thus, the development process can be considered a sequential waterfall flow. Here, the phases do not overlap with each other. The different sequential phases of the classical waterfall model are below.

Let us now learn about each of these phases in detail.

Feasibility Study

The main goal of this phase is to determine whether it would be financially and technically feasible to develop the software. The feasibility study involves understanding the problem and selecting the possible strategies to solve the problem. These different solutions are analyzed based on their benefits and drawbacks. The best solution is chosen, and all the other phases are carried out per this solution strategy.

Requirements Analysis and Specification

The requirement analysis and specification phase aims to understand and document the customer’s requirements properly. This phase consists of two different activities.

• Requirement gathering and analysis: Firstly, all the requirements regarding the software are gathered from the customer, and then the gathered requirements are analyzed. The goal of the analysis part is to remove incompleteness (an incomplete requirement is one in which some parts of the actual requirements have been omitted) and inconsistencies (an inconsistent requirement is one in which some part of the requirement contradicts some other part).
• Requirement specification: These analyzed requirements are documented in a software requirement specification (SRS) document. SRS document serves as a contract between the development team and customers. Any future dispute between the customers and the developers can be settled by examining the SRS document.

Design

This phase aims to convert the requirements acquired in the SRS into a format that can be coded in a programming language. It includes high-level and detailed design as well as the overall software architecture. A Software Design Document is used to document all of this effort (SDD)

Coding and Unit Testing

Software design is translated into source code using any suitable programming language in the coding phase. Thus, each designed module is coded. The unit testing phase aims to check whether each module is working correctly.

Integration and System testing

Integration of different modules is undertaken soon after they have been coded and unit tested. It is of various modules is carried out incrementally over several steps. During each integration step, previously planned modules are added to the partially integrated system, and the resultant system is tested.

Finally, after all the modules have been successfully integrated and tested, the entire working system is obtained, and system testing is carried out. System testing consists of three different testing activities, as described below.

• Alpha testing: Alpha testing is the system testing performed by the development team.
• Beta testing: Beta testing is the system testing performed by a friendly set of customers.
• Acceptance testing: After the software has been delivered, the customer performs acceptance testing to determine whether to accept or reject the software.

Maintenance

Maintenance is the most critical phase of a software life cycle. The effort spent on maintenance is 60% of the total effort spent to develop a complete software. There are three types of maintenance.

• Corrective Maintenance: This is done to correct errors not discovered during product development.
• Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the system based on the customer’s request.
• Adaptive Maintenance: Adaptive maintenance is usually required to port the software to work in a new environment, such as on a new computer platform or with a new operating system.

Advantages of the Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is straightforward and can be considered the basis for other software development life cycle models. Below are some of the significant advantages of this SDLC model.

• Easy to Understand: The Classical Waterfall Model is simple and easy to understand.
• Individual Processing: Phases in the Classical Waterfall model are processed one at a time.
• Properly Defined: Each stage is clearly defined in the classical waterfall model.
• Clear Milestones: The classical Waterfall model has obvious and well-understood milestones.
• Properly Documented: Processes, actions, and results are very well documented.
• Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like define-before-design and design-before-code.
• Working: The Classical Waterfall Model works well for smaller projects and projects where requirements are well understood.

Disadvantages of the Classical Waterfall Model

The Classical Waterfall Model needs to be revised. We can’t use it in real projects but use other software development lifecycle models based on the classical waterfall model. Below are some significant drawbacks of this model.

No Feedback Path

In the classical waterfall model, the evolution of software from one phase to another is like a waterfall. It assumes that developers never commit any error during any phase. Therefore, it does not incorporate any mechanism for error correction.

Challenging to accommodate Change Requests

 This model assumes that all the customer requirements can be completely and correctly defined at the beginning of the project, but the customer’s requirements keep changing with time. It is difficult to accommodate change requests after completing the requirements specification phase.

No Overlapping of Phases

This model recommends that a new phase can start only after the completion of the previous phase. But in real projects, this can’t be maintained. To increase efficiency and reduce cost, phases may overlap.

Limited Flexibility

The Waterfall Model is a rigid and linear approach to software development, meaning it needs to be better suited for projects with changing or uncertain requirements. Once a phase has been completed, it is difficult to make changes or return to a previous one.

Limited Stakeholder Involvement

The Waterfall Model is a structured and sequential approach, which means that stakeholders are typically involved in the early phases of the project (requirements gathering and analysis) but may not be involved in the later phases (implementation, testing, and deployment).

Late Defect Detection

In the Waterfall Model, testing is typically done toward the end of the development process. This means that defects may not be discovered until late in the development process, which can be expensive and time-consuming.

Lengthy Development Cycle

The Waterfall Model can result in a protracted development cycle, as each phase must be completed before moving on to the next. If requirements change or new issues arise, this can result in delays and increased costs.

Not Suitable for Complex Projects

The Waterfall Model needs to be better suited for complex projects, as the linear and sequential nature of the model can make it challenging to manage multiple dependencies and interrelated components.