3. Software Reviews 3
Origin
■ The initial idea was proposed by
Gerry Weinberg in 1970s (in his
book “The Psychology of Computer
Programming”).
■ Michael Fagan: Fagan Inspection (IBM
Corporation 76).
■ Gilb and Graham in 93 expanded the
Inspection process.
4. Software Reviews 4
Reviews
■ A process or meeting during which a
work product, or a set of work
products, is presented to project
personnel, managers, users,
customers, or other interested parties
for comment or approval.
(IEEE)
5. Software Reviews 5
Reviews
■ A technical assessment of a work
product created during the software
engineering process.
■ A meeting conducted by technical
people for technical people to evaluate
a work product.
6. Software Reviews 6
Why Reviews?
■ To err is human.
■ Lots of errors escape the originator
more easily than anyone else.
■ Reviews are educational.
7. Software Reviews 7
Purpose of Reviews
■ The primary function is to use the skill
of a group of people to:
■ Identify needed improvements
■ Certify correctness
■ Encourage uniformity
■ Enforce subjective rules
8. Software Reviews 8
Other Objectives of Reviews
■ The secondary functions of reviews
include:
■ Communication
■ Milestone
■ Visibility to management
11. Software Reviews 11
Desk Checks
■ Reviewing your own work.
■ The intention is to find the defects by
the creator himself/herself.
■ Checklists can be helpful.
■ Code Reviews, Design Reviews are
examples of Desk Checks.
13. Software Reviews 13
Buddy Checking
■ A person other than the author informally
review a piece of work.
■ Generally, it does not require the collection
of data.
■ Difficult to put under managerial control
■ Generally, it does not involve the use of
checklists to guide inspection and is
therefore not repeatable.
15. Software Reviews 15
Walkthroughs
■ Author of an artifact presenting a document
or program to an audience of their peers.
■ The audience asks questions and makes
comments on the artifact being presented in
an attempt to identify defects.
■ Often break down into arguments about an
issue.
■ Also known as “Team Debugging” or “Peer
Reviews”.
16. Software Reviews 16
Walkthroughs (cont.)
■ Minimal documentation of the process
and of the issues found.
■ Process improvement and defect
tracking are therefore not easy.
■ More work for presenter.
■ May be difficult to control interactions.
■ No prior preparation on behalf of the
audience.
18. Software Reviews 18
Inspections
■ A formal evaluation technique in which
software requirements, design, or code are
examined in detail by a person or group
other than the author to detect faults,
violations of development standards, and
other problems.
(IEEE)
■ A highly structured, clearly defined process
by which software documents are reviewed
in detail by a team including the author
and, ideally, the customer.
19. Software Reviews 19
Inspections
■ Formally structured and managed peer
review processes.
■ Involve a review team with clearly
defined roles.
■ Specific data is collected during
inspections.
■ Inspections have quantitative goals
set.
20. Software Reviews 20
Inspections Rolls
■ Inspection Leader / Moderator
■ Author / Producer
■ Inspector / Reviewer
■ Recorder / Scribe
* IEEE-1028-1997 establishes five rolls for the Inspection.
21. Software Reviews 21
Inspections Team: Moderator
■ Manages the entire Process
■ Manages the inspection meeting
■ Discussion leader? Facilitator?
■ Controls order of participation
■ Is technically competent.
■ Stimulates participation of all team.
■ Consensus driver
■ Ensures that team follows inspection
process.
22. Software Reviews 22
Inspections Team: Author
■ Originator of work product being inspected
■ Has vested interest in ensuring that all
defects are found.
■ Provides inspection team with overview of
work product.
■ Actively participates in Inspection Meeting.
■ Confirms reader and tester understanding.
23. Software Reviews 23
Inspections Team: Reviewer
■ Recipient of work product being
inspected
■ Obtains complete understanding of
the document
■ Determines the path to be followed
through the document
■ Paraphrases and interprets the
document
24. Software Reviews 24
Rules for Reviewers
I. Be prepared
II. Evaluate product, not people.
III. Watch your language.
IV. When you are shown to be wrong, forget it
V. Raise issues, don’t resolve them.
VI. Record all issues in public.
VII. Stick to technical issues.
25. Software Reviews 25
Inspections Team: Recorder
■ Provide info for accurate report of
review.
■ Short, public notes.
■ Capture essence of each issue.
■ Must ensure group has reached
conclusion.
■ Don’t video tape.
26. Software Reviews 26
Inspection Constraints
■ Maximum time allotted for the inspection meeting
is 2 hours
■ Over and above the four roles described, two
additional “INSPECTORS” may participate; all must
prepare and participate, usually as
■ Reader (perhaps diagram interpreter)
■ Tester (with special focus)
■ Maximum of 6 participants allowed in inspection
meeting.
■ Management is not invited.
28. Software Reviews 28
Fagan Inspections
Michael Fagan divided the inspection process
into seven steps:
1. Planning
2. Overview
3. Preparation
4. Inspection
5. Inspection Analysis
6. Rework and
7. Follow-up
29. Software Reviews 29
Fagan Inspections
Meets Entry Criteria
for Inspection?
Yes
Planning
Overview
Preparation
Rework
Follow-Up
Seven Step Process as Outlined by Fagan
Defect
Log
Summary
Report
Meets Exit Criteria
for the work?
Yes
No
Summary
Report
Inspection
Inspection
Analysis
Process
Improvement
Recommendations
30. Software Reviews 30
The Seven Step Inspection
Process
1. Planning
■ Materials meet inspection entry criteria
■ Assign Inspector roles
■ Schedule meeting time/place for steps 2, 4 & 5
2. Overview
■ Educate inspection team. Provide work product background,
context, rationale, etc.
3. Preparation
■ Prepare to fulfill role
■ Completely understand document from role's perspective
4. Inspection
■ Identify, classify and record defects
■ No solutions or improvements
31. Software Reviews 31
The Seven Step Inspection
Process
5. Inspection Analysis
■ Review/analyze inspection steps 1 - 5 for
improvement
■ Identify defect causes
■ Recommend process improvements
6. Rework
■ Correct ALL defects
7. Follow-up
■ Ensure all defects identified are corrected
■ Ensure no new defects are introduced
32. Software Reviews 32
Inspection Process & People
OVERVIEW
Moderator
Author
Reader
Tester
Inspector(s)
PLANNING
Moderator
Author
PREPARATION
Moderator
Author
Reader
Tester
Inspector(s)
INSPECTION
M oderator
Author
Re ade r
Te ster
Inspector(s)
REWORK
Author
FOLLOW-UP
Moderator
Author
Formal
Inspection
Process
Inspection
Announcem ent
Individual
Preparation
Log
Inspection
Defect
List
Inspection
Sum mary
Report
SYMBOLS
- Process Stage
- Stage Transition
- Inspection Form
INSPECTION
ANALYSIS
M oderator
Author
Re ade r
Te ster
Inspector(s)
Othe rs
Inspection
Is sue
Form
Detailed
Inspection
Report
34. Software Reviews 34
Gilb and Graham Inspection
Gilb and Graham [GilbGraham93] divide the inspection
process into the following inspection steps:
1. Entry
2. Planning
3. Kickoff Meeting
4. Individual Checking
5. Logging Meeting
6. Edit
7. Follow Up
8. Exit
35. Software Reviews 35
Gilb and Graham Inspection Process
Work
Product
E
N
T
R
Y
E
X
I
T
Planning
Kickoff
Individual
Checking
Logging
Meeting
Edit and
Follow-
up
Inspected
Work
Product
Process
Improvement
Change Request
Inspection
Process
Source
Checklists
36. Software Reviews 36
Gilb Inspection: Entry
■ The author of the artifact requests that it be
inspected.
■ The artifact to be inspected is checked by
the inspection moderator to ensure that
certain entry criteria are met.
■ The primary purpose of this stage is to
ensure that inspection time is not wasted on
artifacts that contain defects which the
author should rightly have found.
37. Software Reviews 37
Gilb Inspection: Planning
■ The moderator determines the
practical aspects of the inspection.
This may include:
■ Determining the size and composition of
the inspection team.
■ Determining the goals of the inspection.
■ Determine the timing and purpose of the
meetings.
38. Software Reviews 38
Gilb Inspection: Kickoff Meeting
■ Roles for the inspection team are assigned
and clarified.
■ Documents, including the artifact, its source
document, the inspection checklist, and
inspection rules are distributed and checked
■ The author(s) of the artifact may be
required to give a quick walkthrough of the
artifact to be inspected and its relation to
the other documentation.
39. Software Reviews 39
Gilb Inspection: Individual Checking
■ Most defects found in inspection processes
are found in the individual checking stage.
■ During this stage, an individual reviewer
reads the artifact and with the guidance of
an inspection checklist attempt to find
defects in the artifact.
■ The reviewer should record any issues
found.
■ Determines the severity of defects and
classifies the defects.
40. Software Reviews 40
Gilb Inspection: Logging Meeting
■ A planned and moderated meeting with the primary
purpose of logging the issues found by the
reviewers.
■ All reviewers should be given a chance to raise
their issues as a scribe logs the issues being raised
■ It is important that an issue is only logged once.
■ Moderator should ensure that discussion about
issues is kept to a minimum in order to maintain
the continuity of the meeting.
■ Some variations of this process include group
defect finding as an activity at the end of this
meeting
41. Software Reviews 41
Gilb Inspection: Edit
■ The editor (usually the author) is
responsible for addressing all logged
issues in the inspected artifact.
■ The editor decides if something is a
defect or not.
■ All defects must be corrected.
■ All non-defects should also be
addressed in some way.
42. Software Reviews 42
Gilb Inspection: Follow Up
■ Moderator checks that all defects have been
addressed.
■ Moderator must also ensure that any defects found
in a source document during inspection are
forwarded to the owner of that document for
correction.
■ Moderator may calculate certain metrics in this
stage to be analyzed to assess the effectiveness of
an inspection.
■ May also be used to hold a meeting to evaluate and
recommend inspection process improvement.
43. Software Reviews 43
Gilb Inspection: Exit
■ An inspection will be exit when pre-
defined set of inspection exit criteria
have been satisfied.
44. Software Reviews 44
Inspection Entry Criteria
■ Conforms to standard template
■ Spell-checked
■ Layout examined for errors
■ Reference documents are available
■ Line numbers included
■ Open issued marked TBD
■ Moderator no more than 3 defects in a 10
minute examination of the draft
45. Software Reviews 45
Inspection Exit Criteria
■ All issues raised were addressed
■ Changes made were made correctly
■ Revised document spell-checked
■ All TBDs closed
■ Document “baselined” (entered into
configuration management system)