Seminar Paper by Lorenz Hartmann

INVESTIGATING THE INDUSTRIALABILITY OF GLOBAL DISTRIBUTED SOFTWARE
DEVELOPMENT PROJECTS
Seminar paper
submitted: April 2009

by: Lorenz Hartmann
20th of April, 1985
Bad Schwalbach
Student-ID: 1016673
University Mannheim
Lehrstuhl für ABWL und Wirtschaftsinformatik
D – 68131 Mannheim
Phone: +49 621 1811691, Fax +49 621 1811692
Internet: http://wifo1.bwl.uni-mannheim.de/
Content
1 Introduction and purpose.................................................................................................1
2 Basics of software engineering.........................................................................................2

2.1 Key characteristics......................................................................................................2
2.2 Plan based approach....................................................................................................3
2.3 Software crisis and paradigm revisal..........................................................................4
3 Industrialized software development..............................................................................5

3.1 Definition of industrialized software development.....................................................5
3.2 A new software engineering method: agile development...........................................8
3.3 Implications to review SE the global context...........................................................10
4 The global perspective....................................................................................................11

4.1 Global software development...................................................................................11
4.2 Problems of GSD......................................................................................................12
4.3 Approaches to tackle the problems of GSD..............................................................13
4.3.1 Established approaches.................................................................................14
4.3.2 Open source software development (OSSD)................................................17
4.3.3 Tools for distribured collaborative development and how they can
change current development practice........................................................................19
5 Discussion.........................................................................................................................22
FiguresY
Figure 1: Waterfall modell (Royce 1987)...........................................................................3

Figure 2: Cost overun in projects (The Standish Group 1994)...........................................4
Figure 3: Impacts of distance {{28 Carmel,E. 2001}}.....................................................12
Tables
YTable 1: Spectrum of software artifacts (Taubner 2005, Kilian-Kehr et al. 2007)

Table 2: Evaluation of collaboration tool categories (Hildenbrand 2008)........................20
Abbreviations
CSDP Collaborative software development platforms

GSD Global software development
IDE Integrated development environments
OSSD Open source software development
SDP Software development process
SE Software engineering
Keywords
Industrialization of software development

Global software development
Collaborative software development platforms
Agile development
1 Introduction and purpose
By investigating the industrialability of global distributed software development
projects one is faced primarily with the following problem set: To which amount is it
possible to standardize processes, automate tasks and employ reusable components in
software development practice in the general and in the global case. To answer this
question one has to know what software engineering 1 (SE) exactly means, which kind of
software development approaches are available and why/how they are applicable to the
various forms of software products. Furthermore it is important to understand that
matured knowledge about software development in a collocated situation exists.
However there is high uncertainty how to adapt this knowledge to new trends and
developments in a globalized world (Herbsleb, Moitra 2001). For instance projects are
increasingly characterized by globally distributed projects teams. This leads to
difficulties in communication, control and coordination. (Carmel, Agarwal 2001)
This paper will give a general introduction to software engineering (cp. 2) and review
the current state of industrialization in software development practice (cp. 3). In the
main part of the paper the issue will be transferred to the global basis. Different
dimensions which influence the current global software development practice will get
introduced (cp. 4.1). Especially the question how to deal with distance will be assessed
by referring to case studies and new findings of research (cp. 4.3.1). The reader will get
to know why there is a strong emphasize for standardization of processes in global
distributed software development. Additionally the reader will also learn that there are
experts who try to change this tendency of standardization towards higher vitality in SE
by using new communication methods (cp. 4.3.2, 4.3.3). Later it will be presented how
global software development might support the tendency for further industrialization in
SE. There will be a final discussion about the current state, the limits and trends of
industrialization in SE (cp. 5).
1
Software engineering (SE) and software development (SD) are used synonymously in the paper.
2 Basics of software engineering 2
2 Basics of software engineering
2.1 Key characteristics

Software engineering differs significantly from other engineering disciplines; this is not
only because it is still a juvenescent science that started to develop from scratch just 50
years ago. It also differentiates from others due to the extensive need for customer
involvement and its attitude to require knowledge from various fields, especially the
computing- and application domain (Walz et al. 1993). Another difference is the lower
degree of industrialization in contrast to other engineering disciplines. Some experts
point out that SE still “has indications of craft manufacturing” (Janßen 2005, p.284) and
emphasize the high knowledge intensity and the creative attitude of SE (Meyer 2006).
In contrast to other engineering disciplines SDPs are characterized by an empirical and
nonlinear proceeding (Williams, Cockburn 2003). But nonetheless it has to be regarded
that for some software products mass production could already be established (e.g.
operating system, office applications, etc.). So obviously there are many aspects to take
care of by looking at the current state of software development. But before getting lost
into detail, the basics about this topic should get introduced. In the following it will be
described what software engineering is and how it has developed.
Sommerville defines software engineering as an “engineering discipline that is

concerned with all aspects of software production from the early stage of system
specification to maintaining the system after it has gone into use.” (2007, p.7)
According to his taxonomy it consists of four main activities. In the software
specification part engineers and software users define the requirements of the software
to be developed. The software development phase includes the design of the
software/software system and its implementation. This step is seamlessly linked with
software validation, which covers unit and system testing besides reinsuring the
requirements of the customer. In the software evolution phase software is adapted to
customer and market requirement. Analysis as well as maintenance of the existing
system is done. Obviously the phases are overlapping extensively and are not
representing a serial process. They should be seen as an underlying generic framework
of the main models of software development which have evolved until today
(Sommerville 2007)
2.2 Plan based approach

The first approaches which derived from software engineering research were plan based
software processes. The most known model is the waterfall model. It is composed in
several cascading phases. In theory each phase is performed sequentially starting not
before the previous phase has finished and documentation is delivered (Royce 1987).
Figure 1: Waterfall modell (Royce 1987)
But practically the stages show a high level of interdependency (Sommerville 2007). As
an example design problems are found during coding or requirements are identified
during the design phase. Therefore the SDP is done in a sequence of iterations rather
than in theoretically developed linear flow (Sommerville 2007). This involves many
drawbacks. To limit extending costs and time consumption some phases in development
are usually put on hold after some iterations (e.g. requirement analysis, design phase).
This might lead to impractical systems since requirements could have changed in the
meanwhile. “The major problem of the process is its inflexible portioning of the project
into distinct stages. Commitments have to be made at an early stage in process, which
makes it difficult to respond to changing requirements” (Sommerville 2007, p.67) and
lead to the problem that during the maintenance phase previous process stages have to
be repeated. (Sommerville 2007) (Faegri, Hanssen 2007).
2.3 Software crisis and paradigm reversal

