Linköpings universitetSE–581 83 Linköping013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik och Mjukvaruteknik

19 | LIU-IDA/LITH-EX-G--19/011--SE

Utveckling av Mobilapplikationför Rörelseanalys med Kaskad-klassificerareDevelopment of aMobile Application forMotionAnalysiswith Ca-scade Classifiers

Alexander AnderssonAlexander BasaAndreas LindsténMarkus LoborgAnton Orö

Handledare : Aron GoschExaminator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning.Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannensmedgivande. För att garantera äktheten, säkerheten ochtillgängligheten finns lösningar av teknisk och administrativ art.Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning somgod 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 upphovsman-nens litterära eller konstnärliga anseende eller egenart.För ytterligare information om Linköping University Electronic Press se förlagets hemsidahttp://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for aperiod 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 down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercialresearch 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 publisherhas taken technical and administrative measures to assure authenticity, security and accessibility.According to intellectual property law the author has the right to bementionedwhen his/her workis accessed as described above and to be protected against infringement.For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page:http://www.ep.liu.se/.

©Alexander AnderssonAlexander BasaAndreas LindsténMarkus LoborgAnton Orö

Sammanfattning

Denna rapport behandlar projektarbetet som utfördes av fem studenter inom datateknikoch mjukvaruteknik vid Linköpings Universitet. Projektarbetet utfördes som en del av kur-sen TDDD96 Kandidatprojekt i mjukvaruutveckling under vårterminen 2019. Syftet medrapporten är att utvärdera arbetsgången för framtagningen av en produkt. Projektet be-handlar implementering av bildanalys för mobila Android-enheter och har gjorts på upp-drag av Image Systems Nordic AB. Applikationens ändamål var att genom kameran påen mobiltelefon kunna spåra objekt och analysera dess positioner. Resultatet av projektar-betet är applikationen TrackApp som genom maskininlärning kunde spåra objekt i realtidoch på video. Utöver produkten bearbetar rapporten hur projektgruppen arbetade samtindividuella fördjupningsområden gruppmedlemmarna studerat.

Författarens tack

Vårt kandidatarbetet hade inte varit möjligt att utföra utan uppdraget från vår kund ImageSystems Nordic AB och vi vill tacka dem för ett varmt bemötande och möjligheten att jobbamed en spännande teknik, ett speciellt tack vill vi även ge till Tomas Chevalier och FredrikRudbeck. Vi vill även rikta ett stort tack till vår kursledare Kristian Sandahl och handledareAron Gosch som stöttat oss under projektets gång särskilt när vi tappade två teammedlem-mar.

iv

Innehåll

Sammanfattning iii

Författarens tack iv

Innehåll v

Figurer viii

Tabeller x

Definitioner xi

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

2 Bakgrund 32.1 Beställaren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Tidigare Erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Teori 53.1 Metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Bildanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Metod 94.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Iterationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.5 Testning och kvalitetssäkring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Samarbete med kund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.7 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.8 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Resultat 165.1 Dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Logotyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Bildanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.4 Användargränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

v

5.6 Grafritning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.7 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.8 Sammanfattning av individuella delar . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Diskussion 256.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Vidareutvecklingspotential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.5 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Slutsatser 317.1 Går det att implementera objektspårning i en mobilapplikation? . . . . . . . . . 317.2 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 317.3 Vilka erfarenheter kan dokumenteras från programvaruprojektet, som kan va-

ra intressanta för framtida projekt? . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4 Hur kan applikationen implementeras så att man skapar värde för kunden? . . 32

A Alexander Andersson: 3D-Rekonstruktion, en Kortare Abstraktion 33A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36A.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

B Alexander Basa: Hantering av Icke-Funktionella Krav i Mjukvaruutveckling 40B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42B.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44B.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

C Andreas Lindstén: Attitydundersökning av Allmänhetens Inställning till Dator-seende Kamerabevakning 46C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46C.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47C.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47C.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48C.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49C.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52C.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

D Markus Loborg: För och Nackdelar med Automatisk Testning i Git 57D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58D.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58D.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58D.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59D.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60D.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

vi

E Anton Orö: En Jämförelse av Olika Klassificerare i OpenCVs Bibliotek 62E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

F Frågeformulär 69

Litteratur 72

vii

Figurer

3.1 Exempelbild på gruppens Trelloboard. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Översikt över arbetsflödet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Skiss av navigeringen för TrackApp. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1 Systemanatomin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Logotypen för projektet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Skärmbilder av applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 Skärmbilder av applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1 Visualisering av djup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 Sustainability Analysis Diagram för TrackApp . . . . . . . . . . . . . . . . . . . . . 30

A.1 Nattvarden, Perspektivlinjer och horisonten är markerade i blått [Nattvarden]. . . 34A.2 Illustration av projektion av ett kartesiskt system.Blå linje - andragradsekvation,

röd linje - hyperbel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.3 Camera Obscura (Nålhålskamera - egenskapad bild). . . . . . . . . . . . . . . . . . 36A.4 Illustration av Epipolär geometri [EpipolarPicture]. . . . . . . . . . . . . . . . . . . 37

B.1 Processen för framtagning av relevanta artiklar . . . . . . . . . . . . . . . . . . . . . 42

C.1 Inställning till övervakningskameror på allmän plats. . . . . . . . . . . . . . . . . . 50C.2 Inställning till att byta ut traditionella mot datorseende övervakningskameror. . . 50C.3 Inkräktar övervakningskameror på den personliga integriteten? . . . . . . . . . . . 50C.4 Allmänhetens åsikt kring övervakningskamerors brottsförebyggande effekt. . . . . 51C.5 Allmänhetens åsikt kring övervakningskamerors användbarahet för att upptäcka

pågående brott. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.6 Allmänhetens åsikt kring ifall deras integritet kränks om polisen själva tillåts be-

sluta om sitt behov av datorseende övervakningskameror. . . . . . . . . . . . . . . 51C.7 Allmänhetens åsikt för vilken åtgärd som är mest avgörande för att behovet av

integritet säkerställs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52C.8 Inställning till att sätta upp fler traditionella övervakningskameror. . . . . . . . . . 53C.9 Allmänhetens åsikt kring att traditionella övervakningskameror är användbara

föra att klara upp brott. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

E.1 Haar-kännetecken rektanglar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64E.2 Resultatet av summerad area tableux . . . . . . . . . . . . . . . . . . . . . . . . . . . 65E.3 Kaskadklassificerare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65E.4 Kaskadklassificerare träningsdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

F.1 Frågeformulärets inledning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69F.2 Fråga 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69F.3 Fråga 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

viii

F.4 Fråga 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70F.5 Fråga 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70F.6 Fråga 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71F.7 Fråga 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71F.8 Fråga 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

ix

Tabeller

B.1 Identifierade problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

E.1 LBP-metoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67E.2 Haar-metoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

x

Definitioner

• Bitcode Likt maskinkod exekveras Javas kod genom i ett liknande format kallat bitcode.

• Bitmap Format för lagring av bilder. En matris innehåller information om färgkoder förvarje enskild pixel.

• Commit En commit är när en utvecklare skapar en "återställningspunkt" på en gren somgit känner igen. Denna punkt sparas undan med ett specifikt ID som kan användas se-nare för att få tag på "återställningspunkten". Detta görs bland annat om man vill granskahur det såg ut vid det tillfället. Oftast används det dock för att antingen felsöka pro-grammet genom att gå igenom commit för commit för att se vart felet dök upp ellerför att återställa programmet till en tidigare version för att någonting gick fel i senareversioner och det var enklare att börja om än att leta reda på och fixa felet.

• Frame För en video eller rörlig bild är en frame en bild i denna sekvens.

• GPU Grafik processor (Graphics Processing Unit) är en optimerad enhet för grafikrela-terade beräkningar.

• Gren En gren är en sak som Git använder för att dela upp kod. När man använderGit skapas automatiskt en Master-gren. Sedan är det upp till utveklarna eller personensom är ansvarig för Git att bestämma om fler grenar ska skapas. Grenar används föratt man ska kunna modifera koden utan att påverka funktionaliteten av programmet.Ofta finns det minst tre grenar Nämligen mastergrenen, en utvecklingsgren och en grenför den senaste släppta versionen av kod. Dessa grenar brukar ofta existera under helaprojektets gång medan mindre grenar ofta skapas för att lösa problem(buggar), skapanya funktioner(features) och testa ny kod.

• IDE IDE står för Integrated Development Environment och är en miljö som underlättarutvecklandet. Oftast är det ett program som ger stöd för kodning på något sätt.

• Gradle Gradle är ett byggsystem som Android använder för att bygga sina projekt.Det betyder att när man startar ett android projekt från IDE:n så startas egentligen ettGradle-program. Detta program bygger ihop applikationen och installerar den på emu-latorn eller telefonen.

• Layer Androidens grafiska användargränssnitt byggs på lager, så kallade layers.

• Merge En merge är när man slår ihop kod från en gren med kod från en annan gren.Konflikter kan uppstå när man försöker kombinera koden. I det tidigare fallet föreslårversionshanteringsverktyget att man löser dessa konflikter och är ofta tvungen att göranågra ändringar för att kunna köra koden men tekniskt sett är det inte tvunget. Gör mandock en merge där man med flit försöker kombinera två grenar måste alla konflikterlösas innan man kan gå vidare. Självfallet finns det sätt att gå runt detta krav men detär oftast kontraproduktivt att använda dessa.

• Native code Kod som kompileras direkt till maskinkod.

xi

• Pull En pull är när en utvecklare hämtar ner alla ändringar som har gjorts på nuvarandegren. En pull kan enbart misslyckas då en av följande kriterier är uppfyllda

– Man har inte rättigheter att hämta informationen

– Man har inte internet-tillgång

– Det är något problem med den centrala servern där informationen ligger

– Vissa filer har modifierats och kommer bli överskrivna av informationen som skahämtas

Utöver dessa kriterier kan en pull inte misslyckas. Men även om det inte misslyckaskan det fortfarande uppstå problem. Dessa problem kommer då både utvecklaren ochden centrala kodbasen har ändrat på samma filer men pullen fortfarande går igenom.Då notifierar Git utvecklaren om detta och ber hen att lösa dessa konflikter (ofta kallademerge-konflikter) innan hen fortsätter arbeta. Oftast går det inte att fortsätta arbeta utanatt lösa dessa konflikter då git lägger in textsträngar i de berörda filerna för att markerakonflikten vilket oftast gör koden okörbar.

• Push En push är när en utvecklare uppdaterar den centrala delen av git med alla lokalaändringar som utvecklaren har gjort på en gren. Det görs genom att alla commits somutvecklaren har gjort på denna gren sedan senaste push skickas till den centrala servern.Git granskar ifall pushen går igenom eller inte. En push kan misslyckas om en annanutvecklare har gjort en push på samma gren som denna utvecklare inte har hämtat nertill sin lokala version. En push kan också misslyckas om det körs några scripts innanpushen (så kallade pre-push scripts) som kan misslyckas.

• Sprint Arbetet som skall göras delas in i sprintar. En sprint är 1-4 veckor lång.

• Sprint-backlog En Sprint-backlog är en lista av aktiviteter som skall utföras under kom-mande sprint.

• Sprint-planning Gruppen bryter ner de aktiviteter som skall utföras under kommandesprint samt estimerar den tid som skall utföras.

• Sprint-retrospective Samtliga gruppmedlemmar deltar i ett möte där föregående sprintutvärderas samt man diskuterar vad som skall förbättras inför nästa.

1 Inledning

Denna rapport beskriver det kandidatarbete som utförts av fem studenter från data- ochmjukvaruteknikprogrammen på Linköpings universitet under våren 2019. Projektet behand-lar implementering av bildanalys för mobila Android-enheter och har gjorts på beställningav Image Systems Nordic AB.

1.1 Motivering

Idag finns det kraftfulla bildanalysprogram som snabbt och enkelt kan identifiera, klassifice-ra samt följa objekt från såväl stillbilder som videofilmer. Denna typ av mjukvara har varitväldigt värdefull för industrin och har flera applikationsområden, så som säkerhet, mätningoch medicin. Dessa program kan på grund av dess komplexitet vara kostsamma vilket integör dem tillgängliga för alla. Av denna anledning finns det intresse av att ta reda på ifall dettakan förenklas och implementeras för mer lättillgänglig hårdvara för enklare användning försåväl mindre organisationer som privatpersoner. Ett annat användningsområde av enklareimplementationer skulle vara demonstration av konceptet bildanalys på företagsmässor därkunden deltar. Ytterligare en motivering med rapporten är att samla projektmedlemmarnaserfarenheter av att jobba i en projektgrupp för att ta fram en produkt på beställning av enkund.

1.2 Syfte

Den här rapporten syftar till att beskriva det projekt som genomförts. Den behandlar teorier,metoder och resultat för att ta fram och utveckla mjukvara för bildanalys anpassad för mobi-la enheter, implementerad för Android specifikt. Arbetet har gjorts på beställning av ImageSystems Nordic AB. De var intresserade av hur den mjukvarumässiga strukturen för ett så-dant här projekt skulle kunna se ut. Den resulterande mjukvaran kommer fungera som enprototyp eller ett underlag för Image Systems Nordic AB att bygga vidare på.

1

1.3. Frågeställning

1.3 Frågeställning

Under arbetets gång kommer gruppen försöka att besvara följande frågor. Resultatet av ap-plikationen TrackApp och de använda arbetsmetoderna kommer att ligga till grund för detta.

1. Hur kan applikationen implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet, som kan vara intres-santa för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Går det att implementera objektspårning i en mobilapplikation?

1.4 Avgränsningar

Detta projekt är begränsat till att endast utvecklas för mobila Android-enheter. Förutom dettafinns det en tidsmässig begränsning på cirka 400 timmar per gruppmedlem, det vill säga cirka2000 timmar totalt.

2

2 Bakgrund

Detta projekt har utförts som en del av kursen Kandidatprojekt i programvaruutveckling(TDDD96) på Linköpings universitet. I detta avsnitt beskrivs uppdraget mer i detalj.

2.1 Beställaren

Projektet sker på beställning av företaget Image Systems Nordic AB. Företaget har sitt ur-sprung i en utbrytning från Linköpings Universitet och skapades 1983 för att konstrueralösningar till behandling av bilder och videor tagna med höghastighetskameror[1]. De är idagsläget en kommersiell aktör på marknaden för produktion och tjänster inom högupplöstbildbehandling. TEMA och TrackEye är företagets ledande projekt. Det förstnämnda är före-tagets kommersiella produkt som inkluderar flertal artiklar för användning inom industrielltbruk, bland annat krocktester. Det senare är utvecklat för militärt bruk med stöd för GPS ochradar. Företagen som använder sig av Image Systems produkter är bland annat Volvo, Saab,DGA med flera. Företagets programvara har som huvudsyfte att användare skall kunna spå-ra objekt eller markörer genom video för att sedan kunna bilda sig en distinkt uppfattningom objektens rörelse, position och acceleration bland annat. Företagets ledande projekt haräven möjlighet att analysera rotationen av objekt.

2.2 Applikationen

Image Systems Nordic AB har som ambition att genom projektet skapa en mobilapplikationsom skall fungera som ett demonstrationsverktyg för företagets huvudprodukter på blandannat företagsmässor. Dess målsättning är att utveckla en förenklad version av en deras hu-vudprodukt, TrackEye. Projektarbetet kommer följaktligen att fungera som en prototyp ochkommer att vara anpassad så att det finns möjlighet för vidareutveckling av företaget.

2.3 Tidigare Erfarenheter

Gruppmedlemmarna har alla erfarenhet av objektorienterad programmering i Java. Vissa er-farenheter finns även inom androidutveckling och Android Studio men mycket kunskap måstekompletteras för att gruppen ska kunna utveckla en antagbar applikation. Ingen av grupp-

3

2.3. Tidigare Erfarenheter

medlemmarna har tidigare erfarenheter av bildanalys. Då detta är det prestandamässigt mestkritiska området för en fungerande slutprodukt krävde denna del kräva mest utbildningstidför samtliga medlemmar.

De studenter i gruppen som läst kursen "Konstruktion med Mikrodatorer"har erfarenhetav att jobba i liknande projekt. Detta leder till att dessa studenter har erfarenhet av hantering,planering samt dokumentskrivning i större projekt. Merparten av dokumenten i denna kursföljer därför samma struktur som är inspirerad av LIPS-modellen [2].

Samtliga medlemmar har även erfarenhet av vad som fungerat bra samt dåligt i tidigareprojekt. Därför sammanfattades dessa erfarenheter i början av projektet och ur detta skrevsett gruppkontrakt. I gruppkontraktet skrevs bland annat förhållningsregler kring kommuni-kation, kodstandarder, deadlines och tidspassning.

4

3 Teori

Detta avsnitt kommer beskriva metoder, mjukvara och den allmänna teorin som ligger tillgrund för projektet. Även programvara som använts för framtagning av dokument samtkommunikation beskrivs översiktligt. Här beskrivs även den agila arbetsmetoden som an-vänts under projektets gång.

3.1 Metoder

Här beskrivs om de agila arbetsbetoder varifrån idéer har lånats för att komponera den ut-vecklingsmetodik som använts i projektet.

3.1.1 Scrum

Scrum är en agil arbetsmetodik populär inom mjukvaruutveckling runtom i världen. Att Sc-rum är agilt innebär att metoden tillämpar ett iterativt, inkrementellt tillvägagångssätt för attlösa allt från enkla till komplexa problem. Scrum är även väl anpassat till denna typen avprojekt då det ger individerna i gruppen mycket eget ansvar. I Scrum arbetar man i Sprintssom är cirka 1-4 veckor långa. Under en sprint utför man den sprint-backlog som planerats ibörjan av sprinten. Efter en sprint så utvärderas arbetet, både hur arbetet gått samt vad manhar hunnit med[3].

3.1.2 Kanban

Kanban är ett avskalat tillvägagångssätt för mjukvaruutveckling. Ordet Kanban betyder påjapanska "Skylt" eller "Tavla" och sammanfattar mer eller mindre vad denna metodik går utpå. Kanban är ett sätt att visuellt hantera det arbete som krävs för att skapa värde genomatt på ett tydligt sätt dela upp arbetet bland gruppmedlemmar. Ett exempel på hur man kananvända detta är att samtliga uppgifter bryts ned och skrivs sedan upp på någon typ av skylt,sedan väljer gruppmedlemmar vad de vill göra och sätter denna skylt under sitt namn[4].

3.2 Verktyg

Här kommer de mjukvaror och program som använts för att utveckla TrackApp att beskrivas.

5

3.2. Verktyg

3.2.1 Android Studio

Android Studio är Android’s officiella IDE (Integrated Develepment Environment) och är ba-serat på IntelliJ IDEA. I Android Studio finns funktionalitet för att kunna testa applikationen ien emulerad miljö alternativt kunna överföra applikationen via USB till telefon. Detta under-lättar utvecklingen av Androidapplikationer[5].

3.2.2 OpenCV

OpenCV heter det bildbehandling- samt maskininlärningsbibliotek som framförallt har an-vänts i detta projekt. Biblioteket har färdigt stöd för ett flertal funktioner, bland annat KaskadKlassifikation (se 3.3.2) som används för spårningen av markörer[6].

3.2.3 Trello

Trello är en organisationsapplikation samt hemsida där användare kan skapa tavlor, listoroch kort med uppgifter för att enkelt kunna fördela arbetet[7]. Gruppen använde funktio-naliteten för att på ett översiktligt sätt se vem som hade ansvar för vad samt för att se statuspå uppgifterna. Ett kort skapades per aktivitet i sprint-backloggen och sedan skrev de grupp-medlemmar som ville utföra aktiviteten sitt namn på det kortet. När uppgiften var slutförd sålades uppgiften under tavlan "Testa" för att meddela resterande gruppmedlemmar att dennauppgift behövde ses över.

Figur 3.1: Exempelbild på gruppens Trelloboard.

3.2.4 Git

Git är ett decentraliserat versionshanteringsprogram som kan användas för att samtliga med-lemmar ska kunna jobba på ett gemensamt projekt[8]. Git erbjuder även stöd för att köraskripts före, under och efter de flesta av stegen som Git använder för att hålla koll på projektetoch förenkla uppdateringar av projektet så som commit, push, pull, merge med mera. Detta kananvändas för att skriva skript som automatiskt testar kod vid något av dessa tillfällen.

3.2.5 GitLab

GitLab är en webbplattform som har servrar för att hålla den centrala delen av koden förprojekt som använder Git för versionshantering. GitLab har också en hel del verktyg för attunderlätta utveckling av ett projekt[9]. Webbplatformen ger också stöd för övervakning vidmerge av grenar. Stödet innefattar krav på kodgranskning i den utsträckning att via GitLab

6

3.3. Bildanalys

kan man tilldela utvecklare roller med olika behörigheter och restriktioner. Till exempel kanman påtvinga kodgranskning på så sätt att vissa roller behöver utföra en merge förfrågningoch få godkännande innan de kan pusha ny funktionalitet.

3.2.6 Slack

Slack är ett kommunikationsverktyg där samtliga projektrelaterade diskussioner kan hållasvia text och samtal[10]. I verktyget kan olika kanaler och trådar skapas för att hålla relevantadiskussioner på ett ställe. Det går även att sända direktmeddelanden till enskilda personer.

3.2.7 Latex

Latex är ett gratis typsättningsverktyg, och är standard för kommunikation och publikationav vetenskapliga dokument[11]. Latex är inte i sig självt en textredigerare utan en Latexredi-gerare används oftast. Det här dokumentet är skrivet med Latex.

3.2.8 Overleaf

Overleaf är en gratis Latexredigerare där flera personer kan skriva i samma dokument samti-digt[12]. Overleaf har grammatikhjälp samt ett flertal andra bra funktioner för att underlättaskrivandet av dokument i Latex.

3.2.9 Google Drive

