Approaches to Collaborative Software Development - CiteSeerX

International Conference on Complex, Intelligent and Software Intensive Systems

Approaches to Collaborative Software Development Tobias Hildenbrand, Franz Rothlauf, Michael Geisser, Armin Heinzl, and Thomas Kude Department of Information Systems I University of Mannheim, 68131 Mannheim, Germany {hildenbrand, rothlauf, geisser, heinzl, kude}@uni-mannheim.de

Abstract—Software development is becoming more and more complex. Traditionally and to date, the software development process rather corresponds to job-shop manufacturing. Therefore, the ever growing demands for different kinds of software as well as the ongoing globalization require more efficient development processes. Both scientific literature and practical experience hence postulate a necessary industrialization of software development and design of novel forms of specialization, task distribution, and collaboration. Existing approaches to collaborative software development can be classified and analyzed according to multiple categories. By evaluating these, current deficiencies are identified and discussed for further investigation. Index Terms—Collaborative Software Development, Software Engineering, Software Development Processes, Industrialization of Software Production, Inter-Organizational Software Development.

I. I NTRODUCTION

T

HE growing complexity of software and its increasing diffusion into various application domains require higher quality standards in software development processes. Both in theory and practice, a transition to standardization and reuse of software components and processes as well as the automation of particular process steps, i.e. industrialization, is taking place (cf. also [1]). In this connection, the dominating jobshop production is being replaced successively by distributed software development (DSD) processes that are based on industrial production principles. This development is being enforced by an ongoing globalization of software manufacturing and adequate tool support [2]. Instead of monolithic jobshop production, preliminary products of selected suppliers are to be combined to larger software components by means of appropriate software engineering (SE) approaches such as component models and and standards. Within a “pre-industrial” software development process, applications are no longer developed centrally by one software manufacturer, but rather decentrally and concurrently by different companies. This enables an increase of efficiency through division all parallelization of work, although leading to more complicated coordination and communication between the different participants involved in the process. The approaches, in particular methods and tools, developed in the growing field of collaborative software development (CSD) research support these changing conditions. This article thus pursues two major goals: On the one hand, a framework for classifying and evaluating different approaches to DSD and CSD is developed and defined, whereby,

0-7695-3109-1/08 $25.00 © 2008 IEEE DOI 10.1109/CISIS.2008.106

on the other hand, existing approaches can be characterized and compared. This classification and evaluation of the current state-of-the-art in distributed CSD facilitates identifying appropriate methods and tools for distributed and collaborationintensive software development processes as well as finding gaps and deficiencies in the existing set of solutions. In the following section, an initial conceptual foundation is created and distinct dimensions of the classification framework are introduced. Section III classifies and evaluates the different approaches arranging them according to different collaboration-intensive SE process steps, while section IV presents specific collaboration tool support. Section V analyzes the fundamental results from this literature review for persistent deficiencies and particularly against the background of relevant behavioral theories and future challenges. In doing so, the article is mainly aimed at researchers from SE-related fields and also offers motivations and recommendations for practitioners. II. C OLLABORATIVE S OFTWARE D EVELOPMENT The terms “collaboration” and “cooperation” used in the context of this paper are based on literature from ComputerSupported Collaborative Work (CSCW) and SE. They are mostly used synonymously for describing the distributed processing of common software artifacts based on division of labor. In doing so, several authors distinguish multiple levels of collaboration: These consist of (a) informing, (b) coordinating, (c) actually collaborating, and (d) cooperating (definition based on [3], [4]). As opposed to collaboration, cooperation in this taxonomy is conducted by participants with equal rights and individual goals subordinated to one collective target [4, p. 427]. Similar to collaboration, cooperation also implies constant and intensive interaction [3, p. 210]. Furthermore, cooperation features one common process and common outputs such as jointly created documents as well as collective team evaluation and results (cp. [3], p. 210). Collaboration, on the other hand, still implies pursuing some individual, possibly antagonistic, goals [3], [5] often occurring when different departments and/or companies are involved in one common software development process. This might be the case, for instance, when a large company’s ITdepartment collaborates with external consultants and an inhouse department to develop a new software component as part of the overall business application infrastructure. The probability of perfectly congruent goals among the developers

