Pure Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow; hence it is also referred to as a linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete. In waterfall model, phases do not overlap.
1) Waterfall model is simple to implement and also the amount of resources required for it are minimal.
2) In this model, output is generated after each stage (as seen before), therefore it has high visibility. The client and project manager gets a feel that there is considerable progress. Here it is important to note that in any project psychological factors also play an important role.
3) Project management, both at internal level and client's level, is easy again because of visible outputs after each phase. Deadlines can be set for the completion of each phase and evaluation can be done from time to time, to check if project is going as per milestones.
4) This methodology is significantly better than the haphazard approach to develop software. It provides a template into which methods of analysis, design, coding, testing and maintenance can be placed.
5) This methodology is preferred in projects where quality is more important as compared to schedule or cost.
1) Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.
2) It is often difficult to get customer requirements explicitly. Thus specifications can't be freezed. If that case arises baseline approach is followed, wherein output of one phase is carried forward to next phase. For example, even if SRS is not well defined and requirements can't be freezed, still design starts. Now if any changes are made in SRS then formal procedure is followed to put those changes in baseline document.
3) In this model we freeze software and hardware. But as technology changes at a rapid pace,such freezing is not advisable especially in long-term projects.
4) This method is especially bad in case client is not IT-literate as getting specifications from such a person is tough.
5) Even a small change in any previous stage can cause big problem for subsequent phases as all phases are dependent on each-other.
6) Going back a phase or two can be a costly affair.