Software Engineering | Iterative Waterfall Model

Iterative Waterfall Model is the extension of the Classical Waterfall model. In a practical software development work, it is not possible to strictly follow the classical waterfall model. In this context, we can view the Iterative waterfall model as making necessary changes to the classical waterfall model to make it usable in practical software development projects. This model is almost same as the classical waterfall model except some changes are made to improve the performance of the software development. 

The iterative waterfall model provides feedback paths from every phase to its previous phases, which is the main difference from the classical waterfall model. 

When errors are detected at some later phase, these feedback paths allow correcting errors committed by programmers during some phase. The feedback path allows the phase to be reworked in which errors are committed and these changes are reflected in the later phases. There is no feedback path provided for feasibility study phase, so if any change is required in this phase then iterative model doesn’t have scope for modification or making corrections.

Feedback paths introduced by the iterative waterfall model are shown in the figure below. 

Phases of Iterative Waterfall Model:

All the phases of Iterative Waterfall Model in Software Life Cycle Model (SDLC) is the same as the Classical Waterfall Model, and these phases are explained 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. 

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.

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: 

    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 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.

Differentiation between Classical Waterfall model and Iterative Waterfall Model:
 

Iterative Waterfall Model is basically a replacement of Classical Waterfall Model. Classical Waterfall Model is hard to use. In practice it is not possible to strictly follow the classical waterfall model for software development work. So Iterative Waterfall Model is introduced after making certain necessary changes in the Classical Waterfall Model. The iterative waterfall model is cyclic, it’s possible to go from one stage to the previous one, whenever a project is not satisfying the demands of the customer.

 

The fundamental distinction between the iterative waterfall model and the classical waterfall model is that the iterative waterfall model provides feedback path from every phase to its preceding phase.

The phases of Iterative Waterfall Model are the same as the Classical Waterfall Model. The only advancement that Iterative Waterfall Model has over classical waterfall model is that in the iterative model, we have feedback paths that link every phase with one another and with the help of those, we can go to the previous phases and make the modifications that may be required in the software in the later phases of the development. The feedback paths allow for correction of the errors committed during a phase, as and when these are detected in a later phase. The iterative nature of the model allows for changes and adjustments to be made in the project.