The Waterfall model is a classic SDLC model that is widely known, understood and commonly used. It was introduced by Royce in 1970 and is still being followed as a common approach for software development in various organizations across the industry.
In Waterfall model, each lifecycle phase can start only after the earlier lifecycle phase is complete. Thus, it is a linear model with no feedback loops.
Waterfall Model – Strengths
The strengths of the Waterfall model are −
- Easy to understand, easy to use.
- Provides structure to inexperienced development team.
- Milestones are well understood.
- Sets requirements stability.
- Ideal for management control (planning, monitoring, reporting).
- Works well when quality is more important than cost or schedule.
Waterfall Model – Weaknesses
The weaknesses or the disadvantages of the Waterfall model are −
Idealised − It does not match reality well.
Unrealistic − cannot expect accurate requirements early in the project.
Does not reflect iterative nature of exploratory development that is more common.
Difficult and expensive to make changes.
Software is delivered only at the end of the project. Due to this −
Delays discovery of serious defects.
Possibility of delivery of obsolete requirements.
Significant management overhead, which can be costly for small teams and projects.
Requires experienced resources at every phase − analysts, designers, developers, testers.
Testing starts only after the development is complete and the testers are not involved in any of the earlier phases.
The expertize of the cross-functional teams is not shared as each phase is executed in silos.
When to Use Waterfall Model?
You can use the Waterfall model if −
Requirements are very well known.
Product definition is stable.
Technology is well understood.
New version of an existing product.
Porting an existing product to a new platform.
Large organization with structured cross-functional teams.
Communication channels are well established within the organization and with the customer as well.
Evolutionary Prototyping Model
In software development using Evolutionary Prototyping model, the developers build a prototype during the requirements phase. The end users then evaluate the prototype and give feedback. The feedback can be corrections to the prototype or additional functionality. Based on the feedback, the developers further refine the prototype.
Thus, the product evolves through the Prototype → Feedback → Refined Prototype Cycles and hence the name Evolutionary Prototyping. When the user is satisfied with the functionality, and working of the product, the prototype code is brought up to the required standards for the final product delivery.
Evolutionary Prototyping Model – Strengths
The strengths or the advantages of an Evolutionary Prototyping model are −
Customers/end users can visualize the system requirements as they are gathered looking at the prototype.
Developers learn from customers and hence no ambiguities regarding domain or production environment.
Allows flexible design and development.
Interaction with the prototype stimulates the awareness of additionally needed functionality.
Unexpected requirements and requirements changes are easily accommodated.
Steady and visible signs of progress are produced.
Delivery of an accurate and maintainable end-product.
Evolutionary Prototyping Model – Weaknesses
The weaknesses or disadvantages of the Evolutionary Prototyping model are as follows −
Tendency to abandon structured development in the code-and-fix development, though it is not what is prescribed by the model.
This model received bad reputation for the quick-and-dirty methods.
Overall maintainability can possibly be overlooked.
The customer can possibly ask for the delivery of the prototype as the final, not giving the opportunity for the developers to execute the final step i.e. standardization of the end-product.
Project can continue forever (with continuous scope creep) and the management may not appreciate it.
When to Use Evolutionary Prototyping Model?
You can use the Evolutionary Prototyping model −
- When requirements are unstable or have to be clarified
- As the requirements clarification stage of a waterfall model
- To develop user interfaces
- For short-lived demonstrations
- For new or original development
- For implementing a new technology