Tävlingssystem för Teknikåttan

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

20 | LIU-IDA/LITH-EX-G--20/022--SE

Tävlingssystem för Teknikåttan

Competition system for Teknikåttan

Dawid Abucewicz

Frida Blomstedt

Nazir Elpustaty

Edwin Forsberg

Carl Harris

Max Helmrich

Evelina Holmgren

Carl Lidman

Handledare : Christoﬀer Holm Examinator : Kristian Sandahl

(2)

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 ﬁnns 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/. © Dawid Abucewicz Frida Blomstedt Nazir Elpustaty Edwin Forsberg Carl Harris Max Helmrich Evelina Holmgren Carl Lidman

(3)

Sammanfattning

Denna rapport har skrivits i samband med ett kandidatprojekt vid Linköpings universi-tet. Projektet gick ut på att skapa ett nytt system till tävlingen Teknikåttan, och syftet med denna rapport är att fånga upp erfarenheter från detta projekt. I rapporten undersöks vi-dare hur man kan implementera ett system för att skapa värde för en kund, vilket stöd det ger att arbeta med en systemanatomi samt hur man tillsammans med en kund kan arbeta för att prioritera krav. För att utföra dessa undersökningar har rapporten skrivits parallellt med projektet och relevanta erfarenheter och observationer har noterats.

Från projektet har rapporten dragit slutsatsen att värde kan skapas för kund genom att arbeta aktivt med riskhantering. För att kunna samarbeta med en kund och prioritera krav krävs mycket kommunikation för att se till att alla parter har samma information. Er-farenheter som fångades upp under projektet var framförallt att kontinuerligt undersöka hur sammanhållning och arbete fungerade i gruppen. Slutligen användes inte systemana-tomin mycket i detta projekt, förutom vid ett tillfälle då den redovisades. Det insågs att systemet skiljer sig från den tidigt skapade systemanatomin.

(4)

Författarens tack

Vi skulle först och främst vilja tacka vår kund, Teknikåttan, för att ha givit oss denna möj-lighet och förtroende till att utveckla deras tävlingssystem. Vi vill även tacka vår handledare Christoffer Holm för att ha hjälpt och guidat oss genom arbetet och alltid funnits där som ett stöd när vi stött på svårigheter. Kursledningen och vår examinator Kristian Sandahl ska även ha ett särskilt tack för att alltid ha sett till gruppens bästa samt kommit med goda råd under kursens gång. Ett stort tack ska även våra kvalitetscoacher ha för coachningen i vårt kvali-tetsarbete under terminen samt för att ha kommit med många bra idéer och förbättringar på vårt arbete. Slutligen vill vi tacka de opponeringsgrupper som har hjälpt oss förbättra våra dokument samt Stack Overflow för att alltid ha funnits nära till hands när det behövdes som mest.

(5)

Innehåll

Sammanfattning iii Författarens tack iv Innehåll v Figurer xi Tabeller xii Definitioner xiii 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Kunden . . . 3 2.2 Projektgruppen . . . 4 3 Teori 5 3.1 JavaScript . . . 5 3.2 Node.js . . . 5 3.3 Express . . . 5 3.4 Single-page-applikation . . . 5 3.5 React . . . 6 3.6 Redux . . . 6 3.7 HTTP-förfrågan . . . 6 3.8 Polling . . . 6 3.9 WebSockets . . . 6 3.10 MongoDB . . . 6

3.11 Material Design och Material-UI . . . 6

3.12 Scrum . . . 6 3.13 GitLab . . . 7 3.14 Zoom . . . 7 3.15 Slack . . . 7 3.16 Messenger . . . 8 3.17 CMMI . . . 8 3.17.1 Riskhantering . . . 8 4 Metod 9

(6)

4.1 Utvecklingsmetod . . . 9

4.1.1 Innan utveckling . . . 9

4.1.2 Under utveckling . . . 11

4.2 Metod för att fånga erfarenheter . . . 14

4.3 Riskhantering i projektet . . . 14

4.4 Insamling av information för skapat värde för kunden . . . 15

5 Resultat 17 5.1 Systembeskrivning . . . 17 5.1.1 Dokument . . . 18 5.1.2 Systemanatomi . . . 19 5.2 Processbeskrivning . . . 19 5.2.1 Förbättring av process . . . 19 5.2.2 Processresultat . . . 20 5.3 Värdering av system . . . 21 5.3.1 Jämförelse . . . 22 5.4 Gemensamma erfarenheter . . . 22

5.4.1 Erfarenhetsfångst vid mitten av projektet . . . 22

5.4.2 Erfarenhetsfångst i slutet av projektet . . . 22

5.5 Kundkontakt . . . 23

5.6 Översikt över individuella bidrag . . . 24

6 Diskussion 26 6.1 Resultat . . . 26 6.1.1 Erfarenhetsfångst . . . 26 6.1.2 Test av användarvänlighet . . . 27 6.1.3 Process . . . 28 6.1.4 Kundkontakt . . . 28 6.1.5 Systemanatomi . . . 29 6.2 Metod . . . 29 6.2.1 Källkritik . . . 29

6.2.2 Metod för analys av skapat värde för kund . . . 29

6.2.3 Metod för erfarenhetsfångst . . . 30

6.3 Arbetet i ett vidare sammanhang . . . 30

6.3.1 Samhällsaspekter . . . 30

6.3.2 Miljöaspekter . . . 31

6.3.3 Etiska aspekter . . . 31

7 Slutsatser 32 A Scrum-utvecklingsmetodik för utveckling hos små team av Dawid Abucewicz 34 A.1 Inledning . . . 34 A.1.1 Syfte . . . 34 A.1.2 Frågeställning . . . 34 A.1.3 Avgränsningar . . . 35 A.2 Bakgrund . . . 35 A.3 Teori . . . 35 A.3.1 Scrum-utvecklingsmetodik . . . 35 A.3.2 Scrum-beståndsdelar . . . 35 A.3.3 Scrum-roller . . . 37 A.4 Metod . . . 37 A.4.1 Litteraurstudie . . . 37 A.4.2 Enkät . . . 38

(7)

A.5 Resultat . . . 39

A.5.1 Hur skiljer sig den klassiska Scrum-utvecklingsmetodiken från den som används hos kandidatgrupper och andra professionella utveck-lingsteam? . . . 39

A.5.2 Hur ser fördelningen av timmar under en sprint ut? . . . 40

A.5.3 Vad har olika roller för påverkan på Scrum processen i kandidatgrupp av detta projekt? . . . 41

A.6 Diskussion . . . 41

A.6.1 Hur skiljer sig den klassiska Scrum-utvecklingsmetodiken från den som används av kandidatgrupper och andra professionella utveck-lingsteam? . . . 42

A.6.2 Hur ser fördelningen av timmar ut under en sprint? . . . 42

A.6.3 Vad har olika roller för påverkan på Scrum-processen i kandidatprojekt? 43 A.6.4 Metod . . . 43

A.7 Slutsatser . . . 43

B Kommunikationsverktyg i en mindre grupp av Frida Blomstedt 44 B.1 Inledning . . . 44 B.1.1 Syfte . . . 44 B.1.2 Frågeställning . . . 44 B.1.3 Avgränsningar . . . 44 B.2 Bakgrund . . . 45 B.3 Teori . . . 45 B.3.1 Slack . . . 45 B.3.2 Facebook Messenger . . . 45 B.3.3 Zoom . . . 45

B.3.4 Synkron och asynkron kommunikation . . . 46

B.3.5 React Developer Tools . . . 46

B.4 Metod . . . 46 B.4.1 Litteraturstudie . . . 46 B.4.2 Utvärdering . . . 46 B.4.3 Undersökning . . . 47 B.5 Resultat . . . 48 B.5.1 Litteraturstudie . . . 48 B.5.2 Utvärdering . . . 49 B.5.3 Undersökning . . . 49 B.6 Diskussion . . . 51 B.6.1 Resultat . . . 51 B.6.2 Metod . . . 51 B.7 Slutsatser . . . 52

C Grön mjukvaruteknik av Nazir Elpustaty 53 C.1 Inledning . . . 53 C.1.1 Syfte . . . 53 C.1.2 Frågeställning . . . 53 C.2 Bakgrund . . . 54 C.3 Teori . . . 54 C.3.1 Google Scholar . . . 54 C.3.2 Kompilerade programmeringsspråk . . . 54 C.3.3 Interpreterande programmeringsspråk . . . 55 C.4 Metod . . . 55 C.5 Resultat . . . 55

(8)

C.5.1 Hur mäts energiförbrukningen inom de olika områden i

mjukvaruut-veckling? . . . 55

C.5.2 Hur energieffektiva är de olika programmeringsspråken? . . . 56

C.6 Diskussion . . . 57

C.7 Slutsatser . . . 59

