A software tool called EXPLAINER has been developed for helping programmers perform new tasks by exploring previously worked-out examples. EXPLAINER is based on cognitive principles of learning from examples and problem solving by analogy. The interface is based on the principle of making examples accessible through multiple presentation views and multiple representation perspectives. Empirical evaluation has shown that programmers using EXPLAINER exhibit less variability in their performance compared to programmers using a commercially available, searchable on-line manual. These results are related to other studies of programmers and to current methodologies in software engineering.

Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we undertook two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a mediumsized code base. The other study involved industrial programmers working on their own change tasks to code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on how they go about discovering that information. Based on a systematic analysis of the data from these user studies as well as an analysis of the support that current programming tools provide for these activities, this research makes four key contributions: (1) a catalog of 44 types of questions programmers ask, (2) a categorization of those questions into four categories based on the kind and scope of information needed to answer a question, (3) a description of important context for the process of answering questions, and (4) a description of support that is missing from current programming tools.

Software maintenance claims a large proportion of organizational resources. It is thought that many maintenance problems derive from inadequate software design and development practices. Poor design choices can result in complex software that is costly to support and difficult to change. However, it is difficult to assess the actual maintenance performance effects of software development practices because their impact is realized over the software life cycle. To estimate the impact of development activities in a more practical time frame, this research develops a two-stage model in which software complexity is a key intermediate variable that links design and development decisions to their downstream effects on software maintenance. The research analyzes data collected from a national mass merchandising retailer on 29 software enhancement projects and 23 software applications in a large IBM COBOL environment. Results indicate that the use of a code generator in development is associated with increased software complexity and software enhancement project effort. The use of packaged software is associated with decreased software complexity and software enhancement effort. These results suggest an important link between software development practices and maintenance performance.

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 system documentation is almost always expressed informally, in natural language and free text. Examples include requirement specifications, design documents, manual pages, system development journals, error logs and related maintenance reports. We propose an approach to establish and maintain traceability links between the source code and free text documents. A premise of our work is that programmers use meaningful names for program's items, such as functions, variables, types, classes, and methods. We believe that the application-domain knowledge that programmers process when writing the code is often captured by the mnemonics for identifiers; therefore, the analysis of these mnemonics can help to associate high level concepts with program concepts, and vice-versa. In this paper, the approach is applied to software written in an object-oriented language, namely C++, to trace classes to manual sections. Keywords: traceability, versions compliance check, object orientation 1.

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...

Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers comprehend software, as well as the tools that are used to assist in comprehension tasks. During this talk I will review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I will then explore how tools that are popular today have evolved to support program comprehension. Specifically, I will discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools will be further differentiated according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I will predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tools and methods. 1.

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.

This article investigates how and why people remember the existence of hidden information. To obtain data on this kind of memory phenomenon, we observed an experienced programmer doing her own work at her own computer. The programmer's interaction with the computer generates much more information than fits on the screen at once. Most of this information is hidden, scrolled out of the way by the programming environment to make Direct all correspondence to: Erik M. Altmann, George Mason University, Human Factors & Applied Cognition, Mailstop 2E5, Fairfax, VA 22030 USA; E-Mail: altmann@gmu.edu

AbstractÐRecently, the first two in a series of planned comprehension experiments were performed to measure the effect of the control structure diagram �CSD) on program comprehensibility. Upper- and lower-division computer science and software engineering students were asked to respond to questions regarding the structure and execution of one source code module of a public domain graphics library. The time taken for each response and the correctness of each response was recorded. Statistical analysis of the data collected from these two experiments revealed that the CSD was highly significant in enhancing the subjects ' performance in this program comprehension task. The results of these initial experiments promise to shed light on fundamental questions regarding the effect of software visualizations on program comprehensibility. Index TermsÐSoftware visualization, control structure diagram, program comprehension, controlled experiments, evaluation. 1