Measurement: A quick start

Today, this blog will start some discussions related to the roots about software reuse: the productivity issue. These discussions will approach productivity in general, software metrics and, finally, software reuse metrics. We will begin with an important aspect when we are talking about productivity: Measurement. What is it and why we have to do it is the point inspired by Fenton & Pfleeger’s texts.

In our life, day by day we are applying measurements in our activities, jobs, etc. For example, we have economic measurements to determine the prices; measurements in radar and medical systems in order to diagnose illnesses, weather prediction etc. Thus, measurement helps us to understand the world, interact with it and, in some sense, improve our lives based on it.

These are examples of measurements, but a more formal definition stated by Fenton & Pfleeger is that: “Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules”.

But, what are the attributes and entities in their definition? Let us start with entities. An entity is an object (such as a person or a room, for example) or an event (such as a journey in a road or the testing phase of a software project) in the real world. On the other hand, an attribute is a feature or property of an entity. Typical attributes include the distance (of a journey) and its cost, or the time (during the test phase). In our life, we talk about entities and their attributes interchangeably. However, as highlighted by Fenton & Pfleeger, it is wrong to say that we measure things or that we measure attributes; in fact, we measure attributes of things. Thus, we can make judgments about entities by knowing and analyzing their attributes.

However, in this process, we have some difficulties issues which should be analyzed to avoid false assumptions:
1. In general, the accuracy of a measure depends on the measuring instrument as well as on the definition of the measurement. However, some measures are not likely to be accurate, either because the measurement is imprecise or because it depends on the judgment of the person doing the measuring. Think in soccer, how to define a good player or the best team?
2. Even when the measuring devices are reliable and used properly, there is margin for error in measuring the best understood physical attributes. Thus, how do we decide when error margins are acceptable and which are not?
3. When is a scale acceptable for the purpose to which it is put?

In general, we can see measurement and electrical, mechanical, and civil engineering. On the other hand, it is not often in software engineering and in some projects: we fail to set measurable targets for the products; to understand and quantify the component costs of software projects; and we do not quantify or predict the quality of the products which we produce. Moreover, when measurements are made, they are done infrequently, inconsistently, and incompletely. For example, you can remember a software engineer saying that in his code was found just 10 faults in 5000 lines of code. But, often we think: how these results were obtained, how this analysis was performed and interpreted, what entities were measured and how….Thus, as you can see, measurement in software engineering needs a rigorous approach to do it.

In summary, it is good to remember: even when a project is not in trouble, measurement is useful and necessary because how can you tell: ok, my project was a successful? How can we compare our project with some baseline? How to identify points to corrective action? Measurement is useful to understand, control and improvement the work. Thus, remember Tom DeMarco when he said:

“You cannot control what you cannot measure”.

Remember also of managing the expectations of those who will make measurement-based decisions. Explain about the limited accuracy of prediction and the margin of error in the measurement.