Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete | Medieteknik

Vårterminen 2016 | Team B: LiU-ITN-TEK-G--16/014--SE

Livslinjer

Visualisering av data från psykospatienters

återhämtningsprocess

Fanny AldénIsac AlgströmKristin BäckDennis HammerSofia HöglundAnton Kaiser

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-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 Uni-versitet. Kunden till projektet är forskare inom psykiatrin och projektet avser utveckling av en web-bapplikation för visualisering av data över tid. Datan kommer från olika myndigheter och syftet medanvändandet av applikationen är att kunna studera återhämtningsprocessen för patienter med diagno-sen psykos.

Rapporten beskriver, diskuterar och analyserar utvecklingen och resultatet av arbetet. Den Agila ut-vecklingsmetodiken Scrum är beskriven och ligger till grund för projektgruppens rutiner. Efterforsk-ningar inom visualisering och val av verktyg finns beskrivna och motiverade utefter kvalitetskraven.

Projektgruppen har, genom att använda medietekniska kunskaper, uppfyllt kundens kvalitetskrav ochskapat en applikation som kunden kan använda för att studera sin data. Applikationen som utvecklats idetta 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 i

Figurer v

Tabeller vi

Konventioner, förkortningar och termer vii

1 Inledning 11.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Relaterat arbete 3

3 Utvecklingsmetodik 43.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 94.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 145.1 Visualisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Gränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Analys och diskussion 176.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 227.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 28D.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: StilarUtseende Förklaring ExempelKursiv 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()...

Tabell 2: FörkortningarFörkortning FörklaringHTML Hyper Text Markup LanguageSVG Scalable Vector GraphicsDB DatabasCSV Comma Separated ValuesCSS Cascading Style SheetsD3 Data-Driven DocumentsFS File SystemURI Uniform Resource IdentifierAPI Application Programming InterfaceREST Representational State Transfer

Tabell 3: OrdlistaOrdlista FörklaringApplikation Produkten som skapats i projektetProjektgtrupp De personer som arbetat med projektetHändelse Specifik händelse för en patient, tex. “sluten-

vård”Matlab-script En samling av MATLAB-kommandon, sparade

i en textfilBugg Felaktighet i applikationens kodBrushing Färgmarkering av händelser i visualiseringenIdentifikationsnummer I databasen har varje patient ett unikt identifika-

tionsnummer

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 informationom personer med allvarlig psykisk funktionsnedsättning. Applikationens syfte är att hjälpa forskareatt försöka urskilja återhämtningsmönster för dessa personer. Projektgruppens uppgift är att skapa enapplikation för att läsa in datan, analysera den och utifrån det visualisera den på bästa möjliga sätt fören bestämd målgrupp. Rapporten är en del av kursen Medietekniskt kandidatprojekt vid Linköpingsuniversitet.

Projektet görs på uppdrag av flera forskningsinstitutioner genom Katerina Vrotsou, forskare inomvisualisering vid Linköpings Universitet. Forskningsinstitutionerna är FoU Södertörn, Institutionenför Socialt arbete vid Stockholms universitet, Länssjukhuset Ryhov i Jönköping och Psykiatri SödraStockholm. De har ett pågående forskningsprojekt där de studerar återhämtningsprocessen för män-niskor 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 appli-kationen kunna navigera sig genom registerdata. Förhoppningen är att forskarna ska kunna användaverktyget för att analysera och filtrera sin data, dra slutsatser kring återhämtningsprocessen hos pati-enter samt kunna se mönster i datan. Produkten tas fram utefter krav från kund (Bilaga A) och denprojektplan 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 diagno-sen 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 presentationsmil-jöer. Datorerna behöver vara utrustade med en uppdaterad webbläsare. Applikationen är inte tänktatt användas på handhållna enheter. Projektet begränsas av antalet utvecklare i projektgruppen ochav 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 vidprojektets start inte insatta i alla programspråk som ska användas i projektet. Systemet avgränsas avprojektgruppens 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 ochbrottsmyndigheter m.fl. för att forskare ska kunna studera återhämtningsprocessen för personer somfått diagnosen psykos. Dessa personer diagnostiserades mellan år 2000-2004. Personer som förr skul-le bott på mentalsjukhus, lever istället i det nya institutionella landskapet ute i samhället. Hur går detför dem? Vilka hjälp- och stöd-insatser får de? Dessa frågor är bakgrunden till varför visualiserings-applikationen skapas i det här projektet. Forskarna behöver ett hjälpmedel som de formulerat i tresteg, de vill kunna filtrera, sortera och jämföra olika individers återhämtningsfaser. Målgruppen förapplikationen som utvecklas i det här projektet är forskare med begränsad datorvana. Denna målgruppkrä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öratt skapa en grund till vidare efterforskning och utformande av projektet.

