Modelling of Working Groups in Computer Supported Cooperative Work Stef Joosten, Sjaak Brinkkemper Design Methodology group, Centre for Telematics and Information Technology University of Twente, the Netherlands e-mail: fjoosten,
[email protected] June 1993
Keywords: working group model, meta-model, semiotics, groupware design, organigram, process interaction diagram, logistic model. Reference:
S. Joosten, S. Brinkkemper, Modelling of Working Groups in Computer Supported Cooperative Work, Invited paper in: 18th Intern. Conference on Information Technologies and Programming, Bulgarian Academy of Science, Institute of Mathematics, pp. 9–22, June 1993. Abstract Computer Supported Cooperative Work (CSCW) is a new multidisciplinary research area aiming at establishing theories for the computerised support of working groups in organisations, the so-called groupware systems. Beside sociology and management science, this field requires knowledge from various areas of computer science: data-communication, human-computer interfaces, information systems design. CSCW is an area in which social and technical sciences meet. It is an area in which scientists truly attempt to bridge the gap between disciplines. In this paper we make an attempt to do just that. We identify possibilities of using modelling techniques from the design of information systems to build models of group processes. In order to learn how to model working groups, a strict discipline of modelling is needed. In this paper we describe that discipline, illustrating it with examples. This paper is intended as a methodological excursion. Our approach is rather how to model than which modelling technique to choose.
1
Introduction
Models are meant to create a clear and structured view of a specific aspect of a system and help restrict to the relevant information. Models are used in many disciplines and for many purposes. An architect uses a wooden model to show what a building will look like. A car designer uses an aerodynamic model in a windtunnel to study air friction. A logistic engineer may use a simulation model to study a proposal to change the logistic organisation in a factory. An information systems
Invited paper at the 18th International Conference on Information Technologies and Programming, Sofia, publ.: garian Academy of Science, Institute of Mathematics, pg 9-22, June 1993.
Bul-
designer uses models in an information analysis of an organisation, such as Entity-Relation diagrams [1] and Dataflow diagrams [2]. The topic of this paper is modelling of working groups. We want to show that modelling techniques from information systems design might be useful to model working groups. This work is similar to information systems design to the extent that the modelling techniques are the same. It differs from information systems design, because the focus is on the group process rather than the information system. This paper is limited to those models that have an underlying graph structure and have a pictorial representation. We call these graphical models. E-R diagrams, and Dataflow diagrams are well known examples. Clay models, model aircraft, simulation models, linear programming models, aerodynamic models etc. are excluded from this category. Formal (mathematical) models are also excluded, although we use them in this paper to formalise graphical models. To avoid confusion, note that we study graphical models, but we use formal models in the process. We are interested in modelling working groups for the design of groupware systems. Groupware systems are computerised systems for the support of groups. Groupware systems are studied in a new multidisciplinary research area called Computer Supported Cooperative Work (CSCW) [3, 4]. Researchers in CSCW work on theories for the computerised support of working groups in organisations. Research in this field requires knowledge of sociology, management science, and various areas of computer science: data-communication, human-computer interfaces, information systems design. Much of the reported work is technology driven, i.e. giving account of new applications of groupware systems [5]. The problematic acceptance of groupware systems [6, 7] motivates a groupware development approach starting with the user of the CSCW technology: the group. Questions to be addressed are: "What are the needs for computerised support of the group? What is the group task? What means and patterns of communication are applied? How is the group process distibuted among some subgroups? These and other questions demand group modelling. The group models are input for the design of the support software configured from group interaction components. The latter issue is beyond the scope of this paper, more can be found in [8, 9] In order to know how to model working groups, it must be clear why models are made in the first place. when models are successful, and how models are made in general. Section 2 gives a short introduction. Then, in section 3, working group modelling is discussed. The approach is illustrated by three modelling techniques, each highlighting a different aspect of a working group. At the end of this paper, these models are related. Words and phrases in this paper have a meaning that matches daily speech as much as possible. Nevertheless, we have attempted to adopt an accurate use of language. A list of terms can be found at the end of this paper.
1.1
Acknowledgements
The authors wish to thank Paul Grefen, Maarten Fokkinga and Pim van den Broek for their comments while writing the paper.
2 2.1
Modelling Motivation
Models serve as communication means when dealing with complex problems. Without a model, people can discuss an issue within their own frame of mind, not realising that others have an entirely
different conception. If a participant in that discussion recognises the chaos, she may decide to make a model. This model is an abstraction of the subject system, that shows one particular aspect of that system. In the discussion, it may help to expose the different conceptions of the participants, enabling them to enhance their shared understanding of the phenomenon. Thus, a model can help to establish a common frame of reference, by showing an explicit structure. In this perspective, a model has the purpose to improve communication, by creating a larger ‘common reference’ in a group of people. Taking this purpose seriously, we observe that people make many inadequate models. Very often, a picture with many circles, arrows, dotted lines, boxes etc. is presented that does not evoke a common understanding. Although the picture may be beautiful, symmetric, or coloured, if it does not ‘ring any bells’ with the audience it is of no use. We want to use graphical models for studying working groups. Graphical models are used frequently in the design of information systems. Our work can be seen as an extension of information systems design. Nowadays, there exists a large body of knowledge about information systems design. However, the subject of group interaction is hardly investigated from this perspective. Models of the information processing of individual users provide a basis for group models. We think that graphical models are useful for modelling working groups, because of the expressive power that pictures can have. How this is done is the point of our paper. We define a working group as a group of people performing a collective task, where all participants are aware of each other’s participation and contributions. The so-called group-awareness is important to exclude multi-user information systems of which the users perceive themselves as individually operating task performers. Organisational structures and boundaries tend to yield the wrong perspective in studying group processes. A group process has to be considered in its full context [7]. For example, a damage claim handling process involves many people inside and outside an insurance company. The word group is used to stress that people work together for a specific purpose, and not because they are in the same department.
2.2
Purpose
The purpose of modelling is to create a clear and structured view of an aspect of a system and help restrict to the relevant information [10]. We will discuss each of the emphasized words separately. In this discussion, a clear distinction is made between a model of a system and the system being modelled. We use the phrase subject system to denote the latter, and the word model to indicate the former. (See the appendix for definitions). This purpose requires that models are simple to understand. A clear view is not a property that can be measured objectively by inspecting the model. It is rather a property that depends on the person for whom the model is intended. Whether a model is accepted by its ‘audience’ depends on this property. We see, for instance, that the Entity Relationship diagramming technique of Chen [1] has a much wider acceptance than the Binary relationship modelling technique of Nijssen [11], possibly due to the more elaborate notation of the latter. The verb restrict implies that a model does not exhibit all properties of a subject system. It is not even desirable to have a model that exhibits many properties. If a model is deliberately restricted to one aspect only, it stands the best chance of being understood. This aspect is chosen by the modeller. In fact, a model represents many choices of the modeller; every element in a model is a choice. The ability of the modeller is demonstrated in whether a model serves its purpose: clarifying and structuring. The modeler must therefore be conscious about which aspects are being emphasized and which are ignored. For a model can have a major impact on the way people will develop their thoughts. The power of a model lies in its ability to influence these thoughts profoundly. In information system
design it is commonly accepted to distinguish the aspects of data, process and behaviour in separate but inter-related models [12]. In groupware design such aspects have not been identified yet. We will propose a framework of determinant group aspects in section 3. This brings us to the notion of relevance. When is a model relevant? Which aspects of a subject system need to be modelled? In the analysis of systems, it is all too easy to miss important aspects when the modeller is biased in other directions. An easy check on the relevance of a model can be done in practice. If a model is used in a discussion, it should ‘ring a bell’. People must recognise a structure that may have been implicit till then. Modelling has the purpose of communication by creating a shared frame of mind among people. In our practical work we have noticed that some models are more successful than others in providing a clear understanding of a group process. Although there is no recipe for success, there are some guidelines that we have learnt to appreciate. First, we use only well defined modelling techniques. That is: the form, the meaning and practicalities of a modelling technique are established. A picture without an underlying graph structure may be an illustration that supports an argument. However, it may not help to enhance the shared understanding of the stakeholders involved in the analysis. On the contrary, it may even hide misunderstandings by giving an illusion of shared understanding. The examples in the sequel illustrate this argument. Secondly, we restrict to models that show one aspect of the subject system. A model must reduce a phenomenon to a simple structure, in order to make it suitable for shared understanding. Mixing different aspects in one model makes the model more complicated to understand, and therefore less suited for its purpose. Thirdly, we use a modelling technique in its pure form. Decorations, additional graphical elements and structures may cause confusion among the users of the model. Very often, additional elements are used to show aspects unrelated to the original purpose of a model. But, new graphic elements may cause users to question the original graphical elements also, causing more confusion. Finally, every aspect of interest leads to a different model. This gives rise to a number of different models that describe a single system. Each model gives a different perspective on that system.
3
Working Group Modelling
From failing group support systems [6] it can be deduced that the support of group work is not an obvious matter. One of the reasons that many CSCW projects fail is that technology is developed with little consideration for the problems in the group process that are to be solved. Studying and describing the behaviour of groups of people is usually done in the social sciences. It is still an open question whether graphical modelling, as used in information systems design, yields useful new insights about group processes. The discussion in section 2 implies that we first need to identify the principal aspects of working groups. In the literature it is hard to find models of working groups that are based on solid research. One validated framework we found is made by Deborah Gladstein [13]. It has been validated by statistically, based on information about approximately 100 working groups. Figure 1 shows the structure of this framework. The purpose of this framework is to determine which variables are most predictive of team effectiveness. Each box in figure 1 represents a set of variables that have been correlated to find predictive relations. To discuss Gladstein’s framework in full detail would be beyond the scope of this paper. We assume the names of the seven aspects clearly describe an intented contribution to group work. More about the aspects can be found in [13].
INPUTS
PROCESS
Group composition
Group task
OUTPUTS
Group structure Group process
Group effectiveness
Resources available
Organizational structure
Figure 1: Gladstein’s framework for group performance We want to address the point that models can be kept simple and still be formal. Furthermore, a modeller must be aware of the formal meaning of a model, even if the formal definition is not understood by a reader. This is elaborated in section 7. The next three sections contain three examples. Each one describes a modelling technique that can be used in one of Gladstein’s categories. Three popular modelling techniques are chosen to demonstrate the practicality. The examples are taken from a fictitious bakery company, Loaves & Cakes, Ltd., where we analyse the group process that deals with orders. Each of the example modelling techniques is discussed by giving the pragmatics, the syntax and the semantics of the technique. A reader who wants to develop an intuition about the modelling techniques may safely skip the syntax and the semantics. The pragmatics should be sufficient to understand the modelling technique. The formal parts become essential when there is a problem about form (e.g. is picture X a model?) or meaning (e.g. does picture X mean what it is supposed to mean?) Understanding the formalism is essential for a modeller, to avoid ill use of a modelling technique.
4
Example: Organigram
Organigrams are a generally accepted modelling technique to illustrate the hierarchical structure of an organisation. In Gladstein’s framework, the organigram describes the organisational structure. Figure 2 gives an example.
4.1
Pragmatics
An organigram is intended to give insight into the structure of an organisation. There are three kinds of graphical elements in an organigram: a rectangle, a diamond and ‘forks’ that connect them. Rectangles and diamonds describe groups of people in an organisation. The word department is used in a generic sense, referring to any organisational unit that consists of people. Departments, subdepartments, the whole organisation and the smallest working group are all called department. Rectangles represent line-departments and diamonds represent staff-departments. Line-departments are departments involved in the primary process of the organisation. The staff-departments provide secondary support for the business processes in the line-departments. The whole organisation is
Loaves & Cakes Ltd.. adv. brd.
production
warehouse
sales
R&D
private
catering
raw
product
markt.
acct.
shop
Figure 2: Example of an Organigram modelled as a line-department, which is the top rectangle in the organigram. A fork represents a ‘subdepartment’ relation. People in a group are often divided into smaller groups. All people in a subdepartment are considered to be member of the whole department. For example, in an academic environment a faculty is part of a university, a faculty consists of departments and institutes, and a research group can be part of an institute. All members of a research group are also member of the university.
4.2
Semantics
An organigram is a tuple (L; S ) in which L and S are finite disjoint sets of departments. Set L is the set of line-departments (rectangles) and S is the set of staff-departments (diamonds). In order to be an organigram, (L; S ) must satisfy the following conditions for every x and y in L [ S :
9z 2 L : x z ^ y z x 2 S ) y 6 x We use the word department to denote an element of L [ S . The subset relation () describes that one department is part of another department. The first condition enables us to construct a tree-structure of line-departments. The second condition says that staff-departments have no subdepartments. The intended interpretation is that a department is a set of employees. This makes L and S into a set of employee-subsets. So, the root of the tree represents the set of all employees in the organisation.
4.3
Syntax
The semantics describe the relation between rectangles, diamonds and the ‘forks’ that connect them. The syntax describes the form of the tree. We give an informal description. Figure 2 can be used as an example, which might help to understand the syntax. The largest set in L is chosen as the root r of the tree. A department s 2 L [ S is a son of another department p if p is the smallest set in L that satisfies s p. If a department has sons, the rectangle representing it is connected to the stem of a fork. The sons that are a line-department are connected to
the teeth. The sons that are a staff-department are connected with a horizontal line to the stem of the fork. It is worth noticing that the graphical representation of staff-departments supports the semantics in a beautiful way. A modeller is discouraged to identify subdepartments in a staff-department, or to identify staff-departments without linking it to a line-department. In this way, it is made hard to make errors.
4.4
Extensions
Organigrams are rarely used in the pure form as described here. One might add extra predicates to curb the model further. It can even be useful to add predicates in the process of modelling. For example, a modeller might want to describe that no employee can be allocated to two departments that are not part of one another. This can be enforced by requiring for all x; y 2 L [ S :
x y _ y x _ x\y = ; Such additional restrictions can be useful to get refinements of a model. By successive refinements, a sequence of models is obtained that can bring the modeller closer towards her objectives. Other extensions involve the ‘decoration’ of the model with attributes. For example, a budget can be allocated to every department by introducing an extra function:
budget
L [ S) ! N
: (
Additions to "pure" models are necessary to adapt a specific modelling technique to the questions a modeller wants to be answered.
5
Example: Process Interaction Diagram
order in
production products
prod. or sell from stock.
return
delivery
stock control
products
Figure 3: Example of a Process Interaction Diagram Process interaction diagrams [14] are a second example of a modelling technique for group processes. These diagrams are used in logistic modelling for shop floor simulation and control [15]. In a recent study [16] we have experienced that these models are successful in describing workflow processes at an insurance company. In the framework of Gladstein, process interaction diagrams describe the group process. Figure 3 is an illustrative example of a process interaction diagram..
5.1
Pragmatics
PID’s have simple pragmatics, because there are only two graphical concepts: circles and arrows. A circle represents a process and an arrow represents an interaction, which is basically a stream of events. The meaning of one interaction must be seen in the context of time. An interaction can be an electrical signal, starting from the moment the system is built until ‘eternity’. Likewise, the processes are considered to work in parallel. It takes some experience to make proper use of PID’s. Inexperienced modellers tend to choose organisational units instead of processes, for example: mail department, administration, warehouse. Such notions reflect the structure of the organisation in the mind of the modeller. In order to use PID’s properly, the modeller has to forget about the organisational units and start thinking about processes. For example: sorting mail, distributing mail, distributing goods, storing goods. It is our experience that PID’s are usually simple when the circles represent processes. The presence of many arrows in a PID is also an indicator for bad modelling.
5.2
Syntax
A PID is a quadruple (P; I; s; d), in which P is a set of processes and (mnemonic: source) and d (mnemonic: destination) are total functions I
I is a set of interactions. s ! P.
A process is drawn as a circle and an interaction is drawn as an arrow. The arrow representing interaction i is drawn from the edge of the circle representing process s(i) to the edge of the circle representing process d(i). The name of a process is printed inside the corresponding circle. The name of an interaction is printed anywhere ‘near’ the corresponding arrow, or omitted when appropriate.
5.3
Semantics
Process interaction diagrams have a meaning related to time. Let T be the set containing all time instants. For continuous processes, T might be the real numbers R. For discrete processes (events), T might be N. Every interaction i has a value set val(i), that contains the values an interaction may take. For instance, if i represents a digital signal, val(i) might be f0; 1g. Or, if i represents a stream of insurance claim forms, val(i) is the set of all possible insurance claim forms. Every interaction i is a function that maps time to a value of some sort:
i : T ! val(i) The inputs of a process p are all interactions pointing towards p:
inputs(p)
=
fi 2 I jd(i) = pg
Similarly, the outputs of p are:
outputs(p)
=
fi 2 I js(i) = pg
A process is a function that maps inputs to outputs:
p : inputs(p) ! outputs(p) For example a baking process can be modelled by a function that maps four streams of ingredients (i.e. flour, yeast, salt and water) to one stream of bread.
6
Example: Logistic Model
The logistic modelling technique is a variant of the data flow diagramming technique, developed to describe the logistics of the information processing in information intensive organizations [17]. Logistic models turn out to reflect the arrangement of employee tasks in a better recognizable way than the data flow diagrams. Figure 4 shows a part of a logistic model.
Customer
order
Order administration
file order
delivery orders approve credit
check cust. status
accepted orders
reconsider
deliver
Figure 4: Example of a Logistic Model
6.1
Pragmatics
Logistic models have several symbols. Each arrow represents a stream of work orders. Work orders can be forms, letters, tables etc., that are related to the business process. The objects in the logistic model are:
External agents, denoted by double rectangles; external agents are parties outside the organization that interact inside the working group. Processes: denoted by a rounded rectangle; these are either information retrieving and transforming processes, or group interaction processes. Waiting queues, denoted by open bins; queues represent a delay in the business process. Logistic regulators in four types: split, join, switch and junction, denoted by some symbol derived from electronic models; logistic regulators direct the work orders between the various processes and queues.
The logistic model is used to model the primary business process triggered by an order from an external agent. All tasks involved in the process should be specified in the model. Exception handling, i.e. dealing with erroneous or unclear data, can be included.
6.2
Syntax
A logistic model is a graph (N; W ), where N is the set of nodes consisting of the mutually disjoint sets E of external agents, P of processes, Q of queues, and R of logistic regulators, and W is the set of arrows denoting streams of work orders.
W N N s : W !N d : W !N w = (w1; w2) = (s(w); d(w)) A logistic model should satisfy quite a few (25) syntactic rules. We give three examples:
8n 2 N : 9w 2 W : s(w) = n _ d(w) = n 8n 2 E : (9w 2 W : s(w) = n ^ d(w) 2 P ) _ (9w 2 W : s(w) 2 P ^ d(w) = n) 6 9w 2 W : s(w) 2 Q ^ d(w) 2 Q The first rule specifies that all nodes are connected with some other node by a work order stream. The graph is not necessarily be connected. The second rule states that each external agent is connected to a process. The final rule prohibits two waiting queues from being connected. There needs to be some process in between.
6.3
Semantics
We do not give the complete semantics of the logistic model for the same reason as we gave only a bit of the syntax. The logistic model is too complex to describe in this paper. Nevertheless, we can illustrate the idea informally. Logistic models can be (discretely) simulated using the rational numbers as time T . Processes are modelled as agents that treat every work order in a constant time, that depends on the process. This is specified by a function:
processing : P ! T
Similarly, external agents have a specified average time between two work orders. The regulators are considered to perform their task without delays. Starting with a specified initial state, the successive states of the system can be calculated. These functions can be implemented in a simulation program to analyse the performance of the groupware system supporting the working group. Simulation of the business process is one of the advantages of the use of the logistic model.
7 7.1
Observations Description of groups
The reader may have noticed that all three examples have been chosen in the context of a bakery. In fact, each one of the three models gives a different perspective on the case. The organigram shows
groups as they occur in the formal organisation. The process interaction diagram shows (group-) processes and their mutual relations. The logistic model gives part of the order process. Modelling in this way means that specific aspects of a group are highlighted. This evokes the discussion which aspects are most interesting to study. It is quite clear that it is impossible to study all conceivable aspects. Choices must be made in order to get a description of the group that is relevant to the purpose of the analysis. So, this modelling ‘discipline’ helps to make the purpose of modelling explicit, thus avoiding many useless models in practice.
7.2
The role of mathematics
Many practitioners have insufficient mathematical education to use formalisation effectively. Fortunately, mathematical ability is is only needed by those who make models. In order to understand a model, the modeller must be able to explain (in plain language) what the model means. When groups are modelled, the discussion should not focus on the form and formalism behind a model, but rather on the aspect of interest which is to be modelled. However, when the modeller does not know about the form and meaning of the models being used, there is a large risk of misuse. This misuse becomes visible in the form of many pictures with too many different graphical elements with a meaning that cannot be made explicit.
7.3
The value of pictures
A picture can have a high value in communication between people. Implicit structures in a group of people can be made explicit in the form of a picture. In that case, people can recognise their implicit knowledge, which helps to create a comparable frame of mind. In this way a picture can help to avoid misunderstandings and accelerate the forming of a collective opinion. Pictures have the quality of being understood by large audiences. A well conceived picture can help a large group of people with very different backgrounds to get a similar understanding of a phenomenon. This is an important reason to try to use graphical models to analyse group processes.
7.4
Complexity
Organigrams are the simplest of the modelling techniques described in this paper. The logistic model is the most complicated. In our experience with models, we found that modelling techniques with a simple structure are easier to explain and more likely to be appreciated. Complicated modelling techniques are not used very much. A ‘complicated’ modelling technique like the logistic model shows the subject system in more detail than a ‘simple’ technique like the process interaction diagrams. So, the modeller is confronted with the problem of striking the right balance between simplicity and detail. The criterion will allways be whether the stakeholders can actually recognise their ideas in a model. We think that the pragmatics of a modelling technique is very important in the success of it. A technique with a simple, straightforward relation to daily practice (such as organigrams) is more likely to be found useful than a technique with remote pragmatics.
7.5
Meta-modelling
In order to use a modelling technique in a proper way, it is necessary to have a sound description of the technique. We have given three examples of such descriptions. In fact, these descriptions are models of modelling techniques. That is why they are usually called meta-models. Meta-modelling is the construction of models that describe a modelling technique. The discussion about the way to model a group is a discussion about meta-models. This discussion is conducted by methodologists, studying different modelling techniques. A practitioner is not interested in making a meta-model, but in its use. The practitioner will use a modelling technique, and should want to do this properly. For that purpose, practitioners need a (passive) understanding of meta-models. The examples shown in the previous sections are not the only way of presenting meta-models. The reason is simple: meta-modelling is modelling, so there are infinitely many ways to do it. The choice of a meta-model depends on the audience for whom the meta-models are intended, and the aspects of interest. We have chosen to model three aspects: pragmatics, syntax and semantics. Each aspect is treated in a different ‘model’. Thus, we have lived up to our own standards. Many ways of meta-modelling are possible. A different way is described in [10].
7.6
Integration
Different models of a single subject system are interrelated. Very often, conceptual choices in the analysis affect several models simultaneously. In that case it can be desirable to make the relation between different models explicit. If a modelling technique is described formally, it is an obvious choice to formalise the relation between different models as well. Meta-models play an important role in this process..
7.7
Gladstein’s framework
The framework of Gladstein is useful to identify different aspects of a group that are related to the group effectiveness. Although we have only elaborated three aspects, it may be clear that all of these aspects can be modelled using different graphical modelling techniques. In this way, Gladstein’s framework is useful as a general basis for the study of formalised group models.
8
Conclusion
In order to serve its main purpose as a communication medium in a group of people, it is necessary that all participants understand the meaning of the model. Understanding a formalisation of a modelling technique is necessary in order to make proper use of it. However, a modeller does not need to make such formalisations in order to use the technique properly. Gladstein’s framework offers a good starting point for the formalisation of group modelling. In order to define the meaning of a model formally, it is possible to use a minimum of mathematics. Apparently, elaborate mathematical exercises can be avoided.
Appendix: Terminology model [10] A system A is used as a model in order to obtain knowledge about a system B .
In the paper we refer to the system A as the model and to system B as the subject system. Note that the systems A and B should be unquestionably separated, i.e. A providing an abstraction of B .
graphical element Any element that is used to construct pictures: e.g. line, circle, arrow, rectangle. graphical model A model that is based upon an underlying graph structure and represented as a picture by means of graphical elements. working group A group of people performing a collective task, where all participants are aware of each other’s participation and contributions. syntax [18] The way in which words are put together to form phrases. In this paper, the syntax describes the way graphical elements are put together to form a model. Syntax describes the form of a model. semantics [18] the study of meanings. In this paper, we study the meaning of models in a formal way. pragmatics [18] a branch of semiotic that deals with the relation between signs or linguistic expressions and their users. In this paper, we deal with the relation between graphical elements in a model and their meaning as perceived by their users.
References [1] P.P. Chen. The entity-relationship model - toward a unified view of data. ACM Transactions on Database Systems, 1(1):9–36, 1976. [2] C. Gane and T. Sarson. Structured Systems Analysis: Tools and Techniques. Prentice Hall, Englewood Cliffs, 1979. [3] Clarence E. Ellis, Simon J. Gibbs, and Gail L. Rein. Groupware: some issues and experiences. Communications of the ACM, 34(1):38–58, January 1991. [4] ACM. Special issue on collaborative computing. Communications of the ACM, 34(12), December 1991. [5] Jon Turner and Robert (eds.) Kraut, editors. Proceedings CSCW ’92: Sharing Perspectives, 1515 Broadway, New York, New York 10036 USA, November 1992. Association for Computing Machinery. [6] Jonathan Grudin. Why cscw applications fail: Problems in the design and evaluation of organizational interfaces. In Proceedings CSCW ’88, pages 85–93, September 1988. [7] Wanda J. Orlikowski. Learning from notes: Organizational issues in groupware implementation. In Jon Turner and Robert Kraut, editors, Proceedings CSCW ’92: Sharing Perspectives, pages 362–369, 1515 Broadway, New York, New York 10036 USA, November 1992. Association for Computing Machinery.
[8] Mark Roseman and Saul Greenberg. Groupkit: A groupware toolkit for building real-time conferencing applications. In Jon Turner and Robert Kraut, editors, Proceedings CSCW ’92: Sharing Perspectives, pages 43–50, 1515 Broadway, New York, New York 10036 USA, November 1992. Association for Computing Machinery. [9] J.R. Patterson, R.D. Hill, S.L. Rohall, and W.S. Meeks. Rendezvous: An architecture for synchronous multiuser applications. In Proceedings CSCW ’90, Los Angeles, pages 317–328, New York, NY 10036, October 1990. the Association for Computing Machinery. [10] Sjaak Brinkkemper. Formalisation of Information Systems Modelling. PhD thesis, University of Nijmegen, June 1990. [11] G.M. Nijssen and T.A. Halpin. Conceptual Schema and Relational Database Design: a FactBased Approach. Prentice Hall, Englewood Cliffs, 1989. [12] T.W. Olle, J. Hagelstein, I.G. MacDonald, C. Rolland, H.G. Sol, F.J.M. van Assche, and A.A. Verrijn Stuart. Information System Methodologies - A Framework for Understanding. AddisonWesley, 1988. [13] Deborah L. Gladstein. Groups in context: A model of task group effectiveness. Administrative Science Quarterly, 29:499–517, 1984. [14] J.E. Rooda. Procescalculus for modelling (in dutch). Mechanische Technologie, pages 10–20, December 1991. [15] A.M. Wortmann. Modelling and Simulation of Industrial Systems. PhD thesis, Technological University of Eindhoven, November 1991. [16] Edwin Douma and Paul Jongen. Work flow management and documentary information systems at centraal beheer. Master’s thesis, University of Twente, dept. of Comp. Sc., P.O. Box 217, 7500 AE ENSCHEDE, the Netherlands, to appear in 1993. [17] F. Harmsen, M. Kraakman, S. Brinkkemper, N. Brand, and A. ten Harmsen van der Beek. The logistic model: The integration of business process redesign and information systems development based on logistic principles. Memoranda Informatica, 92(70):1–25, November 1992. [18] Merriam-Webster, Inc. Webster’s 7th Collegiate Dictionary, 1963.
