Final Project 2016 Drive - Heim | Skemman · 2019-08-30 · and the team to maintain a healthy...

REYKJAVÍK UNIVERSITY

Final Project 2016Drive

Fanney SigurðardóttirHelgi Rúnar Einarsson

Hrafn Orri HrafnkelssonKristinn Þorri Þrastarson

15. December 2016Advisor: Sigurjón Ingi Garðarsson

Contents

I Introduction 5

Introduction 61.1 The Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 TM Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 The Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II Organization and Schedule 8

Organization and Schedule 92.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Working Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Working Hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Team Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 Working Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Scrum Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Project Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Project Capacity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Development Capacity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.3 Sprint Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

III Risk Analysis 14

Risk Analysis 153.1 About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Initial Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Occurrences and Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1

IV Requirement Analysis and Design 18

Requirement Analysis and Design 194.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.2 User Interface Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.3 Navigational Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 User Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.1 User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.2 User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.3 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.4 Usability Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Technical Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.1 Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.2 Back End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.3 Continuous Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4.4 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4.5 Coding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

V Progress and Changes 36

Progress and Changes 375.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.1 Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.3 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.4 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.5 Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.6 Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.7 Sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.8 Sprint Retrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Time Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

VI Testing 46

Testing 476.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2

6.3 Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.4 Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.5 Capacity Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.6 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.6.1 Admin Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.6.2 Manager Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.6.3 Employee Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.6.4 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VII User Instructions 50

User Instructions 517.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.2 Employee Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2.1 Creating A User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2.2 Sign In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2.3 Get Car Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2.4 Add Car To A Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.5 Sign Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Manager Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3.1 Android Trackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3.2 Accessing Management Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3.3 Add Car To A Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.3.4 Create A Car Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.3.5 Remove A Car Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.3.6 Accept Employee Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.3.7 Promote Employees To Managers . . . . . . . . . . . . . . . . . . . . . . . . 617.3.8 Remove Employee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

VIII Operations Manual 63

Operations Manual 648.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.2 Administrators Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2.1 Create an Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.2.2 Creating a Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.2.3 Removing a Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3 Developer Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688.3.1 Development Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 688.3.2 Programming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3

8.3.3 Project Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.3.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.3.5 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

IX Conclusion 79

Conclusion 809.1 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809.2 Future Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

X Appendix 81

Appendix 8210.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8210.2 Sprint Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8610.3 Think Aloud Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.3.2 Test format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.4 Time Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4

PART I

INTRODUCTION

5

INTRODUCTION

This reports outlines the development and documentation of the project Drive. The project isa Final Project for the University of Reykjavik and is worked in collaboration with TM Software.TM Software was interested in developing Drive as a part of a series of solutions for the travelindustry.

1.1 THE TEAM

The team consists of four third-year students in the Computer-Science division of ReykjavikUniversity. Fanney Sigurðardóttir, Helgi Rúnar Einarsson, Hrafn Orri Hrafnkelsson and KristinnÞorri Þrastarson. The team has worked together for quite a while on other projects and havebeen very satisfied with the results. Therefore the team was confident when deciding to worktogether on this final project.

1.2 TM SOFTWARE

TM Software is a well established and a leading software company in Reykjavik, Iceland. Assuch, it specializes in production of software as well as consultancy and services within mostindustries. TM Software employs over 70 specialists in three departments. Travel solutions, Websolutions and Health Care solutions.

1.3 MOTIVATION

TM Software has been developing new and innovative solutions through the years, whilemaintaining and developing their more known long-term products. Responding to marketchanges, TM Software decided to have a dedicated Travel solutions team. The project Drivebecame an established idea while exploring innovative solutions in the Travel industry. TMSoftware aims to maintain a connection with the university community and therefore it wasconsidered to be a perfect opportunity to use this product as a final project.

6

1.4 THE PROJECT

During the final project’s development, the team handed in reports and manuals over an iterationof three status meetings. The reports helped the over-viewers keep track of the team progressand the team to maintain a healthy overview of the project’s status. Organization and planningwas done in the beginning of the project, as well as requirement analysis and design. Creatingdocumentation on these subjects became very beneficial as the project developed and thisreport describes the tools and techniques that the team used during both analysis anddevelopment. The team met an adviser weekly, Sigurjón Ingi Garðarsson. He gave the teamgreat insight about how to maximize performance using the Scrum methodology which boostedthe project’s management considerably.

1.5 THE PRODUCT

Drive is a web application that will function as a dashboard and a vehicle fleet observationsystem. Car rentals and companies alike can be served with an overview of the current status oftheir fleet, as well as accumulated data over time.

Car rental companies in Iceland do not monitor their vehicles after the customer is handedthe keys and drives off. Most vehicle fleet management system are very expensive and requirespecial permissions from the actual driver of the vehicle. Also, these systems mostly focus onlowering expenses for their customers by lowering gasoline consumption with route optimization.Solutions that do not factor into car rental companies expense structure.

Drive focuses on giving accurate information about the car fleet’s behaviour. Car rentalscan then know if any cars are driving in forbidden areas, see the most popular stops as well asgive their customers warnings about environmental changes in their surroundings.

Drive is entering a new turf in an already established market here in Iceland. Trackwellrespectively seems to have the largest part of the market, however Drive has a slightly differentfocus, which attracts new customers to the market.

7

PART II

ORGANIZATION AND SCHEDULE

8

ORGANIZATION AND SCHEDULE

2.1 INTRODUCTION

The organizational planning and scheduling of the project was done in the first two weeks. Theteam decided to document the decisions that were made about working hours, meetings andoverall development methods and techniques. Furthermore, the team analyzed the productand created a project backlog that listed the preliminary requirements for the product. Therequirements were written as user stories, i.e. tasks that a particular user should be able toperform and why, and the user stories were divided into periods using an initial capacityestimation. The following sections outline the principal structure of the organization of theproject.

2.2 WORKING CONDITIONS

2.2.1 WORKING HOURS

The team decided to split the semester into two segments. The first twelve weeks of the projectincluded about 70% of the project, where each team member spent around 18 hours per weekworking on the project. The remaining 30% of the project spanned over three weeks were eachteam member was estimated to spent around 28 hours per week, but ended up closer to 50hours per week.

The team scheduled one whole day and two half days where they would meet and work atTM Software and actually spent most of their working hours on location. TM Software providedthe team with excellent work spaces where the team could work closely together and haveaccess to support from the company.

2.2.2 TEAM COMMUNICATION

The team had worked together before and have mostly preferred face-to-face communication.Nevertheless, some communication were conducted online, and the team chose to use Slack forthose communications. Slack allows for good organization of topics and makes it easy to sharecode snippets and links. All members had used it before so no learning period was needed andit helped the team keep communications clear and organized.

9

https://slack.com/

2.2.3 WORKING AGREEMENT

During a project like this the team felt it was important to have a common working agreement.The agreement was assembled and agreed upon by all team members and was only changedif all members agreed. The list was also used as a guideline during the retrospective meetings.The list started small but grew a little as the project progressed. During the end of the projectthe list went as follows:

• Be on time, most importantly for the Scrum Meetings.

• Raise issues early.

• Don’t dismiss other’s opinions.

• Try Google before disturbing a working team member.

• Checkout tasks you are working on.

• Run pre push checks before pushing to Git (Jenkins).

• Notify all team members before cleaning or changing the database (preferably using Slack).

2.3 METHODOLOGY

The team felt that it would be very important to use good techniques and protocols duringdevelopment. After diving into various methodologies the team felt that they were mostcomfortable with Scrum. The Scrum methodology essentially follows agile principles for softwaredevelopment. Since the team did not have much former experience with any of the methodologies,it was decided to use the following methods, mostly from Scrum.

For user analysis, User Roles, Personas and User Stories. For requirement analysis, Product-& Sprint Backlogs. For organization and team dynamic, Sprint planning meetings, Sprints (2weeks, 3 work days per week), Daily scrum meetings, Sprint Review meetings, Burndown chartsand Retrospective meetings.

2.3.1 SCRUM ROLES

The team had worked together before and had already started to show an inclination towards acertain team structure. However, the only specified and non-changing roles that were used arethe Product Owner and Scrum Master.

During the project the team had access to a representative from TM Software, Steinar AtliSkarphéðinsson. He was designated the Product Owner for Drive since he is actually workingon the marketing and branding for the product. The team decided that Kristinn Þorri, wouldbe the team’s Scrum Master. He has a good working relationship with the company, as wellas, the Product Owner. He also has good knowledge of Scrum and all the organizational tools

10

https://slack.com/

