TEACHING GLOBAL SOFTWARE ENGINEERING ANDINTERNATIONAL PROJECT MANAGEMENT

Experiences and Lessons Learned from Four Academic Projects

Florian Matthes, Christian Neubert, Christopher SchulzTU Munchen, I19, Boltzmannstr. 3, D-85748 Garching

{matthes,neubert,schulzc}@in.tum.de

Christian LescherTU Munchen, I1, Boltzmannstr. 3, D-85748 Garching

lescher@in.tum.de

Jose ContrerasUniversidad Tecnica Federico Santa Maria, Avenida Espana 1680 Casillo 110-V Valparaıso, Chile

jose.contreras@usm.cl

Robert Laurini, Beatrice RumplerINSA de Lyon, 7 avenue Capelle, F-69621 Villeurbanne{robert.laurini,beatrice.rumpler}@insa-lyon.fr

David SolTecnologico de Monterrey, campus Puebla Vıa Atlixcayotl 2301, 72800 San Andres Cholula

dsol@itesm.mx

Kai WarendorfHochschule Esslingen University of Applied Sciences, Flandernstr. 101, 73732 Esslingen

kai.warendorf@hs-esslingen.de

Keywords: Global software engineering, software project management, education approach, experience report, interna-tional project management

Abstract: As part of the ongoing globalization process, software is no longer developed by a sole enterprise which isbased at one single location only. In turn, distributed engineering teams are continuously modifying softwareby bringing in their local knowledge and country-specific expertise. Due to this cooperation on a global-scale, today’s software engineers require distinct skills and capabilities allowing them to face a paradigmcalled Global Software Engineering (GSE). However, regarding today’s universities curricula, the teachingof GSE can be seen as an emerging discipline which is increasingly gaining attention. This paper depicts theprogression and lessons learned from four different globally distributed software engineering projects executedby late bachelor and master students from five different universities. In doing so, the article facilitates futureGSE endeavors in academia and industry.

1 Introduction and background

Many technological, organizational, and economicfactors have led to the increased globalization of de-velopment projects (Sangwan et al., 2006). Driversfor Global Software Engineering (GSE) include costcompetitiveness, access to talent regardless of loca-tion, the need for a globalized presence, as well asmergers and acquisitions (Carmel, 1999). Globally-

distributed projects are rapidly becoming the normfor large software systems (Herbsleb, 2007). Thereby,GSE imposes new challenges on software engineers,in which coordination over distance (Damian et al.,2010; Herbsleb, 2007; Lescher et al., 2007) can beconsidered as one of the major ones. In this respect,there is a strong need for educating and training ITemployees to act jointly in an international context.Not only those software engineers are geographical

separated from each other by working at multiplelocations on interdepending modules, they are alsosubject to cultural differences including national cul-ture, native language, as well as organizational cul-ture (Carmel, 1999; Hofstede and Hofstede, 2004).In this regard, technical expertise and know-how areessential but the ability to collaborate effectively inglobally distributed teams is equally important (Gotelet al., 2009).

When considering the personal requirements today’ssoftware engineers are facing in their daily work life,it is surprising to see that teaching GSE at universitiesis still in its infancy. Besides its recent occurrence andemerging importance in industry, the sparse offeringof teaching GSE in academia maybe caused by theadditional coordination work hosting institutions haveto cope with when organizing such types of courses.Furthermore, different semester schedules combinedwith an unequal grading and evaluation schemes com-plicate the cooperation among global distributed uni-versities. In the light of aforementioned situation,five chairs of five different universities speaking threedifferent languages conjointly organized a practicalcourse during the winter semester 2009/10, namely:

∙ Institute National des Sciences Appliquees deLyon (INSA) in France

∙ Tecnologico de Monterrey campus Puebla (TEC)in Mexico

∙ Technische Universitat Munchen (TUM) inGermany

∙ Universidad Tecnica Federico Santa Maria (USM)in Chile

∙ University of Applied Sciences Esslingen (UE) inGermany

Coined by the name Network of Engineering univer-sities Educating in Intercultural Design (NEREID)in July 2008, the cooperative course aimed at teach-ing students how to work on software engineeringprojects given a globally distributed team.

Originally, the NEREID course was launched by Prof.Robert Laurini in the Information Technology depart-ment of Institute National des Sciences Appliquees deLyon (INSA). Considering the typical syllabus of themaster computer science graduates of INSA de Lyonsix students work conjointly on six projects during agiven time frame of one year. In this vein, each stu-dent has to take on the role of the project lead, fol-lowing the thought that an expert in computer sciencemust not only be a good programmer, but moreoverhas to obtain distinctive skills in project management,especially for the design and coding of huge software

products. However, the main limitation is that lo-cal students possess the same culture, apply similarmethodologies, and speak identical languages. Re-garding the future work of those students, they willmuch likely be in contact with colleagues having dif-ferent cultures, speaking different languages, as wellas mastering different methodologies.

