CONFER: Towards Groupware for Building Consensus in ...

CONFER: Towards Groupware for Building Consensus in Collaborative Software Engineering Felix Wong, George Fernandez & Jim McGovern School of Computer Science and Information Technology RMIT University GPO Box 2476V, Melbourne 3001, Victoria [email protected], [email protected], [email protected]

Abstract Distributed computing technology allows software engineering teams to work across different locations and times, collaboratively refining documents or diagrams ultimately producing a single agreed outcome. A natural part of this process is the emergence of differences or conflicts reflecting divergent team member perspectives, interpretations, skills or knowledge. This paper describes CONFER (CONflict Free Editing in a Replicated architecture) a system that address the handling of conflicts in collaborative software development projects. At the technical level, CONFER detects and stores conflicts until they are resolved by user actions. However, it is in the social domain that these user actions are formed and resolved, so effective collaboration tools will need to include support for conflict resolution in the social domain as well. Some software engineering teams will be based on models of cooperation and maintenance of team harmony may require that conflict resolution be based on discussion and consensus, rather than by authority or by simple voting systems. A consensus building approach is proposed based on a method used in travel planning (ChuCaroll, 2000) that encourages participants to further explore alternatives together with their own proposals. The social support mechanism has been simulated using paper and pen and assessed in a small experiment. The evaluation suggests that the technique is easy to use, reduces conflict resolution time and may be a useful extension to CONFER. Keywords: Groupware for software engineering, CSCW, Conflict resolution, collaborative software engineering, consensus building.

1

Introduction

Collaboration within a team of expert professionals is central to the software engineering process. Software development projects entail countless formal and informal meetings. Not surprisingly, Robillard and Robillard (2000) found that software engineers spent most of their time in meetings of one form or another, Copyright © 2007, Australian Computer Society, Inc. This paper appeared at the eighth Australian User Interface Conference (AUIC2007), Ballarat Australia. Conferences in Research and Practice in Information Technology (CRPIT), Vol. 64. Wayne Piekarski and Beryl Plimmer, Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included.

with 4 percent of work being mandatory meetings, 14 percent called meetings, 41 percent ad-hoc collaboration, and 41 percent being individual work. Ad-hoc collaboration requires easy access between team members, so that they can talk on an as-required basis discussing requirements, specifications, design, programming, debugging, testing and deployment issues. Computer-based collaboration support systems can bring together team members regardless of where they are, and allow them to work freely on their tasks. Distributed software engineering has many attractions. Globally distributed teams can work continuously, taking advantage of time differences to work around the clock, with each member able to keep the project going without working unusual hours (Gorton et al., 1997). Travel time is reduced, and there is greater access to expertise (Campbell and de Walle, 2003). Further, Damian and Eberlein (2003) have concluded that distributed software engineering teams are no less effective than those that operate in face-to-face mode only. . Wayne Piekarski and Beryl Plimmer, Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included.

Conflicts will emerge in the content of a range of software engineering documents for a variety of reasons. Many software projects are novel and requirements and specifications are often incomplete or ambiguous. Teams necessarily include a range of membership with different areas of expertise, experience and knowledge of the problem domain. Analysts, designers, system architects and a various technical experts are needed to bring a software system from concept to fruition. Aside from different skills and levels of expertise, individuals have different beliefs, attitudes and motivations. Cultural differences that may occur in global teams may also lead to conflicts (Purvis et al., 2004), and team members will view situations quite differently depending on the degree to which they identify themselves as technologically centred or socially centred (Kilker, 1999). Conflict management activities include prevention, detection and resolution (Slimani et al., 2006). The focus of this work is on managing detection and resolution. The ability to detect and resolve conflict effectively can have a significant impact on the outcomes and the costs of a software engineering project. By dealing with conflict openly and as early as possible there may be less chance

