Chapter 2 – Software Processes

Lecture 2

Chapter 2 Software Processes 1

Topics covered

 Software process models

 Process activities
 Coping with change

Chapter 2 Software Processes 2

The software process

 A structured set of activities required to develop a

software system.
 Many different software processes but all involve:
▪ Specification – defining what the system should do;
▪ Design and implementation – defining the organization of the
system and implementing the system;
▪ Validation – checking that it does what the customer wants;
▪ Evolution – changing the system in response to changing
customer needs.
 A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
Chapter 2 Software Processes 3
Software process descriptions

 When we describe and discuss processes, we usually

talk about the activities in these processes such as
specifying a data model, designing a user interface, etc.
and the ordering of these activities.
 Process descriptions may also include:
▪ Products, which are the outcomes of a process activity;
▪ Roles, which reflect the responsibilities of the people involved in
the process;
▪ Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.

Chapter 2 Software Processes 4

Plan-driven and agile processes

 Plan-driven processes are processes where all of the

process activities are planned in advance and progress
is measured against this plan.
 In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
 In practice, most practical processes include elements of
both plan-driven and agile approaches.
 There are no right or wrong software processes.

Chapter 2 Software Processes 5

Software process models

 The waterfall model

▪ Plan-driven model. Separate and distinct phases of specification
and development.
 Incremental development
▪ Specification, development and validation are interleaved. May
be plan-driven or agile.
 Reuse-oriented software engineering
▪ The system is assembled from existing components. May be
plan-driven or agile.
 In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
Chapter 2 Software Processes 6
Software specification

 The process of establishing what services are required

and the constraints on the system’s operation and
development.
 Requirements engineering process
▪ Feasibility study
• Is it technically and financially feasible to build the system?
▪ Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
▪ Requirements specification
• Defining the requirements in detail
▪ Requirements validation
• Checking the validity of the requirements

Chapter 2 Software Processes 7

The requirements engineering process

Chapter 2 Software Processes 8

Software design and implementation

 The process of converting the system specification into

an executable system.
 Software design
▪ Design a software structure that realises the specification;
 Implementation
▪ Translate this structure into an executable program;
 The activities of design and implementation are closely
related and may be inter-leaved.

Chapter 2 Software Processes 9

A general model of the design process

Chapter 2 Software Processes 10

Design activities

 Architectural design, where you identify the overall

structure of the system, the principal components
(sometimes called sub-systems or modules), their
relationships and how they are distributed.
 Interface design, where you define the interfaces
between system components.
 Component design, where you take each system
component and design how it will operate.
 Database design, where you design the system data
structures and how these are to be represented in a
database.
Chapter 2 Software Processes 11
Software validation

 Verification and validation (V & V) is intended to show

that a system conforms to its specification and meets the
requirements of the system customer.
 Involves checking and review processes and system
testing.
 System testing involves executing the system with test
cases that are derived from the specification of the real
data to be processed by the system.
 Testing is the most commonly used V & V activity.

Chapter 2 Software Processes 12

Stages of testing

Chapter 2 Software Processes 13

Testing stages

 Development or component testing

▪ Individual components are tested independently;
▪ Components may be functions or objects or coherent groupings
of these entities.
 System testing
▪ Testing of the system as a whole. Testing of emergent properties
is particularly important.
 Acceptance testing
▪ Testing with customer data to check that the system meets the
customer’s needs.

Chapter 2 Software Processes 14

Software evolution

 Software is inherently flexible and can change.

 As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
 Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.

Chapter 2 Software Processes 15

System evolution

Chapter 2 Software Processes 16

Coping with change

 Change is inevitable in all large software projects.

▪ Business changes lead to new and changed system
requirements
▪ New technologies open up new possibilities for improving
implementations
▪ Changing platforms require application changes
 Change leads to rework so the costs of change include
both rework (e.g. re-analysing requirements) as well as
the costs of implementing new functionality

Chapter 2 Software Processes 17

Reducing the costs of rework

 Change avoidance, where the software process includes

activities that can anticipate possible changes before
significant rework is required.
▪ For example, a prototype system may be developed to show
some key features of the system to customers.
 Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
▪ This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have
not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change.

Chapter 2 Software Processes 18

 Software prototyping : A prototype is an initial version of
a system used to demonstrate concepts and try out
design options.
 Throw-away prototypes : Prototypes should be discarded
after development as they are not a good basis for a
production system
 Incremental delivery : The development and delivery is
broken down into increments with each increment
delivering part of the required functionality.
 Boehm’s spiral model: Process is represented as a spiral
rather than as a sequence of activities with backtracking.
Chapter 2 Software Processes 19
Boehm’s spiral model of the software process

Chapter 2 Software Processes 20

Key points

 Processes should include activities to cope with change.

This may involve a prototyping phase that helps avoid
poor decisions on requirements and design.
 Processes may be structured for iterative development
and delivery so that changes may be made without
disrupting the system as a whole.

Chapter 2 Software Processes 21