Linköpings universitet SE–581 83 Linköping 013-28 10 00 , www.liu.se
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 16hp | Datateknik
2016 | LIU-IDA/LITH-EX-G--16/045--SE
Snowy
–
Visualisering av SNOMED CT:s data
Snowy
–
Visualization of SNOMED CT:s data
Carl Brage, Simon Hadenius , Daniel Johansson, Billy Krig,
Si-mon Lindblad, Emil Nilsson, Joacim Stålberg & Mattias
Ulm-stedt
Handledare : Anton Sundblad Examinator : Kristian Sandahl
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 enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för 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 admin-istrativ 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 sam-manhang 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 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 circum-stances. 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 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 con-sent 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 Uni-versity 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/.
c
Carl Brage, Simon Hadenius , Daniel Johansson, Billy Krig, Simon Lindblad, Emil Nils-son, Joacim Stålberg & Mattias Ulmstedt
Sammanfattning
Detta dokument beskriver ett kandidatexamensarbete som genomförts av åtta civilingenjörsstudenter från Linköpings
universitet. Examensarbetet bestod av att utveckla en webbapplikation för att möjliggöra navigation och visualisering av element ur
den medicinska databasen SNOMED CT samt deras relationer. Den första delen av dokumentet består av gruppens gemensamma arbete och erfarenheter för att uppfylla kundens givna krav samt själva processen om hur det är att arbeta i ett större mjukvaruprojekt. Den andra delen består av studenternas individuella bidrag till examensarbetet som berör något spridda ämnen men som har en anknytning till mjukvaruutveckling och projektarbete.
Projektidentitet
Namn Ansvar Epost
Carl Brage Utvecklingsledare carbr059@student.liu.se
Simon Hadenius Arkitekt simha713@student.liu.se
Daniel Johansson Analysansvarig danjo732@student.liu.se
Billy Krig Testledare bilkr720@student.liu.se
Simon Lindblad Teamledare simli746@student.liu.se
Emil Nilsson Konfigurationsansvarig emini215@student.liu.se Joacim Stålberg Kvalitetssamordnare joast229@student.liu.se Mattias Ulmstedt Dokumentansvarig matul773@student.liu.se
Innehållsförteckning
Sammanfattning iii Projektidentitet iv Innehållsförteckning v Figurer viii Ordlista ix 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 2 Bakgrund 3 3 Teori 5 3.1 SNOMED CT:s datastruktur . . . 5 3.2 Utvecklingsverktyg . . . 6 3.3 Projektdrivningsverktyg . . . 7 4 Metod 8 4.1 Utvecklingsmetod . . . 84.2 Metod för att fånga erfarenheter . . . 9
4.3 Testmetoder för att motverka felaktigheter i slutprodukten . . . 9
4.4 Arbetssätt i versionshantering . . . 10
5 Resultat 11 5.1 Systembeskrivning . . . 11
5.2 Värde för kunden . . . 12
5.3 Gemensamma erfarenheter . . . 12
5.4 Resultat för användningen av SEMAT Kernel ALPHA . . . 14
5.5 Utritning och exportering av diagram . . . 14
5.6 Översikt över individuella bidrag . . . 14
6 Diskussion 18 6.1 Resultat . . . 18
6.2 Metod . . . 20
6.3 Källkritik . . . 20
6.4 Arbetet i ett vidare sammanhang . . . 20
7 Slutsatser 21
A Hantering av situationsbaserade tester av Billy Krig 23 A.1 Inledning . . . 23 A.2 Bakgrund . . . 24 A.3 Teori . . . 24 A.4 Metod . . . 26 A.5 Resultat . . . 27 A.6 Diskussion . . . 28 A.7 Slutsatser . . . 28
B Vilka fördelar kan React ge i ett webbaserat projekt? av Carl Brage 29 B.1 Inledning . . . 29 B.2 Bakgrund . . . 29 B.3 Teori . . . 30 B.4 Metod . . . 31 B.5 Resultat . . . 32 B.6 Diskussion . . . 33 B.7 Slutsatser . . . 35
C Datavisualisering med D3 av Daniel Johansson 36 C.1 Inledning . . . 36 C.2 Bakgrund . . . 36 C.3 Teori . . . 37 C.4 Metod . . . 38 C.5 Resultat . . . 41 C.6 Diskussion . . . 42 C.7 Slutsatser . . . 43
D Versionshantering med arbetsflöden i projekt av Emil Nilsson 45 D.1 Inledning . . . 45 D.2 Bakgrund . . . 46 D.3 Teori . . . 46 D.4 Metod . . . 48 D.5 Resultat . . . 48 D.6 Diskussion . . . 48 D.7 Slutsatser . . . 49
E Kvalitet och kvalitetsarbetet i mjukvaruprojekt med fokus på inspektion av Joacim Stålberg 51 E.1 Inledning . . . 51 E.2 Bakgrund . . . 51 E.3 Teori . . . 52 E.4 Metod . . . 54 E.5 Resultat . . . 54 E.6 Diskussion . . . 56 E.7 Slutsatser . . . 58
F Dokumentskrivning i mjukvaruutvecklingsprojekt av Mattias Ulmstedt 60 F.1 Inledning . . . 60 F.2 Bakgrund . . . 61 F.3 Teori . . . 61 F.4 Metod . . . 62 F.5 Resultat . . . 62 F.6 Diskussion . . . 68 F.7 Slutsatser . . . 69
G Arkitekturbeslut av Simon Hadenius 70 G.1 Inledning . . . 70 G.2 Bakgrund . . . 70 G.3 Teori . . . 71 G.4 Metod . . . 72 G.5 Resultat . . . 72 G.6 Diskussion . . . 73 G.7 Slutsatser . . . 73
H Kommunikations- och projekthanteringsverktyg i ett distribuerat arbetssätt av Simon Lindblad 75 H.1 Inledning . . . 75 H.2 Bakgrund . . . 76 H.3 Teori . . . 76 H.4 Metod . . . 77 H.5 Resultat . . . 78 H.6 Diskussion . . . 80 H.7 Slutsatser . . . 83 Referenser 84
Figurer
3.1 Exempel på begrepp i SNOMED CT . . . 5
5.1 Översikt av systemet . . . 11
5.2 Översikt över applikationen . . . 13
5.3 Översikt av träddiagram i helskärmsläge . . . 15
5.4 Översikt av definitionsdiagram i helskärmsläge . . . 16
C.1 Kundens diagramförslag . . . 37
C.2 Vertikalt träd . . . 40
C.3 Horisontellt träd . . . 41
C.4 Eget implementerat koncept diagram . . . 42
E.1 Graf av rapporterade anomalier från inspektion 1. . . 55
E.2 Graf av rapporterade anomalier från inspektion 2. . . 56
E.3 Graf av rapporterade anomalier från inspektion 3. . . 56
F.1 Trellotavla . . . 64 F.2 Svar på fråga 1 . . . 65 F.3 Svar på fråga 2 . . . 65 F.4 Svar på fråga 3 . . . 65 F.5 Svar på fråga 4 . . . 66 F.6 Svar på fråga 5 . . . 66 F.7 Svar på fråga 6 . . . 66
H.1 Grafen till vänster visar svaren på fråga 1. Grafen till höger visar svaren på fråga 2. 79 H.2 Grafen till vänster visar svaren på fråga 3. Grafen till höger visar svaren på fråga 4. 79 H.3 Grafen till vänster visar svaren på fråga 5. Grafen till höger visar svaren på fråga 6. 80 H.4 Grafen till vänster visar svaren på fråga 7. Grafen till höger visar svaren på fråga 8. 81 H.5 Grafen visar svaren på fråga 9. . . 81
Ordlista
Ord från ordlistan kommer att markeras som kurisva då de används för första gången i doku-mentet.
Agil utveckling Agil utveckling innebär att man under hela projektet planerar upp en kort tid frammåt i taget och hela tiden är öppen för ändringar i planen.
Backlog En lista över saker som behöver göras.
Back-end Det lagret av systemet som har hand om all bakomliggande data, i detta fall servern.
Black-box testing Denna typ av test innebär att testpersonen inte besitter någon kunskap om hur koden faktiskt ser ut.
Commit En commit i sammanhanget versionshantering innebär att man lägger till de än-dringar man gjort till det repository som man arbetar i.
Extreme Programming En agil utvecklingsmetod där ett av elementen är användningen av parprogrammering.
Front-end Det lagret av systemet som användaren interagerar med.
Gren(versionshantering) I versionshanteringssystem kan man dela upp utvecklingen i olika separata grenar som i slutändan slås ihop till ett system.
Kanban En metod för att visuellt hantera aktiviteter såsom vilka aktiviteter som ska göras, när de ska göras och hur de ska göras.
Pair programming Ën utvecklingsteknik där två programmerare arbetar tillsammans vid en dator.
Repository Ett repository i ett versionshanteringssystem är en kodbas där all kod och dess historik mm. sparas.
Scrum En agil utvecklingsmetod där ett av elementen är användningen av så kallade sprints. Sprint En sprint är ett tidsintervall, vanligen mellan 3-30 dagar där man på slutet har skapat
en användbar produkt som potentiellt är redo att släppas vidare.
SPA Single-page application. En hemsida som bara behöver laddas in en gång, när man öppnar sidan för första gången, och sedan laddar in det som behövs dynamiskt istället för att sidan behöver laddas om.
Token Data som genereras av servern och skickas till inloggade användare som fungerar som en slags temporär nyckel för användaren att identifiera sig mot servern med. Vattenfallsmodellen En utvecklingsmetod där man från början planerar upp hela projektet
i detalj.
Weekly scrum Ett tidsbegränsat möte som hålls varje vecka där grupppmedlemmarna går igenom vad som gjorts, vad de ska göra och om det finns några potentiella hinder i vägen för att de kunna uppnå de uppsatta målen.
1
Inledning
I detta kapitel ges en förklaring till projektet, vad det ska leda till och här presenteras även de frågeställningar som ska besvaras i rapporten.
1.1
Motivering
Vi har utvecklat en webbapplikation för att visualisera och arbeta med medicinsk data från SNOMED CT [1] där användaren själv får välja hur datan ska visualiseras. När man ska bygga upp en visualisering börjar man med att välja en term som ska visualiseras. Baserat på denna term kan man sedan välja vilka av begreppets relationer och delhierarkier som ska visas. Man kan navigera sig fram till olika begrepp, både grafiskt genom en lista eller via fritextsökning. När man har byggt upp en visualisering av datan kan man exportera den till två olika bildformat: SVG och PNG.
En sådan visualisering kan sedan användas för att diskutera medicinska situationer mel-lan läkare. Eftersom användaren själv väljer vad som ska visas kan diagrammen anpassas så att de visar en övergripande bild eller understryker specifika relationer, beroende på vad som ger värde för användaren. I rapporten går vi igenom hur vi lade upp arbetet med projektet, hur systemet är implementerat och hur det kan ge värde för användaren.
1.2
Syfte
Syftet med rapporten är att beskriva den webbapplikation som vi har skapat. Rapporten kommer att ta upp aspekter av hur applikationen är uppbyggd, vad den ger för värde för kunden samt vilka användningsområden som finns. Vissa delar kommer även att handla om de erfarenheter som gruppen har haft. Detta kommer både att vara erfarenheter inom de tekniska bitarna och erfarenheter om hur arbetet i grupp har fungerat med de processer som har använts.
1.3
Frågeställningar
1. Hur kan en webbapplikation som visualiserar SNOMED CT:s data implementeras så att man skapar värde för kunden?
1.4. Avgränsningar
2. Vilka erfarenheter kan dokumenteras från webbapplikationen som kan vara intressanta för framtida projekt?
3. Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel ALPHA:s? 4. På vilka sätt kan man rita ut interagerbara diagram för att underlätta exportering? 5. Hur underlättas kommunikationen inom gruppen genom användande av Slack jämfört
med mail?
6. Vilken nytta får man av att använda Trello som verktyg för Kanban?
1.4
Avgränsningar
Inga ekonomiska hänsynstaganden har gjorts utöver det att alla gruppens medlemmar har 400˘40 timmar var att distribuera på kursen. I studien studeras endast en grupp i kursen TDDD96 som går under perioden VT2016 vid Linköpings universitet och gruppen i fråga är grupp 5. Analysen är gjord efter denna enskilda grupps erfarenheter.
2
Bakgrund
SNOMED CT är en ordnad samling av medicinska termer som är byggd för att enkelt kunna bearbetas av olika system. Datan i SNOMED CT:s databas är den mest omfattande av sitt slag i världen [2], och underhålls av International Health Terminology Standards Development Organisation (IHTSDO) [3]. De släpper uppdaterade versioner två gånger per år. Dessa uppdateringar inkluderar nya termer, nya relationer och andra ändringar [4].
SNOMED CT används i över 50 länder och finns översatt till flera olika språk. Social-styrelsen ansvarar för den svenska översättningen och arbetar för att datan från SNOMED CT ska användas i hela landets vårdarbete [5]. SNOMED CT möjliggör ett entydigt sätt att dokumentera och analysera klinisk information, och tanken är att när det införs i sjukvår-den så kommer det underlätta standardiseringen av dokumentation. Enligt Socialstyrelsen så kommer detta innebära att:
• Klinisk information kommer att kunna beskrivas på en detaljerad nivå.
• Överföring av information mellan olika system kommer att underlättas. Detta gäller även i internationella sammanhang.
• Informationen blir mer relevant vid patientmöten.
• Patienten kommer inte att behöva upprepa vårdinformation vid olika vårdkontakter. • Det blir lättare att hitta klinisk information genom sökning.
• Det blir lättare att analysera datan både på en detaljerad och översiktlig nivå.
För att läkare och annan vårdpersonal ska få ut så mycket som möjligt av detta, kommer det att behövas en del olika verktyg som kan användas för att bearbeta denna data. Genom att använda en applikation där man skapar en visualisering av datan kan man skapa ett diskus-sionsunderlag när man behöver kommunicera klinisk information. När användaren får välja vilka relationer som ska visas och vilka delhierarkier som är intressanta kan diagram som är både anpassade för den specifika situationen och innehåller korrekt information skapas.
Kunden för detta projekt var Mikael Nyström och Daniel Karlsson på uppdrag av forskn-ingsgruppen i hälsoinformatik på Linköpings universitet. Deras ambition är att underlätta arbetet för läkare och annan vårdpersonal när SNOMED CT introduceras. Både korrekt och detaljerad överföring av information är viktigt inom vården. Genom att utveckla ett verktyg
där man kan bygga upp visualiseringar av datan så anser kunden att detta kommer ge bra stöd till personer som behöver kommunicera sådan information.
Tidigare erfarenheter
Under tidigare projekt så har för mycket tid ägnats åt att diskutera saker på möten istället för att faktiskt utföra saker. För att åtgärda detta så hade vi ett arbetsflöde som var uppdelat på ett sådant sätt att gruppmedlemmarna arbetade med separata uppgifter i par eller enskilt. Beroende på vad uppgifterna var så träffades medlemmarna en eller två gånger i veckan för att sammanställa delarna som arbetats på.
3
Teori
I detta kapitel behandlas grundläggande teori för examensarbetet.
3.1
SNOMED CT:s datastruktur
SNOMED CT är en databas bestående av en samling medicinska termer som täcker alla om-råden av klinisk information. Exempel på omom-råden som täcks är sjukdomar, läkemedel och undersökningsfynd. SNOMED CT är ett så kallat kompositionellt begreppssystem. Det in-nebär att begrepp definieras av dess relationer till andra begrepp, vilket gör det enkelt att lägga till nya specialiserade begrepp till databasen utifrån de redan existerande begreppen.
Figur 3.1: Exempel på begrepp i SNOMED CT
Ett exempel på ett begrepp i SNOMED CT är “blödande hud” (se figur 3.1). Det definieras av att det är en blödning och ett fynd som rör huden, och har attributen associerad morfologi blödning och fyndplats huden.
3.2. Utvecklingsverktyg
Begreppen är ordnade i en trädstruktur där de kan ha en eller flera föräldrar. I exemplet ovan är “blödande hud” barn till både “blödning” och “fynd som rör huden”. De primära komponenterna i databasen är följande:
KonceptID Konceptets unika identifieringsnummer. Beskrivning Beskrivande text av konceptet.
Relationer Relationer till andra koncept.
3.2
Utvecklingsverktyg
Här beskrivs de olika verktygen och ramverken som användes för att skapa webbtjänsten.
React
React är ett JavaScript-bibliotek med öppen källkod som främst utvecklas av Facebook. React används för att bygga webbgränssnitt och skapades för att lösa ett problem: hur man bygger stora applikationer med data som ändras över tid [6].
JSX
JSX är en syntaxutvidgning av JavaScript. JSX körs inte själv utan kompileras till ren JavaScript som sedan körs av webbläsaren. När det kompileras utförs en hel del optimeringar vilket leder till att JSX är betydligt snabbare än vanlig JavaScript[7]. Det största användning-sområdet för JSX är i samverkan med React.
Flask
Flask är ett Python-ramverk utvecklat för webbapplikationer. Det är ett mikroramverk, vilket betyder att man själv kan välja vilka verktyg och bibliotek man vill använda i kombination. Flask använder sig av Jinja2 som template-motor [8].
Node.js
Node.js är ett program som kör JavaScript-kod direkt i kommandoraden, och det används främst för att sätta upp webbservrar [9].
Npm
Npm är ett verktyg för att förenkla återanvändning av kod. Med hjälp av Npm kan du enkelt ladda ner olika JavaScript-paket andra utvecklare har skapat.
PostgreSQL
PostgreSQL är en gratis open-source relationsdatabashanterare som i hög grad följer SQL-standarden [10].
D3
D3 är ett JavaScript-bibliotek för att manipulera dokument baserat på data. Det har flera funktioner för att generera färdiga diagramstrukturer, bland annat en trädstruktur som an-vändes för det här projektet. Det gör det även möjligt att skapa interaktiva diagram genom att till exempel lägga till funktioner som flyttar noder i en trädstruktur beroende på var mus-pekaren befinner sig på skärmen.
3.3. Projektdrivningsverktyg
jQuery
jQuery är ett JavaScript-bibliotek med metoder för AJAX-funktionalitet (Asynchronous JavaScript and XML) som gör att en webbläsare kan kommunicera med en server utan att behöva ladda om webbsidan [11].
Webpack
Webpack används för att slå samman flera moduler till en modul för användning i en web-bläsare. Utan ett verktyg som Webpack hade det inte varit möjligt att dela upp koden i sepa-rata filer.
Elasticsearch
Elasticsearch är en open-source Javabaserad sökmotor som är väldigt populär tack vara hur snabbt den kan söka igenom stora mängder data.
3.3
Projektdrivningsverktyg
Här beskrivs de verktyg som användes för att kommunicera och planera i teamet.
Slack
Slack är främst ett kommunikationsverktyg för team och projektgrupper och finns både som webbtjänst och app till mobil. Huvudfunktionen är att man kan skapa en grupp, bjuda in medlemmar till gruppen och sedan kommunicera via de kommunikationskanaler man kan skapa. Det finns möjlighet att skapa öppna kanaler för hela teamet eller privata kanaler för utvalda individer. Dessutom kan man kommunicera med enskilda medlemmar via direk-tmeddelanden. Andra funktionaliteter är att man kan ladda upp filer och dela dessa, och man kan installera appar från Slacks App Directory som hjälper integrera andra verktyg i Slack, till exempel kan man få notiser i chatten om ändringar i ett Git repository.
Trello
Trello är ett verktyg som hjälper såväl privatpersoner som projektgrupper att organisera, planera och visualisera aktiviteters livscykler. I Trello skapar man så kallade tavlor (eng. boards) och i en sådan kan man lägga till listor som man i sin tur kan fylla med kort som kan representera aktiviteter.
Git
Git är ett program för att versionshantera dokument som till exempel källkod.
SEMAT
SEMAT (Software Engineering Method And Theory) är ett initiativ till för att skapa en gemensam grund för mjukvaruutvecklare samt en länk mellan industri och akademia. En praxis som tillhör SEMAT:s ramverk är att använda sig av så kallade ALPHA-tillståndskort (Abstract-Level Progress Health Attribute) som är ett sätt att hålla koll på statusen hos ett mjukvaruprojekt och för att fungera som ett hjälpmedel till att planera kommande steg i pro-jektet [12]. Olika ALPHA:s representerar viktiga delområden i ett mjukvaruprojekt och varje ALPHA kan befinna sig i olika tillstånd som representeras av de olika tillståndskorten.
4
Metod
I detta kapitel beskrivs de metoder som användes i projektet för att uppnå kundens krav.
4.1
Utvecklingsmetod
Under projektet arbetade vi iterativt. Projektet bestod av fyra iterationer, varav den första var en förstudie. I den mån som strukturen på projektet tillät så arbetade vi även agilt.
Den agila utvecklingen som vi använde oss av inspirerades av Scrum, Extreme Programming (XP) samt Kanban. Det vi hämtade ifrån Scrum var sprints (våra iterationer) och weekly scrums. Våra sprints inleddes med en planeringssession där vi bestämde vad som skulle göras under iterationen. Efter varje sprint hade vi ett möte med kunden där vi gick igenom vad som hade gjorts och fick feedback.
Genom vårt användande av Trello fick vi in Kanban i vår utvecklingsmetodik. Vi hade där listor som hette: “TODO”, “In Progress” samt “Done”. Saker som behövde göras men vi inte hade påbörjat än låg i listan “TODO”. När vi hade påbörjat något flyttades den till “In Progress”, och efter att en uppgift var klar flyttades den till “Done”. Det fanns inget tak på hur många uppgifter som fick vara i “In Progress” vid varje given tidpunkt, men vi försökte begränsa det till 6-7 stycken.
Vi använde en sådan tavla per iteration för att enkelt hålla isär aktiviteterna. De övriga sakerna som behövde göras fanns i en backlog. När vi satt och utvecklade använde vi vissa aspekter av XP. Detta var framförallt Pair programming. Majoriteten av all utveckling skedde i par, speciellt utvecklingen av de delar som var kritiska för systemet.
Under förstudien utbildade vi oss och samlade in den information som vi ansåg nöd-vändig för att vi skulle klara av projektet. Informationen som vi samlade in berörde de olika tekniska aspekterna av projektet. Detta var de ramverk som vi skulle använda, t.ex. React och Flask, men även strukturen av SNOMED CT:s data som vi skulle arbeta med. Vi spenderade även mycket tid med att skriva dokumentation. Dokumentationen som skrevs var en projek-tplan, kvalitetsplan och kravspecifikation.
Under de följande tre iterationerna fokuserade vi på utveckling och vidareutveckling av dokumentationen. Under den första låg fokus främst på att få upp den grundfunktionalitet som behövdes som de senare iterationerna skulle bygga vidare på. Iterationen efter det byg-gde vi vidare på applikationen genom att lägga till ytterligare funktionalitet. Den sista
4.2. Metod för att fånga erfarenheter
tionen fokuserade främst på att förbättra de funktioner vi redan hade skapat och göra de mer stabila, detta för att hålla en bra kvalitet på produkten.
Efter varje iteration använde vi oss av SEMAT ALPHA-kort [12] för att underlätta utvärderingen av projektets status, samt se vilka områden vi behövde arbeta med.
För att säkerställa produktens kvalité så bedrevs kvalitetsarbete under eller mellan itera-tionerna. Detta arbete hade som syfte att:
• Hitta buggar i kod.
• Se till att kod var läsbar och underhållsbar. • Se till att vi följde kravspecifikationen.
• Se till att vi byggde ett system som kunden ville ha.
Sättet att uppnå syftena bestod dels i att utföra en form av inspektion [13] där några av pro-jektmedlemmarna valdes ut varje iteration för att sedan utföra en ganska omfattande inspek-tion av all kod i develop-grenen i vårt Git repository. Inspektörerna antecknade sedan funna anomalier och skickade dem till kvalitetssamordnaren som sedan delegerade ut arbetet för att åtgärda defekterna. För att uppnå de två sista delmålen i syfteslistan så skulle en punkt på sista mötet i varje iteration handla om hur bra eller dåligt vi följde kravspecifikationen och att kunden i slutet av varje iteration skulle få testa på produkten och ge sina synpunkter.
4.2
Metod för att fånga erfarenheter
Under ett projekt är det alltid viktigt att ta vara på de erfarenheter man upplever, och se till att sprida informationen vidare till gruppens medlemmar. Att ta vara på de lärdomar som finns är till fördel både under och efter projektet.
För att bevara och sprida information inom gruppen så använde vi några olika metoder. Vår dagliga kommunikation sköttes genom Slack. Till skillnad från mail så bjuder Slack in till korta snabba diskussioner. Detta passar sig väl för att dela med sig av småproblem och eventuella snedsteg som man har gjort, vilket gör att de andra gruppmedlemmarna kan und-vika dem. Samma princip gäller när det kommer till att sprida kunskap om hur man har lyckats göra saker.
Genom att efter varje iteration utvärdera vad vi hade gjort och dokumentera detta kunde vi föra vidare de erfarenheter vi lärde oss. Dokumentation hade stort fokus i projektet, vilket underlättade tillvaratagandet av erfarenheter.
4.3
Testmetoder för att motverka felaktigheter i slutprodukten
Ett projekt kan brytas ned till flera mindre beståndsdelar. Alla dessa beståndsdelar motsvarar tillsammans den slutprodukt som åstadkommits vid projektets slut. För att slutprodukten ska uppnå det förväntade resultatet så är det viktigt att projektets beståndsdelar motsvarar de förväntningar som ställts på dem. För att verifiera att dessa förväntningar uppfylldes så använde vi olika typer av tester. Baserat på detta tillvägagångssätt med kontinuerliga tester var syftet att så tidigt som möjligt hitta eventuella felaktigheter i de olika beståndsdelarna, både i sin helhet men även ur ett enhetsperspektiv.
Vilken testtyp som användes var situationsstyrd, olika situationer krävde olika typer av tester. Ett exempel på en av metoderna som användes för att testa en viss beståndsdel var black-box testing. Syftet med det är att testpersonen ska ha ett objektivt förhållningssätt till de användartester som utförs.
4.4. Arbetssätt i versionshantering
4.4
Arbetssätt i versionshantering
Under projektet användes versionshanteringsverktyget Git för att tillåta gruppen att på ett smidigt sätt arbeta på samma kodbas. Användandet av Git gav också möjligheten att följa arbetsflöden (eng. workflow) typiska för Git.
Det arbetsflöde vi använde oss av kallas “Gitflow Workflow” och karaktäriseras av att master-grenen enbart uppdateras vid nya utgåvor. Den gren som istället används som bas för den huvudsakliga delen av utvecklingen är develop-grenen. När det börjar bli dags för en ny utgåva av produkten skapas en ny gren från develop-grenen där inga nya funktioner skapas utan enbart är till för att se till att nästa utgåva är så stabil som möjligt. När det är dags att leverera nästa version av produkten finns då utan några större problem en så stabil version av koden som möjligt redo på master-grenen.
Genom att återupprepa användandet av grenar för utgåvor vid slutet av varje iteration såg vi till att ha senast möjliga stabila produkt redo att visa kunden och oss själva. Detta gav oss en bra möjlighet att få snabb återkoppling på det som vi arbetat med närmast i tiden vid nästa iterations början.
5
Resultat
I detta kapitel presenteras de resultat som projektgruppen kom fram till.
5.1
Systembeskrivning
En översikt av systemet kan ses i figur 5.1. Systemet består idag av två delar, en likation och en server med tillhörande databas. Servern, en Flask-server, levererar webbapp-likationen till klienten. Idag används en PostgreSQL-databas där alla SNOMED CT:s termer lagras. Servern används också för att lagra information relevant till användaren, exempelvis favoritdiagram och tokens vid inloggning. Elasticsearch används också för att förenkla sökn-ing bland termer.
Webbapplikationen är utvecklad i JSX med ramverket React och är en SPA. Detta leder till en bättre användarupplevelse då sidan bara behöver laddas en gång, vid uppstart. Efter det kan individuella delar av hemsidan uppdateras utan att en ny sida laddas ner.
Figur 5.1: Översikt av systemet
5.2. Värde för kunden
5.2
Värde för kunden
Kunden kan via webbapplikationen söka på ett begrepp inom SNOMED CT:s databas. Detta begrepp kan sedan visas i ett diagram där relationer till andra, närliggande begrepp också visas. Vet inte användaren exakt vilket begrepp denne är ute efter kan man hitta begrepp via navigationsmenyn. Med hjälp av navigationsmenyn kan man enkelt klicka sig fram till ett intressant begrepp och visa upp det i ett diagram. Dessutom finns funktionalitet för att spara diagram och termer till en profilsida som man kan nå genom att logga in efter man registrerat ett konto. Förhoppningsvis kommer hemsidan att hjälpa kunden i sin utredning om vad som kommer att behövas för att den svenska sjukvården ska kunna börja använda SNOMED CT på ett bra sätt. En skärmbild över webbapplikationenen visas i figur 5.2.
5.3
Gemensamma erfarenheter
Efter att ha utvärderat och diskuterat projektgruppens åsikter och tankar om de gemen-samma erfarenheter som uppnåtts under projektet så kom vi fram till en hel del saker som kunde förbättras. Bland annat så framkom det under iteration 1 att projektmedlemmar kände sig osäkra på de delar i projektet som de själva inte varit med och utvecklat. För att före-bygga att detta skulle hända igen så föreslogs det att delspecifika demonstrationer ska hål-las under de gemensamma veckomötena i framtiden. En annan erfarenhet var att olika ak-tiviteter var svåra att koordinera, exempelvis så kunde det krävas att en del var klar innan nästa kunde påbörjas. Personer som jobbade med delar som var utsatta för denna typ av ko-ordineringskonflikter kunde då istället använda tiden till att utforska eventuella utökningar och förändringar som skulle kunna göra att slutprodukten blir ännu bättre.
Gruppen kom också fram till att nya insikter kunde uppkomma under projektets, vilket i sin tur ledde till att mer fördelaktiga lösningar kunde tas fram. Dessa lösningar kanske man inte tänkt på tidigare vilket indikerar att den förutbestämda lösningen som man funderat fram i förstudien kanske inte var den bästa. Genom att föra den typen av diskussioner kan man som utvecklare vara mer flexibel.
En annan lärdom som kunde dras var att när man är ett flertal personer som separat kodar olika delar av systemet så är det viktigt att koden sammanfogas till ett system i god tid. Väntar man för länge så kan det ofta uppstå konflikter av olika grader. I värsta fall kan något delsystem behöva kodas om helt och hållet för att det inte passar in med dataflödet i resten av systemet.
Mer konkret så kom gruppen fram till ett läge under iteration 1 där all källkod på front-end behövde kopplas samman på ett bra sätt och det fanns lite olika alternativ till att åstadkomma detta men eftersom Webpack rekommenderades av React kretsar så gjordes beslutet att an-vända detta.
Genom att använda Slack så kunde gruppmedlemmarna sprida information på ett snabbt sätt och det upplevdes som ett väldigt responsivt sätt att kommunicera eftersom att alla i gruppen besvarade varandra relativt snabbt både i privata chattar och i grupp-kanalerna. Gruppmedlemmarna kunde enkelt följa relevanta diskussioner i gruppkanalerna och speciellt läsa om Git commits i en notiskanal.
Med Trello kommunicerade gruppen vad som behövde göras, vad som var under utveck-ling, vad som gjorts och av vem. Under förstudien och iteration 1 var gruppen ganska dålig som helhet med att uppdatera statusen på de aktiviteter som fanns på Trello men från och med iteration 2 fungerade det riktigt bra.
5.3. Gemensamma erfarenheter
Figur 5.2: Översikt över applikationen
5.4. Resultat för användningen av SEMAT Kernel ALPHA
5.4
Resultat för användningen av SEMAT Kernel ALPHA
Under projektets gång uppnådde vi majoriteten av de tillstånd som vi planerade. De som inte riktigt blev uppfyllda var de delar som beror på när någon del av systemet kan användas i produktion. Detta berodde på att vi inte hade någon server där vi kunde ha vår applikation. Användandet av SEMAT ALPHA gav oss information om vilka aspekter vi behövde jobba mer på i projektet. Detta kunde vara att vi behövde ha mer kontakt med alla intressenter i projektet, att vi behövde arbeta med att förbättra team-arbetet eller att mjukvarusystemet hade hamnat efter planen. När vi i slutet av varje iteration utvärderade hur vi låg till kunde vi lägga upp en plan för hur vi skulle hantera de problem vi identifierat genom SEMAT ALPHA.
Genom att hjälpa oss identifiera de områden vi hade lite problem med så kunde vi med hjälp av SEMAT ALPHA snabbare komma fram med en plan för att åtgärda dessa.
5.5
Utritning och exportering av diagram
Utritning av diagram gjordes på två olika sätt. Det första diagrammet vi arbetade med har en trädstruktur och visar en rotnod samt dess barn. Ett exempel på hur detta diagram kan se ut visas i figur 5.3. Det går att visa fler eller färre barn med hjälp av en kontextmeny som kommer upp när man högerklickar på en nod. Det går även att få fram barnen till ett av rotnodens barn genom att klicka på just den noden. På detta sätt kan man få fram ett väldigt stort träd med koncept. I detta diagram kan man förflytta noder för att ändra hur diagrammet ser ut till exempel för att underlätta exportering som bilder. Tanken med diagrammet är att kunna visualisera ett begrepps relationer gentemot andra begrepp i databasen.
Mot mitten av iteration 3 utvecklade vi ett diagram som liknar det man kan finna på IHTSDO:s egna hemsida. Detta diagram valde vi att kalla “Concept Definition Diagram” eller “Definitionsdiagram” och ett exempel av det visas i figur 5.4. I detta diagram får man mer inblick i vilka koncept som är länkade till ett specifikt begrepp som man har navigerat fram till genom sökning eller navigationsdelen till vänster på hemsidan. Dessa koncept är länkade med olika attribut, till exempel attributet "Is a" vilket innebär att konceptet är en förälder till begreppet. Andra attribut visas som en gul rektangel med rundade hörn som är kopplade till ett koncept. Attribut kan även grupperas ihop ifall de är besläktade på något sätt.
Exportering av diagram som bilder är en viktig del av hemsidan för kunden. Det främ-sta användningsområdet är möjligheten att spara ner ett diagram som en bildfil som sedan kan skrivas ut och visas upp i utbildningssyfte. De filformat som stöds är SVG och PNG. SVG är ett fördelaktigt format eftersom det är vektorbaserat, vilket innebär att allt som finns på bilden är uppritat med hjälp av vektorer. Bilden består med andra ord av geometriska objekt så som punkter, cirklar och rektanglar. Eftersom dessa kan förstoras eller förminskas godtyckligt så kan även bilden det. PNG är inte uppbyggt av samma teknologi, men det har fördelen att det är ett väldigt vanligt filformat med stort stöd i olika program. Andra filtyper inkluderades inte eftersom en av våra bildfiler enkelt kan konverteras med hjälp av andra hemsidor eller program till valfritt format.
5.6
Översikt över individuella bidrag
Denna sektion beskriver översiktligt vad de individuella delarna i rapporten handlar om.
A. Hantering av situationsbaserade tester av Billy Krig
Denna utredning redogör vilka testtyper och testmetoder som har använts under projektet. Syftet med att utföra tester är att kunna leverera en buggfri och användarvänlig produkt till kunden.
5.6. Översikt över individuella bidrag
Figur 5.3: Översikt av träddiagram i helskärmsläge
5.6. Översikt över individuella bidrag
Figur 5.4: Översikt av definitionsdiagram i helskärmsläge
5.6. Översikt över individuella bidrag
B. Vilka fördelar kan React ge i ett webbaserat projekt? av Carl Brage
Denna utredning syftar till att ge större förståelse för hur React används i en webbapplikation. Utredningen behandlar även vilka fördelar som finns med att använda React jämfört med mer traditionella webbutvecklingsmetodiker.
C. Diagram med D3 av Daniel Johansson
Denna utredning ger en bakgrund i datavisualisering samt hur gruppen arbetade med att ta fram diagram som visualiserar medicinska begrepp ur SNOMED CT:s databas.
D. Versionshantering med arbetsflöden i projekt av Emil Nilsson
Denna utredning undersöker hur användning av olika versionshanteringssystem och arbets-flöden i versionshantering påverkar mjukvaruprojekt.
E. Kvalitet och kvalitetsarbetet i mjukvaruprojekt med fokus på inspektion av
Joacim Stålberg
Detta bidrag försöker reda ut vad det innebär att vara kvalitetsansvarig i ett projekt och vilken nytta inspektion av källkod kan ge.
F. Dokumentskrivning i mjukvaruutvecklingsprojekt av Mattias Ulmstedt
Denna utredning handlar om hur man på ett bra sätt kan hantera dokumentskrivning i mjuk-varuutvecklingsprojekt. Olika metoder och verktyg som kan användas diskuteras.
G. Arkitekturbeslut av Simon Hadenius
Denna utredning behandlar de olika arkitekturbesluten som togs i projektet. Den undersöker också hur man kan förenkla valet av arkitektur och bli en bättre arkitekt.
H. Kommunikations- och projekthanteringsverktyg i ett distribuerat arbetssätt av
Simon Lindblad
Utredningen utvärderar hur man kan effektivisera projektarbeten i grupp med hjälp av mod-erna verktyg och utvecklingsmetoder. Utvärderingen baseras på hur gruppen har reagerat på vårt arbetssätt.
6
Diskussion
I detta kapitel diskuteras de metoder vi använt, projektets resultat, alternativa lösningar och vilka konsekvenser som projektet resulterat i. Det tas även upp vad vi förbättrat från tidigare projekt, och vilka lärdomar vi dragit inför framtida projekt.
6.1
Resultat
Syftet med detta projekt var att utveckla en webbtjänst för att navigera och visualisera SNOMED CT:s datastruktur. Ingen av oss i projektgruppen hade särskilt stor tidigare er-farenhet av webbutveckling, så det var väldigt mycket nya tekniker och verktyg vi behövde lära oss, men trots det är vi överlag nöjda med den resulterade produkten. Kunden hade inte så många krav, utan gav oss ganska fria händer att designa hemsidan efter eget tycke. Vi uppnådde alla krav med prioritet 1 som i början av projektet ställdes på produkten. Vi im-plementerade dessutom många krav av prioritet 2 som är önskvärda att ha, så som att kunna skapa en användare för att spara favorittermer och diagram.
Alternativa implementationssätt
Eftersom ingen i projektgruppen hade arbetat med webbutveckling tidigare var det i början svårt att veta vilka delar av projektet som skulle ta lång tid. Det var även svårt att bestämma vilka verktyg som skulle användas för att sätta upp front-end och back-end. Under projek-tets gång ändrade vi av olika anledningar vilken typ av server som användes för att sätta upp API:t. I början av projektet använde vi oss av SNOMED CT:s egna API och under slutet använde vi oss av vårt egenutvecklade API. Det var bara en i projektgruppen som arbetade med API:t vilket ledde till att det tog ett tag innan det fungerade. Ett alternativt implemen-tationssätt hade varit att låta fler personer arbeta med API:t. Då hade vi inte behövt använda SNOMED CT:s API i början av projektet.
Den största delen av webbtjänsten handlar om diagram och dess konfigurationsmöj-ligheter. Det tog dock lång tid innan alla gruppmedlemmar satte sig in hur diagrammen fungerade. Detta ledde till att mycket diagramfunktionalitet implementerades i slutet av projektet. Hade fler personer jobbat med diagrammen från början hade vi nog kunnat bli klara tidigare och hunnit implementera fler funktioner.
6.1. Resultat
Vi hade också kunnat använda ett alternativt JavaScript-bibliotek istället för React. React var dock väldigt enkelt att komma igång med, även för en grupp där ingen har tidigare erfarenhet med webbutveckling. Alla i gruppen är nöjda med valet av JavaScript-bibliotek och tror inte det fanns något bättre alternativ för projektet.
De flesta problem som projektgruppen stötte på hade kunnat lösas genom att lägga mer tid på efterforskningar under förstudien. Hade vi vetat om att SNOMED CT:s API krävde en Node.js-server hade vi inte börjat med att sätta upp en Flask-server.
Förbättringar från tidigare projekt
Under tidigare projekt lades för mycket tid på möten och diskussioner istället för utveckling av produkten. Möten och diskussioner är självklart en viktig del i ett projekt av den här omfattningen, men det kan ofta sluka upp för mycket tid. Genom vår användning av Slack för kommunikation inom gruppen sparade vi in väldigt mycket på onödig mötestid. Om det uppkom några oklarheter kunde man snabbt få svar genom att skriva i relevant chattrum eller i privata meddelanden till berörda personer.
Som resultat av bra användning av versionshanteringsverktyget Git med små, atomära commits med bra meddelanden gick det distribuerade arbetssättet bättre än tidigare. Genom användandet av arbetsflödet “Gitflow Workflow” (se sektion 4.4) var det väldigt smidigt att utveckla olika delar av systemet parallellt utan att förstöra för varandra, samtidigt som vi alltid hade en stabil version av produkten att visa upp.
Tack vare användandet av Slacks integration med Git, vilket gjorde att det varje gång någon utförde en ändring i kodbasen kom upp ett meddelande med länk till information om ändringen i vår Slackkanal “Notiser”, var det dessutom väldigt enkelt att hålla koll över vilka delar som var under utveckling och vad alla delsystems status var.
Trello var ett nytt inslag för de flesta i projektgruppen och gav en enkel ingång till an-vändning av Kanban för drivandet av projektet.
En annan förbättring från tidigare är att graden effektivitet var mycket högre än i tidigare projekt vilket delvis nog beror på fler erfarenheter av arbete i projekt men också på de nya verktygen som användes, ett mer agilt förhållningssätt och en mer tydlig rollfördelning.
Lärdomar inför framtiden
En viktig lärdom för framtiden är att det är viktigt att arbeta fram en bra och genomtänkt design från början och tidigt göra beslut om vilka verktyg och ramverk som ska användas. Håller man designbeslut öppna för länge så kan det enkelt leda till att man stänger in sig i ett hörn och upptäcker att man helt måste tänka om vissa delsystem, antingen för att det inte passar ihop med dataflödet i resten av systemet, eller för att verktyget helt enkelt inte fungerar som tänkt.
Detta kan vara svårt när man gör något för första gången, och då är det extra viktigt att ta sig tid att sätta sig in i vad man ska göra, och inte bara hoppa in och börja koda och hoppas på det bästa. Till exempel så var det ingen i gruppen som hade tidigare erfarenhet av att koda i React. React gör att man kan få ett väldigt snyggt dataflöde, men det gäller att man från början tänker efter och kommer fram till vilka komponenter som kommer behöva kommunicera med varandra, och på vilket sätt.
I webbutveckling finns det två huvudområden; front-end och back-end. De flesta i grup-pen satt med front-end medan endast en person satt med back-end vilket från front-end spektivet ledde till många beroenden på back-end vilket kunde ta tid. Från back-end per-spektivet så uppkom mot slutet av projektet väldigt många efterfrågningar för utökningar som måste göras i back-end. Denna överbelastning mot slutet av projektet kunde ha motar-betats med bättre planering. Alternativt skulle fler än en person ansvarat för back-end.
6.2. Metod
Användning av SEMAT Kernel ALPHA
Vårt användande av SEMAT ALPHA gav oss en process för att identifiera de delarna i pro-jektet som hade hamnat efter planeringen. Verktyget gjorde det smidigt att analysera dessa aspekter, men vi hade förmodligen kunnat identifierat dem ändå. SEMAT ALPHA är väldigt övergripande, generellt och snabbt att komma igång med. Detta gör det till ett passande verktyg för den här typen av analyser, men mycket av den data man får ut av processen hade man nog märkt av ändå.
6.2
Metod
Vår agila arbetsmetod med projektet uppdelat i fyra distinkta iterationer ledde till att vi fick bra uppföljning från kunden om vad han tyckte om våra framsteg och vad vi skulle fokusera på inför kommande iteration. Eftersom att kunden hade ganska lösa krav på hur hemsidan i slutändan skulle se ut så passade vår arbetsmetod perfekt. Andra mindre agila metoder som till exempel vattenfallsmodellen hade varit svåra att använda utan att från början ha en klar bild över vad som skulle skapas, och det hade varit extra svårt att ta fram en bra och tydlig design med tanke på att ingen av oss hade särskilt mycket erfarenhet av webbutveckling, och specifikt React, sedan tidigare. Dessutom så är det svårt att veta exakt på förhand allt som ska ingå i någonting man aldrig gjort förut utan det framkommer mer naturligt ju mer insikt man får för problemet som ska lösas vilket är ännu ett argument för att agil utveckling passade bra för just detta projekt.
6.3
Källkritik
För gruppdelen av denna rapport gjordes ansträngningar för att inte ta med Wikipedia som källa eftersom sådana källors trovärdighet varierar väldigt mycket. Dessutom tas många källor direkt från primärkällan vilket gör att de källorna vi använder oss av har en viss tro-värdighet så länge det inte handlar om att sälja en produkt av något slag vilket såklart inte vore relevant för detta dokument.
6.4
Arbetet i ett vidare sammanhang
Här diskuteras arbetet från andra perspektiv än det tekniska.
Samhälleliga och etiska aspekter
Vi har svårt att se att produkten skulle kunna användas till något negativt. Exakt hur produk-ten kommer att användas vet vi inte, men dess huvudsyfte är som underlag i en utredning om vad som behövs för att SNOMED CT ska kunna börja användas inom sjukvården i Sverige. Förhoppningsvis leder produkten i slutändan till en förbättrad sjukvård, vilket gynnar hela samhället.
Miljöaspekter
Detta projekt har haft minimal inverkan på miljön. Det enda som användes vid utvecklingen av produkten var datorer. Dessa datorer kräver så klart elektricitet för att fungera, vilket är negativt för miljön, men det var i så låg grad att det knappt är nämnvärt.
7
Slutsatser
Syftet med denna rapport var att beskriva både den webbapplikation som vi har utvecklat och vår agila arbetsmetod. Det var också att diskutera gruppens samlade erfarenheter och lärdomar som vi drog från projektet. Detta har vi gjort, och vi ska här nedan återkoppla till de frågeställningar som togs upp i sektion 1.3.
Kunden ville ha en webbapplikation där man kan navigera och visualisera SNOMED CT:s data. Vi implementerade hemsidan som en SPA för att få den så responsiv som möjligt. Man kan navigera sig fram till begrepp både genom fritextsökning eller genom att navigera genom trädstrukturen i navigationssystemet. För att underlätta arbetet för användaren finns även funktionalitet för att skapa ett konto där man sedan kan spara termer och diagram för att snabbt kunna hitta tillbaks till dem i framtiden via sin profilsida.
Användningen av SEMAT Kernel ALPHA:s kan hjälpa till med att i ett tidigt stadium identifiera potentiella områden där man ligger efter så att man snabbt kan planera åtgärder.
För att rita ut och exportera diagram så framkom det att ett bra alternativ är att arbeta med vektorbaserade teknologier eftersom det ger stor frihet vid t.ex skalning.
Slack var till väldigt stor hjälp för att underlätta kommunikationen inom gruppen. Till skillnad från mail så bjuder Slack in till korta, snabba diskussioner vilket gjorde att man aldrig behövde vänta för att få svar på eventuella frågor. Tack vare Slacks integration med tjänster som Google Calendar och Git så underlättades all organisering av projektet, och alla hölls hela tiden enkelt uppdaterade om vad som hände i projektet. Behövde man få tag på någon så var det alltid enkelt att göra det via privata direktmeddelanden.
Likaså var Trello till stor hjälp för att organisera vem som skulle göra vad och vad som var kvar att göra. Utan Trello hade det varit betydligt besvärligare att ta sig an nya uppgifter eftersom det skulle vara väldigt svårt att veta vad som redan var gjort och vad de andra i gruppen redan höll på med.
Viktiga lärdomar
De viktigaste lärdomarna vi tar med oss från projektet är:
• Vi har lärt oss hur man kan utveckla en interaktiv hemsida med hjälp av verktyg som JavaScript, HTML, CSS, React, Flask, Webpack och PostgreSQL m.fl.
• Det är viktigt att från början tänka igenom vilka verktyg som kommer att behövas när man ska utveckla en produkt.
• Git är ett väldigt bra verktyg för att kunna arbeta parallellt i samma kodbas och det är viktigt med bra, atomära commits med beskrivande meddelanden.
• Slack är ett perfekt kommunikationsverktyg inom projektgrupper och är att föredra framför mail.
• Trello är ett väldigt bra verktyg för att organisera projekt med agila arbetsmetoder.
A
Hantering av situationsbaserade
tester av Billy Krig
A.1
Inledning
Tester är någonting som dagligen tillämpas inom flera olika områden, främst för att säker-ställa den förväntade funktionaliteten av det testade objektet. Men testerna kan också an-vändas som en inspirationskälla. Exempelvis så kan man specialstudera hur en viss funktion hanterar specifika situationer, samtidigt som detta görs så kan en idé uppkomma om hur funktionen kan bli ännu mer effektiv samtidigt som den fungerar som den är tänkt.
Vår projektgrupp har utvecklat en webbapplikation som är inriktad på att visualisera diagram över önskade sjukdomsrelationer. Detta kräver tester som är områdesbaserade. Ex-empelvis så måste den tekniska aspekten testas samtidigt som användarupplevelsen måste testas av en/flera objektiva testpersoner.
Kontinuerliga tester av den produkt som utvecklats bidrar alltså inte bara till att säker-ställa systemets funktionalitet utan också till att reflektera över hur delar av koden kan skri-vas ännu bättre och bli ännu mer effektiv. Genom att kontinuerligt testa den programkod som skrivs så motverkar det risken till att större felaktigheter uppenbarar sig i ett senare skede i projektet, kanske till och med i ett skede då ursprungsfelet är för sent att åtgärda.
Att hantera testningen på ett felaktigt sätt kan naturligtvis utgöra en stor riskfaktor. För att motverka att denna risk inte ska uppkomma så har en framtida riskanalys gjorts för kritiska funktioner.
Syfte
Syftet med denna individuella utredning är att påvisa hur de situationsbaserade testerna bidrog till den kontinuerliga produktutvecklingen. Redogörelsen för hur testmetodiken påverkade slutprodukten är ett av fokusområdena. Det andra fokusområdet som ska be-handlas innefattar de eventuella felaktigheter som skulle kunna ha uppkommit om testerna hanterats på ett annorlunda sätt.
Frågeställning
1. Vilken inverkan har testning på ett mjukvaruprojekt av denna omfattning?
A.2. Bakgrund
2. Vilka fördelar respektive nackdelar finns det i att ha ett subjektivt förhållningssätt till den kod som ska testas?
3. Hur ska en objektiv bild av användarupplevelsen införskaffas?
A.2
Bakgrund
Testning är något som jag personligen har jobbat med enda sen jag började programmera. Jag har hela tiden kontinuerligt testat den kod jag skrivit. Dock har dessa tester inte behövt vara lika strukturerade och omfattande som testerna i detta projekt behöver vara. Jag har heller inte tidigare gjort någon djupgående reflektion eller analys över vad testresultatet kan innebära för produkten i framtiden.
Tester av den här omfattningen är alltså relativt nytt för mig, vilket också innebär att jag fick tänka på ett lite annat sätt än vad jag är van vid. Det primära fokuset blev att att hitta testmetoder som täckte alla olika testaspekter.
A.3
Teori
Den grundläggande tanken med den testkonstruktionen som tillämpats under detta projekt var att testerna skulle vara så heltäckande som möjligt. Dessa heltäckande tester hade till uppgift att förebygga att missnöje och buggar skulle uppstå, under utvecklingen av projektet och efter slutförandet av projektet.
Under
Eftersom det är en projektgrupp bestående av många olika utvecklare som arbetar på många olika fronter så kan situationer uppkomma då vissa individer är beroende av andra indi-viders kod. Som utvecklare är man beroende av att koden som någon annan producerat är buggfri. Därför blir den kontinuerliga testningen väldigt viktig i detta avseende.
Efter
Kunden vill såklart att vi som grupp levererar en buggfri och användarvänlig slutprodukt. Därför är det inte bara viktigt att fokusera på den tekniska testningen i projektet utan också användarvänligheten är en väsentlig del för kunden. Slutprodukten ska vara enkel och smidig att använda och framförallt så ska kundens önskemål angående användning vara uppfyllda.
För att kunna uppfylla ovanstående kriterier så användes inte enbart en testtyp. Istället så bestod testningen av en kombination av flera olika testtyper, syftet med denna kombina-tion var att kunna uppnå ett önskat testresultat. Testtyperna som kombinerades var följande:
Användarvänlighet
Resultatet av att internt utföra ett användarvänlighetstest blir ganska så subjektivt och inte speciellt tillförlitligt. Det är lätt att man som utvecklare och projektmedlem får tunnelseende och fastnar vid den lösning som gruppen själva framställt.
För att undvika ovanstående situation så konstruerade jag i egenskap av testledare an-vändartester som behandlar de mest centrala användardelarna i den framställda produk-ten. Testpersonerna som skulle utföra dessa tester bestod av civilingenjörssrudenter som inte ingick i vår projektgrupp. Eftersom testpersonerna inte hade någon som helst insyn i koden som skrivits utan bara fick se resultatet av den så definieras dessa tester som black-box-tester[14]. Sammanfattningsvis så var testpersonernas primära uppgift att bedöma om 24
A.3. Teori
den grafiska lösningen tillfredsställer användaren på ett lämpligt sätt. Om någon testperson ser förbättringspotential inom ett visst område i vår produkt så ska den personen presentera det vid testningen. Detta medför att projektgruppen har möjligheten att diskutera om den föreslagna ändringen ska implementeras eller om den befintliga lösningen är mer relevant.
Testpersonerna består av civilingenjörsstudenter som inte ingår i vår projektgrupp och som endast har information om vad våran produkts syfte är. När personerna testas så får de instruktioner om att utföra specifika uppgifter. Baserat på testpersonernas egna användarup-plevelser så får de med hjälp av en bedömningsskala ett till fem betygsätta en viss del i vår produkt. Att ge den aktuella delen en etta innebär att den är jättesvår att använda medan en femma visar att den aktuella delen är jätteenkel att använda. Med föregående testresultat som grund så kan jag som testledare få en översiktlig bild om hur användarvänliga de olika delarna i vår produkt är för tillfället.
Enhetstestning
Enhetstestningens används till att testa mindre delar av den skrivna källkoden. Det som testas då är enskilda funktioner. Genom att hela tiden testa funktionerna så motverkar det att risker och problem med dessa funktioner ska uppenbara sig längre fram i projektet.
Jag som testledare beslutade att enhetstesterna ska utföras enligt den metod som kallas white-box-metoden[14]. Det innebär att kodutvecklarna själva testar den kod och de funk-tioner de skrivit. Detta beslut togs baserat på spetskompetens jag ansåg att man besitter som kodutvecklare inom det specifika ämnet. Detta innebär att någon utomstående inte behöver sätta sig in i koden, det skulle innebära att testerna skulle ta betydligt längre tid och kräva mer resurser.
Integrationstestning
Integrationstestningen tillämpas när olika områden av produkten ska sättas ihop till en enhet. Visionen var att fungerande områden skulle integreras med huvuddelen av produkten så kontinuerligt som möjligt.
Acceptanstest
Syftet med acceptanstesterna var att kunden under kundmötena kunde bekräfta att den pro-dukt som vi presenterade fungerade så som den var tänkt att fungera. Om delar av funk-tionaliteten inte var klar så förklarade vi vid kundmötena hur vi hade tänkt oss att utveckla produkten under nästkommande iteration. Projektarbetsprocessen bestod av tre stycken it-erationer, så ett acceptanstest förekom alltså att tre gånger, i slutet av varje iteration. Detta innebär att acceptanstesterna inte var lika frekvent förekommande som exempelvis enhet-stesterna.
Bugghantering
Om någon testform resulterar i att en bugg identifieras så är det viktigt att personen som hittat buggen vet vad han ska göra med den informationen. Jag som testledare testade lite olika teorier för hur bugghanteringen skulle ske. Teorierna var följande:
1. Jag ansåg att det skulle vara smidigt med ett dokument där buggarna skrevs in. Projek-tmedlemmarna skulle då kontinuerligt kolla i detta dokument för att se vilka buggar som uppkommit och vilka man själv hade möjlighet att åtgärda.
2. En projektmedlem föreslog att vi istället skulle använda oss av en buggtavla i Trello[15]. Detta medförde att man även kunde meddela den personen som hade skrivit den kod där buggen hittats direkt. På grund av detta så var det mycket enklare att se när nya buggar hittats och vilka man själv skulle åtgärda.
A.4. Metod
Jag beslutade mig för att gå över helt och använda den andra teorin efter att ha övervägt fördelar respektive nackdelar med de olika teorierna .
A.4
Metod
Jag har tidigare nämnt att det primära fokuset med testningen i detta projekt är att hitta test-metoder som täckte alla olika testaspekter. Totalt så har två stycken testtest-metoder tillämpats i de olika testtyperna, den ena testmetoden är white-box-testing[14] och den andra testmeto-den är black-box-testing[14]. I detta avsnitt kommer det klargöras vilka testmetoder som tillämpats i vilken testtyp under varje specifik iteration.
Iteration 1
Enhetstestningen utfördes kontinuerligt enligt white-box-metoden under den först iteratio-nen. Innan det var dags för kundpresentation så utförde jag som testledare ett integrationstest för att se om alla olika delar fungerade tillsammans på ett representabelt sätt. Till slut var det dags att få ett utlåtande från kunden som ett acceptanstest.
Iteration 2
Under iteration två blev testerna lite mer omfattande på grund av att produkten är mer utvecklad och genomarbetad. Självklart så fortsatte enhetstesterna att utföras enligt white-box-metoden eftersom kodutvecklarna besitter nödvändig spetskunskap för framställning av relevanta tester. Enhetstesterna utfördes inom dessa områden:
1. Sökning
2. Diagramhantering 3. Profilsida
4. Navigering
Under denna iteration så gjordes inte integrationstestet bara en gång utan det utfördes kontinuerligt. Även i slutet av denna iteration gjordes ett acceptanstest med kunden.
Iteration 3
Enhetstesterna, integrationstesterna och acceptanstestet hanterades under denna iteration precis på samma sätt som i iteration 2. Det som var nytt under denna iteration var att ett användarvänlighetstest utformades av testledaren och utfördes på civilingenjörsstudenter som inte ingick i vår projektgrupp. Detta var alltså ett så kallat användartest enligt black-box-metoden. Anledningen till att använda denna metod var att vi ville se hur vår produkt betraktades från ett objektivt perspektiv.
Sammanfattning av metodval
Sammanfattningsvis så kan man säga att metod- och testtypsvalen var baserade på det arbete som hade utförts i varje iteration. Det skulle exempelvis vara dumt att ha användarvänlighet-stester i iteration 1 då det knappt fanns någonting för användaren att testa.
A.5. Resultat
A.5
Resultat
Testresultat är något som är väldigt viktigt. Det är viktigt att utföra relevanta tester som generar användbara resultat. Det är också viktigt att analysera de testresultat som har framkommit av testerna. Det är också viktigt att våga göra radikala testfall för att se hur testobjektet uppför sig och inte bara testfall som man kan förutse programmet klara av med största sannolikhet.
Precis som i ovanstående avsnitt så kommer testresultaten och testanalyserna presenteras i förhållande till den iteration där dom utfördes.
Iteration 1
De enhetstester som utfördes i iteration 1 klarades av utan några problem. Dock så var det svårt att förutse hur de funktioner som testats skulle påverka den kod som skulle skrivas under iteration 2.
Integrationstestet som gjordes innan kundpresentationen bedömdes också som avklarat då jag som testledare ansåg att den första versionen av produkten var redo att visas för kun-den.
Kunden var nöjd med vårt första version av produkten, han tyckte även att dom idéerna vi hade inför framtiden var intressanta.
Iteration 2
Under iteration 2 så utfördes en mer omfattande enhetstestning, resultatet av testningen var att alla funktioner inte betedde sig så som vi förväntade oss att dom skulle bete sig. Detta togs givetvis med i riskanalysen som gjordes till varje enhetstest, framförallt de tester som inte klarades av. Med all testning inkluderad så uppkom det ungefär tio buggar. Bedömningen som gjordes var att dessa buggar som för tillfället fanns inte skulle påverka den framtida koden då dom var ganska så lätthanterliga och skulle åtgärdas i början av iteration 3.
Integrationstesterna var mycket enklare att hantera under denna iteration då dom gjordes mer frekvent, detta innebar att det var mindre ”stora fel” som kunde uppkomma när kodde-lar integrerades. Så integrationstesterna kkodde-larades av även under denna iteration.
Efter kundmötet var kunden nöjd med den produkt vi presenterat, han tyckte också att de idéer vi ville fortsätta jobba med under iteration 3 var relevanta. Detta får betraktas som ett godkänt acceptanstest.
Iteration 3
Enhetstestningen fortsatte i samma anda som under iteration 2. De tester som inte ansågs som avklarade åtgärdades relativt snabbt, detta medförde att buggproblem blev relativt sällsynta. De buggar som fanns kvar från iteration 2 åtgärdades under inledningen av iterationen 3.
Integrationstesterna hanterades på samma sätt som i iteration 2 vilket medförde att inte-greringsdelen klarades av utan några bestående problem.
Kunden var efter det avslutande mötet nöjd med den produkt som vi åstadkommit vilket innebar av även det tredje acceptanstestet klarades av.
Under iteration 3 så hanterades även användarvänlighetstester. Dessa tester gav oss en översiktlig bild över hur användaren upplevde vår produkt. Testerna resulterade senare i att vi implementerade några av de förslag som testpersonerna givit oss under testtillfället.
A.6. Diskussion
A.6
Diskussion
Testinverkan
Testning har varit en viktig del genom hela projektet. Enligt mig så är det viktigt med test-ning i alla avseenden, oberoende av projektstorlek. Dock så tror jag vikten av formella och välstrukturerade tester blir mer viktiga desto större projektet är. Eftersom kandidatarbetet är det största projekt som jag har deltagit i så har jag insett att testningen i ett projekt av denna omfattning blir essentiell för hur den slutgiltiga produkten kommer att framstå. Om olika typer av tester inte hade utförts så hade den slutgiltiga produkten kanske både varit fylld med buggar och inte varit användarvänlig.
Subjektivt förhållningssätt till den kod som testas
Att ha ett subjektivt förhållningssätt till den kod som man testar kan vara riskabelt. Tester som inte är särskilt objektiva kan utformas, eftersom man själv skrivit koden. Eventuellt kan testutformaren då tendera till att skriva tester som denne nästan är säker på klaras av, det är den stora nackdelen. Det finns dock även fördelar, den största fördelen med att testa sin egen kod är att man känner till lösningarna som gjorts och vet vilka områden som är kritiska. Om man vågar att skriva radikala och utmanande tester så kan man dra stor nytta av den spetskunskap man besitter inom det område som ska testas. En annan fördel är också tidsaspekten, någon utomstående person behöver då alltså inte sätta sig in i dom lösningar som skapats i den aktuella testkoden. Eftersom detta projekt är tidsbegränsat så är det något som är väldigt fördelaktigt.
Objektiv bild av användarupplevelse
När vi skrivit kod och testat denna kod så har det gjorts internt i projektgruppen. Detta in-nebär att vi tagit dom beslut angående användarvänlighet som vi tycker var mest lämpliga. På grund av detta så kan en subjektiv bild skapas om vad vi tror är det mest lämpliga. Att våga ifrågasätta dessa teorier genom att använda oss av utomstående personer till använd-barhetstestningen tror jag gynnade vår produkt, vi fick värdefulla inblickar i hur en utom-stående användare upplevde produkten.
A.7
Slutsatser
Testinverkan
Resultatet av all den testning som genomförts under detta projekt blev att vi slutligen fram-ställt en användarvänlig, uppskattad och buggfri produkt. Många av de testpersoner som fick testa vår produkt berömde den. Det var delvis ett sådant resultat vi eftersträvade vid projektstarten.
Subjektivt förhållningssätt till den kod som testas
Resultatet av den subjektiva testningen som vi tillämpade blev också positivt. Testerna blev väl genomförda och en riskanalys kunde göras angående framtida buggar.
Objektiv bild av användarupplevelse
Testmetoden som användes för att testa den objektiva användarupplevelsen gav många värdefulla resultat som vi inom gruppen kunde diskutera. Testpersonerna gjorde många bra iakttagelser som vi själva inte skulle märkt av på samma sätt. De förväntningar vi hade på resultatet från dessa tester infriades ordentlig.
B
Vilka fördelar kan React ge i ett
webbaserat projekt? av Carl
Brage
B.1
Inledning
React är ett JavaScript-bibliotek med öppen källkod som utvecklas främst av Facebook. Re-act används för att bygga webbgränssnitt och skapades för att lösa ett problem: hur man bygger stora applikationer med data som ändras över tid. [6] Skillnaden mot traditionell webbutveckling är att React bryter ner användargränssnitten till komponenter istället för att använda templates och HTML på det traditionella sättet. Detta gör att man får större frihet i hur man manipulerar hemsidan över tid när informationen inuti ändras.
Syfte
Denna utredning ska beskriva fördelarna i att arbeta med React jämfört med mer traditionella webbutvecklingsmetodiker. Genom att läsa denna utredning så kan man få större förståelse i hur React med fördel kan användas i webbaserade projekt med olika funktionella krav. Utredningen syftar även att beskriva hur React implementeras i en webbapplikation samt hur det används. Mer specifikt handlar utredningen om vilka fördelar React har vid utveckling av så kallade single-page applications, webbsidor eller webbapplikationer som är uppbyggda av en enskild sida.
Frågeställning
1. Vilka fördelar får man av att använda React istället för andra bibliotek eller ramverk? 2. Vilka begränsningar har React jämfört med andra JavaScript-bibliotek och ramverk? 3. Vad gör React särskilt lämpad för single-page applications?
B.2
Bakgrund
Projektet vi fick som uppdrag att genomföra var som tidigare nämnt en implementering av SNOMED CT:s datastruktur med visuella representationer. Genom att undersöka andra im-plementationer av SNOMED CT insåg vi att de flesta var så kallade single-page applications där man oftast har en navigationsvy, en sökvy samt en diagramvy. Dessa kunde interageras
