Specifying coordinators: guidelines for groupware developers

Abstract

There is a growing trend to develop software that supports the work of groups, as opposed to individuals. Such software is currently being termed groupwure (Tazelaar 1988), and the technical field is being called computer-supported cooperative work (Greif 1988). One aspect of supporting group work involves coordinating the speaking and actions of teams. A coordinator is software which supports team conversations (Winograd 1988). Coordinators are distinguished from traditional software applications because they contain embedded protocols which describe group work (Holt & Cashmau 1981). This position paper presents guidelines for specifying coordinators. 1. Adaptable Specifications In the past, software engineers interpreted group work as tasks which require coordination. Early coordinators Iike Monster (Holt & Cashman 1981) and XCP (Sluzier & Cashmsn 1984) took the approach of specifying group work as a set of rules which define the work tasks and their interrelationships. Such rule-based specifications have difficulty adapting to particular group work situations. To explain, these specifications sequence work tasks, and so it is diflicult to specify rules without also considering their execution sequence. Not surprisingly, it is sometimes impossible to reliably modify these rules when a work process quickly changes. Croup work is plastic -groups continually redesign they way they work. In fact, the work process of a group is always in a state of flux (Ehn 1988). In order for software to operate effectively in this domain, adaptable specifications must be written. A more flexible approach to specifying coordinators is to define rules for those work tasks that are independent of time. Task sequencing is left up to the group while they do their work. Coordinators like COSMOS (Buckley 1988) have adopted this approach, using a declarative specification language to describe “timeless” work tasks. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication aad its date appear, and notice IS given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specrfic Permission. 2. Specifications Of Conversation Another interpretation of group work is to consider conversation being common to all work activity (Searle 1969, Wmograd & Flores 1986). This interpretation sees work as language which generates action, and action which generates work products. Specifications written from this perspective define how to manage the commitments people make to each other during their work. Examples of these kinds of coordinators ate: CHAOS (DeMichelis 1988), CONTRACT (Mama et. al. May 1987), and The Coordinator (Winograd 1986). Specifications that define structured conversations have the advantage of being less dependent on the actual work being done and being totally independent of time. This is possible because the specification defines the conversation, as opposed to the work tasks, which can vary in context, content, and complexity. The conversation is straightforward by comparison, and thus the specification is greatly simplified. 3. The CONTRACT System The CONTRACT project (Mama et. al. April 1987), successfully developed a coordinator for a small manufacturing team. The day-to-day operation of the system returned significant savings to several organizations within the company. The process used to specify CONTRACT emphasized understanding the conversations underlying the work of the group. Before discussing the specification in detail, the value engineering work setting is summarized: The mission of a value engineering enterprise is to improve the value of an existing product or product line (Mudge 1971). For the CONTRACT project, cost avoidance was the value goal. To achieve this goal, r-e-engineering is first done to psrticular parts in order to reduce their cost of manufacture. These changes are then introduced somewhere in the life of a product, realizing savings over the remaining life of the product (i.e. multiplying the cost reduction per part, the number of parts per product, and the expected product volume, yields an estimate of the savings returned from the part change). 235 01989 ACM O-89791 -305l/89/0500/0235$00.75 4. The CONTRACT Specification The specification of the CONTRACT coordinator was developed using a paradigm that stresses multiple, interconnected models (Marca & McGowan 1982). Applying this paradigm resuits in the speczjkation architecture shown in Figulre 1. The architecture encapsulates three major aspects of coordinating group work: the work tasks and information flow, the structured conversation types, and negotiation. Models lower in the architecture rely on the model above for context. Figure 1: Specification Architecture The fmt mod&l in the CONTRACT specification defines the context in which the group works. The work process, specified as a user experience (Whiteside et. al. 1988), is the grounding for the remainder of the specification. For CONTFUKT, developers worked along side users in order to specify the typical value engineering scenario shown in Figure 2. The scenario then became the source for the rest of the specification: The boxes represent more detailed work contexts, and the arrows represent the information shared during conversations.