Visualisering av kontinuerlig integration

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/039--SE

Visualisering av kontinuerlig

integration

Visualization of continous integration

Joakim Argillander

Victor Bodin

Sebastian Callh

Rebecca Lindblom

Johan Nåtoft

Johan Thornström

Jonathan Wahlund

Daniel Wassing

Handledare : Lena Buffoni Examinator : Kristian Sandahl

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum 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 kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ 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 sam-manhang som är kränkande för upphovsmannenslitterä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 circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, 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 con-sent 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 Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c Joakim Argillander Victor Bodin Sebastian Callh Rebecca Lindblom Johan Nåtoft Johan Thornström Jonathan Wahlund Daniel Wassing

(3)

Sammanfattning

Den här rapporten behandlar ett kandidatarbete som utfördes av åtta stycken studenter från civilingenjörsutbildningarna datateknik och mjukvaruteknik på Tekniska Högskolan vid Linköpings Universitet. Målet med projektet var att utveckla en applikation för att visualisera kontinuerlig integration. Beställning av applikationen gjordes av kunderna Ola Leifler och Kristian Sandahl på Institutionen för Datateknik (IDA) på Linköpings universitet å Software Centers vägnar.

Utvecklingsarbetet utfördes enligt den agila utvecklingsmetodiken Scrum med diverse anpassningar. Under utvecklingsarbetets gång gjordes olika sorters prototyper för att säk-erställa vilka krav kunden hade på applikationen samt att projektgruppens och kundens tankar om applikationen överensstämde.

Projektet resulterade i en applikation som visualiserar kontinuerlig integration i tre olika nivåer. Projektgruppen erhöll även erfarenheter inom utveckling av mjukvara från start till leverans, hur man reder ut en kunds krav med hjälp av prototyper samt gruppdynamik i en projektgrupp.

Rapporten innehåller åtta stycken individuella bidrag där varje projektmedlem har skrivit en rapportdel om en erfarenhet eller fördjupning inom ett område kopplad till sin projektroll eller utvecklingen.

(4)

Författarnas tack

Vi som skrivit den här rapporten fick möjlighet att genomföra projektet tack vare Institutio-nen för Datateknik vid Linköpings universitet. Vi vill tacka Ola Leifler och Kristian Sandahl för gott samarbete.

Vi vill även rikta ett stort tack till vår handledare Lena Buffoni för hennes stöd och feed-back under projektets gång.

(5)

Innehållsförteckning

Figurlista xi Tabellista xiv Definitioner xv

I

Gemensam del

1

1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 3 1.3 Frågeställningar . . . 3 1.4 Avgränsningar . . . 3 2 Bakgrund 4 3 Teori 5 3.1 Verktyg . . . 5 3.1.1 Git . . . 5 3.1.2 Trello . . . 5 3.1.3 Slack . . . 5 3.1.4 InVision . . . 5 3.2 Kontinuerlig integration . . . 6 3.3 Scrum . . . 6 3.4 Kanban . . . 7 3.5 Feature branch-arbetsflöde . . . 8 3.6 Informationsvisualisering . . . 8 3.7 Prototyper . . . 8 3.8 Användbarhetstest . . . 9 3.9 635-metoden . . . 9

3.10 Mjukvara som applikationen baseras på . . . 9

3.10.1 Eiffel . . . 9 3.10.2 MongoDB . . . 9 3.10.3 Node.js . . . 10 3.10.4 Meteor . . . 10 3.10.5 HTML . . . 10 3.10.6 CSS . . . 10 3.10.7 Bootstrap . . . 10 4 Metod 11 4.1 Projektstruktur . . . 11 4.1.1 Gruppens roller . . . 11

(6)

4.1.2 Resurser . . . 12 4.1.3 Dokumentation . . . 12 4.1.4 Möten . . . 13 4.1.5 Intern kommunikation . . . 13 4.1.6 Standarder . . . 13 4.2 Förstudie . . . 14 4.2.1 Kravinsamling . . . 14 4.2.2 Prototyper . . . 14 4.3 Utvecklingsmetod . . . 15 4.3.1 Anpassning av Scrum . . . 15 4.3.2 Arbetsflöde . . . 15 4.3.3 Arbetsprocess . . . 16 5 Resultat 17 5.1 Testning . . . 17 5.2 Prototyper . . . 17 5.3 Systembeskrivning . . . 20 5.3.1 Systemanatomi . . . 20 5.3.2 Moduler . . . 21 5.4 Användargränssnitt . . . 22 5.4.1 Aggregering . . . 23

5.4.2 Detaljerad vy över en händelsetyp . . . 24

5.4.3 Händelseflöden . . . 26

5.5 Gemensamma erfarenheter . . . 26

5.5.1 Tidigare erfarenheter . . . 26

5.5.2 Nya erfarenheter . . . 27

5.6 Överblick över individuella undersökningar . . . 27

6 Diskussion 28 6.1 Resultat . . . 28 6.1.1 Systemanatomi . . . 28 6.1.2 Backend i Java . . . 29 6.1.3 Användargränssnitt . . . 29 6.2 Metod . . . 29 6.2.1 Gruppens struktur . . . 30 6.2.2 Möten . . . 30 6.2.3 Dokumentationsmetoden . . . 30 6.2.4 Utvecklingsmetoden . . . 31 6.2.5 Prototypningen . . . 31

6.2.6 Deadlines och tidsplanering . . . 32

6.3 Arbetet i ett större sammanhang . . . 32

6.3.1 Etiska och samhälleliga aspekter . . . 32

6.3.2 Miljöaspekter . . . 32

7 Slutsatser 34 7.1 Hur kan en webbapplikation för visualisering av kontinuerlig integration im-plementeras så att man skapar värde för kunden? . . . 34

7.2 Hur kan man använda pappersprototyper för att underlätta kravinsamling? . . 34

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 35 7.4 Vilka erfarenheter kan dokumenteras från programvaruprojektet

(7)

II Individuella delar

36

A Anpassning av testmetoder för småskalig utveckling av Joakim Argillander 37

A.1 Introduktion . . . 37 A.1.1 Motivering . . . 37 A.1.2 Målsättning . . . 37 A.1.3 Frågeställningar . . . 37 A.1.4 Avgränsningar . . . 37 A.2 Teori . . . 38 A.2.1 Arbetsflöde . . . 39 A.3 Metod . . . 39 A.4 Resultat . . . 39 A.4.1 Enhetstest . . . 39 A.4.2 Funktionstest . . . 40 A.4.3 Regressionstest . . . 40 A.4.4 Acceptanstest . . . 40 A.5 Diskussion . . . 40 A.6 Slutsatser . . . 41

B Kodgranskning som en kvalitetsmetod av Victor Bodin 42 B.1 Introduktion . . . 42 B.1.1 Motivering . . . 42 B.1.2 Målsättning . . . 42 B.1.3 Frågeställningar . . . 42 B.1.4 Avgränsningar . . . 43 B.2 Teori . . . 43 B.2.1 Parprogrammering . . . 43 B.2.2 Fjärrgranskning . . . 43 B.3 Metod . . . 43

B.3.1 Metod för framtagning av arbetsflöde . . . 43

B.3.2 Enkäter . . . 44

B.3.3 GitLab- och Trellodata . . . 44

B.4 Resultat . . . 44 B.4.1 Sprint ett . . . 44 B.4.2 Sprint två . . . 44 B.4.3 Sprint tre . . . 45 B.4.4 Sprint fyra . . . 46 B.5 Diskussion . . . 46 B.5.1 Resultat . . . 46 B.5.2 Metod . . . 46 B.6 Slutsatser . . . 46

C Användning av workshops för kompetensutveckling av Sebastian Callh 48 C.1 Introduktion . . . 48 C.1.1 Syfte . . . 48 C.1.2 Frågeställningar . . . 48 C.1.3 Avgränsningar . . . 48 C.2 Bakgrund . . . 49 C.3 Teori . . . 49 C.3.1 Workshop . . . 49 C.3.2 Live-kodning . . . 49 C.4 Metod . . . 49 C.5 Resultat . . . 51

(8)

C.6 Diskussion . . . 51

C.6.1 Resultat . . . 51

C.6.2 Metod . . . 52

C.6.3 Arbetet i ett större perspektiv . . . 52

C.7 Slutsatser . . . 52

D Prototypers påverkan på utveckling av användargränssnitt av Rebecca Lindblom 53 D.1 Introduktion . . . 53 D.1.1 Syfte . . . 53 D.1.2 Frågeställningar . . . 53 D.1.3 Avgränsningar . . . 53 D.2 Teori . . . 54 D.2.1 Designprocessen . . . 54

D.2.2 Prototyper inom mjukvaruutveckling . . . 54

