Afsluttende projekt(denn3902 rasm768g) dat12v by Rasmus Alexander Tvede Jørgensen

Afsluttende projekt - 5. Semester - Datamatiker

Your Places Dato: 6/6-14

Deltagere: Dennis Nielsen (Denn3902) – 23. Marts 1987 Rasmus Alexander Tvede Jørgensen (Rasm768g) – 19. Marts 1991

Forord (Rasmus) .................................................................................................................................. 4 Problemformulering (Dennis) ......................................................................................................... 4 Vision og mission (Rasmus) ............................................................................................................. 5 Projektets struktur og procesmodel (Rasmus) ......................................................................... 5 Feasability Study (Dennis) ................................................................................................................ 8 Målgruppe (Dennis) ....................................................................................................................................... 9 Målgruppe (Kunden) (Dennis) ................................................................................................................................... 9 Målgruppe (Bruger) (Dennis) ..................................................................................................................................... 9 Brugerundersøgelse (Dennis) .................................................................................................................. 10 Kvantitativ undersøgelse. (Dennis) ....................................................................................................................... 10 Kvalitativ undersøgelse (Dennis) ........................................................................................................................... 11 Markedsmæssige problemstillinger (Dennis) .................................................................................... 12 Teknologiske problemstillinger (Dennis) ............................................................................................ 13 Finansielle problemstillinger (Dennis) ................................................................................................. 14 Økonomisk problemstilling (Dennis) ................................................................................................................... 15 Del Konklusion (Dennis + Rasmus) ........................................................................................................ 18 Teknologier (Dennis og Rasmus) ................................................................................................. 19 Versions styring (Rasmus) ......................................................................................................................... 19 Android (Dennis) .......................................................................................................................................... 20 Java (Dennis) ................................................................................................................................................................... 21 XML (Dennis) .................................................................................................................................................................. 21 Nutiteq (Dennis) ............................................................................................................................................................ 22 Backend system (Rasmus) ......................................................................................................................... 23 Frontend (Rasmus) ...................................................................................................................................................... 23 Backend (Rasmus) ........................................................................................................................................................ 23 Vagrant (Rasmus) ......................................................................................................................................................... 30 API (Dennis) .................................................................................................................................................... 31 Del konklusion (Rasmus) ........................................................................................................................... 32 Udviklingsprocessen (Rasmus) ..................................................................................................... 32 Moduler, Chores og Bugs (Rasmus) ........................................................................................................ 32 Scrum roller (Rasmus) ................................................................................................................................ 33 Backlogs (Rasmus) ....................................................................................................................................... 33 Retrospective meeting / sprint review meeting (Rasmus) ............................................................ 34 Scrum board (Rasmus) ................................................................................................................................ 35 Scrum poker (Rasmus) ................................................................................................................................ 35 Risikoanalyse af opgaver (Rasmus) ........................................................................................................ 36 Udvælgelse af opgave i et sprint (Rasmus) .......................................................................................... 36 Iterationen i et sprint (Rasmus) .............................................................................................................. 37 Sprints (Dennis og Rasmus) ........................................................................................................... 38 Kernen (Rasmus) .......................................................................................................................................... 38 2

Sprint1 -‐ Kerne del 1 (Dennis og Rasmus) ............................................................................................ 38 Udvægelse af userstories/moduler (Rasmus) .................................................................................................. 38 User stories (Dennis) ................................................................................................................................................... 40 Wireframes (Dennis og Rasmus) ........................................................................................................................... 40 Design (Dennis og Rasmus) ...................................................................................................................................... 43 Programmering (Dennis og Rasmus) ................................................................................................................... 44 Brugertests (Dennis og Rasmus) ............................................................................................................................ 47 Retrospektive meeting (Dennis og Rasmus) ..................................................................................................... 48 Sprint2 -‐ Kerne del 2 (Dennis og Rasmus) ............................................................................................ 49 Udvægelse af userstories/moduler (Dennis) ................................................................................................... 49 User stories (Dennis) ................................................................................................................................................... 50 Wireframes (Dennis og Rasmus) ........................................................................................................................... 50 Design (Dennis og Rasmus) ...................................................................................................................................... 53 Programmering (Dennis og Rasmus) ................................................................................................................... 55 Brugertests (Dennis og Rasmus) ............................................................................................................................ 62 Retrospektive meeting (Rasmus) .......................................................................................................................... 63 Sprint3 -‐ Kerne del 3 (Dennis og Rasmus) ............................................................................................ 63 Udvægelse af user stories/moduler (Dennis) .................................................................................................. 63 User stories (Dennis) ................................................................................................................................................... 64 Wireframes (Dennis) ................................................................................................................................................... 64 Design (Rasmus) ........................................................................................................................................................... 65 Programmering (Dennis og Rasmus) ................................................................................................................... 66 Brugertests (Dennis) ................................................................................................................................................... 69 Retroskektive meeting (Dennis) ............................................................................................................................ 69 Sprint4 -‐ Modul (Dennis og Rasmus) ...................................................................................................... 70 Udvælgelse af userstories/moduler (Rasmus) ................................................................................................ 70 User stories (Dennis) ................................................................................................................................................... 71 Wireframes (Dennis og Rasmus) ........................................................................................................................... 71 Design (Dennis og Rasmus) ...................................................................................................................................... 74 Afslutning (Dennis og Rasmus) ............................................................................................................................... 77 Del konklusion (Dennis) ............................................................................................................................. 77

Sikkerhed (Rasmus) .......................................................................................................................... 78 Konklusion (Dennis og Rasmus) ................................................................................................... 82 Bilag ........................................................................................................................................................ 83 1. Kernen -‐ modul liste med estimering og risiko .............................................................................. 84 2. Modul liste med estimering og risiko ................................................................................................ 85 3. Glossery ....................................................................................................................................................... 86 4. Spørgeskemaundersøgelse ................................................................................................................... 86 5. Wireframes ................................................................................................................................................. 93 5.1 Appen .......................................................................................................................................................................... 94 5.2 Webservice ............................................................................................................................................................... 94

Forord (Rasmus) Vi kender næsten alle til, at være ude og rejse og ikke have noget kort med. Hvordan ved man hvor man burde gå hen, i et land som man ikke kender? Selvfølgelig er der kort til mobile enheder, diverse guide-bøger, flyers osv. Men mobile enheder kræver internet for at hente kort, guide-bøger, flyers mm. og er uoverskuelige og gammeldags.

Men hvad så med en digitalisering af guides og kombineret med kort der virker offline på mobile enheder? Der er altid i vore dage mulighed for på et tidspunkt at komme på internettet blot for en kort stund. Her kunne det så være muligt, at hente nødvendig data der kan benyttes offline når man er i udlandet. Dette giver en muligheden for nemt og bekvemt, at navigere rundt i ukendte territorier. Men hvem skal så udfylde disse guides og lave kort? og hvordan tjener man penge på dette? og er der overhovedet et marked det dette? Det er det denne rapport vil fokusere på, samt udviklingen af produktet i form af både en app og en web-service til at hente information fra.

Problemformulering (Dennis) Vi har i gruppen fået idé, som gør navigeringen på et kort, når man er ude at rejse, nemmere. Man har altid sin smartphone på sig, og da dataroaming ofte er dyrt i udlandet, skal det derfor kunne fungere offline på sin enhed. Er der et marked for dette og hvem skal administrere dette? Hvilke teknologier er mest relevante for sådan et produkt? Hvordan bygger vi et system, som kan indeholde kort og informationer, som ikke skal bruge internet mens man benytter det? Vi vil i rapporten, gennem markedsanalyser, spørgeskemaer og interviews påvise at en sådan app, kan øge brugeroplevelsen for navigering, og give brugerne en nemmere løsning end de mere gammeldags papirs brochurer, der ligger i receptioner mm.

Vision og mission (Rasmus) Vores vision for dette projekt, er en forbedring/fornyelse af kort. Dette ved at digitalisere og gøre dem interaktive, samt give ejeren en nem og overskuelig måde at styre indholdet på. Papir kortet vil blive erstattet af en app med offline kort, der kan indeholde flere kort, som bliver downloaded vha. en aktiveringskode. Indholdet af kortet, dets størrelse og placering vil kunne blive styret i en webservice med et overskueligt backend system. Vores mål er, at lave backend systemet betalingspåkravet. Et betalingssystem hvorpå vores kunde betaler for præcist hvor meget indhold, der ønskes i sit kort og hvor stort kort den skal indeholde, men som start vil det være en gratis tjeneste. Vores mission er gennem kvantitative markedsanalyser, at finde ud af præcist hvad brugeren prioriterer højst af funktioner i deres app. Med dette kan vi udvælge hvilke features der skal implementeres i app’en. Gennem kvalitative undersøgelser i form af interviews med relevante kunder som hoteller og turistbranchen, vil vi finde ud af hvad kunden ønsker i deres backend system, og dermed hvilke informationer de vil give deres brugere.

Projektets struktur og procesmodel (Rasmus) Vi har valgt, at dele dette projekt op i to faser, en startfase der kan drage paralleler til Unified process Inception fase, og en anden fase der bygger bygger på Scrum. Følgende afsnit vil argumentere for valget af dette. Når man skal vælge en process model, er det meget vigtigt først at have en klar forståelse af, hvad ens mål med projektet er, og hvordan det skal udgives til brugeren. Dette fordi der er en masse faktorer der spiller ind, når man skal vælge hvilken metodik der er mest relevant for netop dette projekt. For nogle projekter kan en vandfaldsmodel være helt perfekt, da et lille og uforanderligt scope er stillet op med minimale risici. Hvorimod andre projekter kræver den agile tilgang, hvor der er plads til forandringer under udviklingsprocessen - Dette ses ofte i større projekter hvor mange faktorer kan spille ind og forandre eller modificere projektet.

Dette projekts opbygning kan ses på illustrationen nedenfor. Det er vigtigt at notere, at denne illustration ikke skal ses i forhold til en udviklingsmetode endnu - den er blot et redskab for, at finde og analysere projektets rette procesmodel! Forklaringen ses under illustrationen.

Dette projekt kræver en opstartsfase, da der intet forarbejde er for projektet, det er blot en idé der skal undersøges og muligvis realiseres! Det kræver en feasibility study, for at finde ud af om projektet overhovedet kan lade sig gøre og om det er muligt at tjene penge på dette projekt(da projektet i sig selv er en forretnings idé, er dette hele pointen). Denne feasibility study har brug for, at være meget omfattende, da den skal ligge til grund for hele projektet, og hvordan det udformes. Som led i feasibility study’en vil der ligge kvalitative og kvantitative undersøgelser, og disse vil også danne grundlag for, hvilke ting der senere skal laves og hvornår i projektet. Efter opstart vil der være behov for, at udvikle en kerne - denne kerne er grundlaget for hele projektet. Selvom det er grundlaget, betyder dette ikke, at det er en risikofyldt del af systemet. Kernen er kun lige netop nok til, at essensen af vores projekt bliver fuldført og vi har et brugbart system, med værdi for vores kunder. Efter dette er resten af projektet opdelt i iterationer, med moduler/features der tilføjer nye funktioner til kernen. Disse moduler bliver valgt på baggrund af undersøgelserne i opstartsfasen, samt ny information i form af nye undersøgelser og feedback på produktet under udviklingen. Med dette i tankerne kan der nu udvælges en procesmodel for vores projekt. Det er hurtigt at konkludere, at der er brug for at arbejde agilt, da projektet leder op til der skal arbejdes inkrementalt og iterativt. Dette med gentagelser i form af nye funktioner, der hele tiden skal designes, udvikles og tilføjes til det inkrementale produkt. Dermed kan 6

der altså udelukkes vandfaldsmodellen. Vores projekt er opbygget i 2 faser, opstartsfasen og “modul-fasen”, og derfor kan vi udelukke UP(Unified process). UP har 4 faser, og en slutning på projektet, med arbejdsopgaver der skifter fokus alt efter hvilken fase og hvor langt mod enden man befinder sig - hvorimod vores har en start og derefter en kontinuerlig udvikling uden nogen definitiv slutning. En af de vigtigste elementer i UP er, at man i de tidlige faser analyserer risikomomenter, der kan udvikles tidligt, og man kan vælge hvad det næste der skal udvikles på baggrund af dette. Vores projekt vil analysere hvad kunden har brug for netop nu, og udvælge næste modul, der skal udvikles på baggrund af dette. Disse forskellige er for fundamentale i UP, til vi kan benytte denne som process model. I dette projekts første fase kan der drages paralleler til UP’s første fase, Inception. Inception giver muligheden for, at analysere og forstå helheden i systemet, samt feasibility study der skal bevise om projektet kan realiseres. Dette vil vores første fase også gøre. Vores markedsanalyse i feasibility study vil også være så gennemført, at den senere kan benyttes til at udvælge de første moduler der skal udvikles i forløbet. Det må ikke forveksles med scrums “spike”, der er en tidsperiode til netop research osv. En spike, har nemlig en fast tidsramme som ikke er bestemt af selve opgaven, men er inden opgavestarten allerede defineret. Til vores formål, har vi brug for en periode der afhænge 100% af opgaven, så vi kan bruge så lang tid som der er brug for til denne opgave og ikke blot stoppe hvis tiden udløber. Når den første fase er gennemført vil resten af projektet skulle udføres. Her vil de to oplagte procesmodeller være XP(Extreme Programming) og Scrum. Begge disse procesmodeller er ikke opdelt i faser og arbejder agilt, så for at vælge imellem disse, må der kigges nærmere på de to modellers indhold, udover blot den agile tilgang. XP har fokus på TDD(Test driven development)1 og pair programming. Dette er to ting der ikke er relevant for os. Pair programming bliver umuligt for os, i hvert fald i starten af projektet, da vi kun er to udviklere, og har brug for at arbejde på hver vores ting, for at have et nogenlunde arbejdsflow tidsmæssigt. 1 2

http://www.agiledata.org/essays/tdd.html Procentsats taget fra Engadget - http://www.engadget.com/2014/01/29/strategy-analytics-2013-

TDD er en ting, der er svær at argumentere imod, som værende en dårlig ting. Men i vores tilfælde er det ikke så relevant. Vores produkt er ekstremt fokuseret på brugerflader, både med en backend til kunderne og en app til brugeren. Da det er brugerflader, er TTD ikke relevant, da det er svært at teste på om en brugerflade virker optimalt. Det er noget man ser vha. brugertest og brugerens feedback på applikationerne. Vi har selvfølgelig logik inden bag vores brugerflader, men hovedfokus ligger stadigvæk på en brugerflade - specielt i starten af projektet. Derfor er TTD ikke noget der har relevans for dette projekt. Med dette sagt, har vi valgt, at udvikle projektet med Scrum som procesmodel. Scrum giver os en masse redskaber udover blot den agile udviklingsmetode, som f.eks. Scrum board, Sprint backlog, standupmeetings og restrospektive meetings. Vores udvikling efter første fase, vil først bestå af at få udviklet kernen af systemet, som er relativt lille, og derefter vil der udplukkes moduler til hvert sprint. Hvordan og hvilke redskaber vi præcist benytter vil være forklaret i afsnittet omkring udviklingsprocessen.

Feasability Study (Dennis) Vores feasibility study skal gøre rede for om vores produkt kan realiseres og sælges. Måden dette gøres på, er ved at stille nogen spørgsmål, der afklarer præcis hvad der skal til for dette. Hvem er vores målgruppe? Hvilken interesse vil målgrupperne have i sådan et produkt, og er det noget slutbrugeren ønsker, og dermed også drager nytte af? Vi vil i vores feasibility study finde ud af, om kunderne har brug for sådan et produkt, og om brugerne vil benytte produktet, hvis det blev udviklet. Hvordan ser markedet ud i dag, og hvordan kan vi adskiller os fra konkurrenterne på markedet.

