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 the 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 measurements that allow us to satisfy these goals. There are two kinds of goals: [4]
The following are examples of goals that might be set in a software development effort:
These general management goals do not translate readily into measurements. 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:
The goal "Improve productivity" would include these subgoals:
Some of the subgoals (but not all of them) would require that you collect measurements. For example, "Measure customer satisfaction" can be derived from the following:
What Is a Measurement?There are two kinds of measurement:
Each measure comprises one or more collected measurements. Consequently, each primitive measure must be clearly identified, and its collection procedure must be defined. Measures to support change or achievement goals are often first-derivative over time (or iterations or project). We are interested in a trend and not in the absolute value of the measure. If our goal is "Improve quality," we must check that the residual level of known defects diminishes over time. |