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

Storlek: px
Starta visningen från sidan:

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

Transkript

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

2 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

3 Innehåll Sammanfattning Figurer Typografiska konventioner i iv vi 1 Inledning Bakgrund Syfte Frågeställning Mål och visioner Avgränsningar Bakgrund 3 3 Relaterat arbete Utvecklingsverktyg Väderprognosmodeller Framtagning av väderprognoser Alternativ osäkerhetsberäkning Utvecklingsmetodik Agil utvecklingsmetod Organisation Rutiner Dokumentation Versionshantering Testning Workshop Användartest Teknisk lösning 12 ii

4 INNEHÅLL INNEHÅLL 5.1 Systemarkitektur Designmönster Öppna datakällor Säkerhet Utvecklingsverktyg Designval Resultat Utvecklingsmetodik Teknisk lösning Analys och diskussion Metod Utvecklingsmetodik Teknisk lösning Förbättringsmöjligheter Källkritik Resultat Arbetet i ett vidare sammanhang Slutsatser Frågeställningar Litteraturförteckning 25 A MVP 27 B Projektgruppen 28 C Förundersökning 30 D UML-diagram 32 iii

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

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

7 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

8 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

9 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

10 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

11 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

12 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] 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

13 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

14 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 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

15 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

16 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 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 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

17 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 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

18 4.2. RUTINER KAPITEL 4. UTVECKLINGSMETODIK Figur 4.3: En del av projektets commits och branches på Github 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 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 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

19 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

20 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

21 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] 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å ställer en fråga till Då kommer webbläsaren automatiskt att känna av att det är en annan domän som frågan ställs ifrån 14

22 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 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

23 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

24 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

25 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

26 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

27 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

28 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 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

29 7.1. METOD KAPITEL 7. ANALYS OCH DISKUSSION 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 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

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se Agila Metoder Nils Ehrenberg nils.ehrenberg@mah.se Agenda Agila Metoder: Scrum och sprints Lean och Design Workshops Kravställning Agil Utveckling Individer och interaktioner istället för processer Fungerande

Läs mer

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign eller Webbutveckling 1 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se

Läs mer

GRÄNSSNITTSDESIGN. Ämnets syfte. Kurser i ämnet

GRÄNSSNITTSDESIGN. Ämnets syfte. Kurser i ämnet GRÄNSSNITTSDESIGN Ämnet gränssnittsdesign behandlar interaktionen mellan dator och människa med fokus på designaspekterna i utveckling av användbara, tillgängliga och tilltalande gränssnitt. Det innehåller

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

KAi SENSEMAKING SYSTEM

KAi SENSEMAKING SYSTEM Alexander Hall, 791023-8554 Individuellt mjukvaruutvecklingsprojekt 7,5 hp Linnéuniversitetet 2013-06-09 KAi SENSEMAKING SYSTEM ABSTRAKT KAi Sensemaking System är en webbapplikation för feedback/återkoppling

Läs mer

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10 Projekt Rapport RaidPlanner Jeanette Karlsson UD10 Abstrakt: Denna rapport handlar om mitt projekt i kursen Individuellt Mjukvaruutvecklings projekt. Rapporten kommer att ta upp hur jag gått tillväga,

Läs mer

Schemaläggning av personal i publik verksamhet

Schemaläggning av personal i publik verksamhet Schemaläggning av personal i publik verksamhet Tilde Crew: Lovisa Dahl Emma Forsling Parborg Martin Gråd Linnea Malcherek Julia Nilsson Linnéa Nåbo Linköpings Universitet 2 juni 2014 Sammanfattning Denna

Läs mer

Offertförfrågan för ny webbplats svenskscenkonst.se samt socialt forum

Offertförfrågan för ny webbplats svenskscenkonst.se samt socialt forum Offertförfrågan för ny webbplats svenskscenkonst.se samt socialt forum Inledning Vi ska utveckla en ny webbplats på www.svenskscenkonst.se. Vårt mål är att ha en ny webbplats färdig att användas fullt

Läs mer

Decentraliserad administration av gästkonton vid Karlstads universitet

Decentraliserad administration av gästkonton vid Karlstads universitet Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå

Läs mer

Priskamp. En prisjämförelsesite Björn Larsson 130609

