Software evolutionary stability has become an important issue in software maintenance and evolution. It is directly related to software reusability, maintainability and evolvability. In reported prior research, software evolutionary stability has been measured with architecture-level metrics, including reference points and program-level metrics, such as number of modules and number of lines of code. In this paper, information-level metrics based on Kolmogorov complexity are used to measure the differences between versions of software products. Using normalized compression distance, various evolutionary stability metrics of software artifacts are defined: version stability, branch stability, structure stability and aggregate stability. Case studies are performed on two open-source products, Apache HTTP server and Apache Ant build tool. The results from this study show that information-level evolutionary stability metrics can be used together with architecture-level metrics and program-level metrics to assist monitoring the software evolution process, as well as identifying stable or unstable software artifacts.

A software system evolves as changes are made to accommodate new features and repair defects. Software components are frequently interdependent, so changes made to one component can result in changes having to be made to other components to ensure that the system remains consistent; this is called change propagation. Accurate detection of change propagation is essential for software maintenance, which can be aided by accurate prediction of change propagation. In this paper, we study change propagation in three leading open-source software products: Linux, FreeBSD, and Apache HTTP Server. We use association rules-based data-mining techniques to detect change-propagation rules from the product version history. These rules are evaluated with respect to different training data sets and different test data sets. We discuss the applicability of using association-rule mining for change propagation, and several related issues. We find that a challenging issue in association-rule mining, concept drift, exists in software systems. Concept drift complicates the task of change-propagation prediction and requires special approaches, different from currently-used techniques for predicting change propagation.

Abstract An accurate maintenance effort model is essential for a successful software maintenance process. Maintenance effort is usually measured in person‐hours used to perform a maintenance task. However, maintenance effort data are usually only available for strictly managed software, such as closed‐source software. In other software projects that do not have complete maintenance records, especially some open‐source software, there are no direct data for maintenance effort, which precludes the establishment of a maintenance effort model. In this paper, we report a series of studies aimed at presenting a method for indirectly predicting the maintenance effort of open‐source software. This report covers two parts of our research. First, we examine the maintenance data from NASA SEL closed‐source software projects and identify some software measures that can be used to indirectly represent maintenance effort. Second, based on the findings in the first part, we analyze 121 recent versions of Linux, and use linear regression to construct two indirect maintenance effort models for the Linux project. Our study demonstrates the applicability of this approach to indirectly predicting the maintenance effort and improving the software maintenance process. Copyright © 2006 John Wiley & Sons, Ltd.

Data coupling between modules, especially common coupling, has long been considered a source of concern in software design, but the issue is somewhat more complicated for products that are comprised of kernel modules together with optional nonkernel modules. This paper presents a refined categorization of common coupling based on definitions and uses between kernel and nonkernel modules and applies the categorization to a case study. Common coupling is usually avoided when possible because of the potential for introducing risky dependencies among software modules. The relative risk of these dependencies is strongly related to the specific definition-use relationships. In a previous paper, we presented results from a longitudinal analysis of multiple versions of the open-source operating system Linux. This paper applies the new common coupling categorization to version 2.4.20 of Linux, counting the number of instances of common coupling between each of the 26 kernel modules and all the other nonkernel modules. We also categorize each coupling in terms of the definition-use relationships. Results show that the Linux kernel contains a large number of common couplings of all types, raising a concern about the long-term maintainability of Linux.