Kuling - Väderapp med multipla datakällor, TNM094. Kajsa Fredriksson Franzén Mikaela Koller Rickard Lindstedt Petra Öhlin

Kuling - Väderapp med multipla datakällor, TNM094 Kajsa Fredriksson Franzén Mikaela Koller Rickard Lindstedt Petra Öhlin 7 juni 2015

Sammanfattning Kuling är en webbaserad applikation utvecklad för att visualisera väderparametrar från två olika meteorologiska myndigheter. Applikationen har utvecklats som ett Medietekniskt kandidatarbete i kursen TNM094 vid Linköpings Universitet. Gruppen fick i uppgift från en kund att skapa en webbapplikation som visualiserar väderparametrar baserat på SMHI:s API. Ett önskemål på utökad funktionalitet var spatial eller temporal osäkerhetsbedömning. Systemet har arbetats fram genom en skräddarsydd variant av den agila utvecklingsmetoden Scrum. Scrum innebär ett iterativt arbete i sprints med delmål. Allt arbete skedde i samtycke med kunden genom en kravspecifikation som gruppen utgått från och delat upp i mindre delmål. Arbetet strukturerades upp i sprints om två veckor. En tidsplanering sattes upp i början av projektet med sprints och delmål inplanerade för att säkerställa att MVP skulle bli klart i tid. Produkten utvecklades i Angular Dart, som är ett objektorienterat programspråk för utveckling av webbapplikationer. Projektet resulterade i ett objektorienterat system utvecklat i Dart kombinerat med JavaScript för att få en tydlig systemarkitektur och för att underlätta vidareutveckling. Produkten är en väderapplikation som jämför väderprognoser från de två meteorologiska instituten Yr.no och SMHI genom bilder i en header och en graf som visar hur en viss väderparameter skiftar över tid. i

Innehåll Sammanfattning Figurer Typografiska konventioner i iv vi 1 Inledning 1 1.1 Bakgrund........................................ 1 1.2 Syfte........................................... 1 1.3 Frågeställning...................................... 1 1.4 Mål och visioner.................................... 1 1.5 Avgränsningar...................................... 2 2 Bakgrund 3 3 Relaterat arbete 4 3.1 Utvecklingsverktyg................................... 4 3.2 Väderprognosmodeller................................. 4 3.2.1 Framtagning av väderprognoser........................ 5 3.2.2 Alternativ osäkerhetsberäkning......................... 7 4 Utvecklingsmetodik 8 4.1 Agil utvecklingsmetod................................. 8 4.1.1 Organisation.................................. 9 4.2 Rutiner......................................... 9 4.2.1 Dokumentation................................. 9 4.2.2 Versionshantering................................ 10 4.2.3 Testning..................................... 11 4.2.4 Workshop.................................... 11 4.2.5 Användartest.................................. 11 5 Teknisk lösning 12 ii

INNEHÅLL INNEHÅLL 5.1 Systemarkitektur.................................... 12 5.2 Designmönster..................................... 12 5.3 Öppna datakällor.................................... 13 5.3.1 Säkerhet..................................... 14 5.4 Utvecklingsverktyg................................... 15 5.5 Designval........................................ 15 6 Resultat 18 6.1 Utvecklingsmetodik................................... 18 6.2 Teknisk lösning..................................... 18 7 Analys och diskussion 21 7.1 Metod.......................................... 21 7.1.1 Utvecklingsmetodik.............................. 21 7.1.2 Teknisk lösning................................. 22 7.1.3 Förbättringsmöjligheter............................ 22 7.1.4 Källkritik.................................... 23 7.2 Resultat......................................... 23 7.3 Arbetet i ett vidare sammanhang............................ 23 8 Slutsatser 24 8.1 Frågeställningar..................................... 24 Litteraturförteckning 25 A MVP 27 B Projektgruppen 28 C Förundersökning 30 D UML-diagram 32 iii

Figurer 3.1 Illustration av ett ensembleprognossystem[22]..................... 5 3.2 Illustration av insamlad data som bearbetas av prognosmodeller. Meteorologen väljer den modell som verkar visa en sannolika utveckling[8]................. 6 3.3 Illustration om hur stor del av bedömnigen av prognoser som styrs av meteorologen från ett till tio dygn framåt[9].............................. 6 4.1 En del av ganttschemat som visar de tre första sprintarna................ 9 4.2 Board för sprint 3 i Trello................................ 10 4.3 En del av projektets commits och branches på Github................. 11 5.1 MVC-flödet ur ett användarperspektiv.......................... 13 5.2 Klassdiagram över systemet............................... 14 5.3 Första mockupen på Kuling............................... 16 5.4 Första mockupen på Kuling längre ner i applikationen................. 16 5.5 Andra mockupen på Kuling............................... 16 5.6 Andra mockupen på Kuling............................... 16 6.1 Applikationens splashscreen............................... 19 6.2 Sökfunktion som ger förslag på städer.......................... 19 6.3 Parameterknapparnas utseende. Här är temperaturen vald som parameter....... 19 6.4 Visualisering av temperaturen.............................. 20 6.5 Längre ner i applikationen................................ 20 6.6 Headern när grafen visualiserar molnmängden..................... 20 6.7 Headern när grafen visualiserar vind........................... 20 C.1 Illustration av en fråga från förundersökningen..................... 30 C.2 Illustration av en fråga från förundersökningen..................... 30 C.3 Illustration av en fråga från förundersökningen..................... 31 C.4 Illustration av en fråga från förundersökningen..................... 31 C.5 Illustration av en fråga från förundersökningen..................... 31 C.6 Illustration av en fråga från förundersökningen..................... 31 D.1 Aktivitetsdiagram över systemet............................. 32 iv

FIGURER FIGURER D.2 Användarfallsdiagram över systemet........................... 32 D.3 Klassdiagram över systemet............................... 33 v

Typografiska konventioner Kursiv text anger en engelsk term. Kursiv och fetstilad text anger en programvara eller andra utvecklingsverktyg. Ordet agil används som en svensk översättning av det engelska ordet agile. MVP är en förkortning av minimum viable product. SMHI är en förkorning för Sveriges meteorologiska och hydrologiska institut. Yr.no är en hemsida som drivs av ett samarbete mellan Norsk Rikskringkasting (NRK) och Meteorologisk institutt. Kuling är namnet på applikationen. vi

