Assessing Optimal Software Architecture Maintainability

Jan Bosch PerOlof Bengtsson

University of Groningen Blekinge Institute of Technology
Department of Computing Science Department of Software Engineering
PO Box 800, and Computer Science
NL9700AV Groningen, Netherlands S-372 25 Ronneby, Sweden
e-mail: [email protected] e-mail: [email protected]
www: http://www.cs.rug.nl/~bosch www: http://www.ipd.hk-r.se/pob

Abstract architecture defines the most fundamental design decisions

and the consequent decomposition of the system into its
Over the last decade, several authors have studied the main components and relations between these components.
maintainability of software architectures. In particular, the Within the community, we have become to understand the
assessment of maintainability has received attention. How- fact that the quality attributes of a software system are, to a
ever, even when one has a quantitative assessment of the large extent, constrained by its architecture. Consequently,
maintainability of a software architecture, one still does the quality requirements most central to the success of the
not have any indication of the optimality of the software software system should drive the design of the software
architecture with respect to this quality attribute. Typically, architecture. Unfortunately, the design of software
the software architect is supposed to judge the assessment architectures is often performed in a similar fashion as
result based on his or her personal experience. In this software design as a whole, i.e. as an experience-driven,
paper, we propose a technique for analysing the optimal implicit activity.
maintainability of a software architecture based on a speci- One of the main causes for the aforementioned
fied scenario profile. This technique allows software archi- problems is the fact that software engineers have few
tects to analyse the maintainability of their software techniques available for predicting the quality attributes of
architecture with respect to the optimal maintainability. a software system before the system itself is available.
The technique is illustrated and evaluated using industrial Typically, we measure the quality attributes, once the
cases. system has been put in operation. The difficulty to predict
quality attributes is particularly problematic at the software
architecture design level. During this phase, the first design
1. Introduction decisions are taken that are fundamental to the system, but
we have little means of evaluating these decisions until
Over the last decade, we have come to the understanding much later in the development process.
that the challenging task of the development of software Of course, this problem has not been ignored within the
systems no longer is to provide the required functionality, software architecture community and several examples of
but rather to fulfil the quality requirements of the system. software architecture analysis techniques exist. Typically,
Quality requirements, e.g. performance and we can categorize these techniques into architecture
maintainability, typically require explicit attention during oriented and quality attribute oriented techniques.
development in order to achieve the required levels. Architecture oriented analysis techniques can be further
Traditionally, software engineers have performed their decomposed into architect-based evaluation, such as
designs based on assumed relations between design architecture assessment teams [2], and stakeholder-based
solutions and quality requirements. Based on these assessment, e.g. SAAM [11]. Quality attribute oriented
relations, software design is often performed as an implicit, techniques can be decomposed into qualitative, typically
relatively ad-hoc process. Unfortunately, in our experience comparing two architectures for a quality attribute, and
the assumptions of software engineers are not always quantitative analysis techniques, e.g. predicting real-time
correct, e.g. [10]. behaviour [1] or our work on maintainability assessment
A second trend one can identify over the last decade is [3]. Typically, architecture-oriented assessment is
the increasing appreciation of the importance of the performed once the software architecture phase is finished,
architecture of a software system. The software

1
whereas quality attribute assessment is often performed as to consist of the structure, in terms of components and their
part of the iterative architecture design process. relations, but also the design constraints and rules, as well
Assuming the availability of quantitative assessments of their rationale.
the driving quality attributes of a software architecture, the The architecture of a software system constrains its
software architect will typically wonder “how good is quality attributes, as discussed in the introduction. This, in
this?”. In the case of maintainability, the quality attribute combination with the fact that the earliest design decisions
we focus on in this paper, this is often one of the core are the hardest to revoke, indicates the important of an
questions during design. Maintainability is defined as the explicit and objective software architecture design process.
ease with which we may perform maintenance tasks of In [6], we present a method for software architecture
different kinds. In practise maintainability is often design that employs explicit assessment of and design for
considered as related to the cost, or effort, it takes to the quality requirements of a software system. Although
perform the necessary maintenance tasks. For instance, this method is one instance, we believe that this method is
assume the result of the software architecture rather prototypical for general software architecture design.
maintainability assessment being that the maintenance Therefore, we describe the method briefly in this section to
effort will be equivalent to 10 full-time maintenance understand the role of quantitative maintainability
engineers per year, one would like to know whether an assessment in the context of software architecture design.
alternative architecture would allow for a substantially
lower maintenance cost. functionality-based requirement
The contribution of this paper is a solution to the architectural design specification

