Sysiphus: Enabling informal collaboration in global software ...

Sysiphus: Enabling informal collaboration in global software development Bernd Bruegge, Allen H. Dutoit, Timo Wolf Technische Universit¨at M¨unchen Department of Informatics Chair for Applied Software Engineering Boltzmannstrae 3 D-85748 Garching, Germany {bruegge, dutoit, wolft}@in.tum.de

Abstract In global software projects, informal communication across sites is severely hampered, making it difficult to disseminate implicit knowledge. Participants have a partial view of the overall organization, do not have access to the complete rationale behind decisions, and when changes arise, participants from other sites are surprised. Consequently, issues that could be clarified almost immediately require days until the relevant stakeholders are identified, the issues are understood, and a resolution is agreed upon. We focus on the specific problem of externalizing issues with their context, stakeholders, and organizational roles in distributed settings. The challenge is to capture sufficient knowledge as a side effect of development, while structuring it for long-term use. We describe S YSIPHUS, a distributed environment providing a uniform framework for system models, collaboration artifacts, and organizational models. S YSIPHUS encourages participants to make communication and issues explicit in the context of system models and become aware of relevant stakeholders.

1

Introduction

Distributed development is increasingly common in global companies [1, 13]. Primary drivers include: mergers and acquisitions, which yield development organizations partitioned along the boundaries of the acquired companies; the scarcity of skills and variations in labor costs as a function of geographical location; customization and support at the client site. While global companies, benefiting from a large pool of skill and experience, have the potential to be more responsive and have a shorter time to market, collaboration in global projects is difficult at best and may results in slower development speeds [16].

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

Researchers have noted the importance of communication and collaboration in software development [6, 15, 16, 19, 24]. Curtis et al. [6], in a field study of several large projects, observed that documentation does not reduce the need for communication, in particular, during the early phases of the project, when stakeholders create informal communication networks to coordinate their representational conventions. They also observed that obstacles in informal communication (e.g., organizational barriers and geographical distance) can lead to misunderstandings in design conventions and rationale. Kraut and Streeter [19] note that formal communication (e.g., structured meetings, specifications, inspections) is useful for routine coordination while informal communication (e.g., hallway conversations, telephone calls, workshops) is needed in the face of uncertainty and unanticipated problems, which are typical of software development. They observed that the need for informal communication increases dramatically as the size and complexity of the software increases. Grinter et al. [15] studied several distributed projects that used different organizational models for coordination. They confirmed the findings of Kraut and Streeter about breakdowns in informal communication for the distributed case. Moreover, they found that the unequal distribution of participants and skills across sites and the difficulty in finding experts were recurring issues, independent of organization. Herbsleb et al. [16] found in a quantitative study of industry projects that cross-site work takes much longer than single-site work and requires more people. They also reported a strong relationship between the delay caused by cross-site work and the degree with which remote colleagues are perceived to help out when the workload is high. A recurring theme in these studies is that informal communication is critical for rapidly disseminating implicit knowledge, in particular, with respect to change and unforeseen events. During informal conversations, participants learn of upcoming changes and the potential impact

on their work. In global projects, informal communication is severely hampered, denying this informal knowledge to its participants. When a change or an issue is raised through formal channels, the recipients are often surprised, they do not have access to its underlying rationale, and they need time to identify and get in touch with the relevant stakeholders. Given the effort required to communicate across sites, ambiguities are glossed over, messages are misunderstood, and more issues are introduced into the project. Under high workloads, the requests from other sites are treated with a lower priority than those coming from local participants. Relationships between sites become adversarial, which further hinders collaboration. We focus on the problem of making visible impending issues and the stakeholders involved, and of raising awareness about these issues across sites. By making this information explicit, participants can more easily contact the relevant stakeholder and resolve issues more quickly. By providing mechanisms to raise the awareness of these issues to potential recipients, participants save time in anticipating such issues and avoid an information overload. The challenges of this approach are to capture sufficient information as a side effect of development while structuring this information for long-term use. To deal with these challenges, we have developed and evolved S YSIPHUS [12, 29, 30], an environment for distributed modeling and collaboration. The novelty of our approach is that system models, collaboration artifacts, and organizational models are given equal emphasis and live in a single, shared repository. System models represent aspects of the system, such as problem statements, requirements, architecture, detailed design, or test cases. Collaboration artifacts include informal comments about other models, issues, change requests, and action items. Organizational models depict the relationships among participants, and between participants and the system and collaboration models they create. This unified representation enables us to provide the same set of traceability and awareness services for all three types of models. This paper is structured as follows. Section 2 discusses our general approach. Section 3 describes how project participants create and access models. Section 4 describes how they can find explicit and implicit relationships in the repository, and thus better understand dependencies between their work and that of others. Section 5 describes how remote participants become aware of changes that might impact them. Section 6 describes our experiences with S YSI PHUS . Section 7 discusses S YSIPHUS in the context of related research. Section 8 concludes with lessons learned.