Priskamp. En prisjämförelsesite Björn Larsson 130609 Priskamp En prisjämförelsesite Björn Larsson 130609 Abstrakt Detta är en post-mortem slutrapport om mitt projekt "Priskamp" inom ramen för kursen Individuellt Mjukvaruutvecklingsprojekt VT 2013. Projektets

Läs mer

Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012.

Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012. PROJEKT: DICE Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012. UPPDRAG Uppgiften är att arbeta med den första delen av teknikutvecklingsprocessen d.v.s.

Läs mer

Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson

Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson Sammanfattning Det här är slutrapporten för ett projekt som gjordes i kursen Webbprojekt I av tre studenter på programmet webbprogrammerare.

Läs mer

Hi-Fi Prototyping + laborationsgenomgång & verktyg

Hi-Fi Prototyping + laborationsgenomgång & verktyg Hi-Fi Prototyping + laborationsgenomgång & verktyg Karin Fahlquist 2015 Frågor att besvara Vad innebär prototyping? Vad är speciellt med hi-fi prototyping? Hur kan man använda dem? Hur väljer man nivå

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

Läs mer

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 SMULTRON av Fredrik Li, Ester, Anders, Jessica, Philip Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 - När man har turen att hitta en plats där man trivs

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

P ROJEKTRAPPORT L INKÖPING U NIVERSITET TNM094 T EAM V IRTUELLA VATTENFÄRGER

P ROJEKTRAPPORT L INKÖPING U NIVERSITET TNM094 T EAM V IRTUELLA VATTENFÄRGER L INKÖPING U NIVERSITET TNM094 P ROJEKTRAPPORT T EAM V IRTUELLA VATTENFÄRGER Tim B RODIN Alexander C EDERBLAD Kristina E NGSTRÖM Sofia W ENNSTRÖM Anton Ö STERBLAD timbr473 alece341 krien026 sofwe496 antos600

Läs mer

Nedisningsprognoser för vindkraft. Vintervind 2008 17-18 mars 2008 i Åsele

Nedisningsprognoser för vindkraft. Vintervind 2008 17-18 mars 2008 i Åsele presenterat på Vintervind 2008 17-18 mars 2008 i Åsele Esbjörn Olsson SMHI/Sundsvall Innehåll: Bakgrund Nuvarande produktion av isbildningsprognoser Prognosmetoder Prognosmodeller och deras begränsningar

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Användarhandbok för administratörer av tjänsten för Mobil och surfplatta

Användarhandbok för administratörer av tjänsten för Mobil och surfplatta Användarhandbok för administratörer av tjänsten för Mobil och surfplatta Ideon Science Park Scheelevägen 17 223 70 Lund, Sweden Innehåll Inledning... 3 Om Handboken... 3 Målgrupp... 3 Översikt av Applikationen...

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

Meteorologi - Grunder och introduktion - Meteorologiska modeller och prognoser

Meteorologi - Grunder och introduktion - Meteorologiska modeller och prognoser Meteorologi - Grunder och introduktion - Meteorologiska modeller och prognoser Elin Sjökvist, meteorolog elin.sjokvist@smhi.se Innehåll Grundläggande meteorologi Hur väder uppstår Molnbildning Nederbörd

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser.

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser. WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

på ett stort spelföretag Andreas Ström

på ett stort spelföretag Andreas Ström på ett stort spelföretag Andreas Ström - Spelföretag som är B2C och B2B orienterat. Bygger en pokerplattform som säljs och driftas som en tjänst till andra företag. - Grundades 1999 i Uppsala - Scrum sedan

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Manual HSB Webb brf 2004 03 23

Manual HSB Webb brf 2004 03 23 TERMINOLOGI I Polopoly används ett antal grundläggande begrepp för publicering och hantering av information, eller innehåll som det också benämns. Nedan följer en kort genomgång av denna grundläggande

Läs mer

Callisma (2 mån) Adam levererade en modern och plattformsoberoende webbplats som även är integrerad till en E-handelsplattform.

Callisma (2 mån) Adam levererade en modern och plattformsoberoende webbplats som även är integrerad till en E-handelsplattform. KONSULTPROFIL Adam Frontend-utvecklare Sammanfattning Adam är en senior frontend-utvecklare med tyngd på HTML, CSS och JavaScript. Han fungerar väldigt bra både i team och individuellt. Han drivs av att

