The Waterfall Model In Software Engineering

What is the waterfall model?

The waterfall model is a software development methodology strategy which relies on following a set sequence of actions from top to bottom in the form of a waterfall. Its stages are closely aligned with the software development life cycle (SDLC) from which it evolved.

First trickle of the waterfall model

The first elements of the waterfall model were identified as the ‘simpler method’ by Winston Royce in his 1970 article ‘Managing and Development of Large Software Systems’ (Proceedings of IEEE WESCON 26 (August) 1-9). In this treatise on how to manage large software projects he describes an idealised process (the ‘simpler method’), but dismisses it as too risky for such projects and suggested alterations, which are in fact iteration, to make it more workable. However this ‘simpler’ version has taken root as ‘waterfall’. It has been suggested that Royce took some of his ideas from the earlier work of Bennington and Hosier, and that Royce never called this system ‘waterfall’. The first mention of the name ‘waterfall’ appears to have been in a 1976 paper by Bell and Thayer, in which they say that ‘Royce …..introduced the concept of the “waterfall” of development activities’ (Bell, Thomas E., and Thayer T.A. ‘Software requirements: are they really a problem?’ Proceedings of the 2nd international conference on Software engineering IEEE Computer Society Press 1976).

The waterfall model description

The ‘waterfall’ concept, as the name implies, describes the downward flow of sequential actions in this model. Just like a run of pools of water, where each pool is at a lower level than the previous one, and each pool fills with water until it overflows so that the water flows down to the next pool, movement of the project down to the next step can only occur when the previous action has been fulfilled and signed off.

The stages in the model are:

1. The define stage
The requirements and functional specification are signed off.

2. The design stage
The design specification is signed off

3. The development stage
The coding is completed

4. The testing stage
Test cases are run and signed off

5. The deployment stage

In the waterfall model there is a high reliance on documentation.

• In the define stage a very detailed functional specification is produced for the project stakeholders. This document contains all the minutiae of information about the project from how the design satisfies the business requirements to how the whole system works, including all the system interactions. This document is the basis for all future development, and encompasses what the application should do. Next, system analysis is undertaken to create models and identify the business logic to be included.
• In the design stage the technical aspects of the design are set out, and the specification is written to outline how the business logic, identified in the define stage, will be addressed.
• In the development stage the source code is written for all the integrations, models and business logic which were identified in the earlier stages.
• In the testing stage quality assurance is focused on process improvements; beta testing is undertaken, and other testing used to identify issues which need to be resolved. This might necessitate a partial repeat of the development coding stage to resolve issues.
• In the deployment stage the application is deployed to a live environment, and support and maintenance are provided.

The waterfall model in software engineering

The waterfall model has now somewhat fallen out of fashion because of its largely inflexible methodology. By defining the parameters of the product at the beginning of the process it does not lend itself to the more flexible modern practises of agile working. However, it has remained as a common methodology in the industry, and is a often a first choice for some large organisations and for some large projects where close control over the stages and deadlines is seen as desirable.

Iterative waterfall model

This might seem like a contradiction in terms since the whole premise of waterfall is that once a stage is completed it is rarely revisited, and the onus on the waterfall model is to get the stage right the first time.

However an amalgam of waterfall and the iterative model is sometimes used, and, to a certain extent, it can work, particularly when the stage immediately prior to the current stage is revisited. Conventional waterfall can be risky and costly, but the risks can be offset to some extent by incorporating a limited iterative process. Where this has been tried the focus has been on providing sprints of work, but difficulties can arise due to a log-jam at the testing stage so that the sprint deadline is missed. Also it is difficult to estimate time allocations for different stages in this model because stages, such as development and testing, are interdependent. Thus if a problem is found in testing you have to go back to development to resolve it. For this hybrid model to work the team has to maintain focus on the final goal rather than the individual stages.

Benefits of the waterfall model

• It provides a disciplined environment and utilises detailed planning to control every part of the project, from its initial specification to its deployment.
• Alterations can be made to the specification at an early stage. If this is done well, with the collaboration of the clients and the development team, it can avoid potentially costly interventions in the coding and deployment stages.
• It lends itself to being easier than some other methodologies to control. Timelines can be drawn and milestones established so that the whole team is aware of what needs to be done and when.
• The production of the detailed functional specification up-front allows newcomers to the team to fit in easily and to quickly understand the project’s direction and progress.

Drawbacks of the waterfall model

• The model does not easily allow for changes at any stage beyond the define stage. Changes can obviously be made by stepping back temporarily to an earlier stage, but this could prove costly and disruptive. In the case of a serious problem being encountered at the testing stage it may jeopardise the entire project. Similarly, if the client wishes to add further requirements at a later stage in the project, this is not easily accommodated.
• Since the testing is all done in one stage, at a point where the project is well advanced, any major problems or errors found in the system at this stage will inevitably impact on smooth flow of the waterfall. This contrasts considerably with the modern view that testing should be an integral part of the methodology.
• The whole model is heavily reliant on the functional specification. If there is an error here or the specification does not cater for a situation which arises down the line, the whole project may result in disaster.
• The model is very reliant on effective managers driving the project by controlling the timeline and the arrival at milestones.