An Approach to Measurement Java Code Quality in a Reuse Environment

A reuse environment was defined by [Frakes, 1994] as an environment where process and tools give support for activities that are important to build components with/for reuse. According to [Griss, 1994], a repository is one of the most important elements in a reuse environment. However, the quality of the assets on the repository had been questionable according to the type of reuse model adopted.

We are thinking about a reuse model where anyone can store assets on the repository without previous analysis. In this model, we have a low reliability about the reusable assets because anyone can store assets and who will reuse don’t have assets' quality assurance. In this model, the main problems are low reliability and a concern about code problems propagation.

We are developing an approach that can minimize these problems. In this approach, the repository can check the stored assets' quality according to metrics. For this initial stage, we are considering a repository where are stored only Java code. Thus, to develop this approach we accomplish the main steps: (i) investigate code metrics that can be used; (ii) select quality attributes; and (iii) quality attributes measurement.

In the first step, we made a time line about software code metrics and selected a set of metrics that can be used in our approach. We analyzed ten metrics groups and we were selecting the metrics according the following criteria: applicable for Java code; there are researche reporting about empiric validation; there are a consistent theoretical validation; and the metrics have a good acceptance, in other words, they were implemented in the analyzed metrics tools. The selected metrics were LOC, Cyclomatic Complexity [McCabe, 1976] and Chindamber and Kemerer metrics [Chidamber, 1994].

The second step was to select what type of quality attributes would be quantified in our approach. We selected the Maintainability quality attribute described in ISO 9126. In the third step, we made a relationship between each quality attribute of Maintainability and a set of metrics selected that can quantify these attributes. So, this approach can quantify a set of quality attributes using code metrics.

The next stage in this work is to integrate the approach automation in a reuse environment. Thus, we want to analyze if the retrieved component's quality is better, and if it is possible this approach to reduce the reuse of low quality code. We believe the main contribution of this research is to introduce a little bit of the quality analysis responsibility of the reusable assets also to the repository. Thus, we can have more reliability in a reuse environment without a certification process for stored assets on the repository, moreover it can reduce the cost to introduce reuse in a begging stage.

Software Measurement: The Initial Climb

Software Measurement: The Initial Climb. Yes, it was the title of my talk at Virginia Tech University, Falls Church, U.S. In this talk, I presented an overview about this topic involving some definitions, the measurement process, the theory of measurement, software measurement programs, including empirical studies and companies reports, and the current state in the area.

You can see our previous discussion about software measurement here.

See the slides of the presentation here.

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.