1. No category

Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datavetenskap vid LiTH
2016-12-21 | LIU-IDA/LITH-EX-G--16/015--SE
Interaktiv programmiljö för
kryptoanalys
Interactive software for cryptanalysis
Fredrik Bergstrand, Kimberley French, Rebecka Geijer
Michaeli, Eric Henziger, Oscar Johansson, Robert Kumpulainen, Erik Rönmark, Kristoffer Tennivaara, Victor Tranell
Handledare: Adrian Sidenvall
Examinator: Kristian Sandahl
Linköpings universitet
SE–581 83 Linköping
013-28 10 00, www.liu.se
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år
från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka
kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för
undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta
tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För
att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och 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 upphovsmannenslitterära eller konstnärliga anseende eller
egenart. För ytterligare information om Linköping University Electronic Press se förlagets
hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement
– for a period of 25 years starting from the date of publication barring exceptional 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. 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 Fredrik Bergstrand, Kimberley French, Rebecka Geijer Michaeli, Eric Henziger, Oscar Jo
hansson, Robert Kumpulainen, Erik Rönmark, Kristoffer Tennivaara, Victor Tranell
Sammanfattning
Det är sedan länge känt, både bland företag och i den akademiska
världen, att det krävs strukturerade arbetsmetoder för att
lyckas med storskalig programvaruutveckling. Vilka metoder som
fungerar bäst är det svårt att göra ett generellt uttalande
om eftersom detta till stor del är situationsberoende. Det
existerar en ansenlig mängd metoder och processer som finns
beskrivna i detalj av deras förespråkare, men ingen metod fungerar
felfritt i alla situationer. I den här rapporten beskrivs de
metoder en projektgrupp tillämpade under ett kandidatarbete i
programvaruutveckling, och konsekvenserna dessa fick för den
slutgiltiga produkten.
Gruppen har kommit fram till att värde har skapats för kunden
genom att implementera kundens begärda system, en interaktiv
webbapplikation. Underhållbarhet har uppnåtts genom att följa en
kodstandard, tillämpa parprogrammering och kodgranskningar samt
publicera koden som öppen källkod. Att under möten diskutera
gruppmedlemmarnas välmående bidrog till bättre sammanhållning och
stämning och därmed ett bättre slutresultat. Många av gruppens
svårigheter hade lösts om gruppen haft ett dedikerat kontor.
Förhoppningen är att de erfarenheter och den kunskap som gruppen
tillgodogjort sig under projektet, och dokumenterat i den här
rapporten, ska komma till nytta för både projektmedlemmarna och
rapportens läsare.
ii
Tillkännagivanden
Tack till vår handledare Adrian Sidenvall och examinator Kristian
Sandahl för det stöd vi fått under projektets gång. Våra tankar
går till vår avlidne vän och kurskamrat Victor Karlsson Sehlin.
iii
Innehållsförteckning
Sammanfattning
ii
Tillkännagivanden
iii
I Gemensamma erfarenheter och diskussion
1
.
.
.
.
2
2
2
2
3
2
Bakgrund
2.1 Tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Kursen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
5
3
Teori
3.1 Underhållbarhet . . . . . . .
3.2 Användbarhet . . . . . . . .
3.3 Mjukvara för enhetstestning
3.4 Webbutvecklingsverktyg . .
3.4.1 HTML . . . . . . . .
3.4.2 CSS . . . . . . . . . .
3.4.3 JavaScript . . . . . .
3.5 Scrum . . . . . . . . . . . . .
3.5.1 Sprint . . . . . . . . .
3.5.2 Roller inom Scrum .
3.6 SEMAT kernel . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
7
7
8
8
8
9
9
10
Metod
4.1 Förstudie . . . . . . . . . .
4.2 Projektorganisation . . . .
4.3 Arbetsmetod . . . . . . . .
4.3.1 Modifierad Scrum
4.3.2 Möten . . . . . . .
4.4 Gränssnittsdesign . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
12
13
14
4
Inledning
1.1 Motivering . .
1.2 Syfte . . . . .
1.3 Frågeställning
1.4 Avgränsningar
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
14
14
15
15
15
16
16
16
16
Resultat
5.1 Gränssnittsdesign . . . . . . . . . . . . . . . .
5.2 Systembeskrivning . . . . . . . . . . . . . . .
5.2.1 Dekrypteringverktygens uppbyggnad
5.2.2 Informationsflöde i systemet . . . . .
5.2.3 Vidareutveckling . . . . . . . . . . . .
5.3 Värde för kunden . . . . . . . . . . . . . . . .
5.4 Gemensamma erfarenheter . . . . . . . . . .
5.5 SEMAT kernel alphas . . . . . . . . . . . . . .
5.6 Översikt över individuella bidrag . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
19
19
20
21
21
21
21
Diskussion
6.1 Resultat . . . . . . . . . . . . . . . . .
6.1.1 Gränssnittsdesign . . . . . . .
6.1.2 Implementation . . . . . . . .
6.1.3 Värde för kunden . . . . . . .
6.1.4 Erfarenheter . . . . . . . . . .
6.1.5 SEMAT kernel alphas . . . .
6.2 Metod för insamling av erfarenheter
6.3 Arbetet i ett vidare sammanhang . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
25
27
27
28
28
.
.
.
.
29
29
29
30
30
4.5
4.6
4.7
5
6
7
4.4.1 Prototypning . . . . . . . . . . .
4.4.2 Användbarhetstester . . . . . . .
4.4.3 Omröstningar . . . . . . . . . . .
Implementation . . . . . . . . . . . . . .
4.5.1 Parprogrammering . . . . . . . .
4.5.2 Kodgranskning . . . . . . . . . .
4.5.3 Enhets- och integrationstestning
Versionshantering . . . . . . . . . . . . .
Utvärdering . . . . . . . . . . . . . . . .
4.7.1 Tidigare projekterfarenheter . . .
4.7.2 Iterationsutvärdering . . . . . . .
4.7.3 SEMAT kernel-genomgång . . .
Slutsatser
7.1 Gränssnittsdesign . .
7.2 Värde för kunden . .
7.3 Erfarenheter . . . . .
7.4 SEMAT kernel alphas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II Individuella bidrag
A Fredrik Bergstrand: JavaScript-ramverks effekt på underhållbarhet
A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1 Resursfördelning vid mjukvaruutveckling . . . . . . . .
A.3.2 Komplexitetsmått . . . . . . . . . . . . . . . . . . . . . . .
A.3.3 Complexity-report . . . . . . . . . . . . . . . . . . . . . .
A.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.1 Jämförelsekandidater . . . . . . . . . . . . . . . . . . . . .
32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
33
34
34
34
34
34
34
A.4.2 Mätning
A.5 Resultat . . . . .
A.6 Diskussion . . .
A.6.1 Metod .
A.6.2 Felkällor
A.6.3 Resultat
A.7 Slutsatser . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
36
36
36
37
B Kimberley French: Värdet av en prototyp
B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . .
B.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . .
B.1.2 Frågeställning . . . . . . . . . . . . . . . . .
B.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3.1 Prototyper . . . . . . . . . . . . . . . . . . .
B.3.2 Designprocessen hos ett interaktivt system
B.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4.1 Litteraturstudie . . . . . . . . . . . . . . . .
B.4.2 Undersökning . . . . . . . . . . . . . . . . .
B.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . .
B.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . .
B.6.1 Resultat . . . . . . . . . . . . . . . . . . . .
B.6.2 Metod . . . . . . . . . . . . . . . . . . . . .
B.6.3 Teori . . . . . . . . . . . . . . . . . . . . . .
B.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
38
38
39
39
39
40
40
40
40
42
42
43
43
43
C Rebecka Geijer Michaeli: Daily Scrum virtuellt via textbaserat verktyg
C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3.1 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3.2 Direktkontakt från daily Scrum . . . . . . . . . . . . . . . . .
C.3.3 Virtuella möten . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3.4 Media Richness Theory . . . . . . . . . . . . . . . . . . . . .
C.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6.1 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
45
45
46
46
46
46
46
46
47
47
47
48
48
48
D Eric Henziger: En utvärdering av parprogrammering och kodgranskning
D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.1 Analys av gransknings-commits . . . . . . . . . . . . . . . . . .
D.4.2 Enkätundersökning . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
49
49
49
50
50
50
51
D.5 Resultat . . . . . . . . . . . . . . . . . . .
D.5.1 Analys av gransknings-commits
D.5.2 Enkätundersökning . . . . . . .
D.6 Diskussion . . . . . . . . . . . . . . . . .
D.6.1 Resultat . . . . . . . . . . . . . .
D.6.2 Metod . . . . . . . . . . . . . . .
D.6.3 Arbetet i ett vidare sammanhang
D.7 Slutsatser . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
52
55
55
56
56
57
E Oscar Johansson: Enhetstestningens påverkan på programmeringsprocessen
E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.3.1 Enhetstestning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.3.2 Testdriven utveckling . . . . . . . . . . . . . . . . . . . . . . . . . .
E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.4.1 Upplägg av datainsamling . . . . . . . . . . . . . . . . . . . . . . .
E.4.2 Uppgifterna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.4.3 Enkät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.4.4 Förhållningssätt till enhetstestning . . . . . . . . . . . . . . . . . . .
E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
58
58
58
59
59
59
60
60
60
61
61
61
63
64
F Robert Kumpulainen: Effekten av en branching model i ett litet utvecklingsprojekt
F.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3.2 Greningsmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3.3 Distribuerade och centraliserade versionshanteringssystem . . . . . . .
F.3.4 Arbetsflöden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.1 Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.2 Greningsmodellens framgång . . . . . . . . . . . . . . . . . . . . . . . . .
F.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5.1 Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5.2 Greningsmodellens framgång . . . . . . . . . . . . . . . . . . . . . . . . .
F.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.6.1 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.6.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
65
65
65
65
66
66
66
67
67
67
67
67
68
68
68
69
69
69
70
G Erik Rönmark: Kvalitetssäkrande processer och produktkvalitet i ett litet utvecklingsprojekt
G.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
71
71
71
G.2 Bakgrund . . . . . . . . . . . . .
G.3 Teori . . . . . . . . . . . . . . .
G.3.1 Kodgranskning . . . . .
G.3.2 Rader kod som mätdata
G.4 Metod . . . . . . . . . . . . . . .
G.4.1 Kodgranskning . . . . .
G.4.2 Användartest . . . . . .
G.4.3 Utvärdering . . . . . . .
G.5 Resultat . . . . . . . . . . . . . .
G.5.1 Kodgranskning . . . . .
G.5.2 Användartest . . . . . .
G.5.3 Utvärderingar . . . . . .
G.6 Diskussion . . . . . . . . . . . .
G.7 Slutsatser . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
72
72
72
72
72
72
73
73
73
74
74
74
74
H Kristoffer Tennivaara: Metoder och processer för grafiska användargränssnitt
H.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.3.1 Användbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.3.2 Designbeslut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.3.3 Metoder för att utvärdera ett användargränssnitt . . . . . . . . . .
H.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.4.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.4.2 Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.5.1 Användbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.5.2 Designbeslut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.5.3 Metoder för att utvärdera ett användargränssnitt . . . . . . . . . .
H.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
76
76
76
76
76
77
77
77
78
78
78
79
79
79
79
80
80
80
80
81
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
82
82
82
82
82
83
83
83
84
84
84
84
85
86
86
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Victor Tranell: Kravhantering med Scrum
I.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . .
I.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . .
I.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.3.1 Traditionell kravhantering . . . . . . . . . . . . .
I.3.2 Agil kravhantering . . . . . . . . . . . . . . . . .
I.3.3 Fördelar och nackdelar med agil kravhantering
I.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.4.1 Litteraturstudie . . . . . . . . . . . . . . . . . . .
I.4.2 Projekt . . . . . . . . . . . . . . . . . . . . . . . .
I.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . .
I.6.1 Litteratursammanställning . . . . . . . . . . . .
I.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Litteratur
Bilaga 1
87
Sammanställning av tidigare erfarenheter
Bilaga 2 Sammanställning av iterationsutvärderingar
2.1 Förstudie . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Fullständig sammanställning . . . . . . .
2.1.2 Förbättringsförslag . . . . . . . . . . . . .
2.2 Iteration 1 . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Fullständig sammanställning . . . . . . .
2.2.2 Förbättringsförslag . . . . . . . . . . . . .
2.3 Iteration 2 . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Fullständig sammanställning . . . . . . .
2.3.2 Förbättringsförslag . . . . . . . . . . . . .
2.4 Iteration 3 . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Fullständig sammanfattning . . . . . . .
2.4.2 Sammanställning från diskussion . . . .
Bilaga 3
Complexity-report-sammanfattningar
91
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
94
94
94
99
100
100
109
110
110
114
115
115
122
123
Bilaga 4 Undersökning: Värdet av en prototyp
125
4.1 Enkät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.2 Sammanställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Bilaga 5 Enkät: Utvärdering av parprogrammering och kodgranskning
130
5.1 Enkät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.2 Sammanställning av fritextfrågor . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Bilaga 6
Enhetstestning - Datainsamling
135
Bilaga 7
Resultat från enkät om daily Scrum
146
Del I
Gemensamma erfarenheter och diskussion
1
1
Inledning
Den här rapporten beskriver ett projektarbete i kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet. Arbetet utfördes under våren 2016 och
projektgruppen bestod av nio studenter som läser till civilingenjör inom datateknik eller
mjukvaruteknik.
Rapporten inleds med en beskrivning av projektet och vilka metoder som använts vid utveckling av systemet och utvärdering av arbetet. Sedan presenteras resultatet och en diskussion
förs kring frågeställningarna. Sista delen av rapporten består av individuella utredningar
som utförts enskilt av gruppmedlemmarna.
1.1
Motivering
Projektet gick ut på att utveckla ett mjukvarusystem åt gruppen för informationskodning
(ICG) på institutionen för systemteknik (ISY) vid Linköpings universitet. Systemet skulle
vara ett verktyg för studenter som läser kursen TSIT03 Kryptoteknik. Kursen innefattar en
laboration som tar upp tre krypteringsmetoder (substitution, transposition och Vigenère)
samt beskriver de verktyg som ska användas för att dekryptera respektive krypto. Systemet som utvecklades skulle ersätta det program som tidigare använts i laborationen och har
därmed funktionalitet för att hjälpa användaren att dekryptera meddelanden som krypterats
med ovanstående metoder.
1.2
Syfte
Syftet med rapporten är att beskriva hur gruppen gick tillväga i framtagandet av ett system
och hur ett system med utbildningssyfte kan göras användbart. I rapporten redovisas också
de erfarenheter och lärdomar gruppen fått under utvecklingen av detta system.
1.3
Frågeställning
Nedan följer de frågeställningar kring projektet som är till underlag för rapporten:
1. Vilka konsekvenser får gruppens beslut gällande utvecklingen av det grafiska gränssnittet med avseende på användbarhet?
2. Hur kan systemet implementeras så att det skapar värde för kunden?
2
1.4. Avgränsningar
3. Vilka erfarenheter kan dokumenteras från ett projekt i programvaruutveckling som kan
vara av intresse för framtida projekt?
4. Vilket stöd kan en projektgrupp få genom att använda och följa upp SEMAT kernel
alphas?
1.4
Avgränsningar
Programmet har utvecklats för skrivbordsmiljö och anpassades för webbläsaren Firefox version 38.6.0. Programmet behövde inte innehålla någon information om hur de olika krypteringsmetoderna används. Målgruppen för systemet var studenter som läser kursen TSIT03
vid Linköpings universitet. Målgruppen för denna rapport är studenter, handledare och
examinatorer i kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings
universitet.
Rapporten utreder inte olika utvecklingsprocesser som kunde tillämpats och jämför dessa,
utan fokuserar på den tillämpade och undersöker hur den fungerat under projektets gång.
Eftersom kunden önskade en interaktiv webbapplikation är det inom detta område rapportens tyngdpunkt ligger gällande implementationen av systemet och dess konsekvenser.
3
2
Bakgrund
Gruppen för informationskodning vid ISY ger en kurs i kryptoteknik. I kursen får studenterna lära sig grunderna i kryptoanalys. Som ett moment i kursen har studenterna en
laboration där de får möjlighet att studera olika krypteringstekniker och dekryptera meddelanden som är krypterade med dessa tekniker. Till denna laboration behövs ett interaktivt
system som kan agera verktyg vid dekrypteringen av krypterade texter.
Tidigare har ett program kallat Enigma 1.2 använts. Det skrevs 1998, och källkoden har gått
förlorad sedan länge. Programmet innehöll buggar och gränssnittet var i behov av en uppdatering. Att åtgärda de buggar som fanns och uppdatera gränssnittet var ett komplicerat
uppdrag eftersom källkoden saknades. Gruppen för informationskodning vid ISY ville därför ha ett nytt system som mötte deras krav. De ville ha ett system publicerat med öppen
källkod som var lätt att underhålla och vidareutveckla. Systemet skulle också levereras med
god dokumentation.
Det gamla programmet behövde köras på ISY:s datorer vilket utgjorde ett onödigt hinder för
studenter som ville sitta med sin egen dator. För att underlätta tillgången till programmet
ville kunden att det nya programmet skulle vara en webbapplikation.
2.1
Tidigare erfarenheter
Projektgruppen bestod av nio medlemmar som alla läst minst fem terminer på civilingenjörsprogrammen inom datateknik eller mjukvaruteknik. Projektmedlemmarna diskuterade
under projektets inledning sina tidigare erfarenheter av projektarbete och vilka önskemål om
förbättringar som fanns.
Ett exempel på förbättringsförslag som togs upp var att lägga mer tid på utbildning innan
det riktiga utvecklingsarbetet påbörjades. En lösning föreslogs i form av utbildningstillfällen
vilka skulle hållas av olika projektmedlemmar med kompetens inom respektive område.
En annan erfarenhet gruppen hade var att kod som skrivits av enbart en person varit svår
att underhålla. Förslag på lösningar var parprogrammering samt att granskning av all kod
skulle utföras, där granskaren inte ursprungligen varit med och skrivit koden. På så sätt
skulle all kod ha lästs av minst tre personer.
4
2.2. Kursen
Projektmedlemmarna hade också flera bra tidigare erfarenheter, bland andra just att parprogrammering och utbildningstillfällen varit givande och underlättat kommunikationen i gruppen. En jämn spridning av arbetstiden under projektets gång lyftes också som positivt. En
sammanställning av alla de tidigare erfarenheterna gruppen tog upp återfinns i bilaga 1.
2.2
Kursen
Detta projekt utfördes som en del i kursen TDDD96 Kandidatprojekt i programvaruutveckling för studenter som studerar civilingenjör datateknik eller mjukvaruteknik vid Linköpings
universitet. Kursens omfattning var 15 hp där poängen fördelades som 14 hp projektarbete
och 1 hp opponering.
5
3
Teori
Detta kapitel innehåller teori som är relevant för att förstå innehållet i rapporten. Inledningsvis ges definitioner av underhållbarhet och användbarhet. Sedan tas enhetstestning och
webbutvecklingsverktyg upp. Avslutningsvis behandlas processrelaterad teori så som Scrum
[1] och SEMAT kernel alphas [2].
3.1
Underhållbarhet
Underhållbarhet definieras enligt ISO/IEC 25010:2011 [3] som hur effektivt en mjukvara kan
modifieras. En mjukvaras underhållbarhet kan också enligt [3] ytterligare kategoriseras i sju
underattribut:
• Modularitet (Modularity)
• Återanvändbarhet (Reusability)
• Analyserbarhet (Analyzability)
• Förmåga till förändring (Changeability)
• Stabilitet vid modifiering (Modification stability)
• Testbarhet (Testability)
• Överensstämmelse med standarder (Compliance)
Konkret innebär det att mjukvaran ska vara modulär i den bemärkelse att den ska bestå av
moduler med tydliga gränssnitt gentemot varandra. Modulerna bör också vara skrivna på
ett sådant sätt att duplicering av funktionalitet undviks. För att hålla en hög underhållbarhet
bör också koden vara skriven så att den lätt kan förstås av nya utvecklare. Koden ska också
skrivas så att det är enkelt att introducera förändringar i mjukvaran och kodbasen. Mjukvarans moduler ska ha så få beroenden av varandra som möjligt för att öka stabiliteten vid
förändring. Delas funktionalitet upp i självständiga delar ökar testbarheten. [4]
3.2
Användbarhet
ISO/IEC 25010:2011 [3] definierar också användbarhet som ett antal underattribut:
• Lämplighet (Appropriateness)
6
3.3. Mjukvara för enhetstestning
• Igenkännbarhet (Recognizability)
• Enkel användning (Ease of use)
• Lärbarhet (Learnability)
• Attraktivitet (Attractiveness)
• Teknisk tillgänglighet (Technical accessibility)
• Överensstämmelse med standarder (Compliance)
Ovanstående innebär för det första att mjukvaran ska vara lämplig sett till dess ändamål.
Idealt ska också användaren kunna känna igen koncept i mjukvaran och relatera dessa till
andra välkända koncept, gärna från andra områden skilda från mjukvaran. Detta nämns
även i Interaktionsdesign och UX av Arvola [5]. Mjukvaran ska också vara lätt att lära sig för
en användare med lämplig teknisk kunskap. Finns det standarder för specifika koncept som
tillämpas i mjukvaran skall dessa också följas. [3]
3.3
Mjukvara för enhetstestning
Karma är en programvara som används för att testa JavaScript-funktionalitet. När ett test ska
genomföras startas en webbserver av Karma. Testkoden skickas sedan till de webbläsare som
kopplar upp sig mot servern. Servern instruerar webbläsarna att köra testkoden och sedan
skicka tillbaka resultatdata till servern. Webbläsarna körs typiskt, men inte nödvändigtvis,
på samma fysiska maskin som testservern körs på. Karma tillåter automatisk testning vid
förändring, vilket innebär att skapade testfall automatiskt körs vid förändring av filerna som
innehåller de aktuella funktionerna. [6] [7]
QUnit är ett testramverk för enhetstestning av JavaScript-kod [8]. QUnit kan användas för att
skriva de testfall som sedan körs av Karma i webbläsaren. Detta sker med hjälp av Karmas
tillägg Karma-qunit [9].
3.4
Webbutvecklingsverktyg
När applikationer utvecklas för webben idag används en grunduppsättning av verktyg som
kommit att bli standard. Uppsättningen består av HTML, CSS samt JavaScript. De olika
verktygen ansvarar för innehåll, utseende respektive beteende hos en given sida eller applikation. [10]
En vy i en applikation består av en kombination av tre komponenter: en HTML-fil, en CSS-fil
och en JavaScript-fil. Nedan beskrivs de tre verktygen mer utförligt.
3.4.1
HTML
HTML står för HyperText Markup Language. HTML används för att bygga den logiska strukturen samt definiera innehållet hos en sida. Det sker genom att använda en uppsättning så
kallade HTML-taggar. Sidans struktur byggs upp genom att innehållet förses med taggar
som talar om hur innehållet ska vara strukturerat. Taggar kan till exempel användas för att
tala om vad som är rubriker, stycken eller tabeller. De används också för att definiera logiska
sektioner i innehållet. Innehåll med en tagg runt sig kallas ett element. [11]
7
3.5. Scrum
3.4.2
CSS
CSS står för Cascading Style Sheets. Det används för att bestämma utseende och visuell struktur för innehållet som finns definierat i HTML-filerna. En CSS-fil innehåller regler som i sin
tur består av utseende- och layoutparametrar. Reglerna kopplas till olika taggar, klasser eller
id:n i HTML-filerna. Klasser och id:n är attribut som används för att bestämma vilka element
i HTML-koden som ska lyda under de olika CSS-reglerna. Skillnaden mellan en klass och ett
id är att flera element kan ha samma klass, medan ett id ska vara unikt och endast associerat
med ett element. [11]
Typiska utseendeattribut som kan sättas på element i HTML med CSS är typsnitt, storlek,
inramning eller position.
3.4.3
JavaScript
Med HTML och CSS kan en sidas innehåll och utseende skapas, men för att användaren
ska kunna interagera med applikationen krävs även att dess beteende implementeras. Handlingar som utförs av användaren ska generera ett resultat av en beräkning eller förändra
applikationens tillstånd. Utseendet eller innehållet på sidan bör ändras för att ge användaren
respons på handlingen. Båda dessa uppgifter sköts av JavaScript. [10]
Typiskt kan användaren trycka på en knapp som definierats i HTML och fått sitt utseende
av CSS-regler. Knapptryckningen genererar ett event. En JavaScript-funktion har knutits till
eventet och körs. Funktionen kan sedan till exempel utföra en beräkning och uppdatera ett
element på sidan för att visa resultatet.
JavaScript-ramverk
Då det i dagens allt mer uppkopplade samhälle finns ett behov av att snabbt kunna utveckla
interaktiva webbapplikationer har flera ramverk som avser förenkla utvecklingen tagits fram.
Exempel på ramverk som finns tillgängliga är Angular [12] och Ember [13]. Ramverken är
oftast designade så att abstraktioner skapas runt vanlig funktionalitet, så som att knyta en
funktion till ett event, hämta innehåll asynkront från en webbserver eller skapa en koppling
mellan en datamodell och en grafisk vy.
3.5
Scrum
Scrum är en agil projektform utformad för mjukvaruprojekt. Fokus ligger på små, självorganiserande team som jobbar självständigt med en produkt. Inom Scrum sker allt jobb indelat
i sprintar. En sprint är en kortare tidsperiod som vanligtvis är mellan 1 och 5 veckor lång.
Målet med en sprint är att ha en körbar produkt i slutet av varje sprint. Produkten förbättras
och byggs ut med ny funktionalitet i varje sprint. Detta upplägg gör det lätt att avbryta
projekt utan att arbetade timmar går förlorade. [1]
I Scrum ligger fokus på att utveckla produkter, och liten vikt vid dokumentation. I den
klassiska vattenfallsmodellen börjar man med att skriva en kravspecifikation, därefter skrivs
en designspecifikation och när det är färdigt börjar man sedan utveckla. I Scrum däremot
hanteras inte krav på produkten via en kravspecifikation. En metod som kan användas är
användarberättelser [14]. En användarberättelse är en kort beskrivning av ett krav på systemet, ofta på följande form:
Som [aktör] vill jag [mål med systemet] för att [anledning].
8
3.5. Scrum
Användarberättelser används för att definiera programfunktioner, vilka sorteras efter prioritet i en product backlog (orderstock). Denna product backlog fungerar som en att göra-lista för
produkten som ska byggas, och är en av artefakterna inom Scrum. En annan artefakt är sprint
backlog, en mindre variant av product backlog som endast gäller under en specifik sprint. [15]
En viktig artefakt inom Scrum är Scrum board. Det är en tavla som används för att visualisera allt arbete och hur det ligger till. Tavlan delas in kolumner för de olika tillstånd som
aktiviteter kan befinna sig i. Ofta förekommande kolumner är “Todo”, “Doing”, och “Done”.
Alla aktiviteter representeras av lappar på tavlan, och flyttas runt mellan de olika kolumnerna beronde på vilket tillstånd de befinner sig i. [1]
3.5.1
Sprint
Varje sprint innehåller ett antal aktiviteter som utförs av projektgruppen [1], de listas nedan:
• Sprint planning – varje sprint inleds med att projektgruppen väljer vilka programfunktioner från projektets product backlog som ska utvecklas under sprinten. Valda
programfunktioner agerar sedan underlag till aktuell sprint backlog.
• Daily Scrum – varje dag inleds med ett kort (under 15 minuter) stående möte, där varje
projektmedlem i tur och ordning får svara på följande tre frågor:
1. Vad har du gjort sen sist?
2. Vad ska du göra härnäst?
3. Har du stött på några problem?
Detta för att alla i gruppen ska få en överblick över hur de andra ligger till.
• Sprint review – i slutet av varje sprint hålls en sammankomst där produkten visas upp
för kunden och övriga intresserade, som får chans att komma med feedback.
• Sprint retrospective – efter varje sprint hålls en utvärdering där projektgruppen går
igenom vad som fungerat bra respektive mindre bra under sprinten, med målet att det
ska fungera bättre i nästa sprint.
3.5.2
Roller inom Scrum
Teamen är små och flexibla, med gemensamt ansvar över allt och utan fixa roller. Men det
finns ändå några explicita roller [16], som beskrivs här:
• Teamet – en självorganiserad grupp om cirka 5-9 personer. Teamet ansvarar för att
utveckla produkten. I det ingår att ha den färdig version till slutet av varje sprint.
• Scrum master – fungerar som ordförande under daily scrum-möten, och har övergripande ansvar för att teamet har allt det behöver för att kunna jobba effektivt. Personen
sköter även kontakten med kunden och övriga utanför teamet.
• Product owner – ansvarar för produkten från kundens håll, framförallt genom att närvara vid alla sprint reviews, och genom att ha huvudansvar för projektets product backlog.
9
3.6. SEMAT kernel
3.6
SEMAT kernel
SEMAT kernel är en modell för att mäta framsteg inom mjukvaruutvecklingsprojekt. Den
bygger på idén att alla mjukvaruprojekt kretsar kring sju huvudområden, så kallade alphas,
och för varje huvudområde finns det ett antal faser som projekt passerar. Genom att behandla
alla huvudområden och diskutera vilken fas projektet ligger i går det att få en tydlig bild av
hur projektet går i stort och vad som ska arbetas på härnäst. [2]
Modellens sju huvudområden beskrivs nedan:
• Möjlighet – Behandlar identifiering av ett problem eller behov som kan lösas av systemet som byggs.
• Intressenter – Rör alla inblandade i projektet vilket innefattar kund, utvecklare, investerare och användare. Området behandlar hur involverade och investerade de är i
projektet och produkten.
• Krav – Handlar om kraven på produkten som ska byggas. I början av projektet behandlas hur väl alla inblandade parter är överens om kraven, och senare i projektet hur stor
del av dem som är uppfyllda.
• Mjukvarusystem – Rör själva systemet som byggs, från att dess arkitektur valts till att
det är i bruk hos slutanvändare.
• Projektgrupp – Följer gruppen som jobbar med produkten, från att den precis formats
till att den upplösts, genom olika stadier av effektivitet.
• Arbete – Hanterar allt arbete som görs inom projektet, från att det precis påbörjats till
att det inte längre finns något att göra och projektet är avslutat.
• Arbetsmetod – Behandlar projektgruppens arbetsmetodik, vilka verktyg och processer
som används, och hur väl de är integrerade i det dagliga arbetet.
10
4
Metod
Detta kapitel beskriver med vilka metoder projektarbetet genomfördes och bygger vidare på
den teori som togs upp i kapitel 3. Utvecklingen var uppdelad i tre perioder, kallade iterationer, som vardera bestod av tre till fyra veckors arbete samt en förstudie som ledde upp till
den första iterationen. Först presenteras de processer som tillämpades under förstudien och
vilka roller som tilldelades projektmedlemmarna. Sedan förklaras den arbetsmetodik gruppen använde sig av under iterationerna i ett antal avsnitt. Avsnitten behandlar arbetsmetod,
alltså gruppens modifierade variant av Scrum samt hur möten gick till, utformningen av slutproduktens gränssnittsdesign, hur kod implementerades, vilken form av versionshantering
som användes samt de utvärderingar som genomfördes under projektet.
4.1
Förstudie
De första fyra veckorna av projektet bestod av en förstudie, vilket var en mjukstart till projektet, då projektmedlemmarna lärde känna varandra och började hålla utbildningar inom
de områden där kompetens krävdes.
Förstudien ägnades framförallt åt följande större punkter:
• Rollfördelning (se 4.2 för rollerna) – första veckan tillsattes teamleader, och veckan
efter fördelades de övriga rollerna.
• Genomgång av SEMAT kernel alphas (se 3.6 för förklaring) – de sju huvudområdena
gicks igenom och en uppskattning gjordes gällande under vilka iterationer de olika
tillstånden skulle uppnås.
• Dokumentskrivande – i samråd med kunden skrevs en kravspecifikation för systemet.
En projektplan och en kvalitetsplan skrevs. En arkitektur- och testplan för systemet
påbörjades.
• Utbildningar – projektmedlemmarna höll workshops och utbildningar för varandra
där ämnen så som Scrum, Git, och webbprogrammering i WebStorm med HTML, CSS
och JavaScript behandlades.
11
4.2. Projektorganisation
4.2
Projektorganisation
Genom hela projektet har gruppmedlemmarna haft tydliga roller. För att se till att alla i
gruppen var överens om arbetet skrevs ett utförligt gruppkontrakt. Rollerna med tillhörande
ansvarsområde beskrivs nedan.
• Teamleader – har fungerat som ordförande för gruppen, både under och utanför möten.
Den har även stått för det mesta av gruppens kontakt med examinatorn och handledaren.
• Analysansvarig – har stått för kontakten med kunden, med stort fokus på att samla in
och sammanställa dennes krav på systemet. Ansvarsområdet innefattar även skrivandet av kravspecifikationen.
• Dokumentansvarig – har ansvarat för alla dokument som skrivits under projektet.
Bland annat har det ingått att formatera dem på ett enhetligt sätt. Dokumentansvarige
har även fungerat som ständig sekreterare under gruppmöten.
• Testledaren – har ansvarat för att testning sker, och att det sker på rätt sätt. Testledaren
ansvarade även för att utbilda resten av gruppen i testning och att skriva testplan och
testrapport.
• Utvecklingsledaren – har lett utvecklingsarbetet. Detta innefattar att informera övriga
gruppmedlemmar om hur kod skulle skrivas och dokumenteras. Dessutom innefattar
rollen även att komma med råd och förslag kring utvecklingsarbetet, gällande bland
annat kodgranskning.
• Arkitekten – har ansvarat för att designa systemets arkitektur, till stor del genom att
skriva ett arkitekturdokument.
• Konfigurationsansvarig – har ansvarat för att allt arbete versionshanteras under projektet. Detta har inneburit att välja vilka verktyg för versionshantering som skulle användas och att sätta upp riktlinjer och lära gruppen hur de används.
• Kvalitetssamordnaren – har ansvarat för att se till att hög kvalitet hålls på allt som
gruppen producerar, framförallt genom att skriva en kvalitetsplan.
• UX-specialisten – har lett arbetet med den grafiska utformningen av systemet, som
användaren kommer i kontakt med.
4.3
Arbetsmetod
Projektgruppen har valt att arbeta enligt särskilda metoder som anpassats efter gruppens
behov och kursens utformning. Detta avsnitt beskriver hur gruppen har arbetat med Scrum
samt hur möten har gått till. Mer information om metod kring mjukvaruutveckling finns i
avsnitt 4.5.
4.3.1
Modifierad Scrum
I denna projektgrupp har en modifierad variant av Scrum använts. Då kursen varit uppdelad
i iterationer har det varit naturligt att låta dessa motsvara sprintar i Scrum.
Inför varje ny iteration har en sprint planning genomförts. De funktioner som lades in i
projektets backlog formulerades utifrån kraven i kravspecifikationen. Vid behov lades även
extra aktiviteter till, framförallt gällande utformningen av det grafiska gränssnittet eftersom
dessa inte specificerades i kraven. Projekthanteringsverktyget Trello [17] användes som
12
4.3. Arbetsmetod
Scrum board där varje iteration hade en egen sprint backlog.
Istället för att hålla ett fysiskt möte för daily Scrum varje dag satte gruppen upp en kanal i
Slack [18] där varje gruppmedlem svarade på frågor varje måndag, onsdag och fredag förmiddag. Ett automatiserat meddelande skickades ut under dessa dagar med följande frågor:
1. Vad har du gjort sen sist?
2. Vad ska du göra härnäst?
3. Finns beroenden till andra som uppehåller ditt arbete?
4. Har du stött på några andra problem?
5. Övriga synpunkter och kommentarer?
Detta innebar att gruppmedlemmarna själva kunde bestämma när det passade att svara på
frågorna samt läsa igenom de andras svar. Det fungerade också som ett verktyg för att kolla
om det som var planerat faktiskt blev utfört. En studie kring denna anpassade form av daily
Scrum förs i individuell del C.
I slutet av varje iteration hölls en utvärdering där projektgruppen reflekterade över den
senaste iterationen. Hur utvärderingen gick till förklaras i avsnitt 4.7.
4.3.2
Möten
Minst en gång i veckan hölls möte med alla i projektgruppen. Oftast var även handledaren
med under dessa möten. De som inte kunde närvara fysiskt var med över Skype [19] i den
mån det var möjligt. Möten bokades generellt in med en veckas framförhållning där det
eftersträvades att alla projektmedlemmar skulle kunna närvara.
Inför varje möte fanns en dagordning på Google Drive [20]. I denna hade projektmedlemmarna möjlighet att själva fylla i om de hade något att ta upp för diskussion eller ett meddelande under mötet. Vissa punkter i dagordningen var stående punkter som alltid fanns med.
Dessa listas nedan tillsammans med en kort beskrivning.
• Måenderunda – mötet inleddes med att alla projektmedlemmar i turordning fick prata
öppet om hur de mådde, om de var stressade eller om de hade någon personlig händelse att dela med sig av.
• Dagordning – alla punkter i dagordningen lästes upp och projektmedlemmarna gavs
möjligheten att lägga till/omdistribuera punkter enligt önskemål. Om det var många
mötespunkter med risk att dra över på tiden sattes tidsbegränsningar för hur länge
varje punkt fick hålla på.
• Veckans rapporter och meddelanden – de som hade någon kort uppdatering eller något särskilt att belysa hade här möjlighet att framföra det.
• Handledaren på besök – om handledaren var med på mötet fanns här möjlighet för
honom att delge information eller ställa frågor till projektgruppen.
• Kommande möten – nästkommande möte bokades in. Första prioritering var här handledarmöten, men eventuella andra möten eller arbetsstugor kunde också komma att
bokas in under den här tiden.
• Övrigt – denna punkt användes för att diskutera eventuella frågor som kan ha dykt
upp under mötets gång eller kortare, mindre viktiga punkter som skulle tas upp i mån
av tid.
13
4.4. Gränssnittsdesign
Under mötena fördes mötesprotokoll i Google Drive. Eftersom protokollet skrevs löpande
i ett delat dokument under mötet kunde gruppmedlemmarna välja att följa med i anteckningarna om så önskades. Även de som var frånvarande hade möjlighet att läsa protokollet i
efterhand och ta del av det som tagits upp.
4.4
Gränssnittsdesign
Eftersom kunden uttryckt behov av en lättförståelig, användbar produkt beslutade projektgruppen att lägga stor vikt vid att ta fram ett lämpligt grafiskt användargränssnitt. Avsnitten
nedan beskriver de metoder som användes för att realisera detta.
4.4.1
Prototypning
För att forma produktens grafiska användargränssnitt skapades tidigt ett antal prototyper.
Till detta användes programmet Axure RP [21] som gör det möjligt för användaren att skapa
en interaktiv hemsida utan att skriva någon kod. Det som skulle bestämmas med hjälp av
prototyperna var positioneringen av menyn och verktygen. Prototyperna kunde även användas för att ge kunden en bättre bild av slutprodukten och möjlighet till återkoppling på
designen.
4.4.2
Användbarhetstester
Under iteration 2 och iteration 3 testades produkten, i dess dåvarande tillstånd, i ett antal användbarhetstester. Syftet var att testa produktens användbarhet och därmed de punkter som
nämns under kapitel 3.2. Testet gick ut på att användare tilldelades uppgifter att lösa under
vägledning. Användaren testade att använda de verktyg som utvecklats och under tiden antecknades hur de gick till väga. När testet var klart ställdes frågor till användaren angående
dennes upplevelse av programmet. Frågorna gällde hur användbara verktygen var, hur lätta
de var att lära sig, hur visuellt tilltalande de var samt övriga synpunkter, idéer och kommentarer. Resultaten från testen sammanställdes och eventuella åtgärder diskuterades under
ett senare möte med hela gruppen.
4.4.3
Omröstningar
Projektgruppen genomförde omröstningar inom gruppen med avseende på färgschema, logotyp, typsnitt, placering av olika element och andra utseendemässiga attribut. Olika förslag
presenterades och alla gruppmedlemmar fick möjlighet att uttrycka sin åsikt kring förslagen.
Ofta resulterade diskussionen i ett antal nya alternativ vilka också ingick i omröstningen.
Med hjälp av de kommentarer som inhämtades kunde gränssnittet bearbetas ytterligare och
utformas efter projektgruppens önskemål.
4.5
Implementation
Detta avsnitt beskriver vilka metoder som användes vid implementeringen av systemet under de olika projektfaserna.
4.5.1
Parprogrammering
Under iteration 1 och 2 skedde utvecklingen huvudsakligen genom en form av parprogrammering. Gruppmedlemmarna delades in i grupper om två och arbetade parvis med någon
funktion hämtad från iterationens backlog. Ofta skedde arbetet med hjälp av två bärbara datorer där själva skrivandet av kod skedde på den ena datorn medan den andra datorn användes för att göra sökningar i dokumentation och på internet. Parprogrammeringen användes
14
4.6. Versionshantering
för att underlätta kunskapsspridning, höja kvaliteten på koden och ge omedelbar granskning
av koden.
4.5.2
Kodgranskning
Då en funktion enligt ansvariga utvecklare var färdig och redo för integration gjordes en förfrågan om granskning. Förfrågan skedde via kommunikationsverktyget Slack [18] och en
frivillig gruppmedlem som inte arbetat med utvecklingen av funktionen åtog sig att granska
den skrivna koden. Det kontrollerades att koden följde den valda kodstandarden, att kommenteringen kunde förklara koden för en oinsatt utvecklare och mer generellt att koden höll
god struktur och läsbarhet. Feedback gavs från granskaren direkt i koden genom att i anslutning till den felaktiga koden skriva en kommentar enligt kodexempel 4.1. När granskningen
var utförd gick utvecklarna igenom koden igen och löste alla uppmärksammade fel. Denna
process upprepades tills granskaren inte längre hade något mer att anmärka på.
Kodexempel 4.1: Exempel på feedback efter granskning.
// FIXME: Variable names should be camelCased.
var crypto_graph_data = { name: ’’, data: [] };
4.5.3
Enhets- och integrationstestning
För kodens logiska funktioner eftersträvades att hålla hög testtäckning med hjälp av automatisk enhetstestning. Med automatisk avses i det här fallet att samtliga enhetstester kan
exekveras med ett knapptryck från utvecklaren. Enhetstesterna skrevs med hjälp av ramverket QUnit och körningen av testerna utfördes av testmotorn Karma. De utvecklare som skrev
en logisk funktion hade också ansvar för att se till att enhetstester skrevs för funktionen.
Enhetstesterna verifierade att funktionen givet ett visst indata returnerade förväntad utdata.
För mer avancerade funktioner i produkten utformades integrations- och funktionstester.
Dessa tester utformades av utvecklaren utifrån en testmall och i samråd med testledaren.
Testmallen hade i uppgift att lyfta fram gränsfall och acceptanskriterier för testet och tydliggöra för en testare hur testet skulle utföras.
4.6
Versionshantering
För att underlätta utvecklingsarbetet ansåg gruppen att en väl fungerande versionshantering krävdes. Gruppen valde därmed att använda Git [22], med en central repository för att
eliminera de problem som uppstår med brandväggar. Därtill utnyttjades en greningsmodell
(eng. branching model), baserad på Driessens [23], vars syfte var dels att bidra till att gruppens
medlemmar kunde arbeta oberoende av andra, samt minimera merarbetet med kodkonflikter som kan uppstå. Reglerna gällande utgrening för den tillämpade greningsmodellen sammanfattas av tabell 4.1. Effekten av denna beskrivs i individuell del F.
Tabell 4.1: Utgreningsregler.
Rules for different
branches
May branch off
Must merge back
May merge back
Naming convention
Feature branch
Release branch
Hotfix branch
develop
develop
Anything except
master,
develop,
release-* or hotfix-*
develop
develop & master
release-*
master
develop & master
release
hotfix-*
15
4.7. Utvärdering
4.7
Utvärdering
Utvärdering och erfarenhetsinsamling om projektarbetet utfördes regelbundet med gruppens medlemmar. I avsnitten nedan beskrivs hur gruppen gick tillväga för att dokumentera
de erfarenheter som fanns från tidigare projekt samt hur utvärderingarna för varje iteration
genomfördes.
4.7.1
Tidigare projekterfarenheter
Under projektets förstudie gjordes en insamling av projekterfarenheter från tidigare projekt.
Denna gjordes först informellt under ett möte där samtliga gruppmedlemmar fick yttra sina
spontana tankar. Därefter gjordes en insamling av erfarenheter där varje gruppmedlem skrev
ner positiva och negativa erfarenheter som skickades till gruppens teamleader. En sammanställning av erfarenheterna skickades vidare till kursens examinator som slutligen gav
feedback på erfarenheterna.
4.7.2
Iterationsutvärdering
Efter varje iteration gjordes en omfattande utvärdering. Utvärderingen innefattade granskning av de verktyg som använts, de processer som tillämpats under iterationen, samarbetet i
gruppen, och hur själva utvecklingsarbetet gått. En utvärdering gjordes även efter förstudien.
Alla utvärderingar genomfördes genom att minst två timmar schemalades till ett tillfälle då
hela gruppen kunde närvara. Utvärderingarna började informellt, i cirka 10 minuter pratade
gruppen bara om saker som var orelaterade till projektet för att alla skulle ha tid att slappna
av och göra sig bekväma. När utvärderingen började delades pappersformulär ut till alla
gruppmedlemmar. I formuläret fanns alla utvärderingspunkter och för varje punkt fanns det
två fält för fritext: vad som fungerat bra, och vad som behövde utvecklas till nästa iteration.
Formulären fylldes i, utan diskussion och utan tidspress. När alla kände att de var färdiga
gick gruppen igenom utvärderingspunkterna en efter en och lät alla gruppmedlemmar dela
med sig av vad de tyckt och tänkt. Diskussion uppmuntrades och förslag till förbättringar
skrevs ner för att kunna efterföljas. Allt producerat material sammanställdes och laddades
upp på gruppens gemensamma Google Drive.
Nedan listas de utvärderingar som genomfördes och deras innehåll:
• Förstudie – rollfördelningen, möten, de verktyg som använts (Trello, Google Drive)
samt gruppdynamiken.
• Iteration 1 – utvecklingsarbetet, utvecklingsmiljöer (WebStorm), versionshantering
(Git), projektstyrning, testning, parprogrammering samt gruppdynamiken.
• Iteration 2 – testning, projektstyrning, prioriteringar och gruppdynamiken.
• Iteration 3 (slutgiltig utvärdering) – slutprodukten, arbetet i helhet, hur gruppen
fungerat samt vilka lärdomar som erhållits att ha med sig till framtida projekt.
4.7.3
SEMAT kernel-genomgång
I samband med iterationsutvärderingar har en genomgång av SEMAT kernel alphas utförts
för att kontrollera gruppens status inom respektive alpha. Fokus har legat på vilka tillstånd
som har uppnåtts, och när nästa tillstånd bedöms vara uppnått.
16
5
Resultat
I detta avsnitt redovisas resultaten från projektets olika delar. Först behandlas hur produktens gränssnitt designats. Därefter ges en övergripande systembeskrivning. Resultaten från
gruppens användande av SEMAT kernel alphas presenteras och slutligen ges en överblick
över gruppmedlemmarnas individuella rapporter.
5.1
Gränssnittsdesign
Under iteration 1 skapades en grupp som ansvarade för produktens grafiska användargränssnitt och kom att kallas GUI-gruppen. Denna grupp ansvarade för att ta fram ett antal
prototyper enligt de önskemål som diskuterats med samtliga projektmedlemmar. Prototyperna testades sedan av kunden som godkände två av dem. En omröstning gjordes inom
projektgruppen för att välja vilken av de två godkända prototyperna som skulle användas
som mall för produkten.
Utifrån prototypen byggdes ett kodskelett för de element som skulle komma att finnas i det
grafiska gränssnittet. Även om dessa till en början var tomma, kunde den implementerade
funktionaliteten läggas in allt eftersom produkten utvecklades och det blev tydligt för de
som utvecklade var allting skulle placeras.
Kunden ville inte att programmet skulle hjälpa användaren utan att användaren skulle behöva tänka själv. Därmed har systemet implementerats så att all information inte är synlig
från början. Däremot är alla tillgängliga handlingar synliga hela tiden. Ett annat val gruppen
gjorde var att presentera mer information än vad som är nödvändigt för att lösa uppgiften.
Till exempel visas de exakta procenttalen för bokstavsfrekvensen i graferna.
För att minska inlärningskurvan har drag and drop implementerats i systemet. De element
som kan manipuleras med drag and drop har en skuggning bakom sig och klickbara element
ändrar färg när musen är ovanför dem. Detta är två exempel på de handlingsinviter som är
implementerade i systemet. De designval som gjorts är implementerade över hela systemet
för att alla verktyg ska vara enhetliga.
5.2
Systembeskrivning
Här följer en beskrivning av det resulterande systemet efter projektets avslut. Systemet fick
namnet Knekt. Beskrivningen inleds med en överblick över systemets användargränssnitt
17
5.2. Systembeskrivning
där den funktionalitet som finns tillgänglig översiktligt tas upp. Sedan behandlas olika
nyckelaspekter av systemets implementation. I figur 5.1 visas en skärmbild från systemets
användargränssnitt.
Figur 5.1: Skärmbild från systemets användargränssnitt.
Systemet tillhandahåller tre olika dekrypteringsverktyg där varje verktyg används för att
angripa en av de tre krypteringsmetoder som ingår i laborationen. Det aktiva verktyget väljs
via navigationspanelen till vänster, markerat 1 i figuren. I navigationspanelen återfinns också
val av den textfil systemet ska arbeta med samt val av det språk verktygen ska arbeta efter.
Tillgängliga språk är engelska och svenska.
Sektionen i mitten av gränsnittet, markerat 2 i figur 5.1, innehåller det valda dekrypteringsverktyget alternativt en hemskärm som visas då systemet startas. Hemskärmen finns
tillgänglig genom att klicka på logotypen i övre vänstra hörnet. Till höger i figuren finns
statistikpanelen markerad 3. I statistikpanelen finns ett antal diagram vilka ger användaren
information om den krypterade texten och statistik för det valda språket. Alla diagram
initieras dolda, men genom att klicka på deras flikar kan de visas eller döljas. Genom att dra
och släppa flikarna kan användaren ändra deras inbördes ordning.
När användaren öppnar ett diagram eller byter deras inbördes ordning associeras det nya
tillståndet endast med det aktiva dekrypteringsverktyget. Det innebär att vilka diagram som
är öppna eller stängda samt deras placering beror på vilket dekrypteringsverktyg som är
aktivt, och hur användaren tidigare förändrat statistikpanelen i detta. Effekten blir att användaren kan experimentera med flera verktyg utan att manuellt behöva öppna och stänga
relevanta diagram för de olika verktygen. Detta sköts automatiskt vid verktygsbyte eftersom systemet då återställer det senast använda tillståndet hos statistikpanelen i det nyligen
aktiverade verktyget.
18
5.2. Systembeskrivning
5.2.1
Dekrypteringverktygens uppbyggnad
Ett dekrypteringsverktyg byggs upp med hjälp av följande filer:
• index.html – verktygets logiska innehåll placeras här. Den här filen delas av alla verktyg.
• [tool-name].scss – verktygets utseende definieras i en .scss-fil specifik för det aktuella
verktyget.
• [tool-name]-manager.js – i manager-filen placeras eventhanterare specifika för verktyget.
Funktionalitet i den här filen tillåts modifiera samt extrahera data från systemets gränssnitt.
• [tool-name]-logic.js – verktygsspecifika beräkningsfunktioner definieras i verktygets
logic-fil. Funktioner i den här filen får inte ha någon kännedom om användargränssnittet utan utför rena beräkningar utan sidoeffekter.
• [tool-name]-interface.js – i de fall då ett verktyg kräver många olika typer av modifikationer av användargränssnittet flyttas den funktionaliteten från manager-filen till verktygets interface-fil.
Figur 5.2: Sekvensdiagram över typiska modulinteraktioner.
Ett exempel på en typisk kedja av modulinteraktioner visas i figur 5.2. Den inleds med att användaren utför en handling i användargränssnittet. Handlingen utlöser ett event som i sin tur
orsakar en körning av en eventhanterare i verktygets manager-modul. Manager-modulen behöver sedan resultatet av en beräkning som delegeras till verktygets logic-modul. Resultatet
av beräkningen returneras till manager-modulen, och ska därefter visas i användargränssnittet. För att utföra uppdateringen av gränssnittet anropar manager-modulen en funktion i
interface-modulen med beräkningsresultatet som argument. Funktionen i interface-modulen
uppdaterar användargränssnittet.
5.2.2
Informationsflöde i systemet
För att verktygen ska kunna anpassa sig till systemets tillstånd och förändringar i detta används en eventdriven modell. Exempel på tillståndsvariabler i systemet är det aktiva språket
19
5.2. Systembeskrivning
samt den valda filen. Den eventdrivna modellen har implementerats så att modulen som
ansvarar för att övervaka applikationens tillstånd triggar ett event av aktuell typ vid varje
förändring av tillståndet. Detta leder till att verktygen kan registrera eventhanterare för relevanta event men ignorera de andra. Effekten blir att modulen som hanterar tillståndet i
systemet inte behöver ha någon kännedom om vilka verktygsmoduler som existerar, utan
endast behöver se till att event triggas. Det skapar en lös koppling mellan verktyg och tillstånd, och leder till att nya verktyg enklare kan läggas till.
Figur 5.3: Sekvensdiagram över en tillståndsförändring i systemet.
I figur 5.3 visas ett sekvensdiagram över en tillståndsförändring, samt ett dekrypteringsverktygs respons på förändringen. Sekvensen inleds av att användaren i användargränssnittet
väljer en fil att arbeta med. Det genererar ett event som hanteras av modulen som övervakar
systemets tillstånd. Där hämtas sedan den valda filen från webbservern. Sedan genereras ett
nytt event av typ fileChange, vilket är det event som verktygen registrerat hanterare för.
Alla verktygs registrerade eventhanterare exekveras sedan, och verktygen kan anpassa sig
till det nya tillståndet.
5.2.3
Vidareutveckling
Systemet har implementerats så att det enkelt ska gå att lägga till ny statistikfunktionalitet
och nya dekrypteringsverktyg. Statistikfunktionaliteten har implementerats likt dekrypteringsverktygen, men eftersom statistikverktygen är mindre komplicerade än dekrypteringsverktygen behövs inte interface-filen. Statistikverktygens filer interagerar med varandra
på samma sätt som dekrypteringsverktygens respektive filer.
En typisk vidareutveckling av systemet kan exempelvis vara att lägga till ytterligare ett
diagram i statistikpanelen. Detta kan göras genom att skapa en manager-fil för det nya
diagrammet, samt eventuellt en logic-fil. I manager-filen bör relevanta eventhanterare registreras. Typiska event som ett diagram vill hantera är att användaren byter fil eller språk.
Diagrammet ska sedan ges en plats i statistikpanelen, vilket sker genom att lägga till dess
HTML-kod i index.html. Den diagramspecifika HTML-koden ska ha en wrapper runt sig av
samma typ som de redan existerande diagrammen och ska också följa samma namngivningskonventioner som dessa. På ett liknande sätt kan ett nytt dekrypteringsverktyg enkelt
20
5.3. Värde för kunden
implementeras.
Implementeras verktygen och alla diagram enligt de konventioner som beskrivits ovan så
fungerar all övrig funktionalitet, exempelvis drag and drop eller statistikpaneltillstånd, tillsammans med det nya verktyget utan att ytterligare förändringar behöver göras.
5.3
Värde för kunden
Systemets delar har implementerats med den struktur och de konventioner som också finns
beskrivna i avsnitt 5.2 vilket gör att det finns riktlinjer att följa vid eventuella tillägg. Nedan
beskrivs de beslut som tagits för att skapa värde för kunden.
• Öppen källkod – vid projektets avslut publicerades systemets källkod under MITlicensen, vilket är en tillåtande källkodslicens. Systemet använde ett mjukvarubibliotek
som inte har en öppen programvarulicens, men som tillåter bruk i icke-kommersiella
sammanhang.
• Dokumentation – en användarhandledning, en README-fil och koddokumentation i
form av JSDoc har skrivits. I användarhandledningen beskrivs hur systemet är tänkt att
användas av användaren. I README-filen beskrivs kodens struktur.
• Kodkvalitet – koden är skriven enligt Googles kodstandard för HTML [24], CSS [24]
och JavaScript [25]. Parprogrammering och kodgranskning har tillämpats.
5.4
Gemensamma erfarenheter
De erfarenheter projektmedlemmarna hade med sig från tidigare projekt återfinns i bilaga 1.
Sammanställningen presenterar de erfarenheter och lärdomar som dokumenterades under
förstudien. De är i största möjliga mån uppdelade efter olika områdesrubriker.
I bilaga 2 presenteras sammanställningar av de utvärderingar som utfördes efter respektive
iteration, inklusive förstudien. Resultaten är indelade efter de punkter som togs upp under
just den utvärderingen och varje punkt är i sin tur uppdelad i Bra och Kan bli bättre. För varje
utvärdering följer även en förteckning över de förbättringsförslag som gruppen kom fram
till.
5.5
SEMAT kernel alphas
I början av projektet utfördes en planering med hjälp av SEMAT kernel alphas. Efter varje
iteration gjordes en kontroll av hur gruppen låg till utifrån planeringen. Vid samtliga möten
framgick att gruppen låg minst lika bra till som planerat. SEMAT kernel alphas användes ej
aktivt under iterationerna, i den bemärkelse att de inte var integrerade i den utvecklingsprocess gruppen tillämpade. Det lades ingen tid under iterationerna på att utvärdera eller använda sig av dem.
5.6
Översikt över individuella bidrag
Nedan följer en kort sammanfattning av gruppmedlemmarnas individuella bidrag.
A
Fredrik Bergstrand: JavaScript-ramverks effekt på underhållbarhet
Rapporten behandlar hur användandet av ett JavaScript-ramverk påverkat systemets
underhållbarhet. Detta undersöks genom att med hjälp av komplexitetsmätningar jämföra systemet i den här rapporten med andra system vilka utvecklats med hjälp av ett
21
5.6. Översikt över individuella bidrag
ramverk. Undersökningen visar att användningen av ramverk bidrar till en mindre
komplex kodbas. Slutsatsen dras att detta kan ge en generellt bättre underhållbarhet
beroende på vilken typ av underhåll eller vidareutveckling av systemet som sker i
framtiden.
B
Kimberley French: Värdet av en prototyp
Denna del undersöker hur prototyper används i framtagingen av ett mjukvarusystem,
vilka för- och nackdelar som finns samt vilka processer som är lämpliga för att arbeta
fram en prototyp. Undersökningen är baserad på en enkät som besvarats av projektgrupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Resultatet visar
på att gruppmedlemmarna tycker att den tid som lagts på prototypningsarbete är väl
investerad och att prototypen har underlättat för produktens utveckling.
C
Rebecka Geijer Michaeli: Daily Scrum virtuellt via textbaserat verktyg
Rapporten presenterar teori kring daily Scrum-möten, och möten som hålls virtuellt.
Teorin jämförs mot de virtuella, textbaserade daily Scrum-möten som detta projekt
tillämpat. Dessutom presenteras insamlade erfarenheter från gruppens medlemmar
om daily Scrum-mötena. Bland dessa framträder värdet i att anpassa frekvensen av
daily Scrum-möten efter hur mycket tid projektmedlemmarna lägger på projektet.
D
Eric Henziger: En utvärdering av parprogrammering och kodgranskning
Rapporten visar på positiva effekter från parprogrammering och kodgranskning med
avseende på både kodkvalitet och samarbetet inom gruppen. Även några negativa effekter framkom som bland annat berörde inflexibilitet hos parprogrammering och obehag med att ge kritik vid kodgranskning.
E
Oscar Johansson: Enhetstestningens påverkan på programmeringsprocessen
Rapporten utreder hur tidpunkt för skrivade av enhetstester påverkar programmeringsprocessen, med avseende på tidsåtgång, resultat och underlättande av lösning. För
att utreda detta anordnades en datainsamling där deltagare fick lösa uppgifter med
tre olika förhållningssätt till enhetstestning. Rapporten visar att olika förhållningssätt
påverkar programmeringsprocessen på många olika vis.
F
Robert Kumpulainen: Effekten av en branching model i ett litet utvecklingsprojekt
Rapporten analyserar huruvida valet av greningsmodell är associerat med en ökad
mängd felaktig kod. Undersökningen visade att ytterligare metoder krävs för att
hantera de datamängder som uppstår vid analys av ett mjukvaruprojekts utvecklingshistorik. Den av rapporten tillämpade datainsamlingsmetoden producerade inte data
från vilken konklusioner kunde dras.
G
Erik Rönmark: Kvalitetssäkrande processer och produktkvalitet i ett litet utvecklingsprojekt
Rapporten utreder hur projektgruppens sätt att göra utvärderingar, användartest och
kodgranskning påverkade produktkvaliteten. Denna undersökning genomförs genom
att gå igenom producerad dokumentation och söka igenom statistik från Git. Rapporten
visar att gruppens kvalitetsäkrande processer faktiskt påverkade produktkvaliteten
positivt.
H
Kristoffer Tennivaara: Metoder och processer för grafiska användargränssnitt
Rapporten utreder vad olika sätt att fatta designbeslut på har för effekt på användbarheten på produkten. Den undersöker också vilka processer och metoder som lämpar
sig bäst för att ta fram ett användargränssnitt med så hög användbarhet som möjligt i
ett småskaligt projekt.
22
5.6. Översikt över individuella bidrag
I
Victor Tranell: Kravhantering med Scrum
Rapporten utreder vilka effekter den agila utvecklingsmetodiken Scrum får på
kravhantering. En litteraturstudie samt en projektstudie visar att agil kravhantering
passar mycket bra för små projekt.
23
6
Diskussion
Här diskuteras olika delar av innehållet i rapporten. Inledningsvis behandlas de resultat som
erhållits ur slutprodukten och projektarbetet. Därefter tas den metod som använts för att
samla in erfarenheter upp, och till sist sätts arbetet in i ett vidare sammanhang.
6.1
Resultat
Här diskuteras de resultat som presenterats i avsnitt 5. Diskussionen inleds med att gränssnittsdesignen behandlas. Därefter berörs den valda implementationen. Sedan tas produktens
värde för kunden upp. Gruppens redovisade erfarenheter diskuteras och avslutningsvis behandlas SEMAT kernel alphas.
6.1.1
Gränssnittsdesign
Då handlingsinviter bidrar till att ge användaren information om vilka delar av systemet det
går att interagera med [5] går det att argumentera för att dessa gör systemet mer användbart. Enhetlig formgivning i systemets olika delar kan exempelvis bidra till att användaren
snabbare förstår hur ett nytt verktyg ska användas. Interaktionsmekanismer som drag and
drop har använts för att göra det lätt för användaren att lära sig använda systemet. Det är
inte säkert att drag and drop alltid är den effektivaste metoden för att interagera med ett
system. Däremot är metoden lätt att förstå och tillämpa jämfört med andra mekanismer,
såsom kommandorads-interface eller komplicerade kortkommandon. Beslutet att använda
dessa mekanismer baserades på att systemet inte är ett verktyg som studenterna ska kunna
bli experter inom eller med vars hjälp kunna lösa problemet så snabbt som möjligt. Det
ansågs viktigare att tillhandahålla ett system som det är lätt att påbörja arbetet i.
Ett antal av de beslut som togs angående gränssnittsdesignen kan anses ha försämrat produktens användbarhet, exempelvis att presentera mer information än vad som är nödvändigt
för att dekryptera en text. Systemet gör heller inte några ansträngningar för att tala om för
användaren vilka verktyg som fungerar bra att använda tillsammans. Detta är exempel på
beslut som kanske sett annorlunda ut om systemet inte tillkommit i utbildningssyfte. Tanken
var att studenterna själva skulle bli tvungna att tänka efter och förstå principerna för att
kunna utföra laborationen. Alla verktyg görs tillgängliga direkt, men inga tips ges gällande
vilka som är lämpliga att använda.
24
6.1. Resultat
6.1.2
Implementation
Det finns ett stort antal implementationer som kunde övervägts. I och med att systemet på
kundens önskemål skulle utvecklas som en webbapplikation minskade valfriheten något.
Det finns ett antal olika verktyg som generellt används för webbutveckling, där de vanligaste
är HTML, CSS och JavaScript. Det är möjligt att systemet sett radikalt annorlunda ut om
kravet på att systemet skulle vara en webbapplikation inte existerat. Dels för att det ger
tillgång till en annan uppsättning verktyg, men också för att projektmedlemmarna hade
begränsad erfarenhet av webbutveckling vid projektets start.
Betraktas olika implementationer ur ett webbutvecklingsperspektiv dyker frågan om
JavaScript-ramverk ganska snabbt upp. Valet att inte använda ett sådant vid utvecklingen av
systemet kan ifrågasättas. Hur detta påverkat systemet undersöks djupare i individuell del A.
JavaScript har också stöd för prototypbaserad objektorientering. Det hade varit möjligt
att implementera en mer objektorienterad lösning än den nuvarande. En sådan lösning
kunde lett till mer inkapslad funktionalitet, men kanske också mer arbete som eventuellt inte
bidragit till en förbättring av underhållbarheten eller minskad komplexitet hos mjukvaran.
Detta på grund av mjukvarans relativt begränsade omfattning.
Projektet följde ett antal konventioner som växte fram under projektets gång. Konventioner är dock inget som påtvingas av språket eller systemet i sig, vilket innebär att framtida
utvecklare bör vara insatta i dessa för att enkelt kunna vidareutveckla systemet. Hur lätt det
är att vidareutveckla systemet beror alltså till stor del på hur väl utvecklingskonventionerna
förmedlas vidare. Eftersom mjukvaran publicerats som ett projekt med öppen källkod finns
en risk att dessa konventioner förbises och med tiden dör ut. Detta då ett potentiellt stort
antal utvecklare kan bidra till projektet, och risken finns att nya utvecklares snabba lösningar
på problem inte alltid följer de etablerade konventionerna. När de lösningarna sedan orsakar
nya problem löses dessa på samma sätt, istället för att den egentliga orsaken till problemet
identifieras.
6.1.3
Värde för kunden
Här diskuteras systemets värde för kunden. Ett av de större målen med projektet var att
kunden skulle få en tillfredställande produkt framtagen. Kunden önskade ett system som
dels var mer lättanvänt än det tidigare, och som dessutom var underhållbart med möjlighet
till vidareutveckling i framtiden. Värdet av systemet beroende på hur det brukas av kunden
tas upp. Därefter behandlas de beslut som tagits för att skapa värde för kunden.
Värde beroende på användning
I avsnitt 5.3 beskrevs ett antal attribut hos systemet som är av värde för kunden, men för
att produkten ska uppnå sitt fulla värde återstår att systemet tas i aktivt bruk. Det krävs
exempelvis också att någon form av vidareutveckling eller underhåll av systemet sker för att
systemets underhållbarhet ska ha ett faktiskt värde för kunden.
Att systemet inte tagits i bruk än i skrivande stund innebär däremot inte att det helt saknar
värde ur kundens perspektiv. Även om systemet aldrig tas i bruk kan kunden ha kommit till
viktiga insikter gällande vad de vill ha ut av ett nytt system. Kunden har också erhållit en
ny referenspunkt, utöver det gamla systemet Enigma 1.2, som kan användas för att beskriva
eventuella önskemål med ett helt nytt system.
25
6.1. Resultat
Öppen källkod
När projektet avslutades publicerades projektet på GitHub under öppen källkod. Därmed
kan alla som hittar buggar fixa dem och sedan göra en merge request. Allt eftersom tiden går
kommer fler och fler buggfixar och refaktoreringar utföras. Kunden får därmed också fortsatt
granskning av systemets kodbas vilket förhoppningsvis bidrar till systemets livslängd. Det
är också den öppna källkoden som möjliggör framtida utveckling av kunden eller utvecklare
anlitade av kunden, i motsats till proprietär programvara.
Dokumentation
Fördelen med teknisk dokumentation är att flytande text och bilder gör sig bättre än kod för
att på ett snabbt sätt beskriva komplexa system på ett övergripande sätt.
Problemet med att ha teknisk dokumentation som förklarar vad koden gör är att dokumentationen ofta inte underhålls i samma takt som kodbasen utvecklas. Detta leder till
att dokumentationen hamnar efter och därmed kan informationen bli inaktuell. Inaktuell
teknisk dokumentation kan vara missvisande och bidra till mer förvirring än förklaring.
Syftet med att JSDoc används som dokumentation är att låta nya utvecklare sätta sig in i
systemet på ett effektivt sätt, och att underlätta vidareutveckling. Anledningen till att JSDoc
använts är att chansen är större att en utvecklare uppdaterar de kommentarer som ligger i koden i anknytning till funktionaliteten än att denne öppnar ett annat dokument och beskriver
förändringar där.
Kodkvalitet
I och med att parprogrammering och kodgranskning har använts kan man argumentera för
att kvaliteten på koden är hög. Som nämns i avsnitt 4.5.2 fokuserade dessa på att öka kodens
läsbarhet. Kodgranskning i samband med parprogrammering gjorde att minst tre personer
har läst och godkänt den kod som skrivits, vilket ökar chansen att koden är läsbar. Läsbar
kod medför att det blir lättare för nya utvecklare att förstå hur systemet fungerar.
Att kodbasen följer etablerade standarder bidrar till kvaliteten eftersom dessa standarder är
något många utvecklare känner till och har en vana att arbeta med. Det låter nya utvecklare
fokusera på innehållet och dess betydelse istället för att lägga tid på att bekanta sig med dess
utformning.
Webbapplikation
Då systemet utvecklats som en webbapplikation är det till stor del plattformsoberoende
vilket bidrar till en större frihet för studenterna som läser kursen. Det blir möjligt att enkelt
arbeta med laborationen både från en egen dator och ISY:s datorsystem. Arbete från andra
platser har tidigare förutsatt att studenten är bekväm med att använda en SSH-klient [26],
exempelvis OpenSSH [27], för att ansluta till ISY. Nu kan alla med webbläsarvana arbeta från
valfri plats.
Ytterligare en fördel med webbapplikationer är att systemet kan anpassas till andra hårdvaruplattformar än stationära och bärbara datorer. Det går att tänka sig att applikationen
anpassas till exempelvis surfplattor eller mobiltelefoner också. Detta är betydligt svårare
med en systemapplikation.
Laborationsassistenter behöver inte ge lika mycket teknisk hjälp som innan, utan kan
fokusera på laborationsinnehållet istället för miljön. Detta dels eftersom det inte var en helt
26
6.1. Resultat
enkel process att starta det gamla systemet, men också eftersom Knekt presenterar tillgänglig
funktionalitet på ett mer överskådligt sätt.
6.1.4
Erfarenheter
Problem som uppmärksammades under iterationsutvärderingarna diskuterades på plats och
man försökte att gemensamt hitta en lösning. Frågan skulle sedan komma att tas upp under
nästa utvärdering för att se om det skett en förbättring eller om ytterligare åtgärder krävdes.
Detta gjorde det enkelt att se om förbättringsförslagen fick önskad effekt. Nedan följer några
exempel:
• Ett område som tydligt går att följa i utvärderingarna är vilket system för tidrapporteringen som användes. Initialt användes Trello, där flera anmärkte i utvärderingen för
förstudien att det var krångligt att använda. I sammanställningen av förbättringsförslag
framgår att gruppen ämnade byta till kalkylark på Google Drive. I utvärderingen för iterationen efteråt går det att läsa från flera personer i gruppen att nya tidrapporteringen
fungerar väldigt bra.
• Måenderundorna är en punkt som omnämns ofta och med positiva ordalag i
utvärderingarna. Förutom en person som tycker de tar för mycket mötestid är alla
odelat positivt inställda till dem.
• I utvärderingen av iteration 1 önskades en andra kickoff. Det lades till under förbättringsförslag, genomfördes och prisades i nästa utvärdering.
Konsekvenserna av utvärderingarna kan tänkas vara många. Bland annat bidrog det till en
bättre sammanhållning bland projektmedlemmarna – när problem uppmärksammades och
hela gruppen involverades i att åtgärda dessa upplevdes det som att alla arbetade gemensamt. Många gånger hade medlemmarna liknande erfarenheter kring punkterna vilket kan
ha bidragit till en känsla av samhörighet till gruppen. Detta kan dock haft motsatt effekt
för de med en annan erfarenhet, om de upplever att “alla andra” haft andra tankar kring
en fråga. Det är då möjligt att den medlem som haft en avvikande åsikt känt sig isolerad
och kanske undvikit att ta upp sin syn på saken. Det kan också tänkas att en medlem känt
sig personligt ansvarig för en företeelse som de andra medlemmarna upplevt som negativt,
vilket ytterligare bidragit till en känsla av att vara utanför gemenskapen. Det har inte uppmärksammats något sådant fall, men det kan bero på de anledningar som tagits upp här.
I och med att projektgruppen redan under förstudien diskuterade de erfarenheter som kommit från tidigare projektarbeten kunde det tidigt fastställas vad som borde undvikas eller
vad som var önskvärt gällande arbetsmetod, gruppdynamik, verktyg, utveckling etc. Ett
område där det tydligt framgår att gruppen lyssnat på varandras åsikter är utveckling, där
alla önskemål uppfylldes och alla tidigare problem förhindrades.
6.1.5
SEMAT kernel alphas
I början lade gruppen lång tid på genomgångarna av alla SEMAT kernel alphas, med utförliga diskussioner kring varje tillstånd och huruvida det uppnåtts eller när under projektet
det skulle uppnås. Under de senare genomgångsmötena gick det klart fortare. Det kan
tänkas bero på att gruppmedlemmarna mot slutet hade betydligt bättre koll på projektet och
hur det låg till, och därför snabbare kunde avgöra vilka tillstånd som uppnåtts och vilka
som inte uppnåtts. Det kan också tolkas som att gruppmedlemmarna mot slutet kände
mindre behov av att utförligt prata igenom alla tillstånd, då de redan upplevde sig ha koll
på projektet.
27
6.2. Metod för insamling av erfarenheter
En annan intressant notering är att gruppen genom hela projektet legat i fas med den ursprungliga uppskattningen, eller före. Det kan tolkas som att gruppen genom att ha gjort
planeringen fick en tydlig bild av vad som skulle göras och när, och sedan följde den. Det
kan också tolkas som att projektgruppen var bra på att planera.
6.2
Metod för insamling av erfarenheter
Eftersom iterationsutvärderingarna fylldes i för hand under speciella utvärderingstillfällen
fanns en tidsbegränsning för hur lång tid det fick ta. Under de två avsatta timmarna hade
deltagarna oftast omkring 30 minuter på sig att fylla i formulären. Detta kan ha medfört att
alla tankar eller åsikter inte hann skrivas ned eller att enbart de “viktigaste” punkterna lyftes
fram. Det är också möjligt att alla medlemmar inte hann reflektera särskilt mycket kring
varje punkt innan de gick vidare med nästa del.
Efter att formulären fyllts i hölls en diskussion kring varje punkt. Först fick alla deltagare
uttrycka sina egna tankar och sedan diskuterades eventuella problem som uttryckts. En konsekvens av detta kan vara att vissa deltagare kanske var obekväma med att ta upp kritik inför
gruppen eller orolig för att någon skulle ta illa upp och därmed höll negativa upplevelser
för sig själv. Dessa har i sådant fall inte tagits upp för diskussion och har därmed heller inte
behandlats som ett förbättringsförslag till nästa iteration.
Utvärderingarna fylldes i med namn och var således inte anonyma. Även om deltagarna
valde att inte ta upp vissa punkter till diskussion inför hela gruppen skulle ändå gruppens
teamleader, samt i vissa fall någon mer gruppmedlem, läsa igenom och sammanställa alla
svar. Kanske skulle fler problemområden eller känsliga punkter ha kommit till ytan ifall
utvärderingarna lämnats in anonymt.
6.3
Arbetet i ett vidare sammanhang
Kryptoteknik är en grundläggande förutsättning för dagens informationssamhälle. Det
möjliggör för miljoner människor att utföra vardagliga uppgifter över internet, exempelvis bankärenden eller interaktion med olika myndigheter. Det gör det också möjligt
för demokratiförkämpar att kommunicera med likasinnade i länder med regimer som utövar
förtyck mot sina medborgare. Samtidigt är det också kryptoteknik som tillåter terrorister att
planera sina dåd och i vissa fall undgå upptäckt.
De kryptotekniker som lärs ut med hjälp av Knekt kan inte användas till något av det som
nämns ovan. Däremot kan det kanske vara dessa tekniker som framkallar ett intresse hos en
student som läser kursen. Det kan sedan leda till en framstående forskarkarriär för denne
med stora framsteg inom just kryptoteknik. Därmed kan Knekt indirekt vara med och
påverka det som beskrivits tidigare. Huruvida denna påverkan blir av positiv eller negativ
karaktär beror på personen samt typen av framsteg.
Med det sagt, för att underhålla den stora mängd system som idag använder sig av kryptoteknik krävs kompetent arbetskraft. Utbildningen av denna arbetskraft måste påbörjas på
något sätt, och där är Knekt ett alternativ.
Då Knekt ersätter ett befintligt system rakt av, och kommer användas på samma sätt och
i samma utsträckning som det tidigare systemet, leder arbetet inte till någon ytterligare
miljöpåverkan.
28
7
Slutsatser
Detta kapitel redogör för de slutsatser som erhållits ur resultatet som presenterades i avsnitt
5. Kapitlet ämnar besvara frågeställningen i avsnitt 1.3.
7.1
Gränssnittsdesign
För att underlätta för användbarheten har handlingsinviter implementerats. Detta för att
användaren ska förstå hur element kan manipuleras. Drag and drop är implementerat för
att användaren ska kunna använda programmet på ett intuitivt sätt. Systemet är enhetligt
vilket minskar tiden det tar för användaren att lära sig systemet. Detta är beslut som kan ha
positiva effekter på användbarheten.
Konsekvenserna av de beslut som tagits är att det system som utvecklats har fokus på att
förstagångsanvändare lätt ska komma igång, snarare än att vana användare ska vara effektiva. En effekt av det är att en van användare inte är mycket snabbare än en nybörjare.
En del av de beslut som tagits baserat på att systemet ska användas i utbildningssyfte har
försämrat användbarheten. Systemet kräver att användaren har en förståelse för ämnet och
tillvägagångssätten som kan användas för att dekryptera texter. Detta är önskvärt ur ett
pedagogiskt perspektiv, men ur ett användbarhetsperspektiv hade det varit önskvärt att ge
användaren mer hjälp.
7.2
Värde för kunden
Kunden ville ha en interaktiv webbapplikation med samma funktionalitet som det gamla
programmet. Programmet skulle vara lättanvänt, interaktivt och alla beräkningar skulle
göras på klientsidan. Det skulle levereras under öppen källkod samt ha god dokumentation
och abstraktion för att förenkla vidareutveckling och underhåll.
För att skapa värde för kunden har gruppen därför jobbat med just dessa områden. En
interaktiv webbapplikation har skapats där systemet har samma funktionalitet som det äldre
programmet. För att göra programmet mer lättanvänt har systemet fått en tydlig struktur
med ett navigationsfält, ett verktygsfält och en statistikpanel.
För att underlätta vidareutveckling och underhåll har systemet delats upp i moduler. Detta
avser förenkla för framtida implementationer av exempelvis nya dekrypteringsverktyg eller
29
7.3. Erfarenheter
statistikverktyg. Utöver det har en användarhandledning, en README-fil samt dokumentation i form av JSDoc skrivits.
Utöver dokumentation har även kodgranskning och parprogrammering använts för att öka
kodens läsbarhet. Lättläst kod förenklar underhåll av systemet.
För att ytterligare bidra till underhållbarheten har systemet publicerats på GitHub under
MIT-licens och finns alltså tillgängligt för allmänheten. Vem som helst med tillgång till
internet kan därmed vidareutveckla eller underhålla systemet.
Sammanfattningsvis har värde skapats för kunden genom att kundens begärda system har
skapats.
7.3
Erfarenheter
Följande erfarenheter har projektmedlemmarna identifierat som särskilt intressanta eller viktiga för framtida, liknande projekt:
• Måenderundor bidrar till personlighet och sammanhållning inom gruppen.
• Att jobba för god stämning i gruppen ger mycket goda förutsättningar för alla former
av arbete.
• Var öppna för att byta verktyg som inte fungerar bra (till exempel tidrapportering i
Trello).
• Dagordningar och mötesprotokoll med tydligt innehåll fungerar som stöd under möten
och gör det mindre jobbigt att vara frånvarande eller vara med på distans.
• Online-baserad lagring av alla dokument säkerställer att alla får tillgång till gemensamma filer. Versionshantera det som behövs (framförallt kod).
• Tydlig rollfördelning som definierar ansvarsområde underlättar framförallt i början.
Det bidrar till att minska risken för konflikter som beror på problem med arbets- och
ansvarsfördelning.
• Att låta en mindre grupp arbeta med det grafiska gränssnittet (GUI-gruppen) och ta
fram förslag som sedan hela gruppen fått besluta om har fungerat bra. GUI-gruppen
kan med fördel vara självbestämmande i sina beslut.
• Det är viktigt att ha en god och trygg stämning vid iterationsutvärderingar. För
att lyckas med detta behövs gott om tid för att undvika stress. Eventuellt kan
utvärderingarna fyllas i på dator eller i förväg för att snabba upp processen. Fika under
utvärderingen har positiva effekter. Möjlighet till anonymitet vid känsliga ämnen är
önskvärt.
• Att sitta tillsammans och arbeta i arbetsstugor har haft positiva effekter på både produktkvaliteten och samarbetet i gruppen. För att förstärka dessa effekter bör ett kontor
finnas till hands för att garantera att det alltid finns en plats för gemensamt arbete.
7.4
SEMAT kernel alphas
SEMAT kernel alphas användes i stort sett bara i planering och för att se hur gruppen
låg till i projektet. Det var alltså inte styrande på något sätt under själva utvecklingen.
Eftersom användandet av SEMAT kernel alphas enbart skedde i planeringsprocesser var
effekterna främst synliga just i själva planeringen av projektet. Planeringen i projektets
30
7.4. SEMAT kernel alphas
förstudie använde sig av SEMAT kernel alphas för att både visualisera vilka områden i
utvecklingsprocessen som skulle uppnås och när områdena skulle uppnås. Flera alpha states
var ej självklara när de skulle planeras in, detta ledde till diskussioner inom gruppen. Efter
diskussionerna fanns det inga uttalade oklarheter om vad som skulle uppnås, eller när det
skulle uppnås.
Alla gruppmedlemmar visste vad slutmålet var vilket medförde att även om inget aktivt användande av SEMAT kernel alphas skedde under iterationerna så påverkade det arbetet indirekt. Om gruppen hade legat bakom med något alpha state hade det uppmärksammats under
iterationsplaneringarna. Även om det inte hände i just detta projekt kan man argumentera för
att SEMAT kernel alphas faktiskt var ett stöd, eftersom det agerade förebyggande. Man kan
också dra slutsatsen att eftersom gruppen inte var helt enig i början med hur utvecklingsprocessen skulle gå till, bidrog SEMAT kernel alphas till samstämmighet inom gruppen. Under
mötena efter iterationerna kunde man även tydligt se framsteg som skett i utvecklingsprocessen vilket var motiverande. På de sätten fick alltså gruppen stöd av att använda och följa
upp SEMAT kernel alphas.
31
Del II
Individuella bidrag
32
A Fredrik Bergstrand:
JavaScript-ramverks effekt på
underhållbarhet
A.1
Inledning
Ett vanligt tillvägagångssätt när webbapplikationer utvecklas idag är att använda ett existerande JavaScript-ramverk. Den här individuella rapporten utgår från systemet beskrivet i
rapportens huvuddel, kallat Knekt. Systemet i fråga är uppbyggt utan hjälp av något ramverk.
Med hjälp av komplexitetsmått undersöks vilken effekt användandet av ett JavaScriptramverk hade haft på systemets underhållbarhet.
A.1.1
Syfte
Syftet med den här rapporten är att med hjälp av komplexitetsmått utreda hur användningen
av ett etablerat JavaScript-ramverk hade påverkat underhållbarheten hos systemet beskrivet
i rapportens huvuddel under avsnitt 5.2.
A.1.2
Frågeställning
Följande frågeställning ligger till grund för arbetet som beskrivs i rapporten:
1. Hur hade användningen av ett etablerat JavaScript-ramverk påverkat underhållbarheten hos systemet Knekt?
A.2
Bakgrund
Idag sköts fler och fler uppgifter på internet, och webbaserade tjänster ökar kraftigt. Ett
allt större antal enheter av olika slag kopplas upp till nätet där de presenterar någon form
av data och/eller kan styras. För att tillgodose det behov som finns av att snabbt utveckla
webbtjänster har ett antal ramverk för utveckling av applikationer vuxit fram. Särskilt så
kallade Single Page Applications (SPA) har ökat i popularitet. En SPA är en applikation som
körs i en webbläsare men som vid navigation i applikationen inte kräver någon omladdning
av sidan. Detta är möjligt antingen genom att allt innehåll hämtas vid den initiala sidhämtningen [28], eller genom att nytt innehåll hämtas asynkront vid användning av systemet.
Ramverkens syfte är bland annat att minska det arbete som krävs från idé till färdig tjänst,
samt tillhandahålla vanlig funktionalitet som behövs i majoriteten av alla applikationer. Ett
par av de vanligaste uppgifterna som förenklas är att hantera de asynkrona dataöverföringar
33
A.3. Teori
mellan klient och server som ofta krävs i en SPA, samt separera datamodell, vy och händelsehantering.
A.3
Teori
I teoridelen presenteras de mått som använts i undersökningen, samt annan relevant kunskap
som behövs för att tillgodogöra sig innehållet i rapporten.
A.3.1
Resursfördelning vid mjukvaruutveckling
En majoritet av de resurser som spenderas på ett mjukvarusystem går inte till den initiala
utvecklingen, utan till underhåll och reparation av systemet [29]. I extremfall uppnår andelen som går till underhåll 80 % av de totala kostnaderna för systemet [29]. För system
som ska vara i drift under längre tid är det också viktigt att det finns möjlighet att modifiera
systemet och anpassa det till förändringar i driftsmiljön [3]. Underhållbarhet är alltså en
viktig kvalitetsfaktor att ta hänsyn till vid utveckling av ett mjukvarusystem.
Det finns starka kopplingar mellan ett systems komplexitet och kostnaderna associerade med
underhåll av systemet [30]. Ett sätt att minska underhållskostnaderna för systemet är alltså
att sträva efter en kodbas som är så ickekomplex som möjligt. För att mäta komplexiteten hos
en kodbas finns det flera mått att tillgå.
A.3.2
Komplexitetsmått
Oman och Hagemeister introducerade 1991 ett mått på mjukvaras underhållbarhet kallat
Maintainability Index (MI) [31]. Måttet definieras som
MI = 171 ´ 3, 42 ln( aveE) ´ 0, 23 ln( aveV ( g1 )) ´ 16, 2 ln( aveLOC )
där E innebär Halsteadansträngning (Halstead effort), V ( g1 ) står för utökad cyklomatisk
komplexitet och LOC är antal rader kod. Prefixet ave innebär att det är det genomsnittliga
värdet över alla moduler i kodbasen som används. Ett högre värde innebär bättre underhållbarhet. MI-uttrycket har sedan det först introducerades modifierats och utökats på ett antal
sätt. En av dessa variationer återfinns exempelvis i “Metrics for assessing a software system’s
maintainability” av Oman och Hagemeister [32].
A.3.3
Complexity-report
Complexity-report är ett verktyg som utför automatiserad komplexitetsanalys av JavaScriptkodbaser med hjälp av det tidigare introducerade måttet Maintainability Index. Verktyget
är egentligen ett gränssnitt mot mjukvaran Escomplex som utför den faktiska analysen [33].
Escomplex utför analyser på abstrakta syntaxträd som genereras av verktyget Esprima [33]
[34].
A.4
Metod
Här beskrivs metoden som följts för att erhålla de resultat som presenteras i rapporten.
A.4.1
Jämförelsekandidater
För att det skulle vara möjligt att utföra en jämförelse av systemet beskrivet i rapportens huvuddel med andra system byggda med ramverk behövde ett antal sådana system identifieras.
Valet föll på ett antal mindre projekt tänkta som exempelprojekt för respektive ramverk, där
dessa projekt demonstrerar olika egenskaper hos ramverken i fråga. De ramverk som valdes
34
A.5. Resultat
ut för jämförelse var AngularJS [12] och EmberJS [13]. Följande lista med projekt användes
slutligen i jämförelsen:
1. CustomerManagerStandard [AngularJS] - en exempelapplikation för hantering av kunder [35].
2. FoodMe [AngularJS] - en applikation för hantering av beställningar på restauranger
[36].
3. Ember.js Dashboard [EmberJS] - en applikation som samlar information och nyheter
om EmberJS från ett antal olika källor [37].
4. Knekt - en applikation som används vid en laboration i kryptoanalys för att dekryptera
meddelanden krypterade med en av tre olika tekniker.
I vissa projekt som initialt skulle ingått i studien användes JavaScript-funktionalitet som
inte fanns standardiserad. Complexity-report kunde inte hantera den funktionaliteten vilket
ledde till att projekten fick uteslutas från studien.
A.4.2
Mätning
För att utföra underhållbarhetsmätningarna användes verktyget Complexity-report [33]. En
mätning utfördes på varje projekts respektive kodbas, inklusive Knekts. För att ge ett rättvist
resultat vid mätningarna var det viktigt att försäkra sig om att Complexity-report endast
analyserade projektspecifik kod, och inte exempelvis källkoden till bibliotek eller ramverk
som använts i projekten. Complexity-report är ett kommandoradsverktyg, och följande kommando användes för att utföra mätningarna:
Kodexempel A.1: Invokering av Complexity-report.
cr -o <projektnamn>-report.txt <kataloger med projektspecifik kod>
Complexity-report sparade då resultatet av analysen i den specificerade utdatafilen. Utdatafilen inleddes med en sammanställning av mätningarna, där bland annat det resulterande MI-värdet kunde utläsas.
A.5
Resultat
I tabell A.1 presenteras de respektive projektens MI-värden.
Tabell A.1: MI-värden för de undersökta projekten.
Projekt
Ember.js Dashboard
FoodMe
CustomerManagerStandard
Knekt
MI-värde
139,7
135,0
129,2
115,1
De resultat som presenteras i tabell A.1 är det genomsnittliga MI-värdet över alla moduler
i respektive projekt. MI-värdet har avrundats till fyra värdesiffror. Sammanfattningen från
Complexity-reports rapportfil för de olika projekten återfinns i bilaga 3.
A.6
Diskussion
Här diskuteras tillvägagångssätt som använts och resultat som erhållits under studien.
Eventuella felkällor behandlas också. Värt att notera är att resonemang som förs här bör appliceras med försiktighet på andra projekt där omfattningen skiljer sig mycket jämfört med
35
A.6. Diskussion
projekten i den här studien. Det kan tänkas att den infrastruktur ramverken tillhandahåller
gör ett litet projekt mycket mer komplext är nödvändigt. På samma sätt kan tillvägagångssättet utan ramverk bli ohållbart i ett större projekt där tydlig struktur och fasta konventioner
krävs.
A.6.1
Metod
Något som bör klargöras när mätningar av den typ som beskrivs i rapporten utförs är att
måtten som erhålls inte är absoluta mått på underhållbarhet. Det finns flera andra faktorer
som inte tas i beaktande med metoden och måtten som använts i studien, exempelvis kodkommentarer.
Data som fås genom underhållbarhetsmätningar används kanske lämpligast genom att studera om det finns oregelbundna tendenser i denna. Finns moduler som kraftigt avviker till
det sämre i mätningarna kan det vara en anledning att manuellt granska modulerna i fråga
och undersöka orsaken till de dåliga värdena.
Den data som använts i studien har också hämtats från ett litet antal projekt. Ett större antal
hade gett ett resultat som varit statistiskt säkrare, men hade tagit längre tid.
Det går också att ställa sig frågan vad som är mest fördelaktigt av att antingen behöva lära sig
ett ramverk för att förstå en ny kodbas, eller enbart sätta sig in i kodbasen givet att utvecklaren i fråga redan är förtrogen med det använda språket. Det kan tänkas att utvecklaren
lätt kan sätta sig in i koden när denne väl lärt sig ramverket och dess principer. Det kan å
andra sidan också vara lättare för utvecklaren att enbart sätta sig in i en kodbas utan ramverk
beroende på ramverkets inlärningskurva. Detta är situationsberoende, och i det hänseendet
ger inte MI-måttet någon information. Handlar det om ett åtagande att underhålla kodbasen
under en längre tid kan det vara fördelaktigt att först utbilda sig i ramverket, och sedan i
gengäld ha en mer trivial kodbas att arbeta med. Handlar underhållsarbetet däremot om mindre sporadiska åtgärder kan utbildningen bli ett orimligt stort moment relativt åtgärderna.
A.6.2
Felkällor
De externa projekt som mätningarna utfördes på är skrivna av erfarna webbutvecklare, och
medlemmarna i det här projektet hade inledningsvis en mycket begränsad erfarenhet av
webbutveckling. Det är möjligt att resultatet sett annorlunda ut om medlemmarna hade haft
en annan bakgrund.
Projekten har också en relativt begränsad omfattning, det är möjligt att skillnaderna i resultatet varit tydligare i större projekt, där den struktur och de mekanismer ramverken
tillhandahåller visar sin fulla potential.
I och med att ett antal projekt fick uteslutas då Complexity-report inte kunde hantera den
utökade JavaScript-funktionaliteten som använts i dessa projekt blev dataunderlaget mindre
än planerat. Resultatet kunde sett annorlunda ut om dessa projekt tagits med. Studien
behandlar följaktligen inte heller effekten av funktionaliteten som inte kunde hanteras.
A.6.3
Resultat
I det erhållna resultatet syns att Knekts MI-värde ligger lägre än de andra projekten. Det
kan finnas flera orsaker till detta. Exempelvis analyserades enbart projektspecifik kod i
de tre externa projekten, vilket innebär att grundläggande funktionalitet som abstraheras
36
A.7. Slutsatser
bort av ramverken inte tas med i analysen. I analysen av Knekt behandlas sådan kod som
projektspecifik vilket kan bidra till det erhållna resultatet.
Det nämndes tidigare under diskussionen om felkällor att projektmedlemmarna hade väldigt
begränsad erfarenhet av webbutveckling innan det här projektet. Det kan också vara en
bidragande faktor.
För att sammanfatta resultatet så erhöll Knekt komplexitetsmässigt en sämre underhållbarhet
än motsvarande externa projekt där ett ramverk använts. Att detta leder till sämre underhållbarhet är inte helt säkert. Vad resultatet däremot berättar är att system som utvecklas ovanpå
ett ramverk får en kodbas som är mindre komplex då ramverken i sig exkluderas. Den kod
utvecklare som underhåller systemet behöver bekanta sig med blir mer trivial, förutsatt att
utvecklarna känner till ramverket.
Något som dock ska tas i beaktande om ett ramverk väljs på grund av en önskan om långsiktigt underhåll och vidareutveckling är att ramverk kan sluta underhållas av de utvecklare
som står bakom ramverken. Det är en risk som får bedömas utifrån vilket ramverk som väljs,
vilken organisation som underhåller det och hur modernt ramverket är.
A.7
Slutsatser
Slutsatserna som kan dras från studien blir att system som utvecklas med hjälp av ett ramverk
får en projektspecifik kodbas som blir mindre komplex än kodbasen hos ett motsvarande
projekt utvecklat utan ramverk. Det bidrar till kod som har en högre underhållbarhet.
Huruvida den totala underhållbarheten påverkas positivt eller negativt är det svårt att göra
ett generellt uttalande om. Det beror på hur enkelt en utvecklare som inte är bekant med det
använda ramverket kan tillgodogöra sig tillräcklig kunskap för att kunna utföra underhåll
på ett tillfredsställande sätt. Om det endast är mindre korrigeringar som ska utföras kan
ansträngningen som krävs för att lära sig ett ramverk bli oproportionerligt stor relativt förändringarna som ska utföras. Handlar det däremot om långsiktigt underhåll och eventuell
vidareutveckling lönar det sig att använda ett ramverk då det i det långa loppet är till fördel
för framtida utvecklare. Detta eftersom ramverken ger en komplexitetsmässigt enklare kodbas att arbeta med, och tiden det tar att lära sig ramverket blir liten i förhållande till den tid
som spenderas på utveckling.
Gällande Knekt dras slutsatsen att ett ramverks påverkan på dess underhållbarhet till sist
beror på vilken typ av vidareutveckling som utförs av kunden i framtiden. Handlar det om
mindre underhållsarbete för att hålla systemet i funktionellt skick är valet att inte använda ett
ramverk fördelaktigt. Om däremot omfattande funktionalitet läggs till kan det vara så att ett
ramverk hade förenklat det framtida arbetet, dock med en existerande risk att det ramverk
som valts idag inte underhålls längre fram i tiden då dessa omfattande tillägg blir aktuella.
37
B Kimberley French: Värdet av en
prototyp
B.1
Inledning
Hur går man tillväga vid utformningen av ett nytt grafiskt användargränssnitt? På vilket
sätt underlättar en prototyp för utvecklingsarbetet och är det värt den tidsinvestering som
krävs? Denna rapport utforskar vilken betydelse prototypning har i framtagandet av ett
mjukvarusystem.
B.1.1
Syfte
Syftet med arbetet är att undersöka vilka för- och nackdelar det finns med att göra en prototyp i samband med utvecklingen av ett mjukvarusystem. Rapporten behandlar de faktorer
som har framträtt för denna projektgrupp och andra projektgrupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Även de processer som kan användas för att arbeta
fram en prototyp presenteras i korthet.
B.1.2
Frågeställning
Rapporten behandlar frågeställningarna nedan.
1. Vad finns det för värde i att ta fram en prototyp?
2. Vilka nackdelar finns det med att arbeta med prototyper?
3. Vilka processer är lämpliga att använda i framtagandet av en prototyp för mjukvarusystem?
B.2
Bakgrund
I och med utvecklingen av ett nytt webbaserat system måste ett grafiskt gränssnitt utformas. Gränssnittet är systemets interagerbara representation som används för att kunna ta
del av dess funktionalitet. Därför är det viktigt att systemet är användbart för sin målgrupp
och simpelt att lära sig. Till hjälp i beslutstagandet görs ibland prototyper, detta för att utforska olika alternativ och få en bild av vad slutresultatet kan bli. Prototyper används ofta
till användartester och för tidiga demonstrationer för kund. De underlättar även vid utvecklingen av systemet. Det finns dock en risk att prototyputvecklingen kräver mycket tid och
att kostnaden för den färdiga prototypen är högre än nyttan den bidrar med [38]. Rapporten
38
B.3. Teori
undersöker om så har varit fallet för projektgrupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling.
B.3
Teori
Detta kapitel beskriver vad en prototyp är och benämner några olika klasser av prototyper.
Processen för hur ett interaktivt system kan arbetas fram behandlas också, där olika faser
beskriver arbetet från idé till färdig produkt.
B.3.1
Prototyper
En prototyp är ett till synes fungerande system eller delsystem där endast ett begränsat antal
funktioner är implementerade. Prototypen används för att testa de designbeslut som tagits
vilket i sin tur avgör ifall vissa delar bör omarbetas innan implementering av systemet sker.
Eftersom prototypen inte är tänkt att vara ett färdigt, fungerande system kan man simulera
de delar som inte kan eller behöver byggas i detta skede – så länge systemet upplevs vara
färdigt på ytan kan variabler och sökresultat vara hårdkodade. [5]
Beroende på vad syftet med prototypen är kan den utformas på olika sätt. Nedan följer en
kort beskrivning av olika klasser av prototyper enligt Floyd [38]:
• Utforskande prototypning används för att förtydliga systemkraven och diskutera alternativa lösningar.
• Experimentell prototypning presenterar en lösning på ett känt problem och används
för att testa funktionaliteten av denna lösning.
• Evolutionär prototypning innebär att utforma prototypen i flera steg där varje version
anpassas efter de krav som uppstår allt eftersom utvecklingen sker.
Till skillnad från den evolutionära typen, kastar man ofta bort utforskande och experimentella prototyper efter att de byggts och testats. Denna typ av prototyper brukar refereras till som temporära. Tanken bakom en temporär prototyp är att de skall göras billiga och
utan större ansträngning så att de idéer som testas är enkla att kassera om det skulle visa sig
att de inte var bra. Evolutionära prototyper används ofta i projekt med agila arbetsmetoder,
exempelvis Scrum [1], där varje version utvecklas under de så kallade sprintarna. [5]
B.3.2
Designprocessen hos ett interaktivt system
Enligt Arvola [5] består designarbetet av en produkt från idé till färdigt system av tre faser.
Dessa faser är konceptfasen, bearbetningsfasen och detaljeringsfasen. De processer som sker
i varje fas beskrivs nedan.
Konceptfasen innefattar identifiering av systemets tänkta användning och generering av
koncept. Genom att identifiera hur produkten eller tjänsten är tänkt att användas – i vilket
sammanhang, av vem, varför den behövs – kan man sätta upp mål och krav för produkten
och projektet. När de övergripande avsikterna har fått klarhet kan olika koncept börja arbetas
fram. För att konkretisera sina idéer finns ett antal frågor man bör ställa sig: vad konceptet är
för något, varför användaren vill ha och använda det och hur det ska vara.
Bearbetningsfasen utformar gränssnittet och alternativa lösningar på problem tas fram
och värderas. Från det koncept som valts struktureras de funktioner upp som produkten eller tjänsten ska ha samtidigt som frågan hur interaktion med användaren ska gå till
39
B.4. Metod
besvaras. Gränssnittsskisser ritas upp som innehåller information om funktioner samt systemets innehåll och struktur. När gränssnittsskissningen är klar blir nästa steg att göra en
interaktiv prototyp. Prototypen är det verktyg med vilket systemets användbarhet kan testas
mot tänkta användare. Utifrån de brister och styrkor prototypen har kan sedan omstruktureringar och förbättringar göras innan man går vidare till den tredje fasen i designarbetet.
Detaljeringsfasen fokuserar på att förfina det tidigare arbetet och gränssnittet bestäms nu
på detaljnivå. Det blir viktigt att tänka på vilken grafisk profil systemet är tänkt att ha, det
vill säga vilken känsla som ska förmedlas och de associationer användaren ska få av systemet.
När alla designbeslut är klara är det dags att lämna över sitt arbete för implementering, där
det oftast bara uppstår mindre ändringar av den grafiska designen innan den blir en färdig
produkt.
B.4
Metod
Kapitlet beskriver de metoder med vilka författaren har gått till väga för att besvara frågeställningarna i avsnitt B.1.2.
B.4.1
Litteraturstudie
Under första läsperioden av vårterminen 2016 samlästes denna projektkurs med en kurs
inom interaktiva system. Innehållet i den senare kursen har bidragit till mycket av kunskapen i detta arbete. Kurslitteraturen skrevs av examinatorn, Mattias Arvola, vilken
användes flitigt i arbetet med denna rapport.
Utöver detta gjordes Google-sökningar på “Prototype” och “Prototyping”. Sökprocessen
ledde till en artikel skriven av C. Floyd vilken definierar uttryck och processer som förekommer i prototyputveckling och hur de är tänkta att användas.
B.4.2
Undersökning
För att kunna besvara frågan om hur värdefull en prototyp är för utvecklingen av mjukvara
utfördes en undersökning med medlemmarna i denna projektgrupp samt andra projektgrupper som också använt sig av prototyper i sitt kandidatarbete. Undersökningen gick ut på att
svara på ett antal frågor kring hur prototypen använts, dels av varje enskild gruppmedlem
och dels av gruppen som helhet. Syftet med undersökningen var att avgöra huruvida prototyputvecklingen för de olika projektgrupperna underlättade för den fortsatta utvecklingen
samt om gruppmedlemmarna ansåg att den tid som investerats i prototyputvecklingen varit
lönsam för projektet som helhet.
Frågorna skickades ut i form av en online-enkät till de olika projektgrupperna. De frågor som
ställdes presenteras i bilaga 4.
B.5
Resultat
Enkäten skickades ut via mail till alla projektgruppers teamleader, som sedan vidarebefordrade denna till sina projektmedlemmar i de fall en prototyp hade använts. Totalt svarade
24 personer från 5 olika grupper. I bilaga 4 presenteras en sammanställning av svaren
från de tre grupper som hade flest deltagare i undersökningen. Figur B.1 visar fördelningen över det antal timmar respektive grupp uppskattat att de investerat i prototyputveckling.
40
B.5. Resultat
(a) Tidsåtgång grupp A
(b) Tidsåtgång grupp B
(c) Tidsåtgång grupp C
Figur B.1: Deltagarnas uppskattning över den totala mängd tid, i timmar, som lagts ner på prototypningsarbete
inom tillhörande projektgrupp.
Nedan presenteras några av de erfarenheter dessa grupper haft med respektive prototyp.
Fler erfarenheter återfinns i bilaga 4.
Fördelar med prototypen
• Kunde blicka tillbaka på vid implementering.
• Prototypen fungerade som guide för resterande i gruppen.
• Kunnat visa kund och få feedback, vilket gör att utvecklingsarbetet känns mer legitimt
och kundförankrat.
• Hela gruppen fick en tydlig bild och mål – blir lättare att arbeta.
• Tid slösades inte på onödig funktionalitet.
• Snabbt och enkelt att ändra efter kundens behag och resultaten från användartester.
• Uppmuntrade till utveckling.
• Kunde återanvända idéer därifrån.
Nackdelar med prototypen
• Prototypens funktionalitet var inte så bra.
• Handlingsinviter behandlades inte i prototyperna.
• Prototyparbetet kan ha försenat upprättandet av ett kodskelett.
• Mycket av designen bestämdes utifrån vad som ansågs möjligt att koda.
• Tvister i implementation och utformning.
• Tar mycket tid att göra en separat prototyp, särskilt i ett tidsbegränsat projekt.
• Ogenomtänkt struktur.
Grupperna gjorde sin prototyp på dator där grupp B och C arbetat med evolutionär prototypning. Grupp A var något oense där 25 % ansåg att prototypen var av evolutionär typ och
75 % istället tyckte att den var temporär. Genom att titta på de avsikter som dessa grupper
haft med prototypen kan kopplingar göras till de klasser som nämns i stycke B.3.1. Både
utforskande och experiementell prototypning har använts efter gruppernas behov. Nedan
presenteras några avsikter från sammanställningen.
41
B.6. Diskussion
Avsikt med prototypen
• Skapa en gemensam bild av produkten och ge gruppen ett mål.
• Utforska flera alternativ.
• Ta reda på hur/vilka funktioner som skulle med.
• Ta fram ett tilltalande GUI.
• Samla kunskap.
• Lära sig verktygen.
• Ta reda på vad kunden vill ha och få snabb feedback.
Samtliga projektgrupper hade tillsatt en mindre grupp att ansvara för prototyputvecklingen.
Inom de tre projektgrupper som ingick i sammanställningen tyckte minst 50 % från varje
grupp att prototypen underlättade tillräckligt för att vara värt den tidsinvestering prototyparbetet innebar. Endast 12,5 % från en av grupperna ansåg att arbetet inte direkt har varit
lönsamt. Fördelningen hos de olika grupperna presenteras i figur B.2.
Figur B.2: Projektgruppernas inställning till den tid som investerats i prototyputvecklingen.
B.6
Diskussion
Detta kapitel för en diskussion kring resultatet av undersökningen, eventuella brister hos den
enkät som låg till grund samt den teori som presenterats i rapporten.
B.6.1
Resultat
För att få en representativ bild av olika gruppers erfarenhet av att arbeta med prototyper
krävdes deltagande från flera personer inom samma projektgrupp. Detta för att få klarhet
i vad för prototyp som gjorts, hur den har använts och på vilket sätt den påverkat olika
projektmedlemmar. Alla projektgrupper bestod av 8–10 medlemmar totalt men deltagandet
var ofta mindre än hälften. Därför togs beslutet att endast de tre projektgrupper som haft
flest deltagare skulle inkluderas i resultatet och sammanställningen.
Ur svaren på enkäten framgår att projektgrupperna tillsatte en mindre grupp som ansvariga
för prototyputvecklingen. De projektmedlemmar som inte själva ingick i denna grupp hade
troligtvis en annan uppfattning, i jämförelse med de som varit involverade, om vad arbetet
42
B.7. Slutsatser
innebar och hur lång tid det tog. Vid en blick på fråga 2: Hur många timmar har lagts ner på
prototypningsarbete? har svaren inom samtliga grupper varit väldigt spridda (se figur B.1).
Grupp A var jämnt fördelade i intervallet 10–150 timmar. Inom grupp B verkar hälften av
deltagarna vara överens om att tidsåtgången var 200 timmar, medan andra hälften trodde
5–10 timmar. Spridningen inom grupp C var dock mindre och de uppskattade 20–60 timmar.
Som framgår av figur B.2 ansåg en överväldigande majoritet av gruppmedlemmarna att
tidsinvesteringen varit givande för utvecklingen. Eftersom deltagarantalet från vissa av
grupperna var lågt kan man även fundera över hur de som inte deltagit i undersökning hade
svarat. Det som enligt figuren ser väldigt positivt ut kan snabbt få ett mer negativt utslag
med endast ett par deltagare extra. Med hänsyn till det resultat som presenterats kan dock
slutsatsen dras att prototypens fördelar vägde upp för de nackdelar som uppmärksammats.
B.6.2
Metod
Frågorna i enkäten skrevs med en temporär prototyp i åtanke, eftersom det var den sorts
prototyp som användes i detta projekt. Det har medfört att vissa frågor inte direkt är applicerbara för de grupper som arbetat med evolutionära prototyper. En stor del av de svar
som samlats in är från grupper som arbetat med just evolutionär utveckling, där alltså “prototypen” de evaluerat i själva verket var en tidig version av slutprodukten. Detta innebär att
vissa av svaren inte kan ses som representativa då de beror på deltagarens egen tolkning av
frågan.
B.6.3
Teori
Mycket av den kunskap som hämtats in kommer från samma källa. Det gör att teorin lätt kan
bli ensidig och vinklad efter källförfattarens egna rekommendationer. Den artikel som också
användes i rapporten är från 1984 och därför bör det ifrågasättas hur mycket av innehållet
som gäller än idag. Man kan tänka sig att mycket har hänt inom prototypning i och med den
tekniska utveckling som skett sedan 1980-talet och framtagandet av nya hjälpverktyg inom
prototyputveckling.
Den process för framtagningen av gränssnittsdesign som presenteras i avsnitt B.3.2 är främst
anpassad efter temporära prototyper. Det är alltså inte säkert att denna metod lämpar sig
särskilt bra för projekt som arbetar med evolutionär utveckling.
B.7
Slutsatser
Från denna studie kan ett antal slutsatser dras gällande prototyputveckling inom projektgrupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Detta avsnitt har för
avsikt att i korthet besvara den frågeställning som presenterades i rapportens inledning.
Fördelarna med att ta fram en prototyp kan tänkas vara många. Från undersökningen syns
tydligt att prototyper har använts för att undersöka olika alternativ och ge projektgruppen ett
gemensamt mål att arbeta mot. De har dessutom varit till hjälp med att konkretisera kundens
önskemål och tidigt kunna få återkoppling på de förslag som tagits fram. En överväldigande
majoritet av deltagarna ansåg att den tid som investerades i prototyputvecklingen var givande för utvecklingen av projektet.
De nackdelar som kommit fram i och med undersökningen har främst varit relaterade till
den tidsinvestering som en bra prototyp ofta kräver. Deltagarna nämnde bristande funktionalitet, dåligt skriven kod och att det tar mycket tid att göra en separat prototyp. Utöver detta
påpekade en grupp att de alternativ som utforskades var ganska snarlika och att nya idéer
43
B.7. Slutsatser
kan ha gått förlorade eftersom alla inte var inblandade i prototyputvecklingen. Ytterligare
upplevde man att gränssnittsdesignen begränsades utifrån det som ansågs vara möjligt att
implementera.
Utifrån enkätsvaren framgår att samtliga projektgrupper tillsatte en mindre grupp som
ansvariga för prototyputvecklingen. I två av tre fall har en prototyp av evolutionär typ
använts, där alltså produkten har utformats i flera steg och “prototypen” som utvärderats
avser en tidig version av slutprodukten. Vidare var avsikten att utforska flera alternativ och
förtyliga kundens önskemål vilket pekar på utforskande prototypning. Den process som kan
användas i utformningen av ett användargränssnitt tas upp i avsnitt B.3.2. Av de tre faser
som där nämns – konceptfas, bearbetningsfas och detaljeringsfas – är det de två första som
innefattar prototyputveckling. Det är värt att nämna att det inte framgår från undersökningen vilka steg i processen som faktiskt har genomförts hos de projektgrupper som deltog. De
olika stegen och faserna kan således anpassas efter gruppens behov.
44
C Rebecka Geijer Michaeli: Daily
Scrum virtuellt via textbaserat
verktyg
C.1
Inledning
Under projektet har gruppen tillämpat en modifierad variant av arbetsmetoden Scrum [1]. En
modifikation som gjorts är sättet på vilket daily Scrum-mötena har gått till, se 4.3.1. Denna
undersökning handlar om dessa daily Scrum-möten, hur de har gått till och vilka erfarenheter
som kan tas med till framtida projekt. Undersökningen behandlar även vad det finns för
litteratur att ta del av om virtuella, textbaserade daily Scrum-möten.
C.1.1
Syfte
Syftet med den här undersökningen är att sammanställa teori som finns att hitta om virtuella,
textbaserade daily Scrum-möten, samt sammanställa erfarenheter från en projektgrupp som
tillämpat Scrum med virtuella, textbaserade daily Scrum-möten.
C.1.2
Frågeställning
Följande frågeställningar har legat till grund för denna undersökning:
1. Vad finns det för teori att inhämta som kan vara till hjälp vid utvärderandet av daily
Scrum-möten genomförda virtuellt via ett textbaserat verktyg?
2. Vilka erfarenheter kan inhämtas från ett projekt om nio personer som tillämpat Scrum
där daily Scrum-möten hållits virtuellt tre gånger i veckan via ett textbaserat verktyg?
C.2
Bakgrund
Som det beskrivs i 4.3.1 har gruppen haft daily Scrum-möten tre gånger i veckan istället för
varje dag. Trots det kommer mötena refereras till som daily Scrum-möten genomgående i
undersökningen. Dessa möten har hållits via kommunikationsverktyget Slack [18], de var
alltså virtuella. Slack ger ingen möjlighet till video- eller telefonkonferenser, utan är helt
textbaserat. Detta har lett till att gruppens daily Scrum-möten skett helt textbaserat.
För att få en enhetlig form på gruppmedlemmarnas daily Scrum-svar har Slack-tillägget geekbot [39] använts. Varje mötesdag skickade geekbot de olika daily Scrum-frågorna till var och
en av gruppmedlemmarna via privatchatt. Gruppmedlemmarna fick sedan svara till geekbot, och avslutningsvis postade geekbot en sammanställning per gruppmedlem i en specifik
Slack-kanal som var dedikerad för ändamålet.
45
C.3. Teori
C.3
Teori
I det här stycket presenteras först teori om daily Scrum-möten i två stycken, följt av ett stycke
om möten som hålls vitruellt, och till sist ett stycke om Media Richness Theory.
C.3.1
Daily Scrum
I 3.5.1 beskrivs hur daily Scrum-möten går till. Tanken med att teammedlemmarna står upp
under mötet är att förhindra att de drar ut på tiden, då det för de flesta är obekvämt att stå upp
längre stunder. En effekt av utformningen av daily Scrum-frågorna, där teammedlemmarna
i början av varje dag får berätta för sina kollegor vad de kommer jobba med under dagen, är
att det ger en ansvarskänsla inför resten av teamet att göra framsteg på det man sagt att man
ska jobba med [40].
C.3.2
Direktkontakt från daily Scrum
En stor del i Scrum är den direkta kontakten mellan teammedlemmar. Direkt kommunikation
tros bidra till effektivitet och samarbete i team [41]. Ett forum för sådan direkt kommunikation är daily Scrum-möten, där gruppmedlemmar får en uppfattning om varandras problem
och direkt kan diskutera lösningar och liknande problem som uppstått.
C.3.3
Virtuella möten
Att delta virtuellt i ett möte ger inte samma känsla av deltagande som att närvara fysiskt. Mer
direktkontakt ger mer direktkommunikation mellan teammedlemmar [42], [43]. Virtuella
möten är praktiskt för de som av olika anledningar inte kan närvara fysiskt.
C.3.4
Media Richness Theory
Media Richness Theory lades fram 1986 av Richard L. Daft och Robert H. Lengel. Den
beskriver hur rikhet kan användas för att jämföra olika kommunikationsmedier. Rikhet
avser här ett värde på ett kommunikationsmedies förmåga att förmedla information. I
information som skickas över ett medie innefattas även implicit kommunikation såsom
kroppsspråk och tonfall. Till exempel videochatt har högre rikhet än e-mail. [44]
Till ärenden som kräver hög social närvaro, till exempel känsliga ämnen såsom avskedanden
och konfliktmedling, behövs ett rikt medie.
För ärenden som inte kräver någon social närvaro, till exempel att bekräfta en bokning, behövs inte ett rikt medie utan e-mail räcker gott.
C.4
Metod
Teori har insamlats genom att läsa artiklar och annan litteratur. För att hitta sagda artiklar
har sökningar gjorts på orden “daily scrum”, “distributed”, “virtual” och “meeting” i olika
konstellationer.
För att samla ihop erfarenheter har en enkät skickats ut till samtliga gruppmedlemmar.
Enkäten innehöll följande fritextfrågor:
• Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?
• Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?
• Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?
46
C.5. Resultat
• Finns det något i vår variant av daily Scrum som du tror hade fungerat bättre på något
annat sätt? Om ja, hur då?
Ingen av frågorna var obligatorisk att svara på.
C.5
Resultat
Enkäten besvarades av sex gruppmedlemmar. En fullständig sammanställning av svaren
finns i bilaga 7. Här följer kortare sammanfattningar av de svar som kom in, indelat efter
enkätens fyra frågor.
Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?
Alla de som svarade är överens om att daily Scrum-möten varannan dag har varit lagom,
med flera kommentarer om att möten varje dag hade varit för ofta.
Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?
Av de som svarat anser alla att det varit praktiskt att daily Scrum-mötena hållits virtuellt,
istället för att behöva få ihop ett kort möte med hela gruppen tre gånger i veckan. Hälften
av de svarande tar upp det negativa i att inte träffa övriga gruppmedlemmar ansikte mot
ansikte, och att de saknat de diskussioner som ofta uppstår i samband med möten.
Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?
Alla som svarat anser att Slack och geekbot har fungerat bra för att hantera daily Scrummötena.
Finns det något i vår variant av daily Scrum som du tror hade fungerat bättre på något
annat sätt? Om ja, hur då?
Tre förslag på möjliga förbättringar kom in från de som svarade på rapporten. Ett var att det
borde gå att se vilka som ännu inte besvarat sin daily Scrum, ett annat att det vore praktiskt
att kunna se en sammanställning av alla sina svar, och det tredje en önskan om att alla till
varje daily Scrum skickat en selfie ihop med sina svar.
C.6
Diskussion
Här diskuteras de virtuella, textbaserade daily Scrum-möten som tillämpats utifrån teorin
som inhämtats. Efter det följer diskussion kring resultaten som kommit från enkäten, och
slutligen ett kort stycke diskussion kring metoden som tillämpats i undersökningen.
C.6.1
Teori
I teorin framgår att flera av fördelarna med daily Scrum-möten går förlorade om inte
teammedlemmarna träffas fysiskt för sina möten. De spontana diskussionerna uteblir, likaså
möjligheten att snabbt ta upp mindre frågor. Att ersätta daily Scrum-möten med videokonferenser ger inte samma effekt, då det är just närheten och möjligheten till oplanerade samtal
som är nyckeln.
Det medie som använts för daily Scrum är lågt i rikhet, vilket har lett till att en del former av
kommunikation inte har gått att förmedla. En annan fördel med face-to-face-möten som går
förlorad är relationsbyggande mellan gruppmedlemmarna.
47
C.7. Slutsatser
C.6.2
Resultat
Här diskuteras de svar som kommit in, indelade efter de fyra frågor som ställdes i enkäten.
Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?
Det är väldigt tydligt att alla som besvarade enkäten är eniga om att daily Scrum varannan
dag istället för varje dag har varit alldeles lagom. Varje dag hade varit för ofta då ingen
jobbade heltid med projektet, och därmed inte säkert jobbat med det varje dag. Det stämmer
bra överens med motiveringen bakom att bara ha daily Scrum varannan dag, vilken var att
projektet gick på halvtid.
Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?
Både nackdelar och fördelar träder fram. Flera svaranden nämner det smidiga i att inte behöva tid och plats för alla att samlas. Det är också flera som pekar på det tråkiga i att inte ses,
och att de har saknat de fria diskussioner som ofta uppstår i samband med möten.
Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?
Här är de svarande enkom positiva. Slack ihop med geekbot har fungerat utmärkt för att
organisera virtuella textbaserade daily Scrum-möten.
Finns det något i vår variant av daily Scrum som du tror hade fungerat bättre på något
annat sätt? Om ja, hur då?
En svarande påpekar att det inte tydligt framgår vilka som inte svarat. Där har virtuella
textbaserade daily Scrum-möten en klar nackdel gentemot den klassiska varianten. En annan
svarande saknar selfies, vilket kan tolkas som en önskan att få träffa de andra i gruppen. Det
framgår även att ett par av de svarande nog föredrar den klassika formen av daily Scrum.
C.6.3
Metod
Alla i gruppen hade inte svarat vid sammanställningen, vilket sannolikt beror på att enkäten
skickades ut för sent.
C.7
Slutsatser
Utifrån resultatet och teorin kan vissa slutsatser dras.
Utifrån den teori som sammanställts kan slutsatsen dras att virtuella, textbaserade daily
Scrum-möten saknar vissa av de positiva effekter som kommer av den klassiska formen
på daily Scrum-möten, framförallt direktkontakten mellan teammedlemmar. Vidare kan
sägas att daily Scrum-möten gör sig bäst i sin ursprungliga form, och att det ska till starka
incitament för att övergå till en virtuell variant.
Följande erfarenheter kan vara av intresse för framtida projekt:
• Även då strukturen kring virtuella textbaserade daily Scrum-möten är felfri, föredrar
flera att ha dem på klassiska viset ändå.
• Anpassa frekvensen på daily Scrum-möten efter hur mycket tid de inblandade lägger
på projektet.
48
D Eric Henziger: En utvärdering av
parprogrammering och
kodgranskning
D.1
Inledning
Under utvecklingen av systemet användes både parprogrammering och kodgranskning.
Metoderna hade för syfte att höja kvaliteten på produkten genom att upptäcka och åtgärda
buggar och andra felaktigheter i koden tidigt från det att koden skrivits. En ytterligare konsekvens är att metoderna kräver interaktion mellan utvecklarna vilket påverkar samarbetet i
gruppen.
D.1.1
Syfte
Syftet med den här rapporten är att lyfta fram för- och nackdelar med parprogrammering och
kodgranskning. Tidigare jämförelsestudier mellan parprogrammering och kodgranskning
har gjorts av Müller [45] där två grupper fick utföra samma uppgift och där den ena gruppen
bestod av programmerande par och den andra gruppen bestod av en självständig programmerare vars kod granskades för att sedan korrigeras. Min rapport undersöker effekterna
av att använda parprogrammering under utvecklingen av ett mjukvaruprojekt för att sedan
även låta koden genomgå en granskningsprocess. Dessutom läggs fokus på hur metoderna
påverkar samarbetet i en nyskapad projektgrupp utan tidigare erfarenhet av webbutveckling.
D.1.2
Frågeställning
Jag ämnar besvara följande frågeställningar:
1. Finns det ett värde i att granska parprogrammerad kod?
2. Vilka styrkor och svagheter finns med respektive metod?
3. Vilken påverkan har metoderna för samarbetet inom projektgruppen?
D.2
Bakgrund
Vår projektgrupp bestod av nio civilingenjörsstudenter inom antingen datateknik eller
mjukvaruteknik. Samtliga hade god allmän programmeringsvana men ingen hade någon
tidigare nämnvärd erfarenhet av webbutveckling. Under projektets förstudie beslutades att
utvecklingen skulle om möjligt ske genom parprogrammering. Gruppmedlemmarna hade
erfarenhet av parprogrammering från tidigare kurser på universitetet och någon formell
49
D.3. Teori
introduktion till hur metoden skulle appliceras krävdes inte.
Vidare beslutades att all skriven kod skulle genomgå granskning och godkännas innan den
kunde integreras med slutprodukten. De flesta i gruppen saknade tidigare erfarenhet av kodgranskning och ett flertal diskussioner krävdes för att nå konsensus i hur granskningsprocessen skulle se ut.
D.3
Teori
I en studie av Cockburn och Williams [46] diskuteras kostnaden av parprogrammering,
vilken enligt kritikerna fördubblas då den kräver två programmerare för att utföra en
ensam programmerares arbete. Studien visade dock att parprogrammering har många positiva effekter på utvecklingsprocessen samtidigt som kostnaden är förhållandevis låg. Den
marginella ökningen av utvecklingskostnaden på 15 % vid parprogrammering kompenserades av att buggar upptäcktes tidigt i utvecklingsfasen, att färre rader kod skrevs för att
utföra samma uppgift och att majoriteten av utvecklarna kände större uppskattning för sitt
arbete vid parprogrammering jämfört med soloprogrammering.
I Müllers [45] jämförelsestudie framgick att parprogrammering inte gav kod av högre kvalitet
jämfört med soloprogrammerad kod som genomgått granskning. Samtidigt var den ökade
kostnaden hos parprogrammering inte av signifikant storlek.
D.4
Metod
Hur gruppen tillämpat parprogrammering och kodgranskning beskrivs i avsnitt 4.5.1 respektive 4.5.2. Undersökningen bestod av två delar, en analys av projektets gransknings-commits
och en enkät om parprogrammering och kodgranskning.
D.4.1
Analys av gransknings-commits
För utvärderingen av kodgranskningen har en undersökning av projektets granskningscommits gjorts. Antalet “FIXME”-kommentarer har beräknats per feature och kategoriserats
för att belysa vilken typ av fel som fångats med kodgranskning. De sju kategorierna som
användes exemplifieras i kodexempel D.1 till D.7.
Kodexempel D.1: Exempel på feedback gällande kommentering.
* An object where the keys are the letters that we wish to count.
* The value will be set to the frequency of the letter.
* FIXME: Rephrase to ’The value _of the key_ will be set to the _count_ of
* the letter.’
*/
Feedback gällande kommentarer gavs då kommenteringen var otydlig eller otillräcklig.
Granskaren verifierade att kommentarerna överensstämde med koden, att kodens syfte gick
att förstå utifrån kommentering och att den följde formatet för JSDoc.
Kodexempel D.2: Exempel på ett refaktoreringsförslag.
document.body.addEventListener(’fileChange’, function(e) {
/* FIXME: This function is similar to plotGraphs()
* perhaps functionality can be extracted into a common function?
*/
50
D.5. Resultat
Feedback om refaktorering var ofta just förslag som gavs för att sprida och väcka tankar om
hur koden kunde förbättras.
Kodexempel D.3: Exempel på ett JavaScript-relaterat fel.
// FIXME: Don’t use ’’ around object keys.
var fileChangeEvent = new CustomEvent(’fileChange’, {’detail’: data});
Kategorin JavaScript fångade upp fel relaterade till stil och syntax för JavaScript men som
var så pass generella att de inte föll inom kategorierna kodstandard eller arkitektur.
Kodexempel D.4: Exempel på feedback gällande kodstandard.
//FIXME: Use camelCase for function names.
function expand_collapse_graph(graph)
Feedback inom kategoring kodstandard gavs vid brott mot de kodstandarder som användes
i projektet. Vilka dessa var redovisas i 5.3.
Kodexempel D.5: Exempel på ett arkitekturellt fel.
<body>
<!--FIXME: Put all style settings in CSS files. -->
<div id="crypto-graph-container" style="width:800px; height:400px;"></div>
Feedback om arkitekturella fel påvisades då koden stred mot den arkitekturplan som framtagits för projektet.
Kodexempel D.6: Exempel på ett presentationsfel.
{
trigramText: "TER", frequency: 0.70 //FIXME: displays as "0.7" in the table
}
Till kategorin presentationsfel hörde kod som inte hade något fel i sig självt, men som ledde
till fel i presentationen av slutprodukten under användning.
Kodexempel D.7: Exempel på ett semantiskt fel.
else if (language === "en") {
plotLanguageGraph(english_stats, english_graph_data);
if (typeof crypto_text != "undefined") {
/* FIXME: Wrong language, use getText[...]Eng() */
crypto_stats = getTextLetterFrequencySwe(crypto_text);
Kategorin semantiska fel rörde kod som var syntaktiskt korrekt enligt alla regler men som
gav fel beteende i produkten.
D.4.2
Enkätundersökning
För att samla in gruppmedlemmarnas åsikter och tankar om parprogrammering och kodgranskning utfördes en anonym enkätundersökning där varje gruppmedlem, mig exkluderad, fick besvara ett antal frågor. Enkäten redovisas i bilagedel 5.1.
D.5
Resultat
Detta avsnitt redovisar resultatet av de undersökningar som presenterades i metoddelen.
51
D.5. Resultat
Semantiska fel
5
Presentationsfel
5
Arkitekturella fel
6
JavaScript
9
Kommentering
19
Kodstandard
20
Refaktoreringsförslag
42
0
10
20
30
40
Antal förekomster
Figur D.1: Sammanställning av feedback från projektets samtliga granskningar.
D.5.1
Analys av gransknings-commits
I figur D.1 visas en sammanställning över antalet förekomster av de olika kategorierna på
feedback som gavs under projektet.
I figur D.2 visas antalet kommentarer per review. En trendlinje är dragen för att ge en
uppfattning av hur utvecklingen har skett över tiden.
I figur D.3 visas hur feedback givits per commit under projektet. Varje commit är presenterad
med git commit id och datum. Medianvärdet för antalet “FIXME”-kommentarer per granskning var 5 med ett genomsnittsvärde på 4,6. Kategorierna Presentationsfel, Arkitekturella fel och
Semantiska fel har slagits samman till kategorin Övrigt.
D.5.2
Enkätundersökning
Åtta personer deltog i undersökningen. I bilagedel 5.2 redovisas svaren från enkätens
fritextfrågor. Parprogrammering hade enligt enkätresultatet många positiva effekter på
samarbetet, bland annat bidrog det till öppenhet i gruppen och att gruppmedlemmarna
lärde känna varandra bättre. De negativa effekterna var färre, men den vanligaste åsikten
var att det var problematiskt att hitta gemensamma tider då båda parter kunde arbeta. De
positiva effekterna av samarbetet från kodgranskningen var spridda men fyra svar angränsar
till ökad interaktion mellan berörda parter, bland annat att kodgranskning har lett till fler
diskussioner och bättre kommunikation.
Parprogrammering och kodgranskning anses av fyra respektive sex av de svarande ge bättre
kod. Den vanligaste nackdelen för båda metoderna var att de var tidskrävande.
52
D.5. Resultat
Antal kommentarer
●
10
●
●
●
●
●
●
5
●
●
●
●
●
●
●
●
●
●
●
●
mar 01
mar 15
●
●
apr 01
Datum
apr 15
●
maj 01
Figur D.2: Antal granskningskommentarer över tiden.
Typer av feedback
Kodstandard
Kommentering
Refaktorering
JavaScript
Övrigt
8
6
4
2
0
c9c04be
2016−02−24
879a8bc
2016−02−26
205dc6f
2016−03−03
b536a4a
2016−03−08
99bb620
2016−03−10
098e15a
2016−03−10
fa3ccee
2016−03−19
9723627
2016−03−28
67b7686
2016−04−04
e0ef284
2016−04−13
5a98aef
2016−04−13
92cbfac
2016−04−13
65f98c3
2016−04−14
37ba671
2016−04−14
8309869
2016−04−14
26a5d2b
2016−04−15
a53a437
2016−04−18
5c794a7
2016−04−22
60fd341
2016−04−22
403ddf1
2016−04−28
0ee2943
2016−05−01
df9be39
2016−05−02
7421356
2016−05−02
8
6
Antal förekomster
4
2
0
8
6
4
2
0
8
6
4
2
0
Git commit
Figur D.3: Detaljbeskrivning av feedback per commit från projektets granskningar.
53
D.5. Resultat
Metod
Parprogrammering
Kodgranskning
Antal
6
4
2
0
Mycket
negativ
Negativ
Neutral
Positiv
Mycket
positiv
Figur D.4: Gruppmedlemmarnas inställning till parprogrammering och kodgranskning.
I figur D.4 visas en fördelning över gruppmedlemmarnas inställning till parprogrammering
och kodgranskning.
I tabell D.1 visas hur stor del av gruppmedlemmarnas utvecklingstid som har ägnats åt
parprogrammering. Tabell D.2 visar hur många kodgranskningar varje gruppmedlem utfört
under projektet.
Tabell D.1: Andel utvecklingstid ägnad åt parprogrammering.
Parprogrammerad utvecklingstid (%)
0-20 %
21-40 %
41-60 %
61-80 %
81-100 %
Antal
2
2
2
1
1
Tabell D.2: Antal kodgranskningar utförda.
Antal kodgranskningar
0
1
2
3
4
5
10+
Antal
1
0
2
1
2
1
1
Figur D.5 visar vilken av metoderna parprogrammering och kodgranskning som
gruppmedlemmarna skulle välja till ett kommande projekt.
54
D.6. Diskussion
25.0%
37.5%
Metod
Parprogrammering
Kodgranskning
Vet ej/Kan inte välja
37.5%
Figur D.5: Gruppmedlemmarnas föredragna metod till ett framtida projekt.
D.6
Diskussion
Detta avsnitt diskuterar särskilt intressanta iakttagelser från resultatet och lyfter fram nackdelar med den valda metoden. Slutligen förs ett resonemang kring det här projektets metoder
för parprogrammering och kodgranskning och hur dessa skiljer sig från mer väletablerade
metoder inom mjukvaruindustrin.
D.6.1
Resultat
Analys av gransknings-commits
I sammanställningen i figur D.1 kan man se att refaktoreringsförslag är den överlägset
mest populära kategorin av feedback, mer än dubbelt så vanligt som de näst mest populära kategorierna kodstandard och kommentering. Arkitekturella fel har varit sällsynta
och gruppmedlemmarna verkar ha haft bättre koll på arkitekturen än kodstandarden. Få
semantiska fel och presentationsfel har uppmärksammats i granskningsstadiet. Detta kan
bero på att utvecklaren själv har testat koden och beteendet av produkten innan granskning
eller att granskaren haft mest fokus på själva koden och inte produkten.
I figur D.2 kan man se en antydan till en nedåtgående trend. Efter att en utvecklare har
arbetat med ett och samma projekt under en längre tid borde rutiner för kodstandard och
kommentering bli en naturlig del i arbetet. Det är dock oklart om någon sådan trend kan
ses i figur D.3. En annan förklaring till en minskning i antalet granskningskommentarer över
tiden är att de features som utvecklades blev mindre omfattande under projektets gång.
Enkätundersökning
Figur D.4 visar att majoriteten av gruppmedlemmarna är positiva till både parprogrammering och kodgranskning. Kodgranskning är marginellt mer polariserande. I resultatet
över vilken metod som är föredragen, figur D.5, är det så gott som jämnt fördelat mellan
svarsalternativen.
I bilagedel 5.2 kan flera trender ses. Generellt kan sägas att för parprogrammering fanns fler
positiva effekter och fördelar listade jämfört med negativa effekter och nackdelar. För kodgranskning var det en jämnare fördelningen mellan positiva effekter/fördelar och negativa
55
D.6. Diskussion
effekter/nackdelar.
En fördel med parprogrammering som endast nämnts av en svarande är “Bättre liv”. Även
om det är sällsynt får parprogrammering ändå ses som en metod som kan ge positiva effekter
av hög magnitud.
D.6.2
Metod
Analysen av granskningskommentarer har varit fullständigt beroende av att dessa har
dokumenterats som “FIXME”-kommentarer via Git. Denna metod fångar inte upp de fall
där feedback har skett via andra kommunikationskanaler (Slack, muntligt etc.) eller där
granskaren inte lyckats hitta några felaktigheter i koden. Den tar heller inte hänsyn till olika
granskares egenskaper, till exempel att vissa granskare tenderar att ge fler refaktoreringsförslag medan andra är mer engagerade i kommentering.
Metoden särskiljer inte granskningar som gjorts på parprogrammerad kod från granskningar
som gjorts på kod utvecklad av en ensam utvecklare.
Trots att utvecklingen i projektet skulle om möjligt ske genom parprogrammering har en stor
del av utvecklingen skett genom soloprogrammering. Om parprogrammering hade varit
ett hårt krav hade förmodligen också resultaten från enkäten förändrats. Valfriheten kan ha
gjort att gruppmedlemmarna har valt att använda parprogrammering när det passat dem
och därmed fått en mer positiv upplevelse utifrån det. Kodgranskning å andra sidan var i
princip ett krav för att en utvecklare skulle få integrera sin kod till projektets kodbas. Om
båda metoderna hade varit påtvingade hade en mer rättvis jämförelse kunnat göras.
Storleken på projektet och antalet deltagare i undersökningen hade med fördel kunnat vara
större. Med en grupp på åtta personer har enskilda individer fått en stor inverkan på upplevelsen av de två metoderna. Hade projektet pågått under en längre tid hade förmodligen
processerna förfinats och förbättrats för en mer positiv upplevlse.
D.6.3
Arbetet i ett vidare sammanhang
Parprogrammering är en metod som etablerades under början av 2000-talet och som har
dokumenterats flitigt. I McConnell [47] listas olika faktorer för att lyckas med parprogrammering. Bland annat nämns “Make sure both partners can see the monitor” vilket kan
ses som en trivial självklarhet. Denna punkt har dock relevans då parprogrammeringen
under projektet i huvudsak skedde på bärbara datorer. Dessa har generella egenskaper
som liten skärmstorlek, låg skärmupplösning och låg ljusstyrka jämfört med en separat bildskärm. Detta kan ha lett till ett mindre aktivt deltagande hos den observerande parten i paret.
Hade parprogrammeringen skett under bättre ergonomiska förhållanden hade förmodligen
också upplevelsen blivit mer behaglig.
Kodgranskning är ett utbrett koncept inom mjukvaruindustrin och används i flera större
projekt och företag. För att göra granskningsprocessen praktiskt genomförbar i stor skala har
specifika granskningsverktyg utvecklats, till exempel använder Android-projektet verktyget
Gerrit [48] och Opera Software använder verktyget Critic [49].
I det här projektet har en enkel granskningsprocess med hjälp av tillgänglig funktionalitet
i Slack, Git och WebStorm använts vilket haft fördelen av att ha en låg inlärningströskel
men där nackdelen varit brist på skalbarhet som lett till strul under granskningsprocessen. I
56
D.7. Slutsatser
enkätresultaten i bilagedel 5.2 och även i bilaga 2 kan man läsa om problem med svårigheter
att få någon att granska ens kod och om oordning i kommunikationskanalen #reviewrequest.
Att använda ett dedikerat verktyg för kodgranskning hade eventuellt gett en mer strukturerad och välorganiserad granskningsprocess och dessutom gett bättre förberedelse för hur
kodgranskning utförs i industrin.
D.7
Slutsatser
Under projektets livslängd har kodgranskning fångat upp misstag i koden och lyft fram
refaktoreringsförslag. Enkätundersökningen har inte visat att kodgranskningen setts som
ett onödigt moment efter att kod har parprogrammerats. De positiva effekterna har dels
berört kodkvalitet men också kommunikation och stämning inom gruppen. Därmed kan
man dra slutsatsen att det finns ett värde i att granska parprogrammerad kod inte enbart ur
ett kodkvalitativt perspektiv utan även för förbättringar av psykosociala förhållanden.
För en nystartad projektgrupp har parprogrammering hjälpt gruppmedlemmarna att lära
känna varandra och skapat ett öppnare och bekvämare klimat i gruppen.
Kodgranskning har triggat diskussioner och samtal vilket förbättrat kommunikationen inom
gruppen. Samtidigt upplever flera det som negativt att behöva lyfta fram kritik.
Kunskapsspridningen har underlättats av både parprogrammering och kodgranskning.
Båda metoderna har bidragit till bättre inlärning och kompetensutveckling vilket får ses som
extra positivt i ett projekt där gruppmedlemmarna saknade erfarenhet inom webbutveckling.
Den största nackdelen med parprogrammering i det här projektet har varit svårigheten i att
hitta gemensamma tider för arbetet. Kodgranskning har uppfattats som en tidskrävande
process och besvärlig då kritik kan ge obehagskänslor.
Båda metoderna har haft en positiv effekt på kodkvaliteten och har lett till högre kompetens
inom gruppen. Särskilt parprogrammering har förbättrat samarbetet och sammanhållningen
bland gruppmedlemmarna.
57
E Oscar Johansson:
Enhetstestningens påverkan på
programmeringsprocessen
E.1
Inledning
Enhetstestning används utbrett i de flesta typer av mjukvaruprojekt. I dessa projekt är det
vanligt att olika typer av testmetoder diskuteras och används. En av dessa metoder är testdriven utveckling, vilken har fått starkt fäste bland de agila utvecklingsmetoderna. Den testdrivna utvecklingens grundpelare är att testfallen för funktionalitet ska skrivas innan funktionaliteten implementeras. Denna rapport behandlar enhetstestning i ett agilt, småskaligt
projekt, och undersöker hur det påverkar beroende på när i programmeringsprocessen som
testfall skrivs.
E.1.1
Syfte
Syftet med rapporten är att undersöka hur tidpunkt för skrivande av enhetstester påverkar
programmeringsprocessen, med avseende på tidsåtgång, resultat och underlättande av lösning.
E.1.2
Frågeställning
Följande frågeställningar ska utredas i denna rapport.
1. Hur påverkas tidsåtgången för programmeringsprocessen beroende på när i processen
enhetstesterna skrivs?
2. Hur påverkas kodstrukturen beroende på när i programmeringsprocessen enhetstesterna skrivs?
3. På vilket sätt bidrar enhetstestningen till att underlätta vid problemlösning? Bidrar
olika förhållningssätt olika mycket?
E.2
Bakgrund
I kursen TDDD96 Kandidatprojekt i programvaruutveckling, på Linköpings universitet, utfördes under vårterminen 2016 ett kandidatarbete i programvaruutveckling. Projektgruppen
valde att använda sig av enhetstestning, där utvecklaren bar ansvaret att utföra testerna på
sin egen kod. Standarden för enhetstestningen beskrevs i en testplan. En av de stora utmaningarna var att utforma denna standard så att testerna var
58
E.3. Teori
• snabba på att ge feedback
• lätta att utföra samt dokumentera
• ett hjälpmedel snarare än ett tidskrävande moment.
Trots att det diskuterades när i programmeringsprocessen enhetstesterna skulle skrivas fastställdes ingen standard för detta.
E.3
Teori
Här presenteras den teoretiska bakgrund som behövs för att förstå innehållet i rapporten.
E.3.1
Enhetstestning
Enhetstestning syftar till att testa den lägsta nivån av funktionalitet. Den används som ett
verktyg i de flesta programvaruutvecklingsprojekt. Enhetstestning definieras som ett kodstycke, ofta en funktion, vilken anropar den funktion som ska testas och sedan kontrollerar
om den fungerar som den ska utifrån uppställda kriterier [50].
I kodexempel E.1 visas ett exempel på en funktion, skriven i JavaScript, som tar in två tal och
returnerar det största.
Kodexempel E.1: Exempel på en funktion som tar in två tal som parametrar och returnerar det största.
function max(x,y){
if (x > y){
return x;
} else {
return y;
}
}
I kodexempel E.2 visas ett enhetstest, skrivet med ramverket QUnit 3.3, som testar två olika
anrop till funktionen max i kodexempel E.1. Det första anropet kontrollerar om 3 returneras när parametrarna 3 och 2 används. Det andra anropet kontrollerar om 5 returneras när
parametrarna 5 och -3 används.
Kodexempel E.2: Exempel på enhetstester i testramverket QUnit som testar funktionen max.
QUnit.test("Test Cases for max()", function(){
equal(max(3,2), 3, "3 should be larger than 2");
equal(max(5,-3), 5, "5 should be larger than -3");
});
E.3.2
Testdriven utveckling
Testdriven utveckling kan definieras som en metod eller ett förhållningssätt som framför allt
förknippas med agila utvecklingsmetoder [51]. Använder man sig av testdriven utveckling
ska man endast skriva kod i syfte att få testfall godkända. Detta innebär att testfallen för
en funktionalitet måste skrivas innan en utvecklare får börja programmera [52]. Testfallen
hämtas oftast från kravspecifikationen och ska bidra till att rätt funktionalitet implementeras,
utifrån intressenternas värderingar.
Testdriven utveckling tvingar utvecklaren att förstå och konkretisera uppgifter innan denne
börjar implementera. En viktig regel är: om man inte vet hur man ska skriva tester för sin
kod, bör man inte ens fundera på att börja skriva kod [53]. Detta ska underlätta när en
utvecklare tar sig an större problem eller uppgifter.
59
E.4. Metod
Om det finns testfall för funktionalitet i en mjukvara kan detta skapa en säkerhet för en
utvecklare som ska modifiera befintlig, eller implementera ny, funktionalitet. Genom att
ständigt kontrollera att testfallen godkänns är utvecklaren säker på att dennes ändringar
eller tillägg inte förstört någon annan funktionalitet. Testfallen agerar då som ett skydd eller
en säkerhet för utvecklaren. [54]
Att skriva tester före funktionalitet har visat sig kunna minska produktiviteten hos utvecklare
som inte är vana att arbeta efter den metoden [53]. Att arbeta effektivt med metoden tar tid,
och det kan vara svårt att lära sig [54].
E.4
Metod
För att undersöka hur enhetstestning påverkar tidsåtgång, kodutformande och hjälp vid
problemlösning, beroende på vilken tidpunkt i programmeringsprocessen de skrivs, anornades en datainsamling. I datainsamlingen fick deltagarna lösa uppgifter utifrån tre olika
förhållningssätt till enhetstestning. Varje förhållningssätt motsvarar en tidpunkt i programmeringsprocessen (före, under och efter kodandet). I datainsamlingen ingick tre uppgifter,
tre förhållningssätt till enhetstestning samt en enkät med frågor gällande enhetstestning.
Datainsamlingen började med att alla deltagare tilldelades ett häfte innehållande information, uppgifter och enkät. Häftet i sin helhet redovisas i bilaga 6.
Datainsamlingen strävade efter att i största möjliga mån efterlikna problemen, utvecklingsmiljön och testramverken som användes i projektet.
E.4.1
Upplägg av datainsamling
Varje deltagare fick ett häfte innehållande information, uppgifter samt enkät. Insamlingen
började med att deltagarna fick läsa första sidan av häftet, vilken bestod av en introduktion
som gav en överblick över hur datainsamlingen skulle gå till. Sedan fick deltagarna utföra
varsin uppvärmningsuppgift. Syftet med denna uppgift var att kontrollera att testramverk
samt utvecklingsmiljö var korrekt konfigurerade.
Sedan påbörjades lösandet av uppgifterna. Till varje uppgift fanns ett förhållningssätt till
testning som deltagaren behövde använda sig av. Vilket förhållningssätt som hörde till vilken
uppgift blandades så att alla uppgifter löstes med alla olika. Det innebär att alla deltagare
löste samma tre uppgifter men med olika förhållningssätt. Efter att deltagaren var klar med
uppgifterna avslutades insamlingen med ifyllandet av en enkät.
Data som samlades in inkluderade:
• Tidsåtgång för lösandet av varje uppgift.
• Svar som deltagaren kom fram till för varje uppgift.
• Antal funktioner som deltagaren skrev till varje uppgift.
• Svaren deltagaren fyllde i enkäten.
E.4.2
Uppgifterna
Till datainsamlingen fanns tre olika uppgifter, inspirerade av olika programmeringstävlingsuppgifter. De översattes till svenska och modifierades sedan för att anpassas till storleken
och syftet med datainsamlingen.
60
E.5. Resultat
Uppgifterna som valdes krävde någon form av uträkning, där svaret var ett tal. Denna typ
av uppgift valdes eftersom de förenklar utförande av enhetstestning. Storleken på talen och
svaren valdes så att deltagaren inte behövde bekymra sig om prestanda, samtidigt som de var
tillräckligt stora för att man inte med enkelhet skulle kunna uppskatta rimligheten i svaret.
Detta valdes eftersom deltagaren då behövde använda sig av testfallen för att försäkra sig om
dennes program och svar var korrekt.
E.4.3
Enkät
Enkäten bestod av två delar, med sammanlagt åtta frågor. Den första delen behandlade enhetstestning under projektets gång och bestod av fyra frågor. Den andra delen behandlade
datainsamlingen och bestod av lika många frågor.
E.4.4
Förhållningssätt till enhetstestning
Under datainsamlingen fick deltagarna använda sig av tre olika förhållningssätt: testdriven
utveckling, testfall kontinuerligt under kodandet samt testfall efter kodandet. I praktiken
innebar detta att deltagaren skrev testfallen före, under och efter implementation. För en
djupare beskrivning av hur deltagarna skulle använda sig av förhållningssätten se bilaga 6.
E.5
Resultat
I det här kapitlet presenteras de resultat som samlades in under datainsamlingen. Datainsamlingen förklaras ingående under avsnitt E.4 och instruktionerna som deltagarna tillgodosågs
finns i sin helhet att läsa i bilaga 6.
Tabell E.1: Översikt över hur många procent av svaren som var korrekta respektive felaktiga.
Svar
Korrekt
Felaktigt
Procent
96
4
Under datainsamlingen fick varje deltagare lösa 3 olika uppgifter. Datainsamlingen hade
totalt 8 deltagare. Således insamlades 24 olika svar på uppgifter. Av dessa 24 svar var 96 %
korrekta och 4 % felaktiga, vilket presenteras i tabell E.1. I antal innebar detta 23 korrekta
svar och 1 felaktigt.
Tabell E.2: Resultat avseende tidsåtgång och
antal funktioner för de olika uppgifterna.
Tabell E.3: Resultat avseende tidsåtgång och
antal funktioner för de olika förhållningssätten.
Uppgift
Uppgift 1
Uppgift 2
Uppgift 3
Förhållningssätt
Testfall före
Testfall under
Testfall efter
Tid [min]
17
9
23
Funktioner
3
2,4
2,1
Tid [min]
15
20
12
Funktioner
3,3
2,4
1,9
I tabell E.2 presenteras den genomsnittliga tiden samt det genomsnittliga antalet funktioner
för varje uppgift. I tabellen visas att den tredje uppgiften tog längst tid, medan den andra uppgiften tog kortast tid. Gällande funktioner skrevs flest funktioner till den första
uppgiften, och minst antal funktioner till den tredje uppgiften.
Den genomsnittliga tidsåtgången samt det genomsnittliga antalet funktioner för de olika
förhållningssätten kan ses i tabell E.3. I tabellen visas att skrivande av testfall kontinuerligt
61
E.5. Resultat
under programmeringsprocessen tar längre tid än de andra förhållningssätten. Dock svarar
majoriteten av deltagarna att just detta förhållningssätt är det som har hjälpt till mest under
lösandet av uppgifterna, se tabell E.8. Att skriva testfall först i programmeringsprocessen
resulterade i flest funktioner. Att skriva testfall efter kodandet resulterade i minst antal
funktioner.
Tabell E.4: Har du använt dig av enhetstestning
under projektet?
Svarsalternativ
Ja
Nej
Antal
6
2
Procent
75
25
Tabell E.6: Vilket av de tre förhållningssätt som
använts under denna datainsamling representerar
bäst hur du har använt dig av enhetstestning
under projektet?
Svarsalternativ
Testfall före
Testfall under
Testfall efter
Antal
0
1
5
Procent
0
17
83
Tabell E.8: Uppfattade du att något
förhållningssätt till enhetstestning underlättade
vid lösning av någon uppgift? (Du kan välja flera
alternativ)
Svarsalternativ
Nej
Ja, testfall före
Ja, testfall under
Ja, testfall efter
Ja, alla förhållningsätt
Antal
0
4
7
1
0
Procent
0
33
58
8
0
Tabell E.5: Tycker du att den här datainsamlingen
är representativ för att motsvara enhetstestandet
under projektet?
Svarsalternativ
Ja
Nej
Antal
4
2
Procent
67
33
Tabell E.7: Uppskatta svårighetsgraden av
uppgifterna på en skala 1-5, där 1 är väldigt enkel
och 5 är väldigt svår.
Uppgift
Uppvärmning
Uppgift 1
Uppgift 2
Uppgift 3
Uppskattad svårighetsgrad
1
1,17
1,4
2
Tabell E.9: Uppfattade du att något
förhållningssätt till enhetstestning försvårade vid
lösning av någon uppgift? (Du kan välja flera
alternativ)
Svarsalternativ
Nej
Ja, testfall före
Ja, testfall under
Ja, testfall efter
Ja, alla förhållningsätt
Antal
5
2
0
1
0
Procent
63
25
0
12
0
Under projektet har 75 % av gruppmedlemmarna använt sig av enhetstestning, se tabell E.4.
De två medlemmar som inte har använt sig av det uppger i enkäten att detta beror på att de
endast har arbetat med sådant som inte var lämpat för enhetstestning. Av de deltagare som
hade använt sig av enhetstestning under projektet tyckte 67 % att uppgifterna från datainsamlingen var representativa, se tabell E.5. De deltagare som inte ansåg att uppgifterna var
representativa tyckte att uppgifterna var för annorlunda eller för små jämfört med problemen
i projektet, vilket framkom i enkäten.
I tabell E.6 kan man se att majoriteten av deltagarna har skrivit testfallen sist i programmeringsprocessen, alltså efter kodandet.
I enkäten fick varje deltagare uppskatta svårighetsgraden på varje uppgift, inklusive uppvärmningsuppgiften. Svårighetsgraden uppskattades till ett tal på en skala 1-5, där 1 var
väldigt enkel och 5 var väldigt svår. Den genomsnittliga uppskattade svårighetsgraden presenteras i tabell E.7. Där framkommer att den genomsnittliga uppskattningen av svårighetsgrad låg mellan 1 och 2 för samtliga uppgifter.
62
E.6. Diskussion
I tabell E.9 presenteras vilka förhållningssätt, om något, som har försvårat vid lösandet av
uppgifterna under datainsamlingen. 63 % tycker inte att något förhållningssätt har varit
försvårande. 25 % tycker att skriva testfallen först varit försvårande, och 12 % menar att
skriva testfall efter kodandet var försvårande.
E.6
Diskussion
I det här kapitlet diskuteras metod, resultat och felkällor. Samtliga diskuteras med stöd från
teorin.
Testning, framförallt testdriven utveckling, används till stor del för att försäkra utvecklaren
om att allting fungerar som det ska. Detta innebär både att koden exekverar utan buggar
samt att rätt sak har implementerats. Testfallen blir då en försäkran för utvecklare. Andra
saker som en utvecklare kan förlita sig på är rimlighet i svaren och övertygelse från koden.
Med rimlighet i svaren menas att utvecklare kan kolla på resultatet av sin funktionalitet för
att uppskatta om det känns rimligt. Med övertygelse från koden menas att koden är så pass
överskådlig, kort och simpel att utvecklaren kan, genom att läsa sin egen kod, övertyga sig
om att allting känns rätt. Som nämnt tidigare framställdes uppgifterna till datainsamlingen
så att deltagarna inte skulle kunna uppskatta rimligheten i svaren, detta för att de skulle
behöva använda sig av testfallen som försäkran. Men som kan ses i tabell E.1 var nästan alla
svar korrekta. Med hänsyn till detta och deltagarnas uppskattning av svårighetsgrad, som
kan ses i tabell E.7, var uppgifterna enkla att utföra. Av de två deltagarna som inte tycke
att datainsamlingen var representativ för projektets enhetstestning uppgav en att det beror
på att datainsamlingens uppgifter var för små. Tittar man på det genomsnittliga antalet
funktioner låg det mellan 1,9 och 3,3, något som också pekar mot ett väldigt litet program.
Deltagarna kanske kunde genom den korta och simpla koden övertyga sig om att sitt program var korrekt, och därmed eliminera behovet av testfall.
Det är inte bara uppgifternas storlek som påverkar resultaten. Det beror även på vilka deltagare man utför insamlingen på. Den utfördes på endast åtta personer och med en sådan liten
testgrupp kan individens personliga erfarenheter och kunskaper ha för stor påverkan.
Det första förhållningssättet döptes till Testdriven utveckling i instruktionerna för datainsamlingen. Med det krävdes att alla enhetstester skulle skrivas innan någon kod kunde skrivas.
Alltså att man behövde planera hela sitt program och all dess funktionalitet innan man
fick börja koda. I testdriven utveckling faller även att skriva testfall kontinuerligt under
kodandet in, vilket var datainsamlingens andra förhållningssätt. Detta innebär att testdriven
utveckling egentligen är en kombination av de första två förhållningssätten beskrivna i
datainsamlingen. Att kalla det första förhållningssättet Testdriven Utveckling kan således ha
varit en felanvändning av begrepp som kan ha skapat förvirring.
Att skriva testfall kontinuerligt under kodandet tar längst tid. Då behöver deltagaren integrera testskrivande med programmeringen. Detta var något bara en person var van med
från projektet. Detta förhållningssätt liknar till stor del testdriven utveckling och det är, som
nämnt innan, något som tar lång tid att komma in i och har visat sig minska produktiviteten
för nya utvecklare.
Att skriva testfall före kodandet tar näst längst tid. Detta var ingen deltagare van med från
projektet. Det här är till väldigt stor del testdriven utveckling med det undantaget att i
datainsamlingen behövde deltagaren planera hela sitt program och all dess funktionalitet
innan denne fick börja implementera. Man kan tänka sig att detta förhållningssätt borde ha
tagit längre tid, men kanske berodde det på att uppgifterna var för lätta och för små för att
63
E.7. Slutsatser
det skulle vara svårt att planera allt innan.
Att skriva testfall efter kodandet tar kortast tid. Detta förhållningssätt var majoriteten av
deltagare vana med från projektet. Vanan i kombination med att uppgifterna var lätta och
behovet av testfall var tveksamt bidrog antagligen till att detta tog kortast tid.
I resultaten kunde man se att skriva testfall före kodandet och att skriva testfall under
kodandet resulterar i fler funktioner än om man skriver testfallen efter kodandet. Så om
man använder något av de två förhållningssätten som påminner om testdriven utveckling,
där testfall utformar koden, resulterar detta i fler funktioner. Kanske kan det bero på att
utvecklaren måste planera och tänka efter innan denne sätter igång med utvecklandet. Men
att skriva testfall först kanske leder till att onödiga eller överflödiga funktioner skrivs. Det
kan vara svårt att planera hela sin kod innan man börjat utveckla, och utvecklaren kommer
kanske efter hand på bättre lösningar som kräver mindre kod. Det kan vara så att det är
därför som deltagarna uppger att skriva testfall under kodandet hjälpte dem mest.
Enligt deltagarna själva har förhållningsättet där utvecklaren skriver testfall kontinuerligt
under kodandet hjälpt mest under lösningen till uppgifterna. Dock så finns det inget annat resultat som varken säger för eller emot det. Detta på grund av att nästan alla svar var
korrekta.
E.7
Slutsatser
Den här delen behandlar frågeställningarna som presenterades i kapitel E.1.2.
Hur påverkas tidsåtgången för programmeringsprocessen beroende på när i processen enhetstesterna skrivs?
Att skriva testfallen efter kodandet, sist i programmeringsprocessen, tar kortast tid. Näst
kortast tid tar det att skriva testfallen före kodandet. Längst tar det att skriva testfallen
kontinuerligt under programmeringsprocessen.
Hur påverkas kodstrukturen beroende på när i programmeringsprocessen enhetstesterna
skrivs?
Att planera och skriva testfallen innan funktionalitet har visat sig i den här datainsamligen
att bidra till att fler funktioner skrivs. Att skriva testfallen sist bidrar till att färre antal funktioner skrivs.
Hur bidrar enhetstestningen till att underlätta vid problemlösning? Bidrar olika förhållningssätt till enhetstestning på olika vis?
Deltagarna tycker själva att skriva testfall kontinuerligt under kodandet har hjälpt mest.
Något annat resultat kan varken förneka eller styrka detta.
Rapporten fyllde sitt syfte i den bemärkelse att den undersökte hur tidpunkt för skrivande
av enhetstestning påverkar programmeringsprocessen, med avseende på tidsåtgång, resultat
och underlättande av lösning. Dock var omfattningen av datainsamlingen begränsad och det
fanns ett flertal felkällor som lyftes fram i diskussionen, vilket skulle kunna göra resultaten
och slutsatserna missvisande.
64
F Robert Kumpulainen: Effekten av
en branching model i ett litet
utvecklingsprojekt
F.1
Inledning
I alla mjukvaruprojekt med flera personer krävs möjlighet att sprida kod mellan olika personer. Ett exempel är vid utvecklingen av Linuxkärnan, där kod delas genom att skicka
patches på en e-postlista [55]. De centralt distribuerade modellerna är populära, till exempel
på GitHub [56], där arbetsflödet liknar de flöden som fås med centrala versionshanteringssystem som Subversion (SVN) [57]. Projekten kan internt använda greningsmodeller (eng.
branching models), som beskriver hur och när utvecklarnas ändringar integreras med andra
delar av projektets kodbas. I denna del utreds organiserandet av versionshantering i ett
småskaligt utvecklingsprojekt.
Läsaren antas ha läst kapitel 4.6.
F.1.1
Syfte
Denna del avser beskriva hur principer inom konfigurationshantering kan tillämpas för ett
mindre utvecklingsprojekt.
F.1.2
Frågeställning
1. Hur kan man organisera versionshantering i ett mindre utvecklingsprojekt?
2. Påverkar valet av greningsmodell kodkvaliteten?
3. Är antalet commit-meddelanden innehållande nyckelord som bug och error ett lämpligt
mått för behandling av fråga 2?
F.2
Bakgrund
Gruppens medlemmar hade varierande erfarenheter kring versionshantering.
En
gruppmedlem hade versionshanterat patches med hjälp av SVN för att arbeta på experimentella lösningsidéer. Den patch-baserade SVN-metoden är ett steg upp från att datumdatera en kodbas med hjälp av en manuell kopiering, men orsakar onödigt arbete vid integrering. Baserat på dessa erfarenheter föreslogs en distribuerad greningsmodell för detta
projekt, se kapitel 4.6.
65
F.3. Teori
F.3
Teori
Lämpliga verktyg för arbetet ökar produktiviteten. Nedan beskrivs några verktyg samt arbetsflöden där dessa verktyg är lämpliga att användas.
F.3.1
Git
Git kan beskrivas som en länkad lista där varje element kallas för en commit (pl. commits).
Varje commit innehåller, bland annat:
• information om det sparade innehållet
• pekare till sina föräldrar
• information om auktorn
• ett commit-meddelande.
Denna information hämtas lämpligen via kommandot git-log. Ett kraftfullt kommando för
att konstruera nya commits som bevarar delar av ovanstående metadata är git-rebase; typiskt
bevaras allt utom eventuella föräldrapekare.
En commit med flera föräldrar kallas för en merge commit.
En gren i Git är en namngiven och flyttbar pekare till den commit som Git anser är grenens
senaste. [58, kapitel 3]
F.3.2
Greningsmodeller
En gren (eng. branch) är en virtuell arbetsmiljö där en utvecklare kan göra ändringar isolerat
från andra utvecklare [59].
En greningsmodell är ett regelverk kring hur utvecklare hanterar kod mellan olika grenar,
och avser enligt Walrad och Strom i [60] underlätta
• för andra att göra ändringar utan att det påverkar dina ändringar
• för dig att spara och dela egna galna experiment oberoende av mindre galna ändringar
• hämtning av andras ändringar utan att förlora dina egna ändringar
• integrering av egna ändringar med andras ändringar.
Att utvecklingen sker i isolerade grenar medför merarbete vid integration, vilket också kan
medföra fel på grund av kodkonflikter eller oförutsedda kodberoenden [59].
Den enklaste formen av en greningsmodell är där enbart en gren används för all utveckling.
Denna greningsmodell erbjuder ingen isolation för utvecklare, vilket medför konflikter om
flera utvecklare arbetar med samma del av kodbasen.
66
F.4. Metod
F.3.3
Distribuerade och centraliserade versionshanteringssystem
Centraliserade versionshanteringssystem tillåter utvecklare att hämta ändringar från, och
skicka ändringar till en central punkt eller nod. Ett exempel på ett sådant versionshanteringssystem är SVN [58].
Distribuerade versionshanteringssystem möjliggör för utvecklare att direkt hämta ändringar från andra utvecklare, utan att först synkronisera med en central nod. Ett exempel
på ett sådant är Git [58].
F.3.4
Arbetsflöden
Hur ett utvecklingsteam delar och integrerar kod med varandra påverkas av vilken typ
av versionshanteringssystem som används. Några vanliga typer av arbetsflöden beskrivs
nedan.
Med det centraliserade arbetsflödet integrerar utvecklare egen kod med en delad central nod. Detta flöde utesluter inte användandet av en integrationsledare eller löjtnantdiktatorflödet med hjälp av grenar, men för väldigt stora projekt skulle det leda till väldigt
många grenar [58].
Med integrationsledarflödet hämtar någon in kod från andra utvecklare och integrerar med
projektets kodbas. På GitHub tillämpas detta arbetsflöde med pull requests [56] [58].
Löjtnant-diktatorflödet används exempelvis vid utvecklingen av Linuxkärnan och utgörs av
en hierarki av integrationsledare, med en diktator i toppen som integrerar löjtnanternas integrationer. Utvecklare hämtar därefter diktatorns version av kodbasen för fortsatt utveckling.
[55] [58].
F.4
Metod
För att utforska organiserandet av versionshantering utfördes en fallstudie i formen av ett
projekt, vilken även var inkluderad i undersökningen gällande greningsmodellers påverkan
på kodkvalitet. För att öka urvalet av projekt för behandling av den senare frågan användes
en blandning av publika samt privata källor.
F.4.1
Fallstudie
Ett projekt med 10 gruppmedlemmar utfördes, där den greningsmodell som finns beskriven
i kapitel 4.6 användes vid utvecklandet av ett kryptoanalyssystem, se kapitel 2. Gruppens medlemmar fick en grundläggande utbildning (i form av en arbetsstuga) av Git, samt
grundläggande utbildning om konfigurationshantering via gruppens kvalitetsplan. En
handbok som beskrev sekvenser av Git-kommandon för att utföra vanligt förekommande
sysslor upprättades och uppdaterades under projektets gång och fanns tillgänglig för gruppens medlemmar. Projektgruppens medlemmar intervjuades nära projektets slut gällande
deras versionshanteringserfarenheter. De fall där projektgruppens konfigurationsansvarige
fick ingripa gällande gruppens användande av versionshantering noterades.
F.4.2
Greningsmodellens framgång
Som mått på en greningsmodells framgång användes mängden av commits vars meddelandefält matchade det reguljära uttrycket fix|bug|defect|patch|error|wrong|issue|change.
67
F.5. Resultat
Detta reguljära uttryck applicerades mot utvecklingshistoriken hos sju projekt. Se kodexempel F.1 för invokation. Projekten hämtades i del från fallstudiens projektmedlemmar samt
från den offentliga källan GitHub. För att utröna hur det undersökta projektet hanterat
utgreningar analyserades meddelandefältet hos commits med flera föräldrar.
Kodexempel F.1: Applicera det reguljära uttrycket mot utvecklingshistoriken
git log -E -i --grep="fix|bug|defect|patch|error|wrong|issue|change"
F.5
F.5.1
Resultat
Fallstudie
Tidigt i projektet var kunskapen om Git väldigt spridd. Git-handboken fick blandat kritik i
form av exempelvis "orsakar mer förvirring än nytta" och "den är jättebra, använder den hela
tiden".
Under utvecklingsarbetets första vecka inträffade en felaktig rebase vilket resulterade i att
samma innehåll existerade på två grenar. Detta ansågs inte vara ett kritiskt fel och läts vara
kvar i utvecklingshistoriken.
Behovet att från feature-branches få tillgång till nyligen utvecklad funktionalitet (som fanns
på develop) visade sig under projektets tredje vecka. Detta löstes, i enlighet med greningsmodellen, genom att (efter kontroll med grenens intressenter) flytta gällande featurebranch till sökt funktionalitet från develop med en rebase, eller likvärdigt genom att skapa
en ny gren och därefter göra en rebase.
Vid mitten av projekttiden blev två feature-branches färdiga samtidigt, och slogs ihop med
develop under loppet av några minuter. Detta resulterade i nya kodkonflikter för den senare
grenen, med en "felaktig" merge som följd, vilket ledde till att merge-arbetet gjordes om.
Intervju
En majoritet av gruppens medlemmar upplevde versionshanteringen under projektets tid
som någonting positivt. De gillade Git samt den greningsmodell som använts.
Vissa medlemmar skulle föreslå denna greningsmodell för framtida projekt av liknande
storlek men skulle inte använda den för mindre eller egna projekt.
Vissa av gruppens medlemmar kunde inte Git sedan tidigare och uppskattade möjligheten
att lära sig Git "på riktigt" och rapporterade att de vid projektets slut skapade frekventa
commits innehållande små förändringar.
Frekvensen för problem liknande "koden funkade igår men nu är det trasigt" har varit lägre
jämfört med tidigare erfarenheter enligt vissa gruppmedlemmar, medan andra rapporterar
att de inte stött på sådana problem tidigare. De senare rapporterar också god versionshanteringsvana.
F.5.2
Greningsmodellens framgång
Data ses i tabell F.1.
Försök till att analysera förändringsinnehållet hos flaggade commits resulterade i mycket
stora datamängder vars analys hade tagit för lång tid för att utföras i detta arbete.
68
F.6. Diskussion
Tabell F.1: Analyserade projekt. # commits är antalet commits i det analyserade projektet. # flaggade är antalet
commits som matchade det reguljära uttrycket.
ID
A
B
C
D
E
F
G
F.6
F.6.1
Greningsmodell
enkel
enkel
distribuerad
distribuerad
enkel
enkel
enkel
# commits
92
197
434
494
103
555
182
varav flaggade
16.3%
23.9%
6.9%
21.9%
4.9%
7.0%
4.4%
Diskussion
Metod
Fallstudie
Flera fallstudier ger inte nödvändigtvis samma resultat, även om förutsättningarna verkar
vara liknande. Med andra ord går det presenterade resultatet inte nödvändigtvis att generalisera. Fallstudier lämpar sig för utforska koncept vilket kan utgöra grund för vidare studier.
Greningsmodellens framgång
Som argumenteras av Bird et al. i [61] går det inte alltid att avgöra ursprungsgren för en
commit. Detta kan medföra problem eftersom en mängd commits kan se ut att ha utvecklats
med en linjär historik, trots att de utvecklats på en parallell gren. För projekt hämtade från
GitHub kan detta medföra ett stort problem på grund av pull requests, som har utvecklats
på en parallell gren.
Därtill finns möjlighet att utvecklare inte publicerar sin ursprungliga utvecklingshistorik,
utan döljer sina misstag, och därigenom påverka historiken till att inte ha separata commits
för buggfixar. Detta förhindrar jämförelser av projekt med varierande konventioner gällande
manipulering av utvecklingshistoriken.
F.6.2
Resultat
Fallstudie
Behovet att från en feature-branch få tillgång till nyutvecklad kod på develop illustrerar en
svaghet hos greningsmodeller: kod utvecklas med beroenden till annan kod. Den tidigare
presenterade åtgärden kan ses onödig: varför tvinga rebase när man kan tillåta en merge
från develop till en feature-branch? I de fall där en ihopslagning av grenarna innebär konflikter kan en merge-konflikt vara lättare att korrigera än de av rebase. Då slutresultatet för
grenen är densamma är det lämpligt att använda en merge istället för rebase för att justera
en feature-branch.
Utbildning är en möjlig åtgärd för att förhindra greningsmisstag. Att utbilda om, och se
till att samtliga förstår, hur handboken skall användas kan bidra till minskad felfrekvens.
Att diskutera scenarion under exempelvis arbetsstugor kan vara ett lämpligt sätt att sprida
kännedom om problem som uppståt kring versionshantering. Att utbildningen hölls tidigt
under projektets gång, innan medlemmarna fått bekanta sig med versionshanteringsreglerna,
kan ha bidragit till misstag. En möjlig åtgärd till detta kan vara att ha en nybörjarkurs samt
kontinuerlig utbildning under projektets gång, förslagsvis via arbetsstugor.
69
F.7. Slutsatser
Greningsmodellens framgång
Det är möjligt att eventuella effekter beror på nyttjandet av processer som kodgranskning
innan kodintegration, och inte på grund av greningsstrategi.
Huruvida de undersökta projekten har manipulerat utvecklingshistoriken kontrollerades
inte för vid datainsamlingen. Det är möjligt att måttet fungerar för att jämföra projekt med
liknande policy gällande manipulering av utvecklingshistoriken, vilket kan vara ett ämne
för vidare efterforskning.
Det föreslagna måttet har inte jämförts med andra metriker för kodkvalitet som rader kod
och cyklomatisk komplexitet. Det vore möjligt att tillämpa tidigare kända metoder för analys
av kodkvalitet via analys av git-historikens förändringsinnehåll, men någon sådan analys
utfördes inte. Detta tillintetgör slutsatsförmågan gällande kodkvalitet från insamlad data.
F.7
Slutsatser
Olika projekt har olika konventioner angående integriteten hos utvecklingshistoriken. Det
föreslagna måttet på kodkvalitet, att räkna förekomsten av nyckelord, tar inte hänsyn till
detta faktum.
Då insamlad data gällande greningsmodellens framgång inte kontrollerade för tidigarenämnda konventioner saknas slutsatsförmåga i frågan om kodkvalitet.
Påverkar valet av greningsmodell kodkvaliteten? Ingen slutsats kan dras.
Hur kan man organisera versionshantering i ett mindre utvecklingsprojekt?
• Ha kontinuerlig utbildning, gärna med nybörjarkurs.
• Använd en greningsmodell.
70
G Erik Rönmark: Kvalitetssäkrande
processer och produktkvalitet i
ett litet utvecklingsprojekt
G.1
Inledning
Inom ramen för Software Quality Assurance finns flera kvalitetssäkrande processer som går
att integrera i utvecklingsprocessen, däribland kodgranskning. I mindre utvecklingsprojekt
finns vanligtvis inte personer dedikerade till att bara arbeta med kvalitetssäkring. På grund
av detta kan man inte alltid tillämpa metoder som fungerar i storskalig mjukvaruutveckling.
Därför applicerades en egen utarbetad kvalitetssäkrande process anpassad till vårt utvecklingsprojekt. Denna rapport undersöker hur de kvalitetssäkrande processer som tillämpades
i detta mindre utvecklingsprojekt påverkade kvaliteten hos slutprodukten.
G.1.1
Syfte
Syftet med rapporten är att ta reda på hur de kvalitetssäkrande processer vi tillämpade
påverkade den slutgiltiga produktkvaliteten.
G.1.2
Frågeställning
1. Hur påverkade kodgranskning den slutgiltiga produktkvaliteten?
2. Hur påverkade de användartest vi gjort den slutgiltiga produktkvaliteten?
3. Hur påverkade de utvärderingar vi gjort den slutgiltiga produktkvaliteten?
G.1.3
Avgränsningar
Rapporten besvarar inte huruvida kodgranskning generellt bidrar till produktkvalitet. Rapporten besvarar heller ej hur utvärderingar och användartest påverkar produktkvalitet
generellt. Ingen jämförelse görs heller med liknande projekt.
G.2
Bakgrund
Från början av projektet stod det klart att det här var en grupp med mycket blandade
erfarenheter av grupparbeten. Därför var projektgruppen väldigt genomgående när den
tidigt diskuterade samarbete i gruppen samt skrev gruppkontrakt. För att gruppen under projektets gång skulle kunna identifiera och åtgärda sådant som riskerar att försämra
projektet bestämdes att omfattande utvärderingar skulle utföras efter varje projektfas. Hur
utvärderingarna gick till förklaras i avsnitt 4.7 i den gemensamma delen.
71
G.3. Teori
Författaren av denna rapport blev tilldelad rollen som kvalitetssamordnare och hade därmed
ansvar över projektets kvalitetsplan. I kvalitetsplanen specificerades att det under projektiteration 2 och 3 skulle utföras användartester. Det är till stor del de användartesten samt
feedback från kunden som utgör den bas för att mäta produktkvaliteten som använts. I
kvalitetsplanen specificerades även hur gruppens process för kodgranskning skulle se ut.
G.3
Teori
Detta kapitel berör teorin bakom kodgranskning och användning av rader kod som mätdata.
G.3.1
Kodgranskning
Målet med granskningar är att upptäcka designmässiga brister, hitta avvikelser från standarder och konventioner, samt identifiera framtida risker [62]. Kodgranskning tenderar att
öka kvaliteten hos mjukvara [63].
G.3.2
Rader kod som mätdata
Skrivna rader kod i ett program som mätdata kan användas för att mäta storleken på ett program och hur mycket resurser som krävst för att skriva programmet[62]. Det kan även användas för att försöka förutsäga kvaliteten men är inte speciellt effektivt för detta ändamål[64].
G.4
Metod
För att undersöka kodgranskning samlades data in från Git, för att undersöka användartester
och utvärderingar granskades de dokument som producerats i samband med dem. Metoden
för hur själva kodgranskningen och utvärderingarna gick till återfinnes i avsnitt 4.5.2 respektive avsnitt 4.7.
G.4.1
Kodgranskning
Alla projektets feature branches gicks igenom. Antalet rader kod som accepterats och blivit
inflyttade till develop skrevs ner. Antalet rader kod som lagts till och tagits bort mellan
den första kodgranskningen och att branchen var klar skrevs även det ner. Bara feature
branches räknades, ingen kod som vi inte skrivit själva är alltså med i resultatet. Rader kod
som tillkommit på grund av namnbyte av en fil räknades inte heller. Bara HTML-, CSS- och
JavaScript-filer räknades.
G.4.2
Användartest
Anteckningarna från användartesten gicks igenom och synpunkter från användarna sammanställdes till en lista. De saker i listan som implementerats i slutprodukten kryssades
av. Synpunkterna klassificerades i kategorierna buggar, funktionella synpunkter och designmässiga synpunkter utifrån vilken sorts synpunkt det var. Buggar inkluderade rena fel som
hittats under testet, funktionella synpunkter var idéer som avändarna fick om hur programmet skulle kunna fungera och designmässiga synpunkter var sådant som rörde programmets
grafiska utformning och utseende. Andelen åtgärdade synpunkter inom varje kategori räknades ut.
72
G.5. Resultat
G.4.3
Utvärdering
Resultatet av utvärderingarna i 2 gicks igenom. Från materialet sammanställdes siffrorna
för antalet förbättringspunkter och för antalet åtgärder som planerades på det efterföljande
mötet. Detta gjordes för alla tre utvärderingarna.
G.5
Resultat
Följande del behandlar
utvärderingarna.
G.5.1
resultatet
från
kodgranskningen,
användartesten
och
Kodgranskning
Nedanstående tabell visar storlek på varje feature samt antalet ändringar som gjorts på varje
feature efter kodgranskning.
Tabell G.1: Ändringar per feature efter kodgranskning.
Featurenummer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Totalt
Tillagda rader
kod per feature
188
63
625
150
140
15
30
9
223
254
257
59
352
44
72
254
167
208
27
8
66
153
377
545
60
4350
Borttagna rader
kod per feature
6
363
4
10
1
12
26
4
9
86
84
39
15
77
20
80
42
44
14
18
38
1
109
33
9
1144
Tillagda rader kod
efter kodgranskning
6
77
7
16
3
4
0
0
0
16
38
97
206
10
0
4
0
0
25
0
0
0
13
36
0
617
Borttagna rader kod
efter kodgranskning
5
83
11
19
3
23
0
0
0
10
70
116
220
10
0
10
0
0
72
0
0
0
15
17
0
677
Tabellen visar att flera av kodgranskningarna ledde till förändringar i koden. Förändringarna
bestod av både tillägg av nya rader kod, samt av borttagning av rader kod.
73
G.6. Diskussion
G.5.2
Användartest
Nedanstående tabell visar hur mycket av användarnas feedback och ideer som samlades in
och implementerades.
Tabell G.2: Resultatet av användartest.
Funna
buggar
1
Åtgärdade
buggar
1
Funktionsförslag
5
Implementerade
funktionsförslag
1
Designförslag
11
Implementerade
designförslag
8
Tabellen visar att flera av användarnas ideér blev implementerade, bara ett funktionsförslag
blev implementerat. Under användertestet hittades även en bugg som åtgärdades.
G.5.3
Utvärderingar
Nedanstående tabell visar antalet punkter som kunde förbättrats som togs upp under varje
utvärdering. Tabellen visar också antalet konkreta förslag som kom upp i samband med
diskussionen.
Tabell G.3: Resultatet av utvärderingarna.
Utvärderingsnummer
1
2
3
Förbättringspunkter
48
76
38
Förbättringsförslag
16
10
14
Ur tabellen ser man att många av de förbättringspunkter som togs upp under
utvärderingarna faktiskt behandlades med konkreta förbättringsförslag.
G.6
Diskussion
Analys av kodgranskning använde sig av antalet tillagda och borttagna rader kod som mätdata, det säger ingenting om kvaliteten på koden som ändrats. Här har antagandet gjorts
att de punkter som tagits upp efter en granskning har varit negativa för kvaliteten och att
den nya koden har bidragit till högre kvalitet. Detta antagande är dock rimligt, eftersom
de punkter som tas upp efter kodgranskning är potentiella brister, fel och avvikelser mot
stilguiden. Att kodgranskningen resulterade i så pass mycket förändringar var inte heller
särskilt märkvärdigt då gruppen ej bestod av erfarna webbutvecklare. Dock gör även erfarna
webbutvecklare fel ibland.
Resultaten av användartesten och utvärderingarna är ej viktade. De säger inget om hur
stor påverkan ett förslag eller en förbättringspunkt hade. Många av förbättringspunkterna
från utvärderingarna löste sig själva eller utan något möte. Gällande användartesten så
fanns det redan planer att testa några av användarnas förslag. Användartesterna utfördes
dessutom på redan granskad och enhetstestad kod, vilket kan förklara varför bara en bugg
hittades.
G.7
Slutsatser
Från resultatet av kodgranskningen kan man se att det förekom en hel del ändringar som
kanske inte hade gjorts utan kodgranskningen. Ungefär 26 % av antalet ändrade rader kod
74
G.7. Slutsatser
som accepterats till developbranchen tillkom efter kodgranskning. Eftersom projektgruppens kodgranskning i första hand sökte efter designmässiga brister samt avvikelser från
standarder och konventioner är det rimligt att dra slutsatsen att kodgranskning ökade den
slutgiltiga produktkvaliteten.
Från resultaten av användartesten kan man se att förslag från användarna faktiskt implementerades. I testen hittades dessutom en ren bugg som kunde åtgärdas. Användarna var
typiska för de som ska använda slutprodukten och flera förslag från dem implementerades.
Utifrån detta är det rimligt att dra slutsatsen att användartesten påverkade den slutgiltiga
produktkvaliteten positivt.
Utvärderingarna uppdagade flera förbättringspunkter. Dessa protokollfördes och följdes
upp, under utvärderingsmötet gavs dessutom konkreta förbättringsförslag för att åtgärda
dessa punkter. Utvärderingarna bidrog därför till kvaliteten hos utvecklingsprocessen.
Mer effektiva möten, administration och utveckling gav mer timmar åt produktkvalitet
och kvalitetssäkrande processer. Utifrån detta dras slutsatsen att även utvärderingarna
påverkade den slutgiltiga produktkvaliteten positivt.
75
H Kristoffer Tennivaara: Metoder
och processer för grafiska
användargränssnitt
H.1
Inledning
Ett grafiskt användargränssnitt kan beskrivas som en länk mellan användaren och den programvara som användaren arbetar med. Gränssnittet tillåter användaren att mata in information vilket ger användaren möjligheten att påverka systemet. Systemet i sin tur bearbetar
den inmatade informationen och presenterar resultat i form av utdata till användaren. Målet
med ett grafiskt gränssnitt är att öka effektiviteten och förenkla användningen av programmet. Hur bra gränssnittet gör detta beskriver måttet användbarhet. Denna rapport utforskar
metoder och processer för framtagning och utvärdering av grafiska användargränssnitt i ett
småskaligt utvecklingsprojekt.
H.1.1
Syfte
Syftet med rapporten är att jämföra och ta reda på vilka processer och metoder som lämpar
sig bäst för att ta fram ett användargränssnitt i ett småskaligt projekt.
H.1.2
Frågeställning
Följande frågor ligger till grund för rapporten:
1. Vilka aspekter i kvalitetsmåttet användbarhet är viktigast för ett utbildningsverktyg?
2. Vad har olika sätt att fatta designbeslut på för effekt på användargränssnittet?
3. Vilken metod lämpar sig bäst för att utvärdera ett användargränssnitt i ett småskaligt
projekt?
H.1.3
Avgränsningar
Fokus ligger enbart på webbaserade applikationer då utvecklingsarbetet endast skett för just
en sådan.
H.2
Bakgrund
Idag implementerar de flesta program ett grafiskt användargränssnitt. En stor del av resurserna för att utveckla ett program eller tjänst går till att designa ett bra gränssnitt. [65] Om till
exempel en hemsida har ett dåligt designat användargränssnitt finns risken att användaren
lämnar sidan för att hitta en sida som har en bättre design.
76
H.3. Teori
H.3
Teori
I teoridelen presenteras de teorier som använts och motiveringar om varför.
H.3.1
Användbarhet
Användbarheten hos ett system är ett kvalitetsmått och ISO 9241-11 definierar användbarhet
som:
“Den grad i vilken specifika användare kan använda en produkt för att uppnå ett specifikt
mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt i ett givet
sammanhang.” [66]
Detta ger kvaliteterna ändamålsenlighet, effektivitet och personlig tillfredsställelse. Utöver
dessa har Nielsen [67] velat väga in tre andra kvaliteter i begreppet:
• Learnability: Hur lätt det är att lära sig använda programmet för en nybörjare.
• Memorability: Hur lätt det är att minnas hur man gjorde om man gör ett uppehåll och
därefter börjar använda produkten igen.
• Errors: Hur många eller få fel som användarna gör.
H.3.2
Designbeslut
Enligt Jared M. Spool [68] finns det fem vanliga sätt att ta designbeslut på. De är baserade på
hur mycket forskning som utförs innan besluten tas. I vissa projekt finns det inte tillräckliga
skäl för att använda den tid och resurser det skulle kräva för att kunna göra omfattande användarundersökningar. Samtidigt skulle andra projekt misslyckas om de inte utförde dessa.
De olika beslutstyperna nedan återspeglar i stigande ordning, den mängd forskning som utförs innan ett beslut tas.
1. Unintended design är det som sker när man utvecklar en produkt utan att ta hänsyn
till designen.
2. Self design är designresultatet som blir när projektmedlemmarna designar åt sig
själva. Projektmedlemmarna ser då inte bortom sina egna erfarenheter när de fattar
designbeslut.
3. Genius design är baserat på tidigare individuella erfarenheter hos projektmedlemmarna. Precis som i self design använder man sig bara av sina egna erfarenheter för
att ta designbeslut. Detta fungerar bra för erfarna utvecklare som har utvecklat produkter inom samma område tidigare.
4. Activity-focused design går ut på att planera och studera användarnas aktiviteter när
de använder produkten. Man använder sig av denna design när projektmedlemmarna
inte har någon tidigare erfarenhet av aktiviteterna i fråga. I forskningen använder man
sig av aktivitetsbaserade tekniker som till exempel uppgiftsbaserade användartester.
Dessa tester utförs genom att testanvändare får uppgifter som de ska lösa med hjälp av
produkten. Denna teknik gör att man får kvalitativa insikter i vad som orsakar problem
för användarna, vilket resulterar i att man kan förbättra designen därefter.[69]
5. User-focused design är den stil där man utför flest användarundersökningar. Man
går ner på djupet och försöker se bortom aktiviteterna. Man tittar på mål, behov och
sammanhang hos användarna. Den här stilen är nödvändig om projektgruppen är ute
efter att skapa en så bra användarupplevelse som möjligt. För att göra detta använder
man sig av användarcentrerade tekniker som till exempel en robust persona. Detta för
att gruppen ska få en kontextuell förståelse av användarnas upplevelse.
77
H.4. Metod
Spool har undersökt de olika stilarna och kommit fram till att den mest effektiva projektgruppen hade erfarenhet i alla fem stilarna. De valde den stilen som bäst passade behoven och
målen baserat på det projekt de arbetade på. Han kom också fram till att valet av designstil har en faktisk effekt på designen. De grupper som producerade de bästa upplevelserna
kände till alla designstilar och kunde snabbt växla mellan dem. De visste när det var dags
att gå ner på djupet med användarcentrerad design i ett projekt. Samtidigt visste de också
när det var viktigt att få ihop en snabb design, i vetskapen om att det skulle bli en oavsiktlig
design.[68]
H.3.3
Metoder för att utvärdera ett användargränssnitt
Det finns olika sätt att utvärdera ett gränssnitt på. Enligt Jakob Nielsen [70] finns det 7 olika
sätt:
• Heuristic evaluation: Den mest informella metoden där användbarhetsspecialister
bedömer om elementen följer de etablerade användbarhetsprinciperna. Denna metod
kan integreras in i den iterativa designprocessen, och kan utföras av projektmedlemmarna istället för specialister. Det går till så att medlemmarna inspekterar gränssnittet
var för sig. Först efter att alla utvärderingar utförts får man kommunicera med varandra för att summera iakttagelserna. [71]
• Cognitive walkthroughs: En mer detaljerad procedur för att simulera en användares
problemlösning steg för steg, för att undersöka om den simulerade användarens mål
kan antas leda till nästa rätta åtgärd.
• Formal usability inspections: En 6-stegs procedur med strikt definierade roller för att
kombinera Heuristic evaluation och en förenklad form av Cognitive walkthroughs.
• Pluralistic walkthroughs: Är möten där användare, utvecklare och specialister på den
mänskliga faktorn går igenom ett scenario och diskuterar alla interaktiva komponenter.
• Feature inspection: Visar en sekvens av funktioner som används för att utföra vanliga
uppgifter. Man kontrollerar långa sekvenser och besvärliga steg som inte skulle vara
naturliga för användare att prova.
• Consistency inspection: Designers som arbetar med flera andra projekt inspekterar
gränssnittet för att se om det gör saker på samma sätt som designmönstren i deras
andra projekt.
• Standards inspection: En expert på gränssnittsstandarder inspekterar gränssnittet för
att se om det följer industristandarden. Till exempel bör mjukvara avsedd för Windowsmiljö ha samma gemensamma element, såsom samma funktioner på Arkiv-menyn och
Hjälp-menyn. [72]
H.4
Metod
Denna del beskriver metoder som följts för att erhålla resultat till frågeställningen.
H.4.1
Litteraturstudie
För att hitta avhandlingar inom det relevanta området har Google-sökningar på "Design Decision Styles", "ISO Usability Standards" samt "Usability Inspection Methods" gjorts. Resultatet
av det var intressanta artiklar och forskning som skrivits av kända personer inom respektive
område. Jakob Nielsen som uppfunnit ett antal metoder inom användbarhet, samt Jared M.
Spool och hans arbete inom användargränssnitt har bidragit till mycket av kunskapen i detta
arbetet.
78
H.5. Resultat
H.4.2
Projekt
För att kunna jämföra teorin och forskningen med ett konkret exempel, har ett småskaligt
projekt utförts i samband med kursen TDDD96 Kandidatprojekt i programvaruutveckling.
En iterativ utvecklingsprocess har använts där designbeslut, användartester och utvärdering
av användargränssnittet skett löpande i varje iteration.
För att få verklighetstrogna resultat från användartester letades tre personer upp som
stämde överens med programmets målgrupp. Varje användartest utfördes sedan under
en 30-minuters period där användarna fick uppgifter att lösa med hjälp av programmet.
Uppgifterna bestod av krypterade texter som skulle dekrypteras, vilket motsvarade realistiska användarscenarion. Under testerna iakttogs deras aktiviteter av två gruppmedlemmar
och eventuella brister i designen noterades. Efter testerna fick användarna också möjlighet
att komma med egna förbättringsförslag. All insamlad data från testerna diskuterades sedan
inom gruppen för att komma fram till eventuella designändringar.
H.5
Resultat
Denna del redovisar resultatet av de undersökningar som specificerats i metoddelen.
H.5.1
Användbarhet
Projektet gick ut på att skapa ett utbildningsverktyg, och projektmedlemmarna hade sedan
tidigare erfarenhet av att använda sig av utbildningsverktyg. Det kunde därför redan i början
av projektet specificeras vad som var viktigt för att det skulle bli en så användbar produkt
som möjligt.
Av de sex användbarhetskvaliteterna som presenteras i teorin H.3.1 kom projektgruppen
fram till att det var viktigast att verktyget:
1. Är lätt att lära sig använda.
2. Är effektivt, med avseende på hur snabbt användare kan utföra uppgifter.
3. Minskar antalet fel som användarna kan tänkas göra.
H.5.2
Designbeslut
Användargränssnittet på produkten låg inte i fokus i början av iteration 1, utan själva funktionaliteten för produkten implementerades först. Det skapades ett provisoriskt kodskelett
för att testa all funktionalitet, men inget utöver det. Således utvecklades produkten under
den perioden med unintended design samt self design. Effekten av denna kombination av
designstilar var, i detta fallet som väntat, ett användargränssnitt utan hög användbarhet.
För att höja användbarheten byggdes kodskelettet om med hjälp av en prototyp där användaraktiviteterna låg i fokus. Det skulle kunna jämföras med activity-focused design, med
skillnaden att forskningen bestod utav kundens samt projektmedlemmarnas testanvändning
av produkten. Effekten av den designstilen var ett användargränssnitt med ett högre användbarhetsmått än tidigare.
Under iteration 2 och 3 undersöktes det närmare hur användargränssnittet skulle se ut och
fungera. Användartester utfördes och både kommentarer och förslag från testanvändarna
analyserades för att få insikt i vilka förbättringsförslag som kunde höja användbarheten på
produkten. Designbesluten som gjordes efter testerna höjde sedan användbarheten ytterligare.
79
H.6. Diskussion
H.5.3
Metoder för att utvärdera ett användargränssnitt
Då det inte funnits någon budget för att hyra in specialister i detta projekt, har alla utvärderingsmetoder uteslutits förutom heuristic evaluation, som har använts löpande under projektets
gång. Projektmedlemmarna inspekterade gränssnittet löpande under utvecklingsperioden,
hittades problem eller eventuella förbättringar av produkten diskuterades vilka åtgärder som
skulle vidtas.
H.6
Diskussion
Här diskuteras tillvägagångssätt och resultat som erhållits under studien.
H.6.1
Resultat
Resultatet av vilka aspekter i kvalitetsmåttet användbarhet som är viktigast för ett utbildningsverktyg är troligtvis inte representativt för utbildningsverktyg i allmänhet. Detta
eftersom verktyget som utvecklats endast är tänkt att användas under en 4-timmars period,
för att sedan aldrig användas igen av samma användare. Detta medför att vissa aspekter i
kvalitetsmåttet användbarhet faller bort direkt, såsom memorability.
Designbesluten som tagits under detta projekt har varit väl genomtänkta och activity-focused
design har fungerat bra. Hade bara unintended design i kombination med self design använts skulle inte det resulterande användargränssnittet haft lika hög användbarhet som
det har idag. Spool’s [68] undersökning argumenterar för att man ska välja designstil efter
de projektspecifika behov som finns. Begränsningen av resurser i form av tid till projektet har dock medfört att user-focused design ej har varit möjligt att utföra. Genius design
har heller inte varit möjlig, då projektmedlemmarna i början av projektet inte hade så stor
erfarenhet utav webbutveckling. Skulle tidsbudgeten tillåtit utförandet av alla användarundersökningar som behövts göras för att använda sig av user-focused design, är det troligt
att produkten skulle fått en högre användbarhet. Detta eftersom att man införskaffar sig en
bättre förståelse av användarnas upplevelse.
De flesta metoder som finns för att utvärdera ett användargränssnitt går ut på att hyra in
specialister som utvärderar användargränssnittet. Detta medförde att Heuristic evaluation
användes eftersom det kunde implementeras i den iterativa designprocessen. Eftersom den
metoden kan utföras av projektmedlemmarna själva, spar det pengar, men tid går förlorad
istället. Hade utvärderingen utförts av specialister istället, skulle det sparat värdefull tid
för projektmedlemmarna som sedan kunde använts för att skapa ytterligare funktionalitet.
En utvärdering av specialister skulle också kunna tänkas bli mer objektiv, vilket är väldigt
viktigt.
H.6.2
Metod
Projektet hade inte någon monetär budget, utan endast en budget i tid. Man var tvungen
att beräkna hur mycket tid det skulle gå åt för att kunna utföra vissa moment, och därför
slopades också alternativ som ej skulle kunnat klämmas in under den tid som fanns tillgänglig. För att få mer representativa resultat utav studien hade projektets budget med fördel
kunnat vara större. Hade frågorna ställts under ett projekt där omfattningen skilt sig mycket
från detta projekt kan det tänkas att man skulle kunna få helt andra resultat.
Datainsamlingen från användartesterna som gjorts kan ses som bristfällig eftersom användarna själva inte skrev ner någonting, utan endast observerades under testerna. En inbyggd funktionalitet i systemet som kunde logga användarens aktiviteter som till exempel
80
H.7. Slutsatser
hur många gånger specifika knappar använts under ett test skulle också kunnat ge en klarare
bild av hur gränssnittet användes.
H.7
Slutsatser
Utifrån resultat och teori från studien kan vissa slutsater dras.
För ett generellt utvecklingsverktyg är alla aspekter mer eller mindre viktiga för att få en så
hög användbarhet som möjligt. Det går vanligtvis inte att hoppa över någon aspekt utan
att det drar ner användbarheten. Projektet i fråga hade dock särskilda omständigheter som
gjorde att det kunde fokuseras mer på vissa aspekter än andra. Den mest betydande av dessa
var att varje användare av produkten endast skulle använda produkten en enda gång.
Designbesluten och det sätt man väljer att fatta dem på har en faktisk effekt på användargränssnittet. Det gäller att välja den stil som bäst passar behoven och målen för det projekt
man arbetar på, eftersom effekten kan vara både bra och dålig. Grundtanken är att fler och
djupare undersökningar innan man fattar designbeslut resulterar i bättre förståelse för vilka
behov som finns, och därmed kan man fatta beslut som ger ett bättre användargränssnitt.
Använder man sig av en iterativ utvecklingsprocess samt har en liten eller ingen budget alls
är Heuristic evaluation den metod som lämpar sig bäst för att utvärdera ett användargränssnitt. Den går att implementera i utvecklingsprocessen, man slipper då det dröjsmålet som
sker om specialister ska anlitas samt att utvecklingen kan fortskrida under tiden.
81
I
I.1
Victor Tranell: Kravhantering
med Scrum
Inledning
En central del i ett projekt är att ha en bra kravspecifikation. Utan en bra kravspecifikation
finns det ingen nedskriven överenskommelse mellan kund och projektgrupp. Samtidigt är
diskussionen med kunden om kravspecifikationen minst lika viktig för utvecklingsgruppen.
Detta gör att man hela tiden vet att man jobbar på något som ger värde till kunden. Denna
rapport kommer handla om hur krav hanteras tillsammans med en agil utvecklingsmetodik.
I.1.1
Syfte
Syftet med studien är att analysera hur kravinsamling fungerar tillsammans med agil mjukvaruutveckling.
I.1.2
Frågeställning
1. Vilka fördelar och nackdelar finns med agil kravhantering?
2. Vilken utvecklingsmetod lämpar sig bäst för ett liknande projekt i framtiden sett till
kravhantering?
I.2
Bakgrund
I kursen TDDD96 Kandidatprojekt i mjukvaruutveckling utfördes ett projekt åt gruppen för
informationskodning vid ISY. Projektet gick ut på att ersätta ett äldre program som användes
i utbildningssyfte. Gruppen beslutade att använda den agila utvecklingsmetodiken Scrum i
detta projekt.
Kunden hade hårda krav på att det nya programmet skulle vara lätt att vidareutveckla samt
att det skulle vara en webbapplikation. Resterande utformning av programmet var kunden
inte lika säker på utan ville ta ställning till förslag från projektgruppens sida. Därmed krävdes
ett flertal iterationer av kravspecifikationen innan konsensus nåddes.
I.3
Teori
Nedan beskrivs hur agil kravhantering samt traditionell kravhantering typiskt går till. Exempel på en agil utvecklingsmetod är Scrum som beskrivs i avsnitt 3.5 i rapporten.
82
I.3. Teori
I.3.1
Traditionell kravhantering
Den traditionella metoden är en linjär process där man i början av varje projekt har en planeringsfas. Planeringsfasen resulterar i en kravspecifikation med välspecificerade krav. Kraven
ska vara noggrant specificerade så att de är mätbara och inte kan misstolkas på något sätt. Anledningen till detta är att dokumentet även används som kontrakt mellan kund och utvecklare. Därefter implementeras systemet som specificeras av kravspecifikationen. Slutligen
valideras det implementerade systemet mot kravspecifikationen tillsammans med kunden.
[15]
I.3.2
Agil kravhantering
I början av ett agilt projekt behöver man ta reda på vad man ska göra. En lång lista av funktioner och krav fås efter intervjuer med olika intressenter. Därefter behöver listan prioriteras
och de högst prioriterade kraven behöver detaljeras. För att göra detta genomförs ytterligare
intervjuer och diskussioner med intressenter. Därefter bestämmer utvecklarna hur många
av de högst prioriterade kraven de kommer hinna med under nästkommande iteration. Om
frågor kring krav uppstår under iterationen diskuteras dessa med kunden direkt. När iterationen tagit slut visas produkten upp för kunden som direkt kan framföra sina åsikter.
Tillsammans med kunden prioriteras listan med krav och funktioner om och eventuella nya
krav placeras i listan och en ny iteration påbörjas. Detta fortgår tills kunden vid demonstrationen tycker att produkten är klar. [15]
I.3.3
Fördelar och nackdelar med agil kravhantering
I en studie från Elsevier [73] sammanställdes en stor mängd artiklar inom ämnet agil
kravhantering. Sammanställningen visar att agil kravhantering främst löser följande fem
problem:
• Kommunikationsgap
• För bred specificering
• Validering av krav
• Föråldrad dokumentation
• Frånvarande kund
I [73] från Elsevier visas att de största problemen med agil kravhantering är följande fem:
• Avsaknad av dokumentation
• Frånvarande kund
• Kostnadsuppskattning
• Fel arkitekturval
• Velande kund
I den traditionella kravhanteringen måste utvecklarna specificera krav på ett system innan de
har satt sig in i det. Kunden kan därför ha en bild av systemet och utvecklarna en helt annan.
Den agila lösningen på detta är att kunden får en demonstration av produkten efter varje
iteration och eftersom en iteration är kort så kan kunden tidigt upptäcka om utvecklarna har
en annan bild av systemet än de själva har. [73]
83
I.4. Metod
Demonstration av produkten gör även att problemet med att validera krav löses. Kunden
bestämmer om produkten är godkänd eller om det behövs fler iterationer. Att ha regelbundna demonstrationer gör att kunden måste vara tillgänglig och involverad. Samtidigt
är detta en av de största svårigheterna med agil kravhantering eftersom det förutsätter att
kunden vet hur de vill ha produkten och kan svara på utvecklarnas frågor. [73]
När utvecklarna som följer den traditionella metoden specificerar sina krav tenderar de att
specificera mer än vad som behövs. Exempelvis kan man ha specificerat ett krav som aldrig
kommer implementeras. Enligt den agila metoden har man då lagt onödig tid på något som
inte ger värde för kunden. Å andra sidan är detta en av svårigheterna med agil kravhantering
eftersom utvecklingsgruppen inte tänker igenom hur arkitekturen ska se ut som om de hade
haft en lång planeringsfas. Detta gör att man kan behöva byta arkitektur mitt i projektet
vilket kan vara kostsamt. [73]
Ytterligare en skillnad mellan agil och traditionell utveckling är att man inom den agila
sfären endast skapar den mängd dokumentation som behövs. Man minimerar på så vis tiden
man behöver lägga på dokumentation för att den inte ska bli inaktuell och rent missvisande.
Å andra sidan gör dokumentation att nya projektmedlemmar har det lättare att sätta sig in i
projektet. [73]
I agila projekt är det svårt att på förhand säga hur mycket ett projekt kommer att kosta eftersom man inte har en stor planeringsfas. Dessutom kan kunden under projektets gång ändra
kraven vilket inte är något man kan planera för. Därför låter man ofta kunden betala för varje
iteration istället för en klumpsumma för hela projektet. Även den traditionella metoden som
har haft en stor planeringsfas har detta problem eftersom det kan bli förändringar av krav
eller moment som tar längre tid än planerat. [73]
I.4
Metod
Nedan beskrivs metoden som utförts för att besvara frågeställningen i avsnitt I.1.2.
I.4.1
Litteraturstudie
För att få perspektiv på studien har ett flertal vetenskapliga artiklar och böcker inom området Requirements engineering studerats och bidragit till kunskap inom området. Dessa erhölls genom sökningar på “agile requirements” samt biblioteket vid Linköpings universitet.
I.4.2
Projekt
För att svara på hur en agil utvecklingsmetodik påverkar kravhanteringen har ett projekt utförts i samband med kursen TDDD96 Kandidatprojekt i mjukvaruutveckling. I projektet användes den agila utvecklingsmetodiken Scrum där författaren i egenskap av analysansvarig
ansvarade för kravhanteringen och kundkontakten.
I agil anda har kravspecifikationen itererats fram mellan kund och projektgrupp. Sedan har
kravinsamlingsprocessen utvärderats och resultatet diskuterats för att sedan dra paralleller
till artiklar och böcker inom ämnet.
I.5
Resultat
Nedan beskrivs några nyckelpunkter för hur kravhanteringen gick till i projektet.
84
I.6. Diskussion
I och med att uppgiften var att ersätta ett äldre program var kravinsamlingen väldigt smidig.
All funktionalitet som fanns i det gamla programmet skulle finnas med i det nya. Därmed
blev alla funktionella krav fastställda tidigt.
Kundens kontor fanns på universitetet och kunden var därmed för det mesta anträffbar där
eller via mail för eventuella frågor. Då kunden i början av projektet inte var säker på hur
systemet skulle se ut fick projektgruppen komma med förslag till vilka kunden kunde ta
ställning. Gruppen använde sig av prototyper och en kravspecifikation för att presentera
förslagen. Därmed träffades representanter från gruppen och kunden ofta i början av projektet. Detta för att så snabbt som möjligt få en tydlig bild av vad kunden ville ha och för att se
till att det inte arbetades med något i onödan.
Efter varje iteration hölls en demonstration av produkten för kunden. Under demonstrationen fick kunden se vad som hade gjorts under föregående iteration och fick själv en
uppfattning om hur mycket arbete som var kvar. I samband med demonstrationen uttryckte
kunden vilka funktioner som saknades och vad som skulle prioriteras under nästkommande
iteration. Dessa möten var en stor källa till de aktiviteter som arbetades på under resten av
projektet. Efter varje möte med kunden sammanställde gruppen ett mötesprotokoll med vad
som hade bestämts under mötet. Detta protokoll skickades till kunden för att kontrollera att
inget hade missats eller missförståtts.
Efter den andra iterationen var kunden nöjd med produktens funktionalitet. Designen tyckte
kunden var övergripande bra men behövde finputsas. Projektgruppen fick därmed fria händer att jobba med vad de själva tyckte skulle förbättras under den tredje och sista iterationen.
Som avslut på projektet hölls ett systemtest för att validera att produkten blev som det var
tänkt. Testet gjordes genom att kravspecifikationen öppnades och produkten startades. Ett
krav i taget gicks kravspecifikationen igenom och verifierades i programmet. I och med att
kunden har medverkat i demonstrationerna under projektets gång hade kunden redan sett
den funktionalitet som skulle verifieras vilket gjorde att mötet gick fort.
I.6
Diskussion
Kunden var i detta fall laborationsassistent i den laboration där detta verktyg ska användas.
Därmed hade kunden full auktoritet att säga vad som skulle vara med eller inte i det nya
programmet. I och med att vår kund hade makt att ta beslut på rak arm utan att behöva
konsultera andra intressenter fungerade agil kravhantering bra.
Eftersom kunden hela tiden var delaktig i projektet hade kravspecifikationen endast två
syften. Dels var den något att diskutera kring på mötena och dels kunde den användas i
slutet för valideringen. Vid valideringen var dock kunden väl medveten om vilken funktionalitet som var implementerad vilket gjorde att valideringen kändes överflödig. Dessutom
användes mötesprotokoll för att dokumentera kundens nya efterfrågningar istället för att
kravsätta dem och uppdatera kravspecifikationen.
I och med att kunden själv inte var säker på hur systemet skulle se ut eller fungera så var en
agil metod väldigt bra. Projektgruppen kunde, ur sin synvinkel, ge kunden ett förslag på ett
system och sedan få feedback på produkten tre gånger innan inlämningen.
I mindre projekt där arkitekturen lätt kan ändras och fokuset ligger på att skapa nya funktioner snarare än att lösa komplicerade problem kan agil utveckling vara att föredra. Däremot om projektet man ska utföra har en kund som har en tydlig bild av vad som ska
85
I.7. Slutsatser
implementeras och inga krav kommer ändras kan den traditionella metoden passa bättre.
Eftersom det, i detta projekt, fanns ett tidigare system som skulle ersättas kunde alla funktionella krav specificeras i förväg och planeras in i en fullständig aktivitetslista. Därmed
hade en vattenfallsmetod kunnat användas. Den agila metoden utnyttjades dock genom att
design och funktionalitet kunde bestämmas allt eftersom produkten blev klar. Dessutom
utnyttjades demonstrationerna till att prioritera vad som skulle arbetas med under nästkommande iteration.
I.6.1
Litteratursammanställning
I och med att agila metoder endast följer riktlinjer och värderingar istället för regler är det
svårt att definiera vad som är agilt eller inte. Den litteratur som hittades var en litteratursammanställning av en stor mängd artiklar. De fördelar och nackdelar som presenterades
i artikeln blir därmed mer trovärdiga. Man kan argumentera för att problemen med agila
metoder beror på att projektgruppen använder metoden fel snarare än att metoden i sig är
felaktig.
I.7
Slutsatser
Den största fördelen med agil kravhantering som kunde märkas i projektet var kunddemonstrationer efter varje iteration. Under dessa möten framkom väldigt mycket ny information
som gruppen annars inte skulle fått reda på.
Ytterligare en fördel med agil kravhantering är att man inte lägger så stor vikt vid att dokumentera kraven. Detta gör att man får mer tid över att lägga på något som är av värde för
kunden. Genom att lägga mindre tid på att specificera krav får man färre krav vilket är lättare
att underhålla och därmed minskar risken att kraven blir föråldrade. Utöver det minskas
risken att specificera något som ändå inte kommer vara med i slutprodukten.
Samtidigt som det är en stor fördel så kan det även vara en nackdel. Avsaknaden av fullständig dokumentation kan göra det svårt att underhålla systemet och det kan även vara
svårt för nya projektmedlemmar att sätta sig in i projektet.
En annan nackdel är att man på grund av ett kortare planeringsarbete kan göra felaktiga
arkitekturbeslut. Att åtgärda ett felaktigt arkitekturval kan vara väldigt tidskrävande och är
något man helst undviker.
Båda dessa nackdelar är mest påtagliga vid större projekt och kan vara rent försumbara för
mindre projekt. I och med att detta projekt var litet, hade en fast utvecklingsgrupp och hade
krav som ändrades lämpar sig en agil kravhantering bäst för ett liknande framtida projekt.
86
Litteratur
[1]
H. Kniberg, Scrum and XP from the Trenches, 1. utg. Lulu, 2007.
[2]
I. Jacobson, P.-W. Ng, P. E. McMahon, I. Spence och S. Lidman, The Essence of Software
Engineering: Applying the SEMAT Kernel, 1. utg. Addison-Wesley Professional, 2013.
[3]
Systems and software engineering — systems and software quality requirements and evaluation
(square) — system and software quality models, ISO/IEC 25010:2011, 2011.
[4]
M. Takada. (9 maj 2016). Single page apps in depth, URL: http : / /
singlepageappbook.com/index.html.
[5]
M. Arvola, Interaktionsdesign och UX: Om att skapa en god användarupplevelse. Studentlitteratur AB, 2014.
[6]
V. Jína, “Javascript test runner,” examensarb., Czech Technical University in Prague,
2013.
[7]
Karma. (19 april 2016). How it works, URL: https://karma-runner.github.io/
0.13/intro/how-it-works.html.
[8]
The jQuery Foundation. (10 maj 2016). Qunit, URL: http://qunitjs.com/.
[9]
V. Jína, M. DuVall, F. Ziegelmayer, S. Yalkabov och N. Cox. (10 maj 2016). Karma-qunit
readme, URL: https://github.com/karma-runner/karma-qunit.
[10]
W3C. (19 april 2016). The web standards model - html css and javascript, URL: https:
/ / www . w3 . org / community / webed / wiki / The _ web _ standards _ model_ _HTML_CSS_and_JavaScript.
[11]
——, (19 april 2016). Html and css, URL: https : / / www . w3 . org / standards /
webdesign/htmlcss.
[12]
AngularJS. (14 april 2016). What is angular? URL: https://docs.angularjs.org/
guide/introduction.
[13]
EmberJS. (14 april 2016). Ember.js - a framework for creating ambitious web applications, URL: http://emberjs.com/.
[14]
Mountain Goat Software. (13 juni 2016). User stories, URL: https : / / www .
mountaingoatsoftware.com/agile/user-stories.
[15]
I. Sommerville, Software engineering, 9. utg. Pearson, 2011.
[16]
International Scrum Institute. (13 juni 2016). Scrum roles - the scrum team, URL: http:
//www.scrum-institute.org/Scrum_Roles_The_Scrum_Team.php.
[17]
Trello Inc. (11 maj 2016). Trello, URL: https://trello.com/.
[18]
Slack. (21 april 2016). Slack: be less busy, URL: https://slack.com/.
87
Litteratur
[19]
Skype and/or Microsoft. (11 maj 2016). Skype | Free calls to friends and family, URL:
https://www.skype.com.
[20]
Google Inc. (11 maj 2016). Google Drive - molnlagring och säkerhetskopiering av foton,
dokument och mer, URL: https://www.google.se/drive/.
[21]
Axure. (21 april 2016). Prototypes, specifications and diagrams in one tool | axure software, URL: http://www.axure.com/.
[22]
Git project. (11 mars 2016). Git, URL: https://git-scm.com/.
[23]
V. Driessen. (11 maj 2016). A successful git branching model, URL: http://nvie.
com/posts/a-successful-git-branching-model/.
[24]
Google. (11 maj 2016). Google html/css style guide, URL: https : / / google .
github.io/styleguide/htmlcssguide.xml.
[25]
A. Whyte, B. Jervis, D. Pupius, E. Arvidsson, F. Schneider och R. Walker. (11 maj 2016).
Google javascript style guide, URL: https://google.github.io/styleguide/
javascriptguide.xml.
[26]
T. Ylonen och C. Lonvick, “The secure shell (ssh) protocol architecture,” RFC 4251, 2006.
URL: https://tools.ietf.org/html/rfc4251.
[27]
OpenBSD. (20 maj 2015). Openssh, URL: http://www.openssh.com/.
[28]
D. Flanagan, JavaScript - The Definitive Guide. O’Reilly, 2006.
[29]
R. L. Glass, Facts and Fallacies of Software Engineering. Addison-Wesley Professional,
2002.
[30]
R. D. Banker, S. M. Datar, C. F. Kemerer och D. Zweig, “Software complexity and maintenance costs,” Communications of the ACM 36.11, 1993.
[31]
P. Oman, J. Hagemeister och D. Ash, “A definition and taxonomy for software maintainability,” Software Engineering Test Laboratory, University of Idaho, Technical Report, 1991.
[32]
P. Oman och J. Hagemeister, “Metrics for assessing a software system’s maintainability,” i Software Maintenance, 1992. Proceerdings., Conference on, IEEE, 1992, s. 337–344.
[33]
J. Stilwell. (12 april 2016). Complexity-report readme, URL: https://github.com/
jared-stilwell/complexity-report.
[34]
——, (12 april 2016). Escomplex readme, URL: https : / / github . com / jared stilwell/escomplex.
[35]
D. Wahlin. (14 april 2016). Customermanagerstandard readme, URL: https : / /
github.com/DanWahlin/CustomerManagerStandard.
[36]
I. Minar. (14 april 2016). Foodme readme, URL: https://github.com/IgorMinar/
foodme.
[37]
C. Müller. (14 april 2016). Ember.js dashboard readme, URL: https://github.com/
pangratz/ember.js-dashboard.
[38]
C. Floyd, “A systematic look at prototyping,” i Approaches to Prototyping, R. Budde, K.
Kuhlenkamp, L. Mathiassen och H. Züllighoven, utg., 1984.
[39]
VentureGeeks. (25 maj 2016). Geekbot, URL: https://geekbot.io/.
[40]
M. Cohn. (11 maj 2016). Daily scrum meeting, URL: http : / / www .
mountaingoatsoftware.com/agile/scrum/daily-scrum.
[41]
T. Niinimaki, “Face-to-face, email and instant messaging in distributed agile software
development project,” IEEE, 2011.
[42]
M. Bless, Agile Processes in Software Engineering and Extreme Programming. Springer
Berlin Heidelberg, 2010, kap. Distributed Meetings in Distributed Teams, s. 251–260.
88
Litteratur
[43]
M. Luz, D. Gazineu och M. Teófilo, “Challenges on adopting scrum for distributed
teams in home office environments,” International Journal of Social, Behavioral, Educational, Economic, Business and Industrial Engineering Vol:3, No:11, 2009.
[44]
R. L. Daft och R. H. Lengel, “Organizational information requirement media richness
and structural design,” Managament Science Vol:32 No:5, 1986.
[45]
M. M. Müller, “Are reviews an alternative to pair programming?” Empirical Software
Engineering, vol. 9, nr 4, s. 335–351, 2004.
[46]
A. Cockburn och L. Williams, “The costs and benefits of pair programming,” Extreme
programming examined, s. 223–247, 2000.
[47]
S. McConnell, Code Complete, Second Edition. Microsoft Press, 2004, kap. 21.2 Pair Programming, s. 483–484.
[48]
Android Community. (8 maj 2016). Life of a patch | android open source project, URL:
https://source.android.com/source/life-of-a-patch.html.
[49]
J. Lindström. (8 maj 2016). Critic code review system, URL: https://www.openhub.
net/p/jensl-critic.
[50]
H. Saleh, JavaScript Unit Testing, 1. utg. Packt Publishing Ltd, 2013.
[51]
D. S. Janzen, “Software architecture improvement through test-driven development,”
2006.
[52]
K. Beck, Test-Driven Development By Example, 1. utg. Addison-Wesley Professional, 2002.
[53]
L. W. Boby George, “An initial investigation of test driven developent in industry,”
2003.
[54]
L. Crispin, “Driving software quality: how test-driven development impacts software
quality,” 2006.
[55]
Linux kernel project. (7 maj 2016). Submitting patches, URL: https://www.kernel.
org/doc/Documentation/SubmittingPatches.
[56]
GitHub. (11 maj 2016), URL: http://www.github.com.
[57]
The Apache Software Foundation. (21 maj 2016). Subversion, URL: https : / /
subversion.apache.org/.
[58]
S. Chacon och B. Straub, Pro Git, 2. utg. Apress, 2014.
[59]
E. Shihab, C. Bird och T. Zimmermann, “The effect of branching strategies on software
quality,” i Proceedings of the ACM-IEEE International Symposium on Empirical Software
Engineering and Measurement, 2012, s. 301–310. DOI: 10 . 1145 / 2372251 . 2372305.
URL: http://doi.acm.org/10.1145/2372251.2372305.
[60]
C. Walrad och D. Strom, “The importance of branching models in scm,” Computer, vol.
35, nr 9, s. 31–38, sept. 2002, ISSN: 0018-9162. DOI: 10.1109/MC.2002.1033025. URL:
http://dx.doi.org/10.1109/MC.2002.1033025.
[61]
C. Bird, P. C. Rigby, E. T. Barr, D. J. Hamilton, D. M. German, P. Devanbu, A. E. Housman och A. S. Lad, The promises and perils of mining git, 2010.
[62]
D. Galin, Software Quality Assurance from theory to implementation, 1. utg. Pearson, 2004.
[63]
S. McIntosh, Y. Kamei, B. Adams och A. E. Hassan, “The impact of code review coverage and code review participation on software quality: a case study of the qt, vtk, and
itk projects,” ICSE, 2014.
[64]
J. Rosenberg, “Some misconceptions about lines of code,” IEEE, 1997.
[65]
B. A. Myers och M. B. Rosson. (27 maj 2016). Survey on user interface programming,
URL: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
18.7394&rep=rep1&type=pdf.
89
Litteratur
[66]
usabilitypartners. (18 maj 2016). Iso-standarder, URL: http : / / www .
usabilitypartners.se/om-anvandbarhet/iso-standarder.
[67]
J. Nielsen. (24 maj 2016). Usability 101: introduction to usability, URL: https://www.
nngroup.com/articles/usability-101-introduction-to-usability/.
[68]
J. M. Spool. (17 maj 2016). 5 design decision styles. what’s yours? URL: https : / /
articles.uie.com/five_design_decision_styles/.
[69]
N. N. Group. (26 maj 2016). Turn user goals into task scenarios for usability testing,
URL: https://www.nngroup.com/articles/task-scenarios-usabilitytesting/.
[70]
J. Nielsen. (11 maj 2016). Usability inspection methods, URL: http://www.sigchi.
org/chi95/proceedings/tutors/jn_bdy.htm.
[71]
——, (13 maj 2016). How to conduct a heuristic evaluation, URL: https : / / www .
nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/.
[72]
——, (27 maj 2016). Standards inspections, URL: http://usability.jameshom.
com/stdinsp.htm.
[73]
I. Inayat, S. S. Salim, S. Marczak, M. Daneva och S. Shamshirband, “A systematic literature review on agile requirements engineering practices and challenges,” 2014.
90
Bilaga 1 Sammanställning av tidigare
erfarenheter
Arbetsuppgifter & planering
• Om alla uppgifter som planerats in under en period färdigställs tidigare än planerat,
fortsätt med nästa uppgift. Vänta inte på att nästa arbetsperiod ska börja.
• Ha en jämn arbetsbelastning.
• Avlasta “experterna” – ge enkla uppgifter till lägre presterande personer.
• Tidplanering är viktigt, likaså prioritetsordning av uppgifter.
• Projektplanen var väldigt svår att uppskatta men det var förväntat. Viktigt att hela
tiden ha ”nästa” steg klart för sig.
Arbetsmetod
• Scrum/Kanban board där man kan se status på tasks vill jag gärna göra igen.
• Ta initiativ till att ta lediga tasks om man har tid över.
• Parprogrammering gillar jag.
• I förra projektet var vi fyra stycken som delade upp oss två och två. Det gick väldigt
bra, men man hade väldigt dålig koll på vad det andra paret höll på med. Om man
kanske kan göra code review på varandras kod eller nåt sånt så man blir lite mer insatt,
för vi hade behövt lite kodgranskning tror jag.
Utbildning
• Lägg mer tid på utbildning, det vill säga läs på mer innan design och kodning görs.
• Bli bättre på att läsa igenom datablad och inte vara rädd att tidrapportera denna typ av
utbildning.
• Kodstugor/workshops gör småfrågor lättare.
91
Gruppdynamik
• Ha inte hemliga kommunikationsvägar (har orsakat att en medlem känt sig utstängd
då hen inte fått info om event).
• När problem uppstår, hantera detta innan det blir konflikt.
• Fira framgångar! Bli inte tyst när allt går bra.
• Kommunikation är viktigt, däri ingår att man ska kunna ta bra och dålig kritik från en
gruppmedlem.
• Kommunikationen har varit bra, mycket tack vare att vi kände varandra bra sedan tidigare.
• I och med att vi är en slumpad grupp tror jag att vi har en bredare kompetens än en
självvald grupp.
• Det är svårt att vara projektledare över sina vänner men samtidigt kan det nog bli fler
konflikter i en grupp där man är mer olika.
Projektorganisation
• Ge inte områdesansvariga för mycket makt över sitt område.
• Skriv gruppkontrakt!
• Gruppkontraktet borde innehålla hur information om möten och liknande kommuniceras inom gruppen.
• Kom överens om konsekvenser om en person kommer sent till ett avtalat möte, alternativt inte dyker upp alls.
• En bra överenskommelse inom gruppen om enklare frågor som förseningar och arbetstid visade sig vara mycket givande, så länge alla är överens.
• Mer formalitet önskas, vi känner inte varandra lika bra nu och är i en större grupp än
tidigare.
Tidfördelning
• Alla ska kunna redogöra för det antal timmar de har arbetat (när och vad och inte bara
totala antalet timmar). Helst att gruppen går igenom varje vecka vad varje enskild
person har gjort, så att alla har en övergripande idé om hur långt man faktiskt har
kommit i arbetet.
• Vi var dåliga på att jobba på i början när vi hade tid, så det blev många helger och nätter
på slutet.
• Vi jobbade mycket men på dagtid, vilket fungerade bra.
• Vi lade ungefär lika mycket tid på projektet varje vecka vilket gjorde att det inte kändes
så tungt.
• Jobba mycket även tidigt i projektet.
• Alla gruppmedlemmar la ner lika mycket tid men vissa bidrog med betydligt mycket
mer än andra. Detta blir förhoppningsvis bättre med ett bredare projekt.
• Lägg tid på dokumentation under projektets gång. På så vis slipper man hetsa ihop
något i slutet.
92
Utveckling
• Kom överens om att all kod som skrivs ska finnas tillgänglig för de andra.
• Det ska helst inte finnas kod som bara en person har skrivit och som endast hen förstår,
de andra ska inte vara låsta bara för att en person inte har dykt upp...
• Vi hade ingen versionshantering av koden utan den låg lite utspridd på ett par personers privata konton, vilket inte fungerade så bra.
• De olika delarna testades inte tillräckligt mycket innan man ansåg att man var klar med
dem. Detta ledde till att när det uppstod fel kunde man aldrig isolera felet eftersom
man inte var helt säker på att något fungerade som de skulle.
• Prototypning är bra.
• Experimentera med features och sätt att jobba för att kunna uppleva för-/nackdelar.
• Använd en gemensam branching workflow (e.g git).
• Genomför code reviews (i någon mån).
• Git var bra men commit-meddelandena blir lätt väldigt dåliga utan regler för det.
• Jag ser gärna att vi inte krånglar till lösningar och vågar bryta mot projektplanen ifall
det finns bättre alternativ vi inte tänkt på.
Övrigt
• En sak som funkade väldigt dåligt var att vi inte direkt såg till att alla hade koll på
hårdvaran och hur man jobbar med den. Det gjorde att vi vara beroende av att vissa
specifika personer var närvarande för att vi skulle kunna jobba framåt.
• Tänk med sunt förnuft.
• Man kanske behöver ha lite tid för retrospection också så man kan ta upp vad som
fungerar dåligt. Det verkar vara ovanligt bland studenter men ganska vanligt hos företagen.
93
Bilaga 2 Sammanställning av
iterationsutvärderingar
2.1
Förstudie
2.1.1
Fullständig sammanställning
Rollfördelning, hur känner du inför din roll och de andras roller?
Bra
• Alla verkar trivas i sina roller. (2 st.)
• Rollfördelningen gick väldigt smidigt. (2 st.)
• Alla sköter sina rollspecifika uppgifter. (5 st.)
• Väldigt bekväm (3 st.)
• Alla har olika arbetsbelastning i början men det är ju bara naturligt.
• Jag har inte så mycket kunskap inom just programmering och upplägget som krävs så
det känns bra att inte behöva ha ansvar över något sådant.
• Hjälper till så fort fråga uppstår! (hjälpt mig sätta upp Git t ex)
• Är mycket nöjd med rollerna. Det känns bra.
• Bra! Min roll tycker jag passar, kunde säkert tagit någon annan men jag tyckte om
alternativen likvärdigt.
• Mycket nöjd med min roll, jag trivs som ledare.
Kan bli bättre
• Vice-roller
• Jag vill ha mer av en ledarroll.
• Det känns lite som att testplanen och kvalitetsplanen mer är till för en inlämning än för
oss själva att använda.
• Utbildningar kunde varit mer strukturerade och genomtänkta, tidsbegränsade. Men i
allmänhet mycket uppskattade! (gäller främst Git).
94
2.1. Förstudie
• Mer samarbete mellan vissa roller.
• Jag är fortfarande lite för snurrig för att kunna hålla alla trådar ordentligt.
Möten, hur har de fungerat och har du kunnat vara med så mycket som du velat?
Bra
• Måenderundor <3 (4 st.) – bidrar till personlighet och sammanhållning inom gruppen.
• Bra med ett protokoll. (2 st.)
• Bra närvaro.
• Trevligt, dagordning -> ej spårar off topic.
• Har varit för det mesta väldigt effektiva och TL är bra på att flika in när vi börjar bli off
topic eller hoppar mellan mötespunkter.
• Bra att ha ett protokoll upplagt för möten som kommer, så att man vet vad man ska
förvänta sig.
• Vi har högt till tak. (2 st.)
• Roliga utsvävningar.
• Inte många förseningar.
• Tycker det flyter på bra.
• Alla får chans att prata, alla vågar säga vad de tycker, tror ingen känner sig överkörd.
• Bra mängd möten.
• Bra med pauser.
• Bra och naturlig schemaläggning.
• Vi är effektiva som tusan.
Kan bli bättre
• Vi har många möten så vi hinner inte med så mycket annat.
• Ha distansarbete.
• Många sena ankomster. (2 st.)
• Det har varit lite mycket off-topic nu.
• Mötena drar ofta över på tiden så det vore bra med ett tydligare avslut.
• Har inte varit med så mycket som jag har velat eftersom jag har haft problem med bilen.
• Det känns ibland en aning ineffektivt då vi pratar om samma ämne under en, enligt
mig, lite för lång stund.
• Måenderundorna känns lite onödiga.
• Har hänt några gånger att jag inte kunnat närvara vilket förstås är tråkigt. Har dock
inte upplevt att detta varit ett problem för min del, men kräver ibland lite extra tid av
någon annan för att ge mig en recap.
95
2.1. Förstudie
• Ibland hamnar vi lite väl off topic, men det verkar som det blir bättre. Varierar lite från
gång till gång också.
• Lite mer koll på tiden, sätta streck i debatten, kanske planera hur lång tid mötespunkter
ska ta för att hinna med allt. (2 st.)
• Bli bättre på att boka lokaler i tid, och sätta upp dagordningen i förväg (funkade bättre
i början för min del).
• Blir ofta tidspressat.
• Missade kodstuga igår, vilket var synd.
Verktyg (Trello, Drive, Git, Slack)
Bra
• Slack är bra. (4 st.)
• Fungerar överlag bra. Skönt att ha olika verktyg till olika saker.
• Drive fungerar bra. (4 st.)
• Slack är en lifesaver med notiser.
• Trello är OK. (2 st.)
• Git är kul.
• Skönt med postspecifika mappen på driven.
• Älskar slack och slackbots.
• Bra att lära sig git på riktigt.
• Översikten på Trello är nice. Svårt att hantera större aktiviteter.
• Drive är ett enkelt sätt att se vad andra gjort och dela med sig av filer. Nice att flera kan
arbeta i ett dokument samtidigt!
• Slack är nice för att man kan ha många kanaler, och även chatta individuellt. (2 st.)
• Git har fungerat övervägande bra. Trello återstår att se.
• Bra med drive och att vi har så mycket material där.
• Git är bäst, roligt med vår planerade branching-strategi.
• Slack är otroligt bra med schemaläggning av möten.
Kan bli bättre
• Ordningen på drive. (2 st.)
• Har inte testat Git än, borde göra det.
• Det är lite svårt att hitta i docs ibland.
• Trello.
• Tidskrävande att fylla i tidrapporteringen i Trello. Kan givetvis underlättas om jag ser
till att fylla i direkt istället för allt i slutet av veckan. . .
96
2.1. Förstudie
• Drygt att snygga till dokumenten hämtade från Drive, blir nog enklare när LaTex börjar
användas?
• Ibland lite rörigt för att det är så många kanaler i slack. . .
• Slacks pushnotifikationer är lite instabila, det är dock inget vi kan göra något åt.
• Tycker formatet för tidrapportering är liiite bökigt, men man kommer nog in i det.
• Jag, personligen, borde ge trello lite mer chans.
• Upprensning i Drive behövs, där börjar bli kaos.
• Trello är inte fullt i bruk än, git har jag inte börjat med.
Samarbetet i gruppen
Bra
• Vi har inte missat någon deadline.
• Får bra respons om man ber om hjälp.
• Har funkat jättebra med de jag kört 1 on 1 med.
• Jag tycker att det har fungerat bra. (3 st.)
• Alla hjälper till.
• Tycker vi varit bra på att fördela ansvar bland gruppmedlemmar.
• Skönt att folk vågar säga vad de tycker. Alla gör sitt jobb, känner att man kan samarbeta
med alla och att det inte är någon barriär att fråga om hjälp.
Kan bli bättre
• Återstår att se när vi börjar parprogrammera.
• Vi sitter ofta en och en.
• När utbildningar ska hållas av två olika personer inom en utsatt klump tid kanske de
borde pratat ihop sig om hur länge respektive del skulle ta. (Dumt att missa Fredriks
grejer, hade behövts!)
Stämning i gruppen
Bra
• Mycket bra stämning. Alla är trevliga och tillmötesgående.
• Bra! Gör att det går off topic ibland, vilket är nice.
• Vi har högt till tak.
• Skön och avslappnad stämning.
• Känns bra att vi kan prata med varandra om hur vi mår och vara öppna och ärliga.
• Bra stämning, inget att klaga på!
• Trevlig, prestigelös, öppen, inkluderande.
• Väldigt fin. Ingen bitterhet vad jag känner av. Inga onödiga kommentarer.
97
2.1. Förstudie
Kan bli bättre
• Vi/jag behöver prata mer.
• Tänk på språket och vad man skämtar om, jag tycker att även om vi känner varandra
och så bör man undvika det människor kan ta illa upp, även utanför gruppen.
Kommunikation mellan gruppmedlemmar
Bra
• Vi är öppna. Ser inget som hindrar god kommunikation just nu.
• Alla svarar snabbt på slack och det känns som att alla säger vad de tycker.
• Bra, mycket tack vare slack. (2 st.)
• Verkar ha fungerat bra än så länge. . .
• Supersmidigt med mötesprotokollen, plus för välskrivna sådana. Har haft väldigt lätt
att skaffa mig en överblick över vad som gjort den veckan jag varit borta nu.
• Bra att folk skriver om de är sena, var de sitter och arbetar. Bra att man kan fråga utan
att känna sig dum. Bra att teamleader och andra säger till när det blir för off topic.
• Sker fint och trevligt, mycket reaktande i slack!
• Slack fungerar hur bra som helst, möten också.
Kan bli bättre
• Jag har inte snackat så mycket med någon ännu så det återstår att se.
• Vi kan behöva en kanal för att bara skriva av oss.
• Lite dumt att TL missade att vidarebefordra mail om seminariet, men lätt hänt!
• Off topic-grejer. Ta ej upp sånt som inte rör en stor del av de på mötena, ha mindre
möten i så fall (mer som tips).
• Fortfarande ovan att chatta med folk -> svårt att läsa humör i meddelanden pga skillnad
i smiley-användande.
Tidrapportering
Bra
• Smidigt att rapportera i trello. (2 st.)
• I största allmänhet så är det bra att den skickas in på måndagar. Rebecka är också bra
på att varna inför deadline.
• Relativt enkelt.
• Skönt att ha allt på samma ställe i Trello. (2 st.)
• Bra att alla rapporterar vad de gör så man får insyn.
• Nice att jag fick öva på Python genom att skriva parsern.
Kan bli bättre
• Kategorikorten är onödiga.
98
2.1. Förstudie
• Skulle vara bra att se hur många timmar man har arbetat under veckan. (3 st.)
• Måste rapportera precis när man har gjort nåt, jag glömmer ofta.
• Behövs ett sätt att kunna se en summering för veckan. Nu är det svårt att se om man
har missat något. (2 st.)
• Funderar om varje aktivitet ska få ett aktivitetsnummer för att underlätta rapporteringen?
• Min egen tidrapportering, borde göra mer kontinuerligt, inte i sista stund.
• Känns som att vi lika gärna kan göra det i excel.
Handledningsmöten
Bra
• Lunchmöteprincip är bra.
• Handledaren är engagerad och svarar på många frågor.
• Väldigt bra i början när vi inte visste så mycket.
• Nöjd med handledaren. (3 st.)
• Bra att handledaren sitter med under våra vanliga möten och blir som en del av gruppen. Flikar in med info/kommentarer när det behövs.
• Tar upp relevanta frågor etc.
• Går hyfsat smidigt att boka in. Adrian är punktlig och trevlig, och svarar otroligt snabbt
(på mail).
Kan bli bättre
• Lite onödiga.
• Vill helst att de inte ska ligga på lunchen.
• Får inte jättemycket information av handledaren. Kanske eftersom han inte fått info av
examinatorn?
• Fortfarande inte helt klart om jag eller handledaren leder mötena, lätt för mig att gå in
i maktkamp.
2.1.2
Förbättringsförslag
Rollfördelning
• Vice-roller.
• Planera workshops/utbildningar bättre så de håller tiden.
• Utvecklingsledaren (Eric H) ska ta mer plats som ledare för utvecklingsarbetet.
• Eventuell workshop/genomgång om hans vision för systemet.
99
2.2. Iteration 1
Möten
• Lite väl mycket off topic-prat då vi blivit så bekväma med varandra.
• Drar ofta över tiden, ha tydligare avslut.
• Helst inte ha handledarmöten under luncher.
• Fylla i mötesprotokoll i förväg med dagordningspunkter.
• Boka salar i tid (Rebecka).
• Avsätta tid per mötespunkt.
• Mötena kommer oftast igång sent.
Verktyg (Trello, Drive, git, Slack)
• Trello funkar inte bra för tidrapportering, vi byter till spreadsheet i Drive från vecka 8.
• Det är kaos i Drive och svårt att hitta. Kim (dokument) och Robert (konfiguration)
städar upp.
• Oklart när man ska flytta tasks mellan listor i Trello.
Gruppen
• Jargongen under mötena har gått lite väl långt. Vi ska försöka hålla en något mer professionell nivå.
• Mer one-on-one tid mellan gruppmedlemmar önskas, löses av parprogrammerandet.
2.2
Iteration 1
2.2.1
Fullständig sammanställning
Utvecklingsarbetet, hur har det gått att kicka igång?
Bra
• Mycket har blivit kodat.
• Tycker det funkat bra med reviewsystemet vi använder nu. (2 st.)
• När man väl började gick det väldigt lätt.
• Äntligen få börja koda.
• Går snabbt att göra saker.
• Har lärt mig mycket. (3 st.)
• Har gått automatiskt! Har någon haft tid har de tagit uppgifter självmant och
självgående! *en tumme upp*
• Vi har vetat vad vi inte vet och kunnat fixa/lära sig.
• Backloggen är tom!
• Mycket bra med utbildningarna plus tips och idéer på IDEer.
• Alla har jobbat på och plöjt igenom det som fanns i backlogen.
100
2.2. Iteration 1
• Kul med nytt språk.
• Att vi har delat upp allting i aktiviteter känns det lätt att komma igång med en uppgift.
Det finns alltid någonting att göra.
Kan bli bättre
• Jag känner att jag ligger efter stort i allt vad gäller koden och kodande.
• Arbetet var lite spretigt i början, men det rättades till efter lite kommunikation och
skapandet av en gemensam grund att stå på.
• Namngivning.
• Det har gått lite trögt pga mycket overhead i kursen såsom seminarier och dylikt.
• Skulle vilja göra mer utvecklingsarbete.
• Borde gjort GUI-skelett tidigare.
• Hade lite överlapp.
• Glöm inte att stå upp! Tänk på hållningen.
• Det är lite spretigt och går lite långsamt.
• Har haft dependencies på andra delar (t ex GUI-framework) som låg olöst ett tag, att
kommunicera dessa dependecies vore nice.
• Lite svårt att veta hur vi skulle börja. GUI-gruppen verkar ha haft lite missförstånd då
huvudgränssnittet inte påbörjades förrän sent.
• Känns som att man inte riktigt har kommit igång än. . .
• I början var GUI-delen väldigt oklar. Vi hade inget gemensamt framework och allt var
lite kaos. Det var oklart vem som hade ansvar för vad. Under iteration 2 får vi inte låta
sådana viktiga och centrala saker bara ligga i luften.
Parprogrammering/ensamt arbetande/arbete i grupp
Bra
• Stort fan av parprogrammering, utifrån det lilla jag gjort.
• Det går mycket snabbare när man är två.
• Väldigt lärorikt.
• Ha koll på mycket features som finns så man kan googla bra.
• Tillgängligt.
• Roligt att parporgrammera, bra för teambildingen.
• Har gått bra :)
• Feedback är nice
• Grupp är nice
• Gick hyfsat bra, svårare när man har funderingar och sitter ensam i övrigt tycker jag att
arbetet har flutit på bra.
101
2.2. Iteration 1
• Det verkar ha flutit på bra hos folk, bra med två hjärnor :)
• Fungerar jättebra med kodstugor, hade gärna fått vara oftare.
• Tycker att det är bra att man är ganska fri i hur man vill arbeta.
Kan bli bättre
• Jag har inte parprogrammerat så mycket, eftersom jag gjort mycket med Kristoffer.
• Svårt att hitta tider då båda kan.
• Mer kodstugor.
• Mer flexibla par?
• Ibland blir man lite låst när jag känner för att jobba men inte vill träffa folk ;)
• Vi har haft personer inblandade i 3-4 olika saker samtidigt som parjobbat med personerna med bara 1 uppgift, men ska jobba lika många timmar. Det funkar ej =) ena
personen jobbar ensam (så: par efter mängd “fria timmar” eller minska antalet “olika
jobb” vi har inom gruppen)
• Lite jobbigt med parprogrammering ibland. Har hänt att den ena jobbar hemifrån ändå
bara för att testa runt lite, som den andra sen måste sätta sig in i.
• Har gått väldigt långsamt då man enbart kört på en dator - är kanske bättre med varsin.
• Jag upplever inte att jag tillfört särskilt mycket.
• Jag måste bli bättre på att arbeta med andra och programmera med andra. Jag har
en tendens att sätta mig själv med musik och arbeta själv istället för att skriva i slackkanalen.
Utvecklingsmiljöer (WebStorm)
Bra
• Helt okej.
• Nöjd med WebStorm, smidigt att använda. (2 st.)
• Fräscht
• Bra filhantering
• Inga bråk med projektfiler.
• Todo/Fixme
• Karma (2 st.)
• Den gör jobbet!
• Inspections
• Egen webbserver
• WebStorm fungerar ganska bra, brackets är helt åt skogen dock.
• Lätt att använda. Skönt att det fungerar så bra med Git.
• Riktigt bra! Tar lite tid att komma igång med allt men nu är det super!
102
2.2. Iteration 1
Kan bli bättre
• Mycket jag inte känner till som skulle kunna underlätta arbetet, förmodligen
• Inspections (finns bugs (t ex unresolved var))
• Koda WebStorm bättre
Versionhantering
Bra
• Nice att äntligen få använda det så jag lär mig.
• Det fungerar:)
• Robert är bra på att svara.
• Lite rädd att göra saker.
• Guiden som finns.
• Branching strategi (3 st.)
• Alla frågor och funderingar jag haft har klarats ut, Robert har koll.
• Skönt med rapporten i git. Latex <3
• Ja! Inga major mishaps =D
• Smidigt att kunna gå tillbaka, annars inget.
• Börjar få grepp om Git nu & känner mig mer självsäker.
• Git är ju rätt svårt men jag tycker att vi har en riktigt bra struktur.
Kan bli bättre
• Lite rädd att göra saker
• Mer strikta regler?
• Local branching (men det behövs inte, det är en personal workflow-grej), testa gärna
mer!
• Har någon läst git-primern?
• Kristoffers git-problem (men det har löst sig nu)
• Kom till mig direkt! Don’t worry
• Fortfarande lite bökigt ibland. Då är det tur att vi har Robert =)
• Jag kan bli bättre på Git, har gjort fel och slitit mitt hår flera gånger nu :)
103
2.2. Iteration 1
Verktyg (Trello, nya tidrapporteringen)
Bra
• Smidigt att se projektets status i Trello.
• Gillar nya tidrapporteringen. (8 st.)
• Nya tidrapporteringen är smidig. (2 st.)
• Trello nice för sprintplan.
• Trello har fungerat relativt bra.
• Tidrapporterar nu i Drive - bättre översikt & snabbare!
• Med nya tidrapporteringen slipper använda något annat verktyg vid sidan av (som till
exempel toggl).
Kan bli bättre
• Att uppdatera Trello då man utfört arbete.
• Fortfarande lite oklart när man ska flytta kort.
• Känns inte som man tittar på trello jättemycket. (2 st.)
• Lätt att glömma bort Trello, inte helt integrerat i utvecklingsprocessen.
• Issue tracking (används knappt?) samt “prioritetsröstning” på issues.
• Reviewern flyttar kortet
• Jag borde fylla i tidigare än söndag kväll.
• Använder alla Trello? Känns som att man är lite rädd för att kryssa i checklistorna &
flytta runt korten.
• Jag känner mig lite osäker i trello. Till exempel nu började jag med “Putsa till GUI”kortet, men gör ju bara små uppgifter. Vet inte om jag ska flytta kortet och sätta det på
mig. Eller om jag borde gör nya underkort/listor och sen berätta vad jag tar. Just det
kortet känns för stort.
Testning, hur har det fungerat?
Bra
• Jag ska kalla till möte.
• Smidigt med QUnit/Karma. Känner sig säkrare när man gör förändringar.
• Karma verkar vara bra men har inte använt det så mycket än.
• Smidigt med karma.
• Lätt installation (även för windows).
• Folk verkar ha lyckats göra en hel del enhetstester utan särskilt mycket utbildning.
• Integrations var nice!
• Både och, WebStorm->view in firefox uppdaterar ej om man har en annan sida öppen
redan.
104
2.2. Iteration 1
• Erics video om att komma igång var toppen!
• Enhetstestningen i WebStorm tycker jag fungerar riktigt bra, skönt att det körs automatiskt.
Kan bli bättre
• Kanske börja dela upp testfallen i fler filer.
• Hade en bugg där karma körde gamla test när jag klickade på run, var tvungen att
stänga fönstret den öppnar.
• Nästa iteration bör alla vara med och integratiostesta. Nu blev det väldigt hafsigt.
• Tycker nivån på unit-testar på är lite off, testerna i sig är bra, men tror att vi borde testa
på en högre nivå (t ex med manuellt skapta html-sidor).
• Har inte hunnit testa. (2 st.)
• Fortfarande osäker på hur testningar faktiskt går till. (2 st.)
Kommunikation mellan gruppmedlemmar
Bra
• Funkar fortfarande bra.
• Tycker det fungerar bra i slack. (4 st.)
• Vi har högt i tak.
• Öppet! Ärligt! Härligt!
• Verkar fungera bra, iaf från mitt perspektiv.
• Bra med Daily Scrums eftersom man då får en inblick i vad alla gör!
• Alla är fortfarande aktiva och hjälpsamma, väldigt bra!
• Tillgänglighet.
Kan bli bättre
• Märks i slack att det är tenta-p nu, inte så responsivt.
• Ev. koordinering av feature-utveckling.
• Mer kodstugor.
• Tror det finns mer frågor att diskutera än vad som hinns med på AFK-mötena, men iofs
är det nog bra att det är lite begränsat.
• Kommunicera “prioriteter” och dependencies (mer utveckling).
• Statusrapporter.
• Slack skickar ej notiser ibland. (2 st.)
• Ibland känns det som om vi borde ha fler kanaler på slack. Typ en “Code_help” som
man kan posta lite kod man tycker är knepig och behöver hjälp med eller nått sånt. En
“Kandidatrapport” där man kan skriva om nått är oklart i rapporten eller LaTeX. “Git”
för frågor om git.
• Jag drar mig lite från att skriva i “General” för då känns det som om jag tvingar alla att
läsa.
105
2.2. Iteration 1
Stämning i gruppen
Bra
• Toppenbra.
• Mycket trevligt (2 st.)
• Vi har lämnat smekmånaden och börjat på riktigt, vilket är bra!
• Bra, mycket bra grupp att jobba i! :)
• Fortfarande smekmånad! Alla verkar glada och trevliga mot varandra & om varandras
arbete.
• Riktigt härlig och bra stämning!
• Vi bryr oss :)
Kan bli bättre
• Mer kodstugor.
• Göra något kul igen?
• Skulle vara kul med kick-off 2. (2 st.)
Följer vi projektplanen?
Bra
• Så vitt jag vet. (2 st.)
• Jag tror den speglar verkligheten rätt bra.
• När vi kollade senast så har vi gjort vissa saker snabbare än tänkt, men i det stora hela
så följer vi planen.
• Än så länge följs den, med undantag från några datum för dokumentation (framflyttade
inom grupp/fått OK av handledare).
• Ja det tycker jag att vi gör! (2 st.)
Kan bli bättre
• Jag har ingen koll på projektplanen just nu.
• Experimentera mera? :P
• Kanske tåls att läsas igenom i början av varje iteration för att kolla att vi inte
avviker/uppdaterar vid behov.
• Jag har väldigt dålig koll på vad som står i projektplanen. Borde uppdatera mig på
dokumenten vi gjorde under förstudien. Detta kanske är någon individuellt dock.
106
2.2. Iteration 1
Följer vi kravspecifikationen?
Bra
• Ingen aning faktiskt.
• Några krav har vi allt bockat av. 50 % kvar dock.
• Tasks i Trello är kopplade till kravspecen. (2 st.)
• Sprint planning “löser” detta till stor del
• Ja, kravspecen har vi följt hittills, det gäller bara att få med alla punkter tillslut.
• Vad jag vet följer vi den!
• Ja det tycker jag att vi gör!
Kan bli bättre
• Personligen har jag inte gått igenom några krav och verifierat att vi faktiskt uppfyller
dem, det borde jag göra.
• Utseendet är ju bara i något första utkast-stadie men färgerna stämmer inte överens
med att inte försvåra för färgblinda.
• Råkade göra ett krav 2?
• Kanske blir svårare när vi börjar arbeta med mindre viktiga krav.
• Jag själv har inte läst kravspec. när jag ställde frågan “behövs denna feature”, det borde
jag gjort, alt. fråga gruppen/Victor.
• Jag har väldigt dålig koll på vad som står i kravspecifikationen. Borde uppdatera mig
på dokumenten vi gjorde under förstudien. Detta kanske är någon individuellt dock.
Uppdatering av relevanta dokument
Bra
• Har fungerat bra. (2 st.)
• Bra med reviews.
• Nu skulle ju alla dokument in i halvtid så därför är de uppdaterade.
• Bra, Driven är smidig, hade inte valt annat verktyg för det.
• Har varit svårt att hitta ibland, men det är rensat nu (Y)
• Projektplan & kravspec har uppdaterats några gånger.
• Tror att de dokument som behövts uppdateras har blivit det. (2 st.)
Kan bli bättre
• Ligger gamla riktlinjer och dräller i Drive, mitt fel :(
• Vi ska nog inte lägga för mycket tid på det dock.
• Kommer inte på att göra det direkt, känns lite jobbigt att göra.
• Har ingen koll på dokumenten :)
• Vet alla om de ändringar som gjorts? (Blir så himla mycket läsande, tråkigt. . . )
107
2.2. Iteration 1
Utbildning WebStorm/webbutveckling
Bra
• Den privata genomgång jag fick med Fredrik var väldigt givande.
• Man kan ju alltid titta på koden som finns alternativt lära sig på egen hand.
• Fredriks utbildning var bra. (3 st.)
• Fick en överblick över vad som skulle göras. (2 st.)
• Fick överblick av vad som WebStorm har att erbjuda.
• Learning by doing!
• Visade kod!
• Diskussion om arkitektur och utvecklingsideologiska ting.
• Bra, det hjälpte mycket i början med ett exempel att kolla på.
• Bra att vi diskuterat kodstandard.
Kan bli bättre
• Kunde hållts tidigare.
Utbildning Git
Bra
• Nöjd med utbildningen.
• Den vi hade var lite lång men samtidigt bra.
• Bra att man alltid kan be Robert om hjälp. (2 st.)
• Väldigt grundlig, mycket bra information. (3 st.)
• Fint visualiserad med branches/tid.
• Gick igenom kommandon.
• Gick igenom mycket så man vet vad som man inte kan.
• Känner att jag kan git tillräckligt bra för att lösa de flesta problemen.
• Bra att se hur det fungerar med olika branches & vad som händer vid ex. merge/rebase
etc.
• Vi har satt upp en bra struktur.
Kan bli bättre
• Bra, lite väl mycket utsvävningar ibland.
• Drog ut lite på tiden. (3 st.)
• Visa kommandon (dvs t ex med projektor?).
• En fil med kommandon + info, en wiki för oss helt enkelt. Vore nice.
• Inte särskilt nybörjarvänligt. Dokumentet med vanliga kommandon förvirrar nästan
mer än den hjälper. . .
• Det var lite krångligt att gå igenom kommandon på tavlan. I Git kan man ju göra
samma sak på flera sätt och vi satte ingen riktig standard. Nu brukar jag bara googla
saker och ta det som kommer upp. Kanske inte spelar någon större roll.
108
2.2. Iteration 1
Utbildning Scrum
Bra
• Kort och koncis. (2 st.)
• Alla vet väl redan vad scrum är.
• Bra tempo, gick igenom relevanta fakta. (2 st.)
• Utbildningen var bra, vår Scrum-metodik känns rätt så förnuftig och lätt att tillämpa.
(2 st.)
• Bra, scrum har vi läst om i teorin så alla kunde väl det mesta om det redan innan.
Men en uppfräschare är ej fel, plus att vår egen modifikation av scrum blev defininerat
ordentligt var bra.
• Det var en riktigt bra genomgång. Tycker att jag fick allt på det klara.
Kan bli bättre
• Rummet var så litet (ADA) att det blev jobbigt varmt och svettigt.
• Hade kanske varit intressant med lite mer ingående utbildning. Dock inte nödvändigt
för vårt arbete =)
2.2.2
Förbättringsförslag
Utvecklingsarbetet, hur har det gått att kicka igång?
• Vi ska prata mer med varandra när vi utvecklar features som är lika varandra, för att
undvika dubbelarbete och se till att alla delar fungerar ihop.
• Saker och beslut som rör hela gruppen ska kommuniceras ut till hela gruppen.
• Olika dependencies mellan tasks ska kommuniceras bättre så inte arbetet fastnar i olika
flaskhalsar.
• Överlag mer kommunikation! Till exempel mötespunkten “Rapporter och meddelanden” ska användas bättre.
• Vi ska bli bättre på att tillsätta kommittéer som kan utreda frågor och ta beslut, i de fall
inte hela gruppen behöver vara inblandad, men det inte är lämpligt att någon gör det
själv.
Verktyg (Trello, nya tidrapporteringen)
• Den som gör reviewen flyttar kortet i Trello-listorna.
Testning, hur har det fungerat?
• Nästa iteration ska hela gruppen vara med och utföra integrationstestning (i början av
sista veckan).
Stämning i gruppen
• Vi ska ha en till kick-off nu när vi känner varandra bättre!
Följer vi kravspecifikationen?
• Victor (analysansvarig) ser till att systemet följer kravspecifikationen.
109
2.3. Iteration 2
Uppdatering av relevanta dokument
• Drive ska rensas på gamla utdaterade riktlinjer (Rebecka fixar).
2.3
Iteration 2
2.3.1
Fullständig sammanställning
Testning, hur har det fungerat?
Bra
• Integrationstestmötet var kul. (5 st.)
• Integrationstestmötet bra sätt att samla issues. (4 st.)
• Bra att alla gjorde rapporten tillsammans på plats.
• Enhetstest: smidigt.
• Alla har varit med och deltagit. (2 st.)
Kan bli bättre
• Svårt att testa funktionalitet på ett systematiskt sätt annat än logic.js
• Har inte testat något annat, vilket är tråkigt.
• Man kan inte enhetsesta all kod, borde vara tydliga vad man ska testa och inte testa.
• Enhetstest: skriver lite för att man måste.
• Det är tidskrävande att enhetstesta.
• Testa i Southfork!!!
• Det var läskigt att göra så för första gången.
Prioriterar vi rätt saker att implementera?
Bra
• Bra att vi avstämt med kravspecen, känns som att vi gör det.
• Känns som att vi har kommit framåt fort och betat av backlogen.
• Jag har inte haft några beroenden som behövts väntas på.
• Det grafiska ges tid att vänjas in i.
• Alla krav 1 är uppfyllda och kunden nöjd. (2 st.)
• Vi har inga konstiga features som t ex snurrande turingmaskiner.
• Jag tror det.
• Ja det tycker jag, allt hinns ju med utan problem.
• Ja det skulle jag vilja påstå. Vi följer kravspecen, och vi implementerade funktionaliteten först, och sedan det grafiska, vilket är logiskt.
Kan bli bättre
• Fundera över prio mellan refaktorering och kand.rapport senare.
• Har börjat implementera annat än som finns i kravspec - problem?
• Borde ha bättre koll på kravspec när man letar uppgifter.
110
2.3. Iteration 2
Kommunikation mellan gruppmedlemmar
Bra
• Tycker slack och de möten vi har funkar bra. (2 st.)
• Öppen & ärlig. Snabb återkoppling över slack. Ofta bra diskussion under kodstugor &
möten.
• Slack blir bara bättre och bättre!
• Som tidigare utvärderingar så funkar allt bra.
• Slack & högt till tak!
• Glatt och trevligt. (2 st.)
Kan bli bättre
• #reviewrequest2016 #RIP
• Deadlines för återkoppling på slack?
• Stökigt i reviewrequest.
• Slack fungerar sådär ibland, notiser kommer lite när slack känner för det.
Stämning i gruppen
Bra
• Allt.
• Lärt känna varandra bättre & alla är engagerade & intresserade av varandras arbete.
• Härlig stämning. (2 st)
• Riktigt roligt med kickoff V2. (4 st.)
• Bara bra =) trots att vi närmar oss slutet.
• Alla tiders! :)
Kan bli bättre
• Viktigt att alla vågar säga vad de tycker vid beslutsdiskussioner.
Följer vi projektplanen?
Bra
• Känns som att vi tillämpar den beskrivna processen ganska bra. (3 st.)
• Möten hålls varje vecka och vi håller det som lovats i planen (vad jag vet).
• Vi har inte gjort några större ändringar i vår arbetsmetodik. Det känns som projektplanen håller ännu.
• Det tror jag. (3 st.)
• Har inte så bra koll på den. (2 st.)
Kan bli bättre
111
2.3. Iteration 2
• Jag kan bli bättre på att parprogrammera.
• Uppdatera projektplanen kanske? Även om det känns lite “onödigt” såhär på slutet.
• Kan ha bättre koll på projektplanen.
• Skriver in hur vi jobbar med grafiska saker (så man kommer ihåg hur vi gjorde saker).
• Mycket dokumentation för att säga att vi är agila.
• Jag skulle behöva ha bättre koll på scrumboarden.
Följer vi kravspecifikationen?
Bra
• Kraven har avstämts, vi följer specen.
• I och med integrationstest kollades kraven igen & även under sprint planning.
• Ja, det finns några krav 2 (spara till fil t ex) som vi inte har tittat på.
• Krav 1 avklarade. (2 st.)
• Nivå två är långt ifrån lika vettiga som design.
• Jajamen, Victor verkar ha koll.
• Antar det, kunden var ju nöjd.
• Har inte 100% koll på det, men under iteration 1 gjorde vi det, och jag skulle ändå säga
JA :)
Kan bli bättre
• Borde plocka ut kraven vi har kvar och läsa upp dem på sprint planning!
• Det grafiska arbetet är svårt att koppla till kravspecen.
• Kommer in en del okravade arbetspunkter. (2 st.)
Följer vi arkitekturdokumentet?
Bra
• Följer till stor del just nu.
• Utifrån det jag såg senast i dokumentet verkar det som att det följs!
• Kan lita på att Fredrik säger ifrån annars.
• Tror vi gör det fortfarande. (3 st.)
• Vi följer den generella strukturen till punkt och pricka. (2 st.)
Kan bli bättre
• Vissa påtänkta refaktoreringar eventuellt introducerar lite nya, ej beskrivna “mekanismer”.
• Har dålig koll på arkitekturdokumentet...
112
2.3. Iteration 2
• Jag tyckte det var lite oklart exakt vilka funktioner som ska vara i bridge.js och vilka
som ska vara i logic.js. Råkade lägga några funktioner fel, kanske är andra som har
gjort samma sak?
• Kanske sker utvecklingen till viss del utanför ramarna av arkitekturdokumentet.
• Hur gick det med kommitéen?
Följer vi kvalitetsplanen?
Bra
• Tror vi i stort sett gör det.
• Verkar ha fungerat bra!
• Tror vi följer kodgranskning, användbarhetstesterna, parprogrammering och git som vi
skrev där. (3 st.)
• Jag skulle tro det.
• Ingen aning. (2 st.)
• Parprogrammering + review höjer kvalitén.
Kan bli bättre
• Använder vi JS/HTML/CSS-valideringsverktygen vi nämnde i början?
• Jag har lite dålig koll på dokumentet.
• Mer parprogrammering och hårdare granskningar!
Uppdatering av relevanta dokument
Bra
• Inte så mycket förändring av dokumenten just nu.
• Alla verkar ha kommit igång med kandidatrapport.
• Tror alla dokument rättas efter kommentarer och opponering. (2 st.)
• Vi lägger inte för mycket tid på det.
• Tidrapporten är relevant och uppdateras väl.
• Testrapporten utvecklades fint mellan iteration 1 och 2.
• Tror det? Mest rapporten just nu av förklarliga skäl.
• Ja när det behövs uppdaterar ansvarig för det specifika dokumentet, det dokumentet
som behöver uppdateras :p
Kan bli bättre
• Trello - flytta kort och lägg till aktuella personer.
• Alla verkar inte så hemma i LaTeX. Måste vara jobbigt att vara osäker på syntaxen och
slösa tid på det när man bara vill få dit sin text.
• Kan behöva gå igenom äldre dokument igen? Någon mer inlämning av dessa?
113
2.3. Iteration 2
• Jag har rättat testplanen efter kommentarerna, kom dock på igår att det står där i att vi
har en utbildning under iteration 1. Jag måste sätta mig och läsa vad som faktiskt står
och inte bara kolla på kommentarer.
• Kom ihåg användarmanual till sprint planning.
• Vi kanske borde diskutera kommentarerna från oppositionen: gemensamt språk (nej),
gemensam framsida, osv. . .
• Övriga dokument har jag dålig koll på.
2.3.2
Förbättringsförslag
Testning, hur har det fungerat?
• Vi bör testa mer i den faktiska labbsalen (Southfork) där labbarna kommer hållas. Oscar
driver.
Prioriterar vi rätt saker att implementera?
• Vågar vi lägga timmar på en stor refaktorering, eller bör alla läggas på rapporten? Svar:
kör på det som ni vill göra! Så länge allt blir klart kan överflödiga timmar läggas på vad
man vill.
• Under nästa sprint planning ska vi gå igenom alla krav i kravspecen och plocka ut de
som ännu inte är uppfyllda för åtgärdande.
Kommunikation mellan gruppmedlemmar
• Det har blivit lite stökigt i #reviewrequest på sistone, med några lösa trådar. Åtgärd:
posta om de requests som inte blivit plockade av någon!
• Det är viktigt att alla vågar säga vad de tycker vid beslutspunkter. Ibland går det lite
för fort att ta beslut, vi borde sakta ner så alla hinner bilda sig en uppfattning.
• Designbeslut tas på afk-möten, med itererande i slack inför. Deadlines på reactande så
man inte behöver hetsa fram en åsikt, men samtidigt kommer åsikter in i vettig tid.
Följer vi projektplanen?
• Eventuellt beskriva hur vi jobbat med framtagning av det grafiska i systemet? [side
note: det ska tas upp i nästa utvärdering]. Åtgärd: Vi skriver om det i slutrapporten
såklart!
• Sammanställning av vad som händer nu de sista veckorna (deadlines och sånt) vore
nice - Kim fixar!
• Behöver vi uppdatera några av de dokumenten? Åtgärd: Rebecka kollar med Kristian.
Följer vi arkitekturdokumentet?
• Vi ska göra ett valideringstest för HTML/CSS/JavaScript.
114
2.4. Iteration 3
Uppdatering av relevanta dokument
• Vid uppdatering av dokument efter feedback - fixa inte bara de specifika kommentarerna, se över helheten också!
• Fredrik fixar så radbrytningarna blir rätt i rapporten. (Problem då vissa editar i specifika LaTex-editors och andra i emacs.)
• Egenordnad föreläsningsserie för kompetensutveckling och timmar.
• Rollspel inför slutredovisning? Och uttagning inför slutredovisningen.
2.4
Iteration 3
2.4.1
Fullständig sammanfattning
Jobbet med att ta fram det grafiska
• Känns som att det blivit överfullt i #design ibland. Jag hade varit okej med att bara få
ett par förslag istället för typ 10.
• Synd att det dröjde innan skelettet kom upp, men vi löste det bra sen.
• Jag tycker det gått bra. En funderingar jag har är om inte GUI-gruppen skulle ha
tillåtits vara lite mer autonoma i beslitsfattande gällande designval. Tror inte alla dessa
formella omröstningar vi haft egentligen behövts. Det har fungerat eftersom vi ändå är
en relativt liten grupp. Men i större projekt kan inte alla ha ansvar/bestämma över allt.
• Fungerat jättebra med GUI-gruppen, enklare att diskutera alternativ med 3 pers än 9.
Alla i GUI-gruppen fick göra en prototyp som visades för kund. Misskommunikation
medförde dock att kodskelett inte sattes upp förrän någon utomstående tog tag i det
själv, villket var synd.
• Borde lagt mer tid på att prototypa utseendet av de olika verktygen, de ser ganska olika
ut nu.
• Gick bra att köra whiteboard i början men det var kanske inte helt demokratiskt.
• Bra att låta GUI-gruppen ta fram förslag.
• Omröstningar har varit bra, men ibland hade valdeltagandet behövt vara bättre.
• Det har varit väldigt svårt att jobba med det grafiska. Mycket eftersom det inte har
funnits tydliga riktlinjer för vad vi ska jobba emot.
• Prototypandet har jag inte varit så inblandad i men det har varit bra att ha något att
visa kunden.
• Prototypningen var väldigt nyttig. Att ta fram en “fysisk” prototyp som alla kunde
testa öppnade upp för många bra diskussioner.
• Det var också betryggande att man visste att kunden ville samma sak som oss.
• Att ta fram de grafiska har varit superkul! Det är ju dock ett känsligt ämne, eftersom
det mesta är subjektivt. Men med våra omröstningar och möten tror jag att allas åsikter
lyfts fram. Jag tycker att det har fungerat bra!
• Hade gärna lagt mer vikt på att testa och utveckla handlingsinviter med användbarhetstesterna.
• Gillar hur slack använts för det visuella med massor av alternativ.
115
2.4. Iteration 3
Formatet på utvärderingarna
• Har alltid blivit ont om tid på slutet så vi stressat igenom diskussioner.
• Vi har haft väldigt fin och konstruktiv stämning på alla utvärderingar.
• Känns som att alla varit fokuserade på att förbättra framtida arbete, inte gnällande och
anklagande.
• Jag gillar att vi skriver på fysiska papper, det ger en lugn och fin och fokuserad stund
under mötet när alla fyller i. Dock lite jobbigt att transkribera allt sen.
• Trevligt med fika också.
• Tycker om formatet på utvärderingarna. Tror diskussionerna som uppkommit när vi
gått runt i gruppen och behandlat en viss punkt varit mycket givande. Många problem
som har uppkommit har fått ett naturligt forum för diskussion.
• Hade varit fördelaktigt om dessa utvärderingar kunde fyllts i via dator, då vissa handstilar är under all kritik, tydligen :(
• Fika är gott också!
• Hade föredragit anonyma utvärderingar.
• Har fungerat bra att punkterna delades upp i Bra/Kan förbättras.
• Tycker om upplägget med att diskutera punkterna i gruppen efter man fått tid för egen
reflektion.
• Fylla i utvärderingen på dator istället hade varit bra, slippa massa papper och slippa
läsa+skriva in på datorn senare för sammanställning. Finns såklart fördelar med att
fylla i för hand också.
• Bra att vi har diskuterat allas åsikter efteråt.
• Lite jobbigt att skriva för hand :)
• De har skett lagom ofta.
• I och med att vi har högt till tak fungerar det med icke-anonyma utvärderingar.
• Jag upplever att vi fått ut ganska mycket av utvärderingarna. Dock så har de inte alltid
känts så effektiva. Vi hade kunnat låta bli att skriva mer enskilt och bara ha diskussion
men då hade vi inte kunnat ha med det i rapporten på samma sätt.
• Tycker att våra utvärderingar har varit väldigt givande.
• Jag känner mig alltid oförberedd innan, men upplägget att man först får sitta och tänka
och sedan diskutera gör att man får fram väldigt mycket.
• Diskussionerna har varit guld värda med det här formatet
• Eftersom man inte vill ta upp känsliga ämnen till diskussion men ändå vill att de ska
adresseras. . . vet inte riktigt hur man ska göra där
• Gillar att vi skriver på papper på plats
116
2.4. Iteration 3
Slutprodukten, är vi nöjda?
• Jag tycker den blev himla snygg, ser verkligen ut som ett “riktigt” system.
• Jag är nöjd med att jag kan peka på en del (Vigenere front end i mitt fall) och säga “kolla,
det där jag jag gjort!”
• Jag är nöjd, speciellt med tanke på den begränsade erfarenhet vi hade av webbutveckling inledningsvis. Det är klart vi hade kunnat prestera en bättre produkt med mer
erfarenhet, men givet förutsättningarna är jag nöjd.
• Kunden verkar ju vara nöjd också, så det gör att det känns bra.
• Känns inte som att vi är riktigt klara ännu, all funktionalitet finns där men framförallt
utseendemässigt finns det en del kvar att förbättra.
• I stort är jag nöjd och stolt över produkten! Den är väldigt annorlunda mot Enigma 2.0
och jag anser den vara en klar förbättring.
• Slutprodukten är något jag kommer känna stolthet över att få visa för vänner och familj.
• Det finns mer att jobba på men utifrån den tid vi har haft och förbättringarna jämfört
med den tidigare produkten (Enigma?) så är jag väldigt nöjd.
• Produkten måste publiceras!
• Ja!
• Med tanke på vad som hänt tycker jag att vi gjort ett utmärkt jobb. Det finns dock vissa
saker jag vill att vi ska finslipa.
• Vi hade kanske hunnit med mer om vi lagt mindre tid på möten och utvärderingar.
• Ja, det är jag =D
• (Kommer dock alltid att svida lite att jag inte hann klart med allt och att jag inte satt så
mycket i SouthFork.)
• Nöjd!
• Vi var inte webbutvecklare när vi börjarde så, det känns inte riktigt som en hemsida,
systemet ser lite klumpigt ut på vissa ställen, men vi är inte grafiska designers och har
inte heller någon formell sådan.
Arbetandet i helhet
• Asså vi är så himla grymma!
• Upphör aldrig att förvånas över hur himla bra vi är och hur bra allt har gått.
• Tycker den process vi följt varit bra. Hade önskat mer arbete på samma fysiska plats
tillsammans, gärna också i samma lokal över tid för att mer få känslan av att gå till ett
jobb.
• Upplever att de flesta av oss också lyckats dela upp sin tid så att arbetsbördan varit
ganska jämn under projektets gång.
• Vi komplementerar varandra väldigt bra i gruppen, vilket har varit en stor fördel i
arbetet!
• Alla har ansvar för sina roller och man har aldrig behövt fastna länge i ett problem
innan man fått hjälp.
117
2.4. Iteration 3
• Vi har alla varit intresserade av varandras arbete .
• Vi har tursamt nog haft en grupp där alla är ambitiösa och drar sitt strå till stacken.
Det har varit roligt att arbeta så mycket tillsammans, mycket tack vare arbetsstugor och
Slack.
• Alla verktyg (Drive, WebStorm, Latex, git, Megaspreadsheet) har till slut fungerat så
bra så att vi kan arbeta effektivt och tillsammans lösa de problem som uppstår.
• Det känns som att alla har bidragit till slutprodukten och tagit sitt ansvar.
• Det här arbetet har känts väldigt proffsigt och på riktigt. Jag föreställer mig (och hoppas) att arbetslivet kommer vara ungefär så här.
• Tycker vi undvikit (nästan??) alla tidigare negativa erfarenheter?
Hur har vi fungerat som grupp?
• Bästa gruppen =) går mest omkring och pöser av stolthet. Vi har brytt oss om varandra
och sett till att hålla ihop gruppen.
• Bra. Vi har lyckats fördela arbete bra, och har kompetens inom olika områden som
kompletterar varandra.
• Tycker kommunikationen varit bra inom gruppen (igen, Slack<3).
• Det som kanske varit lite mindre bra är punktligheten till möten och liknande, det tycker jag är lite respektlöst mot de andra gruppmedlemmarna. Detta har dock inte varit
ett utbrett problem.
• Vi har eventuellt varit lite dåliga på att uppmärksamma framgång.
• Helt klart bästa projektgruppen jag varit delaktig i.
• Gruppmedlemmarna tar arbetet seriöst och alla har jobbat på redan från början.
• Även fast vi inte känner varandra särskilt väl på ett personligt plan, har vi varit öppna
och ärliga mor varandra.
• Väldigt harmoniskt.
• Mycket bättre än vad jag hört om andra grupper :)
• Jag har känt mig trygg i de andras sällskap, vågat visa vem jag är.
• Något för mycket förseningar och frånvaro från möten.
• Kanon! Vi har högt till tak och roligt tillsammans.
• Väldigt proffsigt och strukturera
• Kommer vara ett föredöme för mina projekt framöver
• Bästa gruppen ever
118
2.4. Iteration 3
Lärdomar
• Personligen har jag lärt mig mycket om ledarskap, jag har fått möjlighet att öva, och
reflektera kring hur jag är som ledare.
• En insikt om ledarskap är hur tydligt mitt humör och stämning påverkar stämningen
under mötena. Är jag trött och seg blir mötet trött och segt.
• En stor insikt är vilket otroligt värde det har att ha bra stämning i gruppen. Alla problem och hinder känns hanterbara, och det blir roligt att gå till jobbet. Plus att vi presterar
jävligt bra.
• Använd versionshantering, och lär alla i gruppen att använda det bra.
• Känner mig personligen mer hemma i webbvärlden än innan.
• Uppmärksamma framgång.
• Underskatta inte vad socialt umgänge/fika/icke projektrelaterade aktiviteter gör för
gruppsammanhållningen.
• Lägg upp en bra grund för att sedan bygga vidare på denna när utvecklingsarbetet
börjar. Infrastruktur är viktigt.
• Var öppna med personliga problem från början, det underlättar i längden.
• Måenderundor <3 - gruppen lär känna varandra och det känns mer accepterat att man
kan ha en dålig dag. Jag upplever att det öppnar upp för mer personlighet och att folk
blir mer än bara resurser i arbetet.
• Utbildningar inom gruppen - istället för att alla ska läsa på om något på egen hand,
tillsätt en ansvarig att hålla en workshop/genomgång. Det blir trevligare, folk kan
ställa frågor och diskutera och den ansvarige för öva presentationsteknik. Detta har
fungerat jättebra hos oss.
• Kickoff, Halvtidsmys och Avslutning har varit bra sätt att komma bort från att endast
associera varandra till projektet. Både planeringen inför och genomförandet av dessa
träffar har varit riktigt kul! (Avslutningen har dock inte varit men har svårt att tro att
det skulle vara annat).
• Utvärdera ofta så att det finns möjlighet att förbättra och utveckla gruppens arbete under projektets gång. Var inte rädd för att säga ifrån om något inte fungerar bra.
• Det är viktigt att ha roligt. Kick-off och dylikt har varit mycket givande.
• Vi har fått arbeta med det vi tycker är intressant, men också provat på många nya saker.
• Parprogrammera mera!
• Kodgranskning fungerar bra.
• Båda dessa arbetssätt gör att man kan lära av de bästa i gruppen. Istället för att avundas
dem.
• Någon hade behövt ta ansvar för designarbetet och styra det mer diktatoriskt.
• En bra branching model och en kompetent gitmaster behövs verkligen om man ska
jobba effektivt på olika features samtidigt.
• Det gäller även strukturen på koden.
119
2.4. Iteration 3
• Daily scrum är superbra för att få en överblick av vad alla gör och för att motivera folk
till att prestera något.
• Hur viktigt engagemang, struktur och planering är. Nästintill ingenting, under hela
projektets gång, han känts “kaosigt” eller hopplöst. Ibland känner jag nästan att vi
slapp undan för lätt.
• Platt rollstruktur i all sin ära. Men det är väldigt bra med tydliga roller och ansvarsområden. Vi har jobbat väldigt mycket med våra roller och vi har krävt att man gör sin
rollspecifika uppgift, och samtliga medlemmar har bara gjort det utan strul.
• Ha en öppenhet i gruppen, Använd verktyg (Git, drive, trello, slack) och kräv att alla
jobbar “genomskinligt”. För gruppen och projektets bästa så ska man inte dölja sitt
arbete, även om det är skit.
• Eftersom vi mått bra har vi fått en bra produkt! Fokuset låg på att vi skulle må bra!
• Inte döljt arbete
• Första om webb, i like
• Mer fira framgång
• Måenderundor+++
• Utbildningar++
• Code reviews++
• (Bra) format och frekvens på utvärderingar+
• Arbetsstugor++
Arbetsmetod (Scrum, parprogrammering, arbetsstugor)
• Arbetsstugor är det bästa ever, så himla trevligt och givande.
• Parprogrammering är ett jättebra sätt att lära sig, om man sitter ihop med någon som
kan mer än en själv.
• Scrum har funkat bra, vi har ju inte följt det jättenitiskt.
• De jobbstugor vi haft har varit superbra. Det leder till ett så mycket större informationsutbyte än att arbeta själv hemma. Nöjd också med Scrum, tror dock vi tjänat på att
ha våran Scrum Board (Trello) mer integrerad i utvecklingen. Detta hade kanske varit
lättare om vi haft en fysisk sådan (se kommentar om samma fysiska arbetsplats över
tid).
• Har inte parprogrammerat så mycket under projektet, men vet att det är bra. Återigen,
en gemensam arbetsplats hade underlättat.
• Hade kanske varit smidigare i längden att använda ett dedikerat verktyg för kodgranskning också.
• Jobbstugor har fungerat jättebra och motiverat till att sitta och arbeta. Jag har föredragit
att arbeta självständigt hellre än att parprogrammera, men jobbar jämsides någon som
sitter med en liknande uppgift, så att man kan diskutera alternativ och be varandra om
hjälp.
120
2.4. Iteration 3
• Scrum har fungerat jättebra för utvecklingen. Jag har tidigare endast jobbat enligt vattenfallsmodellen tidigare så är mycket positivt överraskad. Jag upplever att Scrum
medfört att gruppen arbetade hårt redan från start eftersom vi ville hinna tömma sprint
backlogen för varje iteration.
• Scrum - Enkel att applicera, kommer in som en naturlig del i planering och informationsspridning.
• Parprogrammering - Extra bra för att lära känna varandra. Tur att det var valfritt, lite
oflexibelt.
• Jobbstugor - Trevligt, har inte blivit stökigt utan vi har hållit oss till effektivt arbete. Bra
att ha oavsett om man är 2 eller 9 personer.
• Scrum har fungerat smidigt. Dock så har vi gjort väldigt mycket mer dokumentation
än vad agil utveckling förespråkar.
• Parprogrammering är kanon för att lära sig och bli en bättre utvecklare. Dock så är det
svårt att hitta tider (gäller främst VT1).
• Jobbstugor var bra när man skulle utveckla men kunde vara distraherande när man
ville skriva dokument. Detta berodde dock på vem man satt med.
• Kodgranskning har varit bra för att lära sig. Dessutom har det bidragit till att koden
känns bättre, vilket är viktigt när den ska publiceras.
• Scrum har fungerat kanon. Tror att det var utbildningen som möjliggjorde att det skulle
fungera. Vi har ju ständigt anpassat Scrum efter våra behov. Då har det fungerat mer
som ett verktyg än ett krävande moment.
• Parprogrammering verkar bra. Har inte använt det så mycket.
• Jobbstugorna har varit trevliga.
Övrigt
• Rollfördelningen har varit guld värd, den gjorde det väldigt tydligt i början vem som
hade ansvar för vad, och bidrog till att ordna så alla hade saker att jobba med.
• Jag har lärt mig väldigt mycket av utvecklingen och gruppmedlemmarna i detta projekt.
• Jag hade gärna arbetat längre med projektet, det har varit väldigt kul!
• Jag har ännu inte gjort någon projektrealterad enhetstestning och inte heller någon review av någon annans kod. Detta är väldigt synd men helt och hållet mitt egna fel. Om
vi i början av projektet hade gått igenom några sådana tillsammans hade jag nog varit
mer benägen att ta åt mig fler reviews när tillfälle getts.
• Projektet har levt sitt liv i en egen liten bubbla. Det har varit fantastiskt, men det ska bli
skönt att avsluta och gå vidare.
• Jag tycker att måenderundorna var bra i början för att lära känna varandra men har
sedan dess blivit ett nödvändigt ont som kostat ganska mycket tid från mötena. Dessa
diskussioner kan tas under raster.
• Vi hade behövt vara hårdare på mötesregler. Det var ofta möten började minst fem min
efter utsatt tid.
• Tråkigt att projektet måste ta slut nu.
• Code review i grupp?
121
2.4. Iteration 3
2.4.2
Sammanställning från diskussion
Jobbet med at ta fram det grafiska
• Mer autonom GUI-grupp.
• Smidigt med prototyp i början, och i relation till kunden.
• Kunde prototypat verktygen i början, nu ser de väldigt olika ut.
• Lite styrda av CSS i designarbetet.
Formatet på utvärderingarna
• Eventuellt fylla i på dator istället.
• (Litet) eventuellt fylla i i förväg.
• Möjlighet att skicka känsliga punkter anonymt
• Helt anonyma utvärderingar?
Slutprodukten, är vi nöjda?
• Ja!
• Finns mer att göra.
Arbetandet i helhet
• Eget kontor hade varit givande.
• Undvikit det negativa från tidigare erfarenheter.
• Fungerat.
Hur har vi fungerat som grupp?
• Mer uppmärksammande av det som gått bra.
• Vad grymma vi är.
• Bli hårdare på att börja möten på utsatt tid.
Arbetsmetod (Scrum, parprogrammering, arbetsstugor)
• Scrum boarden har inte varit så integrerad i arbetsmetoden.
• Vi har anpassat Scrum efter oss, istället för tvärtom.
• Kontor hade hjälpt mycket.
Övrigt
• Det har varit en bubbla.
• Utbildning i code review och enhetstestning vore bra.
122
Bilaga 3 Complexity-reportsammanfattningar
Sammanfattning från mätning på CustomerManagerStandard.
Mean per-function logical LOC: 3.751946606149028
Mean per-function parameter count: 0.9351797746177035
Mean per-function cyclomatic complexity: 1.4586836202825904
Mean per-function Halstead effort: 667.9685212052052
Mean per-module maintainability index: 129.21554203129884
First-order density: 0%
Change cost: 4.166666666666666%
Core size: 0%
Sammanfattning från mätning på FoodMe.
Mean per-function logical LOC: 3.764285714285715
Mean per-function parameter count: 1.2784313725490197
Mean per-function cyclomatic complexity: 1.2683473389355742
Mean per-function Halstead effort: 422.78367039791067
Mean per-module maintainability index: 134.9797991841414
First-order density: 0%
Change cost: 5.88235294117647%
Core size: 0%
Sammanfattning från mätning på Ember.js Dashboard.
Mean per-function logical LOC: 3.365432098765432
Mean per-function parameter count: 0.5583333333333333
Mean per-function cyclomatic complexity: 1.3138888888888889
Mean per-function Halstead effort: 430.90967990255655
Mean per-module maintainability index: 139.67517804960195
First-order density: 0%
Change cost: 8.333333333333332%
Core size: 0%
Sammanfattning från mätning på Knekt.
Mean per-function logical LOC: 8.790385855728855
Mean per-function parameter count: 1.0571479017616219
Mean per-function cyclomatic complexity: 2.4074217055786056
123
Mean per-function Halstead effort: 2799.0255918963885
Mean per-module maintainability index: 115.11291969945968
First-order density: 0%
Change cost: 4.3478260869565215%
Core size: 0%
124
Bilaga 4 Undersökning: Värdet av en
prototyp
4.1
Enkät
Denna del presenterar de frågor som ställdes i en online-enkät för att undersöka de olika
projektgruppernas erfarenhet av att jobba med prototyper.
Introduktion
I samband med kursen TDDD96 Kandidatprojekt i Mjukvaruutveckling skrivs en individuell
rapport. Denna rapport kommer att behandla de för- och nackdelar som finns med att ta
fram en prototyp för ett mjukvarusystem samt vilka processer som genomförs i utvecklingen
av en prototyp. Som underlag kommer sammanställningen av denna undersökning att
användas.
Undersökningen riktar sig till studenter som ingår i en projektgrupp i denna kurs. För att
kunna ta del av undersökningen skall projektgruppen ha använt sig av prototyper i någon
form. Undersökningen utförs av Kimberley French (kimfr230@student.liu.se), dokumentansvarig i grupp 10.
Alla svar är helt anonyma.
Frågor
1. Vilken projektgrupp tillhör du?
2. Hur många timmar har lagts ner på prototypningsarbete?
Antal timmar totalt, för hela gruppen. Om du inte vet kan du gissa på vad du tror är rimligt.
3. Vilken sorts prototyp har använts för ert projekt?
Med avseende på material.
˝ Pappersprototyp
˝ Datorprototyp
˝ Övrigt:
4. Vilken sorts prototyp har använts för ert projekt?
Med avseende på livslängd.
125
4.1. Enkät
˝ Temporär (“throw away”) prototyp
˝ Evolutionär prototyp (tidig version av slutprodukten)
˝ Övrigt:
5. Varför valdes just denna sorts prototyp?
6. Vad hade er projektgrupp för avsikt med att arbeta fram en prototyp?
7. Anser du att prototypen har uppfyllt sitt syfte med avsikten i åtanke?
˝ Ja, till stor del
˝ Till viss del
˝ Inte alls
8. Beskriv, i korthet, hur ni gick tillväga i framtagandet av er prototyp.
Gjordes en eller flera prototyper? Hur många gruppmedlemmar var involverade i prototyputvecklingen?
9. Har du använt eller tittat tillbaka på prototypen sedan den blev färdigställd?
˝ Ja, flera gånger
˝ Ja, någon enstaka gång
˝ Nej
10. Skulle du påstå att du haft användning av prototypen i ditt arbete med projektet?
˝ Absolut, den har varit till stor hjälp i mitt arbete
˝ Ja, den har fungerat som stöd i mitt arbete
˝ Inte direkt, jag har fått en bättre bild av slutprodukten men den har inte nämnvärt
påverkat mitt arbete
˝ Nej, jag har inte haft någon användning för den i mitt arbete
11. Om ja, på vilket sätt?
12. Har du någonsin upplevt prototypen som begränsande eller hämmande av nya idéer?
˝ Ja, flera gånger
˝ Ja, någon enstaka gång
˝ Nej
13. Om ja, på vilket sätt?
14. Anser du att tiden ni investerat i prototypningsarbetet har varit givande för utvecklingen av ert projekt?
˝ Absolut, vinsten av prototypningsarbetet överskred kostnadenrna markant
˝ Ja, det har underlättat gruppens arbete utan att kräva alltför mycket tid
˝ Inte direkt, tiden det tog att göra prototypen har inte lönat sig för resten av projektarbetet
˝ Nej, det var helt bortslösad tid som hade kunnat läggas på annat
15. Ytterligare kommentarer om varför/varför inte.
Anser du att tiden ni investerat i prototypningsarbetet har varit givande för utvecklingen av ert projekt?
16. Övriga fördelar
På vilket sätt underlättade prototypen för er utveckling? Vad var det som gjorde er prototyp bra?
17. Övriga nackdelar
Vilka problem fanns kring prototypningsarbetet eller med prototypen i sig? Saknades något i er prototyp?
126
4.2. Sammanställning
4.2
Sammanställning
Nedan visas en sammanställning av svaren från de tre grupper som hade flest deltagare i
undersökningen. Svaren har sorterats efter projektgrupp och flervalsalternativ har angivits
som en procent av antalet deltagare från varje grupp. För att anonymisera svaren har gruppnummer ersatts av bokstäver.
Grupp A (8 personer):
1. Projektgrupp: A
2. Tidsåtgång: 10 - 150 timmar. Se figur B.1a.
3. Sorts prototyp (material): 87.5% Dator. 12.5% Whiteboard.
4. Sorts prototyp (livslängd): 75% Temporär. 25% Evolutionär.
5. Varför detta prototypval: Ville ha många alternativa designer, snabbt sätt att visa olika exempel på utseende. Var tänkt att vara evolutionär men kodbasen gick inte att använda.
6. Avsikt med prototypen: Skapa en gemensam bild av produkten och ge gruppen ett mål. Visa
kund ett antal alternativ. Utforska flera alternativ. Ta reda på hur/vilka funktioner som skulle
med. Ta fram ett tilltalande GUI.
7. Har uppfyllt sitt syfte: 87.5% Ja, till stor del. 12.5% Till viss del.
8. Tillvägagångssätt: Mindre grupp (3 pers) tog fram några alternativ som visades för kund. Input och omröstning med övriga projektmedlemmar. Gruppen diskuterade vad som skulle finnas
med och hur alternativen kunde skilja sig.
9. Har använt/tittat på färdig prototyp: 62.5% Ja, någon enstaka gång. 37.5% Nej.
10. Haft användning utav den: 58% Inte direkt. 28% Ja, fungerat som stöd. 14% Nej, ingen
användning.
11. Hur använt: Gav en bild av slutresultat men inte hur det var tekniskt genomförbart. Har
fungerat som mall. Kan blicka tillbaka på vid implementering. En övergripande plan i början.
12. Prototypen varit begränsande: 75% Nej. 25% Ja, någon enstaka gång.
13. Hur begränsande: Alternativen konvergerade väldigt tidigt, borde haft fler idéer som inte var
så lika.
14. Givande investering av tid: 75% Ja, har underlättat. 12.5% Absolut, vinsten överskred kostnaderna markant. 12.5% Inte direkt lönsamt.
15. Kommentarer på tidsinvestering: Kunnat visa kund och få feedback, vilket gör att utvecklingsarbetet känns mer legitimt och kundförankrat. Hela gruppen fick en tydlig bild och mål –
blir lättare att arbeta. Visste vad vi skulle göra, inte slösa tid på onödig funktionalitet. Gruppen
var överens redan från början, hade gått utan prototyp.
16. Övriga fördelar: Kunde visa kund tidigt var vi tänkte. Ett mål att arbeta mot. Utan en prototyp
hade det saknats en grund att utgå ifrån, speciellt i en så stor grupp.
17. Övriga nackdelar: Alla var inte med i prototyputvecklingen, kanske gick någon bra idé förlorad? Prototypens funktionalitet var inte så bra, men hade varit bortkastad tid att göra mer.
Handlingsinviter behandlades inte i prototyperna. Prototyparbetet kan ha försenat upprättandet
av ett kodskelett. Mycket av designen bestämdes utifrån vad som ansågs möjligt att koda.
127
4.2. Sammanställning
Grupp B (6 personer):
1. Projektgrupp: B
2. Tidsåtgång: 50% 5-10 timmar. 50% 200 timmar. Se figur B.1b.
3. Sorts prototyp (material): 100% Dator.
4. Sorts prototyp (livslängd): 100% Evolutionär.
5. Varför detta prototypval: Krävdes lite planering. Hade inget behov av att göra en isolerad
prototyp. Prototypen är på många sätt produkten.
6. Avsikt med prototypen: Samla kunskap. Visa något för kunden. Lära sig verktygen.
7. Har uppfyllt sitt syfte: 100% Ja.
8. Tillvägagångssätt: En person började med en första prototyp. Mindre grupp testar sig fram.
Sedan nästan alla med menyskal som vidareutvecklades.
9. Har använt/tittat på färdig prototyp: 83% Nej. 17% Ja, flera gånger.
10. Haft användning utav den: 50% Ja, fungerat som stöd. 33% Inte direkt. 17% Stor hjälp.
11. Hur använt: Grunden i projektet (eftersom evolutionär).
12. Prototypen varit begränsande: 67% Nej. 33% Ja, någon enstaka gång.
13. Hur begränsande: Tvister i implementation och utformning. Inte tid att realisera fler prototyper.
14. Givande investering av tid: 67% Ja, har underlättat. 33% Absolut, vinsten överskred kostnaderna markant.
15. Kommentarer på tidsinvestering: Experimenterade med verktyget. Prototyp fungerade som
guide till resterande i gruppen. Är grunden till slutprodukten.
16. Övriga fördelar: Snabb och enkel att ändra efter kundens behag och resultat av användartestning. Uppmuntrade till utveckling.
17. Övriga nackdelar: Tar mycket tid att göra en separat prototyp, särskilt i ett tidsbegränsat
projekt.
Grupp C (4 personer):
1. Projektgrupp: C
2. Tidsåtgång: 20 - 60 timmar. Se figur B.1c.
3. Sorts prototyp (material): 100% Dator.
4. Sorts prototyp (livslängd): 100% Evolutionär.
5. Varför detta prototypval: Snabbt kunna visa för kunden. Testa erhållet script.
6. Avsikt med prototypen: Ta reda på vad kunden vill ha och få snabb feedback. Se till att det
erhållna scriptet fungerar.
7. Har uppfyllt sitt syfte: 50% Ja. 50% Till viss del.
8. Tillvägagångssätt: En person gjorde ritningar. Mindre grupp ansvarade för utvecklandet.
128
4.2. Sammanställning
9. Har använt/tittat på färdig prototyp: 50% Ja, någon enstaka gång. 25% Ja, flera gånger.
25% Nej.
10. Haft användning utav den: 50% Ja, fungerat som stöd. 25% Inte direkt. 25% Stor hjälp.
11. Hur använt: Kod att utgå från. Implementation av GUI. Testa funktionalitet.
12. Prototypen varit begränsande: 75% Nej. 25% Ja, någon enstaka gång.
13. Hur begränsande: Dålig kod som skrivits.
14. Givande investering av tid: 50% Ja, har underlättat. 50% Absolut, vinsten överskred kostnaderna markant.
15. Kommentarer på tidsinvestering: Borde lagt mer fokus på use cases. Tog lite tid och kunde
återanvända idéer därifrån.
16. Övriga fördelar:
17. Övriga nackdelar: Ogenomtänkt struktur.
129
Bilaga 5 Enkät: Utvärdering av
parprogrammering och
kodgranskning
5.1
Enkät
Nedan följer den enkät om parprogrammering och kodgranskning som utfördes med grupp
10 under kandidatprojektet i kursen TDDD96.
Parprogrammering
1. Hur är din inställning till parprogrammering sett utifrån dina erfarenheter under projektets gång?
˝ Mycket negativ
˝ Negativ
˝ Neutral
˝ Positiv
˝ Mycket positiv
2. Hur stor del av din programmering under projektet har skett genom parprogrammering?
˝ 0-20 %
˝ 21-40 %
˝ 41-60 %
˝ 61-80 %
˝ 81-100 %
3. Vilka positiva effekter har parprogrammering haft på samarbetet i gruppen?
4. Vilka negativa effekter har parprogrammering haft på samarbetet i gruppen?
5. Vilka fördelar har du sett med parprogrammering i det här projektet?
6. Vilka nackdelar har du sett med parprogrammering i det här projektet?
Kodgranskning
1. Hur är din inställning till kodgranskning sett utifrån dina erfarenheter under projektets
gång?
130
5.2. Sammanställning av fritextfrågor
˝ Mycket negativ
˝ Negativ
˝ Neutral
˝ Positiv
˝ Mycket positiv
2. Hur många granskningar har du utfört under projektet?
˝ 0
˝ 1
˝ 2
˝ ...
˝ 10+
3. Vilka positiva effekter har kodgranskning haft på samarbetet i gruppen?
4. Vilka negativa effekter har kodgranskning haft på samarbetet i gruppen?
5. Vilka fördelar har du sett med kodgranskning i det här projektet?
6. Vilka nackdelar har du sett med kodgranskning i det här projektet?
Avslutande frågor
1. Vilken av metoderna parprogrammering och kodgranskning skulle du välja att använda till ett framtida projekt om du bara kunde välja en av dem?
˝ Parprogrammering
˝ Kodgranskning
˝ Vet ej/Kan inte välja
2. Har du några övriga kommentarer kring parprogrammering eller kodgranskning som
du vill lyfta fram?
5.2
Sammanställning av fritextfrågor
Här redovisas svaren från enkätens fritextfrågor. Vid tillfällen då flera personer har givit
samma eller snarlika svar redovisas dessa svar som ett svar med suffixet “(X st.)” där X
anger antalet personer.
Parprogrammering
1. Vilka positiva effekter har parprogrammering haft på samarbetet i gruppen?
• Man lär känna varandra bättre. (3 st.)
• Man tvingas umgås med varandra. (2 st.)
• Det skapar en öppenhet i gruppen. (2 st.)
• Koden blir aldrig personlig eftersom två personer skapat den. (2 st.)
• Jag tror att det har bidragit till kompetensspridning. (2 st.)
• Gruppen får en mer enhetlig bild av projektet.
• Jag tror att om ett par sitter och diskuterar lösningsgångar, problem och idéer så
känns det naturligare att blanda in flera personer i diskussionen än om en person
satt själv och aldrig hade diskuterat sin kod.
131
5.2. Sammanställning av fritextfrågor
• Givande diskussioner kring problem samt informationsspridning inom gruppen.
• Det blir lättare att samarbeta ju mer man parprogrammerat.
• Det känns som att vi är ett team.
• Parprogrammering hjälper till med kommunikation, sådan man kanske inte haft
annars.
• Parprogrammeringen har också gjort att det funnits minst 2 personer som kan säga
“dra in och jobba?” som kan ge positiva känslor i fall man inte känner sig så sugen
på att göra något alls.
2. Vilka negativa effekter har parprogrammering haft på samarbetet i gruppen?
• Det är svårt att hitta tider där båda kan jobba. (4 st.)
• Inga (3 st.)
• Om man är en av de som har svårt att jobba under kontorstid kan man ha känt sig
utanför.
• Ibland förstår man inte riktigt varandra och blir då nästan låst på grund av det.
• Ibland har det känts tråkigt, till exempel när enhetstest som varit självklara behövt
skrivas (med copy paste), har stundvis känts som man inte är till hjälp.
3. Vilka fördelar har du sett med parprogrammering i det här projektet?
• Bättre kod. (4 st.)
• Mer genomtänkta och generella lösningar. (4 st.)
• Kunskapsspridningen ökas vilket förhindrar att en person blir kritisk för projektet.
(2 st.)
• Lärorikt. (2 st.)
• När man kört fast tar man sig snabbare ur det.
• Bra då många var osäkra på HTML/JavaScript.
• Personer som inte känt sig så säkra programmeringsmässigt har ändå fått vara
med i utvecklingsarbetet samt kanske också fått större självförtroende gällande
utvecklingsarbetet.
• Bättre liv.
4. Vilka nackdelar har du sett med parprogrammering i det här projektet?
• Tidskrävande. (2 st.)
• Inga.
• Om den ena är lite nere kan den göra att även den andra blir lite nere.
• Små saker kan förstoras till större problem i onödan.
• Vissa uppgifter har varit förhållandevis triviala och har kanske bäst lämpat sig att
utföras av en utvecklare lite snabbt, men eftersom vi inte påtvingat parprogrammering så har detta inte varit ett praktiskt problem egentligen.
• Bestämma plats. Två personer måste kunna deltaga samtidigt, kan vara krabbigt
att hitta tid som passar för båda två.
• Förmodligen mer åtgångna timmar då mycket av kodandet kostat dubbla timmar.
Kodgranskning
1. Vilka positiva effekter har kodgranskning haft på samarbetet i gruppen?
132
5.2. Sammanställning av fritextfrågor
• Det gör att det är naturligt att andra sätter sig in och kommenterar din kod. Det
blir inget påhopp och det känns inte konstigt om någon kommer med kritik eller
synpunkter.
• Fler har tittat på koden.
• Granskaren lär sig mer om och av de som skrivit koden och vice versa.
• Det leder till diskussion mellan gruppmedlemmar samt spridning av kompetens.
• Det har känts att den som granskar försöker hjälpa en
• Bättre kommunikation mellan berörda parter.
• Snacket efter granskningen har gjort att man lärt känna varandra genom att höra
varandras synpunkter på t.ex. en viss lösning vilket ökar tilliten vilket är en grundsten för samarbete!
• Mer pratande mellan gruppmedlemmar -> bekvämare stämning.
2. Vilka negativa effekter har kodgranskning haft på samarbetet i gruppen?
• Inga (2 st.)
• Ibland kan det kännas som om kodgranskarens ord är lag trots att det handlar om
smak och eget tycke i vissa frågor.
• Det ökar mängden kritik inom gruppen.
• De som har lite egen “stil” i sitt kodskrivande kan lätt bli överkörda då vi vill att
kodstilen ska vara enhetlig.
• Ibland svårt att få personer till att reviewa sitt arbete.
• Kan kännas lite jobbigt om det är mycket negativt att ta upp.
• Personer är olika i hur man vill ha feedback, en risk vid kodgranskning är att man
uttrycker sig slarvigt vilket gör att review:n får en negativ klang.
3. Vilka fördelar har du sett med kodgranskning i det här projektet?
• Bättre kod. (6 st.)
• Det blir naturligt att dela med sig och visa sin kod.
• Man lär sig mycket både av att granska och bli granskad.
• Om granskaren förstår utan att ha varit involverad i lösningen borde den vara
tillräckligt välkommenterad och i och med det ökar även underhållbarheten.
• Det gör så att fler projektmedlemmar är bekanta med en större del av kodbasen.
• Mycket fel i stil har eliminerats innan den kommit upp på dev, hjälpt att undvika
parallellt arbete på develop.
• Lärdomar, olika sätt att lösa ett och samma problem på. Tips och idéer flyger runt
efter en granskning.
• Det har gett intressanta diskussioner om tekniska lösningar.
• Vi har undvikit olämpliga kodkommentarer och onödiga småfel.
4. Vilka nackdelar har du sett med kodgranskning i det här projektet?
• Tidskrävande. (4 st.)
• Funktionalitet som hade varit praktisk att snabbt mergea in i develop får ligga och
vänta på grund av att granskningen dröjer.
133
5.2. Sammanställning av fritextfrågor
• Ibland sker kodgranskningen formellt (med request - review push -merge) trots
att det kanske handlar om någon eller en rad kod som blivit skriven. Det kan då
ta onödigt lång tid för vissa saker att komma in på develop. Det blir i vissa fall en
onödigt flaskhals.
• Det är inte speciellt roligt.
• Inga.
• Ibland har det blockat en från att merga in till dev, vilket resulterat i fler mergekonflikter
• Kan ta tid att gå vidare (få någon att granska), men har vi haft dependencies så har
det gått fort.
• Review tas negativt av vissa.
• Dröjt innan saker kommit in på develop.
Övrigt
1. Har du några övriga kommentarer kring parprogrammering eller kodgranskning som
du vill lyfta fram?
• Parprogrammering fungerar bäst för att komma igång med en uppgift eller när
man känner sig osäker på hur ett problem kan lösas. Allra bäst tycker jag det
fungerar om man sitter tillsammans men arbetar enskilt, så att man lätt kan ta
hjälp av varandra så fort man kör fast, men det blir mer produktivt än att två
personer sitter vid samma dator och kodar.
• Alla klarar inte alltid att samarbeta, vissa gillar bäst att koda själv. Kombinationen
parprogrammering och kodgranskning lämpar sig i alla fall för projekt i mindre
skala, om kodgranskningsprocessen inte är så extensiv.
• Kodgranskning är guld värt, både att få veta bättre sätt att lösa något på, men
samtidigt kunna få feedback på saker man löst på ett bra sätt.
• Jag vill använda båda metoderna i ett framtida projekt.
134
Bilaga 6 Enhetstestning - Datainsamling
Datainsamling
Introduktion
Välkommen till den här datainsamlingen. Idag ska vi undersöka om och hur enhetstestning
kan påverka programmeringsprocessen och tidsåtgången. Det du ska göra är att lösa några
programmeringsuppgifter med olika förhållningssätt till enhetstestning.
Uppgifterna, utvecklingsmiljön och enhetstesterna ska efterlikna det riktiga projektet i
största möjliga mån.
Miljö
Allting kommer ske i samma utvecklingsmiljö, testramverk och programmeringsspråk som
det du är van vid från projektarbetet, nämligen:
• Utvecklingsmiljö:WebStorm
• Testkörare: Karma
• Testramverk: QUnit
• Programmeringsspråk: JavaScript
Upplägg
Uppvärmning
Datainsamlingen börjar med att du utför uppvärmningsuppgiften. Under den här uppgiften
får du skriva enhetstester precis hur och när du vill, det viktiga är att några godtyckliga
enhetstester faktiskt skrivs. Tanken med den här uppgiften är dels att värma upp dig som
deltagare men även för att se att miljön, språket och testerna fungerar som tänkt, så att detta
inte tar tid eller saboterar annan data under de andra uppgifterna.
Uppgifterna
Du kommer utföra 3 olika uppgifter. Idén till uppgifterna kommer från diverse tävlingsprogrammeringsuppgifter. Dessa uppgifter framställdes eftersom de går fort att lösa och i nån
135
mån representerar problem du stött på under projektet.
I den här datainsamlingen ska du genom dina testfall försäkra dig om att din kod fungerar
som du tänkt. Därför ska du inte lägga tid på att analysera om ditt slutgiltiga svar är rimligt.
Om dina testfall går igenom anger du svaret du har fått och går vidare.
Skulle något vara otydligt så är det bara att fråga.
136
Testdriven utveckling
Tanken bakom testdriven utveckling är att testerna ska utforma koden. Du kan tänka på det
som att “tänka först, programmera sen”.
För att lösa den givna uppgiften med testdriven design ska du börja med att skriva enhetstester. Då är det bra att tänka igenom vilka funktioner din kod behöver. För att göra
testvänlig kod är det klokt att bryta upp din kod i många, mindre funktioner. Sträva emot att
en funktion endast ska utföra en enda uppgift.
När du har bestämt vilka funktioner du behöver skriva och har skrivit testfall för dessa
har du nästan ett komplett kodskelett. Nu gäller det bara att börja skriva den faktiska koden.
När alla testfall godkännes så ska din kod vara färdig och fungerande.
Lycka till!
137
Skriva testfall under programmeringen
Nu ska du testa på hur det är att skriva testfall omlott med kodskrivandet. Ett sätt att göra
detta kan vara att skriva testfall efter du har kodat en ny funktionalitet. Till exempel om ditt
program kommer bestå av tre funktioner kan du skriva testfall för varje funktion precis efter
du har skrivit klart den.
Försök integrera testskrivandet i kodskrivandet i största möjliga mån.
Det viktigaste är att du inte skriver alla testfall före eller efter kodandet.
Lycka till!
138
Skriva testfall efter kodandet
Nu ska du prova att skriva alla testfall efter du har skrivit klart programmet. Du kan tänka
på det som “gör först, tänk sen”.
Koda tills du känner dig klar, programmet borde fungera. Skriv sedan testfall som du
känner är lämpliga. Kontrollera att alla testfall körs och blir godkända.
Lycka till!
139
Uppvärmning
17 är större än 4. Likaså är 3 större än 2.
Skriv en funktion som tar in två tal och returnerar det talet som är störst.
Skriv några lämpliga testfall och se att allting fungerar som det är tänkt innan du tar
dig an de riktiga uppgifterna.
140
Uppgift 1
Förhållningssätt du ska använda dig av:
Kvadraten av summan av de första tio naturliga talen är:
(1 + 2 + ... + 10)2 = 552 = 3025
Summan av kvadraten av de första tio naturliga talen är:
12 + 22 + ... + 102 = 385
Skillanden mellan summan av kvadraten och kvadraten av summan för de tio första naturliga
talen är:
3025 ´ 385 = 2640
Vad är skillanden mellan summan av kvadraten och kvadraten av summan för de första
100 naturliga talen?
Tips: x n kan skrivas som Math.pow(x, n) i JavaScript.
Svar:
Tidsåtgång för att koda och testa:
Antal funktioner:
141
Uppgift 2
Förhållningssätt du ska använda dig av:
Kent har köpt en pizza.
Kent älskar ost. Kent tycker att hans pizza har för lite ost. Kent blir förargad.
Kents pizza är rund och har en radie på 10 cm. Den yttre kanten av deg är 2 cm och
har ingen ost på sig. Hur många procent av Kents pizza har ost på sig?
Tips 1: Arean för en cirkel: A = Radien ˚ Radien ˚ π
Tips 2: π kan i denna uppgift betraktas som 3.14
Svar:
Tidsåtgång för att koda och testa:
Antal funktioner:
142
Uppgift 3
Förhållningssätt du ska använda dig av:
2520 är det minsta talet som är jämnt delbart med alla tal från 1 till 10.
Hitta det minsta talet som är jämnt delbart med alla tal från 1 till 20.
Tips: Kom ihåg att man kan använda modulo (%) för beräkna restprodukten av en division.
Svar:
Tidsåtgång för att koda och testa:
Antal funktioner:
143
Enkät
Enhetstestning under projektet
1. Har du använt dig av enhetstestning under projektets gång? Om du svarar "Nej": gå
vidare till nästa kapitel som behandlar datainsamlingen.
˝ Ja
˝ Nej, varför?
2. Tycker du att den här datainsamlingen är representativ för motsvara att enhetstestandet
under projektet?
˝ Ja
˝ Nej, varför?
3. Vilken av de tre förhållningssättet som använts under denna datainsamling representerar bäst hur du har använt dig av enhetstestning under projektetsgång?
˝ Testdriven design, det vill säga testfall före kodande
˝ Testfall kontinerligt under kodandet
˝ Testfall först efter att koden var färdigskriven
4. Vilket av följande påståenden skulle du säga passar bäst in på dig i ditt arbete med
enhetstestning?
˝ Jag tycker att enhetstestningen har varit till stor hjälp för att lösa problem under
projektets gång.
˝ Jag tycker att enhetstestningen har varit till någon hjälp för att lösa problem under
projektets gång.
˝ Jag tycker att enhetstestningen varken har varit till nytta eller något hinder när jag
löste uppgifterna under projektets gång.
˝ Jag tycker att enhetstestning har varit ett jobbigt moment som bara måste göras
˝ Jag tycker att enhetstestning har varit ett hinder under projektets gång
Om datainsamlingen
5. Om du skulle uppskatta svårighetsgraden av uppgifterna på en skala 1-5, där 1 är
väldigt enkel och 5 är väldigt svår:
˝ Uppvärmningsuppgift:
˝ Uppgift 1:
˝ Uppgift 2:
˝ Uppgift 3:
144
6. Uppfattade du att något förhållningssätt till enhetstestning underlättade vid lösning av
någon uppgift? I så fall vilket förhållningssätt (Du kan välja flera förhållningssätt):
˝ Nej.
˝ Ja, skriva testfallen först.
˝ Ja, skriva testfallen kontinuerligt under kodandets gång.
˝ Ja, skriva testfallen efter kodandet.
˝ Ja, alla förhållningsätt bidrog.
7. Uppfattade du att något förhållningssätt till enhetstestning försvårade lösningen av någon uppgift? I så fall vilket förhållningssätt? (Du kan välja flera alternativ):
˝ Nej.
˝ Ja, skriva testfallen först.
˝ Ja, skriva testfallen kontinuerligt under kodandets gång.
˝ Ja, skriva testfallen efter kodandet.
˝ Ja, alla förhållningssätt bidrog.
8. Övriga kommentarer:
145
Bilaga 7 Resultat från enkät om daily
Scrum
Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?
• Tycker det passar bra eftersom vi inte jobbar heltid med projektet och man då ibland
har vissa dagar då man inte gör nånting.
• Bra! I och med att det inte hinner hända så mycket på två dagar så räcker det.
• Jag tycker det varit rimligt i förhållande till den mängd arbete vi lagt ner i projektet,
åtminstone tidigare. Det är möjligt att det varit bättre att ha alla dagar nu på slutet när
det arbetas intensivt.
• bra sett till hur ofta det finns något att uppdatera. känns som om varannan dag har
gjort att det inte riktigt känns integrerat
• Tillräckligt med varannan dag, blir lite tjatigt annars och händer inte så mycket mellan
varje gång
• Bra! Varannan dag borde man ha saker att skriva. Efter varje dag skulle det bara bli
massa upprepningar.
Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?
• Enkelt och smidigt. Skönt att inte behöva vänta på folk för att kunna rapportera.
• Bra. Det hade varit väldigt jobbigt att hitta en tid då alla hade kunnat vara med.
• Det har fungerat bra. Saknar dock diskussion bland medlemmar som kan uppstå efter
avslutat möte, känns som att en del information går förlorad eftersom kommunikationen sker i textform och inte face-to-face.
• praktiskt. men kommer förespråka face-to-face eller skype för framtida projekt
• Har fungerat jättebra, skönt att själv kunna bestämma när man ska skriva/läsa. Skulle
ha känts onödigt att samla alla för 15min varje dag när läsa går lika bra, även om man
kanske missar lite det trevliga med att träffas ansikte mot ansikte.
• Mycket bra! Jag tycker om när man gör saker så enkla som möjligt. Skulle vara jobbigt
att behöva ta sig till skolan om man egentligen vill sitta hemma.
146
Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?
• Hur bra som helst!
• Fantastiskt.
• Tycker att det har fungerat bra, känner inte till någon lösning jag tror skulle fungerat
bättre när vi valt att ha virtuella möten.
• geekbot och slack har fungerat väldigt bra! slackbot kritik: borde kunna fråga om hjälp
under en pågående report
• Geekbot har fungerat bra, skönt att få en påminnelse automatiskt. Han ställer alltid rätt
frågor!
• Exemplariskt!
Finns det något i vår variant av daily Scrum som du tror hade fungerat bättre på något
annat sätt? Om ja, hur då?
• Om det hade varit tydligare vilka som inte gjort scrum, som det är nu kan folk glömmas
bort.
• Nej.
• Jag tror vi hade fått ut mer av mötena om vi haft fysiska sådana, men samtidigt så hade
det blivit svårt i praktiken. Så mitt svar blir nej.
• ställer mig tveksam till att hålla dem virtuellt
• Om alla hade postat en selfie tillsammans med sin uppdatering!
• Det hade varit spännande att på ett enkelt sätt få ut en sammanfattningen över sina
egna daily scrum under en lång period. Detta för att leta efter mönster i sitt arbete.
147