Global Software Development Development of a Web Platform for Exchanging Educational Content in a Virtual Team Setting

Global Software Development Development of a web platform for exchanging educational content in a virtual team setting

Soﬁa Lazopoulou, Xiuqing Li, Nikolaj Lund, Bastian Muller,¨ Mikkel Nielsen, Frederik Williams IT-University of Copenhagen Rued Langgaards Vej 7, 2300 Kbh S slaz, xili, nilu, bmue, mibn, fwil @itu.dk { } May 22, 2012

Abstract This paper explains the process of developing a web platform for exchanging educational content. The focus lies on the collaboration and team management, as well as the product itself. During the project, various difﬁculties have been encountered. As a result, we describe the problems that virtual teams might encounter when working on a project of similar nature, and we propose different methods to mitigate or even avoid such difﬁculties in future teamwork. Even though the resulting approach is not perfect and might be of limited use for other development teams, the presented suggestions could have certainly optimized the development process of the project.

Contents

1 Introduction 3

2 Background 4 2.1 Situation ...... 4 2.2 M-Pesa ...... 4 2.3 DRM ...... 5

3 Related work 5

1 4 Method 6 4.1 Workflow ...... 6 4.2 Artifacts ...... 10 4.3 Collaboration ...... 11 4.3.1 Cultural Differences and lack of Common Ground .... 11 4.3.2 Language Difficulties ...... 12 4.3.3 Coordination and communication difficulties ...... 13 4.3.4 Time/Calendar differences and individual schedules .... 14 4.3.5 Difficulties with Collaboration Technologies ...... 15 4.3.6 Motivational Challenges ...... 16 4.3.7 Summary ...... 17

5 Product 18 5.1 Requirements ...... 18 5.2 Overview ...... 19 5.3 User Interface ...... 20 5.4 Integration with M-Pesa ...... 21 5.5 Use Case View ...... 22 5.6 Logical View ...... 24 5.7 Data View ...... 25 5.8 Security View ...... 26 5.8.1 Explicit Authentication ...... 26 5.8.2 DRM ...... 27 5.9 Development View ...... 28 5.10 Summary ...... 28

6 Evaluation 29 6.1 Workﬂow ...... 30 6.1.1 Group organizations provided loose but effective control . 30 6.1.2 Interchanging teams ...... 31 6.1.3 Awareness ...... 31 6.1.4 Experience with virtual meetings ...... 32 6.1.5 Implementation activities ...... 33 6.1.6 Value of artifacts ...... 34 6.2 Product ...... 36 6.2.1 Functionality ...... 36 6.3 Technology ...... 37

7 Discussion 38 7.1 Artifact Efﬁciency ...... 39

2 8 Further Work 41 8.1 Product Improvements ...... 41 8.2 No Collaboration with other Groups ...... 42

9 Conclusion 43

A Appendix 45 A.1 Product Development Iterations ...... 45 A.1.1 Analysis Phase Activities ...... 46 A.1.2 Design Phase Activities ...... 47 A.1.3 Implementation Phase Activities ...... 47 A.2 Organization in Analysis and Design for 1st Iteration ...... 48 A.3 Organization in Implementation for 1st Iteration ...... 49 A.4 Organization in Analysis and Design for 2nd Iteration ...... 50 A.5 Organization in Implementation for 2nd Iteration ...... 51 A.6 Table Listing artifacts ...... 52 A.7 Screen Dumps of Skill and Motivation Sheet ...... 55 A.8 Collaboration Protocol ...... 56 A.9 Code and deployment guide ...... 58 A.10 OpenProj Project plan ...... 60 A.11 Technology Evaluation ...... 61 A.12 Requirements ...... 66 A.13 Use Cases ...... 68 A.14 Meeting Resume Sample ...... 71 A.15 Test Cases ...... 75

1 Introduction

This report describes the collaborative project between IT University of Copen- hagen, Denmark and Strathmore University, Nairobi Kenya. Six graduate students of each university were responsible for implementing an end product and the management of the collaborative effort required to achieve this. The end product is a web platform for exchanging educational contents at a fee. A user is able to register, preview all the authorised content, look for content of a speciﬁc category and search for speciﬁc content. When a user registers, he/she automatically gets a personal virtual money account that should be used in order to pay when downloading content. To load money to this virtual account, the user can transfer money via the M-Pesa payment system1. Registered users are also

1M-Pesa is explained in detail in Section 2.2

3 able to act as content creators, by uploading their own content, setting a price and specifying descriptive tags, that helps users when searching for content. From the given project description and collaborative situation, the following concise definition of the problem at hand was formulated: How can a group of 12 students, with 5 different nationalities, situated in Den- mark and Kenya, effectively develop a web based software system, capable of stor- ing educational content for later browsing and purchasing? This report is structured in the following way. In section 2 the relevant background concepts are described; in section 3 the related work is introduced; in section 4 the method consisting of workflow, artifacts and collaboration is presented; in section 5 the details of the developed product is explained; in section 6 both the workflow and product is evaluated; in section 7 challenges and method improvements are discussed; in section 8 further work is defined, consisting of improvements and a different approach to the collaboration. Finally, the conclusions are drawn in section 9, followed by references and appendices.

2 Background

In this section, a background to the components of the platform, the payment system M-Pesa and the concept of Digital Rights Management is provided.

2.1 Situation The main motivation for the development of such a web platform is the increasing demand in the developing world for educational content and systems to make it easily available and exchangeable. Providing students with such a system, will boost the knowledge sharing between them. For educational content authors, it will decrease the effort required to make their material globally available to students, as access is not limited to organizations. In countries of the developing world, payment via bank transactions or credit cards is less common, as their usage is regarded as a security risk. Instead, mobile payment systems are common and widely available.

2.2 M-Pesa As it should be possible to offer content exchanged on the platform for sale, it needs to be integrated with a payment system of a payment provider. In Kenya, the lead- ing and most established mobile payment system is M-Pesa. Moreover, it is also available in Tanzania, Afghanistan and South Africa. The system is widespread

4 and is commonly used for the purchase of goods, payment of bills and direct transfer between customers. As it is mobile, it requires a mobile phone. However, the application is integrated in the SIM card and works both on low and high-end devices and provides a simple interface for sending and receiving money. The service requires no visit to a bank to perform a transaction and in general it requires no bank account. Instead, customers are able to deposit and withdraw money through licensed agents (e.g., gas stations, shops, etc.). In its nature, it is very similar to the traditionally used bank transfer, instead of payment via credit card. The main difference between the two concepts is that of push and pull transactions. When using credit cards, the customer gives his card details (name, card number, expiration date and veriﬁcation code) to a third-party and allows it to debit money from his account. With M-Pesa and bank transfer, transaction customer sends money to a third-party, it is a push transaction. The advantage of the later scheme is safety, because no details are stored at third-party and can not be stolen.

2.3 DRM DRM (Digital Rights Management) is an umbrella term used for a number of access control technologies which are used by publishers, copyright holders and individuals to limit the use and distribution of digital content after purchase. In most cases, the content is encrypted before distribution by the content provider and a special application on the customer’s device is then able to open the content by decrypting it, and enforcing the limitations imposed by the provider. In case of the web platform, purchased content is encrypted when the user downloads a ﬁle using a unique device ID. A client-side reading application will then check the ID and decrypt the content in case it matches. Thus, further distribution of content is prevented.

3 Related work

In the scope of this course at the universities, two other groups worked on related products. Both teams had the task to design and construct an eBook reading application for handheld devices, that allows the display and navigation of hypertext documents. One group focused on the implementation for devices running the Symbian operating system, whereas the second focused on devices running the Android operating system. Both groups collaborated together on a shared speciﬁ- cation. Both applications can be regarded as potential client applications for the server

5 system that was developed. A possible scenario would be the purchase and download of educational content through the website, transfer to the reading device and use of one of the reading applications to consume the content. However, this group worked independently and there was no direct collaboration with these groups. The possibility of this is discussed in Section 8.2.

4 Method

In this section, the working process or workﬂow used throughout the entire project is described. A subsection on the artifacts used by the collaborating students follows. Also, an explanation is given of how the collaboration was performed. In general, this section is of descriptive nature. For evaluation, discussion and reﬂec- tion of these matters please refer to later sections.

4.1 Workﬂow Before any actual product development could commence, the need for group organization emerged. In an established business you already have an organization established and roles are based on employee contracts and position, i.e. there are dedicated programmers, managers, testers, etc. In this case, no such organization existed and therefore the need to establish one arose, as the group consisted of 12 students and it was desirable to distribute the work. As it is essential that everyone knows their role in the team and their responsibilities, the most natural thing was to have an establishment phase at the beginning, where people got to know one another, their skills and their motivation. From here on, the work could move into the product development phase, consisting of sequential development iterations, con- tinuously improving the product and management. Management processes con- trolled the development activities and the development activities provided valuable feedback for improving the management used in later iterations. The diagram shown in Figure 1 illustrates this workﬂow.

6 Figure 1: Process model

Establishment phase: Organization & collaboration establishment In this phase students reached out and contact between the members was established. This included holding ﬁrst virtual meetings, assessment of skill and motivation, sharing of personal biographies and the creation of contract and collaboration protocols. Product producing phase: Product development Typical activities such as analysis, design and implementation were performed several times. This is illustrated in the ﬁgure as Sequential iterations. Later in this section, more details on the mentioned activities will be presented. Product producing phase: Process, product and collaboration management The development activities were planned and improved, and different organization of the students were tried out. Important feedback from the development activities affected later decisions on organization and planning.