Läs mer

WEBBKLUSTRING SLUTRAPPORT

WEBBKLUSTRING SLUTRAPPORT Arne Jönsson 2014-01-09 WEBBKLUSTRING SLUTRAPPORT 1. Inledning Inom projektet har vi utvecklat teknik som gör det möjligt att identifiera webbsidors innehåll och därefter klustra (gruppera) dem så att

Läs mer

Bruse - en webbdatabas för filhantering Projektrapport, TNM094. Grupp J Erik Olsson Ronja Grosz Klas Eskilson Daniel Rönnkvist Therése Komstadius

Bruse - en webbdatabas för filhantering Projektrapport, TNM094. Grupp J Erik Olsson Ronja Grosz Klas Eskilson Daniel Rönnkvist Therése Komstadius Bruse - en webbdatabas för filhantering Projektrapport, TNM094 Grupp J Erik Olsson Ronja Grosz Klas Eskilson Daniel Rönnkvist Therése Komstadius 8 juni 2015 Sammanfattning Den här rapporten beskriver hur

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

1d, Individuellt Designkoncept, GPS-navigering för cykel i stadsmiljö

1d, Individuellt Designkoncept, GPS-navigering för cykel i stadsmiljö 1d, Individuellt Designkoncept, GPS-navigering för cykel i stadsmiljö Design & Struktur Applikationen är designad för att användas som ett navigeringssystem för cyklister i stadsmiljö. Eftersom cyklister

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Erik Lundgren 820419-1491. GarageLoppisen.se. Projekt i kursen Individuellt Mjukvaruutvecklingsprojekt, 1dv430

Erik Lundgren 820419-1491. GarageLoppisen.se. Projekt i kursen Individuellt Mjukvaruutvecklingsprojekt, 1dv430 Erik Lundgren 820419-1491 GarageLoppisen.se Projekt i kursen Individuellt Mjukvaruutvecklingsprojekt, 1dv430 Abstrakt En kort rapport om projektet GarageLoppisen.se. En applikation som skapats för att

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp 2008 02 21 Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp PM, Seminarie SEM1, 3hp Kapitel 4 Seminariegrupp 7 Författare: Robin Hellsing Robin Jarl Handledare: Rolf Lövgren Sammanfattning

Läs mer

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson PROJEKT ALBYLEN Datum: 25 mars 2011 AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson 0 Sammanfattning: Föreningen Albylen som bedriver aktivitets- och friskvårdscentrum

Läs mer

TDDD26 Individuell projektrapport

TDDD26 Individuell projektrapport TDDD26 Individuell projektrapport Kort beskrivning av projektet Vi hade som projekt att utveckla en digital media servicer som skulle hjälpa filmentusiasten att organisera sitt filmbibliotek. Programmet

Läs mer

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5)

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5) Läs mig först Stockholms stad SOA-plattform 1 (5) Innehållsförteckning 1 Beskrivning av SDK 3 1.1 Software Developer Kit för Utvecklare... 3 1.2 Support för... 3 1.3 Omfattning... 4 1.4 Versionshantering...

Läs mer

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp

Läs mer

Anpassningsbar applikationsstruktur för flerpunktsskärmar

Anpassningsbar applikationsstruktur för flerpunktsskärmar Datavetenskap Opponent(er): Rikard Boström Lars-Olof Moilanen Respondent(er): Mathias Andersson Henrik Bäck Anpassningsbar applikationsstruktur för flerpunktsskärmar Oppositionsrapport, C/D-nivå 2005:xx

Läs mer

TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE

TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE DET HÄR ÄR TEAMENGINE DISTRIBUERA STYRELSEMATERIALET ENKLARE Med TeamEngine styrelseplats får du och övriga styrelsemedlemmar en

Läs mer

<script src= http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js></script> AngularJS Skriven av: Isak Glans. Datum: 2015-04-29. Kurs: Webbutveckling. Lärare: Per Sahlin. Utbildning: Systemutvecklare i.net, Newtons Yrkeshögskola. 1 Sammanfattning Syftet med denna uppsats är att

Läs mer

