Maintainability Metrics Research Articles

Measuring the maintainability of a communication protocol based on its formal specification

It is difficult to measure the maintainability of a software system early in the development life cycle from its requirement descriptions written in a natural language because informal specifications cannot be analyzed. With the uses of formal description techniques (FDTs) in the communication protocol area since the mid-1980s, avenues have been opened up for a system to be analyzed early in the specification phase. Quantitative measures on its maintainability can then be extracted from such a formal specification, so that we can develop easily maintainable communication software systems and further reduce the increasingly high cost of software maintenance. To date, there is hardly any work done on measuring the maintainability of a system early in its specification phase. This paper presents a method for measuring the maintainability of a communication by using maintainability metrics derived from its formal specification written in Estelle. The methodology for building the Estelle maintainability metrics hierarchy is presented. We have also developed an automated tool, called PSAMS, to automate the calculation of the maintainability indices. We also found that there is a significant correlation between the specification metrics proposed and the widely adopted implementation metrics, thus demonstrating that our proposed metrics are a reliable means of measuring the maintainability of a communication protocol early in the specification phase.

Metrics for maintainability of class inheritance hierarchies

AbstractSince the proposal for the six object‐oriented metrics by Chidamber and Kemerer (1994), several studies have been conducted to validate their metrics and have discovered some deficiencies. Consequently, many new metrics for object‐oriented systems have been proposed. Among the various measurements of object‐oriented characteristics, we focus on the metrics of class inheritance hierarchies in design and maintenance. As such, we propose two simple and heuristic metrics for the class inheritance hierarchy for the maintenance of object‐oriented software.In this paper we investigate the work of Chidamber and Kemerer (1994) and Li (1998), and extend their work to apply specifically to the maintenance of a class inheritance hierarchy. In doing so, we suggest new metrics for understandability and modifiability of a class inheritance hierarchy. The main contribution here includes the various comparisons that we have made. We discuss the advantages over Chidamber and Kemerer's (1994) metrics and Henderson‐Sellers's (1996) metrics in the context of maintaining class inheritance hierarchies. Copyright © 2002 John Wiley & Sons, Ltd.

A comparative case study of three database application development environments

This paper describes an exploratory case study that investigates the claim that the object-oriented approach to information systems development reduces development effort and improves maintainability. Software metrics for development effort, complexity, and maintainability of three functionally similar 4GL database development environments, one objected-oriented and two traditional (relational) are compared. The results indicate that programs developed using the object-oriented environment needed fewer lines of code, had less volume, required less effort, were less complex and were more maintainable than those developed using the traditional 4GL environments.

Development and Application of an Automated Source Code Maintainability Index

When software maintenance results in changing the source code, the change frequently occurs in an undisciplined manner that results in source code that is inherently more difficult to maintain. The long-term effect may be thought of as a downward spiral that culminates in virtually ‘unmaintainable’ code where it is more cost effective to just start again. Too often, software personnel and managers, aware that the code is becoming less maintainable, have been unable to estimate with useful accuracy the degree to which maintainability has diminished. The result is that they either continue to waste time and money maintaining code which is effectively unmaintainable, or they opt to live with what seems to be bad code, not touching it for fear of breaking it. To avoid this state of affairs, software developers need to be able to quanitify both the current level of software maintainability and the impact on it of any given change. This paper discusses the application of software metrics as a tool for quantifying code maintainability and, by extension, for making decisions. The first part of the discussion focuses on deriving a minimal set of easily calculated metrics which, when taken together, can produce a single-valued quantification (or index) of code maintainability. Case studies are then presented which serve to illustrate not only the degree to which software can degrade over time, but how this ‘maintainability index’ (MI) can be used to quantify maintainability and aid decision making. Finally, a methodology for making metric assessments readily available to software personnel is presented so that they can now easily integrate maintainability metrics into maintenance (and development) processes. As a result, the downward spiral of code degradation becomes at least recognizable, hopefully less precipitous, and perhaps avoidable entirely. © 1997 by John Wiley & Sons, Ltd.

Economics of software re‐engineering

AbstractThere is a pressing need to be able to calculate and to justify the costs of software re‐engineering. The purpose of the paper is to address that need by establishing a framework for the economics of re‐engineering. The objective of re‐engineering is to reduce maintenance costs. This objective is served by increasing quality and reducing complexity. Both of these goals are examined here in the light of software maintainability metrics. The costs of re‐engineering are driven by the size and interdependency of the software as well as by the degree of automation available. The paper presents a method of estimating the costs of re‐engineering, and presents some figures acquired through practical experience. Finally, a method is defined for weighing estimated costs against expected benefits in order to support decisions on whether to renovate existing software or replace it by a new development. This is a major decision faced by many industrial managers today.