Process & Project Metrics

• quantitative measures
  • give software engineers insight into the efficacy of
    • the software process, and
    • the projects conducted using the process
  • measuring allows the organization & team to
    • characterize
    • evaluate
    • predict
    • improve
  • quantitative measures are objective rather than subjective
  • the same measures & metrics may serve two purposes
    • organizational process improvement happens over a long period of time
    • project management is largely concerned with productivity and quality metrics
      
      

• terminology
• measure - provides a quantitative indication of the size of some product or process attribute
• measurement - is the act of obtaining a measure
• metric - is a quantitative measure of the degree to which a system, component, or process possesses a given attribute
• error - a mistake found and corrected before release
• defect - a mistake found by the user after release
  

• process indicators

• data should be collected so that process and product indicators can be ascertained
  
  
  
  
• over a long period of time we can use these metrics to improve the process
  
  
• process metrics
  • private process metrics (e.g. defect rates by individual or module) are only known to by the individual or team concerned
  • public process metrics (aggregation of private process metrics) enable organizations to make strategic changes to improve the software process
    
    
    
    
    
    
  • statistical software process improvement helps an organization to discover where they are strong and where they are weak
    
    
    
    
  • statistical process control
    1. errors are categorized by their origin
    2. record cost to correct each error and defect
    3. count number of errors and defects in each category
    4. overall cost of errors and defects computed for each category
    5. identify category with greatest cost to organization
    6. develop plans to eliminate the most costly class of errors and defects or at least reduce their frequency
       
       
• project metrics
  • the team can use software project metrics to
    • adapt project workflow and technical activities
    • avoid development schedule delays
    • mitigate potential risks
    • assess product quality on an ongoing basis
      
      
      
      
      
      
      
      
      
• software measurement
  • direct measures of a software engineering process include cost and effort
  • direct measures of the product include lines of code (LOC), execution speed, memory size, defects reported over some time period
  • indirect product measures examine the quality of the software product itself (e.g., functionality, complexity, efficiency, reliability, maintainability)
    
    
  • size-oriented metrics
    • derived by normalizing (dividing) any direct measure (e.g., defects or human effort) associated with the product or project by LOC
    • size-oriented metrics are widely used but their validity and applicability is a matter of some debate
    • other size related metrics may also be of interest
      
      
      
      
  • function-oriented metrics
    • function points are computed from direct measures of the information domain of a business software application and assessment of its complexity
    • function points are used like LOC to normalize measures
    • the relationship of LOC and function points depends on the language used to implement the software
      
      
      
      
  • object-oriented metrics

    

  • software quality metrics
    • factors assessing software quality come from various points of view
    • software quality factors we might measure include
      
      
      
      
    • defect removal efficiency (DRE) - a measure of the filtering ability of the quality assurance and control activities as they are applied throughout the process framework
      
      
      
      
    • examples of measures related to maintainability
      
      
      
      
• integrating metrics with software process
  • many software developers do not collect measures
  • without measurement it is impossible to determine whether a process is improving or not
  • baseline metrics data should be collected from a large, representative sampling of past software projects
  • getting this historic project data is very difficult, if the previous developers did not collect data in an ongoing manner
  • it has been estimated that up to three years are required before useful process indicators are available
    
    
• metrics for small organizations
  • most software organizations have fewer than 20 software engineers
  • choose simple metrics that provide value to the organization and don't require a lot of effort to collect
  • even small groups can expect a significant return on the investment required to collect metrics, if this activity leads to process improvement
    

Notes and figures from:

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