Seminar Paper by Lorenz Hartmann

8/6/2019 Seminar Paper by Lorenz Hartmann

1/35

submitted: April 2009

by: Lorenz Hartmann20th of April, 1985Bad Schwalbach

Student-ID: 1016673

University MannheimLehrstuhl fr ABWL und Wirtschaftsinformatik

D 68131 MannheimPhone: +49 621 1811691, Fax +49 621 1811692

Internet:http://wifo1.bwl.uni-mannheim.de/

I NVESTIGATING THE INDUSTRIALABILITY OF GLOBAL DISTRIBUTED SOFTWAREDEVELOPMENT PROJECTS

Seminar paper


2/35

Content

1 Introduct ion and purpose ....................... ......... ......................... ....... ........................... . 1

2 Bas ics of software eng ineer ing ................................ ................................ ..................... 2

2.1 Key character i tics ................................ ................................ ................................ . 2

2.2 Plan based approach ................................ ................................ ............................... 3

2.3 Sof t are cr isis and paradig revisal................................ ................................ ....... 4

3 Industr ial ized software development ........................... ..... ........................ ........ .......... 5

3.1 Def inition of industr iali ed sof t are development................................ .................. 5

3.2 A new sof tware engineer ing method: agile development ................................ ........ 8

3.3 Implications to review SEthe global context ................................ ........................ 10

4 Th e global perspect ive ................................ ................................ ............................... 11

4.1 Global sof tware development ................................ ................................ ............... 11

4.2 Problems of GSD ................................ ................................ ................................ . 12

4.3 Approachesto tack le the problems of GSD ................................ .......................... 13

4.3.1 Established approaches ................................ ................................ ............. 14

4.3.2 Open source sof tware development (OSSD) ................................ ............. 17

4.3.3 Tools for distr i bured collaborative development and howthey can

change current development practice ................................ ................................ .... 19

5 Discuss ion ................................ ................................ ................................ ................... 22


3/35

F igures

F igure 1: Waterfall modell (R oyce 1987) ................................ ................................ ....... 3

F igure 2: Cost overunin projects (The Standish Group 1994) ................................ ......... 4 F igure 3: Impacts of distance {{28Carmel E. 2001}} ................................ .................. 12


4/35

T ables

Table 1: Spectrum of sof tware ar tifacts (Taubner 2005, K ilian-Kehr et al. 2007) ............. 6

Table 2: Evaluation of collaboration tool categor ies (Hildenbrand 2008) ....................... 20


5/35

Abbrev iat ions

CSDP Collaborative sof tware development platforms

GSD Global sof tware development IDE Integrated development environments

OSSD Open source sof tware development

SDP Sof tware development process

SE Sof tware engineer ing


6/35

Keywords

Industr iali ation of sof tware development

Global sof tware development Collaborative sof tware development platforms

Agile development


7/35

1 Introduct ion and purpose

By investigating the industr ialability of global distr i buted sof tware development

projects one is faced pr imar ily with the following problem set: To which amount is it

possi ble to standardi e processes, automate tasks and employ reusable components insof tware development practice in the general and in the global case. To answer this

question one hasto know what sof tware engineer ing1 (SE) exactly means, which k ind

of sof tware development approaches are available and why/howthey are applicable to

the var ious forms of sof tware products. F ur thermore it is impor tant to understand that

matured knowledge about sof tware development in a collocated situation exists.

However there is high uncer tainty how to adapt this knowledge to new trends and

developments in a globali ed wor ld (Herbsleb, Moitra 2001). F or instance projects are

increasingly character i ed by globally distr i buted projects teams. This leads to

diff iculties in communication, control and coordination. (Carmel, Agarwal 2001)

This paper will give a general introduction to sof tware engineer ing (cp. 2) and review

the current state of industr iali ation in sof tware development practice (cp. 3). In the

main par t of the paper the issue will be transferred to the global basis. Different dimensions which inf luence the current global sof tware development practice will get

introduced (cp. 4.1). Especially the question how to deal with distance will be assessed

by referr ing to case studies and new f indings of research (cp. 4.3.1). The reader will get to know why there is a strong emphasi e for standardi ation of processes in global

distr i buted sof tware development. Additionally the reader will also learn that there are

exper ts who try to change this tendency of standardi ation towards higher vitality in SE

by using new communication methods (cp. 4.3.2, 4.3.3). Later it will be presented how

global sof tware development might suppor t the tendency for fur ther industr iali ation in

SE. There will be a f inal discussion about the current state, the limits and trends of

industr iali ation in SE (cp. 5).

.

1 Sof tware engineer ing (SE) and sof tware development (SD) are used synonymously in the paper.


8/35

Error! Usethe Hometab to apply berschr if t 1 to the text that you want to appear here. Error! Usethe Hometab to apply berschr if t 1 to the text that you want to appear here. 2

2 Bas ics of software eng ineer ing

2.1 Key c h aracter ist ics

Sof tware engineer ing differs signif icantly from other engineer ing disci plines; this is not

only becauseit is still a juvenescent science that star ted 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 var ious f ields, especially the

computing- and application domain (Wal et al. 1993). Another difference is the lower

degree of industr iali ation in contrast to other engineer ing disci plines. Some exper ts

point out that SE still has indications of craf t manufactur ing (Janen 2005, p.284) and

emphasi e the high knowledge intensity and the creative attitude of SE (Meyer 2006).In contrast to other engineer ing disci plines SDPs are character i ed by an empir ical and

nonlinear proceeding (Williams, Cockburn 2003).But nonetheless it has to be regarded

that for some sof tware products mass production could already be established (e.g.operating system, off ice applications, etc.). So obviously there are many aspects to take

care of bylook ing at the current state of sof tware development. But before getting lost

into detail, the basics about this topic should get introduced. Inthe following it will be

descr i bed what sof tware engineer ing is and howit has developed.

Sommerville def ines sof tware engineer ing as an engineer ing disci pline that is

concerned with all aspects of sof tware production from the ear ly stage of system

specif ication to maintaining the system af ter it has gone into use. (2007, p.7)

According to his taxonomy it consists of four main activities. In the sof tware

specif ication par t engineers and sof tware users def ine the requirements of the sof tware

to be developed. The sof tware development phase includes the design of the

sof tware/sof tware system and its implementation. This step is seamlessly linked with