Google Drive är en molntjänst som samtliga medlemmar kan komma åt, redigera samt sedokument, kalkylark och bilder med mera[13]. Här kan flera individer redigera ett dokumentpå samma gång från olika ställen. Dessa är egenskaper som gör att denna tjänst lämpar sigväl för stora projekt där flera dokument ska redigeras och läsas samtidigt.

3.2.10 MPAndriodChart

MPAndroidChart är ett grafritningsbibliotek för Android. MPAndroidChart kan användasför att snabbt och enkelt rita ut linje- block- cirkel- spindel- bubbel- och ljusdiagram[14].

3.3 Bildanalys

I detta kapitel beskrivs hanteringen av bildanalysen i projektet.

3.3.1 Hough Transform

För att detektera enklare former i en bild så kan man använda sig utav en teknik som heterHough Transform. Denna teknik kan då användas för att identifiera t.ex. linjer eller cirklar i ettstörre mönster för att avgöra om det är det objekt man söker.

3.3.2 HAAR Cascade Classifier

För att kunna genomföra spårning av markör i detta projekt så används framförallt en metod,nämligen HAAR-feature detection, som OpenCV har stöd för. För att hitta ett ungefärligt värdepå mittpunkten av markören används HAAR-kännetecken i applikationen. Haar-känneteckenär kännetecken som är unika för något specifikt objekt. Dessa fås ut automatiskt via Open-CV’s inbyggda verktyg. Dessa kännetecken är skillnader i pixelintensitet i en gråskalad bildoch för en 24x24 pixlar stor bild fås cirka 160 000 st kännetecken [15]. Genom något somkallas Ada-boost, vilket är en maskininlärningsalgoritm, så kan dessa kännetecken delas in i

7

3.3. Bildanalys

kaskadklassificerare ("Cascade Classifier") samt antalet kännetecken kan minskas ner till cir-ka 6000. För att få så få och effektiva kännetecken som möjligt är det bra att använda mycketträningsdata, det vill säga många positiva bilder (bilder där markören finns med) samt nega-tiva bilder (bilder där markören inte finns med). Exakt hur många varierar mycket beroendepå hur unikt objektet du vill leta efter är.

Kaskadklassificerare är ett effektivt sätt att slippa leta efter alla kännetecken i varje bild-område. Genom att endast ha ett kännetecken i första klassificeraren sedan tio i nästa och såvidare så kan man snabbt utesluta om en del av en bild innehåller objektet man söker eftereller ej, se Figur E.3.

När detta är gjort så skapas en kaskad-fil som kan användas på ett enkelt sätt i applika-tionen för att snabbt kunna hitta samtliga markörer i bild och ge ut dess x- och y-koordinateri bilden.

Nackdelen med denna implementation är att en del falska detektioner kan fås samt attkoordinatpunkten i en bild för en markörs mittpunkt kan bli oprecis. För mer detaljerad ge-nomgång se appendix E.

8

4 Metod

I detta avsnitt beskrivs hur arbetet utförts för att ta fram en produkt samt för att besvarafrågeställningarna.

4.1 Organisation

Inom projektgruppen tilldelades varje person en specifik roll. Detta var nödvändigt på grundav projektets storlek. Dessa roller innebar att arbetet kunde delas upp där en person hade ettspecifikt ansvarsområde. Nedan följer en redogörelse av dessa roller samt vad de innebär.

Teamledare – Anton OröTeamledarens yttersta ansvar är att se till att processer följs, se till att gruppen är i en trevligmiljö samt ha sista ordet om någon dispyt skulle uppstå. I detta projekt representerade äventeamledaren gruppen för all kontakt utåt förutom med kund. Teamledaren var även ansvarigför veckorapporter samt statusrapporter för varje iteration. Teamledaren agerar coach förgruppen vid tillfällen då det behövs och ser till att gruppens mål uppfylls.

Arkitekt – Alexander BasaArkitekten i projektet ansvarar för att en bra arkitektur som är anpassad till projektetanvänds. Arkitekten är ansvarig för dokument som behandlar detta, framförallt arkitektur-dokumentet. Personen ansvarar även för den tekniska delen i projektet vilket inkluderar allatekniska beslut där personen har sista ordet. Arkitekten skall även ta fram tydliga modellerför att ge gruppen en bra översikt av systemets uppbyggnad och arkitektur.

Utvecklingsledare - Andreas LindstenUtvecklingsledaren ansvarar för att ta fram en mer detaljerad design av produkten. Underutvecklingsfasen är även utvecklingsledaren ansvarig för samtliga projektmedlemmar (oav-sett tidigare roll) då samtliga medlemmar i detta projekt deltar vid utvecklingen.

Analysansvarig - Alexander AnderssonAnalysansvarig har som ansvar att vara gruppens kontakt gentemot kunden. Detta innebäratt personen är ansvarig för att ta reda på kundens verkliga behov samt för att vara gruppensförhandlingspart med insikt i kundens önskningar. Analysansvarig har även en nära kontakt

9

4.2. Iterationer

med både arkitekt och testledare för att kunna skriva och verifiera att krav uppfylls.

Kvalitetsamordnare - Markus LoborgKvalitetsamordnaren tar på sig ett stort ansvar då personens område innefattar testningoch försäkring av att kvalitetskrav uppnås. Personen tar även det övergripande ansvaretav dokumentation för projektet. Kvalitetssamordnare ska se till att fånga in vad resten avgruppen har för erfarenheter samt att analysera dessa. Utifrån detta skall han förbereda enutbildningsplan och ge inspiration till gruppen om hur de ska gå tillväga. Som ansvarig förtestning har personen ansvar för att sköta den dynamiska verifieringen och valideringen avsystemet genom exekvering. Utöver det ska denna vara ansvarig för att ta fram en logotyp,dokumentmallar samt ändringsrutiner. Detta är dock något som hela gruppen hjälps åt med,då alla tar fram en mall för sitt eget ansvarsområde.

4.2 Iterationer

Projektet utfördes i flera iterationer. Inför en iteration uppdaterades en testplan. Varje itera-tion avslutades med en inlämning av de dokument som hade producerats under iterationensamt en statusrapport och en testrapport.

4.3 Dokumentation

Ett flertal dokument behövdes under projektet för att fastställa struktur och ramverk för attarbeta inom. Gruppen använde sig av ett flertal dokument som beskrivs nedan.

4.3.1 Förstudie

Den förstudie som utfört gjordes genom att gruppen tillsammans med kunden gick igenomvisionen för projektet och de förväntningarna man hade. Till detta arbete skrevs det ett flertaldokument som kommer att beskrivas i detta avsnitt.

Kravspecifikation

Efter att två personer ur gruppen träffat kunden och diskuterat projektet så fortsatte mandiskutera inom gruppen. Mycket av syftet var att ta reda på för och nackdelar med mobilaenheter och hur denna produkt på ett så bra sätt som möjligt kan implementeras för dessa.Det ledde till formulering av väldigt generella krav som man kom överens om med kunden.Genom att inte ha alltför specifika krav lämnade man frihet åt gruppen för att undersöka debästa och mest lämpliga metoderna under arbetets gång.

Systemanatomi

En preliminär systemanatomi skissades fram för att få en övergripande visualisering av syste-mets funktionalitet. Detta dokument har utökats och förbättrats kontinuerligt under arbetetsgång.

Projektplan

Kandidatgruppen tog fram en projektplan där man listade de uppgifter som behövde ge-nomföras samt en tidsuppskattning för dessa. Uppgifterna togs fram genom att gruppen gickigenom kravspecifikationen och diskuterade hur implementationen av kraven skulle kunnase ut tills konsensus var nådd.

10

4.4. Utveckling

Kvalitetsplan

Då gruppen från början bestod av sex gruppmedlemmar påbörjade kvalitetsansvarig ett do-kument för en kvalitetsplan till projektet inspirerat av IEEE std 730. Egentligen var det be-stämt att gruppen skulle ha sju medlemmar men ett avhopp skedde innan projektet börjat.Syftet med kvalitetsplanen var att sätta och upprätthålla standarder för kvaliteten på doku-menten och produkten TrackApp. När ännu en gruppmedlem hoppade av så att gruppen nubestod av fem personer övergavs arbetet med att färdigställa och upprätthålla kvalitetsplanensom ett levande dokument. Istället skapade kvalitetsansvarig tillsammans med utvecklings-ledaren en presentation för examinatorn. Presentationen beskrev översiktligt de delar somskulle ha ingått i den fulla versionen av kvalitetsplanen. Den beskrev även hur projektgrup-pen säkerställer att kvaliteten upprätthålls. Kvaliteten säkerställs genom diskussioner somutgår från kravspecifikationen och gruppmedlemmarnas tidigare erfarenhet av standarder.

4.3.2 Veckorapport

Varje vecka skickades en veckorapport till handledaren samt examinatorn. I veckorapportensammanfattades veckans arbete samt kommande veckas arbete.

4.3.3 Statusrapport

I slutet av varje iteration skickades en statusrapport in. Statusrapporten reflekterade överhela iterationens arbete, hela nästa iterations arbete samt de risker projektet stod inför nästaiteration.

4.3.4 Arkitekturdokument

Arkitekturdokumentet skapades för att ge en beskrivning av den arkitektur som använts förutvecklingen av applikationen. Här beskrivs även för- och nackdelar med den arkitektur somhar valts. Detta dokument skrevs på engelska, då kunden önskade detta.

4.4 Utveckling

Utvecklingen inleddes med att arkitekten gjorde en övergripande design som sedan deladeupp projektet i olika områden. Gruppmedlemmarna fick sedan ansvar för dessa områden.Varje ansvarig person fick se till att ta till sig den nödvändiga kunskap som behövdes för attförstå vad som skulle göras och hur det skulle implementeras. Utöver detta hade man ävenansvar för den tillhörande dokumentationen. De huvudområden som identifierades var:

• Bild-analys

• Data-analys

• Testning

• Datavisualisering/GUI

Designval gjordes genom att testa olika typer av metoder med fokus på dess komplexitetför att säkerställa att de inte skulle utgöra något hinder för de utsatta kvalitetskraven ellerförhindra utökning eller modifiering av mjukvaran. Utvecklingen skedde genom att var ochen tog ansvar för sitt område enligt tilldelning, däremot skedde ett nära samarbete mellangruppmedlemmar inom dessa områden. Det bestämdes att minst ett möte skulle hållas pervecka för att gruppen skulle kunna ligga i fas med varandra samt för att gå igenom resultatetav det arbete som gjorts. I praktiken blev det mer än ett gång per vecka som gruppen träffadesoch det hölls ett väldigt nära samarbete.

11

4.4. Utveckling

Figur 4.1: Översikt över arbetsflödet.

4.4.1 Agil utveckling

Agil utveckling är en generell beskrivning av en rad olika arbetsmetoder som alla följer ettvisst koncept. Termen populariserades av manifestet för Agil systemutveckling[16]. De be-skriver sina prioriteringar som följande.

Individer och interaktioner framför processer och verktygFungerande programvara framför omfattande dokumentationKundsamarbete framför kontraktsförhandlingAnpassning till förändring framför att följa en plan

Det som dessa koncept har gemensamt är att de beskrivs som väldigt flexibla, där man intebinder sig till en detaljerad plan som är känslig för ändringar. Fokus blir istället att man ar-betar i mindre iterationer, utvärderar och anpassar arbetssättet löpande under arbetets gång.Stort fokus läggs på att ha en nära kontakt med beställaren av projektet samt ett nära samar-bete inom gruppen. Vi har framförallt använt oss av en kombination av Scrum [3] och Kanban[17] under utvecklingen.

Från Scrum användes i första hand konceptet Sprints. Vi hade sprintar på en vecka ochbörjade varje måndag med ett Sprint retrospective möte kombinerat med Sprint planning, dvsen planering av kommande veckas sprint samt en sammanfattning av föregående vecka.

Vi använde oss av en Kanbantavla i applikationen Trello, som är en applikation där varjemedlem kan fylla i tavlor med aktiviteter. Detta gjorde att vi kunde strukturera upp vem somskulle göra vad samt ha deadlines för när det skulle vara klart, på ett tydligt och överskådligtsätt.

12

4.5. Testning och kvalitetssäkring

4.4.2 Implementationsspråk

Samtliga gruppmedlemmar hade erfarenhet av Java och därför valdes det språket för im-plementation av TrackApp. Som utvecklingsmiljö användes Android Studio. På en del avde veckomöten som arrangerades under iteration 1 och 2 diskuterades möjligheten att skri-va delar av programmet i C++. Framför allt övervägde gruppen att optimera spårningen avmarkörer eftersom C++ kom rekommenderat som det snabbare och bättre alternativet. Detförutspåddes dock innebära en del extra kodskrivning och utbildning på grund av den ökadekomplexiteten och inlärningskurvan av att kommunicera mellan de två språken, då grundenav applikationen måste vara i Java. Ett strategiskt beslut togs att skriva källkoden i endastJava för att hinna få med den önskade funktionaliteten.

4.4.3 Användargränssnitt

Användargränssnittet utvecklades i ett flertal steg. Till en början skissades ett antal olikastrukturval kring hur man skulle navigera runt i applikationen (se figur 4.2). Dessutom val-des vilket del av applikationen som skulle vara startsida. Efter att ett antal förslag hade tagitsfram så gick gruppen igenom de olika förslagen och valde det som flest tyckte mest om. Efterdet togs multipla alternativ fram för de färger och stilar på bakgrunder och knappar. Des-sa alternativ demonstrerades för kunden där kunden då kunde säga vad de tyckte om våraalternativ samt komma med egna förslag. Deras förslag kring färger implementerades.

4.4.4 Utvecklingsmiljö för Användargränssnitt

Android Studio ger utvecklare ett bra stöd för grafisk utveckling. Vi använde oss således avLayout Editor som är ramverket för grafisk design i Android Studio tillsammans med MPAnd-riodChart för grafritning. Detta eftersom att vi inte använde komplicerade grafiska moduleri utvecklingen av användargränssnittet.

4.4.5 Navigering

En gemensam bild av hur de olika utvecklingsområdena i projektet skulle integreras behöv-des. Dessa områden var framför allt markördetektion, grafritning och layout. En enkel skissskapades för att beskriva TrackApps funktionalitet och vy-navigering. Skissen användes somutgångspunkt för diskussioner under iteration 1 (se figur 4.2).

4.5 Testning och kvalitetssäkring

Skapandet av tester går till på så sätt att en gruppmedlem väljer att skriva ett test för en delav koden. Medlemmen öppnar en specifik mapp i projektet. Beroende på om testet är ettenhetstest eller ett test där man behöver hela applikationen för att trycka på en knapp ellerliknande så finns det varsin mapp. Dessa två mappar genererades automatiskt av AndroidStudio när projektet skapades.

I den valda mappen skapas antingen en ny klassfil eller så modifieras en existerande be-roende på om testet man skapar är ett nytt test eller ett extra test för ett problem där vi redanhar skapat några tester. Sedan skriver man ihop sitt test och ser till att det fungerar mot dennuvarande koden. Fungerar det inte får man granska och se ifall man har skrivit fel i testeteller om det är den nuvarande koden som inte fungerar som den ska. Oavsett vart felet liggerser man till att fixa det.

Sedan när testet passerar är skapandet av testet klart. Vid nästa Git-push på den grenenkommer detta test att köras tillsammans med alla andra tester som fanns tidigare. Detta berorpå att alla tester som ligger under de två specifika mapparna körs automatiskt av ett skriptvarje gång man pushar på en gren. Detta händer för att vi har skapat ett skript som allagruppmedlemmar måste köra efter första gången de drar ner projektet på en dator. Detta

13

4.6. Samarbete med kund

Figur 4.2: Skiss av navigeringen för TrackApp.

skript modiferar en fil som skapades av git som körs innan varje push till att testa alla testeroch bara fortsätta om testerna passerar.

Även en del manuella tester har gjorts nämligen kodgranskning vid merge samt under-sökt hur många procent av koden som är kommenterat. Detta för att säkerställa kvaliteten påkoden som skrivs samt för att se till att koden var lättläst.

4.6 Samarbete med kund

För att säkerställa att arbetet tillfredsställde kundens önskemål under arbetets gång så såggruppen till att ha möte med kunden cirka varannan vecka samt regelbunden kontakt viaemail. Vid dessa möten med kunden så demonstrerades arbetets fortgång och hur produktenutvecklats hittills samt så diskuterade deras åsikter. Kundens åsikter respekteras och användsvid all implementation genom hela projektarbetet.

4.7 Versionshantering

Git är det versionshanteringsprogram som använts. Gruppen använde Gitlab för att kunnadela projektet med varandra samt för att lägga krav på merge till master-grenen. Kravenvar att det krävdes två gruppmedlemmars godkännande, vilket gavs elektronisk via GitLab.Dessa två skulle dessutom inte ha varit med och utvecklat den specifika grenen. Innan ettgodkännande gavs skulle gruppmedlemmarna gå igenom de ändringar som försöker mer-gas och se till att de uppehåller den standard som var satt. Grenar användes för att de olikamodulerna skulle kunna utvecklas parallellt samt för att underlätta arbetet för utvecklarnaoch minska merge-konflikter. Dessutom användes Gits skriptfunktionalitet för att se till att

14

4.8. Metod för att fånga erfarenheter

alla tester körs innan varje push via pre-push skriptet. Skriptet skrevs så att varje gruppmed-lem enbart behövde köra ett skript som kallades install-hooks.bash en gång i början efter attde hade hämtat ner all kod första gången. Detta skript bytte ut Gits default pre-push skriptvilket inte gör något mot ett skript som anropar två metoder som finns i gradle för att köraandroidtester.

4.8 Metod för att fånga erfarenheter

Gruppen hade som mål att ha ett möte en gång i veckan där alla medlemmar närvarade utö-ver de handledarmöten som hölls varje vecka. Dessa möten planerades oftast in på måndagaroch hade som mål att synkronisera arbetet. Under mötena fick gruppmedlemmar visa uppnya funktioner som de kodat och få återkoppling på dessa. På mötena delades arbetet uppför den kommande veckan fram till nästa möte. Ofta träffades hela eller delar av gruppenfler gånger i veckan men då mer specifikt för att utveckla produkten eller skriva dokumen-tation. Utöver det diskuterades hur arbetet hade gått och hur gruppen kunde ta till vara påden kunskap och erfarenhet som skaffat hittills. Det som diskuterades var de arbetsmetodersom använts och hur gruppmedlemmar arbetade tillsammans. Även den återkoppling somgruppen fått från kunden diskuterades för att komma fram till hur man på bästa sätt kundeleverera en bra produkt och om det fanns utrymme för förbättring.

15

5 Resultat

Detta kapitel behandlar resultaten av vad som producerats av projektgruppen för projektetTrackApp. Dessa innefattar resultaten vid utvecklingen av produkten samt de dokument somär relaterade till produktens utveckling. Syftet är huvudsakligen att klarlägga resultat som ärrelevanta i förhållning till frågeställningen.

5.1 Dokument

Här presenteras resultaten utav de dokument projektgruppen har bearbetat under projektetsgång.

5.1.1 Förstudie

Material som producerades under förstudien ligger till grund för hur arbetet genomförts.Kravspecifikationen som utformades är det dokument som huvudsakligen dikterat grund-principerna för projektets arbetsprogression [18]. Vi använde oss av use-cases och diskussio-ner inom gruppen för att bygga en uppfattning om vilken information som behövde inför-skaffas.

5.1.2 Systemanatomi

Systemanotomins syfte var att identifiera nyckelfunktioner som systemet behövde och avgö-ra relationer mellan dessa. Vi tog hjälp av systemanatomin vid implementation av funktio-nerna. Systemanatomin kan ses i figur 5.1.

5.1.3 Arkitekturdokument

Produkten dokumenterades i arkitekturdokumentet där viktiga aspekter av dess strukturbeskrevs. Dokumentet beskriver de olika vyerna i applikationen och implementationen avdessa.

16

5.2. Logotyp

Figur 5.1: Systemanatomin

5.2 Logotyp

Under förstudien ritades en logga i det fria bildbehandlingsprogrammet GIMP (The GNUImage Manipulation Program)[19]. Tanken med loggan var att ha en symbol som represente-rade projektet för gruppmedlemmarna. Vid framtagandet var temat att inkludera något sompåminde om projektet. Loggan (se figur 5.2) är anpassad för att kunna klistras in i sidhuvudetpå de dokument som skrevs utan att ta upp alltför mycket plats.

Figur 5.2: Logotypen för projektet.

5.3 Bildanalys

Spårning av objekt i bild och video använder mönsterigenkänning. Genom en 2D pixelmatriskan ett specifikt sökt mönster urskiljas från detaljer i bilden. Generellt sett innebär det im-plementation av algoritmer som noterar skillnader från en pixel till en annan. Mer specifiktska skillnader uppvisa kännetecken som klassificeras för det sökta objektet. Det finns ett fler-tal utvecklade algoritmer för mönsterigenkänning med olika angreppssett för hur detta görsmen också vad de letar efter.

17

5.4. Användargränssnitt

5.3.1 Träning av klassificerare

Själva träningen av kaskadklassificerare gjordes med OpenCV’s inbyggda metoder[20]. Häranvändes 1000 positiva bilder samt 3000 negativa. Positiva bilder innebär bilder där objektetfinns med. Dessa bilder var tagna i olika ljus och från olika avstånd. Sedan klipps dessa bilderut manuellt, man tar alltså bort bakgrunden från bilden. De negativa bilder som användes var3000 slumpmässiga bilder, både inomhus och utomhus, där objektet inte finns med. Dennaträning tog cirka sex timmar.

5.3.2 Alternativa spårningsmetoder

Försök till att skapa en mer exakt spårning av markören gjordes bland annat genom att im-plementera Harris corner detection. Denna algoritm visade sig vara effektiv för att hitta mitt-punkten och kanterna men gav även många falska positiva resultat längst linjerna av mar-kören. För att minimera detta skapades ytterligare ett filter som avgjorde om färgerna kringdessa resultat matchade färgerna på markören. Detta visade sig vara problematiskt då fär-gerna skiljer avsevärt beroende på ljuset som faller på markören. Dessutom blev spårningensignifikant mycket långsammare, spårningen tog upp mot tio gånger längre tid när dessaalgoritmer användes.

