GEO Localization {Final Report}
Version 1.0
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Revision History
Date Version Description Author 2019-12-18 1.0 Initial Draft Mohini Gupta, Emma Bortone, Philip Lindberg, Anton Roslund, Davide Hu, Fabio Di Silvestro, Golrokh Hamidi, Luca Ferrera, Luca Terracciano, Mattia Righetti
Page 2
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Table of content
I. INTRODUCTION ...... 5 1. Purpose of this document ...... 5 2. Document organization ...... 5 3. Intended Audience...... 5 4. Scope ...... 5 5. Definitions and acronyms ...... 6
II. PROJECT GROUP ...... 6 1. Team ...... 6 2. Supervisors ...... 7 3. Customers ...... 8
III. BACKGROUND INFORMATION ...... 8 1. Background ...... 8 2. Goal ...... 8 3. Requirements and User stories ...... 9
IV. PROJECT IMPACT ...... 11
V. PROJECT RESULTS ...... 11 1. Sequor – Go Green! ...... 11 2. Backend and Trip endpoint ...... 15 3. More details about the detection algorithm ...... 16 4. Satisfied Requirements ...... 18 5. Future improvements ...... 19 6. Installation and Usage manual ...... 19 7. Produced Deliverables ...... 20
VI. PROJECT WORK ...... 20 1. Organization and Communication...... 20
Page 3
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
2. Scrum Process ...... 22 3. Product backlog ...... 23 4. Efforts ...... 24 5. Gantt chart ...... 26
VII. PROJECT RISK AND ISSUES ...... 28
VIII. POSITIVE EXPERIENCES ...... 29
IX. IMPROVEMENT POSSIBILITIES ...... 30
X. LIST OF TABLES ...... 31
XI. LIST OF FIGURES ...... 31
Page 4
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
I. Introduction 1. Purpose of this document The purpose of the final report document is to summarize and analyse the whole development of the project “Sequor”, both in terms of the produced results and of the project work.
2. Document organization The document is organized as follows: Section I: Introduction, describes the content of this document Section II: Project group, describes the persons involved in the project and their roles Section III: Background information, describes the goal of the project with the requirements to be fulfilled Section IV: Project impact, describe the Stakeholders and users of this project Section V: Project results, provides a description of the result of the project for the frontend and the backend Section VI: Project work, provides metrics about the project development process Section VII: Project risks and issues, details the risks and issues faced during the project and how they were handled Section VIII: Positive experiences, describes what we have learnt from the project Section IX: Improvement possibilities, provides guidelines on what should be done for a similar project in order to improve the experience
3. Intended Audience The intended audience is: The development team, people who developed the solution must have full access to this document which provides a global view of the project. The supervisors, as the development team is composed by students who are supervised by professors from POLIMI and MDH, they must have full access to the document to evaluate the project both in terms of results and of project work The client, Mia Platform must have full access to this document which contains the results of the project.
4. Scope
This document summarizes the whole development of the project. This includes details on the project final results and metrics illustrating the project work on the level of the team and
Page 5
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
on the level of the team members. The final report document also analyses the correspondences and differences between what was planned in the project plan document and what actually occurred during the project course.
5. Definitions and acronyms a. Definitions
Keyword Definitions Commuter/passenger The person that is traveling on public transportation. Coupon/discount A voucher entitling the holder to a discount off a product. Trip The path travelled by commuters. A trip can contain only one type of transportation. So, if during the validity of his ticket a user uses a bus then a train, two trips will be created. Sequor Name of the system developed during this project
b. Acronyms and abbreviations
Acronym or Definitions abbreviation POLIMI Politecnico di Milano MDH Mälardalen University ATM Azienda Trasporti Milanesi CO₂ Carbon dioxide REST Representational State Transfer API Application Programming Interface JSON JavaScript Object Notation
II. Project group 1. Team The team is composed of ten members; six from Politecnico di Milano and four from Mälardalens Högskola (MDH).
Page 6
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Student Name Origin Main roles - Frontend development Anton Roslund MDH - Interlocutor linking the backend and frontend teams Philip Lindberg MDH - Frontend development - Java backend development Fabio di Silvestro MDH - SPRINT 3: Scrum master - Java backend development Golrokh Hamidi MDH - SPRINT 0: Scrum master - Product owner Luca Ferrera Politecnico di Milano - Python backend development - Mia platform expert Mattia - Python backend development Politecnico di Milano Righetti - SPRINT 2: Scrum master - Python backend development Davide Hu Politecnico di Milano - Java backend development - SPRINT 1: Scrum master - Python backend development Luca Terracciano Politecnico di Milano - SPRINT 5: Scrum master - Java backend development Emma Bortone Politecnico di Milano - SPRINT 6: Scrum master - Java backend development Mohini Gupta Politecnico di Milano - SPRINT 4: Scrum master Table 1: Project team In addition to the roles described in table 1, all members participated in the redaction of the documents and in the design choices.
2. Supervisors
This project was supervised by two teachers: one for each location. - Elisabetta Di Nitto at Politecnico di Miano. - Lorenzo Addazi at Mälardalens högskola.
Page 7
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
3. Customers The customer of this project is Mia Platform. Mia Platform is an IT company based in Italy that provides consultancy and a platform for its clients. The platform they offer provides three main suites: developer suite, runtime suite and business suite. Those suites allow their clients to build digital platforms, to automatically manage the contents of their applications, to have data and customized reports on their reality. During this project, the development team was in contact with: - Federico Oldrini: Teach Leader - Edoardo Bevilacqua: Product Owner
III. Background information 1. Background One of the most important clients of Mia Platform is Trenord, an Italian railway company responsible for the operation of regional passenger trains in Lombardy. Mia Platform helps the public transportation company to organize, centralize and exhibit data about planned and real-time routes. The project described in this document is a proof of concept. It will serve as a base for an application that will be integrated to an already existent Trenord application.
2. Goal
Public transportation in Milan desires to offer commuters an integrated ticket that allows them to travel by bus, train and underground, even if the services are provided by different companies (ATM and Trenord). For financial reasons, the companies need to know for which transportation service the commuters spend their ticket. In particular, an important metrics they are interested in is the number of kilometres the commuters travelled on the vehicles. The goal of this project is to develop proof of concept for a system destined to commuters and public transportation companies. This system should provide a gamification on carbon credits that rewards commuters with discounts and it should provide an interface for the companies to retrieve the data of the commuters’ trip. The carbon credit gamification part should be accessible by everyday users through their mobile device. The interface for retrieving data must be accessible only by the authorized public transportation companies.
Page 8
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
3. Requirements and User stories
The following table (table 2) shows the functional requirements of the project. Each requirement has an identifier and a brief description.
Functional Requirements ID Description R1 The application displays the total amount of CO2 a passenger has saved by using public transportation. R2 The application rewards the passenger with a coupon when he/she saves enough CO2. R3 The application displays information about the coupon to the passenger. R4 The passenger can redeem a coupon. R5 The application notifies the passenger when he/she gets a new coupon to use. R6 The application starts tracking the passenger when a ticket is activated. R7 The application stops tracking the passenger when the ticket expires. R8 The system recognizes the type of public transportation the passenger is using. R9 The system allows public transportation companies to retrieve data about the trips. Table 2: Functional requirements
The following table (table 3) shows the non-functional requirements of the project. Each requirement has an identifier and a brief description.
Non-Functional requirements ID Description NR1 The system has to be deployed on Mia Platform. NR2 The programming languages that can be used to develop the backend are Java, Javascript, Go and Kotlin. NR3 The data have to be stored in MongoDB database. NR4 The application must be compatible with Android or IOS. Table 3: Non-Functional requirements
The following table (table 4) focuses on presenting the user stories in the scope of SCRUM- based Agile Software Development.
Page 9
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
User stories ID Req Description Priority ID US1 R1 As a passenger I want to know how much CO2 I saved High by using public transport US2 R2 As a passenger I want to be rewarded with a coupon High after using the application so that I can redeem them and take advantage of the discounts it offers. US3 R3 As a passenger I want to see details of the coupons I Medium have earned so that I know what the coupon gives. US4 R4 As a passenger I want to be able to redeem a coupon Low so that I can get a discount US5 R5 As a passenger I want to be notified when I have Low earned a new coupon so that I know I have a new coupon to use US6 R6 As a public transportation company, I want passengers' High trips to be tracked when they activate their tickets so that the mode of transportation can be classified. US7 R7 As a public transportation company, I want the High application to automatically stop tracking a trip after the ticket expires so that only necessary data is collected. US8 R7 As a passenger user I want to the application to High automatically stop tracking a trip after the ticket expires so that I can save device battery. US9 R8 As a public transportation company, I want to have the High transportation mode for trips classified so that I have data for a revenue share model between public transportation companies US10 R9 As a public transportation company, I want to be able Low to retrieve trip data about the users so that I can use those data for business analytics. Table 4: User stories More details about the requirements and user stories can be found in the document Requirement_Definition_v1.01 available at: https://studentmdh-my.sharepoint.com/:f:/g/personal/ard15003_student_mdh_se/En_G2dL- 1chPtfe4tnMafMIBBfGT84SXe0psmaqEcX4ErA
Page 10
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
IV. Project Impact
Geo-localization project is destined to be used by: • The users of the public transports in Milan. They must have an integrated ticket that is valid for 90 minutes provided by the Trenord application and they must give the permission to be tracked when using a public transport, as the main goal of the system is to detect whether a user is on a bus/tram or a train. This will lead to less information privacy and more effort for the user. To overcome this problem, the system provides discount to the user based on the CO2 that the user has saved by using the public transportation instead of cars. • The public transportation companies, Trenord and ATM. The Public Transportation companies will use the system to retrieve data about trips to examine whether a trip was made by a bus/tram or a train or both.
V. Project Results
The project is developed considering all the functional and non-functional requirements, and the User Stories described in the Requirement_Definition_v1.01 document. The main result of the project is the Sequor iOS application for the Milan Public users, and the Trip Endpoints through which the details of the trips can be fetched by the Public Transportation companies. 1. Sequor – Go Green!
Our iOS mobile application is intended for the Milan Public users to take as many trips using
Page 11
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
the Public Transport, therefore helping to prevent the climate change by saving CO2 and earning discount coupons. The app is designed to integrate into the Trenord application used by the Milan Public users to buy Urban Ticket that is valid for 90 minutes. The Trenord app uses a tab bar interface. We suggest our feature to be added as a tab in the tab bar interface. In the form of a dashboard tab. After a user has purchased a ticket from the Trenord application, they can activate a ticket using an “Activate ticket” button as shown in the Figure 1.
Figure 1: Deactivate ticket Figure 2: Invalidate ticket
The main feature of the project is to detect the distance a user travels by each public transportation type (bus, tram and train) in each journey. The application records the GPS coordinates of the user during his/her trip. The Urban ticket is valid for 90 minutes, so the ticket gets expired after 90 minutes and the GPS recording is stopped. The user can manually “Invalidate ticket” as well. (Figure 2)
Page 12
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Furthermore, users can easily view their real time tracking in the map as shown in the figure 3. The application distinguishes the activity of the users with different colours, when he/she is walking the path is coloured by Green, when he/she is on a vehicle the path is coloured by Blue, as shown in the figure 3.
Figure 3: Activity detection
The most interesting part of the application is the Tree Gamification. In the main dashboard view, the CO2 is represented by a growing tree. (Figure 4) The tree would start out as a sapling but would grow as the user saves CO2 by taking trips using the public transport in Milan. When enough CO2 is saved a coupon will grow on the tree that then can be tapped to be claimed/used. The coupon is in the form of a fruit. Tapping a coupon will bring up details of the coupon, with options to use or discard the coupon as shown in the figure 5.
Page 13
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Figure 4: Growing tree
Figure 5: Coupon use
Page 14
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
This approach of saving CO2 and seeing your tree grow could serve to motivate more people to use the application, and possibly even those who aren’t motivated to use it just for earning discount coupons.
2. Backend and Trip endpoint
The backend is composed of two main components, Business Logic backend and Detection Algorithm. Mia Platform offers large varieties of tools to develop, design and deploy application. As the backend is deployed on Mia Platform, all the components are accessible for the clients to make use of them. • Business Logic Backend: This part of the backend is created for Trip, Wallet, and Coupon management. The programming language use to develop is Java. • Detection Algorithm: This part of the backend is created to detect the transport type in a user trip. This was developed using Python. • Trip Endpoint:
This interface is invoked by an HTTPS GET request and it allows public transportation companies to retrieve all trips stored in the database.
This interface is invoked by an HTTPS GET request and it allows public transportation companies to retrieve all trips with a specific means of transportation stored in the database.
• Statistics Endpoint:
Page 15
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
This interface is invoked by an HTTPS GET request and it allows public transportation companies to retrieve the total number of kilometers travelled with each mean of transportation by user or by user and ticket.
More details about all the interfaces of the system can be found in the document Design_Description_V4.
3. More details about the detection algorithm
The detection algorithm is developed in Python. This service is responsible for the mean of transportation detection (distinction between bus/tram and train) and the calculation of the distance travelled by the user.
The detection algorithm will only receive trip data that are for sure detected to be on an automotive vehicle by the Sequor application. Indeed, the front end uses machine learning techniques to recognize if a user is “walking”, “stationary” and “automotive”. The front-end application will group trip data and segment them whenever the user is walking. For instance, if a user travels first by bus and then he walks to a train to reach his/her final destination, Sequor will first gather bus data which are recognized to be on an automotive, then, since the user has to walk to a train, the app will immediately know that the user ended his first sub-trip and will send that first part to the backend app. When the user finally arrives to the train and travels to his destination, the front-end application will gather those trip data, which still are recognized as on an automotive and send them to the back end. So, as a user must inevitably walk between two different means of transportation; the backend will necessarily receive trips containing data about one and only one mean of transportation.
To detect if a trip was made by bus, tram or train the algorithm performs the following main steps: 1. Assume that the trip was made on a bus or tram, then calculates the number of kilometres travelled and a compatibility parameter 2. Assume that the trip was made on a train, then calculates the number of kilometres travelled and a compatibility parameter 3. Compares the two compatibility parameters to determine if the trip has most likely been made on a train or on a bus/tram.
Page 16
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Details about step 1 and step 2: • The input of the step 1 is the GPS data sent by the device after being processed by the SnapToRoad API by Google Maps. • The input of the step 2 is the raw GPS data sent by the device.
For the steps 1 and 2 the algorithm the algorithm performs the following operations: • Searches the bus stops/train stations close to the first point and the last point of the GPS data received as input. • Finds the bus/train lines that contain those two stops. • Computes polygons starting from the points between the two stops (see figures 6 and 7) • Checks which points of the user's trip are inside the polygons and compute the distance and the compatibility parameter.
Figure 6: Public transport line Figure 7: Polygons
A more detailed description of the algorithm can be found in the notebook at https://gitlab.partners.mia-platform.eu/partners/polimi/notebookalgorithm and in the document Design_Description_V4.
Details about the accuracy: The accuracy of the results depends on the quality of the GPS data sent by the device. The tests results show that the algorithm was able to detect the correct mode of transportation for 70% of the trips. The main causes of error were encountered whenever a train or bus route was not in the dataset retrieved from OpenStreetMap.
Page 17
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Concerning the computation of the distance travelled, there’s always a small percentage of error that in most cases can be discarded and the distance can be considered accurate enough.
4. Satisfied Requirements
There are in total 9 Functional Requirements and 4 Non-functional requirements. We have covered all of them. The functional requirement R5 is developed on the front-end and didn’t had any support from the backend (see tables 5 and 6)
Functional Requirements ID Description Priority Implemented The application displays the total amount of CO2 a R1 passenger has saved by using public transportation. High 100% The application rewards the passenger with a R2 coupon when he/she saves enough CO2. High 100% The application displays information about the R3 coupon to the passenger. Medium 100% R4 The passenger can redeem a coupon. Low 100% The application notifies the passenger when he/she R5 gets a new coupon to use. Optional 50% The application starts tracking the passenger when a R6 ticket is activated. High 100% The application stops tracking the passenger when R7 the ticket expires. High 100% The system recognizes the type of public R8 transportation the passenger is using. High 100% The system allows public transportation companies R9 to retrieve data about the trips. High 100% Table 5: Functional Requirements coverage
Non-Functional requirements ID Description Implemented NR1 The system must be deployed on Mia Platform. 100% The programming languages that can be used to develop the NR2 100% backend are Java, Javascript, Go and Kotlin. NR3 The data have to be stored in MongoDB database. 100% NR4 The application must be compatible with Android or IOS. 100% Table 6: Non-functional requirements coverage
Page 18
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
5. Future improvements
Tracking the user in the metro train is a feature that could be added to the application in the future. At this time, a metro trip can be easily recognized because the users are forced (by the architecture of the underground architecture) to tap their ticket when entering and exiting the metro. As the detection of a metro trip does not need the use of a detection algorithm, this mode of transportation is not considered in this project. If the public transportation companies provide beacons in their vehicles, it would be possible to use the beacons to track the presence of the user in the vehicle, so there would be no need for the user to manually start and end the trip. Improve the size of the dataset of both trains and buses, in this way it will be possible to detect trips with a higher accuracy than now.
6. Installation and Usage manual
The frontend application is distributed as a private beta and can for the time being be accessed using the following link: https://testflight.apple.com/join/DmwBYjtW. To install the application: 1. An iOS device is required 2. Download and install TestFlight from App Store 3. Open your invitation email or tap on the public link on your iOS device. 4. Tap View in TestFlight or Start Testing; or tap Install or Update for the app you want to test. Detailed installation instruction is provided when accessing the link. Manual installation is possible but not recommended, a payed Apple Developer account is required.
The backend uses Google Road API for data pre-processing the Bus and Tram trip data. To get an accurate result for the Detection Algorithm as mentioned before, we need an API Key to use Google Road API. The API key is a unique identifier that is used to authenticate requests associated with your project for usage and billing purposes. Following are the step one needs to follow to acquire the API key and to paste it: • Before proceeding with the steps remember to create a billing account in Google Maps Platform. (https://developers.google.com/maps/gmp-get-started) • Go to the Google Cloud Platform Console. • Create a new project and select APIs & Services>Credentials from the menu button • On the Credentials page, click Create credentials > API key.
Page 19
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
• Copy the newly create API Key under API key created dialog or from the Credentials page under API keys. • Paste it in the Backendgeolocalization repository that handles the trip data, i.e. in the method name snappedToPoints inside the TripService.java. The path to TripService.java: backendgeolocalization\src\main\java\eu\miaplatform\customplugin\springboot\trip\Tri pService.java
7. Produced Deliverables
Documents Date 1 Project Plan v1 25-10-2019 2 Requirements Definition v1.01 08-01-2020 3 Design Document v4 10-01-2020 4 Test Plan v1.1 11-01-2020 5 Minutes of Meeting (17) Every Monday and Tuesday 6 Sprint Retrospective (5) End of Sprint 7 Sprint Backlog Trello board 8 Test Report 17-01-2020 9 Final project report 17-01-2020 10 Final product 17-01-2020 Table 7: Produced deliverables
VI. Project Work 1. Organization and Communication a. Daily
Initially, we decided to do daily Scrum meetings, but it was skipped as we communicated every day on Slack. Following channels were created and used for different purposes: • #general: for all the information, questions, and comments about our project • #announcements: for all the general announcement, deadlines to fulfil • #links: for all useful links helpful for our project • #supervised: for the communication with our Supervisors • #development: for the front-end development communication • #lecture: for communication during lecture hours • #testing: for communication regarding testing efforts • #peer-review: for the results of the intermediary assessment
Page 20
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
In addition to these, there were channels created for the different sub teams. And, Direct messages are used for one-to-one communication.
b. Meetings
• Team meeting: The team meetings are held on Monday and Tuesday at 17.00 via Skype. • Supervisor meeting: The meetings with Supervisor are held on Monday at 16.00 via Skype. • Customer meeting: Communication with the customer are done by our Product Owner, Luca Ferrera, who also works at the Mia Platform.
c. Tools
Communication Tool Purpose Product Backlog, Sprint Backlog, Sprint Review, Effort Trello estimation Office Online Documentation, Slides Skype Meetings Slack Daily communication and discussion about development Gitlab Backend development Github Frontend Development Table 8: Communication tools
d. Statistics
Following are the analytics of Geo-localization Slack taken as of until 16 January 2020. • Total Messages sent: 8835 messages • Daily Active Members: see figure 8
Page 21
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Figure 8: Daily activity on Slack
2. Scrum Process a. Scrum roles We have three roles in the team; Scrum Master, Project Owner, and the team. The Scrum master will change each spring while the Product Owner is constant. We have total 6 sprints and a total of 6 Scrum master. b. Sprint planning All the sprint is 2 weeks long since the size of the team is big (10 people) and the team is distributed in two locations, except Sprint 5. The duration of Sprint 5 was 3 weeks, because of the Holiday week and most of us were not available during that time.
At the beginning of each sprint, that is, on Tuesday the team meet for the Sprint Planning Meeting. At the meeting, items with the highest priority in “Product Backlog” Trello board are taken into consideration and move to the Sprint backlog Trello board. Task are assigned on a voluntary basis and proactivity. All the task in the Sprint Backlog are equally divided among team members. Task information was written to Trello and everything was recorded in our Minutes of Meeting during the meeting so all information could be available to team members
During Sprint, each member assigns a Story Point in the form of Fibonacci numbers to indicate the estimated time or effort needed to do that specific task, and gives a final time spent to do that task when it is completed.
Meetings with Supervisor are held on Monday at 16.00 to discuss the progress about the overall development. The comments made by the Supervisors are discussed on Monday at 17.00. In addition, we discuss about the progress of each team members.
Page 22
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
c. Sprint retrospective Before starting with Sprint planning on Tuesday, it is necessary to do the Sprint Retrospective. Each team members gives opinion about what went well and what went bad. Then we discuss about how to improve and the ideas generated are assigned to team members.
3. Product backlog
Sprint Backlog Item Description Vehicle Detection 1 Map Matching Match the location of the user to the map 1 Data Structure for Data Routes Determine the data structure for the routes 2+3 Bus/Tram Trip Detection Be able to detect when the user is traveling by bus or by tram 5+6 Train Trip Detection Be able to detect when the user is traveling by train - Underground Metro Trip Detention Be able to detect when the user is traveling by metro. This item was not implemented. Collecting Data 3 Tracking 3+4 Use ML to detect user activity to segment With the help of machine learning be able to trips distinguish between different modes of travel 4 Ticket Expiration/Stop tracking Stop tracking when the ticket expires Gamification 3+4 CO2 Saved Gamification Display the CO2 saved in the form of a tree that grows as more CO2 is saved KM and CO2 3 KM Calculation Calculate the distance traveled each trip - Trip History This item was not implemented 4+5 CO2 Saved Calculation Calculate how much CO2 is saved per kilometer based on the mode of transport Wallet 4 View Coupons Have the user be able to view the coupons they have earned by using the application 3 View CO2 Have the user be able to view the total amount of CO2 they have saved while using the application 5 Redeem Coupon Have the user be able to redeem one of the coupons that they have earned 5 Coupon Notification Send a notification to the user when a new coupon has been earned Table 9: Product Backlog During each sprint planning phase, the backlog items were broken down into smaller more refined tasks and then moved to the sprint backlog.
Page 23
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
4. Efforts a. Meeting hours per Sprint
Figure 9: Meeting hours per Sprint
b. Team time investment per sprint Total working hours per sprint 300
250
200
150
100
50
0 Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Figure 10: Total working hours per Sprint
Page 24
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
c. Total working hours per team member per sprint
Figure 11: Working hours per team member per Sprint
d. Total working hours per team member Total working hours per team member 180 154,5 160 140 143,25 142,5 140 109 110,95 120 102,75 104,45 105 96,8 100 80 60 40 20 0 Hours
Anton Davide Emma Fabio Golrokh Luca F Luca T Mattia Mohini Philip
Figure 12: Total working hours per team member
Page 25
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
e. Sprint estimated versus effective effort
For the Sprints 1 to 3 the effort estimation was made using T-shirt sizes (S / M / L). So, no comparison between estimated and effective effort is possible for those sprints. In the sprints 4 to 6 we can observe that the estimation was relatively close to the effective effort, this is due to the fact that by the fourth sprint we had already acquired some experience in evaluating tasks effort.
Sprint Effort 140
120
100
80
60
40
20
0 Sprint 4 Sprint 5 Sprint 6
Effective Estimate
Figure 13: Comparison estimated and effective effort
5. Gantt chart
In figure 14 shows the original time plan from the project vison plan in the form of a Gantt chart. The actual time spent can be seen in figure 15. We can see that the plan was followed successfully with some minor variations.
Page 26
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Figure 14: Original Gantt chart
Page 27
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
Figure 15: Actual Gantt chart
VII. Project risk and issues
In the project plan, nine project related risks where identified along with a plan for mitigation. How the risks were managed are displayed in the table below (table 10)
ID Risk description Planned mitigation Outcome 1 Selection of inappropriate Literature review of the topic, Mitigated successfully. Had no major geo-localization brainstorming, customer issues with the chosen geo-localization technology validation/approval technology 2 Lack of experience with Strong interaction inside the team Lack of experience with using the MIA- the development to share knowledge, self-learning platform proved to be an issue especially technologies as there was a lack of proper documentation 3 Unsafe application process Use Case simulation, customer There were no major issues that allows the user to use validation/approval intentionally the application in a malicious way 4 Low communication Fixed meeting days for the team, This risk was well mitigated as there between the team frequent communication within were active communication within the members the sub-teams, use of Slack and team. The fixed weekly meetings also Skype proved useful for keeping everyone on the same page 5 Inaccurate estimation of Proper discussion during the The estimated of workloads generally the workload Sprint varied from the actual workload, but the estimations were never too far off to be an issue
Page 28
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
6 Imbalance in the workload Use of Trello for assigning tasks, Even though some team members among the team member team agreement when assigning worked more than others, it the tasks workload where generally balanced and it was never a major issue 7 Changing Scrum Master Sharing the gained knowledge There were no major issues with after every Sprint between the old and the new changing the scrum master each sprint Scrum master in order to avoid but keeping the same scrum master experience loss during the entire project would probably have been a better solution. The experience from one scrum master to the next didn’t efficiently carry over between the sprints, still there were some positives with our system as more team members got to experience what it’s like to be a scrum master 8 Lack of non-functional Features testing before the release There were no major issues requirements (performance, reliability, security) 9 Miss a deadline Use of Trello, team Risk mitigated successfully as no (presentation, communication, team help deadlines where missed documentation, prototype) Table 10: Risk management
VIII. Positive experiences
There were many positive experiences to take away from the course. A major part was of course the distributed nature of the development process with an international team. While not being able to communicate as efficiently as one would with a local team, everyone got used to it eventually and it proved to be a fun and valuable experience. The team communication and coordination in the end turned out to be very successful and there were no issues with time management or missed deadlines.
Working on a real project with a real customer was also a positive experience. Getting to encounter and learn new tools and technologies, while not always going smoothly, was if nothing else a good learning experience. Using the Scrum development methodology and getting experience with it was also a positive, and a major positive with the general project was that we managed to fulfil all the original requirements.
Page 29
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
IX. Improvement possibilities
The project was overall successful, but there are always some things that could have been done better.
One of the biggest changes we would make is related to the choice of technologies. Working with the MIA-platform proved to be very challenging due to no prior experience with the platform as well as a lack of documentation. Generally, there were also a lot of time spent on learning new technologies, which is a positive to a degree, but the time spent on development instead of learning could have been reduced to some degree. Therefore, we would in case of a redo only select technologies that at least some of the group members already have experienced with.
Some aspect of the work could have made more efficient if we were to have used a specialized tool for project management. In retrospect it would also have been good to divide areas of responsibility sooner than what we did. Another potential change could be to have the same scrum master during the whole project. Changing scrum master each sprint had some benefits as more team member got the experience, but overall the consistency gained from having the same scrum master would probably have been better for the project overall.
Page 30
Geo Localization Version: 1.0 {Final Report} Date: 2020-01-10
X. List of Tables
Table 1: Project team ...... 7 Table 2: Functional requirements ...... 9 Table 3: Non-Functional requirements ...... 9 Table 4: User stories ...... 10 Table 5: Functional Requirements coverage ...... 18 Table 6: Non-functional requirements coverage ...... 18 Table 7: Produced deliverables ...... 20 Table 8: Communication tools ...... 21 Table 9: Product Backlog ...... 23 Table 10: Risk management ...... 29
XI. List of Figures
Figure 1: Deactivate ticket Figure 2: Invalidate ticket ...... 12 Figure 3: Activity detection ...... 13 Figure 4: Growing tree ...... 14 Figure 5: Coupon use ...... 14 Figure 6: Public transport line ...... 17 Figure 7: Polygons ...... 17 Figure 8: Daily activity on Slack ...... 22 Figure 9: Meeting hours per Sprint ...... 24 Figure 10: Total working hours per Sprint ...... 24 Figure 11: Working hours per team member per Sprint ...... 25 Figure 12: Total working hours per team member ...... 25 Figure 13: Comparison estimated and effective effort ...... 26 Figure 14: Original Gantt chart ...... 27 Figure 15: Actual Gantt chart ...... 28
Page 31