OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/concepts/metrics.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;concepts&amp;#92;&amp;#92;metrics.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: metrics.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0mYYkMlgEdmt3adZL5Dmdw CRC: 3979842427 -->Metrics<!-- END:presentationName,_0mYYkMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw CRC: 366394322 -->A metric is used to interpret measurements so that team members and stakeholders can know the state of the project.<!-- END:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_7ygXoMM3EdmSIPI87WLu3g CRC: 3951303467 --><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 to implement 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">Example 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 metrics
     coverage areas are listed below.
 </p>
 <h4>
     Software quality
 </h4>
 <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>
 <h4>
     Development productivity
 </h4>
 <ul>
     <li>
         Velocity: Number of delivered points by iteration (see <a class="elementLink" href="./../../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Agile Estimation</a>)
     </li>
 </ul>
 <h4>
     Development process effectiveness
 </h4>
 <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>
 <h4>
     Cost and schedule estimate and variance
 </h4>
 <ul>
     <li>
         Effort: Actual effort spent per iteration
     </li>
     <li>
         Cost: Cost per iteration
     </li>
     <li>
         Effort remaining: Track <a class="elementLink" href="./../../../openup/guidances/reports/project_burndown_206E4670.html" guid="_ePrt8Dj3EduxovfWMDsntw">Project Burndown</a>
     </li>
 </ul>
 <p>
     There are many other measures and metrics that may make sense, based on what you are trying to accomplish. As an
     example, to measure the quality of your architecture, you may for example 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><!-- END:mainDescription,_7ygXoMM3EdmSIPI87WLu3g -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;concepts&#92;&#92;metrics.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: metrics.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0mYYkMlgEdmt3adZL5Dmdw CRC: 3979842427 -->Metrics<!-- END:presentationName,_0mYYkMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw CRC: 366394322 -->A metric is used to interpret measurements so that team members and stakeholders can know the state of the project.<!-- END:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_7ygXoMM3EdmSIPI87WLu3g CRC: 3951303467 --><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 the
	team 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 to implement 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".
	</p>
	<h3>
	<font size="5">Example 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 metrics
	coverage areas are listed below.
	</p>
	<h4>
	Software quality
	</h4>
	<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>
	<h4>
	Development productivity
	</h4>
	<ul>
	<li>
	Velocity: Number of delivered points by iteration (see <a class="elementLink" href="./../../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Agile Estimation</a>)
	</li>
	</ul>
	<h4>
	Development process effectiveness
	</h4>
	<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>
	<h4>
	Cost and schedule estimate and variance
	</h4>
	<ul>
	<li>
	Effort: Actual effort spent per iteration
	</li>
	<li>
	Cost: Cost per iteration
	</li>
	<li>
	Effort remaining: Track <a class="elementLink" href="./../../../openup/guidances/reports/project_burndown_206E4670.html" guid="_ePrt8Dj3EduxovfWMDsntw">Project Burndown</a>
	</li>
	</ul>
	<p>
	There are many other measures and metrics that may make sense, based on what you are trying to accomplish. As an
	example, to measure the quality of your architecture, you may for example 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><!-- END:mainDescription,_7ygXoMM3EdmSIPI87WLu3g -->
	</body>
	</html>