spårbarhetssystem för...

Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapKandidatarbete på grundnivå, 15hp | Datateknik

Vårterminen 2018 | LIU-IDA/LITH-EX-G--18/010--SE

Spårbarhetssystem försekretessuppgifter– Hantering av hemlig information har aldrig varit enklare

A traceability system for confidential information– Handling classified information has never been easier

Andreas LundquistDaniel HerzeghDavid HasselquistJennifer LindgrenJohan LindNiklas NilssonPhilip Bengtsson

Handledare : Erica GavefalkExaminator : Kristian Sandahl

http://www.liu.se

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrå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 enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt 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 iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt 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 elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida 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 toread, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and educational purpose. Subsequent transfers of copyrightcannot 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 measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

©

Andreas LundquistDaniel HerzeghDavid HasselquistJennifer LindgrenJohan LindNiklas NilssonPhilip Bengtsson

http://www.ep.liu.se/

http://www.ep.liu.se/

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 medprojektet 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 utvecklingsfasföljde projektgruppen en modifierad version av det agila systemutvecklingsramverket Sc-rum. Projektet resulterade i en fungerande webbapplikation som uppfyller de krav som togsfram tillsammans med Sectra Communications AB. Projektgruppen har utvecklat sina kun-skaper inom webbutveckling, agila metoder och att arbeta i grupp. Alla projektmedlemmarhar fördjupat sig inom ett varsitt ämne kopplat till projektet, dessa individuella bidrag kanläsas i slutet av rapporten.

Författarens tack

Projektgruppen vill tacka våra kundkontakter Åsa Lindbäck Mattsson och Robert Kihlbergsom har varit tillgängliga för att besvara frågor genom projektet och som gjort detta projektmö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 ossgenom projektet.

Innehåll

Figurer

Tabeller

Definitioner

1 Inledning 11.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Uppgift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Arbetsflödet kring hantering av kort och handlingar . . . . . . . . . . . . . . . . 32.3 Sectras nuvarande verktyg för hantering av kort och handlingar . . . . . . . . . 52.4 Projektgruppens tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Teori 73.1 Arbetssätt för programvaruprojekt . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Git och GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.3 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.4 Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.5 Toggl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.6 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.7 Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.8 Google Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 En webbapplikations arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Ramverk, verktyg och utvecklingsspråk . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3.2 Angular 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3.3 Material Design for Angular . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.4 Bootstrap 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.5 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.6 MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.7 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.8 Protractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 Databasstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Metod 13

4.1 Projektmedlemmar och roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.1 Arbetssätt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.2 Kommunikation och samarbete . . . . . . . . . . . . . . . . . . . . . . . . 174.3.3 Designarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3.4 Kvalitetsarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.5 Utbildning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.6 Kravsammanställning, kontrakt och utvecklingsplan . . . . . . . . . . . 194.3.7 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.8 Resurser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.9 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.10 Riskanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Resultat 215.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Ingående delsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.1.2 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.3 Användarhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.4 UI-design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.5 UX-design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.6 PDF-generering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.7 Databasstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Värde för kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Översikt över individuella bidrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.1 Balans mellan olika testnivåer vid agil systemutveckling av AndreasLundquist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.2 Kundinverkan vid agil mjukvaruutveckling av Daniel Herzegh . . . . . 385.4.3 Sårbarhet för Cross site scripting (XSS) i en webbapplikation av David

Hasselquist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.4 Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren 385.4.5 Implementation av kontinuerlig leverans av Johan Lind . . . . . . . . . 385.4.6 Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson . . . . . . . 385.4.7 Vikten av kodstandarder och effektiv kod av Philip Bengtsson . . . . . . 38

6 Diskussion 396.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Alternativa implementationssätt . . . . . . . . . . . . . . . . . . . . . . . 396.1.2 Kvarstående arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.1.3 Utveckling sedan tidigare projekt . . . . . . . . . . . . . . . . . . . . . . 406.1.4 Lärdomar inför framtiden . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3.1 Miljöperspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.2 Etiskt perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.3 Socialt perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Slutsatser 437.1 Hur kan SecTrack implementeras så att värde för kunden skapas? . . . . . . . . 437.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? . . . . . . 437.4 Kan systemutvecklingen i projektet anpassas för att förenkla underhåll och vi-

dareutveckling i framtiden? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.5 Leder ett agilt arbetssätt till att eventuella problem och förbättringsmöjligheter

inom projektet uppmärksammas och kan åtgärdas? . . . . . . . . . . . . . . . . 447.6 Projektets syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A Balans mellan olika testnivåer vid agil systemutveckling av Andreas Lundquist 45A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.1.2 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A.3.1 Testnivåer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.3.2 Vattenfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.3.3 Agil systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

A.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.5.1 Erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.5.2 Insamlad data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

B Kundnöjdhet vid agil programvaruutveckling av Daniel Herzegh 51B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

B.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

B.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.3.1 Vattenfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.4.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.4.2 Projektarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

B.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.5.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.5.2 Projektarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

B.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C Sårbarhet för Cross site scripting (XSS) i en webbapplikation av David Hasselquist 57C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

C.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57C.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

C.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

C.3.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.3.2 XSS-kategorier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

C.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60C.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

C.5.1 Reflekterad XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

C.5.2 Sparad XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.5.3 DOM-baserad XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63C.5.4 Förhindrande av XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

C.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65C.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

D Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren 68D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

D.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.1.2 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

D.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69D.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

D.3.1 Hantering av data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69D.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

D.4.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70D.4.2 Analys av SecTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

D.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71D.5.1 Metoder för att utföra SQL-injektioner . . . . . . . . . . . . . . . . . . . . 71D.5.2 Sårbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72D.5.3 Säker databashantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72D.5.4 SecTracks sårbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

D.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73D.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73D.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

D.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74D.7.1 Frågeställning 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74D.7.2 Frågeställning 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74D.7.3 Frågeställning 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

E Implementation av kontinuerlig leverans av Johan Lind 76E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

E.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76E.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

E.3.1 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77E.3.2 Agil mjukvaruutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

E.5.1 Information från litteraturstudien . . . . . . . . . . . . . . . . . . . . . . 78E.5.2 Gruppens erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

F Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson 82F.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

F.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

F.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

F.3.1 Arbetsplatsens utformning . . . . . . . . . . . . . . . . . . . . . . . . . . 83

F.3.2 Ergonomi vid datorarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . 83F.3.3 Ljud på en arbetsplats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84F.3.4 Ljus på en arbetsplats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

F.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85F.4.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85F.4.2 Nuvarande och tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . 85

F.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85F.5.1 Litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85F.5.2 Nuvarande och tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . 86

F.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86F.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

G Vikten av kodstandarder och effektiv kod av Philip Bengtsson 88G.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

G.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88G.1.2 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

G.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88G.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

G.3.1 Exempel på innehåll i en kodstandard . . . . . . . . . . . . . . . . . . . . 89G.3.2 Energieffektivitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

G.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90G.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

G.5.1 Att ha en kodstandard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90G.5.2 Läsbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91G.5.3 Energieffektiv kodning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91G.5.4 Egna erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

G.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92G.6.1 Källkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

G.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94G.7.1 Frågeställning 1 och 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94G.7.2 Frågeställning 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94G.7.3 Frågeställning 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Litteratur 95

Figurer

2.1 Arbetsflödet kring kort och handlingar . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Exempelvy av register med aktiva kort . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Exempelvy av register med handlingar . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Ett schema över projektets organisation . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Första designskissen över webbapplikationen . . . . . . . . . . . . . . . . . . . . . . 174.3 Designskiss av en kvittens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 Ingående delsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Meny till vänster i webbapplikationen . . . . . . . . . . . . . . . . . . . . . . . . . . 245.4 Tabell med information om handlingar . . . . . . . . . . . . . . . . . . . . . . . . . 245.5 Inloggningssida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.6 Tabell med kort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7 Tabell med kort filtrerat på ett kort-id . . . . . . . . . . . . . . . . . . . . . . . . . . 265.8 Modal för att kvittera ut ett kort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.9 Modal för val gällande PDF-dokument . . . . . . . . . . . . . . . . . . . . . . . . . . 275.10 Inventering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.11 Sortering efter typ av kort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.12 Alla kort av typen GEID är markerade . . . . . . . . . . . . . . . . . . . . . . . . . . 285.13 Valmöjlighet vid generering av PDF-dokument från inventeringstabellen . . . . . . 295.14 Alla kort av typen GEID har nu blivit inventerade . . . . . . . . . . . . . . . . . . . 295.15 Tabell med handlingar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.16 Modal för lägg till ny handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.17 Modal för detaljer om en handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.18 Kvittensmall användarkopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.19 Inventeringsmall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.20 Databasens primära tabeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.21 Databasens sekundära tabeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.22 Fullständig struktur med länkar för tabellen Dokument . . . . . . . . . . . . . . . . 35

A.1 Pyramidmodell för testnivåer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.2 Omvänd pyramidmodell för testnivåer . . . . . . . . . . . . . . . . . . . . . . . . . 49

D.1 SecTracks arkitektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Tabeller

4.1 Utvecklingsroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Standarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 Sprintplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 Riskanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Definitioner

I det här avsnittet förklaras begrepp som används i rapporten men vars innebörd inte antasvara 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ändarenser och interagerar med i en webbapplikation.

• Single-page application: En webbapplikation som vid interaktion dynamiskt skriverom 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 atthä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öratt skapa webbsidor och webbapplikationer.

• Cascading Style Sheets (CSS): Ett programmeringsspråk som används för att beskrivapresentationen 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 tillexempel 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 CommunicationsAB gjort till ett annat företag.

• Inventering: En kontroll utförd av en administratör för att verifiera att ett kort eller enhandling fortfarande finns tillgänglig.

• Egenkontroll: En kontroll utförd av en användare för att verifiera att ett kort eller enhandling fortfarande finns tillgänglig.

• Registrator: En administratör som registrerar samt hanterar kort och handlingar.

1 Inledning

Denna rapport beskriver ett projektarbete som utfördes i kursen TDDD96 Kandidatprojekti 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 resultatetblev samt en diskussion kring detta. Slutligen redovisas sju utredningar som utförts enskiltav 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ånföretagets kunder, som behövs för att utveckla olika produkter. Dessa kan vid olika skedenbehöva byta ansvarig ägare inom företaget och dessa byten måste då registreras. Vissa företagsaknar 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 ansvarigför att hålla koll på var samtliga tillgångar befinner sig samt har befunnit sig vid varje giventidpunkt. 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 befinnasig på blir fler kan pappershantering lätt bli rörig och oorganiserad. När historik över hurtillgångarna hanterats dessutom måste redovisas blir det nästintill omöjligt utan ett anpassatsystem.

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ören användare som inte känner till alla funktioner i excelprogrammet, och även för en vananvändare kan det lätt bli fel när information ska lägga till eller modifieras. Systemet saknardessutom 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 kanunderlätta hanteringen av ett företags tillgångar. Ett sådant system skulle spara in på resurseroch arbetstid som behöver läggas på det administrativa arbetet. Ur ett hållbarhetsperspektivskulle ett nytt system som utvecklas kunna fungera helt digitalt, vilket för företag som redananvänder många datorer inte kommer att öka energiförbrukningen nämnvärt.

1

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åratillgångar internt hos företaget. Viktiga egenskaper hos systemet var användbarhet, stabilitetsamt 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 produktsom 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örframtida 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 inomprojektet 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 400timmar per projektmedlem. I denna tid ingick planering, utbildning, utveckling och doku-mentation.

Projektgruppen skulle endast producera öppen källkod vilket innebar att endast öppenkä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å detfrå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 GoogleChrome 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 äranpassad till att köras på Ubuntu version 16.04 då det var ett kundkrav.

2

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överdetta ges även en övergripande beskrivning av projektgruppens tidigare erfarenheter av attarbeta inom projekt.

2.1 Uppgift

Kunden är företaget Sectra Communications AB som fortsättningsvis benämns som Sect-ra i denna rapport. Sectra erbjuder lösningar för säker kommunikation [1]. Deras kunderinkluderar 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överspå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 blandannat utlämningar till användare, återlämningar och kontroller ingår. På grund av dettaefterfrågade Sectra ett nytt och bättre system för inventering och spårning av handlingar ochkort ä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 vardet passar in i Sectras arbete kommer denna sektion att kartlägga hur arbetsflödet kring do-kumenten fungerar.

3

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 enfö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 ärplacerad 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äftainnehav av datan.

8. När datan inte längre behövs lämnas den in till registratorn och arkiveras och förstörseventuellt, om den inte ska användas av en annan användare inom företaget.

De delar systemet SecTrack är inblandat i och avser att underlätta är steg 4 till 8 i listan.

4

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 elleraktiva handlingar. Dessa register existerar i form av exceldokument. Figur 2.2 och figur 2.3visar exempelvyer, som tillhandahölls av kunden, över registret med aktiva kort respektiveregistret 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 exceldokumentsom är ett register över återlämnade kort.

Det som saknas helt är ett verktyg för kvittenser och kvittensgenerering vilket innebäransvars- och uppföljningsproblem kring ett kort eller en handling. Med hjälp av kvittenserblir 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äckningoch gruppstorlek. Dessa erfarenheter togs i beaktande vid starten av projektet innan någonutveckling hade påbörjats. De punkter gruppen gemensamt tyckte var viktiga inför arbetetmed det här projektet var god och öppen kommunikation, tydlig kodstruktur, gemensammastandarder och kontinuerlig tidsplanering.

Gruppens tidigare erfarenheter av projekt har bland annat visat hur viktigt det är att kom-munikationen mellan gruppmedlemmarna fungerar. I tidigare projekt har bristfällig kom-munikation lett till att flera personer arbetat på överlappande områden och uppgifter, vilketinneburit bortslösade arbetstimmar. Det var därför viktigt för varje gruppmedlem att vetavad andra gruppmedlemmar arbetade på för att undvika duplicerat arbete. I samma andahar tidigare projekt lidit när gruppmedlemmar väntat med att be om hjälp eller berättat attde 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

5

2.4. Projektgruppens tidigare erfarenheter

främja en öppen och ickedömande attityd hos varje gruppmedlem för att på så sätt öppnaupp för god kommunikation där medlemmar frågar varandra om hjälp eller råd när något ärproblematiskt.

Utöver detta har gruppen även kommit fram till att det är av värde att ha en tydlig struktur ihur arbetet ska utföras och att ha en tydlig tidsplan över när delmoment ska utföras. Gruppenhar ä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 delarav utvecklingsprocessen.

6

3 Teori

Det här kapitlet beskriver teorin som ligger till grund för rapporten. Läsaren bör känna tillhur arbetssätt kan utformas efter utvecklingsramverket Scrum och underlättas av verktygsom till exempel Git, Trello och Slack. Förutom teori som relaterar till arbetssätt beskrivsramverk och verktyg för utveckling, vad ett API är, hur en databas är strukturerad och huren 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 ochversionshanteringsverktyget 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 dokumentskrivningi LaTeX, Google Drive för att lagra viktiga projektfiler samt Google Calendar för att hålla kollpå 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årgö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 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 avtidsestimeringarna och prioriteringsordningen i stacken beslutar projektgruppen vilka upp-gifter som ska utföras. Det rekommenderas att bryta ned uppgifter i mindre aktiviteter undersprintplaneringen för att få en bra uppfattning om de är lämpade för den tänka sprinten.

7

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 skautföra uppgifterna som ingår i sprinten [2]. Det är upp till dem själva att dela upp arbetet ochbesluta 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 vanligtatt 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, vilkaframsteg 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 gjortsunder den gångna sprinten [2]. Det är viktigt att en konversation hålls med eventuella kundereller sponsorer för att ge dem en chans att utvärdera nya funktioner och guida den framtidautvecklingen i rätt riktning. Sprintgenomgången innebär en tvåvägskommunikation mellanutvecklare 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 framvad som fungerat bra och mindre bra under sprinten som varit. På så sätt kan projektgruppengöra justeringar i processen så att nästa sprint kan fungera bättre. Efter sprintutvärderingenbö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 ettprojekts 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 ettcentraliserat 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öratt samordna koden mellan flera utvecklare.

Grundidén är att varje utvecklare kan hämta den senaste versionen av koden, för att sedangöra sina egna ändringar och överföra dem till det centrala arkivet så att andra utvecklarekan 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 attkunna gå igenom historiken för att se den senast fungerande versionen av koden.

8

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]. Engren kan ses som en kopia av projektet som kan modifieras parallellt med andra grenar. Oftaanvänds en huvudgren som innehåller projektets fullständiga historik, och nya grenar skapasfö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 vissafall kan Git automatiskt resonera fram hur de olika ändringarna bör sammanfogas, men oftabehöver användare själva inspektera ändringarna och manuellt sammanfoga dem. För störreprojekt 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 medGit [3]. Tjänsten inkluderar även diverse administrativa funktioner för att hantera de projektsom 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 tillen särskild server. Denna server kommer i sin tur att försöka bygga applikationen och närdetta är klart blir det synligt på projektets GitLab-sida ifall applikationen kunde byggas utanfel. Detta ger en grundläggande försäkran om att applikationen saknar enkla fel av typensom 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 beskrivningfinnas. Det finns även tillägg till Trello som möjliggör hierarkier av kort. På så sätt kan ettkort 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 nyalistor 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]. Omett 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 mjukvaradiskuteras och en annan där hårdvara diskuteras. Vem som har tillgång till en specifik kanalkan 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 kananvä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 ibland 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-dokumentsamtidigt [8]. Det finns även stöd för förhandsvisning av dokumentet, versionshantering,stavningskontroll och PDF-generering.

9

3.2. En webbapplikations arkitektur

3.1.7 Google Drive

Google Drive är en molnlagringstjänst som finns tillgänglig i webbläsare, smarttelefoner ochsurfplattor [9]. Filer som laddas upp till en användares Google Drive kan sorteras i mapparoch delas med andra. Det finns även stöd för att skapa dokument som alla med tillgång tillkan 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 skapakalendrar som kan delas med andra. Det innebär att om en händelse läggs till i en gemensamkalender visas den hos alla som delar på kalendern. Det är på så sätt enkelt att samordnamö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ätverkoch 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 iprojektet 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 somJavaScript 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-pagewebbapplikationer [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 delaupp applikationen i små komponenter där varje komponent utför ett eget arbetsområde. Tillvarje komponent tillhör en mall där utvecklaren beskriver komponentens utseende. Dessakomponenter går även att återanvända.

Tjänster används för att förmedla information mellan komponenter om informationen intehar någon tydlig arvshierarki [13]. Direktiv används för att ändra utseendet eller beteendetav en mall. Pipes används för att ändra den visuella datan i applikationen.

10

3.4. API

3.3.3 Material Design for Angular

Material Design for Angular är ett front-end bibliotek byggt med Angular och TypeScriptav 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-pagewebbapplikationer.

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. Detingå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]. Dennaplattform är asynkron och händelsedriven, det vill säga att platformen väntar på händelseroch sedan ger svar baserat på händelsen. En sådan struktur gör det lätt att designa skalbaraback-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å utvecklarenlä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 implementationav 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ändareskulle 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 somkrä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]. Dettakan göras via anrop till ett API (Application Programming Interface) tillhörande det and-ra programmet. Funktionaliteten hos ett API och hur den ska användas specificeras i dessdokumentation. 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.

11

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 raderoch kolumner. Betrakta till exempel en tabell med användare. Då representerar varje rad enanvändare medan kolumnerna innehåller data om användaren så som namn, personnummereller 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 tabellmed 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 ävenviktigt att krav på tabeller och fält ställs för att göra datan som lagras mer konsekvent och föratt ö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 samtvilka delar som är beroende av varandra. En systemanatomi kan vara en bra grund för pro-jektplanering och beslutstagande.

12

4 Metod

Det här kapitlet beskriver projektets arbetsgång, vilka ansvarsområden varje medlem hadeoch hur produkten utvecklades. Slutligen beskrivs också hur gruppen fångade erfarenheteroch kontinuerligt utvärderade projektarbetet och dess resultat.

4.1 Projektmedlemmar och roller

Alla projektmedlemmar hade en huvudroll inom projektet. Projektmedlemmarnas roller gesi 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 ochteamledaren kommunicerade med varandra och handledaren. Veckomöten, övriga mötenoch en gemensam kalender användes också för att samordna projektgruppen. Kontaktenmed kursansvarig gick via teamledaren medan kontakten med kunden gick via analysansva-rig. Teamledaren och analysansvarig var tillsammans ansvariga för att presentera produktensstatus 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 teametutåt. Denna såg till att processer följdes och svarade för arbetsmiljö. Teamledaren hadehuvudansvaret för projektplanen.

13

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örkodstandarden.

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. Dennaplanerade och budgeterade med övriga gruppen. Kvalitetssamordnaren hade huvudansvaretför kvalitetsplanen.

Dokumentansvarig ansvarade för att förbereda dokumentmallar för resten av gruppensamt korrekturläsa färdiga dokument innan inlämning. Denna ansvarade för ändringsrutineroch leveranser till deadlines. Dokumentansvarig hade även ansvar för dokumentstandarden.

14

4.2. Dokumentation

Konfigurationsansvarig beslutade om vad som skulle versionshanteras samt vad somingick i en utgåva. Denna bestämde och ansvarade även för vilka verktyg som användesfö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 verktygetOverleaf, medan för mindre dokument som statusrapporter och mötesprotokoll användesGoogle 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 iprojektet 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 ochfunktionalitet.

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 avslutprodukten 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 internastandarder fram. De olika standarderna säkerställde att utvecklingen skedde på liknande sättsamt att det arbete projektgruppen gjort ska vara lätt att sätta sig in i för vidareutveckling ochunderhå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 attgemensamt arbeta efter.

15

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 attfö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ördemånga oönskade begränsningar. Det beslutades att projektet skulle delas in i sprintar enligtScrum-ramverket, men att dagliga möten ansågs onödiga eftersom utvecklingen ej ägde rumpå heltid. Projektet delades in i fem olika sprintar där varje sprint huvudsakligen bestod avtvå 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 medlemmarnahade blivit mer vana kunde utvecklingen delas upp och ske individuellt. Gruppen träffadesdä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ångnaveckan samt för att planera den kommande veckan. På detta möte skrevs en sammanfattningav vad som gjorts under veckan samt vilka risker i projektet gruppen ser för kommandeveckan.

I slutet av varje sprint utvärderades resultaten som framställdes utifrån målen som sattesupp i början av sprinten. Om inte alla mål hade uppnåtts beslutade gruppmedlemmarna hurde skulle gå vidare för att uppnå målen under nästkommande sprint. Dessa utvärderingargjorde 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 gaven bra översikt och uppfattning av hur gruppen låg till. Det gav även en översikt över vemsom 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 projektetshelhet.

16


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ötenoch mjukvarurelaterade frågor och diskussioner.

När gruppen bokade in möten gjordes detta via en gemensam kalender på Google Calendarsom alla hade tillgång till. Bokningarna gick till så att gruppen kom överens om att ses enviss dag och tid varpå någon av medlemmarna lade in detta i kalendern. Dagen innan mötetfick 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 beslutkring utvecklingen gemensamt på möten eller via Slack. Det var även lätt att få hjälp omnågon hade problem med någon del i utvecklingen bara genom att ta upp det på ett möteeller 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 rumi början av utvecklingen men förekom även mot slutet. Designmöten som projektgruppenhade gick ofta ut på att göra en skiss på en whiteboardtavla. På detta sätt gick det snabbt attvisualisera 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å skulle 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 toppen av en tabell varje gång användareninteragerade med den, så att information och funktionalitet kunde visas högst upp. Det visa-de sig dock inte fungera så bra, därför beslutade sig projektgruppen för att använda modalerinnehållande information och funktionalitet istället. På så sätt behövde användaren aldrigbläddras bort från positionen i tabellen den befann sig på, för att till exempel se detaljeradinformation om någonting från tabellen.

17


Ett designbeslut som togs i slutet av utvecklingen handlade om hur PDF:en för kvittenserskulle se ut. En skiss visas i figur 4.3 och slutresultatet kan ses i figur 5.18 i kapitel 5.1.6. Andradesignbeslut som togs under projektets gång var exempelvis hur knappar skulle placeraseller 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 kvalitetsplan. I den redogjordes hur dokument och kod skulle granskas samthur ändringar av dessa fick göras. Alla gruppmedlemmar uppmanades att använda kod-rättningstillägget TSLint. I kvalitetsplanen definierades även gruppmedlemmarnas roller ikvalitetsarbetet, till exempel vem som skulle kontaktas om en ändring behövde göras i ettvisst 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 uppfylla enligt kravspecifikationen var uppfylldainnan 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. Eftersomdet oftast fanns minst en medlem som hade tidigare erfarenheter inom något område kundeutbildningen ske till stor del genom att medlemmarna hjälpte varandra. Förutom detta söktegruppen tidigt upp olika guider på internet som delades i Slack. Planeringen tog hänsyn tillatt 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.

18


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 kundeninte 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 aktiviteterutfördes. Detta var ett bra sätt att gå igenom hela projektet, dela upp det i mindre delar ochfå en bild av hur det skulle genomföras. Det var värdefullt att bestämma i vilken ordning alladelar skulle utvecklas samt förtydliga vilka delar som gick att arbeta på parallellt. Det endasom å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 omdesign, exempelvis vilka typer av ikoner och indatakomponenter som skulle användas föratt 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 ochstrategier 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älpav 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å 2800timmar. 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 lokalerför projektet utan utvecklingen ägde främst rum på Linköpings universitet. Enligt avtal medkund 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öratt det underlättade utvecklingen. Versionshanteringen som valdes var GitLab eftersom allahade 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 äratt 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 ensammanfogningsförfrågan är att en annan projektmedlem måste godkänna koden innan den

19

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 ochkontrollerades 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 minimeraderas 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, eventuelltminska på aktiviteter. Isista hand omförhandlamed kund

Missförstånd medkund 4 2 8 Kontinuerlig avstämning

med kund

Serverfel 2 2 4 Tillhandahålla ny server

Lokalbrist 2 4 8 Diskussion med kursan-svarig

Webbapplikationenfungerar inte i allawebblä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 gjortunder den senaste veckan. Då fanns även tillfälle för de övriga medlemmarna att ställa frågorom de var nyfikna på någonting.