523

and other stakeholder involved decreases with an increasing division of labor and according task distribution. The connotation of “antagonistic goals” is expressed in the way that the term “collaboration”, besides describing distributed work processes, is sometimes also understood as “working together and willingly assist an enemy of one’s country and especially an occupying force” (or competitor)1 . Organisational Distribution

Spatial Distribution

Stakeholders Coordination

Temporal Distribution

Collaboration Process Direction

Communication Technology

Process Intensity

Process Discipline

Figure 1.

Collaborative Software Development Analysis Framework

CSD therefore concerns both methods and tools supporting the different stakeholders’ communication and coordination requirements within a (distributed) software development process. This, however, is essential for planning, execution, and coordination of all task-based as well as organizationally, temporally and spatially distributed activities incorporating all process- and product-related activities of the stakeholders aiming at the development of one (common) software product (cp. [5], p. 20). The interplay of CSD, stakeholder communication and coordination as well as the various framework dimensions is depicted in figure 1. As already indicated in figure 1, CSD can be both characterized by the different dimensions of distribution, the process-based direction as well as the intensity of the common development activities in terms of time spent and frequency. The respective dimensions will be explained in further details in the following and substantiated by relevant literature: Organizational Distribution, meaning the distribution of process steps across several organizational units, is often referred to as “units of distribution” exhibiting either interorganizational or intra-organizational characteristics [6]. High organizational distribution, meaning collaboration of many organizationally divided units of distribution, implies many additional organizational, economic, and legal issues for the software development process (for further details see [6] and [7]). A more fine-grained discrimination of organizational distribution layers is presented by [8]: First, a project-related and business-related level can be distinguished. The project level includes inter-individual and inter-team collaboration whereas the business-level covers collaboration on the company and business environment scale (see also [9]). Spatial distribution distinguishes spatially collocated and 1 cp. Merriam-Webster Online: http://mw1.merriam-webster.com/dictionary/ collaboration (2007-07-30)

spatially distributed organizational units (either inter- or intraorganizationally, see [5]). Even within short distances and spatial barriers such as the the different floors of a building, the lack of personal contact, transfer of tacit knowledge, and informal coordination in daily collaboration can have a direct impact on the means of communication and collaboration [3], [4]. Thus, numerous papers in the DSD field investigate socio-technical implications of spatially distributed software projects [10]. Furthermore, if several independent companies collaborate in these projects (inter-organizational distribution, see above) and/or activities are distributed over different timezones and cultures, as it is the case in offshore software development projects, this additionally affects communication and coordination processes, e.g. through higher organizational and/or national distance as well as language barriers [7], [11]. Complementary, the known classifications of collaboration in the CSCW field and thus also in CSD research also distinguish the temporal distribution of working processes [3], [4]. The question here is whether the development tasks are processed at the same time (synchronously) or at different time (asynchronously). Information, particularly software artifacts like requirements descriptions and design models are either processed synchronously (remote or collocated) or buffered by some sort of information and artifact repository [4], [12]. CSD processes that are not constantly and instantly synchronized are often referred to as concurrent SE (CSE, cp. [5], [13], [14]). As regards coordination, CSE is conducted asynchronously even if there are no time differences or similar temporal barriers. The authors claim CSE to be more efficient due to highly parallel task distribution among independent actors. The process direction indicates, from an economical perspective, whether collaboration occurs within or in-between certain value creation phases of the SE process. SE can basically be divided into single process steps or into distinct disciplines as regards content, respectively. These consist of analysis, design, and implementation (cp. Rational Unified Process, RUP). “Discipline” is deliberately preferred rather than “phases”, because the latter already implies a particular process model, here, a sequential waterfall model. Hence, two characteristics can be distinguished regarding the process direction: horizontal collaboration within one discipline and vertical collaboration as inter-disciplinary forms of collaboration spanning several value creation stages (cp. [4]). In the wake of ever growing industrialization and organizational distribution, some authors also distinguish the process direction by means of software value chains [6]. The process direction is determined by the relationship between the collaboration partners in these value chains during the inter-organizational collaboration [6]. Horizontal collaboration relationships can be found among companies on the same value creation stage [6], whereas vertical relationships correspond to a suppliercustomer relationship, e.g. when the requirement specification is created by one company and the corresponding design concept by another one [15]. Collaboration within the SE process features different intensities of interaction processes. The higher the information flow between the various actors and the more frequent and/or

