What is the Waterfall Model?

The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through several phases. History of the Waterfall Model In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a model which he argued was flawed (Royce 1970). His paper then explored how the initial model could be developed into an iterative model, with feedback from each phase influencing previous phases, similar to many methods used widely and highly regarded by many today. Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative. Usage of the waterfall model In Royce's original waterfall model, the following phases are followed perfectly in sequential order: Requirements specification Requirements are captured and set in stone. Design A "blueprint" is drawn up for the developers to implement. Implementation Integration Testing Installation Maintenance The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged. Criticism of the waterfall model The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front". In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows: Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases. Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases. Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client. It is difficult to estimate time and cost for each phase of the development process. The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself. Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.