Er der nogen teknologiske udfordringer associeret med dette produkt og kan vi undgå disse? Kan der tjenes penge på dette? Feasibilty study’en skal ende ud i en detaljeret og rangeret liste med mulige fremtidige features for vores produkt. Denne liste vil til vores udviklingsfase agerer kravspecifikation, og give os muligheden for at vælge præcis de features, som vores kunder og brugere ønsker mest i vores produkt. På den måde vil produktets udvikling være styret af markedets behov lige nu og her, frem for en udviklers synspunkt på hvad brugeren har brug for.

Målgruppe (Dennis) “Hvem er vores målgruppe?”

Målgruppe (Kunden) (Dennis) En af de ting der er lagt vægt på fra start er, at det færdige produkt er rettet mod virksomheder med en masse kunder. Produktet skal anses som en service, der kan tilbydes virksomhedens kunder(vores kundes kunder).

Derfor ville en typisk kunde være et hotel, der ofte har mange udenlandske besøgende, der kan drage nytte af denne service. Men selvom målgruppen er defineret, er dette ikke ensbetydende med at andre ikke kan drage nytte af vores produkt. Problemet åbner muligheder til mange forskellige målgrupper, når først systemet begynder at tage form med mange forskellige features. F.eks. kunne det tænkes, at målgruppen i starten kun er hoteller, der vil give deres kunder et hurtigt bykort. Men som udviklingen skrider frem, vil features blive tilføjet og produktet vil endda blive fordelagtigt for andre brancher end blot hotelbranchen. Et eksempel kunne være en cafekæde, der ønsker deres kunder et kort over andre cafeer i cafekæden.

Målgruppe (Bruger) (Dennis) Vores kunders målgruppe er brugerne af vores app. Dermed bliver disse indirekte også vores målgruppe, da vores app skal være bygget til dem og hvad de ønsker.

Da kundens målgruppe kan være meget forskellig, lige fra de festglade unge der søger efter steder at gå i byen, til det pensionerede par, der ønsker at se museer og lokal kunst, stiller det nogle krav til selve applikationen til de mobile enheder. Da applikationen er en man har med sig, når man er ude at gå, og hurtig vil se informationer om det man søger, skal man ikke klikke rundt for meget, og indstille for meget. Applikationen skal være intuitiv, og meget brugervenlig, så man ikke gør det “svært og farligt” for nogle brugere.

Brugerundersøgelse (Dennis) “Hvilken interesse har kunden?”

Kvantitativ undersøgelse. (Dennis) Vi har lavet kvantitative undersøgelser i form af spørgeskemaer samt kontakt til brugere af et kommende system som vores, den fulde undersøgelse kan ses i bilag 5. Formålet med denne undersøgelse er, at finde brugernes behov, for et system til navigering på offline kort(vores produkt). Grunden til at vi foretager denne undersøgelse er, at vi vil vise vores kunder, at brugerne mangler dette. På den måde kan det ses som en slags salgsargument, “Vi har dette produkt, og vi ved dine kunder ønsker dette”. Vores undersøgelse skete online, og blev delt gennem sociale medier uden nogen direkte valgt målgruppe. På denne måde kommer vi vidt omkring, og får lidt fra alle vinkler. Der var 71 der besvarede vores spørgeskema. Vi har spurgt kommende brugere, om hvordan de benytter rejsebrochurer og kort på papir, som de er i dag. Omkring halvdelen af de adspurgte, benytter papirmateriale fra rejseselskaberne, og diverse materiale som ligger i papirsform på hotellerne. Omkring 80% af de adspurgte ville mene, at det er eftertragtet at have alle disse informationer som en applikation på mobiltelefonen, samt have et interaktivt kort, som fungerer offline, så man ligeledes kan finde vej til de forskellige attraktioner. Den mest brugbare feature, som brugerne har meldt tilbage som ønske er, at man skal have et offline kort, så man kan finde vej, men lige efter kommer visning af spisesteder og seværdigheder på kortet. Dvs, at brugerne ønsker sig en kombination af alle de kort

der ligger på hotellerne. Der plejer at være et kort i receptionen så man kan finde rundt, og ved siden af en del reklamer for nationalparker, forlystelsesparker, spisesteder og ting som dette. Alle disse informationer, ønsker brugeren samlet på ét sted, så man kan finde frem mellem dem på et kort. Da vi spurgte brugerne om, hvad der skulle til for at gøre en sådan app attraktiv for dem, så svarede over halvdelen af dem, at der skulle være informationer fra lokalområderne, og ikke blot de informationer som alle de større rejsebøger, og rejseguides skriver omkring - altså information fra den lokale befolkning eller folk der er kender området. Det er kun omkring hver tredje, der benytter kort på mobilen når de er i udlandet, og næsten alle, der ikke benytter kort på mobilen, gør det ikke pga. den høje datapris der er i udlandet. Til sidst spurgte vi brugerne, om de ville benytte en sådan app, der havde et offline kort samt attraktioner, spisesteder og andre lokale ting på. Til det svarede kun 2% nej. Resten ville benytte sig af en sådan app, hvis den havde de førnævnte ting, og hver fjerde ville tillige gerne betale lidt, for at benytte sådan en app.

Kvalitativ undersøgelse (Dennis) Vi har lavet et interview med et hotel i København, som vi er kommet i kontakt med. Her fremlagde vi vores idé til systemet, backend som app, og foreviste wireframes af backend system og android applikationen. Herefter gennemgik vi forskellige moduler, som vi på forhånd havde fundet på baggrund af den kvantitative undersøgelse og brainstorming til projektet. Repræsentanterne fra hotellet satte et tal, fra 1 til 10 på, hvor vigtig sådan et modul ville være for dem. Dette afledte samtidig også en del nye moduler, der blev tilføjet til listen. Gennem interviewet oplevede vi, at der blev tænkt business ind i det med det samme. De skal naturligvis også tjene penge på systemet, så de lagde meget vægt på de dele, hvor de kan få noget feedback tilbage fra deres kunder, og på den måde lave deals med de attraktioner de skal indtaste i systemet.

De brochurer der ligger i lobbyen i dag, er finansieret af både hotellet og omkringliggende erhvervsdrivende, som fælles er gået sammen om at lave en folder der kan ligge på en masse forskellige lokationer. Denne brochure kan erstattes af vores system, med en tilhørende app, som kan virke dynamisk for brugerne. Derudover er der mulighed for hele tiden at ændre indholdet, og målrette det til årstider, events eller til forskellige aldersgrupper. Alt dette uden at skulle få produceret en ny brochure, og tilsendt denne.

Markedsmæssige problemstillinger (Dennis) “Hvordan ser market ud i dag og kan vi konkurrere på det?”

Vi har undersøgt markedet for offline kort apps. Vi er ikke de første der vil lave et kort offline til en mobile enheder. Der findes en del forskellige tjenester, der kan gøre dette. “MapsWithMe” og “CityMaps2Go” er korttjenester, hvor man kan hente et kort til sin telefon, og derved navigere rundt på det kort uden at benytte dataforbindelse. Det er applikationer, hvor man henter et kort ned til sin enhed, og så er der en masse foruddefinerede seværdigheder eller attraktioner udfyldt. Disse fungerer lidt som en digital udgave af Politikkens “Turen går til…”. Disse applikationer og indholdet hertil, er noget som folkene bag skal indtaste og vedligeholde. Har man mange kort over forskellige lokationer, er der lige pludselig meget der skal opdateres, og holdes styr på. Derfor vil vi løse denne problemstilling, ved at lægge ansvaret ud på kunderne (hoteller, caféer, barer, hostels mm), da de er kendte i lokalområdet, og har forbindelserne og kendskab til de små hyggelige steder, som man ikke nødvendigvis opdager, hvis man køber en bog hjemmefra. Det samme gælder for mange andre app’s med kort, både offline on online. GoogleMaps egen, er dog ikke offline, men af samme princip og alle folk kan her tilføje steder, hvilket vi mener bliver uoverskueligt.

“Momondo” rejseselskabet har også lavet en app kaldet “Momondo Places”, hvor de har defineret kort med en masse steder man burde tage hen at se. Ved at lave et system som kunderne kan skræddersy, giver det også endnu mere værdi til deres forretning, idet de laver en “digital folder”, og dertilhørende kort, over de ting som er interessante for deres kundebase. Fra kundens synspunkt køber de ikke en mobil app, men derimod adgang til en platform, hvor de kan lægge det indhold ud til deres kunder, som de ønsker, og det som de mener er vigtigt at se, mens man er i lokalområdet. Problemstillingen med at få kunderne overbevist om, at de skal investere i dette projekt skal derfor løses med, at de kan skabe merværdi i forbindelse med denne platform, til at påvirke gæsterne i den retning, hvor de har lavet aftaler med f.eks. caféer mm. Dette løser vi også, ved at lave muligheden for en masse feedback fra brugen af applikationen, samt motivere brugerne til at melde tilbage til hotellet gennem appen, så de således har mulighed for at se, hvad deres brugere søger, og opsøger. Derudover har kunden mulighed for at vælge præcis det indhold, som deres kunder skal se. Vores produkt er altså et niche produkt til markedet, som lader kunderne selv bestemme deres indhold. På denne måde får vi opfyldt brugernes ønsker omkring det skal være de lokales rekommanderinger til brugeren. Tendensen omkring niche produkter, ses mange steder, som f.eks. twitter og instagram, der hver har deres niche med henholdsvis billeder og tekst-opdateringer, frem for facebooks “vi kan det hele”. Vores produkt vil så være markedets niche for folk der ønsker den lokales rekommandering og ikke alle andres eller den professionelle anmelderes rekommandering.

Teknologiske problemstillinger (Dennis) “Er der nogen teknologiske udfordringer associeret med dette produkt

og kan vi undgå disse?”

Da de systemer vi vil udvikle, sker primært til mobile enheder, vil opdatering af disse platforme også være nogle der hele tiden vil blive opdateret, for at kunne følge med udviklingen. Derfor er det også vigtigt at der hele tiden bliver brugt udviklingstid, på at optimere applikationerne til at understøtte de forskellige operativsystem opdateringer der vil komme, og sørge for at dette hele tiden virker. Denne er en udefrakommende faktor vi ikke kan undgå. Tanken er at benytte Open Street Maps (OSM) og MapQuest som leverandør af korttjenester, da de leverer kort gratis, som man kan benytte. Der er naturligvis nogle begrænsninger, hvis man vil skalere denne løsning op, og have mulighed for at lave flere kort på samme tid. Der er også andre leverandører af kort til mobiltelefoner, så hvis der skulle ske noget med den ene leverandør, så er det forholdsvis nemt at skifte over til en anden en. Der er en del forskellige mobile platforme man kan udvikle til, og blandt de populære er Googles Android, Apples iOS og Microsofts Windows Phone. Da vores produkt starter som et skoleprojekt, udvikler vi først og fremmest til Android platformen, men idéelt set, ville man som minimum også have iOS platformen med, for at fange størstedelen af brugerne. Det er Googles Android og Appels iOS der i dag har størst markedsandel, og tilsammen udgør de omkring 94%2 af markedet til smartphones og tablets. Da de begge er så store og markedsførende, udvikler de også hele tiden deres mobile styresystemer, hvilket gør, at udviklingen af applikationerne der skal køre herpå, også bliver nødt til at følge med udviklingen.

Finansielle problemstillinger (Dennis) “Hvordan kan vi tjene penge på produktet?”

Procentsats taget fra Engadget - http://www.engadget.com/2014/01/29/strategy-analytics-2013smartphone-share/

En af de problemstillinger der vil være, når projektet skal langes ud over disken, og hen til kunden, vil være, hvordan kunden kan tjene penge på systemet. Det vil naturligvis også have en stor impact på vores økonomiske situation, for at kunne sælge produktet til så mange som muligt. Før det kan blive en lukrativ forretning, skal produktet bevise, at det kan skabe merværdi for kunderne, der skal købe det. Da vores system vil blive udviklet hele tiden, og udvidet med funktionalitet løbende, skal der således også være en kontinuerlig betaling. Derfor ville en abonnementsbetaling være den mest naturlige løsning, da kunden derved også kun betaler mens man bruger systemet. Hvis man ikke vil benytte systemet længere, så er det bare at melde abonnementet fra. Det skal selvfølgelig helst ikke ske, at folk bare afmelder sig, i tide og utide, men at kunderne bliver glade for systemet, og bliver ved med at bruge det. En af måderne dette kunne gøres på, er ved konstant at udvikle systemet, så kunden hele tiden får mere value for deres abonnement, samt kan have indflydelse på hvilken funktionalitet de ønsker til systemet. I de undersøgelser vi har lavet, er det også nogle features og moduler, der ville skulle være i et sådan system, før at det overhovedet ville være anvendeligt og interessant for kunden. En af de vigtigste mål for kunden er at skabe flere penge til deres forretning. Og deres brugere skal derved føle at de blot får en ekstra god service fra eksempelvis hotellet, ved at de tilbyder offline kort gennem appen. Finansielt skal projektet også kunne betale sig at lave, og derfor kan en konklusion findes senere i afsnittet, der vil vise hvordan der kan skabes en økonomisk balance mellem os og de virksomheder som bliver kunder af os. Men først og fremmest vil vores produkt starte som et gratis produkt, og senere kan denne løsning med abonnement implementeres som et modul.

Økonomisk problemstilling (Dennis) Som vi har beskrevet afsnittet omkring udvælgelse af procesmodel, er der en masse moduler som kunderne ville kræve af systemet, før det ville være en lukrativ forretning for dem, at benytte et sådan system. 15

Derfor vil det kræve en del udvikling til at starte med, før at man ville kunne få kunder tiltrukket af systemet. Når kunderne så er kommet til, vil der være en masse moduler som er “nice to have”. Disse moduler vil man kunne udvikle videre, og derved tiltrække en anden kundegruppe, som lige netop manglede denne feature, før at systemet var perfekt for dem. Ud fra vores kvantitative og kvalitative undersøgelser, er der lagt en god bund for, at dette system er noget der mangler for både brugerne og for kunderne. Kunderne kan godt se fordelene i sådan et system, og brugerne længtes efter systemet. Der vil derfor være et marked for udviklingen af dette system. Da dette produkt er et iværksætterprojekt, frem for et produkt der er bestilt af en specifik kunde, er det svært at vurdere om det kan betale sig. Nedenfor kommer der nogle udregninger, som viser hvad systemets kerne vil koste hvis det skulle bestilles hos et konsulentfirma, der udfører sådanne systemer. Disse estimater er lavet på baggrund af at kernesystemet skulle kunne laves på 3 ugers arbejde for to mand. Et produkt som vores er estimeret til at tage følgende mandetimer: App: Kerne applikation: 120 timer. Backend system: Kerne system: 120 timer Hvis vi regner med en timeløn på 250 kr./t så ender vi her på (120 + 120) 240 * 250 = 60.000 kr. alene for kernen. Da virksomhederne vi har talt med, ønsker en del ekstra funktionalitet, før at systemet ville være attraktivt for dem, kommer der følgende mere med på regnestykket.

