Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2021 | LIU-IDA/LITH-EX-G--21/028--SE
Tävlingssystem för Teknikåttan
Competition system for Teknikåttan
–
A quiz based live competition system with multiple synchronised
views and an editor
Albin Henriksson
Sebastian Karlsson
Victor Löfgren
Björn Modée
Josef Olsson
Max Rüdiger
Carl Schönfelder
Emil Wahlqvist
Handledare : Jonas Wallgren 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/. © Albin Henriksson Sebastian Karlsson Victor Löfgren Björn Modée Josef Olsson Max Rüdiger Carl Schönfelder Emil Wahlqvist
Sammanfattning
Denna rapport gjordes som en del av kursen TDDD96 och beskriver det arbete som gjorts åt Teknikåttan under våren 2021. Projektets mål var att skapa ett väldokumenterat tävlings-system som skulle vara lätt för andra att utöka vilket gruppen också lyckades med. Täv-lingssystemets syfte var att ge Teknikåttan ett modernt och användarvänligt sätt att ska-pa, administrera och köra sina tävlingar. Systemet konstruerades som en webbapplikation med databas, server och klient. Databasen och servern skrevs med programspråket Python och klienten med Typescript. De viktigaste biblioteken som användes var Flask för servern, SQLAlchemy för databasen samt React och Material-UI för klienten.
Författarens tack
Vi i projektgruppen vill ge ett stort tack till alla från Teknikåttan för att de gett oss möjligheten att kunna utföra detta projekt och för deras samarbete under projektets gång. Vi vill speci-ellt tacka Fredrik Löfgren och Peter Andersson som har varit väldigt tillgängliga för möten och lätta att resonera med. I tillägg till detta vill projektgruppen även tacka kursledningen, examinator Kristian Sandahl för det breda urval med projekt som fanns att välja mellan och handledare Jonas Wallgren som alltid gett bra och väldigt tydliga kommentarer på inlämna-de dokument. Vi vill tacka föregåeninlämna-de projektgruppen för att inlämna-de hjälpte oss med att komma igång med projektet och gav oss bra insikter om hur projektet fungerar. Vi vill slutligen ock-så tacka alla som tar sig tid att svara på stackoverflow.com. Utan deras svar hade detta projekt inte kommit alls lika långt.
Innehåll
Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller x Definitioner xi 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 1.5 Kontext . . . 2 2 Bakgrund 3 2.1 Systembeskrivning . . . 3 2.2 Tidigare system . . . 4 2.3 Projektgrupp . . . 4 3 Teori 5 3.1 Programspråk . . . 5 3.2 Bibliotek . . . 6 3.3 Utvecklingsverktyg . . . 7 3.4 Kommunikationsverktyg . . . 8 3.5 Dokumentationsverktyg . . . 9 3.6 Scrum . . . 9 4 Metod 11 4.1 Utvecklingsmetod . . . 11 4.2 Förstå kundens behov . . . 12 4.3 Riskhantering . . . 134.4 Metod för att fånga erfarenheter . . . 13
5 Resultat 14 5.1 Systembeskrivning . . . 14
5.2 Process- och produktkvalitetssäkring . . . 18
5.3 Gemensamma erfarenheter . . . 19
6 Diskussion 22
6.1 Resultat . . . 22
6.2 Använda verktyg . . . 25
6.3 Metod . . . 25
6.4 Arbetet i ett vidare sammanhang . . . 26
7 Slutsatser 28 7.1 Hur kan systemet implementeras så att man skapar värde för kunden? . . . 28
7.2 Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för framtida projekt? . . . 28
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 29
7.4 Hur kan man samarbeta med en kund för att prioritera krav? . . . 29
7.5 Hur kan ett mjukvarusystem utvecklas på bästa sätt för att underlätta framtida vidareutveckling? . . . 29
A Strukturering av CSS i React av Albin Henriksson 30 A.1 Inledning . . . 30 A.2 Bakgrund . . . 31 A.3 Teori . . . 31 A.4 Metod . . . 31 A.5 Resultat . . . 32 A.6 Diskussion . . . 34
A.7 Val av metod . . . 35
A.8 Slutsatser . . . 36
B Utbildning inom ett utvecklingsprojekt av Sebastian Karlsson 38 B.1 Inledning . . . 38 B.2 Bakgrund . . . 39 B.3 Teori . . . 40 B.4 Metod . . . 41 B.5 Resultat . . . 41 B.6 Diskussion . . . 48 B.7 Slutsatser . . . 50
C Resursanvändning i Git av Victor Löfgren 51 C.1 Inledning . . . 51 C.2 Bakgrund . . . 52 C.3 Teori . . . 53 C.4 Metod . . . 53 C.5 Resultat . . . 54 C.6 Diskussion . . . 57 C.7 Slutsatser . . . 60
D Tillståndshantering i React av Björn Modée 62 D.1 Inledning . . . 62 D.2 Bakgrund . . . 63 D.3 Teori . . . 63 D.4 Metod . . . 68 D.5 Resultat . . . 69 D.6 Diskussion . . . 70 D.7 Slutsatser . . . 71
E Programvara för kommunikation i mindre mjukvaruprojekt av Josef Olsson 72 E.1 Inledning . . . 72
E.2 Bakgrund . . . 72
E.3 Teori . . . 73
E.4 Metod . . . 74
E.5 Diskussion . . . 75
E.6 Slutsatser . . . 77
F Alternativa vägar till kunskap av Max Rüdiger 79 F.1 Inledning . . . 79 F.2 Bakgrund . . . 80 F.3 Teori . . . 80 F.4 Metod . . . 80 F.5 Resultat . . . 81 F.6 Diskussion . . . 82 F.7 Slutsatser . . . 82
G Relationen mellan prestanda och skalbarhet i SQLAlchemy av Carl Schönfelder 84 G.1 Inledning . . . 84 G.2 Bakgrund . . . 85 G.3 Teori . . . 85 G.4 Metod . . . 87 G.5 Resultat . . . 88 G.6 Diskussion . . . 88 G.7 Slutsatser . . . 89
H Att använda prototypning i mjukvaruprojekt av Emil Wahlqvist 90 H.1 Inledning . . . 90 H.2 Bakgrund . . . 91 H.3 Teori . . . 91 H.4 Metod . . . 92 H.5 Resultat . . . 92 H.6 Diskussion . . . 97 H.7 Slutsatser . . . 97 Litteratur 99
Figurer
5.1 Administratörsida under fliken tävlingshanterare som visar tidigare skapade
täv-lingar. . . 15
5.2 Tävlingsredigerare som visar en para ihop fråga på åskådarvyn på sida 3 med sidinställningar. . . 15
5.3 Operatörsvy. . . 16
5.4 Åskådarvy. . . 16
5.5 Tävlandevy. . . 17
5.6 Domarvy. . . 17
A.1 Andelen utvecklare i studien som använt respektive bibliotek . . . 32
A.2 Intresse i biblioteken från utvecklare i studien . . . 33
A.3 Standard syntax för Emotion . . . 34
A.4 Syntax i Emotion med @emotion/styled biblioteket . . . 34
B.1 Histogram för svar till enkätfråga 1 . . . 42
B.2 Histogram för svar till enkätfråga 2 . . . 42
B.3 Svar till enkätfråga 3 . . . 43
B.4 Svar till enkätfråga 5 . . . 43
B.5 Svar till enkätfråga 7 . . . 44
B.6 Svar till enkätfråga 8 . . . 44
B.7 Svar till enkätfråga 9 . . . 45
B.8 Svar till enkätfråga 4 . . . 46
B.9 Svar till enkätfråga 10 . . . 46
B.10 Svar till enkätfråga 11 . . . 47
C.1 Objektmodell i Git . . . 55
C.2 Olika sätt att införa ändringar från en gren till en annan . . . 57
D.1 Komponenter bygger upp en applikation . . . 64
D.2 Reactkomponenter . . . 65 D.3 Globalt State . . . 65 D.4 Redux lifecycle . . . 66 D.5 MobX lifecycle . . . 67 D.6 Exempel på Recoilstrukturen . . . 68 D.7 Inlärningskurva . . . 69
E.1 Grafer som visar nöjdhet per program och mötestyp . . . 78
G.1 Tillstånd i SQL . . . 86
G.2 Hur frågan ska presenteras i SQL . . . 87
G.3 Exempel objekt Competition har två relationer med ett djup på tre relationer . . . 87
H.1 En illustration av arbetsmetoden vattenfall . . . 94
H.3 Huruvida prototypning reducerar kostnaden vid utvecklingen av mjukvara . . . . 95 H.4 Huruvida prototypning reducerar varaktigheten av ett mjukvaruprojekt . . . 96
Tabeller
5.1 Kodmetriker av projektet . . . 19 C.1 Ordlista för Git . . . 52 D.1 Jämförelse av bibliotek . . . 70 E.1 Antal svarande, varians och medelvärde för olika program och mötestyper . . . . 76 E.2 Rangordning av program för olika mötestyper . . . 77
Definitioner
Frontend Presentationslagret i en applikation, alltså den del av ap-plikationen som användaren ser.
Backend Dataåtkomstlagret i en applikation, delen som kommuni-cerar med databasen och skapar ett gränssnitt som fron-tend kan använda för att ändra data i databasen.
Issue En liten arbetsdel som skall utföras. Används ofta i Scrum-sprints.
Scrum Agilt utvecklingssätt för att utveckla produkter. Baserat på sprints och en prioriterad lista av issues.
Webbläsare Ett program för att köra och rendera webbapplikationer. Google Chrome, Moxilla Firefox och Safari är exempel på dessa.
HTML HyperText Markup Language, ett programspråk designat för att visas på en webbläsare.
Kanban Metod för att visualisera framsteg i utvecklingen genom att skapa en tavla med saker som arbetas på.
Single-page-applikation Sida som laddas om och dynamiskt visar upp rätt infor-mation istället för att byta sida helt när url:en ändras.
Kund Aktören som beställer ett visst system eller produkt.
Teknikåttan En organisation som anordnar en årlig tävling med samma namn för åttondeklassare. Teknikåttan är kunden för detta projekt.
DOM Document Object Model, ett gränsnitt till webbsidor som ger programspråk möjligheten att dynamiskt läsa och uppdatera innehållet på sidan.
TCP Transmission Control Protocol, ett dataöverföringsproto-koll som används för huvuddelen av all kommunikation över internet.
SQL Structured Query Language, programspråk för att läsa och redigera data i en databas.
API Application Programming Interface, ett gränssnitt som möjliggör kommunikation mellan två program.
Plugin Ett tillägsprogram som inte körs fristående utan är ett tillägg i ett annat program för att lägga till nya funktioner.
LATEX Ett typsättningssystem, alltså ett system för
doku-menthantering.
HTTP Hyper Text Transfer Protocol, ett kommunikationsproto-koll för att överföra webbsidor på World Wide Web på in-ternet.
PowerPoint Presentationsprogram som är utvecklat av Microsoft.
1
Inledning
I denna del får läsaren en överblick över av vad projektet handlar om, hur det har utförts, varför det utfördes och var fokuset har varit. Här presenteras även de frågeställningar som diskuteras och besvaras i rapporten.
1.1
Motivering
Digitalisering blir mer och mer relevant i alla olika branscher och sammanhang. Teknikåttan är dock en tekniktävling som fortfarande använder sig av papper, pennor och ett omodernt digitalt system. Detta är motsägelsefullt och Teknikåttan vill spegla det centrala i tävlingen, det vill säga teknik, i hur tävlingen är uppbyggd och hur den genomförs. Teknikåttan vill även främja intresset för teknik, matematik och naturvetenskap hos unga. Arrangörernas mål är att visa att dessa ämnen förekommer i många olika sammanhang och även att visa att det är kul och viktigt. Ett annat syfte med tävlingen är att ge prov på ett alternativt sätt att lära sig.
1.2
Syfte
Syftet med rapporten är att kunna följa projektets tillvägagångssätt och tankegångarna som har utvecklats vid till exempel designval eller uppkomna konflikter. Detta kan ge inspiration till hur liknande lösningar kan appliceras på framtida projekt eller problem. Rapporten bidrar även med de erfarenheter som har erhållits under projektets gång vilket ger en förståelse för de val som har gjorts och vad som skulle kunna ha gjorts bättre. Detta kan handla om både tekniska delar och hur man samarbetar i en grupp eller med en kund. De individuella delarna av rapporten låter även läsaren följa diskussioner kring vissa intressanta aspekter av projektet som analyseras och värderas.
1.3
Frågeställningar
Ett delmål med denna rapport är att besvara följande frågeställningar: 1. Hur kan systemet implementeras så att man skapar värde för kunden?
1.4. Avgränsningar
2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan man samarbeta med en kund för att prioritera krav?
5. Hur kan ett mjukvarusystem utvecklas på bästa sätt för att underlätta framtida vidare-utveckling?
1.4
Avgränsningar
Projektets utförande avgränsas av vissa omständigheter. Dessa omständigheter påverkar å ena sidan utvecklandet av systemet och å andra sidan denna rapports innehåll. Systemets begränsningar inkluderar kundens krav och redan fattade designbeslut. Kravbilden som ar-betats fram tillsammans med kunden innefattade höga ambitioner vad gäller dokumentation och programvarans kvalitet. Detta innebär att mindre tid kan läggas på att implementera funktionalitet än vad som annars hade varit möjligt. De designbeslut som fattats innan pro-jektets start inkluderade att systemet måste kunna användas på olika sorters enheter och webbläsare, samt att systemet skulle vara webb-baserat. Detta beslut påverkar val av pro-gramspråk, ramverk och arkitektur, och kan därför ha en inverkan på behandlingen av frå-geställning 1.
Rapporten avgränsas även av projektets tidsbegränsning och av gruppens kompetens. Projektet är begränsat till 400 timmar per gruppmedlem. Dessa timmar ska delas upp på utveckling av systemet och skrivandet av denna rapport, varför rapportens behandling av frågeställningarna med nödvändighet måste bli mer kortfattad och mindre djupgående än om mer tid kunde användas. Vidare utgörs gruppen av studenter som endast har begränsad erfarenhet vad gäller kundkontakt och utveckling av större system. Frågeställning 3 och 4 kunde måhända ha analyserats bättre av en grupp med mer erfarenhet.
1.5
Kontext
Projektet utförs som en del av kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Lin-köpings universitet våren 2021. I och med att arbetet utförs relaterat till en universitetskurs så begränsas möjligheten till att öka tidsspannet som projektet utgör. Tiden disponeras även på ett flertal dokument, seminarier och föreläsningar vilket begränsar gruppens möjlighet att lägga fokus på utvecklingen av systemet. Gruppen utför även arbetet utan betalning och det finns en risk att gruppmedlemmarna inte har samma erfarenheter som anställda konsulter.
2
Bakgrund
Teknikåttan är en samarbetsorganisation mellan de främsta lärosätena i Sverige [1]. De arran-gerar varje år tävlingar för åttondeklassare i hela Sverige där de tävlande får engagera sig i naturvetenskapliga ämnen genom att svara på frågor. De klasser som presterar bäst kvalifice-rar sig sedan till riksfinalen. I riksfinalen sitter tre personer från varje klass i varsitt bås med en surfplatta där de måste svara på olika typer av frågor på tid. Förutom lagen ingår det domare som kan se vad lagen har svarat, en programledare som läser frågorna, en tävlingsoperatör som bestämmer vilket tävlingssida som ska visas och åskådare som tittar på.
2.1
Systembeskrivning
Kunden har beskrivit systemet de vill ha som en PowerPoint med extra funktionalitet. Det ska gå att lägga till tävlingar som är en uppsättning tävlingssidor med olika frågor. Det finns olika typer av frågor som måste stödjas, bland annat sant/falskt-frågor, flervalsfrågor och textfrågor. Dessa frågetyper måste hanteras på olika sätt då deltagarna matar in olika typer av svar och de visas upp på olika sätt. Förutom dessa frågetyper måste det även vara möjligt att skapa en tävlingssida som inte relaterar till en fråga som till exempel kan användas i pauser för information eller sponsormeddelanden.
Frågorna måste visas på olika sätt för operatören, publiken, deltagarna och domarna. Del-tagarna måste förutom att se frågan även kunna svara på den i sitt gränssnitt. Domarna ska kunna se det rätta svaret och vad deltagarna har svarat. Åskådarvyn som visas för publiken har ibland en kortare formulering av frågan med mindre detaljer än vad som syns i delta-garvyn. Operatörsvyn visar en sammanställning av alla vyer, och det är även från den vyn som man styr tävlingen genom att bland annat byta tävlingssida och starta tiden för frågor. Systemet som ska utvecklas måste klara av att hålla alla olika vyer synkroniserade och vara tillräckligt stabilt för att inte krascha mitt i en pågående tävling.
Det måste även gå att utföra allmänna administrativa uppdrag som till exempel att hante-ra användare, tävlingar, regioner och lag. Utökningar till denna systembeskrivning som faller utanför projektets ram är bland annat att kunna se statistik från tidigare tävlingar, att vissa typer av frågor ska automaträttas och att kunna använda speciella teman för olika tävlingar och regioner.
2.2. Tidigare system
2.2
Tidigare system
Två försök att realisera dessa krav har gjorts tidigare. Det ena av kunden och det andra av en tidigare studentgrupp i denna kurs.
2.2.1
Kundens befintliga system
Teknikåttan har redan ett i princip helt fungerade system för att lägga till tävlingar, skapa frågor och senare visa frågor för tävlande och publik. Det är bland annat tack vare detta system som projektgruppen har fått en tydlig bild av hur systemet ska fungera och vad det ska klara av. Problemet med detta system är enligt kunden att det inte är användarvänligt och svårt att vidareutveckla. De är speciellt missnöjda med hur krångligt det är att skapa nya frågor, vilket var en av anledningarna till att de ville ha ett nytt system.
2.2.2
System av en tidigare studentgrupp
Teknikåttan tog även hjälp av en tidigare studentgrupp från denna kurs för att utveckla sy-stemet [2]. Den största delen av projekttiden lades då på att utveckla ett bättre sätt att skapa frågor på, vilket enligt kunden blev enklare än tidigare. Problemet med detta system var dock att för mycket funktionalitet saknades för att Teknikåttan skulle kunna använda det. Ef-ter diskussion med några medlemmar från den tidigare gruppen bestämdes det att det skulle bli enklare att börja om med projektet än att fortsätta på deras. Av dem har projektgruppen även fått lärdomen att det är bättre att försöka få något som fungerar och som går att vida-reutveckla än att vara alltför ambitiösa från början. Detta hade en direkt påverkan på hur kraven togs fram och prioriterades med kunden.
2.3
Projektgrupp
Medlemmarna som ingick i projektet var totalt åtta stycken civilingenjörsstudenter varav sex studerade datateknik och två studerade mjukvaruteknik. Alla medlemmar hade tidigare erfa-renhet av att arbeta i grupp av denna storleksordning. Arbetserfaerfa-renheten skilde sig däremot inom gruppen då några hade haft tidigare jobb och sommarjobb, medan andra inte hade haft det. Ungefär hälften av gruppen hade någon form av tidigare erfarenhet av webbutveckling medan endast två hade arbetat med databaser tidigare.
3
Teori
I detta kapitel presenteras den teori som lägger grunden för resten av rapporten.
3.1
Programspråk
I detta avsnitt ges en beskrivning av de programspråk som användes under projektet.
3.1.1
JavaScript
JavaScript, ibland förkortat JS, är världens mest populära webbprogramspråk och används på 97% av de 10 miljoner mest trafikerade hemsidorna [3]. JavaScript är skapat för att skriva skript och är av hög abstraktionsnivå, vilket bland annat innebär att det erbjuder dynamisk typning. Det betyder att utvecklaren inte behöver definiera exempelvis variabler som speci-fika typer.
3.1.2
TypeScript
TypeScript är ett programspråk som har öppen källkod och bygger på det tidigare nämnda språket JavaScript. TypeScript inför statiska typ-definitioner som förser språket med ett sätt att beskriva objekt, ger bättre dokumentation och tillåter TypeScript att genomföra kodvali-dering [4].
TypeScript valdes som utvecklingsspråk till frontend-delen för dess stöd av typhantering till skillnad från JavaScript. TypeScript kan inte användas direkt i frontend, men med hjälp av en motor kommer alla TypeScript-filer automatiskt att kompileras till JavaScript-filer. Ty-peScripts typhantering gör det enklare att skriva självförklarande kod, och gör felsökning enklare.
3.1.3
Python
Python är ett populärt och enkelt programspråk som används inom matematik, mjukvaru-utveckling och webbmjukvaru-utveckling på serversidan [5]. Python valdes som programspråk på ser-versidan eftersom alla gruppmedlemmar hade erfarenhet av Python sedan tidigare kurser och projekt.
3.2. Bibliotek
3.2
Bibliotek
I detta kapitel beskrivs några av de bibliotek som har använts i projektet.
3.2.1
React
React är ett JavaScript-bibliotek som används för att bygga användargränsnitt för single-page-applikationer. React är komponentbaserat, alltså är det uppbyggt av flera delar som kan återanvändas på olika ställen, och har öppen källkod som underhålls av Facebook. React använder sig av en virtuell dokumentobjektmodell (DOM). Detta uppdaterar webbläsarens DOM mer effektivt än en traditionell DOM, så att utvecklaren kan skriva kod som om hela sidan renderas med varje ändring, men där DOM:en känner av vilka objekt som har ändrats och endast renderar om dessa [6]. Detta ger en snabbare och mer responsiv applikation.
React valdes som ramverk till webbapplikationen för att kunna ta inspiration av den förra utvecklingsgruppens komponenter, som använde React. Dessutom har React hög utbredning inom webbutveckling [7], så kundens önskemål om att systemet ska vara modernt vägde in i beslutet. Webbapplikationen ska utvecklas i TypeScript som en single-page-applikation vilket React hanterar väl.
3.2.2
Redux
Dan Abramov och Andrew Clark skapade Redux 2015 vilket är ett JavaScript-bibliotek som är gjort för att hantera tillstånd i en applikation [8]. Redux fungerar genom att ha ett globalt tillstånd som är tillgängligt i alla komponenter och det tillståndet uppdateras genom att ett ”event” skickar ”actions” som fångas upp av ”reducers” som sedan uppdaterar tillståndet [9]. Denna design gör att det blir väldigt lätt att dela information mellan olika komponenter och att få de komponenterna att renderas när informationen förändras. Detta är väldigt viktigt i denna applikation eftersom flera olika sidor ska hållas synkroniserade med rätt värden då en tävling körs.
3.2.3
NodeJS
NodeJS är ett asynkront exekveringsverktyg för JavaScript som används för att köra JavaScript-kod på en server för att sedan visa upp innehåll av webbsidor [10]. NodeJS an-vänds i projektet för att hantera bibliotek, bygga, testa och köra frontend-delarna. NodeJS sammankopplar alla utvecklingsfiler till en webbapplikation som sedan kan köras på en live-server där nya ändringar i koden automatiskt visas på hemsidan.
3.2.4
WebSocket
WebSockets är ett kommunikationsprotokoll som erbjuder simultan tvåvägskommunikation (full-duplex) över en enda TCP-koppling [11].
3.2.5
Socket.IO
Socket.IO möjliggör realtids-, tvåvägs- och eventbaserad kommunikation. Det fungerar på varje plattform, webbläsare och enhet samt fokuserar lika mycket på pålitlighet och snabbhet [12]. Det är en abstraktionsnivå över WebSockets, men kan använda sig av andra tekniker om WebSockets inte stöds, vilket gör det mer pålitligt.
Socket.IO används i projektet för att kommunicera med alla klienter och synkronisera nu-varande sida och tid för alla deltagare. Detta bibliotek valdes eftersom det är mycket vanligt, snabbt, pålitligt och enklare att använda än många andra liknande bibliotek.
3.3. Utvecklingsverktyg
3.2.6
Material-UI
Material-UI är världens populäraste UI-bibliotek för React och innehåller färdiga komponen-ter som följer Makomponen-terial Design [13]. Makomponen-terial-UI underlättar utvecklingsprocessen efkomponen-tersom utvecklaren inte behöver spendera tid på styling och design av egna komponenter.
Material-UI valdes till ramverk för frontend av flera skäl. Användarna av systemet kan inte förväntas ha teknisk utbildning utan är primärt lärare och elever, så det behöver vara enkelt att använda. Material-UI är även modernt och av industristandard, vilket ökar under-hållbarheten.
3.2.7
Flask
Flask är ett mikro-webramverk byggt i Python för snabba, mindre och pålitliga projekt. Med Flask byggs ett så kallad Rest-API som möjliggör kommunikation mellan frontend och bac-kend [14]. Ett Rest-API tilldelar till varje funktion hos applikationen en URL som klienten kan skicka anrop till och förvänta sig ett svar från. Särskilda anrop kräver att ett JWT-Token skickas med för att ge servern information om vem som är inloggad och vilka privilegier användaren har.
Flask valdes som det huvudsakliga ramverket på serversidan av projektet eftersom Flask är gjort för snabba pålitliga projekt som är av mindre skala. Då projektet kräver en snabb och pålitlig kommunikation under tävlingar gör det Flask till ett utmärkt val.
3.2.8
SQLAlchemy
SQLAlchemy är ett Python-verktyg för hantering av SQL. SQLAlchemy tillåter utvecklaren att skapa objektmodeller och databasscheman på ett enkelt och frikopplat sätt [15]. SQLAl-chemy gör det möjligt att utföra databasförfrågningar och skapa eller modifiera tabeller till en SQL-databas med hjälp av Python som genererar SQL-kod.
SQLAlchemy valdes för att underlätta relationen mellan Python och en SQL-databas. Ef-tersom hela servern är skriven i Python så integreras den väl med Flask och underlättar skapandet av tester för databasen. Andra fördelar med SQLAlchemy är felhantering med inbyggd säkerhet och kompatibilitet med alla industristandardversioner av SQL vilket ökar produktiviteten, säkerheten, flexibiliteten och underhållbarheten av projektet.
3.3
Utvecklingsverktyg
Här beskrivs de verktyg som har använts i utvecklingsprocessen.
3.3.1
GitLab
GitLab är en webbtjänst som använder versionshanteringssystemet Git. GitLab erbjuder an-vändarna att spara sina bidrag och ändringar de har gjort i en kodfil och ger en överblick över systemets status. GitLab erbjuder även verktyg för produktivitet och sociala interaktio-ner [16].
Det är industristandard att använda Git för versionshantering men att just GitLab använ-des beror huvudsakligen på att Linköpings universitet erbjuder den tjänsten i andra kurser. Det var därför naturligt att fortsätta använda GitLab istället för något av alternativen såsom GitHub.
3.3.2
Visual Studio Code
Visual Studio Code är en enkel och anpassningsbar kodredigerare utvecklad av Microsoft. Visual Studio Code har stöd för plugins och har inbyggd versionshantering [17].
3.4. Kommunikationsverktyg
Visual Studio Code valdes bland annat för de många plugins som finns och som har an-vänts flitigt av projektets medlemmar. Det finns syntaxmarkering, autokomplettering och möjligeht att låta flera personer skriva samtidigt i samma fil. Eftersom gruppen valt att an-vända sig av parprogrammering så är det sistnämnda något som är väldigt viktigt. Eftersom det i projektet används två programspråk så behövdes ett program som kunde hantera detta, och Visual Studio Code fungerar för många olika språk tack vare dess plugins.
3.3.3
Postman
Postman är en plattform för att snabbt och effektivt utveckla och skapa komplexa HTTP-förfrågningar som erbjuder utvecklarna ett sätt att organisera och dela dessa [18]. Tack vare detta är Postman ett väldigt bra verktyg för att testa funktionalitet hos ett API.
Postman användes i projektet för att se om det resulterande svaret av en API-förfrågning såg ut som förväntat eller inte. Vid mer komplicerat serverrelaterat arbete som exempelvis autentisering görs det inte bara snabbare, utan även enklare att se om svar på en förfrågan ser ut som det ska eller inte.
3.3.4
Figma
Figma är ett onlineverktyg för redigering av vektorgrafik. Figmas huvudsakliga funktion är att skapa prototyper för användargränsnitt med viss funktionalitet. Dessa prototyper kan redigeras samtidigt, i realtid, av flera användare och kan sedan sparas och delas vidare. [19]. Figma användes i början av projektet som en del av prototypbyggandet, efter att pappers-prototyper gjorts och diskuterats. Den funktionalitet som finns i Figma gjorde att gruppen och kunden hade möjlighet att interagera med prototypen för att bättre bilda sig en uppfatt-ning om hur produkten skulle se ut och fungera.
3.3.5
Draw.io
Draw.io är en applikation som kan användas för att skapa enkla diagram tillsammans med andra personer. Draw.io fungerar även med Google Drive vilket gör att det är speciellt lätt att dela med sig av diagrammen som skapas och arbeta tillsammans [20].
Draw.io användes främst i början av projektet för att kunna skapa ett tydligt flödeschema över hur systemet används. I tillägg till detta så användes Draw.io även för att skapa en modell över databasens struktur.
3.3.6
DB Browser for SQLite
SQLite är ett lättviktigt databashanteringssystem som ofta används vid utveckling. DB Brow-ser for SQLite är ett visuellt verktyg med öppen källkod som är till för att redigera och bläddra i databasfiler som använder sig av SQLite [21]. I utvecklingen av ett program som använder sig av en databas så är det nödvändigt att kunna se exakt vilken data som finns i databasen.
3.4
Kommunikationsverktyg
Här beskrivs de verktyg som har använts för att kommunicera inom gruppen, med handle-daren och med kunden.
3.4.1
Slack
Slack är en applikation som används för att skapa chattkanaler där gruppdeltagare kan kom-municera med varandra i text. Slack har till skillnad från andra kommunikationsapplikatio-ner inte fokuserat på röstkommunikation utan satsat mer på kommunikation via text. Med
3.5. Dokumentationsverktyg
anledning av denna satsning har Slack många funktioner som inte finns på alternativa platt-formar. Till exempel är det lätt att skapa trådar från meddelanden så att det går att samla en diskussion och undvika att den blir väldigt utspridd [22]. Slack har använts genom projektets gång för mer generell textbaserad kommunikation och diskussion om ämnen relaterade till projektet.
3.4.2
Discord
Discord är en applikation som är till för att skapa text- och röstkanaler där en grupp kan kommunicera med varandra via tal [23]. Discord är en relativt ny plattform som har blivit mer och mer populär tack vare sin goda ljudkvalitet och användarvänlighet. Discord har under projektet använts för vardaglig kommunikation och i parprogrammering. I viss mån har det även använts för gruppmöten men för möten har Microsoft Teams primärt använts.
3.4.3
Microsoft Teams
Microsoft Teams är ett verktyg som är utvecklat av Microsoft för att planera och utföra möten, videokonferenser och gruppchattar. Teams har även en samarbetsyta där det går att dela med sig av filer [24]. Microsoft Teams har använts för bokade möten och för att ha en mer formell plattform. Främst har Teams använts vid gruppens veckovisa status- och handledarmöten.
3.5
Dokumentationsverktyg
Här beskrivs ett antal verktyg som har använts för att generera dokumentation.
3.5.1
Sphinx
Sphinx är ett verktyg som används för att på ett enkelt och fint sätt skapa dokument uti-från kodkommentarer i Python. Utöver dokumentationen som skapas uti-från kommentarerna går det att inkludera Restructured text eller Markdown-filer för en komplett dokumentation. Dessa dokument kan fås i HTML, LATEX, ren text, eller andra format [25].
Sphinx har använts för att omvandla dokumentationen, som är skriven i Markdown, till HTML för att kunna lägga upp det på en webbsida. Med tydlig dokumentation i ett fint format kommer förhoppningsvis nästkommande grupper ha större möjlighet att förstå och vidareutveckla systemet.
3.5.2
Typedoc
Typedoc är en dokumentationsgenererare för TypeScript-kod som genererar dokumentation i antingen HTML eller JSON-format [26].
Typedoc har använts i projektet för att generera dokumentation för alla klasser och funk-tioner för koden på frontend. Även detta görs för att framtida grupper ska få bra möjligheter att vidareutveckla systemet.
3.5.3
Read the Docs
Read the Docs är en hemsida som automatiskt kan generera dokumentation från Sphinx och hysa denna [27]. Read the Docs används för att hysa den statiska sidan genererad av Sphinx. Denna sida länkas sedan till från kodförrådet i GitLab för att göra den lättåtkomling.
3.6
Scrum
Scrum är en arbetsmetodik som är väldigt populär inom programvaruutveckling. Det är ett ramverk för att lösa komplexa problem samtidigt som man skapar produkter med maximalt
3.6. Scrum
värde för kunden. Arbetsflödet fungerar så att en produktägare beordrar arbete för att lösa ett problem i en ”produkt-backlog”. Utvecklingsgruppen skapar sedan issues, som är en upp-delning av arbetet i mindre bitar, som arbetas med under en så kallad sprint. Denna sprint kan variera i längd beroende på projektets natur men är vanligtvis 2-8 veckor. I slutet av en sådan sprint utvärderas resultatet och processen upprepas tills projektet är färdigställt [28].
3.6.1
Parprogrammering
Parprogrammering är en agil metod som kan appliceras i Scrum. Parprogrammering är när två utvecklare sitter tillsammans och arbetar med samma problem. Rollerna delas upp i en programmerare och en observatör. Detta bidrar till att koden som skrivs blir granskad di-rekt, att den som programmerar har fullt fokus på utvecklingen och att observatören kan ge vägledning och stöd [29].
4
Metod
Detta kapitel beskriver valda metoder och hur de har använts för utveckling och insamling av erfarenheter.
4.1
Utvecklingsmetod
I denna del ges först en kort beskrivning av hur projektetarbetet förbereddes. Sedan beskrivs de metoder som har använts genom utvecklingsarbetet.
4.1.1
Förberedelser
I projektets första fas behövde många beslut fattas, inte minst vad gäller kommunikation och regler inom gruppen för att undvika konflikter. Under ett flertal möten diskuterades dessa frågor samtidigt som det undersöktes vilka kommunikationskanaler som faktiskt användes, och på vilket sätt. Efter några veckor författades ett gruppkontrakt som specificerade vilka regler som skulle gälla för arbetet och föredragna kommunikationskanaler.
Innan utvecklingsarbetet kunde påbörjas behövde gruppen säkerställa vad projektet skul-le innefatta och hur det resulterande systemet skulskul-le användas. Att besvara den här fråge-ställningen och att lära känna kunden utgjorde de viktigaste delarna av det första kundmö-tet. Kunden beskrev att projektet skulle utgöras av en webbapplikation med koppling till en server och en databas. Webbapplikationens gränssnitt ska vara modernt och enkelt med en server som ska vara portabel, pålitlig och snabb.
Även utvecklingsspråk, ramverk, utvecklingsmiljöer och tillvägagångssätt för versions-hantering behövde väljas. En studie kring val av dessa utfördes parallellt med kravanalysen. Det slutgiltiga beslutet baserades på gruppmedlemmarnas erfarenheter och vilka fördelar gruppen såg jämfört med andra verktyg.
4.1.2
Scrum
Scrum valdes som arbetsmetod eftersom det är ett enkelt sätt att strukturera upp utveck-lingen utan överflödigt arbete. Dessutom är Scrum förhållandevis populärt bland utvecklare. Eftersom projektet var tidsbegränsat till fyra månader användes kortare sprintlängder än vad som annars är brukligt. Gruppen valde att utföra en sprint per vecka. Varje måndag hölls ett
4.2. Förstå kundens behov
sprintmöte där gruppmedlemmarna gick igenom vad de hade gjort föregående sprint. Sedan skapade gruppmedlemmarna tillsammans issues för den kommande sprinten. Gitlab använ-des för att administrera och tilldela använ-dessa issues.
Gruppmedlemmarna fick själva välja vilken eller vilka av dessa issues de ville arbeta med under sprinten, men omsorg togs för att minst en person i varje programmeringspar skulle ha viss erfarenhet av det som issuen innefattade. Dessa par höll sedan ihop under sprinten och arbetade med de issues de blivit tilldelade. Ibland behövdes mer än en vecka för att färdigställa en issue. Denna issue fördes då över till nästa sprints uppsättning av issues. Ofta bibehölls samma programmeringspar när så var fallet.
4.1.3
Parprogrammering
Parprogrammering har använts i projektet för att låta de mer erfarna utvecklarna dela med sig av sin kunskap till de andra i gruppen. Det gör då att den totala kunskapen i gruppen snabbt ökas vilket gynnar gruppen som helhet. Eftersom gruppmedlemmarna inte har kun-nat träffas så har olika programvaror använts för att möjliggöra parprogrammering. Discord har använts för röstkommunikation och skärmdelning. Ett särskilt viktigt verktyg har varit Visual Studio Codes Liveshare-funktion som ofta har använts för att tillåta flera utvecklare att redigera samma dokument i realtid.
4.1.4
Testning
I små projekt kan det räcka med att koden manuellt testas när ny funktionalitet läggs till. Det kan fungera när en person kan hålla reda på hela koden samtidigt, men i större projekt som detta så är det inte möjligt. Det går inte att alltid veta hur en del av koden kan påverka en annan och därmed så går det inte att med manuella tester se att en ändring inte får oönska-de konsekvenser. Med anledning av oönska-detta skapaoönska-des standardiseraoönska-de tester som har använts genom projektets gång. Både enhetstester för servern och klienten samt end-to-end-tester där användning av systemet simuleras har använts. Testerna har kunnat köras av utvecklare med hjälp av tasks i Visual Studio Code, och även i en pipeline på Gitlab. Ett mål sattes i kvalitets-planen om att täcka minst 80% av projektets kod i testerna.
4.2
Förstå kundens behov
För att kunna leverera det en kund vill ha är det viktigt att så fort som möjligt förstå dess behov. För att åstadkomma detta i projektet har tre verktyg använts. Det första verktyget var kundmöten. I början av projektet användes dessa främst för att diskutera kraven på systemet. Parallellt med dessa möten utvecklades en kravspecifikation, som var det andra verktyget, för att gruppen och kunden skulle kunna komma överens om vad som kunde förväntas av den slutgiltiga tjänsten. Kravspecfikationen utgjorde således en grund för vad tjänsten skulle kunna göra, och i viss mån hur det skulle göras. Det tredje och sista verktyget var proto-typning. Den framtagna prototypen främjade ett flertal diskussioner eftersom den tillät både kunden och gruppen att få en konkretiserad bild av hur tjänsten skulle kunna komma att se ut. Prototypen gjorde det lättare att notera fler aspekter av systemet som inte redan var fastställda.
I andra halvan av projektet började regelbundna möten med kunden hållas med interval-ler om två veckor. Dessa mötens funktion var att regelbundet uppdatera kunden om projek-tets aktuella status och att erbjuda frekventa diskussioner, ofta då på en mer detaljerad nivå eftersom systemets grund skapades tidigt.
4.3. Riskhantering
4.3
Riskhantering
Alla projekt har olika risker men hur man hanterar dem kan skiljas åt mycket. Ibland är det bäst att mitigera skadan men ibland är det bättre att minimera risken. Oavsett hur riskerna ska hanteras så är det viktigt att de upptäcks. Några av de risker som upptäcktes i detta projekt diskuteras nedan.
4.3.1
Kunden kräver funktioner som gruppen inte kommer att hinna med inom
tidsramen av projektet
I början av projektet när kravspecifikationen utformades så var det väldigt mycket mer som kunden ville att gruppen skulle göra än vad gruppen trodde sig kunna leverera. Genom att tidigt diskutera det inom gruppen och resonera sig fram till vad som rimligtvis skulle kunna hinnas med så kunde risken diskuteras med kund och den minimerades.
4.3.2
Gruppmedlemmar hamnar efter tidsplanen
I början av projektet gjordes en tidsplan för hur mycket tid som gruppmedlemmarna skulle lägga varje vecka. Det var väldigt viktigt, eftersom det fanns andra kurser som gick samtidigt, för att säkerställa att ingen kurs skulle komma i kläm i slutet av projektet. Det gick relativt bra att följa den i första perioden, men det var väldigt många som hamnade efter i andra perioden. För att motverka det uppmärksammades tidsplanen på varje veckomöte och sedan det började så har gruppen lagt fler timmar än tidigare.
4.4
Metod för att fånga erfarenheter
För att fånga in erfarenheter under projektets gång har gruppen genomfört ett sprint-retrospektivmöte i slutet på varje sprint, där gruppen har fått besvara en enklare enkät med frågor om hur sprinten har gått och hur arbetet har upplevts (se Appendix). Utifrån des-sa svar kunde gruppen analysera och se vad som fungerade bra eller ordes-sakade eventuella problem. Varje medlem i gruppen genomförde tillsammans med teamledaren en sorts utvär-deringsmöte två gånger under projektet. Där kunde de diskutera projektet enskilt vilket gav teamledaren en bättre överblick över projektets status och hur individerna låg till i arbetet.
5
Resultat
Detta kapitel beskriver projektets resultat.
5.1
Systembeskrivning
Här beskrivs det system som skapades och hur projektgruppen utvecklat det.
5.1.1
System
Systemet kommer att användas av Teknikåttan vid deras tävlingar. De aktuella användarna innefattar administratörer av tävlingssystemet, tävlande lag, tävlingsoperatörer och domare. Dessa användare interagerar med systemet via olika men liknande gränssnitt, kallade vyer, och de beskrivs nedan.
5.1.1.1 Administratör
En administratör är en typ av användare som skapar, redigerar och tar bort följande: • Användare • Regioner • Tävlingar ‚ Tävlingssidor ‚ Frågor ‚ Svar ‚ Frågealternativ ‚ Bilder
Kortfattat sköter administratören allting innan en tävling. I figur 5.1 syns administratör-svyn med den valda fliken tävlingshanterare. I den vyn går det även att se regioner och an-vändare.
5.1. Systembeskrivning
Figur 5.1: Administratörsida under fliken tävlingshanterare som visar tidigare skapade täv-lingar.
I administratörsvyn finns även tävlingsredigeraren som är den del av applikationen där tävlingarna skapas och redigeras, se figur 5.2.
Figur 5.2: Tävlingsredigerare som visar en para ihop fråga på åskådarvyn på sida 3 med sidinställningar.
5.1.1.2 Tävlingsoperatör
En tävlingsoperatör är den som sköter en pågående tävling. Det är denna aktör som bestäm-mer vilken tävlingssida som ska visas för de andra synkroniserade vyerna. Tävlingsopera-tören bestämmer när en eventuell timer ska startas och när nuvarande ställning visas för publiken. Tävlingsoperatörens vy syns i figur 5.3.
5.1. Systembeskrivning
Figur 5.3: Operatörsvy.
5.1.1.3 Åskådare
Åskådare är publiken som tittar på tävlingen. De kan bli visade lätt modifierade tävlingssi-dor för att dessa ska passa en större skärm. Publiken har heller inte samma behov av lika mycket information som de tävlande har, så frågorna kan vara mer kortfattat formulerade. Åskådarvyn syns i figur 5.4.
5.1. Systembeskrivning
5.1.1.4 Tävlande
Tävlande är de lag som är med och tävlar. De ska svara på frågor och utföra uppgifter med hoppet om att göra det bäst av alla lag och vinna tävlingen. Tävlandevyn syns i figur 5.5.
Figur 5.5: Tävlandevy.
5.1.1.5 Domare
En domare bedömer de tävlandes svar och prestationer. Den kan själv välja vilken tävlings-sida den vill se utan att det påverkar andras vyer. Domarna har rättningsanvisningar för alla frågor. De kommer att se samma tävlingssidor som de tävlande. Domarvyn syns i figur 5.6.
5.2. Process- och produktkvalitetssäkring
5.1.2
Dokument
Dokument som skrivits är:• Arkitekturdokument • Gruppkontrakt • Kravspecifikation • Kundkontrakt • Kvalitetsplan • Projektplan • Testplan • Testrapport • Användarmanual
5.1.3
Värde för kund
Kunden får en produkt som är en god grund att fortsätta jobba på. Kunden genomför idag tävlingen men det finns många hinder med det nuvarande systemet. Ett väl utfört arbete ger ett system som skulle ge stort värde för kunden. Först och främst kommer det att spara myck-et tid eftersom dmyck-et finns många funktioner som idag är väldigt tidskrävande. Ett exempel på det är presentationseditorn som är klumpig och långsam. Att det går snabbare att redigera tävlingar är en bidragande faktor till minskad frustration med systemet. Det kan göra att det blir lättare att locka nya personer till att jobba med tävlingen och att tävlingen därmed kan växa. Förhoppningen är också att själva svarssystemet blir så pass bra att tävlingsutförandet i sig blir bättre än det är idag vilket också kan bidra till att tävlingen växer.
5.2
Process- och produktkvalitetssäkring
Det processmål som valdes att fokusera på i detta projekt var process- och produktkvalitets-säkring (PPQA). Begreppet innebär att man, på ett övergripande och objektivt sätt, ska iden-tifiera, strukturera och organisera arbetsmetoder samt utvärdera produkten. Arbetsmetoden som utvärderades under detta projekt var hur gruppen arbetar med Scrum och, mer specifikt, sprintar. Utformningen av detta processmål gjordes tillsammans med studenter ur kursen Programvarukvalitet (TDDE46) på Linköpings universitet och diskuterades under coaching-tillfällen.
Inledningsvis hade gruppen sprintar som varade en vecka och efter varje sprint genom-fördes en kort utvärdering i form av ett formulär (se Appendix) som varje medlem svarade på. Detta låg som grund till de förbättringar som gjordes.
Under projektets gång analyserades utvärderingarna och resultatet visade att gruppen trivdes, och visade väldigt bra samarbetsförmåga och stark vilja att hjälpas åt. Det utvärde-ringen dock kom fram till var att längden på sprinten var för kort eftersom alla tilldelade issues inte hanns med på en vecka. Två åtgärder gjordes: den första åtgärden var att förlänga sprintlängden till två veckor vilket uppskattades då paren kunde fortsätta jobba med det de eventuellt inte hann klart med sprinten innan. Den andra åtgärden var att dela upp stora is-sues i mindre delar. Åtgärderna kunde ses som förbättringar då svaren från formuläret visade att gruppmedlemmarna trivdes något bättre i helhet, de tyckte att sprintlängden var bättre och de hann med fler av de issues som de blev tilldelade.
En mätbar kvalitet som kunden uttryckte stort behov av var hög underhållbarhet. Kun-den ville själv kunna fortsätta utvecklingen av systemet eller ha möjligheten att lämna över
5.3. Gemensamma erfarenheter
koden till en annan grupp studenter. Gruppen fokuserade därmed på att mäta kvaliteten för att se till att produkten uppnådde detta krav. För att mäta underhållbarhet på ett objektivt sätt valde gruppen att mäta underhållbarhetsindex (eng. maintainability index). Detta index räknas ut genom att använda en formel som tar in Halstead Value (HV) som är antal opera-tioner, Cyclomatic Complexity (CC) som är ett värde på hur hög komplexitet ett program har och Lines of Code (LOC) som mäter antalet rader kod. Denna matematiska formel ser ut som följande [30]: Maintainability Index= Max 0,100 171 171 ´ 5.2 ¨ ln(HV)´0.23(CC) ´ 16.2 ¨ ln(LOC) (5.1) I denna modell kan värdena 0-9 tolkas som att koden är helt oacceptabel utifrån ett under-hållsperspektiv. Om resultatet däremot ligger mellan 10 och 19 så är det acceptabelt, men inte önskvärt. Målet är att få ett resultat som ligger mellan 20 och 100 som då visar att koden har medel till hög underhållbarhet. Som kan ses i tabell 5.1 så uppnår systemet dessa krav och kan därmed ses som att det har god underhållbarhet [31].
Metric Frontend Backend
Lines of code 3304 1710
Cyclomatic Complexity (Avg.) 11 14
Maintainability Index 42 34
Tabell 5.1: Kodmetriker av projektet
5.3
Gemensamma erfarenheter
Det finns många aspekter av projektet som har varit nya för projektmedlemmarna. Dessa aspekter har varit väldigt givande för gruppen eftersom det har gett möjligheten att ta med sig nya lärdomar som kan nyttjas i framtiden.
5.3.1
Kundkontakt
Den främsta erfarenhet som gruppen har tagit med sig från projektet är hur det är att arbeta efter en kunds behov i en större grupp. Vid tidigare tillfällen har projektmedlemmarna jobbat i mindre grupper med tydliga fördefinierade mål. Det är helt annorlunda att försöka ta fram krav från en kunds behov och att kunna arbeta utifrån dem. Att kunna ha en god kontakt med kunden och se till att man har förstått dess behov är en mycket bra erfarenhet att ha om man i framtiden ska arbeta på liknande sätt.
5.3.2
Tekniska och processrelaterade erfarenheter
De tekniska erfarenheterna sedan innan projektet varierade bland gruppmedlemmarna. På grund av detta varierar även de nya erfarenheter som medlemmarna har tagit med sig från projektet. Dock så har alla medlemmar lyckats ta med sig åtminstone någon ny lärdom från projekts gång. Flera av medlemmarna har fått med sig mer erfarenhet inom användning-en av versionshanteringsverktyget Git och hur ett bra arbetsflöde kan åstadkommas med hjälp av det, kunskap som är väldigt bra att ha på grund av hur mycket det används inom applikationsutveckling. Alla i gruppen kände sedan tidigare till agila arbetsmetoder, men majoriteten hade inte använt sig av dem. Därför har gruppen även lärt sig att arbeta utifrån arbetsmetoden Scrum, vilket visade sig vara till stor nytta eftersom det skapade tydliga mål att arbeta efter.
5.4. Översikt över individuella bidrag
5.3.3
Övriga erfarenheter
Gruppen har också tagit lärdom i användbarheten av att skriva vissa dokument i samband med projektet. Detta har störst koppling till kundkontakten med att kunna ta fram en accep-terad kravspecifikation. Kravspecifikationen visade sig vara till mycket hjälp när man kom längre in i projektets utveckling, då den snabbt kunde ge en uppfattning om vad som fanns kvar att jobba på och behövde prioriteras.
5.4
Översikt över individuella bidrag
Här ges en översikt över varje gruppmedlems egna text.
5.4.1
Strukturering av CSS i React av Albin Henriksson
Det här bidraget syftar till att hitta olika sätt att strukturera CSS i React och utvärdera dessa för att kunna ge en vägledning för utvecklare som söker efter vilket verktyg som passar dem bäst.
5.4.2
Utbildning inom ett utvecklingsprojekt av Sebastian Karlsson
Det här bidraget undersöker mängden tid som läggs på utbildning i utvecklingsprojekt ge-nom en kvantitativ enkätundersökning, och presenterar effektiva metoder för arbetsplatsba-serat lärande genom en fallstudie.
5.4.3
Resursanvändning i Git av Victor Löfgren
I det här bidraget undersöks resursanvändningen i Git beroende på hur det används i en lit-teraturstudie. Även hur Git har använts i detta projekt och dess resursanvändning diskuteras.
5.4.4
Tillståndshantering i React av Björn Modée
I denna litteraturstudie undersöks tillståndshantering i JavaScript-biblioteket React tillsam-mans med en jämförelse av de två populäraste alternativen för att hantera detta.
5.4.5
Programvara för kommunikation i mindre mjukvaruprojekt av Josef
Olsson
I detta bidrag genomförs en undersökning som relaterar olika program till olika mötestyper och som tar reda på hur viktigt programvalet är för att ett möte ska gå bra.
5.4.6
Alternativa vägar till kunskap av Max Rüdiger
Detta bidrag undersöker olika digitala verktyg som används inom lärande, hur de används och vad de har för påverkan i jämförelse med mer traditionella utlärningsmetoder.
5.4.7
Relationen mellan prestanda och skalbarhet i SQLAlchemy av Carl
Schönfelder
I denna text undersöks relationen mellan prestanda och skalbarhet i SQLAlechemy. Mer spe-cifikt hur prestanda av olika nivåer påverkas av ett projekts skalbarhet och hur SQLAlchemy kan tillämpas på ett effektivt sätt.
5.4. Översikt över individuella bidrag
5.4.8
Att använda prototypning i mjukvaruprojekt av Emil Wahlqvist
I det här bidraget sammanställs en uppsättning litterära källor för att ta reda på när det är lönsamt att arbeta med prototyper i mjukvaruprojekt. Vidare undersöks det effektivaste sättet att arbeta med dessa.
6
Diskussion
I detta kapitel analyseras och diskuteras de resultat som redovisades i det föregående kapitel.
6.1
Resultat
I detta kapitel diskuteras olika synvinklar på resultatet och mer specifikt vad som kunde ha hanterats annorlunda. Det diskuteras även om projektets vidareutveckling, vilka lärdomar som tagits med till projektet och slutligen vilka lärdomar som tas med från projektet.
6.1.1
Alternativa implementationssätt
Systemet innehåller ett flertal funktioner som är svåra att implementera i SQL. En stor ut-maning var att hämta en hel tävling från databasen eftersom en tävling består av en tabell som har relationer till andra tabeller. De mest komplexa relationerna som en tävling har är till tabellerna tävlingssidor och lag eftersom de i sig också har relationer till andra tabeller. Det blir ett rekursivt problem vilket är svårt att implementera väl i SQL. Det kräver mer avancerade SQL-frågor (eng. query) som join och subqueries för att lösa det rekursiva proble-met. Ett alternativ till SQL är NoSQL, vilket är ett uttryck för databasmodeller där data inte lagras i relationstabeller vilket är hur SQL fungerar. Ett exempel på ett NoSQL-verktyg är MongoDB. Fördelen med att använda en NoSQL-databas är att det går enkelt att spara, re-digera och hämta hela JSON-dokument. Vi gjorde valet med SQL över NoSQL eftersom SQL har en strikt struktur. Till en början blev det svårare med SQL då den strikta strukturen måste skapas och därefter följas. Över tiden underlättades utvecklingen då det blir enkelt att sätta sig in i databasen eftersom den är väl strukturerad. Utöver det finns verktyget SQLAlchemy som underlättar SQL-utveckling i Python.
Det skulle ha underlättat om projektet använde sig av ett enda programspråk istället för två. På frontend är valen begränsade till Javascript och andra relaterade språk som till ex-empel TypeScript, men på backend är det ett helt fritt val av programspråk. Då klienten är implementerad i TypeScript hade en alternativ lösning varit att implementera backend i Ty-peScript. Det skulle ge en homogen struktur över hela projektet och underlätta utvecklings-processen då projektets kod skulle bestå av enbart ett programspråk. I slutändan togs beslutet att frontend och backend ska vara två separata enheter och därmed inte dela någon kod. All kommunikation mellan frontend och backend sker genom ett API och därför har det ingen
6.1. Resultat
större betydelse att de två delarna använder olika programspråk. Att implementera backend och frontend i olika programspråk tvingar även fram den valda strukturen om att inte de-la någon kod melde-lan dede-larna. Den avgörande faktorn till varför Python valdes var att alde-la i gruppen hade goda förkunskaper från tidigare kurser.
Ett alternativ till React är Angular. Huruvida man väljer att använda React över Angular eller tvärtom har ingen större betydelse då båda ramverken har den funktionalitet som krävs för att lösa samma problem. De små skillnaderna mellan React och Angular skulle inte ha påverkat vårt resultat. Eftersom gruppen hade mer kunskap om React än Angular blev valet självklart React.
6.1.2
Återstående arbete
Projektgruppen har hunnit implementera mycket av den funktionalitet som kunden önskade. Det återstår däremot lite arbete innan kunden kan få fullt värde av systemet.
För att kunna använda systemet krävs det först och främst att kunden litar på att det är tillräckligt stabilt så att det inte slutar fungera mitt under en pågående tävling. Från gruppens sida uppnås det med hjälp av automatiska tester på både frontend och backend och integra-tionstester som testar hela systemet. Från kundens sida kommer det även att kräva mycket användartestning för att se till att systemet är lättanvänt och robust. Innan kunden övertygat sig själva om att det är tillräckligt stabilt, säkert och robust kommer de inte att vilja använda systemet.
Systemet saknar också viss funktionalitet som skulle behövas. Bland annat kan inte alla olika efterfrågade frågetyper läggas in vilket gör att kunden potentiellt inte kan använda pro-dukten om några av dessa skulle krävas för en viss tävling. Den prioriteringen gjordes för att få klart all kärnfunktionalitet i systemet. Nu när dessa är på plats kommer det att gå relativt enkelt att lägga till nya frågetyper. Sedan saknas även lite extra funktionalitet som skulle öka användbarheten och göra produkten bättre. Dessa är att kunna automaträtta frågor, som till exempel flervalsfrågor, för att avlasta domarna. Statistik hade varit användbart för att i efter-hand enklare kunna bedöma svårighetsgraden på frågor och tävlingar. Bilder kan läggas in i tävlingar men det bör även gå att lägga in videor och ljud. Att hantera ljud hade avlastat ännu en person då det oftast finns en på plats på en tävling som sköter uppspelning av ljud, men genom att bygga in det direkt i systemet hade operatören kunnat sköta det.
Kundens plan har alltid varit att fortsätta utvecklingen av systemet efter oss. För att un-derlätta detta har gruppen skapat en kort manual som beskriver hur systemet är uppbyggt, hur man använder det och hur det utvecklades. Detta kommer förhoppningsvis att ge ett bra underlag för nästa grupp som kommer ta över projektet. Detta prioriterades eftersom det saknades från den tidigare studentgruppen vilket tvingade gruppen till att börja om från början, och både gruppen och kunden vill ogärna att det händer igen.
6.1.3
Förbättringar från tidigare projekt
Innan projektet började skulle varje gruppmedlem fundera över saker som kunde ha förbätt-rats i deras tidigare projekt. Vid projektets slut diskuterades sedan dessa områden igen, och vi kunde identifiera ett antal saker som vi har gjort bättre i detta projekt jämfört med tidigare. Medlemmarna hade utfört olika projekt och hade därför olika erfarenheter, så vissa personer hade redan utfört några av dessa områden på ett bra sätt i andra projekt. Därför kan dessa områden inte betraktas som förbättringar för varje enskild individ, utan för gruppen som helhet.
6.1.3.1 Möten
Flera i gruppen påpekade att möten hade fungerat bättre i det här projektet. Tidigare projekt hade inte alltid haft regelbundna möten, och de hade inte alltid varit givande. Nu har vi
6.1. Resultat
haft regelbundna möten varje vecka som vi har tyckt att vi har fått ut mycket av. Scrum-mötena har varit särskilt givande. Under Scrum-mötena har vi gått igenom vad alla har gjort och planerat för veckan tillsammans. Vi har även haft ett möte med gruppens handledare varje vecka vilket har varit bra för att hålla handledaren informerad om arbetets gång och för att fånga upp eventuella problem tidigt. I tidigare projekt hade inte en så hög mötesfrekvens hållits. Ytterligare en förbättring vi har gjort är att alltid boka in nästa handledarmöte som sista punkt på dagordningen, något vi tog till oss efter en kommentar från vår handledare. Vi har även hållit oss till dessa planerade handledarmöten och inte kallat till möten med kort varsel eller utanför ordinarie arbetstid, något som förekom i tidigare projekt.
6.1.3.2 Roller
En gemensam erfarenhet var att grupproller inte hade utnyttjats till fullo i tidigare projekt. I detta område såg vi ett blandat resultat, där vissa medlemmar ansåg att deras roll hade an-vänts mer än tidigare medan andra inte såg någon stor skillnad. En annan skillnad mot tidi-gare projekt var att viss omfördelning av ansvar skedde nära projektets slut. Gruppmedlem-men som hade rollen som arkitekt fick då även ansvar över kodkomGruppmedlem-menteringen, eftersom arkitekturen var färdigställd och inte behövde mer arbete. Någon sådan omfördelning av rollansvar hade inte gjorts i tidigare projekt.
6.1.3.3 Testning
Detta projekt hade mer omfattande testning än tidigare projekt hade haft. Redan i kvalitets-planen sattes mål för kodtäckning av testerna. Kontinuerligt under projektet har tester skri-vits och förts in i testsviten för att uppfylla dessa mål. Testerna har använts dels lokalt av utvecklarna för att utvärdera sin kod, och dels i en automatiserad CI/CD-pipeline som körs på GitLab varje gång en utvecklare försöker lägga till ny kod projektets huvudgren, för att hu-vudgrenen alltid ska vara körbar. I tidigare projekt hade knappt någon strukturerad testning gjorts alls, så detta var en stor förbättring.
6.1.4
Viktigaste lärdomarna inför framtiden
I början av projektet bokade vi in kundmöten med relativt långa mellanrum, mellan tre och fem veckor. Ungefär halvvägs in projektet föreslog kunden att hålla regelbundna möten med två veckors mellanrum. Detta bidrog till regelbundna diskussioner om projektets alla aspek-ter. Det visade sig vara en bra idé eftersom det är lätt att se många saker på olika sätt. I framtida projekt kan det därför vara fördelaktigt att boka in regelbundna kundmöten från projektets start.
Eftersom projektet även utfördes föregående år kunde vi använda de lärdomar som förra gruppen delat med sig av. Vi gjordes medvetna om att projektet är sådant att mycket funktio-nalitet kan efterfrågas. Med hänsyn till detta kunde vi i ett tidigt stadie sätta ramar om vad som är rimligt och vilka förväntningar kunden kunde tänkas ha. Under projektets förlopp är det dock viktigt att ta i beaktande att saker och ting kan komma att förändras. I vårt fall omprioriterades kraven för att projektet skulle ha en rimligare målbild i förhållande till den tidsram vi befann oss i. Detta kunde som sagt göras tidigt tack vare den föregående gruppens lärdomar.
Med grundliga förberedelser kan det bli en snabb övergång till att komma igång med pro-grammeringen. Vi identifierade att övergången mellan planeringsfasen och utvecklingsfasen skulle bromsa projektet eftersom det kan ta tid för alla gruppmedlemmar att komma igång med projektets konfiguration. Detta löste vi genom att några gruppmedlemmar började ti-digt med att etablera utvecklingsmiljöerna och standarderna för versionshanteringen. Detta gjorde det lätt för resterande medlemmar, av vilka några hade mindre erfarenhet av webb-utveckling, att komma igång med utvecklingen. Även tydliga instruktioner dokumenterades
6.2. Använda verktyg
för att samtliga gruppmedlemmar skulle få en tydlig bild av hur olika saker fungerade, ex-empelvis hur man gör en sammanfogningsförfrågan i GitLab, vilket är när man lägger ihop kod från olika källor. Detta bidrog också till en smidigare övergång från förberedelserna till utvecklingen.
Olika projekt kräver olika typer av tillvägagångssätt. Ett flertal av kursens obligatoris-ka moment blev i vårt fall överflödiga. Detta inkluderar coachningstillfällena om kvalitetsa-spekter, kvalitetsplanen, flödesschemat, arkitekturdokumentet, systemanatomin, projektpla-nen och aktivitetslistan. I ett större projekt skulle kvalitetsplaprojektpla-nen kunna ha större betydelse, då kvalitetssamordnaren skulle kunna lägga en större vikt vid kvalitetsaspekterna. Vidare blev det ofta samma innehåll i handledarprotokollen och statusrapporterna. Dessa ansåg vi skulle kunna utgöra samma moment. Vi kände att vi hade tillräckligt med underlag för att arbeta utan de moment vi ansåg vara överflödiga, då de ändå inte kom till användning i utvecklingsprocessen.
Slutligen är det viktigt med ett konsekvent arbete för att undvika större uppgifter i slutet av projektet. Det är viktigt att tänka på att kontinuerligt dokumentera och testa kod för att upprätta ett metodiskt tillvägagångssätt.
6.2
Använda verktyg
Det har valts många program och applikationer under projektets gång och de flesta har fun-gerat bra. Visual Studio Code är ett program som har funfun-gerat väl och det har varit få pro-blem. Förhoppningen var att det skulle fungera bra med de plugins som fanns och att de skulle hjälpa utvecklingen framåt. Som tur var hittade vi plugins som fungerade väldigt bra och som hjälpte utvecklingen. Det var bara ett plugin som gav vissa medlemmar problem och det var LiveShare som låter flera deltagare skriva i samma dokument samtidigt. För vis-sa gick det då inte att vivis-sa filer i Python utan att LiveShare kraschade men det problemet gick att lösa genom att stänga av vissa andra plugins.
Valet att använda Visual Studio Code som primär utvecklingsmiljö orsakade en utmaning då projektet består av två programspråk. Först och främst är Visual Studio Code inte nybör-jarvänligt vilket skapade en inlärningskurva. Visual Studio Code är väldigt konfigurerbart, något som leder till en brist på standardisering eftersom alla användare arbetar med sin egen konfiguration. Ett alternativ till Visual Studio Code är att använda en integrerad utvecklings-miljö där de flesta konfigureringar är standardiserade, som till exempel JetBrains [32].
Ett annat program som valts är Discord som också det har levt upp till förväntningarna. Kommunikationen har haft en avslappnad stämning när det använts vilket också var för-hoppningen. Det har även fungerat rätt bra att dela skärm vid parprogrammeringen men upplösningen är inte lika bra på Discord som till exempel på Zoom. Skärmdelning var inte var något som planerades på förhand men som tur var gick det bra ändå.
Det finns ett stort antal olika kodredigerare att välja mellan för alla sorters situationer. För detta projekt skulle gruppen likaväl ha kunnat använda ett program som Atom, som också är mycket populärt eller till och med något mer grundläggande som Notepad++. Dock så valdes just Visual Studio Code av de anledningar som nämnts tidigare. För kommunikation finns det ett flertal olika alternativ att använda, några exempel skulle kunna vara Skype, Zoom och Messenger. Den sistnämnda var även i diskussion i början av projektet om huruvida den skulle användas istället för Slack. De kommunikationsverktyg som i slutändan användes blev valda antingen för att gruppen redan hade använt dem tidigare, eller för att de erbjöd funktionalitet som andra plattformar inte gjorde.
6.3
Metod
Scrum har fungerat bra som arbetsmetod. I ett projekt av den här storleken är det viktigt att man har något slags ramverk för arbetet, men kanske inte lika viktigt exakt hur det ramverket
