Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2019 | LIU-IDA/LITH-EX-G--19/004--SE
Digital 3D-rekonstruktion av
per-sonskador
Digital 3D reconstruction of injuries
Yohan Ayoub
Viktor Barr
Johan Fallström
Simon Gustavsson
Martin Jirenius
Jacob Olausson
Arin Rashid
Handledare : Jonas Wallgren Examinator : Kristian Sandahl
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 fkopi-orskning 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 upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgä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 som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens 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 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-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Yohan Ayoub Viktor Barr Johan Fallström Simon Gustavsson Martin Jirenius Jacob Olausson Arin Rashid
Sammanfattning
Denna rapport behandlar ett arbete utfört under kursen TDDD96 Kandidatprojekt i pro-gramvaruutveckling vid Linköpings Universitet. Arbetet är efterfrågat av Nationellt Fo-rensiskt Centrum (NFC) och utfört av 7 datateknologstudenter. Arbetet bestod i att ta fram och utveckla ett färdigt program som ska göra det enkelt för kriminaltekniker och obdu-center att rekonstruera personskador samt presentera det på ett pedagogisk sätt.
Författarnas tack
Vi vill tacka NFC för att de gav oss möjligheten att utföra det här arbetet åt dem. Projek-tet har varit motiverande och gett varje gruppmedlem en chans att utvecklas inom många olika områden. Vi vill speciellt tacka Jimmy Berggren och Johan Lind på NFC för ett fantas-tiskt samarbete. De har varit tillmötesgående från dag ett och att ha så engagerade kunder har varit en stor anledning till gruppens engagemang i arbetet. Vi vill också tacka Torbjörn Lundstedt och Brita Zilg för att de ställde upp och gav feedback från användarens perspektiv. Vidare vill vi tacka Jonas Wallgren för all handledning under projektets gång. Han har varit ett kontinuerligt stöd och alltid haft relevanta kommentarer på vårt arbete. Den kvalitet som kandidatrapporten har uppnått är mycket tack vare honom. Vi vill också tacka Kristian Sandahl, examinator för kursen. Han har tillhandahållit utmärkt undervisningsmaterial och kursen kändes väl utformad och flexibel när förtydliganden och extra stöd behövdes. Vi vill dessutom tacka våra kvalitetscoacher Aron Gosch och Mustaf Musse för många värdefulla möten och deras stora insikt i kvalitet kring utvecklingprocessen. Vi utformade många processer efter dessa möten och det har bidragit till flera förbättrade arbetssätt.
Sammanfattning iii Författarens tack v Innehåll vi Figurer ix Tabeller x 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 1.5 Definitioner . . . 2 2 Bakgrund 5 2.1 Kunden . . . 5 2.2 Tidigare erfarenheter . . . 5 3 Teori 7 3.1 Framställning av digitala modeller idag . . . 7
3.2 Verktyg och programvara . . . 7
4 Metod 11 4.1 Projektorganisation . . . 11
4.2 Utbildning . . . 12
4.3 Samarbete . . . 12
4.4 Utvecklingmetod . . . 13
4.5 Metod för att fånga erfarenheter . . . 17
5 Resultat 19 5.1 Systembeskrivning . . . 19 5.2 Systemanatomi . . . 25 5.3 Dokument . . . 25 5.4 Värde för kunden . . . 26 5.5 Gemensamma erfarenheter . . . 26
5.6 Översikt över individuella bidrag . . . 27
6 Diskussion 29 6.1 Resultat . . . 29
6.4 Lärdomar inför framtiden . . . 36
7 Slutsatser 37 A En spelmotors påverkan på ett projekt som vårt av Martin Jirenius 39 A.1 Inledning . . . 39 A.2 Teori . . . 40 A.3 Metod . . . 44 A.4 Resultat . . . 45 A.5 Diskussion . . . 46 A.6 Slutsatser . . . 49
B En jämförelse mellan 3D-spelmotorerna Unity 3D och Unreal Engine 4 av Arin Rashid 51 B.1 Inledning . . . 51 B.2 Bakgrund . . . 52 B.3 Teori . . . 52 B.4 Metod . . . 53 B.5 Resultat . . . 54 B.6 Diskussion . . . 56 B.7 Slutsatser . . . 57
C Lärstilar och Learn-by-doing av Jacob Olausson 59 C.1 Inledning . . . 59 C.2 Bakgrund . . . 60 C.3 Teori . . . 60 C.4 Metod . . . 62 C.5 Resultat . . . 66 C.6 Diskussion . . . 67 C.7 Slutsatser . . . 68
D Hur kan ikoner användas i ett program för att öka förståelsen? av Johan Fallström 69 D.1 Inledning . . . 69 D.2 Teori . . . 70 D.3 Metod . . . 72 D.4 Resultat . . . 72 D.5 Diskussion . . . 73 D.6 Slutsatser . . . 75
E En jämförelse mellan olika Git-arbetsflöden av Simon Gustavsson 77 E.1 Inledning . . . 77 E.2 Bakgrund . . . 78 E.3 Teori . . . 78 E.4 Metod . . . 78 E.5 Resultat . . . 79 E.6 Diskussion . . . 84 E.7 Slutsatser . . . 85
F Hur kan 3D-rekonstruktioner påverka rättsprocesser och forensik av Viktor Barr 87 F.1 Inledning . . . 87
F.2 Bakgrund . . . 88
F.3 Teori . . . 88
F.4 Metod . . . 89
G Blender och MakeHuman i ett projekt av Yohan Ayoub 95 G.1 Inledning . . . 95 G.2 Bakgrund . . . 95 G.3 Teori . . . 96 G.4 Metod . . . 96 G.5 Resultat . . . 97 G.6 Diskussion . . . 99 G.7 Slutsatser . . . 100 Litteratur 103 H Arkitekturdokument 109 I Bildmanifest 119
Figurer
5.1 Flödesschema mellan scener . . . 20
5.2 Startskärm . . . 21
5.3 Karaktärsskapandevyn . . . 22
5.4 Ändra ställning på karaktär . . . 23
5.5 Skadevyn . . . 23
5.6 Presentationsvyn . . . 24
5.7 Systemanatomi 1 . . . 25
5.8 Systemanatomi 2 . . . 25
6.1 Exempel på tidig knappdesign.. . . 30
6.2 Exempel på aktuell knappdesign. . . 31
6.3 Tidig designskiss. . . 32
A.1 En kub uppbyggd av trianglar . . . 40
A.2 Sfärer uppbyggda av olika antal trianglar . . . 40
A.3 Nodtransformationer under rendering . . . 41
A.4 Illustration av en rastrering.. . . 42
A.5 Flöde för fragmenttestning . . . 42
C.1 Kolbs fyra lärstilar . . . 61
D.1 Ikonexempel . . . 69
D.2 Enkelriktat gränssnitt . . . 70
D.3 Dubbelriktat fysiskt gränssnitt. . . 71
D.4 Användargränssnitt. . . 71
E.1 Centraliserat arbetsflöde . . . 80
E.2 Feature branch arbetsflöde . . . 80
E.3 Gitflow arbetsflöde . . . 82
A.1 Tabell över resultat på undersökning . . . 45
B.1 Jämförelsetabell över resultat . . . 56
C.1 Tabell över resultat på påståendefrågorna . . . 66
C.2 Tabell över resultat på flervalsfrågorna . . . 66
E.1 Tabell över svar på fråga 1 . . . 82
E.2 Tabell över svar på fråga 2 . . . 83
E.3 Tabell över svar på fråga 3 . . . 83
E.4 Tabell över svar på fråga 4 . . . 83
E.5 Tabell över svar på fråga 5 . . . 83
E.6 Tabell över svar på fråga 6 . . . 84
G.1 Tabell över svar på intervjufråga 1 . . . 97
G.2 Tabell över svar på intervjufråga 2 . . . 98
G.3 Tabell över svar på intervjufråga 3 . . . 98
G.4 Tabell över svar på intervjufråga 4 . . . 98
1
Introduktion
1.1
Motivering
Detta kandidatarbete behandlar ett uppdrag efterfrågat av Nationellt Forensiskt Centrum (NFC), en nationell avdelning inom polismyndigheten. Programvaran som togs fram är en skrivbordsapplikation för kriminaltekniker och rättsläkare där användaren kan ta fram 3D-modeller av brottsoffer och visualisera personskador. Med hjälp av detta ska använ-daren på ett intuitivt sätt kunna presentera fallet för jurister i en rättssal. Programmet utvecklades i programspråket C# och togs fram med hjälp av spelmotorn Unity 3D och 3D-modelleringsverktyget Blender.
Programvaran som framställdes är ingen teoretisk möjlighet utan en praktisk lösning på ett verkligt problem. Det medför att denna rapport ger läsaren stor insikt i hur man tar sig från en enkel tanke till färdig produkt.
1.2
Syfte
Syftet med rapporten är att beskriva den produkt som blivit framställd, hur kandidatgrup-pen utvecklat och arbetat, det slutgiltiga resultatet, vilka erfarenheter som fångats och vilka slutsatser som kan dras utifrån arbetet. Rapporten har dessutom syftet att svara på de fråge-ställningar som tas upp i avsnitt 1.3.
1.3
Frågeställningar
Följande frågeställningar ska besvaras i kandidatrapporten:
1. Hur kan ett program för visualisering av personskador implementeras så att man ska-par värde för kunden?
2. Vilka erfarenheter kan dokumenteras från projektarbetet som kan vara intressanta för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan ett program tas fram med stora krav på användarvänlighet?
1.4
Avgränsningar
Denna rapport kommer endast behandla framställandet och resultatet av produkten StabLab som projektgruppen tog fram i kursen TDDD96, Kandidatprojekt i Programvaruutveckling och de ämnena som tas upp i de individuella delarna. Frågeställning fyra kommer besvaras utifrån gruppens erfarenheter från utvecklingen av produkten.
1.5
Definitioner
Nedan följer en ordlista med begrepp som inte är vedertagna
• Gizmo - Ett visuellt objekt för att förenkla förflyttning och rotation av objekt i 3D-miljö.
• 3D-motor - En mjukvarukomponent som främst skapar grafik i ett program, men även funktionalitet.
• 3D-pipeline - En modell för processen att gå från 3D-modell till visualisering på en 2D-skärm.
• Agil verksamhet - En verksamhet som använder sig av en systemutvecklingsmetod där utvecklandet är flexibelt och iterativt.
• C# - Ett objektorienterat programspråk.
• Cross-platform - Implementation på olika plattformer
• Discord - Ett program för röst- och textchatt. Programmet är främst avsett för spelkom-munikation men kan användas för annan komspelkom-munikation. Det stödjer även skärmdel-ning.
• Facebook Messenger - En chattapplikation som är avsedd för kommunikation.. • Git - Ett versionhanteringsprogram.
• Git LFS - Ett tillägg till Git för att hantera stora filer.
• Google Drive - En molntjänst, skapad av Google. Kan användas för att spara och dela filer.
• Gren - Ett avvikande från huvudutvecklingen i Git.
• Grafiskt gränssnitt - Den grafiska mellanhanden mellan användare och program; de knappar och menyer man ser och använder.
• Fotogrammetri - metod för bestämmning av föremåls position och mått genom flera bilder.
• Iteration - En uppdelning av kursens tid. I snitt knappt en månad långa. • Karaktär - 3D-modell av en person
• Kurs - "Kandidatprojekt i programvaruutveckling", kurs vid Linköpings Universitet. • Mesh - Definierar formen av ett 3D-objekt. Består av hörn, kanter och ytor.
• Morfning - Stegvis förändring av en 3D-modell till en annan. • Obduktion - En undersökning av en död kropp.
1.5. Definitioner
• Projekt - Programfil. En fil med information om typ av modell, skador och sparade modell- och kamerapositioner för presentationsläge för ett specifikt fall.
• Rendering - De beräkningar som datorn gör för att framställa grafik.
• Skelettrig - En skelettstruktur som är kopplad till en mesh. Dess delar kan användas för att styra och böja på meshen så att den kan agera som en kropp.
• Slack - En chattapplikation där grupper och kanaler för specifika ämnen skapas. Det går även att skicka direktmeddelanden och dela filer.
• Spelmotor - Ett program som innehåller grundläggande funktioner för att skapa ett datorspel. Till exempel funktioner för att rendera grafik.
• Sprint - En tidsram där arbete ska utföras. • StabLab - Namnet på produkten som togs fram. • Tillhygge - Tillfälligt vapen.
• Vy - En uppdelning av det grafiska gränssnittet, representeras av en scen i Unity. • Unity Asset Store - Webbsida för tillägg till Unity.
2
Bakgrund
Här beskrivs bakgrunden till att projektet utförs och vilka tidigare erfarenheter gruppmed-lemmarna har inom detta område.
2.1
Kunden
Detta projekt föreslogs av Nationellt Forensiskt Centrum (NFC). De har en grupp som arbetar med forskning och utvärdering inom brottsplatsdokumentation. Det senaste året har mycket fokus lagts på att visualisera brottsplatser i 3D och en del i detta arbete har berört hur man kan visualisera skador på brottsoffer. Under hösten tog NFC fram en 3D-rekonstruktion av en docka med hjälp av fotogrammetri. Denna 3D-modell användes i ett interaktivt verktyg som kriminaltekniker kunde använda för att stegvis förklara skadorna på offret under rätte-gången.
Detta arbete sågs som mycket lyckat då det dök upp fler förfrågningar om att kunna skapa liknande visualiseringar av skador. Tyvärr är detta en mycket tidskrävande och dyr process för att framställa resultatet vilket gjorde metoden orealistisk i längden. Därför togs det fram ett förslag om ett eget digitalt verktyg för att kunna generera liknande interaktiva visuali-seringar utan fotogrammetri. Det är det digitala verktyget som det här kandidatarbetet har behandlat.
2.2
Tidigare erfarenheter
Gruppens medlemmar hade en begränsad kunskap om verktygen sedan tidigare, med några enstaka medlemmar som hade en grundläggande erfarenhet av Unity. Dock hade samtliga medlemmar gått universitetskurser som berört större systemutveckling, där sex medlemmar hade examinerats i kursen Konstruktion med Mikrodatorer (TSEA29) och en hade exami-nerats i kursen Artificiell Intelligens - Projekt (TDDD92). Samtliga medlemmar hade också examinerats i kursen Programutvecklingsmetodik (TDDC93), vars verktyg och metodik ap-plicerades på systemutvecklingskurserna. Således hade gruppen tidigare erfarenhet av pro-gramutveckling i en större grupp, och hade verktyg och erfarenheter som kunde användas till detta arbete. Den viktigaste erfarenheten var kunskapen om scrum som lärdes ut i TDDC93.
3
Teori
Kapitel 3 beskriver den teori som användaren behöver för att förstå de övriga delarna av rapporten.
3.1
Framställning av digitala modeller idag
Innan projektets utförande var det en omfattande process att gå från en obduktion till en digital modell av en kropp. När rättsläkarna fick in en kropp så gjordes en obduktion där ett obduktionsprotokoll togs fram. I protokollet framgick bland annat vilka skador personen utsatts för och var på kroppen dessa fanns. Tillsammans med en kriminaltekniker tog sedan rättsläkarna fram en fysisk docka där varje skada indikerades. För att sedan göra denna fy-siska docka till en digital modell anlitades en 3D-modellerare från polisen som med hjälp av fotogrammetri fick fram en 3D-modell av dockan i digital miljö. Denna modell kunde sedan konverteras och animeras i modelleringsprogram på datorn för att slutligen användas som presentationshjälpmedel i en rättegång.
3.2
Verktyg och programvara
Nedan följer beskrivningar av de verktyg och programvaror vi använt i projektet.
3.2.1
Unity 3D
Unity 3D [75] är en spelmotor som under de senaste åren har använts till allt fler projekt. Spelmotorn har många önskvärda funktioner för att enkelt kunna manipulera 3D-objekt. Ut-över de inbyggda funktionerna ger Unity 3D möjligheten att utöka en del funktionalitet hos motorns gränssnitt vilket gör att man kan anpassa utvecklingsmiljön till sitt specifika pro-jekt. Unity 3D har stor användarbas och är en välkänd och populär spelmotor vilket var de avgörande faktorerna för att projektgruppen valde att använda just denna spelmotor som hjälpmedel. Unity har även vissa begränsningar. T.ex. finns det inte inbyggt stöd för att öpp-na en filhanterare för att välja filer och mappar. Det finns inte heller stöd för att på ett smidigt sätt ladda in 3D-objekt från en fil på datorn under körning av programmet. Däremot finns tjänsten Unity Asset Store som erbjuder extra tillägg som kan köpas eller laddas ned gratis
för att få vissa funktioner utan att behöva göra det själv. För resterande funktionalitet som be-hövs men inte finns som tillägg på Unity Asset Store kan det programmeras i programspråket C#, som väldigt smidigt kan implementeras i Unity.
3.2.2
Blender
Blender [16] är ett komplett 3D-pipeline-program vilket innebär att man bland annat kan modellera, rigga, animera, simulera och rendera i programmet. Programmet är gratis och har öppen källkod vilket har lett till dess stora ökning i populäritet och har börjat användas av etablerade företag som Disney. Licensen ger också användaren frihet att använda allt som ren-deras från Blender helt gratis till vilket syfte som helst. Blender är dessutom cross-platform och kan köras lika stabilt på Linux, Windows och OSX.
3.2.3
MakeHuman
MakeHuman [47] är ett program där man kan skapa mänskliga modeller. Programmet gör det enkelt att ändra på kön, ålder och kroppsomfång. MakeHuman går dessutom under en öppen källkodslicens, som tillåter att allt som exporteras från programmet får användas gratis för godtyckligt ändamål.
3.2.4
Scrum
Scrum är ett ramverk för hur man kan strukturera och leda en agil verksamhet [65].
Roller
En projektgrupp som använder sig av scrum ska ha utsatt tre roller bestående av en produkt-ägare, en scrum master och ett team. Produktägaren är vanligtvis en insatt person från bestäl-laren som sammanställer och prioriterar tillägg och förändringar som önskas om produkten. Denna sammanställning skrivs ner i en product backlog, vilket är en lista med önskemål om produkten. Scrum master är den person som ser till att allting går rätt till och att utvecklings-gruppen inte stöter på några hinder. Teamet är utvecklingsutvecklings-gruppen med den viktiga detaljen av att de är självorganiserande. Det innebär att de själva bestämmer vem som utvecklar vad och hur.
Arbeta i scrum
Arbetet i scrum delas in i olika arbetsperioder som kallas för sprintar. En sprint är vanligtvis inte kortare än en vecka och heller inte längre än en månad. Varje sprint har ett sprintmål vilket är det övergripande mål man ska sträva att uppnå. Varje sprint börjar med en sprint-planering och avslutas med en sprintgenomgång och en sprintåterblick.
Sprintplaneringen, genomgången och återblicken är centrala i en scrummetod och bru-kar oftast hållas genom möten. Under sprintplaneringen ska produktägaren, scrum master och teamet tillsammans gå igenom den product backlog som produktägaren har tagit fram. Därefter ska teamet bryta ner dessa önskemål och planera hur gruppen ska åta sig dessa uppgifter. Det finns olika metoder för att tidsestimera dessa uppgifter. När planeringen är gjord sammanställs planen i en sprint backlog vilket består av uppgifter som gruppen kommer att arbeta med under den kommande sprinten. Sprintgenomgången är det tillfälle gruppen har för att utvärdera sprinten och demonstrera informellt vad som har tagits fram under sprinten. Till det här tillfället är alla intressenter inbjudna. Till sist hålls även ett tillfälle för sprintåterblicken vilket är då gruppen tittar på de erfarenheter de fått och med det som underlag försöker bestämma hur nästkommande sprintar ska utformas.
3.2. Verktyg och programvara
3.2.5
Git
Git är ett versionshanteringsverktyg som används för att på ett smidigt sätt hantera källkod. Git är distribuerat vilket innebär att det inte finns något centralt arkiv. Detta betyder att Git tillåter flera programmerare att ha åtkomst och arbeta med samma filer på distans, utan att kontinuerligt behöva skicka den modifierade koden emellan sig. [22]
3.2.6
GitLab
GitLab är ett grafiskt webbaserat program som är tänkt att förenkla hanteringen av ett Git-projekt och gör det möjligt att komma åt Git-projekt från en server. [39]
3.2.7
Git LFS
Git LFS är en tillbyggnad till Git för att hantera större filer. Git LFS kan byta ut filer mot textpekare inom Git och lagra de faktiska filerna på en server. [38]
3.2.8
Trello
Trello är en webbasrad applikation som används för att få struktur över arbetsuppgifter. [71]. Det kan ses som en slags anslagstavla för att få koll på vad som ska göras, vad som görs och vad som är gjort. Det kan också användas mer generellt för att representera exempelvis: funktioner, milstolpar, verifieringar.
4
Metod
I detta kapitel beskrivs hur projektet utförts och vilka verktyg som använts.
4.1
Projektorganisation
Vid projektets start tilldelades alla gruppmedlemmar en roll för att underlätta fördelning av arbete. Dessa roller klargjorde varje medlems huvudsakliga ansvarsområde, men eftersom arbetet skedde enligt en agil arbetsmetod var rollerna relativt flytande. Här nedan beskrivs alla rollers ansvar.
Analysansvarig - Arin Rashid
Ansvarar för kundkontakt med fokus på att hitta kundens verkliga behov. Länk mellan arki-tekt, testledare och kund. Ansvarar även för att dokumentera krav.
Dokumentansvarig - Simon Gustavsson
Ansvarar för dokumentmallar, logotyp, ändringsrutiner och leveranser till deadlines. Jobbar tätt med kvalitetssamordnare och konfigurationsansvarig.
Testledare - Viktor Barr
Beslutar om systemets status. Ansvarar för dynamisk verifiering och validering av systemet genom exekvering. Testar kvalitetskrav med kvalitetssamordnaren och ansvarar för testplan och testrapport.
Utvecklingledare - Johan Fallström
Ansvarar för detaljerad design. Leder och fördelar utvecklingsarbetet. Fattar beslut om ut-vecklingsmiljö och organiserar utvecklarens tester.
Kvalitetssamordnare - Yohan Ayoub
Ansvarar för erfarenhetsfångst i gruppen, utbildning, inspiration, planering och budgetering. Skriver även kvalitetsplan.
Arkitekt - Jacob Olausson
Ansvarar för att en stabil arkitektur tas fram, dokumenterar arkitekturen, identifierar kom-ponenter och gränssnitt samt övergripande teknikval.
Teamledare - Martin Jirenius
Leder projektarbetet, ansvarar för måluppfyllnad, projektplanen och att processer följs. Age-rar coach för projektgruppen och representeAge-rar teamet utåt.
4.2
Utbildning
Detta projekt innefattade många nya utvecklingsmiljöer och framförallt ett nytt program-språk för gruppmedlemmarna. Gruppmedlemmarna var medvetna om att det var viktigt att börja utveckla produkten tidigt då den förväntades vara klar för leverans och användning vid projektavslutet. Därför sattes det upp en plan för hur gruppmedlemmarna skulle hinna lära sig allt som var nödvändigt för att komma igång med arbetet så tidigt som möjligt. Först delades arbetet upp i 7 områden där vardera medlem fick ett primärt och ett sekundärt an-svarsområde. Därefter fick vardera medlem ansvara för att lära sig det som var nödvändigt inom dessa områden. Mycket av den informationen som gruppmedlemmarna införskaffade kom från instruktionsvideor från utvecklarna av programmen eller trovärdiga entusiaster. För att lära sig behärska nya program och språk användes tekniken learn-by-doing [63] som går ut på att små projekt - orelaterade till projektet - skapades och genomförs. Med tiden började gruppmedlemmarna bli tillräckligt insatta i de olika utvecklingsmiljöerna och pro-gramspråken, och instruktionsvideor var inte längre tillräckliga. Programdokumentationen, i synnerhet Unitys användarmanual [79], blev då en viktigt tillgång.
4.3
Samarbete
Samarbetet inom gruppen skedde genom olika kanaler beroende på arbete. Alla dokument redigerades på lagringstjänsten Google Drive. Där lagrades bland annat mötesprotokoll, pro-jekttrelaterade dokument och arbetsdokument. När gruppen arbetade på projektrelaterade dokument arbetade man nästan uteslutande i grupp. En stor del av arbetet behövde ske hemifrån varpå Discord användes. Detta var framförallt användbart när man programmera-de eller skrev på dokument då programmera-det inte var ovanligt att man haprogrammera-de information som behövprogrammera-de delas med övriga gruppmedlemmar. Eftersom det var viktigt att kunna arbeta hemifrån in-fördes det obligatorisk närvaro i Discord vissa dagar för att se till att samtliga medlemmar arbetade. Gruppens primära kommunikationskanal var Facebook Messenger. Där förmedla-de gruppmedlemmar kortsiktig information och diskuteraförmedla-de mindre viktiga ämnen för att smidigt hålla kontakten med gruppen. Däremot försvann kommentarer snabbt i Messenger vilket var anledningen till att Slack användes. Där lade gruppmedlemmar upp information som skulle vara enkelt att få tag på över längre tid, i kontrast till att leta bland kommentarer från Messenger. När projektet närmade sig slutet började gruppmedlemmar få spetskom-petens inom olika områden. Därför användes parprogrammering när funktioner som täckte flera områden togs fram.
4.4. Utvecklingmetod
4.4
Utvecklingmetod
4.4.1
Verktyg och programvara
Unity 3DUnity 3D var den primära utvecklingsmiljö som gruppmedlemmarna använde sig av. Pro-grammet användes för att skapa det grafiska användargränsnittet, funktioner för att kon-trollera 3D-modeller och filhantering. Programmet var en stor tillgång och hade många in-byggda funktioner som gruppmedlemmarna använde sig av. Bland dessa var bland annat kameramanipulering, stöd för 3D-filer, morfning av 3D-modeller, ett intuitivt sätt att bygga användargränssnitt och cross-platformstöd. Samtidigt fanns det flera funktioner som inte var inbyggda som gruppen själva fick programmera källkoden för, alternativt ladda ner eller ta inspiration från Unity Assets store. Två av dessa var naturlig filhantering och manipulering av kroppsdelar på 3D-modell.
MakeHuman
I och med att ingen i projektgruppen hade några 3D-modelleringsvanor behövde gruppen komma på ett enkelt sätt att skapa realistiska mänskliga modeller, då detta var en viktig komponent i programmet. Det var därför man beslutade att använda MakeHuman. Make-Human användes för att ta fram en kvinnlig och manlig modell, och dessutom en modell av ett barn. De kvinnliga och manliga modellerna behövde ha olika kroppsomfång och längder vilket också behövde tas fram. Detta innebar att gruppen behövde ta fram en lång/kort mo-dell, en överviktig/underviktig modell och en muskulös/icke muskulös modell samt varje kombination av dessa. Gruppen ansåg att det räckte att man endast kunde justera höjden av barnet och därför togs det bara fram olika längder av barnet.
Blender
Blender var det program som användes för att skapa de 3D-modeller som Stablab behövde ha inbyggt. Det som skapades var olika tillhyggen för att kunna visa hur en skada kan ha gått till. Dessutom användes Blender för att korrigera MakeHuman-modellerna för att passa gruppens behov. Det som framförallt behövde korrigeras var hur modellens skelettrigg var kopplat till dess mesh. Vi behövde också skapa olika kombinationer av modeller som använ-daren av Stablab skulle kunna morfa emellan. Morfningen var en tidskrävande process då det var många kombinationer som gruppen behövde ta hänsyn till. Att få alla lägen mellan extremfallen att se naturliga ut var svårt. Därför hade gruppen satt en ansvarig person för 3D-modellerna då det förutspåddes från början att detta kunde bli en flaskhals under projektets gång.
Scrum
Utvecklingen skedde enligt en variant av scrum. Gruppen hade sprintar med två veckors längd vilket ansågs rimligt för storleken på projektet. Dessutom var det smidigt med två veckor eftersom kunden också använde sig av scrum med två veckors längd. I och med detta beslutades det om att synkronisera sprintarna så att gruppens sprint började i mitten av kundens sprint. Det gjorde att kunden hade möjlighet att närvara på de sprintplanerings-möten gruppen hade. Scrum är en väldigt generell utvecklingsmetod som är skapad för att kunna användas i de flesta projekt. Därför var det naturligt att det fanns saker som inte passade just vår grupp. En av de saker som gruppen valde att prova på för att sedan lämna var dagliga scrummöten. Dessa byttes ut mot veckomöten som hölls i slutet av veckan där gruppmedlemmarna kunde dela vad de hade arbetat med under veckan. Dessutom kom man överens med kunden om att gruppmedlemmarna fick agera produktägare enligt scrum istället för kunden, vilket annars är det vanligaste.
Utöver detta hölls scrumplaneringsmöten i början av veckan där gruppen planerade sprinten som skulle inledas. I och med att gruppmedlemmarna själva var produktägare var det upp till gruppen att komma med önskemål om produkten. Detta utvecklades till brainstorming-pass där hela projektgruppen försökte komma på funktioner som saknas i programmet. När detta var klart översatte man dessa till uppgifter och lade in dem i en scrumtavla i Trello. Dessutom värderades uppgifter som inte hanns med under föregående sprint om dessa skulle föras över till nästkommande sprint.
När sprinten var slut var det dags att ha sprintutvärdering samt sprintåterblick. Dessa hölls nästan uteslutande på veckomötet som hölls i slutet av veckan. Där fick varje gruppmedlem chansen att visa en informell demonstration av vad man hade tagit fram. Det diskuterades sedan om man hade uppnått sprintmålet, och efter det gick man över till återblicken. Där diskuterade man vad man ska börja med, sluta med och fortsätta med. En utökning som gruppen kom överens om att införa var så kallade briefing-möten. Dessa möten var en mer ingående version av sprintutvärderingen med fokus på kod eller nya koncept. Dessa kunde hållas om någon i gruppen kände att man saknade en djupgående förståelse av någon annans arbete. Under dessa möten fick gruppmedlemmarna hålla en mer detaljerad demonstration av sitt arbete och gå igenom koden eller nya koncept noggrant tills samtliga medlemmar kände att man hade fått full förståelse.
Git och GitLab
Git och GitLab användes för att versionshantera produkten. För att versionshantera större filer som bilder och 3D-modeller med Git användes Git LFS. Arbetsflödet som användes för att strukturera upp grenar i Git var en variant av Gitflow Workflow (se kapitel E.5.1). Det innebär att man hade tre led av grenar, en mastergren, en utvecklingsgren och en funktions-gren. Projektets färdiga versioner hölls på mastergrenen och det var den hela arbetet utgick från. Det var på utvecklingsgrenen som all utveckling skedde. Detta var ett sätt att sära på de färdiga iterationerna av programmet och det som då höll på att utvecklas. När en gruppmed-lem skulle arbeta på en ny funktion gjorde man en förgrening från utvecklingsgrenen som man kallade för funktionsgren. Där arbetades den nya funktion fram utan att utvecklingsgre-nen ändrades. Detta på grund av att på utvecklingsgreutvecklingsgre-nen fick endast verifierade funktioner finnas. När medlemmen kände sig färdig med en funktion begärde denne att få foga sam-man sin gren med utvecklingsgrenen. Därefter var två andra gruppmedlemmar tvungna att bekräfta att funktionen inte hade några större buggar. Hade den inte det så integrerades den med resten av programmet. Efter en sprint valde gruppen om det som låg under utvecklings-grenen var tillräckligt färdigt för att klassas som produktionsklar kod och det slogs då ihop med mastergrenen som endast fick innehålla produktionsklar kod.
Trello
Trello var det verktyg som projektgruppen använde för att hålla koll på sin sprint backlog där man skapade en trellotavla för varje sprint. En trellotavla var uppdelad i fyra stadier som en uppgift kunde befinna sig i samt en övergripande kategori denne tillhörde. De fyra stadierna var To-do, In-process, To-verify och Done. Den övergripande kategorin kallades för Epics och var ett sätt för gruppen att hålla koll på vilket område man arbetade på. När en uppgift var identifierad under sprintplaneringsmötet lades den under To-do, vilket höll de uppgifter som man skulle göra under den kommande sprinten. När en gruppmedlem skulle åta sig en uppgift förflyttade han uppgiften till In-process och etiketterade uppgiften med sina initialer för att övriga gruppmedlemmar inte skulle råka arbeta på samma uppgift. När en uppgift var klar förflyttade medlemmen sin uppgift till To-verify. Då var det upp till övriga medlemmar
4.4. Utvecklingmetod
att verifiera arbetet som denne hade gjort. Om en uppgift blev godkänd förflyttades den till Done, och gruppmedlemmen kunde sedan börja på en ny uppgift.
Discord
När projektet kom igång insåg projektgruppen snabbt att produkten skulle behöva utvecklas på kraftfull hårdvara. Detta ledde till att en stor del av arbetet behövde ske på medlem-mars stationära hemdatorer. Därför började gruppen att använda sig av chatt-programmet Discord. Där gick gruppmedlemmar in när dom arbetade så att man kunde kommunicera med övriga medlemmar hemifrån. Detta var lyckat och discordmöten med obligatorisk när-varo infördes. Detta blev ett centralt verktyg för kommunikation inom projektgruppen.
Slack
Slack användes som en kanal för att kunna lägga upp och kategorisera information och mate-rial. Man använde detta när en gruppmedlem hade information som denne ville att gruppen enkelt skulle kunna få tillgång till, men som inte var tillräckligt relevant för att förvara i grup-pens gemensamma Google Drive.
4.4.2
Utvecklingsprocess
FörstudieDen första perioden i projektet var förstudien. Här var syftet att få grepp om vad vårt projekt gick ut på, lägga upp en plan för projektet och komma i kontakt med kunden. Gruppen hade tidigt som slutmål att ha en leveransklar produkt, så för att tiden skulle räcka till bestämdes att utvecklingen av programmet behövde komma igång så fort som möjligt. På grund av det-ta bokades ett möte med kund redan den försdet-ta veckan för att få deras bild av hur produkten skulle fungera och väva ihop den med hur vår bild såg ut av produkten. Tillsammans kom gruppen och kunden fram till vilka funktioner och egenskaper som var nödvändiga respekti-ve önskvärda, och sammanställde utifrån detta en kravspecifikation för produkten. Nu fanns en nedskriven bild av hur produkten skulle fungera och se ut, men innan utvecklingen kunde starta så behövdes en projektplan tas fram. Här framgick hur projektet skulle utföras, vilka verktyg som skulle användas och när de specificerade funktionerna skulle vara klara.
Sprint 1
När förstudien var klar och gruppen hade definierat vad som skulle göras och när det skulle göras var det dags att påbörja utvecklingsarbetet. Målet för den första sprinten var att kom-ma igång med Unity och bekanta sig med utvecklingsmiljön. Vi skulle också implementera grundläggande funktionalitet för rörelse av kropp, filhantering, skademarkering och att ge användaren möjlighet att röra sig i 3D rummet. Tanken var inte att funktionerna skulle vara klara för att användas i slutprodukten efter sprinten, utan mer som något att bygga vidare på i ett senare skede. Utöver implementation i Unity så identifierades 3D-modellering som en potentiell flaskhals och därför sattes en gruppmedlem som ansvarig för modellering och för att ta fram de önskade modellerna till projektet.
För att projektarbetet i ett senare skede skulle fungera smidigt så gjordes också en sats-ning av gruppen för att lära sig att använda Git [39] på ett smart och effektivt sätt, genom att bland annat sätta upp dokument som förklarade hur våra olika grenar fungerade och olika vanliga kommandon som behövde användas regelbundet.
Sprint 2
Sprint 2 var den iteration där gruppen hade planerat att stora delar av produktens funktiona-litet skulle implementeras och att ett system skulle sättas upp för att koppla ihop dessa delar. Delarna behövde inte nödvändigtvis sitta ihop i en prototyp, men ändå finnas som separata projekt med en genomtänkt struktur. Målet med iterationen blev därför att programmets övergripande processtruktur skulle vara färdig.
På grund av dokument som behövde skrivas och med en tentamensperiod i slutet av sprinten så blev resultatet inte som väntat. Gruppen nådde inte till det mål som sattes upp och det som gjordes under perioden var till största del skrivande av dokument. Detta var något som gruppen hade prioriterat ned under tidigare sprintar på grund av hur mycket av tiden som gick till implementation av programmet. Under sprint 2 tog gruppen tag i dokumentskrivning och skrev en grund till kandidatarbetet och skrev klart större delarna av de andra dokumenten (kravspecifikation, testplan, kvalitetsplan, projektplan, arkitektur-plan, systemanatomin). Det gjordes också små utvecklingar av programmet under sprinten. Framförallt gjordes framsteg inom programmets arkitektur. De uppgifter som planerats att vara klara, men som inte hade hunnits med under sprinten, fördes vidare till de uppgifter som skulle utföras under sprint 3.
Sprint 3
Denna sprint blev liknande föregående eftersom målet inte hade uppnåtts. Många av de uppgifter som togs fram i sprint 2 låg kvar i sprint 3 och målet med sprint 3 blev ungefär samma som i sprint 2 - att programmets övergripande struktur skulle vara klar. Målet med denna sprint var också att ha satt ihop alla funktionaliteter i ett första utkast till en färdig produkt. Gruppen var medveten om att denna sprint skulle kräva stor arbetsinsats för att nå målet, men samtidigt så behövde projektet komma framåt så att produkten kunde levereras vid leveransdatumet.
Under sprinten så gick mycket tid åt att skapa det grafiska gränssnittet, och ett bibliotek med ikoner och annat material som behövdes för att det grafiska gränssnittet skulle kunna implementeras med rätt utseende. I det grafiska gränssnittet kunde också programmets olika funktionaliteter sättas ihop och gruppen kunde få en bild av hur de olika funktionerna fungerade ihop. Givetvis behövdes också dessa olika delar korrigeras för att felfritt fungera ihop, och en hel del arbete gick till att få delarna att fungera på detta sätt. Till det grafiska gränssnittet implementerades också funktionalitet och grafisk representation av den lista där användaren ska kunna lägga till och välja skador. Programmet fick under denna sprint också funktionaliteten att spara all skadedata till specifika skadeobjekt, som kopplades till listan med skador. Som följd av att förståelsen för hur Unity fungerade och insikt i hur programmet borde vara uppbyggt så förbättrade gruppen under denna sprint också programarkitekturen genom att påbörja användning av bland annat ett observatör-system[53]. Slutresultatet av sprinten var att det fanns en färdig prototyp som hade de viktigaste funktionerna i program-met implementerade och ett snyggt grafiskt gränssnitt som följde den standard som satts upp i designmanifestet(Se Bilaga I).
Sprint 4
Efter att en prototyp av programmet hade framställts i sprint 3, kände sig gruppen ganska bekväm med att nu lägga gott om tid till skrivande av dokument, då inlämningen av dessa började närma sig. Målet med sprint 4 blev därför att skriva klart ett första utkast av kandi-datrapporten och färdigställa de övriga dokumenten.
4.5. Metod för att fånga erfarenheter
och nådde på så sätt målet att ha ett första utkast av kandidatrapporten klart och de övriga dokumenten färdiga. Under sprinten ändrades också funktionen för kroppspositionering till att använda sig av 3D-Gizmos istället för att använda sig av musens position för förflyttning.
4.5
Metod för att fånga erfarenheter
För att fånga erfarenheter sattes ett dokument upp, där varje gruppmedlem fick skriva om dagen varit produktiv eller inte samt varför. Detta gav en bra bild av vilka erfarenheter varje medlem kunde ta med sig från varje dag. Vi hade även möten där alla medlemmar fick gå igenom det de hade hunnit göra i Unity eller Blender och fick hålla föredrag för resten av medlemmarna om vad de lärt sig om programmen.
Briefing-mötena blev också ett sätt att fånga erfarenheter. De hölls när gruppen kände att mycket arbete hade gjorts och alla medlemmar hade divergerat ifrån varandra. Mötena var relativt informella men gjorde så att alla medlemmar fick en grundläggande förståelse av vad andra gjort och för att lära sig av varandra.
5
Resultat
Här beskrivs vad gruppen har framställt och vad slutprodukten innehåller.
5.1
Systembeskrivning
Produkten beskrivs bäst med två system: ett arkitektursystem och ett gränsnittsystem. Ar-kitektursystemet visar på programmets modularitet, generella upplägg och kopplingarna i programstrukturen medan gränsnittssystemet visar vilken användarupplevelse programmet ska förmedla.
5.1.1
Arkitektursystem
Strikta konventioner har använts när det kommer till vilken kod som får kommunicera med annan kod och göra vad. Den övergripande konventionen behandlar Managers, Controllers och dataklasser. En Manager behandlar ofta funktioner som behöver påverka många under-klasser och används för att bidra till färre kopplingar mellan under-klasser. Exempel på Managers i programmet är ProjectManager, DataManager, FileManager och SceneManager. Controllers hanterar hur individuella objekt eller klasser styrs. Exempel på detta i programmet är Ca-meraController och ModelController. Dataklasser innehåller en mängd data och funktioner som måste kunna sparas och hämtas även efter att programmet har avslutats. Exempel på detta i programmet är ProjectData, InjuryData, CameraData och SettingsData. För mer infor-mation om de ingående arkitekturdelarna och klassificeringen hänvisas läsaren till projektets arkitekturdokument i bilaga H.
5.1.2
Gränssnittssystem
Gränssnittet är en av de viktigaste komponenterna i programmet, i och med att kunden vär-desätter användarvänlighet högt. Här beskrivs hur användargränssnittet är utformat och hur flödet i programmet ser ut.
Flöde
I figur 5.1 beskrivs flödet mellan de olika scenerna i programmet. Dessa vyer beskrivs i detalj senare i avsnittet.
Figur 5.1:Flödesschema mellan scener
Generella designdrag
Vissa komponenter på skärmen är gemensamma för alla scener i programmet, och det är dessa som är viktigast att användaren kan förstå och hantera. Först och främst rör det sig om menyn högst upp till vänster, som endast skiljer sig i presentationsvyn. Där har användaren möjlighet att skapa ett nytt projekt, spara nuvarande projekt och ladda ett sparat projekt. Utöver dessa vanliga operationer finns också möjligheten att här ändra inställningar för och få upp en hjälpruta för den nuvarande scenen. De två senare har samma funktion över alla scener, men dess innehåll är specifikt för scenen. De andra knapparna (nytt, spara och ladda) är scengenerella, och har samma funktion i alla scener.
Kameran styrs med kamerastyrningsknappar nere i högra hörnet. Det finns fyra knap-par för att förflytta kameran i x- och y-led relativt till kamerans nuvarande riktning. Detta illustreras med raka pilar åt respektive riktning. Det finns fyra böjda pilar som representerar rotation av kameran runt kroppen i respektive riktning. Möjligheten att zooma in och ut illustreras av knappar med ett plus och ett minus. Kamerastyrningsknapparna fungerar likadant och har samma utseende över alla scener i programmet.
Knapparnas utseende är utformade för att ge användaren ett intuitivt intryck av vad som kommer hända när knappen trycks ned. För att ge användaren ytterligare information om vad som kommer hända vid interaktion med en knapp, ger användargränssnittet informa-tion via text då musen hålls över knappen. I texten framgår vad ett tryck på knappen innebär och vilken funktion knappen har.
När användaren försöker göra en ändring som potentiellt skulle låta osparade föränd-ringar gå förlorade framträder promptrutor. Ett exempel är att användaren försöker ladda en ny fil under tiden denne jobbar på ett annat projekt. Då ger promptrutan användaren möjligheten att avbryta operationen. Dessa finns till om användaren skulle klicka fel eller inte tänkt igenom konsekvenserna av knapptryckningen.
Startvyn
Den första skärmen som användaren får interagera med är startskärmen (se figur 5.2). För att intuitiviteten ska vara så stor som möjligt är det här väldigt få knappar. Det är tydligt vad användaren har för val och vilka funktioner de olika knapparna har. Genom att utvid-ga möjligheterna utifrån vilken knapp som användaren trycker på blir programförloppet
5.1. Systembeskrivning
stegvis vilket ger ett enkelt och tydligt sätt för användaren att ta sig framåt i programmet. Användarvänlighet prioriterades före smidighet, så för att skapa ett nytt projekt krävs det att användaren klickar sig från CREATE NEW till FILENAME och väljer namn samt var filen ska sparas genom FILE PATH och sedan CREATE. Det krävs många klick för en enkel operation, men eftersom användargruppen särskilt har efterfrågat enkelhet har programmet generellt många klick som skulle kunna förkortas ner till smidigare vägar genom programmet. Det skulle dock krävt en användare med större kunnighet inom digitala verktyg, och det kan inte antas om den generella kunden.
I startskärmen finns utöver CREATE NEW möjligheten att öppna ett redan existerande projekt. Detta görs via OPEN FILE som ger användaren möjligheten att välja vilken fil som ska öppnas via filhanteraren. Det är ett välanvänt och känt sätt att lokalisera filer på. Detta anses vara intuitivt och tillräckligt enkelt för att en användare med grundläggande kunska-per ska klara av att slutföra uppgiften. När filen öppnas tas användaren direkt till skadevyn där denne kan ändra och lägga till skador.
Den sista funktionen som användaren har möjlighet att nå på startskärmen är OPEN RE-CENT. Detta, som namnet antyder, öppnar den senaste arbetade filen utan att användaren behöva söka och lokalisera filen i filhanteraren. Genom att i fildatan spara ner filvägen till det projekt som senast använde i programinställningar så kan programmet alltid öppna det senaste projektet, vilket gör programmet lättstartat och då också ger en låg tröskel till att faktiskt fortsätta med arbete som inte är slutfört.
Figur 5.2:Startskärm
Karaktärsskapandevyn
När en användare skapar en nytt projekt får denne välja vilken karaktär som projektet ska innehålla. Detta görs i karaktärsskapandevyn (se figur 5.3). Varje projekt kan endast ha en karaktär, eftersom syftet med programmet är att visualisera skador på en person. Om ett brott har begåtts där flera personer fått skador, så betraktas dessa som separata fall och representeras därmed med olika projekt i programmet.
För att projektets karaktär ska representera personen som erhållit skadorna får använda-ren möjlighet att ställa in dess utseende. Användaanvända-ren får möjligheten att välja mellan man, kvinna och barn och kan sedan forma den valda karaktären genom tre reglage. Första reg-laget ställer in längden på karaktären, andra regreg-laget ställer in vikten på karaktären och det tredje reglaget ställer in proportion mellan muskler och vikt. Genom att kombinera dessa tre reglage så kan användaren nå en nära bild av hur personen som ska modelleras faktiskt
såg/ser ut. Det finns dock ingen möjlighet att ställa in utseendet i ansiktet hos karaktären och detta är ett medvetet val som gruppen tagit tillsammans med kunden. Eftersom programmet syftar till att användas under rättegång så kan ett alltför karaktäristiskt utseende hos mo-dellen ge opassande och negativa bilder av målsägande. Det underlättar inte heller arbetet för de som tar fram modellen. Däremot är det viktigt att karaktären har rätt kroppstyp och kroppsomfång då detta påverkar hur skadorna sitter på personen och hur viktig modellen är för juryns beslut under en rättegång. Detta gjorde att vi tog beslutet att programmet endast ska kunna ändra kroppstypen hos karaktären.
Figur 5.3:Karaktärsskapandevyn
Skadevyn
Den största delen av arbetet i ett projekt sker i skadevyn. Här lägger användaren till alla skador och informationen om dem. Alla skador som läggs till sparas med ett ID-nummer och ett namn. Dessa läggs till i en lista sorterad efter ID-numret. Den information som sparas till varje skada är:
• Namn och ID • Kroppsställning
• Kamerans position i rummet • Typ av skada
• Skadans position på kroppen • Tillhyggets färg
• Lista av bilder • Informationstext
Användargränssnittet för skadevyn är upplagt så att all information kan matas in på samma ställe: i den vänstra panelen. Endast en skada kan vara markerad åt gången. Informa-tionen som visas och kan ändras i panelen gäller den markerade skadan. När ingen skada är markerad åker panelen in till vänster för att tydligt visa användaren att det inte finns någon skada att redigera.
5.1. Systembeskrivning
också själv rotera kroppsdelarna så att alla möjliga kroppsställningar kan uppnås. För att godkänna ändringarna finns här en knapp DONE som godkänner ändringarna och då ändrar positionen. Vill användaren istället återvända till ursprungspanelen utan att ändra till nya kroppsställningen så kan denne istället välja att klicka på knappen RESET som återställer kroppens ställning till vad den var innan användaren gick in i CHANGE POSE.
Figur 5.4:Ändra ställning på karaktär
Samma design används då användaren ska ändra skadetyp, position på skadan och färg på skadeikonen. DONE och RESET har samma funktion i alla momenten, men den data som ändras skiljer sig givetvis mellan de olika funktionerna. När användaren försöker ändra skadetyp så får denne välja mellan fyra olika alternativ på skador: krosskada, skottskada (ingångs- och utgångshål), stickskada och skärskada. Då skadans position ska bestämmas finns endast möjligheten att godkänna med DONE eller återställa med RESET. Här får an-vändaren klicka på den position på kroppen där skadan ska placeras och därför krävs inga alternativ i panelen. Till sist får användaren välja en färg på skadeikonen. Användaren kan då välja en av de tillhandahållna färgerna eller ta fram en egen färg med hjälp av ett färgvals-verktyg. Vad färgen representerar är upp till användaren, om det så är vissheten på skadan eller att skilja olika tillhyggen åt. När användaren matat in all information om skadan på modellen så finns även möjlighet att lägga in bilder och text till den aktiva skadan. Bilderna kan senare visas i presentationsläget när den aktiva skadan visas upp. Det finns möjlighet att lägga in så många bilder som önskas och dessa går att bläddra mellan genom två pilar vid sidan om bilden.
Presentationsvyn
Detta är den del av programmet som är ämnad att användas vid presentationer (se figur 5.6). Vyn påminner starkt om skadevyn, men de menyelement som hanterar modifiering av skador har nu bytts ut till statiska fält för metadata. Den vänstra menyn innehåller därför ett verktyg för att visa en skadas bilder och text. Skadelistan är också där, men knappen för att lägga till en skada är dold. Menyn uppe till vänster är utbytt mot skade-ID, namn på skada och knappar för att fokusera kameran och ställa tillbaka 3D-modellens kroppsställning. En knapp finns också längst ner till vänster som tar användaren tillbaka till skadevyn.
5.2. Systemanatomi
5.2
Systemanatomi
Två systemanatomier togs fram tidigt i projektet för att få en helhetsbild över hur program-met skulle fungera. En systemanatomi över hela systeprogram-met som visas i figur 5.7 och en mer specifik systemanatomi om hur framtagningen av och interaktionen med modellen för krop-pen var tänkt att fungera visas i figur 5.8. Dessa anatomier användes dock inte i det slutgiltiga programmet.
Figur 5.7:Systemanatomi 1
Figur 5.8:Systemanatomi 2
5.3
Dokument
Nedan följer en beskrivning av de dokument som togs fram under projektet.
Kravspecifikation definierar och tydliggör krav som sätts på produkten.
Kvalitetsplan är en plan för hur arbetet ska fungera för att uppnå kvalitet.
Arkitekturdokument ger en beskrivning av systemet, sett från dess komponenter.
Testplan beskriver hur olika funktioner i produkten testas.
Riskplan identifierar risker och beskriver hur dessa ska åtgärdas.
5.4
Värde för kunden
Genom att använda ett program som förenklar skadevisualiseringen kan mycket tid sparas. Istället för att jobba med en docka som sedan skannas in och manipuleras i ett 3D-program kan alla steg göras direkt i programmet. Genom att sänka antalet övergångar mellan verktyg så minskar också risken för mänskligt felande.
Mycket av de designbeslut som togs fram var med avseende på hur kunden bäst kan förstå och använda produkten på ett intuitivt sätt. Kunden bidrog med en referensgrupp och produkten anpassades efter deras kommentarer och önskemål.
5.5
Gemensamma erfarenheter
Genom att arbeta på ett projekt tillsammans med en kund, som haft specifika krav på hur slutprodukten ska fungera och se ut, har gruppen fått med sig flera viktiga erfarenheter. Att inte bara få jobba med den bild som man själv har haft i huvudet, utan att gemensamt diskutera med kund för att komma fram till den modell av produkten som alla parter känner sig nöjda med var en viktig erfarenhet för samtliga gruppmedlemmar. En stor del av arbetet bygger på kompromisser och justeringar av den egna bilden av produkten efter andras tankar och idéer, och det är en lärdom och erfarenhet som alla i gruppen kommer ta med sig. Många i projektgruppen var obekanta med 3D-utveckling och i synnerhet med utveck-lingsmiljön Unity innan projektstarten. Detta har lett till att samtliga gruppmedlemmar har utvecklats både inom programutveckling i Unity och att jobba med 3D-modellering i Blender. Denna kunskap kommer med stor sannolikhet vara användbar i framtiden då 3D-modellering är något som ofta är åtråvärt bland uppdragsgivare.
Under projektets gång har gruppmedlemmarna behövt revidera och modifiera program-met efter att problem har uppenbarat sig och behövt lösas. Detta har medfört en utökad förståelse för hur ett effektivt program är uppbyggt och hur koden bör vara strukturerad för att kunna behålla särskild funktionalitet trots att systemet förändras. Hur man skriver modulär kod och varför det är nödvändigt är en lärdom samtliga medlemmar kommer att ta med sig i framtiden.
En erfarenhet som gruppen fick den hårda vägen var konsekvensen av en bristfällig ar-kitektur. Gruppen kunde tidigt börja utveckla och bli bekanta med utvecklingsmiljön, programspråket och de verktyg som fanns tillhandahållet. Eftersom det är något oortodoxt att utveckla den här typen av program i spelmotorer fick gruppen till största del komma på egna system för att lösa många problem. Under projektets gång började gruppen få förstå-else för användbara designmönster och effektiva funktioner och en arkitektur kunde börja framställas. Denna arkitektur togs fram vid sidan av det dåvarande systemet vilket ledde till att arkitekturen, trots att den var klar sedan länge, inte hann migreras in i systemet fören sent i projektet. Lärdommen är att det kan vara bättre att byta ut det gamla systemet på en gång istället för att försöka göra det simultant.
5.6. Översikt över individuella bidrag
En annan erfarenhet gruppen fick var att det var en bra ide att använda sig av muntlig kommunikation så mycket som möjligt, med till exempel Discord, istället för skriftlig kom-munikation när gruppmedlemmarna befann sig på olika platser. Det gjorde det mycket lättare att diskutera olika idéer, förslag och lösningar utan att missförstå varandra. Däremot att sitta tillsammans med hela gruppen på samma plats fungerade helt klart bäst och gav det effektivaste arbetet.
Ett råd till nästa års studenter är att lägga stor vikt vid kravspecifikationen. Att ha en tydlig och väl genomtänkt kravspecifikation gjorde att gruppen visste vad som skulle gö-ras och vad som kunden förväntade sig av programmet. Tyvärr framgick det vid slutet av projektet att det fanns funktioner som kunden inte hade nämnt när kravspecifationen togs fram men som ändå önskades i programmet. Att få kunden att tänka igenom hur den vill ha produkten och att få fram så konkreta och korrekta krav som möjligt kommer att förenkla utvecklingsprocessen. Dessutom bör detta leda till en nöjdare kund.
Ett till råd till nästa års studenter är att få tillgång till en referensgrupp tidigt i projektet, framför allt om programmet kräver en användarcentrerad design. Gruppen fick inte tag på en full referensgrupp föränn programmet var färdigt. Då uppdagades det okända krav och önskemål, från de faktiska slutanvändarna, som varken gruppen eller kunden var medvetna om. Att vara frågvis och duktigt tolka de tankar som kunden har är därför inte nog om kun-den själv inte har hela sanningen. Detta är något som givetvis kan ligga utanför gruppens påverkan, men en lärdom likväl om hur det kan gå.
5.6
Översikt över individuella bidrag
Detta delkapitel behandlar samtliga gruppmedlemmars individuella bidrag.
A. En spelmotors påverkan på ett projekt som vårt av Martin Jirenius
Tidigt i projektet var gruppen tvungen att välja mellan om de skulle göra en egen 3D-motor för programmet eller om en befintligt skulle användas. I det här individuella bidraget kom-mer fördelarna med en egen 3D-motor jämfört med en befintlig motor att studeras. I resultatet redogörs huruvida gruppen anser vad som hade passat det här projektet genom en under-sökning och under diskussionen kommer man försöka dra slutsatser utifrån svaren.
B. En jämförelse mellan 3D-spelmotorerna Unity 3D och Unreal Engine 4 av Arin
Rashid
I ett projekt som detta där det varit mycket diskussioner huruvida vi ska använda Unity 3D eller Unreal Engine 4 kände jag att det vore intressant att jämföra dessa två spelmotorer för att se om någon faktiskt är bättre och om vi valde rätt.
C. Lärstilar och Learn-by-doing av Jacob Olausson
Detta projekt krävde att de gruppmedlemmar som saknade erfarenhet av programmet Unity 3D var tvungna att snabbt lära sig hur programmet kunde användas för att utveckla nya avancerade program. Här använde sig gruppen av olika metoder, men de flesta utgick från metoden Learn-By-Doing. Detta fick mig att undra, är det lämpligt att alla gruppmedlemmar använder samma metod för att lära sig? och vilka missgynnas av tidspressen som finns i projektet och varför?
D. Hur kan ikoner användas i ett program för att öka förståelsen? av Johan
Fallström
Här undersöks och jämförs ikoner som visuellt redskap med användandet av text. Avsnittet innehåller även en kort historisk beskrivning av några vanliga ikoner, då sett till mjukvara.
E. En jämförelse mellan olika Git-arbetsflöden av Simon Gustavsson
I detta avsnitt följer en jämförelse mellan olika populära Git-arbetsflöden och en undersök-ning om arbetsflödet som användes i projektet var optimalt eller om ett annat arbetsflöde borde ha valts.
F. Hur kan 3D-rekonstruktioner påverka rättsprocesser och forensik av Viktor
Barr
Efter terrordådet på Drottninggatan 2017 konstruerades en 3D-rekonstruktion som visade hur händelseförloppet gick till för att visas i rättegången. Teknik för att scanna in hela brotts-platser till ett virtuellt 3D-rum finns och har använts i rättegångar. I detta delkapitel under-söks hur 3D-rekonstruktioner av brottsfall kan påverka brottsbekämpning och rättsprocesser.
G. Blender och MakeHuman i ett projekt av Yohan Ayoub
I detta avsnitt diskuteras vilket 3D-modelleringsprogram som är optimalt för detta projekt. För- och nackdelar med de olika programmen diskuteras och jämförs.
6
Diskussion
I detta kapitel diskuteras och analyseras de olika delarna av rapporten.
6.1
Resultat
Nedan följer en analys av resultatet från projektet.
6.1.1
Användarvänlighet
Varje designbeslut som tagits har i någon mån utgått från dess användarvänlighet. Gräver vi lite i de tankar och diskussioner som utformat programmet så blir detta väldigt tydligt. De flesta designbeslut som beskrivs nedan finns också beskrivna i det designmanifest som använts som referensmaterial under projektets gång (Se Bilaga I).
Färgval
Programmet använder huvudsakligen 3 färger: ljusgrå, mörkgrå och blå. Den vitaste och den svartaste färgen undveks då dessa färger varierar starkt beroende på vilken skärm som programmet visas på. De står dock i god kontrast mot varandra, så att programmets menye-lement tydligt ska synas om det visas upp med projektor. Mörkgrå är den dominanta färgen då ett mörkt färgtema är bekvämare för ögonen och bättre lämpar sig för att användas under längre perioder. Den blå färgen valdes då det också står i god kontrast mot de andra färgerna och för att blått ger ett lugnt men seriöst intryck.
Förutom dessa huvudfärger så användes tre till i mindre utsträckning: röd, grön och beige. Röd används för alla element som tar bort något, och grön används för alla element som lägger till något. Röd och grön är komplementfärger och de används ofta som motpoler (tänk på trafikljus, som ett allmänt exempel). Den beige färgen används endast till knappen för att öppna ett projekt, som föreställer en pappersmapp. Detta för att pappersmappar ofta är tillverkade av oblekt papper.
Formval
Figur 6.1:Exempel på tidig knappdesign.
I början av projektet så gick vi efter ett annat formspråk på programmet. Då var fokus på att knappar skulle efterlikna fysiska knappar, i det att de skulle se ut som en upphöjd yta som kunde tryckas ned (Se: Figur 6.1). Vi lämnade dock denna design senare i arbetet, och gick istället för en mer modern design som lånar inspiration från den aktuella versionen av operativsystemet Windows (Se: Figur 6.2). Här är formspråket rektangulärt, med undantag för reglagebanor och enskilda knappar. Helfärger används genomgående i programmet, och eventuella övergångar är diskreta förutom när sidomenyn visas/döljs.
Knappar kommer i två utföranden: textknappar och ikoner. Textknapparna är rektanglar som varierar sin bredd efter innehållet, som är en textsträng. Den innehållande texten be-rättar då vad knappen är till för, och knappens färg styrker, om det är möjligt, detta syfte. Ett exempel är knappen DELETE i skadevyn som har en röd bakgrund då den tar bort den nuvarande skadan. Ikoner används istället där det råder konventioner för vad en sådan ikon betyder. Det tydligaste exemplet återfinnes i filhanteringsknapparna, som föreställer ett pap-persark (med ett tillagt grönt plus efter önskan av kunden), en diskett och en pappersmapp. Dessa är ikoner som kan återfinnas i program sedan den tid när disketter fortfarande var den dominanta lagringsenheten. Till höger om dessa ikoner finns det två knappar som också försöker förmedla sitt syfte genom metaforer. Knappen för inställningar har en ikon som föreställer en skiftyckel för att beskriva korrigering och inställning. Knappen för hjälp är i form av ett frågetecken. Detta för att förmedla att det är dit användaren kan vända sig om något känns oklart med programmet. Något som är gemensamt för alla knappar är att de lyses upp om användaren håller muspekaren över dem, och blir mörkare om de trycks ned. Detta för att förstärka visuellt för användaren att knapparna svarar på dess interaktion.
6.1. Resultat
Figur 6.2:Exempel på aktuell knappdesign.
Det finns också menyelement som kan aktiveras och avaktiveras. Detta gäller navigerings-pilar för skade- och bildlistan samt för kryssrutor. Navigeringsnavigerings-pilar berättar för användaren att de går att använda om de är blå, medan de är mörkgrå om de är avstängda. Kryssrutor är istället blå om de är valda och mörkgrå när de inte är det.
Skadelistan har gått igenom en del revideringar under projektet. Till en början skissades den som en radlista i menyn till vänster, då listor ofta går uppifrån och ned. Detta byttes i sinom tid ut till en horisontell lista som är placerad vid skärmens nedre kant. Detta beslut togs av två anledningar: dels för att menyn behövde rymma andra element, dels för att en horisontell lista efterliknar en tidslinje, vilket förstärker att skadorna bildar ett händelseför-lopp.
Programflöde
Programflödet är format för att erbjuda användaren ett fåtal menyelement åt gången. Detta för att motverka att användaren ska känna sig överrumplad med för många alternativ. Pre-senteras de istället i etapper så blir det lättare för användaren att lära sig vad varje element gör, och det välkomnar användaren till att själv utforska programmets funktioner. Program-met är uppdelat i fyra särskilda vyer, som alla erbjuder en viss typ av funktionalitet. Detta gör det lätt för användaren att få en överblicksbild om var denne kan finna en önskad funk-tionalitet. Dessa vyer presenteras också för användaren i utförandeordning: för att kunna presentera skador så behöver skador ha satts ut. För att ha något att sätta ut skadorna på så måste karaktären ha skapats, och för att kunna skapa en karaktär så måste ett projekt ha skapats eller valts.
Tidigare i programutvecklingen så tillhandahölls vyerna för användaren på ett annorlunda sätt. Startvyn existerade inte, utan användaren togs istället till en tom 3D-rymd där endast den övre sidomenyn fanns presenterad. Efter att ha skapat ett projekt så visades det sedan tre knappar vid skärmens nedre kant, där alla ledde till en av de kvarvarande vyerna (Se Figur 6.3). Då var tanken att det skulle vara lätt att intuitivt navigera mellan vyerna, samt att det då skulle gå att ändra på karaktären även efter att skador satts ut. Denna design avskaffades av flera anledningar:
• Till en början övergavs idéen om att kunna återvända till karaktärsvyn relativt tidigt. Det hade varit svårt att implementera, då skadorna hade behövts följa med när använ-daren antingen ändrade på en karaktär eller bytte ut den helt. Slutanvänanvän-daren skulle inte ha ett behov att behöva ändra på kroppen när den väl börjat sätta ut skador.
• En annan annan anledning att lämna designen var för att knapparna hade behövt kon-kurrera med skadelistan om skärmutrymme. En tanke var att presentera knapparna där presentationsknappen sitter nu, men då hade dess centrala funktion för program-met inte framgått lika bra. Att sätta dem mitt i nedre kant var just för att förstärka hur viktiga de var.
• Det var också svårt att hitta en god design till knapparna. Ikoner testades men det var inte intuitivt ens för gruppmedlemmarna vad de representerade. Även textknappar testades, men då tog de istället för mycket plats. Av dessa orsaker valdes till sist det nuvarande flödet mellan vyerna, och gruppmedlemmarna upplever själva att det var ett klokt beslut.
Figur 6.3:Tidig designskiss.
Verktygsutformning
De verktyg och funktionaliteter som programmet erbjuder är i en form som ska vara enkel att använda. Det innebär ofta att en del funktionalitet begränsats eller rentav hoppats över för att stärka användarvänligheten. Under gruppens spånande av vad programmet ska innehålla så fick vi ofta stanna upp och fråga oss själva om en funktion stärkte användarvänligheten eller endast var en bekvämlighet för den datorvane.
Ett sådant exempel är hur kameran styrs i programmet. I nuläget finns det två sätt: di-rekt med musen eller med kameraknapparna i programmet. Musstyrningen efterliknar det styrningssätt som vi i gruppen känner igen från liknande program som använder en 3D-vy. Det är en konvention som vi är bekväma med, då vi stött på den förut. Vi insåg dock att det inte är en självklarhet att slutanvändaren är lika van med denna styrning, så därför lade vi in kameraknappar i programmet. Med hjälp av att interagera med dessa knappar så kan användaren styra kameran lika exakt som denne hade kunnat göra med musen, men skillnaden är att dessa presenteras tydligare för användaren och fungerar rent interaktivt på samma sätt som övriga knappar i programmet.
Vi funderade även på att ha en låd-zoom i programmet. Det innebär att användaren mar-kerar en area på skärmen, och att då programmet zoomar så att denna area fyller skärmen. I slutändan så skippade vi denna funktion, just för att den inte bidrar med någon nytta för slutanvändaren som inte övrig kamerastyrning redan fyller. Det fanns också risk att
