Hardware Reference
In-Depth Information
E.g. from a configuration management point of view in [20, 21, 22] as well as from a
requirements management point of view in [15, 23]. In our case, SW Team 1 produces
SW that is part of an evolving platform product whereas SW Team 2 produces industry-
specific SW products. This study showed that one ALM solution does not necessarily fit
all teams in an organisation. The study showed that SW Team 1 needed a common way
to share and access the same type of information with the other platform projects.
Therefore, the organization can view and access consistent product platform related
information, for instance, faults or test reports, through a single channel based on prod-
uct structure. In SW Team 1, this meant that it was reasonable for the team to use the
same global product information management systems as other platform projects, i.e. a
feature management DB, fault management DB and test document management DB.
The lack of integration between the commercial ALM tool (TFS) and company's Notes
databases caused that TFS could not be used for managing all lifecycle artefacts. The
use of consistent practices and tools over related development projects has also been
stressed in the telecommunication industry [19]. On the other hand, for SW Team 2 the
single central ALM solution has worked well since they do not have strong relations to
the platform level. One challenge with several databases is that often their functionality
and managed information overlaps [14, 18]. The same data is duplicated in various
applications that complicate the traceability and maintenance of data. In this case, this
has forced the organisation to build point-to-point integrations between different Notes
databases, for instance, between the fault management DB and test document manage-
ment DB. However, since these databases share the basic technology and the company
is very familiar with the Notes technology, the integration has been fairly easy to
implement.
The agile methods have been under active research for a decade. There are a num-
ber of commercial and open source tools that support the methods. In our case, the
company had the challenges of increasing globalisation and efficiency demands.
Therefore, the company started to seek more integrated solutions and methods to
coordinate distinct project phases and to provide visibility into development projects.
In practice, this meant that the SW teams deployed a commercial ALM tool, Team
Foundation Server (TFS), with the Scrum process. The successful use of TFS to sup-
port Scrum methodology has been reported in [4]. However, Moore et al. [4] stated
that they needed to considerably tailor the TFS process template for their purposes.
The same problem was also noticed in our case [11, 12]. A challenge with the com-
mercial ALM solution was to find a suitable template for the projects. Since each
organisation has its own characteristics and needs, the challenge is to find efficient
implementations of lifecycle management for complicated, real-life situations. If the
ALM suite's process template library does not include a suitable process template for
an organisation, the modifications to a standard template or creation of a new template
from scratch might need significant effort. Therefore, teams wanted to keep the
changes in a standard template minor even though the basic template was not optimal.
This was the opposite approach if compared to Moore et al. [4] since in their study the
company made considerable modifications. One interesting study related to the adap-
tation of TFS process templates is presented in [24]. Medina-DomÃnguez et al. pro-
pose the project pattern concept and a model to support process improvement based
on patterns in a TFS environment.
