Software reviews and inspections

R

®

Design Technology PVPD

Intel Confidential

Software Reviews and Inspections

Tuesday, June 01, 2004

Miles and Yi

2

R

®


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

R

®


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

R

®


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

R

®


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

R

®


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

R

®


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

R

®


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

R

®


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

R

®


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