GutenTag : Ett användarvänligtverktyg för datamärkning

2021 | LIU-IDA/LITH-EX-G--2021/054--SE

GutenTag – Ett användarvänligt

verktyg för datamärkning

GutenTag – A user-friendly tool for data labeling

Adam Hjalmarsson

Joseph Hughes

Linnéa Ivansson

John Lindström

Oscar Lönnqvist

Maximilian Vorbrodt

Annie Wång

Handledare : Tobias Wang Examinator : Kristian Sandahl

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/. © Adam Hjalmarsson Joseph Hughes Linnéa Ivansson John Lindström Oscar Lönnqvist Maximilian Vorbrodt Annie Wång

Denna rapport behandlar ett projektarbete i kursen TDDD96 Kandidatprojekt i program-varuutveckling som utförts av sju studenter på Linköpings Universitet under vårterminen 2021. Arbetet kretsade kring utvecklingen av en webbapplikation vid namn GutenTag på uppdrag av konsultföretaget TietoEVRY. Applikationens syfte var att hjälpa deras kunder att komma igång med maskininlärning. Detta genom att möjliggöra datamarkering och göra processen både enkel och rolig. Applikationen publicerades med öppen källkod på plattformen GitHub för att främja vidareutveckling av produkten.

Rapportens gemensamma del börjar med att introducera och kontextuelisera projektet, och beskriver sedan vilka arbetsmetoder och tekniker som användes för att utveckla pro-dukten. Därefter beskrivs projektets resultat som diskuteras för att nå fram till slutsatser kring de centrala frågeställningarna. Sist finnes individuella bidrag skrivna av projektgrup-pens sju medlemmar som djupdyker in i ett relaterat ämne.

Projektgruppen vill tacka David Buffoni på TietoEVRY som ständigt varit tillgänglig för dis-kussioner, frågor och rådgivning gällande utveckling av produkten. Projektgruppen vill även rikta ett stort tacka till sin handledare Tobias Wang tillsammans med kursledningen i kursen TDDD96 vid Linköpings universitet år 2021.

Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller ix Definitioner xi 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 2 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 1.5 Kontext . . . 2 2 Bakgrund 3 2.1 Kundens bakgrund och syfte . . . 3

2.2 Gruppens tidigare erfarenheter . . . 3

3 Teori 5 3.1 Artificiell intelligens . . . 5

3.2 Programmeringsverktyg och ramverk . . . 6

3.3 Verktyg . . . 8

7.2 Uppfyllande av syfte . . . 50

A Automatisk testning i ett kandidatprojekt – Adam Hjalmarsson 51 A.1 Inledning . . . 51 A.2 Teori . . . 52 A.3 Metod . . . 53 A.4 Resultat . . . 54 A.5 Diskussion . . . 55 A.6 Slutsatser . . . 57

B Jämförelse av Docker, Docker Compose, Docker Swarm och Kubernetes i webb-utvecklingsprojekt – Joseph Hughes 59 B.1 Introduktion . . . 59

B.2 Bakgrund och teori . . . 60

B.3 Metod . . . 61

B.4 Resultat . . . 62

B.5 Diskussion . . . 64

B.6 Slutsatser . . . 65

C Samarbete i dokumentredigerare på distans - Linnéa Ivansson 67 C.1 Introduktion . . . 67 C.2 Teori . . . 68 C.3 Metod . . . 70 C.4 Resultat . . . 71 C.5 Diskussion . . . 73 C.6 Slutsatser . . . 75

D En undersökning av JSON Web Tokens – John Lindström 76 D.1 Introduktion . . . 76 D.2 Teori . . . 77 D.3 Metod . . . 79 D.4 Resultat . . . 80 D.5 Diskussion . . . 81 D.6 Slutsatser . . . 82

E Användning av spelifiering i en kandidatgrupp – Oscar Lönnqvist 83 E.1 Introduktion . . . 83 E.2 Teori . . . 84 E.3 Metod . . . 87 E.4 Resultat . . . 88 E.5 Diskussion . . . 89 E.6 Slutsatser . . . 90

F Analys av React och varför dess popularitet ökar inom webbutveckling -Maximilian Vorbrodt 92 F.1 Introduktion . . . 92 F.2 Teori . . . 93 F.3 Metod . . . 93 F.4 Resultat . . . 95 F.5 Diskussion . . . 98 F.6 Slutsatser . . . 100 vi

G.2 Teori . . . 102 G.3 Metod . . . 104 G.4 Resultat . . . 108 G.5 Diskussion . . . 117 G.6 Slutsatser . . . 120 Litteratur 121

3.1 Översikt över designmönstret model-view-controller. . . 7

4.1 Utvärderingsenkät för sprintåterblick. . . 14

5.1 Gruppens systemanatomi för produkten. . . 21

5.2 GutenTags startsida för ej autentiserade besökare. . . 22

5.3 GutenTags startsida för en autentiserad adminanvändare. . . 23

5.4 GutenTags sida för projektspecifika inställningar . . . 24

5.5 GutenTags datamärkningssida för projekt av typen dokumentklassificering. . . 25

5.6 GutenTags datamärkningssida för projekt av typen bildklassificering. . . 26

5.7 GutenTags datamärkningssida för projekt av typen sekvensmärkning. . . 27

5.8 GutenTags datamärkningssida för projekt av typen sekvens-till-sekvensmärkning. 28 5.9 GutenTags inställningssida. . . 29

5.10 GutenTags sida för att skapa ett projekt. . . 30

5.11 GutenTags sida för att hantera användare. . . 31

5.12 GutenTags sida för att ändra lösenord. . . 32

5.13 Kodgranskningsproceduren för kodintegreringen i projektet. . . 35

5.14 Scrumboard i ClickUp för en sprint. . . 36

A.1 Black-boxtestning. . . 53

C.1 LaTeX som indata (vänster), PDF-filen som utdata (höger). . . 69

D.1 Exempel hur ett JSON-objekt kan se ut . . . 77

E.1 3C modellen. . . 86

G.1 Enkät uppdelad i avsnitt . . . 106

G.2 Resultat från fråga 1 . . . 110 G.3 Resultat från fråga 2 . . . 110 G.4 Resultat från fråga 4 . . . 110 G.5 Resultat från fråga 5 . . . 111 G.6 Resultat från fråga 8 . . . 111 G.7 Resultat från fråga 9 . . . 111 viii

0.1 Definitioner . . . x 5.1 Sprintutvärdering. . . 37

Denna sektion avser att definiera begrepp som används i rapporten. Tabell 0.1: Definitioner

Ord Beskrivning

Frontend Del del av ett datorsystem eller en applikation som användaren interagerar med.

Backend Den del av ett datorsystem eller en applikation som inte direkt nås av användaren, vanligtvis ansvarig för lagring och manipulering av data. AI Förkortning av artificiell intelligens.

HTTP Ett protokoll för förfrågan och svar inom dator-system.

HTTP-förfrågan Klientens förfrågan till servern.

HTTP-svar Serverns information till följd av klientens begä-ran.

Axios Ett JavaScript-bibliotek för att skicka och ta emot HTTP-förfrågningar

ORM Förkortning för Object–relational mapping.

YAML Rekursiv förkortning för YAML Ain’t Markup

Language.

Nätverksport En siffra som identifierar data från en viss tjänst eller process på ett nätverk.

Volym En logisk indelning av en hårddisk.

TypeScript En utökning av JavaScript som adderar statisk typning.

Git Ett versionshanteringsverkyg som kan användas vid utveckling av mjukvara.

PyTest Ett testramverk som tillåter användare att skriva testkod med Python.

JEST Ett testramverk för JavaScript.

Lisam Linköpings universitets samarbetsplattform för lärande.

SharePoint Innehållshanteringssystem utvecklat av Micro-soft.

RESTful API En arkitekturprincip för hur man designar ett API.

Sass Förkortning för Syntactically Awesome Style

Sheets och är ett scriptspråk som kompilerar till CSS.

andra att använda mjukvaran hur som helst för-utsatt att upphovsmannen attributeras.

Artificiell intelligens (AI) och maskininlärning är två begrepp som i dagens samhälle är kopp-lat till framtidens teknologi. I takt med att kunskapen kring ämnet ökar blir allt fler aktörer intresserade av att vara en del av utvecklingen och användning av AI blir mer av en norm [1]. Företag som vill börja med AI är många men steget kan vara stort. Det är från denna utma-ning som projektet Data Labeling Product och produkten GutenTag framtogs.

