Linköpings universitet
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
Kumpu-lainen, Erik Rönmark, Kristoffer Tennivaara, Victor Tranell
Handledare: Adrian Sidenvall Examinator: Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
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.
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.
Innehållsförteckning
Sammanfattning ii
Tillkännagivanden iii
I
Gemensamma erfarenheter och diskussion
1
1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Tidigare erfarenheter . . . 4 2.2 Kursen . . . 5 3 Teori 6 3.1 Underhållbarhet . . . 6 3.2 Användbarhet . . . 6 3.3 Mjukvara för enhetstestning . . . 7 3.4 Webbutvecklingsverktyg . . . 7 3.4.1 HTML . . . 7 3.4.2 CSS . . . 8 3.4.3 JavaScript . . . 8 3.5 Scrum . . . 8 3.5.1 Sprint . . . 9
3.5.2 Roller inom Scrum . . . 9
3.6 SEMAT kernel . . . 10 4 Metod 11 4.1 Förstudie . . . 11 4.2 Projektorganisation . . . 12 4.3 Arbetsmetod . . . 12 4.3.1 Modifierad Scrum . . . 12 4.3.2 Möten . . . 13 4.4 Gränssnittsdesign . . . 14
4.4.1 Prototypning . . . 14 4.4.2 Användbarhetstester . . . 14 4.4.3 Omröstningar . . . 14 4.5 Implementation . . . 14 4.5.1 Parprogrammering . . . 14 4.5.2 Kodgranskning . . . 15
4.5.3 Enhets- och integrationstestning . . . 15
4.6 Versionshantering . . . 15 4.7 Utvärdering . . . 16 4.7.1 Tidigare projekterfarenheter . . . 16 4.7.2 Iterationsutvärdering . . . 16 4.7.3 SEMAT kernel-genomgång . . . 16 5 Resultat 17 5.1 Gränssnittsdesign . . . 17 5.2 Systembeskrivning . . . 17 5.2.1 Dekrypteringverktygens uppbyggnad . . . 19 5.2.2 Informationsflöde i systemet . . . 19 5.2.3 Vidareutveckling . . . 20 5.3 Värde för kunden . . . 21 5.4 Gemensamma erfarenheter . . . 21
5.5 SEMAT kernel alphas . . . 21
5.6 Översikt över individuella bidrag . . . 21
6 Diskussion 24 6.1 Resultat . . . 24 6.1.1 Gränssnittsdesign . . . 24 6.1.2 Implementation . . . 25 6.1.3 Värde för kunden . . . 25 6.1.4 Erfarenheter . . . 27
6.1.5 SEMAT kernel alphas . . . 27
6.2 Metod för insamling av erfarenheter . . . 28
6.3 Arbetet i ett vidare sammanhang . . . 28
7 Slutsatser 29 7.1 Gränssnittsdesign . . . 29
7.2 Värde för kunden . . . 29
7.3 Erfarenheter . . . 30
7.4 SEMAT kernel alphas . . . 30
II Individuella bidrag
32
A Fredrik Bergstrand: JavaScript-ramverks effekt på underhållbarhet 33 A.1 Inledning . . . 33A.1.1 Syfte . . . 33
A.1.2 Frågeställning . . . 33
A.2 Bakgrund . . . 33
A.3 Teori . . . 34
A.3.1 Resursfördelning vid mjukvaruutveckling . . . 34
A.3.2 Komplexitetsmått . . . 34
A.3.3 Complexity-report . . . 34
A.4 Metod . . . 34
A.4.2 Mätning . . . 35 A.5 Resultat . . . 35 A.6 Diskussion . . . 35 A.6.1 Metod . . . 36 A.6.2 Felkällor . . . 36 A.6.3 Resultat . . . 36 A.7 Slutsatser . . . 37
B Kimberley French: Värdet av en prototyp 38 B.1 Inledning . . . 38 B.1.1 Syfte . . . 38 B.1.2 Frågeställning . . . 38 B.2 Bakgrund . . . 38 B.3 Teori . . . 39 B.3.1 Prototyper . . . 39
B.3.2 Designprocessen hos ett interaktivt system . . . 39
B.4 Metod . . . 40 B.4.1 Litteraturstudie . . . 40 B.4.2 Undersökning . . . 40 B.5 Resultat . . . 40 B.6 Diskussion . . . 42 B.6.1 Resultat . . . 42 B.6.2 Metod . . . 43 B.6.3 Teori . . . 43 B.7 Slutsatser . . . 43
C Rebecka Geijer Michaeli: Daily Scrum virtuellt via textbaserat verktyg 45 C.1 Inledning . . . 45 C.1.1 Syfte . . . 45 C.1.2 Frågeställning . . . 45 C.2 Bakgrund . . . 45 C.3 Teori . . . 46 C.3.1 Daily Scrum . . . 46
C.3.2 Direktkontakt från daily Scrum . . . 46
C.3.3 Virtuella möten . . . 46
C.3.4 Media Richness Theory . . . 46
C.4 Metod . . . 46 C.5 Resultat . . . 47 C.6 Diskussion . . . 47 C.6.1 Teori . . . 47 C.6.2 Resultat . . . 48 C.6.3 Metod . . . 48 C.7 Slutsatser . . . 48
D Eric Henziger: En utvärdering av parprogrammering och kodgranskning 49 D.1 Inledning . . . 49 D.1.1 Syfte . . . 49 D.1.2 Frågeställning . . . 49 D.2 Bakgrund . . . 49 D.3 Teori . . . 50 D.4 Metod . . . 50 D.4.1 Analys av gransknings-commits . . . 50 D.4.2 Enkätundersökning . . . 51
D.5 Resultat . . . 51 D.5.1 Analys av gransknings-commits . . . 52 D.5.2 Enkätundersökning . . . 52 D.6 Diskussion . . . 55 D.6.1 Resultat . . . 55 D.6.2 Metod . . . 56
D.6.3 Arbetet i ett vidare sammanhang . . . 56
D.7 Slutsatser . . . 57
E Oscar Johansson: Enhetstestningens påverkan på programmeringsprocessen 58 E.1 Inledning . . . 58 E.1.1 Syfte . . . 58 E.1.2 Frågeställning . . . 58 E.2 Bakgrund . . . 58 E.3 Teori . . . 59 E.3.1 Enhetstestning . . . 59
E.3.2 Testdriven utveckling . . . 59
E.4 Metod . . . 60
E.4.1 Upplägg av datainsamling . . . 60
E.4.2 Uppgifterna . . . 60
E.4.3 Enkät . . . 61
E.4.4 Förhållningssätt till enhetstestning . . . 61
E.5 Resultat . . . 61
E.6 Diskussion . . . 63
E.7 Slutsatser . . . 64
F Robert Kumpulainen: Effekten av en branching model i ett litet utvecklingsprojekt 65 F.1 Inledning . . . 65 F.1.1 Syfte . . . 65 F.1.2 Frågeställning . . . 65 F.2 Bakgrund . . . 65 F.3 Teori . . . 66 F.3.1 Git . . . 66 F.3.2 Greningsmodeller . . . 66
F.3.3 Distribuerade och centraliserade versionshanteringssystem . . . 67
F.3.4 Arbetsflöden . . . 67 F.4 Metod . . . 67 F.4.1 Fallstudie . . . 67 F.4.2 Greningsmodellens framgång . . . 67 F.5 Resultat . . . 68 F.5.1 Fallstudie . . . 68 F.5.2 Greningsmodellens framgång . . . 68 F.6 Diskussion . . . 69 F.6.1 Metod . . . 69 F.6.2 Resultat . . . 69 F.7 Slutsatser . . . 70
G Erik Rönmark: Kvalitetssäkrande processer och produktkvalitet i ett litet utveck-lingsprojekt 71 G.1 Inledning . . . 71
G.1.1 Syfte . . . 71
G.1.2 Frågeställning . . . 71
G.2 Bakgrund . . . 71
G.3 Teori . . . 72
G.3.1 Kodgranskning . . . 72
G.3.2 Rader kod som mätdata . . . 72
G.4 Metod . . . 72 G.4.1 Kodgranskning . . . 72 G.4.2 Användartest . . . 72 G.4.3 Utvärdering . . . 73 G.5 Resultat . . . 73 G.5.1 Kodgranskning . . . 73 G.5.2 Användartest . . . 74 G.5.3 Utvärderingar . . . 74 G.6 Diskussion . . . 74 G.7 Slutsatser . . . 74
H Kristoffer Tennivaara: Metoder och processer för grafiska användargränssnitt 76 H.1 Inledning . . . 76 H.1.1 Syfte . . . 76 H.1.2 Frågeställning . . . 76 H.1.3 Avgränsningar . . . 76 H.2 Bakgrund . . . 76 H.3 Teori . . . 77 H.3.1 Användbarhet . . . 77 H.3.2 Designbeslut . . . 77
H.3.3 Metoder för att utvärdera ett användargränssnitt . . . 78
H.4 Metod . . . 78 H.4.1 Litteraturstudie . . . 78 H.4.2 Projekt . . . 79 H.5 Resultat . . . 79 H.5.1 Användbarhet . . . 79 H.5.2 Designbeslut . . . 79
H.5.3 Metoder för att utvärdera ett användargränssnitt . . . 80
H.6 Diskussion . . . 80
H.6.1 Resultat . . . 80
H.6.2 Metod . . . 80
H.7 Slutsatser . . . 81
I Victor Tranell: Kravhantering med Scrum 82 I.1 Inledning . . . 82
I.1.1 Syfte . . . 82
I.1.2 Frågeställning . . . 82
I.2 Bakgrund . . . 82
I.3 Teori . . . 82
I.3.1 Traditionell kravhantering . . . 83
I.3.2 Agil kravhantering . . . 83
I.3.3 Fördelar och nackdelar med agil kravhantering . . . 83
I.4 Metod . . . 84 I.4.1 Litteraturstudie . . . 84 I.4.2 Projekt . . . 84 I.5 Resultat . . . 84 I.6 Diskussion . . . 85 I.6.1 Litteratursammanställning . . . 86 I.7 Slutsatser . . . 86
Litteratur 87
Bilaga 1 Sammanställning av tidigare erfarenheter 91
Bilaga 2 Sammanställning av iterationsutvärderingar 94
2.1 Förstudie . . . 94 2.1.1 Fullständig sammanställning . . . 94 2.1.2 Förbättringsförslag . . . 99 2.2 Iteration 1 . . . 100 2.2.1 Fullständig sammanställning . . . 100 2.2.2 Förbättringsförslag . . . 109 2.3 Iteration 2 . . . 110 2.3.1 Fullständig sammanställning . . . 110 2.3.2 Förbättringsförslag . . . 114 2.4 Iteration 3 . . . 115 2.4.1 Fullständig sammanfattning . . . 115 2.4.2 Sammanställning från diskussion . . . 122 Bilaga 3 Complexity-report-sammanfattningar 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
Del I
1
Inledning
Den här rapporten beskriver ett projektarbete i kursen TDDD96 Kandidatprojekt i pro-gramvaruutveckling 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 utveck-ling 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. Sys-temet 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änss-nittet med avseende på användbarhet?
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 ver-sion 38.6.0. Programmet behövde inte innehålla någon information om hur de olika krypter-ingsmetoderna 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 rap-portens tyngdpunkt ligger gällande implementationen av systemet och dess konsekvenser.
2
Bakgrund
Gruppen för informationskodning vid ISY ger en kurs i kryptoteknik. I kursen får stu-denterna lära sig grunderna i kryptoanalys. Som ett moment i kursen har stustu-denterna en laboration där de får möjlighet att studera olika krypteringstekniker och dekryptera medde-landen 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 upp-datering. 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är-fö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å civilingen-jö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.
2.2. Kursen
Projektmedlemmarna hade också flera bra tidigare erfarenheter, bland andra just att parpro-grammering och utbildningstillfällen varit givande och underlättat kommunikationen i grup-pen. 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 programvaruutveck-ling för studenter som studerar civiprogramvaruutveck-lingenjö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.
3
Teori
Detta kapitel innehåller teori som är relevant för att förstå innehållet i rapporten. Inled-ningsvis 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. Mjuk-varans 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)
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 app-likation. [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 struk-turen 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]
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 struk-tur 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. Han-dlingar 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älvorgan-iserande 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å sys-temet, ofta på följande form:
3.5. Scrum
Användarberättelser används för att definiera programfunktioner, vilka sorteras efter prior-itet 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 visualis-era 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 kolumn-erna 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 program-funktioner 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
övergri-pande 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är-vara vid alla sprint reviews, och genom att ha huvudansvar för projektets product back-log.
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 sys-temet som byggs.
• Intressenter – Rör alla inblandade i projektet vilket innefattar kund, utvecklare, in-vesterare 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 behand-las 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.
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 itera-tioner, 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 grup-pen 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 slut-produktens 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 pro-jektet, 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.
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 han-dledaren.
• 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 skrivan-det 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 pro-jektet. Detta har inneburit att välja vilka verktyg för versionshantering som skulle an-vä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
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ör-middag. 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 projektmedlem-marna möjlighet att själva fylla i om de hade något att ta upp för diskussion eller ett medde-lande 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än-delse 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 hand-ledarmö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.
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 anteck-ningarna 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 projekt-gruppen 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 an-vä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 an-vä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 an-tecknades 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 kom-mentarer. 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, lo-gotyp, 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 un-der de olika projektfaserna.
4.5.1
Parprogrammering
Under iteration 1 och 2 skedde utvecklingen huvudsakligen genom en form av parprogram-mering. 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 da-torer där själva skrivandet av kod skedde på den ena datorn medan den andra datorn använ-des för att göra sökningar i dokumentation och på internet. Parprogrammeringen använanvän-des
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ör-frågan om granskning. Förför-frå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 kom-menteringen 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 anslut-ning till den felaktiga koden skriva en kommentar enligt kodexempel 4.1. När granskanslut-ningen 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 au-tomatisk enhetstestning. Med auau-tomatisk avses i det här fallet att samtliga enhetstester kan exekveras med ett knapptryck från utvecklaren. Enhetstesterna skrevs med hjälp av ramver-ket 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 tydlig-gö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 versionshanter-ing 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 kodkonflik-ter som kan uppstå. Reglerna gällande utgrening för den tillämpade greningsmodellen sam-manfattas av tabell 4.1. Effekten av denna beskrivs i individuell del F.
Tabell 4.1: Utgreningsregler. Rules for different
branches
Feature branch Release branch Hotfix branch
May branch off develop develop master
Must merge back develop develop & master develop & master
May merge back - - release
Naming convention Anything except master, develop, release-* or hotfix-*
4.7. Utvärdering
4.7
Utvärdering
Utvärdering och erfarenhetsinsamling om projektarbetet utfördes regelbundet med grup-pens 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 sam-manstä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 granskn-ing 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.
5
Resultat
I detta avsnitt redovisas resultaten från projektets olika delar. Först behandlas hur produk-tens 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ändar-grä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. Proto-typerna 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 be-hö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
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 dekrypter-ingsverktyget 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 an-vä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 efter-som systemet då återställer det senast använda tillståndet hos statistikpanelen i det nyligen aktiverade verktyget.
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änss-nitt.
• [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änss-nittet 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 modifika-tioner av användargränssnittet flyttas den funktionaliteten från manager-filen till verk-tygets 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 an-vä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 be-hö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änss-nittet. 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 an-vänds en eventdriven modell. Exempel på tillståndsvariabler i systemet är det aktiva språket
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 rel-evanta 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 till-stå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 dekrypteringsverk-tygs 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 ingsverktygen, men eftersom statistikverktygen är mindre komplicerade än dekrypter-ingsverktygen 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 reg-istreras. 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 namngivn-ingskonventioner som dessa. På ett liknande sätt kan ett nytt dekrypteringsverktyg enkelt
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, till-sammans 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 MIT-licensen, 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 utvecklingspro-cess gruppen tillämpade. Det lades ingen tid under iterationerna på att utvärdera eller an-vä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äm-föra systemet i den här rapporten med andra system vilka utvecklats med hjälp av ett
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 projekt-grupper 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 ef-fekter framkom som bland annat berörde inflexibilitet hos parprogrammering och obe-hag 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 programmer-ingsprocessen, 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 utveckling-shistorik. 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
utveck-lingsprojekt
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änd-barheten 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.
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.
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änss-nittsdesignen behandlas. Därefter berörs den valda implementationen. Sedan tas produktens värde för kunden upp. Gruppens redovisade erfarenheter diskuteras och avslutningsvis be-handlas 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änd-bart. 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 pro-duktens 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.
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. Konven-tioner ä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.
