Tim,
I can only give general advice without knowing the details. You have a basline measurement, but I’d revisit D and M. D to confirm the problem statement, goals, and scope of the improvement effort. M not only to make sure you’re measuring the right thing but to better understand the limitations of your measurement system. There’s plenty of information on this site and elsewhere about techniques for evaluating your measurement system so you can determine how much confidence you have in your 23% difference. This is important to know since you want to be able to show that there was improvement beyond the variation that may be due to measurement innaccuracy — And you may find that you need to improve the accuracy of the measurement systems you used to get that 23%.
In the Analysis phase, do not get sidetracked into looking for the causes of the defects that were not found during code review. You want to understand why they were not detected. So whatever tools you use (FMEA, C&E, QFD, etc.) make sure that you are using them to understand failures in the code review process.
During the Improvement phase, but not before, you can consider published standards and good practices to get ideas for improving your code revew / peer review / structured walkthrough practices, which may include implementing some automated code analysis tools. Do the Analysis phase first so that you understand what you need to fix in your current process. I have not read the book that Gregg suggested so I can’t recommend. Here are two references that I’ve used successfully and do recommend:
1. The Peer Review key process area of the Software Engineering Institute’s Capability Maturity Model for Software v. 1.1 (1993). The SEI retired this old SW-CMM and incorporated the Peer Review practices into the CMMI for Developement. Download a copy from: http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html However it does not have the focus and detail of the old SW-CMM so I still recommend the old version for Peer Reviews if you can dig up a copy.
2. I’ve used Edward Yourdon’s book “Structured Walkthroughs” as a guide and found it very helpful. You can get a copy through Amazon.
In the Control phase, make sure that you are monitoring and controlling key process variable(s) that allow you to be proactive rather than reactive. The % of defects not detected during code review is reactive since it is an output measurement. Keep track of that, but look for input or intermediate variables that will help you manage the code review process before defects are passed to the next step. Identify these variables during M, A, and I.
.
