2.
1 ■ Software process models 47
can be instantiated in different ways to create processes that resemble any of the
general process models discussed here. The RUP has been adopted by some large
software companies (notably IBM), but it has not gained widespread acceptance.
2.1.1 The waterfall model
The first published model of the software development process was derived from
engineering process models used in large military systems engineering (Royce
1970). It presents the software development process as a number of stages, as shown
in Figure 2.1. Because of the cascade from one phase to another, this model is known
as the waterfall model or software life cycle. The waterfall model is an example of a
plan-driven process. In principle at least, you plan and schedule all of the process
activities before starting software development.
The stages of the waterfall model directly reflect the fundamental software
development 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 requirements
to either hardware or software systems. It establishes an overall system
architecture. Software design involves identifying and describing the fundamental
software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is realized as
a set of programs or program units. Unit testing involves verifying that
each unit meets its specification.
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
Figure 2.1 The maintenance
waterfall model
48 Chapter 2 ■ Software processes
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, this is the longest life-cycle phase. The
system is installed and put into practical use. Maintenance involves correcting
errors that 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 in the waterfall model is one or more documents
that are approved (“signed off”). The following phase should not start until
the previous phase has finished. For hardware development, where high
manufacturing costs are involved, this makes sense. However, for software
development, 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, in practice, is never a simple linear model but involves
feedback from one phase to another.
As new information emerges in a process stage, the documents produced at previous
stages should be modified to reflect the required system changes. For example,
if it is discovered that a requirement is too expensive to implement, the requirements
document should be changed to remove that requirement. However, this requires
customer approval and delays the overall development process.
As a result, both customers and developers may prematurely freeze the software
specification so that no further changes are made to it. Unfortunately, this means that
problems are left for later resolution, ignored, or programmed around. 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.
Boehm’s spiral process model
Barry Boehm, one of the pioneers in software engineering, proposed an incremental process model that was
risk-driven. The process is represented as a spiral rather than a sequence of activities (Boehm 1988).
Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be
concerned with system feasibility, the next loop with requirements definition, the next loop with system
design,
and so on. The spiral model combines change avoidance with change tolerance. It assumes that changes are
a result of project risks and includes explicit risk management activities to reduce these risks.
[Link]
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.
In reality, software has to be flexible and accommodate change as it is being
developed. The need for early commitment and system rework when changes are
made means that the waterfall model is only appropriate for some types of system:
1. Embedded systems where the software has to interface with hardware systems.
Because of the inflexibility of hardware, it is not usually possible to delay decisions
on the software’s functionality until it is being implemented.
2. Critical systems where there is a need for extensive safety and security analysis
of the software specification and design. In these systems, the specification and
design documents must be complete so that this analysis is possible. Safetyrelated
problems in the specification and design are usually very expensive to
correct at the implementation stage.
3. Large software systems that are part of broader engineering systems developed
by several partner companies. The hardware in the systems may be developed
using a similar model, and companies find it easier to use a common model for
hardware and software. Furthermore, where several companies are involved,
complete specifications may be needed to allow for the independent development of
different subsystems.
The waterfall model is not the right process model in situations where informal
team communication is possible and software requirements change quickly. Iterative
development and agile methods are better for these systems.
An important variant of the waterfall model is formal system development, where
a mathematical model of a system specification is created. This model is then refined,
using mathematical transformations that preserve its consistency, into executable
code. Formal development processes, such as that based on the B method (Abrial
2005, 2010), are mostly used in the development of software systems that have
stringent safety, reliability, or security requirements. The formal approach simplifies
the
production of a safety or security case. This demonstrates to customers or regulators
that the system actually meets its safety or security requirements. However, because
of the high costs of developing a formal specification, this development model is
rarely used except for critical systems engineering.
2.1.2 Incremental development
Incremental development is based on the idea of developing an initial implementation,
getting feedback from users and others, and evolving the software through
several versions until the required system has been developed (Figure 2.2).
Specification, development, and validation activities are interleaved rather than
separate, with rapid feedback across activities.
2.1 ■ Software process models 49
