kuling - väderapp med multipla datakällor,...

Kuling - Väderapp med multipla datakällor, TNM094

Kajsa Fredriksson FranzénMikaela Koller

Rickard LindstedtPetra Öhlin

7 juni 2015

Sammanfattning

Kuling är en webbaserad applikation utvecklad för att visualisera väderparametrar från två olika mete-orologiska myndigheter. Applikationen har utvecklats som ett Medietekniskt kandidatarbete i kursenTNM094 vid Linköpings Universitet. Gruppen fick i uppgift från en kund att skapa en webbapplika-tion som visualiserar väderparametrar baserat på SMHI:s API. Ett önskemål på utökad funktionalitetvar 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 kundengenom 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 projektetmed sprints och delmål inplanerade för att säkerställa att MVP skulle bli klart i tid. Produkten utveck-lades 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 attfå en tydlig systemarkitektur och för att underlätta vidareutveckling. Produkten är en väderapplikationsom jämför väderprognoser från de två meteorologiska instituten Yr.no och SMHI genom bilder i enheader och en graf som visar hur en viss väderparameter skiftar över tid.

i

Innehåll

Sammanfattning i

Figurer iv

Typografiska konventioner vi

1 Inledning 11.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 43.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 84.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 186.1 Utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Teknisk lösning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Analys och diskussion 217.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 248.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äljerden modell som verkar visa en sannolika utveckling[8]. . . . . . . . . . . . . . . . . 6

3.3 Illustration om hur stor del av bedömnigen av prognoser som styrs av meteorologenfrå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






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) ochMeteorologisk 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 ikursen TNM094, Medietekniskt kandidatarbete vid Linköpings Universitet.

1.2 Syfte

Syftet med projektet är att med en skräddarsydd utvecklingsmetodik, baserat på Scrum, utveckla enwebbaserad väderapplikation. Applikationen ska innehålla visualiseringar av väderprognoser basera-de 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å detekniska 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 storpåverkan på både utvecklingen och resultatet av projektet. Den första frågeställningen är även sattefter kursens mål, att utveckla kunskaper inom systemutveckling och utvecklingsmetodik. Den andrafrågeställningen berör visualisering av osäkerhetsbedömning eftersom det var ett område önskvärt attundersö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 ochhur 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 intuitivoch 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 attskapa en applikation som visar väderparametrar genom att användaren får söka efter en plats ochse 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, varatt visualisera osäkerhetsdata, spatialt eller temporalt. Med osäkerhetsdata innebär i det här fallet hurosäker en väderprognos är. Visionerna för projektet sattes internt inom gruppen och handlade omapplikationens slutresultat och utseende.

Målen för MVP, se Bilaga A, delades upp och fördes in i en tidsplanering som milstolpar. Det säker-ställde att målen skulle uppfyllas inom tidsramen. Planeringen gjordes även för att det skulle finnasmö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äkerhetuppfylldes delvis eftersom gruppen valde att visualisera skillnaden mellan två vädermyndigheter. Desatta visionerna uppfylldes också delvis, dels med hjälp av en designworkshop och dels med hjälp avgruppens fokus på fungerande funktioner.

På grund av problem under utvecklingsprocessen hindrades gruppen från att klara av alla satta måloch visioner för applikationen. De hinder som uppstod upp var på grund av tekniska problem meddet valda utvecklingsverktyget och problem med kopplingen mellan JavaScript och Dart. Ett annathinder var att det tog tid att lära sig ett nytt programspråk och en ny utvecklingsplattform. Gruppenhade 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äkertsystem.

1.5 Avgränsningar

Applikationen är begränsad till att vara webbaserad och använda sig av SMHI:s öppna data. Projekt-metodiken 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å uppdateringarom 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 visualiseraväderparametrar. Eftersom gruppen ville att applikationen skulle skilja sig från andra väderapplikatio-ner, beslutades att visualisera väderparametrar från två olika datakällor. Det gör att användaren självkan göra en osäkerhetsbedömning av prognosen.

Den primära målgruppen för applikationen, som även kommer benämnas som Kuling, är personersom äger en mobil enhet med en webbläsare och är en van mobilanvändare. Applikationen är ävenanvä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 ochnackdelar med alla verktyg. Det gäller samtidigt att välja det verktyg som passar bäst för den specifikatillämpningen.

Dart är ett nytt språk utvecklat med syfte att underlätta webbprogrammering. JavaScript, som ärdet vanligaste scriptspråket inom webbutveckling, är ett språk med många tillhörande bibliotek medtillhörande dokumentation [2]. Biblioteken är utvecklade för att underlätta och förenkla arbetet förutvecklare. Google, som har utvecklat Dart, menar att det behövs en drastisk förändring och städ-ning av utvecklingsmöjligheterna för webbutveckling [3]. Dart är objektorienterat och är tänkt attvara enkelt och mer funktionellt. Språket har influenser av Java och JavaScript. Dart-kod kompi-leras till JavaScript för att vara kompatibel med de flesta webbläsare. Google har även skapat entillhörande utvecklingsplattform DartEditor som är utrustad med kompilator, refaktoreringshjälp ochdebug-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 avatmosfären [5]. Därför sker beräkningar av väder med sannolikhetsteori. Eftersom det uppkommer enfeltillväxt som ökar med tiden, visas endast väderprognoser cirka tio dagar framåt, prognoser längrefram är för osäkra. Det uppkommer även felmarginaler eftersom en dator inte kan beräkna med ettfinit antal decimaler vilket leder till avrundningsfel.