used during this project. The Scrum Master spent around 25% of his scheduled time setting upmeetings and organizational data and keeping in touch with the Product Owner.

Other team members are Fanney, Helgi and Hrafn Orri. They were not classified into anyspecific roles. All members were responsible for logging their own times, although they mayhave gotten a few friendly reminders from the Scrum Master.

2.4 PROJECT BACKLOG

The product backlog is a list of User Stories for the product. The backlog does not contain thetasks included in Sprint 0 because those were mostly analysis, deciding on which stories to takeon and defining the project itself. The backlog does however have a list of ’other’ stories thatdefine the tasks needed to setup the development environment that the team decided upon inSprint 0. The other stories are meant as tasks that are not adding any value to the product butare instead helping development of the product. These tasks are going to have a high priority inthe development process because the earlier they are completed the easier tasks in the productbacklog become.

Each story has an ID, it is not meant as an order of any kind but simply an identifier for theteam to be able to reference a particular story when needed. The stories are written from theperspective of a particular kind of user, describing a task he wants to perform and why (UserRoles are described in section 4.3.1). Each story also has a priority value. The values are A,B, C, where A are the must have features, B is for important features and C is for nice to havefeatures. Each story is then given a story point estimation, which is a time estimation relativeto a task that the team knew the scope of. The product owner has final say on all changes tothe product backlog. Whether they are changes to stories themselves or just their prioritisation.The complete project backlog is included in appendix 10.1.

2.5 SPRINT PLANNING

For the development of Drive, the project was divided into sprints and the team set themselvesdeadlines for each specific feature. At the end of each sprint, all work during that sprint shouldbe finished and the product ready to ship with those features. By using this approach the teammanaged to keep the project live from the moment the deployment pipeline was finished, rulingout all deployment related errors during the development process, rather than at the end of it.

For the sprints during the development phase the team decided to keep the estimationof team capacity and story points as simple as possible. The team capacity was estimated inhours and each sprint was planned by choosing stories from the product backlog that the Scrummaster and the team felt could fit into each sprint. Each team member was responsible forlogging their time to the correct task during their work period, so more accurate estimationscould be performed in future sprints.

11

2.5.1 PROJECT CAPACITY PLAN

A capacity plan was estimated by evaluating the number of hours that each team memberwould contribute both to the development of the product, as well as other tasks, such as meetingsand reports. The following table shows how time was divided into sprints and days during theproject:

Sprint Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Total0 32 24 24 32 24 24 0 1601 32 24 24 32 24 24 0 1602 32 24 24 32 24 24 0 1603 32 24 24 32 24 24 0 1604 32 24 24 32 24 24 0 1605 32 32 32 32 32 32 32 2246 32 32 32 32 32 32 32 224

Total: 1248

Table 2.5.1: Project Capacity Plan

2.5.2 DEVELOPMENT CAPACITY PLAN

A capacity plan was estimated by evaluating the number of hours that each team memberwould contribute to the development of the product. The Scrum Master spent less time developing,i.e. about 20% of his time went into planning meetings and sprints. All team members spenttime doing reports and attending meetings so it was estimated that 60% of their time would gointo development.

Sprint Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Total0 18 13 13 18 13 13 0 881 18 13 13 18 13 13 0 882 18 13 13 18 13 13 0 883 18 13 13 18 13 13 0 884 18 13 13 18 13 13 0 885 18 18 18 18 18 18 18 1266 18 18 18 18 18 18 18 126

Total: 692

Table 2.5.2: Development Capacity Plan

12

2.5.3 SPRINT BACKLOGS

After estimating the time it would take to finish each user story and how much time the teamactually had during the semester, the team planned each sprint. For each sprint the team chosestories that would fit approximately into one sprint and would not depend on anything that hadnot been developed.

It was estimated that the capacity of the team could cover all but one story. ThereforeStory 16 was not included in the sprint backlogs as it was decided by the Scrum Master andProduct Owner that the effort was to high compared to the importance of the story.

The original sprint backlogs were only an educated guess as to how much could be doneduring each sprint. Nevertheless, the backlogs did not require much modifications. Duringsprint 3 the team decided to move Story 2 to sprint 4 due to outer effects on capacity duringsprint 3. This had the following effects on the sprint backlogs to prevent overestimation on thecapacity of the group. Firstly, story 6 was moved from sprint 4 to sprint 5, story 13 was movedfrom Sprint 5 to Sprint 6 and story 18 was removed from sprint 6. However during the sprintplanning meeting of sprint 6 the team decided to add Story 18 and 32 to the sprint due to howwell the previous sprint went. Story 32, change languages, was new to the project backlog, butwas low risk as the project already had string management.

The sprint backlogs are included in appendix 10.2.

2.6 CONCLUSION

The team feels that the organization and planning was very successful. The tools and techniquesused were highly effective and the team also feels that the work done during the initial stages ofthe project were extremely beneficial to the whole development process.

13

PART III

RISK ANALYSIS

14

RISK ANALYSIS

3.1 ABOUT

The team analysed risks that would be most likely to disrupt or kill the project. The risksprobabilities and impact were estimated using Fibonacci numbers relative to the other risks.High numbers mean high impact/probability and low numbers mean low impact/probability.The risk factor was then calculated by multiplying the risk’s probability and impact. Each riskwas assigned a guarantor that was responsible for responding if the risk became a reality andapplying some remedy (if applicable) that would lower the impact.

The team feels that the making of the risk analysis definitely increased the response timewhen dealing with issues. Knowing that the risks had been identified and given a guarantorgave the team a sense of security and confidence. Furthermore, since team members weremade responsible for devising a plan for dealing with the risks, should they occur, many riskslost their impact as the project progressed, since solutions to the problems had already beenthought of. The initial risk analysis follows.

15

3.2 INITIAL RISK ANALYSIS

The initial risk analysis suggested that the project was very unlikely to fail. I.e. most of the risksassociated with the project were unlikely to happen. Nevertheless, the relatively likely onescould potentially fail the project if they all happened. It was estimated that the bus factor forthe project was 3, since two members could likely finish a minimum viable product on theirown.

16

3.3 OCCURRENCES AND RESPONSES

During the project’s development the team reevaluated the risks. During the first few sprintsthe development was mostly related to research, reports and building a development pipeline,but after Sprint 4 the team felt that some changes should be made to the risk analysis. Firstly,the team quickly dealt with the fact that the Here Maps component that the project was usingdid not contain all the functionality that was needed. After the map component had beenswitched for another one the team felt that the impact for losing the map component shouldbe considerably less, since it was not difficult to replace. Secondly, the risk for time consumingassignments in other courses was removed, since all other classes were finished. Thirdly, theprobability and impact of TM Software not being able to house the team were lowered. Bothbecause the team has a very good relationship with the company and also because the impactwould be less because of the short amount of time left of the project. Lastly, the impact forsickness was increased since only two sprints were left and losing a team member to sicknesscould have considerable impact on development. The revised risk analysis.

17

PART IV

REQUIREMENT ANALYSIS AND DESIGN

18

REQUIREMENT ANALYSIS AND DESIGN

4.1 INTRODUCTION

This part elaborates on the requirement analysis for Drive, as well as how the team plannedto fulfill those requirements. The sections are split into design, user analysis and technicalenvironment. The design section goes over the preliminary designs and how they changedduring development. The user analysis briefly goes over the kind of users the team expectedto be using the system, and the technical environment aims to give an overview of the maintechnologies used in the making of Drive.

4.2 DESIGN

During the initial stages of the project the team felt very strongly that simple and clear visualswould be very helpful in defining and encompassing the product as a whole. The team didmany drawings and diagrams to help them visualize the system, but the most important onesare listed below.

4.2.1 WIREFRAMES

The first steps in designing the system’s user interface as well as trying to determine the mainaspects of the system was to make wireframes. The purpose of the wireframes was to give abasic fundamental structure of the user interface and help the team to figure out what datawould be needed to give the user the appropriate and necessary information. The wireframeswere first sketched up in Google’s spreadsheet environment, giving a good skeletal frameworkof the website. The wireframes did not exactly reflect the final outcome of Drive’s user interfacebut gave the team a good perspective and common ground to work with. Following are theinitial wireframes.

19

4.2.1.1 LOGIN PAGE

The Login page is accessible for the user when not logged in. It is very minimal in design andonly contains the two fields and the login button. Later the team added a register button andalso language buttons when an additional user story was added to the last sprint.

20

4.2.1.2 FRONT PAGE