För varje barns rätt att upptäcka världen

För varje barns rätt att upptäcka världen För varje barns rätt att upptäcka världen Lär dig använda din GPS 1 Vad är GPS? GPS står för Global Positioning System (Global Positions System). GPS använder sig av 27 satelliter som cirkulerar runt jordklotet,

Läs mer

Deadline 3. Grupp A.4 Kathrin Dahlberg Elin Gardshol Lina Johansson Petter Liedberg Pernilla Lydén

Deadline 3. Grupp A.4 Kathrin Dahlberg Elin Gardshol Lina Johansson Petter Liedberg Pernilla Lydén Deadline 3 Grupp A.4 Kathrin Dahlberg Elin Gardshol Lina Johansson Petter Liedberg Pernilla Lydén 1 3. Kartlägg kundens röst För att få en klar bild av kundens nuvarande och kommande behov definieras marknaden

Läs mer

Kandidatarbete I- data

Kandidatarbete I- data Kandidatarbete I- data TDDD83 Aseel Berglund aseel.berglund@liu.se Journey line X KURSINFORMATION Mål Utveckla e? litet webbaserat affärssystem av typ e- bufk. Skriva rapport inkl marknasföringsplan för

Läs mer

FLEX Personalsystem. Uppdateringsanvisning

FLEX Personalsystem. Uppdateringsanvisning FLEX Personalsystem Uppdateringsanvisning Innehållsförteckning UPPDATERING... 3 Allmänt... 3 Förberedelser... 3 Informera om uppdatering... 3 Ladda hem uppdateringsfiler... 4 Att observera vid uppdatering...

Läs mer

Snake App Rapport - Snake App Rapport Utskriven/PDF Export: 2011-10-17 Copyright 2011 - Version 1.2 Sidan 1 av 9.

Snake App Rapport - Snake App Rapport Utskriven/PDF Export: 2011-10-17 Copyright 2011 - Version 1.2 Sidan 1 av 9. Snake App Rapport - Snake App Rapport Utskriven/PDF Export: 20-0-7 Copyright 20 - Version.2 Sidan av 9 Snake App Rapport DAT255 - Software engineering project Jesper Sjövall Martin Sonesson Alesandro Sanchez

Läs mer

Sällskapsspel baserat på mobilkluster

Sällskapsspel baserat på mobilkluster LINKÖPINGS UNIVERSITET 19 juni 2014 Institutionen för Teknik och naturvetenskap TNM094 Medietekniskt kandidatprojekt Projektrapport Sällskapsspel baserat på mobilkluster Joakim Deborg Marcus Nygren Mikael

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Manual - Ledningskollen i mobilen

Manual - Ledningskollen i mobilen 8010 Manual Ledningskollen i mobilen.docx Manual - Ledningskollen i mobilen Innehållsförteckning 1. Introduktion 2. Inkluderade funktioner 3. Manualens upplägg 4. Kortversion av manualen 4.1 Registrera

Läs mer

Introduktion Vi har som uppgift att göra ett systemutvecklingsprojekt åt en kund. Målet är att tillfredställa alla behov denne kund har.

Introduktion Vi har som uppgift att göra ett systemutvecklingsprojekt åt en kund. Målet är att tillfredställa alla behov denne kund har. Projektplan Introduktion Vi har som uppgift att göra ett systemutvecklingsprojekt åt en kund. Målet är att tillfredställa alla behov denne kund har. Projektöversikt Roller och ansvar Projektledare: Fanny

Läs mer

Process- och metodreflektion Grupp 5

Process- och metodreflektion Grupp 5 Process- och metodreflektion Grupp 5 IDM Grupp 5 Anders Fougstedt, Anders Green, Lay Truong, Anna Sjödin, Tobias Kask Val av metoder Det första steget i vår designprocess var att bestämma vilka metoder

Läs mer

Våra designmål Roligt Lättnavigerat Lekfull. Vår målgrupp Barn mellan 9-13 år som vill lära sig mer om väder.

Våra designmål Roligt Lättnavigerat Lekfull. Vår målgrupp Barn mellan 9-13 år som vill lära sig mer om väder. Våra designmål Roligt Lättnavigerat Lekfull Vår målgrupp Barn mellan 9-13 år som vill lära sig mer om väder. Vårt koncept En app med ett spel där vädret är i fokus. Användaren tar sig vidare i spelet genom

