An Environment for Cooperative Software Development Realization and Implications

An Environment for Cooperative Software Development Realization and Implications Josef Altmann and Rainer Weinreich C. Doppler Laboratory for Software Engineering Johannes Kepler Universität Linz, A-4040 Linz, Austria email: {altmann, weinreich}@swe.uni-linz.ac.at Abstract The development of large software systems is teamwork that requires tool support for coordinating cooperative activities, maintaining project control and sharing information. Existing collaborative environments that aim to support cooperative software development often try to predefine and automate the development process. This leads to problems since software development is a highly dynamic process where creativity, uncertainty, informal communication and incremental modification play important roles. We present an environment for distributed cooperative software development that supports informal communication as well as planning, defining, manipulating and supervising cooperative development activities. Our environment accommodates the highly dynamic development process primarily by providing guidelines for various activities and work processes that can be changed according to a clearly defined cooperation model. 1. Introduction and Motivation Software development has never been a simple task and software development projects often end up with missed schedules, blown budgets and flawed products [1]. One of the reasons for this situation, especially for large projects, is problems in coordinating team activities and maintaining project control. Today mastering large software development projects becomes even more complex, not only because projects grow larger, but also because software teams are increasingly distributed across space and time due to globalization and internationalization. This makes adequate support for efficient coordination of (distributed) development activities and the exchange of information among team members an important prerequisite for a successful software engineering project. Several tools and environments have been developed to help control and coordinate software engineering teams. Many of them focus on supporting formal communication procedures, such as written documents, automated processes and other rather non-interactive communication channels. Based on a study of 65 projects, Kraut and Streeter [2] argue that main characteristics of software development like large size, interdependence and uncertainty also need extensive support for informal or interactive communication. We present an environment for distributed cooperative software development that supports informal communication as well as planning, defining, manipulating and supervising cooperative development activities. The highly dynamic development process is considered by mainly providing guidelines for various activities and work processes that can be changed according to a clearly defined cooperation model. Another important characteristic of our environment is the combination of product-centric and process-centric views of software development. During the development of the described environment an existing infrastructure for distributed object-oriented applications was used and extended. We describe lessons learned by presenting the implications of the chosen application architecture on the infrastructure. Based on first experiences using the developed environment, we also present consequences for the software development process. 1.1. Related Work Research projects dealing with the coordination and control of software engineering teams can be found in the areas of process-centered software engineering, workflow management, computer-supported cooperative work, computer-aided software engineering and cooperative software engineering. These research fields have made important contributions toward supporting cooperative work in software engineering projects, but each approach has its deficiencies. Process-centered software engineering (PCSE) strives to predefine and automate the development process by establishing process models that describe all the activities and

information flows of specific software processes (e.g., [3], [4]). The focus is on process models that are enactable and thus executable. Once the process is modeled, a process engine, which is the kernel of a PCSE environment, executes the process model. The process engine controls the invocation of tools and how team members work together according to well-defined protocols. A major drawback of PCSE, which tries to formalize cooperation among a team of people, is that it fails to consider important characteristics of software development like creativity, uncertainty, and informal communication. In this kind of human-intensive processes many of the tasks to be executed cannot be predefined and automated, but require humans creative work. From our point of view, it is impossible to forecast and thus to model all possible kinds of interactions among software developers. According to [5] and [6] process models should be viewed as a vehicle for providing guidance to the members of a software engineering team and for clarifying and understanding the activities of software development and evolution. Workflow management (WFM) systems are obviously similar to PCSE in supporting cooperative software development. They focus primarily on predefining fixed sequences of tasks through which the users are forced to move. Once a workflow is defined in a process-oriented WFM environment (see, e.g., [7]) it is usually impossible to escape from the modeled sequence of cooperative work steps at run time. Form-based WFM systems such as proposed in [8] manage issue reports in a software development process and provide informal communication between the users. As we argued above, these systems fail to support flexible cooperation, which is needed because of the complex interplay of fine-grained development activities. Computer-supported cooperative work (CSCW) supports groups in communicating and coordinating during the execution of their activities. Research includes the development of multi-user applications to support collaboration (e.g., multi-user writing tools) and new methods for communicating between team members (e.g., desktop conferences). Much of this work has potential influence on cooperative software development, but there are only a few tools that were specifically developed to support a team of developers during the development process (see, e.g., [9], [10], [11]). Most of the available tools support synchronous editing and debugging (see, e.g., [12], [13]) or organizing complex information through hypertext linking (see, e.g., [14], [15]). The functionality provided by this kind of tools is useful, but it is not sufficient to solve the problems when cooperatively developing large software systems. Computer-aided software engineering (CASE) environments provide tools for supporting, guiding, or (partly) automating the software development process. The available CASE tools are either supporting a few activities of the software development process or a large part of the whole software development life cycle. Most of these tools are tailored to support specific design or analysis methods, and often have the knowledge of the corresponding methodology built into the environment. The system developer is therefore bound to a particular development method when using a particular CASE tool. In a study examining the support of collaborative facilities in CASE tools, Vessey and Sravanapudi [16] show that available CASE tools provide only few of the features that are commonly found in groupware systems. The only cooperation feature found in the CASE tools investigated was an electronic mail capability. Cooperation and communication facilities such as informal communication, attachment of structured and unstructured annotations, automatic notifications about changes, user awareness capabilities, personal to-do list, etc. are mostly missing in current CASE tools. The most promising approaches can be found in the area of cooperative software engineering. Systems in this category offer policy-driven cooperation such as conventional version and configuration management as well as informal cooperation by connecting structured and unstructured information to documents. The environment presented in [17] provides such specific support for informal cooperation. In this environment an annotation mechanism can be used to visually mark and attach arbitrary information to any kind of software artifact, such as projects, files or variables. This enables developers to organize information as hypertext and facilitates asynchronous communication. Support for software configuration management and project management during the software development and testing phase can be found in [18]. The drawback of these approaches is that they do not offer appropriate support for synchronous and asynchronous cooperation during whole software life cycle. In summary, the described approaches provide only basic support for effective cooperation in a software development project. Tools and methods developed in the area of PCSE, WFM, CSCW and CASE either try to over-automate the development process or support only a particular activity of the software life cycle. Our approach differs in that it supports the coordination of qualified cooperative work throughout the software development process by allowing direct intervention by the users according to a clearly defined cooperation model. We enable team members to generate, categorize, distribute and hierarchically structure information that can be analyzed easily. The information sharing functionality is enhanced with basic facilities for awareness, authentication and authorization.

