The classical waterfall model is idealistic and assumes that no defect is introduced during any development activity. However, in practice, defects are introduced in almost every phase of the life cycle, and defects usually get detected much later in the life cycle.
For example, a design defect might go unnoticed till the coding or testing phase. Once a defect is detected, the phase in which it occurred needs to be reworked. Further, redo some of the work done during that, and all subsequent phases are expensive and time-consuming. Therefore, the classical waterfall life cycle model needs some feedback mechanism to correct the errors in the previous phases.
This feedback mechanism is introduced and named it Iterative waterfall model (or waterfall model).
Before going into the details of the Iterative waterfall model, we will first understand the Phase containment of errors. This is required in the iterative waterfall model as they introduced the error correction mechanism in the previously frozen phases. The error correction cost will be minimized if it exists and detects in the same phase.
For example: If a design problem is detected in the design phase itself, the problem can be taken care of much easier than, say, if it is identified at the end of the integration and system testing phase. The main problem is rework must be carried out not only to the design but also to code and test phases. The principle of detecting errors as close to its point of introduction as possible is known as Phase containment of errors.
Iterative waterfall model
The iterative waterfall model is very similar to the classical waterfall model, but there are feedback paths; these feedback paths make the model realistic. Here, we assume that there can be a defect noticed during the testing phase, and we need to go back to the design phase or maybe the requirement analysis phase and then fix that defect. The defects must be detected and fixed in the same phase to lower the correction cost. The more delay occurs in detecting the defect, the more expensive it will be. This is the main concept behind Phase containment of errors.
Iterative Waterfall Model strengths
- Easy to understand, easy to use.
- Provides a reference for inexperienced staff.
- Milestones are well understood by the team.
- It provides requirements stability.
- Facilitates strong management controls.
Iterative Waterfall Model deficiencies
- All requirements must be known upfront.
- Deliverables created for each phase are considered frozen.
- It can give a false impression of progress as there is no output until the project’s completion.
- Integration is one big bang at the end.
- Little opportunity for the customer to preview the system.
When to use the Iterative Waterfall Model
- Requirements are well known and stable.
- Technology is understood.
- Experienced development team.
Although, the iterative waterfall model has so many limitations. It is the most widely used model by far, and almost every other model is derived from the waterfall model.
Detailed Explanation of Iterative waterfall life cycle model
The iterative waterfall model is very similar to the classical waterfall model, but there are feedback paths; these feedback paths make the model realistic, unlike the classical model where one phase completes and then the next phase completes. Here, we assume that a defect will get noticed during the testing phase, and we need to go back to the design phase or maybe the requirement analysis phase and then fix that defect or series of defects in the lower phases.
To minimize error propagation, it is important to detect it when the developers make mistakes. The idea is that the defects must be detected and fixed in the same phase that will incur the lowest cost. The more delay occurs in detecting the defect, the more expensive it will be.
If a design defect is detected in the design phase itself, then it just needs to change the design document, but if it is detected during the testing phase, not only the design document needs to be changed, but the code needs to be reworked, and that will be much more expensive. So, this is called the phase containment of errors. Once a mistake or error occurs, it is an important principle that this must be contained in the same phase; it is called a phase containment of errors.
The principle of detecting errors as close to its point of the introduction is called the phase containment of errors it is a very important principle and very intuitive too.
The main strength of the waterfall model is that it is very intuitive, easy to understand, and all the developers can very easily understand and use the model. The milestones are clearly understood by the team, and the project manager can easily monitor the progress.
One of the major problems with the waterfall model is that it is not very suitable to handle changes to the functionalities. And we know that almost every software project sooner or later demands requirement change. There are many reasons why the requirement may change.
For example, the customer may not have thought that some functionalities will be required because he/she did not understand or did not think or cannot grasp what all required at the beginning of the project is. Still, as he/she looks at functionalities, then he/she can make out that certain functions will be required. The other is that as the development occurs, the business itself might undergo some change, and therefore, changes will be required.
So, there are many reasons why changes will be required during the software development, but the requirements are fixed upfront in the waterfall model. Then the design, coding, and testing are undertaken, and the waterfall model provides no way to make any changes. This is possibly the biggest shortcoming of the waterfall model.
Another problem with this model is that once the customer gives the requirement, they cannot see the system until the end when it is delivered to them. It would have been perfect if the customers were involved, they could see that what are the functionalities that or they are being developed, they could have suggested modifications, and so on.
These are the major difficulties with the waterfall model that it does not have the flexibility to handle the requirement change, a false impression of progress because phases are getting complete, but integration is big bang at the end where it is noticed that the progress is very less; most of the functionalities are not working, and the customer involvement is very minimal, the customer cannot give suggestions.
Reference
- Fundamentals of Software Engineering Book & NPTEL Video Lectures by Rajib Mall.
3,428 total views, 1 views today
