During software development, a number of strategies are applied to ease a system's evolution, such as separation of concerns, information hiding, the application of design patterns. etc. Note. however. that the use of 'improved' software engineering technologies does not necessarily incur lower maintenance costs. For instance, Dekleva (1992) found no difference in maintenance costs between systems developed using development methodologies considered modern at that time, and those developed using a more traditional approach. Development methodologies were considered modern if they produced an implementation-independent logical representation of a system's function. Dekleva found that such modern development methodologies lead to changes in the allocation of maintenance time. Less time was spent on bug fixing, evaluating change requests. and the like, while more time was spent on implementing changes imposed by external factors and functional enhancements. Apparently, those modern methodologies enable the realization of significant enhancements. while traditional methodologies facilitate patching but discourage users to request major changes. We may conjecture a similar phenomenon. i.e. maintenance will be different but not necessarily cheaper, for architecture-based development versus non-architecture-based development. We have no empirical data to substantiate this conjecture, yet. 
Another strategy that may be employed to enhance the modifiability of a system is to assess the quality of interim results produced in the development process. In particular, the software architecture of the system may be assessed to determine the evolutionary capabilities of the system yet to be built. IEEE Standard 1471 (IEEE, 22000) defines software architecture as 'the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution'. The software architecture captures the first design decisions concerning the system. 


In an architecture-based development process, the result of these design decisions is represented in an architectural description. The main mechanisms to represent architectural descriptions are architecture description languages (ADLs) and view models. ADLs resemble module interconnection languages (MILS) (Prieto-Diaz and Neighbors, 1986). For an overview of 
ADLs, see (Medvidovic and Taylor.2000). 
View models are based on the principle that a software architecture cannot be captured in a single view. View models define a number of aspects of a software architecture that should be addressed in a software architecture description. e.g. (Kruchten. 1995) or (Soniet al., 1995). The views in both these models are represented as box-and-line diagrams. Their semantics are defined rather informally. A more recent version of the latter model uses LAML to define its semantics more precisely (Hofineister et al., 1999). 
Early design decisions captured in these models have a considerable impact on various quality attributes of the system. including its modifiability. It thus pays off to assess these quality attributes at this early stage. We have defined a generalized, adaptable method for architecture-level modifiability analysis (ALMA), which is based on the Software Architecture Analysis Method (SAAM) (Kazman et al., 1996). ALMA is a generalization of earlier work by the authors independently (Bengtsson and Bosch, 1999; Lassing et al.. 1999). In this paper we illustrate our experiences in using ALMA in two case studies. One case concerns a system developed by Ericsson Software Technology for positioning mobile telephones ,and the other case concerns a system for freight handling at DFDS Fraktarna. The observations made in this paper corroborate and strengthen our individual experiences in earlier studies( Bengtsson and Bosch. 1999; Lassing et al.. 1999). 


