SSE4306

Chapter 1
Software Quality Fundamentals
 Learning Outcomes

At the end of this chapter student should be

able
• to describe the basic concepts of software quality
• give own definition of quality and software quality
• explain the costs and impacts of bad quality

2
Software Quality Concepts and Culture

• Software engineers are expected to share a commitment to

software quality as part of their culture.
• A healthy software engineering culture includes many
characteristics, including the understanding that tradeoffs
among cost, schedule, and quality are a basic tenant of the
engineering of any product.
• A strong software engineering ethic assumes that engineers
accurately report information, conditions, and outcomes
related to quality.
• Ethics also play a significant role in software quality, the
culture, and the attitudes of software engineers.
• https://youtu.be/Xo0_8CNNTWk
3
Software Quality Concepts and Culture

4
Software Quality Concepts and Culture
• Why should we, as technical people, care about such a “soft” issue?
• First, a quality culture cannot be bought. It needs to be developed,
mostly at the beginning, by the founders of the organization. Then,
as employees are selected and hired, the initial leaders culture will
start to slowly adjust to the pressures of the environment.
• Quality culture cannot be bolted on to an organization, it has to be
designed-in and nurtured. The ultimate aim of upper management
is to instill a culture that will allow the development of high-quality
products, and offer them at competitive prices, in order to generate
revenues and dividends in an organization where employees are
committed and satisfied.

5
Software Quality Concepts and Culture
• The second reason, any change an organization wants to
make, for example moving up on the CMMI maturity scale,
cannot simply be ordered; the organization has to cope with
the current culture when making a change in maturity,
especially when such a change implies a profound change in
that culture.
• An organization cannot just buy and deploy off-the-shelf
processes that contain quality.
• It has been demonstrated that one of the major inhibitors of
change is the culture of the organization.
• The management of change is imperative in order to achieve
the desired result.

6
Software Quality Concepts and Culture

7
 What does quality mean?

• Producing quality products has been identified as a key factor

in the long term success (i.e. profitability) of organizations.
• Quality doesn’t happen by chance.
• Quality requires on ongoing commitment by all parties
(management, designers, developers).
• The commitment to quality includes the use of careful
development processes. Quality control must be embedded
into the process.

8
Perspectives on quality

9
 Definitions of quality
Oxford English Dictionary: the standard of something as
measured against other things of a similar kind; the degree of
excellence of something
Crosby: zero defects
ISO: The totality of features and characteristics of a product or
service that bear on its ability to satisfy specified or implied
needs.
Juran: Fitness for Purpose
DoD: The degree to which the attributes of the software enable
it to perform its intended end use.

10
 DEFINITION: QUALITY
• Quality is conformance to requirements, both
explicit and implicit.

• Implicit and Explicit Requirement

– Think of a car :
– Explicit requirements are the size of engine, number of
doors, color, etc (user-based & manufacturing views).
– Implicit requirements include the standards to which the
car has been built (product based view).
 DEFINITION: SOFTWARE QUALITY

• ISO 9000 (also known as BS 5750) Software Quality

is defined as the totality of features and
characteristics of a product or service that bear on
its ability to satisfy stated or implied need.

• IEEE Standard Glossary of Software Engineering

Terminology, software quality is defined as the
degree to which software possesses a desired
combination of attributes. [IEEE Std. 1061]
 DEFINITION : SOFTWARE QUALITY

• Another IEEE definition : “Totally of features and

characteristics of a software product that bear on its
ability to satisfy given needs; for example, conform to
specifications”.

• Department of Defense Standard on Software

Quality Evaluation(DOD-STD-2168) provides this
definition: “The ability of a software product to
satisfy its specified requirement”.
 DEFINITION : SOFTWARE QUALITY
• Operational meanings:
– Software does what is wanted and expected
– On budget and on schedule
– Users are happy
– Level of bugginess is tolerable
– Changes are not too expensive
– Software is cost-effective in use and supports
organizational mandate

14
15
 Value and Costs of Quality
• CoSQ - a set of measurements derived from the economic
assessment of software quality development and
maintenance processes
• Defining and then achieving software quality is not simple.
Quality characteristics may or may not be required, or they
may be required to a greater / lesser degree-tradeoffs
• CoSQ: To determine the level of software quality, i.e.,
achieving stakeholder value,
• The level of quality in a software product can be inferred from
the cost of activities related to dealing with the consequences
of poor quality.

16
17
18
19
20
21
 Four cost of quality categories
1. Prevention – (build a quality product)
– Include investments in software process improvement efforts, quality
infrastructure, quality tools, training, audits, and management
reviews.
– costs are usually not specific to a project; they span the organization.
2. Appraisal –( assess quality of product)
– arise from project activities that find defects.
– costs of reviews (design, peer) and costs of testing (software unit
testing, software integration, system level testing, acceptance testing);
– appraisal costs would be extended to subcontracted software
suppliers.

22
 Four cost of quality categories