På billedet ovenfor er vist kundens højseste prioriterer af moduler, som skulle implementeres. Uden at gå for meget i analyse her, vil vi lave et overslag der siger hvert modul ca. tager en halv arbejdsuge(20 timer) at udvikle - og dette skal ske til hvert system, så der kan regnes med 2x20 timer per modul. Dette for at give et nogenlunde estimat for hvad dette system ville koste - før det er helt optimalt brugbart for vores kunder. Dette ville give en yderligere estimeret pris på (5 * 20 * 2) 200 timer * 250 kr = 50.000 kr. Så er vi oppe på et tidsestimat der hedder 440 mandetimer for udviklingen af systemet, og det ville koste 440 * 250 kr = 110.000 kr. Dette er naturligvis et skøn. Hvis vi derimod tager det op mod HTML24 hvor vi har været i praktik, vil en timeløn for kunden ligge på 850 kr. Hvis dette var bestilt hos HTML24, som også laver den slags applikationer, ville regnestykket se således ud: App + web udvikling som estimaterne ovenfor: 440 timer. Det giver total 440 mandetimer og med en pris på 850 kr i timen, rammer vi: 374.000 kr. Det er prisen en kunde ville skulle betale for et system hos et konsulenthus, som ville kunne tages i brug med det samme, men kun til Android enheder.

Efterfølgende ville systemet højst sandsynligt også skulle udvikles til iOS, som ville tage det samme som Android appen at udvikle, dvs. 120 timer for kernen, og 100 timer for modulerne. Her rammer vi total 660 timer, hvilket giver en slut totalpris på 561.000 kr. Det vil tage 660 mandetimer at udvikle, som minimum, før at det ville være brugbart for de fleste kunder. Da vi er studerende, og har dette med som en læringsprocess, samtidig med at vi udvikler det, og derfor kun forventer at få 125 kr i timen, ville systemet koste os 82.500 kr i løn vi skulle betale os selv. Da et system som dette typisk ville være abonnementsbetalt af kunden, sikrer man en kontinuerlig betaling, og derved også en fortsat udvikling af systemet senere hen. Hvis systemet for kunden koster 200,- kr om måneden, er det en forholdsvis lav omkostning for eksempelvis et hotel. Det vil hurtigt være tjent ind igen for kunden, og ville kræve at vi havde kunder i (82.500 / 200) 412,5 måneder, før at systemet er tjent ind. Det kunne være en kunde i 412,5 måneder, eller 412 kunder der hver har det i en måned. Dette er naturligvis hårde tal, og uden driftsomkostninger som webhotel, android udvikler konto mm.

Del Konklusion (Dennis + Rasmus) Hos kunderne og brugerne ses en klar interesse i produktet. Med idéen om, at kunderne selv kan vælge deres indhold, vil både kundens og brugernes krav til systemet blive mødt. Vores problemstilling omkring hvem der skal administrere produktet er hermed også løst. Idet omkostningerne kan holdes nede, ved selv at producere systemet, ville det være en meget lukrativ forretning, selv hvis der blot kommer en forholdsvis lille kundegruppe. Da det er kundernes interesse at deres brugere benytter de mobile applikationer, er reklamer mm. ikke medregnet i budgettet, da sådanne omkostninger vil være hos kunden. Derudover ville det også være en fordel at sælge konceptet direkte til en kunde, som så kan præge produktet helt i den retning de ønsker.

Vi har hermed bevist, at der er et marked for systemet, og det er noget kunderne og brugerne ønsker, og derfor er systemet muligt at lave.

Teknologier (Dennis og Rasmus) Versions styring (Rasmus) Det er meget vigtigt for os, at holde styr på forskellige versioner af koden, og kunne holde styr på præcis hvornår tingene er blevet lavet, så man altid kan gå tilbage til en tidligere version hvis noget pludselig ikke virker. Her vil man så kunne gå tilbage til den version før, som man er sikker på virker. Til dette benytter vi GIT3. Git holder styr på præcis hvad for nogen ændringer der er i ens dokumenter efter hver gang man gemmer(commit’er) til git. Git ligger lokalt på egen computer, men vi har valgt også at backe tingene op online, i et gratis repository kaldet BitBucket4. Når vi benytter BitBucket, skal vi “bare” pushe tingene til serveren hvor man har en bruger, og så bliver ens repository gemt på serveren ligesom det allerede er på ens computer. Dette giver en muligheden for senere, at hente hele projektet ved en enkelt git commando i konsolen til, at fetche samtlige versioner fra det repository(og dermed også den nyeste man kan arbejde videre på). Samtidig gør brugen af BitBucket også, at vi hver især kan arbejde på det samme projekt og endda skrive i de samme filer, så finder git ud af præcist hvad for nogen linjer hver af os som programmører har skrevet, og sammenfletter vores versioner. Da vi har to systemer kørende, laver vi to respositories, så de er skilt ad fra hinanden, men alligevel begge nemt tilgængelige og delt imellem vores brugere på BitBucket. Vi vil hovedsageligt kode på hver vores repository, og derfor har vi lavet bestemte regler for hvordan vi benytter git bedst muligt til vores behov. Vores to vigtigste ting er:

3 4

http://git-scm.com/documentation https://bitbucket.org/

1. at alle versioner der bliver committet skal virke og altså være en fuld version. Dette betyder, at man altid kan gå tilbage til seneste version, hvis noget slet ikke fungerer eller man kommer til at skrive noget helt forkert kode og ikke kan finde hoved og hale i det hele. 2. Vi skriver gode og klart formulerede commit-beskeder. Når man lavet er commit er der muligheden for at skrive en besked med. Denne besked beskriver ens commit og forklarer præcist hvad der er blevet lavet, så man altid kan gå tilbage og finde den kode, der er blevet implementeret på et bestemt tidspunkt. Dette gør også fejlfinding meget nemmere, da man i versionerne hurtigt kan få overblik over, hvornår noget er lavet og på den måde komme hurtigt til det, og rette fejlen. Vi bruger derudover en single-branch løsning, så vi kun har et konstant repository for hvert system. Når man har kodet en ny ting til ens system, fetcher man først den nyeste version, derefter rebaser5, og til sidste tillægger man ens seneste commits ovenpå ved et push. Til sidst benytter vi også bitbuckets system til at holde styr på vores bugs. Bitbucket har indopereret en funktion til at oprette issues for ens projekt og give dem en rank for vigtighed. Dette gør det nemt, at holde styr på bugs, så hver gang en ny bug bliver opdaget, vil der blive oprettet et issue. Dermed kan vi hurtigt få overblik over bugs, og finde ud af hvad der skal laves først af dem, ud fra deres rank. Issues bliver også automatisk fjernet fra bitbucket, hvis dens kode er skrevet ind i commit-beskeden - så vores arbejde med at holde styr på hvilke der er lavet bliver også automatiseret af bitbucket.

Android (Dennis) Vi benytter os af Android som den mobile platform for vores mobil udvikling. Android systemet er baseret på en del teknologier, hvor det primære udviklingssprog er Java.

http://git-scm.com/book/en/Git-Branching-Rebasing

Java (Dennis) Når der skal skrives apps til en bestemt enhed eller platform, kalder man det for en native app. I vores tilfælde, udvikler vi specifikt til Android, i kodesproget Java, og dette er derfor en native app. Fordi at vores app er native, og skrevet direkte til Android, har vi mulighed for at benytte og interagere med alle de forskellige hardware komponenter, gennem android operativsystemet, som er i enheden. Vi skal f.eks. benytte os af en sensor i enheden, som giver kompass funktionalitet. Denne funktionalitet skal benyttes til at bestemme hvilken vej man har sin enhed i forhold til kortet. For at finde ud af hvor man befinder sig på kortet, skal vi også benytte os af GPS komponentet der sidder i enheden. Det kunne også tænkes, at vi skulle benytte et kamera i enheden på et tidspunkt, og derfor er det godt at det er skrevet native. Dette er alt sammen noget vi har adgang til gennem Java, og den Android SDK som følger med, når man installerer sit udviklingsværktøj. Det SDK (Software Development Kit) man har, giver et interface til de hardware komponenter der findes i enhederne, så man kan tilgå disse. I Android systemet, skal man bede om lov til at benytte forskellige komponenter, og dette giver man ved at erklære disse tilladelser i android-manifest filen. Når brugeren installerer appen, skal man samtidig acceptere, at appen må benytte disse komponenter.

XML (Dennis) Når grafiske elementer skal genereres, er der forskellige måder at gøre dette på. Android benytter XML til at erklære grafiske elementer. Dette giver en god fordel ved at holde kode og grafiske elementer adskilt. Hvert skærmbillede er i hovedtræk sin egen XML-fil. Dette layout sættes direkte ind i den activity, som køres. Men der er elementer som ikke har brug for en XML fil, f.eks. et ListActivity, der på forhånd er defineret, og ikke behøves at blive defineret.

Navngivningen der bliver brugt, til erklæring af de grafiske elementer i XML, følger tæt navngivningen, som der bliver brugt til klasserne og koden. Elementnavnene passer på klassenavnene og attributterne passer til de metoder, der findes i koden. Et eksempel kunne være et EditText element, som i XML har attributten text, her hedder metoden setText() i koden. En anden fordel ved at benytte XML-lauout filer er, at man kan lave forskellige layouts til forskellige skærmrotationer, forskellige skærmstørrelser og forskellige sprog. Det er en fordel, at kunne lave specifikke layouts til forskellige device, så en smartphone og en tablet kan få vist den samme app, på to forskellige måder, som passer bedst til hver skærmstørrelse.

Nutiteq (Dennis) Nutiteq6 er et eksternt bibliotek man kan benytte til at vise kort direkte i sin app. Det kan være online såvel som offline kort, som det kan benytte med billede kort, eller vektorgrafik, afhængig hvad der løser ens behov. Det understøtter tillige 3D kort, så der er virkelig mange muligheder i det. Det vi skal benytte det til er, at vi i backenden genererer en mbtiles-fil, som indeholder alle kort-billederne og en database, der holder styr på hvor de forskellige billeder hører til. Vores valg er kommet på Nutiteq biblioteket, da det understøtter alle de forskellige ting vi har brug for til vores løsning. Der er mulighed for at sætte nogle afgrænsninger på kortet, så man ikke kan se mere af kortet end de grænser man sætter ind. Ligeledes kan man sætte forskellige andre parametre, som zoom niveau, så man ikke kan zoome helt ud og se hele verden, eller man kan slå rotation af kortet fra mm. En af de muligheder Nutiteq også giver os er, at vi kan smide forskellige objekter på kortet, og det skal vi bruge, når der skal oprettes steder, så man kan vise forskellige steder. Der er ligeledes også muligt at smide vektorgrafik ind, så man kan lave beskrivelse af steder eller på anden vis give informationer i form af f.eks. tekst.

https://github.com/nutiteq/hellomap3d

Backend system (Rasmus) Frontend (Rasmus) Vores backend system bliver bygget så det kan tilgås i en browser, og skal derfor skrives i HTML, CSS og javascript som frontend. Vi vil gøre brug af et frontend framework kaldet Bootstrap. Dette framework gør det muligt, nemt og relativt hurtigt, at designe frontend der både er responsivt til mobil og overholder W3C(World Wide Web Consortium) standarderne7. Bootstrap virker ved, at man inkluderer en javascript fil og en css fil i sin HTML. Derefter kan man benytte HTML markup med foruddefinerede classes, der så bliver stylet og gjort responsive af bootstrap css og javascript filerne. Ud over bootstrap vil der blive lavet custom CSS, til at overskrive nogen af tingene i bootstrap, for at ændre mindre ting som mellemrum mellem elementer osv.

Backend (Rasmus) Til vores backend systems server side sprog har vi valgt, at benytte PHP som hovedsprog. Årsagen til dette er, at det er det web-backend sprog, vi er mest erfarende i. Derudover vil vi benytte et PHP framework kaldet Symfony2, der gør vores udvikling mere fleksibel, og implementerer en MVC lignende struktur. Vores database, vil være MySQL som standard, men systemet vil være opbygget med en abstraktion til databasen, så det er muligt senere at kunne skifte - hvis det bliver en nødvendighed. Det er svært, at skulle forklare hele Symfony2 her i opgaven, men vi vil give et forsøg på at fremhæve de vigtigste dele af frameworket. “Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems. Then, based on these components, Symfony2 is also a full-stack web framework.” 8 - Fabien Potencier

7 8

http://www.w3.org/standards/ http://fabien.potencier.org/article/49/what-is-symfony2

Citatet ovenfor, er af Fabien Potencier, en af Symfony2’s grundlæggere. Hans forklaring på Symfony2, er at det består af en masse low coupling og high cohesion komponenter, der kan bruges i samspil for at skabe Symfony2 full-stack frameworket. At Symfony2 er et full-stack framework vil sige, at det består af en masse komponenter, der kan bruges individuelt. Vil du benytte Symfony2 som et framework, skal du benytte det som et fullstack framework9. I denne opgave vil vi benytte Symfony2 som et full-stack framework, men dog kun berøre de vigtigste komponenter i dette afsnit. De næste afsnit vil fokusere på forskellige dele af Symfony2.

Doctrine (Rasmus)

Doctrine er en samling af PHP biblioteker, samlet til et projekt, der har fokus på persistens og relaterede funktioner. Doctrines vigtigste feature i dette projekt og Symfony2 er dets ORM (Object Relational Mapper). ORM er et abstraktionsniveau til en database, der bliver repræsenteret med objekter i stedet for blot en database tabel(der plejer at være repræsenteret i f.eks. et array eller lign. når databaser benyttes i et programmeringssprog). Dette gør det nemt og overskueligt som programmør, at benytte en database objektorienteret, uden overhovedet at skulle tænke over databasen, da doctrines ORM både opretter og håndterede databasens tabeller og relationerne dem imellem. Til venstre kan man se opbygningen af doctrines ORM, der øverst har doctrine ORM, der er selve klasserne for hver tabel. Nedenunder er 9

Et framework der kræver, hvis du benytter en komponent skal du bruge dem alle, for at det er et framework.

DBAL(DatabaseBase Abstraction Layer), der er klasserne der håndterer abstraktionen fra klasse til tabeller i databasen. Til sidst PDO(PHP Data Object), som er en af PHP’s mest brugte database API’er - dette lag håndterer den endelige connection til databasen og forsendelsen af queries til databasen. Ud over selve abstraktionen til databasen fra doctrines ORM, benytter Symfony2 også doctrine til at generere tabel objekter(Entity Objects). I doctrine er der PHP scripts, der kan kaldes fra en terminal. Disse scripts prompter så brugeren for nødvendig data til at lave et ORM tabel objekt.

Symfony’s struktur og filtyper (Rasmus)

Når man bygger et Symfony2 projekt, kan man selv vælge hvilke type filer man vil benytte. I dette projekt har vi valgt at benytte Symfony2’s egne fil-typer, der gør meget nemmere når man først kender til dem - hvilket vi heldigvis gør(Den anden mulighed er, at skrive alt i php). Bundles (Rasmus)

For at forstå Symfony2, er der et kerneprincip der skal forstås: Bundles, i Symfony2 består næsten alt af bundles. Et bundle kan ses som et plug-in, men hvorfor hedder det så ikke et plug-in? Det er fordi alt i Symfony2 er et bundle, og derfor ikke kan være et plugin - der anses som en ekstra feature. De tidligere omtalte komponenter, som Fabien Potencier nævner i sit citat, er i Symfony2 bundles, med hver deres fast definerede funktion(f.eks. doctrine der håndtere persistens). Når man udvikler selve projektet, kan man inkludere utallige forskellige bundles som allerede er lavet, så man ikke skal genopfinde den dybe tallerken hver gang. Der kan skelnes lidt imellem, Symfony2’s fullstack frameworks bundles, der skal være med før, at Symfony2 kan benyttes som et framework. Også de andre bundles der kan inkluderes eller selv laves derefter(de andre bundles kan ses lidt mere som plug-ins). Et godt eksempel på et bundle, er en af de mest benyttede bundles “FOSuserBundle”, et bundle der gør det muligt at håndtere brugere i systemet.

