DESIGN FOR SIX SIGMA (DFSS) SOFTWARE MEASUREMENT AND METRICS - Software Design for Six-Sigma: A Roadmap for Excellence - page 120

The ground rules for a metrics plan are as follows:
Metrics must be understandable to be useful. For example, lines-of-code and
function points are the most common, accepted measures of software size with
which software engineers are most familiar.
Metrics must be economical: Metrics must be available as a natural by-product of
the work itself and integral to the software development process. Studies indicate
that approximately 5% to 10% of total software development costs can be spent
on metrics. The larger the software program, the more valuable the investment
in metrics becomes. Therefore, the team should not waste programmer time
by requiring specialty data collection that interferes with the coding task. They
need to look for tools that can collect most data on an unintrusive basis.
Metrics must be field tested: Beware of software contractors who offer metrics
programs that seem to have a sound theoretical basis but have not had practical
application or evaluation. The team needs to make sure proposed metrics have
been successfully used on other programs or are prototyped before accepting
them.
Metrics must be highly leveraged: The team is looking for data about the soft-
ware development process that permit management to make significant improve-
ments. Metrics that show deviations of 0.005% should be relegated to the trivia
bin.
Metrics must be timely: Metrics must be available in time to effect change in
the development process. If a measurement is not available until the project is
in deep trouble, it has no value.
Metrics must give proper incentives for process improvement. High-scoring
teams are driven to improve performance when trends of increasing improve-
ment and past successes are quantified. Conversely, metric data should be used
very carefully during contractor performance reviews. A poor performance re-
view, based on metrics data, can lead to negative working relationships. Metrics
should not be used metrics to judge team or individual performance.
Metrics must be spaced evenly throughout all phases of development. Effective
measurement adds value to all life-cycle activities.
Metrics must be useful at multiple levels. They must be meaningful to both
management and DFSS team members for process improvement in all facets of
development.
REFERENCES
Basili, V., Gianluigi, C., and Rombach, D. (1994), The Goal Question Metric Approach .
ftp://ftp.cs.umd.edu/pub/sel/papers/gqm.pdf.
Belzer, J., Kent, A., Holzman, A.G., and Williams, J.G. (1992), Encyclopedia of Computer
Science and Technology , CRC Press, Boca Raton, FL.