Page 48 -

2.1 Software process models 31

The principal stages of the waterfall model directly reflect the fundamental devel-
opment activities:

1. Requirements analysis and definition The system’s services, constraints, and
goals are established by consultation with system users. They are then defined
in detail and serve as a system specification.
2. System and software design The systems design process allocates the require-
ments to either hardware or software systems by establishing an overall system
architecture. Software design involves identifying and describing the fundamen-
tal software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is real-
ized as a set of programs or program units. Unit testing involves verifying that
each unit meets its specification.
4. Integration and system testing The individual program units or programs
are integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to
the customer.
5. Operation and maintenance Normally (although not necessarily), this is the
longest life cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are discovered.

In principle, the result of each phase is one or more documents that are approved
(‘signed off’). The following phase should not start until the previous phase has fin-
ished. In practice, these stages overlap and feed information to each other. During
design, problems with requirements are identified. During coding, design problems
are found and so on. The software process is not a simple linear model but involves
feedback from one phase to another. Documents produced in each phase may then
have to be modified to reflect the changes made.
Because of the costs of producing and approving documents, iterations can be
costly and involve significant rework. Therefore, after a small number of iterations,
it is normal to freeze parts of the development, such as the specification, and to con-
tinue with the later development stages. Problems are left for later resolution,
ignored, or programmed around. This premature freezing of requirements may mean
that the system won’t do what the user wants. It may also lead to badly structured
systems as design problems are circumvented by implementation tricks.
During the final life cycle phase (operation and maintenance) the software is put
into use. Errors and omissions in the original software requirements are discovered.
Program and design errors emerge and the need for new functionality is identified.
The system must therefore evolve to remain useful. Making these changes (software
maintenance) may involve repeating previous process stages.