Twig og YAML

Ud over PHP, er der to andre sprog man skal kende til for at forstå Symfony2. ● YAML: Menneskelæsligt data serialiserings format ● Twig: Template sprog YAML

YAML har fil endelsen “.yml”, og bruges hovedsageligt til konfiguration og routing i Symfony2. Som udvikler laver man yaml filer, der er direkte serialiserede objekter, som symfony så kan udlede forskellige konfigurationer ud fra. Grunden til dette bruges, er at det er nemmere og kræver mindre kode, at sætte forskellige konfigurationer i YAML end i PHP at skulle sætte hver variabel i et objekt.

Et godt eksempel på konfiguration i YAML kan ses ovenfor. Til venstre er et lille skærmbillede af vores config.yml fil, hvor database parametre bliver sat til doctrines ORM. Dette bliver gjort med variabler i YAML som man kan se i skærmbilledet til højre notationen siger lidt sig selv, med let læselig “{variabelnavn} : {værdi}”. Twig

Twig er en template engine, der er bygget specielt til PHP. Kerne konceptet omkring twig er, at når man kalder render-funktionen i sin PHP kode, kan man tilføje variabler i

et array, som man så kan benytte i twig templaten. Derudover er der features som nedarvning af templates og simple logiske funktioner i twig. Dette kunne f.eks. være, at nedarve en master template med alle links til eksterne filer(f.eks. css- og js filer) og eventuelle HTML-head10 contents. Eller der kan loopes over et array fra parametrene tilføjet i render funktionen. Twig kan også tilgå objekter hvis de bliver tilføjet som parameter. Dermed kan man tilgå objektets variabler direkte(twig udnytter getter funktionerne til at tilgå variablerne i et objekt).

Strukturen(Rasmus)

Strukturen i symfony, er bygget op omkring først en routing. Denne routing er YAML filer, som peger på en controller. Denne controller udfører en opgave, og sender et svar tilbage, som ofte er resultatet af en rendering, af en twig template(eller hvis det er en API, et JSON objekt). Det er meget vigtigt, at en controller ikke forveksles med MVC-pattern controlleren. I Symfony2 kan routing.yml filerne ses som controlleren i MVC-pattern. Controller.php filer i Symfony2, kan ses som modellen og hvor logik finder sted. Til sidst kan Viewet ses som twig templaten, der blot bliver renderet af controlleren og sendt tilbage til i et HTTP svar. Nedenfor ses en simpel illustration over Symfony2’s struktur.

http://www.w3schools.com/html/html_head.asp

Denne illustration er en request på URL’en: http://domainname.dk/user/location/ . Denne bliver brugt som illustration, da den er simpel og er en funktion, vi laver i vores andet sprint. Når en HTTP request kommer ind til et symfony projekt, bliver der først kigget i hovedroutingfilen. I realiteten kunne der peges direkte hen på en controller her, men dette er ofte dårlig skik og fjerner meget af selve overblikket hvis alle routes skulle ligge her til

hver enkelt side der kan renderes. Derfor peger man videre ned på en anden routing fil, der tilhører et bestemt bundle. Dette kan ses i den første kodestump på illustrationen, hvor routing.yml filen ser URL’en har en prefix der hedder “/user”, derfor skal der videre stilles til “CustomerBundle”-routing filen. I denne BundleRouter-fil, er der endnu et prefix der hedder “/location”, som i URL’en - denne peger nu hen på endnu en router fil, der er specielt lavet til denne controller(Endnu en opdeling af routing fra bundle til blot en controller for overblik igen). Det næste prefix i URL’en, er så “/”, og derfor kaldes nu en controller. Dette sker med linjen: _controller: CustomerBundle:Location:Index forklaret generelt: _controller: {BundleNavn}:{ControllerNavn}:{Metode i controller} Inde i controleren, er der så en metode med navnet, som der stod i routen, dog med navnet Action som endelse - her indexAction. I indexAction bliver der fetched alle location ORM objekter, og til sidst returneret den renderet template med locations ORM objekterne som parametre. En lille outsticker der ikke blev en realitet i dette eksempel, var boksen med “service.php”. En service er i Symfony2 et stykke logik, der ikke tilhører en bestemt controller, men f.eks. skal kaldes fra forskellige controllere. Hertil opretter man en service, som er en class der kan genbruges flere steder. På den måde slipper man for rendundantkode og har en service class som har høj cohesion og lav kopling.

Filstrukturen i symfony er opbygget med 4 hovedmapper med hver deres formål: ● app/: Applikations konfiguration ○ Konfigurations filer og hoved-routerfilen ● src/: Projektets kode

○ Bundles (BundleRouting, Templates, Controllers, Services) ● vendor/: Tredje parts biblioteker ○ Plugin bundles som f.eks. FOSuserBundle ● web/: (Web root) ○ Roden til web projektet hvor statiske filer gemmes som billeder (i normale tilfælde også javascript og css filer)

Vagrant (Rasmus) Man skulle tro Symfony2, var det eneste der er brug for, for at udvikle et backendsystem. Og det er det også! Men hvad så når, udviklingen skal flyttes til en ny computer, eller en ny udvikler kommer til og skal være med udvikler? Skal han så opsætte alt på sin computer, for at få det til at køre? Dette er både en tidskrævende og irriterende process, som alle udviklere kender. Ikke nok med det tager tid, så er der ofte problemer med versioner af software, og pludselig virker noget ikke på den anden computer. Hvad er så svaret på dette? Vagrant! Vagrant er en open source uviklingsmiljø-virtualiseringssoftware, dette gør vagrant ved at lave en form for wrapper rundt om en virtuel maskine, og styrer denne. I bund og grund består vagrant af en vagrant fil. I denne vagrant fil bliver der defineret, hvilken socket og IP din virtuelle maskine skal køre på. En simpel commando i terminalen “vangrant up”, vil så starte din virtuelle maskine, og hvis den ikke er installeret, vil den installere og starte denne. Vagrant kræver du har vagrant(programmet), virtuel box og ruby installeret på din computer, men vil prompte brugeren, hvis noget mangler. Det smarte kommer så, når man tilføjer en puppet11 til ens projekt. En puppet består vigtigst af alt, af et manifest. I manifestet beskriver man samtlige ting, som det virtuelle udviklingsmiljø skal indeholde. Dette kunne f.eks. være MySql, Apache og Composer. Når en puppet er tilføjet, vil ens virtuelle maskine automatisk installere samtlige ting, der er defineret i ens puppet, og dermed vil alle udviklere, der benytter vagrant til projektet, have præcis samme virtuelle udviklingsmiljø. Dette gør det nemt og enkelt at sætte udviklingsmiljøet op på hvilken som helst computer. Alle udviklere på projektet, slipper hermed for at opsætte servere, eller noget som helst systemet skal køre på. Det eneste de har brug for er deres vagrant. Når vagrant er oppe at køre, pusher man filer hen til den virtuelle maskine, og de bliver dermed eksekveret i det rette miljø.

http://docs.puppetlabs.com/learning/manifests.html

API (Dennis) Vi har i vores projekt både et backend system, som er en webservice, og en mobilapplikation som kører på Android enheder. Disse systemer skal derfor også kommunikere samme, gennem et API. Vores API er en fast defineret protokol, så vi har et fast defineret regelsæt for adfærd systemerne imellem. Vi har valgt at kommunikationen mellem systemerne skal foregå gennem JSON12. De ting der skal kommunikeres i kerne delen er kun envejs kommunikation fra backend systemet og ud til Android enheden. Nogle af de senere moduler, der bliver implementeret, vil muligvis kræve kommunikation tilbage, til backend systemet. Al kommunikation bliver udført via JSON gennem HTTP-Request, nogle GET og andre POST. Vores API er enormt vigtig for hele vores projekt, og intet i systemerne giver mening uden det andet system kan modtage/sende oplysningerne. Derfor gør vi meget ud af konstant, at have et veldokummenteret og updateret API. Dette så vi altid er enige omkring, hvordan vores protokol er defineret, mht. at skal sende og modtage data. Nedenstående er vores dokumentation af API fra kerne delen.

http://www.w3schools.com/json/

Del konklusion (Rasmus) Dette projekt bygger på to forskellige systemer, kædet sammen af en API. Dette API er over HTTP-protokollen og sendes i formatet JSON. Det ene system til vores brugere, er bygget til den mobile enheds OS, Android. Android giver muligheden, igennem programmerings sproget Java, at interagere med den mobile enheds komponenter, og udnytte disse efter behov. Der benyttes XML, til layout og settings i systemet, da android benytter disse. Vores systems grundidé er, at vise kort til brugere offline. Til dette benyttes et bibliotek kaldet Nutiteq. Til vores andet system, webservicen, som er bygget til vores kunder, skal der være mulighed for at oprette lokationer, der hver indeholder et kort. Dette skal være browser baseret og bygges i HTML, CSS og javascrip som frontend sprog og med PHP som server side sprog. Til backendsystemet benyttes der et PHP framework kaldet Symfony2. Dette giver en MVC lignende struktur og bliver opbygget i komponenter kaldet Bundles, der skaber lav binding og høj cohesion.

Udviklingsprocessen (Rasmus) Moduler, Chores og Bugs (Rasmus) Dette afsnit omhandler de tre forskellige elementer der bliver valgt og produceret i et sprint. Afsnittet er placeret her i rapporten for at give bedre forståelse for resten af indholdet. Vi har i dette projekt en samlet betegnelse for disse 3 som er: en opgave. Moduler er en termonologi vi benytter utroligt meget i dette projekt. Derfor er det også meget vigtigt at forstå præcist hvad et modul i dette projekt er. Dette projekt består af to uadskillelige dele, en backend til vores kunder og en app til brugerne. Disse to snakker sammen via. et API, og alle funktionerne der bliver tilføjet til den ene, giver ingen mening før den også er tilføjet til den anden - Opret et kort i backend, giver ingen mening uden at kunne se det kort på sin app. Derfor er vores projekt skrevet ned i moduler. Et modul består af 2 user stories - en user story for brugeren og en user story for kunden. Eller sagt på en anden måde, en user story der skal laves i backend samt API (PHP, HTML mm. ) og en user story der skal

laves i appen (Android). Så når der bliver nævnt et modul, er det altså en funktion, der bliver tilføjet til systemet i både backend og app’en. Chores er funktionaliteter, der ikke har nogen bruger-værdi, men værdi for selve produktet eller programmøren. Som f.eks. at skifte fra en database til en anden. Dette giver reelt set ikke brugeren nogen forbedring, men måske giver det hele produktet en forbedring, eller programmøren får et nemmere arbejde fremover. Chores vil vi anse og planlægge som var det moduler i vores system, og endda estimere dem ligeledes, så de kan fremgå i planen over et sprint. Hvornår de skal laves, er på baggrund af os som programmører, hvornår vi mener de er mest optimale at implementere. En chore der altid vil være i alle sprints, er opdatering af vores API. Da API’et er essential for vores produkt og grunden til de to user stories hænger sammen til et modul i først omgang. Bugs er fejl i systemet, der kommer efter den færdige implementering. Disse bliver estimeret ud fra hvor vigtige de er, og planlagt sammen med chores og moduler i et sprint. Bugs vil ofte få meget høj prioritet, da nogen kan have stor indvirkning på brugen af begge systemer.

Scrum roller (Rasmus) Vores brug af scrum vil være uden brug af roller, da vi egentlig kun er to programmøre. Derfor vil vi begge være både: product owner, developer team og scrum masters.

Backlogs (Rasmus) Vores brug af product backlog vil være samlingen af alle vores moduler og chores. Denne produkt backlog vil være 100% dynamisk, modulerne og chores kan til hver en tid skiftes ud, og komme nye til i løbet af et sprint. Vi vil udvælge hvilke moduler og chores der skal indgå i sprint-backloggen ved starten af et nyt sprint. Dette giver os fleksibilitet og muligheden for hurtigt, at indrette os efter nye eller modificeret krav fra kunden, eller fra vores brugere. Nedenfor kan ses en illustration af en iteration (et

sprint). Det starter med udvælgelse af moduler fra product-backloggen. Derefter består et sprint af en arbejdsuge med 5 dage af 8 timer. Den lille runde pil, der ses oven for sprint-pilen, illustrerer en dag på ca. 8 timer, og det er her vi hver morgen vil gøre status omkring hvad der skal laves i løbet af dagen, samt hver aften gøre status over hvad vi nåede den dag. Vores udvælgelse af sprint-backloggen, vil være på baggrund af hvad vi får mest ud af at lave næste gang, og hvad der er tid til at lave af moduler, i et sprint. Selve processen vi gennemgår, for at udvælgehvilket modul vi får mest ud af at lave, er forklaret længere nede i afsnittet omkring udvælgelse af moduler.

Retrospective meeting / sprint review meeting (Rasmus) I slutningen af scrum sprints, afholder man normalt 2 møder, der har hver deres funktion: sprint review meeting: at gennemgå opgaverne der blev lavet og ikke lavet i sprintet, samt at præsentere produktet for stakeholders. Retrospective meeting: en reflektion over sprintet og hvad der gik godt i sprintet og hvad der kunne blive gjort bedre. Disse to møder vil vi slå sammen til et møde, som vi blot kalder retrospective meeting, der kommer til at variere lidt fra sprint til sprint. Men selve pointen med mødet vil altid være det samme: hvordan gik sprintet, hvad kunne vi gøre bedre og hvad siger vores kunder og brugere til vores nye funktioner. Grunden til det dette vil variere lidt fra sprint til sprint er, at vi ikke har mulighed for, at lave en direkte undersøgelse fra hos brugeren og kunden for hvert sprint. Dette pga. vi endnu ikke har den store kundekreds eller brugerskare endnu. Vi vil udvælge nogen sprints hvor det er særligt relevant, og forsøge at komme i kontakt med vores kunder og 34

brugere for at få feedback. Når projektet går live, vil vi få masser af information fra f.eks. Google Play Store, der vil give os feedback fra vores brugere direkte, når de rater vores app, eller skriver en kommentar. Disse vil ikke altid være relevante for netop dette sprint og vil derfor blive håndteret hen af vejen når de er relevante. Det er også her, når vi har kontakt til kunden eller brugeren, vi vil kunne opdatere vores product backlog, med nye prioriteringer eller nye moduler til systemet. En ting der altid vil gå igen er de to først nævnte ting: hvordan gik sprintet og hvad kunne vi gøre bedre. Dette indbefatter også at opdatere vores SPP’s pr. sprint - så vi ved præcist hvor mange SPP’s vi kan vælge til udvikling i næste sprint.

Scrum board (Rasmus) Vi benytter scrum board til vores udvikling, så vi i hvert sprint ved præcis hvad der mangler, og kan gøre status på, om vi kan nå vores mål, eller om der eventuelt skal flere moduler eller chores til sprintet. Vores scrum boards er skrevet sammen med vores sprintbacklog i et googledocs spreadsheet(excel lign. dokument), hvor der vil blive opdateret statuser løbende for hvert modul og chore i det gældende sprint. Scrumboarded består af opgaverne i sprintet, med en tilhørende stadie-status omkring udviklingen. De 4 forskellige stadier er: Waiting, Doing, Testing og Done. Waiting er inden selve udviklingen er begyndt på opgaven. Doing er når opgaven er under udvikling. Done er når selve designet og udviklingen er færdigt. Testing er en intern, og hvis det er muligt ekstern, kvalitetstest af opgaven, f.eks. ved direkte kontakt til en kunde, der kan afprøve det, eller vi selv forsøger at brugerteste opgaven så godt vi kan. Done er stadiet når vi mener opgaven er klar til, at blive implementeret i live versionen af systemet og altså kommer med i næste opdatering.

