Linköpings universitet
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2018 | LIU-IDA/LITH-EX-G--18/017--SE
Schemaläggning genom
webbapplikationen
Placeholder
Scheduling with the Web Application Placeholder
Hampus Eriksson
Daniel Jonsson
Anton Landor
Emelie Lindman
Zacharias Nordström
Erik Tedhamre
David Åström
Handledare : Viktor Wällstedt 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 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 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 upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional 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 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/.
© Hampus Eriksson Daniel Jonsson Anton Landor Emelie Lindman Zacharias Nordström Erik Tedhamre David Åström
Sammanfattning
Den här rapporten behandlar arbetet utfört av sju studenter på Linköpings universitet som går programmen civilingenjör i datateknik och mjukvaruteknik. Rapporten är en del av kursen TDDD96 Kandidatprojekt i programutveckling under vårterminen 2018. Arbetet har omfattat utveckling av webbapplikationen Placeholder, på uppdrag av Niclas Hjorth vid Röntgenkliniken Linköping. Applikationen som utvecklades är ett verktyg skapat för att underlätta schemaläggningen av personalen på röntgenkliniken. Schemaläggarens jobb underlättades genom funktionalitet som att tydligt visa var personer är inbokade samt vilka personer som finns tillgängliga. Arbetssättet följde en anpassad och avskalad vari-ant av Scrum. Utvecklingsarbetet har utförts inkrementellt och iterativt med delleveranser av produkten i form av prototyper under projektets gång. Arbetssättet resulterade i att projektets arbete har kunnat anpassats efter ändringar i kundens önskemål om funktion. Projektet resulterade i en prototyp för kunden som kan användas för fortsatt utveckling. Under projektets gång upplevde gruppen erfarenheter som fångats upp, dessa erfarenhe-ter visade på att kommunikation i projekt är viktiga. Gruppen visade även att Trello är ett användbart verktyg för agil systemutveckling.
Tillkännagivanden
Gruppen vill tacka examinatorn Kristian Sandahl för en väl utformad och lärorik kurs och dessutom för hans höga ambition för att upprätthålla kursen och att hjälpa alla kursdeltagare nå ett högt resultat. Stort tack till vår handledare Viktor Wällstedt för ett gediget stöd och utförlig feedback under kursens gång. Vi vill även tacka vår kund Niclas Hjorth för ett mycket intressant projekt med många utmaningar och dessutom en utmärkt kommunikation med gruppen.
Innehåll
Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller ixI
Gemensam del
1
1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Frågeställningar . . . 3 1.4 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Projektbeskrivning . . . 4 2.2 Tidigare erfarenheter . . . 4 2.3 Kursen . . . 4 3 Teori 5 3.1 Scrum . . . 5 3.2 HTML . . . 6 3.3 CSS . . . 6 3.4 React.js . . . 6 3.5 Node.js . . . 73.5.1 Node Package Manager . . . 7
3.6 Material Design . . . 7 3.6.1 Material-UI . . . 7 3.6.2 Löften . . . 7 3.7 Axios . . . 8 3.8 React DnD . . . 8 3.9 React router . . . 8 3.10 Express.js . . . 8 3.11 Nodemon . . . 9 3.12 MariaDB . . . 9
3.13 Hashning och saltning . . . 9
3.14 Git . . . 9
3.15 Trello . . . 10
3.16 Slack . . . 10
3.17 Figma design . . . 11
4 Metod 12 4.1 Förstudie . . . 12
4.1.1 Krav och tidsplanering . . . 12
4.1.2 Dokumentation . . . 13 4.1.3 Prototyp . . . 13 4.2 Projektstruktur . . . 13 4.2.1 Möten . . . 13 4.2.2 Git . . . 13 4.2.3 Utveckling . . . 14 4.2.4 Kommunikation . . . 14 4.3 Systemanatomi . . . 15 4.4 Testning . . . 15 4.5 Trello . . . 15 5 Resultat 17 5.1 Förstudie . . . 17
5.1.1 Krav och tidsplanering . . . 17
5.1.2 Dokument . . . 17 5.1.3 Prototyp . . . 18 5.2 Projektstruktur . . . 19 5.2.1 Möten . . . 19 5.2.2 Git . . . 19 5.2.3 Kommunikation . . . 20 5.3 Systemanatomi . . . 20 5.4 Testning . . . 21 5.5 Trello . . . 21 5.6 Produktbeskrivning . . . 22 5.6.1 Systemskiss . . . 22 5.6.2 Klient . . . 22 5.6.3 Server . . . 24 5.6.4 Databas . . . 24 5.6.5 Värde för kund . . . 25 5.7 Node.js . . . 25 5.8 Gemensamma erfarenheter . . . 26 5.9 Individuella bidrag . . . 26
5.9.1 Hampus Eriksson: Jämförelse av nyckel utbytesalgoritmer i kommuni-kationsprotokollet TLS . . . 27
5.9.2 Daniel Jonsson: En övergripande jämförelse mellan webbutvecklings-ramverken Reactjs och Angular . . . 27
5.9.3 Anton Landor: Utmaningar med att tillämpa agil systemutveckling på olika organisationer . . . 27
5.9.4 Emelie Lindman: En översiktlig utvärdering av hur testning påverkar systemutveckling . . . 27
5.9.5 Zacharias Nordström: Systemarkitektens roll i utvecklandet av ett håll-bart program . . . 27 5.9.6 Erik Tedhamre: Undersökning av vilket driftsätt som skall användas
för Advanced Encryption Standard vid vidareutveckling av Placeholder 27 5.9.7 David Åström: En undersökning och jämförelse av RDBMS och NoSQL 27
6 Diskussion 28 6.1 Resultat . . . 28 6.1.1 Arbetssätt . . . 28 6.1.2 Systemanatomi . . . 28 6.1.3 Prototyp . . . 29 6.1.4 Klient . . . 29 6.1.5 Server . . . 30 6.1.6 Databas . . . 31 6.1.7 Gemensamma erfarenheter . . . 31 6.2 Metod . . . 32 6.2.1 Möten . . . 32 6.2.2 Utveckling . . . 32 6.2.3 Testning . . . 32 6.3 Trello . . . 33
6.4 Arbetet i ett vidare sammanhang . . . 33
6.4.1 Samhälleliga aspekter . . . 33 6.4.2 Miljöaspekter . . . 33 6.4.3 Tekniska aspekter . . . 34 6.4.4 Ekonomiska aspekter . . . 34 6.4.5 Etiska aspekter . . . 34 7 Slutsatser 35 7.1 Hur kan Placeholder implementeras så att man skapar värde för kunden? . . . 35
7.2 Vilka erfarenheter kan dokumenteras från programvaruprojektet Placeholder som kan vara intressanta för framtida projekt? . . . 35
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 36
7.4 Vilket stöd kan Trello ge för agil systemutveckling? . . . 36
7.5 Vilket stöd kan Node.js ge för utvecklingen av en realtidswebbapplikation? . . 36
7.6 Rapportens syfte . . . 37
II Individuell del
38
A Hampus Eriksson: Jämförelse av nyckelutbytesalgoritmer i
kommunikationspro-tokollet TLS 39
B Erik Tedhamre: Undersökning av vilket driftsätt som skall användas för Advan-ced Encryption Standard vid vidareutveckling av Placeholder 52 C Daniel Jonsson: En övergripande jämförelse mellan webbutvecklingsramverken
Reactjs och Angular 60
D Anton Landor: Kommunikativa utmaningar med att tillämpa agil
systemutveck-ling på olika organisationer 67
E Emelie Lindman: En översiktlig utvärdering av hur testning påverkar
systemut-veckling 73
F Zacharias Nordström: Systemarkitektens roll i utvecklandet av ett hållbart program 80 G David Åström: En undersökning och jämförelse av RDBMS och NoSQL 87
Litteratur 96
Figurer
5.1 En pappersprototyp av Placeholders dagsvy. . . 18
5.2 Första designskiss på dagsvyn av Placeholder . . . 19
5.3 Figuren visar systemantomin som gjordes på whiteboard-tavlan. En större bild kan ses i bilaga H.1 . . . 20
5.4 Figuren visar den digitala versionen av systemantomin. En större bild kan ses i bilaga H.2 . . . 21
5.5 Figuren visar en systemskiss över Placeholder . . . 22
5.6 Figuren visar hur Placeholders huvudsida ser ut. För en större bild se bilaga H.3 . 23 5.7 Diagrammet visar hur Placeholders databas har designats. För en större figur se bilaga H.4. . . 25
A.1 En översiktlig bild av en MITM-attack. . . 45
H.1 Den gamla versionen av systemanatomin till Placeholder . . . 103
H.2 Den reviderade versionen av systemanatomin till Placeholder . . . 104
H.3 Figuren visar hur Placeholders huvudsida ser ut. . . 105
Tabeller
4.1 Sammanställning över de chattkanaler som funnits i Slack med en beskrivning över vad som förekommit i respektive kanal. . . 15 4.2 Tabell över de listor, samt beskrivning för i vilken lista ett kort skulle placeras, för
respektive Trello-tavla . . . 16 5.1 Tabell över gruppens skrivna dokument . . . 18 B.1 Resultat presenterade i Sultan Almuhammadi och Ibraheem Al-Hejris
konfe-renspublikation A Comparative Analysis of AES Common Modes of Operation . . . 57 B.2 Resultat från det egna testet . . . 58
Ordlista
API Applikationsprogrammeringsgränssnitt (eng. application programming interface). Specifi-cerar hur ett externt program kan kommunicera med programmet.
Distribuerat Synonymt med fördelat.
DOM DOM eller Document Object Model är ett gränssnitt för att representera bland annat HTML-dokument som noder eller objekt vilka sedan kan manipuleras med olika pro-grammeringsspråk. Detta gör att hemsidan bland annat kan uppdateras när använda-ren interagerar med objekt.
EER-diagram eng. Enhanced Entity Diagram. Ett diagram som visar hur en databas ska vara uppbyggd.
Exekveringsmiljö En miljö som innehåller alla program, filer och rutiner som behövs för att köra ett program.
Google Drive En molnlagringstjänst utvecklad av Google. Google Drive har inbyggda edi-terare för dokument, bildspel, kalkylark m.m.
Insticksmoduler En mindre programvara som utökar funktionaliteten av ett program. JSON JSON, eng. Javascript object notation. Ett sätt att skicka datamängder över internetet
som en textsträng. Kan användas för att återskapa när det har kommit fram till motta-garen.
Kalkylark, digitalt Ett program som ger stöd för uträkningar av data. Ett exempel på ett kalkylarkprogram är Microsoft Excel.
Klient Klient är ett datorprogram som lägger över arbetsuppgifter på ett annat program, en server, istället för att utföra dem själv. Ofta det program som användaren direkt interagerar med.
Må-runda En mötespunkt där alla deltagare berättar hur de mår.
LaTeX Ett typsättningssystem. Används för att skapa pdf:er från dokumentmallar. Overleaf En online editor för typsättningssystemet LaTeX.
Planeringspoker En planeringsmetod där deltagarna röstar anonymt för tidsåtgången för en aktivitet. Därefter diskuteras resultatet och nya omröstningar görs tills alla deltagare är överens med uppskattningen.
Ramverk Stöd för utveckling av program. Innehåller regler och funktionalitet vid utveck-ling.
Server Server är ett datorprogram avsett för datalagring, tyngre beräkningar och dylikt som bäst sköts centralt på ett ställe.
SQL SQL är en förkortning för Structured Query Language och är en standard för program-språk som används för relationsdatabaser.
Öppen Källkod Öppen källkod är kod som lämnats ut till alla som vill ha den. Koden är tillgänglig tillsammans med det körbara programmet.
Del I
1
Inledning
Denna rapport behandlar utvecklingen av webbapplikationen Placeholder, vilket är ett sche-maläggningsverktyg framtaget för Röntgenkliniken Linköping. Applikationen är utvecklad för att underlätta schemaläggningen av personalen. Genom funktionalitet som att tydligt visa var personer är inbokade samt vilka personer som finns tillgängliga underlättas sche-maläggarens jobb.
Utvecklingen av Placeholder är gjord med hjälp av ramverket React, programsystemet No-de.js och databashanteraren MariaDB.
1.1
Motivering
I dagsläget planerar projektets kund Röntgenkliniken i Linköping sina dagar på ett ineffet-kivt sätt som skulle kunna förbättras drastiskt. Åtminstone en tjänst går just nu åt till att planera över 100 personers schema i ett kalkylark där risken för fel är stor och det saknas en intuitiv struktur. Personen som schemalägger personalen har dessutom ett stort ansvar då informationen om respektive persons kompetenser finns i minnet. Uppdraget har varit att ta fram ett kompetensbaserat schemaläggningsverktyg som skulle kunna användas istället för det digitala kalkylark som använts tidigare. Problemet som upplevdes med det tidigare till-vägagångssättet var att det gick åt mycket tid. Det resulterade schemat var inte särskilt bra heller utan kunde ofta innehålla slarvfel.
1.2
Syfte
Syftet med detta dokument är att ge en beskrivning av det projekt som blivit utfört och sam-la de erfarenheter som projektgruppen fått under projektets gång både för utveckling och interaktion med kund. Dessa erfarenheter ska sedan analyseras och slutsatser dras utifrån detta. Produkten syftar till att underlätta schemaläggningen av personal på Röntgenkliniken Linköping.
1.3. Frågeställningar
1.3
Frågeställningar
I rapporten besvaras följande frågor:
1. Hur kan Placeholder implementeras så att man skapar värde för kunden?
2. Vilka erfarenheter kan dokumenteras från programvaruprojektet Placeholder som kan vara intressanta för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Vilket stöd kan Trello ge för agil systemutveckling?
5. Vilket stöd kan Node.js ge för utvecklingen av en realtidswebbapplikation?
Resultat relevant till frågeställningarna presenteras under kapitel 5 Resultat, därefter analy-seras detta i kapitel 6 Diskussion och slutsatser dras under kapitel 7 Slutsatser för att besvara frågeställnignarna.
1.4
Avgränsningar
Projektet omfattas av 400 arbetstimmar per person, vilket innebär att projektgruppen har 2800 timmar till att arbeta med projektet. Detta innefattar inte bara utvecklingen av produkten som blivit beställd av kund, utan även skrivandet av en gemensam kandidatrapport och en individuell del från varje gruppmedlem. Utöver kandidatrapporten skrev gruppen ett antal projektdokument. På grund av sekretess måste nätverkstrafik begränsas till kundens lokala nätverk, vilket i vårt fall förhindrar möjligheten att använda applikationen på mobila enheter då kunden inte har mobila jobbenheter.
2
Bakgrund
Röntgenkliniken Linköping är en stor arbetsplats med cirka 200 anställda som behöver få sin verksamhet schemalagd. Detta skapar en mängd administrativt arbete som måste utföras av sjukhuspersonalen. Region Östergötland har tidigare gjort en undersökning[1] där de under-sökte hur mycket av vårdpersonalens tid som personalen själva uppskattade gick åt till olika typer av arbetsuppgifter. Undersökningen visade att över 40 procent av vårdpersonalens ar-betstid gick åt till administrativt arbete. Med anledning av det resultatet är det av intresse att minska tiden som går åt till administrativt arbete.
2.1
Projektbeskrivning
Röntgenkliniken Linköping schemalägger just nu sin verksamhet med hjälp av digitala kal-kylark i Microsoft Excel. Det tar mycket tid och skapar många onödiga problem som hade kunnat lösas med bättre lämpad programvara. De har granskat de alternativ som finns på marknaden men upplevt att de inte passar deras verksamhet. Därför vill de nu att ett sche-maläggningsverktyg tas fram som är anpassad till deras verksamhet.
2.2
Tidigare erfarenheter
Projektets medlemmar studerar alla till civilingenjör i datarelaterade inriktningar vid Lin-köpings universitet. Alla medlemmarna har under sina utbildningar utfört projektarbeten av varierande storlek. Detta gör att vi känner oss bekväma med projektarbete. Samtliga personer har även läst kursen TDDC93 - Programutvecklingsmetodik [2] som ger en teoretisk grund i principer för programvaruutveckling.
2.3
Kursen
Projektet utfördes som ett delmoment av kursen TDDD96 - Kandidatprojekt i programvaru-utveckling [3]. Kursen innehåller också diverse seminarium och föreläsningar som ska un-derlätta och skapa diskussion kring utvecklingen av projektet.
3
Teori
Här beskrivs den teoretiska bakgrunden till de verktyg och arbetssätt som använts under pro-jektet. Verktygen innefattar både de som kommit att användas för utvecklingen av produkten, både på server och klientsida. Även de verktyg som använts för till exempel kommunikation inom gruppen tas upp i detta avsnitt.
3.1
Scrum
Scrum är ett agilt arbetssätt som är vanligt vid mjukvaruutveckling. Det är framtaget för team om ungefär tre till nio personer. Arbete delas upp i så kallade sprinter på 30 dagar eller mindre där varje leverans vid slutet av sprinter bör leverera en användbar funktion som kund kan testa eller använda. Scrum består av dagliga möten på ungefär 15 minuter för att koordinera det aktuella laget. [4]
En grupp som följer Scrum behöver placera personer på minst tre roller; en produktägare, en scrummästare och ett utvecklingsteam. Produktägaren är lite av ansiktet utåt för produkten och teamet. Denna roll fokuserar mycket på att underhålla listan över vad som ska göras för produkten, även kallat product backlog och har ett bra kontakt med både kund och teamet som utvecklar produkten. Från denna position kan produktägaren ge vägledning för vad som bör utvecklas härnäst. Produktägaren är dedikerad till att utvecklingsteamet ska kunna levere-ra den produkt som har mest värde för kund och är en roll tilldelad till endast en person. Scrummästaren är såväl teamets som produktägarens coach för hela projektet. Rollen foku-serar på logistiken för hela gruppen och en duktig scrummästare kan optimera arbetsflödet för alla. Mästaren bokar in möten, ser till att resurser finns för samtliga uppgifter och jobbar konstant med att finjustera scrumarbetet för effektivare arbete. Utvecklingsteamet inkluderar flera olika sorters gruppmedlemmar som till exempel testare, designers och mjukvaruutveck-lare som vanligtvis inte är en större grupp än 7 personer. De jobbar tillsammans med att välja uppgifter inför varje sprint, ska helst arbeta tätt tillsammans och försöker hålla alla i teamet på samma kunskapsnivå för att slippa flaskhalsar. [5]
3.2. HTML
3.2
HTML
HTML, eng. Hyper-Text Markup Language, är ett språk som skapar den grundläggande struk-turen av alla hemsidor på internet. HTML består av något som kallas taggar. Dessa taggar placeras runt text för att vissa hur den texten ska formateras och visas på hemsidan. Dessa taggar kan även göra andra saker som att länka till en bild eller en annan hemsida. [6] HTML har fått genomgå ett antal versioner. Den senaste versionen är HTML 5 som utveckla-des av organisationen W3C. W3C var också de som släppte version 4 år 1998, som blev en av de första riktiga standarderna för språket. HTML 5 släpptes 2014 och skulle lösa problemet från HTML 4 med att behöva installera ett antal av insticksmoduler på varje hemsida för att få bra funktionalitet för video och ljud på hemsidor. [6]
3.3
CSS
För att kunna beskriva hur ett dokument skrivit i HTML ska visalusieras i detalj används det stilistiska språket CSS, eng. Cascading Style Sheets. CSS släpptes för första gången 1996 men först 2000 fanns det en webbläsare som hade fullt stöd för CSS. En av de största fördelarna med CSS är att språket tillåter separationen av presentationen och innehållet. Detta gör det enklare att ändra på presentationen eller innehållet var för sig utan att något går sönder. [7]
3.4
React.js
React.js är ett Javascript-bibliotek som är till för att bygga användargränssnitt på webbap-plikationer. Det utvecklades av Facebook och Instagram och är släppt som öppen källkod. Det underhålls av dess skapare samt enskilda utvecklare och företag. React används ofta för att skapa webbapplikationer vilka ryms på en sida, det vill säga webbläsaren behöver inte flytta mellan olika adresser under interaktion med webbsidan. Till skillnad från traditionell webbutveckling, där utvecklaren arbetar med HTML, CSS och Javascript som skilda delar, väver React samman alla dessa. Webbutveckling med React sker till största del istället genom deras egna kodstil JSX där HTML-markup blandas med Javascriptkod. Ett exempel på det går att se i kodexemplet 3.1 där HTML blandas med Javascriptkod för att tillsammans skriva ut Hello world! i webbläsaren . [8]
import React from 'react';
import ReactDOM from 'react-dom'; ReactDOM.render(
<h1>Hello, world!</h1>,
document.getElementById('root') );
Listing 3.1: Exempel på JSX-kod från en React-fil.
React bygger på en komponentbaserad utveckling där alla element på skärmen är del av någon typ av komponent. I vissa fall kan dessa komponenter vara färdiga att använda genom tredjepartsföretag eller från Reacts egna standardutbud av redan färdiggjorda komponenter. I många fall skapas dock dessa själv då det kan behövas delar med ytterligare funktionalitet än vad som erbjuds. Det som ytterligare är speciellt för utveckling med React är att det snabbar upp uppdateringen av hemsidans DOM. Vanligtvis uppdateras hela hemsidans DOM när en ändring sker och detta kan vara tidskrävande. React implementerar därför en virtuell DOM,
3.5. Node.js
en slags kopia, när en ändring sker som sedan jämförs med den nuvarande versionen av hemsidans DOM. Med hjälp av algoritmer uppdaterar sedan React bara de delar som behövs och kan på detta sätt spara den tid det tar att ladda om hela webbsidan [8] [9].
3.5
Node.js
Node.js är en exekveringsmiljö med öppen källkod för att skapa skalbara internetapplikatio-ner, särskilt webbservrar. Att använda Node möjliggör användandet av Javascript på server-sidan. Speciellt för Node är att det fungerar asynkront och är händelsedrivet, vilket gör att flera saker kan hanteras samtidigt och när Node inte behöver arbeta vilar applikationen. Likt React kan utvecklaren utöka funktionaliteten antingen genom att skapa funktionen själv, men även ta del av paket från utomstående parter via Node integrerade pakethanterare npm. [10]
3.5.1
Node Package Manager
Mer känt under förkortningen npm är en pakethanterare vida använd under utveckling med Javascript. Utvecklare kan med hjälp av gränssnittet i terminalen interagera med den publika databasen av Javascriptpaket och framförallt ta del av andra utvecklares arbete. Bland annat är React ett paket som återfinns i npm:s databas och en stor del av de tillägg som finns till React går också att nå via npm. Pakethanteraren har även en hemsida från vilken informa-tion om paket går att nå och användare kan skapa sig en profil för att antingen samarbeta på andras paket eller publicera sina egna. Vem och vad som publiceras är till stor del inte reglerat. [11]
3.6
Material Design
Material Design är ett designspråk utvecklat 2014 av Google. Det använder sig huvudsakli-gen av konceptet att objekt ser ut som kort. Dessutom använder det sig av rutnätsbaserad layout, responisva animationer och övergångar, utfyllnad (eng. padding) och effekter som ger intrycket av djup som ljus och skuggor. [12]
3.6.1
Material-UI
Material-UI är en implementation av Googles Material Design för React. Material-UI imple-menterar majoriteten av alla element som finns definierade i Material Design som Reactkom-ponenter och möjliggör enkel utveckling av användargränssnitt. Detta i en enhetlig stil utan att själv behöva bygga alla komponenter och dess funktionalitet från grunden. [13]
3.6.2
Löften
Löften (eng. Promise) i Javascript är en funktionalitet som tillåter en viss behandling av asyn-kron kod. Löftena representerar den lyckade eller misslyckade körningen av den asynasyn-kront körda koden genom att ge löftesobjektet två metoder: then och catch. Dessa två metoder exe-kveras efter ett löftesobjekt först slutfört den initiala uppgiften och skickar antingen tillbaka resolve eller reject. Det som löften garanterar, till skillnad från traditionell exekvering av kod i Javascript, är att uppgiften slutförs innan någon annan funktion bunden till resulatet av uppgiften exekveras [14].
Vidare har löften i nya versioner av Javascript kunnat representeras med hjälp av de två uttrycken async och await. Async är ett prefix till en godtycklig funktion användaren vill ska kunna exekvera asynkront och await är ett uttryck vilket bara får användas i en funktion som märkts med async. Await används för att låta en bit kod köra klart innan något annat får fortlöpa i funktionen och under huven skapas ett löftesobjekt. På detta sätt kan en användare
3.7. Axios
få samma resultat av att använda antingen löftesobjekt, eller genom att skapa funktioner med async och await [15] [16].
3.7
Axios
Axios är ett paket till Node som kan användas för att skicka HTTP-förfrågningar. Det har stöd för att skicka JSON-data och använder löften i Javascript för att säga till när ett svar till anropet har kommit. [17]
3.8
React DnD
React DnD är ett paket till Node som tillåter utvecklare att paketera sina komponenter i drag och släpp komponenter. Dessa komponenter tillåter delarna de paketerar att bli dragna eller att kunna ta emot komponenter som dras. Funktionaliteten att dra och släppa finns det stöd för i ren HTML5, dock är API:et för denna bökig. React DnD gömmer detta API och ger ett bra API för React. React DnD tillåter användaren att använda olika underliggande API:er för olika typer av dra och släpp funktionalitet. Ett exempel är att det finns ett alternativt underliggande stöd för pekskärmar istället för HTML5 som är standard. [18]
3.9
React router
React router är en nytagning på begreppet dirigering (eng. routing), vilket syftar till att diri-gera vad som visas på användarens skärm beroende på deras webbadress. Traditionellt har dirigering av innehåll skett via förfrågningar till servern som sedan kunde skicka tillbaka det som skulle visas i webbläsaren. Detta betyder att för varje gång användaren vill byta vy, exempelvis gå vidare i applikationen, måste en ny förfrågan skickas till servern för det nya innehållet. I längden är detta tidskonsumerande [19] [20].
Ett mer modernt tillvägagångsätt är att sköta dirigeringen från klienten med hjälp av Java-scriptkod, något som sker med React. Detta sätt att sköta det som servern traditionellt sett gjort kallas klientdirigering (eng. client-side routing) och möjliggör att inte behöva ladda om allt innehåll vid förändringar. React router erbjuder, utöver det React redan kan göra själv, en typ av dynamisk dirigering (eng. dynamic routing). Vanligtvis när användare dirigeras, oavsett om det är från server eller klient, sker detta statiskt. Statisk i den mening att adressers innehåll är fördefinierade och inte kan ändras under exekvering. Med dynamisk dirigering kan applikationen välja innehåll samtidigt som det ska renderas på skärmen. Det öppnar upp möjligheten att bland annat rendera innehåll efter skärmstorlek eller till exempel efter en användares behörighetsnivå [19] [20].
3.10
Express.js
Express är ett ramverk för Node släppt som öppen källkod. Det brukar anses vara standard-valet för serverramverk till Node. Det är gjort för att effektivt skapa webbapplikationer och API:er för serverdelen av applikationen. Express erbjuder även ett dussin gränssnitt för att koppla samman en applikations databas med serverdelen av applikationen och tillåter enkel kommunikation. En central del av Express är att dirigera trafik till rätt funktionalitet när klienter kommunicerar med servern. När en klient gör en HTTP-förfrågan är denna skickad från en viss adress vilken utvecklare kan låta Express lyssna på och därefter utföra rätt funktion. Ett mycket enkelt exempel på det kan ses i kodexemplet 3.2 där en inkommande POST-förfrågan från ’/’ får servern att svara med att förfrågan har mottagits. [21] [22]
3.11. Nodemon
app.post('/', function (req, res) { res.send('Got a POST request') });
Listing 3.2: Exempel på en dirigering av HTTP-förfrågningar i Express.
3.11
Nodemon
Nodemon är ett paket till npm som tillåter en server skriven med hjälp av Node att startas om när en förändring sker i filerna. Nodemon packeterar in de filerna som körs i den för att utvecklaren inte ska behöva skriva sina filer på ett annorlunda sätt från hur de skulle skriva kod till en server utan Nodemon. [23]
3.12
MariaDB
MariaDB är en vidareutvecklad gren av MySQL. Utvecklad av samma utvecklare för att be-hålla öppenheten efter det att MySQL köptes upp av Oracle. MariaDB är, precis som MySQL, en så kallad relationsdatabas bestående av rader och kolumner i form av tabeller. För att gö-ra dessa meningsfulla binds de samman med relationer och restriktioner. Då MariaDB är en direktutveckling av MySQL är den helt bakåtkompatibel med MySQL vilket innebär att en MySQL-databas går att köra direkt i MariaDB. [24]
3.13
Hashning och saltning
De två begreppen hashning och saltning kommer från engelskans hashing respektive salting vilka bland annat är centrala verktyg för att skydda lösenord sparade i databasen. Att hasha är kort beskrivet processen att ta en godtycklig längd med databitar och konvertera denna till en bestämd längd. Denna längd med databitar kan till exempel vara ett lösenord av godtycklig längd, som sedan konverteras till en samling blandade tecken av en exakt längd. För att hasha lösenord eller annan typ av data finns det flertalet olika algoritmer, till exempel SHA-algoritmerna SHA-0, SHA-1, SHA-2. [25]
Hashalgoritmer blir emellertid knäckta då beräkningskraft hos datorer ökar och angripare hittar brister i algoritmerna, men med hjälp av saltning kan åtminstone attacker gjorda med ren råstyrka (eng. brute force) motverkas. Saltning innebär att innan man hashar en använ-dares lösenord läggs det till en textsträng med unika karaktärer. Det genererar ett helt annat hash som dessutom är unikt för varje användare. Genereringen av salt lägger till ytterligare beräkningstid, men är till övervägande del positiv för användaren vars lösenord nu är betyd-ligt svårare att lösa. [25].
3.14
Git
Git är ett distribuerat versionshanteringssystem som används för att hantera källkod skriven av flera personer och är släppt som öppen källkod under villkoren för GNU General Public License version 2. Eftersom Git är distribuerat innebär det att varje utvecklare har en lokal kopia av projektet de arbetar med som sedan kan publiceras till resten av gruppen via ser-vern när det behövs. På detta sätt kan alla som deltar i projektet versionshantera både lokalt, det vill säga lätt gå tillbaka till äldre versioner, och även göra samma på servern. [26]
3.15. Trello
Vidare kan servern grena ut till skilda miljöer för att separera utveckling. När en utvecklare väljer att skapa en gren kopieras den nuvarande versionen av projektet från den gren som utvecklaren redan arbetar i. Med den nya grenen kan nu arbete både versionhanteras lokalt, som innan och vidare kan det nu publiceras till servern, utan att det påverkar andra perso-ner. Grenar kan då isolera utvecklingen av ny funktionalitet som eventuellt kan ha sönder den fungerande applikationen. I praktiken finns det vanligtvis en gren med den fungerande versionen av applikationen, en huvudgren, och flertalet grenar där utveckling sker. Ofta är dessa slags grenar bundna till en central gren för utveckling kallad Develop. När funktionali-tet har testats och anses vara redo att integreras med den fungerande koden kan grenar slås samman. [26]
3.14.1
GitLab
GitLab är en webbaserad Git-förvaring som används för bland annat versionhantering, planering, kodgranskning och problemhantering (eng. issue management). Tjänsten GitLab tillhandahålls till studenter och anställda vid Linköpings universitet av institutionen för datavetenskap [27] [28].
En av de grundläggande delarna som uppskattas med GitLab är verifikationsfunktionalite-ten som tjänsverifikationsfunktionalite-ten erbjuder. Det finns industriledande verktyg för att utvecklare ska kunna testa och bygga sin delar av projekten när det ska integreras med resterande del av projektet. Detta genom bland annat kontinuerlig integration (eng. continuous integration) som gör det möjligt för utvecklare att automatisera tester. Det finns även stöd för flertalet analysverktyg och skanningsverktyg som tillsammans kan hjälpa en grupp att hålla hög kvalitet på kod ut-an att det stjäl för mycket tid från utvecklingen. Som en ytterligare del av GitLab finns det verktyg för att göra sammanslagningen av grenar bekväm och informativ. Utvecklaren som vill slå samman sin gren kan då skapa en förfrågan att få sammanslå två grenar (eng. merge request). Samtidigt kan personen sortera förfrågan under taggar, föreslå personer som ska granska kod etc. Detta kan sedan publiceras och gruppen notifieras om att en ny förfrågan har lagts upp. Därefter kan gruppens medlemmar granska koden i det grafiska gränssnittet på projektets hemsida via GitLab och kommentera på specifika delar och föra en diskussion om det behövs. Slutligen kan förfrågan om sammanslagning godkännas eller nekas och då finns även möjligheten att låta GitLab automatiskt ta bort den nu onödiga grenen som slagits samman med huvudgrenen. [29]
3.15
Trello
Trello är ett visuellt verktyg för att organisera projekt. I programmet kan en användare skapa tavlor som andra medlemmar i projektet kan se och interagera med. Dessa tavlor innehåller i sin tur listor av kort som representerar en aktivitet. Varje kort kan ges ett antal egenskaper, där de kan tilldelas bland annat medlemmar, etiketter och checklistor. Genom att flytta kort mellan listor kan det användas för att ge en bra översikt i projektet av vad som ska göras, vad varje person håller på med för stunden, och vad som är klart. Flera listor kan även skapas för att exempelvis innehålla kort med aktiviteter som ska granskas. Anpassningsmöjligheterna är många och flera tillägg finns för att konfigurera projekttavlan till vad som behövs för just det aktuella projektet. [30]
3.16
Slack
Slack är ett molnbaserat samarbetsverktyg med huvudsakligt fokus på kommunikation inom arbetslag. Slack möjliggör mer strukturerad kommunikation än många andra kommunika-tionsprogram och erbjuder stöd för flera kanaler, direkt kommunikation mellan användare,
3.17. Figma design
hög sökbarhet, och ett stort bibliotek av insticksprogram som kan automatisera och effekti-visera kommunikationen och arbetet. Exempel på detta är integration med både Trello och GitLab i projektet som ger direkta notiser så fort något händer i projektet på dessa plattfor-mar. [31]
3.17
Figma design
Figma design är ett prototypningsverktyg som har stöd för att flera personer ska kunna ar-beta med samma designprojekt samtidigt. Figma används främst för att göra datorbaserade gränssnittsprototyper. [32]
4
Metod
I detta kapitel beskrivs det hur arbetet för att utveckla Placeholder har gått till. I kapitlet presenteras vilka metoder som används för att genomföra en förstudie, hur projektet har strukturerats, vilken metod som använts vid utveckling samt hur vissa verktyg som Trello och systemanatomin använts. Här presenteras även hur teststrukturen för projektet gjordes.
4.1
Förstudie
Förstudien som genomförts gick ut på att undersöka hur kunden ville ha produkten samt hur denna produkt skulle tas fram. Under förstudien har gruppen skrivit ett antal dokument, hur dessa skrevs presenteras under denna rubrik.
4.1.1
Krav och tidsplanering
Kraven för projektet togs fram genom att låta kunden förklara sin vision för analysansvarig och teamledaren som sedan framförde visionen för resterande av gruppen. Sedan satte sig gruppen och definierade vilka delar som ansågs behövas för att mjukvaran skulle uppfyl-la kundens vision. Det gruppen kom fram till beskrevs i en kravspecifikation som sedan delades med kund. Denna process upprepades till både kund och gruppen var nöjda med kravspecifikationen.
Utifrån de krav som togs fram i kravspecifikationen fick varje gruppmedlem enskilt kom-ma fram till milstolpar för produkten. Milstolparna beskrev större funktioner och tillstånd för produkten. Därefter diskuterades allas milstolpar och från diskussionerna gjordes en sammanställning av dem. Till varje milstolpe diskuterades olika aktiviteter fram. Dessa beskrev bland annat den funktionalitet som associerad milstolpe byggde på. Aktiviteterna användes för att tidsuppskatta utvecklingen av Placeholder. Uppskattningen gjordes genom planeringspoker där samtliga medlemmar fick göra en tidsuppskattning för varje aktivitet, som efter diskussion, fick en slutgiltig sådan. Därefter kunde aktiviteterna och milstolparna delas in i iterationer med start- och slutdatum så att gruppen tydligt skulle kunna se hur utvecklingen låg till tidsmässigt.
4.2. Projektstruktur
Utifrån kraven togs även en testplan fram, vilken var underlag för undersökning av att krav blev uppfyllda. Testplanen innehöll information om hur tester skulle gå till och klargörande för när ett test ansågs som godkänt eller icke godkänt.
4.1.2
Dokumentation
Projektgruppen har använt Overleaf för att skriva och lagra de dokument som lämnats in till kund eller handledare. Dokumenten har skrivits med hjälp av typsättningsverktygen LATEXoch mallar som använts har gruppens dokumentansvarig haft ansvar för att ta fram. Via Overleaf har sedan alla i gruppen kunnat arbeta samtidigt. Övriga dokument, som inte lämnades in utan endast var interna inom gruppen till exempel mötesprotokoll, skrevs och lagrades på Google Drive.
4.1.3
Prototyp
En prototyp för det grafiska användargränssnittet togs fram utifrån identifierade krav samt tolkningar av kundens önskemål. Detta gjordes genom att några gruppmedlemmar ritade olika gränssnittselement på en whiteboard-tavla som sedan kunde diskuteras och ändras. Gränssnittselementen som accepterades av gruppen ritades sedan in i en schemaläggningsvy där de diskuterades ytterligare. Därefter skapades en digital prototyp med hjälp av verktyget Figma design. I den digitala prototypen togs idéerna som skissats fram på tavlan och bands samman till ett enhetligt grafiskt gränssnitt som även tillät gruppen att skapa grundläggande funktionalitet. Funktionaliteten kunde simuleras i figma genom att binda knapptryck till att byta till alternativa gränssnitt som skapats i figma.
4.2
Projektstruktur
Här följer den struktur som gruppen planerat att använda under projektets gång. Här presen-teras information om hur mötena har gått till, hur Git användes i projektet samt hur gruppen har skött kommunikationen mellan varandra.
4.2.1
Möten
Handledar- och veckomöten planerades att hållas varje måndag under projektutvecklingen. Under dessa möten skulle varje gruppmedlem, om hen kände sig bekväm med detta, dela med sig om hur de mådde. Därefter skulle varje person ge en kort sammanfattning för vad personen gjort under föregående vecka och hur det arbetet gått. Målet med dessa möten var sedan att bestämma en planering inför den kommande veckan samt ställa frågor till handledare. Här skulle även handledare ha möjlighet att ställa frågor till gruppen samt ge återkoppling på inlämnade dokument.
I slutet av varje iteration hölls även ett möte för att ta vara på gruppens erfarenheter. Vid dessa tillfällen diskuterades även vad som gått bra samt dåligt under iterationens gång. De sämre erfarenheterna har diskuterats där försök till förbättringar på dessa har tagits fram. Under projektet hölls även ett antal kundmöten. Vid dessa möten var minst två gruppmed-lemmar närvarande som kunde svara på kundens frågor, men även ställa frågor till kunden. Även statusuppdateringar kring hur utvecklingen gick gavs till kunden under dessa tillfällen.
4.2.2
Git
För att versionshantera programkod användes Git med en gitförvaring på GitLab. GitLab valdes som förvaringsvärd på grund av de olika verktyg som värden tillhandahöll samt för
4.2. Projektstruktur
att det då gick att hålla projektet privat. På så sätt fanns möjlighet att lagra känslig data då inga utomstående kunde komma åt informationen. GitLab var ett givet val eftersom det är tillgängligt gratis för studenter vid Linköpings universitet genom institutionen för datave-tenskap.
Git som versionshantering planerades att följa en arbetsstruktur där det finns två statiska grenar, mästargren och utvecklingsgren. Det vill säga två utvecklingsgrenar som alltid exi-sterar i gitförvaringen. Utöver dessa grenar skulle en ny gren skapas varje gång en ny större funktionalitet skulle utvecklas till produkten eller ett problem skulle korrigeras. De verktyg som användes var GitLabs verktyg för att rapportera om problem och samt verktyget för att begära sammanfogning av grenar. Problem rapporterades genom en ifyllnad av ett formulär där vital information kring problemet beskrevs. Till formuläret fick rapportören även tillde-la problemet en gradering för hur allvarligt det var. Begäran om sammanfogning av grenar skulle göras då en funktionalitet ansågs klar av utvecklaren eller en korrigering av ett rappor-terat fel genomförts. Minst två utomstående gruppmedlemmar skulle därefter granska och godkänna koden genom GitLabs verktyg innan förändringarna sedan kunde sammanfogas med utvecklingsgrenen. Sammanfogning till mästargrenen skulle endast göras från en stabil utvecklingsgren.
4.2.3
Utveckling
Utvecklingsarbetet var uppdelat i flera olika iterationer. Till dessa iterationer hade vi tilldelat ett antal milstolpar med tillhörande aktiviteter. Hur milstolpar och aktiviteter valdes beskrivs närmare i avsnitt 4.1.1. Planen var att efter varje iteration skulle samtliga tillhörande milstol-par vara uppnådda. Det vill säga alla aktiviteter skulle vara utförda. Aktiviteterna utfördes i största utsträckning genom parprogrammering. Dessutom planerades tillfällen så att he-la gruppen kunde sitta tillsammans och arbeta, även om man inte nödvändigtvis arbetade med samma aktivitet. Då en aktivitet ansågs som genomförd tillkännagavs den till resten av gruppen som redo att testas. Testning av aktiviteter, som beskrivs närmare i avsnitt 4.4 ge-nomfördes därefter när någon gruppmedlem haft tid och då den var genomförd och godkänd kunde aktiviteten förklaras som genomförd.
4.2.4
Kommunikation
Under de planerade tillfällen som gruppmedlemmarna satt tillsammans och arbetade har kommunikationen skett muntligt, så att alla har fått möjlighet att vara delaktiga i diskus-sioner. Utöver dessa tillfällen har all kommunikation mellan gruppmedlemmar skett genom Slack. I Slack delades kommunikationen upp i flera kanaler där varje kanal hade en beskriv-ning över vilken sorts diskussioner som skulle förekomma inom den. De kanaler som fanns beskrivs i tabell 4.1. Utöver kundmöten sköttes kommunikation med kund genom mail och telefonsamtal.
4.3. Systemanatomi
Tabell 4.1: Sammanställning över de chattkanaler som funnits i Slack med en beskrivning över vad som förekommit i respektive kanal.
Kanal Beskrivning
Dokument Här delades information, fördes diskussioner och delades länkar som var direkt relaterat till de do-kument som skrivits.
Generellt Här skrevs det om allt möjligt som var relaterat till kursen och projektet.
Hårdvarulänkar Här delades hårdvarurelaterade länkar som kunde vara intressanta för projektet.
Mjukvarulänkar Här delades mjukvarurelaterade länkar som kunde vara intressanta för projektet.
Random Här skrevs det om allt möjligt mellan himmel och jord som inte nödvändigtvis var projektrelaterat.
4.3
Systemanatomi
Under förstudiefasen skapades en systemanatomi av gruppen genom att skriva upp funktio-ner och delar av systemet på lappar. Dessa lappar sattes sedan ihop på en whiteboard där pilar drogs mellan dem för att visa vilka delar av systemet som beror på vad. Efter att detta gjorts gjordes en revision av systemanatomin. Den reviderade versionen gjordes digitalt.
4.4
Testning
Testning av aktiviteterna gjordes av en till två gruppmedlemmar. Testpersonerna utgick från testplanen för att bland annat veta vilken sorts inmatning som skulle användas och vad det borde ge för resultat. Efter att tester genomförts dokumenterades resultatet i en testrapport. I rapporten skrevs information om vilket test som genomförts, vad man givit och fått för in-och ut-matning, vilka problem man stött på samt vad som behövde åtgärdas för att testet skulle räknas som godkänt.
4.5
Trello
Trello har använts för att tydligt visa vilka arbetsuppgifter som behöver utföras, vad som håller på att utföras samt vad som är färdigt. Det har även använts för att tydliggöra vilka gruppmedlemmar som arbetar med vad. Projektgruppen har haft två stycken tavlor, en för dokument och en för programmering. Båda tavlor beskrivs i tabell 4.2.
4.5. Trello
Tabell 4.2: Tabell över de listor, samt beskrivning för i vilken lista ett kort skulle placeras, för respektive Trello-tavla
Lista Dokument Programmering
Att göra Här placerades kort för de doku-ment som inte blivit påbörjade.
Här placerades kort för de aktivite-ter som inte blivit påbörjade. Pågående Här placerades kort i samband med
att någon börjat arbeta med det associerade dokumentet. Samtidigt som man flyttade kort till denna lis-ta lade man även till personen eller personerna som arbetade på doku-mentet.
Här placerades kort i samband med att någon eller några påbörjade ar-bete med aktiviteten.
Att granska Här placerades korten för de doku-ment som var redo att granskas av någon gruppmedlem.
Här placerades kort för de aktivite-ter som var redo för testning. Färdigt Här placerades korten för de
doku-ment som ansetts klara och redo för inlämning.
Här placerades kort i samband med att aktivitetens test blivit godkänd.
5
Resultat
Här beskrivs projektgruppens resultat i utvecklingen av Placeholder. Resultatdelen är kopp-lad med metod-kapitlet och beskriver resultatet av att använda den angivna metoden utöver de producerade resultaten. Detta kapitel presenterar vad som faktiskt har åstadkommits och vad som har gjorts under projektets gång.
5.1
Förstudie
I denna sektion presenteras resultatet av informationssökandet från innan utvecklingen av Placeholder påbörjades. Här presenteras resultatet av dokument som producerats, hur kra-ven framtogs och tidsplaneringen genomfördes samt hur designen av produkten togs fram.
5.1.1
Krav och tidsplanering
Genom att ha en person dedikerad till att diskutera fram krav med kunden har en relation kunnat byggas upp med kunden och nya vinklar på vad det är kunden vill ha har kunnat tas fram. Genom att ha diskussionen med kund och även slutanvändare har en kravspecifikation tagits fram som både gruppen och kunden är nöjda med.
Tidsplanering med planeringspoker gjorde att det fanns en satt tid för hur länge varje akti-vitet i milstolparna skulle ta. Detta medförde även att varje milstolpe hade ett antal timmar associerat till sig. Gruppmedlemmarna delade upp ansvaret för aktiviteterna till två eller tre av medlemmarna. När tid spenderades på att lösa en aktivitet skulle det rapporteras i ett do-kument för att visa hur mycket tid som fanns och hur mycket tid det gick åt för varje aktivitet. Det fanns även aktiviteter i Trello som skulle flyttas mellan de olika tavlorna för att visa på vad som blivit klart.
5.1.2
Dokument
Ett flertal dokument har producerats som ska hjälpa projektgruppen under själva utveck-lingsfasen och beskrivs i tabell 5.1. Dessa dokument skapar grunden för utvecklingsarbetat av produkten. Dokumenten visar resultatet av förstudien som genomförts och dokumente-rats i förberedelse för utvecklingsarbetet.
5.1. Förstudie
Tabell 5.1: Tabell över gruppens skrivna dokument
Dokument Beskrivning
Projektplan Den övergripande planen för hur projektet ska utföras.
Kvalitetsplan Den övergripande planen för att garantera kvalitet på mjukvara och dokument.
Kravspecifikation Specifikationen för vad produkten ska vara och vad den ska kun-na och inte kunkun-na göra.
Systemarkitektur Beskrivning av applikationens struktur.
Testplan Den övergripande planen för att kontrollera att produktens krav uppfylls.
Dokumenten definierade vad projektet Placeholder skulle handla om samt hur det skulle utföras. Dokumentskrivandet har varit till för att samla in all information om projektet Pla-ceholder.
5.1.3
Prototyp
Genom att börja designa prototypen på en whiteboard-tavla kunde en uppfattning i teamet skapas om hur designen skulle se ut. Efter att ha gjort om skissen på papper kunde en mer detaljerad skiss tas fram. Denna skiss kan ses i figur 5.1.
Figur 5.1: En pappersprototyp av Placeholders dagsvy.
Både pappersskissen och whiteboardskissen var svåra att se hur bra de skulle fungera på en datorskärm. Därför gjordes en digitalskiss över den viktigaste vyn för att se hur mycket in-formation som går att avläsa. I figur 5.2 kan det ses hur den digitala skissen över Placeholders dagsvy ser ut.
5.2. Projektstruktur
Figur 5.2: Första designskiss på dagsvyn av Placeholder
Denna dagsvy användes sedan som referens när det riktiga grafiska gränssnittet skapades i samarbete med de skisser som fanns på papper.
5.2
Projektstruktur
Denna rubrik behandlar hur projektstrukturen har fungerat utifrån den struktur som sattes upp i metoden.
5.2.1
Möten
Det var inplanerat att ha ett handledarmöte samt veckomöte varje måndag. Gruppen har haft möten de flesta måndagar, undantag har varit tentamensperioder och veckor med röd dag eller klämdag på måndagar. Då har mötet skjutits till nästa vita veckodag. Veckomötena var tillfällen då hela gruppen skulle träffas. Detta har fungerat i det stora hela. Vissa möten har frånvaro förekommit och i några få fall har frånvaro förekommit när den frånvarande inte har meddelat varför de var borta. Till varje möte har det funnits en dagordning som har följts, dagordningen har alltid innehållit en “Må-runda”. Denna runda är till för att kolla av läget med varje person i projektet och skapa en bättre gemenskap. Den har varit väldigt uppskattad av alla inblandade då den tillåtit folk att säga till när de känner sig stressade. De veckor när personer har känt sig stressade har arbetet kunnat anpassas för att ta hänsyn till detta. Detta har gjort att alla har kunnat prestera på topp.
5.2.2
Git
Versionshanteringen med Git har fungerat bra. Arbetsmetodiken var dock inte komplett vil-ket gjorde att det ibland var oklart hur versionshanteringen skulle fortgå. Metodik för hur och när utvecklingsgrenen skulle sammanslås med mästargrenen var inte tydlig nog. Det gjorde att mästargrenen inte fyllde den funktion som den skulle utan istället låg orörd. Det saknades även metodik för hur feature-grenar skulle hållas uppdaterade med utvecklingsgrenen, det vill säga när man skulle dra in utvecklingsgrenen i en feature-gren för att undvika för stora förändringar vid sammanslagning.
5.3. Systemanatomi
5.2.3
Kommunikation
Kommunikationen i gruppen har skett i största mån genom muntlig kontakt. Det som har skrivits ner vid de muntliga kontakterna är då gruppen har haft möten. Under övriga dis-kussioner har det diskuterade inte skrivits ner. När gruppen inte kunnat prata med varandra har Slack använts. Här har även information som har diskuterats skickats när det ansetts be-höva diskuteras vidare. För att visa vad som inte fungerar i den nuvarande produkten har GitLabs problemhantering använts. Här har gruppen skapat ärenden som visar på vad som behöver rättas till i produkten. När det kommer till feedback på dokument har informatio-nen dokumenterats i en pdf av dokumentet eller i en vanlig filtyp där man pekar ut vad som behöver göras. Denna information har sedan skickats över Slack till författaren av dokumen-tet. Feedback från handledaren har kommit igenom Slack. Denna information flyttades sedan till Google Drive där personerna kommenterade på de olika kommentarerna när de var åt-gärdade. Ifall det var ett större dokument med feedback skapades det kort i Trello där olika personer fick ansvar att lösa en viss del av feedbacken.
5.3
Systemanatomi
Systemanatomin användes för att förstå hur de olika delarna i Placeholders system in-teragerade med varandra. Först skapade gruppen tillsammans en systemanatomi på en whiteboard-tavla för att få en uppfattning av den grundläggande strukturen på Placeholders system. Denna första version av systemanatomin kan ses i figur 5.3, en större variant kan ses i bilaga H.1. Utifrån denna systemanatomi skapades det en ny, mer konkret, digital version som användes för att lokalisera de viktigaste delarna i systemet. Dessa utnyttjades sedan för att ta fram de milstolpar och aktiviteter som användes vid utvecklingen av projektet. Den digitala versionen av systemanatomin kan ses i figur 5.4.
Figur 5.3: Figuren visar systemantomin som gjordes på whiteboard-tavlan. En större bild kan ses i bilaga H.1
5.4. Testning
Figur 5.4: Figuren visar den digitala versionen av systemantomin. En större bild kan ses i bilaga H.2
5.4
Testning
Testningen som genomfördes var till största delen informell och gjordes i samband med ut-vecklingen av funktionalitet. Med informell testning menas att testerna inte direkt följde den framtagna testplanen. Till dessa tester skrevs heller ingen dokumentation utöver de kommen-tarer som tillkom i samband med att gitförvaringen uppdaterades. Resultatet från de mer for-mella testerna som gjordes finns dokumenterade i en testrapport. I testrapporten finns bland annat information om vem som utfört tester, vilka fel som uppkommit och vilka åtgärder som måste vidtas för att testet ska räknas som godkänt.
5.5
Trello
Genom att använda Trello för att visa vad som behöver göras har gruppen lyckats få en bra överblick över vad alla i gruppen arbetar med. Genom att förflytta ett kort till Pågående och lägga till de personer som arbetar med kortet vet de andra i gruppen att arbete görs på det kortet. När arbetet är klart flyttas kortet vidare till Granska där någon gruppmedlem som inte är på kortet kan granska arbetet. Ifall personen anser att arbetet är klart flyttas kortet vidare till Klara, annars flyttas det till Att göra med feedbacken kommenterad på kortet. Genom att använda det här sättet har alla alltid kunnat hitta något att göra. De två tavlor som använts på Trello har fungerat olika. Tavlan för Dokument var mindre belagd med aktiviteter och upplevdes lättare att navigera och få översikt på arbetet som ska göras, vad som pågår och vad som är klart. Tavlan för programmering var stundtals rörig, det var för mycket aktiviteter
5.6. Produktbeskrivning
och det var svårt att utgöra vem som skulle arbeta på vad. Programmeringstavlan ändrades efter viss tid och aktiviteter blev mindre. Detta fick resultatet att likt dokumenttavlan blev även programmeringen enkel att navigera och det gick att se vad som pågick.
5.6
Produktbeskrivning
Under denna rubrik kommer den resulterade produkten tas upp. Här återfås vilken typ av funktionalitet som finns och hur denna är implementerad. I denna sektion presenteras även vilket värde produkten Placeholder kan skapa för kund.
5.6.1
Systemskiss
Placeholder är byggd efter systemskissen som kan ses i figur 5.5. Systemskissen visar på hur programmet ska vara ihopkopplat. I figuren kan man se att allt som klienten ber servern att göra ska sparas undan i en loggfil. Det är också möjligt att se att klienten ska fokusera på att visa informationen och låta servern och databasen sortera och bearbeta informationen som kommer från användaren.
Figur 5.5: Figuren visar en systemskiss över Placeholder
5.6.2
Klient
Denna sektion beskriver hur Placeholder ser ut på klientsidan. Här presenteras även Place-holders funktionalitet. I figur 5.6 visas en bild på hur Placeholder ser ut. Det finns även en
5.6. Produktbeskrivning
version av figuren med en större storlek under bilaga H.3. I bilden går det att se en lista till vänster. Denna lista kallas resurslistan och används för att visa all personal som arbetar på verksamheten. Listan innehåller kort som kallas personalkort som kan återfinnas i resten av applikationen. Dessa kort visar vilket yrke personen har, den färglagda delen till vänster av kortet. Korten visar även vad personen heter, eller deras smeknamn om sådant finns. Det går även att se ifall en person ska gå på ett möte den schemalagda dagen. Detta ses genom att kolla på de runda prickarna nere i det högra hörnet på personalkortet. Prickarna matchar färgen på det möte personen ska gå på. I mitten av bilden kan man se ett antal blå kort. Dessa kallas rumkort och ska visa vilka personer som ska arbeta i det rummet för den schemalagda dagen. Rumkorten innehåller personalkort när den personen ska arbeta i det rummet. Till höger i vyn kan man se de möten som är inplanerade. Den runda cirkelns färg på ett möte korresponderar till färgen på personalkortens prickar. Genom att klicka på pilen i cirkeln på ett möte kommer en lista ner som visar vilka personer som ska delta i det mötet.
Figur 5.6: Figuren visar hur Placeholders huvudsida ser ut. För en större bild se bilaga H.3
Placeholder är byggd runt en central mekanik: dra och släpp funktionalitet. För att förflytta en person ifrån ett rum till ett annat i Placeholder behöver användaren ta tag i det perso-nalkort som ska flyttas och sedan dra det till det nya rummet. Detta gäller även inplacering av ny personal i rum. Användaren tar då tag i de personalkort som finns i resurslistan till vänster, se figur 5.6. Denna funktionalitet implementerades med hjälp av biblioteket Re-act DnD. ReRe-act DnD använder dra komponenter och släpp komponenter. I Placeholder är personalkorten dra komponenter. Släpp komponenterna är resurslistan, möteskorten och rumkorten.
Placeholder använder färger för att markera olika yrkesgrupper. De olika rummen som per-sonerna kan bli placerade i har olika behov på yrkesgrupper. Dessa behov visualiseras med samma färg som yrkesgruppen har. Man ser även en siffra som indikerar hur många av den angivna yrkesgruppen som behövs.
Ifrån figur 5.6 går det att se cirklar på vissa personalkort. Dessa cirklar representerar möten som personen kommer att delta på.
5.6. Produktbeskrivning
För att hämta hem information skickas en förfrågning med hjälp av axios till servern som returnerar den efterfrågade informationen som sedan kan visualiseras.
5.6.3
Server
Placeholders serverdel är byggd i ramverket Node.js [10]. Här beskrivs Placeholders ser-verstruktur. Placeholder är uppbyggt så att servern behandlar förfrågningar från klienten. Under de flesta av dessa förfrågningar fungerar servern som en mellanhand mellan klient och databas, det vill säga klienten berättar för servern vad den vill ha och servern skickar en förfrågan till databasen efter informationen. När servern sedan får ett svar från databasen behandlar servern informationen så att den kan skickas vidare till klienten.
Klienten kan inte formulera egna förfrågningar utan måste hålla sig till de förfrågningar som är tillgängliga i serverns applikationsprogrammeringsgränssnitt, översättning av Ap-plication Program Interface (API). Ett API beskriver hur du kan interagera med en viss programvara. För att skapa API:et har paketet Express [22] använts. Det betyder att designen till viss del blir modulär eftersom en API förfrågan kan användas var som helst ifrån i klien-ten.
För att kryptera lösenorden som sparas i databasen användes npm paketet bcrypt. Bcrypt saltar först lösenordet för att sedan hasha lösenordet innan det krypterade lösenordet sparas i databasen. När en användare ska logga in skickar den sitt lösenord. När ett lösenord ska jämföras för att se ifall det stämmer med det som är sparat i databasen används bcrypts egna jämförelse. Denna jämförelse letar upp vilket salt som har används i det krypterade lösenordet och genomför sedan krypteringen av det inskickade lösenordet med det som är sparat. Ifall de stämmer överens betyder det att det har skickats in rätt lösenord. [33]
Under utvecklingen av servern har paketet Nodemon använts för att underlätta utveckling-en. Nodemon startar automatisk om servern när en ändring har skett i filerna som serverna använder. Detta gör att servern beter sig på samma sätt som klienten, som automatiskt laddar om sidan när en ändring har upptäckts. [23]
5.6.4
Databas
Databasen är skapad efter ett EER-diagram, vilket kan ses i figur 5.7. En större version av figuren finns under bilaga H.4. Alla förfrågningar till databasen måste gå igenom fördefini-erade funktioner och moduler. Dessa funktioner tar information och letar sedan reda på rätt information i databasen för att sedan returnera denna information till servern. Databasen är gjord till MariaDB, en förgrening av MySQL. Men då MariaDB:s syntax är kompatibel med MySQL fungerar den till databaser som använder MySQL.
5.7. Node.js
Figur 5.7: Diagrammet visar hur Placeholders databas har designats. För en större figur se bilaga H.4.
5.6.5
Värde för kund
Kunden, Röntgenkliniken Linköping, schemalade vart deras anställda skulle vara varje dag i ett kalkylark. Placeholder erbjuder samma möjligheter som fanns i kalkylarket på ett enkel och smidigt sätt. Ett exempel där Placeholder överträffar föregående schemaläggningsteknik är med funktionaliteten dra och släpp. Med Placeholder kan schemaläggarna dra och släppa personerna på de ställen där de ska arbeta. Eftersom kalkylarket kräver att schemaläggaren ska klippa och klistra, eller skriva om personens namn i den nya cellen, inkommer många fel med hur stilen av cellerna ser ut. När man klipper och klistrar hänger formateringen av den gamla cellen med till den nya vilket skapar problem. Problemet är att hålla varje rum väldefinierat på ett stilistiskt vis.
Problemet med Placeholder är att det fortfarande är en prototyp. Den är inte redo att arbetas med för flera personer, men Placeholder skapar fortfarande ett värde för kunden. Det värde som skapas är i att kunden kan låta schemaläggare testa den prototyp som finns för att ta reda på vad som är viktigt för schemaläggarna för att de ska kunna lägga scheman så effektivt som möjligt. Då Placeholder redan är en prototyp kan denna utvecklas med den funktionalitet som behövs för att skapa en välanpassad produkt till kunden.
5.7
Node.js
Node.js användes som exekveringsmiljö på serversidan av produkten Placeholder. Node tillåter Placeholder att installera moduler med Node:s pakethanterare npm. Npm möjliggör paket att installeras till en applikation. Node sköter sedan att alla paket byggs och körs. Detta tillåter en applikation att fungera i realtid då Node ger möjlighet till uppdateringar av kod att ske samtidigt som applikationen kör. Node möjliggör även att skript kan skrivas. Dessa skript kan användas för att starta upp en server och en klient med ett kommando istället för
5.8. Gemensamma erfarenheter
flera. Detta underlättar en realtidsapplikation som Placeholders utveckling, då inga argument kommer glömmas när applikationen startas.
5.8
Gemensamma erfarenheter
Under projektets gång har ett antal erfarenheter uppsamlats. Resultatet från uppsamlingarna presenteras under relevant rubrik här.
Arbetssätt
Under projektets gång satt gruppen till största del gemensamt och arbetade, vilket enligt gruppens erfarenhet ledde till ett starkt samarbete och en god kommunikation mellan de närvarande gruppmedlemmarna. Detta eftersom de problem som uppstod under arbetets gång kunde tas upp i diskussion med övriga medlemmar och lösningar på dessa problem kunde lösas gemensamt på plats. Problemet som uppstod med denna arbetsmetodik var att de problem och lösningar som diskuterades var svåra att fånga upp då de sällan antecknades samt att det var svårt för de medlemmar som inte närvarade att uppfånga denna information i efterhand. Gruppen kom fram till att detta problem kunde ha lösts genom att exempelvis dela denna information över Slack, detta var däremot något gruppen inte hann sätta i bruk innan projektets avslut.
Undantaget till att gruppen satt gemensamt och arbetade var då samtliga gruppmedlemmar skrev på sin individuella del. Detta gjorde att vissa hade svårt med disciplinen jämfört med när de satt i grupp under resten av projektet, vilket ledde till att dessa individer inte fick myc-ket produktivt arbete gjort. Detta var någonting som upptäcktes ganska tidigt och det löstes genom att gruppmedlemmarna försökte sitta tillsammans för att arbeta produktivt även med denna del.
Git
En av erfarenheterna för gruppen var att trots att vi satt tillsammans var det svårt att få alla att hålla sina Git-grenar uppdaterade med den senaste utvecklings-grenen, vilket ledde till att utveckling skedde på utdaterad kod där antaganden om kodstruktur och funktionalitet gjordes som inte överensstämde med den senaste versionen.
Tidsuppskattning
För att kunna följa upp vår tidsuppskattning för aktiviteter fanns det ett separat tidsrapporte-ringsdokument där man fyllde i exakt vilken aktivitet man jobbade på, till skillnad från den generella tidsrapporten där man bara skrev en enklare beskrivning. Det var dock svårt för gruppen att rapportera på specifika aktiviteter då de flesta upplevde att de antingen gjorde flera aktiviteter samtidigt eller att de inte fanns någon aktivitet som passade.
Testning
Gruppen har under utvecklingens gång varit dåliga på testning överlag. Det har inte skrivits ordentliga testrapporter för de tester som genomförts. De tester som har genomförts har inte gjorts i den utsträckning som var tänkt initialt. Beslutet att inte skriva enhetstester i koden har också diskuterats och ifrågasatts.
5.9
Individuella bidrag
I denna sektion presenteras en kort översikt av de individuella bidrag som återfinns i del två i denna rapport.