5.3.3 Spårningssäkerhet

Hur väl markören spåras varierar beroende på ljusförhållanden vid inspelningen. Vid opti-mala förhållanden hittas markören direkt och spåras utan falska detektioner, dessa förhållan-den innebär ett stadigt ljus uppifrån mot en plan bakgrund med starka kontraster som av-skiljer markören från bakgrunden. Innehåller bakgrunden flera tydliga räta vinklar kan ävendet ge upphop till falska detektioner. Kvantitativa metoder att säkerställa huruvida effektivspårningen är har däremot inte genomförts.

5.3.4 Filtrering

Eftersom falska positiva resultat kan uppstå från kaskadklassificeraren så behöver detektio-ner genomgå ett filter för att säkerställa att resultatet är korrekt. Det som gjorts i detta projektär att man använt Hough Lines för att hitta alla linjer inom området för detektionen. Linjernasorteras sedan baserat på deras lutning och algoritmen approximerar om linjerna utgör ettkors genom att titta på ifall majoriteten av linjerna tillhör de två största grupperna (lutning-arna) och att dessa två är vinkelräta.

5.4 Användargränssnitt

Applikationens grafiska användargränssnitt startar med en huvudmeny (se figur 5.3.a) därtillgång till all funktionalitet utgår.

5.4.1 Android aktiviteter

Utseendet på det grafiska användargränssnittet byggs i Android Studio genom aktiviteter sominnehåller grafiska layers där funktionalitet fästs via koden till varje specifikt layer. Varje hu-vudsaklig funktion för applikationen är följaktligen skapad som en egen aktivitet.

Huvudmeny

Applikationen är byggt utifrån en huvudmeny där tillgång till kamera, grafer och inställning-ar finns distribuerat genom rörelseresponsiva knappar. Huvudmenyn är skapad med avsiktatt följa Image System Nordic ABs färgschema. Exempel kan ses i figur 5.3a.

18

5.4. Användargränssnitt

(a) Huvudmeny (b) Kamera

Figur 5.3: Skärmbilder av applikationen

Kamera

Kameraaktivtetens grafiska användargränssnitt visar användaren bilden från vad som in-hämtas från kameran på helskärm. Den ritar dessutom ut och spårar markörer som upphittasi bilden så att användaren kan följa dessa i realtid. När användaren börjar filma öppnas mobi-lenhetens egen kameramodul och filmning sker precis som användarna är vana vid. Exempelses i figur 5.3b.

Extern kameramodul

Gruppen jobbade även på att skapa en extern kameramodul för filmning av video genomAndroids API. denna modul ger möjlighet för utökad funktionaliteten vid videoinspelning,så som kontroll av inhämtning av extern data i samband med inspelning och videoinspel-ning med flera synkroniserade kameror. Modulen blev dock aldrig färdig och utelämnades islutprodukten.

Grafer

Då grafaktiviteten öppnas väljer användaren en inspelad video att utföra spårningen på fråninternminnet. Efter att en inspelning valts analyseras denna från back-end. Då beräkning-arna är klara visas en bild för videons nuvarande frame. Exempel ses i figur 5.4b. Genomatt välja en axel X- eller Y för spårning får användaren upp ett kartesiskt koordinatsystemsom skapats av MPAndroidChart som indikerar rörelse av markören med avseende på tiden.Användaren har därefter möjlighet att välja olika punkter på grafen och bilden på videonsnuvarande frame uppdateras därefter. Under inspelningen av video från applikationen ville

19

5.5. Tester

(a) Lista på videos (b) Datavisualisering

Figur 5.4: Skärmbilder av applikationen

vi ha objektigenkänning i realtid. Denna del implementerades i projektet med hjälp av Haarclassifiers som beskrivs närmre i appendix E.

5.5 Tester

Testerna delades in i ett antal grupper beroende på vad testerna behandlade och vilken delav projektet som testerna testade. Dessa grupper var Layout-, Bildanalys-, Kvalitets-, System-och Acceptanstester.

5.5.1 Layouttester

Alla layouttester som planerades blev gjorda. Dessa tester testade rotation, skärmsvepningaroch knapptryckningar på huvudmenyn i applikationen. Mer specifikt kring rotation testadesdet att oavsett vilket håll man roterade enheten så roterade aldrig applikationen. Knapptryck-ningstesterna innebar att korrekt aktivitet startades utan att krascha och skrämsvepnings-testet testade att svepningar inte påverkade applikationen på något sätt. Alla dessa testergenomfördes och passerade.

5.5.2 Bildanalystester

Det fanns enbart ett inplanerat bildanalystest och det testet genomfördes aldrig. Testet skulleha testat att markörer detekteras inom en viss tidsperiod 3 utav 4 gånger.

20

5.6. Grafritning

5.5.3 Kvalitetstester

Kvaliteten har testats på flertal sätt. Först körs alla tester automatiskt när kod blir pushad påen branch. Sedan går all kod genom en granskning av minst två individer som inte har varitmed och skapat koden. Under denna granskning ska individerna gå igenom all kod och se tillatt de förstår den samt att den uppfyller de kodstandarder och andra kvalitetskrav som sattesnär gruppkontraktet skrevs på. Sedan finns ett test som kollar hur många procent av kodensom är kommentarer. Det testet lyckades med resultatet att 20 procent var kommentarer.

5.5.4 Systemtester

De systemtesterna som genomfördes var endast informella test utförda av gruppen där dekvalitetskrav som var satta analyserades. Dessa krav var att appen skulle hitta en markör påunder tio sekunder, samt att kunna spela in en tio sekunders video på minst 10Hz och sedanvisa datan i grafer. Dessa tester uppskattades att vara godkända då båda dessa funktionerklarade kraven.

5.5.5 Acceptanstester

Det planerades och genomfördes ett acceptanstest. Testet genomfördes hos kunden men an-ses vara informellt. Kunden fick då testa applikationen och resultatet blev blandat. De blevglada över att att se hur långt projektet hade kommit men däremot missnöjda med att vissfunktionalitet inte hade blivit implementerad. Bland annat att 3D detektion av markören inteblev färdig.

5.6 Grafritning

Kunden efterfrågade funktionalitet för att rita upp grafer i syfte att demonstrera vad markör-detektion kan användas till. Markördetektionen ger datapunkter i form av position och tidfrån vilka annan data kan beräknas. Under förstudien undersöktes möjligheten att rita uppgrafer genom att använda OpenGL som har stöd för hårdvaruacceleration[21]. Det övergavsdock under iteration 1 till förmån för grafritningsbibilioteket MPAndroidGraph för att sparatid, vi valde detta bland flera andra alternativ [14, 22]. Biblioteket ges ut under Apache Licen-se Version 2.0. Biblioteket har i skrivande stund över 26000 uppröstningar på GitHub vilketavgjorde valet av grafritningsbibliotek. Jämför detta med HelloChart 6000, WilliamChart 4000och GraphView över 2000 uppröstningar.

5.7 Gemensamma erfarenheter

Under projektarbetets gång har gruppen samlat mycket erfarenheter om projektarbeten ochgrupparbete. I detta avsnitt behandlas de erfarenheter vi tillsammans har erhållit. Riskhante-ring har också varit centralt för gruppen eftersom gruppen under arbetets gång blivit av medtvå gruppmedlemmar tidigt under projektet.

5.7.1 Utbildning

Eftersom gruppen inte hade någon erfarenhet av varken Android eller bildanalys så krävdesen hel del utbildning inom dessa ämnen för att kunna lösa de problem som gruppen stodinför. Det vi fick ut av detta var en grundläggande kunskap av Android och Android studiosom användes för utvecklingen. Gruppen fick även kunskaper om grundläggande bildanalysoch de olika metoder som kan användas för att detektera olika kännetecken i en bild. Majori-teten av tiden åt bildanalys gick åt att lära sig använda existerande verktyg och metoder föratt arbeta med detta på en högre abstraktionsnivå istället för att sätta sig in i hur metoderna

21

5.7. Gemensamma erfarenheter

exakt fungerade. Detta har gjort att en del funktionalitet kunde implementeras på kort tid.Att inte lära sig förstå dessa metoder lite djupare ledde däremot till att implementationeninte blev optimal. Att sätta sig in i dessa på en mer detaljerad nivå skulle leda till effektivarebildanalys och är någonting att ta med sig till nästa projekt.

5.7.2 Projektarbete

Samtliga medlemmar i projektgruppen har utvecklats inom att jobba i en projektgrupp relate-rat till mjukvaruutveckling. Detta innebär att medlemmarna kunnat tillämpa sina kunskapersom utvecklats under kursen Programutvecklingsmetodikdär gruppen bland annat lärde sigom effektiv versionhantering med olika grenar samt användning av UML-diagram. Gruppenhar även fått kunskaper inom agil utveckling samt användandet av applikationer, som t.ex.Trello för att underlätta arbetet. Här har gruppen lärt känna många av de fallgropar som finnsi större projektarbeten med en extern kund och kommer kunna förutse många problem bättreframöver.

5.7.3 Riskhantering

Projektgruppen bestod från början av sju personer men innan arbetet startat hoppade en per-son av och sedan ett par veckor in i projektet ytterligare en person. Det ledde till att arbetetmed att upprätthålla en kvalitetsplan övergavs och alternativ med mindre arbetsbörda an-vändes för att upprätthålla kvaliteten. Utöver det identifierades fyra risker med projektet.Riskerna bedömdes inträffa med trolighet T enligt skalan låg 1, måttlig 2, hög 3 och myckethög 4. Riskernas påverkan P på projektets framgång bedömdes enligt skalan katastrofal 4,allvarlig 3, tolererbar 2 och insignifikant 1. Utifrån dessa bedömningar beräknades riskfak-torn R enligt trolighet x påverkan för varje risk. I början av projektet identifierades fyra riskersom beskrevs i projektplanen.

Hantering av kvalitet

Då vi inte använde oss av en kvalitetsplan säkerställde vi kvaliteten genom följande: Innanen merge skedde skulle koden läsas igenom och godkännas av två personer. Vi såg till att15 % av koden bestod av kommentarer samt att vi implementerade automatiserade tester avGUI:t som kördes vid push till branch.

Risk: otillräcklig beräkningskraft

Android smarttelefoner har inte tillräcklig beräkningskraft för att köra bildbehandlingspro-gram såsom OpenCV. Beredskapsplan: ifall det skulle visa sig att android smarttelefoner intehar tillräcklig beräkningskraft kan koden köras på surfplattor istället. I värsta fall finns deten tanke om att lägga beräkningarna på Image Systems AB:s servrar. Alternativt optimerakoden. T=2, P=4, R=8.

Risk OpenCV saknar behövliga algoritmer

OpenCV saknar de bildanalyseringsalgoritmer som TrackApp behöver. Beredskapsplan: Vianvänder ett annat bibliotek för bildanalys. Till exempel Image Systems egna via deras API.T=1, P=3, R=3.

Risk: tracking modul ej modulär

Utvecklingen av vår tracking-modul är inte modulär i enlighet med kundens efterfrågan samtatt modulen ej kan färdigställas. Beredskapsplan: Eftersom att modulen kan lämnas öppen ärhuvudsaken att denna går att bytas mot kundens egna modul. T=2, P=2, R=8.

22

5.8. Sammanfattning av individuella delar

Risk: frånvaro på möten

Personer i gruppen närvarar ej vid gruppmöten och/eller handledarmöten. Beredskapsplan:Gruppen tar och pratar med personen i fråga och tar reda på varför personen inte närvarar.T=3, P=2, R=6.

5.7.4 Tidsplanering och tidsbrist

Under projektets gång har gruppen fått god erfarenhet av att både planera och rapporteratid. Vi har närmare deadlines, inlämningar och seminarium fått en indikation på huruvidavi ligger i fas med den planering som gjorts. Detta har haft som konsekvens att gruppenvarit tvungen att planera om vid tidsbrist och att vissa delar av projektet inte blev utförda.Exempel på gruppens planering är hur det på veckomötena bestämdes vad som skulle görasunder den kommande veckan och vilka som skulle ta ansvar för vilken del för att föra projek-tets arbete framåt. Gruppens behov av att balansera tidsbristen med att leverera den önskadefunktionaliteten gjorde att de delar som ansågs ta för lång tid att slutföra lades åt sidan tillförmån för det som snabbare kunde slutföras. Mycket av de beslut som togs gjordes eftersamtal med kunden. Ett exempel på detta var implementationen av att kunna utläsa grafdatai SI-enheter. Här valde gruppen en enklare och mindre noggrann metod över en mer avan-cerad och tidskrävande med mer precision för att ha någon form av funktionalitet av dettapresenterat i applikationen.

5.7.5 Androidutveckling

Alla gruppmedlemmar har under projektarbetet lärt sig mycket om Android-utveckling. Ut-veckling för applikationer är huvudsakligen styrt från GUI. Detta har som konsekvens attprogramflödet sker asynkront. Det asynkrona programflödet har inneburit vissa problem vidimplementation av delar och hantering av dessa har också varit lärorikt i avseende på hurAndroid-enheter fungerar. Utvecklingen överlag har också givit oss erfarenheter att arbetamed stora existerande bibliotek och hantering av dess dokumentation. Mycket av utveck-lingen krävde att utforska den tillgängliga funktionaliteten i diverse bibliotek för att på bästasätt kunna implementera de önskade funktionerna.

5.8 Sammanfattning av individuella delar

Här ges en kort sammanfattning av samtliga individuella delar som tas upp i denna rapport.

5.8.1 Alexander Andersson: 3D-Rekonstruktion, en Kortare Abstraktion

Detta bidrag undersöker tillvägagångssätt för att införa djupseende från tvådimensionellabilder. Den förklarar även olika metoder för att genomföra denna övergång och hur en foto-graferad bild representeras matematiskt.

5.8.2 Alexander Basa: Hantering av Icke-Funktionella Krav iMjukvaruutveckling

Framtagning av en kravspecifikation är en central del i ett mjukvaruprojekt. Den ger ett kon-kret mål att arbeta mot både under design, utveckling och testning, och har stor nytta förpersoner, oavsett roll, i utvecklingen. Denna undersökning kommer att titta på den kunskapsom finns om icke-funktionella krav och försöka att besvara frågor relaterat till hur dessa bästhanteras.

23

5.8. Sammanfattning av individuella delar

5.8.3 Andreas Lindstén: Attitydundersökning av Allmänhetens Inställning tillDatorseende Kamerabevakning

Denna del presenterar en enkätundersökning som undersöker attityder kring datorseendeövervakningskameror. Attityderna jämförs med åsikter kring övervakningskameror utan da-torseende. Etiska aspekter av kamerabevakning samt deras brottsförebyggande effekt ochanvändbarhet som bevisföring introduceras.

5.8.4 Markus Loborg: För och Nackdelar med Automatisk Testning i Git

Denna rapport kommer gå igenom några av för och nackdelarna med automatiserade tes-ter med fokus på verktyget Git. Den konstaterar att för- och nackdelarna är ofta beroendepå vilket typ av projekt samt nivå av automatisering man vill ha. Dock är en del av slutsat-serna baserade på åsikter mer än vetenskaplig fakta då det var svårt att hitta källor till allafrågeställningar.

5.8.5 Anton Orö: En Jämförelse av Olika Klassificerare i OpenCVs Bibliotek

För att utföra spårning av objekt i detta projekt så har OpenCV’s inbyggda funktioner an-vänts. Dock upptäckte gruppen tidigt att det var svårförståeligt samt att det inte fanns någottydligt sätt att se ungefär hur lång tid det skulle ta att träna klassificeraren samt vad skill-naden var mellan HAAR-metoden samt LBP-metoden. Denna rapport försöker ge läsarenen översiktlig bild över hur dessa klassificerare fungerar samt vilken metod som ger vilkafördelar.

24

6 Diskussion

I detta kapitel diskuteras och analyseras resultaten samt metoderna för att komma fram tillresultaten.

6.1 Resultat

Detta avsnitt diskuterar de resultat som gruppen producerade under projektet.

6.1.1 Dokument

En del av resultatet för projektet var de dokument som gruppen producerade. Här upplev-de samtliga gruppmedlemmar att vissa dokument var bra, men några var onödiga och togendast tid. Under förstudien upplevde medlemmarna att kravspecifikationen var nödvändigför både kunden samt medlemmarna. Detta på grund av att man tvingades tänka igenombåde vad gruppen skulle hinna med samt vad kunden ville ha, man gav också kunden tidigten indikation om vad som förväntades utföras under projektets gång.

Efter förstudien var det framförallt systemanatomin samt arkitekturdokumentet som ar-betades på. Här upplevde gruppen återigen att dessa dokument gav visst värde för bådekund samt grupp. Systemanatomin tvingade gruppen tidigt att tänka igenom strukturen påsystemet och gav även kunden en bra översikt av hur systemet är byggt. Arkitekturdoku-mentet bidrog också med detta men även mer djup kunskap i systemet.

Däremot upplevde medlemmarna i gruppen att projektplan samt testplaner endast bidrogmed stress samt tidsbrist till projektet. Då arbetet utfördes agilt var det svårt att skapa enprojektplan med färdiga aktiviteter med mera. Det var även svårt att hålla testplanen aktuelldå gruppen inte hade någon ensam testansvarig. Det man istället hade kunnat göra är att låtagruppens behov leda utvecklingen av dokumenten för att inte ta fram överflödiga dokumentsom mest konsumerar tid som kunde gått till annat. Även fler gruppmedlemmar hade löstmånga av problemen.

6.1.2 Bildanalys

Som presenterat i Teori samt Resultat så har bildanalys varit en central del i detta projekt. Häranvände sig gruppen av inbyggda verktyg i OpenCV’s bibliotek. De alternativa implementa-

25

6.2. Vidareutvecklingspotential

tionssätt som finns hade varit att skapa en egen maskininlärningsmetod alternativt kommu-nicera mer med kunden och implementera en lösning som de redan har. Utöver detta finnsdet få bildanalys bibliotek och liknande, detta på grund av att det vanligaste är att användasig av OpenCV.

6.1.3 Användargränssnitt

Användargränssnittet som kan ses i figur 5.3 och 5.4 har hög kontrast mellan text och bak-grund vilket ger bra läsbarhet. I aktiviteten med realtidsdetektion av markörer visas en rödring runt de markörer som hittats vilket tydligt visar att TrackApp har hittat en markör. Nären video har filmats backar användaren tillbaka till menyn. Diskussioner hölls om att gå di-rekt till grafaktiviteten efter att en video filmats men den idéen avslogs då det skulle innebäraatt användaren skulle backa förbi kameraaktiviteten för att komma tillbaka till huvudmenynefter att en video analyserats i grafaktiviteten. För att demonstrera konceptet bildanalys hargrafaktiviteten valts att göras så interaktiv som möjligt genom att göra datapunkterna klick-bara. Vid ett klick visas den bild i videon varur en markör detekterats.

6.2 Vidareutvecklingspotential

Status för projektet i slutskededet var att gruppen lyckades implementera spårning i ett två-dimensionellt koordinatsystem. Dessvärre lyckades vi inte genomföra spårning i koordinateri förhållande till världen, någonting som vi hade sätt som en målsättning. Fler metoder finnsför att lösa detta problem. Dessa kan delas in i två kategorier, problem med datahämtningoch problem med effektiv markörspårning.

6.2.1 Dataextraktion

Nuvarande hämtar applikationen all sin information från en kamera brygga från Java vidrealtidsspårning. Detta gränssnitt skiljer sig från att spela in videor där applikationen öpp-nar den redan befintliga kameraapplikationen för inspelning. Detta är däremot en stor be-gränsning för huruvida vi kan kontrollera vilken typ av data som vi kan registrera. Tillgångatt extrahera mer data än den specifika videon har visats avgörande för vissa metoder av3D-spårning för ytterligare läsning se Appendix A.5.3. Vi hade exempelvis kunnat mäta hurtelefonen rört sig mellan varje bild och på så vis spåra via Structure-from-motion (A.5.3). Alter-nativt att vi hade kunnat filma med två kameror samtidigt och på så vis triangulera objekteti realtid (A.5.3). Vi har däremot skapat en passande kameramodul som kan göra möjlighetför att extrahera den data som behövs. Dessvärre har vi inte lyckats få modulen att fungerafelfritt för att implementera denna i vår nuvarande applikation. Vi hoppas däremot genomatt bifoga denna modul kunna skapa ytterligare värde för kunden.

6.2.2 Markörspårning och prestanda

Applikationen kräver i dagsläget relativt lång tid för att utföra beräkningar enbart för en mar-kör genom Haar klassificerarna. Harris corner detection algoritm för att registrera kanternaoch mittpunkten för vår markör skapade också problem med tiotal gånger längre beräknings-tid än utan denna implementation. Metoder för att skapa uppfattning om tredimensionellakoordinater kan utföras genom kamerans egenskaper – Kameramatrisen i kombination medflertalet specifika punkter i en bild SolvePnP, detta förklaras noggrannare i Appendix A.5.3.Om dessa punkter kan detekteras på bilden och deras verkliga förhållande till varandra, detvill säga avståndet mellan dessa punkter, är känt kan vi vid varje bild få en uppfattning omrörelser i förhållande till kameran. Problemet för denna metod är däremot att applikationenbehöver klara effektiv spårning av flera punkter på markören. Om vi hade lyckats skapa ensnabbare spårnings algoritm som dessutom klarar av flera punkter hade vi på så sätt snabbt

26

6.3. Tester

kunna skapa ett tredimensionellt referenssystem. Vi har däremot skapat värde för kund ge-nom att implementera extrahering av kamera matrisen genom kamera kalibrering.

Ytterligare problem vid den långa beräkningstiden av spårningen uppkommer vid fast-ställandet av hastigheter och acceleration. Eftersom att skillnaden i tid – dt, behöver vara såliten som möjligt mellan varje bild för att upptäcka hastigheter så exakt som möjligt behövsdet många datapunkter för att fastställa hastigheter precist.

