Software Engineering: A Practitioner’s Approach, 6/e
Chapter 15
Review Techniques
copyright © 1996, 2001, 2005
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
What Reviews Are Not



A project summary or progress assessment
A meeting intended solely to impart information
A mechanism for political or personal reprisal!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
Rationale for Software Technical Reviews


Software development is error-prone process (later errors detected,
higher the cost for repair)
Not possible to test all software








Cannot do exhaustive testing;
Cannot test specification or high level design
Reviews are a form of validation
Aid in tracking project
Provide feedback
Educational aspect – better understanding of software; learn
additional technical skills
Impact on morale – provides visibility of work; some see as intrusion
Impact on maintainability – force incremental documentation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
5
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
Planning for the Review
1. Select participants
2. Schedule review
3. Develop agenda
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
8
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 (no face to face meeting)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
Sample-Driven Reviews (SDRs)

SDRs attempt to quantify those work products that are primary
targets for full FTRs.
To accomplish this …




Inspect a fraction ai of each software work product, i. Record the
number of faults, fi found within ai.
Develop a gross estimate of the number of faults within work product
i by multiplying fi by 1/ai.
Sort the work products in descending order according to the gross
estimate of the number of faults in each.
Focus available review resources on those work products that have
the highest estimated number of faults.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
10
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
11
Fault clas s
Data faults
Ins pection check
Are all program variab les in itialis ed befo re th eir values
are u sed?
Hav e all con stants been n amed ?
Sh ould the lower bou nd o f arrays be 0, 1, or something
else?
Sh ould the upp er b ound of array s b eequal to the size of
the array or Size -1?
If character s tring s are us ed , is a delimiter explicitly
ass igned?
Con trol faults
Fo r each co nditional s tatement, is the con ditio n correct?
Is each loo p certain to termin ate?
Are compou nd s tatements correctly bracketed ?
In case statements, are all p oss ible cas es accounted fo r?
Inp ut/outp ut faults
Are all inpu t variab les us ed ?
Are all outpu t variab les ass igned a value before they are
ou tput?
Interface faults
Do all fu nction and procedu re calls hav e th e correct
nu mb er o f parameters?
Do fo rmal and actual parameter typ es match?
Are th e p arameters in the righ t order?
If compon ents acces s s hared memory, do th ey hav e the
s ame mo del of th e s hared memory s tructure?
Sto rage man agement If a linked s tructure is mo dified,
have all links been
faults
correctly reass igned?
If d ynamic s torag e is u sed, h as sp ace b een allocated
correctly?
Is sp ace explicitly de-allocated after it
is no lon ger
required?
Exception
Hav e all pos sib le error con ditio ns been taken
in to
man agement faults
account?
Inspection
checks
Inspection rate





500 statements/hour during overview
125 source statement/hour during individual
preparation
90-125 statements/hour can be inspected
Inspection is therefore an expensive process
Inspecting 500 lines costs about 40 man/hours
effort = $5600