Context and background: Software maintenance and evolution occur throughout the lifetime of a software system and involve activities such as fixing bugs, adding functionality or improving the software’s design. Maintenance and evolution consume the majority of a software product’s lifecycle costs. With system evolution, the software architecture of a system evolves as well.

Problem: A poor understanding of software maintenance tasks can negatively impact the software architecture of a system. For example, practitioners may lack sufficient details to interpret the effort and implications of performing a task. From an architecture perspective, practitioners need to understand where and how much architecture changes happen. Poorly performed or understood maintenance tasks may lead to the accumulation of technical debt and compromise quality attributes of systems (e.g., understandability, extensibility, reliability, etc.). Therefore, this thesis aims at better understanding software maintenance in the context of architecture evolution. In detail, the research questions investigated in this thesis are: RQ1 – What is the state-of-the-art of maintenance-related tasks? RQ2 – How do software architectures change during maintenance and evolution?

Research method: To answer RQ1 and to analyse and characterize maintenance tasks, we conducted a systematic mapping study analysing the literature from January 2010 to November 2017. To answer RQ2 and to explore architecture evolution at system and component level, we conducted a replication of an empirical study that analyses the evolution path of several open source software systems. We analysed the evolution patterns between different types of version pairs (e.g., between major and minor releases). Our replication included more (and more recent) versions of software system included in the original study.

Findings and conclusions: The answer to RQ1 offers a) a hierarchical classification of software maintenance tasks, and b) a catalogue of characteristics of tasks (what do tasks impact [e.g., source code, documentation], when would they be performed, etc.). When characterising maintenance tasks based on the software development artefacts they impact, we found that architectural impact appears most frequently. Also, characterizing maintenance tasks based on their impact on quality attributes is another frequent way of characterising tasks. The answer to RQ2 not only confirmed findings from the original study and therefore strengthens the empirical evidence related to architectural evolution, but also identified reasons for why differences in evolution patterns exist. Furthermore, our replication showed that architectures do not stabilize over time, even if longer evolution paths are considered.