Previous taxonomies of software evolution have focused on the purpose of the change rather than the underlying mechanisms. This paper proposes a taxonomy of software evolution based on the characterizing mechanisms of change and the factors that influence these mechanisms. The taxonomy is organized into the following logical groupings: temporal properties, objects of change, system properties, and change support. The ultimate goal of this taxonomy is to provide a framework that positions concrete tools, formalisms and methods within the domain of software evolution. Such a framework would considerably ease comparison between these tools, formalisms and methods. It would also allow practitioners to evaluate their potential use in particular change scenarios. As an initial step towards this taxonomy, the paper presents a framework that can be used to characterize software change support tools and to identify the factors that impact on the use of these tools. The framework is evaluated by applying it to three different change support tools and by comparing these tools based on this analysis.

Programmers must attain knowledge about a system before they can perform specific software maintenance tasks on it. Traditionally, computer scientists have described the activity of attaining this knowledge as ‘software comprehension’. However, if we look at the educational literature, attainable knowledge has been described with much finer granularity. Bloom’s (1956) taxonomy identifies six separate levels of knowledge within the cognitive domain, one of which refers to a (more constricted) definition of comprehension. Several other levels in Bloom’s taxonomy seem to correlate more directly to specific software maintenance tasks. This article reviews Bloom’s taxonomy as a richer descriptive framework for programmers’ knowledge of code and illustrates how various software maintenance tasks map to knowledge levels in this hierarchy. A pilot study is presented showing how participants’ knowledge of software may differ at various levels of this hierarchy.

A software designer often has little control over, or means of checking, whether his design is being adhered to, once the implementation begins. This ‘architectural drift’, where the original design of the system and the as-implemented design of the system diverge, can cause serious problems for evolution, maintenance and the comprehensibility of a system if it remains undocumented or uncorrected. The earlier such discrepancies can be identified, the better.

This paper reports on a case study designed to evaluate a proposed approach for monitoring architectural drift during software development. The proposed approach differs significantly from existing design conformance approaches in that it has been designed for application within a forward engineering context. The findings show the utility of the approach in identifying architectural drift but also illustrate a number of improvements that could be made to the technique to further promote architecture conformance.

Objectives: Software architecture is perceived as one of the most important artefacts created during a system’s design. However, implementations often diverge from their intended architectures: a phenomenon called architectural drift. The objective of this research is to assess the occurrence of architectural drift in the context of de novosoftware development, to characterize it, and to evaluate whether its detection leads to inconsistency removal. Method: Anin vivo, longitudinal case study was performed during the development of a commercial software system, where an approach based on Reflexion Modelling was employed to detect architectural drift. Observation and think-aloud data, captured during the system’s development, were assessed for the presence and types of architectural drift. When divergences were identified, the data were further analysed to see if identification led to the removal of these divergences. Results: The analysed system diverged from the intended architecture, during the initial implementation of the system. Surprisingly however, this work showed that Reflexion Modelling served to conceal some of the inconsistencies, a finding that directly contradicts the high regard that this technique enjoys as an architectural evaluation tool. Finally, the analysis illustrated that detection of inconsistencies was insufficient to prompt their removal, in the small, informal team context studied. Conclusions: Although the utility of the approach for detecting inconsistencies was demonstrated in most cases, it also served to hide several inconsistencies and did not act as a trigger for their removal. Hence additional efforts must be taken to lessen architectural drift and several improvements in this regard are suggested.

Information seeking has been recognised as a core subtask in software maintenance. This paper reviews, merges, and adapts existing information seeking models for different domains to propose a non-linear information-seeking model for programmers involved in software maintenance. Talk-aloud data from two empirical studies of industrial programmers carrying out real software maintenance tasks is presented, to illustrate and validate (in part) this model.

It is the view of many computer scientists that the standard of empirical software engineering research leaves scope for improvement. However, there is also an increasing awareness in the software engineering community that empirical studies are a vital aspect in the process of improving methods and tools, for software development and maintenance. This paper presents a review of the empirical work carried out to date in the area of program comprehension and illustrates that most of the evidence from these studies derives from lab-based experiments, thus implying a degree of artificial control. The paper argues that, in order to address the methodological shortfalls of the experimental paradigm, more qualitative methods need to be applied to accompany and support these quantitative studies, thus broadening the sources of data and increasing the ‘body of evidence’.

This paper presents an analysis schema for talk-aloud protocols, which distinguishes between bottomup and two variants of top-down comprehension (as originally described by Brooks and Soloway et al). The first is ‘expectation-based’ comprehension, where the programmer has pre-generated hypotheses of the code’s meaning before studying the code segments. The second variant is ‘inference-based’ comprehension, where the programmer derives hypotheses from clichéd implementations in the code. The schema is placed in the context of other talk-aloud analysis schemas. It is described in detail, allowing other researchers replicate the protocol and assess the generality of its findings. A brief description of an experiment, which uses this schema, is also included.

Large legacy systems that have been in use for several decades need to evolve in order to take advantage of new technological advances. One such development is the emergence of multi-core processors and parallel platforms. However, the evolution of code written for single-core platforms into code that can take advantage of multi-core technology is challenging. The aim of this research is to explore the challenges that parallel programmers face in the evolution of existing software to exploit multicore and parallel architectures. A review of the current literature was conducted and ten frequently reported challenges were identified. It is important to raise awareness of potential challenges that practitioners may face when evolving sequential code to exploit multicore platforms in order to be better prepared for future evolution. The research community can use these results to develop a research agenda in order to design and develop solutions to address these challenges.

Identifying elements of existing software that are reused within a system may provide maintainers with valuable insights during system evolution. This paper evaluates an extension of software reconnaissance that can be used to analyze reuse across features in a system, as part of a component recovery process. We illustrate and evaluate retrieval of reuse information in this fashion using a large, commercial ERP and warehousing application. Results suggest that the approach scales well in terms of reuse information across features in existing software, providing maintainers with a valuable new perspective on the software system in question.

Software architecture and its related documentation are acknowledged as some of the most important artefacts created during system design. However, often the implemented system diverges, over time, from the designed architecture. This phenomenon is called architectural drift and is either a result of inconsistent evolution of the system, or a failure to keep the architectural documentation up to date. A case study, performed at IBM, over two years showed how architectural drift can occur in small development teams over time. It suggested that even when approaches are in place to identify architectural drift, they may prove insufficient for subsequent removal of the drift, and some possible reasons for this were derived. Consequently, this document outlines the resultant design requirements for an approach to inhibit architectural drift, primarily by identifying it as, or before, it is introduced.