teamwork coordination in a distributed software development ...

TEAMWORK COORDINATION IN A DISTRIBUTED SOFTWARE DEVELOPMENT ENVIRONMENT* Andreas Oberweis, Thomas Wendel**, Wolffried Stucky Universität Karlsruhe Institut AIFB D-76128 Karlsruhe Germany eMail: {oberweis|wendel|stucky}@aifb.uni-karlsruhe.de 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Teamwork in INCOME/STAR . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Teamwork components . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Supporting group communication . . . . . . . . . . . . . . . . . . . . . . . 4. Supporting workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Coupling group communication and workflow management . . . 6. Related approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 3 5 8 10 11 12 13

Abstract The development process of large software systems is usually splitted into several subprocesses which are to be handled by different project teams. An efficient coordination of the development activities is an important prerequisite for a successful software engineering project. For that reason group communication and workflow aspects must be supported by appropriate teamwork methods and tools. This paper surveys the teamwork methods and tools of INCOME/STAR which is a cooperative development environment for distributed information systems. _______________ * to appear in: Proceedings of the IFIP '94 Workshop FG 9: Communication and Coordination in Distributed Corporate Application Systems, Hamburg, August 28 - September 2, 1994 ** Th. Wendel's work was supported by a scholarship according to the 'Landesgraduiertenförderungsgesetz Baden-Württemberg' under grant no. 8122/93.

1 Introduction Teamwork in a software engineering project includes different coordination aspects. Usually many different workflows are implied by a software development process model, which prescribes - among other things - the general course of the development process and all demanded deliverables such as design and system documents or source codes. During the whole course of a development project, communication support and efficient management of the flow of work items between different people or between different groups of people is required.

perspective system development consists of the execution of prescribed activity structures. In contrast to this the social action perspective describes the development process as social processes of interactions between developers and users [HiKN87, cited in WaWh93]. Due to this distinction, workflow management can be related to the technical perspective and group communication to the social action perspective on system development. Consequently both perspectives have to be considered in a development environment. So, the users of the environment have to decide, what perspective they want to prefer in the current project context. For this reason we introduce an

Specific types of communication are related to

approach which supports (technical) workflow

certain project activities, such as requirement

management as well as (social) group commu-

definition, collective design, document review,

nication. A communication process can be trig-

program inspection, software testing and pro-

gered by workflow and vice versa. Moreover

ject management.

the possibility is given to adopt communication

Workflow management in a software develop-

processes to workflow processes and to pay ex-

ment project includes the following aspects:

plicitly attention to the association between

planning and modelling of development acti-

communication and workflow in an easy way.

vities, based on a development process

This paper is organized as follows: In chapter 2

model.

we

resource allocation.

INCOME/STAR, a distributed environment for

monitoring and control of development

the cooperative development of distributed in-

activities.

formation systems. Chapter 3 describes the sup-

introduce

teamwork

components

of

A communication process may be interpreted as

port of group communication during the

a special kind of workflow. However, this inter-

development process. In chapter 4 several fea-

pretation neglects the necessity to distinguish

tures of the workflow management in INCOM-

between a technical and a social action per-

E/STAR are surveyed. Chapter 5 shows the

spective on system development. In a technical

possibilities to couple group communication and workflow management. In chapter 6 a list

of related approaches is given. Finally, chapter

groupwork. Especially components of the latter

7 presents future work.

type are responsible for teamwork support between different environments.

2 Teamwork in INCOME/STAR

The INCOME/STAR repository contains process model representations and stores all devel-

This chapter describes the teamwork compo-

opment documents. Moreover it is responsible

nents of INCOME/STAR which is a repository-

for consistency control of documents and it

based environment for the cooperative develop-

supports shared access to process information.

ment of distributed information systems.

Development process information consists of

Figure 1 presents a general view of the distribu-

static data and dynamic behaviour aspects,

tion structure of INCOME/STAR. Each project

which are represented by a semantic object

team works with its own environment which

model and high level Petri nets. This informa-