of divergence in documents, with consequent less need for costly back tracking and rework. Further, negotiation around conflicts and disagreements can be expensive (Slimani et al., 2006) in terms of participant time, and methods that can make conflict resolution more efficient may reduce the overall costs of software development. Many conflicts will be quickly and easily resolved, but some conflicts will be “sticky” and their resolution will not be straight forward. It is these difficult or “sticky” conflicts that will require significant cognitive effort in the social domain that is the main focus of improved support for conflict resolution. This research aims to enhance an existing technical environment referred to as CONFER (CONflict Free Editing in a Replicated architecture). CONFER has been partially implemented to demonstrate algorithmic correctness and proof of concept (Wong, 2006). CONFER detects conflicting operations in software engineering documents, and maintains these conflicts until they are resolved by user actions. These user actions take place in the social domain, and the primary aim is to augment the existing technical solution with a means of facilitating the resolution of software engineering conflict in this domain. This paper describes a proposed approach based on consensus building and reports on a preliminary empirical investigation of its application. The rest of this paper is organised as follows. Section 2 provides background in computer-based collaborative software engineering. Section 3 focuses on the conflicts in software engineering. Section 4 briefly surveys means of resolving conflict in the social domain and identifies a suitable method based on building consensus. Section 5 describes an experiment aimed at assessing the effectiveness of the social support mechanism. Section 6 provides discussion around the outcome of the experiment and its consequence for implementation. Finally, section 7 provides a concluding discussion for the paper.

2

Collaborative software engineering

There has been considerable interest in developing tools to support software engineering teams in various parts of the software development life cycle (Boehm et al., 2001; Bowen & Maurer, 2002; Cook et al., 2004; Nutter & Bolfreff, 2003; Gorton et al., 1997). The pervasiveness of computer networks has enabled these tools to be extended to geographically, possibly globally distributed software engineering teams. Global collaboration has been successfully employed by software development teams working over the Internet, developing widely used software such as Open Source Linux, Apache and Samba (Augustin et al., 2003). Collaboration has different modes of interaction, varying from asynchronous modes where users work relatively independently to highly synchronous activity where a number of users work together on the same document in real time. Any single project may embrace the full spectrum of these interaction modes. At times software engineers may develop all or part of a document in isolation independently and asynchronously, but a critical

part of their work may be interactive, intensive and focused, best supported by highly concurrent real-time synchronous access. Periods of intense collaboration may be needed to resolve differences, clarify detail, and generally provide a forum for critical evaluation of content. While these periods of overlapping work may be relatively small in the context of a project, they are necessary in achieving a good, collectively owned outcome and the technical challenges are worth pursuing. The focus of CONFER is on support of cooperative software engineering teams (as opposed to delegation or consultation teams identified by Gorton et al. (1997)), and support for positive interaction between participants. Good collaboration support should produce better outcomes through collective knowledge and wisdom and should provide an open environment that supports learning. Openness in part is achieved by ensuring that users have ready access to their own work and are aware of the work of others, providing a complete context for each team member’s activity (Arnold, 1995; Nutter and Boldyreff, 2003). Successful software development process is built on good communication. Openness is a pre-requisite to effective communication providing everyone with the opportunity to learn by observing those who are more knowledgeable or have a more accurate point of view in some aspects of the work (Robillard and Robillard, 2000). Collaborative systems can be either primarily centralised or fully replicated with no reliance on a central server. Centralised systems are the most commonly deployed architecture for collaborative engineering, however, a distributed or replicated architecture can better meet the needs of many projects (Zha & Du, 2006) and CONFER is based on a replicated architecture. Each participant has a copy of their own data and application providing greater local control, flexibility and scalability. It also supports concurrent modular development, enabling experts to work both independently and cooperatively. CONFER supports synchronous concurrent access, as well as the ability for participants to work relatively independently in an asynchronous mode. The replicated architecture of CONFER provides the following advantages. Real-time response: the response to local users is as immediate as for face-to-face or for a single-user system. Availability: users can continue to have access to their own copies, even when other members are disconnected. Unconstrained activity: multiple concurrent users are able to freely read and edit a software engineering document at any time, in order to facilitate free and natural information flow among collaborating users. Further, while not a fundamental part of a replicated architecture, two other aspects of collaborative software engineering are supported within this framework. Awareness: the operations of a user are available to all other users of the same document as soon as possible.

Fair dealing: all users are treated equally, and no user given precedence over any other so that, where possible, actions of any user should be accepted and applied.

3

Conflict in software engineering