Denna rapport framför en redovisning samt diskussion kring ett kandidatarbete utfört av en grupp studenter vid Linköpings universitet. Rapporten framför också vilka metoder som använts för att utföra projektet samt relevant teori. Rapporten innehåller även sju individu-ella delar som alla gruppens medlemmar bidragit med. De individuindividu-ella delarna djupdyker i specifika ämnen relaterade till projektet och produkten. Projektets mål var att utveckla en unik webbapplikation för att markera data. Produktens namn är GutenTag vilket kommer användas i rapporten. Detta kapitel presenterar projektets motivering, syfte, frågeställningar, avgränsningar, och kontext.

1.1

Motivering

För att flera företag ska kunna komma igång med den växande AI-utvecklingen hade grup-pen som mål att göra det lättare att komma igång. För att lära en AI med hjälp av övervakat lärande måste det finnas tillgång till markerad träningsdata. Detta för att träna AI:n att se mönster. Markerad data kan vara kostsamt för företag som inte har AI som högsta prioritet. Att hitta exakt den markerade datan för att träna en specifik AI är också svårt. Därför är det betydligt mindre kostsamt, både i tid och pengar, att skapa egen testdata genom att personal manuellt markerar testdata.

I dagsläget är de datamärkningsverktygen som har öppen källkod komplexa, avancera-de och monotona. Därför gav projektgruppens uppdragsgivare gruppen i uppdrag att lösa detta. Med GutenTag är det simpelt att starta, ladda upp data, markera datan och extrahera datan. Med extra fokus på spelifiering och ett simpelt användargränssnitt blir erfarenheten att markera data rolig istället för monoton.

1.2

Syfte

Projektets syfte var att utveckla ett roligt, lättanvändbart och lättillgängligt verktyg i form av en webbapplikation för att markera data. Detta för att ge små företag och privatpersoner en chans att bryta sig in på AI-marknaden samt att ge gruppens kund, TietoEVRY, ett verktyg att använda vid företagets konsultarbeten relaterade till AI.

Denna rapports syfte är att ge en inblick i projektet, hur det utfördes, och dess resultat. Den har även som syfte att leda en diskussion kring gruppens val under projektets gång samt hur dessa påverkat resultatet.

1.3

Frågeställning

1. Hur kan systemet implementeras för att skapa värde för kunden?

2. Vilka erfarenheter kan dokumenteras från GutenTag som kan vara intressanta för fram-tida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan spelifiering appliceras på ett projekt av denna skala?

5. Vilket stöd har React.JS och Bootstrap bidragit med under utvecklingen?

1.4

Avgränsningar

En begränsning var att projektgruppen på grund av den då rådande covid-19 pandemin inte kunde befinna sig på Campus Valla. Samarbete och utvecklingen var därmed begränsad till projektgruppens privata datorutrustning och digitala verktyg för möten.

1.5

Kontext

Denna rapport är skriven för kursen TDDD96 Kandidatprojekt i programvaruutveckling på In-stitutionen för datavetenskap vid Linköpings universitet. Ett krav från kursen var en budget på 400 timmar per person på projektet, vilket totalt blir 2 800 timmar för hela gruppen. Kursen hade som krav att ett antal dokument relaterade till projektet utöver denna rapport skulle skapas, dessa var:

• Projektplan

Detta kapitel avser att presentera gruppens samt kundens bakgrund, varför produkten skulle utvecklas och vad dess ändamål var.

2.1

Kundens bakgrund och syfte

TietoEVRY är ett IT-konsultföretag med högkvarter i Finland som erbjuder en rad olika tjäns-ter till exempel inom att ge företag digitala lösningar och affärsmodeller, och modarnisation inom företagets verksamhet. Från deras expertis inom AI och maskininlärning har de upp-täckt en stor efterfrågan av dessa tekniker på dagens marknad [2]. När ett marknadsbehov uppstår krävs det en reaktion, och en del av TietoEVRYs reaktion är att finna lösningar på att göra AI mer lätttillgängligt för allmänheten. Den här projektgruppen och produkten Guten-Tag är en del i den processen.

2.2

Gruppens tidigare erfarenheter

Projektetgruppen bestod av sju studenter som alla studerade till civilingenjörer vid Linkö-pings universitet. Fyra av medlemmarna studerade programmet civilingenjör inom datatek-nik medan resterande medlemmar studerade programmet civilingenjör inom mjukvarutek-nik.

Alla medlemmar hade vid tidigare tillfällen i sin utbildning tagit del av projektarbeten, men inget projekt i denna skala. Studenterna som gick datateknik hade under hösten 2020 ett projekt i kursen TSEA29 - Konstruktion med mikrodatorer där fokuset var på dokumentation av ett projektarbete, programmering av hårdvara och samarbete i grupper om sex personer. Studenterna som gick mjukvaruteknik hade under hösten 2020 ett projekt i kursen TDDD92 AI-projekt där fokuset var programmering av mjukvara och AI, samt samarbete i grupper om sex personer. Utifrån dessa kurser tog studenterna med sig kunskaper kring att påbörja, genomföra och avsluta ett projekt i mindre grupper.

Förkunskaper inom gruppen var blandad då några medlemmar tidigare arbetat med verktygen som används inom projektet utanför universitetsutbildningen. Programmerings-kunskaper var också spridda då de som gick mjukvaruteknik tidigare haft kurser om databa-ser och webbdataba-servrar, medan de som gick datateknik ej haft det. De studenter som gick data-teknik hade däremot kunskaper om design av användarvänliga applikationer genom kursen

TDDD60 - Interaktiva system, som var användbart inom projektarbetet. De spridda kunska-perna inom gruppen bidrog till att gruppmedlemmarna lärde upp varandra och resultatet blev en gruppvis jämn kunskapsbas.

I detta avsnitt behandlas den relevanta teorin, som berör de tekniker och verktyg, som har använts i projektet. Syftet är att ge läsaren underlag och förståelse för teorin som kommer behandlas och diskuteras i senare delar av rapporten.

3.1

Artificiell intelligens

Artificiell intelligens är ett omfattande ämne med en stor mängd grenar och begrepp. Detta delavsnitt beskriver grundläggande begrepp relaterat till projektet.

3.1.1

Maskininlärning

Ett av områdena inom artificiell intelligens är maskininlärning. Idén med maskininlärning är att utveckla applikationer som genom analys av träningsdata kan specificera en funktion som identifierar datans mönster och egenskaper. Applikationen kan sedan mata in ny data i funktionen som klassificeras och returneras som utdata. Kvaliteten på klassificeringen beror huvudsakligen på mängden och kvaliteten på träningsdatan samt valet av träningsalgoritm [3].

3.1.2

Datamärkning

I många tillämpningsområden är det fördelaktigt att träningsdatan förmarkeras av männi-skor innan den matas in i träningsalgoritmen. Det finns alltså två huvudsakliga tillväga-gångssätt: övervakad maskininlärning med hjälp av förmarkerad träningsdata och oöver-vakad maskininlärning med omarkerad träningsdata [4].

Oövervakad maskininlärning används i områden där det går att utnyttja datorers möns-terigenkänning för att hitta mönster i komplicerade datamängder. Exempelvis för att grup-pera ihop konsumenter utefter deras köphistorik. I andra områden hjälper det att ta nytta av mänsklig intuition och där kan en människa exempelvis översätta texter från ett språk till ett annat så att algoritmen kan analysera översättningarna och lära sig av dem. Att manuellt märka data är däremot dyrt och tidskrävande [4].

De datamärkningsuppgifter som GutenTag hanterar är:

• Dokumentklassificering, där en användare märker ett helt textstycke. 5

• Sekvensklassificering, där en användare märker individuella sekvenser i ett textstycke. • Sekvens-till-sekvensmärkning, där en användare översätter en textsekvens till en

an-nan.

• Bildklassificering, där en användare märker hela eller en del av en bild.

3.2

Programmeringsverktyg och ramverk

För att genomföra projektet användes ett antal olika programmeringsverktyg och ramverk, och denna sektion presenterar grundläggande teori som berör detta.

3.2.1

Python

