International Journal of Computers and Applications, Vol. 31, No. 3, 2009
SUPPORTING PROJECT MANAGEMENT WITH FINE-GRAINED ARTEFACT MANAGEMENT IN ADAMS F. Fasano∗ and R. Oliveto∗∗
Key Words
In this paper, we present the project management support provided by ADAMS (ADvanced Artefact Management 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 as context-awareness and traceability features. Besides influencing the project success in terms of respected budget, schedule, and specification, a successful project management system should have individual impacts 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.
Software project management, communication and coordination,
2. Related Work
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 contextawareness 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.
product-oriented WBS
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 address specific tasks or phases of the management process. An example is provided by project planning tools, such as Microsoft’s MS Project,1 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 as well as context-awareness within the project team. Another limitation is the lack of management of the information flows. Primavera P62 is a commercial tool that enables project management allowing planning and scheduling management, also managing resources and collaboration among them. Another research area is represented by Process Support Systems (PSSs) [4–6], including Workflow Management Systems (WfMSs) [7–11] and Process-centered Software Engineering Environments (PSEEs) [12–15]. These tools aim at supporting the coordination of software development activities through process modelling and enactment. Despite the advances made in the field, most of
1. Introduction The benefits of adopting tools to support project management is widely recognised. Regarding the IT industry, 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 [1]. One of the issues to deal with during the management of a software project regards the communication and coordination of cooperative workers. Projects have been defined as “collective, purposeful activities based 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 scheduling activities of the Project Manager, but the entire software lifecycle, providing shared workspaces, high context-awareness features, and reasoning support tools. ∗
Member, IEEE – STAT Dept. – University of Molise, 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)
1 2
145
http://office.microsoft.com/project http://www.primavera.com
the solution proposed have not gained wide acceptance in the industry because the Process Description Languages (PDLs) they propose for the modelling of business processes are too complicated to understand and manipulate for many practitioners. Most PSSs do not support the deviations from the process model when unforeseen situations (frequently) happen and even when such a support is provided, 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 integrating communication tools 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 artefact 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, dependencies 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 documents such as requirements, designs, and source code. However, this approach is passive, forcing software development teams to obtain information on their own behalf [6]. Our approach is closer to MILOS [6] (Minimally Invasive Long-term Organizational Support) a web-based process support system that allows the specification of hierarchical, 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 expected outputs that can be used as inputs for other tasks. Differently to standard workflow engines, MILOS allows changes and redefinitions of the information flow, 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 following the entire lifecycle of each artefact as well as for the project. Moreover, we pose a great emphasis on communication, 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 results of an evaluation conducted to assess the project management support of the system, while Section 6 discusses concluding remarks.
a more agile software process management than activitybased 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 focus on the project management functionalities of ADAMS. A description of the other functionalities provided by the system can be found in [18].
3. ADAMS Overview
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.
4. Project Management Support in ADAMS In this section, we provide a brief overview of each subsystem, 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 management to better manage most of the documents produced during software development having a well-defined hierarchic 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 granularity level for each artefact is left 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 defining 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 allowing 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 artefact is out of sync with respect to the content of the artefacts it is composed of by decorating it with an exclamation mark (Fig. 1). This information provides contextawareness to the Project Manager, who can visually identify 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 fine-grained management of software artefacts in ADAMS can be found in [18]. 4.2 Traceability Management Subsystem
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 146
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 artefacts, to download latest artefact versions, or to subscribe events on specific artefacts to receive notifications concerning their development.
4.3 Administration Subsystem The Administration Subsystem provides administrative functionalities. Such functionalities allow the system administrator to define the types of artefact managed by the system, define projects and resources at system level. Moreover, the administration subsystem is used by the Project Manager in the early phases of the project, when he/she composes the project team selecting human resources.
Traceability information can support the Project Manager during the evaluation of the requirements coverage: in case a traceability path cannot be found between a requirement 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.
4.4 Project Management Subsystem The Project Management Subsystem supports the Project Manager during the software life cycle, by allowing him/her to define the WBS and allocate and deallocate 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.
ADAMS integrates a traceability link recovery tool based on an Information Retrieval technique, namely Latent Semantic Indexing [20], that proposes candidate traceability links and highlights possible incorrect traceability 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.5 Rationale Management Subsystem The Rationale Management Subsystem manages rationale information collected during the software process. Rationale information is a special type of artefact produced during the software development process. The subsystem relies on the revision control subsystem and the traceability management subsystem to maintain versions and relations among rationale items. This allows to maintain all the versions produced for a rationale element, to browse across the 147
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 necessary 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.
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 Experimentation Definition and Context The goal of the experimentation was to analyze 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 was 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 Computer Science program at the University of Salerno (Italy). The experience involved 249 students allocated in 27 software 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 the quality management role). Team members and managers were Bachelor students (second 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 was responsible for coordinating the project, defining the project schedule, organizing project meetings, collecting process metrics, and allocating human resources to tasks. The Project and Quality managers 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.
4.6 Cooperative Development Management Subsystem 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 lockbased 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 Management Subsystem 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 something relevant occurs on the artefact. Besides providing a solution to the isolation problem for resources working on the same artefact in different workspaces, event notification 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 quality (by scheduling a review for the involved artefact) as well as to evaluate the performance of the team.
5.2 Experimentation Design Three different experimentations were conducted: a first evaluation was conducted in 2005 and involved about 156 students allocated on 17 projects. A second evaluation involving 32 students allocated on 4 software projects has been conducted in 2006 and, finally, a third experimentation involving 61 students allocated on 6 software projects has been conducted in 2007. With respect to the focus of this article, the main difference between the first experimentation and the last two experimentations was the improvement of the finegrained management functionality that resulted in a better support to the WBS management. In fact, during the first experimentation, the artefact composition was realized by specifying a stereotyped traceability link. Successively, 148
compositional and traceability links has 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 experimentations as to the second evaluation period. At the end of the projects, students evaluated ADAMS through a questionnaire.
During the second evaluation period, the average number 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 case, 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 decomposed, 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 3. 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 incremented during the second experimentation period. In particular, the overall perceived usefulness of ADAMS rose from 75.00% to 86.90% (see question Q1). Regarding the evaluation of the usability for the main functionalities of ADAMS, the project and resource management functionalities 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).
5.3 Experimentation Results During the first experimentation period, the average number 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. This led to a coarser-grain WBS 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 was low with respect to the number of contained requirements, use cases, and diagrams.
Table 1 Projects of the First Evaluation Period Project Project Team Size Artefacts Average Artefact Team Size RAD SDD ODD
Test
Code Management Documents
1-1
10
172
9.92
48
24
18
54
3
25
1-2
10
189
7.85
30
35
42
45
3
34
1-3
10
151
6.01
24
24
37
31
3
32
1-4
9
192
2.73
31
27
32
72
2
28
1-5
10
152
6.00
24
30
45
31
1
21
1-6
9
167
4.97
27
16
22
71
3
28
1-7
9
198
9.21
32
21
24
74
2
45
1-8
9
150
5.64
24
29
44
44
3
6
1-9
8
201
3.53
32
33
38
24
2
72
1-10
8
325
3.13
52
33
23
65
2
150
1-11
10
140
5.45
22
22
37
27
3
29
1-12
10
244
9.10
39
27
25
79
1
73
1-13
7
213
6.05
29
22
15
104
1
42
1-14
10
183
2.49
29
24
31
79
2
18
1-15
8
163
5.82
26
19
26
73
1
18
1-16
10
196
3.32
31
22
25
76
1
41
1-17
9
215
4.79
25
41
26
62
2
59
Average
9.18
191.24
5.65
30.88 26.41 30.00 149
59.47 2.06
42.41
Table 2 Projects of the Second Evaluation Period Project
Project Artefacts Average Artefact RAD SDD ODD Test Code Management Team Size Team Size Documents
2-1
10
386
2.49
201
12
44
31
43
55
2-2
7
600
1.99
403
18
16
37
36
90
2-3
7
581
2.09
384
20
27
37
39
74
2-4
8
421
1.73
157
12
1
52 149
50
2-5
16
1100
1.87
297
16
48
268 214
257
2-6
9
167
1.31
65
15
10
26
1
50
2-7
9
838
1.15
213
32
69
105
62
357
2-8
9
678
1.12
158
27
36
116
96
245
2-9
9
260
1.92
137
12
7
1
3
100
2-10
9
448
1.18
164
72
85
57
4
66
Average
9.3
547.9
1.68
217.9 23.6
34.3
73
64.7
134.4
Table 3 Survey Questionnaire Distribution of Answers Question
2005 Yes
No
2006–2007 Yes
No
Q1. Was ADAMS useful during the software development process?
75.00 25.00 86.90 13.10
Q2. Did Project Management functionalities fit your needs?
93.75
6.25 90.00 10.00
Q3. Are Project Management functionalities intuitive?
93.75
6.25 80.00 20.00
Q4. Was the functionality to visualize the graph composed by the artefacts of 56.25 43.75 90.00 10.00 the project and the traceability links useful? Q5. Did Resource Management functionalities fit your needs?
87.50 12.50 90.00 10.00
Q6. Are Resource Management functionalities intuitive?
93.75
6.25 90.00 10.00
Q7. Was the functionality to view users allocated to a specific artefact useful? 80.58 19.42 84.52 15.48 Q8. Were Project and Resource Management performances satisfactory? The usefulness of specific tools, such as the tool for graphbased 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).
81.25 18.75 90.00 10.00
historically repository of similar project conducted by students 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 management experience of the subject involved in the evaluation is questioned. Unfortunately, in a real-working environment there are other pressures, so the results cannot be completely generalized to the industrial context and then the experience should be replicated with practitioners.
5.4 Threats to Validity During the experience, we tried to simulate a real-working environment, although we used undergraduate and Master 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
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 providing 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 as to propagate events concerning project artefacts, thus also increasing the contextawareness 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 evaluation highlighted how the use of the fine-grained productoriented 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 usefulness and adequacy of ADAMS project and resource management functionalities.
[9] D. Georgakopoulos, H. Hornick, & A. Sheth, An overview of workflow management: from process modelling to workflow automation infrastructure, Distributed and Parallel Databases 3(2), 1995, 119–153. [10] Workflow Management Coalition, Workflow Management Coalition Interface 1: Process Definition Interchange Process Model, Document no. WFMC-TC-1016-P, 1999, available from http://www.aiim.org/wfmc/standards/docs/if19910v11.pdf. [11] V. Ambriola, R. Conradi, & A. Fuggetta, Assessing ProcessCentered Software Engineering Environments, ACM Transaction on Software Engineering and Methodology, 6(3), 1998, 283–328. [12] S. Bandinelli, E.D. Nitto, & A. Fuggetta, Supporting cooperation in the SPADE-1 environment, IEEE Transactions on Software Engineering, 22(12), 1996, 841–865. [13] S. Bandinelli, A. Fuggetta, C. Ghezzi, & L. Lavazza, SPADE: An environment for software process analysis, design, and enactment, in Software process modelling and technology (A. Finkelstein, J. Kramer, & B. Nuseibeh, (Eds.)) (Research Studies Press Limited, John Wiley & Sons, 1994). [14] J.C. Grundy, M.D. Apperley, J.G. Hosking, & W.B. Mugridge, A decentralized architecture for software process modeling and enactment, IEEE Internet Computing, 2(5), 1998, 53–62. [15] G. Cugola, E.D. Nitto, & A. Fuggetta, The JEDI event-based infrastructure and its application to the development of the OPSS WFMS, IEEE Transactions on Software Engineering, 27(9), 2001, 827–850. [16] J. Cleland-Huang, C.K. Chang, & M. Christensen, Eventbased traceability for managing evolutionary change, IEEE Transaction on Software Engineering, 29(9), 2003, 796–810. [17] F. Fasano, Fine-grained management of software 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. 1st International Conference on Requirements Engineering, Colorado Springs, CO, 1994, 94–101. [19] S. Deerwester, S.T. Dumais, G.W. Furnas, T.K. Lan-dauer, & R. Harshman, Indexing by latent semantic analysis, Journal of the American Society for Information Science, 41(1), 1990, 391–407. [20] A. De Lucia, F. Fasano, R. Oliveto, & G. Tortora, Recovering traceability links in software artefact management systems using information retrieval methods, ACM Transactions on Software Engineering and Methodology, 16(4), Article no. 13, 2007. [21] A. De Lucia, F. Fasano, G. Scanniello, & G. Tortora, Enhancing collaborative synchronous uml modelling with fine-grained versioning of software artefacts, Journal of Visual Languages & Computing, 18(5), 2007, 492–503. [22] A. De Lucia, F. Fasano, G. Scanniello, & G. Tortora, Assessing the effectiveness of a distributed method for code inspection: A controlled experiment, Proc. 2nd International Conference on Global Software Engineering, Munich, Germany, 2007, 252– 261.
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 dell’Universit`a e della Ricerca) under grant PRIN-2006-2006098097. References [1] M. Light, B. Rosser, & S. Hayward, Realizing the Benefits of Project and Portfolio Management, Gartner Research, Document Number G00125673, 2005, 1–31. [2] P. Jackson & J. Klobas, Building knowledge in projects: A practical application of social constructivism to information systems development, International Journal of Project Management, 26(4), 2008, 329–337 [3] L. Raymond & F. Bergeron, Project management information systems: An empirical study of their impact on project managers and project success, International Journal of Project Management, 26(2), 2008, 213–220. [4] L. Aversano, A. De Lucia, M. Gaeta, P. Ritrovato, S. Stefanucci, & M.L. Villani, Managing coordination and cooperation in distributed software processes: the GENESIS environment, Software Process: Improvement and Practice, 9(4), 2004, 239– 263. [5] G. Cugola, Tolerating deviations in process support systems via flexible enactment of process models, IEEE Transactions on Software Engineering, 24(11), 1998, 982–1001. [6] F. Maurer, B. Dellen, F. Bendeck, S. Goldmann, H. Holz, B. K¨ otting, & M. Schaaf, Merging project planning and webenabled dynamic workflow for software development, IEEE Internet Computing, 4(3), 2000, 65–74. [7] G. Alonso & C. Mohan, Workflow management systems: The next generation of distributed procesing tools, Jajodia & L. Kerschberg (Eds.), Advanced transaction models and architectures (Norwell, MA: Kluwer Academic, 1997), chapter 1, 35–62. [8] P. Grefen, B. Pernici, & G. S´ anchez (Eds.), Database support for workflow management: The WIDE project (Norwell, MA: Kluwer Academic Publishers, 1999).
Biographies Fausto Fasano received his Laurea degree cum laude in Computer 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 University of Molise, Italy where he teaches Software Engineering and Operating Systems. His research interests include configuration management, global software development, traceability 151
management, software maintenance, reuse, reengineering, program comprehension, source code analysis, 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, workflow management, document management, visual languages, and empirical software engineering. He is a member of the IEEE, the IEEE Computer Society, and the ACM. Rocco Oliveto received his Laurea degree cum laude in Computer 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
