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

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Designing for the Dynamics of Cooperative Work Activities

paper_content:

CSCW seems to have a persistent problem of understanding the nature of “cooperative work”. This paper argues that this problem is a direct result of not looking at the dynamic aspects of work – i.e. that cooperative work is not one thing, but different things at different times and in different places. Based on Activity Theory the paper gives a conceptual frame for understanding the dynamics of collaborative work activities, and argues that the design of computer support should view cooperative breakdowns not as a problem but as an important resource in design. These arguments are based on empirical studies of healthcare work and the design of a computer support for planning and scheduling operations and other activities within a hospital.
---
paper_title: Questioning Representations

paper_content:

The role of models in the design of computer systems to support interpersonal and cooperative work is examined. It is argued that the current generation of models over-emphasise determinism at the expense of interpretation in the work process. It is further argued that there are many cases in which designs pass between many different professional groups (office workers, managers, analysts, designers, programmers). Each of these groups has its own worldview and specialised language, and hence they are termed "semantic communities". When designs pass between semantic communities, something is lost and something is gained -- but the objects on which each community works are not commensurable. The distinct objects of work (office problems, analyses, designs, programs) do not map onto each other, and cannot be mutually tested using simple true/false criteria. This is termed a problem of "ontological drift", and arises whenever several distinct semantic communities work on the "same" system. It is suggested that the disparity so often observed between design expectations and the ways systems are actually used is therefore quite normal. Current efforts are directed at eliminating the disparity. We suggest that a more fruitful approach might be to accept that the final determination of a system rests with the users. In the long run this might give rise to different types of design principles than those used at the moment. In the short run, even the consciousness of this perspective could make significant differences to design dialogues and attitudes to "users".
---
paper_title: Plans and situated actions: the problem of human-machine communication

paper_content:

Preface Acknowledgements 1. Introduction 2. Interactive artefacts 3. Plans 4. Situated actions 5. Communicative resources 6. Case and methods 7. Human-machine communication 8. Conclusion References Indices.
---
paper_title: Concepts for Evolving Software Processes

paper_content:

Software processes are complex entities that may last for long periods of time and are carried out through the interaction of humans and computerised tools. They need to continuously evolve in order to cope with di erent kinds of changes or customisations both in the organisation and in the technologies used to support software production activities. In recent years, many software process technologies have been developed, and have currently been further extended and used in trial projects. Moreover, some research prototypes have generated commercial products, that are marketed and currently used in industrial organisations. Despite these signi cant e orts and results, however, there is still little conceptual characterisation and assessment of the properties of software processes and related support environments. It is di cult to compare and assess existing approaches. Even a common characterisation of the problems to be addressed seems to be problematic and di cult to achieve. This is particularly true when we consider software process evolution, for which it seems that an agreed-upon and satisfactory solution has not been established yet. Dept. of Computer Systems and Telematics, NTH, N-7034 Trondheim, Norway. Tel.: +47-73-593444, Fax: +47-73-594466, E-Mail: conradi@idt.unit.no. CAP Gemini Innovation, 7 Chemin du Vieux Chene, F-38240 Meylan, France. Tel.: +33-76-764720, Fax: +33-76-764748, E-Mail: christer@capsogeti.fr. Politecnico di Milano, Dipartimento di Elettronica e Informazione, Piazza Leonardo da Vinci 32, I-20133 Milano, Italy. Tel.: +39-2-239.93623, Fax: +39-2-239.93411, E-Mail: Alfonso.Fuggetta@mailer.cefriel.it.
---
paper_title: Characterizing and assessing a large-scale software maintenance organization

paper_content:

One important component of a software process is the organizational context in which the process is enacted. This component is ofien missing or incomplete in current process modeling approaches. One technique for modeling this perspective is the Actor-Dependency (AD) Model. This paper reports on a case study which used this approach to analyze and assess a large software maintenance organization. Our goal was to identify the approach's strengths and weaknesses while providing practical recommendations for improvement and research directions. The AD model was found to be very useful in capturing the important properties of the organizational context of the maintenance process, and aided in the understanding of the flaws found in this process. However, a number of opportunities for extending and improving the AD model were identified. Among others, there is a need to incorporate quantitative information to complement the qualitative model.
---
paper_title: Design and implementation of PROSYT: a distributed process support system

paper_content:

The paper describes the design and implementation of a process support system (PROSYT), which is intended to provide guidance in performing business processes and cooperation among people over a local or geographically distributed network. In particular it can be used as a process-centered software engineering environment (PSEE) to support distributed software development. Our main purpose is to describe how complex applications of this kind can be developed systematically. In particular, how the requirements of high flexibility, reconfigurability, scalability, and efficiency demanded by these applications can be met through appropriate design choices.
---
paper_title: Language constructs for managing change in process-centered environments

paper_content:

Change is pervasive during software development, affecting objects, processes, and environments. In process centered environments, change management can be facilitated by software-process programming, which formalizes the representation of software products and processes using software-process programming languages (SPPLs). To fully realize this goal SPPLs should include constructs that specifically address the problems of change management. These problems include lack of representation of inter-object relationships, weak semantics for inter-object relationships, visibility of implementations, lack of formal representation of software processes, and reliance on programmers to manage change manually. ::: APPL/A is a prototype SPPL that addresses these problems. APPL/A is an extension to Ada.. The principal extensions include abstract, persistent relations with programmable implementations, relation attributes that may be composite and derived, triggers that react to relation operations, optionally-enforceable predicates on relations, and five composite statements with transaction-like capabilities. ::: APPL/A relations and triggers are especially important for the problems raised here. Relations enable inter-object relationships to be represented explicitly and derivation dependencies to be maintained automatically. Relation bodies can be programmed to implement alternative storage and computation strategies without affecting users of relation specifications. Triggers can react to changes in relations, automatically propagating data, invoking tools, and performing other change management tasks. Predicates and the transaction-like statements support change management in the face of evolving standards of consistency. Together, these features mitigate many of the problems that complicate change management in software processes and process-centered environments.
---
paper_title: Taking the work out of workflow: Mechanisms for document-centered collaboration

paper_content:

There are two aspects to technical support for collaborative activity; support for content work and support for coordination. The design of CSCW systems must typically address both of these, combining them in a collaborative application. This approach, however, suffers from a variety of well-known problems, not least the compatibility between collaborative and single-user applications, working styles and practices. In this paper, we describe an alternative approach that makes coordination and collaborative functionality an aspect of the collaborative artifact rather than a collaborative application. We present an infrastructure and a series of application examples to illustrate the idea of document-centered collaboration, in which coordination and collaboration are separated from and independent of applications.
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment

paper_content:

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.
---
paper_title: A role-based empirical process modeling environment

paper_content:

Much contemporary development process research is based on analyses of process steps, their duration, and the events they propagate. Because their initial research in large, mature telecommunications development processes concluded that such models do not capture abstractions that remain stable over time, the authors turned their attention to empirical role-based models. The basic abstraction in the model is a role, a longstanding, stable locus of associated responsibilities in a process. A process model evaluation prototyping environment is used to visualize the process data in several ways, including community-of-interest clustering, communication network clustering, and hierarchical rendering. Analyses of these models have led to insight both into individual projects and into the properties of software development processes in general. >
---
paper_title: Analyzing due process in the workplace

paper_content:

Every office is an open system, and the products of office work are the result of decentralized negotiations. Changing patterns of task organization and alliance inevitably give rise to inconsistent knowledge bases and procedures. This implies that there are no globally correct answers to problems addressed by OIL%. Rather, systems must deal with multiple competing, possibly irreconcilable, solutions. Articulating alternative solutions is the problem of due process. This problem and its consequences are illustrated by a case study of a rate-setting group in a large health insurance firm. There is no formal solution to the problem of due process. But it must be solved in practice if distributed intelligent 01% are to be developed. We propose an alternative approach based on the work of social scientists concerned with analyzing analogous problems in human organization. Solution of the due process problem hinges on developing local closures to the problem faced by an organization. This means analyzing (a) local, tacit knowledge and its transfer ability; (b) articulation work, that is, reconciling incommensurate assumptions and procedures.
---
paper_title: A plan-based intelligent assistant that supports the software development

paper_content:

We describe how an environment can be extended to support the process of software development. Our approach is based on the AI planning paradigm. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators; the sequences of actions in plans are tailored to the context of their use, and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition ; this establishes a context in which programmer-selected goals can be automated via plan generation . We also show how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives, and yet accede to the programmer's superior judgment. This extension to intelligent assistance provides deeper understanding of software processes.
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Tolerating Deviations in Process Support Systems Via Flexible Enactment of Process Models

paper_content:

Process support systems (PSSs) support business organizations in modeling, improving and automating their business processes. Thanks to their ability in enacting process models, they can be used to guide people in performing their daily work and to automate the repetitive tasks that do not require human intervention. Given these potential benefits, it is surprising to observe that PSSs are not widely adopted. This is especially true in case of highly flexible and human-intensive processes, such as design processes in general and software processes in particular. This fact can be explained by observing that currently available PSSs do not fulfil some crucial needs of modern business organizations. One of their major drawbacks is that they do not offer adequate mechanisms to cope with unforeseen situations. They are good at supporting business processes if all proceeds as expected, but if an unexpected situation is met, which would require one to deviate from the process model, they often become more an obstacle than a help. This paper deals with the problem of managing unforeseen situations that require deviations from the process model during enactment in the context of the PROSYT (PROcess Support sYstem capable of Tolerating deviations) PSS. During process model enactment, PROSYT is capable of tolerating deviations from the process model by supporting users even when unexpected situations arise. Furthermore, it supports users in reconciling the process model with the process actually followed, if necessary.
---
paper_title: A bi-level language for software process modeling

paper_content:

The authors present a multi-user implementation of a bi-level process modeling language (PML). Most process modeling formalisms are well-suited to one of two levels of specification, but not both. Some concentrate on global control flow and synchronization. These languages make it easy to define the broad outline of a process, but harder to refine the process by expressing constraints and policies on individual tools and data. Other process formalisms are inherently local. It is easy to define constraints, but far from straightforward to express control flow. Combining global and local formalisms is proposed to produce bi-level formalisms suitable for expressing the enacting large scale processes. The new PML is called the activity structures language. The activity structures language integrates global constrained expressions with local rules. Its implementation on top of the Marvel rule-based environment is described. >
---
paper_title: Taking the work out of workflow: Mechanisms for document-centered collaboration

paper_content:

There are two aspects to technical support for collaborative activity; support for content work and support for coordination. The design of CSCW systems must typically address both of these, combining them in a collaborative application. This approach, however, suffers from a variety of well-known problems, not least the compatibility between collaborative and single-user applications, working styles and practices. In this paper, we describe an alternative approach that makes coordination and collaborative functionality an aspect of the collaborative artifact rather than a collaborative application. We present an infrastructure and a series of application examples to illustrate the idea of document-centered collaboration, in which coordination and collaboration are separated from and independent of applications.
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Provence: A Process Visualization and Enactment Environment

paper_content:

A process-centered software development environment must be open and as non-intrusive as possible. Openness is important because the nature of software process work is experimental, making it difficult to determine the forms of assistance that are needed. An extensible architecture that can incorporate new tools is more appropriate than one that fixes its components and functionality. Providing process support in a non-intrusive manner relieves organizations adopting process technology from having to change their working environment significantly. We present Provence, an architecture that inculcates these criteria and realizes them by integrating existing software components. Supporting cooperation is equally important, but we do not address this issue yet. Provence monitors developers' activities, maps them to process steps, and maintains process and product data. Further, it provides a dynamic visual representation of changes to process and data throughout the lifetime of a project.
---
paper_title: Separating process model enactment from process execution in Provence

paper_content:

The conceptual distinction between the enactment of a software process model and the actual execution (or performance) of a process has been pointed out by Fernstrom (1983). Separating the two domains is essential for process support systems that aim to provide process-centered assistance without changing the project's working environment, by which I mean the set of tools and the file system utilities used by project personnel, the way the project's information is organized, etc. To achieve the separation, process support systems must monitor the actual execution of a project's processes, which takes place outside of the system, and map it to the enactment of the project's process model. Assistance can then be provided based on the process model enactment. In this manner, project personnel continue to use the working environment with which they are familiar and still benefit from the assistance provided by the process support system. Provence is an architecture for modeling, enacting, monitoring and visualizing processes that maintains the separation between process model enactment and process execution. In implementing Provence, we had to resolve three fundamental difficulties: (1) how to map the states in the process model enactment onto the states in the actual process execution, (2) how to synchronize state changes in the two domains, and (3) how to monitor the process execution while maintaining the privacy of data belonging to project personnel. This paper describes how the three difficulties were overcome in Provence. It gives some of the details of the mapping between the enactment world and the execution word, it presents the protocol used to synchronise state transitions in the two worlds, and it describes briefly how the low-level operating system events that comprise the process execution are monitored.
---
paper_title: Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment

paper_content:

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.
---
paper_title: Plans and situated actions: the problem of human-machine communication

paper_content:

Preface Acknowledgements 1. Introduction 2. Interactive artefacts 3. Plans 4. Situated actions 5. Communicative resources 6. Case and methods 7. Human-machine communication 8. Conclusion References Indices.
---
paper_title: To be and not to be: on managing inconsistency in software development

paper_content:

The development of software systems involves the detection and handling of inconsistencies. These inconsistencies arise in system requirements, design specifications and, quite often, in the descriptions that form the final implemented software product. This paper presents a critical review of approaches that explicitly tolerate and manage inconsistencies, and explores different kinds of inconsistencies that arise during different stages of software development. Managing inconsistency refers not only to the detection and removal of inconsistencies, but also to activities that facilitate continued development in their presence. Such activities include procedures for controlled amelioration or avoidance of inconsistency, which in turn may require analysis and reasoning in the presence of inconsistency.
---
paper_title: Tolerating Deviations in Process Support Systems Via Flexible Enactment of Process Models

paper_content:

Process support systems (PSSs) support business organizations in modeling, improving and automating their business processes. Thanks to their ability in enacting process models, they can be used to guide people in performing their daily work and to automate the repetitive tasks that do not require human intervention. Given these potential benefits, it is surprising to observe that PSSs are not widely adopted. This is especially true in case of highly flexible and human-intensive processes, such as design processes in general and software processes in particular. This fact can be explained by observing that currently available PSSs do not fulfil some crucial needs of modern business organizations. One of their major drawbacks is that they do not offer adequate mechanisms to cope with unforeseen situations. They are good at supporting business processes if all proceeds as expected, but if an unexpected situation is met, which would require one to deviate from the process model, they often become more an obstacle than a help. This paper deals with the problem of managing unforeseen situations that require deviations from the process model during enactment in the context of the PROSYT (PROcess Support sYstem capable of Tolerating deviations) PSS. During process model enactment, PROSYT is capable of tolerating deviations from the process model by supporting users even when unexpected situations arise. Furthermore, it supports users in reconciling the process model with the process actually followed, if necessary.
---
paper_title: Tolerating inconsistency