problem outlined above. We present a technique that,

based on a maintenance scenario profile and an impact
analysis of this profile on an architecture, calculates what application
architecture
the theoretically minimal maintenance effort would be for
a software system based on the available maintenance
scenario profile. Our technique is based on the results of
estimate
architecture
the scenario-based maintainability assessment which transformation
not OK quality
attributes
controls the different types of maintenance considered in
the assessment. In its current form the scenario impact
OK
analysis id only concerned with non-corrective QA-optimizing
solutions
maintenance, i.e. the maintenance tasks that are not
concerned with correcting bugs.
The remainder of this paper is organized as follows. In Figure 1. Software architecture design method
the next section, assessment and design of software
architectures is discussed. Section 3 discusses the The architecture design process, as shown in figure 1,
quantitative assessment of maintainability using change can be viewed as a function taking a requirement
scenarios and impact analysis. The technique for the specification that is taken as an input to the method and an
assessment of the optimal maintainability of a software architectural design that is generated as output. However,
system is presented in section 4, whereas the subsequent this function is not an automated process and considerable
section exemplifies the technique using an industrial case. effort and creativity from the involved software architects
Finally, related work is discussed in section 6 and the paper is required. The software architecture is used for the
is concluded in section 7. subsequent phases, i.e. detailed design, implementation and
evolution. The design process starts with a design of the
software architecture based on the functional requirements
2. Software Architecture Assessment and specified in the requirement specification. Although
Design software engineers generally will not design a system less
reliable or maintainable, the quality requirements are not
When discussing software architecture assessment and explicitly addressed at this stage. The result is a first
design, one has to start with defining software architecture. version of the application architecture design. This design
One frequently used definition is “The software is evaluated with respect to the quality requirements. Each
architecture of a program or computing system is the quality attribute is given an estimate in using a qualitative
structure or structures of the system, which comprise or quantitative assessment technique. The estimated quality
software components, the externally visible properties of attribute values are compared to the values in the
those components and the relationships among them” [2]. requirements specification. If all estimations are as good or
Some authors, e.g.[14], consider the software architecture