Detta leder till att väderprognoser mellan olika myndigheter nästan alltid skiljer sig. Därför byggsalla prognoser upp i kluster, även kallat ensembler, baserade på olika uppskattningar om hur pro-gnosen kommer se ut, se figur 3.1. De olika strecken representerar prognoser beräknade med olikaväderprognosmodeller. Meteorologerna kan utifrån en sådan graf bedöma hur värdet troligtvis kom-mer 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 somefterliknar 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 olikaprognoser. GEFS startades för att behandla olika osäkerheter i väderobservationer, vilket används föratt initiera väderprognosmodeller. Dessa osäkerheter tar hänsyn till att små skillnader i verklighetenoch 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ånskapas. Detta är dock ett extremt exempel. GEFS försöker därför kvantisera osäkerhetsmängden aven prognos genom att generera en ensemble av flera prognoser, där varje minut är annorlunda från deursprungliga observationerna.

SMHI tar fram väderprognoser genom insamling av data och genom val av lämplig modell, exempel-vis GEFS, som bedömer den inlästa datan [7]. Insamling av data sker med många olika parametrarfrån olika platser. Det tas in observationer från bland annat flygplan, fartyg, väderballonger, väderra-dar och satelliter från både automatiska och manuella väderobservationer. Automatiska stationer görmä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. Model-lerna har tagits fram genom att bland annat observerat hur processer i atmosfär, vattendrag och havpåverkar lufttryck och temperatur. Olika modeller används till olika prognoser.

5


Figur 3.2: Illustration av insamlad data som bearbetas av prognosmodeller. Meteorologen väljer denmodell som verkar visa en sannolika utveckling[8].

All den insamlade datan sammanställs i superdatorer och beräknas med globala prognosmodeller tiodygn framåt [10]. Meteorologer väljer sedan en lämplig modell som verkar visa den mest troligautvecklingen, se processen i figur 3.2. Prognoserna bedöms och färdigställs på olika sätt beroendepå hur långt fram i tiden de är. Datorprognoser längre fram i tiden jämförs även med prognoser frånandra 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 över20 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 lokalaprognoser de närmsta 12 timmarna används förutom den aktuella observationsdatan även numeriskaprognosmodeller 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ånett 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 kombinationav information från olika väderprognoser. Där söker meteorologerna efter en minsta gemensammanämnare, även kallad “konsensusprognos”. Vid bedömning av prognoser från och med tre dygn framåtanvänds ensembleprognossystemet vilket jämför 50 prognoser med olika utgångslägen. Figur 3.3visar hur prognoserna som ges ut via olika mediakanaler de första dygnen styrs till störst del avmeteorologen, 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


tolkning av hur osäker en prognos är. Utifrån sådana beräkningar går det att presentera en osäkerhets-bedö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äker-het. På så vis kan osäkerheten antingen beräknas temporalt eller spatialt. Ett exempel på temporalosäkerhet är temperaturskillnaden mellan två tidpunkter. Om SMHI meddelar att temperaturen kom-mer vara tio grader klockan tolv och elva grader klockan ett går det att beräkna en derivata och utifråndet bedöma säkerheten för prognosen. Eftersom det är en liten skillnad mellan de två tidpunkterna gårdet 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 utveck-lingsprocessen av projektet.

4.1 Agil utvecklingsmetod

Arbetet genomfördes enligt en skräddarsydd variant av den agila utvecklingsmetoden Scrum som ärhämtad från en artikel om Scrum [11]. Scrum innebär ett iterativt och inkrementellt arbetssätt medregelbundna 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 endelprototyp av produkt. Varje sprint planerades att vara i två veckor, vilket resulterade i totalt sexsprintar. Det fanns även möjlighet att förkorta sprintarna om så krävdes. Inför varje sprint hölls ensprint planning, där arbetet planerades genom att hämta stories från product backlog. Valda stori-es fördes över till en sprint backlog där de delades upp i mindre tasks. Sprint backlog innehöll deuppgifter som skulle slutföras under den aktuella sprinten. Sista dagen varje vecka hölls en sprint ret-rospect där delleverans av produkt visades upp för alla i utvecklingsgruppen och all kod som skrivitsgranskades. Sista dagen på varje sprint hölls en sprint review där gruppen utvärderade den genom-förda sprinten ur olika synvinklar. Vid behov planerade gruppen om arbetsmetoderna och prioriteradeom stories i product backlog.

