Supporting Traceability in Distributed Software

Shared by: byt34827

Tags

requirements traceability, software engineering, distribution software, requirements engineering, software artifacts, supply chain, traceability solutions, software development, software artefacts, use cases, international conference, software maintenance, food traceability, manufacturing software, international conference on software engineering

Stats

views:: 6
posted:: 3/22/2010
language:: English
pages:: 14

Public Domain

Document Sample

Supporting Traceability in Distributed Software
Development Projects

Timo Wolf∗ and Allen H. Dutoit†

Abstract. Traceability is the ability to follow the life of a requirement, both in forward and backward
directions. Traceability facilitates dealing with change, by identifying which components may be im-
pacted and by identifying which stakeholders may need to be consulted when speciﬁc requirements
are revised. Rationale is the justiﬁcation behind decisions, including alternatives explored, evaluation
criteria, arguments, and decisions. In typical projects, little traceability or rationale is explicitly doc-
umented, because of the overhead and cost of capturing and maintaining this information. Instead,
this information is often exchanged among stakeholders informally and during peer review activities
or reconstructed when changes or issues arise. In distributed projects, opportunities such information
exchanges are signiﬁcantly reduced, resulting in even less traceability and rationale being captured.
However, this information is critical when assessing the impact of changes, as few participants in a
distributed setting have a complete overview of the system and the stakeholders involved.

In this paper, we propose a model and tool support for uniformly representing and integrating system
models and rationale. We support traceability within and across these models. Participants collab-
orate by attaching annotations, action items, and issues to the system models, providing the relevant
collaboration context. By dealing with all three types of information together, we aim to increase
their value, to decrease the overhead and cost of capturing and maintaining rationale and traceabil-
ity, while providing participants an incentive for maintaining their consistency. To follow existing
traces and dependencies across system models and rationale, we provide alternate graphical user
interfaces that focus on clear and simple design and on desired tasks.

1. Introduction

Driven by the global market and resource requirements, distributed software development has become
typical in technology companies. In contrast to single site projects, communication and coordination
issues, as well as language and cultural differences are major challenges within global projects [1, 8]
and are responsible for reduced productivity and success [11]. It is quite common that large industry
projects split the development into subsystems and assign them to different sites. Each subsystem
realizes coherent features and can be developed more or less independent of the other sites. There-
fore, interest among sites decreases, less information is exchanged and the awareness of other sites’
progress, problems, and decisions is minimal. Problems become visible and are confronted only
when integrating subsystems, resulting in long integration cycles [8]. The interfaces among major
subsystems are not sufﬁcient for preventing such surprises at integration. Increasing the awareness
∗
a u
Chair for Applied Softwareengineering, Technische Universi¨ t M¨ nchen, email: wolft@in.tum.de
†
a u
Chair for Applied Softwareengineering, Technische Universi¨ t M¨ nchen, email: dutoit@in.tum.de
of the other sites development state, including problems and upcoming changes, is a key factor for
increasing collaboration and trust among sites, and consequently, increasingly their ability to prevent
or solve integration problems [1].

Software development projects need to deal with change during the whole life cycle. A variety of
changes occur during development, including requirements changes triggered by the client, architec-
tural changes triggered by technology enablers, and stakeholder changes, including new clients, end
users, or project managers. Because dependencies among development artifacts, a single change can
impact many other artifacts. Traceability is a key success factor for long-term projects. Dependency
links between stakeholders, requirements, design and implementation are captured and maintained to
identify change impact on models and the system, as well as identify critical, decision making stake-
holders [12, 9, 10]. When developing in distributed settings, the need for traceability increases, as the
information exchange and awareness of other sites decreases and the identiﬁcation of change impact
becomes more difﬁcult.