524

comprehensive this occurs, the higher the intensity [3], [11]. The intensity is determined by the fact whether work on an object is actually done collectively or collaboration just occurs through the systematic exchange of knowledge-based services and/or software components [6], [16]. CSD processes, both horizontal and vertical, exhibit uneven levels of participant involvement in collective endeavors [3], which results in the various existing roles. From a legal perspective, the intensity of inter-organizational (organizationally distributed) software development can also be classified depending on to what extent a loose, a contract, or a capital-based relationship is the case. As opposed to strategic alliances, joint ventures, for instance, require a common investment (capital-based relationship) and thus usually result in more intensive collaboration, since costs and revenue are distributed between the companies involved [15]. Thus CSD particularly implies frequent interaction with intensive knowledge exchange among the distributed stakeholders persuing potentially antagonistic goals (cp. [3], [6], [17]). Based on these possible task distribution dimensions and process characteristics, a software development scenario is called collaborative, if it features one or more of the following characteristics: • organizational distribution (between several departments and/or companies), • temporal distribution (i.e. asynchronous collaboration processes) and • spatial distribution (between several locations and/or floors). Taken together, these three task distribution dimensions account for the the quintessential determinants of CSD scenarios. Increasing organizational, temporal, and/or spatial distribution, affects a software development process negatively regarding the congruence of the stakeholders’ goals and thus distinguishes CSD from strictly collective SE cooperation (cp. [3], [4]). The transition from the strictly collective, noncollaborative cooperation and CSD is fluent and sometimes diffuse. However, a software development process becomes more collaborative by increasing organizational, spatial, and/or temporal distribution. Besides these characteristics of distribution, more of the following process-based characteristics leads to an increase of the collaborative character of a software development scenario: • a vertical, interdisciplinary teamwork (spanning several phases between different roles) with a simultaneously • high intensity of the working process (as regards time spent and frequency of interaction). Analogously to the organizational, temporal, and spatial distribution, the collaborative character of the software development process becomes predominant with an increase in these two criteria. CSD processes therefore usually require specific tool support (cf. [6], [10], [14], see also section IV). As a preliminary conclusion, CSD distinguishes itself from other software development processes with respect to the degree of organizational, temporal, and/or spatial distribution. However, the working process nevertheless is supposed to remain intense, phase-spanning, and interdisciplinary. Selected

approaches that satisfy one or more of the CSD requirements are introduced and analyzed in the following section. III. C OLLABORATIVE D EVELOPMENT M ETHODS In SE, process-oriented approaches examine formally structured procedures , e.g. in the form of process models. Examples are the sequential and iterative models (waterfall and spiral model) as well as more recent process frameworks like the RUP. The individual SE disciplines, from customer requirements elicitation in RE to the deployment of the final software, account for a structured organization of the processes. Since there are no process models for a vertically continuous and collaboration-intensive SE process up to now (cp. section II), existing fragmental approaches are organized vertically alongside the value chain. Thus, we differentiate and analyze articles containing collaborative approaches from the fields of (1) RE, (2) design and modeling as well as (3) implementation, testing, and maintenance. A. Collaborative Requirements Engineering Up to now, various collaborative approaches to requirement elicitation and analysis have been developed and evaluated. Since many stakeholders’ interests have to be coordinated and consolidated in this early project phase [18, p. 118], so far, some interesting approaches to collaborative RE (CRE) have been developed within the SE field. They differ in the type of distribution supported as well as regards the tool infrastructure provided. The WinWin spiral model is based on the Theory W, developed accordingly to the Harvard concept of negotiation techniques [19]. Its basic assumption is that the success of CSD projects depends on all involved parties to positively gain benefits from the collaboration and the different requirements to be equally represented. To accomplish this, asymmetric winlose situations between individual stakeholders are avoided through systematic negotiation and moderation techniques to minimize the overall project risk. WinWin represents an appliance of this theory and an enhancement to the original spiral model at the same time. Here, changing interests of various stakeholders as well as their coordination throughout several iterations are considered by consolidating them continuously resulting in high collaboration intensity. Up to now, the EasyWinWin method represents the fourth generation of the WinWin approach [20]. EasyWinWin (EWW) is characterized by a flexible, iterative elicitation process that also allows integrating new participants in the ongoing process. Furthermore, the establishment of trust is encouraged through physical meetings and moderated discussions. The methodology is however complex and in despite of its specific groupware not primarily conceived for a distributed environment. Collaboration occurs with high intensity and partially asynchronously. The groupware-based version ARENA enables the reduction of complexity, spatially distributed work, and asynchronous information exchange, e.g. by logging discussions [21]. However, ARENA only allows asynchronous but distributed and mobile collaborative requirement elicitation. Due to technical

