Collaboration and coordination in process-centered software development environments: a review of the literature

https://doi.org/10.1016/S0950-5849(03)00091-0Get rights and content

Abstract

Process-centered software development environments are systems that provide automated support for software development activities.

Such environments mediate the efforts of potentially large groups of developers working on a common project. This mediation is based on runtime support for actual work performance based on formal representations of work.

In the present work, we survey and assess the contributions of the software process literature under the perspective of support for collaboration and coordination. A broad range of alternative approaches to various aspects of representation and runtime support are identified, based on the analysis of an expressive number of systems. The identified functionality can serve both as a guide for the evaluation and selection of systems of this kind as well as a roadmap for the development of new, improved systems.

Introduction

Software Engineering “deals with the building of software systems which are so large or so complex that they are built by a team or teams of engineers” [1]. Developing non-trivial software systems is therefore a task that requires that a group of agents work in concert, that is, they must collaborate in order to reach the common goal.

Process-Centered Software Development Environments (PCSDE) allow for the definition and enactment of procedures performed by groups of developers working on a common project. A PCSDE stores definitions of processes in terms of steps that need to be performed, artifacts produced and transformed by these steps, of users that should perform the steps, sometimes given in terms of roles, and of constraints on execution, such as precedence among steps.

The focus in this paper is on how capable systems are of supporting groups of software engineers in their common objective of developing systems. Two complementary aspects are key in such support: collaboration and coordination. For the purpose of this paper, we define collaboration as relating to user communication and user awareness of each other's actions; coordination is related to mechanisms that are used to avoid the need of such inter-user communication, such as division of labor and automatic distribution of work.

Large development teams are plagued by what Brooks called the ‘Tar-pit’ effect [2]—as team sizes grow linearly, the time spent by team members to align perspectives and to keep aware of the actions of others might grow exponentially. The challenge then is how to devise strategies for dividing the work, for assigning work to different developers and to indirectly coordinate their actions.

PCSDE tackle this problem by allowing complex work processes to be defined beforehand and by supporting actual development as processes unfold. These systems embed knowledge about processes and can serve as a source of information and guidance, thus avoiding some of the communication that would be necessary otherwise. On the other hand, while unnecessary communication should be avoided, one wants developers to be able to be as aware as possible of the work of others that might affect their own. There is a need for strong support for both indirect and direct communication among team members aiming at keeping their perspectives aligned. A support systems should to the extent possible mediate this communication.

Support for collaboration and coordination under this broad perspective includes a wide range of functionality. Important factors include how expressive the descriptions of work are; how effective is the distribution among team members; how flexible is the work execution; how much support is available for handling unavoidable variations, among others. Inflexible or otherwise inappropriate functionality along any of these dimensions can adversely impact the performance of a team, either because of information overload or information deprivation.

Clearly, no system can match the complexities of actual work and are therefore by definition limited (and limiting). Research in process-centered process development acknowledges this fact, even if indirectly, by proposing alternatives that make environments more useful by imposing less restrictions on the way work is performed or by better adapting to particular work styles.

The goal of this paper is therefore to examine available PCSDE literature and identify ranges of functionality along a few key dimensions. The result of this work can be read as a guide for evaluation of process support systems, by comparing offered features with those of a wide range of existing solutions. This paper can also be understood as a roadmap for developers of new PCSDEs.

For the purpose of contrasting solutions, some references to the workflow management literature are made. Workflow management systems (WFMS) are process support systems as well, but target mostly business, rather than development processes as PCSDEs. WFMS has a rich literature on flexibility and support for cooperation [3] that can sometimes shed light on some of the issues we are interested in here.

Related work deals with similar issues, but under a different focus. A survey and taxonomy of PCSDE can be found in Ref. [4]; in depth descriptions of systems' features can be found in Refs. [5], [6], [7] and in the many papers mentioned throughout this paper.

