Generalised environment for process management in ... - IEEE Xplore

Generalised Environment for Process Management in Cooperative Software Engineering

Matteo Gaeta*†, Pierluigi Ritrovato* [email protected]; [email protected];

*

†

Consorzio CRMPA – Centro di Ricerca in Matematica Pura ed Applicata Dipartimento di Ingegneria dell’Informazione e Matematica Applicata – Università di Salerno Via ponte don Melillo – 84084 Fisciano – ITALY Abstract

In this paper we present an Open Source platform supporting distributed software engineering processes, which is currently under development in the GENESIS project1 (GEneralised eNvironment for procEsS management in cooperatIve Software engineering). It supports the definition, enactment and control of software processes in a distributed manner and the formal and informal communication among distributed software engineer teams using Workflow and Document Management technologies. We make use of software agents as technological glue to control and monitor the activities execution at different sites (low invasive approach). The highly flexible process definition language allows Project manager to define a software process at different levels of detail supporting both iterative refinement and on the fly activities flow modification.

1. Introduction and motivation The software development is a not simple task [17] especially for large projects where big teams, often geographically distributed, are involved in. The internet remarkable growth, the emergence of distributed component technologies and the globalisation and internationalisation objectives achievement, are influencing both software development and deployment by promoting the adoption of virtual organisation models [12] including development teams located all over the world (especially in countries such as those of Eastern Europe). This approach contributes to emphasise the intrinsic distributed nature of software development. As showed by Kraut and Streeter in their study [15] a key element for successful project realisation is providing a concrete 1

partially funded by the European Commission in the frame of Information Society Technologies RTD Programme (contract no. IST2000-29380). The GENESIS Consortium Members are: CRMPA (coordinator - IT), MoMA – Modelli Matematici ed Applicazioni (IT), RCOST – Research Center on Software Technologies at University of Sannio (IT), RISE – Research Institute in Software Evolution at University of Durham (UK), LogicDIS (Pilot User – GR), SchlumbergerSema (Pilot user – ES).

support to communication and activities coordination among team members. Supporting communication in a distributed software engineering scenario means allowing software engineers to know how to make some artefact, why and who has taken some design decisions, etc. Supporting coordination in this scenario means supporting the definition and the enactment of a software process (i.e. arranging the life cycle phases in order to create and maintain a software system). Many research projects addressing coordination and communication issues in software development have been developed. Results have been produced in the fields of process-centered software engineering (e.g.[5], [6], [2], [11]), computer supported cooperative work (e.g. [8], [14], [4], [7], [9]), workflow management systems ([3], [10], [16]). Obviously each of these approaches presents some drawbacks. PSEE, as stated in [13], are too intrusive, rigid in process specification, complex to configure and use and are often strongly connected to specific software production tools. CSCW environments provide with a good support for synchronous and asynchronous communication but this is not enough in the cooperative software development. WFMS may address some of the PSEE drawbacks allowing to model different aspects of a software organisation (not only software processes) in a uniform way. Unfortunately, WFMSs are too rigid in the process execution. In fact, once the workflow (the software process) is enacted by the engine (an instance of the process is created) it is impossible to escape from the modelled sequence of tasks. We aim to address many of these drawbacks through the integration of several technologies in an Open Source distributed platform to support cooperative software engineering. The paper is organised as follows: Section 2, describing in general the GENESIS platform; Section 3, describing the architecture, Section 4 presenting the Use Case and finally Section 5, drawing conclusions and future work.

Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02) 0730-3157/02 $17.00 © 2002 IEEE

2. The GENESIS Platform After a brief summary of user needs we outline in this section a general description of how we think to meet these needs.

•

