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