Webbapplikation för den operativa polisen : Gör polisingripanden mycket smidigare

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2019 | LIU-IDA/LITH-EX-G--19/012--SE

Webbapplikation för den

operativa polisen

–

Gör polisingripanden mycket smidigare

Web application for the operational police

–

Makes police interventions much smoother

Yousef Hashem

Martin Brolin

Elmedin Zildzic

Joakim Tao

Jacob Larsson

Viktor Blidh

Handledare : David Hasselquist Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från pub-liceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till doku-mentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upp-hovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgänglig-heten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende el-ler egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

© Yousef Hashem Martin Brolin Elmedin Zildzic Joakim Tao Jacob Larsson Viktor Blidh

Sammanfattning

Denna rapport beskriver ett kandidatarbete som utfördes av sex studenter från civilingen-jörsprogrammen inom datateknik och mjukvaruteknik vid Linköpings universitet. Projektet utfördes som ett obligatoriskt kursmoment i kursen TDDD96 – Kandidatprojekt i program-varuutveckling under våren 2019.

Syftet med arbetet var att utveckla en webbapplikation för Polismyndigheten som ska vara ett konceptbevis för ett eventuellt utryckningssystem. Produkten som togs fram var en webbapplikation med mobil- och datorläge och kart-, larm- och förstärkningsfunktionalitet.

En modifierad, mer begränsad variant av det agila systemutvecklingsramverket Scrum har använts under projektets utförandefas. Alla medlemmar i teamet har utfört en individuell studie inom ett ämne relevant till projektarbetet. Dessa individuella bidrag finns att läsa i slutet av rapporten.

Författarens tack

Teamet vill tacka vår kundkontakt, Niclas Appleby, som har varit väldigt kontaktbar och flexibel med mötestider under hela projektets gång. Dessutom vill vi tacka poliserna som har varit med och informerat oss om hur polisens nuvarande system fungerar och kommit med önskemål till produkten. Speciellt vill vi tacka Lars Sandberg och Björn Forslind, som åkte från Rinkeby till Linköping för att delta på ett möte.

Dessutom vill vi tacka Kristian Sandahl och kursledningen för en väldigt välplanerad och lärorik kurs. Ett stort tack måste även riktas till teamets handledare, David Hasselquist, som har varit med och guidat oss under projektets gång.

Innehåll

2.3 Kommunikation vid ingripanden . . . 3

2.3.1 Nuvarande metod . . . 4

2.3.2 Vision . . . 4

2.4 Tidigare erfarenheter . . . 4

3 Teori 5 3.1 Systemanatomi . . . 5

3.2 Verktyg och ramverk . . . 5

3.2.1 Django . . . 5

3.2.2 Vue . . . 5

3.2.3 SQLite . . . 6

3.2.4 Google API . . . 6

3.2.5 Websockets . . . 6

3.2.6 Visual Studio Code . . . 6

3.3 Adminsitrativa verktyg . . . 6 3.3.1 Scrum . . . 7 3.3.2 Git . . . 7 3.3.3 Gitlab . . . 7 3.3.4 LaTeX . . . 7 3.3.5 Overleaf . . . 8 3.3.6 Google Drive . . . 8 3.3.7 Google Calendar . . . 8 3.3.8 Heroku . . . 8 3.3.9 Slack . . . 8 4 Metod 9 4.1 Projektmedlemmar och roller . . . 9

4.3 Utvecklingsmetodik . . . 10 4.3.1 Arbetssätt . . . 10 4.3.2 Kommunikation . . . 11 4.3.3 Utbildning . . . 12 4.3.4 Versionshantering . . . 12 4.3.5 Testning . . . 12 4.3.6 Kvalitetsutveckling . . . 12 4.3.7 Riskanalys . . . 13 4.4 Dokumentation . . . 13

4.5 Metod för att fånga erfarenheter . . . 13

5 Resultat 15 5.1 Systembeskrivning . . . 15 5.1.1 Systemanatomi . . . 15 5.1.2 Klient-Server arkitektur . . . 18 5.1.3 Front-end . . . 18 5.1.4 Back-end . . . 23 5.1.5 Heroku . . . 24 5.2 Värde för kunden . . . 25 5.3 Gemensamma erfarenheter . . . 25 5.4 Individuella bidrag . . . 26

5.4.1 Jämförelse av Vue.js och Angular/AngularJS för nybörjare av Yousef Hashem . . . 26

5.4.2 Jämförelse mellan mobilapplikationer och webbapplikationer av Mar-tin Brolin . . . 26

5.4.3 Man-in-the-middle attack i HTTPS av Elmedin Zildzic . . . 26

5.4.4 Jämförelser av Google Map API med andra API av Joakim Tao . . . 26

5.4.5 Dynamisk typning i JavaScript – en typisk undersökning av Jacob Larsson 26 5.4.6 En webbapplikations sårbarhet mot CSRF-attacker av Viktor Blidh . . . 27

6 Diskussion 28 6.1 Resultat . . . 28

6.1.1 Alternativa implementationssätt . . . 28

6.1.2 Kvarstående arbete . . . 29

6.1.3 Förbättringar sedan tidigare projekt . . . 30

6.1.4 Lärdomar inför framtiden . . . 30

6.2 Metod . . . 31

6.2.1 Organisation . . . 31

6.2.2 Utveckling . . . 31

6.2.3 Dokumentation . . . 31

6.2.4 Källkritik . . . 32

6.2.5 Förbättringsmöjligheter i framtida projekt . . . 32

6.3 Arbetet i ett bredare sammanhang . . . 32

6.3.1 Tillgänglig oanvänd teknik . . . 32

6.3.2 Nya möjligheter . . . 32

6.3.3 Nya problem . . . 33

6.3.4 Miljöaspekter . . . 33

6.3.5 Social hållbarhet . . . 33

7 Slutsatser 35 7.1 Hur kan MRP implementeras så att det skapar ett värde för kunden? . . . 35

7.2 Vilka erfarenheter kan dokumenteras från kandidatprojektet som kan vara in-tressanta för framtida projekt? . . . 35

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

7.4 Var det rätt val att göra MRP till en webbapplikation? . . . 36

7.5 Uppfyller projektet sitt syfte? . . . 36

A Jämförelse av Vue.js och Angular/AngularJS för nybörjare av Yousef Hashem 37 A.1 Inledning . . . 37 A.1.1 Syfte . . . 37 A.1.2 Frågeställning . . . 37 A.1.3 Avgränsningar . . . 38 A.2 Bakgrund . . . 38 A.3 Teori . . . 38 A.3.1 JavaScript . . . 38 A.3.2 TypeScript . . . 38 A.3.3 Vue.js . . . 38 A.3.4 Angular/AngularJS . . . 38 A.4 Metod . . . 39 A.4.1 Litteraturstudie . . . 39 A.5 Resultat . . . 39 A.5.1 Historia . . . 39 A.5.2 Företagsstöd . . . 39 A.5.3 Popularitet . . . 40 A.5.4 Nybörjarvänlighet . . . 41 A.5.5 Basfunktioner . . . 41 A.6 Diskussion . . . 42 A.6.1 Resultat . . . 42 A.6.2 Metod . . . 42 A.7 Slutsatser . . . 42

B Jämförelse mellan mobilapplikationer och webbapplikationer av Martin Brolin 44 B.1 Inledning . . . 44 B.1.1 Syfte . . . 44 B.1.2 Frågeställning . . . 44 B.1.3 Avgränsningar . . . 45 B.2 Bakgrund . . . 45 B.3 Teori . . . 45 B.3.1 Webbapplikation . . . 45 B.3.2 Mobilapplikation . . . 45 B.3.3 iOS . . . 45 B.3.4 Swift . . . 45 B.3.5 Android . . . 45 B.3.6 Java . . . 46 B.3.7 Caching . . . 46 B.4 Metod . . . 46 B.5 Resultat . . . 46 B.5.1 Implementationsmöjligheter . . . 46

B.5.2 Programmeringsspråken för oerfarna programmerare . . . 46

B.5.3 Applikationerna för oerfarna programmerare . . . 47

B.5.4 Webbapplikation . . . 49 B.5.5 Uppstart av applikationen . . . 49 B.5.6 Prestanda . . . 50 B.5.7 Intäktsgenerering . . . 50 B.6 Diskussion . . . 50 B.6.1 Resultat . . . 50

B.6.2 Metod . . . 50

B.7 Slutsats . . . 51

B.7.1 Vilka för- och nackdelar kan det finnas med att enbart utveckla web-bapplikationer före mobilapplikationer för mobilanvändare inom pre-standa och i vilka scenarion är det fördelaktigt att utveckla enbart en webbapplikation eller mobilapplikation? . . . 51

