Schemaläggningsstöd för kirurgi

Linköpings universitet | Instutitionen för datavetenskap Examensarbete på grundnivå, 15hp | Datateknik och Mjukvaruteknik Vårterminen 2018 LIU-IDA/LITH-EX-G–18/013–SE

Schemaläggningsstöd för

kirurgi

Scheduling support for surgery

Adam Andersson Niclas Byrsten Björn Hvass Henrik Lindström Martin Persson Christoffer Sjöbergsson Tor Utterborn

Handledare: Jonas Wallgren Examinator: Kristian Sandahl

Projektidentitet

Namn Roll E-post

Adam Andersson Teamledare adam.e.a.andersson@gmail.com

Niclas Byrsten Testansvarig nicby889@student.liu.se

Björn Hvass Konfigurationsansvarig bjorn.hvass@gmail.com Henrik Lindström Utvecklingsledare henli070@student.liu.se Martin Persson Arkitekturansvarig marpe902@student.liu.se Christoffer Sjöbergsson Analysansvarig chrsj812@student.liu.se

Tor Utterborn Dokument- & Kvalitetsansvarig tor.utterborn@gmail.com

Kund

Region Östergötland, 581 91 Linköping. Kontaktperson hos kund

Gunnar Nordqvist, IT-arkitekt, 010-1030698, Gunnar.Nordqvist@regionostergotland.se Erik Sundvall, Informationsarkitekt, 010-1036252, Erik.Sundvall@regionostergotland.se

Dokumenthistorik

Datum Händelse Iteration Version

2018-02-19 Dokument skapas 2 0.1

2018-04-18 Dokument reviderat efter feed-back 3 0.2

2018-04-23 Kapitel teori samt individuella bidrag uppdaterade 3 0.3

2018-05-03 Utökning, standard inför inlämning 4 4 0.4

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publiceringsdatum 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 ensta-ka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ 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 ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannenslitterä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 publisher 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 circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-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 me-asures 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 Lin-köping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

Adam Andersson Niclas Byrsten Björn Hvass c _{Henrik Lindström} Martin Persson Christoffer Sjöbergsson Tor Utterborn

Sammanfattning

Denna rapport är resultatet av kandidatprojektkursen TDDD96 som ges vid Linköpings Universitet. Rapporten omfattas av sju studenter som har utvecklat ett schemaläggnings-stöd för kirurgin till Region Östergötland. I rapporten behandlas de tekniska val som har gjorts, hur utvecklingsarbetet har fortgått och hur resultat blev. Varje student har också bidragit med en individuell studie, dessa finns i slutet av dokumentet.

The word aeon also spelled eon and æon, originally meant ”life”, ”vital force” or ”being”, ”generation” or ”a period of time”, though it tended to be translated as ”age” in the sense of

”ages”, ”forever”, ”timeless” or ”for eternity”

Tack

Vi vill tacka alla som har hjälpt oss under projektets gång. Speciellt tack till vår kund Region Östergötland som har gett bra återkoppling på möten och som har bistått med testpersoner till den produkt vi utvecklat. Slutligen vill vi tacka vår handledare som alltid har haft svar på de frågor och funderingar som vi har haft.

Innehållsförteckning

I

Huvudrapport

1

1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Frågeställningar . . . 2 1.4 Avgränsningar . . . 3 1.5 Definitioner . . . 3 2 Bakgrund 4 2.1 Processen idag . . . 4 2.2 Projektet . . . 4 2.3 Gemensamma erfarenheter . . . 4 3 Teori 5 3.1 Scrum . . . 5 3.2 GitLab . . . 5 3.3 Webstorm . . . 6 3.4 Node.js . . . 6 3.5 Angular . . . 6 3.6 Model-View-Controller . . . 6 3.7 MySQL . . . 7 3.8 Sequelize . . . 7 4 Metod 9 4.1 Projektorganisation . . . 9 4.1.1 Roller . . . 9 4.1.2 Möten . . . 11

4.1.3 Dokumentation . . . 11 4.1.4 Kompetensutveckling . . . 11 4.2 Utvecklingsmetod . . . 11 4.3 Förstudie . . . 12 4.4 Design . . . 12 4.4.1 Grafisk design . . . 12 4.4.2 Mjukvarudesign . . . 13 4.5 Utveckling . . . 13 4.5.1 Front-end . . . 13 4.5.2 Back-end . . . 14 4.6 Insamling av erfarenheter . . . 15 4.7 Utvärdering . . . 15 4.7.1 Sprintutvärdering . . . 15 4.7.2 Utvärdering av projektet . . . 15 5 Resultat 16 5.1 Systembeskrivning . . . 16 5.1.1 Front-end . . . 16 5.1.2 Back-end . . . 16 5.1.3 LoFi-Prototyper . . . 17 5.1.4 Grafiskt gränssnitt . . . 18 5.1.5 Systemanatomi . . . 20 5.1.6 Värde för kund . . . 21 5.2 Gemensamma erfarenheter . . . 22 5.2.1 Tekniska erfarenheter . . . 22

5.2.2 Kommunikation och planering . . . 22

5.2.3 Dokumentation . . . 22

5.2.4 Samlad kompetens . . . 22

5.2.5 Nyttan för kommande projekt . . . 22

5.3.1 Teamledarens roll kombinerad med Scrum-metodik av Adam Andersson 23 5.3.2 Versionshantering för ett mindre mjukvaruutvecklingsprojekt av Björn

Hvass . . . 23

5.3.3 Effektivt val av aktörer för kravinsamling av Christoffer Sjöbergsson 23 5.3.4 Jämförelse mellan TypeScript och JavaScript av Henrik Lindström . 23 5.3.5 Angular som webbutvecklingsplattform av Martin Persson . . . 23

5.3.6 Prototyputveckling i ett kandidatprojekt av Niclas Byrsten . . . 23

5.3.7 Kvalitetsförsäkrande metoder i ett småskaligt mjukvaruprojekt av Tor Utterborn . . . 23

6 Diskussion 25 6.1 Resultat . . . 25

6.1.1 Viktigaste lärdomar inför framtiden. . . 25

6.1.2 Har vi förbättrat något från tidigare projekt? . . . 25

6.1.3 Val av Webbutvecklingsramverk . . . 26 6.2 Metod . . . 26 6.2.1 Projektorganisation . . . 27 6.2.2 Utvecklingsmetodik . . . 27 6.2.3 Förstudie . . . 28 6.2.4 Design . . . 28 6.2.5 Utveckling . . . 28 6.2.6 Utvärdering . . . 29 6.3 Källhantering . . . 29

6.4 Arbetet i ett vidare sammanhang . . . 29

6.4.1 Samhälleliga aspekter . . . 30

6.4.2 Etiska aspekter . . . 30

6.4.3 Miljöaspekter . . . 30

II

Individuella bidrag

34

8 Teamledarens roll kombinerad med Scrum-metodik av Adam Andersson 35

8.1 Inledning . . . 35 8.1.1 Syfte . . . 35 8.1.2 Frågeställning . . . 35 8.2 Bakgrund . . . 35 8.3 Teori . . . 36 8.3.1 Scrum . . . 36 8.3.2 Teamledarrollen . . . 37 8.4 Metod . . . 38 8.4.1 Informationssökning . . . 38 8.4.2 Egna erfarenheter . . . 38 8.4.3 Intervjuer . . . 38 8.5 Resultat . . . 39 8.5.1 Resultat - Informationssökning . . . 39

8.5.2 Resultat - Egna erfarenheter . . . 39

8.5.3 Resultat - Intervjuer . . . 40

8.6 Diskussion . . . 40

8.6.1 Metod . . . 40

8.6.2 Resultat . . . 41

8.7 Slutsatser . . . 41

9 Prototyputveckling i ett kandidatprojekt av Niclas Byrsten 43 9.1 Inledning . . . 43 9.2 Syfte . . . 43 9.3 Frågeställningar . . . 43 9.4 Bakgrund . . . 43 9.5 Avgränsningar . . . 43 9.6 Teori . . . 44

9.7 Prototyp . . . 44 9.7.1 Lo-fi prototyp . . . 44 9.7.2 Hi-fi prototyp . . . 44 9.8 Val av Prototyp . . . 44 9.9 Förberedelse . . . 44 9.10 Första designmötet . . . 45 9.11 Andra designmötet . . . 45 9.12 Metod . . . 45 9.13 Resultat . . . 46 9.14 Diskussion . . . 46 9.15 Slutsats . . . 47