525

reasons, ARENA however can no longer be combined with the earlier WinWin groupware [21]. B. Collaborative Design and Modeling Processes Collaborative design and modeling (CDM) processes convert requirement specifications into both architectural and more detailed component models as a basis for the subsequent implementation as source code. Collaborative approaches are frequently transferred from other engineering disciplines (e.g. from Computer-Aided and Concurrent-Design processes in the automobile industry). Initial approaches which will not be further addressed here were Joint Application Design (JAD) [22] as well as Participatory Design (PD) [23]. Concurrent design processes [13], such as the Collaborative Software Engineering Methodology (CSEM), are more and more incorporated into UML-based methods for model-driven software development (MDD) and eventually automatic source code generation from models. Even though there are so far not many theoretically sound methodologies in this field, modern development tools such as, for instance, Gentleware Poseidon and IBM Rational XDE allow concurrent DSD and MDD processes (Concurrent MDD, CMDD). The current UML software supports asynchronous, distributed collaboration by managing and versioning the models centrally, similar to source code in configuration managements systems like Subversion. The methods mentioned provide at least server-side repositories with the ability to register changes in the models and to determine discrepancies. Conflicts due to modification by different developers on a model can therefore also be reduced similarly to code versioning in a Subversion system. C. Collaboration in Implementation, Testing and Maintenance Due to their direct relation to source code as primary artifact, approaches to collaborative implementation, testing and maintenance (CITM) already feature a higher tool orientation as the ones discussed in the previous disciplines. Collaboration-intensive processes can be supported synchronously in form of both shared workspaces and application sharing (Collaborative Editing) and/or asynchronously through versioning systems [2], [14]. By now, various tools like SubEthaEdit enable editing source code files collaboratively. Here, developers see the respective changes made by their spatially distributed colleagues directly in the document. The methodological support for the implementation-based collaboration processes however is still neglected in academic research. In practice, a return to socio-technical problems can be observed within the general field of CSD [24]. As a part of this trend, particularly people-centered approaches for small to medium-sized development groups, so-called agile development methods, for instance Extreme Programming (XP) are subject to investigations [25]. Distinctive collaborationintensive processes within XP are pair programming, where two collocated developers simultaneously work on one part of the source code and alternately one codes and the other one evaluates the code as well as continuous CRE, i.e. the customer is highly integrated on-site. However, XP features only little methodical guidance and neither considers spatial