B.7.2 Var det lämpligt att välja webbapplikation istället för mobilapplikation i detta projekt? . . . 51

C Man-in-the-middle attack i HTTPS av Elmedin Zildzic 52 C.1 Inledning . . . 52 C.1.1 Syfte . . . 52 C.1.2 Frågeställning . . . 52 C.1.3 Avgränsningar . . . 52 C.2 Bakgrund . . . 53 C.3 Teori . . . 53 C.3.1 HTTPS . . . 53

C.3.2 Certificate Authorities (CA) . . . 53

C.3.3 SSL/TLS . . . 53

C.4 Metod . . . 54

C.5 Resultat . . . 54

C.5.1 Åtgärder hos klienten . . . 55

C.5.2 Skydda webbapplikationen mot MITM . . . 55

C.6 Diskussion . . . 56

C.6.1 Användare uppdaterar inte sina system . . . 56

C.7 Slutsats . . . 56

D Jämförelser av Google Maps API med andra API av Joakim Tao 58 D.1 Inledning . . . 58 D.1.1 Syfte . . . 58 D.1.2 Frågeställning . . . 58 D.1.3 Avgränsningar . . . 59 D.2 Bakgrund . . . 59 D.3 Teori . . . 59 D.3.1 Geocoding . . . 59 D.3.2 Geocoding process . . . 59 D.3.3 Gorilla Index . . . 60 D.3.4 DX index . . . 60 D.3.5 Statiska kartor . . . 61 D.3.6 Dynamiska kartor . . . 61 D.4 Metod . . . 61 D.5 Resultat . . . 61

D.5.1 Google Maps API . . . 61

D.5.2 Mapquest API . . . 62

D.5.3 Bing Maps API . . . 62

D.5.4 Mapbox API . . . 62

D.6 Diskussion . . . 63

D.6.1 Resultat . . . 63

D.7 Slutsats . . . 63

D.7.1 Vad finns det för för- och nackdelar med att använda Google Maps API samt vad är kostnaden jämfört med Mapquest API? . . . 64

D.7.2 Vad finns det för för- och nackdelar med att använda Google Maps API samt vad är kostnaden jämfört med Microsoft Bing Maps API? . . . 64

D.7.3 Vad finns det för för- och nackdelar med att använda Googles Maps

API samt vad är kostnaden jämfört med Mapbox API? . . . 64

E Dynamisk typning i JavaScript – en typisk undersökning av Jacob Larsson 65 E.1 Inledning . . . 65 E.1.1 Syfte . . . 65 E.1.2 Frågeställning . . . 65 E.1.3 Avgränsningar . . . 66 E.2 Bakgrund . . . 66 E.3 Teori . . . 66 E.3.1 Typsystem . . . 66

E.3.2 JavaScript som språk . . . 66

E.3.3 Dynamisk typning . . . 66

E.3.4 Strikt typning . . . 67

E.4 Metod . . . 67

E.4.1 Internetkällor . . . 67

E.4.2 Erfarenheter från projektet . . . 68

E.5 Resultat . . . 68

E.5.1 Gruppens slutsatser . . . 68

E.5.2 Skillnad i utvecklingstider . . . 68

E.5.3 Flexibilitet . . . 69 E.6 Diskussion . . . 69 E.6.1 Resultat . . . 69 E.6.2 Utvecklingstider . . . 70 E.6.3 Metod . . . 70 E.6.4 Källkritik . . . 70 E.7 Slutsats . . . 70 E.7.1 Frågeställning 1 . . . 70 E.7.2 Frågeställning 2 . . . 71

F En webbapplikations sårbarhet mot CSRF-attacker av Viktor Blidh 72 F.1 Inledning . . . 72

F.1.1 Syfte . . . 72

F.1.2 Frågeställning . . . 72

F.2 Bakgrund . . . 73

F.3 Teori . . . 73

F.3.1 Exempel på en CSRF attack via GET request . . . 73

F.3.2 Exempel på en CSRF attack via en POST . . . 74

F.4 Metod . . . 74

F.5 Resultat . . . 74

F.5.1 Begränsningar hos en CSRF attack . . . 74

F.5.2 Skydd mot CSRF . . . 75 F.5.3 MRPs sårbarhet mot CSRF . . . 76 F.6 Diskussion . . . 76 F.6.1 Litteraturstudie . . . 76 F.6.2 Kodanalys . . . 77 F.6.3 Källkritik . . . 77 F.7 Slutsatser . . . 77

F.7.1 Hur går en CSRF-attack till och vilka utmaningar ställs en angripare inför för att med framgång utföra en CSRF-attack? . . . 77

F.7.2 Vilka grundläggande åtgärder kan en utvecklare ta till för att minimera en webbapplikations sårbarhet mot CSRF-attacker? . . . 77

F.7.3 Hur sårbar är projektets webbapplikation mot CSRF-attacker och vad kan gruppen göra för att motverka denna eventuella sårbarhet? . . . 77

Figurer

5.5 Sida för att skapa nya användare . . . 19

5.6 Mobilläge . . . 20

5.7 Sida med karta för Ledningscentralen . . . 20

5.8 Ledningcentralsläget där en användare i Mobilläget ber om förstärkning . . . 21

5.9 Inmatning av information . . . 21

5.10 Larmfunktionalitet i Mobilläget . . . 22

5.11 Lista med aktiva poliser . . . 22

5.12 Responstiden för ett larm . . . 23

5.13 Översikt av hur servern distribuerar data till klienterna . . . 24

5.14 Djangos administrationssida . . . 24

A.1 Antalet nedladdningar av Angular/AngularJS respektive Vue.js . . . 40

B.1 Filerna i ett nyskapat Andriodprojekt . . . 47

B.2 "Hello World”-applikation på Android . . . 48

B.3 ”Hello World”-applikation på iOS . . . 48

B.4 HTML-kod för webbapplikationen . . . 49

B.5 “Hello world” på en webbapplikation . . . 49

C.1 Överskådlig bild av hur en MITM attack ser ut . . . 54

D.1 Geocoding process . . . 60

D.2 Kostnaden för Mapquest Map API paket . . . 62

E.1 Generella skillnader mellan ett dynamisk och statisk typsystem . . . 67

E.2 Resultatet från Stuchliks experiment, x-axeln visar uppgiftsnummer och y-axeln ett sammanfattningstal för differensen i utvecklingstid där ett negativt tal betyder att det dynamiska är snabbare . . . 69

Tabeller

4.1 Ansvarsområden . . . 9

4.2 Milstolpar för de olika iterationerna . . . 11

4.3 Risker . . . 13

4.4 Dokument som skrivits . . . 14

Definitioner

I detta avsnitt introduceras och förklaras alla begrepp som inte antas vara självklara för läsa-ren.

• NFC: Nationellt Forensiskt Centrum, en avdelning inom polismyndigheten. • Team: Ett arbetslag som har ett gemensamt huvudmål.

• Webbapplikation: En applikation som körs direkt i en webbläsare.

• Ledningsläge: Ett läge i webbapplikationen som är avsett att användas av Lednings-centralen.

• Mobilläge: Ett läge i webbapplikationen som är avsett att användas av den operativa polisen samt insatsledaren.

• Back-end: Mjukvaran som bygger upp server- och databasfunktionalitet i en webbap-plikation.

• Front-end: Mjukvaran som bygger upp det yttre lagret av en webbapplikation, det vill säga det användarna interagerar med.

• Python: Ett simpelt programmeringsspråk. Används bland annat för webb- och appli-kationsutveckling.

• Javascript: Ett skriptspråk som primärt används för webbutveckling.

• Node.js: Ett programsystem som används för att skapa skalbara webbservrar och andra internetapplikationer.

• HTML: Kort för HyperText Markup Language. Standardmärkspråket för att skapa webbsidor. Den senaste standarden kallas HTML5.

• CSS: Kort för Cascading Style Sheets. Ett språk för att skapa stilmallar för dokument och webbsidor.

• Vue: Kort för Vue.js. Ett ramverk för webbutveckling som specialiserar sig på front-end och använder sig av Javascript, HTML och CSS. Körs på Node.js.

• SQL: Standardiserat språk för att hämta och modifiera data i databaser. • SQLite: Programvarubibliotek som implementerar en filbaserad SQL-databas. • API: Ett gränssnitt som utvecklare kan programmera mot.

• Google Maps: En kart- och sattelittjänst från Google.

• Scrum: En metodik för systemutveckling som går ut på att arbeta agilt. • Sprint: Tidsintervall i Scrum under vilket ett team utför ett antal av uppgifter.

Tabeller

• Sprint review meeting: Möte efter en sprint under vilket teamet och kunden går ige-nom vad som gjorts under sprinten.

• Product Backlog: Lista av saker som ska göras.