Kapitel 1 Inledning 1.1 Bakgrund Rapporten beskriver utvecklingsprocessen och det slutliga resultatet av ett projekt som genomförts i kursen TNM094, Medietekniskt kandidatarbete vid Linköpings Universitet. 1.2 Syfte Syftet med projektet är att med en skräddarsydd utvecklingsmetodik, baserat på Scrum, utveckla en webbaserad väderapplikation. Applikationen ska innehålla visualiseringar av väderprognoser baserade på öppen data och den primära målplattformen är mobiltelefoner. 1.3 Frågeställning Frågeställningarna som tagits fram grundar sig dels på organisationen av projektet och dels på de tekniska delar som var väsentliga och prioriterade från handledare och utvecklingsgrupp. En av frågeställningarna rör det verktyg som användes i projektet. Detta eftersom valet av verktyg hade en stor påverkan på både utvecklingen och resultatet av projektet. Den första frågeställningen är även satt efter kursens mål, att utveckla kunskaper inom systemutveckling och utvecklingsmetodik. Den andra frågeställningen berör visualisering av osäkerhetsbedömning eftersom det var ett område önskvärt att undersöka från kund och grupp. Frågeställningarna följer nedan. Hur erhålls en tydlig systemarkitektur genom att kombinera Dart och JavaScript-bibliotek och hur bidrar den samt utvecklingsmetodiken Scrum till en vidareutvecklingsbar produkt? Hur visualiseras osäkerheten för en väderprognos för att erhålla en applikation som är intuitiv och användarvänlig? 1.4 Mål och visioner I början av projektet sattes mål och visioner för projektet i samtycke med kunden. Målet var att skapa en applikation som visar väderparametrar genom att användaren får söka efter en plats och se resultatet vid olika tidpunkter, alternativt att användaren söker efter en specifik tid och vädret för 1

1.5. AVGRÄNSNINGAR KAPITEL 1. INLEDNING flera olika platser visualiseras. Ett mål som sattes upp, som skulle implementeras i mån av tid, var att visualisera osäkerhetsdata, spatialt eller temporalt. Med osäkerhetsdata innebär i det här fallet hur osäker en väderprognos är. Visionerna för projektet sattes internt inom gruppen och handlade om applikationens slutresultat och utseende. Målen för MVP, se Bilaga A, delades upp och fördes in i en tidsplanering som milstolpar. Det säkerställde att målen skulle uppfyllas inom tidsramen. Planeringen gjordes även för att det skulle finnas möjlighet för implementation av de satta visionerna. Tack vare planeringen uppfylldes de krav som var satta från kund. Målet om att visualisera osäkerhet uppfylldes delvis eftersom gruppen valde att visualisera skillnaden mellan två vädermyndigheter. De satta visionerna uppfylldes också delvis, dels med hjälp av en designworkshop och dels med hjälp av gruppens fokus på fungerande funktioner. På grund av problem under utvecklingsprocessen hindrades gruppen från att klara av alla satta mål och visioner för applikationen. De hinder som uppstod upp var på grund av tekniska problem med det valda utvecklingsverktyget och problem med kopplingen mellan JavaScript och Dart. Ett annat hinder var att det tog tid att lära sig ett nytt programspråk och en ny utvecklingsplattform. Gruppen hade slutligen svårt att bestämma sig för vissa val av verktyg vilket försenade arbetet. De satta målen och visionerna följer nedan. Mål: Uppfylla alla krav från kund. Visioner: Skapa en fungerande och visuellt tilltalande väderapplikation. Skapa en innovativ väderapplikation. Skapa en enkelt designad applikation med få väl fungerande funktioner framför ett stort osäkert system. 1.5 Avgränsningar Applikationen är begränsad till att vara webbaserad och använda sig av SMHI:s öppna data. Projektmetodiken ska enligt kursmålen följa en iterativ, Scrum-liknande struktur. 2

Kapitel 2 Bakgrund I dagens samhälle finns flera olika webbapplikationer som kan användas för att få uppdateringar om väderprognoser. Webbapplikationerna som finns tillgängliga skiljer sig i utseende och funktion. Gruppen har fått i uppdrag att på ett estetiskt tilltalande, lättillgängligt och informativt sätt visualisera väderparametrar. Eftersom gruppen ville att applikationen skulle skilja sig från andra väderapplikationer, beslutades att visualisera väderparametrar från två olika datakällor. Det gör att användaren själv kan göra en osäkerhetsbedömning av prognosen. Den primära målgruppen för applikationen, som även kommer benämnas som Kuling, är personer som äger en mobil enhet med en webbläsare och är en van mobilanvändare. Applikationen är även användbar för personer som kan ha nytta av, eller intresseras av att göra en osäkerhetsbedömning. 3

Kapitel 3 Relaterat arbete I detta kapitel behandlas fakta angående utvecklingsverktyg och väderprognoser. 3.1 Utvecklingsverktyg Valet av utvecklingsverktyg var inledningsvis ett stort delmoment av projektet, som hade inverkan på hela projektet. Det finns många valmöjligheter av programspråk och ramverk för webbutveckling [1]. Det stora utbudet gör valet av utvecklingsverktyg både svårt och viktigt, eftersom det finns för och nackdelar med alla verktyg. Det gäller samtidigt att välja det verktyg som passar bäst för den specifika tillämpningen. Dart är ett nytt språk utvecklat med syfte att underlätta webbprogrammering. JavaScript, som är det vanligaste scriptspråket inom webbutveckling, är ett språk med många tillhörande bibliotek med tillhörande dokumentation [2]. Biblioteken är utvecklade för att underlätta och förenkla arbetet för utvecklare. Google, som har utvecklat Dart, menar att det behövs en drastisk förändring och städning av utvecklingsmöjligheterna för webbutveckling [3]. Dart är objektorienterat och är tänkt att vara enkelt och mer funktionellt. Språket har influenser av Java och JavaScript. Dart-kod kompileras till JavaScript för att vara kompatibel med de flesta webbläsare. Google har även skapat en tillhörande utvecklingsplattform DartEditor som är utrustad med kompilator, refaktoreringshjälp och debug-verktyg. Det finns även en tillhörande stilguide [4] på Darts hemsida. Eftersom Dart nyligen är utvecklat finns inte dokumentation i samma utsträckning som det finns för JavaScript. Google har även utvecklat ett annat verktyg, Angular, som är kompatibelt med Dart. 3.2 Väderprognosmodeller Det går inte att förutsäga väder exakt eftersom väderprognosmodeller är approximativa modeller av atmosfären [5]. Därför sker beräkningar av väder med sannolikhetsteori. Eftersom det uppkommer en feltillväxt som ökar med tiden, visas endast väderprognoser cirka tio dagar framåt, prognoser längre fram är för osäkra. Det uppkommer även felmarginaler eftersom en dator inte kan beräkna med ett finit antal decimaler vilket leder till avrundningsfel. Detta leder till att väderprognoser mellan olika myndigheter nästan alltid skiljer sig. Därför byggs alla prognoser upp i kluster, även kallat ensembler, baserade på olika uppskattningar om hur prognosen kommer se ut, se figur 3.1. De olika strecken representerar prognoser beräknade med olika väderprognosmodeller. Meteorologerna kan utifrån en sådan graf bedöma hur värdet troligtvis kommer utvecklas baserat på hur de olika prognoserna förhåller sig till varandra. Ju längre fram i tiden 4

