Chapter One

Software Quality
 Introduction
 What is Quality ?
 For software, two kinds of quality may be encountered
o Quality of design: refers to characteristics that designers specify for
the end product to be constructed. Quality of design encompasses
requirements, specifications, and the design of the system.
o Quality of conformance: is the degree to which design
specifications are followed during developing the product. Quality
of conformance is an issue focused primarily on implementation.
 User satisfaction = compliant product + good quality + delivery
within budget and schedule

2
Software Quality
“An effective software process applied in a manner that
creates a useful product that provides measurable value
for those who produce it and those who use it.”
 Effective software process
 Infrastructure
 Check and balance
 Change control and technical reviews
 Useful product
 Explicit and implicit requirements
 Reliable, error-free

3
Software Quality -Definition
 Add value for producer and user of a software product
 Less maintenance effort
 Efficient business process

 IEEE Definition:
Software quality is:
The degree to which a system, component, or process
meets specified requirements.
The degree to which a system, component, or process
meets customer or user needs or expectations.
4
Software Quality- Definition
 According to Philip B. Crosby(1979):
“Quality means conformance to requirements”
 Analysis :
Crosby’s definition of software quality refers to the degree
to which the written software meets the specifications
prepared by the customer and his professional team.
This means that errors included in the software
specification are not considered and do not reduce the
software quality, a characteristic that can be considered the
approach’s deficiency.

5
Software Quality- Definition
 According to Joseph M. Juran(1988):
Quality consists of those product features which meet the
needs of customers and thereby provide product
satisfaction.
Quality consists of freedom from deficiencies”
 Analysis:
Juran’s definition is aimed at achieving customer
satisfaction, and views the fulfillment of customers’ real
needs as the true goal of software quality.

6
 Software Quality- Definition
 According to Pressman:
Software quality is defined as:
“Conformance to explicitly stated functional and performance
requirements, explicitly documented development standards, and
implicit characteristics that are expected of all professionally
developed software”.
 Analysis:
Pressman’s definition suggests three requirements for quality
that are to be met by the developer:
Specific functional requirements, which refer mainly to the outputs of the
software system.
The software quality standards mentioned in the contract.
Good Software Engineering Practices (GSEP), reflecting state-of-the-art
professional practices
7
Software Quality Factors
 The requirements document is one of the most important
elements for achieving software quality.
 The great variety of issues related to the various attributes
of software and its use and maintenance, as defined in
software requirements documents, can be classified into
content groups called quality factors.
 Classifications of software requirements into software
quality factors:
Several models of software quality factors and their
categorization in factor categories have been suggested
over the years and few are:
8
Software Quality Factors
The classic model of software quality factors,
suggested by McCall, consists of 11 factors.
 McCall’s factor model
McCall’s factor model classifies all software
requirements into 11 software quality factors.
The 11 factors are grouped into three categories –
product operation, product revision and product
transition – as follows:

9
Software Quality Factors : McCall’s factor model
 Product operation factors: Correctness, Reliability,
Efficiency, Integrity, Usability.
 Product revision factors: Maintainability, Flexibility,
Testability.
 Product transition factors: Portability, Reusability,
Interoperability.

McCall’s model and its categories are illustrated by the

McCall model of software quality factors tree, which on
next slide.

10
Software Quality Factors : McCall’s factor model

11
McCall’s Model
Portability:
Maintainability: Will I be able to use it on
Can I fix it? another machine?
Flexibility: Reusability:
Can I change it? Will I be able to reuse some of
Testability: Product Product
transition the software?
Can I test it? revision Interoperatability:
Product Will I be able to interface it with
operations another machine / software?
Correctness: Does it do what I want?
Reliability: Does it do it accurately all the time?
Efficiency: Will it run on my machine as well as it can?
Integrity: Is it secure?
Usability: Can I run it?
12
McCall’s factor model: Product operation
software quality factors

 According to McCall’s model, five software quality

factors are included in the product operation
category, all of which deal with requirements that
directly affect the daily operation of the software.
These factors are as follows.
Correctness
Reliability
Efficiency
Integrity
Usability
13
McCall’s factor model: Product operation software
quality factors
 (Correctness)
