Cooperative Software Development in GENESIS - CiteSeerX

Cooperative Software Development in GENESIS: Requirements, Conceptual Model and Architecture Daniele Ballarini*, Marco Cadoli*, Matteo Gaeta†, Toni Mancini*, Massimo Mecella*, Pierluigi Ritrovato† and Giuseppe Santucci* *

Università di Roma “La Sapienza” Dipartimento di Informatica e Sistemistica Via Salaria 113, I-00198 Roma, Italy E-mail: {ballarin,cadoli,tmancini,mecella,santucci}@dis.uniroma1.it †

Università di Salerno Centro Ricerca in Matematica Pura ed Applicata c/o DIIMA, Via Ponte Don Melillo, I-84084 Fisciano (SA), Italy E-mail: {gaeta,ritrovato}@crmpa.unisa.it Abstract GENESIS is an Open Source distributed platform supporting cooperative software engineering. All requirements concerning cooperation, collaboration, and coordination have been derived from actual user needs, collected from some of the largest software development companies in the European scenario; moreover, an integrated approach, merging both process-centered and product-centered ones, has been adopted. In this paper we present such two basic facets of GENESIS, which constitute some of the main achievements of the project, and therefore provide an innovative platform to be experienced both by practitioners and researchers.

1.

Introduction and Motivation

The trend towards faster and faster software development processes leads to the need of defining, designing and developing software platforms supporting them. The main features of such new software development processes, which are often referred to as cooperative, are the distribution of the different development teams involved in the projects, the need of storing, retrieving 1

and accessing all artefacts (documentation, source code, etc.) produced during the projects – as well as all possible versions of such artefacts – and the opportunity of monitoring and controlling all the development process through automated tools (Canfora and De Lucia, 2002). In this paper, we present GENESIS (GENERALIZED ENVIRONMENT FOR PROCESS MANAGEMENT IN COOPERATIVE SOFTWARE ENGINEERING), an Open Source distributed platform supporting cooperative software engineering, which is currently developed in the context of an international research project. The GENESIS platform design has been carried out on the basis of two main principles: Focus on user requirements. All requirements concerning cooperation, collaboration, and coordination have been derived from actual user needs, as detailed in Section 3. In the literature, several definitions of such terms have been provided (e.g., Jarke et al. (1992), De Michelis et al. (1997)); typical systems supporting the paradigms of cooperation, collaboration, and coordination include process managers, artefact management systems, configuration management tools, and so on, but, as of authors’ knowledge, only few studies have been carried out on the effective application of such paradigms and tools to real cases (e.g., see Crnkovic (1999), Asklund et al. (1999) for real experiences on software configuration management systems in distributed scenarios). This implies that the effective validity of cooperative software engineering is far away from being assured, and therefore a project stemming from real requirements should improve the comprehension of such issues. Integrated conceptual approach. Systems supporting distributed and cooperative/collaborative software development have mainly adopted either a process-centered or a product-centered approach (Garg et al., 1996) (we mention, among the others, Belkhatir et al. (1991), Bandinelli et al. (1996), Ebert et al. (1999), Altmann and Weinreich (1998), Baentsch et al. (1995); a comprehensive review is presented in Derniame et al. (1999)). All such systems are biased towards either workflow management-like or document repository-like systems, whereas GENESIS considers all the main facets of cooperative software development: (i) process management, (ii) artefact management, (iii) resource management, and (iv) event management (see Section 4 and Gaeta and Ritrovato (2002) for details on the GENESIS architecture). 2