3.2. VÄDERPROGNOSMODELLER KAPITEL 3. RELATERAT ARBETE prognosen beräknas, desto mer skiljer de sig. Ju fler beräknade prognoser av olika modeller som efterliknar atmosfären, desto mer sannolikt är det att den verkliga väderutvecklingen efterliknas. Figur 3.1: Illustration av ett ensembleprognossystem[22]. 3.2.1 Framtagning av väderprognoser Global Ensemble Forecast System (GEFS), [6], är en väderprognosmodell som består utav 21 olika prognoser. GEFS startades för att behandla olika osäkerheter i väderobservationer, vilket används för att initiera väderprognosmodeller. Dessa osäkerheter tar hänsyn till att små skillnader i verkligheten och uppmätt data kan få stora konsekvenser för hur korrekt en väderprognos blir. Ett exempel på detta är att en fjärils vingslag vid en plats kan vara orsaken till att vindbyar flera tusen mil ifrån skapas. Detta är dock ett extremt exempel. GEFS försöker därför kvantisera osäkerhetsmängden av en prognos genom att generera en ensemble av flera prognoser, där varje minut är annorlunda från de ursprungliga observationerna. SMHI tar fram väderprognoser genom insamling av data och genom val av lämplig modell, exempelvis GEFS, som bedömer den inlästa datan [7]. Insamling av data sker med många olika parametrar från olika platser. Det tas in observationer från bland annat flygplan, fartyg, väderballonger, väderradar och satelliter från både automatiska och manuella väderobservationer. Automatiska stationer gör mätningar kontinuerligt och manuella gör mätningar cirka var tredje timme. Matematiska modeller beräknar förändringar av till exempel lufttryck, temperatur och vindar. Modellerna har tagits fram genom att bland annat observerat hur processer i atmosfär, vattendrag och hav påverkar lufttryck och temperatur. Olika modeller används till olika prognoser. 5

3.2. VÄDERPROGNOSMODELLER KAPITEL 3. RELATERAT ARBETE Figur 3.2: Illustration av insamlad data som bearbetas av prognosmodeller. Meteorologen väljer den modell som verkar visa en sannolika utveckling[8]. All den insamlade datan sammanställs i superdatorer och beräknas med globala prognosmodeller tio dygn framåt [10]. Meteorologer väljer sedan en lämplig modell som verkar visa den mest troliga utvecklingen, se processen i figur 3.2. Prognoserna bedöms och färdigställs på olika sätt beroende på hur långt fram i tiden de är. Datorprognoser längre fram i tiden jämförs även med prognoser från andra meteorologiska institut. Prognoser som görs ett till tre dygn framåt bedöms med hjälp av två väderleksmodeller, HARMONIE och HIRLAM. HARMONIE har utvecklats tillsammans med över 20 länder i Europa och uppdateras oftare och mer detaljerat än de mer globala prognoserna. HIRLAM är en äldre prognosmodell, som inte ger lika detaljerade prognoser och inte uppdateras lika frekvent, men mäter över ett större geografiskt område. Därför kombineras ofta de två modellerna. För lokala prognoser de närmsta 12 timmarna används förutom den aktuella observationsdatan även numeriska prognosmodeller med hög detaljnivå som väger samman all tillgänglig data. Figur 3.3: Illustration om hur stor del av bedömnigen av prognoser som styrs av meteorologen från ett till tio dygn framåt[9]. Ju längre fram i tiden som en prognos bedöms, desto mer utgörs bedömningen av en kombination av information från olika väderprognoser. Där söker meteorologerna efter en minsta gemensamma nämnare, även kallad konsensusprognos. Vid bedömning av prognoser från och med tre dygn framåt används ensembleprognossystemet vilket jämför 50 prognoser med olika utgångslägen. Figur 3.3 visar hur prognoserna som ges ut via olika mediakanaler de första dygnen styrs till störst del av meteorologen, därefter används ensembleprognossystemet. Genom att beräkna väderprognoser via ensembler och olika beräkningsmodeller, går det att göra en 6

3.2. VÄDERPROGNOSMODELLER KAPITEL 3. RELATERAT ARBETE tolkning av hur osäker en prognos är. Utifrån sådana beräkningar går det att presentera en osäkerhetsbedömning. 3.2.2 Alternativ osäkerhetsberäkning Ett annat förslag, som handledaren instruerade om, var att beräkna derivatan som ett mått av osäkerhet. På så vis kan osäkerheten antingen beräknas temporalt eller spatialt. Ett exempel på temporal osäkerhet är temperaturskillnaden mellan två tidpunkter. Om SMHI meddelar att temperaturen kommer vara tio grader klockan tolv och elva grader klockan ett går det att beräkna en derivata och utifrån det bedöma säkerheten för prognosen. Eftersom det är en liten skillnad mellan de två tidpunkterna går det att bedöma att väderdatan för temperaturen har en stor chans att stämma. 7