Correctness requirements are defined in a list of the
software system’s required outputs, such as a query display
of a customer’s balance in the sales accounting information
system.
Output specifications are usually multidimensional.
 Reliability
Reliability requirements deal with failures to provide
service. They determine the maximum allowed software
system failure rate, and can refer to the entire system or to
one or more of its separate functions.
14
McCall’s factor model: Product operation software
quality factors
 Efficiency
Efficiency requirements deal with the hardware resources
needed to perform all the functions of the software system in
conformance to all other requirements.
The main hardware resources to be considered are :
The computer’s processing capabilities (measured in MIPS –
million instructions per second, MHz or megahertz – million
cycles per second, etc.)
Its data storage capability in terms of memory and disk
capacity (measured in MBs – megabytes, GBs – gigabytes, TBs
– terabytes, etc.)
15
McCall’s factor model: Product operation software
quality factors
The data communication capability of the
communication lines (usually measured in KBPS – kilobits
per second, MBPS – megabits per second, and GBPS –
gigabits per second).
Integrity
Integrity requirements deal with the software system
security, that is, requirements to prevent access to
unauthorized persons, to distinguish between the majority of
personnel allowed to see the information (“read permit”) and
a Software quality factors limited group who will be allowed
to add and change data (“write permit”), and so forth.

16
 McCall’s factor model: Product operation software
quality factors
 Usability
Usability requirements deal with the scope of staff resources
needed to train a new employee and to operate the software system.
 Example
The software usability requirements document for the new help
desk system initiated by a home appliance service company lists the
following specifications:
(a) A staff member should be able to handle at least 60 service calls a
day.
(b) Training a new employee will take no more than two days (16
training hours), immediately at the end of which the trainee will be
able to handle 45 service calls a day.
17
McCall’s factor model: Product revision software
quality factors
 According to the McCall model of software quality factors,
three quality factors comprise the product revision
category.
 These factors deal with those requirements that affect the
complete range of software maintenance activities:
 Corrective maintenance (correction of software faults and
failures).

 Adaptive maintenance (adapting the current software to

additional circumstances and customers without changing
the software)
18
McCall’s factor model: Product revision software
quality factors
 perfective maintenance (enhancement and improvement of
existing software with respect to locally limited issues).
These are as follows:
Maintainability
Maintainability requirements determine the
efforts that will be needed by users and
maintenance personnel to identify the reasons for
software failures, to correct the failures, and to
verify the success of the corrections.

19
McCall’s factor model: Product revision software
quality factors

 Flexibility
The capabilities and efforts required to support adaptive
maintenance activities are covered by the flexibility requirements.
These include the resources required to adapt a software
package to a variety of customers of the same trade, of various
extents of activities, of different ranges of products and so on.
This factor’s requirements also support perfective maintenance
activities, such as changes and additions to the software in order
to improve its service and to adapt it to changes in the firm’s
technical or commercial environment.

20
McCall’s factor model: Product revision software
quality factors

 Example
TSS (teacher support software) deals with the documentation
of pupil achievements, the calculation of final grades, the
printing of term grade documents, and the automatic printing
of warning letters to parents of failing pupils.
The software specifications included the following flexibility
requirements:
(a) The software should be suitable for teachers of all subjects
and all school levels (elementary, junior and high schools).
.
21
McCall’s factor model: Product revision software
quality factors

(b) Non-professionals should be able to create new types of

reports according to the schoolteacher’s requirements
and/or the city’s education department demands.

 Testability
Testability requirements deal with the testing of an
information system as well as with its operation. Testability
requirements for the ease of testing are related to special
features in the programs that help the tester, for instance by
providing predefined intermediate results and log files.

22
McCall’s factor model: Product revision
software quality factors
Testability requirements related to software operation include
automatic diagnostics performed by the software system prior to
starting the system, to find out whether all components of the
software system are in working order and to obtain a report about
the detected faults.
Another type of these requirements deals with automatic
diagnostic checks applied by the maintenance technicians to detect
the causes of software failures.
 Example: An industrial computerized control unit is
programmed to calculate various measures of production status,
report the performance level of the machinery, and operate a
warning signal in predefined situations.
23
 McCall’s factor model :Product transition software
quality factors
 According to McCall, three quality factors are included in the
