Linköpings universitet | Institutionen för datavetenskap
Kandidatarbete på grundnivå, 15hp | Datateknik
Vårterminen 2018 | LIU-IDA/LITH-EX-G--18/010--SE
Spårbarhetssystem för
sekretessuppgifter
–
Hantering av hemlig information har aldrig varit enklare
A traceability system for confidential information
–
Handling classified information has never been easier
Andreas Lundquist
Daniel Herzegh
David Hasselquist
Jennifer Lindgren
Johan Lind
Niklas Nilsson
Philip Bengtsson
Handledare : Erica Gavefalk 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 admi-nistrativ 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 upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. 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 unchang-ed for non-commercial research and unchang-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/.
© Andreas Lundquist Daniel Herzegh David Hasselquist Jennifer Lindgren Johan Lind Niklas Nilsson Philip Bengtsson
Sammanfattning
Denna rapport beskriver ett projektarbete som utfördes av sju studenter från civilingenjörs-programmen inom datateknik och mjukvaruteknik vid Linköpings universitet. Projektet ut-fördes i kursen TDDD96 Kandidatprojekt i mjukvaruutveckling under våren 2018. Syftet med projektet var att utveckla en webbapplikation till Sectra Communications AB som kan använ-das för att hantera och spåra tillgångar internt hos företaget. Under projektets utvecklingsfas följde projektgruppen en modifierad version av det agila systemutvecklingsramverket Sc-rum. Projektet resulterade i en fungerande webbapplikation som uppfyller de krav som togs fram tillsammans med Sectra Communications AB. Projektgruppen har utvecklat sina kun-skaper inom webbutveckling, agila metoder och att arbeta i grupp. Alla projektmedlemmar har fördjupat sig inom ett varsitt ämne kopplat till projektet, dessa individuella bidrag kan läsas i slutet av rapporten.
Författarens tack
Projektgruppen vill tacka våra kundkontakter Åsa Lindbäck Mattsson och Robert Kihlberg som har varit tillgängliga för att besvara frågor genom projektet och som gjort detta projekt möjligt. Vi vill tacka Kristian Sandahl och kursledningen för en mycket lärorik kurs.
Vi vill även rikta ett stort tack till vår handledare Erica Gavefalk som hjälpt och guidat oss genom projektet.
Innehåll
Figurer Tabeller Definitioner 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 2 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Uppgift . . . 32.2 Arbetsflödet kring hantering av kort och handlingar . . . 3
2.3 Sectras nuvarande verktyg för hantering av kort och handlingar . . . 5
2.4 Projektgruppens tidigare erfarenheter . . . 5
3 Teori 7 3.1 Arbetssätt för programvaruprojekt . . . 7
3.1.1 Scrum . . . 7
3.1.2 Git och GitLab . . . 8
3.1.3 Trello . . . 9 3.1.4 Slack . . . 9 3.1.5 Toggl . . . 9 3.1.6 Overleaf . . . 9 3.1.7 Google Drive . . . 10 3.1.8 Google Calendar . . . 10 3.2 En webbapplikations arkitektur . . . 10
3.3 Ramverk, verktyg och utvecklingsspråk . . . 10
3.3.1 TypeScript . . . 10
3.3.2 Angular 5 . . . 10
3.3.3 Material Design for Angular . . . 11
3.3.4 Bootstrap 4 . . . 11
3.3.5 Node.js . . . 11
3.3.6 MariaDB . . . 11
3.3.7 Visual Studio Code . . . 11
3.3.8 Protractor . . . 11
3.4 API . . . 11
3.5 Databasstruktur . . . 12
4.1 Projektmedlemmar och roller . . . 13
4.2 Dokumentation . . . 15
4.3 Utvecklingsmetodik . . . 16
4.3.1 Arbetssätt . . . 16
4.3.2 Kommunikation och samarbete . . . 17
4.3.3 Designarbete . . . 17
4.3.4 Kvalitetsarbete . . . 18
4.3.5 Utbildning . . . 18
4.3.6 Kravsammanställning, kontrakt och utvecklingsplan . . . 19
4.3.7 Testning . . . 19
4.3.8 Resurser . . . 19
4.3.9 Versionshantering . . . 19
4.3.10 Riskanalys . . . 20
4.4 Metod för att fånga erfarenheter . . . 20
5 Resultat 21 5.1 Systembeskrivning . . . 21 5.1.1 Ingående delsystem . . . 21 5.1.2 Systemanatomi . . . 22 5.1.3 Användarhantering . . . 22 5.1.4 UI-design . . . 23 5.1.5 UX-design . . . 24 5.1.6 PDF-generering . . . 31 5.1.7 Databasstruktur . . . 33 5.2 Värde för kunden . . . 37 5.3 Gemensamma erfarenheter . . . 37
5.4 Översikt över individuella bidrag . . . 38
5.4.1 Balans mellan olika testnivåer vid agil systemutveckling av Andreas Lundquist . . . 38
5.4.2 Kundinverkan vid agil mjukvaruutveckling av Daniel Herzegh . . . 38
5.4.3 Sårbarhet för Cross site scripting (XSS) i en webbapplikation av David Hasselquist . . . 38
5.4.4 Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren 38 5.4.5 Implementation av kontinuerlig leverans av Johan Lind . . . 38
5.4.6 Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson . . . 38
5.4.7 Vikten av kodstandarder och effektiv kod av Philip Bengtsson . . . 38
6 Diskussion 39 6.1 Resultat . . . 39
6.1.1 Alternativa implementationssätt . . . 39
6.1.2 Kvarstående arbete . . . 40
6.1.3 Utveckling sedan tidigare projekt . . . 40
6.1.4 Lärdomar inför framtiden . . . 40
6.2 Metod . . . 41
6.3 Arbetet i ett vidare sammanhang . . . 42
6.3.1 Miljöperspektiv . . . 42
6.3.2 Etiskt perspektiv . . . 42
6.3.3 Socialt perspektiv . . . 42
7 Slutsatser 43 7.1 Hur kan SecTrack implementeras så att värde för kunden skapas? . . . 43
7.2 Vilka erfarenheter kan dokumenteras från detta projekt som kan vara intres-santa för framtida projekt? . . . 43
7.3 Vilka stöd kan fås genom att skapa och följa upp en systemanatomi? . . . 43
7.4 Kan systemutvecklingen i projektet anpassas för att förenkla underhåll och vi-dareutveckling i framtiden? . . . 44
7.5 Leder ett agilt arbetssätt till att eventuella problem och förbättringsmöjligheter inom projektet uppmärksammas och kan åtgärdas? . . . 44
7.6 Projektets syfte . . . 44
A Balans mellan olika testnivåer vid agil systemutveckling av Andreas Lundquist 45 A.1 Inledning . . . 45 A.1.1 Syfte . . . 45 A.1.2 Frågeställningar . . . 45 A.2 Bakgrund . . . 45 A.3 Teori . . . 46 A.3.1 Testnivåer . . . 46 A.3.2 Vattenfallsmodellen . . . 46
A.3.3 Agil systemutveckling . . . 47
A.4 Metod . . . 47
A.5 Resultat . . . 48
A.5.1 Erfarenheter . . . 48
A.5.2 Insamlad data . . . 48
A.6 Diskussion . . . 49
A.7 Slutsatser . . . 50
B Kundnöjdhet vid agil programvaruutveckling av Daniel Herzegh 51 B.1 Inledning . . . 51 B.1.1 Syfte . . . 51 B.1.2 Frågeställning . . . 51 B.2 Bakgrund . . . 51 B.3 Teori . . . 52 B.3.1 Vattenfallsmodellen . . . 52 B.3.2 Scrum . . . 52 B.4 Metod . . . 52 B.4.1 Litteraturstudie . . . 52 B.4.2 Projektarbete . . . 53 B.5 Resultat . . . 53 B.5.1 Litteraturstudie . . . 53 B.5.2 Projektarbete . . . 54 B.6 Diskussion . . . 54 B.6.1 Resultat . . . 54 B.6.2 Metod . . . 55 B.7 Slutsatser . . . 55
C Sårbarhet för Cross site scripting (XSS) i en webbapplikation av David Hasselquist 57 C.1 Inledning . . . 57 C.1.1 Syfte . . . 57 C.1.2 Frågeställning . . . 57 C.2 Bakgrund . . . 58 C.3 Teori . . . 58 C.3.1 Definitioner . . . 58 C.3.2 XSS-kategorier . . . 59 C.4 Metod . . . 60 C.5 Resultat . . . 60
C.5.2 Sparad XSS . . . 61
C.5.3 DOM-baserad XSS . . . 63
C.5.4 Förhindrande av XSS . . . 64
C.6 Diskussion . . . 65
C.7 Slutsatser . . . 66
D Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren 68 D.1 Inledning . . . 68 D.1.1 Syfte . . . 68 D.1.2 Frågeställningar . . . 68 D.1.3 Avgränsningar . . . 69 D.2 Bakgrund . . . 69 D.3 Teori . . . 69 D.3.1 Hantering av data . . . 69 D.4 Metod . . . 70 D.4.1 Litteraturstudie . . . 70 D.4.2 Analys av SecTrack . . . 71 D.5 Resultat . . . 71
D.5.1 Metoder för att utföra SQL-injektioner . . . 71
D.5.2 Sårbarhet . . . 72 D.5.3 Säker databashantering . . . 72 D.5.4 SecTracks sårbarhet . . . 73 D.6 Diskussion . . . 73 D.6.1 Resultat . . . 73 D.6.2 Metod . . . 74 D.7 Slutsatser . . . 74 D.7.1 Frågeställning 1 . . . 74 D.7.2 Frågeställning 2 . . . 74 D.7.3 Frågeställning 3 . . . 75
E Implementation av kontinuerlig leverans av Johan Lind 76 E.1 Inledning . . . 76 E.1.1 Syfte . . . 76 E.1.2 Frågeställning . . . 76 E.2 Bakgrund . . . 76 E.3 Teori . . . 77 E.3.1 Versionshantering . . . 77
E.3.2 Agil mjukvaruutveckling . . . 77
E.4 Metod . . . 78
E.5 Resultat . . . 78
E.5.1 Information från litteraturstudien . . . 78
E.5.2 Gruppens erfarenheter . . . 79
E.6 Diskussion . . . 80
E.7 Slutsatser . . . 81
F Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson 82 F.1 Inledning . . . 82 F.1.1 Syfte . . . 82 F.1.2 Frågeställning . . . 82 F.1.3 Avgränsningar . . . 82 F.2 Bakgrund . . . 82 F.3 Teori . . . 83 F.3.1 Arbetsplatsens utformning . . . 83
F.3.2 Ergonomi vid datorarbete . . . 83
F.3.3 Ljud på en arbetsplats . . . 84
F.3.4 Ljus på en arbetsplats . . . 84
F.4 Metod . . . 85
F.4.1 Litteraturstudie . . . 85
F.4.2 Nuvarande och tidigare erfarenheter . . . 85
F.5 Resultat . . . 85
F.5.1 Litteraturstudie . . . 85
F.5.2 Nuvarande och tidigare erfarenheter . . . 86
F.6 Diskussion . . . 86
F.7 Slutsatser . . . 87
G Vikten av kodstandarder och effektiv kod av Philip Bengtsson 88 G.1 Inledning . . . 88
G.1.1 Syfte . . . 88
G.1.2 Frågeställningar . . . 88
G.2 Bakgrund . . . 88
G.3 Teori . . . 89
G.3.1 Exempel på innehåll i en kodstandard . . . 89
G.3.2 Energieffektivitet . . . 90 G.4 Metod . . . 90 G.5 Resultat . . . 90 G.5.1 Att ha en kodstandard . . . 90 G.5.2 Läsbarhet . . . 91 G.5.3 Energieffektiv kodning . . . 91 G.5.4 Egna erfarenheter . . . 92 G.6 Diskussion . . . 92 G.6.1 Källkritik . . . 93 G.7 Slutsatser . . . 94 G.7.1 Frågeställning 1 och 2 . . . 94 G.7.2 Frågeställning 3 . . . 94 G.7.3 Frågeställning 4 . . . 94 Litteratur 95
Figurer
2.1 Arbetsflödet kring kort och handlingar . . . 4
2.2 Exempelvy av register med aktiva kort . . . 5
2.3 Exempelvy av register med handlingar . . . 5
4.1 Ett schema över projektets organisation . . . 14
4.2 Första designskissen över webbapplikationen . . . 17
4.3 Designskiss av en kvittens . . . 18
5.1 Ingående delsystem . . . 21
5.2 Systemanatomi . . . 22
5.3 Meny till vänster i webbapplikationen . . . 24
5.4 Tabell med information om handlingar . . . 24
5.5 Inloggningssida . . . 25
5.6 Tabell med kort . . . 25
5.7 Tabell med kort filtrerat på ett kort-id . . . 26
5.8 Modal för att kvittera ut ett kort . . . 26
5.9 Modal för val gällande PDF-dokument . . . 27
5.10 Inventering . . . 27
5.11 Sortering efter typ av kort . . . 28
5.12 Alla kort av typen GEID är markerade . . . 28
5.13 Valmöjlighet vid generering av PDF-dokument från inventeringstabellen . . . 29
5.14 Alla kort av typen GEID har nu blivit inventerade . . . 29
5.15 Tabell med handlingar . . . 30
5.16 Modal för lägg till ny handling . . . 30
5.17 Modal för detaljer om en handling . . . 31
5.18 Kvittensmall användarkopia . . . 32
5.19 Inventeringsmall . . . 33
5.20 Databasens primära tabeller . . . 34
5.21 Databasens sekundära tabeller . . . 34
5.22 Fullständig struktur med länkar för tabellen Dokument . . . 35
A.1 Pyramidmodell för testnivåer . . . 48
A.2 Omvänd pyramidmodell för testnivåer . . . 49
Tabeller
4.1 Utvecklingsroller . . . 13 4.2 Dokumentation . . . 15 4.3 Standarder . . . 15 4.4 Sprintplan . . . 16 4.5 Riskanalys . . . 20Definitioner
I det här avsnittet förklaras begrepp som används i rapporten men vars innebörd inte antas vara självklara för läsaren.
• Webbapplikation: En applikation som körs i en webbläsare.
• Back-end: Mjukvaran som utgör serverfunktionaliteten i en webbapplikation.
• Front-end: Mjukvaran som utgör presentationslagret, det vill säga det som användaren ser och interagerar med i en webbapplikation.
• Single-page application: En webbapplikation som vid interaktion dynamiskt skriver om webbsidan istället för att ladda in nya webbsidor från en server.
• Modal: Ett fönster som visas ovanpå en webbapplikations huvudfönster. • UX-design: Design av användarupplevelse (eng. User Experience design). • UI-design: Design av användargränssnitt (eng. User Interface design).
• Structured Query Language (SQL): Ett programmeringsspråk som används för att hämta och modifiera data i databaser.
• MySQL: En relationsbaserad databashanterare baserad på SQL. • Sass: Ett skriptspråk som kompileras till CSS.
• Hypertext Markup Language (HTML): Ett standardiserat märkspråk som används för att skapa webbsidor och webbapplikationer.
• Cascading Style Sheets (CSS): Ett programmeringsspråk som används för att beskriva presentationen av ett dokument skrivet i HTML.
• JavaScript: Ett prototypbaserat skriptspråk som används till webbsidor och webbap-plikationer.
• ECMAScript: En skriptspråksspecificering skapad för att standardisera JavaScript. • LaTeX: Ett typsättningssystem som används vid dokumentskrivning.
• Versionshantering: Ett sätt att spåra ändringar och återskapa äldre versioner av till exempel dokument eller kod.
• Git: Ett versionshanteringsverktyg för kod.
• bcrypt: En hashfunktion för att kryptera lösenordssträngar. • Kort: Ett fysiskt kort med ett chip som innehåller information.
Tabeller
• Handling: Ett pappersdokument som innehåller information.
• Leveranser: En handling som representerar en leverans som Sectra Communications AB gjort till ett annat företag.
• Inventering: En kontroll utförd av en administratör för att verifiera att ett kort eller en handling fortfarande finns tillgänglig.
• Egenkontroll: En kontroll utförd av en användare för att verifiera att ett kort eller en handling fortfarande finns tillgänglig.
1
Inledning
Denna rapport beskriver ett projektarbete som utfördes i kursen TDDD96 Kandidatprojekt i mjukvaruutveckling under våren 2018. Projektgruppen bestod av sju studenter från ci-vilingenjörsprogrammen inom datateknik och mjukvaruteknik vid Linköpings universitet. Produkten som projektgruppen utvecklade beställdes av Sectra Communications AB. Pro-jektgruppen har valt att kalla produkten SecTrack, som efter utvecklingen publicerades som öppen källkod under Apache2-licens.
I rapporten behandlas bakgrunden till projektet, hur utvecklingen gick till, vad resultatet blev samt en diskussion kring detta. Slutligen redovisas sju utredningar som utförts enskilt av varje projektmedlem.
1.1
Motivering
Det finns företag och organisationer som har tillgångar de behöver spåra och redovisa han-teringen av. Tillgångarna skulle till exempel kunna vara sekretessbelagd information, från företagets kunder, som behövs för att utveckla olika produkter. Dessa kan vid olika skeden behöva byta ansvarig ägare inom företaget och dessa byten måste då registreras. Vissa företag saknar lämpliga system för att sköta detta på ett enkelt och smidigt sätt.
En lösning som används på företag idag är att förlita sig på en administratör, som är ansvarig för att hålla koll på var samtliga tillgångar befinner sig samt har befunnit sig vid varje given tidpunkt. Med få tillgångar att spåra och få platser som en tillgång kan befinna sig på behö-ver detta inte vara ohanterligt. Men allt eftersom tillgångarna och platserna de kan befinna sig på blir fler kan pappershantering lätt bli rörig och oorganiserad. När historik över hur tillgångarna hanterats dessutom måste redovisas blir det nästintill omöjligt utan ett anpassat system.
Administratörens nuvarande system för att spåra tillgångar kan exempelvis bestå av excel-dokument och papper som fylls i. Detta system är inte nödvändigtvis användarvänligt för en användare som inte känner till alla funktioner i excelprogrammet, och även för en van användare kan det lätt bli fel när information ska lägga till eller modifieras. Systemet saknar dessutom stöd för multipla användare med olika behörighetsnivåer.
Det finns därmed ett behov av att utforma ett anpassat och användarvänligt system som kan underlätta hanteringen av ett företags tillgångar. Ett sådant system skulle spara in på resurser och arbetstid som behöver läggas på det administrativa arbetet. Ur ett hållbarhetsperspektiv skulle ett nytt system som utvecklas kunna fungera helt digitalt, vilket för företag som redan använder många datorer inte kommer att öka energiförbrukningen nämnvärt.
1.2. Syfte
1.2
Syfte
Syftet med detta kandidatprojekt var att skapa och utveckla en webbapplikation, med nam-net SecTrack, till Sectra Communications AB som kan användas för att hantera och spåra tillgångar internt hos företaget. Viktiga egenskaper hos systemet var användbarhet, stabilitet samt goda underhålls- och vidareutvecklingsmöjligheter.
Projektet var en del av kursen TDDD96, Kandidatprojekt i programvaruutveckling, på Lin-köpings universitet och utfördes av projektmedlemmarna i utbildande syfte. Projektmedlem-marna hade som mål att lära sig mer om programutveckling, webbutveckling, Scrum och ar-bete inom ett större projekt. Målet med projektet var även att leverera en fungerande produkt som skulle användas av Sectra Communications AB.
Syftet med denna rapport är att beskriva bakgrunden till projektet, utvecklingsprocessen, resultatet samt att diskutera projektet och de lärdomar som projektgruppen samlat in.
1.3
Frågeställning
1. Hur kan SecTrack implementeras så att värde för kunden skapas?
2. Vilka erfarenheter kan dokumenteras från detta projekt som kan vara intressanta för framtida projekt?
3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi?
4. Kan systemutvecklingen i projektet anpassas för att förenkla underhåll och vidareut-veckling i framtiden?
5. Leder ett agilt arbetssätt till att eventuella problem och förbättringsmöjligheter inom projektet uppmärksammas och kan åtgärdas?
1.4
Avgränsningar
Den tid som fanns att lägga på projektet var begränsad till 2800 timmar, det vill säga 400 timmar per projektmedlem. I denna tid ingick planering, utbildning, utveckling och doku-mentation.
Projektgruppen skulle endast producera öppen källkod vilket innebar att endast öppen källkod användes i utvecklingen.
Applikationen är utformad specifikt efter kundens behov, därför är bland annat tabeller-na i databasen skräddarsydda för att uppfylla dem.
Applikationen är endast utformad för att fungera på normalstora datorskärmar, då det från kundens sida inte fanns behov av att använda applikationen på till exempel mobiltelefo-ner eller surfplattor. Därmed har inga designbeslut tagits med hänsyn till mobilanvändning. Språket i användargränssnittet är svenska eftersom det var ett kundönskemål. Webbap-plikationen är utvecklad för att stödja dagens moderna webbläsare, exempelvis Google Chrome version 65.0.3325.181 och Firefox version 59.0.2.
Produkten är avsedd för att köras på en server i ett säkert och isolerat nätverk. Back-end är anpassad till att köras på Ubuntu version 16.04 då det var ett kundkrav.
2
Bakgrund
Det här kapitlet ger en kort beskrivning av kunden, deras nuvarande verktyg och deras ar-betsflöde kring handhavande av data samt deras behov av en produkt som SecTrack. Utöver detta ges även en övergripande beskrivning av projektgruppens tidigare erfarenheter av att arbeta inom projekt.
2.1
Uppgift
Kunden är företaget Sectra Communications AB som fortsättningsvis benämns som Sect-ra i denna Sect-rapport. SectSect-ra erbjuder lösningar för säker kommunikation [1]. DeSect-ras kunder inkluderar bland andra europeiska försvarsdepartement, Försvarsmakten samt andra myn-digheter. Sectras produkter används av kunder från ett 50-tal olika länder.
I arbetet handhar Sectra känslig data som de fått från sina kunder. Denna data behöver spåras internt på företaget för att ansvarig personal alltid ska veta var datan befunnit sig. Systemet som hittills använts är mödosamt att underhålla. Dessutom saknas viss funktiona-litet som kvittensgenerering, inloggning för användare och loggning av händelser där bland annat utlämningar till användare, återlämningar och kontroller ingår. På grund av detta efterfrågade Sectra ett nytt och bättre system för inventering och spårning av handlingar och kort än det befintliga system de har för tillfället.
2.2
Arbetsflödet kring hantering av kort och handlingar
För att förstå varför systemet som projektgruppen utvecklat är designat som det är och var det passar in i Sectras arbete kommer denna sektion att kartlägga hur arbetsflödet kring do-kumenten fungerar.
2.2. Arbetsflödet kring hantering av kort och handlingar
Figur 2.1: Arbetsflödet kring kort och handlingar
I följande lista beskrivs arbetsflödet som är illustrerat i figur 2.1.
1. En arbetsgrupp inom Sectra arbetar med ett projekt åt en kund.
2. Gruppen behöver konfidentiell data från kunden för en del av projektet och skickar en förfrågan för denna data.
3. Kunden skickar denna data till Sectra.
4. Registratorn tar emot och registrerar att denna data, i form av ett kort eller en handling, nu finns hos dem.
5. Ansvarig gruppmedlem hämtar ut datan hos registratorn som registrerar att datan är placerad hos denna gruppmedlem.
6. En gång om året inventerar registratorn samtliga kort och handlingar inom företaget. 7. Ansvarig för datan ska genomföra egenkontroller en gång varje kvartal för att bekräfta
innehav av datan.
8. När datan inte längre behövs lämnas den in till registratorn och arkiveras och förstörs eventuellt, om den inte ska användas av en annan användare inom företaget.
2.3. Sectras nuvarande verktyg för hantering av kort och handlingar
2.3
Sectras nuvarande verktyg för hantering av kort och handlingar
När registratorn tar emot data från kunder registreras detta i ett register över aktiva kort eller aktiva handlingar. Dessa register existerar i form av exceldokument. Figur 2.2 och figur 2.3 visar exempelvyer, som tillhandahölls av kunden, över registret med aktiva kort respektive registret med handlingar. När ett kort återlämnas från en användare till registratorn motsva-rar detta i systemet att klippa ut den kortraden och klistra in det i ett annat exceldokument som är ett register över återlämnade kort.Det som saknas helt är ett verktyg för kvittenser och kvittensgenerering vilket innebär ansvars- och uppföljningsproblem kring ett kort eller en handling. Med hjälp av kvittenser blir det tydligt vem som har ansvar för viss data och var datan kan finnas.
Figur 2.2: Exempelvy av register med aktiva kort
Figur 2.3: Exempelvy av register med handlingar
2.4
Projektgruppens tidigare erfarenheter
Projektgruppens sju medlemmar har tidigare arbetat i projekt med varierande utsträckning och gruppstorlek. Dessa erfarenheter togs i beaktande vid starten av projektet innan någon utveckling hade påbörjats. De punkter gruppen gemensamt tyckte var viktiga inför arbetet med det här projektet var god och öppen kommunikation, tydlig kodstruktur, gemensamma standarder och kontinuerlig tidsplanering.
Gruppens tidigare erfarenheter av projekt har bland annat visat hur viktigt det är att munikationen mellan gruppmedlemmarna fungerar. I tidigare projekt har bristfällig kom-munikation lett till att flera personer arbetat på överlappande områden och uppgifter, vilket inneburit bortslösade arbetstimmar. Det var därför viktigt för varje gruppmedlem att veta vad andra gruppmedlemmar arbetade på för att undvika duplicerat arbete. I samma anda har tidigare projekt lidit när gruppmedlemmar väntat med att be om hjälp eller berättat att de ligger efter med sin del i arbetet. Övriga gruppmedlemmar var inte medvetna om proble-men och tid för att åtgärda dem gick till spillo. Detta problem tros kunna åtgärdas genom att
2.4. Projektgruppens tidigare erfarenheter
främja en öppen och ickedömande attityd hos varje gruppmedlem för att på så sätt öppna upp för god kommunikation där medlemmar frågar varandra om hjälp eller råd när något är problematiskt.
Utöver detta har gruppen även kommit fram till att det är av värde att ha en tydlig struktur i hur arbetet ska utföras och att ha en tydlig tidsplan över när delmoment ska utföras. Gruppen har även beslutat att alla ändringar av programkoden ska redovisas med tydliga meddelan-den som beskriver dessa. Detta för att alla gruppmedlemmar enkelt ska kunna följa alla delar av utvecklingsprocessen.
3
Teori
Det här kapitlet beskriver teorin som ligger till grund för rapporten. Läsaren bör känna till hur arbetssätt kan utformas efter utvecklingsramverket Scrum och underlättas av verktyg som till exempel Git, Trello och Slack. Förutom teori som relaterar till arbetssätt beskrivs ramverk och verktyg för utveckling, vad ett API är, hur en databas är strukturerad och hur en systemanatomi kan användas.
3.1
Arbetssätt för programvaruprojekt
Det här delkapitlet beskriver teorin bakom projektgruppens arbetssätt. Här beskrivs ut-vecklingsramverket Scrum som projektgruppens utvecklingsprocess var inspirerad av och versionshanteringsverktyget Git som användes under utvecklingen av webbapplikationen. Andra verktyg som beskrivs här är Trello för fördelning av arbetsuppgifter, Slack för kom-munikation och Toggl för tidsrapportering. Vidare beskrivs Overleaf för dokumentskrivning i LaTeX, Google Drive för att lagra viktiga projektfiler samt Google Calendar för att hålla koll på gemensamma möten.
3.1.1
Scrum
Scrum är ett agilt utvecklingsramverk vars huvuddelar beskrivs i det här delkapitlet. Produktstacken
Produktstacken (eng. Product Backlog) är projektgruppens samling av aktiviteter som ska ut-föras [2]. Stacken är sorterad efter prioritet. Tillägg, förändringar och omprioriteringar får göras kontinuerligt under projektets gång.
Sprintar
Enligt Scrum-modellen delas allt arbete upp i iterationer som även kallas sprintar [2]. Läng-den på en sprint kan variera men bör generellt sett vara Läng-densamma genom hela projektet. Varje sprint har alltid ett start- och slutdatum.
Sprintplanering
Inför varje sprint hålls en sprintplanering där alla uppgifter i produktstacken ges en tidses-timering i timmar för hur lång tid den uppskattningsvis tar att slutföra [2]. Med hjälp av tidsestimeringarna och prioriteringsordningen i stacken beslutar projektgruppen vilka upp-gifter som ska utföras. Det rekommenderas att bryta ned uppupp-gifter i mindre aktiviteter under sprintplaneringen för att få en bra uppfattning om de är lämpade för den tänka sprinten.
3.1. Arbetssätt för programvaruprojekt
Sprintgenomförande
När sprintplaneringen är gjord är det ingen som berättar för projektmedlemmarna hur de ska utföra uppgifterna som ingår i sprinten [2]. Det är upp till dem själva att dela upp arbetet och besluta hur de vill genomföra det.
Dagliga Scrummöten
Varje dag hålls ett Scrummöte som helst ska vara 15 minuter eller kortare [2]. Det är vanligt att varje medlem svarar på tre frågor:
• Vad har jag åstadkommit sedan det senaste Scrummötet? • Vad planerar jag att göra innan nästa Scrummöte? • Vad är hindren som stoppar mig från att göra framsteg?
Genom att alla svarar på dessa frågor får gruppen en helhetsbild av vad som händer, vilka framsteg som görs, vilka problem som finns och om de vill göra justeringar i dagens plane-ring.
Sprintgenomgång
Efter varje avslutad sprint går projektmedlemmarna igenom och inspekterar vad som gjorts under den gångna sprinten [2]. Det är viktigt att en konversation hålls med eventuella kunder eller sponsorer för att ge dem en chans att utvärdera nya funktioner och guida den framtida utvecklingen i rätt riktning. Sprintgenomgången innebär en tvåvägskommunikation mellan utvecklare och intressenter på så sätt att intressenterna får insikt i utvecklingen och utveck-larna får insikt i intressenternas önskemål.
Sprintutvärdering
Till sist utför gruppen en utvärdering med avseende på processen [2]. Syftet är att lyfta fram vad som fungerat bra och mindre bra under sprinten som varit. På så sätt kan projektgruppen göra justeringar i processen så att nästa sprint kan fungera bättre. Efter sprintutvärderingen börjar processen om med en ny sprintplanering.
3.1.2
Git och GitLab
Git är ett versionshanteringssystem, som används för att spara historiken av ändringar av ett projekts kodbas och som tillåter flera utvecklare att samtidigt skriva kod till projektet [3]. Git tillhör kategorin distribuerade versionshanteringssystem, vilket innebär att varje använ-dare har en lokal kopia av projektets fullständiga historik på sin maskin, till skillnad från ett centraliserat versionshanteringssystem där detta endast lagras på en central server [3]. Utö-ver dessa lokala kopior kopplas Git typiskt även till ett centralt webb-arkiv som används för att samordna koden mellan flera utvecklare.
Grundidén är att varje utvecklare kan hämta den senaste versionen av koden, för att sedan göra sina egna ändringar och överföra dem till det centrala arkivet så att andra utvecklare kan ta del av dem [3]. Ifall kod raderas men sedan behövs igen är den inte förlorad, utan det är enkelt att gå tillbaka i historiken för att återhämta den. Det är även vanligt att viss funktio-nalitet slutar fungera när nya ändringar introduceras, vilket gör det mycket användbart att
3.1. Arbetssätt för programvaruprojekt
Git har stöd för att skapa grenar, som används för att hålla projektet strukturerat [3]. En gren kan ses som en kopia av projektet som kan modifieras parallellt med andra grenar. Ofta används en huvudgren som innehåller projektets fullständiga historik, och nya grenar skapas för att implementera viss funktionalitet som sedan sammanfogas med huvudgrenen.
När flera användare har ändrat på samma rad i samma fil uppstår konflikter [3]. Vid vissa fall kan Git automatiskt resonera fram hur de olika ändringarna bör sammanfogas, men ofta behöver användare själva inspektera ändringarna och manuellt sammanfoga dem. För större projekt kan dessa manuella sammanfogningar ta mycket tid.
GitLab är en webb-baserad tjänst som används för att lagra de webb-arkiv som används med Git [3]. Tjänsten inkluderar även diverse administrativa funktioner för att hantera de projekt som lagras där. GitLab har även stöd för att implementera en form av automatisk testning [4]. När uppdateringar överförs till projektets huvudgren skickar GitLab ett kommando till en särskild server. Denna server kommer i sin tur att försöka bygga applikationen och när detta är klart blir det synligt på projektets GitLab-sida ifall applikationen kunde byggas utan fel. Detta ger en grundläggande försäkran om att applikationen saknar enkla fel av typen som lätt uppstår vid kodsammanfogning.
3.1.3
Trello
Trello är en webbapplikation för projektunderhållning [5]. Det används genom att skapa tav-lor som i sin tur kan innehålla listor. Inuti listorna kan flera kort som har en beskrivning finnas. Det finns även tillägg till Trello som möjliggör hierarkier av kort. På så sätt kan ett kort representera en uppgift som i sin tur delas upp i mindre aktiviteter på andra kort. Dess-utom kan flera användare samarbeta i samma tavla där alla användare kan lägga till nya listor och kort. I och med detta går det även att fördela de olika korten till olika användare.
3.1.4
Slack
Slack är en webbapplikation och ett molnbaserat kommunikationsverktyg för team [6]. Om ett team vill börja använda Slack så kan en egen arbetsyta skapas och sedan är det bara in-bjudna medlemmar som har tillgång till den. Inuti arbetsytan kan teamet skapa egna kom-munikationskanaler med olika syften. Till exempel kan teamet skapa en kanal där mjukvara diskuteras och en annan där hårdvara diskuteras. Vem som har tillgång till en specifik kanal kan specificeras av medlemmen som skapade kanalen.
3.1.5
Toggl
Toggl är en webbapplikation för loggning och rapportering av arbetad tid [7]. I Toggl kan användarna förutom att redogöra när de har arbetat även specificera vad de arbetat med, med vem och med vilket projekt. Användarna kan även generera olika typer av rapporter i bland annat PDF-format för att kunna redovisa den arbetade tiden.
3.1.6
Overleaf
Overleaf är en webbapplikation där flera personer kan arbeta på samma LaTeX-dokument samtidigt [8]. Det finns även stöd för förhandsvisning av dokumentet, versionshantering, stavningskontroll och PDF-generering.
3.2. En webbapplikations arkitektur
3.1.7
Google Drive
Google Drive är en molnlagringstjänst som finns tillgänglig i webbläsare, smarttelefoner och surfplattor [9]. Filer som laddas upp till en användares Google Drive kan sorteras i mappar och delas med andra. Det finns även stöd för att skapa dokument som alla med tillgång till kan redigera samtidigt direkt i webbläsaren.
3.1.8
Google Calendar
Google Calendar är ett kalenderverktyg som kan köras i webbläsare, smarttelefoner och surf-plattor [10]. Förutom att lägga till och visa personliga händelser finns möjlighet för att skapa kalendrar som kan delas med andra. Det innebär att om en händelse läggs till i en gemensam kalender visas den hos alla som delar på kalendern. Det är på så sätt enkelt att samordna möten och bestämma mötesplatser med hjälp av Google Calendar.
3.2
En webbapplikations arkitektur
Den simplaste arkitekturen hos en webbapplikation inkluderar en webbläsare, ett nätverk och en webbserver [11]. Webbläsaren begär webbsidor från servern och servern skickar inne-hållet som ska visas tillsammans med instruktioner kring hur det ska visas i form av HTML-kod. Vissa webbsidor innehåller även skript som beskriver dynamiska beteenden hos webb-sidan.
3.3
Ramverk, verktyg och utvecklingsspråk
Det här delkapitlet beskriver de olika ramverk, verktyg och utvecklingsspråk som använts i projektet för att utveckla produkten.
3.3.1
TypeScript
TypeScript är ett programmeringsspråk som är en delmängd av JavaScript, som är en dia-lekt av ECMAScript [12]. Med TypeScript får utvecklaren utöver all vanlig funktionalitet som JavaScript erbjuder även klassbaserad objektorientering och statiska typer. TypeScript kom-pileras sedan till vanlig JavaScript-kod som har stöd för ECMAScript 3 eller senare.
3.3.2
Angular 5
Angular 5 är ett TypeScript-baserat ramverk som är riktat till utveckling av single-page webbapplikationer [13]. Applikationen byggs upp av moduler, komponenter, mallar, direk-tiv, tjänster och pipes. För att få en modulär applikation har utvecklaren möjligheten att dela upp applikationen i små komponenter där varje komponent utför ett eget arbetsområde. Till varje komponent tillhör en mall där utvecklaren beskriver komponentens utseende. Dessa komponenter går även att återanvända.
Tjänster används för att förmedla information mellan komponenter om informationen inte har någon tydlig arvshierarki [13]. Direktiv används för att ändra utseendet eller beteendet av en mall. Pipes används för att ändra den visuella datan i applikationen.
3.4. API
3.3.3
Material Design for Angular
Material Design for Angular är ett front-end bibliotek byggt med Angular och TypeScript av Angular-teamet [14]. Biblioteket innehåller vältestade komponenter byggda för använd-ning med Angular för att enkelt kunna implementera en snygg front-end-design i single-page webbapplikationer.
3.3.4
Bootstrap 4
Bootstrap är ett front-end bibliotek som används vid utveckling av webbapplikationer [15]. Med hjälp av detta bibliotek går det snabbt och enkelt att implementera en snygg och funktio-nell design. I Bootstrap ingår det grundläggande Sass-klasser och HTML för de flesta grund-läggande element så som knappar, tabeller, navigering, ikoner, typografi och formulär. Det ingår även funktionalitet om utvecklaren vill göra en responsiv sida, där Sass-klasser kan ändra beteende beroende på webbläsarens fönsterstorlek.
3.3.5
Node.js
Node.js är en systemplattform som är gjord för att köra JavaScript i servermiljö [16]. Denna plattform är asynkron och händelsedriven, det vill säga att platformen väntar på händelser och sedan ger svar baserat på händelsen. En sådan struktur gör det lätt att designa skalbara back-end servrar då det är minimal overhead och det inte finns någon risk för dödläge.
3.3.6
MariaDB
MariaDB är en gren av MySQL som är vidareutvecklad under öppen källkod och all program-kod är fri att använda [17]. MariaDB har en hög kompatibilitet med MySQL så utvecklaren lätt kan konvertera mellan en MySQL-databas och MariaDB.
3.3.7
Visual Studio Code
Visual Studio Code är en utvecklingsmiljö som fungerar på Windows, Linux och MacOS [18]. Denna utvecklingsmiljö har stöd för flera olika programmeringsspråk, en bra implementation av Git direkt tillgänglig i utvecklingsmiljön, stöd för felsökning, kodkomplettering, kodrefak-torering och syntaxmarkering. Många andra funktioner är även tillgängliga genom program-tillägg.
3.3.8
Protractor
Protractor är ett end-to-end ramverk för testning i Angular [19]. Ramverket utför tester ge-nom att simulera den riktiga webbläsaren och sedan interagera med den som en användare skulle göra. Tester kan skrivas för att simulera all möjlig funktionalitet som en vanlig an-vändare kan utföra. På detta sätt kan utvecklaren automatisera tester av funktionalitet som kräver interaktion, exempelvis beteenden vid knapptryckningar eller navigationsmenyer.
3.4
API
Om ett program behöver utföra uppgifter som ligger bortom dess egna förmåga eller be-fogenhet kan programmet använda sig av funktionalitet från ett annat program [20]. Detta kan göras via anrop till ett API (Application Programming Interface) tillhörande det and-ra progand-rammet. Funktionaliteten hos ett API och hur den ska användas specificeand-ras i dess dokumentation. Nästan alla applikationer beror till exempel på det underliggande operativ-systemets API för att utföra grundläggande uppgifter som att få tillgång till filsystemet.
3.5. Databasstruktur
3.5
Databasstruktur
Datan i en SQL-databas är organiserad i olika tabeller [21]. En tabell består i sin tur av rader och kolumner. Betrakta till exempel en tabell med användare. Då representerar varje rad en användare medan kolumnerna innehåller data om användaren så som namn, personnummer eller telefonnummer. Kolumner i en tabell, även kallade fält, kan peka på rader i andra tabel-ler. Till exempel kan en kolumn i användartabellen innehålla en pekare till en rad i en tabell med adresser. På så sätt kan en användare ha en adress som i sin tur har kolumner för land, stad, gata och gatunummer.
En bra databasstruktur minimerar redundans genom att samma data inte lagras på flera stäl-len [21]. Hög redundans leder lätt till en inkonsekvent och onödigt stor databas. Det är även viktigt att krav på tabeller och fält ställs för att göra datan som lagras mer konsekvent och för att öka dess kvalitet.
3.6
Systemanatomi
En systemanatomi är en riktad graf som visar ett systems funktionalitet från ett användnings-perspektiv [22]. Syftet är att i ett projekt ge en gemensam bild av vad systemet innefattar samt vilka delar som är beroende av varandra. En systemanatomi kan vara en bra grund för pro-jektplanering och beslutstagande.
4
Metod
Det här kapitlet beskriver projektets arbetsgång, vilka ansvarsområden varje medlem hade och hur produkten utvecklades. Slutligen beskrivs också hur gruppen fångade erfarenheter och kontinuerligt utvärderade projektarbetet och dess resultat.
4.1
Projektmedlemmar och roller
Alla projektmedlemmar hade en huvudroll inom projektet. Projektmedlemmarnas roller ges i tabell 4.1.
Tabell 4.1: Utvecklingsroller
Namn Roll
David Hasselquist Teamledare
Jennifer Lindgren Dokumentansvarig/Kvalitetssamordnare
Niklas Nilsson Arkitekt
Andreas Lundquist Testledare
Daniel Herzegh Analysansvarig
Johan Lind Konfigurationsansvarig
Philip Bengtsson Utvecklingsledare
I figur 4.1 åskådliggörs hur projektets organisation såg ut. Samtliga projektmedlemmar och teamledaren kommunicerade med varandra och handledaren. Veckomöten, övriga möten och en gemensam kalender användes också för att samordna projektgruppen. Kontakten med kursansvarig gick via teamledaren medan kontakten med kunden gick via analysansva-rig. Teamledaren och analysansvarig var tillsammans ansvariga för att presentera produktens status till kunden vid slutet av varje sprint.
Rollernas definitioner och ansvarsområden var följande:
Teamledaren ledde arbetet, ansvarade för att mål uppfylldes och representerade teamet utåt. Denna såg till att processer följdes och svarade för arbetsmiljö. Teamledaren hade huvudansvaret för projektplanen.
4.1. Projektmedlemmar och roller
Figur 4.1: Ett schema över projektets organisation
Analysansvarig hade hand om kundkontakten och tog reda på kundens verkliga behov. Denna agerade som förhandlingspart och orakel in mot övriga gruppen. Analysansvarig ha-de huvudansvaret för kravspecifikationen.
Arkitekten såg till att en stabil arkitektur togs fram, identifierade komponenter och gräns-snitt samt gjorde övergripande val av verktyg. Arkitekten hade huvudansvaret för att doku-mentera arkitektur och ansvarade för arkitekturdokumentet.
Utvecklingsledaren ansvarade för detaljerad design och att organisera tester. Denna per-son ledde och fördelade utvecklingsarbetet vid behov. Utvecklingsledaren ansvarade för kodstandarden.
Testledaren beslutade om systemets status och skötte den dynamiska verifieringen och va-lideringen av systemet genom exekvering. Denna testade tillsammans med kvalitetssamord-nare kvalitetskrav. Testledaren hade huvudansvaret för testplanen samt testrapporten. Kvalitetssamordnaren hade initiativ- och uppföljningsansvar för kvalitetsarbetet. Denna planerade och budgeterade med övriga gruppen. Kvalitetssamordnaren hade huvudansvaret för kvalitetsplanen.
Dokumentansvarig ansvarade för att förbereda dokumentmallar för resten av gruppen samt korrekturläsa färdiga dokument innan inlämning. Denna ansvarade för ändringsrutiner och leveranser till deadlines. Dokumentansvarig hade även ansvar för dokumentstandarden.
4.2. Dokumentation
Konfigurationsansvarig beslutade om vad som skulle versionshanteras samt vad som ingick i en utgåva. Denna bestämde och ansvarade även för vilka verktyg som användes för versions- och konfigurationshantering.
4.2
Dokumentation
Dokumenten som producerades under projektets gång samt deras syfte finns i tabell 4.2. För större dokument som exempelvis projektplan och kandidatrapport användes verktyget Overleaf, medan för mindre dokument som statusrapporter och mötesprotokoll användes Google Drive.
Tabell 4.2: Dokumentation
Dokument Syfte
Projektplan Ge en översikt av projektet och hur detta ska utföras. Kravspecifikation Redogöra för kundens och projektgruppens krav på
produkten.
Kvalitetsplan Initiera samt stärka processer kring kvalitetsarbetet i projektet och kvalitetssäkra utvecklingen av systemet. Arkitekturbeskrivning Få en överblick över arkitekturen och en teknisk
förstå-else för uppbyggnaden av systemet.
Systemanatomi Ge en översiktlig bild av systemets uppbyggnad och funktionalitet.
Testplan Definiera hur kraven ska verifieras.
Testrapport Verifiera att krav har uppfyllts enligt testplanen. Mötesprotokoll Bokföra beslutspunkter vid möten.
Utvärdering Utvärdera projektet.
Statusrapport Sammanställa måluppfyllelse kring projektet.
Teknisk dokumentation Utgöra ett tekniskt underlag för vidareutveckling av slutprodukten efter projektets slut.
Användarhandledning Beskriva hur slutprodukten är menad att användas. För att säkerställa att allt arbete på projektet skulle hålla en enhetlig standard togs interna standarder fram. De olika standarderna säkerställde att utvecklingen skedde på liknande sätt samt att det arbete projektgruppen gjort ska vara lätt att sätta sig in i för vidareutveckling och underhåll. De standarder och dess syfte som togs fram under projektet finns i tabell 4.3.
Tabell 4.3: Standarder
Dokument Syfte
Kodstandard Redogöra för hur koden skall skrivas och dokumente-ras.
Dokumentationsstandard Redogöra för hur projektets olika dokument skall skri-vas.
Gruppkontrakt Redogöra för vilka principer gruppen har beslutat att gemensamt arbeta efter.
4.3. Utvecklingsmetodik
4.3
Utvecklingsmetodik
Det här avsnittet tar upp de metoder gruppen använde för att utforma och utveckla produk-ten.
4.3.1
Arbetssätt
Projektets arbetssätt och resultatutvärdering var inspirerat av det agila ramverket Scrum. Några av medlemmarna hade arbetat enligt ramverket förut vilket bidrog till beslutet att följa det. En annan anledning till beslutet var att flera av projektmedlemmarna tidigare arbe-tat efter en sekventiell utvecklingsmodell, vattenfallsmodellen, och ansett att det medförde många oönskade begränsningar. Det beslutades att projektet skulle delas in i sprintar enligt Scrum-ramverket, men att dagliga möten ansågs onödiga eftersom utvecklingen ej ägde rum på heltid. Projektet delades in i fem olika sprintar där varje sprint huvudsakligen bestod av två veckor, men kunde anpassas till olika längder, se tabell 4.4, på grund av tentamensperio-der. Vid slutet av varje sprint gjordes en leverans till kunden.
Tabell 4.4: Sprintplan
Sprint Startdatum Slutdatum
1 2018-02-12 2018-02-23
2 2018-02-26 2018-03-09
3 2018-03-19 2018-03-29
4 2018-04-09 2018-04-20
5 2018-04-23 2018-05-04
I början av utvecklingsfasen när utvecklingsmiljön och verktygen fortfarande var nya samar-betade hela gruppen genom att utveckla de första delarna tillsammans. När medlemmarna hade blivit mer vana kunde utvecklingen delas upp och ske individuellt. Gruppen träffades därefter vid behov eller då det passade att sitta tillsammans. Normalt ägde detta rum på mån-dagar, onsdagar samt fredagar. Varje måndag träffades gruppen för att utvärdera den gångna veckan samt för att planera den kommande veckan. På detta möte skrevs en sammanfattning av vad som gjorts under veckan samt vilka risker i projektet gruppen ser för kommande veckan.
I slutet av varje sprint utvärderades resultaten som framställdes utifrån målen som sattes upp i början av sprinten. Om inte alla mål hade uppnåtts beslutade gruppmedlemmarna hur de skulle gå vidare för att uppnå målen under nästkommande sprint. Dessa utvärderingar gjorde att alla i gruppen var medvetna om vad de andra gjorde och hur projektet låg till. För att skapa en översikt över det pågående arbetet användes Trello. Inför varje sprint skapa-des olika listor där medlemmarna kunde flytta aktiviteter mellan listor för det som ska göras, det som görs just nu och det som är färdigt. Varje aktivitet hade en ansvarig person. Detta gav en bra översikt och uppfattning av hur gruppen låg till. Det gav även en översikt över vem som gjorde vad. Listorna visade förvisso bara det som var aktuellt för den dåvarande sprin-ten men det gav generellt inga problem så länge sprint-planeringen tog hänsyn till projektets helhet.
4.3. Utvecklingsmetodik
4.3.2
Kommunikation och samarbete
När gruppmedlemmarna inte var fysiskt närvarande skedde kommunikationen via Slack. Där skapades kanaler för olika samtalsämnen som till exempel dokumentskrivning, möten och mjukvarurelaterade frågor och diskussioner.
När gruppen bokade in möten gjordes detta via en gemensam kalender på Google Calendar som alla hade tillgång till. Bokningarna gick till så att gruppen kom överens om att ses en viss dag och tid varpå någon av medlemmarna lade in detta i kalendern. Dagen innan mötet fick den som först hade möjlighet boka en sal och lägga in platsen i kalendern.
Även om mycket av arbetet skedde på individuell nivå lyckades gruppen ta alla viktiga beslut kring utvecklingen gemensamt på möten eller via Slack. Det var även lätt att få hjälp om någon hade problem med någon del i utvecklingen bara genom att ta upp det på ett möte eller i Slack. Bra kommunikation ledde till ett bra samarbete.
4.3.3
Designarbete
Under utvecklingen hade projektgruppen flera designmöten. Dessa möten ägde främst rum i början av utvecklingen men förekom även mot slutet. Designmöten som projektgruppen hade gick ofta ut på att göra en skiss på en whiteboardtavla. På detta sätt gick det snabbt att visualisera applikationen och skapa en gemensam bild av designen inför implementationen. Den första designskissen som gjordes visas i figur 4.2.
Figur 4.2: Första designskissen över webbapplikationen
Genom att framställa flera skisser över applikationens olika delar kom projektgruppen över-ens om hur den skulle utformas. Bland annat beslutades att menyn i webbapplikationen skul-le ligga till vänster på skärmen eftersom skärmens yta då skulskul-le användas effektivt.
Ett annat stort designbeslut som togs handlade om modaler. Från början tänkte projektgrup-pen att webbapplikationen skulle bläddras upp till topprojektgrup-pen av en tabell varje gång användaren interagerade med den, så att information och funktionalitet kunde visas högst upp. Det visa-de sig dock inte fungera så bra, därför beslutavisa-de sig projektgruppen för att använda modaler innehållande information och funktionalitet istället. På så sätt behövde användaren aldrig bläddras bort från positionen i tabellen den befann sig på, för att till exempel se detaljerad information om någonting från tabellen.
4.3. Utvecklingsmetodik
Ett designbeslut som togs i slutet av utvecklingen handlade om hur PDF:en för kvittenser skulle se ut. En skiss visas i figur 4.3 och slutresultatet kan ses i figur 5.18 i kapitel 5.1.6. Andra designbeslut som togs under projektets gång var exempelvis hur knappar skulle placeras eller hur olika typer av bekräftelser skulle ges.
Figur 4.3: Designskiss av en kvittens
4.3.4
Kvalitetsarbete
För att försäkra att dokument och mjukvara som producerades under projektet höll hög kva-litet skrevs en kvakva-litetsplan. I den redogjordes hur dokument och kod skulle granskas samt hur ändringar av dessa fick göras. Alla gruppmedlemmar uppmanades att använda kod-rättningstillägget TSLint. I kvalitetsplanen definierades även gruppmedlemmarnas roller i kvalitetsarbetet, till exempel vem som skulle kontaktas om en ändring behövde göras i ett visst dokument och vilka som sedan ansvarade för att genomföra ändringen.
I kvalitetsarbetet ingick även inspektioner av slutprodukten. Inspektionerna skulle säkerstäl-la att samtliga krav som produkten skulle uppfylsäkerstäl-la enligt kravspecifikationen var uppfyllda innan leverans. Inspektionerna hade också som syfte att försäkra att mjukvaran som levere-rades var konsekvent.
4.3.5
Utbildning
Vid projektets början var medlemmarnas kunskapsnivåer inom de relevanta områdena varie-rande. Dessa områden innefattade främst Angular, Node.js, Bootstrap, SQL och Git. Eftersom det oftast fanns minst en medlem som hade tidigare erfarenheter inom något område kunde utbildningen ske till stor del genom att medlemmarna hjälpte varandra. Förutom detta sökte gruppen tidigt upp olika guider på internet som delades i Slack. Planeringen tog hänsyn till att tid behövde avsättas till utbildning genom att färre uppgifter las i de tidiga sprintarna. Detta visade sig vara bra eftersom utvecklingen tog längre tid i början.
4.3. Utvecklingsmetodik
4.3.6
Kravsammanställning, kontrakt och utvecklingsplan
När gruppen hade kommit i kontakt med kunden började arbetet med att formulera ett kon-trakt samt krav på produkten. Detta gjordes genom kundmöten och mejlkonversationer. Kon-traktet mellan kunden och projektgruppen togs fram med hjälp av universitetets avtalsmall. De avvikelser som gjordes från avtalsmallen, på begäran av kunden, handlade om att slutpro-dukten skulle publiceras som öppen källkodslicens under Apache2-licens samt att kunden inte kunde tillhandahålla lokaler för projektgruppen.
Kraven på produkten sammanställdes i en kravspecifikation som godkändes av båda parter. När kraven var fastställda planerades utvecklingen genom att formulera milstolpar och till-hörande aktiviteter. Milstolparna var mål som uppnåddes genom att flera mindre aktiviteter utfördes. Detta var ett bra sätt att gå igenom hela projektet, dela upp det i mindre delar och få en bild av hur det skulle genomföras. Det var värdefullt att bestämma i vilken ordning alla delar skulle utvecklas samt förtydliga vilka delar som gick att arbeta på parallellt. Det enda som återstod var sedan att planera in detta i sprintar för att ge varje del en tidsbegränsning. Det var i planeringsfasen som de första skisserna av produkten gjordes med hjälp av feed-back från kunden samt inspiration från andra webbapplikationer. Gruppen beslutade om design, exempelvis vilka typer av ikoner och indatakomponenter som skulle användas för att designen skulle bli konsekvent, trots att sju olika personer hade arbetat på produkten.
4.3.7
Testning
I samband med att en utvecklingsplan skrevs gjordes även en testplan indelad i fem itera-tioner, en för varje sprint. Syftet med denna var att ge projektmedlemmarna riktlinjer och strategier för hur webbapplikationen skulle testas. Testningen bestod av belastningstester, enhetstester, utforskande tester och systemtester. Enhetstestning av kod utfördes av projekt-medlemmen som skrivit koden, medan resterande tester utfördes av testledaren. Både ma-nuella tester och automatiska tester utfördes. De automatiska testerna utfördes med hjälp av verktyget Protractor. Testplanen hjälpte projektgruppen att säkerställa en hög kvalitet på webbapplikationen samt att alla krav i kravspecifikationen uppfylldes.
4.3.8
Resurser
Alla projektmedlemmar har lagt ned ungefär lika mycket tid på projektet, detta har kontrol-lerats med hjälp av verktyget Toggl. Tiden som planerades att läggas var 400 timmar per pro-jektmedlem, inklusive dokumentation. Detta gav alltså projektet en total tidsbudget på 2800 timmar. Materiel som användes för att genomföra projektet tillhandahölls av gruppmedlem-marna själva. Exempel på materiel är datorer och server. Kunden tillhandahöll inga lokaler för projektet utan utvecklingen ägde främst rum på Linköpings universitet. Enligt avtal med kund utgick ingen ersättning för projektarbetet.
4.3.9
Versionshantering
Projektgruppen använde sig av versionshantering för att det var ett kundkrav, men även för att det underlättade utvecklingen. Versionshanteringen som valdes var GitLab eftersom alla hade tillgång till studentkonton samt att det blev lätt att följa den uppsatta utvecklingsmo-dellen. Utvecklingsmodellen som sattes upp var Feature Branch Workflow, där grundidén är att all utveckling sker på en separat gren innan den integreras in i huvudgrenen. Efter ut-vecklingen på den separata grenen gjordes en sammanfogningsförfrågan (eng. merge request), detta för att få integrera koden från den separata grenen till huvudgrenen. Syftet med en sammanfogningsförfrågan är att en annan projektmedlem måste godkänna koden innan den
4.4. Metod för att fånga erfarenheter
accepteras. Det resulterade i att allting som låg i huvudgrenen testades en extra gång och kontrollerades följa den uppsatta standarden.
4.3.10
Riskanalys
I samband med projektstarten gjordes en riskanalys. Tabell 4.5 visar de risker som projekt-gruppen identifierade, där sannolikhet och konsekvens rangordnades på en skala 1-5 där 5 är högst och 1 är lägst. Projektgruppen arbetade under projektets gång med dessa risker i åtanke, där varje projektmedlem försökte hantera riskerna på ett rimligt vis för att minimera deras påverkan på projektet.
Tabell 4.5: Riskanalys
Riskbeskrivning Sannolikhet Konsekvens Total
på-verkan Åtgärd
Dålig
gruppsam-manhållning 2 5 10
Samtal med handledare/ kursansvarig
Kursavhopp 1 3 3
Omplanering, eventuellt minska på aktiviteter. I sista hand omförhandla med kund
Missförstånd med
kund 4 2 8
Kontinuerlig avstämning med kund
Serverfel 2 2 4 Tillhandahålla ny server
Lokalbrist 2 4 8 Diskussion med
kursan-svarig Webbapplikationen
fungerar inte i alla webbläsare
1 5 5 Programmera mot
kun-dens webbläsare
4.4
Metod för att fånga erfarenheter
Arbetssättet gav goda förutsättningar för alla medlemmar att dra lärdom av varandras arbete. Under de veckovisa genomgångarna fick var och en av medlemmarna förklara vad de gjort under den senaste veckan. Då fanns även tillfälle för de övriga medlemmarna att ställa frågor om de var nyfikna på någonting.
I slutet av varje sprint hölls en sprintåterblick för att gruppmedlemmarna gemensamt skulle reflektera över erfarenheter från den gångna sprinten. På så sätt kunde de komma fram till vad som skulle kunna göras annorlunda under nästa sprint. Under alla möten fördes även protokoll vilket innebar att om en projektmedlem var frånvarande så fanns ändå möjligheten att ta del av det som togs upp.
5
Resultat
I detta kapitel presenteras projektets resultat. I resultatet ingår en systembeskrivning av det slutgiltiga systemet, vad projektet har för värde för kunden, de gemensamma erfarenheterna som fåtts under projektet samt en översikt över de individuella bidragen.
5.1
Systembeskrivning
Systemet är en webbapplikation, med tillhörande databas, för att kunna registrera och spåra kort, handlingar och leveranser samt generera och hantera kvittenser för kort och handlingar. Systemet är även till för att lätt kunna se inventeringsunderlag och skriva ut relevanta doku-ment i PDF-format. En användare av systemet kan med hjälp av ett webbgränssnitt registrera nya kort, handlingar och leveranser. Kort och handlingar kan sedan kvitteras ut och spåras för att se var dessa finns just nu och se vem som använder dem. Leveranser kan inte kvitte-ras eftersom dessa är dokument som är skapta internt på företaget och levererade till andra företag.
5.1.1
Ingående delsystem
Webbapplikationen består av tre delar. En front-end applikation som har utvecklats i ram-verket Angular 5, en API back-end som är skriven i TypeScript (NodeJS) och en MariaDB databas, se figur 5.1. Hela applikationen körs på en Ubuntu 16.04 server.
I front-end används färdiga komponenter från biblioteken Bootstrap 4 och Material Design for Angular för bland annat knappar, inmatningsfält och modaler. Webbapplikationen är en single-page application.
5.1. Systembeskrivning
5.1.2
Systemanatomi
Den systemanatomi som projektgruppen tog fram i början av projektet har med tiden utveck-lats och använts som underlag för systemets funktionalitet och uppbyggnad. Systemanato-min kan ses i figur 5.2.
Kommunikation Hårdvara Serverfunktioner Display Tjänster Registrera handlingar Generera dokument Registrera kvittenser Användar- inloggning Utforska innehåll Lista
innehåll Lista loggar
Filtrera Ändra innehåll Användar- inloggning input Kvittenser input Välja dokument-innehåll Handlingar input Kvittens i pdf Logga in användare Generera dokument Spara dokument Registrera kvittens i databas Registrera handling i databas Ändra i databas Hämta information Kommunikation med server Ström Figur 5.2: Systemanatomi
5.1.3
Användarhantering
För att använda webbapplikationen krävs ett användarkonto. En användare eller administ-ratör loggar in till sitt konto med hjälp av sitt unika användarnamn och ett lösenord.
Vanliga användare
En vanlig användare har tillgång till två olika vyer. Den första är en vy över kort och hand-lingar som användaren har kvitterat ut. Den andra är en vy där användaren kan utföra egen-kontroller, vilket innebär att användaren intygar att ett kort eller en handling finns där det ska vara.
5.1. Systembeskrivning
Administratörer
Administratörsanvändare skiljer sig från vanliga användare genom att dessa användare inte kan ha några kort eller handlingar utkvitterade till sig. Istället är det administratörerna som kvitterar ut kort och handlingar till vanliga användare.
Kort, handlingar och leveranser har egna vyer med tabeller där administratören kan lägga till eller ändra objekt av respektive typ. Administratören har även en vy för att göra en invente-ring. En inventering bekräftar att ett kort eller en handling finns där det ska vara. Detta liknar en egenkontroll, som görs av en vanlig användare, men är istället gjord av en administratör. För att se vad som tidigare har gjorts finns det en vy för loggar. Det finns även en vy som visar alla användare där administratören kan lägga till nya användare eller ändra information som rör en befintlig användare. Till sist finns en vy som visar alla kort- och handlingstyper där administratören kan lägga till nya typer eller ändra information om befintliga typer.
Back-end hantering
När en ny användare ska läggas till i databasen skapas en hash av lösenordet som angivits genom att hashfunktionen bcrypt appliceras på lösenordssträngen. Sedan sparas aldrig det faktiska lösenordet i databasen utan bara dess hashvärde. När en användare gör ett inlogg-ningsförsök appliceras samma hashfunktion på det angivna lösenordet och resultatet jämförs med det som finns lagrat i databasen. Om strängarna är lika betyder det att lösenordet som angivits måste vara lika med det ursprungliga lösenordet. Genom att aldrig spara de faktis-ka lösenorden i databasen skyddas användarna om en obehörig skulle stjäla lösenorden från databasen.
5.1.4
UI-design
Fokuset för webbapplikationens UI-design är att den ska vara lätt att använda och samtidigt ha en simpel design. Det ska vara enkelt för en användare att navigera och uppnå det an-vändaren vill med så få knapptryck som möjligt. Detta möjliggjordes, efter att anan-vändaren loggat in i webbapplikationen, genom en tydlig meny till vänster som kan ses i figur 5.3. Genom denna meny, som alltid är synlig, kan användaren navigera till alla flikar i webbap-plikationen. När en flik väljs visas information till höger om menyn. Fokus har lagts på att de olika flikarna ska vara enhetliga i sin design, därav visas alla flikars information i form av tabeller, se figur 5.4.
5.1. Systembeskrivning
Figur 5.3: Meny till vänster i webbapplikationen
Figur 5.4: Tabell med information om handlingar
5.1.5
UX-design
Målet med webbapplikationens UX-design var att alla klickbara element skulle vara tydliga och att det skulle vara enkelt att förstå vad som händer när användaren klickar på en specifik knapp. För att beskriva hur webbapplikationen fungerar visas tre typiska användningsfall som webbapplikationen kommer att användas till. Alla användningsfall är utförda av en ad-ministratörsanvändare.
5.1. Systembeskrivning
1. Kvittera ut ett specifikt kort
Det första en användare ser i webbapplikationen är en inloggningssida. När en användare ska kvittera ut ett kort behöver användaren först logga in. Detta görs genom att fylla i använ-daruppgifter i fälten för användarnamn och lösenord samt sedan klicka på logga in, se figur 5.5.
Figur 5.5: Inloggningssida
Efter att användaren loggat in klickar användaren på fliken kort. En tabell med alla tillgäng-liga eller utkvitterade kort visas då till höger om menyn, se figur 5.6.
5.1. Systembeskrivning
Eftersom användaren vill kvittera ut ett specifikt kort filtrerar användaren på det unika kort-id som kortet har genom att skriva detta kort-kort-id i sökfältet. Det aktuella kortet är nu det enda kortet som finns kvar i tabellen, se figur 5.7.
Figur 5.7: Tabell med kort filtrerat på ett kort-id
Användaren klickar på knappen KVITTERA UT. En modal kommer då upp som visar infor-mation om kortet och ber användaren fylla i användarnamn, datum och ny förvaringsplats för kortet, se figur 5.8.
5.1. Systembeskrivning
Det finns också möjlighet att skriva en kommentar och att generera en kvittens i form av ett PDF-dokument. När användaren klickar på KVITTERA UT i modalen kvitteras kortet ut. Om alternativet att generera kvittens är ifyllt får användaren två val, att ladda ned dokumentet eller att öppna det i en ny flik i webbläsaren, se figur 5.9.
Figur 5.9: Modal för val gällande PDF-dokument
2. Skriva ut en specifik inventeringslista och verifiera inventering
I detta användningsfall utförs samma inloggning som i det förra fallet. Efter inloggningen klickar användaren på fliken inventering. En tabell med alla tillgängliga eller utkvitterade kort och handlingar visas då till höger om menyn, se figur 5.10.
5.1. Systembeskrivning
Användaren vill i det här fallet inventera alla kort av typen GEID och sorterar därför efter typ genom att klicka på fältet typ, se figur 5.11.
Figur 5.11: Sortering efter typ av kort
Användaren markerar sedan alla kort av typen GEID genom att klicka på kryssrutan på ra-den, se figur 5.12.
Figur 5.12: Alla kort av typen GEID är markerade
Sedan klickar användaren på knappen Generera PDF. En modal kommer då upp som frågar användaren om en PDF ska genereras från de framfiltrerade resultatet eller de markerade
5.1. Systembeskrivning
Figur 5.13: Valmöjlighet vid generering av PDF-dokument från inventeringstabellen
Användaren får sedan två val, att ladda ned PDF-dokumentet eller att öppna det i en ny flik i webbläsaren. Användaren laddar ned dokumentet och stänger modalen. Efter att användaren fysiskt har inventerat korten klickar användaren på knappen Verifiera. Efter att användaren har bekräftat verifieringen i en modal är verifieringen genomförd vilket kan ses genom att datumet för senaste verifieringen har uppdaterats, se figur 5.14.
5.1. Systembeskrivning
3. Lägga till en ny handling i systemet
Även i detta användarfall måste inloggning utföras, precis som i de tidigare fallen. När detta är gjort klickar användaren på fliken handlingar, se figur 5.15.
Figur 5.15: Tabell med handlingar
Användaren klickar nu på knappen Lägg till ny handling. Det kommer då upp en modal som ber användaren fylla i 7 obligatoriska informationsfält för handlingen. Det finns även möjlig-het att lägga till en kommentar, se figur 5.16.