2
better than required, the architectural design process is operational, quality requirements, such as performance and
finished. Otherwise, the third stage is entered: architecture reliability. However, for other quality attributes, other
transformation. During this stage, the architecture is profiles can be used. For example, for specifying safety we
improved by selecting appropriate quality attribute- have used hazard scenarios and for maintainability we
optimizing transformations. Each set of transformations have used change scenarios.
(one or more) results in a new version of the architectural
design. This design is again evaluated and the same process 3.1.Scenario Profiles
is repeated, if necessary, until all quality requirements are
fulfilled or until the software engineer decides that no There are two ways of specifying profiles for quality
feasible solution exists. In the latter case, the software attributes, i.e. complete and the selected profiles. When
architect needs to renegotiate the requirements with the defining a complete profile for a quality attribute, the
customer. The transformations, i.e. quality attribute software engineer defines all relevant scenarios as part of
optimizing solutions, generally improve one or some the profile. For example, a usage profile for a relatively
quality attributes while they affect others negatively. small system may include all possible scenarios for using
In order to be able to determine whether the software the system. Based on this complete scenario set, the
architecture design process is finished and, if not, to be software engineer is able to perform an analysis of the
able to select transformations, assessment techniques are architecture for the studied quality attribute that, in a way,
required provide quantitative data concerning the relevant is complete since all possible cases are included.
quality attributes of the system. In the next section, we The alternative to complete profiles are selected
discuss a technique for assessing maintainability of profiles. Selected profiles are analogous to the random
software architectures. selection of sample sets from populations in statistical
experiments. Assuming a large population of possible
3. Assessing Maintainability scenarios, e.g. change scenarios, one selects individual
scenarios that are made part of the sample set. A complete
Quality requirements such as performance and sample set is what we, so far, have referred to as a scenario
maintainability are, in our experience, generally specified profile. Assuming the selection of scenarios has been done
rather weakly in industrial requirement specifications. In careful, one can assume that the profile represents an
some of our cooperation projects with industry, e.g. [4], the accurate representation of the scenario population.
initial requirement specification contained statements such Consequently, results from architecture assessment based
as “The maintainability of the system should be as good as on the profile, will provide accurate results for the system
possible” and “The performance should be satisfactory for as a whole and not just for the profile. Obviously, the
an average user”. Such subjective statements, although actual selection of scenarios is not random because these
well intended, are useless for the evaluation of software are created by a software architect. Therefore, we have to
architectures. spend explicit effort on making sure that the scenario
When one intends to treat the architecture of a software profile is as representative as possible. In [5], we present
system explicit in order be able to predict the quality three approaches to defining profiles, evaluate these using
attributes of the system early in the design process, one is an experiment and identify one of the three as the preferred
required to specify quality requirements in sufficient detail. technique for scenario profile specification.
One common characteristic for quality requirements is that
stating a required level without an associated context is 3.2.Maintainability Assessment
meaningless. For instance, also statements such as
“Performance = 20 transaction per second” or “The system A software system is developed according to a requirement
should be easy to maintain” are meaningless for specification, i.e. RS = {r 1, …, r p} where r i is a atomic
architecture evaluation. functional requirement or a quality requirement. Based on
One common denominator of most quality attribute this requirement specification, the software architect or
specification techniques is that some form of scenario architecture team designs a software architecture consisting
profile is used as part of the specification. A scenario of a set of components and relations between these
profile is a set of scenarios, generally with some relative components, i.e. SA = {C, R} . The set of components is
importance associated with each scenario. The profile used C = {c 1, …, c q} and each component c i = {I, cs, rt} has an
most often in object-oriented software development is the interface I, a code size cs and a requirement trace rt. The
usage profile, i.e. a set of usage scenarios that describe set of relations is R = {r 1, …, r r} , where each relation is
typical uses for the system. The usage profile can be used
as the basis for specifying a number of, primarily

