Stöd för digital chatt och kommunikation i vård

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2021 | LIU-IDA/LITH-EX-G--2021/025--SE

Stöd för digital chatt och

kommu-nikation i vård

Support for digital chat and communication in healthcare

–

A thesis exploring a system developed for communication

between patients and healthcare workers.

Lucia Choura

Casper Jensen

Taha Unalan

Kevin Bärudde

Hannes Westander

Filip Karlberg

Felicia Posluk

Ludwig Forsberg

Handledare : Jonas Wallgren Examinator : Kristian Sandahl

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

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

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

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

Copyright

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

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

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

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Lucia Choura Casper Jensen Taha Unalan Kevin Bärudde Hannes Westander Filip Karlberg Felicia Posluk Ludwig Forsberg

Sammanfattning

Denna rapport är ett kandidatarbete vid Linköpings Universitet i kursen TDDD96. Rap-porten är baserad på ett projekt som gruppen har utfört där de har byggt ett chattsystem åt en extern kund, Region Östergötland. Chattsystemet som byggdes var en chattapplika-tion som kan användas mellan patienter och vårdpersonal, även en chattbott användes. Chattapplikationen fokuserade på hur förgrening av konversationer kunde ske på ett smi-digt och användarvänligt sätt samt att vårdpersonalen kan markera viktiga meddelanden. I projektet användes Scrum vilket är ett ramverk som bygger på utveckling som sker i sprintar, dagliga möten samt utvärdering efter varje sprint. Sist i rapporten ligger ett antal olika individuella bidrag som varje projektmedlem har gjort.

Kandidatgruppen vill tacka examinatorn Kristian Sandahl samt gruppens handledare Jonas Wallgren och resten av kursledningen för all hjälp under projektet. Gruppen vill även tacka Region Östergötland och speciellt gruppens kontaktpersoner Magnus Stridsman, Erik Rei-nicke och Erik Sundvall för ett mycket trevligt samarbete och en intressant uppgift.

Innehåll

2.2 Tidigare erfarenheter . . . 4

3 Teori 5 3.1 Programspråk och ramverk . . . 5

3.1.1 JavaScript . . . 5 3.1.2 TypeScript . . . 5 3.1.3 HTML . . . 5 3.1.4 CSS . . . 6 3.1.5 Flask . . . 6 3.1.6 React . . . 6 3.2 Arbetsprocesser . . . 6 3.2.1 Scrum . . . 6 3.2.2 Trello . . . 6 3.2.3 Discord . . . 7 3.2.4 CMMI . . . 7 3.2.5 Git . . . 7 3.2.6 GitHub . . . 7 3.3 Testverktyg . . . 7 3.3.1 Pytest . . . 7 3.3.2 pytest-cov . . . 8 3.3.3 Flake8 . . . 8 3.3.4 Jest . . . 9 4 Metod 11

4.1.2 GitHub . . . 11

4.1.3 Discord . . . 12

4.1.4 Parprogrammering . . . 12

4.1.5 Roller . . . 12

4.1.6 Systemanatomi . . . 13

4.2 Metod för att fånga erfarenheter . . . 13

4.3 Kvalitetscoachning . . . 13

4.3.1 Process i fokus . . . 13

4.3.2 Metrikprogram . . . 13

4.4 Informationsinsamling . . . 14

4.4.1 Föreläsningar och seminarier . . . 14

4.4.2 Kundmöten . . . 14

5 Resultat 15 5.1 Systembeskrivning . . . 15

5.1.1 Systemet och dess moduler . . . 15

5.1.1.1 Interaktionsmodulen . . . 15 5.1.1.2 Kommunikationsmodulen . . . 17 5.1.1.3 Lagringsmodulen . . . 18 5.1.1.4 Chattbott . . . 19 5.1.2 Systemanatomi . . . 19 5.1.3 Produktutvärdering . . . 20 5.2 Prototyper . . . 21

5.3 Vad har kunden för värde hos det som skapats? . . . 22

5.4 Dokument som har producerats . . . 22

5.5 Processbeskrivning . . . 23 5.5.1 Mätning av kvalitetskrav . . . 23 5.5.2 Beskrivning av mätningar . . . 23 5.5.3 Dokumentation av process . . . 23 5.5.4 Förbättring av process . . . 23 5.5.5 Utvärdering av förbättringen . . . 24 5.6 Gemensamma erfarenheter . . . 24 5.6.1 Projektorganisation . . . 24 5.6.2 Tekniska erfarenheter . . . 26 5.6.3 Kundkontakt . . . 26

5.7 Översikt över individuella bidrag . . . 26

5.7.1 Lucia Choura - Chattbottar med fokus på användarupplevelse . . . 26

5.7.2 Casper Jensen - Studenters åsikter om digital kommunikation med vårdpersonal . . . 26

5.7.3 Taha Unalan - Användandet av Scrum i vårt kandidatprojekt . . . 27

5.7.4 Kevin Bärudde - Agila arbetsmetoder för mjukvaruprojekt-teams . . . . 27

5.7.5 Hannes Westander - Parprogramering . . . 27

5.7.6 Filip Karlberg - Användning av prototyper för utveckling av webbap-plikation . . . 27

5.7.7 Felicia Posluk - Kommunikation på projektmöten vid distansarbete . . . 27

5.7.8 Ludwig Forsberg - Jämförelse av TypeScript och JavaScript i webbut-veckling . . . 28

6 Diskussion 29 6.1 Resultat . . . 29

6.1.2 Lyckades gruppen att förbättra eller forsätta med något från tidigare

projekt? . . . 30

6.1.3 Vilka är de viktigaste lärdomar gruppen har fått från projektet? . . . 30

6.2 Metod . . . 30 6.2.1 Utvecklingsmetoder . . . 30 6.2.1.1 Scrum . . . 30 6.2.1.2 Trello . . . 31 6.2.1.3 Github . . . 31 6.2.1.4 Implementation . . . 31 6.2.1.5 Systemanatomi . . . 31 6.2.1.6 Alternativa implementationssätt . . . 32

6.2.2 Metod för att fånga erfarenheter . . . 32

6.2.3 Kvalitetscoachning . . . 32

6.3 Arbetet i vidare sammanhang . . . 32

6.3.1 Hållbarhetsaspekter . . . 32

6.3.2 Etiska aspekter . . . 32

6.4 Förslag på vidareutveckling av produkten . . . 33

7 Slutsats 34 7.1 Återkoppling till frågeställningar . . . 34

7.1.1 Hur kan ett chattsystem implementeras för att skapa värde för Region Östergötland? . . . 34

7.1.2 Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara intressanta för framtida projekt? . . . 34

7.1.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . 35

7.1.4 Vilka likheter och skillnader finns mellan chattbotten i detta projekt och chattbottar på marknaden? . . . 35

7.2 Uppfyllande av syfte . . . 35

7.3 Viktigaste lärdomar . . . 35

A Lucia Choura - Chattbottar med fokus på användarupplevelse 36 A.1 Inledning . . . 36 A.1.1 Syfte . . . 36 A.1.2 Frågeställning . . . 36 A.2 Bakgrund . . . 36 A.3 Definitioner . . . 37 A.3.1 Chattbott . . . 37 A.3.2 Användarupplevelse . . . 37 A.4 Teori . . . 37 A.4.1 Enkätundersökning . . . 37 A.5 Metod . . . 37 A.5.1 Litteraturstudie . . . 38 A.5.2 Enkätundersökning . . . 38 A.6 Resultat . . . 39

A.6.1 Vilka för- och nackdelar finns det att ha en chattbott från ett sjukvårds-perspektiv? . . . 39

A.6.2 Vilka egenskaper anses vara viktiga hos en chattbott (vars syfte är att hjälpa till inom ett designerat område) för att kunna bidra till använ-darupplevelsen? . . . 40

A.7 Diskussion . . . 42

A.7.1 Vilka för- och nackdelar finns det att ha en chattbott från ett sjukvårds-perspektiv? . . . 42

darupplevelsen? . . . 43

A.8 Slutsatser . . . 44

A.8.1 Vilka för- och nackdelar finns det att ha en chattbott ur ett sjukvårds-perspektiv? . . . 44

A.8.2 Vilka egenskaper anses vara viktiga hos en chattbott (vars syfte är att hjälpa till inom ett designerat område) för att kunna bidra till använ-darupplevelsen? . . . 44

