-
Conduct reviews in a meeting format, although the participants of the meetings might prepare some reviews on their
own.
-
Continuously monitor quality during the process tasks to prevent large numbers of defects from remaining hidden
until the reviews. In each task in the Rational Unified Process (RUP), the checklist listed below are referenced to
reinforce this; use them for informal review meetings or in daily work.
In a 1990 standard glossary, IEEE defines three kinds of reviews:
-
Review
-
A formal meeting at which a work product, or a set of work products are presented to the user, customer, or
other interested parties for comments and approval.
-
Inspection
-
A formal evaluation technique in which work products are examined in detail by a person or group other than the
author to detect errors, violations of development standards, and other problems.
-
Walkthrough
-
A review process in which a developer leads one or more members of the development team through a segment of a
work product that he or she has written while the other members ask questions and make comments about
technique, style, possible error, violation of development standards, and other problems.
When implemented across teams, reviews also provide opportunities for people to discover design and code from other
groups, and increase the chances of detecting common source code, reuse opportunities, and opportunities for
generalization. Reviews also provide a way to coordinate the architectural style among various groups.
In the RUP, reviews play an important though secondary part in assuring quality. The major contributors to quality in
the RUP are well described in [ROY98] in the
section on Peer Inspections. However, this book does identify a valuable additional effect of reviews in professional
development: junior staff have the opportunity to see the work of experts, and have their own work reviewed by senior
mentors.
We plan reviews to determine the focus and scope of the review, and to make sure all participants understand their
role, and the goals of the review.
Prior to the review, define the scope of the review by determining the question that will be asked; define what will be
assessed and why? See the Checklist for the work products to be reviewed for the types of questions that could be
asked. The exact questions will depend on the phase in the project: earlier reviews will be concerned with broader
architectural issues, later reviews will be more specific.
Once the scope of the review has been determined, define the review participants, the agenda, the information that will
be required to perform the review. In selecting the participants, establish balance between software architecture
expertise and domain expertise. Clearly and unambiguously designate an assessment leader who will coordinate the
review. If necessary, draw upon other teams or other parts of the organization to supply domain or technical expertise.
The number of reviewers should be approximately seven or less. If chosen appropriately, they will be more than capable
of identifying problems in the architecture. More reviewers actually reduce the quality of the review by making the
meetings longer, making participation more difficult, and by injecting side issues and discussion into the review.
Fewer than 4 reviewers increases the risk of review myopia, as the diversity of concerns is reduced.
Reviewers should be experienced in the area to be reviewed; for use cases, reviewers should have an understanding of
the problem domain; for software architecture a knowledge of software design techniques is also needed. Inexperienced
reviewers may learn something about the architecture by participating, but they will contribute little to the review
and their presence may be distracting. Keep the group small; no more than seven people and no fewer than three. Fewer
reviewers jeopardize the quality of the review, and more reviewers prevent interactive discussion essential to
achieving quality results.
Select reviewers appropriate for the material:
-
those who have the background to understand the material presented
-
those who have an active stake in the quality of product or work product being reviewed
Prior to the review, the work products to be reviewed and any background material should be gathered and distributed to
the review participants. This must be done sufficiently in advance of the review meeting for reviewers to review the
material and gather issues. Distributing review materials sufficiently in advance, and allowing reviewers to have time
to prepare for the review significantly improves the quality of review results. Preparation for reviews also greatly
improves the efficiency and effectiveness of the review.
Reviewers should study the documentation, forming questions and identifying issues to discuss, prior to the
review. Given normal workload of reviewers, a few working days is usually the minimum time needed to prepare for
the review.
There are several keys to conducting a successful review:
Each of these is discussed in detail below.
In general, the review process follows a repetitive cycle:
-
An issue is raised by a reviewer
-
The issue is discussed, and potentially confirmed
-
A defect is identified (something is identified as needing to be addressed)
-
Continue until no more issues are identified
In order for this to work effectively, everyone must understand that the goal of a review is to improve the quality of
the reviewed work product. The work products should be reviewed with a critical eye to finding problems. Doing this can
be difficult, so all reviewers must constantly remind themselves to focus on identifying issues (we are all natural
problem solvers, but as reviewers we must put that aside).
We all have strong ownership of our work; it is often difficult to accept criticism, even when it is constructive. As a
result, we must work even harder to focus on the goals of the review: to make that work better.
In order to conduct an effective review, everyone has a role to play. More specifically, there are certain roles that
must be played, and reviewers cannot switch roles easily. The basic roles in a review are:
-
the moderator
-
the recorder
-
the presenter
-
reviewers
The moderator makes sure that the review follows its agenda and stays focused on the topic at hand. The moderator
ensures that side-discussions do not derail the review, and that all reviewers participate equally.
The recorder is an often overlooked, but essential part of the review team. Keeping track of what was discussed and
documenting actions to be taken is a full-time task. Assigning this task to one of the reviewers essentially keeps them
out of the discussion. Worse yet, failing to document what was decided will likely lead to the issue coming up again in
the future. Make sure to have a recorder and make sure that this is the only role the person plays.
The presenter is the author of the work product under review. The presenter explains the work product and any
background information needed to understand it (although if the work product was not self-explanatory, it probably
needs some work). It's important that reviews not become "trials" - the focus should be on the work product, not on the
presenter. It is the moderator's role to make sure that participants (including the presenter) keep this in mind. The
presenter is there to kick-off the discussion, to answer questions and to offer clarification.
Reviewers raise issues. It's important to keep focused on this, and not get drawn into side discussions of how to
address the issue. Focus on results, not the means.
As discussed above, the moderator plays a crucial role in keeping the review from losing focus. It's important that the
moderator be focused on keeping the review on track; the moderator should not have reviewer responsibilities. The role
of the moderator is to elicit discussion, ensure equal participation, and to defuse contention. This is a full-time
task. Failure to moderate effectively causes reviews to drag on beyond their intended conclusion, and to fail to
achieve their goals.
Reviews are most effective when they are brief and focused on well-identified objectives. Because it is difficult to
maintain focus for long periods, and because reviewers have other work to do as well, limit reviews to no more than two
hours. If a review is expected to go longer, break it into several smaller and more focused reviews. Results will be
better if reviewers can maintain focus.
The key to doing this is to have a well-identified agenda and clearly articulated goals. These should be communicated
when the review materials are distributed, and the moderator should reinforce them when the review meeting begins. The
moderator must then consistently (and sometime ruthlessly) reinforce these goals during the meeting.
One of the major reasons why review meetings fail to achieve their intended results is that they have a tendency to
degenerate into discussions of how a problem should be fixed. Fixing problems usually requires investigation and
reflection; the format of the review is not an effective medium for this kind of discussion. Once the issue is
identified, determine if it is a defect that must be resolved, and then assign it to someone to investigate and
resolve. The review meeting should focus on identification only.
If the issue requires further discussion among a group of people, form a separate meeting to focus on that topic.
Typically this meeting will require some investigation and preparation, and people with the right skills will need to
be involved. The review should remain focused on identifying other issues. The moderator will often need to exert
considerable will to keep the review meeting focused on this.
The review is of little value if nothing comes of it. At the conclusion of the review:
-
Prioritize the list of problems.
-
Create defects to track the problems and their resolution.
-
If additional investigation is required, assign a small team to research the problem (but not to solve it).
-
For problems that can be resolved in the current iteration, assign a person or team to fix the problem.
-
Feed the list of unresolved problems into future iteration planning efforts.
See also [MCO97].
|