paper_content:

This is a short paper about a simple technique for making applications robust by marking data that violates specially identified invariants and using those marks as guards around code which is sensitive to that invariant. Such a capability is needed when dealing with the exceptions that arise in practical applications and distinguish them from idealized specifications. Previous techniques either required the removal of the constraint so that the exception would be allowed, or its modification to exclude the particular exception from the restriction. Our technique softens the entire constraint without introducing special cases, and is intended primarily for temporary exceptions. Rather than synchronizing all updates required by some constraint, it allows them instead to occur distributed in time in any arbitrary order. Thus, it is particularly useful in multiclient applications with shared responsibilities and authority, such as cooperative design (including software development). While the constraint is violated, the offending data is automatically marked by guards to screen it from, or identify it to, code segments sensitive to the violation. When the time distributed update is complete so that the data is no longer inconsistent, the guards are automatically removed so that the data can again be processed normally. The relevance of this work to the Process Workshop is that it provides a technique for relaxing the synchronization problem among multiple users cooperating on some compound update and allows them instead to operate asynchronously. That is, this technique allows us to write more realistic process programs describing the flexible time-distributed coordinations among agents without loosing the formal constraints on their shared goals. The cost of this flexibility is the conditionalization of the cooperating agents to tolerate these temporary inconsistencies. We have created two implementations of our technique for softening constraints to allow temporary inconsistencies. Both are fully automatic and both handle arbitrary constraints expressed in our first-order logic formalism. The first converts the original constraint into a pair of constraints that require the presence of the guards while the original constraint is violated and their absence otherwise. These new constraints have “repairs” which fix violations by respectively inserting or removing the guards. The second implementation replaces the original constraint by an inference rule which derives the guard if and only if the original constraint predicate was violated. Our contribution lies in formally representing constraints whose temporary inconsistency can be tolerated by an application, and in automatically marking the particular offending data while the constraint is being violated. The goal of minimizing the number and duration of such violations is informal and implicit. The task of identifying sensitive code segments and determining how they should respond to the temporary inconsistencies is likewise informal and manual. Our work has an interesting relationship with the recent work on transactions by Pu, Kaiser, and Hutchinson @cite(Split-Transactions) addressing the times and set of users over which a constraint applies. They, too, are interested in multi-party transactions, and have proposed “splitting” transactions into pieces with differing visibility scopes so that users in some group could see the changes made by the splits within the transaction, while those outside the group wouldn't see any changes until the entire transaction was committed. Split-Transactions can be viewed as another approach to exception handling. Rather than dealing with an exception or an inconsistency after a completed transaction, Pu, Kaiser, and Hutchinson subdivide the transaction so that the multi-party coordinations can occur within it. As in all transactions, constraints are only applied when committed. Thus, during the transaction the effect is to remove the constraints. The power of the Split-Transaction approach is the scoping (potentially multi-level) that it provides to allow groups to cooperatively prepare a compound update for a broader community. However, within the transaction, since the constraints are not in effect, the inconsistency is not explicit, and hence cannot be tracked, managed, or supported except by informal mechanisms outside the system. But there is no reason why Split Transactions couldn't be combined with our own techniques for tolerating inconsistency to provide the advantages of both. While the inconsistency existed, it would be guarded by Pollution Markers, but it would only be visible to the group (dynamically formed) needed to resolve that inconsistency. After it was resolved, the Pollution Markers would be removed, and the new consistent state would be visible outside the group.
---
paper_title: Tolerating exceptions in workflows: a unified framework for data and processes

paper_content:

Practical workflow systems need to be able to tolerate deviations from the initial process model because of un-anticipated situations. They should also be able to accommodate deviations in the format of the forms and data being manipulated. We offer a framework for treating both kinds of deviations uniformly, by applying ideas from programming languages (with workflow agents as potential on-line exception handlers) to workflows that have been reified as objects in classes with special attributes. As a result, only a small number of new constructs, which can be applied orthogonally, need to be introduced. Special run-time checks are used to deal with the consequences of permitting deviations from the norm to persist as violations of constraints.
---
paper_title: Supporting Cooperation in the SPADE-1 Environment

paper_content:

Software development is a cooperative activity that relies heavily on the quality and effectiveness of the communication channels established within the development team and with the end-user. Process-centered software engineering environments (PSEEs) support the definition and the execution of various phases of the software process. This is achieved by explicitly defining cooperation procedures, and by supporting synchronization and data sharing among its users. PSEE and CSCW technologies have been developed rather independently from each other, leading to a large amount of research results, tools and environments, and practical experiences. We have reached a stage in technology development where it is necessary to assess and evaluate the effectiveness of the research efforts carried out so far. Moreover, it is important to understand how to integrate and exploit the results of these different efforts. The goal of the paper is to understand which kind of basic functionalities PSEEs can and should offer, and how these environments can be integrated with other tools to effectively support cooperation in software development. In particular, the paper introduces a process model we have built to support a cooperative activity related to anomaly management in an industrial software factory. The core of the paper presents and discusses the experiences and results that we have derived from this modeling activity, and how they related to the general problem of supporting cooperation in software development. The project was carried out using the SPADE (Software Process Analysis, Design and Enactment) PSEE and the ImagineDesk CSCW toolkit.
---
paper_title: A plan-based intelligent assistant that supports the software development

paper_content:

We describe how an environment can be extended to support the process of software development. Our approach is based on the AI planning paradigm. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators; the sequences of actions in plans are tailored to the context of their use, and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition ; this establishes a context in which programmer-selected goals can be automated via plan generation . We also show how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives, and yet accede to the programmer's superior judgment. This extension to intelligent assistance provides deeper understanding of software processes.
---
paper_title: Tolerating Deviations in Process Support Systems Via Flexible Enactment of Process Models

paper_content:

Process support systems (PSSs) support business organizations in modeling, improving and automating their business processes. Thanks to their ability in enacting process models, they can be used to guide people in performing their daily work and to automate the repetitive tasks that do not require human intervention. Given these potential benefits, it is surprising to observe that PSSs are not widely adopted. This is especially true in case of highly flexible and human-intensive processes, such as design processes in general and software processes in particular. This fact can be explained by observing that currently available PSSs do not fulfil some crucial needs of modern business organizations. One of their major drawbacks is that they do not offer adequate mechanisms to cope with unforeseen situations. They are good at supporting business processes if all proceeds as expected, but if an unexpected situation is met, which would require one to deviate from the process model, they often become more an obstacle than a help. This paper deals with the problem of managing unforeseen situations that require deviations from the process model during enactment in the context of the PROSYT (PROcess Support sYstem capable of Tolerating deviations) PSS. During process model enactment, PROSYT is capable of tolerating deviations from the process model by supporting users even when unexpected situations arise. Furthermore, it supports users in reconciling the process model with the process actually followed, if necessary.
---
paper_title: Taking the work out of workflow: Mechanisms for document-centered collaboration

