Waterfall Model
Waterfall Model
The waterfall model of development is an example of a Software Development Life Cycle (SDLC) model. It is called waterfall because of the way it falls down. This visual aspect is what affects people’s perceptions of what it does and hence how it is implemented. The earliest paper which describes the waterfall is “Managing the Development of Large Software Systems” by Dr. Winston W. Royce published in 1970. However he did not call it the waterfall model and he had several criticisms in using it if it was naively implemented. Instead he was championing the concepts of a sequence of development stages and crucially iterating back to previous stages as more evidence emerged during development.
The waterfall model is an example of a SDLC model. The example model used in this article has seven stages which map to the four SDLC phases.
Decide Phase
The Decide phase of a SDLC is when you decide what it is you want to build as software. In this phase there are three stages:
- Business Case – What the user want to achieve with the software.
- User Requirements – What the software needs to do to achieve the business aim.
- System Specification – What the software need to do in computer terms to meet the user requirements.
Business Case
This is the justification for building the software system and needs to cover a number of areas including:
- What the current business and software situation is.
- What the business opportunity is that the software will solve.
- What the various solution strategies are and their feasibility.
- What the preferred solution strategy is.
- What the costs versus the benefits are.
- What the assumptions, risks, and constraints are likely to be.
- What the outline implementation approach will be.
A considerable amount of work needs to be done by the users with developer input to produce a business case. The benefits of doing so are to give everybody on the project a clear map of where the users are going and why.
User Requirements
The next stage is to define a set of user requirements. These define for the preferred solution strategy what the software system needs to achieve in order to meet the business opportunity. Areas which need to be included are:
- Functional requirements – what does the system need to do e.g. to store details of customer records.
- Non-functional requirements – these come in two types:
- Performance constraints – what performance is required from the system e.g. It will update all customer records overnight.
- Development constraints – what restrictions on development will apply e.g. the system must be available by a certain date.
- Design Objectives – what is the most important features that apply to the system.
More details about these points are on the User Requirements page.
System Specification
The system specification is when the focus changes from the users to the system being developed. It is the logical design of the software system and what it is to achieve. It covers:
- System Processes – what technical process is required to implement each business process.
- External Interfaces – what is required for the system to communicate outside including:
- Transactional interfaces – what is needed to communicate with users e.g. screens.
- Report Interfaces – what types of report are required.
- Application Interfaces – what connections are required to other software systems.
- Non-functional requirements – what the constraints on the system are.
Stage Overlaps
The distinctive feature of all three stages in Decide is they deal with what is wanted. However the boundaries between each of them can overlap.
The user develops both the Business Case and the User Requirements and issues from either can migrate to the other, or even be covered twice. The key point is to ensure that they are covered somewhere.
The boundary between the User Requirement and the System Specification can have a great deal of overlap especially as both are aimed at informing the developers. The key differences between them are:
- The User Requirements are written by the users with developer assistance, whereas the Systems Specification is written by the developers with user assistance.
- The User Requirements expresses the functionality required in terms of what the business wants to achieve, whereas the System Specification expresses the functionality in terms of what a software systems could deliver.
Design Phase
The Design Phase is when the various requirements are mapped to the software environment and implementation decisions are taken. This phase concentrates on how the software will be built. This version of the waterfall model has two stages:
- System Design – how the software will be structured into components.
- Component Design – how a component will be structured.
System Design
The System Design stage takes the System Specification and designs the architecture of the system. This is done by defining a series of components with what they do and how they interact with other components. These components can be other systems, interfaces, modules of code, screens, databases etc. What is not defined is the detail of how each component will work.
Component Design
The Component Design stage is the detail design of how any particular component will work, and communicate it results to other components via its interfaces. There is not likely to be a document covering all component designs as they are designed by different people. In many cases these designs are done by coders themselves.
Develop Phase
The Develop phase is the Component Construction stage in the waterfall model. It deals with building the components required for the software. Software components come in many forms and range from bespoke custom software developed specifically for the system, through to packaged software which is configured to meet the requirements.
There are two main types of package software:
- Commercial Of The Shelf (COTS) – These are packages of applications covering various needs of users which are bought and configured from commercial suppliers.
- Open Source – Again these are various packages of applications but they are maintained by the community of users.
Bespoke software potentially will meet the needs exactly but is expensive to produce. In theory there are cost savings with using packaged software. I say in theory as the installation costs might be less but the cost of running the package over its life may be more.
Demonstrate Phase
The Demonstrate phase is the Test stage and involves proving that the software system meets each of the designs, specifications and requirements in the Decide and Design phases. An explanation of the various types of testing is in the Types of Testing article.
Observations
These seven stages make up the waterfall model as traditionally used, but the flexibility in how it is used affect how successful it is. There are a number of problems with the model which is why it was evolved into the V-Model.
Software Development Life Cycles
- Software Development Life Cycle - the five principles and four basic phases of a Software Development Life Cycle (SDLC).
- From Waterfall model to V-Model - how the V-Model is derived from the waterfall model.