Python är ett dynamiskt typat programmeringsspråk med enkel syntax. Python kan tillämpas inom många områden och används ofta inom datavetenskap, maskininlärning och för att tillhandahålla webbtjänster [5].

3.2.2

Flask

Flask är ett mikroramverk för Python som är specialiserat för webbutveckling. Enligt ska-parna av ramverket, The Pallet Projects, är Flask designat för att vara lätt att använda och komma igång med. Flask erbjuder förslag på verktyg och bibliotek som kan användas, vilket gör att det ses som ett flexibelt ramverk [6] [7].

3.2.3

JavaScript

JavaScript är ett lättviktat programmeringsspråk som är mest välkänt och använt som ett skriptspråk för att skapa dynamiska webbsidor. Trots att namnet JavaScript liknar Java är de två väldigt skilda språk [8].

3.2.4

React

React är ett bibliotek för JavaScript och TypeScript som utvecklades av Facebook. Bibliote-ket är komponentbaserat vilBibliote-ket innebär att sidans olika delar håller koll på sitt eget tillstånd. Webbsidan som skapas är därför uppbyggt av komponenter, som i sin tur kan vara upp-byggda av delkomponenter. React är intelligent i att utvecklaren enbart behöver specificera komponenternas olika tillstånd och överlåter rendering och cachning till biblioteket [9].

3.2.5

CSS

3.2.7

Relationsdatabaser och SQL

En relationsdatabas lagrar data i tabeller innehållande fält vars värden följer fördefinierade restriktioner. Datan kan sedan kommas åt med olika sorters nycklar och därmed kan ett fält peka till fält i andra tabeller. Structured Query Language (SQL) är ett standardiserat pro-grammeringsspråk för att hämta och manipulera data i relationsdatabaser. SQL har två stora fördelar jämfört med konkurrenter; dels är det med SQL möjligt att komma åt mer informa-tion från databasen med ett enda kommando och dels specificerar inte programmeraren hur data skall kommas åt [12].

3.2.8

PostgreSQL

PostgreSQL är en av flera implementationer av SQL-standarden. Olika implementationer kan skilja sig i prestanda och hur nära de följer standarden. Överensstämmelse med SQL-standarden indikerar robust och felsäker datahantering. Det finns idag inga relationsdata-baser som stämmer överens med den fullständiga SQL-standarden, men PostgreSQL påstår sig komma väldigt nära och samtidigt leverera hög prestanda. En till fördel med PostgreSQL är att teknologin tillhandahålls med en tillåtande källkodslicens, MIT-licens, och är gratis att använda.

3.2.9

SQLAlchemy och objekt-relationell mappning

SQLAlchemy är en SQL-verktygslåda och objekt-relationell mapper (förkortat ORM) för att skapa databaser i Python. ORM innebär att SQLAlchemy är ett objektorienterat system som konverterar databastabeller till klasser, tabellrader till objekt, samt celler till objekt-attribut. Detta gör det möjligt att skapa enkla och komplexa relationer mellan tabellerna samtidigt som verktyget gör det användarvänligt [13].

3.2.10

Model-view-controller

När arkitekturen till systemet skulle tas användes designmönstret model-view-controller som utgångspunkt. Designmönstret definierar ett antal komponenter samt hur informationsflödet mellan dem ser ut. En bild över model-view-controller kan ses i figur 3.1.

Figur 3.1: Översikt över designmönstret model-view-controller.

3.3

Verktyg

Under detta delavsnittet kommer de verktyg som projektgruppen använt sig av under pro-jektets gång definieras och beskrivas ur ett teoretisk perspektiv.

3.3.1

Docker

Docker är ett verktyg som används för att köra applikationer i kortlivade och isolerade mil-jöer, benämnt behållare (eng. container). Syftet med att använda Docker är att underlätta utveckling och lansering av applikationer genom att endast låta programmet köras i en för-bestämd och väldefinierad virtuell miljö [14]. All konfiguration som krävs för att köra pro-grammet specificeras i en Docker-fil vilket gör systemet väldigt portabelt. Behållare skiljer sig från virtuella maskiner i att de utnyttjar dynamisk resursallokering istället för att varje ma-skin tar upp en förbestämd mängd resurser. Verktygen kan potentiellt snabba på utveckling och minska antalet miljörelaterade buggar och erbjuder även lättviktighet i jämförelse med virtuella maskiner.

3.3.2

Docker Compose

Docker Compose är ett verktyg som används för att definiera och köra applikationer be-stående av flera Docker-behållare. Konfigurationen som specificeras i en YAML-fil beskriver förhållandena mellan applikationens olika tjänster. Tjänsterna kan då exponera olika portar på virtuella nätverk och komma åt filer på virtuella volymer som vid behov kan bevaras mel-lan sessioner [15]. Behållarna startas och stängs ner med ett gemensamt kommando vilket underlättar applikationers utveckling och lansering.

3.3.3

Visual Studio Code

Visual Studie Code (VSCode) är en textredigerare publicerad av Microsoft med öppen käll-kod. Textredigeraren har genom tillägg stöd för syntaxmarkering och felsökning i en stor mängd programmeringsspråk [16].

3.3.4

GitHub

GitHub är ett populärt verktyg för utvecklare att spara sina utvecklingsprojekt och nätverka med andra utvecklare. GitHub grundar sig i versionshanteringsvektyget Git, framtaget av operativsystemet Linux grundare Linus Torvalds. Gits versionshantering gör det möjligt för utvecklare att gå tillbaka till tidigare versioner av projektet för att bättre förstå förändringar inom filer. GitHub gör det även möjligt för användare att samarbeta på ett projekt genom att användarna klonar projektet från GitHub ner på sitt egna filsystem. GitHub har även en

3.3.6

ClickUp

ClickUp är ett molnbaserat samarbets- och projekthanteringsverktyg som passar projekt-grupper och även företag. Funktionerna inkluderar kommunikations- och samarbetsverktyg, uppgiftstilldelningar, statusar, och ett aktivitetsfält. ClickUp fungerar väl för projekthante-ring där arbetsmetodiken i val har varit till exempel Scrum. [19]

3.3.7

L

_TEX

LA_{TEX är ett markup-språk specifikt anpassat för vetenskapliga och tekniska dokument. Det}

som särskiljer LA_{TEX från många andra format är att användare av L}A_{TEX kan mer fokusera}

på innehållet i dokumentet än själva utseendet. Precis som i många programmeringsspråk grundar sig LA_{TEX i funktioner som kan användas för att skapa funktionalitet i dokumentet}

och några vanliga funktioner är att skapa listor, sätta en gemensam header och fixa innehålls-förteckning med mera [20].

3.3.8

Overleaf

Projektgruppen för GutenTag använde sig av textredigeraren Overleaf för att skriva alla do-kument relaterat till projektet. Overleaf är speciellt designat för grupparbeten där projektdo-kumenten skrivs i LA_{TEX, för att skapa mer transparens i dokumentskrivandet och möjlighet}

för att lämna kommentarer till varandra [21].

3.4

Övrigt

Den teorin som inte kan klassas under de föregående rubrikerna hamnar här. Detta innefattar arbetsmetodiken Scrum, teori kring testning och begreppet spelifiering.

3.4.1

Scrum

Scrum är en arbetsmetodik som använder sig av ett agilt tänkesätt för att utveckla, leverera och upprätthålla komplexa produkter. Scrum består av teori, värden, gruppen, händelser, och artefakter.

Teorin grundar sig i empirism och magert tänkande. De tre viktiga aspekterna bakom teorin är transparens, inspektion, och adaption. Dessa aspekter kombineras för att skapa en effektiv och produktiv miljö för problemlösning.

Värdena som Scrum utgår ifrån är åtagande, fokus, öppenhet, respekt, och mod. Syftet med dessa värden är att ge gruppen en rikting i deras arbete, agerande och beteende.

Gruppen består av alla delaktiga i projektet, och innefattar rollerna:

• Utvecklare: Utvecklare är en grupp av personer som utvecklar de olika komponenterna i projektet.

• Produktägare: Uppdraget som produktägaren har är att maximera det värde som ut-kommer av det utvecklingsteamet levererar. Detta görs genom att prioritera rätt saker i rätt tid, genom en så kallad produkt-backlog.

• Scrummästare: Rollen handlar om att facilitera att ramverket för Scrum följs och att driva gruppens ständiga förbättring och utveckling.

