If you use an agile methodology it’s continuous. If you use a waterfall methodology where formal testing occurs after development, it can be discrete. One of the major reasons for the success of agile methods is that testing early and often helps us to eliminate defects before they are passed along and become much more expensive to fix.
Defects/Kloc is not a good measurement. The only reason we continue to use it is that Kloc is so easy to measure. We really want to measure DPMO and a line of code is by no means equivalent to an opportunity for defect. I don’t think it’s possible to normalize given that the population of programming languages, styles and development environments is so huge, and constantly changing.
It is not acceptable to use only defects counts. You need some way to get to DPMO so you can compare to the standard measure of quality. I recommend:
1. Clearly define the requirements.
2. Clearly define potential defects for each requirement.
3. Identify where any potential defect might occur (opportunities).
4. Count this number of opportunities.
5. Design tests to determine whether or not a defect exists for each of these opportunities.
6. Count the number of defects detected. This is not simply the number of failed test cases since proper test coverage may require more than one test case for each opportunity.
This will give you the counts to compute DPMO and sigma without the distortion resulting from passed/failed test cases, defects/Kloc, defects/function points, etc.
.