2

Approach

In S YSIPHUS, system, collaboration, and organizational models are represented as a single graph stored in a shared

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

repository. Documents and filters provide activity-specific views into the graph. Models, documents, and filters exist independently from each other and can be created in any order, thus increasing flexibility with respect to the process and the development method used. Participants access the repository through a variety of tools, based on their skills and their role. RAT, a rich client, provides a graphical user interface for creating models and diagrams, similar to commercial CASE tools such as IBM Rational XDE or TogetherJ. REQuest, a web-based client, provides a hypertext view of the repository, providing non-technical users access to the same models and diagrams from a document-based perspective. A notification service sends emails to selected participants to raise their awareness of changes in the model. A data analysis tool enables the visualization of metrics and accesses to the repository. S YSIPHUS enables the following: • Participants are able to directly attach collaboration artifacts to system models, thus capturing dependencies and rationale that are otherwise left implicit. For example, a design issue can relate a nonfunctional requirement to a system decomposition. • Regardless of the type of model under discussion, participants use the same types of collaboration artifacts, thus reducing the number of collaboration, modeling, and management tools to be learned. For example, issues can be used to justify requirements as well as system design and object design models. The status of issues can be used to track progress. • Traceability and awareness mechanisms provided by S YSIPHUS can be used uniformly for system, collaboration, and organizational models. For example, stakeholders can be identified by examining the authors of critical criteria relevant to issues that are attached to system models. • Changes are propagated to other participants working on the same model, enabling synchronous distributed modeling. For example, participants can modify the same class diagram at the same time from different locations, all seeing all changes consistently, including the position of nodes in diagrams.

3

Modeling in Sysiphus

The S YSIPHUS graph consists of elements of two classes: ModelElement and ModelLink. These classes provide generic and extensible mechanisms for persistent storage, tracking of authorship, access control, and history. All system model elements (e.g. use cases, nonfunctional

requirements), collaboration artifacts (e.g. comments, issues, action items), and organizational models (e.g., participants, teams) extend ModelElement. Associations between elements are realized by extending ModelLink. The abstract classes provide generic mechanisms for storage and link traversal, while their concrete subclasses are used for type checking (e.g., ensuring that only actors can initiate use cases) and providing specialized behavior (e.g., generating sequence diagrams from use cases). S YSIPHUS provides generic services for exploring, searching, filtering, and analyzing the graph. As system, collaboration, and organizational models are part of the same graph, these services can be used to bridge the gap between modeling, collaboration, and awareness. The following subsections give an overview of selected models and their associations.

3.1

System Models

S YSIPHUS provides system models for a number of development activities, including requirements analysis, system design, implementation, test, and maintenance. These models include functional and nonfunctional requirements, use cases, components, class diagrams, sequence diagrams, state charts, and test cases. The system models are based on UML and extended by additional model element and link classes. For example, nonfunctional requirements can be linked to use cases, use cases can be linked to their realizing components and participating classes, and test cases are linked to the classes or use cases that they are testing. The model elements are organized and viewed in the context of documents or as a result of filters. A document is defined in terms of sections and subsections, each containing text, diagrams, or a filter. The filter is used to attach matching model elements to the sections. A filter is defined as a class of element (e.g., UseCase) and an optional number of property name and values (e.g., “priority = high” or “planned for release = 2”). Documents and filters are themselves model elements that are stored in the S YSI PHUS graph and can be customized for each project. For example, Figure 1 depicts the use case “Purchase Article” in the context of the “Requirements Specification” document. The subsection “3.1 Use Cases” includes a filter displaying all use cases. A management document in the same project contains a section that includes all high-priority use cases. When a new use case is created, it appears under the “3.1 Use Cases” subsection of the “Requirements Specification”. When the priority of “Purchase Article” is changed from low to high, this use case dynamically appears in the management document. When changing a use case, both documents are kept consistent, since both refer to the same model element (see Figure 2). At the beginning of a project, an initial set of documents,

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