The rest of this paper is organized as follows. We start by presenting background information on the issues surrounding collaboration in the context of software development (Section 2.1). Process Centered Software Development Environments and the nomenclature used in this paper are presented in Section 2.2. We then proceed to present an analysis framework (Section 3) that is employed to classify system functionalities in this paper. The software development literature is then examined in 4 Process descriptions, 5 Latitude of description interpretation, 6 User–environment interaction, 7 Inter-user communication, 8 Management and assessment. The paper ends with summary and conclusions (Section 9). More detailed information on a some of the analyzed systems can be found in Appendix A.

Section snippets

General issues in collaborative software development

In software development, from an initial abstract goal (an end state consciously selected a priori [8]) a series of incremental transformations is performed. These transformations need to be soundness preserving, i.e. at the end, the informational product needs somehow to match the initial goal, in difficult to qualify ways.

The objective is to keep the adherence to the goal in it's many incrementally more detailed incarnations. Each step in the process should expand the concepts of previous

Analysis framework

Technology (including computer technology) is at the same time enabling and restricting. Tools enhance users' capabilities (e.g. to communicate), but are obviously only effective within the limits of the functionality that is made available by the tool. E-mail technology, for instance, is adequate for asynchronous support for written messages—it does not help much in cases where synchronous communication is required or desired.

PCSDEs can be seen as technology that constrains possible action

Process descriptions

Process descriptions ultimately drive process-oriented systems' execution. The coverage that is provided therefore directly impacts system usability. Process models usually cover a variety of aspects, such as control, artifacts, tools and user roles. Different styles of specification result from focus on one of these aspects that is taken to be central. A few interesting specification style alternatives are explored in PCSDEs.

Rule-based specifications are employed by the majority of the

Latitude of description interpretation

An old and powerful insight of the software process community is that the focus in a process should not be on modeling some abstract representation of work, but rather on understanding and supporting the dynamic and contingent way an actual process unfolds in use [5].

Collaborative processes are characterized by the impossibility of completely pre-defining their unfolding due to the high degree of change and potential breakdowns that are known to occur. The main component of collaborative work

User–environment interaction

Two main aspects determine the interaction between process environments and users: the interaction paradigm (what the interaction is centered on) and the user binding strategy. Interaction paradigm refers to the main entity around which interaction revolves, e.g. steps, artifacts, goals or roles. User binding strategy is the one employed to match users to work that has to be performed.

Inter-user communication

In conventional WFMS, collaboration between users is usually restricted to asynchronous sharing of artifacts, usually forms or documents, i.e. artifacts are handled in a serial way, from task to task. In particular, there is usually no support for concurrent access to documents in parallel tasks. Such collaboration through document hand-off is lossy [48]—much of the knowledge is not communicated in this type of transfer. Documents represent just the end result of a potentially complex chain of

Management and assessment

Management control aspects take form of meta-activities, activities whose focus of attention is not the development of software itself, but the way by which software is developed. In other words, their object is the work itself, not the product of the work.

Change seems to be inherent to the development of software, due to the fact that development is also (or primarily) a discovery process. At start little is known about the problem, and as work progresses, the increased understanding may cause

Summary and conclusions

PCSDE features were analyzed in the context of collaboration. PCSDE are by nature geared towards collaboration and coordination, due to their focus on supporting software development, an activity that can be characterized as creative, exploratory collaborative work.

Some features offered by such systems can be useful in the general case:

  • Range of possible enforcement policies, from tracking of user initiated actions to strict, push based enforcement.

  • Rich notion of interaction paradigms that

Acknowledgements

The contribution of the anonymous reviewers is gratefully acknowledged. Their thorough and insightful comments helped to substantially improve the presentation of this paper.