Development Methodology The requirements were stated in the provided project description and ﬁxed, so one could argue for settling on a non-iterative approach, like the waterfall model. The assessment of the group members’ skills and motiva- tions gave a valuable insight regarding knowledge about development methodolo- gies. The group consisted of many experienced developers, and the opinion was that the product was not large or even complex compared to previously encountered development projects. Therefore, applying a complex development methodology was considered to be overkill. Instead, modelling techniques and documentation methods that were suitable to support the development efforts were selected and

7 used. Some of the elements were: Rich picture diagram, requirement specifica- tion, use case descriptions, domain model and architecture component diagram. The use of iterations for product development was decided on, because by implementing and adding little functionality iteratively, a working product is always available that can be evaluated and that guides the decision making process for future development. Also, by starting with basic functionality, laying out the baseline architecture would make later implementation of more advanced functionality less troublesome. Each iteration was performed in a sequential manner and contained analysis, design and implementation activities. This basically meant that not only code was improved, but also analysis and design artifacts. For instance, the first iteration only contained analysis activity for the features of the first iteration and therefore the analysis activity performed in the second and third iteration improved and added to the created artifacts.

Organization Foundation The entire group was divided into two teams. Team Denmark consisted of six students from IT-University of Copenhagen (ITU) and team Kenya consisted of six students from Strathmore University in Nairobi (SU). In the establishment phase of the project, also the assignment of the management responsibility was discussed. This resulted in a shared management responsibility among one member from team Denmark and one from team Kenya. The complete virtual team management was then done through a collaboration of these two managers. The tasks included project planning, creation of sub teams and creation and assignment of tasks. Managing local affairs and communicating the agreed planning was the individual manager’s responsibility.

Product Development Iterations The roles and organization of the group members throughout the entire product development was not ﬁxed, but was changed with each iteration. The only role that was not affected and did not change was that of the project manager. Even though this is not normally done in product development projects, this allowed for the evaluation of different approaches and collaboration scenarios. Each constellation provided valuable feedback for following iterations and for the project as a whole. The following tables provide a brief overview of all the activities performed in the iterations.

8 Area Activity No. of assign. students Analysis Rich picture ITU(1) Analysis Requirements speciﬁcation ITU(1) SU(1) Analysis Use case description ITU(1) SU(1) Design Technology research ITU(1) Design UI prototypes ITU(1) SU(1) Design Component diagram ITU(2) SU(2) Design Domain model ITU(2) SU(2) Implementation Use cases p1.05, p1.06 and p1.07 ITU(3) Implementation Use cases p1.02, p1.08 and p1.10 ITU(3) Implementation Use cases p1.01, p1.03, p1.04 and SU(3) p1.09 Implementation Use case p1.12 SU(3)

Table 1: 1st Iteration

Area Activity No. of assign. students Analysis Requirements speciﬁcation ITU(2) SU(2) Analysis Use case description ITU(2) SU(2) Analysis Quality requirement speciﬁcation ITU(1) SU(1) Design Payment system research and design ITU(1) SU(1) Design Payment system research and design ITU(1) SU(1) Design Test case design ITU(1) SU(1) Implementation Use- and test cases for p1.01–p1.12 ITU(2) SU(2) Implementation Use- and test cases for p2.01, p2.02, ITU(2) SU(2) p3.01 and p3.02 Implementation Use- and test cases for p2.01, p2.02, ITU(2) SU(2) p3.01 and p3.02

Table 2: 2nd Iteration

For further information please refer to the appendices in Table 3

9 No. Description A.1 This appendix contains a diagram over all the activities performed in analysis, design and implementation illustrated as phases and iterations. Further a description of each activity is listed in appendix A.1. A.2 This appendix contains the group organization diagram and description related to analysis and design in ﬁrst iteration.) A.3 This appendix contains the group organization diagram and description related to implementation in ﬁrst iteration 1. A.4 This appendix contains the group organization diagram and description related to analysis and design in second iteration. A.5 This appendix contains the group organization diagram and description related to implementation in second iteration 2.

Table 3: Iteration appendices

4.2 Artifacts The project group shared multiple artifacts throughout the entire virtual team collaboration effort. Because the list of artifacts are long, it will not be shown here, but can be found in appendix 5C. Instead this section will try to group the artifacts. The first artifacts created were related to documentation. This being project report(s), organization and workflow diagrams, meeting agendas/resumes and collaboration tracking tables. Artifacts for management were planning2, skill and motivation assessment3, member biography, collaboration protocol4 and contact informations. The rest of the artifacts were related to product development. These being task distribution, code/deployment guides5, technology assessment document6, requirement and use case tables, rich picture and architecture drawings etc. After an initial analysis of tools required to manage these artifacts and the source code, it was agreed to use the following software: Google Docs/Drive was used to create, store and collaborate on documents and spreadsheets; DropBox was used to store other file types; Microsoft Visio was used for modelling; Google

2Screen dump of OpenProj ﬁle found in Appendix A.10. 3Screen dump of skill and motivation sheet found in Appendix A.7 4Collaboration protocol is found in Appendix A.8. 5Code and deployment guide found in Appendix A.9. 6Technology assessment document found in Appendix A.11.

10 Code7 was used as code repository and the included issue tracker8 was used for assigning implementation tasks and gather problem reports. Actual programming of the product was done in Eclipse or Netbeans. The project plan was maintained using OpenProj and stored in the shared DropBox folder.

4.3 Collaboration Because of the international nature of the group, the distributed location [7] of the members and the fact that they have never met before, there were some collaborative challenges that needed to be faced. Those challenges will be described in this section together with the way they have been handled. Artifacts created for that purpose are mentioned here, but are described in Appendix A.6.

4.3.1 Cultural Differences and lack of Common Ground When the groups were formed some students also within the local groups had not collaborated or even met in the past. They did not know what to expect from each other and whether they had anything in common, neither for their local nor for their distributed co-workers. Coming from totally different cultures, backgrounds and having different personalities makes the collaborative difﬁculties more con- tingent. People from different cultures have different sense of humour and other perspectives according the deadlines and the punctuality, thus misunderstandings can easily arise. Questions to know somebody’s culture and way of life or jokes to “break the ice” can sometimes be misinterpreted and considered to cross the lines. Moreover, diverse academic backgrounds and experiences can delay the management procedure, the decision making and the actual work.

Mitigation Formal and informal approaches have been used in order to investi- gate and establish common ground as well as to bridge the cultural differences. The ﬁrst approach was the very ﬁrst virtual meeting. Team members in- • troduced themselves providing some basic information regarding their academic background and their skills related to the project. All the team to team meetings were focused on the work that had been and needed to be done, so there were no problems trying out each other’s limits.

Closer relations were established within the working subteams, where the • involved members were also chit chatting in parallel while exchanging their knowledge in project manners.

7http://code.google.com/p/gsd2012-backend/ 8http://code.google.com/p/gsd2012-backend/issues/list

11 In order to determine the existing common ground and find out how the • collaboration could be performed, a Google Spreadsheet9 that reflected all the individuals’ skills in relation with specific technologies, programming languages, fields of interest regards the project, etc., has been created and also taken into consideration in the decision making procedure.

One more Google document has been used in order for the members to get • to know each other. In that document, the students of the group project provided more personal information about themselves, like their family status, working experience, hobbies, etc. Most of them have also included some pictures.

A shared mailing list was established early on, so that all students could be • aware of all the activities going on (activity awareness) and not only the ones they were part of. At the same time everybody could have an overview of how far they are in their project (process awareness) [1]. It also allowed for discussions about a broad range of topics and allowed members to ask questions addressing all other group members.

4.3.2 Language Difficulties Since the whole group was a mix of different nationalities, it was common sense that the language to be used was English. The initial concerns were regarding how fluent and confident everybody was in oral and written English. The correct use of the language as well as to use it in the same way is very important in order to understand what is communicated. Translating something in a different way leads to time loss for clarifications or doubling the work by correcting something that was misinterpreted and developed in the wrong way (especially in case of asynchronous collaboration). Moreover, an important issue during the audio conferences is the pronunciation of the involved members of the virtual meetings.

Mitigation In general the language was not a real challenge in that group. The level of English was quite sufﬁcient and although different pronunciations were distinguished, they were understandable.

In case of virtual meetings if something was not clear because of the use • of English or the pronunciation, either the speaker was asked to talk more slowly and clearly, or even to type it. There were also cases where somebody else helped by explaining it in another way.

9Found in Appendix A.7.

12 In case of uncertainties in written word, the person who had typed the unclear • sentence was asked to paraphrase in writing or orally. Again, other members could also intervene in a fashionable manner and help with clariﬁcations.

4.3.3 Coordination and communication difﬁculties These difﬁculties have to do mainly with the level of commitment of the involved members. In collaboration, and especially in a distributed one, it is hard for all the members to coordinate and there is always the risk that some members will not be that engaged in their tasks as others. Furthermore, it needs extra effort and articulation work to communicate tasks and opinions in such big and diverse groups.

Mitigation Because of the previously described potential factors that could lead to problems, like misinterpretations, team norms were deﬁned right at the beginning. To ensure that the common goal would be reached in the most efﬁcient way, the following strategies were employed:

A communication protocol “Global software development - Contract”10 was • established. The purpose of that document was to reinforce the involvement and commitment of every single member. It reﬂects the required behaviour in the meetings and the way the disagreements or ambiguities during the whole project should be addressed.