1.2. Contents In the next section, we outline the application domain and present the main principles of an experimental toolset that supports our view of cooperative software development. Section 3 describes the implications of the chosen application architecture on the underlying infrastructure. In Section 4 we focus on the implications for the software development process. The paper concludes with a discussion of the limitations of our approach and a presentation of future research directions. 2. An Environment for Cooperative Software Development In this section we first present fundamental requirements on an environment for supporting cooperative work in a software development team. Based on the identified requirements, we describe a lean conceptual framework that enables distributed team members to cooperate asynchronously. Finally, we describe the developed cooperative software development environment (CSDE), which is intended for nontechnical as well as technical users in small teams of up to six team members. 2.1. System Requirements In order to identify the requirements for the CSDE we studied the way software development teams work together, the kind of information exchanged, the underlying needs for coordinating the work of software development teams, the kinds of existing project groups, etc. At the C. Doppler Laboratory software is typically developed in small teams based on a common suite of object-oriented application frameworks. Reusing and extending this common base of frameworks is a main task of all development teams. This means that challenges are not only intraprojects but also interproject coordination. A main objective that was identified is the combination of product-centric and process-centric views of software development: the former regards the resulting software as a product consisting of different artifacts (e.g., specification documents, design documents, reference manuals, source files, object files, executable prototypes, etc.), while the latter represents the dynamics in the development process. Aspects to be supported in the product-centric view are expression of relations among artifacts (e.g., by using hypertext; see, e.g., [15], [19]), availability of document templates, concurrent access to files, version management and platform/tool independence. The process-centric view focuses on how team members work together, cooperatively construct artifacts, and exchange information and notifications about changes. To enable participants to correctly anticipate the actions of their colleagues, cooperative software development must integrate these two dimensions. For an environment supporting both views, we have identified the following specific requirements: individual- and group-specific views of the current development process group-, project- and organization-specific information context-dependent document templates, check lists and other guidelines predefined work procedures, each of which contains a list of tasks representing the standard or routine case of performing work status and history information about an ongoing project and its software artifacts browsing facilities to visualize and sort the activity sequence according special aspects, e.g., all activities related to a certain artifact or user configuration of project-specific constraints and regulations, e.g., templates, documentation schemes, work processes, processing states, etc. automatic notification of team members about changes and modifications mechanisms for supporting awareness in cooperative development activities communication independent of time and location asynchronous informal communication (where dispersed team members can jointly comment and annotate documents) Based on these requirements we developed a lean conceptual framework that describes how team members cooperatively do their work. No complex process modeling method or formal approach is employed in the framework to describe and preplan distributed software development activities. 2.2. Conceptual Framework The central notion of the conceptual framework is that of a workpackage. The idea is to split up a complex activity into smaller sub-activities that are assigned to team members. This means, that cooperative activities are organized as a hierarchy of workpackages which aim at describing isolated activities executable by a single person. Workpackages have a person responsible, performer of the work, deadline, specifications, other participants, the artifacts necessary for work performance, and possibly subtasks. The workpackage specification contains the goal of the activity and helps to provide an overall understanding. It may contain attached artifacts such as docu-

