SQM P.selvapriyavadhana

Software Quality Management
July 27, 2011
Author name : Selvapriyavadhana
1
P.Selvapriyavadhana,Asst.Prof,ACT
Syllabus
MC9277 : SOFTWARE QUALITY MANAGEMENT
UNIT I : FUNDAMENTALS OF SOFTWARE QUALITY ENGINEERING
Concepts Of Quality - Hierarchical Modeling - Quality Models - Quality Cri-

teria And Its Interrelation - Fundamentals Of Software Quality Improvement -
Concepts Of Quality Improvement - Concepts Of Process Maturity - Improving
Process Maturity.
UNIT II:DEVELOPMENTS IN MEASURING QUALITY
Selecting Quality Goals And Measures - Principles Of Measurement - Measures

And Metrics - Quality Function Deployment - Goal/Question/Measure Paradigm
- Quality Characteristics Tree - The FURPS Model And FURPS+ - Gilb Ap-
proach -Quality Prompts.
UNIT III:QUALITY MANAGEMENT SYSTEM
Elements Of A Quality Engineering Program - Quality Control, Assurance And

Engineering - Reliability, Maintainability, Verifiability, Testability, Safety And
Supportability - Historical Perspective Elements Of QMS - Human Factors -
Time Management - QMS For Software-Quality Assurance - ISO9000 Series-A
Generic Quality Management Standard - Tools For Quality.
UNIT IV:PRINCIPLES AND PRACTICES IN QMS
Process-Product-Project-People In Software Development And Management Spec-

trum - Principle And Critical Practices In QMS - ISO 9001 And Capability Ma-
turity Models -Six Sigma, Zero Defects And Statistical Quality Control.
UNIT V MEASURES AND METRICS IN PROCESS AND PROJECT DO-

MAINS
Key Measures For Software Engineers - Defects - Productivity And Quality -

Measuring And Improving The Development Process - Assigning Measures To
Process Elements And Events - Isikawa Diagrams - Metrics For Software Quality
- Integrating Metrics Within Software Engineering Process - Metrics For Small
Organizations.
SQM 2
Fundamentals of software quality engineering
1 Quality
Software quality In the context of software engi-

neering, software quality measures how well soft-
ware is designed (quality of design), and how well
the software conforms to that design (quality of
conformance), although there are several differ-
ent definitions.
Definition:
1. Conformance to specification: Quality that

is defined as a matter of products and ser-
vices whose measurable characteristics satisfy
a fixed specification that is conformance to an
in beforehand defined specification.
2. Meeting customer needs: Quality that is iden-
tified independent of any measurable charac-
teristics. That is quality is defined as the
products or services capability to meet cus-
tomer expectations explicit or not.
3. Quality is the degree of goodness of a product
or service or perceived by the customer.
The Department of Defense (DOD, 1985) in the
USA defines software quality as “ the degree to
which the attributes of the software enable it to
perform its intended end use” .
SQM 3
Characteristics of Quality:
Quality is a multidimensional construct. It may therefore be consid-

ered using a polyhedron metaphor. Within this metaphor, a three-
dimensional solid represents quality. Each face represents a different
aspect of quality such as correctness, reliability, and efficiency.
• Quality is not absolute.

• Quality is multidimensional.
• Quality is subject to constraints
• Quality is about acceptable compromises.
• Quality criteria are not independent, but in-
teract with each other causing conflicts.
Views of Quality
In an attempt to classify different and conflicting

views of quality,Garvin(1984) has suggested five
different views of quality:
1. The transcendent view
• Innate excellence
• Classical definition
2. The product-based view
• Higher the quality higher the cost
• Greater functionality
• Greater care in development
3. The user-based view
• Fitness for purpose
• Very hard to quantify
SQM 4
4. The manufacturing view

• Measures quality in terms of conformance
• Zero defects
5. The value-based view
• Provides the data with what the customer
requires at a price.
2 HIERARCHICAL MODEL OF QUALITY
To compare quality in different situations, both

qualitatively and quantitatively, it is necessary to
establish a model of quality.
Many model suggested for quality.
Most are hierarchical in nature.
A quantitative assessment is generally made, along

with a more quantified assessment.
Two principal models of this type, one by Boehm(1978)