Since INSA de Lyon regards international project ex-perience as a key aspect of each student’s curricu-lum1, in fall 2007 the idea came up to organizecross-country projects, in which students from differ-ent countries would have to work conjointly on oneproject. Thereupon, Prof. Robert Laurini and his col-leagues contacted several international universities in2008. With regards to participation constraints, therelationships between students within a project teamhad to be on the same level, i.e. each software engi-neering task could be assigned to each student. Ad-ditionally, the time schedule of both institutions hadto be congruent. Although, the contacted institutionsconsidered student exchange as being of the utmostimportance, they either denied the proposal or couldnot meet the criteria. As for the reasons stated, eitherproject management was not their priority, time pe-riod and duration were not relevant, or project man-agement was a priority, but organization could notcomply.

In July 2008, Prof. Robert Laurini was invited to theTEC were the colleagues of the Mexican chair wereimmediately enthusiastic about his project ideas. Asa fruitful consequence, one student project topic wasselected, and two groups of France-Mexican studentswere organized in order to work together from au-tumn to winter 2008. The subject consisted in thecreation of a small information system for a tourismoffice based on Google mash-ups. As a follow up ofthis experimentation, a first post-mortem report wascompiled (Laurini and Sol., 2009), analyzing the dif-ferent aspects encountered during the project execu-tion in an international context. In addition, the twopartners jointly decided to extend the NEREID coursein terms of academic partners and number of studentprojects facing the upcoming year 2009.

In this paper, we now document and reflect the ex-periences when teaching GSE during the winter term2009/10. In detail, we describe the general approachbeing taken by the five universities as well as the stu-dents including roles and deliverables (Section 2), the

1Institute National des Sciences Appliquees de Lyon(INSA) is a very international-oriented institution withmore than 25% of its students being from foreign countries.Moreover, 75% of INSA de Lyon students are spending oneor two semesters abroad.

final outcome and experience students made withinthree projects (Section 3), and the experience as wellas lessons learned from a teaching staff’s perspective(Section 4). In doing so, our results are grounded inthe experience we as the teachers made when inter-acting with the participants as well as in the informa-tion we gained when conducting four semi-structuredinterviews with students involved in projects Tech-nische Universitat Munchen (TUM) were tutoring.Having taught GSE to 43 students organized in ninedifferent software teams during a time span of 4months, our main goal is to inspire the reader howto teach GSE in an academic context. More precisely,we attempt to help teaching staff to plan, implement,and guide software engineering projects realized byglobally distributed teams who are compelled to usea communication language other than their mothertongue.

2 An approach to teach globalsoftware engineering

This section delineates the approach which was ap-plied when carrying out the NEREID course. It orig-inates from the first cooperation between France andMexico in 2008 and was refined before the second it-eration of the course started in October 2010. Fig-ure 1 illustrates the main phases and their duration bydistinguishing between course preparation, execution,and post processing stage. Since the NEREID coop-eration involved universities’ teaching staff equallyto students, a differentiation between both groupsis made through the two gray horizontally alignedrounded rectangles. In the following, each phase’smain activities are explained.

2.1 Introduce & coordinate

The preliminary phase consisted of two main activi-ties: first of all, the participating universities had to beselected. Afterwards, those members agreed on howto put the NEREID course into practice during a kick-off meeting. Since NEREID initially was launched byProf. Robert Laurini from INSA de Lyon the acquisi-tion and the selection of the participating universitieswere managed by him and his colleagues. In June2009, he announced that the members for the win-ter semester 2009/10 consisted of the five institutions(cf. Section 1). After the participants had been identi-fied, a kick-off meeting was summoned. Date, meansof communication, and the agenda of this initial meet-

ing were mainly arranged through e-mail exchange.As communication device, an IP-videotelephony sys-tem was used being available at all universities. Thetwo-hour meeting was held in English, the professorsand all respective research assistants were participat-ing. Main purpose was to get to know all membersand to discuss the boundary conditions for the seconditeration of NEREID course. In addition, mutual trustand rapport was build on a teaching staff level.

The overall course goal was to allow student teamsto work conjointly on distinct software engineeringprojects in order to improve their project managementand communication skills taking differences in geo-graphical location, academic curriculum, and cultureinto account. Less focus was put on technical experi-ence and tooling skills students would gain throughthe implementation of the assigned projects. Allacademic institutions agreed that participating stu-dents would start without any introductory lectures.Hence, no specific project management and coopera-tion methods or models were taught in beforehand.

It was up to each single member to fit the course in theindividual degree program and grading scheme. Forinstance, each institution independently determinedthe type of the course (e.g. seminar, internship), thecredit points which could be achieved (e.g. four creditpoints regarding the European Credit Transfer Sys-tem ECTS), as well as the experience and knowledgerepresenting prerequisites for a participation in thecourse (e.g. attended software engineering lecture,language classes, project management).

All members settled on that the student teams had toconsist of 4-6 students who were enrolled in computerscience and business informatics at their accordinguniversity. The set of team participants had to origi-nate from 2-3 nations differing in their first languageswhich made communication in a foreign language in-evitable. In terms of workload, ten hours per weekwere estimated by the members, hence 100-120 hourswould be accumulated by each student taking threemonth project time as a basis. The universities agreedthat each individual project topic was addressed byone student team only.