Kundmöten planerades in varje sprint för kontinuerlig kontakt och för att säkerställa att projektet varpå väg i rätt riktning. Eftersom kunden inte hade många specifika krav på projektet gavs gruppenvalmöjligheter att utveckla projektet i egen riktning. Under utvecklingsprocessen tillkom heller ingakrav 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 framtidaarbetet och efterforskning kring verktyg gjordes. Varje sprint sattes att vara två veckor. Under sprint 0skrevs ett gruppkontrakt som innehöll mål med projektet och rutiner kring möten, tider och kommu-nikationsvägar. Det gjorde det tydligt för alla medlemmar i gruppen att förstå de andras förväntningaroch vad varje gruppmedlem hade för skyldigheter. Gruppen kom överens om att det var viktigt medbra kommunikation i gruppen samt att alla skulle ha kunskap om alla delar inom projektet. Detta varmöjligt eftersom gruppen endast bestod av fyra personer. Det fanns även utrymme på sprint reviewsatt uttrycka sina åsikter kring hur gruppen fungerade för att följa upp och vidareutveckla det sombeslutades under sprint 0. En tidsplan utformades enligt ett ganttschema, se ett utdrag av schemat ifigur 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 hadegjorts, 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 debeslut som fattades. Under projektets gång delades utvecklingsgruppen upp i mindre grupper föratt effektivisera utvecklingsarbetet. Då gruppen arbetade efter scrum valdes en scrum master ochen produktägare. Även andra roller infördes för att effektivisera arbetet ytterligare. För varje rollförfattades en kort rollbeskrivning för att tydligt visa ansvarsområden och för att undvika missförståndinom 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 rutinerbeskrivs 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 beslutsom tagits. Varje sprint dokumenterades var för sig, där resultatet av varje sprint review och retrospecttydligt strukturerades.

Alla dynamiska dokument, som exempelvis product backlog, hölls levande och uppdaterade genomGoogle Drive. Detta möjliggjorde enkel delning av dokumenten mellan gruppmedlemmarna. Ävenstatiska 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ånproduct backlog bröts ner till tasks som flyttades framåt på boarden under utvecklingen tills de mar-kerats som färdiga, se figur 4.2. Scrumboard uppdaterades varje daily scrum och varje gång en nytask var slutförd, påbörjad eller behövde uppdateras.

9


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 extraherasmed hjälp av dartdocgen. Dartdocgen är Darts egen dokumentationsgenerator som utifrån speciellakommentarer beskriver funktioner och medlemsvariabler i varje klass. Det underlättar för utomståen-de att förstå systemets uppbyggnad vid eventuell vidareutveckling. Rutin för dokumentering av kodvar att varje utvecklare som arbetade med en ny funktionalitet i koden även dokumenterade de nyatillagda funktionerna. Dokumentering med Dartdocgen sammanställdes i slutet av projektet, men ko-den kommenterades även under projektet. En gemensam granskning vid veckans slut kontrolleradeatt 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 attkoden var ordentligt strukturerad och kommenterad. Under projektets gång användes Git och Githubför versionshantering. De rutiner som användes för kodhanteringen illustreras i figur 4.3. Rutinernavar att masterbranchen hela tiden skulle ha en fungerande version av produkten, i figuruen represente-ras masterbranchen av den svarta linjen. Vid start av en ny task skapades en branch vanligtvis utifrånmasterbranchen, dessa representeras av de färgglada linjerna. Efter att en task färdigställts och grans-kats, sammanfogades den med masterbranchen. För att koden hela tiden skulle vara välstruktureradoch kommenterad fick en annan gruppmedlem gå igenom koden innan den sammanfogades med mas-ter. Vid varje commit, till både master och en branch, användes en förklarande text på engelska omvad för ändringar som gjorts. Det gjorde det enklare att återgå till tidigare versioner av programvaran.Commits illustreras i figuren av punkter.

10


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. Detminskade risken för fel i koden samtidigt som alla fick en grundläggande förståelse för hur kodenfungerade. Under dessa möten låg även fokus på kodens struktur och att den var ordentligt kommen-terad. Även simpla tester genomfördes kontinuerligt för att säkerhetställa att applikationen följde dekrav som hade satts upp. Parprogrammering tillämpades på de tasks som ansågs behöva det, vilketmedförde kontinuerlig kodgranskning och effektivare problemlösning. En task ansågs dock inte fär-digtestad förens koden granskats av en person som inte utvecklat den aktuella koden, detta skeddeannars under sprint retrospect.

4.2.4 Workshop

Gruppen uttryckte ett behov av att förtydliga specifika delar av projektet, därför planerades works-hops. Den första workshopen hölls för att komma på en tydlig produktidé och beskrivning utifrån dekrav 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 varmålgrupp, utvecklingsgrupp och kollegor.

Den andra workshopen hade fokus på design eftersom utvecklingsgruppen saknade en tydlig grafiskvision att arbeta mot. Resultatet av den workshopen blev en prototyp som beskrivs utförligare i stycketDesignval 5.5.

4.2.5 Användartest

Kontinuerlig kontakt med användarna för att få återkoppling på produkten har eftersträvats underalla utvecklingslägen. Den första interaktionen med användarna var en förstudie som gjordes via ettwebbformulär. Där ställdes frågor kring nuvarande användandet av väderapplikationer och önskadefunktionaliteter. Resultatet av förstudien gav utvecklingsgruppen fler idéer som användes i den förstaplaneringsfasen 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öranvä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 ochuppmanades 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 attförklara vilket designmönster som tillämpats, vilken utvecklingsplattform som används och hur funk-tionaliteter implementerats.

5.1 Systemarkitektur