3. internal failure (failure found by the project)
– incurred to fix defects found during appraisal activities and discovered
prior to delivery of the software product to the customer.
• Eg. Rework, scrap

4. external failure. (failure found by the customer)

– include activities to respond to software problems discovered after
delivery to the customer.
• Eg. Liabilities, law suits, product recalls; warranty work; lost business AND loss
credibility
• Software engineers should be able to use CoSQ methods to ascertain
levels of software quality and should also be able to present quality
alternatives and their costs so that tradeoffs between cost, schedule, and
delivery of stakeholder value can be made.

23
24
25
Example: https://www.wallstreetmojo.com/cost-of-quality/

26
Models and Quality Characteristics
• Quality models for software have been developed to assess
both software processes and software products.
• Terminology for software quality characteristics differs from
one taxonomy (or model of software quality) to another,
• Each model perhaps having a different number of
hierarchical levels and a different total number of
characteristics.
• Various authors have produced models of software quality
characteristics or attributes that can be useful for discussing,
planning, and rating the quality of software products. ISO/IEC
25010: 2011 defines product quality and quality in use as two
related quality models.
27
McCall’s Quality Model

28
Boehm’s Quality Model

29
30
31
32
 Software Process Quality
• Software quality management and software engineering
process quality have a direct bearing on the quality of the
software product.
• Models and criteria that evaluate the capabilities of software
organizations are primarily project organization and
management considerations
• It is not possible to completely distinguish process quality
from product quality because process outcomes include
products.
• Determining whether a process has the capability to
consistently produce products of desired quality is not simple.
• The software engineering process influences the quality
characteristics of software products, which in turn affect
quality as perceived by stakeholders.
33
 Software Product Quality
• The software engineer must determine the real purpose of
the software. In this regard, stakeholder requirements are
paramount, and they include quality requirements in addition
to functional requirements.
• Thus, software engineers have a responsibility to elicit
quality requirements that may not be explicit at the outset
and to understand their importance as well as the level of
difficulty in attaining them.
• All software development processes (e.g., eliciting
requirements, designing, constructing, improving quality) are
designed with these quality requirements in mind and may
carry additional development costs if attributes such as
safety, security, and dependability are important.
34
 Software Product Quality
• The additional development costs help ensure that quality
obtained can be traded off against the anticipated benefits.
• The term work-product means any artifact that is the
outcome of a process used to create the final software
product. E.g. a system/subsystem specification, a software
requirements specification for a software component of a
system, a software design description, source code, software
test documentation, or reports.
• While some treatments of quality are described in terms of
final software and system performance, sound engineering
practice requires that intermediate work-products relevant
to quality be evaluated throughout the software engineering
process.
35
Software quality in the context of the products and process of software development

36
 Software Quality Improvement
• The quality of software products can be improved through
preventative processes or an iterative process of continual
improvement.
• It requires management control, coordination, and feedback
from many concurrent processes: (1) the software life cycle
processes, (2) the process of fault/defect detection, removal,
and prevention, and (3) the quality improvement process.
• The theory and concepts behind quality improvement—such
as building in quality through the prevention and early
detection of defects, continual improvement, and stakeholder
focus—are pertinent to software engineering.

37
 Software Quality Improvement
• These concepts are based on the work of experts in quality
who have stated that the quality of a product is directly linked
to the quality of the process used to create it.
• Approaches such as the Deming improvement cycle of Plan-
Do-Check- Act (PDCA), evolutionary delivery, kaizen, and
quality function deployment (QFD) offer techniques to
specify quality objectives and determine whether they are
met.
• Management support implies that each improvement project
has enough resources to achieve the goal defined for it.

38
 Deming’s PDCA Cycle

• Plan: identify and analyze the problem or opportunity, develop hypotheses about
what the issues may be, and decide which one to test.
• Do: test the potential solution, ideally on a small scale, and measure the results.
• Check/Study: study the result, measure effectiveness, and decide whether the
hypothesis is supported or not.
• Act: if the solution was successful, implement it
(Source: https://www.mindtools.com/pages/article/newPPM_89.htm)
39
40
 Software Safety
• Safety-critical systems are those in which a system failure
could harm human life, other living things, physical structures,
or the environment.
– E.g. mass transit systems, chemical manufacturing plants, and medical
devices.
• Safety-critical software can be categorized as direct or
indirect.
• Direct is that software embedded in a safety-critical system,
such as the flight control computer of an aircraft.
• Indirect includes software applications used to develop
safety-critical software. Indirect software is included in
software engineering environments and software test
environments.
41
 Software Safety
• Three complementary techniques for reducing the risk of
failure are avoidance, detection and removal, and damage
limitation.
• These techniques impact software functional requirements,
software performance requirements, and development
processes.
• Increasing levels of risk imply increasing levels of software
quality assurance and control techniques such as inspections.
• Higher risk levels may necessitate more thorough inspections
of requirements, design, and code or the use of more formal
analytical techniques.

42
43