Due to its world-wide acceptance in terms of writ-ten and spoken communication, English was cho-sen as the official project language, for both the or-ganizing members as well as the participating stu-dents. Since none of the members came from an An-glophobe country, each participant was equally chal-lenged in speaking a foreign language. Regardingcommunication devices, no explicit directives werestated in advance. This allowed the teaching staff and

Stu

de

nts

Univ

ers

itie

s

© sebis 1

Introduce &

coordinate

Define

projects

Finalize

preparation

Guide &

assess

Evaluate

results

Conduct

project

Two weeks Two weeks Two weeks

Preparation

(six weeks)

Execution

(three month)

Post processing

(two weeks)

Three month Two weeks

Reflect

course

Select

project

Figure 1: NEREID course execution stages

students to take advantage of a broad lineup of com-munication devices ranging from simple e-mail andphone calls to more sophisticated video and web con-ference solutions.

Regarding the different project roles following dis-tinctions were made 2:

Project sponsor: Initiated the project by proposing aspecific topic one student team would work on. Dur-ing the execution, the sponsor played the role of alocal or remote business customer, hence formulatedfunctional and non-functional requirements consider-ing the software engineering product. He or she wasalso in charge of validating the final outcome from acustomer perspective. In most cases the role of thesponsor was filled by a professor of the participatingacademic institutions. If local students were involvedin the fulfillment of the project, the sponsor could si-multaneously act as the supervising tutor.

Supervising tutor: Once students enrolled in a soft-ware engineering project, they were automatically as-signed to at least one local supervising tutor who wasappointed by each university in beforehand. The tu-tor’s role was to assist the students not only for tech-nical issues with regards to the results and the com-munication means, but also help them to overcomeorganizational obstacles. Even if the local supervis-ing tutor often did not know the desired project out-come in detail, he or she was able to provide help-ful support considering general project managementtechniques as well as the concerned deliverables. Inaddition to escalate objections raised by the local stu-dents to other tutors or to the project sponsor, the localsupervising tutor was also responsible of evaluating

2The term local refers to roles whose assigned personsare working at the same place, hence may have physicalcontact to each other. For instance, for a student the localsupervising tutor represents the tutor who is available on-site, thus at the same institution. In the contrary, remotesignifies that the person playing a specific role can be onlycommunicated to by using telecommunication equipment.

the students he was looking after.

Student project lead: Directly at the start of eachproject, all student teams had to appoint one projectlead who was responsible for classical project man-agement tasks. In particular, he or she organizedthe internal team and external presentation meet-ings, assigned different project activities to the teammembers, and kept track of the overall project goalsachievement. Furthermore, the student project leadrepresented the single point of contact to the projectsponsor by being in regular discussion with regardsto the system’s functional and non-functional require-ments. Steering the team through the course of theproject in addition to interacting with the customer,made the lead a pivotal but also a tough role.

Student project member: As mentioned, every stu-dent team consisted of 4-6 students who conjointlyworked on the software project. The individual stu-dent role within this team was determined internallyby each group regardless of the project sponsor andsupervising tutor. The spectrum of duties ranged fromquality, design, testing, communication, etc. tasksand was mostly contingent on the experience andknow-how the respective student could contribute.Each student was assigned to a local supervising tutorwho could aid with the project work and approved thestudent’s overall performance expressed in participa-tion and deliverables.

Another item discussed by the members consisted ina common web page (NEREID-Page, ) enabled bya Wiki (infoAsset, ) in order to generate a form ofcorporate feeling. Besides a presentation of all par-ticipating universities, this site also contained a shortdescription of each student project. For further infor-mation considering a specific project, every memberwas in charge of providing details on their local website. It was also intended that the common Wiki wouldserve as registration platform where students couldexpress their interest in a certain project while sharing

their main contact information. In this vein, the Wikiwould facilitate composition and initial contact of theteam in advance. Finally, all members were asked tocontribute at least one relevant software engineeringproject during a time frame of two weeks. After thisphase, a synchronization meeting was scheduled byapplying IP-videotelephony again.

Regarding the output, the members decided on sub-sequent software development artifacts every studentteam had to provide during the individual project.Each deliverable had to be written and presented inEnglish language, all students were urged to con-tribute equally to the final outcome. The results weresubmitted to the local tutor, who either reviewed themin case of a document or attended them as for oral pre-sentations. With respect to the deliverables, all stu-dent teams had to provide the following items:

Initial presentation: During a period of 10 minutes,each team presented the general project content in ad-dition to a project plan and anticipated risks. After-wards, a 5 minutes question & answer section washeld allowing the audience and speakers to discuss.

Final presentation: Students had 10 minutes topresent their project as well as the lessons learned. 5minutes were reserved for a short live demonstrationof the main results complemented by another discus-sion round.

