Sallie M. Henry

Object-oriented metrics that predict maintainability

Abstract Software metrics have been studied in the procedural paradigm as a quantitative means of assessing the software development process as well as the quality of software products. Several studies have validated that various metrics are useful indicators of maintenance effort in the procedural paradigm. However, software metrics have rarely been studied in the object-oriented paradigm. Very few metrics have been proposed to measure object-oriented systems, and the proposed ones have not been validated. This research concentrates on several object-oriented software metrics and the validation of these metrics with maintenance effort in two commercial systems. Statistical analyses of a prediction model incorporating 10 metrics were performed. In addition, a more compact model with fewer metrics is presented.

The evaluation of software systems' structure using quantitative software metrics

The design and analysis of the structure of software systems has typically been based on purely qualitative grounds. In this paper we report on our positive experience with a set of quantitative measures of software structure. These metrics, based on the number of possible paths of information flow through a given component, were used to evaluate the design and implementation of a software system (the UNIX operating system kernel) which exhibits the interconnectivity of components typical of large‐scale software systems. Several examples are presented which show the power of this technique in locating a variety of both design and implementation defects. Suggested repairs, which agree with the commonly accepted principles of structured design and programming, are presented. The effect of these alterations on the structure of the system and the quantitative measurements of that structure lead to a convincing validation of the utility of information flow metrics.

Software quality metrics based on interconnectivity

We state a set of criteria that has guided the development of a metric system for measuring the quality of a largescale software product. This metric system uses the flow of information within the system as an index of system interconnectivity. Based on this observed interconnectivity, a variety of software metrics can be defined. The types of software quality features that can be measured by this approach are summarized. The data-flow analysis techniques used to establish the paths of information flow are explained and illustrated. Finally, a means of integrating various metrics and models into a comprehensive software development environment is discussed. This possible integration is explained in terms of the Gandalf system currently under development at Carnegie-Mellon University.

Predicting source-code complexity at the design stage

It is shown how metrics can be used to gauge the quality of source code by evaluating its design specifications before coding, thus shortening the development life cycle. The predictive abilities of several types of metrics, all quantitative, are evaluated, and statistics that can be used to adapt them to a particular project are provided. The study data consist of programs written by students, but, because the programs are large, the professor did not provide the specifications, and the test data were not provided, it is believed that the programs are sufficiently realistic for the approach presented to be generally valid.<<ETX>>

On the relationships among three software metrics

Automatable metrics of software quality appear to have numerous advantages in the design, construction and maintenance of software systems. While numerous such metrics have been defined, and several of them have been validated on actual systems, significant work remains to be done to establish the relationships among these metrics. This paper reports the results of correlation studies made among three complexity metrics which were applied to the same software system. The three complexity metrics used were Halsteads effort, McCabes cyclomatic complexity and Henry and Kafuras information flow complexity. The common software system was the UNIX operating system. The primary result of this study is that Halsteads and McCabes metrics are highly correlated while the information flow metric appears to be an independent measure of complexity.

An empirical study of the object-oriented paradigm and software reuse

Little or no empirical validation exists for many of software engineerings basic assumptions. While some of these assumptions are intuitive, the need for scientific experimentation remains clear. Several assumptions are made about the factors affecting software reuse, and in particular, the role of the object-oriented paradigm. This paper describes the preliminary results of a controlled experiment designed to evaluate the impact of the object-oriented paradigm on software reuse. The experiment concludes that (1) the object-oriented paradigm substantially improves productivity, although a significant part of this improvement is due to the effect of reuse, (2) reuse without regard to language paradigm improves productivity, (3) language differences are far more important when programmers reuse than when they do not, and (4) the object-oriented paradigm has a particular affinity to the reuse process.

Using Belbin's leadership role to improve team effectiveness: an empirical investigation

Abstract This paper presents a controlled experiment conducted with senior software engineering students that demonstrates the utility of forming teams based on R. Meredith Belbins set of team roles. The overall research effort focuses on the general utility of Belbins roles in improving the effectiveness of teams, which can be viewed in two ways: performance and team viability. Performance effectiveness, which is the focus of this paper, clearly addresses a teams productivity. To address this problem, the first phase of the total research project consists of a controlled experiment that demonstrates that teams containing leadership roles perform better than teams that do not have this role filled. In a laboratory setting, a number of teams were formed that contained a single leader; others were formed that had no leader or multiple leaders. The results of this experiment are positive; they demonstrate that indeed Belbins roles provide useful information to form teams. The specific conclusion of this controlled experiment is that a single leader on a team improves a teams performance over teams having multiple leaders or no leader. In other words, as one would expect, the mean time-to-completion for the leaderless teams was significantly greater than the teams with leaders. This means that Belbins roles can be utilized in formation of new teams as well as in evaluation of extant teams, making certain that a team has a single leader. Both of these aspects, formation and evaluation, are extremely useful to managers of software programmers.

Predicting Maintainability with Software Quality Metrics

Maintenance of software makes up a large fraction of the time and money spent in the software life cycle. By reducing the need for maintenance these costs can also be reduced. Predicting where maintenance is likely to occur can help to reduce maintenance by prevention. This paper details a study of the use of software quality metrics to determine high complexity components in a software system. By the use of a history of maintenance done on a particular system, it is shown that a predictor equation can be developed to identify components which needed maintenance activities. This same equation can also be used to determine which components are likely to need maintenance in the future. Through the use of these predictions and software metric complexities it should be possible to reduce the likelihood of a component needing maintenance. This might be accomplished by reducing the complexity of that component through further decomposition. Even though this is only one study, this methodology of developing maintenance predictors could be applied in any environment.

A model based on software quality factors which predicts maintainability

Software quality metric were developed to measure the complexity of software systems. The authors relate the complexity of the system as measured by software metrics to the amount of maintenance necessary to that system. The authors have developed a model which uses several software quality metrics as parameters to predict maintenance activity. A description is given of three classifications of metrics that are used to measure the quality of source code: code metrics, which measure physical characteristics of the software, such as length or number of tokens; structure metrics, which measure the connectivity of the software, such as the flow of information through the program and flow of control; and hybrid metrics, which are a combination of code and structure metrics.<<ETX>>

Improving software maintenance at Martin Marietta

Using data collected throughout a major project, the authors apply common statistical methods to quantitatively assess and evaluate improvements in a large contractors software-maintenance process. Results show where improvements are needed; examining the change in statistical results lets you quantitatively evaluate the effectiveness of the improvements. We selected a process-assessment methodology developed by J.E. Henry (1993) that follows Total Quality Management principles and is based on Watts Humphreys Process Maturity Framework. It lets you use a process modeling technique based on control-flow diagrams to define an organizations maintenance process. After collecting process and product data throughout the maintenance process, you analyze it using parametric and nonparametric statistical techniques. The statistical-analysis results and the process model help you assess and guide improvements in the organizations maintenance process. The method uses common statistical tests to quantify relationships among maintenance activities and process and product characteristics. The relationships, in turn, tell you more about the maintenance process and how requirements changes affect the product.<<ETX>>