Digital Tvilling : Visualisering av personlig hälsodata

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Kandidatarbete på grundnivå, 15hp | Datateknik och mjukvaruteknik

2019 | LIU-IDA/LITH-EX-G--19/002--SE

Digital Tvilling

–

Visualisering av personlig hälsodata

Digital Twin

Teodor Ganestål

André Palmborg

Adrian Royo

William Stenberg

Olle Stenvall

Juliette Winneroth

Sami S. Yahya

Handledare : Jacob Lundberg Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Teodor Ganestål André Palmborg Adrian Royo William Stenberg Olle Stenvall Juliette Winneroth Sami S. Yahya

Sammanfattning

Detta projekt är givet som ett kandidatarbete i mjukvaruutveckling vid Linköpings universitet, i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Arbetet är utfört av en grupp tredjeårsstudenter på D- och U-programmen.

Projektet ges av forskargruppen för integrerad systembiologi på IMT LiU, som utveck-lar matematiska modeller av biologiska system. Dessa modeller kan användas för att förstå systemen bättre, eller som beslutsstöd inom farmakologi och vård. Forskargruppens fokus för tillfället är att sammankoppla modeller för olika delar av människokroppen till en hel-hetsbild som beskriver delsystemens samverkan.

Denna helhetsbild för en särskild individs hälsotillstånd kallas för en digital tvilling, för vilken detta projekt ämnar framställa ett användargränssnitt.

Användargränssnittet skall erbjuda grafer över hälsoparametrars förändring över tid, och användaren ska kunna ta fram olika sådana genom att interagera med gränssnittet.

Utöver framtagning av själva gränssnittet, skall en brygga mellan applikationen och kundens modeller tas fram. Detta har gjorts genom en version av programmet OpenCOR, vilket forskarna använder sig av, som exponerar ett API i Python. Detta API sammankopp-lat med en server kallas i projektet för motor.

Författarens tack

Vi skulle vilja tacka vår kund och forskargruppen för integrativ systembiologi på IMT vid LiU för deras intresse i det prototypprojekt som vi har utfört. Vi vill även tacka de läkare vi varit i kontakt med i våra användarstudier för deras insikter och erfarenheter inom svensk vård.

Ett särskilt tack går ut till Malin Eklund på kognitionsvetenskapsprogrammet för hennes hjälp att utforma en designprocess och tips kring användarstudier.

Innehåll

I

Gemensam del

1

2.2.1 Förbättringar inför detta projekt . . . 7

2.3 Kund . . . 8 3 Teori 9 3.1 Projektverktyg . . . 9 3.1.1 Trello . . . 9 3.1.2 Google Drive . . . 9 3.1.3 Slack . . . 9 3.1.4 Microsoft Teams . . . 10 3.1.5 Git . . . 10 3.1.6 LA_{TEX . . . 10} 3.2 Design . . . 10 3.2.1 Användarstudier . . . 11 3.2.2 Personor . . . 11 3.2.3 Designkoncept . . . 11 3.3 Implementationsverktyg . . . 11 3.3.1 Systemanatomi . . . 11 3.3.2 JavaScript . . . 11 3.3.3 Node.js . . . 12 3.3.4 React . . . 12 3.3.5 CSS . . . 12 3.3.6 JSS . . . 12 3.3.7 Python . . . 12 3.3.8 Pytest . . . 12 3.3.9 CellML . . . 12

3.3.10 OpenCOR . . . 13 4 Metod 14 4.1 Besvara frågeställningarna . . . 14 4.2 Förstudie . . . 14 4.2.1 Systemanatomi . . . 14 4.3 Designarbete . . . 15 4.3.1 Användarstudie . . . 15 4.3.2 Personor . . . 15

4.3.3 Skisser och koncept . . . 15

4.4 Systemimplementation . . . 16 4.4.1 Systemöversikt . . . 16 4.4.2 Frontend . . . 16 4.4.3 Victory . . . 16 4.4.4 Fetch . . . 17 4.4.5 Backend . . . 17 4.4.6 Motor . . . 18 4.4.7 Databaser . . . 18 4.5 Insamling av data . . . 18

4.6 Metoder för att fånga erfarenheter . . . 19

4.6.1 Workshops . . . 19

4.6.2 Möten . . . 20

4.6.3 Veckoenkät och statusrapport . . . 20

4.6.4 Granskningar . . . 21 4.7 Arbetsmetodik . . . 21 4.7.1 Samarbete . . . 21 4.7.2 Kommunikation . . . 21 4.7.3 Implementation . . . 22 4.8 Testningsarbete . . . 22 5 Resultat 23 5.1 Dokumentöversikt . . . 23 5.1.1 Arkitekturdokument . . . 23 5.1.2 Kravspecifikation . . . 23 5.1.3 Kvalitetsplan . . . 24 5.1.4 Projektplan . . . 24 5.1.5 Testplan . . . 24 5.1.6 Testrapporter . . . 24 5.1.7 Driftmanual . . . 24 5.2 Systemanatomi . . . 24 5.3 Systemöversikt . . . 26 5.4 Frontend . . . 28 5.4.1 React . . . 29 5.4.2 Fetch . . . 30 5.5 Backend . . . 30 5.6 Motor . . . 31 5.7 Databaser . . . 31 5.8 Designarbete . . . 33 5.9 Gemensamma erfarenheter . . . 34 5.9.1 Kundkontakt . . . 34 5.9.2 Hantering av OpenCOR . . . 35

5.10 Översikt av individuella bidrag . . . 36 6 Diskussion 37 6.1 Resultat . . . 37 6.2 Metod . . . 39 6.2.1 Förstudie . . . 39 6.2.2 Designarbetes metod . . . 39

6.2.3 Metoder för att fånga erfarenheter . . . 40

6.2.4 Arbetsmetodik . . . 40

6.3 Svårigheter . . . 41

6.3.1 Källkritik . . . 42

6.4 Arbetet i ett vidare sammanhang . . . 42

6.4.1 Applikationssäkerhet . . . 42

6.4.2 Samhällsaspekter . . . 43

7 Slutsatser 44 7.1 Hur kan systemet implementeras så att värde skapas för kunden? . . . 44

7.2 Vilka erfarenheter kan dokumenteras från gruppens projekt som kan vara in-tressanta för framtida projekt? . . . 45

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 45

7.4 Hur kan ett användarvänligt användargränssnitt tas fram? . . . 45

II Individuella delar

46

A.3.3 Net Promoter Score . . . 48

A.3.4 System Usability Scale . . . 48

A.4 Metod . . . 51 A.4.1 Datainsamling . . . 51 A.4.2 SUS-mätning . . . 51 A.5 Resultat . . . 53 A.5.1 SUS-mätning . . . 53 A.6 Diskussion . . . 54 A.6.1 Metod . . . 54 A.6.2 Resultat . . . 56 A.7 Slutsatser . . . 56

A.7.1 Vad är SUS, och hur kan det användas för att mäta ett systems använ-darvänlighet? . . . 56

A.7.2 Blev projektgruppens slutprodukt användarvänlig? . . . 57

B Att säkerställa integrationen av tredjeparts beroende av André Palmborg 58 B.1 Inledning . . . 58

B.1.1 Syfte . . . 58

B.1.2 Frågeställning . . . 59

B.2 Bakgrund . . . 59

B.3.1 Testobjekt . . . 59 B.3.2 Ekvivalensklasser . . . 59 B.3.3 Uttömmande testning . . . 60 B.4 Metod . . . 60 B.4.1 Litteratursökning . . . 60 B.5 Resultat . . . 61

B.5.1 Arbetsätt och testmetoder . . . 61

B.5.2 Problem ur projektarbetet . . . 62

B.6 Diskussion . . . 63

B.6.1 Hypotetiskt arbete med “All Pairs”-testning . . . 63

B.6.2 Nackdelar och kompromisser . . . 64

B.7 Slutsatser . . . 64

B.7.1 Vilka arbetssätt är lämpade för att arbeta med black-box testobjekt? . . . 64

C Att designa med människan i centrum av William Stenberg 65 C.1 Inledning . . . 65 C.1.1 Syfte . . . 65 C.1.2 Frågeställning . . . 65 C.2 Bakgrund . . . 66 C.3 Teori . . . 66 C.3.1 Konceptfasen . . . 66 C.3.2 Bearbetningsfasen . . . 68 C.3.3 Detaljeringsfasen . . . 69 C.4 Metod . . . 69

C.4.1 Planering och uppstart . . . 69

C.4.2 Användarstudier och personor . . . 69

C.4.3 Koncept: generering och värdering . . . 70

