When learning about the phases of SDLC, you are also at the same time learning about one of the most straight forward software development life cycle models; the waterfall model, which follows the flow of the phases in their exact order!

Assumptions

Knowledge of SDLC Phases

What is the Waterfall Model?

The waterfall model (sometimes called the classical waterfall model) is a linear approach to the software development life cycle where progress on a phase begins only once the previous phase has completely finished. In this sense, each phase "cascades" into the next, like a waterfall.

</div>

Starting from the planning phase, the requirements only begin to take place once planning is complete, just as design only occurs once the requirements have been completed. This continues until the final phase is reached.

Advantages of the Waterfall Model

The waterfall model is very simple, and most of the strengths of this model are in its sheer simplicity. Some of the biggest advantages of utilizing the waterfall model are:

Simplicity to understand.
Especially useful in small projects where complex management is not needed.
It is easy to manage a project under the rigid conditions.
Enforces good development hygiene; the needs must be defined before they can be designed and implemented.
Phases of the process are well-defined.

Disadvantages of the Waterfall Model

While the rigidity keeps the waterfall model simple, it also introduces some headaches that are the driving factors behind its low utilization in the industry:

Requirements cannot change once they are set in place.
Does not work well for complex projects.
Introduces risk in large projects of not allowing any working code to be implemented until later in the process after a significant investment has been made.
Does not offer many signals as to how the project is progressing; this makes it easy for projects to run over their time budget.

When to use the Waterfall Model

Despite its drawbacks, there are a few instances where it is favorable to utilize the waterfall model above others:

The project requirements are clearly defined and well documented.
You know there is a high certainty that the requirements will not change over time.
The project is relatively small.
The development team is highly skilled.
The technology behind the project is well-understood by the team.

If a project will have dynamic requirements that might change as the project develops, such as in a client-facing situation, it would be worth considering another model. However if you are creating a small, well-understood project that will not change over time, you might not even utilize a model at all, though you may end up unconsciously following the waterfall model.