1. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 1 Software Process and Project Metrics zOutline: yIn the Software Metrics Domain: xproduct metrics xproject metrics xprocess metrics ySoftware Measurement xsize-oriented metrics xfunction-oriented metrics yMetrics for Software Quality

2. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 2 Measure, Metrics, and Indicator zMeasure -- Provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some product or process attribute. zMetrics -- A quantitative measure of the degree to which a system, component, or process possesses a given attribute. zSoftware Metrics -- refers to a broad range of measurements for computer software. zIndicator -- a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.

3. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 3 In the Process and Project Domains zProcess Indicator yenable insight into the efficacy of an existing process yto assess the current work status yGoal -- to lead to long-term software process improvement zProject Indicator yassess the status of an ongoing project ytrack potential risks yuncover problem areas before they “go critical” yevaluate the project team’s ability to control the product quality

4. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 4 Process Metrics and Software Process Improvement Customer characteristics People Project Business conditions Technology Process Development environment

5. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 5 Measurement zWhat to measure? yerrors uncovered before release ydefects delivered to and reported by end users ywork products delivered yhuman effort expended ycalendar time expended yschedule conformance zAt what level of aggregation? yBy team? yIndividual? yProject?

6. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 6 Privacy Issues zShould they be used for personnel evaluation? zSome issues? yPrivacy? y Is total assignment being measured? yAre the items being measured the same as for other individuals being measured? yAre the conditions of measurement the same across individuals? zHowever, they can be useful for individual improvement.

7. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 7 Use of Software Metrics zUse common sense and organizational sensitivity. zProvide regular feedback to individuals and teams. zDon’t use metrics to appraise individuals. zSet clear goal and metrics. zNever use metrics to threaten individuals or teams zProblems != negative. These data are merely an indicator for process improvement. zDon’t obsess on a single metric to the exclusion of other important metrics. zDo not rely on metrics to solve your problems. zBeware of people performing to metrics rather than product quality or safety.

8. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 8 Typical Causes of Product Defects

9. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 9 Example of Defect Analysis missing ambiguous wrong customer queried customer gave wrong infor. inadequate inquiries used outdated information changes incorrect specification defects

10. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 10 Project Metrics zSoftware Project Measures Are Tactical yused by a project manager and a software team yto adapt project work flow and technical activities zThe Intent of Project Metrics Is Twofold yto minimize the development schedule to avoid delays and mitigate potential problems and risks yto assess project quality on an ongoing basis and modify the technical approach to improvement quality zProduction Rates ypages of documentation yreview hours yfunction points ydelivered source lines yerrors uncovered during SW engineering

11. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 11 Software Metrics zDirect measures yCost and effort applied (in SEing process) yLines of code(LOC) produced yExecution speed yCPU utilization yMemory size yDefects reported over certain period of time zIndirect Measures yFunctionality, quality, complexity, efficiency, reliability, maintainability.

12. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 12 Software Measurement zSize-Oriented Metrics yare derived by normalizing quality and/or productivity measures by considering the “size” of the software that has been produced. ylines of code often as normalization value. projectLOCeffort$(000)pp.docerrorsdefectspeople alpha 12,100 24 168 365 134 29 3 beta 27,200 62 440 1224 321 86 5 gamma 20,200 43 314 1050 256 64 6......

13. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 13 Typical Size-Oriented Metrics zErrors per KLOC zDefects per KLOC zDollars per KLOC zPages of documentation per KLOC zErrors per person month zLOC per person month zDollars per page of documentation

14. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 14 Software Measurement zFunction-Oriented Metrics yuse “functionality” to measure yderived from “function point” yusing an empirical relationship ybased on countable (direct) measure of SW information domain and assessments of software complexity zUse of Function-Oriented Metrics yMeasuring scale of a project yNormalizing other metrics, e.g., $/FP, errors/FP

15. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 15 Function Point Calculation Weighting Factor measurement parametercountsimpleaveragecomplex number of user outputs*457= # of user inquiries * 3 4 6 = number of files * 7 10 15 = # of external interfaces*57 10= count_total number of user inputs*346=

16. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 16 Function Point Calculation Computing function points Rate each factor on a scale of 0 to 5 no influence incidental moderate average significant essential 12 3 456 1. does the system require reliable backup and recovery? 2. are data communications required? 3. are there distributed processing functions? 4. is performance critical?........ 14. is the application designed to facilitate change and ease of use by the user?

17. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 17 Function-Oriented Metrics FP = count_total * [0.65 + 0.01 * sum of F i ] Outcome: errors per FP defects per FP $ per FP page of documentation per FP FP per person_month

18. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 18 Function Point Extensions zFunction Points emphasizes “data dimension” zTransformations added to capture “functional dimension” zTransitions added to capture “control dimension”

19. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 19 3-D Function Point Calculation

20. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 20 Reconciling Different Metrics

21. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 21 Metrics for Software Productivity zLOC and FP Measures Are Often Used to Derive Productivity Metrics z5 Important Factors That Influence SW Productivity ypeople factors yproblem factors yprocess factors yproduct factors yresource factors

22. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 22 Measures of Software Quality zCorrectness yis the degree to which the software performs its required function. the most common measure for correctness is defects per KLOC zMaintainability ythe ease that a program can be corrected yadapted if the environment changes yenhanced if the customer desires changes in requirements ybased on the time-oriented measure mean time to change.

23. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 23 Measures of Software Quality (Cont’d) zIntegrity yto measure a system’s ability to withstand attacks (both accidental and intentional) on its security threat and security are defined yintegrity = sum [ 1 - threat * (1- security)] zUsability - an attempt to quantify “user friendliness” yphysical/intellectual requirement to learn ytime required to become moderately efficient ythe net increase in productivity yuser attitudes toward system

24. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 24 Defect Removal Efficiency zA Quality Metric That Provides Benefit at Both the Project and Process Level z DRE = E / ( E + D ) E = # of errors found before delivery of the software to the end user D = # of defects found after delivery zMore generally, DRE i = E i / ( E i + E i+1 ) E i = # of errors found during SE activity i

25. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 25 Summary View

26. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 26 Summary zMetrics are a tool which can be used to improve the productivity and quality of the software system zProcess metrics takes a strategic view to the effectiveness of a software process zProject metrics are tactical that focus on project work flow and technical approach zSize-oriented metrics use the line of code as a normalizing factor zFunction-oriented metrics use function points zFour quality metrics------correctness, integrity, maintainability, and usability were discussed

27. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 27 METRICS zCLCS Metrics Philosophy Phase 1: Provide a mandatory, nearly automated, metrics foundation to track lines of code and errors. Phase 2: Provide additional high-return metrics with recognized value. xSchedule metrics (milestones) xAdditional S/W Problem metrics (actuals, trends, prediction) xDefect correction metrics xRun-time analysis metrics (McCabe tools, automated, COTS) Phase 3: Be driven to additional metrics only by absolute need.

28. Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 1997 28 METRICS