Alternativa designbeslut

Följande är ett antal alternativa designbeslut som diskuterades under projektets gång.

6.1.3.1 Ändringar under arbetets gång

Under projekttiden togs två större designbeslut till följd av problem som stöttes på. Det förs- ta var att ZeroMQ, det kommunikationsramverk projektgruppen först beslutade om skulle användas för kommunikation mellan front- och back-end, visade sig inte tillhandahålla den funktionalitet som behövdes i front-end. Detta eftersom ZeroMQ-biblioteket var skrivet för Node.js server och kunde inte användas i en webbläsare. Beslutet togs då att istället använda Socket.IO, något som diskuteras vidare nedan.

6.1. Utvärdering av resultat

Det andra beslutet som togs var att köra en egen tile server. Detta gav större kontroll över kartbilderna och möjliggjorde för back-end att anpassa flygfotona till kartan. Mer om detta i avsnitt 6.1.3.5.

6.1.3.2 Möjliga förbättringar

Under utvecklingen av front-end upptäcktes det mot slutet av projektet att JavaScripts svaga typning medförde extra arbete vid hantering av objekt. Detta hade kunnat lösas med hjälp av att implementera TypeScript. För vidare information, se appendix A.

6.1.3.3 Front-end

Ursprungligen gjordes valet att implementera systemet som en applikation med bara en si- da/sökväg, även kallat single page application, men i utvecklingsfasen gjordes sedan valet att lägga till en sida för uppstartssekvensen. Detta beslut togs för att det tycktes enklare att låta bytet mellan uppstarts- och huvudläge skötas av React Router. Systemet laddade då automa- tiskt in nya komponenter då sökvägen ändrades, utan att specialimplementerade system för detta behövde skapas. Produkten är i huvudsak fortfarande bara en single page application.

Möjliga alternativ för designen på front-end kunde exempelvis vara att implementera systemet som en applikation som körs hos användaren istället för en webbsida. Vad detta medför är ett krav på användaren att ha systemet installerat på sin hårdvara och att denna process behöver genomgås för varje ny enhet. En positiv konsekvens av en sådan design hade varit att det möjliggör en mer anpassning av vad som ingår i applikationen då stöd för och kompatibilitet med webbläsare ej behöver tas hänsyn till.

Ett annat alternativ är att sköta lagring lokalt hos användaren istället för på en server. Det- ta medför större krav på användarens hårdvara men sänker kraven på serverns tillgänglighet och kapacitet.

6.1.3.4 Socket.IO

