Paper submitted to Information Systems Journal
Integrating geographically distributed development teams through increased product awareness Babak A. Farshchian Norwegian University of Science and Technology Email:
[email protected] Fax: +47 73 59 44 66 March 20, 2001 Abstract More and more product development projects involve geographically distributed groups of developers. One major problem among the members of such groups is the long term lack of awareness of the activities in remote sites. In this paper we discuss the importance of awareness in distributed product development projects. We argue that generic services are needed in development environments in order to provide continuous awareness of activities in remote sites. We introduce a product awareness model that puts focus on a shared composite product and the propagation of awareness in it. We describe the design and implementation of this awareness model in the form of an awareness engine called Gossip.
Keywords: cooperation support, product development, CASE tool, distributed team, groupware, CSCW, awareness, awareness engine, Gossip
1
Introduction
Information systems development is an area of intensive human collaboration [3]. A normal practice for managing collaboration in large scale IS development projects has been to divide the system into parts and have the parts be developed separately by groups of developers, in this way reducing the amount of ad hoc communication and dependencies [5, 24]. However, many recent case studies of project groups have revealed that this is not an easy task. No matter how rational the division of the system into parts is, each group will still need a large amount of information about what is happening within and across the groups in order to coordinate its work [15, 17, 22]. Access to this ad hoc information becomes particularly problematic when the developers are geographically distributed. The effect of geographical distances on long term collaboration has been well documented in the literature. Herbsleb and Grinter [17], Kraut and Streeter [22], and Krasner et al. [20] document the occurrences of communication breakdowns when there are organizational or geographical barriers among the group members. In a study of researchers from 70 research labs, Kraut and Egido [21] found that there was considerably higher collaboration frequency among researchers having offices in the same corridor than among those who did not. The reason, according to the authors, is that physical proximity increases the frequency and the quality of communication, and decreases the cost of initiating communication. As members of co–located groups, developers have the advantage of constantly being aware of the status of the product being developed by simply using their social abilities, such as “looking over the shoulder” of each other, being involved in chance encounters in the corridors, and having a much greater opportunity for “keeping in touch” with each other. In distributed cooperation, both the amount and the quality of this information decreases. In addition, providing and consuming this awareness information becomes an explicit burden on the co–workers simply because most of the natural social channels of communication are eliminated. Page 1 of 19
Babak A. Farshchian
Graphical editor Menu Enter title here
Text
Text
Text
Text
Text
Text
Text
Text
Text
< Back
Next >
Cancel
Application Layer
Integrating geographically distributed...
Cluster Cluster Layer
Cluster
Cluster Layer
Cluster network-based API
Gossip
Product Layer
Gossip network-based API
Figure 1: A framework for supporting product awareness in distributed product development environments.
In the recent years there has been a large amount of research conducted with the aim of developing tools to support distributed development groups in performing specific and recurring types of tasks. Tools are developed for supporting collaborative modeling [9], JAD sessions [4], programming [18], and more. In addition to these specific tools and environments, we believe there is a need for more generic tools for simulating long–term physical proximity of the distributed project members, making it easy and less costly for the developers to initiate collaboration when they need it. In this way strict geographical divisions can be relaxed, and the collaboration can proceed in a more natural and flexible way. One essential step in doing this is to develop support systems that increase the amount of long term awareness provided to project members about the activities of remote co–workers. As a part of our research on product development environments, we have been developing a framework for supporting collaboration in distributed product development projects [11]. The framework consists of three parts (Fig. 1). An underlying product layer is in charge of providing awareness of a distributed virtual product consisting of parts. A cluster layer implements mechanisms for grouping product parts into collaboration aware clusters, such as diagrams. An application layer assists the integration and use of various development tools. In this paper we describe Gossip. Gossip implements the product layer, and is in charge of keeping all the other parts of the framework constantly aware of user activities involving different parts of the product, in this way Page 2 of 19
Integrating geographically distributed...
Babak A. Farshchian
Support for organizational awareness
DBMS
CASE tools
Activity-based groupware Social groupware
Co-located
Room-based groupware Media spaces Spatial systems
Quantity of awareness information Figure 2: A comparison of awareness support in different systems.
providing a shared collaboration space for distributed development groups. The structure of the paper is as follows: In Sect. 2 we will look at different approaches to awareness support. In Sect. 3 we introduce our product awareness model. Section 4 describes Gossip, which implements this awareness model in the form of an awareness engine. Section 5 provides a discussion and directions for future work.
2
Approaches to Awareness Support
Awareness information is the information that human beings exchange with their environment in order to coordinate their work with others. Providing computer–based mechanisms for supporting exchange of awareness information has shown to be of central importance to the design of collaboration support systems [16]. For the purpose of this paper, we will organize the type of awareness support in existing collaboration support systems along two dimensions (Fig. 2). The first dimension focuses on the quantity of the exchanged awareness information compared to natural co–located situations. The second dimension is the level of organizational awareness provided by the awareness mechanism. By organizational awareness we mean awareness of the overall organization of the work, e.g. the interconnections among the tasks to be performed by the different people. High quantities of awareness information are normally important in order to increase the “naturalness” of the collaboration, while access to proper organizational awareness facilitates collaboration in large groups. The quantity of transmitted awareness information is largest in co–located situations, where all the available social channels are used to their full capacity. Media spaces are probably the closest imitations of co–located situations regarding the quantity of awareness information. A typical media space consists of permanent video and audio connections between geographically distributed sites. The amount of awareness information is high because the video and audio lines transmit a natural picture of the remote site. In addition, the permanence of the connections reduces the cost of initiating collaboration, contributing further to the creation of a common social space in the long run [2]. Page 3 of 19
Integrating geographically distributed...
Babak A. Farshchian
Smaller amounts of awareness information are typically transmitted through software based collaboration support systems (also called groupware [10]). This is both because of the difficulty of collecting this information from the group’s natural context, but also because of the difficulty of visualizing this information in a proper way. A challenging part of implementing awareness support is thus to find the proper awareness model for the domain to be supported. This model will decide what awareness information will be delivered to whom. By using proper awareness models, collaboration support systems can make better use of the limited information bandwidth, and ensure that those who need the awareness information will get it. The majority of awareness models are developed based on empirical studies of workers in different work domains. This is necessary in order to know the real awareness information needs of those who will use the systems developed based on awareness models. Several awareness models have been proposed in the literature. Normally, awareness models have a notion of shared space, presence and focus. Shared space is where shared objects have to reside in order to be able to produce and consume awareness information. An object makes its presence known to the shared space by registering itself with a set of parameters. Once present in the shared space, the objects commit to update their presence information regularly. Objects can in addition focus on other objects by providing to the shared space a set of parameters that defines their focus. The focus can also be updated regularly. In the spatial model of Benford and Fahl´en [1], for instance, each object declares its presence in the shared space by its coordinates according to some spatial measure (e.g. geographical location). By changing its coordinates, an object can “move” in the shared space. The focus of each object is defined in form of an “aura” (an area in the object’s surrounding space); each object will be able to receive awareness about other objects that are inside its aura, i.e. are close to it. Moving in the space will also move the object’s aura. As we see in Fig. 2, systems that adopt the spatial model often result in moderate amounts of awareness information. The number of parameters used for representing objects in the shared space is often much lower than what is available in the physical space, i.e. in the case of co-located collaboration. For instance, human being are often represented in form of simplified “avatars,” where many important details such as facial expressions are missing. In addition, spatial models are also weak in providing organizational awareness because they often focus on providing awareness of the immediate surroundings of an object. The spatial model is mainly used in virtual reality applications, where spatial relations play a central role. The room–based model is a similar awareness model that has gained popularity among the researchers and developers of collaboration technologies. In a room–based model of awareness the shared space is partitioned into rooms with more or less rigid walls. This partitioning controls the visibility of the objects in the space. Objects are present inside a room, and their focus is limited to the contents of that room. Awareness information about the activities in the room is delivered to all the inhabitants of the room, while the walls limit the propagation of awareness information to the outside. This model is used in many shared workspace applications, notably TeamRooms [26]. The amount of awareness information in typical applications based on the room–based model can be as much as that for spatial models (see Fig. 2). In reality, however, this awareness information is often limited to what is important for performing a specific task in a room. For instance, TeamRooms has a quite limited representation of human beings in a room, and awareness about other objects is limited to the changes done to them. Room-based models are often quite limited in providing organizational awareness because they isolate the inhabitants of a room from the rest of the shared space. A third model is the activity–based model. Here, awareness information delivery is not based on spatial relations, but on the activities or organizational processes the users are involved in [14]. Activities themselves are present in the shared space, and changes to them will produce awareness information similar to changes to any other object. For instance, an activity might change its status from “ongoing” to “finished,” a change that will be visible to those users in the shared space who are involved in that activity. The focus of the objects in the shared space is directed towards the activities they are involved in. The activity–based model of awareness is quite limited regarding the amount of awareness information it provides (awareness information is normally limited to information about changes to the activities) but is capable of providing higher amounts of organizational awareness (see Figure 2). The activity–based model used in GroupDesk [14] provides a good example of high organizational support. GroupDesk is used in conjunction with a workflow application, where a user involved in a step in a workflow is made aware of the activities in other related steps. Page 4 of 19
Integrating geographically distributed...
Babak A. Farshchian
Social awareness models put more focus on human participants and social relations among them. One such model is the locale model used in Orbit [23]. In this model, the shared space is divided into locales. Locales are similar to rooms in the room–based model in the sense that they partition the shared space. They are however different because they do not have rigid boundaries and might involve different people and objects at any time. In addition, locales are social constructs as opposed to physical rooms which are spatial. Social awareness models often produce lesser amounts of awareness information compared to spatial and room–based models because awareness information is normally connected to more abstract happenings in the shared room. Organizational awareness might potentially be high depending on the degree to which informal communication in the organization maps to the formal organizational structures. Though CASE and similar product–based tools provide access to an organizational context in the form of a large shared product, the degree of awareness information exchange is low [27]. Central repositories used in product–centered development tools provide a first technological step for supporting collaboration, but more is needed. These repositories are normally developed in the form of time–sharing systems. In particular, they are based on the assumption that conflicts among developers should be delayed as long as possible [19], with the consequence of isolating developers from each other. Despite this attempt to isolate, Vessey and Sravanapudi [27] found that having access to a shared product and being able to observe or monitor the changes done to it by others had an implicit coordinative role in CASE tools. In the next section we will introduce a new awareness model that addresses this problem by supporting exchange of explicit product awareness among developers.
3
A Product Awareness Model for Distributed Product Development
In this paper we introduce an awareness model that uses the product, in particular its structure, as a basis for providing awareness to the developers in a distributed project. Our assumption, as discussed in the introduction, is that a developer needs to have continuous awareness of the events related to a shared product. The needed awareness is first and foremost related to the parts of the product that a developer is directly working on, but a developer may also need to be informed about the happenings related to other parts of the product that are somehow related to “his” parts. We believe an awareness model that focuses on the shared product can be useful in a distributed product development context because the product is normally the main focus of work for the developers, and the shared product is something the developers can “talk about.” Being kept updated about what is happening to the product will reduce the risk for double–work and integration problems. In addition, since the product is normally used throughout the project’s life independent of the way the developers work and the way they are combined in groups, the product can be used as a permanent information basis for coordinating the work. Before we describe the details of the model, it is important to further clarify the role of such a model in a development environment. Awareness information is information about a shared state. In case of a group of product developers, the shared state is partly constituted by the shared product being developed. The majority of existing awareness models do not deal with increasing awareness of a large and composite artifact involving lots of dependencies among its sub–parts, as software products tend to be. The shared product is the focus of our model, and the model will facilitate awareness about the shared product. The problem that we have addressed in this paper is that, due to geographical distribution, the visibility of the happenings to the shared product is reduced. In co–located situations, the product itself is often stored in a repository, while awareness of changes to it is articulated through social interaction among the developers. In geographically distributed settings, even though the product is still stored in a repository and is easily accessible to all the members, awareness of changes to it is hindered. This is mainly because the developers no longer can use their social abilities to “hint” each other about the changes they make to the product, or be hinted about others’ changes. Our product awareness model will increase the quantity of product awareness, and will make it easier for developers to exchange this awareness information. Regarding the location of CASE tools in Fig. 2, this means that the quantity of awareness information will increase, while we will still be able to make use of a high level of organizational awareness that is already supported by many CASE tools. Note that by organizational Page 5 of 19
Integrating geographically distributed...
Babak A. Farshchian
is manipulated by N
M 1
contains
N
Product Object 1 1
1
is originator of
Direct awareness information
N
N
is produced by
1
Awareness producer
N
1
is produced by
is consumed by
N
1 Product model
is source of
is destination of
is originator of
1 N
N N
contains
N
Awareness relation
is mediator of
N
M
N Mediated awareness information
N
is consumed by
M
Awareness consumer
Figure 3: The core concepts of the product–based awareness model and the relationships among them.
awareness we mean awareness related to the structure of the product, i.e. interdependencies among the different parts of the product. CASE tool repositories often support organizational awareness through strong support for interdependencies among the different parts of a product. We emphasize that product awareness should be considered as only one of several forms of awareness in a product development environment [17]. Therefore the model introduced here should be used in combination with other models in order to support true simulation of physical proximity motivated in the introduction. The product awareness model introduces a virtual space for exchanging awareness information that results from development activities involving a shared product. The model assumes that a group of developers will work with a possibly large product consisting of a large number of parts and interdependencies among these parts. Because of the interdependencies among the parts, the model supports propagation of awareness; awareness information can propagate from one part of the product to another, possibly through several intermediate parts. In this way, a group of developers working on one part of the product can get the proper awareness information from any other part, in addition to the part they directly work with. This propagation property is important because of often large size and complex structure of the products being developed. The model includes concepts for representing product parts and relations among them, the developers working with the product, and the type of awareness information that can be exchanged by the developers. The core concepts of the model are product model, product object, awareness relation, direct awareness information, mediated awareness information, awareness producer, and awareness consumer. These concepts and the associated relations are shown in the ER diagram in Fig. 3. Developers in a development project are represented as awareness producers and awareness consumers accessing a product model. The product model is a representation of the shared product being developed by a group of developers. The product model constitutes the shared space where different parts of a product can register their presence in form of product objects. Product objects may represent documents, diagrams, source code files, etc. The product parts will normally be stored in a CASE repository, on the Internet, or in a database elsewhere. For each such part, only one product object may exist in the product model, but the type of the parts is not limited by the awareness model. Each product object is capable of generating awareness information as a result of being manipulated (by awareness producers). This awareness information is consumed by awareness producers and used for keeping aware of what awareness producers are doing. The model supports a notion of focus for product objects. Each product object’s focus is defined by creating awareness relations from those product objects it focuses on and to the product object itself. Each awareness relation has therefore a source and a destination product object, indicating the direction of the flow of awareness information. In addition, awareness relations are capable of selectively propagating awareness information. This Page 6 of 19
Integrating geographically distributed...
Babak A. Farshchian
means that a relation might for instance be configured to propagate only awareness information about updates to its source product objects, and to ignore read operations on the object. Each awareness relation has a list of operations that it will propagate. This list consists of a sub–set of the operation types that are performable on the relation’s source. Criteria for deciding what each product object should focus on, i.e. how awareness relations should be created among product objects, is not defined by the model. Awareness relations may be defined based on product architecture, or other criteria such as the specific usage patterns of a project group. Awareness relations might as well be created based on social relations among the developers themselves. In a typical CASE tool, awareness relations might be created where there are conceptual relations among the different object types, e.g. “part of” relations. It is not feasible for a model to predict all the possible criteria since they will be influenced by the way different groups do their work. These criteria are therefore left to be defined by the users of the model (i.e. cluster and application layers in the framework shown in Fig. 1). The awareness model and its implementation only focus on providing easy mechanisms for creating and modifying awareness relations as needed. A product model is in this way created in order to mirror the real product and the various relations among its parts. An example is shown in Fig. 4. In this figure, awareness producers and consumers are shown as human figures with white arrows from/to a product model (depending on whether they are awareness producers or consumers). The product model is shown as a collection of round rectangles (product objects) and black arrows (awareness relations) among the rectangles. This model represents a product consisting of three main modules, “Database module,” “Middleware module” and “User interface module.” In addition, each module consists of other sub–modules. In this example, product objects are created for each module or sub–module in the product. Awareness relations are created among the product objects, reflecting the paths through which one would like product awareness to be propagated. In this case an awareness relation exists from “Database module” to “Middleware module,” and one from “Middleware module” to “User interface module” (following possible “dependency” relations among the modules). For each of these modules, all the sub–modules are also connected to their parent module using awareness relations (following possible “part-of” relations). This means, for instance, that if some object in “Database module” is modified, “Middleware module” will get awareness information about the modifications. As the product development process proceeds, product parts may be manipulated in different ways. Manipulation activities include those that are normally supported by development tools, such as creating, accessing and deleting product parts. It is assumed that each manipulation of a product part is “repeated” in the product model. By repetition we mean that when a manipulation is performed on a local product part by a developer (e.g. if the developer changes an attribute of a product part), the developer or the tool he is using should inform the product model about the exact nature of the manipulation. The various types of manipulation are not defined by the awareness model. Groups of developers can define and share their own manipulation types in the application layer of our framework (shown in Fig. 1). The awareness model represents developers and their tools as awareness producers. Each manipulation activity performed by an awareness producer will produce a unit of direct awareness information in the product model. This information indicates a change to the product model. Each unit of direct awareness information contains information about the awareness producer who did the manipulation, the product object that was manipulated, an identifier for the manipulation type, and other user–defined values depending on the type of the manipulation. Developers using the same product object can exchange direct awareness information related to that object. For instance, in Fig. 4 users A and B can exchange direct awareness information related to product object “Sub–module 2” because both of them are currently using the object (e.g. in their private workspace). If user A changes “Sub–module 2” user B will receive direct awareness information about the change. Moreover, direct awareness information can be propagated to other product objects used by other developers. Propagation of awareness information inside the product model happens through the mediation mechanism. A mediation starts as a product object, e.g. “Sub–module 2” in Fig. 4, broadcasts its awareness information (i.e. direct awareness information that is produced as a result of user A accessing that object) to all the product objects in the product model. A product object “Database module” that is focusing on “Sub–module 2” (through an awareness relation) will generate a unit of mediated awareness information based on the broadcasted awareness information. User C can then consume this mediated awareness information, and find out what user A did to “Sub–module 2.” The mediated awareness information contains the same information as the original direct Page 7 of 19
Integrating geographically distributed...
Babak A. Farshchian
User D
User C Database module
User interface module
Middleware module
The formal product
User E Submodule 6
Submodule 3
Submodule 1
Submodule 4 Submodule 5 Submodule 7
Submodule 2
User A
Submodule 8
User B
Figure 4: An example product model. Round rectangles are product objects and arrows are awareness relations.
awareness information, except that its originator product object is changed to the new product object, i.e. “Database module.” However, the mediated awareness information also contains a pointer to the originally manipulated product object “Sub–module 2” (the “is mediator of” relation in Fig. 3). Mediation from a product object X to a product object Y is thus possible only if a mediation path consisting of (possibly several) awareness relations exists from X to Y. Awareness consumers represent developers (or other “agent” applications) who make use of the awareness information generated by the product model. Awareness consumers have access to both direct awareness information (produced by the product objects they work with directly) and mediated awareness information (produced by other product objects related to the product objects they work with directly). In Fig. 4 user A is an awareness producer who is manipulating the product part presented by “Sub–module 2” in the product model. As a result of his manipulation, direct awareness information is generated. This direct awareness information is mediated by product objects “Database module” and “Middleware module.” This causes awareness consumers C and D to receive mediated awareness information from their corresponding product objects. An actor (a developer or an “agent” application) can be both awareness producer (producing awareness related to his own activities) and awareness consumer (consuming awareness of the activities of others). As a means for configuring the amount of awareness information generated by the model, each mediation is checked against a strength factor. Each awareness relation has a strength factor that can be changed by the users. Before a mediated awareness information is mediated further, the mediator, i.e. the last product object in the mediation path so far, will compare the strength of the proceeding awareness relation to the number of times the mediated awareness information is already mediated. If this number is equal to the strength of the awareness relation, the mediation stops. This feature, in combination with the operation type selection mechanisms mentioned earlier, can be used to configure the generation of awareness information to fit the different needs of the users. For instance, in Fig. 4, user E might not be interested in knowing every access to “Sub–module 1.” In this case, the awareness relation from “Middle–ware module” to “User interface module” can be given a strength of 2. This will prevent “User interface module” from generating any mediated awareness information related to “Sub–module 1.” Page 8 of 19
Integrating geographically distributed...
Babak A. Farshchian
Using this product awareness model, each developer produces awareness information based on his own activities related to the shared product, for instance by manipulating a set of product objects in his workspace. Each developer can also have access to relevant product awareness information by simply having the relevant product objects in his workspace. In addition, each unit of awareness information is directly connected to the developer who did the manipulation, in this way opening for social interaction among developers with related interests in the shared product. Another advantage of the model is that each developer only needs to focus on those product objects that are of direct importance to his own work, disregarding the rest. The product objects he is working with will inform him about peripheral changes to the product that might be of interest to him, at the same time hiding the irrelevant part of the awareness information. This can greatly reduce the effort needed for keeping an eye on everything that might be important to the developer’s work. Product awareness model supports in this way the creation of a virtual shared space, where a distributed product can be represented in the form of interconnected product objects. The actual parts of the product are not handled by the model. It is not the responsibility of the model to store the shared state (although an implementation of the model might offer simple database services for storing the parts). The model is merely responsible for facilitating the exchange of awareness information about the shared state (i.e. the shared product). In this way, even if each developer has access only to “his part” of the product, he can participate in a shared interaction involving the whole product. Continuous flow of information about access to the shared product will increase the long term awareness of the activities of the remote co-workers.
4
Gossip: An Awareness Engine for Supporting Product Awareness
In this section an implementation of the product awareness model called Gossip is described. The implementation is in form of an awareness engine, i.e. a specialized notification server that is in charge of supplying awareness information to a diverse range of client applications (client applications denote here various software applications that are used by the users for manipulating a shared state, e.g. a shared product). The basic mechanism behind using notification servers for supporting awareness is shown in Figure 5. In this figure, the user of client A performs an action. The action results in client A sending a service request to the notification server. If the request is performed, an acknowledgement is sent to client A, and other clients receive a notification. The effect of the action is shown to client A’s user as a feedback, while other users will observe the action performed by client A’s user in form of a feedthrough. Clients B, C and D will somehow visualize for their own users (e.g. by animation) the action performed by client A’s user. Notification servers have proved to be efficient means for supporting awareness in collaboration support systems [25]. Notification servers are capable of providing generic awareness support to a range of collaboration support systems. Awareness information is typically provided in form of generic notifications that can be used in different ways by different applications. This means that different types of applications can use a notification server for exchanging awareness information as long as a uniform protocol is used for communication with the server. A notification server often employs an information push policy, where notifications are sent to clients instead of clients pulling the server for information. (Though a pull policy is also a perfectly possible solution in many cases. See [25] for a discussion.) Pushing information has the technical advantage of reducing network traffic to a number of necessary messages being exchanged between the server and the clients. The push policy is in particular useful for synchronous applications, where performance and feedthrough speed are critical [7]. The difference between a notification server and an awareness engine is fluid. In this paper we will use the following distinction: An awareness engine is a notification server with an internal logic that guides the distribution of notifications to the clients. This internal logic is often based on a specific awareness model. For instance, NSTP [8] is an awareness engine that uses a room–based model of awareness. As a result, notifications of changes to the contents of a room are sent only to the inhabitant of that room. According to our definition all awareness engines are also notification servers. Gossip is a notification server based on an information push policy. Gossip implements a uniform network protocol where all service requests adhere to a standard format. This protocol allows any client application to connect and perform the services offered by the server. In addition, Gossip is an awareness engine because it Page 9 of 19
K AC N K/
t io n
ifica
ifica
AC
req ue st
Not
Se rv i ce
Feedthrough
Client C t io n
Client B
Not
Client A
Feedthrough
Feedthrough
Babak A. Farshchian
Feedback
User action
Integrating geographically distributed...
Client D
c tifi No
at i
on
Notification server
Figure 5: Using notification servers to support awareness.
also implements a specific awareness model, i.e. the product awareness model developed in the previous section. The product awareness model guides the distribution of notifications, and in this way provides a customized flow of awareness information to the clients.
4.1
The Functionality of Gossip
Gossip provides a set of uniform network–based services for creating and maintaining a product model in an evolutionary manner, and for exchanging notifications (i.e. direct and mediated awareness information) based on the users’ activities related to this model. Gossip itself is not an end–user application, i.e. the users will typically not interact with Gossip directly. Instead, the client applications that the users use in their daily work can be set to communicate with Gossip on behalf of their users. The product model manipulation operations offered by Gossip may be integrated into the various tools of the developers, making it possible to transparently maintain the shared product model while each developer is working with his local product part. In addition, a uniform notification delivery service makes it easy to receive and consume notifications about other developers’ manipulations. Figure 6 shows such a usage scenario for Gossip. Different developers communicate with Gossip (through their client applications) in order to register a subset of their product parts (objects with black color) as product objects in Gossip (objects with gray color). In addition, awareness relations are created among the product objects registered in Gossip independently from which developer owns which product objects. In this way, all the developers are integrated in a shared collaboration space based on a shared product model. Gossip stores minimal information about each product object and awareness relation (only an object ID for each product object, but more information about awareness relations). Gossip enforces its own name space for the registered product objects. The clients (and their users) are responsible for correct updates to the product model using Gossip’s network protocol (see Sect. 4.3 for Gossip network protocol). This approach makes it possible to transparently extend client applications with Gossip functionality. An example can be a graphical diagram editor in a CASE tool. The editor can be extended in order to be able to communicate with Gossip. The users can still use the editor for normal editing tasks. The editor will Page 10 of 19
Integrating geographically distributed...
Babak A. Farshchian
Gossip client A
Gossip client B
Gossip client C
Gossip client D
Gossip manipulation and notification servics
Gossip product model
Figure 6: Clients can use the services provided by Gossip to register their product objects and create awareness relations among them.
in addition be in charge of communicating with Gossip for manipulating the shared product model and for consuming product awareness information produced by other users. Different degrees of automation can then be implemented in the communication with Gossip. For instance, the editor can automatically register product objects and awareness relations in the shared product model as the user creates objects and relations in the editor. More details on developing such “Gossip clients” can be found in [13]. In the rest of this section we will focus on the functionality of Gossip in form of the provided services. Manipulation mechanisms are accessible in form of operations on the shared product model. The operations are initiated by the users (either directly or indirectly as a side-effect of user operations), are requested by the clients, and are performed by Gossip. There are two groups of manipulation operations, product object manipulation and awareness relation manipulation. In addition, Gossip produces different notification events as a result of product object manipulations reported by the clients. Query mechanisms are also provided to the clients in order to ask Gossip about various product model information, e.g. what product objects and relations are currently registered in the model. The following describes manipulation and notification functions provided by Gossip.
Product Object Manipulation Clients can issue requests for product object manipulation. Besides product object registration and deletion, Gossip supports operations such as adding, changing, reading and deleting attribute=value pairs for each product object. The set of attributes for each product object type is defined by the users, and will resemble the attributes of the real product parts that are to be shared within the user group. Note that product parts (e.g. the actual files, documents, diagrams, descriptive attributes, etc.) are not stored in Gossip, but a place–holder for each part is registered in form of a product object. This means that Gossip does not store the attribute=value pairs for each object, but only mediates notifications of a client’s operations on the attribute=value pairs. This policy requires that product object manipulation operations provide precise information about the actual manipulations done on the product parts at each client site. The clients can still use their local repositories, and at the same time use Gossip to exchange product awareness information. They will use product object manipulation operations to inform Gossip about how they manipulate their product parts. In this way Gossip will help its clients to keep updated about each other’s activities related to a shared Page 11 of 19
Integrating geographically distributed...
Babak A. Farshchian
(distributed) product. Each client can choose to register in Gossip only a sub–set of its product parts (in Fig. 6, product parts with white color are not shared among clients). The set of possible operations on product objects is defined by the users. In particular, there is no limit on which attributes can be manipulated for each product object, and the manipulation types are not predefined. All this can be decided among the users sharing the product model, based on the operations they normally perform on their product parts. Gossip will only propagate the awareness and produce the proper notifications.
Awareness Relation Manipulation In addition to object manipulation, clients can also request awareness relation manipulation in order to create and manipulate awareness relations among existing product objects. Awareness relations may be created manually by the users (e.g. “social” relations among two product objects used by two developers who work together) or automatically by the clients as a side-effect of user activities (e.g. “semantic” relations that are created automatically parallel to other semantic relations such as “sub-part” or “depends”). The decision to choose between the manual or the automatic approach is on the users, and depends on many factors. Gossip is developed to support the basic services of awareness relation manipulation (for more details on how relations can be created manually or automatically see [13]). Awareness relations are stored fully inside Gossip. Each awareness relation is stored in Gossip in form of a set of operation=strength pairs, where operation decides what kind of awareness information the relation will mediate, and strength decides how many product objects each awareness information can be mediated through. For instance, if an awareness relation has an “updateAttribute” field with a strength of 2, the relation will mediate awareness related to all “updateAttribute” operations that have not already been mediated twice. Gossip supports operations for adding and deleting awareness relations, as well as adding, deleting, and updating operation=strength pairs on the existing awareness relations. In addition, the clients can query Gossip for information about the existing awareness relations.
Notifications When a client application performs operations on the shared product model maintained by Gossip, notifications are generated automatically and sent to other clients in order to inform them about the nature of the original operation. Notifications are the technical counterpart of direct and mediated product awareness information. Notifications are sent only for product object manipulations. There are two types of notifications, direct and mediated. They follow the distinction between direct and mediated awareness information as described in Sect. 3. Direct notifications have a pointer to the client who did the manipulation, and a pointer to the product object that was manipulated. Mediated notifications have in addition a list of pointers to all other product objects that the notification has passed through (recall that for mediated awareness information, the manipulated product object is different from the product object that provides the awareness information, as shown in Fig. 4). Additional information can be contained in each notification event for allowing the receiving client synchronize its own state. For instance, a “createNewObject” notification might contain the identifier of the new product object, and an “updateObject” notification might have the name and the new value of the updated attribute. It is again important to note that the operations provided by Gossip are low-level operations intended for the software clients used by the users. The users will not communicate with Gossip directly, and will typically be provided with more high level means of manipulating the product model. Most of the manipulations can in fact be automated (e.g. by automatically creating awareness relations when the user creates semantic relations in a CASE editor). In addition, the higher levels of the collaboration framework shown in Fig. 1 are used for raising the level of abstraction when interacting with the product model. Details about these issues can be found in [11, 13].
4.2
The Architecture of Gossip
Figure 7 shows the main components of Gossip’s architecture, and their relationships. Boxes denote functional components, while gray boxes denote persistent object registers. Black thin arrows denote Gossip event communication, and white thick arrows denote other data communication. Gossip clients are end-user applications Page 12 of 19
Integrating geographically distributed...
Babak A. Farshchian
Producer client
Content Manager
Consumer client Consumer Consumerclient client
Receiver Receiver Receiver
Sender Sender Sender
Content DB Request Manager Product Object Register
Notification Manager Subscription Register
Relation Register
Internal Notification Bus
Gossip
Figure 7: The internal architecture of Gossip.
that are capable of communicating with Gossip. Each user will normally interact with Gossip through one or several Gossip clients running on the user’s computer. There are two types of Gossip clients. Producer clients can send requests to Gossip for performing a Gossip operation that might result in one or several notifications. They are the producers of awareness information. Consumer clients are those connected clients who receive notifications from Gossip. They are consumers of awareness information. A Gossip client can choose to be a producer, a consumer, or both. An application becomes a Gossip client by explicitly connecting to the proper network channel. Consumer-only clients are not permitted to access any internal data (they can however change their awareness subscription, see bellow), so they will typically be event monitors. The contents of the product model are stored in persistent registers. Product objects are registered in Product Object Register, and relations are stored in Relation Register (together with their operation=strength pairs). Gossip supports the storage of a content file for each product object. A content file can be a note that describes the product object (e.g. what product part it is representing in the product model). Content files are external to Gossip, i.e. Gossip only stores a pointer to them internally. However, they might also be stored in a Content Database (the local file system) for easy access. Content files can also be available on the Internet, in which case Gossip stores only a pointer to their location. Each client, upon connecting to Gossip, can define an awareness subscription for itself. All awareness subscriptions are stored in a Subscription Register. A client’s awareness subscription tells Gossip which notifications should be sent to the client. There are a number of awareness subscription parameters that can be set by the client. A client can for instance tell Gossip which product objects and what operations on each product object it is interested in. The awareness subscription of each client is consulted before any notification is sent to the client (details on awareness subscriptions can be found in [13]). Any Gossip operation (e.g. product object manipulation) can be asked for by a client sending a request to Gossip. Producer clients normally send requests for modifying product objects and awareness relations, while consumer clients might send requests for changing their awareness subscriptions. Each request will initiate an operation and will possibly result in one or several notifications, as defined by Gossip network protocol (see Section 4.3). All requests, notifications and other types of messages that are exchanged between clients and Page 13 of 19
Integrating geographically distributed...
Babak A. Farshchian
Gossip are Gossip events and follow a standard format. Gossip event is extendable, meaning that additional operation types may be defined by the users and in future versions of Gossip. All clients have to communicate their requests to a Receiver. A Receiver is a translator between a specific network protocol and Gossip’s internal representation, i.e. Gossip event. There are several Receiver objects in Gossip, one for each supported network protocol (currently only one). When a request arrives through a network channel to a Receiver, the Receiver creates a Gossip event object of type REQUEST, and initializes it based on the contents of the received request. The Gossip event is then delivered to Request Manager that is responsible for the processing of requests. Processing might be necessary for instance when a client wants to register a new product object or awareness relation, or change an awareness relation’s operation=strength pairs. After the corresponding operation is processed, the client will get back an event of type ACKNOWLEDGEMENT or NEGATIVE ACKNOWLEDGEMENT depending on whether the request was performed successfully. If the operation was successful a new Gossip event object of type NOTIFICATION DIRECT is created by Request Manager based on the initial request (some operations do not product notifications). The new event is sent to Notification Manager and to Internal Notification Bus. Each awareness relation is implemented in Gossip in form of an awareness agent with related source and destination product objects. Awareness agents constitute the contents of Relation Register. Awareness agents are responsible for generating mediated notifications on behalf of their destination product objects, and therefore listen to Internal Notification Bus in order to monitor accesses to product objects. Each awareness agent will check the bus for notifications that have originated from the agent’s source product object. For each such notification the agent will check its operation=strength pairs, and will possibly generate a new Gossip event of type NOTIFICATION MEDIATED on behalf of its destination product object. These events are again sent to Internal Notification Bus, and other awareness agents may in turn generate new mediated notifications based on them. Notification Manager is in charge of sending proper notifications to each client. Upon arrival of a new Gossip event (from Request Manager or Internal Notification Bus) Notification Manager consults the awareness subscription of each consumer client in order to see if the event should be sent to it. For each client that has a subscription for an event, the event is delivered to the client’s preferred Sender object. Each client has a preferred network protocol, and Senders are in charge of translating the internal Gossip event to this preferred network protocol understandable by the Consumer client. Note that Gossip does not put any restrictions on the contents of the awareness information that is exchanged among the clients. What Gossip does is to receive information about an operation a client wishes to perform on the product model (i.e. modifying product objects and awareness relations), and to forward this information to the other interested clients. This gives a high degree of freedom for the users to decide what awareness information they want to exchange. For instance, the users can define any combination of attributes for a specific product object and ask Gossip to forward changes to these attributes. In addition, the type of operation on different product objects can also be defined by the users. In this way it is also possible to use Gossip for exchanging awareness about several product models at the same time.
4.3
Gossip network protocol
Communication between Gossip and its clients is implemented in form of a network protocol. All messages, both from a client to Gossip and from Gossip to a client, are Gossip events as shown in Figure 8. The fields may have different meanings according to originator and type of communication. clientID is a unique identifier for the client that sent the initial event to Gossip. The same clientID is copied to all the events sent from Gossip to other clients as a result of the original event. For instance, if a producer client sends a REQUEST to update a product object, all the resulting events of type NOTIFICATION DIRECT will have the clientID of the original request. This allows other clients see which client sent the initial request. eventType can be one of the supported types shown in Table 1, or other user–defined event type. An event from a client to Gossip is always of type REQUEST. Events sent from Gossip to the clients may be of any of the types shown in Table 1 except the REQUEST type. Page 14 of 19
Integrating geographically distributed...
Babak A. Farshchian
One byte
clientID
eventType
operationType
reserved
eventID
authenticationInfo
bodySize
Figure 8: The format of a Gossip event. This format is used uniformly for communication with Gossip.
operationType might have different meanings according to the type of the event. Gossip provides a set of predefined operation types, but the users can extend this set to define their own operation types. In an event of type REQUEST sent from a client to Gossip, operationType indicates the requested operation, for instance UPDATE PRODUCT OBJECT. In an event of any other type sent from Gossip to the clients, operationType indicates the operation that resulted in the event being sent. For instance, if a client sends a REQUEST of type UPDATE PRODUCT OBJECT to Gossip, Gossip will send the following events: • An event of type ACKNOWLEDGEMENT or NEGATIVE ACKNOWLEDGEMENT (depending on if the request succeeded or not) with operationType UPDATE PRODUCT OBJECT to the client that sent the original request. • In case the request was successful, consumer clients will get an event of type NOTIFICATION DIRECT with operationType UPDATE PRODUCT OBJECT and additional information about the performed operation. • If the updated object is source for any relations, Gossip will send to consumer clients one or more events of type NOTIFICATION MEDIATED with operationType UPDATE PRODUCT OBJECT. eventID is a unique identifier derived from a time stamp, and can be used by the clients to synchronize the reception of events. authenticationInfo is used in combination with clientID to authenticate the connected clients. The body of the event contains additional information about the event. For instance an event of type NOTIFICATION DIRECT and operationType UPDATE PRODUCT OBJECT ATTRIBUTE will include the identifier of the updated product object, and the name and the new value of the updated attribute. This data is different from event to event, and a bodySize indicates its size. The protocol provides a basis that can be expanded both in new versions of Gossip, and in the current version by the users. Users can define new event types and new operation types according to their needs. This can be useful in cases where the set of operations provide by Gossip does not include frequently used local activities of the developers. For instance, a new event type might be INSTANT MESSAGE, allowing the clients send instant textual messages to each other. Page 15 of 19
Integrating geographically distributed...
Babak A. Farshchian
Field
Semantics
REQUEST
A request event sent by a client for performing an operation. All events from clients to Gossip are requests. A direct notification sent as a result of access to the shared product model. A mediated notification sent as a result of awareness mediation. An event sent to a client as a result of a system activity. An event sent back to a client as a result of a successful request. An event sent back to a client as a result of a failed request. The event will contain an error code explaining the reason for failure.
NOTIFICATION DIRECT NOTIFICATION MEDIATED NOTIFICATION SYSTEM ACKNOWLEDGEMENT NEGATIVE ACKNOWLEDGEMENT
Table 1: Event types in Gossip network protocol. New event types can be defined by the users.
4.4
Gossip client extension
As part of the Gossip server, a small library of classes called Gossip client extension is developed. The purpose of this library is to hide most of the details of Gossip network protocol from the clients. Keeping the programming interface to Gossip as simple as possible has been one of our main goals in order to motivate developers to develop Gossip-enabled clients, or extend existing clients with Gossip-related functionality. Using Gossip client extension, clients can easily send to and receive events from Gossip. The client extension contains classes called Gossip Server, Gossip Producer Channel, Gossip Consumer Channel, Gossip Awareness Subscription, and Gossip Event. An application can initiate an instance of the Gossip Consumer Channel class, which will automatically set up a network channel towards a Gossip server and register the application as a producer client of that server. After this, the application can make requests to the server using instances of the Gossip Event class. In the same way, creating an instance of a Gossip Consumer Channel will automatically register the application as a consumer client of the Gossip server. Upon the creation of a Gossip Consumer Channel, the application is requested to provide a call–back function. The arrival of events from the server will force the execution of this function. The application can then implement the call–back function in proper way in order to handle the received events. Gossip Awareness Subscription allows a client application to change its awareness subscription on the server, and in this way control what notifications are sent to it by Gossip. These classes support all the functionality provided by Gossip through an easy-to-use object-oriented interface.
4.5
The Implementation of Gossip
Gossip is implemented in the Java programming language. Network communication in Gossip, both towards clients and internally in the notification bus, is based on JSDT1 (Java Shared Data Toolkit). JSDT is a flexible toolkit provided by Sun as an extension to the Java Development Toolkit. This toolkit implements useful groupware abstractions such as sessions and channels, and provides consistent and ordered delivery of messages over network. Using JSDT we have been able to focus on the functionality of Gossip without implementing low-level network functionality. The connection between the clients and Gossip is through a JSDT session. Inside this session, two channels are used for communication between Gossip and the producer and consumer clients. 1 http://java.sun.com/products/java-media/jsdt/
Page 16 of 19
Integrating geographically distributed...
Babak A. Farshchian
The internal notification bus is implemented in form of a network channel that is accessible only by other Gossip servers. Several Gossip servers can share the same notification bus, in this way creating a Gossip network. This is useful for scalability and performance reasons. Our experience with using Gossip shows that inside a high–speed local network notifications are distributed in real time. We have in fact used Gossip in a synchronous graphical group editor where the notifications are used to synchronize the screens of the clients. The notifications are distributed in a much slower speed on the Internet. Having one local server for each local group can help to build a more optimized Gossip infrastructure.
5
Conclusions
In this paper we have discussed the importance of awareness in product development projects where the developers cooperate across geographical distances for long periods of time. We have introduced an awareness model that puts focus on the shared product and the propagation of awareness in large composite products. This awareness model is implemented in form of an awareness engine called Gossip, which is used as a part of a framework for collaboration support in distributed product development. The design and implementation of Gossip are described. Awareness information which is produced by Gossip is in form of events. These events need to be integrated into the context in which the users are doing their actual work. In this sense, Gossip cannot exist in a vacuum, but has to be integrated into the tools and the environments of the users. Having provided a well–defined and easy–to–use protocol for communicating with Gossip is an essential step towards this end. In addition, Gossip is developed as a part of a larger framework called IGLOO (see Figure 1) where the services provided by Gossip are used in order to provide higher level services to applications such as CASE tools [11]. As a part of developing our framework, we have implemented two test applications. One is a graphical editor for creating simple ER–like models [13]. This editor is used to demonstrate the capability of Gossip for supporting synchronization of screens in real time. The editor also demonstrates how the various operations in a tool can be configured to automatically trigger operations in Gossip. The other application is a shared workspace application that demonstrates how different awareness models can be used in combination [12]. There are several issues that constitute our future research and development agenda. One important issue is privacy. The high specialization of labor among developers makes it unrealistic to expect that they will expose information about their activities without a second thought. The name “Gossip” is chosen deliberately to emphasize this. Gossip provides easy mechanisms for registering and removing product parts from a shared space, but more advanced mechanisms, such as access control, are needed. The current version of Gossip does not fully implement the subscription mechanisms needed in order to allow the clients configure optimally their awareness needs. In its current form, Gossip somehow enforces a uniform delivery of awareness information to all the clients. Although each client can define which product objects it is interested in, more fine–tuning capabilities are needed. We need more usage data in order to find out what subscription mechanisms and criteria are needed. With large scale deployment of Gossip, subscription mechanisms will become a necessity not only for having higher degree of individual tailoring, but also because of technical issues involved regarding network bandwidth usage. Although Gossip is implemented with CASE tool integration in mind, as a generic awareness engine it is also possible to use it in other areas within software engineering. One such area is software maintenance. Software maintenance is interesting in this context because of its long term nature. Software maintenance deals with often large and composite software systems, and as a cooperative activity it is distributed both in time and space. However, more investigation is needed before any generalization.
Acknowledgement I thank Arne Sølvberg, Monica Divitini, and the anonymous reviewers of CAiSE*00 for their comments on this paper. Part of this research is supported by a grant from Andersen Consulting Forskningsfond, Norway. Page 17 of 19
Integrating geographically distributed...
Babak A. Farshchian
References [1] Steve Benford and Lennart Fahl´en. A Spatial Model of Interaction in Large Virtual Environments. In Giorgio De Michelis, Carla Simone, and Kjeld Schmidt, editors, Proceedings of the Third European Conference on Computer–Supported Cooperative Work, ECSCW’93, Milano, Italy, pages 109–124, Dordrecht, September 1993. Kluwer Academic Publishers. [2] Sara Bly, Steve R. Harrison, and Susan Irwin. Media Spaces: Video, Audio, and Computing. Communications of the ACM, 36(1):28–47, January 1993. [3] Frederick P. Brooks Jr. The Mythical Man–Month – Essays on Software Engineering. Addison–Wesley, Reading, MA, 1975. [4] Erran Carmel, Loey F. George, and Jay F. Nunamaker, Jr. Examining the Process of Electronic JAD. Journal of End User Computing, 7(1):13–22, 1995. [5] Melvin E. Conway. How do committees invent? Datamation, 14(4):28–31, April 1968. [6] CSCW’98, editor. Proceedings of the Conference on Computer Supported Cooperative Work, Seattle, Washington, USA, New York, November 1998. ACM Press. [7] Mark Day. What Synchronous Groupware Needs: Notification Services. In Proceedings of The Sixth Workshop on Hot Topics in Operating Systems, Cape Cod, Massachusetts, pages 118–122, Los Alamitos, California, may 1997. IEEE Computer Society Press. [8] Mark Day, John Patterson, Jakov Kucan, and Wei Meng Chee. Notification Service Transfer Protocol (NSTP) version 1.0. Lotus Workgroup Technologies Technical Report 96-08, Lotus Research, 1996. [9] Douglas L. Dean, James D. Lee, and Jay F. Nunamaker, Jr. Group Tools and Methods to Support Data Model Development, Standardization, and Review. In HICSS’97, editor, Proceedings of the 30th Hawaii Int’l Conf. on System Sciences, Volume 2 – Collaboration Systems and Technology, pages xx–yy. IEEE Computer Society Press, 1997. [10] C.A. Ellis, S.J. Gibbs, and G.L. Rein. Groupware – Some Issues and Experiences. Communications of the ACM, 34(1):39–58, January 1991. [11] Babak A. Farshchian. IGLOO: A framework for developing product-oriented shared workspace applications. In Rose Dieng, Alain Giboin, Laurent Karsenty, and Giorgio De Michelis, editors, Proceedings of the 5th International Conference on the Design of Cooperative Systems, COOP’2000, Sophia Antipolis, France, pages 337–350, Amsterdam, May 2000. IOS Press. [12] Babak A. Farshchian. Supporting virtual collocation with a combination of basic awareness services. In Paper presented at the CHI’2000 Workshop on Virtually Collocated Teams, The Hague, The Netherlands, April 2000. [13] Babak A. Farshchian. A framework for shared interaction in distributed product development projects. Forthcoming ph.d. thesis, Norwegian University of Science and Technology, Trondheim, Norway, 2001. [14] Ludwin Fuchs, Uta Pankoke-Babatz, and Wolfgang Prinz. Supporting Cooperative Awareness with Local Event Mechanisms: The GroupDesk System. In Hans Marmolin, Yngve Sundblad, and Kjeld Schmidt, editors, Proceedings of the Fourth European Conference on Computer–Supported Cooperative Work, ECSCW’95, Stockholm, Sweden, pages 247–262. Kluwer Academic Publisher, September 1995. [15] Rebecca E. Grinter. Recomposition: Putting It All Back Together Again. In CSCW’98 [6], pages 393–402. [16] Carl Gutwin and Saul Greenberg. Effects of Awareness Support on Groupware Usability. In CHI’98, editor, Proceedings of the Conference on Human Factors in Computing Systems, CHI’98, Los Angeles, CA, USA, pages 511–518, New York, April 1998. ACM Press. Page 18 of 19
Integrating geographically distributed...
Babak A. Farshchian
[17] James D. Herbsleb and Rebecca E. Grinter. Splitting the Organization and Integrating the Code: Conway’s Law Revisited. In ICSE’99, editor, Proceedings of the 21th Conference on Software Engineering, Los Angeles, California, USA, pages 85–95, New York, May 1999. ACM Press. [18] Chung-Hua Hu and Feng-Jian Wang. A Multi–User Visual Object–Oriented Programming Environment. In Proceedings of The Twenty-Second Annual International Computer Software and Applications Conference, COMPSAC’98, Vienna, Austria, pages 262–268, Los Alamitos, CA, 1998. IEEE Computer Society Press. [19] Matthias Jarke, Carlos Maltzahn, and Thomas Rose. Sharing Processes: Team Coordination in Design Repositories. International Journal of Intelligent and Cooperative Information Systems, 1(1):145–167, March 1992. [20] Herb Krasner, Bill Curtis, and Neil Iscoe. Communication Breakdowns and Boundary Spanning Activities on Large Programming Projects. In Gary M. Olson, Sylvia Sheppard, and Elliot Soloway, editors, Proceedings of Empirical Studies of Programmers: Second Workshop, Washington D.C., USA, pages 47–64. Ablex Publishing Corporation, December 1987. [21] Robert Kraut and Carmen Egido. Patterns of Contact and Communication in Scientific Research Collaboration. In CSCW’88, editor, Proceedings of the Conference on Computer–Supported Cooperative Work, CSCW’88, Portland, OR, USA, pages 1–12. ACM, September 1988. [22] Robert E. Kraut and Lynn Streeter. Coordination in Software Development. Communications of the ACM, 38(3):69–81, March 1995. [23] Tim Mansfield, Simon Kaplan, Geraldine Fitzpatrick, Ted Phelps, Mark Fitzpatrick, and Richard Taylor. Evolving Orbit: a progress report on building locales. In Stephen C. Hayne and Wolfgang Prinz, editors, Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work, Group’97, Pheonix, USA, pages 241–250, New York, November 1997. ACM Press. [24] D. L. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12):1053–1058, December 1972. [25] Devina Ramduny, Alan Dix, and Tom Rodden. Exploring the design space for notification servers. In CSCW’98 [6], pages 227–235. [26] Mark Roseman and Saul Greenberg. TeamRooms: Network Places for Collaboration. In Mark S. Ackerman, editor, Proceedings of the ACM 1996 Conference on Computer Supported Cooperative Work, CSCW’96, Cambridge, Mass., U.S.A., pages 325–333, New York, November 1996. ACM Press. [27] Iris Vessey and Ajay Paul Sravanapudi. CASE Tools as Collaborative Support Technologies. Communications of the ACM, 38(1):83–95, January 1995.
Page 19 of 19