Gruppen bör ej vara fler än tio personer. De händelser som finns i ramverket är:

• Sprint: En Sprint, även iteration, är alltid tidsbestämd (till exempel en vecka) och inom den ryms planering, utveckling och utvärdering.

• Sprintplanering: På planeringen inför sprinten går Utvecklingsteamet igenom produkt-backlogen tillsammans med Produktägaren och utifrån detta beslutas vad som kan genomföras och hur.

• Daglig Scrum: Daglig Scrum är ett dagligt återkommande planeringsmöte för Utveck-lingsteamet. Mötet får inte överstiga 15 minuter i längd.

• Sprintgenomgång: En sprintgenomgång är till för att kommunicera den utveckling som skett (eller inte skett) under en Sprint.

• Sprintåterblick: Under sprintåterblicken utvärderar gruppen den senaste Sprinten uti-från arbetssätt, verktyg, relationer och annat värdefullt.

Under händelserna finns det en del saker som inte är definierade och som meningen är att varje enskild instans av Scrum själva skall definiera. Dessa är sprintlängd, metod för sprint-planering, samt metod för sprintgenomgång och sprintåterblick.

Artefakter som finns i Scrum är produkt-backlog, sprint-backlog, och inkrement. Varje artefakt har även ett åtagande kopplad till sig. För produkt-backlog är det produktmål, för sprint-backlog är det sprintmål, och för inkrement är det definitionen av avklarade uppgifter [22].

3.4.2

Testnivåer

Det finns olika nivåer av tester som kan utföras på kod beroende på vad det är som ska testas. Dessa nivåer är:

• Enhetstestning – Tester där enskilda funktioner testas.

• Integrationstestning – Tester som innefattar integration av två eller flera enheter. • Systemtestning – Tester som testar systemet i sin helhet. Ofta kopplade till kraven som

satts upp.

• Acceptanstestning – När kunden får produkten och får utföra de tester som hen vill. [23].

3.4.3

Spelifiering

Spelifiering är tillämpningen av designelement och principer från spel i icke-spelskontexter. Det kan också definieras som en uppsättning aktiviteter eller processer för att lösa problem genom att använda eller tillämpa spelelementens egenskaper. Spelifiering används i

appli-Denna sektion avser att presentera och beskriva projektgruppens metoder för utveckling, erfarenhetsfångning och utbildning.

4.1

Utvecklingsmetod

I detta delavsnitt presenteras projektgruppens utvecklingsmetod i detalj för att ge läsaren en inblick i hur produkten GutenTag kom till och bearbetades.

4.1.1

Roller inom projektgruppen

För att underlätta utvecklingsarbetet för gruppen fick varje gruppmedlem en specifik roll, och till varje roll fick medlemmarna ett antal ansvarsområden. Gruppens roller var följande:

• Teamledare: Ledde arbetet och representerade teamet utåt. Under projektets gång an-svarade teamledaren över att projektet uppfyllde målen, att interna processer följdes och att mötesprotokoll fördes. Teamleadaren såg även till att en arbetsmiljö sattes upp för resten av gruppen och personen hade sista ordet i frågor som berörde gruppen. • Analysansvarig: Hade den främsta kontakten med kunden och såg därigenom till att

projektet uppfyllde kundens verkliga behov. Analysansvarig såg även till att dokumen-tera de krav som teamet och kunden kom fram till i kravspecifikationen.

• Arkitekt: Identifierade gränssnitt och komponenter inom projektet, tog övergripande tekniska beslut i vad som berörde arkitektur och såg därefter till att en stabil arkitektur togs fram som hela projektet följde. Arkitekten dokumenterade arkitekturen i arkitek-turdokumentet.

• Utvecklingsledare: Ansvarade för det mer detaljerade arbetet inom utvecklingen och, ledde och fördelade det valda arbete bland resterande teammedlemmar. Utveckling-ledaren fattade beslut kring stilguider och satte upp en utvecklingsmiljö som passade valda stilguiderna.

• Testledare: Satte upp en automatisk testmiljö och beslutade om systemets aktuella sta-tus. Skrev en testplan, såg till att kontinuerlig testning genomfördes och uppdaterade

ständigt testrapporten med ny data. Testledaren validerade även att funktionella krav uppfylldes.

• Kvalitetssamordnare: Ansvarade för att projektet höll en viss nivå av kvalitet och hade ett uppföljningsansvar vad gällde kvalitet. Kvalitetssamordnare såg till att kvalitetspla-nen skrevs och efterlevdes.

• Dokumentansvarig: Såg till att dokument skrevs inför leveranser och skapade mallar som alla dokument följde för att uppnå samma standard på upplägg och design. Doku-mentansvarig samordnade med andra roller vid dokumentskrivning.

• Konfigurationsansvarig: Bestämde vilka arbetsprodukter som skulle versionshanteras och vad som ingick i en utgåva. Konfigurationsansvarig satte upp miljö och verktyg för versionshantering, underhöll dessa verktyg och såg till att resterande gruppmedlem-mar använde verktygen på rätt sätt.

• Designansvarig: Ansvarade över projektets designaspekter. Designansvarig tog fram förslag på design med diverse prototyper och såg till att det implementeras på ett kor-rekt sätt. Såg till att designen efterlevde kundens önskan.

4.1.2

Projektfaser

Projektarbetet kan i stora drag delas upp i tre olika faser; förstudie, utveckling och efterstudie. I detta delavsnitt presenteras de olika faserna och vad som har genomförts.

4.1.2.1 Förstudie

Förstudien innefattar tiden från projektets start till då utvecklingen av webbapplikationen påbörjas. I denna fas tillägnade gruppen mycket tid på att starta upp projektet; komma igång med möten, få kontakt med kunden, och sätta upp en plan för hur arbetet skulle funge-ra. Många arbetssättmässiga beslut fattades här och gruppen satte upp följande relaterade arbets- och utvecklingsmiljöer:

• GitHub. • ClickUp.

• Kommunikationskanaler. • Dokumentmallar i Overleaf. • Visual Studio Code.

4.1.2.2 Utveckling

Utvecklingsfasen innefattar tiden från det att utvecklingen på produkten påbörjades till det att produkten färdigställdes. Utvecklingsledaren hade här ansvaret att dela upp utvecklings-områden till resterande gruppmedlemmar efter att gruppen gemensamt fattade beslutet att dela upp gruppen i två övergripande delar; frontend- och backendutvecklare. Utvecklingen följde i stora drag arbetsmetoden Scrum och gruppen arbetade iterativt i sprintar.

Något som gruppen ansåg vara viktigt att fokusera på under utvecklingen av produkten var att genomföra en riklig mängd tester. Dessa tester var varierade i storlek och funktion, mer kan läsas under avsnitt 4.1.5. Gruppen valde även här att följa stilguider i Python och JavaScript vid kodskrivning som blev kontrollerat bland annat med automatisk testning att dessa följdes. Kodskrivningen genomfördes annars enskilt eller i mindre grupper beroende på hur stor funktionalitet som skulle läggas till.

Utöver kontroll med automatisk testning valde även gruppen att använda sig av Git-Hubs funktion pull request som genomfördes varje gång någon skrev till ny funktionalitet till produkten. En pull request behövde godkännas av två personer, utöver utvecklaren eller utvecklarna, för att den skulle bli godkänd och läggas till i huvudprogrammet.

4.1.2.3 Efterstudie

Efterstudien innefattar tiden från det att utvecklingen är avslutad till det att projektgruppen upplöses. Gruppens huvudfokus här var att utvärdera projektarbetet och kursen i sin helhet, samt att färdigställa kandidatrapporten och få den godkänd för publicering. Projektgrup-pen genomförde även här en slutpresentation av produkten och projektarbetet inför samtliga kursdeltagare och kunden. Efter presentationen behövde produkten levereras till kunden. Leveransen av produkten skedde genom ett möte då två gruppmedlemmar demonstrerade produkten och visade hur kunden skulle ladda ner och installera produkten från det publika GitHub repositoriet.

4.1.3

Scrum

Gruppen har under projektet använt sig av en anpassad version av arbetsmetodiken Scrum där projektgruppen justerade de traditionella rollerna och händelserna i arbetsmetodiken.

Rollerna anpassades inom projektgruppen genom att ha två scrummästare och genom att inte ha en produktägare, utan istället låg det ansvaret på hela gruppen. Alla i gruppen skulle även vara med och utveckla, och fick till följd av detta även rollen som utvecklare tilldelad.