• Single-page application: En webbapplikation som interagerar med användaren genom att dynamiskt skriva om nuvarande sida istället för att ladda in en ny sida från en server. • Use case: Ett use case innehåller ett eller flera scenarion som beskriver hur systemet ska

interagera med sin omvärld för att uppnå ett specifikt mål.

• Patreon: En donationstjänst där individer kan donera pengar och stödja andra privat-personer eller projekt.

• Git: Ett verktyg för versionshantering som används för att bevaka förändringar i käll-kod under mjukvaruutveckling.

• Commit: En specifik version av källkoden som bevakas i ett Git-arkiv

• CI-Skript: Ett skript för att automatisera kontinuerlig integration av ny kod i ett källkods-arkiv

• CLI: Kort för Command-line Interface. En komandotolk vilket är ett gränssnitt där an-vändare kan mata in kommandon.

• Platform-as-a-Service: En molntjänst som tillhandahåller en datorplattform som ut-vecklare kan ladda upp sina applikationer på.

• Socket: En kommunikationspunkt (oftast på en server) som binder sig till en port och lyssnar efter socketanslutningar från en klient.

1

Inledning

Denna rapport består av två delar; en gemensam del och en individuell del. Den gemensam-ma delen av rapporten beskriver metoden, teorin, processen och resultatet av det projektar-bete teamet utförde, samt en diskussion kring resultatet. Den individuella delen består av sex individuella utredningar som redovisas; en utredning per teammedlem. Projektarbetet är ett obligatoriskt moment i kursen TDDD96 – Kandidatprojekt i programvaruutveckling på Linköpings universitet.

Teamet bestod av sex civilingenjörsstudenter, varav fem från Civilingenjörsprogrammet i datateknik och en från Civilingenjörsprogrammet i mjukvaruteknik. Projektarbetet gick ut på att skapa en webbapplikation för Nationellt Forensiskt Centrum. Teamet kallar produkten för MRP, en förkortning av Mobile Reinforcements for the Police. Produkten publicerades efter projektarbetets slut som öppen källkod under MIT-licens.

Detta avsnitt behandlar motiveringen och syftet med applikationen som utvecklades, samt frågeställningen som besvaras i Kapitel 7 i rapporten.

1.1

Motivering

Den operativa polisens ingripanden tar idag lång tid och styrs ofta av radioanrop från Ledningscentralen, vilket kan förbättras. Ett ingripande börjar ofta med ett radioanrop där patrullen som skall ingripa får en adress och en kort beskrivning av Ledningscentralen. Ef-tersom denna information endast tillhandages via röststyrd kommunikation blir det svårt att komma ihåg alla diverse detaljer som kan uppkomma under stressfyllda ingripanden.

Om radioanropen för ingripanden istället komplementeras med en applikation där Led-ningscentralen kan larma en position kan den operativa polisen få mer information snabbare. Genom att visa position, vägbeskrivningar och eventuellt annan data på en mobiltelefon kan poliserna som ska ingripa ta sig till den larmade positionen på ett smidigare sätt samt sam-arbeta när de väl är på plats. Applikationen kan då agera som ett hjälpmedel för kommuni-kation och koordination.

Polisen kan dock inte skapa ett nytt system utan att vara säkra på att det nya systemet kommer förbättra det nuvarande systemet. Det kan kräva lagändringar eller omorganisation för ett nytt system att implementeras, vilket gör det svårt att påbörja utvecklingen av en applikation vars funktionalitet inte nödvändigtvis gynnar polisen.

1.2. Syfte

För att undvika ovannämnda risk finns ett behov för att bevisa att systemets koncept kan realiseras. Målet med systemet som utvecklades var att skapa ett konceptbevis och därmed minska riskerna för resurserna som krävs ska vara oproportionerliga gentemot förbättring-arna.

1.2

Syfte

Syftet med detta projektarbete var att designa och utveckla en applikation som NFC kan använda som konceptbevis när de ska presentera projektet för avdelningen som utvecklar programvara för polisen. Viktiga egenskaper som potentiella slutanvändare nämnde på ett möte var lättillgängliga funktioner och en intuitiv och användarvänlig design.

Projektarbetet utfördes i utbildande syfte och var ett obligatoriskt kursmoment i kursen TDDD96 – Kandidatprojekt i programvaruutveckling på Linköpings universitet. Teamets mål med projektarbetet var att lära sig mer om webbutveckling, databashantering, samarbete in-om större projekt och rapportskrivning i allmänhet, samt att leverera en produkt sin-om NFC kan använda som ett bevis på den funktionalitet de vill att slutprodukten ska ha.

Denna rapport består av en gemensam del, som beskriver projektarbetets process, samt en individuell del för varje medlem i teamet. Den individuella delen är en undersökning av en hypotes relevant till projektarbetet.

1.3

Frågeställning

1. Hur kan MRP implementeras så att det skapar ett värde för kunden?

2. Vilka erfarenheter kan dokumenteras från kandidatprojektet som kan vara intressanta för framtida projekt?

3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? 4. Var det rätt val att göra MRP till en webbapplikation?

5. Uppfyller projektet sitt syfte?

1.4

Avgränsningar

Projektmedlemmarna är avsedda att lägga ned 400 timmar var på projektet, dvs att pro-jektet är begränsat till sammanlagt 2400 timmar. Av dessa timmar är 100 timmar var, eller sammanlagt 600 timmar, avsedda till den gemensamma och de individuella delarna av kan-didatrapporten. I den resterande tiden ingår utbildning, utveckling, gruppsammanhållning och dokumentarbete.

Produkten kommer användas som ett konceptbevis och tekniska säkerhetsaspekter kom-mer därför inte tas i hänsyn. Exempelvis komkom-mer databasen inte ha några säkerhetstillämp-ningar utöver det som redan finns inbyggt i databasen.

Produkten är i första hand avsedd att fungera på enheter med operativsystem Windows eller Android. Produkten bör dock fungera på alla operativsystem som kan använda en webbläsare.

2

Bakgrund

Detta kapitel behandlar kunden, vilka de är och hur deras nuvarande metod för ingripanden ser ut, samt uppgiften som teamet blev tilldelad. Dessutom tas teamets tidigare erfarenheter inom webbutveckling och projektarbeten upp.

2.1

Kunden

Nationellt Forensiskt Centrum, NFC, har en sektion inom informationsteknologi. Denna sek-tion ansvarar bland annat för IT-utveckling inom polismyndigheten och det är denna seksek-tion teamet arbetade med. Kontakten med NFC skedde via Niclas Appleby.

På grund av projektets storlek och av säkerhetsskäl kommer produkten som produce-rades i detta projekt inte se någon användning hos operativa poliser. MRP kommer endast vara ett konceptbevis och en prototyp för en eventuell applikation med samma eller liknande funktionalitet. Ifall polisen dömmer att MRPs funktionalitet är värd att satsa på kommer en likande applikation skapas internt av NFC:s egna utvecklare.

2.2

Uppgift

Ingripanden idag tar lång tid och processen att skapa nya system kan vara väldigt kostsam för polisen. Genom att skapa ett system som visar att konceptet kan realiseras och vilken funktionalitet som kan byggas in i systemet kan den potentiella kostnaden för att utveckla ett liknande system minskas drastiskt. Uppgiften teamet tog sig an var att skapa en sådan applikation åt NFC, som de sedan kan visa för sina interna utvecklare som en specifikation på funktionaliteten de vill ha. System skulle specifikt fungera både på Windows- och Andro-idenheter.

2.3

Kommunikation vid ingripanden

För att förstå hur polisens nuvarande kommunikationssystem fungerar och vad målet är kommer detta avsnitt beskriva polisens nuvarande system och förklara hur polisens vision för kommunikation ser ut.

2.4. Tidigare erfarenheter

2.3.1

Nuvarande metod

Idag använder polisen primärt radioanrop för förmedling av information under ingripanden. Radiosystemet som används av polisen använder sig av ett kösystem, där ledningscentralen prioriterar anrop i kösystemet. Detta radiosystem kompletteras med en skärm i utvalda po-lisbilar som visar informationen som ges via radion.

Detta system är inte särskilt effektivt då all information om brottsplatsen förmedlas via röstkommunikation och poliserna i fråga måste memorera all information efter ett snabbt ra-dioanrop. Med hjälp av en liten skärm som visar informationen från anropet när poliserna befinner sig i polisbilarna kan detta problem till en viss grad förhindras. Detta är dock en-dast i polisbilarna och denna funktion försvinner så fort poliserna i fråga måste förflytta sig någonstans till fots.

Även när poliserna pratar med en misstänkt fallerar systemet, då deras öronsnäcka i många fall måste plockas ur för att det pågår för mycket parallellt i örat. Ett annat exem-pel är när någon polis jagar någon och får ett anrop samtidigt, anropet kan då missas för att polisen fokuserar på jakten istället för att fokusera på det som sägs.

