4.4
Översikt över individuella bidrag
Inom projektet har varje gruppmedlem skrivit en individuell rapport som berör ett relevant ämne för projektet. Nedan presenteras varje del översiktligt så att läsaren snabbt kan få en överblick.
Kravhantering i ett mindre mjukvaruprojekt av Gustav Andersson
Denna rapport utvärderar projektets kravhantering med hjälp av två vetenskapliga artiklar om agila kravhanteringsmetoder och ett frågeformulär som gruppmedlemmarna besvarat.
Studenters kunskap om och inställning till lösenord och internetsäkerhet av
Gustav Eriksson
Denna rapport undersöker studenters kunskap om säker lösenordshantering. Detta innefat- tar hur mycket de vet om hur ett säkert lösenord konstrueras, vilka risker som finns samt vilken generell inställning till internetsäkerhet som råder. Studien utfördes med hjälp av en enkätunderöknig och en litteraturstudie.
Påverkan av olika arbetsflöden i Git under ett mindre mjukvaruprojekt av David
Jungmalm
I denna rapport beskrivs hur olika arbetsflöden, framförallt Gitflow som användes av grup- pen, påverkar ett mindre mjukvaruprojekt. Rapporten undersöker också hur historiken i Git påverkas av Gitflow och jämför för- och nackdelar med andra strategier. Resultatet visar att val av strategi är mycket av en personlig preferens och att en rak historik bäst bevaras i en strategi som inte använder sig av grenar.
Tillståndsstrukturer för webbapplikationer av Björn Möller Ehrnlund
Denna rapport presenterar och jämför två bibliotek för tillståndshantering i React. Biblioteken som studerades var Unstated och Redux. Arbetet baserades dels på en förstudie om bibliote- ken samt en implementation av en webbapplikation i respektive bibliotek. Studien visade att Unstated var marginellt mer nybörjarvänligt än Redux.
PostgreSQL eller MongoDB för ett mindre mjukvaruprojekt av Julius Petersson
Rapporten försöker redogöra vilken av databaserna PostgreSQL och MongoDB som lämpar sig bäst i ett mindre mjukvaruprojekt. Frågan är mer komplex än ett enkelt svar och rapporten försöker ge en enklare riktlinje för hur valet bör ske i ett liknande scenario som detta projektet.
Sandboxing för att köra okänd kod av Tim Yngesjö
Denna rapport beskriver hur godtyckliga binärer kan köras på ett relativt säkert sätt så att värdsystemet inte tar skada. Även vilken metod som var lämpligast för detta projekt att an- vända sig av diskuteras.
5
Diskussion
I detta kapitel diskuteras de resultat som presenterades i rapporten. Det diskuteras huruvida systemanatomin och dokument användes på ett korrekt sätt och hur kodgranskning följde de standarder som bestämdes i början av projektet. I slutet diskuteras produkten ur ett håll- barhetsperspektiv med avseende på faktorerna etik, ekonomi, individ, teknik och miljö.
5.1
Systemanatomi
En systemanatomi ger en kort beskrivning av ett system som är lättare att enas om än långa dokumentationstexter. Den verkar även ge fördelar i projekt som förändras. I dessa projekt är det av stor vikt att alla i projektgruppen har en gemensam förståelse för produkten och dess beroenden vilket systemanatomin verkar kunna hjälpa till med. [77] Då projektets initiala struktur inte ändrades kan det argumenteras att motiveringen till att följa upp systemanato- min saknades. Däremot kan skapandet ses som en fördel eftersom vissa medlemmar ansåg att denna hjälpte till att skapa en förståelse för produkten. Då systemanatomin inte följdes upp begränsas möjligheten till att diskutera vilken påverkan detta kunde haft. Resultatet kring systemanatomin gäller bara dess skapande i ett tidigt stadium. Sammantaget ger detta en be- gränsad vy och nyttan är svår att fastställa då det endast var en minoritet som funnit något positivt i systemanatomin och dess skapande.
5.2
Dokument
Det framkom att många i gruppen upplevt att de fått all nödvändig information ifrån möten och gemensam utvecklingstid. Detta sträckte sig även till de övriga dokumenten. Däremot var en majoritet av gruppen eniga om att dokumenten varit viktigare om gruppen varit stör- re. På grund av gruppens lilla storlek kunde information utan problem framföras via möten samt i kortare meddelanden genom valfri kommunikationskanal. Det i sin tur ledde till att dokument inte efterföljdes. Det går självfallet inte att utesluta möjligheten att dokumenten kunde gett ett bra stöd om gruppen hade tvingats följa upp dem kontinuerligt under projek- tet.
5.3. Kodgranskning
5.3
Kodgranskning
Syftet med de skapade reglerna kring kodgranskning var ett främja mer välskriven och mer väldokumenterad kod. Överlag visade erfarenhetsenkäten att medlemmarna upplevde den önskade effekten av kodgranskningen. Att koden blev bättre var naturligt eftersom den granskades av en yttre person innan den flyttades in i produkten. En negativ konsekvens av kodgranskning är att det kan ta ett tag innan koden godkänns av någon. Under tiden då kod ligger för granskning kan en utvecklare bli blockerad från att fortsätta med sitt jobb som bygger på koden som håller på att bli granskad. I erfarenhetsenkäten kom det fram att många hade upplevt detta problem. Att tiden från merge request till att koden godkändes in i development var relativt lång berodde troligen på metoden för att tilldela ansvarig för att granska. Hade metoden varit mer strikt hade det kunnat gå snabbare för en granskare att utnämnas och därmed hade fördröjningen minskat. Det fanns inga regler för hur snabbt den som blev tilldelad att granska skulle granska koden. Att ha någon form av tidsbegränsning, exempelvis en arbetsdag hade kanske snabbat på processen.
Granskningen var från början tänkt att hanteras av utvecklingsledaren, men gruppen bör- jade ganska snabbt diskutera och gemensamt komma fram till vem som skulle ta på sig det då det kändes mer praktiskt. Exempelvis var det rimligt att de som satt och jobbade på klienten skulle granska varandras merge requests då de har bättre kunskap i just det området än de andra gruppmedlemmarna. Denna princip har varit bra då eventuella buggar hittades snab- bare. Planen från början att varje merge request skulle granskas av minst två personer. Detta slutade följas nästan direkt då utvecklingsfasen kom igång på riktigt, delvis på grund av att granskningen tog längre tid än förväntat och att det vid den tidpunkten kändes viktigare att fortsätta arbeta på nya saker.
För framtida studier skulle det vara intressant att testa olika metoder för granskning av kod, som att ha mer än en granskare för varje merge request. Detta skulle kunna testa om det finns möjlighet att godkänna kod snabbare men med samma kvalitet eller om flera personer för granskning endast skulle leda till överflödig kommunikation.
5.4
Erfarenheter
Med hjälp av erfarenhetsenkäten och de dokumenterade erfarenheterna kan en relativt bra översikt om hur gruppen ansåg projektet gått. Överlag verkade utvecklingen av produkten gått bra. Det som gruppen upplevde hade gått mindre bra var testning, WSL och PostgreSQL. Att testningen blev problematisk berodde troligtvis på att testledaren hade hoppat av grup- pen. Detta var ett exempel på att dela upp arbetsbördan kan leda till problematik. Med osä- kerheten innan det verkliga avhoppet visste gruppen inte hur de skulle agera vilket ledde till att testningen blev fördröjd då de inte visste huruvida testledaren skulle närvara på nästkom- mande tillfälle eller inte. Problematiken med WSL låg troligtvis i en naiv tro från gruppen att det skulle fungera felfritt och vara exakt likadant som att ha en vanligt distribution av Li- nux. PostgreSQL var ett mer komplext problem att lösa. Det hade gått snabbare att utveckla i MySQL då gruppen hade kunskap inom det. Det fanns däremot ingenting som gjorde att just PostgreSQL var ett sämre verktyg att utveckla med. När gruppen egentligen inte fick någon fördel av att använda PostgreSQL så skulle det troligtvis varit ett bättre designval att använda MySQL. Av detta kan noteras att det kan vara bra att tidigt ifrågasätta huruvida en viss funktionalitet kan motivera ett byte av mjukvara. Det applicerar både på problematiken med PostgreSQL och WSL.
Om resultatet kring saker som inte är utveckling kan en trend finnas. Trenden är att grup- pen själva upplevt att de varit dåliga på att följa de många dokument som skrevs. Flertalet gruppmedlemmar påpekade att de upplevde att det inte vara givande att studera dokument när de kunde få tag i informationen lätt ändå för att gruppen var så pass liten. En av dessa gruppmedlemmar gick så pass långt till att undra hur det skulle finnas tid att följa massor av dokument för utveckling om det inte ens fanns tid att faktiskt utveckla?
5.5. Produktutveckling
5.5
Produktutveckling
I detta avsnitt presenteras diskussion kring de resultat som berör produktutvecklingen. Här innefattas projektets tidsomfång, Gitflow, Kanbantavlan och arbetsmetoden Scrum.
5.5.1
Projektets omfång av tid
Att det utförda projektet endast skedde på deltid begränsade projektet mycket. Som en- kätsvaren tydde på, var det många som upplevde att dokument och processer inte följdes eftersom det inte fanns tillräckligt mycket tid för både utveckla produkten och följa proces- serna samtidigt. Hade projektet utförts på heltid hade det kanske troligtvis gett annorlunda resultat, eftersom medlemmar då haft mer arbete att diskutera varje vecka. Detta hade även gjort projektet större och därmed inkluderat erfarenheter från underhåll av systemet, vilket inte blev så stor del av projektet.
5.5.2
Scrum
Scrummetoden har till viss del efterföljts i den utsträckning som avsågs vid projektets start. Metoden var helt ny för flera medlemmar vilket kan ha bidragit till att den inte följdes till den graden som gruppen från början hade tänkt.
5.5.3
Gitflow
Den metod som användes för versionshantering har visat sig fungera på det sätt som var tänkt. Metoden har, genom att lägga till kodgranskning i steget där kod sammanfogas in från en funktionsgren, förbättrat kodkvaliteten och förståelsen för andras kod. Däremot har mas- tergrenen visat sig vara överflödig. Tanken med denna har varit att sammanfoga stabila ut- vecklingsgrenar. Anledningar till detta kan tänkas vara brist på integrationstester som bidrar till att gruppen inte har känt tillräcklig tillförlitlighet för stabiliteten av utvecklingsgrenen.
5.5.4
Kanbantavla
I samband med att projektet använde sig av Scrummetoden så användes också en Kanban- tavla i Jira för att logga vilka funktioner som skulle prioriteras. Tanken var också att alla medlemmar skulle tilldela sig själva de funktioner som de jobbade med för tillfället. Syste- met fungerade ungefär fram till andra iterationen, då alla funktioner istället diskuterades och bokfördes i ett kalkylark på gruppens Google Drive. Tanken med Kanban i Jira var god, men metoden krävde dels att alla funktionaliteter bestämdes och sedan att man var tvungen att kolla igenom hela orderstocken för att hitta alla funktioner, och sedan prioritera mellan dessa för vilka funktioner som skulle utföras varje sprint. Gruppen tyckte det kändes mer intuitivt att diskutera vilka funktioner som saknades inför varje sprint, istället för att välja de funktio- ner som fanns i Jira. Detta för att i Jira visades allting som fanns och hade inte den struktur som krävdes för att lätt kunna använda det.
5.6
Hållbarhetsperspektiv
För framtida mjukvaruprojekt kommer hållbarhet bli ett allt större fokus. Universitet har re- dan fått direktiv i hur detta ska vara en del av utbildningar och detta appliceras bland annat i denna kurs. Under kursens tidiga stadie fick studenterna analysera sitt projekt utifrån ett hållbarhetsperspektiv som en övning inför framtiden. Några av de tankar som kom upp pre- senteras nedan.
5.6. Hållbarhetsperspektiv
5.6.1
Etik
Överlag är produkten väldigt neutral vad det gäller personidentiteter, eftersom endast per- soners namn, startår på universitetet och deras id från universitetet sparas på applikationen. Detta leder inte till exkludering av specifika persongrupper och skulle ge alla studenter vid universitetet samma möjlighet att använda applikationen.
Skulle applikationen senare använda en rankinglista skulle det kunna leda till både posi- tiva och negativa konsekvenser. Dels skulle det kunna ge duktiga studenter extra motivation och att universitetet skulle kunna använda detta för att exempelvis utse assistenter för labora- tionsserier vid universitetet. Dock skulle det också kunna påverka mindre erfarna studenter negativt på så sätt att de inte skulle vilja att låga resultat publicerades på hemsidan.
5.6.2
Ekonomi
Ur ett ekonomiskt perspektiv kan produkten innebära en stor besparing för Linköpings uni- versitet. Om produkten sätts i bruk kan det dels innebära att färre laborationsassistenter krävs då inlärningen blir mer intuitiv. Den största kostnaden för att sätta den i bruk skulle vara dess konfiguration och energikostnader.
5.6.3
Individ
Produkten erbjuder stor flexibilitet för att alla studenter ska kunna använda den. Friheten kan både ge positiva och negativa effekter för individerna. Dels kan det ge dem större möjlighet att arbeta när de vill, eftersom de inte behöver tillgång till laborationssalar och de skulle kunna arbeta när de ville i en högre utsträckning än idag. Dock skulle detta kunna leda till att vissa studenter arbetade för mycket hemma och på så vis blivit mer isolerade.
5.6.4
Teknik
Produkten hade stort fokus på att motivera studenter till att lösa mjukvarumässiga problem. Detta kan bidra till att studenters framtida problemlösningsförmåga blir bättre. Detta kan bidra till att framtida ingenjörer skapar mer hållbara system.
5.6.5
Miljö
Produktens miljöpåverkan kan både argumenteras för och emot om den är positiv. Eftersom exekveringen av spel sker på servern, kräver inte applikationen att användare utvecklar sina agenter på kraftfulla enheter vilket kan leda till att mindre energikrävande enheter används. Skulle applikationen däremot komma i bruk men inte användas av studenter, skulle det leda till onödig energikonsumtion eftersom applikationen kräver att servern väntar på för- frågningar från klienter.
Systemet skulle också indirekt kunna leda till att mindre transportmedel krävs eftersom studenter erbjuds större möjlighet att arbeta från sina hem.
6
Slutsatser
För att besvara projektets frågeställningar utformades ett antal olika metoder. Med hjälp av dessa metoder kunde gruppen presentera de resultat som framkom av metoderna. Resulta- ten diskuterades sedan utifrån olika perspektiv. Sammanställningen av den viktigast infor- mationen som gruppen vill redovisa för att besvara frågeställningarna, som står till grund för denna rapport, presenteras i detta kapitel.
6.1
Hur kan en webbplattform för spelifierad tävlingsprogrammering
implementeras så att värde skapas för kunden?
Det system som utvecklats har delats upp i flera komponenter som ska kunna fungera själv- ständigt. Genom att skapa ett modulärt system så har gruppen främjat vidareutveckling för kunden. Det ger även kunden möjlighet att ersätta de komponenter som de inte anser passar produkten.
Systemet har utvecklats med kundens plattform i åtanke. Systemet ska utan större pro- blem gå att installeras och köras på en servermaskin med en relativt modern Linuxdistribu- tion installerat, vilket är det som kunden har.
Spelmotorn är väldokumenterad och förberedd för utökningsmöjligheter tack vare an- vändningen av abstrakta objekt. Det har även skrivits manualer för att komplettera doku- mentationen som skapar värde för kunden genom att erbjuda goda möjligheter att utveckla och utöka plattformen med flera spel.
Databasen implementerades på ett sätt som gjorde det möjligt att spara användare, spel, agenter, loggar och spelhistorik för att på ett tillfredsställandet sätt kunna hantera den infor- mation som krävdes för att ta fram det system som kunden efterfrågade.