Som modelleringsstandard användes UML, Unified Modelling Language. Detta är ett standardiseratspråk inom modellering av system [12]. Denna grafiska metod underlättade bland annat kommunika-tionen av idéer, testning av koncept samt definiering av enheter och klasser. Utifrån denna standardskapades aktivitetsdiagram, användarfallsdiagram och klassdiagram, dessa kan ses i Bilaga D. Använ-darfallsdiagrammet resulterade i en grafisk bild av kundens MVP-krav. Aktivitetsdiagrammet ökadeförståelsen för hur anrop i applikationen skulle implementeras. Klassdiagrammet visar applikationensklasser, hur de hör ihop samt vilka variabler och funktioner en viss klass innehåller. Detta diagramhar 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äntdesignmönster för webbapplikationer [13]. MVC underlättar vidareutveckling och modifiering, ge-nom att strukturerna påverkar varandra minimalt. Det gör det även möjligt att arbeta på flera kompo-nenter samtidigt. Designmönstret består av tre undersystem. I det första, Model, lagras all data i olikaklasser som används av systemet. En Model i Kuling är klassen WeatherData som i sin tur hanterarde klasser som till exempel läser in SMHI:s och Yr:s data. I det andra undersystemet, View, användsdatan för att rita ut de komponenter som systemet består av. Det är även i View som användaren in-tegrerar med systemet genom mjukvarans användargränssnitt, med till exempel knappar. I det sistaundersystemet, Controller, kontrolleras flödet mellan Model och View. Eftersom applikationen är ensingel-page-applikation, har den endast en View som uppdateras dynamiskt, utan att ladda om sidanpå nytt.

Ett exempel är om användaren trycker på en parameterknapp för att ändra visad data. Användarenshandling skickas till Controller som tar emot och sedan kräver uppdatering från aktuell Model somhanterar 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ändarensbegäran till View, som i det här fallet representerar datan i en graf. Figur 5.1 visar även kopplingenmellan 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äderpro-gnosdata. API:erna liknar varandra genom att de båda svarar på en plats given i världskoordinater ochger svar i form av väderparametrar för den aktuella platsen vid olika tidpunkter. En skillnad mellanAPI:erna är att SMHI:s API ger svar i JSON-format och Yr:s API ger svar i xml-format. En annanskillnad är att SMHI svarar med en fullständig tio dygns prognos med femton tillhörande parametraroch Yr svarar med en nio dygns prognos med tolv tillhörande parametrar. SMHI:s API hanterar endastkoordinater 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 olikaformat. Dart är uppbyggt för objektorienterade system, därför skapades två olika klasser som läs-te in väderdata för respektive API. Ytterligare två klasser skapades för bearbetning av datan. Denena klassen definierar ett väderobjekt och den andra tar emot data från båda API:erna och bearbetarprognoserna. Detta medföljer att klasserna som läser in datan även omformulerar dem till sammaformat, listor av väderklassobjekt, som skickas vidare till klassen som presenterar datan. Ett väderob-jekt 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 koor-dinater i form av latitud och longitud. I dagens moderna enheter finns en GPS som kan avslöja varenheter befinner sig. Webbläsaren kan komma åt GPS:en genom att fråga användaren om tillåtelse attta 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. Eftersomatt SMHI:s och Yr:s API:er använder sig av koordinater för att skicka tillbaka väderparametrar mås-te 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 ge-nom implementation av Google Maps API [18]. Eftersom Kuling endast ska visa väderprognoser förSverige 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 para-metrar i form av siffror. Vid temperaturmätning används siffror eftersom det är allmänt känt att tempe-ratur mäts med siffror. Det blir dock svårare när molnighet eller vindstyrka ska översättas. Det är intesä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ålgruppenskulle 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återinte att en förfrågan ställs automatiskt från en annan domän än den som servern använder sig av. Ettexempel ä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ördatorn.

Ett Cross-Origin problem uppstod då applikationen försökte ställa frågor till Yr:s API. Efter dialogmed Yr:s kundtjänst, projektets handledare och kund togs ett beslut om att en proxyserver skullesättas upp. Proxyservern används som mellanhand mellan klienten och Yr:s API för att komma runtproblemet med Cross-Origin. Proxyservern skrevs i PHP och lades upp på en extern apache-server. Iproxyservern tillåts Cross-Origin requests, vilket gör att applikationen kan skicka förfrågan till prox-yn. Förfrågan behandlas sedan i proxyn och skickas vidare till Yr. Eftersom att proxyn inte användersig av en webbläsare blir inte Cross-Origin något problem. Yr:s API svarar sedan tillbaka till proxy-servern, 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 servernsdata genom att rensa requests från allt annat än siffror. Servern kunde gjorts ännu mer säker, meneftersom 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 skickasi HttpRequesten. För att URL:en inte ska innehålla någonting annat än koordinater rensas den tillsden 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 undersprint 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 enrutnätsstruktur av HTML-elementen. Alla HTML-element omgivs av div-taggar med en CSS-klassdefinierad i Bootstrap. Angular är från början ett JavaScripts-bibliotek utvecklat av Google, liksomDart, som underlättar Document Object Model (DOM)-manipulation. I den version av Dart somKuling byggts i finns även Angular integrerat. Angular används bland annat för händelsehanteringoch repetitiv utskrift.