10 Versionshantering för ett mindre mjukvaruutvecklingsprojekt av Björn Hvass 48 10.1 Inledning . . . 48 10.2 Syfte . . . 48 10.3 Frågeställning . . . 48 10.4 Avgränsningar . . . 48 10.5 Bakgrund . . . 49 10.6 Teori . . . 49 10.6.1 Versionshantering . . . 49 10.7 Metod . . . 50 10.7.1 Intervjufrågor . . . 50 10.8 Resultat . . . 51 10.9 Diskussion . . . 51 10.10Slutsatser . . . 52

11 Jämförelse mellan TypeScript och JavaScript av Henrik Lindström 53 11.1 Inledning . . . 53

11.2 Syfte . . . 53

11.4 Bakgrund . . . 53 11.5 Teori . . . 54 11.5.1 JavaScript . . . 54 11.5.2 TypeScript . . . 54 11.5.3 Dynamisk typning . . . 54 11.5.4 Statisk typning . . . 55 11.6 Metod . . . 55 11.6.1 Egna erfarenheter . . . 55 11.6.2 Intervjuer . . . 55 11.6.3 Litteraturstudie . . . 55 11.7 Resultat . . . 55 11.7.1 Egna erfarenheter . . . 55 11.7.2 Intervjuer . . . 56 11.7.3 Litteraturstudie . . . 56 11.8 Diskussion . . . 57 11.8.1 Resultat . . . 57 11.8.2 Metod . . . 58 11.9 Slutsatser . . . 58

11.9.1 Bidrar den statiska typningen i TypeScript till att fel hittas tidigare under utveckling? . . . 58

11.9.2 Bidrar den statiska typningen i TypeScript till kod som är lättare att läsa och förstå? . . . 58

11.9.3 Hur påverkas produktivitet vid utveckling av statisk typning jämfört med dynamisk? . . . 59

12 Angular som webbutvecklingsplattform av Martin Persson 60 12.1 Inledning . . . 60

12.2 Syfte . . . 60

12.2.1 Frågeställing . . . 60

12.2.2 Avgränsningar . . . 60

12.4 Teori . . . 61 12.4.1 Angular . . . 61 12.4.2 TypeScript . . . 61 12.5 Metod . . . 61 12.5.1 Litteraturstudie . . . 61 12.5.2 Empirisk undersökning . . . 62 12.6 Resultat . . . 62 12.6.1 Litteraturstudie . . . 62 12.6.2 Empirisk undersökning . . . 62 12.7 Diskussion . . . 63 12.7.1 Val av ramverk . . . 63 12.7.2 Utvärdering av Angular . . . 63 12.7.3 Metod . . . 64 12.8 Slutsats . . . 65

13 Kvalitetssäkrande metoder i ett småskaligt mjukvaruprojekt av Tor Ut-terborn 66 13.1 Inledning . . . 66 13.2 Syfte . . . 66 13.3 Definitioner . . . 66 13.4 Frågeställning . . . 66 13.5 Avgränsningar . . . 67 13.6 Bakgrund . . . 67 13.7 Teori . . . 67 13.7.1 IEEE-730 . . . 67 13.7.2 ISO/IEC TR 29110-5-1-3 . . . 67 13.7.3 TSLint . . . 68 13.7.4 Angular . . . 68 13.8 Metod . . . 68 13.9 Resultat . . . 68

13.10Diskussion . . . 69

13.11Slutsatser . . . 70

14 Effektivt val av aktörer för kravinsamling av Christoffer Sjöbergsson 71 14.1 Inledning . . . 71 14.2 Syfte . . . 71 14.3 Frågeställning . . . 71 14.4 Avgränsningar . . . 71 14.5 Definitioner . . . 71 14.6 Bakgrund . . . 71 14.7 Teori . . . 72 14.7.1 Kravframställning . . . 72

14.7.2 Urval av berörda aktörer . . . 72

14.7.3 Brainstorming . . . 72 14.7.4 Intervjuer . . . 73 14.7.5 Användartest . . . 73 14.8 Metod . . . 73 14.8.1 Vår framtagning . . . 73 14.9 Andra metoder . . . 74 14.9.1 Metod 1 . . . 74 14.9.2 Metod 2 . . . 74 14.10Resultat . . . 75 14.11Diskussion . . . 76 14.11.1 De alternativa metoderna . . . 76 14.11.2 Vår metod . . . 76

14.11.3 Implementera alternativa metoder . . . 76

III

Bilagor

81

A Intervjuer för versionshantering för ett mindre

mjukvaruutvecklingspro-jekt. 82

B Intervjuer om TypeScript och JavaScript 89

B.1 Intervjufrågor . . . 89 B.2 Svar på intervjuer . . . 89 B.2.1 Gruppmedlem 1 . . . 89 B.2.2 Gruppmedlem 2 . . . 90 B.2.3 Gruppmedlem 3 . . . 90 B.2.4 Gruppmedlem 4 . . . 91 B.2.5 Gruppmedlem 5 . . . 91

C Intervju svar på frågor om prototyp. 92 D Intervjuer om val av ramverk 94 D.1 Intervjufråga 1 . . . 94 D.2 Intervjufråga 2 . . . 94 D.3 Intervjufråga 3 . . . 94 D.4 Intervjufråga 4 . . . 95 D.5 Intervjufråga 5 . . . 95 D.6 Intervjufråga 6 . . . 95 D.7 Intervjufråga 7 . . . 96

E Intervjuer om teamledarens roll kombinerad med Scrum-metodik 97 E.1 Intervjufråga 1 . . . 97 E.2 Intervjufråga 2 . . . 97 E.3 Intervjufråga 3 . . . 97 E.4 Intervjufråga 4 . . . 97 E.5 Intervjufråga 5 . . . 98 E.6 Intervjufråga 6 . . . 98 E.7 Intervjufråga 7 . . . 98

E.8 Intervjufråga 8 . . . 98

E.9 Intervjufråga 9 . . . 99

E.10 Intervjufråga 10 . . . 99

Figurer

4.1 Systemskiss . . . 13 4.2 EER-diagram . . . 14 5.1 Sista LoFi-prototypen . . . 17 5.2 Gränssnittet . . . 18 5.3 Sidopanelens två vyer. . . 19 5.4 Spårvyn . . . 20 5.5 Systemanatomi . . . 21 14.1 Tidslinje för kravframtagnin . . . 73

Tabeller

4.1 Dokumentation i förstudien . . . 12

Del I

Kapitel 1

Inledning

Detta kapitel beskriver syftet med produkten som utvecklats, vilka frågeställningar som besvaras i rapporten samt vilka avgränsningar projektet haft.

1.1

Motivering

På en operationsavdelning utförs olika ingrepp som kräver många olika sorters kompetenser, utrustning och material. För att organisera detta arbete sitter idag flera planerare med ansvar för olika rum och schemalägger olika operationer som ska genomföras.

Varje planerare ska se till att alla resurser finns tillgängliga. Operationen behöver rum att utföras i med behörig personal och rätt verktyg. Dessutom ska operationer med hög brådskandegrad få prioritet. All denna information är mycket för en person att bevaka. Om det uppstår fel kan det i sin tur leda till att en operation inte kan utföras för att alla behov inte är tillgodosedda vid operationstillfället, eller att operationsrum står tomma.

För att förenkla processen för planerare att schemalägga operationer ska ett schemalägg-ningsstöd utvecklas. All information som rör olika operationer ska finnas tillgänglig så att man enkelt ska kunna få fram tillgängliga operationstider för det ingrepp som ska utföras. Denna programvara kommer att förenkla vårdpersonalens arbete då man inte behöver hål-la lika många saker i huvudet. Phål-lanerare kommer att kunna se och fylhål-la de tillgängliga operationstiderna som finns. Detta kommer även att hjälpa dem som väntar på operation. Väntan på att opereras kommer att minska om sjukhus kan nyttja så mycket som möjligt av den tid som finns tillgänglig. Därmed kan sjukhuset operera fler patienter än vad som görs idag.

1.2

Syfte

Syftet med projektet var att utveckla ett schemaläggningsstöd för kirurgi för användning inom Region Östergötland. Programmet är tänkt att underlätta och optimera schemalägg-ning av operationer. Den slutgiltiga produkten tillsammans med demonstrationsmöten och dokumentation kommer att användas av Region Östergötland som en form av förstudie till ett större projekt som pågår på Universitetssjukhuset i Linköping, GOLI(a)T. [1] Rappor-tens syfte är att beskriva utveckling av produkten, beskriva slutprodukten samt utvärdera hur projektet har gått och hur resultatet blev.

1.3

Frågeställningar

För att ge rapporten ett fokus så har ett antal frågeställningar formulerats som behandlas i rapporten:

1. Hur kan systemet som utvecklas implementeras så att värde skapas för kunden? 2. Hur kan man separera front-end och back-end på ett bra sätt så att delarna inte är