The two distributed groups knew how to work together internally because • they had adjusted to the culture of the country they were located. Because of their physical presence the members of the local groups developed more personal relations, as a matter of fact they were more direct in expressing themselves when dissatisfactions occurred and solutions were formed promptly.

When problems occurred within the subteams, they were discussed and solved • internally. If there was an urgent issue, the rest of the members were asked for their opinion/help during the meetings, through the mailing list and instant messaging or by the use of comments in the relevant documents.

There was a silent agreement that when any irregularity/ misbehaviour oc- • curred, the directly concerned members have solved it by themselves through discussing the problem. If common discipline still had not been reached, the team leaders got involved in order to help resolving it.

10Found in Appendix A.8.

13 The idea was to take decisions in a joint effort. The first approach was to • try to define the needs of the project and discuss them together through local and distributed meetings. After the structure of the team took its final form, the usual way of decision making was as follows: the management team defined/discussed the problems and possible solutions. Those were introduced to the local team and decisions were made at first place locally, then proposed and discussed in the common team to team meetings to decide on the best possible solution.

4.3.4 Time/Calendar differences and individual schedules Nairobi has a 2 hour time difference from Copenhagen during winter time and 1 hour when Denmark is observing daylight saving time. This fact could make it difﬁcult to ﬁnd common available hours and arrange meetings or group work. It also possessed the possibility of confusion. Moreover, the students from the different universities had to deal with the differences in their academic calendars (na- tional/school holidays and examination periods). In addition, each member had his own personal schedule, involving other courses and projects that they should also focus on. The majority of the group members were working in parallel with their studies and they had other personal obligation/plans (important family/religious events, traveling, etc.). Consequently, it can be very challenging to coordinate so many people with different everyday routines and special occasions.

Mitigation The small time difference was not that much of a problem and most of the participants had a quite ﬂexible schedule.

To find out which day and time fits all/most of them, they made a poll using • Doodle, a tool provided for free online. It reflected the usual availability of the group members and was used as a guide when planning the team to team meetings. As expected, there were only a few times when all group members could participate.

After subteams for working had been formed, the related members arranged • their meetings through mails or by using instant messaging. When there was a need for all of them to meet, either they used the results of the availability poll, i.e., picking one of the days that suited the majority, or there was a discussion on the mailing list for a more traceable communication.

According to the academic calendars, it was decided to work during holi- • days (e.g. Easter). Moreover, the examination period of the Kenyan team

14 was communicated through e-mail and was around the middle of the project duration, so it was no problem that the team needed to step back for a week. When possible, the members also participated at the meetings from their • workplace. Especially when deadlines were close and some members were unavailable • for a speciﬁc time frame, they ﬁnished the tasks assigned to them either before or they were at least partially available, in terms of checking their emails once per day, responding to questions and discussing potential problems.

4.3.5 Difﬁculties with Collaboration Technologies In distributed collaboration the availability and the quality of different collaboration technologies is of major importance. Members located in one country could not be sure that the other country had good internet connections and if everybody had access to the internet at their own homes. Because also synchronous communication was used and in order to ensure the good quality of the virtual meetings, the group was planning on using some sort of groupware technology [4], but was unsure if both teams had access to relevant technologies (e.g. licenses for Adobe Connect, a web conferencing software). Regarding the actual software development process, access to the collaborative tools was required from all team members. Technology readiness[3] of all the participants was another potential obstacle. It was not clear if all members knew how to use and handle the chosen technologies, as they may not have used them before or are accustomed to different tools.

Mitigation Tools that provided the features the execution of the project required, were mostly available online for free and this was also a major factor which inﬂu- enced the decision making process in regards to the chosen collaboration tools. In general there were no serious problems, but there were some smaller problems: Few people had no connection at home. When they had to attend an online • meeting they went either to the university or used the internet connection available at a relative’s home. Strathmore University was not providing supplementary equipment to en- • hance virtual meetings. At the ﬁrst meetings, ITU students used an advanced video conferencing system (Polycom 360) and it was working well. How- ever, because only one team had access to such a system, it was decided to try out different tools like Skype or Google Hangout with no extra equipment depending on what worked best at the particular time.

15 During the virtual conferences, a combination of solutions had been used • to overcome some connection quality problems. Voice and video was the primary communication form, but if it failed, chat was used instead. Par- ticipants that were not talking muted their microphones to avoid noise and echoing.

Whoever was more familiar with a speciﬁc technology/tool explained to the • members unfamiliar with it how to use it and also created relevant guide- lines11, e.g. what tools are required to access the source code repository and what steps are required to set it up, as well as how to download and commit code to the repository.

4.3.6 Motivational Challenges For the smooth function of projects like that, self motivation is very important. It affects a lot the commitment and the efﬁciency of the members. A challenge was to keep everybody motivated so that they would all contribute during the whole project.

Mitigation To help with motivation issues, task were divided according to members personal interest.

The distribution of roles and tasks was primarily guided by the members’ • skills. After discussing the assignments, it was realized that some people were not satisﬁed with the roles and tasks they were assigned to. Thus, the ”interests/motivation” section was added to the skills spreadsheet12. Moti- vation of learning new things and the willingness/availability to help others to learn was also taken into consideration when forming the working subteams. After analyzing everybody’s ﬁeld of interest and skills, the teams were reorganized accordingly. For example, the team leader of the Danish team changed in the beginning of the project.

Not all the members could be fully satisﬁed or they just were indifferent for • what they would need to do in the project. In addition, there were some tasks that nobody really enjoyed, but they needed to be done. In this case, the team leaders just assigned work to the rest of the members in such a way, that everybody was more or less doing an equal amount of work.

11Found in Appendix A.9 12Screen dump of skill and motivation sheet found in A.7

16 In cases where some people were lacking motivation and thus not took the • project seriously, some of the members took the work on them in order to deliver the tasks on time. A situation that had not been predicted, was the case of some members being • over motivated. At the beginning of the project, when the group still tried to plan and organize the collaboration, the Danish team was discussing the most optimal working method and planned on having a similar discussion with the Kenyan team. At the same time, the Kenyan team had already started working without the Danish team being aware of it. This resulted in confusion for the Danish team, but was taken as a good sign of committed co-workers. It was decided, that the internal group meetings only create proposals, that decisions would be made collectively during team to team meetings and work would commence only after reaching a ﬁnal decision.

4.3.7 Summary The students at ITU and SU never had the chance to meet in person, so all communication was done electronically, using technologies and tools that could also record the collaborative work during the project’s life cycle. The virtual meetings were arranged through a mailing list and the content of • the meetings were documented in Google Docs documents13. These meeting notes included the agenda, conclusions and decisions, as well as the overall impression regarding the meeting, i.e., quality of the technology used, participation of the attendants, etc. Meeting notes were also created for discussions for the respective activities, • such as requirements and use cases, UI mockups, architecture, implementation, etc. Besides that, documents for the virtual meetings were created. One document for meetings done by management and one for meetings done between team ITU and team SU. Throughout the entire project life span the following known collaboration activities took place: 6 virtual team-to-team meetings with a total length of approx. 5 hours. • 6 virtual management-to-management meetings with a total length of ap- • prox. 5 hours. 328 messages created through the mailing list/Google group. • 13An example of a team meeting resume can be found in Appendix A.14

17 5 Product

This section describes the initial requirements for the product and the ﬁnal outcome of the collaboration. Initially an overview of the solution is established. Subsequently, key components of the application will be elaborated in isolation to illustrate the more complex workings of the application.

5.1 Requirements From given project description, the following requirements were extracted:

Web platform with web interface • User accounts, authentication and authorization • Upload and editing of content • Purchase and download of content • Tagging, rating, searching and categorizing of content • DRM • Integration with the payment system M-Pesa • To those mentioned above, also some non functional requirements were added and kept in mind while implementing. Security is very important, so the DRM, authentication and authorization functionality was appropriately designed and implemented. For example, all requests, including authentication and purchase is encrypted (using SSL) and private user data is not leaked. Performance on the other hand, is not of great importance. It can be improved when needed. All requirements were expanded and described in the requirement analysis14, and use cases15 around these features were created. One core addition to the requirements was identified during the first team to team meetings. It was noticed that the teams had different point of views regarding the requirements. For example, the Kenyan team wanted to have separated user roles (i.e., guest, registered user, author, administrator, etc.) and the Danish team found basic user types (i.e., guest, registered user/author) sufficient. The final com- promise was first, adding the requirement for an administrator role, who is able to review and approve document uploads, changes and deletions, and second, that any registered user can also act as an author.

14Found in Appendix A.12 15Found in Appendix A.13

18 5.2 Overview The resulting solution is the outcome of several iterations of analysis, design, implementation and test phases. In order to get a better understanding of the problem domain, the rich picture shown in Figure 2 was drawn from the initial requirements. It will now serve as a point of departure for the presentation of the product.

Figure 2: Rich picture illustrating the system

The rich picture encapsulates all the given requirements and presents a number of communicating entities, along with loosely deﬁned interfaces between them. As described in Section 5.1, the outcome of this collaboration process only involves the creation of the web platform (back-end) and its related interfaces. As it can be seen, integration with the end user takes place in four distinct ways: Through normal browsing, mobile browsing, a reading application and through the payment system, M-Pesa. In the ﬁrst three cases we are in control of the integration to some

