[[Property:title|14 Computing Project Metrics]]
[[Property:link_title|Computing Project Metrics]]
[[Property:weight|0]]
[[Property:uuid|8d1a3556-d9a2-0ac8-4d54-458f18cb56ad]]
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 <span>quantitative</span> information about their projects. You can get such information through the <code> Metrics </code> 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.
<div> 
==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 <span>linear combination</span> of existing ones, but not a way to compute arbitrary arithmetic operations, since it isn't clear that -- say -- <span>multiplying</span> two metrics ever makes sense. 
</div><div> 
==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 <code> Classes </code>, 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 <code> Classes </code>, is called <code> class </code>. 

EiffelStudio provides a set of predefined units. Some simply serve to count occurrences of certain construct specimens in the software; examples include <code> group </code>, <code> class </code>, <code> feature </code>, <code> line </code>, <span>...</span> The metric <code> ratio </code> 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. In a domain 
</div>
==Metric tool interface==
*  [[Metric Evaluation Panel|Metric Evaluation panel]]  
*  [[Detailed Result Panel|Detailed Result panel]]  
*  [[Metric Definition Panel|Metric Definition panel]]  
*  [[Metric History Panel|Metric History panel]]  
*  [[Metric Archive Panel|Metric Archive panel]]