We argue that GENESIS introduces some novelties over current state-ofthe-art cooperative software development platforms, being its definition and design based on the previous principles. In previous work (Aversano et al., 2002; Boldyreff et al., 2002) the details of the different GENESIS modules have been presented; conversely the aim of this paper is to highlight the two basic principles, by presenting the actual user requirements collected during the definition of GENESIS, and then the conceptual design on which GENESIS is based, which are the milestone of the integrated approach merging workflow, artefact, resource management, and event management. The remaining of the paper is organized as follows. Section 2 outlines the GENESIS project and describes the actual users which will use and test the system; Section 3 summarizes the collected user requirements, which provide the basis of the specific vision of the concepts of cooperation, collaboration and coordination adopted in the project; Section 4 presents the integrated conceptual design of the platform and the identified main modules; Section 5 describes the system architecture and subsystems; Section 6 compares GENESIS to related work; finally, Section 7 concludes the paper.

2.

The GENESIS Project

GENESIS allows distributing and controlling software development activities among geographically distributed sites. Each site can execute instances of a software process or sub-process; the input and output of these process instances are software artefacts. Each site locally executes instances of its own process model and interacts with other sites mainly to receive the input artefacts from them, and to send the output artefacts to them. The coordination aspects at each site are supported by a Workflow Engine, which allows the enactment of the software process instances applied to that site. The communication involves both formal (e.g., the release of specification documents) and informal (e.g., annotations describing personal considerations about a design choice) aspects, which are provided through data and control integration with an Artefact Management System available at each site. An Event Engine is used as glue for workflow and document management technologies. Specific events have been defined for allowing the synchronization of the process instances executed at distributed sites, for the dynamic reconfiguration of the whole software process, and for allowing a flexible distributed exception handling mechanism. 3

Moreover, Software Agents will be used for the execution of some specific tasks such as metrics collection, multi-site artefact search, and process enactment monitoring (both at the global and local level). The GENESIS platform will be implemented according to the following guidelines: Full autonomy of the local sites. This allows local teams to freely choose both tools and software process models. Powerful Process Description Language (PDL). It allows organizing activities carried out by each site (sub-processes), assigning roles and responsibilities at global level as well as for organizing the activities that will be executed at a local site for a specific sub-process. Inter-site coordination based on Events and Software Agents. These guidelines perfectly match with the research directions suggested in (Fuggetta, 2000), concerning the main characteristics of future process modelling languages.

2.1

The Industrial Partners

The GENESIS project includes two industrial partners, namely LogicDIS from Greece and SchlumblegerSema from Spain. Both industrial partners will execute two different test-beds in order to validate how useful is the GENESIS platform for supporting real software projects and how difficult is to introduce it into an enterprise software production line. Both test-beds will be related to real but already completed activities of a complex software project. This allows reducing the risks and facilitating the introduction of the GENESIS platform into both industrial partners’ premises. Obviously, both test-beds refer to software projects where geographically distributed teams were involved in.

2.1.1

LogicDIS Test-bed

For the needs of the test execution, design and implementation of an Enterprise Resource Planning (ERP) system called “Solution” have been chosen. The LogicDIS scenario will reproduce the simulated development procedures between three development teams located in different geographic locations. 4

The first two development teams consist of development units each one delivering the cooperating modules/components of the ERP that will be customized by the third team. The third team will in turn customize the produced modules according to final customer’s needs. More specifically, two development teams located in different places of Athens, will undertake the development of the ERP modules. The third development team located in Thessaloniki will receive the developed ERP modules along with instructions concerning how to perform customizations. For the communication between the development teams, a VoIP network is used along with VPN and Internet. The scenario provisions for a simulated software development process that will reflect the actual one followed for the development of Solution. Apart from the actual procedure, the scenario will be enriched with actual tracked incidents and details that occurred during the actual development such as design and technical issues, coordination and communication mishaps, etc. GENESIS will be evaluated against the actual procedure that was followed. The three distributed teams will use the GENESIS platform to manage the repository with all input and output artefacts related to each development phase (textual documents, official deliverables, software source files, etc.) and also make use of its communication and collaboration features. The design procedures, discussions between the groups themselves will be reproduced along with communication between the customization group and a final customer.

2.1.2

SchlumbergerSema Test-bed

