Review Guidelines
The reviews guidelines for the conduct of formal technical reviews must be build in advance, distributed to all reviewers, agreed upon and them followed. A review which is uncontrolled can often be worse than no review at all.
The following formal technical reviews represent a minimum set of guidelines for:
1. Take a review the product not to the producer. An FTR involves egos and people. Conducted properly the FTR should leave all participants with a warm feeling of accomplishment. To conduct improperly the FTR can take on the aura of an inquisition. The tone of the meeting should be loose and constructive; The Errors should be pointed out gently and the intent should not be to embarrass or belittle. Review leader should conduct the review meeting to ensure in which the proper attitude and tone are maintained and should immediately halt a review that has gotten out of control.
2. Set an agenda or a policy and maintain it. One of the major key of meetings of all kind is drift. The review leader is chartered with the responsibility for maintaining the meeting schedule and should not be afraid to nudge people when drift sets in. FTR must be kept on track and on schedule.
3. Rebuttal and Limit debate. When an issue is increased through a reviewer there may not be universal agreement on its impression. Rather than spending time debating the question the issue should be recorded for further discussion off-line.
4. Enunciate problem fields but do not attempt to solve every problem noted. By a review it is not a problem solving session it should be postponed until after the review meeting. The solution of a problem can often be accomplished through the producer alone or with the help of only one other individual.
5. Take written notes. It is sometimes a good idea for the recorder to make notes on as wall board so that wording and prioritization can be assessed by other reviewers as information is recorded.
6. Limit the number of participants and insist upon advance preparation. 2 heads are better than 1 but fourteen are not necessarily better than four. Keep the number of people involved to the necessary minimum. However, all review team members must prepare in advance. Written comments should be solicited through the review leader providing an indication; that the reviewer has reviewed the material.
7. Develop a checklist for each work product which is as like to be reviewed. The checklist helps the review leader to structure the FTR meeting and helps each reviewer to focus on important issues. Checklists should be established for analysis or design or coding and even test documents.
8. Arrange the resources and time schedule for FTRs. For reviews to be effectual they should be scheduled as a task during the software engineering procedure. In addition time should be scheduled for the inevitable modification which will occur as the result of an FTR.
9. Conduct important and meaningful training for all reviewers. To be effectual all review participants should receive some formal training. The training should stress both procedure related issues and the human psychological reviews of side. Weinberg and Freedman [FRE90] estimate a 1 month learning curve for every twenty people who are to participate effectively in that reviews.
10. Review your previously reviews. Debriefing can be beneficial in uncovering efforts with the review process itself. The very 1st work product to be reviewed might be the review guidelines themselves.
Because there are many variables example for number of participant's kind of work products timing and length specific the review approach which have an impact on a successful review a software organization should experiment to determine what approach works best in a local context. Porter [POR95] and his colleagues give excellent guidance for this kind of experimentation.