Information Technology Reference
In-Depth Information
12.1.2 Properties of a Good Measurement or Metric
Software development does not lend itself to the creation of measures and metrics for
several reasons. One reason is that in order to obtain the most accurate and pertinent
measures there must be a deeply engrossed analysis team in place (Basili and Phillips
1981
). An attempt to involve team members so deeply would cause the development
team much anguish and most likely skew any sort of metric or measurement being
attempted. Knowing this, most companies deploy analyst, but they rely on devel-
opers to report their doings using standard forms and accounting procedures.
Even in the most trivial circumstances Basili and Phillips point to a few issues
that can arise from trying to measure things like the number of faults or developer
hours involved in creating a module. One of the more pertinent issues is time
reporting. If an analyst wanted to measure the time spent integrating each of three
separate modules into a subsystem, they could merely read the developer's time
logs and determine the amount of time integrating each module. There are,
however, few methods that the developer could use to log the time spent inte-
grating the modules (Basili and Phillips
1981
):
• Take the overall time and divide it by three (the number of modules in this case).
• Denote the time taken per module as the time it took to associate it with any
other module.
• Associate the entire time with what the developer deems to be the most sig-
nificant module being associated.
Saying all of these measurements have their merits and all have their faults is
cliché, but pertinent to understand why you cannot mix and match measurements
in order to cover for the individual faults of each metric or measurement. Using
more than one will cause unnecessary complications. These complications may not
be evident when examining the measurement in a vacuum, but the faults are
brutally evident when attempting to use these measurements in another metric.
The process for construction of metrics, measurements and their applications
should be consistent throughout an organization and should have well established
guidelines that are followed closely. In order for the metrics to be used properly,
they should be of the least complexity possible.
12.1.3 Etiquette
Measuring and analyzing the software development process is a fundamental part
of development. The information that is gained, though pertinent to the under-
standing of the project as a whole, may come with certain aspects that may provide
personal insight regarding the developers. Some metrics may be found to be
reflective of a certain individuals' competence, though the metric may not be
designed nor actually reflect such a measure. It is necessary to respect the
developer and not provide their name or other identifying information to people
