Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2019 | LIU-IDA/LITH-EX-G--19/010–SE
Plattform för visualisering av
trafikdata
Platform for visualization of traffic data
Juan Basaez
Joakim Bergström
Johan Fisch
Viktor Ivarsson
Oskar Magnusson
Anna Montelius
Felix Nodelijk
Handledare : Rasmus Viitanen Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Juan Basaez Joakim Bergström Johan Fisch Viktor Ivarsson Oskar Magnusson Anna Montelius Felix Nodelijk
Sammanfattning
Den här rapporten redovisar och diskuterar resultatet av ett kandidatarbete. Arbetet som utförts var uppdraget Plattform för maskininlärning och visualisering av trafikdata med Institutionen för datavetenskap som kund och Östgötatrafiken som behovsägare och refe-renspartner. Östgötatrafiken är idag intresserade av maskininlärningsmöjligheter inom tra-fikområdet och efterfrågar en plattform som möjliggör presentation samt analys av trafik-data med hjälp av maskininlärning. Uppdragets syfte var att utveckla en produkt som passade Östgötatrafikens önskemål för att visualisera trafikdata i Linköping och Norrkö-ping.
Projektet utfördes av sju studenter som studerade på Linköpings universitet som en del av kursen TDDD96 Kandidatprojekt i programvaruutveckling och resulterade i webbapplika-tionen Chronos. Chronos är ett system byggt enligt en treskiktad klient-server-arkitektur där klienten är en webbsida byggd i JavaScript med React och servern är byggd i Python med Flask och Flask-SQLAlchemy. Klienten har kontroller för filtrering av data och visua-lisering av trafikdata sker på en Leaflet-karta. De data som visualiseras på kartan hämtas automatiskt från Trafiklab, som tillhandahåller API:er för kollektivtrafiken i Sverige, för att bygga en databas med historisk trafikdata. Visualisering av data sker genom att visa bilder av bussarnas hastigheter över en vald tidsperiod. Rapporten innehåller även individuella bidrag från varje gruppmedlem.
Författarens tack
Ett stort tack till Institutionen för datavetenskap på Linköpings universitet och Östgötatrafiken för att vi fått ta del av ett så spännande och intressant projekt. Vi vill även tacka handledare i kursen TDDD96 Kandidatprojekt i programvaruutveckling för all hjälp och vägledning genom projektet.
Innehåll
Figurer viii 1 Introduktion 3 1.1 Motivering . . . 3 1.2 Syfte . . . 3 1.3 Frågeställningar . . . 3 1.4 Avgränsningar . . . 4 2 Bakgrund 5 2.1 Tidigare erfarenheter . . . 5 3 Teori 7 3.1 Dataformat . . . 7 3.2 JavaScript . . . 8 3.3 Python . . . 9 3.4 SQL . . . 10 3.5 Verktyg . . . 10 3.6 Git . . . 11 3.7 Webbteknologier . . . 12 3.8 Övrig teori . . . 13 4 Metod 15 4.1 Arbetsmetod . . . 154.2 Grupp och projektidentitet . . . 17
4.3 Kundkontakt . . . 17 4.4 Förstudie . . . 17 4.5 Dokument . . . 18 4.6 Google Drive-mapp . . . 18 4.7 Trellotavlor . . . 18 4.8 Versionhantering . . . 19 4.9 Modeller . . . 19
4.10 Utvecklingsmiljö, bibliotek och ramverk . . . 20
4.11 Databaserna . . . 21
4.12 Metod för att fånga erfarenheter . . . 21
4.13 Programvarutestning . . . 21 4.14 Systemets kvalitetskrav . . . 22 5 Resultat 23 5.1 Förstudie . . . 23 5.2 Modeller . . . 23 5.3 Systemets arkitektur . . . 25
5.4 Server- och databasmodulen . . . 26
5.6 Systemets kvalitetskrav . . . 31 5.7 Gemensamma erfarenheter . . . 32 6 Diskussion 34 6.1 Resultat . . . 34 6.2 Metod . . . 38 6.3 Källkritik . . . 44
6.4 Arbetet ur ett större perspektiv . . . 44
7 Slutsats 46 7.1 Hur kan Chronos implementeras så att värde skapas åt kunden? . . . 46
7.2 Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för framtida projekt? . . . 47
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 47
7.4 Hur kan GTFS-data användas för att identifiera problem i trafikflöden? . . . 47
7.5 Hur kan GTFS-data presenteras för att tillåta analys och identifiering av pro-blem i trafikflöden? . . . 47
8 Översikt över individuella delar 49 A Juan Basaez - Konsekvenserna av det vi utvecklar 51 A.1 Introduktion . . . 51 A.2 Teori . . . 52 A.3 Metod . . . 54 A.4 Resultat . . . 56 A.5 Diskussion . . . 64 A.6 Slutsatser . . . 67
B Joakim Bergström - Möjligheter för maskininlärning med GTFS trafikdata i Chro-nos 69 B.1 Introduktion . . . 69 B.2 Bakgrund . . . 70 B.3 Teori . . . 70 B.4 Metod . . . 72 B.5 Resultat . . . 72 B.6 Diskussion . . . 73 B.7 Slutsatser . . . 74
C Johan Fisch - Git vs. SVN som versionshanteringssystem för Chronos 76 C.1 Introduktion . . . 76 C.2 Bakgrund . . . 76 C.3 Teori . . . 77 C.4 Metod . . . 79 C.5 Resultat . . . 80 C.6 Diskussion . . . 81 C.7 Slutsatser . . . 82
D Viktor Ivarsson - En jämförelse mellan utforskande testning och skriptad testning 84 D.1 Introduktion . . . 84 D.2 Bakgrund . . . 85 D.3 Teori . . . 85 D.4 Metod . . . 86 D.5 Resultat . . . 86 D.6 Diskussion . . . 88
D.7 Slutsatser . . . 89
E Oskar Magnusson - En jämförelse mellan D3 och Google Charts för visualisering av statistik i ett mindre projekt 90 E.1 Introduktion . . . 90 E.2 Bakgrund . . . 91 E.3 Teori . . . 91 E.4 Metod . . . 92 E.5 Resultat . . . 92 E.6 Diskussion . . . 94 E.7 Slutsatser . . . 96
F Anna Montelius - Maskininlärning ur ett normkritiskt perspektiv 97 F.1 Inledning . . . 97 F.2 Teori . . . 98 F.3 Metod . . . 98 F.4 Resultat . . . 99 F.5 Diskussion . . . 101 F.6 Slutsatser . . . 103
G Felix Nodelijk - React som verktyg för webbutveckling 104 G.1 Introduktion . . . 104 G.2 Bakgrund . . . 105 G.3 Teori . . . 105 G.4 Metod . . . 108 G.5 Resultat . . . 109 G.6 Diskussion . . . 110 G.7 Slutsatser . . . 112 H Prototyp 1 114 I Prototyp 2 116 J Logotyper 120 K Systemanatomi 121 L Blockdiagram 122 M SUS-enkät 123 M.1 SUS-enkät . . . 123 N Svar på SUS-enkät 126 N.1 SUS-enkät . . . 126 Referenser 129
Figurer
5.1 Bilden visar gränssnittet för den första prototypen då användaren har valt att
vi-sualisera busslinjen 3 från Linköping. . . 24
5.2 Bilden visar hur menyn såg ut vid den senaste versionen av prototypen. . . 25
5.3 Denna bild visar den övergripande arkitekturen av systemet. . . 25
5.4 Trafikdata runt Linköpings Centralstation. Färgskalans gränser är 0 till 40 km/h. . 26
5.5 Trafikdata runt Linköpings Centralstation. Färgskalans gränser är 0 till 40 km/h. . 27
5.6 Bild på slutprodukten. Vänstra sidan av kartan visar en högupplöst bild, högra sidan visar en lågupplöst bild. Färgskalans gränser är 0 till 40 km/h. . . 28
5.7 Bilden visar bussfart under en dag i Linköpings centrum. . . 28
5.8 Bilden visar poppuppfönsteret som visas när en pixel klickas. . . 29
5.9 a) visar huvudkontrollerna för applikationen. b) visar kontroller i den högra menyn. 29 5.10 Fortsättning på kontroller i den högra menyn. . . 30
5.11 Färgskala för databilderna. Siffrorna visar vad vilken fart färgerna representerar. . 31
5.12 Data filtrerad med avseende på en enda busslinje i Norrköping. . . 31
A.1 Hållbar utvecklings representation. . . 52
A.2 SusAD diagram . . . 54
B.1 Ett enkelt neuronnät med ett inputlager, två dolda lager och ett outputlager. . . 71
E.1 Två busslinjers sannolikhet att komma i tid till en viss hållplats. Y-axeln represen-terar procent (0-100) och x-axeln timme (00-23). . . 93
E.2 Två busslinjers sannolikhet att komma i tid till en viss hållplats. Y-axeln represen-terar procent (0-100) och x-axeln timme (00-23). . . 94
G.1 Reacts Livscykelmetoder react_lifecycle_pic . . . 107
H.1 Bilden visar visualisering av trafikinformationen efter att man har valt dag och tidsintervall från filtret. . . 114
H.2 Bilden visar gränssnittet då användaren har valt en hållplats att visualisera. . . 115
I.1 Bilden visar gränssnittet där Linköping är vald och trafikflödet aktiverad. På kar-tan visualiseras trafikflödet i form av heatmap . . . 117
I.2 Bilden visar den svarta versionen av trafikflödet, hållplatserna (blå punkter) samt information angående en specifik hållplats. . . 118
I.3 Bilden visar resultatet användaren får efter att ha valt busslinje 1 . . . 118
I.4 Bilden visar resultatet användaren får efter att ha valt busslinje 1 och en specifik dag av veckan. . . 119
I.5 Bilden visar gränssnittet då användaren har valt att visualisera en busslinje . . . . 119
J.1 Gruppens logga. . . 120
K.1 Denna bild visar den uppdaterade systemanatomin. . . 121 L.1 Denna bild visar blockdiagramet av den slutgiltiga systemarkitekturen. . . 122 M.1 Uppdrag att utföra som en del av SUS-enkäten. . . 124 M.2 Påståenden i SUS-enkäten som användes för att mäta produktens användbarhet. . 125 N.1 Representantens markering angående huruvida hen lyckades med enkätens
upp-drag eller inte. . . 127 N.2 Representantens svar på enkätens påståenden. På grund av att svaren är något
svårtolkade anges varje poäng här i ordningen uppifrån och ned: 3, 2, 2, 2, 2, 4, 5, 4, 3, 2. . . 128
Definitioner
Adobe XD: Ett verktyg för att skapa prototyper av applikationer, som till exempel hemsidor [1].
AngularJS: Ett JavaScript-webbramverk för front-end utveckling [2].
Create React App: Ett verktyg för att skapa single-page applikationer baserade i React [3]. CSV: Står för Comma-Separated Values och är en tabell med värden som är separerade med ett
kommatecken [4].
Django: Ett webbramverk för Python [5].
DOM: Står för Document Object Model och är ett objektmodells- och programmeringsgräns-snitt för HTML [6].
Draw.io: Ett verktyg för att skapa diagram [7].
Fetch: En specifikation för kommunikation över HTTP som stöds av alla moderna webblä-sare [8].
Flask: Ett webbramverk för Python [9].
GDAL: Står för Geospatial Data Abstraction Library och är ett C-bibliotek för hantering av och översättning mellan olika raster och vektordataformat [10].
GeoTIFF: Står för Georeferenced Tagged Image File Format och är ett filformat för lagring av geospatiala data, baserat på bildformatet TIFF [11].
Git: Ett versionshanteringssystem [12].
Google Docs: Ett enkelt program för dokumentskrivning och delning som erbjuds online av Google [13].
Google Drive: En molntjänst som kan användas för att lagra, redigera filer, och dela dem med andra [14].
GTFS: Står för General Transit Feed Specification och är ett vanligt format för tidtabeller och samhörande geografisk information [15].
Figurer
GTFS Realtime: En utökning till GTFS och ger detaljerad reseinformation i realtid [16]. HTTP: Står för Hypertext Transfer Protocol och är ett kommunikationsprotokoll [17]. Leaftlet: Ett JavaScript-bibliotek för att skapa interaktiva kartor [18].
Microsoft Word Online: Ett enkelt program för dokumentskrivning och delning som er-bjuds online av Microsoft [19].
Overleaf: En online LATEX-redigerare för vetenskapliga texter [20].
PEP8: En stilguide för programmeringsspråket Python [21].
PostgreSQL: Ett öppet objektrelationsdatabashanteringssystem [22]. Prettier: En kodformaterare med stöd för bland annat JavaScript [23]. Protocol Buffer: Ett sätt att strukturera data [24].
Rasterio: Ett Pythonbibliotek som abstraherar GDALs funktionalitet och gör den enkel att använda [25].
RDBMS: Står för Relational Database Management System och är den vanligaste typen av da-tabashanteringssystem [26].
React: Ett JavaScript-bibliotek för att skapa av interaktiva gränssnitt för webbläsare [27]. REST API: Står för Representational State Transfer API. Det är en mjukvaruarkitektonisk stil
för hantering av server-klient interaktioner [28].
Scrum: Ett ramverk för att utveckla, tillhandahålla samt underhålla produkt [29].
Single-page-applikation: En webbapplikation som laddar en enda HTML-sida och dyna-miskt uppdaterar den sidan [30].
Slack: Molnbaserat kommunikationsverktyg för grupparbeten [31].
SQL: Står för Structured Query Language och är ett standardiserat programspråk för lagring, manipulering och hämtning av data i databaser [32].
SQLite: Den vanligaste implementationen av RDBMS som använder SQL [33]. TCP/IP: Det grundläggande kommunikationsprotokollet för internet [34]. TensorFlow: Ett maskininlärningsramverk [35].
Trafiklab: En community för öppna trafikdata som tillhandahåller data och API:er för kol-lektivtrafiken i Sverige [36].
Visual Studio Code: En programutvecklingsmiljö [37].
WebSocket: Är ett protokoll som möjliggör dubbelriktad kommunikation mellan en klient och en server [38].
1
Introduktion
I den här rapporten redovisas och diskuteras ett projektarbete utfört av en grupp studenter i kursen TDDD96 Kandidatprojekt i programvaruutveckling på Institutionen för datavetenskap vid Linköpings universitet. Projektarbetet gick ut på att utveckla en webbapplikation som visu-aliserar trafikdata åt Östgötatrafiken, vilka var produktens behovsägare och referenspartner. Officiell kund var Institutionen för datavetenskap. Produkten som utvecklades kallas Chro-nos. Detta kapitel presenterar projektets motivering, syfte, frågeställningar och avgränsning-ar.
1.1
Motivering
Idag går bussar i Östergötland enligt fasta tidtabeller. Ett mer dynamiskt sätt att hantera busstrafik som anpassar planeringen efter hur trafiken ser ut skulle innebära en bättre fun-gerande kollektivtrafik. Trafiklab [39] erbjuder ett flertal API:er för trafikdata med bland annat bussars position och hastighet, men för tillfället har Östgötatrafiken inget verktyg som visualiserar tillgängliga data. Chronos ger möjlighet att visualisera Trafiklabs trafikdata och fungerar på så sätt som ett pedagogiskt verktyg för att ge förståelse för var i trafiken problem ofta uppstår. På så sätt kan utomstående parter, som kommunaltrafikplanerare enkelt få en bild av exempelvis vilka gator som ofta är tungt belastade av trafik.
1.2
Syfte
Syftet med projektet var att utveckla en plattform för att visualisera trafikdata i Linköping och Norrköping åt Östgötatrafiken i ett försök att uppmärksamma problem i busstrafiken och på så sätt bidra till att den kan förbättras. Syftet med den här rapporten är att ge en inblick i hur projektet utförts och vad projektet gav för resultat, och att diskutera den valda metoden samt resultatet utifrån ett antal frågeställningar.
1.3
Frågeställningar
Följande frågeställningar besvaras i rapporten.
1.4. Avgränsningar
2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan GTFS-data användas för att identifiera problem i trafikflöden?
5. Hur kan GTFS-data presenteras för att tillåta analys och identifiering av problem i tra-fikflöden?
1.4
Avgränsningar
Hela projektarbetet hade en tidsbegränsning på 2800 timmar, där varje projektmedlem hade 400 timmar avsatt till projektarbete. Chronos kan endast hantera trafikdata på formatet GTFS och GTFS Realtime då det var det som var tillgängligt. Rapporten kommer inte ingående behandla alternativa lösningar utöver de som implementerats.
2
Bakgrund
Projektet genomfördes av sju studenter som en del av kursen TDDD96 Kandidatprojekt i pro-gramvaruutveckling som gavs under vårterminen 2019 vid Linköpings universitet. Det utför-des på uppdrag åt Östgötatrafiken. Projektet skapautför-des utifrån Östgötatrafikens projektförslag Plattform för maskininlärning och visualisering av trafikdata. Följande utdrag är Östgötatrafikens beskrivning av projektets bakgrund:
"En av utmaningarna inom hubben är att öka framkomligheten i staden eftersom kollek-tivtrafiken är beroende av att deras fordon kan ta sig fram i stadsmiljön utan att fastna i köbildning. Östgötatrafiken är en av de ledande aktörerna vad gäller realtidsinhämtning och tillgängliggörande av trafikinformation. Varje sekund samlas positionen för samtli-ga fordon in och tillgängliggörs som öppna data. Tanken med detta studentprojekt är att skapa en plattform där dessa data kan utnyttjas bättre för maskininlärning och visualise-ring. Genom visualisering och automatiska metoder för att tidigt identifiera problem med trafikflöden och att hitta nya lösningar kan servicen för kollektivtrafiken förbättras och i förlängningen bidra till ökad attraktivitet, mindre bilåkning och ett mer hållbart resan-de." [40]
Utifrån projektbeskrivningen identifierade gruppen behovet av ett verktyg för att visuali-sera busstrafik. Verktyget skulle uppmärksamma problem i busstrafiken och på så sätt bidra till att busstrafiken kunde förbättras. Personbilar är idag bland de största miljöbovarna och enligt Naturvårdsverket motsvarar bilar hela 65% av kolodixutsläppen i trafiken [41]. I ge-nomsnitt åker endast en person i varje bil men ändå tar bilen upp lika mycket plats som om den hade varit fullsatt [42]. Detta är uppenbarligen en ineffektiv och miljömässigt ohållbar användning av vägar och bränsle. En förbättring av busstrafiken skulle kunna bidra till att fler väljer att åka buss. Genom användning av verktyget som projektgruppen erbjuder kan Östgötatrafikens busstrafik effektiviseras, vilket kan leda till att Östgötatrafiken förbättrar si-na trafikflöden. Förbättringen påverkar i sin tur hur attraktivt det är att åka buss och kan leda till ökat användande av bussar och minskat användande av personbilar.
2.1
Tidigare erfarenheter
Fem projektmedlemmar studerar sitt tredje år på programmet Civilingenjör i Datateknik och två studerar sitt tredje år på Civilingenjör i Mjukvaruteknik. Förutom de kurser studenterna
2.1. Tidigare erfarenheter
läst som en del av programmen, har några gruppmedlemmar erfarenhet som mjukvaruut-vecklare. Specifika erfarenheter som gruppmedlemmarna erhållit under utbildningarna listas nedan:
• Programmeringserfarenheter i programmeringsspråk som C++, Python och Java. • Teoretiska färdigheter inom bland annat matematisk analys, statistik och optimering. • Erfarenhet av projektarbete i grupper med ungefär sex personer.
Under de nästan tre år som studenterna har läst på deras respektive program har de utfört olika slags projektarbeten som givit viktiga erfarenheter inför kandidatarbetet. Upplevelser från tidigare projekt som gruppen kände var viktiga att ta lärdom av listas nedan.
• Veckomöten som schemalagts blev kortvariga och kändes onödiga.
• På grund av bristande kunskap lade projektmedlemmar onödigt mycket tid på att lösa problem gällande Git.
• Kod som projektmedlemmar skrivit var inte kommenterad, vilket gjorde den svår att förstå.
• En projektmedlem hade större kunskap än de andra projektmedlemmarna, vilket resul-terade i att de andra projektmedlemmarna inte lärde sig mycket.
3
Teori
I det här kapitlet beskrivs den teoretiska bakgrunden för projektet. Kapitlet täcker alla verk-tyg, programmeringspråk, bibliotek och arbetssätt som användes i projektet.
3.1
Dataformat
I detta kapitel beskrivs diverse dataformat som används i projektet. Dessa dataformat an-vänds för lagring av data och för statistiska visualiseringar av dessa data.
3.1.1
GeoTIFF
GeoTIFF står för Georeferenced Tagged Image File Format. Det är ett filformat för lagring av geospatiala data och är baserat på bildformatet TIFF. Formatet används för att spara raster-bilder, det vill säga pixelbaserade bilder. En fil kan ha flera olika lager, så kallade band, med data. [11]
3.1.2
GTFS
GTFS står för General Transit Feed Specification och kallas ibland GTFS Static för att skilja det från realtidsutökningen GTFS Realtime. GTFS är ett format som används för att definiera tid-tabeller i kollektivtrafiken och tillhörande geografisk data. En GTFS-feed är en zip-fil som består av flera .txt-filer skrivna på formatet CSV. I en GTFS-feed finns det vissa textfiler som måste finnas med: agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt och calendar.txt. Det finns också en del filer som inte krävs för att det ska fungera, men som innehåller informa-tion som kan vara av intresse. Exempelvis finns shapes.txt som innehåller data för att kunna rita ut vägar. [15]
3.1.3
GTFS Realtime
GTFS Realtime är en utökning till GTFS som bidrar med realtidsdata från kollektivtrafiken. En Realtime feed kan bestå av tre olika filer: TripUpdates, ServiceAlerts, och VehiclePosi-tions. Dessa filer är på ett format baserat på Protocol Buffers som är skapat av Google, likt XML. TripUpdates innehåller information om förseningar, inställd trafik, och ändrade rutter.
3.2. JavaScript
ServiceAlerts innehåller information om problem i trafiken, exempelvis om det är vägarbe-te eller om en hållplats invägarbe-te trafikeras. VehiclePositions behandlar data om fordons position, riktning och hastighet. GTFS Realtime kan exempelvis användas för att visa tid för ankomst och avresa. [16]
3.2
JavaScript
JavaScript är ett Just In Time-kompilerat språk baserat på standarden ECMAScript. JavaScript förekommer ofta i webbsidor och stöds av alla moderna webbläsare. JavaScript är dynamiskt, prototypbaserat, och stödjer flera programmeringsparadigm, som till exempel funktionell och objektorienterad programmering. JavaScript har flera bibliotek tillgängliga för att utö-ka dess funktionalitet, som exempelvis Leaflet (se 3.2.2 Leaflet) och React (se 3.2.8 React och Create React App). [43]
3.2.1
AngularJS
AngularJS är ett ramverk för front-end utveckling av dynamiska webbsidor i JavaScript. An-gularJS tillåter webbsidor att utvecklas enligt diverse designmönster. [2]
3.2.2
Leaflet
Leaflet är ett öppet JavaScript-bibliotek för karthantering. Leaflet har funktionalitet för visu-alisering av bland annat vektorer, markörer och bilder. Dessa kan vara klickbara för att visa poppuppfönster. Det finns också stöd för interaktivitet, i form av dragkontroller och zoom. Leaflet stöds av alla moderna webbläsare och har även stöd för visning på mobiltelefoner. Leaflet stödjer också hårdvaruaccelerering. [18]
3.2.3
Leaflet Heatmap
Leaflet Heat är en utökning till Leaflet. Utökningen gör det möjligt att skapa ett färgdiagram (heatmap). Detta diagram visas direkt på Leafletkartan med hjälp av punkter. Dessa punkter kan beroende på vilket värde de representerar ha olika färger. Punkterna kan även ha oli-ka storleoli-kar och suddighet, detta gör så att närliggande punkter blandas ihop om oli-kartan är mycket utzoomad. [44]
3.2.4
Leaflet.CanvasLayer.Field
Leaflet.CanvasLayer.Field är en utökning till Leaflet. Den gör det möjligt att visa skalärfält och vektorfält med färgskalor på en Leafletkarta. Det finns också möjlighet att visa animerade partiklar som följer vektorfältet. [45]
3.2.5
Mapbox GL
Mapbox är ett JavaScript-bibliotek vilket använder WebGL. Mapbox är i grunden en kartvi-sare och erbjuder tjänsten Mapbox Studio som ger kart-tiler. Mapbox tillåter 50 000 kartvis-ningar varje månad, helt gratis. [46]–[48]
3.2.6
Material UI
Material UI är ett JavaScript-bibliotek för React, se 3.2.8 React och Create React App, för att implementera Googles materialdesign i webbapplikationer [49].
3.3. Python
3.2.7
Node package manager
Node package manager, förkortat npm, är en hanterare för JavaScript som erbjuder en ter-minalklient och även ett mycket stort bibliotek med paket som projekt kan använda, likväl privata som allmänna [50].
3.2.8
React och Create React App
React är ett öppet JavaScript-bibliotek skapat av Facebook. Det är ett deklarativt, kompo-nentbaserat sätt att bygga avancerade interaktiva webbsidor. React utökar JavaScript med en syntax kallat JSX som låter element i React byggas snabbt. Dessa element renderas till DOM som visas i webbläsaren. Komponenter i React kan ha lokala tillstånd och livscykler. Detta tillåter interaktiva komponenter att implementeras. [27]
En toolchain kallad Create React App kan användas för att implementera majoriteten av gränssnittet. Denna toolchain, också utvecklad av Facebook, är deras rekommenderade sätt att skapa så kallade single-page applikationer med React. Create React App-applikationer utvecklas på en utvecklingsserver som kontrollerar kod och varnar om misstag. Webbsidan laddas automatiskt om efter att kod uppdaterats. När applikationer skapade i Create Re-act App är färdiga kan de byggas till självständiga sidor som kan serveras av ramverk som Flask. [3]
3.3
Python
Python är ett interpreterande högnivåspråk som har stöd för många olika saker, däribland funktionell programmering och objektorienterad programmering. Python är dynamiskt ty-pat, vilket innebär att variabeltyp inte behöver bestämmas när variabeln skapas. Python har många bibliotek tillgängliga, allt från TensorFlow, se 3.3.5 TensorFlow som används för ma-skininlärning till Flask, se 3.3.3 Flask, som används för att skapa servrar. Python fungerar på många plattformar, bland annat Mac, Windows, och många Unixversioner. [51]
3.3.1
Pytest
Pytest är ett ramverk som kan användas för att underlätta och automatisera testning av kod skriven i programmeringsspråket Python [52]. Pytest är inte inkluderat i Pythons standard-bibliotek utan det finns tillgängligt på PyPI [53].
3.3.2
Django
Django är ett webbramverk för Python. Det tillåter utvecklare att skapa säkra och skalbara webbaplikationer snabbt. Django har bland annat ett mallsystem som genererar HTML och funktioner för autentisering. Sidor som Mozilla, Instagram och Pinterest använder Django. [5]
3.3.3
Flask
Flask är ett webbramverk baserat på Werkzeug [54] och Jinja 2 [55]. Werkzeug är ett Web Server Gateway Interface (WSGI) bibliotek till Python. Jinja 2 är ett språk för mallar som genererar HTML. Flask tillåter snabb implementation av webbapplikationer. Flask har en utvecklingsserver som tillåter webbsidorna att snabbt laddas om vid kodändringar, vilket ökar utvecklingseffektiviteten. [9]
Flask-SQLAlchemy är en utökning på SQLAlchemy som tillåter hantering av SQL-databaser i Python. Flask-SQLAlchemy är anpassat för bättre stöd med Flask och passar där-för bättre än att direkt använda SQLAlchemy. [56]
3.4. SQL
Flask-CORS är en utökning till Flask som hanterar Cross Origin Resource Sharing (CORS) [57]. CORS är en mekansim som hanterar behörigheter för resursdelning mellan olika nätverksenheter, till exempel en klient och en server på olika webbadresser. [58]
3.3.4
Rasterio
Rasterio är ett Pythonbibliotek som abstraherar GDALs funktionaliteter och gör det enklare att användare dem. Rasterios mål är att vara ett enkelt och snabbt geospatialt dataabstrahe-ringsbibliotek [25].
3.3.5
TensorFlow
TensorFlow är ett open-source bibliotek utvecklat av Google som ger funktionalitet för sym-bolisk matematik och kan användas för maskininlärning. TensorFlow fungerar på i princip alla plattformar och på både CPUer och GPUer utan att anpassa koden. Google har till och med skapat egen hårdvara kallad Tensor Processing Unit (TPU) som är speciellt konstruerad för artificiella neuronnät [59]. TensorFlow har APIer för flera olika språk och garanterar sta-bila versioner i Python och C, men det finns också icke-garanterade versioner för C++, Go, Java, JavaScript och Swift. [35]
3.4
SQL
SQL står för Structured Query Language och är ett standardspråk för att hantera databaser och dess data. SQL har varit en standard sedan 1986 för American National Standards Institute (ANSI) respektive 1987 för International Organization for Standardization (ISO). [60]
3.4.1
SQLite
SQLite är ett litet och snabbt C-bibliotek som implementerar en SQL-databasmotor. SQLite har dåligt stöd för samtidighet då det endast tillåter en skrivare åt gången. [33]
3.4.2
PostgreSQL
PostgreSQL är ett öppet objektrelationsdatabashanteringssystem. Systemet är känt för att va-ra robust, pålitligt med bva-ra prestanda. PostgreSQL har bva-ra stöd för samtidighet. [22]
3.5
Verktyg
I detta kapitel beskrivs teori av diverse verktyg som användes under projektets gång. Detta inkluderar bland annat verktyg för dokumentskrivning, kommunikation och programme-ring.
3.5.1
draw.io
draw.io är ett verktyg för att skapa diagram. Programmet har färdiga komponenter som kan dras runt i ett fönster. Två komponenter kan kopplas samman med en av flera sorters kopp-lingar. Bland andra finns direkta linjekopplingar och hörnkopplingar där diagonala linjer för-bjuds. Programmet finns tillgängligt on-line och kan laddas ned för att användas off-line. [7]
3.5.2
Google Scholar
Google Scholar är en hemsida som erbjuder ett enkelt sätt att söka på vetenskaplig litteratur. Genom att söka på ord fås ett stort antal källor i form av bland annat artiklar, böcker,
uni-3.6. Git
versitet och professionella organisationer. Sökresultatet går att filtrera och sortera på bland annat utgivningsår. [61]
3.5.3
L
ATEX
LATEX är ett typsättningssystem designat för högkvalitativa tekniska och vetenskapliga texter
och är standarden inom publicering av vetenskapliga dokument. [62]
3.5.4
Overleaf
Overleaf är en webbaserad LATEX textredigerare. I Overleaf kan dokument redigeras av flera
användare samtidig, LATEX paket enkelt användas och dokumenthistorik finns tillgänglig och
gamla versioner kan återställas. [20]
3.5.5
Slack
Slack är ett kommunikationsverktyg som inte bara kan köras som applikation på en mobil-telefon och dator, utan också i webbläsare på många enheter. I Slack går det också att göra olika “kanaler” för att dela upp chattrummen i tydliga kategorier. Det går att bestämma vilka medlemmar som ska ha tillgång till olika chattrum, vilket gör att olika team i ett projekt kan ha egna chattrum. I chattrummen kan medlemmar sedan göra inlägg om vad som helst och dela olika filer. Dessa inlägg kan andra medlemmar sedan svara på genom att skapa en tråd på inlägget. Trådar gör att konversationen håller sig till det som inlägget handlade om och att det enkelt går att följa konversationen. [31]
3.5.6
Trello
Trello är ett webbverktyg för att hantera och organisera projekt. På Trello kan tavlor med listor skapas. I dessa listor kan det läggas till kort med till exempel aktiviteter som ska utföras. Korten kan ha färgmarkering som till exempel kan representera prioritet. Om flera användare delar på en tavla kan ett kort tilldelas till en specifik användare för att markera att det är denna användare som har ansvar över just det kortet. Med hjälp av alla dessa funktioner kan en projektgrupp använda Trello för att enkelt planera sitt projekt. [63]
3.5.7
Visual Studio Code
Visual Studio Code är en multiplattform kodredigerare som byggdes för att stödja både Linux, Windows och MacOS. Visual Studio Code har stöd för flera programmeringsspråk, Githantering, syntaxfärgläggning, kodkomplettering och många andra tilläggbara utökning-ar. [64]
3.6
Git
Git är ett distribuerat versionshanteringssystem skapat av Linus Torvalds år 2005. Git funge-rar på så sätt att det spafunge-rar tillståndet av filerna och varje gång nya filer läggs till eller ändras. Filer som inte ändrats sparas inte på nytt utan då skapar Git en länk till den föregående versionen. Nästan alla funktioner i Git är lokala och kräver inte en internetuppkoppling. Det-ta gör Git väldigt smidigt i situationer där internetuppkoppling saknas. Git gör det ganska svårt att ta bort data som lagts till i historiken, vilket gör att ändringar inte går miste under utvecklingsprocessen. [65]
3.7. Webbteknologier
3.6.1
Branch
En branch eller gren som det kallas på svenska är en separat ”tidslinje” av data. Koden delas upp i flera grenar utifrån en tidigare gren. Detta gör att samarbete mellan projektmedlemmar går smidigt. [65]
3.6.2
Feature branch
En feature branch är en branch som skapas från huvudbranchen med syfte att utveckla en specifik funktion i applikationen. Branchen får gärna ha ett bra och beskrivande namn, men detta beror på vilken standard man följer i projektet. När funktionen eller problemet sedan är fixat görs en merge mellan feature branchen och huvudbranchen. Till sist tas feature branchen bort och en ny branch skapas för nästa funktion. [66]
3.6.3
Merge
En merge är då två grenar med delvis eller helt olika data slås samman för att få allt på en och samma gren. Det kan hända att samma sak har ändrats i båda grenarna, då uppstår något som kallas Merge-konflikt. Det är då versionshanteringssystemet inte kan lösa konflikten och användaren själv måste ändra så att ingen konflikt finns kvar innan grenarna kan bli helt sammanslagna. [65]
3.6.4
Continuous Integration
Continuous Integration är en utvecklingsmetodik där målet är att utvecklarna ska pusha till Git-repot ofta. Vid varje push ska koden integreras och testas. För att försäkra sig om att koden genomgår tester vid varje push, kan en pipeline sättas upp som automatiskt kör igång testerna. [67]
3.7
Webbteknologier
I detta kapitel beskrivs teorin av diverse webbteknologier som används i systemet. Detta är främst teknologier och specifikationer för webbkommunikation.
3.7.1
REST API
REST API står för Representational State Transfer API. Det är en mjukvaruarkitektonisk stil för hantering av server-klient interaktioner. I en sådan arkitektur finns alla tillstånd på klien-ten. Genom att använda en Uniform Resource Identifier (URI) kan då klienten bland annat hämta, skapa och ta bort data på servern. [28]
3.7.2
Fetch
Fetch används för att hämta resurser (data) mellan nätverksenheter. Fetch används inom webbutveckling och är en standard som definierar förfrågningar, svar och den process som sammanbinder dessa [8]. Fetch stöds av alla moderna webbläsare och är det moderna sättet att hämta resurser över nätverk. Huvudkoncepten inom Fetch är ”Promise” och ”Response”. När fetchmetoden körs har den som argument sökvägen till resursen som ska hämtas. Denna metod returnerar ett Promise som resolveras till en Response. Denna Response har därefter flera metoder för att hantera dess innehåll. [68]
3.7.3
Websockets
Websockets är ett protokoll för tvåvägskommunikation mellan en klient som kör som ej be-trodd kod och en fjärrvärd. Protokollet använder handskakningar, data skickas i en sekvens
3.8. Övrig teori
av ”ramar” över Transmission Control Protocol (TCP). Protokollets syfte är att tillåta kom-munikation utan att behöva öppna flera HTTP anslutningar med värden. [38]
3.8
Övrig teori
I detta kapitel beskrivs diverse övrig teori. Detta inkluderar bland annat teori om modeller, mjukvarumetriker och API som används för att hämta realtidstafikdata.
3.8.1
High- respektive Low-fidelity-prototyp
En High-fidelity-prototyp är en interaktiv prototyp med den färdiga produktens funktionali-tet simulerad. En Low-fidelity-prototyp är en elementär prototyp som visar de grundläggan-de koncepten, ofta gjord på papper. [69]
3.8.2
Koppling och kohesion
Koppling är graden av beroenden mellan moduler i ett system. Kohesion eller sammanhåll-ning, beskriver hur starkt förhållandet mellan elementen i ett system är. En låg grad av kopp-ling och en hög grad av kohesion är önskvärt bland annat för att systemet blir lättare att förstå. [70]
3.8.3
Blockdiagram
Blockdiagram abstraherar exempelvis arkitekturen hos ett system, där block utgör kompo-nenter och linjer visar dataflöde mellan dessa kompokompo-nenter. [70]
3.8.4
Systemanatomi
En systemanatomi är ett diagram som delar upp en produkts egenskaper och funktioner i flera lager. Funktioner placeras i lämpligt lager och länkas sedan till funktioner som denna beror på. Med denna kan beroenden i systemet identifieras. [71]
3.8.5
Scrum
Scrum är ett ramverk för att utveckla, tillhandahålla samt underhålla produkter. Inom Sc-rum arbetar man i ScSc-rumteam som består av en produktägare, en scSc-rummästare och ett ut-vecklingsteam. Produktägaren ansvarar för att maximera värdet hos en produkt och hanterar därför önskemål om ändringar för produkten. Scrummästaren coachar teamet och ser till att teamet följer Scrummetodiken. Utvecklingsgruppen utvecklar produkten. [29]
Ett projekt som följer Scrum har en product-backlog vilket är en lista med önskemål om förändringar av produkten. Arbetet delas in i sprintar som är högst en månad lång. I början av en sprint planeras sprinten. En sprint-backlog används för att beskriva vad som ska im-plementeras under sprinten. Under sprintens gång hålls Daily Scrums, vilket är 15 minuter långa möten under vilka utvecklingsgruppen planerar arbetet 24 timmar fram, och produk-ten utvecklas. I slutet av sprinproduk-ten hålls en sprintgenomgång, under vilken sprinproduk-ten granskas. Därefter hålls en återblick under vilken utvecklingsgruppen, scrummästaren samt produktä-garen arbetar för att lära sig av den gångna sprinten. [29]
3.8.6
Geospatial Data Abstraction Library
Geospatial Data Abstraction Library, förkortat GDAL, är ett C/C++ bibliotek för hantering av raster- (pixelbaserade) och vektorgeospatiala dataformat. GDAL inkluderar funktioner för bearbetning och översättning mellan raster- och vektorformat och kan spara rasterdata som 155 olika filtyper, och vektordata som 95 olika filtyper. [10]
3.8. Övrig teori
3.8.7
Trafiklab
Trafiklab är en gemenskap för öppna trafikdata som tillhandahåller data och API:er för kol-lektivtrafiken i Sverige. Trafiklab började som ett samarbete mellan Samtrafiken, Storstock-holms Lokaltrafik och Viktoria ICT. Nu finns även fler aktörer med i samarbetet, vilket ger mer trafikdata. Trafiklab jobbar för att ge utvecklare de kollektivtrafikdata de behöver för att utveckla användbara applikationer. [36]
4
Metod
I detta kaptitel redovisas hur gruppen har gått tillväga för att utveckla produkten. Här be-skrivs upplägget av utvecklingen vilket inkluderar roller, gruppindelningar, kontakt med kunden, förstudie, dokumentation, verktyg för kommunikation och versionshantering.
4.1
Arbetsmetod
Nedan beskrivs hur projektgruppen arbetade tillsammans och vilka ansvarsområden respek-tive projektmedlem hade.
4.1.1
Gruppkontrakt
Utifrån projektgruppens tidigare erfarenheter listade i kapitel 2.1 Tidigare erfarenheter, skrevs i början av projektet ett gruppkontrakt för att definiera hur gruppen skulle arbeta tillsammans. Gruppkontraktet innehöll saker som att om någon i gruppen var sen till ett veckomöte skulle den gruppmedlemmen ta med fika till nästa gång.
4.1.2
Roller
Vid projektets uppstart definierades och tilldelades de roller som gruppmedlemmarna skulle ha. Rollerna hade olika ansvarsområden som förklaras nedan. Utöver arbetsuppgifter som följde av de individuella ansvarsområdena utförde samtliga projektmedlemmar gemensamt utvecklandet av produkten och dokumentskrivningen.
Teamledare - Oskar Magnusson
Projektets teamledare ledde och coachade utvecklingsgruppen genom projektet samt repre-senterade gruppen utåt. Denna person ansvarade också över projektplanen.
Analysansvarig - Anna Montelius
Analysansvarig agerade som mellanhand mellan kunden och utvecklingsgruppen. Denna person tog reda på kundens behov och såg till att dessa dokumenterades som krav.
4.1. Arbetsmetod
Arkitekt - Joakim Bergström
Arkitekten tog fram en systemarkitektur för produkten och gjorde övergripande teknikval. Utvecklingsledare - Felix Nodelijk
Utvecklingsledaren ansvarade för den detaljerade designen av produkten och fattade beslut om utvecklingsmiljö. Denna person ledde och fördelade utvecklingsarbetet vid behov. Testledare - Viktor Ivarsson
Testledaren ansvarade för att planera och utföra tester av systemet. Denna person verifierade systemet och beslutade därför om systemets status.
Kvalitetssamordnare och dokumentansvarig - Juan Basaez
Denna person hade två ansvarsområden, kvalitet och dokument. Detta inkluderade att skri-va en kskri-valitetsplan och se till att projektgruppen följde denna plan och höll en hög kskri-valitet på arbetet. Att ha ansvar för dokumentmallar och att leveranser skedde i tid ingick också i denna roll.
Konfigurationsansvarig - Johan Fisch
Denna person bestämde vilket verktyg för versionshantering som skulle användas, hur de skulle användas samt vilka delar av produkten som skulle versionshanteras.
4.1.3
Undergrupper
Gruppen delades in i två undergrupper som ansvarade för att utveckla produktens front-end respektive back-end. Dessa två grupper arbetade ofta i samma lokal, och det fanns därför många tillfällen för grupperna att hålla diskussioner kring vad som arbetades på.
Front-end
Front-end-gruppen bestod av tre gruppmedlemmar. Dessa var teamledaren, utvecklings-ledaren och kvalitetssamordnare. Denna grupp hade ansvaret att utveckla det grafiska gränssnittet och dess kontroller.
Back-end
Back-end-gruppen bestod av fyra gruppmedlemmar. Dessa var arkitekten, testledaren, ana-lysansvarig samt konfigurationsansvarig. Denna grupp hade ansvaret att utveckla servern, databashateringen och de funktioner som hanterade statistik. De hade även ansvaret att se till att den statistiska visualiseringen blev korrekt.
4.1.4
Utvecklingsmetodik
Produkten utvecklades enligt utvecklingsmetodiken Scrum (se avsnitt 3.8.5). Ett par saker från det ursprungliga formatet av metodiken har anpassats efter projektgruppens behov. Till skillnad från standardversionen och det officiella formatet på metoden har gruppen genom-fört en version av Daily Scrum som ägde rum vid varje veckomöte istället för dagligen. En annan skillnad i utvecklingsmetodiken var att samtliga gruppmedlemmar hade en specifik roll. Analysansvarig, som motsvarar Product Owner, och teamledaren, som motsvarar Scrum Master, var också en del av utvecklingsgruppen. Ytterligare en avvikelse från det ursprungli-ga formatet var att Sprint reviews inte genomfördes, och istället utvärderades och diskuterades produktens status på kundmöten.
Projektet delades in i tre iterationer som var tre veckor långa var. Varje iteration bestod av tre sprintar vilka var en vecka långa var. Istället för ett Sprint Retrospective-möte i slutet av varje sprint hölls istället motsvarande möten i slutet av varje iteration.
4.2. Grupp och projektidentitet
4.1.5
Kommunikation
Två stycken kommunikationsvägar valdes att användas: Facebook Messenger och Slack. I Messenger skedde majoriteten av kommunikationen, vilket inkluderade planering och ge-nerella diskussioner. I Slack skedde kommunikationen med kvalitetscoacherna (se 4.14.3 Kvalitetscoachning), och här vidarebefordrades e-post från handledaren.
4.2
Grupp och projektidentitet
I början av projektet satt gruppen tillsammans för att tänka fram en grupp och projektidenti-tet med tillhörande logotyper. Medlemmarna gav förslag på namn och logotyper, och utifrån dessa röstades favoriterna fram. Logotyperna skapades i vektorgrafikprogrammet Adobe Il-lustrator.
4.3
Kundkontakt
Möten hölls under projektets gång mellan kundens kontaktperson och projektgruppens ana-lysansvarig, samt teamledare. Under möten som hölls tidigt under projektet diskuterades krav och kundens vision. Efter projektets första iteration hölls ett möte där representanter för projektets behovsägare deltog. Då diskuterades deras syn på projektet. Under de komman-de iterationerna hölls en kontinuerlig kundkontakt genom e-postutbyte, där analysansvarig skickade en uppdatering om hur projektet gick och vad som implementerats i produkten. Kunden och behovsägaren svarade med att ge synpunkter på produkten.
4.4
Förstudie
Efter att ha fått bekräftelse på vilket kandidatarbete som skulle utföras fick gruppen den första beskrivningen av produkten som skulle utvecklas. För att förbereda gruppen i början av projektet genomfördes en förstudie. I denna ingick en undersökning för att ta reda på vilka kunskaper som skulle krävas för att utföra projektet. Sedan diskuterades samtliga pro-jektmedlemmars tidigare erfarenheter inom de områden projektet skulle behandla. Utifrån det bestämdes utbildningar gruppen skulle delta i.
Workshop i JavaScript och React
Som del av förstudien hölls en workshop i JavaScript och React, då gruppen inte bedömdes besitta den kunskap som krävdes för att genomföra projektet. Workshopen hölls under fem timmar av projektgruppens utvecklingsledare. Alla projektmedlemmar deltog med undan-tag för analysansvarig.
Föreläsningar om Git
Förstudien innebar även att tre projektmedlemmar, konfigurationsansvarig, arkitekt, samt analysansvarig, deltog på en två timmar lång föreläsning om Git, eftersom det skulle an-vändas under projektet. Under föreläsningen förklarades hur Git är uppbyggt från grunden. Konfigurationsansvarig deltog på ytterligare en föreläsning under vilken olika tips om Git gavs.
Föreläsning om OpenUP Architecture Notebook
Under förstudien deltog arkitekten i en föreläsning om OpenUP Architecture Notebook. Fö-reläsningen var två timmar lång och gick igenom hur arkitekturdokument kan skrivas, vilket inkluderar vad som kan vara intressant att ha med och hur dokumentets upplägg kan vara. Denna föreläsning lade grunden för upplägget i arkitekturdokumentet som sedan skrevs.
4.5. Dokument
4.5
Dokument
Ett antal dokument påbörjades under förstudien och uppdaterades under projektets gång. Dessa skapades för att ge alla medlemmar en gemensam bild över produkten och arbetspro-cessen. Dokumenten skrevs i Overleaf och redogörs för nedan.
Projektplan
En plan över hur utvecklingen av produkten skulle gå till. Den innehöll bland annat en beskrivning av produkten, hur projektgruppen skulle arbeta, vilka aktiviteter som skulle utföras under projektet, milstolpar för projektet, en samling potentiella risker tillsammans med en riskplan, samt en fasplan som beskrev vad som skulle utföras under vilka faser i projektet.
Kravspecifikation
Ett dokument med beställarens och projektgruppens önskemål och krav kring funktionalitet, kvalitet och design som ges olika prioritet.
Arkitekturdokument
Ett dokument där produktens arkitektur presenterades och beskrevs i detalj. Här motivera-des också arkitekturbeslut.
Kvalitetsplan
Kvalitetsplanen skapades för att kunna definiera kvalitetsprocesserna som behövde applice-ras under projektet. Att definiera kvalitetsarbetet, samt de standarder som måste följas under projektet bidrog till att arbetet, utvecklingen och slutprodukten höll hög kvalitet.
Testplan
En plan över hur tester skulle utföras på produkten. Innehöll beskrivningar av olika typer av tester som skulle utföras under projektet, samt testfall för projektets alla iterationer.
Testrapport
En rapport där resultaten av de tester som genomfördes under en viss iteration redogjordes.
4.6
Google Drive-mapp
En gemensam Google Drive-mapp skapades för projektgruppen för att dela vissa dokument, som till exempel presentationer, tidsrapporteringsdokument och mötesprotokoll. Annat som delades var databaser och diagram av användbara modeller.
4.7
Trellotavlor
Inför den andra iterationen infördes användandet av Trellotavlor. En Trellotavla skapades för respektive undergrupp. Nedan förklaras hur de olika undergrupperna specifikt arbetade med Trello.
Front-end
Utifrån aktiviteterna definierade i projektplanen som handlade om front-end skapades en lista som motsvarade en generell backlog. Tre andra listor skapades. Dessa skulle innehålla aktiviteter som utfördes just nu, aktiviteter som var genomförda, samt buggar som uppda-gats. När en aktivitet i backloggen skulle utföras flyttades denna från backloggen till listan med pågående aktiviteter, och när den var genomförd flyttades den till listan med
genom-4.8. Versionhantering
förda aktiviteter. Back-end
En lista skapades för att representera en generell backlog vilken tilldelades aktiviteter rela-terade till implementationen av produktens back-end från projektplanen. Gruppen skapade också en backlog för varje iteration. Ytterligare tre listor skapades och representerade, på samma sätt som för front-end-gruppen, pågående aktiviteter, genomförda aktiviteter samt buggar. Inför varje iteration bröts aktiviteterna i den generella backlogen ned i mindre akti-viteter och tilldelades till den iterationens backlog för att tydliggöra vad som skulle utföras under just den tidsperioden. Precis som för front-end-gruppen flyttades aktiviteter mellan tavlor för att indikera om aktiviteten skulle utföras, utfördes just nu eller hade utförts. Akti-viteterna tilldelades en etikett med någon av färgerna grön, gul och röd, där röd betydde att det var av högsta prioritet att genomföra aktiviteten, och grön betydde att det var av lägsta.
4.8
Versionhantering
Ett Git-projekt för respektive undergrupp skapades för att versionshantera alla delar av pro-dukten. Varje gång något nytt skulle implementeras skapades en ny gren utifrån en gren kallad dev. Båda grupperna hade som regel att sammanfoga alla grenar varje fredag. Detta innebar att det som fanns på dev-grenen sammanfogades med den nyskapade grenen, på den sistnämna grenen. Slutligen sammanfogades denna gren med dev-grenen.
4.9
Modeller
I detta kapitel beskrivs de modeller och diagram som skapades för att beskriva hur produk-ten skulle se ut.
Systemanatomi
I början av projektet skulle en systemanatomi skapas som en del av en obligatorisk del i kur-sen. Denna process gick ut på att gruppen tillsammans skulle, med hjälp av brainstorming, hitta på det funktioner som slutprodukten skulle ”sälja” till användarna. Dessa funktioner skulle sedan kopplas till underliggande lager som innehöll funktioner som krävdes för att realisera de ”säljande” funktionerna (se kapitel 3.8.4 Systemanatomi). Systemanatomin ritades först upp på en whiteboardtavla och återskapades sedan i programmet draw.io.
Blockdiagram
Genom att utgå från en specifik arkitektur och en systemanatomi kunde blockdiagram över arkitekturen skapas. Funktioner i systemanatomin drogs ut till block och kopplades samman enligt dess beroenden. Dessa block kunde sedan placeras enligt den arkitektur som skulle implementeras. Funktioner som hörde ihop kunde då abstraheras ut i större block. Till ex-empel kunde serverfunktioner placeras i ett stort serverblock. Blockdiagrammen skapades i programmet Draw.io.
Prototyper
För att bekräfta att både design och utveckling av produkten uppfyllde kundens önskemål under projektets gång bestämde gruppen sig för att använda High-fidelity-prototyper. Pro-totyperna skapades i Adobe XD och skulle visas vid slutet av iterationerna för att utifrån re-sultatet planera kommande iteration samt ändringar och förbättringar att implementera. En första prototyp skapades i syfte att bekräfta att gruppens idé stämde med kundens önskemål. Prototypen visades för kunden och behovsägaren, vilka gav återkoppling på prototypen. En andra prototyp skapades med utgångspunkt i kritiken på den första prototypen.
4.10. Utvecklingsmiljö, bibliotek och ramverk
4.10
Utvecklingsmiljö, bibliotek och ramverk
Utifrån den framtagna systemanatomin togs beslut angående hur systemet skulle implemen-teras. Programmeringsspråk, utvecklingsmiljöer, bibliotek och ramverk som skulle användas bestämdes.
Front-end
Front-ends funktionalitet implementerades i JavaScript med hjälp av biblioteket React, vilket användes för utvecklingen av produktens användargränssnitt. Front-end utvecklades i Visual Studio Code. Visual Studio Codes utökning Prettier användes för att automatiskt formatera JavaScript-koden när en kodfil sparats.
Följande JavaScript-bibliotek användes i front-end: 1. React 2. D3 3. Chroma.js 4. Leaflet 5. Leaflet.heat 6. Leaflet.CanvasLayer.Field 7. MapboxGL Back-end
Produktens back-end utvecklades i Python. Back-end utvecklades i Visual Studio Code. Vi-sual Studio Code formaterade Pythonkod automatiskt enligt Python stilguiden PEP8. Data-baserna skapades i SQLite.
Följande Pythonbibliotek användes i back-end: 1. Python 2. Numpy 3. Flask 4. Flask-CORS 5. Flask-SQLAlchemy 6. GTFSrDB 7. GTFSDB
8. Rasterio (använder C++ biblioteket GDAL) 9. Protocol Buffers
4.10.1
MapboxGL and Leaflet
Gruppen var i början oeniga kring vilket kartbibliotek som skulle användas; således använ-des både MapboxGL och Leaflet för att fånga erfarenheter om båda verktygen, och en kort litteraturstudie kring båda verktygen för att ta fram om det fanns något som triumferade det andra verktyget.
4.11. Databaserna
4.11
Databaserna
I början av projektet startades en Amazon Web Services server. På servern kördes en mo-difierad version av GTFSrDB [72] som automatisk hämtade realtidstrafikdata från Trafiklab. Denna server användes för att bygga upp en databas med historiska realtidstrafikdata. De data som hämtades kommer från GTFS realtime-dataströmmen ”VehiclePositions.pb” och ”TripUpdates.pb” som Trafiklab tillhandahåller. VehiclePositions uppdaterades varje sekund medan TripUpdates uppdaterades var 15:e sekund. Statiska trafikdata i CSV-format hämta-des från Trafiklab. Med hämta-dessa filer skapahämta-des en SQLite-databas.
4.12
Metod för att fånga erfarenheter
Ett antal metoder för att ta vara på och dela med sig av erfarenheter inom gruppen genom-fördes under projektet. Dessa redogörs för nedan.
4.12.1
Möten
Under de veckoliga mötena fanns tillfällen för gruppen att ta upp erfarenheter. Eventuella problem diskuterades och lösningar togs fram.
4.12.2
Drive-dokument och Slack
Vissa källor med användbar information sparades i delade Drive-dokument i den delade Drive-mappen för att alla i gruppen enkelt skulle kunna ta del av dem. Andra källor skicka-des i gruppens Slack-kanal.
4.12.3
Iterationsretrospektiv
Efter varje iteration hölls ett möte där en utvärdering genomfördes, vilket i klassisk Scrum liknar ett sprintretrospektiv. På mötet togs åsikter och erhållna erfarenheter från iterationen upp och diskuterades.
4.12.4
Samarbete
Gemensamma arbetstider schemalades, där så många som möjligt av projektmedlemmarna närvarat för att arbeta i samma lokal. Detta för att uppmuntra medlemmarna att ställa frågor till gruppen och på så sätt möjliggöra diskussioner.
4.13
Programvarutestning
För att planera testning av programvara skrevs en testplan. Testplanen beskrev hur projekt-gruppen definierade olika testnivåer, vem som var ansvarig för de olika testnivåerna och hur de skulle utvärderas. Den innehöll även de testfall som var planerade att utföras under varje iteration. För att dokumentera genomförda tester samt testernas utfall skrevs en testrapport i slutet av varje iteration.
En Continuous Integration pipeline sattes upp genom GitLab. Vid varje push till Git-repot kördes alla enhets- och integrationstester som definierats i projektets testmapp. Detta utför-des av en GitLab Runner [73] som gruppen satt upp på den gemensamma Amazon Web Service-servern. Det var endast Pythonkoden i projektets back-end som testades av pipeli-nen, och detta skedde med hjälp av PyTest.
Under sista iterationen av projektet användes testningsapproachen utforskande test-ning [74]. Gruppen avsatte en tidsperiod på 60 minuter per projektmedlem till utforskande testning. Under denna tidsperiod hade gruppen fria händer att utforska programvaran med
4.14. Systemets kvalitetskrav
målet att hitta så många buggar som möjligt. För att dokumentera buggar skapades ett do-kument som innehöll de buggar som var relaterade till front-end och på motsvarande sätt skapades ett dokument för back-end. Buggarna beskrevs med en kort rubrik, samt tillväga-gångssätt för att återskapa buggen.
4.14
Systemets kvalitetskrav
Utifrån kravspecifikationen och med hjälp av standarden ISO/IEC 25010 [75], bestämdes två kvalitetsfaktorer att fokusera på under utvecklingen. Dessa var användbarhet och underhåll-barhet.
4.14.1
Användbarhet
Användbarhet är ett mått på hur effektivt och tillfredställande en användare kan uppnå sitt mål med systemet. [76]
För att mäta systemets användbarhet använde sig gruppen av en SUS-enkät som är till för att mäta hur pass användarvänlig ett användargränssnitt är [77]. En representant för pro-jektets behovsägare fyllde i en SUS-enkät efter ett test av användargränssnittet, där represen-tanten fick två uppdrag att genomföra på en prototyp av produkten (se figur M.1 i bilaga M SUS-enkät). Ett resultat av enkäten beräknades (se figur M.2 i bilaga M SUS-enkät).
4.14.2
Underhållbarhet
Underhållbarhet är ett mått på hur enkelt ett system är att underhålla, det vill säga hur enkelt systemet kan modifieras och förbättras. [76]
För att få ett underhållbart system byggdes det enligt en modulär design. Dessutom följ-des diverse standarder inom verktyg och programmeringsspråk för att hålla en konsekvent struktur som bidrar till underhållbarhet:
1. Python - PEP 8
2. JavaScript - Googles JavaScript standard 3. HTML/CSS - Google HTML/CSS Style Guide
4.14.3
Kvalitetscoachning
En av resurserna gruppen hade som stöd under projektet var kvalitetscoachning. Kvalitets-coachgruppen bestod av fem masterstudenter, med inriktning i storskalig mjukvaruutveck-ling, som skulle hjälpa att både identifiera och mäta kvalitetsfaktorer i projektet. Kommuni-kation mellan coacherna och gruppen, representerad av kvalitetssamordnare och testledare, skede via möten och Slack.
5
Resultat
I detta kapitel presenteras resultatet av förberedelserna, hur systemet ser ut, samt hur de uppsatta kvalitetskraven behandlas. Här tas även upp de erfarenheter gruppen samlat på sig under projektet.
5.1
Förstudie
Resultatet av förstudien var början på ett arkitekturdokument, en testplan, en projektplan, en kravspecifikation, en kvalitetsplan, och en systemanatomi. Gruppmedlemmar som inte hade förkunskaper i JavaScript och React fick introduktion till dessa genom att delta i works-hopen. De medlemmar som gick på föreläsningar om Git respektive OpenUP Architecture Notebook erhöll nyttig kunskap inför projektet. Under förestudie bestämdes också grupp-namnet NainCorpoch produktgrupp-namnet Chronos, samt deras respektive logotyper. I bilaga J finns logotyperna för gruppen och projektet.
5.2
Modeller
En systemanatomi, ett blockdiagram och två prototyper skapades under projektet, i detta kapitel presenteras resultaten av dessa.
5.2.1
Systemanatomi
Systemanatomin som skapades i början av projektet visas i figur K.1 i bilaga K Systemanatomi. Denna var grundläggande och inkluderade de funktioner som systemet troddes behöva. Sys-temanatomin delades upp i lager. Från topp till botten innehöll den tjänster, UI, serverfunk-tioner, kommunikation och hårdvara. I tjänster-lagret fanns det som produkten skulle ”sälja” till kunden, alltså det som efterfrågades av dem. Detta var maskininlärning, visualisering av data och analys av busstur. I UI-lagret fanns klientens komponenter. Dessa var grafik-komponenter som kartan och kontroller för gränssnittet. I lagret för serverfunktioner fanns hantering av databaser och statistik. I kommunikations-lagret specificerades TCP/IP som kommunikationsprotokoll mellan systemets hårdvara, servern och klienten.
5.2. Modeller
5.2.2
Blockdiagram
Det första blockdiagrammet som skapades över arkitekturen beskrev den grundläggande arkitekturen hos systemet (se figur 5.3). Det andra blockdiagrammet som skapades var en utökad version av det första som visade mer ingående var specifika funktioner skulle imple-menteras i systemet, se figur L.1.
5.2.3
Prototyper
Två prototyper togs fram. Den första gjordes kort efter förstudien och den andra efter ett möte med kunden hållits.
Vid skapandet av den första prototypen utgick projektgruppen ifrån att den skulle visa trafikflöden, statistik i form av grafer, samt en sannolikhetsuppskattning av att en buss kom-mer för sent. I figur 5.1 visas den första prototypen. Ytterligare figurer på prototyp 1 finns i bilaga H Prototyp 1.
Figur 5.1: Bilden visar gränssnittet för den första prototypen då användaren har valt att vi-sualisera busslinjen 3 från Linköping. 1: Menyn (se figur H.1). 2: Busslinje 3:s ruta, bussars position i realtid (röda oval med numret 3) samt de inblandade hållaplatserna. 3: Ruta som innehåller en lista av alla valda busslinjer vilka kan stängas av genom att trycka på krysset. 4: Ruta där användaren får välja en specifik hållplats, dag och tidsintervall för att se försenings-information.
Den andra prototypen presenterade en ny design och struktur. Informationen som visua-liserades var annorlunda än den från prototyp 1, trafikflödet visades i formen av ett färgdia-gram och menyn innehöll nya knappar.
I figur 5.2 presenteras slutversionen av prototyp 2. Ytterligare figurer på prototyp 2 finns i bilaga I Prototyp 2.
5.3. Systemets arkitektur
Figur 5.2: Bilden visar hur menyn såg ut vid den senaste versionen av prototypen. 1: Knapp för att välja mellan Linköping och Norrköping (Linköping är vald). 2: Knapp för att aktivera trafikflödet. 3: Knapp för att expandera en lista med alla busslinjer som tillhör den valda sta-den. En eller flera busslinjer får väljas (se figur I.5). 4: Knapp för att expandera en lista med alla hållplatser som tillhör den valda staden. En hållplats får väljas för att visualisera informa-tion angående den (rutan med hållplats informainforma-tionen är samma som den i figur I.2). 5: Filter för att visualisera hållplatserna med valda procent förseningar (80% på bilden). Specifik dag, tidsintervall och procent kan väljas.
5.3
Systemets arkitektur
Systemet byggdes enligt en tre-skiktad klient-server-arkitektur. Det består av en lokal server och ett webbaserat användargränssnitt som utgör klienten. Dessa skikt är presentation, data och logik. I presentationsskiktet finns klienten. I logikskiktet finns majoriteten av systemets uträkningar, se figur 5.3 för snabb översyn av arkitekturen. Se figur L.1 i bilaga L Blockdiagram för en fullständig bild av arkitekturen.
Logic Database Manager Server
GTFS Realtime Updater
Architecture Block Diagram
Client Computer Trafiklab GTFS Realtime Browser Server handler Logic Databases Statistics Handler Three-Tier architecture Logic Map API Legend Presentation
layer Business layer Database layer Data
flow External service
GUI
5.4. Server- och databasmodulen
Systemet har två distinkta moduler som har varsin uppgift. Dessa moduler är: server- och databasmodulen, och klientmodulen.
5.4
Server- och databasmodulen
Server- och databasmodulen är en server med tillhörande databashantering. Denna utgör systemets huvudkomponent och dess back-end. Denna server hanterar majoriteten av sy-stemets beräkningar, kommunikationen med användaren och operationer på databasen. Till exempel serverar den trafikdata till klienten för visualisering. Denna server kan antingen köras lokalt eller på en värddator.
Databashanteringen sker genom ett gränssnitt från servern till databasen. Det är med det-ta gränssnitt som servern till exempel hämdet-tar från och modifierar dadet-tabasen.
Servern implementerades i Python med biblioteket Flask. Med Flask kan andra nätverk-senheter ansluta sig till servern. Servern har funktioner för att skicka trafikdata till klienten för visualisering. Dessa funktioner följer ett REST API. Servern har även funktioner för ska-pandet av bilder av trafikdata som sedan kan visualiseras i klienten. Bilderna som kan skapas från trafikdata är medelvärdet, maximum, minimum och medianen av bussfarter.
5.4.1
Generering av bilder
Funktionen som genererar bilderna är skapad med Rasterio (se 3.3.4 Rasterio) som använder GDAL (se 3.8.6 Geospatial Data Abstraction Library). Med funktionen kan en yta på en kar-ta väljas ut och undersökas under en tidsperiod. Rekkar-tangeln delas sedan in i ett rutnät som då utgör en tom rasterbild. Fyra sådana bilder skapas. Utifrån en databas med lagrade real-tidstrafikdata fylls bildernas pixlar med trafikdata i form av medelvärdet och minimum (se figurer 5.4a och 5.4b), samt maximum och medianen av bussfarter (se figurer 5.5a och 5.5b).
(a) Medelvärdet av bussfarten. (b) Minimivärdet av bussfarten.