2.1 GENESIS user needs In the following, we summarize the user needs and their expectations from the GENESIS platform. It has been expressed by the whole GENESIS Consortium and accepted by the user partners. General needs • A GUI providing a project oriented view is needed. • A project is implemented by assigning specific tasks or sub-processes to several sites (Organisation involved in the project). • A resource management for each site is needed. Software process control • The entire project is supervised by a Global Project Manager (GPM) who assigns tasks/sub-processes to the other project site where Local Project Managers (LPM) lead teams throughout the project. • Each developing team has its own leader who assigns roles and tasks. • Several worksheets are needed allowing GPM, LPMs and team members to monitor the current situation and advancement of the project (software and project metrics, follow up reports, deadlines alarms, list of pending tasks and incomplete duties). • Tasks rescheduling and changing of role/activities assignment to team resources must be allowed. Artefacts Management • A local site repository for artefacts is needed. • Users must be able to edit artefacts and add comments, notes and replies to them. • It is important to provide document versioning and reference issues to specific versions. • In a single project, the access rights to artefacts have to be based on roles and sites. • Policies to control concurrent access to artefacts are needed. • A way to manage and join pieces of “documents” (i.e. specific document sections, code, etc.) elaborated by different working teams, is needed. • It is needed to control and to monitor all the test phase results for code artefacts (the teams have to know what tests have been passed by every versions of code; when a new version is configured, developers must know if there are prior versions that passed any test that the newest one did not). Communication and Coordination • Team members should be able to cooperate. The main point is to support all necessary interactions and

•

• • •

communication facilities in order to enhance the effectiveness and the results of the software engineers and/or developers. All the changes in the activities and tasks scheduled must be notified to people involved both directly (i.e. member of the local team charged with this task/activity) and indirectly (i.e. people working in another site that should use the output of this task/activity). A log of main events is needed (it is a public document that helps to trace the most important dates and facts during the project: deliveries, incidents, changes of request, any other kind of troubles, etc). If anyone completes a task or delivers any kind of artefact, the log has to be updated. The communication is distinguished in synchronous and asynchronous, by involving a variety of tools: email, chat, forum, etc. A “remind” facility should be implemented to remind people about tasks assigned to them and that are not yet complete.

2.2 Our Vision Starting from the above mentioned user needs, we aim at designing and developing a non-invasive and distributed Open Source platform which can be easily introduced into an enterprise in order to model and control software engineering processes and to manage co-operation among team members. The GENESIS platform allows distribution and control of the software development activities among different sites. A site corresponds to an Organisation involved in a project and running a GENESIS server. 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 back from them and send the output – artefacts to them. The co-ordination aspects at each site are supported by a workflow-like engine, which implements 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 will be provided through data and control integration with an Artefacts Management System available in each site. Software agents are used as glue for workflow and document management technologies. In particular, they will be in charge of synchronizing process instances executed at distributed sites, dynamic reconfiguration of the whole software process and flexible distributed exception handling mechanism (allowing on the fly


modification of the activities flow), dynamic resources allocation management, process data collections and process monitoring, and artefacts retrieval. The GENESIS platform will be implemented according to the following three fundamental principles: • Full autonomy of the local sites. It stands for independence for tools and processes choosing. • Simple and abstract macro-process modelling language. It allows describing activities carried out by different sites (located in different geographic areas). • Inter-site coordination based on software agents. The macro-process is enacted by software agents and is based on the exchange of artefacts. These principles perfectly match with the research directions as suggested in [13] concerning the main characteristics of future PSEE and Process Modelling Languages. In particular, we think that some of the following key factors could lead us to succeed in the project: • Starting from real user needs, to adapt technologies in order to avoid imposing constraints to the user daily work; • Beeing flexible by allowing the project manager to model, in a simple way, their “real” projects (i.e. allowing different level of details in process specification, supporting a continuous rescheduling and a resources allocation, having always an updated view of the project status, etc.); • Supporting and tracking formal and informal communication, facilitating re-use and transmission of organizational knowledge among software engineers; • Avoiding a centralised approach for artefacts and software processes, management and enactment (providing to local site maximum independence in both technology and methodology choices). • Concentrating mainly on software process control, making the Artefact a central element of the platform (artefact-centred approach). • The Open Source nature of the project.