While the ability to work concurrently has the advantages of imposing fewer constraints on users, it also introduces the possibility of conflicts emerging early as users independently propose incompatible operations. In concurrent software engineering this may mean conflicting operations on diagrams, text, project plans, and spreadsheets. Typical examples of conflict are spatial-temporal interference (Slimani et al. 2006) where multiple users have conflicting proposals about some object in the same place or time, such as might occur in diagrams or animations. Similarly, concurrent users can update a project plan component or spreadsheet cell with incompatible values. These conflicts can arise in a replicated architecture in three ways: through real-time activity, through asynchronous activity or through disagreements. A real-time conflict occurs when connected users initiate conflicting operations at the same time. While working independently on the same document user A and user B may produce incompatible operations, for example, user A may create a class “student” with a one-to-many cardinality relationship with another class “academic program”, while user B may claim that a “student” has a many-to-many relationship with “academic program”. These conflicts are reflected in the CONFER environment as part of its support for concurrent replicated processing. An asynchronous conflict occurs between users who are disconnected and work independently. The differences appear when they re-connect and their operations are in conflict with other existing operations. Asynchronous conflicts are an extension of synchronous conflicts, the difference being that periods of concurrency are longer and that conflict detection is only possible when participants re-connect. Disagreements require that participants enforce their change above that of another participant. If a user disagrees with an existing proposition, CONFER can force a conflicting operation at the local level, which will then be broadcast to all other users. Disagreements as defined here are conflicts that arise after the event, on reflection at some later stage, and do not arise through concurrent operations as do synchronous and asynchronous conflicts. Detection is dealt with at the technical level, identifying conflicts of intention that occur in the flow of the process (synchronous and asynchronous conflicts) or after reflection (disagreements). Once detected, conflicts are highlighted as needing resolution. Bringing additional knowledge hand can help resolve conflict. This includes expanding the discussion beyond those involved in the conflict, such as to include an expert viewpoint with more experience or knowledge, or to provide access to other knowledge bases and previous

cases that assist with understanding the issue (Slimani et al., 2006). Frameworks that can guide the process, such as argumentation and negotiation, have been used in resolving conflict in concurrent engineering (Slimani et al. 2006). A well known argumentation approach is that of Toulmin (1956), a technique used to resolve conflict in applications such as law (Freeman & Farley, 1996). The approach requires work at a very detailed level, getting participants to examine in detail their supporting evidence as well as its exceptions and may be overly tedious for most software engineering conflicts. Negotiation approaches have been particularly prevalent in engineering design and can be characterised by all members participating in proposing new solutions, and supporting or opposing solutions (Slimani et al., 2006). While not as formal as Toulmin’s argumentation scheme, members are encouraged to provide their rationale and to examine the impact of their solution. Negotiation has been implemented in software through a dedicated space, where participants are guided through a negotiation process, and provided ready access to helpful resources (Slimani et al., 2006). Delphi techniques have also been used to resolve conflict by systematically soliciting and collating informed judgments on a particular topic (see for example Rowe, 2000). Delphi is an iterative process where individual responses are shared among participants in the form of analysis and comments, and individuals are given the opportunity to revise their original answers in response to group feedback. The process continues until a predetermined level of consensus is achieved. These methods tend to present knowledge and resolve differences at a surface level only, and do not always improve understanding of the fundamental cause of the disagreement. Chu-Carroll (2000) present a conflict resolution approach based in the problem domain of travel planning. The method aims to build consensus through a multi-step process in which participants are encouraged to explore alternatives, rate their confidence in their proposals, examine their proposals in more detail, and if necessary enter into fuller discussion with their peers. The original Chu-Carroll (2000) process works at the complete design of an overall travel plan. That is, the basis of conflict is a complete travel plan. In contrast, CONFER works on operations and is able to detect the first small divergence in a software engineering document. By resolving conflicts as early as possible when they arise, artefacts such as designs are less likely to significantly diverge and require backtracking. The Chu-Carroll method provides a middle ground solution akin to negotiation that can be supported in a team environment. It provides a staged approach gradually extending effort as needed requiring a reasonable level of detail to resolve the difference. Further, since it is focused on cooperation and fairness, it is a good candidate for preserving team harmony and building a strongly cooperative team.

4

Resolving conflict in CONFER

