2. 2
R
®
Design Technology PVPD
Intel Confidential
Introduction
Several PVPD teams have found reviews and inspections to be
a helpful part of their software development methodology
Reviews and inspections can help you to:
– Find bugs in both design and implementation
– Share and teach BKMs and good development practices
– Encourage good habits and practices
– Foster teamwork
Individual groups/teams can decide how to incorporate reviews
and inspections into their methodology, but we encourage you to
standardize on a set of practices that people have found useful
3. 3
R
®
Design Technology PVPD
Intel Confidential
Suggested Methodology
Follow the standard inspection process for code inspections
– Focus is on identifying defects – resolution is left to the implementer,
or can be discussed separately after defect identification
Use a modified process for design and specification reviews
– Includes discussion of design alternatives
– Brainstorming plays a larger role
– Treating design and specification reviews differently than code
inspections is a change from our earlier inspection efforts
Many of the common elements are briefly described on the
following foils
– Some of the this has been condensed from older training materials
developed by Neela (more details can be found there)
4. 4
R
®
Design Technology PVPD
Intel Confidential
Participants
Participants in reviews and inspections have well defined roles
Inspector General (Team Inspection Czar)
– Identifies a regular time slot that works for the group
– Help maintain continuity of reviews in a group
– Handles scheduling and administrative aspects
– Helps to identify and schedule reviews
– Make sure properly formatted materials (with line numbers) are
provided to reviewers
– Should allow at least 48 hours for reviewers to prepare
– Makes sure that it happens…
Owner
– Person responsible for the work being reviewed/inspected
– Also acts as an inspector
– Performs necessary rework triggered by the review inspection
5. 5
R
®
Design Technology PVPD
Intel Confidential
Participants
Moderator
– Facilitates the inspection and records the meeting data
– Should never be the owner
For Code: Inspectors
– Identify bugs, gotchas, confusing or unclear code, and deviations
from common accepted coding practices
For Design/Architecture: Reviewers
– Same as code review plus…
– Identify good and bad parts of the design/architecture
– Bring suggestions for improving the design/architecture
6. 6
R
®
Design Technology PVPD
Intel Confidential
Preparation
Preparation is absolutely essential to the success of the review
or inspection
– If the necessary preparation has not been done, then the review or
inspection should be rescheduled
Owner’s Initial Preparation
– The owner should be given enough heads-up notice to do any
cleanup that he/she deems necessary – this initial step often can
eliminate many errors
– Just thinking about it improves the product and work habits
– Owner should provide the properly formatted materials to the
Inspector General, or directly to the inspection participants
7. 7
R
®
Design Technology PVPD
Intel Confidential
Preparation
Inspector’s/Reviewer’s Preparation
– Without proper advance prep, the session will be a waste of time
Spend 30-60+ minutes reviewing the materials
Reschedule if necessary
– Note defects that are identified
– For design reviews, note
Portions of the design that can be improved
Any suggestions you may have for improvement
– Some reviewers will have focus areas assigned
Review code in reverse, look for pointer problems, const usage, etc.
– A checklist for common errors may be helpful during preparation
(see slide 10)
8. 8
R
®
Design Technology PVPD
Intel Confidential
Review Session
Review or Inspection session
– Pace and tangential discussions should be controlled by moderator
– A strict process is important to keep emotions under control
Focus on the code/design, not on the owner
– Moderator logs inputs and suggestions
– For reviews:
The moderator should make sure that inputs are understood and allow
some discussion – however, the design decisions will usually require
analysis or interaction with stakeholders that will need to happen after
the session
– For inspections
Discussion shouldn’t dwell on the specific code itself (or the coder)
Instead, focus on the coding concepts that apply to the code
If there is a discussion, it should be about the merits of the coding
guideline that the code violates (helps to level-set the team on what is
considered good and what is considered bad)
9. 9
R
®
Design Technology PVPD
Intel Confidential
Rework and Follow-up
Rework
– It is the responsibility of the code/design owner to address defects or
design suggestions
– Addressing a defect does not imply mean changing the code or
design, but it does mean that sufficient analysis was done to
determine that the existing code or design is adequate
Follow-up
– The czar should follow up with the code/design owner
– Identify with the code/design owner the inputs that were addressed
– Decide whether the updated design/code should be
reviewed/inspected again
– If inputs have been addressed in a satisfactory manner, then the
review/inspection can be closed, and results logged
10. 10
R
®
Design Technology PVPD
Intel Confidential
Common Errors Checklist
It is useful for each group to develop a list of common errors that
inspectors can use
– The list will evolve over time as people in the group learn to avoid
certain types of errors
– Especially useful when people have not participated in many
inspections and are not sure about the types of defects they should
be trying to identify
– It is helpful if the teams can reach consensus on the guidelines,
since the whole team needs to support them
– Nothing is set in stone and adherence is ultimately up to the owner
We can start with a generic common list, although the types of
errors or concerns will tend to vary from team to team