beroende av varandra?

3. Vilka erfarenheter kan dokumenteras från projektet som kan vara intressanta för fram-tida projekt?

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

1.4

Avgränsningar

Denna rapport är avgränsad till den produkt som arbetats fram samt de individuella bidra-gen. I övrigt så har kunden gett oss tämligen fria händer vid utvecklingen av produkten. Den begränsning vi fick är att produkten ska gå att köra på Internet Explorer 11. I övrigt så har projektarbetet en tidsbudget på 2800 timmar, det vill säga 400 timmar per person. Dessa timmar är fördelade på olika områden som dokumentskrivning, utveckling och individuellt bidrag.

1.5

Definitioner

• GOLI(a)T - Gemensam Operationsprocess, Ledning och IT-stöd. Projekt inom Region Östergötland där man siktar på att standardisera och förenkla operationsprocesser. • ORM - Object-relational mapping. En programmeringsteknik som konverterar

data-bastabeller till klasser, tabellrader till objekt och celler till objekt-attribut.

• LoFi-prototyp - LoFi betyder ungefär “low fidelity” och kan översättas till “låg pre-cision”. LoFi-prototypen är i det här fallet en ritad pappersprototyp av det grafiska gränssnittet.

• Front-end - Med front-end menas den del av systemet som körs i användarens webb-läsare. Front-end har i denna rapport använts synonymt med klient.

• Back-end - Med back-end menas den del av systemet som inte körs i användarens webbläsare. Back-end har i denna rapport använts synonymt med server.

• Scrum - Agil utvecklingsmetodik som ofta används i mjukvaruprojekt.

• Sprint - Tidsperiod där en grupp som arbetar med Scrum arbetar mot specifika mål. Längden på perioden varierar men brukar vara mellan 1-4 veckor.

• EER-diagram - Står för Enhanced Entity-Relationship model. Modell över vilka ta-beller och kolumner som ska finnas med i en databas och vilka relationer dessa tata-beller har med varandra.

Kapitel 2

Bakgrund

I detta kapitel beskrivs bakgrunden till kundens beslut att beställa projektet. Utöver det så beskrivs också övergripande de erfarenheter som teamet hade när de gick in i projektet.

2.1

Processen idag

Planering av operationer på ett sjukhus sker i en mycket komplex miljö. Det finns väldigt många resurser som måste koordineras för att allt ska fungera på rätt sätt. I dagsläget finns nödvändig information om detta i olika system, ibland finns det inte i något system alls utan informationen finns bara “i huvudet” på de anställda. Detta skapar en situation där det är svårt att få en överblick över den information som finns om resurser och deras tillgänglighet vid olika tider.

Det är mer än bara en operationssal och en kirurg som ska finnas tillgängliga för att en operation ska kunna genomföras. Det krävs ofta att ett antal prov har tagits på patienten före operationen. Därefter ska patienten förberedas inför operationen. Vilka förberedelser som ska göras beror både på vilken patient det är och vilken operation det är som ska utföras.

Sedan är det själva operationen som ska genomföras. I vissa fall krävs det flera olika kompe-tenser på plats i operationssalen och då måste dessa kunna bokas i förväg. Det krävs även olika uppsättningar av verktyg och specialutrustning för olika operationer. Patienten måste givetvis också ha en plats att återhämta sig på efter operationen, en så kallad postoperativ vårdplats.

2.2

Projektet

För att lösa detta problem behövs ett system som kan visualisera alla resurser och hitta lediga tider för olika typer av operationer baserat på tillgången av dessa resurser.

Ett stort och nytt system är under utveckling där schemaläggningsstöd är en del i ett större sammanhang. Projektet som beskrivs i denna rapport är avsett att vara en prototyp för att testa vilka funktioner som är viktiga och även hur dessa kan implementeras i ett användargränssnitt som är lättarbetat och effektivt. Det är därför ett primärt fokus på funktioner och gränssnitt över robusthet och säkerhet.

2.3

Gemensamma erfarenheter

Teamet hade vid projektets start tidigare erfarenheter i diverse programmeringskurser i Java, C++ och Python. Samtliga medlemmar har även läst en kurs i programutvecklings-metodik för att lära sig teori om hur man arbetar i mjukvaruprojekt. Medlemmarna har även fått praktiskt erfarenhet av att arbeta i projekt, D-studenterna genom kursen kon-struktion med mikrodatorer och medlemmarna från U-programmet genom ett AI-projekt.

Kapitel 3

Teori

Detta kapitel beskriver teorin bakom de olika metoder och verktyg som har använts för att utveckla och färdigställa projektet.

3.1

Scrum

Scrum är en agil utvecklingsmetodik som innehåller tre parter: produktägaren, scrummäs-taren och utvecklingsteamet. Produktägaren är den person som kommer med en beställning till utvecklingsteamet. Scrummästaren arbetar för att Scrum-metodiken ska upprätthållas och ser, tillsammans med produktägaren, till att underhålla backloggen så att utvecklings-teamet förstår vad som ska göras och så att arbetet kan fortgå.

Utvecklingsteamet är själva kärnan i Scrum-metodik, det är teamet som bestämmer vilka uppgifter som ska utföras under en sprint och hur de ska lösas. För en utförligare beskrivning av Scrum-metodik, se avsnitt 8.3.1.

3.2

GitLab

GitLab är en webbtjänst för hantering av data som använder versionshanteringsprogrammet Git. Medlemmar i ett GitLab-projekt kan lägga till och ändra i filer. Med Git arbetar varje medlem i ett projekt på en lokal kopia av data som finns på GitLabservern för att sedan skicka upp de ändringar man gjort till servern. Git fungerar på så sätt att alla ändringar sparas. Det betyder att om någon skulle göra en ändring som har oönskad effekt kan man enkelt gå tillbaka till en tidigare version av den data som finns på servern.

Git har stöd för något som kallas grenar, en gren kan beskrivas som en kopia av projektets data, vanligtvis av den data som finns i projektets huvudgren. När en ny gren har skapats sker alla ändringar som görs på den nya grenen. Det finns flera fördelar med att arbeta i grenar. För det första möjliggör det parallellt och strukturerat arbete då man kan namnge en gren så att namnet motsvarar ändringarnas syfte. Till exempel kan det vara namnet på någon ny funktionalitet.

Vidare gör det inget om en gren inte fungerar i sitt nuvarande tillstånd. Om du arbetar med en gren så kan kollegor fortfarande arbeta med andra grenar när du testar nya saker. För det andra kan man genom GitLab skapa sammanslagningsförfrågningar för att väva samman två grenar. Fördelen med det är att det på ett väldigt enkelt sätt går att se vilka ändringar som har gjorts på den nya grenen och vad som kommer att uppdateras.

Det finns också möjlighet att ärendehantera med hjälp av Git. Då skapar en person ett ärende om att personen t.ex. har hittat en bugg eller att personen anser att en ny funktio-nalitet ska implementeras. Sedan finns dessa ärenden sparade på projektets sida på GitLab så att medlemmar kan se och hantera dem. [2]

3.3

Webstorm

Webstorm är en utvecklingsmiljö skapad av programvaruutvecklaren JetBrains som är an-passad för JavaScript och webbutveckling. Den har även stöd och hjälp för relaterade språk som HTML, CSS och TypeScript. Till dessa språk finns smidiga hjälpfunktioner som kod-komplettering, kraftfull navigering, feldetektering i realtid och refaktorisering.

För populära miljöer och ramverk som Node.js, Angular och React finns det inbyggd as-sistans direkt i Webstorms gränssnitt. Det finns även grafiskt gränssnitt som assisterar användning av versionhanteringssystem som till exempel Git.[3]

3.4

Node.js

Node.js är en asynkron och händelsedriven miljö som tillåter körning av JavaScript utanför webbläsare. Node är designat för att skapa skalbara nätverksapplikationer men kan lika väl användas för att skapa andra typer av system och applikationer. [4]

Node.js har även sin tillhörande pakethanterare, Node Package Manager (NPM), som är det största ekosystemet för bibliotek med öppen källkod. [5] I NPM finns det bland annat paket för Angular, Sequelize och för hantering av HTTP och MySQL.

3.5

Angular

Angular är ett ramverk för webbutveckling med en komponentbaserad arkitektur som an-vänts till projektets front-end.

Komponenterna i Angular består i huvudsak av tre delar: • HTML-mall

• CSS-fil

• TypeScript-klass

HTML-mallen beskriver vilket grafiskt innehåll som ritas upp för användaren. HTML-koden som skrivs i Angular är utökad med Angular-specifik funktionalitet. Detta gör den kraft-fullare än vanlig HTML-kod.