Kapitel 4 Utvecklingsmetodik I följande kapitel presenteras vilken utvecklingsmetod och vilka rutiner som använts genom utvecklingsprocessen av projektet. 4.1 Agil utvecklingsmetod Arbetet genomfördes enligt en skräddarsydd variant av den agila utvecklingsmetoden Scrum som är hämtad från en artikel om Scrum [11]. Scrum innebär ett iterativt och inkrementellt arbetssätt med regelbundna utvärderingar av arbetet och kontinuerlig kontakt med kund. Arbetet delades upp i sprints, vilket är begränsade tidsperioder som var och en avslutades med en delprototyp av produkt. Varje sprint planerades att vara i två veckor, vilket resulterade i totalt sex sprintar. Det fanns även möjlighet att förkorta sprintarna om så krävdes. Inför varje sprint hölls en sprint planning, där arbetet planerades genom att hämta stories från product backlog. Valda stories fördes över till en sprint backlog där de delades upp i mindre tasks. Sprint backlog innehöll de uppgifter som skulle slutföras under den aktuella sprinten. Sista dagen varje vecka hölls en sprint retrospect där delleverans av produkt visades upp för alla i utvecklingsgruppen och all kod som skrivits granskades. Sista dagen på varje sprint hölls en sprint review där gruppen utvärderade den genomförda sprinten ur olika synvinklar. Vid behov planerade gruppen om arbetsmetoderna och prioriterade om stories i product backlog. Kundmöten planerades in varje sprint för kontinuerlig kontakt och för att säkerställa att projektet var på väg i rätt riktning. Eftersom kunden inte hade många specifika krav på projektet gavs gruppen valmöjligheter att utveckla projektet i egen riktning. Under utvecklingsprocessen tillkom heller inga krav från kund som påverkade funktionalitet eller utseende av produkten. Den inledande sprinten i projektet kallades för sprint 0. Under denna sprint planerades det framtida arbetet och efterforskning kring verktyg gjordes. Varje sprint sattes att vara två veckor. Under sprint 0 skrevs ett gruppkontrakt som innehöll mål med projektet och rutiner kring möten, tider och kommunikationsvägar. Det gjorde det tydligt för alla medlemmar i gruppen att förstå de andras förväntningar och vad varje gruppmedlem hade för skyldigheter. Gruppen kom överens om att det var viktigt med bra kommunikation i gruppen samt att alla skulle ha kunskap om alla delar inom projektet. Detta var möjligt eftersom gruppen endast bestod av fyra personer. Det fanns även utrymme på sprint reviews att uttrycka sina åsikter kring hur gruppen fungerade för att följa upp och vidareutveckla det som beslutades under sprint 0. En tidsplan utformades enligt ett ganttschema, se ett utdrag av schemat i figur 4.1. Nedan följer några av de milstolpar som sattes: Sprint 1: kunna läsa in data och skriva ut dagens väder. Sprint 2: kunna skriva ut resterande veckas väder. 8

4.2. RUTINER KAPITEL 4. UTVECKLINGSMETODIK Sprint 3: kunna söka på en plats och visa den aktuella platsens väder. Varje dag inleddes med en daily scrum. Det var ett kortare möte där det togs upp vad som senast hade gjorts, vad som skulle göras härnäst och eventuella problem. Figur 4.1: En del av ganttschemat som visar de tre första sprintarna. 4.1.1 Organisation Eftersom gruppen endast bestod av fyra personer var samtliga med i utvecklingsgruppen och all kod ägdes gemensamt. Under hela arbetet användes en platt hierarki, där alla i arbetet fick ta del i de beslut som fattades. Under projektets gång delades utvecklingsgruppen upp i mindre grupper för att effektivisera utvecklingsarbetet. Då gruppen arbetade efter scrum valdes en scrum master och en produktägare. Även andra roller infördes för att effektivisera arbetet ytterligare. För varje roll författades en kort rollbeskrivning för att tydligt visa ansvarsområden och för att undvika missförstånd inom gruppen. Det gjorde att ansvarsområden varken förbisågs eller ingick i flera poster, se Bilaga B. 4.2 Rutiner För att få utvecklingsprocessen så smidig som möjligt har rutiner satts upp för arbetet. Dessa rutiner beskrivs nedan. 4.2.1 Dokumentation Dokumentation prioriterades högt under utvecklingen för att underlätta arbetet. Information gällande ändringar dokumenterades för att undvika oklarheter och för att kunna gå tillbaka och se vilka beslut som tagits. Varje sprint dokumenterades var för sig, där resultatet av varje sprint review och retrospect tydligt strukturerades. Alla dynamiska dokument, som exempelvis product backlog, hölls levande och uppdaterade genom Google Drive. Detta möjliggjorde enkel delning av dokumenten mellan gruppmedlemmarna. Även statiska dokument som projektplan sparades där för att samla alla dokument på samma ställe. Trello är ett webbaserat gränssnitt för planering. Detta användes som scrumboard, där stories från product backlog bröts ner till tasks som flyttades framåt på boarden under utvecklingen tills de markerats som färdiga, se figur 4.2. Scrumboard uppdaterades varje daily scrum och varje gång en ny task var slutförd, påbörjad eller behövde uppdateras. 9

4.2. RUTINER KAPITEL 4. UTVECKLINGSMETODIK Figur 4.2: Board för sprint 3 i Trello. För dokumentation av kod har Darts standard använts [14]. Detta möjliggör att koden kan extraheras med hjälp av dartdocgen. Dartdocgen är Darts egen dokumentationsgenerator som utifrån speciella kommentarer beskriver funktioner och medlemsvariabler i varje klass. Det underlättar för utomstående att förstå systemets uppbyggnad vid eventuell vidareutveckling. Rutin för dokumentering av kod var att varje utvecklare som arbetade med en ny funktionalitet i koden även dokumenterade de nya tillagda funktionerna. Dokumentering med Dartdocgen sammanställdes i slutet av projektet, men koden kommenterades även under projektet. En gemensam granskning vid veckans slut kontrollerade att all kod var tillräckligt dokumenterad. 4.2.2 Versionshantering För att varje gruppmedlem skulle kunna sätta sig in i någon annans kod och använda den, gällde det att koden var ordentligt strukturerad och kommenterad. Under projektets gång användes Git och Github för versionshantering. De rutiner som användes för kodhanteringen illustreras i figur 4.3. Rutinerna var att masterbranchen hela tiden skulle ha en fungerande version av produkten, i figuruen representeras masterbranchen av den svarta linjen. Vid start av en ny task skapades en branch vanligtvis utifrån masterbranchen, dessa representeras av de färgglada linjerna. Efter att en task färdigställts och granskats, sammanfogades den med masterbranchen. För att koden hela tiden skulle vara välstrukturerad och kommenterad fick en annan gruppmedlem gå igenom koden innan den sammanfogades med master. Vid varje commit, till både master och en branch, användes en förklarande text på engelska om vad för ändringar som gjorts. Det gjorde det enklare att återgå till tidigare versioner av programvaran. Commits illustreras i figuren av punkter. 10

