Measure and metric

I received an email where the sender wrote: “What is the difference between a measure and a metric and how many software measure or metric are there?”

Answer: By definition a measure is a standard or unit of measurement for example: Number of defects, number of source lines of code (SLOC). A metric is a calculated indicator based on two or more measures. For example, a number of defects per thousand lines of code (KSLOC). As you can see two or more measures make up a metric and two or more metrics provides you the information. For example, 10 defects per thousand lines of code is better than 40 defects per thousand lines of code.

There are many measures and metrics, probably hundred of them but there are few common measures in software project such as Size, Effort, and Quality. Size is the amount of software a project develops such as number of source lines of code (SLOC). Size can also be measured by Function points or number of functionality. Lines of code is simple, easy to use but each project must clearly defines how to count them consistently. For example the number compiler gives when it compiles a program. Function points are better in some applications because the number is more consistent across languages and it is easy to count the size of the project at the early phase even before coding.

Effort is the amount of work for one person required to perform a task. For example, the number of man-hours spent per phase of software. For example, a project has one person working five days to complete a design activity has an effort of 40 man-hours. If it has two people working five days to complete the design activity than the effort would be 80 man-hours.

Quality has several definitions, depends on the type of project and by the customers or the project manager. Some people consider quality is the number of defects in the product, the more defects the less quality. For example the number of defects found in each phase, or number of defects in each thousand line of code. Other people defines quality as how easy to use the product, the easy users can use the product the better quality. Because each people sees quality differently, it is very important to clarify the definition by document early in the project plan what do you mean by quality.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University