The majority of software developers still do not measure, and sadly, most have little desire to begin. As we noted earlier in this chapter,...
The majority of software developers still do not measure, and sadly, most have little desire to begin. As we noted earlier in this chapter, the problem is cultural. Attempting to collect measures where none had been collected in the past often precipitates resistance. "Why do we need to do this?" asks a harried project manager. "I don't see the point," complains an overworked practitioner.
Arguments for Software Metrics
Why is it so important to measure the process of software engineering and the product (software) that it produces? The answer is relatively obvious. If we do not measure, there no real way of determining whether we are improving. And if we are not improving, we are lost.
By requesting and evaluating productivity and quality measures, senior management can establish meaningful goals for improvement of the software engineering process. If the process through which it is developed can be improved, a direct impact on the bottom line can result. But to establish goals for improvement, the current status of software development must be understood. Hence, measurement is used to establish a process baseline from which improvements can be assessed. The day-to-day rigors of software project work leave little time for strategic thinking.
Software project managers are concerned with more mundane (but equally important) issues: developing meaningful project estimates, producing higher-quality systems, getting product out the door on time. By using measurement to establish a project baseline, each of these issues becomes more manageable. We have already noted that the baseline serves as a basis for estimation. Additionally, the collection of quality metrics enables an organization to "tune" its software process to remove the "vital few" causes of defects that have the greatest impact on software development.
At the project and technical levels (in the trenches), software metrics provide immediate benefit. As the software design is completed, most developers would be anxious to obtain answers to the questions such as
• Which user requirements are most likely to change?
• Which components in this system are most error prone?
• How much testing should be planned for each component?
• How many errors (of specific types) can I expect when testing commences?
Establishing a Baseline
By establishing a metrics baseline, benefits can be obtained at the process, project, and product (technical) levels. Yet the information that is collected need not be fundamentally different. The same metrics can serve many masters. The metrics baseline consists of data collected from past software development projects To be an effective aid in process improvement and/or cost and effort estimation,
baseline data must have the following attributes:
(1) data must be reasonably accurate—"guestimates" about past projects are to be avoided;
(2) data should be collected for as many projects as possible;
(3) measures must be consistent, for example, a line of code must be interpreted consistently across all projects for which data are collected;
(4) applications should be similar to work that is to be estimated—it makes little sense to use a baseline for batch information systems work to estimate a realtime, embedded application.
Metrics Collection, Computation, and Evaluation
Ideally, data needed to establish a baseline has been collected in an ongoing manner. Sadly, this is rarely the case. Therefore, data collection requires a historical investigation of past projects to reconstruct required data. Once measures have been collected (unquestionably the most difficult step), metrics computation is possible. Depending on the breadth of measures collected, metrics can span a broad range of LOC or FP metrics as well as other quality- and project-oriented metrics. Finally, metrics must be evaluated and applied during estimation, technical work, project control, and process improvement. Metrics evaluation focuses on the underlying reasons for the results obtained and produces a set of indicators that guide the project or process.
