2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications

Application Lifecycle Management as Infrastructure for Software Process

Improvement and Evolution: Experience and Insights from Industry

Hermann Lacheiner and Rudolf Ramler

Software Competence Center Hagenberg
Softwarepark 21, A-4232 Hagenberg, Austria
{hermann.lacheiner, rudolf.ramler}@scch.at

Abstract—Application Lifecycle Management (ALM) is widely
promoted by tool vendors and ALM solutions have attracted
the attention of many software developing companies. In this
paper we describe the introduction of an ALM solution for
software development in a large industrial manufacturing
company. The introduction is complemented by several small-
scale process improvement initiatives. Thereby the ALM solu-
tion was turned on itself by using the tool for the tool evalua-
tion, the introduction as well as the process improvement ac-
tivities. Based on this experience we explore whether the fea-
tures provided by ALM for software development are also an
effective utility for software process management. The paper
shows how the ALM solution was applied for process develop-
ment, process documentation, process implementation and
process monitoring. We found that the concepts underlying
ALM were suitable to support these activities and, further-
more, endorsed the view that software processes are software
too.
Keywords-application lifecycle management; ALM; software
eingineering environment; process management
I. INTRODUCTION
The development of software products is a highly com-
plex endeavor, which includes numerous interdependent
activities, various different roles and a wide range of artifacts
spanning over all phases of the development project and –
beyond that – across the phases of the product’s overall life-
cycle. In response, Application Lifecycle Management
(ALM) has been proposed with the objective to provide a
comprehensive technical solution for monitoring, controlling
and managing software development over the whole applica-
tion lifecycle (e.g., [2], [4], [8], [13]).
ALM is related to concepts from Product Lifecycle Man-
agement (PLM) [12] in manufacturing and service industries.
In contrast, the term ALM “has emerged to indicate the
coordination of activities and the management of artefacts
(e.g. requirements, source code, test cases) during the soft-
ware product’s lifecycle” [4] and was coined mainly by tool
vendors to emphasize the move towards integrated tool
suites. Many available ALM tools and solutions have been
evolved out of a heterogeneous set of specialized engineering
and management tools covering activities that range from
requirements engineering over design, implementation, inte-
gration, testing, to deployment and maintenance.
Due to this background, ALM commonly shows a strong
focus on support for engineering activities. Nonetheless, the
advancement to integrated tool suites also leveraged the
support for management activities such as project planning,
effort estimation, task management, reporting and monitor-
ing. This perspective also fostered the need as well as the
ability to support process management as part of ALM. In a
Forrester Research report on ALM [13], for instance, the
significance of process management is expressed in the defi-
nition of ALM as “the coordination of development life-
cycle activities, … through: 1) enforcement of processes that
span these activities; 2) management of relationships be-
tween development artifacts used or produced by these ac-
tivities; and 3) reporting on progress of the development
effort as a whole” [13].
Aspects of process management [7] can be found in most
of the ALM solutions available on the tool market. For ex-
ample, many tools provide support for process templates that
map the tool configuration to the building blocks of a soft-
ware process model (e.g., [2], [8]). Typically the process
templates are the starting point for tailoring the ALM solu-
tion to the requirements of a software development organiza-
tion. In addition, several tools provide means to collect proc-
ess-related metric data that can be integrated in the ALM
tools’ dashboards and reports.
However, the premise that “software processes are soft-
ware too” (see [9] and [10]) suggests that process manage-
ment may benefit from ALM support beyond these dedicated
features. Thus, in this paper we raise the question: Are the
concepts of ALM aiming at software development and main-
tenance also an effective utility for evolving and improving
the software process? We try to answer this question by
describing the results and experiences from the introduction
of an ALM solution complemented by small-scale process
improvement initiatives in an industrial manufacturing com-
pany. In this context the ALM solution was used to manage
the tool evaluation, the introduction as well as the subsequent
process improvement activities.
The paper is structured as follows: In Section 2 we give a
brief overview of ALM and related work. Section 3 presents
the background of the case company and describes the intro-
duction of the ALM solution including the accompanying
process management activities. Section 4 describes how the
features of the ALM solution were used for process man-
agement. Section 5 discusses the results and lessons learned.
In Section 6 a conclusion and outlook on future work round
out the paper.

978-0-7695-4488-5/11 $26.00 © 2011 IEEE 286

