Facilitating Communication, Resource and Task Allocation in
Software Maintenance Teams
George Dafoulas, Christos Tjortjis, Paul Layzell, Linda Macaulay
Department of Computation, UMIST
Corresponding author:
George Dafoulas, Department of Computation, UMIST, P.O. Box 88, Manchester, M60 1QD,UK. TEL/ FAX: +44 161 2003738/ 2003324, email: [email protected]
Index terms- Software Maintenance, Computer Supported Cooperative Work
Abstract
Modern software maintenance teams lie far from a mere number of skilled members working on various tasks in isolation. Software engineering in general is no longer the preserve of individuals but is essentially a team-based activity involving a wide variety of stakeholders (such as maintainers) and thus making the need for communication and co-operation an inherent characteristic.
The structure of maintenance teams and the characteristics of their resources and tasks make the need for support imperative. Several proposed solutions were drawn from the Computer Support Cooperative Work (CSCW) domain, focusing on how Groupware applications may be used to enhance efficiency of these processes.
This paper briefly discusses some of the most widespread problems that maintenance teams face and presents the objectives of current work in the area. We attempt to combine and evaluate software engineering, software maintenance and CSCW findings and propose methods of support for software maintenance teams in three key areas: supporting communication, facilitating resource and task allocation and assisting strategy definition.
1. Introduction
Software maintenance is one of the most demanding stages in the lifecycle of software. Up to 67% of the total software cost involves maintenance [3]. A maintenance project can be addressed just like any other software-engineering project, i.e. a change needs to be specified, designed, coded, tested and documented, commercial and pragmatic factors impose constraints and require a modified approach. However the characteristics of maintenance may impose a more idiosyncratic approach.
According to a study by IBM [33] about 50% of a typical programmer’s time is spent interacting with other group members. DeMarco and Lister [13] suggest that developers working on large-scale systems spend 70% of their time working with others. Finally, according to Jones [27], 85% of the cost of large software systems is spent on team activities. It is estimated that when maintenance projects are concerned, the above figures are even higher based to the fact that communication is more frequent and accuracy of information must not be compromised.
These findings resulted in the first joint efforts from researchers in software engineering and Human Computer Interaction (HCI). The notion of Computer Supported Cooperative Work (CSCW), which was initially “constructed” in the mid 80s in order to define a subset of HCI applications, has become quite common in organisations and it seems reasonable that computer support for teams could enhance productivity [25], [26], [40].
The problem with trying to understand the potential of CSCW is that focus is usually on only one of the many types of support possible (i.e. electronic meeting systems, video conferencing), and teams vary considerably in their needs for support [31], [38].
This paper identifies the key issues in industrial scale team based maintenance, it addresses the need for solutions derived from CSCW in facilitating communication, resource and task allocation. Section 2 discusses software maintenance and it’s special features and collaboration issues and the way they can be supported by CSCW. Section 3 presents the objectives of this work. Section 4 proposes ways for supporting team communication. Section 5 suggests means for facilitating task and resource allocation and section 6 addresses strategy definition assistance. The paper concludes with future work and the way forward discussed in Section 7.
2. Background
Supporting software engineering teamwork and CSCW is an area which has recently received significant research focus [7], [8], [20]. Maintenance is a part of software engineering with certain specific needs. This section introduces and discusses the key terms and issues involved in supporting maintenance teamwork.
2.1 Software Maintenance
Large organisations have been long using software systems to perform a lot of enterprise critical tasks. Programmers who were given the system requirement specifications, designed software solutions, and implemented most of the systems, ad hoc, using languages and techniques of the time. However, as time passed, the needs of enterprises increased, business rules changed and the availability of higher technology tools and hardware, resulted in necessitating software maintenance and evolution.
Software maintenance is defined in (IEEE 1219 1993) as “Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment” [37].
Legacy systems face many problems traditionally tackled by means of maintenance, which can be of different distinct forms [3]. Maintenance is usually performed in order to improve the design, correct errors or design flaws, enhance the performance, enable interface with other systems, change the system, migrate to different platforms and so on [37]. These tasks can be grouped into three categories or else types of maintenance: corrective, adaptive and perfective.
Corrective maintenance is a reactive process, which aims to fix defects in the functionality of software. It is necessary when the system does not perform according to the original intentions. Adaptive maintenance takes place usually when there is a change in the requirements, which influences the system accordingly. All sorts of modifications are included here such as insertions, deletions, and enhancements. Finally, perfective or preventive maintenance includes all efforts to improve a system in terms of quality, such as restructuring, increasing efficiency, readability of code, and documentation updates.
Maintenance is, as described above, an expensive and complex process. Modifications, improvements or even total replacement of old legacy systems involve program understanding, usually in the face of lack of adequate documentation and domain knowledge. 50%-90% of the maintenance programmer’s time is spent on program comprehension [3], [37], [41]. Program comprehension during software maintenance involves the acquisition of knowledge about programs, as well as accompanying documentation and operating procedures.
Thus program comprehension is a task that sometimes has to precede any other task, when maintaining or upgrading a system. Several methods have been proposed, most of which are relying on extracting information from any available resource such as source code, documentation, personal experience and domain knowledge [4], [29], [32], [41].
2.2 Collaboration issues in maintenance teams
This paper is concerned with teamwork issues related to software maintenance and comprehension. An earlier survey revealed that according to practitioners from the industrial field the main such problems are a) inadequate team communication, b) the necessity of presence of experts who are familiar with the software in hand, c) limited time availability due to pragmatic, business constraints which results in poor task allocation [42].
More specifically, team-based maintenance was common, although the teams were clearly loosely structured and flexible in nature in the surveyed organisations. Information exchange among team members is sparse, informal and is hardly ever formally recorded. Teams were perceived as primarily a management and organisational structure and have little bearing on the maintenance and program understanding process itself. This raises the issue whether communication during maintenance and
program comprehension activities is inherently problematic, such as difficult to formally record, or whether maintenance and comprehension is primarily an individual task which does not benefit from interaction with peers, possibly because it is time-consuming for the value it gives.
The issue of team communication highlights that communication within maintenance teams is weak and lacks efficient means to convey information to support maintenance tasks. Oral communication is problematic as it gives rise to misunderstandings and is difficult to keep track of.
Furthermore, members of teams are not necessarily physically located in the same area nor are expected to be in the future [18], thus compounding the difficulty in communication and mutual support from maintainers with experience in a given system to those without such experience. This is an area where CSCW is of particular relevance [8], [40].
It is interesting to note that a previous study of communication and co-operation practices on a range of distributed software projects revealed that communication is indeed more formal when teams are distributed [28]. This study identified several issues in distributed working. Advantages include a) greater formality, well documented procedures and well defined processes, b) minimal interruptions in core work, c) good project decomposition and management, d) built in external memory. On the downside, there were a) difficulties in achieving consensus, b) and additional layer of complexity, when cultural, time zone and regulatory differences exist, c) different ways of working, tools and support infrastructure, d) communication overheads, e) lack of commitment, over/under- confidence in the perceived level of expertise and ability.
The lessons learned from this study include: a) no single team structure is best for all projects, b) trust and confidence are critical success factors, c) a chain of accountability ensures that problems get resolved, d) formalised communication is essential [28].
As mentioned earlier software development projects have transformed into a more virtual process regarding where team members, resources (i.e. funds, information and facilities) and responsibilities (i.e. roles and tasks) reside [9], [17]. Managing and performing distributed projects requires certain skills including communications, teamwork, management and technical skills. Acquiring such skills and effectively using them becomes critical regarding the time constraints and limited flexibility of software maintenance.
Naturally, special attention is drawn to CSCW since it is perceived as the most common field to seek support while addressing software maintenance issues. Large organisations moved to a number of radical changes in their teams’ structure. Initially provided the means for team members to work remotely from home, then moved to merging sub-teams or “ borrowing” suitable team members for specific projects, next outsourcing entire development stages to teams in low-wage high-skill countries and finally creating virtual teams like the ones involved in the famous IBM Visual Age project [7]. Results of existing research in virtual software development teams show that the main
issues in distributed projects, which are geographic dispersion, time zone differences and cultural differences cause significant coordination breakdown, and losses of communication richness and teamness [7], [10]. This underlines the necessity of CSCW support in such projects.
2.3 Software engineering and CSCW
It is undeniable that most software projects are large undertakings involving many people. As the number of people working on a project increases, the potential for communication increases “ multiplicatively in proportion to the square of the number of people taking part” [29]. Obviously, due to the cooperative nature of software development, success is dependent upon the quality and effectiveness of the communication channels established within the development team. These communication channels and various other processes of software engineering teams, are usually supported by CSCW methodologies, applications and tools. CSCW is a generic term that combines the understanding of the way people work in teams with the enabling technologies of computer networking and associated software, hardware, services and techniques. Linked with CSCW, is the term Groupware that refers to the technological aspect of CSCW, that is, a computer software and hardware, over communication network, which supports and augments the team activity [32]. Table 1 includes a taxonomy of Groupware applications and tools that is adapted from Nunamaker [37]. These technologies are classified in this table according to the kind of support that provide in software engineering teams, in two categories. The first column includes the tools and applications that support communication of such teams, while the second column lists technologies that facilitate resources and task allocation and also assist in strategy definition.
Communication support Resources & Task Support
Electronic mail and messaging Groupware Services
Electronic Meeting Systems Workflow
Non-real-time data conferencing (asynchronous) Group Document Handling Desktop Video and real-time Data Conferencing
(Synchronous)
Collaborative-Internet-Based Applications and Products
Workgroup utilities and development tools Groupware and KM Frameworks Group Calendaring and Scheduling
Groupware Applications
2.4 CSCW solutions for maintenance teams
Previous research on software engineering roles, teamwork activities and tasks identified several tasks that developers undertake while in the maintenance stage such as [14]:
• Adding new characteristics
• Correcting possible errors.
• Evaluating performance.
• Increase users’ understanding of software.
• Increase engineers’ understanding of users’ needs.
• Increase skills and improve training.
It is common for members in software development teams while performing the above tasks to simultaneously participate in activities that are not directly related with maintenance but occur frequently in any organisation and involve communication and collaboration between them. Several of such “ teamwork” activities may take place in parallel with a single maintenance task and facilitate in identifying those CSCW tools required for supporting the task in hand [30], [14]. Some of them are:
• Formulate and exchange ideas.
• Allocate work among team members.
• Hold meetings.
• Co-develop and edit graphic designs.
• Co-develop documents and reports.
• Keep track of progress.
• Discuss about work and deadlines.
• Elicit feedback.
The outcome of this research may be summarised in the following example. One of the major tasks during the maintenance stage is “ Adding new functions or modifying existing ones” . A number of teamwork activities are triggered such as exchange of ideas, group meetings, progress monitoring, constant discussions/brainstorming sessions and feedback elicitation. Based on the project characteristics, the structure of the team, and the above teamwork activities the CSCW tools used to facilitate the entire process can be identified as email and messaging, group calendaring and scheduling, electronic meeting systems and perhaps video conferencing.
The described methodology attempts to provide a framework of “ good use” of CSCW tools and techniques available to software developers and investigate its suitability for maintainers. Our focus is on identifying the main requirements of maintainers and provide them with adequate support especially from the CSCW area considering the special characteristics their role and the critical issues that modern teams face, such as geographical dispersion (usually over a number of different time zones), diversity of national, functional and corporate culture and a variety of experience and knowledge levels.
Although formal team communication is limited, informal meetings do take place in order to assist new or inexperienced members of the team seek guidance from senior experienced members, or
the original designers and programmers. This model of staff familiar with the system, mentoring less familiar staff is common, indicating the importance of human factors and the degree of dependence of the understanding effort on the maintainer’ s familiarity with the system.
There seems to be no high-quality substitute for experience when it comes to understanding and maintaining a system, as existing methods and tools are not effective enough and documentation tends to be unreliable. In other words there appears to be a clear need for means of achieving and recording comprehension equivalent to having access to the original developers of the system or to maintainers who are very familiar with it [42].
3. Objectives
The analysis above highlighted the potential of customising existing resource allocation and teamwork methods to produce a new framework which will be applied to maintenance team of industrial scale.
The objectives of this work are as follows:
1. Formalise communication via customised CSCW tools. 2. Introduce a model for task and resource allocation. 3. Facilitate strategy definition.
Obviously using CSCW tools will introduce an overhead but this will be compensated for by the valued added by formalising and recording the knowledge acquired about a system over time and by improving the quality of the decisions made in a more formalised and controlled environment.
The advantage of introducing a model for resource and task allocation will be the support to the decision formulating process. Finally strategy definition can be assisted in the context of large and perhaps distributed maintenance teams the members of which may not be collocated in space or time.
4. Supporting Communication
Traditionally a project is decomposed into sub-systems and each one of them is then allocated to a development team, which decomposes this into a number of modules, which individuals can concurrently design, code, test or maintain. This manner of project decomposition is usually carried out using teams that operate from the same geographical location. Projects that utilise geographically separated teams with partially overlapping or disjoint working hours, an opportunity exists to exploit an additional dimension of concurrent activity. This method has several benefits but mainly a
potential 24-hour continuous development effort and access to a greater pool of skills globally. The main concerns and potential drawbacks are about the communications between the working units and their structure.
Gorton’ s work on shift work sets the standards in this area since 1995 with several prototypes applied and tested in existing case studies concerning coding and testing [19], [20]. Maintenance tasks were part of the entire development process incorporated into coding and testing. The main findings included certain communication requirements including the use of certain CSCW tools such as group email, shared discussions, and a document database with excellent versioning and replication facilities, in conjunction with a good electronic meeting system.
The various types of software process and how Japanese software factories have evolved during the last fifteen years are covered by Aoyama’ s work with a series of case studies at Fujitsu [1], [2]. Also, according to Ocker and Fjermestad, high performing teams significantly out-communicate the low performing teams in terms of the number of lines communicated between team members [35].
A proposed solution that should be further tested and evaluated would be three-fold. First, the requirements specification for each maintenance project should be prepared. That should include common task definition in order to view parts maintained by other members, understand and follow constraints, proceed to any modifications, discuss progress interactively or asynchronously, propagate task outcomes and review deliverables. Also to coordinate teamwork activities like the ones mentioned earlier and also team tasks such as run-time modifications and exception handling. As Domazet et al suggest, these requirements must be supported by, both a shared product data repository and collaborative workflow management [15].
Second, a detailed list of guidelines for formal communication should be set aside for maintenance teams to use for the entire duration of each project. The guidelines as adopted from Horrocks et al [24] should covers areas such as meeting outcomes, participants, resources (e.g. available technologies, cost estimates), time and place of meetings (e.g. scheduling, face-to-face, different place/different time) and interaction process.
Third, the most suitable collaboration technologies should be selected from the Groupware Taxonomy mentioned earlier in this paper. Each category of CSCW applications offers different types of support, some are related, while others overlap.
Various models for task allocation and collaboration methodologies for distributed projects attempt to monitor and facilitate the communication process [7], [20]. Figure 1 represents the various communication opportunities based on different collaboration patterns for maintenance teams that are either collocated or have a more virtual nature. Various communication patterns exist for maintenance teams regarding the nature of the problems in software, the requirements of customers and the characteristics of the maintenance teams involved.
Team A Team B Team C Customer 9 am 11am 1 pm 3 pm 9 am 11am 1 pm 3 pm Day 2 Day 1 9 am 11am 1 pm 3 pm 9 am 11am 11am 1 pm 3 pm 11am 1 pm 3 pm 9 am 11am 1 pm 3 pm 9 am 11am 1 pm 3 pm Reporting errors Maintainer with task Maintainer idle
Overnight
Team-Team communication
Customer - Team(s) communication
Figure 1: Communication Patterns in Maintenance Teams
The scenario in Figure 1 involves three specialised teams that reside in different locations and consist of three, two and four members respectively. As shown in the graph the customer has a two-hour time difference with sites A and C and no time differences with site B but they are not necessarily collocated. The scenario includes the available slots for each team member for the specific project and the problem recording slots for the customer site. The customer has certain times available for communication with the supporting maintenance teams and each team has specific times dedicated for synchronous meetings All other communications take place asynchronously.
The graph illustrates some guidelines for optimum allocation of resources and tasks in order to decrease time overheads within each maintenance team and minimise response times. Team A is not suitable to respond in day 1 since their shift starts two hours later than the customer’ s. Team B has no time differences with the customer but needs to be further involved in the project by increasing the number of available slots or allocate tasks in the existing idle times. Team C is ideal to support the customer early in both days after the first communication. Also they have the opportunity to pass their results at the end of their shift with enough time for the customer site to respond.
5. Facilitating task and resource allocation
Existing research in software engineering and CSCW has resulted in several models for forming software engineering teams and allocating roles to their members with respect to special structure of software development teams, the particular requirements of virtual teams and the available CSCW technologies [10], [11], [12]. Initially, this section focuses briefly on team formation issues that apply to maintenance teams, then emphasising on facilitation of task and resource allocation.
According to Dyer effective teams have the following characteristics [16]: (i) clear goals and values, (ii) members that have clear understanding of their roles, (iii) trust and supportiveness between team members, (iv) open communications, (v) participation to decision making, (vi) commitment to decisions, (vii) high performing and supportive leadership, (viii) awareness of differences within the team, and (ix) consistent team structure and procedures. This list is representing a certain viewpoint of team building. Numerous variations exist depending on the nature of the team, the domain of the wider organisation, and so on. The common element of all these varying perspectives is that the characteristics of effective teams may be used for developing an agenda for team formation [5], [16], [21], [23], [43].
Three different similar types are used in current research to identify the responsibilities of maintenance team members. Earlier in this paper the notion of teamwork activities was discussed. The other two are project roles and tasks that are concerned with development goals. Their main difference is that project roles are more generic, being used in a similar manner as job titles and having a complex structure and can be broken down in simpler tasks.
Tasks are quite simple and are usually undertaken by a single individual. An object oriented approach is followed while identifying role and their actors. According to Ould, a role is actually a type [36]. Therefore, within a group there can be a number of different instances of a role type active at any time. Enoki also proposes a role-oriented organisation model that regards roles and resources as objects and people as subclass object under resources [17]. Roles have specific requirements on resources such as software technology, equipment, access to information, financial, and finally suitable actors. Actors have similar requirements on resources as roles, and should lie at the same conceptual level. An actor responsible for a role, which requires specific programming skills and use of special computer equipment, should posses the required skills and have access to the computer equipment needed.
Furthermore actors have specific attributes expressing their characteristics. An actor may be a single individual or even a group. Apart from technical skills, knowledge and experience there are four attribute categories for each actor object [9]: (i) Personal, (ii) Cultural, (iii) Personality and (iv) Constraint attributes such as workload and location.
Team Teamwork Activities Project Roles Tasks M TMS M Roles Actors Resources Allocation Access Availability Individual Funds Facilities Information Project
Figure 2: Maintenance Teams Management Support Methodology (MTMSM)
A methodology is required for management support in maintenance teams also called MTMSM. This methodology covers both resource and task allocation in maintenance teams. Figure 2 displays the interactions between three key concepts of resource allocation. Their bi-directional relationships are described by the terms allocation, availability and access:
Roles are allocated to actors and vice versa.
Roles require specific resources available, at the beginning and during the project.
Actors require access to specific resources according to the roles that occupy, and while these roles exist.
The “ Project” stage incorporating task allocation is presented in Figure 3, where a task allocation model is represented in detail. A number of available specialised maintenance teams are made available for a specific project. Each team member has a specific role and set of responsibilities. Such teams are not necessarily collocated with each other or the customer’ s site. There are a number of filters that are used to select the team and its members for a specific project. Initially the special requirements of the project are taken under consideration with respect to skills, knowledge and experience needed. Next according to the customer’ s characteristics time zone differences and cultural dimensions are used to identify the most compatible candidates for each task. The project is then split into a number of problems that are allocated to different sub-teams. The constraints for the
problem-solving phase are constantly updated by the customer’ s site which directly interacts with each sub-team. Filter 1 Problem 1 Project Problem 2 Organisation Customer Skills Experience Knowledge Time Zones Cultural Differences Constraints Filter 2 Filter 3 Filter 4
Figure 3: Task Allocation Model
Following Figures 2 and 3, Table 2 includes the associations between classes representing roles and actors as discussed in earlier sections of this paper. For example cell {5, 4} reads that one or more tasks are assigned to a single team, while cell {4, 3} reads that a task might be supported by zero or more teamwork activities.
Project Role Teamwork Activity
Task Team Individual
Project Role *** Supports 1..N Part of 1 Assigned 1..N Assigned 1
Teamwork Activity Supported by 0..N *** Supported by 0..N Supported by 1..N Supported by 0..N
Task Has 1..N Supports 1..N *** Assigned 1..N Assigned 1..N
Team Allocated to 1 Supports 1..N Allocated to 1 *** Part of 1..N
Individual Allocated 1..N Supports N Allocated to 1 Has 1..N ***
Table 2: Relationships between Roles and Actors classes
6. Assisting strategy definition
It is evident that strategy definition in software maintenance teams should take under consideration the characteristics of the project and the team members as well as the external and technological environment. Quite a few industry-oriented guides for management practitioners attempt to provide compiled lists that should be followed during start-up meetings, collaboration sessions, and so on. The most frequent elements in such lists are to: (i) set an organisation direction,
(ii) have a team vision, (iii) clarify the main goals and objectives, (iv) create a project plan, (v) identify individual responsibility and (vi) undertake a resource analysis.
However, these guidelines usually fail to take under consideration the special requirements of a maintenance team and the available technological advances in order to support strategic actions such as decision-making and target setting. Additionally, when human and other resources are dispersed several factors are critical for the smooth running of the project and the success of any strategy goals. Different strategies should be followed, especially when parallel work is the norm, continuous anytime communications exist, exchange of documentation is electronic than paper-based, tasks are shared with varying responsible parties, close collaboration is inherited as part of each task, and issues such as trust, effective teamwork and team decision-making may cause the project to fail.
Bendeck et al have identified a very useful set of requirements that a software engineering environment must meet in order to support the coordination of management activities in software development projects [6]. These are: (i) process modelling and planning support, (ii) schedule support, (iii) monitoring support, (iv) support for the selection of corrective actions, (v) re-planning and rescheduling support during enactment, (vi) interleavable planning, management and enactment, (vii) notification system, (viii) dependency and change management, and (ix) legacy software. The requirements in this list correspond to the previously discussed teamwork activities that may take place both in a managerial or development context and supported by various groupware applications.
7. Conclusions - The way forward
This paper discussed the issues arising in distributed/ virtual software maintenance teams. The main problems identified include communication, resource and task allocation and strategy definition. Some of these issues have been scrutinised in the context of software engineering and CSCW. The contribution of this work is to provide a framework for modern maintenance teamwork which addresses communication, trust, motivation, commitment task allocation and team management difficulties.
The proposed framework is yet to be empirically tested and evaluated. A preliminary survey of the industrial reality has strongly indicated that the work presented here will indeed facilitate teamwork and deal with the pragmatic limitations it imposes in modern industrial maintenance environments.
References
[1] M. Aoyama, “ Sharing and Managing the Design Information in a Distributed Concurrent Development of Large-Scale Software Systems” , Proc. IEEE COMPSAC ’ 96, pp. 168-175, 1996.
[2] M. Aoyama, “ Agile Software Process Model” , Proceedings IEEE COMPSAC ’ 97, pp. 454-459, 1997. [3] L.J. Arthur, ‘Software Evolution. The software maintenance challenge’ , A Wiley-Interscience publication,
1987.
[4] F. Balmas, H. Wertz and J. Singer, ‘Understanding Program Understanding’ , Proc. 8th Int’l Workshop
Program Comprehension (IWPC 00), IEEE Comp. Soc. Press, 2000, pp. 256.
[5] R. M. Belbin. Management Teams: Why they succeed or fail. Butterworth-Heinemann, 1998.
[6] F. Bendeck, S. Goldmann, H. Holz, B. Kotting “ Coordinating Management Activities in Distributed Software Development Projects” , Proceedings of the 7th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE ‘98), IEEE Computer Society Press, ISBN 0-8186-8751-7, pp. 33-38, 1998.
[7] E. Carmel, “ Global Software Teams: Collaborating Across Borders and Time Zones” , Prentice Hall, 1999. [8] D. Coleman, ‘Groupware- Collaborative Strategies for Corporate LANs and Intranets’ , Prentice Hall,
1997.
[9] G. Dafoulas and L. Macaulay, “ DRASIS: Supporting Dynamic Role Allocation in Software Engineering Teams” , Proceedings of the GEMISIS Millennium Conference, University of Salford, England, 2000. [10] G. Dafoulas and L. Macaulay, “ Decision Making Issues in Software Engineering: Investigating Factors
Affecting Team and Role Conflicts in Collaborating Virtual Teams” , 5th International Conference: Computer Supported Cooperative Work in Design, CSCWD 2000, Hong Kong, IEEE Computer Society. [11] G. Dafoulas and L. Macaulay “ Assisting Knowledge Management in Virtual Software Teams: Coping
with Location, Time, and Cultural Differences” in proceedings of International Workshop on Cooperative Internet Computing, CIC 2000, Sponsored by IEEE, Hong Kong, 2000.
[12] G. Dafoulas and L. Macaulay “ Facilitating Group Formation and Role Allocation in Software Engineering Groups” , AICCSA ‘01, Beirut, Lebanon, 2001.
[13] T. DeMarco, and T. Lister, Peopleware, Dorset House, 1987.
[14] DiCE – Scenarios C & D, Internal Technical Report, Computation Department, UMIST.
[15] D.S. Domazet, M.C. Yan, C.F.Y. Calvin, H.P.H. Kong and A. Goh, “ An Infrastructure for Inter-Organizational Collaborative Product Development” , Proceedings of the 33rd Hawaii International Conference on System Sciences, 2000.
[16] W. G. Dyer, “ Team Building: Current Issues and New Alternatives” 3rd edition, Addison Wesley, Organisation Development Series, 1994.
[17] H. Enoki, Y. Kanda, K. Nakamura, T. Etani , Y. Shimoji and S. Kitamura, “ Role-Oriented Organisation Model and Its Implementation with Agent System” , in Seventh International Conference of Human-Computer Interaction, San Francisco, California, USA, ELSEVIER Science B. V., 1997.
[18] A. French and P.J. Layzell, ‘A Study of Communication and Cooperation in Distributed Software Project Teams’ , Int. Conf. Software Maintenance (ICSM 98), IEEE Comp. Soc. Press, 1998, pp.146-155.
[19] I. Gorton and S. Motwani, “ Towards a Methodology for 24 hour Software Production Using Geographically Separated Teams” , Proceedings First IFIP International Conference on Software Quality and Productivity, Hong Kong, Chapman & Hall, pp. 50-55, 1994.
[20] I. Gorton and S. Motwani, “ Issues in Co-operative Software Engineering Using Globally Distributed Teams” , Information and Software Technology, 38, pp. 647-655, 1996.
[21] M. Haywood, “ Managing Virtual Teams: Practical Techniques for High-Technology Project Managers” , Artech House, 1998.
[22] G. Hofstede G, “ Cultures and Organisations” , Harper Collins Publishers, 1994. [23] G. C. Homans. The Human Group. Routledge and Kegan Paul, London, 1951.
[24] S. Horrocks, N. Rahmati and T. Robbins-Jones, “ The Development and Use of a Framework for Categorising Acts of Collaborative Work” , Proceedings of the 32nd Hawaii International Conference on System Sciences, 1999.
[25] G. Huber, “ A Theory of the Effects of Advanced Information Technology on Organizational Design, intelligence, and decision making” , Academy of Management Review, 15, 1, pp. 47-71, 1990.
[26] R. Johansen, “ Groupware: Computer Support for Business Teams” , New York, The Free Press, 1998. [27] T.C. Jones, Programming Productivity, McGraw-Hill, 1986.
[28] P.J. Layzell, P. Brereton, A. French, ‘Supporting Collaboration in Distributed Software Engineering Teams’ , Proc. 7th Asia-Pacific Software Engineering Conf. (APSEC 2000), IEEE Comp. Soc. Press, 2000, pp.38-45.
[29] D.C. Littman, J. Pinto, S. Letovsky, and E. Soloway, ‘Mental Models and Software Maintenance. Empirical Studies of Programmers’ , Albex, Norwood NJ, 1986.
[30] L.A. Macaulay, and A.N. Shaikh, “ Groupware and Software Engineering: Success Criteria” in ‘The Digital University’ , ed. R.Hazemi, Springer-Verlag CSCW Series, 1998.
[31] M. Mandiwalla and L. Olfman, “ What do Groups Need? A Proposed set of Generic Groupware Requirements” , ACM Transactions on Human Computer Interaction, 1995.
[32] A. Von Mayrhauser and A.M. Vans, ‘Program Comprehension During Software Maintenance and Evolution’ IEEE Computer, Vol. 28, No. 8, August 1995.
[33] G.M. McCue, “ IBM’ s Santa Teresa laboratory: architectural design for program development” , IBM Systems Journal, 17, (1), 4-25, 1978.
[34] J.F. Nunamaker Jr., N.C. Romano Jr. and R.O. Briggs “ A Framework for Collaboration and Knowledge Management” , Proceedings of the 34th Hawaii International Conference on System Sciences, 2001. [35] R.J. Ocker and J. Fjermestad “ High Versus Low Performing Virtual Design Teams: A Preliminary
Analysis of Communication” , Proceedings of the 33rd Hawaii International Conference on System Sciences, 2000.
[36] M.A. Ould, “ Business Processes: Modelling and Analysis for Re-engineering and Improvement” , John Wiley & Sons, 1995.
[37] T.M. Pigoski, ‘Practical Software Maintenance: best practises for managing your software investment’ , Wiley Computer Publishing, 1996.
[38] J. Satzinger and L. Olfman, “ Computer Support for Group Work: Perceptions of the Usefulness of Support Scenarios and End-User Tools” , Journal of Management Information Systems, Vol 11, No 4, pp. 115-148, 1995.
[39] I. Sommerville, Software Engineering, 6th edition, Harlow, Addison-Wesley, 2001.
[40] K. Spurr, P.J. Layzell, L. Jennison, N. Richards, Computer Support for Co-operative Work. John Wiley and Sons Ltd., 1994.
[41] T.A. Standish, ‘An Essay on Software Reuse’ , IEEE Transactions on Software Engineering, vol. 10, no. 5, Sept. 1984, pp. 494-497.
[42] C. Tjortjis and P.J. Layzell, “ Expert Maintainers’ Strategies and Needs when Understanding Software: A Qualitative Empirical Study” , Proc. 8th Asia-Pacific Software Engineering Conf. (APSEC 2001), IEEE Comp. Soc. Press, 2001, pp. 281-287.
[43] B. Tuckman and N. Jensen. Stages of Small Group Development Revisited. Group and Organisational Studies, vol. 2, pp. 419-427, 1977.