consisting of the empty sections and their filters, enables a template-based development. They can be changed during a project and may serve as new templates for subsequent projects. To enable collaboration with external stakeholders, S YSIPHUS can export documents and filter results into files of different formats, such as PDF or RTF.

3.2

Collaboration Models

In S YSIPHUS, users collaborate by linking collaboration artifacts, called annotations, to model elements. Comment, Issue and ActionItem are the main subclasses of Annotation. Annotation inherits in turn from ModelElement. Consequently, annotations have the same importance as system model elements and, unlike in other tools, are treated as first class objects. Annotations can also be included into document sections, in the same way system model elements are. For example, a requirements specification or an architecture document typically includes an “Open Issues” section, listing the annotations of class Issue whose status property is open. A single model element can be annotated by many annotations and a single annotation can be linked to many model elements. Therefore, annotations can be used to represent complex relationships, for example, connecting system elements that are not directly linked. Comments are an informal and unstructured way for project participants to communicate, similar to posts in a newsgroup. Project participants can reply to existing comments, initiating discussion threads. Unlike in newsgroups, in S YSIPHUS comments and replies can refer to other model elements, including system model elements and other annotations, thus providing a detailed context for the discussion. While comments are suited for light-weight, short-term collaboration, such as requesting clarifications or indicating superficial problems, they are not sufficient for longrunning or complex design discussions involving conflicting criteria and trade-offs. To support these types of discussions, S YSIPHUS provides an issue model similar to QOC [22], including options, criteria, assessments, and decisions. We chose QOC instead of the more popular IBIS model [5] because we observed that users often reverse engineer issue models from threaded discussions (as opposed to structuring them on the fly). For example in Figure 1, the annotation “How should the customer input commands?” depicted at the bottom of the editor pane is an open issue on the use case “Purchase Article”. When issues or comments are attached to a model element, the icon depicting the model element is augmented with a red ball for an issue or a yellow note for a comment. These indicators quickly tell the user whether a model element is part of an ongoing discussion. S YSIPHUS supports a simple task model, consisting of

Figure 1. Overview of the rich client RAT.

Action Items. Once an issue has been discussed and resolved, users can plan the resulting work as an aggregate of action items. An action item has a description, a status, a due date and is assigned to project participants. Like all annotations, they can be attached to any number of model elements, to indicate which elements are likely to change when accomplishing the task. Capturing collaboration artifacts can help support future changes, such as finding the human source of a criterion and identifying related model elements, as indicated by studies about pretraceability [14] and rationale [18]. The challenge is in making such capture practical and useable. To address this challenge S YSIPHUS provides an annotation mechanism that strikes a balance between spontaneous, informal collaboration and formal, long-term rationale capture.

3.3

Organizational Models

S YSIPHUS supports an organizational model consisting of Organizational Units that are either Participants or Teams. Teams in turn consist of other Organizational Units. Participants may be members of many Teams. Organizational Units have common attributes, such as names, phone numbers, and email addresses and can be accessed and manipulated through an address book integrated in S YSIPHUS. For example, the address card of “Bernd Bruegge” is displayed

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

in Figure 1. The organizational model extends the S YSI PHUS graph and is used in the same way as system models and annotations. For instance, a management document can include the organizational structure by using filters as described above, ensuring consistency with the address book. Action Items can be assigned to Organizational Units (Figure 2). Displaying a project participant in S YSI PHUS lists assigned Action Items and their Teams, supporting awareness of current tasks.

4

Traceability in Sysiphus

Software projects need to deal with change. Requirements change when the problem domain is better understood. The architecture is adapted when new technology is selected. To maintain consistency among documents and models, impacted elements need to be identified and updated [9]. Moreover, it is often necessary to identify the stakeholders responsible for these elements, as they may have implicit knowledge about how or whether the change should be realized. Tracing from requirements forward, to impacted design, implementation, or test elements is called posttraceability. Tracing from elements back to their human sources is called pretraceability [17]. The abstract ModelLink class and the inclusion of collaboration and organizational models in S YSIPHUS provides uniform mechanisms for supporting pre- and post-traceability. Let

Sysiphus Graph filters

*

2

*

annotates

* ModelElement

ModelLink Organizational Model

Collaboration Artifacts

System Models

Annotation

SystemModel

Section

* *