I slutet av varje sprint hölls en sprintåterblick för att gruppmedlemmarna gemensamt skullereflektera över erfarenheter från den gångna sprinten. På så sätt kunde de komma fram tillvad som skulle kunna göras annorlunda under nästa sprint. Under alla möten fördes ävenprotokoll vilket innebar att om en projektmedlem var frånvarande så fanns ändå möjlighetenatt ta del av det som togs upp.

20

5 Resultat

I detta kapitel presenteras projektets resultat. I resultatet ingår en systembeskrivning av detslutgiltiga systemet, vad projektet har för värde för kunden, de gemensamma erfarenheternasom 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årakort, 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 registreranya kort, handlingar och leveranser. Kort och handlingar kan sedan kvitteras ut och spårasfö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 andrafö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 MariaDBdatabas, 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 Designfor Angular för bland annat knappar, inmatningsfält och modaler. Webbapplikationen är ensingle-page application.

Figur 5.1: Ingående delsystem

21

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änsterRegistrera handlingar

Generera dokument

Registrera kvittenser

Användar- inloggning

Utforska innehåll

Listainnehåll Lista loggar

Filtrera

Ändra innehåll

Användar- inloggning input

Kvittenserinput

Välja dokument-innehåll

Handlingarinput

Kvittens i pdf

Logga in användare

Generera dokument

Spara dokument

Registrera kvittens

i databas

Registrerahandlingi 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 detska vara.

22


Administratörer

Administratörsanvändare skiljer sig från vanliga användare genom att dessa användare intekan ha några kort eller handlingar utkvitterade till sig. Istället är det administratörerna somkvitterar ut kort och handlingar till vanliga användare.

Kort, handlingar och leveranser har egna vyer med tabeller där administratören kan lägga tilleller ä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 liknaren 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 visaralla användare där administratören kan lägga till nya användare eller ändra information somrör en befintlig användare. Till sist finns en vy som visar alla kort- och handlingstyper däradministratö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 angivitsgenom att hashfunktionen bcrypt appliceras på lösenordssträngen. Sedan sparas aldrig detfaktiska 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örsmed det som finns lagrat i databasen. Om strängarna är lika betyder det att lösenordet somangivits 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åndatabasen.

5.1.4 UI-design

Fokuset för webbapplikationens UI-design är att den ska vara lätt att använda och samtidigtha 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 användarenloggat 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å attde olika flikarna ska vara enhetliga i sin design, därav visas alla flikars information i form avtabeller, se figur 5.4.

23


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 tydligaoch att det skulle vara enkelt att förstå vad som händer när användaren klickar på en specifikknapp. För att beskriva hur webbapplikationen fungerar visas tre typiska användningsfallsom webbapplikationen kommer att användas till. Alla användningsfall är utförda av en ad-ministratörsanvändare.

24


1. Kvittera ut ett specifikt kort

Det första en användare ser i webbapplikationen är en inloggningssida. När en användareska 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 figur5.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.

Figur 5.6: Tabell med kort

25


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-id i sökfältet. Det aktuella kortet är nu det endakortet 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örvaringsplatsför kortet, se figur 5.8.

Figur 5.8: Modal för att kvittera ut ett kort

26


Det finns också möjlighet att skriva en kommentar och att generera en kvittens i form av ettPDF-dokument. När användaren klickar på KVITTERA UT i modalen kvitteras kortet ut. Omalternativet att generera kvittens är ifyllt får användaren två val, att ladda ned dokumenteteller 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 inloggningenklickar användaren på fliken inventering. En tabell med alla tillgängliga eller utkvitteradekort och handlingar visas då till höger om menyn, se figur 5.10.

Figur 5.10: Inventering

27


Användaren vill i det här fallet inventera alla kort av typen GEID och sorterar därför eftertyp 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ågaranvändaren om en PDF ska genereras från de framfiltrerade resultatet eller de markeradekorten, se figur 5.13. Användaren väljer då att generera en PDF från de markerade korten ochett inventeringsunderlag skapas.

28


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 iwebbläsaren. Användaren laddar ned dokumentet och stänger modalen. Efter att användarenfysiskt har inventerat korten klickar användaren på knappen Verifiera. Efter att användarenhar bekräftat verifieringen i en modal är verifieringen genomförd vilket kan ses genom attdatumet för senaste verifieringen har uppdaterats, se figur 5.14.

Figur 5.14: Alla kort av typen GEID har nu blivit inventerade

29


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 somber 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.

Figur 5.16: Modal för lägg till ny handling

30


När modalen är korrekt ifylld klickar användaren på knappen SPARA. Handlingen är nutillagd i systemet. För att visa mer detaljer kring handlingen kan användaren klicka på hand-lingens rad i tabellen. En modal kommer då upp som visar alla detaljer kring handlingen, sefigur 5.17.

Figur 5.17: Modal för detaljer om en handling

5.1.6 PDF-generering

Vid genereringen av en PDF skickas all relevant data till servern där den stoppas in i enmall. Detta gäller för alla kvittenser, inventeringar och liststrukturer. PDF:erna i detta projektgenereras med hjälp av biblioteken html-pdf och ejs [23, 24].

Vid utkvittering skapas två nästan identiska sidor, en för registratorn och en för användaren,exempel på användarkopian kan ses i figur 5.18. På användarkopian finns utöver informationom kortet och plats för signaturer, även utrymmen för att göra egenkontroller. Det innebäralltså att en användare kan manuellt verifiera att kortet eller handlingen fortfarande finnsdär det ska vara utan att behöva logga in i SecTrack. Skillnaden mellan registratorkopian ochanvändarkopian är att registratorkopian inte innehåller några fält för egenkontroller.

Då PDF:erna för inventeringen och listorna inte har någon bestämd storlek behövs mallarsom kunde ha en dynamisk storlek. På så sätt kan mallarna fyllas i med en större mängdobjekt i taget. Efter att mallen sedan konverteras till den slutgiltiga PDF:en syns typen och ID:tför kortet eller handlingen, platsen objektet förvaras på, vilken användare, om någon, somhar hand om kortet eller handlingen och den kommentar som tillhör objektet. Ett exempel påen sådan lista kan ses i figur 5.19.

31


Figur 5.18: Kvittensmall användarkopia

32


Figur 5.19: Inventeringsmall

5.1.7 Databasstruktur

För att lagra all data i SecTrack användes en databas med 14 olika tabeller. De primära tabel-lerna, som utgör hälften av alla tabeller, är de tabeller som innehåller objekt för att visas uppi någon av webbapplikationens tabellistor. I figur 5.20 visas databasens primära tabeller samtderas fält. De kvarvarande sju sekundära tabellerna innehåller objekttyper. Figur 5.21 visardatabasens sekundära tabeller samt deras fält.

33


Figur 5.20: Databasens primära tabeller

Figur 5.21: Databasens sekundära tabeller

34


Figur 5.22: Fullständig struktur med länkar för tabellen Dokument

I databasen finns flera fält länkade till andra fält. Exempelvis länkar fältet Dokumenttyp ID itabellen Dokument till fältet ID som finns i tabellen Dokumenttyp. Den fullständiga strukturenmed länkar för tabellen Dokument visualiseras i figur 5.22. På liknande sätt är andra tabellerlänkade till olika delar av databasen, vilket medför att ingen data i databasen dupliceras.

De olika fältens syfte i de olika tabellerna är följande:

• Aktiv kvittens: Länk till fältet ID i tabell Kvittens.

• Användarnamn: Användarnamn för att logga in i systemet.

• Användartyp ID: Länk till fältet ID i tabell Användartyp.

• Avsändare ID: Länk till fältet ID i tabell Användare.

• Dokument ID: Länk till fältet ID i tabell Dokument. Enbart ett av fälten Kort ID ochDokument ID kan ha ett värde som indexerar mot respektive tabell. Vilket fält som äraktivt bestäms av fältet Objekt typ ID.

• Dokument datum: Daterat datum på objektet.

• Dokumentnummer: Unikt serienummer som tillhör ett dokument eller en leverans.

35


• Dokumenttyp ID: Länk till fältet ID i tabell Dokumenttyp.

• ID: Unik identifierare för varje objekt i respektive tabell.

• Kommentar: En eventuell kommentar till objektet som kan till exempel beskriva vadobjektet är till för eller vad en användare får göra.

• Kort ID: Länk till fältet ID i tabell Kort.

• Kortnummer: Unikt serienummer för ett kort.

• Korttyp ID: Länk till fältet ID i tabell Korttyp.

• Logg data: Beskrivning av händelsen för loggen.

• Logg datum: Datum som loggen fördes in i databasen.

• Loggtext: En beskrivning av vad loggningstypen innebär.

• Loggtyp ID: Länk till fältet ID i tabell Loggtyp.

• Lösenord: Krypterat lösenord för att logga in i systemet.

• Mejl: Kontoinnehavarens mejladress.

• Modifierat datum: Datum som objektet senast är modifierad i databasen, exempelvisdå objektet bytte förvaringsplats eller kvitterades.

• Mottagare: Mottagare av leveransen.

• Namn (Användare): Förnamn och efternamn för kontoinnehavaren.

• Namn: Namn eller beskrivning på objektet.

• Objekt typ ID: Länk till fältet ID i tabell Objekttyp för att specificera vilken typ objektetär, exempelvis ett kort eller en handling.

• PDF namn: Namn på genererad PDF.

• Plats: En fysisk plats som objektet förvaras när den inte används.

• Registrerat datum: Datumet som dokumentet registreras som inkommet, ej nödvän-digtvis samma datum som dokumentet förs in i databasen.

• Senast verifierad: Datum då objektet senast verifierades.

• Skapat datum: Datum som objektet är inlagd i databasen.

• Skickat datum: Datumet då objektet skickades.

• Slut datum: Datum för inkvittering av ett objekt.

• Start datum: Datum för utkvittering av ett objekt.

• Status ID: Länk till fältet ID i tabell Statustyp som beskriver vilket tillstånd objektetbefinner sig i. Exempel på status är utkvitterat och arkiverat.

• Sändare: Personen eller organisationen som skickat dokumentet.

• Utgångsdatum: Utgångsdatum för ett kort.

• Verifiering datum: Datumet som verifieringen utfördes i systemet.

• Verifieringstyp ID: Länk till fältet ID i tabell Verifieringstyp.

36

5.2. Värde för kunden

5.2 Värde för kunden

Projektet har givit värde för kunden genom att de fått tillgång till ett bättre alternativ tillderas nuvarande system. Produkten kommer förbättra effektiviteten i arbetet och underlättaorganiseringen. En annan värdefull aspekt med projektet är att det är enkelt att vidareutveck-la systemet. Detta eftersom systemet är utvecklat med det modulära ramverket Angular ochlevererades med dokumentation som beskriver det. Kunden kan själv lägga till funktionalitetsom de känner saknas eller kommer på vid ett senare tillfälle.

5.3 Gemensamma erfarenheter

Projektets medlemmar hade sedan tidigare erfarenhet av att arbeta i grupp, men aldrig i ettmjukvaruprojekt av den här storleken. För att alla projektmedlemmar skulle kunna arbetaeffektivt i gruppen krävdes att projektmedlemmarna höll god kontakt med varandra. Dettaför att försöka undvika att samma arbete utfördes på flera håll, eller på ett onödigt krångligtsätt. Projektgruppen försökte ofta sitta tillsammans och arbeta, men eftersom att det vid vissatillfällen inte fanns en ledig lokal så var detta inte alltid möjligt. Flera medlemmar i gruppentyckte också att det var enklare att programmera hemifrån, där en bättre dator fanns tillgäng-lig. Detta ledde till att gruppen arbetade tillsammans mer sällan mot slutet av projektet. Kon-takt mellan gruppmedlemmar hölls då via Slack och möten, vilket fungerade bra, men dethade troligtvis fungerat bättre om gruppen arbetat tillsammans eftersom kommunikationendå blir smidigare.

Alla medlemmar i projektet hade någon form av tidigare erfarenhet gällande versionshan-tering, dock saknade vissa projektmedlemmar erfarenhet av utvecklingsmodellen FeatureBranch Workflow som projektgruppen använde sig av. Detta ledde ibland till väldigt storasammanfogningsförfrågningar, som vidare ledde till många konflikter i koden. Ibland händedet att flera sammanfogningsförfrågningar hamnade i kö, vilket hade som konsekvens attprojektmedlemmen som skickat in sin sammanfogningsförfrågan sist, fick revidera sin kodatt passa med den projektmedlem som skickat in sin kod först. Dessa konflikter ledde till attde möten vi hade för att granska och slå samman kod ibland tog väldigt lång tid.

Samtliga projektmedlemmar har lärt sig mycket inom webbprogrammering, speciellt medramverket Angular 5. Flera av projektmedlemmarna hade ingen tidigare erfarenhet av var-ken webbprogrammering eller Angular, vilket ledde till en stor ökning i kunskap inom des-sa områden. En av projektmedlemmarna hade sedan tidigare erfarenhet av både webbpro-grammering och Angular vilket var till stor hjälp för projektgruppen, speciellt i början avutvecklingen. Projektgruppen har under hela projektet bytt erfarenheter och försökt hjälpavarandra med problem som uppstått. Detta har bidragit till en god gruppdynamik och ettbra kunskapsutbyte mellan samtliga projektmedlemmar.

För flera av projektmedlemmarna var detta första gången som de arbetade med iterationeroch Scrum. Det har varit en givande erfarenhet, speciellt eftersom planeringen av projektetskett kontinuerligt istället för vid projektets start. Detta medförde även att hela projektgrup-pen blev involverad i alla moment av planeringen, vilket gett en bättre helhetsblick överprojektet för alla projektmedlemmar.

37

5.4. Översikt över individuella bidrag

5.4 Översikt över individuella bidrag

Denna del ger en kort översikt över de individuella bidragen i rapporten.

5.4.1 Balans mellan olika testnivåer vid agil systemutveckling av AndreasLundquist

Detta bidrag reflekterar över balansen mellan olika testnivåer vid agil systemutveckling ochspecifikt hur balansen sett ut under detta projekt. Detta för att sedan undersöka potentiellaförbättringsmöjligheter och diskutera dessa tillsammans med de erfarenheter som samladesunder projektets gång.

5.4.2 Kundinverkan vid agil mjukvaruutveckling av Daniel Herzegh

Detta bidrag undersöker hur de tekniker och strategier som förespråkas av utvecklingsram-verket Scrum kan användas för att producera en slutprodukt som är i linje med kundensförväntningar. Bidraget redovisar detta genom att jämföra det projektarbete som har utförtsav projektgruppen med en litterär studie utförd av bidragets författare.

5.4.3 Sårbarhet för Cross site scripting (XSS) i en webbapplikation av DavidHasselquist

Detta bidrag undersöker vilka kategorier av XSS-attacker en webbapplikation kan utsättas föroch vad som är utmärkande för dessa kategorier. Därefter ämnar studien sig åt att studerade grundläggande metoder och åtgärder som finns för att skydda sig mot XSS-attacker. Bi-draget redogör även hur webbapplikationen SecTrack kan skyddas genom att tillämpa dessametoder.

5.4.4 Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren

Detta bidrag undersöker vad som gör en webbapplikation sårbar mot SQL-injektioner ochvad utvecklare kan göra för att minska risken för att en webbapplikation utsätts för dem.Bidraget redogör även för eventuella säkerhetsbrister i SecTrack.

5.4.5 Implementation av kontinuerlig leverans av Johan Lind

Detta bidrag undersöker hur processen kontinuerlig leverans kan användas vid utvecklingav ett interaktivt system. Bidraget redogör även för vilka delar av teorin om kontinuerligleverans som saknas från utvecklingsprocessen bakom SecTrack.

5.4.6 Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson

Detta bidrag undersöker vilken påverkan arbetsmiljöer kan ha på det egna arbetet samt huren grupp arbetar tillsammans med en gemensam uppgift. Bidraget kommer även att under-söka hur olika saker i arbetsmiljöer kan göra arbetetet lättare eller svårare.

5.4.7 Vikten av kodstandarder och effektiv kod av Philip Bengtsson

Detta bidrag undersöker hur en kodstandard påverkar effektiviteten vid programvaruut-veckling och hur den påverkar underhållbarheten hos programvaran. Dessutom undersökerbidraget vad som påverkar energiförbrukningen hos programvaror.

38

6 Diskussion

I det här kapitlet diskuteras projektets resultat samt metoder som använts. Dessutom disku-teras hållbar utveckling med avseende på miljöpåverkan, etik och social inverkan.

6.1 Resultat

I den här delen av kapitlet diskuteras alternativa val av ramverk och implementationssättsamt vilket arbete som kvarstår för att kunden ska få ut fullt värde av produkten. Till sistdiskuteras vilka egenskaper som har utvecklats sedan tidigare projekt samt vilka lärdomarsom kan tas med inför framtiden.

6.1.1 Alternativa implementationssätt

Här tas alternativa implementationssätt som projektgruppen övervägde upp. Dessa inklude-rar alternativa ramverk för front-end och back-end samt val av databasmjukvara.

Front-end ramverk

När ramverk för front-end skulle väljas var det två som övervägdes, React och Angular. Detsom gjorde att Angular slutligen valdes över React var att en projektmedlem hade tidiga-re erfarenhet av webbutveckling i Angular medan ingen tidigare erfarenhet av React fannsbland projektmedlemmarna. Ytterligare en anledning till att Angular valdes var att front-enddå blir modulär.

Ett alternativ till att använda färdiga komponenter från Bootstrap och Material Design forAngular hade varit att utveckla egna komponenter. Att använda färdiga komponenter varenkelt och sparade tid jämfört med att utveckla egna, det uppstod heller aldrig något behovav någon komponent som inte fanns i varken Bootstraps eller Angulars utbud av komponen-ter. Därför valde gruppen att enbart använda färdiga komponenter i applikationen.

Back-end ramverk

Några exempel på ramverk för back-end-utveckling i en webbapplikation är:

• NodeJS som skrivs i JavaScript eller TypeScript [16, 25].

• Play Framework som skrivs i Java eller Scala [26].

• Django som skrivs i Python [27].

39

6.1. Resultat

När det hade beslutats att Angular skulle användas som ramverk för front-end resonera-de projektmedlemmarna att ett ramverk som också kan skrivas i TypeScript vore passandeför back-end. Då skulle all kod i projektet vara skriven i TypeScript vilket skulle underlättakodskrivning och kodgranskning. Det enda alternativet som övervägdes då var NodeJS somockså valdes.

Databasmjukvara

Ett av kundens krav var att databasmjukvaran skulle ha öppen källkod. Kunden föreslog attvi skulle använda MariaDB som är en känd databasmjukvara som används av stora företagsom Google, Wikipedia och Facebook [28]. Alternativ mjukvara som hade kunnat användasvar till exempel MySQL. MySQL ägs av företaget Oracle och har i grunden öppen källkod.Dock drivs utvecklingen inte längre av engagerade utvecklare, vilket annars brukar känne-teckna mjukvara med öppen källkod, utan av Oracle själva. I slutändan vägde kundens re-kommendation tyngst. MariaDB är utvecklat av samma personer som utvecklade MySQL ochhar samma grundfunktionalitet. Säkerhet är dessutom MariaDBs utvecklares främsta priori-tet.

6.1.2 Kvarstående arbete

För att kunden skall få ut fullt värde av produkten återstår att ersätta testdatan i databasenmed verklig data. Ett sätt att göra detta är att manuellt lägga till alla kort, handlingar och le-veranser som behöver finnas i databasen. Alla användare, inklusive administratörer, som skaanvända applikationen behöver konton för att kunna logga in. Eventuellt kommer kunden attanvända sig av en befintlig databas över användare genom att integrera den med SecTrack.

6.1.3 Utveckling sedan tidigare projekt

Vikten av god kommunikation i ett projekt är någonting som togs upp ur flera aspekter ikapitel 2.4 om tidigare erfarenheter. Dålig kommunikation kan både leda till dubbelarbeteoch till att uppgifter inte blir gjorda. Kommunikationen är dock något som fungerade väldigtbra genom hela projektet. Anledningen till det är att gruppen lade stor vikt vid att allas åsikterskulle bli hörda. Även om mycket arbete skedde enskilt gjordes sprintplanering, fördelningav arbetsuppgifter och framtagning av gränssnittsskisser alltid gemensamt. Det fanns ävenalltid någon i gruppen att fråga om hjälp när problem uppstod.

Ett annat sätt gruppen har utvecklats på är i hur kodoch designstandarder har använts.Redan när utvecklingen började fanns tydliga riktlinjer. För att all kod skulle följa sammastandard uppmanades alla medlemmar använda kodrättningstillägget TSLint. För att appli-kationens design skulle bli konsekvent listades vilka komponenter och ikoner som skulleanvändas i applikationen. På grund av dessa riktlinjer har gruppen troligtvis sparat tid somannars hade behövts spenderas på att justera kod och designdetaljer i applikationen.

6.1.4 Lärdomar inför framtiden

En viktig lärdom som projektmedlemmarna tog med sig från det här projektet var vikten avatt hålla en aktiv dialog med kunden. Genom att regelbundet visa upp vad som hade åstad-kommits kunde kunden komma med feedback och eventuella missförstånd kunde uppmärk-sammas i god tid innan produkten skulle levereras.

En annan lärdom som projektet givit är förståelsen att det kan vara värt att lägga lite extratid på en implementation om andra delar sedan bygger på den. Flera delar av systemet tänk-tes inte igenom och utvecklades snabbt för att komma igång med resten av projektet. Detskapade senare problem när dessa delar behövde ändras.

40

6.2. Metod

Ett exempel på en implementation som ändrades mitt i projektet är de olika datamodellerna.Datamodellerna innehöll från början ett fält med ett index som pekar på ID:t på en annantabell. Senare gjordes denna implementation om så att datamodellen innehåller hela objektetav typen istället för enbart ID:t på typen. Eftersom implementationen gjordes om mitt i pro-jektet behövdes mycket kod skrivas om. Många arbetstimmar, som användes för att anpassaden föregående implementationen, gick till spillo.

6.2 Metod

Projektgruppen bestämde sig i början av arbetet för att använda sig av utvecklingsramverketScrum, med ett antal modifikationer för att bättre passa detta projekt. Beslutet att avstå frånde dagliga möten som normalt ingår i Scrum kan i efterhand anses vara lyckat, då lokalbristskulle ha gjort det mycket svårt att ses dagligen och mycket extra tid skulle ha ägnats åt att tasig till dessa möten. Ett alternativ skulle varit att ersätta dessa fysiska möten med en dagligstatusrapport via t.ex. Slack, där varje gruppmedlem berättar om vad de har gjort, vad deplanerar att göra och potentiella problem. Detta kunde potentiellt ha varit värt att implemen-tera, då det skulle ha minskat risken för missförstånd med relativt liten tidsåtgång. Bristenpå dagliga rapporter eller möten anses inte ha lett till några större problem, då gruppen ändåträffades flera gånger i veckan under större möten. Dock kunde dagliga rapporter via Slackpotentiellt ha minskat behovet av dessa möten och därmed kunde gruppen ha hållit kortaremöten och på så vis sparat tid.

Ett alternativ till att arbeta agilt hade varit att använda vattenfallsmodellen, där en mer detal-jerad planering sker i början av projektet och följs av en lång period då implementation sker.Projektgruppen var oerfaren gällande utveckling av webbapplikationer i större projekt ochlärde sig mycket under projektets gång. På grund av detta skulle det ha varit ett misstag attlägga ännu större fokus på en detaljerad planering i början av projektet när kunskapen varsom absolut lägst och ovissheten var mycket stor. Den agila utvecklingen gav också möjlighetatt demonstrera en prototyp för kunden vid slutet av alla iterationer. Återkopplingen underdessa tillfällen hjälpte gruppen få med all funktionalitet som kunden önskade och såg till atttid inte slösades på att utveckla funktionalitet som inte var nödvändig.

Vid slutet av de senare iterationerna samlades gruppen för att sammanfoga kod inför leve-ranserna. Dessa möten tog lång tid och var relativt kaotiska med buggar som upptäcktes ochfixades på plats. För att undvika detta kunde större fokus ha lagts på att se till att hålla grenar-na små och endast fokusera på utveckling av en funktionalitet. Detta skulle göra det lättareoch mer naturligt att sammanfoga mer kod under sprintens gång och mindre skulle bli kvartill slutet. Det var dock ett mycket bra beslut att ha ett möte just för sammanfogning där allagruppmedlemmar träffades och arbetade tillsammans. Utan ett möte för detta skulle det medall sannolikhet ha blivit ännu mer oorganiserat och fler buggar skulle uppstått.

Projektgruppen hade inte i förväg beslutat att hålla ett bestämt antal möten varje vecka, ut-an schemalade istället dessa utefter behov. Detta fungerade bra då behovet av möten kundevariera mycket mellan olika veckor och mindre flexibilitet hade troligen lett till lägre tidsef-fektivitet.

41

6.3. Arbetet i ett vidare sammanhang

6.3 Arbetet i ett vidare sammanhang

Projektgruppen har försökt att utveckla systemet med medvetenhet om hållbar utvecklingmed fokus på miljö-, etiskt- och socialt perspektiv.

6.3.1 Miljöperspektiv

Det finns flera faktorer i systemet som spelar in i begreppet hållbar utveckling från ett miljö-perspektiv. Systemet i sig kräver ingen förbrukning av papper, men kan generera många olikaPDF-dokument som är tänkta att skrivas ut och användas av kunden som mallar. I nulägetskapar kunden sina utskriftsmallar manuellt, något som webbapplikationen automatiserarhelt. Eftersom det blir så pass mycket lättare att skapa utskriftsmallar kommer troligen flersådana mallar att skapas när kunden börjar använda webbapplikationen. Det blir även lättareatt råka skapa en felaktig mall som skrivs ut i onödan.

Energiförbrukningen som systemet kräver är en annan faktor som påverkar miljön. Systemetbehöver en server samt en dator som är igång för att det ska fungera. Även om kunden tidiga-re hade dessa kommer beroendet av dem att öka och så även energiförbrukningen, vilket haren negativ inverkan på miljön. Eftersom hårdvaran hos kunden kommer att användas merminskar troligtvis livslängden på den. Detta gör att kunden måste köpa in nya komponenteroftare, vilket också har en negativ inverkan på miljön.

