Konstruktion av databas och verktyg för insamling och behandling av data från bevisinstrument

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

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

Konstruktion av databas och

verk-tyg för insamling och behandling

av data från bevisinstrument

Construction of database and tools for collection and handling of

data from evidence instruments

Elin Frankell

Marcus Gandal

Regina Hansson

Dennis Mivelli

Johan Nordling

Christopher Olli

Younus Salman

Handledare : Dylan Mäenpää Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Elin Frankell Marcus Gandal Regina Hansson Dennis Mivelli Johan Nordling Christopher Olli Younus Salman

Sammanfattning

Denna rapport behandlar ett kandidatprojekt som utförts med Nationellt Forensiskt Cent-rum som kund. Uppgiften var att skapa ett databasbaserat program för att lagra och han-tera stora mängder XML-filer från kundens testinstrument. Rapporten beskriver de teknik-er och metodteknik-er som använts för detta ändamål, där Java, MySQL, Git och agil utveckling är några av de mest centrala.

Resultaten i projektet innefattar en presentation av slutprodukten, projektgruppens er-farenheter och medlemmarnas individuella bidrag. Utöver den gemensamma kandidat-rapporten, har varje gruppmedlem genomfört ett individuellt bidrag om valfritt ämne, ofta kopplat till medlemmens projektroll. Detta gav möjlighet till fördjupning inom om-råden som medlemmarna fann intressanta.

Utifrån diskussionen av dessa resultat dras, bland flera, slutsatserna att det utvecklade projektet kommer att bidra till tidsbesparingar för kunden, att en systemanatomi är ett an-vändbart kommunikationsverktyg i början av ett projekt och att utvecklingen begränsades av valet av teknologier.

Tillkännagivanden

Projektgruppen som står bakom denna rapport vill rikta ett stort tack till projektets hand-ledare Dylan Mäenpää, för goda råd, trevliga möten och genomgående engagemang. Vi vill även tacka Rickard och Andreas på NFC för deras tillmötesgående tillgänglighet och glada tillrop, och examinator Kristian Sandahl för det stöd han givit, på kursnivå såväl som enskilt.

Ordlista

Nedan beskrivs ord och bregrepp som används, men inte explicit förklaras, i rapporten.

Begrepp

Beskrivning

Backend Den del av produkten som innehåller databasen, och som använd-aren inte kommer i direkt kontakt med

Frontend Den del av produkten som användaren interagerar med Gränssnitt Se frontend

Komprimering Att ”packa ihop” data så att det tar mindre plats NFC Nationellt Forensiskt Centrum, förkortning för kunden PBA Portabelt bevisinstrument för alkoholutandning

Pusha Term inom versionshantering, som innebär att ladda upp kod till en global server

Innehåll

2.2 Gruppens tidigare erfarenheter . . . 4

3 Teori 5 3.1 Arbetsmetodik . . . 5 3.1.1 Scrum . . . 5 3.1.2 Teams . . . 6 3.1.3 Drive . . . 6 3.1.4 Git . . . 6 3.1.5 Gitlab . . . 6 3.2 Modellering . . . 7 3.2.1 ER-modell . . . 7 3.2.2 EER-modell . . . 7 3.2.3 Systemanatomi . . . 7 3.3 Utveckling . . . 7 3.3.1 Java . . . 7 3.3.2 IntelliJ . . . 7 3.3.3 JavaFX . . . 7 3.3.4 MySQL . . . 7 3.3.5 MySQL Workbench . . . 8 3.3.6 LA_{TEX . . . . 8} 3.3.7 Overleaf . . . 8 3.4 Testning . . . 8

3.4.1 JUnit . . . 8 3.4.2 MyTAP . . . 8 4 Metod 9 4.1 Utvecklingsmetod . . . 9 4.1.1 Förstudie . . . 9 4.1.2 Roller . . . 9 4.1.3 Utbildning . . . 10 4.1.4 Kommunikation . . . 11

4.1.5 Möten med kund . . . 11

4.1.6 Framtagning av krav . . . 11

4.1.7 Utvecklingmiljö . . . 11

4.1.8 Agilt arbete . . . 11

4.1.9 Dokumenthantering . . . 12

4.1.10 Versionshantering och GitLab . . . 12

4.1.11 Testning . . . 13

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

4.2.1 Utbildning . . . 13

4.2.2 Möten . . . 13

4.2.3 Enkät för process i fokus . . . 14

4.2.4 Seminarier . . . 14

4.3 Systemanatomi . . . 14

4.3.1 Skapande och uppföljning . . . 14

4.3.2 Utvärdering . . . 14 4.4 Kvalitetskrav . . . 15 4.4.1 Portabilitet . . . 15 4.4.2 Användarvänlighet . . . 15 4.4.3 Hållbarhet . . . 15 5 Resultat 17 5.1 Systembeskrivning . . . 17

5.1.1 Översiktlig beskrivning av systemet . . . 17

5.1.2 Systemarkitektur . . . 19 5.1.3 Systemanatomi . . . 19 5.1.4 Värde för kund . . . 20 5.1.5 Alternativ implementation . . . 21 5.2 Processbeskrivning . . . 21 5.2.1 Utvärdering av process . . . 21 5.2.2 Förbättring av process . . . 22 5.2.3 Kvalitetskrav . . . 23 5.3 Gemensamma erfarenheter . . . 24 5.3.1 Externa erfarenheter . . . 24 5.3.2 Interna erfarenheter . . . 25

5.4 Översikt över individuella bidrag . . . 25

5.4.1 Studie i att förstå kundens verkliga behov av Elin Frankell . . . 26

5.4.2 Metod för testning av databasapplikationer med underliggande relationsdatabas av Marcus Gandal . . . 26

5.4.3 Jämförelse av byggautomatiseringsverktyg av Regina Hansson . . . 26

5.4.4 Undersökning av NoSQL-databaser av Dennis Mivelli . . . 26

5.4.5 Behovet av en applikationsserver ur ett skalningsperspektiv av Johan Nordling . . . 26 5.4.6 Betydelsen av ett processområde och dess förbättring av Christopher Olli 26

5.4.7 Säkerhetsjämförelse med att lagra databasen i moln eller i en lokal

ser-ver av Younus Salman . . . 26

6 Diskussion 27 6.1 Resultat . . . 27 6.1.1 Kravframtagning . . . 27 6.1.2 Krav på portabilitet . . . 27 6.1.3 Systemanatomi . . . 28 6.1.4 Alternativ implementation . . . 28 6.1.5 Vidareutveckling . . . 28 6.2 Metod . . . 29 6.2.1 Utvecklingsmetod . . . 29 6.2.2 Alternativa metoder . . . 29 6.2.3 Systemanatomi . . . 30 6.2.4 Utbildning . . . 30 6.2.5 Dokumentutveckling . . . 30 6.2.6 Scrum . . . 30 6.2.7 Kontinuerlig integration . . . 30 6.2.8 Kodgranskning . . . 31 6.2.9 Testning . . . 31 6.2.10 Källkritik . . . 32

6.3 Arbetet i ett vidare sammanhang . . . 32

6.3.1 Samhällsaspekter . . . 32

6.3.2 Etiska aspekter . . . 32

6.3.3 Miljöaspekter . . . 33

7 Slutsatser 34 7.1 Återkoppling till frågeställningar . . . 34

7.1.1 Hur kan en Java-applikation kopplad till en MySQL-databas imple-menteras så att värde skapas för kunden? . . . 34

7.1.2 Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara intressanta för framtida projekt? . . . 34

7.1.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . 35

7.1.4 Begränsade valet av teknologier implementationen av systemet? . . . . 35

7.2 Nåddes syftet? . . . 35

A Studie i att förstå kundens verkliga behov - Elin Frankell 36 A.1 Introduktion . . . 36 A.1.1 Syfte . . . 36 A.1.2 Frågeställningar . . . 36 A.1.3 Avgränsningar . . . 37 A.2 Bakgrund . . . 37 A.3 Teori . . . 37

A.3.1 Vad är krav? . . . 37

A.3.2 Formulering av krav . . . 37

A.3.3 Kravspecifikation . . . 37

A.3.4 Kundens verkliga behov . . . 37

A.4 Metod . . . 38

A.4.1 Litteratursökning . . . 38

A.5 Resultat . . . 38

A.5.1 Olika kravframtagningstekniker . . . 39

A.5.2 Jämförelse kravframtagningstekniker . . . 40

A.6.1 Resultat . . . 40

A.6.2 Metod . . . 41