B Casper Jensen - Studenters åsikter om digital kommunikation med vårdpersonal 45 B.1 Inledning . . . 45 B.1.1 Syfte . . . 45 B.1.2 Frågeställning . . . 45 B.2 Bakgrund . . . 45 B.3 Teori . . . 46 B.4 Metod . . . 46 B.4.1 Enkätundersökning . . . 46 B.4.2 Litteraturstudie . . . 46 B.5 Resultat . . . 47 B.5.1 Resultat av enkätundersökning . . . 47 B.5.2 Resultat av litteraturstudie . . . 49 B.6 Diskussion . . . 50 B.6.1 Resultat av enkätundersökning . . . 50 B.6.2 Resultat av litteraturstudie . . . 51 B.6.3 Metod . . . 51 B.7 Slutsatser . . . 52

C Taha Unalan - Användandet av Scrum i vårt kandidatprojekt 53 C.1 Inledning . . . 53 C.1.1 Syfte . . . 53 C.1.2 Frågeställning . . . 53 C.2 Bakgrund . . . 53 C.3 Teori . . . 54 C.3.1 Scrum . . . 54 C.3.2 Scrumlag . . . 54 C.3.3 Händelser . . . 54 C.3.3.1 Sprint . . . 54 C.3.3.2 Sprintplanering . . . 54 C.3.3.3 Dagliga scrummöten . . . 54 C.3.3.4 Sprintrecension . . . 54 C.3.3.5 Sprintåterblick . . . 54 C.3.4 Artefakter . . . 55 C.3.4.1 Produktbacklogg . . . 55 C.3.4.2 Sprintbacklogg . . . 55 C.3.5 Trello . . . 55 C.4 Metod . . . 55 C.4.1 Enkätundersökning . . . 55 C.5 Resultat . . . 55 C.5.1 Roller . . . 55 C.5.2 Aktiviteter . . . 56 C.5.3 Trello . . . 56 C.5.4 Enkätresultat . . . 56

C.6 Diskussion . . . 59 C.6.1 Roller . . . 59 C.6.2 Aktiviteter . . . 59 C.6.3 Trello . . . 59 C.6.4 Metod . . . 59 C.7 Slutsatser . . . 59

C.7.1 Hur tillämpades Scrum i vårt projekt? . . . 60

C.7.2 Upplevdes det gynnsamt att använda sig av Scrum? . . . 60

D Kevin Bärudde - Agila arbetsmetoder för mjukvaruprojekt-teams 61 D.1 Inledning . . . 61 D.1.1 Syfte . . . 61 D.1.2 Frågeställning . . . 61 D.1.3 Avgränsningar . . . 61 D.2 Teori . . . 62 D.2.1 Iterativ utveckling . . . 62 D.2.2 Agil utveckling . . . 62 D.2.3 Scrum . . . 62 D.3 Metod . . . 62 D.3.1 Enkätundersökning . . . 62 D.3.2 Litteraturstudie . . . 63 D.4 Resultat . . . 63 D.4.1 Litteraturstudie . . . 63 D.4.2 Helhetsuppfattning om sprintar . . . 64 D.4.3 Agilt bräde . . . 65 D.4.4 Återblicksmöte . . . 65 D.4.5 Parprogrammering . . . 66 D.4.6 Scrum standup . . . 66 D.4.7 Åsikter från teamet . . . 67 D.5 Diskussion . . . 67 D.6 Slutsatser . . . 68

D.6.1 Skiljer sig åsikterna om arbetsmetoderna mellan teamet och hur det ser ut i andra studier? . . . 68

D.6.2 Vilka generella synpunkter har teamet, och hur siljer detta sig från hur det ser ut i andra studier? . . . 68

E Hannes Westander - Parprogramering: effektivt eller inte? 69 E.1 Inledning . . . 69 E.1.1 Syfte . . . 69 E.1.2 Frågeställning . . . 69 E.1.3 Begränsningar . . . 69 E.2 Bakgrund . . . 70 E.3 Teori . . . 70

E.3.1 Agila metoder . . . 70

E.3.2 Parprogrammering . . . 70

E.4 Metod . . . 70

E.5 Resultat . . . 70

E.5.1 Are Two Heads Better than One? On the Effectiveness of Pair Program-ming . . . 71

E.5.2 Pair Programming vs. Solo Programming: What Do We Know After 15 Years of Research? . . . 71

E.5.3 Strengthening the case for pair programming . . . 72

F Filip Karlberg - Användning av prototyper för utveckling av webbapplikationer 74 F.1 Inledning . . . 74 F.1.1 Syfte . . . 74 F.1.2 Frågeställning . . . 74 F.2 Avgränsningar . . . 74 F.3 Bakgrund . . . 75 F.4 Teori . . . 75 F.4.1 Prototyper . . . 75 F.4.2 Scrum . . . 75 F.5 Metod . . . 75 F.5.1 Litteraturstudie . . . 75 F.6 Resultat . . . 75 F.6.1 Resultat Litteraturstudie . . . 75 F.6.1.1 Temporära prototyper . . . 76 F.6.1.2 Evolutionära prototyper . . . 76

F.6.2 Resultat prototyper i vårt projekt . . . 76

F.7 Diskussion . . . 77

F.7.1 Diskussion metod . . . 78

F.7.2 Diskussion resultat . . . 78

F.7.3 Vad är syftet med temporära och evolutionära prototyper? . . . 80

F.7.4 Hur användes prototyper i vårt projekt? . . . 80

F.7.5 Hur fungerar det att använda prototyper i samband med agila metoder så som Scrum? . . . 80

F.8 Slutsatser . . . 80

F.8.1 Vad är syftet med temporära och evolutionära prototyper? . . . 80

F.8.2 Hur användes prototyper i vårt projekt? . . . 80

F.8.3 Hur fungerar det att använda prototyper i samband med agila metoder så som Scrum? . . . 80

G Felicia Posluk - Kommunikation på projektmöten vid distansarbete 81 G.1 Inledning . . . 81 G.1.1 Syfte . . . 81 G.1.2 Frågeställning . . . 81 G.2 Avgränsningar . . . 82 G.3 Bakgrund . . . 82 G.4 Teori . . . 82 G.4.1 Discord . . . 82

G.4.2 Viktiga faktorer inom projektarbete . . . 82

G.4.3 Grupputveckling . . . 82

G.5 Metod . . . 83

G.5.1 Litteraturstudier . . . 83

G.5.2 Enkät om kommunikation och grupputveckling . . . 83

G.6 Resultat . . . 84

G.6.1 Resultat från litteraturstudier . . . 84

G.7 Diskussion . . . 85

G.7.1 Diskussion kring urvalsgruppen . . . 85

G.7.2 Diskussion kring kommunikation . . . 85

G.7.3 Diskussion kring grupputveckling . . . 86

G.8 Slutsatser . . . 87

H.1 Inledning . . . 89

H.1.1 Syfte . . . 89

H.1.2 Frågeställning . . . 89

H.2 Bakgrund . . . 90

H.3 Teori . . . 90

H.3.1 Dynamisk och statisk typning . . . 90

H.3.2 JavaScript . . . 90 H.3.3 TypeScript . . . 90 H.4 Metod . . . 90 H.5 Resultat . . . 90 H.6 Diskussion . . . 91 H.6.1 Resultat . . . 91 H.6.2 Metod . . . 92 H.7 Slutsatser . . . 92 I Bilagor 94 Litteratur 99

3.1 Pytest exempel. . . 7

3.2 Pytest resultat. . . 8

3.3 Pytest-cov resultat. . . 8

3.4 Flake8 resultat. . . 9

3.5 Jest exempel. . . 9

3.6 Jest resultat exempel. . . 10

5.1 Startsidan . . . 16

5.2 Val av kategorier delen av sidan . . . 16

5.3 Chatten från patientens synvinkel . . . 17

5.4 Chatten från personalens synvinkel . . . 17

5.5 En översiktlig bild av kommunikationsmodulen. . . 18

5.6 Relations diagram av databasen . . . 18

5.7 Systematonomin . . . 19

5.8 Fas 1 prototyp. . . 21

5.9 Fas 2 prototyp. . . 22

5.10 Svar på frågan “Jag tycker att de förra återblicksmötet hade en positiv påverkan på sprinten”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver medelvärdet för sprinten. . . 25

5.11 Svar på frågan “Jag tycker att agilbrädet (Trello) har använts som planerat”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver medelvärdet för sprinten. . . 25

5.12 Svar på frågan “Jag tycker att de dagliga mötena har fungerat väl”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver medelvärdet för sprinten. . . 26

A.1 Andelen deltagare som har stött på en chattbott tidigare. . . 40

A.2 Deltagarnas svar på hur viktigt det är att chattbotten besvarar relevanta frågor. Skala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 40

A.3 Deltagarnas svar på hur viktigt det är att chattbotten konsekvent använder rätt grammatik och stavning. Skala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 41

