Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 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.

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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?

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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.

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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.

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

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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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.

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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, beta 27, gamma 20,

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

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

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

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

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

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

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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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.

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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

Chapter 4 -- R. A. Volz -- assistance -- Mingjuan Cui November 2, 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.

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