Because learning changes everything.

Chapter 15
Quality Concepts

Part Three – Quality and Security

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 What is Quality?
The American Heritage Dictionary defines quality as “a
characteristic or attribute of something.”
For software, three kinds of quality may be encountered:
• Quality of design encompasses requirements, specifications, and
the design of the system.
• Quality of conformance is an issue focused primarily on
implementation.
• User satisfaction = compliant product + good quality + delivery
within budget and schedule.

© McGraw Hill 2
 Quality – Pragmatic Views
The user view sees product quality in terms of meeting the
end-user’s specific goals.

The product view suggests that quality can be tied to inherent

characteristics (for example: functions and features) of a
product.

The value-based view measures quality based on how much a

customer is willing to pay for a product.

Quality includes all of these views and more.

© McGraw Hill 4
 Software Quality
Software quality can be defined as:
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.

Advantages of providing useful products:

1. Greater software product revenue.
2. Better profitability when an application supports a business
process.
3. Improved availability of information that is crucial for the
business.

© McGraw Hill 5
 Software Quality – Effective Process
• An effective software process establishes infrastructure that
supports building a high-quality software product.
• The management aspects of process create the checks and
balances that help avoid project confusions—a key contributor to
poor quality.
• Software engineering practices allow the developer to analyze
the problem and design a solid solution—both critical to
building high quality software.
• Umbrella activities such as change management and technical
reviews have as much to do with quality as any other part of
software engineering practice.

© McGraw Hill 6
 Software Quality – Useful Product
• A useful product delivers the content, functions, and features that
the end-user desires.
• But as important, it delivers these assets in a reliable, error free
way.
• A useful product always satisfies those requirements that have
been explicitly stated by stakeholders.
• A useful product satisfies a set of implicit requirement that are
expected of all high-quality software.

© McGraw Hill 7
 Software Quality – Adding Value
• By adding value for both the producer and user of a software
product, high quality software provides benefits for the software
organization and the end-user community.
• The software organization gains added value because high
quality software requires less maintenance effort, fewer bug
fixes, and reduced customer support.
• The user community gains added value because the application
provides a useful capability in a way that expedites some
business process.

© McGraw Hill 8
 McCall’s Quality Factors

Access the text alternative for slide images

© McGraw Hill 9
 McCall’s Quality Factors - Text alternative
Return to parent-slide containing images.

A pyramidical illustration displays McCall's quality factors. The faces of the

pyramid are labeled: product revision, product transition, and product operation.
Product operation verifies: correctness, reliability, usability, integrity, and
efficiency. Product transition verifies: portability, reusability, and interoperability.
Product revision verifies: testability, flexibility, and testability.

Return to parent-slide containing images.

© McGraw Hill 10
 Quality in Use – ISO25010:2017
• Effectiveness. Accuracy and completeness with which users
achieve goals.
• Efficiency. Resources expended to achieve user goals completely
with desired accuracy.
• Satisfaction. Usefulness, trust, pleasure, comfort
• Freedom from risk. Mitigation of economic, health, safety, and
environmental risks.
• Context coverage. Completeness, flexibility.

© McGraw Hill 11
 Product Quality – ISO25010:2017
8 Features
• Functional suitability. Complete, correct, appropriate.
• Performance efficiency. Timing, resource use, capacity.
• Compatibility. Coexistence, interoperability.
• Usability. Appropriateness, learnability, operability, error
protection, aesthetics, accessibility.
• Reliability. Maturity, availability, fault tolerance.
• Security. Confidentiality, integrity, authenticity.
• Maintainability. Reusability, modifiability, testability.
• Portability. Adaptability, installability, replaceability.

© McGraw Hill 12
 Software Quality Dilemma
• If you produce a software system that has terrible quality, you
lose because no one will want to buy it.
• If you spend infinite time, extremely large effort, and huge sums
of money to build a perfect piece of software, then it's going to
take so long to complete and will be so expensive to produce that
you'll be out of business.
• You will either missed the market window, or you exhausted all
your resources.
• People in industry try to find that magical middle ground where
the product is good enough not to be rejected right away, but
also not the object of so much perfectionism that it would take
too long or cost too much to complete.

© McGraw Hill 13
 Good Enough Software
Arguments against “good enough” (buggy software):
• It is true that “good enough” may work in some application
domains and for a few major software companies.

• If you work for a small company and you deliver a “good

enough” (buggy) product, you risk permanent damage to your
company’s reputation and may lose customers.

• If you work in certain application domains (for example: real

time embedded software - application software that is integrated
with hardware) delivering “good enough” may be considered
negligent and open your company to expensive litigation.

© McGraw Hill 14
 Cost of Quality
• Prevention costs - quality planning, formal technical reviews,
test equipment, training.

• Appraisal costs - conducting technical reviews, data collection

and metrics evaluation, testing and debugging.

• Internal failure costs – rework, repair, failure mode analysis.

• External failure costs - complaint resolution, product return and

replacement, help line support, warranty work

© McGraw Hill 15
 Relative Costs to Find and Repair a
Defect

Access the text alternative for slide images.

© McGraw Hill 16
 Relative Costs to Find and Repair a Defect - Text alternative
Return to parent-slide containing images.

A graph displays relative costs to find and repair a defect. The graph plots
requirements, design, coding, testing, and maintenance on the x axis and the
relative costs on the y-axis. The relative costs to repair a defect are as follow:
requirements at $139, design at $455, coding at $977, testing at $7,136, and
maintenance at $14,102.

Return to parent-slide containing images.

© McGraw Hill 17
 Quality, Risk, and Security
• Low quality software increases risks for both developers and
end-users.
• When systems are delivered late, fail to deliver functionality, and
does not meet customer expectations litigation ensues.
• Low quality software is easier to hack and can increase the
security risks for the application once deployed.
• A secure system cannot be built without focusing on quality
(security, reliability, dependability) during design.
• Low quality software is able to contain architectural flaws as
well as implementation problems (bugs).

© McGraw Hill 18
 Impact of Management Decisions
• Estimation decisions – irrational delivery date estimates cause
teams to take short-cuts that can lead to reduced product quality.

• Scheduling decisions – failing to pay attention to task

dependencies when creating the project schedule.

• Risk-oriented decisions – reacting to each crisis as it arises

rather than building in mechanisms to monitor risks may result in
products having reduced quality.

© McGraw Hill 19
 Achieving Software Quality 1

Software quality is the result of good project management and

solid engineering practice.

To build high quality software you must understand the problem to

be solved and be capable of creating a quality design the conforms
to the problem requirements.

Project management – project plan includes explicit techniques for

quality and change management.
1. Use estimation to verify that delivery dates are achievable.
2. Schedule is understood and team avoids taking shortcuts.
3. Risk planning is conducted so problems do not breed confusions, software
quality will be affected in a positive way.

© McGraw Hill 20
 Achieving Software Quality 2

• Project plan should include explicit techniques for quality and

change management.
• Quality control - series of inspections, reviews, and tests used to
ensure conformance of a work product to its specifications.
• Quality assurance - consists of the auditing and reporting
procedures used to provide management with data needed to
make proactive decisions.
• Defect prediction is an important part of identifying software
components that may have quality concerns.
• Machine learning and statistical models may help identify
relationships between metrics and defection components.

© McGraw Hill 21
Because learning changes everything. ®

www.mheducation.com

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.