CSS-filen styr det grafiska innehållet mer detaljrikt. CSS står för Cascading Style Sheets och tillför möjligheter att justera innehållets färg, placering, textstorlek eller typsnitt och andra grafiska egenskaper.

TypeScript-klassen innehåller logik kopplad till det grafiska innehållet hos en specifik kom-ponent. TypeScript är ett programspråk som utökar funktionaliteten hos JavaScript med bland annat statisk typning. Även Angulars tjänster är skrivna i detta programspråk. Utöver komponenterna finns även tjänster som tillhandahåller funktionalitet som inte är kopplad till någon särskild komponent. Mer om Angular finns att läsa i avsnitt 12.4.1.

3.6

Model-View-Controller

Designmönstret MVC för användargränssnitt möjliggör separation av hur gränssnittets data representeras internt från sättet datan visas upp för användare. Designmönstret delar upp

gränssnittet i tre delar, Model, View och Controller.[6] Delarna beskrivs nedan:

• Model innehåller gränssnittets data och logik för att manipulera datan. Denna del motsvaras av Angulars tjänster.

• View presenterar data från Model för användaren. Denna del motsvaras av HTML-mallen i en Angular-komponent.

• Controller hanterar kommunikation mellan användare och Model. Denna del motsva-ras av TypeScript-klassen i en Angular-komponent.

Det system som tagits fram implementerar alltså designmönstret MVC utgående från de verktyg och den arkitektur Angular tillhandahåller.

3.7

MySQL

MySQL är ett relationsdatabashanteringssystem för att skapa och behandla data. För att hålla reda på information lagrar MySQL data i tabeller. En tabell kan liknas vid en model av ett verkligt objekt. Exempel på detta är en patient, en bokning eller en sal. [7] Tabellen innehåller en kolumn för varje attribut som objektet har, till exempel ett namn och ett personnummer. Detta innebär att varje rad i tabellen motsvarar en unik entitet av det modelerade objektet. Det vill säga en specifik patient eller en specifik sal.

Tabeller kan även kopplas ihop med så kallade relationer. På så sätt kan till exempel en specifik bokning kopplas ihop med en specifik patient. Detta fungerar genom att alla tabeller har en unik nyckel. Nyckeln kan vara vilket attribut som helst så länge det har ett unikt värde för alla objekt i tabellen. En tabell kan ha flera nycklar men den nyckel som används för relationer kallas för primary key eller primärnyckel på svenska.

Primärnyckeln kan användas för att unikt identifiera ett visst objekt i tabellen. Denna egenskapen används för att koppla ihop olika objekt från olika tabeller. Detta går att göra på många olika sätt men i grunden används värdet på primärnykeln för ett visst objekt som värde för ett attribut i ett annat objekt. Ett exempel är att tabellen bokning kan ha ett attribut som kallas ’patient’. När en ny boking skapas används då värdet för primärnyckeln till den specifika patienten för att koppla patienten till den nya bokningen.

Relationer är mycket användbara då de tillåter att datan filtreras och presenteras på ett effektivt sätt så att det är enkelt att hitta den data som behövs.

För att interagera med MySQL används språket Structured Query Language (SQL). I SQL kan kommandon skrivas både för att mata in och begära ut olika data. Även om SQL är väldigt kraftfullt så har vi i det här projektet valt att använda oss av Sequelize.

3.8

Sequelize

Sequelize är ett ORM-system för Node.js som stödjer dialekterna PostGreSQL, MySQL, SQLite och MSSQL. [8] ORM står för Object-relational mapping och är en teknik som tillåter hämtning och manipulering av data i en relationsdatabas med hjälp av objekt och objektorientering. Detta innebär att ingen användning av SQL krävs i Sequelize, dock möj-liggör den fortfarande att köra normala SQL-frågor.

I Sequelize används modeller och associationer för utformning eller beskrivning av databa-sen. Det går antingen att manuellt skapa modellerna och associationerna utifrån en existe-rande databas eller att låta Sequelize generera databasen utifrån dem.

Modellerna definierar de objekt som används för att manipulera och läsa från databasen. Varje modell beskriver attributen i sin motsvarande tabell och för att beskriva relationer mellan olika modeller används så kallade associationer. Med hjälp av associationerna kan en till en, en till många och många till många-relationer mellan tabeller beskrivas.

Ändringar i databasens struktur kan hanteras genom att använda migrationer i Sequelize. Dessa beskriver dels hur ändringen utförs och dels hur den ångras. Genom att utföra dem i ordning kan man byta mellan alla tidigare versioner av databasen. [9]

För att fylla databasen med initial data har Sequelize så kallade seeds. Dessa är script som både kan utföras och ångras. De används främst för att lägga in statisk data i databasen men kan även skrivas för att generera data.

Kapitel 4

Metod

Metodkapitlet beskriver hur arbetsgången i projektet har gått till.

4.1

Projektorganisation

Projektgruppen bestod av sju studenter på Linköpings universitet. Projektet hade även en handledare som fanns tillgänglig om problem skulle uppstå. I detta avsnitt beskrivs hur organisationen var uppbyggd med de olika roller som ingick, hur möten gick till, dokumen-tation av projektet och ett avsnitt om kompetensutveckling.

4.1.1

Roller

I projektgruppen hade varje person en specifik roll. Dessa roller innebar att man hade ett antal specifika uppgifter att utföra och ansvar att upprätthålla. Nedan beskrivs dessa roller och vad de innebar.

Teamledare

Teamledaren har ansvaret för att leda arbetet i gruppen och att gruppen når de mål som har satts upp. För att hjälpa gruppen med detta ska teamledaren coacha gruppen samt se till att de processer som är uppsatta efterföljs och att gruppen har en trevlig arbetsmiljö. Teamledaren är också representant för teamet utåt och kontaktperson för gruppen mot examinator, handledare eller annan person som kan tänkas vilja ha kontakt med gruppen. Teamledaren har även ansvaret för att en projektplan ska skrivas i förstudien av projektet och har dessutom sista ordet om det skulle uppstå en situation där gruppen är oense eller då en omröstning i gruppen skulle bli oavgjord.

Analysansvarig

Analysansvarig är den person som håller den huvudsakliga kontakten med kunden. Personen tar reda på vad kunden är ute efter och arbetar därefter med att analysera och sammanställa de kundens behov till en kravspecifikation för projektet. Om det skulle vara så att krav och behov från kunden är otydliga för gruppen är det analysansvariges uppgift att tolka dessa krav åt resten av gruppen så att de är förståeliga och så att kunden inte missuppfattas. För att både projektgruppen och kunden ska bli nöjda är analysansvarig ansvarig för för-handling mellan de båda parterna. Det ska leda till en acceptabel kompromiss mellan vad kunden vill att projektet ska åstadkomma och vad gruppen tror att man kan åstadkomma. Den analysansvarige har mycket kontakt med arkitekten vid utformandet av arkitekturen för produkten, detta så att de krav som är uppsatta blir uppfyllda. Under implementations-fasen ska det finnas en god kontakt med ansvarig testledare. Det är viktigt eftersom när test utförs ska det säkerställas att funktionaliteten och designen stämmer överens med kraven i kravspecifikationen.

Arkitekt

Arkitekten har ansvaret för att produkten får en stabil arkitektur. Ansvaret för att göra övergripande teknikval ligger på arkitekten och i tekniska frågor så är det arkitekten som

har det sista ordet, bortsett från teamledaren. För att göra dessa teknikval så förväntas det av arkitekten att komponenter och gränssnitt identifieras och att de görs tydliga för gruppen. Denna bakgrundskunskap som arkitekten införskaffar gör att denne är en styrande röst och har möjlighet att kunna kommunicera bärande idéer.

Arkitekten håller en god kontakt med analysansvarig. Detta för att kunna skapa en arkitek-tur som bygger på och upprätthåller de krav som finns från kunden, men det gäller också att arkitekten genom analysansvarig kommunicerar med kund i de fall det finns krav som inte är möjliga rent kunskaps- eller teknikmässigt.

Utvecklingsledare

Utvecklingsledaren har ansvar för att skapa en mer detaljerad design av produkten. Under utvecklingsfasen i projektet så leder och, vid behov, fördelar utvecklingsledaren arbetet så att allting ska gå så smidigt som möjligt. Denna roll har även ansvaret för att fatta beslut om vilken utvecklingsmiljö som ska användas under projektet.

I projektet som hör till denna rapport så är alla i gruppen delaktiga vid utveckling vil-ket innebär att utvecklingsledaren kommer leda samtliga personer, oavsett vilken roll de innehar.

Testledare

