Chapter 7 A:Quality Management

 Software quality management for large systems can be

structured into three main activities;
 Quality assurance: The establishment of a framework of organizational
procedures and standards that lead to high-quality software.
 Quality planning: the selection of appropriate procedures and
standards from this framework, adapted for a specific software project.
 Quality control: The definition and enactment of processes that ensure
the software development team have followed project quality
procedures and standards.

1
 Quality management provides an independent check on the
software development process.
 The project quality management process check the project
deliverables to ensure that they are consistent with
organizational standards and goals.
 The quality assurance team should be independent from the
development team so that they can take an objective view of
the software.

2
Process and Product Quality
 A fundamental assumption of quality management is that the
quality of the development process directly affect the quality
of delivered products.
 In an automated manufacturing system, the process involves
configuring, setting up and operating the machines involved
in the process. Once the machines are operating correctly,
product quality naturally follows.

3
 You measure the quality of the product and change
the process until you achieve the quality level that you
need.

4
Process-based Quality

Assess product quality

Define Develop
process Product

No
Improve Quality Standardize
OK
process process

5
 There is a clear link between process and product
quality in manufacturing because the process is
relatively easy to standardize and monitor.
 Once manufacturing systems are calibrated, they can
be run again and again to output high-quality
products.

6
 However, software is not manufactured, but it is
designed.
 Software development is a creative process rather
than a mechanical process, so the influence of
individual skills and experience is significant.
 In software development, therefore, the relationship
between process quality and product quality is more
complex.

7
 It is more difficult to measure software quality
attributes, such as maintainability, even after using
software for a long period.
 Consequently it is hard to tell how process
characteristics influence these attributes.
 Also because of the role of design and creativity is the
software process, you can’t predict how process
changes will influence the quality of the product.

8
 However, process quality has a significant influence
on the quality of the software. Process quality
management involves:
Defining process standards such as how and when reviews
should be conducted.
Monitoring the development process to ensure that the
standards are being followed
Reporting the software process to project management and
to the buyer of the software.
9
Quality Assurance and Standards

 Quality assurance is the process of defining how

software quality can be achieved and how the
development organization knows that the software
has the required level of quality.

10
 The two types of standards that may be established
as part of the quality assurance process are:
Product standards: These standards apply to the software
product being developed. They include document standards
(e.g. the structure of requirements documents),
documentation standards (e.g. a standard comment header
for an object class definition), and coding standards that
define how a programming language should be used.

11
Process standards: These standards define the processes
that should be followed during software development. They
may include definitions of specifications, design and
validation processes and a description of the documents that
should be written in the course of these processes.

12
 Software standards are important for several reasons:
They are based on knowledge about the best or most
appropriate practice for the company.
They provide a framework for implementing the quality
assurance process.
They assist in continuity where work carried out by one
person is taken up and continued by another.

13
 Quality Managers who set the standards need to be
adequately resourced and should take the following
steps:
Involve software engineers in the selection of product
standards. The standards document should not simply state
a standard to be followed but should include a rationale of
why particular standardization decisions have been made.

14
Review and modify standards regularly to reflect
changing technologies. Once standards are developed,
they tend to be enshrined in a company standards handbook
and management is often reluctant to change them. A
standards handbook is essential, but is should evolve to
reflect changing circumstances and technology.

15
 Provide software tools to support standards wherever
possible.

16
ISO 9000

 An international set of standards that can be used in

the development of a quality management system in
all industries is called ISO 9000.
 ISO 9000 standards can be applied to a range of
organizations from manufacturing to service
industries.

17
 ISO 9001 standard isn’t specifically aimed at software
development process but sets out general principles that can
be applied to software.
 It describes various aspects of the quality process and lays
out the organizational standards and procedures that a
company should define.
 The quality assurance procedures in an organization are
documented in a quality manual that defines the quality
process.

18
ISO 9000 and Quality Management

ISO 9000 quality

models

Instantiated as
documents Organization
Organizational quality process
quality manual

Is used to develop
Instantiated as

Project 1 quality Project 2 quality Project 3 quality Project quality

plan plan plan management

Supports

19
Documentation Standards
 Documentation standards in a software project are important because
documents are the only tangible way of representing the software and
the software process.
 There are three types of documentation standards;
 Documentation process standards: These standards define the process that
should be followed for document production.
 Document standards: These standards govern the structure and presentation of
