Artifact: Review Record
|
| Created to capture the results of a review activity in which one or more project artifacts are reviewed. |
|---|---|
| Role: | Reviewer |
| Optionality/Occurrence: | Required. Occurs throughout the development lifecycle. |
| Templates and Reports: |
|
| Examples: |
|
| UML Representation: | Not applicable. |
| More Information: |
|
|
|
Purpose
A Review Record is an assessment artifact specialized for review activities. Its primary purpose is to capture the results or conclusions of review activity and identify any action items arising from the review.
Brief Outline
1. Project Identification and Type of Review
Identify the project and the type of review; for example, code inspection, requirements traceability review, PRA project review, project planning review.
2. Artifacts Reviewed and Objectives of the Review
List the artifacts that will be the subject of this review and describe the objectives of the review.
3. Review Participants
List the individuals who will participate in the review and their roles during the meeting; for example, moderator, note-taker, reviewer, author.
4. Schedule & Location
Identify the schedule for the review. Include the date, time and place of the review meeting, and also a publication schedule for the review artifacts if they are not attached to the review record.
5. Problems Identified and Recommendations for Resolution
List any problems identified during the review. Reviewers may identify:
- Problems with the review artifacts that require correction; that is, defects
- Project problems whose symptoms are identified from the review artifacts
- Product problems whose symptoms are identified from the review artifacts
The review team may make recommendations on problem resolution.
6. Action Item Status
List any action items resulting from the review; these should be listed with an identified owner (responsible for action completion) and target date. These will typically be action items intended to correct the problems identified. Action items may include:
| Continue work: | Artifact is not considered complete and development work should continue |
|---|---|
| Raise Work Orders: | If problem requires new work to be planned but doesn't change a baselined artifact |
| Raise Change Requests: | If problem requires change to baselined artifacts |
There may exist action items from previous reviews of this artifact, and these should be listed with their status (for example, open/closed), owner, and target or closure date.
7. Issues for Consideration by the Project Manager
Certain problems or anomalies may be discovered for which a course of action cannot be agreed on by the review team, and which needs to be escalated for resolution.
8. Follow-up Review
Describes the review team's recommendations for follow-up (for example, whether another review is necessary) and what, if any, additional information or data is needed.
9. Record of Effort
Captures the effort-hours spent in review preparation and conduct.
Timing
Review activities are integral to the Rational Unified Process and occur throughout the development lifecycle.
Responsibility
At least one person in the Reviewer role needs to take responsibility for the review record. That responsibility may be allocated at the start of the review meeting, on rotation amongst the members of a review team who meet regularly, or it may be determined based on the most appropriately skilled member of the group. The assigned Reviewer who has responsibility for the review record will also typically be required to manage any follow-up on action items and coordinate problem resolution is that becomes necessary.
In larger teams or in more formal project environments, the responsibilities of the Reviewer role are often delegated to a number of specialized supporting roles:
- Responsibility for organizing the review is delegated to the Review Coordinator role.
- The primary input to the review is provided by the subject-matter experts participating in the review. These experts are represented by one of two specialized roles: Technical Reviewer and Management Reviewer.
Tailoring
While all projects should use this artifact, the level of formality will be differ from project-to-project based on factors such as how formal the relationship is between customer and developer, or how formal the developer's own organization is with regard to process compliance. For example, the project charter may state that reviews are subject to audit: in this case the artifact will typically be treated as an auditable record of the review and its conclusions
While this artifact is primarily used to capture the results of a review, it can also be used as a specialized work order or control document to manage the execution of the review. When used for this purpose it is issued to the participants in the review prior to the review meeting to initiate the review activity.