The first draft of the front page was a relatively simple design. It did not change very muchduring development, although the search functionality was never included in the project backlogand all the buttons below the map were included in one group dropdown. Also the settingsbutton was not needed, since no functionality of that kind was included in the project. The pageconsists of a header, simple map view with a few statistics windows, represented in a dashboardmanner and a footer.

21

4.2.1.3 DETAILS PAGE

The details page is similar to the front page, with an additional detail component about thecurrently selected car from the map. The details window remained very similar throughout thedevelopment process.

22

4.2.1.4 MANAGE USERS PAGE

The user management page is for the owner and managers. However, the list of managerswill not be visible for the managers themselves. This view gives the owner the option to addadditional users or promote users in the system to manager status. The managers can only addadditional user to their own accounts and promote their own employees. This view changed afair amount during development. The team noticed that a lot more data would be included inthe manage view, e.g. list of trackers and groups.

23

4.2.2 USER INTERFACE DESIGNS

When designing Drive the basic idea was for it to be responsive, clean and simple. Therefore theteam talked to a designer who works for TM-software and he created some rough design draftsfor Drive. He used the wireframes as the underlying idea while designing. The team madesome changes, all in consultation with the designer, but the look will undoubtedly continue todevelop with the product in its future endeavours. Following are the preliminary designs.

4.2.2.1 LOGIN

The team chose to remove the blue box with company logo, because the aim was a simple loginscreen. The picture of the road will act as a background instead.

24

4.2.2.2 FRONT PAGE

The front page is pretty similar to our implemented design. Although there were few thingschanged from the original design. The name of the person logged in was added to the header,and the manage button was moved to the left and a home button was added beside it. Also thewhole search bar was not needed because the functionality was never included in the project.

25

4.2.2.3 MANAGEMENT

The manage view changed quite a bit. The team needed to add a lot more information so thecomponents are a bit more nested. Otherwise the look is meant to be similar.

26

4.2.3 NAVIGATIONAL DIAGRAM

The Drive Dashboard Application is meant to be as user friendly as possible. There shouldnot be much navigation in the larger sense, i.e. most changes in the state of the applicationshould be presented on a single screen. Nevertheless, the team felt that for the first draft of theapplication’s navigation it would be more convenient to have the ’Manage Users’ view separatefrom the ’Front Page’ view, from the user’s perspective. The application will be written as aSingle Page Application so all navigation occurs only from the user’s perspective and can beeasily altered.

So, as the diagram portrays, using arrows, all users will land on the ’Login’ view. Failure tolog in will not cause any component changes. If the user does not have an account he will beable to go to a register screen. This view was added later on and only changed the navigationfrom login to register and if and when a user is accepted into the company he will be routed tothe front page. After logging in the user will arrive at the ’Front Page’. All views, after logging inwill offer a log out option. The ’Front Page’ view will display a number of components, and bypressing on a car the user will see a detail window open as part of the ’Front Page’. This will notcause the user to be ’moved’ to another navigational aspect, but is still displayed on the diagramwith a broken line wrapper as indicator.

The only change in the navigational aspect, besides the ’Login’ view, is the ’Manage Users’view. It will be accessible from the header navigation-bar. A home icon in the top left cornerwill be used as a ’home’ button to return the user back to the ’Front Page’.

This diagram has stayed the same throughout the project except for the register screenbeing added.

27

4.3 USER ANALYSIS

4.3.1 USER ROLES

To better understand our users the team listed their roles and descriptions into a table. Thishelped the team view the product from different perspectives and since the product is made forcar rental companies, the manager and the employee are most likely the most important roles.The team decided to include the owner/administrator which should have complete overview ofall companies usages.

User Role DescriptionOwner The owner is the one managing the product and has administrative

privileges. He/She has access to all the companies to help if customers arehaving trouble navigating the system.

Manager A manager is the one that maintains the company’s Drive service. He/Sheis an employee/owner of some car rental company that is using the Driveservice and has write permission within his company.

Employee Is an employee using the system for a car rental company. He/She has readpermissions within his company.

Table 4.3.1: User Roles

28

4.3.2 USER PRIVILEGES

Not all users using the Drive application will have the same privileges. Users should only haveaccess to information relevant to their position. Managers and employees should only haveaccess to information from their company and the employees should not be able to changeinformation about other users in the company. The following diagram lists the privileges ofeach user role. An Owner has all the privileges that a Manager has and a Manager has all theprivileges that an Employee has.

4.3.3 PERSONAS

A Persona is a representation of a user, based off what the team felt would be the primary usersof the system i.e. they were the voice of the user. The team wanted to make them realistic butnot idealized, so that designers, programmers and people that were involved in the productcould feel empathy for them.

The team decided to use personas to help develop the product by making decisions withthem in mind. They guided us through what features, interactions, and visual design aspectsare most important to them. The personas are listed below.

29

4.3.4 USABILITY GOALS

The team decided to set a few target goals for new users, if more than 80% of them are able toperform the tasks with the given constraints then the system’s usability is satisfactory. Of courseexperienced users should easily be able to outperform the constraints.

• The user should be able to log-in in less than 20 seconds.

• The admin or manager should be able to approve another user in 2 minutes.

• The user should be able to reach all statistics available in less than two clicks.

• The user should be able to log-out in one click from all views.

32

4.4 TECHNICAL ENVIRONMENT

Drive is a web application written in React that uses Firebase as it’s backend. Firebase receivesupdates from mobile devices and saves them to a database. The Drive client is then notifiedabout the update and React takes care of re-rendering the page with the updated information.

4.4.1 FRONT END

4.4.1.1 REACT

The web application is written in React which is an open-source JavaScript library. The Reactlibrary uses a virtual DOM and components that are rendered into HTML. React is designed tore-render the HTML when the data is changed and only the components affected by the change.React is therefore the perfect fit for Drive since it is displaying the real-time location of cars.

4.4.2 BACK END

4.4.2.1 NODEJS

We are using NodeJS because it is open-source and there is a great variety of packages availablefor it to speed up development. E.g. React and Firebase along with development tools such asKarma and the Selenium Webdriver.

33

4.4.2.2 FIREBASE

The web application uses Firebase cloud service as its backend, taking care of both userauthentication and data storage. The service is maintained by Google and they are constantlyadding more features and have multiple development packages. One of which is for NodeJSwhich takes care of synchronizing the requested data with the database. Each client maintainsa socket connection with Firebase subscribing to a dataset and is then notified by the Firebaseserver when changes are made to that dataset. This behaviour makes Firebase an ideal fitfor a React application, since the application can be seamlessly re-rendered when new datais received from Firebase.

Firebase might seem a bit chaotic to developers that haven’t used non-relational databasesbefore. Firebase database storage is abstracted to a JSON object where this JSON object’s structureis most telling when determining whether your queries will scale or not. Below is an example ofhow a Firebase database might look like:

Listing 4.1:

1 {2 "Users" : {3 "Admins" : {4 "FanneyUID" : {5 "Active" : true ,6 "Name" : "Fanney Sigurðardóttir"7 }8 } ,9 "Employees" : {

10 "HelgiUID" : {11 "Active" : true ,12 "Name" : "Helgi Rúnar Einarsson"13 } ,14 "HrafnUID" : {15 "Active" : true ,16 "Name" : "Hrafn Orri Hrafnkelsson"17 } ,18 "KristinnUID" : {19 "Active" : true ,20 "Name" : "Kristinn þorri þrastarsson"21 }22 }23 } ,24 "Sensitive" : {25 "Data" : "Information"26 }27 }

34

In the example above you can see that the database has a Users property that contains Adminsand Employees. A query for all Admins in a company would simply request the ’Users.Admins’property containing the list of all admins. Firebase also provides a way to filter out data in aquery but it is imperative for scaling to use good structural design wherever possible.

Firebase is also unlike SQL in the way that it is accessed. Most SQL databases are onlyaccessible from trusted sources, Firebase on the other hand is designed to synchronize data tomultiple clients so each client is talking directly to the database, this makes access managementcrucial for protecting sensitive information. Here is an example of how such a ruleset mightlooks like:

Listing 4.2:

1 "rules" : {2 "Sensative" : {3 ".read" : "root.child(’Users’).child(’Admins’)4 .child(auth.uid).child(’Active’).val() === true"5 }6 }

In the example ruleset above only users listed in the Admins property would have access to theSensitive property in the database seen above. The Drive application is using a lot of sensitiveinformation so it is important to write the database rules with security in mind to make sureusers with different privileges can only access information the are supposed to have access to.