nor temporal distribution. A possible organizational distribution of development tasks is not specified to this approach either. Yet, there are some first approaches to apply XP in a spatially distributed environment through the use of appropriate tools for overcoming distance like Voice-over-IP, video conferencing, and parallel, synchronous editing of source code (collaborative editing, see above). Collaboration-intensive, code-centric processes, that are also efficient and effective in large, distributed projects, have been established within various open source software development projects [22], [26]. Moreover, both the Collaborative Software Inspection and Collaborative Asynchronous Inspection of Software methods are distributed approaches to collaborative quality assurance, based on hypertext as a part of the post-implementation disciplines of testing, and maintenance. It features a tool-based method for the distributed asynchronous source code inspection that aims at minimizing synchronous physical meetings [27]. Approaches to distributed and asynchronous maintenance of software (e.g. collaboration in software maintenance, [28]) also fall into this category. The latter approach supports distributed collaboration among several software engineers by providing a hypertext-based system to record maintenance decisions and to reference to source code which is also belongs to traceability and rationale management activities. IV. C OLLABORATION T OOL S UPPORT On the basis of existing Groupware and integrated development environments (IDE) functionality, Collaborative Software Development Platforms (CSDPs) offer centralized coordination and communication capabilities for asynchronous and synchronous collaboration processes for highly distributed teams of developers over the Internet while integrating traditional tool support. As a first proof-of-concept, they are already used successfully within numerous open source projects [22], [26]. Hence, in addition to commercial solutions, there are various open source and experimental approaches from research projects. As regards commercial solutions, platforms like SourceForge represent specialized enhancements of server-based CSCW solutions [22]. The basic functionalities of a collaboration platform can be distinguished into the three major categories (1) “coordination”, (2) “collaboration”, and (3) “community building”, which is a new feature compared to the aforementioned solutions (cp. [3]). In addition to SCM systems, asynchronous and synchronous communication tools (forums, wikis, chats, etc.), CSDPs also feature detailed task management with issue trackers [29], [30]. CSDPs thus allow for better traceability of individual process steps as well as relationships between different software artifacts among each other and their authors and contributors (cp. [18], p. 163) and [24]). CSDPs can be accessed either through an IDE plugin or directly via browser [29]. For inter-organizational scenarios, a CSDP can also be provided by an independent vendor as an application service (software-as-a-service) over the Internet. As opposed to IDEs, CSDPs cover all functions necessary for a vertically-continuous and collaboration-intensive development

526

process. In addition to asynchronous information exchange, synchronous collaboration processes are more and more supported through complementary tools like instant messaging or voice services [10], [11]. Server-based CSDP solutions therefore cover a maximum of tool-related requirements for conducting CSD projects (cp. section II and [30]). Established requirements management tools, on the other hand, do not provide sufficient support for distributed collaboration (see analyses in [31] and [32]). As has been mentioned before, in addition to existing commercial collaboration platforms, there are many experimental and prototypical ones. Their specific features as compared to standard commercial CSDPs available on the market (cp. [29]) will be addressed in the following. For preparing this article, a total of 12 experimental platforms were analyzed [15]. None of the experimental platforms systematically differentiates and supports intra- and inter-organizational collaboration scenarios. However, these approaches can be distinguished by different considerations of temporal distribution as well as intended collaboration-intensity. Comprehensive and continuous support for vertical, collaboration-intensive CSD processes is only provided by ConversationBuilder, GENESIS, JAZZ, and MILOS. These approaches are therefore further analyzed in the following: ConversationBuilder supports common management and versioning artifacts as well as distributed collaboration in the form of so-called “conversations” [33]. GENESIS (GEneralised eNvironment for procEsS management in cooperatIve Software engineering) includes workflow as well as artifact management systems and features extensive coordination and communication functions. Both process- and product-based software projects are supported, while GENESES utilizes its own language to define the processes [34]. The JAZZ project, actively supported by IBM Research, constitutes a collaborative enhancement to the open source delelopment tool “Eclipse”. Its main approach is to leave the users in their familiar IDE environments and simply provide context-based enhancements for more intense collaboration within software projects (see [35]). MILOS, on the other hand, provides tools for collaborative process modeling, project planning, and implementation as well as traceability management and change notification. Additionally, it is compatible to Microsoft Project [36]. CSDPs have proven to be efficient in collaboration-intensive scenarios like, for instance, highly distributed and specialized open source projects or globally-distributed offshore development projects (cp. section II and [7]). The use of traditional methods and tools in large-scale distributed projects however consistently leads to problems within the individual disciplines due to vertical barriers as regards the overall process [15]. V. D ISCUSSION AND C ONCLUSION The goal of this paper is to create a systematic overview of existing approaches to CSD from a SE process perspective. For this purpose, three dimensions of collaboration in SE contexts as well as different categories of approaches are identified from academic literature. This analysis and classification