Final report: In the end, each student team wasobliged to compile a report composed of approxi-mately 10-15 pages. The document summarized theirproblem and context, the approach which was taken,lessons learned, as well as possible future work. Onthe one hand, the report served as a specification bydelineating the solution which was implemented bythe students. On the other hand, it also contained per-sonal experience and suggestions for developing soft-ware in international teams.

In terms of the initial and final presentation, localtalks only including the students of the tutoring uni-versity were preferred by the supervising tutors aswell as the respective project team members. Thiswas mainly caused by organizational and technicalissues, i.e. time differences coupled with problemsconsidering video communication making it difficultto gather all stakeholders working on the specificproject.

2.2 Define projects

Main activity in this phase was to propose and to de-cide on the different project topics based on the agree-

ments and general project conditions elaborated dur-ing the kick-off meeting. Thereby, all topics were re-stricted to software engineering tasks related to thecurrent research focus of the universities by targetingat late bachelor and master students. The complex-ity of the projects where adequately adjusted, bear-ing in mind the time constraint of three months allstudent teams were exposed to. In case of the spe-cific work packages, all proposals consisted of theimplementation or enhancement of a software sys-tem, however there was no overlapping in terms ofspecific project content. The respective sponsor com-posed a general project description in addition to arequirement specification containing must as well asnice-to-have requirements serving as a foundation forthe teams. Concluding, the project descriptions werepublished in the Wiki and a second synchronizationmeeting among the universities was scheduled.

2.3 Finalize preparation

Main goal of the synchronization meeting as part ofthe finalization phase was the presentation of the fi-nal project topics in addition to their start and enddates. In mid-September 2009, a IP-videotelephonysystem was set up as means of communication allow-ing all universities to participate. Due to the differ-ent semester schedules, the members decided to startthe projects independently from each other. Hence,once enough students were registered for a specificproject matching the criteria agreed upon in the pre-liminary phase, the team could get down to business.For the registration process, students were asked tomake use of the project specific Wiki page. Further-more, e-mails between the teaching staff were ex-changed since not all universities took advantage ofthe Wiki.

In addition to above mentioned activities, prelimi-nary discussions were hosted at the particular uni-versities addressing students who were interested inthe NEREID project. The 30 minutes meeting tookplace at the beginning of the semester and provideda quick rundown of the course. Besides the generalcourse of action and required deliverables, the differ-ent software engineering projects were presented. Af-ter the audience got familiar with the multiple topicsand related questions were answered on the part of theteachers, a first allocation of students to the projectswas carried out. In this process, students had the free-dom to select the topic of their choice.

2.4 Guide & assess

When the preparation phase was finished at the endof September 2009, universities could pass over tosupervise the different projects which were now ex-ecuted by the student teams. Since students did notattend any preparative lecture sessions in advance,strong support by the supervising tutors as well as aclose cooperation with the project sponsor were in-dispensable throughout the project’s implementationphase. As depicted in Figure 2, universities undertookthe execution of three parallel activities all serving toguide and assess the different student teams.

An initial kick-off meeting was held by the projectsponsor which was destined for all student team mem-bers and targeted at building trust as well as rap-port among the participants. During this meeting, thesponsor presented a more detailed project descriptionincluding the overall context, a technical description(e.g. specification, architecture, technology) in addi-tion to further organizational information (e.g. linksto the website, e-mail addresses). The main activitiesof this phase were instantiated in the following man-ner:

Evaluate results: Each software engineering arti-fact delivered by a student team was assessed by tak-ing advantage of a simple excel spreadsheet. In thissheet, supervising tutors made note of strong pointsand flaws considering the specific deliverable as wellas the way latter was presented also by distinguish-ing between the different team members. Thereby,the evaluation of the final report was part of the postprocessing stage. Besides, a continuous assessmentbased on student-tutor interaction took place. Theoverall assessment of the student teams also includesan evaluation of the source code (quality of the im-plementation, functional test) and recommendationsof the partner universities. A second activity of thisphase consisted in the evaluation of the overall course.In addition to the feedback given by the local studentsall members of the participating universities sharedtheir experience and lessons learned within a 60 min-utes long final video-telephony session.

Tutoring and organize: Supervising tutors not onlyprovided technical help in introducing and explain-ing different software engineering technologies to thestudent teams, they also made recommendations withrespect to organizational issues and deliverables. Forinstance, this comprised suggestions for presentationand final report structure, hints regarding escalationpaths in case of team-internal problems, and resolv-ing of project holdups which could originate from a

lack of team coherence.

Define and validate system requirements: Af-ter presenting the project topic during the kick-offmeeting, the project sponsor monitored the overallprogress with regards to the afore specified require-ments and constraints. In doing so, the sponsoralso validated the deliverables and checked the sourcecode against the initial demands. Furthermore, ques-tions were clarified raised by the students consideringthe system.

2.5 Conduct project

After the organizational preparation was performedby the universities, the students were able to tackletheir specific software engineering project within thegiven time frame of three months. The executionphase (Figure 2) was subdivided into four distinct ac-tivities. Final outcome of each activity was the deliv-erable as mentioned above.