consists of - among other components - several

tion is stored in so-called development objects.

teamwork

Furthermore the repository contains so-called

components

and

the

teamwork objects, such as conversation dia-

INCOME/STAR repository.

grams (see below for details) and eMail Environment A

Environment B

project team A

project team B

documents. Moreover there are appropriate mechanisms to guarantee a valid distribution of data and pro-

teamwork components

teamwork components

INCOME/STAR repository

INCOME/STAR repository

INCOME/STAR

INCOME/STAR

- Distribution of data and processes - Consistency mechanism - Teamwork support

cesses with respect to several consistency checks.

2.1 Teamwork components Among other components - like graphical editors, database and application program generators, etc. - there are the following teamwork specific components using the INCOME/STAR

Figure 1: Teamwork support in a distributed development environment

repository (see Figure 2): extended eMail system

Teamwork components have the aim to support

The eMail system maintains a semi-structured

work activities between members of a group,

message exchange which supports the use of

so-called intra-groupwork, and between mem-

message filtering methods to avoid informa-

bers of different groups, so-called inter-

tion overload, a typical problem of existing

teamwork components

tem ed il sys d en a y da ext eM person-centered components n pla

ne

r

ion sat er r e g v con mana

low r rkf nage o w ma group-centered components

teamwork objects

development objects

teamwork information INCOME/STAR repository

Figure 2: Teamwork components in INCOME/STAR computer-mediated communication systems

to analyze incoming mails. The mail editor

[HiTu85]. Therefore we have extended the

maintains the creation of mail with respect to

conventional eMail structure by different

the selected eMail type. Furthermore it per-

areas, where rule expressions - like if mail

mits the conversion of a mail from a given

comes from team member smith then put mail

eMail type into another kind of eMail type.

in dictionary smithMail - can be interpreted. Furthermore there are four different types of eMail: common, standard, extended and conversational eMail. Common eMail corresponds to conventional UNIX mail. Standard eMail permits to format the mail content. Extended eMail allows the declaration of specific message types, for instance a request or a

day planner The day planner maintains three kinds of electronic calendar: personal, group and common project calendar. A personal electronic calendar consists of private and shared spaces. Shared spaces - in contrast to private spaces are periods of time which can be seen and manipulated by other authorized team members.

question. Conversational eMail is embbeded in a so-called conversation which declares valid orders of message types which can be modelled in a conversation editor tool.

Group appointments can be realized by using appropriate shared spaces of all team members. These group appointments are registered in a group calendar. Furthermore there is a

The main components of the extended eMail system are a mail desktop and a mail editor. The mail desktop provides access to incoming mails and supports message filtering methods

common project specific day plan, in which all deadlines and important project dates are registered und by this are accessible to group members.

conversation manager

of a group appointment negotiation, are also

The conversation manager allows the planning

supported by this component.

and modelling of conversations, which are represented by conversation diagrams (see below for details). Furthermore there is a

3 Supporting group communication

monitor component, which presents progress

Computer supported group communication de-

information

pends on the available communication infra-

about

current

conversation

processes. workflow manager

structure. In software engineering projects members of different project teams often use computer-mediated

The workflow manager supports planning and modelling of development activities based on a development process model. It monitors and

communication

systems

(CMCS), like eMail systems or bulletin-board systems, for information - especially document exchange due to the following reasons:

controls the execution of workflows and supports resource allocation.

possibility to exchange complex multi-media information.

Each team member has access to own, adapt-

project teams may be located at geographi-

able instances of the day planner and the mail

cally distributed places.

desktop. So these applications emphasize a

different working times.

person-centered view on teamwork. Comple-

low costs to realize communication

mentary to this kind of view, the workflow

possibility.

manager and the conversation manager must pay attention to group specific information, like general resource allocations, personal compositions of groups or the skills of group members. So, these components emphasize a groupcentered view on teamwork.

We decided to use an eMail system as favorite basis for realizing group communication because this kind of CMCS is usually available in every network environment. However conventional eMail systems only support text document exchange between different team members