C.5 Resultat . . . 70 C.5.1 Användarstudie . . . 70 C.5.2 Koncept . . . 71 C.5.3 Förändringar av grundkonceptet . . . 74 C.6 Diskussion . . . 75 C.6.1 Användarstudie . . . 75 C.6.2 Uteblivna prototyper . . . 76

C.6.3 Projektgruppens förutsättningar för designarbete . . . 76

C.7 Slutsatser . . . 76

C.7.1 Hur är Mattias Arvolas modell för interaktionsdesign utformad, och hur kan den användas för att utveckla en webbapplikation? . . . 76

C.7.2 Hur kan gruppens resultat i designarbetet med produkten relateras till denna process? . . . 76

C.7.3 Vilka avvikelser från metoden har gjorts i projektet? . . . 77

D Skalbar mjukvara - hur det utvecklas i ett småskaligt projekt av Olle Stenvall 78 D.1 Inledning . . . 78 D.1.1 Syfte . . . 78 D.1.2 Frågeställningar . . . 78 D.2 Bakgrund . . . 79 D.3 Teori . . . 79 D.3.1 Skalbarhet . . . 79 D.3.2 Uppskalning av hårdvara . . . 79 D.3.3 Docker . . . 80

D.4.1 Litteraturundersökning . . . 80

D.4.2 Mätning av skalbarhet . . . 81

D.4.3 Metod för att besvara, hur kan man utveckla skalbar mjukvara i ett små-skaligt projekt? . . . 84

D.5 Resultat . . . 84

D.5.1 Hur skalbar är produkten utvecklad till IMT LiU? . . . 84

D.5.2 Hur kan skalbarhet mätas? . . . 86

D.6 Diskussion . . . 86

D.6.1 Val av metrik . . . 86

D.6.2 Metod för att samla information . . . 87

D.6.3 Resultat av mätdata . . . 87

D.6.4 Resultat av undersökning om hur skalbar webbapplikation kan utveck-las i ett småskaligt mjukvaruprojekt . . . 87

D.7 Slutsatser . . . 88

D.7.1 Hur kan man utveckla en skalbar webbapplikation i ett småskaligt pro-jekt? . . . 88

D.7.2 Hur kan man mäta skalbarheten hos mjukvara och hur skalbar är pro-jekts slutprodukt enligt den metriken? . . . 88

D.8 Bilagor . . . 89

E Fördelar med Brainstorming av Sami S. Yahya 96 E.1 Inledning . . . 96 E.1.1 Syfte . . . 96 E.1.2 Frågeställning . . . 96 E.2 Bakgrund . . . 97 E.3 Teori . . . 97 E.3.1 Brainstorming . . . 97

E.3.2 Olika typer av brainstorming . . . 97

E.3.3 Trizmetoden . . . 99

E.3.4 Idéassociation . . . 100

E.4 Metod . . . 100

E.5 Resultat . . . 101

E.5.1 Brainstorming: så ska det användas . . . 102

E.5.2 Fördelar med Brainstorming . . . 102

E.5.3 Nackdelar med Brainstorming . . . 103

E.6 Diskussion . . . 103

E.6.1 Brainstorming i Digital Tvilling . . . 103

E.6.2 Brainstorming vs Trizmetod och Idéassociation . . . 103

E.7 Slutsatser . . . 104

E.7.1 Vilka för och nackdelar har brainstorming över trizmetoden, och idéas-sociation? . . . 104

E.7.2 Hur kan man utföra brainstorming på bästa sätt? . . . 104

E.7.3 Hur har vi använt brainstorming i projektet? . . . 105

F Undersökning av moderna webbutvecklingsspråk av Adrian Royo 106 F.1 Inledning . . . 106 F.1.1 Definitionslista . . . 106 F.1.2 Syfte . . . 106 F.1.3 Frågeställning . . . 107 F.2 Bakgrund . . . 107 F.3 Teori . . . 107

F.3.1 Bibliotek och ramverk . . . 107

F.3.3 Javascript . . . 107 F.3.4 TypeScript . . . 108 F.3.5 XML . . . 108 F.3.6 DOM . . . 108 F.3.7 HTML5+CSS3 . . . 108 F.3.8 React . . . 109 F.3.9 AngularJS . . . 109 F.3.10 Flask . . . 111 F.3.11 REST API . . . 111 F.4 Metod . . . 111 F.5 Resultat . . . 112 F.5.1 Inlärningskurva . . . 112 F.5.2 Jämförelse av egenskaper . . . 113

F.5.3 Hur väl anpassat är språken för Flask backend? . . . 115

F.6 Diskussion . . . 116

F.6.1 Webbutvecklingsverktygen . . . 116

F.6.2 Webbutvecklingsverktygen relativt Flask . . . 117

F.6.3 Partisk till React . . . 117

F.6.4 Informella källor . . . 117

F.7 Slutsatser . . . 117

F.7.1 Vilket webbverktyg är mest rimligt att lära sig samt använda sig av med tanke på kursens tidsbegränsning på 400 timmar per person? . . . 117

F.7.2 Vilka likheter samt olikheter har webbverktygen jämfört med resteran-de valda webbverktyg? . . . 118

F.7.3 Vilket webbverktyg fungerar bäst med Flask-backend för kandidatpro-jektet? . . . 118

G Fördelar med React i utvecklingen av en single-page applikation av Juliette Winneroth 119 G.1 Inledning . . . 119 G.1.1 Syfte . . . 119 G.1.2 Frågeställning . . . 119 G.2 Bakgrund . . . 119 G.3 Teori . . . 120 G.4 Metod . . . 121 G.5 Resultat . . . 122

G.5.1 Fördelar med React över Angular . . . 122

G.5.2 Nackdelar med React över Angular . . . 123

G.5.3 Inlärningskurva . . . 124

G.5.4 Arkitektur . . . 125

G.6 Diskussion . . . 127

G.6.1 Vilka fördelar och begränsningar har React gentemot Angular? . . . 127

G.6.2 Vilka fördelar kan React ge för en nybörjare gentemot Angular? . . . . 129

G.6.3 Hur kan man bygga arkitekturen för en single-page applikation med frontend i React? . . . 130

G.6.4 Felkällor och svårigheter . . . 131

G.7 Slutsatser . . . 132

G.7.1 Vilka fördelar och begränsningar har React gentemot Angular? . . . 132

G.7.2 Vilka fördelar kan React ge för en nybörjare gentemot Angular? . . . 132

G.7.3 Hur kan man bygga arkitekturen för en single-page applikation med frontend i React? . . . 132

Publicerade källor . . . 133 Elektroniska källor . . . 135 Interna källor . . . 142

Figurer

4.1 “Brush and Zoom”-graf som använts i projektet. . . 17

5.1 Systemets anatomi . . . 25

5.2 Implementation av systemet . . . 26

5.3 Användningsfall, första versionen . . . 27

5.4 Användningsfall, slutgiltig version . . . 28

5.5 Det färdiga användargränssnittet . . . 29

5.6 EER-diagram som beskriver databasernas struktur . . . 32

5.7 RM-diagram som beskriver databasernas tabeller . . . 33

5.8 Första skiss av användargränssnittet . . . 33

5.9 Datorskiss i Marvel App av användargränssnittet . . . 34

A.1 Relationen mellan SUS-poäng, percentiler, och betyg. Framtagen av Jeff Sauro och Jim Lewis. . . 50

A.2 Det Google Formulär som användes vid projektets SUS-mätning . . . 52

A.3 Svarsstatistiken från SUS-mätningen av projektgruppens slutprodukt . . . 54

C.1 Klisterlappar kategoriserade vid brainstorming . . . 71

C.2 Flera koncept skisserade på en whiteboardtavla . . . 72

C.3 En första datorskiss, återskapad efter handskisser . . . 74

C.4 Andra datorskiss som återger konceptet i stora drag . . . 74

D.1 Skärmdump av den kod som använts för att köra Locust tester mot backend. . . . 82

D.2 Skärmdump av kommandot som matas in i terminalen för att köra testerna defi-nerade i locust.py mot server angiven som host. . . 83

D.3 Skärmdump av webbgränssnittet som startas då man kör Locust, det som visas på bilden är hur inmatning sker av antal användare och “hatch rate”. . . 83

D.4 Skärmdump av graferna från Locust webbgränssnitt. Det vita vertikala strecket ovan markerar när servern inte kunde hantera fler användare. . . 85

D.5 Sammanställning av resultat från simulation med 100 användare och 5 i hatchrate. 86 D.6 Samtliga tester för 100 användare med hatchrate 20 visualiserade. . . 89

D.7 Samtliga tester för 300 användare med hatchrate 5 visualiserade. . . 90

D.8 Samtliga tester för 500 användare med hatchrate 25 visualiserade. . . 91

