Chapter 14

 Quality Concepts
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
Software Quality
 In 2005, ComputerWorld [H il05] lamented that
 “bad softw are p lagu es nearly every organization that u ses
com p u ters, cau sing lost w ork hou rs d u ring com p u ter d ow ntim e,
lost or corru p ted d ata, m issed sales op p ortu nities, high IT su p p ort
and m aintenance costs, and low custom er satisfaction.
 A year later, InfoWorld [Fos06] w rote about the
 “the sorry state of softw are qu ality” rep orting that the qu ality
p roblem had not gotten any better.
 Tod ay, softw are quality rem ains an issue, but w ho is to blam e?
 Cu stom ers blam e d evelop ers, argu ing that slop p y p ractices lead to
low -qu ality softw are.
 Develop ers blam e custom ers (and other stakehold ers), argu ing
that irrational d elivery d ates and a continu ing stream of changes
force them to d eliver softw are before it has been fu lly valid ated .

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2
Quality
 The American Heritage Dictionary defines
quality as
 “a characteristic or attribute of something.”
 For software, two 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3
Quality—A Pragmatic View
 The transcendental view argu es (like Persig) that qu ality is
som ething that you im m ed iately recognize, bu t cannot
explicitly d efine.
 The user view sees qu ality in term s of an end -u ser ’s
specific goals. If a prod u ct m eets those goals, it exhibits
qu ality.
 The manufacturer’s view d efines qu ality in term s of the
original specification of the prod u ct. If the prod u ct
conform s to the spec, it exhibits qu ality.
 The product view su ggests that qu ality can be tied to
inherent characteristics (e.g., fu nctions and featu res) of a
prod u ct.
 Finally, the value-based view m easu res qu ality based on
how m u ch a cu stom er is w illing to pay for a prod u ct. In
reality, qu ality encom passes all of these view s and m ore.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
Software Quality
 Softw are qu ality can be d efined as:
 A n 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Effective Software Process
 An effective software process establishes the infrastructure
that su pports any effort at bu ild ing a high qu ality
softw are prod u ct.
 The m anagem ent aspects of process create the checks
and balances that help avoid project chaos—a key
contribu tor to poor qu ality.
 Softw are engineering practices allow the d eveloper to
analyze the problem and d esign a solid solu tion —both
critical to bu ild ing high qu ality softw are.
 Finally, u m brella activities su ch as change m anagem ent
and technical review s have as m u ch to d o w ith qu ality
as any other part of softw are engineering practice.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Useful Product
 A useful product d elivers the content, fu nctions,
and featu res that the end -u ser d esires
 Bu t as im portant, it d elivers these assets in a
reliable, error free w ay.
 A u sefu l prod u ct alw ays satisfies those
requ irem ents that have been explicitly stated
by stakehold ers.
 In ad d ition, it satisfies a set of im plicit
requ irem ents (e.g., ease of u se) that are
expected of all high qu ality softw are.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
Adding Value
 By adding value for both the producer and user of a softw are
prod u ct, high qu ality softw are provid es benefits for the
softw are organization and the end -u ser com m u nity.
 The softw are organization gains ad d ed valu e becau se
high qu ality softw are requ ires less m aintenance effort,
few er bu g fixes, and red u ced cu stom er su pport.
 The u ser com m u nity gains ad d ed valu e becau se the
application provid es a u sefu l capability in a w ay that
exped ites som e bu siness process.
 The end resu lt is:
 (1) greater softw are prod uct revenue,
 (2) better profitability w hen an application supports a
business process, and / or
 (3) im proved availability of inform ation that is crucial for
the business.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Quality Dimensions
 David Garvin [Gar87]:
 Performance Quality. Does the softw are d eliver all
content, functions, and features that are specified as part of
the requirem ents m od el in a w ay that provid es value to the
end -user?
 Feature quality. Does the softw are p rovid e features that
surprise and d elight first-tim e end -users?
 Reliability. Does the softw are d eliver all features and
capability w ithout failure? Is it available w hen it is
need ed ? Does it d eliver functionality that is error free?
 Conformance. Does the softw are conform to local and
external softw are stand ard s that are relevant to the
application? Does it conform to d e facto d esign and cod ing
conventions? For exam ple, d oes the user interface conform
to accepted d esign rules for m enu selection or d ata input?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Quality Dimensions
 D urability. Can the softw are be m aintained (changed ) or
corrected (d ebugged ) w ithout the inad vertent generation
of unintend ed sid e effects? Will changes cause the error
rate or reliability to d egrad e w ith tim e?
 Serviceability. Can the softw are be m aintained (changed )
or corrected (d ebugged ) in an acceptably short tim e period .
Can support staff acquire all inform ation they need to
m ake changes or correct d efects?
 Aesthetics. Most of us would agree that an aesthetic entity has a
certain elegance, a unique flow, and an obvious “presence” that
are hard to quantify but evident nonetheless.
 Perception. In some situations, you have a set of prejudices that