A.7 Slutsatser . . . 41

A.7.1 Hur kan man arbeta för att ta fram kundens verkliga behov? . . . 41

A.7.2 Vilka är de vanligaste arbetssätten för att ta fram kundens behov i litte-raturen? . . . 41

A.7.3 Vilka arbetssätt är användbara då kunden själv ska utnyttja systemet? . 41 A.7.4 Vilka arbetssätt är användbara då kunden ska utveckla system åt en tredje part? . . . 41

A.7.5 Metod . . . 42

B Metod för testning av databasapplikationer med underliggande relationsdatabas - Marcus Gandal 43 B.1 Introduktion . . . 43 B.1.1 Syfte . . . 43 B.1.2 Frågeställningar . . . 43 B.2 Teori . . . 44 B.3 Metod . . . 45 B.4 Resultat . . . 45

B.4.1 Varför bör man testa sin databas? . . . 45

B.4.2 Vilka funktioner i databasen bör testas? . . . 46

B.4.3 Vilka utmaningar finns det kopplad till testning av en databas? . . . 47

B.4.4 Hur kan databasen testas med hänsyn till dessa utmaningar? . . . 47

B.5 Diskussion . . . 48

B.5.1 Resultat . . . 48

B.5.2 Metod . . . 48

B.6 Slutsatser . . . 49

B.6.1 Varför bör man testa sin databas? . . . 49

B.6.2 Vilka funktioner i databasen bör testas? . . . 49

B.6.3 Vilka utmaningar finns det kopplad till testning av en databas? . . . 49

B.6.4 Hur kan databasen testas med hänsyn till dessa utmaningar? . . . 49

C Jämförelse av byggautomatiseringsverktyg - Regina Hansson 51 C.1 Introduktion . . . 51

C.1.1 Syfte . . . 51

C.1.2 Frågeställningar . . . 51

C.1.3 Avgränsningar . . . 51

C.2 Teori . . . 52

C.2.1 Att bygga ett Java-projekt . . . 52

C.2.2 Vad är byggautomatiseringsverktyg och vad används de till? . . . 52

C.2.3 Kort om Gradle . . . 53 C.2.4 Kort om Maven . . . 53 C.3 Metod . . . 53 C.3.1 Litteraturstudie . . . 53 C.3.2 Experiment . . . 53 C.4 Resultat . . . 54 C.4.1 Kriterier . . . 54

C.4.2 Likheter och skillnader . . . 55

C.5 Diskussion . . . 58

C.5.1 Resultat . . . 58

C.5.2 Metod . . . 59

C.6 Slutsatser . . . 60

C.6.2 Metod . . . 60

C.6.3 Framtida forskning . . . 60

D Undersökning av NoSQL-databaser - Dennis Mivelli 61 D.1 Introduktion . . . 61

D.2 Teori . . . 61

D.2.1 SQL och robusthet: ACID . . . 61

D.3 Frågeställningar . . . 62

D.4 Metod . . . 62

D.5 Kundens databas . . . 62

D.5.1 Representera samma data med färre tabeller . . . 63

D.5.2 Tänkt användning av databasen . . . 64 D.6 NoSQL . . . 65 D.6.1 NoSQL-modeller . . . 65 D.6.2 Möjliga fördelar . . . 66 D.6.3 Möjliga nackdelar . . . 67 D.7 Resultat . . . 67

D.7.1 Vilka för- och nackdelar kännetecknas av NoSQL-databaser? . . . 67

D.7.2 För vilka typer av databaser och operationer kan NoSQL-databaser er-bjuda bättre prestanda än SQL-databaser? . . . 68

D.7.3 Skulle kundens databas teoretiskt sett vara bättre lämpad som en NoSQL-databas? . . . 68

D.8 Diskussion . . . 69

D.8.1 Kundens tidigare lösning är NoSQL . . . 69

D.8.2 För- och nackdelar kan variera mellan olika NoSQL-databaser . . . 69

D.8.3 NoSQL som begrepp . . . 69

D.8.4 Förslagen i avsnitt D.6.1 . . . 69

D.8.5 Prestandaskillnader . . . 69

D.8.6 Val av databasmodell . . . 69

D.8.7 Behovet att utveckla NoSQL-databaser från grunden . . . 70

D.8.8 MySQL var ett krav för projektet . . . 70

D.8.9 SQL lär inte försvinna . . . 70

D.9 Slutsatser . . . 70

D.9.1 Vilka för- och nackdelar kännetecknas av NoSQL-databaser? . . . 70

D.9.2 För vilka typer av databaser och operationer kan NoSQL-databaser er-bjuda bättre prestanda än SQL-databaser? . . . 70

D.9.3 Skulle kundens databas teoretiskt sett vara bättre lämpad som en NoSQL-databas? . . . 71

E Behovet av en applikationsserver ur ett skalningsperspektiv - Johan Nordling 72 E.1 Introduktion . . . 72 E.1.1 Motivering . . . 72 E.1.2 Syfte . . . 72 E.1.3 Frågeställning . . . 72 E.1.4 Avgränsningar . . . 73 E.2 Teori . . . 73 E.2.1 Klient . . . 73 E.2.2 Databas . . . 73 E.2.3 Applikationsserver . . . 73 E.2.4 2-lagersarkitektur . . . 73 E.2.5 3-lagersarkitektur . . . 73 E.3 Metod . . . 73 E.4 Resultat . . . 74

E.4.1 Ökning av antalet användare . . . 74

E.4.2 Komplexitetsökning av systemet . . . 75

E.5 Diskussion . . . 75

E.5.1 Metod . . . 75

E.5.2 Resultat . . . 75

E.5.3 Erfarenheter från projekt . . . 76

E.6 Slutsatser . . . 77

E.6.1 Hur väl hanterar arkitekturen ett ökande antal användare? . . . 77

E.6.2 Hur väl hanterar arkitekturen ett system med ökande komplexitet? . . . 77

F Betydelsen av scrum som process och dess förbättring - Christopher Olli 78 F.1 Introduktion . . . 78 F.1.1 Syfte . . . 78 F.1.2 Frågeställningar . . . 78 F.2 Bakgrund . . . 78 F.3 Teori . . . 79 F.3.1 Process i fokus . . . 79 F.3.2 CMMI . . . 79 F.3.3 De olika nivåerna . . . 79 F.3.4 Definition av kvalité . . . 80 F.3.5 Scrum . . . 81 F.4 Metod . . . 81 F.4.1 Litteraturstudie . . . 81 F.5 Resultat . . . 81

F.5.1 Hur implementerar man scrum som process för ökad kvalité? . . . 81

F.5.2 Vilka fördelar samt nackdelar finns det inom scrum? . . . 83

F.6 Diskussion . . . 84

F.6.1 Hur implementerar man scrum som process för ökad kvalité? . . . 84

F.6.2 Vilka fördelar samt nackdelar finns det inom scrum? . . . 84

F.6.3 Metod . . . 85

F.7 Slutsatser . . . 85

F.7.1 Frågeställning 1 . . . 85

F.7.2 Frågeställning 2 . . . 85

G Säkerhetsjämförelse med att lagra databasen i moln eller i en lokal server -Younus Salman 86 G.1 Introduktion . . . 86 G.1.1 Frågeställning . . . 86 G.2 Bakgrund . . . 86 G.3 Teori . . . 87 G.3.1 Definition av säkerhet . . . 87 G.3.2 Lokal databasserver . . . 88 G.3.3 Global databasserver . . . 88 G.4 Metod . . . 89 G.5 Resultat . . . 89

G.5.1 Konsekvenser för säkerheten med lokala databasserver . . . 89

G.5.2 Konsekvenser för säkerheten med globala databasserver . . . 89

G.6 Diskussion . . . 90

G.6.1 Resultat . . . 90

G.6.2 Metod . . . 91

G.7 Slutsatser . . . 91

G.7.1 Vilka konsekvenser finns det med avseende på säkerheten med att lagra databasen i en lokal databasserver? . . . 91

G.7.2 Vilka konsekvenser finns det med avseende på säkerheten med att lagra databasen i en global databasserver? . . . 91 G.7.3 Vilket sätt är säkrare, att lagra databasen i en global eller lokal

databas-server? . . . 91

H Enkät 93

Figurer

5.1 Systemets inloggningsskärm . . . 17

5.2 En av systemets centrala vyer: sökvyn . . . 18

5.3 Systemarkitektur . . . 19

5.4 Systemanatomi . . . 20