D.9 Median och medelvärde av värden från simulation med 100 användare och hatch-rate 5 visualiserade. . . 92

D.10 Median och medelvärde av värden från simulation med 100 användare och hatch-rate 20 visualiserade. . . 92

D.11 Median och medelvärde av värden från simulation med 100 användare och hatch-rate 50 visualiserade. . . 93 D.12 Median och medelvärde av värden från simulation med 300 användare och

D.13 Median och medelvärde av värden från simulation med 300 användare och

hatch-rate 5 visualiserade. . . 94

D.14 Median och medelvärde av värden från simulation med 500 användare och hatch-rate 25 visualiserade. . . 94

D.15 Median och medelvärde av värden från simulation med 500 användare och hatch-rate 25 visualiserade. . . 95

E.1 Resultat av en post-it brainstorming session . . . 98

E.2 “Tangible 3D primitives” . . . 98

E.3 Prisma för TRIZ . . . 99

E.4 En del av “Contradictions” matris av Genrich Altshuller . . . 100

F.1 Visualisering av jobbmöjligheter bland de topp 4 mest eftertraktade Javascript-verktyg. [JavaFigur] . . . 109

F.2 Visualisation av relationen mellan Controller, Scope och View. [CSV-Relation] . . 110

F.3 Ben Nadels graf av hur det var att lära sig AngularJS. [BN-Angular] . . . 113

G.1 Nerladdningar av React och Angular . . . 125

Tabeller

2.1 Projektgruppens medlemmar . . . 6 A.1 SUS-poäng och dess relation till olika utvärderingsmetoder . . . 51 A.2 Resultatet från SUS-mätningen, uppdelat i tre delar . . . 53

Definitioner

Definition av begrepp som ingår i projektet och används löpande i texten. • Applikation: Körbar kod, ett program som kan startas och avslutas.

• Agil utveckling: Ett flexibelt sätt att arbeta mot ett mål. Namnet kommer från engels-kans ”agile”, som betyder lättrörlig [1].

• CellML: XML-baserat språk, som används för att beskriva, lagra, och dela datorbasera-de matematiska modatorbasera-deller [2].

• Create React App: Ett verktyg byggt av Facebook för att underlätta byggnande av web-bapplikationer genom att undvika manuell installation och konfiguration [3].

• Delsystem: Organ eller annat system i kroppen som har modellerats i den digitala tvil-lingen, till exempel levern eller blodomloppet. Kan väljas bland av användaren för att se möjliga mätningar associerade med det.

• EER-diagram: EER står för enhanced entity-relationship. EER-diagram används i detta projekt för att beskriva strukturen på en databas [4].

• Flask: Open-source backendramverk för att skapa webbapplikationer i Python [5]. • JSON: Ett lätt datautbytesformat [6].

• Insats: Åtgärd eller aktion som användaren kan välja för att påverka modellen, till ex-empel måltid, träning, och medicin som då alltså appliceras till prediktionen av valda variabler.

• Marvel App: En applikation som används för att skapa göra prototyper för en webbap-plikation [7].

• Modellen: Den digitala tvillingen – den samling matematiska modeller över processer i den mänskliga kroppen som är mer eller mindre tränad på data från den verkliga personen som tvillingen är modellerad efter.

• Objektorienterad programmering: Är en programmeringsmetod där programmet kan innehålla flera olika objekt som integrar med varandra [8].

• OpenCOR: Miljö som används vid simulering av modeller skrivna i CellML [9]. • Prediktion: Hämtning av tidsföränderlig data från modellen för en uppsättning

vari-abler i ett visst delsystem, där de returnerade tidsserierna inte är begränsade till dåtid-nutid.

• React: Bibliotek till JavaScript som används för att bygga användargränssnitt [10]. • RM-diagram: RM står för relational model. RM-diagram används i detta projekt för att

• Server-side scripting: en teknik som används i webbutveckling. Där man använder skript på en webbserver som ger ett svar anpassat för varje användares (kundens) be-gäran till webbplatsen [11].

• System Usability Scale (SUS): En metod för att mäta användarvänligheten hos en pro-dukt [12].

• Variabel: Parameter hos den digitala tvillingen. Exempelvis vikt, blodsocker- och glu-koskoncentrationer, insulin, med mera. Variabler kan visualiseras genom att visa dess graf över tid. Där kan de även prediceras av modellen.

Del I

1

Inledning

I detta kapitel presenteras motiveringen till projektet och syftet med denna rapport.

1.1

Motivering

Ofta delas nyfunnen forskning via publikationer eller tidskrifter, men allteftersom forskning utförs mer via datorer, och modeller byggs i program såsom MatLab, krävs nya lösningar för hur forskare skall dela med sig av sina resultat. Vissa forskare delar sin källkod via Git eller andra plattformar för att andra skall kunna ta del av forskningen.

För projektgruppens kund, forskargruppen för integrativ systembiologi på IMT LiU, som arbetat fram modeller i MatLab [13] och OpenCOR [9] innebär detta att ge bort sin källkod, sitt arbete. De saknar ett enkelt sätt att simulera MatLab- och OpenCOR-modeller via ett ex-ternt användargränssnitt. Detta är något som Digital Tvilling skulle lösa. Digital Tvilling ger användaren en tydlig inblick och enkel tillgång till simuleringar framtagna av forskargrup-pen. Detta helt utan att ge tillgång till de bakomliggande modellerna.

Produkten presenteras i form av en webbapplikation, utvecklad i syfte att göra det möj-ligt för projektgruppens kund att kunna dela sin forskning på ett relativt enkelt sätt. Digital Tvilling skall fungera som en digital version av en person. Hälsovärden och insatser såsom kost tas in som indata och ut kommer en prediktion på hur dessa hälsovärden kan komma att förändras utefter de valda parametrarna.

Den färdiga produkten är tänkt att användas av kunden som konceptvalidering (eng. proof of concept). Med det menas att webbapplikationen skall visa potentialen hos forskar-gruppens modeller i förhoppningen att finna investerare som vill dra nytta av deras forsk-ning. Tanken är att den åtkomst som skapats till de bakomliggande modellerna sedan skall kunna säljas till företag för att de skall kunna bygga egna system kring modellerna. I första hand skulle detta gälla sjukvårdsföretag, men längre fram i tiden är det tänkt att denna pro-dukt även skulle kunna rikta sig mot den privata sektorn. Då skulle privatpersoner kunna hålla koll på sin egen hälsa och se hur olika vanor kan komma att påverka deras kropp och hälsa.

Projektet utförs som ett kursmoment i kursen TDDD96: Kandidatprojekt i programvaruut-veckling [14]. Utifrån gruppens erfarenheter och lärdomar har denna rapport skrivits för att

1.2. Syfte

I den här rapporten diskuteras problem som kan uppstå vid mjukvaruutvecklingsprojekt, tillvägagångssätt, och olika hinder. Rapporten fokuserar på lärande och utveckling, genom att ta upp viktiga moment i utvecklingsprocessen och beskriva vilka lärdomar som kan dras av projektgruppens erfarenheter.

Genom att läsa denna rapport får man en större insyn i gruppens projekt och erfarenheter. Därav få en kunskaper kring utvecklingen av slutprodukten och vilka eventuella erfarenheter som kan tas med från gruppens egna. Dessutom kan information samlas om ämnena som diskuteras kring en vald frågeställning.

1.2

Syfte

Syftet med den här rapporten är att avhandla det projektarbete som utförts och redogöra för teori, metoder, och resultat för den mjukvara som producerats. Rapporten består av projekt-gruppens gemensamma del, följt av individuella delar från varje gruppmedlem.

Rapporten ska leda läsaren till en djupare förståelse ab projektet som utförs och produkten som utvecklas. Dessutom ska den förmedla de kunskaper och erfarenheter som gruppmed-lemmarna samlat på sig under projektets gång. Till sist kommer djupdykningar i specifika ämnen ske via de individuella delarna för att ge bättre insyn i ämnen och tekniker som varit relevanta för projektet.

1.3

Frågeställningar

En frågeställning att fokusera rapporten runt har tagits fram utifrån projektgruppens lär-domar kring mjukvaruutveckling och att jobba emot en kund. För alla medlemmar var det första gången en produkt utvecklas till en kund detta innebar att mycket arbete gjordes för att kunden skulle bli nöjd med slutprodukten. Bland annat gjordes en systemanatomi och ett de-signarbete för att ge gruppen stöd vid implementation av användargränssnittet och systemet som helhet.

I denna rapport kommer följande frågor att behandlas:

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

2. Vilka erfarenheter kan dokumenteras från gruppens projekt som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan ett användarvänligt användargränssnitt tas fram?