LifeLines: Visualizing Personal Histories [1] beskriver en applikation för att visualisera en övergripan-de bild av en individs liv och händelser från medicinska register och brottsregister. Projektgruppenhar 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 enlighetmed artikeln Exploring Time Diaries Using Semi-Automated Activity Pattern Extraction [2] är det förtidslinjegranskning ett mer givande gränssnitt att placera tiden utefter y-axeln och därigenom kunnavisa flera individer på samma gång under en längre tid. Artikelns fokuserar på automatiserat igenkän-nande av sekvenser och projektgruppen har kunnat ta till sig information från artikeln för att kunnautveckla den egna applikationen. Efterforskningar gjordes även runt D3.js och dess färdiga modulersom 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 sigvara svåra att omvandla valde projektgruppen att utveckla egna moduler anpassade till applikationensbehov.

3

Kapitel 3

Utvecklingsmetodik

I detta kapitel beskrivs vilka metoder som använts under utvecklingen av projektet. Agil systemut-veckling 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 kapitelinnehå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 huvudfokusför metoden är att kontinuerligt kunna tillhandahålla kunden en funktionsduglig produkt som efterhand kan utvärderas och förbättras. Metoden innebär att system ska byggas i korta iterationer utan förmycket dokumentation. Systemet ska testas ofta och det kan med fördel göras med automatiseradetestfall. Kunden får stor delaktighet i skapandet och utvecklingsprocessen av produkten. Arbetet skerinkrementellt och iterativt [5].

Projektet har utvecklats med hjälp av den Agila utvecklingsmetoden Scrum [6]. Arbetet har delats ini olika sprintar där varje sprint har haft ett mål i form av att en funktionalitet utvecklas. Ett sådantmål behandlas inom en story och delas upp i olika tasks. Att arbetsprocessen har varit Agil har inne-burit 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 hi-erarki. Gruppmedlemmarna har haft varsitt område där de haft det yttersta ansvaret över att bestämdarutiner 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 beskrivnai Kapitel 1.4. Kunden har också haft underliggande krav som syftar till särskild funktionalitet i deolika stegen. Dessa har framlagts på möten med kunden och ibland ändrats eller utvecklats. Idéer omimplementationer som uppkommit i ett senare skede i processen har utelämnats på grund av att deinte skulle hinnas med. Fokus har legat på att leverera en produkt baserad på kraven som fanns vidprojektets 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 arbetsmeto-den Scrum. Eftersom den gjordes i ett tidigt stadie fanns reservation för ändringar. Den slutgiltigatidsplanen presenteras i ett Gantt-schema i Figur 3.1, och är uppbyggd av sex sprintar med sammaarbetstidslängd.

Figur 3.1: Gantt-schema.

Arbetstillfällena var delvis gemensamma och delvis enskilda. Den planerade tiden för arbetet var 24timmar i veckan. En preliminär plan över milstolpar i projektet bakades in i sprintarna och beskrivsnedan.

Sprint 0

Projektet började med en planeringsfas. Perioden bestod av efterforskningar kring de tekniska verk-tyg 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örut-sä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 tillhanda-hå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ådeinnefattade huvudgrafen för visualiseringen och det andra området innefattade ett komplement i formav 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änssnitteti 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 attgränssnittet utvecklades i HTML, Javascript och CSS. Arbetet med filtrering av data påbörjades ochvisualiseringen 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 arbetetoch 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å applikationenoch kunden fick komma med synpunkter på design och implementationen. Storleken på data utöka-des för att kontrollera funktionaliteten av datahämtning. En färglegend med brushing-funktionalitetutvecklades för enklare navigering och bättre överblick i visualiseringen och en hovringsfunktionimplementerades. 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 ochprojektgruppens ö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 skaframlä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 harutvecklat för kunden. Förslag till eventuella utvecklingar efter det här projektets tid redogörs i kapitel7.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, seBilaga 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örden kommande sprinten lagts upp, vad som ska göras och vem som är ansvarig för vilken del un-der 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 atttilldelat 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 ar-betets status och vad de har för avsikt att göra under arbetsdagen. Här fanns även utrymme till attdiskutera eventuella problem. För att hålla mötet kort och effektivt har alla medlemmar stått uppunder mötet.

Kundmöte

Under arbetsprocessen har fyra kundmöten hållits då kunden bland annat fått ta del av och utvärderaprototyper av applikationen. Mötena har inneburit att kunden haft kontinuerlig kontakt med projekt-gruppen 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 arbeteutvärderats och sammanställts. Oavklarade uppgifter har skickats med till nästa sprint. Under mötethar koden för de funktionaliteter som skapats under sprinten tittats igenom i en walkthrough, se kapitel3.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 harhaft några möten där tekniska problem och lösningar har diskuterats. Experterna presenteras i BilagaB. 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 ver-sionshantering 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öroklarheter inom gruppen och ger även möjlighet att gå tillbaka för att ta reda på relevant fakta somantecknats tidigare. Dokumentationen har varit kortfattad och tydlig för att ge en överskådlig bildav vad som gjorts. All kod som skrivits har kommenterats och dokumenterats. Det finns huvudkom-mentarer överst i filen där det står vem som skrivit koden, vilket datum det skrivits och övergripandeinformation om koden. Det har även dokumenterats när koden lagts upp på GitHub, där varje commitinnehå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 be-stämts och diskuteras. Mötesprotokollen har sedan lagts upp på Google Drive för att ge alla utvecklaretillgå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 implemente-rats. Kunden har sedan framfört önskemål och krav på funktionerna som skall implementeras. Kravenhar skrivits ned i projektgruppens prioriteringslista på Trello och delats in i stories. Under en storyhar en viss funktionalitet behandlats och arbetet har delats upp i mindre tasks som baserats på de kravkunden 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 proces-sen. 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 detmöjligt att se när, var och av vem kod har implementerats. På Github användes en huvudgren, ävenkallad för master-branch. Varje enskild funktionalitet i applikationen har utvecklats på en egen grentill huvudkoden. Endast körbar kod har laddats upp på huvudgrenen efter testning och när all kod harsammanfogats 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 attskapa en slutprodukt med bra prestanda och hög kvalitet. Det är sällsynt att koden är felfri på engång och det är därför viktigt att kontinuerligt gå igenom den för att se att den gör det den ska utanproblematik.

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 atttänka på är att koden inte ska vara onödigt komplicerad. Det räcker med att den tillfredsställer defunktions- 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 skrivitklart en funktionalitet i programmet. Under dessa walkthroughs har koden gåtts igenom för de andragruppmedlemmarna 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 attse till att applikationen är användarvänlig. Det är lätt att vänja sig vid utseendet av applikationenunder 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 avanvä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 somkunde utföras. Fokus låg under dessa test på applikationens gränssnitt och användarvänlighet, iställetför på koden. Dessa test bidrog mycket med att se till att utvecklingen av applikationen skedde i rättriktning.

8

Kapitel 4

Teknisk beskrivning

Detta kapitel beskriver ingående systemets arkitektur, programdesign och utvecklingsverktyg. Syste-met och hur varje del är uppbyggd och relaterar till övriga delar beskrivs i Kapitel 4.1. Programde-signen 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, visu-alisering och gränssnitt.

4.1 Systemarkitektur

Systemarkitekturen visar hur systemet kan brytas ner i enheter, hur dessa enheter relaterar till varand-ra samt enheternas egenskaper [5, sid. 224]. Att redan innan systemet implementeras ha en tydligsystemarkitektur ä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 medvilken eller vilka enheter. Fördelen med en tydlig arbetsfördelning är att det möjliggör parallellt arbetemed systemets enheter. En tydlig arkitektur minskar inte bara kostnader och underlättar planeringenav 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ärkommunikation med enheter utanför den specifikt beskrivna delen av systemarkitekturen. Heldragetstreck 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 medolika 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 densekretessbelagda 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örligfö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 sorte-ringsval, samt att tolka och visa visualiseringen av datan från servern för användaren. Klienten är dendel 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, funktionoch anpassningsbarhet användes HTML, CSS och ramverket Bootstrap. Javascript och Javascript-biblioteket 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.jsanropas servern och data ritas till ett SVG-element, som skapats i HTML-koden. I Figur 4.2 visarpilarna 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 datanfrån databasen. Servern skapar en CSV-fil och skriver de personers identifikationsnummer som inteblivit bortfiltrerade till filen. Kunden kan använda CSV-filen för att göra vidare undersökningar avidentifikationsnumren 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 avNode.js. Denna Javascript-fil innehåller moduler som används av Node.js körning av servern. Dessamoduler är Sqlite3, Express, Path, FS. Modulen Sqlite3 hanterar uppstart av databasen. Path ochExpress används vid hämtning av data från databas. FS-modulen är till för att skapa och skriva datatill CSV-fil på servern. Hur modulerna och servern kommunicerar visas i Figur 4.3.

10

4.2. PROGRAMDESIGN KAPITEL 4. TEKNISK BESKRIVNING

Figur 4.3: Serverns uppbyggnad och kommunikation.

4.1.3 Databas

Databasen innehåller all data och består av en DB-fil. Denna DB-fil skapades utifrån två CSV-filermed hjälp av Node.js. Från databasen kan data hämtas med så kallade databasfrågor som skickas frånservern. Ett exempel på en databasfråga kan vara: ”hämta alla kvinnor som bor i bostadsrätt och harhemmavarande barn och sortera dessa på ålder”. Uppbyggnad och kommunikation med server visas iFigur 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 annatklasstrukturer, 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 filernai databasen som beskrivs i Kapitel 4.1.3. Databasen består av två tabeller, en för vardera CSV-fil. Denena tabellen innehåller informationen om händelserna i visualiseringen, bland annat start- och slut-datum. Den andra tabellen innehåller bakgrundsfakta om individerna. När information hämtas fråndatabasen 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 filtre-ring baserat på detta sker. Användarens filtreringsval skickas till ett REST-API, som i sin tur hämtarden valda datan från databasen. Hämtningen sker med hjälp av tredjeparts-API:et Sqlite3 och denvalda datan visualiseras i applikationen. För att en eventuell justering av filtreringen ska ske måsteanvändaren implicit skicka en ny hämtning till databasen. Detta sker med hjälp av en knapp i gräns-snittet. Applikationen skulle bli långsam och prestandan sänkas om datan hämtas vid varje nytt valanvä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 ärfillArray() respektive drawData(). I fillArray() används bakgrundsfakta-tabellen föratt skapa en lista som innehåller de filtrerade individerna. För att de ska visas i visualiseringen anro-pas drawData(). Ännu en gång hämtas data i databasen, men nu från tabellen som innehåller allahä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ärstora mängder data behandlas.

4.3 Utvecklingsverktyg

Under arbetet har programmet Webstorm använts. Med en studentlicens är programmet gratis attladda 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 ärGoogle Chrome och Mozilla Firefox. Deras verktyg är fullt tillräckliga och har använts av samtligautvecklare för att eliminera buggar.

Programkoden är skriven efter JavaScript-standard med stöd för tredjeparts-biblioteken D3.js ochNode.js. D3.js erbjuder stor kontroll av det visuella resultatet samt möjlighet att kunna anpassa funk-tioner efter projektets behov. Färdiga funktioner riskerar att låsa flexibiliteten i applikationen, därförhar 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 datanfrån databasen.

För att göra applikationen anpassningsbar har ramverket Bootstrap[10] använts. Ramverket är gratisoch förenklar webbsidors utformning och uppbyggnad på ett användarvänligt sätt. Det ger en tydligCSS-struktur som bygger upp HTML-elementen.

4.4 REST

Representational State Transfer (REST) är ett begrepp som blivit populärt inom mjukvaruutveck-ling sedan det introducerades 2000 av Roy Fielding [11]. REST är en hybridstruktur som syftar tillatt medföra viktiga arkitekturella egenskaper för klient- och server-kommunikation. Via dessa egen-skaper minimeras nätverkskommunikationen till när klienten kontaktar servern, vilket minskar för-dröjningar och mängden data som klienten behöver veta vid uppstart. Istället kan den önskade datanhämtas under körning och då anpassa klienten utefter responsen. Tillvägagångssättet kan beskrivassom att ge datan en unik adress via URI-standard. All data kan sedan genom ett gemensamt gränssnitti kommandon skickas mellan klient och server via HTTP-standarden: POST, GET, PUT och DELETEfö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 intressantadatan 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 ochreturnerades 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-biblioteketD3.js. Datan hämtas från servern och rektanglar ritas. Vilken höjd varje enskild rektangel har berorpå vilket start- och slutdatum händelsen har. Färgen bestäms utefter inställningar om filtrering ochdetaljnivå enligt en färgkod som skapats tillsammans med kunden. Grafen består av två axlar ochvarierande antal rektanglar. En karta över händelser och färger finns att se närmare i Bilaga E. Datankan visualiseras i tre olika detaljnivåer. Alla detaljnivåer visar samma valda händelser, skillnaden är atthändelserna visualiseras med olika många färger beroende på detaljnivån. Detaljnivå 1 består av fyrafärger, där varje färg representerar en huvudkategori. Alla händelser som tillhör samma huvudkategoriblir 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 enenkel användning av HTML, CSS och Javascript för att skapa responsiva hemsidor som fungerar försåväl datorskärmar och handhållna enheter. Bootstrap innehåller färdiga mallar som ger dynamik iapplikationen. Mallarna har i det här projektet fungerat som en grund att utgå ifrån och skapa egnautvecklingar genom.

13

Kapitel 5

Resultat

Applikationen Livslinjer är anpassad för att köras i en webbläsare på en dator. Resultatet har delatsin i två delar. Den första delen behandlar själva visualiseringsdelen av applikationen, det vill sägaden delen som visar all data. Andra delen behandlar gränssnittet, vilket handlar om hur menyer ochanpasssningbarheten 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. Visua-liseringen består av två delar och utgör huvudfokus i applikationen. Den ena delen är en graf meden 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ändelsenslä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 visualisering-en, se Bilaga F. Tidsaxeln är en utzoomad version av den data som visas i grafen för tillfället. Denligger 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 informa-tion 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 ochdatum för första kontakten med psykiatrin, se Bilaga F .

Beskrivningen av vad de olika färgerna representerar ligger under visualiseringen och kallas färgle-gend. Även legenden kan ses i Bilaga F, den är placerad under visualiseringen. Användaren kan medhjä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örsi menyn till vänster. Menyn är till en början dold, vilket kan ses i Bilaga G. I menyn görs val för fil-trering, sortering och detaljnivå. Valen görs genom att en kryssruta markeras. Åldersintervallet väljsgenom 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. Visualiseringenkommer att visas på största delen av skärmen. Användaren kan när som helst göra nya val i menynoch 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å olikastora skärmar. Både menyn och menyraden är gjorda anpassningsbara med hjälp av Bootstrap. Vi-sualiseringen anpassas efter sidans storlek då sidan uppdateras, medan menyn anpassas när fönstretskalas om.

16

Kapitel 6

Analys och diskussion

Det har varit utvecklande att i grupp genomföra ett större projektarbete. Mycket planering har krävtsoch många beslut har tagits. Tillsammans har projektgruppen uppnått framgång och bekämpat mot-gång. Ingen i projektgruppen hade tidigare erfarenhet av att arbetat Agilt, men trots det har arbetsme-toden 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 attden Agila arbetsmetoden Scrum har använts. Det tog tid att läsa på och sätta sig in i metoden ochtill en början fanns det osäkerheter kring hur saker och ting skulle utföras. Det tog även tid att skrivadokumenten som låg till grund för arbetet, vilket fördröjde uppstarten. Det var svårt att förutse ochplanera hur mycket arbete som skulle hinnas med under varje sprint. Vissa gånger fanns det tid över islutet av sprinten, trots att alla tasks avklarats. Andra gånger fanns det milstolpar som inte hanns medunder sprintens gång. Vid dessa tillfällen följde tasksen med till nästa sprint. Det tillkom uppgiftermed 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 återkopplingpå den.

6.1.2 Projekthantering

Arbetet strukturerades med Trello och tjänsten användes kontinuerligt under hela projektet. Trello varlätt att använda och gav en bra struktur. Det var tydligt vem som arbetade med vad och när arbetet hadeutförts. Att börja projektet med en sprint 0 var ett bra beslut av projektgruppen eftersom förarbetetsom gjordes effektiviserade de resterande sprintarna. Ett annat verktyg som effektiviserade arbetetvar Github. De flesta gruppmedlemmarna var bekanta med Github sedan tidigare och det var enkeltatt jobba på olika delar parallellt. Det uppstod dock problem när olika versioner av samma fil skullesammanfogas. Det var förväntat att det skulle uppstå problem men inte problemens antal. Kunskapenom hur felen skulle lösas fanns men inte tiden. Därför löstes oftast problemen genom att sammanfogafiler 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årtatt skapa en tydlig arkitektur och den ändrades flera gånger under projektet. En större refaktoreringskedde under sprint 3. Efter varje ändring var projektgruppen noga med att meddela och gå igenomkoden tillsammans.

6.2 Diskussion om förutsättningar

Projektgruppen anser att utvecklingen av visualiseringen hade haft bättre förutsättningar och kunnatgenerera ett bättre resultat om kundkontakten hade skett innan påbörjat arbete. Datan som applika-tionen 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 havarit ett problem men intressenternas tveksamheter och brist på kommunikation internt i kundgrup-pen ledde till att formatet på data ändrades flertalet gånger under projekttiden. Den slutgiltiga datanlevererades till projektgruppen sent i utvecklingsstadiet. Problemet var att när datan levererades ha-de den ett annorlunda format än överenskommet. Problemen som uppstod gick att lösa men tid somhade kunnat läggas på att skapa utvecklingar i applikationen och förbättra delar gick istället åt tillomstrukturering 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 nyaprogrammeringsspråk och en Agil utvecklingsmetod, skapades ett tillfredsställande slutresultat. Demilstolpar som sattes i början av projektet (Kapitel 3.2.1) blev uppfyllda. På grund av att gruppenanvä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 sigav Javascript-biblioteket tidigare. Ett flertal applikationer som liknade detta projekt fanns tillgängligtpå Internet, men var ofta inte till någon större nytta under implementeringen av koden. Detta beroddepå att många funktionaliteter i dessa liknande applikationer skilde sig ifrån det som eftersträvades iprojektet. 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öratt uppfylla kraven i Bilaga A. Efter att ha utforskat liknande projekt kom gruppen kom fram till attrepresentera händelser med rektanglar i olika färger. Det svåra var här att välja färger för alla olikahändelser. I samråd med kund togs det fram passande färger för de tre olika detaljnivåerna se BilagaE. Nyanser av dessa togs sedan fram med hjälp av verktyget ColorBrewer för att få en så stor kontrastsom möjligt mellan färgerna.

Ännu ett utmaning som gruppen stötte på under utvecklingen var inläsningen av datan. “Låtsasda-tan” som skapades bestod först av 5000 händelser. Från början lästes datan in direkt i D3.js, vilketfungerade bra tack vare det låga antalet händelser. Då den riktiga datan sedan levererades visade detsig att den bestod av ungefär 200 000 händelser. På grund av detta användes istället ett REST-API, seKapitel 4.4, för att läsa in datan snabbare. Även filtreringen blev tvungen att ändras på under utveck-lingsprocessen. I början lästes all data in, där den datan som inte skulle visas filtrerades bort. Dettavar onödigt och krävande för programmet. Istället gjordes det om så att endast den data som skullevisas hämtades, vilket snabbade upp applikationen avsevärt.

Sammanfattningsvis var utvecklingsprocessen krävande men lärorik. Flertalet problem blev tvungnaatt 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ättradproblemlö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 harutformats. Exempel från Internet kombinerades med exempel från Katerina Vrotsou och den förstaprototypen togs fram. Det gjordes en enkel skiss som visades för kunden. Kunden bedömde prototy-pen och hade oftast åsikter och frågor. Det var tur att prototypen endast var en skiss då den lätt kundeanpassas efter kundens nya önskemål. Det hade varit tidskrävande att ändra en färdigprogrammeradprototyp och därför fick kunden alltid uttrycka sina åsikter i tidigt skede. Kunden påpekade ofta sakersom projektgruppen inte hade tänkt på, till exempel att de ville att y-axeln skulle visa tid eftersom devar vana vid det. Under prototypens skapande uppstod det ofta frågor om applikationens funktiona-litet 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 kontinuerligakontakten med kunden krävde möten och kontakt via mejl. Tack vare kontinuerlig kundkontakt kundekunden 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 änd-ringar i krav om funktionalitet har uppkommit på fler kundmöten än önskvärt. Detta har projektgrup-pen förhållit sig till genom att skapa en prioritetslista tillsammans med kunden. En diskussion omkundens 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 attvisualiseringen 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 enmeny skapar bättre förståelse för dess funktionalitet. Hur applikationen såg ut med två menyer kanses i figur 6.1. Menyn placerades till vänster eftersom det är där de flesta människor tittar först, precissom att målgruppen läser text från vänster till höger. Symbolen med streck är en vanlig symbol somde flesta förknippar med en meny. Under användartesterna förstod alla att det fanns en dold menybakom symbolen. De förstod även att de var tvungna att trycka på ”Rita visualisering”-knappen övermenyn, för att rita ut visualiseringen. Knappen är grå och har en förklarande text på sig. Den ändrarfärg till blå när den är klickbar, vilket ger tydlig affordans. För att indikera en funktionalitet ändrasmuspekarens 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 re-gelbundet. Tack vare dessa tester skapades förståelse över hur en ovan användare hanterade applika-tionen. 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 medhjälp av gränssnittet. Om det var någon del av gränssnittet som var otydligt var det vanligt att flera tes-tare hade problem på samma ställe. Användartesterna var viktiga i skapandet av applikationen, trotsatt 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 testaapplikationen. En användare som är insatt i ämnet hade kanske förstått saker som vår testgrupp integjorde.

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. Iblandvar 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 andrajobbades på länge. Mellan varje sprint var målet att byta arbetsområden, för att alla i projektgruppenskulle skapa sig förståelse för projektets olika delar. Det blev inte alltid så eftersom det var enklast attfortsätta jobba på det man var mest insatt i. Problemet löstes genom att projektgruppen jobbade i pardär den ena redan jobbat inom ämnet och därför kunde förklarade för den som jobbat med en annandel 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 ge-nomföra alla mål och vissa mål prioriterades högre än andra. På grund av projektets tidbegränsninghanns inte alla mål med. Projektgruppen anser att de viktigaste målen, som skapar den grundläggandefunktionaliteten i applikationen, är uppnådda. Ett mål som prioriterades bort och inte uppnåddes varsekvenssökning av visualiseringen. En sådan funktion hade varit värdefull för kunden, som lättarehade kunnat urskilja mönster i datan. Mönster kan fortfarande ses i visualiseringen, men inte på ettlika tydligt sätt. Projektgruppen visste redan vid projektets start att denna funktionalitet kanske inteskulle hinnas med och kunden informerades tidigt om detta. Tack vare detta accepterade kunden attslutprodukten saknade sekvenssökningsfunktionen. En annan funktionalitet som inte hann implemen-teras var hanteringen av händelser som överlappar varandra. Händelser kan pågå parallellt och till enbörjan var ambitionen att det skulle visualiseras med olika färger eller mönster. Orsaken till att detinte 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 medresultatet.

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 storförsiktighet. Datan får aldrig lagras på Internet eller ha minsta chans att hamna där. Google Driveanvä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 USAhar legat bakom är Google Drive inte tillräckligt pålitligt för att lagra känslig data på. Ett annat landska 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 attkorsköra data från exempelvis kommun och landsting. Forskarna som kontaktat kunden till det härprojektet 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 versionuppfyller kundens och projektgruppens krav, men det finns utvecklingsmöjligheter. Dessa beskrivs iKapitel 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 diagno-sen psykos?

