Supporting Traceability in Distributed Software
Shared by: byt34827
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 . 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 . 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: firstname.lastname@example.org † a u Chair for Applied Softwareengineering, Technische Universi¨ t M¨ nchen, email: email@example.com 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 . 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 . 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 . 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 . 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 . Users more familiar with a document management metaphor access SYSIPHUS through a web application called REQuest . 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, ), 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, ) 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 , project participants need a mechanism for documenting conﬂicts and their resulting agreements, as indicated by the experience with WinWin . 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 . 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 . 5. The Sysiphus Tools In this section, we describe SYSIPHUS , 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 ) or a graphical user interface (RAT ). 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 . 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  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 . 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  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  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 . 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 . 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  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  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  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  Robert D. Battin, Ron Crocker, Joe Kreidler, and K. Subramanian. Leveraging resources in global software development. IEEE Software, pages 70–77, March/April 2001.  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.  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.  Jeff Conklin and K. C. Burgess-Yakemovic. A process-oriented approach to design rationale. Human-Computer Interaction, 6(11):357–391, 1991.  Barbara Dellen, Kirstin Kohler, and Frank Maurer. Integrating software process models and design rationales. In Knowledge-Based Software Engineering Conference, volume 11, 1996.  Allen H. Dutoit and Barbara Paech. Rationale-based use case speciﬁcation. Requirements En- gineering Journal, 7(1):3–9, 2002.  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.  Christof Ebert and Philip De Neve. Surviving global software development. IEEE Software, pages 62–69, March/April 2001.  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.  Orlena Gotel and Anthony Finkelstein. Contribution structures. In International Symposium on Requirments Engineering, pages 100–107. IEEE, March 1995.  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.  Matthias Jarke. Requirements tracing. Communications of the ACM, 41(12):32–36, December 1998.  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.  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.  Thomas P. Moran and John M. Carroll. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, January 1996.  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.  Telelogic. http://www.telelogic.com, 2005.  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.  Timo Wolf and Allen H. Dutoit. Sysiphus at http://sysiphus.in.tum.de, Mai 2005.