improvement opportunities, an obvious choice is information flow. Obtaining accurate, up-to-date, and useful information about a system being maintained is a major task. It is also a difficult task because the sources of this information are often limited, inaccessible, or unknown. Clearly this impacts maintenance productivity - simply because of the time it takes to find and use the appropriate information sources - as well as the quality of system changes, which depends on the quality of the system information available. This paper describes the results of a survey study that aims to discover the information gathering strategies that software maintainers employ. The survey was completed by 45 software professionals in two different organizations with varying degrees of experience in maintenance. Their responses, on the surface, simply show that maintainers overwhelmingly rely on source code, which is not surprising. However, a deeper analysis of the responses show that other sources of information, in particular human sources, some types of CASE support, and lessons learned recorded from previous projects are at least as valuable than source code under some conditions. The results of this ongoing survey study are meant to determine a set of hypotheses about information gathering strategies, which will then be empirically evaluated in future studies.

This paper presents ongoing work on using data mining to discover knowledge about software systems thus facilitating program comprehension. We discuss how this work fits in the context of tool supported maintenance and comprehension and report on applying a new methodology on C++ programs. The overall framework can provide practical insights and guide the maintainer through the specifics of systems, assuming little familiarity with these. The contribution of this work is two-fold: it provides a model and associated method to extract data from C++ source code which is subsequently to be mined, and evaluates a proposed framework for clustering such data to obtain useful knowledge. The methodology is evaluated on three open source applications, results are assessed and conclusions are presented. This paper concludes with directions for future work. 1.

Abstract: The quality of business software is more and more becoming a competitive factor. As complete testing is impossible, testers have to make decisions, e.g. to choose which parts of the software have to be tested in which way. For this purpose, testers need a lot of information, e.g. input documentation which serves as a basis for the derivation of test cases or information on the project status which serves as a basis to plan the testing process. Thus, testers rely on up-to-date and complete information in order to make sound decisions. Consequently, the quality of the testing process depends on the quality of the information sources available for the testers. This paper presents the results of an interview study conducted during the SIKOSA research project with expert testers of our industry partners in order to identify the most valuable sources of information during testing. Particularly, we investigated which documents are often used by testers as well as the role of communication and experience. Our results show that defect reports are very valuable. User manuals and problem reports are equally important, because they represent real usage of the software and serve testers as input for realistic test cases. Additionally, our results show the influence of an independent testing team on test process characteristics. 1.

Conducting controlled experiments about programming activities often requires the use of multiple tasks of similar difficulty. In previously reported work about a controlled experiment investigating software exploration tools, we tried to select two change tasks of equivalent difficulty to be performed on a medium-sized code base. Despite careful effort in the selection and confirmation from our pilot subjects finding the two tasks to be of equivalent difficulty, the data from the experiment suggest the subjects found one of the tasks more difficult than the other. In this paper, we report on early work to create a metric to estimate the cognitive difficulty for a software change task. Such a metric would help in comparing between studies of different tools, and in designing future studies. Our particular approach uses a graph-theoretic statistic to measure the complexity of the task solution by the connectedness of the solution elements. The metric predicts the perceived difficulty for the tasks of our experiment, but fails to predict the perceived difficulty for other tasks to a small program. We discuss these differences and suggest future approaches.

Software maintenance is widely known as a problematic area that may consume up to 80 % of a software project’s resources. It has been claimed that providing an effective mechanism to access Design Rationale (DR) has great potential to improve software maintenance processes. However, we postulate that the first step towards exploring the potential of DR for improving software maintenance should be to gain a better understanding of what DR means to practitioners, how valuable they consider DR to be and how they use DR. To determine the perceived usefulness of DR, we surveyed a large number of software designers. This exploratory study has discovered that practitioners recognize the importance of DR to understand existing designs and frequently use it to reason about proposed modifications. The results of this study establish that DR is perceived by practitioners to be useful and the efforts required to capture DR for the purpose of maintenance are worthwhile. The findings allow us to identify areas of further research on DR support that have the potential to improve the maintenance process. 1.