Projektgruppen valde även att ha en sprintlängd på en vecka, och sprinten startades med en sprintplanering. Vid slutet på varje sprint valde även gruppen att genomföra en sprintge-nomgång och sprintåterblick gemensamt med en utvärderingsenkät uppföljt av gruppdiss-kusion. Här valdes det ut att testledaren skulle ansvara för utvärderingsenkäten, och gruppen såg gemensamt till att gruppdiskussionen antecknades i mötesprotokollet. För utvärderings-enkät, se figur 4.1. De diskussionsfrågor som användes var följande:

1. Vad gick bra under senaste sprinten? 2. Vad gick inte bra under senaste sprinten?

3. Vad kan förbättras för att öka produktivitet nästa sprint?

Här anpassade projektgruppen även daglig Scrum. Istället för att ha det varje dag valde gruppen att ha det tre gånger i veckan, och avvarade en kvart för varje tillfälle.

4.1.4

Kvalitetskrav

Gruppen tog fram tre olika kvalitetskrav för att se till att systemets behov uppnåddes. 1. Portabilitet/Kompatibilitet (eng. Portability/Compatibility)

2. Användbarhet (eng. Usability) 3. Pålitlighet (eng. Reliability)

Dessa kvalitéer ansågs vara de viktigaste i projektet då alla är nära relaterade till använ-darupplevelsen vilket var fokuset under projektet. Det togs även fram en plan för hur varje kvalité skulle uppehållas och mätas.

1. Portabilitet/Kompatibilitet

• Beskrivning: Antal olika miljöer programmet funkar i. • Hur data tas fram: Testar programmet i de olika miljöerna.

• Hur mätningen räknas: Räkna antalet miljöer programmet fungerar i. Målet är att programmet ska funka på Ubuntu, macOS och Windows.

• Relevant kvalitetsfaktor: Portabilitet/Kompatibilitet – Högt antal fungerande miljöer visar att den är kompatibel med många olika miljöer.

2. Användbarhet

• Beskrivning: Antal roliga och tråkiga funktioner enligt användare.

• Hur data tas fram: Med hjälp av ett användartest. Sätt upp ett testscenario som innefattar gamificationfunktionerna och låter användaren gå igenom det. Samla sedan in antal roliga och tråkiga funktioner i en enkät efter.

• Hur mätningen räknas: Ta medelvärdet av antal roliga funktioner och medelvär-det av antal tråkiga funktioner. Två värden fås.

• Relevant kvalitetsfaktor: Användbarhet – Högt antal roliga funktioner och lågt antal tråkiga funktioner visar på att programmet är användarvänligt och speciellt roligt som eftersträvades.

3. Pålitlighet

• Beskrivning: Antal icke-kommenterade rader kod.

• Hur data tas fram: Räknar antalet icke-kommenterade rader kod med ett verktyg. • Hur mätningen räknas: Räknar antalet icke-kommenterade rader kod.

• Relevant kvalitetsfaktor: Pålitlighet – Många rader icke-kommenterad kod leder till att det är svårt att förstå vad som händer, feldensiteten är då ofta större.

4.1.5

Testning

För att säkerställa att produkten och dess kod fungerade som den skulle användes olika for-mer av testning.

Projektgruppen valde att använda sig av de fyra olika testnivåerna för att testa produkten; enhets- , integrations- , system- , och acceptanstestning. Detta för att säkerställa att den slutli-ga produkten skulle vara fri från bugslutli-gar och uppfylla de kraven som ställdes på produkten. För att produkten skulle anses klar och godkänd var den tvungen att genomgå och klara alla tester. För att testa koden togs olika testverktyg fram.

Då frontend skulle vara skriven i programmeringsspråket JavaScript och backend i Pyt-hon tog testledaren i gruppen fram två testverktyg, ett till varje programmeringsspråk. De olika testverktygen som användes för att köra testerna var:

• Python – Pytest • JavaScript – JEST

Testerna skrevs manuellt i olika testfiler, och projektgruppen följde principen att varje gång ny funktionalitet skapades behövdes även ett test skapas. Följden av manuell testning blev att det tog längre tid, och därför valde gruppen att i den mån det var möjligt automatisera alla testkörningar.

Testerna kördes automatiskt varje gång ny kod tillfördes i gruppens huvudgren med hjälp av GitHubs inbyggda CI-funktion. Detta för att säkerställa att allt fortfarande fungerade som det skulle även efter ny kod tillkommit i projektet.

En del av testprocessen för projektgruppen var att dokumentera och planera alla tester. En testplan och testrapport framställdes därför för att underlätta testning och uppföljning av den.

4.1.6

Kommunikation

Projektarbetet som genomfördes krävde mycket kommunikation, både internt inom gruppen och med utomstående som kund, handledare och examinator. Denna delsektion avser att lyfta hur projektgruppen skötte kommunikationen och vilka verktyg som användes.

4.1.6.1 Gruppkontrakt

Projektgruppen diskuterade redan vid början av arbetet hur medlemmarna skulle förhålla sig till varandra och vilka krav gruppen kunde ställa på varje medlem. Utefter dessa diskus-sioner skapades ett intern gruppkontrakt som alla medlemmarna skrev på. Gruppkontrak-tet redogjorde för alla medlemmars förväntad deltagande i projekGruppkontrak-tet, kommunikation inom gruppen, förhållningssätt inför deadlines, och hur projektgruppen skulle förhålla sig till ko-den och dokumenten som skrevs.

4.1.6.2 Kommunikationskanaler

Projektgruppen valde att ha tre stycken kommunikationskanaler under projektets gång. Gruppen använde Microsoft Teams för att sätta upp förbestämda möten med kund, hand-ledare och internt inom projektgruppen. För mer informella eller spontana möten användes applikationen Discord, och det var även i Discord som samarbete i mindre grupper genom-fördes. För att snabbt få tag på varandra eller skicka ut meddelanden som inte behövdes tas upp på ett möte, använde gruppen chattapplikationen Facebook Messenger. På detta vis hade alla tre kanaler sitt egna syfte.

kom-4.1.6.4 Kundkommunikation

Projektgruppen hade en projektmedlem med rollen analysansvarig vilket bland annat inne-bar att medlemmen skötte den huvudsakliga kontakten med kunden. För möten med kun-den användes Microsoft Teams där analysansvarig och minst ytterligare en gruppmedlem var närvarande. När projektgruppen inte hade möten med kunden ansvarade analysansva-rig för att skicka en uppdatering om projektets fortgång till kunden via mejl. Detta för att bibehålla den goda kontakten med kunden.

4.1.7

Dokument

Enligt kontexten i avsnitt 1.5 behöver gruppen skriva en del dokument och vid leveranser lämna in de för revidering. Dokumenten hade som syfte att underlätta planeringen och ge-nomförandet av projektarbetet. Detta delavsnitt beskriver syftet med varje dokument samt kort vad dokumenten innehöll.

4.1.7.1 Projektplan

Projektplanen hade som syfte att hålla samtliga medlemmar i projektet uppdaterade om pro-jektets fortgång, samt att ge utomstående en god uppfattning om projektet. Dokumentet re-dogjorde för bland annat organisationsplanen, tid- och resursplan, och riskanalys.

4.1.7.2 Arkitekturdokument

Syftet med arkitekturdokumentet var att definiera och förmedla den arkitektur som användes i projektet GutenTag. Dokumentet redogjorde för bland annat arkitekturer kring:

• Datamärkningmodulen. • Autentiseringsmodulen. • Kommunikationsmodulen. • API. • Databashanteraren. • Parsern. • Databasen.

Dokumentet redogjorde även för motiveringar inför de arkitekturellt signifikanta besluten och diskuterade dem gentemot andra lösningar.

4.1.7.3 Systemanatomi

Systemanatomin var en del av arkitekturdokumentet som beskrev hur olika moduler hängde ihop och vilka nivåer moduler befann sig på. Syftet med systemanatomin var att ge en visuell översikt över systemet, för att underlätta implementeringsarbetet.

4.1.7.4 Kravspecifikation

Kravspecifikationen hade som syfte att redogöra för dem krav som projektgruppen och kun-den ställde på produkten GutenTag. Dokumentet listade funktionella-, icke-funktionella-, prestanda- och visuella krav. Det fanns en beskrivning samt prioritetsskala för varje krav.