The GENESIS project will be evaluated through the simulation of a specific part of a geographically distributed software development project in which SchlumbergerSema is one of the sub-contractors together with other two external Companies located in other EU countries. The project includes the design and implementation of a very complex satellite-based communications system composed of several components. SchlumbergerSema has responsibility for only one of these components, which has four sub-modules and a database. A complete project development will be reproduced for the analysis, design, implementation and testing of these sub-modules and the database, bearing in mind the defined project phases and all tracked historic details such as incidents and troubles found in the actual project development, discussions about design issues, etc. During the test-bed execution, particular emphasis will be given to the test phase (including the simulation of the acceptance test) of the component and 5

to the evaluation of the support provided by the GENESIS environment for the incident management. According to the original geographical distribution of the project, a threesite architecture (coordinator, site A and site B) has been planned for the testbed. In particular, the role of the coordinator consists of managing the whole project development and centralizing discussions and communications among participant partners. Site A has in charge the responsibility for the four submodules while site B has in charge the database. Thus, the reproduced project will have a global project manager, two local project managers and two development teams located in two different buildings of the company, although they can use the same intranet. A special role, the conductor, is introduced in order to supervise the course of the events during the project execution. In fact, this role is not a user of the GENESIS system but takes charge of conducting externally the test-bed scenario. The main objective of the conductor is to guarantee that all situations of the real project are reproduced, thus allowing a better evaluation of the platform. Using the data extracted from the actual project, the conductor will cause discussions between development teams and will also introduce incidents. In addition, the conductor is in charge of gathering the user comments and opinions in order to improve the GENESIS system. He centralizes the communication with the developers of GENESIS and he will get user feedbacks to them in the context of refinements of the platform.

3.

User Requirements

Setting up an environment for cooperative software development is a very hard task; in the GENESIS project we followed a human-centered approach (Earthy et al., 2001), collecting requirements from actual users in a planned and structured way. We gathered use cases from both industrial partners, LogicDIS and SchlumbergerSema, grouping together akin functionalities and homogenizing as much as possible the adopted vocabulary. Our systematization has been checked against actual users through several iterations (formal and informal meetings, e-mails, etc.) reaching the confidence we were working on a shared vision of the project goals. Looking at the result of these activities it was quite clear that the users’ interest focused mainly on project coordination and control, on project measuring, on storing and retrieving common artefacts in a collaborative fashion, and on providing the user with features that help the collaboration between 6

the developers (e.g., technical discussions, fora). In particular, we identified the following main groups of functionalities: 1. Global and local process control – Users require a Global Project Manager (GPM) who supervises the entire project, assigning team leaders and project parts to teams, each of them having its own leader (Local Project Manager, LPM) who assigns roles and tasks; 2. Conflicts and incidents handling – Users asked for a facility which allows the customer for posting any kind of conflicts and a functionality allowing for strictly following up incidents; 3. Measuring, monitoring, and alarming – User requirements concerned both panels presenting metrics and figures useful for monitoring the current project situation and advancement, and alarming facilities reminding team members, automatically and on demand, what is pending; 4. Protected, indexed, and shared repository of documents – Users asked for a common place in which team members can store and share different artefacts, providing access through some authentication mechanism that incorporates different authorization policies. Stored artefacts should be indexed by project, workpackage, task, team, allowing for a fast and efficient retrieval, and users must be able to add comments and notes to them. Different policies for controlling collaborative access and version management must be included as well; 5. Communication and coordination – GENESIS must support different kinds of communication, synchronous and asynchronous, allowing the GPM for coordinating team leaders; communication issues must be divided into discussions held in categorized topics, messages to people and to roles; 6. Captain’s log – The system must keep track of all principal events, like the delivery of an artefact or the completion of a task, storing them in a structured way. In order to check the system functionalities with respect to the user requirements we designed a conceptual schema, described in Section 4, tracing each requirement against the data it needs. This activity has been performed 7

together with the end users, increasing the global confidence on the system we were building: users understood our main conceptual design issues and helped us in checking such issues against their needs.

4.

Conceptual Model

