Formal technical review; Garvin’s quality dimensions

A formal technical review (FTR) is a planned, structured meeting in which a small group of software engineers examines a work product (SRS, design, code, test plan) to find errors early. Walkthroughs and inspections are the common types of FTR.

Conducting a formal technical review

Constraints on the review meeting (Pressman):

• 3 to 5 people take part.
• Each reviewer prepares in advance, but for no more than about 2 hours.
• The meeting itself lasts less than 2 hours.
• So the review covers a small, specific part of the product (for example one component's design or 200–300 lines of code), not the whole system.

Roles

• Producer: the developer who created the work product.
• Review leader: plans and chairs the meeting.
• Reviewers (2–3): examine the product and raise issues.
• Recorder: writes down every issue raised.

Steps

1. The producer tells the project leader that the work product is complete and ready for review.
2. The project leader contacts a review leader, who checks the product for readiness, makes copies and gives them to the reviewers.
3. Each reviewer studies the product for 1–2 hours and notes possible errors, often using a checklist.
4. In the meeting, the producer walks through the product and explains it. Reviewers raise issues; the recorder logs each one.
5. At the end, all participants decide to:
   • accept the product without changes,
   • reject it because of serious errors (another review is needed after correction), or
   • accept provisionally (minor errors must be fixed, with no further review).
6. Everyone signs off. The recorder produces a review issues list and a review summary report (what was reviewed, who reviewed it, what was found, the decision).
7. Follow-up: the review leader checks that every item on the issues list has been corrected.

Producer --> Project leader --> Review leader
                                   |
                     copies to reviewers (prepare)
                                   |
                            Review meeting
                                   |
            Accept / Reject / Accept provisionally
                                   |
           Issues list + summary report --> Follow-up

Review guidelines

• Review the product, not the producer; keep criticism polite.
• Set an agenda and keep to it; limit debate and rebuttal.
• Point out problem areas, but do not try to solve every problem in the meeting.
• Take written notes; use checklists for each type of work product.
• Limit the number of participants and insist on advance preparation.
• Schedule time and resources for reviews, train reviewers, and review the early reviews to improve the process.

Garvin's quality dimensions

David Garvin proposed eight dimensions for judging the quality of a product. Pressman applies them to software:

Garvin's dimensions show that quality is multi-dimensional: some (reliability, conformance) can be measured objectively, while others (aesthetics, perception) are subjective but still matter to users.