A.4 Deltagarnas svar på hur viktigt det är att chattbotten kan flera språk utöver svens-ka och engelssvens-ka. Ssvens-kala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 41

A.5 Deltagarnas svar på hur viktigt det är att chattbotten är artig. Skala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 41

A.6 Deltagarnas svar på hur viktigt det är att chattbotten bidrar med intressant infor-mation om samtalsämnet. Skala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 42

A.7 Deltagarnas svar på hur viktigt det är att chattbotten utvecklar en relation med användaren. Skala 1-5 där 1 är Oviktigt och 5 är Mycket viktigt. . . 42

B.1 Skala 1-5 där 1 är håller inte alls med och 5 är håller med fullständigt. . . 47

B.3 På vilket sett man brukar ta kontakt med vården. Här fanns ett övrigt alternativ

där man kunde ange egna svar vilket de odefinierade sektorerna är. . . 48

B.4 Vid frågor angående milda symptom på sig själv, hur hade man då kontaktat vår-den. Här fanns ett övrigt alternativ där man kunde ange ett eget svar vilket de odefinierade sektorerna är. . . 49

B.5 Vid frågor angående milda symptom på en närstående, hur hade man då kontak-tat vården. Här fanns ett övrigt alternativ där man kunde ange ett eget svar vilket de odefinierade sektorerna är. . . 49

C.1 Hur projektgruppen upplevde Scrum för projektet . . . 56

C.2 Om projektgruppen upplevde sprint och produktbackloggen positivt . . . 57

C.3 Projektgruppens upplevelse till hur Scrums implementation följdes inom projektet. 57 C.4 Hur projektgruppen upplevde att planeringen följdes . . . 58

C.5 Kände projektgruppen att en annan agil arbetsmetod hade fungerat bättre . . . 58

D.1 Sprint . . . 64

D.2 Agilt bräde . . . 65

D.3 Återblicksmöte . . . 65

D.4 Parprogrammering . . . 66

D.5 Scrum standup . . . 66

F.1 Pappersprototyp av förgrening (Kevin) . . . 77

F.2 Pappersprototyp av påbörja konversation (Filip) . . . 78

F.3 Pappersprototyp iteration 2 av förgrening (Lucia) . . . 79

Definitioner

Här definieras begrepp som används i dokumentet. • 1177 - En vårdguide från Sveriges regioner.

• Förgrening - Någonting som grenar ut från en original punkt.

• W3C - World Wide Web Consortium, en internationell församling som sätter upp en standard för nätet.

• HTML - Hyper Text Markup Language. • CSS - Cascading Style Sheet.

• CMMI - Capability Maturity Model Integration. • PPQA - Process and Product Quality Assurance.

I dagsläget finns det möjlighet att ringa till 1177 Vårdguiden för att få hjälp från sjukvårds-personal, dygnet runt, utan tidsbokning [21]. Dock kan denna tjänst ibland vara belastad av långa telefonköer. Speciellt under Corona-pandemin har många ringt in i oro för viruset vilket ökat väntetiderna markant [6]. Det är väsenligt för alla att enkelt och snabbt kunna få tillgång till sjukvårdspersonal för råd kring medicinska problem. Det kan ibland vara irriterande att vänta i en telefonkö för att få hjälp. Då skulle det vara smidigare att chatta istället. Därför ser Region Östergötland möjligheten att införa digital kommunikation i vården med hjälp av ett chattsystem. Även chattbottar kan användas för att minska belastningen på personalen. I denna rapport beskrivs det projekt vars avsikt är att undersöka hur användningen av en chat-tapplikation tillsammans med en chattbot förbättrar patient- och personalkommunikationen i vården.

1.1

Motivering

Denna rapport handlar om ett programvaruutvecklingsprojekt med leverans av en program-vara till en extern kund. Kunden för projektet var Region Östergötland och projektet gick ut på att skapa en prototyp av ett chattsystem mellan vårdpersonal, patienter och en chatt-bott. Prototypen utvecklades i utforskningssyfte och kan användas som inspirationskälla för kunden Region Östergötland vid utveckling av ett eget chattsystem. I dagsläget har 1177 Vårdguiden en vårdtjänst dit man kan ringa och få rådgivning över telefon av en sjukskö-terska [21]. Detta är främst för intern kommunikation men det finns också andra och likande digitala kommunikationsformer som är etablerade. Detta kan till exempel vara chattkonver-sationer med ungdomsmottagning eller appen Din vård [5]. Det som saknas idag är ett mer komplett system för digital chatt och kommunikation mellan vårdpersonal och patienter. Det vill säga ett komplement till att ringa 1177 och därmed minska den belastningen över telefon. Dessutom kan ett chattsystem tillföra nya funktionaliteter mellan patient och vårdpersonal. Ett exempel är konversationsförgrening där en sjuksköterska kan bjuda in en specialist till konversationen för att hantera patientärendet.

1.2. Syfte

1.2

Syfte

Syftet med projektet var att leverera en prototyp av ett chattsystem åt Region Östergötland som ska kunna förbättra vårdrelaterad kommunikation för patienter och vårdpersonal. Kon-kret innebär det att denna prototyp ska bli ett verktyg att utgå från vid en eventuell imple-mentation av ett liknande större system.

1.3

Frågeställningar

Denna rapport svarar på följande frågeställningar:

1. Hur kan ett chattsystem implementeras inom vården för att skapa värde för Region Östergötland?

2. Vilka erfarenheter kan dokumenteras från detta programvaruprojekt som kan vara in-tressanta för framtida projekt?

3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi?

4. Vilka likheter och skillnader finns mellan chattbotten i detta projekt och chattbottar på marknaden?

1.4

Avgränsningar

Projektets fokus ligger på patientens användarupplevelse av chattsystemet och är endast in-riktat på sjukvården i Sverige. Chattsystemet har implementerats som en webbsida vilket innebär att systemet enbart kan nås via en webbserver. Systemet är inte begränsat till en spe-cifik webbläsare och projektet ska säkerställa att produkten fungerar på populära webbläsare, som till exempel Google Chrome.

1.5

Kontext

Denna rapport har skrivits som en del av kursen TDDD96, kandidatprojekt i programvaruut-veckling, vid Linköpings universitet. Gruppen bestod av åtta studenter som har utvecklat programvara till en extern kund. Projektet hade en tidsbegräsning på 400 timmar per person under vårterminen 2021.

Detta kapitel beskriver bakomliggande information som är relevant för projektet och vilka förutsättningar som finns för att projektgruppen ska genomföra projektet.

2.1

Kunden Region Östergötland

Region Östergötaland är ett landsting på 450 tusen invånare. Deras mest omfattande upp-drag är att erbjuda invånarna i Östergötaland en bra hälso- och sjukvård, där även tandvård ingår. Sjukvården består av primärvård, närsjukvård och specialistskjuvård. Det finns cirka 40 vårdcentraler som är antigen regiondrivna eller privata. Uppdraget drivs i länsdelarna Motala, Linköping, Norrköping och Finspång.

2.2

Tidigare erfarenheter

Medlemmarna i gruppen var studenter i år 3 på civilingenjörsprogrammen i datateknik och mjukvaruteknik vid Linköpings universitet. Detta innebar att alla medlemmar hade goda kunskaper inom programmering och var utbildade inom mjukvaruutveckling. Alla medlem-mar hade dessutom erfarenhet av att jobba med programutvecklingsprojekt i tidigare kurser. Gruppens generella erfarenheter av tidigare utvecklingsprojekt var goda och många medlem-mar hade relevanta förbättringspunkter som togs i akt med detta projekt. Ett stort fokus var på kommunikation mellan gruppmedlemmarna och Git struktur. Detta minimerade otydlig-heter och underlättade debuggning.

3

Teori

I detta kapitel förklaras den bakomliggande teorin. Detta kan vara saker som verktyg eller processer som använts under projektets gång.

3.1

Programspråk och ramverk

I denna sektion ges en översikt över de olika programspråken och ramverken som tas upp i rapporten. Testningsverktygen beskrivs inte här utan i sektion 3.3.

3.1.1

JavaScript

JavaScript hanterar logikdelen av en hemsida på klientsidan. JavaScript har som huvudsyfte att göra hemsidan responsiv för användaren. Ifall användaren trycker på en knapp på hem-sidan är det JavaScript-kod som körs och bestämmer vad som ska hända. JavaScript har, som de flesta programspråken; variabler, klasser, funktioner, aritmetik med mera. Det är ett dyna-miskt programspråk, vilket innebär att språket kompileras under körtid. [35]

JavaScript är definierat som en standard för webbutveckling av W3C. [13]

3.1.2

TypeScript