4.2. RUTINER KAPITEL 4. UTVECKLINGSMETODIK Figur 4.3: En del av projektets commits och branches på Github 4.2.3 Testning I slutet av varje arbetsvecka gick gruppen tillsammans igenom koden på en sprint retrospect. Det minskade risken för fel i koden samtidigt som alla fick en grundläggande förståelse för hur koden fungerade. Under dessa möten låg även fokus på kodens struktur och att den var ordentligt kommenterad. Även simpla tester genomfördes kontinuerligt för att säkerhetställa att applikationen följde de krav som hade satts upp. Parprogrammering tillämpades på de tasks som ansågs behöva det, vilket medförde kontinuerlig kodgranskning och effektivare problemlösning. En task ansågs dock inte färdigtestad förens koden granskats av en person som inte utvecklat den aktuella koden, detta skedde annars under sprint retrospect. 4.2.4 Workshop Gruppen uttryckte ett behov av att förtydliga specifika delar av projektet, därför planerades workshops. Den första workshopen hölls för att komma på en tydlig produktidé och beskrivning utifrån de krav som kunden ställt. Den metod som användes för genomförandet av workshopen baserades på att gruppen satte sig in i olika perspektiv kring utvalda diskussionsfrågor. De olika perspektiven var målgrupp, utvecklingsgrupp och kollegor. Den andra workshopen hade fokus på design eftersom utvecklingsgruppen saknade en tydlig grafisk vision att arbeta mot. Resultatet av den workshopen blev en prototyp som beskrivs utförligare i stycket Designval 5.5. 4.2.5 Användartest Kontinuerlig kontakt med användarna för att få återkoppling på produkten har eftersträvats under alla utvecklingslägen. Den första interaktionen med användarna var en förstudie som gjordes via ett webbformulär. Där ställdes frågor kring nuvarande användandet av väderapplikationer och önskade funktionaliteter. Resultatet av förstudien gav utvecklingsgruppen fler idéer som användes i den första planeringsfasen av produkten. En del av formuläret och resultatet kan ses i Bilaga C. Ett användartest gjordes på den första mockupen, en detaljerad skiss av produkten. Rutinerna för användartesten var att två ur utvecklingsgruppen, en som höll i användartestet och en som antecknade, tillsammans med en användare satt på en avskild plats. Användaren fick svara på öppna frågor och uppmanades att tänka högt under alla frågor. Detta gav utvecklingsgruppen förbättringsförslag och återkoppling på om produkten var tillräckligt intuitiv. 11

Kapitel 5 Teknisk lösning I följande kapitel presenteras hur applikationen är uppbyggd. Det beskrivs bland annat genom att förklara vilket designmönster som tillämpats, vilken utvecklingsplattform som används och hur funktionaliteter implementerats. 5.1 Systemarkitektur Som modelleringsstandard användes UML, Unified Modelling Language. Detta är ett standardiserat språk inom modellering av system [12]. Denna grafiska metod underlättade bland annat kommunikationen av idéer, testning av koncept samt definiering av enheter och klasser. Utifrån denna standard skapades aktivitetsdiagram, användarfallsdiagram och klassdiagram, dessa kan ses i Bilaga D. Användarfallsdiagrammet resulterade i en grafisk bild av kundens MVP-krav. Aktivitetsdiagrammet ökade förståelsen för hur anrop i applikationen skulle implementeras. Klassdiagrammet visar applikationens klasser, hur de hör ihop samt vilka variabler och funktioner en viss klass innehåller. Detta diagram har uppdaterats under projektets gång eftersom refaktorering av systemet varit nödvändigt vid två tillfällen. 5.2 Designmönster Systemarkitekturen gruppen utgått från i projektet är designmönstret Model-View-Controller, MVC. Detta eftersom de exempel applikationen initialt baserats på är uppbyggda med MVC och är ett känt designmönster för webbapplikationer [13]. MVC underlättar vidareutveckling och modifiering, genom att strukturerna påverkar varandra minimalt. Det gör det även möjligt att arbeta på flera komponenter samtidigt. Designmönstret består av tre undersystem. I det första, Model, lagras all data i olika klasser som används av systemet. En Model i Kuling är klassen WeatherData som i sin tur hanterar de klasser som till exempel läser in SMHI:s och Yr:s data. I det andra undersystemet, View, används datan för att rita ut de komponenter som systemet består av. Det är även i View som användaren integrerar med systemet genom mjukvarans användargränssnitt, med till exempel knappar. I det sista undersystemet, Controller, kontrolleras flödet mellan Model och View. Eftersom applikationen är en singel-page-applikation, har den endast en View som uppdateras dynamiskt, utan att ladda om sidan på nytt. Ett exempel är om användaren trycker på en parameterknapp för att ändra visad data. Användarens handling skickas till Controller som tar emot och sedan kräver uppdatering från aktuell Model som hanterar den efterfrågade datan, alltså vilka parametrar som ska behandlas. När all data har uppdateras 12

5.3. ÖPPNA DATAKÄLLOR KAPITEL 5. TEKNISK LÖSNING skickas den tillbaka till Controllern som manipulerar och vidarebefordrar resultatet av användarens begäran till View, som i det här fallet representerar datan i en graf. Figur 5.1 visar även kopplingen mellan de olika delarna. Figur 5.1: MVC-flödet ur ett användarperspektiv. 5.3 Öppna datakällor Visualiseringarna i Kuling är baserade på SMHI:s [15] och Yr:s [16] öppna API:er för väderprognosdata. API:erna liknar varandra genom att de båda svarar på en plats given i världskoordinater och ger svar i form av väderparametrar för den aktuella platsen vid olika tidpunkter. En skillnad mellan API:erna är att SMHI:s API ger svar i JSON-format och Yr:s API ger svar i xml-format. En annan skillnad är att SMHI svarar med en fullständig tio dygns prognos med femton tillhörande parametrar och Yr svarar med en nio dygns prognos med tolv tillhörande parametrar. SMHI:s API hanterar endast koordinater inom Norden, medan Yr kan hantera koordinater utanför Norden. För att läsa in de två prognoserna krävs två olika inläsningar eftersom API:erna svarar med olika format. Dart är uppbyggt för objektorienterade system, därför skapades två olika klasser som läste in väderdata för respektive API. Ytterligare två klasser skapades för bearbetning av datan. Den ena klassen definierar ett väderobjekt och den andra tar emot data från båda API:erna och bearbetar prognoserna. Detta medföljer att klasserna som läser in datan även omformulerar dem till samma format, listor av väderklassobjekt, som skickas vidare till klassen som presenterar datan. Ett väderobjekt innehåller parametrarna temperatur, vind, molnighet, nederbörd och tiden för den aktuella datan. Klasserna och hur de hör ihop illustreras i ett klassdiagram som kan ses i figur 5.2. 13