D.3 Metod . . . 55 D.3.1 Datainsamling . . . 56 D.4 Resultat . . . 56 D.4.1 Gruppmedlemmarnas prototyper . . . 56 D.4.2 Svar från enkät . . . 57 D.5 Diskussion . . . 59 D.5.1 Resultat . . . 59 D.5.2 Metod . . . 59 D.6 Slutsatser . . . 60 D.6.1 Frågeställning 1 . . . 60 D.6.2 Frågeställning 2 . . . 60 D.6.3 Frågeställning 3 . . . 60

E Retrospektiv - hur det hjälper team att effektivisera sitt arbete av Johan Nåtoft 61 E.1 Introduktion . . . 61 E.1.1 Motivering . . . 61 E.1.2 Målsättning . . . 61 E.1.3 Frågeställningar . . . 62 E.1.4 Avgränsningar . . . 62 E.2 Teori . . . 62 E.2.1 Retrospektiv . . . 62

E.2.2 Erfarenheter från andra studier . . . 63

E.3 Metod . . . 63

E.3.1 Implementation . . . 63

E.3.2 Utvärdering av Retrospektiven . . . 64

E.4 Resultat . . . 64

E.4.1 Sammanställning av data . . . 64

E.4.2 Utvärderingsformuläret . . . 65

E.5 Diskussion . . . 65

E.5.1 Metod . . . 66

E.5.2 Resultat . . . 66

E.6 Slutsatser . . . 67

E.6.1 Till vilken grad hjälper då Retrospektiv arbetsgruppen att fullfölja beslut som effektiviserar gruppens arbete samt förbättrar gruppens samarbete? . . . 67

F Utveckling med Meteor av Johan Thornström 69 F.1 Introduktion . . . 69

(9)

F.1.2 Frågeställning . . . 69

F.2 Bakgrund . . . 70

F.3 Teori . . . 70

F.3.1 Meteor . . . 70

F.3.2 Node Package Manager . . . 71

F.4 Metod . . . 71

F.5 Resultat . . . 71

F.5.1 Meteors fördelar . . . 71

F.5.2 Meteors nackdelar . . . 72

F.5.3 Användning av externa bibliotek . . . 72

F.6 Diskussion . . . 72

F.7 Slutsats . . . 73

G Hur projektgruppen använt de verktyg som valts för utveckling av mjukvara av Jonathan Wahlund 74 G.1 Inledning . . . 74 G.1.1 Syfte . . . 74 G.1.2 Frågeställningar . . . 74 G.1.3 Avgränsningar . . . 75 G.2 Bakgrund . . . 75

G.3 Teori, metod och källor . . . 75

G.3.1 Valda verktyg i utvecklingsprocessen . . . 75

G.4 Resultat och analys . . . 76

G.4.1 Redogörelse för använda verktyg i utvecklingsprocessen . . . 76

G.4.2 Analys av använda verktyg och projektgruppens utvecklingsprocess . . 77

G.5 Diskussion . . . 78

G.6 Slutsatser . . . 79

H Val av verktyg vid projektdokumentation av Daniel Wassing 81 H.1 Introduktion . . . 81 H.1.1 Motivering . . . 81 H.1.2 Målsättning . . . 81 H.1.3 Frågeställningar . . . 82 H.1.4 Avgränsningar . . . 82 H.2 Bakgrund . . . 82 H.3 Teori . . . 82 H.3.1 LaTeX . . . 82 H.3.2 Git . . . 83 H.3.3 Google Drive . . . 83 H.3.4 ShareLaTeX . . . 83 H.3.5 Microsoft Office . . . 83 H.3.6 WYSIWYG . . . 84 H.4 Metod . . . 84 H.5 Resultat . . . 84 H.5.1 LaTeX . . . 84 H.5.2 Git . . . 85 H.5.3 Google Drive . . . 86 H.5.4 ShareLaTeX . . . 86 H.5.5 Microsoft Office . . . 87 H.6 Diskussion . . . 87

H.6.1 Dokumentation enligt WYSIWYG . . . 88

H.6.2 Dokumentation med typsättning och versionshantering . . . 88

(10)

H.6.4 Kontrolläsning av dokument . . . 89

H.6.5 Lagring av dokument . . . 89

H.6.6 Koordinering av arbetet . . . 90

H.6.7 Metod . . . 91

H.7 Slutsatser . . . 91

H.7.1 Vilka verktyg finns tillgängliga för att dokumentera i ett projektarbete och vilka uppenbara för- och nackdelar medför de? . . . 91

H.7.2 Vilka kriterier väger tyngst vid valet av verktyg att dokumentera med? 91

III Bilagor

93

Bilaga 1 Frågeformulär för utvärdering av workshop 94 1 Frågeformulär inför workshop . . . 94

2 Frågeformulär efter workshop . . . 95

3 Frågeformulär efter utveckling . . . 95

Bilaga 2 Kravspecifikation för system till Donaldknuthias regering 96 1 Arkitekturkrav . . . 96

2 Funktionella krav . . . 97

Bilaga 3 Uppgift för prototypning 98 1 Skissbas för prototypuppgift . . . 98

2 Prototypuppgift . . . 98

3 Gruppmedlemmars resultat av prototypuppgift . . . 99

Bilaga 4 Frågeformulär: Att arbeta med och utan prototyper 103 1 Frågeformulär: Att arbeta med och utan prototyper . . . 103

1.1 Hjälpknapp och hjälpruta . . . 103

1.2 Tabell i den detaljerade vyn . . . 107

1.3 Avslutande frågor . . . 109

Bilaga 5 Resultat från frågeformulär om prototyper 110 1 Resultat från enkät om prototyper . . . 110

1.1 Hjälpknapp och hjälpruta . . . 110

1.2 Tabellen i den detaljerade vyn . . . 113

1.3 Avslutande frågor . . . 115

Bilaga 6 Frågeformulär för utvärdering av hur verktyg har använts för utveckling av mjukvara 119 Bilaga 7 Resultat från utvärdering av hur verktyg har använts för utveckling av mjukvara 120 Bilaga 8 Frågeformulär för utvärdering av sprint 125 Bilaga 9 Formulär för utvärdering av retrospektiv 128 Bilaga 10 Sammanställning av data från retrospektiv 130 1 Bra och Bättre . . . 134

(11)

Figurlista

3.1 En illustration över ett KI-flöde. . . 6

3.2 En illustration över vattenfallsmodellens olika stadier. . . 6

3.3 En illustration över Kanbans flödesschema. . . 7

3.4 En illustration över Meteors arkitektur. . . 10

4.1 En illustration över Gruppens arbetsflöde i Trello. . . 13

4.2 En illustration över hur spårbarhet uppnåddes. . . 15

5.1 Prototyp för den aggregerade vyn och händelse vid placering av mus-pekaren på en nod. . . 18

5.2 Prototyp för diagramläget samt tabelläget för den detaljerade vyn. . . 19

5.3 Prototyp för ett händelseflöde. . . 19

5.4 Översikt av systemet. . . 20

5.5 Systemets anatomi. . . 21

5.6 Översikt av klientens moduler. . . 21

5.7 Aggregeringsvyn med navigationspanelen till höger. . . 22

5.8 Hjälprutan har öppnats ovanpå den aggregerade vyn. . . 22

5.9 Informationsruta som dyker upp om klienten tappar kontakten med servern. . . 23

5.10 Symbol för att indikera att klienten väntar på svar från servern. . . 23

5.11 En informationsruta öppnas vid klick på en nod. . . 24

5.12 Den detaljerade vyns tabelläge. . . 25

5.13 Den detaljerade vyns diagramläge. . . 25

5.14 Ett händelseflöde, med en öppnad informationsruta. . . 26

A.1 Illustration över ett tänkt arbetsflöde . . . 39

C.1 En funktionskurva över mängden kodändringar i gruppens version-shanteringssystem med workshoppen utmärkt. . . 51

D.1 Illustration över hur designprocessen minskar osäkerheten i ett projekt. . 54

D.2 En av prototyperna gjord av en gruppmedlem enligt uppgiften. . . 57

F.1 Syntax för klient och server i Meteor. . . 71

Bilaga 3.1 Skissbas gruppmedlemmarna var givna att utgå från för sin prototyp. . . 98

Bilaga 3.2 Prototyp av gruppmedlem A gjord enligt uppgiften. . . 99

Bilaga 3.3 Prototyp av gruppmedlem B gjord enligt uppgiften. . . 99

Bilaga 3.4 Prototyp av gruppmedlem C gjord enligt uppgiften. . . 100

Bilaga 3.5 Prototyp av gruppmedlem D gjord enligt uppgiften. . . 100