In contrast to group-centered components,

acting as mail sender or mail recipient (in the

person-centered components can also be used

following called 'sender' respectively 'recipient').

without teamwork functions ('stand alone'

There is no explicit consideration of the follow-

mode) due to the fact that everyday work con-

ing social action aspects, which are important

sists of individual and group specific activities.

for an efficient group communication support:

For example, in general the day planner supports personal time organization. Furthermore specific teamwork functions, i.e. the execution

Why is the mail sent to the recipient? Which working context is assumed?

Which reaction is expected by the sender?

processes. On the second layer the extended

Is this mail important for the current work

eMail system is introduced. Each extended mail

of the recipient?

corresponds to a document stored in the

etc.

INCOME/STAR repository. The extended

The following technical aspects must also be considered:

eMail system can be supplemented on a third layer with the conversation manager to allow the execution of conversations. All conversa-

Which kind of documents (e.g. simple text, multimedia, etc.) can be transmitted? Which recipients can be reached? What kind of mail information can be used?

tion information, concerning, e.g., conversation diagrams or conversation reports, is also stored in the INCOME/STAR repository as teamwork objects.

etc. Consequently, conventional eMail systems must be extended to pay attention to these aspects. For this reason so-called adaptorsystems are proposed in [HoRö93]. A simple extension is the use of specific mail areas to declare filter information and a mes-

ail eM

ail eM

ail eM

t. ex Mail e

t. l exMai e

t. exMail e extended eMail system

sage type. Filter information can be interpreted to avoid information overload. A message type, like an enquiry for appointment, allows to put the mail in a specific working context. Often a specific kind of reaction is expected by the sender. However this expectation can be

on ati ger s r e a nv an co m conversation support teamwork objects conversation diagram

INCOME/STAR repository

misjudged by the recipient. So the sender needs the possibility to propose different types of valid reactions. This feature can be realized by ex-

Figure 3: Group communication support in INCOME/STAR

ecuting a conversation which is based on a

Conversation diagrams are a graphical lan-

conversation diagram.

guage which allows to specify communication

Figure 3 shows the general layer structure of

processes in an easy and intuitive way. Each

group communication support in INCOME/

conversation diagram consists of two compo-

STAR. On the top layer a conventional eMail

nents: conversation acts and processing rela-

system is used to permit communication

tions. The execution of a conversation diagram

under control of the conversation manager is

information while a conversation process is 'on

called a conversation.

the run'. The information used to check the ful-

A conversation act represents a team member related communication activity which can be

fillment of the conditions is also stored in the INCOME/STAR repository.

linked to additional conversation acts by pro-

However, the initiator of a conversation has the

cessing relations. A processing relation repre-

possibility to decide whether given conditions

sents the following so-called conditions of

have to be used in the current process or not.

fulfillment to execute a conversation act:

Additionally the execution of a conversation act depends on the conversation processing state.

i. conversational relevance This condition represents the importance -

A conversation process passes through the fol-

e.g. high, low or undetermined - of the fol-

lowing three states: start, continue and

lowing conversation act for the course of the

end. Possibly the continue state can be

conversation. In this way course preferences

omitted to realize a simple communication pro-

can be considered.

cess which consists of a single sender and a single recipient activity.

ii. personal competence A conversation can also pay attention to the

neglect

this

analyst kind

of

knowledge. iii. organisational role Each software project is embedded in an or-

strong start act

X

weak start act

X

continuation act

X X

strong conclusion act weak conclusion act

end

can

an

or

(possibly)

while

continue

language

or

have good knowledge of (at least) one programming

... turns conversation process into state ...

start

and skills. For instance, a programmer must

conversation act types graphical representation

fact that team members differ in competence

X X

X

ganisational context. Within this context different kinds of roles, like programmer,

Figure 4: Conversation act types

analyst, etc., will be taken by the team members in the course of a software project.

At state start a new conversation process is initiated. If the conversation process is finished