6.3.2 Etiskt perspektiv

Att som företag erbjuda tjänster där kunders känsliga tillgångar hanteras med garantin omatt dessa kommer att förvaltas säkert innebär att företaget tar på sig att med tillräckliga medelförebygga att dessa tillgångar tappas bort eller hamnar i fel händer. Att lova och garantera ensäker hantering av tillgångar utan att faktiskt kunna tillhandahålla det är uppenbart oetiskt.

Utifrån det etiska perspektivet kan därmed SecTrack-systemet jämföras med den nuvarandeexcel-baserade lösningen. I förhållande till den nuvarande lösningen bidrar systemet till attregistratorn får en bättre överblick över tillgångar som Sectra hanterar. Ansvars- och upp-följningsproblem av tillgångar löses med hjälp av kvittenser som systemet automatiskt gene-rerar. Samtliga ändringar som genomförs på en tillgång loggas i systemet vilket underlättarspårbarhet. Båda dessa funktioner, som saknas i den nuvarande lösningen, minskar därmedrisken för att bland annat sekretessbelagda tillgångar försvinner. SecTrack bidrar därmed påett positivt sätt till Sectras verksamhet sett från ett etiskt perspektiv.

6.3.3 Socialt perspektiv

Ur ett socialt perspektiv bidrar systemet både positivt och negativt. Användare som web-bapplikationen riktar sig till kommer med dess hjälp kunna jobba effektivare, få en välstruk-turerad och enklare översikt av användningsområdet för systemet. Som exempel kommeranvändaren få en bra översikt över var alla kort och handlingar är lokaliserade, samt vemsom har kvitterat ut dem och därmed har ansvar för dem. Eftersom all information kringkorten och handlingarna är lättåtkomlig för användaren kan användaren lägga mindre tidpå att leta reda på dessa samt strukturera upp och skapa dokument, vilket tidigare gjortsmanuellt. Detta leder till att användaren får mer tid över, vilket är positivt.

Systemet bidrar även till att användaren blir beroende av att använda en dator för att kunnautföra dessa uppgifter. Ett ökat datoranvändande kan leda till negativa hälsoeffekter hos an-vändaren. Detta kan dock motverkas genom att användaren är medveten om dessa effekteroch aktivt motarbetar dem.

42

7 Slutsatser

Detta kapitel besvarar rapportens frågeställningar och om projektets syfte uppnåddes.

7.1 Hur kan SecTrack implementeras så att värde för kunden skapas?

Genom att ta fram en kravspecifikation tillsammans med kunden garanterades att slutpro-dukten blev någonting som kunden värdesatte och kunde ha användning av. Genom helaprojektet arbetade projektgruppen iterativt i sprintar med en leverans till kunden i slutet avvarje sprint. På så sätt fick kunden ta del av den senaste utvecklingen i projektet och kom-ma med synpunkter och ändringsförslag. Detta bidrog till att systemet utvecklades genomen öppen dialog mellan kund och projektgrupp. Det medförde också att systemet hela tidenutvecklades i den riktning som kunden ville, samtidigt som projektgruppen fick veta vilkenfunktionalitet som prioriterades högst av kunden.

7.2 Vilka erfarenheter kan dokumenteras från detta projekt som kan varaintressanta för framtida projekt?

Många nya erfarenheter har under projektets gång samlats in av projektgruppen. Projekt-gruppen har fått mycket erfarenhet kring att arbeta i grupp och med agila systemutveck-lingsmetoder. Det har varit en ny erfarenhet och mycket lärorikt för projektgruppen att fåarbeta mot en riktig kund. Det har också varit lärorikt att få utveckla systemet utan någonvägledning från universitetet. Slutligen har projektgruppen fått mycket kunskap om webb-utveckling och sina specifika rollers ansvarsområden.

7.3 Vilka stöd kan fås genom att skapa och följa upp en systemanatomi?

Systemanatomin som gruppen skapade i början av projektet har använts som underlag försystemets uppbyggnad och funktionalitet. Skapandet av systemanatomin bidrog till att pro-jektgruppen fick tänka igenom hela uppbyggnaden av systemet tidigt i utvecklingen. Dettaledde till en del frågetecken som projektgruppen fick räta ut kring implementationerna ochhur systemet skulle byggas upp. Att projektgruppen fick tänka igenom och diskutera dessamoment tidigt under utvecklingen bidrog till att utvecklingen kunde flyta på bättre underden resterande delen av projektet. Uppföljning av systemanatomin gav en kontroll av hurlångt i utvecklingen projektet framskridit och vilken funktionalitet som saknades.

43

7.4. Kan systemutvecklingen i projektet anpassas för att förenkla underhåll ochvidareutveckling i framtiden?

7.4 Kan systemutvecklingen i projektet anpassas för att förenklaunderhåll och vidareutveckling i framtiden?

Projektgruppen har skrivit en utförlig dokumentation kring hela projektet samt dokumente-rat all kod. Systemet är modulärt, vilket gör att kunden enkelt kan vidareutveckla systemetoch lägga till funktionalitet som de vill ha i framtiden. Att systemet är modulärt underlättarockså underhållningen av systemet, eftersom att modulerna är oberoende av varandra.

7.5 Leder ett agilt arbetssätt till att eventuella problem ochförbättringsmöjligheter inom projektet uppmärksammas och kanåtgärdas?

Genom att arbeta agilt har flera problem och förbättringsmöjligheter upptäckts i projektet.Dessa har främst framkommit vid leveranser till kunden som skett i slutet av varje sprint.Lösningar till problemen och förbättringar planerades in och åtgärdades under nästföljandesprint. Om projektet istället följt någon annan utvecklingsmetod, till exempel vattenfallsmo-dellen, skulle dessa problem ha kostat mer för gruppen att åtgärda och hade eventuellt inteupptäckts lika tidigt i utvecklingen.

7.6 Projektets syfte

Projektets syfte, som var att utveckla en användbar och stabil webbapplikation med goda vi-dareutvecklingsmöjligheter, var uppfyllt vid projektets avslut. Applikationen tillfredsställdealla uppsatta krav om kvalitet och funktionalitet och mer därtill. Projektmedlemmarna harlärt sig mycket om programutveckling, webbutveckling, Scrum och att arbeta i större grupp,vilket också var en del av projektets syfte.

44

A Balans mellan olika testnivåer vidagil systemutveckling av AndreasLundquist

A.1 Inledning

Denna rapport avhandlar hur agil systemutveckling påverkar balansen mellan olika nivåerav testning. Med balans menas den tid som läggs ner på testning samt antalet tester somutförs på respektive nivå. Den handlar också om vilka nivåer av testning som är mest essen-tiella för agil utveckling i ett mindre mjukvaruprojekt. De olika testnivåerna som diskuterasär enhetstest, integrationstest och systemtest. Rapporten beskriver hur testning har gått till iprojektet, på vilka nivåer testning har utförts och fördelningen mellan dessa nivåer. Detta föratt sedan diskutera erfarenheter och möjliga förbättringar av upplägget. Det diskuteras ocksåhuruvida balansen mellan testnivåerna skiljer sig då systemutveckling istället följer vatten-fallsmodellen. Speciellt fokus läggs på att hitta en fungerande balans som gynnar kombina-tionen av testning tillsammans med agil systemutveckling.

A.1.1 Syfte

Syftet med denna rapport är att reflektera över balansen mellan olika testnivåer vid agilsystemutveckling och specifikt hur balansen sett ut under detta projekt. Detta för att sedanundersöka potentiella förbättringsmöjligheter och diskutera dessa tillsammans med de erfa-renheter som samlades under projektets gång.

A.1.2 Frågeställningar

Rapporten försöker besvara följande frågeställningar:

1. Vad kan vara en fungerande balans mellan de olika testnivåerna när det gäller agilsystemutveckling i ett mindre mjukvaruprojekt?

2. Skiljer sig balansen mellan testnivåer när det gäller agil utveckling och vattenfallsmo-dellen?

3. Hur kunde balansen mellan testnivåerna i detta projekt ha förbättrats?

A.2 Bakgrund

Som testledare i projektarbetet innebar det att ta det huvudsakliga ansvaret när det gälldetestning. Det var då viktigt att ha kännedom om olika sorters testning och hur dessa kunde

45

A.3. Teori

bidra till att säkerställa hög kvalitet på systemet. Eftersom projektet utfördes under en be-gränsad tid var det viktigt att lägga fokus på de nivåer av testning som bidrog mest till ettvälfungerande system fritt från buggar. För att kunna testa systemet så utförligt och effektivtsom möjligt hade denna rapport som mål att ta reda på vilka nivåer som är viktigast att testai ett mindre mjukvaruprojekt. Detta kombinerades med att försöka hitta en balans mellan deolika testnivåerna som fungerar bra vid agil utveckling. Det ansågs också vara intressant attjämföra detta med hur balansen rekommenderas se ut i mindre mjukvaruprojekt utveckladeefter vattenfallsmodellen.

A.3 Teori

Det här kapitlet beskriver den teori som är relevant att känna till för att förstå resterandekapitel i rapporten.

A.3.1 Testnivåer

Denna del innehåller en grundläggande beskrivning av de olika testnivåerna.

A.3.1.1 Enhetstest

Enhetstestning är den minsta testbara delen i en applikation [29]. Dessa tester ska vara kortaoch normalt bara testa en funktion, modul eller liten del av koden. Testerna ska vara unikaoch gärna oberoende av kod utanför den specifika kod som testas. Enhetstester skrivs normaltav utvecklaren.

A.3.1.2 Integrationstest

Integrationstester testar hur väl olika delar av koden fungerar tillsammans [29]. Dessa typerav tester brukar till exempel utföras då två enhetstestade moduler sammanförs för att se attde fungerar som det är tänkt tillsammans.

A.3.1.3 Systemtest

Systemtestning är till för att testa systemet i sin helhet och utförs efter integrationstestningenär klar [29]. Syftet är att kontrollera att systemet håller de krav som är ställda i till exempelen kravspecifikation. Systemtestning ska vara av typen Black-box-testning, vilket betyder atttestaren inte behöver ha kunskap om hur systemet fungerar.

A.3.2 Vattenfallsmodellen

Vattenfallsmodellen är en systemutvecklingsmodell som har en bestämd struktur [30]. Ut-vecklingen sker i faser där en fas ska vara klar innan nästa fas påbörjas. Faserna brukar van-ligtvis ha följande ordning:

1. Analys.

2. Design.

3. Implementation.

4. Testning.

5. Underhåll.

46

A.4. Metod

Under analysfasen brukar en kravspecifikation skrivas, det är den som beskriver vad syste-met ska klara av. Under designfasen tas designbeslut om olika delar i systemet och underimplementationsfasen skrivs koden. Efter implementation kommer testning av systemet ochsedan slutligen underhåll. Underhållsfasen har ofta inget bestämt slut, men produkten är mereller mindre färdigutvecklad vid det stadiet.

A.3.3 Agil systemutveckling

Agil systemutveckling är en samling av flexibla systemutvecklingsramverk som förespråkaratt jobba med iterationer och i mindre team [31]. Agil systemutveckling beskrivs i ett manifestom fyra punkter enligt följande [32]:

• Individer och interaktioner framför processer och verktyg.

• Fungerande programvara framför omfattande dokumentation.

• Kundsamarbete framför kontraktsförhandling.

• Anpassning till förändring framför att följa en plan.

Dessa punkter leder till att agil systemutveckling passar in i många olika systemutvecklings-ramverk som har liknande värderingar.

A.4 Metod

Detta kapitel beskriver hur testning har gått till i projektet och hur material att jämföra medhar hittats.

Testning har varit en kontinuerlig del av projektarbetet. I början av varje sprint har en test-plan skrivits som beskrivit vilka tester som ska utföras och vad det förväntade resultatenav dem bör vara. Enligt testplanen var det bestämt att alla gruppmedlemmar skulle skrivaenhetstester för sin egen kod, dessa finns därför inte med i testplanen. Det har inte funnitsnågon övergripande kontroll av hur eller om projektmedlemmarna skrivit de enhetstestersom bör ha skrivits. Alla projektmedlemmar har istället litat på varandra och antagit att kodsom lämnats in har varit korrekt skriven och fungerande. Alla sammanfogningsförfrågningarsom lämnats in har dessutom besiktats okulärt innan de godkänts. Några integrationstesterhar inte utförts då detta ansågs vara den minst givande typen av testning för projektet. Iställethar det fokuserats på systemtester för att se till att systemet fungerar som tänkt i sin helhet.

Majoriteten av dessa tester har utförts automatiserat med hjälp av verktyget Protractor [19].Att skriva automatiserade tester tog mycket tid i början av projektet eftersom det var en nyerfarenhet för projektgruppen. Det visade sig dock vara mycket användbart, detta eftersomnär testerna väl var skrivna gick utförandet av testningen väldigt fort och projektmedlem-marna kunde göra andra aktiviteter under tiden. Det var också smidigt att kunna testa helasystemet på nytt då ny kod hade skrivits, utan att behöva skriva fler tester. Systemtesternaskrevs innan slutet av varje sprint så att dessa kunde köras och systemet testas innan nästasprint påbörjades. Testerna fungerade också som verifiering av de krav som skulle uppfyllasunder sprinten.

Underlag till rapporten samlades in genom egen erfarenhet från projektet samt genom artik-lar och bloggar. Google Scholar har i första hand använts för att hitta artiklar publicerade itidskrifter [33]. Dessa artiklar och bloggar har sedan använts för att jämföra hur upplägget avtestning kan se ut med de egna erfarenheterna.

47

A.5. Resultat

A.5 Resultat

Detta kapitel presenterar resultatet av erfarenheter gällande testning från projektarbetet ochinnehåll i studier samt blogginlägg som är intressanta att jämföra testupplägg med. Studiernaoch blogginläggen berör både agil systemutveckling och vattenfallsmodellen.

A.5.1 Erfarenheter

Balansen mellan de olika testnivåerna i projektet har inte följt någon specifik modell. Däremoteftersträvades det att både enhetstester och systemtester skulle skrivas under projektets gångför att säkra systemets kvalitet. Enhetstester ansågs vara viktiga för att kunna kontrollera spe-cifika funktioners korrekta beteende, och systemtestning ansågs vara viktigt för att verkligense om systemet fungerade som planerat. Motiveringen till att inte skriva integrationstestervar att systemtesterna kunde avgöra om systemet fungerade eller ej, integrationstester kän-des då överflödiga och inte lika intressanta för projektet.

Det skrevs väldigt få enhetstester under projektets gång, detta eftersom många funktioner varsimpla och projektmedlemmarna kände då inget behov av att skriva tester för dem. Däremotskrevs det många systemtester som alla verifierade specifika krav på systemet. Detta resul-terade i att balansen mellan testnivåer i projektet blev få enhetstester, inga integrationstesteroch många systemtester.

A.5.2 Insamlad data

Enligt flera källor kan en bra balans mellan testnivåer vid agil systemutveckling illustrerasav en pyramidmodell, se figur A.1 [34, 35, 36].

Figur A.1: Pyramidmodell för testnivåer

I pyramidens botten ligger enhetstester, i mitten finns integrationstester och i toppen finnssystemtester. Denna modell menar att det är en bra praxis att skriva fler enhetstester än integ-rationstester och fler integrationstester än systemtester. Det skiljer sig dock mellan källornahur stor andel av testningen varje nivå ska uppta.

En källa beskriver att en vanligt förekommande balans mellan testnivåer då utvecklingenföljer vattenfallsmodellen är en omvänd pyramidmodell, se figur A.2 [34].

48

A.6. Diskussion

Figur A.2: Omvänd pyramidmodell för testnivåer

Den omvända pyramiden betyder att det skrivs fler systemtester än integrationstester och flerintegrationstester än enhetstester. Den omvända pyramiden, alternativt en pyramidmodellmed mindre eller ingen enhetstestning, föreslås kunna fungera vid vissa typer av systemut-veckling [37]. Detta är till exempel då det utvecklas ett simpelt system som inte har någonkomplex funktionalitet som behöver testas.

I vattenfallsmodellen verkar det inte finnas någon bestämd eller rekommenderad balans mel-lan testnivåerna [30, 38]. Modellen beskrivs av att testnivåerna utförs efter varandra i följandeordning:

1. Enhetstester.

2. Integrationstester.

3. Systemtester.

Detta betyder att en testnivå måste vara avklarad innan nästa kan påbörjas. Hur många testeroch hur mycket tid som läggs ned på varje testnivå kan variera mellan projekt.

A.6 Diskussion

I detta kapitel jämförs insamlad data med de egna erfarenheter som samlats under projektetsgång.

Testningen under projektet har inte varit särskilt lik de rekommendationer som framkommitfrån insamlad data. Om balansen mellan testnivåer i projektet jämförs med pyramidmodel-len så överensstämmer den inte alls. Under projektet har det skrivits för få enhetstester ochintegrationstester, medans det har skrivits ett större antal systemtester. Även om det kan ar-gumenteras för att enhetstester inte var nödvändiga för all funktionalitet i systemet, hade detvarit en förbättring att testa mer funktionalitet än vad som faktiskt gjordes. Fler enhetstesterhade bidragit till att det hade blivit lättare att identifiera var en bugg fanns i koden. Att im-plementera integrationstester hade också varit en stor förbättring av systemet. Speciellt medtanke på hur få enhetstester som skrevs. Integrationstester hade bidragit till att minska an-talet buggar som uppkom efter sammanslagning av koden. Eftersom projektet utveckladesmed få enhetstester och utan integrationstester upptäcktes buggar oftast slumpvis vid testan-vändning och vid körning av systemtester. Det var då svårt att identifiera vad som gick feloch var i koden buggen befann sig, och det kunde därför ta lång tid att rätta till en bugg.

49

A.7. Slutsatser

Att utgå från pyramidmodellen vid projektets testplanering hade troligtvis bidragit till enmer balanserad testning av systemet. Även om alla projekt är olika och kräver olika balansav testnivåer kan det vara en bra idé att ha en vedertagen modell att utgå från när testplane-ringen görs. I detta projekt hade det troligtvis varit lämpligt att följa en modifierad variant avpyramidmodellen. Modifikationen skulle vara att skriva lite färre enhetstester än vad model-len beskriver, för den simpla funktionalitet som inte behöver testas, samt skriva lika mångasystemtester som projektgruppen gjorde. Detta för att systemtesterna bidrog mycket medatt verifiera kraven på systemet, vilket stärkte projektgruppens förtroende för att systemetfungerade som planerat. Balansen mellan testnivåerna skulle då blivit att det skrevs fler en-hetstester än integrationstester och systemtester, och ungefär lika många integrationstestersom systemtester.

Balansen av testnivåer i vattenfallsmodellen verkar vara mer jämn än i pyramidmodellen.Detta för att testningen i vattenfallsmodellen sker en nivå i taget tills personerna som utförtesterna är nöjda. Det betyder att det inte finns någonting som säger att det ska utföras fler en-hetstester än systemtester eller liknande, vilket kan tolkas som att testnivåerna är mer jämntfördelade gällande tid och antal tester som utförs. Det finns troligen också fall där testningenstämmer överens helt med pyramidmodellens balans av testnivåer. Båda modellerna går attanpassa från projekt till projekt vilket betyder att de i princip kan se väldigt lika, eller väldigtolika ut från varandra.

A.7 Slutsatser

I detta kapitel besvaras rapportens frågeställningar.

En fungerande balans mellan de olika testnivåerna när det gäller agil systemutveckling i ettmindre mjukvaruprojekt kan vara att följa pyramidmodellen. Detta betyder att det ska skri-vas fler enhetstester än integrationstester och fler integrationstester än systemtester. Modellenska anpassas efter mjukvaruprojektets behov, men den utgör en bra grund att utgå ifrån.

Skillnaden i balans mellan testnivåer när det gäller agil systemutveckling och vattenfallsmo-dellen beror på projektet som ska utvecklas och personerna som utvecklar det. Eftersom py-ramidmodellen är en vanligt förekommande modell vid agil systemutveckling kommer denanvändas vid jämförelse av skillnader. Om vattenfallsmodellen jämförs med pyramidmodel-len så framstår vattenfallsmodellen som mer flexibel eftersom modellen inte specificerar hurmycket varje nivå ska testas. Dock kan vattenfallsmodellens flexibilitet göra att de två mo-dellerna blir identiska när det gäller balansen mellan testnivåerna. Skillnaden mellan dessamodeller kan alltså vara liten eller stor beroende på projektet och utvecklarna.

Balansen mellan testnivåerna i detta projekt kunde ha förbättrats genom att skriva fler enhets-tester och integrationstester. Detta hade troligtvis bidragit till att fler buggar kunnat identi-fieras och att det kunnat utföras en mer komplett testning av systemet.

50

B Kundnöjdhet vid agilprogramvaruutveckling av DanielHerzegh

B.1 Inledning

Under utvecklingen av programvara eftersträvas att utvecklingsteamet levererar en produktsom uppfyller kundens behov till fullo med minimal kostnad i tid, pengar och energi. Detfinns olika typer av metoder och ramverk vid en sådan utvecklingsprocess, både sekventiellaoch iterativa programvaruutvecklingsmetodiker. Den metodik som kommer att ligga i fokusi denna rapport är den iterativa agila utvecklingen, med flera metoder direkt tagna från el-ler inspirerade av ramverket Scrum, vilken förespråkar leveranser vid regelbundna intervallmed återkoppling från kund.

B.1.1 Syfte

Syftet med denna rapport är att undersöka och utvärdera de tekniker som har använts föratt säkerställa att projektarbetet går mot en slutprodukt i linje med kundens önskemål ochförväntningar.

B.1.2 Frågeställning

1. Hur bra är Scrum som utvecklingsramverk för att producera en slutprodukt som är ilinje med kundens förväntningar?

2. Hur förhåller sig projektresultatet mot studier som gjorts på Scrum-användning i före-tag?

B.2 Bakgrund

Kursen TDDD96 Kandidatprojekt i programvaruutveckling är en kurs som ingår i kurspla-nen för utbildningarna Datateknik och Mjukvaruteknik. Detta är den första kursen, inomutbildningarna, där studenterna arbetar mot en extern kund och måste finna arbetssätt föratt utföra detta på ett bra sätt. Under kursens projektdel utvecklade projektgruppen en web-bapplikation till sin kund.

Flera gruppmedlemmar hade tidigare antingen arbetat enligt vattenfallsmodellen eller åt-minstone studerat teorin och ansåg att den medförde alltför många oönskade begränsningartill ett utvecklingsarbete. Projektgruppen valde istället att arbeta enligt metoder från det agilaramverket Scrum, då den förhoppningsvis skulle passa gruppens arbetssätt bättre, inte minstmed hänsyn till kundnöjdhet.

51

B.3. Teori

B.3 Teori

I detta avsnitt beskrivs teori kring de två utvecklingsmodellerna Vattenfallsmodellen och Sc-rum.

B.3.1 Vattenfallsmodellen

Vattenfallsmodellen är en sekventiell modell för systemutveckling [30]. Utvecklingen skersekventiellt i faser där varje fas ska vara avslutad innan nästa påbörjas. Ordningen på fasernaär följande:

1. Analys

2. Design

3. Implementation

4. Testning

5. Underhåll

B.3.1.1 Kortfattad beskrivning av faserna i vattenfallsmodellen

Under analysfasen ska en fullständig beskrivning, en kravspecifikation, av de färdigutveck-lade systemet sammanställas. När denna är godkänd designas de olika delarna av systemet,såsom algoritmer och arkitektur. Därefter påbörjas implementationen under vilken program-meringen sker och systemet upprättas. Under testningsfasen kontrolleras och verifieras attdet upprättade systemet lever upp till den kravspecifikation som sammanställdes under ana-lysfasen. Slutligen under underhållsfasen ses det till att det utvecklade systemet fungerar iden miljö den ska användas i.

B.3.2 Scrum

I förhållande till sekventiella modeller, som vattenfallsmodellen, förespråkar utvecklingsram-verket Scrum en mer engagerad kundrelation i vilken kontinuerlig feedback efterfrågas påprojektet [2]. Viktiga komponenter av Scrum beskrivs och förklaras under avsnitt 3.1.1 Scrumi huvudrapporten.

B.4 Metod

Data fås genom en litteraturstudie av publicerade artiklar inom ämnet samt av erfarenhetfrån projektarbetet.

B.4.1 Litteraturstudie

För att få fram relevanta rapporter, artiklar och studier kring ämnet har nyckelbegreppen agi-le, customer collaboration och scrum använts i sökningar på både Google och via Linköpingsuniversitets biblioteks sökportal. Sökresultaten har undersökts och sållats baserat på hur välde relaterar till denna rapports frågeställningar. De rapporter och artiklar som hittades medhjälp av sökmotorerna har även lett undersökningen vidare till relevanta dokument som hän-visats i deras källhänvisningar.

Resultat och slutsatser av studierna har ställts mot och jämförts med resultaten av projektar-betet.

52

B.5. Resultat

B.4.2 Projektarbete

Vid starten av projektarbetet var den gemensamma viljan i projektgruppen att minimeramissförstånd med kund och i så hög mån som möjligt lägga ned tid och arbete på rätt uppgif-ter. För att uppnå detta användes följande strategier, mycket i linje med Scrum-metodologin:

• Vid första kundmötet försökte teamledare och analysansvarig att ställa uttömmandefrågor till kunden för att förstå sammanhanget produkten skulle verka i och hur pro-cesser, vilka påverkade produktens användning, såg ut.

• Kravspecifikationen och projektplanens första utkast upprättades av projektgrupp ochpresenterades till kund för feedback och förslag på förändringar innan de slutligen sam-manställdes.

• Projektarbetet lades upp i sprintar om två veckor för att i slutet av varje sprint demon-strera produktens nuvarande utseende och funktionalitet för kund.

• Webbapplikationen låg under projektets gång ständigt uppe på en hemsida som kun-den hade tillgång till även efter möten med möjlighet för egen testning och möjlighetatt potentiellt ge feedback via mail.

• Analysansvarig och teamledare har agerat inofficiella produktägare eftersom att de varpå samtliga möten med kund, fick bedöma implementationsprioritet och fick svara påfrågor om designbeslut som berodde på kundbehov.