Bilaga 3.6 Prototyp av gruppmedlem E gjord enligt uppgiften. . . 101

Bilaga 3.7 Prototyp av gruppmedlem F gjord enligt uppgiften. . . 101

(12)

Bilaga 4.1 Hjälpknapp och hjälpruta, version 1 . . . 103

Bilaga 4.2 Förtydligande av hjälpknapp och hjälpruta, version 1 . . . 104

Bilaga 4.7 Prototyp för tabellen i den detaljerade vyn skapad av gruppen under förstudien. . . 107

Bilaga 4.8 Tabellen i den detaljerade vyn, version 1. . . 107

Bilaga 4.9 Tabellen i den detaljerade vyn, version 2. . . 108

Bilaga 5.1 Fråga 1.1: Hur väl stämmer hjälprutan version 1 överens med din proto-typ? . . . 110

Bilaga 5.2 Fråga 1.2: Hur nöjd är du med resultatet i hjälprutan version 1? . . . 111

Bilaga 5.7 Fråga 4.1: Hur väl stämmer prototypen överens med din initiala bild av prototypens utseende? . . . 113

Bilaga 5.8 Fråga 4.2: Hur nöjd är du med tabellens utseende i denna prototyp? . . . 113

Bilaga 5.9 Fråga 5.1: Hur väl stämmer tabellen version 1 överens med gruppens prototyp? . . . 114

Bilaga 5.10 Fråga 5.2: Hur nöjd är du med resultatet i tabellen version 1? . . . 114

Bilaga 5.11 Fråga 6.1: Hur väl stämmer tabellen version 2 överens med gruppens prototyp? . . . 114

Bilaga 5.12 Fråga 6.2: Hur nöjd är du med resultatet i tabellen version 2? . . . 115

Bilaga 5.13 Fråga 7.1: Upplever du att du har fått göra om features för att resultatets utseende inte stämde överens med andra gruppmedlemmars bild av det? 115 Bilaga 5.14 Fråga 7.2: Tycker du att det har underlättat utvecklingen att jobba med prototyper? . . . 116

Bilaga 5.15 Fråga 7.4: Tycker du att tiden som spenderats på att ta fram prototyper har varit väl spenderad tid? . . . 117

Bilaga 5.16 Fråga 7.5: Hade du velat att gruppen hade tagit fram prototyper för fler features? . . . 117

Bilaga 5.17 Fråga 7.6: Hade du velat att gruppen hade utvecklat de existerande pro-totyperna mer? . . . 118

Bilaga 7.1 Fråga 1: Hur mycket av din projekttid har du lagt på att utveckla mjuk-vara? (utöver obligatoriska möten och seminarium och så). Från “Har ej rört någon kod“ till “Har spenderat all min tid bara programmera“. . . . 120

Bilaga 7.2 Fråga 2: Vilken editor har du främst använt för att koda i appen? . . . 121

Bilaga 7.3 Fråga 3: Varför valde du denna editor? . . . 121

Bilaga 7.4 Fråga 4: Hur tycker du att ditt val av editor har påverkat utvecklingen av mjukvara? Från “Försämrat utvecklingen“ till “Underlättat utveck-lingen väldigt mycket“. . . 121

Bilaga 7.5 Fråga 5: Hur tycker du att Git har påverkat utvecklingen av mjukvara? Från “Försämrat utvecklingen“ till “Underlättat utvecklingen väldigt mycket“. . . 122 Bilaga 7.6 Fråga 6: Har du fått hjälp med Git när du behövt? Från “Nej“ till “Alltid“. 122

(13)

Bilaga 7.7 Fråga 7: Hur tycker du att Trello har påverkat utvecklingen av mjuk-vara? Från “Försämrat utvecklingen“ till “Underlättat utvecklingen väldigt mycket“. . . 122 Bilaga 7.8 Fråga 8: Hur tycker du att Slack har påverkat utvecklingen av mjukvara?

Från “Försämrat utvecklingen“ till “Underlättat utvecklingen väldigt mycket“. . . 123 Bilaga 9.1 Formulär för utvärdering av retrospektiv del 1 . . . 128 Bilaga 9.2 Formulär för utvärdering av retrospektiv del 2 . . . 129

(14)

Tabellista

1.1 En tabell över utvecklingsplattformar. . . 3

4.1 En tabell över producerade dokument. . . 12

B.1 Svar från enkät om kodgranskning efter sprint två. . . 45

C.1 En tabell över områden lämpade för kompetensutveckling. . . 50

D.1 Datum för versioner av utvalda delar för jämförelse. . . 55

D.2 Datum för händelser i utvecklingsarbetet av utvalda delar för jämförelse. 56 D.3 Medelvärdet för överensstämmelse och nöjdhet över de olika version-erna av hjälpruta. . . 58

D.4 Medelvärdet för överensstämmelse och nöjdhet över de olika version-erna av tabell. . . 58

Bilaga 1.1 En tabell över frågorna i frågeformuläret inför workshoppen. . . 94

Bilaga 1.2 En tabell över frågorna i frågeformuläret efter workshop. . . 95

Bilaga 1.3 En tabell över frågorna i frågeformuläret efter utveckling. . . 95

Bilaga 2.1 En tabell över systemets arkitekturkrav. . . 96

Bilaga 2.2 En tabell över systemets funktionella krav. . . 97

Bilaga 4.1 Frågor om hjälpknapp och hjälpruta, version 1 . . . 104

Bilaga 4.4 Frågor om prototyp för tabellen i den detaljerade vyn. . . 107

Bilaga 4.5 Frågor om tabellen i den detaljerade vyn, version 1. . . 108

Bilaga 4.6 Frågor om tabellen i den detaljerade vyn, version 2. . . 108

Bilaga 4.7 Frågor som ställdes sist i enkäten. . . 109

Bilaga 5.1 Fråga 7.3: På vilket/vilka sätt har det underlättat/inte underlättat? . . . 116

Bilaga 5.2 Fråga 7.7: Kommentarer (frivillig) . . . 118

Bilaga 6.1 En tabell över frågorna i frågeformuläret om hur verktyg har använts för utveckling av mjukvara. . . 119

Bilaga 7.1 Fråga 9: Vilka problem ser du med de verktyg vi använt för att utveckla mjukvara? . . . 123

Bilaga 7.2 Fråga 10: Vilka problem ser du med hur verktygen har använts av gruppmedlemmarna? . . . 124

Bilaga 7.3 Fråga 11: Om du skulle vilja ändra något med verktygen eller hur de används, vad skulle det vara? . . . 124 Bilaga 7.4 Fråga 12: Om du kan, hitta på ett verktyg som vi skulle kunna använda

(15)

Definitioner

Artefakt Ett fabricerat föremål, källkod eller produkt.

Back-end Den kod som exekveras på servern i en

webbapplika-tion.

Chai Ett JavaScript-ramverk för att skriva enhetstester.

Dokumentdatabas En databas som lagrar data som dokument istället för

tabellrader.

Front-end Den kod som exekveras på klienten i en

webbapp-likation.

JavaScript Prototyp-baserat skriptspråk som används i

web-butveckling, främst på klientsidan.

Kompilering En översättning av programkod till maskinkod.

KI Kontinuerlig integration

Meteor-paket JavaScript-modul med färdig funktionalitet.

Pålitlighetsgrad Mått på hur väl en artefakt presterat vid testning.

Relationsdatabas En databas där information är organiserad i

rela-tioner (även kallade tabeller), eventuellt med restrik-tioner inom en och samma relation eller mellan rela-tioner.

Software Control Management, SCM Praktiken att spåra och styra förändringar i

(16)

Del I

(17)

1 Inledning

Den här rapporten beskriver ett projektarbete i kursen TDDD96 Kandidatprojekt i mjukvaru-utveckling. Arbetet utfördes under våren 2017 av en grupp bestående av åtta studenter från civilingenjörsprogrammen i datateknik och mjukvaruteknik vid Linköpings Universitet. Rapporten innehåller dels beskrivning av uppgiften, hur den utfördes och vad resultatet blev. Efter detta diskuteras metoden och resultatet ur perspektivet av rapportens frågeställ-ningar. Slutligen redovisas de individuella utredningar som har utförts enskilt av alla gruppmedlemmar.

1.1 Motivering

Kontinuerlig integration (KI) är en process för att integrera nya uppdateringar med befintlig version av en mjukvara. Varje ny uppdatering passerar genom ett flöde av tester, kompiler-ing, granskningar med mera. Detta flöde genererar mycket information om hur väl den nya uppdateringen har presterat, men hur enkelt är det för intressenter i ett projekt att ta denna information till sig? En programmerare kanske främst vill veta hur väl hens uppdatering har klarat sig genom flödet, medan en person i högre chefsposition kan vara mer intresserad av att se helheten för utvecklingen. En chef kan till exempel vilja ha svar på följande frågor:

• Hur går utvecklingen?

• Hinner vi i tid till släpp av nästa version? • Vilka moment tar mest tid?

En chef utan teknisk spetskompetens kan dock ha svårt att ta till sig de stora mängden de-taljerad information som kommer ur ett KI-flöde. Detta arbete gick ut på att utveckla en applikation som visualiserar denna data grafiskt och gör det lättare att tolka vad som sker i flödet.

(18)

1.2 Syfte

Med denna rapport avses att beskriva den arbetsmetodik som använts och hur ett system på ett lämpligt sätt kan visualisera data. Rapporten syftar också till att beskriva de tekniska resultat som erhållits i samband med genomförandet av detta projekt, samt redovisa de er-farenheter och förbättringsmöjligheter som framkommit under arbetet.

1.3 Frågeställningar

1. Hur kan en webbapplikation för visualisering av kontinuerlig integration imple-menteras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojekt "Visualisering av kon-tinuerlig integration" som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan man använda pappersprototyper för att underlätta kravinsamling?

1.4 Avgränsningar

De avgränsningar som appliceras på applikationen täcker en rad områden. Applikationen är ett verktyg för visualisering och utför därför ingen databehandling. Den är anpassad för större skärmar och därmed inte optimal på mindre skärmar och handhållna enheter. Den är utvecklad med stöd för endast engelska.

Tabell 1.1: En tabell över utvecklingsplattformar.

Operativsystem Webbläsare

Ubuntu 16.04 Firefox 51.0.1 macOS Sierra 10.12.3 Chrome 55.0.2883.95 Windows 8.1, 10 Chrome 55.0.2883.95

Utveckling och testning har skett på ett begränsat antal plattformar som kan ses i tabell 1.1 vilket har lett till att applikationen inte är garanterad att fungera på andra plattformar. Utvecklingen av applikationen har utförts med hjälp av ramverket Meteor. Valet att utveck-ling skulle ske med hjälp av Meteor beslutades efter ett möte med kund, vilket gjorde att andra tänkbara ramverk för applikationer valdes bort.

(19)

2 Bakgrund

Även om KI-system implementeras för att hantera komplexitet, kan även de bli komplexa och svåröverskådliga. Konsortiet Software Center arbetar tillsammans med bland annat Linköpings Universitet för att studera storskaliga mjukvarumiljöer för kontinuerlig integra-tion och det var de som lade grunden för det här projektet.

Kunden för detta projekt var Kristian Sandahl och Ola Leifler ifrån Institutionen för datateknik (IDA) på Linköpings Universitet som på Software Centers vägnar ville ha en webbapplikation för att visualisera KI-system. Målet var att ge ett beslutsstöd för intressen-ter utan teknisk kompetens genom att på ett lättöverskådligt sätt kunna identifiera flaskhalsar och eventuella problem i KI-system.

Projektet utfördes som en del av kursen TDDD96 Kandidatprojekt i programvaruutveckling av åtta studenter från civilingenjörsprogram i datateknik och mjukvaruteknik. Tillsammans med projektdirektivet tillhandahölls även en tidigare utvecklad prototyp av systemet.

(20)

3 Teori

Det här kapitlet ämnar redogöra för de verktyg och begrepp som är viktiga att känna till för att förstå projektets innebörd.

3.1 Verktyg

3.1.1 Git

Git är en mjukvara för att versionshantera kod. Användaren kopplar sig via ett klientpro-gram till versionshanteringsarkivet via internet som ligger uppe på värdens server. Genom klientprogrammet kan användaren ladda upp ny kod till arkivet och hämta hem andras kod. Git möjliggör för flera personer att sitta och ändra i samma kod på olika ställen, för att senare kunna sammanfoga alla ändringarna på ett lätt sätt. Alla ändringar som görs sparas som historik så att man alltid kan gå tillbaka till äldre versioner och exempelvis se vem som gjort vad. [1]

3.1.2 Trello

Trello är en webbapplikation för planering där man kan skapa visuella tavlor och dela dessa med andra personer i samma projekt. På dessa tavlor kan man skapa och placera Trello-kort som kan flyttas runt i olika listor. Detta kan jämföras med en anslagstavla i den verkliga världen, där Trello-korten är post it-lappar som kan flyttas runt. På Trello-kort kan det skrivas kommentarer och därav föras en konversation. [2]

3.1.3 Slack

Slack är en chattbaserad kommunikationsplattform som finns både för mobil och dator. Den är mer komplex än andra chattapplikationer då man har möjlighet att skapa kanaler och lägga till funktionalitet från tredje part. [3]

3.1.4 InVision

(21)

görs genom att placera ut aktiva områden ovanpå skisserna, och ställa in vilken bild som ska visas när det aktiva området aktiveras genom klick eller att muspekaren placeras ovanpå.[4]

3.2 Kontinuerlig integration

Kontinuerlig integration är processen att integrera mjukvaruartefakter kontinuerligt, så ofta som möjligt och på så sätt i så små bitar som möjligt. Metoden utvecklades för att undvika det så kallade "integrationshelvetet" som vanligtvis uppstår då man skjutit upp integrationen till den punkten att det är en verklig utmaning att sammanfoga alla komponenter och få dem att fungera tillsammans. [5]

Figur 3.1: En illustration över ett KI-flöde.

För att kunna integrera artefakter så ofta som flera gånger per dag behövs en automatiserad process som säkerställer de integrerade artefakternas kvalitet. En illustration över hur det skulle kunna se ut ses i figur 3.1, där en mängd utvecklare arbetar mot en server för Software Control Management (SCM) som meddelar en mängd servrar förändringar som i sin tur au-tomatiskt kompilerar, testar och integrerar den nya mjukvaran för att sedan rapportera hur det gått.

3.3 Scrum

Scrum är ett ramverk för agila utvecklingsmetoder som utvecklades under 1990-talet, med värdeorden transparens, inspektion och anpassning.[6] Viktiga aspekter som det medför är

1. Eftersträva transparens mot kund 2. Jämför producerade artefakter mot krav 3. Vara redo för förändringar i krav

För att beskriva Scrum är det rimligt att jämföra det med den traditionella vattenfallsmodellen .[7] Det är en metod som tagits från tillverkningsindustrin och tillämpats på mjukvaruindus-trin och som kritiserats för dess oförmåga att hantera förändringar i krav och projektdirektiv.

(22)

Ett projekt som följer vattenfallsmodellen har tydliga faser som i följs i sekvens, från fram-tagning av krav till underhåll. En illustration av vattenfalls modellen kan ses i figur 3.2. Till skillnad från vattenfallsmodellen ristas krav ej i sten inom Scrum, och olika moment i projektet kan itereras på. En grupp som tillämpar Scrum har en utsedd produktägare som ansvarar för att besluta vilka funktionalitetskrav som ger mest värde för kund och i vilken ordning det bör utföras. Krav kan även omformuleras, tillkomma och kasseras genom hela projektet. Produktägaren sammanställer kraven i en produkt-backlog som är en lista på funktionalitet sorterad på prioritet vilken representerar projektets omfång vid ett tillfälle. Produkt-backlogen lägger grund för vad som ska utföras i utvecklingsarbetet.

Utvecklingen i Scrum struktureras i sprinter på två till fyra veckor. Inför en sprint bestämmer sig gruppen för en mängd arbete som skall utföras, plockat från produkt-backlogen varpå den läggs i projektets sprint-backlog. Sprint-backlogen är till skillnad från produkt-backlogen låst och får ej ändras under sprinten. Detta för att ge gruppen möjlighet att fokusera på och organisera sig kring en konstant mängd arbete.

Under en sprint hålls dagliga möten som får ta max en kvart där alla gruppmedlemmar närvarar och svarar på frågorna

1. Vad har du gjort sen senast? 2. Vad ska du göra idag? 3. Vilka problem förutspår du?

Scrum-mötena ökar transparensen bland de deltagande och ger möjligheten att bemöta hin-der innan de uppstår. Det är gruppens utsedda Scrum master som ansvarar för att organis-era mötena, och denna arbetar också för att underlätta utvecklingsarbetet. Efter varje sprint utvärderar gruppen sprinten och förbättringsförslag till kommande sprinter tas fram. Pro-duktägaren presenterar även arbetet som sprinten resulterade i för kund och omarbetar krav baserat på kundens åsikter.

3.4 Kanban

