Quality Management: ©ian Sommerville 2004

Quality Management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1

Objectives
To introduce the quality management process and key

quality management activities
To explain the role of standards in quality management
To explain the concept of a software metric, predictor
metrics and control metrics
To explain how measurement may be used in assessing
software quality and the limitations of software
measurement

Topics covered
Process and product quality

Quality assurance and standards
Quality planning
Quality control

Software quality management
Concerned with ensuring that the required level

of quality is achieved in a software product.
Involves defining appropriate quality standards
and procedures and ensuring that these are
followed.
Should aim to develop a ‘quality culture’ where
quality is seen as everyone’s responsibility.

What is quality?
Quality, simplistically, means that a product should meet

its specification.
This is problematical for software systems
There is a tension between customer quality requirements
(efficiency, reliability, etc.) and developer quality requirements
(maintainability, reusability, etc.);
Some quality requirements are difficult to specify in an
unambiguous way;
Software specifications are usually incomplete and often
inconsistent.

The quality compromise
We cannot wait for specifications to improve

before paying attention to quality management.
We must put quality management procedures
into place to improve quality in spite of imperfect
specification.

Scope of quality management
Quality management is particularly important for

large, complex systems. The quality
documentation is a record of progress and
supports continuity of development as the
development team changes.
For smaller systems, quality management
needs less documentation and should focus on
establishing a quality culture.

Quality management activities
Quality assurance
Establish organisational procedures and standards for quality.
Quality planning
Select applicable procedures and standards for a particular project
and modify these as required.
Quality control
Ensure that procedures and standards are followed by the software
development team.
Quality management should be separate from project
management to ensure independence.

Quality management and software development
Software development
D1 D2 D3 D4 D5
process
Quality management
process
Standards and Quality Quality review repor

ts
procedures plan

Process and product quality
The quality of a developed product is influenced

by the quality of the production process.
This is important in software development as
some product quality attributes are hard to
assess.
However, there is a very complex and poorly
understood relationship between software
processes and product quality.

Process-based quality
There is a straightforward link between process and

product in manufactured goods.
More complex for software because:
The application of individual skills and experience is particularly
imporant in software development;
External factors such as the novelty of an application or the need for
an accelerated development schedule may impair product quality.
Care must be taken not to impose inappropriate process

standards - these could reduce rather than improve the
product quality.

Process-based quality
Develop Assess pr
oduct
Define pr
ocess
product quality
No Yes
Improve Quality Standardise
process OK process

Practical process quality
Define process standards such as how reviews

should be conducted, configuration
management, etc.
Monitor the development process to ensure
that standards are being followed.
Report on the process to project management
and software procurer.
Don’t use inappropriate practices simply
because standards have been established.

Quality assurance and standards
Standards are the key to effective quality

management.
They may be international, national,
organizational or project standards.
Product standards define characteristics that all
components should exhibit e.g. a common
programming style.
Process standards define how the software
process should be enacted.

Importance of standards
Encapsulation of best practice- avoids

repetition of past mistakes.
They are a framework for quality assurance
processes - they involve checking compliance
to standards.
They provide continuity - new staff can
understand the organisation by understanding
the standards that are used.

Product and process standards

Problems with standards
They may not be seen as relevant and up-to-

date by software engineers.
They often involve too much bureaucratic form
filling.
If they are unsupported by software tools,
tedious manual work is often involved to
maintain the documentation associated with the
standards.

Standards development
Involve practitioners in development. Engineers should

understand the rationale underlying a standard.
Review standards and their usage regularly.
Standards can quickly become outdated and this
reduces their credibility amongst practitioners.
Detailed standards should have associated tool
support. Excessive clerical work is the most
significant complaint against standards.

ISO 9000
An international set of standards for quality

management.
Applicable to a range of organisations from
manufacturing to service industries.
ISO 9001 applicable to organisations which
design, develop and maintain products.
ISO 9001 is a generic model of the quality
process that must be instantiated for each
organisation using the standard.

ISO 9001

ISO 9000 certification
Quality standards and procedures should be

documented in an organisational quality
manual.
An external body may certify that an
organisation’s quality manual conforms to ISO
9000 standards.
Some customers require suppliers to be ISO
9000 certified although the need for flexibility
here is increasingly recognised.

