Software Inspection. A formal evaluation technique in which software requirements, design, or code are examined in detail by person or group other than the author to detect faults, violations of development standards, and other problems [IEEE94]. A quality improvement process for written material that consists of two dominant components: product (document) improvement and process improvement (document production and inspection).
Software Inspection is the most formal, commonly used form of peer review. The key feature of an inspection is the use of the checklists to facilitate error detection and defined roles for participants.
Software Walkthrough. In the most usual form of term, a walkthrough is step by step simulation of the execution of a procedure, as when walking through code line by line, with an imagined set of inputs. The term has been extended to the review of material that is not procedural, such as data descriptions, reference manuals, specifications, etc.
Other support materials may be required to efficiently conduct a Walkthrough. These include:
The code walkthrough, like the inspection, is a set of procedures and error-detection techniques for group code reading. It shares much in common with the inspection process, but the procedures are slightly different, and a different error-detection technique is employed.
Like the inspection, the walkthrough is an uninterrupted meeting of one to two hours in duration. The walkthrough team consists of three to five people. One of these people plays a role similar to that of the moderator in the inspection process, another person plays the role of a secretary (a person who records all errors found), and a third person plays the role of a "tester." Suggestions as to who the three to five people should be vary. Of course, the programmer is one of these people. Suggestions for the other participants include (1) a highly experienced programmer, (2) a programming-language expert, (3) a new programmer (to give a fresh, unbiased outlook), (4) the person who will eventually maintain the program, (5) someone from a different project, and (6) someone from the same programming team as the programmer.
|
Comparison
of Software Walkthroughs versus Software Inspections
| ||
|
|
Software Walkthroughs
|
Software Inspections
|
|
Participants |
Peer(s) led by
author |
Peers in designated
roles |
|
Rigor |
Informal to
formal |
Formal |
|
Training
Required |
None, informal, or
structured |
Structured, preferably by
teams |
|
Purpose |
Judge quality, find defects,
training |
Measure/improve quality of
product and process |
|
Effectiveness |
Low
to medium |
Low
to very high, depending on training and
commitment |