Kanban är en arbetsmetodik som går ut på att en grupp har en tavla med kort som från början placeras i en produkt-backlog. [8] Korten med uppgifter flyttas sedan genom arbets-flödet allt eftersom uppgifterna färdigställs. Ett typiskt arbetsflöde innehåller en produkt-backlog, pågående uppgifter, färdiga uppgifter som behöver granskas och klara uppgifter. Nya uppgifter läggs till vid behov och ingen uppgift har en specifik tidsbudget.

(23)

I figur 3.3 visas ett typiskt arbetsflöde inom Kanban. Gruppmedlemmarna får själva plocka uppgifter från produkt-backlogen för att sedan utföra dem.

3.5 Feature branch-arbetsflöde

feature-branch-arbetsflödet går ut på att isolera stabil funktionalitet från funktionalitet som är ny eller under utveckling genom att använda Gits funktionalitet grenar.[9] Det finns alltid en stabil gren som kallas för mästergrenen och en gren med ny funktionalitet som kallas för utvecklingsgrenen. När ny funktionalitet ska utvecklas görs en förgrening från utvecklings-grenen till en funktionalitetsgren där all utveckling sker. När funktionaliteten är klar sam-manfogas funktionalitetsgrenen med utvecklingsgrenen igen, som sedan kan testas noggrant innan den i sin tur sammanfogas med mästergrenen. På så sätt är alltid mästergrenen i lever-ansbart tillstånd.

3.6 Informationsvisualisering

Att visa data med flertalet attribut kan göras på många olika sätt. Något av det mest simpla sätten är att visa data i en tabell, där varje objekt representeras av en rad, och för varje attribut finns en kolumn. De flesta känner sig hemma med att hantera en tabell, men det kan vara begränsande för användaren att hitta den data som eftersöks i tabell. Speciellt svårt blir det när det finns många rader och tio eller fler kolumner. Även om önskad data hittas, så kan användaren fortfarande ställa sig frågan vad mer som gömmer sig i datamängden. Finns det liknande alternativ? Finns det oupptäckta mönster eller korrelationer? En lösning till detta kan vara att lägga in möjligheten att sortera tabellen baserat på de olika attributen, och på så sätt få en interaktiv omplacering. Andra lösningar kan vara att presentera datan på ett helt annrolunda sätt, för att på så sätt förändra användarens mentala modell av hur datamängden ser ut. Om den mentala modellen ser annorlunda ut, ger detta användaren en möjlighet att se datan på ett annat sätt och göra upptäckter som inte hade gjorts i en tabell. [10].

3.7 Prototyper

En prototyp inom utveckling av användargränssnitt till mjukvara är en version av det slut-giltiga systemet eller delar av det, med begränsad eller ingen funktionalitet. Målsättningen med prototyper är att i ett tidigt skede i utvecklingen hitta lösningar och designer av sys-temet för att användaren ska kunna ha så stor nytta av syssys-temet som möjligt. [11] För ett system där större delen av funktionaliteten baseras på användarens interaktion och tolkning av gränssnittet kan också funktioner utvecklas inom ramarna för prototyparbetet.

Det finns många olika sorters prototyper. De kan göras på papper, digitala skisser, delvis kodade eller helt baserat på kod. De kan ha olika grad av interaktion och de styrs eller hanteras på olika sätt. De olika typerna har olika fördelar och passar i olika delar av ett projekt beroende på vilken information man vill få ut från dem. Pappersprototyper lämpar sig allra bäst i början av ett projekt då man vill få de mest övergripande idéerna, men kan också fungera i slutet på ett projekt när mer detaljerade designbeslut ska tas.

En risk med prototyper är att de kan vara underpresterande eller överpresterande. Under-presterande prototyper är obestämda och ambiguösa till den nivån att betraktaren har maximalt utrymme för tolkning, vilket kan vara riskabelt. Detta kan leda till att alla inte delar samma bild av vad prototypen representerar. Överpresterande prototyper har för hög detaljeringsgrad i ett för tidigt skede i ett projekt. Detta kan upplevas som imponerande, men riskerar att medföra att designbeslut tas för tidigt i ett projekt. Detta kan i sin tur medföra att

(24)

slutprodukten inte blir lika bra som den hade kunnat bli, eftersom många designalternativ uteslöts alldeles för tidigt. Effektiva prototyper är en bra balans mellan under- och över-presterande prototyper. De har tillräckligt mycket detaljer för att utvecklingsgruppen ska kunna tolka dem och få inspiration till nya designidéer, men också tillräckligt öppna med utrymme för inga beslut ska tas för tidigt. [12]

Det finns en risk när man arbetar med agila metoder som till exempel Scrum (se avsnitt 3.3) att utvecklingsteamet hoppar över det inledande konceptarbetet och kastar sig direkt på mjukvaran och börjar programmera. Detta kan leda till att teamet i slutet av projektet har en applikation som mycket möjligt kan vara väl implementerad, men som inte är genomtänkt i aspekterna helhet eller nytta för användaren. [11]

3.8 Användbarhetstest

Användbarhetstester är tester som utförs för att få information om hur väl en användare kan förstå och använda ett system. Testerna kan utföras på prototyper, delsystem eller slutgiltigt system. Testerna är en del av utvecklingsprocessen och bör användas kontinuerligt genom ett helt projekt för att säkerställa att systemets uppdateringar följer användarnas förmåga att använda det.[12]

3.9 635-metoden

635-metoden är en metod för att få fram idéer. Sex personer skriver idéer på papper för att svara på en frågeställning på fem minuter. Varje person skriver tre egna idéer. När fem minuter har gått så skickas papperna vidare runt i en cirkel så att alla får skriva tre nya idéer på nästa papper. Detta återupprepas tills alla har skrivit tre idéer på alla papper. Slutligen grupperas idéerna efter relevans och likhet med varandra. [11]

3.10 Mjukvara som applikationen baseras på

Här förklaras kortfattat vilken mjukvara som gruppen inte egenhändigt har tillverkat men som applikationen använder sig av. Alla dessa underliggande applikationer, ramverk eller databaser var önskade av kund att användas i utvecklingen.

3.10.1 Eiffel

Eiffel är ett ramverk för kontinuerlig integration som försöker lösa problemet att en stor mängd enheter behöver kommunicera med varandra igenom ett KI-flöde. Det är tillämpbart på all kommunikation som sker från och med att en kodändring kommit till SCM i figur 3.1. Ramverket möjliggör att sända plattformsoberoende händelser över en gemensam kanal och på så sätt standardisera kommunikationen mellan alla servrar igenom flödet.[13]

Genom att samla all automatiserad kommunikation under samma protokoll möjliggör även Eiffel att samla in och spåra alla händelser i ett KI-flöde på ett enkelt sätt och det är på sådan data applikationen baserar sin rendering.

3.10.2 MongoDB

MongoDB är en dokumentdatabas. Olikt en relationsdatabas så lagrar MongoDB data i doku-ment och returnerar data som till exempel JSON-objekt. Den MongoDB-databasen som ap-plikationen använder är inbyggd i Meteor, men om så skulle önskas så kan en MongoDB-databas delas upp på olika hårdvara för att sprida ut arbetsbelastningen. [14]

(25)

3.10.3 Node.js

Node.js är en exekveringsmiljö för JavaScript baserat på öppen källkod som ofta används för att köra serverapplikationer. Många av basmodulerna och funktionerna i Node.js är skrivna i JavaScript, men även i C och C++. Node.js tolkar JavaScript med hjälp av Googles JavaScript-motor V8 och har stöd för asynkrona funktionsanrop. På så sätt kan flera anrop behandlas parallellt när det körs på en server. [15]

3.10.4 Meteor

Meteor är ett ramverk för webbutveckling i JavaScript baserat på öppen källkod. Ramverket är byggt på Node.js, se avsnitt 3.10.3, och möjliggör implementation av både front-end och back-end i JavaScript. Meteor möjliggör snabb prototypning, integrerar med MongoDB och distribuerar dataändringar automatiskt till klienter utan att utvecklaren behöver skriva kod för synkronisering. [16]

Figur 3.4: En illustration över Meteors arkitektur.

Figur 3.4 visar hur de andra mjukvarukomponenterna som Meteor använder sig av länkas samman. NPM som visas i figuren är pakethanteraren för Node.js.[17] ATMOSPHERE är katalogen för Meteor-paket.

Meteor tillför många kvaliteter till applikationen. Vid utveckling av en Meteor-applikation så behövs t.ex. bara ett språk, JavaScript. Meteor har även väldigt många smarta paket att tillgripa som sparar en mängd tid och fler paket är ständigt inom utveckling. [18]

3.10.5 HTML

HTML är en förkortning för HyperText Markup Language och är ett märkspråk för hypertext. HTML är ett av språken som en webbsida kan skrivas i och hade sitt genombrott under 1980-talet då datorer kommersialiserades för hushållen.

3.10.6 CSS

