Reports from the field are few and far between when it comes to traceability. As a community, we know little more about the traceability practice in companies today than we did a decade ago. This paper reports on findings from a practitioner survey designed to get a high-level update on traceability practice and problems. What emerges is the importance of the prevailing motivation underlying traceability adoption in an organization and we characterize this in four ways. We use these perspectives to discuss our findings and their implications.

For anything but the simplest of software systems, the ease and costs associated with change management can become critical to the success of a project. Establishing traceability initially can demand questionable effort, but sustaining this traceability as changes occur can be a neglected matter altogether. Without conscious effort, traceability relations become increasingly inaccurate and irrelevant as the artifacts they associate evolve. Based upon the observation that there are finite types of development activity that appear to impact traceability when software development proceeds through the construction and refinement of UML models, we have developed an approach to automate traceability maintenance in such contexts. Within this paper, we describe the technical details behind the recognition of these development activities, a task upon which our automated approach depends, and we discuss how we have validated this aspect of the work to date.

traceMaintainer is a tool that maintains post-requirements traceability amongst the elements of structural UML models. The maintenance of traceability relations is based upon predefined rules. Each rule recognizes a development activity applied to a model element. traceMaintainer carries out associated traceability updates in the background after an activity has been completed, requiring minimal manual effort and limited interaction with the developer. Currently, traceMaintainer can be used with two commercial software development (CASE) tools to update the traceability relations stored within them, while the underlying approach extends further to maintaining traceability within a heterogeneous and distributed environment of tools.

An accurate set of traceability relations between software development artifacts is desirable to support evolutionary development. However, even where an initial set of traceability relations has been established, their maintenance during subsequent development activities is time consuming and error prone, which results in traceability decay. This paper focuses solely on the problem of maintaining a set of traceability relations in the face of evolutionary change, irrespective of whether generated manually or via automated techniques, and it limits its scope to UML-driven development activities post-requirements specification. The paper proposes an approach for the automated update of existing traceability relations after changes have been made to UML analysis and design models. The update is based upon predefined rules that recognize elementary change events as constituent steps of broader development activities. A prototype traceMaintainer has been developed to demonstrate the approach. Currently, traceMaintainer can be used with two commercial software development tools to maintain their traceability relations. The prototype has been used in two experiments. The results are discussed and our ongoing work is summarized.

Maintenance is a time consuming activity within software development and it requires a good understanding of the system in question. It is hard or even impossible to understand poorly documented legacy systems. Nevertheless, developers try to understand unknown object oriented systems by analysing the source code to recover the architecture of the system, which is a hard task since the dependencies between the classes cannot be recovered good enough. Here, the knowledge about design patterns can help developers to understand the underlying architecture faster. We analysed existing pattern search approaches and compared them by their recall and precision values, metrics out of the information retrieval domain. As a result we developed own pattern search algorithms for the 23 design pattern described by Gamma et al. (1995). This fast abstract briefly explains the basics of our pattern search and describes first results of the search algorithms developed as a Java plug-in for the Together IDE. This work was funded by the BMBF (2004) and is part of the InPULSE (2004) project.

A methodology for the validation of rule-based expert systems is presented as a multi-step process that has three central themes: (1) creation of a useful set of test inputs that cover the domain; (2) a methodology that evaluates the system's responses to the test inputs and compares it to the responses of a panel of human experts; and (3) use of the validation results for system refinement. The presented methodology is performed in a loop. The starting point is a rule base and the loop ends up in a (hopefully) better rule base. The first three steps of this process have been published as separate issues in earlier papers by the authors. Here, these issues are just outlined and references are provided for detailed information. This paper gives an overview of the entire process and describes the relation between its steps. The last step, system refinement, is the new scientific issue here and thus, presented in more detail. Here, the rules are modified according to the results of evaluating the test cases. The base of this rule base reconstruction is both a 'rule-associated validity' and the existence of a 'better rated' human solution.