D Automatisk testning och testning på distans av Edwin Forsberg 60 D.1 Inledning . . . 60 D.1.1 Syfte . . . 60 D.1.2 Frågeställning . . . 60 D.2 Bakgrund . . . 61 D.3 Teori . . . 61 D.3.1 Enhetstest . . . 61 D.3.2 Integrationstest . . . 61 D.3.3 Acceptanstest . . . 61 D.3.4 Kontinuerlig leverans . . . 61 D.4 Metod . . . 62 D.5 Resultat . . . 62 D.5.1 Automatisk testning . . . 62 D.5.2 Testning på plats . . . 62 D.5.3 Testning på distans . . . 62 D.6 Diskussion . . . 63 D.6.1 Metod . . . 63 D.6.2 Resultat . . . 63 D.7 Slutsatser . . . 64

D.7.1 Hur kan automatisk testning användas i ett mindre mjukvaruprojekt? . 64 D.7.2 Vilka skillnader finns mellan testning på distans och testning på plats? . 64 E Att leda utvecklingsteam på distans av Carl Harris 65 E.1 Inledning . . . 65

E.1.1 Syfte . . . 65

E.1.2 Frågeställning . . . 65

E.2 Bakgrund . . . 65

E.3 Teori . . . 66

E.3.1 Virtuella team . . . 66

E.3.2 KSA . . . 66 E.4 Metod . . . 66 E.4.1 Avgränsningar . . . 67 E.5 Resultat . . . 67 E.5.1 Enkätundersökning . . . 67 E.5.2 Litteraturundersökning . . . 68 E.6 Diskussion . . . 69 E.6.1 Metod . . . 69 E.6.2 Resultat . . . 69 E.7 Slutsatser . . . 71

F Continuous Integration i mindre grupper av Max Helmrich 72 F.1 Inledning . . . 72 F.1.1 Syfte . . . 72 F.1.2 Frågeställning . . . 72 F.2 Bakgrund . . . 72 F.3 Teori . . . 73 F.3.1 Continuous integration . . . 73

(9)

F.3.2 Continuous delivery . . . 73 F.3.3 Continuous deployment . . . 73 F.3.4 CI / CD . . . 73 F.3.5 Automatiserad Testning . . . 73 F.3.6 Test-Driven Development . . . 73 F.3.7 Merge conflict . . . 73 F.4 Metod . . . 74 F.5 Resultat . . . 74 F.6 Diskussion . . . 74 F.7 Slutsatser . . . 75

F.7.1 Ger continuous integration värde i mindre grupper? . . . 75

F.7.2 Ger continuous delivery eller continuous deployment värde för mindre grupper? . . . 76

F.7.3 För vilka typer av grupper passar continuous integration bäst för? . . . 76

G Är tekniktävlingar för alla? av Evelina Holmgren 77 G.1 Inledning . . . 77

G.1.1 Syfte . . . 77

G.1.2 Frågeställning . . . 77

G.2 Bakgrund . . . 77

G.3 Teori . . . 78

G.3.1 Hur går tävlingen till? . . . 78

G.4 Metod . . . 78

G.5 Resultat . . . 79

G.5.1 Att tävla eller inte tävla? . . . 79

G.5.2 Prestation: repetition, uppgift och tid . . . 79

G.5.3 Individuellt, i grupp eller tävling? . . . 79

G.5.4 Konstruktivt tävlande . . . 80

G.5.5 Tjejer och teknik . . . 80

G.6 Diskussion . . . 81

G.7 Slutsatser . . . 81

H React eller Angular, vad passar bäst? av Carl Lidman 82 H.1 Inledning . . . 82 H.1.1 Syfte . . . 82 H.1.2 Frågeställningar . . . 83 H.2 Bakgrund . . . 83 H.3 Teori . . . 83 H.3.1 DOM . . . 83 H.3.2 React . . . 83 H.3.3 Angular . . . 83 H.4 Metod . . . 84 H.5 Resultat . . . 85 H.5.1 React . . . 85 H.5.2 Angular . . . 86 H.6 Diskussion . . . 87 H.6.1 Metod . . . 87

H.6.2 React och Angular . . . 87

H.7 Slutsatser . . . 88

H.7.1 Frågeställning 1: Vilka fördelar samt nackdelar finns det för React och Angular? . . . 88

H.7.2 Frågeställning 2: Finns det några typer av applikationer där React eller Angular lämpar sig bättre än det andra? . . . 89

(10)

(11)

Figurer

5.1 Redigeringsdelen av systemet . . . 18

5.2 Systemanatomi av tävlingssystem för Teknikåttan . . . 19

A.1 Scrum-beståndsdelar som användes av olika grupper under kandidatprojekten 2020. 40 A.2 Fördelning av timmar som ägnades åt utveckling under sprint 2. . . 40

A.3 Fördelning av timmar som ägnades åt utveckling under sprint 3. . . 40

A.4 Fördelning av timmar hos övriga kandidatgrupper. . . 41

A.5 Påverkan av scrum-mästare på utvecklingen hos de övriga kandidatgrupperna. . . 41

A.6 Påverkan av produktägare på utvecklingen hos de övriga kandidatgrupperna. . . 41

B.1 Svar på fråga 1 i utvärdering om kommunikationskanaler . . . 49

B.6 Resultat av undersökningen av textkommunikation . . . 51

C.1 Resultat av undersökningen som gjordes av Cunha, S. et al. . . 57

E.1 Resultat av fråga 1, 2 och 6 från enkätundersökningen . . . 68

E.2 Resultat av fråga 3 från enkätundersökningen . . . 68

(12)

Tabeller

4.1 Mall för commit-meddelanden. . . 13

4.2 Mall för en riskmatris. . . 15

4.3 Tester som utfördes på det gamla och det nya systemet . . . 16

5.1 Riskmatris över alla riskers initiala riskmagnitud. . . 20

5.2 Tabell över vilka risker som behandlades under respektive sprint under utveck-lingen. . . 20

5.3 Riskmatris efter sprint #4. . . 21

5.4 Resultat av testerna på det ursprungliga systemet . . . 21

5.5 Resultat av testerna på det nya systemet . . . 21

B.2 Resultat av undersökningen av möten . . . 50

(13)

Definitioner

Nedan följer de definitioner som används i rapporten:

Anatom En funktionalitet i ett system. Används i en systemanatomi.

Backend Delar av en webbapplikation som inte är synliga för användaren.

CMMI Står för Capability Maturity Model Integration. CMMI är ett pro-cessförbättringsprogram som används för projekt eller organisa-tioner.

CSS Står för Cascading Style Sheet och är ett sätt att ge stil till olika komponenter i HTML genom taggar för dessa komponenter.

Dagligt scrummöte Används inom Scrum och är ett dagligt möte där teammedlem-mar berättar om vad som har gjorts, vad som ska göras och om det finns några problem med utvecklingen.

Frontend Delar av en webbapplikation som är synliga för användaren.

Git Ett versionshanteringssystem för att samla mjukvarukod. An-vänds ofta för att dela kod mellan flera utvecklare.

GitLab Ett webbaserat verktyg för att versionshantera kod, använder sig av Git.

GUI Står för Graphical User Interface och är ett gränssnitt för att navi-gera en hemsida med till exempel knappar.

HTML HyperText Markup Language är det språk som alla hemsidor på nätet skrivs i. HTML anger i huvudsak hemsidans struktur och hierarkin för komponenterna på hemsidan.

Issue En uppgift som ska göras under en sprint i Scrum.

JavaScript Programmeringsspråk som främst används i webbapplikationer.

JSON Står för JavaScript Object Notation. Ett sätt att lagra data där varje bit data får en nyckel med dess namn. Med denna nyckel kan man enkelt spara och hämta data ur JSON-objektet.

Kravspecifikation Lista över krav som ställs på en produkt som tas fram tillsam-mans med beställare och utvecklare.

Material Design Ett designspråk som används för att skapa visuella element i ap-par och webbapplikationer.

(14)

Node.js En motor för att exekvera JavaScript-kod på en server eller dator utanför en webbläsare.

Produktägare Den projektroll som ansvarar för att förmedla kundens tankar till teamet under utvecklingen i Scrum och ser till produkten ger värde för kunden.

React Ett bibliotek av JavaScript-kod som används för att utveckla frontend-delar av applikationer.

Redux Ett kodbibliotek som hanterar tillstånd i webbapplikationer.

Scrum En iterativ utvecklingsmetod för mjukvara.

Scrummästare En person som vägleder teamet vid användning av Scrum och ansvarar att arbetsmetodiken följs.

Scrum-tavla En metod för att visualisera tillståndet av aktiviteter under ut-veckling.

Single-page-applikation En single-page-applikation skriver om sig själv baserat på da-ta som den hämda-tar från en server, vilket gör systemet samman-hängande och responsivt.