19 extent. M-Pesa on the other hand is an established platform, which means that the solution has to conform to a speciﬁcation provided by that system provider. The remainder of this chapter will continue by describing the M-Pesa platform, as integration with it is a big part of the application. Subsequently the system architecture will be elaborated using a number of the views from the N + 1 architectural view model as described in [8]. Speciﬁcally the use case, logical, data, security and development views will be presented. First, the user interface is introduced and the provided M-Pesa interfaces and integration to the back-end is explained.

5.3 User Interface Designing the user interface consisted of ﬁrst considering all features as a whole. Then translating the previously created use cases into interfaces/views the end user should use to interact with. Next, these were modelled into interactive mockups using the collaborative interface prototyping tool, Mockingbird. These were then implemented as actual mockups. For this purpose, Twitter’s Bootstrap framework was used, which is based on modern HTML5 and CSS, and provides reusable components (e.g., buttons, forms, etc.). The resulting web interfaces is responsive and works on desktop and mobile screens, because it automatically adapts to the available resolution. In addition, the usability of the GUI was a key focus while designing it.

Figure 3: Screenshot of the user interface

20 An example of the interface is shown as a screenshot in figure 3. As can be seen, its layout consists of a navigation bar at the top and the content in the center. The navigation is organized in such a way, that the left part allows access to the key functions, such as browsing and uploading documents. The right part contains user-relevant actions, such as access to the profile, shopping cart and signing out. In addition to the required functionality, the PDF documents can also be directly previewed on the detail page of the document. The feature was implemented using a flash-based PDF viewer.

5.4 Integration with M-Pesa As already described in the beginning of the report, the project involved the integration of the web platform with the payment system M-Pesa16. For this purpose, the payment provider, Safaricom, provides a speciﬁcation that describes in detail the two possibilities of payment notiﬁcation that are available to customers:

Poll: the client system regularly check for new payments by performing a • request to the payment system.

Push: the payment system sends a transaction to the client system as soon as • it is processed by making a request to the client system.

The push-based notification integration approach was chosen, because it enables a real-time update of the virtual account balance and does not introduce any delays for the user, like the polling based approach does. In addition, the interface is also based on open web standards (SOAP and HTTP) and easier to implement in the web platform than the polling-based solution, which is based on FTP. Integration therefore requires making available a web service based on HTTP, that can be accessed from the payment provider and is able to process the incoming transaction, which is encoded in an XML document. The account number field can be used by the payment system client for referencing purposes, much like the “reference” field of bank transfers. In the case of the web platform, it corresponds to the user ID. The web service then uses the XML parsing API provided by the web framework and the important values are extracted using XPath. The appropriate user is looked up in the database and its virtual account balance is increased by the supplied amount.

16Using M-Pesa as the payment system was a ﬁxed, non-negotiable requirement

21 5.5 Use Case View The solution’s ﬁnal use case diagram is shown in Figure 4

Figure 4: Use case diagram

22 The diagram shows a more ﬁne grained set of interactions than shown in the rich picture. All use cases are shortly described in Appendix A.13, but the two main ﬂows, upload content and download content, are presented in detail below:

Table 4: Upload content use case

Name Upload Content Actor(s) Registered user, Administrator Precondition The user is logged in Postcondition The content is uploaded and publicly available 1. The user presses upload Main success scenario 2. The user supplies a title, description, category, price, tags and selects the file to be uploaded through a file browser. 3. The administrator approves the content and it is made publicly available. Alternative flows 3a. The administrator does not approve the content

23 Table 5: Download content use case

Name Download Content Actor(s) Registered user Precondition The user is logged in Postcondition The content is downloaded 1. The user presses browse Main success scenario 2. The user locates the wished content. 3. The user presses download and the content file is downloaded. 1a1. The user has not purchased the content yet - presses buy and is sent to his/her shopping cart. Alternative flows 1a2. The user presses checkout and is sent to his/her account page. 1a3. The user pays for the content using M- Pesa. 1a4. The content shows up as approved on the account page when payment has been received. 1a5. The user navigates to the content. 1a6. The user presses download and the content file is downloaded.

5.6 Logical View Figure 6 shows a class diagram of the model elements in our system. Even though it is not an Entity-Relationship (ER) diagram, the database model looks very similar as the Play! Framework initializes the table deﬁnitions from the speciﬁcation of the classes.

24 Figure 5: Class diagram

The User, Content, Tag and Category classes all represent domain objects and therefore should be self explanatory. The transactions on the other hand are implemented in order to facilitate user actions on content items. This allows the administrators to control the validity of such interactions through an approval system. In regards to payment, each one is logged using a payment entity, such that the amount and time of transaction can be tracked.

5.7 Data View The data which the system revolves around, is the content uploaded by authors and downloaded by the paying customers. The ﬂow of data has been illustrated in the data ﬂow model below.

25 Figure 6: Class diagram

Note that an author may also be a paying customer and vice versa. In addition to the ﬂows illustrated above there are a couple of options for manipulating content that have been left out for simplicity, such as associating tags or categorizing it.

5.8 Security View The system is shipped with two security measures. The ﬁrst requires the user to sign-in, before he/she can beneﬁt from the full potential of the site. The second is a DRM system, which is implemented in order to enforce the copyright of the uploaded content. Both security measures are explained in the following two sub- sections.

5.8.1 Explicit Authentication Users who wish to purchase, upload or download content, have to register and authenticate themselves before purchasing content and downloading it. These processes are illustrated in the communication diagrams [8] in Figure 7 and 8.

Figure 7: Signup communication diagram

26 Figure 8: Login communication diagram

All ancillary data is saved in the systems database and is not accessible to other users.

5.8.2 DRM In order to facilitate DRM in the system, a mix of symmetric and asymmetric encryption based on the International Mobile Equipment Identity (IMEI) of the mobile phone has been employed. A sequence diagram describing the encryption ﬂow is shown in Figure 9

Figure 9: DRM sequence diagram

27 The illustrated implementation allows the system to encrypt the content using Password-based Encryption (PBE) before sending it to the mobile phone. Fur- thermore, it does so without exposing the IMEI because it is encrypted using the RSA algorithm before sending it to the server. Should the IMEI number be picked up via other means it would still not be possible to decrypt the content. This is due to the fact, that the PBE encryption is set up using a number of parameters, which are only known server side and by the application running on the mobile phone, which will perform the decryption17.

5.9 Development View To implement the required functionality, the Play! Framework was selected. It is written in Java and is based on the Model-View-Controller (MVC) architecture, providing many built-in abstractions, such as an integrated templating system, Ob- ject Relational Mapping to deﬁne the data layer, an authentication system auto- matic and more. This makes implementing a complex web application easier, as it is not necessary to deal with low-level problems, such as creating an ad-hoc mechanism to structure requests and responses, manual deﬁnition of database tables and queries or manually implementing authentication and authorization using cookies.

5.10 Summary The ﬁnal composition of the implementation can be seen in Figure 10.

17For more information on the Java based implementations of RSA and PBE please see http://docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html

28 Figure 10: Archtecture overview

As explained it makes use of the MVC architecture and Java Persistence API (JPA) for database access. The actual database connection can be configured in the applications config file. H2 is an out-of-the-box database which Play provides as an option for testing, running either in memory or file. The Play! Framework plays a role on every level as it adds support to model, view and controller creation as well as using JPA for easier database access. With this support, the Play! Framework leaves only the implementation concern of the models, views and controllers and releases the concerns of a lot of security and performance aspects, such as SQL injection and the handling synchronous requests. In order to test ingoing requests from M-Pesa, a simulator that can create iden- tical requests of those that are expected from M-Pesa have been developed.

6 Evaluation

In this section an evaluation of the used workflow and the final product is presented. Concerning the workflow, decisions regarding organization, meetings and

29 artifacts are evaluated. This is described in section 6.1. In section 6.2, the product is evaluated, with a focus on functionality, i.e., if all requirements were realized and are properly working.

6.1 Workﬂow Collaborative experiences were gained throughout the entire lifespan of the project. In this section, the most important ones are explained and an evaluation of the workﬂow is given.

6.1.1 Group organizations provided loose but effective control To ensure the process would be be a good experience for all students, the skill and motivation sheet was used to assign responsibilities. With the approach of changing the organization of groups with every iteration, many collaborative setups could be tried out and reﬂected upon. The regular change in responsibility assignment also improved motivation and the learning process for each member individually. To ensure that collaboration naturally presented itself, tasks were preferably assigned to teams consisting of students from both ITU and SU. Previous experience from working on other projects and in the industry revealed the need for coordination, planning and clearly deﬁned responsibilities. Therefore, a decision was made to assign management responsibilities to two members, one in each of the two teams. As the management is responsible for planning and assigning tasks to teams members, there is no need for long discussions and everyone knows exactly what is expected from him. From personal experience, not having this management will result in a bad process and most likely a less optimal product, because confusion about responsibilities might arise and it is also time consuming. Example: As described before, in the beginning of the project, before the product development commenced or was even planned, team Kenya already started implementing. This resulted in general confusion about the state of things. The solution here, was to stop these activities and instead continue planning with use of a spreadsheet with tasks, responsibilities and deadlines, to get the project back on track. The introduction of a joint mailing list ensured that everybody was informed about all activities going on. Moreover, a team collaboration protocol was established that stated necessary formalities. From this point on, members were more aware of ongoing activities and if not, could just ask their local manager.