4.1.7.5 Testplan

Syftet med dokumentet var att utgöra en plan för hur testning av mjukvaran skulle gå till under projektets gång. Detta för att få en stabil och felsökningsvänlig mjukvara som utgjorde grunden för produkten. Dokumentet redogjorde för testtyper och testnivåer, och för varje testnivå fanns det beskrivning på testfall, utförande, kriterier för godkännande och åtgärder vid misslyckande.

4.1.7.6 Kvalitetsplan

Syftet med kvalitetsplanen var att säkerställa att kvaliteten på produkten och processerna under arbetets gång höll en viss grad av kvalité. Dokumentets innehåll redogjorde för hur gruppens organisation skulle arbeta, och hur arbete och produkt skulle utvärderas.

4.1.7.7 Kundkontrakt

Syftet med kontraktet var att beskriva samarbetet mellan kunden och projektgruppen, redo-göra för vad som förväntas av båda parterna och dokumentera vad som gällde angående resultatet av projektet.

4.1.7.8 Testrapport

Syftet med testrapporten var att samla all data från testfall i ett gemensamt dokument som ständigt kunde uppdateras. Förutom information om testfall innehöll testrapporten även av-vikelser och hur de hanterades samt åtgärder som vidtogs.

4.1.8

Versionshantering

För att göra samarbete lättare, alltid ha en säkerhetskopiering, och få en bättre förståelse för hur saker utvecklas använde gruppen versionshantering.

4.1.8.1 Kod

Versionshantering av kod gjordes med hjälp av Git och GitHub.

4.1.8.2 Dokument

Då dokumenten skrevs i Overleaf och vid varje leverans eller större förändring i dokumentet sparades varje unik version av dokumenten på gruppens gemensamma sharepoint i lisam.

4.2

Metod för att fånga erfarenheter

4.2.2

Mötesdokumentation

Under gruppens alla möten – se avsnitt 4.1.6.3 för information om vilka möten som gruppen haft – har mötets diskussion antecknats och sparats i mötesprotokoll. Alla gruppens medlem-mar har agerat sekreterare och valdes vid varje möte ut med hjälp av en rullande lista. Dessa protokoll hjälpte att spara de erfarenheter som gruppen fått.

4.2.3

Dokument

Gruppen skrev under projektet ett stort antal dokument som hjälpte fånga de erfarenheter som gruppen fått. Detta för att alla gruppens dokument hade ett versionsnummer och var versionshanterade, vilket gav en möjlighet att gå tillbaka till tidigare dokument och se hur gruppen och projektet utvecklades under hela arbetets gång. Se avsnitt 4.1.7 för mer detalje-rad information om alla dokument.

Resultatet i denna rapport presenteras i fyra delar: systembeskrivning, processbeskrivning, gemensamma erfarenheter och översikt över individuella rapporter.

5.1

Systembeskrivning

Systemet har enligt krav från kunden utvecklats som en webbapplikation med en frontend, en backend och en databas. Kommunikationen mellan frontend och backend sker genom HTTP-förfrågningar och HTTP-svar. Systemet ska vara installerat i en docker-behållare som nämnts tidigare i rapporten. Det har fördelen att det är väldigt enkelt att distribuera systemet via molnbaserade tjänster, vilket var viktigt då kunden ämnar låta andra företag skapa egna instanser av systemet.

5.1.1

Designfilosofi

Det bestämdes tidigt i projektet att systemet skulle utvecklas med modulär design i åtan-ke. Detta togs i beaktning under designprocessen, och den tilltänkta arkitekturen består så-ledes av flera olika moduler. Under designprocessen användes designmönstret model-view-controller som bas. Detta designmönstret dikterade vilka komponenter som skapades, deras

5.1.2

Systemanatomi

Resultatet av systemanatomin blev en första ritning på hur systemet var tänkt att vara upp-byggt och hjälpte gruppen att få en förståelse för systemet. Gruppens arkitekt tillsammans med utvecklingsledaren skapade systemanatomin när de planerade hur systemet var tänkt att se ut. Systemanatomin kan ses i figur 5.1 nedan.

Figur 5.1: Gruppens systemanatomi för produkten.

5.1.3

Gränssnitt

När gränssnittet till applikationen designades skapades det först en prototyp i programmet Figma som visades för kunden. Efter kundens godkännande började utvecklingen av de olika sidorna och komponenterna som skulle visas i frontenden. Färgerna valdes enligt EVRYs, TietoEVRYs moderbolag, varumärkesguide [26].

För de former som finns på hemsidan i bland annat knappar och textrutor används rek-tanglar med rundade hörn. Detta är på grund av att Bootstrap använder detta utseendet som standard, och för att spara tid behölls denna estetik.

Nedan följer bilder på GutenTags användargränssnitt.

5.1.3.1 Startsida, ej inloggad

Nedan i figur 5.2 hittas en bild GutenTags inloggningssida. Detta är sidan som visas om en ej inloggad användare försöker nå systemet. Då alla funktioner inom systemet, inklusive registrering av nya användare, är begränsade till autentiserade användare finns det ingen annan funktion än att logga in.

5.1.3.2 Startsida, inloggad

I figur 5.3 syns GutenTags startsida för en inloggad adminanvändare. På denna sida visas alla projekt som den inloggade användaren är delaktig i. Om användaren trycker på ett projekt i listan visas mer information, vilket kan ses för Project 1 i bilden. Det finns även en sökruta för att filtrera bland projekten.

Figur 5.3: GutenTags startsida för en autentiserad adminanvändare.

5.1.3.3 Projektinställningssidan

Om en adminanvändare trycker på kugghjulet vid ett projekt från startsidan visas projektin-ställningssidan för det valda projektet. Denna sidan visas nedan i figur 5.4. För att importera data till projektet väljer användaren en JSON-fil att ladda upp, och trycker sedan på Submit. Om det valda projektet är av typen bildklassificering väljer adminanvändaren även de bil-der som ska laddas upp. För att exportera all data från projektet trycker adminanvändaren på Export all data. Användaren erbjuds då att ladda ner en zip-fil med all data från projek-tet. Längst ner syns en lista med systemets användare. Till höger om varje användare kan en adminanvändare se om de är behöriga till projektet eller inte, och kan även trycka på denna symbolen för att ge eller ta bort användarens behörighet. Det finns även ett sökfält för att hitta en specifik användare.

5.1.3.4 Datamärkningssidan, dokumentklassificering

Om en användare från startsidan väljer att trycka på knappen Start under ett projekt av ty-pen dokumentklassificering visas denna sidan, som syns nedan i figur 5.5. I center visas en datapunkt från projektet, och det visas ett textfält där användaren skriver in sina märkning-ar. Pilarna till vänster och höger används för att bläddra genom datapunkterna. Under titeln Your Labels visas de märkningar som användaren redan har gjort för den aktiva datapunkten. Om användaren trycker på krysset till höger om dessa symboler tas den valda datamärkning-en bort. Högst upp på sidan visas två förloppsindikatorer. Ddatamärkning-en översta visar användardatamärkning-ens individuella förlopp för projektet, och den nedre visar förloppet för projektet i helhet.

Figur 5.5: GutenTags datamärkningssida för projekt av typen dokumentklassificering.

5.1.3.5 Datamärkningssidan, bildklassificering

Om en användare från startsidan väljer att trycka på knappen Start under ett projekt av typen bildklassificering visas denna sidan, som syns nedan i figur 5.6. Som datapunkt visas en bild som användaren kan markera med musen. Det går sedan att flytta på eller ändra storlek på markeringen. Likt sidan för dokumentklassificering finns det även här pilar för att traversera projektets datapunkter, ett textfält att skriva märkningar i, ett område som visar användarens utförda märkningar, samt förloppsindikatorer.

5.1.3.6 Datamärkningssidan, sekvensmärkning