Rationale is the justiﬁcation behind decisions, including alternatives explored, evaluation criteria, ar-
guments, and decisions. While requirements and design decisions are captured in system models,
their rationale is gradually lost as participants move to other projects or as their memories fade. The
assumption behind rationale management is that externalizing rationale, making it available to project
participants, and structuring it for long-term use can increase the quality of decisions, increase trust
and consensus among stakeholders, and facilitate changes to existing systems [15]. While the useful-
ness of rationale management has been shown in speciﬁc cases, the overhead associated with training
participants and formalizing knowledge remains a signiﬁcant obstacles during development [16].

In this paper, we propose a model for uniformly representing traceability and rationale within the
context of a system model. Annotations, in the form of comments, action items, or issues, are used as
a lightweight communication mechanism and for making status information explicit. System models
and annotations are represented as a generic graph. Relationships among system models and anno-
tations are captured, either automatically or manually depending on the task at hand. Pre- and post
traceability are then supported by following these links. For example, when assessing the impact of a
requirement change, a user can ﬁnd all likely impacted requirements, test cases that would need to be
adapted and rerun, related nonfunctional requirements, and components that need to be reviewed or
changed. Similarly, when changing a component, all requirements that are related to the component
can be identiﬁed and retested, and critical stakeholders who need to be consulted can be found.

By putting equal emphasis on system elements and annotations, implicit relationships that are other-
wise not captured in the system model can be inferred. For example, it is relatively straightforward
to maintain explicit trace links between functional requirements (e.g., use cases) and the components
in which they are realized. Conversely, tracing nonfunctional requirements to their corresponding
architectural decisions is more complex. In our model, nonfunctional requirements can be used when
assessing different options for addressing an issues. This enables the developer to follow traces be-
tween system elements that are connected through an annotation.

The proposed model is supported by a tool suite called SYSIPHUS [19]. SYSIPHUS is a distributed
multi-user application that enables users to collaborate synchronously on the same system models
(e.g. use cases, classes, components), documents (e.g. requirements analysis document, system de-
sign document), and annotations. Users familiar with CASE tools access SYSIPHUS with a graphical
desktop application called RAT [18]. Users more familiar with a document management metaphor
access SYSIPHUS through a web application called REQuest [6]. SYSIPHUS also includes an aware-
ness component that notiﬁes users of relevant changes. Starting at a speciﬁed element, a traceability
wizard facilitates the identiﬁcation of change impact and exploration of the model, including system
models, documents, and annotations.

This paper is structured as follows. Section 2. introduces our generic graph model and shows how it is
used to realize concrete system models. Section 3. describes the annotation model, including issues,
comments, and action items, and describes its relation to the system models. Section 4. illustrates
how different traceability scenarios are supported. Section 5. summarizes the current status of the
tool suite. Section 6. discusses the case studies we have done so far. Section 7. discusses our model
in the light of related work. Section 8. concludes this paper.

2. System Models

In SYSIPHUS, models are represented as a graph. The graph consists of two classes, ModelElement
and ModelLink. All system model elements (e.g. use cases, nonfunctional requirements) and
collaboration elements (e.g. comments, issues, action items) inherit from the ModelElement class.
A model element can have an arbitrary number of links to other model elements. A link is represented
by the class ModelLink and refers to exactly two other model elements. The class ModelLink
is also a model element and can be connected by other links to any number of model elements. The
graph provides a generic and extensible basis for all concrete model elements. Figure 1 shows the

2
ModelElement

*
ModelLink

InitiatingActor 0..1 1
UseCase
UseCaseLink
* 1
Actor

Figure 1. The UML class diagram shows the generic, type-less graph and an example of a typed reﬁnement
representing a use case and an actor. The InitiatingActorUseCaseLink reﬁnes the ModelLink and deﬁnes
the initiated use cases of an actor.

graph and illustrates the typing mechanism by adding a use case and an actor model element. Both
extends the class ModelElement. To deﬁne that an actor may initiate many use cases, a class
InitiatingActor UseCaseLink is used. It reﬁnes the class ModelLink by connecting only
actors with use cases.