3
r i = {c source, c dest, type} . Thus, relations are directed and have developed a technique that allows us to obtain this
one-to-one. information.
To assess the maintainability of a software architecture, To assess optimal maintainability, we make use of the
we make use of a maintenance profile consisting of a set of maintenance profile, MP, and the results of the impact
change scenarios, MP = {cs 1, …, cs s} , where each change analysis, IA. The technique is based on two assumptions.
scenario defines a set of changed and added requirements, First, the amount of code that needs to be developed or
cs i = {r c, 1, …, r c, t} . To perform the maintainability cahnged for a change scenario is relatively constant in size,
assessment, we assume three types of maintenance independent of the software architecture. Second, the main
activities, i.e. adding new components, adding new plug- difference in maintenance effort is due to the difference in
ins to existing components and changing existing productivity between different maintenance activities, i.e.
component code. Each of these activities has an associated P nc < Pp « P cc . For example, productivity being (>6x)
productivity measure, i.e. Pnc, Pp and Pcc, respectively. higher when writing new code (>250 LOC/Man-month in
Based on earlier research, e.g. [9] and [13], and our own C [13]) compared to modifying legacy code (1,7 LOC/
experience the productivity when developing new Man-day ~ <40 LOC/Man-month [9]). Note that these
components for an existing system is at least an order of productivity metrics include more than simply writing the
magnitude higher than changing the code of existing source statements.
components. Based on these assumptions, it is clear that an optimal
Once the maintenance profile is available, we can software architecture would allow for the incorporation of
perform impact analysis, i.e. analyse the changes to the all change scenarios by adding new components or, in the
software architecture and its components required to case of smaller change scenarios, by adding new plug-ins
incorporate the change scenarios. The result of the impact for existing components.
analysis process is a set of impact analyses, one for each Thus, a straightforward approach is to calculate the
change scenario, i.e. IA = {ia 1, …, ia u} , where ia1 is required effort assuming that all necessary changes can be
implemented as part of a new component. Below, the
defined as ia i = {CC i, NP i, NC i, R i} . Here, CCi is the,
equation calculating this is presented:
possibly empty, set of components that need to be changed
for incorporating the change scenario, including a size
estimate for the required change in lines of code,
CC i = {{c j, s j}, …} . NPi and NCi contain similar
Optimal maintenance effort
information for new plug-ins and new components,
respectively. Ri contains the new, changed and removed = ∑   ∑ sj +  ∑ sj +  ∑ sj  ⋅ Pnc
relations required for incorporating the change scenario. IA CC i NP i NC i
As a final step, once the impact analysis has been
performed, it is possible to determine the maintenance
effort required for the maintenance profile. This can be
calculated by summing up the efforts required for each (Equation 2)
change scenario. Below, the equation is presented:
Although this indeed calculates a lower boundary for
Maintenance effort the required maintenance effort, two issues remain
unresolved. First, especially for change scenarios requiring
= ∑   ∑ sj ⋅ Pcc +  ∑ sj ⋅ Pp +  ∑ sj ⋅ Pnc a relatively small change in terms of code size, it may not
IA CC i NP i NC i be reasonable to assume that these are mapped to
(Equation 1) components. Such change scenarios should be mapped to
new plug-ins and the associated productivity metrics
4. Assessing Optimal Maintainability should be used. The second issue is a more subtle one. The
straightforward model assumes that it is possible that for a
maintenance profile, all change scenarios can be mapped to
Once a quantitative assessment of maintainability has been
either a new component or a new plug-in. The question is,
performed, the next question a software architect typically
however, whether it is possible to define a software
will ask is: “Does this mean that the maintainability of my
architecture that supports this. Especially in the case where
architecture is good, reasonable or bad?”. Therefore, it is
different change scenarios address the same requirements,
important to be able to compare this to the optimal
it is unreasonable to assume that these change scenarios
maintainability for the scenario profile and the domain. We

4
  Pnc if independent & large scenario 
 
 P if indep d endent & small scenario 
Opt· maint. effort = ∑    ∑ s j +  ∑ s j +  ∑ s j  ⋅
p
        
IA  CC i NP i NC i ( P cc ⋅ ratio + P nc ⋅ ( 1 – ratio ) ) if interacting & large scenario
 
 ( P cc ⋅ ratio + P p ⋅ ( 1 – ratio ) ) if interacting & small scenario 