5.3. ÖPPNA DATAKÄLLOR KAPITEL 5. TEKNISK LÖSNING Figur 5.2: Klassdiagram över systemet. För att kunna ta fram väderparametrarna ur API:erna krävs en position. Den tas fram genom koordinater i form av latitud och longitud. I dagens moderna enheter finns en GPS som kan avslöja var enheter befinner sig. Webbläsaren kan komma åt GPS:en genom att fråga användaren om tillåtelse att ta reda på var användares aktuella position är. Om enheten inte har en GPS, eller om den är avslagen, måste användaren söka sig fram till sin egen position. Användaren kan även söka på en valfri position genom att skriva in valfri stad i sökfältet. Eftersom att SMHI:s och Yr:s API:er använder sig av koordinater för att skicka tillbaka väderparametrar måste denna stad översättas till koordinater. För det ändamålet används Nominatim [17], ett API som översätter en stads namn till koordinater. Funktionen som ger sökförslag på städer möjliggjordes genom implementation av Google Maps API [18]. Eftersom Kuling endast ska visa väderprognoser för Sverige var Google Maps API tvunget att begränsas, då det annars ger sökförslag ifrån hela världen. De meteorologiska institut som väderparametrarna hämtas ifrån har beräknat och distribuerat parametrar i form av siffror. Vid temperaturmätning används siffror eftersom det är allmänt känt att temperatur mäts med siffror. Det blir dock svårare när molnighet eller vindstyrka ska översättas. Det är inte säkert att den valda målgruppen vet vad 20 procent molnighet innebär. Därför var gruppen tvungna att översätta dessa siffror till mer allmänt kända uttryck, för att säkerhetsställa att den tänkta målgruppen skulle förstå. För att kunna översätta de värdena har SMHI förklaring av hur alla parametrar översätts [19] 5.3.1 Säkerhet Cross-Origin är en säkerhetsspärr som dagens webbläsare använder sig av. Säkerhetsspärren tillåter inte att en förfrågan ställs automatiskt från en annan domän än den som servern använder sig av. Ett exempel är om den lokala servern som ligger på http://kalle.com ställer en fråga till http://anka.se. Då kommer webbläsaren automatiskt att känna av att det är en annan domän som frågan ställs ifrån 14

5.4. UTVECKLINGSVERKTYG KAPITEL 5. TEKNISK LÖSNING och stoppa förfrågan. Detta för att förhindra att skript och virus ska spridas som kan vara skadliga för datorn. Ett Cross-Origin problem uppstod då applikationen försökte ställa frågor till Yr:s API. Efter dialog med Yr:s kundtjänst, projektets handledare och kund togs ett beslut om att en proxyserver skulle sättas upp. Proxyservern används som mellanhand mellan klienten och Yr:s API för att komma runt problemet med Cross-Origin. Proxyservern skrevs i PHP och lades upp på en extern apache-server. I proxyservern tillåts Cross-Origin requests, vilket gör att applikationen kan skicka förfrågan till proxyn. Förfrågan behandlas sedan i proxyn och skickas vidare till Yr. Eftersom att proxyn inte använder sig av en webbläsare blir inte Cross-Origin något problem. Yr:s API svarar sedan tillbaka till proxyservern, som skickar svaret tillbaka till applikationen. För att säkerställa att servern inte kunde ta in farlig kod användes en metod som manipulerade serverns data genom att rensa requests från allt annat än siffror. Servern kunde gjorts ännu mer säker, men eftersom datan på servern inte har några lösenord eller personuppgifter så låg inte detta i fokus. Yr:s API kräver koordinater för att veta vilken positions väderparametrar som ska skickas tillbaka. För att kunna skicka parametrar mellan applikationen och proxyservern används URL:en som skickas i HttpRequesten. För att URL:en inte ska innehålla någonting annat än koordinater rensas den tills den endast innehåller giltiga tecken och siffror. Detta görs för att öka serverns säkerhet. 5.4 Utvecklingsverktyg Dart användes som utvecklingsverktyg efter rekommendation från kund och efter undersökning under sprint 0. Som komplement till Dart har Angular använts för effektiv och dynamisk händelsehantering. För att få en tydlig CSS struktur har biblioteket Twitter Bootstrap [20] används för att bygga upp en rutnätsstruktur av HTML-elementen. Alla HTML-element omgivs av div-taggar med en CSS-klass definierad i Bootstrap. Angular är från början ett JavaScripts-bibliotek utvecklat av Google, liksom Dart, som underlättar Document Object Model (DOM)-manipulation. I den version av Dart som Kuling byggts i finns även Angular integrerat. Angular används bland annat för händelsehantering och repetitiv utskrift. Vid uppstart ville gruppen att applikationen skulle visa positionen för enheten. För det används den inbyggda GPS:en i enheten. Om det finns en GPS i enheten så kan man komma åt den med hjälp av Geolocator som finns i Dart. För att visualisera väderparametrar valde gruppen att använda sig av JavaScriptbiblioteket D3js. D3js är ett visualiseringsverktyg som underlättar uppritning av grafer inom webbapplikationer. I D3js användes funktioner som ritar upp grafen, D3js hjälper till med att sätta axlarna rätt samt skala axlarna varefter datan manipuleras. I D3js kan man rita grafer ovanpå varandra med hjälp av flera lager, där ett lager i applikationens fall är SMHI och ett annat är Yr. 5.5 Designval För att alla i utvecklingsgruppen skulle arbeta mot samma mål, och för att kunden skulle få en tydligare vision om en slutgiltig produkt, togs två mockups fram under en av de workshops som tidigare nämnts i kapitel 4.2.2. Dessa visade både all önskad funktionalitet och vilken känsla designen strävade efter att återskapa. Den första mockupen gjordes tidigt i utvecklingsprocessen i ett webbaserat gränssnitt för interaktiva prototyper [21]. En skärmdump på delar av resultatet kan ses i figur 5.3 och 5.4. Konceptet med att visualisera väderparametrarna längs en tidslinje kvarstod när den andra 15

5.5. DESIGNVAL KAPITEL 5. TEKNISK LÖSNING mockupen skapades. Figur 5.5 och 5.6 visar den andra mockupen. Den användes för att påminna utvecklingsgruppen om vilken funktionalitet som skulle implementeras och hur designen skulle se ut.. Figur 5.3: Första mockupen på Kuling. Figur 5.4: Första mockupen på Kuling längre ner i applikationen.. Figur 5.5: Andra mockupen på Kuling. Figur 5.6: Andra mockupen på Kuling. Eftersom Kuling innehåller mycket information, har gränssnittet noga valts ut med lättförståeliga visualiseringar för att inte överlasta användaren med information. All den information som presenteras i Kuling är begränsad till det som är relevant för tillfället, det vill säga vilken parameter användaren väljer att visualisera i grafen. Ytterligare information är därefter tillgänglig endast efter val av den specifika parametern. På detta sätt förses användaren med lite information i taget, och endast vid begäran. Detta gör användargränssnittet tydligt, eftersom ingen överflödig information visas. Ett av Kulings syften är att visa osäkerhet. Gruppens implementering av detta är jämförelsen mellan de meteorologiska myndigheterna SMHI och Yr.no. Eftersom detta är en central del i Kuling sattes 16