6.2.3 Effektiviseringsområden

En grundlig undersökning av vad det är i vår nuvarande implementation som tar så lång tidkan möjliga effektiviseringar göras. Processer som kan påverka den prestandan negativt kanbero på att följande funktionalitet inte fungerar optimalt.

• Översättning från bitmap till OpenCV-matris.

• Långsamma spårnings algoritmer.

• Beräkningar uträttas av telefonens centrala processor istället för GPU.

• Översättningar från Javas bitcode till Native code

6.2.4 Användargränssnitt 3D-detektion

En vidareutveckling på grafaktiviteten skulle vara att animera graferna så att datapunkterdyker upp i takt med att videon spelas upp. Kunden Image Systems Nordic AB har ävenuttryckt önskemål om att visa flera dataset samtidigt och i figur 6.1 demonstreras ett sätt attvisa avstånd i djupled med hjälp av färgspektrum.

Figur 6.1: Visualisering av djup

6.2.5 Spårning av markör

För att få optimal spårning av objektet borde antalet bilder vara cirka 10 000 positiva samt 30000 negativa med mer variande ljus samt avstånd, dock hade träningen för detta tagit fleradagar, därför valde gruppen att inte göra detta. Utöver detta fungerade själva spårningenmycket bra.

6.3 Tester

Man kan konstatera från resultatet att alla tester inte genomfördes. Detta beror delvis på attgruppen tappade medlemmar vilket minskade fokus på testning. Det gjorde att det inte längefanns en dedikerad testledare som kunde driva på att tester skulle skrivas. Detta gjorde att

27

6.3. Tester

testning blev nedpriorierat och att bara några layouttester skrevs av testledaren medans allaenhetstester som enligt planen skulle skrivas inte blev skrivna. För att kunna göra detta bättretill nästa gång bör man ha en person som är dedikerad testledare och som har som uppgiftatt styra upp arbetet och se till att även de andra utvecklarna gör sina delar för att testningsköts ordentligt.

6.3.1 Layouttester

Det som upptäcktes genom layouttesterna var att applikationen kunde krascha om man intetidigare genom inställningarna för applikationen hade givit denna (kamera-, skriv-, läs-) rät-tigheter eller om användaren nekade dessa rättigheter. Detta gjorde att kod implementeradesför att säkerställa att applikationen hade de rättigheterna som behövdes och om så inte varfallet att gå tillbaka till huvudmenyn istället för att krascha.

6.3.2 Bildanalystester

Testet som skulle ha testat bildanalys blev inte implementerat på grund av ett antal faktorer.Vi insåg att säkerställandet av att en markör upptäcktes i princip innebar att vi var tvungnaatt implementera ett helt nytt gränssnitt endast för denna detektion. Svårigheten att imple-mentera testet kom ifrån faktumet att den skulle detektera en markör samt att detektionenskulle fungera tre utav fyra fall. En ytterligare svårighet med att detektera en markör kom-mer ifrån att testet körs på en emulerad telefon vars kamera är virtuell stimuleras i en miljöutan markörerna. Tester av denna typ gör även versionhanteren mer komplicerad. Detta ef-tersom pushar teoretiskt sätt kan misslyckas av uteblivna eller felaktiga detektioner som intehärstammar från ny kod ej relaterad till bildanalysen. Exempelvis om kod ändrats för enknapp kan bildanalystestet neka pushen på grund av en misslyckad detektion. Detta skulleförvirring med var felet härstammar från.

6.3.3 Kvalitetstester

Dessa tester var inte initialt planerade att genomföras. Dessa implementerade från krav omkvalitetstester. Det var visserligen planerat att alla skulle granska koden och ungefär en tred-jedel in i projektet bestämdes det att testerna skulle vara automatiserade. Mot slutet lades detfram att detta kunde ses som tester. Det här ledde till att dokumentationen kring detta, i avse-ende som tester, blev undermålig. Testet kring procent som täcks av kommentarer var ocksåett test som gruppen kom på väldigt sent. Annars kunde testet ha visat hur den procentsatsenförändrades under projektets gång vilket skulle kunna vara intressant att se.

6.3.4 Systemtester

Systemtesterna som genomfördes var inte formella tester, Tanken var att man vid något till-fälle skulle sätta sig ner och gå igenom hela applikationen och notera och analysera den.Systemtesterna innebar istället testandet av applikationen som skedde när vi testade funk-tionaliteter och andra delar av applikationen. Systemtestet misslyckades enligt version 1.0 avtestplanen då testet i denna version innebar att analysera videon på en viss tid som var bero-ende på längd av videon och bilduppdateringsfrekvensen. I version 1.1 av testplanen skrevstestet om så att analysen inte längre hade ett tidskrav vilket gjorde att testet passerade. Anled-ningen till att detta test togs bort ur testplanen var att vi implementerat en förloppsindikatorpå progressionen av bildanalysen som gjorde inladdningen överskådlig.

28

6.4. Metod

6.3.5 Acceptanstester

Acceptanstestet gav spridda resultat. Kunden var glad över en del av det som var gjort menlite missnöjda över att andra delar inte var gjorda. Kunden visade intresse av dokumentationkring tidsestimeringar och arbetsbörda för vidareutveckling.

6.4 Metod

Metoder och arbetssätt vi använt oss av under projektarbetet som är relevant diskuteras idenna sektion.

6.4.1 Arbetssätt

Vårt agila arbetssätt fungerade relativt bra dock blev det lite problematiskt då vi bara varfem personer. Detta ledde till att alla delar av projektet inte kunde täckas på ett optimaltsätt och att vissa saker som borde ha gjorts tidigare parallellt med annat blev uppskjutna.Antingen gjordes dessa på slutet eller så skapades det mer uppskjutning av andra saker föratt hinna med. Exempelvis nedprioriterad testning av mjukvaran ledde till att mer tid ladespå utveckling av funktionalitet.

6.4.2 Källkritik

De källor som har använts har valts med omsorg. Denna rapport är inte tekniskt tung men haranvänt sig av forskning i de relevanta tekniska delarna. De flesta av referenserna behandlarmetoder och definitioner som tagits från organisationeras sidor eller andra guider.

6.5 Arbetet i ett vidare sammanhang