Vid uppstart ville gruppen att applikationen skulle visa positionen för enheten. För det används deninbyggda GPS:en i enheten. Om det finns en GPS i enheten så kan man komma åt den med hjälp avGeolocator 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 an-vändes funktioner som ritar upp grafen, D3js hjälper till med att sätta axlarna rätt samt skala axlarnavarefter datan manipuleras. I D3js kan man rita grafer ovanpå varandra med hjälp av flera lager, därett 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 tydli-gare vision om en slutgiltig produkt, togs två mockups fram under en av de workshops som tidigarenä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 webbaseratgränssnitt för interaktiva prototyper [21]. En skärmdump på delar av resultatet kan ses i figur 5.3och 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åminnautvecklingsgruppen 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å Kulinglä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åeligavisualiseringar för att inte överlasta användaren med information. All den information som presenterasi Kuling är begränsad till det som är relevant för tillfället, det vill säga vilken parameter användarenväljer att visualisera i grafen. Ytterligare information är därefter tillgänglig endast efter val av denspecifika parametern. På detta sätt förses användaren med lite information i taget, och endast vidbegä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 mellande 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öratt tydligt visa var användaren befinner sig. Det gör att kan användaren enkelt och snabbt kan se jäm-fö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 samti-digt som att de ska vara lättförståeliga och ha uppfylla samma syfte, har de samma design men olikabakgrundsfärg. Detta resulterar i att användaren tydligt kan skilja på vilket väder som tillhör vilkenväderstation. Den genomgående strukturen och igenkännande symboler gör Kuling lättförståelig ochlättnavigerad.

All utformning är upplagd med tanke på att Kuling skall vara lätthanterlig för olika mobilenheter oav-sett storlek. Vädret visualiseras genom både bild och text. Texten representerar den valda parameternsvä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 Kulinggenomfö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 ru-tiner och förbättringar av de gamla implementerades efter sprint reviews. Exempel på rutiner somfö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 testadesstående möte med planering på en storbildsskärm. Det gjorde det enklare för gruppen att hålla mötetkort och undvika utsvävningar. Gruppen fortsatte trots det att hålla sittande möten med lärdomen attfölja rutinen att tydligt säga när mötet var avslutat. Planering av var nästkommande arbetsdag skullespenderas 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 upp-levde att olika tasks som satts upp var för otydliga. Åtgärden var checklistor som användes för attbryta ner problemen i mindre delar. Alla gruppmedlemmar markerades även på de kort som de arbe-tade 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örde två meteorologiska instituten Yr och SMHI. Nedan beskrivs hela processen från att applikationenstartas till att alla funktioner förklarats.

Vid start av applikationen visas en splashscreen, se figur 6.1 nedan. Den innehåller applikationensnamn och animerade moln som förflyttar sig på skärmen under tiden applikationen laddar in väder-datan 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örslagpå städer.

Första gången applikationen öppnas kommer användaren vara tvungen att tillåta att applikationen fåranvä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 inför den aktuella staden, visas det aktuella vädret från båda väderinstitutionerna i form av en graf. Föratt välja en annan stad än den aktuella, skriver användaren in valfri stad i Sverige i sökrutan. För attunderlätta och effektivisera sökningen ges förslag på städer i en dropdown under tiden användarenskriver, se figur 6.2 ovan. Genom att trycka på kompassknappen till vänster om sökrutan kan använ-daren 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 igen-kä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 pa-rameterknapp är markerad med en mörk ram, se figur 6.3. Vid val av en ny parameter återkopplasanvä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 hori-sontella värden är dynamiska och ändras utefter visualiserad parameter. Vid molnighet representeraraxeln procent, vilket kan ses figur 6.4 nedan. För nederbörd representerar den millimeter per tim-me, för temperatur visar den antal grader och för vind visas meter per sekund. Den vertikala axelnrepresenterar 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 temperatu-ren.

.

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, sefigur 6.5. Skillnaden mellan de två instituten tydliggörs genom att varje datakälla har linjer i grafeni samma färg som i header, vilket gör att användaren enkelt kan se koppla ihop mätningar med rättinstitut.

Användaren intregrerar med grafen med hjälp av en horisontell linje som tydliggör vilken tidpunktsamt dag som denne har angett. Headern uppdateras därefter och ger återkoppling till användaren meden bild på väderleken för den önskade tidpunkten, samt en text som presenterar värdet för den valdaparametern. Headern har en statisk position och kommer alltid vara placerad i översta fjärdedelen avapplikationen, 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 ifigur 6.6 och 6.7 nedan där moln respektive vind är valda parametrar.

Figur 6.6: Headern när grafen visualise-rar molnmängden.

.

Figur 6.7: Headern när grafen visualise-rar 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 kringpositiva och negativa aspekter av arbetets upplägg, möjliga vidareutvecklingar av systemet samt kritikkring 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 gjor-des 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 grup-pen att veta hur mycket efterforskningar som krävdes och hur de skulle prioriteras. Det ledde till attgruppen väntade med att ta viktiga beslut, vilket fördröjde utvecklingen av projektet. För att lösa pro-blemet implementerades en mindre teknisk studie i början av varje sprint eller i samband med taskssom krävde det.