paper_content:

There are two aspects to technical support for collaborative activity; support for content work and support for coordination. The design of CSCW systems must typically address both of these, combining them in a collaborative application. This approach, however, suffers from a variety of well-known problems, not least the compatibility between collaborative and single-user applications, working styles and practices. In this paper, we describe an alternative approach that makes coordination and collaborative functionality an aspect of the collaborative artifact rather than a collaborative application. We present an infrastructure and a series of application examples to illustrate the idea of document-centered collaboration, in which coordination and collaboration are separated from and independent of applications.
---
paper_title: A paradigm for decentralized process modeling and its realization in the OZ environment

paper_content:

We present a model for decentralized Process Centered Environments (PCEs), which support concerted efforts among geographically-dispersed teams - each local team with its own autonomous process - and emphasize flexibility in the tradeoff between collaboration vs. autonomy. We consider both decentralized process modeling and decentralized process enaction. We describe a realization in the OZ decentralized PCE, which employs a rule-based formalism, and also investigate the application to PCEs based on Petri-nets. >
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Software process modeling and execution within virtual environments

paper_content:

In the past, multiuser virtual environments have been developed as venues for entertainment and social interaction. Recent research focuses instead on their utility in carrying out work in the real world. This research has identified the importance of a mapping between the real and the virtual that permits the representation of real tasks in the virtual environment. We investigate the use of virtual environments—in particular, MUDs (Multi-User Dimensions)—in the domain of software process. In so doing, we define a mapping, or metaphor , that permits the representation of software processes within a MUD. The system resulting from this mapping, called Promo , permits the modeling and execution of software processes by geographically dispersed agents.
---
paper_title: Coupled vs decoupled user interaction environments in PSEEs

paper_content:

We discuss the relationship between the process modeling language (PML) paradigm and user interaction paradigm in a PSEE. On one side, the user interaction paradigm may strongly depend on the PML and its supporting environment. On the other side, it is related to the social context and the specific process in which it is used. A user interaction environment decoupled from the PML may be tailored to the specific user needs, without impacting on the PML concepts and on the PSEE architecture, On the other hand, a user interaction environment coupled with the PML does not require specific modeling work by the process modeler but binds the interaction paradigm to the process language paradigm. We characterize these two extreme alternatives and provide pros and cons for each of them.
---
paper_title: Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment

paper_content:

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.
---
paper_title: Supporting Cooperation in the SPADE-1 Environment

paper_content:

Software development is a cooperative activity that relies heavily on the quality and effectiveness of the communication channels established within the development team and with the end-user. Process-centered software engineering environments (PSEEs) support the definition and the execution of various phases of the software process. This is achieved by explicitly defining cooperation procedures, and by supporting synchronization and data sharing among its users. PSEE and CSCW technologies have been developed rather independently from each other, leading to a large amount of research results, tools and environments, and practical experiences. We have reached a stage in technology development where it is necessary to assess and evaluate the effectiveness of the research efforts carried out so far. Moreover, it is important to understand how to integrate and exploit the results of these different efforts. The goal of the paper is to understand which kind of basic functionalities PSEEs can and should offer, and how these environments can be integrated with other tools to effectively support cooperation in software development. In particular, the paper introduces a process model we have built to support a cooperative activity related to anomaly management in an industrial software factory. The core of the paper presents and discusses the experiences and results that we have derived from this modeling activity, and how they related to the general problem of supporting cooperation in software development. The project was carried out using the SPADE (Software Process Analysis, Design and Enactment) PSEE and the ImagineDesk CSCW toolkit.
---
paper_title: Integrating groupware activities into workflow management systems

paper_content:

Computer supported cooperative work (CSCW) has been recognized as a crucial enabling technology for multi-user computer-based systems, particularly in cases where synchronous human-human interaction is required between geographically dispersed users. Workflow is an emerging technology that supports complex business processes in modern corporations by allowing to explicitly define the process, and by supporting its execution in a workflow management system (WFMS). Since workflow inherently involves humans carrying out parts of the process, it is only natural to explore how to synergize these two technologies. The authors analyze the relationships between groupware and workflow management, present their general approach to integrating synchronous groupware tools into a WFMS, and conclude with an example process that was implemented in the Oz WFMS and integrated such tools. Their main contribution lies in the integration and synchronization of individual groupware activities into modelled workflow processes, as opposed to being a built-in part of the workflow WFMS.
---
paper_title: Communication support in a process-centered software engineering environment

paper_content:

The position paper distinguishes different types of activities needed in software processes and proposes enaction support for them. An architecture of enaction exponents providing this support is sketched.
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Separating process model enactment from process execution in Provence

paper_content:

The conceptual distinction between the enactment of a software process model and the actual execution (or performance) of a process has been pointed out by Fernstrom (1983). Separating the two domains is essential for process support systems that aim to provide process-centered assistance without changing the project's working environment, by which I mean the set of tools and the file system utilities used by project personnel, the way the project's information is organized, etc. To achieve the separation, process support systems must monitor the actual execution of a project's processes, which takes place outside of the system, and map it to the enactment of the project's process model. Assistance can then be provided based on the process model enactment. In this manner, project personnel continue to use the working environment with which they are familiar and still benefit from the assistance provided by the process support system. Provence is an architecture for modeling, enacting, monitoring and visualizing processes that maintains the separation between process model enactment and process execution. In implementing Provence, we had to resolve three fundamental difficulties: (1) how to map the states in the process model enactment onto the states in the actual process execution, (2) how to synchronize state changes in the two domains, and (3) how to monitor the process execution while maintaining the privacy of data belonging to project personnel. This paper describes how the three difficulties were overcome in Provence. It gives some of the details of the mapping between the enactment world and the execution word, it presents the protocol used to synchronise state transitions in the two worlds, and it describes briefly how the low-level operating system events that comprise the process execution are monitored.
---
paper_title: Collaboration and composition: issues for a second generation process language

paper_content:

Over the past decade a variety of process languages have been defined and applied to software engineering environments. The idea of using a process language to encode a software process as a “process model”, and enacting this using a process-sensitive environment is now well established. Many prototype process-sensitive environments have been developed; but their use in earnest has been limited. We are designing a second generation process language which is a significant departure from current conventional thinking. Firstly a process is viewed as a set of mediated collaborations rather than a set of partially ordered activities. Secondly emphasis is given to how process models are developed, used, and enhanced over a potentially long lifetime. In particular the issue of composing both new and existing model fragments is central to our development approach. This paper outlines these features, and gives the motivations behind them. It also presents a view of process support for software engineering drawing on our decade of experience in exploiting a “first generation” process language, and our experience in designing and exploiting programming languages.
---
paper_title: Concurrency control in advanced database applications

paper_content:

Concurrency control has been thoroughly studied in the context of traditional database applications such as banking and airline reservations systems. There are relatively few studies, however, that address the concurrency control issues of advanced database applications such as CAD/CAM and software development environments. The concurrency control requirements in such applications are different from those in conventional database applications; in particular, there is a need to support non-serializable cooperation among users whose transactions are long-lived and interactive, and to integrate concurrency control mechanisms with version and configuration control. This paper outlines the characteristics of data and operations in some advanced database applications, discusses their concurrency control requirements, and surveys the mechanisms proposed to address these requirements.
---
paper_title: Integrating groupware and process technologies in the Oz environment