Om en användare från startsidan startar ett projekt av typen sekvensmärkning visas denna sidan, som syns nedan i figur 5.7. I mitten syns projektets datapunkt, i det här fallet en text-sträng. Användaren kan använda sin mus för att markera en del av textsträngen. Den del av textsträngen som användaren har markerat syns i den gråa rutan under textsträngen. Det är denna delen av textsträngen som märks när användaren trycker på knappen Label. Likt övri-ga sidor för datamärkning finns det även här pilar för att traversera projektets datapunkter, ett textfält att skriva märkningar i, användarens tidigare märkningar, samt förloppsindikato-rer. Datapunktens textsträng färgas enligt de markeringar som redan har gjorts. I figur 5.7 är exempelvis Los Angeles skrivet i grön färg, vilket symboliserar den gröna märkningen City. Färgerna på märkningara har ingen ytterligare betydelse, utan används enbart för att sam-mankoppla en märkning med en textsekvens.

Figur 5.7: GutenTags datamärkningssida för projekt av typen sekvensmärkning.

5.1.3.7 Datamärkningssidan, sekvens-till-sekvensmärkning

Om en användare startar ett projekt av typen sekvens-till-sekvensmärkning visas denna si-dan, som syns nedan i figur 5.8. I mitten visas den nuvarande datapunkten representerat av en textsträng. Under den finns ett textfält för att märka datapunkten, samt pilar för att traversera projektets datapunkter. Högst upp finns förloppsindikatorer och längst ned visas användarens tidigare märkningar.

5.1.3.8 Inställningssidan

I figur 5.9 visas hur inställningssidan ser ut för en adminanvändare. Denna sidan nås genom att trycka på Settings i huvudmenyn. Högst upp på sidan visas namnet på den inloggade användaren, vilket i figur 5.9 är Admin Admin. Under användarens namn finns fyra knap-par. Knappen Log out loggar ut användaren. De övriga knapparna leder till andra sidor som redovisas nedan. Knapparna Add new project och Manage users är bara synliga för adminan-vändare. Under knapparna visas användarens bedrifter. De bedrifter som är uppnådda visas i starka färger, medan de icke-uppnådda har svagare färger. Mer information om bedrifter hittas i kapitel 5.1.9. Det går även att bläddra mellan bedrifterna med hjälp av pilarna på sidorna. Under bedrifterna visas användarens statistik för olika aktioner inom systemet.

Figur 5.9: GutenTags inställningssida.

5.1.4

Sidan för att skapa projekt

Figur 5.10 nedan visar hur sidan för att skapa ett nytt projekt ser ut. Denna sidan nås genom att trycka på Add new project från inställningssidan. Det är en enkel sida där användaren skriver in ett projektnamn, väljer en projekttyp och väljer hur många användare som måste märka en datapunkt innan den betraktas som färdigmärkt. När användaren trycker på Submit skapas projektet med de valda inställningarna. Sidan är bara tillgänglig för adminanvändare.

5.1.4.1 Användarhanteringssidan

Nedan i figur 5.11 visas användarhanteringssidan som nås från inställningssidan. Här kan en adminanvändare se alla registrerade användare. Till höger finns en ikon för en soptunna som tar bort den valda användaren. Knappen Add user låter en adminanvändare skapa en ny användare. Det finns även ett sökfält för att filtrera bland de användare som visas.

Figur 5.11: GutenTags sida för att hantera användare.

5.1.4.2 Sidan för att byta lösenord

Om man från inställningssidan trycker på knappen Change password visas denna sida, som kan ses nedan i figur 5.12. Här finns tre textfält där användaren fyller i sitt nuvarande lö-senord, sitt önskade lölö-senord, samt det önskade lösenordet igen. När användaren trycker på Save valideras informationen från textfälten, och om allt är korrekt ändras användarens lösenord.

Figur 5.12: GutenTags sida för att ändra lösenord.

5.1.5

Frontend

Systemets frontend är baserat på JavaScript-ramverket React. React gör det mycket enkelt för en utvecklare att snabbt utveckla en frontend. Det ger tillgång till Reactkomponenter, vilket är små, avgränsade och återanvändbara komponenter. Då React är ett väldigt välkänt och po-pulärt ramverk finns det ett stort antal tillägg. I projektet används till exempel react-router för att omdirigera användare till olika delar av hemsidan samt react-multi-carousel för att uppnå en specifik visuell effekt som annars hade varit svår att uppnå. Frontendens funktionalitet är uppdelad över ett stort antal komponenter och skript som binds samman till en slutgiltig produkt.

För att designa hemsidan användes CSS tillsammans med ramverket Bootstrap. Bootstrap ger tillgång till en stor mängd färdigdesignade element som en utvecklare sedan kan anpas-sa efter projektets behov. Exempelvis tillhandahåller Bootstrap färdiga knappar, menyer och textrutor som sedan kan anpassas med minimalt arbete.

förfrågan som rör databasen skickar backenden en förfrågan till databasen, formaterar datan, och skickar tillbaka den i ett HTTP-svar.

Flask förenklar utvecklingen av backendkomponenter avsevärt. Det ger enkel tillgång till funktionalitet som att hantera HTTP-förfrågningar och HTTP-svar, samt att det ger tillgång till en stor mängd tillägg. De Flasktillägg som används i projektet är SQLAlchemy som tidigare nämnts, Flask-CORS för att konfigurera hur servern hanterar HTTP-förfrågningar från olika ursprung, RESTful för ytterligare funktionalitet vid utveckling av ett REST-api, Flask-Bcrypt för kryptering av lösenord, samt Flask-JWT-Extended för sessionshantering.

Backenden har även i uppgift att exportera och importera data till och från filer. För att göra detta finns det en parserkomponent som har i uppgift att konvertera data mellan olika format. Backenden tar emot en HTTP-förfrågan som innehåller en JSON-fil med data som ska importeras till databasen. Filen skannas och valideras, och den korrekta datan läggs till i databasen. Backenden kan även ta emot en HTTP-förfrågan om att exportera den projektdata som finns. Även i det fallet är det parserns uppgift att formatera all data från databasen och skapa en JSON-fil att skicka tillbaka i HTTP-svaret.

5.1.7

Databasen

I projektet används en PostgreSQL-databas. I databasen sparas all data som har med applika-tionen att göra. I projektet används ingen SQL-kod överhuvudtaget, utan all kommunikation med databasen sker via SQLAlchemy. Alla tabeller i databasen har definierats som databas-modeller i form av Pythonobjekt. Dessa Pythonobjekt har definierade fält och funktioner för att lägga till, ta bort, eller på annat sätt manipulera datan.

5.1.8

Värde för kunden

När kunden först presenterade uppgiften fanns det två alternativ för utvecklingen. Det förs-ta var att bygga ett daförs-tamärkningsverktyg helt från grunden, och det andra var att bygga vidare på ett annat datamärkningsprogram med öppen källkod som kunden nyligen hade hittat. Projektgruppen valde det första alternativet. För att särskilja GutenTag från det andra programmet skulle GutenTag ha särskilt fokus på spelifiering efter önskemål från kunden. Projektgruppen diskuterade olika sätt att implementera spelifiering och presenterade dessa för kunden. I utvecklingen av projektet tog grundfunktionaliteten dock längre tid än väntat, och spelifieringen blev mindre ambitiös än vad som var planerat. Projektgruppen anser såle-des att det värde som genererats för kunden är ett stabilt system med bra grundfunkionalitet med grundläggande spelifiering. Kunden har även tillgång till det underlag projektgruppen skapade för ytterligare spelifiering.

5.1.9

Spelifiering

Som tidigare nämnts var spelifiering ett särskilt fokus under produktutvecklingen. Flera av de planerade spelelementen implementerades. En stor del av spelifieringen finns på använ-darsidan. Där kan användaren se statistik över sitt totala bidrag inom applikationen, till ex-empel antalet markerade datapunkter och antalet inloggade arbetsdagar i följd. Vidare kan användaren se sin placering gentemot andra användare i en anonym rankinglista, till exem-pel om användaren ligger topp 1 eller topp 5 inom en viss kategori. En användare kan låsa upp flera olika bedrifter genom att utföra olika typer av uppgifter. Exempel på sådana bedrif-ter är att logga in två dagar i följd, eller att markera 150 olika datapunkbedrif-ter. För varje projekt finns det förloppsindikatorer som visar användarens bidrag till projektet samt hur långt pro-jektet har kvar tills det är klart.

5.1.10

Utvärdering av produkten

Produkten uppnår de mål som projektgruppen satte i början av projektet. All grundfunkiona-litet har implementerats och fungerar väl. Då kunden önskade att projektet skulle ha särskild fokus på spelifiering hade projektgruppen från början ambitioner om mer omfattande speli-fiering än vad som hanns med. Trots detta är projektgruppen nöjda med den spelispeli-fiering som har implementerats, och är även nöjda med den slutgiltiga produkten.