Contrained Element

Document

* *

Criterion

Comment

1

Issue

* Leaf Section

Composite Section

Nonfunction Requirement

*

* DesignGoal

Option

*

*

* * Criteria

*

ActionItem

*

1

*

*

*

OrganizationalUnit

* 1 Resolution

*

Team

Participant

Assessment Class

*

*

UseCase

* *

TestCase

Figure 2. Sysiphus graph, including system models, collaboration artifacts, and organizational model (UML class diagram). The diagram shows only selected classes and associations.

us consider three activities in which traceability is needed: • Identifying change impact. Explicit links are used for tracing between the elements. These links are part of the model and are created by the users. For instance, links between Actors and Use Cases, Use Cases and Classes, or Use Cases and Test Cases are created during requirements, system design, and testing. By following these links forward and backward, the user can assess the potential impact of a requirements change or validate the test results against a set of requirements.

on the one hand, users need a localized view of elements, to explore the immediately surrounding context; on the other hand, users need to view traces several levels deep, to visualize a complete path between a pair of indirectly related elements. When addressing both of these requirements, the amount of information displayed quickly overloads the user.

• Identifying implicit dependencies. Annotations typically relate several model elements. As annotations are also model elements, a user can trace over annotation links to find related elements. For example, a component can be referred in the discussion of a design issue, involving a number of nonfunctional requirements. Even if the component is not explicitly linked to these nonfunctional requirements, the user will be able to find them by tracing through the issue.

S YSIPHUS addresses this challenge with focused graphs: To reduce the amount of information displayed, the element under consideration is displayed at the center of the focused graph while its directly related elements are displayed around it. Only links to and from the focused element are displayed, links among the other elements are hidden. For example, at the top of Figure 3, “Purchase Article” is the element under consideration. To differentiate quickly between types of relationships, the layout is separated into four areas: left, right, top and bottom. Contributor links are displayed on the left. Incoming system links are depicted on the left and outgoing system links on the right. Annotations (issues, comments, and tasks) attached to the system element are displayed below it while constraining elements (e.g., nonfunctional requirements, design goals) are displayed above. In other words, the horizontal axis displays system and organizational dependencies while the vertical axis displays rationale and collaboration artifacts. The user resets the focus of the graph by clicking on any of the related elements, thus enabling a quick mechanism for exploring a full trace. Double clicking on an element opens the element in a new pane that displays its properties and enables its modification. Table 1 shows selected traceability links supported by S YSIPHUS.

While traceability is conceptually simple to explain, it is not trivial to provide practical and usable traceability tools:

To further reduce the amount of information displayed, the user can filter and search within the traceability graph.

• Identifying stakeholders. As participants are also represented as model elements, the user can examine the author of a model element or trace from an Action Item to its assigned Organizational Units. For example, by examining who wrote a specific nonfunctional requirement and how it was used as a criterion when resolving an issue, the user can identify which qualities are critical for a stakeholder.

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

Organizational Unit Use Case Component Class NFR Test Case Annotation

Use Case author includes/extends realizes realizes constrains tests attached

Component author realized by depends part of ----attached

Class author realized by contains association --tests attached

NFR author constrained by ----refines constrained by attached

Test Case author tested by --tested by constrains --attached

Table 1. Traceability matrix supported by Sysiphus.

Figure 3. Traceability in Sysiphus. Each screenshot shows the focused graph after the user clicks on a traced element.

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 identified as impacted by a change but still needs to be reviewed. Figure 3 consists of three screenshots, showing an example of a traceability sequence. Each screenshot shows the graph after the user clicks on a traced element, starting at the use case “Purchase Article”. From the use case, he clicks on the issue “How should the customer input commands?” and ending at the quality constraint “Familiarity with Checkout Procedure”. All elements related with the focused element, including the creator and the last modifier are shown in this example.

5

Awareness in Sysiphus

Within distributed projects, awareness of changes at other sites is key to reduce misunderstandings and redundant work and to increase trust across sites. Awareness helps to identify critical issues early and provides the opportunity to resolve issues in time [1, 10, 13].

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

5.1

Subscribing to Notifications

