Types of Reviews

Types of Reviews

Reviews can be formal or informal. They can be technical or managerial. Managerial reviews usually focus on project management and project status. The role of project status meetings is discussed in Chapter 9. In this chapter we will focus on technical reviews. These are used to:

• verify that a software artifact meets its specification;

• to detect defects; and

• check for compliance to standards.

Readers may not realize that informal technical reviews take place very frequently. For example, each time one software engineer asks another to evaluate a piece of work whether in the office, at lunch, or over a beer, a review takes place. By review it is meant that one or more peers have inspected/evaluated a software artifact. The colleague requesting the review receives feedback about one or more attributes of the reviewed software artifact. Informal reviews are an important way for colleagues to communicate and get peer input with respect to their work. There are two major types of technical reviews—inspections and walkthroughs— which are more formal in nature and occur in a meeting-like setting. Formal reviews require written reports that summarize findings, and in the case of one type of review called an inspection, a statement of responsibility for the results by the reviewers is also required. The two most widely used types of reviews will be described in the next several paragraphs.

Inspections as a Type of Technical Review

Inspections are a type of review that is formal in nature and requires prereview preparation on the part of the review team. Several steps are involved in the inspection process as outlined in Figure 10.2. The responsibility for initiating and carrying through the steps belongs to the inspection leader (or moderator) who is usually a member of the technical staff or the software quality assurance team. Myers suggests that the inspection leader be a member of a group from an unrelated project to preserve objectivity [4]. The inspection leader plans for the inspection, sets the date, invites the participants, distributes the required documents, runs the inspection meeting, appoints a recorder to record results, and monitors the followup period after the review. The key item that the inspection leader prepares is the checklist of items that serves as the agenda for the review. The checklist varies with the software artifact being inspected (examples are provided later in this chapter). It contains items that inspection participants should focus their attention on, check, and evaluate. The inspection participants address each item on the checklist. The recorder records any discrepancies, misunderstandings, errors, and ambiguities; in general, any problems associated with an item. The completed checklist is part of the review summary document. The inspection process begins when inspection preconditions are met as specified in

the inspection policies, procedures, and plans. The inspection leader announces the inspection meeting and distributes the items to be inspected, the checklist, and any other auxiliary material to the participants usually a day or two before the scheduled meeting. Participants must do their homework and study the items and the checklist. Apersonal preinspection should be performed carefully by each team member [3,5].

Errors, problems, and items for discussion should be noted by each individual for each item on the list. When the actual meeting takes place the document under review is presented by a reader, and is discussed as it read. Attention is paid to issues related to quality, adherence to standards, testability, traceability, and satisfaction of the users/clients requirements. All the items on the checklist are addressed by the group as a whole, and the problems are recorded. Inspection

metrics are also recorded (see Section 10.7). The recorder documents all the findings and the measurements.

When the inspection meeting has been completed (all agenda items covered) the inspectors are usually asked to sign a written document that is sometimes called a summary report that will be described in Section 10.4.6. The inspection process requires a formal follow-up process. Rework sessions should be scheduled as needed and monitored to ensure that all problems identified at the inspection meeting have been addressed and resolved. This is the responsibility of the inspection leader. Only when all problems have been resolved and the item is either reinspected by the group or the moderator (this is specified in the summary report) is the inspection process completed.

Walk t hrough s a s a Type of Technical Review

Walkthroughs are a type of technical review where the producer of the reviewed material serves as the review leader and actually guides the progression of the review [6]. Walkthroughs have traditionally been applied to design and code. In the case of detailed design or code walkthroughs, test inputs may be selected and review participants then literally walk through the design or code with the set of inputs in a line-by-line manner. The reader can compare this process to a manual execution of the code. The whole group ―plays computer‖ to step through an execution lead by a reader or presenter. This is a good opportunity to ―pretest‖ the design or code. If the presenter gives a skilled presentation of the material, the walkthrough participants are able to build a comprehensive mental (internal) model of the detailed design or code and are able to both evaluate its quality and detect defects. Walkthroughs may be used for material other than code, for example, data descriptions, reference manuals, or even specifications [6].

Some researchers and practitioners believe walkthroughs are efficient because the preparer leads the meeting and is very familiar with the item under review. Because of these conditions a larger amount of material can be processed by the group. However, many of the steps that are mandatory for an inspection are not mandatory for a walkthrough. Comparing inspections and walkthroughs one can eliminate the checklist and the preparation step (this may prove to be a disadvantage to the review team) for the walkthrough. In addition, for the walkthrough there usually no mandatory requirement for a formal review report and a defect list. There is also no formal requirement for a follow-up step. In some cases the walkthrough is used as a preinspection tool to familiarize the team with the code or any other item to be reviewed.

There are other types of technical reviews, for example, the roundrobin review where there is a cycling through the review team members so that everyone gets to participate in an equal manner. For example, in some forms of the round-robin review everyone would have the opportunity to play the role of leader. In another instance, every reviewer in a code walkthrough would lead the group in inspecting a specific line or a section of the code [6]. In this way inexperienced or more  reluctant reviewers have a chance to learn more about the review process. In subsequent sections of this chapter the general term review will be used in the main to represent the inspection process, which is the review type most formal in nature. Where specific details are relevant for other types of reviews, such as round-robin or walkthroughs, these will be mentioned in the discussion.