CONFER is a prototype collaborative editing system that focuses on software engineering diagrams. CONFER demonstrates a supporting technical environment that detects, records, highlights and notifies users of conflicting operations. CONFER maintains all divergent operations until they are resolved, and only removes these conflicts or divergent operations when they are explicitly reversed by user actions. Some conflicts can be easily resolved, but more “sticky” conflicts may require actions in the social domain. CONFER and other similar tools provide low level algorithmic management of conflicts and need enhancement through new tools and techniques to support consensus building in the human domain. The software creation tools, such as text editors and diagramming tools used in CONFER ensure syntactic correctness at the local site, and the integration of operations at remote sites ensures syntactic correctness is maintained. The model is also based on interaction between peers, and there is no concept of a facilitator, or session controller. In cases of conflict the CONFER conflict management system provides divergent copies and maintains these until the differences are resolved. The steps outlined by Chu-Carroll (2000) and adapted to consensus building around software engineering conflicts are as follows. Step 1: Notify users. This initial phase involves detecting the conflicting operations received at various sites. These operations are stored (in a queue or queues) and all users are notified. This step immediately alerts all involved and can be used to enhance the human knowledge base by involving all those who can assist in its resolution. When users are aware of these conflicting operations, they may choose to remove the conflict by changing or reversing their operations. As soon as the model receives the reversal of the operation, the conflicting operations can be removed and this operation will no longer be highlighted as a source of conflict. All users can be notified and the reversal applied consistently at each local site. Step 2: Check Domain Knowledge. If the conflict persists, the process moves to more formal phases, starting by expanding the knowledge that can be brought to bear on the conflict. For example, say for a student enrolment application every enrolled student may be able to register in a maximum of two programs and there has to be courses associated with each student. These business rules may be present in other schemas or information sources. Users can then revise their operations and remove conflicts. Some projects will not have a knowledge base to draw on, though design patterns and existing designs may become increasingly accessible and useful as a basis in new design. If an existing knowledge base cannot assist in resolving conflict, then the next step is to encourage users to explore alternatives. Step 3: Explore alternatives. The aim of this step is to encourage participants to explore other possibilities. This step encourages participants to explore the merits of other proposals and concludes by asking them to review their proposal in the light of their examination of alternatives.

Step 4: Assess confidence levels. Should conflicts still remain unresolved, participants are asked to assess their confidence in their own proposal, as well as any alternatives. All participants see all confidence levels of all proposals, as well as their alternatives. The aim of this step is to encourage participants to take into account the relative confidence levels, perhaps to reexamine proposals with which they are less confident in the light of higher levels of confidence by others. Step 5: Enter fully synchronous discussion. Participants discuss their proposals more fully, possibly face-to-face, or using other channels, such as electronic conferencing, to resolve the difference. This gives each other a chance to more fully explain their proposal. Step 6: Coordinator or group decision. This is the last resort of collaborative conflict resolution. A decision is referred to a nominated arbitrator, an expert in the area, or an independent person (an honest broker) who will not favour any side, or a vote may be taken. Ultimately, a designated person, a project manager for example, would be accountable for the progression of the project beyond the conflict. Although the aim of the preceding steps is to avoid reaching this stage, the presence of this step recognizes the possibility that the problem may not be resolved in any other way, and is the step of last resort.

Technical Focus Basic editor Membership management Distribution & replication support Conflict detection, recording & reversal Check existing knowledge Solicit alternatives Check confidence levels Discuss directly Escalate to coordinator

Social Focus

Figure 1. Integrated collaborative software engineering environment Basically, the approach can be divided into a number of phases. Step 1 involves notifications. Step 2 brings more knowledge to bear through access to other knowledge sources. Step 3-4 aim to strengthen the assessment of expert viewpoints, by making available the views of others, their alternatives and confidence. While this does not explicitly address the strength of the expertise, it does support informal consideration of other views and assessments of the strengths and bases of those views.

Step 5 provides for more direct communication, and Step 6 involves final decision making should all other avenues fail. This overall approach may be combined with software engineering tools, distribution control and consistency management to provide the basis of a fully integrated collaboration environment built as shown in Figure 1. Components in the technical domain provide support for the basic operations of software engineering design, the ability to extend this to a fully distributed mode of operation, and the ability to manage conflicts. Users initiate local operations, and these are transmitted to all sites. Each site must integrate remote operations into their own workspace. Conflicting concurrent operations must be detected and maintained until removed. The activities in the social domain provide a step-bystep approach aimed at supporting the humans involved in the resolution of conflict. The framework can be summarized as escalating the process and elaborating the difference. If the process does not resolve the differences, then the fair dealing principle is relaxed, and the conflict may be referred to an arbiter.

5

Evaluation of conflict Resolution in the Social Domain