• Analysansvarig hade ensamt hand om mailkontakten med kund. Om utvecklingstea-met hade frågor som ej kunde svaras direkt av produktägarna gick de via analysansva-rig till kunden.

B.5 Resultat

I detta avsnitt redovisas de resultat som togs fram under den litterära undersökningen samtresultaten av de erfarenheter som projektarbetet gav.

B.5.1 Litteraturstudie

Under litteraturstudien upptäcktes det att flertalet rapporter påvisade att en av grundorsa-kerna till programvaruutvecklingsproblem är bristfällig kommunikation, både inom utveck-lingsteam och mellan utvecklingsteamet och kunden. Samtliga rapporter som påstod dettahänvisade till artikeln Agile Methods and GSD: The Wrong Solution to an Old but Real Problemdär detta och flera andra problem kring programvaruutveckling tas upp [39].

En studie i vilket ett företag, som applicerat Scrum på många projekt, hade undersökts visadeatt återkommande problem i projekten berodde på bristfällig kundkommunikation [40]. Tvåpunkter som försvårade arbetet för utvecklingsteamen var följande:

1. Kundmöten ägde rum för sällan. Helst önskades det att dialog kunde föras med kundenvarje dag, men i praktiken ägde de endast rum en till två gånger per sprint.

2. Kunden är inte tillräckligt tydlig med vilka funktioner som eftersöks, även fast de trordet. Exempelvis kan en kund vilja ha ett system som spårar människors krediter. Dåkvarstår bland annat frågorna: Vilka är människorna, vad är dessa krediter för någotoch hur länge ska krediterna spåras?

53

B.6. Diskussion

Ett tydligt problem är även distansen till kunden [40]. Desto enklare det är att träffa kundenöga mot öga desto bättre visar sig kommunikationen bli, trots de distanslösningar som finnsidag med bland annat e-mail och videosamtal.

När kundkommunikationen fungerar visar Scrum ge positiva effekter för både kunder ochutvecklare [41]. Då Scrum förespråkar leverans av fungerande funktionalitet vid slutet avvarje iteration innebär detta att kunden kan testa funktionaliteten och ge feedback på den-na. Kunden får ett värde tidigt i utvecklingsskedet och utvecklarna får snabb feedback medvilken riktningen i projektet ska styras.

B.5.2 Projektarbete

Arbetet fortskred väl i början av projektarbetet. Efter första kundmötet och sammanställ-ningen av kravspecifikation samt projektplan, med kundgranskning och feedback av dessa,påbörjades arbetet. Implementationsmålen hade delats upp i delmål för varje sprint. Samt-liga medlemmar i utvecklingsteamet fick deluppgifter att arbeta på under första sprinten.Samtliga mål som var uppsatta nåddes denna sprint.

Vid första demotillfället var kunderna nöjda med utseendet och den initiala funktionaliteten.

Vid andra sprinten uppenbarade sig problem med implementation av funktionaliteten gäl-lande användarhantering då det inte var uppenbart hur detta skulle integreras med kundensnuvarande system för användare. Denna funktionalitet och implementationen av denna stodsom baskrav i kravspecifikationen och arbetet hade därför påbörjats. Dock sas det tydligt vidandra demotillfället att detta inte var funktionalitet som kunden ville ha fokus på på grundav oklarhet i integration i deras system, vilket ledde till att implementationen av denna funk-tionalitet avbröts. 26 mantimmar hade spenderats på denna del vid den här tidpunkten, avvilket inget sedan användes i slutprodukten.

Vid andra demo-mötet med kunden visade det sig att ett de förväntade sig en funktionalitetsom inte projektgruppen kände till. Denna funktionalitet var ej med i kravspecifikationen.Kunden var förstående för att detta var något som hade missats. Projektgruppen beslutadeatt implementera funktionaliteten efter övervägande av hur mycket arbete det skulle kräva.

Projektarbetets progression låg i övrigt i linje med planeringen som hade satts i början. Kun-derna var under demotillfällena tydliga med vad som skulle ändras, tilläggas eller tas bort.

Eftersom kunden befann sig i samma stad som projektgruppen var det mycket enkelt attstämma möten. Kommunikationen fungerade utöver detta på ett tillfredsställande sätt förprojektgruppen. Vid mailkorrespondens dröjde deras svar, i snitt, aldrig mer än 5 timmarunder arbetsdagar.

B.6 Diskussion

I detta avsnitt diskuteras resultat och metod, med avseende på både den litterära undersök-ningen och projektarbetet, utifrån ett kritiskt synsätt.

B.6.1 Resultat

Förändringarna i kravspecifikationen samt kundens nya önskemål under projektets gång vi-sar att den initiala förståelsen utvecklaren har av kundens behov inte nödvändigtvis är detkunden faktiskt behöver. Att dra slutsatsen att kunden inte visste vad de ville ha, vilket är ettåterkommande problem i Scrum-projekt [1], är nog förhastat att göra i det här fallet. Kundenkunde mycket väl ha vetat vad de ville ha men en bristande förmåga att kommunicera detta

54

B.7. Slutsatser

och/eller en bristande förmåga av projektgruppen att förstå behoven skulle lika väl kunnastämma.

Kommunikationsfärdigheter är en faktor som är svår att definiera och kvantifiera, men likvälhar haft en påverkan på hur projektet har gått. Detta gäller även kundens initiala nöjdhetefter det första demotillfället, vilket kan ha givit en positiv psykologisk effekt som bestodunder resten av projektet [41].

Den frekvens av återkoppling som ansågs äga rum för sällan enligt flera företag som applice-rade Scrum ansågs istället vara tillräcklig under vårt projekt. Detta illustrerar skillnaden avbehov som två olika projekt kan ha, vilket påverkar vilka verktyg från Scrum-ramverket sompassar det relevanta projektet.

Det är svårt att bedöma hur viktig distans och tillgänglighet till kunden i projektarbetet varför resultatet. Medan resultatet som erhölls av litteraturstudien menade att desto svårare detvar att träffas öga mot öga desto svårare är det även att genomföra ett projekt. Medan pro-jektgruppen, i sitt arbete, fick ut mycket kritisk information från de direkta kundmötena gårdet inte att besvara hur arbetet hade gått om dessa ej hade kunnat genomföras, och iställetförlita sig på annan typ av kommunikation.

B.6.2 Metod

Något som är värt att kommentera är att detta projektarbete ej var avlönat samt utfördesav studenter i utbildningssyfte. Kundens insats i detta projekt var ej ekonomisk utan bestodendast av ett par timmar möte varannan vecka samt en mail-korrespondens med i snitt treskickade mail per vecka. Det kan därmed tänkas att kundens förväntan på produktens pre-station ej låg i paritet med vad den skulle ha gjort om detta var en professionell beställning.Förmodligen kan förväntningarna på resultatet vara lägre än det är i de projekt som har be-skrivits i rapporterna i litteraturstudien.

Att samtliga rapporter vid den litterära undersökningen hänvisade till en och samma artikelangående problem kring kundkommunikation kan tyda på att det finns väldigt begränsadforskning inom området.

B.7 Slutsatser

I detta avsnitt besvaras rapportens frågeställning.

Hur bra är Scrum som utvecklingsramverk för att producera en slutprodukt som är i linjemed kundens förväntningar?

Projektarbetets slutdemonstration, i vilken det slutgiltiga systemet visades upp, visade attkunden uppskattade och var nöjd med resultatet. Strategierna, vilka härleddes från Scrum,anses ha varit en stark bidragande faktor då signifikanta ändringar och designbeslut togsmed hjälp av feedback från kund under arbetets gång. Hade arbetet genomförts enligt ensekventiell modell skulle inte feedback under arbetets gång varit relevant, vilket hade lett tillen slutprodukt som såg annorlunda ut.

Hur förhåller sig projektresultatet mot studier som gjorts på Scrum-användning i företag?

Projektets resultat stämmer i många aspekter väl överens med de studier som har gjorts påämnet. Den kontinuerliga kundkommunikationen, med regelbundna leveranser och tillhö-rande feedback, bidrog till en tillfredsställande slutprodukt. På grund av projektets begrän-

55

B.7. Slutsatser

sade omfattning har inga jämförelser kunnat göras med de delar av studierna som tog uppoönskad brist på kommunikation med kund.

56

C Sårbarhet för Cross site scripting(XSS) i en webbapplikation avDavid Hasselquist

C.1 Inledning

Cross site scripting (XSS) attacker är en typ av injektion där kod injekteras in i sårbarawebbsidor [42, 43]. Målet med XSS-attacker är inte att skada webbsidan eller komma åt dessserver, utan attacken riktar sig mot den stora publiken som är webbsidans användare.

XSS-attacker går generellt ut på att att lura en webbapplikation att skicka ett skadligt skriptvia webbläsaren [42, 43]. Webbläsaren tror att koden kommer från den betrodda webb-sidan och ger tillgång till användarens session. På detta sätt kan den som attackerar stjälaanvändarens session genom webbkakor och tokens eller sprida skadlig kod och virus. Medanvändarens session kan den som attackerar se det som en annan användare ser, så somlösenord och betalningsinformation. Ofta märks attacken heller inte av och användaren blirinte medveten om att någonting har skett.

Trots att XSS-attacker funnits länge är de fortfarande vanligt förekommande [42, 43]. XSS-attacker kan orsaka stor skada om en webbsida med många besökare attackeras. Någraexempel på välkända webbsidor som tidigare utsatts för XSS är Facebook, PayPal och Google.JavaScript används ofta i samband med XSS-attacker eftersom det stöds av alla modernawebbläsare.

C.1.1 Syfte

Syftet med denna studie är att studera vilka kategorier som XSS-attacker kan delas in ioch vad som är utmärkande för dessa kategorier. Därefter ämnar studien sig att studera degrundläggande metoder och åtgärder som finns för att skydda sig mot XSS-attacker samt hurprojektets webbapplikation SecTrack kan skyddas genom att tillämpa dessa metoder.

C.1.2 Frågeställning

1. Inom vilka kategorier kan XSS-attacker delas in i och vad är utmärkande för dessakategorier?

2. Vilka grundläggande metoder och åtgärder finns det att vidta för att skydda sig motXSS-attacker?

3. Hur kan projektet tillämpa dessa metoder i SecTrack för att skydda sig mot XSS-attacker?

57

C.2. Bakgrund

C.2 Bakgrund

Vid mitten av 90-talet släpptes JavaScript och gjorde det möjligt för webbutvecklare attimplementera nya funktioner som animationer och pop-ups. Detta gav dock upphov till vissaproblem, då det blev möjligt för en webbsida att ladda andra webbsidor och läsa dess innehåll[44, 45]. Den inladdade webbsidan kunde sedan exekvera olika skript, ta data från formuläreller modifiera sidan. En webbsida kunde alltså lämna sin egen domän och laddas in i enannan sårbar webbsida, vilket gav upphovet till namnet Cross site scripting.

Till en början användes förkortningen CSS för Cross site scripting. Men eftersom det lättblandades ihop med det som vi idag förknippar med CSS, nämligen Cascading Style Sheets,började förkortningen XSS användas istället [46]. Namnet XSS introducerades i början av år2000 av säkerhetsingenjörer på Microsoft och med tiden har den ursprungliga betydelsen avXSS förändrats. Begreppet XSS är i dag inte längre bara begränsat till att injektera skadlig kodöver domäner, utan används flitigt då en webbsida visar och exekverar kod injekterad av enanvändare.

C.3 Teori

Det här avsnittet beskriver definitioner av begrepp som används i denna del samt teorin förde olika kategorierna inom XSS.

C.3.1 Definitioner

Nedan förklaras begrepp som används i denna del men vars innebörder inte antas varasjälvklara för läsaren.

• DOM: När en webbsida laddas skapas en dokumentobjektsmodell (eng. DocumentObject Model) av webbläsaren [47]. Dokumentobjektsmodellen är ett plattforms- ochspråkoberoende gränssnitt som ger programspråk möjligheten att dynamiskt läsa ochuppdatera dokumentets innehåll, struktur och formatering.

• Fragment identifierare: Fragment identifierare (eng. fragment identifiers), även kalladhash, är den frivilliga och sista delen av en webbadress som följer efter tecknet #[48]. Exempelvis har webbadressen adress.se/fil.html#abc strängen abc som fragmentidentifierare.

• Proxyserver: En proxyserver är en server som agerar som mellanhand för en användareoch andra servrar. Detta medför att en användare kan surfa bakom proxyserverns IP-adress, där IP-adressen kan delas mellan flera användare.

• Skript: Ett skript är ett program eller en sekvens av kodinstruktioner som exekveras.

• Token: Ett objekt som representerar rättigheten att utgöra en viss operation.

• SQL-injektion: En injektion eller manipulering av data i en databas, se kapitel D.

58

C.3. Teori

C.3.2 XSS-kategorier

Attacker utförda genom XSS kan i huvudsak delas in tre olika kategorier och dessa kallas förreflekterad XSS, sparad XSS samt DOM-baserad XSS [43, 49]. Reflekterad XSS, som är denvanligast förekommande metoden i dag, sker då någon form av skadlig kod inkluderas viden begäran till webbservern. Sparad XSS är den typen av XSS-attack som kan orsaka mestskada då den skadliga koden sparas ner på webbsidan och dess server. DOM-baserade XSS-attacker riktar sig mot att modifiera en användares DOM lokalt utan att skicka någon datatill webbservern.

Det som bör noteras är att det finns en överlappning i terminologin för XSS-attacker [49].En DOM-baserad XSS-attack kan också ses som antingen en reflekterad XSS-attack eller ensparad XSS-attack. DOM-baserade XSS-attacker behöver alltså inte vara någon separat typav attack. Det finns ingen allmänt accepterad terminologi som täcker alla typer av XSS utanöverlappning.

C.3.2.1 Reflekterad XSS

Reflekterade XSS-attacker, även känd som icke-beständiga XSS-attacker, sker när ett skriptreflekteras av en webbapplikation till en användares webbläsare [42, 43, 50]. Det är denvanligast förekommande attacken och sker ofta genom en begäran till en webbserver, somsedan svarar med en webbsida som innehåller det skadliga skriptet. Är länken till en vanligoch allmänt känd sida finns det risk att användaren inte märker att ett skadligt skript harexekverats. Många gånger är syftet med attacken att stjäla användarens session genomwebbkakor och tokens eller sprida skadlig kod och virus.

För att åstadkomma detta används ofta inmatningsfält [42, 50]. En webbsida som inteskyddar sig mot XSS och som innehåller ett inmatningsfält är sårbar om det som matas inskrivs ut på webbsidan. Ett exempel på inmatningsfält som finns på många webbsidor ärsökfält. Vid sökning av exempelvis sökordet katter skriver webbsidan ofta ut Sökresultat förkatter eller liknande, alternativt katter hittades inte. Om en användare däremot söker eftersökordet katter <script> alert(); </script> kommer webbsidan att svara med katter <script>alert(); </script> hittades inte. Men istället för att skriva ut <script> alert(); </script> kommerden koden att exekveras istället. Det som användaren ser är enbart katter hittades inte eftersomkod som exekveras inte syns i webbläsaren.

I detta fall exekveras enbart koden alert();, vilket inte är skadligt. En som attackerar kandock ersätta det med skadlig kod eller använda sig av externa filer i JavaScript och sedanlänka till dessa med hjälp av skript-taggarna. På så sätt kan i princip vilken kod somhelst exekveras. Ett exempel på inmatningen till sökfunktionen kan då vara katter <scriptsrc="http://adress.se/fil.js></script>. Användaren som söker efter detta kommer bara se attkatter har sökts efter, medan filen fil.js, som ligger på webbadressen adress.se kommer attexekveras i bakgrunden.

C.3.2.2 Sparad XSS

Sparade XSS-attacker, även känt som beständiga XSS-attacker, sker när ett skript injekterasoch sparas på servern, exempelvis i en databas [42, 43, 51]. För att åstadkomma dettakan kommentarsfält eller andra liknande användarinlägg göras. På samma sätt som förreflekterad XSS kan en användare skriva skadlig kod och dölja detta. En annan användaresom hämtar denna information från servern riskerar att bli attackerad då informationen kaninnehålla skadlig kod.

59

C.4. Metod

Sparade XSS-attacker är mindre vanliga jämfört med reflekterade XSS-attacker, men är dentyp av attacker som kan göra mest skada eftersom den i normalfallet når ut till flest användare[42, 43, 51]. Användaren som blir attackerad behöver inte klicka på någon länk, utan deträcker med att besöka en sida som blivit injekterad med skadlig kod. På samma sätt som förreflekterad XSS går sparad XSS ut på att stjäla användarinformation och sprida virus.

C.3.2.3 DOM-baserad XSS

DOM-baserade XSS-attacker är attacker som utnyttjar användarens dokumentobjektmodell,som används för att arbeta med objekt i ett HTML-dokument [43, 52, 53]. Dessa attackerbygger på olämpling hantering, på HTML-sidan, av data från dess associerade DOM. Blandobjekten i DOM:en finns det flera objekt som attackeraren kan manipulera där två av devanligaste att manipulera vid XSS-attacker är document.url och document.location.

Det som skiljer DOM-baserade XSS-attacker mot reflekterad XSS och sparad XSS är att dataoch skript-kod aldrig når webbservern [43, 52, 53]. Reflekterad XSS och sparad XSS sker medinjektioner på serversidan medan DOM-baserad XSS sker på klientsidan. DOM-attacker skerlokalt i användares webbläsare och därför kan dessa attacker inte stoppas av webbservernsfilter. Eftersom ingenting skickas till webbservern loggas heller ingenting på servern och detblir därför mycket svårare för utvecklaren att upptäcka attacken och vidta åtgärder.

Ett möjligt sätt att utföra en DOM-baserad XSS-attack är att utnyttja fragment identifierare,även kallad för hash [52, 53]. Allting som skrivs efter tecknet # i en webbadress skickas aldrigtill webbservern. Historiskt sett användes fragment som ett enkelt sätt för att bläddra påHTML-sidan utan att behöva ladda om den, men har senare utvecklats och används idagäven inom JavaScript.

C.4 Metod

För att få en förståelse för vilka kategorier XSS-attacker kan delas in i har digitala artiklar ochkonferensmaterial från kvalificerade källor studerats. Denna studie låg till grund för teorinoch slutsatser som drogs om de utmärkande delarna i de olika XSS-kategorierna. Därefterhar en webbsida satts upp för att undersöka och testa dessa XSS-kategorier och illustrerateorin med kodexempel. Sedan undersöktes vilka grundläggande metoder och åtgärder somfinns att vidta för att skydda sig mot XSS-attacker. Med denna undersökning som grundanalyserades sedan SecTrack för att komma fram till hur SecTrack kan anpassas genom atttillämpa dessa metoder och skydda sig.

C.5 Resultat

Det här avsnittet illustrerar de olika XSS-kategorierna med kodexempel samt beskriver vilkagrundläggande metoder och åtgärder som finns att vidta för att skydda sig mot XSS-attacker.

C.5.1 Reflekterad XSS

För att illustrera reflekterad XSS och det som förklarats i teorin kan följande kod användas ien HTML-fil.

60

C.5. Resultat

<html><body>

<input type="text" id="input" /><input type="submit" value="submit" onclick="goToPage();" />

<script type="text/javascript">let params = (new URL(document.location)).searchParams;document.write(params.get("q"));

function goToPage() {window.location = document.location.origin + "?q=" +document.getElementById('input').value;

}</script>

</body></html>

Koden innehåller ett simpelt textfält och en knapp. Vid nedtryckning av knappendirigeras webbsidan om till webbadressen adress.se/?q=input, där input är inmatningen somanvändaren gjort i textfältet. Sidan hämtar sedan denna input från webbadressen och visardet på sidan. Exemplet illustrerar en simpel sökfunktion som finns på många webbsidor.

En attackerare kan sedan skapa en skadlig webbadress och distribuera detta. ReflekteradeXSS-attacker levereras ofta till andra användare med ett e-postmeddelande eller påen annan webbsida [42]. Ett exempel på hur en skadlig webbadress kan se ut är:adress.se/?q=katter<script>kod</script>. För att länkarna inte ska se misstänkta ut kan sedanolika kodningsmetoder för länken användas.

C.5.2 Sparad XSS

För att illustrera en form av sparad XSS kan koden nedan användas i en HTML-fil. Iexemplet sparas inte koden på någon databas utan lagras istället som en webbkaka lokalti användarens webbläsare. Detta för att slippa hantera kod för en server samt en databas iexemplet. Exemplet illustrerar en form av kommentarsfunktion, där kommentarerna sparasundan. I ett vanligt fall sparas kommentarerna i någon form av databas där andra användaresenare kan hämta informationen.

61

C.5. Resultat

<html><body>Name: <input type="text" id="inputName"/>Comment: <input type="text" id="inputComment"/><input type="submit" value="submit"

onclick="submitComment();" /><br><br>

<script type="text/javascript">document.write(getComments());

function submitComment() {var cname = document.getElementById('inputName').value;var cvalue = document.getElementById('inputComment').value;document.cookie = cname + "=" + cvalue + ";";location.reload();

}

function getComments() {var cookiesList = document.cookie.split('; ');if (cookiesList[0] == "") {

return "No comments";}var res = '';for (var i = 0; i < cookiesList.length; i++) {

var cookie = cookiesList[i].split("=");res += cookie[0] + " says:<br>" + cookie[1]+"<br><br>";

}return res;

}</script></body></html>

Koden innehåller två simpla textfält och en knapp. Det ena textfältet är tänkt att vara namn,medan det andra är tänkt att vara kommentaren. Vid nedtryckning av knappen sparaskommentaren tillsammans med namnet. Precis som i fallet för reflekterad XSS, kan skadligkod eller länk till en skadlig kod sparas undan i textfälten. När en användare sedan hämtarinformation från servern hämtas den skadliga koden och exekveras.

Andra exempel kan handla om profilinformation eller publiceringar och inlägg på ensocial medieplattform. Om plattformen inte skyddar sig mot sparade XSS-attacker kan enanvändare skriva in skadlig kod. Alla andra användare som sedan besöker denna profil ellerladdar inlägget kommer att exekvera denna kod. Detta kan få allvarliga konsekvenser försårbara webbsidor som har många besökare.

Till skillnad från reflekterade XSS-attacker, behöver inte sparade XSS-attacker levereraattacken manuellt via exempelvis ett e-postmeddelande eller en annan webbsida [51].Användarna behöver inte lockas till att klicka på en misstänkt länk, utan det räcker medatt besöka en webbsida som innehåller det skadliga skriptet för att råka ut för en XSS-attack.Däremot försöker attackeraren ofta locka fler användare till webbsidan som innehåller detskadliga skriptet, vilket innebär att webbsidan ofta sprids genom exempelvis skräppost-meddelanden.

62

C.5. Resultat

C.5.3 DOM-baserad XSS

Exemplet nedan liknar exemplet för reflekterad XSS eftersom den använder sig av webb-adressen. Här används fragment identifierare för att byta vyn mellan två bilder 1.jpg och2.jpg med hjälp av två knappar.

<html><body>

<input type="submit" value="Picture 1" onclick="viewPicture1();" /><input type="submit" value="Picture 2" onclick="viewPicture2();" /><p id="img"> <img src="1.jpg"> </p>

<script type="text/javascript">function viewPicture1() {

location.hash = '1';}

function viewPicture2() {location.hash = '2';

}

window.onhashchange = function() {var hash = unescape(location.hash.substr(1));document.getElementById("img").innerHTML = "<img src='"

+ hash + ".jpg' />";}

</script>

</body></html>

Eftersom webbsidan till skillnad från reflekterad XSS och sparad XSS inte innerhåller någratextfält att skriva i utnyttjas istället webbadressen. För att kunna exekvera ett skript i enanvändares DOM kan sidan med länken adress.se/#9’ onerror=alert();> besökas. Koden ovananvänder fragments för att hämta olika bilder och syftet är att växla mellan bild 1.jpg och2.jpg. Det som händer i det här fallet är är att webbläsaren försöker att hämta bilden somheter 9’ onerror=alert();> och klistrar in detta på sidan. Det koden gör är att manipulerataggen <img> och stänga taggen src i förväg med hjälp av tecknet ’. Sedan anges att vid ett felska koden alert(); exekveras och sedan stängs taggen <img> helt.

Koden som webbläsaren tolkar och skickar till användaren blir följande:

<img src="9" onerror="alert();"> ".jpg' />

Notera här färgkodningen och att användarinmatningen stänger taggen <img>. Vi ser attwebbläsaren försöker hämta bilden 9 som i det här fallet inte finns. Eftersom den inte finnskommer webbläsaren att ge ut ett felmeddelande och sedan exekvera koden alert();. Exempletvisar också att XSS-attacker kan ske genom andra taggar än <script>. I det här fallet användestaggen <img>, men det går även att använda andra taggar som exempelvis <body> eller <b>[42].

63

C.5. Resultat

På samma sätt som för reflekterad XSS kan DOM-baserade attacker levereras med skadligkod till andra användare med hjälp av bland annat e-postmeddelande eller på någon annanwebbsida.

C.5.4 Förhindrande av XSS

XSS-attacker är svåra att förhindra eftersom det finns många sätt en XSS-attack kan ske på[54]. Det finns därför inget standardsätt för en utvecklare att förhindra en XSS-attack. Därförär det viktigt att använda sig av en blandning av kodgranskning och testning under bådeutveckling och underhåll samt följa de kända programmeringspraxis som hjälper till att skapaen säker webbsida.

För att i grunden försöka förhindra XSS-attacker måste webbsidan först och främst separeradet egna innehållet från externt innehåll som kommer från användaren eftersom externtinnehåll inte går att lita på helt och hållet [54]. Efter att ha separerat på internt och externtinnehåll måste det externa innehållet behandlas så att det inte kan tolkas som kod.

Teorin är att alltid förvänta sig att externt innehåll är otillförlitlig och skadlig data [54]. Alltingsom ursprungligen inte kommer från systemet och som systemet inte har full kontroll överriskerar att vara skadlig. Detta kan exempelvis vara formulärdata, inmatningssträngar, webb-kakor och begäran från andra system.