product transition category, a category that pertains to the
adaptation of software to other environments and its interaction
with other software systems.
 Portability :
Portability requirements tend to the adaptation of a software
system to other environments consisting of different hardware,
different operating systems, and so forth.
These requirements make it possible to continue using the same
basic software in diverse situations or to use it simultaneously
in diverse hardware and operating systems situations.
24
McCall’s factor model :Product transition software
quality factors
 Example
A software package designed and programmed to operate in
a Windows 2000 environment is required to allow low-cost
transfer to Linux and Windows NT environments.
 Reusability
Reusability requirements deal with the use of software
modules originally designed for one project in a new software
project currently being developed.
They may also enable future projects to make use of a given
module or a group of modules of the currently developed
software.
25
McCall’s factor model :Product transition software
quality factors
The reuse of software is expected to save development
resources, shorten the development period, and provide
higher quality modules.
These benefits of higher quality are based on the
assumption that most of the software faults have already
been detected by the quality assurance activities performed
on the original software, by users of the original software,
and during its earlier reuses.
The issues of software reuse became a subject of
software industry standards

26
McCall’s factor model :Product transition software
quality factors
 Example
A software development unit has been required to develop a software
system for the operation and control of a hotel swimming pool that
serves hotel guests and members of a pool club. Although the
management did not define any reusability requirements, the unit’s
team leader, after analyzing the information processing requirements of
the hotel’s spa, decided to add the reusability requirement that some of
the software modules for the pool should be designed and programmed
in a way that will allow its reuse in the spa’s future software system,
which is planned to be developed next year.
 These modules will allow- entrance validity checks of
membership cards and visit recording.

27
 McCall’s factor model :Product transition software quality factors

 Interoperability
Interoperability requirements focus on creating interfaces with
other software systems or with other equipment firmware (for
example, the firmware of the production machinery and testing
equipment interfaces with the production control software).
Interoperability requirements can specify the name(s) of the
software or firmware for which interface is required. They can
also specify the output structure accepted as standard in a
specific industry or applications area.
E.g The firmware of a medical laboratory’s equipment is required to process
its results (output) according to a standard data structure that can then serve
as input for a number of standard laboratory information systems.

28
 Quality Measurement
 A quality measure is in effect a rule (or the result of a
rule) that assigns numeric values to a specific quality
indicator.
 Quality measures take on numeric values.
 Measure - quantitative indication of extent/degree,
amount, dimension, capacity, or size of some
attribute of a product or process. E.g., Number of
errors

29
Principles Of Measurement
 The objectives of measurement should be established before
data collection begins.
1. Formulation - The derivation/origin of software measures and
metrics appropriate for the representation of the software that is
being considered.
2. Collect information - The mechanism used to accumulate data
required to derive the formulated metrics.
3. Analysis information - The computation of metrics and the
application of mathematical tools.
4. Interpretation -The evaluation of metrics results in an effort to
gain insight /awareness into the quality of the representation.
30
Types of Measures
 Direct Measures (internal attributes)
 Cost,
 Effort,
 Speed,
 Memory
 Indirect (external attributes)
 Functionality,
 Quality,
 Complexity,
 Efficiency, Reliability, Maintainability
31
Why Measure Software?

 Determine the quality of the current product or process.

 Predict qualities of a product/process

 Improve quality of a product/process

32
 Metrics Measurement
 Quantitative measure of degree to which a system,
component or process possesses a given attribute. Handle or
guess about a given attribute.
 E.g., Number of errors found per person hours expended.
Motivation for Metrics
 Estimate the cost and schedule of future projects.
 Evaluate the productivity impacts of new tools and techniques.
 Establish productivity trends over time.
 Improve software quality.
 Forecast future staffing needs.
 Anticipate and reduce future maintenance needs.
33
 Product Quality Metrics

 The definition of software quality consists of two levels:

intrinsic/ core product quality and customer
satisfaction. The metrics we discuss here cover both
levels:
 Mean time to failure
 Defect density
 Customer problems
 Customer satisfaction.
34
Customer Satisfaction Metrics
 Customer satisfaction is often measured by
customer survey data via the five point scale:
 Very satisfied
 Satisfied

 Neutral

 Dissatisfied

 Very dissatisfied

