The Rational Unified Process: An Introduction (3rd Edition)

THE CONCEPT OF METRICS

Why do we measure? We measure primarily to gain control of a project and therefore to manage it. We measure to evaluate how close or far we are from the plan's objectives in terms of completion, quality, and compliance with requirements. We also measure so that we can plan better a new project's effort, cost, and quality based on experience. Finally, we measure to evaluate the effects of changes and assess how we have improved over time on key aspects of the process's performance (see Chapter 17).

Measuring key aspects of a project adds a non-negligible cost, so we do not measure something simply because we can. We must set precise goals for a measurement effort and collect only metrics that allow us to satisfy these goals. There are two kinds of goals: ^[4]

^[4] K. Pulford, A. Kuntzmann-Combelles, and S. Shirlaw, A Quantitative Approach to Software Management ”The ami Handbook . Reading, MA: Addison-Wesley, 1995.

• Knowledge goals

  These goals are expressed by the use of verbs such as evaluate, predict, and monitor. They express a desire to understand your development process better. For example, you may want to assess product quality, obtain data to predict testing effort, or monitor test coverage or requirements changes.

• Change or achievement goals

  These goals are expressed by the use of verbs such as increase, reduce, improve , and achieve. They express an interest in seeing how things change or improve over time, from one iteration to another, and from one project to another.

The following are examples of goals that might be set in a software development effort:

• Monitor progress relative to the plan.

• Improve customer satisfaction.

• Improve productivity.

• Improve predictability.

• Increase reuse.

These general management goals do not translate readily into metrics. We must translate them into subgoals (or action goals), which identify the actions that project members must take to achieve the goal. We also must make sure that the people involved understand the benefits.

For example, the goal "Improve customer satisfaction" would break down into the following action goals:

• Define customer satisfaction.

• Measure customer satisfaction over several releases.

• Verify that satisfaction improves .

The goal "Improve productivity" would include these subgoals:

• Measure effort.

• Measure progress.

• Calculate productivity over several iterations or projects.

• Compare the results.

Some of the subgoals (but not all of them) would require that you collect metrics. For example, "Measure customer satisfaction" can be derived from

• A customer survey (in which the customers would give marks for different support aspects)

• The number and severity of calls to a customer-support hotline