Analyzing Software Evolvability of an Industrial Automation Control

System: A Case Study

Hongyu Pei Breivold1, Ivica Crnkovic2, Rikard Land2, Magnus Larsson1
1
ABB Corporate Research, Industrial Software Systems, 721 78 Västerås, Sweden
{hongyu.pei-breivold, magnus.larsson}@se.abb.com
2Mälardalen University, 721 23 Västerås, Sweden

{ivica.crnkovic, rikard.land}@mdh.se
respect to evolvability; and (ii) perform architectural
Abstract transformation. It is generally acknowledged that the
Evolution of software systems is characterized by software’s architecture holds a key to the possibility to
inevitable changes of software and increasing software implement changes in an efficient manner [1].
complexity, which in turn may lead to huge Therefore, in this paper, we analyze evolvability at the
maintenance and development costs. For long-lived architecture level and identify the evolvability
systems, there is a need to address evolvability (i.e. a subcharacteristics of interest in an industrial case study,
system’s ability to easily accommodate changes) where a large automation control system at ABB was
explicitly in the requirements and early design phases, evolved from a monolithic architecture towards a
and maintain it during the entire lifecycle. This paper product line. We present our experiences of the
describes our work in analyzing and improving the development of the product line architecture in the
evolvability of an industrial automation control system, form of a general method, which we have constructed
and presents 1) evolvability subcharacteristics based from data in the manner of grounded theory research
on the problems in the case and available literature; 2) [25]. In addition, the risk of bias has been further
a structured method for analyzing evolvability at the decreased through the involvement of other researchers
architectural level - the ARchitecture Evolvability in the analysis of the experiences.
Analysis (AREA) method. This paper includes also the The remainder of this paper is structured as follows.
main analysis results and our observations during the Section 2 describes the context of the case study.
evolvability analysis process in the case study. The Section 3 presents our architecture evolvability analysis
evolvability subcharacteristics and the method should method - AREA. Section 4 presents the case study, in
be generally applicable, and they are being validated which the method was applied to analyze, evaluate and
within another domain at the time of writing. improve the software architecture of the automation
1. Introduction controller software system. Section 5 discusses the
Studies indicate that more than 50% of the total life experiences we gained through the case study. Section
cycle cost is spent after the initial development [18]. 6 reviews related work. Section 7 concludes the paper.
Therefore, it becomes essential to cost-effectively carry 2. Context of the Case
out software evolution. In order to prolong the This section presents the case to motivate
productive life of a software system, the need to evolvability analysis and describe seven evolvability
explicitly address software evolvability is becoming subcharacteristics from the case perspective.
recognized [6]. There are examples of industrial
systems with a lifetime of 20-30 years. These systems
2.1 Motivating Evolvability Analysis
are subject to and may undergo a substantial amount of The case study was based on a large automation
evolutionary changes, e.g. shifting business and control system at ABB and focused on the latest
organizational goals, software technology changes, generation of the controller. The controller software
software systems merge due to organizational changes consists of more than three million lines of code written
[16], demands for distributed development, system in C/C++ and uses a complex threading model, with
migration to product line architecture, etc. The support for a variety of different applications and
evolution problems we have observed came from devices. It has grown in size and complexity, as new
various cases in industrial context, where evolvability features and solutions have been added to enhance
was identified as a very important quality attribute that functionality and to support new hardware, such as
must be maintained. In order to preserve and improve devices, I/O boards and production equipment. Such a
evolvability, we need to (i) analyze the system with complex system is difficult to maintain. It is also
important and considerably more difficult to evolve. must have the capability to be analyzed and explored in
Due to different measures such as organizational and terms of the impact to the software by introducing a
lifecycle process improvements, the system keeps the change.
maintainability, but the evolvability becomes more Architectural Integrity A strategy for communicating
difficult since the increased complexity in turn leads to architectural decisions that we found out from various
decreased flexibility, resulting in problems to add new case studies was to appoint members of the core
features. Consequently, it becomes costly to adapt to architecture team as technical leaders in the
new market demands and penetrate new markets. development projects. However, this strategy although
Our particular system is delivered as a single helpful to certain extent, did not completely prevent
monolithic software package, which consists of various developers from insufficient understanding and/or
software applications developed by distributed misunderstanding of the initial architectural decisions,
development teams. These applications aim for specific resulting in unconscious violation of architectural
tasks in painting, welding, gluing, machine tending and conformance. This may lead to evolvability
palletizing, etc. To keep the integration and delivery degradation in the long run. Therefore, it is important
process efficient, the initial architectural decision was to record rationale for each design decision, strategy
to keep the deployment artifact monolithic. The and architectural solution.
complete set of functionality and services is present in Changeability Due to the monolithic characteristic of
every product even though not everything is required in the controller software, modifications in certain parts of
the specific product. As the system grew, it became the software package lead to some ripple effects, and
more difficult to ensure that the modifications of requires recompiling, reintegrating and retesting of the
specific application software do not affect the quality whole system. This results in inflexibility of patching
of other parts of the software system. As a result, it and customers have to wait for a new release even in
became difficult and time-consuming to modify case of corrective maintenance and configuration
software artifacts, integrate and test products. To changes. Therefore, it is strongly required that the
continue exploiting the substantial software investment software system must have the ease and capability to be
made and to continuously improve the system for changed without negative implications or with
longer productive lifetime, it has become essential to controlled implications to the other parts of the
explicitly address evolvability, since software software system.
evolvability is a fundamental element for increasing Portability The current controller software supports
strategic and economic value of the software [28]. The VxWorks and Microsoft Windows NT. There is a need
inability to effectively and reliably evolve software of openness for choosing among different operating
systems means loss of business opportunities [2]. system (OS) vendors, e.g. Linux and Windows CE, and
2.2 Evolvability Subcharacteristics from Case possibly new OS in the future.
Perspective Extensibility The current controller software supports
around 20 different applications that are developed by
In our previous work [21], we have identified
several distributed development centers around the
subcharacteristics that are of primary importance for an
world. To adapt to the increased customer focus on
evolvable software system. Definitions and detailed
specific applications and to enable establishment of
explanations of evolvability subcharacteristics are
new market segments, the controller, like any other
provided in [21]. The derivation of evolvability
software systems, must constantly raise the service
subcharacteristics are based on survey and analysis of
level through supporting more functionality and
literatures (see related work section), problems we have
providing more features [4], while keeping some
observed and experiences from several earlier case
important extra-functional properties, such as
studies. We do not exclude the possibilities that other
performance, or reliability.
domains or cases might have slightly extended set of
Testability The controller software exposed huge
subcharacteristics. Each subcharacteristic is explained
number of public interfaces which resulted in
below in conjunction with the case.
tremendous time merely on interface tests. One task
Analyzability The release frequency of the controller
was therefore to reduce the public interfaces to around
software is twice a year, with around 40 various new
10% of the original public interfaces. Besides, due to
major requirements that need to be implemented in
the monolithic characteristic, error corrections in one
each release. These requirements have impact on
part of the software requires retesting of the whole
different attributes of the system, and the possible
system. One issue was therefore to investigate the
impact must be analyzed before the implementation of
feasibility of testing only modified parts.
the requirements. This requires that the software system
Domain- specific attributes The controller software This phase focuses on the identification and
has critical real-time calculation demands. It is also improvement of the components that need to be
expected to reduce the base software code size and refactored.
runtime footprint. Step 2.1: Extract architectural constructs related to the
3. Overview of the ARchitecture respective identified requirement.
Evolvability Analysis (AREA) Method We mainly focus on architectural constructs that are
related to each identified requirement. In order for the
The steps that we performed in the case are divided architecture to allow changes in the software without
into three main phases as shown in Figure 1. compromising software integrity and to evolve in a
Phase 1: Analyze the implications of change stimuli on controlled way, documentation of architectural
software architecture. decisions and their rationale play a key role.
This phase analyzes the architecture for evolution and Step 2.2: Identify refactoring components for each
understands the impact of change stimuli on the current identified requirement.
architecture. Software evolvability concerns both In this step, we identify the components that need
business and technical issues [29], since the stimuli of refactoring in order to fulfill the prioritized
changes come from both perspectives, e.g. requirements.
environment, organization, process, technology and Step 2.3: Identify and assess potential refactoring
stakeholders’ needs. These change stimuli have impact solutions from technical and business perspectives.
on the software system in terms of software structures Refactoring solutions are identified and design
and/or functionality. decisions are taken in order to fulfill the requirements
Step 1.1: Identify potential requirements in the derived from the first phase. The change propagation of
software architecture. the effect of refactoring need to be considered and
Any change stimulus results in a collection of potential provided as an input to the business assessment,
requirements that the software architecture needs to estimating the cost and effort on applying refactorings.
adapt to. The aim of this step is to extract these In some cases, the refactoring of a certain component is
requirements that are essential for software architecture straightforward if we know how to refactor with only
enhancement so as to cost-effectively accommodate to local impact. When the implementation is uncertain
change stimuli. Architecture workshops can be and might affect several subsystems or modules,
conducted, where the stakeholders discuss and identify prototypes need to be made to investigate the feasibility
the potential architecture requirements. Each of potential solutions as well as the estimation of
requirement is concretized with a collection of implementation workload. As part of this step, an
identified refined activities. Afterwards, each identified assessment regarding the compatibility of the
requirement must be checked against the evolvability refactoring solutions and rationale with earlier made
subcharacteristics so as to ensure the consistency and design decisions is made to ensure architectural
completeness. integrity.
Step 1.2: Prioritize potential requirements in the Step 2.4: Define test cases.
software architecture. New test cases that cover the affected component,
In order to establish a basis for common understanding modules or subsystems need to be identified.
of the architecture requirements among stakeholders Phase 3: Finalize the evaluation.
within the organization, all the potential requirements In this phase, the previous results are incorporated,
identified from the first step need to be prioritized. We analyzed and structured into a collection of documents.
do not propose any general criteria for requirement Step 3.1: Analyze and present evaluation results.
prioritization that apply to all the software systems The evaluation results include (i) the identified and
evolution, since the criteria might be different from prioritized requirements on the software architecture;
case to case depending on factors such as development (ii) the identified components/modules that need to be
and organizational constraints, the probability of refactored for enhancement or adaptation; (iii)
potential requirements becoming mandatory refactoring investigation documentation which
requirements that the architecture must adapt to, etc. describes the current situation, rationale and solutions
Phase 2: Analyze and prepare the software to each identified candidate that need to be refactored,
architecture to accommodate change stimuli and including estimated workload; (iv) test scenarios; and
potential future changes. (v) impact analysis on evolvability.
 Figure 1. The steps of the ARchitecture Evolvability Analysis (AREA) method

