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.

Maintenance tends to degrade the structure of software, ultimately making maintenance more costly. At times, then, it is worthwhile to manipulate the structure of a system to make changes easier. However, it is shown that manual restructuring is an error-prone and expensive activity. By separating structural manipulations from other maintenance activities, the semantics of a system can be held constant by a tool, assuring that no errors are introduced by restructuring. To allow the maintenance team to focus on the aspects of restructuring and maintenance requiring human judgment, a transformation-based tool can be provided---based on a model that exploits preserving data flow-dependence and control flow-dependence---to automate the repetitive, errorprone, and computationally demanding aspects of re...

Restructuring software to improve its design can lower software maintenance costs. One problem in restructuring is planning out the redesign. The star diagram manipulable visualization can help a programmer redesign a program based on abstract data types. However, the underlying meaning-preserving transformational support for restructuring is costly to provide.

Software becomes better or worse because of the changes made to it. Each change to legacy software is expensive and risky but it also has potential for generating revenues because of desired new functionality or cost savings in future maintenance. Hence it is important to understand and quantify change properties in order to make good business deci- sions. Particularly good sources of historical information about changes, especially for legacy software, are generated by change management systems used by most large software organizations. This paper describes how to measure change properties and how to use that information to identify cost and quality drivers in software production. The methodology is codified in a system called 5'oftChange. 5'oftChange was developed for use with the 5EsSTMswitch at Lucent Technolo- gies, but can also be used with other software projects using the same, widespread version control systems. 5'oftChange defines, constructs and presents essential measures of software change size, complexity, and developer expertise. Also, it provides tools for imputing the purpose and effort required for a change, and generates predictions of the quality of a change. This methodology uses measurements of changes to benefit the software development process and to generate insights about software evolution.

Abstract: This article examines the academic substance of software engineering. It identifies the basic research questions and the methods used to solve them. What is learned during this research constitutes the body of knowledge of software engineering. The article then discusses at length what about software makes its production so difficult and makes software engineering so challenging an intellectual discipline. 1

Reverse engineering has been a standard practice in the hardware community for some time. It has only been within the last ten years that reverse engineering, or "program comprehension," has grown into the current sub-discipline of software engineering. Traditional software engineering is primarily focused on the development and design of new software. However, most programmers work on software that other people have designed and developed. Up to 50% of a software maintainers time can be spent determining the intent of source code. The growing demand to reevaluate and reimplement legacy software systems, brought on by the proliferation of clientserver and World Wide Web technologies, has underscored the need for reverse engineering tools and techniques. This paper introduces the terminology of reverse engineering and gives some of the obstacles that make reverse engineering difficult. Although reverse engineering remains heavily dependent on the human component, a number of automated t...

Tool-assisted meaning-preserving program restructuring has been proposed to aid the evolution of large software systems. These systems are difficult to modify because relevant information is often widely distributed. We performed an exploratory study to determine how programmers used a restructuring tool interface called the "star diagram" to organize their behavior for the task of encapsulating a data structure. We videotaped six pairs of programmers while they encapsulated and enhanced a data structure in an existing program. Each team used one of three environments: standard UNIX tools, a restructuring tool with textual view of the source code, or a restructuring tool using the star diagram view. We systematically analyzed the videotape transcripts to derive a model of how the programmers performed encapsulation. Each team opportunistically exploited the features of the tools (e.g., cursors) and the program representation (e.g., ordering of lines in a file) to help them track the current state of the activity...

A variety of programming accidents, i.e., models and methods, including extreme programming, are examined to determine that each has a step that programmers find painful enough that they habitually avoid or postpone the step. This pain is generally where the programming accident meets requirements, the essence of software, and their relentless volatility.

This paper presents a program analysis approach that discovers a general class of auxiliary informaton and latent program structure for incremental program comprehension. It combines traditional program analysis technology and comprehension mechanism for efficient incrementality of program understanding. The auxiliary information can be used in software maintenance and other possible applications.

A variety of programming accidents, i.e., models, methods, artifacts, and tools, are examined to determine that each has a step that programmers find very painful. Consequently, they habitually avoid or postpone the step. This pain is generally where the programming accident meets requirements, the essence of software, and their relentless volatility. Hence, there is no silver bullet.