4.4.3 CONTINUOUS DEPLOYMENT

The team decided to use Jenkins as a continuous deployment server. When a change is pushedinto the repository on github a job will automatically be triggered on the Jenkins server (TheCommit Stage) via webhook. If any stage in the pipeline fails the following stages will not runand the build will be marked as a failure. Python is being used to create the scripts that are runon Jenkins.

4.4.4 MOBILE APPLICATION

Drive is dependant on a Mobile Application developed by TM Software. This application allowsthe user to navigate towards its destination. It is an Android application for tablets.

As part of the Drive project, the team integrated the application to Drive’s back-end sothat Firebase would receive updates from the devices using the application.

4.4.5 CODING RULES

The team decided to adapt coding rules to improve code readability and consistancy. Thecoding rules are included in the Operations Manual.

35

www.github.com

PART V

PROGRESS AND CHANGES

36

PROGRESS AND CHANGES

5.1 INTRODUCTION

This part outlines the progress and status of the project Drive. The part reflects all sprints, hoursworked, release burn-down and gives an overview of the project and changes made duringdevelopment.

5.2 SPRINTS

The following sections highlight each sprint’s progress and retrospective.

5.2.1 SPRINT 0

Sprint 0 was set up as an organizational and planning Sprint. The team wanted to start planningfrom the beginning so two stories were created and a very rough estimate was made for eachstory. The team decided on what reports would be handed in and also what each one wouldfocus on. The team also looked closer at the requirements for the projects and created thefirst draft of User Stories. Planning Poker was used to estimate each story’s duration. Nextthe team started looking into the development environment and also how the product wouldbe structured. All decisions and thoughts on the development process were included in thereports, although, much of them evolved and changed during the actual development.

5.2.1.1 SPRINT BACKLOG

User Story Story Point EstimationSetup Organizational Workflow 13Create first drafts of Reports 8

37

5.2.2 SPRINT 1

Sprint 1 started on Monday, 13. September, and lasted 2 weeks. The team had a Sprint Planningmeeting and decided upon 5 User Stories for this Sprint. Since this is the first actual developmentSprint, the team suspected considerable variance in estimations.These estimates were onlymade to track progress and to have an overview of how the project was going, not to scrutinizeor create a stressful environment. The sprint backlog is included in table 10.2.1.

5.2.2.1 SPRINT BURNDOWN

38

5.2.3 SPRINT 2

Sprint 2 started on Monday, 26. September, and lasted 2 weeks. The sprint started with aSprint Planning meeting, the team then confirmed the work capacity of the team based onthe upcoming weeks and the projects ahead. The sprint began smoothly and the team wasconfident that it would finish on time. However, on Day 2 the team realized that the ReactBoilerplate we were using had many issues concerning deployment. The team tried manydifferent deployment options, Heroku, Amazon and Azure, but were unsuccessful. Finally itwas decided to switch the boilerplate, which meant that a lot of work was lost. Nevertheless,since the issue was discovered relatively early and the team was already very familiar with thescripting and setup of Node and Jenkins, the project was back on track early in Sprint 3. Thesprint backlog is included in table 10.2.2.


39

5.2.4 SPRINT 3

Sprint 3 started on Monday, 10. October, and lasted 2 weeks. The sprint underwent minoralterations when meeting with the Product Owner. Both Scrum Master and Product Owneragreed on removing Story 0 for the time being. This story was thought to be to large and perhapsnot necessary in the early stages of the project as Drive did not have an automatic sign-upprocess for its customers. During the sprint a few problems came along in other courses. Inaddition to a status meeting during mid-sprint the team failed to complete story 2. It was thenpassed down to Sprint 4 and the following sprints altered. The sprint backlog is included intable 10.2.3.


40

5.2.5 SPRINT 4

Sprint 4 started on Monday, 24. October, and lasted 6 weeks, due to the final tests the sprint wasdragged out throughout the period instead of giving everyone a 4 week break. The team had aSprint Planning meeting and decided upon 5 User Stories for this Sprint. Because of the overallload from other courses story 2 was moved to this sprint and story 6 over to the next.

During Sprint 4 we needed to change our Maps API, this is due to the fact that the HEREMaps API wrapper for React was not helpful when selecting map markers. This led to the teamdeciding to look at other options. After a discussion and a few hours of research, it was decidedto change the map being used to Mapbox. This sprint was longer than the others due to thetiming of it, final exams and final projects in other courses had great factor on the decision onmaking the sprint longer instead of giving team members a break from the project.

The team handled changing the fundamental aspect of the app very well. During riskanalysis in the beginning of the project, the impact of the Here Maps API not longer workingfor our needs was the same as losing a team member. Thankfully the team had prepared forthis, due to it’s staggering risk factor of 105. The guarantor of this risk was Fanney and shealready had another map in mind. This made the transition period quicker and easier. Thesprint backlog is included in table 10.2.4.


41

5.2.6 SPRINT 5

Sprint 5 started on Monday, 28. November, and lasted 7 days. Because of the team havingmore time to focus on this project, we have an updated story point capacity. The team hada Sprint Planning meeting and decided upon 8 User Stories for this Sprint, one of them beingstory 6 which was passed down from Sprint 4. After finishing all exams the team started Sprint 5.The fact that team members were able to spend much more time together made the structuralenvironment a very pleasant experience. A great feeling of accomplishment swept over theteam when the project took a giant leap towards completion every day it seemed. The sprintbacklog is included in table 10.2.5.


42

5.2.7 SPRINT 6

Sprint 6 started on Wednesday, 7. December, and lasted 7 days. The sprint was postponed 2days because of a status meeting that the team needed to prepare for during that week. Thishelped the team focus better on completing the user stories during the sprint. The team had aSprint Planning meeting and decided upon 6 User Stories. Including story 32 that was passeddown from Sprint 4 and stories 18 and 32 were included in the sprint from the backlog. Theteam felt confident enough to add more story points to the sprint since morale was high and allteam members were working effectively. The sprint backlog is included in table 10.2.6.


43

5.2.8 SPRINT RETROSPECTIVES

The team feels that the organization of the sprints went very well. Although sprint 2, sprint 3and sprint 4 could have been organized better from the beginning, the response and alterationsworked out exceptionally well. This was largely thanks to the risk analysis as shown in section3.3 and great communication within the team. The overall release burndown follows below.

5.2.8.1 RELEASE BURN-DOWN

44

5.3 TIME TRACKING

During the the project’s progressing the team spent a total of 1431 hours. The hours are splitevenly between members for the most part as shown in the pie-chart below. A more detailedtime log can be found in appendix 10.4.

5.4 CONCLUSION

The team managed to finish all stories in the Product Backlog with an exception of an earlyexcluded Story 16. The Release Burndown shows the status of the project at the end of sprint 6.As shown the team completed every aspect of the project. The team is extremely satisfied withthe outcome of the project and the whole development process was both effective and highlyenjoyable.

45

PART VI

TESTING

46

TESTING

6.1 INTRODUCTION

The team decided to place great emphasis on testing the code to avoid regression. The testingis there to validate that a change to the application does not break the existing functionalityof the system. These tests should aim to prove that the modification of code could not havedamaged any functionality. The team feels that this is very important, since the cost of changeto an application rises exponentially when there is an absence of automated testing.

6.2 UNIT TESTING

Drive uses Karma and Mocha to unit test the application’s business logic. This gives developersgreater confidence when re-factoring and maintaining the code, in addition to making sure thecode works as expected. During each run the Jenkins CI server publishes a code coverage reportfor the build and the team strives to be around 80% coverage. Although coverage is far from agood measurement for unit test quality, it is still valuable to know that the tests are touching80% of the code, especially in a loosely typed language like JavaScript.

6.3 ACCEPTANCE TESTING

The acceptance tests are there to make sure the units of code are interacting correctly. If anacceptance test fails and the unit tests do now, it usually means the units where communicatingincorrectly. For our acceptance tests we are using Selenium Webdriver. It is a tool for makingtests that interact with a web page as a human would (clicking buttons, filling input fields, etc).The unit tests are also valuable in telling whether some feature has been implemented, such asuser login, etc.

The team is using its own test runner for the acceptance tests since they could not be runinside Karma because they are executed inside a virtual browser that does not have access tothe Selenium Webdriver dependencies.

47

6.4 SECURITY TESTING

