seminar paper by lorenz hartmann
Post on 08-Apr-2018
215 Views
Preview:
TRANSCRIPT
-
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
6/35
Keywords
Industr iali ation of sof tware development
Global sof tware development Collaborative sof tware development platforms
Agile development
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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/6/2019 Seminar Paper by Lorenz Hartmann
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)
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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)
-
8/6/2019 Seminar Paper by Lorenz Hartmann
10/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. 4
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)
-
8/6/2019 Seminar Paper by Lorenz Hartmann
11/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. 5
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 (
-
8/6/2019 Seminar Paper by Lorenz Hartmann
12/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. 6
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
13/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. 7
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
14/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. 8
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
15/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. 9
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
16/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. 10
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
17/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. 11
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
18/35
-
8/6/2019 Seminar Paper by Lorenz Hartmann
19/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. 13
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
20/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. 14
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
21/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. 15
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
22/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. 16
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
23/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. 17
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).
-
8/6/2019 Seminar Paper by Lorenz Hartmann
24/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. 18
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
25/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. 19
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)
-
8/6/2019 Seminar Paper by Lorenz Hartmann
26/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. 20
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,
-
8/6/2019 Seminar Paper by Lorenz Hartmann
27/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. 21
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
28/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. 22
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
29/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. 23
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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.
-
8/6/2019 Seminar Paper by Lorenz Hartmann
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
top related