Trots att XSS-attacker är svåra att förhindra finns det några generella och grundläggandemetoder som täcker och förhindrar en stor del av alla XSS-attacker [55]. Först och främst börutvecklaren använda sig av HTML-kodade tecken (eng. HTML escape) för att representera-alla tecken som användaren kan mata in. Att använda sig av HTML-kodade tecken innebäratt vissa specialtecken som tas emot av användaren inte ska tolkas på ett skadligt sätt[56]. Tecken som främst bör kodas om eller inte tillåtas att matas in överhuvudtaget är detecken som används i kodsammanhang. Några av dessa tecken är &, <, >, ", ’ och /. Ihuvudsak censureras data som webbsidan tar emot genom att koda om inmatningstecken tillspecialtecken.

Utvecklaren bör som regel aldrig sätta icke-kodad inmatningsdata i programmeringstaggarsom exempelvis <script>, HTML-kommentarer, <div> och webbadresser med <a> [54].Utvecklaren bör heller inte låta icke-kodade inmatningsdata finnas i någon attribut för entagg eller inom en attribut för CSS-kod.

För att skydda sig mot XSS-attacker kan utvecklaren även tillåta en viss inmatning frånanvändaren och validera dessa [55]. Tillåtelse och validering av inmatning används ofta somett skydd mot SQL-injektioner, men kan även användas som ett skydd mot XSS. Det är bättreatt begränsa vad som går att mata in och använda sig av en så kallad whitelist än att förbjudaen viss inmatning och därmed använda sig av en så kallad blacklist. För att kunna användasig av en blacklist behöver utvecklaren förbjuda allt skadligt som kan matas in, vilket ärmycket svårare än att bara tillåta en viss inmatning som systemet har designats för.

Att validera inmatning är speciellt användbart för att förhindra XSS-attacker i formuläreftersom det hindrar en användare från att lägga till specialtecken i fälten [55]. Däremot ärvalidering av inmatning inte en primär och heltäckande metod för att förebygga XSS-attacker,utan ska ses som en liten del av att göra systemet mer säker.

Ett annat sätt för att göra ett webbsystem mer säker mot en XSS-attack är genom att sanitera(rensa) användarinmatning [55]. Saniteringsprocessen inspekterar otillförlitlig data och görom den så den blir säker att läggas in i användares DOM. Sanitering är ett starkt försvarmen bör likt alla andra försvar inte användas ensamt utan ska ses som ett komplement till de

64

C.6. Diskussion

andra. Sanitering av användarinmatning är speciellt användarbar på webbsidor där externoch otillförlitlig inmatning kan innehålla kod. Metoden säkerställer att den mottagna dataninte skadar andra användare och systemet genom att modifiera inmatningen och ändra dentill ett tillåtet format. Saniteringen beror även på kontexten, ett värde som är helt ofarligt iCSS kan vara farligt i en webbadress.

Det som bör noteras är att webbsidan och dess kod ursprungligen kommer från webbservernoch det är utvecklarens ansvar att göra webbsidan säker mot XSS-attacker oavsett attacktyp[57]. Det vill säga, även om det rör sig om en DOM-baserad XSS-attack och attacken endastsker på klientsidan bör utvecklaren fortfarande sträva mot att förhindra attacken.

För att skydda sig mot DOM-baserade XSS-attacker där servern aldrig tar emot den skadligainmatningen måste hantering och kontroll av inmatning göras på klientsidan [57]. Dettagörs oftast med hjälp av JavaScript. Moderna webbläsare har redan till en viss del inbyggdfunktionalitet för att detektera sådana attacker. Dessa är dock långt från heltäckande ochmånga gånger lyckas den som attackerar komma runt dessa skydd.

Ett annat möjligt skydd som en utvecklare kan ge sina användare är att binda deras sessioneroch användarkakor till deras IP-adresser [58]. På så sätt, om en XSS-attack skulle ske ochden som attackerar kommer över användarens sessioner och webbkakor, blir det svårareatt använda dessa. Detta är dock någonting som inte används i stor utsträckning eftersomdet finns några nackdelar med det. Först och främst kan det finnas flera användare somanvänder samma IP-adress på grund av en proxyserver. En användare kan även ha olikaIP-adresser under en och samma session, det vill säga om användaren byter nätverk menanvänder samma enhet. En attackerare kan dessutom ansluta sig till webbservern frånsamma IP-adress genom att exempelvis göra attacken från användarens dator eller helt enkeltbefinna sig inom samma nätverk.

Ramverket Angular har ett inbyggt skydd mot XSS-attacker [59]. För att motverka XSS-attacker behandlar Angular normalt all extern data som otillförlitlig. Angular definierar tresäkerhetskontexter där alla tre saniterar användarinmatningen. Dessa är HTML, CSS samtwebbadresser. När ett värde läggs in i webbläsarens DOM sker sanitering och omkodning avinmatningen. I Angular behandlas HTML-filerna för varje komponent som exekverbar kodoch tillförlitlig kod. Kod, attributer och tilldelningar behandlas som säkra, medan värdenasom blivit tilldelade behandlas som otillförlitliga. Det innebär alltså att en utvecklare måstese till att en användarinmatning aldrig utgör källkoden i HTML-filerna. Om detta görs,genom exempelvis att HTML-filer genereras genom konkatenering med användarinmatning,riskerar webbsidan vara sårbar.

C.6 Diskussion

När det gäller reflekterad XSS finns inga uppenbara sårbarheter i SecTrack. Det finns ettinmatningsfält för varje tabell som skulle kunna utgöra en säkerhetsrisk, men användar-inmatningen för filtreringen skrivs aldrig ut på webbsidan. Filtreringen sker på klientsidanoch där kan inte ny information läggas till, utan funktionen begränsar endast visningen avinformationen som redan finns på webbsidan. SecTrack anses alltså inom det området intevara sårbar för reflekterade XSS-attacker och därför behövs inga extra åtgärder tas för attskyddas mot sådana attacker.

65

C.7. Slutsatser

Att skydda SecTrack mot sparade XSS-attacker är mer aktuellt då hela produkten går ut påatt spara information i en databas som senare visas vid en annan session eller för andraanvändare. Att separera internt innehåll mot användarinmatning, som är externt innehåll, ärinte svårt att göra i SecTrack. All användarinmatning som sparas sker genom inmatningsfältnär användaren vill lägga till ny information, ändra information eller kvittera ett kort eller enhandling.

Tillåtelse och validering av en viss inmatning på ett fält kan i SecTrack hjälpa till att skyddamot XSS-attacker. I SecTrack är detta redan implementerat då kontroller görs på varjeinmatningsfält. Exempelvis används en whitelist på korttyp respektive dokumenttyp. Dessatyper är definierade i databasen och i dessa fält kan endast de definierade typerna fyllas i. Ettannat exempel där tillåtning av viss inmatning görs är alla datum. I SecTrack har ett kort ettutgångsdatum, en handling har ett inkommet datum samt ett daterat datum och en leveranshar ett skickat datum och ett daterat datum. I alla dessa fälten görs en kontroll av datumet ochdess format. Är detta inte korrekt går det inte att skapa eller modifiera en handling, leveranseller ett kort.

För de fälten som är fritext kan SecTrack istället förbjuda en viss inmatning. Sådanainmatningar kan vara special tecken som &, <, >, ", ’ och /. Eftersom kunden specificeratatt de inte kommer att använda sig av specialtecken begränsas inte produktens användnings-område.

Att sanitera användarinmatningen hjälper till att motverka XSS-attacker. Eftersom SecTrackär uppbyggd av ramverket Angular sker sanitering av extern data redan automatiskt. ISecTrack genereras heller inga källkod baserad på användarinmatning, vilket bibehållerskyddet som Angular ger.

I SecTrack görs kontroll och sanitering av användarinmatning redan på klientsidan. Dess-utom använder SecTrack sig inte av några fragment identifierare. Det innebär alltså att ingafler åtgärder behöver tas för att skydda SecTrack mot DOM-baserade XSS-attacker.

Eftersom SecTrack endast kommer att användas internt hos kunden går det lätt att begränsaanvändarinloggningen. Exempelvis kan ett specifikt användarkonto vara kopplat till endator med en specifik MAC-adress. På så sätt binds kontot till datorn och om någonannan kommer åt inloggningsinformationen kan de inte logga in utan åtkomst till denspecifika datorn. Det här eliminerar i princip obehörig åtkomst till ett användarkonto om denobehörige inte har tillgång till användarens dator. Detta är ett väldigt starkt skydd och gernaturligtvis användarbegränsningar. Kontoinnehavaren kan exempelvis inte logga in frånvilken dator som helst och kontot måste konfigureras om varje gång ägaren byter dator.

C.7 Slutsatser

Det finns alltså tre huvudkategorier som XSS-attacker kan delas in i. Den första, reflekteradXSS, är den vanligast förekommande attacken och sker då skadlig kod inkluderas vid enbegäran till webbservern. Här sparas den skadliga koden inte sparas ner på webbservern.Det skiljer sig från den andra kategorin av XSS-attack som kallas för sparad XSS. SparadXSS är den typen av XSS-attack som kan orsaka mest skada då den skadliga koden sparasner på webbservern och kan därför nå ut till flest användare. Den tredje kategorin av XSS-attacker heter DOM-baserad XSS. Utmärkande för DOM-baserad XSS är att attacken skerlokalt i användarens DOM. Ingen begäran skickas eller sparas på webbservern och därförblir det svårare för utvecklaren att vidta åtgärder.

66

C.7. Slutsatser

Det finns flera små grundläggande metoder och åtgärder att vidta för att skydda sig motXSS-attacker. Grunden bygger på att separera internt innehåll, som är pålitlig, mot externtinnehåll, som kommer från användarinmatning och kan vara opålitlig. Därefter måste-det externa innehållet förväntas vara skadligt och inte tolkas som kod. De tre grund-läggande åtgärder som kan vidtas är att använda sig av HTML-kodande tecken, tillåta ochvalidera användarinmatning samt sanitera användarinmatning. Att använda sig av HTML-kodande tecken innebär att vissa specialtecken inte ska tolkas på ett skadligt sätt. Att tillåtaoch validera användarinmatningen kan hindra en användare att exempelvis använda ettformulär på ett felaktigt sätt och fylla i med felaktiga format. Den tredje åtgärden, saniteringav användarinmatning, innebär att den mottagna användarinmatningen modifieras ochändras till ett tillåtet och icke-skadligt format.

Eftersom det inte finns några uppenbara sårbarheter i SecTrack när det gäller reflekteradeXSS-attacker behöver inget skydd mot detta implementeras. När det gäller sparade XSS-attacker kan alla tre grundläggande åtgärder tillämpas. Först och främst kan SecTrackkan tillämpa HTML-kodade tecken och koda de specialtecken som behövs. Därefter kantillåtelse och validering av användarinmatning användas för att exempelvis förbjuda vissatecken, kräva en viss inmatning eller kräva inmatning på ett speciellt format. Sanitering avanvändarinmatning kan också göras, men detta görs detta redan av ramverket Angular somSecTrack använder sig av, vilket innebär att ingen ytterligare utveckling behöver göras kringsaniteringen. För att få ett ytterligare skydd kan ett användarkonto knytas till en specifikdator och MAC-adress, vilket innebär att det blir svårare för en obehörig att logga in medett viss användarkonto. När det gäller DOM-baserade XSS-attacker behöver inga ytterligareskydd implementeras eftersom kontroll och sanitering av inmatning redan sker på klient-sidan.

67

D Sårbarhet mot SQL-injektioner ien webbapplikation av JenniferLindgren

D.1 Inledning

SQL-injektioner (eng. SQL injections) sker då en användare utnyttjar indatahanteringen i ettprogram för att få tillgång till eller manipulera data i en databas. Sårbarhet för sådana opera-tioner kan medföra stora konsekvenser för företag som lagrar känslig information i databaser.I den här redogörelsen tas de vanligaste anledningarna till sårbarhet upp samt hur utvecklarekan minimera den.

Alla datadrivna applikationer kan utsättas för SQL-injektioner men den vanligaste mål-tavlan är webbapplikationer [60]. Det finns verktyg som automatiskt kan detektera om enapplikation är sårbar mot SQL-injektioner och utföra attacker mot den. En lyckad attack kaninnebära att data extraheras, ändras eller till och med förstörs. Främst utförs attackerna föratt ge någon typ av finansiell vinning. Till exempel kan det vara personuppgifter som stjälsför att användas till att stjäla någons identitet.

D.1.1 Syfte

Syftet med det här bidraget är att redogöra hur SQL-injektioner kan utföras mot en webb-applikation och vad utvecklare kan göra för att förhindra dem. Genom denna redogörelsesprids viktig kunskap kring ämnet till författarna och läsarna av denna kandidatrapport. I sintur kan den kunskapen användas för att skydda webbapplikationer och tillhörande databasermot SQL-injektioner i framtiden.

D.1.2 Frågeställningar

Frågeställningarna som denna redogörelse ämnar att besvara är följande:

1. Vad gör en webbapplikation sårbar mot SQL-injektioner?

2. Finns det någon säkerhetsbrist i SecTrack som gör att dess databas är sårbar mot SQL-injektioner?

3. Vad kan utvecklare göra för att minska risken för att en webbapplikation utsätts förSQL-injektioner?

68

D.2. Bakgrund

D.1.3 Avgränsningar

Alla datadrivna applikationer kan utsättas för SQL-injektioner men den här redogörelsenbehandlar endast sårbarheten hos webbapplikationer.

Reglerna för hur SQL-kod ska skrivas, den så kallade syntaxen, i olika databasmjukvarorkan variera något. Därför antas för enkelhetens skull att MariaDB är databasmjukvaran somanvänds i webbapplikationerna i denna redogörelse, eftersom det är mjukvaran som användsi SecTrack.

Arkitekturen hos en webbapplikation kan variera. SecTrack är en så kallad three-tierapplication vilket innebär att den består av tre lager, se figur D.1. Det översta lagret ärpresentationslagret, det som användaren ser och interagerar med [61]. Det andra lag-ret är serverlagret och det lager som presentationslagret kommunicerar med. Serverlagretkommunicerar i sin tur med ett tredje lager, datalagret, som består av databasen. I den härredogörelsen antas webbapplikationen ha denna arkitektur där presentationslagret alltså intekommunicerar med datalagret direkt.

Presentationslager

Serverlager

Datalager

Figur D.1: SecTracks arkitektur.

D.2 Bakgrund

Denna redogörelse kring SQL-injektioner görs i samband med kandidatprojektskursenTDDD96 som läses vid Linköpings universitet. Redogörelsen är relaterad till projektet i ochmed att SecTrack levererades med en databas som potentiellt skulle kunna utsättas för SQL-injektioner.

D.3 Teori

Det här avsnittet beskriver hur data i databaser hanteras. Se även kapitel 3.5 om databas-struktur.

D.3.1 Hantering av data

SQL (Structured Query Language) är ett välkänt programmeringsspråk som används för atthämta, lägga till, ändra och ta bort data i en databas [62]. När data ska hämtas eller ändrasi en databas formuleras detta i SQL-kod som skickas till databasen. Kod som skickas tillen databas för exekvering kallas i den här redogörelsen för kommandon eller förfrågningar.SQL-kod kan även användas för att ändra strukturen i databasen, till exempel för att läggatill eller ta bort tabeller, lägga till kolumner i tabeller eller byta namn på dem.

69

D.4. Metod

Något som kommer visa sig vara viktigt senare i denna redogörelse är att alla SQL-kommandon avslutas med ett semikolon. Det är så kompilatorn vet att ett kommando äravslutat och att det som eventuellt följer är början på ett nytt. Det kan även vara bra att vetaatt två på varandra följande bindestreck betyder att resterande del av raden är en kommentarfrån utvecklaren och därför inte ska tolkas som kod.

D.3.1.1 Kodexempel

För att ge läsaren en uppfattning om hur SQL fungerar visas här ett par exempel på SQL-kod. Det första exemplet hämtar alla användare från tabellen med användare. Det står ävenen kommentar i slutet av raden som inte kommer exekveras som kod:

SELECT * FROM Users; -- Hämta alla användare (detta är en kommentar)

Det går även att lägga till påståenden som måste vara sanna för att data ska hämtas. Det görsgenom att lägga till WHERE och sedan skriva påståenden som till exempel Age=25 för atthämta alla användare som är 25 år gamla. Påståenden kan separeras med AND för att krävaatt både påståendet till vänster och det till höger om AND måste uppfyllas. De kan på sammasätt separeras med OR för att säga att det räcker om det ena eller det andra påståendet är santför att datan ska hämtas. Ett kommando som hämtar alla användare som är 25 år gamla är:

SELECT * FROM Users WHERE Age=25; -- Hämta alla användare med ålder 25

Det sista kodexemplet tar bort tabellen med användare och dess innehåll:

DROP TABLE Users; -- Ta bort tabellen med användare, detta kan inteångras!ãÑ

D.4 Metod

Det här kapitlet beskriver hur svaren på frågeställningarna togs fram genom en litteratur-studie samt en analys av webbapplikationen SecTrack.

D.4.1 Litteraturstudie

För att få en förståelse för vilka metoder som kan användas för att utföra SQL-injektionerstuderades flertalet texter från kvalificerade källor. Några av källorna som användes varkandidat- och masterarbeten som hittades via sökmotorn Google Scholar. Andra källor vartill exempel boken SQL: Practical Guide for Developers som är publicerad av Elsevier Scienceand Technology och artikeln On automated prepared statement generation to remove SQL injectionvulnerabilities publicerad i Information and Software Technology.

Denna studie gav svaret på vad som gör en webbapplikation mottaglig för SQL-injektioneroch vad utvecklaren kan göra för att förhindra dem. Slutligen användes resultatet frånlitteraturstudien för att analysera SecTrack samt dra slutsatser kring huruvida applikationenär sårbar mot SQL-injektioner.

70

D.5. Resultat

D.4.2 Analys av SecTrack

För att besvara frågeställningen om huruvida det finns någon säkerhetsbrist i SecTrack somgör att dess databas är sårbar för SQL-injektioner utfördes en analys av applikationen.

D.4.2.1 Kodanalys

Det första steget i analysen var att identifiera delar av koden som uppenbart innebar sårbar-het mot SQL-injektioner. Det som främst uppmärksammades var om det fanns implemen-tationer där indata från användare användes direkt när en förfrågan till databasen skulleskickas. En sådan implementation möjliggör för användaren att integrera kommandon tilldatabasen i indatan vilket tas upp mer ingående i kapitel D.5. På samma sätt kontrollera-des hur data hanteras då den hämtas. Det finns sätt att hämta data som möjliggör olovligexekvering av kommandon, även detta tas upp i kapitel D.5.

D.4.2.2 Tester

Den andra delen av analysen bestod av tester. En del av testerna som utfördes var de manu-ella tester som föreslås på OWASPs (The Open Web Application Security Project) webbsida[63]. Det finns även mjukvara som kan skanna, utföra tester och identifiera säkerhetsriskeri en webbapplikation. En sådan mjukvara är OWASP ZAP som användes i den här redo-görelsen för att identifiera sårbarhet mot SQL-injektioner hos SecTrack [64].

D.5 Resultat

Det här avsnittet redovisar de resultat som litteraturstudien och analysen av SecTrack gav.

D.5.1 Metoder för att utföra SQL-injektioner

En klassisk SQL-injektion använder sig av en webbapplikations URL [65]. För att en sådanattack ska vara möjlig förutsätts alltså att förfrågningar som skickas till databasen är baseradepå URL:en. Följande URL är påhittad men specificerar vad som ska hämtas och visas fråndatabasen via parametern pris, det vill säga alla produkter med pris 300:

http://www.varumarke.se/produkter.php?pris=300

Eftersom innehållet som visas baseras på URL:en kan den modifieras för att styra vad somvisas. Till exempel kan strängen ’OR’1’=’1 läggas till i slutet av URL:en för att inte bara hämtaprodukter där pris är lika med 300 utan hämta all data eftersom 1=1 är ett påstående som ärsant för alla produkter:

http://www.varumarke.se/produkter.php?pris=300’OR’1’=’1

På så sätt har en enkel SQL-injektion utförts via en webbapplikations URL. I det här falletvar det bara produkter som visades men i vissa fall kan känsligare data som till exempelanvändarnamn och lösenord också extraheras genom denna metod.

Ett annat sätt att använda parametrar för att utföra SQL-injektioner är att lägga till komman-don i webbapplikationens inmatningsfält. Anta att det finns ett inmatningsfält för användar-namn och lösenord som vid ett inloggningsförsök ger upphov till kommandot:

SELECT * FROM Users WHERE Username='användarnamn' ANDPassword='lösenord';ãÑ

71

http://www.varumarke.se/produkter.php?pris=300

http://www.varumarke.se/produkter.php?pris=300'OR'1'='1

D.5. Resultat

där användarnamn är användarnamnet som fyllts i och lösenord är lösenordet som fyllts i. Antavidare att användarnamnet ’; DROP TABLE Users; – fylls i. Det ger då upphov till komman-dot:

SELECT * FROM Users WHERE Username=''; DROP TABLE Users; --' ANDPassword='losenord';ãÑ

Detta skulle tolkas som en hämtning av alla användare med ett användarnamn som är entom sträng men även att hela tabellen för användare ska tas bort. Detta är förstås en allvarligattack vars konsekvens är att all information om systemets användare går förlorad.

D.5.2 Sårbarhet

En applikation vars indata från användare används direkt när kommandon skickas till data-basen kan enkelt utsättas för SQL-injektioner om inga ytterligare säkerhetsåtgärder vidtas,vilket togs upp i avsnitt D.5.1. Sårbarhet relaterad till indatavalidering står för nästan 50 pro-cent av alla sårbarheter på internet [66].

Om en användare kan skicka kommandon till databasen innebär det att användaren kanändra, lägga till eller ta bort data från databasen [65]. Om data som hämtas dessutom visas föranvändaren i till exempel en tabell så möjliggör det för användaren att hämta och visa känsliginformation om databasen, såsom tabell- och kolumnnamn, som vidare kan användas för atthämta till exempel användarnamn och lösenord. Användaren har alltså mer eller mindre fullkontroll över databasen och dess innehåll vilket utgör en stor säkerhetsrisk.

Även om en utvecklare lyckas eliminera risken att en användare skickar kommandon somexekveras av databasen direkt i samband med datainmatning finns det fortfarande risk att såkallade andrahandsförfrågningar exekveras. Det innebär att en användare lägger till data idatabasen normalt men när samma data senare hämtas ger den upphov till att kommandonexekveras.

D.5.3 Säker databashantering

Ett sätt att minska risken för SQL-injektioner är att kontrollera all indata. Det vill säga att isamband med användningen av indata se till att tecken som kan användas för att konstruerakommandon identifieras och oskadliggörs [65]. Med att oskadliggöra ett tecken menas attutvecklaren, ofta genom att lägga till ett omvänt snedstreck framför tecknet, berättar för data-basen att tecknet bara ska tolkas som en del av en textsträng i ett kommando och inte somen del av kommandot i sig. Samma sak gäller då data från databasen hämtas. Om en strängfrån databasen ska användas måste den kontrolleras och oskadliggöras för att förhindra attoönskade kommandon exekveras.

Ett annat vanligt sätt att undvika SQL-injektioner är genom att använda förberedda komman-don (eng. prepared statements) [67]. Det är ett sätt att separera definitionen av ett kommandooch dess indata. På så sätt kan indata aldrig modifiera kommandot som ska exekveras ellerge upphov till att ett helt annat kommando exekveras.

72

D.6. Diskussion

D.5.4 SecTracks sårbarhet

Här beskrivs resultatet av kodanalysen och testerna som utfördes med avseende på webb-applikationen SecTrack.

D.5.4.1 Resultat av kodanalys

När SecTracks kod analyserades söktes implementationer där användaren genom indata kanpåverka förfrågningar som skickas till databasen. Som tidigare nämnts kan detta ske direktdå indata skickas från webbapplikationen via URL eller inmatningsfält, eller i ett senare skededå data som är lagrad i databasen hämtas ut.

Först undersöktes risken att webbapplikationens URL kan utnyttjas för att skicka komman-don till databasen, men eftersom SecTracks URL endast används för att välja vilken vy somvisas så uteslöts denna risk. Sedan undersöktes filtreringen eftersom det är vanligt att SQL-injektioner orsakas via den. Det visade sig dock att det inte går att påverka SecTracks databasgenom filtreringen. Det berodde på att all data som kan visas i tabellen är hämtad i förväg ochfiltreringen sker på denna data i front-end. Det skickas alltså ingen förfrågan till databasen isamband med filtrering som användaren skulle kunna påverka.

Nästa del som undersöktes var då användaren lägger till objekt till databasen. Även här vi-sade det sig vara omöjligt för användaren att utföra SQL-injektioner. Det berodde på att allaspeciella tecken i indatan, som krävs för att användaren ska kunna avsluta pågående kom-mandon och formulera egna, oskadliggörs automatiskt innan indatan används.

Slutligen undersöktes huruvida det var möjligt att lägga in en särskild sträng i databasen ochfå kommandon att exekveras genom att hämta ut datan. Det visade sig att även här oskadlig-görs speciella tecken innan de hanteras vidare och därmed kan oönskade kommandon hellerinte köras när data hämtas ut. I båda fallen som nämns ovan används även förberedda kom-mandon, som beskrivs i avsnitt D.5.3, vilket innebär ett bra skydd mot SQL-injektioner.

D.5.4.2 Testresultat

Varken de manuella testerna som föreslogs på OWASP:s hemsida eller testerna som utfördesmed hjälp av OWASP ZAP visade på några sårbarheter hos SecTrack.

D.6 Diskussion

I detta avsnitt diskuteras resultatet av redogörelsen samt metoden som användes för att kom-ma fram till det.

D.6.1 Resultat

Resultatet kan delas upp i två delar, resultatet från litteraturstudien och resultatet från analy-sen av SecTrack.

D.6.1.1 Litteraturstudien

Litteraturstudien utfördes för att ge författaren och läsaren en grundkunskap inom ämnetSQL-injektioner i webbapplikationer. Resultaten gav en bra bild av vad som medför sårbarhetmot SQL-injektioner i en webbapplikation, det vill säga grunden för att besvara frågeställning1. Det var även genom litteraturstudien som frågeställning 3, om vad utvecklare kan göra föratt minska risken för att en webbapplikation utsätts för SQL-injektioner, kunde besvaras.

73

D.7. Slutsatser

