OSM-data (se avsnitt 3.4.11) i en lokal PostgreSQL-databas. [56] Sedan används en apache web server för att skicka tiles till klienter. [57] Tilesen renderas med hjälp av mapnik. [58]
5.1.6
Värde för kunden
Projektgruppens huvudsakliga mål med arbetet var att ta fram en produkt som är värde- full för kunden. Här följer en beskrivning av vad som anses vara värde för kunden och hur projektgruppen gått tillväga för att säkerställa att detta uppnåddes.
5.1.6.1 Användarvänlighet
Då kundens vision om systemet i huvudsak var att användaren skulle slippa oro och svårig- heter med styrning av drönare föll det sig naturligt att användarvänlighet var något som kun- den värdesatte. Detta hade projektgruppen i åtanke genom hela arbetet. Genom användartest med extern part och kontinuerlig kontakt med kunden kunde projektgruppen säkerställa att design av användargränssnitt och relaterad funktionalitet var lätt att förstå och använda.
5.1.6.2 Underhåll
Kunden hade även inställningen att produkten skulle kunna vidareutvecklas och integreras i befintliga system hos RISE. Av denna anledning såg projektgruppen det som värdefullt att säkerställa att kod och dokumentation höll en god nivå för att underlätta underhåll och vi- dareutveckling. Genom granskningsprocesser och kontinuerlig dokumentation har gruppen genomfört detta och kunnat lämna ifrån sig material till kunden som håller önskad standard. Dessutom har gruppen sammanställt en användarmanual där användning, generell förkla- ring av kod och förslag på vidareutveckling ingår.
5.1.6.3 Användningsområdets påverkan på utvecklingsarbetet
Systemet är utformat för att vara enkelt att navigera i och lätt att förstå. För att uppnå detta användes Material Design som är känt för sina stilrena drag (se avsnitt 3.4.4).
För att fastställa om användargränssnittet var lättanvänt skapades först en prototyp. Den- na prototyp fick granskas av en medlem ur räddningstjänsten. Under granskningen fick test- personen berätta sina känslor och tankar, vilka antecknades. Då testpersonen var från syste- mets tänkta målgrupp kunde anteckningarna användas för att besluta hur systemet skulle se ut. Detta lade grunden för användargränssnittet.
Dessa åsikter hjälpte gruppen att ta designbeslut senare under implementationen. För att systemet ska fungera till den tänkta användaren har onödig funktionalitet valts bort och fokus har legat på att all funktionalitet ska vara självförklarande. För att systemet ska kunna användas under kritiska förhållanden var det viktigt att design av knappar, text och ikoner var tydlig så att användaren enkelt kan navigera i systemet.
5.2
Utvärdering av hur väl produkten uppfyller kraven
I detta avsnitt utvärderas produkten utifrån ett urval av centrala krav från kravspecifikatio- nen och kvalitetskraven i kvalitetsplanen.
5.2.1
Kravspecifikation
Tabell 5.1 beskriver hur många av de kraven i projektets kravspecifikation som uppfylls av den levererade produkten.
5.2. Utvärdering av hur väl produkten uppfyller kraven
Tabell 5.1: Sammanställning av kravspecifikationens krav.
Beskrivning Prioritet 1 Prioritet 2 Prioritet 3 Totalt
Uppfyllda 30 3 0 32
Ouppfyllda 0 2 1 4
Totalt 30 5 1 36
Andel uppfyllda 100 % 60 % 0 % 89 %
Ett av kraven med prioritet 2 beskriver hur flygfoton tagna på samma plats vid olika höjd ska hanteras. Enligt kravet ska användaren genom inställningar kunna påverka denna hantering. Det färdigställda systemet visar samtliga bilder som överlappar med den aktuella vyn och inte täcks av en senare tagen bild, och den senast tagna bilden placeras alltid överst. Användaren har dock ingen möjlighet att anpassa valet av bilder. Detta krav kan därför inte anses vara uppfyllt.
Det andra ouppfyllda kravet med prioritet 2 är att användargränssnittets karta ska initie- ras baserat på användarens nuvarande position. Detta har inte implementerats, utan kartan startar alltid på samma fördefinierade plats.
Det sista kravet, med prioritet 3, som inte uppfylls är att systemet ska ha möjlighet att visa en tidslinje över ett händelseförlopp. I detta läge ska en användare kunna gå tillbaka och återskapa omständigheterna vid ett tidigare skede, och exempelvis kunna se vilka bilder som då fanns tillgängliga. Denna funktion skulle ge användaren möjlighet att se hur en position i en vy utvecklats över tid och då kunna förutse vad som skulle hända härnäst och fatta beslut därefter. Detta skulle exempelvis vara användbart för en räddningsledare som vill få en över- blick över hur en brand spritt sig i ett område. Läget skulle även kunna användas i efterhand i forskningssyfte för att analysera bränders spridning. Projektgruppen implementerade inte något sådant läge.
5.2.2
Kvalitetskrav
De krav som ställs på produktens kvalitet fokuserade på underhållbarhet, då produkten ska vidareutvecklas av kunden. Kraven lyder som följer:
1. Alla systemets publika funktioner är kommenterade med docstring.
2. 75 % av alla issues skapade på Gitlab undersöks eller tilldelas inom en vecka från det att de skapas. Detta inkluderar utvärdering av vad som behöver göras och uppgiftens prioritet, alternativt att tilldela detta arbete till någon projektmedlem.
3. 75 % av alla commit-meddelanden till Git följer standarden som beskrivs i utvecklings- planen (se avsnitt 4.2).
Att kraven skulle uppnås säkerställdes genom kontinuerlig granskning och kontroll. Krav 1 kontrollerades under kodgranskingstillfällen som utfördes under projektets gång. En slut- giltig kontroll innan leverans säkerställde att kravet uppnåddes. Ansvaret för att krav 2 upp- fylldes låg på projektets utvecklingsledare. SCRUM-arbetet underlättade för projektgruppen att hålla ordning på alla issues som skapades under arbetsveckorna. Vid projektets slut gjor- des en kontroll av alla issues och det kunde då konstateras att kravet uppfylldes av 98.8 % av alla issues i front-end och 94.1 % av alla issues i back-end. Krav 3 kontrollerades av konfigura- tionsansvarig, som genom en utvecklingsplan definierade hur ett commit-meddelande skulle se ut. Vid eventuell avvikelse från standard notifierades gruppen om detta för att säkerställa att vidare arbete följde planen. Vid projektets slut kontrollerades detta och täckningsgraden var 99 % för både back-end och för front-end.