Figur 5.11: Färgskala för databilderna. Siffrorna visar vad vilken fart färgerna representerar.
Data som ska visas kan filtreras med avseende på plats, tid, id för en busslinje och id på en buss. För att filtrera med tid finns två datum-och tidrutor, där den första rutan bestämmer startdatum och starttid, och den andra rutan bestämmer slutdatum och sluttid. Det finns även en knapp som helt stänger av och på tidsfiltreringen. För att filtera med id finns två textrutor där flera id kan skrivas samtidigt, för att enbart visa data associerade med dessa, i figur 5.12 visas en sådan filtrering.
Figur 5.12: Data filtrerad med avseende på en enda busslinje i Norrköping.
Det finns även en blå hjälpknapp som visar instruktioner, och en knapp som visar en sidolista till vänster i klienten vari olika inställningar kan bestämmas, till exempel kan an- vändaren välja att se Norrköping eller Linköping. Denna lista innehåller även ofullständiga kontroller som ej har någon funktion.
5.6
Systemets kvalitetskrav
I detta kapitel presenteras resultatet av de kvalitetskrav projektet hade. Dessa inkluderar an- vändbarhet och underhållbarhet. Även resultatet av kvalitetscoachingen gruppen fick pre- senteras.
5.6.1
Användbarhet
Som förklarades i 4.14.1 Användbarhet, använde sig gruppen av SUS-enkäten för att få mäta systemets användbarhet. Representanten för behovsägaren lyckades utföra ett av två upp- drag i SUS-enkäten (se figur N.1 i bilaga N Svar på SUS-enkät). Hur behovsägaren svarade på SUS-enkäten framgår i figur N.2 i bilaga N Svar på SUS-enkät. Enkätens resultat blev 52,5 poäng av 100 möjliga.
5.7. Gemensamma erfarenheter
5.6.2
Underhållbarhet
Att fokusera på att systemet skulle vara underhållbart gav som resultat ett modulärt system. Här listas det som kännetecknar systemets modularitet:
• Systemet är byggt enligt en treskiktad klient-server-arkitektur.
• Systemets arkitektur består av tre lager (presentation, logik, och data) och två modu- ler (server-och databas och användargränssnitt) vilket möjliggör ytterligare uppdelning som gör det enklare att uppnå så kallad låg koppling och hög sammanhållning. • Koden som har skrivits är väl kommenterad, vilket underlättar underhåll och vidareut-
veckling av systemet.
5.6.3
Kvalitetscoachning
Fem möten hölls under projektet. Som resultat av coachningen kunde gruppen bestämma de kvalitetsfaktorerna att fokusera på under utvecklingen. Mer information, som anvisning- ar angående metrik och testning, förmedlades under coachningen, men gruppen fick inget konkret resultat utifrån det.
5.7
Gemensamma erfarenheter
Bortsett från de tekniska erfarenheter som erhölls ifrån användningen av programmerings- språk eller verktyg, har gruppen lärt sig arbeta utan bekräftade krav. Det var efter den första iterationen som ett möte med behovsägaren hölls där kraven granskades. Eftersom kraven blev granskade, och färdigställda, i ett senare stadie av projektet, fick gruppen utgå ifrån tänkbara krav som kunden kunde vara intresserad av. Gruppen höll i brainstorm-sessioner där gruppmedlemmarna tog fram alla tänkbara idéer, vilket är en nyttig erfarenhet som hjälp- te när projektet befann sig i sitt tidiga stadie och som gruppmedlemmarna kommer ta med sig till framtida projekt. Gruppen har därför lärt sig arbeta agilt då kraven kontinuerligt upp- daterades.
Nedan listas utförligare beskrivningar av några av de gemensamma erfarenheterna som erhölls:
• Arbete med kund - Detta var första gången som gruppmedlemmarna fick arbeta åt en riktig kund i ett (skol-) projektarbete. Kunden visste att de ville få en plattform för visu- alisering av trafikdata, men visste inte hur programmet skulle se ut, inte heller hur in- formationen skulle visualiseras. Att de inte visste hur programmet skulle se ut innebar kontinuerliga ändringar i det gruppen designade eller utvecklade. I början av utveck- lingen var det speciellt svårt eftersom gruppen fick tolka deras idé och beskrivningar av det de ville, vilket ledde till en misslyckande prototyp, vilket i sin tur innebar många spenderade timmar. Men även en helt misslyckad prototyp var något positiv, eftersom gruppen fick veta vad kunden inte ville ha och bättre förstå deras idé. I helhet var den här upplevelsen mindre optimal, framför allt för ett projekt av den här storleken, men den passade bra för agil systemutveckling, vilket användes. Samtliga medlemmar an- såg att detta arbete mot kunden var en lärorik upplevelse.
• Agilt arbete - Genom att arbeta med obekräftade krav och med en kund som inte visste vad de ville ha, krävde detta att gruppen arbetade agilt. Gruppmedlemmarna har stort sett alltid jobbat med vattenfallsmodellen och det var nyttigt att testa på agilt arbete. Den agila modellen som användes var en modifierad Scrum-modell. Gruppen hade inte dagliga möten, utan hade istället veckoliga möten. Detta då gruppen tyckte att det vore överflödigt och kontraproduktivt med dagliga möten för ett projekt i den här storleken. Vidare var sprintarna en vecka långa. I slutet av en iteration hade gruppen
5.7. Gemensamma erfarenheter
ett större möte där föregående iteration diskuterades. Den här arbetsmetodiken var ny för gruppen och resulterade i nya erfarenheter.
• Workshops - Det visade sig att Workshops var ett nyttigt verktyg och som gruppen uppmanar framtida grupper att nyttja. Workshops användes i ett tidigt stadie för att dela den efarenhet som gruppmedlemmarna hade innan projektet, detta underlättade utvecklingen under de övriga iterationerna. De workshops som hölls i projektet resulte- rade inte bara i nya erfarenheter för deltagarna, utan också var det träning för personen som höll i workshopen. Båda dessa erfarenheter anser gruppen att vara nyttiga. • Övrigt - Framtida grupper bör vara medvetna om att kunden inte alltid har en exakt
plan eller kravlista av det projekt som ska utföras, och det är därför viktigt för gruppen att själva ta fram krav som givetvis bör extraheras utifrån den information som ges av kunden. Att tidigt upprätta korrekt kommunikation med kunden är viktigt för att bygga en stabil grund på vilket det gemensamma arbete mellan kunden och gruppen kommer att ske.
6
Diskussion
I detta kapitel diskuteras projektets resultat och metoderna som användes för att genomföra det. Projektet diskuteras sedan ur ett större perspektiv.
6.1
Resultat
I detta kapitel diskuteras projektets resultat. Diskussionen behandlar främst genereringen av databilderna som är en central del av systemet. Även resultatet av förstudien och modeller- na behandlas. Alternativa implementationssätt nämns och de val som tagits under projektet motiveras.
6.1.1
Förstudien
Förstudiens mål var att hjälpa gruppmedlemmarna inför projektarbetet. Med hjälp av förstu- dien fick gruppen en uppfattning om vilka kunskaper som skulle krävas för att genomföra projektet. Deltagande i utbildningarna beskrivna under kapitel 4.4 Förstudie bidrog till att projektmedlemmarna fick nyttig kunskap inför projektet. Dock kunde mer utbildning under förstudien kanske underlättat utvecklingen av produkten. En workshop i Flask var från bör- jan planerad att utföras, men på grund av tidsbrist ställdes den in. Generellt sett var projekt- gruppen tvungen att lära sig mycket under projektets gång, till exempel inom Flask, SQLite, Leaflet och Mapbox. Om detta istället hade behandlats under förstudien som utbildningar för hela gruppen hade alla medlemmar haft en bättre bild av verktygen och hur de används. Istället blev det generellt så att den som implementerade en komponent var den som bäst för- stod hur den fungerade, till skillnad från att låta alla medlemmar få samma lära sig. Om alla medlemmar besuttit en generell uppfattning om hur produktens alla verktyg och därmed komponenter fungerade hade mer diskussion kring implementationer i produkten kunnat uppstå. Det hade i sin tur kunnat leda till mer genomtänkta implementationer, och på så sätt en bättre produkt.
6.1. Resultat
6.1.2
Modeller
Här diskuteras de resulterande modellerna som utgjorde grunden för produkten. Detta in- kluderar systemanatomi och prototyper.
Systemanatomi
Systemanatomin (se figur K.1) skapades som en del av en obligatorisk uppgift i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Ett par veckor in i projektet, när gruppen hade en bättre bild av vad som krävdes av systemet, utökades systemanatomin med fler funk- tioner. Systemanatomin hjälpte gruppen identifiera kritiska funktioner som andra funktioner berodde på. Den var även till hjälp då gruppen skulle strukturera upp resten av arkitekturen. I projektets slutskede följde gruppen upp systemanatomin. Uppföljningen visade att systemanatomin till stor del beskriver hur systemet ser ut. De flesta komponenter och länkar som är beskrivna i den, är även implementerade i någon mening i systemet. Den främsta skillnaden mellan systemet och systemanatomin är att maskininlärningsmodulen i systema- natomin inte implementerades i systemet. Att systemanatomin stämde bra överens med hur slutversionen av produkten blev, förutom att maskininlärningsmodulen saknades, visar att systemanatomin korrekt beskrev komponenternas beroenden. Dock kan detta bero på att systemanatomin utökades i mitten av projektet när en del av systemet redan hade imple- menterats. I helhet har systemanatomin varit användbar för att få en bild av vad som krävs av systemet. Dock var denna bild begränsad från början. Att göra uppföljningar av syste- manatomier kan ge förståelse för dessa begränsningar utifrån det redan implementerade systemets nuvarande tillstånd. Med denna förståelse kan man förhoppningsvis skapa nya systemanatomier i framtiden som bättre täcker det system man vill implementera.
Prototyper
Det går att diskutera på vilket sätt mer detaljerade prototyper hade kunnat bidra till mer användbar kritik från kund och behovsägare. De prototyper som skapades var enkla och saknade en stor del av designen som den riktiga produkten skulle ha. Det berodde till stor del på att ingen projektmedlem hade använt Adobe XD tidigare och att andra saker bedöm- des som viktigare att prioritera. Ibland fick projektgruppen kritik från kund och behovsägare om brister i prototypen som inte var planerade att ha med i slutprodukten. Om prototyperna hade stämt bättre överens med hur produkten skulle fungera hade kunden och behovsäga- ren fått en bättre uppfattning om projektgruppens vision av produkten, och på sätt hade de kanske kunnat ge relevantare kritik.
6.1.3
Generering av bilder och visualisering
Genereringen av GeoTIFF-bilder fungerar relativt bra. Funktionerna som används för att ska- pa datafilerna kan enkelt ändras och utökas för att lagra nya data. Det finns dock ett flertal nackdelar med genereringen. Bland annat är den långsam då stora databaser används och när de valda ytorna på kartan är stora. Detta är svårt att undvika då trafikdata från en veckas tid innebär tiotals miljoner värden.
För att göra genereringen snabbare skapas samtidigt alla fyra databilder. Hade de inte skapats samtidigt måste samma data hämtas ur databasen flera gånger. I och med att data- hämtningen är en mycket långsam del av processen hade detta gjort genereringen betydligt mycket långsammare. Alltså blir processen, med den lösning som implementerades, effekti- vare både tidsmässigt och energimässigt. Troligen vill en användare analysera flera bilder på en gång, och därför är det rimligt att göra alla data tillgängliga samtidigt. Ett annat sätt att göra genereringen snabbare är att sänka upplösningen på bilderna.
Eftersom bilder som täcker stora landytor på kartan generellt består av glesa matriser av bilddata, på grund av att vägar endast täcker en liten del av den undersökta ytan och det är på vägar data finns, innehåller filerna för det mesta lite data. En bildfils storlek beror endast
6.1. Resultat
på dess upplösning och sparad datatyp, vilket innebär att filerna alltid sparas med samma storlek oavsett vad bildfilernas pixelvärden är. Därför blir filerna relativt stora. En bild på 3000x3000 pixlar med ett band är ungefär 35 MB stor. Vill man lagra gamla filer kan detta tyckas vara ett problem för långtidslagring.
En lösning på detta är att komprimera ned de sistnämnda datafilerna. I ett test beskrivet i sektion 5.4.1 resulterade komprimering av två bilder, 59 MB respektive 118 MB stora, i två filer 0.6 respektive 1.4 MB stora. Om komprimering användes skulle långtidslagring inte vara ett stort problem. Vill man spara gamla bilder kan dessa komprimeras, och sedan när de ska analyseras igen kan de enkelt dekomprimeras och användas. Detta skulle i så fall kunna hanteras automatiskt av servern.
En annan möjlighet för att förminska filernas storlek är att ändra den datatyp som spa- ras i filerna. I nuläget är varje pixel i en bild ett 32-bitars flyttal. Tyvärr stödjer inte GDAL 16-bitars flyttal, så det är inte en möjlighet att använda det. 8- och 16-bitars heltal skulle kun- na användas, vilket skulle reducera en bilds storlek fyrfaldigt respektive till hälften. Dock förlorar man den decimala precision man har med flyttal. Denna begränsning kan kringgås genom att multiplicera varje värde som lagras i filen med en skalningsfaktor. Vid visualise- ring kan då värdet som visas divideras med samma skalningsfaktor. Denna lösning har inte implementerats eftersom en bilds storlek inte ses som ett problem.
För att skapa bilderna användes databaser innehållande lagrade realtidsdata. Databaser- na som skapades hade begränsade storlekar på grund av det system som användes för att hämta data. Gratisversionen av Amazon Web Services begränsade datahämtningen till 30 GB i månaden, vilket är en av anledningarna till att trafikdata ursprungligen samplades var 30:e sekund under endast en vecka. Om man vill ha högre upplösning med en snabbare sampel- frekvens krävs stora databaser. Detta har fördelen att man kan göra noggrannare analyser av trafikdata, eftersom fler datavärden finns tillgängliga.
Vissa värden från Trafiklab användes inte och var därmed överflödiga i lagringen. För att minska de data som lagrades begränsades lagringen till att endast innehålla de datavärden som skulle användas. Till exempel filtrerades bussar som ej var i trafik bort, vilket eliminerade ungefär hälften av den bussdata som samplades, vilket under en dag motsvarar miljontals sampel. Detta minskade storleken på databaserna drastiskt. Den slutgiltiga databaslagringen som används lagrar runt 400 MB data per dygn.
Beroende hur noga man vill analysera ett område kan man använda olika bildupplös- ningar. En upplösning på 1/3 pixlar per meter är fördelaktig. Denna upplösning låter van- liga vägars två körfält visas som separata pixlar, eftersom vanliga vägar är 5–6 meter breda. Används en lägre upplösning kommer fler sampel avbildas till samma pixlar som nu täc- ker större landytor. Detta kan vara användbart eftersom en låg upplösning fungerar som ett lågpassfilter på den bussdata som undersöks. Är man inte intresserad av högfrekventa änd- ringar i fart kan det vara användbart att använda låga upplösningar.
Visualiseringen av data med Leaflet Heatmap bedömdes vara sämre än den med Lea- flet.CanvasLayer.Field. Leaflet Heatmaps visualisering består av suddiga punkter som blan- das ihop, vilket betyder att exakt fart inte visas. Det går inte heller att skapa specifik statistik, som till exempel medelvärde, med Leaflet Heatmap. Det finns i princip ingen fördel att an- vända Leaflet Heatmap över Leaflet.CanvasLayer.Field.
6.1.4
Systemets arkitektur
Eftersom systemet byggdes enligt en tre-skiktad klient-server-arkitektur borde systemet bli mer underhållbart och modulärt. På grund av det får systemet en mer sammanhängande struktur. Det innebar också att arbetet behövde delas upp i front- och back-end. Det faktum att projektet och dess struktur inte behövde ändras under projektets gång visar på att arki- tekturen var väl definierad från början.
6.1. Resultat
6.1.5
Alternativa implementationssätt
I detta kapitel diskuteras alternativa implementationssätt till systemet och dess arkitektur. Dessa implementationsmöjligheter är förutom ett par förändringar tagna ur gruppens arki- tekturdokument.
Server- och databasmodul
Istället för att använda en klient-server-modell kan hela systemet implementeras så att det körs på en enda dator, det vill säga utan en extern server där allt körs lokalt. Fördelar med denna implementation är att systemet troligen blir enklare att implementera eftersom det finns färre komponenter. Nackdelar är att allt finns på en dator. Om flera personer vill an- vända Chronos måste alla ha databaserna lagrade på sin individuella dator. Detta kan bli problematiskt om databaserna blir för stora. Stora databaser kan också medföra att webbap- plikationen blir långsam om datorerna inte är kraftfulla nog. Om en extern server används räcker det att den är kraftfull för att hela systemet ska vara användbart och responsivt.
Istället för Flask kan Pythonbiblioteket Django användas. Django är ett mer komplett paket än Flask men kräver mer initial konfiguration. Fördelar med Django är att det är vanligare än Flask för större applikationer. Alltså finns bättre möjligheter till stöd och hjälp från forum och dylikt. En nackdel jämfört med Flask, är att Flask är enklare och snabbare att komma igång med. Annars gör Flask och Django väsentligen samma uppgifter och kan bytas ut vid behov.
Databaserna
Istället för att använda SQLite kan det vara mer passande i en produktionsmiljö att använda exempelvis PostgreSQL. I det fall då högre databasprestanda är nödvändigt, då databasen har många användare och ständigt uppdateras, hade PostgreSQL passat bättre med sitt stöd för samtidighet.
Klientmodulen
Istället för React kan AngularJS (se 3.2.1 AngularJS) användas. Eftersom React endast är ett UI-bibliotek och på grund av att gruppen gjorde ett UI-baserat system, hade dock inte An- gularJS varit att föredra. AngularJS är ett fullständigt ramverk och kommer därmed med fler funktioner som hade varit överflödiga i systemet, och detta hade haft en negativ påverkan på systemets prestanda.
Om systemet inte hade implementerats enligt en klient-server-arkitektur och allt hade behövts köras lokalt, hade användargränssnittet kunnat implementeras i Pythonbiblioteket TkInter. Att köra alla systemets delar lokalt kommer dock med flera nackdelar. Om systemet inte hade byggts enligt en klient-server-arkitektur hade mängden data som lagras, samt de tunga beräkningar som exekveras, blivit ett problem. Att hantera detta lokalt hade betytt att varje användare måste hämta databaserna, som kan bli väldigt stora. Även beräkningarna hade behövts utföras på deras lokala dator, vilket kan ta väldigt lång tid beroende på hur kraftfull datorn som används är. Genom att centralisera dessa på en server kan vilken dator som helst enkelt använda systemet.
Istället för Fetch kan kommunikationen göras med HTML WebSockets. Detta borde ge en mer responsiv kommunikation jämfört med Fetch. En nackdel är att det kan bli svårare att implementera än Fetch. Flask och JavaScript har båda stöd för Fetch och det är enkelt att implementera.
6.1.6
Övrig diskussion
Produkten saknar i nuläget maskininlärningfunktionaliteter vilket hindrar den från att ge fullt värde åt kunden. Eftersom möjligheten att integrera maskininlärningsramverk i platt- formen var efterfrågad, krävs därför att denna integration fullbordas för att produkten ska
6.2. Metod
kunna anses komplett. Denna integrationsmöjlighet finns, men kommer inte fullbordas av projektgruppen på grund av tidsbrist.
6.1.7
Förbättringar från tidigare projekt
I 2.1 Tidigare erfarenheter listas bland annat problem som gruppmedlemmar haft i tidigare projekt. Nedan beskrivs hur gruppen hanterat dessa problem i detta projekt.
• Veckomöten som schemalagts blev kortvariga och kändes onödiga.
Gruppen tyckte att veckomötena hade en lagom längd, och kändes produktiva och nöd- vändiga för projektet. Eftersom arbetet var agilt skedde det många ändringar som i sin tur behövde diskuteras. Arbetsfokuset behövde skiftas flera gånger på grund av seminarier el- ler dokumentation, och därför behövde båda dessa diskuteras för att planera och informera gruppmedlemmarna.
• På grund av bristande kunskap lade projektmedlemmar onödigt mycket tid på att lösa problem gällande Git.
Git var inte heller något större problem då konfigurationsansvarig skapade en grupp med två Gitprojekt i GitLab, en för front-end och en för back-end. Detta delade upp projektet i två mindre projekt och gjorde vardera enklare att underhålla. Samtliga konflikter som uppstod löstes utan större problem.
• Kod som projektmedlemmar skrivit var inte kommenterad, vilket gjorde den svår att förstå.
Gruppen kommenterade ej all kod under projektets gång, utan detta skedde främst i mit-