Testledaren är den person som ansvarar för att produkten testas enligt en standard som kan säkerställa systemets funktionalitet och uppfyllnad mot de mål som finns uppsatta. För att säkerställa detta och den kvalitet som produkten ska upprätthålla så testas kvalitetskrav tillsammans med kvalitetssamordnaren.

Som testledare är det bra med viss distans till det som testas då beslutet om vilka delar av systemet som anses testade och färdiga ligger hos denna person. Testledaren ansvarar även för att skriva en testplan och en testrapport.

Kvalitetssamordnare & Dokumentansvarig

Den sammanslagna rollen kvalitetssamordnare & dokumentansvarig går ut på att kunna säkerställa att kvalitet och dokumentation upprätthålls och skrivs under projektets gång. Kvalitetssamordnare tittar på den budget som projektet har och hur mycket av detta man kan lägga på just kvalitet.

Den dokumentansvarige ser till att det finns dokumentmallar för de dokument som ska skrivas. Rollen innefattar även ansvar att se till att det tas fram en logotyp för projektet och att gruppen kan leverera till de deadlines som existerar.

Denna sammanslagna roll arbetar mycket med konfigurationsansvarig så att båda är överens om versionshantering och tillvägagångssätt vid produktsläpp.

Konfigurationsansvarig

Konfigurationsansvarig har ansvaret för att produkten som skapas versions- och konfigura-tionshanteras på ett korrekt sätt. Rollen går ut på att bestämma vilka arbetsprodukter som ska versionshanteras och vara med i en specifik utgåva. Då konfigurationsansvarig ser till att version- och konfigurationshantering sköts på ett korrekt sätt så ansvarar denne också för att välja de verktyg som ska användas för versionshanteringen.

Denna roll arbetar mycket med utvecklingsledare och dokumentansvarig då dessa två är ansvariga för utveckling av produkter och dokument som ska ingå i olika utgåvor.

4.1.2

Möten

Gruppen hade möte nästan en gång om dagen för att uppdatera varandra om vad man har gjort, vad man skulle göra härnäst och om man hade några problem. Varannan vecka hade gruppen ett längre möte där man redovisade vad som hade presterats, vad som gått bra/kunde ha gjorts bättre och vad man ska göra under kommande två veckor. Dessa möten följde Scrum-metodik, se avsnitt 3.1.

Utöver Scrum hade gruppen möte med handledaren en gång i veckan för att uppdatera varandra och handledaren om statusen för projektet. Till dessa möten skickades en dagord-ning ut av teamledaren i god tid innan mötet. Dagorddagord-ningen bestod av ett antal punkter som skulle behandlas under handledarmötena. Utöver dessa punkter hade medlemmar i projektgruppen samt handledare möjlighet att tillföra punkter på dagordningen, deadline för detta var 12.00 dagen innan respektive möte.

Slutligen höll projektgruppen möten med kund med jämna mellanrum där några personer från projektgruppen träffade några av de involverade personerna på Region Östergötland. Dessa möten gick ut på att uppdatera kunden om statusen för projektet, utbyta idéer och se till att projektgruppen och kund var på samma spår.

4.1.3

Dokumentation

För hantering av interna dokument har gruppen främst använt sig av Google Drive. Detta innefattar bland annat protokoll från handledarmöten, gruppkontrakt, veckorapporter och tidsrapportering.

Externa dokument som har lämnats in i diverse iterationer har gruppen producerat i LaTeX och versionshanterat med hjälp av Git.

4.1.4

Kompetensutveckling

Vid utveckling av kompetens och för att kunna bevara och dela erfarenheter med varandra har gruppen arbetat på några olika sätt.

Om gruppen behövde grundläggande kunskap i något verktyg eller metod gick man tillväga så att en person samlade in kunskap om det aktuella området och sedan höll personen en genomgång för gruppen innan verktyget eller metoden började användas i projektet. Exempelvis så har det varit genomgångar i Git, Scrum och Angular.

Vidare så ägde dagliga scrum-möten rum där gruppmedlemmarna delade med sig vad de gjort och vilka erfarenheter de fått ut av detta men samtal och diskussioner fördes även mellan gruppmedlarna kontinuerligt. Utöver det så var det upp till var och en att införskaffa den kunskap som behövdes för att kunna genomföra projektet.

4.2

Utvecklingsmetod

I början av projektet hade inte projektgruppen så mycket struktur i arbetet och större delen av gruppen arbetade med konfigurering av diverse verktyg som användes i projektet till exempel Git, LaTeX och Google Drive.

Tre veckor efter projektets start hade projektgruppen ett möte med kunden. Under mötet kom frågan upp gällande vilket arbetssätt vi skulle använda oss av och kunden föreslog Scrum. Teamledaren i gruppen gjorde efterforskningar om hur Scrum fungerar och gav en presentation för gruppen där slutsatsen var att Scrum fortsättningsvis skulle användas som utvecklingsmetod i projektet.

Tabell 4.1: Dokumentation i förstudien

Dokument Beskrivning

Projektplan Projekt- och arbetsgång

Kravspecifikation De krav som finns på produkten Kvalitetsplan Försäkring av hög kvalitet i projektet Statusrapport 1 Statusrapport över arbetet i iteration 1 Systemanatomi Skiss på hur systemet ska se ut Rapporthalva av kandidatarbetet Projektet fram till slutet av iteration 2

Arkitekturdokument Beskrivning av systemet Testplan Hur testning av systemet ska gå till Testrapport Testning under iteration 2 Utvärdering av iteration 2 Hur arbetet gick under iteration 2

4.3

Förstudie

Under förstudien, som var uppdelad i två iterationer, arbetade gruppen väldigt mycket med dokumentation som skulle ligga till grund för design och implementation av systemet. Ett flertal dokument utformades. Dessa är listade i tabell 4.1.

Under iteration två lämnades projektplan, kravspecifikation och kvalitetsplan in en andra gång så att handledaren fick se hur de hade utvecklats.

Utöver denna dokumentation arbetade gruppen mycket med kompetensutveckling för att förstå det system och de verktyg som skulle användas under design- och implementations-fasen. Gruppmedlemmar höll genomgångar av Git och Scrum så gruppen skulle få grund-läggande kunskaper och kunna applicera dessa verktyg.

Under förstudien hade gruppen även flera möten med kund för att få information om vad kunden ville ha för typ av produkt så att en kravspecifikation kunde utformas.

4.4

Design

Då kravspecifikationen var färdigställd var det dags för projektet att gå in i designfasen. Under fasen så låg fokus på två saker, grafisk design och mjukvarudesign.

4.4.1

Grafisk design

För att bestämma den grafiska designen av produkten skapade samtliga medlemmar i pro-jektgruppen en egen pappersprototyp av hur man tänkt sig att produkten skulle kunna se ut. Gruppen diskuterade de olika förslagen och kombinerade idéer till tre olika alternativ som redovisades för kund.

Kunden gav återkoppling på de olika alternativen och utifrån detta skapade gruppen en ny prototyp som efter ett ytterligare möte resulterade i den slutgiltiga designen för produkten (figur 5.1).

Kvaliteten på designen planerades att testas med hjälp av ett användbarhetstest. Testet består av ett formulär som värderar de olika grafiska komponenterna på en skala mellan ett och fem. Utifrån svaren skulle gruppen få en uppfattning om vilka komponenter som upperätthåller en lämplig standard att implementeras i slutprodukten.

4.4.2

Mjukvarudesign

Samtidigt som en grafisk design togs fram så arbetade projektets arkitekt och utvecklingsle-dare på att ta fram designen för mjukvaran. En systemanatomi (figur 5.5) och en systemskiss (figur 4.1) skapades för att få en överblick på hur systemet skulle se ut.

Figur 4.1: Systemskiss

Det skrevs även ett arkitekturdokument där de olika designbesluten som fattats beskrevs och motiverades. Lösningar som övervägdes men förkastades finns också beskrivna i det dokumentet.

Den mjukvarudesign som togs fram i projektets inledande skede var något översiktlig. Den kompletterades under projektets gång när det blivit klarare vilka mjukvarumässiga pro-blem och utmaningar projektgruppen stod inför. Detta då projektmedlemmarna förvärvade ytterligare kunskaper om hur webbutveckling fungerar.

Besluten om mjukvarudesign fattades ofta utgående från den pappersprototyp som tagits fram i samband med den grafiska designen och demonstrationsmöten med kund.

4.5

Utveckling

När designfasen var över gick gruppen in i projektets utvecklingsfas. Gruppen delades upp i två undergrupper där den ena fokuserade på front-end och den andra på back-end.

4.5.1

Front-end

Arbetet började med att implementera designen för det grafiska gränssnittet med hjälp av Angular-komponenter. Efter det så implementerades logiken för de komponenterna. Slutli-gen sammankopplades det med arbetet gruppen i back-end utfört. Gruppen växlade mellan

parprogrammering och enskild programmering beroende på vad som skulle göras.

4.5.2

Back-end

Figur 4.2: EER-diagram

När utvecklingen av back-end startade skapades först ett EER-diagram över den databas som produkten skulle använda sig av för att lagra data (figur 4.2). Sedan översattes

dia-grammet till kod, som skrevs i Javascript med hjälp av Sequelize. Gruppen skrev ett API som också implementerades i back-end-koden så att man enkelt skulle kunna hämta och modifiera data i databasen.

4.6

Insamling av erfarenheter

Under projektets gång så har gruppens erfarenheter samlats in på främst två sätt. Dels ge-nom att dela erfarenheter relaterade till kunskap ige-nom gruppen vid de olika presentationer som medlemmarna haft för varandra och dels genom att regelbundet utvärdera arbetet som skett. Båda dessa metoder har använts för att sprida erfarheter och kunskap till hela grup-pen. Utvärderingarna beskrivs i mer detalj i nästa stycke och kunskapsdelningen beskrivs i del 4.1.4.

Det har inte skett någon skriftlig dokumentation av erfarenheterna under projektets gång utan gruppen har istället sammanfattat alla erfarenheterna i slutet av projektet och besrivit dem i denna rapport, främst i del 5.2.

4.7

Utvärdering

Under projektets gång utvärderade gruppen arbetet kontinuerligt. Gruppen gjorde även en utvärdering i slutet av projektet.

4.7.1

Sprintutvärdering

Gruppen arbetade med tvåveckors-sprintar, vilket innebar att det gjordes en sprintutvär-dering varannan vecka. Under utvärsprintutvär-deringen gick gruppen igenom vad som hade gått bra under de två veckor som gått och vad som inte gick lika bra. Gruppen listade vad som hade kunnat förbättras och valde sedan ut 2-3 punkter att arbeta med under nästkommande sprint. Gruppen diskuterade även hur arbetet hade gått med de punkter man arbetat med under föregående sprint.

4.7.2

Utvärdering av projektet

I slutet av arbetet utförde gruppen en utvärdering av projektet i sin helhet. Där reflekterade gruppen över resultatet, hur arbetet hade gått och vad man hade kunnat göra bättre.

Kapitel 5

Resultat

Det här kapitlet beskriver resultatet av den mjukvara som har utvecklats och de erfarenheter teamet har samlat på sig under projektets gång.

5.1

Systembeskrivning

Systemet som skapats består av två separata delar, en back-end och en front-end.

5.1.1

Front-end

Projektets front-end utvecklades i ramverket Angular. Front-end använder sig därför av den komponentbaserade arkitektur som starkt förordas av ramverket. Systemets front-end använder Angulars arkitektur för att implementera designmönstret MVC (se 3.6).

Det grafiska innehållet i projektets front-end är uppdelat i komponenter som uppdateras eller byts ut till andra komponenter när användaren interagerar med systemet. De kompo-nenter som finns överst i applikationens komponenthierarki är tomma behållare vars enda syfte är att separera applikationens olika beståndsdelar från varandra. Inuti dessa har sedan komponenter med faktiska funktioner, som knappsatser eller sökrutor, placerats.

Applikationen består av flera olika vyer, där vissa av vyerna ska visas upp i samma behållare men vid olika tillfällen, beroende på vilken vy användaren för stunden är intresserad av. För att byta mellan vyerna används Angulars tjänster. Tjänsterna är inte direkt kopplade till någon specifik komponent och används därför för att kommunicera mellan komponenter i olika delar av komponenthierarkin.

All den data om patienter, salar och utrustning som användaren är intresserad av finns på en server i projektets back-end. Därför är det nödvändigt med kommunikation mellan de båda delarna. Från projektets front-end sköts kommunikationen med AJAX-anrop. Dessa anrop sker i tjänster för att de ska vara tillgängliga för alla komponenter som behöver tillgång till data av olika sorter.

5.1.2

Back-end

Back-end i projektet är en server som har två huvuduppgifter. Den första är att vara värd för klienten så att den kan kommas åt av flera användare och datorer över nätverk. Den andra uppgiften är att ha en databas med tillhörande webb-API. Databasen används för att hantera all data som behövs för schemaläggningen - bland annat operationsbeslut, kirurger, resurser och bokningar. Ett webb-API tillåter klienten att kunna logga in och sedan hämta och modifiera denna data.

Servern är byggd på miljön Node.js och är skriven i JavaScript. Den använder sig av Node.js-biblioteket Express för den statiska leveransen och klienten och för att definiera HTTP-API:t. För hantering av databasen används i grunden MySQL men även ORM-biblioteket Sequelize i Node.js. Sequelize tillåter objektorienterad hantering av databasen och tar bort behovet att använda direkta SQL-frågor. All testdata som används i prototypen läggs också

in i databasen med hjälp av seeds i Sequelize. Mer om seeds och Sequelize går att läsa i avsnitt 3.8.

Hela API:t i servern skyddas bakom autentisering. Detta görs med hjälp av Node.js-biblioteket Passport och ser till att ingen data i databasen kan kommas åt eller modifieras utan inlogg-ning.

5.1.3

LoFi-Prototyper

Figur 5.1: Sista LoFi-prototypen

Under projektets andra iteration utvecklades tre olika LoFi-prototyper. Dessa LoFi-prototyper designades för att visa på olika designalternativ för användargränssnittet. Ett exempel på detta är informationen som var med i listan över beslutade operationer.

I en av prototyperna identifierades patienten som hörde ihop med beslutet med namn, den andra med personnummer. I den tredje LoFi-prototypen fanns inget som identifierade patienten utan enbart information om vilken typ av operation det var. På liknande sätt utvärderades olika sätt att visualisera lediga tider i schemat samt olika sätt att anpassa sökparametrarna för en sökning efter lediga tider.

När prototyperna visades för kunden kunde alternativen sållas bort och en tydligare bild av behoven framträdde. Till exempel gick det snabbt att konstatera att användarna ville ha både personnummer och namn för att identifiera patienter.

Den första iterationen av prototyper användes sedan för att ta fram en ny LoFi-prototyp med enbart mindre designalternativ som visades för tre olika operationsplanerare. (Figur 5.1 illustrerar en bild av den sista Lofi-prototypen.)

Figur 5.2: Gränssnittet

5.1.4

Grafiskt gränssnitt

Då arbetet med prototyper var klart inleddes implementationen av designen i form av de grafiska komponenterna. Det här resulterade i en komplett webbsida med tre olika huvud-komponenter: sidopanelen, informationslisten och den huvudsakliga innehållsrutan. Arbetsflödet i appen börjar med att användaren loggar in med sina inloggningsuppgifter. Därefter presenteras vyn som visas i figur 5.2.

Sidopanelen

När användaren loggat in presenterar sidopanelen alla beslut som finns att planera (figur 5.3a). Ett beslut visualiseras som ett kort som innehåller en mängd viktiga data som pati-entens namn och personnummer, hur långt det är innan operationen bör ske och även vilken typ av operation det gäller samt vad anledningen är till att operationen behövs. En akut operation är tydligt markerad med rött för att det enkelt ska gå att se att det är viktigt att boka in denna så snart som möjligt.

Det går även att söka i listan. Dessutom kan användare filtrera listan på olika kriterier och sortera den.

När användaren klickar på en patient så visas en detaljvy för patienten (figur 5.3b). Här kan användaren se mer detaljerad information om beslutet som hur lång tid operationen beräknas ta, hur lång förberedelsetid som krävs med mera. Det går också att se en lista med alla de verktyg och material som krävs.

Längst ner finns det även en ruta med sökkriterier för att filtrera den schemavy som visas i huvudfönstret så att en ledig tid kan hittas.

(a) Beslutsvyn (b) Planneringsvyn

Figur 5.3: Sidopanelens två vyer.

Informationslisten

Informationslisten är den smala rad längst upp gränssnittet i 5.2. Informationslisten är till för att alltid visa information om den patient som för tillfället håller på att bokas in. Så snart ett beslut har valts i sidopanelen så visas patientens namn och personnummer i informationslisten.

I informationslisten syns det också vilken användare som är inloggad längst till höger och där finns även en knapp för att logga ur aktuell användare.

Huvudfönstret

I huvudfönstret visas i grundutförandet en månadsvy över där det går att se hur många operationer som är inbokade på olika dagar. Om en dag markeras så visas fler detaljer över de operationer som är inbokade på den dagen. När en patient har valts i sidomenyn används månadsvyn för att välja vilken dag man vill boka in operationen. När en dag har valts skickas användaren vidare till spårvyn.

Spårvyn