Sprint Ett tidsintervall på oftas en till fyra veckor som utvecklingen i Scrum delas upp i.

Sprintbacklogg En lista med de issues som ska göras under en sprint.

Sprintgenomgång Ett möte med kund och andra intressenter där resultat från av-slutad sprint redovisas

Sprintåterblick Ett möte med hela utvecklingsteamet där avslutad sprint utvär-deras.

Systemanatomi Ett dokument för att visa på beroenden i ett system, genom att arrangera anatomer i en trädstruktur.

Teknikåttan En organisation som anordnar en årlig tävling med samma namn för åttondeklassare. Teknikåttan är kunden för detta projekt.

Utvecklingsteam En grupp av utvecklare som jobbar med att utveckla en produkt.

WebSockets Ett kommunikationsprotokoll för kommunikation både mellan olika klienter samt mellan server och klient vid webbapplikatio-ner.

(15)

1 Inledning

Tävlingar finns i alla möjliga former. Allt från sten, sax, påse på skolgården till massiva globala tävlingsevenemang. Oavsett vilken form av tävling som ska hållas finns det några saker som är extra viktiga; att tävlingen ska gå smidigt att anordna och att de tävlandes insatser ska bedömas likvärdigt. Detta är även viktigt när tävlingen anordnas med tekniska hjälpmedel. Dessa hjälpmedel behöver vara minst lika användbara som deras icke-tekniska motsvarig-heter för att de ska vara värda att använda, och detta är exakt vad som har varit målet med detta kandidatprojekt.

1.1 Motivering

Under projektet har ett system för Teknikåttan utvecklats. Teknikåttan är en frågetävling med mål att främja teknikintresset hos ungdomar, och varje år deltar mellan 20 och 25 tusen hög-stadieelever. Systemet utvecklades för att byta ut det system som tävlingen nu använder, vilket har beskrivits som krångligt och omodernt. Systemet består av två huvudsakliga delar: ett verktyg för att skapa och redigera tävlingar och ett verktyg för att utföra dessa tävlingar.

1.2 Syfte

Syftet med denna rapport är att samla de erfarenheter och kunskaper som projektgruppen har fått genom att utföra detta projekt. Detta görs för att dessa erfarenheter ska kunna an-vändas i framtida projekt, både i utvecklings- och arbetsmiljö. Dessa erfarenheter inkluderar hur man arbetar i grupp, hur man kommunicerar och samarbetar med en kund samt hur dokumentation såsom en systemanatomi kan bidra till utvecklingen av ett system.

1.3 Frågeställningar

I denna rapport kommer följande frågeställningar att undersökas och besvaras: 1. Hur kan systemet implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?

(16)

1.4. Avgränsningar

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?

1.4 Avgränsningar

Totalt har projektgruppens medlemmar lagt 380 timmar vardera på projektet. Bland des-sa timmar utgörs en stor del av utveckling av systemet, annan dokumentation och andra kursmoment.

(17)

2 Bakgrund

I detta kapitel presenteras bakgrunden för både projektet och projektgruppen. Här tas både relevanta erfarenheter kring tidigare projekt upp samt bakgrunden till behovet hos kunden som projektet försöker lösa.

2.1 Kunden

Kunden för detta projekt är Teknikåttan som är ett samarbete mellan tolv olika lärosäten runtom i Sverige. Teknikåttan anordnar årligen tävlingar för elever som går i årskurs åtta i grundskolan, med syftet att främja elevernas teknikintresse. Teknikåttan startades 1993 vid Linköpings tekniska högskola [1]. För att skapa och utföra tävlingarna har de sedan ett tag tillbaka använt sig utav ett liknande system till det som beställdes under detta projekt. Det gamla systemet har däremot byggts upp på så sätt att komponenter har lagts till vid behov under en längre period, vilket har resulterat i en avsaknad av struktur. Det tidigare systemet har även beskrivits som ”buggigt” och svårt att använda av kunden, och av den anledningen ville kunden att ett nytt system skulle utvecklas, gärna från grunden. Eftersom det var ett gammalt system som skulle förbättras visste kunden vilka egenskaper de ville ha hos det nya systemet. Därmed fick projektgruppen en ganska lång kravlista i början av projektet.

I det tidigare systemet skrevs tävlingen ut på papper och delades ut till deltagare och do-mare. Dessa pappersversioner användes i kombination med ett digitalt presentationssystem. Till följd av detta behövde alla dokument ändras individuellt och skrivas ut manuellt vid förändringar. Kunden hade även ett fullt digitalt alternativ, med det var så svårt att använda och så opålitligt, så de valde ofta att fortsätta med papper.

Projektgruppen har haft kontakt med tre personer på kundsidan, alla med olika roller inom Teknikåttan. Det var en person som arbetade som General Manager för Teknikåttan i Linköping, en som arbetade med utvecklingsteamet samt en som var en av representanterna för Linköping inom organisationen. Av dessa skulle projektgruppen framförallt ha kontakt med representanten och utvecklaren, som båda hade hög förväntan på projektet. Utvecklaren hade fram tills nyligen varit student på Linköpings universitet och var medveten om att en stor del av ett kandidatprojekt går åt till annat än utveckling, medan representanten hade uppfattningen att en mycket större del av kursen skulle läggas på utveckling.

(18)

2.2. Projektgruppen

2.2 Projektgruppen

Projektet som denna rapport behandlar är en del av kursen TDDD96 Kandidatprojekt i pro-gramvaruutveckling vid Linköpings universitet. Projektgruppen består av åtta studenter från Linköpings universitet där fem av studenterna studerar civilingenjörsprogrammet i datatek-nik, och de resterande tre medlemmarna studerar civilingenjörsprogrammet i mjukvarutek-nik. Nästan ingen i gruppen hade sedan tidigare någon större erfarenhet av webbutveckling. Alla medlemmar i projektgruppen har tidigare haft kurser där de har fått arbeta i grup-per och utföra ett projekt. Dessa projekt har däremot varit mindre och med lägre tidsbudget än detta projekt. I dessa kurser har även gruppmedlemmarna i olika omfattning fått arbeta utifrån krav och en skriven kravspecifikation.

I de tidigare projektarbetena har projektgrupperna till viss del bestått av engagerade med-lemmar vilket gjorde att arbetet kom igång relativt snabbt samt att arbetet gav resultat. I dessa projektarbeten har även arbetet delats upp på ett bra sätt vilket resulterade i en jämn arbets-börda samtidigt som det fanns ett bra utbyte av kunskap mellan medlemmarna och en bra sammanhållning.

Det som har varit mindre bra under vissa av de tidigare projekten är att grupperna inte har varit överens om hur arbete skulle gå till. Det har berott på både olika ambitionsnivåer och dålig kommunikation samt ojämn fördelning av arbete. I tidigare projekt har inte tiden spenderats på ett effektivt sätt, och mycket tid har gått åt till delar som inte var relevanta för slutprodukten. Tråkiga och jobbiga uppgifter har undvikits och sparats till slutet och arbetet har inte varit så pass strukturerat att flaskhalsar har kunnat undvikas. Det finns även erfa-renheter från att viktiga delar av projektet har glömts bort, att versionshanteringen inte har fungerat och att det har uppstått konflikter när medlemmarna blivit stressade nära deadlines.

(19)

3 Teori

I detta kapitel presenteras den teori som lägger grund för resten av rapporten.

3.1 JavaScript

JavaScript är ett högnivåspråk som används vid webbutveckling på både klientsidan och ser-versidan. JavaScript introducerades för första gången 1995 av Netscape som ett verktyg att bygga interaktiva hemsidor [2].

3.2 Node.js

Node.js är byggt på Google Chromes V8 JavaScript-motor [3], och används för att bygga nät-verksapplikationer. Node.js är inte trådbaserat, vilket innebär att inga lås behöver implemen-teras. Detta innebär att användare av Node.js inte behöver vara oroliga för att ett dödläge ska ske [4].

3.3 Express

Express är ett ramverk för Node.js som används vid utveckling av serversidan för hemsidor och mobila applikationer. Express används främst för att hantera HTTP-förfrågan och öppna IP-portar för kopplingar mellan server och klient [5].

3.4 Single-page-applikation

Single-page-applikation eller SPA är en teknik som används för att göra hemsidor mer respon-siva. En hemsida som är gjord med SPA kan ladda ner ny data samtidigt som den visar upp information för användare. Detta ger snabbare uppdateringar och göra att en hemsida upp-levs som mer responsiv. Med SPA behöver man inte ha tomma laddningsskärmar när man klickar på länkar till andra sidor på samma hemsida, vilket är fallet om man inte använder sig av SPA [6].

(20)

3.5. React

3.5 React

React är ett kodbibliotek till JavaScript för användargränssnitt vid webbutveckling [7] som kan användas vid utveckling av single-page-applikationer [8].

3.6 Redux