The Drive application is storing a lot of sensitive data about the location of rental cars. Therefore,it is imperative that clients can only access the information they are supposed to have access to.The team decided to add an extra set of tests that make sure information in the database is onlyexposed to users that are supposed to have access to it. We are currently only testing sensitiveproperties but it would be very beneficial to test every field in the database schema.

6.5 CAPACITY TESTING

The Drive application is expected to render hundreds of cars simultaneously so it is importantto make sure that the application scales. Therefore, the team included tests that check whetherFirebase supports 100 location updates in 1 second. In addition, the team is testing the memoryusage of the application after receiving 100 location updates, to make sure the application canbe used for a long period of time without it affecting performance.

6.6 USABILITY TESTING

When most of Drive’s functionality was ready, the team decided to reach out to potential users.The team decided to use think aloud testing where users would perform specific tasks anddescribe out loud their thoughts and feelings while using the system. The complete think aloudtests are included in appendix 10.3 but the results are listed below.

6.6.1 ADMIN TESTS

Both subjects did well when finishing their tasks. Nevertheless, they both took some timefamiliarizing themselves with the manage view. They felt that the design was ok, but it wasmade clear that some reorganization was needed in that view.

6.6.2 MANAGER TESTS

One of the subject did note that the login screen was more lively than the rest of the website,although the design was considered good by both subjects. Tasks went well, although acceptingusers and promoting employees to managers triggered some minor confusion.

6.6.3 EMPLOYEE TESTS

The login screen was mentioned again but all tasks were easy to complete and overall designwas considered good.

48

6.6.4 IMPROVEMENTS

The team discussed the results and decided upon improvements. It was decided to place moreeffort into the design of the manage screen, the plan had previously been to focus less on stylingand more on the functionality. After the usability testing the team decided to place one teammember solely into styling the application. Among the changes were a blue filter that wasadded over the login page, it was meant to increase the consistency of system, and dropdownfunctionality for the companies in the admin view.

6.7 CONCLUSION

During Drive’s development the effort put into testing has really paid off. It has greatly improvedthe teams confidence when making changes to the code and revealed some hidden errors inthe code. The tests will most likely keep making a return investment as they provide value eachtime that changes are made to the code and new features added. This makes good testing justas important as good documentation.

49

PART VII

USER INSTRUCTIONS

50

USER INSTRUCTIONS

7.1 INTRODUCTION

This part outlines the user instructions for the project Drive. These instructions will providenew customers with the opportunity to get to know the system.

Users are split into two categories, managers and employees. A manager has the highestuser permissions in a car rental company, this would be the account of the customer. Managerscan then manage employees to their needs.

7.2 EMPLOYEE OPERATIONS

An employee has access to a subset of the managers operations that help a car rental employeedo his job. They can e.g. better estimate the arrival of a returning car to the company andanswer customer’s questions about popular destinations.

51

7.2.1 CREATING A USER

Creating a new user is simple. Go the the application’s login screen and click Register, fill inthe fields and click Register. There should now be a pending access request that a managerwithin the company will have to accept to grant the user access to the company (see ManagerOperations - Accept Employee Request).

7.2.2 SIGN IN

Sign in by filling in the fields with your account credentials and pressing the Sign In button.

52

7.2.3 GET CAR DETAILS

To get details about a car, a user can find it on the map (you can move around by pressing on itusing the mouse and moving it around), there should be a car icon at the car’s current location(see picture red arrow). You can click on the car icon and a window will appear on the right sideof the map with information about the car you clicked on.

53

7.2.4 ADD CAR TO A GROUP

After you’ve opened the details about a car (see Employee Operations - Get Car Details) youcan add it to a group by selecting the group in the drop-down menu (see red arrow 1) andclicking the check mark icon (see red arrow 2). Note, if the group drop-down is not showingup it’s probably because there are no groups in the company, adding a group requires managerpermissions.

54

7.2.5 SIGN OUT

To sign out of your account simply click on the icon in the top-right corner on any page (whereyou are logged in, see red arrow).

55

7.3 MANAGER OPERATIONS

A manager has access to all the operations for a rental company. Such as granting access to auser requesting access to a company.

7.3.1 ANDROID TRACKERS

An Android tablet with the Driver Guide application should be installed into rental cars. Thetrackers will periodically push locations among other information to the database so managersor employees in a company can see the real-time location of each rental car.

7.3.2 ACCESSING MANAGEMENT PAGE

After signing in (see Employee Operations - Loggin in), press the management icon (see redarrow) to access the management page.

56

7.3.3 ADD CAR TO A TRACKER

Open the management page (see Manager Operations - Accessing the management page), ifthere are any trackers or cars assigned to the company they will appear in the Cars section ofthe page. Navigate to the tracker you wish to assign to a car, fill in the car plate field and selectdrive (see red arrow 1) then press the plus icon (see red arrow 2).

57

7.3.4 CREATE A CAR GROUP

Open the management page (see Manager Operations - Accessing the management page), atthe bottom of the Groups section enter the name of the new group into the field (see red arrow1) then press the plus icon (see red arrow 2).

58

7.3.5 REMOVE A CAR GROUP

Open the management page (see Manager Operations - Accessing the management page), inthe Groups section there should appear a list of all groups in the company (see red square) clickon the trash icon next to the group you wish to remove (see red arrow).

59

7.3.6 ACCEPT EMPLOYEE REQUEST

Open the management page (see Manager Operations - Accessing the management page), inthe Employees section there should appear a list of all employees requests in the company (seered square). Click on the check mark icon below the user you would like to accept into thecompany (see red arrow).

60

7.3.7 PROMOTE EMPLOYEES TO MANAGERS

Open the management page (see Manager Operations - Accessing the management page), inthe Employees section there should appear a list of all employees in the company (see redsquare). Click on the Make Manager switch button below the user you would like to promote tomanager within the company (see red arrow).

61

7.3.8 REMOVE EMPLOYEE

Open the management page (see Manager Operations - Accessing the management page), inthe Employees section there should appear a list of all employees in the company (see redsquare). Click on the trashcan icon below the user you would like to remove from the company(see red arrow).

62

PART VIII

OPERATIONS MANUAL

63

OPERATIONS MANUAL

8.1 INTRODUCTION

This part outlines the operations manual for the project Drive. This manual will provide newdevelopers and admins information on how to approach the project.

8.2 ADMINISTRATORS MANUAL

The Drive web dashboard offers the possibility for administrator accounts. It is meant for superusers working for the owners of the system. An administrator has access to all data for allcompanies and can therefore provide companies with full tech support.

8.2.1 CREATE AN ADMINISTRATOR

An administrator log-in account must be created manually by the developers themselves. Theycan directly add their email into Firebase and take their unique ID (given by Firebase) andadd it to the Firebase user and admin groups. Admins can read and write all data hosted onFirebase and can perform all actions that managers and employees can, except for placing carsinto groups, which is not considered an administrator task.

64

Create Email:

Add UID to Users:

65

Add UID to Admins:

66

8.2.2 CREATING A COMPANY

The web dashboard does not currently have the functionality to create a company. Rather, thisis done by adding the company directly into Firebase.

8.2.3 REMOVING A COMPANY

The web dashboard does not currently have the functionality to delete a company. This can bedone by deleting a company directly with the X button.

67

8.3 DEVELOPER MANUAL

8.3.1 DEVELOPMENT REQUIREMENTS

The following steps are required to begin developing.

8.3.1.1 SETUP

This project depends on Node and the Node Package Manager.

Listing 8.3:

1 /* Clone project from Git Repository */2 git clone ’https://github.com/IronPeak/Drive.git’3

4 /* Navigate to repository folder */5 cd Drive6

7 /* Navigate to main project folder */8 cd app9

10 /* I n s t a l l required packages */11 npm install12

13 /* S t a r t project in l o c a l environment ( http : / / localhost :3000/) */14 npm start15

16 /*17 Tests are divided into four categories ,18 Unit , Acceptance and Capacity19 each having t h e i r own command20 */21 npm run test :unit22 npm run test :acceptance23 npm run test :security24 npm run test :capacity25

26 /* To run unit t e s t s automatically a f t e r saving , use watch */27 npm run test :watch28

29 /* Run Linter */30 npm run lint31

32 /* Fix Lint Errors */

68

33 npm run lint :fix34

35 /* Run u s a b i l i t y and speed t e s t s using Pagespeed */36 npm run pagespeed

69

8.3.2 PROGRAMMING RULES

The following programming rules are a guide to the programming conventions used in theproject. There are also some javascript rules included in the .eslintrc file in the project’s repository.The rules can be adjusted to fit the development team as needed.