CSS är en förkortning för Cascading Style Sheets och är ett språk som beskriver presentation-sstilen för ett dokument, såsom färg, typsnitt och textstorlek. CSS är ett språk man använder för att designa innehåll på webbsidor.

3.10.7 Bootstrap

Gränssnittsramverket Bootstrap 3.0 är ett väletablerat ramverk för gränssnitt på webbsidor. Ramverket bygger på öppen källkod och utvecklades av företaget Twitter. Bootstrap stödjer också responsiva gränssnittskomponenter för utveckling av applikationer på mindre, hand-hållna enheter.[19]

(26)

4 Metod

Det här kapitlet går igenom hur arbetet med projektet gick från krav till slutprodukt, vilka ansvarsområden varje medlem hade, vilka resurser användes och hur arbetet dokumenter-ades.

4.1 Projektstruktur

I början av kursen så fick alla välja tilltänkta roller som ingår i ett kandidatprojekt i kursen TDDD96 på Linköpings universitet. En projektplan utarbetades som lade grunden för grup-pens arbete. Några viktiga riktlinjer och ansvarsområden som har guidat gruppen genom kandidatprojektets gång tas upp här.

4.1.1 Gruppens roller

Projektet strukturerades från början i att alla fick välja tilltänkta roller som togs upp i början av kursen. Följande struktur uppnåddes.

Testledare Joakim Argillander - ansvarar för att en testplan finns och följs enligt

överenskommen standard, ser till att krav testas och att testfall finns för alla testbara krav.

Kvalitetsansvarig Victor Bodin - ansvarar för att samordna kvalitetsbeslut och ansvarar

för kvalitetsplanen.

Utvecklingsledare Sebastian Callh - ansvarar för att organisera utvecklingsarbetet.

Agerar Scrum master, tar ansvar för att kompetensen som utveck-lingsarbetet kräver finns och undanröjer hinder för att gruppen ska kunna utveckla så effektivt som möjligt.

Analysansvarig Rebecca Lindblom - ansvarar för kontakt mellan kund och grupp,

analyserar kundens behov och ser till att en uppdaterad och rele-vant kravspecifikation finns.

(27)

Arkitekt Johan Thornström - ansvarar för att ha en översiktlig syn över imple-mentationen och ska kunna fatta beslut om kodens struktur.

Konfigurationsansvarig Jonathan Wahlund- ansvarar för att versionshanteringen fungerar,

hittar lösningar på problem som uppkommer med de verktyg vi använder samt har koll på kod för att kunna ta beslut angående kodpublicering till kund.

Dokumentansvarig Daniel Wassing - ansvarar för att protokoll förs på möten, ser till

att standarder finns och följs för dokument, ser till att det finns ansvariga för alla dokument.

En kort riskanalys genomfördes, och det stod klart att det det var en ganska stor risk för projektets genomförande om medlemmar reste bort eller blev sjuka. Därför tilldelades även alla roller en ersättare om huvudansvarig för en viss roll skulle vara otillgänglig av olika anledningar. Denna ersättare byttes ibland ut vid behov då situationen krävde det, men det gav gruppen riktlinjer att jobba efter.

4.1.2 Resurser

Hela gruppen har haft en tidsbudget på 3200 timmar. Dessa fördelades jämnt på åtta per-soner, så varje person förväntades arbeta 400 timmar med projektet.

Gruppen hade en handledare att tillgå samt lokaler på Linköpings universitet. Kunden tillhandahöll även en virtuell server för testning under applikationens utveckling.

4.1.3 Dokumentation

Gruppen använde Google Drive för att hantera alla typer av dokument som hade med internt arbete att göra. Bland annat ingick här flera standarder om hur dokument och kod skrevs, hur gruppen konfigurerade Git, hur gruppen använde Trello och diverse installationsguider. Alla dokument som levererades till kund producerades med hjälp av LaTeX och version-shanterades genom Git.

Tabell 4.1: En tabell över producerade dokument.

Dokument Beskrivning

Projektplan Projektets plan över lag, förklarade hur gruppen skulle arbeta Kravspecifikation Kraven som ställdes på applikationen återges här

Kvalitetsplan Detaljerade beskrivningar om hur arbetet fungerade Arkitekturbeskrivning Beskrev applikationens struktur

Systemanatomi Visualiserade applikationens anatomi

Testplan Beskrev hur gruppen skulle testa under utvecklingens gång Testrapport Resultat och utvärdering av hittills utförd testning

(28)

4.1.4 Möten

Gruppen hade ett större internt möte varje vecka, vanligtvis måndagar för att samtidigt kunna planera veckan. Utöver interna gruppmöten så hölls handledarmöten nästan varje vecka med gruppens handledare för att få kommentarer på gjort arbete och förslag på kom-mande arbete.

Kundmöten tog plats under projektets gång, med högre frekvens i början för att hjälpa till med informationsinsamlingen. Bland annat så gavs kommentarer och åsikter på proto-typningen av den tänkta slutprodukten.

Både gruppmöten och handledarmöten hade protokoll-skal som användes vid varje möte med en tydlig dagordning för mötet. Dagordningen spikades alltid i början av mötet. Om medlemmar inte kunde närvara fysiskt på mötet men hade tillgång till mobil enhet så bjöds de ibland in över digitalt medium.

4.1.5 Intern kommunikation

Textbaserad intern kommunikation skedde över en Slack-kanal [3]. Denna kanal var utrustad med rum för olika delar av projektarbetet samt verktyg för att underlätta beslutstagande och informationsspridning. Kommunikation och statusuppdateringar angående utvecklingsar-betet skedde med hjälp av Trello [2]. Trello användes aktivt i Scrum-processen som kan ses i avsnitt 4.3.2.

Figur 4.1: En illustration över Gruppens arbetsflöde i Trello.

4.1.6 Standarder

För att säkerställa att allt arbete som gjordes av gruppen skulle hålla en enhetlig standard togs diverse interna standarder fram. De standarder som togs fram var; hur man skriver och ska formulera sig i dokument, vilka stilkonventioner som ska användas vid kodning och för hur testfall för kod ska formuleras.

(29)

del för att säkerställa att det arbete som gjorts av gruppen ska vara lätt att sätta sig in och om vidareutveckling önskas ska inte sättet som dokumentation och utveckling gjorts på vara ett hinder.

4.2 Förstudie

Då både datavisualisering och KI var nytt för hela gruppen spenderades mycket resurser i början på att förstå projektets direktiv. Ingen konkret tidsplan för studier gjordes dock. Parallellt så etablerades en projektplan och en kravinsamling påbörjades där en gränss-nittsprototyp användes som hjälpmedel.

Under förstudien genomfördes en iterativ process kring insamlandet av kraven som kunden ställde på applikationen. Efter ett flertal kundmöten så kunde gruppen presentera designen av en prototyp som kunden var nöjd med.

Då det framgick klart att det var Meteor som skulle användas för appen så sammansat-tes en presentation om JavaScript som hela gruppen tog del av tillsammans för att få en introduktion till språket. Alla i gruppen installerade den redan befintliga men inte så funk-tionella prototypen som också den var skriven i JavaScript och Meteor för att få möjligheten att tidigt prova på att utveckla.

4.2.1 Kravinsamling

Gruppens analysansvarig och projektledare intervjuade till en början kunden för att sam-manställa en första kravlista, och fick kort efter kontakt med representanter för applikatio-nens tänkta slutkunder på företagen Ericsson och Grundfos, som också intervjuades.

Kravinsamlingen har skett i ett flertal iterationer då kraven oftast utvecklades i och med de kundmöten som genomfördes. Kunden har haft svårt att se varenda aspekt i designen av applikationen från början och det blev naturligt att fler träffar planerades in så att en tillmötesgående design kunde utformas. Vissa krav utvecklades även på grund av problem som stöttes på under utvecklingen.

4.2.2 Prototyper

För att konkretisera och validera de utvunna kraven skapades prototyper. För ett första utkast på prototyp användes 635-metoden [11] för att gemensamt i gruppen generera idéer för en första prototyp. Alla i gruppen skapade varsitt förslag för olika delar av gränssnittet, och dessa sammanställdes till en första variant som visades för kund. Efter diskussion med kund och några nya idéer skapades en uppdaterad övergripande version som kom att bli grundstommen för gruppen att arbeta efter. Denna prototyp var dock inte heltäckande för all funktionalitet i systemet. Kravspecifikationen uppdaterades med både förändringar och nya krav för att spegla de mer detaljerade överrenskommelserna med kund.