TypeScript bygger på JavaScript genom att lägga till hårt typade variabler. TypeScript an-vänds för att säkerställa att den utvecklade koden följer förväntat beteende. TypeScript kom-pileras till JavaScript som är den faktiska koden som körs på hemsidan. Vid kompilering kan det uppstå kompileringsfel som indikerar att något i koden kan ge felaktigt beteende vid kör-ning. Ifall koden hade varit utvecklad i JavaScript hade dessa fel varit svårare att upptäcka då de oftast endast upptäcks vid körning. Då JavaScript är dynamiskt och ofta accepterar kod som skulle genererat ett fel i andra språk kan det vara svårt att hitta problem i koden med ren JavaScript-utveckling. Det är dessa typer av situationer TypeScript är skapad för att undvika. [18]

3.1.3

HTML

HTML är den mest grundläggande byggstenen i webbutveckling. Språket beskriver struktu-ren och flödet av de olika objekten på hemsidan. HTML använder sig av så kallade taggar

för att särskilja olika typer av objekt. Det går också att lägga till attribut med olika värden på objekten för att få objektspecifika beteenden. Detta kan till exempel vara attributet “id” som gör det enkelt att komma åt objekten från JavaScript. [34]

3.1.4

CSS

CSS är ett stilspråk som beskriver hur de olika objekten ska presenteras på en hemsida skri-ven i HTML. I CSS kan till exempel färgscheman, position och animationer för olika objekt specificeras. Språket applicerar egenskaper på rätt objekt genom identifiering av klasser, id och tagg. Alltså är det till exempel möjligt att sätta generella egenskaper för alla objekt av samma typ eller specificera egenskaperna för ett objekt med ett speciellt id. [33]

3.1.5

Flask

Flask är ett Python-ramverk som är gjort för att enkelt sätta upp en webbapplikation. [44] Flask är ett mikroramverk vilket betyder att det har minimalt antal beroenden till andra ex-terna bibliotek. Fördelar med ett mikroramverk är att det är resursvänligt och risken för sä-kerhetsbuggar minskar avsevärt. Nackdelar är att ramverket kan behöva flera plugins och beroenden som måste läggas till.[27]

3.1.6

React

React är ett JavaScript-bibliotek som används för att enkelt bygga interaktiva användargräns-snitt. React är komponentbaserat vilket betyder att webbsida byggs upp med en mer tradi-tionell objekt orienterad struktur för att förenkla uppsättningen av webbsida. [22]

3.2

Arbetsprocesser

I denna sektion så kommer arbetsmetoderna som använts under projektets gång beskrivas.

3.2.1

Scrum

Scrum är ett ramverk utvecklat för kortare projekt. Ramverket fokuserar på att bryta ner ar-betet till mindre aktiviteter. Aktiviteterna hamnar i kategorien Backlog vilket innefattar alla aktiviteter som inte har påbörjats. Aktiviteterna kan tas upp av alla gruppmedlemmar och kan placeras i kategorierna påbörjad, sprintbacklog och avslutad sprint. Sprint är det som gör ramverket unikt. Det är nämligen arbetsprocessen som upprepas kontinuerligt under projek-tets gång fram till slutleveransen. Varje sprint innefattar en nedbrytningsprocess av projekprojek-tets mål för att skapa mindre aktiviteter, sortering av avklarade aktiviteter och en utvärdering-process. Utvärderingen är ett tillfälle för återkoppling för att förbättra nästkommande sprint. [49]

3.2.2

Trello

Realiseringen av Scrum sker med hjälp av online-verktyget Trello. Trello möjliggör skapan-det av tavlor och kort. Korten placeras inuti tavlorna och används som en representation av arbetsuppgifter inom projektet. Tavlorna används för att kategorisera korten enligt nuvaran-de status. De olika statusen är anpassanuvaran-de enligt Scrum-monuvaran-dellen, därför finns nuvaran-det en tavla för Backlog, Sprintbacklog, Pågående och en tavla för varje föregående sprint. Onlineverkty-get förenklar och förtydligar arbetet inom projektet. Varje kort kan kategoriseras med hjälp av färgkodade-etiketter och korten kan tilldelas till olika gruppmedlemmar. Trello skapar en översiktligt bild av arbetsflödet inom projektet samtidigt som detaljerade aktiviteter enkelt kan delegeras mellan gruppmedlemmar.

3.3. Testverktyg

3.2.3

Discord

Discord är ett gratis chatt-verktyg som används av över 150 miljoner användare. Discord används för att förenkla kommunikation i stora grupper. [17]

3.2.4

CMMI

CMMI är ett akronym för de engelska orden Capability, Maturity, Model och Integration som betyder förmåga, mognad, modellering och integration. Det är ett ramverk som används för att förbättra arbetsprocesser och öka effektiviteten inom projektarbeten samt hos organisa-tioner. CMMI består av fem mognadsnivåer som används som referenspunkter för organi-sationer och projektarbeten. Vid nivå ett är mognadsnivån låg och därmed är processerna opålitliga, inte kontrollerade och reaktiva. Nivå två är mer kontrollerad, arbetsprocesserna är mer planerade och det finns en kontroll inom projektarbeten. Vid nivå tre finns det en ökad förståelse för arbetsprocesserna, olika standardiseringsätt används vid utveckling och pro-cesserna är definierade på en organisationsnivå. Nivå fyra fokuserar på att arbetsprocesser kontrolleras med hjälp av kvalitativa och statistiska tekniker. Den högsta nivån, nivå fem, fokuserar på innovation och vidareutveckling. Här utvecklas arbetsprocesser kontinuerligt med inkrementella förbättringar. Mognadsnivå ett är en naturlig startnivå för ett nystartat företag, nivå fem är vad stora och välorganiserade företag strävar efter. [29]

3.2.5

Git

Git är ett online-verktyg som ofta används i utveckling av projekt. Programmet tillåter ut-vecklare att testa och strukturera kod under implementering. Verktyget är en distribuerad versionshanterare som är designad för både små och stora projekt [23]. Det finns ett flertal plattformar som baseras på Git så som GitHub och GitLab. [51].

3.2.6

GitHub

GitHub är en plattform som underlättar användningen av Git. Plattformen är väl etablerad och populär med miljontals användare och Git-repon [26]. Att använda plattformen är helt gratis för vanliga användare och fungerar på likande sätt som andra plattformar som använ-der Git, till exempel GitLab [51].

3.3

Testverktyg

I detta projekt har testverktygen Pytest, Pytest-cov, Flake8 för Python och Jest för Javascript använts för att förenkla testningen och verifiera implementationen.

3.3.1

Pytest

Pytest är ett testverktyg för att förenkla testningen av Pythonkod samt att visualisera resulta-tet från testningen. [54] Figuren 3.1 visar ett enkelt exempel på hur funktionen sum testas.

1 def sum(a, b):

2 return a + b

3

1 from sum import sum

2 def test_sum():

3 assert sum(1, 2) == 3

4

Ett test körs genom att skriva Pytest i terminalen i mappen där koden finns. Pytest kommer att köra alla tester i filer som följer namnkonventionen test_*.py eller *_test.py där testerna namn som körs måste motsvara test_*. Efter ett test körs fås ett resultat i samma terminal. Figur 3.2 visar hur ett sådant resultat kan se ut.

Figur 3.2: Pytest resultat.

3.3.2

pytest-cov

Pytest-cov är ett plugin som bygger på Pytest för att förbättra visualiseringen av resultatet av ett test. [28] Testningen fungerar på liknande sätt som Pytest men testningen startas med Pytest –cov. Figur 3.3 visar ett exempel hur ett sådant resultat ser ut.

Figur 3.3: Pytest-cov resultat.

3.3.3

Flake8

Flake8 är ett testverktyg som testar Python-kod för syntaxfel och programmeringsstil från PyCodeStyle-projektet [9]. Testet körs genom att skriva flake8 i terminalen där filerna finns. Resultatet från ett flake8-test kan se ut som figuren 3.4.

3.3. Testverktyg

Figur 3.4: Flake8 resultat.

3.3.4

Jest

Jest är ett JavaScript-ramverk som gör det enklare att skriva tester för JavaScript-kod. [30] Figuren 3.5 visar ett enkelt exempel på hur funktionen sum testas.

1 function sum(a, b) {

2 return a + b;

3 }

4 module.export = sum;

5

1 const sum = require(’./sum’);

2

3 test(’adds 1 + 2 to equal 3’, () => {

4 expect(sum(1, 2)).toBe(3);

5 });

6

Figur 3.5: Jest exempel.

Ett Jest-test kan köras genom att skriva npm test i terminalen. Jest kommer att köra alla tester som följer namnkonventionen *.test.js. Efter testet så fås resultatet i terminalen. Ett exempel på hur ett resultat från ett test kan se ut finns i figur 3.6.