DOI 10.1109/SEAA.2011.51
 II. RELATED WORK
Despite the widespread use of the term Application Life-
cycle management (ALM), a generally accepted definition or
a common understanding of the scope of ALM has not yet
evolved. From the tool vendors’ perspective, ALM cumu-
lates to integrated tool suites covering activities that range
from requirements engineering over design, implementation,
integration, testing, deployment, to usage and maintenance
(e.g., [2], [8]).
In contrast, Schwaber presents a less tool-focused picture
of ALM, which she defines as “the coordination of develop-
ment life-cycle activities, including requirements, modeling,
development, build, and testing” [13]. She identifies three
pillars on which ALM is based: “1) enforcement of processes
that span these activities; 2) management of relationships
between development artifacts used or produced by these
activities; and 3) reporting on progress of the development
effort as a whole” [13].
Likewise Kääriäinen and Välimäki consider “the coordi-
nation of activities and the management of artefacts” [4] as
central aspect of ALM. In their work they investigate the
impact and evolution of ALM solutions. They conducted a
series of case studies on two solutions from two different
software teams from one organization forming a longitudinal
study on ALM (see [4], [5] and [6]). According to
Kääriäinen and Välimäki the principal elements of an ALM
framework are: “creation and management of project arte-
facts”, “traceability of lifecycle artefacts”, “reporting of
lifecycle artefacts”, “process automation”, “tool integration”
and “communication” [6].
Pirklbauer et al. [11] emphasize the role of ALM for
strengthening the business perspective in software engineer-
ing. They discuss (technical) concepts that facilitate the
combination of engineering and management activities, e.g.,
traceability, version control, measurement, workflow sup-
port, and collaboration.
From the tool perspective, an ALM solution can be cate-
gorized as software engineering environment (SEE). The
ISO/IEC Std. 15940 on software engineering environments
refers to a SEE as “a collection of software services, partially
or fully automated by software tools, that are used to support
the execution of human activities in software engineering”
[3].
III. BACKGROUND AND CASE SETTING
The ALM solution described in this paper1 has been es-
tablished for software development in a large industrial man-
ufacturing company. This section introduces, first, the back-
ground of the organization in which, second, the project
concerned with establishing the ALM solution took place.
A. Organizational Background
As a large manufacturer of industrial machinery, the case
company has more than three thousand employees located at
several production plants and subsidiaries worldwide. Simi-
larly software development teams are – like product man-
1
Polarion ALM (http://www.polarion.com/products/alm/)
287
agement and quality assurance teams – distributed to differ-
ent subsidiaries across the world.
Overall far more than 100 employees are involved in the
development and customization of the software for machin-
ery. The software consists of various different products and
spans from visualizations at the HMI level to low level con-
trol of machinery and periphery equipment. Each of the
different products and application levels resulted in a soft-
ware system with a history of numerous years of develop-
ment and maintenance and the accumulated size of several
hundred thousand lines of source code. Furthermore, ampli-
fied by the distribution to separate development sites, a het-
erogeneous landscape of software technologies and an equal-
ly heterogeneous set of development tools and divergent
software development processes had evolved.
All software development activities are organized within
yearly development projects with one release synchronized
for all projects. These yearly releases are driven by the me-
chanical and electrical engineering processes that dominate
product development and management. Software develop-
ment and all its activities are embedded in the context of
mechanical and electrical engineering. The superordinate
product development process provides only a rough guide-
line with considerable room for interpretation on how the
activities, roles and deliverables of the software development
process should be organized.
The product lifecycle is characterized by the innovations
in mechanical and electrical engineering, the substantial
investments bound in hardware manufacturing and assem-
bling as well as the product maintenance cycles of more than
10 years. In this context software is considered an enabling
technology. Software engineering is expected to come up
with prompt and flexible initial solutions that evolve to sus-
tainable products applicable for many different product lines
with a high demand regarding dependability and reliability.
B. Introducing ALM and Process Management
The case company decided to establish an ALM solution
to address the above mentioned challenges. A dedicated
project was launched for the introduction of ALM. Although
this project was performed in a highly iterative way, it can be
divided into five consecutive phases, each completed by
defined milestones: (1) evaluation, (2) piloting, (3) customi-
zation, (4) enhancement and (5) roll-out. Each phase in-
volved process management activities that were coordinated
and supported by utilizing the ALM solution. Figure 1 gives
an overview of the phases and the involved activities.
1) Evaluation
The objective of the first phase was the selection of an
appropriate ALM solution for the case company. In the first
phase, the goals and requirements for ALM were identified.
Based on a study of commercial and open source ALM solu-
tions a candidate ALM tool was selected.
As a starting point for the evaluation, requirements and
goals were elicited in initial workshops and further refined
iteratively. The goals were derived from the company’s
business strategies w.r.t. software development. They re-
flected the needs of the company independent of the underly-
ing development process or ALM solution. The requirements

