Chapter 2

Software Process Models

Objectives
Chapter 2 Software Process Models

A software process is a set of related activities that leads to the production of a software
product. These activities may involve the development of software from scratch in a standard
programming language like Java or C. However, business applications are not necessarily
developed in this way. New business software is now often developed by extending and
modifying existing systems or by configuring and integrating off-the-shelf software or system
components. There are many different software processes but all must include four activities
that are fundamental to software engineering:

1. Software specification: The functionality of the software and constraints on its

operation must be defined.
2. Software design and implementation: The software to meet the specification must be
produced.
3. Software validation: The software must be validated to ensure that it does what the
customer wants.
4. Software evolution: The software must evolve to meet changing customer needs.

In some form, these activities are part of all software processes. In practice, of course, they are
complex activities in themselves and include sub-activities such as requirements validation,
architectural design, unit testing, etc. There are also supporting process activities such as
documentation and software configuration management.
A software process model is a simplified representation of a software process. Each
process model represents a process from a particular perspective, and thus, provides only partial
information about that process. For example, a process activity model shows the activities and
their sequence but may not show the roles of the people involved in these activities. In this
section, I introduce a number of very general process models.

ENG. SHADA KHANBARI 2020-2021 2

Chapter 2 Software Process Models

1. The waterfall model:

The first published model of the software development process was derived from more general
system engineering processes (Royce, 1970). This model is illustrated 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,
you must plan and schedule all of the process activities before starting work on them.

Figure 2.1: The waterfall model

The principal stages of the waterfall model directly reflect the fundamental development
activities:
1. Requirement’s 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 by establishing 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.

ENG. SHADA KHANBARI 2020-2021 3

Chapter 2 Software Process Models

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. The following
phase should not start until the previous phase has finished. 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 waterfall model is consistent with other engineering process models and
documentation is produced at each phase. This makes the process visible so managers can
monitor progress against the development plan. Its major problem is the inflexible partitioning
of the project into distinct stages. Commitments must be made at an early stage in the process,
which makes it difficult to respond to changing customer requirements.
In principle, the waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development. However, the
waterfall model reflects the type of process used in other engineering projects. As is easier to
use a common management model for the whole project, software processes based on the
waterfall model are still commonly used.

ENG. SHADA KHANBARI 2020-2021 4

Chapter 2 Software Process Models

2. Boehm’s spiral model:

A risk-driven software process framework (the spiral model) was proposed by Boehm (1988).
This is shown in Figure 2.2. Here, the software process is represented as a spiral, rather than a
sequence of activities with some backtracking from one activity to another. 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.

Figure 2.2: Boehm’s spiral model of the software process

Each loop in the spiral is split into four sectors:

1. Objective setting: Specific objectives for that phase of the project are defined.
Constraints on the process and the product are identified and a detailed management
plan is drawn up. Project risks are identified. Alternative strategies, depending on these
risks, may be planned.

2. Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk
that the requirements are inappropriate, a prototype system may be developed.

ENG. SHADA KHANBARI 2020-2021 5

Chapter 2 Software Process Models

3. Development and validation: After risk evaluation, a development model for the
system is chosen. For example, throwaway prototyping may be the best development
approach if user interface risks are dominant. If safety risks are the main consideration,
development based on formal transformations may be the most appropriate process, and
so on. If the main identified risk is sub-system integration, the waterfall model may be
the best development model to use.

4. Planning: The project is reviewed and a decision made whether to continue with a
further loop of the spiral. If it is decided to continue, plans are drawn up for the next
phase of the project.

The main difference between the spiral model and other software process models is its explicit
recognition of risk. A cycle of the spiral begins by elaborating objectives such as performance
and functionality. Alternative ways of achieving these objectives, and dealing with the
constraints on each of them, are then enumerated. Each alternative is assessed against each
objective and sources of project risk are identified. The next step is to resolve these risks by
information-gathering activities such as more detailed analysis, prototyping, and simulation.
Once risks have been assessed, some development is carried out, followed by a planning
activity for the next phase of the process. Informally, risk simply means something that can go
wrong. For example, if the intention is to use a new programming language, a risk is that the
available compilers are unreliable or do not produce sufficiently efficient object code. Risks
lead to proposed software changes and project problems such as schedule and cost overrun, so
risk minimization is a very important project management activity. Risk management, an
essential part of project management, is covered in Chapter 7.

ENG. SHADA KHANBARI 2020-2021 6