4

Metod

I detta kapitel beskrivs de metoder som gruppen har använt under genomförandet av pro-jektet.

4.1

Utvecklingsmetod

Den valda utvecklingsmetoden för projektet var Scrum. Scrum är en iterativ arbetsprocess för systemutveckling och används i stor omfattning inom teknikbranschen. Online-verktygen Trello och Github användes som hjälpmedel för att verkställa metoden. Det hjälper projekt-gruppen att ha en överblick och uppskattning av arbetsbelastningen vid varje iteration.

4.1.1

Scrum

Under projektets gång användes Scrum kontinuerligt. Gruppen planerade tvåveckorssprin-ter med leverans till kunden och ett åtvåveckorssprin-terblicksmöte i slutet av varje sprint. Istället för dagli-ga Scrummöten, som metodiken förespråkar, blev det möten varannan arbetsdag under den första halvan av projektet. Denna schemaläggning gjordes för att anpassa metoden till grupp-medlemmarnas schema. Möten var inplanerade på måndag, onsdag och fredag varje vecka. Under andra halvan av projektet börjades Scrummötena hållas varje arbetsdag för att anpas-sa till förändrat schema. På varje möte gick varje medlem igenom vad hen hade gjort sedan det senaste mötet, vad hen skulle jobba med tills nästa möte och huruvida hen hade eller såg eventuella problem. För att organisera och illustrera vad gruppmedlemmarna skulle jobba med under varje sprint användes ett agilt bräde (som implementerades i Trello). I detta brä-de skrevs aktiviteterna för projektet och flyttabrä-des mellan olika kolumner beroenbrä-de på brä-deras status.

4.1.2

GitHub

Vid projektutvecklingen användes GitHub som versionshanterare. I tidigare studentprojekt har Gitlab använts men gruppen beslutade om att byta till GitHub. Detta gjordes både för att kunden bad om det och för att gruppens serverimplementation passade bättre för GitHub. Arbetsgången för Git organiserades på följande sätt: Alla nya features fick en egen gren och

när de var färdiga användes Git-merge och Git-push för att flytta dessa features till huvudgre-nen om koden klarade testen. Inför slutet av varje sprint med kodleverans flyttades koden till en leveransgren (release branch) efter många tester.

4.1.3

Discord

Gruppen använde sig av discord som komunicationsverktyg under projektets gång. Discord tillåter skapandet av flera text och röst kanaler där konversationer kan pågå parallellt. Grup-pen skapade många text kanaler som kan grupperas i tre grupper: info, allmänt och chatt. I info så sparades bara viktig information och ingen konversation var tillåtet. Under allmänt så pågick alla diskussioner som handlade om projektet. Medan i chatt så pågick alla konver-sationer som inte har något med projektet att göra.

4.1.4

Parprogrammering

Gruppen använde parprogrammering vid kodimplementation för att öka kvaliteten på ko-den. Parpgroammeringen användes även för att öka trivseln i gruppen då hela gruppen fö-redrog att jobba i par så ofta det gick.

4.1.5

Roller

• Teamledare: Ludwig Forsberg

Teamledaren hade som uppgift att representera gruppen och ha en översiktlig syn på gruppmedlemmarnas arbetsområden. Teamledaren skulle också styra upp dialoger och lösa konflikter mellan gruppmedlemmar. En ytterligare uppgifter var att se till att grup-pen håller mål och milstolpar.

• Utveklingsledare: Felica Posluk

Utvecklingsledaren hade huvudansvar för implementationen av arkitektstrukturen på detaljnivå.

• Kvalitetssamordnare: Hannes Westander

Kvalitetssamordnaren hade som uppgift att sätta prioriteter på aktiviteterna och se till att den färdiga produkten mötte kundens förväntningar.

• Arkitekt: Taha Unalan

Arkitekten hade huvudansvaret för modulerna och deras relation till varandra. Arki-tekten hade också ansvar för arkitekturdokumentationen samt hade mest makt vid val av övergripande tekniklösningar.

• Testledare: Kevin Bärudde

Testledaren hade som uppgift att översätta kraven till testbara parametrar samt att se till att alla krav blir testade och att dessa tester blev dokumenterade.

• Dokument- och konfigurationsansvarig: Casper Jensen

Dokument- och konfigurationsansvarig hade som uppgift att tillhandahålla diverse do-kument, skapa mallar samt definiera Git-strukturen.

• Analysansvarig: Lucia Choura

Analysansvarig hade som uppgift att hålla den primära kontakten med kunden samt såg till att kundens krav uppnåddes. En ytterligare uppgift var att framföra viktig in-formation från kunden till resterande gruppmedlemmar.

4.2. Metod för att fånga erfarenheter

• UI/UX ansvarig: Filip Karlberg

UI/UX-ansvarig hade huvudansvaret för all front-end-utveckling och såg till att den färdiga produkten var användarvänlig.

4.1.6

Systemanatomi

Gruppen använde en systemanatomi för att få en överblicklig syn av systemet. Systemana-tomi är en acyklisk graf där varje nod är en funktion eller egenskap i systemet. AnaSystemana-tomin byggdes upp tidigt i projektutvecklingen för att skapa förståelse och förväntningar av slut-produkten.

4.2

Metod för att fånga erfarenheter

I slutet av varje sprint hade gruppen ett återblicksmöte och fyllde i en anonym enkät. Resulta-tet från enkäten användes som en bas för återblicksmöResulta-tet. På detta möte diskuterade gruppen vad som hade fungerat bra eller dåligt under den avslutade sprinten. Gruppen diskuterade också planen för nästa sprint och om något borde göras annorlunda. Allt detta sammanfatta-des i en rapport som delasammanfatta-des med gruppen.

4.3

Kvalitetscoachning

Under projektets gång anordnades ett flertal coachningsmöten i samarbete med studenter i kursen TDDE46. På dessa möten blev två representanter för gruppen coachade i hur de ska skriva en kvalitetsplan samt hur de ska dokumentera process i fokus, metrikprogram och process förbättring i relation till PPQA från CMMI. Som representanter för gruppen sändes kvalitetssamordnaren och testansvarig. På dessa möten närvarade även representanter från gruppen PUM 1. Kombinationen av studenter från andra grupper och studenter från tidigare årskursers projektgrupper var en bra grund för givande diskussioner om projektarbetet.

4.3.1

Process i fokus

Under coachningen så bestämdes det att gruppen skulle fokusera på att analysera arbetsme-toden Scrum. Målet var att få en ökad förståelse av mearbetsme-toden inom gruppen för att öka dess effektivitet.

4.3.2

Metrikprogram

Som en del av coachningen från TDDE46-studenterna skapade gruppen ett metrikprogram. Som metrik valdes pålitlighet då det var väldigt viktigt att systemet inte kraschade under demonstrationen inför kunden.

Eftersom målet bara var att klara demonstrationen, sattes kravet att systemet bara behövde klara att köras i en timme. Men under denna timme skulle systemet ha en pålitlighet på 90%. För att mäta detta startades systemet och kördes i en timme. Om systemet inte kraschade räknades det som en lyckad omgång.

För att kravet på 90% pålitlighet skulle vara uppnått skulle systemet uppfylla ekvationen: S ´ 9F ą=8

Där S och F representerar antalet lyckade respektive misslyckade omgångar. Praktiskt sett innebar detta att varje gruppmedlem körde systemet i en timme. Vid en misslyckad om-gång försökte gruppen isolera anledningen till kraschen och skapa en ny version som fixade problemet. Den nya versionen testades och processen upprepades tills dess att systemet upp-nådde nittoprocentig pålitlighet.

4.4

Informationsinsamling

För att skapa värde för kunden behövde gruppen samla in väldigt mycket information. I denna del ges de metoder studenterna använde för att hitta information och kunskap som hjälpte utvecklingen och dokumentationen av produkten.

4.4.1

Föreläsningar och seminarier

Som en del av kandidatprojektskursen TDDD96 annordnades flera föreläsningar och semi-narier. Vid dessa tillfällen fick gruppmedlemmarna tips om både utveckling av projektet och hur en bra kandidatrapport skrivs och presenteras. Gruppen visades också bra kandidatpro-jekt från tidigare år.

4.4.2

Kundmöten

För att förstå kundens verkliga krav och för att få feedback på gruppens arbete hölls flera möten med kunden. I snitt hölls ett möte i veckan och på de första mötena deltog endast teamledaren och kundansvarig. Efter några möten deltog även dokumentansvarig samt ut-vecklingsansvarig för att ta anteckningar.

5

Resultat

5.1

Systembeskrivning