Läs mer

Institutionen för matematik och datavetenskap Karlstads universitet. GeoGebra. ett digitalt verktyg för framtidens matematikundervisning

Institutionen för matematik och datavetenskap Karlstads universitet. GeoGebra. ett digitalt verktyg för framtidens matematikundervisning Karlstads GeoGebrainstitut Institutionen för matematik och datavetenskap Karlstads universitet Mats Brunström Maria Fahlgren GeoGebra ett digitalt verktyg för framtidens matematikundervisning Invigning

Läs mer

Mäta rakhet Scanning med M7005

Mäta rakhet Scanning med M7005 Matematikföretaget jz M7005.metem.se 141121/150411/150704/SJn Mäta rakhet Scanning med M7005 Mätgivare Detalj Mäta rakhet - Scanning 1 (12) Innehåll 1 Ett exempel... 3 2 Beskrivning... 6 2.1 Scanna in

Läs mer

Introduktion till programmering. Programspråk och paradigmer

Introduktion till programmering. Programspråk och paradigmer Introduktion till programmering Programspråk och paradigmer Vad är ett programspråk? Aprogramming languageis a formal constructedlanguagedesigned to communicate instructions to a machine, particularly

Läs mer

ATT ARBETA MED VEKTORGRAFIK

ATT ARBETA MED VEKTORGRAFIK ATT ARBETA MED VEKTORGRAFIK Helene Brogeland Vektorgrafik och animation VT 2014 2014-04-29 Inledning Före aktuell kurs hade jag bara en vag uppfattning av innebörden av vektorgrafik och hade aldrig jobbat

Läs mer

Medieteknologi Webbprogrammering och databaser MEB725, 5p (7,5 ECTS) Klientprogrammering JavaScript Program på flera sidor

Medieteknologi Webbprogrammering och databaser MEB725, 5p (7,5 ECTS) Klientprogrammering JavaScript Program på flera sidor http://w3.msi.vxu.se/multimedia Medieteknologi Webbprogrammering och databaser MEB725, 5p (7,5 ECTS) Klientprogrammering JavaScript Program på flera sidor Rune Körnefors Innehåll Variabler i JavaScript

Läs mer

Sammanhållen hantering. En ansökan och ett beslut

Sammanhållen hantering. En ansökan och ett beslut Sammanhållen hantering En ansökan och ett beslut Bakgrund och syfte När det nuvarande studiestödssystemet infördes år 2001, valde CSN att varje studiestödsform skulle hanteras som separata ärenden (ärendeklasser).

Läs mer

Introduktion. Byggstenar TDBA63 2005-11-22

Introduktion. Byggstenar TDBA63 2005-11-22 Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet

Läs mer

Design och konstruktion av grafiska gränssnitt

Design och konstruktion av grafiska gränssnitt Design och konstruktion av grafiska gränssnitt Peter Börjesson Interaktionsdesign Tillämpad informationsteknologi Chalmers/GU Idag Kort kursinfo Lab info Föreläsning - Vad utmärker ett bra användargränssnitt?

Läs mer

Grafisk formgivning. Gränssnittet utformning skall på ett naturligt sätt stödja användarens interaktion mot programsystemet

Grafisk formgivning. Gränssnittet utformning skall på ett naturligt sätt stödja användarens interaktion mot programsystemet 1-1 Grafisk formgivning Gränssnittet utformning skall på ett naturligt sätt stödja användarens interaktion mot programsystemet Komponenter måste utformas och användas på ett konsekvent och enhetligt sätt.

Läs mer

Föreläsning 15: Repetition DVGA02

Föreläsning 15: Repetition DVGA02 Föreläsning 15: Repetition DVGA02 Vad handlar kursen om? Kursen kan i grova drag delas upp i tre delar: 1. Objekt-orienterad programmering 2. Grafiska användargränssnitt 3. Datastrukturer Dessutom genomsyras

Läs mer

Netwise Office Web. 2001-12-05, Rev 1.0, CJ 1(30)

