Pragmatic Change Metrics

Section 13.1 describes some goals of a successful metrics program. These goals are reiterated next and discussed in terms of whether the metrics described here meet these goals.

• Metrics must be simple, objective, easy to collect, easy to interpret, and hard to misinterpret. The number of statistics to be maintained in an SCO database to implement this metrics approach is small: fewer than 10. They are simple counts and can have simple definitions, although in practice many of the units of these counts are ambiguous. Depending on the discipline, consistency, and level of automation inherent in an organization's process, the definition and collection of these metrics may be relatively easy. On the other hand, an ad hoc organization with diverse software projects may find it very difficult to converge on acceptable practices. The various perspectives provided by these metrics have a straightforward interpretation in most cases. Most trends are obviously good or bad. Most values are context-dependent, but with data from multiple projects in a common context, it should be easy to reason about similarities and differences.

• Metrics collection must be automated and nonintrusive, that is, not interfere with the activities of developers. All the collected data and analysis required in this metrics approach can be, and have been, automated. While engineers simply follow their normal workflows for generating artifacts, the configuration control system can be instrumented to collect and process all the data required to extract the metrics and trends.

• Metrics must provide consistent assessments throughout the life cycle, especially in early phases, when efforts to improve quality have a high payoff. The approach described here is derived from a software maintenance perspective. However, an iterative development process can be viewed as a merging of the development and maintenance activities into a more common set of life-cycle activities that use the same techniques and tools. From this perspective, an iterative approach can be seen as simply accelerating the establishment of baselines so that baseline changes, and their inherent progress and insight into quality, can be used to better instrument the process. With conventional technologies, this would have been a manual, error-prone activity. With today's advanced change management automation and round-trip engineering support among various engineering artifacts, change freedom is improved and the transition to an iterative process is technically feasible and economically advantageous.

• Metrics, both values and trends, must be used actively by management and engineering personnel for communicating progress and quality in a consistent format. These metrics deal with tangible measurements of evolving software artifacts. They are derived directly from the evolving baselines of the product, not from separate documentation or subjective judgments. Software engineers will accept and use these objective metrics to avoid bad technical and management decisions. As far as managers are concerned, they will acclimate to any objective measures. The metrics presented are straightforward: Most stakeholders can understand them, they can be automated, and they can be compared with the metrics from other projects if used judiciously.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment