Quality Measurements in Software Projects
If a process can not be measured, it can not be controlled. The primary reason for collecting and analyzing process metrics is to identify sources of process variation and to determine if observed variation is acceptable. Often effort is wasted to fix a process that is not actually broken. But more often than not, insufficient effort is expended to prevent re-work and more defects that degrade work product quality and functionality. This is particularly important in software development projects: The later defects are detected in the development cycle, the more those defects cost to resolve.
There are several major types of measurement sources. One source is directly observable - there are physical features that can be measured (dimensions), events that occur in a measurable amount of time (defects found during a peer review), and defects that can be counted over project segments (defects in each SDLC phase). Another measurement source consists of indirect or calculated measurements based on direct measurement sources. Examples include direct measurements expressed as ratios and percents, including percent re-work, percent of total defects injected by phase, hours per defect, and defects per lines of code.
How often measurement is performed depends on what must be measured. An inspection occurs whenever a work product is ready for inspection or review. A process is measured when there is a failure to produce a quality output in the time allotted. Generally, measurements in software development projects should be taken to establish baselines and determine if on-going results are outside of observed measurement ranges.
In a typical project most metrics charts are derived from data collected about inspections of work products, code or reviews of processes. Metrics generated as a result of measurements made during peer reviews can be grouped under a category labeled, "Peer Review Data Analysis." Findings documented during peer reviews are further analyzed and the results of those analyses presented in another set of metrics charts labeled, "Defect Characterizations."
Too often data is collected without any plan for how that data is to be used. The purpose of a Quality Management Plan is to provide a metrics use plan to ensure that the data collected in a software project is put to good use. The primary reasons for collecting integrated engineering metrics include characterization, evaluation, prediction, and improvement of project management and engineering processes. Organizations following the CMMI approach to systems and software development employ metrics to plan, manage, and monitor integrated engineering processes.