Modeling Real Requirements for Cooperative Software Development ...

Modeling Real Requirements for Cooperative Software Development: A Case Study Daniele Ballarini∗ , Marco Cadoli∗ , Matteo Gaeta† , Toni Mancini∗ , Massimo Mecella∗ , Pierluigi Ritrovato†and Giuseppe Santucci∗ ∗

Universit`a 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`a di Salerno, Centro Ricerca in Matematica Pura ed Applicata c/o DIIMA, Universit`a di Salerno, Via Ponte Don Melillo, I-84084 Fisciano (SA), Italy E-mail: {gaeta,ritrovato}@crmpa.unisa.it

Abstract G ENESIS 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 G ENESIS, which constitute 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 formally storing, retrieving and accessing all artefacts (documentation, software 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 [11]. In this paper, we present G ENESIS (G ENERALIZED E NVIRONMENT FOR P ROCESS M ANAGEMENT IN C OOP -

ERATIVE S OFTWARE E NGINEERING ), an Open Source distributed platform supporting cooperative software engineering, which is currently developed in the context of an international research project. The G ENESIS 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., [13, 20]); 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 [5,12] 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 processcentered or a product-centered approach [19] (we mention, among the others, [4, 7–9, 16]; a comprehensive review is presented in [14]). All such systems are bi-

ased towards either workflow management-like or document repository-like systems, whereas G ENESIS 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 [18] for details on the G ENESIS architecture). We argue that G ENESIS 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 [6,10] the details of the different G EN ESIS 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 G ENESIS, and then the conceptual design on which G ENESIS is based, which is 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 G ENESIS platform and describes the actual users which will use and test the platform; Section 3 will summarize 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 will present the integrated conceptual design of the platform and the identified main modules, Section 5 will compare G ENESIS to related work, and finally Section 6 will conclude the paper.

2. The G ENESIS Project G ENESIS 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 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 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 in-

stances executed at distributed sites, for the dynamic reconfiguration of the whole software process, and for allowing a flexible distributed exception handling mechanism. Moreover, Software Agents will be used for the execution of some specific tasks such as metrics collection, multisite artefact search, process enactment monitoring (both at the global and local level). The G ENESIS 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 organising 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 subprocess. ❒ Inter-site coordination based on Events and Software Agents. These guidelines perfectly match with the research directions suggested in [17], concerning the main characteristics of future process modelling languages.

2.1. The Industrial Partners The G ENESIS 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 G ENESIS 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 G ENESIS platform into both industrial partners’ premises. Obviously, both test-beds refer to software projects where geographically distributed teams were involved in. 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. 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 each 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 customisations. 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 the Solution ERP. 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. G ENESIS will be evaluated against the actual procedure that was followed. The three distributed teams will use the G ENESIS platform to manage the repository with all input and output artefacts related to each 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 customer. SchlumbergerSema Test-bed. The G ENESIS 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 to the evaluation of the support provided by the G ENESIS environment for the incident management. According to the original geographical distribution of the project, a three-site architecture (coordinator, company A and company B) has been planned for the test-bed. In particular, the role of the coordinator consists of managing the whole project development and centralising discussions and communications among participant partners. Company A

has in charge the responsibility for the four sub-modules while company 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 G ENESIS system but takes charge of conducting externally the test-bed scenario. The main objective of the conductor is to guarantee that all situations of a 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 G ENESIS system. He centralises the communication with the rest of the partners that develop G ENESIS 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 G ENESIS project we followed a human-centered approach [15], 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 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 – G ENESIS 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 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 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. A G ENESIS 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 G EN ESIS 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 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 people involved work in a specific Site. Tests are designed for “trying” Artefacts, and are themselves specific (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 (specialization) Artefact Versions. People can express (see the association from) Comments related to Artefact Versions. Events can be either AutomaticallyHandled

Figure 1. Class diagram for G ENESIS

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

4.1. Subsystems We note that, as a result, the diagram is partitioned in three distinct regions, one for each main subsystem: WorkFlow and Resource Management System (WfRMS), which will be described separately in the following, Event Engine (EE), and Artefact Management System (AMS). A1 – Resource Management System. The Resource Management System is the module that manages the local organization resources. It manages the user data, project data, allocation data of the users in the projects and the access control to the G ENESIS platform. The following services will be accessible from the users through the G ENESIS manager 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 interface 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. The Event Engine is in charge of notifying events that happen during the process enactment, collecting appropriate metrics for monitoring sites activities, and performing 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. The AMS 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. 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) processcentered or (ii) product-centered [19]. Specifically, several systems have been developed: Adele [9], Spade [8], SOCCA [16], the one proposed in [4], WebMake [7], just to mention some of them; a comprehensive review is presented in [14]. The main novelty of G ENESIS 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., [5, 12] 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 G ENESIS, 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, [2, 21]). 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 G ENESIS platform are highly dynamic, with many exceptions likely to be raised during enactment; moreover process enactment is often not repetitive, i.e., in many situations only a single instance of a given process schema is created and enacted [3]. Finally, it should be pointed out that CASE tools supporting software development (e.g., [1]) differ from G ENE -

SIS 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. G ENESIS operates at higher level, allowing the project manager to define the process schema, and subsequently its instantiation and enactment.

6. Conclusions G ENESIS is an Open Source distributed platform supporting cooperative software engineering. We argue that G ENESIS introduces some novelties over current state-ofthe-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 G ENESIS 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 G ENESIS 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.

Acknowledgments This work has been partially supported by the European Commission under Contract No. IST-2000-29380, Project G ENESIS (G ENERALIZED E NVIRONMENT FOR P RO CESS M ANAGEMENT IN C OOPERATIVE S OFTWARE E N GINEERING ) (http://www.genesis-ist.org). The G ENESIS consortium members are: CRMPA (coordinator, Italy), 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 [1] Rational Unified Process, white papers, available at http: //www.rational.com/products/rup. [2] SAP R/3 white paper, available at http://www.sap. com/solutions/r3, 2002. [3] J. Altmann and G. Pomberger. Cooperative software development: concepts, model and tools. In Technology of Object-Oriented Languages and Systems, 1999. TOOLS-30, pages 194–207. IEEE Society Press, 1999. [4] J. Altmann and R. Weinreich. An Environment for Cooperative Software Development: Realization and Implications. In Proceedings of the Thirty-First Annual Hawaii International Conference on System Sciences, Collaboration Systems and Technology, pages 27–37. IEEE, 1998. [5] U. Asklund, B. Magnusson, and A. Persson. Experiences: Distributed development and software configuration management. In Proceedings of 9th International Symposium on System Configuration Management, SCM-9, volume 1675 of Lecture Notes in Computer Science, pages 17–33. Springer, 1999. [6] L. Aversano, A. Cimitile, P. Gallucci, and M. Villani. FlowManager: 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, Oxford, England, 2002. [7] M. Baentsch, G. Molter, and P. Sturm. WebMake: Integrating Distributed Software Development in a StructureEnhanced Web. In Proceedings of the 3rd International WWW Conference, Darmstadt, Germany, 1995. [8] S. Bandinelli, E. Di Nitto, and A. Fuggetta. Supporting cooperation in the SPADE-1 environment. Transactions on Software Engineering, 22(12):841–865, 1996. [9] N. Belkhatir, J. Estublier, and W. L. Melo. A support to large software development process. In Int’l Conference on the Software Process, pages 159–170. IEEE Computer Society Press, 1991. [10] C. Boldyreff, D. Nutter, and S. Rank. 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, Oxford, England, 2002. [11] G. Canfora and A. De Lucia, editors. Workshop on Cooperative Supports for Distributed Software Engineering Processes. Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC02), IEEE, Oxford, England, 2002. [12] I. Crnkovic. Why do some mature organizations not use mature CM tools? In Proceedings of 9th International Symposium on System Configuration Management, SCM-9, volume 1675 of Lecture Notes in Computer Science, pages 50–65. Springer, 1999. [13] G. De Michelis, E. Dubois, M. Jarke, F. Matthes, J. Mylopoulos, M. Papazoglou, K. Pohl, J. Schmidt, C. Woo, and E. Yu. Cooperative information systems: A manifesto. In M. P. Papazoglou and G. Schlageter, editors, Cooperative Information System: Trends and Directions. Academic Press, 1997.

[14] J. C. Derniame, B. Ali Kaba, and D. Wastell. Software process: Principles, methodology, and technology. Lecture Notes in Computer Science, 1500:i–xii, 1–307, 1999. [15] J. Earthy, B. Sherwood Jones, and N. Bevan. 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, 2001. [16] J. Ebert, L. Groenewegen, and R. S¨uttenbach. A Formalization of SOCCA. Fachberichte Informatik 10–99, Universit¨at Koblenz-Landau, Universit¨at Koblenz-Landau, Institut f¨ur Informatik, Rheinau 1, D-56075 Koblenz, 1999. [17] A. Fuggetta. Software process: a roadmap. In Proceedings of the conference on The future of Software engineering, pages 25–34. ACM Press, 2000. [18] M. Gaeta and P. Ritrovato. 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, Oxford, England, 2002. [19] P. Garg and M. Jazayeri, editors. Process-Centered Software Engineering Environments. IEEE Computer Society Press, Los Alamitos, California, 1996. [20] M. Jarke, C. G. van Maltzahn, and T. Rose. Sharing processes: team support in design repositories. International Journal on Intelligent and Cooperative Information Systems, 1(1):145–167, 1992. [21] L. Willcocks and C. Sauer, editors. Journal of Information Technology, Special issue: Enterprise Resource Planning (ERP) Systems, volume 15(4), 2000.