S YSIPHUS stores all model elements in a central repository, tracking authorship and changes, and
providing access control. Users access model elements in the context of a document. In SYSIPHUS,
a document is a view of the model customized for a speciﬁc activity or role. Documents can be cus-
tomized for each project. A document is deﬁned in terms of sections and subsections, each containing
either text, a diagram, or a ﬁlter. The ﬁlter mechanism is used to attach any selected model elements
into the sections. A ﬁlter is deﬁned as a class of element (e.g., a use case) and an optional number
of property name and values (e.g., priority = high). For example, a requirements section may contain
all use cases and a use case diagram. A management document may contain a section with all use
cases with a high priority. When changing a use case, both documents are kept consistent, because
all sections display the same model. Assuming the priority of a use case changes from low to high,
the use case stays in the requirements section but dynamically appears in the management document.
To enable collaboration with external stakeholders, SYSIPHUS can export a document into ﬁles of
different formats, such as PDF or RTF. Figure 2 illustrates the document model used in SYSIPHUS
and adds some selected model element classes (only selected class shown).

ModelElement *
Service

Component

Class
Document *
TestCase * Section

* Criterion

Composite Leaf
Section Section
*
Contrained Nonfunction
DesignGoal TestCriterion
Element Requirement

0..1 *
UserTask UseCase

Figure 2. S YSIPHUS document structure (UML class diagram), only selected classes depicted for illustration.

3. Annotation Models

In SYSIPHUS, users collaborate by linking annotations to model elements. Comment, Issue and
ActionItem are the main classes within this model. All inherit from the Annotation class.
Annotation inherits in turn from ModelElement. Consequently, annotation elements have the
same importance as system model elements and, unlike other tools, are treated as ﬁrst class objects.
Annotations can also be included into document sections, in the same way system model elements
are. For example, a requirements speciﬁcation or an architecture document typically has an open
issue section, listing the annotations of class Issue whose status property is open. Figure 3 shows
that a single model element (e.g. use case, class, component) can be annotated by many annotations
and a single annotation can be linked to many model elements. Therefore, the annotations can be
used to represent complex relationships, relating many system and annotation elements from different
stakeholders.
ModelElement *

Annotation *

1 1
Comment ActionItem
* Issue *
* *
*
1
* *
Option Criteria Resolution

Assessment

Figure 3. S YSIPHUS annotation model (UML class diagram).

Comments are a simple, informal, and unstructured way for project participants to communication,
similar to a newsgroup. S YSIPHUS does not impose any rules on the usage of comments. Project par-
ticipants can reply to existing comments, creating discussion threads. Unlike newsgroups, comments
and replies can be attached to many model elements, providing a context for the discussion.

While comments are suited for supporting light-weight, short-term collaboration, such as requesting
clariﬁcations or indicating superﬁcial problems, they are not sufﬁcient for long-running or complex
design discussions involving conﬂicting criteria and many alternatives. To support such discussions,
SYSIPHUS provides an issue model similar to QOC (Questions, Options, Criteria, [13]), including
elements for representing options (i.e., alternatives under consideration), criteria (i.e., qualities, such
as nonfunctional requirements or design goals, that should be used to evaluate the alternatives), and
assessments (i.e., a judgment indicating how well an option satisﬁes a criterion). We selected QOC
instead of the more popular IBIS model (Issue Based Information System, [4]) as we observed that
users often reverse engineer issue models from threaded discussions (as opposed to structuring them
on the ﬂy). Once an issue has been discussed and resolved, users can plan the resulting work in terms
of action items.

S YSIPHUS supports a simple task model, consisting of Action Items. An action item has a de-
scription, a status, a due date and can be assigned to any project participant. Users can decompose an
action item into more detailed action items. Like all annotations, they can be attached to any number
of model elements, to indicate which elements are likely to change in the process of accomplishing
the task.

The annotation elements of SYSIPHUS have been designed incrementally and based on the feedback
of SYSIPHUS users. Our goal is to strike a balance between spontaneous, informal collaboration,
and formal, long-term rationale capture. While using issue models for supporting daily collaboration
User Task Use Case Serivce Component Class NFR Test Case Annotation
User Task x x x
Use Case x x x x x x x
Service x x x
Component x x x x
Class x x x
NFR x x x x
Test Case x x x
Annotation x x x x x x x x
Table 1. Traceability matrix between selected model classes, supported by SYSIPHUS . A cross indicates a direct
link.