Samarbetet med TDDE46 gav ingen feedback som kunde användas för att förbättra pro-dukten. Detta var delvis för att projektgruppen fick ta del av deras feedback alldeles för sent under projektets gång, men också för att feedbacken var fokuserad på projektgruppens ar-betsprocesser och inte på systemet.

5.2

Processbeskrivning

Under projektet hade två av gruppens medlemmar regelbunden kontakt med studenter från kursen TDDE46 Programvarukvalitet. Detta samarbete bidrog med att hjälpa till att utveckla kvalitetsplanen.

De processer som från början valts att vara i fokus under projektet var Scrum och kodin-tegrering. Dessa processer valdes då de var väsentliga till projektet. Efter ett tag valdes dock kodintegreringen bort då gruppen ansåg att det var bättre att fokusera fullt på Scrum istäl-let. Gruppen valde att ha kvar Scrum istället för kodintegreringen för den kändes viktigare eftersom det låg bakom hela arbetssättet och många av gruppmedlemmarna hade minimal erfarenhet från Scrum. Kodintegrering hade gruppen en ganska bra plan för redan och den kändes tillräcklig, se figur 5.13.

Under detta avsnitt kommer det beskrivas hur vår implementation av Scrum dokumen-terades, förbättrades och utvärderades.

Figur 5.13: Kodgranskningsproceduren för kodintegreringen i projektet.

5.2.1

Scrum

Gruppen har under projektets gång arbetat i en modifierad variant av arbetsmetodiken Sc-rum. Hur gruppen arbetat i Scrum finns mer detaljerat i avsnitt 4.1.3.

5.2.1.1 Processdokumentation

Denna process har dokumenterats genom ett antal olika medier. De uppgifter som skapats har sparats i en stor uppgiftstavla på ClickUp i en stor backlog. Dessa uppgifter har sedan valts ut och delats upp i mindre uppgiftstavlor för varje sprint, se nedanstående figur 5.14. För att utvärdera processen användes till en början endast ett utvärderingsformulär med fem frågor där spannet man kunde svara var 1-5, se figur 4.1. Efter första utvärderingen insåg gruppen att det var svårt att få konkret feedback på vad det var som inte fungerade via endast ett formulär. Det bestämdes att sprintåterblicken också skulle innehålla en diskussion, frågorna som diskuterades finns i avsnitt 4.1.3. Diskussionen hölls efter utvärderingen på grund av att den inte skulle påverka medlemmarnas beslut när de fyllde i utvärderingen. Sprintåterblicken var efter att diskussionen lagts till likadan under resten av projektet.

Figur 5.14: Scrumboard i ClickUp för en sprint.

5.2.1.2 Processförbättring

Utvärderingsenkäten började användas bara efter ett par veckor i projektet, och kort därefter började gruppen också använda diskussion som ett utvärderingsverktyg. Dessa två användes för att hitta förbättringspunkter i gruppens sätt att arbeta med Scrum. Några av de saker som förbättrades var:

• Kortare möten för att hinna med mer arbete.

• Införandet av taggar i ClickUp för att undvika missförstånd vad de olika uppgifterna stod för.

• Förändra utvärderingsformuläret för att göra det tydligare vad vad betygen stod för. • Dela upp uppgifterna i mindre delar för att underlätta arbete.

5.2.1.3 Processutvärdering

Totalt har gruppen haft 12 sprintar. Några av dessa har inte innefattat någon utvärdering, då det ansågs avvika för mycket från en normal sprint för att resultatet av utvärderingen skulle vara rättvist. De första sprintarna hade ingen utvärdering på grund av att ett formulär inte

Tabell 5.1: Sprintutvärdering. Sprintnummer Helhetsbetyg Sprint 3 4 Sprint 4 3.4 Sprint 5 3.6 Sprint 8 2.9 Sprint 9 4.4 Sprint 10 4.1 Sprint 11 4 Sprint 12 4.1

5.2.2

Beskrivning av mätningar

Här under kommer det beskrivas hur gruppens prestanda- och kvalitetskrav mätts och resul-tat av dessa.

5.2.2.1 Prestandakrav

Hittills har gruppen verifierat att vissa av prestandakraven är uppfyllda, medan vissa måste avvaktas med då inte testmöjlighet finns.

5.2.2.2 Kvalitetskrav

De tre kvalitetskraven gruppen hade var: • Portabilitet/Kompatibilitet

• Användbarhet • Pålitlighet

De olika kvalitetskravens mätningar genomfördes på de sätt som metoden antyder i av-snitt 4.1.4 för de två första kraven. För det sista kravet hittades inget digitalt verktyg som kunde mäta hur stor del av koden som var kommenterad. Gruppens kodgranskningsproce-dur, som ska användas när kod granskas innan den integreras in i huvudgrenen, innefattar dock att kod som inte är självförklarande av funktionsnamn och variabelnamn ska kommen-teras. Det har flera gånger varit anmärkningar på att kommentarer glömts bort i koden vilket visar på att det har uppmärksammats och rättats till.

Resultatet av mätningarna var följande:

1. För första kvalitetskravet insåg gruppen att det inte kommer vara några problem för produkten att fungera i olika miljöer då den utgår ifrån en docker. Det beskrivs i av-snitt 3.3.1 hur en docker fungerar. Detta gjorde att första kvalitetskravet uppfylldes utan problem.

2. För andra kvalitetskravet blev resultatet på antal roliga funktioner 3 stycken. Resultat på antal tråkiga funktioner blev 0 stycken.

3. För det tredje och sista kvalitetskravet visar mätningen på att majoriteten av koden är kommenterad. Ett fåtal gånger har det kommit in anmärkningar om att koden inte varit kommenterad och då har det rättats till.

5.2.2.3 Testning

Metoden som sattes upp för att testa produkten följdes på ett bra sätt, framförallt i början. Inga andra verktyg än PyTest och JEST användes och alla tester som skrevs automatiserades. Däremot skrevs det inte tester till all funktionalitet, speciellt inte till kod som skrevs framåt slutet av projektet. Testernas resultat visade dock att alla krav som skulle uppfyllas enligt kravspecifikation, var uppfyllda. En sak som dock inte följdes var att dela upp testerna i enhets-, integrations-, och systemtester.

5.3

Gemensamma erfarenheter

Över projektets gång fick gruppen många nya erfarenheter tillsammans. Dessa erfarenheter varierar från bra till dåliga, tekniska till mjuka och överförbara till icke överförbara.

5.3.1

Erfarenheter om verktyg och programmering

Först och främst har gruppen lärt sig mer om alla ramverk och programmeringsspråk som användes för att utveckla produkten. Dessa inkluderar programmeringsspråken JavaScript och Python, stilspråket CSS, ramverken React, Flask, Bootstrap och SQLAlchemy, databas-systemet PostgreSQL, och virtualiseringsverktyget Docker. Gruppen lärde sig även mycket om de olika verktygen som använts under projektet. Dessa inkluderar Git, GitHub, LA_TEX,

Overleaf, Visual Studio Code, och Figma. Gruppen upplevde att dessa verktyg var trevliga att arbeta med och kommer försöka använda dem igen i framtiden.

En av de största erfarenheterna från dessa är användningen av Git och GitHub. Då stor del av arbetet på själva produkten var tvunget att ske snabbt arbetade gruppen ofta parallellt. Detta resulterade i att mycket integration skedde under projektet. Vilket i stor del av fallen resulterade i konflikter. Gruppens medlemmar hade tidigare hanterat integrationskonflikter (eng. merge conflicts) i Git, men aldrig riktigt i denna skala. Något som märktes vid dessa konflikter var att om man tänkte efter och hade sunt förnuft när koden skrevs var konflik-terna lättare att lösa. Men det var inte bara hur bra en person var på detta som spelade roll, utan även hur bra de andra i gruppen var på att hålla etikett. Mer konkret så var konflikter generellt sett lättare om koden som skulle integreras inte var baserad på alltför gammal kod och inte berörde många filer.

Utöver de mer självklara sakerna som verktyg, ramverk och språk har gruppen även lärt sig mer om de olika typerna av programmering som krävts för att utveckla GutenTag. Bland dessa finns webbprogrammering och databaser.