ISO 9000 and quality management
ISO 9000
quality models
instantia
ted as
documents
Organisation Organisation
quality manual quality pr
ocess
is used to de
velop instantia
ted as
Project 1 Project 2 Project 3 Project quality

quality plan quality plan quality plan management
Supports

Documentation standards
Particularly important - documents are the tangible

manifestation of the software.
Documentation process standards
Concerned with how documents should be developed, validated
and maintained.
Document standards
Concerned with document contents, structure, and appearance.
Document interchange standards

Concerned with the compatibility of electronic documents.

Documentation process
Incorporate
Create Review Re-draft
review
initial draft draft document
comments
Stage 1:
Creation Approved document
Proofread Produce Check

text final draft final draft
Stage 2:
Polishing Approved document
Layout Review Produce Print

text layout print masters copies
Stage 3:
Production

Document standards
Document identification standards

How documents are uniquely identified.
Document structure standards
Standard structure for project documents.
Document presentation standards
Define fonts and styles, use of logos, etc.
Document update standards
Define how changes from previous versions are
reflected in a document.

Document interchange standards
Interchange standards allow electronic documents to be

exchanged, mailed, etc.
Documents are produced using different systems and on
different computers. Even when standard tools are used,
standards are needed to define conventions for their use
e.g. use of style sheets and macros.
Need for archiving. The lifetime of word processing
systems may be much less than the lifetime of the software
being documented. An archiving standard may be defined
to ensure that the document can be accessed in future.

Quality planning
A quality plan sets out the desired product

qualities and how these are assessed and
defines the most significant quality attributes.
The quality plan should define the quality
assessment process.
It should set out which organisational standards
should be applied and, where necessary, define
new standards to be used.

Quality plans
Quality plan structure

Product introduction;
Product plans;
Process descriptions;
Quality goals;
Risks and risk management.
Quality plans should be short, succinct documents
If they are too long, no-one will read them.

Software quality attributes

Quality control
This involves checking the software

development process to ensure that procedures
and standards are being followed.
There are two approaches to quality control
Quality reviews;
Automated software assessment and software
measurement.

Quality reviews
This is the principal method of validating the quality of a

process or of a product.
A group examines part or all of a process or system and
its documentation to find potential problems.
There are different types of review with different
objectives
Inspections for defect removal (product);
Reviews for progress assessment (product and process);
Quality reviews (product and standards).

Types of review

Quality reviews
A group of people carefully examine part or all

of a software system and its associated
documentation.
Code, designs, specifications, test plans,
standards, etc. can all be reviewed.
Software or documents may be 'signed off' at a
review which signifies that progress to the next
development stage has been approved by
management.

Review functions
Quality function - they are part of the general

quality management process.
Project management function - they provide
information for project managers.
Training and communication function - product
knowledge is passed between development
team members.

Quality reviews
The objective is the discovery of system defects

and inconsistencies.
Any documents produced in the process may be
reviewed.
Review teams should be relatively small and
reviews should be fairly short.
Records should always be maintained of quality
reviews.

Review results
Comments made during the review should be

classified
No action. No change to the software or documentation is
required;
Refer for repair. Designer or programmer should correct an
identified fault;
Reconsider overall design. The problem identified in the
review impacts other parts of the design. Some overall
judgement must be made about the most cost-effective way of
solving the problem;
Requirements and specification errors may
have to be referred to the client.

Software measurement and metrics
Software measurement is concerned with deriving a

numeric value for an attribute of a software product or
process.
This allows for objective comparisons between
techniques and processes.
Although some companies have introduced
measurement programmes, most organisations still
don’t make systematic use of software measurement.
There are few established standards in this area.

Software metric
Any type of measurement which relates to a software

system, process or related documentation
Lines of code in a program, the Fog index, number of person-days
required to develop a component.
Allow the software and the software process to
be quantified.
May be used to predict product attributes or to control the
software process.
Product metrics can be used for general predictions or to
identify anomalous components.

Predictor and control metrics
Software Software
process product
Control Predictor
measurements measur
ements
Management
decisions

Metrics assumptions
A software property can be measured.