Scrum poker (Rasmus) For at estimere vores opgaver, og selve kernen af system som udvikles inden modulerne, benytter vi en scrum metode kalder Scrum Poker. Scrum Poker består af både en måleenhed SPP(Scrum Poker Points) og metoden at estimere disse på. SPP 35

er givet ved en aftalt opgave som alle i projektgruppen har lavet. Denne opgave får så værdien 2 i SPP, og herefter vil resten af modulerne der skal estimeres, blive baseret på hvor lang tid de vil tage, i forhold til den tidligere opgave. F.eks. hvis man mener det tager lidt mere end dobbelt så lang tid at lave, så vil man give denne opgave 3 eller 5 SPP. Måden man så fordeler disse point på er, at ved Scrum poker hvor hver “spiller” har kort med værdier(ofte givet ved fibonacci 1-2-3-5-8 osv. da det skaber dynamik og forskellighed). Hver spiller vælger et kort og viser det samtidig til hinanden, hvis der er uenighed diskutere man kort og vælger kort igen. Er der enighed bliver dette estimatet for dette modul.

Risikoanalyse af opgaver (Rasmus) Efter vores opgaver er estimeret gennem Scrum Poker, vil vi forsøge at gennemdiskutere hver opgave, for at finde ud af, om der er en speciel risiko involveret i denne opgave. Disse risici vil kun blive nedskrevet, hvis de er yderst relevante og har mulighed for direkte at påvirke et sprints forløb. Det kunne være hvis en risiko omhandler et umuligt aspekt, eller den teknologi vi, under estimatet, havde taget udgangspunkt i, simpelthen skal udskiftes eller lign. Når vi finder sådan en risiko, vil vi forsøge at estimere denne ved SPP’s, så det er muligt at lave en eventuel buffer i dette sprint, hvor denne indgår.

Udvælgelse af opgave i et sprint (Rasmus) Inden vi overhovedet kan begynde at tænke på at udvælge opgaver, er det mest relevante for os at finde ud af præcis hvor mange SPP´s vi kan nå at lave på et sprint. Dette vil vi gøre i startfasen under produktionen af vores kerne-del af programmet. Da vores produkt gerne skulle gå live, og kunne blive taget i brug af vores første kunder allerede efter kernedelen, er det yderst vigtigt for os, at vi ved præcis hvor meget vi kan nå at programmere i hvert sprint når denne del af overstået. Hvorimod inden kernedelen er færdig, har vi mere frihed til at overskride en tidsgrænse, da vi endnu ikke står til regnskab direkte overfor kunder, men kun os selv. Derfor vil vores første estimat gå på,

at vi kan nå samtlige points i vores kernedel på tre sprints, og derefter ved vi, om vi kan overholde dette antal SPP’s per iteration eller ej. Man kan se kernedelen lidt som en kalibrering af SPP’s per sprint. Efter kerne-delen er overstået, skal vi i starten af hvert sprint, udvælge hvilke opgaver vi skal lave i dette sprint. Reglen for dette er, at vi aldrig må vælge flere SPP’s end tidligere sprints, og skal så vidt muligt, forsøge at opretholde samme antal points, som sidste sprint. Hvis vi f.eks. når 30 points i et sprint, skal vi udvælge 30 points til næste sprint - når vi så at blive færdig før tid, kan vi vælge nogen ekstra points, og dermed må der i næste sprint igen vælges flere points. Men hvordan vælger vi så hvilket modul der bliver det næste? Dette skal ske på baggrund af kundens rangering af moduler og vores tekniske viden omkring opgaverne. Vi vil tage faktorer ind i overvejelserne som risici, estimeret tid, brugerens rangering og nødvendighed for systemet(hvis f.eks. en chore eller bug burde laves). Men som helhed vil systemet være påkrævet alle opgaver med rangeringen over 8 ud af 10 før det er brugbart nok til vores kunder kan bruge det i praksis. Derfor vil disse selvfølglig været klart opprioriteret.

Iterationen i et sprint (Rasmus) Udviklingen i hver sprint vil være en iteration af følgende: ● Udvælgelse af opgaver ud fra estimater - dannelse af sprint backlog. ● Wireframes af relevante moduler ● Design af moduler - hvis dette er nødvendigt ● Programmering ● Brugertests og API tests(teste samspillet mellem backend og app) ● Opdatering af produkt-backlog ● retrospektive meeting / sprint review meeting

Sprints (Dennis og Rasmus) Dette afsnit vil omhandle vores sprints. De første tre sprints er udviklingen af selve kernen af systemet, og de opgaver denne kerne består af, er det absolutte minimum af systemet, således at systemerne er klart til at kunne blive taget i brug af en eventuel kunde og bruger. Derudover giver vores udvikling af kernen os også muligheden for bedre, at kunne estimere fremtidige sprints, når nye opgaver skal udvælges til produktion. Her vil vores viden omkring antallet af SPP’s vi kan nå per sprint, blive mere og mere præcist med tiden. Afsnittet vil tage udgangspunkt i nogen af de vigtigste moduler, der bliver udviklet i løbet af et sprint, fra design og programmering til opdatering af sprint backlog. Udvælgelsen af hvad vi viser i afsnittene, er på baggrund af hvad, vi synes har mest relevans i sprintet. Samtlige moduler, estimater og risici kan ses i bilag 2.

Kernen (Rasmus) Selve kernen af vores system består af en række opgaver. Disse opgaver bliver udvalgt i en logisk rækkefølge, i forhold til om de er afhængige af hinanden, og om tilsvarende opgaver passer ind i sprintet. Hvis der f.eks. mangler 3 SPP’s er en opgave med 3 eller 2 SPP’s prioriteret højere end en med 5 SPP’s gør. Dette selvom denne burde blive lavet først, da vi ikke må overskride grænsen for antallet af SPP’s, der bliver sat af til et sprint, for at kunne holde tidsplanen. Oversigten over samtlige opgaver i kernen kan ses i bilag 1.

Sprint1 - Kerne del 1 (Dennis og Rasmus) Udvægelse af userstories/moduler (Rasmus) I dette sprint har vi udvalgt chores, moduler og user stories, baseret på logik og afhængighed. Disse opgaver er valgt, da de skaber en “bund” for resten af opgaverne i kernen. F.eks. har vi to chores omkring opsætning - en i hvert system. Disse to chores bliver vi nødt til at tælle med i vores planlægning, da de er meget tidskrævende, men

giver en signifikant værdi til produktet og den senere udvikling. Vores estimat inden start var, at vi kan nå omkring 26 SPP’s per sprint.

Ovenfor ses et billede, af vores scrumboard og sprint backlog, som vi laver i samme spreadsheet. Dette skærmbillede er taget i slutningen af vores sprint, men ikke helt til sidst. Grunden til vi vælger at vise billedet inden sprintet er færdigt, er for at vise hvordan der bliver arbejdet med dette. Vores opgaver er skrevet i første kolonne, med beskrivende navne og SPP’s i næste kolonne. Man kan se på vores scrumboard kolonne, hvor mange SPP denne opgave har fået, og til sidst status for hver opgave. Her i kernedeludviklingen, er der visse opgaver, som ikke er moduler, da de kun består af en user story. F.eks. har opgaven “simple html sider og css/js setup”, ikke noget med android app’en at gøre, og derfor er det bare en user story relatereret til vores backend system. Denne opgave er også lidt speciel, da den både er en user story, der beskriver nogen simple html sider. Samtidig er det også en chore, da opsætning af css/js er nødvendigt her(grunden til der står “opsætning”, er fordi da vi benytter Symfony2, er det ikke bare at linke til filerne. Der skal oprettes nogen routes, som laver den mest optimale inkludering af javascript og css filer, kun der hvor der er brug for dem). I dette sprint, blev vi hurtigere færdige med opsættelsen af vagrant, end forventet og derfor kunne et ekstra bonus modul blive tilføjet til PHP delen - Log in(Her er det dog

ikke et modul, men blot en user story, da denne kun findes i backend-delen af opgaven, og derfor ikke har to user stories). 5 ekstra SPP’s var altså tilføjet til dette sprint. Dette vil medføre en afledt effekt der gør, at vi så i næste sprint, kan vælge endnu flere opgaver, da vi har nået flere SPP’s end forventet i dette sprint.

User stories (Dennis) Her er et uddrag af nogle af de user stories, vi har arbejdet med i dette sprint. 1. Som kunde vil jeg kunne logge ind i systemet, så jeg ser de ting der har relevans for mig 2. Som kunde vil jeg kunne oprette mig som bruger, så jeg kan komme i gang med at benytte systemet. 3. Som kunde vil jeg kunne generere et kort ud fra det område jeg selv vælger 4. Som bruger vil jeg kunne hente et kort, ved at indtaste et kode i appen. 5. Som bruger vil jeg kunne fjerne et kort fra min enhed

Wireframes (Dennis og Rasmus) Her er udvalgte wireframes fra sprintet, som også vil være de cases, der bliver omtalt i afsnittet for dette sprint. Vi har udvalgt disse idet vi desværre må prioitere hvad vi vælger at vise i denne rapport. Resten af vores wireframes kan ses i bilag 5. I dette afsnit kan man se wireframe, samt resultatet. På den måde kan man se sammenligningen af vores produkt kontra vores wireframe.

Wireframe - Log in (Rasmus)

← Wireframe

â&#x2020;? Resultat

Wireframes - Download kode (Dennis)

â&#x2020;? Wireframe

← Resultat

← Wiraframe

← Resultat

Design (Dennis og Rasmus) Design login - (Rasmus)

Designet for backend systemet’s login, krævede ikke noget videre design. En ORM klasse blev oprettet, for en bruger i system med de nødvendige variabler. Det vigtigste element her, var sikkerheden og kryptering, som er beskrevet i vores afsnit om sikkerhed. Derudover bliver der benyttet et Symfony2 bundle kaldet FOSuserBundle(Friends Of Symfony userBundle), som giver muligheden for at opsætte restriktioner i Symfony2 (områder/url’er hvor visse brugere har adgang, mens andre ikke har).

Design download kode - (Dennis)

Til vores download kodemodul, har vi her skulle definere et API, som appen skal spørge backend systemet om, for at få de oplysninger, der skal benyttes.

Vi har her valgt at API-kaldet skal ske gennem en HTTP-POST request. Når android enheden laver en request, med den indtastede kort-kode, kommer der et JSON-objekt tilbage, med forskellige oplysninger som, “code”, “name”, “map”, “size”, “url”, nogle kort afgrænsninger, og et max zoom niveau. “Name” er det eneste som brugeren kommer til at se, som kommer til at være det navn for kortet, som vises i appen. Alle de andre felter, er nogle som android skal bruge, for at vise kortet korrekt. Dette respons fra backend systemet, fylder typisk kun et par få KB, og indeholder et link til hvor kortet kan downloades henne, da det er kortet, der er det datatunge i dette system. Den første del henter JSON objektet, og viser brugeren størrelsen af kortet, og den næste del henter kortet ned, hvis brugeren accepterer download af kortet. Dokumentation af API’en kan findes under “Teknologier - API”. Inden der sættes noget til download, og inden nogle oplysninger vises, tjekkes der om den kode man prøver at downloade, allerede eksisterer på enheden først.

Programmering (Dennis og Rasmus) Programmering - Login (Rasmus)

Da dette skulle programmeres, skulle der som tidligere nævnt installeres et bundle til Symfony2. Dette bliver gjort vha. composer13. Først skal der tilføjes følgende til composer.json filen14: { "require": { "friendsofsymfony/user-‐bundle": "~2.0@dev" } } 13

http://symfony.com/doc/current/book/installation.html En fil der definere, samtlige biblioteker som composer automatisk skal downloade for ens projekt og benytte. 14

Derefter kan man i konsolen eksekvere kommandoen:

“php composer.phar update friendsofsymfony/user-bundle” Denne kommando fortæller composer, at den skal opdatere FOSuserBundle, og da det endnu ikke er installeret, vil den installere denne. Når dette er gjort kan man nu benytte FOSuserBundle, som andre bundles i Symfony2. Efter dette bundle er installeret, laver vi et ny bundle, der så nedarver fra dette bundle. Dette gør det muligt, at overskrive alle filer i det første bibliotek, og på denne måde kan man overskrive f.eks. templates, så de bliver ens egne, eller lave custom controllere(logisk lag), hvis man får brug for at overskrive noget senere hen i udviklingen. For at nedarve fra FOSuserBundle, benytter vi koden, der kan ses i skærmbilledet til højre. Ved at benytte linje 5, fortæller vi symfony, at vores BaseUser15 er defineret af FOSuserBundle’s ORM klasse User. I linje 14 nedarver vi så denne klasse fra BaseUser, som altså nu er FOSuserBundles User klasse. Således ender vi op med at det er vores User, der er BaseUser. Nu kan der så styres, en hver brugerrelateret ting som f.eks. login, gennem denne entity klasse og dets bundle. I forhold til login, kan vi altså nu overskrive den tidligere login template med en ny twig template, men stadigvæk benytte logikken for login formen fra FOSuserBundle, som håndterer selve oprettelsen af en session og om hvilken type user brugeren er. Dermed styres hvad brugeren har adgang til(i dette system er der dog kun en type bruger). Yderligere omkring login sikkerheden er beskrevet i sikkerheds afsnittet længere nede i rapporten, idet selve sikkerheden omkring login er et helt emne for sig selv. 15

BaseUser, er en terminology i symfony, der basalt set fortæller symfony hvad for en class der er vores bruger class. Denne kan man så benytte i forskellige brugerrelateret sammenhæng.

Programmering - Downloade code (Dennis)

Det første der startes med, når der skal oprettes en Activity (et skærmbillede) er at definere hvordan det skal se ud i en layout fil. Layoutfilen er et XML-dokument, der definerer hvilke elementer der skal være, og hvordan de skal se ud. Her til højre er et udsnit af vores layout fil, til download kode user story. Der er vist 3 forskellige elementer. Et TextView, hvilket har en reference til strings.xml filen, hvor man gemmer alle tekster, så man nemt efterfølgende blot kan oversætte en enkelt fil til et andet sprog. Samtidig har man også alle tekster samme sted. Det næste er et EditText element, hvilket har nogle flere attributter på sig. F.eks. er der sat en tekstfarve, en background som har endnu en reference til en drawable fil, der definere hvordan dette element skal se ud med borderline, farve, tykkelse mm. Dernæst er der en Button, som er en knap. Denne har ligeledes en reference til en tekst, og ligeledes en reference til en drawable fil. Idéen med at lave referencer til filer er, at man definere et sted, hvordan man f.eks. vil have en knap til at se ud. Og så alle de knapper man vil have til at se ud på samme måde, skal man bare referere til den drawable-fil, man har lavet til knappen, i feltet background.