D.6.1.2 Analysen av SecTrack

Analysen av SecTrack genomfördes för att besvara frågeställning 2 som specifikt behandlarsårbarheten mot SQL-injektioner hos SecTrack. Resultaten från analysen visade inte på någrasårbarheter och det var även vad resultaten från testerna indikerade. Båda delarna i analysenpekade alltså på att SecTrack inte är sårbar mot SQL-injektioner.

Det finns en risk att författaren som genomförde kodanalysen missade någon sårbarhet ikoden. Om så var fallet är dock sannolikheten liten att den sårbarheten inte upptäcktes senarenär testerna utfördes.

D.6.2 Metod

Den här redogörelsen inkluderade en litteraturstudie eftersom en fördjupning inom ämnetSQL-injektioner i webbapplikationer var nödvändig. Detta för att ge både författaren ochläsaren den nödvändiga grundkunskapen inom ämnet som behövs för att förstå resteradedelar av redogörelsen. I slutändan var det väldigt lärorikt att ta del av andras kunskap inomämnet och resultatet kunde appliceras när SecTrack skulle analyseras.

Analysen av SecTrack genomfördes för att avgöra om SecTrack är sårbar mot SQL-injektionereller inte. Även om författaren medverkade under utvecklingen av SecTrack och hade en godinsikt i dess implementation var en närmare analys samt noggranna tester nödvändiga föratt med säkerhet kunna svara på frågeställning 2.

Det övervägdes att skicka en enkätundersökning om SQL-injektioner till företag för att tareda på vad deras utvecklare gör för att minska risken att deras webbapplikation utsätts förSQL-injektioner, det vill säga för att besvara frågeställning 3. Detta gjordes dock aldrig dålitteraturstudien visade sig ge svar på frågeställningen.

D.7 Slutsatser

I detta kapitel besvaras frågeställningarna från kapitel D.1.2.

D.7.1 Frågeställning 1

Vad gör en webbapplikation sårbar mot SQL-injektioner?Att använda en användares indata för att konstruera kommandon till databasen utan att kon-trollera den är något som gör en webbapplikation sårbar mot SQL-injektioner. Indatan kanpotentiellt innehålla kod som avslutar det pågående kommandot till databasen för att sedandefiniera egenkonstruerade kommandon. Dessa egenkonstruerade kommandon skulle kun-na hämta, ändra eller till och med ta bort data från databasen. Ett annat scenario då indata kanorsaka en SQL-injektion är om den lagras i databasen men inte kontrolleras då den hämtasut.


Finns det någon säkerhetsbrist i SecTrack som gör att dess databas är sårbar mot SQL-injektionerEnligt den analys som utfördes av SecTrack är risken liten att det finns någon säkerhetsbristsom gör applikationen sårbar mot SQL-injektioner. Denna slutsats drogs, med stöd av analy-sen av webbapplikationen, eftersom att indata som en användare anger aldrig används utanatt kontrolleras och oskadliggöras. Dessutom används förberedda kommandon i SecTrack.

74

D.7. Slutsatser


Vad kan utvecklare göra för att minska risken för att en webbapplikation utsätts för SQL-injektioner?För att minska risken för SQL-injektioner kan utvecklare säkerställa att varje gång data somen användare vid något tillfälle har matat in används utförs noggranna kontroller. Teckensom skulle kunna användas vid konstruktion av kommandon måste oskadliggöras, så att deendast kan användas i textsträngar och inte för att konstruera exekverbara kommandon. Yt-terligare ett sätt att försäkra att inga oönskade kommandon exekveras är genom att användaförberedda kommandon.

75

E Implementation av kontinuerligleverans av Johan Lind

E.1 Inledning

Kontinuerlig leverans (KL) är en process inom mjukvaruutveckling som är centrerad kringförmågan att kunna leverera uppdateringar när som helst. På så vis kan användare så snabbtsom möjligt dra nytta av felkorrigeringar och ny funktionalitet. Genom att se till att koden all-tid är i ett tillstånd som skulle kunna levereras så minimeras även problem med att integrerany kod.

Förespråkare för KL argumenterar för att det även resulterar i produkter av högre kvalitetsamt lägre kostnader och mindre risk [68]. Denna rapport kommer att undersöka hur KLkan implementeras och hur denna information kan relateras till utvecklingsprocessen bakomSecTrack.

E.1.1 Syfte

Syftet med denna rapport är att redogöra för hur utvecklingsprocessen KL kan implemen-teras vid utveckling av ett interaktivt system. Rapporten ämnar även att redogöra för vilkadelar av teorin om KL som saknas från utvecklingsprocessen bakom SecTrack.

E.1.2 Frågeställning

1. Hur kan KL implementeras?

2. Vilka delar av teorin om KL saknar utvecklingsprocessen bakom SecTrack?

E.2 Bakgrund

Denna undersökning utförs som en del av kursen ”Kandidatprojekt i programvaruutveck-ling” på Linköpings universitet. I samband med kursen utvecklades en webbapplikation åten extern kund. Under utvecklingens gång gjordes ett antal leveranser till kunden, vilket gördet relevant att undersöka processer som potentiellt kan underlätta detta. För att åstadkom-ma detta kan gruppens praktiska erfarenheter av systemutveckling relateras till rekommen-dationer från litteratur inom området.

76

E.3. Teori

E.3 Teori

I detta kapitel presenteras information som är relevant för att förstå resten av rapporten.

E.3.1 Versionshantering

Användning av versionshantering är central till modern utveckling av mjukvara, vilket in-nebär att en förståelse av versionshantering är viktig för att förstå resten av rapporten [69].Versionshanteringsverktyg har som syfte att spara historiken av ändringar till ett projektskodbas. Detta kan användas för att spåra hur koden ändras över tiden, för att återhämta ra-derad kod, och för att gå tillbaka till en tidigare version av mjukvaran om någonting slutaratt fungera. Versionshanteringssystem kopplas typiskt till ett webb-arkiv som används föratt samordna koden mellan flera utvecklare. När olika utvecklare samtidigt har ändrat påsamma rad i samma fil sägs en konflikt ha uppstått. Denna konflikt måste lösas genom attspecificera vilka ändringar som ska behållas och vilkas som ska kastas genom en processsom kallas sammanfogning.

Ett arbetsflöde med versionshantering följer typiskt ett mönster som liknar följande:

1. Användaren hämtar den senaste kodversionen från webb-arkivet.

2. Användaren utför egna ändringar lokalt.

3. Användaren registrerar dessa ändringar med versionshanteringssystemet.

4. Användaren hämtar senaste kodversionen från webb-arkivet.

5. Användaren sammanfogar versioner om konflikter uppstår.

6. Användaren överför lokala ändringar till webb-arkivet.

Grenar är ett viktigt koncept inom versionshantering [70]. En gren kan från användarens per-spektiv ses som en kopia av projektet som kan modifieras parallellt med andra grenar utan attpåverka dem. Inom mjukvaruutveckling används ofta ett system där koden versionshante-ras med en huvudgren som innehåller projektets fullständiga historik. När ny funktionalitetska läggas till eller fel ska korrigeras så skapas en ny gren för just den ändringen, som sedansammanfogas med huvudgrenen och raderas när dess syfte är uppfyllt. KL ställer vissa kravpå tillståndet av projektets kod, och det är just koden på huvudgrenen som syftas på, inte desmå grenarna som kan tillåtas innehålla ofärdig kod under utvecklingens gång.

E.3.2 Agil mjukvaruutveckling

Agil mjukvaruutveckling syftar på en samling utvecklingsmetoder som är designade för attge god förmåga att reagera på förändringar [31]. Agila metoder är starkt förknippade medidén om att arbetet ska brytas upp i hanterbara iterationer istället för att sikta på en enda gi-gantisk leverans. Hur långa dessa iterationer är beror mycket på typen av projekt, men oftastmellan 1-4 veckor [71]. Under varje iteration sker en planering om vad som ska göras underiterationens gång. Eftersom planeringen av projektet är utspridd över iterationerna kan ettarbetslag på ett naturligt sätt planera om ifall oväntade fördröjningar uppkommer eller kun-dens krav förändras. Den utspridda planeringen har även fördelen att laget undviker att göraden större delen av planeringen när kunskapen är som lägst. Vid projekt där ovissheten ärstor och kraven har stor sannolikhet att förändras är det en enorm fördel att kunna anpassaplaneringen på detta vis [72].

Eftersom KL siktar på att producera mjukvara i många små och snabba leveranser så är deniterationsbaserade agila mjukvaruutvecklingen en utmärkt match.

77

E.4. Metod

E.4 Metod

En litteraturstudie utförs för att ge en översikt över allmänna rekommendationer för att im-plementera kontinuerlig leverans. Denna information ställs sedan i kontrast till gruppenspraktiska erfarenheter under projektarbetets gång. Genom att reflektera över vilka problemsom gruppen stötte på samt deras orsaker så ges en ökad förståelse av hur rekommendationerfrån litteraturen relaterar till systemutveckling i praktiken. De artiklar som undersökningenhämtar information ifrån har funnits via användning av verktygen Google Scholar och IEEEXplore [33, 73].

E.5 Resultat

I detta kapitel presenteras informationen som resulterade från litteraturstudien samt grup-pens egna erfarenheter.

E.5.1 Information från litteraturstudien

KL handlar i sin kärna om att se till att koden alltid befinner sig i ett tillstånd som skulle kunnasjösättas på begäran utan fördröjningar eller problem [74]. Detta innebär däremot inte att allaändringar i kodbasen faktiskt omedelbart används i en produktionsmiljö, endast att det skavara möjligt om så önskas. När arbetet på ny funktionalitet eller felkorrigeringar är klart såsammanfogas detta med projektets huvudgren, någonting som kan ske flera gånger per dagför större projekt. Detta begränsar hur mycket olika utvecklares lokala kodversioner hinnerglida isär, och undviker därmed de problem som ofta uppstår där alltför många ändringarmåste sammanfogas samtidigt, ofta kallat ”integration-hell”.

För att inte dessa frekventa uppdateringar av huvudgrenen ska leda till att stora mängder feluppstår i koden så används nästan alltid automatiserade tester som ger en grundläggandeförsäkran om att koden fungerar korrekt. För att göra sjösättningen av denna kod till ensnabb och smidig process används typiskt skript som på begäran startar denna kod på envald server och utför ännu ett lager av tester [75].

E.5.1.1 Implementation av KL

KL implementeras med hjälp av en sekvens av steg som kallas en pipeline [75]. Varje stegsom passeras ger ökat förtroende om att produkten kommer att fungera som önskat i enriktig miljö. Olika projekt inkluderar lite olika steg och implementerar stegen på lite olikavis, men strukturen skiljer sig sällan mycket. Här presenteras information om hur en vanligpipeline ser ut [76].

1 – Versionshantering och Kodgranskning

När en kodändring har implementerats så överförs den till versionshanteringssystemet. Oftasker detta i samband med en kodgranskning innan ändringen accepteras in i projektets hu-vudgren. En sådan kodgranskning kammar bort vissa lättupptäckta fel och ser till att kodenföljer projektets standarder för lättlästhet och kodkvalitet.

78

E.5. Resultat

2 – Byggnads och enhetstester

När ändringen sedan har överförts till webb-arkivet som används för versionshantering avprojektets huvudgren så körs automatiskt en serie grundläggande tester. Först av allt så för-söker ett verktyg kompilera och sammanlänka projektets olika moduler. Ifall detta lyckas såblir resultatet en exekverbar produkt som kan testas. Sedan körs projektets enhetstester, vil-ket innebär att produktens funktionalitet testas finkornigt. Enstaka funktioner, moduler ochklasser ges en viss indata för att se om de genererar korrekt utdata.

3 – Acceptanstestning

I detta steg testas ifall produkten som helhet möter de krav som ställs på den. Projektmed-lemmar försöker att använda produkten så som en användare skulle, och kontrollerar att allönskad funktionalitet är närvarande och korrekt, samt att prestandan är acceptabel.

4 – Användartester

Efter den interna acceptanstestningen är det nödvändigt att se om produkten faktiskt funge-rar för användare. När projektmedlemmar testar sin egen produkt så har de ofta förkunska-per som ändrar sättet de använder produkten på. Användartesten avslöjar ifall produktenfaktiskt fungerar som det är tänkt i en mer verklig situation. Är produkten lätt att använda,och finns all funktionalitet som användare faktiskt vill ha?

5 – Sjösättning

När alla tester har passerats anses produkten vara redo att levereras till användare. För attdenna process ska ske så smidigt som möjligt används skript som automatiserar sjösättnings-processen. I en typisk KL-miljö har dessa skript testats många gånger under tidigare uppda-teringar, och projektlaget kan ha stort förtroende att leveransen kan ske felfritt med en endaknapptryckning.

E.5.2 Gruppens erfarenheter

Gruppen fattade aldrig formellt beslutet att använda sig av KL, och termen förekommer in-te i projektplanen för applikationen. Trots detta så använde gruppen många processer somassocieras med KL, och följde ett arbetssätt som påminner om vad som används inom KL.

En agil arbetsmetodik användes, där utvecklingen av applikationen bröts upp i 5 iterationer.Vid början av varje iteration planerades ett visst antal aktiviteter som skulle slutföras underiterationens gång, som sedan tilldelades till gruppmedlemmar. Dessa aktiviteter var oftastny funktionalitet eller felkorrigeringar som skulle implementeras. Vid slutet av varje iterationskulle koden för alla färdiga aktiviteter sammanfogas och överföras till projektets huvudgren.

Gruppen siktade på att kontinuerligt överföra ny funktionalitet till projektets huvudgren, ochatt hålla huvudgrenens kod i ett fungerande och lättläsligt skick. Vid utvecklingens start fat-tades beslutet att alla sammanfogningar in i projektets huvudgren skulle granskas av minsten annan gruppmedlem innan de verkställdes. Detta skedde via GitLabs inbyggda funktio-nalitet för sammanfogningsförfrågningar, så att gruppmedlemmar kunde se aktiva förfråg-ningar på projektets GitLab-sida. Vilken gruppmedlem som helst kunde ta initiativet för attganska en sådan förfrågan, och lägga kommentarer på delar av koden som bör ändras för attuppfylla projektets krav på kodkvalitet. Dessa kommentarer åtgärdas sedan av utvecklarensom lämnade sammanfogningsförfrågan, och en ny sammanfogningsförfrågan lämnas. I deflesta fallen hade granskaren inga kommentarer, och då accepterades förfrågan utan ytter-ligare kommunikation, varefter ett automatiskt mail skickas till medlemmen som lämnadeförfrågan. Större ändringar skulle sammanfogas vid gruppmöten, så att alla medlemmar för-

79

E.6. Diskussion

stod ändringarna och fick en chans att lämna kommentarer. Ändringar som accepterades in ihuvudgrenen sjösattes automatiskt på en särskild server.

Vid slutet av varje iteration skedde en leverans till kunden, vilket innebar att all ny funktiona-litet skulle vara införd i huvudgrenen innan dess. För att se till att detta skedde planerades ettsammanfogningsmöte där alla gruppmedlemmar tillsammans fick reda ut hur koden skullesammanfogas. Dessa möten varade ofta längre än vad som var tänkt och var relativt kao-tiska, med ett antal buggar som upptäcktes och fixades på plats. Eftersom ett flertal grenarbehövdes sammanfogas in i huvudgrenen bildades en kö av sammanfogningsförfrågningar,och följande arbetsflöde behövde följas:

1. Grenen som ska sammanfogas granskas, och kommentarer läggs på vad som behövsändras.

2. Eventuella kommentarer åtgärdas.

3. Sammanfogningsförfrågan accepteras.

4. Övriga grenar i sammanfogningskön integrerar de nya ändringarna.

5. Nästa gren väljs för att sammanfogas.

Dessa steg upprepas tills samtliga ändringar har integrerats in i huvudgrenen. Detta gav inteupphov till några större problem under projektets gång, men det är lätt att se att detta inte ärsärskilt skalbart, och det finns tydligt rum för förbättring.

Webbapplikationen som utvecklades hade en tillhörande back-end som även den uppdatera-des på liknande vis, dock inte lika ofta. Vid vissa tillfällen accepterades en ändring i front-endutan att tillhörande back-end uppdatering också accepterades, vilket under en kort tid leddetill att de två delarna av projektet var icke-kompatibla.

När utvecklingen på applikationen påbörjades sattes ett automatiskt build-test upp, eftersomdetta var relativt snabbt och enkelt att implementera och aldrig behövdes skrivas om underprojektets gång. Dock skrevs inga tillhörande automatiska enhetstester, eftersom att grupp-medlemmarna hade begränsad kunskap om automatisk testning och ville undvara så lite tidsom möjligt från själva systemutvecklingen. En annan faktor till att avstå från automatiskaenhetstester var att många komponenters funktionalitet förändrades mycket under utveck-lingens gång, vilket hade gjort det nödvändigt att spendera mycket tid på att skriva om en-hetstester varje gång en komponent förändrades. Majoriteten av all testning skedde istället iform av oregelbundna manuella tester, där gruppmedlemmar försökte använda applikatio-nen för att se om den fungerade som önskat. Inga tillfällen för användartestning förekom,dock fick kunden tillfälle att komma med kommentarer när applikationen visades upp underleveranserna.

E.6 Diskussion

Problemen som gruppen stötte på under utvecklingens gång visar tydligt på att det finnsrum för förbättring gällande gruppens arbetssätt. Integrationsproblemen orsakades av att förmånga och för stora ändringar tilläts hamna i kö. KL lägger stor vikt vid att nya ändringar skaintegreras in i kodbasen så fort som möjligt, vilket hade minskat eller eliminerat projektets in-tegrationsproblem. Genom att lägga fokus på att hålla grenarna med ny funktionalitet så småsom möjligt så skulle fler grenar lättare kunna integreras in i huvudgrenen under iterationensgång, och mindre hade därmed blivit kvar till iterationens slut.

80

E.7. Slutsatser

Automatiserade enhetstester som täcker en betydelsefull del av komponenternas funktiona-litet hade tagit lång tid att implementera, vilket möjligtvis hade lett till att mindre funktio-nalitet blev klar under projektets gång. Buggar skulle ha upptäckts tidigare med hjälp avautomatiserade tester, och detta skulle i sin tur leda till färre integrationsproblem. Det äräven möjligt att det fortfarande existerar oupptäckta buggar i slutprodukten som levererastill kunden, och att automatiserade enhetstester hade hjälpt gruppen att hitta och åtgärdadessa buggar i tid.

E.7 Slutsatser

I detta kapitel besvaras rapportens frågeställning.

Hur kan KL implementeras?

KL kan implementeras genom att skicka varje kodändring genom en sekvens av steg somkallas en pipeline. En kodgranskning ger en första försäkran om att koden följer projektetsstandarder för kodkvalitet. Därefter körs en serie automatiska tester för att se till att systemetkan sammanställas korrekt och att dess komponenter fungerar som väntat. Slutligen testassystemet manuellt av utvecklare och användare för att kontrollera att systemet är lättanväntoch uppfyller de krav som ställs på det.

Ett utvecklingslag kan på detta vis snabbt och effektivt bekräfta att en ny version av ett systemär redo att levereras.

Vilka delar av teorin om KL saknar utvecklingsprocessen bakom SecTrack?

Utvecklingsprocessen bakom SecTrack har mycket gemensamt med en typisk implementa-tion av KL, men de skiljer sig när det gäller testning. När KL används så ska varje ny integ-ration in i projektets huvudgren typiskt passera automatiska byggnadstester och enhetstes-ter, följt av manuella acceptanstester och eventuellt även användartester. Vid utvecklingenav SecTrack användes utav dessa endast byggnadstester och acceptanstester, och acceptan-stesterna skedde inte i samband med varje integration in i huvudgrenen utan var iställetoregelbundna. När KL används läggs vikt vid att integrationsfrekvensen ska vara hög nogför att minimera eller undvika integrationsproblem, vilket inte var fallet vid utvecklingen avSecTrack.

81

F Arbetsmiljöers påverkan pågrupparbeten av Niklas Nilsson

F.1 Inledning

Den här rapporten kommer att ge en insikt i hur arbetsmiljöer kan påverka grupparbeten,både hur gruppen samt gruppmedlemmar påverkas. Vilka faktorer är det egentligen sompåverkar välmåendet på en arbetsplats? Finns det bättre eller sämre arbetsmiljöer för justgrupparbeten?

Information kommer att komma från erfarenheter under projektets gång, tidigare erfarenhe-ter samt artiklar och andra typer av källor som till exempel arbetsmiljöverket.

F.1.1 Syfte

Syftet med denna studie är att få en insikt i hur både mental och fysisk hälsa samt produkti-vitet kan påverkas av den arbetsmiljö som en större del av arbetsdagen spenderas i. Då detär individuellt vilken typ av miljö som föredras så betyder det inte att det är den bästa förens hälsa och produktivitet. Den här studien ämnar sig åt att ge en insikt i hur olika typer avarbetsmiljöer kan påverka en och förhoppningsvis leda till en förbättring av sin egen.

F.1.2 Frågeställning

1. Hur påverkas en projektgrupp av arbetsmiljön?

2. Hur påverkas en person av arbetsmiljön?

F.1.3 Avgränsningar

Rapporten baserar sig på egna erfarenheter från olika projekt vilket resulterar i att rapportenkommer att vara begränsad till ett mindre antal arbetsmiljöer.

F.2 Bakgrund

Följande rapport om hur en arbetsmiljö kan påverka sitt arbete både i grupp och individuelltgörs i samband med att kursen TDDD96 - Kandidatprojekt i programvaruutveckling läses.I denna kurs arbetar vi i grupp mot en extern kund där varje grupp får sina egna och olikaförutsättningar beroende på uppgift. Då vissa kunder erbjuder tillgång till antingen platserpå deras arbetsytor eller tillgång till separata lokaler hos antingen kund eller på skola kandetta ses som en väldigt stor fördel, till skillnad från de grupper som inte har tillgång tillnågon fast arbetsmiljö. De grupper som inte får någon tilldelad arbetsyta behöver lösa dettasjälva, genom att boka lokaler på skolan eller andra sätt.

82

F.3. Teori

F.3 Teori

Denna del kommer att handla om de faktorer som har en påverkan på ens arbetsmiljö ochvad som kan göras för att undvika problem och skador. Följande information är hämtad frånArbetsmiljöverkets informationssida och en rapport framtagen av Arbetslivsinstitutet [77,78].

F.3.1 Arbetsplatsens utformning

Det finns nog inte en arbetsplats som är den andra lik, men det går att dela upp kontor i ettpar kategorier vilket denna del kommer att handla om [79, 80].

F.3.1.1 Öppna kontor

Ett öppet kontor är ett kontor där det istället för flertalet små rum är en större lokal därgrupper bestående av de personer som arbetar med varandra är utplacerade tillsammans.Till skillnad från ett cellkontor så leder denna typ av kontor till att det är lättare att arbetainom gruppen och upprätthålla kommunikationen mellan varje gruppmedlem. Denna typav kontor kan lida av störande ljud då det inte finns mycket som kan absorbera ljudet mellanarbetsplatserna.

F.3.1.2 Cellkontor

Cellkontor är ett kontor där allt är uppdelat i enskilda kontorsrum med syftet att ha en storavskildhet vilket kan leda till ökad koncentrationsförmåga och minskade störmoment frånljud. Denna uppdelning av ett kontor leder till minskad sammanhållning och kommunika-tion inom grupper samt att informationsflödet hämmas. Flexibiliteten som finns när kontoretbestår av en öppen lokal försvinner och det blir svårare att ändra på arbetsgrupper. Det blirlättare för personer att fokusera på sitt eget men gruppen får lida.

F.3.1.3 Kombikontor

Denna typ av kontor är en kombination av fördelarna hos de två ovannämnda kontorstyper-na, det finns många små enskilda arbetsrum utspridda runt ett större gemensamt rum. Pådetta sätt kan en grupp bibehålla sammanhållningen och kommunikation men gruppmed-lemmar kan även sitta enkelt för sig själva om det behövs för att hålla koncentrationen uppe.

F.3.1.4 Flex- och aktivitetsbaserade kontor

I ett flexkontor har varje enskild person ingen förbestämd arbetsplats, istället kan en personsätta sig lite var den vill och arbeta. I det aktivitetsbaserade kontoret finns även möjlighetenatt välja miljö beroende på det arbete som ska utföras.

F.3.2 Ergonomi vid datorarbete

Ergonomin är en viktig del av arbetsmiljön, att konstant ha en dålig ergonomi kan leda tillallvarliga problem [81]. När en stor del av dagen spenderas med att arbeta framför en da-torskärm ökar riskerna för både fysiska som psykiska hälsoproblem. Dåliga arbetsytor or-sakar ofta problem med överkropp, nacke, skuldror och armar. För att undvika de fysiskaproblem som uppstår vid ett stillasittande jobb bör den fysiska arbetsplatsen vara bra plane-rad och utformad på ett sätt som undviker att stress placeras på kroppen. Den låga fysiskaaktiviteten som utövas under lång tid på grund av denna typ av jobb kan även leda till pro-blem med svaga muskler och nedsatt rörlighet, men även sänkt ämnesomsättning och pro-blem med vikt samt hjärt-kärl-systemet. Om bildskärmen är placerad på ett dåligt sätt eller

83

F.3. Teori

att belysningen är undermåttlig kan det leda till synbesvär, en dålig placerad bildskärm kanäven leda till de fysiska problem som nämnts ovan.

För att förebygga dessa besvär som kan uppstå på grund av den arbetsmiljö en person utsättsför finns det en hel del att göra, men det är inte bara upp till en själv utan även arbetsgivarenatt se till att ens arbetsmiljö är duglig. Fokus bör ligga på att ha utrustning som passar ensarbete bra och som har en utformning och placering som leder till en hälsosam ergonomi.Att kunna variera positionen för att undvika att sitta stilla och vara inaktiv under större delav dagen är även det viktigt att ha redskap för att kunna göra, antingen genom att ha varie-rande arbetsuppgifter eller möjlighet till ett höj- och sänkbart arbetsbetsbord. En bekväm ochjusterbar stol är även det viktigt för att kunna uppehålla en bra ergonomi, att kunna ställa inhöjder och djup på stolens alla delar är viktigt för att kunna uppnå en bra sittandes position.

