Product Metrics for Software

• Software engineers use product metrics to help them assess the quality of the design and construction of the software product being built.
  • first, derive software measures and metrics that are appropriate for the software representation under consideration
  • data are collected
  • metrics are computed
  • metrics are compared to pre-established guidelines and historical data
  • results of comparisons are used to guide modifications made to work products arising from analysis, design, coding, or testing
    
    
• Software Quality Principles - a Qualitative View
  1. Conformance to software requirements is the foundation from which quality is measured.
     
  2. Specified standards define a set of development criteria that guide the manner in which software is engineered.
     
  3. Software quality is suspect when a software product conforms to its explicitly stated requirements and fails to conform to the customer's implicit requirements (e.g., ease of use).
     
     
     
     
  • ISO 9126 Quality Factors
    • Functionality
      
    • Reliability
      
    • Usability
      
    • Efficiency
      
    • Maintainability
      
    • Portability
      
      
• Product Metrics
  • Benefits of Product Metrics
    1. Assist in the evaluation of the analysis and design models
    2. Provide indication of procedural design complexity and source code complexity
       
    3. Facilitate design of more effective testing
       
       
  • Measurement Process Activities
    
    
    
    
  • Measurement Principles
    • The objectives of measurement should be established before collecting any data.
      
    • Each product metric should be defined in an unambiguous manner.
      
    • Metrics should be derived based on a theory that is valid for the application domain.
      
    • Metrics should be tailored to accommodate specific products and processes.
      
      
      
      
  • Metrics Characterization and Validation Principles
    • A metric should have desirable mathematical properties
      
    • The value of a metric should increase when positive software traits occur or decrease when undesirable software traits are encountered
      
    • Each metric should be validated empirically in several contexts before it is used to make decisions
      
      
  • Measurement Collection and Analysis Principles
    • Automate data collection and analysis whenever possible
      
    • Use valid statistical techniques to establish relationships between internal product attributes and external quality characteristics
      
    • Establish interpretive guidelines and recommendations for each metric
      
      
  • Goal-Oriented Software Measurement (GQM)
    
    
    
    
  • Attributes of Effective Software Metrics
    
    
    
    
  • Important Metrics Areas
    • Analysis Model Aspects
      • Functionality delivered
        
      • System size
        
      • Specification quality
    • Design Model Attributes
      • Architecture metrics
        
      • Component-level metrics
        
      • Specialized OO Design Metrics
        
    • Source Code Characteristics
      
      • Halstead metrics
        
      • Complexity metrics
        
      • Length metrics
        
    • Testing
      
      • Statement and branch coverage metrics
        
      • Defect-related metrics
        
      • Testing effectiveness
        
      • In-process metrics
        
        
  • Representative Analysis Metrics
    
    
    |
    • Function-based metrics
      
      
      
      
      
      
  • Representative Design Metrics
    
    
    • Architectural design metrics
      
      • Structural complexity (based on module fanout)
        
      • Data complexity (based on module interface inputs and outputs)
        
      • System complexity (sum of structural and data complexity)
        
      • Morphology (number of nodes and arcs in program graph)
        
        
        
        
      • Design structure quality index (DSQI)
        • a formula involving derived measures based on:
          
          
          
          
    • Object-Oriented design metrics
      
      
      • characteristics of object-oriented designs that lead to specialized design metrics
        
        
        
        
      • categories of object-oriented design metrics
        
        
        
      • Class-Oriented Metrics
        
        
        • Chidamber and Kemerer - CK Metrics Suite
          
          
          
          
        • Harrison, Counsel, and Nithi (MOOD) Metrics Suite
          
          • method inheritance factor (MIF)
            
          • coupling factor (CF)
            
          • polymorphism factor (PF)
            
            
        • Lorenz and Kidd
          
          • class size (CS)
            
          • number of operations overridden by a subclass (NOO)
            
          • number of operations added by a subclass (NOA)
            
          • specialization index (SI)
            
            
      • Component-level design metrics
        
        
        
        
      • Operation-Oriented Metrics
        
        
        
        
      • Interface design metrics
        • a function of layout entities
        • the geographic position
        • the “cost” of making transitions among entities
          
          
  • Source Code Metrics
    
    
    • Halstead's Metrics (lots of controversy here)
      • Overall program length
        
      • Potential minimum algorithm volume
        
      • Actual algorithm volume (number of bits used to specify program)
        
      • Program level (software complexity)
        
      • Language level (constant for given language)
        
        
  • Testing Metrics
    
    
    • Metrics that predict the likely number of tests required during various testing phases
      
      • Function-based metrics (e.g., function points)
        
      • Architectural design metrics
        
      • Cyclomatic complexity can target modules that are candidates for extensive unit testing
        
      • Halstead effort
        
        
    • Metrics that focus on test coverage for a given component
      
      • Cyclomatic complexity lies at the core of basis path testing
        
        
    • Object-Oriented Testing Metrics
      
      
      • provide indication of the testability of an OO system
        • Encapsulation
          • Lack of cohesion in methods (LCOM)
            
          • Percent public and protected (PAP)
            
          • Public access to data members (PAD)
            
        • Inheritance
          
          • Number of root classes (NOR)
            
          • Fan in (FIN)
            
          • Number of children (NOC)
            
          • Depth of inheritance tree (DIT)
            
        • Class complexity
          
          • Weighted metrics per class (WMC)
            
          • Coupling between object classes (CBO)
            
          • Response for a class (RFC)
            
            
  • Maintenance Metrics
    
    
    • Software Maturity Index (IEEE Standard 982.1-1988)
      
    • SMI approaches 1.0 as product begins to stabilize

Notes and figures from:

• Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005