Waterfall is a classic product development model. American information scientist Winston Walker Royce invented and described it back in 1970, and in 1976 scientists Thomas Bell and Thomas Thayer gave it its name. At first Waterfall was used in the creation of any software, but then the Agile model came along and Waterfall dried up. Now the cascade model is used in the aircraft industry, military or space industries, medicine, and the financial sector. That’s where Waterfall belongs, because these industries need clear processes and deadlines, and that’s the essence of cascade. Hence the comparison with a waterfall: each stage of product creation, like a stream of water, continues the previous one and cannot begin until the previous one is over.
In the original homogeneous IPs, each application was a single entity. The cascade method was used to develop this type of application. Its main characteristic is that the entire development is divided into stages, and the transition from one stage to the next occurs only after the current stage has been fully completed. Each stage ends with the issuance of a complete set of documentation sufficient to enable the development to be continued by the team of specialists in the next stage.
The advantages of the cascade approach are as follows:
Cascade approach has proven itself in the construction of the IS, for which at the beginning of development can be accurately and completely formulate all the requirements to give developers the freedom to implement them as best as possible from a technical point of view. This category includes complex calculation systems, real-time systems and other similar tasks. However, in the process of using this approach, a number of its drawbacks were revealed, caused primarily by the fact that the real software creation process never fully fit into such a rigid scheme. In the process of software creation there was a constant need to go back to the previous stages and to clarify or revise the decisions made earlier.
The main disadvantage of the cascade approach is the considerable delay in obtaining the results. Coordination of the results with users is performed only at the points planned after completion of each stage of work, the requirements to the IS are “frozen” in the form of technical specifications for the whole time of its creation. Thus, users can make comments only after the work on the system is fully completed. In the case of an inaccurate statement of requirements or their changes during the long period of software creation, users receive a system that does not meet their needs. Models (both functional and informational) of the object to be automated may become obsolete at the same time as they are approved.