1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 4 Software Process and Project Metrics

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Measurement & Metrics... collecting metrics is too hard... it's too time-consuming... it's too political... it won't prove anything... Anything that you need to quantify can be measured in some way that is superior to not measuring it at all.. Tom Gilb

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why do we Measure?  To characterize  To evaluate  To predict  To improve

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 TERMS  A measure is established when a single data point has been collected (eg. The number of errors uncovered in the review of a single module)  A software metrics relates the individual measures in some way (eg. The average number of errors found per review)  An indicator is a metric or a combination of metrics that provide insight into the software process, project or product. (eg. Formal technical review may provide a higher return) ++

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Process Indicators  Enable a software engineering organization to gain insight into the efficacy of an existing process (ie, the paradigm, tasks, products, milestones)  Enable managers and practitioners to assess what works and what does not ++

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Project Indicators Enable a software project manager to:  Assess the status of an ongoing project  Tract 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 products ++

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 A Good Manager Measures measurement What do we use as a basis? size? size? function? function? project metrics process metrics process product product metrics

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Process Metrics  majority focus on quality achieved as a consequence of a repeatable or managed process  statistical SQA data  error categorization & analysis  defect removal efficiency  propagation from phase to phase  reuse data

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Process Metrics Measuring the outcomes:  Errors  Defects  Productivity  Effort  Time  Schedule conformance Measuring the characteristics of specific task:  Effort and time spent performing the umbrella activities and generic SE activities ++

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Project Metrics  Effort/time per SE task  Errors uncovered per review hour  Scheduled vs. actual milestone dates  Changes (number) and their characteristics  Distribution of effort on SE tasks

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Product Metrics  focus on the quality of deliverables  measures of analysis model  complexity of the design  internal algorithmic complexity  architectural complexity  data flow complexity  code measures (e.g., Halstead)  measures of process effectiveness  e.g., defect removal efficiency

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Metrics Guidelines  Use common sense and organizational sensitivity when interpreting metrics data.  Provide regular feedback to the individuals and teams who have worked to 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.

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Normalization for Metrics

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Typical Size-Oriented Metrics  errors per KLOC (thousand lines of code)  defects per KLOC  $ per LOC  page of documentation per KLOC  errors / person-month  LOC per person-month  $ / page of documentation

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Typical Function-Oriented Metrics  errors per FP (thousand lines of code)  defects per FP  $ per FP  pages of documentation per FP  FP per person-month

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Opt for FP Measures?

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Computing Function Points

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analyzing the Information Domain

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Taking Complexity into Account + Backup and recovery + Reusable

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Defect Removal Efficiency DRE = (errors) / (errors + defects) where errors = problems found before release defects = problems found after release

23. 23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Managing Variation – Why?  Metrics collected for one project or product may not be the same as similar metrics collected for another project  How can we tell if improved (or degraded) metrics values that occur as consequence of improvement activities are having a quantitative impact?  How do we know whether we’re looking at a statistically valid trend or not?  When are changes to a particular software metric meaningful?  A graphical techniques  is available for determining whether changes and variation in metrics data are meaningful  Control chart  enables individuals to determine whether the dispersion (variability) and location (moving average) of process metrics are stable or unstable  Two different types: moving range & individual control charts ++

24. 24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Managing Variation The mR Control Chart

25. 25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Moving range control chart ++ Eg. @ project 1  4.3 – 3.1 = 1.2 Differences in successive Er values Project

26. 26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Individual control chart ++ Std dev Error found/ review hour Project