Software Engineering | Classical Waterfall Model

The classical waterfall model is the basic software development life cycle model. It is very simple model. It is also known as a linear-sequential life cycle model. Earlier this model was very popular but nowadays it is not used. But it is very important because all the other software development life cycle models are based on this model. We therefore need to first understand the classical waterfall model well, in order to be able to develop proper understanding of other life cycle models.  It is not a practical model because it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software.

The classical waterfall model divides the life cycle into a set of phases. In this model 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 is seen as following steadily downwards like a waterfall through several phases. Here the phases do not overlap with each other. 

Phases of Classical Waterfall Model:

The different sequential phases of the classical waterfall model are shown in the figure below: 

Feasibility Study: The main aim 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 then determining the various possible strategies to solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks.

Project managers or teams, leaders 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.

Requirements analysis and specification: The aim of the requirement analysis and specification phase is to understand the exact requirements of the customer and document them properly. This phase consists of two different activities.

1. Requirement gathering and analysis: The aim of ‘requirements gathering’ is to collect all relevant information from the customer regarding the product to be developed and then the gathered requirements are analyzed.

The goal of the requirements analysis part is to remove incompleteness and inconsistencies in these requirements. Once all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements have been properly understood, the requirements specification activity can start.

2. Requirement specification: The customer requirements identified during the requirements gathering and analysis activity are organized into 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: The goal of this phase is to convert the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. There are two design approaches being used at present: traditional design approach and object-oriented design approach.

 

Coding and Unit testing: In the coding phase software design is translated into source code. This phase is also called the implementation phase since the design is implemented into a workable solution in this phase. Each component of design is implemented as a program module. 

The end-product of this phase is a set of program modules that been individually tested. After coding is complete, each module is unit-tested to determine the correct working of all individual modules. The aim of the unit testing phase is to check whether each module is working properly or not.

Integration and System testing: Once the modules have been coded and unit tested, the Integration of different modules is undertaken. Integration of various modules is carried out incrementally over a number of 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 full working system is obtained and system testing is carried out on this.

System testing consists of three different kinds of testing activities as described below:

1. Alpha testing: Alpha testing is the system testing performed by the development team.

2. Beta testing: Beta testing is the system testing performed by a friendly set of customers.

3. Acceptance testing: After the software has been delivered, the customer performed acceptance testing to determine whether to accept the delivered software or reject it.

Maintenance: Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of the total effort spent to develop full software. Maintenance can be referred as a process of enhancement in the software product according to the changing requirements of the user.

There are three types of maintenance:

Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered during the product development phase.

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 for modifying the system to cope with changes in the software environment.