D.1 SQL-version av kundens databas med fyra tabeller. PK står för primary key (unikt ID) och FK för foreign key (referens till annan tabell) . . . 63

D.2 En version av databasen från figur D.1 där riggkörningstabellen tagits bort. . . 64

D.3 Kundens tidigare lösning med filer organiserade i mappar följer mönstret för document-based models . . . 66

F.1 CMMI mognadsnivåer [CMMI_mat] . . . . 80

G.1 En bild som illustrerar en lokal databasserver . . . 88

Tabeller

4.1 Projektets medlemmar och deras roller . . . 11

5.1 Resultat från sprintutvärderingar . . . 22

5.2 Exempel på genomförda förbättringar utifrån enkätsvar . . . 22

5.3 Resultat från hållbarhetsmätningar . . . 23

C.1 Statistik över de 10 senaste Maven- respektive Gradle-uppdateringssläppen . . . . 57

D.1 Exempel på en key-value-databas. Tabellen kan lagra helt olika sorters data på varje rad. Datan i raden lagras som en textsträng . . . 65

D.2 Key-value-databas där datatyp är identifierbar . . . 66

1

Introduktion

Det här kapitlet går igenom motiveringen till och syftet med projektet och de frågeställningar som rapporten kretsar kring. Här finns också en kort beskrivning av de avgränsningar och den kontext som har påverkat projektet.

1.1

Motivering

I sin uppgift att kontrollera och kalibrera bevisinstrument hanterar NFC stora mängder data. Denna data hanteras i nuläget som XML-filer med ett antal olika interna scheman. Det nu-varande sättet att lagra datan kräver mycket lagringsutrymme och gör det omständligt att interagera med lagrad data, till exempel för att ta fram statistik.

Denna rapport presenterar arbetet med att skapa ett system som lagrar XML-filer på ett homogent sätt i en platsbesparande relationsdatabas och via ett gränssnitt förenklar inter-aktionen med data. Även de insikter som projektet gett längs vägen berörs.

Mätinstrumenten som kunden (NFC) arbetar med används i hela Sverige och även i övriga Norden, så det är många som kan påverkas. Kunden kan spara tid och organisationen (Po-lisen) kan spara pengar som kan användas i andra ändamål. I och med att kundens organi-sation är statlig bedöms detta vara ett viktigt mål, då det i förlängningen handlar om skatte-pengar som kan sparas.

1.2

Syfte

Syftet med rapporten är att beskriva slutprodukten, vilken innehåller en databas och ett gränssnitt för att hantera databasen, samt de verktyg och metoder som använts för att ut-veckla den. Rapporten beskriver också lärdomarna från projektet, dels genom en gemensam del och dels genom de individuella rapporter som gruppmedlemmarna bidragit med.

1.3

Frågeställning

1.4. Avgränsningar

1. Hur kan en Java-applikation kopplad till en MySQL-databas implementeras så att värde skapas för kunden?

2. Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara in-tressanta för framtida projekt?

3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? 4. Begränsade valet av teknologier implementationen av systemet?

1.4

Avgränsningar

Projektet är väldigt specifikt och kontextberoende, eftersom slutprodukten endast kommer att användas i NFC:s egna system. Det är alltså ingen generell lösning som ska utvecklas, utan det är kundens specifika XML-scheman som ska hanteras. Produkten ska köras på Windows 10.

1.5

Kontext

Gruppen som har jobbat med projektet består av sju studenter som studerar civilingenjörsut-bildningar inom data- och mjukvaruteknik vid Linköpings universitet. Projektet utförs inom kursen TDDD96 Kandidatprojekt i programvaruutveckling. Det omfattar 400 timmar per pro-jektmedlem, d.v.s totalt 2800 timmar, och det pågår mellan 18 januari 2021 och 25 maj 2021. I dessa timmar ingår även skrivande av kandidatrapport och andra kursmoment. Hela projekt-et genomfördes på distans på grund av Covid-19.

2

Bakgrund

Detta kapitel presenterar bakgrunden till varför kunden beställt projektet, samt projektmed-lemmarnas tidigare projekterfarenheter.

2.1

Kundens bakgrund och syfte

Kunden som beställt projektet är en avdelning inom NFC, som i sin tur är en avdelning inom Polismyndigheten. NFC ansvarar för den forensiska processen inom polisen, vilken bland annat innefattar utförande och utveckling av kriminaltekniska metoder för en framgångsrik och framtidssäker brottsbekämpning. [1] NFC har förutom driftsverksamhet sitt avdelnings-kansli och sitt största laboratorium i Linköping. [1]

Den del av NFC som kunden tillhör har bland annat i uppgift att utföra kontroll och kalibrering av portabelt bevisinstrument för alkoholutandning (PBA) efter genomgångna reparationer och årlig service. [2] Detta innebär att de utför en stor mängd tester. Datan från testerna är viktig för framtida kalibreringar och sparas under lång tid. Mätningar från flera år tillbaka i tiden används när ett bevisinstrument kalibreras. Trots detta har kunden ingen databas att spara datan i, utan allt sparas på lokala hårddiskar.

Kunden har en enorm mängd XML-filer för alla de mätningar som har utförts. Dessutom är varje enskild fil väldigt stor, i storleksordningen av ca 400 kB per fil. Filerna sparas lokalt och tar upp mycket utrymme på hårddiskarna. Filerna sparas i diverse mappar och undermappar som tar lång tid att navigera genom manuellt. Det är opraktiskt av många skäl att lagra så mycket och så viktig data lokalt. Dessutom är det svårt för nya medarbetare på NFC att lära sig att använda systemet.

Det system som togs fram i projektet innehöll en databas och tillhörande gränssnitt för att samla all data från test och kalibrering i samband med kundens kontroller av PBA. Detta underlättade statistiska utvärderingar av bevisinstrumenten och möjliggjorde mätningar av bevisinstrumentens prestanda över tid.

2.2. Gruppens tidigare erfarenheter

2.2

Gruppens tidigare erfarenheter

Alla medlemmar i gruppen har erfarenhet av omfattande projektarbeten via olika kurser inom utbildningen, exempelvis Konstruktion av Mikrodatorer [3], Databasteknik [4] och Stor-skaliga distribuerade system och nätverk [5]. Några har dessutom erfarenhet från projekt utanför skolmiljön genom sommarjobb. Utifrån tidigare bra och dåliga erfarenheter har det fram-kommit att gruppen som helhet värdesätter ett antal områden (utan inbördes ordning):

• Regelbundna statusmöten

• Öppen kommunikation under och mellan möten

• Tydlig definition och uppdelning av roller och arbetsuppgifter • Kodgranskning och god förståelse av projektkoden

3

Teori

Detta kapitel presenterar och förklarar de verktyg och processer som används under projekt-et. Vissa av dem har enhälligt utsetts av ansvarig rollinnehavare, medan andra har fastslagits genom gemensamma beslut inom gruppen.

3.1

Arbetsmetodik

I denna del behandlas de arbetsmetoder och samarbetsverktyg som gruppen använt sig av under projektets gång.

3.1.1

Scrum

Scrum är ett agilt arbetssätt som gruppen har arbetat efter. Arbetssättet skapades 1995 av Jeff Sutherlands och Ken Schwarber. [6] Nedan förklaras några av de centrala begreppen inom Scrum.

Sprint

Sprinten är en av Scrums grundpelare. I Scrum delas projektet in i flera mindre iterationer, och dessa tidsperioder kallas för sprintar. Varje sprint har ett mål, och ramas in av ett antal fastställda möten. Varje sprint börjar med en sprintplanering och avslutas med sprintgransk-ning och sprintåterblick. Det är i sprinten som gruppmedlemmarna arbetar med sina upp-gifter och tanken är att dessa uppupp-gifter ska slutföras helt under sprinten. På så sätt uppnås det agila arbetssättet. Sprintarna är vanligtvis två veckor långa, men det går att ha längre eller kortare sprintar om så önskas.

Artefakter

Samlingen med alla uppgifter som behöver slutföras för att uppnå en färdig produkt kallas produkt-backlog. För varje sprint skapas också en ”lokal” backlog, bestående av de uppgifter som ska slutföras under sprinten. Själva produkten räknas också som en artefakt, och den byggs på efter varje sprint, då de utförda uppgifterna inkorporeras. [7]

3.1. Arbetsmetodik

Dagliga Scrummöten

I de flesta fall hålls dagliga Scummöten varje morgon. Dessa är ett par minuter långa av-stämningar, där gruppmedlemmarna får delge vad de gjorde igår, vad de ska göra idag och eventuella problem.

