by

Lili Murtha

Sophomore, University of California, Irvine

Although people are good at catching some of their own errors, lots of errors escape the originator more easily than they escape anyone else. A review is a way of using the diversity and power of a group of people to point out needed improvements in a product of a single person or team. [Freedman/Weinberg].

Some of the benefits to be gained by inspections include the following: [Wheeler]

• Reductions in user-reported defects
• Increased customer satisfaction
• Increased development productivity, evidenced by more function shipped in a given time or reduced development cycle time
• Improvement in meeting committed schedules
• Rapid cross-training of developers and maintainers on new products
• Continuous process improvement through removal of systemic defects (which cause product defects) and
• Team building

Although extra time needs to be spent planning, preparing for, conducting, and summarizing inspections, it has been proved that this time spent reduces the overall software effort. This is because more than 50 percent of the test effort is spent correcting errors or defects, rather than proving that the software satisfies the requirements it is supposed to satisfy. Since it takes less time to fix errors during the coding/inspection phase than the test phase, the overall software effort is reduced,

When software is complete, usually in chunks of 200 to 250 lines of code, the developer schedules a review by his or her peers. The peers, usually a small group of four or five, are invited to a meeting. The meeting should last no more than two hours because people get tired after that. The developer provides copies of the source code to be inspected and the checklists to be used to review the source code. The goal is to have the reviewers look at the software prior to the meeting. During the meeting, checklists are usually looked at to remind the people what kinds of errors they are looking for. The developer also brings to the meeting any related material, such as a design or requirements document. One or more checklists are filled out summarizing the defects found, comments made, and action items to be taken after the meeting. The listing of the source code is usually marked up with corrections made by the reviewers. After the meeting, the defects are corrected and checked by someone else to make sure the corrections have been properly made. The source code is then usually placed under some type of control.

Checklists are used to remind and record the types of errors that are supposed to be looked for during inspections. Depending on the source code language, these errors usually include the following:

• Coding or Logic Error
• Data Error
• Input/Output Error
• Constants used instead of numeric values
• Timing Problem
• Programming standard not followed
• Conflict with the requirements
• Not enough comments
• Variable not initialized
• Code doesn't match the design
• Code not clearly written or hard to follow
• Loop error (off by one, out of range)
• Dead code (code is not used or reached)
• Pointer or address errors
• Memory overlap

Because any error can lead to the downfall of a system, it's hard to claim that one type of review is more important than another. [Freedman/Weinberg]. Code reviews have received so much attention because most people think that most errors are in coding and that those errors are the most important ones. This is also because coding is the step in which we usually find a lot of errors. Code reviews are therefore the best place to start to implement reviews because: "...we might as well take advantage of the feelings that people have concerning coding errors. Like the doctor who is going to have to perform a painful procedure on a patient, we may need the patient's pain as motivation to get the procedure accepted.... The results from code reviews are most likely to be readily translated into facts that many people will be able to appreciate. [Freedman/Weinberg].

Once software engineers realize the benefits of code inspections, they are more willing to practice other types of reviews or inspections such as requirements reviews, or design reviews. The more times a programmer attends code inspections, the better he or she becomes in not repeating those same types of errors. And the better he or she becomes in being able to spot those same errors made by others.

[CMU/SEI] Carnegie Mellon University/Software Engineering Institute "The Capability Maturity Model: Guidelines for Improving the Software Process" Addison-Wesley Publishing Company 1995

[Wheeler] David A.Wheeler, Bill Brykczynski, and Reginald N.Meeson, Jr., Foreward by Michael Fagan "Software Inspection - An Industry Best Practice" Published by the IEEE Computer Society Press

[Freedman/Weinberg] Daniel P. Freedman, Gerald M. Weinberg, "Handbook of Walkthroughs, Inspections, and Technical Reviews", Dorset House Publishing 1990