ments, annotations, messages, etc. and hyperlinks to additional sources and software engineering tools. A number of related workpackages form a workcontext. Product-centric or process-centric aspects can be taken into consideration when defining such a workcontext. At the highest level of abstraction a workspace groups several workcontexts that are relevant to achieve the common goals of a set of people. Workspaces contain additional projectspecific information about persons and groups, document templates, guidelines, predefined work procedures and time schedules. A predefined work procedure consists of a sequence of work steps or subtasks that represent a guideline for how to perform a standard or routine activity. Concurrency control schemes with rigid locking and conservative serialization have certain drawbacks (see, e.g., [20], [21]) in asynchronous collaboration settings, because the user is an active part of the process. Following the idea that CSCW applications should inform rather than constrain (see [22]) and provide a medium that can be adapted to suit the flexible nature of work of the users (see [23]), we supplemented our conceptual framework with a flexible cooperation model. We argue that some conflicting interactions should be solved by negotiations among the involved users. For this reason, our cooperation model distinguishes between various levels of participation and competence. All workspace members have unrestricted read permission to all workpackages contained in the workspace. There is a set of people involved in a workspace, the controllers, who are the constructors and at the same time the owners of a package object. Controllers are responsible for the completion and result of a workpackage; therefore they have read/ write access to the package s attributes. In addition, they can engage and refuse another user, the executor, to perform work by granting or revoking corresponding access rights. The cooperation model allows the users to know exactly who can do what with a certain workpackage. Controller and executor of a workpackage coordinate and negotiate their work on a package based on this model using informal communication means, such as electronic email, annotations, phone, or face-to-face. Because of this clearly exposed model, conflicts due to simultaneously working on some objects in the workspace can be solved explicitly. The described cooperation model provides a certain kind of awareness within the development process but does not enforce a strict locking model. Our experience shows that this model is usually adequate to avoid conflicts among cooperating project members. 2.3. System Components Applying our conceptional framework on the top of our infrastructure (an overview of the infrastructure is provided in Section 3.2), we implemented the CSDE that consists of a Workspace Manager, which manages shared data, and a number of Cooperation Managers, which represent the interface to the team members working together at different locations and times. Workspace Manager The Workspace Manager maintains workspace structures and a list of registered users. To ensure optimal availability of the workspace objects and immediate reflection of user actions, workspaces are fully replicated in the user s Cooperation Manager. When a user invokes the Cooperation Manager, the workspaces he/she participates in are actually replicated. A producer/consumer approach is used to subsequently distribute changes in a certain workspace to all its replicas. For example, when a controller creates or an executor modifies a specific workspace object, the Cooperation Manager sends a request to the Workspace Manager, which is responsible for the synchronization of the replicated data. The Workspace Manager updates the central workspace objects and multicasts changes to all remote Cooperation Managers. It is up to the Cooperation Manager to update any affected view accordingly. This asynchronous distribution mechanism is also used to distribute messages, annotations and documents. Cooperation Manager During the software development process, the Cooperation Manager supports a team in planning collaborative work, provides to-do lists and informal communication, allows the delegation of workpackages to other users or groups of people involved in task performance, notifies about changes, and provides up-to-date overviews of work progress. The system supports not only a separate but also a combined view of the development activities and involved software artifacts. The Cooperation Manager includes the following tools: Agenda, Workcontext Manager, and Workpackage Editor. Agenda Figure 1 shows a part of the environment where a workspace structure and all related workcontexts and workpackages are presented to a user. When a team member first connects to the Workspace Manager, a login window 1 opens that prompts the user to enter user name and password. After successful authentication, the user receives a list of completed and ongoing workspaces 2 which he/she participates in. The Agenda 3 provides a decomposition hierarchy of each workspace. Project-specific information such as time schedules, document templates, predefined work procedures, guidelines and organizational context can