Ett problem som tidigt uppstod var formulering av och storleken på tasks i en sprint. Eftersom ingenav gruppens medlemmar varken arbetat agilt eller med Dart innan, var det svårt att uppskatta hur långtid olika tasks krävde. Det var även svårt att veta hur mycket uppgifterna behövde brytas ned för attvara 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. Dettaresulterade i att de nya tasks som skapats inte hann slutföras innan sprintens slut. För att undvikadetta 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ättatidsestimeringar för varje task, men på grund av svårigheten att tidsestimera valde gruppen att intetillämpa en sådan åtgärd. Under projektets gång, i och med att utvecklingsgruppen fick mer kunskaperom verktyget, utvecklades en bättre uppskattningsförmåga för hur många tasks som en sprint skulleinnefatta. Detta ledde till att tydligare och mer organiserade sprints.

Utvecklingsgruppen var medveten om att vissa av användartesten var utförda på ett selektivt urvalav målgruppen. Beslut har därför inte kunnat baseras helt och hållet på slutsatserna som dragits frånanvä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 planresulterade i att produkten fick refaktoreras under projektets gång, vilket tog tid från utvecklingen avprodukten. Gruppen ansåg dock att refaktoreringarna var nödvändiga för fortsatt utveckling av pro-jektet. Den första refaktoreringen följde efter att gruppen strukturerade om applikationen efter Dartsmodulbaserade systemuppbyggnad. I den andra refaktoreringen delades klasserna upp tydligare, föratt undvika att en viss klass växer och blir svår att överskåda. Eftersom en agil utvecklingsmetodefterföljdes var detta möjligt. Som tidigare nämnts, i kapitel 7.1.1, var detta resultatet av att gruppensaknade 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ättaimplementeringen. 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örJavaScript, vilket har försvårat implementeringen. Men att valet föll på Dart var för att det är merobjektorienterat ä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 tillatt göra grafen. Till en början hade gruppen tänkt att skriva JavaScript-koden direkt i Dart, på sammasätt som JavaScriptsfunktioner ur Google Maps API användes för att producera sökförslagen. Grafenkrävde mycket kod och det resulterade i att översättningen till Dart fick en komplex och svårförståeligsyntax. För att fortsatt ha en god systemarkitektur och lättöverskådlig kod, valde gruppen att skrivaJavaScript -koden i en separat fil som endast hanterade grafen. På så sätt behölls projektet vidareut-vecklingsbart med god systemarkitektur i Dart-delen och endast en JavaScripts-fil som hanterade endel av projektet.

De få funktionaliteter som gruppen utnyttjar från AngularDart fick gruppen att ifrågasätta nyttan meddet framför ett program skrivet i enbart Dart. I det slutliga systemet hanterar AngularDart händelse-hanteringen, men om projektet skulle haft en senare deadline hade en disskusion förts om ytterligareen refaktorering i form av byte till ren Dart.

Utvecklingsgruppen har även haft problem med utvecklingsmiljön, DartEditor, vilket har lett till attgruppen inte kunnat dra nytta av alla de funktionaliteter som DartEditor innehåller. Ett av problemensom uppstod var att vissa funktioner som implementerades inte hade stöd i utvecklingswebbläsarensom stöder Dart-kod. För att kunna köra projektet var det tvunget att kompileras till JavaScript vidvarje redigering i Dart-koden, detta tar längre tid och fördröjde utvecklingsarbetet. Problemen vardock 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 iprojektet och valdes därför bort. Att implementera enhetstester skulle möjliggöra att problem i kodenkunde 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 efterforsk-ningar kring valda parametrar och vad dessa innebär. Datakällorna ger exempelvis information omvilken typ av moln som finns, den informationen tas inte hand om i applikationen utan bara den totalamolnmängden.

Fler navigeringsmöjligheter och möjlighet att spara olika platser som favoritstäder, samt att kunna vi-sualisera 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örsig är också en förbättringsmöjlighet. På så vis får användaren möjlighet att göra en egen osäkerhets-

22

7.2. RESULTAT KAPITEL 7. ANALYS OCH DISKUSSION

bedömning genom jämförelsen av två datakällor.

7.1.4 Källkritik

Vid undersökning angående kod och systemutveckling fanns dokumentation på Dart och Angu-larDarts hemsida. Där fanns relevanta artiklar samt information om Darts uppbyggnad, struktureroch funktioner. Denna dokumentation ansågs pålitlig då den var skriven av utvecklarna och användessom grund för applikationen.

7.2 Resultat

Osäkerhetsbedömning kan beräknas på olika sätt. Ett sätt är att göra en bedömning genom ensembler,men för detta hade gruppen inte tillräckligt med intresse och tid. Att beräkna osäkerheten med enenkel modell, så som den som presenteras i underrubriken till relaterat arbete 3.2.2, var inte hellernågot alternativ då gruppen ansåg att den beräkningsmodellen inte var tillräckligt pålitlig. Dennamodell ger ett felaktigt resultat om vädret skiftar snabbt eftersom derivatan mellan två tidpunkterdå är hög utan att vara osäker. Samma situation uppstår om osäkerheten beräknas spatiellt, eftersomväder kan vara väldigt lokalt och därmed ha hög spatial derivata utan att vara osäker.

Därför togs beslutet att jämföra Yr och SMHI:s väderdata och därav ge användaren en egen uppfatt-ning om hur osäker prognosen var. Beslutet gjordes även med avseende på resultatet från det andraanvändartestet. Metoden ger inte en korrekt osäkerhetsanalys, men beroende på skillnader i väderda-tan kan användaren själv tolka datan och på så sätt göra en egen osäkerhetsbedömning.