Prepare: Right after the projects have been assigned,the student teams started to get familiar with the otherteam members as well as the overall project topicand constraints. Furthermore, they defined the inter-nal project organization including roles and respon-sibilities, set up a project plan, and identified workpackages. Afterwards they distributed these packagesamong the members and prepared the initial presenta-tion representing the first deliverable, which was dis-cussed together with the local supervising tutors dur-ing the initial talk.

Design & implement: In the core working phasethe student teams had a total of seven weeks for sys-tem design and implementation. Besides, other soft-ware engineering tasks e.g. testing, documentationas described in (Rausch and Broy, 2008) were exe-cuted. Each team proposed a system design basedon the project sponsor’s requirements complementedby the results of the initial presentation. This designwas discussed and double-checked during the syn-chronization meeting (cf. Subsection 2.1) in the pres-ence of the local supervising tutors. After the designwas approved, students independently implementedthe working packages and integrated them in a sub-sequent step. After the test cases were carried out, theoverall results were incorporated in the final presenta-tion which was held at the end of the implementationphase.

Compose & summarize: Finally, a time frame ofthree weeks was scheduled enabling the student teamsto write their final report. In order to facilitate the

Stu

de

nts

Un

ive

rsitie

s

Initial

presentationSynchronization

presentation

Final ReportFinal

presentation

Kick off presentation

Prepare

Advise & organize

Define & validate system requirements

Evaluate

Two weeks Three weeks Four weeks Three weeks

Design ImplementCompose &

summarize

Evaluation I Evaluation III

EvaluateEvaluate

Evaluation II

Execution

(three month)

Figure 2: Execution stage details

writing and enhance the quality of the deliverables,students had the possibility to send in their intermedi-ate report. This draft was reviewed by the local tutorand potential suggestions for improvement were com-monly discussed during a short meeting at the chair.After the final version of the report was submitted, thestudents received their final grade based on the evalu-ation criteria as explained in Subsection 2.4.

2.6 Reflect course

To improve the quality of future courses the 43 stu-dents could voluntarily provide feedback during 20minutes long interview sessions together with the lo-cal supervising tutors.

3 The student projects

In the following, we describe three selected studentprojects conducted in the NEREID course. To capturethe experiences and lessons learned, we carried outsemi-structured interviews with the students teamsfrom TUM, after the projects were completed andevaluated. Hence, the statements in this Section re-flect the perspective of the student teams and the col-laboration between them.

3.1 Project 1: University foreignrelations map

Project 1 aimed at developing a web application tographically display partner university relationships.The application should make it easier for students

to find partner universities and compare possible ex-change partners. The scope included displaying anuniversity relations map as an overview of partneruniversities, basic administration capabilities to edituniversity relationship data as well as provisioning ofan online forum for communication between studentsand uploading experience reports.

The project team consisted of students of three siteswith two students from each location: INSA deLyon, TUM, and UE. The latter was the initiator ofthe project thus also the site of the project sponsor.Project 1 had a student project lead from the projectsponsor site who was appointed already before theproject was started and had a close contact to theproject sponsor. The worksplit was defined by thelead, the development tasks were separated by subsys-tems: The responsibility for the web page was at UE,the online forum was assigned to INSA de Lyon andthe database development was the task of the team atTUM. The requirements for the project were providedby the project sponsor at UE. All communication withthe project sponsor was handled by the project lead atUE; there was no direct communication between theteam at TUM and the project sponsor. For projectcommunication, weekly phone calls were scheduled,however, due to different reasons, the project teamwas never fully present at these meetings. Later, e-mail communication was used instead. The team atTUM experienced long delays to receive an answer toe-mails – sometimes up to one week. Another issueof distribution was the access to the web server at UE,as the team at TUM developing the database had nodirect access to the server and always needed to go viathe team in UE.

A major problem occurred with the INSA de Lyonstudent site, which was responsible for the online fo-rum. According to the TUM, there was low involve-

ment from the INSA de Lyon team and they weremost of the time arguing why they cannot proceed.The TUM team kept sending e-mails to the projectlead and asked for an escalation. However, the prob-lem was not solved. At the very end of the project,the INSA de Lyon team posted rudimentary code foran online forum as their contribution, but it was notintegrated with the overall system and therefore notusable. The TUM student team felt annoyed abouttheir student colleagues at INSA de Lyon.

The student team at TUM reported in the interviewthat they saw there were different motivations of thesites involved. In particular the team at UE treated theproject lightly. When there were discussions aboutproblems with the project lead, he referred to clari-fying all issues with his professor in a personal andinformal way. According to the TUM team, there wasno formal final presentation at UE, but only an infor-mal meeting with the professor, and the project reportof the TUM team was used instead of writing an ownreport.

3.2 Project 2: Picture-based itineraries

Task of project 2 was to develop a picture-based nav-igation system for pedestrians. While existing navi-gation systems usually use street names and a map toexplain the route, many pedestrian ways do not havenames. Therefore the goal of this project was to createa system which uses pictures augmented with arrowsto explain the route, e.g. view of a crossroad whereone needs to turn left.