Redux är ett bibliotek som hjälper till att hantera tillstånd och kommunikation mellan olika komponenter i webbapplikationer. Detta gör det lättare att testa individuella funktioner och se hur de påverkar programmet. React-Redux är en kraftfull kombination som underlättar utvecklingen och leder till mer förutsägbara program med färre buggar [9].

3.7 HTTP-förfrågan

HTTP-förfrågan (eng. HTTP-Request) är en standard för att skicka och ta emot data relaterat till webbsidor. En förfrågan skickas från klienten och tolkas av servern. Servern kan då välja att skicka tillbaka ett svar (eng. response) eller göra något annat med datan som skickades [10].

3.8 Polling

Polling är när en enhet begär data regelbundet från en annan enhet för att få uppdateringar av tillståndet hos den andra enheten [11].

3.9 WebSockets

WebSocket är en kommunikationsmetod som tillåter en klient och server att kommunicera med varandra utan att använda polling. Med WebSockets kan klienten och servern skicka meddelanden direkt till varandra utan att vänta på en förfrågan [12].

3.10 MongoDB

MongoDB är ett dokumentbaserat databassystem som är utvecklat för moderna applikationer. I MongoDB sparas all data som JSON-liknande objekt, vilket gör det lättare för programme-rare att tänka på och använda databasen [13].

3.11 Material Design och Material-UI

Material Design är riktlinjer för hur man kan designa moderna system och hemsidor. Rikt-linjerna är utformade för att skapa enhetligt utseende mellan system och enheter. Material Design är inspirerat av hur fysiska system ser ut och försöker förmedla det med hjälp av skuggor, ljus, färg och form för att visa djup, vikt och interaktionsmöjligheter [14].

Material-UI är ett företag som jobbar mot att förena React och Material Design. Detta gör de genom att bygga öppna källkodsverktyg som kan användas av utvecklare för design av webbapplikationer [15].

3.12 Scrum

Scrum är en arbetsmetod som används i små team på runt sju personer. Det är en agil utveck-lingsmetod som går ut på att man arbetar i sprintar. En sprint är en period på cirka en till fyra veckor som utvecklingen delas upp i [16].

Innan utvecklingen börjar tar man fram en produktbacklogg, vilket är en lista över funk-tionalitet man önskar att den färdiga produkten ska ha. Varje sprint inleds sedan med en

(21)

3.13. GitLab

sprintplanering där mål för vad som ska göras under sprinten hämtas från produktbacklog-gen. Dessa mål bryts ner i issues vilket är mindre aktiviteter som oftast tar maximalt en dag att genomföra. Issues sedan i en sprintbacklogg så att teamets medlemmar kan hämta nya issues så fort en issue blir klar [16].

Under varje arbetsdag under sprinten hålls ett stand-up-möte, även kallat ett dagligt scrum-möte. Under mötet ska varje medlem besvara tre frågor:

• Vad har du gjort? • Vad ska du göra?

• Har du några hinder i utvecklingen? [16]

Efter varje sprint hålls ett möte med kunden och övriga intressenter kallat sprintgenom-gång. Under detta möte redovisas vad som har gjorts under sprinten och eventuella mål som inte slutfördes. Under sprintarna är fokuset att alltid ha en fungerande prototyp som utveck-las iterativt vid varje sprint. Då arbetet sker iterativt ligger det stort fokus på utvärdering och reflektion av arbetet. Därför hålls det i slutet av varje sprint ett möte där sprinten som varit utvärderas, kallat sprintåterblick [16].

I Scrum finns rollerna produktägare, scrummästare och utvecklingsteam. Produktägaren an-svarar för att hålla koll på kundens krav och önskemål och ser till att produkten utvecklas för att skapa värde för kunden. Scrummästaren ser främst till att Scrum följs av utvecklingstea-met. Scrummästaren coachar och vägleder vid aktiviteter som dagligt scrummöte och sprint-planering. Utvecklingsteamet består av de teammedlemmar som utvecklar själva produkten [16].

I Scrum finns även ett antal verktyg man kan använda. Ett av dessa är en Scrum-tavla (eng. Task Board eller Scrum Board), där aktiviteter som ska göras skrivs upp. En enkel Scrum-tavla består av tre kolumner; ”Att göra”, ”Gör”, och ”Färdigt”. Aktiviteterna flyttas sedan mellan dessa kolumner beroende på hur utvecklingen av dessa ser ut [16].

3.13 GitLab

GitLab är ett webbaserat verktyg för att arbeta med versionshanteringsverktyget Git [17]. Git-Lab tillhandahåller fler funktoner förutom just versionshantering, bland annat en så kallad GitLab Issue Board som kan användas som en Scrum-tavla [18].

3.14 Zoom

Zoom Video Communications är ett företag som jobbar inom modern företagskommunikation och erbjuder en molnplattform för video- och ljudkonferenser. Deras produkt, Zoom, finns både som ett datorprogram och som en mobilapplikation [19] [20].

3.15 Slack

Slack är ett molnbaserat kommunikationsverktyg. Grupper, lag eller företag kan ansluta sig via en inbjudan de får av deras administratör. Kommunikation inom Slack sker via olika ka-naler. Kanalerna kan antingen vara offentliga eller privata och kan sorteras efter exempelvis ämne eller arbetsgrupp. De offentliga kanalerna är öppna för alla förutsett att de har blivit inbjudna dit. Privata kanaler är för mindre grupper att kommunicera och kan utnyttjas för att dela en stor grupp i mindre delgrupper [21].

(22)

3.16. Messenger

3.16 Messenger

Messenger är ett kommunikationsverktyg av Facebook [22], som erbjuder möjligheten att ska-pa en kommunikationsgrupp. Andra tjänster är bland annat möjligheten att delta i ett samtal eller en gruppvideochatt. Den erbjuder även möjligheten för omröstningar och platsdelning för att underlätta planering [23].

3.17 CMMI

CMMI står för Capability Maturity Model Integration och är en samling av processer som an-vänds för att förbättra utveckling i projekt och organisationer. Processerna i CMMI delas in i olika nivåer som är kopplade till ett teams mognad, vilket ger en logisk utvecklingsplan med olika processer. Processerna har dessutom olika nivåer över hur väl de har uppnåtts [24].

3.17.1 Riskhantering

Riskhantering är ett processområde inom CMMI som fokuserar på att identifiera potentiella risker innan de inträffar för att kunna förebygga dem samt planera hur de ska tas om hand ifall de inträffar. Detta arbete sker under hela livstiden hos projektet eller produkten. Målet med riskhantering är att bestämma vart risker kan uppstå, vilka risker som finns i projektet samt skapa en plan för hur dessa risker ska hanteras [25].

(23)

4 Metod

Detta kapitel går igenom ett antal metoder som har använts under kandidatprojektet.

4.1 Utvecklingsmetod

På gruppens första två möten valdes projektet och sedan fick varje gruppmedlem en unik roll. Rollerna som fanns inom projektet var följande:

Analysansvarig Har kontakt med kunden och har ansvar för kravspecifikationen.

Arkitekt Ansvarig för arkitekturen i projektet.

Dokumentansvarig Ansvarar för framtagandet av dokument.

Konfigurationsansvarig Ansvarar för versionshanteringen under projektet.

Kvalitetssamordnare Leder kvalitetsarbetet.

Teamledare Leder gruppen under arbetet och representerar gruppen för utom-stående parter.

Testledare Ansvarar för de tester som görs på systemet.

Utvecklingsledare Leder utvecklingsarbetet.

4.1.1 Innan utveckling

Innan utvecklingsdelen av projektet började jobbade gruppen på att bygga upp kontakten med kunden och på att ta ett antal beslut för att underlätta för samarbetet inom gruppen.

4.1.1.1 Kommunikation med kunden

I början av projektet skapades en kravspecifikation kring de krav som kunden satte upp och utefter de förutsättningar projektgruppen hade. Denna togs fram genom ett flertal möten med kunden och via mejl. Det var gruppens analysansvarige som hade ansvar för att förhandla med kunden och skapa en klar och tydlig kravsepcifikation. Gruppen tog även hjälp av sin

(24)

4.1. Utvecklingsmetod

handledare med prioriteringarna på kraven samt hur och om vad man kan förhandla med kunden om. I samband med detta hölls även ett möte med hela projektgruppen där kunden visade upp det befintliga systemet och förklarade vilka egenskaper hos systemet de ville ha.

Efter att kravspecifikationen var klar och godkänd av både projektgruppen och kunden togs ett avtal fram. Kunden hade ansvar för att skapa ett kontrakt utefter de riktlinjer Linkö-pings universitet och kandidatkursens examinator satt upp. Alla medlemmar i projektgrup-pen och en representant från nämnden för skolverksamhet vid Linköpings universitet skrev under kontraktet.

4.1.1.2 Dokumentation