Det næste der sker er, at man skal vælge hvilken layout fil, ens activity skal benytte, og det gøres således → Således er ens javakode koblet sammen med layout-filen. Det næste er, at man opretter alle sine elementer i koden, og forbinder dem med elementerne i layout-filen. Når det er gjort, kan man begynde på den logik man vil have ind i appen. Det der skal ske, når man klikker på download knappen er, at man skal kommunikere med API’en, og få et JSON-objekt tilbage. Alt dette skal ske i en AsyncTask, som er en tråd, der samtidig kan tilgå UI tråden, og opdatere nogle grafiske elementer, hvis der er brug for det. Der oprettes her et HttpPost objekt, og et HttpResponse som henter alt det indhold som vi får fat i, på vores kald. Det ser i koden sådan ud:

Efterfølgende bliver alle JSON felter sat ind i et objekt, og gemt ned i en database på enheden, og så starter en ny activity, hvorpå man kan hente selve kortet, hvor url’en hertil ligger i et af de felter, man allerede har hentet ned, som er gemt i databasen. For at sikre, at vi ikke får en masse forskellige database connections, har vi valgt at benytte singleton pattern til at få en databaseforbindelse. Vi benytter SQLite, som er en lokal filbaseret database, på android enheden.

Brugertests (Dennis og Rasmus) Brugen af test i backend systemet, var ikke videre relevant her, da implementeringen af login hovedsageligt bygger på et framework, der er veldokumenteret og testet. Testen her var, at efter opsættelsen, blev der logget ind på forskellig vis, og forsøgt at tilgå de sider, der var tilgængelige. Og omvendt at forsøge at tilgå siderne der kun var

tilgængelige for brugere som er logget ind. Begge ting var implementeret korrekt. Da vi havde fundet ud af, hvad vores app skulle bruge af oplysninger, og da vi havde defineret hvordan vores API skulle se ud, lavede vi et testAPI, da vores backend system ikke var klar til at generere dette endnu. Men da appen krævede at få nogle oplysninger tilbage, for at kunne færdiggøre denne opgave, oprettede vi et test-API, som kunne give appen det JSONobjekt som den forventede. Vi opbyggede det, således at vi manuelt genererede et kort, og skrev linket ned til dette i feltet “Map-url” og manuelt udfyldte alle de andre felter, så vi vidste præcis hvad der kom ind i appen. Dernæst testede vi hvordan appen reagerede, hvis den fik forkerte oplysninger ind, eller der var oplysninger der manglede, og på den måde eliminerede eventuelle fejl, der måtte komme, når man skulle kalde det rigtige API.

Retrospektive meeting (Dennis og Rasmus) I dette sprint havde vi ingen yderligere kunde eller bruger kontakt. I dette tidlige stadie, var vi lige efter udgangen af vores startfase og der var derfor ikke nogen opdatering af vores product backlog. Vores estimater var på dette tidspunkt, sat lige inden sprintets start, og ændrede sig ikke siden. Til gengæld var dette et meget succesfuldt sprint for os. Vores sprint backlog fik endnu en user story tilføjet, omkring login til backend systemet, da opsættelsen af vagrant gik hurtigere end forventet. Derudover kunne vi nå lidt flere points end forventet, og på den

måde hæve maks antal SPP’s i næste sprint fra 26 til 31.

Sprint2 - Kerne del 2 (Dennis og Rasmus) Udvægelse af userstories/moduler (Dennis) I dette sprint har vi valgt nogle af de næste moduler, der skulle implementeres. I dette sprint var der en risiko, som blev estimeret med ind i planen, da det var en stor risiko procent. Hvis den så skulle blive en en realitet, så var den estimeret med ind. Hvis ikke at den blev en realitet, så kunne man vælge et andet modul med samme SPP, til at tage pladsen i stedet for. I vores tilfælde blev risikoen en realitet, og det var derfor godt, at den var estimeret ind i planen. De moduler, der er blevet valgt ud til dette sprint, er dem der naturligt ligger i forbindelse med sprint 1. Der er blevet oprettet alt med brugerhåndtering i backenden, som opret bruger og login. Dertil skal man kunne oprette en lokation. Her blev risikoen en realitet, da det var sværere end som så, at klikke på et kort, og få den til at agere som forventet. På app delen er det download kort og visning af kort, der er punkterne som skal laves i dette sprint. Kortet hentes gennem det test-API’et som blev lavet i sidste sprint, da det rigtige API endnu ikke er lavet. Visning af kortet er blevet udvalgt her, da den skal danne grundlag for selve applikationen, og derfor er et af de vigtigste elementer i appen. Det er også derfor, den har så stor værdi i backloggen. 49

User stories (Dennis) Her er et uddrag af nogle af de user stories vi har arbejdet med, i dette sprint. 1. Som bruger vil jeg kunne hente et kort ned på min enhed 2. Som kunde vil jeg kunne oprette mit eget et kortudsnit 3. Som bruger vil jeg kunne se et kort, så jeg kan navigere rundt Wireframes (Dennis og Rasmus) Wireframe - Opret lokation: Overview (Rasmus)

← Wireframe

← Resultat

Wireframe - Opret lokation: Opret (Rasmus)

Wireframet til opret lokation, blev lavet i samarbejde med kunden, da vi lavede interview med et dansk hotel. Det vigtigste for kunden var, at det er nemt og overskueligt og placere ens kort. Derfor blev vi enige om, at selve placeringen af kortet skulle være med tryk på et kort, hvor man ønsker centrum af ens eget kort skal være. Her er genkendelsesfaktoren også stor, da man er vant til at bruge kort som google maps osv. og dermed ville det blot være at trykke på sådan et kort. Vi fandt så på, at selve kortet

skulle illustreres med en ramme rundt om centrum, der viser præcist hvor ens kort befinder sig, så kunden hurtigt kan se, om det er den rigtige størrelse og placeret korrekt.

← Wireframe

← resultat

Wireframe - Vis kort (Dennis)

â&#x2020;? Wireframe

â&#x2020;? Resultat

Design (Dennis og Rasmus)

Design - Opret lokation (Rasmus)

For at oprette en lokation, var det logiske at starte med databasedesignet, så der kunne laves en entity klasse(entity er navnet for en tabel i Symfony2) til vores ORM. Dette blev gjort med skitse af ER-diagrammet(Entity Relationship) i hånden, som kan ses på billedet nedenfor.

Det mest basale for en lokation er, at den er ejet af en bruger og indeholder et kort. At den er ejet af en bruger, er lavet ved en foreign key, der er many-to-one. Hvilket vil sige at en bruger kan have flere lokationer, men ikke omvendt. Dette er illustreret ved den lille trefork i forbindelsen på illustrationen mellem de to tabeller. Den næste ting der skulle indtænkes var, hvordan man gemmer et korts placering og størrelse, i en database.

I vores projekt er et kort altid kvadratisk. Dette kort laves ved, at kunden vælger det punkt, på et verdenskort, som skal være centrum for hans kort. Her vælger vi at gemme centerkoordinaterne for længde- og breddegrader brugeren har valgt. Dertil skal vi så have en størrelse på kortet. I realiteten kunne vi bare gemme størrelsen direkte på lokationen, men dette ville senere forårsage irritationsmomenter og vi ville ikke overholde normalformerne for databasedesign. Vores størrelser bliver derfor placeret i en tabel for sig selv, og får tildelt en beskrivelse. På denne måde kan der nemt blive tilføjet nye størrelser bruger kan vælge imellem, ved blot at tilføje denne til tabellen for størrelser. Selve kortet skal gemmes i en fil, derfor er der en kolonne i databasen med mapfile, som indeholder en sti til selve filen. Men i dette sprint er der endnu ikke lavet “opret kort”, men blot at gemme de respektive værdier til kortet.

Design - Vis kort (Dennis)

Inden vi kunne gå i gang med at vise kort, skulle der defineres nogle specifikationer på, hvad kortet skulle bruge af data for at virke optimalt. Vi var klar over, at vi ikke skulle vise hele verden, og at vi ville have et begrænset kort. Derfor besluttede vi os for at et “Map-Objekt” skulle indeholde følgende oplysninger, som beskrevet til højre. Alle oplysninger er gemt i en SQLite database på den mobile enhed. Når Activity’en, der skal vise kortet, bliver oprettet, får den ID’et med på kortet der skal vises. Dette har vi lavet et lille simpelt

dataflow diagram over, så man kan se sammenhængen af datastrømmen, og flowet mellem de forskellige activities(skærmbilleder).

Programmering (Dennis og Rasmus) Programmering: opret lokation (Rasmus)

For at starte på opret lokation, må der først laves en entity klasse til vores doctrine ORM. Denne skrives som en PHP klasse med ER-diagrammet som baggrund. Et udsnit af denne klasse kan ses til på skærmbilledet til højre. Her bliver hver attribut lavet som en privat variable,

med en getter og setter funktion. På billedet kan man se hvordan en relation bliver sat op, ved at man med docblock16 skriver nationer til doctrines ORM omkring variablen og hvordan den skal være i databasen(må den være null? er den private key? osv). Dette kaldes i Symfony2 for annotation17. Derudover giver docblock også fordele, hvis man benytter en IDE(Integrated Development Environment), der kan genkende dette. På denne måde kan man f.eks. få autocomplete og genkendelse til ens objekter. På billedet kan man se hvordan en foreign key bliver sat op, ved at skrive relationstypen “ManyToOne” efterfulgt af hvilken entity(tabel) der refereres til. Under selve relationstypen bliver der defineret foreign keyens navn og hvilken kolonne den refererer til. Selve oprettelsen af en lokation, er en form som kunden skal udfylde og dermed vil en lokation blive oprettet. En form i Symfony2 kan laves på mange forskellige måder, men den vi vælger at benytte, er et element i Symfony2 kaldet “formtype”18. Her laver man en klasse, der håndterer alt omkring formen, men det vigtigste klassen håndterer er: validering af input i backend og oprettelse af fields(input felter). På denne måde skaber man en low coupling og high cohesion, idet denne form nemt kan genbruges, og pålægger meget konkret ansvaret for formen i denne klasse. Det er også nemmere på denne måde, at editerer denne form, da man ved præcist, hvor der skal ændres, når det hele er samlet et sted. I Symfony2 kan man nedarve fra den abstrakte klasse “AbstractType”, der søger for metoder og håndtering af alt validering, hvis man blot opretter sine felter i formen korrekt.

http://www.phpdoc.org/docs/latest/for-users/phpdoc/basic-syntax.html http://docs.doctrine-project.org/en/2.0.x/reference/annotations-reference.html 18 http://symfony.com/doc/current/book/forms.html 17

I koden ovenfor kan man se et udsnit af klassen for LocationsType, som er selve formen for lokationer. Her bliver der nedarvet fra AbstractType, og implementeret den nødvendige funktion “buildForm”. Denne metode indeholder en form builder, som er Symfony2’s måde at lave forms på. Metoden setDefaultOptions bruges til at sætte hvilken entity klasse, der skal bruges til formen. Her sætter vi den til vores entity Location, på denne måde ved Symfony2, at formen hører til denne entity. Når vi så tilføjer f.eks. “name” til formbuilderen, ser Symfony2, at “name” findes i entity’en og benytter dennes værdier. Disse værdier kan ses i koden til højre, som er et udsnit af hvor “name” attributen bliver sat i lokations entity klasse. Endnu en feature der bliver brugt her, er at en foreign key også kan sættes i formen. Vores lokation indeholder en foreign key til mapSize, her tilføjer vi denne til formen på linje 21. Derefter tilføjer vi så parametre, der fortæller dette er en entity, og et array som gør det mere specifikt. I arrayet fortæller vi konkret, hvilken class den skal benytte, her “MapSize” ,og hvilken attribut, der skal vises til brugeren(som han kan vælge ud fra). Som default når Symfony2 bruger foreign keys i en form, vises det som en dropdown i formen. 57

Men selvom denne form virker efter hensigten, mangler der stadigvæk nogle ting. Som der står i afsnittet omkring wireframet for denne userstory, så ønsker kunden ikke at indtaste værdierne længde- og breddegrader for centrum selv. Dette skal gøres ved tryk på et kort så de automatisk bliver udfyldt. Dette bliver gjort ved, at skjule elementerne i formen med CSS og lade et javascript fylde disse ud. Dette skabte problemer under udviklingen, da det tog meget længere tid end forventet. Både at finde det rigtige kort bibliotek, men også selve kodningen og forstå bibliotekets API. Det var til gengæld i planlægningen forudset, at der var en risiko omkring dette, som vi havde sat til 5 SPP’s og dette var ca. hvad det tog ekstra at lave. Måden dette kort bliver tegnet på, er ved at benytte et javascript bibliotek kaldet OpenLayers19. OpenLayers er objektorienteret javascript, og biblioteket giver os mulighed for, at vise kort til brugeren samt oprette EventListeners20 på kortet. Javascript koden genererer en EventListener på kortet, der registrerer klik på kortet, og henter koordinaterne for dette punkt. Dette punkt bruges så til, at indsætte den firkant på kortet som kan ses i det tidligere afsnit for wireframes. For at tegne en firkant med OpenLayers, skal man bruge to koordinater, øverste koordinat til venstre og nederste koordinat til højre i længde- og breddegrader. I koden nedenfor, ses den metode der bliver benyttet til at beregne punkterne til firkanten. Parametrene den modtager er centerpunktet for firkanten. Med simpel cikel matematik, kan disse to punkter beregnes. Vi har valgt, at simplificere vores formel lidt, så vi ikke skal ud i avanceret kugle matematik. Således antager vi at Jorden er flad, og på den måde får vi et nemmere matematisk regnestykke med fejl, der ikke spænder meget mere end max 200m. ved vores største kortstørrelse (på 10 km.) og omkring 10m med mindste kort(400m). Dette ser vi som acceptabelt. 19 20

http://openlayers.org/ http://www.w3schools.com/jsref/dom_obj_event.asp

Her tager vi jordens radius i meter, og størrelsen for kortet(som vi henter fra brugerens valg af kort størrelse) og gemmer dem i variabler. Herefter gemmer vi to variabler en med minus tal for halvdelen af størrelsen og en med plus tal for halvdelen størrelsen, for at få de to punkter(halvdelen fordi vi allerede er i centret for firkanten og kun skal række halv den ene vej og halvt den anden vej). Herefter omregner vi i linje 40 til 43 dette til radianer, så vi nemt bagefter i linje 46 til 49 kan omregne disse til længde- og breddegrader.

Programering - Download kort (Dennis)

Når man har indtastet en kode, ser man oplysningerne omkring koden, som er navn og størrelsen på kortet. Herefter kan man så begynde at hente kortet ned, når man trykker på knappen “Download”. Her begynder processen så, at hente selve kort-filen ned til enheden.

Hele download processen sker ligeledes i en AsyncTask, som er en tråd, der også kan kommunikere med UI’en tråden, så man kan vise brugeren, hvor langt den er i download processen. En AsyncTask har nogle forskellige metoder, som bliver kørt i forskellige dele af processen. Den starter med en onPreExecute(), hvor vi gør nogle af UI elementerne klar, og skriver at download processen begynder. Det næste der bliver kørt, er doInBackground(), her startes tråden og til højre er vist hvordan der bliver oprettet forbindelse til kort-filen, og hentningen af denne bliver startet. Mens den er i gang med at downloade kortet, bliver der kaldt en metode der hedder onProgressUpdate(), som kan arbejde med UI’en imens kortet er i gang med at hente. Denne metode bruger vi til at opdatere et tekstfelt med hvor mange procent af processen, der er fuldført. Da det tager noget tid at hente data ned, så skal brugeren se en progressbar, så der kan følges med i, at programmet ikke er gået i stå. Progressbaren bliver opdateret, så man grafisk kan se, hvor langt den er nået, samt at vi skriver det i procent. Når hentningen af kortet er færdig, bliver metoden onPostExecute(). Denne benytter vi til at åbne det hentede kort.