F.3.3 Ljud på en arbetsplats

Att ha en tyst och trivsam miljö är ett grundkrav för att kunna hålla sig koncentrerad. Störan-de ljud som höga brus, buller eller högt talande människor är de största problemen som finnsvid arbete i kontorsmiljö [82]. Det är väldigt lätt att fastna i det andra pratar om det tydligtgår att höra vad som sägs, det gäller att arbetsmiljön anpassas efter de arbetsuppgifter somska utföras. Behöver folk prata mycket i sitt arbete kan det vara bättre att avskilja de sompratar från de som behöver tystnad för att kunna behålla koncentrationen. Det är även braatt tänka på placeringen av störande ljudkällor så att hur de störande ljuden sprids i lokalenminimeras. För att minimera problem med ljudnivån kan absorberande material sättas upp igolv och tak samt absorberande skärmar mellan arbetsplatser där det upplevs störmoment.

Planeringen av arbetsytor är väldigt viktigt för att undvika en störande arbetsmiljö, om enöppen kontorsmiljö önskas så kan glasväggar eller andra uppsättningar användas där detfortfarande ser ut att vara öppet men spridningen av ljud minskas. Att undvika att placeradörrar som låter i närheten av där folk jobbar är också bra då dörrar som används flitigt har entendens till att bli störande. Separata rum för raster och samtal minskar också störmomentenpå ett kontor, att hålla ljudnivån nere där folk behöver tala leder till att mindre ansträngningför rösten vilket är bra då slitage på stämband, rösttrötthet, smärta i halsen, svag röst ochheshet kan undvikas [83]. Då rösten är ett viktigt arbetsverktyg bör är det bra att vara så månom den som möjligt.

F.3.4 Ljus på en arbetsplats

Bra belysning är något som behöves för att kunna utföra sitt arbete ordentligt, en undermåligkontorsbelysning kan leda till besvär och nedsatt produktivitet [84]. Besvären innefattar tröttaögonen, huvudvärk och spänningar i nacken då människor har en tendens att eftersöka enså bra bild som möjligt av det som beskådas. Störande ljuskällor är även det en orsak tillatt kroppen och huvudet försöker anpassa positionen för att undvika bländande ljus ellerandra störande reflektioner. Flimmer och för lite dagsljus kan leda till trötthet och nedsattarbetsförmåga, för att ha en optimal ljusnivå behöves alltså en jämn och lagom stark ljusnivåpå arbetsplatsen.

Olika typer av arbeten kräver olika mängder ljus, arbetsmiljöverket har en tabell med rikt-värden för ett flertal arbetsuppgifter [85]. Bara för att vissa arbetsuppgifter kräver en starkarebelysning än andra betyder inte detta att det är ett måste att ha denna ljusnivå i hela konto-ret, det räcker att kunna uppnå det förhållande som behövs lokalt och endast under den tidarbetet utförs.

84

F.4. Metod

F.4 Metod

Denna del kommer att handla om hur informationen för denna rapport samlades in, insam-lingen gjordes via en litteraturstudie och egna erfarenheter under nuvarande och tidigareprojektarbeten.

F.4.1 Litteraturstudie

För att hitta studier och rapporter om arbetsmiljöer gjordes sökningar på Google och GoogleScholar, ett flertal sökresultat undersöktes för att identifiera vilka källor som var mest rele-vanta för att kunna besvara de frågeställningar om har ställdes i kapitel F.1.2. En hemsidaoch en rapport valdes ut som innehöll väldigt mycket relevant information, både för sig självsamt de källor som hänvisades. Den kunskap som erhölls från denna studie jämförs mot deerfarenheter som det nuvarande projektarbetet har genererat samt erfarenheter från tidigareprojekt.

F.4.2 Nuvarande och tidigare erfarenheter

Erfarenheter från två snarlika projektarbeten valdes som referensmaterial, det som skiljerprojekten är förutsättningar kring den arbetsmiljö som gruppen blev försedd med. I det nu-varande projektet erhölls ingen lokal men i det tidigare projektet blev gruppen tilldelad enarbetsyta i en delad lokal. Det som har analyserats från dessa två projekt är hur arbetsmiljönpåverkade gruppen och ens eget arbete.

F.5 Resultat

Denna del kommer att gå igenom resultatet av den litteraturstudie som utfördes och resulta-tet av den erfarenhetsjämförelse som har gjorts.

F.5.1 Litteraturstudie

Utifrån den information som inskaffades under den litteraturstudie som utfördes framkomdet att det egentligen inte finns en perfekt arbetsmiljö. Det är ofta upp till personen ellergruppen om vad som passar dom bäst, men det finns väldigt många faktorer som kan bidratill en sämre arbetsmiljö om dessa inte tas i åtanke. Det viktiga när en arbetsmiljö bestäms äratt ha uppgiften i åtanke och sedan forma en passande arbetsmiljö utifrån vad som ska görasoch vilka som ska utföra arbetet.

Ergonomi är väldigt viktigt att ha i fokus för att uppnå en bra arbetsmiljö och för att varjeperson ska kunna arbeta under optimala förhållanden. En bra arbetsyta som är tillräckligtstor för den uppgift som ska utföras är viktigt, men även att ha en bekväm stol om personenförväntas sitta under längre tider. Möjligheten att ändra position med hjälp av ett höj- ochsänkbart bord är även det fördelaktigt.

En belysning som är anpassad efter de arbetsuppgifter som utförs underlättar arbetet och le-der till färre hälsoproblem, det är även bra att försöka kombinera dagsljus med det syntetiskakontorsljuset då möjligheten existerar.

Att minska störande ljud från maskiner, vägar och andra utomstående faktorer bör görasoavsett vilken kontorstyp som arbetsmiljön befinner sig i. Om det är en kontorsmiljö därmycket ljud från arbetskollegor kan störa är det bra om denna typ av störmoment minskaspå de sätt som är möjliga då det ofta leder till koncentrationsproblem.

85

F.6. Diskussion

F.5.2 Nuvarande och tidigare erfarenheter

I det nuvarande projektet som är ett projekt i mjukvaruutveckling där en grupp på sju perso-ner arbetar tillsammans dagligen för att utveckla en produkt åt en kund märktes vissa pro-blem då det inte har funnits en tillgång till en fast arbetsplats. Sammanhållningen i gruppenhar fortfarande varit bra men det har varit svårare att arbeta tillsammans då det inte alltidhar gått att få tag på en lokal.

Det var inte alltid möjligt för varje projektmedlem att arbeta esnam på en uppgift då detinte fanns tillräckligt många uppgifter som kunde göras samtidigt, om en lokal inte fannstillgänglig och flera projektmedlemmar skulle arbeta tillsammans kunde det bli att de gjordesamma sak. För att det undvika större problem försökte gruppen att hålla möten minst tregånger i veckan där det pratades om vad projektmedlemmarna hade jobbat på och vad deplanerar att jobba med efter mötet.

Att hålla öppen kommunikation om vad som arbetas på var nog det som fick lida mest av attinte arbeta tillsammans på en fast arbetsplats då det blev väldigt mycket egenarbete. Då vihade ett antal frågor varje vecka om hur kunden ville ha sin produkt hade en arbetsplats hoskunden gjort utvecklingen av produkten smidigare.

Det tidigare projektet var ett projekt i både mjukvaruutveckling och hårdvaruutveckling därär en grupp på sex personer arbetar tillsammans dagligen för att konstruera och program-mera en robot som ska utföra en viss uppgift, i det här fallet var det en robot som ska kunnautforska och kartlägga ett rum.

I det här projektet hade gruppen en fast arbetsplats i en lite större lokal där andra grupperockså hade sina arbetsplatser. Det var mycket lättare att arbeta tillsammans och upprätthållaen bra kommunikation med alla i gruppen då vi träffades fysiskt varje dag. Även här fannsuppgifter som det krävdes att flera arbetade samtidigt på och det gick lätt och smidigt attsammarbeta då det fanns en gemensam arbetsyta.

Problemet under det här projektet var ljudnivån i den gemensamma lokalen då ett störreantal grupper var på plats samtidigt, många olika störande ljud från olika grupper och högakonversationer ledde till att alla behövde prata ännu högre och koncentrationsnivån sänktesdå det var svårt att fokusera. Det var inte så farligt att det blev några kvarvarande symtommen det hade varit lättare att arbeta i en lugnare arbetsmiljö.

F.6 Diskussion

Att inte ha någon tilldelad arbetsplats i ett projekt som det utförs under denna kurs ledertill minskad produktivitet och en tydligt försämrad arbetsmiljö. Det försvårar för gruppenatt arbeta tillsammans och minskar sammanhållningen. Det hade hjälpt att ha tillgång till enbestämd lokal eller blivit tilldelad arbetsplatser hos kunden, men bara för att en grupp haren lokal att arbeta i behöver det inte betyda att arbetsmiljön är fördelaktig. Många i gruppenarbetar nog bättre hemma där de har en arbetsmiljö de är vana med samt en arbetsplats meden fast utrustning som kan vara fördelaktig vid den typ av arbete som utförs i detta projekt.En fast lokal kan alltså leda till att gruppen arbetar bättre tillsammans om arbetsmiljön ärtillräckligt bra.

För att arbeta så optimalt som möjligt i ett projekt som detta hade det nog varit bäst att grup-pen hade blivit tilldelad arbetsytor hos kunden där arbetsmiljön för uppgiften hade tagits iåtanke vid uppsättning av arbetsytan. En anpassad arbetsmiljö för mjukvaruutveckling medfast utrustning och bra ljus, ljud och ergonomiförhållanden samt med bra kommunikations-

86

F.7. Slutsatser

förmåga inom grupp och med kund hade utifrån den framtagna teorin och egna erfarenheterlätt till en mer sammanhållen, produktivare och mer hälsosammare projektgrupp.

F.7 Slutsatser

Denna del besvarar de frågeställningar som ställdes i kapitel F.1.2.

Hur påverkas en projektgrupp av arbetsmiljön?En projektgrupp påverkas starkt av arbetsmiljön, dåliga arbetsmiljöer kan leda till en splittradgrupp med dålig sammanhållning och kommunikation. Arbetsmiljön behöver anpassas efterden uppgift som ska utföras och se till att gruppen har bra förutsättning från början så attgruppen börjar med en bra grund inför arbetet. Om en grupp får en fördelaktig arbetsmiljösom har tagits fram med det som har nämnts i denna rapport i åtanke kommer hela gruppenatt må bättre under arbetets gång.

Hur påverkas en person av arbetsmiljön?Det är väldigt många faktorer i en arbetsmiljö som påverkar en person, allt ifrån ljus och ljudtill vilka verktyg man har blivit tilldelad. För att få en bra arbetsmiljö bör en ergonomiskarbetsyta tas fram till varje person där hänsyn tas till de speciella behov just den personenhar. Att ha en välplanerad lokal är viktigt och att den del av lokalen där en person ska arbetabör vara anpassad efter uppgiften som ska utföras där då alla arbetsuppgifter inte behöver hasamma förhållanden. Ljus bör anpassas efter arbetsuppgift och behöver inte vara den sammaöver hela lokalen, men en hälsosam nivå på ljus och ljud är viktigt för att person ska ha enbra arbetsmiljö.

87

G Vikten av kodstandarder ocheffektiv kod av Philip Bengtsson

G.1 Inledning

Det finns många projekt och programvaror där koden är svårläst och ostrukturerad. Därförär det intressant att ta reda på hur stor påverkan en tydlig kodstandard har på utvecklings-hastigheten, läsbarheten och underhållet samt att ta reda på skillnaden i miljöpåverkan hosvälstrukturerad kod och mindre välstrukturerad kod.

G.1.1 Syfte

Syftet med denna utredning är att klargöra huruvida en kodstandard nämnvärt förbättrarläsbarhet, underhållbarhet. Dessutom är syftet att ta reda på vad som minskar energiförbruk-ningen hos programvaror.

G.1.2 Frågeställningar

Följande frågeställningar kommer att behandlas under utredningen.

1. Vilka positiva effekter får en kodstandard på effektiviteten vid utveckling av program-varor?

2. Hur påverkas underhållet av programvaran när en kodstandard följs?

3. Finns det tillfällen där det är bättre att inte använda sig av en kodstandard?

4. Vad kan göras för att minska en programvaras energiförbrukning?

G.2 Bakgrund

Det är nästan en självklarhet att alla har programmeringsstilar som skiljer sig åt vilket kanleda till att ett större projekt skulle kunna innehålla flera olika av dessa stilar. Därför finns detpå många arbetsplatser en kodstandard som försöker få programmerarna att på ett någorlun-da liknande sätt skriva sin kod. Det är däremot inte alla som har en sådan standard som deföljer utan det finns projekt där varje programmerare skriver enligt sin egen stil.

Eftersom att det skrevs en kodstandard som följdes under projektets gång är det även relevantatt analysera vilka effekter detta hade på projektets utveckling.

88

G.3. Teori

G.3 Teori

Nästan varje företag eller arbetsplats har en annan kodstandard än sina konkurrenter. Des-sa är för det mesta baserade på en grupp eller en enskild programmerares personliga stil.Utöver detta kan standarderna eller riktlinjerna skilja sig åt beroende på vilket språk de pro-grammerar i eller beroende på vilket verktyg de använder för att programmera.

Om varje person använder sin egen programmeringsstil kan det leda till att framtida utveck-lare inte kommer att kunna ta till sig och förstå den kod som är skriven. Detta kan leda till attdet krävs många fler arbetstimmar innan man kan få ordning och börja underhålla systemetoch det kan även vara så att den kod som är skriven kräver mer energi att köra än kod somskrivits enligt en standard, givetvis kan även det motsatta vara sant, dock inte samtidigt.

G.3.1 Exempel på innehåll i en kodstandard

En kodstandard beskriver vilken typ av namngivning som ges till variabler, klasser samtmetoder och funktioner. De brukar dessutom beskriva hur typer som är särskilda för pro-gramspråket i sig används, exempelvis Private, Protected, Public och Static för många av deobjektorienterade språken. Andra regler som en kodstandard kan beskriva är hur många tec-ken som får vara på varje rad, hur en rad bör fortsättas när den blir för lång, hur och närkommentarer ska göras samt vilken indenteringslängd och metod som bör användas. Dessaär bara några exempel på vad en kodstandard kan innehålla.

Nedan följer några exempel från Googles kodstandard för c++ [86].

Det första exemplet hänvisar till att lokala variabler bör deklareras så nära sitt användnings-område som möjligt och ska initialiseras samtidigt som de deklareras.

int i;i = f(); // Bad -- initialization separate from declaration.// ----------------------------------------int j = g(); // Good -- declaration has initialization.

std::vector<int> v;v.push_back(1); // Prefer initializing using brace initialization.v.push_back(2);// ----------------------------------------std::vector<int> v = {1, 2}; // Good -- v starts initialized.

I nästkommande exempel ger Google exempel på hur variabler bör namnges, med bra exem-pel först och sämre exempel därefter.

int price_count_reader; // No abbreviation.int num_errors; // "num" is a widespread convention.int num_dns_connections; // Most people know what "DNS" stands

// for.int lstm_size; // "LSTM" is a common machine learning

// abbreviation.

int n; // Meaningless.int nerr; // Ambiguous abbreviation.int n_comp_conns; // Ambiguous abbreviation.int wgc_connections; // Only your group knows what this stands

89

G.4. Metod

// for.int pc_reader; // Lots of things can be abbreviated

// "pc".int cstmr_id; // Deletes internal letters.FooBarRequestInfo fbri; // Not even a word.

G.3.2 Energieffektivitet

Att dra ner på den energi som krävs för att upprätthålla våra datasystem har länge varit ettproblem. För att minska på energiförbrukningen har stort fokus legat på att göra hårdva-rukomponenterna mer energisnåla [87]. Tidigare forskning på inbyggda system har främstfokuserat på att minska mängden processorcykler och på så sätt även minska energiförbruk-ningen. Det finns också, enligt tidigare nämnda artikel, mycket litteratur gällande energief-fektiviteten hos inbyggda system då det är lättare att påverka den underliggande hårdvarannär systemen är nära sammankopplade. Den litteratur som finns för inbyggda system inne-håller även metoder för att både uppskatta energiförbrukningen och för att bygga energief-fektiva system.

G.4 Metod

För att få fram den data som behövdes för att analysera behovet av en kodstandard har ettflertal tidigare undersökningar analyserats och jämförts med varandra, dessutom har någ-ra kodstandarder jämförts med varandra innehållsmässigt. Dessutom analyserades de egnaerfarenheterna av att använda en kodstandard under projektets gång.

De undersökningar som använts har hittats genom att söka på Google Scholar med sökningarsom Coding Standards, Coding Conventions med tillagda nyckelord som readability, efficiency ochimportance [33].

G.5 Resultat

I denna del presenteras de resultat som framkommit av analysen på litteraturstudien somutförts.

G.5.1 Att ha en kodstandard

Anledningen till att företag och programmeringsgrupper har en kodstandard är för att lättarekunna programmera samtidigt på flera olika delar av projektet. Om gruppen sedan växlarvem som jobbar med vilken del eller om någon vill sätta sig in i en annan del av koden kande genom att de har en standard eller åtminstone riktlinjer snabbare sätta sig in i koden somderas kollegor har skrivit [88].

Detta är även relevant om ett projekt ska byggas om eller utökas vid ett senare tillfälle då detär möjligt att inte alla som arbetade med projektet ifråga finns kvar på plats. Det räcker intemed att enbart kunna läsa och förstå den kod som är skriven utan personen eller personernabehöver även kunna förändra koden på ett effektivt och fortsatt bra sätt. Det är dessutomextra viktigt att ha en fungerande standard som andra kan ta till sig då 80 % av kostnadenför ett program eller en mjukvara hamnar bland underhållskostnader och inte under självautvecklandet [89]. För att citera en okänd skribent hos Overpass Apps gällande hur viktigt detär att följa en standard när det handlar om både programvaruutveckling och husbyggande[90].

90

G.5. Resultat

"I think I can build a house. Okay... there’s no way I can build a house. So, let’s say I canbuild a shed. I can buy some plans and build according to that plan. Or, since it’s fairlysimple, I can just wing it and build a new shed. It’s faster to wing it. It will save me timeand money to just build it and not spend any time planning or taking classes.

Halfway through building a shed, though, I realise I need help. There’s no way I’ll fi-nish this thing. So, I hire a second builder. I need to explain to him why I did things theway I’ve done them. I may need to re-do some parts of the shed so he can work on his part.This could take hours with a shed . . . but days or weeks with software.

Then, after the shed is complete and a few years have passed, I decide I want to adda new feature . . . like a back door. I would need to spend hours looking at how I builtthe thing. I can’t hire a contractor, because he will spend longer trying to figure out why Ibuilt it that way so he doesn’t undo something that was intentional. Version 1.1 (my newfeature) will cost me a fortune to add and I will have to do it myself. All because I did notbuild to standards."

G.5.2 Läsbarhet

Det har visat sig att lättläslig kod innehåller färre fel än mindre lättläst kod för att program-meraren har lättare för att förstå sin egen kod och därför lättare kan hitta vart felen kan dykaupp [91]. Även om detta inte nödvändigtvis alltid har med kodstandarder att göra så gjordesderas undersökning genom att kontrollera vissa specifika element som oftast finns med i enkodstandard.

Dessutom har det visat sig att när en kodstandard bryts mot påverkas även läsbarheten hosprojektet drastiskt [92]. Däremot påstås det i [93] att när en standard följs blir mjukvaranalltid lättare att läsa och underhålla, dessutom blir den lättare att förstå sig på.

Att följa någon sorts kodstandard leder för det mesta till att koden som skrivs blir mer läsbaroch det går därför snabbare att hitta okända fel eller fel som dykt upp under utveckling [94].Detta leder i sin tur till att mer tid kan läggas på att föra projektet framåt istället för att lösagamla problem. Dessutom kan användandet av en kodstandard leda till att upp till 60 % avde fel som finns i mjukvaran hittas redan under utvecklingen.

G.5.3 Energieffektiv kodning

Att använda sig av utvecklingsmiljöer när mjukvara ska utvecklas är inte alltid ett hjälpme-del, åtminstone inte när det är viktigt att minimera energiförbrukningen [87]. Användandetav utvecklingsmiljöer effektiviserar för det mesta för utvecklaren när denna skriver kod, menanvändandet av ramverk och andra hjälpmedel påverkar hur många lager som ett anropmåste genomtränga innan det slutförs. Att ramverk och hjälpmedel försämrar energiförbruk-ningen gäller inte alla storlekar av program. I samma undersökning visar det sig att små ochmedelstora program har en lägre energiförbrukning om de använder sig av fler ramverk ochinbyggda metoder än om de inte hade gjort det. För större program påverkar användandetav ramverk och inbyggda metoder negativt på energiförbrukningen. Undersökningens argu-mentation för detta var att det är oftast fler moduler och fler lager som behöver gås igenominnan ett anrop har färdigställts och gett ifrån sig sitt resultat.

Undersökningen visade också på att programtyper som behövde göra stora beräkningar, ex-empelvis spel och bildhanteringsprogram, eller som behövde uppdatera ett grafiskt gräns-snitt i realtid, exempelvis textredigerare eller affärssystem, hade en högre energiförbrukningjämfört med exempelvis kalendrar och kalkylatorer då dessa krävde mer minne istället förprocessorcykler [87].

91

G.6. Diskussion

Den tidigare nämnda undersökningen påstod även att programmeringsstilar påverkar hurmånga inbyggda funktioner, kontrollstrukturer, externa bibliotek och hur mycket av pro-gramspråkets syntax som används [87]. Även programmerarnas erfarenheter av projekt på-verkade dessa faktorer. Användandet av dessa påverkade som tidigare nämnt energieffekti-viteten på projekten olika beroende på projektets storlek.

G.5.4 Egna erfarenheter

Under projektets gång använde projektgruppen en kodstandard, baserad på AirBnBs stil-guide för javascript och AngularIOs stilguide, som definierade på vilket sätt variabler, funk-tionsnamn och klassnamn skrev samt vilka typer av variabler som användes [95, 96]. Deninnehöll även definitioner för att visa att ett yttryck avslutats och för att visa vilka rader ikoden som tillhörde olika blocknivåer. För att upprätthålla standarden användes kodrätt-ningsprogrammet TSLint då det innebar att mindre tid behövde läggas av utvecklaren till attfölja standarden. Denna tid kunde istället läggas på att skriva den kod som behövdes. I ochmed att tiden kunde användas till effektivt kodande och att kodrättningsprogrammet hjälpteutvecklaren att hålla koden efter standarden blev koden lättare att läsa och lättare att sättasig in i för de andra gruppmedlemmarna. Detta ledde i sin tur till att det inte behövde läggaslika mycket tid på att förstå och sätta sig in i någons annans kod när någon behövde ta övereller hjälpa till med en uppgift.

G.6 Diskussion

Att använda sig av utvecklingsmiljöer för att effektivisera utvecklandet är något som kantänkas alltid vara till en fördel, men att det i större projekt kan vara negativt är någontingsom inte är självklart. Detta kan vara viktigt att tänka igenom noga när ett större projekt skagenomföras, speciellt om det är viktigt att energiförbrukningen hålls på en låg nivå. Det kanockså vara värt att tänka på att avväga huruvida det är viktigare att projektet blir energief-fektivt när det färdiga programmet väl körs eller om det ska gå snabbare att skriva färdigtprojektet och vara lättare att underhålla i framtiden. Ett alternativ till de båda extremernaskulle kunna vara att programmera vissa energiintensiva komponenter utan hjälp av färdig-byggda system och miljöer och programmera de mindre energiintensiva delarna med hjälpav dessa.

Dessutom skulle det inte vara otänkbart att användandet av en kodstandard gör att det blirlättare att programmera både med och utan hjälpmedel. Det är inte orimligt att när det gällerenergiförbrukning kan kodstrukturen bli mindre läsbar, men om kodstandarden är upprätt-hållen även här kan koden bli mer läsbar och lättare att underhålla. Då artikeln om energief-fektivitet nämnde att programmeringsstilar påverkade energieffektiviteten kan det antas attkodstandarder som anpassats för att förbättra energikonsumtion och läsbarhet kommer, ommöjligt, att utvecklas och påverka mjukvaruutvecklingens energikonsumtion positivt [87].

Det finns olika teorier för att minska på energiförbrukningen hos mjukvarusystem, de flestaav dessa handlar om att minimera mängden hårdvaruresurser som används, exempelvis pro-cessorcykler eller minnesanvändning. Däremot är det ingen som tänker på den tid och energisom läggs på att skriva eller underhålla mjukvaran, all denna tid påverkar också energiför-brukningen dock på ett indirekt sätt. Om det går att effektivisera utvecklingstiden, testernaoch tiden det tar att underhålla programmet kommer även energiåtgången som krävs förprojektet och programvaran att minskas vilket antagligen leder till en grönare utveckling.

92

G.6. Diskussion

Det kan argumenteras för att det finns tillfällen där det inte är nödvändigt med att följa enkodstandard. I de flesta fall skulle en kodstandard öka produktiviteten hos programmerar-na och även läsbarheten för varandra. Det finns däremot exempel på kodstandarder som ärrentav dåliga att följa då dessa kan vara onödigt komplicerade eftersom att de kan kräva attprogrammerarna följer konstiga namnstandarder eller formatstandarder eller rentav använ-der sig av en kodstandard som inte passar för programmeringsspråket som de för tillfälletutvecklar i. Det är i sådana lägen som det kan vara bättre att istället följa sin egen program-meringsstil om den håller högre kvalité och ökar produktionshastigheten. När detta händerkan det dock leda till att stora delar av projektet är skrivna på olika sätt men kanske på sättsom är tillräckligt läsbara eller åtminstone tillräckligt lika varandra för att någon annan iett senare skede skulle kunna gå tillbaka och förstå sig på och ändra koden. Dessutom gårdet om projektet inte är alltför stort gå tillbaka när en bättre eller åtminstone en uppdateradkodstandard har skrivits och då skriva om koden så att den följer den nya standarden.

G.6.1 Källkritik

Då de flesta av de källor som använts till denna text har publicerats antingen i en akademisktidskrift eller under en konferens kan det antas att dessa källor åtminstone har granskats avexperter. De källor som inte har publicerats i något av ovan nämnda format har haft infor-mation som överensstämmer med de publicerade källorna och med andra liknande källor.Därför har även dessa valts att tas med under denna undersökning.

