Explain the Phased Waterfall Model - Testing

Explain the Phased Waterfall Model

It is a type of waterfall model where the project is divided into small phases and delivered at intervals by different teams. Different Teams work in parallel for each small phase and integrates at the end of the project.

As the name suggests, Waterfall Model is the basis of this. It essentially means, all the phases or small subsystems follow the traditional waterfall model of development.

The stages of "The Waterfall Model" are:

- Requirement Analysis & Definition: This phase is focused on possible requirements of the system for the development are captured. Requirements are gathered subsequent to the end user consultation.

- System & Software Design: Prior to beginning the actual coding, it is inevitable to understand what actions are to be taken and what they should like. The requirement specifications are studied in detail in this phase and the design of the system is prepared. The design specifications are the base for the implementation and unit testing model phase.

- Implementation & Unit Testing: Subsequent to receiving the system design documents, the work is shared into various modules and the real coding is commenced. The system is developed into small coding units. These units are later integrated in the subsequent phase. Every unit is tested for its functionality.

- Integration & System Testing: The modules that are divided into units are integrated into a complete system and tested for proper coordination among modules and system behaves as per the specifications. Once the testing is completed, the software product is delivered to the customer.

- Operations & Maintenance: It is a never ending phase. Once the system is running in production environment, problems come up. The issues that are related to the system are solved only after deployment of the system. The problems arise from time to time and need to be solved; hence this phase is referred as maintenance.

Unlike the big bang waterfall model, the phased model is suitable if the work can be grouped into separate units and delivered in steps rather than everything once and together, by different teams. Consider a system that consists of 4 subsystems, each being developed by a separate team. In the end all the 4 subsystems make up one complete system, giving the flexibility of breaking the system down in 4 parts and allowing each being developed separately. It’s more like a collection of mini projects run by different teams approach.