So-called little,ordomain-specific languages (DSLs), have the potential to make software maintenance simpler: domain-experts can directly use the DSL to make required routine modifications. On the negative side, however, more substantial changes may become more difficult: such changes may involve altering the domain-specific language. This will require compiler technology knowledge, which not every commercial enterprise has easily available. Based on experience taken from industrial practice, we discuss the role of DSLs in software maintenance, the dangers introduced by using them, and techniques for controlling the risks involved.

In 2001, Chou et al. published a study of faults found by applying a static analyzer to Linux versions 1.0 through 2.4.1. A major result of their work was that the drivers directory contained up to 7 times more of certain kinds of faults than other directories. This result inspired a number of development and research efforts on improving the reliability of driver code. Today Linux is used in a much wider range of environments, provides a much wider range of services, and has adopted a new development and release model. What has been the impact of these changes on code quality? Are drivers still a major problem? To answer these questions, we have transported the experiments of Chou et al. to Linux versions 2.6.0 to 2.6.33, released between late 2003 and early 2010. We find that Linux has more than doubled in size during this period, but that the number of faults per line of code has been decreasing. And, even though drivers still accounts for a large part of the kernel code and contains the most faults, its fault rate is now below that of other directories, such as arch (HAL) and fs (file systems). These results can guide further development and research efforts. To enable others to continually update these results as Linux evolves, we define our experimental protocol and make our checkers and results available in a public archive.

The paper reports on a method for software risk assessments that takes into account “primary facts ” and “secondary facts”. Primary facts are those obtained through automatically analyzing the source code of a system, and secondary facts are those facts obtained from people working with or on the system, and available documentation. We describe how both types of facts are retrieved, and how we are bridging the interpretation gap from the raw facts (either primary or secondary) to a concise risk assessment, which includes recommendations to minimize the risk. This method has been developed while performing numerous risk assessments, and is continuously being fine-tuned. 1.

Maintainers face the daunting task of wading through a collection of both new and old revisions, trying to ferret out revisions which warrant personal inspection. One can rank revisions by size/lines of code (LOC), but often, due to the distribution of the size of changes, revisions will be of similar size. If we can’t rank revisions by LOC perhaps we can rank by Halstead’s and McCabe’s complexity metrics? However, these metrics are problematic when applied to code fragments (revisions) written in multiple languages: special parsers are required which may not support the language or dialect used; analysis tools may not understand code fragments. We propose using the statistical moments of indentation as a lightweight, language independent, revision/diff friendly metric which actually proxies classical complexity metrics. We have extensively evaluated our approach against the entire CVS histories of the 278 of the most popular and most active SourceForge projects. We found that our results are linearly correlated and rankcorrelated with traditional measures of complexity, suggesting that measuring indentation is a cheap and accurate proxy for code complexity of revisions. Thus ranking revisions by the standard deviation and summation of indentation will be very similar to ranking revisions by complexity. 1

We use 810 versions of the Linux kernel, released over a period of 14 years, to characterize the system’s evolution, using Lehman’s laws of software evolution as a basis. We investigate different possible interpretations of these laws, as reflected by different metrics that can be used to quantify them. For example, system growth has traditionally been quantified using lines of code or number of functions, but functional growth of an operating system like Linux can also be quantified using the number of system calls. In addition we use the availability of the source code to track metrics, such as McCabe’s cyclomatic complexity, that have not been tracked across so many versions previously. We find that the data supports several of Lehman’s laws, mainly those concerned with growth and with the stability of the process. We also make some novel observations, e.g. that the average complexity of functions is decreasing with time, but this is mainly due to the addition of many small functions.

Abstract—Software maintenance involves different categories of activities: corrective, adaptive, perfective, and preventive. However, research regarding these distinct activities is hampered by lack of empirical data that is labeled to identify the type of maintenance being performed. A promising dataset is provided by the more than 800 versions of the Linux kernel that have been released since 1994. The Linux release scheme differentiates between development versions (dominated by perfective maintenance) and production versions (mainly corrective maintenance). The structure of the codebase also distinguishes code involved in handling different architectures and devices (where additions reflect adaptive maintenance) from the core of the system’s kernel. By analyzing different parts of the code separately, we demonstrate that corrective maintenance does not necessarily lead to code deterioration, that adaptive maintenance may improve some quality metrics, and that growth is largely the result of continued development as part of perfective maintenance. Index Terms—Perfective maintenance, Corrective maintenance, Adaptive maintenance, Linux kernel

Clustering is a data mining technique that allows the grouping of data points on the basis of their similarity with respect to multiple dimensions of measurement. It has also been applied in the software engineering domain, in particular to support software quality assessment based on source code metrics. Unfortunately, since clusters emerge from metrics at the source code level, it is difficult to interpret the significance of clusters at the level of the quality of the entire system. In this paper, we propose a method for interpreting source code clusters using the ISO/IEC 9126 software product quality model. Several methods have been proposed to perform quantitative assessment of software systems in terms of the quality characteristics defined by ISO/IEC 9126. These methods perform mappings of low-level source code metrics to highlevel quality characteristics by various aggregation and weighting procedures. We applied such a method to obtain quality profiles at various abstraction levels for each generated source code cluster. Subsequently, the plethora of quality profiles obtained is visualized such that conclusions about different quality problems in various clusters can be obtained at a glance. 1.

For many years now, software practitioners have been collecting metrics from source code in an effort to better understand the software they are developing or changing. Maintainability Index (MI) is a composite metric that incorporates a number of traditional source code metrics into a single number that indicates relative maintainability. As originally proposed by Oman and Hagemeister, the MI is comprised of weighted Halstead metrics (effort or volume), McCabe’s Cyclomatic Complexity, lines of code (LOC), and number of comments [1, 2]. Two equations were presented: one that considered comments and one that did not. The original polynimial equations defining MI are as follows: 3-Metric: MI=171-3.42ln(aveE)-0.23aveV(g’)- 16.2ln(aveLOC) where aveE is the average Halstead Effort per module, aveV(g’) is the average extended cyclomatic complexity per module, and aveLOC is the average lines of code per module.

This thesis aims at characterizing software maintenance activities using Linux kernel, based on calculation of different software metrics. We perform our analysis and calculation for over 800 versions of the Linux kernel. We perform our analysis using several dissections — comparing production and development versions, as well as the new releases branch (2.6), and also comparing the core of the kernel to the arch and drivers directories. We present the results and the calculated metrics and then try to tie them to the different maintenance activities and make significant observations about them. We also aim at examining whether some of Lehman’s Laws exist in the development of the Linux kernel.

Abstract- This research paper studies the complexities of four tree search algorithms in order to determine the most efficient programming language for implementing each of the algorithms. Each the tree search algorithm was implemented in C, C++, Pascal, and Visual BASIC programming languages. The codes were empirically analysed using Halstead Volume and Cyclomatic number. The result of the analysis revealed that Pascal programming language is the best language for implementing breadth-first, depth-first, and depth-limited search algorithms while C language was isolated as the best for implementing A-Star search algorithm.