sof tware validation, which covers unit and system testing besides reinsur ing therequirements of the customer. In the sof tware evolution phase sof tware is adapted to

customer and market requirement. Analysis as well as maintenance of the existing

system is done. Obviously the phases are over lapping extensively and are not

representing a ser ial process. They should be seen as an under lying gener ic framework

of the main models of sof tware development which have evolved until today

(Sommerville 2007)


9/35

Error! Use the Home tab to apply berschrift 1 to the text that you want to appear here.Error! Use the Home tab to apply berschrift 1 to the text that you want to appear here. 3

2.2 P lan based approach

The first approaches which derived from software en ineerin research were plan based

software processes. The most known model is the waterfall model. It is composed in

several cascadin phases. In theory each phase is performed sequentially startin not before the previous phase has finished and documentation is delivered (Royce 1987).

But practically the sta es show a hi h level of interdependency (Sommerville 2007). As

an example desi n problems are found durin codin or requirements are identifieddurin the desi n 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 extendin costs and time consumption some phases in development

are usually put on hold after some iterations (e. . requirement analysis, desi n phase).

This mi ht lead to impractical systems since requirements could have chan ed in the

meanwhile. The ma jor problem of the process is its inflexible portioninof the pro ject

into distinct sta es. Commitments have to be made at an early sta e in process, which

makes it difficult to respond to chan in requirements (Sommerville 2007, p.67) andlead to the problem that durin the maintenance phase previous processsta es have to

be repeated. (Sommerville 2007) (Fae ri, Hanssen 2007).

F igure 1: Waterfa ll mode ll (Royce 1987)


10/35


2.3 Software crisis and paradigm reversa l

Plan based software development was the state-of-the-art until the be innin of the

1990s. But it could not overcome the dilemma between keepin cost and time exposure

low and deliverin useful complete systems (Sommerville 2007). Therefore it led tovery poor success rates of software pro jects and the so called software crisis in the

be innin of the 1990s. The Chaos Report shows that only 16.2% of the examined

pro jects could be delivered on-time and in-bud et and especially in lar e software

pro jects 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 avera e softwaredevelopment overshoot is scheduled by half ; lar er pro jects enerally do worse. (1994, p.86). Evidently the plan based approaches with extensive documentation and a

si nificant overhead in plannin , desi nin and coordination seemed not to be

appropriate for most software development pro jectsany lon er. The needs had chan ed

si nificantly. Software development had become an on oin process with shorter life

cycles instead of a process which always starts from scratch (Sommerville 2007). Due

to the fact that business needs were rapidly chan in there was a demand for fast

product delivery and features which could be inte rated steadily into a runnin system(Janen 2005). The previous software development techniques were identified as

inefficient processes and there was an increasin demand for lower software production

and maintenance costs (Sommerville 2007). One proposition to address these new

developments was to extent the de ree of industrialized software development which

will be discussed into more detail in the followin para raph(cp. 3.1).

15.50%

31.50% 29.60%

10.20% 8.80%4.40%

0.00%5.00%

10.00%15.00%20.00%25.00%30.00%35.00%

Under20%

21 -50%

51 -100%

101 -200%

201 -400%

Over400%

F igure 2: Cost overun in projects ( T he Standish Group 1994)


11/35


3 Industr ial ized software development

3 .1 Def in it ion of industr ial ized software development

Industr iali ation can be def ined as the spread of highly productive industr ial

approaches in the production of goods and services. (Zwahr 2006, p.263) Greenf ield

def ines the patterns of industr iali ation 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 standardi ation of processes, architectures and packaging

norms. (2004, p.17) Subsequently it will be presented which patterns of

industr iali ation are transferable to SE. In doing so, the questions will be answered how

and to which extend they have been adapted to SE. F ur thermore the limitations of industr iali ation in SE will be introduced.

F ollowing the taxonomy of Greenf ield standardi ation might be seen as the key

character istic of industr iali ation. In SE standardi ation was f irst applied with thedevelopment of high level programming languages like C , which have provided

language level and machine-architecture independency (Stroustrup 1986). Another

cr itical innovation to extent standardi ation 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). F ur thermore

or gani ations and committees (ISO, IEEE, W3C) established industry standards for

sof tware 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 sof tware cr isis with its ability of being slow and

expensive (Greenf ield, Shor t 2004), got challenged. Industr ial production pr inci ples like

speciali ation, division of labor and automation of process steps got into the focus of interest. Instead of creating a sof tware ar tifact from scratch, sof tware products were

increasingly combined out of sof tware components of selected suppliers (Greenf ield,

Shor t 2004). This approach, which is called component based sof tware engineer ing

(CBSE), is descr i bed by Sommerville as a process of def ining, implementing and

integrating or composing loosely coupled independent components into systems (


12/35


2007, p.440). There are many advantages of developing sof tware in this industr iali ed

manner :

Allocation of extensive development costs of sof tware products on high volumes

of customers (economy of scale) (Maidl 2005, Taubner 2005) Sof tware becomes a commodity which can be bought easily according to

individual preferences (Sof tware as a service) (Carr 2005) Sof tware as a commodity leads to market concentration (e.g.: Microsof t, SAP)

which has the positive effect of general accepted standards (e.g.: f ile formats)

(Taubner 2005)and reduction of niche-suppliers (Maidl 2005) Higher dependability and less development costs because reused components are

already specif ied, designed, implemented and validated in work ing systems

(Sommerville 2007) R eduction of process r isk par ticular when relatively lar ge components such as

subsystems can be reused (Sommerville 2007) The overall SDP is aimed to be accelerated (Sommerville 2007)

However the pr inci ples of industr iali ation are not generally applicable to all k ind of

sof tware products. Sof tware ar tifacts differ depending on the number of customers they

are developed for, the product var iability and the related ability for

standardi ation(Taubner 2005, K ilian-Kehr et al. 2007), which is indicated in table 1.Products Spe cific solutions

Syst em a nd ma ss ma rk e t p roducts

App lic a tion softw a r e

Ent e r p ris esoftw a r e

Int eg r a tion Indi vidu a l

DMS, o pe r a tin gs yst em s ,app lic a tion s e r ve r or n e twork softw a r e, offic e

and e-ma il

port a ls , d a t aw a r eh ous e,CRM

