Code Inspections

1
Code Inspections

• CS 414 Software Engineering I
• Donald J. Bagert
• Rose-Hulman Institute of Technology
• January 23, 2003

2
Outline

• Terminology
• Inspection Format
• Why not just test code?

3
Terminology

• Reviews
• Reviews should be applied to major project
  artifacts at various points during software
  development
• The goal of reviews is to remove defects (errors)
  from and make improvements to an artifact before
  that artifact is used to produce other ones

4
Terminology (continued)

• An informal review is one where a number of
  developers are involved and the artifact is not
  studied in detail
• Informal reviews usually only uncover major
  conceptual errors and can be in part for
  informational purposes and used to build a
  consensus
• From here on, informal reviews will be referred
  to as just reviews

5
Terminology (continued)

• An inspection, or formal review (also called a
  walkthrough or a formal technical review), is
  when a small group of developers looks at a
  project artifact in detail with the express
  purpose of
• finding defects in the artifact,
• making sure the artifact meets professional
  standards, and
• ensuring that all artifacts are developed in a
  uniform manner
• The most common type of inspections are code
  inspections, first defined by Michael Fagan in
  1976

6
Inspection Format

• Personnel
• There should be between 3 to 5 people at an
  inspection
• Four is the optimal number, and the number we
  will use here
• Roles
• Moderator
• Reader
• Inspector, or tester
• Recorder
• Producer, or author
• Some people can have more than one role
• All except the producer is a member of the
  inspection team

7
Inspection Format (continued)

• One Possible Configuration(For Four People)
• Moderator
• Reader/Inspector
• Recorder/Inspector
• Producer
• Should be arranged around a square or round
  table, or 2 by 2 at a larger table (like the ones
  in our classroom)

8
Inspection Format (continued)

• Phases
• Preparation
• Inspection meeting
• Inspection report
• This process needs to be repeated, if it is
  decided that a sufficient a number of problems
  are uncovered in an inspection to warrant another
  inspection

9
Inspection Format (continued)

• Constraints
• Each inspection should cover about 200 lines of
  code
• However, some types of code may need more
  detailed inspection than others
• Advance preparation should be 1-2 hours per
  person
• The inspection meeting should also be 1-2 hours
• Inspection of other artifacts should also use the
  1-2 hours per inspection rule

10
Inspection Format (continued)

• Guidelines
• A checklist of common problems can be helpful
• There should only be identification of errors,
  and little fixing of them (no problem solving)

11
Why not just test code?

• Debugging requires doing an on-the-spot
  inspection anyway
• Such inspections may have to be done several
  times on the same code
• A test case failure doesnt pinpoint where the
  problem is
• That said, testing is almost always needed in
  order catch some of the errors not found through
  inspections

12
Summary

• Inspections (formal reviews) can be used as a
  time-saving measure for producing better
  artifacts more reliable code
• The goal of an inspection is to find all defects
  so that they can be removed before going on to
  the next phase
• Inspections have a specific structured format and
  time constraints
• Code inspections are an essential complement to
  the testing of source code