35
Metrics Measurement Cont’d

 Based on the five-point-scale data, several metrics with

slight variations can be constructed and used, depending
on the purpose of analysis.
 For example:
1. Percent of completely satisfied customers.
2. Percent of satisfied customers (satisfied and completely
satisfied).
3. Percent of dissatisfied customers (dissatisfied and
completely dissatisfied)
4. Percent of nonsatisfied (neutral, dissatisfied, and completely
dissatisfied)
36
 GOAL QUESTION METRIC(GQM) Model
 The Goal Question Metric (GQM) approach is based upon the
assumption that for an organization to measure in a purposeful way it
must first specify the goals for itself and its projects, then it must trace
those goals to the data that are intended to define those goals
operationally, and finally provide a framework for interpreting the
data with respect to the stated goals.

 The result of the application of the Goal Question Metric

model is the specification of a measurement system
targeting a particular set of issues and a set of rules for the
interpretation of the measurement data. The resulting
measurement model has three levels:

37
 GQM Model

1. Conceptual level (GOAL): A goal is defined for an

object, for a variety of reasons, with respect to various
models of quality, from various points of view, relative to
a particular environment. Objects of measurement are-
 Products: Artifacts, deliverables and documents that are produced
during the system life cycle;
E.g., specifications, designs, programs, test suites.
 Processes: Software related activities normally associated with time;
E.g., specifying, designing, testing, interviewing.
 Resources: Items used by processes in order to produce their
outputs;
E.g., personnel, hardware, software, office space.
38
 GQM Model
2. Operational level (QUESTION): A set of questions is used to
characterize the way the assessment/achievement of a
specific goal is going to be performed based on some
characterizing model. Questions try to characterize the object
of measurement (product, process, resource) with respect to
a selected quality issue and to determine its quality from the
selected viewpoint.

3. Quantitative level (METRIC): A set of data is associated with

every question in order to answer it in a quantitative way.

39
Glib's Attributes

40
 Glib’s (Goal Literal Babbling) Approach
 Availability
 Availability is concerned with the proportion of elapsed time
that a system is able to be used. The sub attributes highlighted
here are reliability, maintainability and integrity.
 Reliability
 Reliability is the degree to which the system does what it is supposed to do.
 Because the purpose of each system is different, and the purpose of
different parts of the system is different, the way in which reliability is
assessed may also vary.
 Glib suggests that reliability may be assessed in terms for both logic ware
(code) and data ware (data files),

41
 Glib’s Approach

 Maintainability
Maintainability refers to the process of fault handling. Some of the
principal sub-attributes are:
1. Problem recognition time is the time required to
recognize that a fault exists.
2. Administrative delay is the time between recognition of a
problem and activity designed to rectify it.
3. Tool collection is the time required to gather all relevant
information, e.g. program analysis and documentation.
4. Problem analysis is the time needed to trace the source
of the problem.
42
 Maintainability Cont’d

5. Correction hypothesis time is the time required to come up

with a possible solution.
6. Inspection time is the time taken to evaluate said solution.
7. Active correction is the time to implement a hypothesized
correction.
8. Testing is the time taken to adequately test cases to validate
the change.
9. Test evaluation is the time needed to evaluate the test
results.
10. Recovery is the time required to recover and restore the
system.
43
Glib’s Approach-
 Integrity
 The integrity of a system is a measure of its ability to
remain intact whilst under threat.
 It may be regarded as the ability of in-built security
functions to cope with threats.
 Threats may come from human action (deliberate or
otherwise) or machine action, either hardware or
software driven.
 Integrity affects availability. A system with poor
integrity is likely to be unavailable for much of the
time.
44
 Glib’s Approach

 Adaptability
 Adaptability may be considered in terms of improvability, extendibility and
portability.
 Improvability is the time taken to make minor changes to the system where
the term ' system' is taken to include items such as documentation.
 Extendibility is the ease of adding new functionality to a system.
 Portability is the ease of moving a system from one environment to another.
 Usability
 Usability may be considered as the ease of use and effectiveness of use of a
system.
 This may be considered in terms of handling ability, entry requirements,
learning requirements etc,

45
Thank you

46