AN INTEGRATION-ORIENTED MODEL FOR APPLICATION

LIFECYCLE MANAGEMENT

Guenter Pirklbauer, Rudolf Ramler and Rene Zeilinger

Software Competence Center Hagenberg, Softwarepark 21, A-4232 Hagenberg, Austria

Keywords:

Application lifecycle management, Software engineering process, Tool integration, Requirements engineering.

Abstract:

In the last years a new trend emerged in the software engineering tool market: Application Lifecycle Manage-

ment (ALM). ALM aims at integrating processes and tools to coordinate development activities in software

engineering. However, a common understanding or widely accepted deﬁnition of the term ALM has not yet

evolved. Thus, companies introducing ALM are usually confronted with a wide range of solutions following

different, vendor-speciﬁc interpretations. The aim of this paper is to clarify the concept of ALM and to provide

guidance on how to develop an ALM strategy for software development organizations. The paper identiﬁes

key problem areas typically addressed by ALM and derives a model to relate the solution concepts of ALM to

engineering and management activities. The work has been applied in the context of an improvement project

conducted at an industrial company. This case shows how the model can be used to systematically develop a

tailored, vendor-independent ALM solution.

1 INTRODUCTION

Traditional software development emphasizes distinct

project phases and a functionally separated organiza-

tion with specialized roles. All of these roles have

their own separate perspective, are organized along

their own processes, use their own tools, and their

data and results are locked in their own repositories.

The management of software product development

faces the challenge to align these different perspec-

tives to the overall business objectives, to enforce

consistent processes spanning the different groups,

to manage the relationship between the development

artifacts produced by the different groups, and to

monitor the development progress across the whole

lifecycle. Application lifecycle management (ALM)

promises to meet these challenges (e.g., (Schwaber

et al., 2006)) and over the last few years a large num-

ber of ALM solutions have been announced.

The term ALM is quite new. It appeared in the

software tool market around 2004 (Azoff, 2007). Its

purpose was to emphasize the tool vendors’ move to-

wards integrated tool suites covering the whole ap-

plication lifecycle. However, tool vendors tend to in-

terpret and deﬁne ALM differently, often according to

their existing or planned marketing strategies. A com-

mon understanding or widely accepted deﬁnition of

ALM has not yet evolved (Kriinen and Vlimki, 2008).

Due to the loosely deﬁned scope of ALM, a broad va-

riety of tools has up to now been labeled as ALM so-

lution while, at the same time, it is hard to compare

these solutions on an objective basis.

The goal of this paper is to shed some light into

the current situation of ALM and to provide guidance

on how to develop an ALM strategy for software de-

velopment organizations.

2 ORGANIZATIONAL CONTEXT

AND KEY PROBLEM AREAS

The work presented in this paper has been applied

in the context of an improvement project conducted

at an international company headquartered in Aus-

tria. The company’s software products are organized

as software product lines, i.e., the standard products

are customized according to the needs of individual

customers. The products evolve over many years of

ongoing development, organized in a sequence of re-

lated projects with a ﬂoating boundary between de-

velopment and maintenance.

By analyzing the organizational context, we have

identiﬁed a number of company-speciﬁc problems

that we have generalized to the following key prob-

lem areas. These key problem areas correspond to

399

Pirklbauer G., Ramler R. and Zeilinger R. (2009).

AN INTEGRATION-ORIENTED MODEL FOR APPLICATION LIFECYCLE MANAGEMENT.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

399-402

DOI: 10.5220/0002007203990402

 SciTePress

issues and obstacles we also observe in many other

industrial projects conducted by a variety of different

enterprises.

• Lack of Reuse of Lifecycle Artifacts.

When enterprises evolve over time, the reuse of

artifacts gets more and more important. Reuse at

the level of code has been addressed by object-

oriented concepts. The key challenge lies in trans-

forming the reuse paradigm to lifecycle artifacts

such as requirements, architecture, design, terms,

and deﬁnitions.

• Unclear Rationale of Historical Decisions.

Decisions are often based on informal discus-

sions, which are not documented or preserved in

any other way. Therefore, decisions can not be

traced back to their origins and the rationale for

requirements can not be reconstructed.

• Intransparent Consequences of Changes.

Software products are subject to continual im-

provement and enhancement over many years.

Changes and enhancements become part of the

day-to-day business and the need for systematic

investigation of the impact of changes increases.

• Imbalance of Activities over the Lifecycle.

In many organizations the activities over the life-

cycle of software products are imbalanced with an

overemphasis on core engineering activities such

as coding, testing, building, and deployment. Ac-

tivities like product management, product portfo-

lio management, asset management are frequently

neglected.

• Heterogeneous Tool-Infrastructure.

In the analyzed case, the existing tool infrastruc-

