Ch25

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 •

●

Improvement identification •

●

Modify the process to remove identified bottlenecks

Process change training •

●

Identify quality, cost or schedule bottlenecks

Process change introduction •

●

Model and analyse (quantitatively if possible) existing processes

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

I n t r o d u c e p r o c e s   h a n g T u n e A lprocyse im n a Ipd erovntim fyentsenT p r o c e s   c h a g e s r a i n g e r s P rm ocdesl P rocespl changeT rpailngiF em  provem d b a c k ontsR evism edo pro cles

The process improvement process

©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

D e v l o p m e n t t c h n g y P rquoacleistyC rosq P ttc,h aim o d u c P e o p l e 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 •

●

Questionnaires and interviews •

●

It is always best to start process analysis with an existing  model. People then may extend and change this. 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

R ™ l e P o s t ­ c o n d i t o n T e s t A l   d e f e   e s t P rM ew ­ocido itu tholer ctosoym n d n e n g i r r u n o   m o d u l p i l e s n t a x R e s p o n s i b l e f r O u t p u t s T e s t S i g n e d ­ o f   t e s m o d u l r c r d In p u tspeM roces M lcifateionP o d u oduale ts The module testing activity

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 25 

Slide 15

 M T E S T D A T   P R E P A R A T I O N P r e p a r e   t s   d a t  O R e a d m o d u l e S u b m i t   e s t   d a t c o d i n g o R e v i w   t e s   d a t sfD iC froU p thm ieL c a n f o r v i w s f c a n  m E T E S T   H A R N E S   P R E P A R A T I O N c k o u t   m o d u l e C o m p i l e   t s P r e p a r e   t s   h a r n e s R e a d   n d   u n d e r s t a n d  T n f i g r a t i o n h a r n f o m o d u l m o l e i t f c e a n g m e s y m E  Inw S T E X E C U T I O N c o r p a t e   m o d u l e R u n   a p r o v e d   t e s R e c o r d   t e s   r e s u l t s iT tE  W h s h r n e s o m u l f   g i o n  toesfridtnR S T E P O R T I N G eg  srinp ifor apt rep u b m rvalt reS o sM t cvoelrut doinpgrm  o ebdtaum ilesS sublm sito eC

Activities in module testing

©Ian Sommerville 1995 

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 •

●

Resources required for processes or activities •

●

E.g. Calendar time or effort to complete an activity or  process 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 •

●

Questions •

●

What is the organisation trying to achieve? The objective of  process improvement is to satisfy these goals 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   5 O p t i m z i n g L e v l   4 M a n g e d L e v l   3 D f i n e d L e v l   2 R p a t b e L eInvitla 1

The SEI process maturity model

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 25 

Slide 22

Maturity model levels ●

Initial •

●

Repeatable •

●

Process management procedures and strategies defined  and used

Managed •

●

Product management procedures defined and used

Defined •

●

Essentially uncontrolled

Quality management strategies defined and used

Optimising •

Process improvement strategies defined and used

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 25 

Slide 23

O p t i m z i n g P r o c e s   c h a n e   m a n g e m n t T h n o l g y c h g e   a g e m n t D f t p r e v t i o M a n g e d S o f t w r e   q u a l i t y   m a n g e m n t Q u a n i a t v p r o c e s   m a n g e m n t iP D e f n e d  O rT eIS v w s no tragfeiw  nratzgea dp g o u ctirsonogf ptuw p rard icm toc eesm n a igo n r doecafiunsintm e goent R e p a t b l e tR fS S roefqtuw o w  iarm a cee q fspnu o irbatsjlceo n rm ttyt  pnrslaciguokern g u a  im m a n g e m n t cng eatnd oversight In ital

Key process areas

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

efIodrelnacstti fp S rey so jism eucn tess quD C l a r i f y ieInsttorenrbvuiaetierw A n a l y s e r e s p o n s e s r e s p o I n t e r v i e w I n t e r v i e w p r o j c   m a n g e r s fB rarnide f m o cgaingo n g r s m a g r s ers asP resm net W rite rport

The capability assessment process

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 25 

Slide 28

Process classification ●

Informal •

●

Managed •

●

Defined process model which drives the development  process

Methodical •

●

No detailed process model. Development team chose their  own way of working

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

P r o t y p e s IM fpaoncrem n agsedl S h o r t ­ l i f e m   r o d u c t s 4 G L   b u s n s e m L a r g e   s y t e m s L o n g ­ l i f t m   p r o d u c t s rM p o c s laep­nigca­u W e rtio stm n d e o d eptrhoedsical R ayienm s

Process applicability

©Ian Sommerville 2000

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 lesC a M a n g e d M e t h o d i c a l I m p r o v i n g p r o c s p r e s c e s rantogjelm P cstnw A aod n lrkeybsigc ahnedsS oanftioguelrm astionm petcoialszed G etonlrsicm

Process tool support

©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