The waterfall model is an information technology system development type model initially published in 1970 by Winston W. Royce. Prior to this time, there had been a number of significant malfunctions of IT system type projects; this is due to a lack of proper parameters, procedural approaches and procedural controls of IT project management tasks.
The purpose of this model is to introduce modus operandi into the system design process; as a skeleton for system development it advances consecutively through a succession of phases, preliminarily with system feasibility analysis and concluding up to system release and maintenance.
The name “waterfall” portrays system progress flows from the top to the bottom, like water falling down steps in a waterfall panorama, one phase at a time towards the bottom in a cascading effect.
In the present day, the waterfall model is considered classical and conservative system type model; however, it is indispensable for a fundamental understanding of system development in IT project systems management.
In the waterfall model, system design is broken down into a number of linear and sequential stages, in which system evolution is seen as flowing progressively downwards, through the phases. The waterfall model has distinct goals for each phase of development. In this development method it is not allowed to journey onto the succeeding phase until the operation of the preceding phase has been accomplished.
The output from each phase formed the input to the next phase; therefore, each phase had to be accomplished in turn to maintain the linkage between the inputs and outputs.
A detail waterfall model can be represented as in the following system development life cycle:
Phase I [SYSTEM FEASIBILITY / Justification]
———————–
Phase II [SYSTEM PLAN / Justification]
———————–
Phase III [OUTLINE DESIGN / Confirmation]
———————–
Phase IV [DETAIL DESIGN / Confirmation]
———————–
Phase V [CODING/ Unit Test]
———————–
Phase VI [INTEGRATION / Product Confirmation]
———————–
Phase VII [IMPLEMENTATION / System Test]
———————–
Phase VIII [OPERATION AND MAINTENANCE / Re Justification]
Here, a system flows through eight different sequential phases, and each phase is segmented into two divisions: the first division covers the task to be carried out in that phase, and second part is the justification or confirmation procedure on that specific work. Within this model, the terms confirmation and justification have specific meanings:
Justification means validation or inspecting whether the result is fit for the operational mission, that is, checking whether the correct product is being build or not. Is the product correct?
Confirmation means verification or inspecting the link between a result and the specification for the result. In other words, a check that the result is being constructed in the correct manner. Is the system structure correct?
The process of building the systems product flows phase to phase with very little interaction in-between two stages, apart from transfer of outputs and inputs between them. The phase progression sequences enforce discipline as every phase has a specific start and end spot, and progress can be categorically acknowledged.
Within more modern system design projects, the water model is in use to mean any chronological representation that is divided into successive phases and which pursue the common structure of the original model. Here, the naming of the phases is not vital, and suitable names can be used for the particular project being undertaken.
The waterfall model retains that system and should move to the next phase only when it’s previous phase is completed and perfected. Thus in the waterfall model each phase in a system development life cycle is seen as part of an irreversible succession of events. One phase cannot commence until the previous step has ended. Once a step has been started, there is no reverse back to a prior step.
For instance, “detail design” cannot start until “outline design” has been finished, and program “coding” cannot begin until “detail design” has been completed.
Phases of development in the waterfall model are thus discrete, and there is no leaping back and forth or overlap between different phases.
Appreciations and Criticism of the waterfall model:
Appreciations:
The waterfall model provides a clear and easy to follow sequence of activities; it is simple and can be understood without many complications. Furthermore, particular issues on quality management are addressed through the Justification and Confirmation section that is being followed in each phase of the model, and in addition to this, this model will facilitate project management and control by the need to complete each stage before moving to the succeeding phase.
Criticism:
The waterfall model lacks prescribed technique of implementing management control over a project; planning, controlling, and risk management are not enveloped within the model itself. Moreover, forecasting the estimated time and cost are complicated for each stage. The life cycle can take long as the original requirements may no longer be valid, with little possibility for prototyping.
The waterfall model of system development works best when any reworking of products is kept to a minimum and the products remain unchanged. It still remains useful for steady and non-volatile types of projects, and if properly implemented, generates significant cost and timesaving. If the system is likely to go through significant changes and if the system requirements are unpredictable then different approaches are recommended, one such alternate approach is popularly know as the spiral model.
