Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 8
Software Quality Assurance
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
SQA Encompasses…
A quality management approach
Effective SE technology (methods & tools)
Formal technical reviews
A multi-tiered testing strategy
Compliance with development standard
Measurement & reporting mechanism
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Why SQA Activities Pay Off?
cost to find
and fix a defect
100
60.00-100.00
log
scale
10
1
10.00
0.75 1.00
1.50
3.00
Design testsystem field
Req.
use
code
test
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
Quality Concepts
general objective: reduce the “variation
between samples” ... but how does this apply
to software?
quality control: a series of inspections,
reviews, tests
quality assurance: analysis, auditing and
reporting activities
cost of quality
 appraisal costs
 failure costs
 external failure costs
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
What is quality?
A characteristic or attribute of something
(American Heritage Dictionary)
Measurable characteristics
such as length, color, electrical properties, &
malleability.
Software’s characteristics:
 cyclomatic complexity, cohesion, number of function
points, LOC, and many others
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Quality
Two kinds of software quality:
1. Quality of design:
the characteristics that the designers specify for an item.
Eg, requirements, specifications, and design
2. Quality of conformance:
the degree to which the design specifications are followed
during manufacturing
Eg, implementation
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Quality Control
Involves the series of inspections, reviews,
and tests used throughout the software
process to ensure each work product meets
the requirements
Includes a feedback loop to the process
May be manual, automated, or both
Measurement + feedback
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
Quality Assurance
Consists of the auditing and reporting
functions of management
Goal:
to provide management with the data necessary to
be informed about product quality,
thereby gaining insight and confidence that product
quality is meeting its goal
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
Quality Costs
1. Prevention costs:
quality planning, formal technical reviews, test equipment,
training
2. Appraisal costs
include activities to gain insight into product condition
the “first time through” each process: in-process & interprocess inspection, equipment calibration & maintenance,
testing
3. Failure costs:
Internal Failure costs: rework, repair, failure mode analysis
External Failure costs: complaint resolution, product return
& replacement, help line support, warranty work
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
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
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
DEFINITION (2)
Three important points of the definition:
1. Software requirements are the foundation from
which quality is measured
2. Specified standards define a set of development
criteria that guide the engineering
3. A set of implicit requirements often goes
unmentioned (eg. Ease of use, maintainability)
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Software Quality Assurance
SQA
Process
Definition &
Standards
Formal
Technical
Reviews
Analysis
&
Reporting
Measurement
Test
Planning
& Review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
SQA Activities
Software engineers address quality by
 applying solid technical methods & measures,
 conducting formal technical reviews, and
 performing well-planned testing
SQA group assists the software team in
achieving a high quality product by addressing
 quality assurance planning,
 oversight,
 record keeping,
 analysis, &
 reporting
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Reviews & Inspections
... there is no particular reason
why your friend and colleague
cannot also be your sternest critic.
Jerry Weinberg
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
What Are Reviews?
a meeting conducted by technical people for
technical people
a technical assessment of a work product
created during the software engineering
process
a software quality assurance mechanism
a training ground
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Constraints
Between 3 and 5 people
Advance preparation should occur but should
require no more than 2 hours of work for each
person
Duration of review meeting should be less
than 2 hours
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
What Reviews Are Not!
They are not:
a project budget summary
a scheduling assessment
an overall progress report
a mechanism for reprisal or political
intrigue!!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
The Players
review
leader
standards bearer (SQA)
producer
maintenance
oracle
reviewer
recorder
user rep
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Conducting the Review
1. be prepared—evaluate
product before the review
2. review the product, not
the producer
3. keep your tone mild, ask
questions instead of
making accusations
4. stick to the review agenda
5. raise issues, don't resolve them
6. avoid discussions of style—stick to technical
correctness
7. schedule reviews as project tasks
8. record and report all review results
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
Review Guidelines
 Review the product, not the producer
 Set an agenda and maintain it
 Limit debate and rebuttal
 Enunciate the problem areas, but don’t attempt to
solve every problem noted
 Take written notes
 Limit the number of participants and insists upon
advance preparation
 Develop a checklist for each product that is likely to be
reviewed
 Allocate resources and schedule time for FTRs
 Conduct meaningful training for all reviewers
 Review your early review
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
Review Options Matrix
trained leader
agenda established
reviewers prepare in advance
producer presents product
“reader” presents product
recorder takes notes
checklists used to find errors
errors categorized as found
issues list created
team must sign-off on result
IPR *
WT
IN
no
maybe
maybe
maybe
no
maybe
no
no
no
no
yes
yes
yes
yes
no
yes
no
no
yes
yes
yes
yes
yes
no
yes
yes
yes
yes
yes
yes
RRR
yes
yes
yes
no
no
yes
no
no
yes
maybe
* IPR—informal peer review WT—Walkthrough
IN—Inspection RRR—round robin review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
Metrics Derived from Reviews
inspection time per page of documentation
inspection time per KLOC or FP
inspection effort per KLOC or FP
errors uncovered per reviewer hour
errors uncovered per preparation hour
errors uncovered per SE task (e.g., design)
number of minor errors (e.g., typos)
number of major errors
(e.g., nonconformance to req.)
number of errors found during preparation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
Statistical SQA
Product
& Process
• collect information on all
defects
• find the causes of the
defects
• move to provide fixes for
the process
measurement
... an understanding of how
to improve quality ...
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
________stoppage
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
SOFTWARE RELIABILITY
The probability of failure-free operation of a
computer program in a specified environment
for a specified time
Measures:
MTBF = MTTF + MTTR
Availability = (MTTF/(MTTF+MTTR)) * 100%
Software safety is
 SQA activity that focuses on the identification &
assessment of potential hazards that may affect software
negatively and cause system to fail
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26
ISO 9000
 Describes quality assurance elements in generic terms
that can be applied to any business regardless of the
products or services offered
 Elements of quality assurance system:
 organizational structure,
 procedures,
 processes, and
 resources to implement quality planning,
 quality control,
 quality assurance, and
 quality improvement
 ISO 9001 – for software engineering
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
27
SQA plan
 Provides road map for instituting software quality
assurance
 The plan serves as template for SQA activities
 Contents:
initial section – purpose and scope
management section – organizational structure
documentation section – project documents, models, technical
documents, user documents
test section
tools & methods, SCM, contract, records maintenance,
training, risk
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
28