Go/No-go decision
ALM tool selected
Evaluation Piloting
ƒ Elicitation of goals ƒ Elicitation of usage
and requirements scenarios (“stories”)
ƒ Managing changing ƒ Tracing stories to
requirements requirements and
ƒ Traceability matrix goals
for requirements ƒ Tracking defects
and goals ƒ Online process
ƒ Project planning documentation
and management (“how-tos”)
Figure 1. Phases of ALM introduction and complementary process management activities.
describe what is necessary to achieve the goals in terms of
the development process and in terms of the ALM solution.
For example, a requirement states that “developer activities
should be managed as tasks”.
To gather additional hands-on experience with the se-
lected tool candidate, the elicited goals and requirements for
ALM were managed with the candidate tool. Using the se-
lected tool also for the purpose of the evaluation laid the
foundation for managing the whole introduction project with
the ALM tool. Hence the tool was used to plan and coordi-
nate project resources and tasks, to document elicited re-
quirements, to store project artifacts, and to track and report
the progress.
With the selection of a candidate ALM tool a milestone
was reached, which marked the end of this phase and the
transition to an extended evaluation in a pilot project.
2) Piloting
The objective of the second phase was to gain feedback
from users about the ALM tool support for representative
scenarios in their daily work. The ALM tool was set up in a
basic configuration for the pilot project. In order to speed up
productive usage after a quick introduction and training
session, a tool specialist continually supported the users
performing their daily tasks and adapted the ALM tool’s
configuration if necessary.
Thereby the tool specialist recorded user feedback, e.g.,
issues concerning the functionality, usability or performance,
which was used to refine the initially elicited requirements.
An important effect of the pilot phase was that completely
new requirements emerged once the users started to under-
stand the additional possibilities offered by the ALM tool.
Soon the users in the pilot project discussed new usage sce-
narios and adapted existing workflows to exploit these new
possibilities. For example, the ability to easily combine
structured items such as tasks and requirements with unstruc-
tured text from Wiki pages resulted in a new approach for
requirement documentation and meeting protocols.
When existing and new usage scenarios were explored, a
brief description of these scenarios and how they can be
Process template and
tool configuration
External tools
integrated
Customization Enhancement Roll-out
ƒ Tracking tool con- ƒ Process guidelines ƒ Process quality and
figuration changes ƒ Tool usage and compliance report
ƒ Synchronizing process metrics ƒ Tailoring of process
process documenta- ƒ Measurement part templates
tion of the daily build ƒ New requirements,
ƒ Labeled releases of ƒ Dashboard visuali- stories, how-tos,
process templates zations rules, etc.
executed with the ALM tool was made to document the tool
evaluation. These descriptions were, of course, also stored in
the ALM tool and traced to the elicited requirements. By
making use of the ALM tool’s traceability support, an over-
view of fulfilled requirements in terms of successfully exe-
cuted and documented usage scenarios could be easily gen-
erated. Problems experienced in usage scenarios were
tracked with the ALM tool’s defect management.
The described usage scenarios piled up to a small but
highly accurate and up-to-date documentation of activities in
the software process and, furthermore, linked this documen-
tation to tool-specific know-how. The resulting demand of a
light-weight, Wiki-like process documentation is another
example of a requirement that was identified due to the ac-
tive usage of the ALM tool during the pilot phase.
The end of this extended evaluation phase was marked by
a go/no-go decision about the selected ALM tool candidate.
Based on a refined and extended set of requirements, the
previously evaluation results were revisited and, finally, the
decision was made to proceed with the selected tool.
3) Customization
The objective of the third phase was to customize the
ALM tool to optimally support the specific use cases of the
company. In the previous phase only the absolutely neces-
sary adaptations for the pilot project were made to keep the
effort during the evaluation at a minimum. In this phase the
full range of customization and productivity options was
utilized, e.g., for dashboards, work items, Wiki pages, filter
settings, search queries, and workflows.
Compared to all other phases, the customization of the
ALM tool claimed most of the effort in the introduction
project. The effort was managed via the ALM tool in form of
tasks and change requests specifying what should be custom-
ized. In addition, customization tasks were traced to the
previously gathered requirements and usage scenarios to
document their rationale.
An advantage of the selected ALM tool is that all settings
and configurations are stored in XML files, which are under
version control. Thereby the same version control system is
288
used as for any other artifact from software development.
Indeed, whenever a setting is changed, a new version of the
associated configuration file is created and checked in. To
keep track of what configurations were changed in resolving
a customization task, the ALM tool’s mechanism to link
changes from the version control system with tasks and
change requests was utilized. Changes in configurations files
could be traced back to customization tasks and, finally, to
the underlying requirements for ALM representing the com-
pany’s goals and user needs. Hence, all settings and defini-
tions regarding the ALM tool and, ultimately, the develop-
ment process itself could be managed like software engineer-
ing artifacts.
Consequently, at the end of the customization phase, the
tool configuration with all its settings and accompanying
process documentation was labeled as baseline in the version
control system and released as template for future projects.
4) Enhancement
The objective of the fourth phase was to extend the tool
support beyond the functionality of the selected ALM tool.
Once the ALM tool was ready for the use by other software
development teams, workshops were held, on the one hand,
to introduce the ALM solution and, on the other hand, to
identify open issues in the current configuration and process
description. It was recognized that technology specific fea-
tures such as test frameworks, code metrics or the build
system did not fully cover the requirements of the other
teams. Therefore additional tools had to be integrated. For
example, a build system based on open source tools (Hud-
son2 and Maven3) was established as central integration hub.
It combines the different tools as part of the daily build,
collects their results and presents or links them as part of the
build report.
Since in the previous phases software engineering meth-
ods and approaches were successfully utilized for establish-
ing the ALM solution, the daily build concept was also con-
sidered to be exploited for process management. It was
found that the daily build provided an ideal mechanism for
collecting data from the development projects about the
usage of the ALM solution and the proposed software proc-
ess. This process-related measurement data was visualized in
a dashboard integrated in the selected ALM tool.
To assess compliance with documented usage scenarios
and guidelines, the measurements were extended by a set of
queries that return artifacts and work items violating the
guidelines and common practices. Typical examples were
“tasks need to be linked to a requirement”, “passed iterations
must not have open tasks associated”, or “large requirements
in terms of estimated effort need to be split into smaller re-
quirements”. These process rules were run as part of the
daily build to identify and manage violations on a daily ba-
sis. The results were linked with problematic work items to
allow for a quick inspection and correction. Over time the
number of process rules steadily increased and process im-
provement evolved as an implicit activity once awareness
about critical deviances had been created.
2
http://hudson-ci.org
3
http://maven.apache.org
289
For the enhancement phase the final milestone marks the
integration of most of the different tools. However, the en-
hancement and integration tasks initiated in this phase will
continue in future and gradually faded into the roll-out phase
described below.
5) Roll-out
The objective of the roll-out phase was to establish ALM
support for the software projects of the company’s other
development teams. These teams were using various kinds of
different technologies, different tool sets and followed dif-
ferent development processes. As described above, it was the
aim of the previous phase to address technology and tool
issues via enhancements of the ALM solution.
In contrast, however, a common ground in terms of a
“one-size-fits-all” solution is less likely for the development
process. Although the overall development process appears
to be similar across the different development groups at the
first glance, there are many disagreements and incompatibili-
ties as the established practices vary notably from group to
group. The differences manifest themselves, for example, in
questions about how requirements are specified, how estima-
tions are made or have to be interpreted, how tasks are de-
rived from requirements, and how responsibilities are dis-
tributed among team members.
For the different development groups such deviations
may be necessary for good reason. Thus – although it is a
long-term goal to homogenize the development processes –
the short-term solution is to keep the ALM tool’s configura-
tion open to incorporate process variants. Instead of enforc-
ing a particular usage, e.g., by defining mandatory workflow
steps or input fields, once again process rules were used to
make deviations from the defined standard visible. A rule
engine was developed to respond to the increasing demand
for new process rules, the definition of rule sets, and the
parameterization of rules.
Monitoring deviations over an extended period of time is
necessary to surface inconsistencies in the overall software
process that need to be resolved at company level. Currently
a process manager is established as a dedicated role whose
duty is to launch and coordinate company-wide improvement
initiatives and to assess their results.
With a standardized development process for all groups
the milestone marking the end of the roll-out phase will be
reached.
IV. PROCESS MANAGEMENT ENVIRONMENT
For the evaluation of the ALM tool a dedicated project
was launched that, initially, hosted the evaluation and intro-
duction of the ALM support and, thereafter, evolved to a
platform for process management initiatives. This particular
project itself utilized the functionality provided by the ALM
tool, which it evaluated. Initially the ALM solution was
mainly utilized for requirements engineering and project
management tasks (e.g., planning resources, tracking tasks,
monitoring progress, storing results) like in any other soft-
ware development project. Thereafter, with the transition
towards process management, the ALM solution has been
utilized as technical infrastructure and environment for proc-
 Figure 2. Work items, trace links and views for process management in the ALM tool.