Sprintplanering

Inför varje sprint väljs ett antal uppgifter ut från projektets produkt-backlog. De utvalda upp-gifterna utgör sprintens backlog, alltså det arbete som gruppen planerar att genomföra under den nya sprinten. Gruppmedlemmarna fördelar sedan dessa uppgifter emellan sig. Under sprintplaneringen tas också kommentarer från den senaste sprintåterblicken upp för förbätt-ringsmöjligheter.

Sprintgranskning

En sprintgranskning görs i slutet av sprinten för att gå igenom vad som gjorts under sprint-en. Målen jämförs med vad som gjorts och allt innehåll i backloggsprint-en. Alla medlemmar får möjlighet att demonstrera vad de gjort under sprinten. [8]

Sprintåterblick

I slutet av varje sprint har gruppen en återblick för att utvärdera sprinten. Där har gruppen en diskussion och samlar in åsikter, exempelvis med hjälp av uppsatta diskussionspunkter eller en utvärderingsenkät.

3.1.2

Teams

Teams är ett kommunikationsvektyg från Microsoft. I Teams kan olika kanaler skapas för or-ganiserad informationsdelning. Det går att sätta upp möten för hela gruppen i dessa kanaler och även enskilda möten när det behövs. Det går dessutom att dela filer mellan varandra genom Teams, och redigera filerna samtidigt. [9]

3.1.3

Drive

Google Drive är en molnbaserad lagringstjänst för filer. Det går att lagra många olika fil-format, och strukturera filerna med hjälp av mappar och undermappar. Det finns inbyggda texteditorer, exempelvis Docs och Sheets, som är integrerade på så sätt att de tillåter redi-gering på plats i Drive. Då synkroniseras filerna, så att flera personer kan redigera samma dokument och se varandras ändringar i realtid.

3.1.4

Git

Git är ett verktyg för versionshantering som kan användas för att dela framsteg med var-andra. Alla i ett projektet kan ha en lokal miljö för att utveckla kod, och det olika personer jobbat på delas genom att pusha upp lokala ändringar till det Git-projekt (även kallat Git-repo) som gruppen delar. [10] I Git finns även möjligheten att skapa olika grenar, så att flera olika versioner av koden kan vara aktiva och under utveckling parallellt i samma Git-repo. [11]

3.1.5

Gitlab

GitLab är ett online-verktyg för att hantera Git-repon, se avsnitt 3.1.4. GitLab erbjuder ett stort antal verktyg. Det finns Merge Requests för kodgranskning, där en projektmedlem kan lägga upp kodändringar som granskas och kommenteras av andra medlemmar innan ändringen efter eventuella modifikationer tas i bruk. Det finns också stöd för kontinuerlig integration

3.2. Modellering

via så kallade pipelines. [12] Detta innebär att varje gång kod pushas, oavsett till vilken gren, körs en uppsättning användardefinierade skript för att bygga och testa koden. GitLab har även så kallade issues för att bokföra uppgifter i projektet och agila bräden (eng. boards) för att visualisera dessa. [13]

3.2

Modellering

Under denna rubrik förklaras de verktyg som använts för att modellera produkten.

3.2.1

ER-modell

Entity-Relationship Model (ER-modell) är en konceptuell datamodell som visualiserar ett databasschema. ER-diagrammet som modellen består av visar samband mellan enheter och attribut. Diagrammet är nära knutet till realiseringen av databasen, men ändå tillräckligt ge-nerellt för att diskutera med personer som inte är tekniskt insatta. [14]

3.2.2

EER-modell

Enhanced Entity-Relationship Model (EER-modell) är en utökning av ER-modellen, och inne-håller bland annat arv, subtyper, specialisering och generalisering. [14]

3.2.3

Systemanatomi

En systemanatomi är en riktad acyklisk graf som illustrerar en produkts funktionalitet sett från användarens perspektiv. En systemanatomi underlättar diskussioner kring produkten och kan vara ett gott stöd för bland annat integrationstestning. [15]

3.3

Utveckling

Detta avsnitt behandlar de språk och miljöer som användes till utveckling.

3.3.1

Java

Java är ett statiskt typat, klassbaserat, objektorienterat högnivå-programmeringsspråk. Java är dessutom portabelt, då koden kan köras på alla plattformar; det enda som krävs är en virtuell Javamaskin (JVM), vars funktion är att interpretera kompilerad Java-kod. [16]

3.3.2

IntelliJ

IntelliJ är den utvecklingsmiljö där frontend och delar av backend utvecklas. IntelliJ läser av koden medan den skrivs för att kunna komma med förslag. Det finns även många tillvals-moduler (eng. plugins) och verktyg som kan underlätta arbetet, exempelvis stöd för att hålla god kodstil. IntelliJ har även en koppling direkt till Git. [17]

3.3.3

JavaFX

JavaFX är en mjukvaruplattform för att skapa såväl skrivbordsapplikationer som webbapp-likationer. Med JavaFX utvecklas alltså GUI:n, både dess design och funktionalitet vid inter-aktion med designen. [18]

3.3.4

MySQL

MySQL är en databashanterare som använder sig av Structured Query Language (SQL). MySQL hanterar relationella databaser, vilket innebär att data sparas i olika tabeller med

3.4. Testning

relationer sinsemellan, vilket möjliggörs av pekare och användardefinierade regler. Denna struktur gör MySQL snabbt och flexibelt. [19]

3.3.5

MySQL Workbench

MySQL Workbench är ett verktyg för att hantera MySQL-databaser. [20] Verktyget erbjuder bland annat funktioner för att skapa och ansluta till databaser, samt modifiera, modellera och visualisera innehållet i databaser.

3.3.6

L

_TEX

LA_{TEX är ett typsättningssystem som mestadels används för att skriva vetenskapliga texter.}

LA_{TEX separerar text och formattering, vilket låter författaren fokusera på innehållet.}

For-matteringen beskrivs i kod, vilket innebär att LA_{TEX-dokument behöver kompileras för att}

få sin slutliga form. LA_{TEX är mycket flexibelt tack vare alla paket och färdiga mallar som finns}

tillgängliga, samt möjligheten att fördela innehåll i flera filer innan kompilering. [21]

3.3.7

Overleaf

Overleaf är en online-textredigerare som underlättar hantering av LA_{TEX-dokument. [22]}

Overleaf möjliggör dessutom simultan redigering av dokument. Andra användbara funktioner är att kunna kommentera text, räkna ord, auto-kompilera och kontrollera stav-ning och LA_{TEX-kodsyntax.}

3.4

Testning

Nedan presenteras de metoder och verktyg som använts för testning i projektet.

3.4.1

JUnit

Testramverket JUnit låter utvecklare skriva repeterbara tester för Java-program. [23] Detta ramverk kan användas för att enhetstesta och integrationstesta, och förutom att kunna köra alla eller enskilda tester lokalt, kan JUnit användas till regressionstestning genom att alla tester automatiskt körs i en pipeline, se avsnitt 3.1.5.

3.4.2

MyTAP

MyTAP är ett testramverk för MySQL som följer TAP (Test Anything Protocol). Tester skrivs som assertions och resultatet skrivs ut i terminalen. [24]

4

Metod

Detta kapitel beskriver de metoder och tillvägagångssätt som användes under genom-förandet och utvärderingen av projektet. Varje avsnitt är knutet till en eller flera av rapportens frågeställningar, som presenteras i avsnitt 1.3.

4.1

Utvecklingsmetod

Nedan beskrivs de metoder som användes under produktutvecklingen, kopplat till fråge-ställning 1.

4.1.1

Förstudie

Förstudien utfördes huvudsakligen under två perioder. Den första av dessa perioder varade knappt två veckor – fram till det första mötet med kunden. Under denna period spenderade medlemmarna tid med att läsa igenom de redan publicerade dokumenten från kunden. Syf-tet var att alla skulle ha en bättre förståelse för vad kunden faktiskt ville ha, så att det första mötet med kunden skulle bli mer gynnsamt för alla parter. Efter det första mötet fortsatte förstudien, men nu kunde medlemmarna lära sig mer om de språk och verktyg som kunden ville att produkten skulle utvecklas i. Mycket tid lades också på att organisera projektet, pla-nera arbetsmetoder och sätta upp lokala utvecklingsmiljöer. Denna andra period varade fram till att kraven formulerats och godkänts, cirka tre veckor. Därefter övergick förstudiearbetet i implementation.

4.1.2

Roller

