1. No category

Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Visualisering av svarstider mellan mobila
klienter och datacenter
av
Adrian Sidenvall, Andy Truong, Erik Boman, Mikael Szreder,
Oskar Lind, Simon Eriksson, Simon Petersson
LIU-IDA/LITH-EX-G--15/026--SE
2015-06-15
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings universitet
581 83 Linköping
Linköpings universitet
Institutionen för datavetenskap
Examensarbete
Visualisering av svarstider mellan mobila
klienter och datacenter
av
Adrian Sidenvall, Andy Truong, Erik Boman, Mikael Szreder,
Oskar Lind, Simon Eriksson, Simon Petersson
LIU-IDA/LITH-EX-G--15/026--SE
2015-06-15
Handledare: Jonas Lindgren
Examinator: Kristian Sandahl
Sammanfattning
Rapporten är en sammanställning av gruppens samlade erfarenheter
och lärdomar av ett projekt vars syfte var att utveckla ett verktyg
som ska visualisera svarstider mellan mobila klienter och datacenter.
Genom att använda kontinuerlig prototypning har gruppen kunnat arbeta på ett användarnära sätt för att uppfylla kundens verkliga behov.
För att uppnå detta användes utvecklingsmetodiken Kanban. Under
projektets gång anpassades metodiken för att bättre passa in i arbetet.
Projektets användartester har lett till sammanfattande erfarenheter om visualisering av data. Visualiseringar som projektgruppen ansett tydliga uppfattades inte alltid på samma sätt av användarna. Att
visualisera flera parametrar på en världskarta anses vara problematiskt
då kartan i sig endast består av länder. För visualisering av flera parametrar måste då även externa element användas, exempelvis cirklar
eller andra former.
i
Innehåll
I
Gemensamma erfarenheter och diskussioner
1 Inledning
1
2
1.1
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Bakgrund
4
2.1
Kursen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Opera Software . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3 Teori
5
3.1
Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2
D3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.3
SEMAT Alpha Kernel . . . . . . . . . . . . . . . . . . . . . .
6
4 Metod
7
4.1
Dokumentgranskning . . . . . . . . . . . . . . . . . . . . . . .
7
4.2
Kravinhämtning . . . . . . . . . . . . . . . . . . . . . . . . . .
7
4.3
Prototypning . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
4.4
Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.5
Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.5.1
Utvecklingsverktyg . . . . . . . . . . . . . . . . . . . .
8
4.5.2
Dokumentverktyg . . . . . . . . . . . . . . . . . . . . .
9
4.5.3
Planeringsverktyg . . . . . . . . . . . . . . . . . . . . .
9
4.6
Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.7
Forskningsmetod . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7.1
Möten . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ii
4.7.2
Biblioteket . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7.3
Insamling av projekterfarenheter . . . . . . . . . . . . 11
5 Resultat
12
5.1
Fas 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2
Fas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3
Fas 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4
Användartester . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4.1
Användartester . . . . . . . . . . . . . . . . . . . . . . 16
6 Diskussion
6.1
6.2
17
Erfarenheter för förstudie och fas 1 . . . . . . . . . . . . . . . 17
6.1.1
Kravinhämtning . . . . . . . . . . . . . . . . . . . . . . 17
6.1.2
Aktiviteter . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.3
Prototyper . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.4
Mötesanteckningar . . . . . . . . . . . . . . . . . . . . 18
Erfarenheter från fas 2 . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1
Arbeta mer intensivt med Kanban metodiken . . . . . 18
6.2.2
Mötesanteckningar . . . . . . . . . . . . . . . . . . . . 19
6.3
Erfarenheter från fas 3 . . . . . . . . . . . . . . . . . . . . . . 19
6.4
Tekniska erfarenheter . . . . . . . . . . . . . . . . . . . . . . . 20
6.5
6.6
6.4.1
Framtagning av verktyg för kartritande . . . . . . . . . 20
6.4.2
Framtagning av mer detaljerad kartdata . . . . . . . . 20
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.5.1
Visualisering på kartor . . . . . . . . . . . . . . . . . . 21
6.5.2
Visualisering av flera parametrar på en karta . . . . . . 24
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.6.1
6.7
Möten . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Arbeta i ett vidare sammanhang . . . . . . . . . . . . . . . . . 25
6.7.1
Miljöaspekter . . . . . . . . . . . . . . . . . . . . . . . 26
7 Slutsatser
27
iii
II
Individuella delar
29
1 Adrian Sidenvall: Projektledning i ett mjukvaruprojekt där
Kanban-metodiken används
30
1.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.7
1.8
1.9
1.6.1
Stategisk projektledning . . . . . . . . . . . . . . . . . 31
1.6.2
Kanban och Scrum . . . . . . . . . . . . . . . . . . . . 32
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.7.1
Böcker . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.7.2
Projekterfarenheter . . . . . . . . . . . . . . . . . . . . 33
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.8.1
Förstudie . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.8.2
Förberedelser till att använda Kanban . . . . . . . . . 34
1.8.3
Att börja använda Kanban . . . . . . . . . . . . . . . . 35
1.8.4
Vår användning av Kanban . . . . . . . . . . . . . . . 36
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.10.1 Hur Kanban påverkar ett projekt . . . . . . . . . . . . 39
1.10.2 Introduktion av Kanban i ett projekt . . . . . . . . . . 40
1.10.3 Strategisk projektledning . . . . . . . . . . . . . . . . . 41
2 Andy Truong: Dokumenthantering i projekt
43
2.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
iv
2.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.1
Versionshantering . . . . . . . . . . . . . . . . . . . . . 44
2.6.2
Kollaborativ redigering . . . . . . . . . . . . . . . . . . 45
2.6.3
Typsättning . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6.4
Molnbaserad lagring . . . . . . . . . . . . . . . . . . . 47
2.6.5
Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.8
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.9
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3 Erik Boman: Testning och säkerhet vid utvecklandet av en
webbapplikation
56
3.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5
3.4.1
Avgränsningar i rapporten . . . . . . . . . . . . . . . . 57
3.4.2
Avgränsningar vid testning . . . . . . . . . . . . . . . . 57
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5.1
3.6
Webbapplikationer nu och då . . . . . . . . . . . . . . 57
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.6.1
Cross-site scripting . . . . . . . . . . . . . . . . . . . . 58
3.6.2
SQL-injektioner . . . . . . . . . . . . . . . . . . . . . . 58
3.6.3
Brute force . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6.4
Denial of service
. . . . . . . . . . . . . . . . . . . . . 59
3.7
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
v
3.9
3.8.1
Cross-site scripting . . . . . . . . . . . . . . . . . . . . 61
3.8.2
SQL-injektioner . . . . . . . . . . . . . . . . . . . . . . 61
3.8.3
Brute force . . . . . . . . . . . . . . . . . . . . . . . . 62
3.8.4
Denial of service
. . . . . . . . . . . . . . . . . . . . . 63
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4 Mikael Szreder: Kanban som utvecklingsmetodik för mjukvaruprojekt med kontinuerlig prototypning
66
4.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.6
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9
4.8.1
Fas 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.8.2
Fas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.8.3
Fas 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5 Oskar Lind: Kontinuerlig kravinsamling
74
5.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4
Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
vi
5.5
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.1
5.7
TDDD77 - Projektet . . . . . . . . . . . . . . . . . . . 76
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7.1
Kravhanteringsmetoder . . . . . . . . . . . . . . . . . . 76
5.8
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.9
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.9.1
Intervjuer . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.9.2
TDDD77 – kravinsamlingsprocess . . . . . . . . . . . . 78
5.10 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.11 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6 Simon Eriksson: Implementation av interaktiv kartvisualisering med D3
83
6.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.5
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.6
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.7
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.8
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.9
6.8.1
Första fasen med Datamaps . . . . . . . . . . . . . . . 86
6.8.2
Övergripande funktioner . . . . . . . . . . . . . . . . . 86
6.8.3
Världskartan . . . . . . . . . . . . . . . . . . . . . . . 87
6.8.4
Bubblorna . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.8.5
Datacenter . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.8.6
Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8.7
Statistik . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
vii
6.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7 Simon Petersson: Kvalitetssäkring och inspektioner
92
7.1
Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.2
Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.5
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6
Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6.1
Inspektioner . . . . . . . . . . . . . . . . . . . . . . . . 94
7.6.2
Kvalitetsbegrepp . . . . . . . . . . . . . . . . . . . . . 94
7.7
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.8
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.9
7.8.1
Granskning av dokument . . . . . . . . . . . . . . . . . 96
7.8.2
Inspektioner av kod . . . . . . . . . . . . . . . . . . . . 96
7.8.3
Allmänt om kodinspektioner . . . . . . . . . . . . . . . 97
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.9.1
Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.9.2
Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.10 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Referenser
104
viii
Del I
Gemensamma erfarenheter och
diskussioner
1
1
Inledning
Detta dokument behandlar ett projekt i kursen TDDD77: Kandidatprojekt
i programvaruutveckling vid Linköpings universitet. Dokumentet inleds med
de frågeställningar som projektet behandlat samt en beskrivning av de utvecklingsmetoder och utvärderingsmetoder som använts.
Projektet gick i korthet ut på att skriva en applikation för visualisering
av svarstider mellan mobila klienter och datacenter, beroende på datacenters
placering. För att uppnå detta använde sig projektet av utvecklingsmetodiken
Kanban.
1.1
Syfte och mål
Syftet med projektet var att utveckla ett verktyg vars uppgift var att genom
visualisering underlätta och effektivisera placeringen av nya datacenter för
att förbättra svarstider för mobila klienter.
Målet var att kunden, Opera Software, skulle få ett bättre hjälpmedel för
diskussion kring placering av nya datacenter. Då de tidigare använt sig av
kalkylblad var förhoppningen att det nya visuella hjälpmedlet skulle ge en
bättre överblick över hur placeringen av datacenter påverkade deras användare.
1.2
Frågeställning
Här tas frågeställningar upp som besvaras i rapporten.
1. Vilka erfarenheter kan man få av att genomföra ett programmeringsprojekt?
2. Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel
Alphas?
3. Vad finns det för för- och nackdelar med att använda metoden Kanban
i ett programmeringsprojekt?
2
4. Hur kan man visualisera flera olika data för enskilda länder simultant
på en världskarta?
5. Finns det bra verktyg som kan användas för visualisering av data för
olika länder i en webbaserad applikation?
6. Vad kan man stöta på för problem vid hantering av kartdata?
1.3
Avgränsningar
Då projektet hade begränsad tidstillgång har fokus legat på att uppfylla de
primära prioritetskraven, vilket har begränsat mängden uppfyllda sekundära
prioritetskrav.
Projektets huvudsyfte var att applikationen skulle visualisera svarstider
för specifika länder och inte specifika positioner. Applikationen begränsas
även av tillgänglig information och kommer endast använda den vid visualisering.
Programmet hanterar endast de datacenter som kunden tillhandahåller.
Dessa datacenter behöver endast kunna aktiveras och inaktiveras. Den sekundära delen av projektet handlade om automatisk optimering av datacenter.
På grund av tidsbegränsningar och svalt intresse från Opera lades inget arbete på denna del.
Då visualiseringen skulle ske i en webbapplikation fanns det direkt ett
flertal begränsningar på vilka verktyg och tekniska lösningar som kunde användas.
3
2
Bakgrund
Här beskrivs bakgrund om kursen som projektet utfördes i, kunden för projektet och projektmetodiken Kanban.
2.1
Kursen
Detta projekt utfördes som en del i kursen TDDD77: Kandidatprojekt i programvaruutveckling som är kandidatprojektkursen för studenterna som studerar civilingenjör datateknik vid Linköpings universitet. Kursen omfattar
16 högskolepoäng där även kursdelar i entreprenörskap och kommunikation
ingår.
2.2
Opera Software
Kunden för projektet var Opera Software som är ett mjukvaruföretag grundat
i Norge år 1995. Deras huvudsakliga produkt är deras webbläsare, Opera, som
har över 350 miljoner användare. De har kontor på 25 olika platser runt om i
världen och huvudkontor i Oslo. Detta projekt utfördes i kontakt med Operas
kontor i Linköping. [1]
2.3
Kanban
Kanban är från början en del av Toyotas Lean-metodik och utvecklades i
Japan under 1940-talet. Syftet med metoden är att, i de områden där den
tillämpas, öka produktionstakten och minska kostnaden. Ordet Kanban kommer från japanskan och betyder ”visuellt kort”. På Toyota är Kanban det
visuella system med kort eller lappar på tavlor som används för att binda
ihop deras Lean-metodik. [2]
Här beskrivs den projektmetodik som utvecklats utifrån Toyotas idéer
och därifrån fått namnet Kanban. Grunden i den metodiken, eller det processverktyget som det också kan kallas [3], kommer från just de tavlor med
lappar som Toyota kallar Kanban-tavlor.
4
3
Teori
Här nedan beskrivs relevant teori som berör projektets frågeställningar.
3.1
Kanban
I Kanban finns egentligen bara tre principer som ska följas för att man ska
kunna säga att Kanban används.
Den första är just Kanban-tavlan. Tanken är att varje projektgrupp har en
egen tavla där de sätter upp lappar med de olika uppgifter som måste utföras
för att projektet ska bli klart. Tavlan delas upp i olika kolumner och/eller
rader med sin egen titel och/eller prioritet. Lapparna med uppgifter flyter
sedan över denna tavla, från att uppgiften lagts till som något som behöver
göras, till att den är färdigutvecklad. Tavlans utseende, och kolumner och
rader, finns inte definierat i Kanban utan anpassas efter det/de projekt som
den ska användas till. Ett enkelt exempel för hur en Kanban-tavla kan se ut
syns i figur 1 nedan.
Figur 1: Enkelt exempel på en Kanban-tavla med tre flödestillstånd. [4]
Utöver att visualisera arbetsflödet med tavlan så begränsar man antalet
pågående arbetsuppgifter (Works In Progress – WIP) i de olika flödestill5
stånden, detta är den andra Kanban-principen. Projektgruppen bestämmer
då hur många lappar som får finnas i varje kolumn utefter vilket antal som
passar för just det projektet. Kanban säger inget om vilket antal WIP som får
finnas och inte heller om antalet måste begränsas i alla flödestillstånd. Detta
är något som gruppen får komma fram till, och ständigt utveckla, själva för
just deras projekt.
Den tredje och sista principen som ska följas är att lead time ska mätas. Lead time är den tid det tar från att en arbetsuppgift påbörjas, eller
kan påbörjas, tills att den är klar. Alltså den tid det tar från att en uppgiftslapp flyttas in på tavlan, t ex från uppgiftsbanken, backlogen, till att
den har flyttats till de färdiga uppgifterna. Denna tid kan användas för att
utveckla användandet av Kanban vidare. Man vill nämligen få en så kort och
förutsägbar lead time som möjligt. [3]
3.2
D3
JavaScript-biblioteket D3, som står för Data-Driven-Documents, valdes som
grund till visualiseringen i projektet. D3 är ett bibliotek som använder sig av
de standarder som finns implementerade inom moderna webbläsare så som
HTML, CSS och JavaScript. Syftet med D3 är att underlätta skapandet av
datavisualiseringar i webbläsare.
3.3
SEMAT Alpha Kernel
SEMAT Alpha Kernel är ett enkelt sätt för en organisation att utvärdera ett
mjukvaruprojekt nuvarande status. Den kan också underlätta planeringen av
nästa steg i utvecklingen. Alphas representerar nyckelområden för ett projekt
och Alpha States representerar tillståndet inom dessa områden [5].
6
4
Metod
Här beskrivs olika metoder och arbetssätt som använts under projektets gång.
Vissa är verktyg som använts till delar av projektet medan andra beskriver
sätt som vi arbetat på.
4.1
Dokumentgranskning
För att se till att projektets dokument höll en viss kvalitet granskades allt
som skrevs av minst en annan person utöver författaren själv. Detta gjordes
för att minimera antalet mindre fel och för att kunna peka ut brister i texten. Dokument samskrevs i Google Docs och förslagsläget användes för att
den som granskade skulle kunna ge förslag på förbättringar och ändringar.
Dokumentansvarig hade sedan ansvar för att godkänna dessa förslag för att
sedan överföra ändringarna till LATEX för formatering.
4.2
Kravinhämtning
För kravinhämtning har projektgruppen använt sig av möten med kund samt
av ett formulär med frågor som skickades till kunden för evaluering. Formuläret skapades genom att alla gruppmedlemmar skrev frågor och funderingar
som fanns angående projektet. Dessa skrevs sedan rent och formulerades om
till tydliga frågor som kunden sedan besvarade. Till vissa frågor användes en
sifferskala, detta för att ge en bättre bild av hur relevant en viss funktionalitet
var.
4.3
Prototypning
För att få en bättre bild av kundens verkliga behov och vilka krav som sattes så användes kontinuerlig prototypning. Tidigt i projektet användes helt
visuella prototyper utan funktionalitet, dessa gav en enkel bild av hur applikationen skulle kunna se ut. Senare användes dessa prototyper som grund till
7
framtida prototyper. Dessa prototyper utvecklades vidare med utökad funktionalitet genom projektets gång. Varje ny prototyp som fungerade kunde då
fortsätta utvecklas mot den slutliga produkten. Vi presenterade även några
av dessa prototyper för kunden vid möten och antecknade reaktioner och
kommentarer.
4.4
Testning
Under projektet har webbapplikationen testats för att se till att den uppfyller
de krav som gruppen och Opera haft på den. Dessa tester har delvis skett
informellt under tiden som produkten har utvecklats men även mer formella
tester har utförts och finns dokumenterade i testrapporterna. Fokus under
dessa tester låg framförallt på att hitta buggar samt avvikelser i applikationen
mellan olika webbläsare.
I slutet av projektet gjordes även ett antal användartester för att se hur
intuitiv applikationen var. För utförandet av testerna användes en användarberättelse för att sätta in testanvändaren i ett sammanhang inför testningen. De observationer som noterades under användartesterna dokumenterades
med hjälp av ett standardiserat protokoll. Dessa tester gav mycket värdefull
feedback om potentiella framtida förbättringar och funktionaliteter.
4.5
Verktyg
Under projektets gång har gruppen använt sig av ett antal olika verktyg.
Dessa finns beskrivna nedan.
4.5.1
Utvecklingsverktyg
För att underlätta utvecklingsprocessen användes Redmine. Redmine är ett
webbaserat projektverktyg där aktiviteter har hanterats enligt Kanban metodiken. Gruppmedlemmarna har även rapporterat spenderad tid på varje
aktivitet.
8
För att hantera all källkod har versionshanteringssystemet Git använts.
För att få en bättre översikt över utvecklingsprocessen integrerades Git med
Redmine.
4.5.2
Dokumentverktyg
För en stor andel av dokumenten som producerades under projektets gång
användes Google Docs. Detta för att enkelt kunna samskriva gemensamma
dokument. Google Docs har bra funktionalitet för kommentarer och ändringsförslag vilket har använts produktivt i arbetet med kontinuerlig uppdatering
och förbättring av dokumenten. Sedan har LATEX använts för att renskriva alla dokument så att de blivit utseendemässigt korrekta och följt en gemensam
mall.
Google Docs har även använts för att dela med sig av erfarenheter och
information samt för att samla material till presentationer och oppositioner.
4.5.3
Planeringsverktyg
Gruppen har använt sig av tjänsten Doodle för underlätta planeringen av
möten inom projektgruppen. Där har teamledaren planerat möten utifrån
tillgängliga tider och sedan skickat ett formulär till gruppmedlemmarna. Där
har alla gruppmedlemmar kunnat välja individuellt passande tider för mötet.
4.6
Arbetsmetod
I utförandet av projektet så har utvecklingsmetodiken Kanban använts. Från
och med att Kanban infördes fanns en Kanban-tavla tillgänglig på gruppens
Redmine-sida. Där har gruppens utvecklingsledare ansvarat för att lägga till
och flytta runt aktiviteter.
Vi valde att använda arbetsstegen Backlog, To Do, Development, Integration & Testing och Resolved. Dessa blev kolumner på gruppens Kanban-tavla.
Begränsningarna av antalet aktiviteter som fick finnas i de olika kolumnerna
9
sattes initialt till tre, men anpassades under projektets gång med avseende
på arbetsflödet.
Under möten bestämde gruppen vilka aktiviteter som skulle påbörjas,
dessa flyttades då från Backlog till To Do.
Då Kanban saknar specificerade ansvarsposter för exempelvis teamledare
eller testledare så har dessa lagts till utifrån de ansvarsposter som föreslagits
i kursen.
4.7
Forskningsmetod
Nedan följer en beskrivning av metoder som projektgruppen använt sig av
för att samla erfarenheter under projektet gång. Primärt har erfarenheter
erhållits från möten, där protokoll och tankar samlats.
4.7.1
Möten
Under projektets gång har minst ett möte i veckan, ofta fler, hållits med hela
gruppen. Vid vissa av dessa möten har även gruppens handledare närvarat
för att ge gruppen stöd och svara på eventuella frågor. Mötena har använts
både för att samordna och planera arbetet såväl som för att dela med sig
av erfarenheter och diskutera problem och framsteg. Tanken var att alla
gruppmedlemmar skulle komma till tals under möte och därför inledes varje
möte med en statusuppdatering från varje gruppmedlem.
Initialt var tanken att en sekreterare skulle föra mötesprotokoll, vilket
följdes till stor del. Dessa mötesanteckningar kunde sedan användas för att
få en återblick på beslut som tagits under möten samt för att snabbt få en
överblick av vad som sades. Mötesprotokollen samlades på Google Drive för
enkel tillgång.
4.7.2
Biblioteket
Biblioteket på Campus Valla har använts för att få tillgång till böcker och
artiklar på ett smidigt sätt. Där finns en stor samling böcker om både pro-
10
grammering, projektmetodiker och projektledning vilket har varit en värdefull resurs, både för projektet i sig och för skrivandet av denna uppsats.
4.7.3
Insamling av projekterfarenheter
Mallar och riktlinjer för dokumentation av erfarenheter från projektet har
saknats. Dessa erfarenheter har istället främst samlats från kommunikation,
såsom mötesanteckningar och mail. Varje vecka har teamledaren skickat in en
tidrapportering till examinatorn och handledaren där framsteg under gången
vecka, planer för den kommande veckan samt de risker som funnits för tillfället sammanfattades. Dessa rapporteringar har senare kunnat användas för
att se tillbaka på vad som gjorts och, i vissa fall, på de funderingar som tagits
upp. En del individuella anteckningar av erfarenheter har även förekommit.
Insamling av erfarenheter har även gjorts vid de tillfällen då faser av
projektet har utvärderats. I samband med att faser har avslutats har även
erfarenheter från dessa skrivits in i andra dokument, framförallt i denna
uppsats.
11
5
Resultat
Här presenteras resultaten från projektets olika faser. Resultatet är i stort
uppdelat efter de tre faser som projektet genomgått. Men då projektgruppen
använts sig av Kanban har faserna inte varit lika strikta.
Under första fasen lades mycket arbete på prototyper, detta för att kunna
få återkoppling av kunden om vad som önskades samt för att testa flera sätt
att visualisera den givna data. I slutet av första fasen togs den första interaktiva prototypen fram. Under fas 2 fortsatte arbetet med prototypen och
den utvecklades vidare med utökad funktionalitet. Efter fas 2 var bilden över
var kunden önskade tydlig och prototypen övergick till den verkliga produkten. Under fas 3 fortsatte arbetet med utökad funktionalitet och kartdatan
uppdaterades ett flertal gånger. I fas 3 introducerades även en back-end för
hantering av data.
5.1
Fas 1
I fas 1 tog gruppen fram ett flertal enkla prototyper som diskuterades med
kund för att få återkoppling. Denna återkoppling användes sedan för att få
en klarare bild över vad kunden önskade. Detta gav gruppen en bättre bild
över vad som skulle utvecklas, och hur utvecklingen skulle gå till.
Gruppen producerade även en interaktiv prototyp där länder visualiserades med färger utifrån deras svarstid och där landets namn kom upp då man
hade muspekaren över landet. Se figur 2.
Denna prototyp användes sedan för vidare utveckling med utökad funktionalitet som zoomning och möjligheten att aktivera och inaktivera datacenter.
Prototypen gjordes på ett sådant sätt att den med fördel kunde användas för
vidare utveckling under senare faser.
12
Figur 2: Skärmdump av produkten efter fas 1.
5.2
Fas 2
Då gruppen gick ifrån iterationer efter fas 1 för att istället jobba mer emot
Kanban-metodiken behandlar det här avsnittet istället tidsperioden vecka 1316. Under denna period ändrades arbetssättet och användningen av Redmine
mot att mer efterlikna Kanban med en webbaserad Kanban-tavla. Detta
efter att teamledaren, och även arkitekten, läst boken Kanban and Scrum –
Making the most of [3] av Henrik Kniberg och Mattias Skarin. En Kanbantavla skapades och aktiviteter formades mer som Kanban-uppgifter.
Under fas 2 påbörjades en ny prototyp med bubblor efter att kund uttryckt sig positivt om den idén. Sidfältet förbättrades också markant med
en sortering av datacentren efter svarstid. Ny och mer detaljerad kartdata
började också användas. Efter fas 2 såg produkten ut som i figur 3.
13
Figur 3: Skärmdump av produkten efter fas 2.
5.3
Fas 3
Under fas 3 fortsatte arbetet enligt Kanban-metodiken. Kanban-tavlan började användas mer frekvent och antalet WIP justerades ytterligare för att
passa slutfasen av projektet. Även aktiviteter för buggar började skapas för
att rapportera buggar eller felaktig funktionalitet. Dessa aktiviteter innehöll
kommentarer om när buggen uppstod och hur man skulle gå tillväga för att
buggen skulle uppstå, för att förenkla för den person som skulle åtgärda felet.
I vissa fall fanns även en tilldelning till en person som skulle utföra aktiviteten. Detta ledde till att buggar åtgärdades väldigt snabbt och effektivt.
Under fas 3 vidareutvecklades produkten som tagits fram under fas 2. En
sökfunktion lades till i sidfältet och datacentren ritades ut på kartan. Utöver
kartförbättringar skapades även en ny vy för statistikvisualisering med syftet
att ge en bättre överblick över den tillgängliga datan. Utöver detta gjordes
även många visuella förändringar och finjusteringar. Även flaggor för länderna
introducerades under fas 3.
För att förenkla för kunden introducerades även en back-end som tidigare
14
utvecklats men som inte använts. Detta för att konverteringen av data skulle
bli enklare för kunden då back-end hanterar detta. Kartdatan ändrades även
för att större länder som USA skulle gå att dela upp i mindre regioner.
Under fas 3 gick gruppen över till att helt använda D3 istället för ett
det tidigare biblioteket som innehöll vissa begränsningar. Detta då utökad
funktionalitet krävdes utöver det tidigare bibliotekets funktioner. I figur 4
visas resultatet efter fas 3.
Figur 4: Skärmdump av produkten efter fas 3.
15
5.4
Användartester
Här beskrivs de användartester som utfördes med resultaten redovisade.
5.4.1
Användartester
För att testa hur den visualiserade datan tolkades av användare utfördes
tester mot personer med liknande teknisk kompetens som slutanvändaren.
Testet
Testet inleddes med att varje användare fick ett scenario uppläst för sig. Detta
scenario handlade om att användaren hade en viss roll hos kunden och skulle
använda sig av den utvecklade produkten för att göra vissa bedömningar.
Det första steget var att användaren skulle bekanta sig med produkten
och dess olika egenskaper. Steg två handlade om att tolka den visualiserade
datan. Steg tre handlade om att utföra en specifik uppgift med de kunskaper
som testpersonen erhållit från de två första stegen.
Resultatet
Många av de funktioner som för utvecklingsteamet var självklara tog tid för
testpersonerna att förstå. Bland annat var det svårt att förstå skillnaden
mellan färg och storlek på bubblorna. Användarna var osäkra om färgen eller
storleken representerade antalet användare. Det var inte heller helt intuitivt
att använda sidfältet eller att nyttja några av de mer avancerade funktionerna
som fanns tillgängliga. De streck som målats ut för att visa kopplingarna
mellan de olika länderna och de tre bästa datacentrena var också svåra för
användarna att förstå, speciellt när de var långa och delvis ritades utanför
kartan.
16
6
Diskussion
Här tas diskussioner om resultat och erfarenheter från projektets olika faser
upp. Diskussionen är uppdelad i tre delar efter projektets faser och består
av olika delar i projektet, som kravinhämtning, prototyper och möten.
6.1
Erfarenheter för förstudie och fas 1
Fas 1 bestod till stor del av att ta fram prototyper för att få en tydligare
bild av kundens behov. Då kunden från början inte hade en klar bild av den
slutgiltiga produkten ledde detta till mycket prototyparbete. Denna process
gav gruppen många erfarenheter inom prototypning och kravinhämtning.
6.1.1
Kravinhämtning
Projektet var från början otydligt definierat och kunden gav projektgruppen
fria händer över produktens utformning. Det fanns endast ett fåtal funktionella krav som kunden önskade, vilket ledde till ett intensivt arbete inom
gruppen för att ta fram krav och diskutera fram en kravspecifikation tillsammans med kund. Då det tog tid innan kraven specificerades ledde detta till
att gruppen till en början kände att det var svårt att påbörja utvecklingsarbetet. Gruppen ville nämligen inte påbörja arbetet på något som sedan
skulle visa sig inte behövas. I slutändan var det ändå bra att få erfarenhet
av hur en kravinhämtning där kunden inte vet vad den behöver.
6.1.2
Aktiviteter
Då det till en början fanns många oklarheter i projektet var det svårt att
planera aktiviteter. Detta ledde i sin tur till att det i förstudien och delar
av första fasen var svårt att arbeta effektivt i gruppen. Detta löstes genom
mycket enskilt arbete i gruppen vilket fungerade bra men kunde lösts bättre
med ett annat upplägg än det som var definierat i kursen. Något som var svårt
i det enskilda arbetet var att jämnt fördela arbetet över gruppmedlemmarna.
17
6.1.3
Prototyper
Tidigt i kursen valde gruppen att fokusera på ett par prototyper utifrån de
idéer och tankar som uppkommit under förstudien. Prototyperna demonstrerades sedan till kund för återkoppling och eventuella förbättringar. Dessa
prototyper fungerade bra och gav bra respons från kunden. Det gruppen tar
med sig till framtida projekt är att det är betydligt lättare att visa konkreta
idéer för kund och observera kundens reaktioner än att bara diskutera tankar
med kunden. Då gruppen sedan övergick till första fasen kunde prototyperna
direkt användas som en bas för vidareutveckling.
6.1.4
Mötesanteckningar
Gruppen valde tidigt en sekreterare som ansvarade för att skriva mötesprotokoll på handledarmöten och gruppmöten. Dessa mötesprotokoll har varit
uppskattade och har möjliggjort att snabbt och enkelt gå tillbaka och se
vad som bestämdes på ett visst möte, exempelvis vid eventuella konflikter.
Dessutom fungerade dessa utmärkt för att frånvarande personer skulle få en
överblick av vad som tagits upp på mötet.
6.2
Erfarenheter från fas 2
Fas 2 sträckte sig från och med vecka 13 till och med vecka 16.
6.2.1
Arbeta mer intensivt med Kanban metodiken
Under fas 2 satte teamledaren in sig bättre i utvecklingsmetodiken Kanban
och planerade upp arbetet efter metodiken för att uppnå ett bättre arbetssätt. Från början hade gruppen lite svårt att komma på aktiviteter och även
minimera pågående arbete. Men i det stora hela gick gruppen mer in i Kanbans sätt att tänka och kunde på detta sätt använda metodiken på ett effektivare sätt under fortsättningen av projektet.
Det märktes att det krävdes en del tid att komma in i Kanban-tänket, speciellt då majoriteten av gruppen inte använt metoden tidigare. Att gruppen
18
inte hade ett eget kontor gjorde inte saken lättare då Kanban centraliseras
kring visuella hjälpmedel, med Kanban-tavlan i spetsen. Det skulle även ha
varit lättare att ha fler korta spontana möten om gruppen haft en gemensam
samlingsplats som ett eget kontor. Gruppen minskade detta problem genom
att ofta sitta flera stycken tillsammans på CreActive som är en mötesplats
för samverkan mellan studenter och näringslivet, men gruppen saknade möjligheten att ha tillfällen med obligatorisk närvaro då gruppmedlemmar haft
andra viktiga saker att göra.
6.2.2
Mötesanteckningar
Under denna fas ändrades de handledarmöten som gruppen haft till gruppmöten där handledaren fanns närvarande för att kunna lägga in synpunkter
samt kunna rådfrågas. Då både gruppmöten och handledarmöten nu skedde
på samma sätt, med enda skillnaden om en handledare var närvarande eller
inte, var det svårt att separera de två mötestyperna. Då gruppen från början
valde att producera två typer av protokoll för de två mötestyperna var de
anpassade för det specifika möten, vilket bidrog till att gruppen inte var lika
noggrann med att skriva mötesprotokoll.
Gruppen ansåg dock att det fortfarande gick bra att planera och hålla
koll på alla delar i projektet, men protokollen skulle ändå ha varit bra att ha.
Därför återupptogs mötesanteckningarna mot slutet av fasen, med mallen för
gruppmöten.
6.3
Erfarenheter från fas 3
Fas 3 sträckte sig från och med vecka 17 till och med vecka 20.
Under fas 3 arbetade gruppen vidare med och utvecklade användandet
av Kanban. Detta gav djupare kunskap om hur Kanban fungerar. En annan
erfarenhet som gruppen tar med sig är från de användartester som gjordes
under denna fas. Gruppen blev förvånad över att de användare som produkten testades på hade svårt att förstå vad vissa visualiseringar betydde. Denna
kunskap kommer vara till stor nytta av i framtida projekt.
19
6.4
Tekniska erfarenheter
Detta stycke behandlar de tekniska utmaningar som gruppen mött under sitt
arbete samt vilka erfarenheter som utvecklats för att möta dessa.
6.4.1
Framtagning av verktyg för kartritande
När vi började undersöka hur produkten skulle utvecklas tänkte vi först använda kartdata från OpenStreetMap. OpenStreetMap är ett projekt som har
framtagit öppen geografisk data för kartor till öppna så som kommersiella
syften.
Problemet med att använda kartdata från OpenStreetMap är att det inte
fanns något enkelt sätt att få ut konturerna på alla länder. Detta fick oss
att leta efter andra alternativ. Efter ett tag hittades ett färdigt bibliotek
kallat Datamaps. Datamaps baseras på D3 och använder SVG-element för
att rita upp en interaktiv karta i en webbläsare. Efter att ha vägt för- och
nackdelar med OpenStreetMap kontra Datamaps bestämde vi oss för att
använda Datamaps eftersom att det uppfyllde kriteriet med att få ut konturer
på länder.
6.4.2
Framtagning av mer detaljerad kartdata
Gruppen upptäckte under fas 2 att kartdatan som användes till systemet för
att visualisera alla länder inte var tillräckligt noggrann för kundens data.
Bland annat så saknades det en stor mängd mindre länder och öar. För
att lösa detta problem så påbörjades ett arbete för att skaffa mer noggrann
kartdata.
Då ingen i gruppen arbetat med kartdata förut så blev det en lärandeprocess och gruppen fick göra flera försök innan tillräckligt noggrann kartdata
erhölls.
Ett av de största problemen gruppen kämpade med var att hitta kartdata
där alla länder ingick. En enkel kontroll som användes för att bedöma om
kartdata var tillräckligt noggrann var att kontrollera att Franska Guyana var
20
ett separat land från Frankrike och att Monaco fanns som ett eget land. Detta
krav var svårare att uppfylla än förväntat, då problem uppstod med att till
exempelvis länder som Storbritannien blev uppdelade i dess riksdelar. Problemet med detta var att kunden hade data för att visualisera Storbritannien
och inte dess riksdelar.
Detta ledde till att gruppen bestämde sig för att manuellt konstruera
kartdata till en världskarta som var anpassad efter kundens data. För att lösa
detta var gruppen tvungen att skriva skript som använde sig av hårdkodade
listor av regioner som skulle grupperas ihop med deras administrativa länder.
För att få fram den slutgiltiga versionen av kartdatan så behövde gruppen för
hand gå igenom varje datapunkt som skulle visualiseras och se till att länder
stämde överens och att de var rätt placerade. Anledningen till varför länder
ibland inte blev rätt placerade berodde på på att vissa öar som tillhörde
länderna tog över som huvudland. Den enda lösningen till detta problem var
att för hand hitta dessa felaktiga länder och lägga in dem till den hårdkodade
listan av länder som skulle grupperas.
6.5
Resultat
Nedan följer en diskussion av resultaten. Här förs diskussion kring visualisering kopplat till frågeställningen om att simultant visualisera flera dataparametrar på en världskarta.
6.5.1
Visualisering på kartor
Då projekts huvudsyfte var att producera ett verktyg för att kunna visualisera svarstider och användare fanns två parametrar att hantera vid visualiseringen. Kunden ville att svarstiden skulle representeras med en färgskala och
att mängden användare även skulle kunna gå att observera på världskartan.
Den första tanken som kom upp var att färga länder efter en färgskala beroende på svarstiden men problemet var då att visualisera antalet användare.
21
Figur 5: Prototyp för visualisering av svarstider med färgskala för länder.
Detta medförde att flera principer för visualisering av användarantal diskuterades. Ett förslag som kom upp tidigt var att ge varje land en bubbla,
där storleken berodde på antalet användare och färgen berodde på landets
svarstid, se figur 6. Efter att ha visat kunden en prototyp med bubblor var
kunden positiv inställd till idén och gruppen valde att fortsätta arbeta på
den prototypen.
22
Figur 6: Prototyp för visualisering av svarstider med färgskala för länder.
Andra visualiseringsmetoder
Det diskuterades och utfördes även några tester på om konturlinjer skulle
kunna användas för att, på samma sätt som en orienteringskarta visar höjdskillnader, kunna visualisera mängden användare. Problemet med lösningen
var att det inte var uppenbart vad konturerna visualiserade, samt att fördelningen av mängden användare för varje land var okänd vilket försämrade hur
visualiseringen skulle ha sett ut.
Det fanns även flera andra lösningar som diskuterades, såsom att skapa
tredimensionella staplar för visualisering av användarantal. Hela landet skulle
då alltså ses som en stapel och bli högre om landet hade många användare.
Denna idé testades aldrig utan slopades tidigt då gruppen inte trodde att
resultatet skulle bli bättre än det med bubblor. Det skulle även ha varit svårt
att utveckla, vilket gjorde att gruppen inte ville lägga tid på en prototyp.
En svårighet med idén skulle även vara prestandaproblem. På samma sätt
slopades flera andra idéer tidigt i processen för att ge mer tid åt idéer med
mer potential.
23
Figur 7: Tidig prototyp på visualisering av användare med konturlinjer.
6.5.2
Visualisering av flera parametrar på en karta
Att simultant visualisera flera dataparametrar på enbart en världskarta är
svårt. Kartan i sig består bara av länder, vilka är svåra att modifiera för att
visualisera mer än en parameter. Att visualisera en parameter, t ex genom att
ändra färger på länder beroende på data, är enkelt, men att visualisera två
eller fler parametrar samtidigt är svårare. Man skulle kunna ändra storleken
eller formen på ett land, men detta är ingen bra lösning då det lätt kan
förvirra användaren.
För att lösa visualiseringen av två eller flera data simultant måste externa
element användas. Det kan vara enkla symboler, som kvadrater, bubblor,
linjer eller mer avancerade symboler som ikoner för specifika ändamål. Dessa
element bidrar till att kunna visualisera flera parametrar simultant. Precis
som tidigare nämnts använder slutprodukten sig av en bubbla för varje land,
för att med storleken visa mängden användare och med färgen visa svarstiden.
Man kan även tänka sig att använda kanten på bubblan för att visualisera
ytterligare saker, exempelvis en förändring av svarstider.
24
6.6
Metod
Nedan utvärderas metoder som användes under projektet. Här ger gruppen
sina synpunkter på hur metoderna har fungerat och vad som skulle kunnat
gjorts bättre.
6.6.1
Möten
Hur möten har strukturerats har varierat lite under projektet, vilket beskrivs
mer under resultat. Under förstudie och fas 1 var handledarmötena centrala,
då handledarens stöd behövdes mycket. Detta eftersom gruppen inte visste
mycket om projektet ur varken kund- eller kurssynpunkt. Från och med fas
2 var behovet av handledarmöten inte lika stort längre och handledarmötena
blev till gruppmöten med handledaren närvarande.
Gruppen skrev tidigt i projektet mötesprotokoll. Mötena hölls ganska
öppna och var anpassningsbara vid ändringar beroende på vad som var viktigt vid just det mötet. Detta har varit på både gott och ont då det har varit
tillåtet att snabbt kunna ta upp vad som var viktigt vid just det mötet. Ordentliga protokoll hade dock kunnat bidra till mer seriösa samt strukturerade
möten där uppmärksamheten till mötet kunde varit bättre.
I Kanban finns det inget specificerat angående möten, men gruppens lösning med statsuppdateringar under mötet har fungerat mycket bra och ledde
ofta till bra diskussioner.
6.7
Arbeta i ett vidare sammanhang
Att gå vidare med samma projektgrupp skulle kunna innebära att gruppen
arbetar vidare med samma produkt och utvecklar den med utökad funktionalitet. I gruppens fall skulle detta kunna ske genom att kunden anställer
gruppmedlemmarna för att integrera produkten på deras server tillsammans
med deras databas. Detta skulle kunna förbättra och ge aktuell data till verktyget. I övriga aspekter är det beställda verktyget färdigutvecklat. Det går
alltid att förbättra saker och lägga till mer funktionalitet, men i det stora
25
hela anser gruppen att produkten är klar.
Ett annat sätt att arbeta vidare skulle kunna vara att gruppen går vidare och arbetar med ett annat projekt. Detta skulle innebära ett intressant
perspektiv då gruppen har börjat lära känna varandra bättre och vet hur
gruppmedlemmarna brukar arbeta, vilket borde förenkla arbetet i ett framtida projekt.
Inom detta projekt har gruppen haft en kund som givit gruppen mycket
frihet med vad som ska produceras och gruppen har själva ansvarat för mycket av arbetet med vad som ska tas fram och vilka krav som ska sättas. I ett
framtida projekt med en annan kund skulle det kunna vara så att denne är
mer strikt och har tydligare krav på vad som ska göras och hur det ska göras,
vilket gruppen inte blivit vana med under det här projektet. I stort har gruppen fått många erfarenheter i detta projekt som kommer vara applicerbara
även i framtida projekt.
Ytterligare erfarenheter som kan nämnas är att projektgruppen har arbetat inom en specifik metodik som utvidgats för att passa just detta projekt.
Detta har givit bra erfarenheter som skulle kunna vara applicerbara även till
andra projekt.
De roller som gruppen har använt under projektet är något som skulle
kunna användas i ett vidare sammanhang. Gruppens medlemmar har med
tiden lärt sig sin roll dess ansvarsområden, vilket kan vara bra i andra projekt
om man får samma roll.
6.7.1
Miljöaspekter
Produktens syfte är att effektivisera utplaceringen av datacenter för att optimera svarstiden för användare. Detta kommer att implicit bidra till att
mängden datacenter och deras placering optimeras vilket ger positiva miljöaspekter då överflödiga datacenter elimineras.
26
7
Slutsatser
För att dra en sammanfattande slutsats av projektet och dess frågeställningar kan visualiseringen nämnas som den stora erfarenheten som gruppen
kommer att ta med sig tillsammans med arbetssättet Kanban och hur det
kan användas för att planera och utföra arbetet.
Efter genomförandet av projektet har projektets medlemmar erhållit stora
erfarenheter inom webbutveckling med dess programspråk och vilka problem
som ofta uppstår hos denna utvecklingsplattform. Många av gruppens medlemmar hade inga tidigare erfarenheter av de programspråk som användes,
detta ledde till att det blev olika inlärningskurvor för medlemmarna.
Den stora delen i projektet har varit att arbeta enligt utvecklingsmetodiken Kanban. Här har gruppen själva utvecklat metoden för att passa detta
projekt och med tiden utvecklat gränser för antalet aktiviteter för olika kategorier i aktivitetsstegen, vilket har varit en bra erfarenhet. De projektroller
som använts inom projektet har i vissa fall fungerat olika bra. För att göra
arbetsgången bättre hade till exempel en kombination av Kanban och någon
annan agil utvecklingsmetodik fungerat bättre.
Då produkten som utvecklas var en webbapplikation för visualisering har
gruppen erhållit stora erfarenheter inom visualisering och metoder som kan
användas för att visualisera data och hur användaren uppfattar det som visualiseras. Gruppen märkte exempelvis att lösningar som internt inom gruppen
tycktes var tydliga inte uppfattades på samma sätt av de testpersoner som
testade produkten. Det tydligaste exemplet på detta var att de linjer som
användes för att visualisera kopplingen mellan de tre bästa datacentren och
ett land vid markering där testpersonerna hade svårt att uppfatta vad som
menades. Se figur 8.
Då länder har olika beteckningar beroende på vilken standard som använts har vissa problem uppstått när gruppen bytt mellan standarder allt
eftersom i projektet. Detta skapade vissa problem och kunde ha diskuterats
mer noggrant tidigt för att undvika problem i slutet.
27
Figur 8: Visualisering av ett lands tre bästa datacenter med linjer.
SEMAT Alpha-korten har varit något som gruppen inte använt sig av
tidigare. Detta har medfört att korten kommit i skymundan och inte använts
till dess fulla potential. Gruppen har kommit fram till slutsatsen att korten
inte är något att föredra i ett mindre projekt av denna typ.
28
Del II
Individuella delar
29
1
Adrian Sidenvall: Projektledning i ett mjukvaruprojekt där Kanban-metodiken används
1.1
Inledning
I den här delen kommer projektledning undersökas djupare. Då vårt projekt
använder metodiken Kanban kommer projektledning i just sådana projekt
vara i fokus. Både erfarenheter från vårt projekt och mer generell teori om
projektledning kommer att tas upp.
1.2
Syfte och mål
Syftet med denna undersökning är att få en djupare kunskap om projektledning samt att samla de erfarenheter om detta som insamlats under projektet.
Tanken är att detta ska kunna hjälpa mig att vara en bättre teamledare i
detta projekt såväl som eventuella framtida projekt.
1.3
Frågeställning
1. Hur påverkar användning av Kanban ett projekt?
2. Vad är det viktigt att tänka på då Kanban introduceras i ett projekt,
som teamledare?
3. Vad innebär strategisk projektledning?
1.4
Avgränsningar
Då detta projekt har utförts på ganska kort tid, med begränsade resurser
och med ganska lite förkunskaper, har användningen och utvecklingen av
Kanban varit begränsad. Detta begränsar då även utvärderingen av Kanban
i sin helhet då vi inte kunnat använda det fullt ut.
30
1.5
Bakgrund
En bakgrund om Kanban återfinns i huvuddelen av denna uppsats i avsnitt 2.3.
1.6
Teori
Här sammanfattats teori från källor som använts till denna del av uppsatsen.
1.6.1
Stategisk projektledning
I boken Strategic Project Management Made Simple [6] beskriver Terry Schmidt strategisk projektledning. Där ser man projekt i ett bredare perspektiv
än i den mer traditionella taktiska projektledningen. Istället för att fokusera
på uppgifter som behöver utföras i projektet ser man mer på helheten och de
behov som finns. Centralt i boken finns fyra frågor som varje projektgrupp
bör försöka svara på.
• Vad försöker vi uppnå och varför?
• Hur kommer vi mäta projektets framgång?
• Vilka externa förutsättningar måste existera för projektet?
• Hur ska vi nå målet?
Dessa frågor måste, enligt Schmidt, ställas i just den ordningen, och svaren
kan utvecklas under projektets gång.
För att hjälpa läsaren att kunna använda dessa frågor finns ett kapitel
för varje fråga. Där går författaren in mer på djupet om vad man ska tänka
på vid diskussion kring varje fråga, vad som är viktigt m.m. Detta bildar en
av tre delar av boken. De andra två delarna beskriver strategisk projektledning mer generellt och vilka verktyg man kan använda respektive hur man
applicerar strategisk projektledning och vad som är viktigt att tänka på som
projektledare. Även mer detaljerade saker, såsom en lista över bra verb att
använda vid kommunikation med gruppen kring projektmål, finns.
31
1.6.2
Kanban och Scrum
Boken Kanban and Scrum - Making the most of both [3] av Henrik Kniberg
och Mattias Skarin handlar som titeln antyder om Kanban och Scrum. Båda
dessa är agila projektmetodiker och de har många likheter. Boken tar i sin
första del, skriven av Kniberg, upp grunderna för båda metodiker och hur
de bör användas. Även viss jämförelse mellan de båda metodikerna tas upp.
I bokens andra del, som Skarin skrivit, finns en case-studie som behandlar
introduceringen av Kanban i en projektgrupp på ett större företag. Dessa
två delar ger tillsammans en väldigt bra bild av hur både Kanban och Scrum
fungerar, och hur man kan gå tillväga för att introducera någon av metodikerna i en projektgrupp. Något som boken trycker mycket på är att ingen
av dessa metodiker är ett komplett regelverk, det är endast grunder eller
verktyg för hur man kan jobba i ett projekt. Man kan alltså inte bara läsa
hur metodikerna fungerar och följa en punktlista, man måste själv utveckla
metodiken för just sitt projekt. Detta ställer en del krav på projektgruppen.
Tanken är dock inte att man ska behöva vara expert på metodiken för att
kunna använda den, det finns många hjälpmedel för att på ett enkelt, och
ofta ganska självklart, sätt utveckla sin process.
1.7
Metod
Insamling av kunskap för den här delen av uppsatsen har skett på två huvudsakliga sätt. Dels genom att läsa böcker i ämnet och dels genom insamling av
erfarenheter från projektet som utförts. Ingen tydligt specificerad metod har
använts vid insamlingen av denna kunskap utan metoden har anpassats efter
situation. Här kommer dock beskrivas mer övergripande hur insamlandet har
gått till.
1.7.1
Böcker
För att hitta givande böcker att läsa har Google-sökningar använts flitigt.
Genom att undersöka vilka författare som är framstående inom de intressanta
32
områdena och sedan undersökning av vilka av deras böcker som var mest
intressanta för just detta projekt har bra val av böcker kunnat göras. Val har
även till viss del begränsats av tillgängligheten av böckerna och till denna
del har alla böcker kunnat lånas från Vallabiblioteket.
För att sedan få ut så mycket som möjligt från böckerna har de kunskaper
som de har givit använts i projektet så snart som möjligt. De huvudområden
som böckerna har behandlat är projektmetoden Kanban och projektledning.
För mig har båda dessa områden varit direkt applicerbara i projektet och
många av de saker som böckerna beskrivit har varit mycket användbara. För
att komma ihåg att använda de metoder som böckerna beskrivit har ofta minnesanteckningar använts. Dessa har ibland även varit korta handledningar,
hämtade från böckerna, om hur metoderna bör användas.
1.7.2
Projekterfarenheter
En viktig grund för det som skrivs i denna del är erfarenheter från projektet
i stort och även erfarenheter för mig som teamledare speciellt. Hur dessa
erfarenheter har samlats in och utvärderats har dock varierat kraftigt. I vissa
fall har reaktioner från gruppen av hur något fungerar antecknats. Ibland
har erfarenheter direkt kunnat skrivas in i denna uppsats. Som nämnts i
metodavsnittet i huvuddelen av uppsatsen har erfarenheter även samlats och
utvärderats i tidrapportering och utvärderingar av faser i projektet.
1.8
Resultat
I det här avsnittet läggs vårt arbete under projektet genom dess olika faser
fram, sett från min synvinkel som teamledare.
1.8.1
Förstudie
Under projektets förstudie så hade vi ännu inte börjat arbeta efter någon
projektmetodik, att undersöka vilken metodik vi skulle välja var en del av
arbetet under den fasen. På grund av detta hade vi inte så mycket struktur
33
i vårt arbete till en början. För att vårt arbete, och samarbete, ändå skulle
fungera och flyta på bra krävdes en mer flexibel typ av projektledning än
vanligt. Gruppen och arbetet behövde få någon form av struktur, trots att
avsaknaden av metodik och oklarheten i projektet gav en brist på just det.
I förstudien skrevs mycket dokument. Avtal med kunden skrevs på och
projektmetodik samt mjukvara till denna valdes. Som teamledare låg mitt
ansvar främst på att se till att alla i gruppen hade något att göra och att
samarbetet i gruppen fungerade bra, men även mycket på kontakten med
kunden.
Vi bestämde roller i gruppen tidigt och detta gav en bra grund i vem
som hade ansvar för vilket dokument. Det fanns dock många oklarheter i vad
som skulle skrivas i vilket dokument och det behövdes en hel del samordning
för att vi skulle få en bra samling dokument utan så många upprepningar
eller felaktigt placerad information. Som teamledare fick jag även ansvar för
projektplanen, som jag skrev i samarbete med resten av gruppen.
Det blev en hel del kontakt med kunden under förstudien då det var en del
krångel med avtalet och även för att projektet var otydligt definierat. Denna
kontakt sköttes av mig och analysansvarige, Oskar Lind. Som teamledare var
det jag som hade ansvar för avtalet och det var även jag som planerade möten
med kunden och skötte den mesta kontakten med dem, med undantag för
ren kravanalys vilket sköttes av Oskar.
1.8.2
Förberedelser till att använda Kanban
Processen med att börja anpassa vårt arbete efter Kanban var ganska utdragen. Vi bestämde tidigt, ca 3 veckor in i projektet, att vi skulle använda oss
av Kanban men det tog många veckor innan vi verkligen började göra det.
Till en början, efter att vi bestämt att Kanban skulle användas, så gjorde
vi väldigt lite för att anpassa oss till Kanban, mest för att vi inte visste så
mycket om det.
Vi började dock läsa på lite smått om Kanban och diskuterade det en
del på möten. Vi kom då fram till att vi behövde något datorbaserat verktyg
34
där vår Kanban-tavla kunde finnas. Man bör förstås ha en riktig tavla som
gruppen kan samlas kring för diskussioner och möten men då vi saknade
ett eget rum kunde vi inte ha någon sådan. Efter en del undersökning av
alternativ började vi använda Redmine där man kan ha ett tillägg för agila
projekt med en tavla som kan användas som Kanban-tavla.
Vi försökte även planera aktiviteter på ett sådant sätt att de skulle kunna
göras till aktivitetslappar då vår Kanban-tavla tagit form. Detta försvårades
precis som mycket annat av att vi inte riktigt visste vad vi skulle utveckla, på
grund av otydligheterna från kunden. Dock gjorde inte det så mycket eftersom
att Kanban är en agil metod och inte kräver en komplett aktivitetslista från
början, fler aktiviteter kunde läggas till efterhand.
1.8.3
Att börja använda Kanban
Innan vi verkligen började använda Kanban läste jag boken Kanban and
Scrum - Making the most of both [3] av Henrik Kniberg och Mattias Skarin.
Det behövdes för att jag skulle ha den kunskap om Kanban som krävdes för
att jag skulle kunna bidra till att få gruppen att använda det på rätt sätt.
Efter att ha läst i den boken omformade jag den Kanban-tavla som vi skapat på Redmine så att den verkligen blev en Kanban-tavla, anpassad efter
vårt projekt. De flödestillstånd jag skapade då var: Backlog, To Do, Development, Integration & Testing och Resolved. Vi började då med begränsningar
på 3 Works In Progress (WIP) på To Do, Development och I&T, egentligen
bara för att ha någon begränsning att börja med. Backlog höll vi utan begränsning då det bara var en kolumn där vi lade uppgifter som vi trodde
skulle behöva utföras någon gång under projektet, den var inte heller med i
flödet då uppgifterna där inte arbetades på.
Tanken var att Backlog skulle vara sorterad, med uppgifter av högre prioritet längst upp. På möten skulle vi då kunna flytta in uppgifter från toppen
av Backlog till To Do så att de skulle finnas tillgängliga för gruppmedlemmar
att börja jobba på. Uppgifter i Backlog var annars låsta där så att de endast
kunde flyttas av administratörer, tanken var att de endast skulle flyttas in
35
till To Do på möten. När uppgifter flyttats till To Do skulle de även där vara
sorterade efter prioritet.
Denna information om hur jag tänkt att vi skulle använda vår Kanbantavla kommunicerade jag först till gruppen via mail då vi just då inte kunde
ha möte på över en vecka. Det var dock en period då gruppen hade mycket
annat att göra utanför projektet och Kanban-tavlan började inte användas
ordentligt förrän efter ett möte då vi kunde diskutera den mer. Då började
vårt arbete till slut likna Kanban.
1.8.4
Vår användning av Kanban
När Kanban väl hade börjat användas ordentligt betydde det inte att allt
arbete kring projektmetodik var klart, istället flyttades fokus till att förbättra
snarare än implementera metodiken. Kanban är uppbyggt på ett sådant sätt
att processen hela tiden ska utvecklas och anpassas bättre för projektet.
Från att Kanban introducerats ordentligt i gruppen användes det kontinuerligt genom resten av projektet. De saker som gjorde att det märktes
tydligast att vi använde Kanban var Kanban-tavlan på Redmine och hur vi
jobbade med denna på möten. Vid mötena kunde vi ha Kanban-tavlan framme på en datorskärm eller projektor och utifrån den diskutera läget. Det
kunde handla om ifall någon aktivitet på tavlan skulle flyttas fram då den
var klar i den kolumn den låg i eller att någon ny aktivitet skulle flyttas in
eller läggas till.
Hur många WIP som var tillåtna i varje kolumn ökades efterhand då
det märktes att den ursprungliga gränsen på 3 var väldigt låg. Tanken med
den låga gränsen var att få medlemmar att samarbeta mer och att alla bara
skulle fokusera på en aktivitet i taget. Då detta inte fungerade bra ökades
gränserna för att inte skapa flaskhalsar i arbetsflödet.
1.9
Diskussion
I det här avsnittet diskuteras resultatet och erfarenheter tas upp.
36
1.9.1
Resultat
Det finns mycket som kan diskuteras om hur vi använde oss av Kanban och
hur jag jobbade som teamledare. Här tas en del av detta upp. Jag har delat
upp detta i två delar för att först diskutera tiden innan vi började använda
Kanban och sedan hur vi använde Kanban.
Förstudie
Till en början visste vi väldigt lite om projektet, vilket gjorde planering
svårt. Så istället för att lägga en bra plan för resten av projektet bestod
vår förstudie till stor del av att skapa en tydlig bild av vad vårt projekt
egentligen bestod av. Kontakten med kunden fungerade ändå bra och mot
förstudiens slut började det kännas som att vi hade bra koll på projektet så
att vi åtminstone kunde börja göra prototyper.
För mig, som teamledare, så innebar den bristande informationen vi hade
om projektet stora svårigheter i att planera vårt projekt. Det tog lång tid
innan vi kunde göra en aktivitetslista för utvecklingen av programmet, så
gruppen blev snart rastlös och trött på att bara jobba med dokument. Något
som man hade kunnat tänka sig var att fler gruppmedlemmar skulle vara med
i kontakten med kunden för att kunna jobba fram specifikationer för projektet
snabbare. Detta var dock något som vi snabbt insåg att inte skulle hjälpa,
utan vi höll oss till att bara jag och Oskar höll den kontakten. Detta eftersom
att vi nästan enbart jobbade mot en enskild kontaktperson på Opera och
det bara skulle bli överväldigande och förvirrande för honom om han skulle
behöva ha kontakt med många olika gruppmedlemmar. Det skulle antagligen
bara ha bidragit till en sämre relation med kunden.
Något som jag kan se i efterhand att jag hade kunnat göra bättre är att jag
borde ha lagt mer fokus på att undersöka projektmetodik under förstudien.
Det hade varit bra om vi hade kommit igång med att följa en metodik tidigare
så att vi hade fått mer tid till att lära oss den och använda den mer effektivt.
Valet av Kanban var ändå bra och arbetet fungerade bra under merparten
av den tid som Kanban användes. Jag tror dock att jag kunde ha bidragit
37
mer till användandet av metodiken, och varit en bättre teamledare, om jag
hade läst på mer tidigare.
Kanban
Då jag själv aldrig hade jobbat med Kanban tidigare och inte heller visste
speciellt mycket om metoden var det mycket viktigt att jag läste boken om
Kanban [3] som nämnts tidigare. Som teamledare var det nödvändigt att jag
hade den kunskap som boken gav, då det var jag som styrde arbetet med
Kanban. Vi hade inte tid till att alla gruppmedlemmar skulle läsa på mycket
om Kanban utan istället fick jag förmedla det jag lärt mig, tillsammans med
hur jag tänkt att det skulle appliceras i vårt projekt.
Det var viktigt att skapa en positiv bild av Kanban inom gruppen för att
alla skulle vilja jobba efter metodiken. Visst motstånd fanns mot Kanban
från början då det kunde upplevas som att det krävdes en del onödigt jobb
bara för att följa metodiken. Efterhand tror jag dock att alla i gruppen insåg
att det inte var alls mycket jobb och att det lilla som behövde göras bidrog
till att gruppen kunde jobba mer effektivt.
Jag skulle själv inte säga att vi använde Kanban fullt ut i projektet.
Exempelvis så mätte vi aldrig lead time ordentligt som man ska göra i Kanban [3]. Detta berodde på flera saker. Främst skulle jag säga att det berodde
på att Kanban användes ganska kort tid och det då inte fanns tid att lära
sig det ordentligt. Det kändes inte heller som att det skulle ge så mycket för
vårt projekt att lära oss om och utveckla Kanban fullt ut. Att vi inte visste
så mycket om Kanban från början var förstås även det en bidragande faktor.
Efter detta projekt skulle jag dock säga att jag lärt mig väldigt mycket
om Kanban och hur det kan användas. Det kan definitivt användas i framtida
projekt, och jag hoppas att jag får chansen att göra det. Jag har själv upplevt
Kanban som en väldigt bra grundmetodik och jag har tyckt att det har varit
kul att jobba med det. Det är dock viktigt att tänka på att Kanban bara är en
bas att utgå från och inte en komplett metodik. Detta är dock något som jag
upplever som något positivt med metodiken då inte alla projekt är likadana
38
och det då är dumt att behandla dem så. Varje projekt som man jobbar med
Kanban ger också mycket erfarenhet och jag tror att om man jobbar med
det i flera projekt så kommer man bli mycket bättre på att introducera det
och använda det i ett nytt projekt.
1.9.2
Metod
Metoden som jag använt och beskrivit tidigare i denna del har varit ganska
bristfällig. Det hade varit bra att göra mycket mer utförliga anteckningar av
både erfarenheter från projektet och lärdomar från böckerna jag läst. Att
föra anteckningar mer kontinuerligt, kanske varje dag, hade även det varit
väldigt positivt. Detta hade kunnat bidra till en bättre uppsats men kanske
framförallt så hade det kunnat bidra till att jag kunnat utvecklas mer som
teamledare under projektets gång.
Anledningen att detta inte gjordes var främst lathet. Efter en dag i ett
projekt känns det ofta inte som att man gjort något speciellt som är givande
att reflektera över och anteckna, med det kan vara väldigt bra att göra det
ändå. De reflektioner som behöver göras i samband med att anteckningarna
skrivs kan bidra till mycket medvetenhet om vad man gör och hur det påverkar projektet. Detta är något som jag tar med mig till framtida projekt och
som jag då kan förbättra.
1.10
Slutsatser
För att sammanfatta svaren på de frågeställningar som denna del behandlar
kommer de här att tas upp och besvaras var för sig. Detta är dock inga
direkta svar på frågorna utan endast de erfarenheter som kunnat dras under
detta projekt och från de böcker som jag har läst.
1.10.1
Hur Kanban påverkar ett projekt
Det mest centrala i metodiken Kanban är Kanban-tavlan. Denna är en bra
samlingspunkt och centrum för diskussion vid möten. Även fast vi inte kunnat
39
ha en fysisk tavla utan enbart haft en virtuell tavla som funnits tillgänglig via
internet har detta fungerat bra. Tavlan visar på ett bra sätt vilka aktiviteter
som arbetas på och var i arbetsflödet de finns. Vid möten är det väldigt bra
för att starta diskussioner kring hur arbetet går.
Den direkta påverkan på projektet som Kanban-tavlan i sig haft för oss
är att den har ändrat sättet som vi har diskuterat aktiviteter på. Eftersom
det funnits väldigt konkreta virtuella lappar med aktiviteter som varit placerade på specifika platser i arbetsflödet har det gjort att diskussioner kring
aktiviteterna kunnat få mycket tydligare struktur. Att lägga till och flytta
runt lapparna har även gett mötena ett tydligare syfte. Istället för att bara
nämna hur arbetet går på en aktivitet har vi kunnat diskutera mer om hur
den ligger till, när den kan tänkas flyttas vidare till nästa kolumn, hur högt
prioriterad den är och så vidare.
Utöver Kanban-tavlan i sig har vi även använt oss av gränser på antal WIP
i varje flöde eller kolumn, vilket Kanban förespråkar. Detta är ett sätt att
hålla fokus på rätt saker och inte jobba med för många olika saker samtidigt.
Det bidrar också till att gruppen får mycket fokus på att även testa och
integrera nya funktioner så att de snabbt kommer med i den sammansatta
produkten. Det har fungerat väldigt bra med vår användning av kontinuerliga
prototyper.
Att hela tiden försöka utveckla användningen av Kanban, exempelvis genom att ändra gränserna för antal WIP, har bidragit till bättre medvetenhet
kring hur vi jobbar. Då gruppen har behövt ändra sådana gränser har det
tvingat oss att tänka på hur antalet pågående aktiviteter påverkar effektiviteten i vårt arbete. Jag tror själv att medvetenhet om sådana saker i hela
gruppen är något mycket positivt då det bidrar till bättre samarbete, motivation och i slutändan även effektivitet.
1.10.2
Introduktion av Kanban i ett projekt
Det finns många sätt att introducera Kanban i ett projekt, bra och mindre
bra och mer och mindre krävande. Då min kunskap om Kanban vid intro40
duktionen var ganska bristfällig och även tiden för introduktionen var mycket
begränsad blev introduktionen av Kanban i vårt projekt definitivt inte optimal. Jag har dock fått många erfarenheter av vad som fungerar bra och inte,
och jag har fått många tips från de böcker som jag läst.
Det som kanske är viktigast vid introduktionen av Kanban i ett projekt
är att få gruppen att förstå vad nyttan med metodiken är. Om inte alla i
gruppen förstår varför metodiken används och hur den bidrar till gruppens
effektivitet så kommer metodiken motarbetas och inte kunna uppnå sin fulla
potential. I case-studien i Kniberg och Skarins bok[3] används en workshop för
att sprida metodens budskap. Jag kände inte att jag hade de förutsättningar
som krävdes för att göra en workshop med gruppen. Istället fick jag använda
vårt eget pågående projekt för att testa saker på. En workshop hade definitivt
kunnat vara bättre då man i en sådan kan visa tydliga fördelar och vinster i
att använda metodiken, och samtidigt lära ut hur den ska användas.
Något annat som är viktigt att tänka på vid introduktionen av Kanban är
att lyssna på gruppens tankar och åsikter. Kanban ska hela tiden utvecklas
i ett projekt och det kommer det inte göra om inte alla får en möjlighet
att uttrycka brister. Detta är något som jag har försökt göra hela tiden så
mycket som möjligt.
1.10.3
Strategisk projektledning
Denna frågeställning besvaras främst utifrån boken om strategisk projektledning[6] som jag har läst i och mina tankar kring detta.
Att se projektet i det helhetsperspektiv som boken beskriver tror jag
är väldigt bra som projektledare. Som boken säger så är projektledarens
uppgift att få gruppen att producera resultat som bidrar till projektets syfte.
Detta uppnås inte på bästa sätt om projektledaren sätter sig in mycket i
varje enskild del av projektet. Det är då bättre om projektledaren ser och
förmedlar helheten av projektet och projektets syfte.
De frågor som nämns under teori i denna del tror jag bidrar till en väldigt
bra grund för projektgruppen. Om dessa besvaras ordentligt efter mycket
41
reflektion så är det sannolikt att hela gruppen har en bra bild av projektet
och dess syften och mål.
42
2
Andy Truong: Dokumenthantering i projekt
2.1
Inledning
Genom ett systematiskt arbetssätt kan dokumenthantering i större projekt
bli enklare och effektivare med högre kvalitet på dokumenten. Denna individuella del utreder projektgruppens tillvägagångssätt för att effektivisera
hanteringen av projektets elektroniska dokument.
Metoder såsom versionshantering, kollaborativ redigering och typsättning
behandlas i denna utredning. De erfarenheter som förvärvats under projektets
gång analyseras och redogörs.
2.2
Syfte och mål
Syftet med denna delrapport är att redogöra samt reflektera över projektgruppens arbetssätt med avseende på dokumenthantering.
2.3
Frågeställning
• Hur kan flera personer simultant arbeta i ett dokument men samtidigt
bibehålla dess kvalitet?
• Vilka metoder finns för att effektivisera dokumenthanteringen och därmed spara tid och resurser?
2.4
Avgränsningar
Utredningen behandlar inte hela arbetsflödet av dokumenthantering. Delar
såsom informationsinhämtning samt dokumentdistribuering till tredje part
utelämnas. Utredningen avgränsas till teknisk och vetenskaplig dokumentation som lagras elektronisk. Resultatet av versionshantering begränsas till
dokument även om det dessutom tillämpats på källkod. Resultatet begränsas
till detta projekts erfarenheter.
43
2.5
Bakgrund
Ett stort projekt kan innehålla många delmoment och oftast är flera personer involverade. Ibland kan det bli problematiskt att hantera dokumenten,
särskilt då de snabbt blir många och flera ska redigera i dem samtidigt. Idag
finns det många verktyg för att hantera dessa problem. Det kan dock fortfarande var svårt att hitta ett effektivt arbetssätt för dokumenthantering,
vilket är motivationen till denna utredning.
Under detta mjukvaruprojekt har en dokumentansvarig anordnat projektets samtliga dokument. Dokumentansvarig har försett projektet med verktyg
samt dokumentmallar för att effektivt kunnat bearbeta projektets dokument.
Utöver det innebar rollen att granska och formatera dokumenten.
2.6
Teori
En stor del av ett projekt spenderas till dokumentation och oftast görs detta
i grupp [7]. Dokumentation är en viktig byggsten då den formaliserar kommunikationen mellan projektmedlemmarna. En god dokumentation anses effektivisera utvecklingen av projektet eftersom den ger projektmedlemmarna
en bättre uppföljning och insyn av projektet [8]. De ger även en återblick för
framtida referenser och utveckling.
Detta avsnitt behandlar olika arbetssätt och verktyg som kan tillämpas
vid dokumenthantering.
2.6.1
Versionshantering
Dokument som versionshanteras lagras i flera versioner. Det möjliggör spårning av tidigare ändringar och eventuellt återskapa dem. Versionshantering
kan förutom på dokument tillämpas på andra medier.
Kärnan i ett versionshanteringssystem är en repository som fungerar som
en lagringsplats. Där lagras vanligtvis filer, kataloger samt information om
dess hierarki. Behöriga klienter kan ansluta till en repository för att läsa eller
44
skriva. Filerna kan spåras och återskapas från en tidigare tidpunkt eftersom
alla händelser loggas.
Versionshanteringssystem finns i två former, centraliserade och decentraliserade även kallade distribuerade. Under lång tid har centraliserade system
dominerat marknaden men på senare tid har många övergått till distribuerade system [9]. Exempel på versionshanteringssystem nämns i avsnitt 2.6.5.
Centraliserad versionshantering
I centraliserade versionshanteringssystem finns det endast en repository
på en central server. Samtliga klienter kommunicerar med samma server
för hämta och skicka ändringar.
Distribuerat versionshantering
Distribuerade versionshanteringssystem är ett nyare alternativ till det
centraliserade. Huvudkonceptet är att varje klient har en egen lokal
repository. Klienterna gör sina ändringar i sin lokala repository. Ändringarna kan sedan skickas till en delad repository på en extern server,
men är inte nödvändigt.
2.6.2
Kollaborativ redigering
Kollaborativ redigering är ett arbetssätt för dokumentredigering där fokus
ligger på deltagande, uppmärksamhet och koordination. Genom att vara uppmärksam och förstå andras aktiviteter ger det förutsättningar att förstå sina
egna aktiviteter bättre [10]. Målet är att gemensamt uppnå en enhetlig version av det slutgiltiga dokumentet.
När flera personer samarbetar i ett dokument uppkommer det flera beslut
som måste tas. Det krävs en plats där dokumentet ska lagras samtidigt som
det ska vara åtkomligt för övriga deltagande. Det krävs ett verktyg för att
kunna redigera dokumentet. Delarna som har bearbetats måste sammanfogas
och eventuella konflikter måste hanteras. Ett system som tillämpar kollaborativ redigering löser detta och ska, enligt Jun-hui och Geng-yu och Cong [11]
efter en sammanställning av andra rapporter, ha följande tre kännetecken.
45
• Obegränsad – Deltagande ska vid alla tillfällen fritt kunna redigera
alla delar av dokumentet.
• Distribuerad – Dokumenten ska vara åtkomliga från andra enheter
än huvudkällan.
• Realtid – Alla lokala förändringar ska reflekteras till andra deltagande
utan större fördröjningar.
Ett alternativt arbetssätt i gemensam dokumentskrivning är att tilldela
varje deltagare olika delar att skriva och avsluta med att sammanfoga dessa till en slutgiltig version. Ett annat alternativ är att individuellt arbeta
med dokumentet och sedan skicka den vidare till de övriga författarna för
fortsatt redigering. Skulle någon hinna uppdatera dokumentet före, måste de
ändringarna läggas till innan dokumentet kan skickas vidare.
Idag finns det sofistikerade verktyg (2.6.5) för kollaborativ redigering.
Många av dem nyttjar någon form av versionshanteringssystem för att spåra
ändringar samt automatiskt sparar ändringar. Ett system behöver emellertid
inte nödvändigtvis ha sparat en ändring även om ändringen har reflekterats
till de andra deltagarna [11].
2.6.3
Typsättning
En väsentlig del av ordbehandling avser typsättning. Det är processen för skapandet av dokumentets layout och formatering av text. En god typsättning
kan bidra till mer läsliga dokument samtidigt som de kan bli mer estetiska
tilltalande.
De flesta ordbehandlingsprogram har ett grafikbaserat typsättningssystem. Texten formateras efter användarens inmatningar och resultatet presenteras omgående. När dokumentet sparas ner till fil lagras texterna med
formatering oftast i ett märkspråk, vilket instruerar hur dokumentet ska presenteras. Grafikbaserade typsättningssystem abstraherar bort märkspråket
från användaren.
46
Märkningsbaserade typsättning exponerar användaren direkt till märkspråket. Användaren ansvarar själv formatteringen av texten utifrån exempelvis markeringstaggar eller kommandon.
2.6.4
Molnbaserad lagring
Lagringstjänster som tillhandahålls över Internet lagrar filer och dokument
i molnet, vilket i praktiken är ett externt serverutrymme. Filerna lagras i
en eller flera servrar som är ägda och kontrollerade av företagen som tillhandahåller tjänsterna. Eftersom filerna lagras i molnet och inte lokalt är
de ständigt uppdaterade och åtkomliga från flera olika enheter. Enligt en
undersökning [12] är molnbaserade lösningar billigare än egna lösningar.
2.6.5
Verktyg
Ett verktyg i detta sammanhang syftar till en produkt eller tjänst som kan
bidra till dokumenthanteringen.
Git
Git är ett distribuerat versionshanteringssystem med öppen källkod. Git särskiljer mellan arbetsyta, ett förberedande steg, lokal och distribuerad repository. I arbetsytan sker alla ändringar och innehåller filer som både är spårade
och icke-spårade. I det förberedande steget väljs de ändringar som ska med
en specifik commit, vilket betyder att ändringarna lämnas över till en lokal
repository. Slutligen skickas ändringarna upp till en distribuerad repository
för att göra de tillgängliga för övriga klienter.
Eventuella nya ändringar från andra klienter måste sammanfogas med de
lokala innan de kan skickas upp. Skulle konflikter uppstå med ändringar från
en annan författare kommer systemet automatiskt försöka sammanfoga ändringarna. Lyckas inte den automatiska sammanfogningen krävs en manuell
granskning. Ju fler ändringar mellan sammanfogningarna desto högre risk för
konflikter som kräver manuella åtgärder.
47
Andra distribuerade versionshanteringssystem är bland annat Mercurial
och Bazaar. Centraliserade alternativ är Concurrent Versions System och
Subversion. Skillnaderna mellan dem är oftast prestanda och arbetsflöde.
Google Drive
Google Drive är en tjänst, skapat av Google Inc., som möjliggör fillagring i
molnet. Tjänsten erbjuder ett begränsat utrymme med möjlighet till uppgradering. Användaren har åtkomst till filerna från företagets webbplats. Filerna
kan synkroniseras till användarens lokala system genom en applikation. Efter
en fullständig synkronisering finns filerna tillgängliga även utan internetanslutning. Filer som lagras på molntjänsten kan delas med andra parter som
också använder tjänsten. Ändringar som görs på delade filer speglas till samtliga parter.
Andra tjänster som erbjuder molnlagring är OneDrive, Dropbox, Box och
iCloud.
Google Docs
Google Docs är en tjänst som erbjuder webbaserad redigering av dokument, kalkylark och presentationer. Tjänsten tillhandahålls av samma företag som tillhandahåller Google Drive, vilket gör tjänsterna tätt integrerade.
Dokumenten i Google Docs kan simultant bearbetas av flera användare eftersom tjänsten utövar kollaborativ redigering (2.6.2). Används företagets
egna webbläsare, Google Chrome, kan dokumenten dessutom redigeras utan internetanslutning. Ändringarna synkroniseras då till molnet (2.6.4) först
när internetanslutningen återfås. Google Docs har ett eget versionshanteringssystem (2.6.1) för att spåra ändringar. Det finns även ett förslagsläge
där nya ändringar måste godkännas. Utöver det finns det möjlighet till att
lämna kommentarer i dokumentet. Ändringar sparas automatiskt i Google
Drive. De sparas i intervaller men skulle en konflikt uppstå visas ett meddelande med konflikten. Eftersom ändringarna sparas regelbundet är konflikter
sällsynta.
48
Det finns alternativa lösningar som kan installeras på användarens system
såsom OpenOffice och Microsoft Office skapat av Star Division respektive
Microsoft Corporation. Det sistnämnda erbjuder också kollaborativ redigering om dokumenten är placerade i företagets molnlagringstjänst OneDrive.
LaTeX
LaTex är ett populärt typsättningssystem baserat på TeX. Användaren arbetar med texten i valfri textredigerare. Dokumentets layout och textens format
bestäms av bland annat kommandon som kommer från olika paket som är
konfigurationsfiler. Ett dokumentet kan bestå av flera filer som importeras
till huvuddokumentet. Detta gör det möjligt att dela upp dokumentet i flera
delar.
LaTeX har många användbara kommandon som bland annat förenklar
numrering av sektioner, figurer och tabeller samt automatiskt genrering och
numrering av litteraturlista.
För att se resultatet av dokumentet måste filerna kompileras. Utdatan är
oftast en PDF-fil som kan presentera det formaterade dokumentet i en valfri
PDF-läsare.
2.7
Metod
Redan vid projektets start gjordes en gemensam evaluering av potentiella
verktyg med hänsyn till parametrar såsom kostnad, tillgänglighet och tidigare erfarenheter. Ett gemensamt beslut togs om vilka verktyg som skulle
användas. Under projektets gång experimenterade dokumentansvarig med
nya arbetssätt för att förbättra dokumenthanteringen.
Dokumentskrivning påbörjades tidigt i projektet. Efter att projektgruppen förstått projektets syfte sammanträdde samtliga projektmedlemmar i ett
möte för att bestämma strategi. Utan vidare undersökningar beslutades att
Google Docs huvudsakligen skulle användas till dokumentskrivning. Dokument som skrevs i Google Docs skulle lagras i Google Drive. LaTeX skulle
användas till de slutgiltiga dokumenten som skulle publiceras eller skickas till
49
tredje part. Mindre interna dokument såsom mötesprotkoll skulle endast skrivas i Google Docs för att spara tid. Git skulle användas för versionshantering
av LaTeX-dokumenten. Besluten grundades på de verktyg projektmedlemmarna tidigare kände till.
En server sattes upp av projektets arkitekt för att hantera Git. Initialt
användes Git enbart till projektets källkoder. Användandet av Git introducerades först när dokumenten började skrivas i LaTeX. Alla dokument i LaTeX
versionshanterades i Git.
Innan det första dokumentet överfördes från Google Docs till LaTeX tog
dokumentansvarig fram en LaTeX-mall som skulle användas genomgående
under projektets gång. Eftersom mallen skulle gälla för projektets samtliga
dokument behövde den generaliseras. Mallen skulle dessutom ha stöd för flera språk. Dokumentansvarig hade inga tidigare erfarenhet av LaTeX således
krävdes självstudier inom ämnet innan mallarna kunde skapas. Mallen förbättrades kontinuerligt under projektets gång. Oftast var det små ändringar
såsom att inkludera nya paket, men även ibland stora ändringar såsom layoutförändringar. Ändringar i mallarna reflekterades dessutom i äldre dokument
som använde mallarna. För att uppdatera de äldre dokumenten krävdes dock
omkompilering.
Mallen till dokumenten bestod av flera filer. Ett av dem är ett eget paket
skapat för projektets dokument. Paketet konfigurerade dokumentens layout
och importerade nödvändiga paket. Paketet tog in språk som inparameter
för att anpassa dokumentet efter olika språkregler. Övriga filer bestod av
framsida, försättsblad och informationsblad. Dessa fanns tillgängliga på både svenska och engelska. Filerna separerades i olika kataloger namngivna
efter språkens namnkoder enligt ISO 639-1. Rätt katalog importerades till
huvuddokumentet baserat på det språk som var inställt i det egna paketet.
Första utkastet av varje dokument samskrevs i det vanliga redigeringsläget i Google Docs. Texten granskades och överfördes sedan till LaTeX av
dokumentansvarig där nödvändiga formatteringar av texten fick göras. Följande ändringar till texterna gjordes istället i förslagsläget. Med förslagsläget
50
kunde dokumentansvarig enkelt granska och acceptera dem innan de överfördes till LaTeX-dokumenten. Därigenom överfördes endast nya ändringar
och inte hela dokumenten på nytt. Texter som samskrevs bearbetades alltid i
Google Docs före det överfördes till LaTeX-dokumenten. Detta medförde att
dokument som skrevs i Google Docs alltid var uppdaterade med de senaste
ändringarna.
I Google Docs kunde projektmedlemmarna kommentera och diskutera
delar av dokumentet om något var oklart.
Delar av dokument som skulle skrivas individuellt skrev projektmedlemmarna direkt i LaTeX. Varje individuell del skrevs i en egen fil som importeras
av huvuddokumentet. De delarna granskades först när de blev klara.
Det avslutades med att hela dokumenten korrekturlästes av en eller flera
projektmedlemmar. Korrigeringar gjordes vid behov.
2.8
Resultat
I detta projekt producerades tio större dokument som antingen publicerades
eller skickades till tredje part. Detta gällde allt från projektplan och kvalitetsplan till arkitekturbeskrivning och teknisk dokumentation.
Genom tillämpning av kollaborativ redigering kunde projektets medlemmar arbeta i samma dokument simultant. Till detta användes Google Docs.
Projektmedlemmarna var alltid uppmärksamma på ändringar i dokumenten
eftersom de uppdaterades i realtid. De kunde därmed arbeta med texterna mer effektivt. Tjänsterna som är webbaserade krävde ingen installation,
vilket gjorde det enkelt att komma igång. Eftersom projektmedlemmarna redan sedan tidigare hade erfarenhet och användarkonton på tjänsterna kunde
dokumentskrivandet påbörjas omedelbart.
Mellan varje utkast överfördes texterna från Google Docs till LaTeX för
att utforma dokumentens layout. Dokumentansvarig ansvarade för dokumentens layoutmallar. Detta medförde att övriga projektmedlemmar istället kunde fokusera på dokumentens innehåll. Genom användandet av LaTeX kunde
mycket tid sparas eftersom skapandet av mallen endast gjordes en gång me51
dan det återanvändes av flera dokument. LaTeX numrerar bland annat referenser, sektioner, figurer och tabeller automatiskt. Det gjorde det enklare att
lägga till och ta bort innehåll samtidigt som korrekt numrering bevarades.
Dokument som redigerades på Google Docs kunde endast lagras i Google
Drive, där de även versionshanterades av ett internt system. LaTeX-dokumenten
versionshanterades på Git. Dokumenten var därmed alltid tillgängliga för
samtliga projektmedlemmar.
Varje text granskades av dokumentansvarig för att erhålla hög dokumentkvalitet. För nya dokument granskades hela texter innan de senare överfördes till LaTeX. För ändringar i befintliga dokument användes förslagsläget i
Google Docs. Dokumentansvarig granskade och accepterade ändringen innan
den överfördes till LaTeX.
2.9
Diskussion
Under ett projekt kan det skapas många fler dokument än förväntat. Avsevärd stor del tid av detta projekt gick åt till bearbetning och hantering av
dokument. Det fanns oerhört många olika verktyg att välja emellan. Det kan
vara krångligt att hitta ett arbetssätt som ska fungera bra för ett projekt.
2.9.1
Resultat
Google Docs valdes främst för tillämpningen av kollaborativ redigering. Att
samtliga projektmedlemmar hade tidigare erfarenhet av det hade också betydelse. Alternativa lösningar undersöktes ej eftersom det inte kändes något
behov. Google Docs erbjöd de funktioner som behövdes, vilket även inkluderar möjligheten att lämna kommentarer samt ett förslagsläge som gjorde
det möjligt att granska ändringar. Dessa funktioner användes väldigt ofta
av projektmedlemmarna för att kommunicera i texterna. En stor nackdel
med Google Docs är layout och formatering. Det fanns stora begränsningar i
dokumentkonfiguration för Google Docs, något LaTeX inte hade. Detta var
den enda anledningen till valet av LaTeX. Samtliga verktyg som användes i
projektet var kostnadsfria som också var ett av kriterierna när de valdes.
52
Förslagsläget i Google Docs var både bra och dåligt beroende kvantiteten av den text som hade ändrats. Vid färre ändringar fungerade det bra
eftersom dokumentansvarig inte behövde föra över hela dokumentet på nytt,
vilket sparade tid. Vid många ändringar blev det mycket rörigt i Google
Docs och allt behövde föras över på nytt. Det positiva med förslagsläget
var att ändringarna enkelt kunde granskas. Arbetssättet fungerade väldigt
bra. Granskning av alla ändringar var tidskrävande men resulterade i högre
dokumentkvalitet.
I detta projekt fanns det endast en dokumentansvarig, vilket var adekvat
för projektets storlek. För större projekt skulle det rekommenderas att flera
personer tilldelas olika dokument att granska överföra från Google Docs till
LaTeX för att avlasta dokumentansvarig.
Både LaTeX och Git är väldigt användbara verktyg men brister i att användaren måste förstå de kommandon som ska användas. Användaren måste
lära sig hantera konflikter och lösa dem, något som inte alltid är trivialt.
Att ta fram dokumentmallen var mycket tidskrävande. Främst för att
dokumentansvarig inte hade tidigare arbetat med LaTeX och det krävdes
mycket självstudier. När mallen väl var på plats gick det snabbt att skapa nya
dokument som använde mallen. Det var endast det egna LaTeX-paketet som
var komplex att skapa. Dokumenten som använde sig av mallen var triviala
och bestod endast av några fåtal kommandon som enkelt kunde läras ut till
projektmedlemmarna med inga tidigare erfarenheter av LaTeX. Detta gjorde
det möjligt att alla projektmedlemmar kunde skriva sina individuella delar
direkt i LaTeX eftersom behovet av kollaborativ redigering då inte fanns.
Det ultimata hade varit om Google Docs hade utökat funktionalitet för att
bättre hantera layout och formatering, men samtidigt behålla dess enkelhet.
Utan att behöva vänta på att Google ska uppdatera deras tjänst skulle det
vara möjligt att bygga ett script som automatiskt konverterar till LaTeXformat. Det skulle dock vara ett stort projekt i sig.
53
2.9.2
Metod
Mot slutet av projektet närmade sig deadline allt för fort och det blev tidsbrist. Det gjorde att metoden inte följdes fullständigt för ett återstående
dokument. De slutgiltiga ändringar i det dokumentet gjordes direkt i LaTeX. Detta medförde att ändringarna inte granskades enligt tidigare arbetssätt. Istället korrekturläste samtliga projektmedlemmar dokumentet när det
ansågs vara klart. Detta fungerade bra men begränsas till när dokumentet
började bli färdigt och hela dokumentet ändå skulle korrekturläsas. Det skulle
krävas för mycket resurser att ständigt behöva läsa igenom hela dokumenten
även vid fåtal ändringar.
Eftersom det fanns bristande kunskap inom LaTeX uppstod det emellanåt
kompileringsfel som var besvärliga och tidskrävande att lösa. Ofta var orsaken
att gammal cache-data inte hade rensats ordentligt. Annars har LaTeX gett
mycket goda erfarenheter.
Ett problem med redigering i förslagsläget var att projektmedlemmar
stundvis kunde glömma slå på förslagsläget. Det resulterade i att en del
ändringar inte fördes över till LaTeX-dokumenten.
2.10
Slutsatser
Valen av arbetssätt och verktyg för projekthantering i ett projekt varierar
beroende på typ av projekt och dess storlek. De flesta projekt kan dock ta
lärdomar av de erfarenheter som erhölls av detta projekt. Sannolikt kommer
det produceras många dokument i projekt och oftast bearbetas dokumenten
grupp. Kollaborativ redigering (2.6.2) och versionshantering (2.6.1) kan bidra
till bättre och enklare bearbetning och hantering av dokument i grupp.
I detta mjukvaruprojekt har flertalet verktyg (2.6.5) använts. Google Docs
har använts till att samskriva dokument och det tillämpar kollaborativ redigering. Google Drive har använts till lagring av gemensamma filer. LaTeX har använts till typsättning av dokuments layout eftersom formatering
i Google Docs är bristande. Git har använts till versionshantering av LaTeX-
54
dokumenten.
Dokumenten bör granskas av en andra person för att säkerhetställa att
dokumentet håller kvalitet. Detta kan göras genom exempelvis ett förslagsläge i Google Docs för att endast granska nya ändringar.
Eftersom det kan skapas många dokument bör bra dokumentmallar tas
fram redan vid projektets start. Lämplig användning av dokumentmallar
sparar tid eftersom repetitiva moment undviks.
55
3
Erik Boman: Testning och säkerhet vid utvecklandet av en webbapplikation
3.1
Inledning
Detta är en individuell del av kandidatrapporten om visualisering av svarstider mellan mobila klienter och datacenter. Denna del kommer att behandla
det testande och säkerhetsarbete som sker vid utvecklandet av en webbapplikation. Rapporten tar även upp och diskuterar hur man kan effektivisera
testandet genom att använda olika automatiska tester.
3.2
Syfte och mål
Syftet med denna delrapport är att visa på vad som är viktigt att tänka
på i testarbetet av en webbaserad applikation samt vilka delar som är extra
viktiga att testa grundligt. Ett annat syfte är att visa på hur viktigt det är
för företag att testa deras webbapplikationer och vilka konsekvenserna kan
bli om detta inte görs grundligt.
3.3
Frågeställning
1. Varför lägger inte många företag mer pengar på testning av deras webbsäkerhet?
2. Vilka olika typer av säkerhetsrisker finns det när en webbapplikation
görs tillgänglig via internet och hur kan man motverka dessa risker?
3.4
Avgränsningar
Nedan beskrivs de avgränsningar som gjorts.
56
3.4.1
Avgränsningar i rapporten
Den här rapporten tar endast upp testning och säkerhetsarbete vid utvecklandet av en webbapplikation som tillhandahålls via en webbserver. Ingenting
om skillnader i säkerhet mellan olika webbläsare tas upp. Det är även viktigt
att poängtera att långt ifrån alla säkerhetsrisker tas upp utan fokus ligger
på de som är vanligast förekommande.
3.4.2
Avgränsningar vid testning
Den stora begränsningen vid testandet av en produkt är oftast tid och/eller
pengar. Eftersom att de flesta projekt (även vårt) har begränsad budget
kan testandet av en produkt inte pågå hur länge som helst. Vi har under
projektets gång fått göra många avvägningar mellan vidare utveckling och
testning.
3.5
Bakgrund
Det blir vanligare och vanligare att företag får sina servrar hackade så att
privat information läcker ut. Snittföretaget lägger idag ca 10-15 % av sin
totala IT-budget på säkerhet [13, s. 3]. Detta är ofta inte tillräckligt [14].
Internetattacker kan orsaka företag osannolika kostnader både genom att
eventuellt förstöra hårdvara och genom det extra arbete som företaget får
lägga ner på att hantera attacken [15, s. 2]. Företagets rykte kan också skadas
allvarligt speciellt om personlig information om företagets kunder läcker ut.
Bristerna är i många fall ett resultat av otillräckligt testande av serverns
säkerhet och bristande kunskap. Om mer tid lades på testning skulle det ske
mycket färre lyckade internetattacker.
3.5.1
Webbapplikationer nu och då
I internets tidiga dagar var de flesta hemsidorna statiska informationskällor.
Det var nästan bara företag, myndigheter och föreningar som hade hemsidor
och de innehöll sällan något mer än ren html-kod. Idag är merparten av
57
världens hemsidor dynamiska, med kod skriven ofta i Javascript eller liknande
[16, s. 17]. Användaren kan ofta också mata in data till webbservern via olika
typer av formulär och med detta kommer säkerhetsrisker. Antalet hemsidor
har också ökat lavinartat från den ensamma första hemsidan 1991 till dagens
över 1 miljard hemsidor.
3.6
Teori
Det finns otroligt många sätt att förstöra eller få tillgång till en webbserver
och informationen på en webbserver. Några av de vanligaste sätten beskrivs
nedan.
3.6.1
Cross-site scripting
En av de vanligaste säkerhetsbristerna som många hemsidor har handlar om
cross-site scripting [17, s. 41]. Attacker genom cross-site scripting drabbar
ofta forum eller chatter. Det finns egentligen två stycken varianter av crosssite scripting. I det ena fallet läggs html-kod in i ett inlägg i till exempel en
gästbok eller på ett forum. På det sättet kan hemsidans utseende förändras
genom ramar som går kors och tvärs över hemsidan eller stora bilder över
hela skärmen. I det andra fallet utnyttjas samma säkerhetsläcka som i det
första fallet men här ligger ofta fokus istället på att få tag i information
om andra användare på hemsidan. Detta kan till exempel göras genom ett
enkelt skript som när användare besöker den infekterade sidan skickar deras
inloggningsinformation till hackaren[16, s. 17].
3.6.2
SQL-injektioner
Webbsidor med webbformulär är särskilt utsatta för SQL-injektioner. Ta som
ett exempel en hemsida med ett inloggningsformulär. Användaren matar in
användarnamn och lösenord som sedan skickas till webbservern med tillhörande databas för validering. För att se om inloggningsinformationen stämmer kan databasen till exempel ges följande fråga (MySQL),
58
”SELECT * FROM users WHERE username=’+username+’
AND password=’+password+’;”, om databasen returnerar en rad fanns en
användare med givet användarnamn och lösenord. Antag nu att användaren angav till exempel ”admin” som användarnamn och ” ’ OR ’1’=’1 ”
som lösenord. Databasqueryn blir därmed: ”SELECT * FROM users WHERE
username=’admin’ AND password=” OR ’1’=’1’;”. Eftersom att 1=1 kommer databasen att returnera en rad och användaren får tillgång till adminkontot.
Det finns många andra exempel på vad en hackare kan göra. Med grundläggande kunskap om databaser och lite gissande av tabellnamn kan till exempel hela tabeller ur databasen raderas [17, s. 42].
3.6.3
Brute force
En brute force attack går helt enkelt ut på att gissa sig fram till rätt lösenord för inloggning på till exempel en hemsida. Det är ganska ovanligt att
rena brute force attacker lyckas eftersom att det krävs otroligt lång tid även
för en snabb dator att gissa på alla möjliga kombinationer av tecken som
kan bygga upp ett lösenord. Istället brukar olika kombinationer av vanligt
förekommande lösenord testas först för att öka chansen att få en tidig träff.
3.6.4
Denial of service
Det finns otroligt många olika typer av denial of service attacker men det
de flesta varianterna har gemensamt är att de försöker förhindra vanliga
användare från att komma åt information. [18, s. 515] Denna information
kan till exempel vara en hemsida. En av de vanligaste sätten att utföra en
denial of service attack är en så kallad distribuerad denial of service. I det
fallet så används massor av datorer som är uppkopplade till internet till
att skicka förfrågningar, ofta till något företags webbserver, så att den blir
överbelastad. [19, s. 117] Ofta är det vanliga privatpersoners datorer som
har blivit hackade och sedan används till dessa attacker utan att ägaren av
datorn ens vet om det.
59
3.7
Metod
Under arbetet med projektet har gruppen inte fokuserat särskilt mycket på
säkerhetsarbete eftersom att produkten vi utvecklar ändå bara kommer att
finnas tillgänglig internt på Opera. För att lära mig mer om säkerhet har
därför antagits att vår produkt kommer att göras tillgänglig via internet och
sedan testat dess säkerhet.
Vid säkerhetsarbetet användes programmet Vega [20] som är ett gratis
verktyg för att automatiskt hitta säkerhetsläckor i webbapplikationer. För att
kunna göra ett test på en applikation med Vega behövdes en webbserver så
därför installerades Apache, som är den den vanligaste webbservern i nuläget,
på den dator som testernas utfördes på.
Att testa applikationen tog endast några minuter och Vega hittade inga
säkerhetsrisker relaterade till vår applikation (endast några risker i webbserverinställningarna). Dock skulle säkerhetsrisker kunna uppstå, framförallt
med den sökruta för att söka efter länder som applikationen innehåller. Om
den data användaren matar in i sökfältet direkt skulle användas till att ta ut
länder ur en databas skulle SQL-injektioner kunna bli ett problem. I nuläget
letar den bara i en array med länder men det är bra att vara medveten om
säkerhetsriskerna i förväg.
3.8
Resultat
För att förbättra säkerheten hos en webbapplikation finns det många olika
saker som kan göras. Till att börja med är det viktigt att se till så att nyaste
versionen av alla program på webbservern är installerade eftersom att nya
uppdateringar med säkerhetsfixar släpps kontinuerligt.
Eftersom att vår webbapplikation inte kommer att vara ansluten direkt
till internet behövde inte vi tänka särskilt mycket på det som diskuteras i
den här rapporten men det är fortfarande viktigt att känna till de risker som
finns och de begränsningar som en produkt har om den görs tillgänglig via
internet. Om Opera av någon anledning skulle vilja göra webbapplikationen
60
tillgänglig för allmänheten via internet och ha den kopplad till en databas
skulle mycket mer arbete behöva läggas på säkerhetsarbete för att inte riskera
informationsstölder och/eller serversabotage.
3.8.1
Cross-site scripting
För att skydda sig mot cross-site scripting är det viktigt att se till så att
användarinmatad data inte får innehålla vad som helst. För att förhindra
att skadlig kod läggs in på hemsidan bör man därför konvertera riskabla
tecken till deras respektive vanliga texttecken. Till exempel bör tecknet ”<”
konverteras till ”&lt” eftersom att den annars kan användas till att skapa ett
skript som exekveras vid laddning a hemsidan. Om ”&lt” används kommer
tecknet istället att skrivas ut som vanligt. Ofta finns det inbyggda funktioner
som gör detta automatiskt, till exempel så kan man i PHP använda sig av
funktionen htmlspecialchars.
Att testa om en applikation är skyddad mot cross-site scripting manuellt
kan vara mycket tidskrävande eftersom att det potentiellt kan finnas otroligt
många kryphål där skadlig kod kan ta sig in i systemet. Det finns också stor
risk att man missar något ställe i koden och lämnar en lucka för hackaren.
För att enkelt och tidseffektivt kolla om en applikation har några kryphål
kan man istället använda sig av ett program som automatiskt hittar dessa åt
en. Det finns ett stort antal sådana program i olika prisklasser att ladda ner.
Det finns även ett antal hemsidor som utför sådana sökningar över internet
och visar resultatet direkt i webbläsaren.
3.8.2
SQL-injektioner
Det bästa sättet att skydda sig mot SQL-injektioner är genom att använda
parametriserade frågor när man hämtar eller lagrar något i en databas. Att
implementera detta är ganska enkelt och gör så att om någon användare försöker mata in till exempel ” ’ OR ’1’=’1 ” som lösenord (se 3.6.2) kommer
databasen inte att bli lurad av att 1=1 utan kommer istället kolla om ” ’
OR ’1’=’1 ” stämmer överens med användarens lösenord. Ett exempel på en
61
simpel databasinsättning som använder parametriserade frågor skulle i PHP
kunna se ut så här:
Listing 1: Parametriserad query i PHP
$query = $dbh - > prepare (" INSERT INTO users ( username , password )
VALUES (: username , : password )");
$query - > bindParam ( ’: username ’ , $username );
$query - > bindParam ( ’: password ’ , $password );
$query - > execute ();
De användarinmatade variablerna $username och $password kan inte
längre skada databasen allvarligt eftersom att de inte kan påverka frågan på
något oväntat sätt.
För att testa om en applikation är skyddad mot SQL-injektioner kan
man ofta göra på samma sätt som i fallet med cross-site scripting (se 3.8.1).
Det finns många program som försöker hitta svagheter i en applikation och
sedan rapporterar vilka som hittades. Ofta finns det program som testar både
svagheter vad det gäller cross-site scripting och SQL-injektioner samtidigt.
3.8.3
Brute force
Brute force attacker utförs ofta av botar eftersom att det kortar ner tiden
det tar att gissa ett lösenord mot om en människa skulle sitta och göra
gissningar. Därför skulle ett enkelt sätt att förhindra brute force attacker
kunna vara genom att införa en verifikation på att det är en människa som
gör inmatningen till exempel genom att låta dem utföra någon uppgift som en
dator har svårt att utföra, till exempel känna igen några bokstäver och/eller
siffror i en bild. Detta kan dock vara jobbigt att göra för användaren varje
gång denne vill logga in och datorer kan, även om det är lite komplicerat
klara av att känna igen bokstäver och siffror.
Ett bättre sätt att lösa problemet kan vara att införa restriktioner på
antal inloggningsförsök för en specifik IP-adress eller för ett användarkonto.
Att lägga in en kort tidsfördröjning vid misslyckad inloggning kan också vara
lämpligt eftersom att det kan förhindra servern från att bli överbelastad vid
en attack utförd av en bot.
62
Precis som för cross-site scripting och SQL-injektioner finns det program
som automatiskt testar hur utsatt en applikation är för attacker. Dessa program simulerar helt enkelt en attack och ser hur lång tid det tar att få tillgång
till en användares konto.
3.8.4
Denial of service
Den här typen av attack är den svåraste att på egen hand förhindra av de
typer av attacker som tagits upp i den här rapporten. Om en distribuerad
denial of service attack utförs mot en server är det ganska hopplöst att försöka blockera IP-adresser eftersom att potentiellt flera tusentals IP-adresser
skulle behöva blockeras. Istället bör man leta efter likheter bland förfrågningarna som kan blockeras med brandväggen. Likheter kan till exempel hittas i
“user agenten”. En ”user agent” innehåller information om bland annat operativsystem och typ av webbläsare. Vid denial of service attacker är denna
information ofta avsaknad eller felaktig. I andra fall ser denna information
helt korrekt ut och då får man leta efter andra likheter. Eftersom att det kan
vara svårt att hitta någon likhet krävs det att den som är säkerhetsansvarig
har mycket stor kunskap om denna typ av attack.
Ett annat sätt att lösa problemet skulle kunna vara att se till så att
den server och den internetuppkoppling som används har en så pass stor
överkapacitet att en attack knappast märks, men eftersom att serverhårdvara
och internettrafik kostar pengar är detta ofta inte någon särskilt bra lösning.
För att testa hur bra sin egen applikation klarar av en denial of service
attack är antagligen det bästa sättet att simulera en attack innan applikationen görs tillgänglig online. På så sätt upptäcker man eventuella brister
i till exempel brandväggens inställningar och dessutom tränas den som är
ansvarig för applikationen på att hantera en attack. Eftersom att de flesta
denial of service attacker sker på olika sätt och ser olika ut är det i princip
omöjligt att helt skydda sig helt mot dem.
63
3.9
Diskussion
När det finns så pass relativt snabba metoder för att testa och förbättra en
webbsidas säkerhet är det beklagligt att vissa företag inte lägger mer pengar
och tid på att testa deras säkerhet. Ofta är en ganska stor bidragande orsak
bristande kunskap om webbsäkerhet men även bristande vetskap om hur
ofta och hur lätt webbattacker sker kan påverka [21, s. 12]. Många företag
vet antagligen inte ens om att de har blivit hackade och att deras privata
information läckt ut.
Jag tror också att många företag låter bli att lägga pengar på att testa
och förbättra deras säkerhet eftersom att de tror att det är ointressant för
hackare att anfalla deras webbapplikation. Detta kan bero på att de tror att,
eftersom att de till exempel är ett litet företag eller för att de inte lagrar
någon känslig information, inte är ett intressant mål för hackare.
När det gäller större företag så har de i de flesta fall åtagit åtminstone
grundläggande säkerhetsåtgärder för sina webbapplikationer. När säkerheten
sedan ska förbättras ytterligare så krävs det mer avancerade och tidskrävande
åtgärder vilket kan leda till att testandet och säkerhetsarbetet avslutas efter
att ett grundläggande skydd upprättats.
3.9.1
Resultat
Det är inte särskilt överraskande att det går att förbättra en webbapplikations säkerhet genom att testa välkända säkerhetshål, men att det i de flesta
fall är så pass lätt och kräver så pass lite kompetens, åtminstone för att få ett
grundläggande skydd är överraskande. Datorprogram kan skanna en webbapplikation efter cross-site scripting, SQL-injectioner och brute force attacker
på mycket kort tid. Det är dock värt att poängtera att dessa automatiska
testprogram kan missa viktiga säkerhetsrisker och om ett mer komplett skydd
är nödvändigt behöver även manuella kontroller av applikationens kod göras.
Att förbättra säkerheten för en webbapplikation behöver i många fall inte
ta lång tid. Att skydda sig mot cross-site scripting och SQL-injektioner kräver
64
endast att lite försiktighet används vid hanterade av användarinmatad data.
När det gäller denial of service attacker är det svårare att skydda sig. Här
ställs höga krav på att ha personal som vet hur man hanterar en sådan attack
snarare än på hur robust applikationen är.
3.9.2
Metod
Att sätta upp en webbserver och installera ett program för testning av säkerhet tog inte alls lång tid. Jag använde mig som sagt av programmet Vega
men jag tror att de flesta andra liknande program är lika lätta att sätta upp
och använda. Vega är kanske inte den mest avancerade säkerhetsskannern
som finns men för att täcka de flesta av säkerhetsriskerna som tagits upp i
detta dokument fungerade det riktigt bra.
3.10
Slutsatser
De slutsatser som kan dras ifrån arbetet med testning under projektets gång
samt från innehållet i denna rapport är att en produkt aldrig blir fullständigt testad. Det går heller inte att helt och hållet säkra en webbserver från
säkerhetsrisker hur mycket tid som än läggs på att testa den och göra den
säker.
Trots detta så kan man komma ganska långt i säkerhetsarbetet på ganska
kort tid om man bara tänker på vilka risker som finns och hur man försvårar
arbetet för potentiella hackare. Framför allt så gäller det att vara försiktig
med användarinmatad data.
Att företag inte lägger mer pengar på testning av säkerhetsfunktioner
beror i de flesta fall antingen på att de är omedvetna om riskerna med att
inte göra det, eller att det skulle krävas för mycket arbete för att göra några
ytterligare säkerhetsförbättringar.
65
4
Mikael Szreder: Kanban som utvecklingsmetodik för mjukvaruprojekt med kontinuerlig
prototypning
Agila utvecklingsmetodiker har blivit allt mer populärare inom mjukvaruutveckling. Det finns dock ett akut behov av empiriska studier som utvärderar
deras effektivitet [22, s. 1].
4.1
Inledning
Eftersom slutprodukten i detta projekt inte var tydligt definierad av kunden
ledde detta till att projektet utvecklades med en strikt process för inhämtning av krav och prototypning [23, s. 5]. Genom att kontinuerligt evaluera
prototyper tillsammans med kunden och mot kundens krav var det tänkt att
skapa produkten som kunden ville ha.
4.2
Syfte och mål
Syftet med denna delrapport är att undersöka hur Kanban, en agil utvecklingsmetodik, fungerar för projekt där krav och slutresultat inte är strikt
definierade.
4.3
Frågeställning
Följande frågeställningar ska besvaras i denna rapport.
1. Vilka fördelar och nackdelar finns det med att använda Kanban när
man använder sig av kontinuerlig prototypning?
2. Jämfört med andra agila utvecklingsmetodiker vad är fördelarna med
att använda Kanban i ett projekt där produktkraven ändrar på sig?
3. Vilka fördelar och nackdelar finns det med att använda Kanban när
man arbetar i ett litet projekt?
66
Eftersom detta projekt var av relativt litet storlek så ska bland annat storleken av projektet tas i beaktning vid diskussionen.
4.4
Avgränsningar
Vid diskussionen av frågeställningarna kommer endast erfarenheter från just
detta projekt samt erfarenheter och resultat från eventuella forskningsrapporter att användas.
4.5
Bakgrund
De traditionella utvecklingsmetodikerna, ibland kallade Heavyweight beskriver strikt processerna som ska användas vid utveckling. De agila utvecklingsmetodikerna försöker ändra dessa prioriteringar till mer fria och flexibla
metoder.
Den agila rörelsen har delvis sitt ursprung i den så kallade Agile Manifesto eller som den egentligen heter The Manifesto for Agile Software Development [24]. Denna publikation var resultatet av ett samarbete mellan
17 representanter från olika företag som samlades för att försöka skapa ett
gemensamt ramverk för denna typ av utvecklingsmetodiker [22, s. 16]. Vid
detta tillfälle skapades även den så kallade Agile Alliance [25] en global ideell organisation som har åtagit sig uppgiften att främja agila principer inom
mjukvaruindustrin.
En utvecklingsmetodik som har tagit inspiration från den agila tankesättet är Kanban [26, s. 28]. Kanban tar sitt ursprung i Toyotas produktionssystem och har anpassats till mjukvaruutveckling på den senaste tiden [2]. En
mer noggrann beskrivning av Kanban kan återfinnas i huvuddelen av denna
rapport under rubrik 2.3 - Kanban.
67
4.6
Teori
Kärnan i Kanban beskrivs av följande tre uppgifter [2]:
Visualisera arbetsflödet
Uppgifterna ska delas in i aktiviteter och placeras på den så kallade
Kanban-tavlan. Namngivna kolumner hjälper till att illustrera vart aktiviteter är i arbetsflödet.
Begränsa mängden aktiviteter i ett visst arbetssteg
Begränsa mängden aktiviteter som är i ett visst arbetssteg/kolumn på
Kanban-tavlan.
Mät ledtiden
Mät tiden det tar för aktiviteter att gå genom hela arbetsflödet. Målet
är sedan att minimera denna tid.
En viktig påpekning är att Kanban begränsar mängden arbete per utveckligssteg till skillnad från vissa andra utvecklingsmetodiker som begränsar
mängden arbete inom en iteration eller inom ett visst tidsintervall [3]. Denna skillnad tillåter Kanban att vara mer responsiv till eventuella ändringar i
produktkrav eftersom aktiviteter kan alltid prioriteras om innan utvecklingen
av dem har påbörjats.
4.7
Metod
Projektgruppen har haft minst ett möte per vecka där gruppens Kanbantavla sågs över och en statusuppdatering av gruppmedlemmarna gjordes.
Under dessa möten diskuterades eventuella ändringar till arbetsbegränsningarna på Kanban-tavlan och eventuella problem med arbetet togs upp. Dessa
möten har även givit en överblick över hur utvecklingen fortskridit.
Under dessa möten har observationer skrivits ner för att användas som
grund till denna rapport.
68
4.8
Resultat
I det här avsnittet läggs vårt arbete fram, sett från min synvinkel som arkitekt.
4.8.1
Fas 1
Eftersom gruppen inte hade någon bra bild på vad kunden egentligen var
intresserad av, gick mycket av arbetet i fas 1 ut på att skapa prototyper samt
evaluering av olika idéer angående hur produkten skulle kunna utformas.
På slutet av fas 1 så hade gruppen producerat en interaktiv prototyp
som presenterades för kund för att få återkoppling. Rent arkitekturmässigt
så skapades denna prototyp med så minimalt arbete som möjligt.
4.8.2
Fas 2
Under fas 2 så använde gruppen sig av återkopplingen från kunden för att
utöka den interaktiva prototypen med mer funktionalitet och förbättra existerande visualisering.
Eftersom arkitekturen av prototypen i fas 2 var fortfarande minimalt
definierad så påbörjades planeringen av en refaktorisering av all kod som
skulle ske under fas 3.
4.8.3
Fas 3
Under fas 3 så skrevs hela prototypen om och arkitekturen definierades tydligare. Gruppen gjorde detta för att göra den mer lättförståelig och enklare
att upprätthålla samt för att det skulle vara enklare utöka i framtiden.
I denna fas infördes även en back-end som var ansvarig för att tillgängliggöra verktyget från flera datorer. Denna back-end var även ansvarig att
konvertera kundens datafiler till ett format som kunde direkt användas av
klientsidan.
69
4.9
Diskussion
I det här avsnittet diskuteras resultatet och erfarenheter tas upp.
4.9.1
Resultat
Generellt gick projektet mycket bra och tack vare kontinuerlig prototypning
kunde gruppen testa produkten ofta och se till att funktionalitet var meningsfull och tydlig.
När man använder sig av Kanban och kontinuerlig prototypning kan det
vara en bra ide att definiera vilka aktiviteter som ska inkluderas i nästa
prototyp. Mängden aktiviteter som inkluderas till nästa prototyp kan variera
baserat hur ofta man har kontakten med kunden. Om kunden finns på plats
och kan testa varje ny funktionalitet så snart den är klar så kommer denna
lista att vara rätt så kort. Om detta inte är fallet så kommer extra planering
behövas, där man i samarbete med kunden bestämmer vilken funktionalitet
ska vara färdig till nästa prototyp. Detta kommer ge utseendet av iterationer
men med den stora fördelen är att iterationslängden inte måste vara strikt
definierat. Iterationslängden kan då till exempel sättas till tiden tills nästa
kundmöte.
Eftersom Kanban inte föreskriver något angående ändringar i produktkrav så betyder detta att aktiviteter kan i princip ändras fritt när som helst
så länge man inte bryter mot begränsningarna i något av arbetsstegen. Jämfört med de andra agila utvecklingsmetodikerna så leder detta till att Kanban
blir väldigt responsiv mot ändringar i produktkrav.
En svaghet av Kanban är att inga processer för utveckling eller testning
är definierade. Det är alltså helt upp till utvecklaren att skapa eller använda processer som passar organisationen eller projektet. Detta leder till att
utvecklare kombinerar Kanbans visualisering av arbetsflödet med delar av
andra mer definierade metoder och på så sätt får en mer definierad metodik.
En kombination av Kanban och till exempelvis XP (eXtreme Programming)
är till exempelvis en kombination som kan fungera bra för mjukvaruprojekt.
70
Lika som Kanban är XP också en agil utvecklingsmetodik, dock är XP mer
specificerad för just precis mjukvaruutveckling.
4.9.2
Metod
Projektgruppen har haft minst ett möte per vecka och dessa möten protokollfördes. Dessa protokoll innehöll information om framsteg och problem som
skett i utvecklingen sen senaste mötet.
Förutom att projektgruppen hade minst ett möte per vecka, så gjordes
en stor del kommunikation utanför mötestid. Denna typ av kommunikation
skrevs ofta inte ner då den ofta handlade om detaljer samt designval som
inte var tillräckligt viktiga för att tas upp med hela projektgruppen.
Detta val att hålla icke väsentliga ämnen utanför mötestider ledde till
att det fanns mer tid att diskutera arbetsprocessen under mötena. Detta
har tillåtit gruppen att se över eventuella problem i utvecklingen och vidta
lämpliga åtgärder mot dem.
Nackdelen med att denna typ av kommunikationen var att den inte protokollfördes. Detta ledde till att det i vissa fall uppstod problem i utvecklingen
eftersom inte alla gruppmedlemmar var informerade om ändringar som hade
skett.
Eftersom projektgruppen varit relativt liten så skadade inte den bristande kommunikationen slutresultatet. Skulle gruppen varit större så skulle
denna brist på kommunikation kunna ha lett till allvarligare problem. Det
kan därför vara en bra idé för större projektgrupper att definiera en process
för kommunikation av designval.
4.10
Slutsatser
Man kan tycka att den minimala definitionen av Kanban är en svaghet. Men
det är precis den minimala definitionen som är dess styrka. Tanken med
Kanban är inte att man bara ska använda det som är föreskrivet utan att
man ska utöka processen så den passar projektet/organisationen [2]. Man
kan tänka sig Kanban som en hörnsten till en utvecklingsmetodik som är
71
precis anpassad till projektet/organisationen. Vill man ha iterationer, så är
det bara att använda iterationer, vill man ha möten varje dag, så är det bara
att ha möten varje dag. Kanban begränsar inte projektet utan är ett verktyg
för att stärka planeringen.
Vilka fördelar och nackdelar finns det med att använda Kanban
när man använder sig av kontinuerlig prototypning?
Eftersom Kanban inte kräver någon form av iterationer kan detta leda till att
prototyperna inte är så tydligt definierade. Detta ger en frihet till utvecklarna
som både kan vara befriande men riskerar även att inte passa med kundens
förväntningar.
Jämfört med andra agila utvecklingsmetodiker vad är fördelarna
med att använda Kanban i ett projekt där produktkraven ändrar
på sig?
Om en utvecklingsmetodik har iterationer betyder det oftast att inga ändringar får göras till aktiviteter eller krav inom en påbörjad iteration, vilket
betyder att ändringar till aktiviteter eller krav kommer appliceras i början
på nästa iteration. Den största fördelen med Kanban när det gäller eventuella ändringar i produktkrav är att det inte finns något krav på iterationer.
Detta betyder att aktiviteter kan i princip omprioriteras fritt så länge arbetsbegränsningarna för arbetsflödet inte bryts.
Vilka fördelar och nackdelar finns det med att använda Kanban
när man arbetar i ett litet projekt?
En av de större fördelarna är att det är enkelt att använda och komma igång
med och kräver inte mycket förberedelsearbete innan det tas i bruk.
En nackdel med Kanban är att eftersom Kanban är så minimalt definierat
så finns det en risk att vissa arbetssteg som testning och distribution kommer
kräva extra förberedelser för att definiera processerna för dessa arbetssteg för
att underlätta vidare arbete.
72
Denna nackdel har mindre konsekvenser för små projektgrupper. Vid större projektgrupper skulle jag rekommendera att man ser över och kombinerar
Kanban med andra mer definierade metoder.
73
5
Oskar Lind: Kontinuerlig kravinsamling
5.1
Inledning
I kursen TDDD77 har grupp nummer 3 arbetat med att framställa ett visualiseringsverktyg åt webbläsarutvecklaren ”Opera Software”. Under projektets
början fanns det många stora frågetecken kring vad slutprodukten egentligen
skulle innehålla. Efter att gruppen valt Kanban som utvecklingsmetod fördes en kontinuerlig kommunikation genom hela projektet för att lyckas hålla
backloggen fylld.
I projekt där en agil utvecklingmetodik används så innebär det oftast att
kundens inverkan är stor genom hela projektet. Då varje ny del av projektet
kan resultera i nya önskemål och krav så finns risk att konflikter uppstår då
kraven som satts ej överensstämmer med båda parternas uppfattning.
Denna del kommer handla om kravinsamling och kravens roll i projekt
med agil utvecklingsmetod.
5.2
Syfte och mål
Beskriva, analysera och utvärdera den kravinsamlingsmetod som används
under projektets gång. Där till jämföra och dra paralleller till etablerade
kravinsamlingsmetoder genom att studera hur dessa används av näringslivet.
Det slutgiltiga målet är att samla analys- och kravinsamlingskunskaper
för att förbättra kravinsamlingsmetodiken i framtida liknande projekt.
5.3
Frågeställning
• Vilka kravinsamlingsmetoder har utbredning inom akademin?
• Hur används dessa i näringslivet och hur mycket frångås teorin?
• Vad är en lämplig kravinsamlingsmetod för ett liknande, framtida projekt?
74
• Hur säkerställs att båda parter blir nöjda med slutprodukten i ett agilt
projekt?
5.4
Ordlista
Backlogg – Annan benämning på arbetskö, frekvent förekomande i agila
områden
LEAN – En benämning som ges till arbetsmetoder vars syfte är effektivisering
Latens – Tiden för ett meddelande att skickas från klient till server
REPEAT – Requirements Engineering Process At Telelogic
RDEM – Requirement Driven Evolution Model
Svarstid – Latens plus tiden för servern att svara klienten
Vattenfallsmetoden – arbetsmetod [27]
Scrum – Agil utvecklingsmetod som bygger på ett intervallsystem med så
kallade sprints [27]
Kanban – Planeringsmetod som används i industri och utveckling för att
effektivisera arbetet [28]
5.5
Avgränsningar
För att kunna svara på frågeställningarna som angetts i stycke 5.3 kommer
följande delmoment att genomföras:
• Analys av kravinsamling och värdet av välformulerade krav i Scrum
och Kanban
• Analys av REPEAT
• Intervju med projektledare med analysansvar på ett mjukvaruföretag
75
5.6
5.6.1
Bakgrund
TDDD77 - Projektet
I kursen TDDD77 ingår ett moment som består av ett mjukvaruutvecklingsprojekt. I detta projekt ska grupper av varierande storlek, bestående av studenter vid Datatekniksprogrammet vid Linköpings universitet, på beställning
av en extern part utveckla en mjukvarulösning. Denna delrapport kommer
fokusera på kravinsamlingen i det projekt som utförts av grupp 3. Projektet
utfördes på beställning av Opera Software. Syfte var att ta fram en mjukvarulösning som visualiserade latens mellan länder och potentiella datacenter.
5.7
Teori
För att vara bekant med de termer som behövs för att besvara frågeställningen ges här beskrivningar av de aspekter som spelar en central roll i denna
del.
5.7.1
Kravhanteringsmetoder
Det finns många kravhanteringsmetoder som sedan tidigare är etablerade.
För att få en bättre kunskap av vilka alternativa teoretiska metoder som
finns beskrivs här två alternativ.
REPEAT
REPEAT bygger kring en kravhanteringsorganisation som består av flera olika grupper som uppfyller olika syften. Överst sitter kravhanteringsgruppen
som organiserar och administrerar de olika kraven. Under i hierarkin finns
kravgrupper vars uppgift är att analysera och specificera de olika kraven.
Dessutom finns grupper med testare, utvecklare samt olika typer av specialister för att utforma kraven än bättre.
De steg som ett krav går igenom är: New, Assigned, Classified, Selected
samt Applied. Om det någon gång under kravframtagninsprocessen kommer
76
fram att kravet ej fyller någon funktion, eller inte går att implementera, så
finns möjligheten att när som helst förkasta förslaget. [29]
RDEM
RDEM fokuserar på kvalitet hos de leveranser som kommer att ges och tiden
då de släpps är av mindre vikt. RDEM bygger på att kravinsamlingsansvaret
ligger hos en projektkommitté som består av personer både från utvecklingsteamet och beställaren.
Denna grupp tar varje förslag som inkommer till projektet och får detta
förslag att genomgå fyra olika stadier. Dessa stadier är: Captured, Specified,
Planed och Realized. De olika nivåerna beskriver hur långt ett krav kommer
om det accepteras som ett nytt produktkrav. Ett förslag på ett krav är heller
inte ett krav fören det nått den första nivån, Captured. I specified så specificeras och delas kravet upp för att lättare bearbetas för att slutligen i ett
planerat krav. Först när ett krav blir realiserat så börjar utvecklingsgruppen
med att utveckla det som utvecklingskommittéen sammanställt till ett krav.
Ett krav kan alltid backas i framtagningsprocessen. Däremot så kastas
aldrig ett krav, ett krav pausas endast realized steget om kravkommittéen
ser kravet som icke nödvändigt. [29]
5.8
Metod
För att bredda kunskapen om kravinsamling så har ett utbud med artiklar
av information- och analysegenskap studerats. Till stor del har så har fokus
legat på artiklar som handlar om olika kravinsamlingsmetoder, då främst om
REPEAT och RDEM.
Som en del i studien om kravinsamling så har även kontakt från ett externt
företag använts Den person som intervjuats via mail jobbar som projektledare
på ett företag som levererar mjukvarulösningar till en bred kundbas.
För att få erfarenhet från praktiken har ett projekt genomförts, innehållande en omfattande kravinsamlingsprocess.
77
5.9
Resultat
Här beskrivs de resultat som erhållits genom arbetet med denna rapport.
5.9.1
Intervjuer
Vid en intervju med en kontaktperson på mjukvaruföretaget Valtech så erhölls mycket information om hur kundkommunikation och kravarbete kan
fungera i verkligheten. Till stor del så sköttes kundkommunikation genom
en form av produktägare. Detta oavsett om arbetsmetoden helt baserats på
Scrum eller om det handlar om Kanban som kombinerats med Scrum [30].
All kommunikation kring vad produkten ska omfatta sker via en kanal och
det medför att riskerna för tvetydiga tolkningar av önskemål minskar. Även
om produktägaren i stora drag ofta bara förser utvecklingsgruppen med user
stories så finns en person från intressenternas sida med en förhoppningsvis
stor analysförmåga och teknisk kunnighet. På detta sätt kan kraven ofta specificeras och ibland utökas vid olika steg i utvecklingen av en produkt. [29]
I de fall att kunden känner att produkten uppfyller de krav som de har
så görs valet förmodligen att avsluta projektet. Vid projektavslutet så slutar
kunden att betala för nya sprints varpå kravinsamlingen från projektgruppens sida avslutas. Då en kund vanligtvis inte betalat för onödiga sprints så
avslutas i de flesta fall projekten när kunden slutar komma med nya önskemål. [29]
5.9.2
TDDD77 – kravinsamlingsprocess
I projektuppstarten började arbetet för gruppen med att välja projekt från
en mängd olika alternativ. Det alternativ som gruppen kom att välja blev ett
projekt riktat mot Opera Software.
Redan från början fick alla gruppdeltagare en egen mental bild av vad
som skulle göras. Beskrivningen i projektförslaget gav projektgruppen en idé
om ett optimeringsverktyg som nyttjade sig starkt av ett grafiskt gränssnitt.
Idéer om vilka optimeringsalgoritmer som skulle användas och hur en backend
78
som skulle klara av stora optimeringsproblem började skissas på.
När projektets första kundmöte bara en liten tid senare ägde rum blev
bilden en helt annan. De viktigaste kraven som stod i projektbeskrivningen
lyftes då inte alls längre fram som viktiga och en stor förvirring inom projektgruppen uppstod. För att reda ut vad kunden önskade skapades då ett
formulär för att projektgruppen skulle kunna identifiera i vilken riktning som
kunden ville styra projektet. Då det vid denna tid i projektet hade funnits
åsiktsskillnader mellan kund och projektgruppen så gjordes ett aktivt val att
vänta med konstruktion av kravspecifikation till det att en tydlig vision hade
arbetats fram.
När den första versionen av kravspecifikationen var färdig hade ett mål
diskuterats fram med kunden. Det tog däremot mycket mindre tid än det först
var beräknat att färdigställa de krav som kunden hade kommit med. Efter
ungefär halva projekttiden så hade projektgruppen en lösning som kunden
till mångt och mycket var nöjd med. Resultatet av detta blev på grund av
kursens examinationskrav en dialog med kunden om vilka fler funktioner som
kunden kunde tänka sig ha nytta av som höll på till projektets slut.
Genom hela projektet så har produktdemonstrationer för kunden skett.
Detta började genom att gruppen direkt efter formulärets färdigställande började med ett antal prototyper som löste det problem som kunden förklarat.
Dessa produktdemonstrationer både gav kunden en säkerhet då projektgruppens arbete blev lätt att följa och gjorde att kunden ofta fick komma med
egna nya idéer på hur produkten skulle kunna bli bättre. Prototypningen
hjälpte projektgruppen att kontra det problem som uppstod då kunden ej
hade några user stories.
Kravens målfunktion analyserades med hjälp av de olika stadierna för
krav som SEMAT alpha state cards beskriver [31].
5.10
Diskussion
Bra krav är A och O i alla projekt. En uppsättning med välformulerade krav
ger både kunden säkerhet i resultat och leverantören tydliga avgränsningar
79
för vad som ska utföras. I många sammanhang så sätts kraven till att vara
avklarade vid en specifik tidpunkt. I ett projekt som bygger på vattenfallsmetoden handlar det ofta om att kraven, som alla samlats in i början av
projektet, också alla ska vara avklarade vid slutet av projektet. Då förefaller
det i många fall också naturligt att endast ha en kravinsamling som sedan
revideras under projektets gång. I ett projekt med Scrum som arbetsmetod
handlar det om krav satta för varje enskild sprint. Dessa tas från en backlogg
som hela tiden kan fyllas på. Detta kan då ske genom en kontinuerlig kravinsamling. När Kanban kombineras med någon annan form av arbetsmetod
så kan det lätt uppstå frågor. När ska kravhantering ske? När ska den sluta?
När ska kraven vara färdigställda?
Då ett populärt sätt att arbeta med Kanban är att kombinera det med
Scrum så fås svaren på en gång då det i Scrum redan finns förutbestämt hur
kraven ska hanteras [30]. I de fall som andra projektstyrningsmetoder väljs
kan det däremot uppstå frågor om dessa metoder inte på förhand specificeras. Situationen med otydliga regler kring krav i projektstyrningen uppstod
under projektdelen i TDDD77. Detta tillsammans med en kund som förvisso
hade mycket god teknisk kompetens men däremot saknade erfarenhet som
beställare gav en kravsituation som var osäker. Lyckligtvis fanns goda möjligheter till vidare förhandlingar med kund under hela projektet. Även vid de
tillfällen då backloggen började tömmas så hade projektgruppen fria händer
till att själva tänka kreativt. Denna kreativitet mynnade ut i prototyper som
sedan visades för kund, godkändes eller avvisades och till sist blev föremål
för nya krav.
Den artikel som studerats mest ingående innefattar en jämförelse mellan REPEAT och RDEM. Denna jämförelse visar på många sätt att det
handlar om två väldigt lika kravbearbetningsmetoder. Den stora skillnaden
i slutändan är var utvecklingsgruppens fokus ligger. Ska produkten levereras
i tid oavsett kvalité eller huruvida är leveranstid mindre viktigt om slutprodukten blir så bra som möjligt. Vid granskning av de marknadsdrivna
kravinsamlingsmetoderna är REPEAT den metod som ligger närmst tillvä-
80
gagångssättet under projektet. Metoden har stor fokus på när leverans ska
planeras till. Projektet med Opera hade redan från början ett sistadatum.
När det kommer till projektrollerna som använts i hela projektet är det däremot RDEM som är den process som är mer lik. Då det i detta fall i stort
sett varit hela projektgruppen som varit med och tagit fram kraven. Oavsett
så har inte hela projektgruppen varit delaktig i kravframtagningen, något
som kan ha bidragit negativt sett till metodernas rekommenderade kravgruppsstruktur. Ytterligare en faktor som gör projektets kravhantering mer
lik RDEM är fokus på kvalité i slutprodukten. Då projektgruppen ej hade
krav på tidseffektivitet så låg mycket arbete på mervärde för kunden.
Då det på företaget Valtech är projektledaren som är i fokus när det
handlar om kravinsamling så finns här också olikheter. I projektet användes både analysansvarig och projektledare för att driva kommunikation med
kunden. I till exempel formulärsutformningen var till och med hela projektgruppen inbjudna till att vara en del av kommunikationen utan att ha någon
direkt mellanhand. Detta ledde till att personer med olika ansvarsposter fick
chansen att fråga kunden om det som de undrade om över projektet direkt.
Eftersom det skedde i början fick hela projektgruppen en tydligare bild om
projektets omfattning och inriktning istället för bara projektledaren.
Det blir tydligt att det finns en stor skillnad mellan de kravinsamlingsmetoder som studerats tillsammans med den som används och den som används
på Valtech. De metoder som studerats och den som använts använder sig av
projektgruppens frågvishet och kunskap för kravinsamligen på ett tydligt
sätt. Hos det studerade företaget verkar däremot kravinsamlingen vara mer
centraliserad till en specifik nyckelperson. Vilken roll de övriga projektmedlemmarna har är inte något som framkommit och är något som skulle kunna
studeras vidare.
Ytterligare en intressant aspekt är de olika nivåerna som både RDEM
och REPEAT använder för att beskriva hur mogna de funktioner som kraven beskriver är. Genom att dela upp utvecklingsfasen av en funktion blir
det tydligare när målet med arbetet är uppnått. I det utförda projektet så
81
har SEMAT alpha states använts för att kunna göra denna uppdelning men
uppföljningen har varit dålig. Detta gjorde att det blev svårt att få översikt
på utvecklingen av de olika funktionerna i vissa lägen och ett visst överarbete
ibland skedde. Genom att använda en mer etablerad kravinsamlingsmetod är
det möjligt att denna dokumentation kunde blivit bättre.
5.11
Slutsatser
När det kommer till kravinsamling så finns det många olika metoder som alla
är utformade för att fungera bra i olika arbetsgrupper och situationer. De
metoder som studerats i detta arbete, RDEM och REPEAT, är bara två sätt
att genomföra kravinsamlingen på. Då dessa är framtagna av företag inom
IT-branchen för 10-20 år sedan så är det svårt att avgöra vilken betydelse de
har i den akademiska världen.
När blicken vänds mot näringslivet så har fokus till stor del legat på företag med en verksamhet som liknar den i det utförda projektet. Här ligger
ofta Scrum till grund för mycket av arbetsmetoden oavsett om projektgruppen valt en egen tolkning. Vilken metod som ska användas beror till stor
del på vilken grupp och vilket projekt det handlar om. Vad som däremot
kan konstateras är att en process där kundens grundönskemål identifieras för
att sedan drivas framåt med prototyper har varit ett lyckat koncept i detta
projekt.
Det går aldrig att säkerställa att alla parter blir nöjda vid ett mjukvaruutvecklingsprojekt. Olika kunder har olika behov och det första en person
som är kund eller analysansvarig är att identifiera dessa redan innan avtal
skrivs mellan parterna. När väl ett avtal skrivs ska detta vara anpassat efter
arbetsmetod och på ett tydligt sätt beskriva hur krav ska hanteras.
82
6
Simon Eriksson: Implementation av interaktiv kartvisualisering med D3
6.1
Inledning
Denna individuella del behandlar hur en given design för en interaktiv visualisering som visar landsspecifik information på en världskarta med hjälp av
bubblor kan implementeras med hjälp av JavaScript-biblioteket D3, och hur
bra visualiseringsprogrammet blir inom funktionalitet respektive kodimplementation.
6.2
Syfte och mål
Syftet med denna delrapport är att ta reda på hur bra D3 fungerar för att
implementera avancerade kartvisualiseringar med landsspecifik data inom såväl funktionalitet som inom kodimplementation. Då visualiseringar av landsspecifik data är vanligt förekommande idag så kan denna delrapport hjälpa
utvecklare att välja tekniska lösningar för liknande projekt.
6.3
Frågeställning
• Vilka fördelar respektive nackdelar finns med att använda D3 för att
implementera en avancerad och interaktiv kartvisualisering som uppfyller en given bubbelbaserad design och dess funktionskrav?
• Lämpar sig D3 bra för att skapa effektiva och lättunderhållna implementationer?
6.4
Avgränsningar
Denna individuella del fokuserar på hur man kan implementera en tidigare
designad visualiseringsdesign och tar därför inte upp själva designprocessen.
Ej heller testas andra ramverk eller grafiska bibliotek som också kan användas
83
för visualisering. Det finns heller inga etiska aspekter eller liknande som man
kan ta hänsyn till.
6.5
Bakgrund
Opera Software behöver ett verktyg som kan hjälpa dem att planera och
bestämma var deras proxyservrar, som används för att minska svarstider till
webbplatser, ska placeras. Visualiseringen behöver visa svarstid samt antal
användare för varje land, man ska även kunna se varje datacenters svarstid för
ett specifikt land. För detta har en visualiseringsdesign baserad på bubblor
som visas ovanför länderna tagits fram av gruppen i samråd med Opera.
Applikationen måste vara funktionell och fungera för kunden samtidigt som
den är lätt att implementera och underhålla för utvecklarna.
6.6
Teori
D3 är ett JavaScript-bibliotek för att skapa interaktiva och avancerade datavisualiseringar i webbapplikationer. D3 grundfilosofi är att underlätta databaserade dokumentmanipuleringar samt vara flexibelt och integrera väl med
DOM och vanliga webbstandarder som exempelvis HTML, CSS och SVG.
Grundmodellen i D3 bygger på väljare (selectors), operatorer (operators),
datajoins och events. Med väljare väljer man ut element från DOM enligt vissa kriterier för manipulering som man sedan kan manipulera med operatorer.
Med datajoins binder man JavaScript-data till en grupp av element, där man
även kan använda de speciella väljarfunktionerna enter och exit, enter för att
hämta ingående data samt exit för att hämta utgående element. D3 kan
binda events till element som gör saker med applikationen när användaren
interagerar med element på ett visst sätt, exempelvis hover eller musklick.
Vid dokumentmanipuleringar har D3 stöd för övergångar som kan användas för animeringar mellan olika lägen. D3 har även inbyggda moduler för att
underlätta vanliga operationer, som exempelvis färgskalor, layoutplaceringar, utritning av vektorelement och parsning av dataformat som exempelvis
84
datum och CSV.[32]
D3 har stöd för att hantera TopoJSON och GeoJSON, som är JSONbaserade dataformat för att definiera kartdata i vektorformat inklusive metadata som namn, landskoder och dylikt. D3 har även flertalet kartrelaterade
hjälpfunktioner, bland annat hanterande av kartprojektioner. Man kan implementera egna kartprojektioner men det finns även inbyggda metoder som
exempelvis Mercator. Genom att läsa kartfilerna kan man hämta ut ländernas former och placeringar som sedan kan projiceras och renderas med hjälp
av vektorformatet SVG. [33]
6.7
Metod
Under projektet användes D3 för att utveckla en webbapplikation för kartvisualisering. Under projektets gång bedömdes det hur väl biblioteket fungerade för projektet samt vilka fördelar och brister som fanns. Följande kriterier
bedömdes:
• Hur smidigt fungerar D3 och dess programmeringsmodell för att implementera en viss funktionalitet?
• Hur lättläslig och begriplig blir koden?
Visualiseringens design var en världskarta med bubblor som visas ovanför
länderna, där färgen indikerar minsta latensen mellan landet och ett datacenter och bubblans radie indikerar antalet användare i landet. Datacentren
är placerade på kartan med en kvadratisk ikon, när man klickar på den avaktiveras datacentret. Det finns även en sidebar som listar datacentrerna
samt latenssiffror för varje datacenter i ett individuellt land om användaren
klickat på landets bubbla, även härifrån kan man aktivera eller inaktivera datacentren. När datacentren aktiveras eller avaktiveras räknas minsta latensen
om och färgerna i bubblorna uppdateras.
85
6.8
Resultat
I detta avsnitt diskuteras hur D3 användes under projektet.
6.8.1
Första fasen med Datamaps
Inledningsvis använde vi oss av biblioteket Datamaps, som är ett färdigt
bibliotek för att rita kartor och bubblor med hjälp av D3, på så vis hoppades
vi slippa att själva implementera koden för att rita kartan.
Inledningsvis provade vi att göra bubblorna med hjälp av Datamaps inbyggda bubbelstöd, det visade sig dock vara alltför begränsat då man inte
kunde ge bubblor individuella färger på ett smidigt sätt. I stället gjorde vi
ett eget plugin till Datamaps som ritar bubblor med hjälp av D3 som var
anpassat för bubblor med individuella färger och storlekar. Vi lade därefter
till olika funktioner i vår plugin, som exempelvis en informationsruta som
visas när muspekaren är över bubblan.
Ett problem med Datamaps var att standardkartan saknade många mindre länder, varav många av dessa behövdes. Därför genererade vi en ny karta
i TopoJSON och ersatte standardkartan med den nya. Vi bytte också ut
standardprojektionskoden i Datamaps mot en egen implementerad i D3.
Med tiden blev fler och fler funktioner i Datamaps utbytta mot egna implementationer, och till slut byttes Datamaps ut helt mot egenimplementerad
kartkod med D3, vilken ledde till renare kod med färre beroenden.
6.8.2
Övergripande funktioner
Vid starten laddas all relevant data in från JSON-filer med hjälp av D3:s
inbyggda asynkrona JSON-inläsningsfunktion. För att göra koden modulär
och lättunderhållen är JavaScript-koden uppdelad i ett flertal klasser, där
varje typ av objekt på kartan har en egen klass. Då vi har valt en responsiv
design där kartan anpassar sin storlek efter fönstret, och det inte finns något inbyggt stöd för att hantera detta så måste alla SVG-element manuellt
ändras vid storleksändring. Detta görs genom att ett event som körs vid stor86
leksändring anropar klassernas egna storleksfunktioner, som manuellt räknar
om storleken på alla objekt och uppdaterar.
Kartdatan hämtades från Natural Earth Data och konverterades sedan
till TopoJSON. För att få en karta som både hade Franska Guyana och länder
som Storbritannien och Belgien enade i stället för delade i flera delar fick vi
göra ett särskilt skript som satte ihop vissa länderna genom att kopiera och
modifiera kod från TopoJSON-konverteraren.
Ett problem som fanns sedan den nya kartdatan nu var att applikationen
var alltför seg, det kunde åtgärdas genom att förenkla linjerna i kartdatan
med hjälp av TopoJSON-generatorn.
6.8.3
Världskartan
För att skapa själva världskartan läggs först SVG-elementet och sedan en
SVG-grupp för kartan till med hjälp av D3:s urval och operatorer vid starten
av applikationen. Vid laddningen av sidan laddas först data från kartfilen
med hjälp av TopoJSON-biblioteket, samtidigt filtreras även Antarktis bort
från datan med hjälp av JavaScript:s inbyggda filter-funktion. Sedan läggs
länderna till i kartan med hjälp av databindning i form av SVG-pathelement
som hämtar sin form från en vektorpath. För att kunna rita länderna på en
tvådimensionell yta behöver path:en avbildas med en kartprojektion innan
den ritas upp, vilket vi gjorde med hjälp av D3:s inbyggda funktioner för
Mercatorprojektionen. För att D3:s projektionsfunktioner ska kunna användas behöver utvecklaren dock själv specificera skalningen och translationen
för att kartan inte ska ha fel storlek eller gå utanför SVG-ytan.
6.8.4
Bubblorna
Bubblorna har likt världskartan också ett eget SVG-lager. För att se till
så att små bubblor ritas ovanpå de stora så måste länderna sorteras efter
antalet användare innan de ritas upp, vilket kan göras med sort-funktionen
i JavaScript. När länderna är sorterade skapas en lista med relevant data
om länderna som sedan databinds, där cirklar med korrekt storlek och färg
87
läggs till i det nya SVG-lagret. Varje bubbla har också ett dataattribut med
landskoden för att lätt kunna hittas av andra funktioner. Mittpunkten hämtas från landets form och D3:s funktion för att beräkna mittpunkten på en
form. Eftersom olika händelser ska inträffa när man klickar på eller har musen
över bubblan så läggs även events till för bubblorna när de skapas.
När datacentren aktiveras eller inaktiveras körs en funktion som uppdaterar färgerna genom att hämta alla bubblor med väljare och för var och en
räknar om minsta latenser och uppdaterar färgen med operatorer, i det här
fallet används ej databindning.
När man har muspekaren över ett datacenter i sidebaren så går bubbelfärgerna över till ett särskilt differensläge som visas hur det landet påverkas
om datacentret aktiveras eller avaktiveras. Om tiden blir bättre blir bubblan
grön, om den blir sämre så blir bubblan röd, annars blir den vit. Ju större
skillnaden är desto starkare blir färgen. Uppdateringen fungerar på liknande
sätt som vid uppdateringar i det vanliga läget, skillnaden för varje bubbla
räknas ut och sedan uppdateras färgen.
D3:s funktioner för att skapa skalor användes för att ta fram skalfunktionen som beräknar bubblans storlek samt skalfunktionen som beräknar
bubbelfärgen för en viss svarstid.
När muspekaren är ovanför visas en popupbubbla med landets namn och
flagga samt användarantal och lägsta svarstid. Själva popuprutan är implementerad med en egen klass som huvudsakligen använder jQuery för att välja
och manipulera objekt.
6.8.5
Datacenter
Vid kartuppritning ritas datacentrerna upp på kartan med hjälp av D3, även
här används databindning för att lägga SVG-element med rätt position och
data för varje datacenter. Förutom position och hårdkodad storlek så läggs
även events till. Förutom events för popuprutan så finns även ett event till
som aktiverar eller inaktiverar popuprutan när användaren klickar på datacentret. Koordinaterna måste avbildas med en kartprojektion innan den ritas
88
upp för att de ska hamna på rätt ställe, här återanvänds naturligtvis den som
används för världskartan.
För att tydligare visualisera vilka datacenter som är bäst för ett visst land
så ritas bågar mellan de tre bästa datacentren och landets bubbla när upp
landet är aktiverat. Dessa är implementerade genom att skapa en array med
ett objekt för varje båge som sedan databinds. Databindningen tar linjen
mellan bubblans mittpunkt och det aktuella datacentret och avbildar den
med hjälp av världskartans kartprojektion så att den slutliga formen blir en
båge. D3:s stöd för övergångar används här för att skapa en animering där
bågen gradvis ritas ut.
6.8.6
Sidebar
Sidebarkoden manipulerar inte direkt själva kartan och använder huvudsakligen jQuery, huvudsakligen för att den behöver använda jQuery-pluginet
MixItUp som sorterar datacentrerna på listan efter svarstid, och koden försöker att blanda jQuery och D3 så lite som möjligt i samma klass.
6.8.7
Statistik
I slutfasen gjordes även en separat statistikvy som visar cirkeldiagram över
andelen användare i världen med en viss svarstid. Även för detta användes D3,
bland annat dess inbyggda funktioner för att rita cirkelsektorer och cirkeldiagram. Även denna data uppdateras när man aktiverar eller inaktiverar
datacenter. Eftersom detta inte strikt har med kartvisualiseringen att göra
utelämnas detaljerna.
6.9
Diskussion
I detta avsnitt diskuteras hur bra D3 fungerade för projektet samt hur bra
metoden fungerade.
89
6.9.1
Resultat
Kartimplementationen kunde framgångsrikt och på ett förhållandevis enkelt
sätt implementeras med hjälp av D3 och TopoJSON, inklusive avancerad interaktiv funktionalitet. D3 hade många funktioner som var till stor hjälp och
förenklade utvecklingsarbetet markant, bland annat funktionerna för kartritande och projektion, databindningsmodellen för att rita objekt, funktionerna för asynkron JSON-inladdning, diagramfunktionerna samt förstås även de
mer basala delarna som väljare och operatorer. Den resulterande D3-koden
var också förhållandevis lätt att förstå och underhålla.
För vissa mer avancerade väljaroperationer kändes D3 otillräckligt eller mer klumpigt, och jQuery användes i stället som tillägg. D3-modellen
kunde vara svår att förstå till en början och följdes inte alltid helt, bland
annat användes ofta jQuery när D3 hade fungerat eller loopar i stället för
databindningsfunktionerna, som är mer idiomatisk och korrekt D3-kod. Mer
fördjupning inom D3 och dess programmeringsmodell innan kodskrivandet
hade varit bra för samtliga utvecklande gruppmedlemmar.
En annan svårighet var att det svårt att få ut exakt den kartinformation
vi ville ha från Natural Earth Data, ett exempel är att vi ville ha Franska
Guyana och Frankrike som separata länder men i några av detillgängliga
datamängderna så var de enade och i andra så var flertalet länder splittrade
i diverse delar som var irrelevanta. Problemet kunde slut fixas med hjälp
av ett eget TopoJSON-genereringsskript som manuellt slog ihop specifika
landsdelar för vissa länder.
6.9.2
Metod
Att utvärdera D3 genom att faktiskt använda det i en praktiskt projekt har
känt som en bra lösning. Däremot hade det varit bra med en mer formell
metod för att kvantifiera hur bra D3 fungerar i projektet. Det hade även
varit bra att anteckna och sammanställa löpande i stället för att göra det i
slutfasen.
90
6.10
Slutsatser
Slutsatsen av arbetet och analysen är att D3 kan användas för att förhållandevis enkelt implementera kraftfulla och funktionella interaktiva kartvisualiseringar, själva programmeringsmodellen kan dock vara svår att sätta sig in
i och det rekommenderas att man fördjupar sig in i den innan man utvecklar
applikationen. För vissa mer avancerade operationer kan även jQuery behövas. Man får även vara förberedd på att inhämtningen och genereringen av
kartdata kan vara komplicerat.
91
7
Simon Petersson: Kvalitetssäkring och inspektioner
7.1
Inledning
Att utveckla en produkt som uppfyller kundens krav lyckas inte alltid, vilket
kan bero på flera anledningar. Ofta beror det på att produkten inte utvärderats under projektets gång utan endast i slutet, då kritiska problem blir
svårare att åtgärda.
Denna individuella del behandlar kvalitetssäkring och inspektioner för
”Visualisering av svarstider mellan mobila klienter och datacenter” som utförs
i kursen TDDD77 vid Linköpings universitet. Här beskrivs meningen bakom
kvalitetssäkringen och varför den utförs samt projektgruppens metoder för
att uppfylla kraven.
7.2
Syfte och mål
Syftet med att utföra inspektioner var att säkerställa att projektet följde
en viss standard och att detta i slutändan skulle underlätta slutförandet av
projektet. En kvalitetssäkring helt enkelt, där det slutgiltiga målet var att
projektets alla parter skulle bli nöjda.
Syftet med denna rapport är att undersöka hur kvalitet uppnås och hur
man ska arbeta för att uppnå detta. För att uppnå kvalitet låg fokus på
enklare inspektioner av kod och dokument. Målet med inspektionerna var
att de krav som specificerats skulle uppfyllas samtidigt som problem med
kravmotsägelser i slutet skulle minimeras.
7.3
Frågeställning
Man kan inte i förväg veta att ett projekt kommer lyckas. Man kan ha en
bra projektplan, kvalitetsplan, riskhantering, samt en välmotiverad projektgrupp och en kund som vill ha ett projekt utfört. Detta garanterar inte att
92
projektet kommer lyckas och att projektgruppen kommer uppfylla de förbestämda målen. Här kan kvalitetsstyrning användas för att med olika metoder
säkerställa att den slutgiltiga produkten uppfyller kraven.
Här nedan följer frågeställningar som behandlas i rapporten.
• Hur påverkar inspektioner? Blir det bättre eller sämre i slutändan?
• Vilken tid är rimligt att lägga på kvalitetsarbete?
• Vem har huvudansvar för att projektet håller en god kvalitet?
7.4
Avgränsningar
Då kvalitet är både tidskrävande och dyrt förenklades vissa delar av kvalitetsarbetet i projektet. Vissa metoder förenklades och utfördes av enstaka
personer vid enstaka tillfällen, då projektgruppen inte kunde avsätta alltför
stora resurser på kvalitetsarbete då projektet hade begränsat antal timmar
för färdigställande. Enligt projektets kvalitetsplan planerade gruppen ungefär 4-5 timmar varje vecka till kvalitetsarbete, där den största portionen av
tiden skulle fyllas av kvalitetssamordnaren.
7.5
Bakgrund
En vanlig orsak till att ett projekt misslyckas är dålig planering [34]. Här
behövs ofta en god planering med tydliga ramar för vad som ska göras och
när. Andra orsaker till att ett projekt inte lyckas är att det inte uppfyller de
förbestämda kraven [34]. Denna del är vad som behandlas i denna rapport,
där målet ligger i att förbättra förutsättningarna till att projektet ska lyckas
och att minimera oönskade konsekvenser i slutet av projektet.
7.6
Teori
Nedan följer en beskrivning av relevant teori för rapportens frågeställningar
med förklaring av inspektioner och ordet kvalitet.
93
7.6.1
Inspektioner
Under projektets utfördes mindre inspektioner av kvalitetssamordnaren. Detta för att ge en bild över hur utvecklingsarbetet låg till samt för att utvärdera
kod som skrivits.
Nedan följer en beskrivning av checklistan som användes vid inspektioner för koden. Checklistan följer en enkel tabellform och består av ett antal
punkter som behandlades och antecknades vid inspektioner.
Tabell 1: Checklista vid inspektioner.
Datum
Utförare
Område
Filer
Problem som observerats / Kodfel
Åtgärd
Kravkoppling
Område innebär den funktionalitet som granskades och är en kort beskrivning av vilken del som inspektionen behandlade. Filer innebär de kod-filer
som granskades. Problem / Kodfel är buggar eller allmänna problem som
observerades. Åtgärd innebär sätt som direkt var applicerbara för att lösa
problemet, ofta för mindre buggar. Kravkoppling innebär en bild över kopplingen till kraven som fanns, dvs fanns det några motsägelser eller följde
produkten kraven.
7.6.2
Kvalitetsbegrepp
Anders Weinoff och Emelie Wirström författare till ”Vägen till ett lyckat ITprojekt” beskriver Nordqvist syn på styrning av ett projekt med hjälp av
tre faktorer. Dessa faktorer är tid, kostnad och kvalitet som förhåller sig till
varandra enligt följande: Pris, mängd och tid ger kostnad. Mängden beror på
funktionell standard, vilket ger kvantitet och sist kvalitet som ges av priset
av teknisk lösning [35]. Att öka kvalitet medför således att kostnaden och
94
tiden ökar.
Nedan visas en figur som Anders och Emelie tar upp. Denna figur skapades av Mats Engwall för att pedagogiskt beskriva åtagandetriangeln som en
uppspänning mellan funktionalitet, tid och kostnad [35].
Figur 9: Åtagandetriangel
Figur 9 ger en bild av att dessa faktorer är beroende av varandra och
att öka kvalitet påverkar på alla faktorer. Hur mycket kvalitet får kosta blir
en balans av hur mycket tid och pengar utvecklarna är villiga att lägga på
kvalitetsarbete, då det både är kostsamt och tidskrävande.
Begreppet kvalitet är ett mångsidigt begrepp som ofta måste betraktas
ur flera perspektiv för att ge en heltäckande bild. Kvalitet på kod syftar inte
bara till hur många buggar som finns utan också kodens portabilitet, återanvändbarhet, integrerbarhet och effektivitet. Det finns även andra faktorer
som kodens underhåll och testbarhet som spelar in.
7.7
Metod
Projektgruppen använde sig av granskningar av dokument som utfördes enligt kvalitetsplanen, där huvudtanken låg i att fler än bara författaren skulle
granska dokumenten och ge synpunkter innan dokumentet ansågs vara godkänt för redigering till finare format i LaTeX. Här fördes ett nära samarbete
med dokumentansvarig.
95
Projektgruppen har använt sig av inspektioner där kvalitetssamordnaren
gått igenom koden och dess funktionalitet för att säkerställa överensstämmelse med kraven och i nödvändiga fall se till att saker testas och dokumenteras.
Testningen utfördes av testledaren som hade huvudansvar för testning.
7.8
Resultat
Under projektets tidiga faser genomfördes endast ett fåtal inspektioner för
granskning av kod, då projektgruppen till största del arbetade med prototyper. När prototyparbetet var klart och projektet gick in i en mer produktiv
fas påbörjades kvalitetsarbetet mer intensivt.
7.8.1
Granskning av dokument
Under hela projektet utfördes flera granskningar av de producerade dokumenten. Här var alla gruppens medlemmar delaktiga i att granska och korrekturläsa allt som skrevs, där huvudansvar i uppföljning och slutgiltigt ansvar
togs av kvalitetssamordnaren med hjälp av dokumentansvarig som ansvarade
för själva dokumenten.
Granskning av dokument följde inte någon standard för granskning eller
uppföljning. Istället var projektledaren drivande med att alla skulle läsa igenom det som skrevs för att rätta språkliga fel. Gruppens alla medlemmar tog
ansvar för granskning av dokument och gruppen använde sig av Google docs
för skrivandet, där förslags-läget med god nytta användes för att kunna ge
förslag på förändringar i texten jämfört med nuvarande version. Dokumentansvarig ansvarade sedan för att godkänna förslag och modifiera LaTeX-filer
för finare formatering till alla dokument.
7.8.2
Inspektioner av kod
De inspektioner som utfördes bidrog till att många småfel effektivt kunde
hittas. Inspektionerna var samtidigt bakgrunden till flera diskussioner som
ledde till omstruktureringar för att förbättra koden uppbyggnad. Majoriteten
96
av inspektionerna som utfördes var riktade mot specifika funktionaliteter i
koden, som exempelvis bubblor, datacenter eller sidebar, där uppskattningsvis ett par hundra rader kod tillhörande denna funktionalitet granskades vid
inspektionen. I genomsnitt dokumenterades 2-3 småfel vid varje inspektion
samt ofta ett par förbättringsförslag på koden, exempelvis för att koden skulle
bli mer generell eller för att förbättra kodens prestanda.
Totalt granskades stora delar av koden, där ny funktionalitet som implementerades hade högre prioritet jämfört med förbättringar och utökningar
av tidigare funktionalitet, som då inte granskades lika ingående. Nedan följer
en sammanställning av några relevanta delar från kodinspektionerna:
Ett problem som observerades efter att Popup-rutor implementerades var
att dess position skilde sig mellan olika webbläsare. Detta trodde gruppen
berodde på kompatibilitetsproblem för multipla webbläsare, men det visade
sig efter kodinspektion att det var ett enkelt fel där pixlar användes istället
för procent på två ställen i CSS-koden. Under samma tid observerades även
att många länders bubblor saknades, vilket visade sig bero på att kartbiblioteket som då användes inte var tillräckligt noggrant och många små länder
saknades. Detta låg till grund för den nya kartan som då börjades skapas,
där en person i gruppen började arbeta med en karta anpassad efter den data
som gruppen hade. Då bubbelkoden inspekterades valde gruppen även att
byta till en inbyggd funktion för att bestämma länders mittpunkt, istället
för den dåvarande externa datafilen.
Det utfördes även en noggrann inspektion av sidebaren då gruppen observerat att den inte fungerade korrekt. Vid inspektionen observerades även att
länder sorterades felaktigt, vilket berodde på att sorteringen inte tog hänsyn
till decimaler. Det fanns även problem med att länder som hade oändligt
svarstid inte hamnade sist vid sortering.
7.8.3
Allmänt om kodinspektioner
Efter en tids arbete observerades att det fanns problem med läsbarheten
i koden, speciellt för personer som inte var insatta i vissa delar av koden.
97
Detta ledde till en stor omstrukturering av all CSS- och JavaScript-kod, som
flyttades ut till egna filer och strukturerade upp för att öka läsbarheten. Det
skapades även flera init-funktioner för olika delar av koden.
I senare delar av projektet när produkten började bli klar utfördes även
inspektioner för att kontrollera produktens prestanda, då vissa medlemmar
observerat att den var långsam på att uppdatera färger i webbläsaren Firefox
vid aktivering och inaktivering av datacenter. Vid inspektionen observerades
att uppdateringen av bubblors färg var ineffektiv, då programmet sorterade
alla datacenter för varje land varje gång ett datacenter aktiverades eller inaktiverades. Under inspektionen observerades samtidigt att bubblorna inte
fungerade för Windows-användare, detta var i samband med att back-end
hade införts. Då konverteringen till JSON data på back-end kontrollerades
visades sig problemet bero på att Windows använder en annan separator för
radbrytning vilket gjorde att ”\r” lades till på slutet av alla värden för svarstider och användarantal, vilket orsakade att det blev NaN-värden på all data
efter konverteringen.
7.9
Diskussion
Att granska och utvärdera allt som skrivs är nödvändigt för att få projektmedlemmarna delaktiga i projektets alla delar. Projektmedlemmarna får då
möjligheten att påverka utvecklingsarbetet och samtidigt hjälper det till att
minimera språkfel.
Detta var framför allt viktigt vid skrivandet av projektets kravspecifikation och arkitektplan där stora delar av gruppen hade starka synpunkter
på hur saker skulle implementeras och vilka krav som skulle sättas. Detta
leder till rekommendationen att alla ska gå igenom kraven innan huvudarbetet påbörjas för att minimera oklarheter eller att några krav blir felaktigt
formulerade, vilket skulle kunna påverka projektets utgång.
En orsak till att dålig kvalitet uppstår kan vara att programmerarna hoppar direkt in i utvecklingsarbetet, utan att genomgå förarbetet med analys
och design [36]. Detta är något som kan kopplas till vårt projekt där vi ti98
digt känt att vi vill hoppa in i utvecklingsarbetet så snart som möjligt och
från början inte ansett att planeringsarbetet är viktigt. Men efterhand i projektet har gruppen börjat inse att planeringen både hjälper för kvalitet i
utförandet samt för att effektivisera utvecklingsarbetet. Såklart skulle en del
planeringsarbete kunna skippas om de som utvecklar produkten är väldigt erfarna programmerare och har stor kunskap inom området och gjort liknande
saker tidigare.
Sara Eliason och Jenny Karnehed författare till ”Systemutveckling - en
modell för verifiering och validering” menar att många utvecklare har uppfattningen att kvalitet är något som skapas hos en programvara i slutet av
arbetet när testningen utförs. Här menar de istället att kvalitet förbättras
av testningen men det garanterar inte att ett felfritt program levereras till
kunden, utan kvalitetsarbete är något som måste utföras kontinuerligt. De
anser även att ett projekt bör ha väl genomtänkta verifierings- och valideringsaktiviteter från början för att uppnå kvalitet [36]. I efterhand anser jag
personligen att jag kunde satt upp lite mer tydliga ramar för kvalitetsarbete
och försökt få fler involverade i detta arbete.
”De största felen ligger alltid i kravspecifikationen, inte i koden - Lidfeldt
1998” [36]. Personligen anser jag att detta inte är helt sant, men det är ett
intressant citat och det visar att kravspecifikationen till stor del speglar det
arbete som utförs och är kraven felformulerad från början, finns det stor risk
att problem uppstår i utvecklingsarbetet.
Nedan följer ett diagram som Sara och Jenny presenterar angående hur
korrigeringen av kravfel kostar beroende på när den utförs [36].
Även om detta givetvis är en uppskattning får man ändå en tydlig indikering på hur stor påverkan kraven har på kvalitet i slutet av ett projekt. Vilket
gör det enkelt att dra slutsatsen att kraven ska vara korrekta från början i
så stor utsträckning som möjligt.
99
Figur 10: Diagram över kostnaden i antalet persontimmar beror på när ett
krav korrigeras.
7.9.1
Resultat
För att reflektera över resultatet så har flera erfarenheter kunnat erhållits från
planeringsarbetet. Ofta märks problem inte i början av ett projektet. Ibland
uppstår små problem som sakta växer tills de blir allvarliga och inte längre
kan ignoreras. Med detta menas att det är bra att planera noga innan arbetet
påbörjas och se över alternativ och hur ens lösning kommer att påverka andra
delar av systemet.
I vissa fall har vi inom gruppen märkt att lite bättre planering från början skulle uppskattats. Detta för att minimera ändringar i slutet när gruppen
kommit till insikt med saker som behöver förändras för att de inte fungerar
tillsammans. I det stora hela var planeringen av metoder och ramverk som
använts bra, men det skulle kunna ha dokumenterats och diskuteras lite mer
om hur saker kommer fungera tillsammans. Det tydligaste exemplet är genererandet av kartan, där många modifieringar utfördes efterhand då problem
uppstod. Det första problemet som uppstod var att länder saknades, då kartan inte var tillräckligt noggrann. Ett annat problem uppstod då gruppen
bytte standard för landskoder, vilket i slutet blev problematiskt då det fanns
krav på uppdelning av större länder till regioner. Problemet med standarden
som då användes var att den inte hade beteckningar för regioner, vilket visar
på att gruppen borde planerat bättre från början och kontrollerat kraven
mer noggrant för att undvika problem i slutet.
100
7.9.2
Metod
Kvalitetssamordnaren har ansvarat och utfört inspektioner. För inspektioner
har en enkel modell använts, där den grafiska delen granskats efter småfel
eller buggar, därefter följt av en granskning av koden, efter eventuella syntaxfel, motsägelser med kodstandard eller allmänna problem. Samtidigt har
metoder och funktioner i koden utvärderats för att avgöra dess kompatibilitet, hur generella de är och hur de kommer fungera i framtiden, för att
exempelvis kunna byta ut kartan på ett enkelt sätt. Som exempel kan det
nämnas att gruppen valde att använda en inbyggd funktion i kartbiblioteket
för att räkna ut mittpunkten av länder istället för en separat datafil. Detta
för att minimera arbetet för kunden i framtiden, så endast kartan behövs
uppdateras.
För att förbättra kvalitetsarbetet borde bättre uppföljning använts, då
inspektioner utförts av en person och problem eller liknande som observerats
har fixats av kvalitetssamordnaren och i vissa fall bara lätt diskuterats med
berörda personer. Här vill man ha en vidare diskussion med gruppens medlemmar och gå igenom problemen och se till att de åtgärdas och ha en bättre
uppföljning för att säkerställa att åtgärderna har utförts och att problemet
är löst.
En bra metod som gruppen använde sig av i senare delar av projektet var
att buggar eller saker som inte fungerades lades till som en aktivitet i projektplaneringsverktyget Redmine, vilket förenklade processen att rapportera
fel som observerats. Aktiviteter skapades då med instruktioner för när buggen uppstod och vem i gruppen som tilldelats uppgiften att lösa problemet,
vilket bidrog till att buggar åtgärdades väldigt snabbt och effektivt.
För att sammanfatta inspektioner så har dessa varit ett utmärkt sätt
att kontrollera både kod och dokument som skrivits. För kod behövs ofta
en lite mer strukturerad metod medan för dokumenten fungerar det bra att
korrekturläsa dokument och ge förslag på förändringar. Kodinspektionerna
har bidragit med att förbättra koden som skrivits. De har fungerat mycket
bra för att hitta mindre fel som bland annat kompatibilitetsproblem och för
101
att snabbt kunna rapportera åtgärder, men även för större saker som lett
till omstruktureringar av koden. Den aspekten som ofta ses som negativ med
inspektioner är att de är tidskrävande och bidrar inte till någon markant
förbättring. Detta har inte varit fallet i vårt projekt, då inspektionerna som
utförts varit av det enklare slaget och har inte varit lika formella som för ett
multinationellt företag.
7.10
Slutsatser
För att sammanfatta och dra slutfattande erfarenheter av projektets kvalitetsarbete kan tidsfaktorn nämnas som den avgörande faktorn. Denna speglar
ofta tillsammans med pengar, vilket i vårt fall inte var en faktor, hur mycket
tid en grupp kan lägga på kvalitetsarbete.
Inspektioner har endast utförts av en person som haft huvudansvar för
allt. Här skulle i efterhand en bredare spridning som involverar flera personer varit uppskattad. Dock har gruppen inte kunnat avsätta allt för mycket
resurser på detta då många andra aktiviteter samtidigt har varit viktiga och
behövt uppmärksamhet. Buggrapporteringsverktyget i Redmine har i projektets senare delar varit ett bra sätt att rapportera in buggar och har medfört
att problem snabbt blivit åtgärdade.
Den avsatta tiden för kvalitetsarbete var bra uppskattad och var tillräckligt stor för en person av använda för kvalitetsarbete. Om fler personer
skulle hållit på med kontinuerligt kvalitetsarbete skulle lite mer tid behövts
avsättas. Sedan så har vårt projekt inte haft alltför stor arbetsbörda på utvecklingsarbetet så kvalitetsarbetet har varit ett bra sätt för att se till att
arbetet blir så bra som möjligt och att så många småfel som möjligt elimineras. I det stora hela har inspektionerna varit uppskattade och bidragit till
bra diskussioner över hur vi ska utveckla produkten vidare för att förbättra
användarupplevelsen.
För att återkoppla till frågeställningen angående vem som har huvudansvar för projektets kvalitet så är det enkla svaret alla. Givetvis är det rekommenderat att minst en person har huvudansvaret för uppföljningen och
102
agerar som drivande kraft för att få folk engagerade, men om man vill uppnå
bra kvalitet inom rimlig tid är det bra om alla försöker att engagera sig. Man
kan inte alltid skriva bra fungerade kod direkt utan det kräver erfarenhet och
träning. Att få återkoppling på kod och diskutera problem med någon annan
är ett av de bästa sätten att utvecklas.
103
Referenser
[1] Opera Software. Om - Opera Software. http://www.opera.com/sv/
about. [Online; hämtad den 14 april 2015].
[2] Crisp. Kanban. https://crisp.se/gratis-material-och-guider/
kanban. [Online; hämtad den 14 april 2015].
[3] Henrik Kniberg och Mattias Skarin. Kanban and Scrum - Making the
most of both. C4Media, 2010. isbn: 9780557138326.
[4] Wikimedia Commons. Simple kanban board. http://commons.wikimedia.
org/wiki/File:Simple- kanban- board- .jpg. [Online; hämtad den
20 april 2015].
[5] Wikimedia Commons. Alpha State Cards: A Lean and Lightweight Governance Approach for Agile Software Development. http : / / www .
ivarjacobson.com/alphastatecards/. [Online; hämtad den 22 maj
2015].
[6] Terry Schmidt. Strategic Project Management Made Simple: Practical
tools for leaders and teams. 2009.
[7] R.A. Calvo m. fl. “Collaborative Writing Support Tools on the Cloud”.
I: Learning Technologies, IEEE Transactions on 4.1 (jan. 2011), s. 88–
97. issn: 1939-1382. doi: 10.1109/TLT.2010.43.
[8] Golara Garousi m. fl. “Usage and usefulness of technical software documentation: An industrial case study”. I: Information and Software Technology 57 (2015), s. 664–682. issn: 0950-5849. doi: http : / / dx .
doi . org / 10 . 1016 / j . infsof . 2014 . 08 . 003. url: http : / / www .
sciencedirect.com/science/article/pii/S095058491400192X.
[9] Caius Brindescu m. fl. “How do centralized and distributed version control systems impact software changes?” I: Proceedings of the 36th International Conference on Software Engineering. ACM. 2014, s. 322–
333.
104
[10] Paul Dourish och Victoria Bellotti. “Awareness and Coordination in
Shared Workspaces”. I: New York, NY, USA: ACM, 1992, s. 1. url:
http://www.dourish.com/publications/1992/cscw92-awareness.
pdf.
[11] Jun-hui LIU, Geng-yu WEI och Cong WANG. “Research on concurrency control algorithm for real-time collaborative editing systems”. I:
The Journal of China Universities of Posts and Telecommunications
21, Supplement 1 (2014), s. 6–11. issn: 1005-8885. doi: http://dx.
doi . org / 10 . 1016 / S1005 - 8885(14 ) 60519 - 7. url: http : / / www .
sciencedirect.com/science/article/pii/S1005888514605197.
[12] Andrew Reichman. “File storage costs less in the cloud than in-house”.
I: White paper, Forrester (2011).
[13] Department for Business Inovation & Skills. "2014 Information Security breaches survey. https://www.gov.uk/government/uploads/
system / uploads / attachment _ data / file / 307296 / bis - 14 - 767 information-security-breaches-survey-2014-technical-reportrevision1.pdf. [Online; hämtad den 2 maj 2015].
[14] Paul Rubes. Why you should be spending more on security. http://
www.cio.com/article/2904364/security0/why-you-should-bespending-more-on-security.html. [Online; hämtad den 1 maj 2015].
[15] Paul K Martin och Inspector General. “NASA Cybersecurity: An Examination of the Agency’s Information Security”. I: US House of Representatives, Feb (2012).
[16] Lieven Desmet m. fl. Web Application Security. http : / / research .
microsoft.com/en-us/um/people/livshits/papers%5Ctr%5Cdagrep_
s12401.pdf. [Online; hämtad den 1 maj 2015].
[17] Yao-Wen Huang m. fl. “Securing Web Application Code by Static Analysis and Runtime Protection”. I: Proceedings of the 13th International
Conference on World Wide Web. WWW ’04. New York, NY, USA:
105
ACM, 2004, s. 40–52. isbn: 1-58113-844-X. doi: 10 . 1145 / 988672 .
988679. url: http://doi.acm.org/10.1145/988672.988679.
[18] Frank Kargl, Joern Maier och Michael Weber. “Protecting Web Servers
from Distributed Denial of Service Attacks”. I: Proceedings of the 10th
International Conference on World Wide Web. WWW ’01. Hong Kong,
Hong Kong: ACM, 2001, s. 514–524. isbn: 1-58113-348-0. doi: 10 .
1145/371920.372148. url: http://doi.acm.org/10.1145/371920.
372148.
[19] David Moore m. fl. “Inferring Internet Denial-of-service Activity”. I:
ACM Trans. Comput. Syst. 24.2 (maj 2006), s. 115–139. issn: 07342071. doi: 10.1145/1132026.1132027. url: http://doi.acm.org/
10.1145/1132026.1132027.
[20] Subgraph. Vega Vulnerability Scanner. https://subgraph.com/vega/.
[Online; hämtad den 10 maj 2015].
[21] Kaspersky Lab. Global IT Security Risks: 2012. http://www.kaspersky.
com / downloads / pdf / kaspersky _ global _ it - security - risks survey_report_eng_final.pdf. [Online; hämtad den 26 maj 2015].
[22] MA Awad. “A comparison between agile and traditional software development methodologies”. I: University of Western Australia (2005).
[23] Kristian Sandahl. Project Management. http://www.ida.liu.se/
~TDDC88 / theory / lecture - 4 - project - management . pdf. [Online;
hämtad den 12 mars 2015].
[24] Martin Fowler och Jim Highsmith. “The agile manifesto”. I: Software
Development 9.8 (2001), s. 28–35.
[25] Agile Alliance. http://www.agilealliance.org/.
[26] Dean Leffingwell. Agile software requirements: lean requirements practices for teams, programs, and the enterprise. Addison-Wesley Professional, 2010.
106
[27] Ken Schwaber. “Scrum development process”. I: Business Object Design
and Implementation. Springer, 1997, s. 117–134.
[28] Muhammad Ovais Ahmad, Jouni Markkula och Markku Oivo. “Kanban
in software development: A systematic literature review”. I: Software
Engineering and Advanced Applications (SEAA), 2013 39th EUROMICRO Conference on. IEEE. 2013, s. 9–16.
[29] Pär Carlshamre och Björn Regnell. “Requirements lifecycle management and release planning in market-driven requirements engineering
processes”. I: Database and Expert Systems Applications, 2000. Proceedings. 11th International Workshop on. IEEE. 2000, s. 961–965.
[30] Erik Kurin. Intervju- och mail-material. [Personlig kommunikation; utförd april - maj 2015].
[31] Ivar Jacobson International AB. SEMAT state cards. http : / / www .
ivarjacobson.com/alphastatecards/. [Online; hämtad den 13 april
2015].
[32] Michael Bostock, Vadim Ogievetsky och Jeffrey Heer. “D3 data-driven
documents”. I: Visualization and Computer Graphics, IEEE Transactions on 17.12 (2011), s. 2301–2309.
[33] Michael Bostock och Jason Davies. “Code as cartography”. I: The Cartographic Journal 50.2 (2013), s. 129–135.
[34] George Tentak och Jimmy Nyström. “Identifiering av problem i ITprojekt: En studie baserad på IT-konsultföretags och beställarorganisationers erfarenhet av misslyckade IT-projekt”. I: (2009).
[35] Emelie Weinoff Anders och Wirström. “Vägen till ett lyckat IT-projekt”.
I: (2009).
[36] Sara Karnhed Jenny och Eliasson. “Systemutveckling-en modell för verifiering och validering”. I: (2000).
107
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare
– 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 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 upphovsmannens 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 – from the date of publication barring exceptional circumstances.
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 consent of the copyright
owner. The publisher has taken technical and administrative measures to
assure authenticity, security and accessibility.
108
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 procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Adrian Sidenvall, Andy Truong, Erik Boman, Mikael Szreder, Oskar Lind,
Simon Eriksson, Simon Petersson
109