The project team involved students from three sitesin three countries – INSA de Lyon, TUM, and USM– with two students at each site 3. The supervisingprofessor of the INSA de Lyon site was in the role ofthe project sponsor. The student team felt there was agreat latitude with respect to the requirements, as onlyhigh level requirements were given. The students or-ganized weekly meetings to exchange on the currentstatus and to make upcoming decisions. The teamsplit their work according to subsystems to minimizethe need for communication: the server part was takenby the INSA de Lyon team, the client part was chosenby the TUM team, and the navigation arrows were as-signed to the USM team. In contrast to project 1, thisproject had no explicitly appointed student project

3A second team consisting of students from INSA deLyon and TEC has been working on the same project. How-ever, only the interview statements of the team in whichstudents from the TUM were involved are reflected in thisarticle

lead. While a student from the INSA de Lyon teamsuggested himself in his first e-mail as project lead,the TUM team answered the decision should be de-ferred to the first meeting, where the team membersget introduced to each other. Later at the meeting,no decision was taken. As the project task originatedfrom INSA de Lyon, they gave an overview of thehigh level requirements during the first meeting. Asmany aspects of the task were still underspecified, theINSA de Lyon team took over the responsibility tofurther clarify the requirements and provide a specifi-cation.

Communication was arranged in weekly meetingsand exchange of e-mails. While the first meetings hadno pre-defined agenda, the meetings became morestructured over time. Chat was used as communi-cation medium as the available network bandwidthwas not sufficient for voice-over-IP or video commu-nication. The team reported that they made good ex-periences using this mean, as it allowed for a well-regulated communication.

From the beginning of the project, there were prob-lems in the cooperation with the team in USM. Thestudents from USM did not attend the first meeting,as they “totally forgot the meeting date”. This leadto additional effort, as the information provided andthe decisions made needed to be re-discussed with theUSM team. The TUM team did not escalate the prob-lem in order not to squeal on their colleagues, onlysome e-mails were exchanged within the team. Therewas no contribution from the USM team visible untiltwo days before the final presentation: A code deliv-ery was provided on December 20th, which was notintegrated and therefore not working at the final pre-sentation. Also there were problems with the timesynchronization between the three locations. Whilethe TUM team had to give its final presentation anddemonstration of the system on December 22nd, theINSA de Lyon team went already on holiday fromDecember 19th, so it nearly happened that the serverneeded for the demonstration was not available. For-tunately, the INSA de Lyon team could run the serverduring their holiday from the students’ hall of resi-dence.

3.3 Project 3: Cadaster System

Project 3 focused on developing a system which usesgeographical data of the cadaster system of Puebla(Mexico) to map articles to specific geographic loca-tions. Users should be able to visualize, create andmodify articles related to a specific reference point on

the map.

In the project team were three students from TEC, twofrom INSA de Lyon and one student from TUM. Thetopic was defined by the supervising professor fromTEC who acted as project sponsor. A high level re-quirements specification was already existent at theproject beginning. Project 3 had a student project leadfrom TEC who was designated before the project ac-tually started. The team members jointly organizedthe distribution of work. They decided to have a func-tional worksplit across locations: One member of theINSA de Lyon team was responsible for organizingmeetings (e.g. invitation and agenda) and the docu-mentation (e.g. meeting minutes). TEC was account-able for the conversation and clarifications with re-spect to the requirements. The student from TUMtook over the role of the technical implementationand integration as lead developer. Thereby, each sitewas in charge for a part of the system. Furthermore,for each location the team defined one so-called teammanager who acted as the single point of contact incase of problems or bug reports with the part of thesystem, for which the site was responsible. The teamhad weekly meetings, including both one video con-ference meeting for organizational issues and statusreports and one chat for technical clarifications. Asand when required, the frequency of meetings was in-creased. The supervising professor from TEC whowas in the project sponsor role occasionally partici-pated in the video conferences. Overall the collabora-tion went well, although it was noticed that there arecultural differences between the countries: the teamin TEC was perceived to be more relaxed, while thestudent colleagues at INSA de Lyon sometimes ex-pressed their concerns when progress was not as fastas they wanted. The team had to bear the time dif-ference in mind, which was 7 hours, but it was nota serious problem as there was a sufficient overlapin work time of Mexico and Europe and they couldagree on time slots for the meetings, where all siteswere available. Sometimes it was challenging to finda date for the video conference, as it was difficult forboth the INSA de Lyon and the TEC team to get avideo conference room due to limited resources. Onemajor issue occurred with respect to understandingof the requirements: The Europeans and the Mexicanstudents had different imaginations of a cadaster sys-tem: While the students at INSA de Lyon and TUMassumed that they need to implement a cadaster sys-tem with legal registers – as known in Europe –, theMexican expected to build a system with a simple ge-ographical map. As the team members detected thatthey have different domain knowledge, they were ableto resolve this issue.

3.4 Experience and feedback