Figure 1: GENESIS general Architecture There is a special site acting as a coordinator for the sites federation. This coordinator defines and maintains information concerning the whole software process to be executed, roles and responsibilities of each site (organisation resources modelling), allocates work (subprocess) to the other sites, coordinates agents to collect data for process monitoring. Some of these tasks are accomplished by software agents. For this purpose, each site offers a common API to the outer world, allowing both the interaction with agents and the communication with other sites. Each site presents a multi-layer architecture as depicted in Figure 2 consisting of four layers: Data Layer, Services Layer, Presentation Layer and the Agent layer.

3. The GENESIS Architecture The Figure 1 shows the general architecture of the GENESIS platform. Figure 2: GENESIS site Architecture

3.1 Data Layer In the Data Layer all information used by upper layers is stored. The following information types can be stored in:


•

• • •

Process-Data: it represents all information concerning the definition of the process model (tasks, scheduling, dependences, etc.), the execution and current state of the running process instances. Artefacts: they are final or intermediate work products that are produced and used during the project execution. Metadata: meta-information used to index Artefacts and to facilitate tracing of formal and informal communication. Resource-Data: it stores all contact information concerning either the members or the related projects of a Site (name, phone, skill, etc.).

3.2 Service layer The service layer defines the basic services that the platform must provide to the users. This layer includes the following modules: • Resource Management System: it provides basic services for resources access control to the other components of the platform (single-sign-on) as well as accounting, team group management, etc.. • Workflow Management Module: it defines, creates and manages the execution of the software process, interacts with workflow participants and, where required, invokes the use of IT tools and applications. • Artefact Management Module: it allows the representation, at high level of abstraction, of the artefacts being produced in a scalable and customisable software repository, providing schema and domain models. This module uses metadata for indexing information. • Notification engine: it permits to send messages through the software agents, to different users who may be local or who may belong to other sites. • Metric Engine: by using specific software agents, it permits to collect and manage both process and products metrics. • Communication engine: it provides basic services for the communication among various users of the distributed software development team The events, the metrics and the messages managed by the Notification, Metric and Communication engines, are, respectively, a special kind of artefacts. These components directly interact with the Artefact Management system, using it as a persistent layer.

3.3 Presentation Layer The Presentation Layer includes software components for the access to Platform Services or for the building of new applications combining services provided by the other layers. At the moment it will include:

•

• • • • •

GENESIS Manager: it provides administrative functionalities to configure the GENESIS server (it configures engines, communication ports, addresses of other sites involved in a particular project, etc.), and it manages resources (it: creates accounts and access rights, defines roles and responsibilities, skills, creates teams, links resources to projects, etc.); Metrics Client: it allows accessing and managing quality and productivity metrics. Process Definition Tool: it is used to create the process description in a computer understandable form, via a process definition language. Workflow Client: it is a separate software component, responsible for the look and feel of the user dialogue and control of the local interface with the user. Artefact Client: It permits to access to the artefacts management functionalities (i.e. search, checkin/check-out, etc.). Communication client: it provides a GUI to send messages, to attach comments to artefacts, etc.

3.4 Agent Layer Agents are mainly used for the synchronization of process instances executed on different sites, for the dynamic reconfiguration of the software process and for the flexible distributed exception handling mechanism (allowing the fly flow modification), for the dynamic resources management allocation, for process data collections and process monitoring, and for artefacts retrieval.

4. GENESIS Use Cases The GENESIS platform prototype will be tested in specific domains reality within both industrial project partners. The first use case concerns the development process of an ERP application between two teams located in two different geographical locations. Each team will have its own senior developer who will coordinate the team members, while the entire project is supervised by a project manager. The scenario details the process, from the stage where the teams are assembled to the validation of the produced application. The second use case is in the aerospace domain and aims at stressing the communication and cooperation aspects, as well as on fly modification of a software process instance, to manage rework in tests phases. Another application domain of the GENESIS framework is the management of the European research projects, especially those under preparation in the next FP6 (which foresees large consortiums and a long life time). Most of these projects concern software development.


5. Future work and Conclusions In summary, the main project goal is to create a flexible, usable and low intrusive platform that supports cooperation and monitors the execution of distributed software processes, trying to overcome current PSEE limitations. Most of the design efforts are directed towards both the definition of a PDL that allows/tolerates on the fly modifications/deviations and the uniform management of rules/responsibilities (such as in WFMSs) and artefacts production. The first version of the GENESIS platform will be released to the Open Source community in September 2002. The final version will be released one year later.