8.3.2.1 JAVA-SCRIPT

• Self-Closing Tags

• Wrap JSX tags in parentheses when they span more than one line.

• Alignment styles for JSX syntax. eslint

• Always include a single space in your self-closing tag.

• Always use camelCase for prop names.

• Always include an alt prop on <img> tags. If the image is presentational.

• No trailing spaces.

• Comment your code if needed.

• Maximum line length 120 characters.

• Use 2 spaces for indentation.

• There should be one blank line between functions.

8.3.2.2 HTML

• All attributes, events, and tags must be written in lower case.

• All elements must be closed.

• The value assigned to an attribute must be enclosed in quotes.

• All elements must be properly nested.

• Attribute minimization is not allowed (selected must be selected=‘selected’).

• Declare the correct doctype.

• Use labels for all form boxes.

• Use unordered list for navigation.

• Always place the alt attribute for images.

70

8.3.2.3 CSS

• When grouping selectors, keep individual selectors to a single line.

• Use classes in selectors but avoid id’s for better re-usability of code.

• Include one space before the opening brace of declaration blocks for legibility.

• Place closing braces of declaration blocks on a new line.

• Selectors names should start with a lowercase letter.

• Class names should have hyphens: .profile-image.

• Only use English words.

• Class and id names should be descriptive.

• Avoid shorthand CSS.

• HTML first then CSS.

• Comment the CSS code.

• Avoid extra selectors.

8.3.2.4 PYTHON

• Avoid global variables.

• Do not terminate your lines with semi-colons and do not use semi-colons to put twocommands on the same line.

• One blank line between method definitions.

• Use TODO comments for code that is temporary, a short-term solution, or good-enoughbut not perfect.

• Generally only one statement per line.

• Avoid trailing white space anywhere.

71

8.3.3 PROJECT STRUCTURE

8.3.3.1 REDUX

Redux is a state container for JavaScript applications. Redux works very well with React and canhelp tremendously with managing the global state of the application. The state currently looksas follows:

Listing 8.4:

1 const initialState = {2 "auth" : {3 "admin" : null ,4 "authenticated" : false ,5 "company" : null ,6 "email" : null ,7 "employee" : null ,8 "error" : null ,9 "location" : "/login" ,

10 "manager" : null ,11 "name" : null ,12 "uid" : null13 } ,14 "companies" : {15 "carDetailViewVisible" : false ,16 "carsInGeofence" : [ ] ,17 "companies" : { } ,18 "company" : {19 "cars" : { } ,20 "employees" : { } ,21 "groups" : { } ,22 "name" : null23 } ,24 "currentCar" : { } ,25 "error" : null ,26 "languageStrings" : { }27 } ,28 "filter" : {29 "companies" : [ ] ,30 "groups" : [ ]31 } ,32 "firebase" : { } ,33 "location" : { } ,34 "trackers" : { } ,35 "visibility" : {36 "companies" : [ ] ,

72

37 "trackers" : true38 }39 } ;

8.3.3.2 CLASS STRUCTURE

React has developed a convention, of course not agreed upon by every developer, which sets upthe React classes as either Components or Containers. The basic idea is that Components are’dumb’ classes that should only receive properties and display them (views) while containersshould receive and send data between classes. The division is of course not completely clearand some classes may fall in-between these types, but the team feels that at least some divisionwould be beneficial, both to conceptualize the class structures and for organizational purposes.The containers and components in Drive are currently split as follows.

srccomponents

ButtonCarCarDetailsCarsCheckboxEmployeesFooterGroupsHeaderListLoginMapRegisterStatisticsListStatisticsNumberTextInputTrackers

containersAppContainerLoginContainerMainContainerManageContainerMapViewContainerNotFoundContainerPendingAuthContainerRegisterContainer

73

8.3.3.3 STYLING

Drive uses Sass Css extension for styling, although plain Css is also supported. Sass 7-1 layerpattern is used to keep the .scss files well organized, achieved by splitting them up into appropriatefolders. By using this 7-1 pattern it is only necessary to import the main sass file to all components.The main file will then look up what .scss file is needed for that particular component. All of thefiles except the main are prefixed with an underscore to tell Sass that they are partial .scss filesthat should not be compiled to .css files.

8.3.4 DEPLOYMENT

Drive is setup with continuous deployment pipeline. A continuous deployment is crucial foreven the most rudimentary of projects that are deployed to production. It can speed up developmentfor almost all software projects, improve quality and build up the developer’s confidence.

This is a documentation of the continuous work-flow that is being used for the Driveproject.

8.3.4.1 JENKINS

The team decided to use Jenkins as a continuous deployment server. When a change is pushedinto the repository on www.github.com a job will automatically be triggered on the Jenkinsserver (The Commit Stage) via web-hook. If some stage in the pipeline fails the following stageswill not run and the build will be marked as a failure. Python is being used to create the scriptsthat are run on Jenkins.

8.3.4.1.1 COMMIT STAGE breaklineThe commit stage is the first stage of the continuous deployment pipeline, in this stage Jenkinsruns e.g. unit tests, code coverage, style checker and builds a docker image. Unit Tests arethere to check if the logic of the application code is working as expected, a code coverage toolis used to check if the code meets minimum requirements that the team has set for itself. Thestyle checker confirms wether the code is conforming to the team’s rule set to help maintainconsistency and readability.

8.3.4.1.2 ACCEPTANCE STAGE breaklineThe acceptance stage is the second stage of the continuous deployment pipeline. This stageruns the docker image and runs the acceptance tests on it using Selenium web driver. Next,Page Speed insight tests the usability of the website. Acceptance Tests are used to check if auser story is functional and the usability metric is used to make sure that usability standardsare followed.

8.3.4.1.3 SECURITY STAGE breaklineThe security stage is the third stage of the pipeline. When using Firebase, no web services areused in between the user interaction and the database. This makes authentication rules and

74

www.github.com

access management crucial in the process. Therefore Drive has a security stage, where we runsecurity tests that check if an anonymous or authenticated users have access to data that issupposed to be available to them.

8.3.4.1.4 CAPACITY STAGE breaklineThe capacity stage is the fourth stage of the pipeline. This stage runs the docker image locallyand performs capacity tests on it. However Jenkins is not set up exactly as the production server,so the team is aware that there might be some deviations. These are accounted for in the testsand their expected results. Page Speed is also run on this stage but now it checks the speed ofthe web site to make sure that images are compressed and optimized correctly. The capacitytests check for the application to scale as expected.

8.3.4.1.5 DEPLOYMENT STAGE breaklineThe deployment stage is the fifth and final stage of the continuous deployment pipeline, thisstage pushes the Docker image to Docker and connects through ssh into the Amazon EC2server, pulls the image and runs it. The server that is deployed to depends on the branch Jenkinsis building, if its the master branch jenkins will deploy the application to the production server,if its any other branch it will deploy it to a development server for testing purposes.

8.3.4.2 FIREBASE

We are using Firebase as our authentication and database services. Firebase is a cloud serviceprovider and backend as a service tool for developers that greatly reduces the time it takes toconnect all the different components that are needed for even the most rudimentary applications.Components such as authentication, database, storage, analytics and realtime configurationson a live application. Since Firebase does not enforce types on existing data when the databaseschema is changed, it is important that developers either migrate the existing data to the desiredschema or have the code backwards compatible with previous data.

ADMINS breaklineThe Admins object in the root of the database contains a list of UIDs of users that should haveadmin privileges if the UIDs Admin property is set to true.

COMPANIES breaklineThe Companies object in the root of the database contains a list of companies (with the company’sname as a property name) each containing a list of cars and users within the company. The carslist contains a list of tracker UIDs assigned to the company which contain information aboutthat tracker such as current location, licence plate etc. The users list contains a list of users inthe company with each user having a property for Employee and Manager set that user’s accesspermissions within the company.

75

TRACKERS breaklineThe Trackers object in the root of the database contains a list of UIDS of trackers within theapp. Each tracker contains an Email address for the tracker and a Company property for thecompany he is assigned to if any.

8.3.4.2.1 USERS breaklineThe Users object in the root of the database contains a list of UIDs for the users within the app.Each user has an Email, Name and the Company he is assigned to.

8.3.4.2.2 FIREBASE SCHEMA breaklineWhen first starting to use Firebase databases it is blatantly obvious that it does not follow thesame principles as your typical SQL database. The data is stored in a single JSON object. Theinitial database schema that the team designed for Drive fell a little bit short and did not accountfor all properties. This is Drive’s current database schema seeded with some example values:

Listing 8.5:

1 {2 "Admins" : {3 "FanneyUID" : {4 Admin : true5 }6 } ,7 "Companies" : {8 "examplecompany1" : {9 "Active" : true ,

10 "Users" : {11 "KristinnUID" : {12 Active : true ,13 Name : Kristinn ,14 Email : k@k .is ,15 Employee : true ,16 Manager : false17 }18 } ,19 "Cars" : {20 "Tracker001UID" : {21 Active : true ,22 Plate : "MA891"23 }24 } ,25 "Groups" : {26 "Sendibíll" : Sendib íll27 }

76

28 } ,29 "examplecompany2" : {30 "Active" : true ,31 "Users" : {32 "HrafnUID" : {33 Active : true ,34 Name : Hrafn ,35 Email : h@h .is ,36 Employee : true ,37 Manager : true38 }39 } ,40 "Cars" : {41 "Tracker002UID" : {42 Active : true ,43 Plate : "BR132"44 }45 }46 }47 } ,48 "Trackers" : {49 "Tracker001UID" : {50 Company : examplecompany1 ,51 Email : tracker01@drive .is52 } ,53 "Tracker002UID" : {54 Company : examplecompany2 ,55 Email : tracker02@drive .is56 }57 } ,58 "Users" : {59 "KristinnUID" : {60 Company : examplecompany1 ,61 Name : Kristinn ,62 Email : k@k .is63 } ,64 "HrafnUID" : {65 Company : examplecompany2 ,66 Name : Hrafn ,67 Email : h@h .is68 }69 }70 }

77

8.3.4.2.3 FIREBASE RULES breaklineThe database’s access management can be configured using a JSON object in the Firebase console.When configuring the rules for access management you have access to a lot of useful informationfrom the authentication server, such as the person’s unique ID, if he is logged in. The revisedand currently used version of our Firebase rules can be located in our Github repository atapp/firebase-database-rules.json

Here is a simple Firebase rule as an example:

Listing 8.6:

1 ".read" : "root.child(’Companies’).child(\$Company)2 .child(’Users’).child(auth.uid)3 .child(’Manager’).val() === true4 ||5 root.child(’Companies’).child(\$Company)6 .child(’Users’).child(auth.uid)7 .child(’Employee’).val() === true "

The root indicates the root of the database and then accesses the child property companiesafter which the $Company variable is used to indicate the company which is being accessed.Then, looking into the company’s Users property, if the user’s property contains a property withthe user’s unique identifier it checks if the Manager or Employee property values are set to true.If they are, the user has read permission on the requested resource. One additional thing tonote about these rules is that they are checked in order from the shallowest to the deepest rule,meaning that only if a rule returns false is the deeper checked.

8.3.5 MOBILE APPLICATION

The Project is dependant on a Mobile Application developed by TM Software. This applicationallows the user to navigate towards its destination. The mobile application is an Android projectwhich includes login code to identify the devices on Firebase. The application also includessome code that pushes locations and similar information to Firebase where Drive has access toit. To setup for development in the Mobile Application, please view the Operations Manual forDriverGuide.

78

PART IX

CONCLUSION

79

CONCLUSION

9.1 THE PROJECT

The team feels that the organization and planning was very successful. The tools and techniquesused were highly effective and the team also feels that the work done during the initial stages ofthe project were extremely beneficial to the whole development process.

Meetings with the adviser and the status meetings helped the team keep on track andprompted further project analysis. Moreover, presenting the project to a neutral audience gavethe team a new point of view which greatly broadened the teams viewpoint.

The team managed to finish all intended functionality. The team is extremely satisfiedwith the outcome of the project and the whole development process was both effective andhighly enjoyable. The effort put into testing really paid off. It greatly improved the teamsconfidence and even revealed some hidden errors in the code.

9.2 FUTURE PLANS

After meeting with car rental companies the team found that the product was of great interest tothe targeted clientele. The owners of the product also have potential customers, although muchmore analysis and development will be done. The product owner talked to the team about therequested features and the team is confident that most features can be implemented withoutaffecting the application’s scaling or the user’s experience.

80

PART X

APPENDIX

81

APPENDIX

10.1 PRODUCT BACKLOG

ID User Story Priority Story Point1 As an owner/manager/employee I want to login

to my account so that I have access to my driveapplication.

A 5

2 As an owner/manager/employee I want to logoutof my account so that the computer no longer hasaccess to my drive account.

A 2

3 As an owner/manager/employee I want to accessthe mapview so that I can view the rental car’slocation in realtime.

A 8

4 As an owner/manager/employee I want select a carso that I can see information about it.

A 5

5 As an owner/manager I want to add another user toa company so that he has access to the company.

A 3

7 As an owner I want to assign a tracking device toa company so that the company has access to it’stracking information.

A 5

31 As an owner/manager I want to add informationabout a car so that I can remember informationabout it.

A 5

Table 10.1.1: A Priority User Stories

82

ID User Story Priority Story Point6 As an owner/manager I want to remove another

user from a company so that he no longer has accessto the company.

B 2

8 As an owner/manager I want to add a geofence to acompany so that I can track if a rental car went to aforbidden area.

B 5

9 As an owner/manager I want to remove a geofencefrom a company so that I’m no longer tracking if arental car went outside the geofence.

B 2

10 As an owner/manager I want to create a group ofrental cars so I can easily filter the cars in the groupfrom the others.

B 3

12 As an owner/manager/employee I want to filter themapview by group so that I only see the cars in thegroup.

B 3

19 As an owner/manager/employee I want to assign acar plate number to a rental car so that I can identifyit better.

B 2

20 As an owner/manager/employee I want to see acar’s information on okutækjaskrá.is when I selectit so that I can see more information about it.

B 5

Table 10.1.2: B Priority User Stories

83

ID User Story Priority Story Point11 As an owner/manager I want to remove a group so

that I no longer see it as an available filter.C 2

13 As an owner/manager/employee I want to see if acar is online/offline so that I can see which rentalcars are in use.

C 3

14 As an owner I want to filter the mapview bycompany so that I can see only the rental cars in thatcompany.

C 3

15 As an owner/manager/employee I want to seepopular stops so that I can better analyse mycustomers behaviour.

C 13

16 As an owner/manager/employee I want to seepopular routes so that I can better analyse mycustomers behaviour.

C 13

17 As an owner/manager/employee I want to see thebandwidth usage for each rental car so that Ican respond if any of them are not behaving asexpected.

C 5

18 As an owner/manager/employee I want to see thetotal bandwidth usage for the rental cars that arefiltered in the map view so that I can keep track ofthe usage.

C 3

32 As an owner/manager/employee I want to be ableto change the language of the website so that I canunderstand it better

C 2

Table 10.1.3: C Priority User Stories

84

ID Other Story Priority Story Point21 Setup Jenkins continuous integration server for the

project.A 1

22 Integrate a unit test framework into the project sothat it’s run in the commit stage on Jenkins.

A 2

23 Integrate a code coverage framework into theproject that runs in the commit stage on Jenkins andfails the build if a specific amount of coverage is notmet.

A 2

24 Integrate a style checker framework into the projectthat runs in the commit stage on Jenkins and failsthe build if it does not follow the coding rules.

A 3

25 Setup a process of creating acceptance tests that willrun on the acceptance test stage on Jenkins Server.

A 3

26 Setup a process of creating capacity tests that willrun on the capacity test stage on Jenkins Server.

A 3

27 Create a deployment script that deploys the app toa development server.

A 3

28 Integrate Firebase into the project. A 129 Integrate Here API into the project. A 230 Integrate React into the project. A 1

Table 10.1.4: A Priority Other Stories

85

10.2 SPRINT BACKLOGS

ID Story Priority StoryPoint

21 Setup Jenkins continuous integration server for the project. A 522 Integrate a unit test framework into the project so that it’s

run in the commit stage on Jenkins.A 3

23 Integrate a code coverage framework into the project thatruns in the commit stage on Jenkins and fails the build if aspecific amount of coverage is not met.

A 3

24 Integrate a style checker framework into the project that runsin the commit stage on Jenkins and fails the build if it doesnot follow the coding rules.

A 3

25 Setup a process of creating acceptance tests that will run onthe acceptance test stage on Jenkins Server.

A 5

Total: 19

Table 10.2.1: Sprint 1

26 Setup a process of creating capacity tests that will run on thecapacity test stage on Jenkins Server.

