This is the last batch of questions from the webinar as a pre-cursor to the session I’ll be doing on #softwarequality measurement for the Quest 2014 conference. These questions focused on something really relevant in my research which is a “software quality scorecard”. I’ve started working on a framework and did a short video here. The webinar was recorded as well. You can access here.

What did the acronym KLOC/FP mean listed in the slides.

  • KLOC is K (thousand) L (Lines) O (Of) C (Code).
  • FP is (Function Points). See answer to other question for more explanation.

There are some general conversion ratios to use which can help sizing estimates. For instance, “46” to 1 for LOC to FP for C#.

How important is defect density as a measurement?

Defect density is a great measurement when done across the different functionalities or modules of your software. It enables you to see where you should be looking harder and what peripheral areas might have more defects as well. It would be similar to understand what part of your body needed the most work for exercise? Or what blood reading was not normal. It allows you to focus where you need to.

What recommendations do you suggest that we include on a weekly QA or software quality scorecard?

I would suggest measurements in each part of your QA process and in each role.

For example, measure:

  1. test execution % as a percentage to measure progress
  2. defect arrival rate as a barometer on the software quality
  3. defect density to measure each module’s defects and possible need for more test cases in that module
  4. hours planned versus actual hours to understand both for development and for testing how accurate your forecasts are. Inaccuracy has reasons…

Will you discuss how to generate metrics per function point?

Metrics per function point only make sense for size calculations. For instance, you can use it for testing hours/function point, or defects/function point, or development hours/function point.

What measurements do you use to measure project delivery?

Not sure what you mean by project delivery, but I assume you means schedule and costs. We typically use variance as our primary measurements. Did we include the functionality we intended? Did we do it in the amount of time? both labor and calendar time, and of course the costs related to all those. If that did not quite answer your question, please send another note with more specifics.