Chattsystemet är designat med ett rött och vitt färgschema för att efterlika och förknippas med 1177. Funktionaliteterna i systemet är designade med användarvänlighet och intuitivi-tet i åtanke.

Nya patientbesök påbörjas med att patienter kan välja mellan olika kategorier. Patienter be-höver inte autentiseras direkt, istället finns det en möjlighet för anonymitet. Om patienten har kategoriserat ärendet och ställt en enklare fråga kan den automatiserade chattbotten hantera frågan. Däremot om ärendet skulle kräva vårdpersonal kommer systemet kräva patientens autentisering. En patient har möjligheten att anonymt ställa frågor till chattbotten och få svar till en viss begränsning. Denna begränsning är chattbottens kapacitet. Vid mer personliga frå-gor får patienten chatta med vårdpersonal. Systemet tillåter vårdpersonal att markera ord i syfte att sammanfatta det patienten skriver.

Systemet hanterar dessutom konversationsförgreningar. Det kan förkomma att patienten be-höver tala med olika vårdare. Vid dessa händelser förgrenas dialogen och ett ny chattfönster skapas. Det nya chattfönstret kommer innefatta alla relevanta deltagare och det är enbart del-tagarna som kan se och skriva i chattfönstret. För att underlätta användarupplevelsen skapas länkar mellan chattfönstrena. Därmed kan patienten följa hur chattarna är kopplade och pati-enten kan på ett smidigt sätt återvända till ett tidigare chattfönster vid behov. Systemet lagrar information som chatthistorik, svarsbatteri, standardfraser för chattbotten, nyckelord och an-vändare.

5.1.1

Systemet och dess moduler

Systemet är uppbyggd av moduler för att uppnå modularitet och innefattar interaktionsmo-dulen, lagringsmointeraktionsmo-dulen, kommunikationsmodulen och chattbotten. Varje modul fungerar självständigt med endast särskilda ingångs- och utgångsvärden.

5.1.1.1 Interaktionsmodulen

Interactionsmodulen ansvarar för chattsystemets användargräsnitt och består av fyra sidor. På startskärmen som syns i figur 5.1 introduceras användaren till olika inloggningsalternativ. Detta är således autentiseringssidan för patienter. Patienten kan dessutom fortsätta som gäst

Figur 5.1: Startsidan

Figur 5.2: Val av kategorier delen av sidan

och behålla sin anonymitet. Kategorisidan som syns i figur 5.2 visar hur patienten kan välja kategorin som passar best. Patientchaten som syns i figur 5.3 låter patienten chatta med vård-persional. Personalsidan för chatten syns i figur 5.4. På denna sida kan personalen chatta med patienten samt använda en kontrollpanel som låter personalen lägga till användare i chatter, avaktivera chatter, förgrena ut en ny chatt samt redigera frågebatterit som kan användas för att svara på frågor.

5.1. Systembeskrivning

Figur 5.3: Chatten från patientens synvinkel

Figur 5.4: Chatten från personalens synvinkel

5.1.1.2 Kommunikationsmodulen

Kommunikationsmodulen hanterar all kommunikation mellan systemets moduler. Några ex-empel är när en användare genom interaktionsmodulen vill para med andra användare, när chattbotten vill hämta frågebatteriet från lagrinsmodulen eller när en användare vill prata med chattboten. Vid dessa exempel fungerar kommunikationsmodulen som en brevbärare, det vill säga rätt förfrågning distribueras till rätt modul. Ett enkelt diagram av modulens roll kan ses i figur 5.5.

Figur 5.5: En översiktlig bild av kommunikationsmodulen.

5.1.1.3 Lagringsmodulen

Lagrinsmodulen ser till att all data som behövs kan sparas och återhämtas senare. Vad som sparas är vanliga frågor med dess respektive svar, chattbottens fraser och hela chatten vilket är en blandning av förgreningar, medelanden och användare. Ett relationsdiagram av data-basen finns i figur 5.6.

5.1. Systembeskrivning

5.1.1.4 Chattbott

Chattbotten är en modul som tar in ett meddelande som har skickats i chatten och botten matchar det meddelandet mot lagrinsgmodulen för att hitta ett svar att skicka tillbaka till chatten. Chattbotten skickar vidare meddelandet till lagrinsgmodulen och mottar fraser som matchar meddelandet. Efter det så jämförs fraserna mot meddelandet och frasen som är mest likt meddelandet skickas i chatten.

5.1.2

Systemanatomi

Gruppen skapade ett diagram på hur systemets anatomi är uppbyggd i början av projek-tet, se figur 5.7. Detta gjordes med avsikten av att skapa förståelse och få en överblick över chattsystemet innan gruppen började med implementationen av systemet.

5.1.3

Produktutvärdering

Produkten som har utvecklats i projektet hade tre olika prioritetsnivåer för krav som produk-ten skulle klara. Prio 1 är den högsta prioriteproduk-ten och dessa krav var viktiga att klara av, prio 2 krav kunde genomföras när prio 1 krav var klarade/nästan klara. Prio 3 krav hade lägst pri-oritet och dessa krav behövde inte fyllas om inte alla prio 1 och 2 krav var uppfyllda. Antalet krav som var testade och uppfyllda/ej uppfyllda listas nedan:

• Prio 1: 36 krav, 30 uppfyllda, 5 ej uppfyllda, 1 ej testade. • Prio 2: 13 krav, 6 uppfyllda, 6 ej uppfyllda, 1 ej testade. • Prio 3: 5 krav, 2 uppfyllda, 3 ej uppfyllda.

I prio 1 kategorin så var de krav som ej uppfylldes fokuserade på lagringsmodulen och kvalitet. Fyra av kraven handlade om lagringsmodulens funktionalitet att lagra chattdata, produktens lagringsmodul visade sig inte kunna hantera lagringen av chattdata på det sättet som gruppen ursprungligen tänkt sig. Därför uppfylldes inte kraven. De andra 2 krav som inte testades och inte blev uppfyllda var kvalitetskrav om stabilitet respektive kommente-ringsstandard. Produkten testades aldrig fullt ut för att mäta stabilitetskravet och därför blev det kravet inte testat. De krav som var prio 2 och 3 och som inte blev uppfyllda var krav som innebar mer omfattande implementation och funktionalitet i produkten. Därför hann inte gruppen med att implementera såpass stora funktionaliteter. Ett exempel på en sådan funktionalitet var ett automatiskt filtreringssystem i chattbotten som filtrerade viktig chatthistorik för vårdpersonal.

Testtäckningen på produkten var följande: • Chattbotten: 95%

• Lagringsmodulen: 95%

• Kommunikationsmodulen: 38% • Autentiseringsmodulen: 43% • Interaktionsmodulen: 0%

Totalt i projektet skrevs 11252 rader kod. Här är antalet rader kod för projektet: • Python: 689 • TypeScript: 1366 • bat: 20 • CSS: 791 • HTML: 401 • txt/JSON: 34 • JavaScript: 1196

Projektet hade överlag en bra cyclomatisk komplexitet. Nedan finns den cyklomatiska kom-plexiteten för Python- och Javascript koden. Det är i dessa språk som majoriteten av den viktiga funktionaliteten för projektet är implementerad i.

• Python: Max 10 med ett medelvärde 2.3 med majoriteten mellan 1-3. • Javascript: Max 11 och medianen är 2.

5.2. Prototyper

5.2

Prototyper

Under projektutvecklingen har gruppen skapat papersprototyper. Pappersprototyperna an-vändes för att formulera och diskutera olika implementationer med kunden. Projektet inne-fattade två prototypfaser. Första fasen fokuserade på att skapa en översiktlig bild av slutpro-dukten. Den andra fasen hade konversationsförgrening som fokus. Resultatet från fas ett och två finns i figur 5.8 respektive 5.9.

Figur 5.9: Fas 2 prototyp.

5.3

Vad har kunden för värde hos det som skapats?

Systemet som har skapats har varit i syfte att ge kunden, Region Östergötland, möjligheten att utforska olika chattsystemsvarianter. Produkten kommer att användas i demonstrationer för att bidra med ideer och lösningar till kundens egna skapande av ett chattsystem och chattbott. Det som skapats är då av värde eftersom det underlättar kundens framtida arbete och skapande av ett likanande system.

Det som är extra intressant med produkten ur kundens synpunkt är möjligheten till för-grening samt markering av text i tidigare meddelanden. Detta är något som detta projekt har tagit fram i produkten och något som kunden kan använda i framtiden för att utforska mer i hur liknande system kan implementeras.

5.4

Dokument som har producerats

De dokument som har producerats i samband med projektet är de som är listade nedan. • Kravspecifikation - Innehåller kraven på chattsystemet som ställs av kunden. • Projektplan - Definierar hur projektet organiseras.

5.5. Processbeskrivning

• Testplan - Definierar alla tester.

• Testrapport - Innehåller resultaten av testerna som definierades i Testplanen. • Arkitekturbeskrivning - Beskriver chattsystemets architektur.

• Kvalitetsplan - Definiera kraven och processerna för att säkerställa kvaliteten av arbetet och resultatet.

5.5

Processbeskrivning

I denna del tas processbeskrivningen upp. Detta innefattar mätningar och förbättringar av processerna.

5.5.1

Mätning av kvalitetskrav

Ett utav projektgruppens kvalitétskrav var att implementerad kod skulle följa en kodstan-dard. För att mäta och säkerställa detta användes verktyget flake8 för att verifiera koden. Ett ytterligare projektgruppens kvalitétskrav var att chattsystemet skulle vara modulärt. Det-ta verifierades med hjälp av tester för varje enskild modul.

Ett annat kvalitétskrav var att verisionshanteringen skulle följa gruppens förbestämda stan-dard. För att verifiera detta krav fick dokumentansvarig ansvaret att kolla över commit-meddelanden varje vecka och rapportera innehållet för gruppen.

5.5.2

Beskrivning av mätningar

Under projektarbetet använde gruppen en enkätundersökning för att utvärdera processen efter varje sprint. Enkäten bestod av 10 frågor som kunde besvaras på en skala från ett till fem där ett är Håller inte med och fem är Håller med. Gruppmedlemmarna fick också möjligheten att svara i fritext på ett antal frågor. En av dessa frågor var att föreslå en förbättring på processen till nästa sprint. Enkätundersökningen gjordes anonymt av alla gruppmedlemmar.

5.5.3

Dokumentation av process

Efter varje sprint hade gruppen ett återblicksmöte där resultatet av enkätundersäkningen diskuterades. Mötet bestod huvudsakligen av två punkter. Dessa var enkätundersökning och planering för kommande sprint. När resultatet av enkäten diskuterades gick gruppen igenom varje fråga. Detta för att se om gruppen gjort några förbättringar sedan förra sprinten och för att se om det fanns några förbättringsmöjligheter. När gruppen planerade inför kommande sprint användes Trello för att bestämma hur arbetet skulle delegeras. Efter återblicksmötet sammanställdes en rapport som beskrev resultatet av enkäten, utvecklingen av processen med hjälp av linjediagram, potentiella brister och förbättringsmöjligheter.

5.5.4

Förbättring av process

På återblicksmötet kom gruppmedlemmarna med förbättringsförslag. Följande förbättringar togs upp och behandlades under projektet:

• Planera in återblicksmöten i förväg.

Projektgruppen ville förbättra utvärderingsprocessen efter varje sprint eftersom den upplevdes som ostrukturerad. Innan förbättringen var utvärderingen en del av vanliga projektmöten vilket kunde vara stressigt. För att förbättra kvalitén vid utvärderingarna bestämde gruppen att planera in återblicksmöterna i förväg. Förbättringen tillämpades under de tre sista sprintarna. Därmed finns det lite mätdata för frågan “Jag tycker att de förra återblicksmötet hade en positiv påverkan på sprinten”.

• Mer detaljerad Trello-användning.

Denna förbättring föreslogs då gruppen upplevde att Trello inte användes till sin fulla potential och skulle dra nytta av ett mer rigoröst användande. Detta för att ge bättre förståelse till gruppmedlemmarna om vad olika arbetsuppgifter innefattade.

• Tydligare och mer frekventa standup-möten.

Under återblicksmötena märktes en trend att gruppmedlemmarna inte hade mycket kunskap om vad andra i gruppen arbetade med. En förbättring var att ha standup-möten varje arbetsdag istället för varannan arbetsdag. En ytterligare förbättringen var att gruppmedlemmarna skulle bli mer detaljerade i deras beskrivning under standup-mötena.

5.5.5

Utvärdering av förbättringen

Rapporten som sammanställdes efter varje återblicksmöte användes vid senare återblicksmö-te för att värdera ifall förbättringsmöjligheåterblicksmö-terna hade realiserats och ifall det hade resulåterblicksmö-terat i en förbättring av processen.

• Planera in återblicksmöten i förväg.

Figuren 5.10 visar resultatet av de tre sista sprintarna vad gäller frågan “Jag tycker att de förra återblicksmötet hade en positiv påverkan på sprinten”. Denna visar att grup-pen hade en positiv inställning till återblicksmötena mot slutet av projektet eftersom medelvärdet var över tre poäng för de sista veckorna. Tidigare statistik finns inte men dokumentation om dålig struktur gällande återblicksmötena finns tillgängligt. Detta antyder att gruppen hade en sämre syn på återblicksmötena tidigare i projektet. Därför går det att dra slutsatsen att återblicksmötena förbättrades under projektets gång efter att dessa möten planerades i förväg.

• Mer detaljerad Trello-användning.

Figuren 5.11 visar gruppens synpunkt om användningen av Trello brädet. Det märktes efter den första sprinten att gruppen inte tyckte om användningen av brädet. Förbätt-ringen märktes direkt då synpunkten ökade snabbt.

• Tydligare och mer frekventa standup-möten.

Figuren 5.12 visar gruppens synpunkt om standup-möten under projektet gång. För-bättringen gjordes efter sprint fem och vi märkte en förbättring därefter.

5.6

Gemensamma erfarenheter

Under projektets gång så har projekt gruppen fått flera nya erfarenheter.

5.6.1

Projektorganisation

En positiv erfarenhet som kan användas i framtiden var erfarenheten av att arbeta i en större grupp för att utveckla programvara. Projektet var större än tidigare projekt och studenterna fick inte välja gruppmedlemmarna. Speciellt erfarenheten av att ha jobbat i ett större pro-jekt med nya personer kan bli väldigt nyttigt då de flesta troligtvis kommer behöva jobba på samma sätt i arbetslivet. En annan erfarenhet var att gruppen har gjort ett större projekt på distans och har därmed fått träna på att samarbeta med personer som de inte fysiskt träffar regelbundet. Detta sätt att jobba är inte vanligt i arbetslivet, med undantag under COVID-19-tider, på senare tid har detta sättet att jobba blivit vanligare.

En annan positiv erfarenhet är att skriva dokumentation för arbetsprocessen vilket är något som gruppen hade gjort förut men inte på samma skala. Denna erfarenhet kan också ses

5.6. Gemensamma erfarenheter 1 2 3 4 5 6 7 1 2 3 4 5 (1) (2) (4) (1) (3) (3) (2) (3) (4) (1) Sprint poäng

Figur 5.10: Svar på frågan “Jag tycker att de förra återblicksmötet hade en positiv påverkan på sprinten”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver medelvärdet för sprinten.

1 2 3 4 5 6 7 1 2 3 4 5 (5) (2) (1) (1) (2) (4) (1) (3) (2) (3) (2) (2) (4) (5) (3) (4) (2) (2) Sprint poäng

Figur 5.11: Svar på frågan “Jag tycker att agilbrädet (Trello) har använts som planerat”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver medelvärdet för sprinten.

som mindre positivt då gruppen underskattade hur mycket dokument skrivande som be-hövde göras och att gruppen i helhet har en negativ syn på att skriva dokument. Gruppen har fått praktisk erfarenhet om vissa agila arbetsmetoder och om hur ett projekt av denna storlek organiseras. En viktig erfarenhet är användningen och indelningen av tydliga roller i projektutveckling. Det har varit väsentligt för att skapa struktur och tydliga arbetsuppgif-ter. Delegering av stora arbetsuppgifter till person eller flera personer i gruppen är också en positiv erfarenhet. En annan erfarenhet är att regelbundna möten minskar missförstånd och ger en bättre uppfattning om projektets status. Dessa erfarenheter är positiva eftersom de kan användas i framtiden, både i projekt och i arbetslivet.

1 2 3 4 5 6 7 1 2 3 4 5 (1) (1) (1) (4) (2) (4) (2) (2) (3) (3) (2) (5) (1) (1) (1) (4) (2) (1) (4) (3) Sprint poäng

Figur 5.12: Svar på frågan “Jag tycker att de dagliga mötena har fungerat väl”. Siffran över de blåa mätvärden är antalet personer som valt det svaret. Den röda kurvan beskriver me-delvärdet för sprinten.

5.6.2

Tekniska erfarenheter

Gruppen har fått ökad teknisk erfarenhet, särskilt i språken CSS, HTML och TypeScript. Gruppmedlemmarna har också utvecklat kunskaper om socket-programmering, uppsättning och design av en webbsida med tillhörande server. Dessa tekniska erfarenheter är positiva ef-tersom de kan användas i andra framtida projekt.