1.4

Avgränsningar

Ett antal avgränsningar har satts upp av projektgruppen för att kunna genomföra projektet inom den givna tidsramen. De allmänna begränsningarna för projektet i sin helhet var:

• Tidsbegränsningen för var medlem är 400 timmar

De avgränsningar som sats upp specifikt för utvecklingen av produkten listas nedan: • Funktionalitet för inloggning skall ej implementeras.

• Produkten skall endast implementeras för en enda plattform (alltså inte responsiv de-sign för både platta, dator, och mobil i denna prototyp).

1.4. Avgränsningar

• Appen hanterar inte föränderlig användardata - Digital Tvilling utgörs alltså av en eller ett fåtal statiska dataprofiler.

Avgränsningar sattes även upp för denna rapporten, för att hålla innehållet relevant och arbetet inom tidsramen.

• Rapporten skall ej behandla jämförelser av tekniker och arbetssätt som valts.

• Rapportens diskussioner begränsas till vald frågeställning och de punkter uppsatta för kursen TDDD96: Kandidatprojekt i programvaruutveckling.

2

Bakgrund

Visualisering av biologiska processer är ett område inom systembiologi som under de senaste 20 åren har forskats kring. För att i nuläget beräkna hur en biologisk process går till använder man sig av differentialekvationer (eng. differential algebraic equations) [15]. För att beräkna dessa differentialekvationer används ofta MatLab, OpenCOR, eller liknade program. Dessa program erbjuder även visualisering av den data användaren får ut från beräkningarna. Detta fungerar bra om någon vill visualisera något snabbt på en dator med MatLab eller liknade program installerat. Problemet ligger i att det är svårt att applicera och dela de modeller som har tagits fram om hen inte har tillgång till ett sådant verktyg. Det finns heller inget bra sätt att dela sådan forskning utan att ge tillgång till hela modellen och källkoden till differentialekvationerna.

Projektgruppen har därför fått i uppgift att utveckla en webbapplikation där tredje parter skall kunna ta del av kundens forskning utan att ha insyn i hur beräkningarna sker. Från webbapplikationen skall det vara möjligt att välja vilket delsystem av kroppen användaren vill undersöka och vilken insats hen vill tillföra. Tillbaka skall hen få en visualisering av kroppens respons på den valda insatsen med avseende på de valda variablerna.

2.1

Projektgruppen

Projektgruppen består av sju tredjeårsstudenter på Linköpings universitet. Samtliga projekt-medlemmar studerar till civilingenjör, varav fem i datateknik och två i mjukvaruteknik.

Projektmedlemmarna har blivit tilldelade olika roller. Syftet med rollerna är att ge ansvar över olika områden. En roll innebär inte att den gruppmedlemmen endast skall arbeta med det relaterat till rollen, utan gruppmedlemmar skall ta reda på vad som behöver göras för respektive roll. Nedan genomgås de olika roller.

Teamledare

Teamledarens huvuduppgift är att se till att mål uppfylls och processer följs. Teamledaren tillsammans med analysansvarig är de som representerar teamet utåt. Teamledaren är den som leder möten samt i detta projekt leder teamledaren även arbetet med interaktionsdesign för gränssnittet.

2.1. Projektgruppen

Analysansvarig

Huvudsyftet med en analysansvarig är att ta kontakt med kund och finna kundens sanna behov. Den analysansvarige represterar gruppen vid möte med kund eller beställare. Det är den analysansvarige med hjälp av teamledaren som förhandlar fram kraven. Alla krav som beslutas tillsammans med kunden dokumenteras av den analysansvarige.

Arkitekt

Arkitektens uppgift är att ta fram en stabil systemarkitektur som följs under projekts gång. Arkitekten ser även till att kraven uppfylls. Det är arkitektens uppgift att identifiera de gräns-snitt och komponenter som skall utforma produkten, och sammanställa detta i ett arkitektur-dokument [16].

Utvecklingsledare

Utvecklingsledaren ansvarar för detaljerad systemdesign, leder utvecklingsarbetet, och orga-niserar utvecklarens tester. Utvecklingsledaren samarbetar tätt med testledaren.

Testledare

Testledaren skriver testplan [17] och testrapporter [18][19], beslutar om systemets status, och ser till att tester utförs kontinuerligt. Det är testledarens ansvar att se till att testplanen följs.

Kvalitetssamordnare

Kvalitetssamordnaren säkerställer att gruppen lär sig och utvecklas, samt ser till att standar-der och kvalitetsplan [20] följs. Kvalitetssamordnaren planerar och budgeterar kvalitetspla-nen med resten av gruppen.

Dokumentansvarig

Dokumentansvarig sätter upp dokumentmallar och logotyp, och ser till att dokument levere-ras i tid. Dokumentansvarig arbetar tätt med kvalitetssamordnare och konfigurationsansva-rig.

Konfigurationsansvarig

Konfigurationsansvarig bestämmer vilka arbetsprodukter som skall versionshanteras, och vad som ingår i leveranserna. Hen tar även hand om projektets Git.

I tabell 2.1 presenteras projektgruppens medlemmar och deras respektive roll. Tabell 2.1: Projektgruppens medlemmar

Namn Roll Email

Teodor Ganestål Analysansvarig teoga849@student.liu.se

André Palmborg Testledare andrpa149@student.liu.se

Adrian Royo Utvecklingsansvarig adrro173@student.liu.se

William Stenberg Teamledare wilst118@student.liu.se

Olle Stenvall Dokumentansvarig/

Konfigurationsansvarig ollst531@student.liu.se

Juliette Winneroth Arkitekt julwi075@student.liu.se

2.2. Tidigare erfarenheter

2.2

Tidigare erfarenheter

Samtliga projektgruppsmedlemmar har tidigare arbetat i grupp inom flera olika projekt un-der sin tid på Linköpings universitet. I dessa projekt har gruppens medlemmar utfört förstu-dier, skrivit rapporter, och planerat och utfört projekt. Med hjälp av dessa erfarenheter har gruppen gemensamt kunnat sätta upp mål, krav, och förväntningar på var medlems arbete och gruppens samlade arbete.

Programutveklingsmetodik - PUM

Projektgruppens medlemmar har läst en kurs inom programutvecklingsmetodik [21], vilken räknas som en grund till projektet [14]. Där lärde sig gruppmedlemmarna all teori om hur de ska utföra ett riktigt projekt. Dessa kunskaper har implementeras praktiskt under detta projekt.

Programmeringskurser

Två programmeringskurser som gruppmedlemmarna läste tidigare har de tagit med sig till detta projekt. Dessa kurser är TDDD73 Funktionell & imperativ programmering i Python [22], och TDDD78 Objektorienterad-programmering i Java [23].

Python skulle faktiskt användas under detta projekt så att ha en bakgrund i språket sedan tidigare kan vara hjälpsam. Det används i backend och motor delen av projektet.

Även om Java språket används inte direkt i projekt har gruppmedlemmarna lärt sig myc-ket mer än att bara skriva kod av denna kurs. Objektorienterad programmering är någonting gruppmedlemmarna skall använda i fronten; nämligen i React.

Konstruktion med mikrodatorer - KMM

Ett miniprojekt som vissa gruppmedlemmar hade precis innan detta projekt har varit mycket givande när det gäller erfarenhet. I KMM-kursen hade gruppmedlemmarna också en kund som de skulle leverera en produkt till, fast denna kund representerades av en av kursens handledare. Även om denna kund var de olika kursansvariga så var kraven upplagda för att likna riktiga kundkrav. Dessutom kan man tänka sig att kursen är ett bra sätt att förbereda sig för kandidatprojektet och samla erfarenheter som kan vara bra att ta med sig.

2.2.1

Förbättringar inför detta projekt

Utifrån de tidigare nämnda kurserna och andra grupparbetes erfarenheter kunde gruppen identifiera saker som kunde förbättras inför detta projekt. Dessa förbättringar ville grupp-medlemmarna göra för att arbetet skulle bli så effektivt som möjligt och för att undvika de problem som uppstått i tidigare projekt. Nedan finns en lista över de saker som gruppen ville göra bättre:

• Veckomöten

• Halvtidsutvärdering • Gemmensamt arbete • Att komma i tid • Bättre Kommunikation • Användning av LaTeX

2.3. Kund

De fem första punkterna i ovanstående lista kommer ifrån att gruppmedlemmarna upp-levt dålig organisation i tidigare grupparbeten. Utifrån detta ville medlemmarna ha bättre insyn i varandras arbete, få bättre hjälp från varandra och vara öppnare med varandra. De punkterna som tas upp i listan ovan ansåg gruppen skulle bidra med detta.