I projektets första fas arbetade gruppens medlemmar med ett antal dokument för att dels vara överens med varandra över vad som gällde kring arbetsätt, mål och arkitektur och dels för att försäkra kunden om att det inte finns några missförstånd med kraven. Dessa dokument skrevs för att användas under utvecklings- och testningsfasen av projektet.

4.1.1.2.1 Mötesanteckningar

Under projektets gång har veckovisa grupp- och handledarmöten hållits. Det har även hål-lits möten med kunden. Under dessa möten hade en nävarande gruppmedlem uppdraget att anteckna det som diskuterades och bestämdes under mötet. Detta gjordes dels för att frånva-rande medlemmar skulle kunna ta del av möten efteråt och dels för att göra det möjligt att gå tillbaka till tidigare möten och se vad som beslutats.

4.1.1.2.2 Gruppkontrakt

I början av projektet sammanställdes ett kontrakt mellan gruppmedlemmarna. I kontraktet stod det hur gruppen skulle hantera olika scenarion, hur gruppmöten skulle gå till, hur kon-takten mellan gruppmedlemmarna skulle ske samt hur beslut skulle fattas. Alla medlemmar i gruppen skrev under gruppkontraktet.

4.1.1.2.3 Kravspecifikation

Efter att gruppen hade gått igenom kraven som de fick av kunden började gruppen arbeta med en kravspecifikation. I kravspecifikationen fanns en kort beskrivning om hur gruppen uppfattade kundens bild på slutprodukten samt en lista med mätbara krav. Kraven hade prioriteringar beroende på hur viktiga de var för kunden. Efter att kunden och handledaren hade tittat på dokumentet och granskat det uppdaterades kravspecifikationen enligt deras synpunkter.

Kraven i kravspecifikationen prioriterades efter tre olika nivåer, detta inspirerades utifrån kundens kravlista. Där fanns det krav som var så pass viktiga att systemet inte skulle fungera utan dem, krav som var viktiga för kunden men inte för att systemet skulle fungera samt krav som skulle uppfyllas i mån av tid. Krav med högst prioritet var då krav som behövde utföras för att projektet skulle kunna ses som avslutat, och krav med lägre prioritet skulle uppfyllas endast om högre prioriterade krav var uppfyllda och tid fanns kvar. För att bedöma prioriteringen av kraven utgick gruppen till stor del utifrån kundens önskningar och åsikter. Avsikten var då att eventuellt sänka högprioriterade krav om det skulle visa sig att tiden inte räckte till.

4.1.1.2.4 Projektplan

Projektplanen skrevs tidigt i projektet. Dokumentet innehöll en beskrivning av projektets mål och arbetssätt. Syftet med den var att skapa en plan för hur projektet skulle utföras och med vilka medel.

(25)

4.1.1.2.5 Kvalitetsplan

Kvalitetsplanen innehöll standarder och processer som skulle följas under projektets gång. Dokumentet skulle användas som en garanti för kvalitet och som ledning under arbetet. Do-kumentet innehöll bland annat hur teamarbetet skulle se ut, vilka standarder dokumenten skulle följa och kodstandarder. Den innehöll även de tre kvalitetskraven som gruppen skulle fokusera på under projektets gång. Dessa var underhållbarhet, användbarhet och pålitlighet.

4.1.1.2.6 Arkitekturdokument

I arkitekturdokumentet beskrevs arkitekturen och designvalen som projektgruppen skulle göra under projektets gång. Det beskrev även systemets begränsningar och motiveringar till varför de användes.

4.1.1.2.7 Systemanatomi

Tidigt i projektet togs en systemanatomi fram för systemet. För att göra detta identifierades anatomer, som är funktionalitet i systemet, för att sedan arrangera dessa i ett slags beroende-diagram. Den funktionalitet som användaren kan utföra placeras överst och den funktionali-tet som dessa första anatomer är beroende av hamnar under dessa med en anslutning. Detta bildar en trädstruktur där anatomer i botten inte är beroende av några andra anatomer, och anatomer längre upp i trädet är beroende av fler anatomer. Denna systemanatomi är menad som ett stöd för att visa upp systemets funktionalitet och dess beroenden.

4.1.2 Under utveckling

Nedan listas metoder som användes under projektets gång.

4.1.2.1 Scrum

För utveckling av produkten har ett Scrum-liknande ramverk använts. Scrum-liknande i det-ta sammanhang innebär att inte alla beståndsdelar ifrån det klassiska ramverket användes. Under de två första sprintarna användes sprintplanering och Scrum-tavlan i GitLab för att hålla koll på de uppdrag som utfördes av gruppen. I resten av sprintarna lades stand-up-möten och sprintåterblick till. När det gällde standup-stand-up-mötena har gruppen träffats varannan dag istället för varje.

En viktig del av Scrum är att bestämma roller. Följande roller bestämdes (inom parentes anges vilken eller vilka gruppmedlemmar som hade rollen):

• Scrummästare (utvecklingsledare) • Produktägare (analysansvarig)

• Utvecklingsteam (alla teammedlemmar)

Produkten utvecklades i två veckor långa sprintar med undantaget första sprinten som grup-pen beslutade skulle vara tre veckor lång. Varje sprint inleddes med en sprintplanering. Un-der sprintplaneringen använde sig gruppens medlemmar av en brainstorming-session där en sprintbacklogg togs fram. Varje aktivitet ifrån sprintbackloggen lades upp på Scrum-tavlan där alla teammedlemmar tydligt kunde se vilka aktiviteter som var ej påbörjade, påbörjade eller slutförda. I början av utvecklingen delades aktiviteterna upp i tre större områden:

• Frontend-aktiviteter • Backend-aktiviteter • GUI-aktiviteter

(26)

Inför varje av resterande sprintplanering-möten bestämdes ytterligare områden om det in-sågs att nya behövdes. Aktiviteterna tilldelades gruppmedlemmar och Scrum-tavlan redige-rades. Aktiviteternas namn hölls så korta som möjligt.

Varje sprint avslutades med en sprintgenomgång som hölls tillsammans med kunden. Under mötet presenterade representanter från projektgruppen hur långt gruppen hade kom-mit med sitt arbete. Efter det fick representanterna från kundens sida ge sina synpunkter och åsikter. Dessa möten krävde inga förberedelser från kundens sida.

4.1.2.2 Utvecklingsverktyg

Varje teammedlem fick själv välja vilken utvecklingsmiljö denne skulle använda för att skri-va och felsöka kod. Kunden skri-var ganska öppen för förslag på kodbibliotek eller ramverk som skulle väljas för utvecklingen av systemet. Det bestämdes av hela teamet att använ-da React-biblioteket för frontend-delen, Node.js tillsammans med Express för backend-delen och MongoDB för databasen. Valet av de tre utvecklingsverktygen baserades på popularitet och flexibilitet, då det inte finns några tydliga ramar hos det använda kodbiblioteket som måste följas.

4.1.2.2.1 React

Valet av detta bibliotek bestämdes av hela gruppen. Eftersom tävlingssystemet för Teknikåt-tan skulle utvecklas som en single-page-applikation med många komponenter i sig valdes detta bibliotek. Varje gruppmedlem kunde skriva sina egna komponenter och använda kom-ponenterna som skrevs av andra. Senare kunde separata bitar av systemet integreras ihop utan större problem. React valdes även på grund av dess enkelhet för användning och liten mängd av kodmallar som behövde följas.

4.1.2.2.2 Redux

Systemets arkitektur krävde ett globalt tillstånd där data tillhörande aktuell session skulle sparas. För att kunna behålla en del av informationen som skulle delas av flera komponenter användes Redux-biblioteket. Trots att detta bibliotek kräver att en del förbestämda mallar följs ansågs det vara en bra avvägning för att kunna behålla datan som var kritisk för det utvecklade systemet.

4.1.2.2.3 Node.js med Express

För att servern skulle kunna kommunicera med både databas och frontend behövdes det en miljö där kommunikation mellan dessa kunde implementeras. Eftersom frontend-delen utvecklades med hjälp av JavaScript bestämdes det att backend-delen också skulle skrivas i JavaScript, och Node.js valdes för det.

Express-ramverket hanterar många av basfunktionerna för webbkommunikation och är lätt att lägga till extra funktionalitet på. Express används för att tolka och processera HTTP-förfrågan och skicka tillbaka HTTP-svar.

4.1.2.2.4 WebSocket-biblioteket ws

Det utvecklade systemet krävde ett kontinuerligt flöde av data mellan olika delar av systemet som körs på separata datorer. WebSocket-biblioteket ws användes för att tillhandhålla denna möjlighet. Biblioteket gjorde det möjligt att betrakta varje ny användare av systemet som en ny klient som blev tilldelad en ny WebSocket-anslutning. Koden för en WebSocket-server skrevs även med hjälp av detta bibliotek. Servern användes för att ta emot och distribuera meddelanden mellan klienterna.