documents.
 Document interchange standards: These standards ensure that all electronic
copies of documents are compatible.

20
 Examples of document standards that may be developed are:
 Document identification standards: As large system development
projects may produce thousands of documents, each document should
be uniquely identified.
 Document structure standards: Each class of document produced
during a software project should follow some standard structure.
Structure standards should define the sections to be included and
should specify the conventions used for page numbering, page header
and footer information and section and subsection numbering.

21
Document presentation standards: document presentation
standards define ‘house style’ for documents and contribute
significantly to document consistency. They include definition
of fonts and styles used in the document, the use of logos
and company names, the use of colour to highlight document
structure etc.
Document update standards: as a document evolves to
reflect changes in the system, a consistent way of indicating
document changes should be used.

22
Quality Planning
 Quality planning is the process of developing a quality plan
for a project.
 The quality plan should set out the desired software qualities
and describe how these are to be assessed.
 The quality plan should select those organizational standards
that are appropriate to a particular product and development
process.
 New standards may have to be defined if the project uses
new methods and tools.

23
 Humphrey (1989) suggests an outline structure for a quality
plan:
 Product introduction: A description of the product, its intended market
and the quality expectations for the product.
 Product plans: The critical release dates and responsibilities for the
product along with plans for distribution and product servicing.
 Process descriptions: The development and service processes that
should be used for product development and management.

24
Quality goals: The quality goals and plans for the product
including an identification and justification of critical product
quality attributes.
Risks and risk management: The key risks that might affect
product quality and the actions to address these risks.

25
Quality Control
 Quality control involves monitoring the software development
process to ensure that quality assurance procedures and
standards are being followed.
 There are two complementary approaches that may be used
to check the quality of project deliverables:
 Quality reviews
 Automated software assessment (where the software and the
documents that are produced are processed by some program and
compared to the standards that apply to that particular development
project).

26
 Quality reviews:
The most widely used method of validating the quality of a
process or product. They involve a group of people
examining part of all of a software process, system or its
associated documentation to discover potential problems.
The conclusions of the review are formally recorded and
passed to the author or whoever is responsible for correcting
the discovered problems.

27
Software Measurement and Metrics

 Quality reviews are expensive and time-consuming

and inevitable delay the completion of a software
projects.
 Its is possible to accelerate the review process by
using tools to process the software design or program
and make some automated assessments of software
quality.

28
 These assessments could check that the software has
reached the required quality threshold and where this has no
been achieved, highlight areas of the software where the
review should focus.
 Software measurement is concerned with deriving a numeric
value for some attribute of a software product or a software
process.
 By comparing these values to each other and to standards
that apply across an organization, you may be able to draw
conclusions about the quality of software or software
processes.

29
 There are two ways in which software product measurements
may be used:
 To make predictions about a system. By measuring the
characteristics of system components and then aggregating these
measurements, you can derive a general estimate of some system
attribute such as the number of faults in the system.
 To identify anomalous components. Measurements can identify
individual components whose characteristics deviate from some norm.

30
 A software metric is any type of measurement that
relates to a software system, process or related
documentation.
 Software metrics may either be control metrics or
predictor metrics. Both may influence decision-
making as shown in the following diagram:

31
Predictor and Control Measurements

Software process
Software product

Control Predictor
measurements measurements

Management
decisions

32
 Control metrics are usually associated with software
processes and predictor metrics are associated with software
products.
 Examples of control or process metrics are the average effort
and time required to repair reported defects
 Examples of predictor metrics are the complexity of a module,
the average length of identifiers in a program, and the
number of attributes and operations associated with objects
in a design.

33
 It is often impossible to measure software quality attributes
directly. Quality attributes such as maintainability,
understandability and usability are external attributes that
relate to how developers and users see the software.
 They are affected by many factors and there are no simple
ways to measure them.
 Rather, you measure some internal attribute (e.g. size) and
assume that a relationship exists between what you can
measure and what you really want to know.

34
 The diagram below shows some external quality
attributes that might be of interest and internal
attributes that might be related to them.

35
Relationships between Internal and External
Software Attributes

Number of procedure parameters

Maintainability

Cyclomatic complexity
Reliability

Program size in lines of code

Portability

Number of error messages

Usability

Length of user manual

36
 The above diagram suggests that there may be
relationships between external and internal attributes,
but does not say what that relationship is.
 If the measure of the internal attribute is to be a useful