30 6.1.2 Interchanging teams As mentioned before, different team setups were tried out18. Even though teams consisting of members from both SU and ITU naturally resulted in more collaboration and coordination, because of the overhead it also resulted in less effective work. Also, making decisions via virtual meetings is more difﬁcult, because of the lack of physical presence of attendees makes discussions harder, e.g. through delays and less ﬂuent interactions between the participants. Such virtual meetings essentially exclude the body language, which is important for communication [5]. Compared to teams consisting of only students from ITU or SU, where there were less coordination issues because of use of face to face meetings. The above was experienced with use of both setups (mixed SU/ITU teams and pure SU/ITU teams) for implementation in 1st and 2nd iteration.

6.1.3 Awareness Continuing on the change in team setups, it was noticed that sometimes students from SU reached out to just anyone from team ITU and did not contact their own team members. This was problematic, because the questions sometimes were related to tasks assigned to subteams, therefore possibly specific and not everyone could answer them. One reason could be the lack of awareness regarding the interchanging teams. Another reason might be, the relevant persons from team ITU were unavailable. The different team setups were communicated by the management, and could be found in the project plan19 and diagrams20, so the information was available, but could have been miscommunicated. In general, the mailing list was the primary technology that was used to stay in contact. It was decided to have only one, which resulted in process awareness[1] for all team members, but the downside was that the communication sometimes only were relevant for some members and not all. One central use of it was the scheduling of meetings: It helped in the discussion process and also allowed anyone to look up the result. However, in conclusion, many team members found that looking through mails to find planned meetings was a less than optimal solution. All in all the mailing list did provide value, but better solutions might exist. The group was also lacking availability awareness[1], especially between team ITU and team SU. A tool or protocol for ensuring this awareness was missing. For example, in one specific case, a member who was part of the group being responsible for implementing the integration with the payment system and had the

18See appendix A.1 - A.5 19Project plan found in appendix A.10 20See appendix A.1 - A.5

31 most knowledge about it, was on a business trip to Germany for a week, during this time the group intended to perform the implementation. The situation was not communicated beforehand, and was found out when the developer was offline for a long period of time and unavailable at mail as well. Another problem was that in many occasions e-mail responses were delayed. This is a typical problem with this specific asynchronous technology. After the message has been sent, the sender has no clue whether or not the e-mail has been received, read, understood or replied. Team Denmark sometimes felt there was a lack of participation from team Kenya. They do not know the exact reasons for that, but it presented itself as the aforementioned missing e-mail replies and unfinished work on agreed deadlines. Following evaluation meetings revealed several issues. All the students take different courses and part time jobs besides this project, which are external factors effecting the project planning. Knowing the exact amount of time a student will use on the project is unknown. In a company an employee has specific working hours making it easier to plan. In contrast, a student un- dertakes simultaneously different courses and coordinates with different working groups, of which each member has a different schedule. Secondly, motivation and commitment is based on this core influence. For instance, a member could agree to do some work for a specific deadline, but if it is missed, there are no serious consequences. In a company, the employee would possibly get fired. In the last virtual team SU to team ITU meeting, a broad discussion on the entire project was done. Here team SU explained that the process was not as smooth as expected, because most of the team members had day jobs and getting time off was problematic. In addition, no specific time was allocated to do actual project work, so the SU students had to work on this project beside their normal courses. To handle this issue, they declared Saturday as the main day for the project, as it was not a working day. This was however neither communicated at the beginning, nor during the project.

6.1.4 Experience with virtual meetings Figure 11a and 11b illustrate the time used on a total of ﬁve virtual team to team meetings and ﬁve meetings for the members with management responsibility. In addition, there were both a last team to team meeting and management meeting to discuss and evaluate the project and experience.

32 (a) Team to team meetings (b) Management meetings

Figure 11: Duration times of meetings

The duration of team to team meetings decreased over the course of the project and can be interpreted as a decreasing need for it and/or importance of it. It also indicates that there was less of a need to discuss things. The team meetings were used for team cohesion and general information which lost its meaning, while it was replaced by work done in subteams and management meetings. Management meetings (right ﬁgure) duration was not in sameway declining, but instead peaked at times of reorganization of sub teams. One thing to note is that the number of meetings are relative low. Had the project ran for a longer period, more meeting data would have been gathered. This could provide more statistics or reveal other trends than the ones described.

6.1.5 Implementation activities Figure 12 shows on the X-axis the week number and on Y-axis the number of commits to the repository.

33 Figure 12: Number of commits per week

The interesting part is the decline to one code commit in week 18. The explanation is found in the project plan, where the product completion date is the end of week 18. In a perfect world, no more commits would have been performed after this week, but of course the product had bugs and missing functionality, which was implemented after this week. Week 12 saw another decline, because the ﬁrst implementation iteration was completed there.

6.1.6 Value of artifacts Working with Google’s collaboration technologies worked well. For example, real-time collaborative editing was a huge advantage. A disadvantage however, was the missing integration between the different tools (Google Docs, Spread- sheets, Drawing, etc.). Using software from different vendors would have probably worked equally well. For example, virtual meetings were held using both Skype and Google Hangout, but both worked equally well. One advantage of Hangout however, was the availability of free group video conferencing, which is a paid feature in Skype, so we did not make use of it. The use of Google Docs was very beneﬁcial. All students had access to all documents and could collaborate real time on shared artifacts. During meetings, the appropriate agenda notes were open and amended by all participants. Without this possibility the shared work would have been much more troublesome. In addition, it allowed organizing the large number of documents into a useful hierarchy. While Google Docs provided good text editing support, modelling with Google Drawing did not provide an equally good experience. The same collaboration options were available, so multiple students could manipulate the same drawing

34 simustainly. This was for example used, when creating the component diagram. An issue though, was that as it is not a full UML modelling tool, such as Microsoft Visio, so working on shared development artifacts like the use case diagrams and domain models were impossible. A tool that could provide the functionality of collaborative work on shared development artifact, like a UML models, would have been nice to have. Visio was used, because it was known by some students, but required manual synchronization which let to problems. For instance, working on one Visio ﬁle placed in a shared DropBox folder resulted in overwritten changes, which happened while working on the domain model. Biography: The use of a document containing the members’ biography made it easier for the group to get to know each other, which was not easy when considering the project’s distributed nature. The collaboration became more personal and the team cohesion improved, since members realized that they were all students with concerns and aspirations. Selection of implementation technology: To ease the decision making process of selecting the most appropriate implementation technology for the given task, the most widely used Java web frameworks were evaluated. The resulting spreadsheet listed21 the included features, related them to the functionality that needed to be implemented, and also analyzed the frameworks advantages and disadvantages. This allowed for an objective comparison in respect to the project. The team members were then able to vote and comment on three different frameworks. As a result of this evaluation, the Play! framework was chosen. In general, the evaluation was very valuable and a good approach for settling on the best possible technology, respecting the members’ preferences and abilities. On the negative side however, the evaluation was conducted by only one team member and not all members participated in the voting and commenting process. Skill and motivation: Previously, the skill and motivation sheet22 was mentioned. This turned out to be a very valuable tool, as it was a good base for discussion and decision making and made the division of tasks easier, because the management could see each team member’s skills and motivation and use this as base for distribution of work. To further guide this, the sheet also contained number of expected weekly project working hours and grade being aimed for. This provided a way to see if all members had the same amount of ambition. The challenge which presented itself was timing and content. Content being which relevant subjects should the sheet contain (technologies, methods, processes, etc.), and timing being when should members ﬁll in their data. The issue of timing occurred, because the sheet got updated many times with new content (questions) after mem-

21Found in appendix A.11 22Found in appendix A.7

35 bers had already ﬁlled in their answers. This resulted in missing numbers for new content. Another problem was the confusion regarding the use of intervals for rating, e.g. the chosen 0-10 (with 10 being top) was not applicable for the anticipated grade (max. 12).

6.2 Product 6.2.1 Functionality All required features have been successfully implemented and even some additional functionality was added, such as a the administrators’ approval process. All aspects of the system have been extensively tested by writing a full test-suite using the testing features included in the Play! Framework. All test cases are limited to the functionality that was implemented, as we assume the framework itself is behaving correctly. There are three types of tests, each covering a different level of the MVC architecture:

Acceptance tests: Covers views, written as scripts that run in the browser • and use the web based user interface.

Functional tests: Covers controllers, requests targeted the application layer • (HTTP).

Unit tests: Covers models and other system internals. • First, tests cases for all use cases were defined in a spreadsheet23, then implemented using the integrated testing libraries. The final test suite for the web platform consists of 37 acceptance, 17 functional and 5 unit tests. As the project only covered the implementation of the back-end system/web platform with a web interface, only the interface to the payment system was implemented, but no real integration with an actual payment provider was performed. The project also did not cover the implementation of the client side aspect of the DRM functionality, as the platform only provides a web based interface which can be accessed with a web browser and no description can be performed. This situation made testing difficult. To check that also the payment and DRM functionality was properly functioning, therefore also functionality simulating the external the external components was implemented: A component simulating the submission of payment transaction from M-Pesa to the web platform, and a client

23Found in appendix A.15

36 application decrypting the content on the device. For the payment system, a functional test thus proves the correctness of the integration, and for DRM, both a unit test checks the encryption and decryption process in general, and a functional test veriﬁes the correct behavior of the two-phased download process. An emphasis during testing was also put on checking security in terms of authorization, as there exist different user roles with different levels of privileges. For example, a download of content is only allowed, if it was previously purchased, un- approved uploads should not be visible, and only administrators have access to the approval system.

