Run Charts

Run charts are also frequently used for software project management; numerous reallife examples can be found in books and journals on software engineering. For example, the weekly arrival of defects and defect backlog during the formal machine testing phases can be monitored via run charts. These charts serve as real-time statements of quality as well as workload. Often these run charts are compared to the historical data or a projection model so that the interpretation can be placed into proper perspective. Another example is tracking the percentage of software fixes that exceed the fix response time criteria. The goal is to ensure timely deliveries of fixes to customers.

Figure 5.7 shows a run chart for the weekly percentage of delinquent open reports of field defects (defect reports that were not yet closed with fixes by the response time criteria) of an IBM Rochester product. The horizontal line (denoted by the letter T ) is the target delinquency rate. The dashed vertical line denotes the time when special remedial actions were rolled out to combat the high delinquency rate. For each delinquent defect report, causal analysis was done and corresponding actions implemented. A sample of the cause categories and the actions implemented are shown in Figure 5.8. As a result, the delinquent-defect report rate was brought down to target in about one month. The rate fluctuated around the target for about four months and eventually was brought under control. (The acronym APAR in Figure 5.8 stands for Authorized Programming Analysis Report, which refers to reports of postrelease problem.)

Figure 5.7. Run Chart of Percentage of Delinquent Fixes


Figure 5.8. Causes of and Actions to Reduce Delinquent Fixes


Another type of run chart used by many software development organizations for project and schedule management is the S curve, which tracks the cumulative progress of the parameter of interest over time compared to the plan. At IBM Rochester, parameters that are tracked for every project in terms of actual versus planned include:

  • Completion of design review over time
  • Completion of code inspection over time
  • Completion of code integration over time
  • Completion of component test in terms of number of test cases attempted and successful over time
  • Completion of system test in terms of number of test cases attempted and successful over time
  • Other parameters related to project and quality management

What Is Software Quality?

Software Development Process Models

Fundamentals of Measurement Theory

Software Quality Metrics Overview

Applying the Seven Basic Quality Tools in Software Development

Defect Removal Effectiveness

The Rayleigh Model

Exponential Distribution and Reliability Growth Models

Quality Management Models

In-Process Metrics for Software Testing

Complexity Metrics and Models

Metrics and Lessons Learned for Object-Oriented Projects

Availability Metrics

Measuring and Analyzing Customer Satisfaction

Conducting In-Process Quality Assessments

Conducting Software Project Assessments

Dos and Donts of Software Process Improvement

Using Function Point Metrics to Measure Software Process Improvements

Concluding Remarks

A Project Assessment Questionnaire

Metrics and Models in Software Quality Engineering
Metrics and Models in Software Quality Engineering (2nd Edition)
ISBN: 0201729156
EAN: 2147483647
Year: 2001
Pages: 176 © 2008-2020.
If you may any questions please contact us: