Automatisk taggning av video

(1)

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2018 | LIU-IDA/LITH-EX-G--18/009--SE

Automatisk taggning av video

Automatic tagging of video

Aron Gosch

Niklas Granander

Oliver Haberler

Fabian Haugen

Sabina Serra

Rickard Torén

Rasmus Viitanen

Handledare : Carl Brage Examinator : Kristian Sandahl

(2)

Upphovsrätt

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

Copyright

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

(3)

Sammanfattning

Denna rapport behandlar utvecklingen av tagg-bearbetningssystemet Video Analyser and Tag Generator (VATG). Projektet har utförts som en del av kursen TDDD96 - Kandidatarbete i programvaruutveckling på Linköpings universitet i en grupp på sju personer och på upp-drag av företaget Flowplayer. Syftet med projektet har varit att undersöka hur befintliga tjänster såsom Amazon Web Services kan användas i ett videoanalyssystem med målet att ta fram en lösning för automatiserad taggning av videoklipp. Resultatet av projektet blev en mikrotjänst som använder sig av Amazon Rekognition, en tjänst för objektidentifiering i videoklipp och bilder, och sedan bearbetar resultatet för att skapa en beskrivande samling etiketter för videoklipp. Det visade sig att etiketter genererade av VATG i slutändan var bättre på att beskriva videoklipp än etiketter som enbart kom från Amazon Rekognition.

(4)

Författarnas tack

Projektgruppen skulle vilja tacka Björn Gustafsson, Dan Wester och Henrik Lovén på Flowplayer för samarbetet i genomförandet av detta projekt. Vi vill även tacka vår hand-ledare Carl Brage och examinator Kristian Sandahl för deras stöd under arbetets gång.

(5)

Innehåll

Sammanfattning iii Författarnas tack iv Innehåll v Figurer xi Tabeller xii Definitioner xiv 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Målsättningar . . . 1 1.3 Frågeställningar . . . 2 1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Projektgruppens bakgrund . . . 3 2.1.1 Förbättringspunkter . . . 4 2.1.2 Tidigare erfarenheter . . . 4 3 Teori 5 3.1 Verktyg . . . 5 3.1.1 Git . . . 5 3.1.2 GitHub . . . 5 3.1.3 IntelliJ IDEA . . . 5 3.1.4 Trello . . . 6 3.1.5 Slack . . . 6 3.1.6 Gradle . . . 6 3.1.7 JUnit . . . 6 3.1.8 Travis CI . . . 6 3.1.9 Wordnet . . . 6 3.1.10 Word2Vec . . . 6 3.1.11 Blackboard . . . 7

3.2 Amazon Web Services . . . 7

3.2.1 DynamoDB . . . 7 3.2.2 S3 . . . 7 3.2.3 Lambda . . . 7 3.2.4 SNS . . . 7 3.2.5 SQS . . . 7 3.2.6 Amazon Rekognition . . . 8

(6)

3.3 Scrum . . . 9 3.3.1 Roller . . . 9 4 Metod 11 4.1 Arbetsmetod . . . 11 4.1.1 Projektorganisation . . . 11 4.1.2 Tidigare erfarenheter . . . 12 4.1.3 Utbildning . . . 12 4.1.4 Dokument . . . 13

4.1.5 Möten och kommunikation . . . 14

4.1.6 Scrum . . . 14

4.1.7 Metod för att fånga erfarenheter . . . 14

4.2 Utvecklingsmetod . . . 14 4.2.1 Kodhantering . . . 14 4.2.2 Utvecklingsmiljö . . . 15 4.2.3 Testmiljö . . . 15 4.2.4 Produktionsmiljö . . . 16 4.2.5 Faser . . . 16 5 Resultat 18 5.1 Förstudie . . . 18 5.1.1 Undersökning av API:er . . . 18

5.1.2 Undersökning av lösning för filtrering av taggar . . . 20

5.1.3 Undersökning av lösning för kategorisering av taggar . . . 20

5.2 Utveckling . . . 20

5.3 Resulterande funktionalitet och systembeskrivning . . . 20

5.3.1 Systembeskrivning . . . 21

5.3.2 Huvudfunktioner . . . 22

5.3.3 Resultat från körning . . . 23

5.3.4 Ej uppfyllda funktionella krav . . . 24

5.4 Tester . . . 24

5.4.1 Enhetstester, integrationstester samt installationstester . . . 24

5.4.2 Kvalitetstester . . . 24

5.4.3 Acceptanstest . . . 26

5.5 Nya erfarenheter . . . 27

5.6 Översikt av individuella bidrag . . . 28

6 Diskussion 30 6.1 Metod . . . 30

6.1.1 Utvecklingsmetod . . . 30

6.1.2 Möten och kommunikation . . . 30

6.1.3 Kodhantering . . . 31

6.1.4 Utvecklingsmiljö . . . 31

6.1.5 Tester . . . 31

6.1.6 Källkritik . . . 32

6.2 Arbetet i ett större omfång . . . 32

6.2.1 Socialt sammanhang . . . 32 6.2.2 Etiskt sammanhang . . . 32 6.2.3 Miljöaspekter . . . 33 6.3 Resultat . . . 33 6.3.1 Värde för kunden . . . 33 6.3.2 Systemanatomi . . . 34 6.3.3 Erfarenhetsfångst . . . 34

(7)

6.3.4 Kvalitetstest . . . 34

6.3.5 Begränsningar i Rekognition . . . 35

7 Slutsatser 36 A Aron Gosch: Ordigenkänning - en jämförelse mellan wordnet och word2vec 38 A.1 Inledning . . . 38

A.1.1 Syfte och mål . . . 38

A.1.2 Frågeställningar . . . 38 A.1.3 Avgränsningar . . . 39 A.2 Bakgrund . . . 39 A.3 Teori . . . 39 A.3.1 Användningsområden . . . 39 A.3.2 Wordnet-distans . . . 39 A.3.3 Vektormodeller . . . 41 A.4 Metod . . . 42 A.5 Resultat . . . 43 A.6 Diskussion . . . 45 A.6.1 Metod . . . 45 A.6.2 Körresultat . . . 45 A.6.3 Prestanda . . . 45 A.6.4 Utvecklingsmöjligheter . . . 46 A.7 Slutsats . . . 46

B Niklas Granander: Implementation, begränsningar och ekonomi med ”serverless computing” 47 B.1 Inledning . . . 47 B.1.1 Syfte och mål . . . 47 B.1.2 Frågeställningar . . . 47 B.1.3 Avgränsningar . . . 48 B.2 Bakgrund . . . 48 B.3 Teori . . . 48 B.3.1 *aaS - as a Service . . . 49

B.3.2 AWS SAM Local . . . 50

B.4 Metod . . . 50

B.5 Resultat . . . 50

B.5.1 Introduktion till FaaS - Function as a Service . . . 50

B.5.2 Användning . . . 51 B.5.3 Invokation . . . 52 B.5.4 Begränsningar . . . 52 B.6 Diskussion . . . 55 B.6.1 Metod . . . 55 B.6.2 Resultat . . . 56 B.7 Slutsatser . . . 56

C Oliver Haberler: Amazon Rekognition eller Google Vision 58 C.1 Inledning . . . 58 C.1.1 Syfte och mål . . . 58 C.1.2 Frågeställningar . . . 58 C.1.3 Avgränsningar . . . 59 C.2 Bakgrund . . . 59 C.3 Teori . . . 59 C.3.1 Objektigenkänning . . . 59

(8)

C.3.2 Hur det fungerar . . . 60 C.4 Metod . . . 61 C.5 Resultat . . . 61 C.5.1 Tjänster . . . 61 C.5.2 Hållbarhet . . . 62 C.5.3 Taggar . . . 62 C.6 Diskussion . . . 64 C.6.1 Metod . . . 64 C.6.2 Resultat . . . 64 C.7 Slutsats . . . 65

D Fabian Haugen: Kontextförståelse vid analys av videodata och aktuella utmaningar 67 D.1 Inledning . . . 67 D.1.1 Syfte och mål . . . 67 D.1.2 Frågeställningar . . . 67 D.1.3 Avgränsningar . . . 67 D.2 Bakgrund . . . 68 D.3 Teori . . . 68 D.3.1 Tonalitetsanalys . . . 68 D.3.2 Sammanfattning av video-/textdata . . . 68 D.3.3 RNN . . . 68 D.3.4 LSTM . . . 68 D.3.5 Ordsegmentering . . . 69 D.3.6 Oövervakade lösningsmetoder . . . 69 D.3.7 Yttranden . . . 69 D.4 Metod . . . 69 D.5 Resultat . . . 69 D.5.1 Videosummering . . . 69 D.5.2 Artikelsummering . . . 70 D.5.3 Tonalitetsanalys av videodata . . . 70 D.5.4 Tonalitetsanalys av textdata . . . 70 D.6 Diskussion . . . 70

