See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4369370

Approaches to Collaborative Software Development

Conference Paper  in  Business and Information Systems Engineering the international journal of Wirtschaftsinformatik · April 2008
DOI: 10.1109/CISIS.2008.106 · Source: IEEE Xplore

CITATIONS READS
42 1,836

5 authors, including:

Franz Rothlauf Thomas Kude

Johannes Gutenberg-Universität Mainz ESSEC - Ecole Supérieur des Sciences Economiques et Commerciales
246 PUBLICATIONS   3,501 CITATIONS    57 PUBLICATIONS   896 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Agent-oriented software View project

Governance Practices in Platform Ecosystems of the Enterprise Software Industry View project

All content following this page was uploaded by Franz Rothlauf on 29 September 2015.

The user has requested enhancement of the downloaded file.

 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 pro-
cess 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 devel-
opment and design of novel forms of specialization, task distri-
bution, 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 Develop-
ment.
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 job-
shop 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 manufactur-
ing and adequate tool support [2]. Instead of monolithic job-
shop 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 differ-
ent 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 ap-
proaches to DSD and CSD is developed and defined, whereby,
0-7695-3109-1/08 $25.00 © 2008 IEEE 523
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 ap-
propriate methods and tools for distributed and collaboration-
intensive 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 frame-
work 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 ana-
lyzes 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 Computer-
Supported Collaborative Work (CSCW) and SE. They are
mostly used synonymously for describing the distributed pro-
cessing 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 out-
puts 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 IT-
department collaborates with external consultants and an in-
house department to develop a new software component as
part of the overall business application infrastructure. The
probability of perfectly congruent goals among the developers
and other stakeholder involved decreases with an increasing
division of labor and according task distribution. The con-
notation 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
Stakeholders
Spatial Temporal
Distribution Coordination Distribution
Collaboration
Communication
Process Process
Direction Intensity
Technology
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 pro-
cess. 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 aim-
ing 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 inter-
organizational 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 dis-
tribution 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)
524
spatially distributed organizational units (either inter- or intra-
organizationally, 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 time-
zones 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 syn-
chronized 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 per-
spective, 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 collabo-
ration spanning several value creation stages (cp. [4]). In the
wake of ever growing industrialization and organizational dis-
tribution, 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 supplier-
customer 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 in-
tensities of interaction processes. The higher the information
flow between the various actors and the more frequent and/or
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 stake-
holders 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 sce-
narios. Increasing organizational, temporal, and/or spatial dis-
tribution, 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, non-
collaborative 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 distribu-
tion, 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 de-
velopment 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
525
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 struc-
tured procedures , e.g. in the form of process models. Ex-
amples 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 require-
ments 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 win-
lose situations between individual stakeholders are avoided
through systematic negotiation and moderation techniques to
minimize the overall project risk. WinWin represents an appli-
ance 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 discus-
sions. 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]. How-
ever, ARENA only allows asynchronous but distributed and
mobile collaborative requirement elicitation. Due to technical
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 con-
vert 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 pro-
cesses (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, test-
ing and maintenance (CITM) already feature a higher tool
orientation as the ones discussed in the previous disci-
plines. Collaboration-intensive processes can be supported
synchronously in form of both shared workspaces and appli-
cation sharing (Collaborative Editing) and/or asynchronously
through versioning systems [2], [14]. By now, various tools
like SubEthaEdit enable editing source code files collabora-
tively. 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 devel-
opment methods, for instance Extreme Programming (XP)
are subject to investigations [25]. Distinctive collaboration-
intensive 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
526
nor temporal distribution. A possible organizational distribu-
tion 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 appro-
priate 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 Soft-
ware Inspection and Collaborative Asynchronous Inspection
of Software methods are distributed approaches to collab-
orative quality assurance, based on hypertext as a part of
the post-implementation disciplines of testing, and mainte-
nance. 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 de-
velopment 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 tradi-
tional 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 var-
ious open source and experimental approaches from research
projects.
As regards commercial solutions, platforms like Source-
Forge represent specialized enhancements of server-based
CSCW solutions [22]. The basic functionalities of a collab-
oration 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
process. In addition to asynchronous information exchange,
synchronous collaboration processes are more and more sup-
ported 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 com-
mercial 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 differenti-
ates and supports intra- and inter-organizational collaboration
scenarios. However, these approaches can be distinguished by
different considerations of temporal distribution as well as in-
tended 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 (GEner-
alised 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 develop-
ment 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 iden-
tified from academic literature. This analysis and classification
527
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 ex-
isting 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 vertically-
integrated CSD process, nor do they attempt to consolidate
existing horizontal approaches to particular SE disciplines
(cp. sections III-A to III-C). Predominantly, existing process-
related 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 exam-
ine 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 in-
cluding 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 solu-
tion 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 com-
panies 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 industry-
specific 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 chal-
lenge.
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 behav-
ioral theories from social science should be one main task in
future research. As a starting point, the social exchange theory,
 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, sev-
eral 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 in-
terdisciplinary examination of group behavior (human focus),
development processes (task focus) and tool support (tech-
nology 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. Son-
derheft, pp. S28–S38, 2007.
[3] J. H. Bair, “Supporting cooperative work with computers: Addressing
meetingmania,” in Proceedings of the 34th IEEE Computer Society In-
ternational Conference: Intellectual Leverage (COMPCON’89). IEEE
Computer Society, 1989, pp. 208–217.
[4] H. Krcmar, “Computerunterstützung für 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: Con-
cepts, 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ätze zur kollaborativen
softwareerstellung,” WIRTSCHAFTSINFORMATIK, vol. 49, no. Sonder-
heft, 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 Man-
agement, 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.
528
View publication stats
[15] T. Hildenbrand, M. Geisser, and M. Nospers, “Die Übertragbarkeit
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 deep-
level diversity ongroup functioning,” Academy of Management Journal,
vol. 45, no. 5, pp. 1029–1045, 2002.
[18] I. Sommerville, Software Engineering, 8th ed. Boston, USA: Addison-
Wesley, 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ünbacher, “Integrating groupware and case capabilities for improv-
ing stakeholder involvement in requirements engineering,” in Proceed-
ings of the 26th EUROMICRO Conference (EUROMICRO’00). IEEE
Computer Society, 2000, pp. 2232–2239.
[21] B. W. Boehm, P. Grünbacher, 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 devel-
opment 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 visualiza-
tion 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 Com-
puter, vol. 32, no. 10, pp. 70–77, 1999.
[26] J. Feller and B. Fitzgerald, Understanding Open Source Software De-
velopment. 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 soft-
ware 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, “Evaluat-
ing collaboration platforms for offshore software development scenar-
ios,” 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ür ABWL und Wirtschaftsinformatik der
Universität Mannheim, no. 2, 2007.
[32] C. Hood, S. Mühlbauer, and C. Rupp, iX-Studie: Anforderungsmanage-
ment, 2nd ed. Hannover, Deutschland: Heise Zeitschriften Verlag, 2007.
[33] S. M. Kaplan, W. J. Tolone, A. M. Carroll, D. P. Bogia, and C. Big-
noli, “Supporting collaborative software development with conversa-
tionbuilder,” 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 man-
agement 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ötting, and B. Dellen, “Software
process support over the internet,” in Proceedings of the 21st Interna-
tional Conference on Software Engineering (ICSE’99). IEEE Computer
Society, 1999, pp. 642–645.