5.5. DESIGNVAL KAPITEL 5. TEKNISK LÖSNING headern, där skillnaden visas, statisk. Det gjordes dels för att den skulle hamna i fokus, men även för att tydligt visa var användaren befinner sig. Det gör att kan användaren enkelt och snabbt kan se jämförelsen mellan de valda parametrarna vid den önskade tidpunkten. Headern är uppdelad i två delar, där vänstra halvan representerar SMHI och högra Yr. För att enkelt skilja väderstationerna åt samtidigt som att de ska vara lättförståeliga och ha uppfylla samma syfte, har de samma design men olika bakgrundsfärg. Detta resulterar i att användaren tydligt kan skilja på vilket väder som tillhör vilken väderstation. Den genomgående strukturen och igenkännande symboler gör Kuling lättförståelig och lättnavigerad. All utformning är upplagd med tanke på att Kuling skall vara lätthanterlig för olika mobilenheter oavsett storlek. Vädret visualiseras genom både bild och text. Texten representerar den valda parameterns värde vid en specifik punkt och bakgrunden vädret. 17

Kapitel 6 Resultat Resultatet delas upp i två delar. Den första delen beskriver hur det resulterande arbetet med Kuling genomfördes och det andra stycket beskriver den slutgiltiga applikationen. 6.1 Utvecklingsmetodik Utvecklingsgruppen följde de uppsatta rutiner som bestämdes under projektets början. Även nya rutiner och förbättringar av de gamla implementerades efter sprint reviews. Exempel på rutiner som förbättrades följer nedan. Daily scrum var en av de rutiner som förbättrades. För att få ett tydligare avslut på mötet testades stående möte med planering på en storbildsskärm. Det gjorde det enklare för gruppen att hålla mötet kort och undvika utsvävningar. Gruppen fortsatte trots det att hålla sittande möten med lärdomen att följa rutinen att tydligt säga när mötet var avslutat. Planering av var nästkommande arbetsdag skulle spenderas lades även till på daily scrum-agendan efter ett retrospect. Trello har många inbyggda funktioner som började användas efter en Sprint review där gruppen upplevde att olika tasks som satts upp var för otydliga. Åtgärden var checklistor som användes för att bryta ner problemen i mindre delar. Alla gruppmedlemmar markerades även på de kort som de arbetade med för tillfället, detta för att alla i gruppen skulle veta vad som arbetades med. 6.2 Teknisk lösning Den resulterande applikationen visar väderparametrar för vädret nio dagar framåt i tiden och jämför de två meteorologiska instituten Yr och SMHI. Nedan beskrivs hela processen från att applikationen startas till att alla funktioner förklarats. Vid start av applikationen visas en splashscreen, se figur 6.1 nedan. Den innehåller applikationens namn och animerade moln som förflyttar sig på skärmen under tiden applikationen laddar in väderdatan för den aktuella positionen. 18

6.2. TEKNISK LÖSNING KAPITEL 6. RESULTAT Figur 6.1: Applikationens splashscreen. Figur 6.2: Sökfunktion som ger förslag på städer. Första gången applikationen öppnas kommer användaren vara tvungen att tillåta att applikationen får använda enhetens GPS. Om användaren inte tillåter att GPS:en används, visas vädret för Norrköping. Annars kommer den aktuella staden vara den användaren befinner sig i. När all väderdata laddats in för den aktuella staden, visas det aktuella vädret från båda väderinstitutionerna i form av en graf. För att välja en annan stad än den aktuella, skriver användaren in valfri stad i Sverige i sökrutan. För att underlätta och effektivisera sökningen ges förslag på städer i en dropdown under tiden användaren skriver, se figur 6.2 ovan. Genom att trycka på kompassknappen till vänster om sökrutan kan användaren enkelt komma tillbaka till aktuell stad efter sökning på en annan stad. Genom en tydlig mappning finns fyra parameterknappar ovanför grafen som representeras med igenkännande symboler för nederbörd, vind, temperatur samt moln för att öka synligheten för användaren. Vid start visualiseras temperaturen i grafen och headern vilket förtydligas genom att tillhörande parameterknapp är markerad med en mörk ram, se figur 6.3. Vid val av en ny parameter återkopplas användaren genom att den nya parameterknappen markeras med en mörk ram. Figur 6.3: Parameterknapparnas utseende. Här är temperaturen vald som parameter. Grafen visualiserar skillnaden mellan de två instituten över tid, med tiden fallande. Grafens horisontella värden är dynamiska och ändras utefter visualiserad parameter. Vid molnighet representerar axeln procent, vilket kan ses figur 6.4 nedan. För nederbörd representerar den millimeter per timme, för temperatur visar den antal grader och för vind visas meter per sekund. Den vertikala axeln representerar de nästkommande nio dagarna och punkten längst upp representerar den aktuella tiden. 19

6.2. TEKNISK LÖSNING KAPITEL 6. RESULTAT. Figur 6.4: Visualisering av temperaturen. Figur 6.5: Längre ner i applikationen. För att se det kommande vädret för dagen och veckan, scrollar användaren nedåt i applikationen, se figur 6.5. Skillnaden mellan de två instituten tydliggörs genom att varje datakälla har linjer i grafen i samma färg som i header, vilket gör att användaren enkelt kan se koppla ihop mätningar med rätt institut. Användaren intregrerar med grafen med hjälp av en horisontell linje som tydliggör vilken tidpunkt samt dag som denne har angett. Headern uppdateras därefter och ger återkoppling till användaren med en bild på väderleken för den önskade tidpunkten, samt en text som presenterar värdet för den valda parametern. Headern har en statisk position och kommer alltid vara placerad i översta fjärdedelen av applikationen, var användaren än befinner sig i applikationen. När en viss tidpunkt i grafen anges, uppdateras headern utefter denna tidpunkt och ger användaren återkoppling. Ett exempel kan ses i figur 6.6 och 6.7 nedan där moln respektive vind är valda parametrar.. Figur 6.6: Headern när grafen visualiserar molnmängden. Figur 6.7: Headern när grafen visualiserar vind. 20

