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 ([email protected]), 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
© Copyright 2024