Application 2 – Annotated Bibliography

tchyar

SUPPORTINGPROJECTMANAGEMENTWITHFINE-GRAINEDARTEFACTMANAGEMENTINADAMS.pdf

Home >Information Systems homework help >Application 2 – Annotated Bibliography

International Journal of Computers and Applications. Vol. 31, No. 3, S009

SUPPORTING PROJECT MANAGEMENT WITH FINE-GRAINED ARTEFACT

MANAGEMENT IN ADAMS F. Fasano* and R. Oliveto'^

Abstract

We present the project management support in ADAMS (ADvanced .Artefact Management System), a web-based system that integrates project management features such as resource allocation and process control and artefact management features, such as coordination of cooperative workers and artefact versioning, as well as context- awareness and artefact traceability features. We also present an evaluation of the usefulness and adequacy of the functionalities that ADAMS provides to the project managed. This evaluation has been conducted during the last 3 years with Master students attending a course of Software Project Management at the University of Salerno.

Key Words

Software project management, communication and coordination, product-oriented WBS

1. I n t r o d u c t i o n

The benefits of adopting tools to support project man- agement is widely recognised. Regarding the IT indus- try, Gartner Research estimates that 75% of large projects that use a project management tool will succeed, while the same percentage of projects whose manager do not use an information system to manage the project, will fail I' One of the issues to deal witli during the maiiage-

itirjit of a software project regards the communication and coordination of cooperative workers. Projects have been defined aíí "collective, purposeful activities ba.sed upon the development of common understanding and interpretation of means and ends" [2]. This definition underlines the need for project management information systems that support not only the planning and sclieduling activities of t he Project Manager, but the entire software lifecycle, pro- viding shared workspaces, high con text-awareness features, and reasoning support tools.

* Member, IEEE - STAT Dept. - University of Mouse. C.da Fonte Lappone, 86090 Pesche (IS), Italy; e-mail: [email protected]

*• Member, IEEE DMI - University of Salerno, Via Ponte don Melillo, 84084 Fisciano, Italy; e-mail: [email protected]

(paper no. 202-2961)

In this paper, we present the project management support provided by ADAMS (ADvanced Artefact Man- agement System), an extensible system that integrates project management features such as resource allocation and process control and artefact management features, such as coordination of cooperative workers and artefact versioning. as well ay context-awareness and traceability features. Besides influencing the project success in terms of respected budget, schedule, and specification, a success- fnl project management system should have individual im- pacts in terms of satisfied and effective use [3]. To this aim, we also present an evaluation of the perceived usefulness and adequacy of the project management functionalities of ADAMS conducted at the University of Salerno. The rest of the paper is organised as follows.

2. R e l a t e d Work

Managing a project, especially in a distributed setting, is a complex task that should be supported by a CASE tool. Examples of such tools have been proposed to ad- dress specific tasks or phases of the management process. An example is provided by project planning tools, such as Microsoft's MS Project,' that help the Project Managers to focus on scheduling and resource-balancing problems. However, the support provided by these tools to team management is lacking. Moreover, they do not provide coordination and communication mechanisms an well as context-awareness within the project team. Another limi- tation is the lack of management of the information flows. Primavera P6^ is a commercial tool that enables project management allowing planning and scheduling manage- ment, also managing resources and collaboration among them.