1 4 2 3 Workspace Workcontext Workpackage Figure 1: Agenda be specified by invoking different editors (e.g., for projects, groups and workspaces) from the tools menu. The awareness tool 4 allows a user to see the availability of other group members, provides information about their current situation, and encourages spontaneous informal communication. Workcontext Manager The Workcontext Manager depicted in Figure 2 lists all open and finished workpackages that exist for a workcontext. It acts as a to-do list and enables team members to be aware of their own responsibilities and activities and of those of other participants. Figure 2: Workcontext Manager Workpackages are normally displayed in the order in which they are entered, but users also have the possibility to use filters for selecting and sorting according to criteria. The view presented in Figure 2 displays the most important attributes and shows among other things the controller (i.e., the person who initiated a workpackage) and the executor (i.e., the person who is responsible for processing a workpackage). In addition, the Workcontext Manager provides awareness information about ongoing activities. The user is informed about allocated, submitted, accepted, rejected, locked or changed workpackages indicated by colored icons in the Workcontext Manager. Workpackage Editor The Workpackage Editor provides different views of a single workpackage, extending from an overview of the package s attributes in general to a detailed description of how to perform a task. Figure 3 shows such an overview of a package; some of the attributes are mandatory (e.g., purpose, controller and executor). Controllers can dynamically select appropriate executors to carry out a workpackage. Beyond its mandatory and optional attributes, a workpackage may be specified in more detail by using a set of predefined document templates (see 5 in Figure 4, which shows an example of a bug report). The toolset supports interoperation between the Cooperation Managers and software engineering or office tools, which is illustrated in Figure 4. This is achieved by adapters that enable the user to specify links 6 in any workpackage form, which can be used to automatically invoke or retrieve information from other resources.

when executing work and may be selected from the workspace repository. The Memo Editor 9 facilitates asynchronous communication during task processing. This enables members of a work group to exchange ideas, remarks or requests via memos. Memos can be attached not only to a workpackage but also to a workcontext and to a workspace. 9 10 Figure 3: Workpackage Editor - Overview Once a description is created, the content can be modified by the controller and/or executor only; other participants have the possibility to attach annotations 7, which can be used to add comments, deposit useful experiences, or express problems for other users who look up the workpackage. Parts of the workpackage description can be locked by the controller or executor. Locked parts are highlighted with different background colors in the description view 5 of a Workpackage Editor. 5 6 Figure 5: Workpackage Editor - Memos, Attachments, Workunits In many situations, a user or a group needs to be notified when a workpackage is finished. For that purpose, special triggers can be defined that are executed whenever a workpackage is finished. To sum up, the proposed CSDE supports multiple software developers in working together, sharing information, improving coordination, promoting communication and monitoring ongoing activities. The toolset is intended as a group support system that is supplemental to an arbitrary software development environment. A discussion of its limitations can be found in Section 5. 8 3. Infrastructural Implications and Overview Figure 4: Workpackage Editor - Description Figure 5 gives an example of a scenario illustrating a workpackage specification that contains attached documents 8, memos 9 that team members exchange about the ongoing work, and predefined work procedures 10. Templates for repetitive work processes serve as guidelines 7 An application architecture like that of the CSDE described in the previous section requires specific services that have to be provided by an underlying infrastructure. In this section we first describe the implications for an objectoriented infrastructure that supports applications of this kind. We then give a short overview of the ObjectWire framework that was used as the basic communication infrastructure for the presented toolset and discuss its limitations.