Vissa av gruppmedlemmarna hade använt LA_{TEXunder tidigare projekt medan resten hade}

använt Goodle Docs. De gruppmedlemmarna med erfarenhet av LA_{TEXansåg att det var mer}

effektivt att använda särskilt till ett sådant tungt projekt. Därför kom gruppen överens om att använda sig av LA_{TEX. Det gav även de som inte hade arbetat med L}A_{TEXtidigare en möjlighet}

att lära sig.

2.3

Kund

Projektgruppens kund är forskargruppen för integrativ systembiologi på IMT LiU. Där vå-ra kontakt personer har varit IMT grupp ledaren Gunnar Cedersund och sin kollega Tilda Herrgårdh. Gruppen består av 8 medlemmar och några andra runt om i världen. Integrati-ve Systems Biology(ISB)-Group- vilket är det specifika namnet på forksargruppen från IMT-arbetar med systembiologi, vilket innebär att de använder matematisk modellering som ett verktyg för att analysera biologiska data [24].

Kundens vision är att projektgruppen skall ta fram ett enkelt sätt att dela och visa deras forskning. För att forskningen skall presenteras på ett lättillgängligt sätt vill kunden ha möj-lighet att kalla på modellerna från en webbapplikation. En styrka med att använda sig av en webbapplikation för att visa modellerna är att användare inte behöver se själva källkoden till modellerna.

3

Teori

I detta kapitel kommer bakomliggande teori för projektet att presenteras. Denna teori inne-fattar bland annat verktyg som använts under utveckling, samt resurser som använts vid insamling av relevant information under projektets gång.

3.1

Projektverktyg

Nedan beskrivs de verktyg som projektgruppen använt för kommunikation och organisation inom projektet.

3.1.1

Trello

Trello är en virtuell anslagstavla som kan användas som backlog vid mjukvaruutvecklings-projekt [25]. En backlog kan ses som en prioriterad lista av uppgifter som skall utföras i ett projekt [26].

Anslagstavlan kan delas upp i kolumner och i kolumnerna kan kort läggas till. Korten be-skriver olika uppgifter som behöver utföras tillhörande projektet, och kolumnerna bebe-skriver till exempel vilken typ av uppgift det är. I projektgruppens fall representerade kolumnerna i vilket stadie uppgifterna var; “att göra”, “pågående”, “att granska” eller “klart”. Dessutom kan uppgifter markeras för att indikera vilken person som skall utföra den. Trello har använts av projektgruppen för att alla skall få en tydlig bild av vad de andra medlemmarna arbetar med. Det är även ett användbart verktyg vid agil utveckling.

3.1.2

Google Drive

Google Drive är en molntjänst där filer kan sparas och delas mellan olika personer [27]. I Google Drive har gruppen samlat alla dokument och filer som inte innefattar de dokument som skall lämnas in till handledare, kund, eller examinator. Tidrapportering har skett via ett kalkylark i Google Drive.

3.1.3

Slack

Slack är ett chattverktyg som är tillgängligt på både mobil och dator [28]. Det som skiljer Slack från en klassisk chattjänst, förutom möjligheten att dela upp chatten i olika chattrum,

3.2. Design

är att man kan skapa kanaler. Syftet med att ha kanaler är att dela upp diskussioner och planering av olika saker, så det blir lättare att hitta informationen vid senare tillfälle. Slack är projektgruppens huvudsakliga kommunikationskanal.

3.1.4

Microsoft Teams

Microsoft Teams är en plattform för att koordinera arbete mellan grupper av människor [29]. Kunden använder denna plattform för att koordinera sitt arbete, hålla videokonferenser, och dela filer. Projektgruppen blev under projektets sista iteration inbjudna till kundens “team” i denna tjänst, vilket innebär att de fick tillgång till kundens grupp som skapats i Microsoft Teams. Set underlättade framförallt fildelning mellan de två grupperna.

3.1.5

Git

Git är ett versionshanteringssystem (VCS) (eng. Version Control Systems) [30]. VCS är mjuk-varuverktyg som hjälper utvecklare att samarbeta genom att organisera förändringar av de versionshanterade filerna [31].

När flera utvecklare parallellt förändrar en fil kan konflikter i filens innehåll uppstå. An-vändning av ett VCS möjliggör parallellt arbete med så få konflikter som möjligt.

Gitlab

GitLab är ett distribuerat versionshanteringsprogram som använder sig av Git [32]. GitLab erbjuder en rad olika verktyg som underlättar för mjukvaruutvecklare som arbetar i grupp. Några av verktygen är versionshantering, projektplanering i form av Kanban Boards [33], kontinuerlig leverans (eng. continuous delivery) [34], kontinuerlig integration (eng. continu-ous integration) [35], och automatisk testning [36].

Under projektet har gruppen endast använt sig av GitLabs versionshantering. Gruppen valde just GitLab eftersom man får tillgång till stora delar av det via universitet och Institutio-nen för Datavetenskap (IDA). Dessutom hade flera av projektmedlemmarna tidigare arbetat med GitLab.

Branch

En Branch eller gren(ar) som den ska refereras till i denna rapport, är en pekare till en viss ändring en git användare har gjort på standard grenen [37]. Istället för att direkt ändra på huvudgrenen skapar användaren en kopia av den och ändrar på den.

3.1.6

L

_TEX

LA_{TEX är ett program för typsättning av text. Det är tänkt att användaren inte skall behöva}

tänka för mycket på utseendet av dokumentet när det skrivs, utan bestämma stil och design på dokumentet i efterhand [38]. De filer som skapas sparas med filändelsen .tex och dessa kompileras vanligtvis till PDF-filer [39].

Gruppen har valt att använda sig av LA_{TEX då gruppen tillhandahölls en mall för}

kandi-datrapporter likt denna, samt att flera i projektgruppen ville lära sig hur man kan använda programmet. LA_{TEX användes med denna mall för kandidatrapporten, och utan mall till}

res-terande dokument som producerades under projektets gång. Några av gruppmedlemmarna hade dessutom tidigare erfarenhet av programmet.

3.3. Implementationsverktyg

mer till stor del från Mattias Arvolas forskning [40]. Metoderna innefattar att hämta data från tänkta användare genom en användarstudie, sammanfatta detta till personor, och skapa designkoncept med personorna i åtanke.

3.2.1

Användarstudier

En användarstudie är en undersökning under designarbetet eller när produkten är slutfört där designgruppen samlar in data från potentiella användare, eller andra personer som man vill designa för. Utöver det så kan det användas till att testa användarens upplevelse med den färdiga produkten för att upptäcka potentiella förbättringar[40].

En användarstudie kan utföras genom att intervjua ett urval personer inom produktens tänkta målgrupp. Under intervjuer är det viktigt att den intervjuade inte har någon bild av vad som skall utvecklas, då det kan påverka vilka sorts svar man får under intervjun.

3.2.2

Personor

En användarstudie kan sammanställas till en eller flera personor, som representerar flera an-vändare eller intressenter i projektet. Personor är fiktiva personer med namn, intressen, och åsikter, som skulle kunna vara användare av produkten som designen skapas för [40]. Syftet med personor är att skapa en bild av slutanvändaren, för att lättare kunna föreställa för- och nackdelar med ett designkoncept utifrån ett användarperspektiv.

När man har flera personor är det vanligt att man väljer en primär persona. Denna per-sona blir då den som designen utvecklas för i huvudsak, kanske på bekostnad av de andra personornas behov eller viljor.

3.2.3

Designkoncept

Ett designkoncept är en mer eller mindre konkret beskrivning av ett tänkt gränssnitt[41]. Processen att arbeta fram designkoncept är iterativ och kan till exempel involvera brainstorming i syfte att generera många idéer på kort tid [42]. Dessa idéer kan sedan kom-bineras och förfinas till ett mer färdigt koncept som till slut blir redo att skapa prototyper utifrån [40].

3.3

Implementationsverktyg

Nedan följer teori över de implementationstekniska verktyg och metoder som använts i pro-jektet.

3.3.1

Systemanatomi

En systemanatomi är en riktad graf över ett systems funktionalitet utifrån ett användarper-spektiv [43]. Systemanatomin ska skapa en gemensam bild över vad produkten och systemet ska uppnå och underlätta beslut kring systemet. Anatomin är vidare en bra grund för plane-ring av system integration och planeplane-ring av projektet. Systemanatomin är endast en koncept som är menat att hjälpa projektgruppen och är inte en exakt eller formell beskrivning av systemet.

3.3.2

JavaScript

JavaScript är ett objekt-orienterat webbutvecklingsspråk som har sin största användning som scriptspråk hos webbapplikationer [44]. Att JavaScript är ett scriptspråk betyder att det är ett språk som möjliggör automatisering av mjukvaruexekvering. Med andra ord brukar språket

3.3. Implementationsverktyg

användas för skapande och exekvering av majoriteten av webbapplikationers funktionalite-ter [45]. Enligt Stack Overflows årliga enkät, där data samlats från nästan 90 000 utvecklare, visar det sig att JavaScript är det mest använda programmeringsspråket sex år i rad [46].

3.3.3

Node.js

Node.js är en anpassningsbar JavaScript-miljö med öppen källkod. Denna JavaScript-miljö möjliggör exekvering av JavaScriptkod utanför webbläsaren och “server-side-scripting”. Med andra ord kan man testa ens JavaScript-kods dynamiska möjligheter utan att behöva köra koden mot en hemsida [47].

3.3.4

React

React är ett JavaScript-bibliotek, skapat av Facebook för utveckling av användargräns-snitt [10]. React är komponentbaserat, vilket innebär att man skapar komponenter som re-presenterar olika element i användargränssnittet. En React-applikation kan alltså ses som en kombination av React-komponenter.

3.3.5

CSS

Cascading Style Sheets (CSS) är ett språk som används för att beskriva hur HTML- eller XML-kod skall se ut [48]. Med CSS kan man byta färger, sätta fonts, skapa former, och bestämma storlek på former och text. Det är med andra ord ett språk utvecklat för att designa hemsidor.

3.3.6

JSS

JSS är ett sätt att beskriva CSS kod i form av JavaScript, det kompileras om till CSS-kod antingen direkt i webbläsaren eller på servern [49]. Material-UI som använts för att plocka färdiga komponenter till React stylas med hjälp av JSS.

3.3.7

Python

Python är ett Open Source, högnivå-programmeringsspråk från Python Software Founda-tion [50]. Python är dynamiskt typat och är menat att ge ett enkelt tillvägagångssätt för ob-jekt orienterad programmering. Tanken med språket är att det ska vara enkelt att skriva och förstå så att energi kan läggas på problemlösning snarare än på språket i sig. Att Python är ett högnivå-språk innebär att vid programmering i språket behöver man ej tänka på saker så som hantering av minne.

3.3.8

Pytest

Pytest är ett testramverk i Python som distribueras under MIT-licensen [51]. Ramverket tillå-ter skrivandet av testillå-ter direkt i Python med endast enkla tillägg på ursprunglig syntax. Verk-tyget erbjuder en mängd attraktiva funktioner så som kontroll över livslängden på objekt, kontroll över vilka tester som är med i varje körning, och automatisk inhämtning av testfiler.

3.3.9

CellML

CellML är ett märkspråk som används för att beskriva matematiska modeller, särskilt av biologiska system [52]. Språket är baserat på XML och tillåter forskare att dela sina modeller med varandra i en gemensam standard. CellML utvecklas vid University of Auckland, Nya Zeeland.

3.3. Implementationsverktyg

3.3.10

OpenCOR

OpenCOR är en arbetsmiljö som tillåter hantering av modeller skrivna i CellML [9]. Gräns-snittet erbjuder textredigering av inlästa modellfiler och simulering av deras ingående för-lopp, vilka beskrivs som ekvationer.

I projektet har man utgått från en specialiserad version av programmet som dessutom innehåller en Python-terminal genom Jupyter [53]. Inbäddat i denna version av Python ligger ett API till OpenCOR-programmet som erbjuder en delmängd av de operationer som kan utföras i gränssnittet.

4

Metod

I detta avsnitt beskrivs metoden som använts för att arbeta fram en slutprodukt och besvara projektets frågeställningar.

4.1

Besvara frågeställningarna

För att besvara rapportens frågeställningar kommer gruppens tillvägagångssätt för att slutfö-ra projektet att presenteslutfö-ras och utvärdeslutfö-ras. Från den förstudie som utfördes för att få en förs-ta idé kring vad slutprodukten innebär, det kontinuerliga arbetet inom gruppen som skedde under projektets gång, till det testningsarbete som skedde för att säkerställa produktens kva-litet.

4.2

Förstudie

Projektets tidsplan delades upp i en förstudie, följt av tre iterationer. Tiden som lades på för-studien sträckte sig även in i den första iterationen. Under denna tid var målet att framställa en projektplan, en kravspecifikation, en kvalitetsplan, en testplan för iteration 1, och ett arki-tekturdokument.

Kravspecifikationen [54] togs fram i samarbete med kunden. Projektgruppen samlade in-formation om produktidén från kunden, formulerade krav, och stämde sedan av kraven med kunden. Detta är första steget mot att skapa en produkt som ger värde till kunden.

4.2.1

Systemanatomi

Utifrån de specifikationer på applikationen som projektgruppen hade fått från kunden bygg-des en systemanatomi. Detta gjorbygg-des parallellt med framtagandet av kravspecifikationen och låg till stor del som bas för vad som skulle vara med i kravspecifikationen då den hjälpte pro-jektgruppen att se vilka delsystem och funktioner som behövde implementeras. Systemana-tomin användes även som underlag när arkitekturen av systemet togs fram. SystemanaSystemana-tomin skapades utefter de steg som fanns upplagda på kurshemsidan [43]. Dessa steg nämns här nedan:

4.3. Designarbete

• Inom gruppen jämför förslagen och argument för/emot. • Identifiera funktionsgrupper som anatomer (eng: anatoms). • Brainstorm med Post-it lappar.

• Sätt ihop en systemanatomi med hjälp av post-its.

4.3

Designarbete

Projektgruppen har lagt stor vikt att utföra ett designarbete över det gränssnitt som produce-rats. För att ta fram designen följde metoden beskriven i Mattias Arvolas bok Interaktionsde-sign och UX: om att skapa en god användarupplevelse [40].

4.3.1

Användarstudie

En användarstudie utfördes för att skapa en bättre bild av vilken sorts produkt som skulle utvecklas.

Innan användarstudien hade deltagarna begränsad information kring vad som skulle ut-vecklas. Vissa deltagare visste att ett användargränssnitt skulle utvecklas och att det gällde hälsodata, medan vissa inte hade någon inblick i produkten. Detta på grund av att om den intervjuade har insyn i produkten kan svaren den ger vara svaren som den tror är rätt, och inte nödvändigtvis svaren som speglar deras egna åsikter och tankar.

Under förstudien intervjuades totalt fyra personer. En överläkare inom öra, näsa, och hals, en underläkare som arbetar på vårdcentral, och två stycken forskare ur forskargruppen för integrativ systembiologi vid IMT LiU. Vid varje intervju närvarade två projektmedlemmar, där den ena höll i intervjun och den andra antecknade vad som sades. I tre av fallen spelades intervjuerna in för att se till att inget missades av personen som antecknade.

Efter varje intervju genomgicks och behandlades det dokument som skapats under inter-vjun.

4.3.2

Personor

Utifrån den insamlade datan från intervjuerna togs två personor fram genom att projekt-gruppen diskuterade igenom de intervjuer som hållits. Dessa två personor beskrevs i var sin sammanfattande profil som fick representera de användare man mött [55]. Från dessa två personor valdes en huvudpersona ut, som fick primärt fokus när gränssnittet skulle designas.

4.3.3

Skisser och koncept

Från de skapade personorna togs skisser fram för att illustrera hur slutprodukten kunde se ut enligt olika designkoncept. Skisserna jämfördes och en valdes ut som första utkast av de-signen.

Denna skiss ämnade att ge en överblick för gruppens samtliga medlemmar över vilka delar gränssnittet behövde innehålla i den färdiga produkten. Senare i utvecklingsprocessen arbetades en ny skiss fram som bättre representerade det grafiska målet för slutprodukten.

Efter att denna skiss tagits fram påbörjats ytterligare en skiss. Denna var mer utförlig och välgjord. Skissen skapades med hjälp av Marvel App, vilket är ett prototypningsverktyg som används för att skapa prototyper av hemsidor eller mobilapplikationer [56].

Anledningen till att göra användarstudier, skapa personer, och sedan skissa en koncept utrifrån det, tyckte projektgruppen var ett sätt att börja projektet. Huvudmålet efter produk-ten har skapats är att ha en webbapplikationen som är användarlvänligt till sin tänkta an-vändaren. Det är därför dessa personor är ett bra steg mot attt skapa värde för kunden samt ett användarvänligt användargränssnitt, eftersom projektmedlemmarna utvecklar produk-ten från personornas prespektiv.

4.4. Systemimplementation

4.4

Systemimplementation

I detta avsnitt genomgås metoden som använts för att implementera produktens olika delsy-stem.