The relationship exists between what we can
measure and what we want to know. We can only
measure internal attributes but are often more interested
in external software attributes.
This relationship has been formalised and
validated.
It may be difficult to relate what can be measured to
desirable external quality attributes.

Internal and external attributes
Number ofprocedure
parameters
Maintainability
Cyclomatic comple
x ity
Reliability
Program size in lines
of code
Portability
Number oferror
messages
Usability
Length of user man

ual

The measurement process
A software measurement process may be part

of a quality control process.
Data collected during this process should be
maintained as an organisational resource.
Once a measurement database has been
established, comparisons across projects
become possible.

Product measurement process
Choose Analyse
measurements anomalous
to be made components
Select Identify
components to anomalous
be assessed measur
ements
Measure
component
characteristics

Data collection
A metrics programme should be based on a set

of product and process data.
Data should be collected immediately (not in
retrospect) and, if possible, automatically.
Three types of automatic data collection
Static product analysis;
Dynamic product analysis;
Process data collation.

Data accuracy
Don’t collect unnecessary data

The questions to be answered should be decided
in advance and the required data identified.
Tell people why the data is being collected.
It should not be part of personnel evaluation.
Don’t rely on memory
Collect data when it is generated not after a
project has finished.

Product metrics
A quality metric should be a predictor of

product quality.
Classes of product metric
Dynamic metrics which are collected by measurements made of a
program in execution;
Static metrics which are collected by measurements made of the
system representations;
Dynamic metrics help assess efficiency and reliability; static metrics
help assess complexity, understandability and maintainability.

Dynamic and static metrics
Dynamic metrics are closely related to software quality

attributes
It is relatively easy to measure the response time of a system
(performance attribute) or the number of failures (reliability
attribute).
Static metrics have an indirect relationship with quality

attributes
You need to try and derive a relationship between these metrics
and properties such as complexity, understandability and
maintainability.

Software product metrics

Object-oriented metrics

Measurement analysis
It is not always obvious what data means

Analysing collected data is very difficult.
Professional statisticians should be consulted if
available.
Data analysis must take local circumstances
into account.

Measurement surprises
Reducing the number of faults in a program

leads to an increased number of help desk calls
The program is now thought of as more reliable
and so has a wider more diverse market. The
percentage of users who call the help desk may
have decreased but the total may increase;
A more reliable system is used in a different way
from a system where users work around the
faults. This leads to more help desk calls.

Key points
Software quality management is concerned with

ensuring that software meets its required
standards.
Quality assurance procedures should be
documented in an organisational quality manual.
Software standards are an encapsulation of best
practice.
Reviews are the most widely used approach for
assessing software quality.

Key points
Software measurement gathers information

about both the software process and the
software product.
Product quality metrics should be used to
identify potentially problematical components.
There are no standardised and universally
applicable software metrics.

Quality Management: ©ian Sommerville 2004

Uploaded by

Copyright:

Available Formats

Quality Management: ©ian Sommerville 2004

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Quality Management: ©ian Sommerville 2004

Uploaded by

Copyright:

Available Formats

Quality Management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1

To introduce the quality management process and key

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 2

Process and product quality

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 3

Concerned with ensuring that the required level

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 4

Quality, simplistically, means that a product should meet

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 5

We cannot wait for specifications to improve

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 6

Quality management is particularly important for

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 7

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 8

Standards and Quality Quality review repor

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 9

The quality of a developed product is influenced

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 10

There is a straightforward link between process and

Care must be taken not to impose inappropriate process

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 11

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 12

Define process standards such as how reviews

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 13

Standards are the key to effective quality

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 14

Encapsulation of best practice- avoids

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 15

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 16

They may not be seen as relevant and up-to-

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 17

Involve practitioners in development. Engineers should

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 18

An international set of standards for quality

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 19

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 20

Quality standards and procedures should be

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 21

Project 1 Project 2 Project 3 Project quality

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 22

Particularly important - documents are the tangible

Document interchange standards

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 23

Proofread Produce Check

Layout Review Produce Print

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 24

Document identification standards

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 25

Interchange standards allow electronic documents to be

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 26

A quality plan sets out the desired product

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 27

Quality plan structure

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 28

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 29

This involves checking the software

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 30

This is the principal method of validating the quality of a