Det går att anropa JavaScript ifrån Dart. Detta har gjorts på två sätt i projektet. För sökförslagen iapplikationen, var gruppen tvungna att använda funktioner ur JavaScript-biblioteket Google Maps.Att läsa in och använda JavaScript-biblioteket i Dart gav en fortsatt god systemarkitektur. För attvidareutveckla produkten krävs att utvecklaren läser in sig på hur biblioteket används samt hur Java-Script-funktioner kallas på ifrån Dart. För grafen anropas en separat JavaScript-fil som använder sigav D3js. Det försämrar systemarkitekturen eftersom det inte blir lika lättöverskådligt med flera olikaprogramspråk samt att dokumentationen i projektet endast innefattar Dart-koden. Gruppen anser ändåatt eftersom JavaScripts-filen endast är begränsad till en funktionalitet är detta okej.

7.3 Arbetet i ett vidare sammanhang

Vid val av verktyg för en webbaserad applikation finns numera väldigt många alternativ. Det är omöj-ligt att testa och undersöka alla ramverk för att veta om de lämpar sig för just det här specifikaprojektet. Lika många ramverk som finns, finns det också åsikter om ramverken. Det gör det svårtatt bedöma verktyget innan en själv testat det. Därför bör det efterforskas om olika alternativ ochanvända det som verkar fungera bäst. Om det visar sig vara något annat än vad som förväntades gårdet i och med ett agilt arbetssätt att refaktorera, det vill säga att börja om med ett nytt ramverk.

För en grupp som ska arbeta en längre period tillsammans är det viktigt att ha en bra gruppkänsla ochatt hålla motivationen uppe under utvecklingsprocessen [12]. Därför har gruppen bland annat priori-terat tillfällen tillsammans för att umgås utan fokus på arbete av projektet. För att hålla motivationenuppe bytte gruppen miljö genom att variera arbetsrum med café och hemmamiljö.

23

Kapitel 8

Slutsatser

8.1 Frågeställningar

Hur erhålls en tydlig systemarkitektur genom att kombinera Dart och Javascript-bibliotek ochhur bidrar den samt utvecklingsmetodiken till en vidareutvecklingsbar produkt?Eftersom Dart är objektorienterat delades systemet in i klasser för olika ändamål. Detta struktureradesenligt Darts beskrivning av hur ett system bör struktureras upp. Genom att använda Dart erhålls därfören tydlig systemarkitektur eftersom uppdelning av klasser gör att det är enklare för en utomståendeperson att förstå systemet.

Det går även att erhålla en tydlig systemarkitektur genom att kombinera JavaScript och Dart. Det somkrävs är att JavaScriptet antingen skrivs i Dart-koden eller att JavaScript-filer hålls till en viss funk-tionalitet och sedan anropas från Dart. Nackdelen med det andra alternativet är att dokumentationensom produceras i projektet endast fungerar för Dart.

Utvecklingsmetodiken Scrum möjliggjorde förändring av planeringen. Eftersom gruppen stötte påproblem vid flera tillfällen och behövde tänka om, fanns möjligheten via Scrum att göra detta ochstegvis arbeta framåt. Det gjorde att gruppen vid två tillfällen kunde strukturera om programmet fören tydligare systemarkitektur.

En tydlig systemarkitektur underlättar vidareutveckling av produkten. Genom det objektorienteradesystemet som byggts upp med hjälp av en utvecklingsmetodik som tillät förändring och omstrukture-ring, kunde därför en vidareutvecklingsbar produkt skapas.

Hur visualiseras osäkerheten för en väderprognos för att erhålla en applikation som är intuitivoch användarvänlig?För att tolka osäkerhetsdata behöver beräkningar göras med ensembler, beskrivet i kapitel 3.2. Demeteorologiska instituten gör detta för att sedan bedöma vilken prognos som är mest trolig och visardetta på sin webbplats och applikation. De flesta väderapplikationer visar inte med hur stor säkerhetprognosen stämmer. Där det visas görs det med en procentsats.

Att beräkna en egen osäkerhetsbedömning fanns som alternativ för gruppen, men på grund av tidsbristoch fokus på andra delar i projektet valdes istället att jämföra två meteorologiska institut, SMHI ochYr. Genom två parallella bilder i en fast header och visualisering med en graf blev applikationenintuitiv och enkel för användaren att se skillnad mellan prognoserna.

Eftersom användartestet visade att användarna ofta jämför två olika väderapplikationer i vardagen,möjliggör Kuling ett enkelt sätt att jämföra olika datakällor i samma applikation.

24

Litteraturförteckning

[1] GitHub (Internet) https://github.com/showcases/front-end-javascript-frameworks [2015-05-14]

[2] John Pollock; technical editor, Christie Sorenson, JavaScript [Elektronisk resurs]: a beginner’sguide, fourth edition 2013.

[3] Dart (Internet) https://www.dartlang.org/support/faq.html [2015-05-14]

[4] Dart (Internet) https://www.dartlang.org/articles/style-guide/ [2015-05-14]

[5] SMHI (Internet) http://www.smhi.se/kunskapsbanken/meteorologi/ensembleprognoser-1.1029[2015-05-14]

[6] NCDC (Internet) http://www.ncdc.noaa.gov/data-access/model-data/model-datasets/global-ensemble-forecast-system-gefs [2015-05-14]