[10]

[11] [12] [13] [14]

References [1]

[2]

[3]

[4]

[5]

[6] [7]

[8]

[9]

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, IEEE, pp. 27-37, Los Alamitos, 1998. V. Ambriola, R. Conradi, and A. Fuggetta, “Assessing process-centered software engineering environments”, ACM Transactions on Software Engineering and Methodology, vol. 6, 1997. L. Aversano, S. Betti, A. De Lucia, and S. Stefanucci, “Introducing Workflow Management in Software Maintenance Processes”, Proceedings of Int. Conference on Software Maintenance, Florence, Italy, IEEE CS Press, 2001, pp. 441-450. M. Baentsch, G. Molter, P. Sturm: “WebMake: Integrating Distributed Software Development in a StructureEnhanced Web” in Proceedings of the 3th. International WWW Conference, Darmstadt, Germany, in special issue: Computer Networks and ISDN Systems, Vol. 27, No. 6, Elsevier Science, Amsterdam, Netherlands pp. 789-800, 1995. S. Bandinelli, A. Fuggetta and C. Ghezzi “Software Process Model Evolution in the SPADE Environment”, IEEE Transactions on Software Engineering, 19(12): 1128-1144, 1993 S. Bandinelli, E. Di Nitto, and A. Fuggetta, “Supporting cooperation in the SPADE-1 Environment,” IEEE Transactions on Software Engineering, vol. 22, 1996. W.R Bischofberger, T. Kofler, K.-U. Mätzlel, B. Schäffer “Computer Supported Cooperative Software Engineering with Beyond-Sniff” in Proceedings Software Engineering Environments (edited by: Verrall M.S.), IEEE CS Press, Los Alamitos, CA, pp. 135-143, 1995. L. Brothers , V. Sembugamoorthy, M. Muller “ICICLE Groupware for Code Inspection” in Proceedings of the 1990 ACM Conference on CSCW, ACM Press, Los Angeles, CA, pp. 169-181, 1990. J. Callahan, S. Ramakrishnan “Software Project Management and Measurement on the World-Wide-Web”

[15] [16]

[17]

in Proceedings, IEEE Fifth Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’96) - Workshop on Requirements Engineering for Networked Enterprises, Stanford, CA, 1996. D. Chan and K. Leung “A Workflow Vista of the Software Process” in Proceeding of the International Workshop on Database and Expert Systems Applciations, IEEE Press, 1997. G. Cugola and C. Ghezzi, “Software processes: a retrospective and a path to the future”, Software process Improvement and practice, vol. 4, pp. 101-123, 1998. V. Davidow, M. Malone The Virtual Organisation: Structuring and Revitalising the Corporation for the 21st Century, Burlingame Books, 1992. A. Fuggetta, “Software Process: A Roadmap”, The Future of Software Engineering, A. Finkelstein, Editor, ACM Press, 2000, pp. 25-34. N. Goldman, K. Narayanaswamy “Lazy Consistency – A Basis for Cooperative Software Development” in Proceedings of the 1992 ACM Conference on CSCW, ACM Press, Toronto, pp. 257-264, 1992. R.E. Kraut, L.A. Streeter “Coordination in Software Development,” Communication of ACM, Vol. 38 No. 3, ACM Press New York, pp. 69-81, March 1995. F. Maurer, B. Dellen, F. Bendeck, S. Goldmann, H. Holz, B. Kotting, and M. Schaaf, “Merging Project Planning and Web-Enabled Dynamic Workflow Technologies”, IEEE Internet Computing, vol. 5, no. 3, 2000, pp. 65-74. L. Osterweil “Software Processes are Software too”, in Proceedings of the 9th. International Conference on Software Engineering, ACM Press, New York, N.Y., pp. 2-13, 1987.


Generalised environment for process management in ... - IEEE Xplore

Generalised environment for process management in ... - IEEE Xplore

Suggest Documents