Spårvyn, figur 5.4, visar ett antal konfigurerbara spår där varje spår motsvarar schemat för en viss resurs på den valda dagen. Dessa spår visas brevid varandra för att enkelt visualisera

de olika resurserna och på så sätt skapa en bra överblick över när de olika resurserna är lediga i relation till varandra. Det går att välja vilka resurser som ska visas, som salar, olika personer och verktyg.

Figur 5.4: Spårvyn

5.1.5

Systemanatomi

I första iterationen togs det fram en systemanatomi (se figur 5.5) som användes under projektets gång som ett hjälpmedel för att strukturera upp arbetet under utvecklingen. Den gav en översiktlig bild av vilken funktionalitet produkten skulle innehålla och hur de olika delarna samverkade med varandra. Utöver detta presenterades den i ett tidigt skede för kunden i syfte att säkerställa att projektgruppens syn på systemet stämde överens med kundens.

Figur 5.5: Systemanatomi

5.1.6

Värde för kund

Den produkt som har skapats är ett lättöverskådligt schemaläggningssystem för operationer. Systemet matchar väl den initila målbilden. Sedan har nya upptäckter under projektets gång gjort att systemet förmodligen behöver kompleteras avsevärt för att vara praktiskt användbart. Detta är dock inte ett stort problem då syftet var att skapa en prototyp (se 1.2).

Dokumentationen och processen under projektet har varit minst lika viktig för att ta reda på vad som kommer och inte kommer att fungera och ger stor insikt i hur systemet kan se ut och hur produkten kan förbättras i framtiden.

Vår förhoppning är att de arbetsdokument som vi tagit fram i gruppen som stöd under arbetet kan vara till hjälp för den fortsatta utvecklingen. Detta tillsammans med de officiella dokumenten borde skapa en solid teoretisk kunskapsgrund för vidareutveckling.

Vad gäller faktisk programvara så tror vi starkt på att det finns funktioner och element i vår design som bidrar till en ny syn på schemaläggning och som kan komma till användning antingen som vi implementerat dem eller som inspiration för andra nya sätt att bygga upp systemet.

Totalt sett medför detta att Region Östergötland kommer att ha en bra grund att utgå ifrån då deras projekt startar. Både projektledaren och andra aktörer för det större projektet kommer att kunna ta med sig många erfarenheter från det här projekt i och med att flera av dem har varit så delaktiga i vår process genom flera möten.

5.2

Gemensamma erfarenheter

I denna del kommer gruppens gemensama erfarenheter presenteras.

5.2.1

Tekniska erfarenheter

Under projektet har medlemmarna fått stor erfarenhet av webbprogrammering då ingen hade någon större erfarenhet av detta sedan tidigare. Gruppen har fått sätta sig in i HTTP-protokoll, databaser och ett flertal programspråk och ramverk. Även versionshantering med Git och GitLab har gruppen fått fördjupad kunskap inom.

Vid utveckling av front-end lärde sig gruppen att använda ramverket Angular och att programmera i HTML, CSS och TypeScript. För back-end behövde medlemmarna istället sätta sig in i JavaScript, MySQL-databaser och miljön Node.js med ett flertal tillhörande bibliotek.

Förutom tekniska erfarenheter har gruppen fått en större förståelse för hur sjukvården fungerar och att ett bra IT-system kan göra stor verklig skillnad. Gruppen har även fått praktiskt erfarenhet av att utöva Scrum. Det har varit seminarier där presentation och opponering ingick.

5.2.2

Kommunikation och planering

Det som förmodligen fungerade sämst i gruppen var kommunikation och planering. Det innebär inte på något vis att detta har gått dåligt. Däremot är det detta som gruppen har fått jobba hårdast med för att det ska lyckas. Arbetetes effektivitet är kraftigt beroende av dessa två komponenter. Det som gruppen har insett är att om det inte finns en bra planering så vet inte deltagarna vad de ska göra. Men ett annat problem är att det måste kommuniceras tydligt hur långt i planeringen de olika medlemmarna kommit. För att lyckas med detta har gruppen arbetat hårt med både kommunikation och planering och varje gång någon av delarna har fallerat så har det disskuterats och förbättrats.

5.2.3

Dokumentation

Dokumentation tar otroligt mycket tid att producera. Detta var något som gruppen inte var beredda på och till följd av detta gjordes vissa övergripande planeringsmisstag. Det hade tillexempel varit bra att börja med programmeringen tidigare, det vill säga innan dokumenten var färdigskrivna. Däremot har gruppen också insett den verkliga potentialen med bra dokument som beskriver ett projekt. Då gruppen väl började med programmeringen så gick det väldigt snabbt och effektivt eftersom så mycket av strukturen redan var bestämd.

5.2.4

Samlad kompetens

En annan stor erfarenhet som kom utav detta projekt var en insikt i hur mycket som kan åstadkommas genom att samla ihop de olika medlemmarnas olika kompetenser. Inte bara tidigare kunskap utan även genom aktivt delande av ny kunskap. Alla medlemmarna i detta projekt har uttryckt en känsla av ökat självförtoende i sin kapacitet som ingenjör under detta projekt.

5.2.5

Nyttan för kommande projekt

Av det som pressenterats i detta stycket är det främst de tre sista rubrikerna som gruppen bedömer som viktiga att ta med sig in i kommande projekt. Det är viktigt att hålla en bra stuktur för regelbunden planering och en bra stuktur för koninuerlig kommunikation. Dokumentation tar tid men är värt det i längden. Däremot är det viktigt att inte fastna

utan att komma vidare i tid. Till sist så tog gruppen med sig att samlad kompetens är en otrolig tillgång och om den används och delas rätt skapar det självsäkra individer som tillsammans bildar en stabil grupp.

5.3

Översikt över individuella bidrag

I denna del presenteras deltagarnas individuella bidrag översiktligt.

5.3.1

Teamledarens roll kombinerad med Scrum-metodik av Adam

Andersson

I Scrum-metodik finns det ingen ledare utan alla medlemmar i teamet är med och tar de beslut som ska göras. Denna studie är till för att utvärdera om det går att kombinera rollen teamledare med en projektgrupp som använder sig av Scrum-metodik och ändå kunna behålla syftet med de båda.

5.3.2

Versionshantering för ett mindre

mjukvaruutvecklingspro-jekt av Björn Hvass

Rapporten undersöker hur versionshantering kan användas i ett mindre mjukvaruutveck-lingsprojekt samt redogör för om det går att använda en arbetsmetodik effektivt i den här typen av projekt.

5.3.3

Effektivt val av aktörer för kravinsamling av Christoffer

Sjö-bergsson

Kan en strukturerad metod för urval och prioritering av krav och aktörer förbättra kraven i ett mindre mjukvaruprojekt?

5.3.4

Jämförelse mellan TypeScript och JavaScript av Henrik

Lind-ström

Denna rapport jämför språken TypeScript och JavaScript baserat på erfarenheter från pro-jektet och litteratur. Undersökningen fokuserar på TypeScript och JavaScripts olika typsy-stem - statisk respektive dynamisk typning. Inom detta är det påverkan på feldetektering, kodförståelse och produktivitet hos de två språken som behandlas.

5.3.5

Angular som webbutvecklingsplattform av Martin Persson

Denna rapport utvärderar vad valet av Angular som webbutvecklingsplattform tillfört pro-jektet och vilka faktorer man bör ta hänsyn till vid val av ramverk till webbutvecklingspro-jekt som liknar detta.

5.3.6

Prototyputveckling i ett kandidatprojekt av Niclas Byrsten

Denna rapport undersöker hur prototyper användes i projektet och vilka slutsatser som kan dras baserat på gruppens erfarenheter.

5.3.7

Kvalitetsförsäkrande metoder i ett småskaligt

mjukvarupro-jekt av Tor Utterborn

En undersökning om kvalitetsförsäkrande metoder i ett småskaligt mjukvaruprojekt där de två metoderna som undersökts är användandet av ramverket Angular samt de statiska

Kapitel 6

Diskussion

Detta kapitel tar upp diskussioner om resultatet av projektet och den metod som använts.

6.1

Resultat

I detta avsnitt så diskuterar vi de resultat som gruppen har kommit fram till.

6.1.1

Viktigaste lärdomar inför framtiden.

I början av projektet hade medlemmarna i gruppen olika erfarenheter som kom väl till nytta under projektets gång. Däremot var det ingen som hade en komplett bild. Den kunskap som saknades för många handlade om ett antal programspråk och ramverk som skulle användas. Det saknades också kunskap om arbetssätt för versionshantering och grupparbeten i större projekt. En av lärdomarna som gruppens medlemmar fick ut av projektet var erfarenheten av att sätta upp och gå igenom en sorts utbildningsfas. Utbildningsfasen varade under de första veckorna där gruppen hade ett antal interna utbildningsmoment. Det var allt ifrån programspråk som HTML, CSS, TypeScript, JavaScript och LaTeX till arbetssätt för Git. Även utbildning i ramverket Angular och arbetsmetodiken Scrum ingick i fasen.

