Teaching
670 S '05
 
Lectures
Lecture 1
Lecture 2
Lecture 3
Lecture 4
Lecture 5
Lecture 6
Lecture 7
Lecture 8
Lecture 9
Lecture 10
Lecture 11
Lecture 12
Lecture 13

Lecture 6: Inspections & Design Review: Carcassonne (1)

Inspections

People identify two different types of inspections: one concerning design documents (e.g., requirements, specifications, documentations) and the other one concerning programs.

In both cases, an inspection proceeds in at least three phases: preparation, the actual inspection followed by feedback, and a follow-up meeting. In a business context, you need to prepare for an inspection. You have your own work to do, and you don't know what others are doing. In this course, you have solved a similar problem or written a similar document. So you know what is going on.

The actual inspection is an presentation of the code to a team of readers. The goal of the presentation is to uncover mistakes and to point out omissions. The panel may engage in a dialog but only as long as they are trying to confirm a problem. Once the problem is confirmed they stop and move on.

At the end, the "coder" receives a list of feedback points. Someone is put in charge to follow up on this list. A follow-up session may involved another presentation.

Studies have found that the effectiveness of reviews directly depends on the size of the team. Two readers in addition to the coder are much less effective than three readers. Ideally, these three readers assume the role of a moderator, who leads and directs the presentation; a second reader, and a secretary who takes notes for the feedback report.

The degree preparation of preparation also plays a role in the effectiveness of code walks but to a much smaller degree than the number of people. For more information, see the papers in the bibliography.

Bibliography

The literature on the inspection of software artifacts is huge. Here are some early, historical entry points. If you need to have more recent evidence that it works, conduct a literature search before you present those papers alone to your manager.
  • Fagan. Design and code inspections to reduce errors in program development. IBM Syst. J. 3. 1976
  • Fagan. Advances in software inspection. IEEE ToSE 12(7). 1986
  • Russel. Experience with inspection in ultralarge-scale developments. IEEE Software. Jan 1991.
  • Weller. Lessons from three years of inspection data. IEEE Software. Sep 1993.
  • NASA. Software Formal Inspections Guidebook.

  • Presenters: BinH T Le, Juan Flores

    Readers: Martin Fowler (moderator), Zach Joress (secretary), Chris Barthle (second reader)


    Presenters: John Vulner, Daniel Suchy

    Readers: Andreas Tejeda (moderator), John Sullivan (secretary), Eric Bloomquist (second reader)


    last updated on Tue Jun 9 22:03:19 EDT 2009generated with PLT Scheme