Hardware Reference
In-Depth Information
research phase that produced the current state analysis of ALM solution version 3.0 in
a company and further elaborated the ALM framework by defining relations between
framework elements. The data for this study has been collected by updating the com-
pany's previous ALM description based on information received from the comple-
mentary interviews of the project managers (i.e. what has changed and why teams
ended up with different solutions). The ALM description, analysis results and conclu-
sions drawn have been reviewed by the project managers.
Kääriäinen &
Välimäki [11]
Kääriäinen &
Välimäki [12]
ALM
solution V1.0
ALM
solution V2.0
ALM
solution V3.0
ALM
improvement
2006
2007
2008
2009
Fig. 3.
History of ALM improvement in a company
4 History of ALM Improvement and Current Solution
Previously, the company's ALM solution for distributed development was comprised
of several somewhat isolated databases to manage project related data, such as local
version control and distributed document management and fault management sys-
tems. This caused challenges especially in a global development environment where
the consistency and real-time visibility of the information is important. Therefore, the
company started to seek more integrated solutions to coordinate distinct project
phases and to provide a centralised project database for all project related data. In
practice, this meant that the SW teams deployed a commercial ALM tool with the
Scrum method.
The documentation and the history of version 1.0 and 2.0 ALM solutions have
been reported in [11, 12] (see Figure 3). The teams started from somewhat similar
solutions for ALM. The backbone of this solution was a commercial ALM solution
called Microsoft's Team Foundation Server (TFS). This solution was configured with
a 3
rd
party Scrum process template. Both teams wanted to keep the changes to the
process template to a minimum. After two years, teams ended up with fairly different
solutions. The ALM solution of SW team 1 was comprised of several interconnected
product information databases, whereas the backbone of the ALM solution of SW
Team 2 was a single central global ALM tool, TFS.
Different solutions were due to the different kinds of SW products produced in
these teams and organisations' management constraints related to these SW products.
SW Team 1 produces a SW product that is one part of an evolving “product plat-
form”, whereas SW Team 2 develops industry-specific SW products. Therefore, SW
Team 1 had a need to integrate with, for instance, the test document and fault man-
agement databases that are also used by other platform projects to maintain consis-
tency with other projects, provide a single channel for accessing information and
allow, for instance, test staff to use a single interface for reporting faults that relate to
a certain product platform.