3.1. Implications for an Object-Oriented Infrastructure The presented development environment was designed and built using a uniform object-oriented approach. Therefore the underlying infrastructure has to provide basic mechanisms to support this implementation technique. With its reliance on encapsulation, object-oriented computing seems to be an ideal candidate to hide distribution completely and to use nearly the same computation model in distributed and nondistributed systems. This uniform view of local and distributed objects is very appealing, and standardization efforts such as CORBA (see [24]) are also based on this unified view of objects. One central idea behind this approach is to design a system independently of distribution and to postpone the decision of whether to make an object local or remote until after system implementation. Once the system has been implemented, each object is a potential candidate for distribution, which may lead to a very fine-grained distributed architecture. In order to discuss whether an infrastructure should provide mechanisms to make distribution transparent (invisible) and to deduce further infrastructural implications, it is first necessary to outline important characteristics of a distributed system in general. General Characteristics of a Distributed System The first important characteristic of a distributed application is the physical separation of some of its components, which influences how objects are accessed. A remote object cannot be identified using an unequivocal memory address, and access has to cross process or machine boundaries. Identifying an object in a distributed environment and accessing its functionality can be concealed by means of a name service that maps logical object names to machine and port addresses and by means of libraries that handle packaging, transferring and unpackaging of a specific request and its parameters. This is basic functionality that is provided by most infrastructures for distributed environments, but it is by far not sufficient. A more disturbing characteristic of a distributed system is latency. The difference in the execution time of a local and a remote method call is still within an order of magnitude. This demands mechanisms for system configuration and tuning. Examples are mechanisms for changing the location of objects, for exchanging the protocol used for communication, and for influencing parameter marshaling, as well as services for dealing with method calls that are not within an allowed time-out interval. An inherent property of a distributed system is concurrency. Since two collaborating components own at least two threads of control, the communication between them is more diverse than in a nondistributed system, which usually involves only one thread of control. In addition to synchronous communication, which resembles a method call in local computing with the client waiting for the server to finish the request, deferred synchronous and asynchronous communication are possible and needed. The latter is the basis for asynchronous notification mechanisms, in which a server asynchronously notifies its clients of changes without waiting for an acknowledgment. Concurrency also demands mechanisms for dealing with resource sharing, e.g., locks, message queues, or transactions. Perhaps the most demanding aspect of developing distributed systems is failure management. The physical separation leads to new (unexpected) errors, and there is no common time and no unequivocally determinable system state. One of the central problems is to determine the cause of an error and to insure that the state of the system is consistent after such a failure. In fact, most effort in developing distributed systems is invested in dealing with problems related to failure management. Ignoring or neglecting error handling in favor of transparency may simply lead to unreliable and unstable systems. Implications for Transparent Object Access Access, latency, concurrency and failure management make uniform object access for local and remote objects not only less desirable but even impossible. For example, issuing a request on a remote object is slower, may require additional mechanisms for synchronizing concurrent access, and requires extensive failure management. In the following we illustrate the drawbacks of a fine-grained uniform solution by means of the CSDE described in Section 2 and identify implications for the underlying infrastructure. As described in Section 2, the central objects of the conceptual framework are workspaces, workcontexts, workpackages, etc. that are needed to describe and structure activities and artifacts of a cooperative work. Using a unified view of objects, one could design a system that simply uses these central objects like in a local application and anticipate distributing them on demand. In our environment several distributed clients (Cooperation Managers) work with these central objects, so these objects will have to be accessed remotely later. Since Cooperation Managers access these objects frequently to display their information, it is also likely that they will encounter performance problems because each call to an object might be remote. Because Cooperation Managers also have their own thread of control, mechanisms for synchronizing access to the workspace objects are needed. But the main problem is that each call to these fine-grained distributed objects may fail, and complex error-management procedures may be needed.

The fine-grained solution has a number of additional severe disadvantages. One is availability. If a process that is managing one of these central objects is temporarily unavailable, all clients, e.g., the Cooperation Managers, are blocked. Another disadvantage is specific to the domain of group support systems and regards concurrency control. Using transactions and rigid locking mechanisms to ensure data integrity is not adequate in this domain since transactions usually span a long time period in which other users needing access to objects are prevented from continuing their work. The alternative solution that we used for our environment anticipates distribution in the design of the system and carefully decides which objects to keep local, which objects to access remotely and which to share. For example, in our system the central workspace objects are local objects. They are managed by a Workspace Manager and are copied to its clients, e.g., the Cooperation Managers, for use. This requires a mechanism supporting object transport. This solves the problems of latency and failure management since access to the objects is local and the only point where distribution has to be considered is when fetching the objects from the server. It also solves the problem of availability, especially if the objects are not copied on demand, but instead a client holds local copies of all objects from the server it is likely to need. This means that a part of the server object repository is replicated at the client end. Availability could be further enhanced by using replication at the server end. One issue that is still a problem is concurrency control, since, for the reasons described, above objects cannot simply be locked on the server. A possible solution to this problem is to allow all clients to access data, including objects that are already in use by other clients, and to delay synchronization to the point when data is returned to the central server. This requires sophisticated strategies for synchronizing all existing object copies with the changed data (see, e.g., [25], [26]). A useful strategy (based on [27]) that we adopted for our environment reduces synchronization problems by adjusting the cooperation model that defines ownership and access rights, distributes meta-information on what is happening with workspace objects, and allows usercontrolled coordination as described in Section 2. Implications for the Infrastructure The main implications for an object-oriented infrastructure for the CSDE can be summarized as follows. The main issues of distribution that have to be dealt with are latency, concurrency and failure management; this does not change with object-orientation. Transparent access to remote objects is not even possible because of these characteristics of a distributed system, and architectures following a unified object-oriented approach may run into problems regarding performance, reliability, availability, etc. Because of the problems to be handled, a coarse-grained architecture where distribution is already carefully anticipated in the design is preferable. From this follows that pleasant interfaces to remote objects are desirable, but they are not the main issue. To ensure location transparency and to tune the system, configuration support is desirable. Concurrency demands additional communication primitives such as deferred synchronous and asynchronous communication. To synchronize access to shared objects, mechanisms for concurrency control have to be provided, but transaction-oriented approaches with rigid locking are not appropriate for the specific application domain. To increase availability, some kind of replication mechanism is needed, which demands not only support for object transport but also needs some kind of multicast communication mechanism as the basis for the synchronization of replicas and for the realization of awareness concepts. Synchronization of replicas is still a problem, but it can be diminished by adapting the cooperation model. 3.2. An Overview of the Basic Infrastructure We used an existing infrastructure for distributed objectoriented applications, called ObjectWire, as the basis for the implementation of the CSDE described in Section 2. ObjectWire is an object-oriented application framework that is implemented in C++ (see [28] for a more elaborate description of ObjectWire). The ObjectWire environment was refined and extended during the development of the CSDE to meet the specific demands of the application domain as described above. ObjectWire consists of frameworks that are organized in layers and that offer communication services on different levels of abstraction. The individual layers are decoupled using object-oriented techniques to facilitate the independent usage of services as far as possible. The five basic frameworks that are parts of ObjectWire are: an IPC Services framework a basic communication framework a configuration framework a distributed architecture framework an object-sharing framework The IPC Services framework offers basic IPC services like shared memory, message queues, sockets and TLI (for transmitting byte streams). The framework includes objectoriented C++ wrappers for these services. The basic communication framework is based on these low-level services and supports the transmission of self-