framework consists of the organizational, spatial, and temporal distribution of SE tasks, process direction, and collaboration intensity (see figure 1). Based on these criteria, methodological (process-related) approaches as well as existing collaboration tool support are taken into consideration. As a conclusion from analyzing and comparing these existing approaches, strictly tool-based CSD approaches prevail significantly in terms of frequency and state of elaboration. Existing process models and frameworks neither dedicatedly address different dimensions and characteristics of a verticallyintegrated CSD process, nor do they attempt to consolidate existing horizontal approaches to particular SE disciplines (cp. sections III-A to III-C). Predominantly, existing processrelated approaches focus on RE tasks. Many development methodologies and particularly the collaboration tools applied in commercial large-scale distributed projects originate from open source contexts [29]. Open source methods and tools are however not easily applicable and transferable to commercial environments and require methodological modifications and adaptations [15]. Furthermore, only a few approaches examine questions of behavioral theories from social sciences as regards collaboration-intensive software development and the associated socio-technical issues. Therefore, there is still a lack of approaches attempting to identify methodical CSD support based on behavioral science and socio-technical theories including tool infrastructure (cp. also [9]). Thus, in future research, there is still a need for further investigations regarding the support of CSD processes in terms of both theoretical and practical points of view. From a practical standpoint, there is a need for developing solution approaches including methodological and tool-related SE support for distributed collaboration-intensive processes while at the same time considering socio-technical issues. In doing so, the biggest challenge lies in developing and introducing integrated approaches for this interdisciplinary and practically relevant problem. Future CSD research has to support the companies to find the appropriate methods and tools for various collaboration contexts regarding their respective requirements. Furthermore, specific quality standards have to be maintained within companies from different business environments (cp. section II and [8]), like for instance bi-directional end-to-end traceability of the entire development process as prescribed by the capability maturity model (integration) and numerous other process quality standards. Moreover, other industryspecific standards, like the US Food and Drug Administration (FDA) in the medical engineering field, also require process transparency and traceability of all process steps of SE for medical products. Especially in the case of high distribution of resources and high collaboration intensity, in typical CSD processes, traceability requirements represent a major challenge. From a more academic perspective, it has to be concluded, that the approaches and tools introduced are rarely based on sound theoretical assumptions and analyses regarding the empirical behavior of team members and social interaction processes. Therefore, combining SE knowledge with behavioral theories from social science should be one main task in future research. As a starting point, the social exchange theory,

527