A 5

27 Create a deployment script that deploys the app to adevelopment server.

A 5

28 Integrate Firebase into the project. A 329 Integrate Here API into the project. A 330 Integrate React into the project. A 3

Total: 19


86


1 As an owner/manager/employee I want to login to myaccount so that I have access to my drive application.

A 5

2 As an owner/manager/employee I want to logout of myaccount so that the computer no longer has access to mydrive account.

A 2

3 As an owner/manager/employee I want to access themapview so that I can view the rental car’s location inrealtime.

A 8

Total: 15



4 As an owner/manager/employee I want select a car so that Ican see information about it.

A 5

5 As an owner/manager I want to add another user to acompany so that he has access to the company.

A 3

2 As an owner/manager/employee I want to logout of myaccount so that the computer no longer has access to mydrive account.

A 2

7 As an owner I want to assign a tracking device to a companyso that the company has access to it’s tracking information.

A 5

31 As an owner/manager I want to add information about a carso that I can remember information about it.

A 5

Total: 20


87


6 As an owner/manager I want to remove another user from acompany so that he no longer has access to the company.

B 3

8 As an owner/manager I want to add a geofence to a companyso that I can track if a rental car went to a forbidden area.

B 5

9 As an owner/manager I want to remove a geofence from acompany so that I’m no longer tracking if a rental car wentoutside the geofence.

B 2

10 As an owner/manager I want to create a group of rental carsso I can easily filter the cars in the group from the others.

B 3

12 As an owner/manager/employee I want to filter the mapviewby group so that I only see the cars in the group.

B 3

19 As an owner/manager/employee I want to assign a car platenumber to a rental car so that I can identify it better.

B 2

20 As an owner/manager/employee I want to see a car’sinformation on okutækjaskrá.is when I select it so that I cansee more information about it.

B 5

11 As an owner/manager I want to remove a group so that I nolonger see it as an available filter.

C 2

Total: 25



13 As an owner/manager/employee I want to see if a car isonline/offline so that I can see which rental cars are in use.

C 3

14 As an owner I want to filter the mapview by company so thatI can see only the rental cars in that company.

C 3

15 As an owner/manager/employee I want to see popular stopsso that I can better analyse my customers behaviour.

C 13

17 As an owner/manager/employee I want to see thebandwidth usage for each rental car so that I can respond ifany of them are not behaving as expected.

C 5

18 As an owner/manager/employee I want to see the totalbandwidth usage for the rental cars that are filtered in themap view so that I can keep track of the usage.

C 3

32 As an owner/manager/employee I want to be able to changethe language of the website so that I can understand it better

C 2

Total: 29


88

10.3 THINK ALOUD TESTING

10.3.1 INTRODUCTION

Think aloud testing were performed to get a better understanding of user behaviour. Testingwas separated into three user categories and two persons tested in each of those categories.

10.3.2 TEST FORMAT

The tests were presented to the testers on the following format.

10.3.2.1 INTRODUCTION

Welcome and thank you for participating in the development of Drive. The following test is byno means a test of your abilities, but a test of the website displayed. The data gathered will notbe used for commercial usage and will remain anonymous. We encourage you to try to finishall tasks handed to you, but remind you that you can stop at any time if you feel uncomfortableor lost.

Please try to speak your mind as you navigate the page as it will help us to analyse theproblems we occur.

10.3.2.2 PRIOR TO TESTING QUESTIONS

• Age

• Gender

• Education

• Computer Experience

• Abilities/Disabilities

10.3.2.3 ADMIN TESTS

LOGIN TO A SPECIFIC ACCOUNT breaklineTester is provided with credentials for an admin account.

GET DETAILS ON A CAR breaklineTester is asked to find details on a car registered in the application.

FILTER CARS ON MAP BY COMPANY breaklineTester is asked to filter the cars on the map by a specific company.

89

ASSIGN A TRACKER TO A COMPANY breaklineTester is asked to assign a specific unassigned tracker to a specific company.

REMOVE A TRACKER FROM A COMPANY breaklineTester is asked to remove a specific assigned tracker from a specific company.

REMOVE A USER FROM A COMPANY breaklineTester is asked to remove a specific user from a specific company.

LOGOUT breaklineTester is asked to sign out of the account.

10.3.2.4 MANAGER TESTS



ADD A CAR TO A GROUP breaklineTester is asked to add a specific car to a specific group.

PROMOTE AN EMPLOYEE TO A MANAGER breaklineTester is asked to promote a specific employee to a manager.

REMOVE A USER breaklineTester is asked to remove a specific user from the company.

CREATE A GROUP FOR CARS breaklineTester is asked to create a group with a specific name for the cars in the company.

REMOVE A GROUP breaklineTester is asked to remove a specific group.


10.3.2.5 EMPLOYEE TESTS

REGISTER AN ACCOUNT breaklineTester is asked to register an account to a specific company.

90



ADD A CAR TO A GROUP breaklineTester is asked to add a specific car to a specific group.


91

10.4 TIME TABLE

Date Sum Fanney Helgi Hrafn ÞorriAug 29th 32 8 8 8 8Aug 30th 6 3 3Aug 31st 14 1.5 1.5 6 5Sep 1st 15.5 3.5 2 4 6Sep 2nd 2 2Sep 5th 22 4 0.5 8 9.5Sep 7th 22.5 8.5 8 6Sep 8th 13 2 0.5 6 4.5Sep 9th 6 6Sep 10th 7 2 5Sep 11th 23.5 10 7 6.5Sep 12th 26 6 8 8 4Sep 14th 18 4 5 6 3Sep 15th 25 6 6 6 7Sep 16th 11 6.5 1.5 1.5 1.5Sep 19th 21.5 5.5 3.5 6.5 6Sep 21st 22.5 4 4.5 6 8Sep 22nd 26 6 9 6 5Sep 26th 31.5 8 7.5 8 8Sep 28th 11 6 1 0.5 3.5Sep 29th 7 6 0.5 0.5Oct 3rd 24.5 8 8 8.5Oct 5th 23.5 6 4.5 6.5 6.5Oct 6th 27.5 6 5 8 8.5Oct 10th 21.5 11.5 1.5 8.5Oct 11th 9 5 4Oct 12th 22 6.5 3.5 6 6Oct 13th 15.5 7.5 7 1Oct 14th 10 10Oct 15th 10 10

92

Date Sum Fanney Helgi Hrafn ÞorriOct 17th 28 1 8 8 11Oct 18th 17 7 8 2Oct 19th 17.5 0.5 8 4.5 4.5Oct 20th 15.5 4.5 0.5 4 6.5Oct 21st 7 7Oct 22nd 2 2Oct 24th 18.5 1.5 1.5 8.5 7Oct 26th 5.5 0.5 0.5 4 0.5Oct 27th 1.5 0.5 0.5 0.5Oct 31st 1 0.5 0.5Nov 3rd 8 0.5 6 1.5Nov 7th 2 2Nov 8th 13 5 8Nov 10th 14 6 8Nov 12th 24.5 9 7 8.5Nov 13th 21 6 8 7Nov 14th 8 8Nov 16th 0.5 0.5Nov 18th 8 8Nov 19th 8 8Nov 21st 4 4Nov 24th 15 7 8Nov 25th 3 3Nov 26th 27 10 8 9Nov 27th 30 7 8 6 9Nov 28th 35.5 10.5 8 9.5 7.5Nov 29th 27 6.5 4 8 8.5Nov 30th 24 3.5 6 8 6.5

93

Date Sum Fanney Helgi Hrafn ÞorriDec 1st 31.5 8.5 7.5 8 7.5Dec 2nd 31 7.5 7 8 8.5Dec 3rd 28 7 8 5 8Dec 4th 32 8 8 8 8Dec 5th 29 5 8 8 8Dec 6th 39 10 10 10 9Dec 7th 35 9 9 8 9Dec 8th 40 10 10 10 10Dec 9th 37 9 10 9 9Dec 10th 33 8 9 8 8Dec 11th 36 9 10 9 8Dec 12th 27 7 8 6 6Dec 13th 48 12 12 12 12Dec 14th 48 12 12 12 12Dec 15th 24 6 6 6 6Total 1431 360.5 351 358 361.5

94

Final Project 2016 Drive - Heim | Skemman · 2019-08-30 · and the team to maintain a healthy...

Documents

Transcript of Final Project 2016 Drive - Heim | Skemman · 2019-08-30 · and the team to maintain a healthy...