SEKE 2012 Proceedings - Knowledge Systems Institute

shared repository and specialized code [6]. Open hypermedia
adapters can also be used to create traceability links across tool
boundaries [3]; we build upon th is technique to automatically
capture traceability links. Information retrieval techniques may
be used to address the explos ion of the artifact space [9, 11,
15]. Finally, centrally managing all the artifacts in one tool
[24] may be used to address traceability link maintenance.
C. Social Perspective
The social perspective has equally important challenges that
arise from the interaction of stakeholders with traceability, such
as differing e xpectations and low use r motivation. I t is
recognized that people play a crucial part in deter mining the
quality of traceability links [4, 15]. Be cause of diffe rent
stakeholder expectations [13], it is difficult to create a general
traceability tool that caters to these different stakeholders. This
difficulty can be addressed by developing customized tools [6,
26]. In addi tion, software engineers ge nerally have low
motivation to perform traceability tasks [18]. Providing
incentives to engineers or integrating traceability tasks into the
development process may address these challenges [4, 6, 25].
D. Perspectives Interplay
We argue that the challenges from the economic, technical,
and social perspectives are interrelated. As an exam ple, let us
consider the following scenario. Because of the high cost of
manually capturing traceability links, an organization may
resort to automated techniques to ca pture traceability links
(e.g., [11]). However, since automated techniques cannot
achieve 100% accuracy [9], hum an analysts must still check
the recovered traces, which can be tedious [15]. Since the
number of tra ces to be exa mined can be high [20], manual
checking could lead to additional overhead costs. Thus, simply
addressing the challenges from one perspective is inadequate.
III. ADDRESSING THE CHALLENGES WITH ACTS
To holistically address the traceability challenges, we
present Architecture-Centric Traceability for Stakeholders
(ACTS). The key elements of ACTS are centering the links to
the architecture, enabling stakeholders to trace artifacts that are
of interest to them, and capturing links pr ospectively. We
focus on addressing the challenges of the cost of capturing
traceability links (ec onomic), ability to link across
heterogeneous tools and art ifacts (technical), and low user
motivation in performing traceability tasks (social).
A. Architecture-Centric Traceability
To address the technical challenges of tracing across
heterogeneous artifacts, we chose to center the tracea bility
links to the architecture, since it provides higher level concepts
than the code [12] and it ha s a more rigorous representation
than requirements [15]. T here is also an inherently c lose
relationship between the architecture and other artifacts in
software development: e.g., between r equirements and
architecture [22], between architecture and source code [23],
and between architecture and test cases [17]. Moreover, the
architecture itself contains information that a ids in
understanding the system and its related artifacts. The software
architecture provides a comprehensive view of the system,
enabling engineers to better understand the system in its
entirety as well as in its indi vidual computational units. This
understanding lends itself to understanding the traceability
links from the architecture to the various software artifacts. It
also aids in understanding the links across different syste m
versions and across software product lines [16]. Links centered
on the architecture can be updated to reflect system evolution.
We define software architecture broadly, as the set of
principal design decisions about a software system [28]. This
definition implies that ever y software system has an
architecture—some set of design decisions that were m ade in
its development. Principal design decisions can be expressed
as the system’s structure, functional behavior, interaction, and
non-functional properties; this pa per focuses on decisions as
expressed in the system ’s structure, e. g., the functional units,
the mode of communication between the functional units, and
the configuration of these units. These principal design
decisions provide product-based concepts by which traceability
can be anchored and supported.
B. Stakeholder-driven Traceability
To address the social challe nge of low motivation, we
enable different stakeholders to bot h capture and use the
traceability links they capture, which we call stakeholderdriven
traceability. Stakeholders are indivi duals who ha ve a
vested interest in capturing relationships between soft ware
artifacts. Oftentim es, the stakeholder who captures the
traceability links is not the sam e stakeholder who uses the
links, causing a separation between the work and the incentive
to perform the work [4]. We believe, however, that i t is
imperative for stakeholders who invested time in capturing the
traceability links to also be able to use the links.
To achieve stakeholder-driven traceability, the tool support
must satisfy th e following requirem ents. F irst, the tool m ust
cater to varied stakeholder in terests in capturing traceabi lity
links. For example, a requirements analyst may be interested in
tracing high level to low level require ments while a
maintenance engineer may be interested in tracing architecture
to source code. Thus, the tool support must decouple the
heuristics of deter mining the traceability links from the tool
itself, to allow stakeholders to specify which artifacts to tr ace.
Secondly, the tool m ust enable stakeholders to use the
traceability links they captured. To be usable, the links should
be accessible (i.e., traced artifact s are vie wable within the
context of its native editor), updateable, and maintainable.
C. Tracing Links Prospectively
To address the economic challenge of overhead cost, we
capture traceability links autom atically in the background, in
situ while artifacts are gener ated or e dited. This prospective
technique is complementary to retrospective techniques which
recover links after the fact [9, 11, 15]. The online capture of
links can ensure that important information is not neglected or
overlooked due to lack of resources or tim e [29]. The idea of
tracing prospectively is not ne w [24], but it was only recently
that this approach became feasible [19]. Empirical evidence
reveals that traceability links captured in this manner are often
useful [27].
413