35.00% 31.50% 29.60%
30.00% Plan based software development
25.00%
20.00% 15.50% was the state-of-the-art until the
15.00% 10.20% 8.80% beginning of the 1990’s. But it
10.00%
4.40%
5.00% could not overcome the dilemma
0.00%
between keeping cost and time
exposure low and delivering useful
complete systems (Sommerville
2007). Therefore it led to very poor
success rates of software projects and the so called software crisis in the beginning of
the 1990’s. The Chaos Report shows that only 16.2% of the examined projects could be
delivered on-time and in-budget and especially in large software projects only 42% of
the initially planned features and functions could be implemented (The Standish Group
1994).
Parallel Gibbs refers to several studies and reports that “the average software
development overshoot is scheduled by half; larger projects generally do worse.” (1994,
p.86). Evidently the plan based approaches with extensive documentation and a
significant overhead in planning, designing and coordination seemed not to be
appropriate for most software development projects any longer. The needs had changed
significantly. Software development had become an ongoing process with shorter life
cycles instead of a process which always starts from scratch (Sommerville 2007). Due
Figure 2: Cost overun in projects (The Standish Group 1994)
to the fact that business needs were rapidly changing there was a demand for fast
product delivery and features which could be integrated steadily into a running system
(Janßen 2005). The previous software development techniques were identified as
inefficient processes and there was an increasing demand for lower software production
and maintenance costs (Sommerville 2007). One proposition to address these new
developments was to extent the degree of industrialized software development which
will be discussed into more detail in the following paragraph (cp. 3.1).
3 Industrialized software development
3.1 Definition of industrialized software development

Industrialization can be defined as “the spread of highly productive industrial
approaches in the production of goods and services.” (Zwahr 2006, p.263) Greenfield
defines the patterns of industrialization as “the assembling of products out of
components, the automation of rote or menial tasks, the creation of product lines and
supply chains as well as the standardization of processes, architectures and packaging
norms.” (2004, p.17) Subsequently it will be presented which patterns of
industrialization are transferable to SE. In doing so, the questions will be answered how
and to which extend they have been adapted to SE. Furthermore the limitations of
industrialization in SE will be introduced.
Following the taxonomy of Greenfield standardization might be seen as the key

characteristic of industrialization. In SE standardization was first applied with the
development of high level programming languages like C++, which have provided
language level and machine-architecture independency (Stroustrup 1986). Another
critical innovation to extent standardization was the introduction of the system-
independent and “future proof” (Maidl 2005, p.283) TCP/IP protocol which has
facilitated the communication between workstations and “boosted the use of network
services of companies and individuals” (Taubner 2005, p.292). Furthermore
organizations and committees (ISO, IEEE, W3C) established industry standards for
software development (Maidl 2005), which have established best practices in many
areas (Taubner 2005). These innovations favored that the dominating job-shop
production, which provoked the software crisis with its ability of being slow and
expensive (Greenfield, Short 2004), got challenged. Industrial production principles like
specialization, division of labor and automation of process steps got into the focus of
interest. Instead of creating a software artifact from scratch, software products were
increasingly combined out of software components of selected suppliers (Greenfield,
Short 2004). This approach, which is called component based software engineering
(CBSE), is described by Sommerville as a process of “defining, implementing and
integrating or composing loosely coupled independent components into systems”
( 2007, p.440). There are many advantages of developing software in this industrialized
manner:
 Allocation of extensive development costs of software products on high volumes

of customers (economy of scale) (Maidl 2005, Taubner 2005)
 Software becomes a commodity which can be bought easily according to
individual preferences (Software as a service) (Carr 2005)
 Software as a commodity leads to market concentration (e.g.: Microsoft, SAP)
which has the positive effect of general accepted standards (e.g.: file formats)
(Taubner 2005)and reduction of niche-suppliers (Maidl 2005)
 Higher dependability and less development costs because reused components are
already specified, designed, implemented and validated in working systems
(Sommerville 2007)
 Reduction of process risk particular when relatively large components such as
subsystems can be reused (Sommerville 2007)
 The overall SDP is aimed to be accelerated (Sommerville 2007)
However the principles of industrialization are not generally applicable to all kind of
software products. Software artifacts differ depending on the number of customers they
are developed for, the product variability and the related ability for
standardization(Taubner 2005, Kilian-Kehr et al. 2007), which is indicated in table 1.
Products Specific solutions
System and Application Enterprise Integration Individual
mass market software software
products
DMS, operating portals, data ERP, SCM, Introduction of sales order
systems, warehouse, inventory enterprise processes,
application CRM management applications, airline booking
server or Integration of system
network components and
software, office specific software
and e-mail extensions
Table 1: Spectrum of software artifacts (Taubner 2005, Kilian-Kehr et al. 2007)
This table shows mass software products like database management systems (DMS),
operating systems, application server or network software at the far left. They offer a
high degree of common functionality (Kilian-Kehr et al. 2007), are widely used, have
stable requirements and are not designed for a particular company. Therefore they are
well suited for being developed in components (Kilian-Kehr et al. 2007). The other
categories to the right are characterized by increasingly less opportunities for
standardization. The extreme at the far right of the table is represented by individual
customized software solutions. For these kinds of software artifacts standardization is
not meaningful as the requirements of the software are too specific. Even if there would
be components available the extra cost to find, understand and sometimes adapt the
reusable component would be too high and the trade-off between ideal requirement and
available component might not be found (Sommerville 2007).
Obviously industrialization of SE is possible to a certain degree. Experts are even

agreed that during time many software artifacts which belong to the categories on the
right of the table will have the capability to be standardized and move to the categories
on the left of the table (Taubner 2005). However there are many implications of SE
which will limit the level of industrialization and determine that a “significant share of
software will not be a commodity within the foreseeable future” (Taubner 2005, p.295).
Following arguments support this thesis:
 SE still “has indications of craft manufacturing” (Janßen 2005, p.284)and it will

take time to convince people to switch from their established working procedures
to more specialized and efficient working methods (Janßen 2005)
 According to McKinsey only 7% of German IT employees work in the product
business which has extensive potential for industrialization whereas 93% of the
employees work in software services (Hoch 2005)
 Component models are not as easy applicable as theory might illustrate. The
components have to be independent and completely specified by their interfaces.
There have to be component standards that facilitate the integration of
components. Furthermore middleware is needed that independent, distributed
components are able to communicate with each other (Sommerville 2007).
Besides these important prerequisites the real burdens are even stronger. In SE the
“not invented here syndrome” (Janßen 2005, p.284) is widely common and has
lead to the failure many reuse-project. The reuse of components encounters high
personal and emotional resistance (Janßen 2005). This issue is even enforced
when the source code of components is hidden due to proprietary rights which is
highly common in industry. Components often have to be seen as a black box,
which decreases the trustworthiness in these components because reliability and

stability cannot be ensured (Sommerville 2007). Moreover the black box principle
can lead to increased maintenance costs or even incompatibility when there is a
system change (Sommerville 2007).
 Phases like RE and design are creative activities which are highly knowledge
intensive (Meyer 2006). Parts of SE offer less capability to be standardized and
approaches have to be found to make these processes more efficient.
Addressing the last topic of the previous enumeration agile development will be
introduced in the next paragraph.
3.2 A new software engineering method: agile development