In this section we propose a conceptual schema for the GENESIS system, which accounts for all requirements listed in the previous section; in particular, we present a UML class diagram, highlighting all main concepts and static relationships existing between them. The schema is reported in Figure 1. The main aspects of the diagram are commented in what follows. To improve readability, names of classes/associations are typed in the teletype font. The meaning of AMS, EE, and WfRMS will be clarified in Section 5. A Project involving different organizations is decomposed (association pr_composed_by) into SubProcesses, each of them assigned to a different organization and deployed and supported by a different Site. SubProcesses constitute a graph (association sb_precede), which is the Project schema graph. A Project is linked to its Global Project Manager, which is an instance of Human Resource (see the association gpm). The association rework allows for handling cooperation at global level, modeling rework iterations through new SubProcesses. Each SubProcess is therefore assigned_to a Site under the responsibility of a Local Project Manager which is an instance of Human Resource (see the association lpm). A SubProcess consists of different Activities (association sp_composed_by), that constitute a graph (association ac_precede). This two layer classification into subprocesses and activities allows to design a complex Project in an iterative (i.e., through continuous refinements) fashion, and supports the design of inter-organization Projects, in which each involved organization in turn designs its own complex process by specifying its activities. A specialization of SubProcess is Maintenance. Each Activity produces an Artefact List, which consists of (at least one) Artefacts. Activities take some Artefacts in input and produce some Artefacts as output. Each Artefact is assigned one among a controlled list of Artefact Types (association type); each Artefact Type requires (association at_needs) precise Skills to be realized. Artefacts can be Global if they are accessible and visible to other 8

cooperating organizations. Only Global Artefacts are the inputs/outputs of a SubProcess (see the associations ga_input and ga_output). An Activity is performed by several Human Resources that work in such an Activity with a precise Role; the ternary association work allows to represent, e.g., that a person works in the same activity with two distinct roles, e.g., programmer and team leader. In order to be able to assume a specific Role, a Human Resource needs to be expert (association expertise) of some Skills, required (see the association ro_needs) by the given Role. Human Resources may (i) have read access to an Artefact (visibility), (ii) have write access on an Artefact (work_on), or (iii) be responsible (see the association authorship) of such an Artefact. Clearly involved people work_in a specific Site. Tests are designed_for “trying” Artefacts, and are themselves specific (i.e., specialization) Artefacts. Each Artefact is realized through either one or several Artefact Versions (see the association version_of) on which Test Versions are executed_on. Test Versions themselves are specific (i.e., specialization) Artefact Versions. People can express (see the association from) Comments related_to Artefact Versions. Events can be either AutomaticallyHandled or ManuallyHandled (depending on them being automatically managed or requiring human intervention). Event.importance captures the event relevance and allows for automatically build a “Captain's log” characterized by different levels of detail. Events may be associated with Messages, each of them being possibly identified according to specific Topics. Finally, we remark that it is possible to trace single requirements in the schema. As an example, the requirement stating that «The Global Project Manager supervises the entire project» (cf. Section 3 point 1) is accounted for by the following classes and associations (shadowed in Figure 1): Human Resource, gpm, SubProcess, Project, sp_precede, rework, Maintenance, Site, Global Artefact.

9

Figure 1 – Class diagram for GENESIS

10

5. 5.1

System Architecture Subsystems

The diagram of Figure 1 constituting the GENESIS platform can be partitioned in three distinct regions, one for each main subsystems: WorkFlow and Resource Management System (WfRMS), Event Engine (EE), and Artefact Management System (AMS). A1 – Resource Management System. The RMS is the module that manages the local organization resources. It manages human resource data, project data, allocation data of the human resource involved in the projects and the access control to the GENESIS platform. The following services will be accessible from the users through this server module: − Control the data login; − Create and manage the sites of the organizations which collaborate to the projects; − Create and manage the projects of each organization; − Create and manage the user data and the user skills; − Create and manage the human resource allocation on the projects; − Create and manage the business position in the organization. The following services will be accessible from other modules of the platform: − Provide the list of the projects; − Modify the project state; − Provide the list of the users working on a selected project; − Add a new user, modify the user's data, and delete a user; − Search for a user; − Create and delete a resource allocation. A2 – Workflow Management System. The WfMS is based on a client-server architecture. The system consists in the following three main components: the Workflow Engine, that controls and manages the process execution, and interacts with a supporting database; the Workflow Administration and Monitoring, which provides the user with facilities to start the execution of a process and to monitor its status during execution, and finally the Workflow Client, that provides the user with the inter11

