1

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 sce-nario; 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 support-ing 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

2

and accessing all artefacts (documentation, source code, etc.) produced during the projects – as well as all possible versions of such artefacts – and the op-portunity 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 engineer-ing, 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 coopera-tion, 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 Miche-lis et al. (1997)); typical systems supporting the paradigms of coopera-tion, collaboration, and coordination include process managers, arte-fact 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 scenar-ios). 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), Bandi-nelli et al. (1996), Ebert et al. (1999), Altmann and Weinreich (1998), Baentsch et al. (1995); a comprehensive review is presented in Der-niame et al. (1999)). All such systems are biased towards either work-flow management-like or document repository-like systems, whereas GENESIS considers all the main facets of cooperative software devel-opment: (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 architec-ture).

3

We argue that GENESIS introduces some novelties over current state-of-the-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 concep-tual design on which GENESIS is based, which are the milestone of the inte-grated 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 sys-tem; 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 concep-tual design of the platform and the identified main modules; Section 5 de-scribes 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 activi-ties among geographically distributed sites. Each site can execute instances of a software process or sub-process; the input and output of these process in-stances are software artefacts. Each site locally executes instances of its own process model and interacts with other sites mainly to receive the input arte-facts 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 synchroniza-tion of the process instances executed at distributed sites, for the dynamic re-configuration of the whole software process, and for allowing a flexible dis-tributed exception handling mechanism.

4

Moreover, Software Agents will be used for the execution of some specific tasks such as metrics collection, multi-site artefact search, and process enact-ment 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 model-ling 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 dis-tributed teams were involved in.

2.1.1 LogicDIS Test-bed

For the needs of the test execution, design and implementation of an En-terprise 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.

5

The first two development teams consist of development units each one delivering the cooperating modules/components of the ERP that will be cus-tomized 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 devel-opment 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 re-pository 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 proce-dures, 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 ex-ternal Companies located in other EU countries.

The project includes the design and implementation of a very complex sat-ellite-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

6

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 three-site architecture (coordinator, site A and site B) has been planned for the test-bed. 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 sub-modules while site B has in charge the database. Thus, the reproduced project will have a global project manager, two local project managers and two de-velopment 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 sce-nario. 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 plat-form. Using the data extracted from the actual project, the conductor will cause discussions between development teams and will also introduce inci-dents. 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 feed-backs 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 systematiza-tion has been checked against actual users through several iterations (formal and informal meetings, e-mails, etc.) reaching the confidence we were work-ing on a shared vision of the project goals.

Looking at the result of these activities it was quite clear that the users’ in-terest focused mainly on project coordination and control, on project measur-ing, on storing and retrieving common artefacts in a collaborative fashion, and on providing the user with features that help the collaboration between

7

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 al-lows 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 re-minding team members, automatically and on demand, what is pend-ing;

4. Protected, indexed, and shared repository of documents – Users asked for a common place in which team members can store and share dif-ferent artefacts, providing access through some authentication mecha-nism that incorporates different authorization policies. Stored arte-facts should be indexed by project, workpackage, task, team, allowing for a fast and efficient retrieval, and users must be able to add com-ments and notes to them. Different policies for controlling collabora-tive 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 re-quirements we designed a conceptual schema, described in Section 4, tracing each requirement against the data it needs. This activity has been performed

8

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 particu-lar, 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 dif-ferent organization and deployed and supported by a different Site. Sub-Processes constitute a graph (association sb_precede), which is the Project schema graph. A Project is linked to its Global Project Man-ager, 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 re-sponsibility of a Local Project Manager which is an instance of Human Re-source (see the association lpm). A SubProcess consists of different Activities (association sp_composed_by), that constitute a graph (as-sociation 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 com-plex 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 Ar-tefact Type requires (association at_needs) precise Skills to be re-alized. Artefacts can be Global if they are accessible and visible to other

9

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 al-lows to represent, e.g., that a person works in the same activity with two dis-tinct 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 ex-pertise) of some Skills, required (see the association ro_needs) by the given Role. Human Resources may (i) have read access to an Arte-fact (visibility), (ii) have write access on an Artefact (work_on), or (iii) be responsible (see the association authorship) of such an Arte-fact. Clearly involved people work_in a specific Site. Tests are de-signed_for “trying” Artefacts, and are themselves specific (i.e., spe-cialization) 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., spe-cialization) Artefact Versions. People can express (see the association from) Comments related_to Artefact Versions.

Events can be either AutomaticallyHandled or ManuallyHan-dled (depending on them being automatically managed or requiring human intervention).

Event.importance captures the event relevance and allows for auto-matically 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.

10

Figure 1 – Class diagram for GENESIS

11

5. System Architecture

5.1 Subsystems

The diagram of Figure 1 constituting the GENESIS platform can be parti-tioned 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, pro-ject 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 compo-nents: the Workflow Engine, that controls and manages the process exe-cution, and interacts with a supporting database; the Workflow Admini-stration 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 inter-

12

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 main-

tains the system; − The Worker: is any person working on a project and using the sys-

tem. 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 lo-cal or global level. For local events, the Event Engine stores the user sub-scription 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 es-sentially four separate layers. At the base of the system, the storage layer is responsible for artefact creation, destruction and serialization to appro-priate 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, transforma-tion 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.

13

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 coordi-nator 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, show-ing 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 dif-ferent 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 sub-processes and activities, which is offered by the RMS, is used only at the co- 1 The Forum System is not described in this paper.