The software crisis has not only led to a shift towards a higher degree of
industrialization of software development; the static plan based working methods were
also questioned. It was recognized that most SDPs differ in many cases from the pre-
defined process of other engineering disciplines that follow a certain assembling order
and produce the same results every time (Schwaber, Beedle 2001). People got aware
that most SDPs are characterized by an empirical and nonlinear proceeding (Williams,
Cockburn 2003) and are marked by “inevitable changes throughout its life cycle”
(Highsmith, Cockburn 2001, p. 120) like requirements changes and technology changes.
In the mid 1990’s practitioners first developed methodologies to face this issue and
“embrace rather than reject higher rates of change” (Williams, Cockburn 2003, p.39)
within the development process (see 2.3). Following the target to facilitate the process
of software development and enhance quality, speed of delivery and customer
satisfaction these approaches were called agile methods (Williams, Cockburn 2003,
Sommerville 2007).
The key characteristics of these methods are the focus on incremental delivery: The
system is developed from abstract specifications and then iteratively refined by using
customer input. Well known agile methods are Extreme Programming (XP) (Beck
1999), Crystal (Highsmith, Cockburn 2001), Scrum (Schwaber, Beedle 2001) and FDD
(De Luca 2009). In 2001 the Agile Alliance, a group of the representatives of the
leading agile methods formulated the four basis principles of agile methods:
 Individuals and interaction instead of processes and tools

 Executable software instead of extensive documentation
 Customer collaboration over contract negotiation
 Responding on change over following a plan
According to the first principle programmer following the XP approach work in pairs
which leads to higher involvement, motivation (Fowler 2006) and shows a similar
productivity (due to less rework) as two programmers working separately (Williams et
al. 2000). The fourth principle for instance implies that changes of system requirements
have to be expected and that the system has to be designed to accommodate these
changes (Fowler, Highsmith 2001). The four generative rules of agile methods lead to
higher customer collaboration/user engagement and the distribution of decision making
authority over the whole development team (Highsmith, Cockburn 2001). Advantages
of XP are that the final product is more consistent with the business needs than by using
classic software development methods (Sommerville 2007) and the high applicability to
turbulent, high change environments (Highsmith, Cockburn 2001). However in
literature there dominates the opinion that agile methods are only suited to the
development of small or medium-sized business systems and certain personal computer
products (e.g. computer games) (Williams, Cockburn 2003, Sommerville 2007).
Reasons for this limitation are as followed:
 Customer involvement, which can be a critical success factor for the SDP,
depends on the willingness and availability of the right customers who can
represent all system stakeholders (Faegri, Hanssen 2007, Damian 2007).
 Through the attempt to deliver running software quickly and with a small amount
of documentation there is strong emphasize on extensive formal and informal
communication and coordination during the SDP. It incurs that programmers
should have suitable personalities for intense involvement and that the project
should be characterized by a low level of employee turnover (Sommerville 2007).
 Case studies have shown that projects can collapse when supporters of agile
methods in critical position of the project leave the project team (Faegri, Hanssen
2007).
 The missing documentation may make the source code difficult to understand
which might create problems in maintenance and validation (Sommerville 2007).
 There might occur contractual problems. Normal contracting methods are based
on system specifications which are defined at the very beginning of the project.
Using agile methods system requirements are specified only during the
development process and contracting according to system specifications is not
applicable (Sommerville 2007).
Nevertheless agile methods have faced a high level of recognition because they
introduced an alternative methodology to the static plan based development approaches
(Williams, Cockburn 2003). Although they were initially developed to support software
development in a collocated environment since 2003 researchers and practitioners try to
find out possibilities to “blend selected agile practices with the “regular” practices.”
(Williams, Cockburn 2003, p.40, Boehm 2002) Some experts are even convinced that
agile methods are an adequate approach for the software development of large scale
system developments and projects characterized by distributed development teams
(Hildenbrand et al. 2008, Eckstein, Josuttis 2004). One argument is that agile methods
were used in open source software development (OSSD) projects successfully which are
characterized by distributed development teams (see 4.3.2).
3.3 Implications to review SE the global context

Summing up the implications of software development, it should be mentioned that SE
has changed significantly after the software crisis in the early 1990’s. On the one hand
industrialization has come into the focus and the ideas of standardization, flexibility,
and off-the-shelf products have become highly recognized (cp. 3.1). For the first time
software products were split into modules which imply the opportunity to distribute
SDPs not just according to tasks (RE, implementation, testing, etc.) like in plan based
approaches. Using CBSE companies have received the chance to allocate the
development of components of a software system to different teams and let them work
independently on a smaller piece of software. Therefore software can be developed in
remote locations and simultaneously by different companies. This implicates higher
efficiency through division of labor and simultaneous work but it can lead to higher
coordination and communication efforts as well. These aspects get even more relevant
in a global context (cp. 4.1, 4.2). But people recalled as well that the implementation
part of SE is in many cases an empirical and nonlinear process (cp. 3.2). They
introduced agile methods to make the implementation phase itself more efficient. In the
main part of the paper it will be investigated how these two trends in software
development are employed in the global context.
4 The global perspective
4.1 Global software development

In the last two decades software development practice was forced to adapt to the
ongoing globalization of business. National markets turned into global markets and new
forms of competition and cooperation across national borders had to be developed. The
result is global software development (GSD) which evolved out of several reasons. The
benefits can be summarized as followed (Herbsleb, Moitra 2001, Damian, Moitra 2006,
Ye et al. 2007):
 Delegating development tasks to the most economically viable places to be more

cost competitive which is seen as the initial driving force of outsourcing
 Capitalize the global resource pool and recruit talented and suitable people for
certain tasks regardless of location, nation and time zone differences
 Tackle demand for faster product delivery by using time zone differences in
“round-the-clock” development
 Exploit market opportunities of proximity to the market, including knowledge of
customers and local conditions
Regarding these goals it seems that the idea of the industrialization of software
development which was introduced before is simply transferred to the global issue:
 Simultaneous engineering is extended by “round-the-clock” development.

 Instead of working with distributed teams within one country and between
strongly related organizations, in GSD projects people are organizationally,
spatially and time dispersed.
 Following the division of labor principle employees work in virtual teams for
sometimes one single project by using information and communication
technologies.
Nevertheless the practical experiences have shown that the established approaches and
methods of SE are not fully transferable to GSD (cp. 4.2). In GSD many mechanism
and rules are different. SE on a global basis is characterized by a higher distance in
contrast to collocated software development. This refers to its high distribution of
workforce and processes. According to Carmel this distance magnifies complexity in

organizational processes which leads to difficulties in communication, control and
coordination. (Carmel, Agarwal 2001)
Figure 3: Impacts of distance (Carmel, Agarwal 2001)
4.2 Problems of GSD

The following taxonomy summarizes the most relevant distance related problems out of
different sources (Herbsleb, Moitra 2001, Carmel, Agarwal 2001):
 Strategic dimension: There are different coordination mechanism and no

standardized approach how to divide work of a project across sites. There are
differences in available resources, expertise, infrastructure at each site (Herbsleb,
Moitra 2001).
 Cultural dimension: Culture includes language, attitudes towards hierarchy and
