A FORMAL TECHNICAL REVIEW (FTR) is a software quality control activity performed by software engineers and others. ITS OBJECTIVES (Pressman): 1. to uncover errors in function, logic or implementation for any representation of the software 2. to verify that the software under review meets its requirements 3. to ensure that the software has been represented according to predefined standards 4. to achieve software that is developed in a UNIFORM manner 5. to make projects more MANAGEABLE In addition, the FTR serves as a TRAINING GROUND, enabling junior engineers to observe different approaches to analysis, design and implementation, and it promotes BACKUP AND CONTINUITY because a number of people become familiar with parts of the software they might not otherwise have seen. WHY REVIEWS FIND DIFFERENT DEFECTS FROM TESTING — this is the key point, and it is not merely "two techniques are better than one": · a review can inspect code that has NOT BEEN WRITTEN YET's specification — requirements and designs cannot be executed at all, so review is the ONLY validation available for them · a review examines ALL PATHS by reading, where a test exercises only the paths its inputs reach · a review sees the CODE'S INTENT and can spot "this is correct but will be misunderstood next year" — maintainability defects that no test can express · a review finds MISSING code; a test cannot fail on a feature nobody wrote · but a review CANNOT find defects that emerge from execution — race conditions, performance, integration behaviour, resource leaks under load → reviews and testing are complementary, catching disjoint defect populations. DEFECT AMPLIFICATION — the model that justifies reviewing EARLY. Each development step can pass defects through and generate new ones: errors from errors errors previous step passed amplified ↓ ↓ ↓ ┌────────────────────────────────────┐ │ development step │ │ (detection efficiency %) │ └────────────────────────────────────┘ ↓ errors passed to next step A defect in design that is not caught is not merely carried forward — it is AMPLIFIED, because multiple code modules are written from it. Pressman's classic worked example shows that a project with no reviews ends up with several times the released defects of one with reviews, from the same starting error rate.

THE REVIEW MEETING — Pressman's constraints, which exist to keep reviews effective rather than exhausting: · between THREE AND FIVE PEOPLE should be involved · ADVANCE PREPARATION should occur but should require no more than TWO HOURS of work from each person · the DURATION of the review meeting should be less than TWO HOURS Given these, the FTR focuses on a specific, SMALL part of the overall software — a single work product, not a whole subsystem. Reviewing a smaller piece well beats skimming a large one. THE ROLES: PRODUCER the engineer who developed the work product; informs the project leader it is complete REVIEW LEADER evaluates the product for readiness, generates copies of materials, distributes them, and schedules the review REVIEWERS 2–3 people who spend up to two hours preparing by reading the product and making notes RECORDER one reviewer who records all issues raised THE PRODUCER MAY "WALK THROUGH" the product, or reviewers may raise issues from their prepared notes. The review must be focused on the PRODUCT, NOT THE PRODUCER. THE DECISION — at the end, all attendees must decide whether to: ACCEPT the product without further modification REJECT the product due to severe errors (and re-review after correction) ACCEPT PROVISIONALLY — minor errors must be corrected but no further review is needed All attendees then SIGN OFF, indicating participation and concurrence. THE OUTPUTS: REVIEW ISSUES LIST identifies problem areas, and serves as an action item checklist REVIEW SUMMARY what was reviewed, who reviewed it, what REPORT were the findings and conclusions — typically a single page, and becomes part of the project historical record REVIEW GUIDELINES — the conduct rules, and they matter more than the process: 1. REVIEW THE PRODUCT, NOT THE PRODUCER. A review that becomes personal is worse than no review, because the next one will not be honest. 2. SET AN AGENDA AND MAINTAIN IT. 3. LIMIT DEBATE AND REBUTTAL. Record disagreements for offline resolution rather than arguing in the meeting. 4. ENUNCIATE PROBLEM AREAS, BUT DON'T ATTEMPT TO SOLVE EVERY PROBLEM NOTED. A review is for finding, not fixing. 5. TAKE WRITTEN NOTES. 6. LIMIT THE NUMBER OF PARTICIPANTS AND INSIST UPON ADVANCE PREPARATION. 7. DEVELOP A CHECKLIST for each work product likely to be reviewed. 8. ALLOCATE RESOURCES AND TIME SCHEDULE for FTRs — they are a planned project activity, not a favour done in spare time. 9. CONDUCT MEANINGFUL TRAINING for all reviewers. 10. REVIEW YOUR EARLY REVIEWS — improve the review process itself. TYPES OF REVIEW, from least to most formal: PEER DESK CHECK / over-the-shoulder — informal, one reader PAIR PROGRAMMING — continuous review as the code is written WALKTHROUGH — the author leads the group through the product INSPECTION (Fagan) — the most formal: defined roles, entry and exit criteria, checklists, measured rates, a formal follow-up. Historically the highest defect yields recorded. AUDIT — an external check of compliance, not a defect hunt

REVIEWS ARE MEASURED, and the numbers are what let you tune them. PREPARATION EFFORT (Ep) effort to review before the meeting ASSESSMENT EFFORT (Ea) effort spent during the review REWORK EFFORT (Er) effort to correct errors found WORK PRODUCT SIZE (WPS) pages of documents, or LOC MINOR/MAJOR ERRORS FOUND Err(minor), Err(major) DERIVED: total review effort Ereview = Ep + Ea + Er total errors found Errtot = Errminor + Errmajor ERROR DENSITY = Errtot / WPS review RATE = WPS / (Ep + Ea) WORKED — a design document review: WPS = 32 pages Ep = 4 reviewers × 1.5 h = 6.0 h Ea = 4 reviewers × 1.5 h = 6.0 h Er = 9.0 h Errminor = 18, Errmajor = 7 Ereview = 6 + 6 + 9 = 21.0 person-hours Errtot = 18 + 7 = 25 errors error density = 25 / 32 = 0.78 errors per page major density = 7 / 32 = 0.22 per page review rate = 32 / 12 = 2.67 pages per hour effort per error found = 21/25 = 0.84 person-hours COMPARE with finding those same errors later. At 9 person-hours per defect in system test: 7 major errors × 9 h = 63 person-hours against 21 person-hours for the entire review, which also found 18 minor ones. THE REVIEW PAID FOR ITSELF THREE TIMES OVER on the major defects alone. THE MOST USEFUL DIAGNOSTIC IS THE REVIEW RATE. Published inspection guidance puts effective rates at roughly 150–200 LOC per hour for code and a few pages per hour for documents. A review proceeding at 1,000 LOC per hour is not a review — it is a reading, and its defect yield will show it. If your measured error density is low AND your rate is high, the problem is the review, not the code. REVIEW EFFICIENCY across a project, as a percentage of all defects found: defects found in review 480 defects found in testing 256 defects found by customers 64 review yield = 480/800 = 60% This is the DEFECT REMOVAL EFFICIENCY of the review activity alone, and tracking it over time tells you whether your reviews are improving.