Users can receive email notifications concerning changes to the S YSIPHUS graph. Notifications range from changes to documents, system model elements (e.g. use cases, components, classes), to issues and action items. To avoid broadcasting all changes to all project participants, users can subscribe to the type of changes they want to be notified about. They can specify the model element classes of interest, such as use case, component or issue, resulting in an email if any elements of these classes are created, modified, or deleted. They can also subscribe to changes in documents or in document sections, resulting in notifications when any model element within the document hierarchy changes. For example, if users choose a document that includes only high-priority use cases, they will be informed of all modifications to high-priority use cases, even if those use case did not yet exist at the time of subscription. Each notification includes the type of change, the responsible person, the date and time, and a URL to the modified element. Notifications are batched and sent to users at customizable intervals.

While notification subscription works well for system models (as developers usually have a well-defined area of responsibility), a different mechanism is needed for notifying changes in the collaboration model, as users are not necessarily aware of conversations that might be relevant to their work. To address this problem, S YSIPHUS sends notifications to the last modifier of a model element, when annotations are attached to it. For example, if a user has modified a class, he will receive an email if another user attaches an issue or a comment to this class. Similarly, a reply to an annotation will also trigger a notification mail to the author the initial annotation. In addition, users are notified if an Action Item is assigned to them or to their team.

5.2

Disseminating Changes

As not all stakeholders can be expected to access the S YSIPHUS repository on a daily basis, the notification mechanism described above may not be sufficient to raise their awareness. To address this challenge, S YSIPHUS supports the dynamic creation of lists of URLs into the central repository. These lists can be included into a web page, to provide dynamic content about the state of the project. For example, we created a Wiki-based portal containing lists of all open issues and open action items, organized by teams and sorted by date of modification and by responsible participants [28]. Users can view the Wiki topics using a Web browser without being aware of the origin of the items. By clicking on a specific action item or issue, the user then logs into S YSIPHUS and make use of the traceability and modeling functionality described in the previous sections.

6

of each musician is displayed on one of many screens surrounding the child conductor. The child hears the symphony through a surrond-sound system, providing a threedimensional sound image of the positions of each musician. A camera tracks the baton of the conducting child, enabling the child to interact with the orchestra. The child can change the tempo of the music and volume with motions of the baton. The child can also walk through the orchestra, as the video and audio streams are dynamically adjusted to reflect the relative positions of the musicians and the child (see Figure 4).

Experiences with Sysiphus

Since 2000, we have used and evolved successive versions of S YSIPHUS, both in our project courses and within consulting projects for industry [4, 12, 29]. Our software engineering project courses provide a realistic environment to students who experience first hand the complexity of software development projects. These projects feature an actual problem specified by a real client and sometimes involve up to 100 participants in several locations, in Germany, in the United States, and in New Zealand. These courses have provided us with a research testbed that is realistic enough for quickly evaluating ideas while enabling detailed observation and surveys. Within industry projects, we have used S YSIPHUS as a prototyping platform in the scope of distributed projects, for reengineering existing processes, identifying limitations, and demonstrating new concepts. In our last project course VSO 2005: Virtual Symphony Orchestra [28] we developed a system that enables children to conduct a virtual symphony orchestra. A video stream

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

Figure 4. VSO System mockup and photo. The project started on October 30, 2005 and ended with the Client Acceptance Test on February 16, 2006. The client is the Bavarian Symphony Orchestra with the chief conductor Marriss Jansons. 24 students participated on the project and worked in teams, each lead by a student team leader. Each development team was responsible for a component. A cross-functional architecture team included representatives from each development team. All teams met weekly for team status review and issue discussion. The team leaders met with the project manager weekly for project status. A weekly all-hands meeting was used for tutorials and major reviews. As all participants were students, they had no common office, worked in distributed locations, and often met only at team and all-hands meetings. Participants created all documents and system models in S YSIPHUS. We also used S YSIPHUS to manage the project by creating issues and action items and attaching them to the relevant models. We captured the complete history of accesses during the project. We collected 29930 change events, denoting changes to the ModelElements of the repository and 29151 user events, denoting read accesses and user actions in the client applications (e.g., changes of focus in the traceability window). Table 2 shows for selected ModelElement classes the average number users and teams who read or changed an element of that class. For example, on average, each Action Item was read by 5.76 and modified by 1.78 users. Similarly, on average, each Action Item was read by members of 4.5 teams. The average number of read and write accesses by users show how the system and collaboration models were used

Element Count 141 48 60 32 34 96 13 24 23 9 109 10 5

Element Type Action Items Issues Proposals Resolutions Comments Sections Scenarios Use Cases NFR Packages Classes Sequence D. Components

