• Classical waterfall model
• Iterative waterfall model
• V model.
• Prototyping model

What are the major difficulties of the waterfall-based models?

1. Difficulty in accommodating change requests during development. In reality, 40% of the requirements change during development.
2. High cost incurred in developing custom applications.
3. Heavyweight processes:
   • Lots of documentation are produced at each phase, and it has been reviewed.
   • It has been noticed that 50% of the time, people involved in documentations.
4. Requirements for the system are determined and documented at the start are assumed to be fixed from that point on. And entire long-term planning is done based on the initial frozen requirements.

Fred Brooks: The assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. This assumption is fundamentally wrong and many software acquisition problems spring from this.

In response to the shortcoming of the waterfall model, these models were proposed, and a few of them are listed beneath:

1. Incremental model
2. Rapid Application Development model
3. Evolutionary model
4. Spiral Model

Detail description and discussion (Optional)

The waterfall model has some severe shortcomings because they are not as popular as they were about 30-40 years back. The main problem being faced is that the type of project handled differs from those handled 30-40 years back. Now, the projects are short, and the code is not written from scratch because a lot of code is being reused and only small modifications and tailoring is done, which we called service-oriented software.

The major difficulties of the waterfall-based models

The first problem is that there is no way change requests can be handled. The requirements are gathered up front and documented, it is assumed that this will not change, and then the plan is made based on these documented requirements, the design is done on these requirements, and then coding and testing are done with respective these requirements. But then, in reality, in the present projects, the requirements keep on changing as development proceeds. Typically about 40 to 50 percent of the requirements change after the initial requirement specification.

The second problem is that many of the projects now are for customizing applications, as already mentioned about the service-oriented software where the organization has some software and would tailor it for the specific needs of another customer. If we use the waterfall model for these custom applications, there will be a huge cost because the entire thing must be documented, specification laid out, design, etc.

The third problem is that the waterfall model is called a heavyweight process because much documentation is produced. These are starting from requirement specification, the reviews, review results, the design various types of plans everything is to be documented, and that is why these are called heavyweight processes. And it is estimated the typically, 50 percent of the effort by a development team goes towards creating documents, and naturally, the project costs increase and project delays.

Reference

1. Fundamentals of Software Engineering Book & NPTEL Video Lectures by Rajib Mall.