and one byMcCall in 1977. A hierarchical model
of software quality is based upon a set of quality
criteria, each of which has a set of measures or
metrics associated with it.
The issues relating to the criteria of quality are:
• What criteria of quality should be employed?
• How do they inter-relate?
• How may the associated metrics be combined
into a meaningful overall measure of Quality?
SQM 5
THE HIERARCHICAL MODELS OF BOEHM

AND MCCALL THE GE MODEL
• This model was first proposed byMcCall in

1977.
• It was later revised as theMQmodel, and it is
aimed by system developers to be used during
the development process.
• In early attempt to bridge the gap between
users and developers, the criteria were chosen
in an attempt to reflect user? s views as well
as developer? s priorities.
• The criteria appear to be technically oriented,
but they are described by a series of questions
which define them in terms to non specialist
managers.
SQM 6
The three areas addressed by McCall’s model

(1977)
(basic operational characteristics)

Product operation :
requires that it can be learnt easily, operated ef-
ficiently And it results are those required by the
users.
The product operations perspective identifies qual-
ity factors that influence the extent to which the
software fulfils its specification:-
• Correctness, the functionality matches the spec-

ification.
• Reliability, the extent to which the system
fails.
• Efficiency, system resource (including cpu, disk,
memory, network) usage.
• Integrity, protection from unauthorized ac-
cess.
• Usability, ease of use.
(ability to change) it is concerned

Product revision :
with error correction and adaptation Of the sys-
tem and it is most costly part of software devel-
opment.
The product revision perspective identifies qual-
ity factors that influence the ability to change the
software product, these factors are:-
• Maintainability, the ability to find and fix a
defect.
• Flexibility, the ability to make changes re-
quired as dictated by the business.
SQM 7
• Testability, the ability to Validate the soft-

ware requirements.
(adaptability to new environments)

Product transition :
it is an important application and it is distributed
processing and the rapid rate of change in hard-
ware is Likely to increase.
The product transition perspective identifies qual-
ity factors that influence the ability to adapt the
software to new environments:-
• Portability, the ability to transfer the software
from one environment to another.
• Reusability, the ease of using existing software
components in a different context.
• Interoperability, the extent, or ease, to which
software components work together.
McCall’s criteria of quality defined
1. Efficiency is concerned with the use of re-

sources e.g. processor time, storage. It falls
into two categories: execution efficiency and
storage efficiency.
2. Usability is the ease of use of the software.
3. Integrity is the protection of the program from
unauthorized access.
4. Correctness is the extent to which a program
fulfils its specification.
5. Reliability is its ability not to fail.
6. Maintainability is the effort required to locate
and fix a fault in the program within its op-
erating environment.
SQM 8
Figure 1: The GE model after McCall
7. Flexibility is the ease of making changes re-

quired by changes in the operating environ-
ment.
8. Testability is the ease of testing the programs,
to ensure that it is error-free and meet its
specification.
9. Portability is the effort required to transfer a
program from one environment to another.
10. Reusability is the ease of refusing software in
a different context.
11. Interoperability is the effort required to cou-
ple the system to another system.
SQM 9
The Boehm model (1978)
• It is to provide a set of well-defined, well-

differentiated characteristics of software qual-
ity.
• It is hierarchical in nature but the hierarchy
is extended, so that quality criteria are sub-
divided.
• According to the uses made of the system and
they are classed into general or as is and the
utilities are a subtype of the general utilities,
to the product operation.
• There are two levels of actual quality criteria,
the intermediate level being further split into
primitive characteristics which are amenable
to measurement.
• This model is based upon a much larger set
of criteria than McCall s model, but retains
the same emphasis on technical criteria.
• The two models share a number of common
characteristics are,
1. The quality criteria are supposedly based
upon the user s view.
2. The models focus on the parts that design-
ers can more readily analyze.
3. Hierarchical models cannot be tested or
validated. It cannot be shown that the
metrics accurately reflect the criteria.
4. The measurement of overall quality is achieved
by a weighted summation of the character-
istics.
SQM 10
Boehm talks of modifiability where McCall dis-

tinguishes expandability from adaptability and
documentation, understandability and clarity.
3 Quality Models
In the previous section we presented some quality management gurus