GENESIS site

GENESIS site

GENESIS site

global process model

project coordinator site

defines and controls

assigned and executed

GENESIS site

GENESIS site

GENESIS site

global process model

project coordinator site

defines and controls

assigned and executed

14

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 lo-cal 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 sub-process/activity assignments are managed by the RMS of the project coordi-nator 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 conver-sations 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., implement-ing 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 sub-process 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 ar-tefact is ready, (iii) monitoring the progress of site operations, (iv) getting ar-tefacts, (v) sending alarms/messages, and (vi) notifying users when an impor-tant 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 as-signed to people of different sites, who will be working on the same arte-fact(s), e.g., artefact review. In such scenarios, appropriate access control policies are defined. Therefore a Forum System (FS) is provided by the coor-dinator site, supporting inter-site collaboration services, such as discussion groups, comments, messages to people or roles, artefact publishing.

15

(a)

(b)

Figure 3 – Site Architecture

GENESIS site

artefact management

system

Interface (API)

resource management system

workflow management system

forum system

event layer

GENESIS site

artefact management

system

Interface (API)

artefact management

system

Interface (API)

resource management systemresource management system

workflow management systemworkflow management system

forum system

event layer

GENESISManager

ProcessDefinition

Tool

WorkflowClient

ArtefactClient

MetricsClient

CommunicationClient

Pre

sen

tati

on L

ayer

Ser

vice

s La

yer

WorklistHandler

WorkflowEngine

ProjectManagement

Process Management Platform

MetricEngine

ArtefactManagement

System

ResourceManagement

System

ProcessRepository

EventRepository

ResourceRepository

ArtefactRepository

Dat

a (P

ers i

sten

ce)

L aye

r

GENESISManager

ProcessDefinition

Tool

WorkflowClient

ArtefactClient

MetricsClient

CommunicationClient

Pre

sen

tati

on L

ayer

Ser

vice

s La

yer

WorklistHandler

WorkflowEngine

ProjectManagement

Process Management Platform

MetricEngine

ArtefactManagement

System

ResourceManagement

System

ProcessRepository

EventRepository

ResourceRepository

ArtefactRepository

Dat

a (P

ers i

sten

ce)

L aye

r

16

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 met-rics 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 activi-ties and artefacts, and their elaboration to estimate the completion rate. Both snapshots and measures are stored permanently, so allowing the project man-ager 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 ad-vancement 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 arte-facts, 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 num-ber 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 comple-tion rate for that artefact: the project manager takes care to set a reliability fac-tor for the claimed measures, according to her confidence in the declarations.

17

6. Related Work

Up to now, research focusing on support for distributed and coopera-tive/collaborative software development has biased towards one of two possi-ble approaches: (i) process-centered or (ii) product-centered (Garg and Jazay-eri, 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 coopera-tive/collaborative software development platform is the usability and accep-tance of the platform by end users, i.e., software workers (managers, archi-tects, 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 require-ments (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 collabora-tive paradigms applied to software engineering.

Workflow, artefact, and resource management is carried out also by opera-tional systems such as Enterprise Resource Planning systems (ERPs), (Will-cocks and Sauer, 2000; SAP). In ERPs, managed processes are the operational ones: material and manufacturing requirements planning, sales, finance, hu-man resources and purchasing; such processes, and the documents and re-sources 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

18

situations only a single instance of a given process schema is created and en-acted (Altmann and Pomberger, 1999).

Finally, it should be pointed out that CASE tools supporting software de-velopment (e.g., Rational Unified Process) differ from GENESIS as they sup-port a single process (i.e., the one underlying the methodology supporting the tool), and typically do not allow process enactment, but only resource and de-liverable 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 de-sign (i) focused on user requirements (collected from “real” software devel-opment companies, among the largest in the European scenario) and (ii) adopting an integrated approach merging both process-centered and prod-uct-centered ones.

We have presented the collected requirements, deriving an integrated con-ceptual 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 pro-totype 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 power-ful 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.

19

Acknowledgments

This work has been partially supported by the European Commission un-der Contract No. IST-2000-29380, Project GENESIS (GENERALIZED ENVI-RONMENT FOR PROCESS MANAGEMENT IN COOPERATIVE SOFTWARE ENGI-NEERING) (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 In-stitute 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: Con-cepts, Model and Tools”, in Technology of Object-Oriented Languages and Sys-tems (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 Devel-opment and Software Configuration Management”, in Proceedings of 9th Interna-tional 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 Proc-esses, 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 De-velopment 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 Dis-tributed Software Engineering”, in Proceedings of the 1st Workshop on Coopera-tive Supports for Distributed Software Engineering Processes, in conjunction with COMPSAC 2002. IEEE Computer Society Press.

20

Canfora G., and De Lucia A., editors (2002), “Workshop on Cooperative Supports for Distributed Software Engineering Processes”, Proceedings of the 26th Annual In-ternational 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 Informa-tion 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 Human-Centred 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 Confer-ence on the Future of Software Engineering, pp. 25–34. ACM Press.

Gaeta M., and Ritrovato P. (2002), “Generalised Environment for Process Manage-ment in Co-operative Software Engineering”, in Proceedings of the 1st Workshop on Cooperative Supports for Distributed Software Engineering Processes, in con-junction 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 In-formation 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, spe-cial issue on Enterprise Resource Planning (ERP) Systems, 15(4).