paper_content:

Human-to-human collaboration is critical in any multi-user, multi-organization development process. The CSCW community has already produced extensive work on modeling and supporting collaboration between members of a (possibly geographically dispersed) team. Now that high-speed networks and a sophisticated communication infrastructure (the Internet) have made CSCW technologies more feasible, we are studying how process technologies can embrace them. This position paper focuses on process support for interactions of multiple human users. This is in contrast to work on development of multi-user/CSCW tools and supporting generic human-computer interaction. Finding the appropriate balance between intergroup collaboration and autonomy is beyond the scope of this paper. The in-progress work described here is being implemented in the Oz decentralized Process Centered Environment (PCE).
---
paper_title: Taking the work out of workflow: Mechanisms for document-centered collaboration

paper_content:

There are two aspects to technical support for collaborative activity; support for content work and support for coordination. The design of CSCW systems must typically address both of these, combining them in a collaborative application. This approach, however, suffers from a variety of well-known problems, not least the compatibility between collaborative and single-user applications, working styles and practices. In this paper, we describe an alternative approach that makes coordination and collaborative functionality an aspect of the collaborative artifact rather than a collaborative application. We present an infrastructure and a series of application examples to illustrate the idea of document-centered collaboration, in which coordination and collaboration are separated from and independent of applications.
---
paper_title: Supporting Cooperation in the SPADE-1 Environment

paper_content:

Software development is a cooperative activity that relies heavily on the quality and effectiveness of the communication channels established within the development team and with the end-user. Process-centered software engineering environments (PSEEs) support the definition and the execution of various phases of the software process. This is achieved by explicitly defining cooperation procedures, and by supporting synchronization and data sharing among its users. PSEE and CSCW technologies have been developed rather independently from each other, leading to a large amount of research results, tools and environments, and practical experiences. We have reached a stage in technology development where it is necessary to assess and evaluate the effectiveness of the research efforts carried out so far. Moreover, it is important to understand how to integrate and exploit the results of these different efforts. The goal of the paper is to understand which kind of basic functionalities PSEEs can and should offer, and how these environments can be integrated with other tools to effectively support cooperation in software development. In particular, the paper introduces a process model we have built to support a cooperative activity related to anomaly management in an industrial software factory. The core of the paper presents and discusses the experiences and results that we have derived from this modeling activity, and how they related to the general problem of supporting cooperation in software development. The project was carried out using the SPADE (Software Process Analysis, Design and Enactment) PSEE and the ImagineDesk CSCW toolkit.
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Integrating groupware and process technologies in the Oz environment

paper_content:

Human-to-human collaboration is critical in any multi-user, multi-organization development process. The CSCW community has already produced extensive work on modeling and supporting collaboration between members of a (possibly geographically dispersed) team. Now that high-speed networks and a sophisticated communication infrastructure (the Internet) have made CSCW technologies more feasible, we are studying how process technologies can embrace them. This position paper focuses on process support for interactions of multiple human users. This is in contrast to work on development of multi-user/CSCW tools and supporting generic human-computer interaction. Finding the appropriate balance between intergroup collaboration and autonomy is beyond the scope of this paper. The in-progress work described here is being implemented in the Oz decentralized Process Centered Environment (PCE).
---
paper_title: Supporting collaborative software development with ConversationBuilder

paper_content:

In this paper we discuss the architecture of the Conversation Builder, an environment for collaborative work, and show how our framework provides a powerful basis for support of collaborative software development activities.
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment

paper_content:

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.
---
paper_title: Integrating groupware and process technologies in the Oz environment

paper_content:

Human-to-human collaboration is critical in any multi-user, multi-organization development process. The CSCW community has already produced extensive work on modeling and supporting collaboration between members of a (possibly geographically dispersed) team. Now that high-speed networks and a sophisticated communication infrastructure (the Internet) have made CSCW technologies more feasible, we are studying how process technologies can embrace them. This position paper focuses on process support for interactions of multiple human users. This is in contrast to work on development of multi-user/CSCW tools and supporting generic human-computer interaction. Finding the appropriate balance between intergroup collaboration and autonomy is beyond the scope of this paper. The in-progress work described here is being implemented in the Oz decentralized Process Centered Environment (PCE).
---
paper_title: Serendipity: Integrated Environment Support for Process Modelling, Enactment and Work Coordination

paper_content:

Large cooperative work systems require work coordination, context awareness and process modelling and enactment mechanisms to be effective. Support for process modelling and work coordination in such systems also needs to support informal aspects of work which are difficult to codify. Computer-Supported Cooperative Work (CSCW) facilities, such as inter-person communication and collaborative editing, also need to be well-integrated into both process-modelling tools and tools used to perform work. Serendipity is an environment which provides high-level, visual process modelling and event-handling languages, and diverse CSCW capabilities, and which can be integrated with a range of tools to coordinate cooperative work. This paper describes Serendipity‘s visual languages, support environment, architecture, and implementation, together with experience using the environment and integrating it with other environments.
---
paper_title: Software process modeling and execution within virtual environments

paper_content:

In the past, multiuser virtual environments have been developed as venues for entertainment and social interaction. Recent research focuses instead on their utility in carrying out work in the real world. This research has identified the importance of a mapping between the real and the virtual that permits the representation of real tasks in the virtual environment. We investigate the use of virtual environments—in particular, MUDs (Multi-User Dimensions)—in the domain of software process. In so doing, we define a mapping, or metaphor , that permits the representation of software processes within a MUD. The system resulting from this mapping, called Promo , permits the modeling and execution of software processes by geographically dispersed agents.
---
paper_title: Process, space, & software development suppport.

paper_content:

Over the past five years we have been actively investigating support frameworks for collaborative sofhvare development . Our goal has been the development of an open framework for support of collaborative work activities which provides active guidance and help to the user and allows for dynamic modification of collaboration protocols as work situations evolve. In this position paper we outline our current thinking on support fiameworks for the collaborative efforts of teams of sofiare developers. We postulate that a space-based metaphor for collaborative systems opens the door to the design and construction of families of next-generation sofiare process environments which are open in that many different kinds of processes can be speci$ed, significantly more flexible than existing systems in their affordances for evolution of process models, and provide integrated support for both formal and informal collaborative activities o f their users.
---
paper_title: Provence: A Process Visualization and Enactment Environment

paper_content:

A process-centered software development environment must be open and as non-intrusive as possible. Openness is important because the nature of software process work is experimental, making it difficult to determine the forms of assistance that are needed. An extensible architecture that can incorporate new tools is more appropriate than one that fixes its components and functionality. Providing process support in a non-intrusive manner relieves organizations adopting process technology from having to change their working environment significantly. We present Provence, an architecture that inculcates these criteria and realizes them by integrating existing software components. Supporting cooperation is equally important, but we do not address this issue yet. Provence monitors developers' activities, maps them to process steps, and maintains process and product data. Further, it provides a dynamic visual representation of changes to process and data throughout the lifetime of a project.
---
paper_title: Capability maturity model, version 1.1

paper_content:

The capability maturity model (CMM), developed to present sets of recommended practices in a number of key process areas that have been shown to enhance software-development and maintenance capability, is discussed. The CMM was designed to help developers select process-improvement strategies by determining their current process maturity and identifying the issues most critical to improving their software quality and process. The initial release of the CMM, version 1.0, was reviewed and used by the software community during 1991 and 1992. A workshop on CMM 1.0, held in April 1992, was attended by about 200 software professionals. The current version of the CMM is the result of the feedback from that workshop and ongoing feedback from the software community. The technical report that describes version 1.1. is summarised. >
---
paper_title: Flexible and customizable workflow execution on the www

paper_content:

Because of the common concerns between various disciplines, trends are moving towards overlap and convergence of requirements. However, these communities have yet to identify the union of cross-discipline requirements for a supporting technical infrastructure addressing the level of flexibility and customization required in these real-world settings. This thesis identifies a shared set of core requirements between the process, workflow, and groupware disciplines, examines the current approaches to communication and coordination requirements in the face of ubiquitous network support, and provides contributions in each of the converging fields. ::: In particular, this thesis demonstrates techniques which enable a workflow process infrastructure to better address the distribution of workflow processes and people, bi-directional integration with external tools, customization and reuse of workflow objects and their presentations, dynamic change in the routing of artifacts and control of activities, and support for multiple stakeholders with varying degrees of technical skill. This is accomplished by augmenting the strengths of the World Wide Web with control and coordination infrastructure using a new set of implementation technologies and approaches. These approaches include maintaining several layered object models encompassing interchangeable workflow services at different levels of abstraction, implementing the support architecture as a set of highly componentized, lightweight, concurrent elements, supporting event-based communication between layers and objects including user interface components, allowing customizable distribution policies including design and dissemination of workflow components using standard Internet and WWW protocols, and providing access to internal workflow objects through open application programmer interfaces (APIs) and extensions to the common WWW mechanisms using multiple programming languages. ::: Most importantly, this thesis demonstrates that a workflow infrastructure can concurrently support the requirements of distribution, integration, customization and reuse, dynamic change, and multiple stakeholders on the WWW using the implementation technologies and approaches described above. The benefits of doing so ensure remote project members work together toward common goals by understanding the context of their work assignments, have access to project status information, and coordinate the use of artifacts and tools. Projects undertaken over the WWW can evaluate status and track progress by allowing remote access and changes to the specification of activities and their dependencies, comparison of actual to planned progress, and correction of deviations. ::: The claims made in this thesis are validated by examining the characteristics of domain specific workflow solutions built on top of a customizable and flexible workflow infrastructure research prototype in order to understand the limits of and populate the design space. This dissertation concludes by positioning this work within the context of further shared requirements across the process, groupware, and workflow fields. (Abstract shortened by UMI.)
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: The need for a cooperative model: the Adele/Tempo experience

paper_content:

Our position is that the software process is fundamentally cooperative. We have been developing concepts and mechanism to tackle with cooperation in the Adele/Tempo project. Firstly, we integrated into the Tempo software process formalism a new concept: cooperation classes. In addition, we provided temporal, event-condition-action (TECA) rules in order to monitor and control cooperative activities. Based on TECA rules and cooperation classes, we can describe exchange information policies between software developers as well as rules about the organization, evolution and consistency of software projects. Secondly, we have been developing a transaction management system which is able to support the Tempo cooperative model. This system has been built up to deal with un-predicted events provoked by activities carried out in cooperative work environments.
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Language constructs for managing change in process-centered environments

paper_content:

Change is pervasive during software development, affecting objects, processes, and environments. In process centered environments, change management can be facilitated by software-process programming, which formalizes the representation of software products and processes using software-process programming languages (SPPLs). To fully realize this goal SPPLs should include constructs that specifically address the problems of change management. These problems include lack of representation of inter-object relationships, weak semantics for inter-object relationships, visibility of implementations, lack of formal representation of software processes, and reliance on programmers to manage change manually. ::: APPL/A is a prototype SPPL that addresses these problems. APPL/A is an extension to Ada.. The principal extensions include abstract, persistent relations with programmable implementations, relation attributes that may be composite and derived, triggers that react to relation operations, optionally-enforceable predicates on relations, and five composite statements with transaction-like capabilities. ::: APPL/A relations and triggers are especially important for the problems raised here. Relations enable inter-object relationships to be represented explicitly and derivation dependencies to be maintained automatically. Relation bodies can be programmed to implement alternative storage and computation strategies without affecting users of relation specifications. Triggers can react to changes in relations, automatically propagating data, invoking tools, and performing other change management tasks. Predicates and the transaction-like statements support change management in the face of evolving standards of consistency. Together, these features mitigate many of the problems that complicate change management in software processes and process-centered environments.
---
paper_title: Issues encountered in building a flexible software development environment: lessons from the Arcadia project

paper_content:

This paper presents some of the more significant technical lessons that the Arcadia project has learned about developing effective software development environments. The principal components of the Arcadia-1 architecture are capabilities for process definition and execution, object management, user interface development and management, measurement and evaluation, language processing, and analysis and testing. In simultaneously and cooperatively developing solutions in these areas we learned several key lessons. Among them: the need to combine and apply heterogenous componentry, multiple techniques for developing components, the pervasive need for rich type models, the need for supporting dynamism (and at what granularity), the role and value of concurrency, and the role and various forms of event-based control integration mechanisms. These lessons are explored in the paper.
---
paper_title: Automatic Replanning of Task Networks for Process Model Evolution in EPOS

paper_content:

Evolution is crucial in Software Process Modeling (PM) and its support systems. EPOS is a PM support system, using the same Configuration Management (CM) techniques for the Process Schema (types and meta-types) as for instances of these (tasks with related products and tools etc.).
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Workspace Management: Supporting Cooperative Work

paper_content:

This paper introducesa mechanism coping with cooperative work in developing and maintaningsoftware artifacts in a multi-user engineeringenvironment. For the long time it has been a problemto handleparallel activities on shared or interdependent products. The required mechanism must be sufficientlyfle xible to support concurrent updatesso that none of new updates will be lost, nor lots of work will be rejected and restarted. This problem may be resolved by providing a sophisticated way for cooperating between consistent set of objects (workspaces). This mechanism has been prototyped in the EPOS . EPOS offers integrated software configuration management (CM) and process management. The EPOS process modelling (PM) support system runs on top of the versioned EPOS database (EPOSDB), operating in client-server mode.
---
paper_title: Techniques for Process Model Evolution in EPOS

paper_content:

The authors categorize some aspects of software process evolution and customization, and describe how they are handled in the EPOS PM system. Comparisons are made to other PM systems. A process model in EPOS consists of a schema of classes and meta-classes, and its model entities and relationships. There is an underlying software engineering database, EPOSDB, offering uniform versioning of all model parts and a context of nested cooperating transactions. Then, there is a reflective object-oriented process specification language, on top of the EPOSDB. Policies for model creation, composition, change, instantiation, refinement, and enaction are explicitly represented and are used by a set of PM automatic tools. The main tools are a planner to instantiate tasks, an execution manager to enact such tasks, and a PM manager to define, analyze, customize, and evolve the process schema. >
---
paper_title: Total Software Process Model Evolution in EPOS

paper_content:

This paper presents a categorization framework for and its p otential benefits in managing evolution in software projects. Based on observed evolutions in an ongoing case study, we elaborate methods and techniques to evolve corresponding process models in our Process-centered Software Engineering Environment (PSEE), called EPOS. The method includes four major steps: planning/instantiation; execution/tracking; packaging/assessment; and evolving/lear ning. In addition, guidelines for learning and reusing previous evolution patterns in improving planing process a nd estimation accuracy for future projects are also described. Finally, the techniques and associated too l supports are thereafter implemented in EPOS.
---
paper_title: A Framework for Immigrating Existing Software into New Software Development Environments

