Improvment Project for Code Review Effectiveness
Six Sigma – iSixSigma › Forums › Old Forums › Software/IT › Improvment Project for Code Review Effectiveness
- This topic has 5 replies, 3 voices, and was last updated 13 years, 1 month ago by
Tim.
-
AuthorPosts
-
April 6, 2009 at 12:11 pm #26861
Hi All,
I have to do a project on improving the code review effectiveness of organization.
Presently we are having manual process and going for automated one is not quiet possible.
Would like you all to share your experiences and also guidance on how to proceed as a whole.
TIM
0April 6, 2009 at 2:37 pm #65263
Gregg SporarParticipant@Gregg-SporarInclude @Gregg-Sporar in your post and this person will
be notified via email.There is a free book available on code review best practices: http://smartbear.com/codecollab-code-review-book.php
0April 8, 2009 at 4:23 am #65264
Don StrayerParticipant@Don-StrayerInclude @Don-Strayer in your post and this person will
be notified via email.You need a baseline measurement of current effectiveness. Without that any improvement you may claim by adopting good practices published in books, standards, frameworks, etc. or by implementing code analysis tools is just assumption. Start by measuring the ratio of defects found during code review to defects found after review.
0April 8, 2009 at 5:03 am #65265Thanks Don,
i have the baseline data reflecting 23% difference in pre and post review defects.
Also, if you can guide about he typical steps to follow as six sigma projects for the same, it will be great help
0April 10, 2009 at 5:17 am #65270
Don StrayerParticipant@Don-StrayerInclude @Don-Strayer in your post and this person will
be notified via email.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.0April 10, 2009 at 6:24 am #65271Thanks a lot Don,
that was really helpful0 -
AuthorPosts
The forum ‘Software/IT’ is closed to new topics and replies.