(Equation 3)
can be implemented independently, i.e. we experience operators introduce cellular telephony into an area with a
interaction of change scenarios. primary concern with establishing network capacity,
Based on the discussion above, we refine our technique geographic coverage and signing up customers. However,
for the assessment of optimal maintainability as follows. as subscriber and network growth level cost margins and
First, we categorize change scenarios as independent or other financial issues become more important, e.g. lost
interacting. A change scenario is independent if it affects revenues due to fraud.
existing requirements in the requirement specification that Fraud in cellular telecom can be divided into two main
are not affected by another change scenario that has a categories; subscriber fraud and cloning fraud. Subscriber
lower index number in the maintenance profile than the fraud is when subscribers use the services but does not pay
current scenario. This results in the situation that one their bills. The two main means to prevent this is to
change scenario can affect an existing requirement by perform subscriber background and credit history checks.
factoring it out as a separate component or plug-in, but all Cloning fraud means that a caller uses a false or stolen
subsequent change scenarios affecting the same subscriber identification in order to make calls without
requirement are considered to be interacting. paying, or to be anonymous. There exist various
An interacting change scenario affects one or more approaches to identify and stop cloning. The FCC system is
requirements in the requirement specification that are also a part of an anti-fraud system that counter-checks cloning
affected by change scenarios with a lower index number. fraud using real-time analysis of network traffic.
The effort required for this type of change scenarios is The FCC system is a commercial system and because of
calculated based on the ratio of interacting and independent this we cannot disclose the actual requirements posed on it.
requirements in the set affected by the change scenario. For the purpose of illustrating the method we will denote
Thus, if, for instance, two of five existing requirements for the requirements as R1, R2, etc. We are aware that this is a
a change scenario are interacting, then 40% of the total limitation of the illustration, but argue that the problem is
change size (in, e.g., lines of code) is calculated using the inherent to using a contemporary commercial system. The
Pcc productivity metric. The remainder is calculated by alternative would be to use a artificial example, or a retired
either using the Pnc or the Pp productivity metric. system, but it too has its limitations. In addition, because of
If the total change size of the independent part of the size restrictions we are not able to present all details in this
change scenario is less than the code size of the smallest illustration, e.g. the complete set of scenarios, or an
architectural component and/or less than half of the elaborate description of the impact analysis itself.
average code size of architectural components, then the Pp
productivity metric will be used to calculate the effort. 5.1.System Overview
Otherwise, the Pnc productivity metric is used.
Software in the switching network centres provides real-
Thus, for each type of change scenario, the required time surveillance of suspicious activities associated with a
effort can now be calculated. In equation 3, the alternatives call. The idea is to identify potential fraud calls and have
are presented. The term ‘ratio’ refers to the ratio between them terminated. However, one single indication is not
interacting and independent scenarios. The total enough for call termination.
maintenance effort can be calculated by summing up the The FCC system allows the cellular operator to specify
required effort for each change scenario. certain criteria for terminating a suspicious call. The
criteria that can be defined are the number of indications
5. Illustrating the Technique that has to be detected within a certain period of time
before any action is taken. It is possible to define special
The system that we will use to illustrate this technique is a handling of certain subscribers and indication types. For
cellular telecom fraud detection and management system the rest of this paper we will use the term ‘event’ to denote
called FCC that has been developed by Ericsson Software a fraud indication from the switching network.
Technology AB, Sweden. Usually, cellular telecom

5
 The events are continuously stored in files in the cellular FCC system sends a message to terminate to the switching
network. With certain time intervals or when the files network and the call is terminated. It is possible to define
contain a certain number of events these files are sent to the alternative actions, e.g. to send a notification to an operator
FCC. The FCC system stores the events and matches them console.
against pre-defined rules. When an event match a rule, the

Table 1. The Assessment Results of the Architecture

COMPONENT NEW COMPONENTS
AFFECTED
SCENARIO A B C D E F G H I J
REQUIREMENTS
1 4 1 3 5 1 2 5 2 .5
kLOC kLOC kLOC kLOC kLOC kLOC kLOC kLOC kLOC kLOC
1 .2 .5 .1 .1 .2 r2, r10
2 .3 .1 .2 r3
3 .5 .5 .8 .5
4 .2 .3 1 r4
5 .4 .5
6 .5 .5 .3 .3 1 r1,r11,r12
7 .1 .1 .1 .8 r5,r13,r14,r15
8 .2 .2 .4 .4 .1 .5 1 r1, r5, r16
9 .3 .4 .5 .2 .3 .3 r2, r17, r18
10 .3 1 r2
11 .2 .2 r5
12 .2 1 r8
13 .3 .5 .2 .3 r9

5.2.Architecture switching network. The components marked g-j are

components that were judged as potential new components
The FCC application consists of seven software during the assessment, and have been added to this figure
components, all executing on the same computer (see to illustrate how the fit in the rest of the architecture.
Figure 2). The majority of the components was designed
using object oriented techniques and implemented in C++.
Action

In one component a scripting language was used in

addition to C++. The components do not follow a DBClient
predifined component model but are rather collections of GUI d
related classes, a view of components that is common in f h Parser Data Base
industry [7]. TMOS is an Ericsson propriety off the shelf b
component that handles the interaction with the switching LoadSplitter
network. In this application it is used for collecting event g Event Queue
c
files from switches and other utility services. The Listener Listener
(a) collect events from switches via the TMOS component. a Splitter
TMOS

The TMOS component is a third party component and is i e

