Code Review Metrics - Revision history

Michael Hidalgo: Adding few lines into the Code Coverage.

2014-01-14T12:20:10Z

Adding few lines into the Code Coverage.

Michael Hidalgo: Fixing typo on communication word.

2014-01-14T12:05:17Z

Fixing typo on communication word.

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T15:30:51Z

Added navigation to facilitate sequential reading online

KirstenS: /* Reinspection Defect Rate */

2009-01-25T17:11:32Z

‎Reinspection Defect Rate

KirstenS: /* Defect detection Rate */

2009-01-25T17:10:33Z

‎Defect detection Rate

KirstenS: /* Inspection Rate */

2009-01-25T17:10:01Z

‎Inspection Rate

KirstenS: /* Path complexity/complexity-to-defect/cyclomatic complexity */

2009-01-25T17:08:56Z

‎Path complexity/complexity-to-defect/cyclomatic complexity

KirstenS: /* Risk Density */

2009-01-25T17:08:06Z

‎Risk Density

KirstenS: /* Lines of code (LOC) */

2009-01-25T17:03:54Z

‎Lines of code (LOC)

KirstenS: /* Defect Density */

2009-01-25T17:03:42Z

‎Defect Density

@@ Line 78: / Line 78: @@
 ===Code Coverage===
-Measured as a % of LoC of function points, the code coverage is the proportion of the code reviewed. In the case of manual review we would aim for close to 100%, unlike automated testing wherein 80-90% is considered good.
+Measured as a % of LoC of function points, the code coverage is the proportion of the code reviewed. In the case of manual review we would aim for close to 100%, unlike automated testing wherein 80-90% is considered good. In order to ensure that the code coverage standards are met, some organizations might implement a safety check during the build process, so the build will fail if there are any piece of code that has not been tested or if it the coverage is under the desired percentage. The higher the percentage of code coverage, the better to ensure quality and prevent logic errors.
 ===Defect Correction Rate===

@@ Line 13: / Line 13: @@
 ==Some Metric Benefits==
-The objective of code review is to detect development errors which may cause vulnerabilities, and hence give rise to an exploit. Code review can also be used to measure the progress of a development team in their practice of secure application development. It can pinpoint areas where the development practice is weak, areas where secure development practice is strong, and give a security practitioner the ability to address the root cause of the weaknesses within a developed solution. It may give rise to investigation into software development policies and guidelines and the interpretation of them by the users; communcation is the key.
+The objective of code review is to detect development errors which may cause vulnerabilities, and hence give rise to an exploit. Code review can also be used to measure the progress of a development team in their practice of secure application development. It can pinpoint areas where the development practice is weak, areas where secure development practice is strong, and give a security practitioner the ability to address the root cause of the weaknesses within a developed solution. It may give rise to investigation into software development policies and guidelines and the interpretation of them by the users; communication is the key.
 Metrics can also be recorded relating to the performance of the code reviewers and the accuracy of the review process, the performance of the code review function, and the efficiency and effectiveness of the code review function.

@@ Line 1: / Line 1: @@
-[[Category:OWASP Code Review Project]]
+{{LinkBar
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+  | useprev=PrevLink | prev=OCRG1.1:Application Threat Modeling | lblprev=Application Threat Modeling
 Code review is an excellent source of metrics that can be used to improve your software development process. There are two distinct classes of these software metrics: Relative and Absolute.
@@ Line 80: / Line 85: @@
 ===Reinspection Defect Rate===
 The rate at which upon re-inspection of the code more defects exist, some defects still exist, or other defects manifest through an attempt to address previously discovered defects.

← Older revision		Revision as of 17:11, 25 January 2009
Line 79:		Line 79:

	===Reinspection Defect Rate===		===Reinspection Defect Rate===
−	The rate at which upon re-inspection of the code more defects exist, some defects still exist or other defects manifest through an attempt to address previously discovered defects.	+	The rate at which upon re-inspection of the code more defects exist, some defects still exist, or other defects manifest through an attempt to address previously discovered defects.

@@ Line 69: / Line 69: @@
 This metric can be used to get a rough idea of the required duration to perform a code review. The inspection rate is the rate of coverage a code reviewer can cover per unit of time. From experience, a rate of 250 lines per hour would be a baseline. This rate should not be used as part of a measure of review quality, but simply to determine duration of the task.
-===Defect detection Rate===
+===Defect Detection Rate===
-This metric measure the defects found per unit of time. Again can be used to measure performance of the code review team but not to be used as a quality measure. Defect detection rate would normally increase as the inspection rate (above) decreases.
+This metric measures the defects found per unit of time. Again, can be used to measure performance of the code review team, but not to be used as a quality measure. Defect detection rate would normally increase as the inspection rate (above) decreases.
 ===Code Coverage===

@@ Line 67: / Line 67: @@
 ===Inspection Rate===
-This metric can be used to get a rough idea of the required duration to perform a code review. The inspection rate is the rate of coverage a code reviewer can cover per unit of time. From experience, a rate of 250 lines per hour would be a baseline. This rate should not be used as part of a measure of review quality but simply to determine duration of the task.
+This metric can be used to get a rough idea of the required duration to perform a code review. The inspection rate is the rate of coverage a code reviewer can cover per unit of time. From experience, a rate of 250 lines per hour would be a baseline. This rate should not be used as part of a measure of review quality, but simply to determine duration of the task.
 ===Defect detection Rate===

@@ Line 48: / Line 48: @@
 A decision could be considered commands such as:
-If....else
+If....else<br>
-switch
+switch<br>
-case
+case<br>
-catch
+catch<br>
-while
+while<br>
-do
+do<br>
 and so on.....

@@ Line 36: / Line 36: @@
 Similar to defect density, but discovered issues are rated by risk (high, medium & low). In doing this we can give insight into the quality of the code being developed via a   ['''''X Risk / LoC'''''] or ['''''Y Risk / Function Point'''''] value. (X&Y being high, medium or low risks) as defined by your internal application development policies and standards.
-Eg:<br>
+Example:<br>
 High Risk Defects per 1000 (Lines of Code)<br>
 Medium Risk Defects per 3 Function Points<br>

@@ Line 24: / Line 24: @@
 The average occurrence of programming faults per Lines of Code (LOC). This gives a high level view of the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric. Defect density would cover minor issues as well as major security flaws in the code; all are treated the same way. Security of code can not be judged accurately using defect density alone.
-===Lines of code (LOC)===
+===Lines of Code (LOC)===
 The count of the executable lines of code. Commented-out code or spaces don't count. This is another metric in an attempt to quantify the size of the code. This gives a rough estimate but is not particularly scientific. Some circles of thinking believe that the estimation of an application size by virtue of LOC is professional malpractice!
 ===Function Point===

@@ Line 22: / Line 22: @@
 ===Defect Density===
-The average occurrence of programming faults per Lines of code (LOC). This gives a high level view of the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric. Defect density would cover minor issues as well as major security flaws in the code; all are treated the same way. Security of code can not be judged accurately using defect density alone.
+The average occurrence of programming faults per Lines of Code (LOC). This gives a high level view of the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric. Defect density would cover minor issues as well as major security flaws in the code; all are treated the same way. Security of code can not be judged accurately using defect density alone.
 ===Lines of code (LOC)===