1. SWEN 5430 Software Metrics Slide 1 Quality Management u Managing the quality of the software process and products using Software Metrics

2. SWEN 5430 Software Metrics Slide 2 Objectives u To explain how software metrics may be used in quality management

3. SWEN 5430 Software Metrics Slide 3 Topics covered u Software metrics u Product quality metrics

4. SWEN 5430 Software Metrics Slide 4 u Any type of measurement which relates to a software system, process or related documentation Lines of code in a program, the Fog index, number of person- days required to develop a component u Allow the software and the software process to be quantified u Measures of the software process or product u Should be captured automatically if possible Software metrics

5. SWEN 5430 Software Metrics Slide 5 Predictor and control metrics

6. SWEN 5430 Software Metrics Slide 6 u A software property can be measured u The relationship exists between what we can measure and what we want to know u This relationship has been formalized and validated u It may be difficult to relate what can be measured to desirable quality attributes Metrics assumptions

7. SWEN 5430 Software Metrics Slide 7 Internal and external attributes

8. SWEN 5430 Software Metrics Slide 8 Data collection u A metrics program should be based on a set of product and process data u Data should be collected immediately (not in retrospect) and, if possible, automatically u Three types of automatic data collection Static product analysis Dynamic product analysis Process data collation

9. SWEN 5430 Software Metrics Slide 9 Automated data collection

10. SWEN 5430 Software Metrics Slide 10 Data accuracy u Don’t collect unnecessary data The questions to be answered should be decided in advance and the required data identified u Tell people why the data is being collected It should not be part of personnel evaluation u Don’t rely on memory Collect data when it is generated not after a project has finished

11. SWEN 5430 Software Metrics Slide 11 Measurement analysis u Not always obvious what data means. Analyzing collected data is very difficult u Professional statisticians should be consulted if available u Data analysis must take local circumstances into account

12. SWEN 5430 Software Metrics Slide 12 u A quality metric should be a predictor of product quality. u Most quality metrics are design quality metrics and are concerned with measuring the coupling or the complexity of a design. u The relationship between these metrics and quality as judged by a human may hold in some cases but it is not clear whether or not it is generally true. Product quality metrics

13. SWEN 5430 Software Metrics Slide 13 Product measurement process

14. SWEN 5430 Software Metrics Slide 14 Design maintainability u Cohesion How closely are the parts of a component related u Coupling How independent is a component u Understandability How easy is it to understand a component’s function u Adaptability How easy is to change a component

15. SWEN 5430 Software Metrics Slide 15 u Associated with Yourdon's 'Structured Design'/ Measures 'fan-in and fan-out' in a structure chart. u High fan-in (number of calling functions) suggests high coupling because of module dependencies. u High fan-out (number of calls) suggests high coupling because of control complexity. Coupling metrics

16. SWEN 5430 Software Metrics Slide 16 Structural fan-in and fan-out

17. SWEN 5430 Software Metrics Slide 17 u The approach based on the calls relationship is simplistic because it ignores data dependencies. u Informational fan-in/fan-out takes these into account. Number of local data flows + number of global data structures updated. Data-flow count subsumes calls relation. It includes updated procedure parameters and procedures called from within a module. u Complexity = Length * (Fan-in * Fan-out)2 Length is any measure of program size such as LOC. Henry and Kafura’s modifications

18. SWEN 5430 Software Metrics Slide 18 u Some studies with Unix found that informational fan-in/fan-out allowed complex and potentially fault components to be identified. u Some studies suggest that size and number of branches are as useful in predicting complexity than informational fan-in/fan-out. u Fan-out on its own also seemed to be a better quality predictor. u The whole area is still a research area rather than practically applicable. Validation of quality metrics

19. SWEN 5430 Software Metrics Slide 19 Program quality metrics u Design metrics also applicable to programs u Other metrics include Length. The size of the program source code Cyclomatic complexity. The complexity of program control Length of identifiers Depth of conditional nesting u Anomalous metric values suggest a component may contain an above average number of defects or may be difficult to understand

20. SWEN 5430 Software Metrics Slide 20 Metric utility u Length of code is simple but experiments have suggested it is a good predictor of problems u Cyclomatic complexity can be misleading u Long names should increase program understandability u Deeply nested conditionals are hard to understand. May be a contributor to an understandability index

21. SWEN 5430 Software Metrics Slide 21 u Cyclomatic complexity is a measure of control structure complexity u Metric has two drawbacks It is inaccurate for data-driven programs as it is only concerned with control constructs. It places the same weight on nested and non-nested loops. Deeply nested structures, however, are usually harder to understand. u Oviedo's metric modifies this to take data references into account C = aE +bN Complexity metrics

22. SWEN 5430 Software Metrics Slide 22 Documentation quality metrics u Readability of documentation is important u Gunnings Fog index is a simple measure of readability Based on length of sentences and number of syllables in a word u However, this can be misleading when applied to technical documentation

23. SWEN 5430 Software Metrics Slide 23 u Metrics still have a limited value and are not widely collected u Relationships between what we can measure and what we want to know are not well- understood u Lack of commonality across software process between organizations makes universal metrics difficult to develop Metrics maturity

24. SWEN 5430 Software Metrics Slide 24 Key points u Metrics gather information about both process and product u Control metrics provide management information about the software project. Predictor metrics allow product attributes to be estimated u Quality metrics should be used to identify potentially problematical components