Altogether, the problems encountered by the teamsvery well reflect real-life issues, in particular commu-nication problems as well as technical, organizational,and people aspects (Lescher et al., 2009). Due tothe geographic and organizational separation, the stu-dents perceived themselves being in local sub-teamsinstead of one global team. In critical situations thisresulted in a characteristic “us” versus “them” atti-tude. However, all of the NEREID projects were fi-nally able to present good results and made an impor-tant learning experience. Being asked for their lessonslearned and their feedback towards the seminar, thestudents mentioned the following points:

Separation by subsystems: The modular architec-ture and separation by subsystems has proven well,as it reduces complexity and communication neededacross sites. Project tasks should be defined in such away, that a modular separation is possible.

Harmonize deliverables and schedule: It was sug-gested by the students to better harmonize the deliv-erables and the schedule of the projects. In particu-lar, the dates and the format for the final presentationand the final report along with the evaluation crite-ria should be established in an unique way for all in-volved locations.

Joint kick-off meeting: The students suggested tohave a joint kick-off meeting with all involved sitesand also with the project sponsor in the role of thecustomer. Actually, the sponsor was only availableduring the final presentation. It would improve un-derstanding and morale, if this customer contact couldhappen already at the kick-off meeting. Instead of akick-off meeting at the very beginning of the project,this could be also organized as a milestone meetingafter 1-2 weeks of the project. This would allow fora more funded clarification of open questions, as thestudents already had the chance to get into the matterof their project.

Escalation path: A clearly defined escalation pathwould help the students to deal with problems whichare outside of their responsibility. The current ex-perience has shown that the students are reluctant torun down their colleagues in front of their supervisingprofessor.

All teams interviewed emphasized that the projectwas a very valuable learning experience for them,those were aspects which “cannot be learned by lis-tening to lectures only.”

4 Lessons learned andrecommendations

This section points out major lessons learned of theuniversities acting in both roles: as supervising tutoras for the three projects presented in Section 3 and asproject sponsor. At the same time, recommendationsfor future GSE courses in academia are provided sub-stantiated by a short explanation.

Generally, we suggest that all universities agree uponthe three presented deliverables. Not only project’sperformance can be compared more easily after ev-ery student team has to deliver the same results, stan-dardized software engineering artifacts also facilitatethe composition of a common time schedule whichcan be followed by the teams irrespective the individ-ual project topic. The time schedule should be readyas early as possible (preferably two months beforesemester start) allowing students to fit in the NEREIDcourse in their other academic activities. Further-more, we consider a joint kick-off meeting includingat least all student team members, the project sponsor,and possibly, all supervising tutors, as being manda-tory in order to eliminate initial difficulties endanger-ing the participants ambition and engagement.

Assigning 4-6 participants in total to a student teaminvolving 2-3 locations in which each location pro-vides exactly two students has been proven to be suc-cessful throughout the four conducted GSE projects.The limited size of the team induces the team mem-bers to equally contribute to the project’s success bysimultaneously giving the tutors the possibility to per-sonally advice and monitor each individual student.While communication overhead and project’s contentcomplexity is reduced for students and supervising tu-tors, the project sponsor only needs to keep track ofa very limited project scope of 4-6 engineers workingfor three months on a prior defined outcome. Regard-ing deviating interests on team and on location level(therefore students from one location pursue a goalwhich differs from the overall team goal) we proposethat all involved sponsors and tutors consistently statethe main objective right at the beginning and com-monly evaluate the entire team performance againstthe actual achievement of this objective.

When it comes to the project content, we recommendto closely link a project sponsor’s focus of researchwith the proposed topic. Not only the professor incharge would be acquainted with the project’s under-lying body of knowledge, the sponsor would also havean increased interest carrying out this project sincelatter’s successful finalization may positively con-

tribute to the chair’s research activities. In addition,either the individual content or the type of the projectshould ensure intensive communication within eachstudent team. For instance, topics requiring a organi-zational divide & conquer phase in order to split upand later on integrate the different work packages aresuitable since they entail communication among theinvolved students. Furthermore, projects with an ex-plicit need for country-specific knowledge and localinformation generate cross-national exchange, too.

Regarding the specific target group, participantsshould be at least in the 5th semester of their com-puter science study program, hence late bachelors andmaster students. On the one hand, those team mem-bers are already familiar with elementary softwaremodeling and design techniques (e.g. UML, EPK,Petri nets, and ER models), on the other hand thoseparticipants were already in contact with functionaland object oriented programming languages almostalways required for the fulfillment of the implemen-tation phase of a project. Being less engaged in thewell-known technical related aspect of a GSE projectwould allow participants to focus on the organiza-tional and communicative part of the course in moredetail.

Nevertheless, we do not deem extensive preparatoryclasses taught before the actual project start as anindispensable necessity. Tying in with the previouspoint, participants have been already taught to workon software problems locally and therefore the in-troductory courses would only convey knowledge re-garding project management with regards to globaldistributed projects. In turn, we propose that a shortbut crisp GSE overview session in advance wouldhelp to make a start more smoothly for all actorsby also saving planning and coordination time forthe students. This session, which could be coupledwith the kick-off meeting during the execution phase,should also address escalation paths in the case ofteam internal and external problems (e.g. definitionof project lead, team internal friction, lack of commu-nication with the sponsor), thus whenever the teamcannot solve the issue autonomously.