(27)

4.1.2.3 Designverktyg

För design använde sig gruppen av det öppna källkodsverktyget Material-UI. Verktyget an-vändes för att designa de olika vyerna som ingick i systemet. Projektgruppen använde sig av ett antal element som Material-UI erbjuder som exempelvis knappar, ikoner och textfält.

4.1.2.4 Kommunikationsverktyg

Kommunikation inom gruppen och med externa parter skedde med hjälp av ett antal kom-munikationsverktyg. Mejl användes för kommunikation med kunden, handledaren och kurs-ledningen. Kundkontakten sköttes av gruppens analysansvarige. Kontakt med handledaren och kursledningen sköttes främst av teamledaren. För kommunikation inom gruppen an-vändes tre olika kommunikationsverktyg: Messenger, Slack och mejl. Gruppen kom överens om att använda Slack för interna diskussioner kring projektet. Messenger skulle användas för diskussion kring ämnen som inte var relaterade till projektet. Mejl användes främst av teamledaren för att vidarebefordra mejl som hade fåtts av antingen handledaren eller kurs-ledningen.

Den 18:e mars 2020 gick Linköpings universitet över i distansläge på grund av covid-19 [26]. Detta resulterade i att allt arbete inom kursen TDDD96 skedde på distans under andra perioden av vårterminen. Under den perioden användes Zoom istället för möten på plats. Den användes för ljud- och videokonferenser inom gruppen men även under möten med utomstående.

4.1.2.5 Versionshantering

För versionshantering har Git använts. För varje ny funktion som skulle läggas till i syste-met gjordes en ny Git-branch. Varje Git-branch döptes enligt en standard som bestämdes av gruppens konfigurationsansvarige. Innan ny funktionalitet sammanslogs med huvudgrenen granskades dess kod av åtminstone en teammedlem som inte var med och skrev koden för denna branch. Under utvecklingen sparades all kod på Git. Det bestämdes av projektgruppen att koden som skrevs i nya grenar alltid skulle finnas tillgänglig för alla gruppmedlemmar på GitLab oavsett kvalitet på den. När nya koden lades upp på Git användes commit-meddelanden enligt den mall som visas i tabell 4.1. Mallen bestämdes av gruppens konfigurationsansvari-ge.

Tabell 4.1: Mall för commit-meddelanden. Etikett Användning

FEAT Ny funktionalitet

FIX Buggfix

REFACTOR Refaktorisering av kod

STYLE Formattering, till exempel saknade semikolon; ingen förändring av kod DOC Förändring av dokumentation

TEST Tillägg eller förändring av tester; ingen ändring av produktkod VERSION Uppdatering av versionsnummer; ingen ändring av produktkod

DBG Ändring av debuggningskod eller ramverk; ingen ändring av produktkod HACK Tillfällig lösning för att få utveckling att röra sig framåt

WIP Under utveckling

MERGE Sammanslagning av grenar DEFAULTS Ändring av förinställda värden

(28)

4.2. Metod för att fånga erfarenheter

4.1.2.6 Testning

Under projektets gång utfördes tester för att verifiera att systemet fungerade korrekt och upp-fyllde kravspecifikationen. Främst utfördes integrations- och acceptanstester eftersom syste-mets moduler och enheter var relativt små och det därmed bedömdes som att tid sparades in genom att inte utföra några dokumenterade tester på denna nivå.

På grund av sin typ utfördes testerna i slutet av utvecklingsfasen i samband med att del-system slutfördes och integrerades. Eftersom del-systemet främst drevs av grafiska interaktioner så utfördes tester manuellt då det bedömdes som tidsineffektivt att skriva automatiserade tester för något grafiskt. Detta beslutades dels för att om någon komponent grafiskt flyttades så måste testet skrivas om och dels för att volymen av test som skulle utföras var för liten för att kunna dra nytta av automatisering.

I versionshanteringingssystemet så fanns det inbyggd testning som utfördes automatiskt på koden. Dessa test bestod bland annat av att verifiera om systemet kunde installeras och om den kunde kompileras.

4.2 Metod för att fånga erfarenheter

Under projektarbetet har erfarenheter kring arbetsmetodik, sammanhållning och versions-hantering fångats in för att kunna dra lärdom av gruppmedlemmarnas tankar samt för att kunna förbättra arbetet under projektets gång. Detta skedde vid tre tillfällen; innan utveck-lingen började, i mitten och i slutet av projektarbetet. Första insamlingstillfället fokuserade på tidigare projektarbeten, vad som fungerade bra och dåligt samt vad som kunde förbättras. Insamlingen av erfarenheter skedde gemensamt i grupp.

I mitten av projektet samlades erfarenheter in kring gruppmöten, sammahållning, ver-sionshantering, uppdelning av arbete och arbetsmetodik. Även denna insamling skedde un-der gruppdiskussion.

Tredje insamlingstillfället skedde i slutet av projektarbetet. Då samlades erfarenheter kring arbetsmetodik in via ett anonymt formulär och erfarenheter kring gruppmöten, ver-sionshantering och uppdelning av arbete skedde i grupp.

4.3 Riskhantering i projektet

Under projektet har projektgruppen arbetat med processmålet riskhantering. Utformningen av detta processmål har gjorts i samband med coachingtillfällen med studenter som läser kursen TDDE46 Programvarukvalitet på Linköpings universitet. Innan projektgruppen börja-de med utvecklingen fastställbörja-des börja-det vilka risker som initialt fanns i projektet. Sannolikheten samt konsekvensen att dessa risker inträffar utvärderades och graderades från på en skala från 1 till 4. Skalan för sannolikhet var; sällan, ibland, regelbundet och ofta. Skalan för kon-sekvensen var; ofarlig, måttlig, allvarlig och katastrof. Dessa värden användes sedan för att beräkna riskmagnituden genom ekvation 4.1.

riskmagnitud=sannolikhet ˆ konsekvens (4.1) Sannolikheten och konsekvensen av att dessa risker skulle inträffa utvärderades i början av projektet och sedan kontinuerligt under arbetetsgången som ett sätt att dokumentera ut-vecklingen av riskerna. Denna utvärdering skedde i en riskanalys som skedde i slutet av varje sprint på sprintåterblickarna. Under denna riskanalys planerades det även hur riskers nega-tiva påverkan och sannolikhet kunde minimeras i form av uppgifter som kunde göras under gruppens kommande sprint. Utvärderingen av riskerna presenterades i en riskmatris, enligt tabell 4.2. För att en risk ska ses som acceptabel måste den befinna sig i det gröna området i matrisen.

(29)

4.4. Insamling av information för skapat värde för kunden

Tabell 4.2: Mall för en riskmatris. Sannolikhet

Sällan Ibland Regelbundet Ofta

Konsekvens

Ofarlig Måttlig Allvarlig Katastrof

4.4 Insamling av information för skapat värde för kunden

För att besvara frågeställningarna måste information samlas in från kunden. För att avgöra om värde har skapats för kunden utförs en jämförelse mellan tidigare versioner av systemet som kunden använt sig av och det nya systemet som leveras till kunden. Tidigare versioner kommer jämföras med avseende på tiden det tog att skapa en tävling, hur lång tid det tar för någon ny att lära sig systemet och hur intuitivt det är att skapa en tävling.

För att få kvantifierbar data som kan användas till en jämförelse så utfördes testuppgifter på det ursprungliga systemet och det nyproducerade systemet. Eftersom båda systemen var begränsade i vilka funktioner som fanns implementerade så designades testen för att vara så snarlika som möjligt och testa samma funktioner för att därmed kunna jämföras. För att testen ska vara meningsfulla och representera den framtida användningen av systemet så valdes test med uppgifter som förmodas typiska.

Tabell 4.3 visar de tester som utfördes på båda systemen. Under varje tests gång mättes den totala tiden och antal interaktioner med systemet, med interaktioner menas knapptryck-ningar eller textinmatknapptryck-ningar.

(30)

4.4. Insamling av information för skapat värde för kunden

Tabell 4.3: Tester som utfördes på det gamla och det nya systemet

Test Utförande Skapa frågor 1. Skapa en tävling 2. Lägg till en flervalsfråga 3. Lägg till en textfråga 4. Lägg till en pausslide 5. Spara tävlingen Redigera en fråga 1. Skapa en tävling. 2. Lägg in en bild

3. Ändra storleken på bilden 4. Ändra positionen

5. Spara tävling

Köra en tävling

1. Starta en tävling

2. Bläddra igenom alla sidor och svara på frågor 3. Avsluta tävlingen

(31)

5 Resultat

I detta kapitel presenteras de resultat som projektet har gett. Detta inkluderar bland annat hur slutresultatet av systemet ser ut, erfarenheter som har samlats in och hur dokument har använts.

5.1 Systembeskrivning

