Maintenance Metrics ◾ 113
Backlog Index
is index measures the percentage of bugs in the backlog queue and represents an
operational challenge in maintenance projects.
Bug Classification
Classification is categorical data. To understand bugs better, they are classified in
the bug tracker database. Typical fields are origin, cause, trigger, type, and solu-
tion. More can be added; ODC use may be considered. A periodical analysis of bug
distribution among the various classifications is a good revelation of the problem.
Fix Quality
Bug fixes could have problems. Bugs may reopen and cause rework and delay. e
percentage of bug fixes that are performed right the first time can be measured.
Rework can be measured for cost control.
Refactoring Metrics
To improve quality of software and reduce maintenance costs by refactoring, we
measure coupling and cyclamate complexity. Coupling measures the flow of data
between modules. Cyclomatic complexity measures complexity in module structure.
Reliability
Reliability of the product under maintenance can be computed from “failure inten-
sity,” which is the number of bugs reported per month. From this metric, we can
judge whether the product is recovering or crashing. A time series plot of cumula-
tive bugs discovered called reliability growth curve can be used as a visual represen-
tation of reliability. e mean time between failure also can be computed.
Metric-Based Dashboards
We would consider the top seven metrics for constructing a graphical dashboard
for managing software maintenance. e other metric data may be presented in the
form of a tabular record. e choice of metrics for graphical presentation is entirely
up to the maintenance teams. Stark uses the following metrics [6]:
1. Backlog
2. Cycle time
3. Reliability
4. Cost per delivery
114 ◾ Simple Statistical Methods for Software Engineering
5. Cost per activity
6. Number of changes by type
7. Staff days per change
8. Percentage of invalid change requests
9. Complexity assessment
10. Maintainability
11. Computer resource utilization
12. Percentage of content changes by delivery
13. Percentage of OTD
Figure 7.3 shows an example of a dashboard built with seven metrics.
OTD %
Backlog index
Resources available
Time to repair
Customer satisfaction
Resource utilization
SLA compliance
Reporting month:
Predicted
change requests
for next month
Figure 7.3 Maintenance dashboard.
Box 7.4 lehMan’S lawS of Software evolution
e laws of software evolution refer to a series of laws that Lehman and
Belady formulated in 1974:
1. Continuing change—a system must be continually adapted or it
becomes progressively less satisfactory.
2. Increasing complexity—a system evolves as its complexity increases,
unless work is done to maintain or reduce it.
Maintenance Metrics ◾ 115
Review Questions
1. What is the most important metric in adaptive (enhancement) maintenance?
2. What is the most important metric in corrective maintenance?
3. What is the most important metric in perfective maintenance?
4. Which among the previously mentioned three metrics is the toughest to collect?
5. If you were to design a dashboard for a support project and if you were asked
to limit the number of metrics to just seven, which seven would you choose?
Exercises
1. Develop a metrics list for a support project if the adaptive–corrective–perfective
maintenance task ratio is 3:10:2.
2. Develop a metrics list for an exclusive support contract for the perfective
maintenance of software with an express goal of improving maintainability.
References
1. NESMA, Function Point Analysis for Software Maintenance Guidelines, Version 2.2.1,
Professional Guide of the Netherlands Software Metrics Users Association, Netherland
2009.
3. Self-regulation—a system evolution process is self-regulating with dis-
tribution of product and process measures close to normal.
4. Conservation of organizational stability (invariant work rate)—the average
effective global activity rate in a system is invariant over product lifetime.
5. Conservation of familiarity—a system evolves all associated with it;
developers, sales personnel, and users, for example, must maintain
mastery of its content and behavior to achieve satisfactory evolution.
Excessive growth diminishes that mastery. Hence, the average incre-
mental growth remains invariant as the system evolves.
6. Continuing growth—the functional content of a system must be con-
tinually increased to maintain user satisfaction over its lifetime.
7. Declining quality—the quality of a system will appear to be declining
unless it is rigorously maintained and adapted to operational environ-
ment changes.
8. Feedback system evolution processes constitute multilevel, multiloop,
and multiagent feedback systems and must be treated as such to achieve
significant improvement over any reasonable base.
116 ◾ Simple Statistical Methods for Software Engineering
2. NC State University Communication. Available at http://agile.csc.ncsu.edu/SEMaterials
/MaintenanceRefactoring.pdf.
3. C. V. S. R. Syavasya, An approach to find out at which maintainability metric, software
maintenance cost is less, International Journal of Computer Science and Information
Technology, 3(4), 4599–4602, 2012, ISSN:0975–9646.
4. Journal of Software Maintenance and Evolution: Research and Practice, John Wiley &
Sons, Ltd.
5. V. Zeithaml, A. Parasuraman and L. Berry, Delivering Quality Service, Simon and
Schuster, 1990.
6. G. E. Stark, Measurements to Manage Software Maintenance, Technical Note, e
MITRE Corporation, Colorado Springs, CO, July 1979.
Suggested Readings
Aczel, A. D. and J. Sounderpandian, Complete Business Statistics, McGraw-Hill, London,
2008.
Available at http://www.refactoring.com/.
Available at http://wiki.java.net/bin/view/People/SmellsToRefactorings.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.