Livslinjer. Visualisering av data från psykospatienters återhämtningsprocess

Linköpings universitet Insitutionen för teknik och naturvetenskap Kandidatarbete Medieteknik Vårterminen 2016 Team B: LiU-ITN-TEK-G--16/014--SE Livslinjer Visualisering av data från psykospatienters återhämtningsprocess Fanny Aldén Isac Algström Kristin Bäck Dennis Hammer Sofia Höglund Anton Kaiser Examinator: Karljohan Lundin Palmerius Linköpings universitet SE-581 83 Linköping 013 28 10 00, www.liu.se

Sammanfattning Den här rapporten beskriver ett Medieteknisk kandidatarbete utvecklat i en kurs på Linköpings Universitet. Kunden till projektet är forskare inom psykiatrin och projektet avser utveckling av en webbapplikation för visualisering av data över tid. Datan kommer från olika myndigheter och syftet med användandet av applikationen är att kunna studera återhämtningsprocessen för patienter med diagnosen psykos. Rapporten beskriver, diskuterar och analyserar utvecklingen och resultatet av arbetet. Den Agila utvecklingsmetodiken Scrum är beskriven och ligger till grund för projektgruppens rutiner. Efterforskningar inom visualisering och val av verktyg finns beskrivna och motiverade utefter kvalitetskraven. Projektgruppen har, genom att använda medietekniska kunskaper, uppfyllt kundens kvalitetskrav och skapat en applikation som kunden kan använda för att studera sin data. Applikationen som utvecklats i detta projektet förbättrar forskarnas möjlighet att hitta mönster i datan, vilket kan bidra till effektivare återhämtningsprocesser för personer som diagnostiserats med psykos. i

Innehåll Sammanfattning Figurer Tabeller Konventioner, förkortningar och termer i v vi vii 1 Inledning 1 1.1 Syfte... 1 1.2 Frågeställningar... 1 1.3 Avgränsningar... 2 1.4 Bakgrund... 2 2 Relaterat arbete 3 3 Utvecklingsmetodik 4 3.1 Agil utveckling - Scrum... 4 3.2 Projekthantering... 4 3.2.1 Planering och genomförande... 5 3.2.2 Möten... 6 3.2.3 Expertmöten... 7 3.3 Rutiner... 7 3.3.1 Dokumentation... 7 3.3.2 Krav och versionshantering... 8 3.3.3 Testning... 8 4 Teknisk beskrivning 9 4.1 Systemarkitektur... 9 4.1.1 Klient... 9 4.1.2 Server... 10 4.1.3 Databas... 11 ii

INNEHÅLL INNEHÅLL 4.2 Programdesign... 11 4.3 Utvecklingsverktyg... 12 4.4 REST... 12 4.5 Visualisering... 13 4.6 Gränssnitt... 13 5 Resultat 14 5.1 Visualisering... 14 5.2 Gränssnitt... 15 6 Analys och diskussion 17 6.1 Utvecklingsmetodik... 17 6.1.1 Agilt... 17 6.1.2 Projekthantering... 17 6.2 Diskussion om förutsättningar... 18 6.3 Resultat... 18 6.4 Prototyper... 19 6.5 Gränssnitt... 19 6.6 Användartester... 19 6.7 Arbetsfördelning... 20 6.8 Mål... 20 6.9 Arbetet i ett vidare sammanhang... 21 7 Slutsatser 22 7.1 Frågeställningar... 22 7.2 Framtida arbete... 22 Litteraturförteckning 24 A Kvalitetskrav 25 B Gruppkontrakt 26 C Arbetsfördelning 27 D Användartester 28 D.1 Användartest 1 (2016-03-18)... 28 D.2 Användartest 2 (2016-04-27)... 28 E Färger och händelser 29 iii

INNEHÅLL INNEHÅLL F Gränssnittet 30 G Menyn 32 iv

Figurer 3.1 Gantt-schema.... 5 4.1 Övergripande systemarkitektur.... 10 4.2 Klientdelens uppbyggnad och kommunikation internt och med server.... 10 4.3 Serverns uppbyggnad och kommunikation.... 11 4.4 Databas och dess kommunikation.... 11 5.1 Detaljnivå 1.... 14 5.2 Detaljnivå 2.... 15 5.3 Detaljnivå 3.... 15 6.1 Applikationen i början av projektet.... 20 B.1 Gruppkontrakt... 26 E.1 Färglegend... 29 F.1 Tidslinjen.... 30 F.2 Visar en visualisering när hovringsfunktionen används.... 31 G.1 Applikationens startsida.... 32 G.2 Applikationen när menyn är utfäld.... 33 G.3 Applikationen när olika val är ifyllda.... 33 v

Tabeller 1 Stilar... vii 2 Förkortningar... vii 3 Ordlista... vii vi

Konventioner, förkortningar och termer Här beskrivs de typografiska konventionerna som används i rapporten. Tabell 1: Stilar Utseende Förklaring Exempel Kursiv stil Engelska termer En sprint innehåller... Fet kursiv stil Namn på programvaror Då användes programmet Webstorm... Courier New Kod Funktionen är skriven i fillarray()... Förkortning HTML SVG DB CSV CSS D3 FS URI API REST Tabell 2: Förkortningar Förklaring Hyper Text Markup Language Scalable Vector Graphics Databas Comma Separated Values Cascading Style Sheets Data-Driven Documents File System Uniform Resource Identifier Application Programming Interface Representational State Transfer Ordlista Applikation Projektgtrupp Händelse Matlab-script Bugg Brushing Identifikationsnummer Tabell 3: Ordlista Förklaring Produkten som skapats i projektet De personer som arbetat med projektet Specifik händelse för en patient, tex. slutenvård En samling av MATLAB-kommandon, sparade i en textfil Felaktighet i applikationens kod Färgmarkering av händelser i visualiseringen I databasen har varje patient ett unikt identifikationsnummer vii

Kapitel 1 Inledning Den här rapporten behandlar ett projekt där en kund med flera intressenter har efterfrågat en produkt. Produkten i fråga är en webbapplikation som ska visualisera data, insamlad under en tidsperiod på tio år. Applikationen syftar i första hand till att visualisera datan över tid, där datan innehåller information om personer med allvarlig psykisk funktionsnedsättning. Applikationens syfte är att hjälpa forskare att försöka urskilja återhämtningsmönster för dessa personer. Projektgruppens uppgift är att skapa en applikation för att läsa in datan, analysera den och utifrån det visualisera den på bästa möjliga sätt för en bestämd målgrupp. Rapporten är en del av kursen Medietekniskt kandidatprojekt vid Linköpings universitet. Projektet görs på uppdrag av flera forskningsinstitutioner genom Katerina Vrotsou, forskare inom visualisering vid Linköpings Universitet. Forskningsinstitutionerna är FoU Södertörn, Institutionen för Socialt arbete vid Stockholms universitet, Länssjukhuset Ryhov i Jönköping och Psykiatri Södra Stockholm. De har ett pågående forskningsprojekt där de studerar återhämtningsprocessen för människor diagnostiserade med psykos. 1.1 Syfte Syftet med projektet är att utveckla en visualiseringsapplikation som ska användas för att synliggöra återhämtningsprocessen för personer med psykisk funktionsnedsättning. Användare ska genom applikationen kunna navigera sig genom registerdata. Förhoppningen är att forskarna ska kunna använda verktyget för att analysera och filtrera sin data, dra slutsatser kring återhämtningsprocessen hos patienter samt kunna se mönster i datan. Produkten tas fram utefter krav från kund (Bilaga A) och den projektplan som skrevs i projektets början. 1.2 Frågeställningar Hur skapas en visualisering av data över återhämtningsprocessen för personer som fått diagnosen psykos? Kan filtrering användas för att lyfta fram mönster i datan över återhämtningsprocessen? Hur ska applikationen utformas för att vara användarvänlig för den valda målgruppen? 1

1.3. AVGRÄNSNINGAR KAPITEL 1. INLEDNING 1.3 Avgränsningar Det är önskvärt att applikationen ska kunna fungera på olika datorskärmar i olika presentationsmiljöer. Datorerna behöver vara utrustade med en uppdaterad webbläsare. Applikationen är inte tänkt att användas på handhållna enheter. Projektet begränsas av antalet utvecklare i projektgruppen och av tidsramen för projektet. Projektgruppen består av sex personer som arbetar 60% under fyra månader. Utvecklarna har goda medietekniska kunskaper och programmeringserfarenheter men är vid projektets start inte insatta i alla programspråk som ska användas i projektet. Systemet avgränsas av projektgruppens och kundens kvalitetskrav i Bilaga A. 1.4 Bakgrund Projektet genomförs för att möjliggöra visualisering av data från psykiatrisk vård, socialtjänst och brottsmyndigheter m.fl. för att forskare ska kunna studera återhämtningsprocessen för personer som fått diagnosen psykos. Dessa personer diagnostiserades mellan år 2000-2004. Personer som förr skulle bott på mentalsjukhus, lever istället i det nya institutionella landskapet ute i samhället. Hur går det för dem? Vilka hjälp- och stöd-insatser får de? Dessa frågor är bakgrunden till varför visualiseringsapplikationen skapas i det här projektet. Forskarna behöver ett hjälpmedel som de formulerat i tre steg, de vill kunna filtrera, sortera och jämföra olika individers återhämtningsfaser. Målgruppen för applikationen som utvecklas i det här projektet är forskare med begränsad datorvana. Denna målgrupp kräver att stor vikt läggs vid användarvänlighet under applikationens utveckling. 2

Kapitel 2 Relaterat arbete Artiklar om relaterade arbeten tilldelades utvecklingsgruppen i ett tidigt skede. Dessa användes för att skapa en grund till vidare efterforskning och utformande av projektet. LifeLines: Visualizing Personal Histories [1] beskriver en applikation för att visualisera en övergripande bild av en individs liv och händelser från medicinska register och brottsregister. Projektgruppen har studerat artikeln och hittat intressanta aspekter att inspireras av och funktionalitet att förbättra. Varje persons liv visas som en linje med utmarkerade händelser i olika färger och tema. I enlighet med artikeln Exploring Time Diaries Using Semi-Automated Activity Pattern Extraction [2] är det för tidslinjegranskning ett mer givande gränssnitt att placera tiden utefter y-axeln och därigenom kunna visa flera individer på samma gång under en längre tid. Artikelns fokuserar på automatiserat igenkännande av sekvenser och projektgruppen har kunnat ta till sig information från artikeln för att kunna utveckla den egna applikationen. Efterforskningar gjordes även runt D3.js och dess färdiga moduler som kunde användas antingen helt eller som skelett till en egenskapad funktionalitet som önskades. Då de flesta exempel från D3:s bibliotek [3] hanterade en horisontell utveckling [4] och visade sig vara svåra att omvandla valde projektgruppen att utveckla egna moduler anpassade till applikationens behov. 3

Kapitel 3 Utvecklingsmetodik I detta kapitel beskrivs vilka metoder som använts under utvecklingen av projektet. Agil systemutveckling och Scrum har legat till grund för projektgruppens arbete och dessa beskrivs i Kapitel 3.1. Projekthantering innehållande planering och mötesrutiner beskrivs i Kapitel 3.2 nedan. Rutiner så som dokumentation, krav och versionshantering samt testning beskrivs i Kapitel 3.3. Detta kapitel innehåller hur projektgruppen har arbetat och motiverar valet av utvecklingsmetodik. 3.1 Agil utveckling - Scrum Agil systemutveckling är en metod som ger flexibilitet i utvecklingen av en produkt. Ett huvudfokus för metoden är att kontinuerligt kunna tillhandahålla kunden en funktionsduglig produkt som efter hand kan utvärderas och förbättras. Metoden innebär att system ska byggas i korta iterationer utan för mycket dokumentation. Systemet ska testas ofta och det kan med fördel göras med automatiserade testfall. Kunden får stor delaktighet i skapandet och utvecklingsprocessen av produkten. Arbetet sker inkrementellt och iterativt [5]. Projektet har utvecklats med hjälp av den Agila utvecklingsmetoden Scrum [6]. Arbetet har delats in i olika sprintar där varje sprint har haft ett mål i form av att en funktionalitet utvecklas. Ett sådant mål behandlas inom en story och delas upp i olika tasks. Att arbetsprocessen har varit Agil har inneburit iterativ utveckling och alltså resulterat i att en funktionsduglig produkt alltid funnits till hand. Arbetsprocessen har också gett en bra rutin vad gäller kontakt mellan kund och utvecklingsteam. Utvecklingsprocessen innebär att alla gruppmedlemmar har samma titel vilket resulterar i en platt hierarki. Gruppmedlemmarna har haft varsitt område där de haft det yttersta ansvaret över att bestämda rutiner följts. En beskrivning av områden och ansvariga finns att läsa i Bilaga C. 3.2 Projekthantering Projektgruppen har planerat arbetet utefter de tre stegen i kundens beställning som finns beskrivna i Kapitel 1.4. Kunden har också haft underliggande krav som syftar till särskild funktionalitet i de olika stegen. Dessa har framlagts på möten med kunden och ibland ändrats eller utvecklats. Idéer om implementationer som uppkommit i ett senare skede i processen har utelämnats på grund av att de inte skulle hinnas med. Fokus har legat på att leverera en produkt baserad på kraven som fanns vid projektets början. 4

3.2. PROJEKTHANTERING KAPITEL 3. UTVECKLINGSMETODIK 3.2.1 Planering och genomförande I början av projektet utvecklades en preliminär tidsplan bestående av sprintar utefter arbetsmetoden Scrum. Eftersom den gjordes i ett tidigt stadie fanns reservation för ändringar. Den slutgiltiga tidsplanen presenteras i ett Gantt-schema i Figur 3.1, och är uppbyggd av sex sprintar med samma arbetstidslängd. Figur 3.1: Gantt-schema. Arbetstillfällena var delvis gemensamma och delvis enskilda. Den planerade tiden för arbetet var 24 timmar i veckan. En preliminär plan över milstolpar i projektet bakades in i sprintarna och beskrivs nedan. Sprint 0 Projektet började med en planeringsfas. Perioden bestod av efterforskningar kring de tekniska verktyg och tredjepartsbibliotek som skulle användas, samt skapande av en utförlig planering för arbetet. Under sprinten hölls ett första kundmöte där projektgruppen fick ökad kunskap om projektets förutsättningar, krav och bakgrund. Sprint 1 Milstolpe: Analysera och läsa in datan, samt skapa en grafisk prototyp. Under sprinten skapades ett Matlab-script med låtsasdata utifrån en variabelbeskrivning tillhandahållen från kund. Låtsasdatan användes fram tills dess att den riktiga datan levererades. Arbetet med visualiseringen inleddes med hjälp av D3.js och delades in i två områden. Ett område innefattade huvudgrafen för visualiseringen och det andra området innefattade ett komplement i form av en tidslinje. Indelningen behölls under resten av arbetet för att underlätta arbetsfördelningen. Sprint 2 Milstolpe: Programmera tidslinjen och filtreringsfunktionerna. Sprinten inleddes med ett kundmöte där projektgruppen visade en prototyp över det tänkta gränssnittet i applikationen. Kundens kvalitetskrav utvecklades och frågor från projektgruppen besvarades. 5

3.2. PROJEKTHANTERING KAPITEL 3. UTVECKLINGSMETODIK Under sprinten påbörjades arbetet med databashanteringen. Applikationen tog form i och med att gränssnittet utvecklades i HTML, Javascript och CSS. Arbetet med filtrering av data påbörjades och visualiseringen fortsatte att utvecklas. Sprint 3 Milstolpe: En beta-version av applikationen ska ha skapats. Arbetet med filtrering fortgick. Kod omstrukturerades genom refaktorering för att underlätta arbetet och ett REST-API skrevs för effektiv åtkomst av data. Läs mer om detta under kapitel 4.4. Sprint 4 Milstolpe: Förbättra beta-versionen med en sorteringsfunktion. Under sprinten hölls ett kundmöte. Projektgruppen presenterade nuvarande stadie på applikationen och kunden fick komma med synpunkter på design och implementationen. Storleken på data utökades för att kontrollera funktionaliteten av datahämtning. En färglegend med brushing-funktionalitet utvecklades för enklare navigering och bättre överblick i visualiseringen och en hovringsfunktion implementerades. Läs mer om detta i kapitel 5.1. Sprint 5 Milstolpe: Beta-versionen ska ha förbättrats med en sekvenssökningsfunktion. Efter önskemål från kund om exportering av data som visas i applikationen implementerades detta. Sorteringsfunktionen utvecklades och gränssnittet uppdaterades efter resultat av användartester och projektgruppens önskemål. Sprint 6 Milstolpe: Applikationen och projektrapporten ska vara färdig. Den avslutande sprinten ligger framåt i tiden för när den här rapporten skrivs. Under sprinten ska framläggning planeras. Applikationen ska färdigställas och de befintliga buggarna ska elimineras. Under sprinten ska det sista kundmötet ske och då presenteras applikationen som projektgruppen har utvecklat för kunden. Förslag till eventuella utvecklingar efter det här projektets tid redogörs i kapitel 7.2. 3.2.2 Möten Vid möten har varje gruppmedlem haft ansvar för att de följer de regler som står i gruppkontraktet, se Bilaga B. Nedan följer en beskrivning av olika typer av möten som varit en del av projektet. Sprint-möten Varje sprint har inletts med ett planeringsmöte, sprint-möte. Under dessa möten har planeringen för den kommande sprinten lagts upp, vad som ska göras och vem som är ansvarig för vilken del under sprinten. Det har också diskuterats önskvärda mål för sprinten. Under mötet planerades också arbetstider och tillfällen. Vid frånvaro från arbetstillfälle ansvarade varje gruppmedlem själv över att tilldelat arbete blev utfört innan nästa arbetstillfälle. 6

3.3. RUTINER KAPITEL 3. UTVECKLINGSMETODIK Daily Scrum Varje arbetsdag har inletts med ett Scrum-möte [6] där projektgruppen uppdaterat varandra om arbetets status och vad de har för avsikt att göra under arbetsdagen. Här fanns även utrymme till att diskutera eventuella problem. För att hålla mötet kort och effektivt har alla medlemmar stått upp under mötet. Kundmöte Under arbetsprocessen har fyra kundmöten hållits då kunden bland annat fått ta del av och utvärdera prototyper av applikationen. Mötena har inneburit att kunden haft kontinuerlig kontakt med projektgruppen och därav har risken för brister i kommunikation minskat. Retrospective Efter varje sprint har ett avslutande möte hållits, ett så kallat retrospective. Där har sprintens arbete utvärderats och sammanställts. Oavklarade uppgifter har skickats med till nästa sprint. Under mötet har koden för de funktionaliteter som skapats under sprinten tittats igenom i en walkthrough, se kapitel 3.3.3. Funktionaliteterna har sedan sammanfogats till en uppdaterad applikation. 3.2.3 Expertmöten Under projektets gång har det funnits tillgång till experter inom olika områden. Projektgruppen har haft några möten där tekniska problem och lösningar har diskuterats. Experterna presenteras i Bilaga B. Under dessa möten har det inte varit ett krav att alla projektmedlemmar ska närvara. 3.3 Rutiner I det här kapitlet presenteras vilka rutiner projektgruppen har haft för dokumentation, krav och versionshantering och testning under arbetets gång. 3.3.1 Dokumentation En viktig del för en bra struktur är att dokumentera under projektets gång. Detta minskar risken för oklarheter inom gruppen och ger även möjlighet att gå tillbaka för att ta reda på relevant fakta som antecknats tidigare. Dokumentationen har varit kortfattad och tydlig för att ge en överskådlig bild av vad som gjorts. All kod som skrivits har kommenterats och dokumenterats. Det finns huvudkommentarer överst i filen där det står vem som skrivit koden, vilket datum det skrivits och övergripande information om koden. Det har även dokumenterats när koden lagts upp på GitHub, där varje commit innehåller en kort och beskrivande kommentar om koden. Alla kommentarer är skrivna på engelska. Vid kundmöten har allt dokumenterats av en sekreterare, där denne har antecknat allt viktigt som bestämts och diskuteras. Mötesprotokollen har sedan lagts upp på Google Drive för att ge alla utvecklare tillgång till denna information. Kunden fick också tillgång till dessa dokument. 7

3.3. RUTINER KAPITEL 3. UTVECKLINGSMETODIK 3.3.2 Krav och versionshantering En prototyp med den tänkta funktionaliteten har presenterats för kunden innan koden har implementerats. Kunden har sedan framfört önskemål och krav på funktionerna som skall implementeras. Kraven har skrivits ned i projektgruppens prioriteringslista på Trello och delats in i stories. Under en story har en viss funktionalitet behandlats och arbetet har delats upp i mindre tasks som baserats på de krav kunden ställt. Hur dessa stories och tasks delades upp bestämdes under de dagliga morgonmötena. Med hjälp av Trello blir kraven lättillgängliga och det blir lätt att spåra tidigare händelser i processen. Tasksen har märkts med olika statusar så som ska göras och färdigställda för att lätt få en överskådlig bild av vad som behöver göras. Versionshanteringen av koden gjordes med hjälp av Git, genom webbhotellet Github som gör det möjligt att se när, var och av vem kod har implementerats. På Github användes en huvudgren, även kallad för master-branch. Varje enskild funktionalitet i applikationen har utvecklats på en egen gren till huvudkoden. Endast körbar kod har laddats upp på huvudgrenen efter testning och när all kod har sammanfogats har testning av hela systemet skett. 3.3.3 Testning Syftet med testningen av koden i det här projektet var att hitta eventuella buggar i koden och för att skapa en slutprodukt med bra prestanda och hög kvalitet. Det är sällsynt att koden är felfri på en gång och det är därför viktigt att kontinuerligt gå igenom den för att se att den gör det den ska utan problematik. Största fokus under testningen var att se till att programmet uppfyllde körtiden enligt kvalitetskraven (Bilaga A) och att inmatning av felaktiga parametrar hanterades korrekt. En aspekt som är viktig att tänka på är att koden inte ska vara onödigt komplicerad. Det räcker med att den tillfredsställer de funktions- och kvalitets-krav som fastställts. Testning av koden sker då varje sprint färdigställts. Under utvecklingen av projektet har walkthroughs hållits när en eller ett par personer har skrivit klart en funktionalitet i programmet. Under dessa walkthroughs har koden gåtts igenom för de andra gruppmedlemmarna och detta har gjort det lättare för dessa att sätta sig in koden [7]. Användartester av gränssnittet har skett kontinuerligt under projektets utveckling (Bilaga D), för att se till att applikationen är användarvänlig. Det är lätt att vänja sig vid utseendet av applikationen under utvecklingsprocessen och därför är det bra med åsikter utifrån. Under dessa tester fick personer, som är oerfarna inom ämnet, testa applikationen för att se om gränssnittet var tydligt. Resultatet av användartesterna diskuterades av projektgruppen och ändringar gjordes. Ett acceptanstest har skett under varje kundmöte, där prototypen av applikationen visats för kunden. Syftet med testet var att ge kunden möjligheten att bidra med åsikter om eventuella förbättringar som kunde utföras. Fokus låg under dessa test på applikationens gränssnitt och användarvänlighet, istället för på koden. Dessa test bidrog mycket med att se till att utvecklingen av applikationen skedde i rätt riktning. 8

Kapitel 4 Teknisk beskrivning Detta kapitel beskriver ingående systemets arkitektur, programdesign och utvecklingsverktyg. Systemet och hur varje del är uppbyggd och relaterar till övriga delar beskrivs i Kapitel 4.1. Programdesignen i Kapitel 4.2 beskriver hur varje enhet fungerar och ger en översikt över bland annat variabler, funktioner och anrop. I avslutningen av detta kapitel ges en utförlig beskrivning av REST-API, visualisering och gränssnitt. 4.1 Systemarkitektur Systemarkitekturen visar hur systemet kan brytas ner i enheter, hur dessa enheter relaterar till varandra samt enheternas egenskaper [5, sid. 224]. Att redan innan systemet implementeras ha en tydlig systemarkitektur är central för att kunna beräkna kostnader och allokera resurser i form av personal. Kostnader och resursallokering för det här projektet var i form av arbetstid och vem som jobbade med vilken eller vilka enheter. Fördelen med en tydlig arbetsfördelning är att det möjliggör parallellt arbete med systemets enheter. En tydlig arkitektur minskar inte bara kostnader och underlättar planeringen av själva arbetet med systemet utan underlättar även vidareutveckling och utbyggnad av systemet. Vidare beskrivs enheternas egenskaper samt hur dessa är relaterade och kommunicerar med varandra. Kommunikationen i Figurerna 4.1-4.4 beskrivs med heldragna pilar. Pilar som är streckade innebär kommunikation med enheter utanför den specifikt beskrivna delen av systemarkitekturen. Heldraget streck i Figurerna 4.1-4.4 innebär utvecklingsspråk eller bibliotek. I Figur 4.1 visas systemets övergripande systemarkitektur. Denna bild innehåller tre enheter med olika egenskaper och roller; databas, server och klient. Mellan dessa enheter finns informationsflöden, vilket pilarna mellan enheterna visar. Systemet arbetar och lagras enbart lokalt. Detta gör att den sekretessbelagda datan inte kan nås från andra enheter än där systemets lagras. Vardera enhets uppgift, uppbyggnad samt hur enheten kommunicerar med det övriga systemet beskrivs med bild och utförlig förklaring i Kapitel 4.1.1-4.1.3 nedan. 4.1.1 Klient Klientens uppgift är att skicka förfrågningar till servern, baserat på användarens filtrerings och sorteringsval, samt att tolka och visa visualiseringen av datan från servern för användaren. Klienten är den del av systemet som användaren kommer i kontakt med. I denna del görs datavisualiseringen. 9

4.1. SYSTEMARKITEKTUR KAPITEL 4. TEKNISK BESKRIVNING Figur 4.1: Övergripande systemarkitektur. Figur 4.2: Klientdelens uppbyggnad och kommunikation internt och med server. Hur klientdelen är uppbyggd visas i Figur 4.2. Klientdelen är skriven i Javascript, HTML, CSS, Javascript-biblioteket D3.js och ramverket Bootstrap. För användargränssnittets utseende, funktion och anpassningsbarhet användes HTML, CSS och ramverket Bootstrap. Javascript och Javascriptbiblioteket D3.js användes för att visualisera data samt att göra anrop till servern. I HTML-koden görs funktionsanrop till Javascript-koden när användaren uppdaterar visualiseringen. Dessa funktionsanrop behandlas av respektive funktion i Javascript-koden och med hjälp av D3.js anropas servern och data ritas till ett SVG-element, som skapats i HTML-koden. I Figur 4.2 visar pilarna kommunikation mellan klientens olika delar. 4.1.2 Server Servern har till uppgift att ta emot och tolka klientens förfrågningar samt hämta den efterfrågade datan från databasen. Servern skapar en CSV-fil och skriver de personers identifikationsnummer som inte blivit bortfiltrerade till filen. Kunden kan använda CSV-filen för att göra vidare undersökningar av identifikationsnumren och deras återhämtningsprocess i sitt forskningsprojekt. Serverns uppbyggnad visas i Figur 4.3 och består av en Javascript-fil som körs lokalt med hjälp av Node.js. Denna Javascript-fil innehåller moduler som används av Node.js körning av servern. Dessa moduler är Sqlite3, Express, Path, FS. Modulen Sqlite3 hanterar uppstart av databasen. Path och Express används vid hämtning av data från databas. FS-modulen är till för att skapa och skriva data till CSV-fil på servern. Hur modulerna och servern kommunicerar visas i Figur 4.3. 10

4.2. PROGRAMDESIGN KAPITEL 4. TEKNISK BESKRIVNING 4.1.3 Databas Figur 4.3: Serverns uppbyggnad och kommunikation. Databasen innehåller all data och består av en DB-fil. Denna DB-fil skapades utifrån två CSV-filer med hjälp av Node.js. Från databasen kan data hämtas med så kallade databasfrågor som skickas från servern. Ett exempel på en databasfråga kan vara: hämta alla kvinnor som bor i bostadsrätt och har hemmavarande barn och sortera dessa på ålder. Uppbyggnad och kommunikation med server visas i Figur 4.4. Figur 4.4: Databas och dess kommunikation. 4.2 Programdesign Programdesignen beskriver hur varje enhet fungerar och ger en detaljerad översikt över bland annat klasstrukturer, variabler, funktioner och anrop. Datan som används i applikationen hämtas från två CSV-filer, som kunden skapat och tillhandahållit projektgruppen. Med hjälp av Sqlite3 lagras filerna i databasen som beskrivs i Kapitel 4.1.3. Databasen består av två tabeller, en för vardera CSV-fil. Den ena tabellen innehåller informationen om händelserna i visualiseringen, bland annat start- och slutdatum. Den andra tabellen innehåller bakgrundsfakta om individerna. När information hämtas från databasen skickas den tillbaka till Javascript-klienten i en JSON-fil. Det första som sker när applikationen körs är att användaren väljer vad som ska visas och en filtrering baserat på detta sker. Användarens filtreringsval skickas till ett REST-API, som i sin tur hämtar den valda datan från databasen. Hämtningen sker med hjälp av tredjeparts-api:et Sqlite3 och den valda datan visualiseras i applikationen. För att en eventuell justering av filtreringen ska ske måste användaren implicit skicka en ny hämtning till databasen. Detta sker med hjälp av en knapp i gränssnittet. Applikationen skulle bli långsam och prestandan sänkas om datan hämtas vid varje nytt val användaren gör. Därför sparas inga filer från en körning till nästa utan hämtas vid varje uppstart och 11

4.3. UTVECKLINGSVERKTYG KAPITEL 4. TEKNISK BESKRIVNING uppdatering av applikationen. Appliaktionen är programmerad i Javascript och funktionerna som hämtar och ritar ut datan är fillarray() respektive drawdata(). I fillarray() används bakgrundsfakta-tabellen för att skapa en lista som innehåller de filtrerade individerna. För att de ska visas i visualiseringen anropas drawdata(). Ännu en gång hämtas data i databasen, men nu från tabellen som innehåller alla händelser. Det är dock bara händelserna för de specifika individerna som valdes i fillarray() som hämtas och ritas ut. Visualiseringen ritas ut med tredjeparts-api:et D3.js, som är användbart när stora mängder data behandlas. 4.3 Utvecklingsverktyg Under arbetet har programmet Webstorm använts. Med en studentlicens är programmet gratis att ladda ner från Internet. Programmet erbjuder inbyggda verktyg för refaktorering och enhetstestning. Koden behöver inte kompileras utan körs direkt i en webbläsare. Webbläsarna som främst använts är Google Chrome och Mozilla Firefox. Deras verktyg är fullt tillräckliga och har använts av samtliga utvecklare för att eliminera buggar. Programkoden är skriven efter JavaScript-standard med stöd för tredjeparts-biblioteken D3.js och Node.js. D3.js erbjuder stor kontroll av det visuella resultatet samt möjlighet att kunna anpassa funktioner efter projektets behov. Färdiga funktioner riskerar att låsa flexibiliteten i applikationen, därför har så mycket som möjligt av koden skrivits från grunden. CSV-filerna med datan läses in i en databas för att därifrån kunna bli tillgänglig av applikationen. Eftersom datan består av känslig information ligger applikationen och dess tillhörande databas lokalt. SQLite [8] är ett fristående databashanteringsprogram. Tillsammans med Node.js [9] hämtas datan från databasen. För att göra applikationen anpassningsbar har ramverket Bootstrap[10] använts. Ramverket är gratis och förenklar webbsidors utformning och uppbyggnad på ett användarvänligt sätt. Det ger en tydlig CSS-struktur som bygger upp HTML-elementen. 4.4 REST Representational State Transfer (REST) är ett begrepp som blivit populärt inom mjukvaruutveckling sedan det introducerades 2000 av Roy Fielding [11]. REST är en hybridstruktur som syftar till att medföra viktiga arkitekturella egenskaper för klient- och server-kommunikation. Via dessa egenskaper minimeras nätverkskommunikationen till när klienten kontaktar servern, vilket minskar fördröjningar och mängden data som klienten behöver veta vid uppstart. Istället kan den önskade datan hämtas under körning och då anpassa klienten utefter responsen. Tillvägagångssättet kan beskrivas som att ge datan en unik adress via URI-standard. All data kan sedan genom ett gemensamt gränssnitt i kommandon skickas mellan klient och server via HTTP-standarden: POST, GET, PUT och DELETE för att nämna några. Datan kan sedan erhållas i olika format beroende på applikationens behov. I applikationen användes REST för att skicka SQL-frågan till databasen och hämta den intressanta datan från önskad tabell. För detta skapades två olika adresser där den ena ledde till bakgrundstabellen 12

4.5. VISUALISERING KAPITEL 4. TEKNISK BESKRIVNING och den andra ledde till händelsetabellen. Via kommandot GET hämtades den efterfrågade datan och returnerades till klienten för behandling. 4.5 Visualisering Varje händelse i datan visualiseras i en graf där koden är skriven med hjälp av Javascript-biblioteket D3.js. Datan hämtas från servern och rektanglar ritas. Vilken höjd varje enskild rektangel har beror på vilket start- och slutdatum händelsen har. Färgen bestäms utefter inställningar om filtrering och detaljnivå enligt en färgkod som skapats tillsammans med kunden. Grafen består av två axlar och varierande antal rektanglar. En karta över händelser och färger finns att se närmare i Bilaga E. Datan kan visualiseras i tre olika detaljnivåer. Alla detaljnivåer visar samma valda händelser, skillnaden är att händelserna visualiseras med olika många färger beroende på detaljnivån. Detaljnivå 1 består av fyra färger, där varje färg representerar en huvudkategori. Alla händelser som tillhör samma huvudkategori blir tilldelad samma färg. Detaljnivå 2 består av åtta färger, där varje delkategori har samma färg. Detaljnivå 3 består av 20 färger och varje färg representerar en specifik händelse. Detaljnivå 1 ger en överblick medan detaljnivå 3 är den mest detaljerade detaljnivån. 4.6 Gränssnitt Gränssnittet i applikationen är utvecklat med hjälp av ramverket Bootstrap. Bootstrap erbjuder en enkel användning av HTML, CSS och Javascript för att skapa responsiva hemsidor som fungerar för såväl datorskärmar och handhållna enheter. Bootstrap innehåller färdiga mallar som ger dynamik i applikationen. Mallarna har i det här projektet fungerat som en grund att utgå ifrån och skapa egna utvecklingar genom. 13

Kapitel 5 Resultat Applikationen Livslinjer är anpassad för att köras i en webbläsare på en dator. Resultatet har delats in i två delar. Den första delen behandlar själva visualiseringsdelen av applikationen, det vill säga den delen som visar all data. Andra delen behandlar gränssnittet, vilket handlar om hur menyer och anpasssningbarheten fungerar. 5.1 Visualisering Applikationens huvudfokus är visualiseringen av data i olika konstellationer. Den visar data på ett övergripande sätt med olika detaljnivåer och möjligheter till filtrering och sortering av data. Visualiseringen består av två delar och utgör huvudfokus i applikationen. Den ena delen är en graf med en x- och y-axel. X-axeln visar olika identifikationsnummer och y-axeln visar tid i år från och med år noll till år tio. I grafen ritas händelser ut som rektanglar i olika storlekar beroende på händelsens längd. Varje händelse har en unik färg och alla händelser för en person bildar en stapel. Beroende på hur många identifikationsnummer som visas varieras staplarnas bredd, vilket kan ses i Figur 5.1-5.3. Färgen på händelserna i de olika detaljnivåerna har valts med hjälp av verktyget ColorBrewer[12]. Figur 5.1: Detaljnivå 1. Den andra delen är en tidsaxel som kan användas för att zooma in och ut samt skrolla i visualiseringen, se Bilaga F. Tidsaxeln är en utzoomad version av den data som visas i grafen för tillfället. Den ligger till höger om visualiseringen och fungerar som ett komplement till grafen. 14

5.2. GRÄNSSNITT KAPITEL 5. RESULTAT Figur 5.2: Detaljnivå 2. Figur 5.3: Detaljnivå 3. Hovring innebär att användaren kan genom att föra muspekaren över visualiseringen få upp information om vilket identifikationsnummer stapeln har. Användaren kan trycka på stapeln och kommer då få upp information om identifikationsnummer, startdatum, slutdatum, datum för psykosdiagnos och datum för första kontakten med psykiatrin, se Bilaga F. Beskrivningen av vad de olika färgerna representerar ligger under visualiseringen och kallas färglegend. Även legenden kan ses i Bilaga F, den är placerad under visualiseringen. Användaren kan med hjälp av denna välja vilka händelser som ska visas genom att avmarkera i färglegenden. Om en ruta är avmarkerad kommer dessa rektanglar bli grå. 5.2 Gränssnitt När applikationen startas informeras användaren kort om applikationens funktion samt hur valen görs i menyn till vänster. Menyn är till en början dold, vilket kan ses i Bilaga G. I menyn görs val för filtrering, sortering och detaljnivå. Valen görs genom att en kryssruta markeras. Åldersintervallet väljs genom att fylla i en lägsta och en högsta ålder. När valen är gjorda visualiseras datan genom att använ- 15

5.2. GRÄNSSNITT KAPITEL 5. RESULTAT daren trycker på knappen Rita visualisering. Knappen är placerad ovanför menyn. Visualiseringen kommer att visas på största delen av skärmen. Användaren kan när som helst göra nya val i menyn och uppdatera visualiseringen genom att åter trycka på Rita visualisering -knappen. Det är viktig att applikationen är anpassningbar, detta för att kunna använda applikationen på olika stora skärmar. Både menyn och menyraden är gjorda anpassningsbara med hjälp av Bootstrap. Visualiseringen anpassas efter sidans storlek då sidan uppdateras, medan menyn anpassas när fönstret skalas om. 16

Kapitel 6 Analys och diskussion Det har varit utvecklande att i grupp genomföra ett större projektarbete. Mycket planering har krävts och många beslut har tagits. Tillsammans har projektgruppen uppnått framgång och bekämpat motgång. Ingen i projektgruppen hade tidigare erfarenhet av att arbetat Agilt, men trots det har arbetsmetoden gett ett tillfredsställande slutresultat. 6.1 Utvecklingsmetodik I det här kapitlet analyseras och diskuteras utvecklingsmetodiken som projektgruppen arbetat utefter. Den Agila utvecklingsmetodiken Scrum utvärderas och diskuteras. 6.1.1 Agilt Under projektets gång har det funnits en version av produkten att visa för kunden, detta tack vare att den Agila arbetsmetoden Scrum har använts. Det tog tid att läsa på och sätta sig in i metoden och till en början fanns det osäkerheter kring hur saker och ting skulle utföras. Det tog även tid att skriva dokumenten som låg till grund för arbetet, vilket fördröjde uppstarten. Det var svårt att förutse och planera hur mycket arbete som skulle hinnas med under varje sprint. Vissa gånger fanns det tid över i slutet av sprinten, trots att alla tasks avklarats. Andra gånger fanns det milstolpar som inte hanns med under sprintens gång. Vid dessa tillfällen följde tasksen med till nästa sprint. Det tillkom uppgifter med hög prioritet som var tvungna att avklaras innan sprintens planerade tasks kunde fortsättas. På kundmötena visades produkten upp och trots att den inte var fullständig kunde kunden ge återkoppling på den. 6.1.2 Projekthantering Arbetet strukturerades med Trello och tjänsten användes kontinuerligt under hela projektet. Trello var lätt att använda och gav en bra struktur. Det var tydligt vem som arbetade med vad och när arbetet hade utförts. Att börja projektet med en sprint 0 var ett bra beslut av projektgruppen eftersom förarbetet som gjordes effektiviserade de resterande sprintarna. Ett annat verktyg som effektiviserade arbetet var Github. De flesta gruppmedlemmarna var bekanta med Github sedan tidigare och det var enkelt att jobba på olika delar parallellt. Det uppstod dock problem när olika versioner av samma fil skulle sammanfogas. Det var förväntat att det skulle uppstå problem men inte problemens antal. Kunskapen om hur felen skulle lösas fanns men inte tiden. Därför löstes oftast problemen genom att sammanfoga filer manuellt. Det fungerade bra men var inte optimalt. I början bestod applikationen av lite kod och 17

6.2. DISKUSSION OM FÖRUTSÄTTNINGAR KAPITEL 6. ANALYS OCH DISKUSSION det glömdes bort att strukturera upp en arkitektur, vilket senare insågs vara nödvändigt. Det var svårt att skapa en tydlig arkitektur och den ändrades flera gånger under projektet. En större refaktorering skedde under sprint 3. Efter varje ändring var projektgruppen noga med att meddela och gå igenom koden tillsammans. 6.2 Diskussion om förutsättningar Projektgruppen anser att utvecklingen av visualiseringen hade haft bättre förutsättningar och kunnat generera ett bättre resultat om kundkontakten hade skett innan påbörjat arbete. Datan som applikationen var avsedd att skapas kring var inte klar i projektets början utan formades under projekttiden. Det medförde att projektgruppen fick skapa egen låtsasdata att arbeta utefter. Detta borde inte ha varit ett problem men intressenternas tveksamheter och brist på kommunikation internt i kundgruppen ledde till att formatet på data ändrades flertalet gånger under projekttiden. Den slutgiltiga datan levererades till projektgruppen sent i utvecklingsstadiet. Problemet var att när datan levererades hade den ett annorlunda format än överenskommet. Problemen som uppstod gick att lösa men tid som hade kunnat läggas på att skapa utvecklingar i applikationen och förbättra delar gick istället åt till omstrukturering av inläsning och hantering av data. 6.3 Resultat Trots gruppmedlemmarnas brist på tidigare kunskaper inom många områden av arbetet, så som nya programmeringsspråk och en Agil utvecklingsmetod, skapades ett tillfredsställande slutresultat. De milstolpar som sattes i början av projektet (Kapitel 3.2.1) blev uppfyllda. På grund av att gruppen använde sig av låtsasdata är det inte möjligt att dra slutsatser från resultatet av visualiseringen. Det svåraste med visualiseringen var att lära sig använda D3.js, då ingen i gruppen hade använt sig av Javascript-biblioteket tidigare. Ett flertal applikationer som liknade detta projekt fanns tillgängligt på Internet, men var ofta inte till någon större nytta under implementeringen av koden. Detta berodde på att många funktionaliteter i dessa liknande applikationer skilde sig ifrån det som eftersträvades i projektet. Därför byggdes istället funktionaliteterna upp ifrån grunden, för att få en bättre struktur och överblick av koden som skrivits. När tillräcklig kunskap av D3.js infann sig blev nästa utmaning hur all data skulle visualiseras för att uppfylla kraven i Bilaga A. Efter att ha utforskat liknande projekt kom gruppen kom fram till att representera händelser med rektanglar i olika färger. Det svåra var här att välja färger för alla olika händelser. I samråd med kund togs det fram passande färger för de tre olika detaljnivåerna se Bilaga E. Nyanser av dessa togs sedan fram med hjälp av verktyget ColorBrewer för att få en så stor kontrast som möjligt mellan färgerna. Ännu ett utmaning som gruppen stötte på under utvecklingen var inläsningen av datan. Låtsasdatan som skapades bestod först av 5000 händelser. Från början lästes datan in direkt i D3.js, vilket fungerade bra tack vare det låga antalet händelser. Då den riktiga datan sedan levererades visade det sig att den bestod av ungefär 200 000 händelser. På grund av detta användes istället ett REST-API, se Kapitel 4.4, för att läsa in datan snabbare. Även filtreringen blev tvungen att ändras på under utvecklingsprocessen. I början lästes all data in, där den datan som inte skulle visas filtrerades bort. Detta var onödigt och krävande för programmet. Istället gjordes det om så att endast den data som skulle visas hämtades, vilket snabbade upp applikationen avsevärt. Sammanfattningsvis var utvecklingsprocessen krävande men lärorik. Flertalet problem blev tvungna att lösas på andra sätt än de ursprungliga, så som filtreringen och inläsningen av data. De flesta av 18

6.4. PROTOTYPER KAPITEL 6. ANALYS OCH DISKUSSION dessa ändringar gjordes för att förbättra applikationens prestanda, men bidrog även till en förbättrad problemlösningsförmåga för gruppens samtliga medlemmar. 6.4 Prototyper Förarbetet som gjordes under sprint 0 gav projektgruppen en förståelse för hur liknande projekt har utformats. Exempel från Internet kombinerades med exempel från Katerina Vrotsou och den första prototypen togs fram. Det gjordes en enkel skiss som visades för kunden. Kunden bedömde prototypen och hade oftast åsikter och frågor. Det var tur att prototypen endast var en skiss då den lätt kunde anpassas efter kundens nya önskemål. Det hade varit tidskrävande att ändra en färdigprogrammerad prototyp och därför fick kunden alltid uttrycka sina åsikter i tidigt skede. Kunden påpekade ofta saker som projektgruppen inte hade tänkt på, till exempel att de ville att y-axeln skulle visa tid eftersom de var vana vid det. Under prototypens skapande uppstod det ofta frågor om applikationens funktionalitet och då vände sig projektgruppen till kunden. Problemet var att kunden inte alltid hade svar på projektgruppens frågor. Dessa löstes genom att problemen diskuterades med kund. Den kontinuerliga kontakten med kunden krävde möten och kontakt via mejl. Tack vare kontinuerlig kundkontakt kunde kunden konfirmera att arbetet gick åt rätt håll. Kunden har haft svårt att föreställa sig applikationen utan konkreta prototyper, vilket lett till att ändringar i krav om funktionalitet har uppkommit på fler kundmöten än önskvärt. Detta har projektgruppen förhållit sig till genom att skapa en prioritetslista tillsammans med kunden. En diskussion om kundens krav har vägts emot projektgruppens uppskattning av kostnad i tillgångar och tid. 6.5 Gränssnitt Till en början var det oklart vilka olika funktioner applikationen skulle ha. Projektgruppen förstod att visualiseringen krävde stor yta på skärmen, därför valde projektgruppen att ha tillfälligt dolda menyer. Till en början innehöll gränssnittet två menyer, men efter ett användartest insåg projektgruppen att en meny skapar bättre förståelse för dess funktionalitet. Hur applikationen såg ut med två menyer kan ses i figur 6.1. Menyn placerades till vänster eftersom det är där de flesta människor tittar först, precis som att målgruppen läser text från vänster till höger. Symbolen med streck är en vanlig symbol som de flesta förknippar med en meny. Under användartesterna förstod alla att det fanns en dold meny bakom symbolen. De förstod även att de var tvungna att trycka på Rita visualisering -knappen över menyn, för att rita ut visualiseringen. Knappen är grå och har en förklarande text på sig. Den ändrar färg till blå när den är klickbar, vilket ger tydlig affordans. För att indikera en funktionalitet ändras muspekarens form vid hovring över funktionen. 6.6 Användartester Gränssnittet växte fram i och med att applikationen skapades och användartester genomfördes regelbundet. Tack vare dessa tester skapades förståelse över hur en ovan användare hanterade applikationen. Testgrupperna bestod av studenter i åldrarna 20-25 år, vilket inte är den tänkta målgruppen. Testpersonerna förstod oftast inte applikationens syfte, men de förstod hur de skulle navigera sig med hjälp av gränssnittet. Om det var någon del av gränssnittet som var otydligt var det vanligt att flera testare hade problem på samma ställe. Användartesterna var viktiga i skapandet av applikationen, trots att kunden inte kunde testa applikationen. Kunden fick självklart se applikationen på varje kundmöte, 19

6.7. ARBETSFÖRDELNING KAPITEL 6. ANALYS OCH DISKUSSION Figur 6.1: Applikationen i början av projektet. men aldrig testa den själv. Det hade varit bra om en tänkt användare, som inte var kund, hade fått testa applikationen. En användare som är insatt i ämnet hade kanske förstått saker som vår testgrupp inte gjorde. 6.7 Arbetsfördelning Projektgruppen jobbade alltid parallellt på olika delar av projektet, ibland i par och ibland ensamma. Att arbeta effektivt i ett större projekt är svårt, men som tur var fanns det alltid något att göra. Ibland var gruppmedlemmar tvungna att vänta på att en del skulle bli färdig innan nästa kunde påbörjas. Det var svårt att dela uppgifterna jämnt inom projektgruppen då vissa tasks löstes fort och andra jobbades på länge. Mellan varje sprint var målet att byta arbetsområden, för att alla i projektgruppen skulle skapa sig förståelse för projektets olika delar. Det blev inte alltid så eftersom det var enklast att fortsätta jobba på det man var mest insatt i. Problemet löstes genom att projektgruppen jobbade i par där den ena redan jobbat inom ämnet och därför kunde förklarade för den som jobbat med en annan del innan. Tack vare det sparades tid då man slapp lära sig det nya helt själv. 6.8 Mål Vid projektets start bestämdes vilka mål som skulle uppnås. Det var osäkert ifall det fanns tid att genomföra alla mål och vissa mål prioriterades högre än andra. På grund av projektets tidbegränsning hanns inte alla mål med. Projektgruppen anser att de viktigaste målen, som skapar den grundläggande funktionaliteten i applikationen, är uppnådda. Ett mål som prioriterades bort och inte uppnåddes var sekvenssökning av visualiseringen. En sådan funktion hade varit värdefull för kunden, som lättare hade kunnat urskilja mönster i datan. Mönster kan fortfarande ses i visualiseringen, men inte på ett lika tydligt sätt. Projektgruppen visste redan vid projektets start att denna funktionalitet kanske inte skulle hinnas med och kunden informerades tidigt om detta. Tack vare detta accepterade kunden att slutprodukten saknade sekvenssökningsfunktionen. En annan funktionalitet som inte hann implementeras var hanteringen av händelser som överlappar varandra. Händelser kan pågå parallellt och till en början var ambitionen att det skulle visualiseras med olika färger eller mönster. Orsaken till att det inte gjordes var även det tidsbrist och att andra funktionaliteter prioriterades högre. Det är tråkigt att 20

6.9. ARBETET I ETT VIDARE SAMMANHANG KAPITEL 6. ANALYS OCH DISKUSSION dessa funktioner inte hanns med men projektgruppen var medvetna om det vid start och är nöjda med resultatet. 6.9 Arbetet i ett vidare sammanhang Att som i det här projektet arbeta med sekretessbelagd data från verkliga personers liv kräver stor försiktighet. Datan får aldrig lagras på Internet eller ha minsta chans att hamna där. Google Drive användes som verktyg för dokumenthantering i det här projektet. Däremot får datan aldrig lagras på Googles servrar. Googles servrar finns i USA och med alla avlyssningsskandaler med mera som USA har legat bakom är Google Drive inte tillräckligt pålitligt för att lagra känslig data på. Ett annat land ska inte kunna ta del av den data vi i Sverige samlar in om inte vi explicit valt att lämna ut datan. Datan i det här projektet kommer från flera olika databaser i Sverige. Det är i Sverige inte tillåtet att korsköra data från exempelvis kommun och landsting. Forskarna som kontaktat kunden till det här projektet tillhandahåller datan och har specialtillstånd. 21

Kapitel 7 Slutsatser I detta kapitel besvaras frågeställningarna som ställs i Kapitel 1.2. Applikationens nuvarande version uppfyller kundens och projektgruppens krav, men det finns utvecklingsmöjligheter. Dessa beskrivs i Kapitel 7.2 om framtida arbete. 7.1 Frågeställningar Frågeställningarna som togs upp i Kapitel 1.2 besvaras nedan. Hur skapas en visualisering av data över återhämtningsprocessen för personer som fått diagnosen psykos? Att skapa en visualisering av en stor mängd data, som återhämtningsprocessen består av, krävde planering och struktur. Det behövdes ett kompetent utvecklingsteam med medietekniska kunskaper, en ordentlig projektplanering och en tydlig systemarkitektur för att effektivt uppnå de uppsatta målen. Genom att kombinera dessa saker har visualiseringen skapats. Kan filtrering användas för att lyfta fram mönster i datan över återhämtningsprocessen? Datan går att filtrera manuellt av användaren. Efterforskningar och utvecklingen i D3.js har lett till att datan visualiseras på ett sådant sätt att mönster kan ses. Vilka val som görs i filtreringen påverkar mönstrets struktur och tydlighet. Projektgruppen har genom att utveckla visualiseringsapplikationen gjort det möjligt för kunden att filtrera och hitta mönster. Hur ska applikationen utformas för att vara användarvänlig för den valda målgruppen? Acceptanstester och diskussioner med kunden i ett tidigt stadie formade visualiseringen utefter vad de tyckte var en bra struktur och hur de är vana att se data. Efterforskningarna som beskrivs i Kapitel 2 gav att vid visualisering av data över lång tid är det fördelaktigt att visa tiden på y-axeln för att göra visualiseringen lättförståelig. Kunden anser att en bra och tydlig visualisering är utvecklad. 7.2 Framtida arbete En funktionalitet som hade kunnat utvecklas är möjligheten att arbeta med ännu fler variabler och en ännu större datamängd. Detta är möjligt i nuläget men går att optimera ytterligare för just detta ändamål. 22

7.2. FRAMTIDA ARBETE KAPITEL 7. SLUTSATSER Något som hade varit värt att utveckla om tiden funnits är en mer avancerad mönsterhantering, genom att skapa algoritmer för att hitta olika slags sekvenser av händelser i datan. På så sätt kan ett ännu mer avancerat system byggas upp där användaren har ännu fler valmöjligheter för att få fram den information som söks. Detta kan i sin tur leda till ännu mer framsteg inom det berörda ämnet och förhoppningsvis bidra till en bättre behandlingsplanering för personer som drabbats av sjukdomen. 23

Litteraturförteckning [1] Plaisant, Catherine och Milash, Brett och Rose, Anne och Widoff, Seth och Shneiderman, Ben. LifeLines: Visualizing Personal Histories, University of Maryland 1996 [2] Vrotsou, Katerina och Ellegård, Kajsa och Cooper, Matthew. Exploring Time Diaries Using Semi-Automated Activity Pattern Extraction, electronic International Journal of Time Use Research 2008, Vol. 5, No. 1, 43-64. [3] D3.js Library, hämtad: 2016-05-09 https://github.com/mbostock/d3/wiki/gallery [4] Swimlane Chart using d3.js, hämtad 2016-05-09 http://bl.ocks.org/bunkat/1962173 [5] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, International Edition, Pearson 2010 [6] Schwaber, Ken och Sutherland, Jeff The Scrum Guide, juli 2013. Hämtad 2016-05-12 http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf. [7] Ulf Eriksson, Test och kvalitetssäkring av IT-system, Studentlitteratur, 2008 [8] SqLite3 hämtad: 2016-05-05 https://www.sqlite.org/ [9] NodeJs hämtad: 2016-05-05 https://nodejs.org/en/ [10] Bootstrap hämtad: 2016-05-05 http://getbootstrap.com/ [11] Roy Thomas Fielding Architectural Styles and the Design of Network-Based Software Architectures Ph.D. Dissertation, 2000, hämtad:2016-05-09 http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm [12] Colorbrewer hämtad: 2016-05-05 http://colorbrewer2.org/ 24

Bilaga A Kvalitetskrav Nedan presenteras de kvalitetskrav som kunden och projektgruppen hade vid projektets början. Tillsammans bildar de kvalitetskraven för applikationen. Kundens kvalitetskrav Visualisera data över tid Olika detaljnivåer Filtreringsfunktion Sorteringsfunktion Projektgruppens kvalitetskrav Applikationen ska vara responsiv Användaren ska kunna zooma in och ut i visualiseringen Användarvänlig applikation Visualiseringen ska kunna hantera en stor datamängd. 25

Bilaga B Gruppkontrakt Figur B.1: Gruppkontrakt 26

Bilaga C Arbetsfördelning Kund: Katerina Vrotsou tillsammans med Alain Topor, Anne Denhov och Gunnel Andersson Examinator: Karljohan Lundin Palmerius Projektgruppen: Fanny Aldén - Prototypansvarig Arbetsområden: kodens arkitektur, anpassningsbarhet, lokalansvarig, användartester av gränssnittet, implementering av tidslinjen, testning och projektrapport. Isac Algström - Systemdesigner & testningsansvarig Arbetsområden: Efterforskning, gränssnittsutveckling, visualisering, testning, filtrering, användartester av gränssnitt, tidslinjen och projektrapport. Sofia Höglund - Ansvarig över gränssnittet Arbetsområden: användartester av gränssnittet, anpassningsbarhet, projektrapport, prototyp, gränssnittsutveckling, visualiseringen. Kristin Bäck - Ansvarig över möten & dokumentation Arbetsområden: Efterforksning, gränssnittsutveckling, responsivitet i gränssnitt, visualisering, dokumentansvarig, projektrapport, testning, hovring, filtrering, färger i visualisering. Dennis Hammer - Ansvarig över databas & data-analys Arbetsområden: Efterforskning, databas, REST, server, visualisering, filtrering, sortering, testning, kodstruktur, mergning av kod, packagehantering, start-up fil för server och webbläsare (batchfil), projektrapport. Anton Kaiser - Scrum master & projektledare Arbetsområden: Efterforskning, kontakt med kund och intressenter, gruppdynamik, inläsning av data till databas, REST, visualisering, filtrering, brushing, färglegender, skriva till fil på server, testning, mergning av kod, projektrapport. Personer som hjälpt till: Katerina Vrotsou, expert inom visualisering Carlo Navarra, webbexpert Karljohan Lundin Palmerius, handledare 27

Bilaga D Användartester D.1 Användartest 1 (2016-03-18) Testpersonerna anmärker på problem när olika val gös i menyn, till exempel försvinner val när andra val tas bort. Menyerna är långt ifrån varandra och vägen till att visa visualiseringen kräver många "klick". Det är svårt att förstå vad visualiseringen föreställer. Variabelnman till y- och x-axeln skulle öka förståelsen av visualiseringen. D.2 Användartest 2 (2016-04-27) Den vänstra menyn, som enbart styr visualiseringen, är tydlig. Testpersonerna förstår hur den ska användas och de flesta lyckas även rita ut visualiseringen med rita data-knappen. Den högra menyn med detljanivåerna och sorteringen upptäcks först efter ett tag. Det räcker med en meny som innehåller filtrering, sortering och detljnivåer. De samlar funktioner med liknande funktionalitet tillsammans och gränssnittet blir tydligare. Applikationen bör ha instruktioner på startsidan och rita data-knappen kan ha ett annat namn som förklarar dess funktion bättre. Placeringen av knappen borde vara bredvid menyn, det skulle indikera att de hör ihop. Det är svårt att förstå att boxarna i färglegenden är klickbara. En skuggning skulle öka deras klickbarhet och ge en 3D-effekt. Testpersonerna missar en del funktioner som att det går att klicka på händelserna i visualiseringen. Som förbättringsförslag föreslog de att muspekarens symbol skulle ändras vid hovring över funktionen. 28

Bilaga E Färger och händelser Figur E.1: Färglegend 29

Bilaga F Gränssnittet Figur F.1: Tidslinjen. 30

BILAGA F. GRÄNSSNITTET Figur F.2: Visar en visualisering när hovringsfunktionen används. 31