as well as their ideas and views on quality primarily because this is
a used and appreciated approach for dealing with quality issues in
software developing organizations. Whereas the quality management
philosophies presented represent a more flexible and qualitative view
on quality, this section will present a more fixed and quantitative
quality structure view
McCalls Quality Model (1977)
One of the more renown predecessors of todays quality models is the

quality model presented by Jim McCall (also known as the General
Electrics Model of 1977). This model, as well as other contemporary
models, originates from the US military (it was developed for the
US Air Force, promoted within DoD) and is primarily aimed towards
the system developers and the system development process. It his
quality model McCall attempts to bridge the gap between users and
developers by focusing on a number of software quality factor that
reflect both the users views and the developers priorities.
Three major perspectives for defining and identifying the quality of

a software product:
• product revision (ability to undergo changes),

• product transition (adaptability to new envi-
ronments) and
• product operations (its operation characteris-
tics).
SQM 11
• Product revision includes

1. Maintainability (the effort required to lo-
cate and fix a fault in the program within
its operating environment),
2. Flexibility (the ease of making changes re-
quired by changes in the operating envi-
ronment) and
3. Testability (the ease of testing the pro-
gram, to ensure that it is error-free and
meets its specification).
• Product transition is all about portability (the
effort required to transfer a program from one
environment to another),
1. Reusability (the ease of reusing software in
a different context) and
2. Interoperability (the effort required to cou-
ple the system to another system).
• Quality of product operations depends on
1. Correctness (the extent to which a pro-
gram fulfils its specification),
2. Reliability (the systems ability not to fail),
3. Efficiency (further categorized into execu-
tion efficiency and storage efficiency and
generally meaning the use of resources, e.g.
processor time, storage),
4. Integrity (the protection of the program
from unauthorized access) and
5. Usability (the ease of the software).
SQM 12
Figure 2: McCalls Quality Model
Boehms Quality Model (1978)
The second of the basic and founding predeces-

sors of todays quality models is the quality model
presented by Barry W. Boehm . Boehm addresses
the contemporary shortcomings of models that
automatically and quantitatively evaluate the qual-
ity of software. In essence his models attempts
to qualitatively define software quality by a given
set of attributes and metrics. Boehm’s model is
similar to the McCall Quality Model in that it
also presents a hierarchical quality model struc-
tured around high-level characteristics, interme-
diate level characteristics, primitive characteris-
tics - each of which contributes to the overall
quality level.
SQM 13
The high-level characteristics represent basic high-level requirements

of actual use to which evaluation of software quality could be put
the general utility of software. The high-level characteristics address
three main questions that a buyer of software has:
• As-is utility: How well (easily, reliably, effi-

ciently) can I use it as-is?
• Maintainability: How easy is it to understand,
modify and retest?
• Portability: Can I still use it if I change my
environment?
The intermediate level characteristic represents
Boehms 7 quality factors that together represent
the qualities expected from a software system:
• Portability (General utility characteristics): Code
possesses the characteristic portability to the
extent that it can be operated easily and well
on computer configurations other than its cur-
rent one.
• Reliability (As-is utility characteristics): Code
possesses the characteristic reliability to the
extent that it can be expected to perform its
intended functions satisfactorily.
• Efficiency (As-is utility characteristics): Code
possesses the characteristic efficiency to the
extent that it fulfills its purpose without waste
of resources.
• Usability (As-is utility characteristics, Human
Engineering): Code possesses the characteris-
tic usability to the extent that it is reliable,
efficient and human-engineered.
• Testability (Maintainability characteristics): Code
possesses the characteristic testability to the
SQM 14
extent that it facilitates the establishment of

verification criteria and supports evaluation
of its performance.
• Understandability (Maintainability character-
istics): Code possesses the characteristic un-
derstandability to the extent that its purpose
is clear to the inspector.
• Flexibility (Maintainability characteristics, Mod-
ifiability): Code possesses the characteristic
modifiability to the extent that it facilitates
the incorporation of changes, once the nature
of the desired change has been determined.
The lowest level structure of the characteristics
hierarchy in Boehms model is the primitive char-
acteristics metrics hierarchy. The primitive char-
acteristics provide the foundation for defining qual-
ities metrics which was one of the goals when
Boehm constructed his quality model. Conse-
quently, the model presents one ore more met-
rics2 supposedly measuring a given primitive char-
acteristic.
SQM 15
Figure 3: Boehm’s Software Quality Characteristics Tree
SQM 16
4 QUALITY CRITERIA and INTERRELATION
The individual measure of software quality pro-