Kapitel 7 Analys och diskussion Den framtagna produkten täcker de mål som satts upp för MVP. Nedan följer en diskussion kring positiva och negativa aspekter av arbetets upplägg, möjliga vidareutvecklingar av systemet samt kritik kring källor. 7.1 Metod 7.1.1 Utvecklingsmetodik Eftersom ingen i utvecklingsgruppen tidigare arbetat med det valda verktyget eller systemutveckling, försvårades arbetet med att få en helhetsbild över applikationens uppbyggnad. Efterforskningar gjordes i ett tidigt stadium, men bristen på erfarenhet av verktyget gjorde det svårt för gruppen att förstå hur en systemarkitektur bäst skulle byggas upp för det aktuella projektet. Det var även svårt för gruppen att veta hur mycket efterforskningar som krävdes och hur de skulle prioriteras. Det ledde till att gruppen väntade med att ta viktiga beslut, vilket fördröjde utvecklingen av projektet. För att lösa problemet implementerades en mindre teknisk studie i början av varje sprint eller i samband med tasks som krävde det. Ett problem som tidigt uppstod var formulering av och storleken på tasks i en sprint. Eftersom ingen av gruppens medlemmar varken arbetat agilt eller med Dart innan, var det svårt att uppskatta hur lång tid olika tasks krävde. Det var även svårt att veta hur mycket uppgifterna behövde brytas ned för att vara tillräckligt tydliga. Detta resulterade i att tasks ibland inte var implementerade vid sprintens slut. Det förekom även att det var för få tasks i sprinten, då lades ytterligare stories till i sprinten. Detta resulterade i att de nya tasks som skapats inte hann slutföras innan sprintens slut. För att undvika detta hade sprinten kunnat förkortas genom att avsluta sprinten när aktuella stories var slutförda. Det hade strukturerat utvecklingsprocessen ytterligare. Problemet hade kunnat lösas genom att sätta tidsestimeringar för varje task, men på grund av svårigheten att tidsestimera valde gruppen att inte tillämpa en sådan åtgärd. Under projektets gång, i och med att utvecklingsgruppen fick mer kunskaper om verktyget, utvecklades en bättre uppskattningsförmåga för hur många tasks som en sprint skulle innefatta. Detta ledde till att tydligare och mer organiserade sprints. Utvecklingsgruppen var medveten om att vissa av användartesten var utförda på ett selektivt urval av målgruppen. Beslut har därför inte kunnat baseras helt och hållet på slutsatserna som dragits från användartesterna. Eftersom det i och med ett selektivt urval är stor sannolikhet att resultatet inte överensstämmer med hela målgruppens åsikt. 21

7.1. METOD KAPITEL 7. ANALYS OCH DISKUSSION 7.1.2 Teknisk lösning Systemets arkitektur var delvis odefinierad i början av projektet. Avsaknaden av en detaljerad plan resulterade i att produkten fick refaktoreras under projektets gång, vilket tog tid från utvecklingen av produkten. Gruppen ansåg dock att refaktoreringarna var nödvändiga för fortsatt utveckling av projektet. Den första refaktoreringen följde efter att gruppen strukturerade om applikationen efter Darts modulbaserade systemuppbyggnad. I den andra refaktoreringen delades klasserna upp tydligare, för att undvika att en viss klass växer och blir svår att överskåda. Eftersom en agil utvecklingsmetod efterföljdes var detta möjligt. Som tidigare nämnts, i kapitel 7.1.1, var detta resultatet av att gruppen saknade erfarenhet och kunskap inom systemutveckling och utveckling med det valda verktyget. Trots att JavaScript är det vanligaste språket inom webbutveckling valde gruppen att arbeta med Dart. Det finns mycket dokumentation om bibliotek till JavaScript som kan användas för att underlätta implementeringen. Ett problem med dessa bibliotek är att de inte alltid är kompatibla med varandra. Eftersom Dart är ett nytt språk finns inte dokumentation och bibliotek i samma utsträckning som för JavaScript, vilket har försvårat implementeringen. Men att valet föll på Dart var för att det är mer objektorienterat än vad JavaScript är, vilket ger en bättre systemarkitektur. Gruppen implementerade ändå JavaScript i projektet för att kunna använda sig av biblioteket D3js till att göra grafen. Till en början hade gruppen tänkt att skriva JavaScript-koden direkt i Dart, på samma sätt som JavaScriptsfunktioner ur Google Maps API användes för att producera sökförslagen. Grafen krävde mycket kod och det resulterade i att översättningen till Dart fick en komplex och svårförståelig syntax. För att fortsatt ha en god systemarkitektur och lättöverskådlig kod, valde gruppen att skriva JavaScript -koden i en separat fil som endast hanterade grafen. På så sätt behölls projektet vidareutvecklingsbart med god systemarkitektur i Dart-delen och endast en JavaScripts-fil som hanterade en del av projektet. De få funktionaliteter som gruppen utnyttjar från AngularDart fick gruppen att ifrågasätta nyttan med det framför ett program skrivet i enbart Dart. I det slutliga systemet hanterar AngularDart händelsehanteringen, men om projektet skulle haft en senare deadline hade en disskusion förts om ytterligare en refaktorering i form av byte till ren Dart. Utvecklingsgruppen har även haft problem med utvecklingsmiljön, DartEditor, vilket har lett till att gruppen inte kunnat dra nytta av alla de funktionaliteter som DartEditor innehåller. Ett av problemen som uppstod var att vissa funktioner som implementerades inte hade stöd i utvecklingswebbläsaren som stöder Dart-kod. För att kunna köra projektet var det tvunget att kompileras till JavaScript vid varje redigering i Dart-koden, detta tar längre tid och fördröjde utvecklingsarbetet. Problemen var dock inte så pass stora att gruppen kände behov av att byta utvecklingsmiljö. Att implementera verktyg för testning, eller använda testning genom DartEditor, var inte fokus i projektet och valdes därför bort. Att implementera enhetstester skulle möjliggöra att problem i koden kunde hittas och där med lösas. 7.1.3 Förbättringsmöjligheter En förbättringsmöjlighet för applikationen är att göra noggrannare undersökningar och efterforskningar kring valda parametrar och vad dessa innebär. Datakällorna ger exempelvis information om vilken typ av moln som finns, den informationen tas inte hand om i applikationen utan bara den totala molnmängden. Fler navigeringsmöjligheter och möjlighet att spara olika platser som favoritstäder, samt att kunna visualisera dem mot varandra i grafen är funktionaliteter som diskuterats men som inte implementerats. Att beräkna osäkerheten för en prognos så att användaren får en osäkerhetsbedömning presenterad för sig är också en förbättringsmöjlighet. På så vis får användaren möjlighet att göra en egen osäkerhets- 22