ch24_quality Management in software engineering.ppt

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 1
Chapter 24
Quality Management

Quality Management

Managing the quality of the
software process and
products

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

Topics covered

Quality assurance and standards

Quality planning

Quality control

Software measurement and metrics

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
• 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

Must put procedures into place to improve quality
in spite of imperfect specification

Quality management is therefore not just
concerned with reducing defects but also with
other product qualities

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

ISO 9000

International set ofstandards 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
Must be instantiated for each organisation

ISO 9001

ISO 9000 certification

Quality standards and procedures should be
documented in an organisational quality manual

External body may certify that an organisation’s
quality manual conforms to ISO 9000 standards

Customers are, increasingly, demanding that
suppliers are ISO 9000 certified

ISO 9000 and quality management


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
Quality assurance and standards


Encapsulation of best practice- avoids
repetition of past mistakes

Framework for quality assurance process - it
involves checking standard compliance

Provide continuity - new staff can understand
the organisation by understand the standards
applied
Importance of standards

Product and process standards

Problems with standards

Not seen as relevant and up-to-date by software
engineers

Involve too much bureaucratic form filling

Unsupported by software tools so tedious
manual work is involved to maintain standards


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
Standards development

Documentation standards

Particularly important - documents are the
tangible manifestation of the software

Documentation process standards
• How documents should be developed, validated and maintained

Document standards
• Concerned with document contents, structure, and appearance

Document interchange standards
• How documents are stored and interchanged between different
documentation systems

Documentation process

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

Documents are produced using different systems
and on different computers

Interchange standards allow electronic documents
to be exchanged, mailed, etc.

Need for archiving. The lifetime of word processing
systems may be much less than the lifetime of the
software being documented

XML is an emerging standard for document
interchange which will be widely supported in future


The quality of a developed product is influenced
by the quality of the production process

Particularly important in software development
as some product quality attributes are hard to
assess

However, there is a very complex and poorly
understood between software processes and
product quality
Process and product quality

Process-based quality

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

Process-based 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
Practical process quality

Quality planning

A quality plan sets out the desired product
qualities and how these are assessed ande
define the most significant quality attributes

It should define the quality assessment process

It should set out which organisational standards
should be applied and, if necessary, define new
standards

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

Checking the software development process to
ensure that procedures and standards are being
followed

Two approaches to quality control
• Quality reviews
• Automated software assessment and software measurement

Quality reviews

The principal method of validating the quality of a
process or of a product

Group examined 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


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.
Quality reviews

The review process

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

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

Review should be recorded and records
maintained


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.
Review results

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
measurment programmes, the systematic use of
measurement is still uncommon

There are few standards in this area


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

Measures of the software process or product

May be used to predict product attributes or to
control the software process
Software metric

Predictor and control metrics


A software property can be measured

The relationship exists between what we can
measure and what we want to know

This relationship has been formalized and
validated

It may be difficult to relate what can be measured
to desirable quality attributes
Metrics assumptions

Internal and external attributes

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

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

Automated data collection

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


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
Product metrics

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

ch24_quality Management in software engineering.ppt

More Related Content

Similar to ch24_quality Management in software engineering.ppt (20)

More from nilampatoliya (15)

Recently uploaded (20)

ch24_quality Management in software engineering.ppt