These conditions can be used to restrict the par-

it gets the state end. At state continue there

ticipation on a conversation process to a specif-

is (at least) one conversation act which has to

ic collection of team members. Moreover it

be activated.

allows the consideration of different context

Figure 4 shows different general types of con-

quest and repeat the review process with new

versation acts and their graphical representa-

information.

tion.

Each

conversation

act

turns

the

conversation process in a specific state. There are two kinds of conversation acts which can start respectively conclude a conversation pro-

Also A can start a new conversation with the refinement of a given, already accepted request. For that we use a weak conversation act. Consequently the 'accept' act is a weak act, too.

cess: weak and strong types. In contrast to a strong type, a weak act can also be used to con-

4 Supporting workflow

tinue the process. The second group-centered component in Example

INCOME/STAR is a workflow manager which

In the following we consider a typical commu-

supports the flow of work items between differ-

nication process to arrange a document review

ent team members and between different teams

(see Figure 5). If a team member (named A)

based on a workflow model. As a formal speci-

wants to initiate a document review by another

fication language for workflows we use high-

team member (named B), A can start a con-

level Petri nets in combination with a semantic

versation for review with a new review request.

data model. The modeling of workflows in a software engi-

A: new request

neering project consists of the following two (complex) steps: i. Specification of the generic software engi-

B: reject

B: further information

B: accept

neering process model as a hierarchy of Petri nets. The structure of the deliverables is specified in a semantic data model. Development documents usually have a complex structure.

A: refined request

Figure 5: conversation for review (cfr)1

To model operations on complex structured objects adequately we have developed an extension of high level Petri nets, namely

In the following B can accept or reject this re-

NR/T-nets (Nested Relation/Transition nets

quest. Moreover B can ask for further informa-

[ObSS93]).

tion before making a decision. If B accepts the review request, A can possibly refine the old re-

ii. Instantiation of the generic model and tailoring due to the specific project needs.

1

We neglect the representation of specific conditions of fulfillment to keep this example simple.

Finally, each NR/T-net represents a class of possible workflows in a software project. Simulation can be used to validate a given NR/T-net. In INCOME/STAR workflow modelling is supuser interface

ported by a workflow editor, a workflow simu-

workflow engine user interface

lator and a workflow analyzer. The NR/T-net representation of the relevant workflows - including temporal aspects, resource allocation and personal responsibilities -

transaction manager cts development objects bje o rk wo m tea INCOME/STAR repository

is interpreted as a project plan, which is to be fulfilled for a concrete running project. The

Figure 6: Architecture of the workflow manager in INCOME/STAR

workflow manager in INCOME/STAR provides the following functionality:

Figure 6 shows the architecture of the work-

team members are notified about actions

flow manager. Central component of this archi-

that are to be started, completed or inter-

tecture is the workflow engine. It is coupled to

rupted in a given situation.

the repository via the transaction manager. The

team members are provided with specific in-

modification of values in the database or signals

formation about the current system state.

from other software systems trigger certain ac-

project managers are provided with an over-

tivities of the workflow engine.

view

The transaction manager handles the execution

about the status of workflow.

of repository-based transactions. For that it re-

certain standard procedures are automated.

lieves the workflow manager of specific data-

activities and their results are controlled.

base tasks, such as commitment control and

alternative decisions, e.g. alternative re-

exception handling, e.g., in the case of hard-

source allocations, may be validated.

ware

certain procedures may be simulated in ad-

INCOME/STAR's workflow concepts in more

vance, e.g. for training of unskilled persons

detail.

or for analysis. team members are provided with support for exception handling.

errors.

[Ober94]

describes

5 Coupling group communication and workflow management

coupling allows an explicit combination of

There are the following degrees of coupling

the execution of specific kinds of conversation

group communication and workflow manage-

processes:

ment in INCOME/STAR, which depend on the

i. valuation of development objects.

group communication and workflow management. The following aspects can be handled by

use of the conversation manager by the workflow manager in a specific workflow:

ii. support of workflow activities, such as: negotiation about the responsibility for the

i. no coupling Conversation processes can not be initiated by the workflow manager. In this case a pure technical perspective on software development is preferred. All activi-

execution of workflow activities. coordination of several team members related to one workflow activity. exchange of experience to carry out a workflow activity.

ties are exclusively supported by the workflow manager.

Therefore the workflow specification language must be extended by a special kind of transition

ii. close coupling

which we call a conversation-transition.

The workflow manager is able to trigger specific kinds of conversation processes. Here, conversation processes can be related to specific workflow activities respectively specific workflow objects (see below for details).

A conversation-transition represents the execution of a specific conversation process. In contrast to conventional transitions1 it can be related to both places respectively predicates and transitions. For that reason a conversation transition is interpreted in the first case as a

iii. loose coupling

conventional transition and in the second case

All conversation processes supported by the

as a combination of a place and a transition (see

conversation manager can be triggered by the

Figure 7).

workflow manager. In contrast to close coupling, conversation processes can be initiated independent of the

Use of a conversationtransition with

underlying Petri net structure c

c

a place

current workflow. a transition

t

c

t

In the following we consider close coupling in more detail due to the fact that this kind of 1

Figure 7: Conversation-transition

We suppose that the reader is familiar with the basic Petri net concepts (see, e.g., [Reis85]).

c

Therefore we use as graphical representation a

revision in detail. After the revision activity is

box with rounded edges to indicate the modi-

executed, the application will be tested again.

fied semantics. The inscription of the box refers to a specific conversation diagram.

Additionally, it is possible to support the reject application activity by a cfa-process to determine a responsible person for the revision activ-

Example In the following example we want to describe a workflow for quality control (see Figure 8) with a close coupling to a conversation for review (cfr).

ity. Also a cfa-process can be triggered if a test request exists and an appropriate team member is needed for the test activity.

6 Related approaches revise application

compiled code test application

There are several approaches which also aim at supporting teamwork in organisations and espe-

test request

cially in software projects. However, there is usually no possibility given to pass from the so-

cfr revise assignment acceptance program document trouble report

cial action perspective to the technical perspective on software development or vice versa.

reject

source code

application

Some of these approaches are surveyed in the following:

transfer to configuration management

deliverables

prepare for revision

Figure 8: Workflow for quality control

The Coordinator [Wino88] is a conversation based approach which supports everyday communication processes in organisations by fixed orders of messages. Based on the so-called lan-

An application will be tested if a test request

guage/action perspective each message repre-

and an appropriate compiled code are given. If

sents a specific kind of (teamwork) activity.

the application is errorfree, an acceptance

Other approaches which support everyday com-

document will be created and afterwards the ap-

munication in teams on the basis of conversa-

plication documents (source code and compiled

tions are Strudel [ShMK90] and CHAOS

code) will be transferred by the configuration

[BiSi91].

management to the deliverables. On the other hand, if the application is invalid, a program trouble report will be worked out. On the basis of this document the current application will be rejected. The result of this activity is a revise assignment which prescribes the application

The ConversationBuilder [KT..92] maintains collaborative work activities in software projects. It allows the modelling and use of conversation protocols which can be tailored to

certain software development process models or to specific group preferences.

7 Outlook The teamwork components of INCOME/

CoNeX [HaJR90] supports teamwork in soft-

STAR are currently being implemented in

ware projects with respect to the underlying so-

SMALLTALK. We use these components on

cial processes. Moreover, further human

UNIX workstations and PCs. The INCOME/

collaboration aspects, concerning, e.g.,

task

STAR repository is currently realized on the

negotiation and decision making, are also con-

basis of a relational database system in the

sidered. Therefore several models, e.g. a multi-

workstation environment. At present, we are

agent conversation model for task-oriented ne-

validating our approach in practice.

gotiations, are introduced and integrated.

An important aspect of our future work is the

GroupFlow [Hilp94] provides a groupware

support of other system environments, for ex-