describing typed message objects. Each message may contain arbitrary other objects that are passed along with the message. The framework also supports an optional dynamic remote method invocation interface (DII) that is based on the typed message interface (TMI). A remote method call is a special message object of type RMC that supports construction of remote method invocations at run time (including parameter marshaling). Synchronous, deferred synchronous and asynchronous communication are supported in this framework, as well as time-outs, priorities and various message filters. The design of this framework allows exchanging the currently used communication service at run time. This framework also contains basic services to support tools for dynamic program analysis (i.e., monitoring). The configuration framework supports system configuration on the basis of coarse-grained distribution only (although the basic communication layer supports remote method calls to individual objects within an application). This means that this layer provides proxies for remote objects that usually represent applications. A distributed environment is statically configured using a central configuration file. In addition, the configuration can be changed dynamically by means of a central configuration manager that can also be used to make queries about the current configuration. Group communication (multicasting) is also supported at this layer by means of group proxies. The services in this layer provide location independence by offering the possibility to assign logical names to coarsegrained objects, allow tuning of the system by providing options to change system parameters such as the IPC service and communication protocol, and can be used to enhance flexibility by allowing queries on the system structure. The most specialized frameworks are the distributed architecture framework and the object sharing management framework. The former provides classes implementing specialized interaction protocols or client and server types. The object sharing management framework is especially important for the implementation of the CSDE described in the previous sections. It provides a replication mechanism that allows clients to hold local copies of all server objects they need during execution of their work. Changes to a replicated object structure are propagated to the server and to other clients managing replicas. The problem of synchronizing replicas is diminished by a clearly defined cooperation model, which has been described in Section 2.2. 3.3. Limitations Experiments with the toolset have proved the feasibility of the underlying infrastructure. However, the basic infrastructure also shows some limitations. One of them is that the infrastructure does not provide a replication mechanism on the server end to ensure availability of the central Workspace Manager. Another deficiency concerns object retrieval support; currently the object sharing infrastructure allows only simple object queries; in order to support users in creating more flexible queries on a workspace structure, declarative access to objects at run time would be needed. Our infrastructure also requires the implementation of a means to easily create, manipulate and merge versions of workspace objects in order to improve support for asynchronous collaboration. 4. Implications for the Software Development Process In the previous section we presented implications for the infrastructure by discussing demands that were raised in the course of developing the CSDE. In this section we outline implications for some aspects of the software development process that ensue from using a CSDE as described in Section 2. Software Process Support The aim of continuous software process improvement is to provide well defined practices for software specification, development, testing and maintenance that can be transferred from one project to the next (see, e.g., [29]). In order to provide helpful information on how to perform standard and routine tasks in an software development project, our environment allows users to associate quality guidelines, document schemes and predefined work procedures (e.g., test plans) to the settings of a workspace. Predefined work procedures represent a guideline for planning and carrying out a cooperative activity and help to improve productivity and quality of software development processes. Coordination of Team Activities Team coordination represents one of the main problems encountered in managing software development projects (see, e.g., [2]). Our toolset supports the continuous exchange of information, ideas, progress reports, comments, joint reviews and agreements on workpackages, which reduces the chances of misunderstanding and conflict among team members and contributes to ensuring the quality of the software system. In addition, the environment enables team members to understand and coordinate who is doing what and when. A team member is informed of the current status of all workpackages he/she is interested in and has the possibility to comment the ongoing work.

