<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_7ygXoMM3EdmSIPI87WLu3g"
    name="metrics,_0mYYkMlgEdmt3adZL5Dmdw" guid="_7ygXoMM3EdmSIPI87WLu3g" changeDate="2007-07-24T09:06:44.625-0700">
  <mainDescription>&lt;h3>&#xD;
    &lt;font size=&quot;5&quot;>What is a Metric?&lt;/font>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    We distinguish between measure and metric. To clarify, let’s start by defining what is meant by measure and by metric.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Measure&lt;/b>: A raw data item that is directly measured, and that will be used to calculate a metric.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Metric&lt;/b>: An interpretation of a measure or a set of measures that you use to guide your project. For example,&#xD;
        recording how many test cases have passed and how many have failed are measures. Interpreting what level of quality&#xD;
        this indicates and how it reflects the team's progress within the current iteration is a metric.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;font size=&quot;5&quot;>Why Measure?&lt;/font>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Measurements will mainly help you to:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Communicate effectively&lt;/b>. Measurement supports effective communication among team members and project&#xD;
        stakeholders.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Identify and correct problems early&lt;/b>. Measurement enables you to identify and manage potential problems early&#xD;
        in the development lifecycle.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Make informed trade-offs&lt;/b>. Measurement helps objectively assess the impact of decisions, helping&amp;nbsp;the&#xD;
        team&amp;nbsp;make trade-off decisions to best meet project goals.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Tune estimations&lt;/b>. Recording schedule, progress, and expenditures for projects will help team members to make&#xD;
        more reliable estimations in the future.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;font size=&quot;5&quot;>Potential Challenges&lt;/font>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are several dangers when it comes to metrics:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;div align=&quot;left&quot;>&#xD;
            &lt;b>They can be too costly&lt;/b>. The benefit provided by the metric must exceed the cost of collecting it. Keep&#xD;
            your measurements simple and easy to collect.&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div align=&quot;left&quot;>&#xD;
            &lt;b>They’re a poor substitute for communication&lt;/b>. Do not use metrics as a substitute for communication. Team&#xD;
            members may help to decide which metrics make sense for the project. Apply metrics not so much to control the&#xD;
            project but to help team to collaborate better. Asking people about their progress is a co-dependent way of&#xD;
            gaining insight into progress.&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div align=&quot;left&quot;>&#xD;
            &lt;b>They can be misleading&lt;/b>. No metric or collection of metrics is perfect. Furthermore, the measurements&#xD;
            upon which they are based can be manipulated by the people capturing them. Don’t rely simply upon metrics to&#xD;
            manage a project.&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Effective metrics programs can be challenging to implement, though typically not because of the statistics and complex&#xD;
    analysis often associated with metrics. Rather, the challenge lies in understanding which metrics add value to the&#xD;
    project and to the company, and which procedures are most efficient for collecting and using these metrics.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Consider to implement only a handful metrics. Importantly, do not collect metrics unless they help contribute to a goal&#xD;
    of improving a defined area of your software development process. If you will not act on a metric, do not collect it.&#xD;
    It is much more important to focus on a small number of metrics that are important to what you are trying to achieve&#xD;
    right now, versus a larger set of metrics that may be &quot;good to track&quot;.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;font size=&quot;5&quot;>Example Metrics&lt;/font>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Below are some common measures and associated metrics used in software development projects. These metrics help teams&#xD;
    communicate, identify and correct problems early, make informed trade-offs, and tune estimations. Example metrics&#xD;
    coverage areas are listed below.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Software quality&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Defect backlog: Number of defects discovered respectively resolved per iteration&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Test case coverage: Number of test cases executed over total number of test cases&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Code coverage: % of code that have been tested&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Development productivity&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Velocity: Number of delivered points by iteration (see &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../../openup/guidances/guidelines/agile_estimation.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Agile&#xD;
        Estimation&lt;/a>)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Development process effectiveness&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Responsiveness to quality issues: Number of defects discovered versus resolved per iteration&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Responsiveness to process improvement proposal: Number of process enhancements proposed versus implemented&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Cost and schedule estimate and variance&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Effort: Actual effort spent per iteration&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Cost: Cost per iteration&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Effort remaining: Track &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/reports/project_burndown.html&quot;&#xD;
        guid=&quot;_ePrt8Dj3EduxovfWMDsntw&quot;>Project Burndown&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    There are many other measures and metrics that may make sense, based on what you are trying to accomplish. As an&#xD;
    example, to measure the quality of your architecture, you may for example choose to collect metrics related to coupling&#xD;
    between different software packages (groups of related classes) by measuring extensibility, dependency, and&#xD;
    responsibility of each package.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>