ture has evolved over many years. Tool integra-

tion has not been seen as an important aspect for

the infrastructure. Hence, collaboration of roles

using different tools is hampered as the tools iso-

late activities by intransparentand proprietary tool

data stores and repositories.

• Disrupted Workﬂows.

The limited interoperability of tools also causes

frequent disruptions in workﬂows and processes.

As a consequence, we observed a high number of

redundant activities as well as data in the analyzed

case. This redundancy leads to increased admin-

istrative overhead, error-prone manual work, and

inconsistencies, which are in turn the source of fu-

ture errors.

• Intransparent Status of Artifacts and Work

Progress.

Due to the heterogeneous tool landscape, artifacts

are stored both distributed and redundantly in sev-

eral tool repositories. Even with careful consider-

ations and policies in place to align workﬂows it

is cumbersome to determine the current status of

an artifact or the overall progress of the work.

• Inability to Reconstruct Historical States.

Apart from the fact that the code of the software

system is under control of a versioning system,

many artifacts are produced and archived in sepa-

rate tools, that are not able to capture the historic

states or use incompatible approaches versioning,

baseling, and merging.

• Missing Integration of Product Management

and Project Management.

In the analyzed case, the software products

evolved over many years. After the initial de-

velopment phase, the software product will be re-

leased and from this point on it is maintained and

enhanced in a series of ongoing, parallel projects.

This enforces two views. The view on prod-

ucts and the view on projects. Often, however,

the management focus is mainly concerned about

individual projects, which results in sub-optimal

business decisions.

3 INTEGRATION-ORIENTED

ALM MODEL

To develop a strategy for introducing ALM in the case

company,we developeda conceptual model for ALM,

independent from a particular tool vendor’s offer. In-

stead of features and activities, the model emphasizes

the solution concepts proposed by ALM and relates

these solution concepts to the existing engineering

and management activities.

3.1 ALM Solution Concepts

We identiﬁed two main goals of ALM by matching

the tool vendors’ propositions with the key problem

areas listed above.

1. Seamless integration of engineering activities at

tool and process level across the whole lifecycle

of an application

2. Emphasis on management activities to shift the

technical perspective of engineering towards the

business perspective of software management

These two main goals are reﬁned to a number of solu-

tion concepts, which are implemented by tool vendors

using central repositories, service-oriented architec-

tures, integrated tool platforms, etc. Following solu-

tion concepts have been identiﬁed:

ICEIS 2009 - International Conference on Enterprise Information Systems

400

• Traceability. Traceability is a well-known con-

cept, deﬁned as “the degree to which a relation-

ship can be established between two or more prod-

ucts of the development process, especially prod-

ucts having a predecessor-successor or master-

subordinate relationship to one another” (IEEE,

1990).

• Version Control. Over the lifecycle of an appli-

cation multiple versions evolve and require con-

sistent control for managing releases, maintaining

deﬁned states and baselines across different arti-

facts, as well as reverting to these deﬁned states.

The concept of version control is well established

(see e.g. (Leon, 2000)), whereby research is con-

tinuously pushing the boundaries of version con-

trol concepts beyond source code artifacts (Es-

tublier et al., 2005).

• Measurement. Retrieving or computing infor-

mation about products, processes and resources

as well as their relationships is the basis for es-

tablishing transparency, objective evaluation and

planning of future activities. The role of measure-

ment has been ﬁrmly grounded into the manage-

ment of software projects by DeMarco (DeMarco,

1986) and has been expanded to the entire appli-

cation lifecycle.

• Workﬂow Support. By execution, workﬂows bring

together a sequence of operations, resources,

roles, and information ﬂows to achieve a result

of value. Traditionally, workﬂows have been fo-

cused on single activities and tools, for example,

issue tracking or requirements management. Cur-

rent approaches, such as the Application Lifecy-

cle Framework (ALF) (Eclipse, 2008), provide a

interoperability platform for tools to establish a

workﬂow across the entire lifecycle of an applica-

tion.

• Collaboration. Software development is a team

endeavor and, thus, concepts and tools for collab-

oration, e.g. Wikis have found their way into soft-

ware development. Computer-support for collab-

oration and cooperation is yet again another long-

established ﬁeld (see e.g. (Grudin, 1994)).

• Shared Services. In addition to the aboveconcepts

we identiﬁed a number of basic services which

are relevant for every activity and tool applied in

the course of ALM. A typical example is manag-

ing users and access rights, which are often im-

plemented as a central service shared among the

different activities and tools.

Figure 1: Integration-oriented ALM Model

3.2 Dimensions of Integration

The identiﬁed solution concepts have a strong focus

on integration in two directions. First, they provide

profound support for the integration of engineering

activities over the whole application lifecycle at tool