the resource dependency theory, and/or the theory of planned behavior could be applied to CSD scenarios. Based on these and other theories, it is to be examined how SE processes, group behavior, and tool application has to be designed so that the software products are developed efficiently with an uncompromised level of quality (cp. [3], p. 208). To overcome the different dimensions of distribution, several SE methods and tools can be applied, whereas they were initially not designed based on behavioral theories. Research in the field of Human-Computer Interaction has already proven the feasibility and usefulness of behavioral theories on an individual level. Therefore, an ensuing challenge lies in the interdisciplinary examination of group behavior (human focus), development processes (task focus) and tool support (technology focus). The growing number of global and offshore development scenarios underlines the rising relevance of this multi-faceted perspective on collaboration and coordination issues in practical environments (for an empirical analysis of offshore development scenarios see [7]). R EFERENCES [1] R. Kilian-Kehr, O. Terzidis, and D. Voelz, “Industrialisation of the software sector,” Wirtschaftsinformatik, vol. 49, no. Sonderheft, pp. 62– 71, 2007. [2] D. Redmiles, A. van der Hoek, B. Al-Ani, T. Hildenbrand, S. Quirk, A. Sarma, R. S. S. Filho, C. de Souza, and E. Trainer, “Continuous coordination: A new paradigm to support globally distributed software development projects,” WIRTSCHAFTSINFORMATIK, vol. 49, no. Sonderheft, pp. S28–S38, 2007. [3] J. H. Bair, “Supporting cooperative work with computers: Addressing meetingmania,” in Proceedings of the 34th IEEE Computer Society International Conference: Intellectual Leverage (COMPCON’89). IEEE Computer Society, 1989, pp. 208–217. [4] H. Krcmar, “Computerunterst¨utzung f¨ur die gruppenarbeit: zum stand der computer supported cooperative work forschung,” WIRTSCHAFTSINFORMATIK, vol. 34, no. 4, pp. 425–437, 1992. [5] J. Altmann and G. Pomberger, “Cooperative software development: Concepts, model and tools,” in Proceedings of the TOOLS-30 Conference (TOOLS-30’99). IEEE Computer Society, 1999, pp. 194–277. [6] D. G. Messerschmitt and C. Szyperski, Software Ecosystem: Understanding an Indispensable Technology and Industry. Cambridge, USA: MIT Press, 2003. [Online]. Available: http://mitpress.mit.edu/softeco/(28.04.2005) [7] J. Dibbern, J. Winkler, and A. Heinzl, “Explaining variations in client extra costs between software projects offshored to india,” MIS Quarterly, no. Special Issue on Information Systems Offshoring, 2008, accepted for publication. [8] B. Curtis, H. Krasner, and N. Iscoe, “A field study of the software design process for large systems,” Communications of the ACM, vol. 31, no. 11, pp. 1268–1287, 1988. [9] T. Hildenbrand, F. Rothlauf, and A. Heinzl, “Ans¨atze zur kollaborativen softwareerstellung,” WIRTSCHAFTSINFORMATIK, vol. 49, no. Sonderheft, pp. S72–S80, 2007. [10] J. D. Herbsleb and A. Mockus, “An empirical study of speed and communication in globally distributed software development,” IEEE Transactions on Software Engineering, vol. 29, no. 6, pp. 481–494, 2003. [11] E. Carmel and R. Agarwal, “Tactical approaches for alleviating distance in global software development,” IEEE Software, vol. 18, no. 2, pp. 22–29, 2001. [12] J. DeFranco-Tommarello and F. P. Deek, “Collaborative problem solving and groupware for software development,” Information Systems Management, vol. 21, no. 1, pp. 67–80, 2004. [13] P. Dewan and J. Riedl, “Toward computer-supported concurrent software engineering,” IEEE Computer, vol. 26, no. 1, pp. 17–27, 1993. [14] A. van der Hoek, D. Redmiles, P. Dourish, A. Sarma, R. Silva Filho, and C. de Souza, “Continuous coordination: A new paradigm for collaborative software engineering tools,” in Proceedings of the 26th International Conference on Software Engineering (ICSE’04), Workshop on Directions in Software Engineering Environments (WoDiSEE’04). IEEE Computer Society, 2004, pp. 29–36.

