Visual Care
Utveckling av en webbapplikation
f¨or att visualisera v˚
ardprocesser
Otto Bergdahl
Peter Arvidsson
Victor Bennich
Hakan Celik
Petter Granli
Gunnar Grimsdal
Johan Nilsson
Handledare, Jonas Wallgren Examinator, Kristian Sandahl
Detta dokument h˚alls tillg¨angligt p˚a Internet – eller dess framtida ers¨attare – under 25 ˚ar fr˚an publiceringsdatum under f¨oruts¨attning att inga extraordin¨ara omst¨andigheter uppst˚ar.
Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or enskilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or undervisning.
¨
Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upp-hovsmannens medgivande. F¨or att garantera ¨aktheten, s¨akerheten och tillg¨angligheten finns l¨osningar av teknisk och administrativ art. Upphovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upp-hovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumen-tet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsmannens litter¨ara eller konstn¨arliga anseende eller egenart.
F¨or ytterligare information om Link¨oping University Electronic Press se f¨orlagets hemsida http://www.ep.liu.se/.
c Otto Bergdahl c Peter Arvidsson c Victor Bennich c Hakan Celik c Petter Granli c Gunnar Grimsdal c Johan Nilsson
Rapporten beskriver hur produkten Visual Care har tagits fram. Produkten ¨ar en webbapplikation f¨or visualisering av statistik fr˚an kunden Region ¨Osterg¨otland. M˚alet med applikationen ¨ar att hj¨alpa anst¨allda p˚a Region ¨Osterg¨otland att planera behandling av cancer-patienter.
Syften med den h¨ar rapporten ¨ar att analysera projektgruppens ut-vecklingsmetoder och processer f¨or att ta fram produkten Visual Ca-re. Produkten kommer inte att anv¨andas av Region ¨Osterg¨otlands anst¨allda, utan kommer ist¨allet att anv¨andas som en prototyp och inspiration f¨or framtida projekt av kunden.
Abstract
This report is about the production of the web application Visual Care. The product is a tool for visualising statistics provided by the customer Region ¨Osterg¨otland. The goal of the application is to help employees at Region ¨Osterg¨otland to plan treatment of cancer patients.
The purpose of this report is to analyze the group’s development pro-cess for the product. The product will not be used by the employees of Region ¨Osterg¨otland, but will instead be used as an inspiration for future projects by the customer.
Den h¨ar rapporten handlar om projektgruppens framtagning av produkten Visual Care, samt om medlemmarnas individuella delar. Till sist vill projektgruppen tacka handledaren Jonas Wallgren f¨or sitt engagemang f¨or projektet. Gruppen vill ¨aven tacka alla inblan-dade fr˚an Region ¨Osterg¨otland f¨or deras hj¨alp.
1 Inledning 3
1.1 Motivering . . . 3
1.2 Syfte och m˚al . . . 3
1.3 Fr˚agest¨allningar . . . 4
1.4 Avgr¨ansningar . . . 4
1.4.1 Avgr¨ansningar f¨or systemet . . . 4
1.4.2 Avgr¨ansningar f¨or rapporten . . . 4
2 Bakgrund 5 3 Teori 6 3.1 Standardiserade v˚ardf¨orlopp . . . 6
3.2 D3.js . . . 6 3.3 Node.js . . . 6 3.4 Mocha . . . 6 3.5 REST-API . . . 7 4 Metod 8 4.1 Utvecklingsmetod . . . 8 4.1.1 F¨orstudier . . . 8 4.1.2 Modifierad SCRUM . . . 9 4.1.3 Gr¨anssnittsdesign . . . 9
4.2 Metod f¨or att f˚anga erfarenheter . . . 11
5 Resultat 12 5.1 REST-API . . . 12 5.2 Kundkontakt . . . 12 5.3 Systembeskrivning . . . 12 5.4 Produkt . . . 14 5.5 Gemensamma erfarenheter . . . 15 5.5.1 Organisation . . . 15 5.5.2 Programutvecklingsmetodik . . . 16 5.5.3 Kundkontakt . . . 16 5.5.4 Dokumentation . . . 16 5.5.5 Programutveckling . . . 17 5.5.6 Systemanatomi . . . 17
5.6 Oversikt ¨¨ over individuella bidrag . . . 18
5.6.4 Bidrag D . . . 18 5.6.5 Bidrag E . . . 19 5.6.6 Bidrag F . . . 19 5.6.7 Bidrag G . . . 19 6 Diskussion 20 6.1 Diskussion av resultatet . . . 20
6.1.1 Alternativa implementationss¨att . . . 20
6.1.2 Tillfredsst¨allelse av kundens behov . . . 21
6.1.3 L¨ardomar fr˚an projektet . . . 21
6.2 Metod . . . 22
6.2.1 Konsekvenser f¨or resultatet . . . 22
6.2.2 Alternativa metoder . . . 22
6.2.3 K¨allkritik . . . 22
6.3 Arbetet i ett vidare sammanhang . . . 23
6.3.1 Samh¨alleliga aspekter . . . 23
6.3.2 Milj¨oaspekter . . . 23
6.3.3 Etiska aspekter . . . 24
A.1 Inledning . . . 29
A.1.1 Syfte . . . 29
A.1.2 Fr˚agest¨allningar . . . 29
A.2 Bakgrund . . . 30
A.3 Teori . . . 30
A.4 Metod . . . 31
A.5 Resultat . . . 31
A.5.1 Samlade erfarenheter . . . 31
A.5.2 Enk¨atunders¨okning . . . 32
A.6 Diskussion . . . 37
A.6.1 Resultatet . . . 37
A.6.2 Metoden . . . 38
A.7 Slutsatser . . . 38
B Peter Arvidsson - Visualisering i D3.js 39 B.1 Inledning . . . 39 B.1.1 Syfte . . . 39 B.1.2 Fr˚agest¨allningar . . . 39 B.2 Bakgrund . . . 39 B.3 Teori . . . 40 B.4 Metod . . . 40 B.5 Resultat . . . 41
B.5.1 Utv¨ardering av biblioteken och dess inbyggda funktioner . . . 41 B.5.2 Google Chart . . . 41 B.5.3 C3.js . . . 42 B.5.4 D3.js . . . 43 B.6 Diskussion . . . 46 B.6.1 Andam˚¨ al f¨or visualiseringsverktyg . . . 46 B.7 Slutsatser . . . 47
C Victor Bennich - Testa ett API med Mocha 48 C.1 Inledning . . . 48
C.1.1 Syfte . . . 48
C.1.2 Fr˚agest¨allningar . . . 49
C.2 Bakgrund . . . 49
C.5.1 J¨amf¨orelse . . . 53
C.6 Diskussion . . . 53
C.7 Slutsatser . . . 55
D Hakan Celik - Dokumentationsstrategi i ShareLaTeX 56 D.1 Inledning . . . 56 D.1.1 Syfte och m˚al . . . 56 D.1.2 Fr˚agest¨allningar . . . 56 D.2 Bakgrund . . . 57 D.3 Teori . . . 58 D.4 Metod . . . 59 D.5 Resultat . . . 59
D.5.1 Praktiska problem och l¨osningar . . . 59
D.5.2 Dokumentstrukturer . . . 61
D.6 Diskussion . . . 62
D.7 Slutsatser . . . 63
E Petter Granli - Automatiserad drifts¨attning av kod f¨or webbapplikationer 64 E.1 Inledning . . . 64
E.1.1 Syfte . . . 64
E.1.2 Fr˚agest¨allningar . . . 64
E.2 Bakgrund . . . 65
E.3 Teori . . . 65
E.3.1 SaaS (Software as a service) . . . 65
E.3.2 PaaS (Platform as a service) . . . 65
E.3.3 IaaS (Infrastructure as a service) . . . 66
E.3.4 Molnet . . . 66
E.3.5 Heroku . . . 67
E.3.6 Openshift . . . 67
E.3.7 Github . . . 67
E.3.8 Digital Ocean . . . 67
E.4 Metod . . . 68
E.4.1 Test av verktyg . . . 68
E.4.2 Litteraturstudie . . . 68
E.5 Resultat . . . 69
E.7 Slutsatser . . . 72
F Gunnar Grimsdal - Webbserver i Node.js 73 F.1 Inledning . . . 73 F.1.1 Syfte . . . 73 F.1.2 Fr˚agest¨allningar . . . 73 F.2 Bakgrund . . . 73 F.3 Metod . . . 75 F.3.1 Unders¨okning 1 . . . 75 F.3.2 Unders¨okning 2 . . . 78 F.3.3 Unders¨okning 3 . . . 79 F.4 Resultat . . . 80 F.4.1 Unders¨okning 1 . . . 80 F.4.2 Unders¨okning 2 . . . 80 F.4.3 Unders¨okning 3 . . . 81 F.5 Diskussion . . . 82 F.6 Slutsatser . . . 82
G Johan Nilsson - Utecklingsmetodik och Scrum 83 G.1 Inledning . . . 83 G.1.1 Syfte . . . 83 G.1.2 Fr˚agest¨allningar . . . 83 G.2 Bakgrund . . . 84 G.3 Teori . . . 85 G.3.1 Agil systemutveckling . . . 85 G.3.2 Scrum . . . 86 G.4 Metod . . . 87 G.5 Resultat . . . 88
G.5.1 Resultat fr˚an unders¨okningen . . . 88
G.6 Diskussion . . . 89
Del I: Gemensamma
1
Inledning
Inom h¨also- och sjukv˚ard har det historiskt genomf¨orts mycket sto-ra och betydande arbeten, men p˚a senare tid har befolkningen ¨okat. Idag ¨ar det d¨arf¨or en stor utmaning att f˚a en ¨overblick av hur m˚anga m¨anniskor som tillh¨or ett visst v˚ardf¨orlopp (se kapitel 3.1 Defini-tioner) och hur man optimalt kan f¨ordela resurser. Dock finns det st¨andigt v¨axande potential i digitala verktyg f¨or att underl¨atta han-teringen av denna typ av problem. Det ¨ar d˚a naturligt att f¨ors¨oka finna en l¨osning f¨or att visualisera tillg¨angliga data, vilket kommer att f¨ordjupas i detta arbete.
1.1 Motivering
I detta projekt har det d¨arf¨or utvecklats en webbapplikation f¨or visualisering av statistik f¨or standardiserade v˚ardf¨orlopp [46] som anv¨ands av Region ¨Osterg¨otland. Denna applikation ska framf¨or allt anv¨andas f¨or att hj¨alpa anst¨allda inom cancerv˚arden att pla-nera behandling av patienter enligt de riktlinjer som finns f¨or de standardiserade v˚ardf¨orloppen.
1.2 Syfte och m˚al
Syftet med detta arbete ¨ar att analysera projektgruppens utveck-lingsmetoder och processer f¨or att ta fram produkten. Vidare ges en redovisning av samtliga erfarenheter inom detta. I kursplanen f¨or TDDD96 Kandidatprojekt i programvaruutveckling, som nu ¨ar aktuell, ing˚ar det n¨amligen att skriva en kandidatrapport som be-handlar projektet. M˚alet med detta ¨ar att f˚a kunskaper om hur man uttrycker sig professionellt och vetenskapligt i skrift.
1.3 Fr˚agest¨allningar
I denna rapport ska f¨oljande fr˚agor besvaras;
1. Hur har projektgruppens produkt Visual Care implementerats f¨or att skapa v¨arde f¨or kunden?
2. Vilka erfarenheter kan dokumenteras fr˚an detta kandidatpro-jekt i kursen TDDD96 som kan vara intressanta f¨or framtida projekt?
3. Vilket st¨od kan man f˚a genom att skapa och f¨olja upp en sys-temanatomi?
4. Kan Visual Care spara tid och resurser hos kunden? 1.4 Avgr¨ansningar
Detta avsnitt anger projektets avgr¨ansningar. De indelas i tv˚a delar d¨ar den ena handlar om systemet och den andra om rapporten.
1.4.1 Avgr¨ansningar f¨or systemet
Avgr¨ansningar som finns ¨ar att produkten inte ska vara beroende av stora bibliotek och att all skriven programkod m˚aste vara ¨oppen k¨allkod. En annan avgr¨ansning ¨ar att kunden inte har beg¨art att n˚agra s¨akerhets˚atg¨arder ska implementeras.
1.4.2 Avgr¨ansningar f¨or rapporten
Rapporten tar upp de utvecklingsmetoder som har anv¨ants i pro-jektet. Den g˚ar d¨aremot inte igenom de utvecklingsmetoder som har ¨
overv¨agts men inte anv¨ants. Eftersom den huvudsakliga funktionen f¨or produkten ¨ar visualisering kommer extra fokus att l¨aggas just p˚a detta.
2
Bakgrund
Svensk sjukv˚ard har under en l¨angre tid haft problem med l˚anga v¨antetider. Inom cancerv˚ard har d¨arf¨or ett standardiserat v˚ ard-f¨orlopp inf¨orts, vars m˚al ¨ar att effektivisera v˚arden f¨or cancerpa-tienter. [46] I nul¨aget finns det ingen metod att f¨olja upp om v˚arden uppfyller den kvalitet och de ledtider som ¨ar specificerade f¨or de standardiserade v˚ardf¨orloppen. Projektet best¨alldes som ett verk-tyg f¨or att visuellt kunna visa om sjukv˚arden klarar av de krav som specificerats, samt visa vilken del i v˚ardprocessen som inte klarar av det.
Projektets gruppmedlemmar har tidigare arbetat i b˚ade h˚ ardvaru-och mjukvaruprojekt i form av robotbyggen, datordesign ardvaru-och andro-idutveckling, och k¨ande sig d¨arf¨or bekv¨ama med detta uppdrag. Gruppen har bland annat erfarenhet av att arbeta enligt LIPS-modellen. [2]
3
Teori
Detta kapitel g˚ar igenom en del begrepp som har anv¨ants i projektet. Det g˚ar ¨aven igenom speciella verktyg f¨or utveckling av produkten. 3.1 Standardiserade v˚ardf¨orlopp
Ett standardiserat v˚ardf¨orlopp, h¨adanefter SVF, betyder att alla som utreds f¨or en viss cancersjukdom ska bem¨otas lika och f˚a tillg˚ang till samma v˚ard. M˚alet ¨ar att alla unders¨okningar ska g¨oras s˚a fort som m¨ojligt och i samma ordning oavsett vem patienten ¨ar eller var denne bor. Varje cancersjukdom har t.ex. ett eget SVF. [46]
3.2 D3.js
D3.js ¨ar ett JavaScript-bibliotek som anv¨ands f¨or att visualisera da-ta med hj¨alp av webbtekniker som till exempel SVG, HTML5 och CSS3. [14] D3.js anv¨ands i projektet f¨or att visualisera v˚ardprocesser.
3.3 Node.js
Node.js ¨ar ett JavaScript-bibliotek byggt p˚a Chromes V8 JavaScript-motor. [20] Node.js anv¨ander en h¨andelsestyrd, icke-blockerande I/O-modell som g¨or den l¨att och effektiv. Node.js egna ekosystem f¨or paket, NPM, ¨ar enligt Linux.com det st¨orsta ekosystem f¨or ¨oppna bibliotek i v¨arlden. [30] I projektet anv¨ands Node f¨or att k¨ora det REST-API som hanterar produktens data och kommunikation.
3.4 Mocha
Mocha ¨ar ett testramverk i JavaScript som k¨ors p˚a Node.js och i webbl¨asaren, vilket underl¨attar asynkron testning. Mochatester k¨ors i serie, vilket m¨ojligg¨or flexibel och korrekt rapportering, medan kartl¨aggning av ohanterade undantag g˚ar till r¨att testfall. [33]
3.5 REST-API
REST st˚ar f¨or REpresentational State Transfer. Det bygger p˚a ett tillst˚andsl¨ost, klient-server, cachebart kommunikationsprotokoll. I m˚anga fall ¨ar det HTTP-protokollet som anv¨ands. REST ¨ar en arkitekturstil f¨or att utforma n¨atverksapplikationer. En anv¨andare beh¨over d˚a inte veta n˚agot om hur strukturen hos serversidan ser ut. [38]
4
Metod
Metoder som har anv¨ants kan delas in i tv˚a kategorier. Dessa inne-fattar utvecklingsmetoder och metoder f¨or att f˚anga erfarenheter.
4.1 Utvecklingsmetod
Detta delkapitel g˚ar igenom hur gruppen har arbetat med projektet och hur produkten togs fram.
4.1.1 F¨orstudier
Projektgruppen lottades fr˚an de studenter l¨aste kursen TDDD96 un-der 2017. Gruppen valde sedan projekt fr˚an ett antal projektf¨orslag som lagts fram fr˚an f¨oretag och fr˚an institutioner p˚a Link¨opings uni-versitet. Projektgruppen best˚ar av sju projektmedlemmar med olika roller. Vilka roller som b¨or ing˚a beslutades av examinator och i en-lighet med det f¨ordelade projektgruppen dessa internt. Den f¨orsta kontakten med kunden var genom ett mejl f¨or att informera kunden om vilka som kommer att vara deras leverant¨orer.
N¨ar det g¨aller dokumentation har projektgruppen anv¨ant sig av projektmodellen Lips kompletterad med anvisningar f¨or rapport-skrivning p˚a institutionen f¨or datavetenskap. [2] [49] Utbildningen inom projektgruppen har best˚att av individuell inl¨arning och test-program med hj¨alp av internet samt gemensamma genomg˚angar av olika implementationer av delprodukter.
N¨ar det g¨aller programkod har projektgruppen, genom interna m¨oten, diskuterat fram olika riktlinjer och standarder. Programkoden, vars centrala spr˚ak var HTML5, CSS3 och JavaScript, beslutades att kommenteras f¨or att f˚a en ¨overblick av den och f¨olja standarder f¨oreslagna av w3Schools. [44] [45] N¨ar det g¨aller versionshantering-en har det, tillsammans med konfigurationsansvarig, beslutats att anv¨anda Git. I Git skrivs varje delprodukt med hj¨alp av s˚a kallade f¨orgreningar f¨or att inte p˚averka resterande programkod. F¨or vidare detaljer se kvalitetsplanen i bilaga 1.
4.1.2 Modifierad SCRUM
Utveckling skedde med en variant av SCRUM med en sprinttid p˚a en vecka. [40] Prioriterade arbetsuppgifter best¨amdes gemensamt. Projektmedlemmarna tr¨affades en g˚ang per vecka f¨or att evaluera f¨oreg˚aende iteration samt att planera n¨asta. Under m¨otet rapporte-rades vad alla projektmedlemmarna hade utf¨ort. Detta skedde under varje handledarm¨ote och kompletterades med minst ett gruppm¨ote d¨ar fokus l˚ag p˚a veckorapportering och erfarenhetsf˚angst. F¨or en b˚ade mer flexibel och spontan respons fr˚an varje projektmedlem anv¨andes dessutom onlinetj¨ansten Slack. Mestadels skedde arbetet enskilt hemifr˚an, men mindre grupper kunde bildas f¨or att fokusera p˚a ett visst omr˚ade.
4.1.3 Gr¨anssnittsdesign
Efter att ett flertal kundm¨oten hade h˚allits, f¨or att komma fram till kundens verkliga behov, p˚ab¨orjades arbetet p˚a en f¨orsta proto-typ. Det som fokuserades p˚a med prototyperna i det h¨ar stadiet var sj¨alva visualiseringen av data fr˚an kunden och inte gr¨anssnitten f¨or menyer och andra kringfunktioner. Gruppen tog fram id´eer genom att rita upp skisser p˚a koncept p˚a en tavla och sedan diskutera dem. Tre lovande koncept valdes i detta stadie att arbetas vidare p˚a. Fr˚an dessa tre koncept skapades ett antal prototyper som visades f¨or kun-den, dessa kan ses i figur 1.
Parallellt med prototypningsarbetet jobbade delar av gruppen med att strukturera data, som tillhandah˚allits av kunden, i en databas. Klient-applikationen n˚ar datan som finns i databasen genom ett REST-API. N¨ar API:et b¨orjade designas fanns det endast ett f˚atal funktioner planerade. I efterhand som prototyper togs fram vida-reutvecklades funktionaliteten hos API:et f¨or att kunna bidra med filtrering av data fr˚an databasen.
N¨ar kunden hade godk¨ant vissa av prototyperna p˚ab¨orjades arbe-tet p˚a en f¨orsta version av applikationen. Anv¨andartester utf¨ordes l¨opande under produktutvecklingens g˚ang. St¨orre designbeslut togs gemensamt i gruppen genom omr¨ostning och vid behov tillfr˚agades ¨
aven kunden. En f¨orsta design av webbsidan togs fram, se figur 2.
4.2 Metod f¨or att f˚anga erfarenheter
Erfarenhetsf˚angst skedde med hj¨alp av olika gruppm¨oten och hand-ledarm¨oten d¨ar projektmedlemmarna fick ber¨atta om vad som hade varit bra och mindre bra med arbetet i varje sprint. Gruppm¨otena hade en fri agenda baserat p˚a vilka aktuella problem som skulle l¨osas, medan handledarm¨otena f¨oljde en mall framtagen av projekt-gruppen och dokumenterades i form av ett m¨otesprotokoll.
Under dessa tillf¨allen har det ¨aven diskuterats olika l¨osningar p˚a problem, b˚ade allm¨ant och i mer detalj. Projektgruppen har ¨aven nyttjat den ˚aterkoppling som har getts fr˚an andra projektgrupper p˚a de seminarier som ing˚ar i kursen. F¨or att komplettera ovan n¨amnda f˚angstmetoder har det ¨aven till˚atits att projektmedlemmar spontant kommit med synpunkter och fr˚agor under utveckling av projektet.
5
Resultat
Resultatet inleds med en beskrivning av vilken typ av API som har anv¨ants vid programutveckling. D¨arefter kommer en n¨armare re-dog¨orelse f¨or relationer med kunden och kundkontakten. Vidare ges en systembeskrivning av produkten f¨oljt av gemensamma erfaren-heter inom projektet och en avslutande ¨oversikt ¨over individuella bidrag i rapporten.
5.1 REST-API
Ett API f¨or kommunikation mellan databasen och applikationen ska-pades f¨or att dynamisk kunna h¨amta data som webbapplikationen beh¨ovde. API:et fungerar s˚a att applikationen skickar en HTTP GET-f¨orfr˚agan till API:et, som sedan skickar tillbaka ett JSON-objekt, ett datautbytesformat, till applikationen med de data som f¨orfr˚agades. API:et st¨odjer tv˚a olika ”resurser” i GET-f¨orfr˚agan, /persons/[nummer] och /persons/. Om man anv¨ander resursen /per-sons/[nummer] d¨ar [nummer] ¨ar ett heltal kommer API:t returnera data f¨or den person med ID passande heltalet. Om resursen /per-sons/ anv¨ands kan anv¨andaren med hj¨alp av parametrar i GET-f¨orfr˚agan filtrera och sortera de data som skickas tillbaka.
5.2 Kundkontakt
Gruppen har haft en aktiv kontakt med kunden, och har m¨ott en rad olika m¨anniskor fr˚an olika delar av Region ¨Osterg¨otland. Grup-pen har i perioder haft en del problem med kunden, d˚a kunden inte haft en komplett bild av vad det ¨ar den vill ha. Projektgruppen har l¨ost det genom att tr¨affa en m¨angd olika personer fr˚an Regi-on ¨Osterg¨otland, samt genom att presentera ett antal exempel och prototyper f¨or kunden.
5.3 Systembeskrivning
Produkten som levereras till kund best˚ar av tv˚a delar, en klient- och en serverdel. En ¨overblick ¨over detta ges i figur 3. Serverdelens upp-gift ¨ar att kommunicera med en databas och svara p˚a f¨orfr˚agningar fr˚an klientdelen. Serverdelen har ¨aven funktionalitet f¨or att impor-tera data till databasen samt att sorimpor-tera och filtrera data.
Klient-delens uppgift ¨ar att visualisera data som efterfr˚agas fr˚an serverde-len. Anv¨andaren kan via klientdelen v¨alja mellan olika datavisuali-seringsvyer och vilka data som ska visas med hj¨alp av olika filtre-ringsreglage.
Vid utveckling av produkten har gruppen genomg˚aende arbetat med HTML5, CSS3 och JavaScript som programspr˚ak. I praktiken in-neb¨ar detta att b˚ade klient- och serverdel ¨ar skrivna i JavaScript d¨ar Node.js anv¨ands f¨or att exekvera koden p˚a serversidan. Produk-ten har st¨od f¨or att anv¨anda en rad olika databaser av SQL-typ d¨ar kundens efterfr˚agade, Microsoft SQL, ing˚ar.
5.4 Produkt
Produkten levereras som en webbaserad l¨osning och riktas fr¨amst mot l¨akare och de inom sjukv˚arden som har och beh¨over tillg˚ang till statistik f¨or cancerpatienter. Anv¨andaren av produkten bem¨ots av en ¨overblick ¨over tre huvudsakliga diagramtyper beroende p˚a vilken statistik anv¨andaren vill se. Dessa tre diagram motsvarar:
• En enkel f¨ordelning mellan exempelvis ˚alder och k¨on p˚a pati-enter inom SVF
• Ett sambandsdiagram med estimerade utg˚angsdatum baserat p˚a normalf¨ordelning
• En mer detaljerad normalf¨ordelning med expanderbar informa-tion om patienter f¨or valt datum.
Efter vald diagramtyp presenteras anv¨andaren av en graf tillsam-mans med filtreringsalternativ inneh˚allandes bland annat tidsinter-vall, ˚aldrar, k¨on, kommun, med fler. Se figur 5 f¨or att tydligare se hur gr¨anssnittet presenteras.
F¨or att inte tappa n˚agon v¨ardefull information och ha m¨ojlighet att framf¨ora ett diagram vidare, kan en sk¨armdump av inneh˚allet sparas med hj¨alp av en knapp. Ny data f¨or visualiseringen kan ¨aven laddas upp fr˚an ett Excel-dokument direkt p˚a applikationen. Med den v¨anstra menyn kan anv¨andaren dessutom snabbt v¨axla mellan de olika diagramtyperna.
Figur 5: Vald typ av diagram med filtreringsalternativ.
5.5 Gemensamma erfarenheter
Genom projektet har projektgruppen samlat m˚anga olika erfaren-heter. Dessa ¨ar bland annat inom organisation, programutveckling, dokumentation och kundkontakt som n¨armare beskrivs i detta av-snitt.
5.5.1 Organisation
N¨ar det g¨aller organisation har projektgruppen tillsammans tagit fram olika hj¨alpmedel och verktyg f¨or att hantera olika typer av in-formation. Kommunikation g¨allande projektet har skett via Slack
och omfattat information om m¨oten, seminarier, kundkontakt, sta-tus f¨or delprodukter och allm¨anna fr˚agor kring olika ¨amnen. Detal-jerad information om detta ges i kvalitetsplanen, se bilaga. Projekt-gruppen har varit n¨ojd med detta eftersom det har visat sig vara ett snabbt och effektivt s¨att att dela information.
5.5.2 Programutvecklingsmetodik
Inom programutvecklingsmetodik fanns det i b¨orjan av projektet ett intresse f¨or att anv¨anda sig av en mer formell och v¨aldefinierad metod. I samband med detta f¨oreslogs SCRUM och efter en diskus-sion kring dess ing˚aende faser och koncept beslutades det att arbeta enligt en modifierad variant som beskrevs tidigare. Detta f¨or att projektgruppen upplevde att endast n˚agra koncept, som i det h¨ar projektet innebar planering och arbete i sprintar, skulle bidra till en effektivare programutveckling och att resterande endast skulle ta tid som ist¨allet kunnat ¨agnas ˚at annat. Efter en utv¨ardering av detta visades sig att denna metod var l¨amplig f¨or just denna projektgrupp och projekt eftersom inga problem uppstod p˚a grund av detta val.
5.5.3 Kundkontakt
Projektgruppens kundkontakt har inneburit de st¨orsta utmaningar-na. Kunden har haft en vision och ¨onskan kring den slutliga produk-ten, men ingen s¨arskild ˚asikt om detaljer. Vidare har det f¨ormedlats att detta ist¨allet kan sk¨otas av projektgruppen. Detta ledde till pro-blem inom programutvecklingen speciellt i b¨orjan av projektet. Pro-jektgruppen l¨oste detta genom att f¨ors¨oka finna ett rum av id´eer som t¨acker kundens kreativitet och krav. D¨arf¨or har m˚anga olika proto-typer utvecklats och presenterats f¨or kund med syfte att g˚a fr˚an en vision till en konkret l¨osning. I samband med dessa kundm¨oten har projektgruppen l¨art sig att man verkligen beh¨over v¨agleda kunden med fr˚agor och f¨orslag som, av projektgruppen, anses vara m¨ojliga och rimliga l¨osningar.
5.5.4 Dokumentation
I och med att dokumentation mestadels har genomf¨orts via onli-netj¨ansten ShareLaTeX har det medf¨ort problem och l¨osningar p˚a dessa. De huvudsakliga problemen har bland annat varit spr˚akets
inl¨arningsfas, syntaktiska fel och sv˚arigheter med att tyda kom-pileringsfel. Samtliga problem har l¨osts och trots att det kr¨avdes f¨orarbete upplevde projektgruppen verktyget som nyttigt inf¨or fram-tida dokumentation. En mer detaljerad beskrivning av l¨osningarna ges av det individuella bidrag givet av kvalitetssamordnare och do-kumentansvarig.
5.5.5 Programutveckling
N¨ar det g¨aller programutveckling har kunden rekommenderat att programspr˚aken g¨arna ¨ar s˚a f˚a som m¨ojligt och att de helst ¨ar kom-patibla med JavaScript. D¨arf¨or f¨oreslogs, i b¨orjan av projektet, att det centrala programspr˚aket skulle vara TypeScript. Projektgrup-pen ans˚ag det l¨ampligt f¨or projektet, men efter en p˚ab¨orjan av pro-duktens back-end, som skrevs i Node.js, uppt¨acktes det att Type-Script inte hade den ¨onskade kompatibiliteten med Node.js. D¨arf¨or ¨
overgick projektgruppen till JavaScript. Projektgruppen har varit n¨ojd med programspr˚aket eftersom det har erbjudit mer frihet i hur olika mindre problem kunde l¨osas, trots att det medf¨orde mer disci-plin och komplexitet vid programmering.
Vid utvecklingen av produktens front-end var det inga oklarhe-ter med att HTML5 och CSS3 skulle vara centrala programspr˚ak. D¨aremot har projektgruppen parallellt testat tv˚a metoder f¨or att generera olika grafer och diagram. Dessa var programbiblioteken D3 och C3 d¨ar D3 bygger p˚a JavaScript och C3 p˚a D3. Projektgruppen uppt¨ackte tidigt att anv¨andandet av C3 var mycket enklare eftersom det kr¨avdes ett tiotal rader programkod i C3 och ett hundratal ra-der programkod i D3 f¨or att erh˚alla samma resultat. D¨arf¨or hade projektgruppen hoppet att C3:s bibliotek skulle vara tillr¨ackligt f¨or samtliga visualiseringar. Dock var det inte fallet och C3:s begr¨ansade bibliotek ledde d¨arf¨or till att projektgruppen helt ¨overgick till D3. D¨armed accepterades det att arbeta med ett mer komplext bibliotek f¨or att erh˚alla den ¨onskade friheten vid utvecklingen av produktens front-end.
5.5.6 Systemanatomi
Inf¨or utveckling av v˚ar produkt gjordes en systemanatomi f¨or att underl¨atta utvecklingsarbetet. Systemanatomin hj¨alpte gruppen att
gemensamt arbeta mot det stora m˚alet genom att dela upp arbetet i mindre bitar och tydligt visa vilka delar som var viktiga. Gruppen hade hj¨alp av systemanatomin d˚a den visade tydligt vilka funktioner som var ¨onskv¨arda snarare ¨an hur dessa skulle implementeras. 5.6 Oversikt ¨¨ over individuella bidrag
De individuella bidragen, sju stycken, beskrivs ¨oversiktligt nedan.
5.6.1 Bidrag A
Otto Bergdahls bidrag handlar om kontakten mellan projektgruppen och best¨allare/kund. Texten g˚ar igenom problem som kan uppst˚a vid kundkontakt och kravs¨attning samt redovisar en unders¨okning om hur kontakt med best¨allare och kund sett ut f¨or andra grupper i kursen TDDD96. Bidraget avslutas med en diskussion om de erfa-renheter deltagare i kursen har tagit med sig fr˚an kontakten med kund och best¨allare som kan komma till nytta i framtida arbeten i projektform.
5.6.2 Bidrag B
Peter Arvidssons bidrag handlar om f¨ordelarna med att anv¨anda sig av ett visualiseringsverktyg som D3.js, vad som utm¨arker det och hur det skiljer sig fr˚an andra liknande visualiseringsverktyg.
5.6.3 Bidrag C
Victor Bennichs bidrag handlar om vilka vinsterna av automatisera-de testning ¨ar och ger en ¨overblick av testverktyget Mocha. En grov introduktion till att s¨atta upp automatiska tester med Mocha ges och en j¨amf¨orelse och diskussion g¨ors kring huruvida vinsterna av automatisk testning r¨attf¨ardigar resurserna som l¨aggs ned p˚a dess utveckling.
5.6.4 Bidrag D
Hakan Celiks bidrag handlar om dokumentationsstrategi i Share-LaTeX. Syftet ¨ar att analysera identifierade praktiska problem vid dokumentation i onlinetj¨ansten ShareLaTeX, om det finns l¨osningar p˚a dem och hur man ska organisera dokumentation f¨or att erh˚alla
en kvalitativ dokumentstruktur. Slutsatser som dras ¨ar att det finns m˚anga olika problem inom exempelvis inl¨arning och programmering samt att det beh¨ovs en skr¨addarsydd dokumentstruktur anpassad till projekt och projektgrupp.
5.6.5 Bidrag E
Petter Granlis individuella bidrag handlar om verktyg f¨or automa-tiserad drifts¨attning av kod f¨or webbapplikationer och fokuserar p˚a vilka f¨ordelar dessa f¨or med sig samt skillnaderna mellan dessa olika verktyg.
5.6.6 Bidrag F
Gunnar Grimsdals individuella bidrag handlar om prestanda hos en enkel webbserver skriven i JavaScript och exekverad i Node.js j¨amf¨ort med andra l¨osningar. Syftet ¨ar att hitta skillnader i pre-standa och att unders¨oka hur asynkrona funktioner kan f¨orb¨attra prestandan hos webbservern.
5.6.7 Bidrag G
Johan Nilssons individuella bidrag handlar om agil utveckling och utvecklingsmetodik f¨or mindre projekt. Syftet med det individuella bidraget ¨ar att diskutera huruvida Scrum passar som utvecklings-metodik f¨or ett mindre projekt, samt unders¨oka om det finns n˚agon annan etablerad utvecklingsmetodik som passar b¨attre.
6
Diskussion
I detta kapitel diskuteras resultat, metod och arbetet i ett vida-re sammanhang. Det behandlar vida-resultatets alternativa utseende, utv¨ardering och l¨ardomar. Vidare f¨ors en diskussion kring anv¨anda metoder, dess konsekvenser och alternativ samt k¨allkritik. Kapit-let avslutas med att beskriva hur produkten f¨orh˚aller sig till olika aspekter.
6.1 Diskussion av resultatet
I detta avsnitt diskuteras resultatet genom att behandla alterna-tiva implementationss¨att, tillfredsst¨allelse av kundens behov och l¨ardomar fr˚an projektet.
6.1.1 Alternativa implementationss¨att
M˚anga beslut om hur produkten skulle implementeras har tagits under projektets g˚ang och sj¨alvklart finns det andra s¨att att imple-mentera en produkt med samma funktionalitet. Ett tydligt exem-pel p˚a en alternativ l¨osning ¨ar att f¨or varje diagram ha ett sepa-rat HTML-dokument. F¨ordelen med separata HTML-dokument f¨or varje diagram ¨ar att anv¨andaren inte beh¨over ladda ner lika myc-ket information fr˚an servern f¨or att webbapplikationen ska fungera vid start. En annan f¨ordel vore mindre komplex JavaScript-kod d˚a webbservern och webbl¨asaren hade hanterat vilken graf som skulle laddas. En nackdel med denna metod ¨ar att identisk kod finns i olika dokument och d¨armed g¨or vidareutveckling sv˚arare.
I b¨orjan av projektet fick projektgruppen direktiv att produkten skulle kunna l¨asa data fr˚an en Microsoft SQL Server, men efter ett senare kundm¨ote blev gruppmedlemmarna informerade om att kun-den inte hade tillg˚ang till n˚agon SQL-server. Vid denna tidpunkt hade dock produktens API redan utvecklats. Nu i slutet av pro-jektet har gruppen implementerat en funktion i webbapplikationen som kan l¨asa in patientdata fr˚an xlsx-filer. Om gruppen hade f˚att information om att kunden inte hade tillg˚ang till n˚agon databas i b¨orjan av projektet hade troligtvis implementationen av produkten sett helt annorlunda ut, speciellt eftersom API:et i nul¨aget ¨ar helt oanv¨andbart f¨or kunden. Ist¨allet f¨or att utveckla API:et och
server-delen hade gruppen kunnat l¨agga sin tid p˚a att f¨orb¨attra webbapli-kationen samt funktionen att l¨asa xlsx-filer.
6.1.2 Tillfredsst¨allelse av kundens behov
Innan projektstart hade kunden inget bra s¨att att lokalisera brister eller f˚a en tydlig ¨overblick ¨over patient- och resursf¨ordelningen inom v˚arden eftersom all information om v˚ardf¨orloppet fanns i journaler, dokument, listor inf¨orda i Microsoft Excel och liknande. M˚alet med produkten var att tydligt visualisera den information som fanns och d¨armed hj¨alpa kunden att f˚a en tydlig ¨overblick av patient- och re-sursf¨ordelningen. Efter ett flertal kundm¨oten ins˚ag gruppen att kun-den inte hade tillg˚ang till data p˚a det s¨att som det hade f¨orklarats tidigare under projektet och d¨arf¨or lades fokus ist¨allet p˚a att skapa en prototyp som skulle visa hur produkten skulle kunnat fungera. F¨or att tillfredsst¨alla kundens behov hade produkten beh¨ovt l¨asa pa-tientdata fr˚an analysverktyget Power BI och logga alla anv¨andare som beg¨arde patientdata. [32]
6.1.3 L¨ardomar fr˚an projektet
B˚ade gruppen och kunden kan dra mycket l¨ardom av projektet. Gruppen har l¨art sig vikten av att komma ig˚ang tidigt med att f˚a fram en produktid´e f¨or att arbetet skall fortskrida sm¨artfritt och kunden kan hitta f¨orb¨attringsm¨ojligheter vid uppdragsgivande f¨or att underl¨atta detsamma.
Gruppens val att dela upp utvecklingen av applikationen i en server-och en klientdel med separat utveckling server-och versionshantering av de tv˚a har underl¨attat programmeringsarbetet avsev¨art. F¨or mindre erfarna programmerare blir det l¨att kodkrockar n¨ar m˚anga arbetar med samma produkt vilket praktiskt taget eliminerades i och med v˚art tillv¨agag˚angss¨att. Gruppen upplevde ocks˚a att m¨angden admi-nistration och koordination mellan gruppmedlemmarna minskades n¨ar det gick att dela in gruppen i mindre grupper.
6.2 Metod
H¨ar diskuteras effekterna av hur utvecklingsmetoden har p˚averkat resultatet och en diskussion kring alternativa metoder. Vidare ges en k¨allkritik kring de referenser som har anv¨ants i rapporten.
6.2.1 Konsekvenser f¨or resultatet
Sprinter med ¨overgripliga m˚al per sprint har kunnat effektivisera arbetet med en klar uppdelning av arbetetsb¨ordan i gruppen. Med regelbundna m¨oten har alla medlemmar i gruppen uppdaterats om hur projektets status ligger till. Eftersom produktens krav f¨or¨andats under projektets g˚ang har arbetet l¨att kunnat anpassas sprintvis till nya krav och ny funktionalitet som efterfr˚agats.
6.2.2 Alternativa metoder
Projektgruppen har valt att inte anv¨anda metoder som vattenfalls-metoden och ist¨allet g˚att p˚a en mer agil v¨ag f¨or att kunna anpassa utvecklingen till nya och f¨or¨andrade krav. Om vattenfallsmetoden anv¨ants skulle ¨andringar p˚a krav inneburit att vi skulle passerat designfasen n¨ar nya krav dykt upp fr˚an kunden och projektet hade blivit mindre flexibelt.
6.2.3 K¨allkritik
M˚anga av k¨allorna som anv¨ands i denna rapport kommer ifr˚an ut-vecklarna av produkten som k¨allorna handlar om. Detta ger att k¨allorna med all sannolikhet st¨ammer n¨ar det kommer till rent tek-niska detaljer. Dock kan utvecklare glorifiera sin produkt vilket kan ge att endast de positiva delarna av produkten tas upp i k¨allorna. De produkter som gruppen har anv¨ant har dock testats i den ut-str¨ackning som har varit m¨ojligt. I dessa fall har mindre program skrivits med syfte att unders¨oka om produktens funktionalitet mot-svarat gruppens efterfr˚agan. D¨armed har eventuella negativa aspek-ter av produkten kommit upp.
Vid anv¨andning av icke publicerade k¨allor som bloggar eller mindre officiella informationsblad har upphovsm¨annen i m¨ojlig m˚an bak-grundkollats och gruppen har f¨or varje k¨alla f¨ors¨okt verifiera infor-mationen mot andra k¨allor.
6.3 Arbetet i ett vidare sammanhang
Under en utvecklingsprocess ¨ar det l¨att att endast fokusera p˚a pro-gramkod och att uppn˚a funktionalitet, men denna sektion behandlar fler ¨an de tekniska aspekterna f¨or produkten.
6.3.1 Samh¨alleliga aspekter
Sjukv˚arden ¨ar en s¨arskilt viktig samh¨allsfunktion d¨ar ¨agande och styre till avg¨orande del best˚ar av samh¨allet sj¨alvt. Sjukv˚arden ¨ar beroende av samh¨allets fullgoda funktion och vice versa. D¨armed sker en sj¨alvklar p˚averkan av samh¨allet vid vidareutveckling och ef-fektivisering av sjukv˚arden.
Vid utveckling av v˚ar produkt ˚at Region ¨Osterg¨otland l˚ag fokus sj¨alvklart p˚a att produkten skulle underl¨atta f¨or kunden. I fallet med v˚ar produkt gick s˚aledes m˚alet med produkten och samh¨allsnytta hand i hand eftersom en effektivare sjukv˚ard naturligt leder till minskad kostnad f¨or samh¨allet. Det leder antagligen ocks˚a till en behagligare upplevelse f¨or v˚ardtagare och dess anh¨origa. S¨arskilt viktigt kan detta upplevas i samband med det som produkten ¨ar t¨ankt att underl¨atta, dvs. arbete vid cancerdiagnoser.
6.3.2 Milj¨oaspekter
Ett s¨att att minska det negativa avtrycket p˚a milj¨on fr˚an produk-ten ¨ar att optimera antalet n¨atverkspaket som skickas till webbap-plikationen. Detta kan g¨oras genom att minska storleken p˚a alla JavaScript-, HTML- och CSS-filer som beh¨ovs f¨or att webbapplika-tionen ska fungera. Alla dessa filer g˚ar att komprimera genom att ta bort alla obetydliga mellanrum, indrag och radbrytningar, detta g¨or dock koden mer sv˚arl¨ast. Genom att beh˚alla den okomprimerade filen, som kan anv¨andas f¨or vidareutveckling, och vid varje uppda-tering skapa nya komprimerade filer som servern anv¨ander beh˚aller man l¨asbarheten.
Ett annat s¨att att minska n¨atverksanv¨andningen ¨ar att minska an-talet f¨orfr˚agningar webbapplikationen g¨or till servern. V˚ar f¨orsta prototyp av webbaplikationen laddade in alla JavaScript filer och hela databasen varje g˚ang ett nytt diagram visades. Detta var ingen
bra l¨osning. D¨arf¨or ¨andrades det till att databasen endast laddas in f¨orsta g˚angen en anv¨andare g˚ar in p˚a hemsidan och att webbappli-kationen laddar in JavaScript-filerna n¨ar det beh¨ovs.
REST-API:t komprimerar den data som returneras med gzip. [22] Detta ¨ar inte ett lika sj¨alvklart val som att komprimera filer ge-nom att ta bort obetydlig information eftersom data komprimerad med gzip beh¨over avkodas av webbapplikationen; en operation som anv¨ander energi. Huruvida anv¨andningen av gzip ¨ar ett bra alter-nativ beror p˚a hur mycket energi det tar att skicka n¨atverkspaketen mellan webbapplikationen och API:t och hur mycket energi det tar f¨or webbapplikationen att avkoda informationen.
6.3.3 Etiska aspekter
Produkten kommer att behandla sekretesslagd information som per-sonnummer, namn och adresser. Om dessa uppgifter l¨acks ut eller obeh¨origa f˚ar tilltr¨ade till dem s˚a kan det inneb¨ara risker f¨or pati-enterna.
Eftersom s¨akerhet inte togs h¨ansyn till under utvecklingen av pro-dukten f˚ar kunden ist¨allet anv¨anda den p˚a ett ansvarsfullt s¨att. Om produkten endast ¨ar tillg¨anglig p˚a ett slutet n¨at och med en in-loggningsfunktion minimeras riskerna f¨or att information l¨acker ut. Produktens funktionalitet i sig skulle kunna g¨ora stor nytta i v˚arden f¨or att prioritera resurser och i slut¨andan r¨adda liv. Avv¨agningen ¨ar att riskera personlig information f¨or att f¨orb¨attra v˚arden. Eftersom detta sker varje dag i samh¨allet g¨or det inte denna produkt unik ur ett etiskt perspektiv.
7
Slutsatser
Syftet med detta arbete var att analysera projektgruppens utveck-lingsmetoder och processer f¨or att ta fram produkten. Vidare skulle det ges en redovisning av samtliga erfarenheter inom detta. Arbe-tet har besvarat detta och projektgruppen kan dra slutsatser kring fr˚agest¨allningarna enligt f¨oljande:
1. Produkten Visual Care har implementerats som en hemsida med funktionalitet f¨or att visualisera data fr˚an Region ¨Osterg¨ ot-land.
2. N¨ar det g¨aller erfarenheter kan det s¨agas att projektgruppen skulle ha kunnat b¨orja med implementationen tidigare om kun-den hade varit tydligare med vad som ¨onskades.
3. F¨or att hantera detta har projektgruppen, med hj¨alp av en systemanatomi, identifierat de viktigaste behoven hos kunden och fokuserat p˚a funktionalitet som tar h¨ansyn till det.
4. Produkten kommer i sitt nuvarande tillst˚and att fungera som en prototyp och inspiration f¨or en integrerad version hos kunden. Om kunden implementerar en version baserat p˚a Visual Care kommer tid och resurser att sparas eftersom helhet och detaljer klarg¨ors tydligare j¨amf¨ort med dokumentation i pappersformat.
A
Otto Bergdahl - Erfarenheter av kontakt med
best¨
allare och kund under ett projekt
A.1 Inledning
Detta kapitel unders¨oker hur kontakten med best¨allare och kund har fungerat under projekten som genomf¨orts i samband med kursen TDDD96 VT17. Under projektet har en av de st¨orsta utmaningarna f¨or gruppen varit kontakten med best¨allaren och att ta deras behov och visioner och skapa en konkret produkt. Unders¨okningen bygger till stor del p˚a en enk¨atunders¨okning med personer som g˚ar kursen TDDD96 VT17 och deras erfarenheter om kontakt med kund och best¨allare under projektet.
A.1.1 Syfte
Syftet med denna unders¨okning ¨ar att se hur kontakt med best¨allare och kund har fungerat under projektet, vad som g˚att bra, vad som g˚att mindre bra och vilka erfarenheter som kan hj¨alpa i framtida projekt och vidare i arbetslivet.
A.1.2 Fr˚agest¨allningar
1. Vilka erfarenheter har samlats ang˚aende kundkontakt under projektet?
2. Hur har kontakten med kund/best¨allare fungerat f¨or projekt-grupperna i kursen TDDD96 VT17?
A.2 Bakgrund
I projektet i kursen TDDD96 har f¨oretag lagt fram projektf¨orslag som studenterna i grupper om ca 7 sju personer har f˚att v¨alja mel-lan. Varje projektf¨orslag bestod av en beskrivning av produkten p˚a ca tv˚a A4-sidor. Efter att gruppen valt ett projektf¨orslag p˚ab¨orjades kontakt med best¨allaren. Utifr˚an denna kontakt skulle gruppen spe-cificera krav och planera projektet. Sedan skulle planen genomf¨oras och en produkt till slut levereras till kunden. I v˚ar grupp (grupp 5) st¨otte vi snabbt p˚a hinder vid v˚ar kontakt med best¨allaren. Det visade sig vara sv˚arare ¨an vad vi trott att specificera best¨allarens behov till n˚agot konkret. Detta dels f¨or att best¨allaren inte var s¨aker p˚a exakt vad den ville f˚a ut av produkten samt att vi i gruppen var oerfarna av att sortera ut krav ur det som diskuterades p˚a m¨oten med best¨allaren. Efter dessa erfarenheter har nyfikenhet v¨ackts om hur kontakt med best¨allare och kund fungerat f¨or ¨ovriga grupper i projektet. D¨arf¨or har det valts att unders¨oka detta n¨armare.
A.3 Teori
H¨ar f¨oljer en kort beskrivning av n˚agra begrepp som tas upp i rap-porten.
Best¨allare/kund
Best¨allare ¨ar den part i projektet som best¨allt produkten av pro-duktgruppen, i detta projekt ¨ar det ¨aven best¨allaren som varit kund och dessa kommer d¨arf¨or att anv¨andas synonymt i rapporten. Slack
Popul¨ar n¨attj¨anst f¨or gruppkommunikation vid projekt med m¨ojlighet att skapa olika kanaler f¨or olika delar av gruppen eller f¨or olika sam-tals¨amnen. [42]
Google Hangouts
N¨attj¨anst f¨or videokonferenser och text-medelanden. [23] Skype
A.4 Metod
Kundkontakt har varit en stor del av projektet och under projek-tet har en del erfarenheter samlats fr˚an hur v˚ar projektgrupp upp-levt kundkontakten. Dessa erfarenheter kommer att unders¨okas och j¨amf¨oras med erfarenheter fr˚an andra grupper. Erfarenheterna har samlats in l¨opande under projektet fr˚an kommentarer och diskus-sioner under gruppm¨oten.
F¨or att samla mer erfarenheter fr˚an ¨ovriga deltagare i projektet har en enk¨atunders¨okning genomf¨orts (se kapitel A.5.2). Enk¨aten bestod av fem fr˚agor ang˚aende kundkontakt som besvarades p˚a en skala 1-5. Ut¨over dessa fanns det tre extra fr˚agor d¨ar respondenten hade m¨ojlighet att ge mer utf¨orliga svar.
A.5 Resultat
I detta kapitel presenteras resultatet fr˚an den enk¨atunders¨okning om genomf¨orts och de erfarenheter som samlats in fr˚an gruppen under projektets g˚ang.
A.5.1 Samlade erfarenheter
Under projektets g˚ang har v˚ar grupp l¨art oss mycket om kundkon-takt och vad som kan g˚a fel och vara sv˚art n¨ar man kommunicerar med kunden. H¨ar f¨oljer n˚agra av de erfarenheter vi samlat in under projektet.
Ett tidigt problem som uppstod var att det inte var speciellt tyd-ligt vad kunden faktiskt ville f˚a ut av produkten vi skulle utveckla. De hade m˚anga id´eer som var v¨aldigt spridda och som inte alltid fungerade tillsammans. Vissa id´eer gick inte att f¨orverkliga alls d˚a data som skulle beh¨ovas inte fanns. Detta ledde till att vi i b¨orjan av projektet beh¨ovde l¨agga mycket tid till att tillsammans med kun-den gallra bland id´eerna f¨or att sedan g¨ora om dem till krav i en kravspecifikation.
Vi hade under projektet kontakt med m˚anga olika personer fr˚an kundens sida. Personerna kom fr˚an flera olika avdelningar och var olika v¨al insatta i projektet. De hade alla skilda uppfattning av vad
produktens syfte var och vad den skulle best˚a av.
A.5.2 Enk¨atunders¨okning
Nedan f¨oljer en sammanfattning av svaren fr˚an den enk¨atunders¨okning som genomf¨orts f¨or att unders¨oka hur kundkontakten fungerat f¨or medlemmar i andra projektgrupper i TDDD96 VT17. Totalt svara-de 33 personer p˚a enk¨aten.
Hade er kund tydliga krav p˚a produkten innan projektstart: Denna fr˚aga besvarades p˚a en skala 1-5 d¨ar 1 var ”Kunden hade inga specifika krav” och 5 ”Kunden hade mycket tydliga krav”. Som kan ses i figur 6 ¨ar svaren p˚a denna fr˚aga spridda men st¨orre delen av svaren ligger centrerade runt 3 med n˚agra fler svar ˚at de h¨ogre svars-alternativen. Det ser ut som att krav fr˚an kunden har existerat fr˚an kunden f¨or majoriteten av respondenterna men de har inte alltid varit speciellt tydligt formulerade.
Hur l¨att har det varit att komma i kontakt med er kund under projektet: Denna fr˚aga besvarades p˚a en skala 1-5 d¨ar 1 var ”V¨aldigt sv˚art” och 5 ”Mycket l¨att”. Enligt svaren, som kan ses i figur 7, tycks det har varit ganska till mycket l¨att f¨or de flesta av respondenterna att f˚a kontakt med sin kund under projektet.
Hur tydliga har instruktionerna fr˚an kunden varit under projektet: Denna fr˚aga besvarades p˚a en skala 1-5 d¨ar 1 var ”V¨aldigt otydliga” och 5 ”mycket tydliga”. Denna fr˚aga har besvarats mer ne-gativt, med majoriteten av svaren mellan 1 och 3, se figur 8. Det verkar allts˚a som att instruktionerna fr˚an kunden har upplevts gans-ka otydliga f¨or m˚anga respondenter.
Hur v¨al st¨amde projektet med den information som gavs i projektbeskrivningen: Denna fr˚aga besvarades p˚a en skala 1-5 d¨ar 1 var ”st¨amde inte alls” och 5 ”st¨amde helt”, se figur 9. Svaren p˚a denna fr˚aga ¨ar v¨aldigt spridda och det verkar som att kvaliteten p˚a informationen i projektbeskrivningarna har skiljt sig mycket fr˚an projekt till projekt.
Hur v¨al skulle du s¨aga att er kundkontakt fungerat under projektet: Denna fr˚aga besvarades p˚a en skala 1-5 d¨ar 1 var ”inte bra alls” och 5 ”mycket bra”. St¨orre delen av respondenterna ver-kar vara n¨ojda, eller ˚atminstone inte missn¨ojda, med kundkontakten under projektet, se figur 10.
Figur 10: Stapeldiagram ¨over insamlade svar p˚a femte fr˚agan.
Hur har ni i er grupp kommunicerat med er kund: Majo-riteten av respondenterna svarade att de anv¨ande e-post som den huvudsakliga kommunikationsv¨agen f¨or st¨orre fr˚agor och f¨or att pla-nera m¨oten. N¨ar fysiska m¨oten inte var m¨ojliga h¨olls de ist¨allet ¨
over video-/ljud-l¨ank via Skype. F¨or mindre fr˚agor eller l¨attare prat anv¨andes meddelande-tj¨anster s˚a som Slack och Google Hangouts Har du n˚agon ny erfarenhet g¨allande kundkontakt som du kommer att ta med dig fr˚an det h¨ar projektet: Denna fr˚aga gav m˚anga bra svar som kan hj¨alpa vid framtida projekt. N˚agot som togs upp av flertalet av respondenterna var vikten av att vara tydlig i kommunikationen med kunden. Det blir l¨att missf¨orst˚and vilket kan leda till att kunden och projektgruppen f˚ar olika uppfattningar om vad som best¨amts p˚a m¨oten eller via e-post. Det framgick ocks˚a att det var viktigt att h˚alla regelbunden kontakt med kunden och inte l˚ata det g˚a f¨or l˚ang tid mellan uppdateringar om framsteg. En annan sak som togs upp var att det var viktigt att b˚ade kunden vet,
och ¨ar ¨overens om, exakt vilka krav som finns i kravspecifikationen. Har du n˚agot ¨ovrigt du vill meddela ang˚aende kundkon-takt: Svaren p˚a denna fr˚aga hade inget att till¨agga som inte tagits upp i f¨oreg˚aende fr˚aga.
A.6 Diskussion
I detta kapitel diskuteras resultatet och de metoder som anv¨ants i unders¨okningen.
A.6.1 Resultatet
Fr˚an de erfarenheter jag samlat under projektets g˚ang s˚a ser jag nu vikten av att tidigt f˚a bra kontakt med kunden. Kunden kanske inte alltid sj¨alv vet vad de faktiskt vill ha och d˚a g¨aller det att till-sammans med kunden f¨ors¨oka f˚anga upp deras id´eer f¨or att kunna forma dem till en f¨ardig produkt. En metod f¨or att avhj¨alpa detta problem ¨ar att f¨ors¨oka ta fram prototyper redan innan kravspecifica-tionen ¨ar f¨ardigst¨alld. Prototyperna bygger p˚a de id´eer som kunden har och anv¨ands sedan f¨or att ta fram en riktig kravspecifikation f¨or en f¨ardig produkt. Det g¨aller dock att vara f¨orsiktig s˚a att man inte skapar en prototyp som leder bort fr˚an kundens faktiska behov, en prototyp som kanske ser bra ut men egentligen inte uppfyller det som kunden vill ha. [1]
Svaren p˚a enk¨aten gav en del insikter i hur kundkontakten funge-rat f¨or de andra projektgrupperna. Det tycks inte varit n˚agra st¨orre problem f¨or grupperna att f˚a kontakt med sina kunder under pro-jektet men d¨aremot tycks instruktionerna de f˚att fr˚an kunden varit n˚agot otydliga. En del hade ¨aven problem med att projektbeskriv-ningen inte st¨amde med projektet de till slut genomf¨orde. Vikten av att ha regelbunden kontakt med kunden och att alltid vara v¨aldigt tydlig i kommunikationen ¨ar n˚agot som tydligt framgick ifr˚an sva-ren. Detta ¨ar n˚agot jag verkligen h˚aller med om baserat p˚a mina egna erfarenheter. Ett bra s¨att f¨or att se till att kommunikationen med kunden g˚ar s˚a smidigt som m¨ojligt ¨ar att s¨atta upp en ordent-lig kommunikationskanal. Tj¨anster som Slack, Google Hangouts och Skype ¨ar exempel p˚a kanaler som fungerat bra f¨or grupper i det h¨ar projekten.
A.6.2 Metoden
Enk¨atunders¨okningen besvarades av ca 30% av kursens deltagare. Detta g¨or s˚a klart att svaren inte kan ses som helt representativa av alla deltagares erfarenheter. D¨aremot kan det antas att ˚atminstone en representant fr˚an varje grupp, eller i alla fall fr˚an majoriteten av grupperna, svarat p˚a enk¨aten. Den l˚aga svarsfrekvensen berodde nog till stor del p˚a den korta svarstid som respondenterna hade. Detta hade kunnat l¨osas genom att enk¨aten skickats ut tidigare f¨or att ge mer tid ˚at respondenterna att svara. F¨or att kontrollera fr˚an vilka grupper svaren kom ifr˚an borde detta varit en fr˚aga p˚a enk¨aten. Det hade d˚a varit l¨attare att se om svaren var representativa f¨or samtliga grupper.
A.7 Slutsatser
Nedan tas de slutsatser som kan dras av unders¨okningen upp f¨or de fr˚agest¨allningar som beskrevs i avsnitt A.1.2.
1. De erfarenheter som samlats ang˚aende kundkontakt ¨ar framf¨orallt hur viktigt det ¨ar att vara tydlig med kunden s˚a att missf¨orst˚and inte uppst˚ar. Om det ¨ar m˚anga personer inblandade fr˚an kun-dens sida ¨ar det viktigt att information g˚ar ut till alla s˚a att alla inblandade ¨ar ¨overens om kraven p˚a produkten och dess m˚al. Det ¨ar ocks˚a bra att projektgruppen tidigt sj¨alva kommer med f¨orslag och prototyper om kunden inte ¨ar helt s¨akra p˚a vad det ¨ar de vill ha.
2. Kundkontakten har fungerat ganska bra f¨or ˚arets projektgrup-per, det har varit l¨att att f˚a kontakt med sin kund. D¨aremot har en del av de projektbeskrivningar som gavs innan projektstart inte alltid st¨amt med hur det slutgiltiga projektet s˚ag ut. Dess-utom har instruktionerna fr˚an kunden under projektet till viss del varit otydliga.
Kundkontakt ¨ar inte alltid l¨att men genom att l¨ara sig av sina miss-tag och ta med sig samlade erfarenheter till n¨asta projekt har man snart den delen av projektet som i en ask.
B
Peter Arvidsson - Visualisering i D3.js
Detta kapitel behandlar den individuella delen av kandidatrapporten skriven av projektgruppens arkitekt.
B.1 Inledning
Vanligt f¨orekommande i mjukvaruprojekt ¨ar att representera och visualiera data som beskriver en produkts inneh˚all. Dessa visuali-seringar ¨ar ofta vad som f˚ar anv¨andaren att f¨orst˚a produkten och skapa en viss uppfattning om dess information. F¨or detta ¨andam˚al finns det m˚anga visualiseringsbibliotek f¨or att effektivt kunna ska-pa visualiseringar av data. Kapitlet innefattar anv¨andningen uti-fr˚an JavaScript-biblioteket D3.js och och dess syfte samt positiva anv¨andningsomr˚aden. D3 st˚ar f¨or Data-Driven Documents och ¨ar ett kraftfullt verktyg och bibliotek baserat p˚a JavaScript f¨or att grafiskt visualisera data p˚a ett enkelt och effektivt s¨att. I kapitlet j¨amf¨ors ¨aven andra mindre avancerade bibliotek f¨or att framh¨ava f¨orst˚aelsen f¨or vilken typ av bibliotek som passar arbetsg˚angen f¨or ett mjukvaruprojekt.
B.1.1 Syfte
Syftet med unders¨okningen ¨ar att unders¨oka f¨ordelarna D3.js har f¨or projektet gentemot liknande metoder f¨or visualisering av data. Gemensamt har alla visualiseringsbibliotek som huvudsyfte att un-derl¨atta visualisering av data i en smidig och l¨attl¨ast kodstruktur.
B.1.2 Fr˚agest¨allningar
1. D3.js ¨ar ett bland m˚anga liknande bibliotek. Hur skiljer sig D3.js fr˚an ¨ovriga och varf¨or har projektgruppen valt att anv¨anda just detta verktyg?
2. Vilket visualiseringsbibliotek b¨or man v¨alja f¨or att anpassa ef-ter sin erfarenhetsniv˚a och projekt?
B.2 Bakgrund
D3.js ¨ar ett kraftfullt och p˚alitligt verktyg som konstant utveck-las och f¨orb¨attras med nya strukturer och optimeringar tack
va-re dess open source-modell. Eftersom D3.js har s˚a stora och breda m¨ojligheter trots sin struktur och smidighet, kan inl¨arningskurvan vara relativt brant - ¨aven f¨or n˚agon som redan har erfarenhet med JavaScript. Oavsett vad D3.js-anv¨andaren vill uppn˚a, ¨ar det mycket troligt att en mall f¨or visualiseringen redan finns klart p˚a ett eller annat s¨att, d¨aremot kr¨avs det djup f¨orst˚aelse f¨or att kunna modi-fiera mallen och f˚a nya funktioner eller strukturer att fungera ihop med varandra. D3.js anv¨ander ett JavaScript-bibliotek tillsammans med SVG, HTML5 och CSS f¨or den grafiska representationen. [41]
B.3 Teori
Som svar p˚a fr˚agan ”Vilka ¨ar de b¨asta JavaScript-biblioteken f¨or visualisering av data- rankas D3.js p˚a f¨orsta plats. [41] Eftersom D3.js fungerar s˚a bra tillsammans med andra webbteknologier som HTML, SVG och CSS och anv¨ander deras fulla potential, blir D3.js ett kraftfullt verktyg f¨or utvecklare.
Gemensamt med liknande visualiseringsverktyg ¨ar att det utnytt-jas p˚a klientsidan av applikationen, medan serversidan genererar n¨odv¨andiga data f¨or visualiseringen. Till skillnad fr˚an andra visua-liseringsverktyg anv¨ander D3.js en funktionell stil vilket inneb¨ar att kodsekvenser enkelt kan ˚ateranv¨andas och nya funktioner l¨aggas till i det ursprungliga inneh˚allet f¨or exempelvis v¨alutvecklade mallar. Det f¨oljer en stabil struktur samtidigt som utvecklaren ¨ar fri att ¨
andra stil, g¨ora egna funktioner och s¨att att interagera med data. [18]
D3.js har en stark och p˚alitlig anv¨andargrupp med m˚anga exem-pel f¨or alla t¨ankbara datavisualiseringar d¨ar de flesta ¨ar gjorda av verktygets f¨orfattare. K¨allkoden ¨ar tillg¨anglig f¨or alla, vilket inneb¨ar att vem som helst har tillg˚ang till k¨allkoden med m˚al att utveck-la verktyget vidare, d¨arf¨or finns det ¨aven m˚anga anv¨andargjorda visualiseringar presenterade f¨or biblioteket att ta del av.
B.4 Metod
Unders¨okningen har utf¨orts med hj¨alp av en onlinestudie om j¨amf¨orelse mellan olika visualiseringsverktyg d¨ar anv¨andare uttrycker sig om upplevelsen samt f¨ordelarna och nackdelarna med dessa. Dessutom
har egen anv¨andning och testning av tre v¨alk¨anda bibliotek - D3.js, C3.js och Google Charts gjorts, vars skillnader och f¨ordelar noterats f¨or respektive verktyg. Detta f¨or att f˚a en mer praktisk f¨orst˚aelse f¨or och uppfattning av visualiseringsverktyg.
B.5 Resultat
I resultatet presenteras ett exempel f¨or de ovan n¨amnda bibliote-ken , alla baserade p˚a enkla cirkeldiagram. Respektive bibliotek utv¨arderas med dess f¨ordelar och nackdelar tillsammans med ko-den samt n¨ar dessa b¨or anv¨andas. Onlinestudien tas samtidigt till h¨ansyn och de punkter som v¨ager in mest po¨angteras.
B.5.1 Utv¨ardering av biblioteken och dess inbyggda funktioner
Som del av unders¨okningen gjordes ett enkelt cirkeldiagram med hj¨alp av respektive bibliotek med s˚a f˚a funktioner och l˚ag komplex-itet som m¨ojligt. M˚alet var att se och f¨orst˚a de st¨orre skillnaderna och anv¨andningen.
B.5.2 Google Chart
Enklast och snabbast gjordes diagrammet i Google Charts vilket anv¨ander sig av ett f¨orbest¨amt dataformat: ’arrayToDataTable’ och en diagramtyp ’PieChart’ f¨or att till sist rita ut diagrammet med den inf¨orda data som parameter presenterat nedan. Av koden l¨amnas inte mycket kvar till egen utveckling och modifiering. Stildokumen-ten tillh¨or ’google.visualization’ -paketet och animationerna ¨ar redan implementerade. Sj¨alvklart g˚ar det att skriva ¨over de funktioner som finns f¨or att uppn˚a sitt ¨onskade utseende och beteende, men Google Charts ¨ar inte optimalt f¨or det ¨andam˚alet. Enkelheten lig-ger i fokus f¨or biblioteket och anv¨andaren kan snabbt implementera v¨aldesignade visualiseringar utan anstr¨angning.
Figur 11: Enkelt cirkeldiagram byggt i Google Charts f u n c t i o n d r a w C h a r t () { var d a t a = g o o g l e . v i s u a l i z a t i o n . a r r a y T o D a t a T a b l e ([ [’ D a t a T a s k ’, ’ eg . H o u r s per Day ’] , [’ D a t a 1 ’, 3] , [’ D a t a 2 ’, 2] , [’ D a t a 3 ’, 2] ]) ; var c h a r t = new g o o g l e . v i s u a l i z a t i o n . P i e C h a r t ( d o c u m e n t . g e t E l e m e n t B y I d (’ p i e c h a r t ’) ) ; c h a r t . d r a w ( d a t a ) ; }
Kodexempel 1: Google Chart
B.5.3 C3.js
C3.js ¨ar baserat p˚a D3.js p˚a s˚a vis att det packar in koden som kr¨avs f¨or att konstruera hela diagrammet. Resultatet blir att stora delar av D3.js-koden inte beh¨over skrivas, utan blir ist¨allet inbyggd i det nya bibliotekets funktioner. Exempelvis implementeras all SVG och det grafiska i type = ’pie’. Nackdelen med detta ur ett utvecklings-perspektiv ¨ar att friheten f¨or enkel modifiering f¨orsvinner.
Verktyget ¨ar utm¨arkt f¨or att komplettera en redan skapad visualise-ring i D3.js. Utan att blanda in andra bibliotek eller skriva en on¨odig m¨angd kod f¨or en kompletterande graf, kan C3.js smidigt anv¨andas f¨or att ˚astadkomma detta.
var c h a r t = c3 . g e n e r a t e ({ d a t a : { c o l u m n s : [ [’ d a t a 1 ’, 30] , [’ d a t a 2 ’, 120] , ] ,
Figur 12: Enkelt cirkeldiagram byggt i C3.js t y p e : ’ pie ’, o n c l i c k : f u n c t i o n ( d , i ) { c o n s o l e . log (" o n c l i c k ", d , i ) ; } , o n m o u s e o v e r : f u n c t i o n ( d , i ) { c o n s o l e . log (" o n m o u s e o v e r ", d , i ) ; } , o n m o u s e o u t : f u n c t i o n ( d , i ) { c o n s o l e . log (" o n m o u s e o u t ", d , i ) ; } } }) ; s e t T i m e o u t (f u n c t i o n () { c h a r t . l o a d ({ c o l u m n s : [ [" s e t o s a ", 0.2] , [" v e r s i c o l o r ", 1.4] , [" v i r g i n i c a ", 2.5] , ] }) ; } , 1 5 0 0 ) ; s e t T i m e o u t (f u n c t i o n () { c h a r t . u n l o a d ({ ids : ’ d a t a 1 ’ }) ; c h a r t . u n l o a d ({ ids : ’ d a t a 2 ’ }) ; } , 2 5 0 0 ) ; Kodexempel 2: C3.js B.5.4 D3.js
D˚a anv¨andaren av D3.js har m¨ojlighet att skapa exakt sitt ¨onskade utseende p˚a diagrammet, resulterar det ofta i att geometrin f¨or grafer och f¨ordelningar m˚aste h˚allas i tanke till skillnad fr˚an de ovan n¨amnda biblioteken. All stilkodning g¨ors separat och med sm˚a
f¨or¨andringar i koden kan stora variationer av diagrammet skapas.
var svg = d3 . s e l e c t (" svg ") , w i d t h = + svg . a t t r (" w i d t h ") , h e i g h t = + svg . a t t r (" h e i g h t ") , r a d i u s = M a t h . min ( width , h e i g h t ) / 2 , g = svg . a p p e n d (" g ") . a t t r (" t r a n s f o r m ", " t r a n s l a t e ( " + w i d t h / 2 + " , " + h e i g h t / 2 + " ) ") ; var c o l o r = d3 . s c a l e O r d i n a l ([" #98 a b c 5 ", " #8 a 8 9 a 6 ", " #7 b 6 8 8 8 ", " #6 b 4 8 6 b ", " # a 0 5 d 5 6 ", " # d 0 7 4 3 c ", " # f f 8 c 0 0 "]) ;
var pie = d3 . pie () . s o r t (n u l l) . v a l u e (f u n c t i o n( d ) { r e t u r n d . p o p u l a t i o n ; }) ; var p a t h = d3 . arc () . o u t e r R a d i u s ( r a d i u s - 10) . i n n e r R a d i u s (0) ; var l a b e l = d3 . arc () . o u t e r R a d i u s ( r a d i u s - 40) . i n n e r R a d i u s ( r a d i u s - 40) ; d3 . csv (" d a t a . csv ", f u n c t i o n( d ) { d . p o p u l a t i o n = + d . p o p u l a t i o n ; r e t u r n d ; } , f u n c t i o n( error , d a t a ) { if ( e r r o r ) t h r o w e r r o r ;
var arc = g . s e l e c t A l l (" . arc ") . d a t a ( pie ( d a t a ) ) . e n t e r () . a p p e n d (" g ") . a t t r (" c l a s s ", " arc ") ; arc . a p p e n d (" p a t h ") . a t t r (" d ", p a t h ) . a t t r (" f i l l ", f u n c t i o n( d ) { r e t u r n c o l o r ( d . d a t a . age ) ; }) ; arc . a p p e n d (" t e x t ") . a t t r (" t r a n s f o r m ", f u n c t i o n( d ) { r e t u r n " t r a n s l a t e ( " + l a b e l . c e n t r o i d ( d ) + " ) "; }) . a t t r (" dy ", " 0 . 3 5 em ") . t e x t (f u n c t i o n( d ) { r e t u r n d . d a t a . age ; }) ; }) ; Kodexempel 3: D3.js
Den totala tiden f¨or upps¨attningen och inl¨arning skiljde sig stort mellan de olika biblioteken. F¨or Google Charts kr¨avdes n¨astan inte n˚agon inl¨arning ¨overhuvudtaget. Stegen f¨or upps¨attningen var att s¨atta diagramtyp och datatyp baserat p˚a det inbyggda paketet.
Diagrammet i C3.js var steget kr˚angligare d˚a utrymme f¨or en del inst¨allningar fanns tillg¨angligt baserat p˚a D3.js. Som st¨orst skiljde sig D3.js fr˚an de ¨ovriga med en betydligt l¨angre tid f¨or att fr˚an grunden bygga upp ett enkelt cirkeldiagram med tillh¨orande data. Vid anv¨andning av stora m¨angder data presterar ¨aven biblioteken olika. Google Charts i och med alla sina redan inbyggda animatio-ner och grafik, blir l˚angsammare ¨an C3.js och D3.js ju mer data som beh¨over l¨asas in. [19]
B.6 Diskussion
D3.js ¨ar s˚a popul¨art p˚a grund av den smidiga l¨osningen till att f˚a fram en egen visualisering fr˚an grunden eller med hj¨alp av klara mallar, och samtidigt ha friheten att kunna modifiera alla t¨ankbara detaljer utan att g˚a ifr˚an den eleganta strukturen. Till skillnad fr˚an andra visualiseringsverktyg ¨ar inl¨arningskurvan d¨aremot be-tydligt brantare. F¨orutom friheten att bygga upp den visualisering anv¨andaren haft i tanke ger D3.js en robust och kvalitativ prestan-da samt stor variation p˚a implementationer av datatyper. Dessa kan l¨asas in som JSON, XML eller CVS medan flera andra verktyg byg-ger p˚a data-tabeller eller listor f¨or enkelheten. [19]
Ett m˚al som flera andra visualiseringsverktyg som exempelvis Goog-le Charts har ¨ar att f¨orenkla och f¨orminska kodm¨angden till det minsta m¨ojliga men samtidigt till ett imponerande resultat. I dessa bibliotek kr¨avs knappt n˚agon tidigare erfarenhet och en anv¨andare kan p˚a kort tid f˚a fram diverse grafer och visualiseringar med ¨onskat data.
B.6.1 Andam˚¨ al f¨or visualiseringsverktyg
Enklare verktyg ¨ar bra f¨or n˚agon mer oerfaren och f¨or att snabbt f˚a fram en snygg visualisering. D¨aremot m˚aste anv¨andaren anv¨anda sig av verktygets exempel och regler som ¨ar v¨aldigt l˚asta till sitt utseende p˚a grund av den enkla strukturen. En ¨andring i utseendet, funktionaliteten eller beteendet skulle kr¨ava en omskrivning av de redan klara strukturena. D¨armed ¨ar dessa verktyg inte riktade till n˚agon som vill utveckla sin egna visualisering fr˚an grunden.
En erfaren utvecklare vill oftast kunna modifiera och skapa nya funktioner och beteenden utifr˚an ett bibliotek eller verktyg. D3.js ger fullt ut precis denna m¨ojlighet.
B.7 Slutsatser
F¨or att sammanfatta syftet med den individuella rapporten s˚a un-ders¨oktes f¨ordelarna med visualiseringsbiblioteket D3.js i koppling till projektet j¨amf¨ort med andra liknande verktyg som Google Charts och C3.js. Dessutom beskrivs vid vilka anv¨andningsomr˚aden och kunskapsniv˚aer respektive bibliotek passar b¨ast.
1. Genom att unders¨oka mallar f¨or olika grafer och visualiering-ar f¨or de olika biblioteken, visar det sig att D3.js knappt har n˚agra enkla grafer likt Google Charts eller C3.js, utan allt har en viss dynamik och variation i det hela. Detta p˚avisar att det helt enkelt inte ¨ar v¨art att s¨atta sig in i ett mer komplext vi-sualiseringsbibliotek om anv¨andaren inte t¨ankt utveckla n˚agot vidare.
2. F¨or ¨andam˚alet i detta projekt var D3.js ett sj¨alvklart val, trots sin skarpa inl¨arningskurva. Verktyget gav m¨ojligheten att fr˚an grunden skapa de visualiseringar som fr˚an b¨orjan fanns som pappersprototyper f¨or projektet. D3.js tillsammans med C3.js presterar ¨aven mycket b¨attre vid st¨orre m¨angder data j¨amf¨ort med Google Charts. I projektet har C3.js anv¨ands f¨or att kom-plettera visualiseringarna med mindre viktiga diagram d¨ar fo-kus inte riktas.
Alla bibliotek har sina f¨ordelar och passar en viss anv¨andarbas b¨attre ¨an den andra. Med studien f¨orv¨antas den oerfarna l¨asaren f¨orst˚a vad visualiseringsverktyg inneb¨ar och att det finns vari-erande bibliotek med olika m˚als¨attningar och f¨ordelar.
C
Victor Bennich - Testa ett API med Mocha
Detta kapitel behandlar gruppens testansvariges individuella bidrag till kandidatrapporten. Inledningsvis beskrivs kortfattat vad bidra-get behandlar f¨oljt av syftet med bidraget, fr˚agest¨allningen och teori. Slutligen ges resultatet f¨oljt av en diskussion samt slutsatser.C.1 Inledning
Under ett st¨orre mjukvaruprojekts livstid s˚a ¨ar det l¨att f¨or program-merarna och de ansvariga att skriva m¨angder med funktionalitet ut-an att iblut-and t¨anka p˚a helheten och om ens koden fungerar fullt ut. F¨or att ˚atg¨arda detta s˚a ¨ar det mer regel ¨an undantag i f¨oretag att ha en testavdelning som kontinuerligt testar produkten och all ny funktionalitet. Detta f˚angar upp om en ny modul inte ¨ar kompati-bel med en ¨aldre modul och om utvecklarna verkligen t¨ankt igenom alla scenarion programvaran kan uts¨attas f¨or. En viktig del av en testares arbete ¨ar att utveckla och kontinuerligt uppdatera automa-tiska tester mot produkten. Det finns or¨akneligt m˚anga olika verktyg och metoder att skriva dessa tester i, men i detta avsnitt ska det behandlas hur man bygger ett ramverk f¨or automatiska tester med hj¨alp av verktyget Mocha, en modul till Node.js som ¨ar skriven i JavaScript. [20] En studie av f¨ordelar av automatiska tester gente-mot manuella tester har genomf¨orts och resultaten pekar p˚a att om en webbapplikation som f¨oruts¨atts ha l˚ang livl¨angd och kommer vi-dareutvecklas b¨or det finnas en upps¨attning automatiska testfall f¨or att utf¨ora regressionstester under utvecklingens g˚ang.
C.1.1 Syfte
Syftet med detta kapitel ¨ar att peka p˚a f¨ordelarna och nackdelarna med att anv¨anda Mocha och automatiska tester ¨overlag, samt att ge en ¨overblick ¨over hur man bygger ett komplett ramverk av tester f¨or en applikation och de b¨asta v¨agarna f¨or att strukturera det. Efter att ha l¨ast detta kapitel ska det inte vara sv˚art f¨or en utvecklare att f¨orst˚a vinsterna med automatiska tester och komma ig˚ang att skriva sina f¨orsta tester med hj¨alp av Mocha till sin webbapplikation.
C.1.2 Fr˚agest¨allningar
Faktorer som f¨or¨andrad milj¨o, programspr˚ak och infrastruktur kan p˚averka hur mycket resurser som m˚aste l¨aggas ned p˚a underh˚allet av tester vilket leder till att resurserna f¨or utveckling av produkten blir mindre. Det som unders¨oks ¨ar skillnaden i resurser (tid) som skil-jer automatiska tester fr˚an manuella tester f¨or kandidatprojektets REST-API.
1. ¨Ar v¨art att investera signifikanta resurser och tid f¨or att bygga automatiska tester?
2. Hur effektiva ¨ar automatiska tester p˚a att peka ut och tidigt f˚anga upp fel under utvecklingen av en applikation?
C.2 Bakgrund
Mocha ¨ar ett testverktyg i JavaScript som k¨ors med hj¨alp av No-de.js. [33] Tester k¨ors asynkront, det vill s¨aga att ett test inte m˚aste avslutas innan n¨asta test kan p˚ab¨orjas. Mocha ¨ar fr¨amst annpassat till att testa webbtj¨anster och syftet med Mocha ¨ar att det ska vara enkelt och roligt att skriva tester till en applikation. Projektgrup-pen har med hj¨alp av testledaren best¨amt att Mocha ¨ar det b¨ast l¨ampade verktyget f¨or ett inte s˚a omfattande projekt. Eftersom det kan ta hj¨alp av ett n¨astintill o¨andligt bibliotek av v¨alpr¨ovade mo-duler som kan hj¨alpa till att j¨amf¨ora data och hantera anslutningar s˚a minimeras den egna koden och testerna blir mer begripliga.
C.3 Teori
I denna sektion beskrivs hur ett ramverk f¨or testning byggs upp och hur denna testning skiljer sig fr˚an manuell testning.
F¨or att skapa ett testramverk i Mocha s˚a beh¨over man f¨orst lad-da hem Mocha via Node.js. St˚ar man i projektmappen och skriver: npm install mocha installeras Mocha i mappen node modules lo-kalt f¨or projektet, och versionen av mocha sparas i filen package.json. Package.json ¨ar en fil d¨ar detaljer kring ett projekt finns definiera-de. Allt fr˚an f¨orfattare i projektet, scripts, databasinst¨allningar och vilka externa moduler som anv¨ands. F¨or att effektivt f˚a ig˚ang pro-jektet i en annan milj¨o s˚a kan kommandot npm install k¨oras s˚a