D.6.1 Tonalitetsanalys med och utan videodata . . . 70

D.6.2 Skillnader mellan kontextanalys av text och videodata . . . 70

D.6.3 Begränsningar bland rådande lösningsmetoder . . . 71

D.6.4 Möjligheter för urval av höjdpunkter i videoklipp . . . 71

D.6.5 Metod . . . 71

D.7 Slutsats . . . 71

D.7.1 Skillnader vid behandling av video och text . . . 71

D.7.2 Möjligheter för framtagning av höjdpunkter . . . 71

D.7.3 Aktuella verktyg . . . 72

D.7.4 Förslag till vidare forskning . . . 72

E Sabina Serra: Analys av videoklipp med Amazon Rekognition Image istället för Amazon Rekognition Video 73 E.1 Inledning . . . 73

E.1.1 Syfte och mål . . . 73

E.1.2 Frågeställningar . . . 73

E.1.3 Avgränsningar . . . 73

E.2 Bakgrund . . . 74

E.3 Teori . . . 74

(9)

E.3.2 Bakgrundsinformation om stillbildsextrahering från videoklipp och

vi-deoanalys . . . 75

E.4 Metod . . . 76

E.4.1 Förstudie . . . 76

E.4.2 Praktisk undersökning av funktionen ”Label Detection” . . . 76

E.5 Resultat . . . 79

E.5.1 Kostnad . . . 79

E.5.2 Funktionen ”Label Detection” . . . 80

E.6 Diskussion . . . 82

E.6.1 Metod . . . 82

E.6.2 Resultat . . . 82

E.7 Slutsats . . . 83

F Rickard Torén: Funktionellt testande är marginellt frestande 85 F.1 Inledning . . . 85 F.1.1 Syfte . . . 85 F.1.2 Frågeställningar . . . 85 F.1.3 Avgränsningar . . . 86 F.2 Bakgrund . . . 86 F.3 Teori . . . 86 F.3.1 Funktionellt testande . . . 86 F.3.2 Testverktygen . . . 87 F.3.3 Vikten av testande . . . 87 F.4 Metod . . . 87 F.5 Resultat . . . 88 F.5.1 Gemensam funktionalitet . . . 88 F.5.2 Skild funktionalitet . . . 88 F.6 Diskussion . . . 90 F.6.1 Metod . . . 90 F.6.2 Tidsåtgång . . . 90 F.6.3 Påverkan på produkten . . . 91 F.7 Slutsats . . . 91

G Rasmus Viitanen: En jämförelse mellan dynamisk och statisk exekveringsord-ning av systemets analysfunktioner 93 G.1 Inledning . . . 93 G.1.1 Syfte och mål . . . 93 G.1.2 Frågeställningar . . . 93 G.1.3 Avgränsningar . . . 94 G.2 Bakgrund . . . 94 G.3 Teori . . . 94

G.3.1 Ett problem och dess delproblem . . . 94

G.3.2 Metriker för delproblem . . . 95 G.3.3 Statiska system . . . 95 G.3.4 Dynamiska system . . . 96 G.4 Metod . . . 96 G.5 Resultat . . . 97 G.5.1 Delproblem för VATG . . . 97 G.5.2 Förslag på sekvenser . . . 100

G.5.3 Tidsåtgång för implementation av ett blackboardsystem och analys-funktioner . . . 101

G.5.4 Exekveringsresultat . . . 102

(10)

G.6.1 Metod . . . 102

G.6.2 Resultat . . . 103

G.7 Slutsats . . . 104

G.7.1 Fördelar och nackdelar ur ett resultatperspektiv . . . 104

G.7.2 Fördelar och nackdelar ur ett implementationsperspektiv . . . 104

G.7.3 Vilken sekvens fungerar bäst för VATG? . . . 104

H Jämförelse av ARI och ARV 105 H.1 Video 1 . . . 105

H.2 Video 2 . . . 109

H.3 Video 3 . . . 114

(11)

Figurer

3.1 Ett exempel på hur en tagg kan se ut. . . 8

3.2 Videoprocessering i Amazon Rekognition . . . 9

3.3 Scrum-ramverket . . . 10

5.1 Översikt över systemets olika roller. . . 21

5.2 Översikt över vektoriserade ord med Word2Vec, med medelvärdet för punkterna markerat med ett kryss. De streckade cirklarna markerar ord som kan tas bort. . . 23

5.3 Ett exempel på hur resultatet från en körning av VATG kan se ut. . . 24

A.1 Översikt av hierarkisk struktur i Wordnet . . . 40

A.2 Översikt av WuPalmers-algoritm . . . 40

A.3 Vektorrepresentation av ett antal ord behandlade av Word2Vec . . . 41

A.4 Översikt av Cosinus-distans . . . 42

A.5 Körresultat för metoder i stapeldiagram . . . 44

A.6 Körresultat för metoder i linjediagram . . . 44

B.1 Användning av olika leverantörer av serverlösa plattformar. . . 48

B.2 IaaS-applikation: Exempel som använts i studie kring prestanda med Node.js . . . 54

B.3 FaaS-applikation: Exempel som skapats för denna undersökning . . . 54

B.4 Kostnad för invokationer vid 128 MB minnesallokering och 100 samtidiga körningar 55 C.1 Ett exempel på hur en tagg kan se ut . . . 60

C.2 Bild på en chihuahua och en muffin som körts genom Rekognition och Vision . . . 63

(12)

Tabeller

5.1 Taggar för en videointervju med kungen . . . 25

5.2 Taggar för ett sportreportage om amerikansk fotboll . . . 25

5.3 Taggar för ett nyhetsreportage om sagojul på Kolmården . . . 25

5.4 Resultat för en videointervju med kungen . . . 26

5.5 Resultat för ett sportreportage om amerikans fotboll . . . 26

5.6 Resultat för nyhetsreportage om sagojul på Kolmården . . . 26

A.1 Körresultat för metoder på ordpar . . . 43

A.2 Medelvärde för avvikelse av metoder på ordpar . . . 44

B.1 Körtidsmiljöer som stöds . . . 51

B.2 Begränsningar . . . 52

B.3 Prismodell för Lambda (per månad) . . . 53

B.4 Prismodell för GCF (per månad) . . . 54

C.1 Tabellen visar en lista över de tjänster som Rekognition och Vision erbjuder . . . . 62

C.2 Visar de taggar som genererades av respektive tjänst för bilderna i figur C.2 . . . . 63

E.1 Visar vilka funktioner som finns hos ARI och ARV . . . 75

E.2 Klippen som analyserades . . . 76

E.3 Kostnaden för ARI . . . 79

E.4 Tabell över när ARI blir lika kostsamt som ARV . . . 80

E.5 Sammanställning av tidsstämpelresultatet . . . 81

E.6 Sammanställning av differensen mellan tillförlitlighetsresultaten . . . 81

E.7 Sammanställning av antalet etiketter från ARI och ARV . . . 81

E.8 Etiketterna som genererades i ARV men inte i ARI . . . 82

F.1 Funktionalitet i JUnit och TestNG . . . 89

G.1 Systemet VATG och dess delproblem för tagg-analys . . . 97

G.2 Systemets analysfunktioner och dess invärtes påverkan, då delproblemet i kolum-nen exekveras före delproblemet för raden . . . 98

G.3 Analys enligt de metriker som finns presenterade i avsnitt G.3.2 . . . 99

G.4 Resultat från de olika exekveringssekvenserna . . . 102

G.5 De bästa resultaten utifrån projektgruppens åsikter . . . 102

H.1 Tidsstämpelresultatet för video 1 . . . 105

H.2 Differensen mellan tillförlitlighetsvärdena i video 1 . . . 107

H.3 Etiketterna som bara genererades i ARI . . . 107

H.4 Etiketterna som bara genererades i ARV . . . 109

(13)

H.10 Etiketterna som bara genererades i ARI . . . 118

(14)

Definitioner

• Tagg/Etikett – Ett ord som beskriver ett element i en video eller bild.

• VATG – Video Analyser and Tag Generator. Den produkt som tagits fram i projektet. • API – Application programming interface. Gränssnitt som beskriver hur en produkt

eller ett program kan användas.

• AWS – Amazon Web Services. Molntjänster från Amazon.

• Rekognition – En tjänst som kan analysera innehåll i både bilder och videor. Rekognition tillhandahålls av AWS.

• ARI – Amazon Rekognition Image. Rekognition med fokus på att analysera bilder. • ARV – Amazon Rekognition Video. Rekognition med fokus på att analysera videor. • S3 – Simple Storage Service. Molnbaserad lagringstjänst för filer hos AWS.

• Lambda – Händelsedriven molnbaserad plattform för serverlös teknik. Lambda tillhan-dahålls av AWS.

• SAM – Serverless Application Model. Molnbaserad model för dynamisk allokering av maskinresurser. SAM tillhandahålls av AWS.

• SNS – Simple Notification Service. En tjänst för att skicka notifikationer/medelanden från en tjänst eller produkt till en annan. SNS tillhandahålls av AWS.

• SQS – Simple Queue Service. Molnbaserat kösystem för meddelanden. Andra tjänster och produkter kan både hämta och köa medelanden till dessa köer. SQS tillhandahålls av AWS.

• Blackboard – System för att spara information och uppdatera denna iterativt genom ett antal analysfunktioner.

• Controller – Agent som schemalägger och manipulerar analysfunktioner som används i blackboard-systemet.

(15)

1 Introduktion

Denna rapport är skriven i samband med kursen TDDD96 - Kandidatprojekt i programvaru-utveckling vid Linköpings universitet. Rapporten beskriver ett kandidatprojekt som genom-fördes av sju civilingenjörsstudenter i data- och mjukvaruteknik under våren 2018. Kandi-datprojektet innefattade utveckling av tjänsten Video Analyzer and Tag Generator, som med befintliga verktyg för videoanalys analyserar samt genererar taggar till videoklipp, och leve-rerar dem till beställaren, företaget Flowplayer. Detta kapitel behandlar motivation och mål-sättningar för projektet, samt dess frågeställningar och avgränsningar.

1.1 Motivering

För att kunna sortera och söka bland stora mängder videodata krävs ett system för att skapa relevanta taggar till de filmer som behandlas i kundens system. I nuläget utförs detta huvud-sakligen manuellt, vilket leder till inkonsekvens i kvalité och omfång mellan de taggar som skapas av olika användare där motivation bakom val av taggar varierar [1]. Denna taggnings-process kan möjligtvis helt automatiseras med hjälp av tillgängliga ramverk för videoanalys; vi introducerar därför lösningen VATG - Video Analyzer And Tag Generator.

1.2 Målsättningar

Ett mål med denna rapport är att utreda hur ett större programvaruprojekt kan struktureras för att på bästa sätt uppnå de krav som en kund ställer. Detta utifrån arbete som inleds med sammanställning av en systemanatomi som sedan utvärderas med jämna mellanrum. Det är projektgruppens målsättning att efter avslutat arbete kunna dela med sig av de processrela-terade erfarenheter som kan vara av intresse för framtida utvecklare. Ett ytterligare mål är att utreda hur ett system för generering av videodata, ur ett tekniskt perspektiv, kan utformas.

(16)

1.3. Frågeställningar

1.3 Frågeställningar

Följande frågeställningar kommer behandlas i rapporten:

1. Hur kan VATG implementeras så att värde skapas för kunden?

2. Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara in-tressanta för framtida projekt?

3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? 4. Hur skulle en människa tagga ett videoklipp?

5. Går det att göra generaliseringar för att identifiera vad människor tycker är relevanta taggar för videoklipp?

6. Hur begränsas projektet av Amazon Rekognition?

1.4 Avgränsningar

Projektet som behandlas hade en tidsbudget på 400 timmar per person, det vill säga en total omfattning på 2 800 timmar. Projektarbetet har inte innefattat försök till lösning på problem som krävt egenutvecklade, specialiserade maskininlärningsverktyg. Projektet begränsades även till att bara undersöka Amazon Rekognition och Google Vision för videoanalys.

(17)

2 Bakgrund

Idag laddas enorma mängder video upp på internet. Företag som tillhandahåller videotjäns-ter har intresse av att effektivt kunna kategorisera, filtrera och söka bland videor för att er-bjuda sina användare en så bra upplevelse som möjligt. Projektets kund, Flowplayer, är ett företag som erbjuder en videospelare för webbsidor, samt en helhetslösning i form av en videoplattform och önskar således en lösning till detta problem. Idén med projektet är att au-tomatiskt kunna beskriva innehåll i de videoklipp som laddas upp till Flowplayers system. Värde skapas för Flowplayer genom att låta den enorma mängden videoklipp bli mer sök-bar, vilket underlättar hanteringen av en videodatabas för att exempelvis kategorisera eller söka efter specifika videor. Den nuvarande metoden för att beskriva videoinnehåll är att låta användare själva skriva beskrivningar till sina videoklipp. Denna typ av manuell taggning utförs ofta bristfälligt med få taggar och låg relevans till klipp. Detta projekt går därför pri-märt ut på att undersöka om taggningsprocessen kan automatiseras med hjälp av existerande video- och bildanalystjänster hos etablerade företag som Amazon eller Google. En sekundär frågeställning är att avgöra hur väl de fungerar samt kartlägga eventuella begränsningar hos dessa tjänster.

2.1 Projektgruppens bakgrund

Projektgruppen består av fyra datateknologer och tre mjukvaruteknologer. Projektet har ge-nomförts i kursen TDDD96 - Kandidatarbete i programvaruutveckling på Linköpings uni-versitet. Alla medlemmar har tidigare erfarenhet av att arbeta i projekt från andra kurser, datateknologerna i gruppen har läst kursen TSEA29 - Konstruktion med mikrodatorer medan mjukvaruteknologerna har läst kursen TDDD92 - Projekt i artificiell intelligens. I dessa kur-ser har gruppmedlemmarna fått erfarenhet av att arbeta med grupporganisation, dokument-skrivning och programmvaruutveckling. Ett flertal av medlemmarna i gruppen har även ge-nomfört mindre projektarbeten inom området för mjukvaruutveckling på egen fritid och i andra kurser på universitetet.

(18)

2.1. Projektgruppens bakgrund

2.1.1 Förbättringspunkter

Från tidigare projekt har medlemmarna tagit med sig ett antal saker som de skulle vilja för-bättra från tidigare projekt:

• Att sätta tydliga begränsningar och inte ha för stor omfattning på projektet.

• Upprätta en plan och riktlinjer tidigt för att se till att produkten håller en hög kvalité. • Att undvika plattformsberoende, till exempel till Linux eller Windows, som begränsar

utvecklingsmöjligheter.

• Etablera en gemensam kodstandard och struktur för kodbasen i projektet. • Testa mer och testa tidigare i produktionsmiljö.

• Tidigare feature-freeze och undvika ”sista-minuten-ändringar” för att se till att en stabil utgåva av produkten kan levereras.

• Ha en välorganiserad konfigurationshantering med separata grenar för utveckling och leverans.

• Kommunicera och uppdatera varandra samt visa hur det gått med olika aktiviteter i projektet.

• Undvika ”merge-hell”, det vill säga ha tydliga riktlinjer för hur uppladdning av ny kod ska hanteras med konfigurationshantering.

2.1.2 Tidigare erfarenheter

Från tidigare projekt har medlemmarna tagit med sig ett antal erfarenheter som de tycker är viktiga och skulle vilja använda sig av i detta projekt.

• Ordentlig projektplanering, milstolpar och många aktiviteter. • Tanke på kritisk väg och beroenden mellan aktiviteter.

• Genomarbetad arkitektur till systemet för att underlätta implementation

• Ständig kommunikation för att se till att samtliga medlemmar är med på vad som sker i projektet.

• Kunskapsdelning, till exempel workshops, för att se till att alla får den förståelse som behövs för att genomföra projektet.

• Enkel översikt över vilka aktiviteter som är klara och inte, samt hur mycket som kvar-står.

(19)

3 Teori

Kapitlet beskriver den teoretiska bakgrunden till projektet. Inledningsvis tas de verktyg som använts upp för att sedan övergå till Amazons olika molntjänster samt utvecklingsmetodik.

3.1 Verktyg

I denna sektion listas samtliga verktyg som använts under projektets gång.

3.1.1 Git

Git är ett verktyg för versionshantering av mjukvara. Systemet är ett distribuerat versions-hanteringssystem, vilket innebär att utvecklare skapar lokala kopior av hela projektarkivet istället för att bara hämta den senaste versionen av projektet. Med Git är det möjligt att job-ba enligt flera olika arbetsflöden, exempelvis är det vanligt att arbeta enligt ett centraliserat arbetsflöde. Centraliserat arbetsflöde innebär att det även finns en central kopia av projek-takrivet. Åtkomst till den centralt lagrade datan sker via ett klientprogram från användarens lokala arkiv, från vilket användaren kan hämta och utföra ändringar för att senare ladda upp till det centrala arkivet. Samtliga ändringar som utförs lagras och det är därför möjligt att gå tillbaka till tidigare versioner och se de modifieringar som gjorts i arkivet. [2]

3.1.2 GitHub

GitHub är en webbaserad tjänst som använder git för att versionshantera kod. Github kan bland annat användas för att lagra versionshanterad kod, genomföra kodgranskningar, före-slå och diskutera ändringar och mycket annat. [3]

3.1.3 IntelliJ IDEA

IntelliJ IDEA, eller kort IDEA, är en integrerad utvecklingsmiljö som utvecklas av företaget JetBrains. [4]

(20)

3.1. Verktyg

3.1.4 Trello

Trello är en webb-baserad applikation som används för att organisera och visualisera arbets-flöden. Verktyget använder en struktur med tavlor och listor för att organisera aktiviteter. Det kan liknas med att flytta ”post-it-lappar” på en aktivitetstavla med skillnaden att Trello er-bjuder mer funktionalitet, till exempel för att kommentera, tagga personer i ”post-it-lappar” och påminna dem om att aktiviteter ska utföras innan en viss tidpunkt. [5]

3.1.5 Slack

Slack är en kommunikationsplattform för mobil och dator. Namnet Slack är en engelsk för-kortning av ”Searchable Log of All Conversation and Knowledge”. Slack innefattar bland annat chatt-rum organiserade efter ämne, såväl som privata grupper och direkta meddelan-den. Allt innehåll i Slack är sökbart och i gratisversionen går det att söka på de senaste 10 000 meddelandena. Slack har support för ett stort antal tredjeparts-tjänster och stödjer även egenbyggda integrationer. [6]

3.1.6 Gradle

Gradle är ett program som kan användas för att automatisera byggprocessen av mjukvara. Med hjälp av Gradle kan beroenden specificeras, laddas ned samt användas i Java-projekt.

3.1.7 JUnit

JUnit är ett testverktyg som kan användas för att hantera testning av Java-kod. Detta verktyg beskrivs närmare i bilaga F.

3.1.8 Travis CI

Travis CI är ett verktyg som används för att köra tester varje gång en ny uppladdning av kod görs till ett projekt på GitHub, så kallat ”Continuous integration”. När det sker hämtar Tra-vis CI en version av koden och utför en rad tester. Resultatet sammanställs och användaren meddelas. På detta sätt går det att fånga upp fel i koden tidigt och undvika att kod som inte följer en viss kodstandard laddas upp till ett gemensamt kodarkiv. [7]

3.1.9 Wordnet

Wordnet är en storskalig ordbaserad databas utvecklad av Princeton University som innehål-ler substantiv, verb, adjektiv och adverb. Dessa är grupperade i uppsättningar av kognitiva synonymer som kallas för synsets. Ord som är kognitiva synonymer har exakt samma bety-delse och kan ersättas med varandra i en mening, utan att betybety-delsen av meningen förändras. Synsets är sammanlänkade i en hierarkisk struktur genom semantiska och lexikaliska relatio-ner, det vill säga relationer baserade på ordens betydelser. Detta resulterar i ett nätverk som gör det möjligt att söka efter ord och kartlägga släktskap mellan begrepp på ett liknande sätt som i en ordbok. [8]

3.1.10 Word2Vec

Word2Vec är en modell där ord ur en datamängd matchas med en vektor baserad på de re-lationer som finns i datamängden till övriga ord. Ord som ofta används i samma kontexter representeras med liknande vektorer, där vinkel och längd ligger nära; vektorer emellan. Da-tamängden vid beräkning av modellen är ofta stor och modellens ordvektorer bestäms med hjälp av maskininlärning. Det finns flera olika sätt att beräkna ordvektorer. En inlärningsal-goritm kallad GloVe har bevisats vara gynnsam för detta. [9, 10]

(21)

3.2. Amazon Web Services

3.1.11 Blackboard

Ett blackboard-system, är ett system som strävar efter att kunna lösa svåra problem. Kärnan i ett sådant system är en så kallad Blackboard, som är en komponent där ett problem pre-senteras. Ytterligare består ett blackboard-system av agenter, kallade Knowledge Sources (i detta projekt kallas dessa Modifiers), dessa kan ses som ”experter” som kan lösa vissa de-lar av problemet. Alla Knowledge Sources arbetar genom att studera den information som finns presenterad i Blackboarden. Då en Knowledge Source kan bidra till lösningen, presen-teras detta bidrag till Blackboarden, vilket innebär att övriga Knowledge Sources får tillgång till mer information. Utöver Blackboard och Knowledge Sources, består systemet av en Con-troller som bestämmer vilken Knowledge Source som får tillåtelse att presentera sin lösning. Processen av att välja Knowledge Source fortsätter tills ett belåtet resultat nås, och problemet kan lösas tillräckligt. [11]

3.2 Amazon Web Services

Sektionen beskriver Amazons olika molntjänster som använts i projektet.

3.2.1 DynamoDB

DynamoDB är en NoSQL-databas som möjliggör lagring av data i molnet på ett flexibelt vis och används av många stora företag världen över. [12]

3.2.2 S3

S3, Simple Storage Service, är en tjänst för fillagring. Användare betalar för serverutrymme vilket möjliggör uppladdning av filer som sedan kan behandlas med ett flertal AWS-tjänster. Lagringsenheter för den data som laddas upp kallas för en hink eller ”bucket” som tillhör en viss region. S3 lanserades år 2006 i USA och hade enligt egna uppgifter cirka 102 miljarder sparade objekt år 2010. [13, 14]

3.2.3 Lambda

Lambda är en event-driven, molnbaserad plattform. Lambda gör att en användare inte behö-ver tänka på serbehö-verkonfiguration och endast behöbehö-ver betala när kod faktiskt körs. Användare kan ställa in att deras kod ska startas automatiskt när ett anrop sker från en av ett antal andra tjänster inom leverantörens utbud, exempelvis lagringsmedia, databaser, notifieringssystem och andra Lambda-funktioner. [15]

3.2.4 SNS

AWS Simple Notification Service (SNS) är en meddelande- och notifieringstjänst som kan användas för att koordinera leverans av meddelanden. Från användarens synpunkt fungerar SNS som en buss med envägskommunikation vilket gör det möjligt att på ett smidigt sätt fördela meddelanden till ett flertal olika typer av system och tjänster. [16]

3.2.5 SQS

AWS Simple Queue Service (SQS) är en meddelandekö-tjänst som kan användas för att mins-ka sammankoppling mellan delar i ett större system. Med SQS mins-kan en användare skicmins-ka, lagra och ta emot meddelanden mellan olika mjukvarukomponenter utan att behöva vänta på tillgänglighet hos en tjänst eller skapa en egen server. [17]

(22)

3.2. Amazon Web Services

3.2.6 Amazon Rekognition

Amazon Rekognition, eller kort Rekognition, är en tjänst för bild- och videoanalys. Rekognition baseras på deep learning-teknologi utvecklad av Amazon som har samman-ställts i ett användarvänligt API som inte kräver tidigare erfarenhet av maskininlärning för att användas. Modellen lär sig kontinuerligt av den data som behandlas och förbättras även genom att nya möjliga taggar och funktionalitet läggs till. [18]

Rekognitions API tillhandahåller följande tjänster för videoanalys:

• Objektigenkänning • Ansiktsigenkänning • Ansiktsjämförelse

• Känsloigenkänning (ansikten) • Kändisigenkänning

• Igenkänning av olämpligt innehåll

Den utdata som Rekognition producerar sammanställs som en lista av ”labels”, det vill säga taggar, i en JSON-fil. Varje tagg har en tillförlitlighetsnivå på en skala 0-100, där ett högre värde motsvarar en bättre säkerhet hos Rekognition att taggen förekommer i den data som behandlats. Varje tagg har även en tidstämpel som motsvarar när i klippet taggen genererats. Ett exempel på en tagg som genererats från en bild kan ses i figur. 3.1

1 { 2 "Labels": [ 3 { 4 "Label": { 5 "Name": "Brick", 6 "Confidence": 50.79460144042969 7 }, 8 "Timestamp": 400 9 }, 10 ... 11 ] 12 }

Figur 3.1: Ett exempel på hur en tagg kan se ut.

I figur 3.2 går det att se processen för behandling av ett videoklipp med Rekognition. Videon sparas först i en S3 bucket. Analysen startas genom att användaren anropar en funktion som till exempel StartLabelDetection. När en begäran har behandlats helt skickas ett meddelande till en Amazon SNS-topic, som kan bestå av en SQS eller lambda-funktion och användaren kan hämta resultatet genom att anropa en hämtfunktion som GetLabelDetection. [19]

(23)

3.3. Scrum

Figur 3.2: Videoprocessering i Amazon Rekognition Källa: [19]

3.3 Scrum

Scrum är en agil metodik för systemutveckling som baseras på en iterativ arbetsprocess där längre projekt delas upp i ett flertal kortare perioder. En arbetsperiod, som kallas för sprint, är generellt mellan 3 och 30 dagar lång. En sprint inleds med en planeringssession, sprint planning, och avslutas med en granskning av de utlovade ändringarna i en så kallad sprint review. Under sprinten sker dagliga möten, daily meetings, vilket är kortare möten där tea-met diskuterar status för de olika aktiviteterna i projektet. Som sista punkt i en sprintcykel äger en förbättringsaktivitet rum i en så kallad sprint retrospective där eventuella förbätt-ringar i arbetssättet identifieras och ett antal saker väljs ut och åtgärdas i kommande sprintar. Aktiviteter för en sprint hämtas från projektets backlogg, product backlog, som utgör en sam-lingsplats för alla önskemål om förändringar av produkten. Dessa aktiviteter är sorterade efter prioritet. Från produktens backlog väljer utvecklingsgruppen ett antal aktiviteter att arbeta med och lägger till dem sprintens backlog. Det som skapas i varje sprint kallas för inkrement, det vill säga en existerande körbar produkt som fått ett tillskott av nya egenska-per eller funktioner. Genom att granska inkrementet och produktbackloggen kan gruppen komma fram till hur de ligger till och ta beslut om vad som ska göras i nästa iteration. [20] En grafisk översikt av Scrum ges i figur 3.3.

3.3.1 Roller

Lista över roller i Scrum:

• Produktägare – Tar emot, hanterar och prioriterar önskemål om tillägg och ändringar för en produkt.

• Scrummästare – Fungerar som coach för teamet och säkerställer efterlevnad av proces-sen.

(24)

3.3. Scrum

• Utvecklingsteam – Utvecklingsteamet utgörs av en grupp på 3-9 personer med den kompetens som krävs för att utveckla produkten.

Figur 3.3: Scrum-ramverket Källa: [21]

(25)

4 Metod

Kapitlet beskriver hur projektgruppen arbetat för att besvara rapportens frågeställningar. In-ledningvis behandlas projektgruppens organisation och de dokument som skrivits. Därefter redogörs det allmänt för hur projektgruppen arbetat och i slutet av kapitlet beskrivs det mer detaljerat hur de olika faserna såg ut.

4.1 Arbetsmetod

Detta avsnitt beskriver hur vi inom projektgruppen arbetat: vilken agil utvecklingsmetod som projektgruppen använt sig av, vilka roller vi inom gruppen haft, tidigare erfarenheter, dokumentation, samt de interna utbildningar som krävts för att genomföra projektet.

4.1.1 Projektorganisation

I början av projektet hade gruppen en intern process för att tilldela gruppmedlemmarna rol-ler. Processen bestod av möten där varje gruppmedlem fick välja den roll som de var mest intresserade av. Om det fanns en roll som flera var intresserade avgjordes det med hjälp av sten, sax och påse, där vinnaren fick rollen. Rollerna är tydliga och beskrivs nedan:

Teamledare

Teamledarens roll är att leda arbetet, se till att målen nås, att arbetet går framåt och repre-senterar teamet utåt. Teamledaren sammankallar och håller i möten och ansvarar för att tids-rapporting med statusrapport skickas in i tid varje vecka. Teamledaren är ansvarig för att projektplan skrivs.

Analysansvarig

Analysansvarig är ansvarig för att hålla kontakten med kunden. Rollen innebär även att do-kumentera och hitta kundens krav på systemet, analysansvarig är ansvarig för kravspecifi-kationen.

(26)

4.1. Arbetsmetod

Kvalitetssamordnare

Kvalitetssamordnare är ansvarig för kvalitetsprocessen, uppföljning av denna och hur myc-ket av projektets budget som får läggas på detta. Kvalitetssamordnare är ansvarig för att kvalitetsplan skrivs.

Arkitekt

Arkitekten ansvarar för att en stabil grund för systemet tas fram och har som mål att identi-fiera gränssnitt och komponenter. Arkitekten ansvarar för att ett arkitekturdokument skrivs.

Utvecklingsledare

Utvecklingsledaren är ansvarig för detaljerad design och tar över efter att arkitekten beslutat om grunden. Utvecklingsledaren är ansvarig för och leder utvecklingsarbetet.

Dokumentansvarig

Dokumentansvarig ansvarar för att logotyp tas fram och att mallar finns till samtliga doku-ment. Dokumentansvarig är även extra ansvarig för att samtliga dokument skickas in i tid.

Testledare

Testledaren är ansvarig för att skriva en testplan för hur systemet ska testas och på ett sådant sätt att det verifierar samtliga krav i kravspecifikationen. Testansvarig är även ansvarig för att skriva en testrapport efter iteration 3 och 4 som utvärderar testarbetet.

Konfigurationsansvarig

Konfigurationsansvarig är ansvarig för att ta fram vilka arbetsprodukter som ska versions-hanteras och hur. Konfigurationsansvarig är även ansvarig för att verktygen används på rätt sätt varav en workshop kommer ledas av den konfigurationsansvarige.

4.1.2 Tidigare erfarenheter

I början av projektet satt projektgruppen ned och diskuterade tidigare erfarenheter, vad de skulle vilja göra annorlunda eller ta med sig från tidigare projekt, se avsnitt 2.1.2.

4.1.3 Utbildning

Specifika kunskaper behövdes inom ett flertal av Amazons molntjänster, se avsnitt 3.2 för de molntjänster som projektgruppen använt. Projektgruppen har därför genomfört flera works-hops inom olika områden under projektets gång. Dessa worksworks-hops fungerade så att en pro-jektmedlem fick en AWS-tjänst att läsa på om och fick sedan sammanställa en mindre sam-manfattning om tjänsten och presentera det inför övriga projektmedlemmar. Tanken med detta var att på ett tidseffektivt sätt få relevant information om de olika tjänsterna. Ansva-ret för att ha genomfört självstudierna, i form av att läsa på om de relevanta delarna till sitt uppdrag, låg på varje enskild projektmedlem.

Flera i projektgruppen hade varierande kunskaper inom versionshantering. Med anledning av detta höll konfigurationsansvarig en workshop i Git för att berätta mer om konceptet och hur det fungerar. Testledaren och utvecklingsledaren gick även på en workshop om testnings-standarder som hölls av Kristian Sandahl. En workshop i utvecklingsmiljön IntelliJ IDEA hölls av kunden. I workshopen togs kodstandard upp tillsammans med viktiga funktioner i utvecklingsmiljön.

(27)

4.1. Arbetsmetod

4.1.4 Dokument

För dokumentskrivning har projektgruppen valt att använda ShareLaTeX, vilket gjorde det lätt att dela upp dokumenten i diverse avsnitt och bland projektmedlemmarna. För lagring av inofficiella dokument som till exempel mötesprotokoll och seminarieförberedelser har Goog-le Drive använts.

Projektplan

Projektplanen beskriver hur projektgruppen ska arbeta, vilka resurser gruppen har tillgång till, eventuella begränsningar och de risker som finns. Dokumentet innehåller även en tids-plan som översiktligt tar upp vad som ska ske i varje fas av projektet.

Kravspecifikation

Kravspecifikationen beskriver de krav som finns på systemet, vilket innebär att kravspeci-fikationen definierar hur produkten kommer se ut när den är färdig. Kraven som finns be-skrivna är både funktionella och icke-funktionella krav.

Kvalitetsplan

Kvalitetsplanen beskriver processer som projektgruppen ska följa, för att på så vis säkerställa att produkten håller en hög kvalitet.

Arkitekturdokument

Arkitekturdokumentet beskriver detaljerat hur systemet ser ut och vilka eventuella begräns-ningar och beroenden som finns.

Systemanatomi

Systemanatomin visualiserar tydligt hur systemet är uppbyggt på olika nivåer, som till ex-empel funktioner och hårdvara, samt vilka beroenden som finns mellan de olika nivåerna.

Testplan

Testplanen definierar vad som ska testas och inte, hur testningen ska gå till, samt hur upp-följning av testerna ser ut.

Testrapport

Testrapporten är ett verktyg för att följa upp och dokumentera hur testningen gått till och vad resultatet blev.

Statusrapport

Statusrapport är till för att utvärdera och dokumentera hur varje fas gått. Rapporten svarar på vad som blev gjort och vad som är kvar.

Tidrapport

Tidrapporten är ett exceldokument på Google Drive där varje projektmedlem själv är ansva-rig för att fylla i sin tid. Tiden fylls i i tvåtimmarspass och ska innehålla klockslag, aktivitet och eventuellt samarbete. Tillsammans med tidsrapporten finns en så kallad burndown-chart som visar hur varje projektmedlem ligger till i jämförelse med den planerade tiden.

(28)

4.2. Utvecklingsmetod

4.1.5 Möten och kommunikation

I början av varje vecka har projektgruppen haft möte med handledaren för att stämma av hur projektet fortskridit, samt haft möjligheten att ställa eventuella frågor. Utöver dessa möten har projektgruppen haft egna möten för att planera sprintar och diskutera eventuella pro-blem eller funderingar. Mötesprotokoll har förts till större möten. Projektgruppen har även haft kontinuerlig kontakt med kunden via Skype där projektgruppen gett mindre statusupp-dateringar och fått svar på eventuella frågor. Mötena med kunden har varit cirka två till tre gånger i veckan.

För kommunikation inom projektgruppen har Slack använts, där olika kanaler skapades för att diskutera olika ämnen. Kommunikationen med kunden har skett genom Skype, där hu-vudsakligen teamledaren och analysansvarig stått för kontakten. Kunden har även haft till-gång till projektets Trello-tavla för att kunna följa upp hur det gått under de olika faserna av projektet.

4.1.6 Scrum

Arbetsmetoden som användes i projektet är en variant av den agila utvecklingsmetoden Sc-rum. Istället för att ha dagliga möten har projektgruppen försökt att ha möten två till tre gånger i veckan. Varje fas delades upp i två sprintar, se sektion 4.2.5. Istället för att ha en fysisk Scrum-tavla har projektgruppen använt sig av Trello för visualisering av sprintar och dess aktiviteter. Aktiviteter har här tilldelats kort som sorteras efter vad som ska göras i nu-varande sprint (sprint backlog), vilka aktiviteter som är pågående, aktiviteter som är redo att granskas och de aktiviteter som är helt färdiga. Vid slutet av varje sprint har projektgruppen genomfört utvärderingar för att försöka fånga erfarenheter och förbättra processen, se avsnitt 4.1.7.

4.1.7 Metod för att fånga erfarenheter

I slutet av varje sprint skedde en utvärdering, med syftet att regelbundet förbättra projekt-gruppens processer. Utvärderingen gick igenom vad projektgruppen hann bli färdiga med, samt vad de inte hann bli färdiga med, av de aktiviteter som de planerat för sprinten. Ut-värderingen innefattade även reflektioner av vilka problem som gruppen eller enstaka indi-vider stötte på, samt hur de löste problemen. I samband med utvärderingen brukade även den nästkommande sprinten planeras som därmed kunde dra nytta av resultatet från den genomförda utvärderingen.

4.2 Utvecklingsmetod

Detta avsnitt beskriver hur gruppen har arbetat med mjukvaruutveckling under projektets gång.

4.2.1 Kodhantering

All kod samlades i ett IntelliJ-projekt med underliggande Java-paket för att gruppera olika typer av funktionalitet. Projektet använde Git för versionshantering med ett arkiv på GitHub för att lagra all versionshanterad kod. En standard för formatering av namn på förgrening-ar och meddelanden formulerades gemensamt av projektgruppen i början av projektet. Allt arbete i koden skedde i separata förgreningar som sedan, efter godkännande av minst en gruppmedlem enligt testplanen, kunde sammanfogas med huvudgrenen. Målet var att all kod i huvudgrenen när som helst skulle kunna sättas i drift i produktionsmiljö.

(29)

4.2.2 Utvecklingsmiljö

Baserat på Flowplayers befintliga kodbas beslutades det att programspråket som huvudsak-ligen skulle användas i projektet var Java. Produktionsmiljön som användes hade stöd för version 8 och det blev därför Java 8 som projektgruppen valde att använda i hela projektet. Följande program och verktyg användes även i projektet:

• Projektgruppen rekommenderades att använda den integrerade utvecklingsmiljön In-telliJ IDEA från JetBrains, vilket alla i gruppen sedan gjorde. Kontaktpersonen hos Flowplayer använde även just den miljön, vilket gjorde att han kunde ge projektgrup-pen konfigurationsinställningar samt allmänna tips rörande användning av verktyget. • Ett automatiskt byggsystem, Gradle, användes för att bygga VATG samt dess beroenden. • SAM Local, ett verktyg från Amazon, användes för att testa och analysera körning av

kod i en simulerad produktionsmiljö innan driftsättning.

• Olika gruppmedlemmar använde olika lokala program för konfigurationshantering med Git.

• Diverse bibliotek (s.k. SDK) från Amazon för att kommunicera med deras tjänster ge-nom Java-kod.

• GitHub användes för samarbete kring och lagring av versionshanterad kod.

4.2.3 Testmiljö

Denna sektion beskriver hur testande av produkten genomfördes.

Enhetstester, integrationstester samt kodkvalitet

Enhetstester som testar enskilda funktioner och integrationstester som testar att flera moduler fungerar tillsammans, skrevs av de utvecklare som arbetade med respektive del i systemet. Projektgruppen hade som mål att testerna skulle omfatta minst ett element i varje ekvivalens-klass som kunde identifieras ur den funktion som testades.

Då projektets kod skrevs i Java valde projektgruppen att skriva sina tester i ramverket JUnit, detta inbegrep både enhets- och integrationstester. Testerna gick att köra lokalt men startade även automatiskt vid varje begäran att sammanfoga en gren till huvudgrenen i projektgrup-pens versionshantering. Detta skedde med hjälp av verktyget Travis CI som satte upp en testmiljö på en extern server och därefter utförde testerna och rapporterade tillbaka resulta-ten. Projektgruppen hade som regel att den aktiva versionen på huvudgrenen skulle klara av alla tester. För att inte enbart testa funktionalitet utan även aspekter som kodkvalitet, hade projektgruppen som tumregel att ny kod skulle granskas och godkännas av minst en annan person i gruppen.

Installationstester

För att testa att produkten fungerade i produktionsmiljö genomfördes installationstester. Des-sa tester genomfördes huvudDes-sakligen genom att funktionalitet installerades i Amazons miljö, vilket är en produktionsmiljö, varpå den sedan testades manuellt. Den manuella testningen underlättades något då produkten i sig är automatisk.

(30)

Kvalitetstester

För att testa att resultatet från VATG hade ett faktiskt värde och kunde användas av kunden krävdes en subjektiv bedömning. Det löstes genom att ett urval utomstående personer fick värdera och poängsätta flera resultat från VATG, samt några resultat av samma typ fast gjorda av en människa. Anledningen till varför projektgruppen även valde att testa vilken poäng en människa fick var för att göra det lättare att jämföra de två sinsemellan.

Kvalitetstesterna bestod av flera moment. Först valdes tre lämpliga videoklipp som skulle användas i undersökningen. Det blev videor som innehöll en intervju, ett nyhetsreportage samt ett sportreportage. De hade en längd på en till två minuter styck. Efter att videorna hade valts skickades de in till VATG som genererade en grupp av taggar för respektive video. Videorna fick även taggar direkt genererade av Rekognition, vilket i detta fall blev att vi tog de 15 mest förekommande taggarna från Rekognitions objektigenkänning. 15 taggar valdes då VATG hade som krav att den inte fick returnera mer än 15 taggar. Videoklippen fick även ett antal taggar skapade av människor som inte ingick i projektgruppen. De personer som skapade taggarna gjorde det för en video i taget och fick inte diskutera med någon annan. De fick inte heller se vilka taggar andra personer skapat eller vilka taggar VATG skapat. Anledningen till att vi hade flera parter som skapade taggar var för att sedan kunna jämföra resultaten sinsemellan.

Sista delen av undersökningen genomfördes sedan av andra personer som inte deltagit ti-digare och som inte ingick i projektgruppen. Även den gången var personerna som genom-förde undersökningen isolerade från varandra. Först fick de se taggarna skapade av VATG, Rekognition och av en människa, utan att få reda på vilken grupp av taggar som var från vem. Sedan fick de titta på hela videon. Därefter fick de poängsätta hur bra de olika grup-perna av taggarna representerade videon. Där en grupp är alla taggar från antingen VATG, Rekognition eller en människa. Även om vi haft flera människor som skapat taggar till aktuell video så fick personerna i denna del endast se resultatet av en av dem. Detta för att simule-ra hur det vore att ha en person anställd till att skapa taggar. Personerna fick även markesimule-ra de taggar som de tyckte var olämpliga för videon. Efter att ett flertal personer genomfört undersökningen sammanställdes resultatet.

Acceptanstest

För att kontrollera att produkten uppfyllde kundens krav och förväntningar genomfördes ett acceptanstest. Detta test utfördes när produkten innehöll den funktionalitet som förväntades. Testet genomfördes genom att gruppen demonstrerade produkten varpå en diskussion hölls med kunden.

4.2.4 Produktionsmiljö

För att driftsätta systemet användes så kallad serverless computing med hjälp av Amazons tjänst AWS Lambda. Leverantören beskrev tjänsten som en FaaS, Function as a Service. I och med användningen av AWS Lambda krävdes minimal konfiguration av produktionsmiljön. Mer information om denna typ av miljö går att finna i bilaga B. De tjänster som utvecklades byggdes och paketerades med hjälp av Gradle och driftsattes manuellt till AWS Lambda vid leverans.

4.2.5 Faser

Denna sektion beskriver hur projektgruppen jobbat i de olika faserna av projektet. Projektet bestod av fyra stycken faser, förstudie, undersöknings-, utvecklings- och avslutningsfas.

(31)

Förstudie

Under förstudien försökte projektgruppen konkretisera projektdirektiven och lägga upp en övergripande aktivitetsplan. Det gjordes genom att gruppen delade upp sig i två grupphal-vor, där ena grupphalvan skissade på en fasplan och andra grupphalvan på en kravlista. Fasplanen togs fram genom att rita upp fyra faser på en whiteboard-tavla där grupphalvan till en början lade in givna saker som till exempel deadlines. Därefter funderade grupphal-van ut övergripande mål och försökte till detta komma på aktiviteter. Kravlistan togs fram genom att först konkretisera projektdirektiven, för att sedan värdera den framtagna infor-mationen. När projektgruppen försökte förtydliga projektdirektiven märkte de snabbt att det skulle behövas en undersökningsfas för att ta reda på vad som var möjligt att utveckla och inte.

Undersökningsfas

Under projektets undersökningfas genomfördes en undersökning av de verktyg för video-analys som fanns tillgängliga inom tjänsterna Amazon Rekognition och Google Vision. För att undersöka de olika funktionerna Rekognition och Vision erbjöd läste projektgruppen på om vad de innehöll och försökte i den mån det var möjligt att testa och sammanställa hur väl de fungerade. När val av plattform och funktionalitet var bestämd lades projektgruppens fokus på att diskutera möjliga lösningar och verktyg till systemet som skulle utvecklas. Efter en översiktlig undersökning av möjliga verktyg för kategorisering av ord fokuserades arbete på att jämföra ett fåtal verktyg som kunde användas i projektet.

Utvecklingsfas

Under utvecklingsfasen hamnade ett stort fokus på att få ihop en prototyp på hur vårt system skulle se ut. Utvecklingen planerades sprintvis där projektgruppen gemensamt kom överens om vad som först behövde göras. För att på ett effektivt sätt jobba med prototypen valde projektgruppen att jobba mer individuellt med de olika modulerna som tagits fram. Arbets-sättet ställde höga krav på kommunikation inom gruppen och projektgruppen satt därför ofta tillsammans, även om medlemmarna jobbade på olika aktiviteter. För att de moduler som utvecklades skulle gå att slås ihop på ett smidigt sätt använde projektgruppen olika gre-nar på Git. Under utvecklingsfasen hade även projektgruppen en större kodgranskning för att säkerställa att den kod som tagits fram var optimal men också läsbar och lättförståelig. Under fasen lades även ett stort fokus på att påbörja och komplettera dokumentation, samt en presentation av systemets arkitektur på ett halvtidsseminarie.

Avslutningsfas

Under projektet avslutningsfas fortsatte utvecklingsarbetet och i början av fasen hade pro-jektgruppen sin första leverans till kunden. För att säkerställa att tjänsten höll hög kvalitet höll projektgruppen i ett kvalitetstest. Testet finns utförligt beskrivet i sektion 4.2.3. Testet utfördes för att projektgruppen skulle få en bättre uppfattning om hur väl produkten mot-svarade människors förväntningar på taggning av ett videoklipp. Utöver att kvalitetssäkra och förbereda inför leverans lades ett stort fokus på att färdigställa dokumentation och på att förbereda en slutpresentation.

(32)

5 Resultat

Detta kapitel presenterar de resultat som projektet har genererat. Resultaten presenteras un-der två huvudsakliga kategorier, de är: förstudie beskrivet i avsnitt 5.1 och utveckling, avsnitt 5.2. Avsnittet behandlar även systemets uppbyggnad, struktur och testning.

5.1 Förstudie

Under förstudien undersöktes vilka möjligheter som fanns genom användande av API:er samt hur filtrering och kategorisering av utdata från dessa skulle kunna ske. Resultaten från förstudien presenteras i detta avsnitt.

5.1.1 Undersökning av API:er

Under projektets förstudiefas undersöktes ett antal funktioner som Amazon och Google till-handahåller. Nedan presenteras resultatet av de funktioner som undersöktes.

Identitifera kända byggnader och miljöer

Rekognition känner igen miljöer väl. Givet en bild på en strand känner Rekognition igen mil-jön och genererar taggen ”beach” med hög konfidensnivå. Vanligt är dock att Rekognition kan göra antaganden till taggar och till strand genereras taggarna ”hotel” och ”resort”, dessa taggar har däremot en låg konfidensnivå. Analys av kända byggnader stöddes inte av Ama-zons API. En bild på till exempel Eiffeltornet skulle av Amazon Rekognition bara kännas igen som en byggnad.

Identifiera höjdpunkter

Under projektets undersökningsfas kunde inget API hittas som kunde identifiera höjdpunk-ter i videoklipp. En höjdpunkt kan till exempel vara en sekvens i ett sportklipp där det blir mål.

(33)

5.1. Förstudie

Identifiera och läsa text

Varken Amazon eller Google hade något stöd för att läsa text i videoklipp. Däremot hade båda företagen tjänster för att läsa text ur bilder. Amazons tjänst hanterade ej svenska tecken (å, ä och ö).

Analys av videoklipp eller stillbilder från videoklipp

Projektgruppen valde att analysera hela videoklipp eftersom det ansågs vara en enklare lös-ning att arbeta med. Funktionalitet som tillhandahölls av Rekognition för videoanalys ansågs tillräcklig. En mer djupgående analys av skillnaderna mellan att använda bilder och att an-vända videoklipp går att finna i bilaga E.

Transkribering

Både Amazon och Google hade stöd för transkribering av ljud ur videoklipp. Google ha-de stöd för en mängd olika språk, däribland svenska, medan Amazon endast haha-de stöd för engelska och spanska. För att använda Amazons API, Transcribe, var videoklippet som skulle transkriberas tvunget att vara lagrat i en specifik geografisk region. Detta var för projektgrup-pen relativt krångligt och dyrt att åstadkomma.

Logotyper

Google hade stöd för att få ut logotyper samt information om dessa ur videoklipp. Amazon hade fortfarande denna funktionalitet i sin utvecklingsplan [22]. Amazon kunde dock redan vid undersökningsfasen identifiera att en logotyp var synlig i ett videklipp, men ej någon information om vilket företag den representerade eller liknande.

Identifiera känslor och ansiktsuttryck

Det fanns stöd hos både Amazon och Google för att identifiera attribut så som kön, ålder och känslor samt information om ansiktet hos en person. Kön och ålder gavs i de flesta fallen med relativt hög konfidens, även om ålderspannet som gavs ibland kunde vara väldigt brett, upp till 30 år. Även information om ansikten, exempelvis om en person bar glasögon, kunde ges med relativt hög säkerhet. Information om känslor, exempelvis om en person var glad, gavs med lägre konfidens men verkade ofta stämma bra.

Identifiera och känna igen ansikten

Det var genom ett API från Amazon möjligt att identifiera kända personer. Det var då även möjligt att hämta information så som namn och länk till personens sida på imdb.com med ganska stor säkerhet. Ingen officiell information om vilka personer som kunde kännas igen kunde hittas, däremot gjorde projektgruppen antagandet att de personer som finns på IMDb går att identifiera med hjälp av detta API. Det gick även att spara ner egen metadata för ansikten och jämföra dessa med alla ansikten som kan identifieras i videoklipp.

Översätta taggar

Amazon hade inte stöd för flera språk när det kommer till att generera taggar. Google hade stöd för många språk, däribland svenska.

Olika längder av videor

Videons längd verkade inte påverka kvalitén av de taggar som genererades. Projektgruppens uppfattning var att Amazons API tog en bild ungefär var 200:e millisekund och analyserade dessa bilder separat.

(34)

5.2. Utveckling

5.1.2 Undersökning av lösning för filtrering av taggar

Efter undersökning av API:er fattades beslutet att använda ARV för videoanalys. Vad som skulle behövas utöver klassificering av objekt i givna videor för att uppnå detta resultat blev därmed nästa steg. Efter att projektgruppen tillsammans diskuterat detta problem blev det klart att analys av relationer mellan taggar skulle behövas, tillsammans med taggdata såsom konfidens vid klassificering och upprepningsfrekvens, för att ta bort irrelevanta ord och ska-pa grupper som kunde användas för att skaska-pa en beskrivande samling taggar. Därmed utred-des möjliga lösningsmetoder för att analysera samband mellan taggar. Sambanden var tänkta att användas till sållning av den utdata Amazon Rekognition genererat. Även hur taggspeci-fik data såsom konfidens bäst kunde användas för filtrering utreddes.