För att underlätta kommunikation och ansvarsfördelning inom projektet och mot externa parter, använde sig gruppen av olika roller. Varje roll hade definierade uppgifter enligt be-skrivningen nedan. Bebe-skrivningen tar även upp vilka roller som hade sista ordet i vilka frågor vid eventuella tvister. Projektmedlemmarna, samt deras roll, presenteras i tabell 4.1.

4.1. Utvecklingsmetod

Analysansvarig

Denna roll ansvarade för kundkontakt. Analysansvarig tog reda på kundens verkliga behov, genomförde förhandlingar och dokumenterade krav. Denna roll hade sista ordet i kund-frågor, som när och hur kundmöten skulle genomföras.

Arkitekt

Denna roll hade i uppgift att säkerställa att en stabil arkitektur togs fram och dokument-erades. Arkitekten hade också ett stort ansvar för att göra övergripande teknikval, och hade sista ordet i de besluten.

Dokumentationsansvarig

Denna roll ansvarade för att dokumentmallar med tillhörande ändringsrutiner fanns på plats, samt att leveranser var klara till leveransdatum. Dokumentansvarig hade sista ordet i hur dokument skulle utformas.

Konfigurationsansvarig

Denna roll valde och underhöll verktyg för versionshantering, samt avgjorde vad som skulle versionshanteras och att det sköttes på rätt sätt. Konfigurationsansvarig var också den som beslutade vilka produkter som ingick i en utgåva. Konfigurationsansvarig hade sista ordet gällande versionshanteringsfrågor.

Kvalitetssamordnare

Denna roll hade i uppgift att driva gruppens kvalitetsarbete framåt, till exempel genom att ta initiativ till planering och budgetering. Kvalitetssamordnaren såg också till att erfarenheter fångades in och skrev en kvalitetsplan. Denna roll hade sista ordet vad gällde metoder för erfarenhetsfångst.

Teamledare

Denna roll var gruppens representant utåt, och ledde det interna arbetet. Teamledaren ansvarade för arbetsmiljö, måluppfyllnad och att processer följdes. Det var teamledaren som såg till att en projektplan skrevs. Teamledaren hade sista ordet i alla frågor som inte explicit var tilldelade en roll, och där det inte var uppenbart att frågan föll under en annan roll.

Testledare

Denna roll hade koll på systemets status genom sitt ansvar för verifiering och validering av systemet. Testledaren var också huvudförfattaren till testplan och testrapport. Denna roll hade sista ordet gällande testinnehåll.

Utvecklingsledare

Denna roll ledde och fördelade utvecklingsarbetet, ansvarade för den detaljerade design-en och utvecklingsmiljön samt organiserade tester. Ddesign-enna roll hade sista ordet angådesign-ende utvecklings- och testmiljö, samt fördelning av utvecklingsuppgifter.

4.1.3

Utbildning

För att alla medlemmar i projektet skulle ha en stabil kunskapsgrund hade alla ett personligt ansvar att utbilda sig inom relevanta områden. Ett område ansågs vara relevant om individen

4.1. Utvecklingsmetod

Tabell 4.1: Projektets medlemmar och deras roller

Namn Roll E-postadress

Elin Frankell Analysansvarig elifr592@student.liu.se

Marcus Gandal Testledare marga051@student.liu.se

Regina Hansson Dokumentations- och konfigurationsansvarig regha434@student.liu.se

Dennis Mivelli Utvecklingsledare denmi351@student.liu.se

Johan Nordling Arkitekt johno762@student.liu.se

Christopher Olli Kvalitetssamordnare chrol799@student.liu.se

Younus Salman Teamledare yousa991@student.liu.se

bedömde att utökad kunskap behövdes inom det specifika området. Utbildningen kunde bestå i att ta del av dokumentation och videor eller att öva genom att skriva kod.

4.1.4

Kommunikation

För att kommunicera inom gruppen samt med handledare användes Microsoft Teams. Genom Teams kunde helgruppsmöten samt mindre möten anordnas. Utöver möten har platt-formen också chattfunktionalitet, vilket användes flitigt av gruppens medlemmar. Komm-unikationen med kunden skedde genom e-post eller kundens egna kommunikationssystem.

4.1.5

Möten med kund

Målsättningen var att kontinuerligt ha möten med kunden genom hela utvecklingen av projektet. Det första mötet var på plats hos kunden, med syfte att lära känna kunden och bli bekanta med instrumenten de använde. Därefter hölls möten i form av statusuppdateringar, frågestunder och demonstrationer. Demonstrationer hölls under projektets andra halva, med syftet att ge kunden en överblick över hur produkten utvecklats hittills och diskutera hur produkten utformats.

4.1.6

Framtagning av krav

Kraven togs fram tillsammans med kunden för att säkerställa en produkt de skulle vara nöjda med och som gruppen dessutom kunde producera inom tidsgränserna. Kunden hade i förväg sammanställt en lista över saker som var nödvändiga för funktionaliteten och tillägg som kunde genomföras i mån av tid. Utifrån denna lista kunde gruppen prioritera kraven och genomföra planeringen. Dessa krav kunde också användas för att skatta värdet som det nya systemet skapade för kunden, vilket är högst relevant för frågeställning 1.

4.1.7

Utvecklingmiljö

Innan databasen började utvecklas modellerades den med en ER-modell med inslag av EER. Projektets klient utvecklades med Java, GUI:t med JavaFX och databasprocedurer med MySQL. Editorn IntelliJ användes för Java-relaterad utveckling och MySQL Workbench för all MySQL-utveckling. För att testa Java-koden användes ramverket JUnit och för att testa MySQL-koden användes MyTAP. Testningsmetoden beskrivs mer ingående i avsnitt 4.1.11.

4.1.8

Agilt arbete

Projektgruppen arbetade agilt under projektets gång, och tidigt efter det första mötet med kunden påbörjades den första sprinten. För en beskrivning av grunderna i det agila arbets-sättet Scrum hänvisas läsaren till avsnitt 3.1.1. En skillnad mot det beskrivna arbetsarbets-sättet är att gruppen valde att inte ha dagliga Scrummöten på grund av andra kurser och olika scheman.

4.1. Utvecklingsmetod

Istället användes det veckoliga handledarmötet till avstämning, och ett extra möte en gång i veckan schemalades löpande.

Syftet med att påbörja sprintar var att sätta upp en modell för hur utvecklingen av dokument och produkt ska utföras på en hög nivå, alltså vilka som bär ansvar för att vad blir färdigt till en viss tidpunkt. Tanken var alltså övergripande planering, inte att detaljstyra genomförandet. Planen togs fram utifrån inlämningsdatum och obligatoriska moment inom kursen, samt de produktkrav som behövde uppfyllas för att kunna leverera en färdig produkt till kunden inom tidsramen.

Prioriteringen av produktkrav utgick delvis från beroendet mellan olika moduler, men även från vikten hos ett krav. Denna vikt bestämdes genom gruppomröstning, där alla samtidigt fick presentera ett tal mellan 1-10. 10 betydde mycket resurskrävande medan 1 innebar att få resurser krävdes. Syftet med att alla fick presentera sin röst samtidigt var att ingen skulle bli influerad av någon annan. Därefter fördes en diskussion kring avvikande värden, och gruppen enades om ett medelvärde som blev den vikt som kravet tilldelades.

När uppgifterna som skulle utföras under den kommande sprinten bestämts, tilldelades alla medlemmar minst en uppgift. Under sprinten hölls flera statusuppdateringar mellan de olika grupperna som skapats under tilldelningen, med syfte att alla skulle få möjlighet att presen-tera sin framgång och diskupresen-tera eventuella problem.

4.1.9

Dokumenthantering

Majoriteten av de dokument som användes kontinuerligt i projektet, exempelvis projekt-plan, kravspecifikation och testprojekt-plan, skrevs i Overleaf. Dokumenten skrevs då i typsättnings-systemet LA_{TEX. Övriga dokument delades inom gruppen med hjälp av Google Drive. Där}

hade gruppen en mapp innehållande viktiga dokument från kunden, mötesprotokoll, tids-rapport med mera. I mappen fanns olika undermappar vilket möjliggjorde en tydlig struktur för en god överblick.

4.1.10

Versionshantering och GitLab

Projektet versionhanterades med hjälp av Git och ett centralt Git-repo fanns på Gitlab. I gruppens Git-repo fanns en huvudgren dit gruppen pushade kod som var färdig att inte-greras. Själva koden utvecklades i andra grenar, som gruppmedlemmar själva skapade vid behov. Detta gjordes för att kunna utveckla utan konflikter med den kod andra medlemmar höll på att skriva, samt för att möjliggöra kodgranskning och minska risken att få in trasig kod i huvudgrenen.