identified from the change stimuli. The refined

4. Applying the AREA Method
activities for each requirement are presented as well.
The main focus of the analysis in our case was to R1. Improved modularization of architecture.
assess how well the architecture would support a) Enable the separation of layers within the
potential forthcoming requirements and understand controller software: (i) a kernel which comprises
their impact. Through the analysis process, we of components that must be included by all
identified potential flaws and defined an evolution path application variants; (ii) common extensions which
of the software system. The identification and analysis are available to and can be selected by all
of the architectural requirements was performed by the application variants; and (iii) application
architecture core team which consists of 6-7 persons. It extensions which are only available to specific
was a continuous maturation process from the first application variants.
vision to concrete activities that took approximately b) Investigate dependencies between the existing
one calendar year including analysis, identification of extensions.
architecture evolution path and partial refactoring. 2-3 R2. Reduced architecture complexity.
persons from the architecture core team identified the a) Define interfaces and reduce public interface calls.
refactoring solution proposals for the components in b) Add support for task isolation and task
the Basic Services subsystem. These proposals were management.
discussed with the main technical responsible persons R3. Enable distributed development of extensions with
and architects, documented as evolution path for the minimum dependency.
architecture and transferred further to the a) Build the application-specific extensions on top of
implementation teams. the base software (kernel and common extensions)
4.1 Phase 1 - Step 1.1: Identify potential without the need of modification to the internal
requirements on the software architecture base source code.
The change stimuli to the controller software came b) Package the base software into SDK (Software
from the following emerging critical issues related to Development Kit), which provides necessary
software evolution: (a) time-to-market requirements, interfaces, tools and documentation to support
such as building new products for dedicated market distributed application development and separate
within short time; (b) improvement of software system release cycles of the SDK and application-specific
evolvability; and (c) increased ease and flexibility of extensions.
distributed development of products in combination R4. Improved portability.
with the diversity of application variants. We list below a) Investigate portability across target operating
the main potential architecture requirements that were system platforms and across hardware platforms.
R5. Impact on product development process. 4.3 Phase 2 - Step 2.1: Extract architectural
a) Investigate the implications of software constructs related to the respective identified
restructuring on product integration and testing. requirement
R6. Minimized software code size and runtime
Over years of development, a lot of functionality has
footprint.
been added to the system to support new requirements.
a) Investigate enabling mechanisms, e.g. properly
It becomes easy to unconsciously violate the original
partitioning functionality.
good design decisions. To prevent this, it is important
The above architecture requirements should be to extract design decisions and rationale through
checked against the evolvability subcharacteristics to documentation of architectural constructs. In this way,
justify whether the realization of each requirement potential architectural flaws can be discovered. For
would lead to an improvement of the subcharacteristics instance, in the case study, some implementation
(or possibly a decrease, which would then require a violations were discovered, such as improper use of
tradeoff decision), as summarized in Table 1. Besides, conditional compilation in case of environment
the choice of component refactoring and changes, direct access to OS native APIs, etc.
implementation solution proposals for fulfilling each Additional efforts have been put to provide training,
requirement might cause tradeoffs against some other guidelines/rules and code examples for software
subcharacteristics, as detailed in section 4.7. developers in writing code and using tactics that enable
Table 1. Mapping between evolvability subcharacteristics the achievement of a certain quality characteristic. We
and architecture requirements exemplify with R3 and extract architectural constructs
Subcharacteristics Requirements in form of the original coarse-grained architecture as
Analyzability R1. Improved modularization of architecture. depicted in Figure 2.
R2. Reduced architecture complexity.
Architectural not related to any particular architectural
Integrity requirement, but rather to whether the
architectural choices and rationale for
handling these requirements are documented
Changeability R1. Improved modularization of architecture.
R2. Reduced architecture complexity.
Extensibility R3. Enable distributed development of
extensions with minimum dependency.
Portability R4. Improved portability.
Testability R5. Impact on product development process.
Domain-specific R6. Minimized software code size and
attributes runtime footprint.