considered only as is, i.e. we cannot make changes to this Logger
j
component. The events are then propagated to one of the
executing Parser (b) threads. The parser extracts the event Figure 2. The Main software architecture
data from the event files and store then in the EventQueue
(c). Using predefined rules the DBClient (d) checks the
events in the Event Queue and stores the event data in the 5.3.The Scenario List
database. If an event triggers a rule, the Action (f)
component notified, who in turn executes the actions For the purpose of this study we asked a person related
associated with the rule, e.g. a call termination. Standard to the FCC project to prepare a list of the most likely
Unix scripts are used to send terminating messages to the changes to the FCC for the future. No other restrictions or

6
instructions were given. We present a selection of the scenarios that are used to evaluated the software
scenarios from the list we received and used in the architecture.
assessment below. An example of quality attribute oriented analysis
S1 New version of the switch software. Could lead to technique is the architecture trade-off analysis method
new event types and changed attributes of events. (ATAM) [12]. ATAM is the successor of SAAM. The
S2 Port to Windows NT. method defines attribute models that are used to identify
S5 Change of data base supplier. trade-off points in the architecture. These points are
S6 Port of graphical user interfaces to Java. potentially problematic areas in the architecture that, for
S8 Interactive termination. An operator must instance through redesign, can be neutralized.
acknowledge call termination. In [8], the authors present a software architecture
evaluation model that performs quality attribute evaluation
5.4.The Results of Scenario-Based Assessment based on the ISO/IEC 9126 draft standard. The approach
employs metric models to determine internal and external
The original architecture (figure 2) was assessed with the metrics of the system that can be used to evaluate the
assessment method described in section 3. The components quality requirements.
are marked in the figure 2. The results from the scenario Some specific quality attribute assessment techniques
impact analyses are presented in the table below (Table 1). have been developed. [1] discuss an approach to assess the
For this illustration we choose to set productivity for timing properties of software architectures using a global
changing (Pcc) to 40 LOC/Man-month [9], and based on rate-monotonic analysis (RMA) model that is composed
our assumption that writing plug-in code is somewhat from component RMA models. This allows the architect to
easier to do than modifying existing code, we choose to set early obtain information about the real-time behaviour of
Pp at 60 LOC/Man-Month. Based on the productivity for the architecture. In [3], we propose a technique for the
writing new code we choose to set Pnc at 250 LOC/Man- assessment of the maintainability of software architectures.
This technique was discussed in section 3.2. This
Month [13].
assessment technique is part of a software architecture
The maintainability effort on average per scenario of
design method [6].
this architecture according to the calculation in Equation 1
None of the discussed work proposes techniques for the
and based on the changes scenarios defined in section 5.3 is
assessment of optimal quality attribute levels, which is the
63 man-months. The optimal maintenance effort according
topic and contribution of this paper.
to the first equation (Equation 2) is 16 Man-Months on
average per scenario. The refined equation renders these
results instead (Equation 5) is 27 Man-Months on average 7. Conclusions
per scenario.
Concluding, the technique we present in this paper The work presented in this paper is motivated by the
allows the software architect to compare the assessed value increasing realization in the software engineering
(63 man-months per change scenario) with the optimal community of the importance of software architecture for
value (27 man-months per change scenario). Based on the fulfilling quality requirements. Traditionally, the software
difference between these figures, the architect may decide architecture design process is rather implicit and
whether this is acceptable or that additional effort has to be experience driven without a clear and explicit method. One
spent on improving on the software architecture for main reason for this is the lack of architecture assessment
maintainability. Since software architecture design requires techniques that quantify quality attributes of the software
trade-offs between different quality attributes, the architecture.
presented technique provides the software architect with In earlier work [3], we presented a scenario-based
more and better information in order to take well-founded technique for assessing the maintainability of a software
decisions. architecture. The technique employs a scenario profile,
used for performing impact analysis and calculates
6. Related Work maintainability based on this. Although very useful, the
software architect is typically interested in the optimal
maintainability level in order to understand how close the
The software architecture analysis method (SAAM) [11]
actual level is to the optimal level. In this paper, we
was among the first to address the assessment of software
presented a technique for assessing the optimal
architectures. SAAM employs stakeholder-based
maintainability for the software system, based on the
assessment to determine the suitability of the software
scenario profile and impact analysis. The technique
architecture for the system at hand. The stakeholders define
determines the required maintenance effort assuming that