Kodgranskning genomfördes med hjälp av Merge Requests, som behövde godkännas av ut-vecklingsledaren och ytterligare en gruppmedlem. Issues användes för att bokföra planerade och aktuella uppgifter samt de ansvariga projektmedlemmarna för varje uppgift. Bräden an-vändes för att visualisera status på dessa uppgifter, vilket var användbart bland annat under planeringsmöten.

I projektet implementerades kontinuerlig integration för automatisk testning, såsom presen-terad i avsnitt 3.1.5. I projektet kunde inga kodändringar lämna en gren via ett Merge Request, ifall inte dess pipeline lyckades. På detta sätt ökades möjligheten att alltid ha en fungerande version av produkten i huvudgrenen. För varje pipeline producerades också en testrapport, så att gruppmedlemmar vid behov enkelt kunde se vad som gått fel.

4.2. Metod för att fånga erfarenheter

4.1.11

Testning

Testningen indelades i tre nivåer: enhetstestning, integrationstestning och systemtestning. Testprocessen för varje komponent inleddes med enhetstestning, vilket bestod av ett antal testfunktioner, eller testfall, som fanns i ett testskript. För enhetstester var dessa funktioner relativt enkla och anropade högst en funktion, från en och samma systemkomponent. För enhetstestning av databasprocedurer användes biblioteket MyTap (se 3.4.2). Enhetstestning av Java-delen av backend, samt all integrationstestning gjordes med testramverket JUnit (se 3.4.1).

Alla testskript under detta projekt utökades kontinuerligt, vilket innebar att det gjordes en bedömning när en komponent var redo att testas på nästföljande nivå, vilket i detta fall var integrationstestning.

Syftet med integrationstestningen var att kombinera funktionaliteten från två kompo-nenter och säkerställa att funktionaliteten bevarades efter integrationen. Testfunktioner för integrationstester, som för enhetstester, definierades också i testskript, men var mer avance-rade. Testfallen involverade flera funktioner, från de båda komponenterna. När integrations-testningen bedömdes färdig var den resulterande modulen redo för systemtestning.

Systemtestningen utfördes i slutet av projektet och innefattade funktioner från alla systemets moduler i varje testfall. Detta för att säkerställa att information i form av data skickades kor-rekt mellan alla moduler och gav förväntat resultat. Dessa testfall hade ofta en tydlig kopp-ling till kraven.

Varje testfall definierades i en testfallsmatris och identifierades genom ett unikt test-id. Varje testnivå hade en egen testfallsmatris, således fanns det tre matriser. I testfallsmatrisen be-skrevs varje testfall i detalj, med exakt indata och utdata. Testfallen kopplades också till en spårbarhetsmatris, som samlade testfall för alla nivåer på en plats, och som här kopplades till de uppsatta kraven. Testfallsmatriserna och spårbarhetsmatrisen dokumenterades i en test-plan och resultaten från samtliga tester dokumenterades i en testrapport.

4.2

Metod för att fånga erfarenheter

Genom projektets gång samlades erfarenheter inom olika områden in. Erfarenheterna som beskrivs nedan är relevanta för frågeställning 2, eftersom mer information och kännedom underlättar att gynnsamma beslut tas för diverse projektgrupper. Med hjälp av denna er-farenhetsinsamling blev det också uppenbart vilka fördelar respektive nackdelar de valda teknologierna medförde, vilket är relevant för frågeställning 4.

4.2.1

Utbildning

Gruppmedlemmarna delade den kunskap de tagit med sig in i projektet genom gemen-samma utbildningstillfällen. Dessa utfördes genom att en eller flera medlemmar till exempel höll en presentation eller förberedde övningar för resten av gruppen. En mer informell typ av erfarenhetsfångst ägde rum genom parprogrammering. Genom att tillsammans lösa problem kunde gruppmedlemmarna lära sig av varandra genom kontinuerlig utbildning i små doser.

4.2.2

Möten

Varje vecka hölls minst två möten tillsammans med hela projektgruppen, ett handledarmöte och ett dagligt Scrummöte. Under varje sprint hölls också sprintplanering- och återblick. Uti-från de problem, tankar och diskussioner som kom upp under dessa möten kunde gruppens generella uppfattningar samlas, bland annat gällande kundkontakt, dokumenthantering och

4.3. Systemanatomi

gruppdynamik. Mötena fungerade som en form av informella intervjuer. Inga gemensamma protokoll skrevs under mötena, utan varje medlem ansvarade för att anteckna det som var viktigt för deras projektroll och fortsatta arbete.

4.2.3

Enkät för process i fokus

Projektets arbetsmetod undersöktes som process genom projektet. Arbetsmetoden som valdes var Scrum med specifikt fokus på sprintar, som beskrivs i avsnitt 3.1.1.

Erfarenheter från arbetsmetoden fångades genom en enkät, se appendix H. Enkäten togs fram med hjälp av studenter från kursen Programvarukvalitet [25] och reviderades ett flertal gång-er. Syftet med enkäten var att få en överblick över hur gruppen upplevde sprinten, och att ge varje individ i gruppen en möjlighet att påverka nästkommande sprint. Enkäten använ-des därefter för att identifiera förbättringsområden som gruppen kunde tillämpa framöver. Detta gjordes genom att ställa frågor där varje medlem fick utvärdera relevanta aspekter av processen på en skala. Genom att svara på en skala underlättades utvärderingsprocessen, då ett högre resultat än föregående sprint korrelerade med förbättring, medan lägre totalpoäng innebar försämring. Denna enkät summerades sedan av den ansvarige för arbetsmetodiken och förbättringar inför nästa iteration kunde tas fram utifrån resultatet.

4.2.4

Seminarier

Kandidatprojektskursen innefattade fyra seminarier. Seminarierna hade olika inriktningar, men gemensamt för dem alla var att de innehöll presentationer från flera projektgrupper, vilket åtföljdes av opposition av en annan grupp och återkoppling från handledare. Genom dessa seminarier samlades erfarenheter dels genom att ta del av andra gruppers erfarenheter och arbetssätt, och dels genom den konstruktiva kritik som togs emot gällande gruppens egna arbete.

4.3

Systemanatomi

Detta avsnitt beskriver hur systemananomin användes och utvärderades i projektet. Detta är relevant för frågeställning 3.

4.3.1

Skapande och uppföljning

Innan utvecklingen påbörjades togs en systemanatomi fram som en översiktlig plan. Alla gruppens medlemmar hade möjlighet att använda anatomin som en högnivå-manual för hur systemet skulle implementeras.

4.3.2

Utvärdering

För att samla gruppens erfarenheter angående användningen av systemanatomin utfördes en enkät i slutfasen av projektet. Följande frågor ställdes (inom parentes anges på vilket sätt frågan besvarades):

• Hur stort stöd upplevde du att systemanatomin gav i samband med att den skapades? (skala 1-5, där 1 motsvarade inget stöd och 5 motsvarade mycket stort stöd)

• Vad upplevde du gav bra stöd med systemanatomin (om något)? (fritext)

• Hur många gånger använde du systemanatomin under utvecklingen av produkten? (alternativ: 0, 1-5, 5-10, fler)

4.4. Kvalitetskrav

• Har systemanatomin bidragit till en större förståelse för hur systemet skulle utvecklas? (fritext)

• Vad hade kunnat göras annorlunda för att du skulle ha fått mer stöd från system-anatomin? (fritext)

• Upplevde du att det var enklare att hitta eventuella problem med produkten tack vare systemanatomin? (fritext)

4.4

Kvalitetskrav

Portabilitet, användarvänlighet och hållbarhet är de tre kvalitetskrav som bestämdes för detta projekt. Dessa krav togs fram med hjälp från programvarukvalitets-studenterna utifrån krav från kunden.

4.4.1

Portabilitet

Det första kravet som sattes var ett portabilitetskrav. Gruppen ville att implementationen av systemet skulle ske smidigt och kunden ville i början av projektet ha ett system som var kom-patibelt med olika versioner av Windows. Genom att säkerställa att de metoder och funktion-er som användes genom implementationen fungfunktion-erade på flfunktion-era system kunde det garantfunktion-eras att slutprodukten hade hög portabilitet. Detta säkerställdes dels genom att projektgruppens medlemmar rent naturligt utvecklade på olika system, då projektet utfördes på egna ma-skiner på distans, dels genom att via dokumentation verifiera kompatibilitet för exempelvis externa bibliotek.