Det finns inte mycket information gällande hur energieffektiva olika kodbaser är gentemotvarandra, det finns inte heller mycket information gällande energieffektivitet överhuvudta-get. De källor som finns fokuserar på att identifiera vad som kan få mjukvaror och programatt kräva mindre energi både vid körning och vid underhåll.

Det har varit svårt att hitta trovärdiga källor som säger att det inte är bra att följa en kodstan-dard, detta kan ha inneburit att undersökningen blivit snedvriden då argument från bådasidor inte har behandlats. Däremot är det också möjligt att konstatera att det inte finns någraegentliga argument mot att använda sig av en kodstandard utan att det istället borde vara ettkrav på att använda sig av någon sorts kodstandard.

93

G.7. Slutsatser

G.7 Slutsatser

I denna del sammanfattas och avslutas de frågeställningar som tagits upp och diskuteratsunder denna individuella del.

G.7.1 Frågeställning 1 och 2

Att ha en kodstandard vid utveckling av mjukvara kommer med ett stort antal fördelar. Tillatt börja med skapar den en tydlig struktur för hur koden ska skrivas samt hur den skastruktureras, detta leder i sin tur till att utvecklarna har en gemensam stil för hur kodenskrivs. Att ha en gemensam stil leder i sin tur till att det är lätt att byta ut vem som arbetarpå vilken komponent då det förhoppningsvis inte behöver läggas alltför många timmar påatt förstå sig på sin kollegas kod. När det inte borde ta flera extra timmar för att sätta sig in ikoden kan dessutom kostnaden för att underhålla programmet minskas då det går snabbareatt hitta problemen som finns samt att utöka den redan existerande kodbasen.

G.7.2 Frågeställning 3

Att det finns något tillfälle då det är bättre att inte använda en kodstandard är troligt, mende tillfällen som det bör ske ska inte vara många. Mestadels kan detta vara när den kodstan-dard som används istället för att hjälpa utvecklandet gör det svårare och mer komplicerat attutveckla eller då kodstandarden inte passar för utvecklingsspråket. Då kan det vara bättreatt använda sig av den egna programmeringsstilen för att få fram någon produkt som senaregår att justera när kodstandarden har blivit uppdaterad. Kort sagt kan det vara bättre att inteanvända sig av en kodstandard om den standard som finns är dåligt utvecklad, felaktig ellerinte passar till syftet.

G.7.3 Frågeställning 4

Då poängen med att skriva effektiv kod handlar om att minimera användandet av de hård-varuresurser som finns blir det nästan per automatik att effektivare kod kräver mindre energi.Däremot kan kod och projekt bli olika effektiva utan att aktivt eftersträva detta genom att an-vända sig av externa och interna bibliotek samt inbyggda funktioner. Små och medelstoraprogram använder sig av mindre energi när de använder sig av fler bibliotek och inbyggdafunktioner medan större program använder sig av mer energi när programmet utnyttjar bib-liotek och inbyggda funktioner. Det är viktigt att även tänka på att det går åt energi underbåde utvecklingsfasen för ett projekt och underhållsarbetet efteråt. Om det då finns en tydligstruktur för att förstå sig på och hitta fel eller utökningar för ett projekt kommer det att krä-vas färre arbetstimmar för att utveckla eller åtgärda programmet vilket i sin tur leder till attprojektet i sig minskar sin energiförbrukning.

94

Litteratur

[1] Sectra Communications AB. About Sectra Communications. URL:https://communications.sectra.com/about-sectra-communications(hämtad 2018-04-09).

[2] Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process.Addison-Wesley Professional, 2012. ISBN: 9780137043293.

[3] Git. URL: https://git-scm.com/ (hämtad 2018-04-28).

[4] GitLab-CI. URL: https://about.gitlab.com/features/gitlab-ci-cd/(hämtad 2018-04-28).

[5] Trello. URL: https://trello.com/about (hämtad 2018-04-27).

[6] Slack. URL: https://slack.com/about (hämtad 2018-04-27).

[7] Toggl. URL: https://toggl.com/ (hämtad 2018-04-27).

[8] Overleaf. URL: https://overleaf.com/about (hämtad 2018-04-27).

[9] Google Drive. URL: https://google.com/drive (hämtad 2018-04-27).

[10] Google Calendar. URL: https://google.com/calendar (hämtad 2018-04-27).

[11] Jim Conallen. ”Modeling Web Application Architectures with UML”. I:Communications of the ACM (1999). URL:http://www.cs.toronto.edu/km/tropos/conallen.pdf (hämtad2018-04-27).

[12] TypeScript. URL: https://www.typescriptlang.org (hämtad 2018-05-02).

[13] Angular. URL: https://angular.io (hämtad 2018-05-02).

[14] Material Design for Angular. URL: https://github.com/angular/material2(hämtad 2018-05-02).

[15] Bootstrap 4. URL: https://getbootstrap.com (hämtad 2018-05-02).

[16] Node.js. URL: https://nodejs.org/en/ (hämtad 2018-05-02).

[17] MariaDB. URL: https://mariadb.org (hämtad 2018-05-02).

[18] Visual Studio Code. URL: https://code.visualstudio.com (hämtad 2018-05-02).

[19] Protractor. URL: http://www.protractortest.org/#/ (hämtad 2018-04-27).

[20] David Orenstein. Application Programming Interface. 2000. URL:https://www.computerworld.com/article/2593623/app-development/application-programming-interface.html (hämtad2018-04-27).

[21] Chua Hock-Chuan. A Quick-Start Tutorial on Relational Database Design. 2010. URL:https://www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html (hämtad 2018-04-27).

[22] Kristian Sandahl. What is a System Anatomy? 2018. URL:https://www.ida.liu.se/~TDDD96/info/introanatomier.pdf (hämtad2018-04-27).

95

https://communications.sectra.com/about-sectra-communications

https://git-scm.com/

https://about.gitlab.com/features/gitlab-ci-cd/

https://trello.com/about

https://slack.com/about

https://toggl.com/

https://overleaf.com/about

https://google.com/drive

https://google.com/calendar

http://www.cs.toronto.edu/km/tropos/conallen.pdf

https://www.typescriptlang.org

https://angular.io

https://github.com/angular/material2

https://getbootstrap.com

https://nodejs.org/en/

https://mariadb.org

https://code.visualstudio.com

http://www.protractortest.org/#/

https://www.computerworld.com/article/2593623/app-development/application-programming-interface.html

https://www.computerworld.com/article/2593623/app-development/application-programming-interface.html

https://www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html

https://www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html

https://www.ida.liu.se/~TDDD96/info/introanatomier.pdf

Litteratur

[23] Marc Bachmann. html-pdf. URL: https://www.npmjs.com/package/html-pdf(hämtad 2018-04-20).

[24] Matthew Eernisse. EJS. URL: http://ejs.co/ (hämtad 2018-04-20).

[25] TypeScript samples. URL: https://www.typescriptlang.org/samples/ (hämtad2018-05-02).

[26] Play Framework. URL: https://www.playframework.com/ (hämtad 2018-05-01).

[27] Django. URL: https://www.djangoproject.com/ (hämtad 2018-05-07).

[28] Jennifer Champagne. The Top 7 Free and Open Source Database Software Solutions. URL:https://blog.capterra.com/free-database-software/ (hämtad2018-05-01).

[29] ”IEEE Standard for Software and System Test Documentation”. I: IEEE Std. 829-2008(2008). DOI: 10.1109/IEEESTD.2008.4578383.

[30] Youssef Bassil. ”A Simulation Model for the Waterfall Software Development LifeCycle”. I: International Journal of Engineering and Technology (iJET) 2 (2012).

[31] Agile Alliance. Agile 101. URL: https://www.agilealliance.org/agile101/(hämtad 2018-04-27).

[32] Manifest för Agil systemutveckling. URL:http://agilemanifesto.org/iso/sv/manifesto.html (hämtad 2018-04-27).

[33] Google Scholar. URL:https://scholar.google.com/intl/en/scholar/about.html (hämtad2018-04-27).

[34] Roger Brown. The agile testing pyramid. URL:http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid (hämtad 2018-04-29).

[35] Mike Wacker. Just say no to more end-to-end tests. URL:https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html (hämtad 2018-04-29).

[36] Edd Yerburgh. The Front-End Test Pyramid: How to Rethink Your Testing. URL:https://medium.freecodecamp.org/the-front-end-test-pyramid-rethink-your-testing-3b343c2bca51 (hämtad 2018-04-27).

[37] Joe Colantonio. Why the Testing Pyramid is Misleading. URL:https://www.joecolantonio.com/2015/12/09/why-the-testing-pyramid-is-misleading-think-scales/ (hämtad 2018-04-29).

[38] Kai Petersen, Claes Wohlin och Dejan Baca. ”The waterfall model in large-scaledevelopment”. I: 10th International Conference on Product-Focused Software ProcessImprovement (2009).

[39] David Parnas. ”Agile methods and GSD: The wrong solution to an old but realproblem”. I: Communications of the ACM 49.10 (2006), s. 29. URL:https://pdfs.semanticscholar.org/cf84/4eedb60a1698dc2cf7224b16ee148d917988.pdf.

[40] Juyun Cho. ”Issues and Challenges of Agile Software Development with Scrum”. I:Issues in Information Systems 9.2 (2008), s. 188–195. URL:https://pdfs.semanticscholar.org/713c/41d6f352f97a94af1af94c56e0ba2584effd.pdf.

[41] YongSeog Kim. ”Analyzing Scrum Agile Software Development with DevelopmentProcess, Social Factor, and Project Management Lenses”. I: AMCIS (2007). URL:https://pdfs.semanticscholar.org/2afa/1f810dc88b71e3e11abd2c26b2d5739cdd12.pdf.

96

https://www.npmjs.com/package/html-pdf

http://ejs.co/

https://www.typescriptlang.org/samples/

https://www.playframework.com/

https://www.djangoproject.com/

https://blog.capterra.com/free-database-software/

http://dx.doi.org/10.1109/IEEESTD.2008.4578383

https://www.agilealliance.org/agile101/

http://agilemanifesto.org/iso/sv/manifesto.html

https://scholar.google.com/intl/en/scholar/about.html

http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid

http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

https://medium.freecodecamp.org/the-front-end-test-pyramid-rethink-your-testing-3b343c2bca51

https://medium.freecodecamp.org/the-front-end-test-pyramid-rethink-your-testing-3b343c2bca51

https://www.joecolantonio.com/2015/12/09/why-the-testing-pyramid-is-misleading-think-scales/

https://www.joecolantonio.com/2015/12/09/why-the-testing-pyramid-is-misleading-think-scales/

https://pdfs.semanticscholar.org/cf84/4eedb60a1698dc2cf7224b16ee148d917988.pdf

https://pdfs.semanticscholar.org/cf84/4eedb60a1698dc2cf7224b16ee148d917988.pdf

https://pdfs.semanticscholar.org/713c/41d6f352f97a94af1af94c56e0ba2584effd.pdf

https://pdfs.semanticscholar.org/713c/41d6f352f97a94af1af94c56e0ba2584effd.pdf

https://pdfs.semanticscholar.org/2afa/1f810dc88b71e3e11abd2c26b2d5739cdd12.pdf

https://pdfs.semanticscholar.org/2afa/1f810dc88b71e3e11abd2c26b2d5739cdd12.pdf

Litteratur

[42] Open Web Application Security Project (OWASP). Cross-site Scripting (XSS). 2011. URL:https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)(hämtad 2018-04-28).

[43] Shaimaa Khalifa Mahmoud, Marco Alfonse, Mohamed Ismail Roushdy ochAbdel-Badeeh M. Salem. A Comparative Analysis of Cross Site Scripting (XSS) Detectingand Defensive Techniques. Eighth International Conference on Intelligent Computingoch Information Systems (ICICIS), 2017. ISBN: 978-1-5386-0821-0.

[44] Jeremiah Grossman. The origins of Cross-Site Scripting (XSS). 2006. URL:http://blog.jeremiahgrossman.com/2006/07/origins-of-cross-site-scripting-xss.html (hämtad 2018-04-28).

[45] Ryan Oberfelder. Describing XSS: The story hidden in time. 2017. URL:https://medium.com/@ryoberfelder/describing-xss-the-story-hidden-in-time-80c3600ffe81 (hämtad 2018-04-28).

[46] Microsoft blog (dross). Happy 10th birthday Cross-Site Scripting! 2009. URL:https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/ (hämtad 2018-04-28).

[47] World Wide Web Consortium (W3C). Document Object Model (DOM). 2005. URL:https://www.w3.org/DOM/ (hämtad 2018-04-28).

[48] World Wide Web Consortium (W3C) Tim Berners-Lee. URI References: FragmentIdentifiers on URIs. 1997. URL:https://www.w3.org/DesignIssues/Fragment.html (hämtad 2018-04-28).

[49] Open Web Application Security Project (OWASP). Types of Cross-Site Scripting. 2017.URL:https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting(hämtad 2018-04-29).

[50] Acunetix. Non-Persistent Cross-site scripting: Non-persistent XSS. 2014. URL:https://www.acunetix.com/blog/articles/non-persistent-xss/(hämtad 2018-04-29).

[51] Acunetix. What is Persistent XSS (Cross-Site Scripting). 2014. URL:https://www.acunetix.com/blog/articles/persistent-xss/ (hämtad2018-04-29).

[52] Acunetix. DOM XSS: An explanation of DOM-based Cross-Site Scripting. URL:https://www.acunetix.com/blog/articles/dom-xss-explained/(hämtad 2018-04-28).

[53] Netsparker. DOM Based Cross-site Scripting Vulnerability. URL:https://www.netsparker.com/blog/web-security/dom-based-cross-site-scripting-vulnerability/ (hämtad 2018-04-29).

[54] Open Web Application Security Project (OWASP). XSS (Cross Site Scripting) PreventionCheat Sheet. 2018. URL: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet (hämtad 2018-04-29).

[55] Sarah Vonnegut. 3 Ways to Prevent XSS. 2017. URL:https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/ (hämtad2018-04-29).

[56] World Wide Web Consortium (W3C). Using character escapes in markup and CSS. 2010.URL: https://www.w3.org/International/questions/qa-escapes.en(hämtad 2018-04-29).

97

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

http://blog.jeremiahgrossman.com/2006/07/origins-of-cross-site-scripting-xss.html

http://blog.jeremiahgrossman.com/2006/07/origins-of-cross-site-scripting-xss.html

https://medium.com/@ryoberfelder/describing-xss-the-story-hidden-in-time-80c3600ffe81

https://medium.com/@ryoberfelder/describing-xss-the-story-hidden-in-time-80c3600ffe81

https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/

https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/

https://www.w3.org/DOM/

https://www.w3.org/DesignIssues/Fragment.html

https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

https://www.acunetix.com/blog/articles/non-persistent-xss/

https://www.acunetix.com/blog/articles/persistent-xss/

https://www.acunetix.com/blog/articles/dom-xss-explained/

https://www.netsparker.com/blog/web-security/dom-based-cross-site-scripting-vulnerability/

https://www.netsparker.com/blog/web-security/dom-based-cross-site-scripting-vulnerability/

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/

https://www.w3.org/International/questions/qa-escapes.en

Litteratur

[57] Open Web Application Security Project (OWASP). DOM based XSS Prevention CheatSheet. 2017. URL: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet(hämtad 2018-04-29).

[58] Open Web Application Security Project (OWASP). OWASP Application Security FAQ.2016. URL:https://www.owasp.org/index.php/OWASP_Application_Security_FAQ(hämtad 2018-04-29).

[59] Angular. Security. URL: https://angular.io/guide/security (hämtad2018-04-29).

[60] Berkeley: University of California. How to Protect Against SQL Injection Attacks. 2018.URL: https://security.berkeley.edu/resources/best-practices-how-articles/system-application-security/how-protect-against-sql-injection (hämtad 2018-05-01).

[61] Sreedhar Danturthi. ”Comparative Study of Web Application Development with SQLServer and Db4o”. I: (2011). URL:http://www.idt.mdh.se/utbildning/exjobb/files/TR0927.pdf.

[62] Michael J. Donahoo och Gregory D. Speegle. SQL: Practical Guide for Developers.Elsevier Science och Technology, 2005. ISBN: 0122205316.

[63] Open Web Application Security Project (OWASP). Testing for SQL Injection(OTG-INPVAL-005). 2016. URL:https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) (hämtad 2018-05-01).

[64] Open Web Application Security Project (OWASP). OWASP Zed Attack Proxy Project.2018. URL:https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project(hämtad 2018-05-01).

[65] Divya Kilaru. ”Improving Techniques for SQL Injection Defenses”. I: (2014). URL:https://dspace.library.colostate.edu/bitstream/handle/10976/166750/Kilaru_uccs_0892N_10293.pdf?sequence=1.

[66] Martin Flodström och Oskar Vikholm. ”SQL-Injections: A wake-up call fordevelopers”. I: (2013). URL: https://www.diva-portal.org/smash/get/diva2:630946/FULLTEXT01.pdf.

[67] Stephen Thomas, Laurie Williams och Tao Xie. ”On automated prepared statementgeneration to remove SQL injection vulnerabilities”. I: (2008). URL:https://pdfs.semanticscholar.org/2f36/058986f8ae4887baaf7569f5458567301d87.pdf.

[68] Lianping Chen. ”Towards Architecting for Continuous Delivery”. I: 12th WorkingIEEE/IFIP Conference on Software Architecture (2015). DOI: 10.1109/WICSA.2015.23.

[69] What is version control? 2018. URL:https://www.atlassian.com/git/tutorials/what-is-version-control(hämtad 2018-05-09).

[70] Feature branching your way to greatness. 2018. URL:https://www.atlassian.com/agile/software-development/branching(hämtad 2018-05-18).

[71] Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2005.

[72] Agile software development benefits. 2018. URL:https://www.versionone.com/agile-101/agile-software-development-benefits/ (hämtad 2018-05-09).

98

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/OWASP_Application_Security_FAQ

https://angular.io/guide/security

https://security.berkeley.edu/resources/best-practices-how-articles/system-application-security/how-protect-against-sql-injection



http://www.idt.mdh.se/utbildning/exjobb/files/TR0927.pdf

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

https://dspace.library.colostate.edu/bitstream/handle/10976/166750/Kilaru_uccs_0892N_10293.pdf?sequence=1

https://dspace.library.colostate.edu/bitstream/handle/10976/166750/Kilaru_uccs_0892N_10293.pdf?sequence=1

https://www.diva-portal.org/smash/get/diva2:630946/FULLTEXT01.pdf

https://www.diva-portal.org/smash/get/diva2:630946/FULLTEXT01.pdf

https://pdfs.semanticscholar.org/2f36/058986f8ae4887baaf7569f5458567301d87.pdf

https://pdfs.semanticscholar.org/2f36/058986f8ae4887baaf7569f5458567301d87.pdf

http://dx.doi.org/10.1109/WICSA.2015.23

https://www.atlassian.com/git/tutorials/what-is-version-control

https://www.atlassian.com/agile/software-development/branching

https://www.versionone.com/agile-101/agile-software-development-benefits/

https://www.versionone.com/agile-101/agile-software-development-benefits/

Litteratur

[73] IEEE-Xplore. 2018. URL: https://ieeexplore.ieee.org/Xplore/home.jsp(hämtad 2018-05-06).

[74] Continuous Delivery. 2018. URL: https://continuousdelivery.com/ (hämtad2018-05-09).

[75] Mojtaba Shahin, Muhammad Ali Babar och Liming Zhu. ”Continuous Integration,Delivery and Deployment: A Systematic Review on Approaches, Tools, Challengesand Practices”. I: IEEE Access 5 (2015). DOI: 10.1109/ACCESS.2017.2685629.

[76] Lianping Chen. ”Continuous Delivery: Huge Benefits, but Challenges Too”. I: IEEESoftware 32 (2015). DOI: 10.1109/MS.2015.27.

[77] Arbetsmiljöverket. Inomhusmiljö. 2018. URL: https://www.av.se/inomhusmiljo/(hämtad 2018-05-01).

[78] Carl-Göran Ohlson och Peter Westerholm Sten Bornberger-Dankvardt. Arbetsmiljö- ochhälsoarbete i småföretag - försök till helhetsbild. Arbetslivsinstitutet, 2003. ISBN:91-7045-661-5.

[79] Arbetsmiljöverket. Olika typer av kontorslokaler. 2018. URL:https://www.av.se/inomhusmiljo/lokaler-och-arbetsutrymme/lokalernas-storlek/olika-typer-av-kontorslokaler/(hämtad 2018-05-01).

[80] Prevent. Olika kontorstyper. 2018. URL:https://www.prevent.se/formakontoret/fakta-substart/test/(hämtad 2018-05-01).

[81] Arbetsmiljöverket. Dator- och bildskärmsarbete. 2018. URL:https://www.av.se/inomhusmiljo/dator--och-bildskarmsarbete/(hämtad 2018-05-01).

[82] Arbetsmiljöverket. Ljud och akustik. 2018. URL:https://www.av.se/inomhusmiljo/ljud-och-akustik/ (hämtad2018-05-01).

[83] Arbetsmiljöverket. Belasta rösten rätt. 2018. URL: https://www.av.se/inomhusmiljo/ljud-och-akustik/belasta-rosten-ratt/(hämtad 2018-05-01).

[84] Arbetsmiljöverket. Ljus och belysning. 2018. URL:https://www.av.se/inomhusmiljo/ljus-och-belysning/ (hämtad2018-05-01).

[85] Arbetsmiljöverket. Belysning på kontor. 2018. URL:https://www.av.se/inomhusmiljo/ljus-och-belysning/belysning-pa-kontor/ (hämtad 2018-05-01).

[86] Google. Google c++ Style Guide. 2017. URL:https://google.github.io/styleguide/cppguide.html (hämtad2018-05-01).

[87] Eugenio Capra, Chiara Francalanci och Sandra A. Slaughter. ”Is software “green”?Application development environments and energy efficiency in open sourceapplications”. I: Information and Software Technology 54.1 (2012), s. 60–71. ISSN:0950-5849. DOI: 10.1016/j.infsof.2011.07.005.

[88] Likoebe M Maruping, Xiaojun Zhang och Viswanath Venkatesh. ”Role of collectiveownership and coding standards in coordinating expertise in software project teams”.I: European Journal of Information Systems 18.4 (aug. 2009), s. 355–371. ISSN: 1476-9344.DOI: 10.1057/ejis.2009.24.

99

https://ieeexplore.ieee.org/Xplore/home.jsp

https://continuousdelivery.com/

http://dx.doi.org/10.1109/ACCESS.2017.2685629

http://dx.doi.org/10.1109/MS.2015.27

https://www.av.se/inomhusmiljo/

https://www.av.se/inomhusmiljo/lokaler-och-arbetsutrymme/lokalernas-storlek/olika-typer-av-kontorslokaler/

https://www.av.se/inomhusmiljo/lokaler-och-arbetsutrymme/lokalernas-storlek/olika-typer-av-kontorslokaler/

https://www.prevent.se/formakontoret/fakta-substart/test/

https://www.av.se/inomhusmiljo/dator--och-bildskarmsarbete/

https://www.av.se/inomhusmiljo/ljud-och-akustik/

https://www.av.se/inomhusmiljo/ljud-och-akustik/belasta-rosten-ratt/

https://www.av.se/inomhusmiljo/ljud-och-akustik/belasta-rosten-ratt/

https://www.av.se/inomhusmiljo/ljus-och-belysning/

https://www.av.se/inomhusmiljo/ljus-och-belysning/belysning-pa-kontor/

https://www.av.se/inomhusmiljo/ljus-och-belysning/belysning-pa-kontor/

https://google.github.io/styleguide/cppguide.html

http://dx.doi.org/10.1016/j.infsof.2011.07.005

http://dx.doi.org/10.1057/ejis.2009.24

Litteratur

[89] Sun Microsystems Inc. Code Conventions for the Java Programming Language. 1999. URL:http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-139411.html#16712 (hämtad 2018-05-03).

[90] Overpass Apps. Why Coding Standards Are Important. URL:https://www.overpass.co.uk/coding-standards-important/ (hämtad2018-05-03).

[91] Taek Lee, Jung Been Lee och Hoh Peter In. ”A study of different coding styles affectingcode readability”. English. I: International Journal of Software Engineering and itsApplications 7.5 (okt. 2013), s. 413–422. ISSN: 1738-9984. DOI:10.14257/ijseia.2013.7.5.36.

[92] Taek Lee, Jung Been Lee och Hoh Peter In. ”Effect Analysis of Coding ConventionViolations on Readability of Post-Delivered Code”. I: IEICE Transactions on Informationand Systems E98.D.7 (2015), s. 1286–1296. DOI: 10.1587/transinf.2014EDP7327.

[93] Yanqing Wang, Bo Zheng och Hujie Huang. ”Complying with Coding Standards orRetaining Programming Style: A Quality Outlook at Source Code Level”. I: JSEA 1.1(jan. 2008), s. 88–91. DOI: 10.4236/jsea.2008.11013.

[94] Parasoft. Use Coding Standards to Increase Efficiency and Productivity. URL:http://www.theportal.sg/Portal/Download/UseCodingStandardstoIncreaseEfficiencyandProductivity.pdf(hämtad 2018-05-05).

[95] AirBnB. Airbnb JavaScript Style Guide. URL: github.com/airbnb/ (hämtad2018-02-15).

[96] The Angular Team. Style Guide. URL: https://angular.io/guide/styleguide(hämtad 2018-02-15).

100

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-139411.html#16712

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-139411.html#16712

https://www.overpass.co.uk/coding-standards-important/

http://dx.doi.org/10.14257/ijseia.2013.7.5.36

http://dx.doi.org/10.1587/transinf.2014EDP7327

http://dx.doi.org/10.4236/jsea.2008.11013

http://www.theportal.sg/Portal/Download/UseCodingStandardstoIncreaseEfficiencyandProductivity.pdf

http://www.theportal.sg/Portal/Download/UseCodingStandardstoIncreaseEfficiencyandProductivity.pdf

github.com/airbnb/

https://angular.io/guide/styleguide

spårbarhetssystem för...

Documents