Furthermore, we suggest to establish a common eval-uation scheme for all participating universities mak-ing each student’s work transparent, comparable, andtraceable by generating a more objective picture ofthe participant’s performance at the same time. Thisscheme, which could be implemented through a sim-ple electronic spreadsheet with the columns repre-senting the three deliverables and rows depictingthe universities, is exchanged among all supervisingproject tutors after the execution phase is finished.

Nevertheless, we deem important to keep organiza-tional overhead low for the tutors. Hence, completingthe mentioned sheet should not take longer than 10-15minutes for each project team and deliverable.

Not surprisingly, we noticed a higher communica-tion and coordination overhead in comparison to sim-ilar local courses when conducting the different GSEprojects. However, this increased engagement waspaid off by insights in research groups of foreigncountries as well as the international experience wegained ourselves by carrying out those project. Beingin the role of the supervising tutors and the sponsor,we learned how to organize, execute, and coordinatedistributed projects by interacting on a cross-countrylevel with different interest groups. We are satisfiedwith the solid results delivered in the short amount oftime through the students in hoping to prepare themfor upcoming multi-cultural endeavors in the indus-try. We are also confident, that besides academic ex-change programs courses like ERASMUS, NEREIDwill help future software engineers to succeed in anincreasing globalizing work environment. In additionto foreign language mastering, industrial placementin companies located in other countries and studentmobility, we propose and recommend to fully inte-grate GSE and international project management intheir syllabi.

5 Summary and outlook

Presently, graduated software engineers receive ed-ucation in technology and management. Howeverin the arising context of globalization, the interna-tional dimension should be included. In this arti-cle, we presented our experiences gained when offer-ing global software engineering projects to universitystudents. We described the applied approach involv-ing 43 participants at five distributed academic insti-tutions, pointed out three concrete student projectsin detail, and presented the lessons learned and keyrecommendations from the teaching staff and studentperspective. We are confident, that the introduced ap-proach in combination with the suggestions will serveas a solid foundation for similar GSE endeavors atuniversities.

As the NEREID course was seen very successful, wewill re-offer it in upcoming winter semester by takingthe lessons learned into consideration. In particular,the deliverables, the time schedule, and the evalua-tion scheme will be harmonized across all universitiesand a clear escalation path for the students will be set

up. Furthermore, the set of partner universities willbe extended by a South-Korean university. More in-formation on NEREID can be found on our website:

http://wwwmatthes.in.tum.de/wikis/nereid/home

We express our gratitude to all universities takingpart in the NEREID course during the winter term2009/10. We are looking forward to jointly organiz-ing and hosting a second edition of the course nextwinter.

REFERENCES

Carmel, E. (1999). Global Software Teams (High Perfor-mance Cluster Computing). Prentice Hall.

Damian, D., Kwan, I., and Marczak, S. (2010).Requirements-Driven Collaboration : Leveraging theInvisible Relationships Between Requirements andPeople, volume 2010, chapter 3. Springer-Verlag, Hei-delberg, Germany, 1st edition.

Gotel, O., Kulkarni, V., Say, M., Scharff, C., and Sunet-nanta, T. (2009). Quality Indicators on Global Soft-ware Development Projects: Does “Getting to KnowYou” Really Matter? In Proceedings of the IEEE In-ternational Conference on Global Software Engineer-ing (ICGSE’09).

Herbsleb, J. D. (2007). Global Software Engineering: TheFuture of Socio-technical Coordination. In FOSE ’07:2007 Future of Software Engineering, pages 188–198,Washington, DC, USA. IEEE Computer Society.

Hofstede, G. and Hofstede, G. J. (2004). Cultures and Or-ganizations – Software of the Mind: Intercultural Co-operation and Its Importance for Survival. McGraw-Hill.

infoAsset. Website. http://www.infoasset.de; visited onMarch 7th 2010.

Laurini, R. and Sol., D. (2009). Post mortem report, assess-ment of the first experimentation of the nereid inter-national project. page 5. INSA-Lyon, Tec de Monter-rey/Campus de Puebla.

Lescher, C., Herbsleb, J. D., and Bass, M. (2007). Collab-oration in Global Software Projects at Siemens: AnExperience Report. In Proceedings of the IEEE Inter-national Conference on Global Software Engineering(ICGSE’07).

Lescher, C., Herbsleb, J. D., and Bass, M. (2009). ACoordination Risk Analysis Method for Multi-SiteProjects: Experience Report. In Proceedings of theIEEE International Conference on Global SoftwareEngineering (ICGSE’09).

NEREID-Page. Website.http://wwwmatthes.in.tum.de/wikis/nereid/home;visited on March 26th 2010.

Rausch, A. and Broy, M. (2008). Das V-Modell XT : Grund-lagen, Erfahrungen und Werkzeuge. dpunkt.verlag.

Sangwan, R., Mullick, N., and Paulish, D. J. (2006). GlobalSoftware Development Handbook.