Ø User Read 5.76 6.45 3.95 0.75 4.55 9.90 7.69 8.33 7.30 11.66 3.22 8.80 9.00

Ø User Write 1.78 2.20 1,15 1.03 1.05 1.44 2.30 4.95 1.91 3.66 1.67 2.10 2.80

Ø Teams Read 4.50 5.81 3.93 0.84 4.11 7.36 6.46 7.04 6.04 7.66 3.27 7.50 7.00

Ø Team Write 1.98 3.00 2.00 2.03 1.64 0.96 3.23 5.04 3.00 4.00 2.19 2.30 3.00

Table 2. Average number of unique users and teams reading and writing an element.

to interact and how system knowledge is shared across participants and teams. These users gained knowledge about the focused element and transfered the knowledge by faceto-face communication to their teams. Therefore, the average team access indicates how many different teams were involved and aware of the elements. As some users participated in more than one team, the average number of accesses by teams can be higher than the number of users.

raise clarification questions, students created Issues and attached them to other teams’ system models. Examining the content of the S YSIPHUS repository, we observed that students used our collaboration model mostly for application domain problems, design questions, components API discussions, and for project management aspects. Participants used mailing lists to discuss infrastructure problems, implementation and programming questions. While the evidence from this case study is anecdotal as the subjects were students, it confirms that it is feasible for groups of participants who do not know each other to collaborate using S YSIPHUS. Based on these results, we are now able to plan studies with independent participants from industry.

7

The use of rationale, traceability, and awareness for supporting distributed development is not new. Research efforts from the software engineering and computersupported collaborative work communities have investigated these mechanisms for distributed work to achieve a variety of goals, such as improving distributed negotiation [3], identifying social dependencies [8], using traceability to raise awareness [21], using asynchronous issue discovery and consolidation to reduce the need for synchronous collaboration [7, 20]. While many aspects of these proposals appear similar to S YSIPHUS, each differs fundamentally either in the goal they achieve or their approach. In this section, we examine how our work complements and extends these proposals.

7.1

Figure 5. User activity of the VSO project. In addition, we captured the access date and time and recognized mayor activity peeks (see Figure 5) around the Requirement Review, Analysis Review and System Design Review. At all reviews, the students presented the relevant models of the complete system. To ensure consistency and to integrate the different aspects of all teams, communication, negotiations, and problem solving across teams was required. Combining the data from Table 2 and Figure 5 suggests that S YSIPHUS was used to collaborate across sites and teams, while face-to-face meetings were used to resolve team-internal problems. To report problems and to

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

Related Work

Rationale and Distributed Work

The goal of much rationale research has focused on capturing decision making knowledge for long term use, contributing to the group memory of the organization. However, such externalized knowledge is also useful in the short term for supporting transfer between sites [11]. For example, EasyWinWin [3], an approach for negotiating requirements, leverages off both rationale and collaborative techniques. Rationale is represented as Win conditions, issues, proposals, and agreements, similar to the QOC [22] model in S YSIPHUS. During negotiation, stakeholders follow a sequence of stages in which they brainstorm win conditions, define glossary terms, prioritize Win conditions, surface issues and constraints, and resolve issues. The EasyWinWin tool enables stakeholders to remain anonymous during several stages of the process, thus shifting the focus of the negotiation on the content. The tool enables dealing with a large number of win conditions and with geographical distribution. While EasyWinWin and S YSIPHUS are similar in their use of rationale, they differ in their scope: EasyWinWin targets high-level requirements elicitation during syn-

chronous workshops, S YSIPHUS focuses on detailed development of requirements and architecture during both synchronous and asynchronous collaboration. This key difference lead us to investigate closely the relationship of rationale with traceability and awareness.

7.2

Traceability and Awareness

