SE-280 Dr. Mark L. Hornick 1 Design and Code Reviews Review Checklists

SE-280 Dr. Mark L. Hornick 2 Compared to reviews, defect removal in later phases is much more expensive.

SE-280 Dr. Mark L. Hornick 3 Design and code reviews are used to find and fix defects early in the development process. Inspections Walkthroughs Reviews Appraisal methods While unit test rarely has a yield above 50% (industry data, not PSP), experienced reviewers often achieve a yield of 70%. In the PSP, we use only personal reviews; the TSP incorporates team inspections. Reviews generally remove defects more efficiently than testing.

SE-280 Dr. Mark L. Hornick 4 PSP data from SEI and MSOE students confirm the efficiency of code reviews. Note: "compile" values in MSOE data reflect C++, not Java.

SE-280 Dr. Mark L. Hornick 5 To understand the advantage of reviews over testing, let's look at how each handles a defect. ReviewTest Defect existence Understand context Identify cause & how to fix Implement fix time See it Get unexpected result KnownSearch Already knownDebug, isolate FastSlow

SE-280 Dr. Mark L. Hornick 6 Appraisal/Failure Ratio Data from previous SE-280

SE-280 Dr. Mark L. Hornick 7 Defect Removal Efficiency Unit test 2-4 defects/hour Rarely more than 50% found Code reviews 10 defects/hour Experienced reviewers - 70% found 2-5 times as many defects/hour as unit test!

SE-280 Dr. Mark L. Hornick 8 Let's try calculating system test time, based on different assumptions for review yield. Assume that 20 defects are injected in design, and 30 in coding, for a total of 50 defects. Development phase 1 Development phase 2 Development phase 3

SE-280 Dr. Mark L. Hornick 9 PSP reviews make use of Checklists, which are based on historical defect data. Past mistakes -> present mistakes Structures the process

SE-280 Dr. Mark L. Hornick 10 public class Data { Once you have a checklist and the product to be reviewed, how should you proceed? public class Gui {public class Calc { Method arguments Initialization Loop conditions Library usage Checklist format?

The format of a checklist reflects the review process approach. Checklist item"Calc""GUI""Data" 1Copy/paste errors 2Field/var/param initialization 3Check params for method preconditions 4All possible exceptions handled? 5Check for possible null object references In each cell: Enter # of defects found, zero, or "N/A"

How do we manage the quality of our reviews? What can we do earlier in the process (Planning, DLDR, CR)? In postmortem, we can calculate the review yields, but then it is too late to do anything about them! Planning Design DLDR Coding CR Compile UT PM Review rate General guideline: < 200 LOC/hour

When reviewing designs or code, some "minor" details can make a big difference. "Paper or plastic?" Take a break! Reviewing a printed listing, away from your computer, often makes defects more visible. Reviews are more effective if they don’t immediately follow creation of the artifact being reviewed.

SE-280 Dr. Mark L. Hornick 14 Why Checklists again? They help execute precise tasks Difficult to keep track of doing many separate things A Review Checklist: Defines review steps, in order Stages review progress Can be customized to your own defect experience

Personal checklists often combine your personal defect "favorites" with some "standard" categories. Your midterm report defect analysis should suggest some defect categories worth looking out for. You may also get some good ideas from the sample checklists in the textbook (pages 175 and 184). Make your checklist complete enough to support a thorough review.

SE-280 Dr. Mark L. Hornick 16 Next steps Analyze your own Quality Data – Midterm report PD already calculates: Test defects/KLOC Total defects/KLOC Yield Appraisal COQ (%) Failure COQ (%) COQ A/F ratio Action Modify your personal process Analyze again - Final report) Results & Conclusions

SE-280 Dr. Mark L. Hornick 17 Midterm Assignment reading Review textbook pages Download sample code review checklist. Review the midterm report assignment. Carefully review requirements.

One part of the midterm report assignment is designing and executing a "report process". Planning ?? PM Process phasesSize measure(s)? Pages, sections? Charts, tables? In Process Dashboard, add/rename generic phases in the "Midterm Report" project. Why are we doing this, anyway?