Det slutgiltiga systemet består av tre delar: klient, server och databas. Dessa kan också grup-peras i frontend och backend, där servern och databasen tillhör backend, och klienten tillhör frontenden.

Frontend-delen är främst skapad i React och skriven i språken JavaScript, HTML och CSS för att bygga upp ett användarvänligt gränssnitt. Denna del har i uppgift att erbjuda ett gränssnitt där användaren kan hantera frågor och tävlingar, samt visa upp den tävling som klienten ska köra. När en användare har anslutit sig till en tävling visas den relevanta informationen upp på användarens skärm. Denna information är olika beroende på vilken roll användaren har i tävlingen. Till exempel ser domaren vad de tävlande svarar, styrdatorn ser vad de tävlande ser, vad projektorn ser, texten som ska läsas upp, samt knappar för att gå vidare i tävlingen. De tävlande ser frågetexten på en skärm, och svarsfält på en separat surfplatta.

Administratörer kan på klientsidan skapa tävlingar och frågor. Dessa frågor kan sedan bli redigerade i redigeringsverktygen, se figur 5.1, som finns på klienten. Här kan nya element som till exempel text och bilder läggas in, position på element kan flyttas, element kan flyttas på djupet, element kan raderas, text kan ändras i storlek och fontstil, med mera. När dessa ändringar sparas skickas de till servern som kommunicerar med databasen om uppdatering-en. När bilder läggs till laddas dessa upp på serven och kan bli tilldelade taggar så man enkelt kan söka på de bilder som redan finns uppladdade.

Servern på backend-delen är även skriven i språket JavaScript i ramverket Node.js till-sammans med Express. Denna server håller koll på de tävlingar som körs samt har i uppgift att tillhandahålla klienten på frontend-delen med data från databasen, samt bilder från ser-vern. Servern har dessutom i uppgift att ta hand om data som kommer från klienten. Detta kan vara både att skapa en ny tävling i databasen, samt att redigera den data som är sparad för en fråga när användaren har använt redigeringsverktyget på klienten.

(32)

5.1. Systembeskrivning

Figur 5.1: Redigeringsdelen av systemet

Databasen är av typen MongoDB och data lagras på JSON-format. Detta underlättar för webbapplikationer eftersom nästan all information hanteras i JSON-format på både klienten och servern. Dessutom kan man enkelt skicka data mellan dessa två på just JSON-format.

Kommunikationen mellan klienten och servern sker främst via HTTP-förfrågan, men även via WebSockets för att kontinuerligt uppdatera klienten utan att användaren ger in-put. Detta är användbart när styrdatorn skickar ett kommando att byta bild på alla klienter kopplade till tävlingen. Då skickas denna information vidare från servern till dessa klienter via WebSockets. Ingen kommunikation sker mellan klienten och databasen direkt, utan all denna kommunikation sker via servern som både validerar datan och tar hand om den så den sätts in på rätt vis.

5.1.1 Dokument

Under projektet togs ett antal dokument fram, som beskrivs i avsnitt 4.1.1.2. Dokumenten som togs fram var följande:

Gruppkontrakt Ett dokument som togs fram för att nedteckna de förhållingsregler som alla i gruppen var överens om att följa så att samarbetet skulle fungera.

Kravspecifikation Ett dokument som listar upp de krav som produkten ska uppfylla.

Projektplan Ett dokument som togs fram för att identifiera de milstolpar som skulle uppnås och vilka aktiviteter som skulle uppfyllas.

Kvalitetsplan Ett dokument som beskriver de standarder och metoder som gruppen skulle följa för att uppnå önskad kvalitet på slutprodukten.

Arktekturdokument Ett dokument som beskriver systemets arkitektur.

Testplan Ett dokument som beskriver hur tester ska genomföras och dokumen-teras.

Testrapport Ett dokument som dokumenterar de utförda testerna.

(33)

5.2. Processbeskrivning

5.1.2 Systemanatomi

En systemanatomi som illustreras i figur 5.2 var ett av TDDD96-kursens obligatoriska krav. Diagrammet påbörjades efter första kundmötet då alla gruppmedlemmar hade bra överblick över vad systemet skulle innehålla. Systemanatomin skapades dock innan kravspecifikatio-nen hade godkänts av kunden. Vid kundens granskning av detta diagram har det visat sig att diagrammet kunde ha saknat vissa anatomer men samtidigt uppgav kunden att detta kan bero på hans kunskapbrist angående systemanatomin.

Innan utvecklingen påbörjades var systemanatomin ett bra stöd för att snabbt se över och förstå vilka delar systemet skulle bestå av. Efter att kravspecifikationen hade godkänts av kunden var systemets funktionalitet tydlig för alla gruppmedlemmar. Detta gjorde att syste-manatomin förlorade sitt syfte och det beslutades om att inte lägga mer tid på att uppdatera denna. Det insågs att andra dokument var tillräckligt bra stöd för att komma in i utvecklings-fasen av projektarbetet.

I mitten av sprint fyra beslutades det att redovisa systemanatomin främst för att se hur väl diagrammet stämde överens med det utvecklande systemet. Det visade sig att diagrammet saknade flera anatomer för systemets redigeringsverktyg, samt anatomer som skulle illustre-ra WebSockets.

Figur 5.2: Systemanatomi av tävlingssystem för Teknikåttan

5.2 Processbeskrivning

I detta projekt har en process från CMMI använts för att öka kvaliteten på projektet. Pro-jektgruppen har valt att fokusera på området riskhantering (RSKM), detta då ett av kundens viktigaste krav är att systemet ska vara stabilt när det körs. Eftersom systemet mestadels kommer att användas under tävlingar som pågår på flera orter samtidigt är det viktigt att systemet fungerar utan problem. Detta gäller även när utrustningen som använder systemet ändras.

5.2.1 Förbättring av process

För att förbättra den valda processen gick gruppen tillbaka till riskidentifierinsfasen under varje iteration. Genom att införa denna förbättring kunde nya risker fångas upp, både de som missats under första riskidentifieringen samt de som uppstår under arbetets gång. Det nya arbetssättet bestod då av att både välja ut de risker som nästkommande sprint ska fokusera på

(34)

5.2. Processbeskrivning

samt identifiera nya risker som uppstått. Detta skedde under sprintplaneringen tillsammans med hela gruppen.

5.2.2 Processresultat

Resultatet från riskhanteringen var att gruppen initialt bedömde att det fanns nio risker som var relevanta för projektet. Dessa var:

R1. Kunden är inte nöjd med slutprodukten.

R2. Gruppen kommer inte överens med kunden om systemets krav. R3. Gruppen uppnår inte de förbestämda baskraven i tid.

R4. Alla tre surfplattor går sönder.

R5. Kodbibliotek eller ramverk uppdateras. R6. Systemet kraschar.

R7. Systemet tappar wifi-uppkoppling. R8. Databasen svarar inte.

R9. Vyer blir inte synkade.

Efter andra sprinten så utökades denna lista med risken: R10. Någon i gruppen insjuknar i Covid-19.

I tabell 5.1 presenteras deras initiala riskmagnitud.

Tabell 5.1: Riskmatris över alla riskers initiala riskmagnitud. Sannolikhet

Konsekvens

Ofarlig R5

Måttlig R2 R1, R10

Allvarlig R4 R3

Katastrof R7 R6, R8 R9

De risker som arbetades aktivt med under utvecklingen av projektets produkt var risk R1, R2, R3, R6, R8, R9 och R10. Vilka risker som hanterades under vilka sprintar presenteras i tabell 5.2. Förändringen av sannolikheten och konsekvensen av dessa risker presenteras i tabell 5.3 som är riskmatrisen efter sprint #4.

Tabell 5.2: Tabell över vilka risker som behandlades under respektive sprint under utveck-lingen.

Sprint Risker som behandlades #1 R1, R2, R3, R6 #2 R2, R3, R6, R8, R9 #3 R3, R6, R9, R10

(35)

5.3. Värdering av system

Tabell 5.3: Riskmatris efter sprint #4. Sannolikhet

Konsekvens Ofarlig R5 Måttlig R2 R1, R10 Allvarlig R4 R3 Katastrof R7, R8 R6 R9

5.3 Värdering av system

I tabell 5.4 och 5.5 presenteras resultatet av mätningarna som utfördes för att jämföra värdet mellan det tidigare systemet och det som producerats under detta projekt. Mätningarna syf-tar till att undersöka hur mycket tid som gick åt med det ursprungliga systemet kontra det nya. Notera att interaktioner betyder antingen ett knapptryck eller textinmatning, att skriva in en text räknas alltså som en interaktion och inte en per karaktär. Testerna för både det ursprungliga och det nya systemen utfördes av projektgruppen.

Tabell 5.4: Resultat av testerna på det ursprungliga systemet

Skapa frågor