face to access the activities which he/she is responsible for. Four kinds of users interact with the tool: − The Process Designer: designs the software process to be used for a given project; − The Project Manager: instantiates, manages, and controls a process instance; − The WfMS Administrator: creates WfMS users, sets up and maintains the system; − The Worker: is any person working on a project and using the system. These users are provided with suitable Web-based interfaces. B – Event Engine. This system is in charge of notifying events that happen during process enactment, in order to collect appropriate metrics for monitoring sites activities, and to perform the required actions to recover from deviations. A user can subscribe him/herself to the events related to processes or activities – according to some visibility policy – either at local or global level. For local events, the Event Engine stores the user subscription and every time that an event happens, it notifies the subscribed users. For global events, instead, it stores the subscription and informs the remote Event Engine; when a significant remote event occurs, the remote module forwards it to the local module that will notify the subscribed user. C – Artefact and Configuration Management System. This system has essentially four separate layers. At the base of the system, the storage layer is responsible for artefact creation, destruction and serialization to appropriate external storage systems. The indexing and search layer depends on this one and provides orderings on the data within the storage system to the third layer –presentation– that handles client connection, transformation of data and security. Alongside all these layers the fourth, metrics, exists to store data collected by agents.

5.2

GENESIS Overall Architecture

As depicted in Figure 2, for a given project one of the GENESIS sites is elected as manager and coordinator of the other sites that are involved in it.

12

project coordinator site global process model

GENESIS site defines and controls

assigned and executed

GENESIS site

GENESIS site

Figure 2 – The GENESIS model

This site is referred to as the project coordinator site. Different projects may have different coordinator sites, therefore a specific site may be a coordinator site for a given project and a “normal” site (i.e., involved in the project without coordination responsibility) in other projects. The project coordinator site has an overall vision of the global process, by holding the taxonomy of the different activities/sub-processes composing the global process, and by assigning tasks to the other GENESIS sites participating in the project. Each site of the GENESIS platform has the same architecture, depicted in Figure 3. Specifically, Figure 3(a) describes the functional architecture, showing that generic sites consist of the subsystems described in Section 5.1.1 Conversely in Figure 3(b) the layered view of the site architecture is given, focusing on back-end layers for persistence, a middle application layer and a presentation one, consisting of the integrated interfaces (i.e., GUIs) of the different subsystems. Not all subsystems at each site involve the same features during a project execution, but the specific used features depend on being a project coordinator site or not. As an example, in a given project, the feature of assigning subprocesses and activities, which is offered by the RMS, is used only at the co1

The Forum System is not described in this paper.

13