ess development, process documentation, process implemen-
tation and process monitoring.
Figure 2 gives an overview of the main building blocks
of this environment. Details about how this environment has
been implemented with the ALM tool’s functionality are
described in the following.
A. Process Development
As part of the evaluation of the ALM solution, require-
ments and goals were elicited in workshops and further re-
fined iteratively. The requirements and goals were recorded
and managed with the ALM tool as work items of the type
REQ and GOAL, utilizing the tool’s functionality for version
management, change control and traceability. For example,
since every GOAL translated into one or several REQs, the
corresponding associations were specified as trace links. A
traceability matrix was used to visualize and validate the
associations between goals and requirements. GOALs with-
out associated REQs or, vice versa, REQs without associated
GOALs guided the discussions in the workshops towards a
necessary refinement of a goal or a potential superfluous
requirement. The handling of GOALs and REQs was facili-
tated by attributes such as priority or state, whereby state :=
{new, in discussion, ... closed}.
To further elaborate the requirements, common usage
scenarios representing activities in the software development
process were identified. To facilitate the discussion and in-
volvement of ALM users (e.g., developers, requirements
engineers, project managers), the scenarios were specified
similar to user stories known from agile development [1].
User stories too, were managed with the ALM tool as items
of the type STORY and traced to corresponding REQs. Thus,
a traceability chain was established from the overall goals at
company-level down to detailed scenarios at user-level. An
example of a connected GOAL, REQ and STORY is given
in Figure 3.
290
GOAL: Incorporate ideas from all personnel in
development.
REQ: The system should enable company members
to submit an idea.
STORY: Submitting an idea via email.
Figure 3. Example of a goal - requirement - story chain.
Traceability provided a valuable aid for steering discus-
sions, setting priorities and guiding the successive adaptation
of the ALM solution and the development process. Further-
more, when the goals, requirements and scenarios were re-
fined and adapted over time, suspect trace links indicated the
need to verify the potential impact on associated items, e.g.,
part of the process documentation.
B. Process Documentation
The development process was documented mainly from
the perspective of process activities, which were described as
user stories and managed as STORY items. The related roles
involved in development were specified as additional attrib-
ute of a STORY. Since a story primarily captures the pur-
pose and a rough specification of the involved process activ-
ity, a step-by-step description of how to perform the speci-
fied activity is needed. Stories, thus, were complemented
with HOWTOs providing details on the process activities as
well as best practices and hints for using the ALM tool.
The decision to manage HOWTOs as separate work
items in the ALM tool enabled users to work with the proc-
ess documentation like with any other specification and to
take advantage of personal queries, filters and full-text
search. In addition, users were also able to create and modify
HOWTOs to extend and improve the documentation. Chang-
es to these work items are under version control and adhere
to a defined workflow; changes were reviewed and verified
by peers and, finally, enacted with the release of a new ver-
sion of the process documentation.
An alternative access to the process documentation is
provided in form of role-specific Wiki pages [14]. For every
process role a Wiki page has been generated that links to the
associated HOWTOs. The Wiki pages can be enhanced with
further annotations or additional Wiki pages can be created
to group related aspects of the documentation from different
perspectives.
C. Process Implementation
From the viewpoint of the ALM tool, the software devel-
opment process defines how the tool is configured in terms
of, e.g., work item types, workflows, project settings, or
Wiki templates. Most of the configurable items and available
options are stored in XML configuration files, which are
under version control in the same manner as the artifacts
from software development. Hence, from the viewpoint of
the ALM tool, implementing the process mainly corresponds
to the customization of the tool, i.e., the modification of the
corresponding configuration files.
Some of the requirements were supported by the ALM
tool out of the box. For the majority of the requirements,
however, the standard settings had to be modified and the
provided templates and workflows had to be customized to
some extent. Every necessary change was specified and
commissioned as task represented by an item of the type
TASK in the ALM tool. TASKs were linked to the STORY
specifying the requirement that triggered the change. In
addition, the TASKs were also linked to the modified XML
configuration files in the version control system, which rep-
resent the implemented change. Further changes to the con-
figuration followed the same procedure.
After the process had been implemented and the new
configuration had been tested and stabilized, a baseline ver-
sion of the configuration was created and released together
with the process documentation. The change history is doc-
umented in terms of the tasks associated to the baseline.
D. Process Monitoring
In addition to various process-related performance meas-
ures shown as part of the ALM tool’s dashboard, the moni-
toring of the compliance to process rules was considered a
central indicator for process quality. Process rules encode the
guidelines accompanying process activities specified as
stories. Examples are that “tasks need to be linked to a re-
quirement” or that “passed iterations must not have open
tasks associated”. In total 33 process rules were defined, e.g.,
relating to items such as requirements, tasks or iterations.
Process rules are constituted as item of the type RULE. They
are associated to STORYs via trace links.
A specific property of RULEs is that they have to be ex-
ecutable. Therefore each RULE is also linked to a JavaScript
function that queries the repository of the ALM tool in order
to detect violations, which are usually specified in terms of
thresholds. A library of reusable functions implementing
various generic queries has been developed. Thresholds and
other relevant properties are embedded as variables in the
textual description of the RULE. The rule engine parses the
291
description, extracts the variables and executes the query
function. For example, the description of the rule mentioned
above, written as human readable statements, is presented in
Figure 4.
“In project %PROJECT_ID% every item of type
%task% has to be linked to one item of type %req%.
There has to be at least %1% and at most %1% link be-
tween a pair of these items.”
Figure 4. Example of a process rule.
The text contains several variables surrounded by the
character %. These variables are set as parameters of the
query function checkLinkCardinality(projectId, fromItem,
toItem, minLinks, maxLinks).
The process engine executes the query function returning
a list of items violating the rule. The results from all exe-
cuted process rules are compiled to a process quality report
published as Wiki page (Figure 5). Every project member
has access to this report. The report is personalized as it
contains only rules and items the user is responsible for. The
items violating a rule are shown as links, so the user can
open an item with one click and take corrective actions.
Process rule Result
Figure 5. Violations overview in the process quality report.
The process rules are periodically executed as part of the
daily build. It is based on the same build environment that is
used for building in the development projects. To visualize
the process quality over time, the aggregated results are also
shown as trend graph in the build report, which is otherwise
used to depict test results.
V. RESULTS AND LESSONS LEARNED
At the time of writing, the project is in the roll-out phase.
Even though some customizations and enhancements are
planned for the near future, the ALM configuration of the
ALM solution as well as the documented process reached a
stable status. The results in terms of work items grouped by
type are shown in Table 1.
In the beginning a handful of GOALs had emerged as
important drivers representing the company’s software engi-
neering strategy. These goals were refined to REQs – on
average ten requirements exist per goal.
Requirements were once again refined to STORYs,
whereby several requirements may share one story. Stories
can be grouped according to affected process roles. Every with users. These GOALs and REQs were detailed into
story is assigned to exactly one of the roles: Technical prod- STORYs, so there is an initial peak of STORYs in the early
uct manager (5 stories), Project manager (10 stories), Devel- phases too. In the next iterations (iteration 3 to 5) the focus
oper (7 stories), Administrator (3 stories), Tester (2 stories), was on the refinement of HOWTOs to get a better under-
or Everyone (1 story). For every story typically two to three standing of the ALM tool. This resulted in feedback to
HOWTOs exist that provide step-by-step instruction on how REQs, which sometimes had to be changed and additional
to execute the story. REQs were introduced (iteration 6).
Towards the end of the piloting phase (iteration 10 and
Work Item Type Total 11) the users had become more experienced with ALM,
GOAL 9 which resulted in further REQs and additional changes. The-
REQ 59 se changes also caused an adaption of several of the HOW-
STORY 28 TOs, which shows as slightly delayed peak in iteration 11.
HOWTO 82 After the piloting phase only minor changes to REQs oc-
RULE 33 curred that do not stand out in the figure. In contrast, HOW-
TASK 122 TOs were more frequently changed with a significant peek in
iteration 15.
Table 1. Number of work items by type.