Programmering - Vis Kort (Dennis)

Når kortfilen er hentet ned på enheden, skal den også vises. Til at vise kortet, skal vi benytte os af det eksterne bibliotek, Nutiteq. Det første der skal oprettes er et MapView, som kan vise et kort. Dette MapView kan indeholde nogle forskellige lag. Derfor tilføjes kortet til laget, og dernæst bliver laget sat som vores “BaseLayer” i MapViewet.

Koden til at tilføje dette layer ser sådan ud: Først oprettes layer, som her er af typen MBTilesMapLayer, som tager imod nogle forskellige parametre. EPSG3857()21 er et koordinat projektions system, som de kort vi henter ned benytter sig af, til at regne ud, hvor de forskellige tiles præcist ligger henne i forhold til verden, og til hinanden. De næste to felter er, hvad laget skal have af zoom niveauer tilgængelige. Zoomniveau 0 er hele verden og 19 er så tæt, at en cm på kortet svarer til 5 m i virkeligheden. Det gør blot laget klart til alle disse niveauer, så man kan benytte alle disse herpå. Det næste parameter, er udelukkende et unikt id, så man kan holde styr på de forskellige lag, hvis man vil have flere lag i et MapView. Dette gør vi dog ikke brug af. Følgende parameter, er stien til hvor .mbtiles-filen ligger henne. Denne fil indeholder al information omkring kortet i en database, som ligger inde inde i filen. Derudover indeholder den alle de tiles (billeder), som er dem der skal vises i MapView’et. En af de andre features vi gør brug af gennem Nutiteq biblioteket er, at sætte nogle bounds på kortet. Bounds er afgrænsninger af kortet, og linjer som man sætter som ydergrænser, så man ikke kan komme længere ud end disse punkter. Dette har relevans for vores system, da vi arbejder med kort, som ikke dækker hele verden, men blot et udsnit af et lokalområde, og derfor kræver afgrænsninger. 21

http://wiki.openstreetmap.org/wiki/EPSG:3857

Koden for det, ser ud som følgende:

Først oprettes der to MapPos, som er et koordinatsæt, i det format som kortet benytter. setMapBounds() sætter selve afgrænsningen for kortet, og setBoundingBox() sætter det visuelle udsnit af kortet, som man ønsker at se. I dette tilfælde er det de samme punkter, men kan kan vælge hvilket som helst koordinatsæt, som skulle være det visuelle kortet zommede ind på fra start.

Brugertests (Dennis og Rasmus) Da vi skulle teste appen på en bruger denne gang, var de funktioner der var implementeret rimelig simple, og mulighederne for at gøre noget forkert begrænsede. Derfor gik meget af vores test i denne omgang med brugervenligheden af produktet. Det at indtaste en kode, og downloade et kort, og til sidst få vist kortet, blev testet. Hele flowet mellem at hente et kort og vise andre kort blev her gået igennem. Vores første udkast var en stack med skærmbilleder, som er udgangspunktet for at åbne nye activities på Android enheder. Dvs. at når man åbner en ny activity, kommer den oven på den nuværende, og hvis man trykker på tilbage knappen, bliver denne activity fjernet. Dette flow optimerede vi, da det også gjorde oplevelsen af appen bedre. Det blev optimeret på den måde, at skærmbillederne flytter sig op og ud af skærmen, og næste kommer ind fra bunden, og omvendt, så det virker som om at visse skærmbilleder altid er over eller under hinanden. Brugertesten af selve applikationen blev fuldført uden yderligere kommentarer til brugen. Brugertesten af backend systemet, blev udført først ved test af os selv igennem flere forsøg omkring at oprette et kort. Den næste blev udført af kunden selv under vores retrospektive meeting, hvor vi havde kontakt til hotellet, vi før havde været i kontakt med, som fik lov at prøve funktionen. De synes det virkede efter hensigten med tryk på

kortet og ens kort blev afgrænset.

Retrospektive meeting (Rasmus) I dette sprint, havde vi mindre kontakt til kunden, der kunne give os feedback omkring oprettelse af lokation i backend systemet. Dette var, som tidligere forklaret, en succes og kunden synes det virkede efter hensigten og deres ønske. Efter denne korte samtale med kunden, gik resten af vores retrospektive meeting med at opdatere vores SPP’s vi når per iteration, der i denne iteration gik fra 29 points til 34, da vi stødte ind i en risiko, der fyldte mere end forventet af iterationen. Men dette var kun positivt, da vi stadigvæk nåede vores mål og nu kunne vælge flere points til næste sprint.

Sprint3 - Kerne del 3 (Dennis og Rasmus) Udvægelse af user stories/moduler (Dennis) I dette sprint har vi taget resten af vores user stories for kernen, så vi kan få kernen fuldendt. Vi har ventet med at generere kortene i backenden til sidst, da alle andre funktioner skulle være på plads, før at denne gav mening at implementere. I den forbindelse stødte vi også på en risiko, som blev en realitet, da kort tager lang tid at generere. Denne risiko var vi klar over ville være der, og derfor blev der i første omgang afsat tid til en risiko. Vi fandt dog aldrig en løsning på den afsatte tid til risikoen, og måtte som

afledt effekt lave vores risiko til en ny til en selvstændig user story. I stedet blev der fundet en substitut funktion, som blot advarer brugeren omkring det tager lang tid, at generere et kort, inden han begynder. Den nye user story er tilføjet til produkt backloggen. På app siden er der blevet implementeret en vigtig feature, som at vise sin lokation på kortet der er hentet ned på enheden. Denne funktion er også først valgt her i slutningen, da den er afhængig af, at der er et kort. Og da kortet først blev implementeret i seneste sprint, er en GPS-visning af lokaliteten først udvalgt her. En anden user story, der hænger sammen med GPS-lokationer er, om man er indenfor kortets afgrænsninger. Denne kan også først implementeres efter at GPSfunktionaliteten er på plads, hvilket er derfor at disse er udvalgt i samme sprint. Alle disse funktioner har virket mod test-API'et, og først da alt er implementeret korrekt, kan vi teste op mod det rigtige API, hvilket er derfor, at dette er valgt til sidst i dette sprint.

User stories (Dennis) Her er et uddrag af nogle af de user stories vi har arbejdet med, i dette sprint. 1. Som kunde vil jeg have mulighed for at logge ud, når jeg er færdig med arbejdet 2. Som bruger vil jeg kunne se min aktuelle position på kortet 3. Som bruger vil jeg vide, om jeg er inden for kortets afgrænsninger.

Wireframes (Dennis) I dette sprint har der ikke være nogle wireframes, da vi i backenden har lavet ting som generering af kort og oprette det API som appen skal kommunikere med. Det eneste sted hvor man kunne have brug for et wireframe, er i preview af lokation, men dette ville med al sandsynlighed ligne det wireframe for oprettelsen, og derfor var det ikke nødvendigt at lave et wireframe til dette.

P책 app siden er der heller ikke lavet nogle wireframes. Dette skyldes at de visuelle elementer er s책 sm책, som at vise ens egen lokation, at det ikke ville give nogen mening at have et wireframe der udelukkende viser sin egen lokation.

Design (Rasmus) Design - Generere kort (Rasmus)

P책 billedet ovenfor ses et diagram af flowet i oprettelsen af en lokation, som blev lavet inden programmeringen gik i gang med opret lokation. Det logiske valg for os, var at

tegne dette i et slags aktivitets diagram over flowet i koden. Diagrammet blev tegnet i hånden, men genskabt bedst muligt digitalt, for at vise den her. Det vigtigste der fremgår af diagrammet, er valget omkring en service i Symfony2 som skal laves, for at generere et kort. At generere selve kortet, kan ændre sig med tiden, omkring hvordan dette skal gøres, men vores første valg er, at benytte et bundle lavet af en dansk virksomhed kaldet HTML24, der benytter gratis kort fra OSM(Open Street Maps). Senere fandt vi frem til, at vores risici omkring kortet tager for lang tid at generere, blev en realitet og dette må løses på anden vis - lige nu er der implementeret en løsning der blot advarer kunden om at det taget lang tid at lave et kort. Det mest optimale ville i fremtiden være, at have en asynkron opgave der f.eks. kørte i en tråd der generede kortet, da det tager alt for lang tid at lave kortet i samme arbejdsflow - og brugeren må vente på det bliver lavet.

Programmering (Dennis og Rasmus) Programmering: Generer kort (Rasmus)

For at generere selve kortet, blev der oprettet en service. I denne service bliver der brugt samme metode til at udregne kortets placering med koordinater som i javascript, her dog skrevet i PHP. Derefter benytter den biblioteket til at generere en kort fil.

På koden ovenfor kan man se selve hændelsen, efter formen for opret lokation er blevet valideret. Dette er altså de 4 sidste step i flow-diagrammet i design afsnittet. 66

Først benytter vi vores entity-manager22, til at persiste vores entity(med dataen fra formen). Når den er persisted bliver den flushed til databasen og dermed gemt. Derefter vil den have fået et unikt ID, og koden kan nu genereres. Den bliver genereret med en tilfældig md5 hash på 6 karaktere og derefter efterfuldt af ID’et fra entity’en. På denne måde sikrer vi os, at alle lokationer har en unik kode til når de skal downloades af en bruger. Efter den er genereret bliver entity objektet opdateret i linje 60 og derefter persisted og flushed igen. Når koden er lavet, kan der nu laves et kort. Da kortets filnavn også skal være unikt vil den bruge samme navn som koden efterfulgt af filendelsen. Til sidst returneres en renderet version af lokations overviewet(twig templaten) til brugeren så han kan se, at hans nye lokation er oprettet.

Programmering - API (Rasmus)

Koden ovenfor er en stor del af koden for API’et. Her bliver lagt vægt på senere implementeringer og fremtiden. Det skal forstås på den måde, at det er tilpasset til at flere kort bliver fundet, selvom det lige nu kun er et kort per kode. Det første der bliver 22

En manager i symfony2, der benyttes til alt, der har med entities at gøre, deraf navnet: entity manager.

gjort i linje 24, er at fetche samtlige lokations objekter. Disse bliver så i linje 33 itereret over, så hvis der er flere vil det blot blive endnu et element i objektet. For at få det korrekte JSON format, bliver der brugt stdClass som er et anonymt objekt i php. stdClass kan anvendes til f.eks. at skabe objekter on-the-go som her, og senere JSON encode disse. Iterationen finder vi derefter samtlige af de parametre, der skal med i JSON objektet. Her bliver vores service blandt andet også brugt igen, hvor metoden til at få firkantens to hjørner bliver fundet igen, da denne skal sendes med til APP’en.

Programmering - Vis GPS position (Dennis)

Programmeringen af GPS-lokationer kræver, at enheden har en GPS-sensor. Det har de fleste smartdevices i dag. Men man er faktisk også i stand til at få en lokation, uden brug af en GPS-sensor, nemlig det som hedder Assisted GPS23, eller AGPS. Assisted GPS går i alt sin enkelthed ud på, at man får nogle lokationer baseret på netværk. Det kan være fra mobilmaster, eller fra trådløse netværk. Sidstnævnte kræver dog internetforbindelse, da enheden spørger nogle servere omkring sin lokation, når den kan se disse netværk. Vi har implementeret det, at den både lytter efter GPS-signaler, og at den lytter efter netværkslokationer.

Ovenfor vises koden for hvordan vi bruger de forskellige lokations enheder. Linje to får en liste tilbage med alle de forskellige lokationsudbydere, der er på enheden, og “true” som står til sidst, giver kun listen tilbage, hvor denne udbyder er aktiveret. Med udbyder menes der udbyder af lokationer, hvor GPS og netværks lokationer er eksempler på udbydere.

http://en.wikipedia.org/wiki/Assisted_GPS

Udover at sende lokationenskoordinater, sender GPS sensoren også flere ting med, når man spørger efter lokationer. En af de ting er usikkerheden på det koordinatsæt man har fået. Denne usikkerned varierer meget, afhængig af hvor godt signalet er det pågældende sted man er, og dels af hvor man får lokationen fra, om det er via mobilmaster eller direkte fra GPS-sensoren. Derfor har vi valgt at lave en metode, der tester om den lokation vi får ind nu, er bedre end den gamle lokation vi havde. Dette er med til at fjerne lokationer der lige pludseligt stikker ud fra det normale. Grunden til at vi har gjort dette er, at tidligere erfaringer har vist, at dette giver et meget bedre flydende brug af appen.

Brugertests (Dennis) Brugertesten af app funktionaliteter i dette sprint, udførte vi selv, i form af at gå ude i “marken” og prøve de forskellige ting af, som vi havde fået implementeret. Vi havde genereret et kort i backenden, som vi hentede ned på android enheden, og dertil kunne se sin lokation på kortet. Vi fandt ud af, at den kompas-sensor der kommer i de forskellige enheder, som vi har tilgængelige er af lidt forskellig kvalitet. Koden virkede fint som den skulle, men selve de data, som sensoren i enheden leverer tilbage til programmet, var nogle gange lidt tvivlsomme, da den godt kunne tage “nogle hak” en gang imellem. Alle de brugertest vi lavede på appen omkring placering virkede efter hensigten.

Retroskektive meeting (Dennis) I dette sprint har vi heller ikke haft nogen kundekontakt. De dele der er blevet implementeret i dette sprint, er dels testet af os selv, og dels heller ikke noget som kunden har haft meget at bruge til, da sådan noget som API’et er noget der kører i baggrunden, som kunden alligevel ikke kan se. Det er lykkedes os at få kernen færdig og endda til de respektive estimater.

Kommunikationen var rigtig god inden API blev implementeret, og aftalerne var lavet på forhånd, så at gå fra test-API til rigtig API gik glat igennem. Det der gik mindre godt var, at en af vores user stories fik udløst en risiko. Dermed blev der som afledt effekt af dette, skabt en ny chore: generer kort i en tråd.

Sprint4 - Modul (Dennis og Rasmus)

Udvælgelse af userstories/moduler (Rasmus)

Ovenfor ses vores scrumboardet for dette sprint(øverst user stories for backend system, nederst user stories for app’en). I dette sprint stoppede vi før sprintet var overstået, pga. dagen for aflevering af projektet ramte inde i vores sprint. Men vi begge opgaver var tættere på slut end forventet ved dette tidspunkt, så vi regner stærkt med at nå det inden sprintets afslutning. Dette er det første sprint, hvor vi udvælger fra vores moduler, frem for at programmere på selve kernen af system, da denne blev færdig i sprint 3. Så dette sprint er det første hvor vi har skulle analysere hvilke modul der skulle udvælges til udvikling. I dette sprint startede vi med, at tage kontakt til endnu en potentiel kunde, der rangerede vores moduler efter kundens ønske omkring implementering. Dette for at præcisere vores valg endnu mere, så det ikke kun var det ene hotels mening. Rangeringen kan ses i bilag 2 sammen med alle modulerne og gennemsnittet

for de to moduler der er valgt til dette sprint kan ses længst til højre i sprint backloggen (henholdsvis 10 og 9). De to kunder var dog meget enige omkring opret sted, var det allervigtigste modul. Hvilket giver dem muligheden for at tilføje steder på deres kort med. Denne var et forholdsvis højt estimeret modul, og derfor var der ikke meget mere plads i sprintets backlog til flere opgaver. Der var dog et forholdsvis lille modul kaldet “Kategorier til steder”, som gør det muligt at kategorisere stederne. Dette modul kunne vi som programmører se godt kunne programmeres sammen med opret sted, og det var endda estimeret til kun 3 SPP’s derfor blev denne valgt som det andet modul der skulle laves. Da vi her til færdiggørelsen af rapporten endnu ikke er færdige med sprintet, kan der kun ses vort fortløbige sprintbacklog. I denne backlog kan man se vi faktisk har doing på begge opgaver. Dette fordi vi i begge vores systemer, valgte at lave designet for disse sammen, da de gav mening at skrive som var det en userstory.