Efter att ha analyserat hur konfidens samt antalet förekomster av taggar var relaterat till deras relevans för videoklippet kunde inte några direkta slutsatser dras. De taggar som totalt sett förekom minst av alla kunde i många fall, men inte alla, filtreras bort.

5.1.3 Undersökning av lösning för kategorisering av taggar

Efter en översiktlig undersökning av möjliga verktyg för kategorisering av ord fokusera-des arbete på att jämföra två verktyg: Wordnet och Word2Vec. Resultatet från denna jäm-förelse var att Wordnet och Word2Vec kunde lösa problemet med ungefär lika hög kvalitet men att Word2Vec skulle vara betydligt svårare att implementera och driftsätta. Däremot var Word2Vec snabbare att använda vid körning. Undersökningen pekade på att Wordnet läm-pade sig väl för lexikal och semantisk analys, medan Word2Vec snarare baseras på relationer av hur ord förekommer tillsammans med varandra. I bilaga A beskrivs en noggrannare jäm-förelse mellan de två verktygen. Beslutet från undersökningsfasen blev att använda Wordnet som huvudmetod för ändamålet.

5.2 Utveckling

Utvecklingen av systemet började när konsensus mellan gruppens medlemmar uppnåtts kring systemets anatomi och arkitektur. Detta gjordes genom att gemensamt jobba fram en första prototyp för systemet och ha en öppen dialog för hur modulerna skulle implementeras, för att slutligen fatta ett gemensamt beslut. För att gå vidare i utvecklingen och möjliggöra ett mer effektivt arbetssätt började gruppens medlemmar individuellt arbeta på olika utökningar av systemet. Parallellisering av implementation gjordes genom att låta gruppens medlemmar arbeta på olika grenar i Git, se sektion 4.2.1. När gruppens medlemmar var klara med sina im-plementationer slogs grenarna ihop med prototypen. Projektets processer mognade vid den här tidpunkten, vilket gav upphov till högre kvalité och medlemmarna fick bättre kunskap om projektets konfiguration.

5.3 Resulterande funktionalitet och systembeskrivning

Här presenteras en beskrivning av den slutprodukt (VATG) som projektarbetet lett fram till. Det innefattar redogörande av systemets huvudfunktioner och övergripande struktur. En anatomi för systemet kan ses i figur 5.1. Notera avsnitt 5.1.2, förstudiefasen, där beslutet att inte använda Word2Vec fattates; istället lades fokus huvudsakligen på lösningen som inne-höll Wordnet. I den slutgiltiga produkten implementerades dock versioner av båda lösning-arna.

(35)

5.3. Resulterande funktionalitet och systembeskrivning Tjänster från Amazon Word2Vec Amazon DynamoDB Kategorier (lokal lagring) Controller Blackboard Modiﬁers Amazon Rekognition

AWS Lambda AWS SNS AWS SQS WordNet

API Wordnet (lokal lagring)

Figur 5.1: Översikt över systemets olika roller.

5.3.1 Systembeskrivning

Systemet består huvudsakligen av komponenterna:

• Blackboardsystem sköter analys av taggar genererade från Rekognition med syftet att förbättra dessa. Systemet innefattar blackboard, controller och modifiers.

• Lokalt lagrade kategorier används för kategorianalys som finns beskrivet längre ned i kapitlet.

• Wordnet API i Java med tillhörande databas för lexikal och semantisk analys av ord. • En vektorrepresentation av relationer mellan ord framtagen med hjälp av Word2Vec

som lagras i molnet med hjälp av AWS DynamoDB. • AWS Lambda möjliggör serverlös exekvering av systemet.

• Rekognition för att hitta initiala taggar till en video genom objektigenkänning.

• SNS och SQS möjliggör kommunikation in och ut från systemet till övriga system an-slutna till kö- och notifikationstjänsten.

Övergripande systembeskrivning

VATG använder AWS Lambda för att dela upp körningen av systemet i två separata pro-cesser, videoanalys och filtrering. Analysmodulen startas genom ett anrop som innehåller adressen till videoklippet som ska analyseras. Därefter skickas datan vidare med ett anrop till Amazon Rekognition, varpå svaret skickas till en SNS topic. Filtreringsmodulen lyssnar på denna SNS topic och startar upp vidare analys i en ny lambda-process som utför operatio-ner på de taggar som Amazon Rekognition geoperatio-nererat.

Bearbetningen av taggar från Rekognition startar genom att den blackboard- och modul som refererar till motsvarande i blackboard-arkitekturen initialiseras. I controller-modulen körs först ett antal förbestämda modifierieringmoduler på den mängd taggar som

(36)

5.3. Resulterande funktionalitet och systembeskrivning

ligger i blackboarden. Dessa är relevansfiltrering, samplingsfrekvensfiltrering, stoppords-filtrering, omvänd likhetsfiltrering och kategorisering i respektive ordning. Filterna finns beskrivna i avsnitt 5.3.2. Efter detta inleds den kontroll-loop som utmärker blackboard-arkitekturen. De modifieringsmoduler som körs här är likhetsfiltrering och relevansfiltrering. Med detta kör de listade modifieringsmodulerna sina funktioner och den samling operatio-ner som ger upphov till högst påverkan väljs ut och exekveras. Dessa modifieringsmoduler parallelliseras genom att köras i separata lambda-processer. För varje körning ökas variabla värden i de modifieringsmoduler som testas för exekvering i kontroll-loopen med en multi-pel av det nuvarande värdet. Detta upprepas tills ingen modifieringsmodul kan göra några ändringar, alternativt att den tidsgräns som VATG begränsas av har överstigits. Efter detta körs omvänd likhetsfiltrering för att ta bort ytterligare taggar som inte anses höra till kontex-ten. Slutligen presenteras den resulterande taggdatan på det format som kunden angivit och skickas tillbaka till Flowplayer med ett HTTP-anrop.

5.3.2 Huvudfunktioner

VATG tar emot ett filnamn som refererar till ett videoklipp som indata. Detta används sedan för att skapa taggar som är tänkta att representera det som visas i klippet. Denna videotagg-ningsprocess innefattar en mängd delprocesser som presenteras nedan.

• Videoanalys – För att få ut en preliminär samling ord att utgå ifrån används Amazon Rekognition Video för att identifiera objekt i behandlade videofiler. Denna del ansva-rar därmed för att skicka anrop till Amazon och ta emot resulterande ord. Med detta uppfylls följande krav i projektets kravspecifikation ”Systemet skall skapa taggar till en video”. Utskick av anrop och behandling av respons sker som två skilda processer och finns därför som två separata moduler.

• Samplingsfrekvensfiltrering – För att få ner antalet taggar till en konstant nivå utförs ett urval där taggar tas bort likformigt över den inmatade videons tidsintervall, tills antalet taggar ligger under ett visst antal.

• Relevansfiltrering – En form av relevansfiltrering utförs för att sålla bort taggar som inte förekommer tillräckligt ofta i en video. Taggar tas bort på två sätt. De tas bort bero-ende på hur ofta de förekommer under specifika intervall, och de tas bort berobero-ende på hur ofta de förekommer jämfört med taggen som förekommer oftast.

• Likhetsfiltrering – Ord som ligger nära varandra i betydelse tas bort genom att testa ordpar för likhetsgrad, vilket görs med uppslag i orddatabasen Wordnet. Sedan sparas likhetsrelationer över ett visst tröskelvärde, indexerade över hur många relationer varje ord har. Det ord som har flest relationer behålls och de ord som ordet relaterar till tas bort.

• Omvänd likhetsfiltrering – För att minska risken att mindre relevanta ord behand-las i analysen, utförs en omvänd likhetsfiltrering, det vill säga ord som inte har någon som helst anknytning till resterande ord tas bort. Det utförs genom att mäta likhet mel-lan de olika vektorerna, som beskrivs mer ingående i avsnitt A.3.3. I Word2Vec skapas en medelvärdes-vektor, vektorn kan sedan ses som den gemensamma kontexten. Ord som inte tycks ha några relationer till medelvärdet kan därför anses vara mindre rele-vanta, och plockas därför bort, se figur 5.2. Anledningen till att medelvärdes-vektorn kan ses som en gemensam kontext, bygger på Word2Vec-modellens natur som beskri-ver relationer mellan olika ord. I Wordnet fungerar den omvända likhetsfiltreringen på annorlunda vis. I den omvända likhetsfilteringen för Wordnet används ingen medel-värdesvektor, istället skapas samlingar av taggar som ligger nära varandra enligt deras