Requirements traceability has long been identified as a key success factor in large software development projects [9, 14]. The Standish Group’s CHAOS report identified incomplete and changing requirements as two key factors in project failures [27]. Moreover, requirements traceability is required for CMMI compliance [25]. While commercial requirements traceability tools (e.g., DOORS and RequisitePro) have been used in distributed projects, their focus is on managing complex requirements and on change management. The interest of using traceability for supporting the concept of group awareness is recent. Souza et al. [8] conducted a field study on the use of Application Programmer Interfaces (APIs) for coordinating distributed work. While they confirmed the popular belief that APIs create walls between teams allowing them to work independently, they found that defining contracts with APIs can also create obstacles for inter site collaboration, in particular, during the integration. They also noted difficulties by developers in finding and communicating with their counterparts at remote sites. Based on these insights, Souza et al. propose the concept of social call graphs, depicting both dependencies among components and their authors, thus depicting the social dependencies between developers that would be critical during integration. S YSIPHUS provides pretraceability with a similar graph of relationships between model elements and authorship, extended this concept to software engineering models in general. ADAMS [21] tracks artifacts produced during development along with their dependencies. Moreover, ADAMS associates developers with the operations they are allowed to perform on each artifact, thus also capturing life cycle aspects. Developers become aware of changes to dependent artifacts by subscribing to events. To ensure that all dependencies are captured, ADAMS uses a latent semantic indexing mechanism to suggest the addition or removal of links between artifacts, based on their linguistic similarity. Traceability and notification are thus used to raise the awareness of developers to changes to related artifacts. Latent semantic indexing ensures that links among artifacts produced at different sites are captured. ADAMS provides a generic file-based representation of artifacts, but does not explicitly represent software engineering concepts. Conversely, in S YSIPHUS, users can specify such concepts when subscribing to notifications. As indicated before, a user can request to be notified when high-priority use cases change.

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

7.3

Asynchronous Inspections

Several web-based tools have been proposed for supporting asynchronous inspections in distributed projects (e.g., IBIS [20] and HyperCode [23]). The goal of such tools is to minimize the number of synchronous activities during the inspection process to enable its distributed execution while retaining the benefits of inspections. Asynchronous inspection has also been used for requirements [7]. While such inspection tools focuses specifically on the inspection activity, they share with S YSIPHUS the concept of raising and resolving issues asynchronously and attaching issues with the artifact under consideration (e.g., requirements, source code). S YSIPHUS differs in that it does not support specific stages in the process, treating development as a continuous process in which issues can be raised, discussed, and closed in any order.

8

Lessons Learned

Here, we summarize the main lessons learned during this evolution of S YSIPHUS: • Modeling for communication vs. documentation. Project participants construct models for different purposes, for example, to communicate and discuss a proposed alternative or to document the current implementation. Models used for communication include less detail and represent aspects that are not yet agreed on. Models used for documentation include many details and are usually obsolete, referring to a past version of the system. S YSIPHUS attempts to bridge this gap, providing an environment for models to evolve from sketches to refined documents. Early adopters used S YSIPHUS as a documentation tool, first discussing ideas over email and in meetings, then entering agreements into the tool. Consequently, this resulted in a loss of much informal information. Users started using S YSIPHUS for discussions only after we introduced light-weight features such as comments, action items, and list exports to Wiki. In other words, providing an agile tool for synthesis was a more difficult challenge than providing structure for managing complexity. • Rationale reconstruction. An early goal of S YSIPHUS drawn from our experience in distributed projects has been to explicitly capture the rationale behind critical decisions. Initially, we proposed to capture and structure rationale as a side effect of communication. Through repeated experiences, it has become clear that such structuring hinders communication. Instead, rationale is more easily captured during reflection activities by extracting rationale from comments, for example, as a preparation for reviews or as a summary of

an agreement. This agrees with other related work on rationale management [2, 26]. • Awareness of work at other sites. The main lesson learned about awareness is that it is not sufficient to propagate news of a change to other sites: Recipients of the notification must also understand how it impacts their work. When distributed teams are sufficiently decoupled, it is relatively easy to ignore the work of others. In this case, teams typically focus only on their own models, omitting the dependent artifacts produced by others. Notifications from other sites are then ignored until it is too late. Instead, model links in S YSIPHUS enable teams to focus on overlaps between models at different sites, for example, by linking to the interfaces they depend on. In those cases, participants pay more attention to notifications as they impact elements directly related to their work. Finally, we observed that a unified approach to representing systems, collaboration, and organizational models substantially reduces the need for training. Novice users are able to learn the basic collaboration mechanisms of S YSIPHUS quickly. They learn the concepts of each system model incrementally, as they use them in each subsequent activity. They request clarifications and advice from peers using annotations within S YSIPHUS, thus capturing additional rationale and further reducing overhead. Currently, the development of S YSIPHUS itself has become distributed, involving participants from the University of Heidelberg and the University of Victoria using S YSIPHUS for collaboration.