4.4.2

Användarvänlighet

För att säkerställa att kunden skulle kunna använda det färdiga systemet på ett smidigt sätt utfördes användartester. Dessa gjordes främst i form av demonstrationer för kunden, där de kunde ge återkoppling på den grafiska utformningen och användarflödet i produkten. Även den interna kodgranskningen fungerade som användartester, då medlemmar som inte deltagit i utvecklingen av en del av produkten fick testa den och komma med insikter och idéer.

4.4.3

Hållbarhet

En önskan från kunden var att de enkelt skulle kunna vidareutveckla produkten. Utifrån det bedömdes hållbarhet vara ett viktigt kvalitetskrav för produkten. För att kontrollera detta krav implementerades en granskning med Maintainability Index (MI), vilket presenteras i ekvation 4.1. MI är en formel som tar hänsyn till flera olika kodmetriker, nämligen

• Halstead Volym (HV): HV är en metod för att få ett kvantitativt mått av komplexiteten hos olika moduler i ett program. Detta utförs med hjälp av olika aspekter såsom antal operand- och operatorinstanser. [26]

• Cyklomatisk komplexitet (CC): CC är även det ett kvantitativt komplexitetsmått hos ett program. [27] Detta mått beräknas med hjälp av följande data:

– Antal bågar i modulens flödesdiagram. – Antal noder i modulens flödesdiagram. – Antal anslutna komponenter.

4.4. Kvalitetskrav

MI-formeln i ekvation 4.1 kommer utifrån dessa kodmetriker att generera ett resultat mellan 0 och 100. Denna skala delas in i tre olika nivåer där ett resultat mellan 0-9 innebär ett dåligt resultat utifrån ett underhållsperspektiv, 10-19 att koden håller någorlunda rimlig standard och där 20-100 är ett bra resultat. [28]

5

Resultat

Detta kapitel presenterar resultaten. Kapitlet är indelat i systembeskrivning, process-beskrivning, gemensamma erfarenheter och en översikt av gruppmedlemmarnas individu-ella bidrag.

5.1

Systembeskrivning

För att ge en god förståelse av det system som utvecklats beskrivs dess arkitektur, anatomi och värde för kund i detta avsnitt. Avsnittet inleds med en översikt över systemet.

Figur 5.1: Systemets inloggningsskärm

5.1.1

Översiktlig beskrivning av systemet

Systemet består av en databas som lagrar XML-filer. Dessa går att söka fram via nyckelord såsom datum. Informationen i XML-filerna kan vid behov exporteras till CSV-filer.

Databas-5.1. Systembeskrivning

en nås via en applikation med inloggning. Inloggningsskärmen som möter användaren då applikationen startas visas i figur 5.1.

Figur 5.2: En av systemets centrala vyer: sökvyn

Via applikationen kan användaren importera körningar till databasen, hämta ut information från bland annat olika körningar och datum samt hantera olika inställningar, såsom förifyllda sökfält. En känsla för hur användaren kan interagera med systemet ges i figur 5.2. Nedan listas systemets sammantagna funktionalitet:

• Importera resultatfiler

– Hantera fält med olika namn men samma innehåll på ett enhetligt sätt – Spara icke-sökbar data platseffektivt

• Filtrera data från databasen

– Filtrera enligt ett sökkriterium – Filtrera enligt flera sökkriterier

• Exportera data från databasen till modifierbara CSV-format • Grundläggande inloggning

– Skapa användare och ändra lösenord – Kräva behörighet för rätt funktioner – Logga ansvarig person i databasen • Hantera nya XML-filstrukturer

– Funktionalitet för att uppdatera databasen med nya kolumner – Kunna para ihop nya taggar med existerande taggar

5.1. Systembeskrivning

5.1.2

Systemarkitektur

I figur 5.3 kan systemarkitekturen beskådas. Det diskuterades med kunden samt inom projektgruppen om en 2-skikts- eller 3-skiktslösning skulle användas. En 2-skiktslösning innebär att en Java-applikation kommunicerar direkt med en databas. I en 3-skiktslösning körs istället en applikationsserver mellan Java-applikationen och databasen, och applikation och databas har då ingen direktkontakt. Dessa två alternativ jämförs djupare i appendix E. Arkitekten var initialt inställd på att använda en 3-skiktslösning för att kunna möjliggöra det inloggningssystem som kunden efterfrågade. Kunden hade dock önskemål om att hålla arki-tekturen så simpel som möjligt då det fortfarande inte var helt säkert hur deras IT-avdelning skulle sätta upp produktionsmiljön. En gruppmedlem kom sedermera på en lösning för in-loggningsproblematiken som involverade att dra nytta av MySQL:s inloggningslösning. Där-för fastställdes det att en 2-skiktlösning skulle användas, där de två skikten alltså var en Java-applikation och en MySQL-databas.

Figur 5.3: Systemarkitektur

5.1.3

Systemanatomi

I figur 5.4 kan projektets systemanatomi beskådas. Syftet med detta dokument var att skapa en översiktlig och ungefärlig bild av systemet i ett tidigt skede av projektet. Med hjälp av systemanatomin kunde gruppen föra mer konkreta diskussioner kring saker såsom arbetsför-delning, projektets avgränsningar och funktionalitet. Stödet från systemanatomin medförde även att projektets medlemmar och kunden enklare kunde visualisera de krav som kunden hade definierat.

För att besvara frågeställning 3 fångades erfarenheter angående systemanatomin i en enkät som beskrevs i avsnitt 4.3.2. Resultatet av enkäten togs enkelt fram genom att sammanställa samtliga gruppmedlemmarnas svar. På frågan om hur stort stöd systemanatomin gav när den skapades blev medelvärdet 2.6 av 5. Mer utförligt betyder detta att gruppen generellt sett uppfattade systemanatomin som ett litet stöd. Det framkom av fritextsvaren att gruppen som

5.1. Systembeskrivning

Figur 5.4: Systemanatomi

helhet ansåg att systemanatomin bidrog med en god förståelse för hur moduler hängde ihop vid starten av projektet. Vidare framkom att systemanatomin uppmuntrade till diskussioner mellan gruppmedlemmarna, med hänsyn till design. Detta bidrog i sin tur till att gruppen som helhet satte sig in i hur produkten skulle utformas, och således fick samtliga individer med sig en bättre förståelse för vad som måste implementeras, och i vilken ordning, för att systemet skulle fungera. Däremot var projektgruppen enig om att detta var ett bidrag främst i början av projektet.

En majoritet ansåg att fler regelbundna uppdateringar skulle ha utförts för att få ut mer stöd från systemanatomin. Fler uppdateringar hade bidragit till att kontinuerligt kunna använda sig av systemanatomin, och inte bara i början. Det framkom även åsikter om att diskute-ra systemanatomin mer i gruppen. Ett exempel som fdiskute-ramkom var att information som ”nu jobbar person A på detta, och person B är i den här delen av systemet” hade underlättats av en uppdaterad systemanatomi. Detta kunde gjort det enklare att under utvecklingsstadiet se vad som behövde utföras i nästa steg samt ge ett mer visuellt sätt att hålla ordning på vilka moduler som var färdiga.

5.1.4

Värde för kund

Kundens situation och behov beskrivs i avsnitt 2.1. En första aspekt av produkten som knyter an till detta och skapar värde är produktens grafiska gränssnitt. Det möjliggör för kunden att hämta ut data vid behov och spara den i lokala filer för fortsatt behandling. Filer som inte ska användas mer kan därefter tas bort, eftersom de, ifall behov uppstår, kan hämtas från databasen igen. Det blir mer praktiskt för kunden att använda data på det sättet. Prestandan kommer även öka avsevärt med en MySQL-databas. Kunden har berättat att det var ett pro-blem med deras gamla system att det tog för lång tid att importera data från en mätning för granskning. Det blir snabbt och smidigt att med hjälp av gränssnittet hämta precis den data som önskas, exempelvis alla mätningar som gjordes ett visst år eller på ett visst instrument. En annan fördel med det nya systemet är att det är mindre risk att data förloras på grund av oväntade fel på hårddiskarna. Det finns tillförlitliga tekniker för att minska risken av data-förlust på persondatorer, men det är rimligt att anta att en databasserver är robustare både vad gäller feltolerans och säkerhet.

5.2. Processbeskrivning