In Section 2. we sketch ALMA. The steps of this method are used in subsequent sections to structure our experiences and put them into perspective. Section 3 introduces the two cases. Our experiences are described In Section 4. In Section 5, we conclude with some summarizing. Statement. 
2. Overview of ALMA 
The method ALMA that we propose is based on change scenario:. A change scenario is a description of a specific event that may occur in the life cycle of a system and requires the system to be modified. Change scenarios resemble change cases, as defined by Ecklund et al. (19961. Both change scenarios and change cases capture potential change. Change cases are tied to methodologies supporting use cases; change scenarios do not require such a context. By exploring the effect of change scenarios on the software architecture, we can make predictions of the effort that is required to implement the changes once the system is built. This enables us to fudge the modifiability of the system that will be built with the software architecture under analysis. 
ALMA has a fixed structure. consisting of the following five steps: 
1. Set goal: determine the aim of the analysis. 
2. Describe : software architecture: give a description of the relevant parts of the software architecture 
3. Elicit change scenarios: find the set of relevant change scenarios. 
4. Evaluate change scenarios: determine the effect of the set of chance scenarios. 
5. Interpret the results: draw conclusions from the analysis results. 
The main difference between ALMA and SAAM (Kazman et al.. 1996) is that SAAM does rot explicitly address the need for differences in the techniques used as part of the analysis depending on the goal of the analysis. In ALMA this is an essential part and the need to clearly distinguish the goal of the analysis and to only have one goal for each analysis instance is emphasized. 


We will now give a brief overview of the steps. A more elaborate discussion of the full method is given in (Bengtsson et al.. 2000). Obviously, the above steps are not strictly separated when performing an analysis, but will often be iterated over in more or less subtle ways. 
2.1. Goal setting 
Architecture assessment must take place within the context of stakeholders' needs or requirements. The first step to take in the analysis is to set the analysis goal. The goal determines the type of results that will be delivered by the analysis. In addition, the goal influences the choice of techniques to he used in subsequent steps. Different goals ask for different techniques. With respect to modifiability, the following goals can be pursued: 
Risk assessment: finding types of changes for which the system a inflexible. we are then interested in scenarios that are particularly difficult to accomplish. In terms of effort and probability terms of effort and probability. we are then interested in the outliers. In software testing. it is sometimes stated that a test is only useful if it reveals a fault in the software. Pursuing this analogy, we may state that, in the risk-oriented approach to software architecture analysis, a change scenario is only useful if it exposes a risk. i.e. the changes it induces are difficult to accomplish. So, for risk assessment we look for a set of change scenarios that complies with the operational risk profile of the system. 
Maintenance cost prediction: estimating the cost of maintenance effort for the system in a given period. This estimate only concerns modifications caused by changes in the environment. in requirements, or in the functional specification. The cost incurred by bug fixing is excluded, since it is highly dependent upon factors not yet known at this point in time . In a very general sense ,we then use a maintenance cost function C average (the average cost per change scenario ) of the form where C(change,) denotes the effort or cost required to realize the ith change scenario, and p(change,) denotes the probability this scenario will occur, called scenario weight in ALMA. 


This approach presupposes that we are able to estimate the probability that a given change scenario will occur. If no such information is available, we assume a uniform distribution. In either case, we are interested in identifying those change scenarios that are likely to occur during the operational life of the system. I.e. we look for a set of change scenarios that matches the operational change profile of the system. 
Software architecture comparison: comparing two or more candidate software architectures to find the most appropriate one. The difference with the two aforementioned goals is that in comparison we make relative statements about a number of candidate software architectures. while with the other goals we make absolute statements about a single candidate .In comparison we are interested in finding the differences between the software architectures, so the scenario elicitation should be aimed at finding change scenarios that are treated differently by the candidates. 
2.2. Software architecture description 
After the goal of the analysis is set, the next stop is to create a description of the software architecture .To do so. the architecture designs used within the development team are an important source of information .In addition we may ask the architect(s) of the system for additional information. e.g. as component size estimates. or interviewing them for additional architecture information. 
2.3. Scenario elicitation 
One of the most important steps in modifiability analysis is the elicitation of a set of change scenarios. This set of change scenarios captures the events that stakeholders expect to occur in the future of the system. The main technique to elicit this set is to interview stakeholders, because they are in the best position to predict what may happen in the future of the system, in addition. they are able to judge the likelihood of the change scenarios obtained. This likelihood is important 


because unlikely scenarios are not relevant for the analysis and can be discarded. The aim of the scenario elicitation sup is to cone to a set of change scenarios that supports the goal that we have set for the analysis. 
2.4. Scenario evaluation 
After eliciting a set of change scenario ,we determine their effect on the system. To do so, we perform architecture-level impact analysis for each of the scenarios individually. This means that we determine the components of the system and components of other that have to be adapted to implement the change scenario. Also, components to be added or deleted identified. This task is typically performed in collaboration with members of the development team. 
2.5. Interpretation 
After we have determined the effect of the change scenarios, we can interpret these results to come to a conclusion about the system under analysis. The way the results are interpreted is again dependent on the goal of the analysis. 
2.5. Interpretation 
After we have determined the effect of the change scenarios, we can interpret these results to come to a conclusion about the system under analysis. The way the results are interpreted is again dependent on the goal of the analysis. 
If the goal of the analysis is risk assessment the results of the scenario evaluation are investigated to determine which change scenarios pose risks, i.e. for which scenarios the product of probability and costs a too high. The owner of the system should decide on the criteria 
for determining which values are still acceptable. When risks are found, various risk mitigation strategies are possible: avoidance (take measures to avoid that the scenario will occur or take action to limit their effect ,for instance, by use of code-generation tools), Transfer (e.g. choose another software architecture) and acceptance (accept the risks). 


If the goal of the analysis is to do maintenance prediction, the aim of this step is to Cone to an estimate of the amount of effort that is required for maintenance activities in the coming period. If the goal of the analysis is architecture comparison, we compare the results of the evaluation of the two sets of scenarios and choose the most appropriate candidate architecture . 
3 case descriptions 
In this section we introduce the two system used in the case studies. The goal of the case; studies was to conduct a software architecture analysis of modifiability on each of the two systems. We adopted the action research paradigm and look upon ourselves the role of being external analysts. 
The domains of the cases were very different, namely, business information systems and mobile telecommunications services systems. The differences between the domains (see Table 1) illustrate the scope of applicability of our method. In the remainder of this section we will introduce the two systems. 
3.1 Ericsson Mobile Positioning Center (MPC) 
The MPC is a system fur locating mobile phones in a cellular mobile phone network and reporting their geographical position. The network operators may implement their own services based on the positioning service. The positioning is not only intended for commercial services but also for locating emergency calls. 
The MPC client/server system consists of the MPC server and a Graphical User Interface (GUI) as a client. The MPC server handles all communication with external systems to retrieve positioning data and is also responsible for the processing of positioning data. The MPC server may also he divided into two units to adhere to the standard proposal that is under development. 


The MPC GUI is used for system administration, such as configuring for which mobile phones a user is allowed the position, and configuring alarm handling. The MPC system also generates billing information to allow the network operators to charge for the services they provide. 
The MPC is typically deployed as one unit at the network operators, but additional MPCs can be used in the network for redundancy. Each operator that offers positioning services needs an MPC system or the like in the network. 
The goal of the assessment was to predict the maintenance cost for the current system. Hence, we focused the elicitation of change scenarios on finding likely changes. Scenarios were collected by interviewing three stakeholders in the project. First we interviewed One of the software architects, then we interviewed a designer in the project. and finally we interviewed the operative 
product manager. Because the product is intended to serve several customers we had no direct access to the customer as a stakeholder in the assessment. However. one of the responsibilities of the operative product manager position is to stay informed of the market demands and issues.
翻译出来，留下联系方式，除支付稿酬外，另拜你为师。谢谢


543044405，我给你翻译出来,加我