<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="_7ygXoMM3EdmSIPI87WLu3g"
    name="metrics,_0mYYkMlgEdmt3adZL5Dmdw" guid="_7ygXoMM3EdmSIPI87WLu3g" changeDate="2008-10-13T13:20:11.311-0700"
    version="7.2.0">
  <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 implementing 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;>Common 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 of metrics&#xD;
    coverage areas are listed below.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Software quality &#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;/li>&#xD;
    &lt;li>&#xD;
        Development productivity &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                Velocity: Number of delivered points by iteration (see &lt;a class=&quot;elementLink&quot;&#xD;
                href=&quot;./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html&quot;&#xD;
                guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Agile Estimation&lt;/a>)&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development process effectiveness &#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;/li>&#xD;
    &lt;li>&#xD;
        Cost and schedule estimate and variance &#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&amp;nbsp;project burndown&amp;nbsp;&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#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. For example,&#xD;
    if you want to measure the quality of your architecture, you may choose to collect metrics related to coupling between&#xD;
    different software packages (groups of related classes) by measuring extensibility, dependency, and responsibility of&#xD;
    each package.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>