Att skapa en visualisering av en stor mängd data, som återhämtningsprocessen består av, krävdeplanering 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 tillatt datan visualiseras på ett sådant sätt att mönster kan ses. Vilka val som görs i filtreringen påverkarmönstrets struktur och tydlighet. Projektgruppen har genom att utveckla visualiseringsapplikationengjort 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 vadde tyckte var en bra struktur och hur de är vana att se data. Efterforskningarna som beskrivs i Kapitel2 gav att vid visualisering av data över lång tid är det fördelaktigt att visa tiden på y-axeln för att göravisualiseringen 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 ochen ä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, genomatt skapa algoritmer för att hitta olika slags sekvenser av händelser i datan. På så sätt kan ett ännumer avancerat system byggas upp där användaren har ännu fler valmöjligheter för att få fram deninformation som söks. Detta kan i sin tur leda till ännu mer framsteg inom det berörda ämnet ochfö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 UsingSemi-Automated Activity Pattern Extraction, electronic International Journal of Time Use Rese-arch 2008, Vol. 5, No. 1, 43-64.

[3] D3.js Library, hämtad: 2016-05-09https://github.com/mbostock/d3/wiki/Gallery

[4] Swimlane Chart using d3.js, hämtad 2016-05-09http://bl.ocks.org/bunkat/1962173

[5] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, Interna-tional Edition, Pearson 2010

[6] Schwaber, Ken och Sutherland, Jeff The Scrum Guide, juli 2013. Hämtad 2016-05-12http://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-05https://www.sqlite.org/

[9] NodeJs hämtad: 2016-05-05https://nodejs.org/en/

[10] Bootstrap hämtad: 2016-05-05http://getbootstrap.com/

[11] Roy Thomas Fielding Architectural Styles and the Design of Network-Based Software Archi-tectures Ph.D. Dissertation, 2000, hämtad:2016-05-09http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm

[12] Colorbrewer hämtad: 2016-05-05http://colorbrewer2.org/

24

Bilaga A

Kvalitetskrav

Nedan presenteras de kvalitetskrav som kunden och projektgruppen hade vid projektets början. Till-sammans 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 - PrototypansvarigArbetsområden: kodens arkitektur, anpassningsbarhet, lokalansvarig, användartester av gränssnittet,implementering av tidslinjen, testning och projektrapport.Isac Algström - Systemdesigner & testningsansvarigArbetsområden: Efterforskning, gränssnittsutveckling, visualisering, testning, filtrering, användartes-ter av gränssnitt, tidslinjen och projektrapport.Sofia Höglund - Ansvarig över gränssnittetArbetsområden: användartester av gränssnittet, anpassningsbarhet, projektrapport, prototyp, gräns-snittsutveckling, visualiseringen.Kristin Bäck - Ansvarig över möten & dokumentationArbetsområden: Efterforksning, gränssnittsutveckling, responsivitet i gränssnitt, visualisering, doku-mentansvarig, projektrapport, testning, hovring, filtrering, färger i visualisering.Dennis Hammer - Ansvarig över databas & data-analysArbetsområden: Efterforskning, databas, REST, server, visualisering, filtrering, sortering, testning,kodstruktur, mergning av kod, packagehantering, start-up fil för server och webbläsare (batchfil), pro-jektrapport.Anton Kaiser - Scrum master & projektledareArbetsområden: Efterforskning, kontakt med kund och intressenter, gruppdynamik, inläsning av datatill 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 visualiseringCarlo Navarra, webbexpertKarljohan 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 andraval 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 skaanvändas och de flesta lyckas även rita ut visualiseringen med rita data-knappen. Den högra menynmed detljanivåerna och sorteringen upptäcks först efter ett tag. Det räcker med en meny som innehål-ler filtrering, sortering och detljnivåer. De samlar funktioner med liknande funktionalitet tillsammansoch gränssnittet blir tydligare. Applikationen bör ha instruktioner på startsidan och rita data-knappenkan ha ett annat namn som förklarar dess funktion bättre. Placeringen av knappen borde vara bredvidmenyn, det skulle indikera att de hör ihop. Det är svårt att förstå att boxarna i färglegenden är klick-bara. En skuggning skulle öka deras klickbarhet och ge en 3D-effekt. Testpersonerna missar en delfunktioner som att det går att klicka på händelserna i visualiseringen. Som förbättringsförslag föreslogde 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

Bilaga G

Menyn

Figur G.1: Applikationens startsida.

32

BILAGA G. MENYN

Figur G.2: Applikationen när menyn är utfäld.

Figur G.3: Applikationen när olika val är ifyllda.

33