Process Improvement
Trang 1©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 1
Process Improvement
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 2
improvement
influence software quality and productivity
software processes
and the CMMI process improvement model
Objectives
Topics covered
Trang 2©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 4
introducing process changes to improve product quality, reduce costs or accelerate schedules
focused on defect reduction This reflects the increasing attention paid by industry to quality
be the focus of improvement
Process improvement
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 5
Process attributes
Process
characteristic
Description
Understandability To what extent is the process explicitly defined and how easy is it t o
understand the process definition?
Visibility Do the process activities culminate in clear results so that the progress
of the process is externally visible?
Supportability To what extent can CASE tools be used to support the process
activities?
Acceptability Is t he defined process acceptable to and usable by the engineers
responsi ble for producing the software product?
Reliability Is the process designed in such a way that process errors are avoided or
trapped before they result in product errors?
Robustness Can the process continue in spite of unexpected problems?
Maintainability Can the process evolve to reflect changing organisational requirements
or identified process improvements?
Rapidity How fast can the process of delivering a sys tem from a given
specification be completed?
The process improvement cycle
Analyse Measure
Change
Trang 3©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 7
measured These are a baseline for
assessing improvements
bottlenecks and weaknesses are identified
identified during the analysis are introduced
Process improvement stages
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 8
related and process improvement benefits arise because the quality of the product depends on its development process
good product
principal quality determinant
involved especially the capabilities of the designers
Process and product quality
Principal product quality factors
Product quality
De velopment technolo gy
Cost, time and schedule
Process
quality
People quality
Trang 4©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 10
Quality factors
the development process determines product quality
developers is the main determinant
significant for small projects
imposed then product quality will suffer
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 11
their own way of working.
process.
as the RUP.
Process classification
Process applicability
Prototypes Shor t-lifetime systems 4GL b usiness systems Small/medium-sized systems
Infor mal
process
Large systems Long-lifetime pr oducts Mana ged
process
Well-understood applica tion domains Re-eng ineer edsystems Methodical
process
Trang 5©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 13
product which is being developed
problem so you need a strictly managed process;
should be standardised within an organisation
process on a development team;
to reduced quality.
Process choice
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 14
Process tool support
Informal
process
Mana ged
process
Methodical process
Impr o ving process
Specialis ed tools Analysis and design wor kbenches
Pr oject mana gement tools Configur ation
mana gement
tools
Generic
tools
should be collected
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.
assess process improvements
the improvements The improvement driver should be the organizational objectives.
Process measurement
Trang 6©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 16
completed
activity or process
activities
Classes of process measurement
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 17
objective of process improvement is to satisfy these goals
the goals You need process knowledge to derive these
questions
Goal-Question-Metric Paradigm
Process analysis and modelling
the relationships between parts of the process and to compare them with other processes
the tasks, the roles and the entities used;
different perspectives
Trang 7©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 19
activities
You should normally represent this
graphically Several different views (e.g activities, deliverables, etc.) may be required
problems This involves discussing process activities with stakeholders and discovering problems and possible process changes
Process analysis and modelling
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 20
standards
model People then may extend and change this.
they think you want to hear.
Best for in-depth analysis of process fragments rather than for whole-process understanding.
Process analysis techniques
Process model elements 1
Activity
(shown as a round-edged
rectangle with no drop
shadow)
An activity has a clearly defined objective, entry and exit conditions Examples of activities are preparing a set of test data to test a module, coding a fu nction or a module, proof-reading a responsibility of one person or group It is not decomposed into sub-activities.
Process
(shown as a round-edged
rectangle with drop
shadow)
A p rocess is a set of activities which have some coherence and whose objective is generally agreed within an organisation Examples of processes are requirements analysis, architectural design, test planning, etc.
Deliverable
(shown as a rectangle with
drop shadow)
A deliverable is a tangible output of an activity that is predicted in a project plan.
Condition
(shown as a parallelogram )
A condition is either a p re-condition that must hold before a process
or activity can start or a post-condition that holds after a p rocess or activity has finished.
Trang 8©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 22
Process model elements 2
Role
(shown as a circle with
drop shadow)
A role is a b ounded area of responsibility Examples of roles might person may have several different roles and a s ingle role may be associated with several different people.
Exception
(not shown in examples
here but may be
represented as a double
edged box)
An exception is a description of how to modify the process if some undefined and it i s left to the ingenuity of the project managers and enginee rs to handle the exception.
Communication
(shown as an arrow)
An interchange of information between people or between people and supporting computer systems Commu nications may be informal or formal Formal communications might be the approval
of a deliverable by a p roject manager; informal communications
a document.
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 23
The module testing activity
Test module
Signed-of f test recor d
Module test data Module
specifica tion
Module compiles
without syntax
errors
All defined tests run on module Test
eng ineer Pre-condition
Input
Process
Role
Post-condition
Outputs Responsib le
for
Activities in module testing
Prepar e test da ta
accor ding to
Read module
specifica tion
Submit test da ta for review Review test da ta TEST DATA P REPARATION
Read and understand
module inter face
Checkout module
from configur ation
mana gement system
Prepar etestharness for module
Compile test harness MODULE TEST HARNESS PR EPARATION
Incorpor ate module
with test harness
Run a ppro ved tests
on module
Recor d test r esults forr eg ressiontests TEST EXECUTION
Write repor t on module
testing including details
of disco vered pr ob lems
Submit r epor t for appr o val
Submit test results to CM TEST REPORTING
Trang 9©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 25
Process exceptions
models cannot effectively represent how to handle exceptions:
review;
communications are out of action for several days;
proposals.
and managers use their initiative to deal with the exception
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 26
Process change
processes
processes;
goals
The process change process
Process
model
Pr ocess change
plan
Training plan Feedback on impr o vements
Revised pr ocess model
Identify
improvements
Prioritise impr ovements
Tune process changes
Introduce process change
Train eng ineers
Trang 10©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 28
Process change stages
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 29
The CMMI framework
process assessment and improvement that started
at the Software Engineering Institute in the 1980s
transfer particularly to US defence contractors
improvement
Process capability assessment
which an organisation’s processes follow best practice
possible to identify areas of weakness for process improvement
assessment and improvement models but the SEI work has been most influential
Trang 11©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 31
and used
The SEI capability maturity model
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 32
Problems with the CMM
at the same time but if all practices from a lower level were not used, it was not possible to move beyond that level
bottom of levels
rather than the goals to be achieved.
The CMMI model
software and systems engineering capability assessment
of capability levels;
computed
Trang 12©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 34
CMMI model components
and improvement are identified These are organised into
4 groups.
Each process area has associated goals.
are advisory and other approaches to achieve the goal may be used.
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 35
CMMI process areas 1
Process management Organisational process definition
Organisational process focus Organisational training Organisational process performance Organisational innovation and deployment Project management Project planning
Project monitoring and control Supplier agreement management Integrated project management Risk management Integrated teaming Quantitative project management
CMMI process areas 2
Engineering Requirements management
Requirements development
Technical solution
Product integration
Verification
Validation
Support Configuration management
Process and product quality management
Measurement and analysis
Decision analys is and resolution
Organisational environment for integration
Causal analysis and resolution
Trang 13©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 37
CMMI goals
Corrective actions are managed to
closure when the projectÕs performance
plan.
Specific goal in Project Monitoring and Control
Actual performance and progress of the
project is monitored against the project
plan.
Specific goal in project monitoring and control
The requirements are analysed and
validated and a definition of the required
functionality is deve loped
Specific goal in requirements deve lopment.
Root causes of de fects and other
problems are systematically determined.
Specific goal in causal analysis and resolution.
The process is institutionalised as a
defined p rocess.
Gene ric goal
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 38
CMMI practices
Analyse derived requirements to ensure that they are
necessary and sufficient
Validate requirements to ensure that the resulting
product will perform as intended in the userÕs
environment using multiple techniques as
appropriate.
The requirements are analysed and validated and a definition of the required functionality is developed.
Select the defects and other problems for analysis.
Perform causal analysis of selected defects and other
problems and propose actions to address them.
Root causes of defects and other problems are systematically determined.
Establish and maintain an organisational policy for
planning and performing the requirements
development process.
Assign responsibility and authority for performing
the process, developing the work products and
providing the services of the requirements
development process.
The process is institutionalised as a defined process.
CMMI assessment
and assesses their maturity in each process area
Trang 14©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 40
The staged CMMI model
goals For example, the process area associated with the managed level include:
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 41
The staged CMMI model
Level 3 Defined
Level 2
Managed
Level 1
Initial
Level 4 Quantitatively managed
Level 5 Optimizing
Institutional practices
should have institutionalised practices that are geared to standardisation
project management process;
project management process;
process;
project planning process
Trang 15©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 43
The continuous CMMI model
or groups of practices and assesses their use
a set of values showing the organisations maturity in each area
5
organisations can pick and choose process areas to improve according to their local needs
©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 44
A process capability profile
Project monitoring
and control
Supplier ag reement
management
Risk
management
Configuration
management
Requirements
management
Verification
Validation
standardisation, measurement and change
methodical and improving This classification can be used to identify process tool support
measurement, process analysis and process
change
specific process questions, based on organisational improvement goals
Key points
Trang 16©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 46
measurement process are time metrics, resource utilisation metrics and event metrics
activities, roles, exceptions, communications,
deliverables and other processes
and systems engineering process improvement
reaching a set of goals related to good software engineering practice
Key points