Kunden använde, som tidigare nämnt, XML-filer för att spara sin data. XML är lämpat till hierarkiska relationer, men i kundens XML-filer fanns få hierarkiska relationer. Kundens data kunde därför lämpligare representeras i tabellform. SQL är en industristandard för databaser och har varit det i över 20 år. SQL har stöd för lås och transaktioner av tabeller, vilket ser till att data kan uppdateras utan konflikter.

Att kunden får ett effektivare system gynnar hela NFC och även Polismyndigheten. Kunden kan spara tid och organisationen kan spara pengar, som då kan användas till andra ändamål. Eftersom kundens organisation är statlig är detta en viktig aspekt av det nya systemet. Värdet för kunden minskade något då gruppen inte hann implementera krav av prioritet två. De kraven var:

• Generera sammanfattning av data för en körning – Presentera resultaten i text på ett tydligt sätt • Presentera trender i data grafiskt

– Sammanfatta flera filers sammanfattningar – Presentera sammanfattningarna grafiskt

Kunden kan redan göra dessa saker själv via Excel-filer, men det tar tid. Hade gruppen hunnit implementera även dessa krav hade kunden kunnat spara ytterligare tid.

5.1.5

Alternativ implementation

Vissa delar av implementationen var inte möjliga att påverka, då kunden explicit begärt ett system implementerat i Java och MySQL. Följden av detta blev att det var svårare att skapa ett användbart och attraktivt användargränssnitt än om en mer flexibel teknik som gruppen hade större erfarenhet av fått användas, exempelvis webbprogrammering. Det hade också kunnat gå smidigare att göra all parsning av filer och filnamn i ett mindre verbost skript-språk som Python. Gällande MySQL tog det mycket tid att hitta och inkorporera lämpliga testramverk i produkten, tid som möjligen kunnat investeras bättre vid val av en annan data-bashanterare.

Bland det som gruppen hade kontroll över fanns valet mellan Maven, Gradle och Docker. Gruppen valde att använda Maven och var nöjda med detta. Det är dock möjligt att upp-sättningen av utvecklingsmiljön för gruppens medlemmar hade gått smidigare om Docker använts. Huruvida gruppen borde valt Gradle istället för Maven berörs i appendix C.

5.2

Processbeskrivning

Detta avsnitt presenterar arbetet som gjorts med en process i fokus och kvalitetskrav.

5.2.1

Utvärdering av process

Utvärdering av processen skedde genom den framtagna enkäten, se appendix H för slutgiltig version. Resultaten från enkäten redovisas i tabell 5.1.

Det första utkastet av enkäten bestod av fem frågor där svarsalternativen var på en skala mellan 1-10, där 1 innebär starkt avståndstagande från frågans påstående och 10 innebär starkt medhåll för frågans påstående. Tanken med att ha en bred skala var att alla grupp-medlemmar skulle finna ett alternativ som passade in på deras upplevelse. I återkopplingen

5.2. Processbeskrivning

Tabell 5.1: Resultat från sprintutvärderingar

Sprint Poäng 1 135 2 132 3 102 4 107 5 116 6 136

från programvarukvalitets-studenterna poängterades att denna stora skala istället bidrog till förvirring, och att det faktiskt inte var en stor skillnad mellan exempelvis 4, 5 och 6. Skalan reducerades därför till 1-5.

För att förbättra utvärderingen och därmed möjligheterna till förbättring av processen togs en ny upplaga av enkäten fram när resultatet började bli sämre runt sprint 3. Eftersom den gamla versionen av enkäten inte innehöll någon motivering av sifferomdömena, var det svårt för kvalitetssamordnaren att föreslå relevanta förbättringar inför nästkommande sprint. Som lösning till detta introducerades en textruta för att motivera valet efter varje fråga med en skala. Detta underlättade förbättringen av processen inför nästa sprint. Vidare skapades en del där gruppen skriftligen fick svara på frågor mer utförligt. Under denna sektion fanns frågor som ”Vad fungerade bra under denna sprint?”. Genom att medlemmarna hade mer frihet i svaren lyftes mer konkreta förbättringsområden.

5.2.2

Förbättring av process

Utifrån resultatet av enkäten som återfinns i appendix H presenterade kvalitetssamordnaren förbättringsförslag vid varje sprintplanering. Dessa förslag accepterades av gruppen vid samtliga tillfällen, och det lades särskilt fokus på att genomföra dem under den komman-de sprinten. Konkreta exempel på hur komman-detta kunkomman-de se ut presenteras i tabell 5.2.

Tabell 5.2: Exempel på genomförda förbättringar utifrån enkätsvar

Kommentar i enkäten Genomförd förbättring

Ojämn fördelning av uppgifter Införde fler avstämningsmöten under sprint-en med möjlighet att omfördela uppgifter Svårt att hitta rätt info i Teams Skapade fler kanaler som kunde användas

för att separera information

Missförstånd i kommunikation med kund Planerade in demonstration för kunden varje vecka

Svårtolkade uppgifter i den agila brädet La till informationstext för uppgifter

Enligt tabell 5.1 är det tydligt att totalpoängen minskade i början, vilket implicerar att process-ens kvalitet minskat. Varför detta har hänt kan bero på flera olika aspekter. Sprint 3 var den enda sprint som varade i tre veckor – övriga var två veckor långa – och låg även under en tentamensperiod. Enkätsvaren handlade mycket om att den uppsatta planeringen inte följts samt att studier inför tentamina prioriterades. Detta kan förklara varför totalpoängen sjönk från den tidigare sprinten.

Sprint 4 gav ett högre resultat än sprinten innan, vilket är målet med att göra dessa sprint-utvärderingar. Däremot är poängen för sprint 4 betydligt lägre än medelvärdet. Under denna sprint tog medlemmarna på sig betydligt mer arbetsuppgifter än tiden tillät, vilket bevisligen ledde till ett försämrat resultat. Som en följd av detta introducerades det flera

avstämnings-5.2. Processbeskrivning

möten. Syftet med detta var att alla skulle ha en bättre möjlighet att förmedla att arbetsbelst-ningen blivit för hög alternativt för låg.

Sprint 6 gav den största poängökningen jämfört med den föregående sprinten. Kommentarer från enkäten var väldigt överensstämmande och handlade mest om kommunikationen med kunden. Som ett möjligt förbättringsområde föreslogs en demonstration och frågestund med kunden en gång per vecka. Syftet med detta var att kunden skulle få möjligheten att se hur funktionaliteten implementerats, så att inget missförstånd uppstått varken gällande layout eller funktionalitet.

5.2.3

Kvalitetskrav

Nedan presenteras resultaten från kvalitetskraven.

Portabilitet

Under projektets gång beslöt kunden att endast fokusera på en version av Windows, och därmed blev portabilitetskravet inaktuellt. Gruppen beslöt dock att fortsätta med metoden att utveckla på olika versioner, och i den mån det blev aktuellt även läsa dokumentation för nya bibliotek. Ingen i gruppen upptäckte någonsin något som inte var portabelt bland de bibliotek och funktioner som användes.

Användarvänlighet

De användartester som utfördes i samband med demonstrationer för kunden var en viktig orsak till kontinuerliga förtydliganden av avsikter och justeringar av krav, då kunden in-såg vad som var högst respektive lägst prioriterat. Genom de interna granskningarna inom gruppen kunde småmissar rättas till och kvaliteten på produkten höjas innan den togs till kunden.

Under demonstrationer användes det grafiska gränssnittet som kompass för att identifiera krav som missats, eller möjliga förbättringsområden på existerande funktionalitet. Eftersom kunden kunde peka på specifika komponenter i det grafiska gränssnittet blev det enklare för gruppen att förstå vad kunden menade. Detta minskade risken för missförstånd, vilket ledde till att implementationen av ny funktionalitet som diskuterats med kunden oftast fick posi-tiv återkoppling. Exempel på saker som framkom tack vare dessa tillfällen var vilka sökfält som skulle finnas i gränssnittet, att viss uppladdning skulle ske automatiskt istället för vid knapptryck samt att transaktioner och riggkörningar skulle hanteras separat.

Hållbarhet

När produkten började nå ett slutskede utfördes hållbarhetsmätningar enligt MI-indexet pre-senterat i avsnitt 4.4.3, vars resultat presenteras i tabell 5.3. Samtliga resultat var över 20, och är därmed klart godkända ur underhållssynpunkt.

Tabell 5.3: Resultat från hållbarhetsmätningar

Datum LOC (medel) CC HV MI

22/4 1027 (103) 2.82 92.73 41 26/5 3385 (153) 3.04 174.2 36