Architecture-level modifiability analysis (ALMA)

Abstract

Several studies have shown that 50–70% of the total lifecycle cost for a software system is spent on evolving the system. Organizations aim to reduce the cost of these adaptations, by addressing modifiability during the system’s development. The software architecture plays an important role in achieving this, but few methods for architecture-level modifiability analysis exist. Independently, the authors have been working on scenario-based software architecture analysis methods that focus exclusively on modifiability. Combining these methods led to architecture-level modifiability analysis (ALMA), a unified architecture-level analysis method that focuses on modifiability, distinguishes multiple analysis goals, has explicit assumptions and provides repeatable techniques for performing the steps. ALMA consists of five main steps, i.e. goal selection, software architecture description, change scenario elicitation, change scenario evaluation and interpretation. The method has been validated through its application in several cases, including software architectures at Ericsson Software Technology, DFDS Fraktarna, Althin Medical, the Dutch Department of Defense and the Dutch Tax and Customs Administration.

Introduction

The world around most software systems is constantly changing. This requires software systems to be modified several times after their initial development. A number of studies (Ecklund et al., 1996; Lientz and Swanson, 1980) have shown that 50–70% of the total lifecycle cost of a software system is spent on modifications after initial development. This high cost of software maintenance is caused by the incorporation of all kinds of anticipated and unanticipated changes after the system has been delivered.

Based on an understanding of the expected future evolution of the software system, design solutions can prepare for the future incorporation of new and changed requirements. In particular, the software architecture of the system affects the effort of making different types of modifications. One problem, however, is that the software architect has few means or techniques for determining whether the goal of high modifiability has been achieved by the design solutions.

One area of research addressing the above is software architecture analysis. In software architecture analysis, the software architecture of a system is analyzed to predict one or more quality attributes. Software architecture analysis method (SAAM) (Kazman et al., 1996) is a method for assessing software architectures with respect to different quality attributes. The principle of SAAM is to elicit scenarios from the stakeholders and explore their effects on the software architecture. SAAM provides few explicit techniques to be used in the different steps; it leaves much to the experience of the assessor. As such, the repeatability of the analysis may be compromized.

In their earlier work, the authors have independently worked on scenario-based software architecture analysis methods that focus exclusively on modifiability; Bengtsson and Bosch (1999a) have defined a method for predicting maintenance effort based on a system’s software architecture and Lassing et al. (1999a) defined a method with focus on identifying inflexibility at the software architecture level. Comparing these methods revealed similarities and differences (Lassing et al., 2001). They share a similar structure and are both based on scenarios, but the techniques used in the various steps differ. These differences can largely be explained from the methods’ founding assumptions. It was mainly the goals pursued by the analysis that influenced the assumptions. In combining the methods, these assumptions became explicit decisions and led to a unified architecture-level modifiability analysis method that; distinguishes multiple analysis goals, has visible assumptions and provides repeatable techniques for performing the steps. This method is called architecture-level modifiability analysis (ALMA).

ALMA consists of five main steps, i.e. goal selection, software architecture description, scenario elicitation, scenario evaluation and interpretation. We found that modifiability analysis generally has one of three goals, i.e. prediction of future maintenance cost, identification of system inflexibility and comparison of two or more alternative architectures. Depending on the goal, the method employs different techniques in some of the main steps.

The method has been applied successfully to a number of industrial cases, including software architectures at Ericsson Software Technology, DFDS Fraktarna, Althin Medical, the Dutch Department of Defense and the Dutch Tax and Customs Administration. The domains of these software architectures differ considerably, i.e. telecommunications, logistics, embedded systems and business information systems.

The remainder of the paper is organized as follows. In Section 2, we discuss the relationships between software architecture and modifiability. Section 3 discusses various approaches to software architecture analysis. Section 4 presents an overview of the main steps of ALMA. In 5 Case study I. Maintenance prediction, 6 Case study II. Risk assessment, 7 Case study III. Software architecture comparison, we show how to proceed for each of the goals and which techniques to use. These sections are illustrated using case studies that we performed using ALMA. Section 8 discusses the validation of the method. Finally, we conclude with a summary of the paper in Section 9.