vided do not provide an over all measure of soft-
ware quality. The individual measures must be
combined. The individual measures of quality
may conflict with each other.
Some of these relationships are described below;
• Integrity vs. efficiency (inverse) the control
of access to data or software requires addi-
tional code and processing leading to a longer
runtime and additional storage requirement.
• Usability vs. efficiency (inverse) Improvements
in the human / computer interface may signif-
icantly increase the amount of code and power
required.
• Maintainability and testability vs. efficiency
(inverse) Optimized and compact code is not
easy to maintain.
• Portability vs. efficiency (inverse) the use
of optimized software or system utilities will
lead to decrease in probability.
• Flexibility, reusability and interoperability vs.
efficiency (inverse) the generally required for
a flexible system, the use if interface routines
and the modularity desirable for reusability
will all decrease efficiency.
• Flexibility and reusability vs. integrity (in-
verse) the general flexible data structures re-
quired for flexible and reusable software in-
crease the security and protection problem.
• Interoperability vs. integrity (inverse) Cou-
pled system allow more avenues of access to
more and different users.
SQM 17
• Reusability vs. reliability (inverse) reusable

software is required to be general: maintain-
ing accuracy and error tolerance across all
cases is difficult.
• Maintainability vs. flexibility (direct) main-
tainable code arises from code that is well
structured.
• Maintainability vs. reusability (direct) well
structured easily maintainable code is easier
to reuse in other programs either as a library
of routines or as code placed directly within
another program.
• Portability vs. reusability (direct) portable
code is likely to be free of environment-specific
features.
• Correctness vs. efficiency (neutral) the cor-
rectness of code, i.e. its conformance to spec-
ification does not influence its efficiency.
SQM 18
Figure 4: Quality criteria inter-relation
SQM 19
Process Improvement Strategy
Study an existing process to understand its activ-

ities.Produce an abstract model of the process.
Analyse the model to discover process problems.
This involves discussing process activities with
stakeholders and discovering problems and pos-
sible process changes.
5 Quality Improvement Model
• Set the Goal

• Constitute the Software Engineering Process
Group (SEPG)
• Flow Chart the current Processes
• Organize the process champions
• Simplify the process and make changes
• Get feedback from practitioner
• Remove bottlenecks and weak processes after
review
• Baseline the process
• Train the practitioners
SQM 20
Figure 5: Improvement Model
SQM 21
Quality Improvement
Process quality and product quality are closely

related and process improvement benefits arise
because the quality of the product depends on
its development process.
A good process is usually required to produce a
good product.
For manufactured goods, process is the principal
quality determinant.
Understanding existing processes and introducing process changes to

improve product quality, reduce costs or accelerate schedules.Most
process improvement work so far has focused on defect reduction.
This reflects the increasing attention paid by industry to quality.
However, other process attributes can also be the focus of improve-
ment.
For large projects with average capabilities, the
development process determines product quality.
For small projects, the capabilities of the devel-
opers is the main determinant. The development
technology is particularly significant for small projects.
Quality Improvement
Both product and process assessment are required

for quality improvement.
• Performing Testing activities, conducting au-

dits and SQA assessments help to improve the
process throughout the organization
• Review of all the processes and documents
are done rigorously by the audit team so that
SQM 22
Figure 6: product quality factors
margin of error is very less.

• Project Leaders were helped to close the Non
Compliance of quality standards and improve
the process compliance.
Quality products and services result from quality
systems, processes and methods.
Quality is all-consuming focus of the organiza-
tion.
SQM 23
6 Process Maturity Levels
As organizations move up the maturity ladder,

they are more likely to produce higher quality
products with more predictable costs and cycle
times. The higher levels are more likely to cor-
relate with higher productivity and shorter cycle
times as well.
The idea of model based software improvement

is very simple. First pick the applicable Process
Areas. Next perform an assessment of organiza-
tional practices relative to the model. The or-
ganization practices do not have to conform ex-
actly to the representative practices included in
the model. They just have to meet the stated
goals of each PA. Based on this comparison, as-
sign a maturity level to the organization and pro-
duce a list of strengths and weakness relative to
the model.
The output of the assessment is used to priori-