7
all new and changed requirements can be implemented by [5] P. Bengtsson and Jan Bosch, “An Experiment on Creating
adding new components or plug-ins to the system. Scenario Profiles for Software Change”, Annals of Software
We have illustrated and exemplified the technique by Engineering, Vol. 9, May 2000.
using an industrial case from the telecom domain and
[6] J. Bosch, Design and Use of Software Architectures: Adopting
found that, according to the method proposed in this paper,
and Evolving a Product Line Approach, Pearson Education
the optimal average effort per scenario is about half of the
(Addison-Wesley & ACM Press), ISBN 0-201-67494-7, May
same average effort per scenario of the current architecture. 2000.
In addition, the most optimistic calculation (Equation 2)
suggested only a quarter of the average effort compared to [7] J. Bosch, ‘Evolution and Composition of Reusable Assets in
the current architecture. This, however, seem Product-Line Architectures: A Case Study. Proceedings of the
unrealistically optimistic. First Working IFIP Conference on Software Architecture,
In the future we intend to continue with the validation February 1999.
and refinement of the technique by applying it to additional
industrial cases and investigating the validity of the [8] J.C. Duenas, W.L. de Oliveira, J.A. de la Puente, “A Software
assumptions made. In addition, we are interested in Architecture Evaluation Model,” Proceedings of the Second
International ESPRIT ARES Workshop on Development and
investigating whether the technique can be applied to other
Evolution of Software Architectures for Product Families, F. vd.
quality attributes as well.
Linden (editor), LNCS 1429, pp. 148-157, 1998.

Acknowledgements [9] J. E. Henry, J.P. Cain, "A Quantitative Comparison of

Perfective and Corrective Software Maintenance", Journal of
We thank Ericsson Software Technology for providing us
Software Maintenance: Research and Practice, John Wiley &
with the FCC case and allowing us to publish these results. Sons, Vol 9, pp. 281-297, 1997

References [10] Daniel Häggander and Per-Olof Bengtsson, Jan Bosch and
Lars Lundberg, Maintainability Myth Causes Performance
[1] A. Alonso, M. Garcia-Valls, J.A. de la Puente, “Assessment of
Problems in Parallel Applications, Proceedings of IASTED 3rd
Timing Properties of Family Products,” Proceedings of the
International Conference on Software Engineering and
Second International ESPRIT ARES Workshop on Development
Applications, pp. 288-294, October 1999.
and Evolution of Software Architectures for Product Families, F.
vd. Linden (editor), LNCS 1429, pp. 161-169, 1998.
[11] R. Kazman, L. Bass, G. Abowd, M. Webb, ‘SAAM: A
Method for Analyzing the Properties of Software Architectures,’
[2] L. Bass, P. Clements, R. Kazman, ‘Software Architecture In
Proceedings of the 16th International Conference on Software
Practise’, Addison Wesley, 1998.
Engineering, pp. 81-90, 1994.
[3] P. Bentsson, J. Bosch, ‘Architecture Level Prediction of
[12] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson,
Software Maintenance’, The 3rd European Conference on
J. Carriere, ‘The Architecture Tradeoff Analysis Method,’
Software Maintenance and Reengineering (CSMR'99), pp. 139-
Proceedings of ICECCS’98, (Monterey, CA), August 1998.
147, 1999.
[13] K. D. Maxwell, L. Van Wassenhove, S. Dutta, "Software
[4] P. Bengtsson, J. Bosch, ‘Haemo Dialsis Software Architecture
Development Productivity of European Space, Military, and
Design Experiences’, in Proceedings of International Conference
Industrial Applications", IEEE Transactions on Software
on Software Engineering (ICSE’99), ACM Press, New York,
Engineering, Vol. 22, No. 10: OCTOBER 1996, pp. 706-718
pp. 516-525, 1999.
[14] D.E. Perry and A.L. Wolf, “Foundations for the Study of
Software Architecture”, ACM SIGSOFT Software Engineering
Notes, pp. 40-52, 1992.