will influence your perception of quality.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Other Views
 McCall’s Quality Factors (SEPA , Section 14.2.2)
 ISO 9126 Quality Factors (SEPA , Section
14.2.3)
 Targeted Factors (SEPA , Section 14.2.4)

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
McCall’s Triangle of Quality
Maintainability Portability
Flexibility Reusability
Testability Interoperability

PRODUCT REVISION PRODUCT TRANSITION

PRODUCT OPERATION These slides are

designed to
Correctness Usability Efficiency accompany
Software
Engineering: A
Practitioner’s
Reliability Integrity Approach, 7/e
(McGraw-Hill
2009). Slides
copyright 2009 by
12 Roger Pressman.
The Software Quality Dilemma
 If you prod u ce a softw are system that has terrible
qu ality, you lose becau se no one w ill w ant to bu y it.
 If on the other hand you spend infinite tim e, extrem ely
large effort, and hu ge su m s of m oney to bu ild the
absolu tely perfect piece of softw are, then it's going to
take so long to com plete and it w ill be so expensive to
prod u ce that you 'll be ou t of bu siness anyw ay.
 Either you m issed the m arket w ind ow, or you sim ply
exhau sted all you r resou rces.
 So people in ind u stry try to get to that m agical m id d le
grou nd w here the prod u ct is good enou gh not to be
rejected right aw ay, su ch as d u ring evalu ation, bu t also
not the object of so m u ch perfectionism and so m u ch
w ork that it w ou ld take too long or cost too m u ch to
com plete. [Ven03]
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
“Good Enough” Software
 Good enough softw are d elivers high quality fu nctions and
features that end -users d esire, but at the sam e tim e it d elivers
other m ore obscu re or specialized functions and features that
contain know n bugs.
 Argum ents against “good enough.”
 It is tru e that “good enou gh” may w ork in some ap p lication
d om ains and for a few m ajor softw are com p anies. After all, if a
com p any has a large m arketing bu d get and can convince enou gh
p eop le to bu y version 1.0, it has su cceed ed in locking them in.
 If you w ork for a sm all com p any be w ary of this p hilosop hy. If
you d eliver a “good enou gh” (bu ggy) p rod u ct, you risk
p ermanent d amage to you r comp any’s rep u tation.
 You may never get a chance to d eliver version 2.0 becau se bad
bu zz m ay cau se you r sales to p lu m m et and you r com p any to fold .
 If you w ork in certain ap p lication d om ains (e.g., real tim e
em bed d ed softw are, ap p lication softw are that is integrated w ith
hard w are can be negligent and op en you r com p any to exp ensive
litigation.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
 Cost of Quality
 Prevention costs include
 quality planning
 formal technical reviews
 test equipment
 Training
 Internal failure costs include
 rework
 repair
 failure mode analysis
 External failure costs are
 complaint resolution
 product return and replacement
 help line support
 warranty work

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
Cost
 The relative costs to find and repair an error or d efect
increase d ram atically as w e go from prevention to
d etection to internal failu re to external failu re costs.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Quality and Risk
 “People bet their jobs, their comforts, their safety, their
entertainment, their decisions, and their very lives on
computer software. It better be right.” SEPA, Chapter 1
 Exam ple:
 Throughout the month of N ovember, 2000 at a hospital in
Panama, 28 patients received massive overdoses of gamma rays
during treatment for a variety of cancers. In the months that
followed, five of these patients died from radiation poisoning and
15 others developed serious complications. W hat caused this
tragedy? A software package, developed by a U.S. company, was
modified by hospital technicians to compute modified doses of
radiation for each patient.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Negligence and Liability
 The story is all too com m on. A governm ental or
corporate entity hires a m ajor softw are d eveloper or
consu lting com pany to analyze requ irem ents and then
d esign and constru ct a softw are-based “system ” to
su pport som e m ajor activity.
 The system m ight support a m ajor corporate function (e.g.,
pension m anagem ent) or som e governm ental function
(e.g., healthcare ad m inistration or hom eland secu rity).
 Work begins w ith the best of intentions on both sid es,
bu t by the tim e the system is d elivered , things have gone
bad .
 The system is late, fails to d eliver d esired featu res and
fu nctions, is error-prone, and d oes not m eet w ith
cu stom er approval.
 Litigation ensu es.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Quality and Security
 Gary McGraw com m ents [Wil05]:
 “Softw are secu rity relates entirely and com pletely to
qu ality. You m u st think abou t secu rity, reliability,
availability, d epend ability—at the beginning, in the
d esign, architectu re, test, and cod ing phases, all throu gh
the softw are life cycle [process]. Even people aw are of
the softw are secu rity problem have focu sed on late life-
cycle stu ff. The earlier you find the softw are problem ,
the better. And there are tw o kind s of softw are problem s.
One is bu gs, w hich are im plem entation problem s. The
other is softw are flaw s—architectu ral problem s in the
d esign. People pay too m u ch attention to bu gs and not
enou gh on flaw s.”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Achieving Software Quality
 Critical success factors:
 Softw are Engineering Methods
 Project Management Techniques
 Quality Control
 Quality Assurance

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20