The scope of software visualization tools which exist for the navigation, analysis and presentation of software information varies widely. One class of tools, which we refer to as software exploration tools, provide graphical representations of software structures linked to textual views of the program source code and documentation. This paper describes a hierarchy of cognitive issues which should be considered during the design of a software exploration tool. The hierarchy of cognitive design elements is derived through the examination of program comprehension cognitive models. Examples of how existing tools address each of these issues are provided.

maintenance of large-scale software

personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee."

Software programs, especially legacy programs, are often large, complex and poorly documented. To maintain these programs software engineers require a variety of efficient analytical tools. Some software maintenance tools use visualizations (i.e. graphical views) to communicate information about software systems. Although many software visualization tools exist, the majority of them are not very effective in practice. Part of the problem is that they are designed in an ad hoc manner, with little empirical evaluation. They are often criticized because they try to force programmers to use a specific approach to understanding software rather than supporting their own approaches. The result is that current software visualization tools do not play as big a role in industry as was anticipated by some researchers. The tools that are used are very basic, consisting of mainly text editors and searching features. With increasingly fast computing platforms, there is great potential for the use of...

This paper reports on a software understanding experiment during corrective maintenance of large- scale software. Participants were professional software maintenance engineers. The paper reports on the general understanding process, the types of actions programmers preferred during the debugging task, and the level of abstraction at which they were working. The results of the observation are also interpreted in terms of the information needs of these software engineers during the debugging task. 1.

The practice of software development can likely be improved if an externalized model of each programmer’s knowledge of a particular code base is available. Some tools already assume a useful form of such a model can be created from data collected during development, such as expertise recommenders that use information about who has changed each file to suggest who might answer questions about particular parts of a system. In this paper, we report on an empirical study that investigates whether a programmer’s activity can be used to build a model of what a programmer knows about a code base. In this study, nineteen professional Java programmers completed a series of questionnaires about the code on which they were working. These questionnaires were generated automatically and asked about program elements a programmer had worked with frequently and recently and ones that he had not. We found that a degree of interest model based on this frequency and recency of interaction can often indicate the parts of the code base for which the programmer has knowledge. We also determined a number of factors that may be used to improve the model, such as authorship of program elements, the role of elements, and the task being performed.

Maintenance of evolving software systems has become the most frequently performed activity by software developers. A good understanding of the software system is needed to reduce the cost and length of this activity. Various approaches and tools have been proposed to assist in this process such as code browsers, slicing techniques, etc. These techniques neglect to use a central and vital piece of data available -- the historical modification records stored in source control systems. These records offer a rich and detailed account of the evolution of the software system to its current state.

Abstract not found

Prediction of problematic software components is an important activity today for many organizations as they manage their legacy systems and the maintenance problems they cause. This means that there is a need for methods and models to identify troublesome components. We apply a model for classification of software components as green, yellow and red according to the number of times they required corrective maintenance over successive releases. Further, we apply a principal component and box plot analysis to investigate the causes for the code decay and try to characterize the releases. The case study includes eight releases and 130 software components. The outcome indicates a large number of healthy components as well as a small set of troublesome components requiring extensive repair repeatedly. The analysis characterizes the releases and indicates that it is the relationship between components that causes many of the problems. 1. Introduction As a system evolves over a series of re...

Programmers often have to perform change tasks that involve unfamiliar portions of a software system’s code base. To help inform the design of software development tools intended to support programmers in this context, we conducted a qualitative study of how programmers manage such change tasks. In the study we observed Java programmers using a state-of-thepractice IDE to work on real change tasks to a mediumsized open source software system. In this paper we present our results, describing eight observations about the programmers ’ behavior and the impact of the development environment on their behavior. We also highlight several key challenges faced by the programmers and discuss the implications of our results on the design of development tools. 1