6.3 Technology Evaluating the selection of the web framework in general, the chosen web framework Play! was a good decision, as it provided already many aspects of the functionality that needed to be implemented (e.g. MVC, ORM, authentication, testing, etc.). It thus allowed for quick prototyping, changes and extensions, which were performed with each iteration. Using it required adhering to a certain organization of code and files, which led to a well structured code base. The implementation therefore mainly involved turning the mockups, created by the user interface team, into views/templates, and writing short and concise controllers and their actions. A problem however was the challenge of technology readiness [1]. Some of the members were quite familiar with the development of web applications and already knew other MVC-based web frameworks which are using similar concepts, such as ASP.NET. For them, adopting a similar framework was no problem. Some other members had limited experience developing web applications and mostly only new scripting languages, such as PHP, and were not familiar with application architectures, such as MVC. For them it was a minor challenge to understand and get accustomed to a higher-level framework and possibly new language. Few members had no prior knowledge of developing a web application and had problems understanding core concepts of web technology, which resulted in difficulties understanding concepts used in the framework. Thus, the major problem was a different level of knowledge regarding web development and technologies. Nevertheless, it was necessary to reach a consensus, which respected this difference in knowledge, but also the framework should not be too low-level and simple, to reduce development effort and thus development time. The choice of programming language however was not problematic because everyone knew Java and had used it prior to the project, but maybe for different purposes. One possible reason for the problem regarding the knowledge gap and problems with the framework might be the members’ lack of participation in filling out the skill sheet and evaluating/voting on a web framework. Objectively, given the

37 elicited data, good choices were made. When the described problem became evi- dent, it was already too late to switch to another technology. However, the opinion was that using a another framework would not have changed the situation much, because the challenge is more about collaboration, task distribution and commitment.

7 Discussion

In this section the entire collaborative experience is discussed from the perspective of possible improvement by asking key questions about what could have been done better or which approach could have worked out better, regarding both tools, methods, organization, etc. In order to bridge the cultural differences, at the first meeting an introduction could have been presented by each group, containing a few things about the main principles of their cultures. This could then be used as a guideline on how to approach each other. However, when describing your own culture, you can not be objective, so it could be helpful to make a supplementary research about how the participants from different countries are usually thinking and working. People with relevant experience could also be asked, since they are able to indicate the difficulties of the collaboration in the specific cultures, and also to advise how to overcome them. Finding a good solution to resolve the language barrier in such a short term project is difficult. If anyone from the group had serious problem communicating in English, his group mates should help him by giving clarifications and rephrasing the ambiguous sentences. Furthermore, he should be encouraged to participate and describe his intentions if there are misunderstandings. In a real world scenario, the employee could be supported and provided with language courses. Furthermore, delays could have been avoided, if the members would not have hesitated to ask each other when they needed help or for clarifications. To make this happen, more effort should be put in establishing closer relationships, even if it is just at work level. Two cases are relevant with that issue. First, remote members did not feel comfortable to contact their remote group-mates at any time. For example, when new tools/technologies/plug-ins were to be used, a partial solution could be the two distant groups having parallel internal meetings trying them out. Using this approach, both groups would know that everybody is working on the same thing and would not hesitate to disturb the other team for relevant discussion. Second, some members of the project observed problems with the usage of abbreviations, i.e., some were unknown or used differently. Again, many hesitated to ask and tried to understand them from the current context, but not always successfully. To

38 prevent misunderstandings, the person who is introducing the abbreviation should always remember to explain it first, possibly in parentheses or while talking. In case he forgot to do so, the rest of the members should ask him right away. After dividing the tasks by also considering each member’s motivation, the collaboration immediately improved. Realizing how important this is and considering there are no fixed roles in such a broad project and the members are free to decide almost everything by themselves, a document containing the skills and interest of the involved members proved very useful and should be created right at the beginning. Defining the purpose of each type of meeting (internal or team to team) and the use of common agendas for all meetings, including internal ones, proved very useful as well, as the meetings were thus well structured and conducted in a very efficient manner. This also allowed all members to get properly prepared before the meetings in order to be able to actively participate in them.

7.1 Artifact Efﬁciency In the previous section, the value of the artifacts was evaluated. The following discussion focuses on improving this value and therefore lowering the burden of collaboration and coordination activities.

Guidelines and versioning The use of artifacts was more or less ad-hoc, as they were created, manipulated and deleted all the time, as needed. As a result, most members had difficulties keeping a complete overview and questions like ”Where can I find X?” and ”Do we have a document concerning Y?” were common, even though the content existed. Google Docs only provides limited document management capabilities, such as hierarchical collections and search functionality. A history of changes is available, but only in documents and there is no proper support for versioning. It is also not possible to review who worked on what for a given version. A guide for structuring the artifacts was missing and would have been a good idea. However, this would have only been possible if the members had known what was needed in regards to artifacts upfront. This was not the case, so the guide would have changed in a similar ad-hoc way. To help with the structuring of documents, one solution could have been the introduction of a project portal or site, where files could be uploaded, shared, checked-out and manipulated. Had the project duration been longer or the product more complex, the decision of introducing such a solution would be much more relevant. It should also be pointed out that the project was without any budget, so buying a license and running an instance of Microsoft Sharepoint, which included the aforementioned functionality, was not possible. An alternative would

39 have been a Wiki system, which was discussed at the beginning. At that time, the group decided that if the need arose, it would be set up, but was forgotten and only realized in the evaluation phase of the project. Still, some guides were created, e.g., regarding the use of the repository and deployment of the product, which helped a lot. However, this could have been extended and there was a need for more speciﬁc guidance concerning coding standards, check-in policies and proper usage of the issue tracker.

Awareness Previously, the problems regarding lacking process and availability awareness were mentioned. Introducing a shared calendaring system for meeting and availability times would have been a good solution to both. This would have allowed all members to have a centralized place to check for such information, instead of relying on the mailing list, which still could be used for discussions. Such a system also would have allowed the group members to synchronize the data with their mobile devices and get real-time updates. Another possibility could have been the introduction and use of a more complex full-featured collaboration tool, instead of relying on individual tools. This allows for a better overview on what is being worked on, who is working on what, and the status of processes. There exist a number of such systems available for free, for example Trello or Podio. This was not tried out during the project, but could have been promising. On the other side, this would have introduced new tools, which require proper usage and therefore training of the users. Grudin explains this importance of this adoption process as one of 8 challenges for groupware developers [6]. Another challenge when adopting a new collaboration tool is the disparity in work and beneﬁt: usage will drop, if more work needs to be invested into a tool, than the productivity gains it can offer. Also, a sustainable amount of users must be present to sustain it (challenge of critical mass/prisoner dilemma), as a system with few users will result in less contributed content, which in turn results in a useless system, which gets abandoned by its users.

Modeling The artifacts used by the implementation team included requirements, use case descriptions, domain model, component diagram and UI mock-ups. The key question was, whether or not the quality of these artifacts was good enough to support this work. The level of detail was medium, because the teams should think for themselves and not just follow a detailed implementation plan. Prob- lems arose when different teams had to share or use each others artifacts. Without a detailed description and no interface guidance, decisions had to be negotiated ad-hoc. The same issues occurred when the implementation teams included both students from ITU and SU. The problem could have been mitigated by increasing

40 the level of detail, which was also done as soon as the issue was discovered. Use case descriptions were already quite comprehensive, but could have been extended with sequence diagrams. A joint effort with the deﬁnition of interfaces, stub controllers/methods would have also contributed to resolving the problem.

Technology adaptation All of the members being IT students entail the fact that they are welcoming the opportunities of using new technologies. Most of the collaboration technologies (eg issue tracker, play framework, google documents etc) have been used of some of the group members. For those that they were new, per- haps they haven’t used those technologies themselves, but they were familiar with their logic of use since they have worked with relevant ones in their academic or work experience, as a result they could adjust quite fast. Those that knew how to use them have helped their fellows by setting with them and help them with in- stalling and explaining them the basic functionalities. Some guidelines have also been created for asynchronous coaching. Not only the members as individuals have adapted to the technology but the whole group as a unit. The collaboration of the members and its management was adjusted to the available technologies. For instance, when help was needed, the ones that were more familiar with a spe- ciﬁc technology were asked to give directions, if other technologies were used, different persons might be more familiar with them thus been the one consulted when needed. Google docs were providing the ability to comment on things, so thoughts on speciﬁc aspects were communicated in that way instead of using mails or document tracking.

8 Further Work

This section describes the possible improvements and possible future features of the product, but it also presents the possibility of collaborating with other groups, as mentioned earlier in section 3.

8.1 Product Improvements The interface and usability of the resulting product is already on a high level, but for example, the user’s proﬁle already contains all relevant information, but its presentation could be further improved. Even though the web platform can already be used in both desktop and mobile web browsers, giving the user a good cross- platform user experience, native client applications would be a nice addition, as they would provide direct integration with the developed back-end and the DRM system.

41 The platform already provides users with a preview of the document, if the file format is PDF. This could be further extended to support more file formats in general. Currently, the user directly downloads the document in the format as it was uploaded. For instance, this could be a Word document, but the customer might not have Word available. A solution to this problem was already implemented, but is not yet integrated in the final product. As soon as an author uploads a file, it is submitted to a conversation queue, which is using OpenOffice to convert it to PDF. Thus, every user has access to the original file, but also a version of it in an open file format is more widely supported and for which many free reading applications exist.