Up to now 33 RULEs have been implemented. The proc-

ess rules cover different areas of the software development
process: Requirements management (7 rules), project plan-
ning (9 rules), development (10 rules) and product quality (6
rules). Process rules have been introduced on demand. Cur-
rently only the most important aspects are addressed. More
rules would be necessary to cover all relevant aspects of the
development process.
In total 122 TASKs were needed – most ranging from 1 Figure 6. Changes of goals and requirements vs.
to 5 person days – to establish the ALM solution and to stories and how-tos.
adapt the process. About half of the tasks relate to the cus-
tomization of the ALM solution. This corresponds to the The introduction of ALM in the case company is an in-
share of the overall project effort consumed by the customi- teresting example for establishing tool support as well as for
zation phase, which is about 50 percent of the total effort evolving and improving processes. The key lessons we
from evaluation to enhancement, not including roll-out. learned in this project are:
Use prototyping for tool evaluation. Conventional ap-
REQ by Category Total proaches for selecting (software engineering) tools follow
Administration 7 evaluation procedures based on initially elicited require-
Requirements management 13 ments. Such approaches appear efficient and effective if
Change management 6 many tools with comparable features should be ranked to
Project management 8 elect an optimal candidate. However, in evaluating ALM
Implementation 6 tools we found the requirements could not be completely
Reporting 5 specified up-front since innovative features and concepts
Interfaces 4 fostered new application scenarios and implied new require-
Test management 6 ments. A prototyping approach resulting in the pilot project
Team collaboration 4 was thus necessary to gain confidence about the selected
candidate solution.
Table 2. Number of requirements by category.
Plan for customization and enhancements. A consider-
able share of the effort involved in introducing an ALM
Table 2 shows the number of REQs by category. With solution is consumed by the customization of the tool and the
one exception (the category “Requirements management”), tailoring of the process, even when process templates can be
the numbers of requirements are mostly uniformly distrib- used as basis. Not considering roll-out to different groups,
uted. The higher number of requirements in the category customization required about 50 percent of the effort and the
“Requirements management” reflects the company’s initial additional enhancement again about 25 percent. Similar
need to improve the requirements engineering and manage- findings have been reported by Kääriäinen and Välimäki [6].
ment process, which was one of the triggers for introducing Tolerate deviations, but offer feedback. Providing guide-
ALM in the first place. lines and feedback instead of imposing process compliance
Figure 5 illustrates the changes of GOALs and REQs in had a notably impact on the users’ acceptance of the pro-
contrast to STORYs and HOWTOs. These changes are posed process and ALM support. Basically the ALM tool is
grouped by iterations, each lasting about two weeks. In the capable to enforce rules by using strict settings, e.g., via
first iterations GOALs and REQs were elicited in workshops