4.2 Phase 1 - Step 1.2: Prioritize potential

requirements on the software architecture Figure 2. A conceptual view of the original software
architecture
Due to the monolithic characteristics of the The lower layer provides an interface to the upper
architecture, the individual products are burdened with layer and allows the source code of the upper layer to
functionalities and components that are not necessary be used on different hardware platforms and operating
for the specific individual products. Accordingly, the systems. The main problem with this software
main idea was to apply the product line approach, architecture was the existence of tight coupling among
transform the existing system into reusable components some components that reside in different layers. This
that can form the core of the product-line led to additional work required at a lower level to
infrastructure, and separate application-specific modify some existing functionality and add support for
extensions from the base software. With the new functionality in various applications. For instance,
consideration of not disrupting the ongoing the system is required to perform certain tasks during
development projects, the criteria for requirement start-up and shutdown in the controller. Some routines
prioritization were: (i) enable building of existing types for handling such tasks had to be hard-coded, i.e. the
of extensions after refactoring and architecture application developers had to edit in the source code of
restructuring; (ii) enable new extensions and simplify e.g. Support Services subsystem in the lower layer,
interfaces that are difficult to understand and may have which is developed by another group of developers.
negative effects on implementing new extensions. Accordingly, source code updates had to be done not
Based on these criteria, R1, R2 and R3 were prioritized only on the application level, but through several
potential architectural requirements. layers, several subsystems and components.
Recompilation of the whole code base was required. rationale of the solution proposal and architectural
This required that application developers need to have implications of the deployment of the component on
a thorough knowledge of the complete source code. It quality attributes; and (v) estimated workload: the
also constituted a bottleneck in the effort to enable estimated workload for implementation and
distributed application development. verification.
4.4 Phase 2 - Step 2.2: Identify refactoring 4.5.1 Inter-Process Communication. This component
components for each identified requirement belongs to Basic Services subsystem and it includes
mechanisms that allow communication between
To cope with the architectural problems identified in
processes, such as remote procedure calls, message
the previous step, the strategy of separate concerns
passing and shared data.
need to be applied to isolate the effect of changes to
Problem Description. All the slot names and slot IDs
parts of the system [11], i.e. separate the global
that are used by the kernel and extensions are defined
functions from the hardware, and separate application-
in a C header file in the system. The developers have to
specific functions from generic and basic functions as
edit this file to register their slot name and slot ID, and
illustrated in Figure 3.
recompile. Afterwards, both the slot name and slot ID
have to be specified in the startup command file for
thread creation. There is no dynamic allocation of
connection slot.
Requirements. The refactoring of this component is
related to R3. It should be possible to define and use
IPC slots in common extensions and application
extensions without the need to edit the source code of
the base software and recompile. The mechanism for
using IPC from extensions must be available also in the
kernel, to facilitate move of components from kernel to
extensions in the future.
Improvement Solution. The slot ID for extension
Figure 3. A revised conceptual view of the software clients should not be booked in the header file.
architecture Extensions should not hook a static slot ID in the
Accordingly, some components need to be adapted startup command file. The command attribute dynamic
and reorganized to enable the architecture slot ID should be used instead. The IPC connection for
restructuring, e.g. some components within the low- extension clients will be established dynamically
level Basic Services subsystem for resource allocations, through the ipc_connect function as shown in
including semaphore ID management component, Figure 4. It will return a connection slot ID when no
memory allocation management component to separate predefined slot ID is given. An internal error will be
functionality from resource management and to achieve logged at startup if a duplicate slot name is used.
the build- and development-independency between the
kernel and extensions.
4.5 Phase 2 - Step 2.3: Identify and assess
potential refactoring solutions from technical
and business perspectives
Due to space limitations and company
confidentiality, we exemplify with one component
example (inter-process communication component) that
needed to be refactored to represent and illustrate for
the many various discussions and solutions that
occurred during the analysis. We discuss in terms of Figure 4. The inter-communication component after
the following views: (i) problem description: the refactoring
problem and disadvantages of the original design of the Rationale and Architectural Consequences. The
component; (ii) requirements: the new requirements revised IPC component provides efficient resource
that the component needs to fulfill; (iii) improvement booking for inter-process communication and enables
solution: the architectural solution to design problems; encapsulation of IPC facilities. Accordingly,
(iv) rationale and architectural consequences: the distributed development of extensions utilizing IPC
functionality is facilitated. The use of dynamic inter- 5. Reflections
process communication connections addressed resource This section summarizes our observations and
limitations for IPC connection. In this way, limited IPC experiences of applying AREA.
resources are used only when the processes are
communicating. However, the use of IPC mechanisms
5.1 Experiences
requires resources, which are limited on a real-time By applying AREA method, we have improved the
operating system. Therefore, the overheads due to capability in being able to on forehand understand and
resource description processing may be the offset analyze systematically the impact of a change stimulus.
against efficiency [22], since the overall real-time This, in turn, helps us to prolong the evolution stage
performance may be degraded if the cost of creating [2]. Besides, we list below two observations that
and destroying IPC connections is too high. concern visible improvements in the organization. They
Estimated Workload. It was estimated around 2 man were perceived and informally reported by the
weeks which includes the IPC component refactoring stakeholders themselves.
and moving IPC client from kernel to extension. Documentation of architecture is improved,
including the architecture’s evolution path.
4.6 Phase 2 - Step 2.4: Define test cases
Architecture transformation and suggestions for
The corresponding test cases were derived based on refactoring solutions were part of the analysis process.
the selected improvement solution proposal to each This was performed by the architecture core team. As a
component that needed refactoring. For instance, the result of the analysis and refactoring activities, the
architectural test cases for the IPC component are given documentation of design and implementation solution
by the ThreadCreation class creating dynamic slot ID, proposals has been improved. The final refactoring
as shown in Figure 5. analysis investigation report was distributed for
inspection and was approved after a few iterations.
This document served as an input and blueprint to the
implementation teams. In this way, the architecture
core team and implementation teams shared the same
view on the evolution path of the software architecture.
High-level business goals lead to architectural
requirements. In the case study, the potential
requirements on the architecture were derived from the
Figure 5. Test cases for IPC management component high-level business goals through the first phase, where
4.7 Phase 3 - Step 3.1: Present evaluation the potential requirements on the architecture were
results identified based on the change stimuli. Such derivation
In this step, the implications of the potential provides an understanding on how the intended
improvement strategies and evolution path of the software system and its evolving artifacts reflect and
software architecture are analyzed with respect to the contribute to the strategic goals. Together with the
evolvability subcharacteristics as illustrated in Table 2. documentation of architecture evolution path, it would
Table 2. Impacts of the IPC component on evolvability enrich architectural models and facilitate the
subcharacteristics (+ positive impact, - negative impact) traceability of software architecture evolution back to
the various business constraints and assumptions [15].
Consequences of changing IPC component
5.2 Suggestions
Analyzability – due to less possibility of static analysis since
definitions are defined dynamically Due to continuously changing requirements and
Architectural + due to documentation of specific requirements, evolutions of new technologies, the software
Integrity architectural solutions and consequences architecture needs to be evolvable to cost-effectively
Changeability + due to the dynamism which makes it easier to
introduce and deploy new slots
accommodate changes. Thus, we suggest routine
Portability + due to improved abstraction of Application evolvability analysis that should be applied as an
Programming Interfaces (APIs) for IPC integral part during the whole software lifecycle.
Extensibility + due to encapsulation of IPC facilities and Another remark is that the process of making the
dynamic deployment impact analysis of component refactoring in terms of
Testability No impact
Domain- + resource limitation issue is handled through
estimated workload was not an easy task. One principle
specific dynamic IPC connection that was applied during the component refactoring
attributes – due to introduced dynamism, the system process was to preserve the external behavior of the
performance could be slightly reduced system despite the number of changes to the code. This
required a comprehensive understanding of the The method made the architecture requirements,
dependencies among different components within corresponding design decisions, rationale and
different subsystems. Good tool support that assists in architecture evolution path more explicit, better
impact analysis of ripple effects would be helpful. founded and documented, and the resulting
documentation of refactoring improvement proposals
6. Related Works
was widely accepted by the involved stakeholders. The
To evaluate evolvability, Ramil and Lehman analysis results served as an input and blueprint to the
proposed metrics based on implementation change logs implementation teams. We want to point out that the
[23] and computation of metrics using the number of commitment from the organization to perform such a
modules in a software system [17]. Another set of total restructuring of a large system signifies the
metrics is based on software life span and software size importance of software evolvability.
[27]. In [26], a framework of process-oriented metrics The AREA method is presently being applied in
for software evolvability was proposed to intuitively another case within ABB, through which we plan to
develop evolvability metrics and to trace the metrics further refine and validate the method. Another aspect
back to the evolvability requirements based on the NFR that we are considering is to apply the method to
framework [5]. However, they do not explicitly address address evolvability explicitly in the early design phase
the evolvability analysis at architectural level. The best of a new development effort, since software
known quality models e.g. McCall [20], Boehm [3], architecture that is capable of accommodating change
FURPS [10], ISO 9126 [12] and Dromey [9], do not must be specifically designed for change [13].
explicitly address evolvability. An approach was
described in [19] to measure software architecture’s References
[1] Bass, L., Clements, P., Kazman, R.: Software
quality characteristics through identified key use cases,
Architecture in Practice. Addison- Wesley. (2003)
based on the customization of the ISO 9126 standard. [2] Bennett, K., Rajlich, V.: Software Maintenance and
An ontological basis which allows for the formal Evolution: a Roadmap. The Future of Software Engineering,
definition of a system and its change at the architectural Anthony Finkelstein (Ed.), ACM Press. (2000)
level is presented in [24]. [3] Boehm, B.W. et al. : Characteristics of Software Quality.
Kolb et al. [14] presented a case study in refactoring Amsterdam. North-Holland. (1978)
an existing software component for reuse in a product [4] Bosch, J.: Design and Use of Software Architectures –
line using the PuLSE approach. Experiences of using Adopting and Evolving a Product-Line Approach. Addison-
various assessment techniques for software architecture Wesley. (2000)
[5] Chung, L. et al.: Non-Functional Requirements in
evaluation were presented in [8], where scenario-based
Software Engineering. Kluwer Academic Publishers. (2000)
assessment, software performance assessment and [6] Ciraci, S., Broek, P.: Evolvability as a Quality Attribute
experience-based assessment were addressed. The of Software Architectures. ERCIM Workshop on Software
scenario-based methods such as ATAM [7] would Evolution. (2006)
require quite a number of evolvability scenarios (to [7] Clements, P., Kazman, R. and Klein, M. Evaluating
address and cover each of the seven subcharacteristics); Software Architectures: Methods and Case Studies. Addison-
a more important limitation is that while scenarios are Wesley. (2002)
concrete anticipated events in the system life-time, [8] Del Rosso, C.: Continuous Evolution Through Software
evolvability might concern high-level business Architecture Evaluation: a Case Study. Journal of Software
Maintenance and Evolution: Research and Practice. (2006)
requirements at an abstract level which calls for some [9] Dromey, G.: Cornering the Chimera. IEEE Software
more general type of analysis to identify implications (January): 33-43. (1996)
on software architecture and corresponding evolution [10] Grady, R., Caswell, D.: Software Metrics: Establishing a
path. Company-Wide Program. Englewood Cliffs, NJ,
PrenticeHall. (1987)
7. Concluding Remarks [11] Hofmeister, C., Nord, R., Soni, D.: Applied Software
In this paper, we described an analysis of a complex Architecture. Addison-Wesley. (2000)
industrial control system, driven by the need to [12] ISO/IEC 9126-1. International Standard. Software
improve its evolvability. A set of evolvability Engineering: Product Quality, Part 1: Quality Model. (2001)
subcharacteristics were described from the case [13] Isaac, D., McConaughy, G.: The Role of Architecture
perspective: analyzability, architectural integrity, and Evolutionary Development in Accommodating Change.
Proc. NCOSE’94. (1994)
changeability, portability, extensibility, testability and
[14] Kolb, R., Muthig, D., Patzke, T., Yamauchi, K.:
domain-specific attributes. In addition, an architectural Refactoring a Legacy Component for Reuse in a Software
evolvability analysis method (designated as AREA Product Line: a Case Study. Journal of Software
method) was applied to the complex industrial system. Maintenance and Evolution: Research and Practice. (2006)
[15] Lago, P., van Vliet, H.: Explicit Assumptions Enrich [23] Ramil, J.F., Lehman, M.M.: Metrics of Software
Architectural Models. ICSE. (2005) Evolution as Effort Predictors - A Case Study. Proc. ICSM.
[16] Land, R., Crnkovic, I.: Software Systems In-House (2000)
Integration: Architecture, Process Practices and Strategy [24] Rowe, D., Leaney, J.: Evaluating Evolvability of
Selection. Journal of Information and Software Technology, Computer Based Systems Architectures – an Ontological
vol 49, nr 5, p419-444, Elsevier, September. (2006) Approach. Proc. of International Conference and Workshop
[17] Lehman, M.M, Ramil, J.F. et al.: Metrics and Laws of on Engineering of Computer-Based Systems. (1997)
Software Evolution: The Nineties View. IEEE Computer [25] Strauss, A. and Corbin, J. M.: Basics of Qualitative
Press, pp 20-32. (1997) Research: Techniques and Procedures for Developing
[18] Lientz, B., Swanson, E.: Software Maintenance Grounded Theory (2nd edition), ISBN 0803959400, Sage
Management. Addison-Wesley. Reading. MA. (1980) Publications, 1998.
[19] Losavio, F. et al.: ISO Quality Standards for Measuring [26] Subramanian, N., Chung, L.: Process-Oriented Metrics
Architectures. The Journal of Systems and Software. (2004) for Software Architecture Evolvability. Proc. IWPSE. (2002)
[20] McCall, J.A., Richards, P.K., Walters, G.F.: Factors in [27] Tamai, T., Torimitsu, Y.: Software Lifetime and its
Software Quality. National Technical Information Service. Evolution Process over Generations. Proc. ICSM. (1992)
(1977) [28] Weiderman, N.H. et al.: Approaches to Legacy Systems
[21] Pei Breivold, H., Crnkovic, I., Eriksson, P. J.: Analyzing Evolution. Technical Report CMU/SEI-97-TR-014. (1997)
Software Evolvability. Accepted at 32nd COMPSAC. (2008) [29] Yang, H., Ward, M.: Successful Evolution of Software
[22] Quecke, G., Ziegler, W.: Mesch - an approach to Systems. Artech House Publishers. London. (2003)
resource management in a distributed environment. In Proc.
of the First IEEE/ACM International Workshop on Grid
Computing. Springer-Verlag, pp. 47–54. (2000)