8.2 No Collaboration with other Groups As described earlier, two other groups in context of the course worked on mobile client-side reading applications, but collaboration with these teams was neither required nor encouraged. During the course of the project, it often occurred to the team members that working independently on a single system, namely the backend, lead to problems when designing and implementing interactions that involved client-side components. This was for example the case for the Encryption/DRM feature of the system, where control over the encryption part was possible, but was impossible for the decryption. Thus, an alternative approach of implementing the system would have included the collaboration with these two other groups. Like these groups worked collab- oratively on a shared speciﬁcation regarding the content format and other details, a collaboration with them could have involved working on a shared speciﬁcation of a direct web service interface describing details such as authentication, upload, purchase and download of content from the system, including aspects such as encryption/DRM. This would have improved integration with our service and would have resulted in a proper implementation of a educational content sharing system that in- cludes both components, server and client. It would have also increased the number of people involved, resulting in more complex collaboration work, which in turn would have added to the educational aspect of the project. On the other hand, it would have also increased the complexity, articulation work and effort required to implement the system.

42 9 Conclusion

This report reﬂects the collaboration between two teams of students of ITU and SU respectively in order to implement a web platform for sharing educational content. The way decisions have been made, work units have been distributed and members have been coordinated, in order to achieve the common goal, has been explained in detail. Even though the students were part of such a diverse group, the group has overcome many collaboration challenges, by using previously acquired techniques and methods, but also by adopting new ones throughout the process of the development. This allowed the members to overcome most challenges as soon as they occurred. Lesson learned was that the introduction and use of management activities was important to the success of the project. All required functionality of the system and some additional useful features were successfully implemented and tested. The management of collaboration was well executed including proof of a comprehensive tested product. The project experience is vital to all students, which are interesting in learning the many aspects of collaboration. Taking these factors into account, the project can be considered a success. Even though the project is considered a success, one should be careful when drawing parallels from the conclusions in this section to a real world situation.

References

[1] Leinonen, P., S. Jarvela, et al., Conceptualizing the awareness of collaboration: A qualitative study of a global virtual team., Supported Cooperative Work (CSCW): An International Journal 14: 301-322., 2005 [2] Majchrzak, A., R. E. Rice, et al., Technology Adaptation: The Case of a Computer-Supported Inter-Organizational Virtual Team., MIS Quarterly 24(4): 569-600., 2000 [3] Olson, G. M., & Olson, J. S., Distance Matters, Human-Computer Interaction, 15, 139- 178, 2000 [4] Schmidt, K., & Bannon, L., Taking CSCW Seriously: Supporting Articula- tion Work, Computer Supported Cooperative Work (CSCW): An International Journal, 1(1-2), 7-40, 1992 [5] Wikipedia, Body Language, http://en.wikipedia.org/wiki/Body language [6] Grudin, J., Groupware and Social Dynamics: Eight Challenges for Develop- ers, Communications of the ACM, 37(1), 92-105., 1994

43 [7] Bradner, E., & Mark, G., Why Distance Matters: Effects on Cooperation, Per- suasion and Deception Paper presented at the CSCW, New Orleans, Louisiana., 2002

[8] Larman & Craig, Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development (3rd Edition), Pren- tice Hall PTR, 655-699, 223 2004

44 A Appendix

A.1 Product Development Iterations The activities performed through the two development iterations are illustrated on Figure

45 A.1.1 Analysis Phase Activities Rich picture: Is a illustration of the system to be built. The translation of • text oriented requirements into a visual representation, gives the interested reader a better overview of elements involved in the problem space, but also clear boundaries and understanding for the group about the solution.

46 Requirement speciﬁcation: Requirement analysis is to determine the needs • to meet for a product. In order to start implementing the software it should clearly be deﬁned what it should be able to do.

Use case descriptions: Use cases describe more thoroughly the require- • ments. They describe the reaction between the users and the system.

Quality requirement speciﬁcation: Activity contained clariﬁcation of the • quality/test requirements from the supervisors.

A.1.2 Design Phase Activities Technology research: This activity was about ﬁnding suitable frameworks • for use in design and implementation.

UI prototypes: UI Prototypes will show the system from a look-and-feel • perspective. The underlying functionality will be missing or simulated.

Component diagram: Diagram illustrating the different components found • in the solution, which is based on the MVC pattern.

Domain model: UML diagram describing the structure of the system show- • ing the system’s classes, their attributes, operations (or methods), and the relationships among the classes.

Payment R&D: This activity was ﬁrstly to get an overview of the ﬁxed pay- • ment system (M-pesa) and then to design the integration and/or simulation.

Encryption R&D: Firstly DRM encryption was researched. Secondly a de- • sign was developed for the system.

Test case design: Test cases are step-through guidelines to ensure that use • cases work as they are designed.

A.1.3 Implementation Phase Activities Implementation: Implementation is about producing code, realizing the de- • signed product.

Testing: Testing is ensuring that the ﬁnal or partial product contains the de- • signed functionality, follows the requirements etc.

47 A.2 Organization in Analysis and Design for 1st Iteration Figure 13 illustrates the tasks performed between members. The shared artifacts was Google docs, spreadsheets and drawings, but also DropBox ﬁles. The tasks were done sequentially. First task was the iteration plan, laid out by management in a Google spreadsheet. Then analysis activities could start, consisting of requirement speciﬁcation and use case descriptions. After this design could commence consisting of 3 different tasks, some done in parallel.

Figure 13: Analysis and design - ﬁrst iteration

48 A.3 Organization in Implementation for 1st Iteration In implementation for 1st iteration, 4 teams named Implementation Team A, B, C and D (ITeam A-D) with 3 members each were formed. The use cases were grouped and assigned to each team, essentially working as implementation tasks. All artifacts produced in analysis and design was used as speciﬁcations to support the implementation work. All code was committed to the shared repository. The organization is shown in Figure 14.

Figure 14: Implementation - ﬁrst iteration

49 A.4 Organization in Analysis and Design for 2nd Iteration 2nd iteration ﬁnished to job regarding analysis and design. Incorporating the requirements from product 2 and 3. 4 people were assigned so ensure higher quality of this work (having more eyes on the matters). QA team was introduced to spec- ify testing requirements. 2 research and design (R&D) teams for encryption and payment was also formed.

Figure 15: Analysis and design - second iteration

50 A.5 Organization in Implementation for 2nd Iteration The difference from previous implementation setup is the use of mixed teams, consisting of both SU and ITU students, but also introduction of test case tasks/activities. 3 teams (X, Y, Z) were formed with 4 team members each, being 2 from ITU and 2 from SU. The organization during implementation is shown in Figure 16

Figure 16: Implementation - second iteration

51 A.6 Table Listing artifacts

artifact Medium Area/relevance Description Project report, Google Docs: Doc- Documentation This report team Denmark ument Project report, Google Docs: Doc- Documentation The report team Kenya should team Kenya ument hand-in (read-only from our side) Product 1 sub Google Docs: Doc- Product develop- A working document to guide parts ument ment implementation work in ﬁrst iteration. Project plan- Google Docs: Management The project plan with tasks, ning Spreadsheet deadlines and responsible team members (deprecated). Members biog- Google Docs: Doc- Management Document containing descrip- raphy ument tions of team members on a more personal level. Team members Google Docs: Management Skill and motivation assessment skills and moti- Spreadsheet sheet. Measures was done with vation ordinal scale (1-10). Global software Google Docs: Doc- Management First working document contain- development - ument ing contact information and rel- group 6 evant links. Technologies Google Docs: Product develop- Framework assessment and Spreadsheet ment comparisons sheet. Communication Google Docs: Doc- Documentation Collaboration tracking docu- Log ument ment. Contract Google Docs: Doc- Management Formal collaboration protocol. ument Virtual meet- Google Docs: Doc- Documentation Meeting agendas and outcome ings: Team DK ument for complete group meetings. 2 Team Kenya Local meetings: Google Docs: Doc- Documentation Meeting agendas and outcome Team DK 2 su- ument for team denmark and their local pervisors supervisors. Virtual meet- Google Docs: Doc- Documentation Meeting agendas and outcome ings: Man- ument for management responsible agement 2 from both teams. Management

52 Virtual Meet- Google Docs: Doc- Documentation Meeting agendas and outcome ings: Require- ument for analysis activities. ments+UC 2 Require- ments+UC Local Meetings: Google Docs: Doc- Documentation Meeting agendas and outcome Team DK ument for local team meetings (denmark). Virtual Meet- Google Docs: Doc- Documentation Meeting agendas and outcome ings : ar- ument for design activities. chitecture 2 architecture Code Google Docs: Doc- Product develop- Internal guide for running devel- ument ment oped solution on local environ- ment. Requirement- Google Docs: Product develop- Test case descriptions (with rela- test cases Spreadsheet ment tion to requirements). Requirements Google Docs: Product develop- Requirement and use case de- UseCases Spreadsheet ment scriptions. Rich Picture Google Docs: Product develop- Picture illustrating system Drawing ment boundaries and interaction with actors. User Interface Google Docs: Doc- Product develop- Working document for the UI ument ment prototype activity. Architecture Google Docs: Product develop- Component diagram. Overview Drawing ment Deployment Google Docs: Doc- Product develop- Guidelines for deployment of ument ment developed application to a web server. MPesa- Google Drive: Product develop- Introduction slides to M-pesa ITU.pptx Power Point ment payment system (made by team kenya). OpenProj plan DropBox: Open- Management Complete project plan saved in gsd2012 Proj file external tool (Open Proj). ProcessPhases DropBox: Visio Documentation Diagram illustrating workflow file or process. ProductPhases DropBox: Visio Documentation Diagram illustrating activities file and iterations.