Netwise Office Web. 2001-12-05, Rev 1.0, CJ 1(30) Netwise Office Web Netwise Office Web... 2 Allmänt... 2 Användargränssnitt... 2 Inloggning... 4 Felmeddelande vid personlig inloggning... 5 Katalogsökning... 6 Användarinformation... 8 Avancerad sökning...

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

Projektanvisning. Webbsideprojekt. Författare: Johan Leitet Version: 2 Datum: 2012-10-09

Projektanvisning. Webbsideprojekt. Författare: Johan Leitet Version: 2 Datum: 2012-10-09 Projektanvisning Webbsideprojekt Författare: Johan Leitet Version: 2 Datum: 2012-10-09 Inledning Du har nu under ett antal laborationer i webbteknik fått relativt styrda uppgifter där du ensam fått lösa

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Hur vill du använda Visma Severa via din mobil?

Hur vill du använda Visma Severa via din mobil? Hur vill du använda Visma Severa via din mobil? Resultat Severa Mobile -undersökning Förord Tack alla ni som medverkade i denna undersökning som vi fick 389 svar på. Detta är en av de mest kompletta undersökningar

Läs mer

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1 " Scrum Scrum en beskrivning a description 1" 1 Scrums principer Värderingar från Agile Manifesto Scrum är mest känt av de agila arbetssätten. Agile Manifesto utgör en gemensam bas för att arbeta agilt

Läs mer

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08 JavaRats Kravspecifikation Version 1.1 Gustav Skoglund gussk258@student.liu.se Marcus Widblom marwi026@student.liu.se Senast ändrad: 13 / 05 / 08 Sammanfattning Kravspecifikationen för JavaRats har skrivit

Läs mer

Granskning av bokslutsprocessen

Granskning av bokslutsprocessen www.pwc.se Revisionsrapport Martin Westholm Granskning av bokslutsprocessen Motala kommun Innehållsförteckning 1. Sammanfattning och revisionell bedömning... 1 2. Inledning... 2 2.1. Bakgrund... 2 2.2.

Läs mer

Agil programutveckling

Agil programutveckling Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1 1. Inledning 3 2. Extreme Programming (XP)

Läs mer

Bilagor Projektrapport VoteIT år 1

Bilagor Projektrapport VoteIT år 1 1(6) Bilagor Projektrapport VoteIT år 1 Innehåll Bilaga 1. Kravspecifikation... 2 Bilaga 2: Checklista för årsmötesprocessen... 3 Bilaga 3: Om typen av möten som ska stödjas... 5 Bilaga 4. Kvalitetsplan...

Läs mer

TDDC74 - Projektspecifikation

TDDC74 - Projektspecifikation TDDC74 - Projektspecifikation Projektmedlemmar: Namn Efternamn abcde123@student.liu.se Namn Efternamn abcde123@student.liu.se Handledare: Handledare handledare@ida.liu.se eller handledare@student.liu.se

Läs mer

ALM Live: Scrum + VSTS

ALM Live: Scrum + VSTS ALM Live: Scrum + VSTS Explained and distilled for Everyone! Micael Herkommer micael.herkommer@inexor.se Introduktion Micael Herkommer Developer Coach & Solutions Architect INEXOR EPiServer Professional

Läs mer

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

Snabbstartsguide. Visa eller växla mellan onlinekonton Klicka på ditt konto-id för att ändra inställningar eller växla mellan konton.

Snabbstartsguide. Visa eller växla mellan onlinekonton Klicka på ditt konto-id för att ändra inställningar eller växla mellan konton. Snabbstartsguide Microsoft OneNote 2013 ser annorlunda ut jämfört med tidigare versioner, så vi har skapat den här guiden för att hjälpa dig minimera din inlärningskurva. Växla mellan pekskärm och mus

Läs mer

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se Agila Avtal Hur man säljer in agila projekt olika avtalsformer som kan fungera Carina Meurlinger carina.meurlinger@agero.se Min syn på saken och kundens Detta är vad vi alla önskar Lite om mig själv Carina

Läs mer

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Collector en Android-app för att samla saker Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Abstrakt Jag har gjort en Android-app för att samla saker, Collector. Med den kan man upprätta att göra-listor

Läs mer

Användarmanual. 88 SEA för iphone. OBSERVERA! 88 SEA för iphone och 88 SEA HD för ipad är två separata produkter.

