Lecture # 1

Software Quality
Dr. Aprna Tripathi
 Course Objectives
• At the end of this course students will be able
to:
– Understand quality management processes
– Distinguish between the various activities of
quality assurance, quality planning and quality
control.
– Understand the importance of standards in the
quality management process and their impact on
the final product.
 Topics Covered
• Quality
• Software Quality
• Software Quality Attributes and Specification,
• Total Quality Management
 Faults
What is the difference between a fault and
an error? What are some kinds of faults?
 error: incorrect software behavior
 example: message box text said "Welcome null."

 fault: mechanical or algorithmic cause of error

 example: account name field is not set properly.
 a fault is not an error, but it can lead to them
 need requirements to specify desired behavior, and need to see system deviate from
that behavior, to have a failure

4
 Defect, Failure and Fault
• Defect
– Commonly refers to several troubles with the software
products, with its external behavior or with its internal
features.
• Failure
– The incapacity of a system to conduct its required functions
within clarified performance requirements.
• Fault
– A false, wrong step, process or data definition in a software
product.
– Fault refers to an underlying condition within software that
causes failure to happen.
 Error
• Error
– A person act that generates an erroneous result.
– Consequently, the term failure refers to a behavioral
deviation from the user wants or the product
specification.
– Error refers to a missing or wrong person action
resulting in certain fault being injected into software.
– Errors also include error sources such as human
misunderstandings, dissensions, misinterpretation and
so on.
 Bug
• Any Missing functionality or any action that is
performed by the system which is not supposed to
be performed is a Bug.
"Is an error found BEFORE the application goes
into production?"
Any of the following may be the reason for birth
of Bug
1. Wrong functionality
2. Missing functionality
3. Extra or unwanted functionality
• A defect is a deviation from the requirements.
• A defect does not necessarily mean there is a
bug in the code, it could be a function that was
not implemented but defined in the
requirements of the software.
 Some types of faults
• algorithmic faults
– design produces a poor algorithm
– fail to implement the software to match the spec
– subsystems don't communicate properly

• mechanical faults
– earthquake
– virtual machine failure
(why is this a "mechanical" fault?)

9
 Quality
• The standard of something as measured against
other things of a similar kind; the degree of
excellence of something.
• ISO 8402-1986 standard defines quality as
"the totality of features and characteristics of a
product or service that bears its ability to
satisfy stated or implied needs."
 Pressman's definition of
"Software Quality"
Conformance to explicitly stated functional and
performance requirements, explicitly
documented development standards, and implicit
characteristics that are expected of all
professionally developed software.
 IEEE Definition of
"Software Quality"

1. The degree to which a system, component, or

process meets specified requirements.
2. The degree to which a system, component, or
process meets customer or user needs or
expectations.
 Software Quality ??
• Quality must be defined and measured if improvement is to be
achieved. Yet, a major problem in quality engineering and
management is that the term quality is ambiguous, such that it is
commonly misunderstood.
• The confusion may be attributed to several reasons.
• First, quality is not a single idea, but rather a multidimensional
concept. The dimensions of quality include the entity of interest, the
viewpoint on that entity, and the quality attributes of that entity.
• Second, for any concept there are levels of abstraction; when people
talk about quality, one party could be referring to it in its broadest
sense, whereas another might be referring to its specific meaning.
• Third, the term quality is a part of our daily language and the
popular and professional uses of it may be very different.
 Quality: Popular Views
• A popular view of quality is that it is an intangible
trait
• it can be discussed, felt, and judged, but cannot be
weighed or measured.
• One popular view: quality cannot be controlled
and managed, nor can it be quantified.
• I know it, when I see it.
• Another popular view is that quality connotes
luxury, class, and taste. Or in other words,
inexpensive products can hardly be classified as
quality products.
 Quality: Professional View
• Crosby (1979) defines quality as "conformance to
requirements"
• Juran and Gryna (1970) define it as "fitness for
use."
• "Conformance to requirements" implies that
requirements must be clearly stated such that they
cannot be misunderstood.
• The "fitness for use" definition takes customers'
requirements and expectations into account,
which involve whether the products or services fit
their uses.
 Two perspectives on quality
• (customer satisfaction as the ultimate validation of
quality and
• producer's adherence to requirements to achieve
quality),
• the de facto definition of quality consists of two levels.
– The first is the intrinsic product quality, often operationally
limited to the product's defect rate and reliability. This
narrow definition is referred to as the "small q" (q for
quality).
– The broader definition of quality includes product quality,
process quality, and customer satisfaction, and it is referred
to as the "big Q."
 Two Level Concept of Quality
The two-level concept of quality is supposed to form a closed-loop cycle:
 Software Quality
• In software, the narrowest sense of product
quality is commonly recognized as lack of "bugs"
in the product.
• This definition is usually expressed in two ways:
– defect rate (e.g., number of defects per million lines of
source code, per function point, or other unit) and
– reliability (e.g., number of failures per n hours of
operation, mean time to failure, or the probability of
failure-free operation in a specified time).
 Software Quality
• IBM monitors satisfaction with its software
products in levels of CUPRIMDSO (capability
[functionality], usability, performance,
reliability, installability, maintainability,
documentation/information, service, and
overall).
• Hewlett-Packard focuses on FURPS
(functionality, usability, reliability,
performance, and serviceability).
Interrelationships of Software
Attributes
 Total Quality Management (TQM)
• It represents a style of management aimed at
achieving long-term success by linking quality
and customer satisfaction.
• Basic to the approach is the creation of a
culture in which all members of the
organization participate in the improvement of
processes, products, and services.
Key elements of a TQM system
 Key elements of a TQM system
• Customer focus: The objective is to achieve total
customer satisfaction. Customer focus includes
– studying customers' wants and needs,
– gathering customers' requirements, and
– measuring and managing customers' satisfaction.
• Process: The objective is to reduce process
variations and to achieve continuous process
improvement. This element includes both the
business process and the product development
process.
 Cont’d…
• Human side of quality: The objective is to create a
companywide quality culture. Focus areas include
– leadership,
– management commitment,
– total participation,
– employee empowerment, and
– other social, psychological, and human factors.
• Measurement and analysis: The objective is to drive
continuous improvement in all quality parameters by
the goal-oriented measurement system.
 Frameworks to Improve Quality
• Plan-Do-Check-Act
• Quality Improvement Paradigm/ Experience
Factory Organization
• Software Engineering Institute (SEI)
Capability Maturity Model
 Plan-Do-Check-Act
• It is based on a feedback cycle for optimizing a
single process or production line.
• It uses techniques, such as feedback loops and
statistical quality control, to experiment with
methods for improvement and to build
predictive models of the product.
 Quality Improvement Paradigm
Paradigm/Experience Factory Organization
• It aims at building a continually improving
organization, based on its evolving goals and an
assessment of its status relative to those goals.
• There are six fundamental steps of the Quality
Improvement Paradigm are
– (1) characterize the project and its environment,
– (2) set the goals,
– (3) choose the appropriate processes,
– (4) execute the processes,
– (5) analyze the data, and
– (6) package the experience for reuse.
 SEI Capability Maturity Model
• The SEI Capability Maturity Model is a staged
process improvement, based on assessment of
key process areas, until you reach level 5,
which represents a continuous process
improvement.