predictor of the external software characteristic, three
conditions must hold (Kitchenham, 1990): - (P.T.O)

37
 1. The Internal attribute must be measured accurately.
 2. A relationship must exist between what we can
measure and the external behavioral attribute in which
we are interested.
 3. This relationship is understood, has been validated
and can be expressed in terms of a formula or model.

38
The Measurement Process

 A software measurement process that may be part of

a quality control process is shown in the following
diagram:

39
The Process of Product Measurement

Analyze anomalous
Choose
components
measurements to
be made

Identify anomalous
Select components
measurements
to be assessed

Measure
component
characteristics

40
 The key steps in this process are:
 Choose measurements to be made: The questions that the
measurement is intended to answer should be formulated and the
measurements required to answer these questions defined.
Measurements that are not directly relevant to these questions need not
be collected.
 Select components to be assessed. It may not be necessary or
desirable to assess metric values for all of the components in a software
system.

41
 Measure component characteristics: The selected components are
measured and the associated metric values computed. This normally
involves processing the component representation (design, code etc.)
using an automated data collection tool.
 Identify anomalous measurements: Once the component
measurements have been made, you should compare them to each
other and to previous measurements that have been recorded in a
measurement database. You should look for unusually high or low
values for each metric, as these suggest that there could be problems
with the component exhibiting these values.

42
Analyze anomalous components: Once the components
that have anomalous values for particular metrics have been
identified, you should examine these components to decide
whether the anomalous metric values mean that the quality of
the component is compromised.

43
Product Metrics

 Product metrics are concerned with the characteristics

of the software itself.
 Product metrics fall into two classes:
Dynamic metrics – that are collected by measurements
made of a program in execution.
Static metrics – that are collected by measurements made
of representations of the system such as the design, program
or documentation.

44
 Dynamic metrics help to assess the efficiency and the
reliability of a program. Static metrics help to assess
the complexity, understandability and maintainability
of a software system.

45
 Dynamic metrics are usually fairly closely related to software
quality attributes.
 Static metrics, on the other hand, have an indirect
relationship with quality attributes.
 A large number of these metrics have been proposed and
many experiments have tried to derive and validate the
relationships between these metrics and system complexity,
understandability and maintainability.
 The table below describes several static product metrics that
have been used for quality measurement:

46
Static software product metrics
Software Metric Description
Fan-fan-out Fain-in is a measure of the number of functions or methods that call on some
other function or method (say X). fan-out is the number of functions that
are called by function X.

Length of code This is a measure of the size of the program. Generally, the larger the size of
code of a component, the more complex and error-prone that component is
likely to be.

Cyclomatic complexity This is a measure of the control complexity of a program. This control
complexity may be related to program understandability.

Length of identifiers This is a measure of the average length of distinct identifiers in a program. The
longer the identifiers the more likely they are to be meaningful and hence
the more understandable the program.

Depth of conditional nesting This is a measure of the depth of nesting of if-statements in a program. Deeply
nested if statements are hard to understand and are potentially error-prone.

Fog index This is a measure of the average length of words and sentences in documents.
The higher the value for the fog index, the more difficult the document is to
understand.

47
Object-Oriented Metrics
Software Metric
Depth of inheritance tree
Method fan-in/fan-out
Weighted methods per class
Number of overriding operations
Description
This represents the number of discrete levels in the inheritance tree where
subclasses inherit attributes and operations (methods) from super-classes.
The deeper the inheritance tree, the more complex the design.
This is directly related to fan-in and fan-out, described in the table above and
means essentially the same thing. However, it may be appropriate to make
a distinction between calls from other methods within the object and calls
from external methods.
This is the number of methods included in a class, weighted by the complexity of
each method. The larger this metric, the more complex the object class.
This is the number of operations in a super-class that are overriden in a subclass.
A high value for this metric indicates that the super-class used may not be
an appropriate parent for the sub-class
48
 The best known object-oriented metrics were proposed by
Chidamber and Kemerer (1994) and there are some tools
available to collect these metrics.
 The specific metrics that are relevant depend on the project,
the goals of the quality management team and the type of
software that is being developed.
 All of the metrics shown in the above tables may be useful in
some situations.

49
 Equally however, there will be other situations where
they are inappropriate.
 When introducing software measurements as part of
the quality management process, organizations have
to experiment to discover the most appropriate
metrics for their needs.

50
The End !

51