2.3.2

Vision

På grund av att syftet med projektet var att utveckla en prototyp var visionen att prototypen skulle hålla en tillräckligt hög kvalitet för NFC att välja att fortsätta utveckla konceptet. Vida-re var visionen att konceptet skulle implementeras och användas i Polismyndighetens orga-nisation. De samhällsmässiga konsekvenserna kan bli en effektivare polisstyrka i Sverige och därmed ett tryggare samhälle. En annan vision var att källkoden skulle hålla tillräckligt god kvalitet för NFC att fortsätta utvecklingen av teamets källkod. Detta skulle betyda att teamet har tillverkat en produkt som överträffat kundens förväntningar och skulle påvisa teamets goda ingenjörkunskaper.

2.4

Tidigare erfarenheter

Teammedlemmarna studerar på civilingenjörsutbilningen inom datateknik eller mjukvaru-teknik på sitt tredje eller fjärde år. Detta innebär att alla projektmedlemmar har goda kunska-per inom programmering och programmeringsrelaterade vetenskakunska-per. Teammedlemmarna besitter å andra sidan liten kunskap inom webbutveckling. Detta kan vara problematiskt då en webbapplikation ska utvecklas av gruppen.

Samtliga medlemmar i teamet har gått projektkurser med liknande stora grupper förut. Detta kan underlätta administrativa och gruppsociala aspekter. Dessutom kan teamet sätta mer realistiska förväntningar på vad som hinner bli klart med dessa erfarenheter.

3

Teori

Detta kapitel beskriver den teori som ligger till grund för rapporten. Kapitlet ämnar ge lä-saren en grundläggande förståelse om ramverk och verktyg som använts i projektet. Dessa verktyg och ramverk relaterar både till arbetssätt och utveckling.

3.1

Systemanatomi

En systemanatomi är en riktad graf som visar ett systems funktionaliteter ur en utvecklares perspektiv. Varje båge i grafen representerar ett beroende, där den nod som pekas på utgör en funktionalitet som måste finnas implementerad innan den pekande nodens funktionalitet kan testas. Syftet med en systemanatomi är att ge en gemensam bild av vad systemet inne-fattar. Den kan vara en bra utgångspunkt vid planering av ett projekt.

3.2

Verktyg och ramverk

I detta avsnitt beskrivs de olika verktyg och ramverk som använts under projektets gång för att utveckla slutprodukten.

3.2.1

Django

Django är ett ramverk som används främst för att utveckla back-end delen av en applikation. Koden skrivs i Python och följer Batteries-included filosofin, vilket innebär att mycket av den funktionalitet som önskas i back-end finns redan inbyggt i Django, som exempelvis autenti-sering, databashantering och HTML templates. Med Batteries-included följer även utförlig och aktuell dokumentation om de olika delarna som finns inbyggt [1]. Django har idag blivit väl-digt populär och har bland annat använts av hemsidor som Instagram, Disqus, Pinterest och Open stack [2].

3.2.2

Vue

För att utveckla front-end delen av applikationen används ramverket Vue som kommer med diverse funktioner för att underlätta utvecklingen. Vue är ett progressivt ramverk [3], vilket betyder att det är designat för att kunna utveckla hemsidor inkrementellt. Detta innebär att

3.3. Adminsitrativa verktyg

det blir lätt att bygga vidare på sina hemsidor. Vues reaktionssystem är ett typiskt exempel på detta. Det kan, medan en applikation körs, märka av när värden inom applikationen ändras och uppdaterar sidan med de nya värdena automatiskt. I många andra ramverk behöver detta göras manuellt. Ramverket delar också upp hemsidorna i komponent-moduler som innehåller kod med både Javascript, HTML och CSS istället för att ha dessa i separata filer. Varje sida behöver då bara koppla ihop komponenter för att bygga upp sitt utseende och sin logik, eftersom varje komponent har sitt eget utseende och sin egen logik.

3.2.3

SQLite

För databashantering användes SQLite. SQLite är ett bibliotek som implementerar en server-lös SQL-databas motor. Det innebär att, till skillnad från de flesta andra SQL-databaser, datan inte skrivs till en separat server, utan skrivs lokalt till en fil på minnet [4].

3.2.4

Google API

Google API används för att komma åt och applicera avancerad funktionalitet i hemsidor som annars hade tagit för lång tid att implementera själv. Detta görs genom att generera en nyckel som kopplas till ett Google-konto och sedan används i koden för att få tillgång till Googles olika API:er. En av dessa är Maps Javascript API som ger tillgång till Googles egna karta som används i Google Maps applikationen och dess relaterade hjälpmedel, som satellitbilder och att kunna sätta ut markörer. En annan är Geolocation API:n som gör det möjligt att använda olika positioneringssystem i t.ex. en telefon eller webbläsare för att ta reda på användarens position. Tillsammans kan en persons position snabbt tas fram och visas på en karta. Utöver detta används Directions API:n för att beräkna avstånd och vägbeskrivningar mellan olika punkter eller olika personer [5].

3.2.5

Websockets

Websockets är ett protokoll för HTML5 som tillåter full duplex kommunikation över en och samma TCP anslutning, till skillnad från HTTP som bygger på ett förfrågan/svar-förfarande mellan klient och server. En websocketanslutning startar som en vanlig HTTP-anslutning, och uppgraderas därefter i en så kallad websockethandskakning. Detta görs genom att en kli-ent skickar en begäran till servern om att få byta protokoll från HTTP till websockets. Det-ta görs via klientens Upgrade header och om servern har stöd för websocketprotokoll skic-kar den tillbaka en bekräftan. När handskakning med framgång har avslutats bryts HTTP-anslutningen ner och ersätt med en websocketanslutning [6].

3.2.6

Visual Studio Code

Visual Studio Code är en applikation för att redigera källkod som har stöd för att integrera en mängd olika verktyg för att anpassa programmet runt sig själv. Den har inget stöd för att kompilera koden, men de olika integrerbara vektygen kan användas för att ge programmet t.ex. en debugger, kodfärgning och kodrättning. Till skillnad från många utvecklingsmiljöer jobbar inte Visual Studio Code i projektform utan låter användaren öppna en eller flera map-par att jobba med. På detta sätt är det enkelt att hantera olika programmeringsspråk samtidigt och valet av språk behöver inte bero lika mycket på hur bra det passar med utvecklingsmil-jön [7].

3.3

Adminsitrativa verktyg

För att lättare organisera projektet har diverse administrativa verktyg använts. Dessa beskrivs i detta avsnitt.

3.3. Adminsitrativa verktyg

3.3.1

Scrum

Scrum är ett ramverk där ett team kan adressera komplexa problem, men samtidigt på ett produktivt och kreativt sätt leverara produkter av högsta kvalitet. Varje Scrum team har en Product Backlog som är en sorterad lista med alla krav på produkten. Inför varje Sprint pla-neras ett par uppgifter. Under sprinten, som är cirka en månad lång, utförs dessa uppgifter. Under sprinten hålls dagliga Scrum möten på 15 minuter. På mötena tar varje teammedlem upp vad de gjort, kommer göra och potentiella problem. Efter varje sprint sker en Sprint Re-view som är en sammafattning på sprinten. Sammanfattningen hjälper teamet att ta fram vad som gick bra och vad som gick dåligt för att förbättras inför nästa sprint [8].

3.3.2

Git

Git är ett versionshanteringsverktyg som primärt används av grupper för att följa föränd-ringar i källkod och förenkla utvecklingsprocessen med att jobba flera personer på samma projekt. Det bygger på ett distribuerat system, vilket innebär att det finns ett huvudarkiv med alla versioner online och att varje person skapar en lokal kopia av någon version. Under utvecklingen uppdateras de lokala filerna kontinuerligt och sedan skickas de till huvudarki-vet för att spara de förändringar som gjorts. Om flera skickar nya versioner samtidigt finns det funktionalitet inbyggt i Git för att slå samman versioner. Det unika med Git är dess sy-stem av grenar som tillåter en att göra flera alternativa versioner av källkoden. Varje Git-arkiv börjar med en stam som utgör originalversionen av källkoden. Det går sedan att skapa helt nya grenar utifrån originalgrenen som kan användas för att jobba med programmet i olika kontexter. Dessa kan slås ihop för att skapa en gren som innehåller funktionalitet från de ti-digare grenarna på samma sätt som två versioner kan slås samman. Ett vanligt arbetsflöde är att ha en gren för en stabil version av programmet, en för testning och sedan flera små för utveckling av mindre funktioner [9].

3.3.3

Gitlab