ERP , SCM,in ve ntor yma n ageme nt

Introduction of ent e r p ris eapp lic a tions ,Int eg r a tion of co mp on ents and s pe cific softw a r e

ex t ensions

s a le s ord e r p roc e ss e s ,a irlin e b ookin gs yst em

T able 1: Spectrum of software art ifacts ( T aubner 2005, K ilian-Ke h r et al. 2007)

This table shows mass sof tware products like database management systems (DMS),

operating systems, application server or network sof tware at the far lef t. They offer a

high degree of common functionality (K ilian-Kehr et al. 2007), are widely used, have

stable requirements and are not designed for a par ticular company. Thereforethey are


13/35


well suited for being developed in components (K ilian-Kehr et al. 2007). The other

categor ies to the r ight are character i ed by increasingly less oppor tunities for

standardi ation. The extreme at the far r ight of the table is represented by individual

customi ed sof tware solutions. F or these k inds of sof tware ar tifacts standardi ation is

not meaningful as the requirements of the sof tware aretoo specif ic. Even if there would

be components available the extra cost to f ind, 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 industr iali ation of SE is possi ble to a cer tain degree. Exper ts are even

agreed that dur ing time many sof tware ar tifacts which belong to the categor ies on the

r ight of the table will have the capability to be standardi ed and moveto the categor ies

on the lef t of the table (Taubner 2005). However there are many implications of SEwhich will limit the level of industr iali ation and determine that a signif icant share of

sof tware will not be a commodity within the foreseeable future (Taubner 2005, p.295).F ollowing ar guments suppor t this thesis:

SE still has indications of craf t manufactur ing (Janen 2005, p.284)andit will

take time to convince people to switch fromtheir established work ing procedures

to more speciali ed and eff icient work ing methods (Janen 2005)

According to McK insey only 7% of German IT employees work in the product business which has extensive potential for industr iali ation whereas 93% of the

employees work in sof tware services (Hoch 2005) Component models are not as easy applicable as theory might illustrate. The

components have to be independent and completely specif ied by their interfaces.

There have to be component standards that facilitate the integration of components. F ur thermore middleware is needed that independent, distr i buted

components are able to communicate with each other (Sommerville 2007).

Besides these impor tant prerequisites the real burdens are even stronger. In SE thenot invented here syndrome (Janen 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 (Janen 2005). This issue is even enforced

when the source code of components is hidden dueto propr ietary r ights which is

highly common in industry. Components of ten have to be seen as a black box,

which decreasesthe trustwor thiness in these components because reliability and


14/35


stability cannot be ensured (Sommerville 2007).Moreover the black box pr inci ple

can lead to increased maintenance costs or even incompati bility when there is a

system change (Sommerville 2007). Phases like R E and design are creative activities which are highly knowledge

intensive (Meyer 2006). Par ts of SE offer less capability to be standardi ed and

approaches haveto be foundto makethese processes more eff icient.

Addressing the last topic of the previous enumeration agile development will be

introducedin the next paragraph.

3 .2 A new software eng ineer ing met h od: ag ile development

The sof tware cr isis has not only led to a shif t towards a higher degree of industr iali ation of sof tware development; the static plan based work ing methods were

also questioned. It was recogni ed that most SDPs differ in many cases fromthe pre-

def ined process of other engineer ing disci plines that follow a cer tain assembling order

and produce the same results every time (Schwaber, Beedle 2001). People got aware

that most SDPs are character i ed by an empir ical and nonlinear proceeding (Williams,

Cockburn 2003) and are marked by inevitable changes throughout its life cycle

(Highsmith, Cockburn 2001, p. 120)like requirements changes andtechnology changes.

In the mid 1990s practitioners f irst developed methodologies to face this issue andembrace rather than reject higher rates of change (Williams, Cockburn 2003, p.39)

within the development process (see 2.3).F ollowing the tar get to facilitate the process

of sof tware development and enhance quality, speed of delivery and customer

satisfaction these approaches were called agile methods (Williams, Cockburn 2003,

Sommerville 2007).

The key character istics of these methods are the focus on incremental delivery: The

system is developed from abstract specif ications and then iteratively ref ined by using customer input. Well known agile methods are Extreme Programming (XP) (Beck

1999), Crystal (Highsmith, Cockburn 2001), Scrum (Schwaber,Beedle 2001) andF DD

(De Luca 2009). In 2001the Agile Alliance, a group of the representatives of the

leading agile methods formulated the four basis pr inci ples of agile methods:

Individuals and interaction instead of processes andtools


15/35


Executable sof tware instead of extensive documentation Customer collaboration over contract negotiation R esponding on change over following a plan

According to the f irst pr inci ple programmer following the XP approach work in pairswhich leads to higher involvement, motivation (F owler 2006) and shows a similar

productivity (due to less rework) astwo programmers work ing separately (Williams et

al. 2000). The four th pr inci ple for instance implies that changes of system requirements

have to be expected and that the system has to be designed to accommodate these

changes (F owler, Highsmith 2001). The four generative rules of agile methods lead to

higher customer collaboration/user engagement and the distr i bution of decision mak ing

author ity over the whole development team (Highsmith, Cockburn 2001). Advantages

of XP arethat the f inal product is more consistent with the business needsthan by using classic sof tware development methods (Sommerville 2007) andthe 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-si ed business systems and cer tain personal computer

products (e.g. computer games) (Williams, Cockburn 2003, Sommerville 2007).

R easons for this limitation are as followed:

Customer involvement, which can be a cr itical success factor for the SDP,depends on the willingness and availability of the r ight customers who can

represent all system stakeholders (F aegr i, Hanssen 2007, Damian 2007). Through the attempt to deliver running sof tware quick ly and with a small amount

of documentation there is strong emphasi e on extensive formal and informal

communication and coordination dur ing the SDP. It incurs that programmersshould have suitable personalities for intense involvement and that the project

should be character i ed by a low level of employee turnover (Sommerville 2007).

Case studies have shown that projects can collapse when suppor ters of agilemethods in cr itical position of the project leave the project team (F aegr i, Hanssen

2007). The missing documentation may make the source code diff icult to understand

which might create problems in maintenance and validation (Sommerville 2007). There might occur contractual problems. Normal contracting methods are based

on system specif ications which are def ined at the very beginning of the project.


16/35


Using agile methods system requirements are specif ied only dur ing the

development process and contracting according to system specif ications is not

applicable (Sommerville 2007).

Never theless agile methods have faced a high level of recognition because theyintroduced an alternative methodology to the static plan based development approaches

(Williams, Cockburn 2003). Although they wereinitially developed to suppor t sof tware

development in a collocated environment since 2003 researchers and practitioners try to

f ind out possi bilities to blend selected agile practices with the regular practices.

(Williams, Cockburn 2003, p.40,Boehm 2002) Some exper ts are even convinced that

agile methods are an adequate approach for the sof tware development of lar ge scale

system developments and projects character i ed by distr i buted development teams

(Hildenbrand et al. 2008, Eckstein, Josuttis 2004). One ar gument is that agile methodswere usedin open source sof tware development (OSSD) projects successfully which are

character i ed by distr i buted development teams (see 4.3.2).

3 .3 Impl icat ions to rev iew SE t h e global context

Summing up the implications of sof tware development, it should be mentioned that SE

has changed signif icantly af ter the sof tware cr isis in the ear ly 1990s. Onthe one hand

industr iali ation has comeinto the focus and the ideas of standardi ation, f lexi bility,and off-the-shelf products have become highly recogni ed (cp. 3.1). F or the f irst time

sof tware products were split into modules which imply the oppor tunity to distr i bute

SDPs not just according to tasks (R E, implementation, testing, etc.) like in plan based

approaches. Using CBSE companies have received the chance to allocate the

development of components of a sof tware system to different teams and let them work

independently on a smaller piece of sof tware. Therefore sof tware can be developed in

remote locations and simultaneously by different companies. This implicates higher

eff iciency through division of labor and simultaneous work but it can lead to higher coordination and communication effor ts 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

par t of SE is in many cases an empir ical and nonlinear process (cp. 3.2). They

introduced agile methods to make the implementation phaseitself more eff icient. In the

main par t of the paper it will be investigated how these two trends in sof tware

development are employed in the global context.


17/35


4 Th e global perspect ive

4 .1 Global software development

In the last two decades sof tware development practice was forced to adapt to the

ongoing globali ation of business. National markets turned into global markets and new

forms of competition and cooperation across national borders hadto be developed. The

result is global sof tware development (GSD) which evolved out of several reasons. The

benef its can be summar i ed 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 asthe initial dr iving force of outsourcing Capitali e the global resource pool and recruit talented and suitable people for

cer tain tasks regardless of location, nation andtime zone differences Tack le demand for faster product delivery by using time zone differences in

round-the-clock development Exploit market oppor tunities of proximity to the market, including knowledge of

customers andlocal conditions

R egarding these goals it seems that the idea of the industr ialization of sof twaredevelopment which was introduced beforeis simply transferredto the global issue:

Simultaneous engineer ing is extended by round-the-clock development. Instead of work ing with distr i buted teams within one country and between

strongly related or ganizations, in GSD projects people are or ganizationally,

spatially and time dispersed. F ollowing the division of labor pr inci ple employees work in vir tual teams for

sometimes one single project by using information and communicationtechnologies.

Never theless the practical exper iences have shownthat 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 character ized by a higher distance in

contrast to collocated sof tware development. This refers to its high distr i bution of


18/35


19/35


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

Moitra 2001). Communication dimension: F ormal and informal communication is steadily used

