Abstmct-The Sees&t @ software visualization system allows one to analyze up to 50 000 lines of code simultaneously by mapping each line of code into a thin row. The color of each row indicates a statistic of interest, e.g., red rows are those most recently changed, and blue are those least recently changed. Seesoft displays data derived from a variety of sources, such as- version control systems that track the age, programmer, and purpose of the code, e.g., control ISDN lamps, fix hug in call forwarding; * static analyses, e.g., locations where functions are called; and l dynamic analyses, e.g., profiling. By means of direct manipulation and high interaction graphics, the user can manipulate this reduced repnzsentation of the code in order to find interesting patterns. Further insight is obtained by using additional windows to display the actual code. Potential applications for Seesoft include discovery, project management, code tuning, and analysis of development methodologies. Index Terms<hange management systems, code browsing, in-teractive graphics, line oriented statistics, scientific visualization. A

Abstract not found

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development and maintenance. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes. The studies revealed that (1) there is less than 4 percent probability that a one-line change will introduce an error in the code; (2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes; (3 the phenomena of change differs for additions, deletions and modifications as well as for the number of lines affected. 1.

Parallel developments are becoming increasingly prevalent in the building and evolution of large-scale software systems. Our previous studies of a large industrial project showed that there was a linear correlation between the degree of parallelism and the likelihood of defects in the changes. To further study the relationship between parallel changes and faults, we have designed and implemented an algorithm to detect “direct ” semantic interference between parallel changes. To evaluate the analyzer’s effectiveness in fault prediction, we designed an experiment in the context of an industrial project. We first mine the change and version management repositories to find sample versions sets of different degrees of parallelism. We investigate the interference between the versions with our analyzer. We then mine the change and version repositories to find out what faults were discovered subsequent to the analyzed interfering versions. We use the match rate between semantic interference and faults to evaluate the effectiveness of the analyzer in predicting faults. Our contributions in this evaluative empirical study are twofold. First, we evaluate the semantic interference analyzer and show that it is effective in predicting faults (based on “direct ” semantic interference detection) in changes made within a short time period. Second, the design of our experiment is itself a significant contribution and exemplifies how to mine software repositories rather than use artificial cases for rigorous experimental evaluations. 1.

Evolving a large system presents a number of signi cant challenges. Not only is the developer concerned about how to t in a new feature to a maze of existing features, he has to make surehischanges do not con ict with those being made in parallel by his colleagues. This is a minor problem in small projects with small organizations. However, as the project size scales up, so does the organization, and management of parallel tracks of development becomes a major concern. Moreover, increasing usage by customers with diverse needs pulls the evolving software into di erent directions, necessitating the evolution of multiple customized versions and compounding the already complex problem of evolving legacy systems. We will examine one such legacy system, the Lucent Technologies 5ESS R switching system. First introduced in 1982, 5ESS was envisioned to support telecommunication needs well into the next century. Already one of the largest and most complex pieces of real time code in the world, the software to run the switch still continues to evolve with new features and in an increasing number of customized versions. In order to keep up with future evolution and maintain the growing base of customers, a combined procedural and technological solution was put in place. We will discuss this particular solution and its limitations. 1

In building systems there are various levels at which we consider the problems reasoning about consistency and it means different things at those various levels. At the version management level, consistency means what it does in databases: no data is lost due to concurrency problems (eg, race conditions). At the composition and substitution (or creation and evolution) levels it means something that is significantly different--- namely, the syntactic and semantic consistency of the various pieces that make up the system. I first address the issue of what makes a system composition well-formed both syntactically and semantically. I then address the issue of substitution in well-formed system compositions, first in the context of simple substitution and then in the context of compound substitution (that is, the simultaneous substitution of multiple components). Note: This paper derived and extended from papers: the well-formed system composition paper [9] was published only as a technical report at CMU (though variously used without references or with misleading ones) the version control paper from ICSE9 [16], the extended abstract for SCM3 [19], and the shared dependency paper from SCM6 [20] all of which have been published only in conference or workshop versions. There may be parts of the other Inscape papers (ICSE9 [15], ICSE11 [17], and TAV3 [18]) included as well- all of which have been published only in conference versions.

Parallel changes are becoming increasingly prevalent in the development of large scale software system. To deepen the study on the relationship between parallel changes and faults, we have designed a tool to detect the direct semantic interference between parallel changes. In this paper, we describe an empirical study to evaluate this semantic interference detection tool. We first mine the change and version management repositories to find sample versions sets of different degree of parallel changes. On the basis of the analysis reports, we mine the change and version repositories to find out what faults were discovered subsequent to the analyzed versions. We will also determine the lapse and cost data for finding and fixing the faults associated with those samples. This approach provides a significant and low cost method for effectively evaluating the usefulness of software tools. 1.

Since source code is the ultimate definition of the behavior of a software product, changes to source code become the critical factor in understanding behavioral changes and predicting faults. In studies on source code changes, text or syntactic approaches have been widely used. Textual analysis focuses on changed text fragments while syntactic analysis focuses on changed syntactic entities. Although both of them have demonstrated their advantages in experimental results, they have only focused on changed code. Because of semantic dependencies within programs, we believe that code impacted by changes is also helpful. Given a source code change, we identify its impact by program slicing along the variable def-use chains. To evaluate the effectiveness of change impacts in fault detection and prediction, we compare impacted code with changed code according to size and fault density. Our experiment on the change history of a successful industrial project shows that: for large changes, their impacts have relative small size and high fault density; while for small changes, change themselves have relative small size and high fault density. Our study suggests that: 1) change impacts are complementary to change themselves in detecting or predicting faults; 2) within the impact of a large change, a high degree of interference between impacts of different changed lines contributes to the high fault density; 3) high fault density in impacts aggravates the danger of large changes. 1.

Changes to source code have become a critical factor in fault predictions. Text or syntactic approaches have been widely used. Textual analysis focuses on changed text fragments while syntactic analysis focuses on changed syntactic entities. Although both of them have demonstrated their advantages in experimental results, they only study code fragments modified during changes. Because of semantic dependencies within programs, we believe that code fragments impacted by changes are also helpful. Given a source code change, we identify its impact by program slicing along the variable def-use chains. To evaluate the effectiveness of change impacts in fault detection and prediction, we compare impacted code with changed code according to size and fault density. Our experiment on the change history of a successful industrial project shows that: fault density in changed and impacted fragments are higher than other areas; for large changes, their impacts have higher fault density than changes themselves; interferences within change impact contribute to the high fault density in large changes. Our study suggests that, like change itself, change impact is also a high priority indicator in fault prediction, especially for changes of large scales. 1.