and design tasks introduces an unnecessary overhead [16], project participants need a mechanism for
documenting conﬂicts and their resulting agreements, as indicated by the experience with WinWin [2].
Our assumption is also that capturing such contentious issues can also help in future changes for
ﬁnding the human source of a criteria or for identifying indirectly related model elements. We discuss
how SYSIPHUS supports pre- and post-traceability next.

4. Pre- and Post-Traceability

Software development projects need to deal with change. It is quite common that changes occur
during the whole project duration to all artifacts. For instance, the requirements may change, when
project participants gain deeper knowledge of the problem domain. When new technology is iden-
tiﬁed, the current architecture may need to be adapted. To maintain consistency among models, the
related elements of a changed element needs to be evaluated and, if needed, updated. In addition to
identifying all related elements potentially impacted by the change, it is often necessary to identify
the human sources of these elements, as they may have tacit knowledge about how (or whether) the
change should be realized. Tracing from requirements forward, for example, to impacted design,
implementation, or test elements is called posttraceability. Tracing from requirements (or other
elements) back to their human sources is called pretraceability [12].

S YSIPHUS support post-traceability with two concepts. First, explicit links are used for tracing be-
tween the elements. These links are part of the model (e.g. the InitiatingActor UseCaseLink
introduced in section 2.). Table 1 shows selected traceability links that are supported by the default
model. To increase the usability of the tracing, the user can ﬁlter and search within the traceability
graph. Moreover, all elements that might be impacted by a change, can be automatically annotated
with action items. These action items mark that a model element has been identiﬁed as impacted by
a change but still needs to be reviewed.

The second post-traceability concept is based on annotations. Users create annotations, for example
issues, to several model elements. This implies that the model elements have a relation. As anno-
tations are also model elements, a user can trace over annotation links to ﬁnd related elements. For
example, a component can take part in the discussion related to an issue with a number of nonfunc-
tional requirements used as criteria in the resolution of the issue. Even if the component is not directly
related to these nonfunctional requirements, the user will be able to ﬁnd them by tracing through the
issue.
Pre-traceability is supported similarly, by enabling the user to examine the author of a model element
in relation to its use in an issue. For example, by examining who wrote a speciﬁc nonfunctional
requirement and how it was used as a criteria when resolving an issue, the user can identify which
qualities are critical for each stakeholder. This use of issue model is similar to the WinWin process
and tool [2].

5. The Sysiphus Tools

In this section, we describe SYSIPHUS [19], a distributed environment that supports the conceptual
model and traceability scenarios outlined in the previous sections. S YSIPHUS is composed of a suite of
tools centered on a repository, which stores all models, rationale, and user information. The repository
controls access and concurrency, enabling multiple users to work at the same time on the same models.

Users access models either through a web interface (REQuest [6]) or a graphical user interface
(RAT [18]). Both interfaces access the repository through a common model layer that deﬁnes the
type of elements and links. The model layer can easily be extended to accommodate new element and
link types, as dictated by the needs of a project. The model layer in tern uses the SYSIPHUS repository
for persistency and for pushing changes to other users.

With the web interface users can access the repository from a variety of environments (e.g., lab, home,
ofﬁce) without the installation of additional software. It is divided into two parts, one for accessing
and modifying the system models, the other for accessing the discussion threads, rationale and action
items. Users can trace from the system models to relevant collaboration models and back.

The graphical user interface (see Figure 4) provides a UML view over the models, adopting the look
and feel of typical UML modeling tools. The graphical user interface is typically used for drawing
diagrams and, with drag and drop interaction styles, offers more intuitive ways to specify relationships
among model elements than the web interface.

