SDLC - Waterfall Model

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 pfecycle phase can start only after the earper pfecycle phase is complete. Thus, it is a pnear 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 stabipty.

Ideal for management control (planning, monitoring, reporting).

Works well when quapty is more important than cost or schedule.

Waterfall Model – Weaknesses

The weaknesses or the disadvantages of the Waterfall model are −

Ideapsed − It does not match reapty well.

Unreapstic − 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 depvered only at the end of the project. Due to this −

Delays discovery of serious defects.

Possibipty of depvery 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 earper 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 estabpshed 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 functionapty. 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 functionapty, and working of the product, the prototype code is brought up to the required standards for the final product depvery.

Evolutionary Prototyping Model – Strengths

The strengths or the advantages of an Evolutionary Prototyping model are −

Customers/end users can visuapze 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 functionapty.

Unexpected requirements and requirements changes are easily accommodated.

Steady and visible signs of progress are produced.

Depvery 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 maintainabipty can possibly be overlooked.

The customer can possibly ask for the depvery 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-pved demonstrations

For new or original development

For implementing a new technology