Another research area is represented by Process Sup- port Systems (PSSs) [4-6¡, including Workflow Manage- ment Systems (WfMSs) [7-11] and Process-centered Soft- ware Engineering Environments (PSEEs) [12-15]. These tools aim at supporting the coordination of software de- velopment jK-tivities through process modelling and enact- ment. Despite the advances made in the field, most of

' http://office.microsoft. com/project ^ http://www.primavpra.com

145

the solution proposed have not gained wide acceptance in the industry because the Process Description Languages (PDLs) they propose for the modelling of business pro- cesses are too complicated to understand and manipulate for many practitioners. Most PSSs do not support the de- viations from the process model when unforeseen situations (frequently) happen and even when such a support is pro- vided, it is difficult to model and manage in advance every possible exceptional situations. Also, they lack integration with configuration management systems [4]. Recent PSSs provide a greater support to context-awareness, by inte- grating communication toots and notification mechanisms to make developers aware about events occurred during the activities [4-6, 15, 16].

Both project planning tools and PSSs. generally, do not offer an adequate support to artefa<:t traceability and, as a consequence, handling changes is difficult. Even when traceability is supported, the traceability infrastructure fails during the system evolution [17]. in PSSs, depen- dencies between artefacts can be derived from the data flow links between activities but relationships between the involved artefacts is not directly stored and maintained.

Another area is represented by online project spaces, which use the Internet to provide access to project doc- uments such as requirements, designs, and source code. However, this approach is passive, forcing software develop- ment teams to obtain information on their own behalf [6].

Our approach Is closer to MILOS [6] (Minimally In- vasive Long-term Organizational Support) a web-based process support system that allows the specification of liierarchical, object-oriented product models. In MILOS, Project Managers define tasks and decompose them into smaller subtasks, scheduling them by using a web-based user interface. For each task, a user is able to define ex- pected outputs that can be used as inputs for other tasks. Differently to standard workflow engines, MILOS allows changes and redefinitions of the information fiow, notifying team members affected by those changes and updating the workflow engine accordingly.

With respect to MILOS, we provide a specific support to the Project Manager that goes beyond the definition of a product-oriented work breakdown structure (WBS), allowing management of the project teams and follow- ing the entire lifecycle of each artefact as well an for the project. Moreover, we pose a great emphiisis on com- munication, providing several mechanisms to improve the context-awareness within the project.

Section 2 presents related work. Section 3 presents an overview of ADAMS, while Section 4 describes the main functionalities of ADAMS, focusing of the support for project management. Section 5 presents the roisults of an evaluation conducted to assess the project management support of the system, while Section 6 discusses concluding remarks.

3. A D A M S Overview

ADAMS is an artefact-based process support system. It enables the definition of a process in terms of the artefacts to be produced and the relations among them, supporting

a more agile software process management than activity- based PSSs, in particular concerning the deviations from the process model.

ADAMS has a web-based architecture. The system is decomposed into several subsystems. In this paper, we fo- cus on the project management functionalities of ADAMS. A description of the other functionalities provided by the system can be found in [18].

4. P r o j e c t M a n a g e m e n t Support in A D A M S

In this section, we provide a brief overview of each subsys- tem, highlighting the support that each of them provides to the Project Manager during the software lifecycle.

4.1 Artefact Management Subsystem

ADAMS provides a flexible fine-grained artefact manage- ment to better manage most of the documents produced during software development having a well-defined hierar- chic structure. To this aim, artefacts in ADAMS can either be an atomic entity (associated to one or more files) or they can be composed of an arbitrary number of atomic and further composite artefacts. The choice of the granu- larity level for each artefact is ¡eft to the Project Manager. This approach gives the possibility to define more detailed traceability links. In fact, the .software engineer is enabled to specify traceability links between entities within the same document, as well as between parts of two different documents, resulting in a more precise impact analysis.

Project Managers can use the composition mechanism to define the artefact-based WBS of the project (Fig. 1). In ADAMS, the composition of artefacts is realized by defin- ing special types of traceability link between the composite artefact and each of the contained artefacts. The definition of artefact hierarchies in ADAMS is extremely flexible al- lowing the manager to adapt the WBS during the software process to face up unforeseen situations. This gives the flexibility necessary in a highly changeable and evolving context, as the software development. The granularity of the decomposition can also be adapted according to the growing document size.

The system notifies when a manually recomposed arte- fact is out of sync with respect to the content of the arte- facts it is composed of by decorating it with an exclama- tion mark (Fig. 1). This information provides context- awareness to the Project Manager, who can visually iden- tify which parts of a document have been changed from the last rebuild. Such information can be valuable, for example, when scheduling inspections. More information on the flne-grained management of software artefacts in ADAMS can be found in [18],

4.2 Traceability M a n a g e m e n t S u b s y s t e m

Software artefact traceability is the ability to describe and follow the life of an artefact developed during the software lifecycle in both forward and backward directions [19]. ADAMS support to traceability is mainly provided specifying traceability links between pairs of artefacts.

1 4 6

March 1 9 * . 2007

Evaluation

! RAD 9 IndeK 9 Introduction ^ Current System

a !. Proposed System 9 Overview

, : 9 Functional Requirements I : ~ 9 Nonfunctional Requirements ' S ,f System Models

: 9 Actors j j" 9 Scenarios

j- 9 Use cases - actors S t Use cases - schema ; ^ Artefact Visualisation j I Subtree Opening I 9 Artefact Operations i i- 9 Hierarchical Link Creation

' 9 Show / Hide Artefact Details f Data dictionary I Class Diagram

S 9 Dynamic Models 9 User Interface ^ Glossary I SDD 9 Index

^ Current System 9 System Architecture 9 Subsystem Services 9 Acknowledgements A Glossary

J l r4ew Artefact

^3 IrHpectni Prqjea

i S UOtodets

Traceabètv tries •

Drag Option

r Drag befofc

Drag Into

Drag Aft«

Copy

Figure 1. Hierarchical visualization in ADAMS.

Traceability links can be organized in a traceability graph where the artefacts are identified by nodes and the traceability links are represented with edges of the graph. This graph can be visualized by the Project Manager and browsed to look at the state of previously developed arte- facts, to download latest artefact versions, or to subscribe events on specific artefacts to receive notifications concern- ing their development.

Traceability information can snpport the Project Man- ager during the evaluation of the requirements coverage: in case a traceability path cannot be found between a re- quirement and the source code, then the requirement is unimplemented. The same analysis can be done at any phase of the software lifecycle (e.g., to know whether a use case is traced onto a sequence diagram). Finally, for change management traceability is fundamental to identify the estimated impact set.

ADAMS integrates a traceability link recovery tool based on an Inforiuation Retrieval technique, namely La- tent Semantic Indexing [20], that proposes candidate trace- ability links and highlights possible incorrect traceabil- ity links [21]. The support provided by this tool to the Project, Managers is twofold: on the one hand, it reduces the effort required to identify traceability links; on the other hand, by highlighting possible incorrect traceability links, it supports quality assurance. Indeed, warning links are proposed to highlight artefacts traced onto each other whose similarity value is lower than a specified threshold. More details on the traceability management and recovery functionalities of ADAMS can be found in [21].

4.3 A d m i n i s t r a t i o n S u b s y s t e m

The Administration Subsystem provides administrative functionalities. Such functionalities allow the system ad- ministrator to define the types of artefact managed by the system, define projects and resources at system level. Moreover, the iidministration subsystem is used by the Project Manager in the early phases of the project, when he/she composes the project team selecting human re-

4.4 P r o j e c t M a n a g e m e n t S u b s y s t e m

The Project Management Subsystem supports the Project Manager during the software life cycle, by allowing him/her to define the WBS and allocate and dea!loc:ate human resources to each artefact. Access permission management as well as creation, updating, and deletion permission can be specified for each artefact. The system also supports role-based access control, allowing the manager to associate permissions to roles and roles to resources.

4.5 R a t i o n a l e M a n a g e m e n t S u b s y s t e m

The Rationale Management Subsystem manages rationale information collected during the software process. Ra- tionale information is a special type of artefact produced during the software development process. The subsystem relies on the revision control subsystem and the traceabitity management subsystem to maintain versions and relations among rationale items. This allows to maintain all the ver- sions produced for a rationale element, to browse across the

1 4 7

dependences among the current elements version as well as their older versions. Having rationale within the same system used to manage design artefacts, gives the Project Manager an integrated view above all the elements involved into the development process, avoiding the overhead neces- sary to switch between the rationale and the development context. Moreover, links can be traced between rationale items dealing with an issue, to the related requirements as well as to the implementing code classes. This also gives the possibility to propagate event notifications between rationale end design artefacts allowing software engineers involved in an issue resolution to be informed whenever related artefacts change and vice versa.

4.6 C o o p e r a t i v e D e v e l o p m e n t M a n a g e m e n t Sub- s y s t e m

The support for cooperation is offered by ADAMS through typical features of a configuration management system. ADAMS enables groups of people to work on the same artefact (depending on the required roles) adopting a lock- based policy or concurrently, using branching and merging. At any time it is possible to see the people who are working on an artefact.

Some tools have been integrated to support distributed development and enhance the context-awareness: STEVE [22], a collaborative tool for UML diagrams modelling and WAIT [23], a cooperative tool for distributed inspection meeting.

4.7 Event Notification M a n a g e m e n t S u b s y s t e m

One of the most common problems faced by cooperative environments and distributed development teams concerns the context-awareness. Context-awareness in ADAMS is mainly supported through event notifications: software engineers working on an artefact are notified when some- thing relevant occurs on the artefact. Besides providing a solution to the isolation problem for resources working on the same artefact in different workspaces, event notifi- cation can be used by the Project Manager to audit the artefact being aware of the project work in progress. As a project is composed of a huge number of artefacts, some of which considered irrelevant by the Project Manager, ADAMS enables them to subscribe events they would like to be notified about. Events concerning the production of new versions of an artefact are also propagated through the traceability layer to the artefacts depending directly or indirectly on it.

ADAMS provides direct communication mechanisms between software engineers, such as e-mails. Moreover, cooperation between software engineers during iterative software processes is supported through the possibility of sending feedbacks concerning problems found in a software artefact. Project Manager can use feedbacks to improve quaiity (by scheduling a review for the involved artefact) as well as to evaluate the performance of the team.

5. Evaluation

In this section, an evaluation of the support that ADAMS provides to Project Managers is reported. In particular, we present the experience of the tool as process support system and document management system within a university environment. A discussion of threats to validity is also presented.

5.1 E x p e r i m e n t a t i o n Definition and C o n t e x t

The goal of the experimentation was to analyse the support given by ADAMS during the software development. The quality focus was ensuing high support to management of a software development team, while the perspective wa-s of Project Managers, evaluating the possibility of adopting such a tool within their own organization.

The study was executed at the University of Salerno from 15 April 2005 to 30 July 2007. In particular, ADAMS has been experimented within the projects conducted by students of the Software Engineering courses of the Com- puter Science program at the University of Salerno (Italy). The experience involved 249 students allocated in 27 soft- ware projects. Each project team included between 6 and 8 undergraduate students with development roles (i.e., team members) and two Master students with roles of project and quality management, respectively (in some cases, the Project Manager also played tfie quality management role). Team members and managers were Bachelor students (sec- ond year B.Sc.) attending the Software Engineering course and Master students (second year M,Sc.) attending a Software Project Management course, respectively. All students were from the same class with a comparable level of background.

The Project Manager waa responsible for coordinat- ing the project, defining the project schedule, organizing project meetings, collecting process metrics, and allocating human resources to tasks. The Project and Quality man- agers were also in charge of building the traceability matrix for the software artefacts developed in their project.

Finally, the artefact repositories have a small/medium size, but they represent a good benchmark as they cover many different projects with different goals.

5.2 E x p e r i m e n t a t i o n Design

Three different experimentations were conducted: a first evaluation was conducted in 2005 and involved about 156 students allocated on IT projects. A second evaluation involving 32 students allocated on 4 software projects has been conducted in 2006 and, finally, a third experimenta- tion involving 61 students allocated on 6 software projects has been conducted in 2007.

With respect to the focus of this article, the uiain difference between the first experimentation and the last two experimentations was the improvement of the fine- grained nuinagement functionality that resulted in a better support to the WBS management. In fart, during the first experimentation, tiie artefact composition was realized by specifying a stereotyped traceability link. Successively,

1 4 8

compositional and traceability links haa been separated and managed appropriately, thus enabling specific support to the management of composed artefacts. To this aim, in the next sections, we distinguish between the two versions of the system and group data concerning 2006 and 2007, referring to these two experimentatioriis â to the second evaluation period. At the end of the projects, students evaluated ADAMS through a questionnaire.

5.3 E x p e r i m e n t a t i o n R e s u l t s

During the first experimentation period, the average num- ber of artefacts produced within each project was 191 (140 artefacts were produced for the smallest project and 325 artefacts for the largest project): on the average, for each artefact nearly 7 team members were allocated to the same artefact, thus having an artefact team size very close to the entire project team size (9 is the average project team size}. This was due to the fact that the functionalities to manage a fine-grained WBS were limited. Thi.s led to a coarser-grain W'BS definition, causing many workers to be allocated to the same artefact. This is particularly evident for the RAD document (where all resources were involved in) whose decomposition wfis low with respect to the number of contained requirements, use cases, and diagrams.

During the second evaluation period, the average num- ber of artefacts produced within each project was 548 (167 artefacts were produced for the smallest project and 1100 artefacts for the largest project). In this caae, we can notice a small artefact team size (less than 2, on average). This results in a more precise distribution of the artefacts to produce among the project team members especially for highly decomposable artefacts (RAD document was de- composed, on average, in 218 subartefacts). See Tables 1 and 2 for details.

The distribution of answers for each question of the survey questionnaire are reported in Table .'Î. The table reports the questions and the distribution of answers for each question and for each period of experimentation, i.e., 2005 and 2006-2007. Aggregate data are not reported because the system has been changed between the two experimentation periods, in general, we noticed that the user's perception of the tool usefulness has globally in- cremented during the second experimentation period. In particular, the overall perceived usefulness of ADAMS rose from 75.00% to 86.90% (see question Ql). R.egarding the evaluation of the usability for the main functionalities of ADAMS, the project and resource management function- alities are considered adequate by about 90% of the users (see questions Q2 and Q5) and intuitive by over 80% and 90% of the users, respectively (see questions Q3 and Q6).

Table 1 Projects of the First Evaluation Period

Project

1-2

1-3

1-4

1-5

l - ( i

1-7

1-8

1-9

1-10

1-11

M 2

1-13

1-14

1-15

1-16

1-17

Average

Project Team Size

9.18

Artefacts

172

189

151

192

152

167

198

150

201

325

140

244

213

183

163

196

215

191.24

Average Artefact Team Size

9.92

7.85

6.01

2.73

6.00

4.97

9.21

5.64

3.53

3.13

5.45

9.10

6.05

2.49

5.82

3.32

4.79

5.65

RAD

;Í9

30.88

SDD

26.41

ODD

30.00

Test

104

59.47

Code

:Î

2.06

Management Documents

150

42.41

1 4 9

Table 2 Projects of the Second Evaluation Period

Project

2-1

2-2

2-3

2-4

2-5

2-6

2-7

2-8

2-9

2-10

Average

Project Team Size

9.3

Artefacts

3S6

600

581

421

1100

167

838

678

260

448

547.9

Average Artefact Team Size

2.49

1.99

2.09

1.73

1.87

1.31

1.15

1.12

1.92

1.18

1.68

RAD

201

403

384

157

297

213

158

137

164

217.9

SDD

23.6

ODD

34.3

Test

268

105

116

Code

149

214

64.7

Management Documents

257

357

245

100

134.4

Table 3 Survey Questionnaire Distribution of Answers

Question

Ql. Was ADAMS useful during the software development process?

Q2. Did Project Management functionalities fit your needs?

Q3. Are Project Management functionalities intuitive?

Q4. Was the functionality to visualize the graph composed by the artefat'ts of the project and the traceabiHty links useful?

Q5. Did Resource Management functionalities fit your needs?

Q6. Are Resource Management functionalities intuitive?

Q7. Was the functionality to view users allocated to a specific artefact useful?

Q8. Were Project and Resource Management performances satisfactory?

2005

Yes

75.00

93.75

56.25

87.50

93.75

80.58

81.25

25.00

6.25

43.75

12.50

6.25

19.42

18.75

2006-2007

Yes

86.90

90.00

80.00

90.00

84.52

90.00

13.10

10.00

20,00

10.00

15.48

10.00

The usefulness of specific tools, sucii as the tool for graph- based visualization of the artefacts, rose from 56.25% to 90.00%. This was a consequence of the improvement of fine-grained management functionality that resulted in a finer definition of the WBS. Finally, the management subsystems performance were considered satisfactory by over 80% of the users (see question Q8).

5.4 Threats to Validity

During the experience, we tried to simulate a real-working environment, although we used undergraduate and Mas- ter students. In particular, managers have been selected among last-year Master students, so they have a very good analysis, development and programming experience, and they are not far from junior industry analysts. When comparing the quality of the final projects with respect to

historically repository of similar project conducted by stu- dents of the same courses, a significantly better judgment has resulted for teams coordinated by a manager using the system. Moreover, differently from historical projects, all the projects used in this evaluation were on schedule. We consider this a valuable result, especially if the manage- ment experience of the subject involved in the evaluation is questioned. Unfortunately, in a real-working environ- ment there are other pressures, so the results cannot be completely generalized to the industrial context and then the experience should be replicated with practitioners.

6. Conclusion

In this paper, we have presented the project management support in ADAMS, an artefact-based process support system that integrates project management and artefact

150

management features. Besides coordinating distributed software engineers working on the same artefact and pro- viding versioning facilities like configuration management systems, ADAMS also supports context-awareness through event subscription and notification and communication tools. The Project Manager defines the WBS in terms of the artefacts to be produced by each team member and uses traceability links to managers dependences among them, Traceability management is also used to analyze the requirements coverage as well an to propagate events con- cerning project artefacts, thus also increasing the context- awareness in the project. The traceability recovery tool, is also a valid support for the identification of quality problems within project artefacts.

An evaluation of the support provided by ADAMS to the Project Manager has also been reported. The evalua- tion highlighted how the use of the fine-grained product- oriented WBS influenced the distribution of work among the project team allowing a better control on the project evolution. The results from an evaluation questionnaire are encouraging, as there is a generally acknowledged use- fulness and adequacy of ADAMS project and resource management functionalities.

Acknowledgement

The authors would like to thank Professor Andrea De Lucia from the University of Salerno (Italy) for the continuous and constructive comments. This research has been supported by the project METAMORPHOS (http://www.sesa.dmi.unisa.it/metamorphos) funded by MiUR (Ministero deirUniversità e della Ricerca) under grant PRIN-2006-20Ü6098097.

References

[I] M. Light, B. R.üsser, &¿ S. Hayward, Realizing the Bene- fits of Projert and Portfolio Management, Cariner Research, Document Number G00125673, 2005, 1-31.

[2] P, Jackson fc J. Klobas, Building knowledge in projects: A practical application of social constructivism to information systems development, tntemattonal Journal of Project Man- agement, 26(4), 2008, 329-337

[3] L. Raymond &: F. Bergeron, Project management information systems: An empirical study of their impact on project man- agers and project success, Intern.ational Journal of Project Management, 26{2), 2008, 213-220.

[4j L. Aversano, A. De Lucia, M, Gaeta, P. Ritrovato, S. St.efanucci, & M.L, Villani, Managing coordination and cooperation in distributed software processes: the GENESIS environment, Soßware Process: Improvement and Practice, 5(4), 2004, 239- 263.

[5| G. Gugola, Tolerating deviations in process support systems via flexible enactment of process models, IEEE lYansactions on Soßware Engineering, 24(11), ¡998. 982 1001,

[6] F. Maurer, B. Dellen, F. Bendeck, S. Goldmanii, H. Holz, B. Kötting, & M. Schaaf, Merging project planning and web- enabled dynamic workflow for software development, IEEE Internet Computing, 4(3), 2000. 65-74.

[7| Ci. Alonst) & t'. Mohan, Workflow management systems: The next generation of distributed procesing tools, Jajodia Â: L. Kerschberg (Eds.), Advanced transaction models and archi- tectures (Norwell, MA: Kluwer Academic, 1997), chapter 1, 35-62.

[8] P. Grefen, B- Pernici, í¿ G. Sánchez (Eds.), Database support for workflow m,anageTneni: The WtDE project (Norwell, MA: Kkiwer Academic Publishers, 1999).

[9| D. Georgakopoulos, H. Hornick, & A. Sheth, An overview of workflow management: from process modelling to workflow automation infrastructure. Distributed and Parallel Databases 5(2), 1995. 119-153.

[10] Workflow Management Coalition, Workflow Management Coalition Interface I: Process Definition Interchange Process Model, Document no. WFMC-TC-1016-P, 1999, available from http://www,aiim.erg/wfmc/standards/docs/if 19910vll.pdf.

[11] V, Ambriola, R. Conradi, & A. Fiiggetta, Assessing Process- Centered Software Engineering Environments, ACM TYansac- tion on Soßware Engineering and Methodology, 0(3), 1998, 283-328.

[12) S. Bandinelli. E.D. Nitto, & A. Fiiggetta, Supporting coop- eration in the SPADE-1 environment, IEEE Transactions on Software Engineering. 28(12), ¡996, 841-865.

[13] S- Bandinelli, A. Fuggetta, C. Ghezzi, & L. Lavazza, SPADE: An environment for software process analysis, design, and enactment, in Soßware process modelling and technology (A. Finkelstein, J. Kramer, & B, Nuseibeh, (Eds.)) (Research Studies Press Limited. John Wiley A; Sons. 1994),

[14] J.C. Griindy, M.D. Apperley, J,Ci, Hosking, & W.B, Mugridge, A decentralized architecture for software process modeling and enactment, IEEE Internet Computing, 2(5), 1998, 53-62.

[15] C- Cugola, E.D. Nitto, & A. Fuggetta, The JEDl event-based infrastructure and its application to the development of the OPSS WFMS, IEEE Transactions on Soßwarv Engineering, S7(9), 2001, 827-850.

[16] J. Cleland-Huang, C.K. Chang. & M. Christensen. Event- based traceability for managing evolutionary change, IEEE Transaction on Soflware Engineering, 29(9), 2003, 796-810.

[17] F. Fasano, Fine-grained management of Süßware artefacts, Ph.D. Thesis, University of Salerno, available online from: http://sesa.dmi.unisa,it/thesis/fasano.pdf

[18] O. Gotel & A. Finkelstein, An analysis of the requirements traceability problem, in Proc. ¡st International Conference on Requirements Engineering, C'olorado Springs. CO. i994, 94-101.

[19] S. Deerwester. S.T. Dumais, G.W. Birnas, T.K. Lan-dauer, & R. Harshman, Indexing by latent semantic analysis, Jourv.al of the American Society for Information Science, ^ / ( l ) . 1990, 391^07.

[20] A. De Lucia. F. P'asano. R. Oliveto, &¿ G. Tortora, Recovering traceabitity links in software artefact management sy.ftems using information retrieval methods. ACM Transaction.^ on Software Engineering and Methodology. ¡6'{4), Article no. 13. 2007-

[21] A. De Lucia, F. Fasano, G. Scanniello, &¿ G. Tortora, ÍMihancing collaborative synchronous uml modelling witli fine-grained versioning of software artefacts. Journal of Visual Languages & Computing, }8{5), 2007, 492-503.

[22] A. De Lucia, F. Fasano, G. Scanniello, S¿ G. Tortora, .'Vssessing the effectiveness of a distributed method for code inspection: A controlled experiment. Proc. 2nd International Conference on Global Soßware Engineering, Munich, Germany. 2007, 252— 261.

Biographies

Faufiio Fasano received his Lau- rea degree cum laude, in Com- puter Science from the University of Salerno, Italy, in 2003, and his Ph.D. degree in Computer Science from the University of Salerno, Italy, in 2007. He is currently an assistant professor at the Uni- versity of Molise, Italy where he teaches Software Engineering and Operating Systems. His research interests include configuration

management, global software development, traceability

1 5 1

management, software maintenance, rense, reengineering, program comprehension, workflow management, document management, visual languages, and empirical software engineering. He is a member of the IEEE, the IEEE Computer Society, and the ACM.

management, software maintenance, reuse, reengineering, program comprehension, source code analysis, and empiri- cal software engineering. He is a member of the IEEE, the IEEE Computer Society, and the ACM.

Rocco Oliveto received his Lau- rea degree cum laude in Com- puter Science from the University of Salerno, Italy, in 2004, and his Ph.D. degree In Computer Science from the University of Salerno, Italy, in 2008. He is currently a research fellow at the University of Salerno. Italy and is a Contract Lecturer on Software Engineering and Programming Languages at the University of Molise, Italy. His

research interests include information retrieval, traceability

152