N.H. Lassing

Architecture-level modifiability analysis (ALMA)

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 systems 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.

Experiences with ALMA: architecture-level modifiability analysis

Modifiability is an important quality for software systems, because a large part of the costs associated with these systems is spent on modifications. The effort, and therefore cost, that is required for these modifications is largely determined by a systems software architecture. Analysis of software architectures is therefore an important technique to achieve modifiability and reduce maintenance costs. However, few techniques for software architecture analysis currently exist. Based on our experiences with software architecture analysis of modifiability, we have developed ALMA, an architecture-level modifiability analysis method consisting of five steps. In this paper we report on our experiences with ALMA. We illustrate our experiences with examples from two case studies of software architecture analysis of modifiability. These case studies concern a system for mobile positioning at Ericsson Software Technology AB and a system for freight handling at DFDS Fraktarna. Our experiences are related to each step of the analysis process. In addition, we made some observations on software architecture analysis of modifiability in general.

How well can we predict changes at architecture design time

Two years ago, we analyzed the architecture of Sagitta 2000/SD, a large business information system being developed on behalf of Dutch Customs. We were in particular interested in assessing the capabilities of the system to accommodate future complex changes. We asked stakeholders to bring forward possible changes to the system, and next investigated how these changes would affect the software architecture. Since then, the system has been implemented and used, and actual modifications have been proposed and realized. We studied all 117 change requests submitted since our initial analysis. The present paper addresses how well we have been able to predict complex changes during our initial analysis, and how and to what extent the process to elicit and assess the impact of such changes might be improved. This study suggests that architecture analysis can be improved if we explicitly challenge the initial requirements. The study also hints at some fundamental limitations of this type of analysis: (1) fundamental modifiabilityrelated decisions need not be visible in the documentation available, (2) the actual evolution of a system remains, to a large extent, unpredictable and (3) some changes concern complex components, and this complexity might not be known at the architecture level, and/or be unavoidable.

VIEWPOINTS ON MODIFIABILITY

Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a systems quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modifiability analysis for business information systems we found that the views in current view models do not include all information required. In this paper we discuss the views we found useful for architecture level impact analysis of business information systems. They are illustrated using a case study we performed for the Dutch Tax and Customs Administration. We claim that when these views are required for architecture level impact analysis, the decisions they capture should also be considered during architecture development.

Flexibility of the ComBAD Architectures

Software architecture is nowadays regarded as the first step to achieving software quality. The architect’s main task is to translate quality requirements into a software architecture. An important step is to assess whether the architecture actually satisfies these quality requirements. The purpose of this paper is to explore which architectural choices support flexibility and how flexibility can be assessed. To that end, we explored the ComBAD architecture, whose main objective is flexibility. We investigated the architectural choices made and assessed whether flexibility was achieved. This will not only increase our insight into flexibility in general, but particularly into the assessment of this quality attribute. We use the term flexibility in the broadest sense of the word: to denote adaptability, portability and reusability. Adaptability can be regarded as flexibility in the narrow sense, portability as the flexibility to use a system in various technical environments, and reusability as the flexibility to reuse part of a system in another system.