53 TeamWorkFlow DropBox: Visio Documentation Diagrams illustrating different file team/ members setups. Domain model DropBox: Visio Product develop- Diagram illustrating the systems file ment classes and their relations. GSDCrypto- DropBox: Visio Product develop- Sequence diagram describing Sequence file ment the encryption flow between client and server. Use Case DropBox: Visio Product develop- Use case diagram file ment interface DropBox: Folder Product develop- Folder contains UI mockups in ment HTML format. Css etc. Link24 Google Group Documentation/ Mailing list Management Link25 Google Code Product develop- Code repository ment

Table 6: artifacts used throughout the process

24http://groups.google.com/group/global-software-development-backend 25http://code.google.com/p/gsd2012-backend/

A.8 Collaboration Protocol Group behaviours expected of each member Temporal 1. All group members will be punctual. Meetings will start ﬁve minutes after the agreed start time and everyone should be there and ready by then.

2. We should turn up to all meetings unless it has been agreed beforehand or unless there are unavoidable events such as illness.

3. All group members will remain in the meeting until (a) all tasks for that meeting are completed, or (b) there is unanimous adjournment.

4. Breaks will be decided by unanimous consent, and breaks will not exceed twenty minutes in length

Procedural 1. All group members will come to the meetings prepared by

(a) reading the assigned material (as much as possible), and (b) coming with ideas pertaining to the tasks and decisions to be made.

2. Tasks that group members agree to undertake should be completed to the agreed deadline. If it looks as though there will be a problem meeting a deadline, the person concerned should seek help from other members of the team in time to avoid a delay.

3. There will be an assimilation period at the end of the session to evaluate group mechanics and ensure that all tasks have been completed adequately.

4. Each group member has the right to point out whether any of these rules are being broken.

Behavioural 1. The group will actively seek a consensus of opinion based on the opinions of every member.

2. Each member will take turns listening as well as talking, and active listening will be a strategy for all group discussions.

3. Aggressive and dominating behaviour is not acceptable.

Methods for resolving an impasse

56 Step 1: The group members will isolate areas of disagreement, and the group • will come to a consensus. If no consensus is reached, proceed to Step 2.

Step 2: Vote. If the vote is a stalemate, the leader makes a ﬁnal decision. •

57 A.9 Code and deployment guide Repository We’re using Subversion as the version control system. You can browse the code through a web interface at http://code.google.com/p/gsd2012- backend/source/checkout. ”Changes” is a commit history. There’s also information on how to check out the code. Set up the subversion client of your choice by using the URL: https://gsd2012-backend.googlecode.com/svn/trunk/ The username is you mail address listed at the top of this document. NOTE: Your password for the repository is NOT your password of your Google account! You can ﬁnd it at https://code.google.com/hosting/settings. If you’re on Windows, I can recommend TortoiseSVN. A tutorial is here: http://underworldteam.googlecode.com/ﬁles/Tor toise%20SVN%20TUTORIAL.pdf

Using the code Check out the code as described above. Run the following com- mands:

cd path/where/you/checked/out/gsd-backend2012 • Go to the application’s directory, NOT the play directory!

play dependencies • Needed to set up references to the modules we’re using

play eclipsify • Create eclipse project ﬁles for the project. If you’d like to use Netbeans instead of Eclipse, use netbeansify.

Then simply open up your IDE and open the generated project. You only need to start the server once. As soon as you change ﬁles, save the changes and then perform a new request to the web server, it will automatically compile and load the changed code for you.

Play! Framework We are using the Play! Framework for implementation. Please check out the website for tutorials and other information: http://www.playframework.org, We are using version 1.2.4.

Server The server needs to be a web container able to execute Java Web Archives (WAR). See https://en.wikipedia.org/wiki/Web container for possible implementations. As the application is written in Java, it is platform-independent. The description will assume an installation of Debian Linux. One possible web container is Apache Tomcat. To install the server, run: apt-get install tomcat6

58 Application Change the application’s mode from development to production, by editing conf/application.conf and setting application.mode=prod. Currently an in- memory database is used. To point the application to a proper database, such as a MySQL server installation, adjust the db property and set it to a valid connection URL, e.g. in the format db=mysql://user:pwdhost/database. When running the application for the ﬁrst time, the database will not contain any tables. To automatically create them when the application is run, set jpa.ddl=create. Finally the application can be packed as a Web Application Archive. For this purpose, run: play war gsd2012-backend -o ROOT The directory ROOT can now be moved/copied to the server in location /var/lib/tomcat6/webapps/. Restart Tomcat by executing /etc/init.d/tomcat6 restart. The application should be available through http://localhost:8080/.

References See http://www.playframework.org/documentation/1.2.4/deployment for further information.

59 A.10 OpenProj Project plan

Figure 19: Project plan from OpenProj

60 A.11 Technology Evaluation

A.12 Requirements

A.13 Use Cases

68 A.14 Meeting Resume Sample Date: 17.02.2012 Preparation: Fill out skill sheet. Technology: Google Hangout - Video call. Type: Information sharing. Participants: Frederik, Nikolaj, Bastian, Soﬁa, Mikkel, Karen, Mark, Sita, Christo- pher, Oscar. Facilitator: Frederik. Referent: Nikolaj. Duration: 12:00/14:00 - 13:00/15:00 (60 minutes) Location: Frederik=home, Nikolaj=work, Bastian/Soﬁa/Mikkel=ITU, Karen/Mark/Sita/Christopher/Oscar=Strathmore. Experience: There was a lot of noise from microphone feedback on the laptops where multiple people were sitting (no headphones). Muting the mics when not talking was a acceptable solution. Screen share worked well

Agenda:

1. Roles and organization of work and groups.

71 (a) Communication ﬂow: (b) Do we agree on the above? (c) Get people connected following the above diagram.

2. Framework scoring matrix (Bastian)

3. Version Control (Bastian)

4. Requirements: Current state and interaction between Soﬁa and Josphat.

5. Architecture: Current state and interaction between architecture teams.

(a) step 4 in m-pesa presentation on slide no 11: “Can team Kenya please tell us more about this?”. How should it work? (b) Is it part of normal m-pesa process or something we need to implement? (c) Clarify payment process: i. conﬁrmation code?! ii. account number / business number?! iii. approach?: A. pay each item individually B. top up system: send an amount, use it to pay for items

6. Agree on what should be done until next meeting.

(a) Finish requirements and use cases. (b) Create architecture overview.

7. Evaluation of this virtual meeting.

(a) Problems, issues, improvements. (b) Hangout worked ok?

Outcome Meeting minutes, 17/02/2012 12:00: Firstly, the new communication flow was presented (refer to the flow diagram above for details) It’s important to reach out to your counterpart teams yourself and to work in small more or less autonomous groups while reporting to management. Changes to the communication flow are to be expected over time, but at the moment it is accepted by all members.

72 Technologies : Bastian has created 3 documents: The ﬁrst is a framework scoring matrix which presents pros and cons to different kinds of framework. The current onset as proposed by Bastian is to use a framework that covers all layers instead of several frameworks covering only a subset of the layers each. The argument is that integration between the different frameworks and/or layers takes time. The second document contains a list of technologies/frameworks that have already been analyzed. The third document consists of a list of requirements to the framework that we’re going to use and will be extended over time. Feel free to add to the documents yourself - otherwise Bastian will extend the documents. In regards to the different scoring techniques, Frederik wanted to conclude on their usefulness. Oscar pitched in and evaluated the techniques positively. Bastian continued the meeting by presenting the proposed version control mechanism, Google Code. He’s already created a repository, which can be checked out using subversion: https://code.google.com/p/gsd2012-backend/source/checkout Ev- eryone in the project have rights to check code in and out of the repository. Oscar from Team Kenya has used subversion and will introduce it to the rest of the team. Google code’s issue tracker will be used as well, and will be populated via requirements (as system enhancements) or with found defects and possibly other elements in the future. The issue tracker alerts people via the mailing list or speciﬁcally upon certain events like code changes and the like. Splitting tasks (e.g. Issues in the issue tracker) will go via management, when requirements and architecture have evolved to a mature state.

Current state : Sophia has created some requirements, which are to be discussed and enriched with Josphat. They’ll be finished hopefully today (day of the meeting) and otherwise over the weekend or first thing next week. The architectural overview will be evolved once the requirements are in a stable state - Preferably before next Wednesday. The MPesa system has been clarified via email between Mikkel and Oscar.

Overall development : Because the project requirements are ﬁxed the project will be conducted using a waterfall method.

Regarding future meetings and collaboration tracking : Team 2 Team meetings will occur less frequently as the small groups work on their initial tasks. Most likely only for major decisions and status meetings if needed. The different subteams have each their document on google docs to document what is being discussed (e.g. Management 2 Management, Architecture 2 Architecture, etc.) All

73 documents are shared, but different sub-teams don’t need to read each other’s documents. If speciﬁc info is needed it’s probably easier to ask management or via cross sub-team communication. Collaboration tracking is done via the following mechanisms: Google Docs, Mailing List (Emails), Issue Tracker - Comments or extensions to these are encouraged, if people have any good ideas.

Google Hangouts evaluation : Team Kenya: Lots of feedback to begin with, which made sound really bad - ”Push to talk” or using headsets resolved that and the most of the meeting was satisfactory. Oscar: Good way to collaborate - especially being able to share screens/docs was helpful. Some people had initial connection problems, but overall it was better than Skype.

Additions from Team Denmark : Documents shown when sharing screens ap- peared a bit small. Next time hangouts with extras is to be tried. In integrates google hangouts with google docs and a sketchpad.

74 A.15 Test Cases