4.4.1

Systemöversikt

Som bas för systemets implementation skapades en arkitekturskiss för hur systemets olika delar skulle implementeras och vilka ramverk som skulle användas.

En arkitektur fastslogs som bestod utav tre huvuddelar: frontend, backend och motorn, med två stycken tillhörande databaser. Dessa huvudelar är tänkta att skapa värde för kunden på så sätt att de är skapade utifrån kraven som projektgruppen kom fram till med kunden.

4.4.2

Frontend

Denna del av rapporten beskriver hur frontend har utvecklats och vilka verktyg som använts för att skapa gränssnittet. Tidigt i projektet bestämdes det att React skulle användas vid ut-vecklingen av frontend. Under projektets gång har senare flera andra verktyg och bibliotek lagts till. Nedan beskrivs arbetsgången och mer detaljerat hur olika ramverk och verktyg använts under utvecklingsfasen av projektet.

React

En React-applikation producerades, vilken kan köras som en fristående webbapplikation lo-kalt på en dator med Node.js installerat [57]. Genom Node.js kan webbgränssnittet också byg-gas till en statisk filkatalog som kan levereras genom Flask.

För att komma igång med React anordnade gruppens arkitekt en workshop. Gruppmed-lemmarna satte sig in i biblioteket ifrån denna och med hjälp av material som hittades på internet.

Till en början var det tänkt att alla komponenter skulle implementeras helt från grunden och därefter anpassas efter det valda designkonceptet. Halvvägs in utvecklingsarbetet insåg gruppen att detta var tidskrävande och inte helt nödvändigt. Därför valdes istället att i stor utsträckning använda färdiga komponenter så som knappar, reglage, och grafritningskom-ponenter.

Material-UI

Material-UI upptäcktes erbjuda färdiga komponenter skrivna i JavaScript. Några av dessa komponenter har använts till gränssnittet direkt som de är, och några har modifierats med hjälp av JSS-styling eller förändrats funktionalitetsmässigt för att passa Digital Tvilling bätt-re. Dessa komponenter hittas under “Component Demos” på Material-UI:s officiella hemsi-da [58].

4.4.3

Victory

Ett av kundens viktigaste krav på produkten var att på något sätt kunna visa sin forskning och vad var den var kapabel till. Resultat av forskningen representerades ofta i form av gra-fer. För att enkelt kunna rita ut grafer i webbapplikationen bestämdes därför att använda Victory [59]. Victory erbjuder färdiga React-komponenter som kan rita ut grafer och tabeller. Gruppen har endast valt att använda sig av grafritningskomponenterna, nedan i figur 4.1 visas en graf skapad med hjälp av Victory, bilden är tagen från Victorys hemsida [60].

4.4. Systemimplementation

Figur 4.1: “Brush and Zoom”-graf som använts i projektet.

Victorys “Brush and Zoom”-graf användes då den ger möjligheten att zooma in på en specifik del av grafen.

4.4.4

Fetch

För att frontend-delen av webbapplikationen skulle kunna kommunicera med backend så valde gruppen att använda Fetch API:et som finns inbyggt i webbläsaren [61]. Genom dessa kan React och Flask kommunicera och på så sätt kan frontend ta del av information som är sparad i backends databas eller som backend har tagit emot från motorn.

4.4.5

Backend

Utvecklingen av backend innefattade implementationen av en Flask-server vars syfte var att erbjuda anropspunkter för frontend att hämta data genom anrop över HTTP.

Servern i Flask konfigurerades till att servera frontends filer efter att de byggts till pro-duktionsfärdig kod. Detta underlättas av att frontend är en ensidig applikation (eng. single page application). Webbplatsen visas när användaren navigerar till webbplatsens rotkatalog och andra sökvägar används till de specifika anropen som frontend gör via Fetch.

Både anrop och resultat strukturerades i JSON, vilket gör det enkelt både för människa och maskin att tolka vad som förfrågas och lämnas ut. Validering av användargiven data implementeras i enkel form, till exempel för att neka förfrågningar om att simulera negativ tid.

4.5. Insamling av data

I många fall har behoven hos frontends komponenter bestämt hur data formateras för leverans från backend. Till exempel innebär detta att om en React-komponent förväntar sig en koordinat beskriven i heltal, men backend representerar koordinaten som två flyttal, så faller det på backend att avrunda talen till heltal innan anropet besvaras med den efterfrågade datan. Tydligast blir detta i fallet då simulerad data som kommer från motorn ska lämnas ut till frontend, där man dessutom vill utelämna så mycket metadata som möjligt.

4.4.6

Motor

Motorn är den del av systemet som hanterar alla beräkningar i OpenCOR. Den är, precis som backend en Flask-server. Implementationen av motorn började som en kopia av backend-servern. Syftet var att separera den kod som hanterade frontend och användarnära data, och den kod som hanterade OpenCOR och forskargruppens modeller.

Under utvecklingen av denna funktionalitet lades mycket tid på att förstå hur OpenCOR fungerar, hur kundens CellML-filer är strukturerade, och vilken funktionalitet Python-API:et erbjuder. Programmet OpenCOR, som utför simuleringarna, körs genom en Jupyter Note-book [53], då gruppen fick tips av kunden om en version av OpenCOR som gjorts tillgänglig på GitHub och som exponerar ett API mot Python genom Jupyter. Den resulterande funktio-naliteten kan grupperas i två delar: den som körs när motorn startar, och den som körs vid anrop från backend.

För att motorn skulle kunna startas så krävdes kunskap om vilka filer som skulle läsas in, samt fördefinierad information som lagrades i en databas. Utifrån denna relativt lilla mängd information kunde sedan CellML-filer köras genom en XML-filtolkare. Denna filtolkare ut-vann information om vilka variabler som fanns tillgängliga, samt annan relevant information såsom inlagda startvärden i filerna. Startvärdena valdes av forskargruppen efter att ha un-dersökt de fenomen som modellerna beskriver, och dessa är del av deras företagshemlighet.

Motorns anslutning till den övriga produkten byggdes som i backend som en Flask-server, där utvecklingsgången liknade backends med anropspunkter som sattes upp och testades. Backend-servern konfigurerades till adressen på motorn (ofta på samma dator på annan port, även testat över ett lokalt nätverk). Genom detta kunde anrop flöda från användarens interak-tion med gränssnittet, via backend-servern och vidare till motorn för simulering, och tillbaka igen.

4.4.7

Databaser

Behovet för produkten att kunna lagra data på serversidan var tidigt uppenbart. Motorn behövde kunna lagra metadata om forskargruppens CellML-filer, och i backend lagrades be-skrivande text tillsammans med referenser till motorns OpenCOR-variabler.

Projektgruppen hade satt upp Flask och undersökte möjligheterna att lagra data och fann verktyget SQLAlchemy, som förenklar hantering av tabeller och relationer i databaser [62]. Dessa uttrycks i Python, till skillnad från i en rent SQL-baserad lösning, som utvecklas helt i språket SQL. Dessutom kan SQLAlchemy enkelt integreras med övriga moduler och funk-tioner.

Databaserna för projektets produkt designades enligt arbetsgången beskriven i Fundamen-tals of Database Systems av Ramez Elmasri och Shamkant B. Navathe [4].

4.5

Insamling av data

För att göra framsteg med det tilldelade projektet har projektgruppen varit beroende av data från primärt två områden: internetkällor och kunden. Betoning på kunden som den viktigaste källa för data som skall hjälpa med att förstå modellerna, arbeta med dem, och simulera dem

4.6. Metoder för att fånga erfarenheter

Internetkällor

Under utvecklingsprocessen har artiklar, videor, och liknande format som finns tillgängliga på internet använts av projektets medlemmar i utbildande syfte.

Detta innefattar allt från flera Google-sökningar till att läsa publicerade artiklar som be-skriver tillvägagångssätt för att till exempel få React att kommunicera med Flask.

Metoden har inte alltid varit tillförlitlig, men med ett så stort sökrum som finns att leta i har det oftast gått att hitta någon som sökt efter samma information, eller haft den och delat med sig.

Kunden

Kontakten med kunden har givit information relaterat till sådant som de själva arbetar med, och som projektgruppen också behövde hantera i projektet. Detta inkluderar kundens mate-matiska modeller i form av CellML-filer, samt programmet OpenCOR som används för att hantera dessa.

Kunden hjälpe också till genom att sätta projektgruppen i kontakt med OpenCOR:s ut-vecklingsteam i Nya Zeeland, vilka kunde ge mer detaljerad information om programmets funktionalitet och problem.

4.6

Metoder för att fånga erfarenheter