Tid 3 minuter 30 sekunder Interaktion 69 interaktioner

Kommentar Lätt att klicka fel, svårt att intuitivt hitta vart man bör klicka krävdes 35 minuter video för att lära sig. Redigera frågor

Tid 2 minuter 14 sekunder Interaktion 48 interaktioner

Kommentar Krånglig process, svårare att förstå och utföra då uppgiften att lägga in en bild är utspridd över många olika skärmar och moment, man behöver till exempel kopiera en URL för att lägga in bilden vilket inte är intuitivt. Positioneringen av bilden kunde endast uppnås genom att redigera källkoden till sliden. Köra tävling

Tid 57 sekunder

Interaktion 22 interaktioner

Kommentar Lätt när man visste var länkarna till de olika vyerna var.

Tabell 5.5: Resultat av testerna på det nya systemet

Skapa frågor

Tid 1 minut 6 sekunder Interaktion 22 interaktioner Kommentar Tydlig väg till resultat. Redigera frågor

Tid 44 sekunder

Kommentar Intuitivt, bra flöde, processen liknade andra programs processer.

Köra tävling

Tid 36 sekunder

(36)

5.4. Gemensamma erfarenheter

5.3.1 Jämförelse

Här kommer resultat för mätningarna utförda på de två olika systemen jämföras. Ena tillfället var vid mitten av projektet och andra tillfället vid slutet. I kapitel 2 finns även erfarenheter som samlades in innan projektet startade.

5.4 Gemensamma erfarenheter

Totalt samlades erfarenheter från gruppen in vid tre tillfällen där ett skedde innan utveck-lingen och två skedde under utveckutveck-lingen.

5.4.1 Erfarenhetsfångst vid mitten av projektet

I mitten av projektet samlades erfarenheter in från projektarbetet. Erfarenheterna som samla-des in var om gruppmöten, gruppkontrakt, struktur av arbetet, versionshantering och grup-pens sammanhållning.

Vid detta tillfället tyckte gruppen att mötesetiketten kunde förbättras då strukturen på mötena hade varierat. Detta berodde bland annat på att alla i gruppen inte följde dagord-ningen, vilket gjorde att en sak inte avhandlades i taget. Det hade även funnits tillfällen då diskussioner gått ifrån ämnet. Dock upplevdes det som om mötena var öppna för alla att prata om det de ville och få det man ville få sagt. Distansläget som då precis hade börjat på-verkade även detta då mötena kändes mer strukturerade och samlade. Gruppen hade pratat om att införa dagliga stand up-möten för att förbättra gruppmötena.

Erfarenheterna kring gruppkontraktet som skrevs i början av projektet var att det i sig inte gjorde så stor skillnad. Det som var fördelaktigt med att skriva ett gruppkontrakt var att projektet hade pratats igenom och att allas förväntningar hade diskuterats så att gruppen kände att de var på samma plan angående projektet.

När det kom till de andra dokumenten upplevde gruppen att det hade fungerat bra. Ar-betet delades upp så rättvist som möjligt och alla i gruppen kände sig nöjda över det. Alla hade även fått hjälp om de behövde det. Även arbetet i själva utvecklingen delades upp gans-ka ligans-ka tyckte gruppen. Dock hade själva planeringen kring de issues som skulle genomföras för varje sprint varit luddiga. Mycket tid gick åt till inlärning och dokumentation. Dock hade gruppen börjat beräkna hur mycket tid som skulle läggas på vardera sak vilket bidrog till bättre planering.

Andra lite mer tekniska erfarenheter från första halvan av projektet var att det var en del strul med Git samt att mycket av gruppens arbete blev utspritt över flera kommunikations-kanaler och olika texteditorer. Det behövdes redas ut och bestämmas vad som skulle ske var. Även distansläget gav lite motgångar i kommunikationsväg.

Under denna halva av projektet anordnades även en kick-off och en afterwork (AW). Gruppen upplevde inte att kick-offen gjorde så mycket skillnad i sammanhållningen i grup-pen. Dock menar gruppen att det redan var bra innan och att det är anledningen. Efter AW däremot tyckte gruppen att de kom varandra mycket närmare. Denna skedde lite senare i projektets första halva. Erfarenheterna från gruppens sammanhållning i stort var att det ha-de blivit bättre gradvis genom hela projektet och att ha-det redan från början var bättre än ha-det hade varit i tidigare projektgrupper.

5.4.2 Erfarenhetsfångst i slutet av projektet

Från avstämningen i slutet av projektet samlades erfarenheter in igen, som vid mitten av pro-jektet. Gruppen upplevde att effektiviteten hos mötena hade blivit bättre sedan övergången till distans. Dock ansåg gruppen att vissa möten drog ut på tiden mer än nödvändigt, även om viktiga saker diskuterades. En ytterligare fördel som gruppen lyfte fram med distansmöte

(37)

5.5. Kundkontakt

var att de kan ske med kortare varsel, vilket har underlättat arbetet och gruppens beslutsfat-tande.

När det kommer till gruppkontraktet anser gruppen att det inte har bidragit så mycket som det hade kunnat denna period. Gruppen ansåg att om en uppföljning av gruppkontrak-tets innehåll skulle gjorts kunde det varit mer till hjälp.

Planeringsmässigt anser gruppen att det har funnits mer struktur i arbetet. Det har fortfa-rande funnits förbättringsområden, de stora övergripande målen för arbetet var fortfafortfa-rande inte lika tydligt som det borde varit. Det hade behövts mer specificerade mål för varje sprint. Dock tycker gruppen att skapandet av issues har fungerat bättre, tydligare issues med bättre tidsestimering. En ytterligande sak som det flesta i gruppen saknade vid utvecklingen var milstolpar för veckan. De anser att milstolpar skulle hjälpa till med att strukturera arbetet och få gruppen att jobba mot samma gemensamma mål.

Versionshanteringen i andra halvan av projektet har inte förbättrats. Samma problem som uppstod i första halvan av projektet fanns kvar och många har fortfarande inte så bra koll på hur man använder sig av Git.

Sammanhållningen var fortsatt väldigt stark i gruppen, dock har distansläget påverkat den negativt. Gruppen tog upp att de spontana sociala interaktionerna försvann i och med distansläget. Det har även ansett att mötena i sig har blivit mer effektiva vilket var bra. Dock innebar detta att småpratet har försvunnet vilket har påverkat sammanhållningen.

5.5 Kundkontakt

Generellt sett upplevdes kontakten med kunden som smidig. Kunden gav snabb respons på mejl och det fanns möjlighet att ringa kunden vid behov. Möjligheten att ringa bedömdes däremot aldrig behövas under projektet. De två representanterna hos kunden som projekt-gruppen främst hade kontakt med, som beskrevs i avsnitt 2.1, var båda anställda vid Linkö-pings universitet. Detta gjorde att fysiska möten enkelt kunde ordnas under perioden innan distansläge.

Eftersom Teknikåttan är en samarbetsorganisation mellan 12 olika lärosäten var det svårt för dess representanter att fatta beslut på egen hand. Representanterna behövde ibland åter-komma med svar på gruppens funderingar då de behövde ta kontakt med de resterande 11 lärosätena och fatta beslut utifrån allas behov. Representanterna kunde till exempel inte skri-va på avtalet med projektgruppen. I stället fick en representant från nämnden för skolsam-verkan vid Linköpings universitet göra det.

När det kom till prioritering av krav hade de två representanterna hos kunden vitt spridda åsikter. Krav som en person var villig att sänka var extremt viktigt för den andra. Det blev flera diskussioner mellan dem under kundmöten angående prioritering.

Under projektets senare delar började gruppen diskutera hur risken för att inte hinna klart med projektet hade ökat. Projektgruppen ansåg då att det låg i kundens intresse att var-na dem och berätta hur det låg till. Beslutet som togs av projektgruppen diskuterades med handledaren som tyckte att det var lämpligast att försöka få kunden att prioritera antingen funktionalitet eller användbarhet. På en sprintgenomgång som låg sex veckor innan projek-tets slutdatum togs risken upp med kunden. Projektgruppen erbjöd då ett antal förslag på åtgärder som kunde tas för att undvika leverans av ett totalt oanvändbart system. Dessa åt-gärder var bland annat att prioritera funktionalitet över användbarhet och fokusera på vissa delar mer än andra. Svaret på detta var att sänka krav på hur de interna delarna av syste-met såg ut rent estetiskt men att samtidigt avvakta och se hur det skulle gå mot slutet av kommande sprint.

Under sprintgenomgången som låg fyra veckor innan projektets slutdatum tog kunden upp vad de ansåg var ett problem med utvecklingsmetodiken som projektgruppen hade an-vänt. De påpekade att de inte hade fått se ett sammanhållet fungerande system ännu och att projektgruppen istället hade fokuserat på små detaljer. Detta gjorde att under