References [1] R. D. Battin, R. Crocker, J. Kreidler, and K. Subramanian. Leveraging resources in global software development. IEEE Software, 18(2):70–77, March/April 2001. [2] B. W. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah, and R. J. Madachy. Using the winwin spiral model: A case study. IEEE Computer, pages 33–44, July 1998. [3] R. O. Briggs and P. Gruenbacher. Easywinwin: Managing complexity in requirements negotiation with gss. In 35th Hawaii Int’l Conf. Sys. Sciences, volume 1, page 21b, 2002. [4] B. Bruegge, A. H. Dutoit, R. Kobylinski, and G. Teubner. Transatlantic project courses in a university environment. In Asian Pacific Software Eng. Conf., Dec. 2000. [5] J. Conklin and K. C. Yakemovic. A process-oriented approach to design rationale. HCI, 6(11):357–391, 1991. [6] B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Comm. ACM, 31(11), Nov. 1988. [7] D. Damian, F. Lanubile, and T. Mallardo. Investigating ibis in a distributed educational environment: the design of a case study. In Int’l Workshop on Distributed Software Development, pages 153–158, August 2005.

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

[8] C. R. B. de Souza, D. Redmiles, L.-T. Cheng, D. Millen, and J. Patterson. Sometimes you need to see through walls: a field study of application programming interfaces. In CSCW, pages 63–71, New York, NY, USA, 2004. [9] J. Dick. Design traceability. IEEE Software, 22(6):14–16, November/December 2005. [10] P. Dourish and V. Bellotti. Awareness and coordination in shared workspaces. In CSCW, 1992. [11] A. H. Dutoit, R. McCall, I. Mistrik, and B. Paech, editors. Rationale Management in Software Engineering. Springer Verlag, April 2006. [12] A. H. Dutoit and B. Paech. Rationale-based use case specification. Requirements Engineering Journal, 7(1):3–19, 2002. [13] C. Ebert and P. D. Neve. Surviving global software development. IEEE Software, 18(2):62–69, March/April 2001. [14] O. Gotel and A. Finkelstein. An analysis of the requirements traceability problem. In Int’l Conf. on Req. Eng., pages 94– 101, April 1994. [15] R. E. Grinter, J. D. Herbsleb, and D. E. Perry. The geography of coordination: Dealing with distance in R&D work. ACM, 1999. [16] J. D. Herbsleb and A. Mockus. An empirical study of speed and communication in globally distributed software development. IEEE Trans. on Soft. Eng., 29(6):481–494, June 2003. [17] M. Jarke. Requirements tracing. Comm. ACM, 41(12):32– 36, December 1998. [18] L. Karsenty. An empirical evaluation of design rationale documents. In CHI ’96, pages 150–156, 1996. [19] R. E. Kraut and L. A. Streeter. Coordination in software development. Comm. ACM, 38(3), Mar. 1995. [20] F. Lanubile, T. Mallardo, and F. Calefato. Tool support for geographically dispersed inspection teams. Software Process: Improvement and Practice, 8(4):217–231, October/December 2003. [21] A. D. Lucia, F. Fasano, R. Francese, and R. Oliveto. Traceability management in adams. In Int’l Workshop on Distributed Software Development, pages 125–139, Aug. 2005. [22] A. MacLean, R. M. Young, V. M. Bellotti, and T. P. Moran. Questions, options, and criteria: Elements of design space analysis. HCI, 6(3-4):201–250, 1991. [23] D. E. Perry, A. A. Porter, M. W. Wade, L. G. Votta, and J. Perpich. Reducing inspection interval in large-scale software development. IEEE Trans. Soft. Eng., 28(7):695–705, 2002. [24] D. E. Perry, N. Staudenmayer, and L. G. Votta. People, organizations, and process improvement. IEEE Software, 11(4):36–45, 1994. [25] SEI. Capability maturity model integration, 2006. [26] S. B. Shum and N. Hammond. Argumentation-based design rationale: what use at what cost? Int. J. Hum.-Comput. Stud., 40(4):603–652, 1994. [27] StandishGroup. Extreme chaos, 1999. [28] T. Wolf and B. Bruegge. Virtual symphony orchestra. http://wwwbruegge.in.tum.de/VSO, January 2006. [29] T. Wolf and A. H. Dutoit. A rationale-based analysis tool. In IASSE’04, pages 209–214, July 2004. [30] T. Wolf and A. H. Dutoit. Sysiphus at http://sysiphus.in.tum.de, May 2005.