GitLab är en webbtjänst som ger användarna tillgång till ett Git-arkiv och extra funktionalitet för att jobba med det som ett projekt. Förutom att förse med en plats att lagra sin kod så finns det ett grafiskt gränssnitt för att se hur koden förändrats över tid, både versioner och grenar. För att göra det enklare att driva ett projekt finns det t.ex. möjligheten att skapa mål för projektet och skriva upp problem som måste lösas som sedan kan organiseras med en Kanban-tavla. Det finns även funktionalitet för att enkelt skapa pipelines för kontinuerlig integration av ny kod, samt kontinuerlig utplacering av nya stabila versioner av programmet. De flesta av dessa funktioner går också att reglera så att vissa medlemmar bara har tillgång till vissa funktioner [10].

3.3.4

LaTeX

LaTeX är ett typsättningssystem som används i stor utsträckning vid skrivandet av tekniska dokument och akademiska skrifter. LaTeX skiljer sig mycket från andra ordbehandlare i det att hur ett dokument ska vara designat och dess innehåll är väldigt uppdelat. Författaren får själv specificera i ens text vad som är titel, var nya avsnitt ska vara och i detalj hur allting ska se ut. Detta görs genom att författaren skriver in ren text och sedan använder ett märk-språk för att förklara för kompilatorn som genererar dokumentet hur det ska vara designat, t.ex. skrivs titeln in ett dokument med samma typsnitt som brödtexten, men när den delen av texten markeras som titel kommer kompilatorn formatera det så att det ser ut som en titel när textfilen skapas. LaTeX kommer också med diverse inbyggda funktioner som underlät-tar skrivandet av stora dokument. Bland annat kan det automatiskt generera referenser och automatiskt skapa innehållsförteckningar [11].

3.3. Adminsitrativa verktyg

3.3.5

Overleaf

Overleaf är ett webbaserat redigeringsprogram för att skriva LaTeX dokument. Det går att använda på de flesta webbläsare och kompilerar dokumenten i webbläsaren också så att det snabbt går att se hur de förändras. Det har också stöd för att skapa projekt med flera filer som kan delas med andra användare och även att flera användare jobbar på samma dokument samtidigt [12].

3.3.6

Google Drive

Google Drive är en plattform för att lagra filer och dokument via molnet. Det tillåter använ-dare att spara alla sorters filer, men är främst till för att använda Googles egna verktyg, som Google Docs, Google Sheets och Google Slides, online. Alla filer går också att dela med andra användare och Googles egna tjänster går att använda simultant med andra användare. Detta gör Google Drive till ett snabbt och enkelt verktyg för grupper att både spara och producera dokument.

3.3.7

Google Calendar

Google Calendar är en kalenderapplikation, som kan användas som mobilapplikation eller via internet. I Google Calendar kan gemensamma scheman skapas och delas vilket tillåter smidig schemaläggning för grupper.

3.3.8

Heroku

Heroku är en Platform-as-a-Service (PaaS) och tillåter utvecklare att ladda upp ett projekt till Heroku för att göra den tillgänglig via Internet. Herokus fördel är att den kräver minimal konfigurering och administration för att ladda upp ett projekt, samtidigt som den har stöd för flera programmeringsspråk och tjänster som exempelvis PostgreSQL och Redis [13].

3.3.9

Slack

Slack används som kommunikationsmedium och har många fördelar. Slack består av så kalla-de arbetsplatser som i sig består av en samling kanaler som medlemmarna i arbetsplatsen har tillgång till och kan skriva i. Kanaler används för att sortera samtalen mellan medlemmarna genom att de skapas med ett namn och syfte så att den kanalen används för just konversatio-ner med det syftet. På detta sätt sker inte alla konversatiokonversatio-ner på ett och samma ställe. Utöver att organisera samtal har Slack många integrerbara verktyg som kan användas, t.ex. finns det ett verktyg för enkelt dela Google Drive dokument och ett verktyg för att se och hantera Git-arkiv [14].

4

Metod

Detta kapitel ämnar ge läsaren en insikt i projektets arbetsgång, vilka ansvarsområden varje teammedlem hade och avslutas med att beskriva hur teamet fångade erfarenheter.

4.1

Projektmedlemmar och roller

I detta projekt har varje teammedlem tilldelats minst en specifik roll. Fördelen med att ha en rolluppdelning är att alla inte behöver förkovra sig i allt. Dessutom leder det till att en med-lem naturligt tar upp områden som är relaterade till dess ansvarsområde. Exempelvis om det inte hade funnits någon dokumentansvarig kanske projektteamet hade missat att korrektur-läsa dokument. Tabell 4.1 visar vilka roller som fanns och vem som hade vilken/vilka roller.

Tabell 4.1: Ansvarsområden

Namn Ansvar Beskrivning

Yousef Hashem Teamledare Leder arbetet och har det huvudsakliga an-svaret för att projektet genomförs och uppfyl-ler kraven.

Martin Brolin Analysansvarig Driver kontakten med kunden under projek-tet och ansvarar för att dennes vision förmed-las till teamet.

Elmedin Zildzic Arkitekt Gör de generella tekniska besluten och ansva-rar för att en bra produktarkitektur tas fram. Joakim Tao Dokumentansvarig,

Kvalitetssamordnare

Bedriver den största delen av dokumentkon-troll och kvalitetskontrol. Ansvarar för att projektet uppfyller de kvalitetskrav som satts samt att dokument blir granskade.

Jacob Larsson Utvecklingsledare, Konfigurationsansva-rig

Driver majoriteten av versionshantering-en och organiserar utvecklingsarbetet inom gruppen.

Viktor Blidh Testledare Skriver och designar de flesta övergripande tester och ansvarar för att de genomförs.

4.2. Organisation

4.2

Organisation

Detta avsnitt beskriver hur projektet var organiserat, hur administrationen inom gruppen fungerade och vilka områden de olika personerna inom teamet ansvarade för. Kommunika-tionen från teamet till individer utanför teamet gick främst via analysansvarig och teamleda-ren, se Figur 4.1.

Figur 4.1: Medlemsstruktur

För att inga missförstånd om vilka rättigheter och skyldigheter varje gruppmedlem hade mot gruppen skapades ett genomgående gruppkontrakt och det signerades av alla medlemmar i gruppen. Utöver det följde uppgifts- och ansvarsfördelningen den standarden som satts av kursen. Detta innebär att samarbetet inom gruppen också byggde på att medlemmarna följde sina tilldelade ansvarsområden.

Gruppkontraktet beskrev främst hur kommunikationen inom gruppen skulle ske och hur möten skulle planeras. Kontakten mellan medlemmarna skulle enligt gruppkontraktet ske främst via Slack. Kontakt via Facebooks Messenger existerade för snabba informella samtal men skulle undvikas om möjligt. Kontraktet specificerade också att kallelse till möten skulle ske av teamledaren minst 48 timmar innan för att det skulle gälla, annars om det var med kortare varsel behövde en majoritet godkänna för att mötet skulle vara ett giltigt. Utöver detta fanns det en viss skyldighet att vara i tid till mötena.

4.3

Utvecklingsmetodik

Olika verktyg användes för olika syften. I detta avsnitt förklaras och beskrivs vilka verktyg och metoder teamet har använt.

4.3.1

Arbetssätt

Projektet utfördes med hjälp av Scrum. Scrum är ett agilt ramverk där grupper kan jobba med adaptiva projekt samtidigt som konkreta produkter kan levereras kontinuerligt. Arbetet skedde till en början gemensamt i största möjliga grad, eftersom mycket av arbetet var svårt

4.3. Utvecklingsmetodik

att dela upp för specifika roller. Efter att projektet kommit igång var parprogrammering den föredragna arbetsmetoden, men det programmerades också individuellt. Gruppen försökte främst träffas under vardagarna på schemalagd tid för att jobba tillsammans så att alla kunde få hjälp och idéer från varandra. Annars arbetades det också på annan tid hemifrån eller på universitetet.

Varje vecka, förutom under tentaperioder, hade teamet två gruppmöten. Ett av veckomö-tena var på onsdagar, där teamet gick igenom hur arbetet gått den innevarande veckan. Det andra veckomötet var på fredagar, där diskuterade teamet vad som hade gått bra och vad som har gått mindre bra under veckan som varit, samt diskuterade och planerade vad som skulle göras veckan efter. Planeringen utgick efter teamets interna milstolpar för att se till att arbetet skedde i rätt takt.

Utöver dessa gruppmöten gjordes kallelser till gruppmöten ifall någon teammedlem kän-de att kän-det fanns ett behov för ett gruppmöte. Varje vecka, förutom unkän-der tentaperiokän-der, ha-de teamet också ett möte med handledaren. På handledarmötet kunha-de allmänna frågor som teamet hade ställas. Handledarmötena agerade även som tillfällen för återkoppling efter pre-sentationer och dylikt. Ungefär varannan vecka hade teamet ett möte med kunden, där en statusuppdatering gavs till kunden, samt en kort genomgång på vad teamet hade åstadkom-mit sedan senaste mötet med kunden.