While using a uniﬁed model for representing system models and annotations facilitates the use of
traceability links, usability and visualization issues have been as critical to our goal of lowering the
overhead of capturing this information. For example, displaying the entire traceability graph quickly
overwhelms the user, given the number of interrelationships among elements in realistic models.
Instead, we evaluated various features for ﬁltering links and for providing a starting element.

In the next subsections, we single out three features of SYSIPHUS that illustrate these issues: aware-
ness, traceability table, and traceability wizard.

5.1. Awareness

Within distributed projects, awareness of the other sites work progress, including development ar-
tifacts, documentation, and problems is a major key to reduce misunderstandings, redundant work
and to increase the trust across sites. Awareness helps to identify critical issues early and gives the
possibility to resolve issues in time [3, 1, 8]. SYSIPHUS supports awareness of new model elements,
modiﬁcations, and deletions by notifying project participants via email. Therefore, the notiﬁcation
range from documents, system models (e.g. use cases, components, classes), to issues, or action
items. To avoid broadcasting of all changes to all project participants, SYSIPHUS enables the users to
conﬁgure the kind of changes they want to be notiﬁed of. They can choose speciﬁc model element
Figure 4. Screenshot of the graphical user interface RAT.

classes like use case, component, issue or task, resulting in an email, if any elements of these classes
are created, modiﬁed, or deleted. In addition, they can select existing documents or sections of docu-
ments they want to be notiﬁed of. For instance, a user chooses the requirements analysis document,
than he is informed of all text modiﬁcations of the sections, and of all modiﬁcations to use cases in-
cluded in the document. In addition, SYSIPHUS enables the user to restrict the notiﬁcations to changes
of speciﬁc persons. Notiﬁcation emails in hourly, weekly, or monthly periodic intervals, containing
all changes that occurred. To each change, the responsible person, the date and time and a URL to the
model element within S YSIPHUS is included.

5.2. Traceability Table

S YSIPHUS supports two main graphical interfaces to visualize and follow traceability links. Both
focus on the reduction of complexity, to support the users in daily work tasks.

The ﬁrst view displays all elements as a table 5, with one element per row. Element properties are
displayed in the columns. The columns also include the target elements of the traceability links. For
instance, the ﬁgure 5 displays the use cases of an example project, containing Open Annotations and
Realizing Classes. The user can access the properties of any displayed element by double-clicking on
its name. Users can also conﬁgure which columns are displayed for a speciﬁc element class. The rows
can be sorted by column, and the content can be searched and ﬁltered. Hence, the tables are useful
for inspection and review tasks. For example, a user can identify critical use cases by displaying all
use cases and sorting for open issues. Alternatively, all use cases without a corresponding system test
case can be displayed.

Figure 5. A screenshot of the traceability table view, containing use cases. The complexity of displaying traces is
reduced, by adding the trace targets in columns and using a label of the traceability link as column header.

5.3. Traceability Wizard

The second traceability view is graph based and focuses only on the context surrounding a single
element, which is displayed in the center of the graph pane. All its traces and its related elements
are displayed. The layout differs for annotations (issues, comments, and tasks) and the rest. It is
separated into four areas: left, right, top and bottom. The sub graph associated with a system element
is drawn so that all incoming system links are depicted on the left and all outgoing system links
on the right. Annotations attached to the system element are displayed below it while constraining
elements (e.g., nonfunctional requirements) are displayed on the top. In other terms, the horizontal
axis displays system model dependencies while the vertical axis displays rationale information. As
the graph focuses on only one element, traces between other displayed elements are hidden.

Figure 6 shows a sequence of screenshots of the traceability graph. The graph is interactive and en-
ables the user to click on a displayed element to set a new focus. Double clicking on an element opens
the element in a new pane that displays its properties and enables its modiﬁcation. Each screenshot
shows the graph after the user clicks on a traced element, starting at the actor Customer. From the
Customer, he clicks on the user tasks Buy Article, than to the use case Pay for Article,
followed by the issue How should the customer input commands? and ending at the
quality constraint Familiarity with Checkout Procedure.

6. Evaluation