Det som gruppens medlemmar kan ta med sig, något som vi tycker är viktigt och relevant för framtiden, är kunskapen och erfarenheten att sätta sig in i nya komplexa arbetssätt och metoder och att ta del av varandras befintliga kunskaper. Vissa var helt nya och andra stred mot gamla vanor. Att kunna göra sådana stora förändringar och ta in så stor mängd ny kunskap är viktigt för en ingenjör. Detta eftersom en ingenjör egentligen aldrig slutar att anpassa sig i sitt arbete.

Såklart var inte vår utbildningsfas felfri och plågades av avsaknad av kunskap om hur man ska strukturera och planera en sådan. En direkt effekt av det var att vissa moment missades och att andra täcktes bra av teorin men saknade en praktisk sida. Alla dessa misstag och lärdomar resulterade i att vi tillsammans har lärt oss otroligt mycket om vad det innebär att komma mer eller mindre blank till ett projekt.

Utöver detta får man ett nytt perspektiv på projektarbete när det inte finns någon an-nan som tillhandahåller material som säkerställer att projektet lyckas. Detta är vanligt i utbildningssammanhang och på grund av det är fria händer en enorm erfarenhet.

6.1.2

Har vi förbättrat något från tidigare projekt?

Den största förbättringen som gruppen har fått erfara jämfört med tidigare projekt är att arbeta strukturerat med Scrum. Gruppen gick inte in i projektet med tankar om någon specifik utvecklingsmetod som skulle följas. Några veckor in i projektet hade gruppen möte med kund där frågan kom upp om vilken utvecklingsmetodik vi skulle använda. Kunden informerade om att de hade erfarenhet av Scrum sedan tidigare och föreslog detta som metod att använda sig utav.

om hur metodiken fungerade. Efter en redovisning av teamledaren beslutade gruppen att börja använda Scrum för att kunna strukturera och följa upp arbetet.

Gruppen uppmärksammade ganska snabbt att Scrum var bra då det var enkelt att hålla koll på vad varje person arbetade med och om det fanns några hinder. Arbetssättet med iterationer var också väldigt bra för att, med hjälp av sprintplaneringar, få en syn på vad som behöver göras.

På det stora hela är gruppen mycket nöjd med att ha använt Scrum i detta projekt. Till skillnad från vattenfallsmodellen[10] är Scrum en väldigt bekväm metodik i mjukvaruprojekt då man arbetar agilt.

6.1.3

Val av Webbutvecklingsramverk

Under designfasens inledande skede hölls ett möte med kunden där projektgruppen fick veta att kunden i tidigare webbutvecklingsprojekt använt sig av ramverket Angular. Att en stor organisation med gott rykte som Region Östergötland använt Angular tidigare ingav förtroende för ramverket hos projektgruppen. Många av gruppens medlemmar saknade erfarenheter av webbutveckling. För att kompensera för detta såg gruppen möjligheter att dra nytta av kundens erfarenheter. Av denna anledning ansågs det passande att välja Angular som ramverk. Någon utförlig förstudie om vilket ramverk som bäst skulle passa gruppens behov utfördes inte.

Eftersom kunden inte ställt några uttryckliga krav på valet av ramverk hade andra val varit möjliga. Det finns ingen brist på webbutvecklingsramverk. Projektet hade säkert varit genomförbart även om något annat alternativ än Angular valts. Att utföra åtminstone en översiktlig utvärdering av Angular och en eller två konkurrerande webbutvecklingsramverk innan ett slutgiltigt beslut fattats kunde ha resultaterat i färre problem under utvecklings-fasen.

Projektgruppen var vid projektets slutskede överlag nöjda med valet av Angular. De flesta ansåg att det varit svårt att sätta sig in i hur Angular fungerar och bör användas. När de väl lärt sig detta så ansåg samtliga att den komponentstruktur Angular tillfört varit till gagn för projektet. Den hade medfört modularitet mellan olika komponenter, vilket bland annat underlättat parallellt arbete på front-end.

Att Angular har en ganska fix struktur var också en fördel för många av de mindre erfarna projektmedlemmarna. De hade oavsett val behövt sätta sig in i hur webbutveckling måste utföras. Att få riktlinjer från ramverket var alltså inte till någon nackdel för gruppen, även om det kanske irriterat mer erfarna webbutvecklare.

Sammanfattningsvis så var valet lyckat. Eftersom ingen förstudie angående val hade utförts så kunde det möjligtvis ha visat sig att Angular varit olämpligt för ett projekt med Aeons storlek. Att det inte blev så hade mer med tur att göra och mindre med gruppens förbere-delser. Gruppen utnyttjade heller inte kunden kompetens av ramverket, vilket varit ett av skälen till valet. Hade det gjorts hade inlärningsprocessen med all sannolikhet underlättats.

6.2

Metod

6.2.1

Projektorganisation

Rollerna i projektet var förutbestämda av kursen och kunde alltså inte förhandlas eller struktureras på ett annat sätt. Det var bra att rollerna var tydligt definierade och att de kom med vissa bestämda ansvarsområden. Det underlättade under projektets gång då det var tydligt vem som hade ansvar för att olika uppgifter blev utförda i tid.

Ett problem som upplevdes var dock att rollerna var strukturellt tyngre än projektet i sig. Det kändes med andra ord klumpigt och tungrott att använda sig av den rätta arbetsför-delningen baserat på de olika rollerna. Detta berodde förmodligen delvis på att alla utöver sina roller också behövde agera programmerare, designer, och andra roller som inte fanns specificerade från början.

En annan förklaring skulle kunna vara att projektets storlek inte passade organisationen. Den skulle förmodligen ha fungerat bättre i ett större projekt med fler deltagare.

De möten som gruppen hade regelbundet var väldigt användbara. Det gällde alla olika mötestyper men på olika sätt. De korta daily-Scrum-mötena var avgörande för att förmedla gruppens kortsiktiga framsteg, planering samt erfarenheter och problem. Vid vissa tillfällen gick det lite för lång tid mellan två av dessa möten och då märktes det direkt i gruppens produktivitet. För att uppnå maximal produktitvitet var det alltså nödvändigt att dessa möten hölls så ofta som möjligt.

Handledarmötena var till olika mycket nytta genom projektets gång. Generellt går det att säga att de var mer användbara precis innan och efter de olika inlämmningarna i projektet. Detta då de gav gruppen bra möjlighet att reda ut frågor inför inlämmningarna, samt få bra feedback efter inlämmningarna. Mellan inlämmningarna så var dessa möten ofta ganska korta och behandlade mest samma saker som kommit upp i de dagliga mötena. De fungerade då mer som ett tillfälle att rapportera status till handledaren.

Möten som delar av gruppen hade med kunden och potentiella användare var mycket gi-vande för projektets kravframtagning. Det som kom som lite av en överaskning var att kunden var väldigt bra på att få med flera personer med olika kompetenser på mötena. De från gruppen som var där saknade ibland erfarheten att på ett effektivt sätt utnyttja den existerande kompetensen. Trots detta gjorde den stora variationen hos de deltagandes kom-petenser att det framkom många olika idéer och förslag som snabbt drev designprocessen framåt.

Gruppen hade relativt stora svårigheter att balansera dokumentationsarbetet med design och programmeringsarbetet. Framförallt lades det mycket tid på dokumentation i början ut-an att programmera parallelt. Detta gjorde att programmeringen behövde ske på en kortare tid än vad som hade varit optimalt. Den primära anledningen till detta var förmodligen att gruppen saknade erfarenhet av projekt med denna nivå av dokumentationskrav. Det system som fanns för att sköta dokumentation fungerade oftast mycket bra och framförallt så var det väldigt bra att versionshantera slutrapporten i git då detta öppnade upp möjligheten att jobba med grenar i git på samma sätt som gruppen gjorde under utvecklingsarbetet med programmet.

6.2.2

Utvecklingsmetodik

Utvecklingsmetodiken Scrum var gruppen inne på ganska tidigt som ett alternativ men bestämde sig inte omgående. Det framkom dock efter ett av de tidigare mötena med kunden att de hade god kunskap om och erfarenhet av metoden och därför valde gruppen att ta till sig Scrum. De regelbunda dagliga mötena har skapat en bra informationsspridning av status, kunskap och planering. De längre och mer utförliga mötena för demo, utvärdering