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:   
Input to Activities:    Output from Activities:   

Purpose To top of page

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 To top of page

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 To top of page

Review activities are integral to the Rational Unified Process and occur throughout the development lifecycle. Major reviews are held as scheduled in the Review and Audit Plan section of the Quality Assurance Plan.

Responsibility To top of page

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 To top of page

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.



Rational Unified Process   2003.06.13