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 produktnamnet 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 informationen ä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