Tiden team-medlemmarna har lagt ner loggades regelbundet i ett exceldokument. Tiderna loggades i 2-timmars intervall, med starttid och sluttid, samt vem och vad individen hade arbetat med under den tidsintervallen. En veckorapport skapades sedan, där alla tider för veckan summerades till en totalt arbetat tid under veckan, en tid per individ, samt en tid för hela teamet under veckan. Veckorapporten skickades sedan in till teamets handledare varje vecka.

4.3.1.1 Iterationer

Projektet delades upp i fyra iterationer, där iterationerna varade mellan två och tre veckor. Dessa iterationer fungerade som sprintar i vår Scrumversion. Den första iterationen utgjorde förstudie under vilken gruppen skrev kontrakt med kunden, samt undersökte hur projek-tet på bästa sätt skulle utföras. Inför varje sprint satte gruppen upp ett antal milstolpar som skulle vara klara vid sprintens slut. Därefter bestämdes vilka teammedlemmar som skulle arbeta på vilka milstolpar. Detta gjordes med hjälp av Gitlabs issue-board, där teammedlem-mar tilldelades arbetsuppgifter. Via denna issue-board kunde också nya arbetstilldelningar göras under sprintens gång när en milstolpe hade uppnåtts. Tabell 4.2 visar de milstolpar som gruppen bestämde för varje iteration.

Tabell 4.2: Milstolpar för de olika iterationerna

Iteration Milstolpe Milstolpe Milstolpe

1 Skriva kontrakt med kund

Färdigställa dokument Bestämma arbetssätt för projektet

2 Inloggnings-funktionalitet

Visa karta efter inlogg-ning

Färdigställa dokument 3 Registrering av nya

konton

Mobil - och Lednings-centralsläge

Visa andra användare på karta

4 Vägbeskrivning Larm med info Logga tidigare positio-ner

4.3.2

Kommunikation

För att kunna hålla kontakt mellan gruppmedlemmarna utöver mötena under veckan använ-des främst Slack. Slack använanvän-des bland annat för att boka nya möten med gruppen och

ko-4.3. Utvecklingsmetodik

ordinera arbetsfördelningen. I Slack användes olika kanaler för olika ämnen, bland annat en kanal där endast mötena bokas och en för snabb kommunikation med handledaren. Utöver Slack skedde en del kommunikation via e-post. Detta var till personer som var intresserade av projektet som ej tillhörde den primära arbetsgruppen, exempelvis kursansvarig och kund.

4.3.3

Utbildning

Kunskapen om de olika verktyg som skulle användas var inom teamet väldigt blandad till en början. Därför behövde viss utbildning ske under projektets gång. Framförallt skedde ut-bildning genom läsning av dokumentation för de ramverk som användes och av guider för verktygen som skulle användas. Eftersom alla i gruppen hade mycket erfarenhet av program-mering sedan tidigare räckte det oftast med att skapa sig en ungefärlig uppfattning av hur ett ramverk eller verktyg fungerade för att kunna börja använda det. I vissa fall hade en grupp-medlem tidigare kunskaper inom ett område och då kunde den personen hålla workshops med resten av gruppen för att lära de andra. Detta var uppskattat för då kunde alla lära sig tillsammans, vilket gick fortare, och alla kunde ställa frågor ifall det behövdes. Framförallt skedde utbildning inom områdena Django, Vue, JavaScript och Git.

Eftersom beslutet att göra en webbaserad applikation togs en bit in i förstudien bestämdes det att extra tid skulle behöva läggas på förstudien. Både för att gruppens kunskap inom webbprogrammering var begränsad och för att beslutet gjorde att mycket av det som hade studerats innan det beslutet togs blev onödigt.

4.3.4

Versionshantering

För att underlätta utvecklingsflödet användes GitLab som verktyg för versionshantering ef-tersom alla projektmedlemmar har erfarenhet av det tidigare och att universitet förser med studentkonton. Arbetsflödet som användes för versionshanteringen var Feature Branching som bygger på att utvecklingen av ny funktionalitet sker på grenar separata från huvudgre-nen och inkorporeras i huvudgrehuvudgre-nen när funktiohuvudgre-nen är stabil. Feature Branching, tillsammans med ett CI-skript som testar huvudgrenen när ny kod sammanfogas, ser till så att huvudgre-nen alltid är stabil. Detta underlättar testning samt när olika personer utvecklar olika delar av systemet simultant. CI-skriptet exekveras varje gång en commit sker på huvudgrenen och den kör igång hela applikationen och ser till så att den kan köras stabilt. Om något går fel, som att Vue kraschar när projektet initialiseras, kommer den senaste commiten att markeras som instabil.

4.3.5

Testning

För att kontrollera att systemet fungerar som förväntat utfördes tester kontinuerligt under projektets gång. Testerna beskrevs i en testplan som utöver testerna också innehöll infor-mation om hur testningen skulle gå till och vilka kriterier som fanns för en framgångsrik testning.

4.3.6

Kvalitetsutveckling

För att se till att teamet producerade kvalitativa dokument och system skrevs en kvalitets-plan. I kvalitetsplanen utformades metoder för hur teamet kunde identifiera områden där kvalitén var låg och behövde förbättras. En metod som beskrevs var att undersöka vilka krav som är uppfyllda i kravspecifikationen som kunden och teamet har kommit överens om. Ett annat sätt att mäta kvalitet var att undersöka om systemet klarar testerna beskrivna i testpla-nen. För att hantera kvalitetsbristerna diskuterades olika lösningsförslag inom gruppen, och den lösning som teamet ansåg vara bäst valdes.

Kvalitetsplanen beskrev också ett arbetssätt som undviker arbete som producerar dålig kvalitet så som dokument- och kodgranskningsprocesser. Dokumentgranskningsprocessen

4.4. Dokumentation

Tabell 4.3: Risker

Risk Sannolikhet Konsekvens Produkt Åtgärd

En deadline för en inläm-ning missas.

2 3 6 Kontakta

handle-daren. En av teammedlemmarna

plockas bort från teamet av kursledningen.

2 3 6 Planera om

projek-tet med kursledare. Medlemmarnas brist på

erfarenhet inom webbut-veckling kan leda till en dålig arkitektur.

3 3 9 Planera mer tid på

utbildning.

såg till att dokumenten som skrevs i projektet genomgick genomläsningar så att de inne-höll rätt rubriker och inga språkliga fel. Kodgranskningar såg till att kod skriven i projektet genomgick granskningar för att försäkra att de innehöll korrekta kodkonventioner, korrekt indentering samt följde teamets interna programmeringspraxis.

4.3.7

Riskanalys

I samband med att projektplanen skrevs utfördes en riskplanering. Denna planering handla-de om att kunna förstå risker och hantera handla-dessa om handla-de inträffar. Riskerna grahandla-derahandla-des mellan 1 och 5 i hur sannolika de var att inträffa och hur stora de negativa konsekvenserna skulle bli för projektet. Produkten av dessa värden visade hur mycket risken påverkade projektet. I Tabell 4.3 visas de huvudsakliga riskerna för projektet.

4.4

Dokumentation

Under projektets gång skrevs flera dokument, majoriteten av dessa skrevs i LaTeX med hjälp av Overleaf. Overleaf låter flera gruppmedlemmar redigera dokument samtidigt. Mindre do-kument som tidsrapporter och mötesprotokoll skrevs i Google Docs inuti en gemensam mapp i Google Drive. Andra dokument som guider och standarder hittade på nätet lagrades också i den gemensamma mappen på Google Drive. De projektrelaterade dokumenten som skrivits under projektets gång redovisas i Tabell 4.4.

4.5

Metod för att fånga erfarenheter

En metod för att fånga erfarenheter var mötena som hölls i slutet av varje vecka. Dessa möten handlade om att varje person beskrev hur arbetet hade gått och vad den personen kunde ta med sig. Det handlade inte bara om individuell reflektion utan om vad för erfarenheter hela gruppen kunde ta med sig från varje individ.

Liknande möten hölls i slutet av varje sprint. Då gjordes mer utförliga och mer tekniska reflektioner. Under mötet, som hade en mer professionell stämning, utvärderades arbetet som utförts under sprinten och reflektioner gjordes kring arbetsbörda samt tekniska framgångar.

4.5. Metod för att fånga erfarenheter

Tabell 4.4: Dokument som skrivits

Dokument Beskrivning

Arkitekturplan Beskriver systemets arkitekturbeslut och olika typer av UML-diagram.

