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/008--SE
Plattform för spelifiering inom
programmeringskurser
Platform for gamification within programming courses
Gustav Andersson
Gustav Eriksson
David Jungmalm
Björn Möller Ehrnlund
Julius Petersson
Tim Yngesjö
Handledare : Henrik Henriksson 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/. © Gustav Andersson Gustav Eriksson David Jungmalm Björn Möller Ehrnlund Julius Petersson Tim Yngesjö
Sammanfattning
Denna rapport beskriver ett arbete som utförts i kursen TDDD96 - Kandidatprojekt i pro-gramvaruutveckling. Projektet gick ut på att utveckla en webbplattform för spelifierad täv-lingsprogrammering åt UPP-gruppen på Institutionen för datavetenskap vid Linköpings uni-versitet. Plattformen är tänkt att användas i programmeringskurser. Den innehåller funk-tioner som låter användare ladda upp spel och agenter via en hemsida där agenterna kan spela spelen mot varandra. Produkten består av en klient i form av en hemsida, och en server. Det finns även ett API för att skapa spel till plattformen. Rapporten beskriver dessa delar både på det tekniska planet samt hur utvecklingsprocesserna gick till. Utöver detta presenteras och diskuteras gruppens erfarenheter från projektet samt hur den slutgiltiga produkten förhåller sig till gruppens och kundens mål. Genom att använda kodgransk-ning under utvecklingen upplevde gruppen en ökad kvalitet på koden, men också att det stävjade utvecklingen i de fall då granskningen tog lång tid. Den viktigaste erfarenheten gruppen tog med sig från detta projekt är att kommunikationen har mycket stor betydelse för resultaten, och bör därför struktureras upp ordentligt. Genom att arbeta med kundens behov som högsta prioritet, dokumentera all kod väl och konstruera systemet modulärt för att främja vidareutveckling, kan en bra och välgjord produkt skapas som ger värde för kunden.
Författarnas tack
Gruppen vill ägna ett stort tack till de som varit till hjälp under projektets gång. Ett stort tack riktas till projektets kund som varit tillgänglig, hjälpsam och gett bra synpunkter. Gruppen vill också rikta ett tack till kursledare Kristian Sandahl och handledare Henrik Henriksson som har visat stort intresse att leda gruppen i rätt riktning.
Innehåll
Sammanfattning iii Författarnas tack iv Innehåll v Figurer xi Tabeller xii 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 2 1.4 Tidigare erfarenheter . . . 2 2 Teori 3 2.1 Programmeringsbibliotek . . . 3 2.1.1 HTML . . . 3 2.1.2 CSS . . . 3 2.1.3 JavaScript . . . 3 2.1.4 Npm . . . 4 2.1.5 React . . . 4 2.1.6 Material-UI . . . 4 2.1.7 Node.js . . . 4 2.1.8 Express . . . 4 2.1.9 PostgreSQL . . . 4 2.1.10 C++ . . . 5 2.2 Utvecklingsverktyg . . . 52.2.1 Visual Studio Code . . . 5
2.2.2 CMake . . . 5 2.2.3 Git . . . 5 2.2.4 GitLab . . . 5 2.3 Testramverk . . . 6 2.3.1 Google test . . . 6 2.3.2 Jest . . . 6 2.4 Arbetsmetod . . . 6 2.4.1 Scrum . . . 6 2.4.2 Slack . . . 6 2.4.3 Jira Software . . . 7 3 Metod 8 3.1 Metod för att fånga erfarenheter . . . 8
3.2 Enkät . . . 8 3.3 Utvecklingsmetodik . . . 9 3.3.1 Förstudie . . . 9 3.3.2 Dokument . . . 9 3.3.3 Arbetsmetod . . . 10 3.3.4 Versionshantering . . . 11 3.3.5 Kodgranskning . . . 11 3.3.6 Utvecklingsverktyg . . . 11 3.3.7 Grupproller . . . 11 4 Resultat 13 4.1 Erfarenhetsenkät . . . 13 4.1.1 Systemanatomi . . . 13 4.1.2 Kodgranskning . . . 13 4.1.3 Arbetsmetoder . . . 14 4.1.4 Utvecklingsverktyg . . . 15
4.1.5 Samarbete och roller . . . 15
4.1.6 Implementation . . . 15 4.1.7 Dokumentation . . . 15 4.2 Dokumenterade erfarenheter . . . 15 4.3 System . . . 16 4.3.1 Klient . . . 16 4.3.2 Server . . . 19 4.3.3 Spelmotor . . . 20 4.3.4 Databas . . . 21
4.4 Översikt över individuella bidrag . . . 22
5 Diskussion 23 5.1 Systemanatomi . . . 23 5.2 Dokument . . . 23 5.3 Kodgranskning . . . 24 5.4 Erfarenheter . . . 24 5.5 Produktutveckling . . . 25
5.5.1 Projektets omfång av tid . . . 25
5.5.2 Scrum . . . 25 5.5.3 Gitflow . . . 25 5.5.4 Kanbantavla . . . 25 5.6 Hållbarhetsperspektiv . . . 25 5.6.1 Etik . . . 26 5.6.2 Ekonomi . . . 26 5.6.3 Individ . . . 26 5.6.4 Teknik . . . 26 5.6.5 Miljö . . . 26 6 Slutsatser 27 6.1 Hur kan en webbplattform för spelifierad tävlingsprogrammering implemen-teras så att värde skapas för kunden? . . . 27
6.2 Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara intressanta för framtida projekt? . . . 27
6.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . . 28
6.4 Hur kan kodgranskning i ett mindre mjukvaruprojekt fungera? . . . 28
A.1 Inledning . . . 29
A.1.1 Syfte . . . 29
A.1.2 Frågeställning . . . 29
A.1.3 Avgränsningar . . . 29
A.2 Bakgrund . . . 30
A.2.1 Projektets kravhantering . . . 30
A.3 Teori . . . 30
A.3.1 Kravhantering . . . 30
A.3.2 User story . . . 30
A.3.3 Användarfall . . . 30 A.4 Metod . . . 31 A.4.1 Informationssökning . . . 31 A.4.2 Datainsamling . . . 31 A.5 Resultat . . . 31 A.5.1 Informationssökning . . . 31 A.5.2 Datainsamling . . . 32 A.6 Diskussion . . . 33 A.7 Slutsatser . . . 34
B Studenters kunskap om och inställning till lösenord och internetsäkerhet av Gus-tav Eriksson 35 B.1 Inledning . . . 35 B.1.1 Syfte . . . 35 B.1.2 Frågeställningar . . . 35 B.1.3 Avgränsningar . . . 36 B.2 Teori . . . 36 B.2.1 Brute force . . . 36 B.2.2 Dictionary attack . . . 36 B.2.3 Social engineering . . . 36 B.2.4 Rootkit . . . 37 B.2.5 SQL-injection . . . 37 B.2.6 Keylogger . . . 37
B.2.7 Cross site scripting (XSS) . . . 37
B.2.8 Man in the middle . . . 37
B.2.9 Evil twin attack . . . 38
B.2.10 Lösenordshanterare . . . 38 B.2.11 Tvåfaktorsautentisering . . . 38 B.3 Metod . . . 38 B.3.1 Undersökning . . . 38 B.3.2 Litteraturstudie . . . 39 B.4 Resultat . . . 39 B.4.1 Undersökning . . . 40 B.4.2 Litteraturstudie . . . 41 B.5 Diskussion . . . 41 B.6 Slutsatser . . . 43
C Påverkan av olika arbetsflöden i Git under ett mindre mjukvaruprojekt av David Jungmalm 44 C.1 Inledning . . . 44 C.1.1 Syfte . . . 44 C.1.2 Frågeställning . . . 44 C.1.3 Ordlista . . . 44 C.2 Bakgrund . . . 45
C.3 Teori . . . 45 C.3.1 Git . . . 45 C.3.2 Git kommandon . . . 45 C.3.3 Subversion . . . 45 C.3.4 Merge request . . . 46 C.3.5 Gitflow . . . 46 C.3.6 Oneflow . . . 46 C.3.7 Centralized workflow . . . 47 C.4 Metod . . . 47 C.4.1 Enkät . . . 47 C.4.2 Litteraturstudie . . . 47 C.5 Resultat . . . 47 C.5.1 Enkät . . . 48 C.5.1.1 Förkunskaper . . . 48 C.5.1.2 Merge requests . . . 48 C.5.1.3 Merge conflict . . . 48
C.5.1.4 Gruppens uppfattningar om Git och Gitflow . . . 48
C.5.2 Litteraturstudie . . . 49
C.6 Diskussion . . . 51
C.6.1 Metod . . . 51
C.6.2 Resultat . . . 51
C.7 Slutsats . . . 51
C.7.1 Hur påverkar Gitflow ett mindre mjukvaruprojekt? . . . 51
C.7.2 Hur påverkas historiken i Git av att använda Gitflow? . . . 52
C.7.3 Vilka fördelar och nackdelar har Gitflow jämfört med andra metoder såsom Oneflow och Centralized workflow? . . . 52
D Tillståndsstrukturer för webbapplikationer av Björn Möller Ehrnlund 53 D.1 Inledning . . . 53 D.1.1 Syfte . . . 53 D.1.2 Frågeställningar . . . 53 D.1.3 Bakgrund . . . 53 D.2 Teori . . . 54 D.2.1 Google Chrome . . . 54 D.2.2 Model-View-Controller . . . 54 D.2.3 Tillståndshantering i React . . . 54 D.2.4 Context . . . 54 D.2.5 Unstated . . . 55 D.2.6 Redux . . . 56 D.3 Metod . . . 56 D.3.1 Förstudie . . . 56 D.3.2 Prototyp . . . 57 D.3.3 Implementation . . . 57 D.4 Resultat . . . 57 D.4.1 Prototyp . . . 57
D.4.2 Implementation av grundläggande applikation . . . 58
D.4.3 Tidsåtgång för Unstated och Redux . . . 58
D.5 Implementation i Unstated . . . 58 D.6 Implementation i Redux . . . 59 D.7 Diskussion . . . 61 D.7.1 Metod . . . 61 D.7.2 Implementation . . . 61 D.8 Slutsatser . . . 61
D.8.1 Hur lång tid tar det att sätta sig in i grunderna bakom biblioteken och
implementera en given webbapplikation i dem? . . . 61
D.8.2 Hur påverkas komponenternas moduläritet av de olika biblioteken? . . 62
E PostgreSQL eller MongoDB för ett mindre mjukvaruprojekt av Julius Petersson 63 E.1 Introduktion . . . 63 E.1.1 Frågeställningar . . . 63 E.2 Syfte . . . 63 E.3 Avgränsningar . . . 63 E.4 Teori . . . 64 E.4.1 MongoDB . . . 64 E.4.2 PostgreSQL . . . 64 E.5 Metod . . . 64 E.6 Resultat . . . 64
E.6.1 Fördelar och nackdelar mellan de båda databaserna . . . 64
E.6.2 Skapande av databaser och deras skillnad i syntax . . . 65
E.6.3 Sammanfattning av resultat . . . 67
E.7 Diskussion . . . 67
E.7.1 Resultat . . . 67
E.7.2 Utökningar . . . 67
E.8 Slutsats . . . 68
F Sandboxing för att köra okänd kod av Tim Yngesjö 69 F.1 Inledning . . . 69
F.2 Frågeställning . . . 69
F.3 Begränsningar . . . 70
F.4 Bakgrund . . . 70
F.5 Teori . . . 70
F.5.1 Sandboxing och underliggande tekniker . . . 70
F.5.1.1 User ID . . . 70 F.5.1.2 Linux capabilities . . . 70 F.5.1.3 Chroot . . . 71 F.5.1.4 Seccomp . . . 71 F.5.1.5 Cgroups . . . 71 F.5.1.6 Linux namespaces . . . 71 F.5.2 Högnivå-mjukvara för sandboxing . . . 71 F.5.2.1 Virtuell maskin . . . 72 F.5.2.2 Firejail . . . 72 F.5.2.3 Docker . . . 72 F.6 Metod . . . 72 F.6.1 Litteraturstudie . . . 72 F.6.2 Praktisk implementation . . . 72 F.7 Resultat . . . 72
F.7.1 Användning av virtuell maskin . . . 72
F.7.2 Använding av chroot . . . 73
F.7.3 Använding av Linux namespaces . . . 73
F.7.4 Använding av Firejail . . . 73
F.7.5 Användning av Docker . . . 73
F.8 Diskussion . . . 74
F.8.1 Kombination av olika säkerhetsmetoder . . . 74
F.8.2 Val av teknik i projektet . . . 74
G Bilaga 1: Frågeställningar om versionshantering 75
G.1 Intervjufrågor . . . 75 G.2 Svar på intervjufrågor . . . 76
Figurer
2.1 Exempel på en relationsdatabas över hundar och deras ägare. . . 5
3.1 Bild över projektets Kanbantavla i Jira. . . 11
4.1 Systemanatomin som togs fram för produkten. . . 14
4.2 Diagram på den övergripande kommunikationen mellan de utvecklade modulerna. 16 4.3 Bild på välkomstsidan. . . 17
4.4 Bild på inloggningssidan. . . 17
4.5 Bild på hemsidan. . . 18
4.6 Bild på spelsida utan en uppladdad agent. . . 18
4.7 Bild på spelsida med en uppladdad agent. . . 19
4.8 Bild på sidan för att spela upp en spelomgång. . . 19
4.9 Klassdiagrammet för spelmotorn. . . 20
4.10 Flödesschema över ett spels livscykel. . . 21
4.11 ER-diagram för en implementerade databasen. . . 21
B.1 Svaren på fråga 3. . . 40
B.2 Svaren på fråga 4. . . 40
B.3 Stapeldiagram för svaren på frågan om varsamhet på internet. . . 41
C.1 Visualisering av Git rebase. . . 46
C.2 Visualisering av Gitflowmodellen. . . 46
C.3 Visualisering av Oneflowmodellen. . . 47
C.4 Bra merge i Centralized workflow. . . 49
C.5 Sämre merge i Centralized workflow. . . 50
C.6 Merge i Gitflow. . . 50
D.1 Flödet då en underliggande komponent uppdaterar delad data i React. . . 55
D.2 Grafisk prototyp för den implementerade applikationen. . . 57
D.3 Utseende av den implementerade applikationen. . . 58
Tabeller
3.1 Ansvarsfördelning av dokument mellan roller. . . 9
A.1 Frågor i frågeformulär för . . . 31
B.1 Deltagarnas programspridning. . . 40
B.2 Svaren på ja/nej-frågorna. . . 40
1
Inledning
Datorer tar allt mer plats i samhället. Fler och fler tjänster kräver digitala lösningar, vilket gör att efterfrågan på mjukvaruutvecklare ständigt ökar. Linköpings universitet antar varje år ungefär 200-300 studenter till sina datainriktade program och arbetar ständigt för att få så många som möjligt att fullfölja sin utbildning. För att göra kurser mer motiverande och in-tuitiva önskade UPP-gruppen på Institutionen för datavetenskap en produkt för tävlingsinriktad programmering.
Denna rapport beskriver utvecklingsprocesserna och implementationen av en webbappli-kation för spelifierad tävlingsprogrammering som utfördes av sex studenter vid Linköpings universitet. Plattformen som implementerades är webbaserad, konstruerad för att kunna an-vändas som en utbildnings- och tävlingsplattform.
1.1
Motivering
Det finns många sätt att få personer att bli intresserade av och lära sig programmering. Ett sätt är att använda sig av tävlingslik problemlösning. Tävlingslik problemlösning erbjuds på olika sätt av ett flertal plattformar. Spelifierad tävlingsprogrammering där användare pro-grammerar program, i denna rapport kallat agenter, som spelar spel mot varandra är ett sätt att erbjuda tävlingslik problemlösning med programmering i fokus. Fördelarna med en så-dan plattform är att användarna får visuell feedback på vad deras kod gör och att ett såså-dant tävlingsmoment kan motivera användaren att förbättra sin agent eller få användaren att tyc-ka plattformen är rolig. För att göra en sådan plattform lättillgänglig är webben en bra plats att distribuera den på.
1.2
Syfte
Syftet med projektet som beskrivs i denna rapport har varit att samla in erfarenheter från att arbeta med ett kundbaserat mjukvaruprojekt i en grupp med bestämda ansvarsroller och arbetsmetodiker. Gruppen skulle också skapa en produkt som gav värde för kunden. Syftet med denna rapport är att presentera erfarenheter från projektet samt beskriva arbetet och utvecklingen av den kundbeställda produkten. Detta för att upplysa om de erfarenhe-ter som kan vara viktiga i framtida projekt och ge en beskrivning av hur en plattform för spelifiering kan implementeras.
1.3. Frågeställningar
1.3
Frågeställningar
Denna rapport kommer att besvara följande frågeställningar:
1. Hur kan en webbplattform för spelifierad tävlingsprogrammering implementeras så att värde skapas för kunden?
2. Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara in-tressanta för framtida projekt?
3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? 4. Hur kan kodgranskning i ett mindre mjukvaruprojekt fungera?
1.4
Tidigare erfarenheter
Alla gruppmedlemmar hade viss tidigare erfarenhet av att jobba i en större projektgrupp. De studenter som studerar datateknik hade bland annat läst TSEA29 Konstruktion med mikrodatorer och de studenter som studerar mjukvaruteknik hade läst TDDD92 Artificiell intelligens -projekt. Dessa projekt hade dock varit i mindre omfång av tid.
2
Teori
I detta avsnitt behandlas den relevanta teorin för projektets olika delar. Den information som tas upp här har som syfte att ge underlag till förståelsen för både hur arbetsprocessen gått till och hur produkten har utvecklats.
2.1
Programmeringsbibliotek
För att genomföra projektet användes ett antal olika programspråk och bibliotek. Grundläg-gande teori för dessa beskrivs i kommande avsnitt.
2.1.1
HTML
Hyper Text Markup Language, HTML, är ett markeringsspråk som definierar hur en webbsi-da ska struktureras. Språket inkluderar specifika element för att visa webbsi-data och ta emot inwebbsi-data, men det finns också möjlighet att definiera egna mer komplexa element som innehåller undre element. För att definiera utseende och funktionalitet hos webbsidor används CSS respektive JavaScript. [38]
2.1.2
CSS
Cascading Style Sheets, CSS, är ett formateringsspråk som beskriver hur element i bland annat HTML ska visualiseras. CSS används som standard i dagens webbläsare och har därför också blivit en standard vid utveckling av webbapplikationer. [22]
2.1.3
JavaScript
JavaScript är ett objektorienterat språk med dynamisk typning. Språket är ett multi-paradigmspråk vilket innebär att det tillåter flera programmeringsparadigmer, där ett pro-grammeringsparadigm är ett tillvägagångssätt och ett sätt att tänka när ett program ska ut-vecklas. De paradigmer som stödjs är objektorientering samt imperativ och funktionell pro-grammering. [41]
2.1. Programmeringsbibliotek
2.1.4
Npm
Node package manager, Npm, är en pakethanterare för JavaScript. Den används framförallt för att hantera standardpaket till exekveringsmiljön Node.js. Npm består av olika delar. Det består av en webbsida där man kan söka efter paket och där de ansvariga för paketen kan administrera dem. Det finns också ett kommandoradsgränssnitt där det går att interagera med Npm. Det är framförallt denna funktion som används av utvecklare när de behöver installera olika paket som krävs till deras Node.js-implementation. [9]
2.1.5
React
React är ett bibliotek för JavaScript. Biblioteket är utvecklat av Facebook och innehåller funk-tionalitet för att rendera element på webbsidor. Biblioteket bygger på att dela upp webbsidor i komponenter, där en komponent kan bestå av andra komponenter. Genom att låta klasser i JavaScript ärva React.Component fås tillgång till en speciell renderingsfunktion som React sedan kan kalla på för att rendera ett specifikt element. [61]
2.1.6
Material-UI
Material-UI är ett bibliotek för React som innehåller schablonelement för att bygga kompo-nenter i React. Biblioteket är ett MIT-licensierat öppen källkodsprojekt som bygger på Goog-les Material Design, vilket är ett standardiserat grafiskt gränssnitt. Biblioteket finns tillgäng-ligt som ett paket i Npm. [53, 54]
2.1.7
Node.js
Node.js är en exekveringsmiljö för att exekvera kod skriven i JavaScript med mer rättigheter än en vanlig webbläsare. Verktyget är designat för att skapa skalbara webbapplikationer. Eftersom webbapplikationer medför många simultana och oförutsägbara händelser är miljön asynkront händelsedriven. Det betyder att koden exekveras vid en händelse istället för som i ett enda flöde. [8]
2.1.8
Express
Express är ett Node.js-ramverk för webbapplikationer. Det kommer med funktionalitet för att skicka och ta emot HTTP-förfrågningar, vilket är ett kommunikationsprotokoll som används mellan webbsidor och servrar. Express finns tillgängligt som ett paket i Npm. [29]
2.1.9
PostgreSQL
PostgreSQL är ett databassystem som implementerar SQL, Structured Query Language. SQL är en standard för hur relationsdatabaser skapas och manipuleras. I SQL representeras data-basen som en samling tabeller med data och procedurer som kan användas för att hämta och modifiera data i dem. [74, 10]
Tabeller är strukturer baserade på kolumner och rader. Kolumner representerar attribut av objekt och tabellers rader representerar instanser av dem. Relationer mellan tabeller repre-senteras av värden i rader som refererar till andra tabellers värden. [75]
I figur 2.1 visas ett exempel på hur en implementation av en relationsdatabas för hundar och dess ägare skulle kunna se ut. Tabellerna Person och Dog representerar alla personer och hundar i databasen. I denna implementation används attributet owner_id i tabellen Dog för att referera till ett id-attribut i Person för att koppla hundars ägare till hundar.
2.2. Utvecklingsverktyg id name Person 1 Bob 2 Alice id name Dog 1 Scooby 2 Rufus owner_id 1 1
Figur 2.1: Exempel på en relationsdatabas över hundar och deras ägare.
2.1.10
C++
C++ är ett kompilerat programmeringsspråk. Språket tillåter flera programmeringspara-digm, exempelvis objektorientering. [17]
2.2
Utvecklingsverktyg
Utvecklingsverktyg avser de verktyg som användes för att underlätta skrivning av, versions-hantering av och byggande av kod. Kommande avsnitt beskriver funktionaliteten av dessa olika verktyg.
2.2.1
Visual Studio Code
Visual Studio Code (VS Code) är en tunn källkodsredigerare. VS Code i sig själv har inte spe-ciellt mycket funktionalitet men det finns många tillägg (eng. extensions) som kan installeras för att öka funktionaliteten av programmet. Exempel på ett sådant tillägg är syntaxkoll för C++. [91]
2.2.2
CMake
CMake är ett verktyg för att hantera hur mjukvara byggs och använder sig av metoder som är oberoende av kompilator. CMake är i första hand avsett för att bygga system skrivna i C/C++. Make-filer som beskriver hur ett program ska byggas i Linux kan vara svåra att underhålla och förstå hur de fungerar. CMake underlättar byggandet genom att en användare först specificerar vad som ska byggas och därefter genereras automatiskt en Make-fil för att bygga systemet. [7]
2.2.3
Git
Git är ett versionshanteringsverktyg som tillåter klienter att spara filhistorik antingen lokalt eller i en webbtjänst som till exempel GitLab, som nämns i stycke 2.2.4. När ett nytt filsystem ska sparas skapas en så kallad snapshot av dess ursprungliga filer. När ett filsystem har sparats kommer det att användas som referens vid nästkommande sparning. Den nya sparningen innehåller vilka uppdateringar som har utförts och använder den tidigare sparningen som utgångspunkt tillsammans med ändringarna för att återskapa det aktuella filsystemet.
Verktyget använder även så kallade grenar i projekt. Projekt kan då delas upp i flera filsy-stem. Filsystem kan även slås ihop med hjälp av kommandot merge i Git. Detta möjliggör för att arbeta på flera delar av projekt parallellt. Det möjliggör också merge requests, vilket är en förfrågan om att få sammanfoga två grenar. [33]
2.2.4
GitLab
GitLab är en webbtjänst som bygger på Git, och erbjuder extra funktionalitet. Den har inne-håller bland annat ett grafiskt gränssnitt för att använda olika funktioner i Git och hantera filer i projektet. [79]
2.3. Testramverk
Det finns dessutom funktionalitet för så kallade pipelines. En pipeline är en procedur som utförs varje gång en förändring skickas till filsystemet. Pipelines kan exempelvis automa-tiskt konfigurera och bygga kod i projekt och köra enhetstester och integrationstester för att automatisera testningen och minska förekomsten av felaktig kod i sparade filsystem. [35]
2.3
Testramverk
För att testa den kod som skrev under projektet användes i huvudsak två testramverk, Google test och Jest. Dessa två ramverk kan bland annat användas för enhetstester.
2.3.1
Google test
Google test är ett testramverk för C++ utvecklat av Google. Det kan användas för att utföra en mängd olika tester och har stöd för Windows, Mac, och Linux. [34]
2.3.2
Jest
Jest är ett testramverk för JavaScript. Det kan bland annat användas för att testa projekt som använder React och Node.js. [30]
2.4
Arbetsmetod
Den arbetsmetod som användes i projektet var Scrum, vilken beskrivs i kommande avsnitt. Som en del av arbetsmetoden användes även Jira och Slack för hantering av arbetsuppgifter respektive kommunikation inom gruppen. Dessa beskrivs också i kommande avsnitt.
2.4.1
Scrum
Scrum är en agil arbetsmetod som kännetecknas av ett antal särskilda händelser och hjälpme-del. Händelserna är sprint, sprint planning, daily meeting, sprint review och sprint retrospective. Dessa beskriver tillsammans hur arbetsmetoden utförs. En sprint är en upprepande period vars längd kan variera mellan 7 till 30 dagar där utveckling av produkten sker. Varje sprint börjar med en planering i form av sprint planning och avlutas med en sprint review och sprint retrospective där sprinten utvärderas och med- och motgångar diskuteras.
Daily meeting är ett möte där dagar planeras utifrån en sprint backlog, ett av de viktiga hjälpmedlen i Scrum. I den beskrivs vilka uppgifter som ska utföras under sprinten. Sprint backlogen tas fram utifrån en product backlog som är en lista på alla egenskaper som behövs i produkten.
Arbetsmetoden bygger också till stor del på konceptet increment, vilket innebär att man börjar om vid varje sprint och utvecklar nya funktioner från produkt backlog och förbättrar de funktioner som redan finns. [90]
2.4.2
Slack
Slack är en webbaserad kommunikationsplattform framtagen för projektgrupper. Kommu-nikationen delas upp i kanaler med en eller flera medlemmar. I kanaler kan meddelanden innehålla både text och dokumentfiler. När ett meddelande har skickats kan en kanalmedlem välja att skapa en så kallad tråd. Tråden är vad som kan liknas en under-kanal, och är bunden till det specifika meddelandet. Där kan medlemmar diskutera och förmedla information som är relaterat till meddelandet. [69]
2.4. Arbetsmetod
2.4.3
Jira Software
Jira Software är ett webbaserat projekthanteringsverktyg. Verktyget är huvudsakligen till för agila projekt och har stöd för både Kanbantavlor och Scrumtavlor vilket är olika tavlor för att hantera product backlogs. På dessa kan projektmedlemmarna skapa och ta på sig uppgifter som ska utföras. Scrumtavlor och Kanbantavlor är ganska lika men Scrumtavlor är något mer utförligare och tar därför längre tid att sätta upp jämfört med Kanbantavlor [83]. Projektmed-lemmar kan använda verktyget för att fördela uppgifterna och för att tidrapportera för de utförda uppgifterna. [31]
3
Metod
För att besvara frågeställningarna för detta projekt använde sig gruppen av ett antal olika metoder. Många erfarenheter samlades in via en enkät i slutet av projektet tillsammans med kontinuerliga möten där erfarenheter samlades in. Gruppen skrev också ett antal dokument i syfte att kunna använda dessa vid utvecklingen av produkten.
3.1
Metod för att fånga erfarenheter
För att fånga gruppmedlemmarnas erfarenheter hade gruppen ett möte i slutet av varje vec-ka där varje gruppmedlem fick säga vad de gjort under vecvec-kan och vad som varit svårt med det de gjort. Dessa erfarenheter diskuterades och dokumenterades. I slutet av projektet sam-manställdes de i ett dokument. Detta dokument användes som underlag för att presentera vilka erfarenheter gruppmedlemmarna fått, där varje gruppmedlem fick utveckla vad deras dokumenterade erfarenheter betydde.
3.2
Enkät
I slutet av projektet deltog gruppmedlemmarna i en datainsamling i form av en kvalitativ enkät som var till för att samla erfarenheter och på så sätt besvara frågeställningar om syste-manatomi, erfarenheter och kodgranskning. Frågorna och uppgifterna var följande:
• Vilket stöd har du fått från att skapa och följa upp systemanatomin? • Hur har du upplevt att kodgranskningen har fungerat?
• Beskriv dina erfarenheter kopplat till projektets arbetsmetod som till exempel Scrum, Kanban mm.
• Beskriv dina erfarenheter kopplat till projektets val och användning av utvecklings-verktygen som till exempel VS Code, Npm, Git mm.
• Beskriv dina erfarenheter kopplat till projektgruppen som till exempel samarbete, roller, möte mm.
3.3. Utvecklingsmetodik
• Beskriv dina erfarenheter kopplat till implementeringen av produkten som till exempel Full Stack, React, C++ mm.
• Beskriv dina erfarenheter kopplat till gruppens användning av dokument.
3.3
Utvecklingsmetodik
Nedan beskrivs de utvecklingsmetoder som användes under projektet. Det beskrivs vad var-je dokument hade för syfte, vilka roller som fanns i gruppen, hur gruppen skötte versions-hantering och kodgranskning samt en beskrivning av hur gruppen arbetade efter metoden Scrum.
3.3.1
Förstudie
För att strukturera projektet utfördes först en förstudie innan utvecklingen av systemet på-börjades. Under denna period studerade gruppmedlemmarna olika delar som de kunde tän-kas behöva ha kännedom om under utvecklingen. Då systemet bestod av en mängd olika tekniker, blev dessa olika arbetsområden som fördelades mellan gruppmedlemmarna. Ar-betsområdena var följande:
• GUI • Replayspelare • Klient • Rankingsystem • Datahantering • Spelmotor • Spel och agenter • Server
• Säkerhet • Tester
3.3.2
Dokument
Under förstudien påbörjade gruppen ett antal dokument som under de olika iterationerna uppdaterades och utökades. Ansvaret att skriva dessa dokument fördelades i gruppen och denna fördelning kan ses i tabell 3.1. Detta betydde inte att den ansvariga personen skulle skriva dokumentet själv men denna hade ansvar att det skulle bli klart till inlämningsdatum. Dokumenten skrevs för att hjälpa gruppen under utvecklingen av systemet.
Tabell 3.1: Ansvarsfördelning av dokument mellan roller.
Dokumentnamn Ansvarig (roll)
Projektplan Teamledare
Kravspecifikation Analysansvarig Arkitekturdokument Arkitekt
3.3. Utvecklingsmetodik
Gruppkontrakt För att definiera grundläggande regler för projektets arbete skrev projekt-medlemmarna ett gruppkontrakt. Första gruppkontraktet skapades på ett möte där en majo-ritet av projektmedlemmarna var närvarande. Gruppkontraktet uppdaterades sedan under projektets gång när det var nödvändigt.
Kundkontrakt Innan projektet startade skrevs ett kontrakt mellan kunden och projektgrup-pen. I kontraktet bestämdes tiden gruppen skulle arbeta och att arbetet inte involverade eko-nomiskt utbyte mellan parterna.
Projektplan En projektplan togs fram för att definiera hur arbetet skulle gå till under pro-jektets gång, samt vilka roller som gruppmedlemmarna skulle ha. Mål och tidsbegränsningar som fanns under projektet beskrevs också i projektplanen.
Kvalitetsplan En kvalitetsplan togs fram för att säkra kvaliteten av produkten. I den be-skrevs vad som skulle göras för att hela tiden förbättra kvaliteten på projektet. I dokumentet beskrevs också standarder för dokumentation av kod samt hur de olika handlingarna hjälpte till att främja god kvalitet.
Kravspecifikation För att definiera de krav som kunden ställde på produkten utformades en kravspecifikation genom en dialog mellan analysansvarig och kund. Analysansvarig såg till att tolka kundens behov för att utforma dokumentet. Kravspecifikation beskrev vilka krav som fanns och vilka som skulle prioriteras under iterationerna.
Arkitekturplan Dokumentet utformades för att ge en detaljerad beskrivning av systemet. Språkstandarder och systemrelationer definierades i detta dokument, tillsammans med en djupdykning i systemets komponenter. Den innehöll även en motivering till de val som har gjorts gällande ramverk och språk etc.
Systemanatomi En systemanatomi användes för att identifiera vilka komponenter som var nödvändiga för projektet. För att utveckla systemanatomin började projektmedlemmarna med att individuellt identifiera olika funktioner och komponenter, vilka sedan knöts ihop med flera beroenden vilka identifierades vid ett möte med hela gruppen. Systemanatomin användes sedan vid planering som stöd för att identifiera beroenden för att se vad som skul-le göras nästkommande iteration.
3.3.3
Arbetsmetod
Under utvecklingen arbetade gruppen enligt metoden Scrum. Där strukturerades arbetet i sprintar om 2 veckor var. I denna metod agerade utvecklingsledaren som Scrummaster och analysansvarig agerade som produktägare. Detta innebar att utvecklingsledaren hade ett övergripande ansvar att ta fram uppgifter till varje iteration från en product backlog i Jira och att analysansvarig hade ansvar för att dessa uppgifter representerade kundens behov. Gruppen hade däremot själva ansvar att välja vad de skulle göra under sprintarna så länge de valde från sprint backlogen. Gruppen använde sig av en Kanbantavla i Jira där de kunde spåra alla uppgifter, och denna kan ses i figur 3.1 När en gruppmedlem valde att påbörja en uppgift så tilldelade den gruppmedlemmen uppgiften till sig och placerade uppgiften i In progress-kolumnen på Kanbantavlan. Om denna uppgift i ett senare skede inte kunde slut-föras på grund av en annan uppgift kunde gruppmedlemmen placera uppgiften i Blocked. När en uppgift var klar placerades denna i kolumnen Review. Detta betydde att någon annan skulle granska lösningen av uppgiften. Det var då Scrummasterns uppgift att tilldela vem som skulle granska uppgiften. När lösningen var granskad och godkänd placerades upp-giften i kolumnen Done på Kanbantavlan. I slutet av varje iteration utgjorde alla uppgifter i kolumnen Done en så kallad release och togs bort från Kanbantavlan.
3.3. Utvecklingsmetodik
Kanban board KAN board
QUICK FILTERS: Only My Issues Recently Updated
KAN-27 Replayspelare KAN-30 Start/Stop/Paus KAN-31 Trackbar KAN-29 Text-Frames KAN-28 Canvas-Frames KAN-41 GUI KAN-43 Översiktliga skisser KAN-46 Server KAN-69 Kommunikation databas KAN-49 Kommunikation frontend KAN-58 Ranking KAN-59 Utvärdera Rankingsystem KAN-60 Säkerhet KAN-61 Identifiera säkerhetshot KAN-62 Säkra lösningar KAN-21 Databas KAN-88
Skapa procedures för databas
KAN-34 Spelmotor KAN-87 loggsparare KAN-46 Server KAN-70 Kommunikation spelmotor KAN-56 Övergripande struktur KAN-67 Testplan KAN-68 Testpipeline KAN-81 gtest KAN-91 Dokumentation KAN-45 Frontend KAN-86 Spelsida KAN-85 skapa speluppladdning KAN-57 IPC KAN-54
Skapa säker exekveringsmiljö för agenter
We're only showing recently modified issues. Looking for an older issue?
10Selected for Development 8In Progress 0Blocked 3Review 0 of 7Done Release…
Figur 3.1: Bild över projektets Kanbantavla i Jira.
3.3.4
Versionshantering
Koden som skrevs under utvecklingen av produkten versionshanterades i Git på IDAs Git-Labserver. Strukturen bestod av tre huvudgrenar med en för dokument kallad document, en för utveckling kallad development och en för färdiga versioner av systemet kallad master. När en gruppmedlem skulle bidra till systemet och hade valt en uppgift från sprint backlogen så skapade medlemmen en gren från development för just den uppgiften. När uppgiften var klar gjordes en merge request mot development. Denna merge request granskades av en an-nan gruppmedlem och sammanfogades in i development när den blev godkänd.
3.3.5
Kodgranskning
När ändringar av systemet skulle granskas tilldelades en av de personer som inte stod för ändringen uppdraget att granska ändringen. Genom att ändringarna lades till som en merge request till developmentgrenen och genom att använda GitLab kunde den som granskade lätt se vad som hade ändrats och kommentera direkt i koden ifall eventuella problem hittades. Syftet med detta var att underlätta för den som gjort ändringen att förstå kommentaren.
3.3.6
Utvecklingsverktyg
För att utveckla produkten valde gruppen att använda editorn Visual Studio Code då den kan utökas med tillägg för att stödja alla språk gruppen skulle skriva i. Gruppen valde att använda ett tillägg, VS Live Share, som gjorde det möjligt för gruppmedlemmarna att skriva i filer samtidigt med realtidsuppdateringar. Orsaken till detta var att det underlättade när gruppen satt tillsammans och skrev i samma filer. [52]
3.3.7
Grupproller
För att organisera arbetet fördelades ett antal olika ansvarsroller mellan gruppmedlemmarna vid starten av projektet. Varje person fick ange vilken roll de föredrog och sedan fördelades dessa på ett demokratiskt vis. De olika rollerna beskrivs nedan.
3.3. Utvecklingsmetodik
Teamledare Teamledaren ansvarade för att målen blev uppfyllda. Detta innebar bland an-nat att sammanfatta veckornas arbeten till veckorapporter. Den hade även ansvar att se till att projektplan och gruppkontrakt följdes och att veckoliga möten hölls. Den huvudsakliga kom-munikationen med handledare och examinator gick via teamleadaren, som sedan förmedlade detta till gruppen. Under handledarmötet förde teamleadaren den bestämda agendan under mötet. Slutligen hade teamleadaren också som ansvar att agera som coach för övriga teamet med sista ordet i beslut.
Analysansvarig Analysansvarig hanterade all kommunikation med kunden och hade som uppgift att förstå kundens verkliga behov och sedan se till att dessa förmedlades till resten av gruppen. Den hade också som uppgift att förhandla åt gruppen med kunden om produkten. Analysansvarig ansvarade för att kravspecifikationen blev färdigställd i tid, att den följde IEEE Std 830-1998 [40] och att kraven i den var lättförstådda, välformulerade och uppfyllde kundens behov. På Scrummöten agerade analysansvarig som produktägare.
Arkitekt Arkitekten ansvarade för att ta fram en övergripande struktur över hur systemet skulle se ut, i syfte att denna skulle kunna användas för att leda gruppen i utvecklingen. Den hade också som uppgift att ta designbeslut och val om tekniker som gruppen skulle använda. Arkitekten hade också ansvaret för arkitekturdokumentet där resultatet från de föregående uppgifterna presenterades.
Utvecklingsledare Utvecklingsledaren hade det övergripande ansvaret för hur arbetet för-delades och utfördes, och såg till att rätt uppgifter prioriterades. Utvecklingsledaren ledde alla Scrummöten som hölls efter varje sprint, och hjälpte till att organisera testerna tillsam-mans med testledaren under tiden denna medlem fortfarande var aktiv i projektet. Det var även utvecklingsledaren som hade största ansvaret för att välja vilka uppgifter som skulle flyttas från product backlog till sprint backlog för nästkommande sprintar.
Kvalitetssamordnare Kvalitetssamordnarens huvudsakliga uppgift var att försäkra kvali-tet för både projekkvali-tets produkt och organisation. Detta innefattade dels att skapa en kvalikvali-tets- kvalitets-plan tillsammans med övriga gruppmedlemmar för att skapa en struktur över hur kvalitet skulle hanteras i projektet. När kvalitetsplanen var färdigställd var det kvalitetssamordna-rens ansvar att se till att processer och aktiviteter i kvalitetsplanen följdes.
Dokumentansvarig Dokumentansvarig såg till att dokument skrevs i tid. Denna styrde även över utseendet på dokumenten genom att skapa dokumentmallar och välja i vilken miljö dokumenten skulle skrivas i.
Konfigurationsansvarig Konfigurationsansvarig ansvarade för att ha hand om versions-hanteringsprocessen genom att sätta upp grenstrukturen och ge resten av gruppen anvisning-ar om hur de skulle använda den. Den bestämde även vilka produkter som skulle versions-hanteras. När en färdig version av systemet skulle släppas var det konfigurationsansvarig som valde vad som skulle ingå i den versionen.
4
Resultat
I detta kapitel presenteras de resultat som gruppen kunde framställa med hjälp av de tidigare beskrivna metoderna. Mycket resultat presenteras kring de erfarenheter som gruppen fått under projektet och hur produkten kunde utvecklas så att ett värde skapades för kunden. I slutet av kapitlet ges en sammanfattning av alla de individuella bidragen.
4.1
Erfarenhetsenkät
I detta avsnitt presenteras de erfarenheter som kunde fångas med hjälp av den enkät som gruppen tog del av i slutet av projektet. I enkäten fick medlemmarna berätta om sina åsikter för olika delar av projektet såsom hur bra systemanatomin fungerade som verktyg, hur de tycker kodgranskning har fungerat och hur de tyckte att samarbete i gruppen har fungerat och så vidare.
4.1.1
Systemanatomi
Ett fåtal av gruppmedlemmarna ansåg att skapandet av systemanatomin hade givit dem stöd eftersom att det gav dem en översikt av produkten. Andra ansåg att de inte hade fått något stöd från att skapa systemanatomin. Samtliga gruppmedlemmar nämner att då systemana-tomin inte följdes upp under resten av projektet hade ingen fått något ytterligare stöd från systemanatomin.
Ett fåtal ansåg att om gruppen följt upp systemanatomin bättre hade det kunnat hjälpa dem under projektet. En gruppmedlem ansåg att andra dokument som arkitekturdokumen-tet gjorde systemanatomin överflödig och att en uppföljning av systemanatomin inte hade givit något stöd. Den resulterande systemanatomin visas i figur 4.1.
4.1.2
Kodgranskning
Överlag tyckte gruppen att kodgranskningsmetoden fungerade bra då alla följde reglerna som gruppen formulerade kring kodgranskning och koden blev noggrant granskad. En per-son nämnde att en positiv aspekt med att endast gruppmedlemmar med kunskap om koden fick granska den var att det blev lätt att tilldela granskningsuppdraget och att koden granska-des ingående. Två personer upplevde dock ändå att de behövde sätta sig in ytterligare vid
4.1. Erfarenhetsenkät Serverhårdvara Databas Server Spelobjekt Spelmotor IPC Agentobjekt Utmana agent Replay-/logg-sparare Server-klient-kommunikation Kodkontroll Kompilator Agent-övervakning Spelhantering Lagra användare Rankingsystem Spela med agent
Användarhantering Autentisering
Logga in
Söka efter agent Ladda upp agent
Figur 4.1: Systemanatomin som togs fram för produkten.
granskningen, och hade olika syn på detta. Den ena personen tyckte att det var svårt och den andra menar att det var bra då den fick tillägna sig mer kunskap. Många ansåg att när an-talet som kunde granska en viss del begränsades av gruppmedlemmarnas arbetsområde så tog granskningen för lång tid, vilket bromsade utvecklingen. Vid projektets start var tanken att varje merge request skulle granskas av minst två personer som ej skrivit koden, och en person tyckte det var synd att gruppen gick ifrån den principen. Personen trodde att detta bidrog till sämre kodkvalitet. En person tyckte att funktionerna kopplade till kommentering och diskussion av merge requests som tillhandahålls av GitLab var bra.
4.1.3
Arbetsmetoder
Alla gruppmedlemmar var överens om att gruppen successivt slutade följa den bestämda ar-betsmetod som specificerades i början av projektet och att gruppen inte hade följt upp Scrum-metoden tillräckligt. Enligt en gruppmedlem så började till exempel fler och fler gruppmed-lemmarna sluta använda Kanbantavlan under projektet. En ansåg att detta berodde på att gruppen använde Kanbantavlan på ett felaktigt sätt då många uppgifter som hamnade där inte behandlades som iterativa trots att de var det, till exempel dokument.
4.2. Dokumenterade erfarenheter
4.1.4
Utvecklingsverktyg
Hela gruppen ansåg att valet att använda VS Code, Npm och Git varit bra då användningen av dem inte hade lett till några större problem. Till exempel har en majoritet av gruppen uppskattat de många tillägg som fanns för VS Code som till exempel VS Live Share, Rewrap för automatisk radbrytning och typsättningssystemet LaTeX som användes vid skrivandet av denna rapport, eftersom de uppfattades som att de gjorde utvecklingen smidigare. En medlem nämnde även att Npm varit lätt att använda tack vare dess enkla kommandon. För vissa medförde Git vissa svårigheter, en medlem ansåg att detta oftast berodde på okunskap.
4.1.5
Samarbete och roller
Överlag ansåg gruppmedlemmarna att samarbetet i gruppen hade fungerat bra. En medlem nämnde dock vissa situationer där någon tagit en annans uppgift eller att två har jobbat på samma uppgift utan att veta det på grund av kommunikationsproblem.
Alla var överens om att samarbetet fungerade bra eftersom gruppen träffats ofta under projektet och då kunnat diskutera med varandra, dock var det en medlem som ansåg att det blivit för många möten och att det tog för mycket tid från att implementera produkten.
4.1.6
Implementation
Hela gruppen tyckte att React, Node.js och C++ har varit bra val då de gått bra att använda för implementationen av produkten. En medlem som utvecklat i PostgreSQL tyckte inte att det var ett bra val då det medförde mycket problematik med konfigurationer på olika enheter och ingen i gruppen var van vid syntaxen i PostgreSQL. Därför tyckte medlemmen att MySQL hade varit ett bättre val då gruppen hade kompetens inom det.
Då produkten utvecklades till Linux hade det varit svårt för en gruppmedlem att utveckla produkten på Windows trots hjälp av WSL eller en virtuell dator med Linux. Gruppmedlem-men trodde dock att det hade kunnat bli lättare om produkten utvecklats med detta i åtanke, dock nämnde den att det hade varit slöseri med tid.
4.1.7
Dokumentation
Alla i gruppen tyckte att dokumenten gav projektet en bra start. Några ansåg att de kunde fått stöd av dem senare i projektet också, ifall gruppen hade följt upp dem bättre. Andra ansåg att dokumenten inte var så nödvändiga i ett litet projekt som detta och att det endast tog tid från resten av projektet. En tyckte att det lades för mycket tid på dokumenten i början och att detta var ineffektivt då projektet var agilt och dokumenten ändå krävde modifikationer i senare iterationer.
4.2
Dokumenterade erfarenheter
Alla dokumenterade erfarenheter hade med implementationen av produkten att göra ef-tersom det var detta gruppmedlemmarna huvudsakligen diskuterade på veckomöten.
• Att utveckla till Linux på Windows med WSL har krånglat ibland och inte fungerat som på Linux.
• PostgreSQL har varit svårt att konfigurera då det finns många versioner och det är otydligt vilken som ska användas.
• Det har varit svårt att testa vissa komponenter i React på grund av högre ordningens komponenter och att det är svårt att få tag på komponenters tillstånd när de har en övre komponent.
4.3. System
• Det är bra att jobba tillsammans i början av projektet då vissa personer kan ha mer för-kunskaper än andra inom särskilda områden och då dela med sig av de för-kunskaperna. • Det kan vara bättre att implementera funktioner på ett enkelt sätt som kräver mycket
kod än att direkt försöka använda ett svårt bibliotek som gör mer än vad som behövs och tar tid att förstå.
• Det kan vara svårt att skapa en bra struktur i C++ för att undvika cirkulära importer till exempel på grund av friend classes.
• I ett system finns det ibland funktioner som skapar data och funktioner som använder den. Vid sådana situationer upplevdes det smidigare att implementera funktioner som använder denna data innan funktioner som skapar den.
4.3
System
Det implementerade systemet består av fyra huvudsakliga moduler: klient, server, databas och spelmotor. Se figur 4.2 för övergripande kommunikation mellan modulerna.
Klient
Server
Spelmotor Databas
Figur 4.2: Diagram på den övergripande kommunikationen mellan de utvecklade modulerna.
4.3.1
Klient
Klienten är en webbapplikation som kan köras på de flesta moderna webbläsare. Modulens funktionalitet är implementerad i React och dess visuella komponenter är gjorda med hjälp av Material UI.
Förstasidan är välkomstsidan i figur 4.3. Knappen ”Get started” tar användaren vidare till inloggningssidan, se bild 4.4.
Inloggningssidan är en sida användaren kommer till om den försöker ta sig till sidor som kräver autentisering och användaren inte är autentiserad. Det är ett enkelt inloggningsfor-mulär som autentiserar användaren. Create account knappen gör i den slutgiltiga produkten
4.3. System
Wecome to Botify™!
GET STARTED
Figur 4.3: Bild på välkomstsidan.
Please login or create an account
Login
LiU-ID *
Password *
LOGIN
CREATE ACCOUNT
Figur 4.4: Bild på inloggningssidan.
ingenting. Kunden kommer dock i framtiden ersätta denna sida med ett eget inloggningssy-stem och därmed prioriterades den inte.
Efter att användaren har loggat in tas den till hemsidan. Den sidan innehåller två kompo-nenter, den ena som är ett formulär för att ladda upp ett spel till plattformen och den andra är en lista med alla spel i plattformen, se bild 4.5.
Om användaren klickar på en knapp under ett spels namn så tas den till det spelets sida. Spelsidan innehåller tre komponenter. Den första komponenten ger användaren möjlighet att ladda upp en agent till spelet om användaren inte redan laddat upp någon, se bild 4.6 eller ersätta sin befintliga agent och starta en spelomgång mot andra agenter, se bild 4.7. Den andra komponenten är en manual till spelet som användaren kan använda för att skapa en agent till spelet. Den tredje komponenten är en rankinglista av agenterna för det givna spelet.
4.3. System
Home Page
Create game
no file selected
Your games
Tic Tac Toe
Bomberman
CHOOSE FILE UPLOAD PLAY GAME PLAY GAME Title Teaser description Course code Game manualFigur 4.5: Bild på hemsidan.
Tic Tac Toe
A really simple game
Upload bot no file selected Game manual En del text. Leaderboard # 1: Bot 1 # 2: Bot 2 # 3: Bot 3 # 4: Bot 4 # 5: Bot 5 # 6: Bot 6 # 7: Bot 7 CHOOSE FILE SUBMIT
4.3. System
Tic Tac Toe
A really simple game
Play this game against other bots
Game manual En del text. Leaderboard # 1: Bot 1 # 2: Bot 2 # 3: Bot 3 # 4: Bot 4 # 5: Bot 5 # 6: Bot 6 # 7: Bot 7 Opponent 1 * Opponent 2 * Opponent 3 * Opponent 4 * FIGHT UPLOAD NEW BOT
Figur 4.7: Bild på spelsida med en uppladdad agent.
Replay
Play Skip tostart
Terminal GAME: You are X
IN: {'board': [' ',' ',' ',' ',' ',' ',' ',' ',' '], 'player': x}
OUT: {'move': 5}
ERROR: Life is hard
IN: {'board': [' ',' ',' ',' ',' ','x',' ','o',' '], 'player': x}
OUT: {'move': 3}
IN: {'board': [' ',' ',' ','x','o','x',' ','o',' '], 'player': x}
OUT: {'move': 1}
IN: {'board': [' ','x','o','x','o','x',' ','o',' '], 'player': x}
LOG: Making a hard decision
OUT: {'move': 0}
GAME: You lost
Figur 4.8: Bild på sidan för att spela upp en spelomgång.
Om användaren startar ett spel mot andra agenter förflyttas den sedan till en sida där den kan ta del av spelomgången, se bild 4.8. Denna sida har en komponent som visar upp spelomgången grafiskt som en video med en tidsaxel och kontrollknappar. Sidan har även ett textfönster där meddelanden mellan spel och agent spelas upp tillsammans med dess grafiska visualisering.
4.3.2
Server
Servern hanterar användarens interaktioner med applikationen. När en användare skickar förfrågningar och ny data, hanteras detta av servern. Modulen är implementerad i Node.js med ramverket Express.js.
När data ska sparas eller hämtas anropas servern, som i sin tur anropar procedurer defi-nierade i databasen.
4.3. System
När användaren väljer att spela ett spel, skapar servern en spelprocess som kör igenom spelet. När spelet sedan kört klart lagras data från det i databasen.
När spel eller agenter laddas upp till plattformen är tanken att servern ska kompilera koden (undantag för interpreterande språk som till exempel Python) och spara binärerna. Detta är dock ej implementerat i slutprodukten på grund av tidsbrist.
4.3.3
Spelmotor
Spelmotorn är ett bibliotek skrivet i C++ som används för att skapa nya spel till systemet. Bib-lioteket erbjuder abstrakta objekt för spel och spelobjekt, se figur 4.9. Dessa klasser innehåller funktioner för att kommunicera med agenter, starta agenter och spara ner information från spelomgången. Funktionerna är konstruerade på ett sätt som tillåter att agenter är skrivna i flera olika språk. Sammanfattningsvis innehåller modulen all funktionalitet som krävs för att skapa och integrera ett spel i systemet. För att skapa ett spel skapas ett objekt som ärver från den abstrakta klassen Game och implementerar de virtuella funktioner som kallas under spe-lets liv med egen spellogik, se figur 4.10. Spelet sparar under spelomgången ner information om den med hjälp av spelobjekt för att plattformen senare skulle kunna visa spelomgång-en grafiskt på klispelomgång-entspelomgång-en. En logg med kommunikation mellan spel och agspelomgång-ent, meddelandspelomgång-en agenten vill spara och eventuella felmeddelanden från spelomgången sparas också av spelet.
SubProgramController + subprograms: map<int, SubProgram*> Replay
+ game_objects: map<unsigned int, GameObject*> + replay: json Image Rectangle «abstract» GameObject «abstract» DrawObject Log + log: json SubProgram «abstract» Game + logger: Log + replay: Replay + controller: SubProgramController + on_begin(): virtual void + on_turn(int): virtual json + on_move(int, json): virtual void + on_step(): virtual void + on_end(): virtual void
4.3. System
start on_begin on_turn on_move on_step on_end
Figur 4.10: Flödesschema över ett spels livscykel.
4.3.4
Databas
Databasmodulen är byggd i PostgreSQL. Modulen kan ta emot data och sedan spara den i systemets sekundärminne för att inte förlora den mellan exekveringar. I databasen finns ta-beller för den data som är nödvändig för applikationen, såsom användare, spel, agenter och spelhistorik. För att koppla samman data används relationer, se ER-diagram i figur 4.11. Da-tabasen innehåller procedurer som kan anropas för att spara eller hämta data från daDa-tabasen.
user id username email startyear password game course id name description manual code administrator N 1 bot code rank id for created N 1 N 1 student d course_admin U U program Replay History Competed log 1 N Has N 1 id
4.4. Översikt över individuella bidrag
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 negaposi-tiva konsekvenser. Dels skulle det kunna ge duktiga studenter extra moposi-tivation 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.
