©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 1
Process Improvement
Understanding, Modelling and
Improving the Software Process
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 2
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. Reflects increasing
attention paid by industry to quality
Process improvement
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 1995 Software Engineering, 5th edition. Chapter 31 Slide 4
The process improvement process
Process
model Process changeplan Trainingplan improvementsFeedback on Revised processmodel
Analyse
process improvementsIdentify
Tune process changes Introduce process change Train engineers
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 5
Process quality and product quality are closely
related
A good process is usually required to produce a
good product
Process and product quality
Principal product quality factors
Product
quality
Development
technology
Process
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 7
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
Process analysis and modelling
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 8
Activities
• Has clearly defined objective, entry and exit conditions. Often carried out by a single person.
Processes
• Set of activities with some coherence and an agreed objective.
Deliverables
• Tangible output of an activity. Usually a document.
Conditions
• Predicate which must hold either before or after a process or activity.
Software process model elements
Roles
• A bounded area of responsibility. Examples are configuration manager, test engineer, etc.
Exceptions
• An event which requires some special handling and is not processed by normal activities. Usually handled as they arise without a pre-planned strategy.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 10
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
Process measurement
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 11
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
Classes of process measurement
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 1995 Software Engineering, 5th edition. Chapter 31 Slide 13
ISO 9000
Document what are you doing
Do what you have documented to do
You must have a set of documents describing
• Organization
• Documentation Management (similar to configuration management)
• Development and maintenance process • infrastructure support
ISO 9000 certification
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 14
ISO 9000
Can be applied on any type of organization
ISO-9000-3 - is ISO 9000 for the software
production
• Specific issues for software development and maintenance
Capability Maturity Model
US Defense Dept. funded institute associated
with Carnegie Mellon -Software engineering
Institute (SEI)
Mission is to promote software technology
transfer particularly to defense contractors
Maturity model proposed in mid-1980s, refined
in early 1990s.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 16
The SEI process maturity model
Level 3 Defined Level 2 Repeatable Level 1 Initial Level 4 Managed Level 5 Optimizing
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 17
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
Maturity model levels
Key process areas
P r o ce s s c h a n g e m a n a g em e n t T e c h n o l o g y c h a n g e m a n a g em e n t D e f e c t p r e v e n t io n S o f tw a re q u a l it y m a n a g em e n t Q u a nt it a t iv e p r o ce s s m a n a g em e n t P e e r r e v ie w s I n t e r g ro u p c o o r d in at io n S o f tw a r e p r o d u ct e n g i n e e r i n g I n t e g r a t e d s o f tw ar e m a n a g e m e n t T r a i n i n g p r o g r a m m e O r g a n i z a ti o n p r oc e s s d e f in it io n O r g a n i z a ti o n p r oc e s s f o c u s S o f tw a r e c o n f i g u ra t io n m a n a g em e n t R e p e a t a b l e D e f i n e d M a n a g ed O p t i m i zi n g
Key process areas - level 2
I n it i a l
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ##
Software Configuration Management
Software Quality Assurance
Software project planning
Requirements management
Software Project tracing and oversight
Software subcontract management
Key process areas - main characteristics
S o f tw a r e c o n f i g u ra t io n m a n a g em e n t S o f tw a r e q u a l it y a s su r a n c e S o f tw a r e s u b c o n tr a c t m a n a g em e n t S o f tw a r e p ro je c t tr a c k i n g a n d o v e r s ig h t S o f tw a r e p ro je c t p l a n n in g R e q u ir e m e n ts m a n a g e m e n t I n it i a l R e p e a t a b l e M a n a g ed O p t i m i zi n g
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ## Peer reviews
Training program Organization process focus
Software quality management Process change management Technology change management
Focuses on project management rather than product
development.