Our approach to evaluating and reﬁning SYSIPHUS has been incremental. We have used a software
engineering project course at our chair to explore and debug initial ideas [7]. We have used this project
course as a ﬁrst approximation of a distributed project, as students work part time, from different
locations, and usually do not know each other before the start of the course. Moreover, students elicit
requirements and deliver a system to an actual client external to the university. In a second phase, once
we take into account feedback from the project course, we then have used documents and feedback
from industrial partners to assess how realistic our ideas would be in real project. This enables us to
study aspects related to scale and long term use that we cannot assess in an academic environment.

During the winter semester 2003/04, about 30 students developed a prototype forecasting system for
the Wacker chemical company. SYSIPHUS was used for developing the requirements analysis and the
system design documents. The requirements analysis document turned out to be one of the primary
client deliverable for this project for the Wacker IT department for realizing a production version of
the system. During the winter semester 2004/05, about 25 students worked developed CampusTV, a
Figure 6. A sequence of screenshots of the traceability graph. Each screenshot shows the graph after the user clicks
on a traced element.

prototype system for supporting interactive and distributed lectures, based on digital video broadcast
(DVB-T). The hardware transmitters were provided by the company and our client Rhode & Schwarz.

In both projects, annotations in SYSIPHUS were used for ad hoc collaboration (clariﬁcation ques-
tions, discussion of design issues) and for tracking open changes. Change requests were indicated
as challenge questions that were then closed by the participant who implemented the change. This
made it possible by instructors to monitor and address potential problem areas. In addition, we recog-
nized that the student awareness of other teams work, was much higher that in project courses before.
The students noticed open issues of other teams and were enabled by the given traced system model
context to understand, help and collaborate across teams.

To assess our traceability model for an actual project, we used a set of documents from an industrial
project developing a communication framework for enterprise phone applications. At the time, the
project had been running for about nine months, included about 40 people, and was about to be dis-
tributed to four different sites, growing to about 100 participants. We selected about 120 use cases and
100 nonfunctional requirements from their requirements documents, and entered in SYSIPHUS traces
for these requirements, including links to design components, and system tests. The documents we
examined also included annotations which we also entered in SYSIPHUS. We then used the entered
models as examples to elicit feedback during interviews with key individuals, then with project man-
agement, and ﬁnally with all relevant persons as a group. Several participants interviewed had taken
part in distributed projects and had used DOORS [17] as a requirements management tool.

While this study is still ongoing, there are several preliminary lessons learned that we were already
able to draw:

• Different roles are involved in creating and using the traceability links. For example, architect
or senior developers are typically responsible for linking requirements to components, whereas
product managers and requirements engineers need change impact knowledge when prioritizing
requirements. When the individuals involved are in different sites, we think that the likelihood
that traceability links are entered is much reduced.

• Individuals entering requirements in the tool are not necessarily the stakeholders who origi-
nated the requirements, as pointed out by Gotel [10]. However, architectural and development
decisions seem more easily traceable to their authors.

• The project we studied was organized in four week iterations, at the end of which a product
increment, including both documentation and code, was validated. We think that such fast pace
iterations are necessary to keep the model up-to-date so that different sites use annotations on
the model to collaborate. Conversely, we think that the value of traceability through annotations
would be reduced in projects were documentation either precedes the product or is reconstructed
after the product is stable.

In summary, the observations we collected so far seem to indicate that the traceability model presented
in this paper could be deployed and useful in a distributed development environment. However, we
also observe that missing traceability links will probably be most often those between model elements
owned by different sites or by different roles. In this case, it is critical that sufﬁcient collaboration
(either in the form of informal comments or formal issues) occurs over the model to make up for this
deﬁcit. In either case, this phenomenon would have to be studied with models or documents produced
by a distributed project running for a longer period of time.

7. Related Work