User stories (Dennis) Her et uddrag af de user stories der skal nåes i dette sprint. 1. Som en kunde, vil jeg have mulighed for at oprette et sted på kortet, for at vise lokalt indhold til brugeren. 2. Som en bruger, vil jeg gerne kunne se interesante steder på et kort, så man undgår papirs brochurer. 3. Som kunde vil jeg kunne sætte en kategori på et sted, så overskueligheden bliver bedre 4. Som bruger vil jeg kunne se forskellige steder i forskellige kategorier.

Wireframes (Dennis og Rasmus)

Wireframe - Kategori & Opret sted : Overview (Rasmus)

Nedenfor ses wireframe af overview over samtlige steder for en lokation, her går kunden ind når han vil tilføje steder til en lokation og se hans steder allerede tilføjet. 71

Wireframe - Kategori & Opret sted : Opret (Rasmus)

Nedenfor ses wireframet for opret sted, her tilfĂ¸jet kunden nye steder til hans lokation, ved tryk pĂĽ kortet placerer han selve stedet - som ses markeret ved et kryds.

Wireframe - Vis steder & Kategorier (Dennis)

I dette wireframe, bliver der vist steder pĂĽ kortet i forskellige kategorier. De forskellige kategorier er her markeret med forskellige farver pĂĽ kortet og i listen.

Design (Dennis og Rasmus)

Design - Kategori & Opret sted (Rasmus)

På billedet ovenfor ses det første design der blev lavet i dette sprint - En opdatering af ER-diagrammet fra sprint 2. Dette fordi der endnu engang i dette sprint, skulle laves entity klasser til ORM. Her bliver der lavet en entitet kaldet Place, der er et sted. Dette sted indeholder en længde- og breddegrade som placering. Derudover består det af et navn og en beskrivende tekst. Da vi har slået de to userstories sammen her, er der også en kategori på stedet. Denne kategori er en foreign key, da den både indeholder et navn, men også en farve - der

skal bruges til at indikere kategorier på app’en. For at sikre at der kun er et sted der skal ændres hvis en kategori skal ændres eller tilføjes lægger vi ansvaret over på denne database og blot sender informationerne igennem API’et til app’en. Dette gør det nemt at vedligeholde i længden. Et sted har også en foreign key til en lokation, da et sted sidder “fast” på en lokation, dette illustreret ved en many-to-one connection mellem tabellerne. I dette sprint er det også relevant, at lave en delvis klasse model(blot et udsnit af en klasse model, da det ikke er hele systemet der behøver designet her). Denne klasse model skal vise hvordan relationen mellem klasserne for lokation og et sted fungere, da denne er lidt anderledes end blot ER-diagrammet, da vi får flere muligheder, når vi benytter et abstraktions niveau som vi gør igennem doctines ORM.

Den delvise klasse model kan ses ovenfor. Her kan man se hvordan alle de private variabler stemmer overens med ER-diagrammet. Dertil er der getters og setters til alle disse, som benyttes til for at tilgå disse variabler. Hele grunden til, at denne klasse

model er relevant, er der dog er en afvigelse fra ER-diagrammet, der er tilføjet en ekstra variabel på location. Denne variabel er et array, bestående af places. Dette er noget man kan gøre når man arbejder med abstraktion og en feature som doctrines ORM stiller til rådighed. Ved at tilføje et array med places, og lave den rigtige ORM docblock, der beskriver at forholdet er “OneToMany”. Hermed vil et lokations objekt nu indeholde et array med samtlige af de places der har den som foreign key. Derudover er der tilføjet metoderne: ● getPlaces() ● addPlace() ● removePlace() Disse metoder gør det også muligt, at tilføje steder eller fjerne steder direkte fra et lokations objekt. Alt i alt, gør dette at man som programmør kan tænke “et sted ejer sine lokationer”, i stedet for “et sted ejes af en lokation”. Og det er i fremtiden nemmere, at holde styr på en lokations steder, da man får alle sted objekterne for en lokation blot ved, at have lokations objektet.

Design - Opdatering af API (Dennis)

Når stederne er blevet oprettet i backenden, skal de også hentes ned i appen. Derfor har vi været nødt til at opdatere vores API, så stederne nu også bliver hentet ned, sammen med alle de øvrige detaljer. Her vælger vi stadig at hente alle oplysninger ned, i samme JSON objekt, datatamængden ikke er yderligere stor, og da forbindelsen allerede er oprettet til backendens API. De felter der er kommet ekstra på, ser ud som følgende.

Da der kan være flere steder der er oprettet på et kort, er API’et oprettet, så den har et array med steder. Derved kan altallet af steder variere fra kort til kort. Vi har i “category”-objektet lagt både navn og farve ind, så det bliver backenden der styrer, hvilket navn kategorien skal have, og hvilken farve disse vil få. Derved laver vi appen dynamisk, så den ikke behøves at bliver opdateret, hvis vi vælger at skifte nogle kategorier ud, eller hvis farverne skal ændres.

Afslutning (Dennis og Rasmus) Resten af sprintet, er ikke med i denne rapport, da rapporten skal afleveres i midten af dette sprint.

Del konklusion (Dennis) I vores sprints, har vi udvalgt de user stories, som har haft mest relevans for sprintet. Disse er blevet designet og beskrevet, hvor der var behov for det. Det har været for at dokumentere og skabe overblik over hvordan at de forskellige elementer fungerer. Efter det er designet hvordan systemet skal være, bliver de forskellige dele programmeret.

Et vigtigt element fra designfasen, som vi har haft god udnyttelse af er wireframes. Her er der noget konkret kunden kan forholde sig til, og det har hjulpet os i forståelsen af hvordan tingene skulle designes. Vores kerne er blevet konstrueret gennem 3 sprint, og skaber en base for udviklingen af moduler efterfølgende. Vi har draget nytte af elementerne fra scrum til at estimere de forskellige moduler, og ud fra det kan har vi kunnet skabe en holdbar plan, som vi tidsmæssigt har kunne overholde.

Sikkerhed (Rasmus) Dette afsnit omhandler sikkerheden i vores projekt. Det er et vigtigt afsnit der er valgt, at have med pga. det er en ting vi har fokuseret meget på under udviklingen, og derfor er relevant, selvom det som sådan ikke besvarer vores problem formulering, men er tanker og overvejelser vi har gjort under og inden udviklingen. I dette projekt fokuserer vi mest på sikkerhed omkring vores backend system. Dette fordi vores android APP ikke behøver samme form for sikkerhed - i hvert fald i det tidlige stadie. Vores APP har ingen følsom data, der ikke må blive gemt, og derudover er android et lukket system, hvor man skal have adgang til selve enheden for at få adgang til data. Vores API kræver heller ikke meget sikkerhed, da vores tjeneste for brugeren som skal bruge API’en, er gratis - i hvert fald som projektet ser ud i løbet af de tidligere stadier. Til gengæld kræver vores backend system en masse sikkerhed. Selvom der ingen personfølsom data er gemt i vores backend system, så gemmes kundens oprettede lokationer(med tilhørende kort) og instillingerne for disse. Da dette system er tiltænkt professionelt brug, er det meget vigtigt, at uvedkommende ikke kan tilgå disse og andre i kundens lokationer. Som beskrevet tidligere i rapporten, er det tiltænkt at kunden også skal betale for at benytte vores tjeneste, og derfor er det selvfølgelig også vigtigt, vi sørger for sikkerheden omkring dette (specielt hvis kontooplysninger skal gemmes senere). Vores system er bygget op omkring hver kunde har sit eget login. Når kunden så logger 78

ind, bliver han redirected til en del af hjemmesiden, hvor han kan styrer sit indhold (lokationerne med kort). Måden vi deler systemet op, er ved hjælp af URL’s. Brugerens “område” på siden vil have URL’en “http://domainname.dk/user/”. På denne måde er det let og overskueligt, at lave restriktioner. Er man ikke logget ind, kan man ikke tilgå nogen sider med URL’en “/user/”. Måden dette bliver gjort på i Symfony2, er vha. BaseUser, som tidligere forklaret i afsnittet omkring sprint 1. Dertil skal der så opsættes en security fil i Symfony2, som definerer præcist hvad brugere har adgang til.

På skærmbilledet ovenfor, kan man se opsætningen af brugerroller(brugertyper) i Symfony2. Her bliver der defineret et rollehiraki(hvilke roller der existerer). Der er lige nu i systemet kun én rolle, som er vores kunde. Denne rolle kalder vi “ROLE_USER”. Ovenfor rollehirakiet er access_control, her bliver der vha. URL’er defineret, hvilke roller der har adgang til hvad. Her bliver en URL defineret som en path, og “^" symboliserer, at det kan være alt(så det eneste Symfony2 koncentrerer sig om er, om hvad der står efter “^" i URL’en). På skærmbilledet er det opsat så vores “^/user” sti, kræver at man er logget ind som “ROLE_USER”, hvorimod alle andre er “IS_AUTHENTICATED_ANONYMOUSLY” - hvilket vil sige de ikke er logget ind og altså alle kan tilgå dette sted. Sikkerheden i forhold til side-restriktioner er dog ikke det eneste. I databasen hvor kodeord skal gemmes, er det mest optimale at hashe eller kryptere sine kodeord. På denne måde kan man sikre sig, at selvom ens database på nogen måde skulle falde i de forkerte hænder, så er brugernes kodeord stadig ikke tilgængelige.

Hvordan ved man så om man skal kryptere eller hashe sine passwords? Kryptering er en metode, hvor man gør noget ulæseligt for andre end de egnede. Dette sker ofte vha. en krypterings nøgle til at dekryptere det krypterede data(og til at krypterer dataen i første omgang). Dette gør det altså muligt både for dig selv, men desværre også for hackere og andre, at dekryptere koder, hvis man blot kender nøglen der bliver krypteret med, og algoritmen der bliver brugt. Disse ville kunne findes i kildekoden, hvis den blev lækket på nogen måde. Hashing derimod, er en måde at kortlægge (engelsk: mapping) data. Her er det efter selve hashingen næsten umuligt, at “dehashe” og få den originale værdi tilbage. Det bedste man kan få ud af en hash, er en kollision (engelsk: collision). Dette er når man finder en værdi, der kan genskabe samme hashværdi igennem algoritmen. Men selv med en kollision kan man ikke være sikker på, dette er den rigtige værdi. Både hashing og kryptering har svaghed over for brute force24, som man i krypterings tilfældet vil få adgangskoden og i hashing tilfældet vil få en kollisions-værdi. Begge tilfælde vil give adgang til siden men kun med kryptering og så kodeordet. Dette findes der imidlertid også en løsning på. Løsningen hedder salt, og er unik tilfældig data, der bliver knyttet til kodeordet inden det krypteres og på den måde skal der gættes både en salt og et kodeord, hvilket gør brute force næsten umulig. Hele valget ender så ud i; Vil man kunne tilgå kodeordet igen, hvis f.eks. brugeren har glemt sit password? Så brug kryptering, da dette bliver muligt, men mindre sikkert. Er det lige meget med at tilgå kodeordet igen, og skal det bare bruges til verificering igennem et login? Så brug hashing, da denne metode er sikker i forhold til kodeordet ikke bliver afsløret. Vi har valgt hashing med salt i denne opgave, da vi ikke ønsker at give vores brugere kodeordet igen, hvis de glemmer det, men blot give dem et nyt, de senere kan skifte. Denne løsning er sikrest i forhold til, at gemme brugerens kodeord til vores behov. I skærmbilledet med kode nedenfor, kan ses endnu et stykke af security.yml filen. Her sættes vores hashing funktion til FOSuserBundle: sha512, hvilket vil sige den benytter en 512 bits hash(resultatet af hash-algoritmen vil blive 512 bits lang). 24

en metode hvorpå man forsøger samtlige muligheder i en rainbow tabel(der består af alle mulige kombinationer af tegn)

Under vores valg af hashfunktion, er et stykke kode, der beskriver stierne til login og security check. Dette bliver i FOSuserBundle kaldet firewall, da det er denne sti, der skal benyttes til at tjekke validering, inden en bruger bliver dirigeret videre til den rigtige side(du skal som bruger godkendes før du bliver ledt ind i systemet, som en firewall). Her er også endnu en sikkerheds opsætning “csrf_provider”. CSRF(cross-site-requestforgery) er egentlig ikke så relevant endnu for vores side, men kunne blive det, hvis den kommer til at have med bankoverførsler at gøre. I bund og grund er det, et angreb der udnytter browsers tilliden fra et site til en browser. Hvis f.eks. en hacker laver et link, der får brugerens browser til at sende en falsk form-submit(en post request med samme værdier som formen kræver for at simulere form-submit) til vores site, der f.eks. skifter kodeord for brugeren i baggrunden. Dette bliver nu umuligt, da vores forms har et hidden-field25 med en kode, der skal matche en tilsvarende på serveren. Derfor kan der altså ikke laves et script, der udfylder formen, da den gemte værdi i et hidden-field så ikke vil blive genereret. Vores opsætning med csrf_prover, er en funktion i Symfony2, vi aktiverer den blot, og sætter den som hidden fields i vores forms. Dette kan ses på skærmbilledet nedenfor. Der er to linjer kode, hvor den første linje er selve formen, der bliver lavet med det første form tag, og en sti genereret igennem twig. Den anden linje laver så et hiddenfield, der bliver udfyldt med et csrf token, der er den gemte kode til formen.

et input felt en html form der ikke er synligt.

Konklusion (Dennis og Rasmus) Hos kunderne og brugerne er en klar interesse i produktet, hvilket vil sige der er et marked for produktet. Specielt imødekommer vi vores kunder og brugere, ved at sætte administrations ansvaret over på kunderne. På denne måde giver brugerne det indhold de vil have. Produktet består af en webservice og en native app til android, da dette er det mest udbredte system til mobile enheder. Til app’en benyttes Java og XML som udviklings sprog, da det er med disse man udvikler til android. Til webservicen benyttes PHP med et framework kaldet Symfony2. Symfony2 giver en MVC lignende struktur og bliver opbygget i komponenter kaldet Bundles, der skaber lav binding og høj cohesion. Produktet bliver udviklet med procesmodellen scrum, der bygger på den agile tilgang. Vores udvikling af produktet består først af en kerne, hvor de vigtigste elementer i produktet ligger. Denne kerne er udviklet over 3 sprints. Herefter bliver moduler tilføjet til produktet gradvist i hvert sprint. Modulerne bliver udvalgt på baggrund af vores kunder og brugeres feedback og ønsker.

Bilag

Indholdsfortegnelse (Bilag) Bilag 1. Kernen -‐ modul liste med estimering og risiko 2. Modul liste med estimering og risiko 3. Glossery 4. Spørgeskemaundersøgelse 5. Wireframes 5.1 Appen 5.2 Webservice

83 84 85 86 86 93 94 94

1. Kernen - modul liste med estimering og risiko

2. Modul liste med estimering og risiko

3. Glossery

4. SpĂ¸rgeskemaundersĂ¸gelse

5. Wireframes Wireframes som ikke vises i rapporten

5.1 Appen Fremtidig version

5.2 Webservice Simpel html og css forside