Documentation Past activities need to be reinspected in order to allow group members to understand existing contributions of others or to catch up with changes that occurred over time (e.g., changes of requirements, redesign of software components, bug fixes, etc.). The documentation of the software development process is an integral part of our approach. We provide a history of processed workpackages that can be analyzed and used for future development activities such as system maintenance or reengineering projects. Traceability Software development tools often fail to provide enough traceability to allow team members to track down what has been done (see, e.g., [30]). The CSDE offers traceability features that facilitate problem tracking and resolution in both developing and reusing software components. In addition, our approach can help in determining the relationship between the artifacts and the process. Product-related artifacts, which are stored in the project repository, are combined with process-related attributes such as last change, date, activity type and person who is responsible for execution. This allows users to gain a thorough knowledge of a software system and provides indications about potential problems of the system architecture. Support for Distributed Asynchronous Working Teams of software developers working on a software system may not be located in one office. Our environment enables developers to work on the same project, regardless of their location. Project Management The objective of project management is to plan and control development projects from initiation to conclusion. For this reason, the environment provides process metric functionality by means of multiple, different and configurable views on the current project status. Predefined reports allow the management to identify problem areas that are responsible for delays. 5. Conclusion and Further Work We have presented an overview of a CSDE that supports multiple software developers distributed geographically and temporally. The proposed approach provides a cooperation model that leads to a stronger focus on processoriented activities, but the control within cooperative work is always left to the persons involved in the work process. The CSDE supports the cooperation of project members, helps to structure their work, provides a better orientation within the ongoing activities, and provides asynchronous communication facilities. To relate software artifacts with process information, we combined product-centric and process-centric views of software development. Based on the experiences in the development of the environment, we outlined the implications of the chosen application architecture on the underlying infrastructure. Finally, we presented consequences for the software development process that are based on experiences using the CSDE. However, there remain a number of limitations that need to be investigated. One of them is that the environment does not provide more sophisticated views of workspace structures to improve user awareness. Another deficiency concerns information filters: currently the system allows only simple filters on workspaces; in order to support users in getting an overview of an ongoing project a more elaborate filter mechanism would be needed. More work is also necessary to extend the history services with facilities to display multiple views of history information. In addition, we want to support better utilization of workspace data from already completed projects. This could be achieved by mirroring history data in a commercial object-oriented database management system that supports common gateways to other tools. What is additionally needed in our environment is the possibility to easily create, manipulate and merge versions of workspace objects in order to improve support for asynchronous collaboration. 6. References [1] Brooks F.: No Silver Bullet. Essence and Accidents of Software Engineering, Computer, Vol. 20 No. 4, IEEE, April 1987. [2] Kraut R.E., Streeter L.A.: Coordination in Software Development, Communications of the ACM, Vol. 38, No. 3, ACM Press, New York, N.Y., pp. 69-81, March 1995. [3] Osterweil L.: Software Processes are Software too, Proceedings of the 9th. International Conference on Software Engineering, ACM Press, New York, N.Y., pp. 2-13, 1987. [4] Ghezzi C., Armenise P., Bandinelli S., Morzenti A.: Software Processes Representation Languages: Survey and Assessment, Proceedings of the 4th. Conference on Software Engineering and Knowledge Engineering, IEEE CS Press, Los Alamitos, CA, pp. 455-462, 1992. [5] Lehman M.M.: Process Models, Process Programs, Programming Support, Proceedings of the 9th. International Conference on Software Engineering, ACM Press, New York, N.Y., pp. 14-16, 1987. [6] Finkelstein A., Kramer J., Hales M.: Process Modelling: a critical analysis, Integrated Software Reuse: Management and Techniques (Unicom Applied Information Technology) (edited by: Walton P., Maiden N.), Ashgate Pub Co, Portland, OR, pp. 137-148, 1993. [7] Fernström C.: PROCESS WEAVER: Adding Process Support to UNIX, Process-centered software engineering envi-