5.6.3

Kundkontakt

Gruppen har fått erfarenhet om hur det är att jobba med en kund under ett projekt vilket är nytt för gruppens medlemmar. Detta är en positiv erfarenhet eftersom gruppmedlemmarna kommer jobba med kunder i framtiden.

5.7

Översikt över individuella bidrag

Nedan kommer en översiktlig beskrivning av de individuella delarna av kandidatrapporten. Varje person i projektgruppen har varsin del inom ett fördjupningsområde.

5.7.1

Lucia Choura - Chattbottar med fokus på användarupplevelse

I detta bidrag undersöks för- och nackdelar med en chattbott från ett sjukvårdsperspektiv. En undersökning gällande chattbottsegenskaper som kan bidra till användarupplevelsen har också gjorts. Undersökningen utgår ifrån att det är en chattbott vars syfte är att hjälpa inom ett designerat område. Totalt deltog 52 personer i enkätundersökningen. Slutsatser som drogs var att det kan vara en fördel med en chattbott utifrån ett sjukvårdperspektiv, om det är ett ytterligare sätt att få hjälp på utöver de alternativen som finns. Enkätundersökningen visade på att alla egenskaper; medvetenhet, originalitet, uppförande och korrekthet var av vikt.

5.7.2

Casper Jensen - Studenters åsikter om digital kommunikation med

vårdpersonal

I detta bidrag så undersöks det hur studenter i åldern 18-30 år föredrar att kontakta vården för enklare symptom. Alltså om de föredrar att kontakta vården över chatt, telefon eller

öv-5.7. Översikt över individuella bidrag

riga medel. Detta besvarades med en enkätundersökning med totalt 93 svarande. Dessutom gjordes en litteraturstudie för att undersöka hur digital kommunikation mellan vårdgivare och patienter kan förbättras så att kommunikation i chatt blir effektivare. Enkätundersök-ningen visade att mer än hälften av studenterna skulle föredra att kontakta vården i en chatt för enklare symptom på sig själva eller närstående. Litteraturstudien visade att tydlighet när det kommer till svarstider och öppettider för chattkommunikation med vården är viktigt, även stöd för översättning av text hjälper för minoritetsgrupper.

5.7.3

Taha Unalan - Användandet av Scrum i vårt kandidatprojekt

I det här bidraget undersöks hur projektgruppen har implementerat och använt arbetsmeto-den Scrum. Bidraget lyfter fram hur projektgruppen definierade och använde sig av metoarbetsmeto-den samt hur det upplevdes. Studien tar upp hur väl implementationen av Scrum följdes och om det var gynnsamt för projektet. Slutsatsen som drogs av bidraget var att det kändes gynnsamt för projektmedlemmarna och projektutvecklingen.

5.7.4

Kevin Bärudde - Agila arbetsmetoder för mjukvaruprojekt-teams

En undersökning om vad användare av agila metoder tycker om dem. I undersökningen följs ett team under ett mjukvaruprojekt och data samlas in under deras återblicksmöten. Denna datan jämförs med tidigare studiers resultat. Undersökningen visar att agil mjukvaruutveck-ling sätter vissa krav på teams. Medlemmarna i teamet måste kunna tydligt kommunicera med resten av teamet. Dessutom krävs disciplin av teamet genom att delta i metoderna så att resten av medlemmarna får användning av arbetsmetoden.

5.7.5

Hannes Westander - Parprogramering

I denna del undersöks parprogrammering och mer specifikt huruvida det är effektivt eller inte. Utredningen innehåller littaraturstudie för att undersöka parprogrammerings för- och nackdelar. Delen behandlar också vilka typer av projekt och situationer som passar bäst för denna arbetsmetod. Som resultat fås att parprogrammering ger bättre kvalitet och kortare ka-lendertid men högre antal arbetstimmar. Parprogrammering passar bäst för komplexa projekt med höga krav på kvalitet eller projekt med programmerare som inte är väldigt erfarna.

5.7.6

Filip Karlberg - Användning av prototyper för utveckling av

webbapplikation

I detta bidrag studeras konceptet med olika prototyper, med fokus på temporära- och evolu-tionära prototyper. Det dras också en koppling till användning av prototyper inom projektet och användning av prototyper i samband med den agila metoden Scrum. Prototyptyperna värderas efter användningsområde där dess skillnader och likheter jämförs. Studien kom fram till att temporära prototyper är användbara i ett sammanhang där fler idéer måste dis-kuteras och där inte lika mycket resurser läggs på något utanför slutprodukten. Ett exempel på dessa är pappersprototyper. Evolutionära prototyper är användbara i sammanhand där slutprodukten är i fokus. Detta eftersom fler resurser läggs på något som kan användas till slutprodukten. En kombination av temporära och evolutionära prototyper kan användas till projekt som detta men generellt så är evolutionära prototyper mer passande för Scrum.

5.7.7

Felicia Posluk - Kommunikation på projektmöten vid distansarbete

Kommunikation är en kritisk faktor för projektutveckling. Det är dessutom ett av de svårare verktygen att bemästra och underhålla under ett projekt. Kommunikation anses vara en kri-tisk faktor som avgör projektets framgång. Studien undersöker hur informell kommunikation påverkar projektmöten och hur kommunikation påverkar grupputveckling vid distansarbete.

Resultatet visar att det finns en avsaknad av informell dialog som hindrar uppbyggnaden av teamkänsla och gemenskap i de tidigastadierna till grupputveckling. Detta i sin tur påverkar senare delar av grupputvecklingen som att använda konstruktiv feedback som ett verktyg för att effektivisera projektarbetet.

5.7.8

Ludwig Forsberg - Jämförelse av TypeScript och JavaScript i

webbutveckling

I detta bidrag studeras stora skillnader mellan TypeScript och JavaScript som programspråk för webbutveckling. I bidraget tas det upp diskussion om fördelar och nackdelar med Ja-vaScript gentemot TypeScript, jämförelse av uppsättning av de två programspråken samt bakomliggande teori bakom de olika programspråkens grundläggande idéer. Studien är en litteraturstudie vilket innebär att källor har använts för att uppnå ett resultat. Läät samman-fattat är TypeScript bättre för större projekt då det möjliggör en kodstruktur som inte går att lika lätt sätta upp i JavaScript. Den största nackdelen med TypeScript som togs upp i studien var det faktum att TypeScript kräver en kompilator som behövs sättas upp vilket inte är fallet för JavaScript.

6

Diskussion

6.1

Resultat

I denna sektion diskuteras resultatet som uppnåtts under projektet, vilka alternativa imple-mentationssätt som fanns, tidigare erfarenheter samt värdet för kunden. Vidare diskuteras även lärdomarna som gruppmedlemmarna har fått ifrån projektet.

6.1.1

Vad återstår för att kunden ska få ut fullt värde av produkten?

Det som återstår för att kunden ska kunna få fullt värde av produkten är att göra chattsyste-met mer avancerat. I detta fall skulle ett mer avancerat system innebära att vidareutveckla existerande system.

Chattbottens sätt att hantera konversationer på kan förbättras genom att använda en an-nan algoritm för att kunna besvara frågor mer träffsäkert. Den nuvarande chattbotten svarar genom att hitta relevanta kopplingar mellan det som skrivs av patienten och förskrivna svar som finns i databasen. En intressant vidareutveckling hade varit användning av maskininlär-ning för att analysera konversationen och hantera patientfrågor. Detta skulle kunna förbättra chattsystemets textfiltrerings- och sammanfattnings förmågor. Om den är avancerad kan den filtrera ut nyckelord och skapa en sammanfattning för vårdpersonalen att läsa när de går med i konversationen. En ytterligare svaghet är att chattbotten inte kan tolka ord som är felstavade. Det gör att patienter som har svårigheter med att skriva inte kan nyttja systemet. Även detta skulle en mer avancerad chattbott kunna lösa.

Chattsystemets nuvarande autentisering består av inskrivning av personnummer. Detta är inte ett säkert sätt att autentisera en patient på. För att kunden ska få fullt värde av produkten kan autentisering göras på ett sätt som vården anser vara lämpligt. Detta skulle leda till att hantering av personuppgifter kan ske utan större säkerhetsrisker. Chattsystemet tillåter inte vårdpersonal att ha flera konversationer med olika patienter. Hantering av flera patienter är därför en till funktion som återstår för att kunden ska få ut fullt värde av produkten. Detta skulle göra att vårdpersonal kan ha flera parallella konversationer och minska bortslösad tid. Det gör i sin tur att fler patienter kan få hjälp samtidigt och att vårdpersonalens arbete effektiviseras.