Version control and bug tracking systems contain large amounts of historical information that can give deep insight into the evolution of a software project. Unfortunately, these systems provide only insufficient support for a detailed analysis of software evolution aspects. We address this problem and introduce an approach for populating a release history database that combines version data with bug tracking data and adds missing data not covered by version control systems such as merge points. Then simple queries can be applied to the structured data to obtain meaningful views showing the evolution of a software project. Such views enable more accurate reasoning of evolutionary aspects and facilitate the anticipation of software evolution. We demonstrate our approach on the large Open Source project Mozilla that offers great opportunities to compare results and validate our approach. 1.

A central feature of the evolution of large software systems is that change -- which is necessary to add new functionality, accommodate new hardware and repair faults -- becomes increasingly difficult over time. In this paper we approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay, and propose a number of measurements (code decay indices) on software, and on the organizations that produce it, that serve as symptoms, risk factors and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed but on the whole persuasive statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decayarealso discussed.

Kaserntryckeriet, Karlskrona 2002 "Real knowledge is to know the extent of one's ignorance.“

Abstract not found

Visualizations of software changes are presented that complement existing visualizations of software structure. The principal metaphors are matrix views, cityscapes, bar and pie charts, data sheets and networks. Linked by selection mechanisms, multiple views are combined to form perspectives that both enable discovery of high-level structure in software change data and allow effective access to details of those data. Use of the views and perspectives is illustrated in two important contexts: understanding software change by exploration of software change data and management of software development.

Abstract. Formal Concept Analysis (FCA) has typically been applied in the field of software engineering to support software maintenance and object-oriented class identification tasks. This paper presents a broader overview by describing and classifying academic papers that report the application of FCA to software engineering. The papers are classified using a framework based on the activities defined in the ISO12207 Software Engineering standard. Two alternate classification schemes based on the programming language under analysis and target application size are also discussed. In addition, the authors work to support agile methods and formal specification via FCA is introduced. 1

Software tools can improve the quality and maintainability ofsoftware, but are expensive to acquire, deploy and maintain, especially in large organizations. We explore how toquantify the e ects of a software tool once it has been deployed in a development environment. We present a simple methodology for tool evaluation that correlates tool usage statistics with estimates of developer e ort, as derived from a project's change history (version control system). Our work complements controlled experiments on software tools, which usually take place outside the industrial setting, and tool assessment studies that predict the impact of software tools before deployment. Our analysis is inexpensive, non-intrusive and can be appliedtoanentire software project in its actual setting. Akey part of our analysis is how tocontrol confounding variables such asdeveloper work-style and experience in order accurately to quantify the impact of a tool on developer e ort. We demonstrate our method in a case study of a software tool called VE, a version-sensitive editor used in Bell Labs. VE aids software developers in coping with the rampant use of preprocessor directives (such as #if/#endif) in C source les. Our analysis found that developers were approximately 36 % more productive when using VE than when using standard text editors.

In this paper we describe a methodology and algorithm for historical analysis of the effort necessary for developers to make changes to software. The algorithm identifies factors which have historically increased the difficulty of changes. This methodology has implications for research into cost drivers. As an example of a research finding, we find that a system under study was "decaying" in that changes grew more difficult to implement at a rate of 20% per year. We also quantify the difference in costs between changes that fix faults and additions of new functionality: fixes require 80% more effort after accounting for size. Since our methodology adds no overhead to the development process, we also envision it being used as a project management tool: for example, developers can identify code modules which have grown more difficult to change than previously, and can match changes to developers with appropriate expertise. The methodology uses data from a change management system, supported by monthly time sheet data if available. The method's performance does not degrade much when the quality of the time sheet data is limited. We validate our results using a survey of the developers under study: the change efforts resulting from the algorithm match the developers ' opinions. Our methodology includes a technique based on the jackknife to determine factors that contribute significantly to change effort.

Abstract. In 1978, Lientz, Swanson, and Tompkins published the results of a survey on software maintenance. They found that 17.4 % of maintenance effort was categorized as corrective in nature, 18.2% as adaptive, 60.3 % as perfective, and 4.1 % was categorized as other. We refer to this as the ‘‘LST’ ’ result. We contrast this survey-based result with our empirical results from the analysis of data for the repeated maintenance of three software products: a commercial real-time product, the Linux kernel, and GCC. For all three products and at both levels of granularity we considered, our observed distributions of maintenance categories were statistically very highly significantly different from LST. In particular, corrective maintenance was always more than twice the LST value. For the summed data, the percentage of corrective maintenance was more than three times the LST value. We suggest various explanations for the observed differences, including inaccuracies on the part of the maintenance managers who responded to the LST survey.

Object-oriented databases (OODBs) are believed to more naturally reflect the behavior and organization of complex application domains. The schema consists of a collection of classes, organized into hierarchies which nicely organize abstractions over the domain. Objects are created as instances of classes, encapsulating data and interpretation of data together. An important characteristic is the support for evolutionary programming, and so that existing programs may be extended with new classes without affecting other parts of the system.