References (85)

  • C. Ghezzi et al.

    Fundamentals of Software Engineering

    (1991)
  • F. Brooks

    The Mythical Man-Month: Essays on Software Engineering

    (1995)
  • V. Ambriola et al.

    Assessing process-centered software engineering environments

    ACM Transactions on Software Engineering and Methodology

    (1997)
  • P. Armenise, S. Bandinelli, C. Ghezzi, A. Morzenti, Software process representation languages: survey and assessment,...
  • Principia Cybernetica Web, Web Dictionary of Cybernetics and Systems, 1998. Available on the web at...
  • J. Bardram, Designing for the dynamics of cooperative work activities, in: Conference on Computer-Supported Cooperative...
  • R. Conradi et al.

    Concepts for evolving software processes

  • L. Osterweil

    Software processes are software too

  • L. Suchman

    Plans and Situated Actions: The Problem of Human–Machine Communication

    (1987)
  • M. Robinson, L. Bannon, Questioning representations, in: Proceedings of the Second European Conference on Computer...
  • N.S. Barghouti

    Supporting cooperation in the marvel process-centered sde

  • C. Montangero et al.

    Oikos: constructing process-centred sdes

  • R. Conradi

    Epos: object-oriented cooperative process modeling

  • G. Junkerman et al.

    Merlin: supporting cooperation in software development through a knowledge-based environment

  • D. Heimbigner

    Proscription versus prescription in process-centered environments

  • S. Bandinelli et al.

    Spade: an environment for software process analysis, design and enactment

  • S. Sutton, D. Heimbigner, L. Osterweil, Language constructs for managing change in process-centered environments, in:...
  • A. Lamarca, W.K. Edwards, P. Dourish, J. Lamping, I. Smith, J. Thornton, Taking the work out of work flow: mechanisms...
  • G. Cugola, C. Ghezzi, Design and implementation of prosyt: a distributed process support system, in: IEEE Eighth...
  • E. Yu, An actor dependency model of organizational work—with application to business process reengineering, in:...
  • L. Briand et al.

    Characterizing and assessing a large-scale software maintenance organization

  • B.G. Cain, J.O. Coplien, A role-based empirical process modeling environment, in: Proceedings of the Second...
  • G. Engels et al.

    Socca: specifications of coordinated and cooperative activities

  • E.M. Gerson et al.

    Analyzing due process in the workplace

    ACM Transactions on Information Systems

    (1986)
  • J. Lonchamp

    An assessment exercise

  • C. Ghezzi

    Introduction and summary of the workshop

  • N.S. Barghouti, B. Krishnamurthy, Provence: a process visualization and enactment environment, in: Proceedings of the...
  • N.S. Barghouti

    Separating process model enactment from process execution in provence

  • G. Cugola

    Tolerating deviations in process support systems via flexible enactment of process models

    IEEE Transactions on Software Engineering: Special Section on Managing Inconsistency in Software Development

    (1998)
  • K. Huff et al.

    A plan-based intelligent assistant that supports the software development process

  • G. Canals et al.

    Alf: a framework for building process-centered software engineering environments

  • G. Kaiser et al.

    A bi-level language for software process modeling

  • H. Saastamoinen, On handling exceptions in information systems, Jyvskyl Studies in Computer Science, Economics and...
  • R. Balzer

    Tolerating inconsistency

  • A. Borgida, T. Murata, Tolerating exceptions in work flows: a unified framework for data and processes, in: Proceedings...
  • K. Narayanaswamy, N. Goldman, ‘Lazy’ consistency: a basis for cooperative software development, in: Proceedings of the...
  • B. Nuseibeh, To be and not to be: on managing inconsistency in software development, in: Proceedings of the Eighth...
  • S. Bandinelli, E. Di Nitto, A. Fuggetta, Supporting cooperation in the spade-1 environment, IEEE Transactions on...
  • S. Bandinelli et al.

    Coupled vs. decoupled user interaction environments in psees

  • Cited by (27)

    • A new research agenda for tool integration

      2007, Journal of Systems and Software
    • Formalizing the evolution of virtual communities

      2007, Information Systems
      Citation Excerpt :

      Specification support to prevent or reduce the impact of such problems is thus necessary. In general, distributed systems development requires process-centred software development environments that support strategies for dividing the work, assigning work to different developers and to indirectly coordinate their actions [16]. However, accomplishing such governance in a user-driven community environment is not trivial.

    View all citing articles on Scopus
    View full text