communication style (Hofstede 2005). The inability to understand the sender’s
intention is an example for problems in communication. It might arise when a
question of a person of a “high context culture” is interpreted as a criticism from a
person of a “low context culture”. It can lead to serious and chronic
misunderstandings, especially in a non face-to-face situation (Herbsleb, Moitra
2001).
 Process management dimension: Due to different organizational cultures
stakeholders in remote organizations or development sites often have different
techniques for several processes like the electing of requirements in RE or a
different definition of unit test code in testing. This problem can even be enforced
due to unstable specifications, volatile requirements, unavailability of efficient
tools to support collaboration and the lack of informal communication (Herbsleb,

Moitra 2001).
 Communication dimension: Formal and informal communication is steadily used
in software development projects. Formal communication is needed to apply
crucial tasks like defining interfaces, updating project status, determing
responsibilities. Informal communication is used because of the high vitality of a
SDPs. It gets more relevant the more uncertainty the project inhibits (e.g.:
requirements are not defined at the beginning) (Damian 2007). Informal talks
keep the people updated about what is happening around them. Conveniently they
get to know who is working at which topic, the status of sub-projects or which
person has expertise in which area. The absence of informal conversation, which
is typically for projects at remote sites, can keep crucial problems unrecognized
and therefore lead to misalignment between concurrent work which causes rework
(Damian, Zowghi 2003).
 Knowledge management dimension: Since there are less possibilities for informal
communication and moreover cultural problems (e.g.: fear to loss of intellectual
property) knowledge management in a GSD project has to not managed more
intensively as in a collocated projects. Filtered information should be avoided and
reuse opportunities should be given (Herbsleb, Moitra 2001).
 Technical dimension: In GSD it is needed to plan technical issues in detail at the
beginning of the project. Otherwise crucial problems might arise during the
project through different versions of tools or incompatible data formats. Moreover
tasks like the transmission of critical data in configuration management have to be
meticulously planned and executed in contrast to a non GSD (Herbsleb, Moitra
2001). Ebert sees performance rapidly decreasing when multisite use is involved
in certain tasks, due to heterogeneous server and network infrastructure.(Ebert, De
Neve 2001)
Faced with these burdens different approaches for efficient GSD were developed which
will be discussed in detail in the next paragraph.
4.3 Approaches to tackle the problems of GSD

There are two main approaches of GSD to tackle the analysed problems. The first
derived out of a commercial background. In the mid 1990’s some companies started as
pioneers to develop software globally. Using their experience they refined the way to
deal with GSD. These established approaches of GSD will get introduced in the next
paragraph by referring to experiences from different cases related to GSD (cp. 4.3.1).
The other approach is the application of non-commercial open source practices. These
projects are also characterized by globally distributed developers but distinguish
significantly from commercial approaches. They imply many other aspects and ideas
and will be introduced subsequently (cp. 4.3.2). Later tools which support distributed
collaborative software development will be presented. They have the potential to reduce
distance significantly and start a new phase of GSD (cp. 4.3.3).
4.3.1 Established approaches
There are two main ideas how to deal with distance in GSD. On the one hand you can
try to avoid distance in the development process, on the other hand you can try to
handle distance more efficiently that it becomes less relevant. Since the development of
efficient tools to support collaboration was in its infancy in the beginning of GSD,
primarily tactics that went beyond communication technologies were applied in GSD
“aimed at reducing intensive collaboration, national and organizational cultural
differences and temporal differences” (Carmel, Agarwal 2001, p.22).
The most regarded issue to avoid distance is to reduce intensive collaboration, which is
taken up in every case description regarded for this paper. Carmel states, that most
companies try to engage the foreign entity only in tasks that are well defined and
structured (Carmel, Agarwal 2001). The way how companies act is analogical to the
predication of Carmel. Cusick for example suggests to have concept, analysis and
design nearly 100% onshore and to hand structured tasks like construction and quality
assurance over to the offshore partner (Cusick, Alpana Prasad 2006). Cusick regards
standardization of procedures as a key for a successful project. Having this clear
separation of tasks these projects tend to follow a well structured waterfall approach.
Agile, collaboration intensive methods are not or only rarely regarded (Ebert, De Neve
2001, Cusick, Alpana Prasad 2006, Burger 2007, Kobitzsch et al. 2001, Battin et al.
2001). Some experts verify this proceeding by stating that iterative and incremental
development in distributed environments is difficult (Paasivaara, Iassenius 2004).
Another approach to limit the need for collaboration is to give the foreign entity full
responsibility for a system, system component, product or corporate process. Following
this CBSE based approach the foreign entity is not using links with the center frequently
and thus the ongoing collaboration is not as intense (Carmel, Agarwal 2001, Battin et al.
2001). The underlying principal for this proceeding in GSD are the experiences of the
past. The company Alcatel studied projects for five years by distinguishing the degree
of collocation. For example they found out that collocated teams needed half of the time
for defect detection in validation activities than a distributed team which works on the
same task (Ebert, De Neve 2001). This was verified by Teasley, who reports that in
collocated teams, productivity and job satisfaction are much higher (Teasley et al.
2002). Therefore Ebert considers team-task collocation in a distributed project as a key
objective. Teams that are assigned across several locations face many challenges that
could impact their ability to work as a team (Ebert, De Neve 2001). These facts lead to
the conclusion that the methodologies applied in GSD are in contrast to the
methodologies applied in collocated software engineering projects more focused on plan
based software engineering approaches. They favor clearly separated tasks.
Although this proceeding reduces distance, many of the prior named problems are not
solved. To alleviate the remaining distance and to handle it more efficiently several best
practices have been developed since the beginning of GSD. A key learning in most case
studies is that there should be an established a relationship between team members of
remote locations (Carmel, Agarwal 2001, Carr 2005). This way they can identify with
the team, feel responsibility for the team, are able to build up trust. As a result of that
the electronic communication becomes effective. To address these findings the concept
of “cultural liaison” is widely used to bridge the cultural gap across sites and
organizations (Carmel, Agarwal 2001, Carr 2005). According to this concept a key
person of the project acts as ambassador and links the different sites of the project.
Besides building up trust, the cultural liaison enables to spread domain expertise
because knowledge can be easily shared using this link (Carmel, Agarwal 2001, Carr
2005). In a large project of Motorola, key engineers of the remote locations moved to
the main US based site of the company and took part in a three month workshop. They
learned the system, helped completing RE and communicated this information back to
their local teams. This measure was considered as a key success factor for the project by
the company (Battin et al. 2001). Corresponding to this results Ebert claims that “one
way to improve is a heavy exchange of teams and management […] which gradually
build mutual understanding.“ (2001, p.68) Moreover he states that mixed teams should
be set up to integrate diverse cultural and educational backgrounds (Ebert, De Neve

2001). Another central statement in many case studies is that the different development
processes at the remote sites have to be managed efficiently. Instead of installing
common in-detail processes everywhere it is mostly advised to standardize on a higher
level. Battin suggests that teams should not be forced into a common process because
the learning curve of the team would be affected. Instead he proposes to handle the
minor processes as a black box and concentrate on the interface definition right in the
initial architecture definition phase. Pursuant to this the architecture of the project
described by Battin followes three main principles: low coupling among network
elements, well defined interfaces and concise semantics for the network element
behaviors (Battin et al. 2001). Regarding the problem of inconsistency in notations and
terminologies between sites Battin suggests to agree on a set of common “work
products” and common vocabulary at the beginning of the project. However regarding
the implementation, the way how problems are solved differs in the examined case
studies. Areas of disparity are for example the formation of teams, the allocation of
work between teams, the way quality was ensured and the decision in which phases
iterative development should be applied. Nevertheless all papers point out the crucial
need for communication tools. The commonly used tools are (Ebert, De Neve 2001,
Cusick, Alpana Prasad 2006, Burger 2007, Kobitzsch et al. 2001, Battin et al. 2001, Rao
et al. 2007):
 asynchronous messaging systems (e.g. e-mail, web forum)

 synchronous messaging systems (e.g. instant messaging, video-conferencing and
telephone-conferencing, screen sharing)
and in most cases also:
 shared project repositories (for documents , source code etc)

 wiki webs (which substitute shared documents and glossaries)
Summarizing the observations of the different case studies the distance of GSD is still
high and companies adapt their software development practices to this situation.
Companies switch from their partly agile development methods in collocated situations
(Boehm 2002) to strictly plan based approaches in global projects (Cusick, Alpana
Prasad 2006). Most companies prefer to split work according to functional tasks and
only some are following partly a CBSE approach (Kobitzsch et al. 2001). In GSD
coordination mechanisms like plans, schedules, system-level design and defined
processes are seen as a crucial success factor. They are considered to be more important
in geographically distributed software development than in collocated software
development (Herbsleb, Grinter 1999). But surprisingly this finding seems not to be a
natural law. Open source software development (OSSD), which is also characterized by
geographically distributed development lacks many of the presented coordination
mechanisms but also succeeds in developing software of high quality and functionality
(Mockus et al. 2002). Therefore it will be presented in the following paragraph
4.3.2 Open source software development (OSSD)
OSSD is a way for building, deploying and sustaining large software systems on a
global basis (Sommerville 2007). It is an “alternative community-intensive socio-
technical approach to develop software systems, artifacts and social relationships.”
(Scacchi 2007, p.464). One of the basic principles of this software development style is
that licenses and legal arrangements ensure that the source code of OSSD is generally
available for remote access. Moreover OSSD typically has a central body, consisting of
some of the core developers, who are responsible for guiding the development of the
project (Mockus et al. 2002). These basic arrangements ensure that the development
process of OSSD projects is radically different to traditional SE projects:
 In many OSSD projects the systems are build by a large number of volunteers
(Mockus et al. 2002)
 The OSSD developers are typically also end users (Mockus et al. 2002)
 Work is not assigned. The underlying belief in the freedom of choice ensures that
developers just undertake the tasks they are interested in (Benkler 2006)
 There is no explicit system-level design or even detailed design (Vixie 1999)
 There is no project plan, schedule or list of deliverables (Mockus et al. 2002)
In OSSD projects software informalisms (Scacchi 2002) take the place of the
formalisms which is typical for traditional SE approaches. The most common types of
informalisms used in OSSD include online discussion forums or threaded email
messages. Some of the other ways to observe and participate in project related topics are
bulletin boards, group blogs as well as to do lists and project wikis (Scacchi 2007).
These various types of software informalism are accessible through project related
websites and portals. In the interplay with the informalism between different OSSD
projects (e.g.: cross referencing) they form “a web of informal, semi structured and
processable information resources” (Scacchi 2007, p.461). However OSSD do not have
an anarchic attitude. Several mechanisms ensure good software development. Instead of
explicit administrative control OSSD projects rely on “gentle but sufficient” social
control (Scacchi 2007, p.462). OSSD projects are characterized by a skill-based
mediocracy, in which “project participants self-organize around expertise, reputation
and accomplishments of core developers, secondary contributors and tertiary reviewers
as well as other peripheral volunteers” (Scacchi 2007, p.461). This includes voting on
the approval of individual contribution to ongoing project software (Fielding 1999),
shared peer reviewing (Benkler 2006, DiBona et al. 2005) or as well the project’s
recognition of a core developer’s status, reputation and geek fame (Scacchi 2007). This
virtual project management ensures to mobilize, coordinate, control, build and assure
the quality of OSSD activities (Scacchi 2004). But the success of OSSD projects is also
based on the reduction of coordination efforts. The vast majority of source code (~80%)
is created solely by core developers and “most participants typically contribute to just a
single module” (Scacchi 2007, p.460) of the system or tasks like defect reporting
(Mockus et al. 2002). The coordination concerns in the Apache OSSD project for
instance “are sharply limited by the stable asymmetrically controlled interfaces. Any
functionality beyond [the basic development of the Apache server] is added by means of
various ancillary projects that interact with Apache only through Apache’s well defined
interfaces.” (Mockus et al. 2002, p.342) This high interdependency of modules and
components in a OSSD Project and the fact that some “linchpin developers” (Madey et
al. 2005) work simultaneously in several OSSD projects implies the possibility that
OSSD projects are able to grow at a super-linear or exponential rate (Scacchi 2006,
Schach et al. 2002) when modules or even sub systems are integrated into exciting
OSSD projects (Schach et al. 2002).
OSSD has many implications which might be useful for commercial GSD. One is that
industrialization in the sense of CBSE is applicable in global distributed projects. OSSD
shows that coordination efforts are limited by high modularization and stable
asymmetrically controlled interfaces (Mockus et al. 2002). Moreover the evolutionary
characteristic of OSSD through the interrelations between projects might establish the
view to see GSD more as an opportunity than as a burden. Although meanwhile sharing
and reuse became common in traditional SE software, the efforts of traditional SE
projects are still setup to produce systems whose growth and evolution is limited
(Scacchi 2007). In contrast to that in OSSD the focus is on software evolution which “is
a process of co-evolution of interrelated and independent OSSD projects, people
artifacts, tools code and project specific processes (Capiluppi, Michlmayr 2007, Weiss
et al. 2006). The new types of socio-technical work practices, development processes
and community networking excel traditional SE (Scacchi 2007). Finally the extensive
use of communication tools in OSSD already had and will have significant impact on
SE to reduce distance furthermore and facilitate GSD. Maurer is supporting this
argument by stating that adequate and timely sharing of information and knowledge in
all directions, proactive change, management, and process monitoring are some of the
important factors required for successful project collaboration.(Maurer 1996) Therefore
tools for distributed collaborative development will be discussed in the next paragraph.
4.3.3 Tools for distributed collaborative development and how they

can change current development practice
The possibility to handle distance more efficiently by using powerful communication

tools is used in commercial GSD but as it was observed in 4.3.2 even more intensively
in OSSD. The following paragraph investigates which features of communication tools
reduce distance significantly and enable the practicability of software development
similar to a collocated situation.
In the regarded cases of commercial GSD developers of distributed projects employ two
kinds of tools separately to conduct their work (cp. 4.3.1): On the one hand they use
collaborative software development tools (CSCW-tools) or also known as groupware
and on the other hand they utilize integrated development environments (IDE).
Groupware tools help people to conduct a common task and are the basis for computer
supported cooperative work (Hildenbrand 2008). Some of the already presented tools
like asynchronous messaging systems (e.g. e-mail, web forum) and synchronous
messaging systems (e.g. instant messaging, video-conferencing and telephone-
conferencing, screen sharing) are typical groupware applications (cp. 4.3.1). In contrast
to that IDEs integrate individual software development tools like auto complete
functions, code generators and automatic code documentation (Sommerville 2007)
which support the individual developer into a consistent interface and working
environment (Hildenbrand 2008). They are tailored to achieve better individual
productivity but only rudimentarily support distributed collaboration within teams
(Sommerville 2007). Examples for IDEs are open source solutions like NetBeans or
Eclipse (Hildenbrand 2008). But obviously this separate use of groupware and IDE
applications to conduct a certain task leads to inefficient development in GSD. In order
to tackle this issue the open source community integrated Groupware and IDE
functionality into collaborative software development platforms (CSDP). Later these
CSDP were successfully applied in several OSSD projects (Robbins 2005, Augustin et
al. 2002, Feller, Fitzgerald 2002).
Table 2: Evaluation of collaboration tool categories (Hildenbrand 2008)
CSDP offer a central data repository (Robbins 2005), integrated groupware

functionality like IP telephony which is accessible either directly through the web
browser or via IDE plug-ins and a fully internet based user interface (e.g.
sourceforge.net). Hence CSDPs enable synchronous and asynchronous communication
for a “vertically continuous and collaboration intensive development process”
(Hildenbrand 2008, p.31) and the possibility for community building through the
availability of various centralized information, artifacts sharing functions and

stakeholder entities (Hildenbrand 2008). Moreover better traceability of individual
process steps as well as relations between different software artifacts and contributing
stakeholders through high transparency can be achieved. In literature this is seen as a
crucial success factor in GSD, because “current and future PM [in GSD projects] will be
more concerned with tracking project work processes and efficient and effective sharing
of information and knowledge, among project contributors.” (Chen et al. 2003, p.1)
Due to the high performance of CSDP in OSSD projects the platforms were transferred
to the commercial context. The most common CDSP are CodeBeamer, CollabNet
Enterprise and SourgeForge Enterprise. They offer a common set of CSDP features,
have “a considerable market share and […] have been used in multitude distributed
projects.” (Hildenbrand 2008, p.33) According to a study of Rodriguez as well as a
ranking of Hildenbrand CodeBeamer was seen as the best overall platform (Hildenbrand
2008, Rodriguez et al. 2007). Although strictly tool based SE approaches prevail
significantly in terms of frequency and state of elaboration, in 2003 already 65% of
software development companies at least intended to use a CSDP for distributed
projects by the year 2005 (Webster 2003).
The different kind of communication tools were presented here because they have the
high potential to overcome the distance of GSD. Especially CSDP could make GSD
similar to SE in a collocated situation. Due to the complete functionality they even
could make agile software development methods applicable in distributed collaborative
software development.
5 Discussion
The paper shows the most vital trends and developments in global software
development. It indicates that today the crucial question regarding SE is not about the
possibility of industrialization in software development because there is no doubt that
SE has already reached a certain level of industrialization. The question is what the
(current) limits for industrialization in SE are and how they are influenced by GSD.
As we have seen in paragraph 3 the level of industrialization in SE has increased

significantly until today. Numbers of “indications of craft manufacturing” in SE have
been renewed by more professional approaches based on “improved tools and
automation, more appropriate use of components and more efficient project
management.” (Taubner 2005) Nonetheless industrialization of SE solely came into the
focus of interest due to the trend of outsourcing and offshoring at the end of the 1990’s
(Taubner 2005). However it is crucial to understand that industrialization was widely
practiced already before this time. It was shown that already in the beginning of the
1990’s some software artifacts were produced according to the principles of
standardization, modularization, economy of scale and a shift towards commodities (cp.
3.1). These principles were applied to increase the efficiency by reducing cost/risk and
increase effectiveness by ensuring sustainability (Maidl 2005). Although the ensuing
trend to outsourcing/offshoring at the end of the 1990’s raised the attention of
industrialization of SE curiously it countervailed the goal of increased efficiency and
effectiveness at first. As it was shown in the examined case studies companies could
capitalize the global resource pool but were forced to reapply traditional plan based
approaches of low efficiency (cp. 4.3.1). This development signifies the dilemma of
industrialization on the global basis. On the one hand principles of industrialization like
simultaneous engineering and division of labor can be put into a global context (cp. 4.1)
but on the other hand one is faced with additional distance. Organizational, spatial and
time dispersed virtual teams lead to lower efficiency of processes due to difficulties in
communication, control and coordination (cp. 4.2). For instance agile development
methods which offer increased efficiency in SE in collocated situations are mostly not
applicable in a global context (cp. 4.3.1). However OSSD projects have shown that
these burdens can be overcome especially by applying well-engineered communication
platforms (cp. 4.3.2, 4.3.3). Hildebrand claims that only CSDP “provide sufficient
support for spatial, temporal and organizational distribution […] and feature a superb
integrity and traceable information supply.” (2008, p.36) Due to these facts CSDP could
decrease distance in GSD significantly and reduce the dilemma of industrialization in a
global context.
To conclude shortly: As already mentioned industrialization has been established in SE

to a significant degree. The increased amount of features of communicatin tools (cp.
4.3.3) will be one reason why industrialization of SE will even continue to expand in the
future. Others are further standandardzation, outsourcing and offshoring which will
encourage companies to strengthen their processes, be more innovative and manage
tasks more efficiently (Taubner 2005). The critical question for further investigation is
about upcoming limits for industrialization of GSD specifically and SE in general.
References
Augustin, L., Bressler, D. & Smith, G. 2002, "Accelerating software development

through collaboration", Proceedings of the 24th International Conference on
Software EngineeringACM New York, NY, USA, , pp. 559.
Battin, R.D., Crocker, R., Kreidler, J. & Subramanian, K. 2001, "Leveraging resources
in global software development", Software, IEEE, vol. 18, no. 2, pp. 70-77.
Beck, K. 1999, "Embracing change with extreme programming", IEEE Computer, vol.
32, no. 10, pp. 70-77.
Benkler, Y. 2006, The wealth of networks: How social production transforms markets
and freedom, Yale University Press, New Haven.
Boehm, B. 2002, "Get ready for agile methods, with care", IEEE Computer, vol. 35, no.
1; feasible and preferable in some circumstances, pp. 64-69.
Burger, W. Offshoring and Outsourcing to INDIA 2007, .
Capiluppi, A. & Michlmayr, M. 2007, "From the cathedral to the bazaar: An empirical
study of the lifecycle of volunteer community projects" in Open Source
Development, Adoption and Innovation Springer, Boston, pp. 31-44.
Carmel, E. & Agarwal, R. 2001, "Tactical approaches for alleviating distance in global
software development", Software, IEEE, vol. 18, no. 2, pp. 22-29.
Carr, N.G. 2005, "Does software matter - Software-Industrialisierung", Informatik-

Spektrum, vol. 28, no. 4, pp. 271-273.
Chen, F., Nunamaker Jr., J.F., Romano Jr., N.C. & Briggs, R.O. 2003, "A collaborative
project management architecture", System Sciences, 2003. Proceedings of the
36th Annual Hawaii International Conference, pp. 12.
Cusick, J. & Alpana Prasad 2006, "A Practical Management and Engineering Approach
to Offshore Collaboration", Software, IEEE, vol. 23, no. 5, pp. 20-29.
Damian, D. & Zowghi, D. 2003, "Requirements engineering challenges in multi-site

software development organizations", Requirements Engineering, vol. 8, no. 3,
pp. 149-160.
Damian, D. 2007, "Stakeholders in Global Requirements Engineering: Lessons Learned

from Practice", Software, IEEE, vol. 24, no. 2, pp. 21-27.
Damian, D. & Moitra, D. 2006, "Guest Editors' Introduction: Global Software

Development: How Far Have We Come?", Software, IEEE, vol. 23, no. 5, pp.
17-19.
De Luca, J. 2009, , Feature Driven Developemnt. Available:
http://www.nebulon.com/fdd/index.html [2009, 21st of April] .
DiBona, C., Stone, M. & Cooper, D. 2005, Open sources 2.0, O'Reilly Media.
Ebert, C. & De Neve, P. 2001, "Surviving global software development", Software,

IEEE, vol. 18, no. 2, pp. 62-69.
Eckstein, J. & Josuttis, N. 2004, Agile Softwareentwicklung im Grossen: Ein

Eintauchen in die Untiefen erfolgreicher Projekte, Dpunkt-Verl., Heidelberg,
Germany.
Faegri, T.E. & Hanssen, G.K. 2007, "Collaboration, Process Control, and Fragility in
Evolutionary Product Development", Software, IEEE, vol. 24, no. 3, pp. 96-104.
Feller, J. & Fitzgerald, B. 2002, Understanding open source software development,

Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
Fielding, R.T. 1999, "Shared leadership in the Apache project", Communications of the
ACM, vol. 42, no. 4, pp. 42-43.
Fowler, M. 2006, 18th of July 2006-last update, Using an Agile Software Process with
Offshore Development. Available:
http://www.martinfowler.com/articles/agileOffshore.html [2009, 21st of April] .
Fowler, M. & Highsmith, J. 2001, "The Agile Manifesto", Software development, vol. 9,
no. 8, pp. 28-35.
Gibbs, W.W. 1994, "Trends in Computing: Software's Chronic Crisis", Scientific

American, vol. 43, no. 9, pp. 86.
Greenfield, J. & Short, K. (eds) 2004, Software Factories: Assembling Applications

with Patterns. Models, Frameworks and Tools., Wiley Publishing, Inc.
Herbsleb, J.D. & Grinter, R.E. 1999, "Splitting the organization and integrating the
code: Conway's law revisited", Software Engineering, 1999. Proceedings of the
1999 International Conference on, pp. 85.
Herbsleb, J.D. & Moitra, D. 2001, "Global software development", Software, IEEE, vol.
18, no. 2, pp. 16-20.
Highsmith, J. & Cockburn, A. 2001, "Agile software development: the business of

innovation", IEEE Computer, vol. 34, no. 9, pp. 120-127.
Hildenbrand, T. (ed) 2008, Improving traceability in distributed collaborative software

engineering:a design science approach, Peter Lang, Frankfurt a.M.
Hildenbrand, T., Geisser, M., Kude, T., Bruch, D. & Acker, T. 2008, "Agile
Methodologies for Distributed Collaborative Development of Enterprise
Applications", International Conference on Complex, Intelligent and Software
Intensive Systems, 2008 (CISIS 2008), pp. 540.
Hoch, D.J. 2005, "Gefahr Offshoring - Software-Industrialisierung", Informatik-

Spektrum, vol. 28, no. 4, pp. 287-291.
Hofstede, G.J. 2005, Cultures and Organizations: Software for the Mind, McGraw-Hill.
Janßen, R. 2005, "Die Psychologie des Entwicklers - Software Industrialisierung",

Informatik-Spektrum, vol. 28, no. 4, pp. 284-286.
Kilian-Kehr, R., Terzidis, O. & Voelz, D. 2007, "Industrialisation of the software

sector", Wirtschaftsinformatik, vol. 49, no. 1, pp. 62-71.
Kobitzsch, W., Rombach, D. & Feldmann, R.L. 2001, "Outsourcing in India [software
development]", Software, IEEE, vol. 18, no. 2, pp. 78-86.
Madey, G., Freeh, V. & Tynan, R. 2005, "Modeling the Free/Open Source software
community: A quantitative investigation", Free/Open Source Software
Development, , pp. 203-221.
Maidl, J. 2005, "Spannungsfeld zwischen Standard und Prozessführerschaft - Software-

Industrialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 281-283.
Maurer, F. 1996, "Working Group report on Computer Support in Project

Coordination", Project Coordination Workshop of the IEEE Fifth Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprised (WET
ICE)Stanford University, CA, USA, .
Meyer, B. 2006, "The unspoken revolution in software engineering", IEEE Computer,

vol. 39, no. 1, pp. 121-124.
Mockus, A., Fielding, R. & Herbsleb, J.D. 2002, "Two case studies of open source
software development: Apache and Mozilla", ACM Transactions on Software
Engineering and Methodology, vol. 11, no. 3, pp. 309-346.
Paasivaara, M. & Iassenius, C. 2004, "Using Interactive and Incremental Processes in

Global Software Development", Proc. ICSE 3rd Int'l Workshop Global Software
DevelopmentIEEE CS Press, , pp. 42.
Rao, M.T., Earls, T.W. & Sanchez, G. 2007, "International Collaboration in

Transorganizational Systems Development: The Challenges of Global
Insourcing", Journal of global information technology management, vol. 10, no.
3, pp. 52.
Robbins, J. 2005, "Free/Open Source Processes and Tools, chapter Adopting Open
Source Software Engineering (OSSE) Practices by Adopting OSSE Tools", , pp.
245-264.
Rodriguez, F., Geisser, M., Berkling, K. & Hildenbrand, T. 2007, "Evaluating
Collaboration Platforms for Offshore Software Development Scenarios", Lecture
notes in computer science, vol. 4716, pp. 96.
Royce, W.W. Managing the development of large software systems: concepts and
techniques, IEEE Computer Society Press, Monterey, California, United States
1987, .
Scacchi, W. 2007, "Free/open source software development: recent research results and
methods", Advances in Computers: Architectural Advances, vol. 69, pp. 243.
Scacchi, W. 2006, "Understanding Open Source Software Evolution", Software

Evolution and Feedback, Theory and Practice, , pp. 181-206.
Scacchi, W. 2004, "Free/open source development practices in the computer game

industry", Software, IEEE, vol. 20, pp. 59-67.
Scacchi, W. 2002, "Understanding the requirements for developing open source

softwaresystems", IEE Proceedings-Software, vol. 149, no. 1, pp. 24-39.
Schach, S.R., Jin, B., Wright, D.R., Heller, G.Z. & Offutt, A.J. 2002, "Maintainability
of the Linux kernel", IEE Proceedings-Software, vol. 149, no. 1, pp. 18-23.
Schwaber, K. & Beedle, M. 2001, Agile Software Development with Scrum, Prentice
Hall PTR, Upper Saddle River, NJ, USA.
Sommerville, I., 2007, Software engineering, Addison-Wesley, Harlow, England; New

York.
Stroustrup, B. 1986, "The C programming language", Addison-Wesley Series in

Computer Science, .
Taubner, D. 2005, "Software Industrialisierung", Informatik-Spektrum, vol. 28, no. 4,

pp. 292-295.
Teasley, S.D., Covi, L.A., Krishnan, M.S. & Olson, J.S. 2002, "Rapid software
development through team collocation", Software Engineering, IEEE
Transactions on, vol. 28, no. 7, pp. 671-683.
The Standish Group 1994, The CHAOS Report, The Standish Group International Inc.,
West Yarmouth, USA.
Vixie, P. 1999, "Software engineering" in Open sources: Voices from the open source
revolution, eds. C. DiBona, S. Ockman & M. Stone, O'Reilly & Associates, Inc.
Sebastopol, CA, USA, pp. 91-100.
Walz, D.B., Elam, J.J. & Curtis, B. 1993, "Inside a software design team: knowledge
acquisition, sharing, and integration", Commun.ACM, vol. 36, no. 10, pp. 63-77.
Webster, M. 2003, "An end-user view of the collaborative software development
market", Market Research Report, IDC 30608, vol. 1.
Weiss, M., Moroiu, G. & Zhao, P. 2006, "Evolution of open source communities" in
Open Source Systems, IFIP Springer, , pp. 21-32.
Williams, L. & Cockburn, A. 2003, "Agile software development: it's about feedback
and change", IEEE Computer, vol. 36, no. 6, pp. 39-43.
Williams, L., Kessler, R.R., Cunningham, W. & Jeffries, R. 2000, "Strengthening the
Case for Pair Programming", Software, IEEE, , pp. 19-25.
Ye, Y., Nakakoji, K. & Yamamoto, Y. 2007, "Reducing the Cost of Communication
and Coordination in Distributed Software Development" in Software
Engineering Approaches for Offshore and Outsources Development Springer, ,
pp. 152-169.
Zwahr, A. 2006, "Brockhaus Enzyklopädie in 30 Bänden", vol. 13.

Eidesstattliche Erklärung
Ich versichere, dass ich meine Diplomarbeit ohne Hilfe Dritter und ohne Benutzung
anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten
Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht
habe. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde
vorgelegen.
Mannheim, den 9. December 2021
Lorenz Hartmann

Seminar Paper by Lorenz Hartmann

Uploaded by

Copyright:

Available Formats

Seminar Paper by Lorenz Hartmann

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seminar Paper by Lorenz Hartmann

Uploaded by

Copyright:

Available Formats

INVESTIGATING THE INDUSTRIALABILITY OF GLOBAL DISTRIBUTED SOFTWARE

submitted: April 2009

1 Introduction and purpose.................................................................................................1

2 Basics of software engineering.........................................................................................2

3 Industrialized software development..............................................................................5

4 The global perspective....................................................................................................11

Figure 1: Waterfall modell (Royce 1987)...........................................................................3

YTable 1: Spectrum of software artifacts (Taubner 2005, Kilian-Kehr et al. 2007)

CSDP Collaborative software development platforms

Industrialization of software development

2 Basics of software engineering

2.1 Key characteristics

Sommerville defines software engineering as an “engineering discipline that is

2.2 Plan based approach

Figure 1: Waterfall modell (Royce 1987)

2.3 Software crisis and paradigm reversal

3 Industrialized software development

3.1 Definition of industrialized software development

Following the taxonomy of Greenfield standardization might be seen as the key

 Allocation of extensive development costs of software products on high volumes

Table 1: Spectrum of software artifacts (Taubner 2005, Kilian-Kehr et al. 2007)

Obviously industrialization of SE is possible to a certain degree. Experts are even

 SE still “has indications of craft manufacturing” (Janßen 2005, p.284)and it will

which decreases the trustworthiness in these components because reliability and

3.2 A new software engineering method: agile development

 Individuals and interaction instead of processes and tools

3.3 Implications to review SE the global context

4 The global perspective

4.1 Global software development

 Delegating development tasks to the most economically viable places to be more

 Simultaneous engineering is extended by “round-the-clock” development.

workforce and processes. According to Carmel this distance magnifies complexity in

Figure 3: Impacts of distance (Carmel, Agarwal 2001)

4.2 Problems of GSD

 Strategic dimension: There are different coordination mechanism and no

tools to support collaboration and the lack of informal communication (Herbsleb,

4.3 Approaches to tackle the problems of GSD

4.3.1 Established approaches

be set up to integrate diverse cultural and educational backgrounds (Ebert, De Neve

 asynchronous messaging systems (e.g. e-mail, web forum)

and in most cases also:

 shared project repositories (for documents , source code etc)

4.3.2 Open source software development (OSSD)

4.3.3 Tools for distributed collaborative development and how they

The possibility to handle distance more efficiently by using powerful communication

Table 2: Evaluation of collaboration tool categories (Hildenbrand 2008)

CSDP offer a central data repository (Robbins 2005), integrated groupware

availability of various centralized information, artifacts sharing functions and

As we have seen in paragraph 3 the level of industrialization in SE has increased

To conclude shortly: As already mentioned industrialization has been established in SE

Augustin, L., Bressler, D. & Smith, G. 2002, "Accelerating software development

Burger, W. Offshoring and Outsourcing to INDIA 2007, .

Carr, N.G. 2005, "Does software matter - Software-Industrialisierung", Informatik-

Damian, D. & Zowghi, D. 2003, "Requirements engineering challenges in multi-site

Damian, D. 2007, "Stakeholders in Global Requirements Engineering: Lessons Learned

Damian, D. & Moitra, D. 2006, "Guest Editors' Introduction: Global Software

Ebert, C. & De Neve, P. 2001, "Surviving global software development", Software,

Eckstein, J. & Josuttis, N. 2004, Agile Softwareentwicklung im Grossen: Ein

Feller, J. & Fitzgerald, B. 2002, Understanding open source software development,

Gibbs, W.W. 1994, "Trends in Computing: Software's Chronic Crisis", Scientific