1 / 22

Metrics

Metrics. Project and Process Metrics. Why do we measure?. Assessing project status Allows us to track risks Before they go critical Adjust workflow See if the team can control the quality of artifacts. Example metric.

cathy
Download Presentation

Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Metrics Project and Process Metrics

  2. Why do we measure? • Assessing project status • Allows us to track risks • Before they go critical • Adjust workflow • See if the team can control the quality of artifacts

  3. Example metric • Can you calculate a metric that records the number of ‘e’ that appear in a program • Should you?

  4. Effective Metrics • Simple and computable • Empirically and intuitively persuasive • Consistent and objective • Consistent in use of units and dimensions • Programming language independent • Should be actionable

  5. Example metric • If I calculate the number of defects per developer and rank them, then using that rank assign salary raises based on that.

  6. Metrics Guidelines • Don’t use a single metric to the exclusion of others • Metrics should not be used to appraise or threaten individuals • Negative metric should be viewed as an opportunity for improvement

  7. Process vs Project Metrics • Process across multiple projects • i.e. Waterfall vs Agile • Quality: correctness, maintainability, usability, integrity • Productivity: earned value analysis • Statistical SQA data: MTTF, MTTR • Defect removal efficiency (later) • Reuse data: percent of components

  8. Defect Removal Efficiency • 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)

  9. DRE Example DRE = E /(E + D) Defects found during phase: Requirements (10) Design (20) Construction Implementation (5) Unit Testing (50) Testing Integration Testing (100) System Testing (250) Acceptance Testing (5) By Customer (10) 10 / (10 + 20) = 33% What are the rest?

  10. 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

  11. LOC is dangerous • A Function Point is an estimate of a unit of utility/productivity • LOC does not generalize across multiple languages

  12. Other problems with LOC • At IBM in the 70s or 80s (I don’t remember) they paid people per line-of-code they wrote

  13. 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)

  14. Questions/Review • What are some reasons NOT to use lines of code to measure size? • What do you expect the DRE rate will be for the implementation (or construction) phase of the software lifecycle? • What about for testing? • Give an example of a usability metric? • According to the chart, Smalltalk is much more efficient than Java and C++. Why don’t we use it for everything?

  15. Code Metrics • Static • Cyclomatic complexity • Readability • etc. • Dynamic • CPU performance • Memory usage • Threading

  16. Cyclomatic Complexity • A software metric used to measure the complexity of software • Developed by Thomas McCabe • Described (informally) as the number of simple decision points + 1

  17. What is cyclomatic complexity? • Essentially the number of linearly independent paths through the code • The code has no decision statements: complexity = 1 • The code has an if statement, there are two paths through the code: complexity = 2 • Used as a basis for path testing

  18. Example • What is the complexity: public void howComplex(inti) { while (i<10) { i++; System.out.printf("i is %d", i); if (i%2 == 0) { System.out.println("even"); } else { System.out.println("odd"); } } }

  19. When do we care? A number of industry studies have indicated that the higher V(G), the higher the probability or errors. modules V(G) modules in this range are more error prone

  20. Tools will automatically calculate • NCSS = Non Commenting Source Statements • CCN = cyclomatic complexity number

More Related