Ebert and Neve summarize in Surviving Global Software Development [8] experiences and best prac-
tices for global distributed software development projects. The results focus on project organization
structures, process management and integrated workﬂow management. They stated out that one of the
real challenges is to spread the awareness, communication and knowledge to all development levels
and sites in real time, specially when different cultures and languages are involved. Within this paper,
we proposed a model and prototype implementation to increase these properties by realtime collabo-
ration on requirements and system models integrated with rationale knowledge and communication.
Traceability between requirements, system models and rationale knowledge and communication is
supported to identify change impact as well as critical stakeholders.

Battin, Crocker and Kreidler describe in [1] the main issues and solutions of a global distributed
project from Motorola. Main issues they encountered are the loss of communication richness be-
tween different sites and a centralized software conﬁguration management. The solution approach
for the loss of communication richness includes the exchange of documents and work products over
the intranet, using a web site for each site. S YSIPHUS follows the same principle, as all artifacts
like documents, models, rationale and communication elements are located in a central repository,
accessible from all sites. Thus, awareness of the other site’s work increases and foreign experts can
be found.

Chisan and Damian developing a model of awareness support in software development in GSD [3].
They propose a workspace, containing all development artifacts like the requirements or the de-
sign document, which support notiﬁcation to relevant project participants, when the content of the
workspace changes. To avoid broad cast notiﬁcation, the model proposes artifact dependencies to no-
tify selected people only. We agree to the need of awareness in distributed software development and
have already implemented aspects of the proposed model. Our approach consists of a central reposi-
tory containing all development artifacts that are an extension of a generic graph model. Our concrete
development artifacts range from documents (e.g., requirements, design, test) to UML models like
use cases, classes, or components to design rationale based on QOC [13]. Awareness is already sup-
ported as developers can subscribe to their project and gets notiﬁed when elements changes. Instead
of getting notiﬁed about all changes they can deﬁne the artifact class or the document sections they
want to be aware of. Notiﬁcation of depending artifacts is not supported right now, but would be a
consequence of our traceability approach as proposed within this paper.

Mockus and Herbsleb show in [14] the need for ﬁnding experts in distributed projects. They intro-
duced a tool that supports the measurement of expertise and expert searching in terms of people or
organizational units. The tool works on the data of version control systems (VCS), capturing deltas
of ﬁles. In addition, author information, modiﬁcation dates and a change log are captured. The tool
enables the browsing and searching of work products and expertise-based identiﬁcation of people.
The work products are mainly source code ﬁles and are visualized as a product hierarchy resulting
from the source code directory structure. VCSs are very good in dealing with text ﬁles, but they
have problems when working on binary ﬁles, which are mainly used by CASE tools to store models.
Often, MS Word ﬁles are used to create the project documents, containing images of diagrams. The
SYSIPHUS server component is capturing similar change data as a VCS. Therefore, the same approach
as in [14] could be used to identify experts within the requirements, system models, rationale knowl-
edge, or within the communication elements. The introduced traceability concepts would further help
to identify dependencies among experts, expertise, and work products in terms of model elements.

Dellen, Kohler and Maurer propose in [5] methods and techniques to extract automatically causal
dependencies between decisions from development tasks decompositions and from the information
ﬂow of ﬁne-grained software process models. The decisions are part of rationale information and
supported with cons and pros. Decisions are made during tasks, which are part of the process model.
The decisions of a task are inﬂuencing depending tasks. The application of their approach overlaps
to ours. The dependencies are used to identify change impact, when a decision changes or becomes
invalid. In opposite to our work, they focus on a process model and use development artifacts as
inputs and outputs for tasks. We focus on all kinds of development artifacts and support direct links
between them and rationale, capturing the reasoning behind them and providing a context to resolve
issues.

8. Conclusion and Future work

In this paper we described a model to capture and manipulate development artifacts, such as docu-
ments, requirements, system models as well as rationale knowledge and dependencies. Pre- and post-
traceability between system models are supported and in particular, traceability between rationale and
system models. We observed that visualizing and working on these linked models is challenging, as
the complexity of traces increases quickly. Consequently, we evaluated alternate graphical interfaces
supporting the user in focusing on desired traces.