För att kommunicera mellan front-end och back-end valdes Socket.IO istället för ZeroMQ, biblioteket som ursprungligen var planerat att användas. Ett alternativ till Socket.IO ha- de varit att hantera kommunikationen mellan front-end och back-end med hjälp av HTTP- förfrågningar från front-end till back-end. Hos back-end implementerades en webbserver med hjälp av Flask (se avsnitt 3.4.9. Flask stödjer som standard HTTP-förfrågningar och för att använda Socket.IO inkluderades biblioteket Flask-Socket.IO som gav Flask möjligheten att kommunicera med hjälp av Socket.IO. [44]

HTTP-förfrågningar används i nuläget hos back-end när front-end vill få en bild från back-end. Att låta all kommunikation ske via HTTP-förfrågningar hade dock inneburit att back-end inte skulle kunna meddela nya uppdateringar till front-end vid behov. Istället skulle front-end behöva regelbundet göra HTTP-förfrågningar till back-end för att kolla om nya uppdateringar finns. Detta skulle i sin tur innebära en flaskhals hos servern. Att använda Socket.IO eller HTTP-förfrågningar är ett designval som kan diskuteras.

Fördelen med Socket.IO är alltså att back-end lätt kan skicka meddelande till front-end och anslutna klienter. Ytterligare en fördel är att Socket.IO också kan uppgraderas till att använda WebSockets istället för long-polling för kommunikationen om detta implementeras i back-end (se avsnitt 6.1.2.2)

6.1.3.5 Överlagring av bilder i tileserver

Ett designbeslut som diskuterades mycket under projektets utveckling var hur flygfoton skul- le föras över till front-end. Lösningen som valdes beskrivs i avsnitt 5.1.2.2 och 5.1.3.2. Ett alter- nativ till detta vore att överlagra flygfoton på kartan direkt när den genereras av tileservern (se avsnitt 3.4.10). Då skulle bilderna följa med när front-end ber tileservern om kartbilder, och ingen separat bildöverföring eller bildhantering skulle behövas. Projektgruppen valde

6.2. Diskussion av erfarenheter

dock att inte använda denna metod, eftersom det skulle krävas ändringar av tileserverns interna funktioner på ett sätt projektgruppen inte hade medel för att åstadkomma.

6.2

Diskussion av erfarenheter

I detta avsnitt diskuterar vi några av de erfarenheter projektgruppen har från arbetet med projektet.

6.2.1

Kundkontakten

Den öppna dialogen med kunden gjorde att designbeslut kunde tas i vetskap om att de upp- fyllde kundens vision. Detta kan ha lett till att gruppen ibland lät kunden ta beslut då det ansågs effektivare, vilket kan ha gjort att lösningar som gruppen annars hade producerat uteblev och kan ha bidragit till en sämre slutprodukt trots att kunden var nöjd. Detta då det kan vara svårt för kunden att veta vilka implementationer som fungerar bäst.

Kontinuerlig kontakt med kunden tillät gruppen att specificera ingående funktionalitet under arbetets gång. Detta innebar att den ursprungliga kravspecifikationen skrevs med tolk- ningsutrymme. När kravspecifikationen skulle tolkas senare under projektet kunde de delar som var öppna för tolkning leda till att gruppen inte visste hur de skulle implementera dessa. Detta ledde till missförstånd då gruppmedlemmar trodde att kraven betydde annat än vad de gjorde.

6.2.2

Förberedelsearbetet

Under den första delen av projektet spenderades projektgruppens tid till största del på förbe- redelser. De dokument som krävdes skrevs och designbesult kring systemet togs. Många av dessa beslut togs utan att gruppen testade och experimenterade med olika lösningar vilket ledde till att problem kring besluten dök upp längre fram. En sådan testning skulle ha sparat gruppen tid då problemen tidigare hade dykt upp och snabbare kunde ha undvikits. Tids- mässigt borde förberedelsearbetet ha komprimerats för att projektet skulle delats upp bättre över de månader då projektet genomfördes.

6.2.3

Systemanatomin

I början av designarbetet skapade systemets arkitekt en systemanatomi (se avsnitt 5.3.1.5). Systemanatomin gav en översiktlig bild av vilken funktionalitet systemet skulle erbjuda och hur funktionaliteten fördelade sig på systemets moduler. Projektgruppen återvände dock inte till systemanatomin under implementationsarbetet, eftersom varken systemet eller projekt- gruppen var så omfattande att en översikt av detta slag var avgörande.

6.2.4

Dokumentarbetet

Under arbetet var tid för dokumentskrivning sällan planerad. Det var förutbestämt att un- gefär hälften av tiden skulle läggas på dokumentskrivning men aldrig specificerat exakt när. Detta gjorde det svårt att veta när dokument skulle skrivas och det hände att implementatio- nen tog mer tid av veckan än vad som var planerat.

6.2.5

Tidsplanering

Tidsplaneringen skiftade mycket under projektets gång och många ändringar fick göras un- der hela utvecklingsprocessen. Det som noterades var den signifikanta skillnaden i nedlagd arbetstid under april och maj i jämförelse med januari, februari och mars. Under de två sista månaderna ökade arbetsbelastningen markant och det märktes att tidsplaneringen inte var så

6.2. Diskussion av erfarenheter

jämnt fördelad som gruppen hade planerat från början. En tydligare tidsplanering där imple- mentationsfasen började tidigare hade varit fördelaktigt för att jämna ut arbetsbelastningen. Detta skulle dock varit svårt eftersom gruppen i det tidiga stadiet inte hade en tydlig bild av vilka egenskaper produkten skulle ha och detta ledde till att det var svårt att planera in någon faktisk implementation tidigare.

När det kom till antalet nedlagda arbetstimmar stämde den första tidsplanen relativt bra överens med vad gruppen hade presterat. Den planerade tiden för implementation var 840 timmar (se figur 5.6) och gruppen spenderade totalt 1022 timmar (se figur 5.8) vilket var signifikant mer än planerat. Vidare lades 520 arbetstimmar på kandidatrapporten (se avsnitt 5.4.1.2), vilket stämde relativt bra överens med den första planeringen på 560 timmar men var betydligt mindre än den andra planeringen som räknade med 700 timmar (se Figur 5.6 respektive Figur 5.7).

6.2.6

Tidigare erfarenheter

De erfarenheter som medtogs från tidigare projekt och projektliknande arbeten realiserades olika väl i projektet. Erfarenheterna redogörs för i avsnitt 5.4 och följande diskussion relaterar till de erfarenheter som gick mindre bra att implementera, alltså dokumentation och delad kunskap.

Att ingen skulle sitta ensam på kunskap var något som inte fungerade fullt ut. Detta be- rodde i de flesta fall på att en gruppmedlem fick ansvar för en specifik del av systemet och implementerade denna på egen hand. Hur detta kunde undvikas kan exempelvis vara att vid veckomöten eller dagliga Scrum-möten förklara den kod som producerats för att introducera övriga gruppen till tekniken. Ett annat sätt att hantera detta kunde varit att aldrig tilldela något till endast en person utan se till att minst två gjorde arbetet.

Att dokumentera viktiga beslut kontinuerligt gjordes heller inte under projektets gång och som reslutat att det blev mycket dokumentationstid inplanerad under projektets slutfas. Arbetet blev något svårare att genomföra då allt inte var färskt i minnet och några otydlig- heter fick redas ut. För att undvika detta kunde gruppen ha planerat in dokumentationstider under implementationsfasen där allt nyuppkommet kunde dokumenteras och redogöras för ordentligt. Detta hade minskat arbetsbördan mot slutet av projektet men även tydliggjort de bestämmelser som gjordes under implementationen. Å andra sidan hade en sådan lösning inneburit mer arbete under implementationsfasen och potentiellt försenat arbetet något.

6.2.7

Uppdelning i utvecklingsgrupper

Uppdelningen i mindre arbetslag var positivt för arbetet. Det möjliggjorde att projektmed- lemmarna kunde fördjupa sig i sina tilldelade arbeten och således slapp läsa på om den implementationsteori som behövdes för att skapa den andra delen av systemet. Dessa två delgrupper utvecklade egna ordförråd för vissa av systemets delar, något som ibland för- svårade diskussioner mellan grupperna. Detta var emellertid inget större problem, men det hade kanske hjälpt att samla fler tekniska termer tidigt och definiera dem så att alla projekt- medlemmar använde samma ordförråd. Att som projektmedlem göra granskningar på den delmodul man själv inte jobbat med skulle ge en bättre insikt i systemets helhet och säker- ställa att de båda kodbaserna håller samma standard och struktur.

Ett alternativ till detta hade varit att dela upp gruppen i team med några front- och back- end utvecklare i varje. Detta hade underlättat utvecklingen av delar av systemet som berör både front- och back-end, till exempel kommunikationen mellan dem. Det hade även gjort att projektmedlemmarna fick en större inblick i hela systemet, något som projektmedlemmarna nu inte fick. Däremot hade det försvårat integrationen av delar inom varje modul av systemet, vilket förmodligen hade haft en större negativ effekt.

Det finns en risk att projektets medlemmar inte lär känna varandra lika väl om gruppin- delningen görs alldeles för tydlig. Det är därför viktigt att ha social interaktion över del-

6.3. Metod

gruppsgränserna, något som inte har varit ett problem i detta projektarbete. I ett annat sam- manhang eller under ett längre arbete skulle detta kunna bli ett riktigt problem, och det skulle därför vara bra att se till att anordna gemensamma tillfällen att socialisera.

6.2.8

Ansvarsfördelning

Under projektet hade projektmedlemmarna förutbestämda roller vilka kom med ansvarsom- råden och specifika arbetsuppgifter. Detta var något som gruppen anammade och som bi- drog till att arbetsuppgifter lätt kunde tilldelas en av gruppmedlemmarna. Detta förenklade för gruppen att undvika konflikter kring missat arbete. Det gjorde också att gruppmedlem- marna hade sina egna delar att ansvara över vilket gjorde att alla alltid var sysselsatta med något.