paper_content:

We have investigated the problem of immigrating software artifacts from one software development environment (SDE) to another, for the purpose of upgrading to new SDEs as technology improves, while continuing development or maintenance of existing software systems. We taxonomise the larger problem of data migration, to establish the scope of immigration. We classify SDEs in terms of the ease of immigrating software artifacts from the data repository of the source SDE, without knowledge of its internal representation. A framework is presented for constructing automatic immigration tools as utilities provided by destination SDEs. We describe a specific immigration tool, called Marvelizer, that we have implemented as part of the Marvel SDE and discuss our experience using the tool.
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Supporting cooperation in the Marvel process-centered SDE

paper_content:

Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference, which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
---
paper_title: Rule chaining in Marvel: dynamic binding of parameters

paper_content:

Marvel is a software development environment that uses a rule-based model of the development process. When a user issues a command, Marvel invokes the corresponding rule and binds the rule's formal parameter to the object selected by the user. If firing the rule changes the object in a way that satisfies the conditions of other rules, Marvel automatically fires each of these rules and tries to bind their formal parameters to objects. Marvel must infer which objects to bind to the formal parameters of the rules in the chain. A problem arises when the classes of the objects manipulated by the rules are different, because Marvel has to determine which object to bind to the parameter of each rule in the chain. Recursive data definitions cause chaining between rules that act on different objects in the same class. Methods developed to address this chaining problem are discussed. >
---
paper_title: Supporting collaborative software development with ConversationBuilder

paper_content:

In this paper we discuss the architecture of the Conversation Builder, an environment for collaborative work, and show how our framework provides a powerful basis for support of collaborative software development activities.
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Concepts and implementation of a rule-based process engine

paper_content:

The key topic is the way how the Merlin process-centered environment provides execution of rule-based persistent software processes. Any software process in Merlin is de- scribed by rules which are executed either in a forward chaining or backward chaining mode and which are made persistent by storing them in an object-oriented data base After a brief introduction to the general Merlin concepts the paper focuses on the representation of rules in the un- derlying data base and their corresponding flexible and ef- ficient execution.
---
paper_title: Software processes representation languages: survey and assessment

paper_content:

Process modeling is an active research area. During the last few years, new languages and methods have been proposed to describe software processes. In this paper, the authors clarify the issues involved in software process modeling and identify the main approaches. They also review the main existing approaches and propose a classification scheme. >
---
paper_title: Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment

paper_content:

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Software process enactment in Oikos

paper_content:

Despite much research work in progress to model the different facets of software process enactment from different approaches, there are no models yet generally recognized as adequate, and there is need for more experimentation. We describe the Oikos environment and its coordination language ESP: they provide an infrastructure in which experiments may be performed and evaluated. ::: Oikos predefines a number of services offering basic facilities, like access to data bases, workspaces, user interfaces etc.. Services are customizable, in a declarative way that matches naturally the way ESP defines and controls the software process. ESP allows to define services, to structure them in a dynamic hierarchy, and to coordinate them according to the blackboard paradigm. The concepts of environment and of software process and their interplay are naturally characterized in Oikos, in terms of sets of services and of the hierarchy. ::: In the paper, an example taken from a real project (the specification of a small language and the implementation of its compiler) shows how Oikos and ESP are effective for software process enactment. ::: As it is, ESP embeds Prolog as its sequential component, and combines it smoothly to the blackboard approach to deal with concurrency and distribution. Anyway, most of the concepts used to model and enact software processes are largely independent of logic programming.
---
paper_title: Integrating groupware and process technologies in the Oz environment

paper_content:

Human-to-human collaboration is critical in any multi-user, multi-organization development process. The CSCW community has already produced extensive work on modeling and supporting collaboration between members of a (possibly geographically dispersed) team. Now that high-speed networks and a sophisticated communication infrastructure (the Internet) have made CSCW technologies more feasible, we are studying how process technologies can embrace them. This position paper focuses on process support for interactions of multiple human users. This is in contrast to work on development of multi-user/CSCW tools and supporting generic human-computer interaction. Finding the appropriate balance between intergroup collaboration and autonomy is beyond the scope of this paper. The in-progress work described here is being implemented in the Oz decentralized Process Centered Environment (PCE).
---
paper_title: Integrating groupware activities into workflow management systems

paper_content:

Computer supported cooperative work (CSCW) has been recognized as a crucial enabling technology for multi-user computer-based systems, particularly in cases where synchronous human-human interaction is required between geographically dispersed users. Workflow is an emerging technology that supports complex business processes in modern corporations by allowing to explicitly define the process, and by supporting its execution in a workflow management system (WFMS). Since workflow inherently involves humans carrying out parts of the process, it is only natural to explore how to synergize these two technologies. The authors analyze the relationships between groupware and workflow management, present their general approach to integrating synchronous groupware tools into a WFMS, and conclude with an example process that was implemented in the Oz WFMS and integrated such tools. Their main contribution lies in the integration and synchronization of individual groupware activities into modelled workflow processes, as opposed to being a built-in part of the workflow WFMS.
---
paper_title: A paradigm for decentralized process modeling and its realization in the OZ environment

paper_content:

We present a model for decentralized Process Centered Environments (PCEs), which support concerted efforts among geographically-dispersed teams - each local team with its own autonomous process - and emphasize flexibility in the tradeoff between collaboration vs. autonomy. We consider both decentralized process modeling and decentralized process enaction. We describe a realization in the OZ decentralized PCE, which employs a rule-based formalism, and also investigate the application to PCEs based on Petri-nets. >
---
paper_title: The ProcessWall: a process state server approach to process programming

paper_content:

The ProcessWall is a process state server providing storage for process states plus operations for defining and manipulating the structure of those states. It separates the state of a software process from any program for constructing that state. Instead, client programs implement the processes for operating on the process state. This approach has a number of potential benefits such as support for process formalism interoperability, support for multiple process languages, low-cost retro-fitting of process into existing environments, and support for long-term execution of processes. The process server interface provides descriptive mechanisms for representing process state as well as product state. A classification of client programs is provided to show how the state server can be used in a variety of ways.
---
paper_title: Design and implementation of PROSYT: a distributed process support system

paper_content:

The paper describes the design and implementation of a process support system (PROSYT), which is intended to provide guidance in performing business processes and cooperation among people over a local or geographically distributed network. In particular it can be used as a process-centered software engineering environment (PSEE) to support distributed software development. Our main purpose is to describe how complex applications of this kind can be developed systematically. In particular, how the requirements of high flexibility, reconfigurability, scalability, and efficiency demanded by these applications can be met through appropriate design choices.
---
paper_title: Tolerating Deviations in Process Support Systems Via Flexible Enactment of Process Models

paper_content:

Process support systems (PSSs) support business organizations in modeling, improving and automating their business processes. Thanks to their ability in enacting process models, they can be used to guide people in performing their daily work and to automate the repetitive tasks that do not require human intervention. Given these potential benefits, it is surprising to observe that PSSs are not widely adopted. This is especially true in case of highly flexible and human-intensive processes, such as design processes in general and software processes in particular. This fact can be explained by observing that currently available PSSs do not fulfil some crucial needs of modern business organizations. One of their major drawbacks is that they do not offer adequate mechanisms to cope with unforeseen situations. They are good at supporting business processes if all proceeds as expected, but if an unexpected situation is met, which would require one to deviate from the process model, they often become more an obstacle than a help. This paper deals with the problem of managing unforeseen situations that require deviations from the process model during enactment in the context of the PROSYT (PROcess Support sYstem capable of Tolerating deviations) PSS. During process model enactment, PROSYT is capable of tolerating deviations from the process model by supporting users even when unexpected situations arise. Furthermore, it supports users in reconciling the process model with the process actually followed, if necessary.
---
paper_title: How to deal with deviations during process model enactment

paper_content:

A fundamental problem in software processes is how the intrinsic rigidity of a predefined (formal) model can be reconciled with the need for flexibility, change, and evolution. We therefore distinguish between software processes, as specified in a process description, and their actual performance by humans. Further, we claim that the two inevitably diverge, and thus it is necessary to provide means to reconcile them. We present a preliminary exploration into the problem. In particular, we illustrate how a temporal logic-based approach can be used to capture and tolerate some deviations from the process description during execution. We present a simple process language (LATIN), and its prototype environment (SENTINEL), in which these ideas are currently experimented.
---
paper_title: Process support in practice: A case study

paper_content:

Deals with the deployment of the PROCESS WEAVER tool to support the processes of the daily work in our company, Cap Gemini Innovation. The first part of this paper describes the main concepts and functionalities of PROCESS WEAVER, followed by a description of how process support has been gradually introduced in the company. The examples described are chosen to illustrate how the use of process modelling and support functions can be gradually introduced into an organization like ours. The described process support introduction program described is phased, with future effort directed towards supporting distributed work processes-especially important since Cap Gemini Innovation, the research branch of the Cap Gemini Sogeti Group, consists of three research centres, two in France (Grenoble and Paris) and one in the Netherlands (Rijswijk). >
---
paper_title: Provence: A Process Visualization and Enactment Environment

paper_content:

A process-centered software development environment must be open and as non-intrusive as possible. Openness is important because the nature of software process work is experimental, making it difficult to determine the forms of assistance that are needed. An extensible architecture that can incorporate new tools is more appropriate than one that fixes its components and functionality. Providing process support in a non-intrusive manner relieves organizations adopting process technology from having to change their working environment significantly. We present Provence, an architecture that inculcates these criteria and realizes them by integrating existing software components. Supporting cooperation is equally important, but we do not address this issue yet. Provence monitors developers' activities, maps them to process steps, and maintains process and product data. Further, it provides a dynamic visual representation of changes to process and data throughout the lifetime of a project.
---
paper_title: Taking the work out of workflow: Mechanisms for document-centered collaboration

paper_content:

There are two aspects to technical support for collaborative activity; support for content work and support for coordination. The design of CSCW systems must typically address both of these, combining them in a collaborative application. This approach, however, suffers from a variety of well-known problems, not least the compatibility between collaborative and single-user applications, working styles and practices. In this paper, we describe an alternative approach that makes coordination and collaborative functionality an aspect of the collaborative artifact rather than a collaborative application. We present an infrastructure and a series of application examples to illustrate the idea of document-centered collaboration, in which coordination and collaboration are separated from and independent of applications.
---
paper_title: Supporting Cooperation in the SPADE-1 Environment

paper_content:

Software development is a cooperative activity that relies heavily on the quality and effectiveness of the communication channels established within the development team and with the end-user. Process-centered software engineering environments (PSEEs) support the definition and the execution of various phases of the software process. This is achieved by explicitly defining cooperation procedures, and by supporting synchronization and data sharing among its users. PSEE and CSCW technologies have been developed rather independently from each other, leading to a large amount of research results, tools and environments, and practical experiences. We have reached a stage in technology development where it is necessary to assess and evaluate the effectiveness of the research efforts carried out so far. Moreover, it is important to understand how to integrate and exploit the results of these different efforts. The goal of the paper is to understand which kind of basic functionalities PSEEs can and should offer, and how these environments can be integrated with other tools to effectively support cooperation in software development. In particular, the paper introduces a process model we have built to support a cooperative activity related to anomaly management in an industrial software factory. The core of the paper presents and discusses the experiences and results that we have derived from this modeling activity, and how they related to the general problem of supporting cooperation in software development. The project was carried out using the SPADE (Software Process Analysis, Design and Enactment) PSEE and the ImagineDesk CSCW toolkit.
---
paper_title: Assessing process-centered software engineering environments

paper_content:

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments
---
paper_title: Integrating Process Technology and CSCW

paper_content:

Software processes are complex activities where designers, managers, programmers, and users must cooperate to achieve effective results. The work done in the software process community during the last years has been mainly focused on the provision of means to model software processes and to support asynchronous, text-based communication. On the other side, CSCW (Computer Supported Cooperative Work) technology aims at supporting general cooperation activities among human agents exchanging multimedia information. Recently, there has been an increasing interest on the issues related to the integration of these two technologies.
---
paper_title: Coupled vs decoupled user interaction environments in PSEEs

paper_content:

We discuss the relationship between the process modeling language (PML) paradigm and user interaction paradigm in a PSEE. On one side, the user interaction paradigm may strongly depend on the PML and its supporting environment. On the other side, it is related to the social context and the specific process in which it is used. A user interaction environment decoupled from the PML may be tailored to the specific user needs, without impacting on the PML concepts and on the PSEE architecture, On the other hand, a user interaction environment coupled with the PML does not require specific modeling work by the process modeler but binds the interaction paradigm to the process language paradigm. We characterize these two extreme alternatives and provide pros and cons for each of them.
---

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

Section 1: Introduction
Description 1: Introduce the topic of the paper, define key terms, and explain the paper's focus on supporting groups of software engineers.

Section 2: General issues in collaborative software development
Description 2: Discusses the challenges in collaborative software development, including communication overload and the need for organized processes.

Section 3: The Software Development Process and Its Automation
Description 3: Explains the importance of an orderly software development process and the benefits of automation in managing such processes.

Section 4: Process descriptions
Description 4: Details the types of process descriptions (rule-based, task-based, artifact-based, and role-based) used in PCSDEs and their implications for system usability.

Section 5: Latitude of description interpretation
Description 5: Examines the flexibility allowed in interpreting process descriptions, including enforcement policies and strategies for dealing with deviations from the plan.

Section 6: User-environment interaction
Description 6: Describes different interaction paradigms (step-based, artifact-based, virtual environment-based) and strategies for binding users to tasks.

Section 7: Inter-User communication
Description 7: Looks at how inter-user communication is supported in PCSDEs, including through artifact sharing, integration of collaboration tools, and built-in synchronous communication support.

Section 8: Management and assessment
Description 8: Covers the managerial aspects of PCSDEs, including monitoring, assessment, and planning/resource management.

Section 9: Summary and Conclusions
Description 9: Summarizes the paper’s findings on collaboration and coordination in PCSDEs and outlines the strengths and weaknesses of these systems.

Section 10: Acknowledgements
Description 10: Acknowledges the contributions of reviewers and other parties who helped improve the paper.

Section 11: Overview of the Systems
Description 11: Provides detailed descriptions of specific PCSDE systems, highlighting their unique features and functionalities.
</format>

The outline:
