Process Improvement 

● Understanding, Modelling and 
Improving the Software Process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 1

Objectives
● To explain the principles of software process 
improvement
● To explain how software process factors 
influence software quality and productivity
● To introduce the SEI Capability Maturity Model 
and to explain why it is influential. To discuss 
the applicability of that model
● To explain why CMM­based improvement is not 
universally applicable

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 2

Topics covered
● Process and product quality
● Process analysis and modelling
● Process measurement
● The SEI process maturity model
● Process classification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 3

Process improvement
● Understanding existing processes
● Introducing process changes to achieve 
organisational objectives which are usually 
focused on quality improvement, cost reduction 
and schedule acceleration
● Most process improvement work so far has 
focused on defect reduction. This reflects the 
increasing attention paid by industry to quality
● However, other process attributes can be the 
focus of improvement
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 4
Process attributes

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 5

Process improvement stages
● Process analysis
• Model and analyse (quantitatively if possible) existing processes
● Improvement identification
• Identify quality, cost or schedule bottlenecks
● Process change introduction
• Modify the process to remove identified bottlenecks
● Process change training
• Train staff involved in new process proposals
● Change tuning
• Evolve and improve process improvements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 6

An a
lprocyse im Ipd
erovntim
fyentsenT
The process improvement process
I
n
t
r
p
r
o
c
e
s
r
go
ad
u
c
e
 
h
a
n
i
n
e
r
s g pT
r
o
c
e
su
 n
che
a ges
P
rm
ocdesl P
rocespl changeT rpailngiF
em
d
b ac
k
 provem
ontsR
evism
edo pro
cles
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 7
Process and product quality
● Process quality and product quality are closely 
related
● A good process is usually required to produce a 
good product
● For manufactured goods, process is the 
principal quality determinant
● For design­based activity, other factors are also 
involved especially the capabilities of the 
designers

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 8

 P D
e
t
rquoacleistyC v
c
Pl
o
h
n
rosq
o
d
ttc,h aim p
u mc gen
yt P
eople
ldiueyl andquaity
Principal product quality factors

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 9

Quality factors
● For large projects with ‘average’ capabilities, the 
development process determines product quality
● For small projects, the capabilities of the 
developers is the main determinant
● The development technology is particularly 
significant for small projects
● In all cases, if an unrealistic schedule is imposed 
then product quality will suffer

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 10

Process analysis and modelling
● Process analysis
• The study of existing processes to understand the relationships 
between parts of the process and to compare them with other 
processes
● Process modelling
• The documentation of a process which records the tasks, the 
roles and the entities used
• Process models may be presented from different perspectives

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 11

Process analysis and modelling
● Study an existing process to understand its 
activities
● Produce an abstract model of the process. You 
should normally represent this graphically. 
Several different views (e.g. activities, 
deliverables, etc.) may be required
● Analyse the model to discover process 
problems. Involves discussing activities with 
stakeholders

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 12

Process analysis techniques
● Published process models and process 
standards
• It is always best to start process analysis with an existing 
model. People then may extend and change this.
● Questionnaires and interviews
• Must be carefully designed. Participants may tell you what they 
think you want to hear
● Ethnographic analysis
• Involves assimilating process knowledge by observation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 13

Elements of a 
process model
PrM
ew
­ocidond
itu
tholer ctosoym
n
p
i
l
e
s
n
t
a
x R
T
e
s
e
n
g
i
™l
e
t
r P
o
s
t
­
c
o
n
A
l
 
d
e
r
u
n
od
f 
mit
eoon
 
de
s
t
u
l
R
e
s
p
o
fn
rsib
l
e O
u
t
p
u
t
s
The module testing activity

Inp u tspeM
lcifateionP
o d u T
e
s
m
o
dt
u
l
roces MS
i
g
n
e
rd­
c of
rd t
e
s
oduale ts
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 15
TE
 M
 O R
sfD
 m iC S
p
froUe T
a
thm cd
ieLDEmATT
o
a dE uS lP
ne
T R
 HE P
AA RR N AET
I
O
N
P
r
e
c
s
S
 
P
Rp
a
r
e
 
t
o
d
i
f
c
E
P
A
Rs
 
d
a
n
g
o
a
n
A
T
I t
O N Su
b
m
i
t
 
f
o
re
s
t
v
i 
wdat R
e
vi
w
 
t
es
 
d
at
c k o u t  m o d u le R
e
a
d 
n
d  und ers
t and P
r
e pare 
t s  
ha
r
n
e
s C
om
p
i
le
 
t
s
Activities in module testing

 T
ES a
T
 Inw
c n
o rE pg
X m
En
a f
e
C
tei
 g
Um r
s
T
o a
y
I
d t
Oui
o
N
ln
m
e m
o
R
u
n
 l
e
a
p
r
o i
vet
d  tf
e
s ce Re
corf
do
  m
t
es o
 
rd
eu
sl
u
l
t
s h
a
r
n
iT
tE
 WS T h
 toesfridtnR
eg EsP
 srinp Oh R r n
T e
I s
N G om u l f  g i on
cvoelrut doinpgrm
©Ian Sommerville 1995 
 o
ebdtaum
ilesSu
b m
ifor apt rep
o
rvalt reS
sublm
sito eC
sM
t
Software Engineering, 5th edition. Chapter 31.  Slide ##
Process exceptions
● Software processes are complex and process 
models cannot effectively represent how to 
handle exceptions
• Several key people becoming ill just before a critical review
• A complete failure of a communication processor so that no e­
mail is available for several days
• Organisational reorganisation
• A need to respond to an unanticipated request for new 
proposals
● Under these circumstances, the model is 
suspended and managers use their initiative to 
deal with the exception
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 17
Process measurement
● Wherever possible, quantitative process data 
should be collected
• However, where organisations do not have clearly defined 
process standards this is very difficult as you don’t know what 
to measure. A process may have to be defined before any 
measurement is possible
● Process measurements should be used to 
assess process improvements
• But this does not mean that measurements should drive the 
improvements. The improvement driver should be the 
organizational objectives

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 18

Classes of process measurement
● Time taken for process activities to be 
completed
• E.g. Calendar time or effort to complete an activity or 
process
● Resources required for processes or activities
• E.g. Total effort in person­days
● Number of occurrences of a particular event
• E.g. Number of defects discovered

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 19

Goal­Question­Metric Paradigm
● Goals
• What is the organisation trying to achieve? The objective of 
process improvement is to satisfy these goals
● Questions
• Questions about areas of uncertainty related to the goals. You 
need process knowledge to derive these
● Metrics
• Measurements to be collected to answer the questions

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 20

The Software Engineering Institute
● US Defense Dept. funded institute associated 
with Carnegie Mellon
● Mission is to promote software technology 
transfer particularly to defense contractors
● Maturity model proposed in mid­1980s, refined 
in early 1990s.
● Work has been very influential in process 
improvement

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 21

 L
e
v
l
 
4
M
a
n
g
edL
e
v
l
 
O
p
t
i
m
z5
i
n
g
L
e
v
l
 
D
f
i
n
e3
d
The SEI process maturity model

L
eInvitla 1L
e
v
l
 
2
R
p
a
t
be
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 22
Maturity model levels
● Initial
• Essentially uncontrolled
● Repeatable
• Product management procedures defined and used
● Defined
• Process management procedures and strategies defined 
and used
● Managed
• Quality management strategies defined and used
● Optimising
• Process improvement strategies defined and used
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 23
 M a n g e P
T
D
d r of O
c
he
nsp
o
tt
i
m
z
 
c
h
a
n
l
g
y
p
r
e
vi
n
g
e
 
m
c
h
t
i
oa
n
g
e
 g
e
m
a
gn
t
e
m
n
t
Key process areas

iP
eIS
rT
 OnotragfeiwD
g e f
ov un e
w
p
 nratzgea dp d S