292
required attributes for work items or conditional state transi-
tion in the workflow. However, enforcing the rules by such
mechanisms would prevent the use of the ALM solution for
exceptional cases not previously considered. Monitoring rule
violations and accepting a certain level of inconsistency and
deviations showed fruitful and even brought new require-
ments and scenarios to light.
VI. CONCLUSIONS
Over the recent years, the concept of ALM has been
widely promoted by tool vendors and ALM solutions have
attracted the attention of many software developing compa-
nies. In this paper we described the introduction of an ALM
solution for software development in a large industrial manu-
facturing company and the process improvement initiatives
complementing the introduction. For the management of
activities from both, the introduction and the process im-
provement, the ALM support was used.
Across all phases – evaluation, piloting, customization,
enhancement and roll-out – the ALM solution turned out to
be an effective utility not only for software development but
also for process management. Indeed, many activities in
process management show similarities with the management
activities in software development and, furthermore, many of
the process-related artifacts can be treated similar to artifacts
from software development. Examples are (software | proc-
ess) requirements or (user | process) documentation but also
the configuration and implementation (of developed applica-
tions | tools and process rules) as well as measurement re-
sults (from code analysis | process rules). Hence, process
management can draw many benefits from the features pro-
vided by an ALM solution.
For the people involved in the project, this finding stirred
far-reaching discussions. From the perspective of software
development, the underlying software development proc-
esses – and the management thereof – are often perceived as
a separate thread, running in parallel but mostly detached
from the actual development activities. In many cases soft-
ware development and process management have drifted
apart and, thus, software development and process manage-
ment started to evolve in their own (small) universe, focusing
on their own problems, elaborating their own solutions, with
their own models, concepts and tools. The way in which the
ALM solution was used for process management has brought
both worlds closer together. Reusing the concepts from soft-
ware engineering for process management wherever possible
shaped a common language that fostered mutual understand-
ing. Perceiving the ALM tool and its configuration as part of
the implementation of the process created awareness about
the contribution of process management for software devel-
opment.
The inherent risk that process management is by this
means reduced to tool support can be opposed by the ques-
tion whether software development is only concerned about
293
executable results. Reflecting on what software development
actually encompasses – the source code, the underlying
models as well as the activities and people that brought it to
life – further support the appreciation of the role of process
management.
Departing from this discussion, a main point of our future
work will be to investigate whether and how ALM solutions
can serve as instances of a software process. This question is
related to another target we are aiming at, the definition of a
comprehensive set of process rules. In this context we are
interested in exploring how and to what extent the actual
processes can be reverse engineered from the configuration
and measurements extracted from an ALM solution.
REFERENCES
[1] M. Cohn, "User Stories Applied: For Agile Software Development,"
Addison-Wesley, 2009.
[2] M. Gousset, A. Krishnamoorthy, B. Keller and S. Timm,
"Professional Application Lifecycle Management with Visual Studio
2010: with Team Foundation Server 2010," Wiley Publishing, 2010.
[3] ISO/IEC, "International Standard 15940, Information Technology –
Software Engineering Environment Services," ISO/IEC, 2006.
[4] J. Kääriäinen and A. Välimäki, "Applying Application Lifecycle
Management for the Development of Complex Systems: Experiences
from the Automation Industry," 16th EuroSPI 2009, CCIS 42, Alcala,
Spain, Sept. 2009, pp. 149-160.
[5] J. Kääriäinen, J. Eskeli, S. Teppola, A. Välimäki, P. Tuuttila and M.
Piippola, "Extending Global Tool Integration Environment towards
Lifecycle Management," Confederated International Workshops and
Posters on On the Move to Meaningful Internet Systems, OTM 2009.
Springer, LNCS 5872, 2009, pp. 238-247.
[6] J. Kääriäinen and A. Välimäki, "Impact of Application Lifecycle
Management – A Case Study," Conference on Interoperability of
Enterprise, Software and Applications (I-ESA), Berlin, German,
March 2008, pp. 55-67.
[7] A. Kinnula, "Software Process Engineering Systems: Models and
Industry Cases," Oulu University Press, 2001.
[8] S. Krishna and T. Fenstermaker, "IBM Rational Team Concert 2
Essentials," Packt Publishing, 2011.
[9] L. Osterweil, "Software processes are software too," 9th International
Conference on Software Engineering (ICSE '87), Monterey, CA,
March 1987, pp. 2-13.
[10] L. Osterweil, "Software processes are software too, revisited," 19th
International Conference on Software Engineering (ICSE '97),
Boston, MA, 1997, pp. 540-558.
[11] G. Pirklbauer, R. Zeilinger and R. Ramler, "An Integration-Oriented
Model for Application Lifecycle Management," 11th International
Conference on Enterprise Information Systems (ICEIS 2009),
Springer, LNBIP 24, Milan, Italy, May 2009, pp. 399-403.
[12] A. Saaksvuori and A. Immonen, "Product Lifecycle Management,"
3rd Ed, Springer, 2008.
[13] C. Schwaber, "The Changing Face Of Application Life–Cycle
Management," Technical Report, Forrester Research Inc., 2006.
[14] K. Stapel, E. Knauss and C. Allmann, "Lightweight Process
Documentation: Just Enough Structure in Automotive Pre-
development," 15th EuroSPI 2008, CCIS 16, Dublin, Ireland, Sept.
2008, pp. 142-151.