ordinator site. Conversely AMS and WfMS are used in each site: the project coordinator site uses them at global process level and the other sites at the local level. Information on the capabilities of each GENESIS site to execute specific software sub-processes/activities and availability of the human resources is held by the RMSs of the involved sites. Therefore, roles and subprocess/activity assignments are managed by the RMS of the project coordinator site, and are based on evaluations following distributed queries towards the other GENESIS sites. Artefacts are managed by the AMSs, which provide also configuration management features. The AMS is the only subsystem that is a “pure” server with respect to the other ones, i.e., it doesn’t initiate conversations with the other subsystems, but only satisfies service requests, through a well-defined interface (i.e., an API). A Global Process Manager (GPM) is a worker at the project coordinator site, which is in charge to model the global process: a sub-process represents a macro-task within the global software development project, e.g., implementing the user interface or testing a software module; artefacts are the outputs of a sub-process (e.g., source code, documentation of the user interface); each sub-process is assigned to a site. After a sub-process has been assigned to a site, a Local Process Manager (LPM) is in charge of administrating the subprocess execution while the GPM is unaware of site internal choices about schedules, resources, and local artefacts. The WfMS supports all these functionalities: an integrated interface allows for (i) assigning operations to each site, (ii) notifying the site that an input artefact is ready, (iii) monitoring the progress of site operations, (iv) getting artefacts, (v) sending alarms/messages, and (vi) notifying users when an important event has occurred. The EE is in charge of notifying events, according to a publish/subscribe policy. Collaborative activities may be designed in the global process, and assigned to people of different sites, who will be working on the same artefact(s), e.g., artefact review. In such scenarios, appropriate access control policies are defined. Therefore a Forum System (FS) is provided by the coordinator site, supporting inter-site collaboration services, such as discussion groups, comments, messages to people or roles, artefact publishing.

14

GENESIS site event layer

workflow management system

forum system

resource management system Interface (API) artefact management system

Services Layer

Data (Persistence) Layer

Presentation Layer

(a)

GENESIS Manager

Process Definition Tool

Workflow Client

Artefact Client

Metrics Client

Communication Client

Process Management Platform Worklist Handler Workflow Engine

Project Management

Process Repository

Resource Management System

Event Repository

Resource Repository

(b) Figure 3 – Site Architecture

15

Artefact Management System

Artefact Repository

Metric Engine

5.3

Metrics and Measurements

The GENESIS platform has been provided with a tool for monitoring the project enactment and collecting metrics. GEM (GENESIS MEASUREMENTS) is a software module, integrated with the platform and independent from the other subsystems, which is in charge to periodically (batch mode) collect metrics during the project enactment and to present synthetic reports about the project status (on demand mode), allowing project managers to generate alarm events either manually or automatically. The basic functionalities of GEM are the automatic collection of data about the project status, the creation of snapshots about the project, its activities and artefacts, and their elaboration to estimate the completion rate. Both snapshots and measures are stored permanently, so allowing the project manager to have a view of the project evolution. Specifically, the GEM tool automatically analyzes artefacts stored in the AMSs both on the coordinator and the local sites to estimate the current advancement of each activity, and uses the process model to estimate whether each activity is on-time or late. In the latter case it automatically notifies the activity owner and the project manager about the delay. Several policies are used to estimate the current completion rate of artefacts, depending on their type. As an example, software artefacts are analyzed starting from their UML class diagrams or from the preliminary declaration about their complexity (e.g., in function points), and then estimating the number of lines of code needed for their full implementation (by using either known or ad-hoc algorithms). It is worth noting that several estimates are made on each artefact, each one having a customizable reliability factor, and a weighted mean is computed to obtain the estimated completion rate for that artefact. Besides the automatically computed metrics, team members are able to claim, when storing an artefact, its current completion rate. The GEM tool uses this value like the others to compute the weighted mean for the completion rate for that artefact: the project manager takes care to set a reliability factor for the claimed measures, according to her confidence in the declarations.

16

6.

Related Work