Q
s ou f
a
ctirsonogf ptuw t
w
n
rard i
icm
n r
e
a
at
toc eesm q
u
v
igo
n a pl i
rtoy  
m
cesan
g
e
 
m
a
nm
n
g
e
mt
n
t
e
r doecafiunsintm
goent
SR
o
fS
tR
w e
p
a
roefqtuw
 iarm at
cee q
o b
n
fspnu le
irbatsjlceo
gu
rm a
ttyt  pnrslaciguokern im
m a n g e
cng eatnd oversightm n t
In
ital
SEI model problems
● It focuses on project management rather than 
product development. 
● It ignores the use of technologies such as rapid 
prototyping.
● It does not incorporate risk analysis as a key 
process area
● It does not define its domain of applicability

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 25

The CMM and ISO 9000
● There is a clear correlation between the key 
processes in the CMM and the quality 
management processes in ISO 9000
● The CMM is more detailed and prescriptive and 
includes a framework for improvement
● Organisations rated as level 2 in the CMM are 
likely to be ISO 9000 compliant

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 26

Capability assessment
● An important role of the SEI is to use the CMM 
to assess the capabilities of contractors bidding 
for US government defence contracts
● The model is intended to represent organisational 
capability not the practices used in particular 
projects
● Within the same organisation, there are often 
wide variations in processes used
● Capability assessment is questionnaire­based

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 27

S
efIodrelnacstti fp
rey so
jism
eucn
tess quD
The capability assessment process

ieInsttorenrbvuiaetierw
s A
r
e
I
n
t s
en
p
ra
vl
o
iy
s
e
we C
l
a
r
i
r
e
s
p
o
n
I
n
t
e
r
v
if
y
s
e
e
w
fB o
rarnide f m cgaingo n p
ers asPro j c
resm   m a
net Wn g
e
r
s g rs
rite rport m
a
gr
s
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 28
Process classification
● Informal
• No detailed process model. Development team chose their 
own way of working
● Managed
• Defined process model which drives the development 
process
● Methodical
• Processes supported by some development method such 
as HOOD
● Supported
• Processes supported by automated CASE tools

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 29

 IMn
fpaoncrem
agsedl S
h
o
4
G
L r
t
 
L­
b
a P
l
i
u
rr
fs
go
t
e
m
n
e
 
s y
s
yp
e
 
t
e s
r
o
m d
e
sumc
t
s
p
rM oc s L
o
n g­ l
if t
m  
p r
o du c
t
s
Process applicability

eptrhoedsical R
©Ian Sommerville 2000
W e
laep­nigca­u
n de
rtio stm
o d
ayienm
s
Software Engineering, 6th edition. Chapter 25  Slide 30
Process choice
● Process used should depend on type of 
product which is being developed
• For large systems, management is usually the principal problem 
so you need a strictly managed process. For smaller systems, 
more informality is possible.
● There is no uniformly applicable process which 
should be standardised within an organisation
• High costs may be incurred if you force an inappropriate 
process on a development team

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 31

Ipnforcm a
lesC oanftioguelrm
Process tool support

Ma
n
p
r
o
cg
e
d
s
P
rantogjelm
astionm M
e
t
h
p
r
cstnw
A
n
aod oedsic a l I
m
lrkeybsigc ahnedsS p ro
cevi
sng
petcoialszed
G etonlrsicm
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 32
 Key points
● Process improvement involves process analysis, 
standardisation, measurement and change
● Process models include descriptions of tasks, 
activities, roles, exceptions, communications, 
deliverables and other processes
● Measurement should be used to answer specific 
questions about the software process used
● The three types of process metrics which can be 
collected are time metrics, resource utilisation metrics 
and event metrics
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 33
 Key points
● The SEI model classifies software processes as initial, 
repeatable, defined, managed and optimising. It 
identifies key processes which should be used at each of 
these levels
● The SEI model is appropriate for large systems 
developed by large teams of engineers. It cannot be 
applied without modification in other situations
● Processes can be classified as informal, managed, 
methodical and improving. This classification can be 
used to identify process tool support

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 25  Slide 34