Kvalitetsplan Beskriver hur projektet kan förbättra kvaliteten och arbetssätt som ser till att arbetet är kvalitativt. Projektplan Beskriver projektets planering, teamets arbetssätt

och grundläggande systembeskrivningar.

Testplan Beskriver hur kod ska testas och hur tester är utfor-made.

Kravspecifikation Beskriver de kraven kunden och teamet har kommit överens om på den färdigställda produkten. Statusrapporter Skrivs en för varje iteration. Beskriver hur arbetet

gått, hur teamet ligger till i planering och hur teamet planerar på att arbeta kommande iteration.

5

Resultat

I detta kapitel redovisas det resultat som uppnåtts. I resultatet ingår en förklaring av syste-mets uppbyggnad och hur de ramverk som beskrivits i Kapitel 3 använts för att nå resultatet. Därefter summeras gruppens gemensamma erfarenheter. Avslutningsvis ges en översikt av de individuella bidragen.

5.1

Systembeskrivning

För att gruppen skulle vara säkra på att produkten skulle innehålla det som eftersträvades och ha god kvalitet togs tid i början av projektet till att göra en genomgående systemdesign, bestående av två systemanatomier, innan arbetet med applikationen påbörjades. Systemet som byggts under projektets gång är en webbapplikation som delar och visar andra klienters positioner på en karta, samt möjliggör kommunikation mellan dessa. I applikationen finns det två lägen, ett läge för Ledningscentralen och ett läge för den operativa polisen. Läget för Ledningscentralen har tillgång till alla GPS-positioner hos alla klienter och kan distribuera meddelanden och larm till de operativa poliserna. Läget för operativa polisen har inte tillgång till att skicka ut larm, men kan be om förstärkning om det behövs.

5.1.1

Systemanatomi

Två systemanatomier gjordes för systemet, en för Mobilläget i webbapplikationen, och en för Ledningcentralsläget. Se Figur 5.1 och Figur 5.2 för respektive systemanatomi.

5.1. Systembeskrivning

5.1. Systembeskrivning

5.1. Systembeskrivning

5.1.2

Klient-Server arkitektur

Till följd av att programmet som utvecklats är en webbapplikation var det naturligt att följa en Klient-Server arkitektur enligt Figur 5.3.

Figur 5.3: Klient-Server arkitektur

Servern bestod utav en front-end del och en back-end del. Dessa är frikopplade i och med att de olika delarna körs på två olika serverprocesser, men på samma system. Klienten hämtar alltså front-end delen från front-end serverprocessen och exekverar koden i en webbläsare. Därifrån börjar klienten kommunicera med back-end delen för att logga in och sedan intera-gera med systemet samt använda Googles API.

För att göra applikationen smidigare att använda – förutsatt att klienten använder sig av relativt modern hårdvara – har systemet utvecklas i stil med en Fat client – thin server arkitektur, vilket i praktiken betyder att klienten kommer att utföra de flesta beräkningarna och exekvera det mesta av koden.

5.1.3

Front-end

Front-end-delen av webbapplikationen är skriven i ramverket Vue.js som används, tillsam-mans med språket Javascript, för att bygga dynamiska hemsidor. I front-end ligger allt av det som användaren själv ser och interagerar med, som exempelvis kartan som visar positio-nerna och diverse knappar. Det första som användaren möts av när hemsidan öppnas är en inloggningssida, se Figur 5.4, som uppmanar användaren att logga in på ett befintligt konto eller skapa ett nytt konto. När användaren skapar ett nytt konto behöver det, förutom inlogg-ningsuppgifter, tilldelas ett namn och en patrullgrupp som visas på sin markör på kartan så att andra användare kan identifiera en. Front-end kommunicerar med back-end och kontrol-lerar de användaruppgifter som försetts och skapar sedan ett nytt konto i databasen och som därefter kan användas för att logga in. Figur 5.5 visar hur sidan där en användare skapar ett konto ser ut. När en användare loggar in hamnar hen antingen i Ledningcentralsläget eller Mobilläget, beroende på vilket konto som loggats in på.

5.1. Systembeskrivning

Figur 5.4: Inloggningssida

Figur 5.5: Sida för att skapa nya användare

Kartan som visar alla polisers olika positioner är skriven med hjälp av Google Maps API och Google Geolocation API. Vi använder dessa för att skapa en karta, som innehåller all funktio-nalitet som kan hittas i den vanliga Google Maps applikationen och för att räkna ut klientens egna position som sedan visualiseras på kartan. Sidan med kartan tar även emot positioner från andra användare och visualiserar dessa på kartan så att användaren kan se sina kollegor. Som tidigare nämnts har varje användare i Mobilläget ett namn och en patrullgrupp, dessa visas på kartan genom att personer i användarens egna grupp ses som röda markörer och personer i andra grupper är blå. Namnet kan ses vid varje markör.

Operativa poliser använder applikationen i Mobilläget. Genom att hålla in den översta knappen som det står Förstärkning på i tre sekunder kommer ett förstärkningslarm aktiveras som ska signalera till kollegorna att en person behöver förstärkning. Detta sker genom att ikonen för personen förändras till en skylt med ett utropstecken, se Figur 5.6. Detta tecken studsar även på kartan. När användaren ber om förstärkning distribueras det ut till alla andra

5.1. Systembeskrivning

klienter som är inloggade på systemet så att alla kan se att personen behöver hjälp. I Figur 5.8 syns en polis som ber om förstärkning sett från Ledningcentralsläget.

Figur 5.6: Mobilläge

5.1. Systembeskrivning

Figur 5.8: Ledningcentralsläget där en användare i Mobilläget ber om förstärkning

En användare på Ledningcentralsläget kan använda en funktion för att skicka ut larm på en position till användare som är operativa poliser. Det görs genom att klicka på knappen som säger Larma, se Figur 5.7, och sedan klicka på en position på kartan för att skicka larmet till just den platsen. Det går sedan att skriva mer användbar information om larmet, se Figur 5.9. De användare som är operativa poliser ser då att det kommit in ett larm och en markör place-ras på positionen som det larmats till, samt ytterligare information om larmet som en ruta vid markören. För att polisen snabbt ska kunna se hur hen ska ta sig till platsen så kan en vägbe-skrivning från den nuvarande positionen till larmpositionen ges. Denna vägbevägbe-skrivning kan avslutas via menyknappen Avsluta vägbeskrivning, se Figur 5.10. Dessutom kan kartan centre-ras på en annan aktiv användare via knapparna som dyker upp om knappen Aktiva poliser trycks, se Figur 5.11. De aktiva användarna sorteras efter avstånd till personen själv. När ett larm är slutfört av en polis visas hur lång tid som gått från att larmet skapades till att en polis kom fram till platsen. Detta illustreras i Figur 5.12.

5.1. Systembeskrivning

Figur 5.10: Larmfunktionalitet i Mobilläget

5.1. Systembeskrivning

Figur 5.12: Responstiden för ett larm

5.1.4

Back-end

Back-end är skrivet i ramverket Django och fungerar bland annat som ett gränssnitt mot databasen. Back-end används också till att sköta websocket anslutningar från användare på front-end sidan. När en klient uppdaterar sin position skickas de nya GPS-koordinaterna till servern. Det ligger sedan på servern att skicka klientens nya koordinater till alla andra klienter som är anslutna. Då ett större antal poliser ska kunna använda systemet samtidigt kommer mycket data att skickas mellan klienter och servern. Med hjälp av websockets hålls en anslutning mellan servern och varje klient öppen så länge klienten är inloggad på syste-met. På så sätt undviks en TCP handskakning varje gång data skickas. Detta minskar overhead drastiskt och illustreras i Figur 5.13. Back-end sparar aldrig GPS information om alla använ-dare, det sparas istället på front-end sidan för att vidare minska overhead i back-end. Det enda som sparas ner är användaruppgifter, samt eventuell loggning av GPS-positioner som kan användas för att granska situationer som uppstått i samband med larm. Som resultat av det-ta fanns det aldrig heller ett behov av att använda en stor och komplex dadet-tabashantering, det räckte med SQLite.

5.1.4.1 Django Channels

Django har inget eget stöd för websockets, utan används främst för att hantera HTTP begä-ran. För att lösa detta problem behövdes Django Channels. Django Channels utökar Django genom att lägga till stöd för websockets. Andra fördelar med Django Channels är att den tillå-ter flera websocket anslutningar kommunicera med varandra, vilket har varit till stor fördel för detta projekt eftersom att klienterna som är anslutna måste kunna kommunciera GPS-positioner till varandra.

5.1.4.2 Databas

