U.2.1 Establish a review strategy before completing the project plan.
U.2.1.1 Select an appropriate set of review guidelines as part of the SQA plan developed in Task U.1.13.
U.2.1.2 Identify review points for the project.
U.2.1.3 Schedule review points as project tasks.
The project manager and staff should select review points for the project. Questions answered include: Where in the process flow should reviews be conducted? How many reviews should be conducted for each CPF activity? The project plan/schedule should identify review points explicitly and should allocate effort and duration to each. In addition, the plan should allocate effort to the work required to respond to issues uncovered during review.
U.2.2 Initiate formal technical reviews as project deliverables are produced.
Formal technical reviews are conducted as deliverables are produced. In essence, the reviews become SQA "exit conditions" for movement to the next CPF activities and tasks.
U.2.3 Conduct a formal technical review to uncover errors in a software engineering deliverable.
U.2.3.1 Assign a review leader to coordinate the review.
U.2.3.2 Distribute review materials [work product(s)] to reviewers.
U.2.3.2 Set the review agenda and select appropriate checklists.
U.2.3.3 Review work product(s) to uncover errors.
U.2.3.4 Conduct the review meeting.
U.2.3.5 Record any errors and/or issues that are raised during the review meeting.
U.2.3.6 Decide the outcome of the review.
U.2.3.7 Ensure that proper review records are kept.
U.2.3.8 Collect any defined metrics for the review.
Intent: The intent of this task is to uncover errors in any work product produced as a consequence of a software engineering task
Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 328 - 334.
Application of Formal Methods: walkthrough or inspection approach
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Are reviews scheduled as part of the project timeline?
2. Have review team members prepared in advance?
3. Are written records maintained for each review?
Do’s & Don’ts
Do: Review small work products, not massive deliverables. The review should generally take no more that 60 - 90 minutes.
Do: Train team members in review technique and psychology before conducting reviews.
Do: Keep the tone light.
Don’t: Tolerate people who will not prepare in advance. They must.
Don’t: Review the person. Review the product.
Don’t: Let reviews turn into a personnel appraisal.
Helpful Hints
Reviews are actually a technical meeting. Therefore, if you avoid the problems that cause meeting to fail, you’ll avoid the problems that cause reviews to fail. Be sure that you have an agenda before starting the review. Be certain that you define a strong review leader. Take notes. Don’t let the review turn into a problem solving session. The purpose of a formal technical review is to uncover errors, not necessarily to resolve them.
Deliverables:
1. Technical review summary report
2. Issues list
U.2.4 Evaluate review results on a regular basis.
The project team should "debrief" on reviews regularly in an effort to improve the review approach.
Use Browser "back" arrow or return to APM Process Design Language Description
