1 / 71

Software Metrics

Software Metrics. Presented By Dr. Iyad Alazzam Department of Computer Information Systems Faculty of Information Technology and Computer Science Yarmouk University. A Quote on Measurement. “When you can measure what you are speaking about and express it in

windle
Download Presentation

Software 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. Software Metrics Presented By Dr. Iyad Alazzam Department of Computer Information Systems Faculty of Information Technology and Computer Science Yarmouk University

  2. A Quote on Measurement “When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science.” LORD WILLIAM KELVIN (1824 – 1907)

  3. Software Quality Metrics “If you can’t measure it, you can’t manage it” Tom DeMarco, 1982

  4. Metrics Express in Numbers Measurement provides a mechanism for objective evaluation

  5. Uses of Measurement • Can be applied to the software process with the intent of improving it on a continuous basis • Can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control • Can be used to help assess the quality of software work products and to assist in tactical decision making as a project proceeds

  6. Reasons to Measure • To characterize in order to • Gain an understanding of processes, products, resources, and environments • Establish baselines for comparisons with future assessments • To evaluate in order to • Determine status with respect to plans • To predict in order to • Gain understanding of relationships among processes and products • Build models of these relationships • To improve in order to • Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance

  7. Metrics of Project Management • Budget • Schedule/ReResource Management • Risk Management • Project goals met or exceeded • Customer satisfaction

  8. Metrics of the Software Product • Focus on Deliverable Quality • Analysis Products • Design Product Complexity – algorithmic, architectural, data flow • Code Products • Production System

  9. goal of metrics • to improve product quality and development-team productivity • concerned with productivity and quality measures • measures of SW development output as function of effort and time • measures of usability

  10. Definitions • Measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. • E.g., Number of errors • Metric - quantitative measure of degree to which a system, component or process possesses a given attribute. “A handle or guess about a given attribute.” • E.g., Number of errors found per person hours expended

  11. Why Measure Software? • Determine the quality of the current product or process • Predict qualities of a product/process • Improve quality of a product/process

  12. Motivation for Metrics • Estimate the cost & schedule of future projects • Evaluate the productivity impacts of new tools and techniques • Establish productivity trends over time • Improve software quality • Forecast future staffing needs • Anticipate and reduce future maintenance needs

  13. CK Metrics: Objective CK metrics were designed : • To measureunique aspects of the OO approach. • To measure complexityof the design. • To improve thedevelopment of the software

  14. CK Metrics: ObjectiveSW development Improvement Managers can improve the development of the SWby : • Analysing CKmetrics through the identification of outlying values (extreme deviations), which may be a signal of: • high complexity and/or • possible design violations • Taking managerial decisions, such as: Re-designing and/or assigning extra or higher skilled resources (to develop, to test and to maintain the SW).

  15. CK Metrics: DefinitionWMC (Weighted Methods per Class) • Definition • WMC is the sum of the complexity of the methods of a class. • WMC = Number of Methods (NOM), when all method’s complexity are considered UNITY. • Viewpoints • WMC is a predictor of how much TIME andEFFORT is required to develop and tomaintain the class. • The larger NOM the greater the impact on children. • Classes with large NOM are likely to be more application specific, limiting the possibility of RE-USEand making theEFFORTexpended one-shot investment. • Objective: Low

  16. CK Metrics: DefinitionDIT (Depth of Inheritance Tree) • Definition The maximum length from the node to the root of the tree • Viewpoints The greater values of DIT : • The greater the NOM it is likely to inherit, making more COMPLEXto predict its behaviour • The greater the potential RE-USE of inherited methods • Small values of DIT in most of the system’s classes may be an indicator that designers are forsaking RE-USABILITY for simplicity of UNDERSTANDING. • Objective: Trade-off

  17. CK Metrics: DefinitionNOC (Number of Children) • Definition Number of immediate subclasses subordinated to a class in the class hierarchy • Viewpoints The greater the NOC is: • the greater is theRE-USE • the greater is the probability of improper abstractionof the parent class, • the greater the requirements of method's TESTING in that class. • Small values of NOC, may be an indicator of lack of communication between different class designers. • Objective: Trade-off

  18. CK Metrics: DefinitionCBO (Coupling Between Objects) • Definition It is a count of the number of other classes to which it is coupled • Viewpoints Small values of CBO : • Improve MODULARITY and promote ENCAPSULATION • Indicates independence in the class, making easier its RE-USE • Makes easier to MAINTAIN and to TEST a class. • Objective: Low

  19. CK Metrics: DefinitionRFC (Response for Class) • Definition It is the number of methods of the class plus the number of methods called by any of those methods. • Viewpoints If a large numbers of methods are invoked from a class (RFC is high): • TESTING and MAINTANACE of the Class becomes more COMPLEX. • Objective:Low

  20. CK Metrics: DefinitionLCOM (Lack of Cohesion of Methods) • Definition Measures the dissimilarity of methods in a class via instanced variables. • Viewpoints Great values of LCOM: • Increases COMPLEXITY • Does not promotes ENCAPSULATION and implies classes should probably be split into two or more subclasses • Helps to identified low-quality design • Objective: Low

  21. CK Metrics: Guidelines

  22. CK Metrics: Thresholds Thresholds of the CK metrics [2,3,4]: • Can not be determined before their use • Should be derived and use locally for each dataset • 80th and 20th percentiles of the distributions can be used to determine high and low values of the metrics. • Are not indicators of “badness” but indicators of difference that needs to be investigated.

  23. CK in the LiteratureCK Metrics & other Managerial performance indicators Chidamber & Kemerer study the relation of CK metrics with : • Productivity SIZE [LOC] / EFFORT of Development [Hours] • Rework Effort for re-using classes • Effort to specify high-level design of classes

  24. CK in the LiteratureCK Metrics & Maintenance effort Li and Henry (1993) use CK metrics (among others) to predict : • Maintenance effort, which is measured by the number of lines that have changed in a class during 3 years that they have collected the measurement .

  25. CK in the LiteratureDIT & Maintenance effort Daly et al. (1996) in his study concludes that: • That subjects maintaining OO SW with three levels of inheritance depth performed maintenance tasks significantly quicker than those maintaining an equivalent OO SW with no inheritance.

  26. CK in the LiteratureDIT & Maintenance effort However, Hand Harrisson (2000) used DIT metric to demonstrate : • That systems without inheritance are easier to understand and modify than systems with 3 or 5 levels of inheritance.

  27. CK in the LiteratureDIT & Maintenance effort Poels (2001) uses DIT metric, and demonstrate : • The extensive use of inheritance leads to modules that are more difficult to modify.

  28. CK in the LiteratureDIT & Maintenance effort Prechelt (2003) concludes that : • Programs with less inheritance were faster to maintain and • The code maintenance effort is hardly correlated with inheritance depth but rather depends on other factors such as number of relevant methods.

  29. CK in the LiteratureCK Metrics & Fault-proneness prediction CK : Chidamber & Kemerer, QMOOD: Quality Metrics for Object Oriented Design

  30. Product Metrics Landscape • Metrics for the analysis model • Metrics for the design model • Metrics for the source code • Metrics for testing

  31. Metrics for Requirements Quality • E.g., let nr = nf + nnf , where • nr = number of requirements • nf = number of functional requirements • nnf = number of nonfunctional requirements • Specificity (lack of ambiguity) • Q = nui/nr • nui - number of requirements for which all reviewers had identical interpretations

  32. High-Level Design Metrics • Structural Complexity • S(i) = f2out(i) • fout(i) = fan-out of module i • Data Complexity • D(i) = v(i)/[fout(i) +1] • v(i) = # of input and output variables to and from module i • System Complexity • C(i) = S(i) + D(i) Fan-out(i) is the number of modules called by the module i.

  33. High-Level Design Metrics • Morphology Metrics • size = n + a • n = number of modules • a = number of arcs (lines of control) • arc-to-node ratio, r = a/n • depth = longest path from the root to a leaf • width = maximum number of nodes at any level

  34. a b c d e g k f i j l p q h m n r Morphology Metrics size: 17 + 17 depth:4 width:6 arc-to node ratio:1

  35. Component-Level Design Metrics • Cohesion Metrics • Coupling Metrics • data and control flow coupling • global coupling • environmental coupling • Complexity Metrics • Cyclomatic complexity • Experience shows that if this > 10, it is very difficult to test

  36. Coupling Metrics • Data and control flow coupling • di = number of input data parameters • ci = number of input control parameters • d0 = number of output data parameters • c0 = number of output control parameters • Global coupling • gd = number of global variables used as data • gc = number of global variables used as control • Environmental coupling • w = number of modules called (fan-out) • r = number of modules calling the module under consideration (fan-in) • Module Coupling: mc = 1/ (di + 2*ci + d0 + 2*c0 + gd + 2*gc + w + r)

  37. Metrics for Source Code • Maurice HALSTEAD’s Software Science • n1 = the number of distinct operators • n2 = the number of distinct operands • N1 = the total number of operator occurrences • N2 = the total number of operand occurrences Length: N = N1 + N2 Volume: V = Nlog2(n1 + n2)

  38. Metrics for Maintenance • Software Maturity Index (SMI) • MT= number of modules in the current release • Fc= number of modules in the current release that have been changed • Fa= number of modules in the current release that have been added • Fd= number of modules from the preceding release that were deleted in the current release SMI = [MT - (Fc + Fa + Fd)] / MT

  39. Process Metrics • Average find-fix cycle time • Number of person-hours per inspection • Number of person-hours per KLOC • Average number of defects found per inspection • Number of defects found during inspections in each defect category • Average amount of rework time • Percentage of modules that were inspected

  40. Testing Metrics

  41. Defect Category • An attribute of the defect in relation to the quality attributes of the product. Quality attributes of a product include functionality, usability, documentation, performance, installation, stability, compatibility, internationalization etc. • This metric can provide insight into the different quality attributes of the product. • This metric can be computed by dividing the defects that belong to a particular category by the total number of defects.

  42. Defect Removal Efficiency • The number of defects that are removed per time unit (hours/days/weeks). • Indicates the efficiency of defect removal methods, as well as indirect measurement of the quality of the product. • Computed by dividing the effort required for defect detection, defect resolution time and retesting time by the number of defects. This is calculated per test type, during and across test phases.

  43. Defect Severity • The severity level of a defect indicates the potential business impact for the end user (business impact = effect on the end user x frequency of occurrence). • Provides indications about the quality of the product under test. High-severity defects mean low product quality, and vice versa. At the end of this phase, this information is useful to make the release decision based on the number of defects and their severity levels. • Every defect has severity levels attached to it. Broadly, these are Critical, Serious, Medium and Low.

  44. Defect Severity Index • An index representing the average of the severity of the defects. • Provides a direct measurement of the quality of the product—specifically, reliability, fault tolerance and stability. • Two measures are required to compute the defect severity index. A number is assigned against each severity level: 4 (Critical), 3 (Serious), 2 (Medium), 1 (Low). Multiply each remark by its severity level number and add the totals; divide this by the total number of defects to determine the defect severity index.

  45. Test Case Effectiveness • The extent to which test cases are able to find defects. • This metric provides an indication of the effectiveness of the test cases and the stability of the software. • Ratio of the number of test cases that resulted in logging defects vs. the total number of test cases.

  46. Test Coverage • Defined as the extent to which testing covers the product’s complete functionality. • This metric is an indication of the completeness of the testing. It does not indicate anything about the effectiveness of the testing. This can be used as a criterion to stop testing. • Coverage could be with respect to requirements, functional topic list, business flows, use cases, etc. It can be calculated based on the number of items that were covered vs. the total number of items.

  47. Test Effort Percentage • The effort spent in testing, in relation to the effort spent in the development activities, will give us an indication of the level of investment in testing. This information can also be used to estimate similar projects in the future. • This metric can be computed by dividing the overall test effort by the total project effort.

  48. Time to Fix a Defect • Effort required to resolve a defect (diagnosis and correction). • Provides an indication of the maintainability of the product and can be used to estimate projected maintenance costs. • Divide the number of hours spent on diagnosis and correction by the number of defects resolved during the same period.

  49. Effort Adherence • As % of what is committed in contract. Provides a measure of what was estimated at the beginning of the project vs. the actual effort taken. Useful to understand the variance (if any) and for estimating future similar projects.

  50. Number of Defects • The total number of defects found in a given time period/phase/test type that resulted in software or documentation modifications. Only accepted defects that resulted in modifying the software or the documentation are counted.

More Related