Chapter 15
Review Techniques
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.
Reviews
... there is no particular reason
... there is no particular reason
why your friend and colleague
why your friend and colleague
cannot also be your sternest critic.
cannot also be your sternest critic.
Jerry Weinberg
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
What Reviews Are Not
A project summary or progress assessment
A meeting intended solely to impart
information
A mechanism for political or personal
What Do We Look For?
Errors and defects
Error—a quality problem found
before
the software is released
to end users
Defect
—
a quality problem found only
after
the software has been
released to end-users
We make this distinction because errors and defects have very
different economic, business, psychological, and human
impact
Defect Amplification
A
defect amplification model
[IBM81] can be used to illustrate
the generation and detection of errors during the design and
code generation actions of a software process.
Errors passed through
Amplified errors 1:x
Newly generated errors
Development step
Errors from
Previous step
Errors passed
To next step
Defects
Detection
Defect Amplification
In the example provided in SEPA, Section
15.2,
a software process that does NOT include reviews,
•
yields
94 errors
at the beginning of testing and
•
Releases
12 latent defects
to the field
a software process that does include reviews,
•
yields
24 errors
at the beginning of testing and
•
releases
3 latent defects
to the field
Metrics
The total review effort and the total number of
errors discovered are defined as:
•
E
review= E
p+ E
a+ E
r•
Err
tot= Err
minor+ Err
major
Defect density
represents the errors found per
unit of work product reviewed.
•
Defect density = Err
tot/ WPS
Metrics
Preparation effort, E
p
—the effort (in person-hours) required to
review a work product prior to the actual review meeting
Assessment effort, E
a
— the effort (in person-hours) that is expending
during the actual review
Rework effort, E
r
— the effort (in person-hours) that is dedicated to
the correction of those errors uncovered during the review
Work product size, WPS
—a measure of the size of the work product
that has been reviewed (e.g., the number of UML models, or the
number of document pages, or the number of lines of code)
Minor errors found, Err
minor
—the number of errors found that can be
categorized as minor (requiring less than some pre-specified effort
to correct)
Major errors found, Err
major
— the number of errors found that can be
An Example—I
If past history indicates that
the
average defect density
for a requirements model
is 0.6 errors per page, and a new requirement model
is 32 pages long,
a rough estimate suggests that your software team
will find about 19 or 20 errors during the review of
the document.
If you find only 6 errors, you’ve done an extremely
good job in developing the requirements model
or
An Example—II
The effort required to correct a minor model error (immediately after
the review) was found to require 4 person-hours.
The effort required for a major requirement error was found to be 18
person-hours.
Examining the review data collected, you find that minor errors occur
about 6 times more frequently than major errors. Therefore,
you can
estimate that the average effort to find and correct a requirements error
during review is about 6 person-hours.
Requirements related errors uncovered during testing require an
average of 45 person-hours to find and correct.
Using the averages
noted, we get:
Effort saved per error =
E
testing