Up to now, research focusing on support for distributed and cooperative/collaborative software development has biased towards one of two possible approaches: (i) process-centered or (ii) product-centered (Garg and Jazayeri, 1996). Specifically, several systems have been developed: Adele (Belkhatir et al., 1991), Spade (Bandinelli et al., 1996), SOCCA (Ebert, 1999), the one proposed in Altmann and Weinreich (1998), WebMake (Baentsch et al., 1995), just to mention some of them; a comprehensive review is presented in Derniame et al. (1999). The main novelty of GENESIS with respect to previous systems is that it considers all the main facets of cooperative software development: (i) process management and (ii) artefact management and (iii) resource management and (iv) event management. An important issue to consider in designing and implementing a cooperative/collaborative software development platform is the usability and acceptance of the platform by end users, i.e., software workers (managers, architects, analysts, programmers, etc.); as of authors’ knowledge, only few studies have been carried out on the effective application of tools to real cases (see, e.g., Crnkovic (1999), Asklund et al. (1999) for real experiences on software configuration management systems in distributed scenarios). This implies that the effective validity of cooperative software engineering is not assured. In GENESIS, research has been carried out stemming from real requirements (as presented in Section 3) and therefore the platform should gain wide acceptance. Moreover, the use of the platform should also provide insights in the comprehension of usability and acceptance of cooperative and collaborative paradigms applied to software engineering. Workflow, artefact, and resource management is carried out also by operational systems such as Enterprise Resource Planning systems (ERPs), (Willcocks and Sauer, 2000; SAP). In ERPs, managed processes are the operational ones: material and manufacturing requirements planning, sales, finance, human resources and purchasing; such processes, and the documents and resources needed to and produced by them, are stable, highly repetitive (i.e., there are many instances for a given process schema) and in general only few exceptions are raised during process enactments. Conversely, software development processes managed by the GENESIS platform are highly dynamic, with many exceptions likely to be raised during enactment; moreover process enactment is often not repetitive, i.e., in many 17

situations only a single instance of a given process schema is created and enacted (Altmann and Pomberger, 1999). Finally, it should be pointed out that CASE tools supporting software development (e.g., Rational Unified Process) differ from GENESIS as they support a single process (i.e., the one underlying the methodology supporting the tool), and typically do not allow process enactment, but only resource and deliverable management. GENESIS operates at higher level, allowing the project manager to define the process schema, and subsequently its instantiation and enactment.

7.

Conclusions