Currently, we support only manual traceability, in which a user can only navigate between depending
elements. Intelligent ﬁlters, searches and automated operations are needed on the traceability graph
to work with a large amount of data. For instance, SYSIPHUS users have to identify change impact on
design elements manually, when changing a requirement. Ideally, the system should support change
impact by resulting a set of elements that should be revised, while not returning all reachable elements.

The collaboration with an industrial project helped us to identify the needs of distributed development
and assess the current version of our traceability concept. We gathered qualitative observations by
surveying large student development projects and to evaluate our increments. However, the work is
still in progress and more evaluations are needed.

References
[1] Robert D. Battin, Ron Crocker, Joe Kreidler, and K. Subramanian. Leveraging resources in
global software development. IEEE Software, pages 70–77, March/April 2001.

[2] Barry W. Boehm, Alexander Egyed, Julie Kwan, Daniel Port, Archita Shah, and Raymond J.
Madachy. Using the winwin spiral model: A case study. IEEE Computer, pages 33–44, July
1998.

[3] James Chisan and Daniela Damian. Towards a model of awareness support of software develop-
ment in gsd. In The 3rd International Workshop on Global Software Development, pages 28–33,
May 2004.

[4] Jeff Conklin and K. C. Burgess-Yakemovic. A process-oriented approach to design rationale.
Human-Computer Interaction, 6(11):357–391, 1991.

[5] Barbara Dellen, Kirstin Kohler, and Frank Maurer. Integrating software process models and
design rationales. In Knowledge-Based Software Engineering Conference, volume 11, 1996.

[6] Allen H. Dutoit and Barbara Paech. Rationale-based use case speciﬁcation. Requirements En-
gineering Journal, 7(1):3–9, 2002.

[7] Allen H. Dutoit, Timo Wolf, Barbara Paech, Lars Borner, and Juergen Rueckert. Using ratio-
nale for software engineering education. In Timothy C. Lethbridge and Daniel Port, editors,
18th Conference on Software Engineering Education and Training, pages 129–136. IEEE, April
2005.

[8] Christof Ebert and Philip De Neve. Surviving global software development. IEEE Software,
pages 62–69, March/April 2001.

[9] Orlena Gotel and Anthony Finkelstein. An analysis of the requirements traceability problem. In
International Conference on Requirements Engineering, pages 94–101, Colorado, April 1994.
IEEE.
[10] Orlena Gotel and Anthony Finkelstein. Contribution structures. In International Symposium on
Requirments Engineering, pages 100–107. IEEE, March 1995.

[11] James D. Herbsleb and Audris Mockus. An empirical study of speed and communication
in globally distributed software development. IEEE Transactions on Software Engineering,
29(6):481–494, June 2003.

[12] Matthias Jarke. Requirements tracing. Communications of the ACM, 41(12):32–36, December
1998.

[13] Allan MacLean, Richard M. Young, Victoria M.E. Bellotti, and Thomas P. Moran. Questions,
options, and criteria: Elements of design space analysis. Human-Computer Interaction, 6(3-
4):201–250, 1991.

[14] Audris Mockus and James D. Herbsleb. Expertise browser: A quantitative approach to iden-
tifying expertise. In International Conference on Software Engineering, pages 503–512, May
2002.

[15] Thomas P. Moran and John M. Carroll. Design Rationale: Concepts, Techniques, and Use.
Lawrence Erlbaum Associates, January 1996.

[16] Simon Buckingham Shum and Nick Hammond. Argumentation-based design rationale: what
use at what cost? Int. J. Hum.-Comput. Stud., 40(4):603–652, 1994.

[17] Telelogic. http://www.telelogic.com, 2005.

[18] Timo Wolf and Allen H. Dutoit. A rationale-based analysis tool. In Walter Dosch and Narayan
Debnath, editors, Proceedings of the ISCA 13th International Conference on Intelligent and
Adaptive Systems and Software Engineering (IASSE’04), pages 209–214. ISCA, July 2004.

[19] Timo Wolf and Allen H. Dutoit. Sysiphus at http://sysiphus.in.tum.de, Mai 2005.

Related docs