In this section, the effectiveness of the proposed conflict resolution extension is explored with the aim of guiding its ultimate inclusion in CONFER. This is done through an experiment in which users collaboratively worked on a design problem aimed at assessing how well the model assists participants in removing conflicts, and their level of satisfaction with this approach. These are described in the following hypotheses. H1: the proposed approach for CONFER helps remove conflicts effectively.

groups being randomly allocated one of the problem descriptions. Problem description A is as follows. “A student wishing to take a computing course has a choice of the following streams (Information Management, Architecture and Organisation, Operating Systems, Programming Concepts and Skills, Software Engineering. Courses taken before entering the Computing program may satisfy entry requirements, although they do not count for credit towards graduation. Students with previous experience or credits from a previous course may satisfy the course pre-requisites, although they do not count for credit towards graduation unless the credits are accepted by the Graduate School for transfer from another institution or program. There are two possible modes for completing the course: thesis or coursework. Both require the student to complete all admission requirements. 36 credit points are required for the coursework while 24 credit points are required plus another 6 points for thesis writing. Subject available are: Foundations of Computation, Distributed Computing also known as Net-Centric Computing, Software Engineering, Programming Concepts and Skills, Intelligent Systems, Information Management, Architecture and Organisation, and Thesis.” Problem description B was a slight variation on Problem description A and was provided to ensure that there would be some differences. The problem descriptions were aimed to be open to different interpretations in classes, and class hierarchy and relationships with other classes. Subjects from both groups were asked to develop a class diagram concentrating on the basic structure of classes and their associations. Figure 2 shows the major structural elements of a simplified common solution.

H2: participants are satisfied with their experience in using CONFER.

Stream

5.1 METHOD 60 subjects were divided into an experimental group of 30 subjects and a control group also of 30 subjects. Each of the experimental and control groups were further divided into 10 teams of two to four members based entirely on their availability for a particular session. (For example, if 6 students were available, they were divided into 2 teams of 3.) The experimental group carried out their collaboration using the proposed CONFER method, while the control group carried out their task without any specific conflict resolution aid. The subjects were selected conveniently from the professional peers and classmates of the principal author. All participants had knowledge of software engineering, although this varied from exposure as a student up to many years of professional practice. The subjects were randomly allocated to the experimental and control groups, and to teams within these groups. Two problem descriptions were used with control and experimental

Student

Subject

Course

Thesis

Course work

Figure 2. Simplified example solution

Major differences were found in identifying the classes, and getting all of the associations on the diagram. There was some confusion about the use of labels such as course and subject. In some poorer quality examples, class instances such as the specific streams were represented, rather than as classes, and hierarchies were not all represented or represented correctly. The procedure for the experimental group was as follows. 1.

Subjects were given 10 minutes to study the problem domain individually.

2.

Subjects were then asked to complete their design and the facilitator (the principal author in this case) collected their drawings and highlighted the conflicts. Communication between the participants was conducted via the facilitator. Participants were not allowed to talk to each other.

3.

Once the conflicts were identified, each participant was informed of the details of the conflict and asked to revise their design. Participants were allowed to change their minds and subsequently withdraw their initial design.

4.

5.

6.

If this did not resolve differences, subjects were asked to provide alternatives, which were made available to all group members, then asked to review their proposals. If the conflict was still not resolved, participants were asked to provide their level of confidence in the proposed action, and again were asked to review their proposals. Finally, participants were instructed to create a single agreed diagram by discussing their remaining differences face-to-face.

In contrast, the control group subjects were given their problem description to read and work on. When they submitted their work, conflicts were highlighted, and they were allowed to freely discuss them in order to come up with an agreed diagram without any assistance. For each team, the number of conflicts among team members and time taken to resolve them was recorded. At the end of the experiment, each subject in the experimental group filled out a questionnaire that included a number of questions that required a numerical response. The questionnaire also included a space for subjects to describe their impression of the process, and to add any other comments. 5.2 RESULTS The final diagram of each group was assessed and there was found to be no significant difference in their designs with both experimental and control groups producing diagrams of comparable quality. Overall, the quality was somewhat disappointing possibly as a result of the fact that the students did not have significant experience in modelling, and that the practitioners, though actively involved in software engineering also did not necessarily have recent and significant experience with the type of model required. The use of different problem descriptions seemed to make little difference, and in hindsight, a

single problem description contained enough freedom for different interpretation. The two main results were that subjects found the process easy to follow and believed it obtained a better solution. Despite the overhead of the proposed process teams were able to reach agreement more quickly than those who were left to resolve their differences by discussion only. Table 1 shows the average satisfaction score (in a range 1-strongly disagree to 4-strongly agree) by the 30 participants of the experimental group for each question on their post experiment survey. Table 1 shows support for the process. Responses to the open-ended question were brief, but also indicated support for the proposed method. Future experiments could be improved by providing an opportunity for getting better and more targeted qualitative data from participants.

QUESTION

MEAN SCORE (1..4)

The mutual solution obtained was the best after using the CONFER conflict resolution protocol.

3.2 (0.7)

CONFER helped me to obtain a good solution.

2.9 (0.8)

CONFER was very easy to follow.

3.1 (0.8)

I could have done better without CONFER

1.7 (0.8)

Table 1: Satisfaction with CONFER (experimental group) Table 2 shows the number of conflicts identified and the time taken to resolve those conflicts for the group using the proposed CONFER protocol. Table 3 shows the same information for the control group subjects that did not use this protocol. It shows that the proposed protocol as implemented was effective in reducing the time taken to resolve conflicts. The t-test has been used to assess the significance of the difference between the means of the two groups. xexp = 16.1 (Average time taken (mins) by the group not using proposed CONFER protocol (the experimental group)) xcon = 29.7 (Average time taken (mins) by group using the proposed CONFER protocol (the control group)) SE(xexp - xcon) = 2.16 (The Standard error of the difference between the means) t = 6.30 (The t-score) The t-experimental value of 6.30 has the probability of a type 1 error is 6.0-6, which is statistically significant. The results in part support H1, while there is no clear indication that the proposed method reaches a better solution, it does show that it is able to reduce the time taken to achieve consensus, and contributes to the

effectiveness of the conflict resolution process. The questionnaire responses suggest that users are relatively satisfied with the proposed CONFER protocol, supporting H2.

CONFER GROUP ID

NUMBER OF CONFLICTS

TIME TO RESOLVE CONFLICTS (MINS)

1

3

12

2

4

15

3

3

17

4

2

13

5

4

16

6

6

18

7

2

21

8

2

22

9

5

13

10

4

14

Mean

3.5

16.1

Table 2: Results for experimental (CONFER) group.

application of the proposed method was done using pencil, paper and a human facilitator, rather than with purely computer-based mediation. The use of pencil and paper meant that participants had to complete the whole diagram before they could see the work of others, and were deprived of the opportunity of seeing divergence and possibly modifying their actions earlier. While these results are positive, they should be considered preliminary and subject to verification across a wider range of users, tasks and implementations. The incorporation of the proposed method would not appear to require prohibitively expensive or complex development of software. When conflict is detected, users will be able to move into a conflict resolution space, similar to the negotiation process proposed by Slimani et al. (2006). The process would be created as iterative steps where the team could be placed in a particular context, until consensus is reached to move onto the next step in the process. The environment available to participants may include specific tools built around the particular information resources processes as well as general tools and facilities, such as whiteboards, chat, voting mechanisms. There is considerable potential for further work. Further paper and pencil experimentation is warranted, in particular to better consider differences in participants including cultural differences, knowledge and personal differences and preferences. More attention could be given to the collection of qualitative data. Apart from the integration of the conflict resolution process, the prototype itself needs to be expanded to support collaborative editing of a range of artefacts, including diagrams, text and program code. By providing more expert tool support to enhance the collaboration environment, some lower level conflicts resulting from poor knowledge of the tool may have been avoided. There may also be value in escalating the process to a more detailed argumentation phase, if needed. A further potential enhancement is the incorporation of supporting knowledge bases. A particularly attractive focus for future work is on conflict prevention, and more work on conflicts that arise in both the process of software engineering, and in the process of conflict resolution.

CONTROL GROUP ID

NUMBER OF CONFLICTS

TIME TO RESOLVE CONFLICTS (MINS)

11

3

20

12

4

27

13

3

35

14

6

29

15

4

23

16

6

35

17

5

28

18

5

29

19

4

40

7

20

3

31

Mean

4.3

29.7

Collaborative software engineering tools have potential for improving the productivity of software engineering teams. Such tools must deal with conflict as team members work independently and bring different perspectives to the problem. These conflicts are a necessary part of the process of developing an agreed outcome from the software engineering process, and they cannot be managed exclusively at the technical level, but they need new, specific techniques to build consensus and address conflicts. This paper has explored augmenting an existing approach to conflict management at the technical level with an effective means of supporting resolution in the social domain. The Chu-Carrol (2000) model provides a systematic approach to conflict resolution at the social (human) level, guiding users to review and then re-submit their proposal

Table 3: Results for control group.

6

Discussion

While caution needs to be applied in drawing a wide conclusion from these experiments, they provide an indication that the proposed method may be effective in reducing the time to resolve conflicts. Further, the method appeared to be easy to use and gave users confidence in the outcome. These experiments are limited in several ways. The subjects were selected based on convenience, the task was small, the groups were small, and the

Conclusion

with confidence levels and supporting evidence. This process may be able to be used to progress towards agreement avoiding deadlocks, delays and poor outcomes. The effectiveness of the approach has been experimentally tested, showing that the model is potentially useful. In the experiments the time taken to resolve a conflict using the proposed approach was significantly less than when no formal approach was used. Users easily followed the proposed approach and they were generally happy with how conflicts were resolved. From both empirical and conceptual perspectives, the technique shows promise in providing at least some of the techniques needed to build collaboration tools based on more cooperative models of work. Such environments will support the breakdown of distance as a barrier and lead to better outcomes in the software development process. It may also be that these techniques can be adapted to other domains where humans need to work together to produce an agreed outcome.

8

References

Arnold, J. (1995). Toward Collaborative Software Processes. IEEE Transactions on Software Engineering. (26). 107-109. Augustin, L, D. Bressler and G. Smith. (2002). Accelerating Software Development Through Collaboration, ICSE02. May. 559-563. Boehm, B., P.Grunbacher and R.O. Briggs. (2001) Developing Groupware for Requirements Negotiation : Lessons Learned. IEEE Software, May/June. 46-55. Bowen, S. and F. Maurer. (2002). Process Support and Knowledge Management for Virtual Teams Doing Agile Software Development. Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC02). 1-3. Campbell, C. and B. Van De Walle. (2003). Asynchronous Requirements Engineering: Enhancing Distributed Software Development. International Conference on Information Technology: Research and Education, Newark, NJ. Chu-Carroll, J. (2000). Conflicts resolution in collaborative planning dialogs. Int. J. HumanComputer Studies. (53), 969-1015. Cook, C., N. Churcher and W. Irwin. (2004). Towards Synchronous Collaborative Software Engineering. Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC'04).