Prototypen som i slutändan tagits fram var i pappersform där systemet hade återgetts i de olika nivåerna på separata papper. Vardera pappersprototyp beskrev systemets aktuella nivå på ett rent visuellt sätt så att kunden fick en idé om designens önskvärda målbild. Senare under projeket har även mindre skissliknande pappersprototyper använts internt för att ta fram utseende på mindre delar av applikationen, men alla delar av appliktionen föregicks inte av prototyper. Under projetets gång har de befintliga prototyperna använts som en gemensam designgrund för att utvecklare att utgå från vid utveckling av användar-gränssnittet.

(30)

4.3 Utvecklingsmetod

Utvecklingen skedde baserat på den agila utvecklingsmetoden Scrum. Eftersom alla gruppmedlemmar inom projektet hade parallellt pågående kurser och ingen permanent lokal för projektet fanns fick vissa anpassningar av Scrum göras, som beskrivs nedan. I övriga avseenden användes Scrum som beskrivet i avsnitt 3.3.

4.3.1 Anpassning av Scrum

Sprinternas längd valdes till två veckor med motiveringen att gruppen använder Scrum för första gången och en kortare sprintlängd ger fler möjligheter till anpassning och förbättring vilket förutspåddes vara behövligt. De dagliga Scrum-mötena som hålls under sprinten bör enligt Scrum hållas vid samma tid och samma plats varje gång, men då det inte var möjligt p.g.a. gruppmedlemmarnas varierande schema planerades de veckovis vid tidpunkter där så många som möjligt kunde närvara.

Produktägaren utgjordes av gruppens analysansvarig när det gällde kommunikation med kund. Eftersom tidigare utbildning inom rollen saknades så beslutades det att analysansvarig inte skulle vara ensam ansvarig att ta fram projektets produkt-backlog, utan att detta ansvar skulle delas av hela gruppen.

Gruppens Scrum master utgjordes av gruppens utvecklingsledare, som agerade som definierat i Scrum. Utvecklingsledarens uppgift var främst att organisera scrum-mötena och understödja gruppen genom att undanröja eventuella hinder för utvecklingen, så som beslut av vilka ramverk och tekniker som skulle användas eller praktiska frågor om kod.

4.3.2 Arbetsflöde

Gruppen arbetade i självorganiserade par. Parprogrammering användes genom hela projek-tet eftersom gruppen saknade tidigare erfarenhet med de ramverk och tekniker som använ-des och parprogrammering underlättade inlärningen genom att möjliggöra diskussion och att ha någon att felsöka med. Trello användes för att spåra arbetet och Git användes för att versionshantera det. I Trello sparades allt arbete som kort i kolumner “produkt-backlog”, “sprint-backlog”, “pågående”, “behöver granskas” och “klar”. Projektets Git-användning var strukturerat enligt feature-branch-arbetsflödet.

Testning

Samma personer som skrev ny funktionalitet skrev även testfall för den. Automatiska tester användes där de kunde men en stor andel av testerna var manuella. För att få sammanfoga en funktionalitets-gren till utvecklings-grenen behövde ett regressionstest klaras av tillsammans med de nya testerna.

Spårbarhet

För att kunna leverera applikationen mot en kravspecifikation användes ett system för att spåra krav till färdig implementation.

(31)

Krav representerades av Trello-kort, som hade etiketter som visade vilka krav de kom ifrån. Korten hade även testfall noterade i sina kommentarer, som i sin tur validerade implemen-tationen. På så sätt var det möjligt att utgåendes från kravspecifikationen se vilka krav som var mötta genom att notera kravets ID, söka upp korresponderande Trello-kort och utföra de tester som fanns noterade där. Se figur 4.2 för en illustration över systemet.

4.3.3 Arbetsprocess

Gruppen har från början försökt att hålla sig till sina respektive roller och med minimala rol-löverskridanden. Allteftersom projektet har fortskridit har även rollöverskridandet utveck-lats. Gruppmedlemmarna har tagit mer ansvar för de olika delarna i arbetet och själva utvecklingsarbetet var även en jämt delad process. Utvecklingen har skett i par om två där samtliga medlemmar har varit involverade på något sätt i att ta fram mjukvara för slutpro-dukten. Dokumentationen har i största mån skrivits individuellt där gruppmedlemmarna tagit delar de antingen ville skriva om eller var direkt ansvariga för. När en gruppmedlem har upplevt att denna är klar med en del av dokumentationen så tilldelas denna del en form av rättningsansvarig som ansvarar för att läsa igenom det aktuella stycket för att godkänna språk och innehåll.

(32)

5 Resultat

I detta kapitel presenteras resultaten som projektet har genererat. Resultaten är bland annat den faktiska webbapplikation som producerats samt de erfarenheter som gruppen dragit på sig under projektets gång. Det ges även en kort översikt av de individuella fördjupningar som gruppens medlemmar genomfört.

5.1 Testning

Under projektets gång utvecklade gruppen en testmetodik för att kunna verifiera att app-likationen möter de krav som etablerats i kravspecifikationen. Vid projektets start skapades en övergripande testplan som beskrev en förlaga till den testmetodik som utvecklades un-der projektet. Då gruppen såg framtagandet av testningsprocesser som ett kontinuerligt ar-bete så kunde dessa utvecklas inkrementellt utifrån gruppens erfarenheter, färdigheter och förväntningar från tidigare iterationer. Vartefter projektet fortlöpte tillkom testuppgifter, olika testverktyg utvärderades och metoder för att frambringa spårbarhet i testningspro-cessen togs fram. Detta resulterade i ett ramverk för testning anpassat för mindre utveck-lingsgrupper arbetandes efter agila principer.

5.2 Prototyper

De slutgiltiga övergripande prototyperna skapades i pappersform, och gjordes delvis inter-aktiva i verktyget InVision.

(33)

Figur 5.1: Prototyp för den aggregerade vyn och händelse vid placering av muspekaren på en nod.

Skiss för den aggregerade vyn syns i figur 5.1. I skissen finns en yta för en aggregerad graf, där grafens noder representerar en händelsetyp i KI-flödet. De flerfärgade noderna illustr-erar grad av godkända körningar för den händelsetypen. Den översta noden i mitten visar en förstorad nod då muspekaren placeras på noden. Rutan innehåller mer detaljerad infor-mation om händelserna i noden. Vid klick på rutan navigerar applikationen till nästa vy. Grafens ruta inkluderar även en navigeringspanel med zoom-reglage, samt en ikon för hjälp. Under grafens ruta finns en tidslinje för att filtrera ut händelser från ett visst tidsspann.

(34)

Figur 5.2: Prototyp för diagramläget samt tabelläget för den detaljerade vyn.

I figur 5.2 visas prototypen för den detaljerade vyn, som innehåller detaljer om en specifik händelsetyp. Där kan användaren välja att visa ett tabelläge eller ett diagramläge. Tabelläget visar en rad för varje händelse i noden, och den kan sorteras baserat på alla kolumner. Vid växling till diagramläget visas olika data för noden över tid. På den horisontella axeln visas tid, och på den vertikala axeln kan användaren välja någon data genom att bläddra i rullistan.

(35)

Den tredje vyn är en graf som visar ett enskilt händelseflöde, se figur 5.3. I denna graf är varje nod en specifik händelse. I den förstorade rutan vid placering av muspekare på en nod finns en länk för att öppna händelsen i programmet som genererade den.

5.3 Systembeskrivning

Denna del beskriver det system som gruppen har tagit fram och ger en överblick på hur systemet fungerar.

Figur 5.4: Översikt av systemet.

En översikt av systemet ges i figur.5.4 Systemet består av en klient och en server. Både klien-ten och servern har utvecklats i ramverket Meteor för JavaScript. Servern sköter all hämtning av data från databasen och levererar den till klienten. Klienten används för all visualisering av Eiffeldata. Den hämtar Eiffelhändelser från servern och visualiserar dom i webbläsaren. De Eiffelhändelserna sparas ner i en lokal databas med namnet Mini Mongo. Klienten är en Single-page application vilket betyder att sidan bara behöver laddas en gång när den startas, så att de individuella delarna på sidan uppdateras dynamiskt utan att behöva ladda om sidan som leder till en bättre användarupplevelse.

Applikationens filstruktur följer Meteors rekommenderade standard.[20] Den följer även Meteors rekommenderade kodstil för hur kod till en applikation implementeras.[21] En tydlig struktur för projektet ger applikationen en enhetlig standard vilket ökar läsbarheten för utvecklaren.

5.3.1 Systemanatomi

En systemanatomin togs fram baserat på de funktionella kraven från kravspecifikationen och användningsfall.

(36)

Figur 5.5: Systemets anatomi.

I figur 5.5 visas systemanatomin för applikationen. Där de primära användarfunktioner för systemanatomin är högst upp i figuren.

5.3.2 Moduler

Figur 5.6: Översikt av klientens moduler.