[7] SMHI (Internet) http://www.smhi.se/kunskapsbanken/meteorologi/sa-gor-smhi-en-vaderprognos-1.4662 [2015-05-14]

[8] Smhi (Internet) http://www.smhi.se/polopoly_fs/1.25029.1398236923!/image/Databearbetning.png_gen/derivatives/Original_1004px/Databearbetning.png[2015-06-03]

[9] Smhi (Internet) http://www.smhi.se/polopoly_fs/1.25030.1398236132!/image/PrognosenFärdigställs.png_gen/derivatives/Original_1004px/PrognosenFärdigställs.png[2015-06-03]

[10] SMHI (Internet) http://www.smhi.se/kunskapsbanken/meteorologi/meteorologiska-modeller-1.5932 [2015-05-14]

[11] Schwaber, Ken och Sutherland, Jeff. Den definita guiden till Scrum: spelets regler.http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-SE.pdf. Juli 2013 [2015-05-15]

[12] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Third Edition, Internatio-nal Edition, Pearson 2006

[13] Angulardart (Internet) https://angulardart.org/tutorial/02-welcome-to-angular.html [2015-05-14]

[14] Dart (Internet) https://www.dartlang.org/articles/doc-comment-guidelines/ [2015-05-14]

[15] SMHI (Internet) http://www.smhi.se/klimatdata/oppna-data/meteorologiska-data [2015-05-14]

[16] YR (Internet) http://api.yr.no/weatherapi/locationforecast/1.9/documentation [2015-05-14]

[17] Nominatim (Internet) http://wiki.openstreetmap.org/wiki/Nominatim [2015-05-14]

[18] Google (Internet) https://developers.google.com/maps/documentation/javascript/ [2015-05-14]

25

LITTERATURFÖRTECKNING LITTERATURFÖRTECKNING

[19] SMHI (Internet) http://www.smhi.se/kunskapsbanken/ [2015-05-14]

[20] Twitter Bootstrap (Internet) http://getbootstrap.com/2.3.2/ [2015-05-14]

[21] Fluidui (Internet )https://www.fluidui.com/ [2015-05-14]

[22] Institute of global environment and society (Internet) http://www.iges.org/grads/gadoc/ensembles.html[2015-06-03]

26

Bilaga A

MVP

Nedan listas MVP-kraven från kund.

• Som kund vill jag att hemsidan ska vara webbaserad.

• Som kund vill jag kunna se väder från min position.

• Som kund vill jag kunna se vad det blir för väder senare idag.

• Som kund vill jag kunna se vad det blir för väder i veckan.

• Som kund vill jag kunna välja tid och se plats, alternativt välja plats se tid.

27

Bilaga B

Projektgruppen

Involverade personer samt hanterade stories från backloggen.

Mikaela KollerProduktägareHar dokumenterat vad som gjordes under sprinten och vad som skulle göras framöver. Såg även tillatt dokumentation av systemet gjordes. Som produktägare ansvarade hon även för product backlogoch såg till att dessa krav har följdes utav utvecklingsgruppen.

Behandlade stories från product backlog:

• Som ägare av systemet vill jag att all kod ska vara väl dokumenterad och testad.

• Som användare vill jag ha en lättnavigerad och visuellt tilltalande sida.



• Som kund vill jag kunna välja tid och se plats, alt välja plats se tid.

• Som kund vill jag kunna uppskatta hur osäker en prognos är.

Rickard LindstedtKvalitét- och logistikansvarigHar ansvarat att utvecklingsgruppen följer reglerna för kodgranskning samt att koden följer Dartsstilguide. Som logistikansvarig har han sett till att en sal/grupprum varit bokad varje arbetsdag undersamtliga veckor.




• Som kund vill jag att hemsidan ska vara webbaserad.

• Som kund vill jag kunna se väder från min position.

• Som kund vill jag kunna välja tid och se plats, alt välja plats se tid.


28

BILAGA B. PROJEKTGRUPPEN

Kajsa F. FranzénScrum masterHar ansvarat för att Scrummetoden följts av utvecklingsgruppen och att arbetet har fortskridit ochföljt den angivna tidsplanen.







Petra ÖhlinKundkontakt och användartestsansvarigHar skött all kontakt med kund och bokat kundmöten. Som användartestansvarig har hon även sett tillatt användartester genomförts och att dessa fanns som milstolpar i tidsplanen.




• Som kund vill jag ha kontinuerlig kontakt med utvecklingsgruppen och ha löpande avstämning-ar.




29

Bilaga C

Förundersökning

I denna bilaga visas resultatet från det webbformulär som användes som förundersökning i börjanav projektet. Webbformuläret hade även frågor med fritextssvar som inte tagits med i denna grafiskasammanfattning.

Figur C.1: Illustration av en fråga från förundersökningen.


30

BILAGA C. FÖRUNDERSÖKNING





31

Bilaga D

UML-diagram

I denna bilaga visas tre olika UML-diagram över systemet.

Figur D.1: Aktivitetsdiagram över systemet.

Figur D.2: Användarfallsdiagram över systemet.

32

BILAGA D. UML-DIAGRAM

Figur D.3: Klassdiagram över systemet.

33

kuling - väderapp med multipla datakällor,...

Documents