CSC 423 Chapter 25, Fall 2011

1 Chapter 25  Process and Project Metrics 2 A Good Manager Measures process process measurement measurement What do we What do we use as a use as a basis? basis? • • size? size? • • function? function? project metrics project metrics process metrics process metrics product product product metrics product metrics 3 Why Do We Measure?  assess the status of an ongoing project  track potential risks  uncover problem areas before they go “critical,”  adjust work flow or tasks,  evaluate the project team’s ability to control quality of software work products. 4 Process Measurement  We measure the efficacy of a software process indirectly.  That is, we derive a set of metrics based on the outcomes that can be derived from the process.  Outcomes include • measures of errors uncovered before release of the software • defects delivered to and reported by end-users • work products delivered (productivity) • human effort expended • calendar time expended • schedule conformance • other measures.  We also derive process metrics by measuring the characteristics of specific software engineering tasks. 5 Process Metrics Guidelines  Use common sense and organizational sensitivity when interpreting metrics data.  Provide regular feedback to the individuals and teams who collect measures and metrics.  Don’t use metrics to appraise individuals.  Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.  Never use metrics to threaten individuals or teams.  Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.  Don’t obsess on a single metric to the exclusion of other important metrics. 6 Software Process Improvement SPI Process model Improvement goals Process metrics Process improvement recommendations 7 Project Metrics  used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks  used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.  every project should measure:  inputs—measures of the resources (e.g., people, tools) required to do the work.  outputs—measures of the deliverables or work products created during the software engineering process.  results—measures that indicate the effectiveness of the deliverables. 8 Typical Project Metrics  Effort/time per software engineering task  Errors uncovered per review hour  Scheduled vs. actual milestone dates  Changes (number) and their characteristics  Distribution of effort on software engineering tasks 9 Typical Size-Oriented Metrics  errors per KLOC (thousand lines of code)  defects per KLOC  $ per LOC  pages of documentation per KLOC  errors per person-month  errors per review hour  LOC per person-month  $ per page of documentation 10 Object-Oriented Metrics  Number of scenario scripts (use-cases)  Number of support classes (required to implement the system but are not immediately related to the problem domain)  Average number of support classes per key class (analysis class)  Number of subsystems (an aggregation of classes that support a function that is visible to the end-user of a system) 11 WebApp Project Metrics  Number of static Web pages (the end-user has no control over the content displayed on the page)  Number of dynamic Web pages (end-user actions result in customized content displayed on the page)  Number of internal page links (internal page links are pointers that provide a hyperlink to some other Web page within the WebApp)  Number of persistent data objects  Number of external systems interfaced  Number of static content objects  Number of dynamic content objects  Number of executable functions  Customization index, c= #of dynamic pages/(#of dynamic pages+#of static pages) 12 Measuring Quality  Correctness — the degree to which a program operates according to specification  Maintainability—the degree to which a program is amenable to change  Integrity—the degree to which a program is impervious to outside attack  Usability—the degree to which a program is easy to use  Integrity=∑(1-(threat*(1-security)) 13 Defect Removal Efficiency where: E is the number of errors found before delivery of the software to the end-user D is the number of defects found after delivery. DRE = E /(E + D) 14 Metrics for Small Organizations  time (hours or days) elapsed from the time a request is made until evaluation is complete, tqueue.  effort (person-hours) to perform the evaluation, Weval.  time (hours or days) elapsed from completion of evaluation to assignment of change order to personnel, teval.  effort (person-hours) required to make the change, Wchange.  time required (hours or days) to make the change, tchange.  errors uncovered during work to make change, Echange.  defects uncovered after change is released to the customer base, Dchange. 15 Establishing a Metrics Program  Identify your business goals.  Identify what you want to know or learn.  Identify your subgoals.  Identify the entities and attributes related to your subgoals.  Formalize your measurement goals.  Identify quantifiable questions and the related indicators that you will use to help you achieve your measurement goals.  Identify the data elements that you will collect to construct the indicators that help answer your questions.  Define the measures to be used, and make these definitions operational.  Identify the actions that you will take to implement the measures.  Prepare a plan for implementing the measures.