I figur 5.6 ges en översikt över de moduler som används i applikationen. Applikationens klient är uppdelad i fyra moduler som hanterar de olika typer av funktionalitet som används. I följande lista finns de modulerna och deras uppgift.

• Aggregation.js - Innehåller de funktionsanrop som behövs i de aggregerade graferna. • Eventchain.js - Innehåller de funktionsanrop som behövs när en nod från den

ag-gregerade grafen visas i tabelläge eller diagramläge.

• Details.js - Innehåller funktionsanrop för händelseflöde och har precis som aggrega-tion.js i uppgift att rendera grafer.

• Graph.js - Är modulen där all rendering av grafer för aggregering och händelseflö-den sker. Graph.js använder sig av två externa bibliotek: Cytoscape.js för rendering av graferna och Dagre.js för dess layout.

(37)

5.4 Användargränssnitt

Systemet visar data i tre olika vyer. De tre vyerna är placerade under varandra och vid start presenteras den översta vyn. För att navigera mellan de olika vyerna finns dels funktionalitet i varje vy som beskrivs i följande avsnitt, men också en allmän navigationspanel på höger sida. Vid klick på knapparna för vyerna kommer det visade området att förflyttas till den valda vyn. Hela panelen följer med och syns alltid på skärmen oavsett vilken vy som visas.

Figur 5.7: Aggregeringsvyn med navigationspanelen till höger.

Panelen innehåller även informationsknapp för att öppna en hjälpruta, samt en indikator för uppkoppling mot servern, vilket visas till höger i figur 5.7.

(38)

Hjälprutan som visas i figur 5.8 innehåller information om hur applikationen används.

Figur 5.9: Informationsruta som dyker upp om klienten tappar kontakten med servern.

Indikatorn för uppkoppling mot server är grön då klienten är ansluten till servern. Vid tap-pad anslutning dyker en informationsruta upp som informerar om att anslutningen är bruten samt eventuell anledning, se figur 5.9. Indikatorn blir då röd.

Figur 5.10: Symbol för att indikera att klienten väntar på svar från servern.

I figur 5.10 syns symbolen som roterar över skärmen då klienten väntar på svar på ett anrop till servern.

5.4.1 Aggregering

Aggregeringen representeras av en riktad acyklisk graf, och visar Eiffel-händelser som skett i KI-flödet, se figur 5.7. Varje nod i grafen är en typ av händelse, och innehåller i sin tur varje enskild händelse av den typen. Bågarna pekar på den föregående händelsen i flödet. Noderna har olika former baserat på dess händelsetyp.

Vissa noder är händelser som har en status, exempelvis av implementationen definier-ade aktiviteter, eller körningar av testfall och testsviter. Dessa noder har olika färgfyllningar beroende på dess status. En nod för testfall som har 70% klarade fall kommer att visas som en ruta med 7/10 grönt och 3/10 rött.

(39)

Figur 5.11: En informationsruta öppnas vid klick på en nod.

Vid klick på en nod dyker en informationsruta upp, som är kopplad till noden, se figur 5.11. Rutan innehåller mer detaljerad information, som till exempel antal händelser i noden och mer detaljer om händelsernas eventuella status. Informationsrutan innehåller även en knapp för att öppna den detaljerade vyn för den valda händelsetypen.

Under grafen visas en tidslinje, där det är möjligt att filtrera vilka händelser som visas, se figur 5.7. Användaren kan zooma in i tidslinjen genom att scrolla, och då kommer varje steg i tidslinjen representeras av en mindre enhet tid. Minsta möjliga enhet är 10 minuter. Det finns två flyttbara markörer, en för starttid och en för sluttid. Vid förflyttning av dessa skickas ett anrop till servern som returnerar en ny filtrering av händelser. Markörerna kan maximalt flyttas till de tidpunkter då den första respektive sista händelsen i databasen ägde rum. Användaren kan även välja start och sluttid genom att fylla i boxarna för start och sluttid under tidslinjen.

5.4.2 Detaljerad vy över en händelsetyp

Den detaljerade vyn visar all data för varje händelse. Denna vy har två olika lägen, ett tabel-läge och ett diagramtabel-läge.

(40)

Figur 5.12: Den detaljerade vyns tabelläge.

I tabelläget som öppnas som standard visas varje enskild händelse som en rad i tabellen, se figur 5.12. Tabellen har kolumner som speglar varje händelsetyps datainnehåll, till exempel tidsstämpel eller teststatus. Det är möjligt att sortera tabellen i stigande eller fallande ordning med avseende på valfri data genom att klicka på kolumnens rubrik. Då dyker en symbol upp som visar i vilken ordning det är sorterat. Varje rad innehåller en knapp för att navigera till händelseflödet för den aktuella händelsen.

Figur 5.13: Den detaljerade vyns diagramläge.

Reglaget ovanför tabellen används för att navigera till diagramläget, se figur 5.13. I diagram-läget visas en funktionskurva som visar förändringar över tid hos en viss data i händelse-typen.

(41)

5.4.3 Händelseflöden

Ett händelseflöde representeras av en liknande graf som i aggregeringen. Skillnaden är att denna vy inte är aggregerad, alltså är varje nod en enskild händelse.

Figur 5.14: Ett händelseflöde, med en öppnad informationsruta.

Varje händelseflöde inleds med en kodändring, men då alla kodändringar är länkade till varandra i ett cykliskt beroende kapas länkarna från dessa och skapar sekvenser av de resterande händelserna fram till en förändring av pålitlighetsgrad. En händelse tillhör exakt en sekvens, men kan ha kopplingar till händelser i separata sekvenser. Detta kopplingar är oföljda länkar och representeras i grafen med streckade bågar. Den närmast närliggande sekvensen ritas ut, men dess egna oföljda länkar visas inte. På så sätt innehåller varje hän-delseflöde en eller flera sekvenser, med en kodändring som initiering.

Denna graf visar händelsetyp för varje nod samt eventuell status precis som i den ag-gregerade grafen, men då noderna endast representerar en händelse är de enfärgade. Den händelse som valdes i den detaljerade vyn framhävs i grafen genom att omges av en gul skugga. Även dessa noder är klickbara och visar då en informationsruta, vilket visas i figur 5.14. Rutan innehåller detaljerad data om händelsen, samt en länk till programmet som genererade händelsen.

En händelsetyp som hanteras annorlunda i händelseflöden är testsviter. Sviter innehåller körningar av flera testfall, och körningarna av dessa testfall visualiseras genom att dess händelser visas i den detaljerade vyn.

5.5 Gemensamma erfarenheter

Nedan redogörs för vilka tidigare erfarenheter projekgruppen hade vid projektets start, samt hur gruppen utvecklades till projektets slut.

5.5.1 Tidigare erfarenheter

Den här sektionen presenterar de erfarenheter som projektgruppen hade när projektet bör-jade och de erfarenheter som medlemmarna fått under projekttidens gång. Alla utom en av projektgruppens medlemmar hade genomfört ett projekt av liknande magnitud tidigare. Då detta projekt delar många aspekter med den tidigare projektkursen så kunde många av gruppens medlemmar känna en viss kunskap kring vad som förväntades av projektet. Den

(42)

kunskap som kändes mest relevant var den kring hur mycket dokumentation som krävdes för den här typen av projekt. Att vissa medlemmar visste hur gruppen skulle komma igång med dokumentationen underlättade mycket då det var en del dokumentation i början av projektet.

5.5.2 Nya erfarenheter

De erfarenheter som gruppen har fått i och med detta projekt är främst erfarenheter relaterade till att jobba med andra människor i grupp och gruppdynamik. Andra erfarenheter som erhållits är sådana relaterade till webbprogrammering såsom inom HTML och JavaScript, samt dokumentationsrelaterade såsom LaTeX. Den erfarenhet som gruppen har uppskattat mest är den om hur man jobbar tillsammans i grupp då denna erfarenhet har gett mest värde inför framtida arbeten.

5.6 Överblick över individuella undersökningar

Denna del avser att presentera de individuella fördjupningsområden som gruppens medlem-mar valt att fördjupa sig inom.

• Anpassning av testmetoder för småskalig utveckling av Joakim Argillander • Kodgranskning som en kvalitetsmetod av Victor Bodin

• Användandet av workshops för kompetensutveckling av Sebastian Callh

• Prototypers påverkan på utveckling av användargränssnitt av Rebecca Lindblom • Retrospective - Hur det hjälper team att effektivisera sitt arbete av Johan Nåtoft • Utveckling med Meteor av Johan Thornström

• Hur vi använt de verktyg vi valt för utveckling av mjukvara av Jonathan Wahlund • Val av verktyg vid projektdokumentation av Daniel Wassing