Chapter_23.pdf

Chapter 23 Software Metrics and Analytics 2 What is software process and project metrics It is quantitative measures that enable you to gain insight into measures. It gives insight into efficacy of the software process And the project that are conducted using the process...

Chapter 23 Software Metrics and Analytics 2 What is software process and project metrics It is quantitative measures that enable you to gain insight into measures. It gives insight into efficacy of the software process And the project that are conducted using the process as framework. 2 3 Measures, Metrics, and Indicators A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of attributes of a product or process. A metric is a quantitative measure of the degree to which a system, component, or process possesses a given attribute. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself. 3 4 Attributes of Effective Metrics Simple and computable. It should be relatively easy to learn how to derive the metric. Empirically and intuitively persuasive. Satisfies the engineer’s intuitive notions about the product attributes. Consistent and objective. The metric should yield results that are unambiguous. (not open for different interpretations) Consistent in its use of units and dimensions. Computation of the metric should not lead to bizarre combinations of units. Programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. Effective mechanism for quality feedback. Should provide a software engineer with information that can lead to a higher quality end-product. 4 5 KPI and Software Analytics Key performance indicators (KPIs) are metrics that are used to track performance and trigger remedial actions when their values fall in a predetermined range. Software analytics is the systematic computational analysis of software engineering data or statistics to provide managers and software engineers with meaningful insights and empower their teams to make better decisions. 5 6 Software analytics can help developers make decisions regarding: Software analytics can help developers make decisions regarding: Targeted testing. Targeted refactoring. Release planning. Understanding customers. Judging stability. Targeting inspection. 6 7 Requirements Model Metrics Requirement specificity (lack of ambiguity): Q1 = nui / nr where nui is the number of requirements for which all reviewers had identical interpretations. Q1 close to 1 is good. Assume there are nr requirements in a specification: nr = nf + nnf nf is the number of functional requirements nnf is the number of nonfunctional requirements 7 8 Mobile Software Requirements Model Metrics Number of static screen displays. (Nsp) Number of dynamic screen displays. (Ndp) Customization index C = Ndp / (Ndp + Nsp) C ranges from 0 to 1 8 9 Morphology Metrics Morphology metrics: a function of the number of modules and the number of interfaces between modules Size = n + a n = number of nodes, a = number of arcs Depth = longest path root to leaf node Width = maximum number if nodes at each level 9 10 Morphology Metrics Access the text alternative for slide images. 10 11 Object-Oriented Design Metrics Weighted methods per class (WMC). The number of methods and their complexity are reasonable indicators of the amount of effort required to implement and test a class. Depth of the inheritance tree (DIT). A deep class hierarchy (DIT is large) leads to greater design complexity. Number of children (NOC). As NOC increases, the amount of testing (required to exercise each child in its operational context) will also increase. 11 12 User Interface Design Metrics Interface metrics. Ergonomics measures (for example, memory load, typing effort, recognition time, layout complexity) Aesthetic (graphic design) metrics. Aesthetic design relies on qualitative judgment but some measures are possible (for example, word count, graphic percentage, page size) Content metrics. Focus on content complexity and on clusters of content objects that are organized into pages Navigation metrics. Address the complexity of the navigational flow and they are applicable only for static Web applications. 12 13 Maintenance Metrics IEEE Std. 982.1-2005 software maturity index (SMI) that provides an indication of the software product stability (based on changes made). MT = number of modules in current release Fc = number of modules in current release that have been changed Fa = number of modules in current release that have been added Fd = number of preceding release modules deleted SMI = [MT − (Fa + Fc + Fd)]/MT As SMI approaches 1.0, the product begins to stabilize. 13 14 Process and Project Metrics Process metrics collected across all projects, over long periods of time. Their intent is to provide a set of indicators that lead to long-term software process improvement Project metrics enable a software project manager to: 1. assess the status of an ongoing project. 2. track potential risks. 3. uncover problem areas before they go “critical.” 4. adjust workflow or tasks. 5. evaluate project team’s ability to control quality of software work products. 14 15 Process Measurement We measure the efficacy of a software process indirectly – 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. 15 16 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. 16 17 Software Measurement Direct measures of the software process include cost and effort applied. Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many others. 17 18 Normalized Size-Oriented Metrics errors per KLOC (thousand lines of code) defects per KLOC R per LOC pages of documentation per KLOC errors per person-month errors per review hour LOC per person-month R per page of documentation 18 19 Why Opt For Function-Oriented Metrics Programming language independent. Used readily countable characteristics that are determined early in the software process. Does not “penalize” inventive (short) implementations that use fewer LO C that other more clumsy versions. Makes it easier to measure the impact of reusable components. 19 20 Defect Removal Efficiency (DRE) DRE is a measure of the filtering ability of quality assurance and control actions as they are applied throughout all process framework activities. DRE = E / (E + D) E = number of errors found before delivery D = number or errors found after delivery The ideal value for DRE is 1. No defects (D = 0) are found by the consumers of a work product after delivery. The value of DRE improves when E increases because the team is catching its own errors before delivering the software. 20