THE REVIEW PROCESS
10.1 THE REVIEW PROCESS
Reviews can be done in many different ways. A formal group review, also called an inspection, is perhaps the best of these options for identifying defects. Software inspections were first proposed by Fagan.1,2 Earlier inspections focused on code, but over the years this technique has spread to other work products. Today, software inspections are a recognized industry best practice, with considerable data to prove that they improve quality and productivity (for example, see the reports in Gilb and Graham,3 Grady and Slack,4 and Weller5). Several books on the topic describe in great detail how inspections should be conducted.3,6,7
The basic review process at Infosys is the group review, which is similar to an inspection. A group review is an analysis of a software work product by a group of peers following a clearly defined process. The goals of such reviews are to improve quality by finding defects and to improve productivity by finding defects in a cost-effective manner. In addition, reviews provide inputs and visibility for project management into the quality of the work products. A group review is conducted by technical people for technical people, and the focus is on identifying problems, not resolving them.
The group review process includes several stages: planning, preparation and overview, a group review meeting, and rework and follow-up. As shown in Figure 10.1, these stages are usually executed in a linear order.
Figure 10.1. The group review process
In some situations, a group review may be overkill; a more limited form of group review may be more cost-effective. At Infosys, a one-person review, discussed later in this section, is also done.
10.1.1 Planning
The objective of the planning phase is to prepare for the group review by selecting the group review team and scheduling the review. The author of the work product ensures that the work product is ready for group review and that all pertinent standards have been met. The project manager, with the author's agreement, first selects the moderator; then, with the moderator's agreement, the project manager selects the other reviewers. The moderator has the overall responsibility of ensuring that the review is done properly and that all steps in the review process are followed. The reviewers (also called inspectors) have the responsibility of identifying defects in the work product. Generally, the author is also one of the reviewers; the moderator may be a reviewer as well.
As far as possible, no superiors should be included because their presence might discourage the reviewers from raising issues or errors. If the author desires, however, the project leader can also take part.
Once the review team is selected, the author prepares a package that is distributed for group review. This package includes the work product to be reviewed, its specifications, and relevant checklists and standards. Often, the specifications for the work product are the output of the preceding phase and are needed to check the correctness of the current work product.
10.1.2 Overview and Preparation
The purpose of the overview and preparation phase is to deliver the package for review to the reviewers and to explain the work product, if necessary. The material can be distributed and explained in an initial meeting. The moderator opens this meeting with a brief statement on the work product, the group review objectives, and, if needed, an overview of the group review process. The author may provide a brief tutorial on the work product, including a summary of any special considerations or areas that might be particularly difficult to understand. During this overview, anything unique about the project or the work product is highlighted. This step is optional and can be omitted. In that case, the moderator simply provides a copy of the group review package to the reviewers.
To prepare for the group review meeting, the reviewers then individually review (self-review) the work product. Wherever the work product appears to have a defect, reviewers make notes with explanations in a self-preparation log (described in detail in section 10.2.1). They also record the time spent in individual review. During this review, they use any relevant checklists, guidelines, and standards.
Ideally, this preparation step should be done in one sitting. The recommended time for preparation is one hour for every hour of group review meeting scheduled.
10.1.3 Group Review Meeting
The basic purpose of the group review meeting is to come up with the final defect list; this list is based on the initial list of defects and issues reported by the reviewers and any new ones found during the meeting discussion.
Before the meeting is scheduled, the moderator first checks whether all reviewers are prepared. This verification involves a brief examination of the effort and defect data in the self-preparation logs to confirm that sufficient time and attention have gone into the preparation. If preparation is not adequate, the group review is deferred until all participants are fully prepared.
When everything is ready, the group review meeting is held. One reviewer is designated as the scribe and another the reader. The meeting is conducted as follows. The reader goes over the work product line by line (or any other convenient small unit), paraphrasing each line to the team. (Some meetings do not include paraphrasing, in which case the reader role may not be present.) At any line, if any reviewer has previously identified any issues or finds new issues in the meeting while listening to others, he raises the point. There may be a discussion on the issue raised, and other reviewers may agree or disagree with it. In any event, the author reviews the issue under discussion and either clarifies why it is not an issue or accepts it as a defect or open issue. The scribe records the issues and defects identified.
At the end of the meeting, the scribe presents the list of open issues and defects identified during the meeting, and it undergoes a final review by the team members. Note that defects and issues are merely identified during the review process. It is not the purpose of the group to identify solutions; that action is taken later by the author.
If few modifications are required, the group review status is "accepted." If many modifications are required, a follow-up meeting or a re-review might be necessary to verify whether the changes have been incorporated correctly. The moderator recommends what is to be done. Unlike a defect, which the author is responsible for fixing, the moderator may assign issues to different persons for resolution. The assignment is made before the meeting is closed. Sometimes, recommendations regarding reviews in the next stages are also made. For example, in a detailed design review, the group may recommend which code modules should undergo group reviews in the build phase.
The moderator is in charge of the meeting and ensures that the meeting stays focused on its basic purpose defect identification and does not degenerate into a general brainstorming session or personal attacks on the author. The moderator should undergo formal training on how to conduct reviews or should have experience as a participant in a few reviews. During the meeting, the moderator must make sure that all participants contribute effectively, that everyone is heard, that agreement is reached on the findings of the review, and that the interest level does not drop. A key responsibility is to ensure that the focus remains on problem identification and does not drift into problem resolution. Overall, orderly and amicable conduct of the meeting is largely the responsibility of the moderator. After the meeting, the moderator must make sure that all participants are satisfied, the review report is filled and communicated, and follow-up actions are taken.
In a review meeting, a person can be assigned several of these logical roles, with the restrictions that the author cannot be the moderator or the reader, and the moderator cannot be the reader. This limitation implies that the minimum size of the group review team is three: the author, the moderator, and the reader. These three people are also reviewers, and one of them can act as the scribe.
10.1.4 Rework and Follow-up
The author performs rework to correct all defects raised during the group review meeting. The author may also have to redo the work product if the moderator recommends it. In addition, if the reviewers have been assigned open issues, they must investigate those problems and give the investigation results to the author and the moderator.
The author reviews the corrections with the moderator or, if the moderator has decided one is necessary, in a re-review. The scribe ensures that the group review report and minutes of the meetings are communicated to the group review team. After all the issues and defects are closed, the moderator ensures that the group review results and data are recorded and that the group review summary form (see section 10.2.3) is submitted to the SEPG and the project leader.
10.1.5 One-Person Review
Group review is a highly effective way of identifying defects. Unfortunately, its cost is also high: Many people spend time in preparation as well as in the review meeting. In addition, arranging group review meetings is a complex logistical problem, with associated overhead. If the work product has many defects or is a critical one, this cost is justified. Indeed, group reviews may turn out to be a cost-effective way of uncovering those defects. But what if the work product is relatively straightforward, is not likely to have many defects, and is not very critical? In this case, the group review effort may not be justified. Nevertheless, some review of such work products may be useful not only to detect defects but also to gain the psychological benefits that accrue when the author knows that someone else will be reviewing the product.
For such situations, a one-person review may be more appropriate. That is, for work products of medium criticality or complexity, a one-person review may be substituted for a group review. One-person reviews are formal reviews but are less costly than group reviews because they do not involve a review team.
The process for one-person reviews is similar to the group review process. The author, in consultation with the project leader, identifies the reviewer. The review is scheduled, and the reviewer receives the review package in advance. The reviewer reviews the work product individually and prepares for the meeting with the author. The review meeting has only two participants: the author and the reviewer. During the meeting, an issues log and a defects log are generated. The reviewer informs the project leader when the review is finished. The project leader is responsible for tracking defects to closure.
10.1.6 Guidelines for Reviews in Projects
Not all work products in a project undergo group review because it may be prohibitively expensive and may not give commensurate returns. Following are some general guidelines for the selection of work products for reviews.
For a specific project, the actual criteria and the decision regarding the work products to be reviewed are left to the project manager and the team reviewing the work products of the early phases. Armed with the outcome of the reviews, the team can make better decisions regarding what to review in the rest of the project and which method to use. Because the work products of the early part of the life cycle are critical and because defects in them have a multiplier effect in the later stages, it is recommended that the following work products be group reviewed:
The project management plan
The requirement specification
The system test plan
The high-level design
The integration test plan
At the end of high-level design review, the group review team makes a recommendation for review of the detailed design. Similar recommendations are made for the code at the end of the review of the detailed design.
Although the review process is the same for any work product, some differences arise in terms of the focus of the review, the entry criteria, and the makeup of the review team based on the nature of the work product. The checklists used also depend on the nature of the work product. Table 10.1 summarizes the guidelines for a few of the work products. Guidelines for other work products are similar.
Table 10.1. Guidelines for Review of Work Products | |||
| Work Product | Focus | Entry Criteria | Participants |
| Requirement specification | Requirements meet customer needs. Requirements are implementable. Omissions, inconsistencies, and ambiguities in the requirements. | The document conforms to the standards. | Customer Designers Tester (system testing) Installation team member User documentation author |
| High-level design | High-level design implements the requirements. The design is implementable. Omissions and other defects in the design. | The document conforms to standards. The requirements have been reviewed and finalized. | Requirements author Detailed designer Developer |
| Code | Code implements the design. Code is complete and correct. Defects in code. | The code compiles and passes style and other norms. | Designer Tester Developer |
| System test cases | The set of test cases checks all conditions in the requirements. System test cases are correct. Test cases are executable. | Requirements have been baselined. System test plan is consistent with the standards. | Requirements author Tester Project leader |
| Project management plan | Project management plan meets project management and control needs. Completeness. Project management plan is implementable. Omissions and ambiguities. | The project management plan follows the standard template. | Project leader SEPG member Another project leader |
EAN: 2147483647
Pages: 83