based workflow management which maintains a

ample by using commercial groupware applica-

wide area of different workflows. For that it is

tions like Lotus-Notes. Moreover we will

distinguished between the following kinds of

intensify the use of our development environ-

workflow: ad hoc workflow, autonomous work-

ment in software development projects to

group, partially standardized workflow and

evaluate the practical relevance of our research

standard workflow.

work.

MELMAC [BrGr93] is a software process management environment which uses also high level petri nets - so-called FUNSOFT nets - for the representation of human interaction. In this environment FUNSOFT nets are the basis for software process modeling and enacting.

References [BiSi91]

[BrGr93]

[Hilp94] [HiKN87]

[HiTu85]

[HaJR90]

[HoRö93] [KT..92]

[Ober94]

[ObSS93]

[Reis85] [ShMK90]

[WaWh93]

[Wino88]

C. Bignoli, C. Simone: AI Techniques for Supporting Human to Human Communication in CHAOS; in J. M. Bowers, S. D. Benford (eds.): Studies in Computer Supported Cooperative Work - Theory, Practice and Design, North-Holland, pp. 103-118, 1991 A. Bröckers, V. Gruhn: Computer-Aided Verification of Software Process Model Properties; in C. Rolland, F. Bodart, C. Cauvet (eds.): Advanced Information Systems Engineering, pp. 521-545, 1993 W. Hilpert: GroupFlow - Groupware Based Workflow Management, Working paper, Business Computing 2, University of Paderborn, 1994 R. A. Hirschheim, H. Klein, M. Newman: A social action perspective of information systems development; in J. DeGross, C. Kriebel (eds.): Proc. of the 8th International Conference on Information Systems, acm Press, pp. 45-56, 1987 S. R. Hiltz, M. Turoff: Structuring computer-mediated communication systems to avoid information overload, Communications of the ACM, Volume 28, Number 7, pp. 680-689, July 1985 U. Hahn, M. Jarke, T. Rose: Group work in software projects, in S. Gibbs, A. A. Verrijn-Stuart (eds.): Multi-User Interfaces and Applications, North-Holland, pp. 83-101, 1990 K. Hofrichter, K. Röhr: Sanfte Wege zur Multimedia Electronic-Mail; Der GMDSpiegel 2'93, pp. 62-65, 1993 (in German) S. M. Kaplan, W. J. Tolone, A. M. Carrol, D. P. Bogia, C. Bignoli: Supporting Collaborative Software Development with ConversationBuilder; in Herbert Weber (ed.): SIGSOFT '92; Software Engineering Notes, Vol. 15, Nr. 5, acm Press, pp. 11-20, 1992 A. Oberweis: Workflow Management in Software Engineering Projects; in S. Medhat (Ed.): Proc. International Conference on Concurrent Engineering and Electronic Design Automation, Bournemouth/England, pp. 55-60, 1994 A. Oberweis, P. Sander, W. Stucky: Petri net based modelling of procedures in complex object database applications, in D. Cooke (ed.): Proc. Seventeenth Annual International Computer Software and Applications Conference COMPSAC'93, Phoenix/Arizona, pp. 138-144, 1993 W. Reisig: Petri Nets, EATCS Monographs on Theoretical Computer Science, Vol. 4, Springer-Verlag, 1985 A. Shepherd, N. Mayer, A. Kuchinsky: Strudel - An extensible electronic conversation toolkit; CSCW'90, Proc. of the Conference on Computer-Supported Cooperative Work, October 7-10, Los Angeles, pp. 93-104, 1990 D. G. Wastell, P. White: Using Process Technology to Support Cooperative Work: Prospects and Design Issues; in D. Diaper, C. Sanger (eds.): CSCW in practice: An introduction and Case Studies; Springer Verlag, pp. 105-126, 1993 T. Winograd: A language/action perspective on the design of cooperative work; in I. Greif (ed.): Computer-supported cooperative work: A book of readings, Morgan Kaufmann Publishers, pp. 623-653, 1988