Användarmanual. 88 SEA för iphone. OBSERVERA! 88 SEA för iphone och 88 SEA HD för ipad är två separata produkter. Användarmanual 88 SEA för iphone OBSERVERA! 88 SEA för iphone och 88 SEA HD för ipad är två separata produkter. Välkommen! Grattis och välkommen till världen kring 88 SEA. 88 SEA är en komplett sjökortsnavigator

Läs mer

SCRUM och mycket mer

SCRUM och mycket mer Typ av dokument Anvisning Skapad Senaste uppdatering 2008-01-27 2008-11-13 1 (5) Sida 1 Det minsta möjliga? SCRUM och mycket mer Om man nu vill vara agile och inte har allt tid i världen, vad skall man

Läs mer

Projektplan, teaterqlan

Projektplan, teaterqlan Projektplan, teaterqlan 1.1 Projektbenämning TeaterQlan 1.2 Projektgrupp Malimo Productions har tre medarbetare. Det är Mario Frost, Linnéa Forsberg och Mona Wallin Utefter kvalifikationer och personliga

Läs mer

Webbservrar, severskript & webbproduktion

Webbservrar, severskript & webbproduktion Webbprogrammering Webbservrar, severskript & webbproduktion 1 Vad är en webbserver En webbserver är en tjänst som lyssnar på port 80. Den hanterar tillgång till filer och kataloger genom att kommunicera

Läs mer

Tor Sterner-Johansson Thomas Johansson Daniel Henriksson

Tor Sterner-Johansson Thomas Johansson Daniel Henriksson Lab 4: Anti Tower Defence Oskar Mothander Alan Mendez Larsson dit06omr dit06mln Lärare: Handledare: Johan Eliasson Johan Granberg Tor Sterner-Johansson Thomas Johansson Daniel Henriksson Innehåll 1. Problemspecifikation...

Läs mer

Kursplanering Objektorienterad programmering

Kursplanering Objektorienterad programmering Kursplanering Objektorienterad programmering Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-OOP Klass Systemutvecklare.NET 2 Syfte och koppling till yrkesrollen Syftet är att få en stabil grund

Läs mer

UML. Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo.

UML. Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo. UML Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo.fi/~tczarnec Abstrakt The Unified Modeling Language, UML, är ett visuellt

Läs mer

1. Etablera projektet

1. Etablera projektet 1. Etablera projektet Detta är det första steget i projektet och definierar ramarna mellan vilka produktframställningen skall ske. 1.1 Projektdefinition 1.1.1 Intressenter Projektets intressenter har identifierats

Läs mer

Exempel på verklig kravspecifikation

Exempel på verklig kravspecifikation Exempel på verklig kravspecifikation Detta är ett exempel på en proffessionell kravspecifikation hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och

Läs mer

ADAM TELLIA ALICE LUNDIN CHRISTOFFER ENGELBREKTSSON MARCUS LILJA MICHAEL NOVÉN OSKAR CARLBAUM SANDRA TRÅVÉN KARLJOHAN LUNDIN PALMERIUS

ADAM TELLIA ALICE LUNDIN CHRISTOFFER ENGELBREKTSSON MARCUS LILJA MICHAEL NOVÉN OSKAR CARLBAUM SANDRA TRÅVÉN KARLJOHAN LUNDIN PALMERIUS TV-SPEL FÖR MOBILA ENHETER MEDIETEKNISKT KANDIDATPROJEKT NORRKÖPING, 2015-06-08 AV ADAM TELLIA ALICE LUNDIN CHRISTOFFER ENGELBREKTSSON MARCUS LILJA MICHAEL NOVÉN OSKAR CARLBAUM SANDRA TRÅVÉN Linköpings

Läs mer

Alla filer som bearbetar PHP script ska avslutas med ändelsen.php, exempelvis ska en indexsida till en hemsida heta index.php

Alla filer som bearbetar PHP script ska avslutas med ändelsen.php, exempelvis ska en indexsida till en hemsida heta index.php Introlektion PHP är ett av de enklare språken att lära sig just pga. dess dynamiska struktur. Det används för att bygga upp båda stora och mindre system. Några vanliga system som använder sig av PHP är

Läs mer