LECTURE 6

Quality
management
Content

1 Introduction to quality management process

2 Roles of standards in quality management

Relationship between quality attributes and

3 software metrics

4 Using measurement in assessing software quality

What is quality management?

Managing the quality of the

software process and products
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
o Tension between customer quality requirements (efficiency,
reliability, etc.) and developer quality requirements
(maintainability, reusability, etc.)
o Some quality requirements are difficult to specify in an
unambiguous way
o Software specifications are usually incomplete and often
inconsistent
Software quality attributes

Safety Understandability Portability

Security Testability Usability
Reliability Adaptability Reusability
Resilience Modularity Efficiency
Robustnes s Complexity Learnability
A high quality software product

 Satisfies clearly stated requirements

 Checks its inputs and that it reacts in predictable ways to illegal
inputs
 Has been inspected thoroughly by others
 Has been tested exhaustively by others
 Is thoroughly documented
 Has a known defect rate
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 planning
Quality management activities

 Quality assurance
o Establish organizational procedures and standards for quality
 Quality planning
o Select applicable procedures and standards for a particular
project and modify these as required
 Quality control
o Ensure that procedures and standards are followed by the
software development team
 Quality management should be separated 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 reports

procedures plan
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

 Framework for quality assurance process – it involves checking
standard compliance
 Provide continuity - new staff can understand the organization by
understand the standards applied
Product and process standards

Product standards Proces s s tandards

Des ign review form Des ign review conduct
Document naming s tandards Submiss ion of documents to CM
Procedure header format Version release process
Ada programming s tyle s tandard Project plan approval process
Project plan format Change control proces s
Change request form Test recording proces s
ISO 9000 certification

 International set of standards for quality management

 Applicable to a range of organizations from manufacturing to service
industries
 ISO 9001 applicable to organizations which design, develop and
maintain products
 ISO 9001 is a generic model of the quality process that must be
instantiated for each organization
ISO 9000 certification

 Quality standards and procedures should be documented in an

organizational quality manual
 External body may certify that an organization's quality manual
conforms to ISO 9000 standards
 Customers are, increasingly, demanding that suppliers are ISO
9000 certified
ISO 9000 and quality management

ISO 9000
quality models

instantiated as

documents
Organization Organiza tion
quality manual quality process

is used to develop instantiated as

Project 1 Project 2 Project 3 Project quality

quality plan quality plan quality plan mana gement

Supports
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
Overcoming the problems

 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
Process and product quality

 The quality of a developed product is influenced by the quality of the

production process
 Form (product) follows function (process)
 Particularly 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

 Straightforward link between process and product in manufactured

goods
 More complex for software because:
o The application of individual skills and experience is particularly
important in software development
o 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

De velop Assess product

Define process
product quality

No Yes
Improve Quality Standar dize
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
Quality planning

 A quality plan sets out the desired product qualities and how these
are assessed and define the most significant quality attributes
 It should define the quality assessment process
 It should set out which organizational 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
o If they are too long, no-one will read them
IEEE 730-1989 software quality assurance plans
– Tables of contents
IEEE 730-1989 software quality assurance plans
– Tables of contents
Quality control

 Checking the software development process to ensure that

procedures and standards are being followed
 Two approaches to quality control
o Quality reviews
o Assessment via software metrics
Quality review

 The principal method of validating the quality of a process or of a

product
 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
o Inspections for defect removal (product)
o Reviews for progress assessment (product and process)
o Quality reviews (product and standards)
Quality attributes and software metrics

 Software measurement is concerned with deriving a numeric value

for an attribute of a software product or process
 Software metric is any type of measurement which relates to a
software system, process or related documentation
 This allows for objective comparisons between techniques and
processes
 There are few standards, no systematic use
Quality attributes and software metrics

Number of procedur e
par ameters
Maintainability
Cyclomatic complexity

Reliability
Program size in lines
of code
Portability
Number of error
messages
Usability

Length of user manual

Important software metric assumptions

 A software property can be measured

 A relationship exists between what we can measure and a quality
attribute
 This relationship has been formalized and validated
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
organizational resource
 Once a measurement database has been established, comparisons
across projects become possible
Product metrics

 A quality metric should be a predictor of product quality

 Classes of product metric:
o Dynamic metrics which are collected by measurements made
of a program in execution
o Static metrics which are collected by measurements made of
the system representations
o 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

o Collected by a program in execution (response time, number of
failures)
o Help assess efficiency, effectiveness, availability and reliability
 Static metrics have an indirect relationship with quality attributes
o Collected from system representation (lines of code)
o Help assess complexity, understandability and maintainability
Software product metrics
Software metric Description
Fan in/Fan-out Fan-in is a measure of the number of functions that call some other
function (say X). Fan-out is the number of functions which are called
by function X. A high value for fan-in me ans that X is tightly
coupled to the rest of the design and changes to X will have
extensive knock-on effects. A high value for fan-out suggests that the
overall complexity of X m ay be high because of the comp lexity of
the control logic needed to coordinate the called components.
Length of code This is a measure of the size of a program. Generally, the larger the
size of the code of a program’s components, the more comp lex and
error-prone that comp onent is likely to be.
Cyclomatic This is a measure of the control c omplexity of a program. T his
complexity control complexity may be rela ted to program understandability. T he
computation of cyclomatic comp lexity is covered in Chapter 20.
Length of This is a measure of the average length of distinct identifiers in a
identifiers program. T he longer the identifiers, the more likely they are to be
meaningful and hence the more understandable the program.
Depth of This is a measure of the depth of nesting of if-stateme nts in a
conditional nesting program. Deeply nested if stateme nts 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. T he higher the value for the Fog index, th e more difficult
the document may be to understand.
Object-oriented metrics
Object- Description
oriented
metric
Depth of This represents the nu mber of discrete levels in the inher it ance tree whe re
inhe rit ance sub -classes inherit at tributes and ope rations (methods) from supe r-classes.
tree The de eper the inh erit anc e tree, the more complex the design a s,
potentiall y, many d iff erent object classes have to be unde rstood to
unde rstand the ob ject classes at the leave s of the tree.
Method fan- This is dir ectly related to fan-in and fan-out as described above and means
in/fan-out essentiall y the same thing. However , it m ay be appropria te to make a
distinction between call s from other methods wit hin the object and calls
from external methods.
Weighted This is the number of methods included in a class weighted by the
methods per complexit y o f each method. The refore, a sim ple method may hav e a
class complexit y o f 1 and a la rge and complex method a much highe r va lue. The
larger the value for this metric, the more complex the object class.
Complex objects are more li kely to be more diff icult to und erstand. They
may not be logi call y coh esive so canno t be reused effectively a s supe r-
classes in an inherit anc e tree.
Number of These are the nu mber of operations in a supe r-class which are ove r-ridden
ove rriding in a sub-class. A high v alue for this metric indicates that the super -class
operations used may not be an approp riate parent for the sub-class.