ronments (edited by: Garg P.K., Jazayeri M.), IEEE CS Press, Los Alamitos, CA, pp. 141-164, 1996. [8] Callahan J., Ramakrishnan S.: Software Project Management and Measurement on the World-Wide-Web, Proceedings, IEEE Fifth Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 96) - Workshop on Requirements Engineering in and for Networked Enterprises, Stanford, CA, 1996. [9] Brothers L., Sembugamoorthy V., Muller M.: ICICLE - Groupware for Code Inspection, Proceedings of the 1990 ACM Conference on CSCW, ACM Press, Los Angeles, CA, pp. 169-181, 1990. [10] Goldman N., Narayanaswamy K.: Lazy Consistency - A Basis for Cooperative Software Development, Proceedings of the 1992 ACM Conference on CSCW, ACM Press, Toronto, pp. 257-264, 1992. [11] Baentsch M., Molter G., Sturm P.: WebMake: Integrating Distributed Software Development in a Structure-Enhanced Web, Proceedings of the 3th. International WWW Conference, Darmstadt, Germany, in special issue: Computer Networks and ISDN Systems, Vol. 27, No. 6, Elsevier Science, Amsterdam, Netherlands pp. 789-800, 1995. [12] Kaiser G.E., Kaplan S.M., Micaleff J.: Multiuser, Distributed, Language-Based Environments, IEEE Software, Vol. 4, No. 6, IEEE CS Press, 1987. [13] Dewan P., Riedl J.: Toward Computer Supported Concurrent Software Engineering, IEEE Software, IEEE CS Press, January 1993. [14] Kaplan S.M., Tolone W.J., Carrol A.M., Bogia D.P., Bignoli C.: Supporting collaborative software development with conversation builder, Proceedings of ACM SIGSOFT 92: Fifth Symposium on Software Development Environments, Washington D.C., pp. 11-20, 1992. [15] Aimar A., Aimar M., Khodabandeh A., Palazzi P., Rousseau B., Ruggier M.: Using WWW to Improve Software Development and Maintenance: application of the LIGHT System to ALEPH Programs, http://www.cern.ch/light/papers/ chep95/julight.ps, 1994. [16] Vessy I., Sravanapudi A.P.: CASE Tools as Collaborative Support Technologies, Communications of the ACM, Vol. 38, No. 1, ACM Press, New York, N.Y., pp. 83-95, January 1995. [17] Bischofberger W.R., Kofler T., Mätzlel K.-U., Schäffer B.: Computer Supported Cooperative Software Engineering with Beyond-Sniff, Proceedings Software Engineering Environments (edited by: Verrall M.S.), IEEE CS Press, Los Alamitos, CA, pp. 135-143, 1995. [18] Gorton I., Hawryszkiewycz I., Ragoonaden K., Chung C., Lu S., Randhawa G.: Groupware Support Tools for Collaborative Software Engineering, Proceedings of the 30th. Hawaii International Conference on System Sciences (HICSS- 30), IEEE, 1997. [19] Ziv H., Osterweil J.: Research Issues in the Intersection of Hypertext and Software Environments, Department of Information and Computer Science, University of California, Irvine, http://www.ics.uci.edu/ ziv/papers/icse16.ps, 1995. [20] Ellis C.A., Gibbs S.J., Rein G.L.: Groupware some Issues and Experiences, Communications of the ACM, Vol. 34, No. 1, ACM Press, New York, N.Y., pp. 38-58, January 1991. [21] Greenberg S., Roseman M.: Groupware Toolkits for Synchronous Work, Research report 96/589/09, Department of Computer Science, University of Calgary, Canada, http:// www.cpsc.ucalgary.ca/projects/grouplab/papers/97-groupwaretoolkits.wiley/report96-589-09/report96-589-09.html, 1996. [22] Beck E., Bellotti V.: Informed Opportunism as Strategy: Supporting Coordination in Collaborative Writing, Proceedings of the 3rd European Conference on Computer Supported Cooperative Work (edited by: Michelis G., Simone C.), Kluwer, Dordrecht, pp. 233-248, 1993. [23] Bentley R., Dourish P.: Medium vs. Mechanism: Supporting Collaboration through Customization, Proceedings of the 4th European Conference on Computer Supported Cooperative Work (edited by: Marmolin H., Sundblad Y. Schmidt K.), Kluwer, Dordrecht, pp. 133-148, 1995. [24] Siegel J. et. al.: CORBA Fundamentals and Programming, John Wiley & Sons, 1996. [25] Beuter T., Dadam P.: Prinzipien der Replikationskontrolle in verteilten Systemen (in German), Research report Ulmer Informatik Berichte 95-11, University of Ulm, Germany, http://www.informatik.uni-ulm.de/abt/dbis/publikationen.html, 1995. [26] Ahamad M., Ammar M.H., Cheung S.Y: Replicated Data Management in Distributed Systems, Readings in Distributed Computing Systems (edited by: Casavant T.L., Singhal M.), IEEE CS Press, Los Alamitos, CA, pp. 572-591, 1994. [27] Greenberg S., Marwood D.: Real-time Groupware as a Distributed System: Concurrency control and its Effect on the Interface, Proceedings of the ACM 1994 Conference on Computer Supported Cooperative Work, ACM Press, Chapel Hill, N.C., pp. 207-218, 1994. [28] Weinreich R., Altmann J.: An Object-oriented Infrastructure for a Cooperative Software Development Environment, Proceedings of the International Symposium on Applied Corporate Computing (ISACC), Monterrey, Mexico, 1997. [29] Chrissis M.B., Curtis B., Paulk M.C., Weber C.V.: The Capabilitiy Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995. [30] Gotel O., Finkelstein A.: An Analysis of the Requirements Traceability Problem, Proceedings of the 1st International Conference on Requirements Engineering 1994, IEEE CS Press, pp. 94-101, 1994.