in sof tware development projects. F ormal communication is needed to apply

crucial tasks like def ining interfaces, updating project status, determing

responsi bilities. Informal communication is used because of the high vitality of a

SDPs. It gets more relevant the more uncer tainty the project inhi bits (e.g.:

requirements are not def ined at the beginning) (Damian 2007). Informal talks

keep the people updated about what is happening aroundthem. Conveniently they

get to know who is work ing at which topic, the status of sub-projects or which

person has exper tise in which area. The absence of informal conversation, which

is typically for projects at remote sites, can keep crucial problems unrecognizedand thereforelead to misalignment between concurrent work which causes rework

(Damian, Zowghi 2003). Knowledge management dimension: Since there areless possi bilities for informal

communication and moreover cultural problems (e.g.: fear to loss of intellectual

proper ty) knowledge management in a GSD project has to not managed more

intensively as in a collocated projects. F iltered information should be avoided and

reuse oppor tunities 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 ar ise dur ing the

project through different versions of tools or incompati ble data formats. Moreover

tasks like the transmission of cr itical data in conf iguration management have to be

meticulously planned and executed in contrast to a non GSD (Herbsleb, Moitra2001). Eber t sees performance rapidly decreasing when multisite use is involved

in cer tain tasks, dueto heterogeneous server and network infrastructure.(Eber t, De

Neve 2001)

F aced with these burdens different approaches for eff icient GSD were developed which

will be discussedin detail in the next paragraph.

4 .3 Approac h es to tackle t h e problems of GSD

There are two main approaches of GSDto tack le the analysed problems. The f irst

der ived out of a commercial back ground. In the mid 1990s some companies star ted as


20/35


pioneers to develop sof tware globally. Using their exper ience they ref ined the way to

deal with GSD. These established approaches of GSD will get introduced in the next

paragraph by referr ing to exper iences from different cases related to GSD (cp. 4.3.1).

The other approachis the application of non-commercial open source practices. These

projects are also character ized by globally distr i buted developers but distinguish

signif icantly from commercial approaches. Theyimply many other aspects and ideas

and will be introduced subsequently (cp. 4.3.2). Later tools which suppor t distr i buted

collaborative sof tware development will be presented. They havethe potential to reduce

distance signif icantly and star t a new phase of GSD (cp. 4.3.3).

4 .3 .1 Establ ish ed approac h es

There aretwo main ideas howto deal with distance in GSD. Onthe one hand you cantry to avoid distance in the development process, on the other hand you cantry to

handle distance more eff iciently that it becomesless relevant. Since the development of

eff icient tools to suppor t collaboration was in its infancy in the beginning of GSD,

pr imar ily tactics that went beyond communication technologies were applied in GSD

aimed at reducing intensive collaboration, national and or ganizational cultural

differences andtemporal differences (Carmel, Agarwal 2001, p.22).

The most regarded issue to avoid distance is to reduceintensive collaboration, which istaken up in every case descr i ption regarded for this paper. Carmel states, that most

companies try to engage the foreign entity only in tasks that are well def ined andstructured (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 near ly 100% onshore andto hand structured tasks like construction and quality

assurance over to the offshore par tner (Cusick, Al pana 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 (Eber t, De Neve

2001, Cusick, Al pana Prasad 2006,Bur ger 2007, Kobitzsch et al. 2001, Battin et al.

2001). Some exper ts ver ify this proceeding by stating that iterative and incremental

development in distr i buted environments is diff icult (Paasivaara, Iassenius 2004).

Another approachto limit the need for collaboration is to give the foreign entity full

responsi bility for a system, system component, product or corporate process.F ollowing


21/35


this CBSE based approachthe 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 under lying pr inci pal for this proceeding in GSD are the exper iences of the

past. The company Alcatel studied projects for f ive years by distinguishing the degree

of collocation. F or example they found out that collocated teams needed half of the time

for defect detection in validation activities than a distr i buted team which works onthe

same task (Eber t, De Neve 2001). This was ver if ied by Teasley, who repor ts that in

collocated teams, productivity and job satisfaction are much higher (Teasley et al.

2002). Therefore Eber t considers team-task collocation in a distr i buted 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 (Eber t, De Neve 2001). These facts lead to

the conclusion that the methodologies applied in GSD are in contrast to themethodologies applied in collocated sof tware engineer ing projects more focused on plan

based sof tware engineer ing approaches. They favor clear ly separated tasks.

Although this proceeding reduces distance, many of the pr ior named problems are not

solved. To alleviate the remaining distance andto handle it more eff iciently several best

practices have been developed since the beginning of GSD. A keylearning in most case

studies is that there should be an established a relationshi p between team members of

remote locations (Carmel, Agarwal 2001, Carr 2005). This way they can identify with

the team, feel responsi bility for the team, are able to build up trust. As a result of that

the electronic communication becomes effective. To addressthese f indings the concept

of cultural liaison is widely used to br idge the cultural gap across sites and

or ganizations (Carmel, Agarwal 2001, Carr 2005). According to this concept a key

person of the project acts as ambassador andlinks the different sites of the project.Besides building up trust, the cultural liaison enables to spread domain exper tise

because knowledge can be easily shared using this link (Carmel, Agarwal 2001, Carr

2005). In a lar ge project of Motorola, key engineers of the remote locations moved to

the main US based site of the company andtook par t in a three month workshop. They

learned the system, hel ped completing R E 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 Eber t claims that one

way to improve is a heavy exchange of teams and management [] wh ich gradually

build mutual understanding. (2001, p.68) Moreover he states that mixed teams should


22/35


be set up to integrate diverse cultural and educational back grounds (Eber t, De Neve

2001). Another central statement in many case studies is that the different development

processes at the remote sites have to be managed eff iciently. Instead of installing

common in-detail processes everywhereit 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 proposesto handle the

minor processes as a black box and concentrate on the interface def inition r ight in the

initial architecture def inition phase. Pursuant to this the architecture of the project

descr i bed byBattin followes three main pr inci ples: low coupling among network

elements, well def ined interfaces and concise semantics for the network element

behaviors (Battin et al. 2001). R egarding 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 dispar ity are for example the formation of teams, the allocation of

work between teams, the way quality was ensured andthe decision in which phases

iterative development should be applied. Never theless all papers point out the crucial

need for communication tools. The commonly used tools are (Eber t, De Neve 2001,

Cusick, Al pana Prasad 2006,Bur ger 2007, Kobitzsch et al. 2001, Battin et al. 2001,R ao

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 shar ing)

and in most cases also:

shared project repositor ies (for documents , source code etc)

wik i webs (which substitute shared documents and glossar ies)

Summar izing the observations of the different case studies the distance of GSDis still

high and companies adapt their sof tware development practices to this situation.

Companies switch fromtheir par tly agile development methods in collocated situations(Boehm 2002) to str ictly plan based approachesin global projects (Cusick, Al pana

Prasad 2006). Most companies prefer to split work according to functional tasks and


23/35


only some are following par tly a CBSE approach (Kobitzsch et al. 2001). In GSD

coordination mechanisms like plans, schedules, system-level design and def ined

processes are seen as a crucial success factor. They are considered to be moreimpor tant

in geographically distr i buted sof tware development than in collocated sof tware

development (Herbsleb, Gr inter 1999). But surpr isingly this f inding seems not to be a

natural law. Open source sof tware development (OSSD), which is also character ized by

geographically distr i buted development lacks many of the presented coordination

mechanisms but also succeedsin developing sof tware of high quality and functionality

(Mockus et al. 2002). Thereforeit will be presented in the following paragraph

4 .3 .2 O pen source software development ( O SSD)

OSSD is a way for building, deploying and sustaining lar ge sof tware systems on aglobal basis (Sommerville 2007). It is an alternative community-intensive socio-

technical approach to develop sof tware systems, ar tifacts and social relationshi ps.

(Scacchi 2007, p.464). One of the basic pr inci ples of this sof tware development style is

that licenses and legal arrangements ensure that the source code of OSSDis generally

available for remote access.Moreover OSSDtypically has a central body, consisting of

some of the core developers, who are responsi ble 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 lar ge number of volunteers(Mockus et al. 2002)

The OSSD developers aretypically also end users (Mockus et al. 2002) Work is not assigned. The under lying belief in the freedom of choice ensuresthat

developers just under take the tasks they areinterested in (Benk ler 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 sof tware 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 waysto observe and par tici pate in project related topics are

bulletin boards, group blogs as well as to do lists and project wik is (Scacchi 2007).


24/35


These var ious types of sof tware informalism are accessi ble through project related

websites and por tals. 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 ensuregood sof tware development. Instead of

explicit administrative control OSSD projects rely on gentle but suff icient social

control (Scacchi 2007, p.462). OSSD projects are character ized by a sk ill-based

mediocracy, in which project par tici pants self-or ganize around exper tise, reputation

and accomplishments of core developers, secondary contr i butors and ter tiary reviewers

as well as other per i pheral volunteers (Scacchi 2007, p.461). This includes voting on

the approval of individual contr i bution to ongoing project sof tware (F ielding 1999),

shared peer reviewing (Benk ler 2006, DiBona et al. 2005) or as well the projectsrecognition of a core developers status, reputation and geek fame (Scacchi 2007). This

vir tual 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 onthe reduction of coordination effor ts. The vast major ity of source code (~80%)

is created solely by core developers and most par tici pants typically contr i bute to just a

single module (Scacchi 2007, p.460) of the system or tasks like defect repor ting

(Mockus et al. 2002). The coordination concerns in the Apache OSSD project for

instance are sharply limited by the stable asymmetr ically controlled interfaces. Anyfunctionality beyond [the basic development of the Apache server]is added by means of

var ious ancillary projects that interact with Apache only through Apaches well def ined

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 possi bility 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 manyimplications which might be useful for commercial GSD. One is that

industr ialization in the sense of CBSE is applicable in global distr i buted projects. OSSD

shows that coordination effor ts are limited by high modular ization and stable

asymmetr ically controlled interfaces (Mockus et al. 2002). Moreover the evolutionary

character istic of OSSD through the interrelations between projects might establish the


25/35


view to see GSD more as an oppor tunity than as a burden. Although meanwhile shar ing

and reuse became commonin traditional SE sof tware, the effor ts of traditional SE

projects are still setup to produce systems whose growth and evolution is limited

(Scacchi 2007). In contrast to that in OSSDthe focusis on sof tware evolution which is

a process of co-evolution of interrelated and independent OSSD projects, people

ar tifacts, tools code and project specif ic processes (Capiluppi, Michlmayr 2007, Weiss

et al. 2006). The newtypes of socio-technical work practices, development processes

and community network ing excel traditional SE (Scacchi 2007). F inally the extensive

use of communication tools in OSSD already had and will have signif icant impact on

SE to reduce distance fur thermore and facilitate GSD. Maurer is suppor ting this

ar gument by stating that adequate and timely shar ing of information and knowledge in

all directions, proactive change, management, and process monitor ing are some of theimpor tant factors required for successful project collaboration.(Maurer 1996) Therefore

tools for distr i buted collaborative development will be discussedin the next paragraph.

4 .3 .3 T ools for d istr ibuted collaborat ive development and h ow t h eycan c h ange current development pract ice

The possi bility to handle distance more eff iciently by using powerful communication

tools is used in commercial GSD but as it was observedin 4.3.2 even moreintensively

in OSSD. The following paragraph investigates which features of communication toolsreduce distance signif icantly and enable the practicability of sof tware development

similar to a collocated situation.

In the regarded cases of commercial GSD developers of distr i buted projects employ two

k inds of tools separately to conduct their work (cp. 4.3.1): On the one handthey use

collaborative sof tware development tools (CSCW-tools) or also known as groupware

and on the other hand they utilize integrated development environments (IDE).

Groupwaretools hel p people to conduct a commontask and arethe basis for computer suppor ted cooperative work (Hildenbrand 2008). Some of the already presented tools

like asynchronous messaging systems (e.g. e-mail, web forum) and synchronousmessaging systems (e.g. instant messaging, video-conferencing and telephone-

conferencing, screen shar ing) are typical groupware applications (cp. 4.3.1). In contrast

to that IDEs integrate individual sof tware development tools like auto complete

functions, code generators and automatic code documentation (Sommerville 2007)


26/35


which support the individual developer into a consistent interface and workin

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 roupware and IDE

applications to conduct a certain task leads to inefficient development in GSD. In order

to tackle this issue the open source community inte rated Groupware and IDE

functionality into collaborative software development platforms (CSDP). Later these

CSDP were successfully applied in several OSSD pro jects (Robbins 2005, Au ustin et

al. 2002, Feller, Fitz erald 2002).

T ab le 2: E va luation of co llaboration too l categories (Hildenbrand 2008)

CSDP offer a central data repository (Robbins 2005), inte rated roupware

functionality like IP telephony which is accessible either directly throu h the web

browser or via IDE plu -ins and a fully internet based user interface (e. .sourcefor e.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 buildin throu h the

availability of various centralized information, artifacts sharin functions and

stakeholder entities (Hildenbrand 2008). Moreover better traceability of individual

process steps as well as relations between different software artifacts and contri butin

stakeholders throu h hi h transparency can be achieved. In literature this is seen as a

crucial success factor in GSD, because current and future PM [in GSD pro jects] will bemore concerned with trackin pro ject work processes and efficient and effective sharin

of information and knowled e, amon pro ject contributors. (Chen et al. 2003, p.1)

Due to the hi h performance of CSDP in OSSD pro jects the platforms were transferred

to the commercial context. The most common CDSP are CodeBeamer, CollabNet

Enterprise and Sour eFor e Enterprise. They offer a common set of CSDP features,


27/35


have a considerable market share and [] have been used in multitude distr i buted

projects. (Hildenbrand 2008, p.33) According to a study of R odr iguez as well as a

rank ing of HildenbrandCodeBeamer was seen asthe best overall platform (Hildenbrand

2008, R odr iguez et al. 2007). Although str ictly tool based SE approaches prevail

signif icantly in terms of frequency and state of elaboration, in 2003 already 65% of

sof tware development companies at least intended to use a CSDP for distr i buted

projects by the year 2005 (Webster 2003).

The different k ind of communication tools were presented here becausethey 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 sof tware development methods applicable in distr i buted collaborative

sof tware development.


28/35


5 Discuss ion

The paper shows the most vital trends and developments in global sof tware

development. It indicates that today the crucial question regarding SE is not about the possi bility of industr ialization in sof tware development because there is no doubt that SE has already reached a cer tain level of industr ialization. The question is what the

(current) limits for industr ialization in SE are and howthey are inf luenced by GSD.

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

signif icantly until today. Numbers of indications of craf t manufactur ing in SE have

been renewed by more professional approaches based on improved tools and

automation, more appropr iate use of components and more eff icient project

management. (Taubner 2005) Nonetheless industr ialization of SE solely cameinto the

focus of interest due to the trend of outsourcing and offshor ing at the end of the 1990s

(Taubner 2005). However it is crucial to understand that industr ialization was widely

practiced already beforethis time. It was shown that already in the beginning of the

1990s some sof tware ar tifacts were produced according to the pr inci ples of

standardization, modular ization, economy of scale and a shif t towards commodities (cp.3.1). These pr inci ples were applied to increase the eff iciency by reducing cost/r isk and

increase effectiveness by ensur ing sustainability (Maidl 2005). Although the ensuing trend to outsourcing/offshor ing at the end of the 1990s raised the attention of

industr ialization of SE cur iously it countervailed the goal of increased eff iciency and

effectiveness at f irst. 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 eff iciency (cp. 4.3.1). This development signif ies the dilemma of

industr ialization on the global basis. On the one hand pr inci ples of industr ialization like

simultaneous engineer ing and division of labor can be put into a global context (cp. 4.1)

but on the other hand oneis faced with additional distance. Or ganizational, spatial andtime dispersed vir tual teams lead to lower eff iciency of processes dueto diff iculties in

communication, control and coordination (cp. 4.2). F or instance agile development

methods which offer increased eff iciency 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 suff icient


29/35


suppor t for spatial, temporal and or ganizational distr i bution [] and fea ture a superb

integr ity and traceable information supply. (2008, p.36) Dueto these facts CSDP could

decrease distance in GSD signif icantly and reducethe dilemma of industr ialization in a

global context.

To conclude shor tly: As already mentioned industr ialization has been established in SE

to a signif icant degree. The increased amount of features of communicatin tools (cp.

4.3.3) will be one reason whyindustr ialization of SE will even continue to expandin the

future. Others are fur ther standandardzation, outsourcing and offshor ing which will

encourage companies to strengthen their processes, be moreinnovative and manage

tasks more eff iciently (Taubner 2005). The cr itical question for fur ther investigation is

about upcoming limits for industr ialization of GSD specif ically and SEin general.


30/35

R eferences

Augustin, L., Bressler, D. & Smith, G. 2002, "Accelerating sof tware development through collaboration", Proceedings of the 24th International Conference onSoftware Engineering ACM New York, NY, USA, , pp. 559.

Battin, R .D., Crocker,R ., Kreidler, J. & Subramanian, K. 2001, "Leveraging resourcesin global sof tware 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.

Benk ler, Y. 2006, The wealth of networks: How social production transforms marketsand freedom, Yale University Press, New Haven.

Boehm, B. 2002, "Get ready for agile methods, with care", IEEE Computer, vol. 35, no.1; feasi ble and preferable in some circumstances, pp. 64-69.

Bur ger, W. Offshoring and Outsourcing to INDIA 2007, .

Capiluppi, A. &Michlmayr, M. 2007, "F romthe cathedral to the bazaar : An empir ical study of the lifecycle of volunteer community projects" in Open Source

Development, Adoption and Innovation Spr inger, Boston, pp. 31-44.

Carmel, E. & Agarwal, R . 2001, "Tactical approaches for alleviating distance in global sof tware development", Software, IEEE, vol. 18, no. 2, pp. 22-29.

Carr, N.G. 2005, "Does sof tware matter - Sof tware-Industr ialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 271-273.

Chen, F ., Nunamaker Jr., J.F ., R omano Jr., N.C. & Br iggs, R .O. 2003, "A collaborative project management architecture",System Sciences, 2003. Proceedings of the36th Annual Hawaii International Conference , pp. 12.

Cusick, J. & Al pana Prasad 2006, "A Practical Management and Engineer ing Approachto OffshoreCollaboration", Software, IEEE, vol. 23, no. 5, pp. 20-29.

Damian, D. & Zowghi, D. 2003, "R equirements engineer ing challenges in multi-sitesof tware development or ganizations", Requirements Engineering, vol. 8, no. 3,

pp. 149-160.Damian, D. 2007, "Stakeholders in Global R equirements Engineer ing: Lessons Learned

from Practice", Software, IEEE, vol. 24, no. 2, pp. 21-27.

Damian, D. &Moitra, D. 2006, "Guest Editors' Introduction: Global Sof twareDevelopment: HowF ar Have WeCome?",Software, IEEE, vol. 23, no. 5, pp.17-19.


31/35

De Luca, J. 2009, , Feature Driven Developemnt . Available: htt p://www.nebulon.com/fdd/index.html [2009, 21st of Apr il] .

DiBona, C., Stone, M. & Cooper, D. 2005,Open sources 2.0, O'R eilly Media.

Eber t, C. & De Neve, P. 2001, "Surviving global sof tware 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, Dpunk t-Ver l., Heidel ber g,Germany.

F aegr i, T.E. & Hanssen, G.K. 2007, "Collaboration, ProcessControl, and F ragility inEvolutionary Product Development", Software, IEEE, vol. 24, no. 3, pp. 96-104.

F eller, J. & F itzgerald, B. 2002, Understanding open source software development,Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA.

F ielding, R .T. 1999, "Sharedleadershi p in the Apache project", Communications of the ACM, vol. 42, no. 4, pp. 42-43.

F owler, M. 2006, 18th of July 2006-last update , Using an Agile Software Process withOffshore Development . Available: htt p://www.mar tinfowler.com/ar ticles/agileOffshore.html [2009, 21st of Apr il] .

F owler, M. & Highsmith, J. 2001, "The Agile Manifesto", Software development, vol. 9,no. 8, pp. 28-35.

Gi bbs, W.W. 1994, "Trendsin Computing: Sof tware's Chronic Cr isis",Scientific

American, vol. 43, no. 9, pp. 86.

Greenf ield, J. & Shor t, K. (eds) 2004,Software Factories: Assembling Applicationswith Patterns. Models, Frameworks and Tools. , Wiley Publishing, Inc.

Herbsleb, J.D. & Gr inter, R .E. 1999, "Splitting the or ganization andintegrating thecode: Conway's law revisited", Software Engineering, 1999. Proceedings of the1999 International Conference on , pp. 85.

Herbsleb, J.D. &Moitra, D. 2001, "Global sof tware development", Software, IEEE, vol.18, no. 2, pp. 16-20.

Highsmith, J. &Cockburn, A. 2001, "Agile sof tware development: the business of innovation", IEEE Computer, vol. 34, no. 9, pp. 120-127.

Hildenbrand, T. (ed) 2008, Improving traceability in distributed collaborative softwareengineering:a design science approach , Peter Lang, F rankfur t a.M.

Hildenbrand, T., Geisser, M., Kude, T.,Bruch, D. & Acker, T. 2008, "AgileMethodologies for Distr i buted Collaborative Development of Enterpr ise


32/35

Applications", International Conference on Complex, Intelligent and Software Intensive Systems, 2008 (CISIS 2008) , pp. 540.

Hoch, D.J. 2005, "Gefahr Offshor ing - Sof tware-Industr ialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 287-291.

Hofstede, G.J. 2005,Cultures and Organizations: Software for the Mind, McGraw-Hill.

Janen, R . 2005, "Die Psychologie des Entwick lers - Sof tware Industr ialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 284-286.

K ilian-Kehr, R ., Terzidis, O. & Voelz, D. 2007, "Industr ialisation of the sof twaresector", Wirtschaftsinformatik, vol. 49, no. 1, pp. 62-71.

Kobitzsch, W., R ombach, D. &F eldmann,R .L. 2001, "Outsourcing in India [sof twaredevelopment]", Software, IEEE, vol. 18, no. 2, pp. 78-86.

Madey, G., F reeh, V. & Tynan,R . 2005, "Modeling the F ree/Open Source sof twarecommunity: A quantitative investigation", Free/Open Source Software

Development, , pp. 203-221.

Maidl, J. 2005, "Spannungsfeld zwischen Standard und Prozessfhrerschaf t - Sof tware-Industr ialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 281-283.

Maurer, F . 1996, "Work ing Group repor t on Computer Suppor t 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 sof tware engineer ing", IEEE Computer,vol. 39, no. 1, pp. 121-124.

Mockus, A.,F ielding, R . & Herbsleb, J.D. 2002, "Two case studies of open sourcesof tware development: Apache andMozilla", ACM Transactions on Software

Engineering and Methodology, vol. 11, no. 3, pp. 309-346.

Paasivaara,M. & Iassenius, C. 2004, "Using Interactive and Incremental ProcessesinGlobal Sof tware Development", Proc. ICSE 3rd Int'l Workshop Global Software

Development IEEECS Press, , pp. 42.

R ao, M.T., Ear ls, T.W. & Sanchez, G. 2007, "International Collaboration inTransor ganizational Systems Development: The Challenges of Global Insourcing", Journal of global information technology management, vol. 10, no.3, pp. 52.

R obbins, J. 2005, "F ree/Open Source Processes and Tools, chapter Adopting OpenSource Sof tware Engineer ing (OSSE) Practices by Adopting OSSE Tools", , pp.245-264.


33/35

R odr iguez, F ., Geisser, M., Berk ling, K. & Hildenbrand, T. 2007, "Evaluating Collaboration Platforms for Offshore Sof tware Development Scenar ios", L ecturenotes in computer science, vol. 4716, pp. 96.

R oyce, W.W. Managing the development of large software systems: concepts and techniques , IEEEComputer Society Press,Monterey, California, United States1987, .

Scacchi, W. 2007, "F ree/open source sof tware development: recent research results andmethods", Advances in Computers: Architectural Advances, vol. 69, pp. 243.

Scacchi, W. 2006, "Understanding Open Source Sof tware Evolution", Software Evolution and Feedback, Theory and Practice, , pp. 181-206.

Scacchi, W. 2004, "F ree/open source development practices in the computer gameindustry", Software, IEEE, vol. 20, pp. 59-67.

Scacchi, W. 2002, "Understanding the requirements for developing open sourcesof twaresystems", IEE Proceedings-Software, vol. 149, no. 1, pp. 24-39.

Schach, S.R ., Jin, B., Wr ight, D.R ., Heller, G.Z. & Offutt, A.J. 2002, "Maintainabilityof the Linux kernel", IEE Proceedings-Software, vol. 149, no. 1, pp. 18-23.

Schwaber, K. &Beedle, M. 2001, Agile Software Development with Scrum, PrenticeHall PTR , Upper Saddle River, NJ, USA.

Sommerville, I., 2007,Software engineering, Addison-Wesley, Har low, England; NewYork.

Stroustrup, B. 1986, "TheC programming language", Addison-Wesley Series inComputer Science, .

Taubner, D. 2005, "Sof tware Industr ialisierung", Informatik-Spektrum, vol. 28, no. 4, pp. 292-295.

Teasley, S.D., Covi, L.A., Kr ishnan,M.S. & Olson, J.S. 2002, "R apid sof twaredevelopment 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, "Sof tware engineer ing" in Open sources: Voices from the open source

revolution , eds. C. DiBona, S. Ockman &M. Stone, O'R eilly & Associates, Inc.Sebastopol, CA, USA, pp. 91-100.

Walz, D.B., Elam, J.J. &Cur tis, B. 1993, "Inside a sof tware design team: knowledgeacquisition, shar ing, and integration", Commun.ACM, vol. 36, no. 10, pp. 63-77.


34/35

Webster, M. 2003, "An end-user view of the collaborative sof tware development market", Market Research Report, IDC 30608, vol. 1.

Weiss, M., Moroiu, G. & Zhao, P. 2006, "Evolution of open source communities" inOpen Source Systems, IFIP Spr inger, , pp. 21-32.

Williams, L. &Cockburn, A. 2003, "Agile sof tware development: it's about feedback and change", IEEE Computer, vol. 36, no. 6, pp. 39-43.

Williams, L., Kessler, R .R ., Cunningham, W. & Jeffr ies, R . 2000, "Strengthening theCase for Pair Programming", Software, IEEE, , pp. 19-25.

Ye, Y., Nakakoji, K. & Yamamoto, Y. 2007, "R educing the Cost of Communicationand Coordination in Distr i buted Sof tware Development" in Software

Engineering Approaches for Offshore and Outsources Development Spr inger, , pp. 152-169.

Zwahr, A. 2006, "Brockhaus Enzyk lopdie in 30 Bnden", vol. 13.


35/35

Eidesstattl ich e Erklrung

Ich versichere, dass ich meine Di plomarbeit ohne Hilfe Dr itter und ohne Benutzung

anderer als der angegebenen Quellen und Hilfsmittel angefer tigt und die den benutztenQuellen wr tlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht

habe. Diese Arbeit hat in gleicher oder hnlicher F orm noch keiner Prfungsbehrde

vor gelegen.

Mannheim, den 12.May 2011

Lorenz Har tmann

Documents

Seminar Paper by Lorenz Hartmann