GENESIS is an Open Source distributed platform supporting cooperative software engineering. We argue that GENESIS introduces some novelties over current state-of-the-art systems on the basis of the platform definition and design (i) focused on user requirements (collected from “real” software development companies, among the largest in the European scenario) and (ii) adopting an integrated approach merging both process-centered and product-centered ones. We have presented the collected requirements, deriving an integrated conceptual schema which is the milestone of the GENESIS platform, and we have shown how the modular architecture of the platform can be straightforwardly derived from it. The project is currently in the implementation and testing stage: a first prototype of the platform has been released to the open source community (http://sourceforge.net/projects/genesis-ist/) and user partners are experimenting with it in the test-bed projects (see Section 2). The final release of the platform is scheduled by the end of 2003. It might be that single subsystems of GENESIS are, in general, less powerful than top of current research prototypes, but the user requirements formal satisfaction and the integrated approach constitute the main achievements of the project, and therefore provide an innovative platform to be experienced both by practitioners and researchers.

18

Acknowledgments This work has been partially supported by the European Commission under Contract No. IST-2000-29380, Project GENESIS (GENERALIZED ENVIRONMENT FOR PROCESS MANAGEMENT IN COOPERATIVE SOFTWARE ENGINEERING) (http://www.genesis-ist.org). The GENESIS consortium members are: CRMPA (coordinator, Italy, with Dipartimento di Informatica e Sistemistica of the Università di Roma “La Sapienza” as subcontractor), MoMA (Modelli Matematici ed Applicazioni, Italy), RCOST (Research Center on Software Technologies at University of Sannio, Italy), RISE (Research Institute in Software Evolution at University of Durham, United Kingdom), LogicDIS (Pilot user, Greece) and SchlumbergerSema (Pilot user, Spain).

References Altmann J., and Pomberger G. (1999), “Cooperative Software Development: Concepts, Model and Tools”, in Technology of Object-Oriented Languages and Systems (TOOLS-30), pp. 194–207. IEEE Computer Society Press. Altmann J., and Weinreich, R. (1998), “An Environment for Cooperative Software Development: Realization and Implications”, in Proceedings of the 31st Annual Hawaii International Conference on System Sciences, Collaboration Systems and Technology, pp. 27–37. IEEE Computer Society Press. Asklund U., Magnusson B., and Persson A. (1999), “Experiences: Distributed Development and Software Configuration Management”, in Proceedings of 9th International Symposium on System Configuration Management (SCM-9), Lecture Notes in Computer Science, 1675, pp. 17–33. Springer Verlag. Aversano L., Cimitile A., Gallucci P., and Villani M. (2002), “Flow-Manager: A Workflow Management System Based on Petri Nets”, in Proceedings of the 1st Workshop on Cooperative Supports for Distributed Software Engineering Processes, in conjunction with COMPSAC 2002. IEEE Computer Society Press. Baentsch M., Molter G., and Sturm P. (1995), “WebMake: Integrating Distributed Software Development in a Structure-Enhanced Web”, in Proceedings of the 3rd International WWW Conference, Darmstadt, Germany. Bandinelli S., Di Nitto E., and Fuggetta A. (1996), “Supporting Cooperation in the SPADE-1 Environment”, Transactions on Software Engineering, 22(12):841–865. Belkhatir N., Estublier J., and Melo W. L. (1991), “A Support to Large Software Development Process”, in International Conference on the Software Process, pp. 159–170. IEEE Computer Society Press. Boldyreff C., Nutter D., and Rank S. (2002), “Active Artefact Management for Distributed Software Engineering”, in Proceedings of the 1st Workshop on Cooperative Supports for Distributed Software Engineering Processes, in conjunction with COMPSAC 2002. IEEE Computer Society Press.

19

Canfora G., and De Lucia A., editors (2002), “Workshop on Cooperative Supports for Distributed Software Engineering Processes”, Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC02). IEEE Computer Society Press. Crnkovic I. (1999), “Why Do Some Mature Organizations Not Use Mature CM Tools?”, in Proceedings of 9th International Symposium on System Configuration Management (SCM-9), Lecture Notes in Computer Science, 1675, pp. 50–65. Springer Verlag. De Michelis G., Dubois E., Jarke M., Matthes F., Mylopoulos J., Papazoglou M., Pohl K., Schmidt J., Woo C., and Yu E. (1997), “Cooperative Information Systems: A Manifesto”, in Papazoglou M. P., and Schlageter G. editors, Cooperative Information System: Trends and Directions. Academic Press. Derniame J. C., Ali Kaba B., and Wastell D. (1999), “Software Process: Principles, Methodology, and Technology”, Lecture Notes in Computer Science, 1500:i–xii, 1–307. Earthy J., Sherwood Jones B., and Bevan N. (2001), “The Improvement of HumanCentred Processes – Facing the Challenge and Reaping the Benefit of ISO 13407”, International Journal of Human Computer Studies, 55(4):553–585. Ebert J., Groenewegen L., and Süttenbach R. (1999), “A Formalization of SOCCA”, Fachberichte Informatik pp. 10–99, Universität Koblenz-Landau, Institut für Informatik, Rheinau 1, D-56075 Koblenz. Fuggetta A. (2000), “Software Process: a Roadmap”, in Proceedings of the Conference on the Future of Software Engineering, pp. 25–34. ACM Press. Gaeta M., and Ritrovato P. (2002), “Generalised Environment for Process Management in Co-operative Software Engineering”, in Proceedings of the 1st Workshop on Cooperative Supports for Distributed Software Engineering Processes, in conjunction with COMPSAC 2002. IEEE Computer Society Press. Garg P., and Jazayeri M., editors (1996), “Process-Centered Software Engineering Environments”, IEEE Computer Society Press. Jarke M., van Maltzahn C. G., and Rose T. (1992), “Sharing Processes: Team Support in Design Repositories”, International Journal on Intelligent and Cooperative Information Systems, 1(1):145–167. Rational Unified Process, white papers, available at http:// www.rational.com/products/rup. SAP R/3 white paper (2002), available at http://www.sap.com /solutions/r3. Willcocks L., and Sauer C., editors (2000), Journal of Information Technology, special issue on Enterprise Resource Planning (ERP) Systems, 15(4).

20