Databasen som använts för projektet är SQLite. Som nämnts fanns det aldrig något krav på en större databashanterare, SQLite räckte med tanke på att projektet är ett konceptbevis. Trots att databashanteraren använder sig av SQL fanns det aldrig behov av att interagera med da-tabasen i det språket. Django använder sig istället av Object-Relational Mapping (ORM), vilket tillåter programmeraren att skriva förfrågningar till databasen i Python-kod. Fördelen med detta är att det underlättar för teamet att skriva och hämta uppgifter till och från databasen,

5.1. Systembeskrivning

Figur 5.13: Översikt av hur servern distribuerar data till klienterna

eftersom att alla inte har kunskaper inom SQL. Utöver detta erbjuder Django också en HTML sida riktad mot administratörer, som kan användas för att redigera användaruppgifter och dylikt. Denna sida går att se i Figur 5.14.

Figur 5.14: Djangos administrationssida

5.1.5

Heroku

För att kunna testa ett scenario för kunden där användarna befinner sig på långa distanser och måste ta sig till en larmposition, krävdes det att användarna kunde koppla sig till servern via Internet. Scenariot gick ut på att se ifall användarnas position uppdaterades i realtid för

5.2. Värde för kunden

alla involverade, samt att se ifall en användare kunde ta sig till en larmposition med hjälp av vägbeskrivning. Problemet var att användarna inte kunde koppla sig till servern med en lokal server, eftersom denna går inte att nå via Internet. Istället behövdes en publik server som användarna kunde hitta med sin webbläsare. Lösningen på detta var Heroku.

Heroku har dock vissa begränsningar, exempelvis att processer inte kan bindas till egna portar, utan bara till en som Heroku förser med. På grund av detta krävdes två olika Heroku projekt, ett för front-end och ett för back-end, vilket är suboptimalt eftersom att det avslöjar back-end till Internet och förutsätter den för flera risker för attack. Eftersom att säkerhet in-te var ett bekymmer för detta projekin-tet bedömdes denna lösning tillräcklig, och gjorde det möjligt att testa scenariot enligt ovan.

5.2

Värde för kunden

Projektet har haft som mål att skapa en produkt som ska agera som konceptbevis för NFC att möjligen vidareutveckla konceptet och kanske till och med göra det till ett verktyg som polisen använder i sin vardag. Produkten har därför utvecklats till att vara så lik en slutpro-dukt som möjligt genom att programmera med en slutanvändare i åtanke. Detta går framför allt se i den designen som valts för användargränsnittet som är enkel och minimalistisk så att applikationen kan användas intuitivt och snabbt av de operativa poliserna när de är ute i fält. Samtidigt ska det finnas tillräckligt mycket funktionalitet för att applikationen ska vara användbar. Värdet hos kunden ligger alltså i att få en inblick i hur den tänkta slutprodukten skulle kunna se ut och ifall detta är något NFC, och polismyndigheten i allmänhet, vill lägga resurser på för att vidareutveckla.

5.3

Gemensamma erfarenheter

Samtliga gruppmedlemmar hade tidigare erfarenhet av grupparbeten inom IT-utveckling, men inte av denna storlek. Det var en unik erfarenhet för gruppmedlemmarna att ha möte med kunden och komma överens om vilka krav som skulle uppfyllas vid slutet av arbetet. Det krävde många möten med kunden, många möten med gruppen och mycket studerande för att kunna överväga vad som är genomförbart, vad som kunden vill ha, och vad projekt-medlemmarna var villiga att prioritera. Detta arbetssätt krävde att projektets medlemmar var öppna och tänkte på ett sätt som skiljer sig från hur universitets programmeringskurser är upplagda. Programmeringskurserna fokuserar sig på att hitta det rätta utvecklingssättet, där en tydlig indelning finns mellan vad som är rätt och fel. I detta projekt handlade det om att hitta många utvecklingssätt och komma fram till ett sätt som är lämpligt för både kund och projektmedlemmar, som exempelvis balansen mellan att utveckla nya funktioner eller att förfina de som redan finns.

Medlemmarna hade lite erfarenhet inom dokument relaterade till IT-projekt från tidigare kurser. Det gjorde initialt att dokumentskrivandet underlättades. Dokumenten som publice-rades senare under projektets gång hade projektgruppen inte samma erfarenhet av såsom testrapporterna och kandidatrapporten. Detta ledde till att det tog längre tid att skriva dem, eftersom dokumentens struktur och innehåll var okända till en början.

I projektet var det fem studenter från datateknik och en student från mjukvaruteknik, vil-ket innebar att medlemmarna hade mycvil-ket erfarenhet inom programmering. Däremot hade ingen projektmedlem erfarenheter inom webbutveckling, en bristande gemensam erfarenhet som var en av projektets största risker. Detta var en av de största utmaningarna för projekt-gruppen och mycket tid lades ner i form av utbildning till webbutveckling. JavaScript var programmeringsspråket projektgruppen använde sig för att programmera front-end, denna del kom att behöva mycket resurser. För att lära sig JavaScript använde sig gruppen främst av webbaserat material så som guider och videos. Det fungerade bra, men gjorde att gruppmed-lemmarnas kunskap om JavaScript varierade eftersom alla valde att lära sig själva. Back-end

5.4. Individuella bidrag

skrevs med programmeringsspråket Python, ett språk samtliga medlemmar hade erfarenhet av att använda, vilket underlättade utvecklandet av back-end.

5.4

Individuella bidrag

Denna del ger en överblick av de individuella bidragen i denna rapport.

5.4.1

Jämförelse av Vue.js och Angular/AngularJS för nybörjare av Yousef

Hashem

En övervägning som gjordes i detta projekt var vilket ramverk som skulle användas till ut-vecklingen av applikationen. Detta var ett svårt val då ingen i teamet hade mycket erfaren-het av webbutveckling sedan tidigare. Denna litteraturstudie jämför hur lämpade två av de övervägda ramverken är för nybörjare. Dessutom studeras vilka fördelar det finns, rent funk-tionsmässigt, att välja det ena ramverket över det andra.

5.4.2

Jämförelse mellan mobilapplikationer och webbapplikationer av Martin

Brolin

En annan övervägning i detta projekt var om applikationen som var menad för mobilanvän-dare skulle programmeras som en mobilapplikation eller webbapplikation. Denna rapport studerar vilka för- och nackdelar mellan besluten och i vilka situationer som besluten är lämpliga. Sedan beskrivs hur beslutet att utveckla enbart en webbapplikation för mobilan-vändarna var kunde vara bra och dåligt.

5.4.3

Man-in-the-middle attack i HTTPS av Elmedin Zildzic

Till följd av att Google vill göra Internet till en säkrare plats har de valt att markera webb-platser som inte använder sig av HTTPS som osäkra, samt göra deras API:er otillgängliga för vanliga HTTP hemsidor. Eftersom att projektet använt sig av Google Maps har det behövts implementeras HTTPS i webbapplikationen. Att en webbapplikation implementerar HTTPS betyder dock inte att den automatiskt är säker, vilket många användare tar för givet. Det räc-ker med att en användare accepterar ett ogiltigt HTTPS certifikat för att en man-in-the-middle ska kunna avlyssna kommunikationen mellan användaren och servern. Denna studie reder ut vad man-in-the-middle attacker är för något och hur det drabbar användare på klientsi-dan, samt hur de kan skydda sig och vad som kan implementeras i webbapplikationen för att skydda den mot man-in-the-middle.

5.4.4

Jämförelser av Google Map API med andra API av Joakim Tao

Projektet använde sig mycket av karläggnings funktioner och Google Maps API valdes för sitt kända namn. Detta är en litteratur studie som jämför av Google Map API med andra API. Jämförelsen tar upp användarvänlighet, pris samt för- och nackelar med de olika API:na och ställer de emot varandra för att se om valet var rätt.

5.4.5

Dynamisk typning i JavaScript – en typisk undersökning av Jacob Larsson

Olika programmeringsspråk har olika system för att hantera datatyper och just Javascript använder ett dynamiskt system för detta. I denna typiska undersökning görs ett djupdyk in i typsystemens värld för att ta reda på hur Javascripts typsystem har påverkat detta projekt och vilka positiva delar de i allmänhet har.

5.4. Individuella bidrag

5.4.6

En webbapplikations sårbarhet mot CSRF-attacker av Viktor Blidh

Vid utveckling av en webbapplikation finns det många säkerhetsaspekter som en utvecklare måste ha i åtanke. Misslyckande att täcka någon av dessa aspekter riskerar att göra applika-tionen sårbar mot vissa former av attacker. En sådan sårbarhet är Cross Site Request Forgery, CSRF. Denna studie gör en kortare undersökning av vad detta är och hur sårbarhet till CSRF undviks. Dessutom analyseras detta projekts webbapplikation för att se om den uppvisar någon sårbarhet mot CSRF.