tize areas for improvement. The idea is to im-
prove deficient practices at the lower maturity
levels first and systematically move up in matu-
rity level over time using additional assessments
to measure progress.
Focusing on the lowest level practices puts a firm

foundation in place before tacking the higher level
processes and it give the organization time to in-
ternalize the changes. This approach nicely avoids
the twin problems of putting practices in place
before required supporting practices are available
and trying to do too much too soon.
SQM 24
So model based improvement has a lot of very

attractive features. One of the most attractive
ones is the level goal itself. The numerical level
gives organizations a metric that that can be eas-
ily understood, can used to measure progress,
and can used to benchmark against other organi-
zations.
SEI has defined a formal appraisal methodology

and provided a lead assessor training and certi-
fication program. This means that assessment
results, particular those obtained using a third
party assessor, will be reasonably consistent and
can be used to benchmark against other organiza-
tions. In fact SEI maintains a publicly accessible
database of assessment results giving the number
of organizations at each level by industry and the
average time for an organization to improve from
one level to the next.
Process Maturity Levels
• Level 1 - Initial
• Level 2 - Repeatable
• Level 3 - Defined
• Level 4 - Managed
• Level 5 - Optimizing
SQM 25
Level 1 - Initial
1. Characteristics
• Chaotic planning, performance, and results
• Lost (i.e., forgotten) or misunderstood re-
quirements
• Unpredictable cost, schedule, and quality
performance
2. Needed Actions
• Planning (size and cost estimates, sched-
ules)
• Requirements and performance tracking
• Change control
• Management Oversite
• Quality assurance
SQM 26
Level 2 - Repeatable
1. Characteristics
• Intuitive
• Requirements and performance are tracked
• Cost and quality are highly variable
• Reasonable control of schedules
• Informal and ad hoc process methods and
procedures
- Introduce with great care ( new tools and
methods).
- To develop a new kind of project leads to
new problem.
- Organization changes can also be disruptive(
new manager).
2. Needed Actions
• Develop process standards and definitions
• Establish a process group.
• Establish methods for requirements analy-
sis, design, coding, inspection, and testing
Level 3 - Defined
1. Characteristics
• Qualitative(little).
• Requirements are logged, tracked, and closed
out
• Reliable costs and schedules
• Improving but still unpredictable quality
performance
SQM 27
2. Needed Actions
• Establish process measurements
• Establish quantitative quality goals, plans,
measurements, and tracking
Level 4 - Managed
1. Characteristics
• Quantity improvement.
• Reasonable statistical control over product
quality.
• Cost of gathering data is the problem.
2. Needed Actions
• Quantitative productivity plans and track-
ing
• Automatic gathering of process data , Ac-
curacy in manual is poor.
• Economically justified technology invest-
ments
Level 5 - Optimizing
1. Characteristics
• Quantitative basis for continued capital in-
vestment in process automation and im-
provement.
• Data relates directly to product improve-
ment.
• Error prevention through inspection that
find and fixes the bugs.
SQM 28
Figure 7: Software Process Maturity Levels
• Removal of defects by assessment of project

quality.
2. Needed Actions
• Continued emphasis on process measure-
ment and process methods for error pre-
vention
SQM 29
7 Capability Maturity Model
The CMM defines the characteristics of a ma-

ture, capable process in a way that can be mea-
sured and compared to processes at other orga-
nizations.
• The CMM consists of areas of improvement,

goals that must be met for each area, and spe-
cific practices to be implemented.
• A software engineering process group within
the organization identifies problems and in-
efficiencies and defines practices to address
them.
• Independent assessors verify that an organi-
zation is in compliance with CMM practices.
Six Sigma
Six Sigma is an approach to improving quality in manufacturing and

business processes.The term ”six sigma process” comes from the no-
tion that if one has six standard deviations between the mean of a
process and the nearest specification limit, there will be practically
no items that fail to meet the specifications. This is the basis of the
Process Capability Study, often used by quality professionals. The
term ”Six Sigma” has its roots in this tool, rather than in simple
process standard deviation, which is also measured in sigmas.
The Greek letter sigma refers to standard deviationSix Sigma

means six standard deviations from the mean.
DMAIC is a five-phase approach to Six Sigma improvement
SQM 30
Define opportunities, Measure performance, Analyze opportunity,