level as well as process level. Thereby they address

the ﬁrst goal of ALM. Second, the same concepts also

enable the integration of engineering activities with

management activities. In that way they establish the

link between the technical and business perspective

along the application lifecycle, the second goal of

ALM.

Figure 1 depicts these three dimensions show-

ing the engineering activities (software requirements,

software design, software construction, software test-

ing, and software maintenance according to (Abran

et al., 2004)) on the x-axis and the management activ-

ities (software conﬁguration management, software

engineering management, software process manage-

ment, software quality management according to

(Abran et al., 2004)) on the y-axis. The solution con-

cepts of ALM (traceability, version control, measure-

ment, workﬂow support, collaboration, and shared

services according to Section 3.1) are shown as third

dimension depicted as z-axis to clearly distinguish

them from engineering and management activities.

This perception helps to clarify the contribution of

ALM as the thread that ties the different activities of

engineering and management together.

4 IMPLEMENTATION

The ALM model has been used to ﬁnd an ALM strat-

egy for the analyzed company. Therefore, the prob-

AN INTEGRATION-ORIENTED MODEL FOR APPLICATION LIFECYCLE MANAGEMENT

401

lems were mapped to combinations of engineering

and management activites. The concepts were prior-

ized according to the estimated value for supporting

the found combinations. As a consequence, the ALM

solution concepts traceability and baselining (part of

version control) have been implemented in the com-

pany. We have made changes on two different lev-

els of the company’s software engineering structure.

Firstly on the process level and secondly on the tool-

infrastructure level.

On the process level the company had neglected

some activities of requirements engineering, since the

time pressure in the projects did not allow a detailed

documentation of requirements and related decisions.

The implemented solution is based on an information

model representing new artifacts. These documents

enforce the documentation of all relevant information

and consistently describe the state of the entire prod-

uct, which previously had to be digested from a long

list of descriptions of incremental changes made over

time.

On tool-infrastructure a requirements manage-

ment tool had been introduced as central integration

point for the new artifacts. Hence, the information

previously contained in different repositories is now

hosted under a single roof, avoiding inconsistencies

as well as unnecessary overhead for maintaining base-

lines and traceability.

5 SUMMARY AND OUTLOOK

In this paper we have identiﬁed key problem areas

of enterprises in the software engineering business.

Based on these key problem areas we have elaborated

a model of ALM, which integrates engineering activ-

ities and management activities. This model can be

operationalized to systematically develop a company-

speciﬁc ALM strategy and to trigger process improve-

ment projects. Furthermore, the model fosters a com-

mon view for the evaluation of ALM solutions.

An example about the application of the model

for introducing ALM in a software development com-

pany has been provided. Preliminary results conﬁrm

the applicability of the model as a guidance for iden-

tifying and prioritizing problem areas as well as plan-

ning a tailored ALM solution. Our plans for future in-

clude the repeated application of the model for other

companies in different domains and to establish a

vendor-independent improvement approach leverag-

ing ALM for small and medium enterprises.

REFERENCES

Abran, A., Moore, J. W., Bourque, P., Dupuis, R., and Tripp,

L. L. (2004). Guide to the Software Engineering Body

of Knowledge (SWEBOK). IEEE.

Azoff, M. (2007). The future of application lifecycle man-

agement. OpinionWire Articles. Butler Group.

DeMarco, T. (1986). Controlling Software Projects: Man-

agement, Measurement, and Estimates. Prentice Hall

PTR, Upper Saddle River, NJ, USA.

Eclipse (2008). Eclipse Application Lifecycle Framework

(ALF) Project. http://www.eclipse.org/alf/ (November

2008).

Estublier, J., Leblang, D., van der Hoek, A., Conradi, R.,

Clemm, G., Tichy, W., and Wiborg-Weber, D. (2005).

Impact of software engineering research on the prac-

tice of software conﬁguration management. ACM

Trans. Softw. Eng. Methodol., 14(4):383–430.

Grudin, J. (1994). Computer-supported cooperative work:

history and focus. Computer, 27(5):19–26.

IEEE (1990). IEEE standard glossary of software engineer-

ing terminology. Technical report, IEEE.

Kriinen, J. and Vlimki, A. (2008). Impact of application

lifecycle management - a case study. In Enterprise

Interoperability III - New Challenges and Industrial

Approaches. Springer London.

Leon, A. (2000). A guide to software conﬁguration man-

agement. Artech House, Inc., Norwood, MA, USA.

Schwaber, C., Rymer, J. R., and Stone, J. (2006). The

changing face of application life-cycle management:

Tomorrow’s alm platforms will deliver on the promise

of today’s ALM suites. Technical report, Forrester.

ICEIS 2009 - International Conference on Enterprise Information Systems

402