Att ta fram en produkt handlar inte enbart om att lösa det omedelbara problem som motive-rade produkten. Utöver att brygga den direkta länken mellan behov, vilja och efterfråga såbör de mer långsiktiga konsekvenserna av produkten analyseras. Under projektets gång del-tog gruppen i många seminarier. Två av dessa handlade om hållbar utveckling. Den förstapresenterade översiktligt vad hållbar utveckling är och teknikens nuvarande roll i samhäl-let på en global nivå. Det andra förklarade mer djupgående hur en produkt kan analyserasgenom ett SusAD (Sustainability Analysis Diagram") diagram för att identifiera långsiktigakonsekvenser inom sociala, tekniska, miljömässiga, individuella och ekonomiska områden.Det kan ritas upp enligt denna metod. [23]

6.5.1 Sustainability Analysis Diagram

SusAD diagrammet för TrackApp presenteras i figur 6.2. Analysen hjälpte gruppen att bättreförstå de långsiktiga konsekvenserna av applikationen.

6.5.2 Samhälleliga aspekter

TrackApp som den fungerar i dagsläget gör jobbet bra att demonstrera konceptet videoana-lys och inspirerar idéer till vidareutvecklingar. En av dessa skulle kunna vara att analyserasportdata och spelares tekniker. Till exempel straffsparkar i fotboll eller grundslag i tennis(forehand, backhand mm). Det skulle jämna ut villkoren mellan professionella spelare medstor budget och amatörer genom att spelarna kan analysera sina rörelser och därmed kunnakonkurrera bättre.

29

6.5. Arbetet i ett vidare sammanhang

Figur 6.2: Sustainability Analysis Diagram för TrackApp

6.5.3 Miljöaspekter

Bland de vanligaste tillvägagångssätten för att lösa liknande problem som hanterats i dettaprojekt finns användningen av någon typ av server för att sköta beräkningar och annat. Enserver innebär mycket hårdvara och har därför stor påverkan på miljön. Då detta projekt en-dast körs lokalt på den mobila enheten, vilket är något de flesta människor redan äger, så ärapplikationens miljöpåverkan inte stor då ingen extra hårvara behövs. Nackdelen med att hasamtliga beräkningar lokalt på den mobila enheten är dock att batteriåtgången ökar underanvändandet på grund av de CPU-intensiva beräkningarna. Men denna ökningen är margi-nell. Utöver detta ger applikationen möjlighet till att utföra saker så som mätningar vilket göratt tillverkning av verktyg som linjaler och måttband inte behövs i lika stor utsträckning.

6.5.4 Etiska aspekter

I dagsläget spårar TrackApp markörer från videos eller bilder. De videor som applikationenfilmar kan innehålla information om individer. Då det enbart är specifika markörer som spå-ras blir det svårt att använda TrackApp för att spåra personer eller andra saker utan tillåtelsedå de flesta skulle notera dessa markörer och ifrågasätta varför de har dykt upp om de inte ärmening att de ska vara där. Visserligen skulle man teoretiskt kunna använda applikationenför industri spionage genom att i krock-tester och liknande använda TrackApp för att få in-formation som man lättare kan läcka men det är enkelt att fixa genom att företagen förbjuderenheter som inte används för att samla deras mätdata vid sådana tester.

30

7 Slutsatser

I detta avsnitt presenteras svaren på frågeställningarna.

7.1 Går det att implementera objektspårning i en mobilapplikation?

Den enklaste slutsatsen man kan dra från detta projekt är också svaret på en av våra fråge-ställningar, nämligen går det att implementera objektspårning i en mobilapplikation? Då enfungerande produkt har skapats är svaret ett klart ja. När det kommer till de andra frågeställ-ningarna räcker inte bara ett ja eller nej för som svar.

7.2 Vilket stöd kan man få genom att skapa och följa upp ensystemanatomi?

Stödet man kan få genom att skapa och följa upp en systemanatomi är en fråga med mångasvar, då alla grupper fungerar på olika sätt och blir hjälpta av en systemanatomi på olika sätt.För vår grupp gav den egentligen bara stöd i början av projektet. Då vi gjorde en tidig sketchmed funktioner för att få översikt över hur vi skulle strukturera arbetet i gruppen. Dennastruktur handlade om vilka områden vi skulle behöva utbilda oss inom samt uppdelning avarbetsbördor. I senare delar av projektet behövde vi inte använda systemanatomin då allaredan visste vad som behövde göras så den föll i glömska och uppdaterades enbart infördeadlines. Så om man kan få stöd i senare delar av projektet missade vår grupp det då viignorerade den mot de senare delarna av projektet.

7.3 Vilka erfarenheter kan dokumenteras från programvaruprojektet,som kan vara intressanta för framtida projekt?

När det kommer till frågan om vilka erfarenheter som kan dokumenteras från detta projektoch vara intressanta för framtida projekt finns det ett antal. Alla har troligtvis några indivi-duella erfarenheter som de känner kan hjälpa dem i senare projekt men det finns även ettantal gemensamma erfarenheter alla kan ha med sig. Dels kommer vi ta med oss mängdendokumentation samt underhållet av dokumentationen då dessa aspekter förvånade de flestaav oss även om vissa delar av dem ibland finns färdiga när ett projekt startas och ibland inte

31

7.4. Hur kan applikationen implementeras så att man skapar värde för kunden?

används ute på arbetsplatsen. Sedan kommer vi ta med oss hur vi hanterade förlusten av 2/7av gruppen och hur detta påverkade vår produkt för att kunna hantera liknande situationerom de uppstår.

7.4 Hur kan applikationen implementeras så att man skapar värde förkunden?

Sist kommer frågan om hur applikationen kan implementeras för att skapa värde för kun-den. Svaret är att det finns många sätt att implementera applikationen för att skapa värde förkunden där vårt sätt är ett av dem. Dels skapar vi värde genom att ge kunden en konceptva-lidering samt ett skelett de kan använda för att skapa sin egna produkt med sina algoritmeristället för våra. Dessutom ger all dokumentation dem både möjliga alternativ de kan använ-da men också ett antal förbättringar på produkten. Sist så ger vi dem en färdig produkt somde kan använda om de vill utan att ändra på något och lägga ner egen tid.

32

A Alexander Andersson:3D-Rekonstruktion, en KortareAbstraktion

A.1 Inledning

Inom industri och främst robotik behöver maskiner och robotar uppfatta avstånd till anting-en objekt eller sin omgivning. För att detta ska kunna ske effektivt behövs en tredimensionelluppfattning om världen. Genom att avgöra position och hastigheter i verklighetens tre di-mensioner behövs förståelse om hur verkligheten är representerad i våra ögon och på bild.

A.1.1 Syfte

Rapportens syfte är att undersöka och jämföra metoder för att skapa en tredimensionell upp-fattning av objekt eller punkter i en bild samt hur detta kan göras på effektivaste sätt för vårapplikation. Syftet är även att analysera hur återskapning av denna informationen sker.

A.1.2 Motivering

Rapportens huvudsakliga motivering är att insamla kunskap och analysera metoder att im-plementera tredimensionell uppfattning. Detta eftersom det är av intresse för utvecklingenav vår applikation.

A.1.3 Frågeställning

Detta arbete är skapat i syfte att svara på följande frågor.

1. På vilka sätt kan man återskapa en tredimensionell uppfattning av verkligheten fråntvådimensionella bilder?

2. Finns det något sätt tredimensionell återskapning kan ske som är av högre intresse föross?

3. Hur fungerar tredimensionell återskapning teoretiskt och kan det skilja sig i tillväga-gångssätt?

33

A.2. Bakgrund

A.1.4 Avgränsningar

Applikationen förlitar sig enbart på information från Android-telefoner och den utrustningdessa enheter har installerat. Rapporten kommer således främst fokusera på metodik inombildanalys som är anpassad för de resurser vi har att tillgå.

A.2 Bakgrund

För beställaren av TrackApp och funktionaliteten av en applikation som ett mätinstrument ärdet av stor vikt att uppfatta rörelser i SI-enheter istället för pixlar. Detta eftersom avstånds-mätning i pixlar inte bidrar med någon meningsfull information för användaren. En bildär en tvådimensionell representation av en tredimensionell värld, vid fotografering förlorassåledes information av verklighetens tredje dimension. Denna information finns inte längretillgängligt utan att analysera bilden och objekten denna representerar. Människan kan utansvårighet avgöra hur objekt i bilder förhåller sig till verkligheten i en bild genom att instink-tivt jämnföra dess relation till kända objekts storlek. Detsamma gäller dock inte för en datoreftersom uppfattning om världen och storlekar inte är trivial att bestämma.

Figur A.1: Nattvarden, Perspektivlinjer och horisonten är markerade i blått [24].

A.3 Teori

Matematik och geometri är grunden för bildanalys. För att återskapa djup i en bild behövsen matematisk översättning från bild till verklighet och en förståelsen om hur den tredimen-sionella världen är representerad i bilden. Bilder ger oss en uppfattning om djup trots att deär tvådimensionella, information om djupet finns således representerat i bilden trots avsak-nad av den tredje dimensionen. Bilder skiljer sig således från verklighetens Euklida geometrieftersom djup representeras på ett annorlunda sätt. Översättningen mellan hur verklighe-ten förhåller sig till bilder upptäcktes då ett stort intresse bland matematiker och konstnärersom bland annat Da Vinci önskade att skapa realistiska bildscener (Se Figur. A.1) [25]. Att

34

A.4. Metod

representera tredimensionella scener så att alla punkter och delar av objekt vidhåller sinaömsesidiga relationer och visar motsvarande delar på bildplanet. Dessa bilder skapades ge-nom användning av perspektivmålning i form av centralperspektiv [26]. Den geometriskaförklaringsmodellen för hur raka linjer förhåller sig till varandra i bild är läran om projektivgeometri som matematiskt föklarar vad som händer då en tredimensionellt värld projiceraspå ett tvådimentionellt plan [27].

A.3.1 Projektiv geometri och homogena koordinater

Projektiv geometrin (PG) (Figur A.2b) är essentiell för att förstå bilder och ger en uppfattningom vad som händer om en tredimensionell scen eller objekt blir projicerad på en tvådimensio-nell (Se Figur. A.2a) yta eller viseversa. Den huvudsakliga skillnaden mellan PG och Euklidgeometri (EG) är perspektivet till skärning mellan parallella linjer, inom PG skär alla linjeri en punkt, detta är konsekvens av axiomen för PG och innebär att alla geometriska figurerkan observeras i ett perspektiv av alla linjer. För parallella linjer sker denna skärning i en nygrupp av punkter (som inte existerar i EG) vid oändligheten, en för varje familj av parallellalinjer. Detta ger upphov till en ny linje med punkter, linjen vid oändligheten och förklaradestydligare vid upptäckten av homogena koordinater (eller projiektiva koordinater) då en nydimension kompletteras för att kompensera för dessa partiskt abstrakta punkter. Detta inne-bär att homogena koordinater för en tvådimentionell bild representeras i tre dimensioner.

(a) Kartesiskt koordinatsystem (b) Samma system projicerat på ett bildplan

Figur A.2: Illustration av projektion av ett kartesiskt system.Blå linje - andragradsekvation,röd linje - hyperbel

A.4 Metod

Rapporten baseras på tidigare forskning och genom en litteraturstudie för att bygga en förstå-else om hur tredimensionell rekonstruktion sker. Området är av stort intresse inom forskningoch är därav välstuderat. Arbetet innefattar således jämförelser mellan olika förstuderademetoder inom området och dessa metoders för- och nackdelar. Initialt försökte jag byggamig en uppfattning om området för att förstå vilket källmaterial som var av intresse. Dettainnebar att studera material för kurser i computer vision från olika universitet samt online före-läsningar. Därefter sökte jag främst mina källor genom google scholar och använde söksträngarsom 3d reconstruction, depth perception in stereo images och homogeneous coordinates. Jaghar främst försökt använda förstahandskällor vilket innebar att många artiklar och studierberarbetades för att undersöka informationens ursprung.

35

A.5. Resultat

A.5 Resultat

Fotografering i en kamera principiellt med hjälp av sensorer (Charge Coupled Device) elleren ljuskänslig film som registrerar projiecerat ljus på en tvådiemnsionell yta. Varje tredimen-sionell punkt i världen projiceras ner på kamerans bildplan och skapar en tvådimensionellbild. Kamerans funktionalitet abstraheras ofta genom en nålhålskamera modell A.3.

Figur A.3: Camera Obscura (Nålhålskamera - egenskapad bild).

A.5.1 Kamerakalibrering

För återskapa relationen mellan punkter i världen och bilden behöver kamerans interna pa-rametrar fastställas. Dessa parametrar involverar den fysikaliska dimensionen på en pixeli förhållande till brännvidden på kameran och kamerans mittpunkt. Parametrarna samlas ikameramatrisen och används för att översätta från tvådimensionella homogena koordinateri bildplanet, till storleksinvarianta vektorer i den tredimensionella världen. Kamerakalibre-ring har även effekten att uppfatta och kompensera för linsförvrängning. För slutproduktenTrackApp var kamerakalibreringen den enda delen från denna individuella rapport vi im-plementerade. Kalibreringen genomförs genom att ta bilder på ett tidigare känt bildplan iolika vinklar, på så sätt kan uppfattning om förändringar som sker för detta plan i bildenanalyseras.

A.5.2 3D rekonstruktion

För att bestämma djupet i en bild behöver skalan på avståndet från kameran fastställas. Punk-ten vars djup ska bestämmas bildar en linje av ljus från objekten till bildplanet. Vid använd-ning av ytterligare en bildvy kan man genom epipolär geometri skapa ett plan (Figur. A.4)mellan punkterna i de två bildplanen och den observerade punkten [28]. Vid rekonstruktionbehövs också de externa parametrarna fastställas. Dessa innebär kameran eller kamerornas

36

A.5. Resultat

position i förhållande till varandra. Det vill säga rotation och avstånd mellan dessa. De exter-na parametrarna används för att definiera referenssystem i vår tredimensionella värld.

Figur A.4: Illustration av Epipolär geometri [29].

A.5.3 Metoder för tredimensionell uppfattning

Lösningar för problemet med 3D återskapning kan generellt delas in i två kategorier. Aktivaoch passiva metoder. De aktiva metoderna innebär att full kontroll finns på ljusförhållan-den för scenen som ska analyseras, ljuskällor som detta innefattar kan variera mellan lamporoch lasrar. De passiva metoderna är metoder där ljusförhållanden inte kan kontrolleras ochinnebär alla ickekonstruerade bildscener. Denna rapport är skriven med avseende på mobil-kameror och kommer huvudsakligen behandla de passiva metoderna.

Passiv Stereo Triangulering

Passive stereo Triangulation (PsT) innebär att två bilder fotograferas samtidigt med två syn-kroniserade kameror ur olika vinklar. Dessa bilder multipliceras med kameramatrisen nämndovan (avsnitt A.5.1) och trianguleringen genom epipolära koordinater bestämmer sedan detokända djupet [28].

Structure-from-Motion

Structure-from-Motion (SfM) innebär att en scen observeras genom en kamera och föränd-ringen mellan bilderna analyseras genom bilden. Fördelen med denna metod är att kamerorinte behöver kalibreras och självkalibrering kan användas. För användbara resultat behöverpunkter på objekten som studeras upptäckas och alla punkters relationer mellan varje bild ibildserien behöver vara känd. [28, 30].

37

A.6. Diskussion

Shape-from-Defocus

Shape-from-Defocus (SfD) använder kamerans möjlighet (eller begränsning) att fokus enbartligger på ett specificerat djup vid varje bild. Det fokuserade området kan observeras och an-vändas för att skapa ett bildplan. Brännvidden på kameran kan då användas för att skapa ettdjupseende. Fler bilder behövs generellt med olika fokus för användbara resultat om djupet.

Solve Perspective-n-Point

Solve Perspective-n-Point (SolvePnP) är tekniskt sätt inte en metod för återskapning utan enmetod att ta fram externa kameraparametrar. Metoden kan dock användas för att uppfattadjup on n är ett heltal större än 3. Eftersom att dessa tre punkter tillsammans bildar ett linjärtplan [31].

Aktiv Mono Triangulering

Genom att använda en kamera och en aktiv ljuskälla (laser) med ett känt avstånd och vinkelfrån kameran. Reflektionen av ljuset som reflekteras fungerar som en radar och registrerar ettdjup i förhållande till infallspunkten och vinkeln i bilden [28].

A.6 Diskussion

De resultat som bearbetats diskuteras i denna sektion.

A.6.1 Metod

Eftersom informationen jag har att tillgå enbart är intagen från yttre källor ger det mig väl-digt lite empirisk fakta om hur dessa metoder faktiskt förhåller sig till varandra. Många utök-ningar hade kunnat göras om det funnits tid och möjlighet att implementera tidigarenämndaalgoritmer i en mobiltelefon. Exempelvis hade beräkningstider kunnat mätas och svårigheteri själva implementationerna kunnat studeras. Skillnader i djup som registreras mellan varjemetod hade kunnat analyseras och studeras och avvikelser för dessa hade kunnat specifice-rats för avgörande av noggrannhet mellan dessa.

Källorna jag använder hade även kunnat vara mer nyanserade, jag använde främst veten-skapliga källor som diskuterar metoderna som nämnts men inga källor eller information frånkommersiella aktörer som troligtvis använt sig av metoderna i praktiken. Information frånsådana källor hade kunnat skapa ett bredare perspektiv på vissa av metoderna jag nämnt.

A.6.2 Kamerakalibrering

Eftersom kameror inte är nålhålskameror (se Figur. A.2b) behöver i kamerakalibrering ge-nomföras. Detta eftersom linsen på kameran och sensorerna skapar förvrägningar. Idellt sättär detta inget problem om kalibreringen är perfekt. Ett problem är dock att noggrannhetenav måtten på bildplanet som används för kalibreringen måste vara väldigt exakta. Antaletbilder och infallsvinklarna för dessa bör även vara många och med tydlig skärpa. Görs ka-liberingen fel kommer alla metoderna av tredimensionell uppfattning att generera felaktigaresultat [32].

A.6.3 Jämnförelse av metoder

Metoderna som finns att tillgå har alla sina för- och nackdelar. TrackApp är dock begrän-sad till de passiva metoderna som beskrivits ovan. PsT har enorma fördelar genom att allinformation inhämtas i samma tidpunkt och ger exakta svar genom matematisk simpla ma-trismultiplikationer. De huvudsakliga nackdelarna innebär dock att mobilenheten måste ha

38

A.7. Slutsatser

tillgång till två kameror som är placerade i samma rikting och användaren måste dessutomkalibrera dessa. SfM har inte dessa problem men denna metod är inte trivial att använda ut-an kunskap om kamerans rörelseavstånd mellan varje bild, finns inte denna informationenskapas en tredimensionell storleks invariant bild av objektet, någonting som i applikationenssyfte inte är av intresse. SfD är en simpelt matematisk metod eftersom informationen ombrännvidd (focal length) enkelt kan extraheras från mobilenheten. Informationen om djupetblir dock väldigt approximativ eftersom nyare kameror tenderar att ha ett stort djuphets fälti fokus. SolvePnP med fasta mätpunkter är troligen den enklaste metoden att implementeraoch den metoden som skulle generera det snabbaste resultaten. Problemet denna metoderhar är dock att två ytterligare mätpunkter måste finnas tillgängliga och telefonen får inte rörasig under inspelningen. Avståndet mellan dessa referenspunkter måste dessutom vara käntvid bildanalysen för denna metod.

A.7 Slutsatser

I detta kapitel besvaras frågeställningen och behandlar de slutsatser som dras i rapporten.

A.7.1 På vilka sätt kan man återskapa en tredimensionell uppfattning avverkligheten från tvådimensionella bilder?

Som beskrivet i arbetet finns ett flertal metoder till att lösa problemet med att återskapa denförlorade information om djup i bilder. Generellt innebär det att triangulera objektet somobserveras.

A.7.2 Finns det något sätt tredimensionell återskapning kan ske som är av högreintresse för oss?

Passiva metoder utan hjälp av yttre mätinstrument som laser och specifika ljussensorer ärdefinitivt av högre intresse för oss. Alla metoder har sina för- och nackdelar men för en mo-bilapplikation är de metoder som tycks ge bäst resultat PsT och SfM. SolvePnP med fastapunkter tycks vara det enklaste alternativet att implementera men tvingar oss använda fastareferenspunkter.

A.7.3 Hur fungerar tredimensionell återskapning teoretiskt och kan det skiljasig i tillvägagångssätt?

Alla metoder innebär principiellt att lösa linjära ekvationsystem genom övergång från homo-gena koordinater till världskoordinater och ett euklidisk koordinatsystem. Däremot kräverSfM att avgöra hur dessa förhåller sig till varandra och analys av rörelser. SfD kräver ocksåytterligare beräkningar för att hitta en god approximation på var djupet kan befinna sig. PsToch SolvePnP med fasta punkter tycks således vara de matematiskt lägst krävande eftersomdessa metoder enbart innebär matrismultiplikationer för att hitta det sökta djupet.

39

B Alexander Basa: Hantering avIcke-Funktionella Krav iMjukvaruutveckling

B.1 Inledning

Framtagning av en kravspecifikation är en central del i ett mjukvaruprojekt. Den ger ett kon-kret mål att arbeta mot både under design, utveckling och testning, och har stor nytta förpersoner, oavsett roll, i utvecklingen. Denna undersökning kommer att titta på den kunskapsom finns om icke-funktionella krav och försöka att besvara frågor relaterat till hur dessa bästhanteras.

B.1.1 Motivering

En av de större utmaningarna med mjukvaruutveckling är att bestämma vad exakt det ärsom ska byggas. Det har visats att fel i hantering av krav är den del som leder till de mestallvarliga och kostsamma konsekvenserna i ett projekt[33, 34], och cirka hälften av alla miss-tag brukar leda tillbaka till kravspecifikationen[35]. Detta beror på att fel som upptäcks i ettsent skede är svårare att åtgärda då de kräver fler och större ändringar. Därför är det viktigtatt förväntningarna på systemet är bestämda, tydligt formulerade, och att samtliga parter äröverens om dem. Man brukar ofta göra skillnad mellan funktionella och icke funktionella.De icke-funktionella, även kallade kvalitativa krav, ignoreras ofta eller får inte lika mycketuppmärksamhet som funktionella[36, 37]. Av denna anledning finns det ett intresse av bildasig en bättre förståelse för dessa.

B.1.2 Syfte

Syftet med detta arbete är att undersöka hur man kan sköta hanteringen av icke-funktionellakrav i ett mjukvaruprojekt på bästa möjliga sätt. Detta kommer att göras genom läsning avrelevant litteratur där ämnet behandlas.

B.1.3 Frågeställning

Detta arbete ska försöka att besvara följande frågor.

1. Vad för problem finns det i hantering av icke-funktionella krav?

2. Hur skulle man kunna lösa de problem som finns?

40

B.2. Teori

3. Bör funktionella och icke-funktionella krav behandlas på olika sätt?

B.1.4 Avgränsningar

Undersökningens fokus kommer att ligga på icke-funktionella krav inom mjukvaruutveck-ling, men eftersom en del av de frågor vi försöker besvara handlar om hur dessa relaterar tillfunktionella krav kommer även dessa att undersökas, om än översiktligt. Samtlig litteratursom behandlas i denna undersökning är skriven på engelska. Mer om hur detta hanteras iarbetet hittas i avsnitt B.3.3.

B.2 Teori

Kravhantering, eller engelskans requirements engineering beskrivs av Thayer som vetenskapenom att etablera och hantera krav[38]. Sommerville beskriver det även som den term som täc-ker alla aktiviteter inom upptäckt, dokumentering och underhåll av krav i ett datorbaseratsystem[39]. Även om det i praktiken ofta talas om funktionella och icke-funktionella krav, såär detta inte en officiell eller standard klassificering då detta är någonting som saknas. Deicke-funktionella kraven benämns oftast som non-functional requirements eller quality require-ment i litteratur men finns t.ex. inte med i IEEEs rekommendationer av kravhantering där deistället är uppdelade i flera olika undergrupper utöver de funktionella kraven[18]. Däremotså hittar vi en definition i deras ordlista relaterad till mjukvara som är nyare, där de beskrivssom ett krav som anger, inte vad en mjukvara ska göra, utan hur den gör det[40]. Då dennadefinition inte hittas i deras tidigare ordlista, visar det att det är inte förrän relativt nyligensom de sett ett behov av ha med en definition[41]. Samma definition som de ger, ges ävenav Sommverville[39]. Däremot påpekas det att detta är en förenkling och inte alltid gäller.Även andra har dragit samma slutsats[42, 43]. Problemet är att vissa krav kan klassificerassom både funktionella och icke-funktionella beroende på hur de formuleras.

B.3 Metod

B.3.1 Litteratur

Denna undersökning kommer att ske genom undersökning av litteratur som behandlar bå-de icke-funktionella krav och kravhantering generellt. Sökningen efter detta har skett frånLinköping universitets bibliotekdatabas som ger resultat från flera andra databaser och er-bjuder relevant filtrering för detta arbete. Sökningar har gjorts på engelska för att få ett störreutbud och det har sökts efter både böcker och vetenskapliga tidsskrifter. Artiklarna har an-vänts som underlag till undersökningen medan böckerna har varit stöd som kompletterandeallmän information om ämnet.

Tidsskrifter

Sökning efter tidsskrifter gjordes endast med sökordet "non functional requirements software".Även de träffar som innehöll "quality requirement" i titeln togs med, även om detta inte fannsmed i själva sökordet, då dessa ofta syftar till samma sak. Resultaten begränsades sedan tillendast akademiska peer-review tidsskrifter via sidans gränssnitt vilket gav 2630 träffar. Dessasorterades automatiskt efter relevans baserat på sökordet och de första 300 träffarnas titlarlästes igenom. De som söktes efter var de som behandlade ämnet icke-funktionella krav påett generellt plan eller tittade närmre på ett område inom processen av dess hantering. Ettexempel på något alldeles för specifikt är t.ex. en undersökning av en specifik metod ellerramverk i hantering av icke-funktionella krav. Därefter lästes sammanfattningarna igenomför att besluta ifall rätt bedömning gjorts av titeln. Till sist så lästes de som var kvar igenom

41

B.4. Resultat

för att besluta om innehållet stämde med tidigare bedömning. Se figur B.1 för mer detaljerom processen.

Figur B.1: Processen för framtagning av relevanta artiklar

Böcker

Valet av böcker har inte skett lika systematiskt som metoden för tidsskrifter. De böcker somanvänts har nämnts av många av författarna vars arbeten lästes igenom. Böckerna valdes utpå grund av deras stora användning i området för att få en närmre titt på vad mycket avden informationen byggt på. Böckerna har behandlad både kravhantering allmänt och icke-funktionella krav. Detta för att lägga en bra grund för processen samt samla information somäven den kan vara relevant för våra frågeställningar.

B.3.2 Undersökning

För att besvara frågeställningen så kommer litteraturen att läsas igenom. Problem kommer attidentifieras från detta för att få en förståelse av vad forskning anser att nuvarande problembestår av. Vi kommer använda oss av detta för att sedan se vad för lösningar det finns till-gängliga och vad som behöver forskas mer på. Ifall lösningar på problem erbjuds så kommervi även att presentera detta.

B.3.3 Terminologi

Eftersom den litteratur som använts i denna undersökning varit på engelska så har det upp-stått en utmaning i att föra över den terminologin till svenska. Orden funktionella och icke-funktionella krav har tagit från SSTBs ordlista[44]. Dessa är även väldigt intuitiva översätt-ningar från de engelska functional- och non-functional requirement. När definitioner inte va-rit tillgängliga så har termer ibland benämnts på engelska, ibland översatts till svenska dåmissförstånd inte ansetts sannolika och även benämnts på båda språk för att tydligt markerakopplingen mellan termerna.

B.4 Resultat

B.4.1 Vad för problem finns det i hantering av icke-funktionella krav?

Insamlingen av identifierade problem från de lästa artiklarna presenteras sammanfattade itabell B.1. En träff i artikeln innebär att den på något viss formulerat detta som någontingsom förekommer i hantering av icke-funktionella krav. Notera att avsaknad av kryss i en rutainte innebär att det konstaterats som ett icke-problem. Inte heller visar tabellen ifall ett annatarbete motsäger det eller har en lösning på problemet.

Brist på bra definitioner

Vi kan notera att bristen på bra och formella definitioner av icke-funktionella krav är vanligtförekommande i litteraturen och även det mest förekommande. Utöver att detta konstatera-

42

B.4. Resultat

Tabell B.1: Identifierade problem

Källa Brist på bradefinitioner

Låg prioritet Dålig doku-mentation

Behov av nyklassificering

Svårt att inte-grera IFK &FK

[36] x[42] x x[43] x x x[45] x x x[46] x x[47] x x x x[48] x[49] x x x x[50] x x

des i artiklarna kunde man även se det i de olika valen av definitioner i de olika arbetena.T.ex. kunde vi se att prestanda, säkerhet och tillförlitlighet ansågs vara de viktigaste i fleraarbeten[36, 48]. Även ett annat arbete rankade säkerhet och prestanda bland de tre viktigas-te, men nämnde inte tillförlitlighet[45]. Detta visar att det finns någon förståelse av de olikaklasserna men att den inte alltid stämmer överens med andras uppfattning.

Låg prioritet

Den låga prioriteten av icke-funktionella krav har även den noterats av många. Vad som ärintressant är att detta ofta var medvetet. T.ex. kunde utvecklare peka på att kunden inte varitså noga med att definiera dem, eller att de inte nämnt det alls[45, 36]. Mycket av detta beroddedäremot på hur pass mycket fel kunden kunde tåla i sin produkt[45, 50]. Även effektivitet ochkostnader kom upp som orsak.

Dålig dokumentation

Glinz noterade problemet att veta var man skulle dokumentera ett visst krav[43]. Förutomatt det inte finns någon konsensus i frågan så uppstår också problemet i formuleringen. Oli-ka icke-funktionella krav kan ha olika påverkan på systemet och därför är uppdelningen avkrav inte så enkel. Ameller upptäckte i sin undersökning att majoriteten av de tillfrågade in-tervjupersonerna i rollen som arkitekter inte dokumenterade sina icke-funktionella krav[45].Likt prioritetdelen påpekade vissa att detta var medvetet och att det inte alltid krävdes elleratt det kostade pengar.

Behov av ny klassificering

Glinz anser att den nuvarande klassificeringen av funktionella och icke-funktionella inte räc-ker p.g.a problem med definitioner, förenklad klassificering och representation[43]. Han sägeratt formuleringen av ett krav kan avgöra om det är funktionellt eller icke-funktionellt utanatt kravet i sig ändras. Detta gör den nuvarande uppdelningen meningslös och har iställetföreslagit ett system där man tar representation, sort, roll och valideringsmetod i beaktning.Att denna uppdelning skapar problem stöds även av andra[42, 49].

Svårt att integrera funktionella- och icke-funktionella krav

Två arbeten som fokuserade på att undersöka tillgängliga arbetsmetoder för icke-funktionella krav noterade att det fanns fler metoder för att hantera funktionella krav, och att

43

B.5. Diskussion

de som existerade för icke-funktionella krav hade problem med deras relation till de funktio-nella[48, 49]. Antingen så togs båda med i processen och ingen hänsyn togs till deras unikaegenskaper, eller så gjorde de icke-funktionella ingenting för att visa hur de står i relation tillde funktionella.

B.4.2 Hur skulle man kunna lösa de problem som finns

Eftersom större delen av artiklarna har varit analyser har de inte erbjudit konkreta lösningarpå de identifierade problemen. Det problem som nämndes mest var att definitioner av vadfunktionella- och icke-funktionella krav egentligen är och hur deras underuppdelningar börske. Vikten av bra hantering har däremot påpekats av samtliga arbeten.

Glinz föreslår att uppdelningen inte bör ske enligt dessa kategorier då dessa ofta kan beropå hur de formuleras[43]. Istället bör man titta på andra egenskaper som till exempel hurkravet formuleras (t.ex. kvantitet, kvalitet) och vilken typ det är (t.ex. funktion, prestanda).Detta skulle ge krav självständiga från formuleringen som är enklare att hantera.

Enligt Eckhardt så kategoriseras ofta krav som kunde varit funktionella, som icke-funktionella[42]. Detta påverkar ofta hur man validerar dessa. Om de istället kategoriseratskorrekt och de faktiskt gått att validera på samma sätt som de funktionella, så föreslår manatt detta görs. Att olika typer av krav bör ha olika processer förslås även av Ullah[47]. Ullahpåpekar att icke-funktionella krav bör tas i beaktning under hela utvecklingsprocessen inklu-sive inledningsfasen och att man måste ha ett bra sätt att hantera konflikter mellan dessa somkan uppstå.

Ett system för att använda icke-funktionella krav genom hela processen har tagits framav Chung som anser att dessa bör vara drivande i utvecklingen[33]. Han presenterar en mål-driven process kallad NFR Framework där kraven vägs mot varandra i syfte att ta fram hurimplementation bör ske. Detta presenterar en lösning på föregående problem men två arbe-ten som gjorde en undersökning över olika existerande metoder kom fram till att många,inklusive Chung, presenterar en lösning som tar icke-funktionella krav i beaktning utan attegentligen ta deras relation till de funktionella kraven i hänsyn[48, 49].

B.4.3 Bör funktionella och icke-funktionella krav behandlas på olika sätt?

Att icke-funktionella krav behandlas annorlunda än funktionella är något man ofta ser, menär det befogat? Vad som kan noteras är att många tar denna kategorisering för givet. ÄvenGlinz[43] som föreslog en ny metod utan dessa noterade att det uppfattades som lite förradikalt. Krav relaterade till kvalitet kan ofta vara svåra att definiera och kvantifiera[47, 50],vilket ofta gör att de behöver valideras på ett annorlunda sätt.

B.5 Diskussion

B.5.1 Metod

Viktigt är att notera att kvalitén på alla arbeten är begränsade till den metoden som använtsoch det blir då viktigt att påpeka de begränsningar som finns för detta arbetet. Det bör näm-nas att artiklarna som använts inte alla har fokuserat på exakt samma ämnen vilket gör attspridningen i resultaten kan vara missvisande om man inte påpekar att de problem som fö-rekom flest gånger inte nödvändigtvis är de vanligaste problemen. Istället visar de bara detsom valts att tas upp i de arbeten som behandlat icke-funktionella krav på en generell nivå.Inte heller är dessa problem rankade mot varandra på något sätt, och de mest förekommandebehöver nödvändigtvis inte vara de mest kritiska.

Det nämndes i resultatet att identifierade problem i tabell B.1 inte visar ifall något arbetemotsäger det andra eller om det löser problemet. Detta hade gjort arbetet mer värdefullt ochkan därför vara intressant att undersöka ännu närmre i framtiden.

44

B.6. Slutsatser

B.5.2 Resultat

Davis som tog fram en samling egenskaper som bra krav bör ha noterade även då att ingakrav kunde vara perfekta eftersom många av egenskaperna hamnade i konflikt[35]. Det gällerdå att hitta en bra balans för att göra de mer förståeliga och lätthanterliga. Det som man skullekunna få ut från detta samt de arbeten i denna undersökning är att den formella process ochmetod som efterfrågas kan bli svår att implementera på grund av de olika behoven som finnsi praktiken. De lösningar och metoder som föreslås har även dessa viss negativ påverkan påen annan aspekt av hanteringen.

Den låga prioriteringen som noterades kan ofta bero på att det finns ett gap mellan forsk-ningen och de som praktiserar, även om det finns problem i området så föreslås det mångalösningar och metoder. Om man som utvecklare inte ser de kortsiktiga fördelarna med icke-funktionella krav och de kortsiktiga målen är det som driver en så kan detta göra att de fården låga prioritering det har. Det kan vara värt att titta närmre på detta för att se hur väl detstämmer.

B.6 Slutsatser

I detta arbete har vi tittat på hanteringen av icke-funktionella krav inom mjukvaruutveckling.Vi har tittat på de olika problem som identifierats av tidigare arbeten och på olika lösningaroch metoder. Något som blivit tydligt är att det inte finns enkla svar på de frågor som ställts,men här sammanfattar vi vilka slutsatser man kan dra.

Vad för problem finns det i hantering av icke-funktionella krav?

Problemen med icke-funktionella krav är många och varierande. De vanligaste som identifi-erades i denna undersökning var problem med hur de definierades och den låga prioritet defick bland utvecklare. Dessa problem berodde både på utvecklare och beställare.

Hur skulle man kunna lösa de problem som finns?

Att lösa problemen är inte särskilt enkelt då en lösning ofta kan bidra med problem på ettannat sätt och en formell metod kan vara svår att implementera på grund av de varierandebehoven i industrin. Något som man kan se är att det finns ett gap mellan forskning ochindustrin. Även om inte alla metoder och lösningar funkar för alla så existerar många somfunkar i vissa syften. Därför skulle det vara bra om de som praktiserar bättre kände till deninformation som forskare tagit fram i ämnet.

Bör funktionella och icke-funktionella krav behandlas på olika sätt?

Det finns ett behov av att dela upp funktionella och icke-funktionella krav, men denna upp-delning som vi utgått ifrån i denna undersökning är en alldeles förenklad för att vara bety-delsefull. Uppdelning bör ske men man behöver se över hur exakt den sker.

45

C Andreas Lindstén:Attitydundersökning avAllmänhetens Inställning tillDatorseende Kamerabevakning

C.1 Inledning

Den individuella rapport som läggs fram här beskriver en attitydundersökning om datorse-ende övervakningskameror. Undersökningen jämförs med attityder kring traditionella över-vakningskameror. Rapporten ger en kort introduktion till användbarhet och brottsförebyg-gande effekt gällande traditionella övervakningskameror samt etik om datorseende säker-hetskameror. Rapporten innehåller bakgrund och teoridel. Metoden beskrivs och resultat pre-senteras samt en diskussion om resultaten och metoden. Rapporten har även en sektion omslutsatser.

C.1.1 Definitioner

Traditionella övervakningskameror - I den här rapporten används termen traditionella övervak-ningskameror för att syfta på kameror utan datorseende, ansiktsigenkänning och dylikt. Enfysisk person behöver spela upp videomaterialet för att leta information.

Datorseende övervakningskameror - Syftar här till ett koncept av övervakningskameror medobjekt- och ansiktsigenkänning. En dator analyserar videomaterial för att skapa en söknings-bar databas. Data är de tidpunkter där objekt, personer och handlingar detekterats.

C.1.2 Syfte

Rapporten syftar till att jämföra allmänhetens inställning till datorseende övervakningskame-ror med traditionella övervakningskameror. Rapporten introducerar även fakta kring brotts-förebyggande effekt av övervakningskameror och dess användbarhet för att lösa brott samtdess etiska aspekter.

C.1.3 Motivering

För att detektera markörer har vi använt oss av maskininlärning där vi tränat TrackApp på1000 bilder med markör och 3000 bilder utan. Datorseende som TrackApp använder sig avkan tränas till att upptäcka annat än markörer, till exempel personer, cyklar och bilar. Kon-

46

C.2. Bakgrund

ceptet fanns redan på 60-talet[51]. Många offentliga platser, butiker, mataffärer och tunnelba-nestationer har övervakningskameror som filmar allmänheten.

Enligt nyhetsartikel från SVT fanns det år 2017 ca 33000 användare av övervakningska-meror i Sverige[52]. År 2017 konstaterades i en undersökning beställd av LUSAX-gruppenvid Ekonomihögskolan vid Lunds Universitet med Markus Lahtinen som författare att 90procent av allmänheten är positivt inställda till kameraövervakning på allmänna platser. Attkameraövervakning på offentlig plats inskränker på personlig integritet stämmer dåligt anser83 procent av allmänheten[53].

Det har skett stora framsteg inom datoroseende på senare tid. Detta öppnar upp för nyaeffektivare tekniker för kameraövervakning[54]. Samtidigt väcks frågan om dess brottsföre-byggande effekt, användbarhet för bevisföring och inskränkning av den personliga integrite-ten.

C.1.4 Frågeställning

1. Vad anser allmänheten om datorseende övervakningskameror?

2. Är det någon skillnad mellan allmänhetens åsikter kring datorseende övervakningska-meror och datateknik- samt mjukvarteknikstudenters åsikter?

3. Skiljer sig attityden kring datorseende övervakningskameror gentemot traditionellaövervakningskameror?

C.2 Bakgrund

Här presenteras kort om när datorseende började bli ett koncept och ett framtidesscenarioom sådana kameror.

C.2.1 Tidigare datorseende

År 1966 ansåg man att datorseende kunde uppnås med ett sommarprojekt. Seymour Papertskrev en projektbeskrivning vid MIT där en projektgrupp under en sommar skulle försökakonstruera ett program som kunde skilja föremål från bakgrund i en bild och klassificeraobjekten mot ett känt vokabulär[51].

C.2.2 Etik

Greg Bear beskriver ett intressant framtidssenario där inte bara allmänna platser såsom gatoroch torg har datorseende övervakningskameror[55]. Bear kallar individer för småbröder i ettsamhället som har tagit ett steg längre och implementerat datorseende övervakningskamerori de flesta konsumentprodukter, såsom i bilar och glasögon. Dessa används sedan sporadisktav individer för att rapportera varandra. Det blir omöjligt att komma undan med något ochdet finns inget privatliv. Personer som har svårt att anpassa sig till samhällets förväntningarfår lida mycket. Walter Kirn beskriver i New York Times ett liknande scenario om småpoliseroch påstår att det vore värre en George Orwells storebrorssamhälle i boken 1984[56].

C.3 Teori

Här presenteras fakta om kamerabevakningens brottsförebyggande effekt samt dess använd-barhet vid bevisföring.

47

C.4. Metod

C.3.1 Traditionella övervakningskameror i brottsförebyggande syfte

Ett stort antal studier har undersökt den brottsförebyggande effekten av traditionella över-vakningskameror. En sammanfattning av en metastudie sammanställd 2018 på beställningav Brottsförebyggande rådet (BRÅ) går igenom den starkaste forskningen på området. Studi-en behandlade 76 utvalda primärstudier och kommer fram till en sammanlag minskning avbrott med 13 procent jämfört med kontrollområden[57]. Studien poängterar att olika resultatuppmättes ifall brotten delades in i kategorier beroende på var de begås och typ av brott.Till exempel var brottsreduceringen på bilparkeringar 37 procent i samband med kamerabe-vakning. Effekten på våldsbrott var nära noll procent. Antalet narkotikabrott sjönk med 20procent. Studien resonerar att brott som planeras i förväg reduceras medan oplanerad brotts-lighet på till exempel nattklubbar inte påverkas av traditionella övervakningskameror.

C.3.2 Traditionella övervakningskamerors värde som utredningsverktyg och ettpotentiellt användbarhetsområde för datorseende övervakningskameror

I artikeln “The Value of CCTV Surveillance Cameras as an Investigative Tool: An EmpiricalAnalysis” sammanställs statistik från över 250 000 brott utredda av Brittish Transport Police(BTP) vid Storbritanniens järnvägssytem[58]. I 29 procent av fallen var videomaterial fråntraditionella kameror användbart. Avändbarheten av övervakningskameror varierade bero-ende på typ av brott. I 62,2 procent av fallen vid stöld var videomaterialet användbart. Viddrogutredningar var siffran enbart 10,7 procent. Generellt sett var videomaterial från kame-rabevakning användbart i 29 procent av fallen. Chansen att ett brott klarades upp ökadesammanräknat för alla typer av brott med 25 procent ifall användbart material från över-vakningskameror fanns tillgängligt. Studien avslutar sin resultatsdel med att formulera hy-poteser om användbarheten. En hypotes är att ju längre tidsrymden är för när ett brott kanha begåtts desto lägre är sannolikheten att videomaterial inte kommer vara tillgängligt elleranvändbart. Detta eftersom det snabbt anses ogenomförbart att titta igen videomaterial frånflera kameror när brottet kan ha inträffat inom en tidsrymd på en vecka eller mer. Just härkan datorseende övervakningskameror komma till nytta då de kan förse användaren med ensökbar databas över vad som filmats[54].

C.4 Metod

Här presenteras den metod som användes för att hitta artiklar samt hur enkätundersökning-en genomfördes.

C.4.1 Frågeformulär

För att försöka besvara frågeställningen gjordes en enkätundersökning. Enkäten innehöll nästintill samma frågor som i frågeformuläret från undersökningen “Allmänhetens uppfattningkring användandet av övervakningskameror på gator och torg, augusti 2017” av MarkusLahtinen[53]. Skillnaden var att “datorseende” lagts till där Lahtinens undersökning skri-vit övervakningskamera, säkerhetskamera och bevakningskamera. Fråga 2 i formuläret harbytts ut och fråga sex har tagits bort. Frågeformuläret om datorseende övervakningskameroråterges i bilaga F.

C.4.2 Attityden håller i sig

En liknande undersökning gjordes av samma författare ett år senare. “Allmänhetens uppfatt-ning kring användandet av bevakningskameror på allmän plats, april 2018”[53]. Frågorna ärsnarlika men vissa meningar har formulerats om. Attityden kring traditionella övervaknings-kameror har varit stabil med 90 procent positivt inställda. Andelen mycket positivt inställdavar 49 procent och 41 procent var ganska positiva vid båda undersökningarna.

48

C.5. Resultat

C.4.3 Artiklar

För att hitta artiklar och källor användes i första hand googles sökmotor. Även UniSearch haranvänds för att leta artiklar vid Linköpings universitetsbibliotek.

C.4.4 Google Forms

Google Forms användes för att skapa frågeformuläret och till att samla in svar från respon-denter.

C.4.5 Google Sheets

Google Sheets har använts för att skapa diagram där data från respondenter visas.

C.4.6 Mejlutskick till studenter

Insamlingen av attityder från studenter gick till på så sätt att enkäter skickades ut via mejl.Dessa mejl gick till studenter av civilingenjörsprogrammen inom datorteknik (D) och mjuk-varuteknik (U) vid Linköpings Universitet. Frågeformuläret tog emot svar tre veckor i April.Den första dagen mottogs tolv svar och därefter sjönk antalet svar per dag. Totalt mottogs 18svar.

C.4.7 Enkätundersökning utanför butik

Fyra gånger åkte jag ut till platser runtom i linköping och bad folk besvara enkäten via enmedtagen surfplatta. Två av gångerna ställde jag mig vid ingången till Maxi Ica Stormark-nad i Tornby där sammanlagt elva svar mottogs. Därefter åkte jag ut en gång till SkäggetorpsCentrum och ställde mig vid Willys där totalt sju svar mottogs. Slutligen ställde jag mig utan-för City Gross i Lambohov där sex personer besvarade frågeställningen. Två bortfall skedde,ett på grund av att befrågningen avbröts och ett på grund av att internetuppkopplingen bröts.

C.4.8 Avgränsningar

De tillfrågade bedömdes alla vara mellan 18 och 75 år även om det inte var något som fråga-des. Detta för att säkerställa att de tillfrågade kunde sätta sig in i ämnet.

C.5 Resultat

Här presenteras resultatet från enkätundersökningen av datorseende övervakningskameror.Allmänhetens åsikt kring traditionella övervakningskameror har tagits med i stapeldiagram-men för jämförelse. Det ska poängteras tydligt att den datan är hämtade från en annan studieav Lahtinen[53].

49

C.5. Resultat

Figur C.1: Inställning till övervakningskameror på allmän plats.

Figur C.2: Inställning till att byta ut traditionella mot datorseende övervakningskameror.

Figur C.3: Inkräktar övervakningskameror på den personliga integriteten?

50

C.5. Resultat

Figur C.4: Allmänhetens åsikt kring övervakningskamerors brottsförebyggande effekt.

Figur C.5: Allmänhetens åsikt kring övervakningskamerors användbarahet för att upptäckapågående brott.

Figur C.6: Allmänhetens åsikt kring ifall deras integritet kränks om polisen själva tillåts be-sluta om sitt behov av datorseende övervakningskameror.

51

C.6. Diskussion

Figur C.7: Allmänhetens åsikt för vilken åtgärd som är mest avgörande för att behovet avintegritet säkerställs.

C.6 Diskussion

I diskussionen presenteras tolkningar av den insamlade datan. Metodens tillförlitlighet sesöver.

C.6.1 Resultat

Genomgång av resultat från enkätundersäkningen.

C.6.2 Allmänhetens inställning till datorseende övervakningskameror

I undersökningen från Lahtinen var 90 procent av allmänheten positivt inställda till tradi-tionella övervakningskameror. Datan i figur C.1 visar att allmänheten var mer skeptisk tilldatorseende övervakningskameror (51 procent positivt inställda). Studenter D och U var än-nu mer skeptiska (39 procent positivt inställda).

C.6.3 Byta ut traditionella mot datorseende övervakningskameror

Frågan i figur C.2 försöker skapa en bild av i vilken utsträckning allmänheten och studentervill byta ut traditionella övervakningskameror mot datorseende övervakningskameror. Vadsom kan sägas om denna data är att även om 50 procent av studenterna och 46 procent avallmänheten var negativt inställda till datorseende övervakningskameror (figur C.1) så ver-kar en lägre andel, 28 procent av studenterna och 21 procent av allmänheten helt motsätta sigatt installera datorseende övervakningskameror. Det går att se att 67 procent av studenternaoch 80 procent av allmänheten anser att sådana kameror kan installeras i någon utsträckning.Opinionen för att installera fler traditionella övervakningkameror är 72 procent som visasfigur C.8.

52

C.6. Diskussion

Figur C.8: Inställning till att sätta upp fler traditionella övervakningskameror.

C.6.4 Datorseende övervakningskameror och personlig integritet

I figur C.3 ses att studenter, som var minst positiva till datorseende övervakningskameror,anser att påståendet att sådana kameror inkräktar på deras personliga integritet stämmermycket bra eller ganska bra (50 procent). Värdet för allmänheten är 38 procent och som sesi figur C.1 var de även mer positivt inställda till datorseende övervakningskameror. Det kanfinnas en korrelation mellan negativ inställning till datorseende övervakningskameror ochattityden att kamerorna inskränker på personlig integritet.

C.6.5 Brottsförebyggande effekt

Att datorseende övervakningskameror kan avskräcka potentiella gärningsmän från att begåbrott anser 50 procent av studenterna stämma ganska bra. 63 procent av allmänheten anseratt det stämmer mycket/ganska bra (figur C.4). Som nämnts i sektion C.3.1 så har BRÅ kon-staterat en reduktion av brott med 13 procent för traditionella övervakningskameror. Kanskeskulle datorseende övervakningskameror ha en ännu starkare effekt? I studien beställd avBRÅ framhålls det att för att kamerabevakning ska ha en brottsförebyggande effekt behöverde som vistas på platsen känna till att övervakningskameror är uppsatta. Jag resonerar att ettsätt, integritetskränkande eller ej, att öka den brottsförebyggande effekten skulle vara genomatt på TV-skämrar på allmänna platser visa att besökare blivit identifierade. Inte med per-sonens namn av integritetsskäl. Istället kan till exempel en fyrkant som markerar personenansikte ritas ut för att påminna besökare om att datorseende övervakning används.

C.6.6 Förtroendet för att upptäcka pågående brott

I figur C.5 ses att 72 procent av studenterna anser att datorseende övervakningskameror kanvara ett mycket bra eller ganska bra stöd i arbetet att upptäcka ett pågående brott. För allmän-heten är den siffran 75 procent. För allmänheten vad gäller traditionella övervakningskame-ror är siffran 86 procent. Det verkar alltså som om att traditionella övervakningskameror dären människa observerar videomaterial anses vara ett bättre stöd för att upptäcka pågåendebrott än att ha en dator som analyserar videomaterial.

C.6.7 Tilltron till polisen

I figur C.6 presenteras svaren på frågan ifall respondenternas integritet kränks ifall polisentillåts besluta själva om sitt behov av datorseende övervakningskameror och data från Lah-tinens undersökning om traditionella övervakningskameror. En snabb överblick tyder på en

53

C.6. Diskussion

korrelation mellan svaren. Det verkar inte spela någon roll vilken typ av kameror som an-vänds, tilltron till polisen är ändå densamma. Majoriteten av de tillfrågade i alla tre grupper-na tyckte inte att deras integritet kränktes.

C.6.8 Fråga om datorseende övervakningskamerors förmåga att reda ut brott

I efterhand ser jag att det hade varit intressant att även undersöka datateknik, mjukvarutek-nikstudenters och allmänhetens uppfattning kring hur väl material från datorseende över-vakningskameror leder till att brott reds ut och klaras upp. Det var ett misstag av mig att inteställa den frågan. Vid en framtida studie liknande denna rekommenderas författaren att tamed en sådan fråga. Det eftersom ett viktigt användningsområde för traditionella övervak-ningskameror är att samla in bevis[59]. I figur C.9 visas istället data från Lahtinens undersök-ning om traditionella övervakningskameror. Där anser 82 procent att det stämmer mycketbra eller ganska bra att traditionella övervakningskameror kan hjälpa till att brott klaras upp.Allmänheten verkar inte vara helt ute och cyklar. Det har visats att chansen att ett brott kla-ras upp ökar med 25 procent ifall videomaterial från traditionella övervakningskameror finnstillgängligt vilket har nämnts tidigare i sektion C.3.2.

Figur C.9: Allmänhetens åsikt kring att traditionella övervakningskameror är användbaraföra att klara upp brott.

C.6.9 Att säkerställa behovet av integritet

I figur C.7 visar datan att skyltning samt reglering kring hanteringen av videomaterial fråndatorseende övervakningskameror var viktigt för allmänheten. Studenter bryr sig inte likamycket om skyltning men vill framför allt ha reglering av videomaterial samt i viss månsträng tillståndsgivning.

C.6.10 Teori

Den största delen av rapportens teoridel behandlar traditionella övervakningskameror. Dettaval gjordes då det var svårt att hitta artiklar med fakta om datorseende övervakningskamerorinom områdena brottsförebyggande effekt och värde som utredningsverktyg av brott. Artik-larna om traditionella övervakningskameror kan förhoppningsvis ge en ungefärlig bild avdatorseende övervakningskameror inom dessa områden.

C.6.11 Metod

Under nedanstående rubriker kommer rapportens metod att diskuteras mer ingående.

54

C.6. Diskussion

C.6.12 Metod för att hitta artiklar

Googles sökmotor uppdateras kontinuerligt och är påstådd att personalisera sökresultat ut-ifrån användaren[60]. Därför går det att ifrågasätta metoden med att använda google föratt leta källor. En annan sökmotor som använts är UniSearch som används av Linköpingsuniversitetsbibliotek[61]. Det går att använda sig av operatorer såsom AND, OR och NOT iUniSearch. Ett urval av engelska söksträngar som används på google och/eller i UniSearch är“surveillance”, “surveillance camera”, “CCTV”, “public opinion”, “public attitude”, “poll”,“computer vision”, “face recognition”, “crime prevention”. Även svenska: “övervakningska-meror” , “säkerhetskameror”, “kamerabevakning” , “kameraövervakning”, “datorseende”,“ansiktsigenkänning” och “brottsförebyggande”.

C.6.13 Källkritik

Källor har försökt väljas med omsorg. För att hitta enstaka data baserades en del källorstrovärdighet på vedertagna nyhetsgivare. Till exempel siffran på antalet användare av över-vakningskameror som gavs av SVT[52]. En del källor har genomgått peer-review och ansesdå legitima. Till exempel Greg Bears framtidsscenario[55]. Andra källors trovärdighet harbaserats på erkända skribenter har lyft fram dem. Exempelvis ett blogginlägg av AndrewSullivan som refererar till en intervju med internetaktivisten Eli Pariser av Lynn Parramoredär det sägs att google personaliserar sökresultat[60]. Andrew Sullivan har haft sin bloggpublicerad online på nyhetstjänsten The Atlantic[60][62].

C.6.14 Vad undersöktes?

Vid undersökningen försökte skillnaden mellan datorseende och traditionella övervaknings-kameror klargöras. Detta för att se till att just konceptet datorseende övervakningskamerorundersöktes. Det förklarades tydligt att datorseende kameror har förmågorna objekt- ochansiktsigenkänning. Funktionaliteten att söka efter objekt och personer inom bestämda tids-ramar kan ha framkommit mer otydligt. Det är en allvarlig brist.

C.6.15 Fråga om integritet då polisen själva får besluta om behov av datorseendeövervakningskameror

Under insamlandet av svar från förbipasserande utanför Maxi Ica Stormarknad upptäckteen observant respondent att en fråga innehöll ett fel och var ofullständig. Felet kan ha gjortdet otydligt för respondenterna att veta vad de svarade. Jag hade utlämnat Stämmer det...?"i frågan, se figur C.6. De 18 studenter som svarade via mail fick den felaktiga frågansamt de fem första respondenterna utanför Ica innan felet rättades till. Förhoppningsvis gickbudskapet ändå fram.

C.6.16 Urvalet för enkätundersökningen

Urvalet för enkätundersökningen är för litet för att kunna dra några slutsatser utifrån respon-denternas svar. Ett försök gjordes med att få ett så representativt urval som möjligt genom attåka ut till olika matbutiker runtom i Linköping.

C.6.17 Svarsfrekvens

Mailet med enkätundersökningen om datorseende övervakningskameror skickades till sam-manlagt 74 studenter. Då 18 svarade blev svarsfrekvensen (antal svar / antal utskick) 24 pro-cent. Svarsfrekvensen för de tillfrågade utanför butiker mättes ej. För att ett svar skulle räknaskrävdes att alla frågor var besvarade.

55

C.7. Slutsatser

C.7 Slutsatser

Urvalet i enkätundersökningen är för litet för att vara representativt. Därför går det tyvärrinte att dra några säkra slutsatser utifrån de insamlade svaren utan enbart spekulationer ärmöjliga. Forskning om traditionella övervakningskameor har visat att de generellt sett mins-kar brottslighet med 13 procent där de sätts upp. Videomaterial från kameror var användbartvid 29 procent av ett stort antal fall av brottslighet vid Brittiska järnvägar.

C.7.1 Vad anser allmänheten om datorseende övervakningskameror?

Urvalet i enkätundersökningen är för litet för att dra några slutsatser. De svar som mottogspekar på att ungefär hälften av allmänheten anser sig vara positivt inställda till datorseendeövervakningskameror. En något mindre andel anser att datorseende övervakningskamerorinkräktar på den personliga integriteten. Att datorseende övervakningskameror kan vara ettbra verktyg för att upptäcka ett pågående brott anser hela tre fjärdedelar av allmänheten.

C.7.2 Är det någon skillnad mellan allmänhetens åsikter kring datorseendeövervakningskameror och datateknik- samt mjukvarteknikstudentersåsikter?

Som sagt så är urvalet i enkätundersökningen för litet för att dra några säkra slutsatser. Jäm-förs svaren från enkätundersökningen mellan allmänheten och datateknik- samt mjukvar-teknikstudenters åsikter går det att se tendenser på att inställningen till datoseende övervak-ningskameror är något svalare hos studenterna än hos allmänheten. Samtidigt finns svagatendenser på att allmänheten anser att datorseende övervakningskameror inte inkräktar påderas integritet i lika stor utsträckning. Tilltron hos allmänheten till datorseende övervak-ningskamerors förmåga att upptäcka pågående brott är något större än studenternas.

C.7.3 Skiljer sig attityden kring datorseende övervakningskameror gentemottraditionella övervakningskameror?

Om man utgår från resultatet av allmänhetens svar i enkätundersäkningen i denna rapportoch jämför med undersökningen som Lahtinen gjorde år 2017 går det att spekulera att all-mänheten är mer positivt inställda till traditionella övervakningskameror än datorseende.

56

D Markus Loborg: För ochNackdelar med AutomatiskTestning i Git

D.1 Inledning

Under projektets gång har några tester skrivits och körts. En del av testerna kördes automa-tiskt och ett acceptanstest kördes manuellt. De manuella testerna var dock enbart acceptan-stester och användbarhetstester som inte går att automatisera. Utöver dem automatiseradesalla tester. Men var det verkligen nödvändigt att automatisera alla tester, eller gjordes detbara för att det kändes coolt med automatiserade tester? Målet med denna rapport är attlägga fram för- och nackdelarna med automatiserade tester för att konstatera hur bra demegentligen är.

D.1.1 Syfte

Syftet med rapporten är att analysera för- och nackdelar kring automatiserade tester. Frånden analysen ska sedan slutsatser kring när man borde använda automatiserade tester omman någonsin borde använda automatiserade tester dras.

D.1.2 Motivering

Som testledare var det upp till mig att bestämma hur produkten skulle testas. Jag har varitmed i projekt där automatiserade tester använts men aldrig själv haft något med det att göra.Det har gjort att jag gärna ville lära mig att skapa automatiserade tester då det verkade väldigtpraktiskt att alla tester kördes automatiskt utan att vi behövde göra något. Dessutom kändesdet bra då vi blev en relativt liten grupp på 5 personer vilket gjorde att vi valde att läggamindre tid på att testa produkten. Detta gör att om vi skulle kunna göra automatiseradetester behövde vi inte lägga ner extra tid på att köra testerna vilket gör att vi kunde få mertid att lägga på att skapa tester.

Då jag väl satte mig in i automatiserade tester och hur de fungerar började jag funderakring allt positivt automatiserade tester bidrar med. Det i sin tur fick mig att fundera på omdet finns några negativa aspekter eller om automatiserade tester var “perfekta”. Denna frågadrev skapandet av denna rapport.

57

D.2. Bakgrund

D.1.3 Frågeställning

Från syftet har ett antal frågor tagits fram som när de svaras på ska uppfylla syftet med dennarapport. Frågorna har tagits fram på sådant sätt så att hälften av dem är mätbara medans denandra hälften är frågor som besvaras genom att samla data från andra undersökningar.

1. När blir det värt att använda automatiserade tester istället för manuella?

2. Hur enkelt är det att automatisera testandet av kod via Git?

3. Är det enklare att hitta fel med automatiserade tester än med manuella tester?

4. Hur mycket snabbare blir testningsprocessen om man har automatiserade tester iställetför manuella?

D.1.4 Avgränsningar

Automatiserade tester är ett stort område och det finns många sätt att göra det på. Allt frånatt skriva ett skript till att använda sig av färdiga verktyg kan ge automatiserade tester. Underprojektets gång har enbart Git använts för automatisering vilket är varför det antas att manhar använt Git under denna rapport. Alltså kommer svaren enbart gälla om man har enbartanvänt Git för att automatisera.

D.2 Bakgrund

När jag väl hade bestämt mig för ämnet jag skulle skriva om började jag fundera mer kringdet. Jag funderade kring hur lönsamt det var för små projekt kontra stora projekt att användaautomatiserade tester och om det finns någon klar gräns eller om alla kan använda dem förvilket projekt som helst vilket ledde till frågeställning ett. Sedan började jag fundera kringvarför man borde använda automatiserade tester. Jag funderade kring hur mycket snabbareautomatiska tester är kontra manuella och hur mycket mer fel fångar dem då många hävdaratt de är snabbare och fångar fler fel än att bara ha manuella tester[63, 64]. Detta ledde tillfrågeställning tre och fyra. Frågeställning två kom från att jag behövde automatisera vår test-process och funderade över om det var enkelt eller svårt i förhållande till andra verktyg somkan användas.

D.3 Teori

Git är ett versionshanteringsprogram med många funktioner. En av dessa funktionaliteter ärde så kallade hooks. En hook är egentligen bara ett bash skript som skapas så fort man initali-serar ett Git projekt i en mapp. Hooks ligger under mappen ".git". Dessa hooks är från börjanbara tomma exempelskripts som inte riktigt gör någonting, men alla hooks är utbytbara motdina egna skripts. Poängen med Hooks är att de körs vid olika tillfällen i Gits process av atthantera din kod. Detta gör att genom att byta ut vissa eller alla av dessa kan man modifi-era vad som händer under hela hanteringen av din kod. Man kan göra allt från att byta utord till att skapa och köra tester samt blockera och avbryta processer om inte skripten gårigenom.[65]

D.4 Metod

För att komma fram till svar på frågeställningen har information samlats in från flera källorsamt på två olika sätt. Det första sättet var att samla information från tidigare undersökningarkring området. Det andra är sättet var att ta information från gruppens egna erfarenheter ochtankar kring området under projektets gång.

58

D.5. Resultat

D.4.1 Tidigare undersökningar

Det finns en del tidigare undersökningar, artiklar och rapporter kring detta område. Dessahar använts och analyserats för att från metadatan dra egna slutsatser. De har valts för att deuppfyller någon eller några av de följande kriterier:

• De innehåller några av de positiva aspekterna av automatiserade tester.

• De innehåller några av de negativa aspekterna av automatiserade tester.

• De analyserar hur många fel automatiserade tester hjälper till att fånga.

• De analyserar hur mycket automatiserade tester minskar tid som läggs på testning.

För att hitta dessa undersökningar, artiklar och rapporter har två sökplattformar an-vänts. Den första av plattformarna är Google Scholar och den andra är LiU’s online bib-liotek. Där har det sökt efter en kombination av sökord. Dessa sökord är bland annatGit,advantage,disadvantage,för- och nackdelar, testing, automated och reducing. Sedan harresultaten granskats och ibland har resultatens källor granskats för att hitta bra källor.

D.4.2 Gruppens egna erfarenheter och tankar

Då automatiserade tester har använts under projektets gång har en del information samlatsin kring vad de olika gruppmedlemmarna tyckte om att använda automatiserade tester. Det-ta samlades in under det sista veckomötet då vi diskuterade de automatiserade tester somfanns och hur det hade gått för gruppmedlemmarna att använda de automatiserade testerna.Dessutom loggas tiden det tog att skapa, automatisera och köra testerna. Denna data kommeratt användas för att dra slutsatser kring automatiserade tester.

D.5 Resultat

Här presenteras de resultaten som gavs av metainformationen från de källor som har använts.

D.5.1 Fördelar

En av fördelarna med automatiserade tester är att man inte måste starta testerna själv utandet görs automatiskt[65]. Detta gör att man alltid kommer att upptäcka så fort någontingnytt får gamla tester att krascha då de automatiskt kommer att köras och detektera felen somuppstod när det nya lades till. Detta gör att vissa buggar och fel kan hittas snabbare. Dock ärdet bara de fel och buggar som skapas av att den nya koden förstör gammal funktionalitetoch inte buggar som finns i den nya koden.

En annan fördel är att det går snabbare i en pipeline[66] om testningen är automatiserad.Har man manuell testning måste någon ta på sig ansvaret att testa koden och sedan skickavidare den till nästa steg i pipelinen. Detta kan ta tid speciellt om personen har annat somockså behöver göras och gör testningen senare. Har man istället automatiserad testning för-svinner detta steg då alla tester körs automatiskt av datorn och fortsätter vidare i pipelinenutan någon väntan.

D.5.2 Nackdelar

Beroende på vilken nivå av automatiserad tester man har kan det bli väldigt dyrt[67, 68,69]. Har man bara ett simpelt skript på en Git-hook kostar det enbart den lilla tid det tar attskapa skriptet. Detta tog mig ungefär 30 minuter med 3 års programmeringerfarenheter inomskriptspråket. Har man dock en stor automatiserad process där vissa tester genereras ochsedan körs genom en stor pipeline får man betydligt högre kostnader. Dels bara skapandetav pipelinen. Även om det går snabbt så är det många verktyg och de flesta bra varianter

59

D.6. Diskussion

kostar pengar att använda. Sedan har man underhållet[68] av hela pipelinen vilket kostartid då någon anställd måste förstå hela processen samt spendera timmar med att underhållaoch uppdatera den när det behövs. Jämför man då 30 minuters lön kontra en okänd mängdtimmars lön plus inköp av verktyg så kan man se att det kan kosta väldigt lite eller väldigtmycket från ett företags perspektiv.

En annan nackdel är att automatiserade tester är inte heltäckande[69] vilket gör att manfortfarande måste ha en del manuella tester vilket kostar arbetstimmar.

D.6 Diskussion

Här diskuteras problem som uppstod under skrivandets gång. Dessutom diskuteras källkri-tik och ett antal intressanta observationer.

D.6.1 Metod

En hel del av arbetet bakom denna rapport har varit att leta fram källor till resultatet ochhitta svar till frågeställningarna. Vissa av frågeställningarna har det dock inte hittats någravetenskapliga källor som stödjer utan de slutsatserna är enbart dragna från gruppens eg-na åsikter kring automatiserade tester och den automatisering gruppen har använt underprojektet. Detta är ett problem då det bara är personliga åsikter med minimal vetenskapliganknytning i tidsrapportering och en ensam produkt.

Ett annat problem är att datan som hämtas från projektet beror på hur ärligt tiden somrapporterats är. Dessutom eftersom åsikterna kan påverkas av gruppmedlemmarna person-liga relation med mig blir resultatet också påverkat.

D.6.2 Resultat

En sak som man ser både på nackdelarna och fördelarna är att resultatet till stor del berorpå vilken situation man är i. Situation i detta fall refererar till vilken nivå av automatiseradetester man vill ha samt hur stort projektet man jobbar på är.

Detta gör att alla slutsatser som rör andra nivåer av automatiserade tester och andra stor-lekar på projekt är bara extrapolering från tankar och logik kring resultaten som har fåttsfrån detta projekt med denna nivå av automatisering samt de andra källor som har använts.Dessutom gör det att det finns en risk att slutsatserna som dras för detta projekt enbart gällerdetta projekt och kan vara svåra att föra över till andra projekt.

Rent allmänt kan man dock se att mängden fördelar och nackdelar kring automatiseradetester är relativt jämna. Denna rapport tog upp två stycken fördelar och två nackdelar. Själv-fallet finns det fler, både bra och dåliga, men dessa var de som dök upp överallt och alla höllmed om. Dessa för- och nackdelar är också relativt jämnlika i hur mycket de försämrar ellerförbättrar situationen. Detta beror dock till stor del på att den stora nackdelen är kostnad ochkostanden är proportionerlig mot de fördelar som man får.

I denna rapport känns nackdelarna större än fördelarna då kostnad och faktumet att manfortfarande behöver manuella tester känns värre än att man slipper tänka på att köra testeroch att det går snabbare. Men det är troligtvis bara för att jag ser det på en individuell nivå.För företagen och de grupper med stora långvariga projekt spelar det en större roll. Då tidendet tar att göra något påverkar många aspekter. Dels när produkter blir klara och kan släppasoch dels anställdas lön om de har timlön.

Detta tar oss tillbaka till det som diskuterades i början av detta kapitel nämligen hur för-och nackdelarna var beroende på vilken situation man är i. Men det beror också på vilken ni-vå man själv befinner sig på. Även inom ett stort företag kan det skilja sig då bossen troligtviskommer oroa sig mer för kostnaderna medans de anställda kommer gilla att det går snabba-re och inte tänka på kostnader lika mycket. Alltså är för- och nackdelarna med automatiskatester väldigt subjektiva.

60

D.7. Slutsatser

D.6.3 Källkritik

Källorna som valdes är en blandning av olika rapporter, artiklar och åsikter. Artiklarna vardels tagna ur kända publicerade konferanspapper vilket gjorde dem pålitliga då man inte fårpublicera artiklar i de konferenserna utan en nogrann undersökning att artikeln är vettig ochhar bra vetenskapligt stöd. Några artiklar var tagna från tekniska magasin men de användsmest till att dubbelkolla information och styrka åsikter som vi själva har tänkt fram. Våra egnaåsikter är den minst pålitliga källan då den ändras från person till person, men då de oftastöds av andra källor kan de användas ändå. Inhämtningen av de egna åsikterna kunde varitmer systematisk med en intern enkät istället för att bara ha en diskussion om hur det gickoch vad gruppmedlemmarna tyckte. Rapporterna var en blandning av olika examensarbeten.Även där finns det en undersökning på att innehållet är vettigt innan det publiceras.

D.7 Slutsatser

Nedan presenteras slutsatserna samt svaren på frågeställningarna som ställdes i början avdenna rapport.

D.7.1 Hur mycket snabbare processen blir om man använder automatiseradetest än manuella tester?

Som det påpekades under diskussionen är en del av frågeställningarna svåra att svara på dåfå källor har hittats som stärker de tankar och funderingar som har uppstått i gruppen underprojektets gång. En av dem var denna frågeställning. Slutsatsen blev dock att för projektetgår processen inte snabbare då automatiseringen bara är ett skript som kör de tester somfinns. Detta tar samma tid som att köra testerna manuellt. Men har man en hel pipeline försitt projekt går det snabbare då pipelinen inte måste avbrytas för att köra tester.

D.7.2 Hur enkelt är det att automatisera testandet av kod via Git?

Denna frågeställning var det också svårt att hitta vetenskapliga källor på. Dock fanns någramindre vetenskapliga källor. Svaret är att det är väldigt enkelt. För en enkelt variant är detbara att skapa två skripts. Ett som byter ut ett av Gits hook-skript mot det andra skriptet ochett (det andra) skript som går igenom alla tester. För en mer avancerad nivå kan man användaen gratistjänst som ger stöd för en hel automatiserad Git pipeline.

D.7.3 Är det enklare att hitta fel med automatiserade tester än med manuellatester?

Slutsatsen för denna frågeställning är beroende på vad för typ av fel man vill hitta. Om manvill hitta fel och buggar i nya funktioner är svaret nej, det blir inte enklare men om manvill hitta fel som kommer från att ny kod ändrar hur nuvarande kod fungerar underlättarautomatiserade tester.

D.7.4 När blir det värt att använda automatiserade tester istället för manuella?

Svaret på denna frågeställning är beroende på vilken nivå av automatisering man vill ha. Villman ha en hel automatiserad pipeline blir kostnaderna mindre än effekten om man har storaprojekt med kontinuerlig utveckling t.ex spel eller andra seriösa program. Vill man dock baraha det simpla Git-skriptet är kostnaderna mindre än effekten på nästan alla projekt.

61

E Anton Orö: En Jämförelse avOlika Klassificerare i OpenCVsBibliotek

E.1 Inledning

I denna sektion beskrivs syftet samt motiveringen bakom rapporten.

E.1.1 Syfte

I dagsläget är bildigenkänning i realtid med klassificerare samt maskininlärning väldigtaktuellt inom ett flertal områden. Bland annat används det inom bilindustrin för automatiskdetektion av andra bilar eller för att detektera diverse objekt i realtid samt detektion avansikten för upplåsning av mobiltelefoner eller datorer.

Ett väldigt populärt och effektivt sätt att göra detta är att skapa en så kallad "Cascadeclassifier", i fortsättningen kallad kaskadklassificerare. Detta är även vad som har använtsi skapandet av "TrackApp". Bland kaskadklassificerare finns det framförallt två olika typerav klassificerare som används inom mobilapplikationer, nämligen Haar (baserat på "Haar-wavelet"[70]) eller LBP (Local binary patterns).

En litteraturstudie samt experiment har utförts för att få en tydligare bild av metodernasfunktion i moderna system. Experimentet genomfördes genom att undersöka hur lång tiddet tog att träna de två klassificerarna samt hur väl de fungerade på ett program i realtid.För att ge läsaren en större förståelse görs även en djupare undersökningen i hur dessaklassificerare fungerar och tränas.

E.1.2 Motivering

Kaskadklassificering är inte det enda sättet att genomföra bildigenkänning på ett bra och ef-fektivt sätt, men det är ett av de enklare samt vanligare sätten. I och med att dessa klassifice-rare är så pass väl implementerade i OpenCV’s bibliotek samt väl optimerade för att fungeramed lite processorkraft så är det ett väldigt kraftfullt verktyg. Till exempel lyckades Violaoch Jones [15] skapa en ansiktsigenkännare redan år 2004 med endast en 700 MHz processor(detta kan jämföras med dagens cirka 4 GHz[15], det vill säga cirka 5 gånger snabbare). Menen tydlig jämförelse mellan de vanligaste metoderna i verktygen (Haar samt LBP) saknades.

62

E.2. Bakgrund

E.1.3 Frågeställning

1. Vilken klassificerare resulterar i bäst fps i en mobilapplikation?

2. Hur snabbt tränas de olika klassificerarna?

3. Hur fungerar OpenCV’s kaskadklassificerare?

E.1.4 Avgränsningar

Arbetet hanterar endast skillnaderna på dessa klassificerare inom biblioteket OpenCV. Dettabibliotek är mycket populärt och det mest självklara valet inom alla typer av enklare bild-behandling. Det finns även en hel del erfarenhet inom användandet av detta bibliotek frånprojektet. Samtliga undersökningar kommer att göras på samma dator samt mobilapplika-tion (TrackApp) för att minimera skillnaderna i kompileringstider samt träningstider.

E.2 Bakgrund

Maskininlärning samt bildbehandling är högst aktuella områden inom datavetenskap, därförblir kombinationen av dessa intressant att undersöka. Att undersöka skillnader i färdiga ochenkla ramverk som lekmän kan använda sig av är även aktuellt om man till exempel ska ut-föra mindre, enklare detektioner. Detta görs för att man ska kunna välja den bästa versionen,eller åtminstone kunna göra ett kvalificerat val.

E.3 Teori

För att kunna göra en djupare analys av området krävs det att den viktigaste teorin gås ige-nom noggrant. I detta kapitel presenteras de olika koncepten som används för att kunna klas-sificera bilder med både Haar samt LBP metoden. Samtliga metoder i detta avsnitt använderen gråskalad bild då detta är standarden för att använda OpenCV’s inbyggda funktioner.

E.3.1 Begrepp

• Positiva bilder är bilder där det tränade systemet bör upptäcka ett objekt.

• Negativa bilder är bilder där det tränade systemet inte bör upptäcka ett objekt.

E.3.2 Kännetecken

Första steget i att detektera ett objekt är att extrahera kännetecken för just det objektet. Dettagörs genom att en av två metoder.

Haar-kännetecken

Det första steget i att skapa en Haar kaskadklassificerare är att ta ut Haar-kännetecken. EttHaar-kännetecken är motstående rektanglar (se figur E.1) där summan av intensiteten hospixlarna summeras i varje region av dessa rektanglar och sedan beräknas skillnaden. Nuskapas det för varje bild samtliga kombinationer av rektanglar över alla skillnader i ljus påsamtliga pixlar, och detta leder till en hel del kännetecken (för en 24x24 bild fås cirka 160 000stkännetecken [15]). För att kunna göra detta utan att iterera över hela bilden ett flertal gångerför att hitta nästa pixelvärde används något som kallas integrerade bilder.

63

E.3. Teori

Figur E.1: Haar-kännetecken rektanglar [71]

Local Binary Pattern kännetecken

Ett alternativ till Haar-kännetecken är LBP-kännetecken. Metoden för att extrahera dessakännetecken kan delas upp i sex olika steg.

Steg ett är att dela in bilden i kvadrater om till exempel 3x3 pixlar. I steg två så jämförsmitten-pixeln mot de åtta pixlarna runtomkring denna. Om deras värden är större än ellerlika med mitten-pixelns värde så sätts värdena till 1, annars till 0 [72]. Tredje steget är attnumrera pixlarna motsols eller medsols utifrån mitten-pixeln. Dessa pixlar får alltså ettnummer mellan 0-7. Steg fyra är att föra in värdena för dessa i ordning baserat på derasnummer i en lista, det vill säga en lista med åtta element kommer att erhållas. Sedan bytsvärdet av mitten-pixeln mot det binära värdet som listan motsvarar. Steg fem är sedan attgöra detta för varje 3x3 pixelområde. Sista steget, steg sex är att skapa ett histogram (ettmått på distributionen av numerisk data) över den nya erhållna bilden. Eftersom ett områdepå 3x3 pixlar kan innehålla 28 = 256 olika mönster så behöver histogrammet visa värdenmellan 0-255. Histogrammet bildar känneteckens-vektorer för objektet som kan användas förspårning av objekt.

E.3.3 Integrerade bilder

Integral bild är en datastruktur och algoritm för att på ett snabbt och effektivt sätt kunnasummera värdena av ett rutnät, i detta fall det rutnät som ska användas för summering avrektanglar. Algoritmen fungerar så att värdet i någon pixel med koordinaterna (x,y) kan be-räknas som summan av alla pixlar ovanför och till vänster om (x,y).

ii(x, y) =ÿ

x1ă=x,y1ă=y

i(x1, y1)

där ii(x,y) är integral bilden och i(x’,y’) är originalbilden. Detta ger att hela integral bildenkan färdigställas genom att gå igenom bilden endast en gång.

Figur E.2 är ett exempel på hur resultattabellen kan se ut efter en summering av integralbilden. I denna figur så visar bild 1 i figur (a) hur en bild kan se ut innan summeringen ochbild 2 visar hur det kan se ut efter. Figur (b) visar här ett exempel på hur man kan beräknavilken rektangel som helst på endast fyra operationer [71].

64

E.3. Teori

(a) Summerad area tableux [73] (b) Exempel på beräkning [73]

Figur E.2: Resultatet av summerad area tableux

Figur E.3: Kaskadklassificerare

E.3.4 AdaBoost

Om ett system får ett flertal positiva och negativa bilder så kan ett flertal olika maskininlär-ningsmetoder användas för att systemet ska lära sig en klassifikationsfunktion. I den varian-ten av Haar-klassifikation samt LBP som används i OpenCV så används en metod som kallasAdaBoost, både för att välja endast några få kännetecken samt för att träna klassificeraren [15].

AdaBoost används i denna metod för att sålla ut de kännetecken som räcker för att klassi-ficera bilden. Som det stod i tidigare kapitel så finns det på en 24x24 bild cirka 160 000 styckenkännetecken, och detta är för många för att kunna göra beräkningar snabbt. Det AdaBoost görför att ta bort onödiga kännetecken är att den letar efter det kännetecken i bilden som bästsärskiljer en positiv bild från en negativ bild. Det vill säga att i varje bild så går funktionenigenom varje kännetecken och hittar det optimala tröskelvärdet så en minimal mängd exem-pel blir felklassificerade. På detta sätt kan cirka 160 000 kännetecken minimeras ner till endast100-6000 stycken.

E.3.5 Kaskadklassificerare

Kaskadklassificera betyder inom området maskininlärning att man använder sig av en sam-ling av ett flertal olika klassificerare. Detta leder i de flesta fall till bättre resultat när detkommer till att förutsäga var objekt är samt snabbare beräkningstider. Detta fungerar så attresultatet från föregående klassificerare används som indata till nästa klassificerare.

Eftersom majoriteten av bilder inte innehåller det objekt som letas efter så är det onödigtatt leta efter alla kännetecken i alla områden. Det är här kaskadklassificerare används i denna

65

E.4. Metod

metod. I figur E.3 syns hur detta fungerar. Istället för att kontrollera alla cirka 6000 kännetec-ken på en gång så delas dessa kännetecken upp i olika klassificerare. Här innehåller de förstastegen av klassificerare oftast väldigt få kännetecken (första steget cirka ett kännetecken, and-ra steget cirka fem, tredje steget cirka tio osv.) för att snabbt och effektivt kunna avgöra om ettområde innehåller ett objekt eller inte. Så fort ett kännetecken inte hittas så förkastas områ-det. Om området tar sig igenom alla de olika klassificerarna så anses detta område innehållarätt objekt.

E.4 Metod

För att kunna svara på frågeställningarna så har information hämtats från litteratur samt tidi-gare undersökningar inom området. En sammanställning av dessa publikationer har använtsför presenterandet av teoridelen. För att besvara frågeställningar rörande skillnader i hurklassificerare tränas samt hastigheterna för att dessa ska tränas så har framförallt experimentutförts.

E.4.1 Teori

En stor del av denna undersökning går ut på att ta fram en djupare kunskap i hur dessainbyggda funktioner fungerar. För att göra detta har huvudsakligen publicerad forskningundersökts. Framförallt har rapporterna för de ursprungliga metoderna för Haar-metodenanalyserats [15].

E.4.2 Informationsinsamling

Informationen hämtas bland annat via sökning i "Google Scholar" som är ett sökverktyg därendast officiella publikationer finns. Här har bland annat söksträngar som "Viola and Jones Ca-scade" samt "Cascade classifier comparison" använts. Resterande information hämtas från Open-CVs egna hemsida [74] samt olika bloggliknande hemsidor.

E.4.3 Experiment

För att experimentdatan skall vara tillförlitlig så ska dessa utföras i en så kontrollerad miljösom möjligt. För att åstadkomma detta så skall samtliga experiment göras på Linköpings Uni-versitets datorer. Dessa datorer är likadana och bör prestera likadant, så att ingen variation ihårdvara eller liknande bör störa resultaten.

E.5 Resultat

Här presenteras de resultat som producerats. Resultaten innefattar resultaten av fps samt entabell med olika körtider för olika mängder av data. Under rubriken Diskussion så diskuterasdessa vidare.

E.5.1 FPS i TrackApp

Här användes klassificerare som hade tränats på 1000 positiva samt 3000 negativa bilder.Resultaten blev att det inte blev någon skillnad i antal bilder per sekund (FPS) som telefo-nen klarade av. Den telefonen som användes var en telefon med 6 GB RAM samt 2,45 GHzprocessor. I samtliga miljöer erhölls cirka 15 fps.

E.5.2 Träningshastigheter

Nedan är en tabell för resultaten för de olika träningsdatan.

66

E.6. Diskussion

Tabell E.1: LBP-metoden

Antal positiva Antal negativa Tid125 375 00:02:33250 750 00:08:19500 1500 00:29:42

1000 3000 02:48:00

Tabell E.2: Haar-metoden

Antal positiva Antal negativa Tid125 375 00:21:03250 750 00:26:21500 1500 01:22:15

1000 3000 05:57:00

Figur E.4: Kaskadklassificerare träningsdata

E.6 Diskussion

Bildigenkänning är något som många finner intressant men ganska svårt. Denna rapporthoppas jag gett läsaren en bra översikt av några utav OpenCV’s metoder samt vilken avdessa som passar för olika situationer.

E.6.1 Resultat

Den experimentella delen hade kunnat utföras på ett bättre sätt. Då det tar en väldigt långtid att ta fram bilder för klassificerarna att träna på, samt tid för själva träningen, så hannej så många experiment utföras. Detta leder till att denna del endast är relevant för fall därfå positiva och negativa bilder finns. Dock kan man tydligt se att LBP ger mycket snabba-re träningstider, och även att skillnader i träningstider kommer att öka ju mer träningsdataman har. Detta har bra stöd i tidigare studier, bland annat den av L. Zhang et al [75]. Vidanvändning av de olika klassificerarna i TrackApp så märktes inte heller några större skill-

67

E.7. Slutsatser

nader vilket är logiskt då OpenCV behandlar resultatet från träningen på samma sätt vidimplementation i en applikation.

E.6.2 Metod

Metoden som togs fram för att presentera tillförlitliga resultat har framförallt bestått av enlitteraturundersökning samt några experiment.

Den litterära undersökningen fungerade mycket bra, då samtliga källor var publicerade,tillförlitliga artiklar och informationen var lättillgänglig. Relevanta publiceringar så somViola och Jones artikel samt OpenCV’s egna hemsida gav stor insikt i hur metoderna fun-gerade samt vad skillnaderna är. Bland referenserna finns även en del länkar till diverseWikipedia-sidor. För de artiklar som har använts från Wikipedia har källor och referenserkontrollerats för att säkerställa att det som står är korrekt.

Den experimentella delen var mycket tidskrävande. Detta gjorde att antalet experimentinte var tillräckligt många för att ge bra resultat. Dock har jag kontrollerat att mina resultatstämmer överens med tidigare gjorda mätningar. Även värt att nämna är att den vanligas-te metoden för att mäta prestandan hos bildanalys verktyg är just genom experimentellaundersökningar.

E.7 Slutsatser

I detta avsnitt presenteras slutsatser baserade på resultaten samt frågeställningarna besvaras.

E.7.1 Hur snabbt tränas de olika klassificerarna?

Det som syns tydligt utifrån resultaten är att LBP är snabbare. Detta är på grund av denextrema mängd av kännetecken som Haar-metoden genererar. Vid användning av de olikametoderna i applikationen TrackApp så märktes ingen större skillnad, detta kan dock beropå att det objektet inte var så unikt. Tidigare forskning ger stöd för dessa resultat. Dock visartidigare forskning på att vid små datamängder så ger Haar-kännetecken bäst detektion pågrund av att fler kännetecken tas ut [75].

E.7.2 Vilken klassificerare resulterar i bäst fps i en mobilapplikation?

När det kommer till antal bilder per sekunder som erhölls med de olika metoderna så är detingen överraskning att de båda gav samma resultat. Detta beror förmodligen på att OpenCV’sinbyggda funktioner hanterar de vektorer som genereras av träningen av klassificeraren påsamma sätt.

E.7.3 Hur fungerar OpenCV’s kaskadklassificerare?

För att besvara frågan kring hur OpenCV’s kaskadklassificerare fungerar så beskrevs helahändelseförloppet för dessa ingående i Teori-delen av denna rapport. Här kan man se attprocessen består av flera olika moment där maskininlärning används för att förbättra proces-sen med att välja ut bra kännetecken samt för att identifiera objekt.

68

F Frågeformulär

Figur F.1: Frågeformulärets inledning.

Figur F.2: Fråga 1.

69

Figur F.3: Fråga 2.

Figur F.4: Fråga 3.

Figur F.5: Fråga 4.

70

Figur F.6: Fråga 5.

Figur F.7: Fråga 6.

Figur F.8: Fråga 7.

71

Litteratur

[1] Image Systems Motion Analysis - About. 2019. URL: http://www.imagesystems.se/about/ (hämtad 2019-03-09).

[2] Projektmodellen Lips. Nov. 2016. URL: http : / / lips . isy . liu . se/ (hämtad2019-05-18).

[3] Scrum Website. 2019. URL: https://www.scrum.org/ (hämtad 2019-04-01).

[4] Crisp. Kanban. 2009. URL: https://www.crisp.se/gratis-material-och-guider/kanban (hämtad 2019-05-06).

[5] Android Studios Hemsida. 2019. URL: https://developer.android.com/studio/intro (hämtad 2019-05-06).

[6] OpenCV Website. 2019. URL: https://opencv.org/ (hämtad 2019-04-01).

[7] Trello hemsida. 2019. URL: https://trello.com/ (hämtad 2019-04-03).

[8] Gits Hemsida. 2019. URL: https://git-scm.com/about (hämtad 2019-04-24).

[9] GitLab hemsida. 2019. URL: https://about.gitlab.com/ (hämtad 2019-04-03).

[10] Slack hemsida. 2019. URL: https://slack.com/ (hämtad 2019-04-03).

[11] Latex hemsida. 2019. URL: https : / / www . latex - project . org/ (hämtad2019-04-03).

[12] Overleaf hemsida. 2019. URL: https://www.overleaf.com/ (hämtad 2019-04-03).

[13] Google Drive hemsida. 2019. URL: https://www.drive.google.com/ (hämtad2019-04-03).

[14] MPAndroidChart GitHub. 2019. URL: https : / / github . com / PhilJay /MPAndroidChart (hämtad 2019-04-11).

[15] P. Viola och M. Jones. ”Rapid Object Detection Using a Boosted Cascade of SimpleFeatures”. I: IEEE Computer Society Conference on Computer Vision and Pattern Recognition.Kauai, HI, USA, dec. 2001, s. 511–518. DOI: https://dl.acm.org/citation.cfm?doid=358669.358692.

[16] AAKent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunning-ham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, JonKern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherlandoch Dave Thomas. Manifesto for Agile Software Development. 2001. URL: https : / /agilemanifesto.org (hämtad 2019-03-05).

72

Litteratur

[17] David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business.Blue Hole Press, 2010.

[18] ”IEEE Std 830-1998”. I: IEEE Recommended Practice for Software Requirements Specifica-tions (1998).

[19] GIMP THE GNU Image Manipulation Program. 2019. URL: https://www.gimp.org/(hämtad 2019-03-05).

[20] Cascade Classifier Training. 2019. URL: https://docs.opencv.org/trunk/dc/d88/tutorial_traincascade.html (hämtad 2019-05-06).

[21] OpenGL Overview. 2019. URL: https : / / www . opengl . org / about/ (hämtad2019-04-15).

[22] Charts for Android [closed]. 2019. URL: https://stackoverflow.com/questions/9741300/charts-for-android (hämtad 2019-04-15).

[23] Christoph Becker & Stefanie Betz & Ruzanna Chitchyan & Leticia Duboc & SteveM. Easterbrook & Birgit Penzenstadler & Norbet Seyff & Colin C. Venters. ”Require-ments: The Key to Sustainability”. I: IEEE Software 33.1 (2015), s. 56–65. DOI: https://ieeexplore.ieee.org/document/7325195.

[24] L. Da Vinci. Nattvarden. [Muralmålning]. Milano, Santa Maria delle Grazie. 1495-1498.

[25] Boston Museum of Science. Da Vinci the artist. 2019. URL: https://www.mos.org/leonardo/artist (hämtad 2019-05-03).

[26] Lillholmsskolans Bildakademi. Centralperspektiv. 2019. URL: http : / /lillholmsbild.weebly.com/centralperspektiv.html (hämtad 2019-04-20).

[27] John Wesley Young. PROJECTIVE GEOMETRY. Vol. 4. Chicago, Illinois USA: OpenCourt Publishing Company, 1930.

[28] H Christopher Longuet-Higgins. ”A Computer Alorithm for Reconstructing a Scenefrom Two Projections”. I: Nature AA 293 (5828 sept. 1981), s. 133–135.

[29] Epipolar geometry. Febr. 2019. URL: https : / / en . wikipedia . org / wiki /Epipolar_geometry (hämtad 2019-05-16).

[30] M. N. Armstrong. Self-Calibration from Image Sequences. 1996. URL: http : / / www .robots.ox.ac.uk/~vgg/publications-new/Public/1996/Armstrong96a/armstrong96a.pdf (hämtad 2019-05-04).

[31] Martin A. Fischler & Robert C. Bolles. ”Random Sample Consensus: A Paradigm forModel Fitting with Applications to Image Analysis and Automated Cartography”. I:Communications of the ACM 24.6 (1981), s. 381–395. DOI: https://dl.acm.org/citation.cfm?doid=358669.358692.

[32] Camera calibration guidelines. Mars 2018. URL: https://pgaleone.eu/computer-vision / 2018 / 03 / 04 / camera - calibration - guidelines/ (hämtad2019-05-16).

[33] Lawrence Chung, Brian Nixon, Eric Yu och John Mylopoulos. Non-Functional Require-ments in Software Engineering. Kluwer Academic Publishers, 2000.

[34] Merlin Dorfman. ”Requirements Engineering”. I: Software Requirements Engineering.2. utg. IEEE Computer Society Press, 1997. Kap. 1, s. 7–22.

[35] A. Davis, S. Overmyer, K. Jordan, J. Caruso, F. Dandashi, A. Dinh, G. Kincaid, G. Le-deboer, P. Reynolds, P. Sitaram, A. Ta och M. Theofanos. ”Identifying and MeasuringQuality in a Software Requirement Specification”. I: Software Requirements Engineering.2. utg. IEEE Computer Society Press, 1997. Kap. 3, s. 164–175.

73

Litteratur

[36] L. López, J. Partanen, P. Rodríguez och S. Martínez-Fernández. ”How Practitioners Ma-nage Quality Requirements in Rapid Software Development: A Survey”. I: IEEE 1stInternational Workshop on Quality Requirements in Agile Projects (QuaRAP). Banff, AB,Canada, aug. 2018, s. 14–17.

[37] ISTQB. Worldwide Software Testing Practices Report. 2017-2018.

[38] Richard Thayer och Merlin Dorfman. Software Requirements Engineering. 2. utg. IEEEComputer Society Press, 1997.

[39] Ian Sommerville och Pete Sawyer. Requirements Engineering - A good practice guide. JohnWiley & Sons, 1997.

[40] ISO/IEC/IEEE 24765. Systems and Software Engineering — Vocabulary. 2017.

[41] IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. 1990.

[42] J. Eckhardt, A. Vogelsang och D. Méndez Fernández. ”Are ’non-functional’ requi-rements really non-functional?: an investigation of non-functional requirements inpractice”. I: 38th International Conference on Software Engineering (ICSE). Austin, TX,USA, maj 2016, s. 832–842.

[43] M. Glinz. ”On Non-Functional Requirements”. I: 15th IEEE International RequirementsEngineering Conference (RE 2007). Delhi, India, okt. 2007, s. 21–26.

[44] SSTB. Ordlista Engelsk/Svensk version 2018-11-01. 2018.

[45] D. Ameller, C. Ayala, J. Cabot och X. Franch. ”How do Software Architects ConsiderNon-Functional Requirements: An Exploratory Study”. I: 20th IEEE International Requi-rements Engineering Conference (RE). Chicago, IL, USA, sept. 2012, s. 41–50.

[46] V. Bajpai och R. P. Gorthi. ”On non-functional requirements: A survey”. I: 2012 IEEEStudents’ Conference on Electrical, Electronics and Computer Science. Bhopal, India, mars2012, s. 1–4.

[47] S. Ullah, M. Iqbal och A. M. Khan. ”A Survey on Issues in Non-Functional Require-ments Elicitation”. I: International Conference on Computer Networks and Information Tech-nology. Abbottabad, Pakistan, juli 2011, s. 333–340.

[48] M. Umar och N. A. Khan. ”Analyzing Non-Functional Requirements (NFRs) for soft-ware development”. I: IEEE 2nd International Conference on Software Engineering and Ser-vice Science. Beijing, China, juli 2011, s. 675–678.

[49] K. Khatter och A. Kalia. ”Impact of Non-functional Requirements on RequirementsEvolution”. I: 6th International Conference on Emerging Trends in Engineering and Techno-logy. Nagpur, India, dec. 2013, s. 61–68.

[50] L.B. Philips, A. Aurum och R. B. Svensson. ”Managing Software Quality Require-ments”. I: 38th Euromicro Conference on Software Engineering and Advanced Applications.Cesme, Izmir, Turkey, sept. 2012, s. 349–356.

[51] Seymour Papert. The Summer Vision Project. 2019. URL: http://hdl.handle.net/1721.1/6125 (hämtad 2019-05-02).

[52] SVT. Stor ökning av övervakningskameror. 2017. URL: https : / / www . svt . se /nyheter / inrikes / stor - okning - av - overvakningskameror (hämtad2019-03-12).

[53] Markus Lahtinen. Allmänhetens uppfattning kring användandet av övervakningskamerorpå gator och torg, augusti 2017. 2017. URL: http://lup.lub.lu.se/record/aea1a067-4942-41ea-802a-3f4537bc550c (hämtad 2019-05-01).

[54] Marie Alpman. ”Så ska datorn lära sig att hitta terrorister”. I: Forskning och Framsteg(2017). URL: https://fof.se/tidning/2017/8/artikel/sa-ska-datorn-lara-sig-att-hitta-terrorister.

74

Litteratur

[55] Greg Bear. ”Future Tense: Little brother Is watching”. I: Communications of the ACM 53.9(2010), s. 112–111. DOI: https://dl.acm.org/citation.cfm?doid=1810891.1810918.

[56] Walter Kirin. Little Brother Is Watching. 2010. URL: https://www.nytimes.com/2010/10/17/magazine/17FOB-WWLN-t.html (hämtad 2019-05-01).

[57] Erik Grevholm. Fungerar kamerabevakning brottsförebyggande? Resultat från en metastu-die samt reflektioner om metoder och resultat. 2018. URL: https : / / www . bra .se / publikationer / arkiv / publikationer / 2018 - 12 - 17 - fungerar -kamerabevakning-brottsforebyggande.html (hämtad 2019-05-02).

[58] Matthew P. J. Ashby. ”The Value of CCTV Surveillance Cameras as an InvestigativeTool: An Empirical Analysis”. I: European Journal on Criminal Policy and Research 23.3(2017), s. 441–459. DOI: https://doi.org/10.1007/s10610-017-9341-6.

[59] Jack Lantz. Polisen: Kameraövervakning har gett goda resultat. 2017. URL: https : / /sverigesradio.se/sida/artikel.aspx?programid=83&artikel=6742109(hämtad 2019-05-05).

[60] Lynn Parramore. The Filter Bubble. 2010. URL: https://www.theatlantic.com/daily- dish/archive/2010/10/the- filter- bubble/181427/ (hämtad2019-04-17).

[61] Välkommen till Linköpings universitetsbibliotek. URL: https://liu.se/biblioteket(hämtad 2019-04-17).

[62] The Daily Dish. URL: https://www.theatlantic.com/author/daily-dish/(hämtad 2019-04-18).

[63] Jagge. Myter, problem och tankar om testautomatisering. 2019. URL: http : / / www .testzonen.se/?p=3225 (hämtad 2019-05-08).

[64] Amir Ghahrai. Common Myths of Test Automation. 2019. URL: https : / / www .testingexcellence . com / common - myths - test - automation/ (hämtad2019-05-08).

[65] Sascha Just & Kim Herzig & Jacek Czerwonka & Brendan Murphy. ”Switching to Git:the Good, the Bad, and the Ugly”. I: 2016, s. 400–411. DOI: https://ieeexplore.ieee.org/document/7774538.

[66] Lars Danielsson. Därför är automatiserade tester nyckeln till kontinuerliga leveranser avmjukvara. 2019. URL: https : / / techworld . idg . se / 2 . 2524 / 1 . 655426 /automatiserade-tester-mjukvara (hämtad 2019-05-07).

[67] Robert Gistvik. Testautomatisering - det bra, det dåliga och den stora frågan. 2019.URL: https : / / www . frontit . se / inspiration - kunskap / artiklar /testautomatisering- det- bra- det- daliga- och- den- stora- fragan/(hämtad 2019-05-07).

[68] Elin Marsell Klaminder. ”Automatiska tester Vilka är faktorerna till framgång vid infö-randet och användandet?” Examensarb. Mittuniversitetet, 2015.

[69] Mirjami Olsson och Erik Norman Uhlin. ”Testverktyg för test av mobila applikationer”.Examensarb. Högskolan Dalarna, 2015.

[70] Eric J. Stollnitz & Tony D. DeRose & David H. Salesin. Wavelets for Computer Graphics:A Primer. Tekn. rapport. 1994.

[71] OpenCV. Face Detection using Haar Cascades. 2018. URL: https://docs.opencv.org / 4 . 0 . 1 / d7 / d8b / tutorial _ py _ face _ detection . html (hämtad2019-03-12).

75

Litteratur

[72] Local Binary Patterns with Python & OpenCV. 2015. URL: https : / / www .pyimagesearch.com/2015/12/07/local-binary-patterns-with-python-opencv/ (hämtad 2019-04-04).

[73] Wikipedia. Summed-area table. 2019. URL: https://en.wikipedia.org/wiki/Summed-area_table (hämtad 2019-03-12).

[74] OpenCV. OpenCV Website. 2019. URL: https://opencv.org/ (hämtad 2019-04-01).

[75] L. Zhang, R. Chu, S. Xiang, S. Liao och S. Z. Li. ”Face Detection Based on Multi-BlockLBP Representation”. I: International Conference ICB. Seoul, Korea, aug. 2007, s. 11–18.

76