Version

Computing Project Metrics

In earlier sections we saw how EiffelStudio provides extensive documentation on your systems. That information was qualitative. Project managers and developers will also be interested in quantitative information about their projects. You can get such information through the Metrics tool, which enables you to perform a number of operations, detailed over the next few pages:

  • Apply predefined metrics -- number of classes, number of invariants, number of features, number of compilations so far and many others -- to components of a system at various levels including feature, class, cluster, entire system.
  • Define new metrics, through mathematical formulae or boolean selection, and apply them to your project.
  • Store measurement results, as well as metric definitions, into an XML archive that can be stored locally or made available on the Web for future reference.
  • Compare the measurements on a system to those on record locally or on a Web site. Eiffel Software has released on its own site an archive recording the metric properties of its basic libraries, available to any other project for comparison.

Methodological observations

Although the field of software metrics is a rich one with an abundant literature, its methodological basis is sometimes subject to question. One should resist the tendency to believe numbers just because they are numbers ("lies, damn lies, and metrics").

Software engineers and their managers expect, however, to reap at least some of the benefits that precise quantification has brought to other engineering fields. Such is the purpose of software metrics, defined as quantitative estimates of product and project properties. Object-oriented development, with the rich software structures that it induces, is a particularly amenable to metric analysis. Even when some of the measures do not seem to bring much by themselves, comparing them to those of other projects may reveal significant peculiarities of a system or of some of its parts.

The metrics capabilities of EiffelStudio were designed with these observations in mind. They result from a conservative approach, where no metric is provided without a credible assumption that it reflects some meaningful project or product attribute. For example, you will find a way to define a new metric as a linear combination of existing ones, but not a way to compute arbitrary arithmetic operations, since it isn't clear that -- say -- multiplying two metrics ever makes sense.

Metric terminology

The following terms are used in the presentation of EiffelStudio metric mechanisms.

A metric -- not to be confused with a measure -- is a quantitative property of software products or processes whose possible values are numbers. A measure is the value of a metric for a certain product or process.

For example, we can evaluate the metric "number of classes in the system", called just Classes, by counting the classes in our system. This yields a measure.

We may distinguish between product metrics, which measure properties of the elements being turned out (code, designs, documentation, bug reports...) and process metrics, which measure properties of the process used to turn them out (salaries, expenses, time spent, delays...). The current metric facilities of EiffelStudio are primarily product-oriented but include a process metric: "number of compilations".

Any metric should be relevant: related to some interesting property of the processes or products being measured, such as cost, estimated number of bugs, ease of maintenance...A metric theory is a set of metric definitions accompanied with a set of convincing arguments to show that the metrics are relevant. Neither EiffelStudio nor this manual provide a metric theory.

The numbers yielded by measures are meaningless unless we describe what they refer to. Every metric is relative to a certain unit, specified as part of its definition. For example the unit for a metric that counts classes, such as Classes, is called class.

EiffelStudio provides a set of predefined units. Some simply serve to count occurrences of certain construct specimens in the software; examples include group, class, feature, line, ... The metric ratio describes metrics whose values are divisions, for example "average number of classes per cluster", obtained by dividing the number of classes by the number of classes.

A metric can be computed over a scope. This scope is defined using a domain. A domain is a set of program elements. You build up a domain by adding development objects to a list. These development objects are things like application targets, clusters, libraries, classes, and features.

Metric tool interface

The following links will take you out of the Guided Tour and into the EiffelStudio Reference:

See Also: The EiffelStudio Reference section on the Metrics Tool for more comprehensive discussion and precise definitions of terminology.

Back to Tutorials
Permanent link
cached: 12/21/2024 12:16:14.000 PM