©ian sommerville 1995 software engineering, 5th edition. chapter 31 slide 1 process improvement u...

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31 Slide 1

Process Improvement

Understanding, Modelling and Improving the Software Process


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

Process improvement stages


The process improvement process

Processmodel

Process changeplan

Trainingplan

Feedback onimprovements

Revised processmodel

Analyseprocess

Identifyimprovements

Tuneprocess changes

Introduceprocess change

Trainengineers


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

Productquality

Developmenttechnology

Cost, time andschedule

Processquality

Peoplequality


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


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.

Software process model elements


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


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

Goal-Question-Metric Paradigm


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


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.

CMM - Process model


The SEI process maturity model

Level 3Defined

Level 2Repeatable

Level 1Initial

Level 4Managed

Level 5Optimizing


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 areasProcess change managementTechnology change managementDefect prevention

Software quality managementQuantitative process management

Peer reviewsIntergroup coordinationSoftware product engineeringIntegrated software managementTraining programmeOrganization process definitionOrganization process focus

Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking and oversightSoftware project planningRequirements management

Initial

Repeatable

Defined

Managed

Optimizing

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ##

Key process areas - level 2

I n it i al


Software Configuration ManagementSoftware Quality AssuranceSoftware project planningRequirements managementSoftware Project tracing and oversightSoftware 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 tS o f tw a r e q u a l it y a s su r a n c eS o f tw a r e s u b c o n tr a c t m a n a g em e n tS o f t w a r e p ro je c t tr a c k i n g a n d o ve r sig h tS o f t w a r e p ro je c t p l a n n in gR e q u ir e m e n ts m a n a ge m e n t

I n it i al

R e p e at ab l e

M a n ag ed

O p t i m iz i n g


Peer reviewsTraining programOrganization process focus

Software quality management

Process change managementTechnology change management


Focuses on project management rather than product

development.

Ignores use of technologies such as rapid prototyping.

Does not incorporate risk analysis as a key process area

No marketing issues

SEI model problems

©ian sommerville 1995 software engineering, 5th edition. chapter 31 slide 1 process improvement u...

Documents