Inför projektet hade ingen i projektgruppen tidigare arbetat med webbutveckling. För att gruppen skulle lära sig de olika nödvändiga språk och bibliotek som använts under projektet delades tidigt ansvarsområden ut.

Allteftersom val gjordes av ramverk, språk, och bibliotek så dokumenterades valen i grup-pens arkitekturdokument [16]. Detta gav resten av gruppen möjlighet att se hur valen gjordes och varför det passade projektet bäst. Medlemmarna hade då möjlighet att själva läsa på mer om det specifika ämnet om de så ville.

4.6.1

Workshops

Projektgruppen har under projektets gång hållit fyra olika workshops för att gruppmedlem-marna skall kunna dela med sig av information och lära sig de de behöver för vidare arbete. Workshops hölls utav en av gruppmedlemmarna som hade satt sig in i ett ämne och de andra medlemmarna deltog.

• Efter val av ramverk och språk lärde sig arkitekten för projektet hur React fungerar och höll en kort workshop för gruppen om hur man installerar och kommer igång med det under iteration 1. Workshopen gick ut på att arbeta igenom en React-tutorial [63]. • Testledaren i gruppen tog an sig ansvaret att lära sig hur pytest fungerar, vilket är ett

ramverk för att köra enhetstester på Python-kod. Sedan såg han till att resten av grup-pen också lärde sig det genom en tvåtimmars workshop under iteration 1.

• Teamledaren presenterade ett instruktionsdokument, utformat av datateknikstudenten Mattias Salo, om hur man kan använda dokumentverktyget LA_{TEX. Detta gick gruppen}

igenom på en workshop under förstudien.

• Dokumentansvarig höll en timmes workshop för gruppen under förstudien, där han gick igenom Git med de som behövde det.

4.6. Metoder för att fånga erfarenheter

4.6.2

Möten

Gruppen har internt haft avstämningar på måndagar och fredagar för att vara på samma sida med vad som skall göras och hur läget ser ut. Utöver detta har gruppen schemalagt andra tillfällen för teamutveckling och andra aktiviteter. Möten med kunden och andra intressenter har skett med viss regelbundenhet.

Interna möten

Varje medlem i projektgruppen var tilldelad en specifik roll i gruppen. Detta ledde till att vis-sa gruppmedlemmar hade större insyn i visvis-sa aspekter av projektet än andra. Det var därför viktigt för gruppmedlemmarna att dela med sig av sina erfarenheter och vad de har gjort under senaste tiden. Det är en av anledningar till att projektgruppen har haft två veckomöten varje vecka.

Mötena i början av veckan har varit till för att planera upp veckan, gruppen har då ofta valt att ses i helgrupp i så stor utsträckning som möjligt. Detta delvis för att man skall kun-na fråga varandra om hjälp, för att inga missförstånd skall uppstå, och för gemenskapen i gruppen. På möten vid veckans slut valde gruppen att ha för att ge alla en chans att berätta vad de arbetade med under veckan och vad som gick bra eller dåligt. Under fredagsmötena berättade även samtliga gruppmedlemmar vad de skulle arbeta med under nästkommande vecka.

Utöver dessa två möten så hade gruppen också ett handledarmöte varje vecka. Det mötet liknade veckomöten med tillägg från handledaren samt frågor från medlemmarna till hand-ledaren.

Åtgärder mot förseningar

Efter ungefär halva projekttiden kom projektgruppen överens om att införa systemet fikapin-nar, då man sett regelbundna förseningar av flera medlemmar som ett problem och ville testa ett sätt att förhindra det. Systemet innebär att “poäng” i form av virtuella fikapinnar delas ut vid försening, och när en gruppmedlem nått ett visst antal fikapinnar blir denne tvungen att ta med fika till nästa gemensamma arbetspass eller möte.

Kundkontakt

För att tillfredsställa kundens krav i så stor utsträckning som möjligt har mycket information och feedback hämtats in från kunden. Projektgruppen har haft kontakt med kund via fysiska möten, men även via mail och verktyg för videokonferens (till exempel Skype). Gruppen valde att boka in fysiska möten vid större beslut som gruppen behövt ta för att se till att de inte gick i fel riktning jämfört med kundens bild.

Fysiska möten planerades även in med jämna mellanrum för att hålla en god kontakt och uppdatera vad som hänt i projektet. Inför möten kom man överens om vad som skulle tas upp innan mötena ägde rum, detta för att se till att både kund och projektgrupp var förberedda och kunde få ut så mycket som möjligt från mötena.

4.6.3

Veckoenkät och statusrapport

Varje söndag samlade teamledaren utvärderingar från varje gruppmedlem. Denna utvärde-ringen var i form av en enkät med allmänna frågor om hur medlemmarna kände kring pro-jektarbetet, vad hen har jobbat med och lärt sig under veckan, upplevd arbetsbelastning, samt förbättringar och kommentarer. Enkäterna låg till grund för den veckorapport som teamleda-ren skickade till handledare och examinator varje vecka, och användes även som del i

under-4.7. Arbetsmetodik

4.6.4

Granskningar

Vid varje iteration så skedde en inlämning av dokument till kursansvarig samt projektgrup-pens handledare. Innan dessa inlämningar så hade dokumentskrivning delats upp beroende på medlemmarnas roll och sedan skulle varje dokument granskas av en annan gruppmed-lem. På det här sättet så kunde gruppen kontrollera språkfel, upplägg, källhänvisning med mera i dokumentet. I och med dessa granskningar lärde sig varje medlem om minst ett an-nat ämne som hen inte hade skrivit om. Dokumentgranskning har skett effektivt genom hela projektet.

Dessutom hade gruppen kodgranskning för att medlemmarna skulle få kunskap om en annan gruppmedlems kod. Detta genom att granska den innan den kunde räknas som “klar”.

4.7

Arbetsmetodik

Detta kapitel kommer att gå igenom gruppens arbetsmetodik. Under projektets gång har det varit viktigt för gruppmedlemmarna med kommunikation och samarbete, vilket avspeglats i olika aktiviteter och tillvägagångssätt både i teambuilding och i implementation.

4.7.1

Samarbete

För att samarbete skulle fungera väl krävdes regelbundna möten, avstämningar och att med-lemmarna hjälptes åt. Då projektgruppen har arbetat iterativt under projektets gång skedde avstämningar vid varje veckostart och slut. Dessa möten diskuteras i kapitel 4.6.2. Grup-pen planerade även in ett flertal workshops, där en gruppmedlem fick visa och förklara för gruppen hur ett visst arbetssätt, teknik eller system fungerar och vad det skall användas till. Utöver att projektmedlemmarna haft olika roller så valde gruppen att dela upp de olika utvecklingsområdena mellan gruppmedlemmarna. Detta gjorde det extra viktigt att grupp-medlemmarna delade mig sig av sina kunskaper och visade upp sitt arbete så att alla skulle få en inblick i var och en av systemets delar. Detta diskuteras i kapitel 4.6

För att gruppen skulle kunna arbeta bra tillsammans krävdes en bra sammanhållning inom gruppen där medlemmarna vågade prata öppet med varandra. Där valde gruppen att sätta upp träffar utanför studie tid, så kallade “kick-off” och “mid-off”, för att umgås och lära känna varandra bättre.

Efter att halva tiden av projektet hade gått hade gruppen en halvtidsutvärdering. Under denna utvärdering fick gruppmedlemmarna utvärdera hur arbetet så långt hade gått, men också hur de upplevde de andra gruppmedlemmar i en öppen feedback-session kallad “heta stolen”. Heta stolen gick till så att medlemmarna fick en i taget ta emot feedback från res-ten av gruppen. Gruppen fick då ta upp saker som medlemmen gjorde bra och saker som medlemmen skulle kunna förbättra.

4.7.2

Kommunikation

Kommunikation är en viktig del av ett bra samarbete. För kommunikation använde grupp-medlemmarna olika verktyg, bland annat Trello och Slack.

Trello användes för att håll koll på alla uppgifter som behövde göras både vid dokument-skrivning och vid implementation. Verktyget hjälpte gruppen att ordna upp uppgifter i prio-ritetsordning, se vilka uppgifter som höll på att utföras och vem som gjorde vad. Dessutom använde gruppen sig av en “redo för granskning”-kategori som gjorde det möjligt för alla gruppens medlemmar att gå in och se hur arbetet hade utförts, om något behövde förbättras och få bättre insikt i arbetet. Genom Trello kunde en gruppmedlem när som helst gå in och ta på sig en ny uppgift så ingen satt utan arbete att göra.

Slack användes för all kommunikation mellan medlemmarna inom gruppen, och med handledaren. Slack gav möjlighet för gruppen att hålla olika diskussioner parallellt genom