¨ [15] T. Hildenbrand, M. Geisser, and M. Nospers, “Die Ubertragbarkeit der open source-entwicklungsmethodik in die unternehmenspraxis,” Softwaretechnik-Trends, vol. 26, no. 1, pp. 37–42, 2006. [16] D. L. Dean, J. D. Lee, M. O. Pendergast, A. M. Hickey, and J. F. N. Jr., “Enabling the effective involvement of multiple users: Methods and tools for collaborative software engineering,” Journal of Management Information Systems, vol. 14, no. 3, pp. 179–222, 1998. [17] D. A. Harrison, K. H. Price, J. H. Gavin, and A. T. Florey, “Time, teams, and task performance: Changing effects of surface- and deeplevel diversity ongroup functioning,” Academy of Management Journal, vol. 45, no. 5, pp. 1029–1045, 2002. [18] I. Sommerville, Software Engineering, 8th ed. Boston, USA: AddisonWesley, 2007. [19] B. W. Boehm and P. Bose, “A collaborative spiral software process model based on theory w,” in Proceedings of the 3rd International Conference on the Software Process (ICSP’94). IEEE Computer Society, 1994, pp. 59–68. [20] P. Gr¨unbacher, “Integrating groupware and case capabilities for improving stakeholder involvement in requirements engineering,” in Proceedings of the 26th EUROMICRO Conference (EUROMICRO’00). IEEE Computer Society, 2000, pp. 2232–2239. [21] B. W. Boehm, P. Gr¨unbacher, and R. O. Briggs, “Developing groupware for requirements negotiation: Lessons learned,” IEEE Software, vol. 18, no. 3, pp. 46–55, 2001. [22] L. Augustin, D. Bressler, and G. Smith, “Accelerating software development through collaboration,” in Proceedings of the 24rd International Conference on Software Engineering (ICSE’02). IEEE Computer Society, 2002, pp. 559–563. [23] M. J. Muller and S. Kuhn, “Participatory design,” Communications of the ACM, vol. 36, no. 6, pp. 24–28, 1993. [24] C. R. B. de Souza, T. Hildenbrand, and D. Redmiles, “Towards visualization and analysis of traceability relationships in distributed and offshore software development projects,” in Proceedings of the 1st International Conference on Software Engineering Approaches for Offshore and Outsourced Development (SEAFOOD’07). Springer, 2007. [25] K. Beck, “Embracing change with extreme programming,” IEEE Computer, vol. 32, no. 10, pp. 70–77, 1999. [26] J. Feller and B. Fitzgerald, Understanding Open Source Software Development. Boston, USA: Addison-Wesley, 2001. [27] V. Mashayekhi, J. M. Drake, W.-T. Tsai, and J. Riedl, “Distributed, collaborative software inspection,” IEEE Software, vol. 10, no. 5, pp. 66–75, 1993. [28] R. Lougher and T. Rodden, “Supporting long-term collaboration in software maintenance,” in Proceedings of the Conference on Organizational Computing Systems (COCS’93). ACM Press, 1993, pp. 228–238. [29] J. Robbins, “Adopting open source software engineering (osse) practices by adopting osse tools,” in Free/Open Source Processes and Tools, J. Feller, B. Fitzgerald, S. A. Hissam, and K. R. Lakhani, Eds. Cambridge, USA: MIT Press, 2005, pp. 245–264. [Online]. Available: http://www.ics.uci.edu/∼jrobbins/papers/robbins-msotb.pdf [30] F. Rodriguez, M. Geisser, K. Berkling, and T. Hildenbrand, “Evaluating collaboration platforms for offshore software development scenarios,” in Proceedings of the 1st International Conference on Software Engineering Approaches For Offshore and Outsourced Development (SEAFOOD’07). Springer, 2007, pp. 96–108. [31] M. Geisser, T. Hildenbrand, and N. Riegel, “Evaluating the applicability of requirements engineering tools for distributed software development,” Working Paper des Lehrstuhls f¨ur ABWL und Wirtschaftsinformatik der Universit¨at Mannheim, no. 2, 2007. [32] C. Hood, S. M¨uhlbauer, and C. Rupp, iX-Studie: Anforderungsmanagement, 2nd ed. Hannover, Deutschland: Heise Zeitschriften Verlag, 2007. [33] S. M. Kaplan, W. J. Tolone, A. M. Carroll, D. P. Bogia, and C. Bignoli, “Supporting collaborative software development with conversationbuilder,” in Proceedings of the 5th ACM SIGSOFT Symposium on Software Development Environments (SDE’92). ACM Press, 1992, pp. 11–20. [34] M. Gaeta and P. Ritrovato, “Generalised environment for process management in cooperative software engineering,” in Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC’02). IEEE Computer Society, 2002, pp. 1049–1053. [35] L.-T. Cheng, C. R. de Souza, S. Hupfer, J. Patterson, and S. Ross, “Building collaboration into ides,” ACM Queue, vol. 1, no. 9, pp. 40–50, 2003. [36] F. Maurer, G. Succi, H. Holz, B. K¨otting, and B. Dellen, “Software process support over the internet,” in Proceedings of the 21st International Conference on Software Engineering (ICSE’99). IEEE Computer Society, 1999, pp. 642–645.

528