Improve performance, Control performance
The fundamental objective of the Six Sigma method-

ology is the implementation of a measurement-
based strategy that focuses on process improve-
ment and variation reduction through the appli-
cation of Six Sigma improvement projects. This
is accomplished through the use of two Six Sigma
sub-methodologies: DMAIC and DMADV.
The Six Sigma DMAIC process (define, measure,

analyze, improve, control) is an improvement sys-
tem for existing processes falling below specifica-
tion and looking for incremental improvement.
The Six Sigma DMADV process (define, mea-

sure, analyze, design, verify) is an improvement
system used to develop new processes or prod-
ucts at Six Sigma quality levels. It can also be
employed if a current process requires more than
just incremental improvement.
SQM 31
There are five maturity levels in the CMM model.
• Commitment to perform
• Ability to perform
• Activities performed
• Measurement and analysis
• Verifying implementation
SQM 32
Figure 8: SW-CMM maturity levels
SQM 33
In the CMM model, the maturity level of an or-

ganization tells us to what extent an organization
can produce low cost, high quality software. Hav-
ing known the current maturity level, an organi-
zation can work to reach the next higher level.
SQM 34
Figure 9: The CMM structure
SQM 35

SQM P.selvapriyavadhana

Uploaded by

Document Information

Original Description:

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

SQM P.selvapriyavadhana

Uploaded by

Copyright:

Available Formats

Software Quality Management

July 27, 2011

Author name : Selvapriyavadhana

MC9277 : SOFTWARE QUALITY MANAGEMENT

UNIT I : FUNDAMENTALS OF SOFTWARE QUALITY ENGINEERING

Concepts Of Quality - Hierarchical Modeling - Quality Models - Quality Cri-

UNIT II:DEVELOPMENTS IN MEASURING QUALITY

Selecting Quality Goals And Measures - Principles Of Measurement - Measures

UNIT III:QUALITY MANAGEMENT SYSTEM

Elements Of A Quality Engineering Program - Quality Control, Assurance And

UNIT IV:PRINCIPLES AND PRACTICES IN QMS

Process-Product-Project-People In Software Development And Management Spec-

UNIT V MEASURES AND METRICS IN PROCESS AND PROJECT DO-

Key Measures For Software Engineers - Defects - Productivity And Quality -

Fundamentals of software quality engineering

Software quality In the context of software engi-

1. Conformance to specification: Quality that

Quality is a multidimensional construct. It may therefore be consid-

• Quality is not absolute.

In an attempt to classify different and conflicting

4. The manufacturing view

2 HIERARCHICAL MODEL OF QUALITY

To compare quality in different situations, both

Many model suggested for quality.

Most are hierarchical in nature.

A quantitative assessment is generally made, along

Two principal models of this type, one by Boehm(1978)

THE HIERARCHICAL MODELS OF BOEHM

• This model was first proposed byMcCall in

The three areas addressed by McCall’s model

(basic operational characteristics)

• Correctness, the functionality matches the spec-

(ability to change) it is concerned

• Testability, the ability to Validate the soft-

(adaptability to new environments)

1. Efficiency is concerned with the use of re-

Figure 1: The GE model after McCall

7. Flexibility is the ease of making changes re-

The Boehm model (1978)

• It is to provide a set of well-defined, well-

Boehm talks of modifiability where McCall dis-

In the previous section we presented some quality management gurus

McCalls Quality Model (1977)

One of the more renown predecessors of todays quality models is the

Three major perspectives for defining and identifying the quality of

• product revision (ability to undergo changes),

• Product revision includes

Figure 2: McCalls Quality Model

Boehms Quality Model (1978)

The second of the basic and founding predeces-

The high-level characteristics represent basic high-level requirements

• As-is utility: How well (easily, reliably, effi-

extent that it facilitates the establishment of

Figure 3: Boehm’s Software Quality Characteristics Tree

4 QUALITY CRITERIA and INTERRELATION

The individual measure of software quality pro-

• Reusability vs. reliability (inverse) reusable

Figure 4: Quality criteria inter-relation

Process Improvement Strategy

Study an existing process to understand its activ-

5 Quality Improvement Model

• Set the Goal

Figure 5: Improvement Model