PerOlof Bengtsson

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.

Architecture level prediction of software maintenance

A method for the prediction of software maintainability during software architecture design is presented. The method takes: the requirement specification; the design of the architecture; expertise from software engineers; and, possibly, historical data as input and generates a prediction of the average effort for a maintenance task. Scenarios are used by the method to concretize the maintainability requirements and to analyze the architecture for the prediction of the maintainability. The method is formulated based on extensive experience in software architecture design and detailed design and exemplified using the design of software architecture for a haemo dialysis machine. Experiments for evaluation and validation of the method are ongoing and future work.

Scenario-based software architecture reengineering

The paper presents a method for reengineering software architectures. The method explicitly addresses the quality attributes of the software architecture. Assessment of quality attributes is performed primarily using scenarios. Design transformations are done to improve quality attributes that do not satisfy the requirements. Assessment and design transformation can be performed for several iterations until all requirements are met. To illustrate the method we use the reengineering of a prototypical measurement system into a domain-specific software architecture as an example.

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.

Haemo dialysis software architecture design experiences

In this paper we present the experiences and architecture from a research project conducted in cooperation with two industry partners. The goal of the project was to reengineer an existing system for haemo dialysis machines into a domain specific software architecture. Our main experiences are (1) architecture design is an iterative and incremental process, (2) software quality requires a context, (3) quality attribute assessment methods are too detailed for use during architectural design, (4) application domain concepts are not the best abstractions, (5) aesthetics guides the architect in finding potential weaknesses in the architecture, (6) it is extremely hard to decide when an architecture design is ready, and (7) documenting software architectures is an important problem. We also present the architecture and design rational to give a basis for our experiences. We evaluated the resulting architecture by implementing a prototype application.

Assessing optimal software architecture maintainability

Over the last decade, several authors have studied the maintainability of software architectures. In particular, the assessment of maintainability has received attention. However, even when one has a quantitative assessment of the maintainability of a software architecture, one still does not have any indication of the optimality of the software architecture with respect to this quality attribute. Typically, the software architect is supposed to judge the assessment result based on his or her personal experience. In this paper, we propose a technique for analysing the optimal maintainability of a software architecture based on a specified scenario profile. This technique allows software architects to analyse the maintainability of their software architecture with respect to the optimal maintainability. The technique is illustrated and evaluated using industrial cases.

An experiment on creating scenario profiles for software change

Scenario profiles are used increasingly often for the assessment of quality attributes during the architectural design of software systems. However, the definition of scenario profiles is subjective and no data is available on the effects of individuals on scenario profiles. In this paper we present the design, analysis and results of a controlled experiment on the effect of individuals on scenario profiles, so that others can replicate the experiments on other projects and people. Both scenario profiles created by individuals and by groups are studied. The findings from the experiment showed that groups with prepared members proved to be the best method for creating scenario profiles. Unprepared groups did not perform better than individuals when creating scenario profiles.

Object-oriented framework-based software development: problems and experiences

The claimed advantages of object-orien ted frameworks are, among others, increased reusability and reduced time to market for applications. Although several examples have shown these advantages to exist, there are problems and hindrances associated with frameworks that may not appear before their usage in real projects. In this paper a num ber of problems related to frameworks are described organised according to four categories, i.e. framework dev elopment, usage, composition and maintenance. For each category , the most relevant problems and experiences are presented.

Maintainability myth causes performance problems in SMP application

A challenge in software design is to find solutions that balance and optimize the quality attributes of the application. We present a case study of an application and the results of a design decision made on weak assumptions. The application has been assessed with respect to performance and maintainability. We present and evaluate an alternative design of a critical system component. Based on interviews with the involved designers we establish the design rationale. By analyzing the evaluation data of the two alternatives and the design rationale, we conclude that the design decision was based on a general assumption that an adaptable component design should increase the maintainability of the application. This case study is clearly a counter example to that assumption, and we therefore reject it as a myth. This study shows, however, that the myth is indeed responsible for the major performance problem in the application.