Damian, D. and A. Eberlein. (2003). An empirical study of groupware support for requirements negotiations in distributed software development. Proc. of the 4th ICSE Workshop on Software Engineering. Freeman. K. and A. Farley. (1996). A model of argumentation and its application to legal reasoning. Artificial Intelligence and Law (Historical Archive). September. 163-167. Gorton, I., I. Hawryszkiewycz, C. Chung and S. Lu. (1997). Groupware Support Tools for Collaborative Software Engineering, IEEE. Kilker, J. (1999). Conflicton Collaborative Design Teams: Understanding the role of Social Identities, IEEE Technology and Society Magazine, Fall, 12-21. Nutter, D. and C. Boldyreff. (2003). Historical Awareness Support and Its Evaluation in Collaborative Software Engineering. Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises. Purvis, Maryam, Martin Purvis and S. Cranefield. (2004). Educational Experiences from a Global Software Engineering (GSE) Project. The 6th Australasian Computing Education Conference. Robillard, P. and M. Robillard. (2000). Types of collaborative work in software engineering. The Journal of Systems and Software. (1), 219-224. Rowe, H. (2000). The Collaborative Delphi, Department of Eco-science, Colorado State University, Fort Collins. Slimani, K., Ferreira Da Silva, C., Medini, L. and Ghodus, P. (2006). Conflict mitigation in collaborative design. International Journal of Production Research (44) 9. 1681-1702. Toulmin, S. (1959). The Uses of Arguments. Cambridge University Press. Wong, F., (2006). CONFER: Addressing conflict detection and resolution in the technical and social domains, Unpublished Master of Applied Science by research thesis, RMIT University. Zha, X.F. and Du, H. (2006). Knowledge-intensive collaborative design modeling and support: part 1: Review, distributed models and framework, Computers in Industry (57) 1. 39-55.