Visuell hantering av behörigheter till lokaler En grafisk lösning för hantering av lokalbehörigheter

Transkript

1 Linköpings universitet Institutionen för datavetenskap Examensarbete på grundnivå, 15hp Datateknik 2020 LIU-IDA/LITH-EX-G--20/013--SE Visuell hantering av behörigheter till lokaler En grafisk lösning för hantering av lokalbehörigheter Visual management of facility accesses A graphical solution to facility access management Matheus Bernat Johan Ehinger Jesper Jensen Ludvig Joborn Gustav Malmström Anders Ryefalk Mårten Walter Johannes Wilson Handledare : Jonas Wallgren Examinator : Kristian Sandahl Linköpings universitet SE Linköping ,

2 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 administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to 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 consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: Matheus Bernat Johan Ehinger Jesper Jensen Ludvig Joborn Gustav Malmström Anders Ryefalk Mårten Walter Johannes Wilson

3 Sammanfattning Denna rapport beskriver ett arbete genomfört av åtta studenter i kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet under vårterminen Arbetet efterfrågades av företaget Ericsson AB. Syftet var att göra den existerande processen att begära och bevilja tillträden till lokaler enklare. Den åstadkomna produkten blev en webbapplikation som hanterar den ovannämnda processen med hjälp av en interagerbar och visuell karta. Användarvänligheten stod i fokus enligt kundens önskemål. Rapporten innehåller en gemensam beskrivning av utvecklingsprocessen, presentera resultatet och diskutera resultatet av. Rapporten innehåller också individuella bidrag från gruppmedlemmarna inom områden som är relevanta till projektarbetet.

4 Författarens tack Gruppen vill utdela ett stort tack till alla parter som har hjälpt till under projektets gång. Ett särskilt tack går ut till Mikael Stenvall som varit med och hjälpt som både stöd och kundkontakt. Gruppen vill också gärna tacka Linköpings universitet som agerat flitigt och till deras bästa förmåga under krisen som utspelat sig i omvärlden under detta projekt. Tack även till Kristian Sandahl och Jonas Wallgren som funnits med och väglett projektet både i utvecklingen och rapporterna. Gruppen vill fortsätta med att tacka sina mammor och pappor samt de som bjöd på fika under de fysiska mötena. Tack. iv

5 Innehåll Sammanfattning Författarens tack Innehåll Figurer Tabeller iii iv v viii ix 1 Inledning Syfte Bakgrund Frågeställningar Motivering till frågeställningar Begränsningar Tidigare erfarenheter Teori Åtkomstkontroll Databaser och lagring av person- och företagsuppgifter Utvecklingsverktyg Arbetsmetoder Programmeringsramverk Systemanatomi Metod Organisation Förstudie Distansläge Utvecklingsmetod Metod för att fånga erfarenheter Individuella bidrag Resultat Systembeskrivning Systemanatomi Prototyp Systemroller Systemstruktur Gemensamma erfarenheter Kodgranskning Individuella bidrag v

6 5 Diskussion Resultat Metod Arbetet i ett vidare sammanhang Slutsatser Slutsatser kring frågeställningar Uppfyllande av syfte Viktigaste lärdomar A Matheus Bernat CI i ett kandidatprojekt 47 A.1 Inledning A.2 Bakgrund A.3 Metod A.4 Teori A.5 Resultat A.6 Diskussion A.7 Slutsatser B Johan Ehinger Kryptering av relationsdatabaser 57 B.1 Inledning B.2 Bakgrund B.3 Teori B.4 Metod B.5 Resultat B.6 Diskussion B.7 Slutsatser C Jesper Jensen Utveckling av mjukvara på distans 66 C.1 Inledning C.2 Bakgrund C.3 Metod C.4 Teori C.5 Resultat C.6 Diskussion C.7 Slutsatser D Ludvig Joborn Kritiska krav: En fallstudie 77 D.1 Inledning D.2 Bakgrund D.3 Teori D.4 Metod D.5 Resultat D.6 Diskussion D.7 Slutsatser E Gustav Malmström Agil systemutveckling med Scrum i ett mindre projekt 85 E.1 Inledning E.2 Bakgrund E.3 Teori E.4 Metod E.5 Resultat E.6 Diskussion E.7 Slutsatser vi

7 F Anders Ryefalk React med och utan Redux 98 F.1 Inledning F.2 Teori F.3 Metod F.4 Resultat F.5 Diskussion F.6 Slutsatser G Mårten Walter Affärsmodeller för mjukvarusystem 110 G.1 Inledning G.2 Bakgrund G.3 Teori G.4 Metod G.5 Resultat G.6 Diskussion G.7 Slutsatser H Johannes Wilson Mjukvarusystem efter dataskyddsförordningen 117 H.1 Inledning H.2 Bakgrund H.3 Teori H.4 Metod H.5 Resultat H.6 Diskussion H.7 Slutsatser Litteratur 125 I Bilaga 1: Kravspecifikation 133 vii

8 Figurer 4.1 Systemanatomi för en reader i systemet Systemanatomi för en admin i systemet Prototyp för en readers sida Prototyp för en approvers sida Prototyp för en admins sida Exempel på hur tredelad arkitektur fungerar vid inloggning till ett system Webbgränssnittets login-sida Sida med lista över ens egna förfrågningar Startsida för en reader Sida för att begära åtkomst till rum Startsida för en approver Sida för att som approver frånta en annan användares access Dialog som visas för en approver ifall hen klickar på en beställning Startsida för en admin Sida för att redigera accessgrupper som admin Sida för att skapa användare som admin Sida för att redigera användare som admin EER-modell över databasens entiteter Relationsmodell över databasens tabeller A.1 Pipeline skapad av ovanstående.yaml-fil A.2 Svar på en av enkätens frågor B.1 DDM exempel C.1 Grupperat stapeldiagram med för- och nackdelar med distansarbet från svaren i fråga 1 och C.2 Stapeldiagram för frågan om vilka verktyg som underlätta distansarbetet C.3 Stapeldiagram för vilket verktyg som är bäst för ett möte med åtta personer C.4 Tårtdiagram för andelen som arbetat i projektgrupp på distans C.5 Stapeldiagram för hur bra arbetet gick efter övergången till distans C.6 Stapeldiagram för metoden att välja verktyg bestämdes C.7 Grupperade stapeldiagram för de verktyg som användes i olika situationer E.1 Exempel på en GitLab-tavla E.2 Exempel på en burndown chart E.3 Burndown chart från sprint E.4 Burndown chart från sprint E.5 Burndown chart från sprint E.6 Burndown chart från sprint F.1 Schematisk bild av Redux arkitektur viii

9 Tabeller 3.1 Dokument Sprintar Kommentarer per kodsprint D.1 Gränskategorierna som de definieras i CSH ix

10 1 Inledning Många större företag använder idag elektroniska lås för in- och utpassage i deras lokaler. Dessa elektroniska lås öppnas vanligen av passerkort som är kopplade till en digital behörighetskontroll. Denna behörighetskontroll behöver i sin tur mjukvara som möjliggör redigering av behörigheterna som tillhör passerkorten. Mjukvaran som används för hantering av lokalbehörigheterna för passerkort är dock inte alltid användarvänlig. Om detta är fallet kan hantering av lokalbehörigheter vara onödigt krånglig och kräva mer tid jämfört med ett mjukvarusystem med god användarvänlighet. Denna rapport beskriver utvecklingsprocessen av ett system för hantering av lokalbehörigheter. Systemet beställdes av Ericsson AB och utvecklades av åtta studenter vid Linköpings universitet i samband med kursen TDDD96, Kandidatprojekt i mjukvaruutveckling [1]. I detta avsnitt redogörs bakgrunden till systemet såväl som det syfte och de frågeställningar som denna rapport kommer att utgå från. Slutligen tas det upp vilka begränsningar som detta projekt utsätts för, följt av erfarenheter som projektgruppen har haft sedan tidigare. 1.1 Syfte Syftet med rapporten är att beskriva arbetsprocessen och utvecklingen av den produkt som beställdes av projektgruppens kund, Ericsson AB. Rapporten redogör för gruppens erfarenheter under projektets gång, och resultatet av projektet diskuteras. Projektets syfte var i sin tur att göra den existerande processen att begära och bevilja tillträden till lokaler mer användarvänligt. Stort fokus las på att bygga ett mer visuellt system än det existerande hos uppdragsgivaren Ericsson AB. Ytterligare syften var att leverera ett system som kunden blev nöjd med och att utveckla kunskaper kring hur man jobbar i ett större mjukvaruprojekt. 1.2 Bakgrund Stora företag med säkerhetskritiska rum och lokaler möter ett antal utmaningar när det gäller hanteringen av behörigheter till dessa. Det är idag vanligt med elektroniska lösningar för 1

11 1.3. Frågeställningar detta i form av accesskort med tillhörande kortläsare. Flera företag som installerar sådana säkerhetslösningar exempelvis Bravida [2] och Safeguard [3] finns på den svenska marknaden. Det som idag saknas och som vår kund har efterfrågat, är ett sätt att lättare hantera de behörigheter som ett sådant system innebär. Kunden söker ett system så att tilldelandet av behörigheter till en person kan ske på ett enkelt sätt med den tillförlitlighet och säkerhet som företaget kräver. Problemen som kunden upplever kommer från att behörigheter inte är kopplade till de rum som finns i en byggnad. Behörigheterna är endast kopplade till de kortläsare som sitter på vardera sida om dörrarna. Dessutom är läsarna namngivna med svårlästa maskingenererade namn. Detta gör att det kan bli en långdragen process för att tilldela en grupp anställda en eller flera nya lokalbehörigheter. Med detta system behöver man ta reda på namnet på alla kortläsare in och ut ur det rummet och vilken accessgrupp som innehåller dessa behörigheter. Detta öppnar upp för fel och kräver mycket tid av administrativa personalen på företaget. Det finns heller inget sätt för en vanlig anställd att se sin behörighet till lokalerna. Detta innebär att för att som anställd kunna se sin behörighet måste man gå till receptionen och be receptionisten att kontrollera ifall man har behörighet. Om man behöver en ny behörighet måste den administrativa personalen att sköta behörighetsbeställnigen. Processen är krånglig och binder upp mycket tid hos administrativ personal med uppgifter som är repetitiva. Det ligger i kundens Ericsson AB:s intresse att utveckla ett system som kan ta bort mycket av den manuella arbetsgången för personalen. Ett bra system skulle inte bara lösa problemet att administrativa delar tar lång tid, det skulle också hjälpa till vid möteskallelser då användaren lätt kan se vilka lokaler som hen har tillgång till. Det hjälper även i arbetet som företaget utför då anställda lätt kan byta projekt och enkelt befinna sig i nya lokaler utan att säkerheten får lida. Ett bättre behörighetssystem skulle förbättra samarbetet mellan konsulter, anställda, chefer, områdesansvariga och så vidare vilket i sig är väsentligt för att kunna utföra teamarbeten och uppdrag på ett effektivt sätt. 1.3 Frågeställningar För att uppnå godkänt i kursen TDDD96 [1], leverera ett system gruppen och kunden är nöjda med och utveckla kunskapen kring hur man jobbar i ett större mjukvaruprojekt kommer följande frågor att besvaras: 1. Hur kan systemet implementeras så att värde skapas för kunden? 2. Vilka erfarenheter kan dokumenteras från Visuell hantering av behörigheter till lokaler 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. Vilka för- och nackdelar finns det med att använda kodgranskning i ett litet mjukvaruutvecklingsprojekt? 1.4 Motivering till frågeställningar Här motiveras och förklaras projektets frågeställningar Frågeställning 1 Denna frågeställning kopplas till hur projektgruppen uppnår ett system som både gruppen och kunden är nöjda med. Antagandet som har gjorts är att värde för kunden skapats när kraven i systemets kravspecifikation har uppnåtts och följts upp. 2

12 1.5. Begränsningar Frågeställning 2 Denna frågeställning riktar in sig i sin tur på hur gruppen ska utveckla sin gemensamma och individuella kunskap kring denna typ av projekt. Frågeställningen har som mål att sammankoppla alla erfarenheter kring projektet och på det sättet kunna meddela framtida projektarbeten om vad som är viktigt, vad som gjordes bra och vad som kunde ha förbättrats Frågeställning 3 För att koppla ihop utvecklingsprocessen med gruppens och individens lärande är det viktigt att svara på denna frågeställning. Frågan har som mål att få projektgruppen att tänka igenom projektet och koppla utvecklingen med lärandet. Målet är också att se hur man skulle kunna använda systemanatomin som stöd under projektets gång Frågeställning 4 För att få återkoppling på utvecklingsprocessen och kvaliteten på kod kan kodgranskning användas. Frågan syftar till att undersöka hur kodgranskning har använts i projektet och vilka fördelar eller nackdelar det förde med sig. 1.5 Begränsningar Projektet är främst begränsat i tid, gruppen ska lägga 380 timmar per gruppmedlem, så totalt finns 3040 timmar att tillhandahålla. Inräknat i dessa timmar är allt som rör kursen: utveckling av produkten, dokumentskrivning, föreläsningar, möten, seminarier, presentationer och opponeringstillfällen. Funktionaliteten i produkten begränsas primärt av de krav som ingår i kravspecifikationen (se bilaga I). Produkten kommer att utvecklas till en avancerad prototyp och kommer inte att vara testad eller byggd för att användas i produktion vid projektets slut. Produkten ska därefter kunna användas som en utgångspunkt för att bygga ett nytt system som uppfyller samma funktioner. Dessa begränsningar härstammar från de användningsområden som kunden ansåg viktiga för produkten. 1.6 Tidigare erfarenheter Projektmedlemmarna går på civilingenjörslinjerna Datateknik eller Mjukvaruteknik. Medlemmarna har goda kunskaper i programmering och andra datarelaterade kunskaper. De medlemmar som studerar Mjukvaruteknik har läst kurser om webbutveckling och databaser, något som gynnat gruppen då dessa kunnat vägleda projektets riktning i de tidiga faserna av projektet. De som utfört projektet har tidigare i sin utbildning fått prova på att jobba i projekt för mjukvaruutveckling. Flera har också gjort det under sommarjobb, extrajobb eller i föreningsliv. Positiva erfarenheter som alla i gruppen upplevt och vill behålla är: bra kommunikation, gott samarbete och god stämning. Om kommunikationen är bra i gruppen så följer ofta de två sistnämnda automatiskt. Vid god kommunikation blir det enkelt att ha ett bra samarbete då eventuella missförstånd och eventuellt dubbeltarbete undviks. När dessa undviks bidrar det till en bra stämning i gruppen där alla känner att de kan bidra till det gemensamma arbetet. På grund av tidigare negativa erfarenheter ville gruppen undvika situationer där kunskap inte delas mellan gruppmedlemmarna. Gruppen ville också undvika att kritik som relaterar till 3

13 1.6. Tidigare erfarenheter projektet ska tas personligt. Om gruppen strävar att hålla sig borta från dessa dåliga aspekter skapas goda förutsättningar för bra kommunikation, gott samarbete och god stämning. 4

14 2 Teori I detta kapitel ges en teoretisk bakgrund till de koncept och modeller som rapporten använder. 2.1 Åtkomstkontroll Behovet att skydda värdefulla resurser har existerat i alla tider. Dessa resurser kan vara både materiella och immateriella tillgångar. Exempel på materiella tillgångar är sekretessbelagda lokaler och värdesaker, medan immateriella tillgångar ges i form av information och kunskap [4]. Åtkomstkontroll är den process som säkerställer att endast behöriga individer eller system får åtkomst till de avsedda resurserna. Denna process har potentialen att främja både åtkomst och delning av resurser. Däremot kan en dåligt genomförd åtkomstkontroll medföra ekonomiska och vetenskapliga förluster och följaktligen stor frustration för de inblandade parterna [4]. Åtkomstkontroll strävar efter att uppnå konfidentialitet, integritet och tillgänglighet. Konfidentialitet innebär att endast behöriga parter får ta del av den skyddade resursen. Integritet innebär att endast behöriga parter får ändra den skyddade resursen. Slutligen innebär tillgänglighet att den avsedda resursen, i största möjliga mån, ska vara tillgänglig för de behöriga parterna [5]. Beroende på vilken resurs man avser att skydda finns det olika metoder för att åstadkomma detta. Fysisk åtkomstkontroll har historiskt sett åstadkommits med hjälp av personal som vakter, mekaniska apparater som lås och även elektroniska apparater som kortläsare. De elektroniska sätten att lösa åtkomstkontroll har flera fördelar jämfört med de andra. För det första går det att lagra i en systemlogg vilka handlingar som har utförts och på detta sätt ha bättre översikt över vilka som tar del av den avsedda resursen. För det andra är det enkelt att ta bort ett korts åtkomst till en resurs ifall kortet tappas bort [6]. 2.2 Databaser och lagring av person- och företagsuppgifter För att hantera behörigheter till lokaler går det inte att komma ifrån att data lagras om vilka behörigheter som existerar och vilka användare de tillhör. I det här avsnittet redogörs för hur 5

15 2.2. Databaser och lagring av person- och företagsuppgifter behörighetsdata lagras och på vilket sätt lagrad data kan omfattas av dataskyddsförordningen Relationsdatabas och SQL En databas är en samling av logiskt sammanhängande data. I en relationsdatabas lagras data i tabeller (relationer). Dessa består av rader och kolumner vilket motsvarar poster (eng. records) respektive attribut. En rad i en tabell utgör och innehåller en unik instans av data och identifieras av en unik primärnyckel (eng. primary key). Vidare kan tabeller ha kolumner för främmande nycklar (eng. foreign key) som är en typ av referensattribut som refererar till primärnycklar i andra tabeller. Genom främmande nycklar kan relationer mellan data i olika tabeller upprättas. Genom så kallad normalisering kan relationer och data i relationsdatabaser göras icke-redundant, vilket sparar lagringsutrymme men framförallt förhindrar datamanipulationsanomalier och dataintegritetsförluster [7]. Databaser brukar skapas och underhållas med hjälp av databashanteringssystem alltså ett eller flera datorprogram på ett sätt sådant att databasanvändarna inte behöver känna till exakt hur datan lagras, struktureras och kodas i filer. Många databashanteringssystem för relationsdatabaser tillämpar Structured Query Language (SQL) som kommunikationsspråk för att låta användare hantera data. SQL-syntax innefattar bland annat frågor (eng. queries), uttryck för att skapa och ta bort tabeller och uttryck för att lägga till och ändra data i tabeller [8] EER-modell En EER-modell (kort för eng. Enhanced Entity Relation Model) används för att skapa konceptdiagram över databaser i ett tidigt skede databasdesignprocessen. De ger en högnivåöverblick över databaskonceptet och gör det enkelt att diskutera designen med personer som inte har någon större erfarenhet av databaser. Dessutom går det sedan enkelt att översätta en EERmodell till en relationsmodell och därefter att implementera relationsmodellen i ett specifikt databashanteringssystem [9] Relationsmodell En relationsmodell är också ett sorts konceptdiagram över en databas, men används snarare för att illustrera implementationsdetaljer. I en relationsmodell framgår relationer och deras attribut, samt primärnycklar och främmande nycklar. Från en relationsmodell kan en databas enkelt implementeras i en specifik databashanterare genom att uttrycka modellens detaljer i det språk och den syntax som hanteraren tillämpar [10] Personuppgifter och dataskyddsförordningen Som en del av systemet för att hantera behörigheter till lokaler kommer en databas att upprättas vilken innehåller data om användare, passerkort, rum och behörigheter. Eftersom användare i systemet är tänkta att representera personer och vi avser att lagra viss data om dem kan personuppgifter anses lagras av systemet. I dataskyddsförordningen (GDPR, eng. The General Data Protection Regulation) görs en distinktion mellan vanliga personuppgifter och känsliga personuppgifter. Till vanliga personuppgifter hör bland annat personnummer, namn och adresser i vissa fall elektroniska identiteter medan känsliga innefattar information som etnicitet, sexuell läggning, politiska åsikter, religionsåskådning samt hälso- och sjukvårdsuppgifter. Vidare måste all hantering av personuppgifter följa dataskyddsförordningen, vilken säger att sådan hantering måste vila på rättslig grund [11]. 6

16 2.3. Utvecklingsverktyg För företag är det främst de rättsliga grunderna samtycke, avtal, rättslig förpliktelse och intresseavvägning som är aktuella att använda. De berörda personerna ska alltid informeras om vilken rättslig grund deras uppgifter behandlas på, vilket ställer krav på dokumentation av resonemang om varför dessa uppgifter används. Därutöver får insamling och hantering av personuppgifter endast ske för berättigade ändamål som hela tiden är och har varit tydligt angivna. Personuppgifter bör också skyddas på sätt som förebygger och förhindrar att de blir stulna eller oavsiktligt raderade eller ändrade. Ett sätt att efterleva kraven i dataskyddsförordningen är att se till att personuppgifter inte behandlas i onödan: till exempel att ett system inte samlar in, delar ut eller visar mer information än nödvändigt [11]. Vidare bör tillgång till personuppgifter bara vara möjlig på nödvändig grund (eng. need-to-know basis) och via rollbaserad tillgång [12] Hashsummering av lösenord Av säkerhetsskäl bör inte användares lösenord lagras i klartext. Det är istället bra praxis att hashsummera lösenord med hjälp av en hashfunktion. En hashfunktion utför en matematisk envägstransformation av lösenordet till en ny sträng sådan att lösenordet inte ska kunna återskapas i klarttext. Det är alltså det hashade lösenordet som sparas i databasen. När användare sedan ska logga in via tillhörande applikation anger de sitt lösenord i klartext vilket hashfunktionen appliceras på, och resultatet jämförs därefter med det hashade lösenordet i databasen [13]. 2.3 Utvecklingsverktyg Projektet har använt flera utvecklingsverktyg för att underlätta utvecklingen och i det här avsnittet tar vi upp teorin kring dem Git Git är ett versionhanteringssystem utvecklat av Linus Tordvals i syfte att organisera utvecklingen av operativssytemet Linux. Sedan dess början i 2005 har Git blivit ledande inom versionshantering för mjukvaruutveckling, med stöd för integrering med många tredjepartsprogram [14] GitLab GitLab är ett program som syftar till att effektivisera livscykeln för systemutveckling och som integrerar de olika stegen i en utvecklingsprocess. GitLab använder Git för fjärrlagring av kodprojekt men tillhandahåller också tjänster som automatiskt byggande och körande av kod, uppslagstavlor, och ärendehantering [15]. Linköpings universitet tillhandahåller en licens för GitLab som får användas av studenter vid universitetet [16] Slack För att effektivt kommunicera utanför möten så använde projektgruppen Slack, ett chattsystem som erbjuder molnbaserade verktyg och tjänster för grupparbeten. Slack tillät gruppen att ansluta så kallade appar för andra tjänster och verktyg som användes i projektet, till exmpel GitLab och Google Calendar, vilket gjorde att information om och från dessa kunde förmedlas direkt i gruppens chatt [17] Zoom Kommunikation med ljud och bild, som ersättning för fysiska möten, har skett med hjälp videomötesverktyget Zoom [18]. Under distansundervisning var det i Zoom som samman- 7

17 2.4. Arbetsmetoder strålningar, handledarmöten, workshops, diskussioner och allmänt samarbete inom gruppen skedde. 2.4 Arbetsmetoder Projektgruppen har använt sig av olika arbetsmetoder och här tar vi upp teorin för dem Agil utveckling Agil utveckling (eng: Agile development) är ett samlingsnamn på utvecklingsmetoder som bygger på metodik som främjar flexibilitet och evolution. Agila utvecklingsmetoder följer följande värderingar: individer och interaktioner över processer och verktyg, fungerande mjukvara över utförlig dokumentation, samarbete med kund över förhandling och att reagera på förändring över att följa en plan (översatt från [19]) Scrum Scrum är ett agilt utvecklingsramverk för utvecklingsteam på maximalt tio personer. Det finns många utökningar och varianter av Scrum, men grundprinciperna bygger på att bryta ner arbete i tidsbegränsade iterationer, så kallade sprintar, och sedan utvärdera arbetet i korta sprint-möten som hålls dagligen. På dessa möten utvärderas och planeras det kommande arbetet [19] Branch based workflow Branch based workflow, feature-branch workflow, eller bara git-flow är ett sätt att nyttja verktyget Git för effektiv hantering av olika arbetsytor, kallade branches, som en del i utvecklingsprocessen. Tanken är att separera arbete som sker parallellt till olika arbetsytor för att undvika konflikter under arbetet. Det ger också möjligheten att reservera vissa arbetsytor för mer kompletta versioner [20]. 2.5 Programmeringsramverk Mjukvaruutvecklingsprojekt av kandidatarbetesstorlek motiverar användandet av olika ramverk. Nedan ges en kort beskrivning av ramverken och verktygen som används i detta projekt React React är ett JavaScript-bibliotek som används för att bygga webbgränssnitt. Biblioteket skapades av företaget Facebook år 2013 och är släppt med öppen källkod. Den stora fördelen med React är att gränssnittets komponenter enkelt kan delas upp och hantera sina egna tillstånd. Detta medför en förenkling av byggandet av mer komplexa gränssnitt och av återanvändandet av färdigskrivna komponenter. React-strukturen är byggd för att behandlas som basen för utveckling av single-page applications. React skrivs i språket JSX, som är en blandning av HTML (se 2.5.9) och skriptspråket JavaScript [21] SPA SPA står för single-page application och är en webbapplikation eller webbplats som dynamiskt uppdaterar den nuvarande webbsidan med hjälp av webbläsaren. Standardmetoden om man inte bygger en SPA är att på en webbplats byta mellan olika webbsidor för att ladda ny information beronde på vad användaren begär. En SPA använder sig istället bara av en enda 8

18 2.5. Programmeringsramverk webbsida på sin webbplats och uppdaterar den dynamiskt. Målet med detta är att få hemsidan att kännas responsiv genom snabba och snygga övergångar [22] Material UI Material UI är ett gränssnittsbibliotek bestående av React-komponenter som är implementerade med Google s Material Design [23]. Syftet med detta bibliotek är att underlätta arbetet med React-komponenters utseendet Flask Flask är ett mikroramverk skrivet i Python som är designat för att låta sina användare snabbt och enkelt skapa webbapplikationer på servernivå [24]. Flask är mycket minimalistiskt vilket betyder att kärnfunktionerna är simpla och lätta att bygga ut på. Ett bra citat från flask dokumentationen är: [...] Flask can be everything you need and nothing you don t. [25] Utöver det går det att använda sig av funktionalitet från SQLAlchemy (se 2.5.6) genom biblioteket Flask-SQLAlchemy Object-relational mapper Object-relational mapper, eller ORM, är ett objektorienterat system som är skapat för enkel hantering av databasförfrågningar genom att skapa dataobjekt. Genom att använda en ORM abstraheras databasens tabeller bort. Utvecklaren gör istället förfrågningar på dataobjekt, som ORM:en internt omvandlar till och från förfrågningar i SQL [26] SQLAlchemy För att kommunicera med en databas genom en Flask-server kan SQLAlchemy, vilken inkluderar en ORM, användas [27]. I synnerhet biblioteket Flask-SQLAlchemy [28]. Vanligtvis sker kommunikation med en relationsdatabas genom SQL-förfrågningar till en relationsdatabashanterare i dess specifika språk. SQLAlchemy ger utvecklare möjlighet att kommunicera med relationsdatabaser genom Python-kod. Python-koden översätts sedan till rätt SQLsyntax för den databashanterare som används. Detta gör det lätt att byta mellan två olika databaserhanterare om det så krävs utan att en stor mängd kod behöver skrivas om. Flask har också bra stöd för SQLAlchemy med ett paket som heter Flask-SQLAlchemy som förenklar användningen genom hjälpfunktioner för vanliga operationer SQLite SQLite är en SQL-databashanterare som använts i projektet [29]. SQLite är en öppen, fri mjukvara som är lättviktig när det kommer till installation, administrering och resursanvändning [30]. Vidare fungerar SQLite som en inbyggd databas i meningen att det inte kräver att en serverprocess samtidigt körs över nätverket. SQLite är också lättviktig i funktionalitet; till exempel stödjer det bara fem datatyper, erbjuder inget autentiseringssystem och hanterar inte samtidighet. Däremot är SQLite väldigt snabbt, mycket tack vare dess enkelhet PostgreSQL PostgreSQL är en kraftig och robust relationsdatabashanterare som används världen över [31]. Till skillnad från SQLite följer förfrågningarna till databasen ACID-standarden. ACID står för atomicity, consistency, isolation och durability som är fyra viktiga attribut som ser till att hanteringen av databasen hanteras på ett konsist sätt [32]. PostgreSQL tar dock längre tid att sätta upp och få att fungera då en serverprocess för databasen krävs [30]. 9

19 2.6. Systemanatomi HTML Hyper Text Markup Language (HTML) är ett vanligt märkspråk som beskriver hur en webbläsare ska presentera ett dokument som innehåller text, bilder och andra komponenter. Det används för att skapa elektroniska dokument så kallade sidor som visas på internet. Det används ofta i samband med andra teknologier såsom CSS och JavaScript [33] CSS Cascading Styling Sheets (CSS) är ett programmeringsspråk använt till att beskriva presentationsstilen för ett dokument. Med hjälp av CSS kan man ändra på ett dokuments färg, fontstorlek och upplägg. Ett HTML-dokument har inte någon utformning beskriven i sig själv och därför krävs CSS för att designa sidan som det önskas [34]. 2.6 Systemanatomi En systemanatomi är en riktad, acyklisk graf som representerar ett systems funktionella kapabiliteter, skapad ur ett användarperspektiv. Den kan användas för att ligga till grund för projekt- och integrationsplanering. Den är inte en exakt, unik och formell beskrivning av systemet [35]. 10

20 3 Metod Här beskrivs de tillvägagångssätt som användes vid utvecklingen av produkten och hur frågeställningarna besvarades. 3.1 Organisation Gruppen tilldelades roller, där varje roll hade ett specifikt ansvarsområde inom gruppen. Vissa av rollerna hade även ansvar för dokument relaterade till sina roller. Dessa dokument lade sedan grunden för arbetssätten gruppen följde Roller Det ansvar varje roll hade beskrivs här. Gruppen bestod av åtta medlemmar och det var en roll per medlem. Teamledare Teamledaren ansvarade för gruppens organisation i stort och såg till att uppsatta riktlinjer och rutiner följdes. Teamledaren var även ansvarig för konflikthantering inom projektgruppen och hade sista ordet vid oenigheter. Teamledaren ansvarade för kontakt med handledaren och andra utomstående. Han ledde också arbetet och hjälpte projektmedlemmarna att vara produktiva. Teamledaren hade också huvudansvaret för projektplanen och att tidsrapporter lämnades in till handledaren i tid. Analysansvarig Den analysansvarige hade som uppgift att föra dialog med kunden och analysera kundens behov. Han hade huvudansvar för kravspecifikationen och att jobba med elicitering för att ta fram krav som relaterade till kundens faktiska behov. 11

21 3.1. Organisation Arkitekt Arkitekten hade ansvar för att planera systemets övergripande struktur och ansvarade för arkitekturdokumentet. Arkitekten gav förslag på de ramverk som gruppen sedan valde. Arkitekten hade även huvudansvar till att ta fram en systemanatomi. Utecklingsledare Utvecklingsledaren planerade och ledde det utvecklingsarbete som gruppen skulle göra. Han ansvarade för att organisera och ta fram planen för det iterativa arbetssätt som projektgruppen följde. Utvecklingsledaren beslutade även om projektgruppens utvecklingsmiljöer. Testledare Testledaren hade ansvar för att organisera och leda testarbetet i projektet. Han skrev en testplan och en testrapport som projektgruppen följde när de utförde tester. Testledaren såg till att projektmedlemmarna följde testplanen och stöttade medlemmarna vid testrapportering. Kvalitetssamordnare Kvalitetessamordnaren ansvarade för det arbete som fokuserade på produktens kvalitet. Han hade uppföljningsansvar och skulle fånga upp den kompetens och de erfarenheter gruppmedlemmarna fick under projektets gång. Kvalitetssamordnaren budgeterade med resten av gruppen den tid och de resurser som skulle spenderas på kvalitetsarbete. Han skrev kvalitetsplannen som användes för att säkerställa att produkten höll den kvalitet kunden sökte. Kvalitetssamordnaren hade också ansvar att se till att projektmedlemmarna faktiskt följde kvalitetsplanen. Dokumentansvarig Den dokumentansvarige ledde dokumentskrivande, skapade mallarna för dokumenten och såg till att projektets dokument blev fördelade, skrivna, granskade och färdiga till inlämningsdatum. Den dokumentansvarige var även ansvarig för att organisera projektgruppens dokument. Konfigurationsansvarig Den konfigurationsansvarige ansvarade för att de arbetsprodukter som gruppen tillhandahöll under projektet versionshanterades och beslutade om vilka arbetspunkter som skulle versionshanteras. Konfigurationsansvarig hade ansvar för att det inte skulle uppstå konflikter mellan versioner och att det alltid fanns en fungerande version av koden tillgänglig. Den konfigurationsansvarige hade också ansvar för att de verktyg som behövdes under projektets gång fanns tillgängliga och var förstådda av gruppen, exempelvis utvecklingsmiljöer och ramverk Dokument För att ge struktur åt arbetet skrevs ett antal dokument i syfte att planera projektet. De roller som hade dokument som var direkt relaterade till deras ansvarsområde hade även huvudsakligt ansvar för skrivandet av dessa dokument. Dessa dokumenten finns i tabell 3.1 Efter färdigställandet av varje dokument granskades det av minst två gruppmedlemmar. Eventuella dokument reviderades efter kommentarer av personen som skrev texten innan den färdiga versionen sammanställdes. 12

22 3.2. Förstudie Tabell 3.1: Dokument Dokument Ansvarig Projektplan Teamledare Kravspecifikation Analysansvarig Kvalitetsplan Kvalitetssamordnare Systemanatomi Arkitekt Arkitekturdokument Arkitekt Testplan Testledare Konfigurationsplan Konfigurationsansvarig 3.2 Förstudie Projektets första fas bestod till stor del av förarbete i syfte att planera och strukturera projektoch rapportarbetet. Arbetsprocesser bestämdes inom projektgruppen, och möten hölls med kunden för att förstå problematiken och diskutera lösningar. Innan utvecklingsarbetet började skrev projektgruppen fyra dokument: en projektplan, en testplan, en kvalitetsplan och en kravspecifikation. I projektplanen detaljerades en plan för hur projektet skulle struktureras och utföras. De viktigaste områden som utarbetades var tid- och resursplan, projektorganisation och riskhantering. I testplanen dokumenterades projektgruppens plan för hur projektets tester skulle utföras och dokumenteras. Kvalitetsplanen redogjorde för hur utvecklingen skulle organiseras för att försäkra en god kvalitet på slutprodukten. Kravspecifikationen framställdes i samarbete med kunden i syfte att specifiera de krav som ställdes på produkten. Kraven uppdaterades utifrån återkoppling från kunden under projektets gång Systemanatomi Projektgruppen tog även fram en systemanatomi innan projektet började. Systemanatomin utvecklades gemensamt i gruppen genom att utgå från kraven som tagits fram i kravspecifikationen. Sedan undersöktes vilken funktionalitet som var nödvändig för dessa krav, och den funktionaliteten undersöktes i sin tur på samma sätt. Genom detta producerade gruppen en systemanatomi. 3.3 Distansläge Den 18 mars beslutade krisledningen på Linköpings universitet att all undervisning skulle ske på distans på grund av den pågående COVID-19 pandemin. Efter beslut den 22 april förlängdes distansundervisning fram till nästkommande hösttermin, och därmed skedde allt arbete under projektet från och med den 18 mars på distans. 3.4 Utvecklingsmetod I detta avsnitt redogörs gruppens arbetssätt inom ramarna för kandidatprojektet Arbetssätt Detta projekt utfördes med ett agilt och iterativt arbetssätt baserat på Scrum och Kanban. Projektet utvecklades iterativt genom att dela upp projektets kalendertid i tidboxar på 3-10 arbetsdagar, så kallade sprintar, under vilka projektgruppen arbetade mot en prototyp av systemet. Varje sprint bestod av tre moment: ett sprint startup-möte, ett sprint retrospectivemöte och utveckling. I början av varje sprint hölls sprint startup-mötet, där projektgruppen 13

23 3.4. Utvecklingsmetod diskuterade och planerade sprintens milstolpar och uppgiftsfördelning. Vid ett sprint startup-möte bestämdes vilka övergripande mål sprinten hade och exakt slutdatum fastställdes. De övergripande målen delades upp i vad som behövde göras och detta översattes sedan till uppgifter som skrevs in i projektets backlog. Som backlog användes ärendehanteringssystemet i GitLab. Varje sprint avslutades med ett sprint retrospective-möte där projektgruppen gick igenom vilka av sprintens milstolpar som uppnåtts, projektets backlog uppdaterades och den gångna sprinten utvärderades. Mellan dessa möten fokuserade projektgruppen på att utföra aktiviteterna i projektets backlog. Projektgruppen använde sig av en backlog som visualiserades på ett Kanban-bräde. Denna backlog uppdaterades på varje sprint startup- och retrospective-möte. Vid behov uppdaterades även backlog utanför mötena, vilken sedan togs upp på nästkommande möte. Vid programmeringstillfällen delades gruppen upp i tre huvudsakliga ansvarsområden. Halva projektgruppen bildade en grupp som ansvarade för frontend, resterande fyra gruppmedlemmar fördelades jämnt på server och databas. Uppdelningen skedde efter medlemmarnas egna preferenser. Denna uppdelning följdes i stort sätt under all utveckling. Under senare delen av projektet skedde det mesta av arbetet antingen på frontend eller i server, vilket betydde en viss omfördelning av uppgifter. Sprintar Planerade sprintar och deras målsättningar beskrivs i tabell 3.2. Vissa sprintar hade fokus på utvecklingen av systemet, andra hade fokus på att skriva alla dokument inklusive denna rapport. Tabell 3.2: Sprintar # Veckor Målsättning 1 6 & 7 Första utkast av projektplan, kravspecifikation, kvalitetsplan och systemanatomi 2 8 & 9 Första version av projektplan, kravspecifikation, kvalitetsplan och systemanatomi 3 10 & 11 Första kodprototyp av programmet 4 14 & 15 Reader-funktionalitet 5 16 Dokumentskrivande 6 17 Approver-funktionalitet 7 18 Admin-funktionalitet 8 19 Dokumentskrivande Parprogrammering Projektgruppen har använt parprogramering i vanlig form före distansläget och efter övergången till distansläget har projektgruppen använt sig av Zoom för att dela sin kod och få hjälp av andra, vilket kan ses som parprogrammering [36]. Projektgruppen har även använt sig av Visual Studio Code och dess utbyggnad Live-Share [37] för att kunna programmera tillsammans för att ytterligare koordinera effektivt programmerande Kommunikation Kommunikationen inom projektgruppen skedde i största utsträckning på tre sätt: regelbundna projektgruppsmöten, chattkanaler på Slack och muntlig kommunikation vid utveckling på delad plats. Under distansläget skedde alla gruppmöten via Zoom, och kundmöten skedde över Microsoft Teams. Även det mesta av arbetet skedde genom videosamtal i Zoom för 14

24 3.4. Utvecklingsmetod att öka sammanhållningen och sammarbetsförmågan. Skärmdelningsfunktionen i Zoom användes flitigt för att kunna dela med sig av arbete och snabbt fråga om hjälp. Projektgruppsmöten Varje vecka hade projektgruppen ett till två möten, varav ett med handledaren närvarande. Syftet med dessa möten var att få en överblick över vilket arbete som hade gjorts, vad som var kvar att göra och att planera kommande arbete. Teamledaren ansvarade för att ta fram en agenda till alla dessa möten. Agendan innehöll alltid statusrapport från samtliga medlemmar av projektgruppen. Dessa möten fungerade vid sprintstart som ett sprint startup-möte och vid sprintslut som ett sprint retrospective-möte. Kundkontakt Projektgruppen upprätthöll kontakt med kunden genom regelbundna möten och via e-post. I projektets tidiga skede användes mötena för att skaffa sig förståelse för kundens behov och därmed arbeta fram en kravspecifikation. Det gjordes även användartester med hjälp av pappersprototyper i syfte att få återkoppling från kunden på det skissade användargränssnittet. Mot slutet av projektet presenterades verkliga kodprototyper vid slutet av varje sprint där kunden fick se hur långt arbetet hade kommit. Övrig kommunikation Projektgruppen använde Zoom dagligen för att hålla möten samt för att sitta tillsammans och utveckla produkten. Linköpings universitet tillhandagav full tillgång till alla Zooms funktioner. Slack användes även av gruppen för att kommunicera när alla inte närvarade på Zoom Testning För att öka kvaliteten på systemet skrevs enhetstester (eng. unit tests) i Python för att testa viktiga databasfunktioner och anrop till servern. Genom integration till GitLab kördes testerna automatiskt vid varje ny commit. Detta gav en indikation på ifall en ny ändring hade förstört tidigare funktionalitet och gjorde att mindre tid behövde läggas på att testa den funktionaliteten Kodgranskning Efter varje utvecklingssprint hade gruppen ett gemensamt kodgranskningsmöte. Under mötet tilldelade kvalitetssamordnaren varje person några filer med kod som de skulle granska. Deltagarna läste koden och skrev kommentarer om de saker de hittade i ett separat dokument. Granskningens syfte var dels att hitta felaktigheter och otydligheter i koden, dels att öka förståelsen bland projektgruppsmedlemmarna för kod som skrivits. Därför uppmuntrades alla att inte bara ta upp saker de trodde var fel, utan också saker de inte förstod eller tyckte borde förtydligas Versionshantering Vid utveckling av produkten användes Git som versionshanteringsverktyg. Konfigurationsansvarig tog fram ett arbetsätt för att använda Git så att det blev en integrerad del i utvecklingsarbetet. Det bestämdes att fokus skulle läggas på branch based workflow (se avsnitt 2.4.3) med master branch reserverad för klara versioner och en branch med namnet dev för övrig utveckling. 15

25 3.5. Metod för att fånga erfarenheter 3.5 Metod för att fånga erfarenheter Efter varje sprint fyllde varje gruppmedlem i en enkät skriven av kvalitetssamordnaren. I enkäten utvärderade gruppmedlemmarna arbetet under den gångna sprinten och beskrev vad de lärt sig. Resultatet av enkäten sammanställdes därefter av kvalitetssamordnaren inför start av nästa sprint. 3.6 Individuella bidrag För att uppnå kravet i kursen TDDD96 krävdes att varje gruppmedlem skrev en egen del av rapporten. Dessa delar skulle behandla ett ämne som kunde relateras till projektarbetet. Varje medlem ansvarade för att själv leta reda på ett lämpligt ämne för att sen sammanställa en egen rapport. De går att läsa i slutet av detta dokument. 16

26 4 Resultat I detta kapitel presenteras resultatet av projektet. 4.1 Systembeskrivning Systemets syfte är att visualisera och hantera användares behörigheter till lokaler inom ett företag. Systemet är uppbyggt genom en webbaplikation som använder sig av ett användargränsnitt, en server och en databas. Webbapplikationen körs på en lokal server för demonstration av systemet, men är konstruerad för att kunna använda sig av en server i molnet. Produkten är konstruerad till att användas i webbläsarna Google Chrome och Firefox. Systemet har getts namnet Visual1ze. 4.2 Systemanatomi Den systemanatomi som togs fram syns i figurerna 4.1, 4.2 och Prototyp De tre figurerna 4.3, 4.4, 4.5 visar tidiga prototyper av hur gränssnittet skulle se ut. Utifrån dessa prototyper implementerades det gränssnitt som beskrivs i avsnitt

27 4.3. Prototyp Figur 4.1: Systemanatomi för en reader i systemet. Figur 4.2: Systemanatomi för en admin i systemet. 18

28 4.3. Prototyp 19

29 4.3. Prototyp Figur 4.3: Prototyp för en readers sida. Figur 4.4: Prototyp för en approvers sida. 20

30 4.3. Prototyp Figur 4.5: Prototyp för en admins sida. 21

31 4.4. Systemroller 4.4 Systemroller Klienten har tre olika standarduppsättningar av komponenter för de tre grupper av användare som existerar i systemet. De tre grupperna är reader, approver och admin Reader All personal på företaget som implementerar detta systemet kommer att ha rollen reader. Användarna som tillhör denna roll har möjlighet att: Se de rum och accessgrupper som de personligen har åtkomst till. Begära åtkomst till ett rum eller en accessgrupp genom en beställning. Se när deras behörigheter till rum och accessgrupper tar slut Approver Approvers är de anställda som kan godkänna eller avslå en användares begäran till accessgrupper eller rum. Användarna som tillhör denna roll har möjlighet att: Ha åtkomst till alla systemfunktioner som en reader har. Ha ett ansvarsområdet som innehåller ett godtyckligt antal rum och accessgrupper. Varje rum och accessgrupp som en approver är ansvarig för har ett prioritetsnummer som kopplar ihop dem. Prioritetsnummeret är ett tal från 1 och uppåt som bestämmer vilken approver som först kommer att få beställningar för just detta rum eller accessgrupp. Om den ansvariga inte avslår eller godkänner beställningen inom en förbestämd tid kommer beställningen att skickas vidare till en ny approver enligt prioritetsnummret. Den approver som har prioritetsnummer 1 kommer först få beställningen därefter den som har 2 följt av den som har 3 och så vidare. Se en användares åtkomster inom sitt ansvarsområde. Ta bort behörigheter till rum och accessgrupper för användare inom sitt ansvarsområde Admin Admins är de användare som har den högsta behörigheten i systemet med full åtkomst till alla systemfunktioner som existerar för produkten. Användarna som tillhör denna roll har möjlighet att: Ha åtkomst till alla systemfunktioner som en approver har. Ansvarsområdet för en admin är alla rum och alla accessgrupper som existerar i systemet. Skapa nya accessgrupper. Lägga till och ta bort konton från systemet. Ändra en användares roll i systemet. Spärra en användares kort. 4.5 Systemstruktur Systemstrukturen är baserad på en tredelad arkitektur med de tre skikten klient, logik och data. Genom gränssnittet på klientsidan kan användare och administratörer skicka förfrågningar till servern som hanterar logiken. Servern hämtar sedan den nödvändiga information från databasen och skickar tillbaka resultatet till klienten [38]. En översikt hur systemet är uppbyggt ses i figur

32 4.5. Systemstruktur Figur 4.6: Exempel på hur tredelad arkitektur fungerar vid inloggning till ett system Klientskikt Klienten är en SPA (kort för Single-page-application) skriven i JavaScript med hjälp biblioteket React och är uppbyggd av React-komponenter. Kartkomponenten är uppbyggd i React med hjälp av biblioteket Konva, som är Javascript-bibliotek för ritning av komplexa figurer [39]. Biblioteket Redux används för att hantera klientens tillstånd. För att vara en SPA uppdaterar klienten sina komponenter dynamiskt genom anrop till servern Gränssnitt I figur 4.7 syns inloggningssidan som är den sida en användare först möts av. En användare loggar in genom att skriva in sin e-postadress och sitt lösenord. Efter att användaren är inloggad navigeras hen automatiskt till sidan för deras roll - reader, approver eller admin. Dessa sidor syns i figur 4.9, 4.11 respektive Gemensamt för alla sidor (utöver inloggningssidan) är navigationsmenyn som syns högst upp på sidan. I den finns olika menyval beroende på ens roll. Rollerna reader och approver har samma menyval. Dessa är START, REQUESTS och ett med användarens namn som också har en ikon brevid sig. Knappen START navigerar tillbaka användaren till startsidan för hens roll och REQUESTS visar alla beställningar användaren har gjort på sidan som syns i figur 4.8. De med rollen Admin har också två till menyval MANAGE AGS och MANAGE ACCOUNTS som leder till hantering av access grupper respektive användare. Knappen längst till höger visar namnet på den person som är inloggad och en meny ikon. När den klickas på dyker det upp alternativ beroende på personens roll. Gemensamt för alla roller är alternativet Sign out för att logga ut ur systemet. För rollen approver finns det här Manage personal access och See pending requests som leder till reader-funktionalitet. De med rollen Admin har utöver detta en Edit map knapp i alternativen och See pending requests och Gemensamt för alla roller är valet För rollerna approver och admin finns här alternativ för att navigera till de andra rollernas sidor med knappen. 23

33 4.5. Systemstruktur Figur 4.7: Webbgränssnittets login-sida. Figur 4.8: Sida med lista över ens egna förfrågningar. 24

34 4.5. Systemstruktur Reader-gränssnitt En användare som endast har rollen reader möts av en stor karta med rum (representerade av färgade rektanglar) markerade i olika färger, se figur 4.9. Grön färg indikerar att användaren har tillgång till rummet, och grå färg indikerar att användaren inte kan ta sig in i det rummet. Notera att de rum som har vit färg inte går att interagera med då interagerbara rutor inte har ritats ovanpå dem. Det går att navigera i kartan genom att dra med musen. Om användaren klickar på ett rum så markeras rummet i blått, och en liten ruta med information om rummet dyker upp. I rutan står rummets namn, ID, och ifall användaren har behörighet till rummet står det även när behörigheten tar slut. Ifall användaren inte har behörighet till rummer kan hen klicka på knappen Request This Room. Då navigeras användaren till sidan som visas i figur Här behöver användaren klicka i att hen godkänner villkoren, och kan även skriva en motivering till varför hen behöver tillgång till rummet. Efter att ha klickat på knappen SEND REQUEST navigeras användaren tillbaka till kartan som syns i figur 4.9 ifall beställningen var giltig. Om beställningen inte var giltig så kommer ett error upp i röd text som förklara problemet. Endast en beställning till varje rum kan göras åt gången, så en ny beställning är endast giltig om en beställning till samma rum gjord av användaren inte redan existerar. För att söka efter en accessgrupp används istället sökrutan med texten Search Access Group. I denna kan en användare välja mellan alla accessgrupper i systemet genom att först filtrera dem på namn och sen klicka på en i en lista som dyker upp under sökrutan. När en accessgrupp valts markeras de tillhörande rummen i ljusblått på kartan. Med en vald accessgrupp går det att trycka på knappen med texten Request Access Group. Då navigeras användaren till en sida som motsvarar den i figur 4.10, men med accessgruppens namn på platsen där rummets stod. Precis som för rum går det endast att beställa access till en accessgrupp om det inte redan existerar en beställning till den accessgruppen gjord av användaren. Figur 4.9: Startsida för en reader. 25

35 4.5. Systemstruktur Figur 4.10: Sida för att begära åtkomst till rum Approver-gränssnitt Ifall användaren har rollen approver hamnar hen istället på sidan som visas i figur 4.11 efter inloggning. Även här syns en karta över lokalen, men färgkodningen visar istället vilket ansvarsområde approver:n har. Ljus grön färg visar alla rum som användaren har ansvar över, antingen genom att hen ansvarar över det rummet, eller genom att hen ansvarar för en accessgrupp som innehåller det rummet. I sökrutan ovanför kartan går det att söka bland de användare som finns i systemet. Om en användare väljs visas hens accesser i kartan i grönt, men endast för de rum som är inom ansvarsområdet för den approver som är inloggad. Med en annan användare vald går det att välja ett av de grönmarkerade rummen och sen välja Revoke access. Då visas sidan i figur Efter att ha godkänt avtalet går det att trycka på den blåa knappen, och då kommer användaren att förlora sin access till det rummet eller den accessgruppen. En approver ser också de beställningar som hen har kvar att godkänna till vänster på startsidan, se figur När användaren håller muspekaren över en beställning i listan visas vilka rum som den gäller i ljusblått i kartan. Ifall användaren klickar på en beställning visas dialogen som syns i figur Här kan beställningen antingen nekas - vilket behåller alla accesser som de är eller godkännas vilket lägger till rummet eller accessgruppen i personens existerande accesser. Alla användare som är approvers har tillgång till den funktionalitet som en reader har. För att komma åt sidan för readers som en approver används menyn högst upp till höger på sidan. Där väljs Manage personal access. Därefter ser sidan ut som den gjorde för en reader i figur 4.9. Det går när som helst att navigera tillbaka till approver-startsidan genom att klicka på START i menyfältet. 26

36 4.5. Systemstruktur Figur 4.11: Startsida för en approver. Figur 4.12: Sida för att som approver frånta en annan användares access. 27

37 4.5. Systemstruktur Figur 4.13: Dialog som visas för en approver ifall hen klickar på en beställning Admin-gränssnitt En admin:s sida är lik den för en approver, men valen i navigationsmenyn högst upp på sidan är utbytta. Knappen MANAGE AGS leder till sidan som visas i figur Denna sida används för att skapa accessgrupper och visar en ny karta, men i denna är rummen från början alltid markerade i grått. När ett rum i kartan markeras visas det i blått. När ett annat rum väljs så behåller det första rummet en färg, fast nu i ljusblått. Genom att välja ett rum i taget går det att markera ett område som ska bilda en ny accessgrupp. De approvers som ska ha ansvar över accessgruppen väljs genom sökrutan med texten Add approvers. När sökrutan markeras visas en lista med alla som har rollen approver eller högre. När personer väljs behålls deras namn i sökrutan och det går sen att fortsätta att lägga till fler personer. När området i lokalen, ansvariga approvers och accessgruppens namn är valt kan användaren klicka på knappen CREATE ACCESS GROUP för att spara accessgruppen permanent i systemet. Denna accessgrupp går det därefter att begära åtkomst till. Om en accessgrupp sparas med samma namn som en existerande accessgrupp så kommer den accessgruppen att skrivas över. Detta möjliggör redigering av redan existerande accessgrupper. Knappen MANAGE ACCOUNTS i navigationsmenyn ger två val: Create account och Manage accounts. Dessa leder till två olika sidor som är till för att skapa, respektive redigera användare i systemet. På sidan för att skapa användare (se figur 4.16) kan en admin fylla i för- och efternamn, e-postadress, lösenord och roll. Rollen väljs som en av de tre befintliga rollerna. Knappen ADD USER lägger till den nya användaren i systemet, och det kommer därefter att gå att logga in som denna person. Sidan för att redigera existerande användare kan ses i figur Här kan en admin välja att radera eller byta roll hos en användare. Användaren väljs först genom sökrutan högst upp på sidan, varefter namn, e-postadress och roll visas i rutan i mitten av skärmen under rubriken User information. För att blockera användarens kort används knappen BLOCK CARD, och för att radera användaren från systemet används knappen REMOVE USER. För att ändra en användares roll används rullgardinsmeny Edit user role. 28

38 4.5. Systemstruktur Figur 4.14: Startsida för en admin. Figur 4.15: Sida för att redigera accessgrupper som admin. 29

39 4.5. Systemstruktur Figur 4.16: Sida för att skapa användare som admin. Figur 4.17: Sida för att redigera användare som admin. 30

40 4.5. Systemstruktur Logikskikt Servern är mellansteget mellan gränssnittet och databasen och är uppbyggd med ramverket Flask. Kommunikation med servern sker genom HTTP requests specifikt GET eller POST till olika URL:er för att hämta eller spara data i databasen. Flask binder funktioner till URL:er som sedan anropas när servern får en request till respektive URL. För att till exempel logga in i systemet behöver användaren skriva in e-post och lösenord i gränssnittet. När användaren sedan klickar på log-in-knappen skickas en POST request som innehåller e-postadressen och lösenordet i ett JSON-objekt till servern via URL localhost:5000/login. Funktionen syns i listing 1. Servern kollar sedan om användaren finns i databasen och loggar antingen in användaren eller skickar ett felmeddelande. Servern innehåller mer än 30 olika URL:er där varje URL är kopplad till en egen funktion. För att kommunicera med servern måste requests skickas på samma dator som kör servern. Servern fungerar då bara lokalt men är skapad i syftet att det, med lite mer arbete, ska gå att hysa servern på molnet. Detta skulle göra det möjligt att skicka requests till servern på distans vilket är ett måste om systemet skall fungera som en webbplats Dataskikt Förnamn Efternamn Mejladress Namn Användar-ID Kort-ID Slutdatum Lösenord 1 ANVÄNDARE M M Slutdatum HAR TILLGÅNG TILL TILLHÖR GÖR 1 U APPROVER M ANSVARIG FÖR Prioritet N N ACCESSGRUPP Namn M GER TILLGÅNG TILL HANTERAS AV U M N N ADMIN ANSVARIG FÖR Kortläsar-ID KORTLÄSARE Prioritet N N N N M ANSLUTER FÖRFRÅGAN N AVSER 1 d RUM M Datum lagd Motivering Benämning Rum-ID Visuell representation Figur 4.18: EER-modell över databasens entiteter. I figur 4.18 visas den EER-modell som skapades för att ta fram systemets databas. I en EERmodell representeras entiteter av rektanglar, associationer mellan entiteter av diamanter, och attributer av ellipser vilka det går streck till från entiteten eller asssociationen de tillhör. Vidare kan även kardinalitet (1, N, M) och begränsningar som tillhörighet (dubbelstreckad linje) illustreras, samt entitetssubtyper och ärvning (U, d) [9]. De huvudsakliga entiteterna är 31

41 4.5. methods=["post"]) def login(): """ Logs in the reader and returns an access token if and password matches in the database. """ # Checks if the request is a json if not request.is_json: return bad_request("missing JSON in request") # Gets the and password from the client = request.json.get(" ") password = request.json.get("password") if not return bad_request("the field can not be empty") if not password: return bad_request("the password field can not be empty") reader = Reader.query.filter_by( = ).first() # If wrong or password if not reader or not reader.check_password(password): return bad_request("wrong or password") approver = Approver.query.filter_by(reader_id=reader.id).first() admin = Admin.query.filter_by(approver_id=reader.id).first() # Gets the users role role = "reader" if approver: role = "approver" if admin: role = "admin" # Create the users access token token = create_access_token(identity= ) json = {"access_token": token, " ": reader. , "name": reader.name, "surname": reader.surname, "role": role} return ok(json) Listing 1: Serverns loginfunktion användarna som också kan vara approvers eller admins accessgrupperna, rummen, kortläsarna och användarnas förfrågningar. Diagrammet visar hur dessa entiteter förhåller sig till varandra. Exempelvis har en användare tillgång till vissa kortläsare, och dessa kortläsare ansluter rummen. På liknande sätt ger en accessgrupp tillgång till en grupp kortläsare, och en användare tillhör en eller flera accessgrupper. Slutligen så gör användarna förfrågningar som antingen hör till ett rum eller en accessgrupp. Varje förfrågan hanteras av en approver 32

42 4.6. Gemensamma erfarenheter som också måste vara ansvarig över det rum eller den accessgrupp som efterfrågas. Ovalerna representerar den data som varje entitet eller relation behöver ha tillgänglig. Exempelvis är namn, e-postadress med mera kopplad till varje användare. Relationerna Ger tillgång till och Tillhör har båda ett slutdatum associerade med sig. Detta för att kunna uppfylla kravet att alla accesser ska ta slut efter en viss period. Slutligen har varje approver en prioritet associerad med sitt ansvarsområde. Detta för att kunna uppfylla kravet att en beställning ska gå vidare till nästa approver ifall en viss tid har passerat. I figur 4.19 syns den databasmodell som skapades utifrån EER-modellen. Relationsmodellen visar de tabeller som databasen innehåller tillsammans med vilken data som sparas i vilken tabell. Både entiteterna och relationerna i EER-modellen blir egna tabeller, medan datan blir de kolumner som hamnar i varje tabell. Rollerna har modellerats så att alla användare finns i tabellen reader oberoende av roll. Ifall de också är approver så finns motsvarade reader ID i tabellen approver. På samma sätt finns ett approver ID i tabellen admin ifall de också har rollen admin. På så sätt kommer alla admins att också vara approvers, och alla approvers att också vara readers. Databasen använder sig av databashanteraren SQLite. För att bygga databasen användes biblioteket Flask-SQLAlchemy. Modeller skapades till ORM-verktyget som matchade den specifikation som tagits fram, och därefter kunde databasen användas från Python. För att dölja lösenorden i databasen användes en hashfunktion vid sparandet av lösenordet. För att se ifall en användare som loggade in angav rätt lösenord jämförs det hashsummerade lösenordet med det som var sparat i databasen. 4.6 Gemensamma erfarenheter Gruppen har lärt sig mycket om hur man jobbar i ett Scrum-team tack vare att varje medlem fått ansvara för en egen specifik roll med ett ansvarsområde. God kommunikation har många gånger visat sig vara mycket viktigt för projektet. Varje individ har tagit eget ansvar för att tillsammans skapa en så bra produkt som möjligt. Gruppen har lärt sig att jobba i LATEX med hjälp av verktyget Overleaf för att tillsammans skapa snygga och strukturerade dokument. Hur man kodgranskar och ger kommentarer till andra medlemmar i gruppen för att förbättra produktens kod har varit något som gruppen har lärt sig tillsammans genom arbetet. Gruppen har läst på och tillsammans lärt sig hur man skapar en webbapplikation med tredelad arkitektur under kursens gång. Det gruppen tar med sig till framtida projekt baserat på erfarenheter från kandidatarbetet är bland annat att anstränga oss för att hantera uppstartsflaskhalsar så fort som möjligt. De första veckorna hade gruppen svårt att komma upp i rådande timmål i väntan på ny information från kundmöten och från föreläsningar/seminarier i kursen. Detta bidrog senare till att den andra halvan av våren blev väldigt intensiv gällande just timmål varje vecka. Vidare tar gruppen med sig vikten av att planera mer kortsiktiga aktiviteter och mål, och att se över och uppdatera dessa under arbetets gång. Gruppen blev bättre på hantering av aktiviteter och mål efter ungefär halva projektets gång, men för framtida projekt hade det varit önskvärt att ha sådana bra rutiner på plats redan från början. Slutligen tar gruppen med sig mycket positiva erfarenheter av att arbeta med mjukvaruutveckling och dokumentskrivande på distans, till sådan grad att det ofta skulle vara att föredra i framtida projekt. Gruppen vet bland annat hur verktyg som Zoom, Overleaf och Google Drive tillåter kommunikation och samarbete i realtid, och har också kommit att inse att arbete hemifrån tar bort problemet med och tiden det tar att hitta salar och att förflytta sig mellan dessa. 33

43 4.6. Gemensamma erfarenheter Figur 4.19: Relationsmodell över databasens tabeller. 34

44 4.6. Gemensamma erfarenheter Erfarenhetsuppfångst Efter varje del av projektet har en erfarenhetsuppfångstenkät delats ut och sammanställts. Terminens första period sammanställs som en sprint, därefter gjordes enkäter och sammanfattningar efter varje sprint. Sprint 1 Gruppen tyckte arbetet gick bra och tog bra ansvar för sina ansvarsområden. Gruppen tycker den kan bli bättre på att fråga varandra om hjälp vid oklarheter. Gruppen fick mycket ny kunskap om hur man jobbar i ett större projekt och de verktyg som kan underlätta detta. Arbetsbelastningen inför första seminariet blev ojämnt fördelad inom gruppen. Sprint 2 I sprint 2 uteblev erfarenhetsuppfångstenkäten och därmed även dess sammanfattning. Sprint 3 Vad gruppen tyckte om Sprint 3 som helhet varierade mycket, vissa tyckte det gick sämre och andre bättre. Gruppen började programmera under denna sprint och fokus på dokument försvann lite vilket upplevdes som stressigt för vissa. Gruppen delade upp sig i 3 delgrupper med fokus på varsitt utvecklingsområde och det upplevdes som positivt. Den första kodgranskningen hölls i gruppen och den upplevdes som positiv. Det var svårt för gruppen att nå upp till de timmål som sattes inför sprinten. Flera upplevde att arbetet sista veckan blev stressigt och lite oorganiserat. Gruppen lärde sig mycket nytt under sprinten. Sprint 4 Gruppen tyckte arbetet under sprinten gick väldigt bra. Sprint 4 var en ren utvecklingssprint och det tyckte gruppen var kul. Det upplevdes också som att målen för sprinten var tydliga. Det upplevdes som att alla tog ansvar för arbetet och hjälpte varandra vi behov. Denna sprint var också första perioden i distansläge, vilket krävde en omställning för gruppen. Men gruppen upplevde att omställningen gick bra. Gruppen provade på att parprogrammera på distans över Zoom och tyckte det funkade bra. Gruppen kände att den behövde bli bättre på att inte pusha saker som inte funkar till en branch i Git där andra jobbade. Sprint 5 I sprint 5 gick gruppen tillbaka till dokumentfokus. Det upplevde många som mindre kul och det blev svårt med fokus. Arbetet som var planerat blev gjort för sprinten och de mål som satts upp upplevdes som en bidragande faktor till framgången. Gruppen tog med sig att de ska försöka variera dokumentskrivande och programmering i framtida sprintar. Sprint 6 Sprint 6 innebar återigen en programmeringssprint. Sprinten upplevdes ha gått bra och många kände att kommunikationen och samarbetet inom gruppen gick väldigt bra och var en bidragande faktor till framgången. Gruppen tyckte också att det funkade bra att be om och att få hjälp med saker inom gruppen, vilket ökade kunskapsspridningen inom gruppen. Något som gick mindre bra var gruppens försök att balansera dokumentskriving och programmering under sprinten då dokumentskrivandet ofta uteblev. 35

45 4.7. Kodgranskning Sprint 7 Sprint 7 var en kort sprint på 3 dagar men trots detta gick arbetet för gruppen bra och målet för sprinten nåddes. Gruppen tyckte sprinten var lite kort och kände att det finns flera fördelar med längre sprintar, till exempel att kunskapsspridning blir enklare inom gruppen och att buggar hinner hittas. 4.7 Kodgranskning Antalet kommentarer som skrevs vid varje kodgranskningssmöte redovisas i tabell 4.1. En kommentar syftar här till något som behövde åtgärdas eller något som förklarades under kodgranskningen. Det syns att antalet kommentarer ökade allteftersom volymen kod växte under projektets gång. Mötena hjälpte att strukturera upp koden och hjälpte gruppen att följa de standarder som gruppen kommit överens om att koden skulle följa, eftersom största delen av kommentarerna från kodgranskningen rörde kodens struktur och läsbarhet. Efter dessa kommentarer skrevs koden om och/eller förklarades med fler eller bättre kodkommentarer. Få kommentarer från kodgranskningen rörde logikfel. Flera medlemmar upplevde att de fick bättre förståelse av systemet efter kodgranskningarna. Medlemmarna ansåg även att det var mycket dödtid under de första kodgranskningarna. Därför ändrades upplägget allteftersom för att korta ner mötestiden (t.ex. genom att inte gå igenom kommentarer kring kodkonventioner), vilket bidrog till att göra kodgranskningarna effektivare och mer lärorika. Tabell 4.1: Kommentarer per kodsprint Sprint Antal kommentarer Processförbättring Under projektets gång gång var kodgranskning en process som gruppen med hjälp av ett trevligt gäng av studenter från kursen TDDE46 jobbade på att förbättra. Det som gruppen mätte under varje kodgranskning var tiden gruppen spenderade på kodgranskning, antalet kommenterar och antalet olika typer av kommentarer. Processen arbetades mycket på under projektets gång och flera olika metoder testades för att se vad som fungerade bäst för gruppen. Första kodgranskningen saknade struktur i hur och vad som skulle kommenteras och mycket tid spenderades på att ställa frågor. Detta förbättrade vi i framtida kodgransknignar då kvalitetssamordnaren skapade ett kalkylark till vardera gruppmedlem med instruktioner om var och hur kommentarer skulle ske. Detta gjorde mötet därpå mycket mer strukturerat. Sedan märkte gruppen att även om kommentarerna dokumenterades blev det ingen bra uppföljning för att lösa sagda problem. Detta löste gruppen genom att tilldela alla kommenterar till gruppmedlemmar så varje medlem visste exakt vad de behövde fixa. Med dessa ändringar hade gruppen en väl fungerande process men det betydde inte att den ej kunde förbättras. Gruppen fick tips från studenterna från kursen TDDE46 att använda sig av linters. En linter fungerar genom att kolla igenom kod och systematiskt hitta fel. För vårat projekt fungerade dock linters inte så bra som önskat eftersom vi använda specifika ramverk och bibliotek. Verktyget hjälpte dock med att hitta fel i indentering vilket gjorde att vi inte 36

46 4.8. Individuella bidrag behövde ta upp dessa problem på kodgranskningen. Slutligen blev tiden den största mätbara skillnaden efter processförbättringen. De första kodgranskningarna tog cirka två timmar medan den sista tog endast en timma. Att mätta antalet kommentarer och typen av kommenterar gav ingen användbar data i vårt fall. Detta var på grund av att olika kommentarer hade olika stor vikt bakom sig. Till exempel var en kommentar under det första möttet ändra alla till och en kommentar under sista kodgranskningen fel standard med dubbelt citattecken i stylingen på rad 37 i UserSearch.js. Så även om det var mycket mindre att fixa vid sista kodgranskningen fick vi ändå mer kommentarer. 4.8 Individuella bidrag Nedan följer en kort introduktion av de individuella bidragen Matheus Bernat CI i ett kandidatprojekt I kapitel A redogörs för hur Continuous Integration:s principer påverkar ett mjukvaruprojekt. Det ges dessutom praktiska exempel på hur automatiserade testningar av Reactkomponenter kan göras i verktyget GitLab CI Johan Ehinger Kryptering inom relationsdatabas I kapitel B finns det individuella bidraget. Rapportens syfte är att undersöka kryptering inom relationsdatabaser. Fokus ligger på att väga olika metoder mot varandra och svara på vilken metod som hade varit mest relevant för att kryptera relationsdatabasen i vårt projekt Jesper Jensen Utveckling av mjukvara på distans I kapitel C analyseras distansarbete i relation till gruppens projekt. Rapportens syfte är att undersöka skillnaderna i att utveckla mjukvara i en projektgrupp på distans jämfört med på plats. Bidraget tar upp för- och nackdelar med att jobba på distans och verktyg samt platformar som kan underlätta arbetet Ludvig Joborn Kritiska krav: En fallstudie I kapitel D används en modell för att kritiskt analysera kravhantering och kravspecifiktionen i projektet som utförts. Fokus ligger på att undersöka aspekter av social hållbarhet som inte fått plats vid framställandet av projektets system Gustav Malmström Agil systemutveckling med Scrum i ett mindre projekt I kapitel E redogörs hur det har fungerat att arbeta agilt efter metoden Scrum i ett mjukvaruprojekt med relativt få medlemmar. Det undersöks också hur olika längd på sprintar kan påverkar produktiviteten hos en projektgrupp Anders Ryefalk React med och utan Redux I kapitel F finns det individuella bidraget. Rapportens syfte är att undersöka vilka för- och nackdelar som finns med att använda tillståndshanteraren Redux tillsammans med React. 37

47 4.8. Individuella bidrag Mårten Walter Affärsmodeller för mjukvarusystem I kapitel G redogörs för olika affärsmodeller för mjukvarusystem som skulle kunna vara aktuella för det system som utvecklats av gruppen Johannes Wilson Mjukvarusystem efter dataskyddsförordningen I kapitel H diskuteras dataskyddsförordningen och hur den kan tolkas i sammanhanget av systemet som utvecklats i projektet. Potentiella problem med användningen av personuppgifter tas upp, och ett sätt att använda systemet i enlighet med dataskyddsförordningen föreslås. 38

48 5 Diskussion I detta kapitel diskuteras rapportens resultat, projektets resultat, de metoder som använts och projektet i sin helhet. 5.1 Resultat I detta avsnitt diskuteras resultaten som uppnåtts under projektet. Fokus för avsnittet är hur utvecklingsabrbetet har gått utifrån gruppens tekniska förutsättningar. Detta ingår i frågeställning 1 om hur värde kan skapas för kunden Val av ramverk och språk Applikationen blev en webbapplikation eftersom det fanns flera fördelar med det. Då ingen installation krävs kan applikationen köras på nästan varje dator och många är redan bekanta och trygga med att använda en webbläsare. Det enda som krävs är tillgång till internet (eller ett internt nätverk) för att komma åt applikationens webbserver. Projektet delades upp i tre områden och ett enda språk passade inte in för alla områden. Projektgruppen var därmed tvungen att välja ett ramverk eller språk för varje område som passade bäst. Gränssnitt För att enkelt kunna utveckla ett användargränssnitt till webbapplikationen valde gruppen att använda ramverket React. Det är ett av de mest använda ramverken inom webbutveckling och har stöd för många bibliotek som kan användas för att effektivisera hemsidans implementation. Språket som används inom React är Javascript då React är ett Javascriptbiblotek. Det finns stöd i React för ett ramverk vid namn Konva, som är ett bibliotek som bygger på HTML5 Canvas Javascript och som tillåter skapandet av mer dynamiska gränssnitt. Konva användes vid utvecklingen av kartkomponenten i projektet eftersom att Konva förenklade processen att rita upp figurer. 39

49 5.1. Resultat Ytterligare ett ramverk som användes var Redux. För en mer detaljerad diskussion om användandet av Redux, se kapitel F. Webb-server För serverdelen av applikationen valdes ramverket Flask. Anledning till att Flask valdes var att: det var enkelt att koppla ihop det med React. Både React och Flask är populära ramverk, så det fanns många instruktioner på hur dessa två ramverk skall kopplas ihop. Det kombinerat med gruppens ovana att skriva webbapplikationer gjorde att Flask valdes. Några i gruppen hade också arbetat med Flask tidigare vilket också bidrog till valet. Databas Systemet använde en relationsdatabas skriven i SQL. Andledningen till att detta användes var för att relationsdatabaser är snabbare och enklare att använda för data som behöver kopplas samman. Hela systemet baserades på att användare kopplas till kortläsare och accessgrupper. Rum är med kortläsare, som i sin tur är kopplade till andra rum och sedan har kortläsare relationer med accessgrupper och så vidare. Att använda något annat än en relationsdatabas hade inte varit lämpligt här och hade bara gjort databasen svårare att hantera. Databasen SQLite valdes för att det gör det enkelt att använda sig av programmet lokalt. En SQLite-databas kräver väldigt lite förberedelser för att använda sig av och presterar väldigt bra relativt hur enkel databasen är. Med en SQLite-databas gick det snabbt att få igång en fungerande prototyp Alternativa implementationssätt I detta avsnitt diskuteras alternativa implementationssätt och ramverk som applikationen hade kunnat utvecklas på. Andra ramverk Som alternativ till ramverket Konva hade vi kunnat rita våra figurer i Canvas [40]. I projektet hade hela kartkomponenten kunnat implementeras i Canvas för mer anpassningsbarhet i de figurer som ritas. Projektgruppen valde att använda Konva eftersom de figurer som skulle ritas upp var enkla rektanglar med god händelsehantering (musklick, etc), vilket var något som Konva redan implementerat på ett bra sätt. Som alternativ till React togs ett annat ramverk upp som förslag: Elm. Elm är ett funktionellt språk med fokus på att kunna rita upp grafiska gränssnitt för användare. Detta språk garanterar att runtime exceptions buggar som är mycket svåra att hitta inte kan förekomma. Nackdelen med Elm var att Elm är ett mindre etablerat ramverk än React, och på grund av detta var det svårare att hitta bra dokumentation och implementationsexempel till Elm [41]. För serversidan av projektet föreslogs ramverket Django som alternativ till Flask. Django är ett ramverk till programspråket Python. Några fördelar med Django är att ramverket är byggt för att kunna utveckla skalbara, säkra applikationer. Det genereras automatiskt administrations-gränssnitt utifrån data-modeller som anges i Python-koden och Django genererar generellt mindre kod. Flask föredrogs här på grund av att det var fler gruppmedlemmar som hade arbetat med det tidigare [42]. Ett alternativ till Material UI som togs upp var Bootstrap [43]. Detta alternativ valdes bort tidigt då projektgruppen blev tipsad om att hellre använda det förstnämnda biblioteket. 40

50 5.2. Metod Användargränssnitt Användargränssnittetet i systemet hade kunnat se ut på många sätt. Anledningen till att gränssnittet landade på den designen som den gjorde var kombinationen av kraven på systemet och kundfeedback. Vissa funktioner var kritiska för applikationen och systemet designades runt dessa. Ett exempel på detta är kartan som är i huvudfokus för användargränssnitetet. Att designa systemet runt kartan var en bra utgångspunkt för gruppen. Databasstruktur Accesserna i systemet sparades som accesser till kortläsare. Eftersom kortläsarna inte syntes direkt i gränssnittet hade ett alternativ kunnat vara att spara behörigheterna till rum direkt. Vi valde att inkludera kortläsare i databasstrukturen för att bättre avspegla hur ett verkligt behörighetssystem skulle fungera. En kortläsare behöver kunna söka upp ifall ett kort har access på ett enkelt sätt vilket går tack vare databasstrukturen. Ifall endast rummen sparas kan systemet inte enkelt säga om en viss kortläsare accepterar ett kort, den informationen måste istället beräknas genom att undersöka ifall kortet ger access till rummen på båda sidor av dörren. Det hade kunnat vara värt den extra beräkningen, eftersom ett system som hanterar behörigheter till rum hade modellerat det system som användaren ser närmare Vad återstår för att kunden skall få ut fullt värde av produkten? Resultatet av projektet är en fungerande hemsida som uppfyller de krav som gruppen och kunden kom överens om i kravspecifikationen. Det arbete som återstår för en komplett produkt (utöver att lägga till extra funktionalitet) är att integrera produkten med ett dörrsystem och koppla produktens databas mot den mjukvara som styr dörrarna alternativt integrera produkten med den nuvarande databasen för dörrar. För att ytterligare öka värdet för kund hade fler prioritet 2- och 3-kraven kunnat implementeras. Systemet som det är nu fungerar som överenskommet mellan kund och grupp, men extra funktionalitet inom systemet är alltid åtråvärt. De krav som inte implementerades på grund av deras låga prioritet är ändå funktionalitet som kunden skulle vilja ha tillgång till Viktigaste lärdomar inför framtiden Mycket positivt har kommit från projektet och det finns mycket som gruppen kommer att ta med sig i framtiden. Att jobba iterativt med utvecklingen i projektet har upplevts som positivt och har gett bra erfarenhet att ta med inför framtiden. Utvärderingen av arbetet under dess gång är något som gruppen upplevt fördelar med och kommer att ta med till framtida projekt, med till exempel en erfarenhetsuppfångst-enkät och utvärdering mellan sprintar. Det är viktigt att dela upp och tydligt definiera uppgifter. Att skapa processer är viktigt för att underlätta arbetet i projektet, men gruppen ska vara öppen för att förändra processer efter utvärderingar. Något som projektgruppen lärt sig extra mycket om är hur projektarbete kan utföras på distans. Genom effektivt användande av videosamtal, versionshantering och ett fåtal kommunikationskanaler så anser samtliga projektgruppsmedlemmar att arbetet har fungerat bättre på distans än det gjorde under icke-distansläge. Zoom har under distansläget varit väldigt användbart som en gemensam arbetsplats. Seminarier, workshops och möten gick utmärkt att hållas över Zoom. 5.2 Metod I detta avsnitt kommer rapportens metod att diskuteras. 41

51 5.2. Metod Utvecklingsmetod I detta avsnitt diskuteras val och genomförande av utvecklingsmetoder och processer. Agilt arbetssätt Utvecklingsarbetet skedde i sprintar som planerades efter de milstolpar och deadlines som projektet hade. Detta satte begränsningar på vad som kunde sättas som mål vid varje sprint, och påverkade också valet av längden för varje sprint. Enligt Scrum bör varje sprint vara lika lång för att det ska gå att planera på ett konsekvent sätt. Det är normalt mängden arbete som anpassas till att bäst passa den etablerade sprintlängden. I det här projektet behövde både sprintars längd och mängden arbete ändras vid varje ny sprint, vilket gjorde att planeringen inte kunde vara lika precis. Detta kan ha varit orsaken till att alla mål som sattes upp inför sprinten inte alltid uppnåddes fullt ut. Versionshantering Flera av frustrationsmomenten under projektet hade att göra med versionshanteringen. Vid motstridiga ändringar behöver en användare genomföra en merge för att slå ihop ändringarna. Detta är oundvikligt eftersom att versionshanteringsprogrammet inte själv kan avgöra hur olika ändringar av samma kod borde hanteras. Frustration uppstår dock eftersom andras ändringar sätter stopp för att ens egna ändringar ska kunna delas eftersom man först måste genomföra en merge. Beroende på storleken på ändringarna kan även en merge i sig kräva en del tid, vilket distraherar från utvecklingsarbetet. För att minimera de negativa effekterna från motstridiga ändringar prövades några olika strategier. Under den första utvecklingssprinten användes git branches för att separera arbetet så att varje del i programmet kunde utvecklas på en egen branch. Detta minskade antalet merges som behövde utföras, men resulterade i att kod blev svårare att dela då varje branch blev mer och mer olik de andra. Under resterande sprintar arbetade istället majoriteten av gruppen på samma branch, vilket gjorde att kod blev lättare att dela, men vilket resulterade i att många fler merge-operationer behövde genomföras Projektorganisation Under projektets gång har hanteringen av rollerna skötts väl av projektgruppsmedlemmarna. Även om exempelvis konfigurationsansvarig var ytterst ansvarig att leda hanteringen av versionshantering i projektet tog även de övriga medlemmarna ansvar för att underlätta en god versionshantering. Ingen projektgruppmedlem hade attityden av inte mitt ansvar om det t.ex. gick dåligt. Tack vare detta gick uppdelningen av ansvar med hjälp av rollerna väl Systemanatomi Systemanatomin som skapades i projektets tidiga fas lade grunden till strukturen hos systemet. Genom att tidigt skapa en helhetsbild av hur vi tänker oss att systemet ska struktureras så kunde vi använda vår delade förståelse över hur systemets olika delar ska struktureras för att förenkla integration mellan moduler. Mycket av de positiva effekterna av systemanatomin var omedvetna och därmed svåra att lägga märke till. Systemanatomin i sig användes sparsamt under projektet, men skapandet av denna hade subtila positiva effekter Kundkontakt Som tidigare nämnts gagnade kundkontakten projektet på flera sätt. Det bidrog till bättre förståelsen för kundens faktiska behov, underlättade återkoppling på de genomförda prototyperna, etc. Kundkontakten bedöms ha varit bra under hela projektets gång trots övergången till distansläge i mitten av projektet. 42

52 5.3. Arbetet i ett vidare sammanhang Kodgranskning Majoriteten av kommentarerna rörde kodstruktur och kodstandard. Kodens läsbarhet och struktur blev markant förbättrad i många fall, men större logikfel hittades det få av. Detta kan bero på att den applikation som skapades ofta var enkel att felsöka och om något gick snett märktes detta ofta tydligt när applikationen kompilerades. Därför var det rimligt att logikfel som gjordes åtgärdades utanför kodgranskningen. Däremot var samtliga gruppmedlemmar nöjda att ha gjort kodgranskningen då de kände att de hade fått bättre förståelse för systemet tack vare kodgranskningen. Projektgruppen tyckte däremot att kodgranskningen skulle ta så lite tid som möjligt då det ofta uppkom dödtid under kodgranskningen Källkritik Många av referenserna är till hemsidor för olika mjukvaruprogram som har använts under projektets gång. Dessa sidor är skrivna för att ge tillgång till mjukvaran och bistå med dokumentation för hur den används. Denna källa kan ses som tillförlitlig då syftet med sidan är att göra mjukvaran så användbar som möjligt. I vissa fall kan också sidan ha till syfte att sälja en produkt, och i sådana fall kan viss information om produkten eller företaget vara något vinklad. Källor som är publicerade tidsskrifter anses vara de mest trovärdiga. Dessa har höga krav på att få publiceras och är skrivna på ett vetenskapligt sätt. Här har källor hämtats från bland annat IEEE och ACM. En annan typ av källa som har använts i rapporten är texter som är publicerade på nätet som artiklar eller bloggar. Dessa källor är mer trovärdiga ifall de kan kopplas till den person som har skrivit dem eftersom det då går att se vems åsikter som står i artikeln. Det är en fördel ifall det står något om personen på sidan så att det går att veta med vilka grunder författaren baserade sina påståenden på. Då går det att göra en bedömning för varje källa ifall personen har tillräcklig erfarenhet för det som de skriver i artikeln. För den här typen av källa har främst artiklar med en person angiven använts. För information om dataskyddsförordningen har främst Datainspektionens hemsida använts. Datainspektionen är en statlig myndighet och är därför en mycket trovärdig källa. Ett fåtal fakta har hämtats från Wikipedia. Wikipedia anses ofta vara en opålitlig källa eftersom den är redigerbar av alla. För viss information är den dock praktisk eftersom informationen hålls uppdaterad, och i data-relaterade sammanhang är sidorna ofta väl använda, och därför också väl redigerade och uppdaterade. 5.3 Arbetet i ett vidare sammanhang För att detta arbete ska kunna anses som fullständigt är det av stort värde att reflektera över systemets påverkan ur ett större perspektiv. För att göra detta kommer aspekter om hållbar utveckling att diskuteras nedan Säkerhetsaspekter Genom bättre hantering av lokaler kan obehöriga uteslutas från områden de inte ska ha tillgång till. Säkerhetsområden kan skyddas från människor som intresserar sig för sabotage, vilket ökar säkerheten och kan öka tryggheten hos de som använder systemet. Det finns dock en säkerhetsrisk med detta system. Systemets beteende med kortläsare är helt odefinierat då 43

53 5.3. Arbetet i ett vidare sammanhang det inte finns strömtillgång. Om strömtillförseln till lokalerna slås ut finns det en risk att kortläsarna kommer att sluta fungera, och alla som befinner sig i lokalerna blir inlåsta. Det finns även en risk att detta system går att hacka sig in i, och därav kan systemet bli en svag punkt för kunden då en hackare skulle kunna frånta allas lokalbehörigheter eller ge sig själv eller någon annan tillgång till säkerhetsbelagda områden Miljöaspekter Systemet som implementerats förhoppas kunna positivt påverka arbetsmiljön inom kundens företag vad gäller fysisk miljö och relationer inom företaget. Genom bättre kontroll och hantering över vem som rör sig var kan ett flertal åtgärder vidtas. Till exempel kan städning fokuseras på de områden där det oftast rör sig folk, och ström kan stängas av om ingen befinner sig i ett område Etiska aspekter Systemet är baserat på idén om att det är etiskt försvarbart att kunden har rätt att utestänga de som den anser är obehöriga inom de områden som styrs av detta system. Detta ter sig rimligt, då kunden har ett flertal lokaler som är sekretessbelagda. Systemet lagrar även data om personer, vilket måste ske i enlighet med dataskyddsförordningen (på engelska General Data Protection Regulation eller GDPR). För mer om GDPR, se kapitel H Ekonomiska aspekter Jämfört med kundens gamla, befintliga, system, där ansvaret för att hantera lokalbehörigheter om än på uppmaning av vanliga anställda landat på receptionister och administratörer, innebär det nya systemet ett större ansvar för vanliga anställda. Avsikten är att ge de anställda större möjlighet att hantera sina lokalbehörigheter proaktivt och att ge dem en bättre och mer intuitiv möjlighet att överblicka sina behörigheter. En risk skulle dock kunna vara att anställda lägger betydligt mer tid på hantering av lokalbehörigheter än tidigare, och därmed mindre tid på sina primära, mer värdeskapande arbetsuppgifter - vilket kostar pengar för arbetsgivaren. Beroende på kunskapen och disciplinen hos de anställda kan det eventuellt vara önskvärt att ha reader-funktionaliteten mycket väl avskalad, sådan att antalet användarfall för en reader begränsas och därmed också tiden som potentiellt kan spenderas i systemet med att utföra dessa användarfall. En annan ekonomisk aspekt är den att projektet genomförts av studenter som alltså inte är färdigutbildade och heller inte nödvändigtvis har någon tidigare erfarenhet av mjukvaruutveckling gentemot en extern kund eller i den omfattning som rått. De investeringar som kunden behövt göra har varit i form av tid och engagemang, inte (direkt) finansiella. Förhoppningsvis har kundens önskemål tillgodosetts och detta antagligen betydligt billigare än om kundens egna anställda eller konsulter fått samma uppgift. Vidare skulle en bra ansedd prestation kunna innebära att kunden och dylika verksamheter ser värde i att förlita sig på datavetenskapstudenters färdigheter och kanske erbjuda dem sommar- och extrajobb. Verksamheterna skulle då kunna få tillgång till relativt billig men tillräckligt bra arbetskraft, medan studenterna kan tjäna pengar och få erfarenhet med relevans för sin utbildning. 44

54 6 Slutsatser I detta kapitel presenteras rapportens slutsatser. 6.1 Slutsatser kring frågeställningar I detta avsnitt dras slutsatser på frågorna i avsnitt 1.3 från resultatet och diskussionen i rapporten Fråga 1 1. Hur kan systemet implementeras så att värde skapas för kunden? För att skapa värde för kund är det viktigt att lyssna på kundens önskemål och gemensamt ta fram krav för produkten. Det är viktigt att ha regelbundna möten där prototyper kan presenteras och att det finns utrymme att revidera kravspecifikationen. Det är av yttersta vikt att reflektera över vem som produkten är ämnad till och att sedan ha detta i åtanke vid utformandet av systemet. Genom att sedan visa upp prototyper för kunden så kan antaganden om hur systemet ska utformas. Ju färre antaganden och ju mer kunden bekräftar om vad som gör systemet värdefullt, desto mer värde skapas åt kunden Fråga 2 2. Vilka erfarenheter kan dokumenteras från Visuell hantering av behörigheter till lokaler som kan vara intressanta för framtida projekt? En viktig erfarenhet som dokumenterats är att iterativ utvärdering av ett projekts arbete är av yttersta vikt. I början av projektet var projektgruppen missnöjd med användandet av Kanbanbrädet, men efter att detta uppdagats i sprintutvärderingarna så gjorde projektgruppen god användning av Kanban-brädet till en prioritet. Samtliga projektgruppsmedlemmar var nöjda med denna utveckling. Liknande trender skedde inom flera områden som kommunikation, kodgranskningar och sprintplanering. Dessa trender ledde till att projektarbetet blev progressivt effektivare. 45

55 6.2. Uppfyllande av syfte Fråga 3 3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? Inom ramarna för detta projekt fick projektgruppen positiv effekt av skapandet av systemanatomin. Det fanns inget behov att följa upp och revidera systemanatomin, men skapandet gav samtliga gruppmedlemmar en helhetsbild över hur systemet skulle implementeras. Det var även ett bra sätt att starta diskussioner om systemets arkitektur Fråga 4 4. Vilka för- och nackdelar finns det med att använda kodgranskning i ett litet mjukvaruutvecklingsprojekt? Kodgranskning kan fungera som ett sätt att fördjupa förståelsen av systemet för de som utför kodgranskningen och bidrog till ökad kunskapsdelning inom projektgruppen. Det kan även användas effektivt för att se till att kodens struktur och läsbarhet förbättras. Kodgranskning kan däremot vara ineffektiv och innebära onödig dödtid, så steg måste tas för att tiden till kodgranskningen spenderas effektivt. 6.2 Uppfyllande av syfte Projektgruppen och kunden anser att ett system har skapats med värde för kunden. Projektgruppsmedlemmarna var även nöjda med den kunskap de samlat på under projektets gång. 6.3 Viktigaste lärdomar Den viktigaste lärdom som kan dras utifrån projektet som utfördes är att mjukvaruutveckling på distans kan fungera utmärkt om korrekta steg tas för att försäkra en god distansarbetsmiljö. Versionshantering och videosamtal har starkt bidragit till detta projekts framgång under distansläget. Rapporten belyser även vikten av god kommunikation med kunden då samarbete med denne har resulterat i att önskemål för systemet klargjordes under systemets utveckling. 46

56 A Matheus Bernat CI i ett kandidatprojekt A.1 Inledning Dagens mjukvarudrivna värld ställer allt högre krav på mjukvarukvalitet och produktion. Samtidigt som utveckling ska ske fortlöpande förväntas robusta slutprodukter levereras och förbättras i takt med samhällets snabbändrade behov. Detta är en tämligen svår tvist att lösa, nämligen att uppnå bra kvalitet på kort tid. Ytterligare en faktor som gör mjukvaruutveckling svårare är de utvecklade systemens ökande komplexitet. Denna ökade komplexitet leder till att ett system inte längre kan utvecklas som en enda enhet utan måste separeras och utvecklas i olika moduler. Uppdelningen i olika moduler leder i sin tur till att enheterna måste integreras för att i slutändan bilda den önskade produkten. Det är enkelt att inse att integrationen av alla dessa enheter kan bli kostsam tidsmässigt och ekonomiskt om den inte sköts på ett lämpligt sätt. Detta är alltså också ett problem som måste lösas. Inom ramen för mjukvaruutveckling finns det en rad olika arbetssätt vars syfte är att lösa den ovannämnda problematiken kring mjukvaruutveckling. Ett av dessa arbetssätt eller snarare filosofier är Continuous Integration (CI). En betydande andel av mjukvaruindustrierna idag omsätter denna princip i praktik. Med detta i åtanke ter det sig naturligt att behandla ett sådant viktigt ämne för att på så sätt bli mer medveten om vad termen innebär. A.1.1 Syfte Avsikten med detta arbete är i stort att ge läsaren en insikt i vad CI innebär i ett kandidatprojekt bestående av cirka åtta studenter och hur sådana grupper kan utnyttja det. Särskilt kommer fokuset att läggas på presentation av vad CI är och innebär, och på hur grupperna med hjälp av ett CI-verktyg kan göra testning av komponenter i frontend mer effektiv. A.1.2 Frågeställningar För att uppnå syftet på ett tydligt sätt kommer detta bidrag att lägga fokus på och besvara följande frågor. 47

57 A.2. Bakgrund A På vilka sätt påverkar CI:s principer arbetet och därmed slutprodukten i ett kandidatprojekt i programvaruutveckling? 2. Hur lämpar sig GitLab CI för automatiserad testning av React-komponenter? Avgränsningar Denna rapport kommer endast att behandla de teman som anses relevanta för att besvara frågeställningarna. Följaktligen tas inte upp frågor som hör till CI men som inte bidrar till att åstadkomma rapportens syfte. Exempel på sådana ämnen som inte ska behandlas men som ändå är relevanta inom CI är: hur tester skapas på ett bra och omfattande sätt så att de bidrar till utvecklingen; jämförelse av existerande CI-verktyg. Slutligen är är det värt att poängtera att CI-verktyget i fråga, GitLab CI, har talrika tillgängliga funktioner, men endast de funktioner som rör denna rapports mål kommer att tas upp. A.1.4 Ordlista Build. Detta är resultatet av att bygga programkod. Att bygga programkod innebär att kompilera och testa koden med hjälp av färdiga tester. CI. Continuous integration (CI) är en praxis som består av olika praktiker vars mål är att effektivisera mjukvaruutveckling. Stage. I GitLab CI delar man upp testprocessen i olika faser som tillsammans bygger en pipeline. Exempelvis kan den första fasen bestå av importering av nödvändiga bibliotek, medan den andra fasen kan bestå av körning av olika testfiler. Varje sådan fas som alltså består av en klump av kommandon och testfiler kallas för en stage. A.2 Bakgrund Inom ramarna för ett kandidatprojekt i programvaruutveckling förväntas grupperna jobba på ett iterativt sätt. Målet bakom det iterativa arbetssättet är att, vid slutet av varje iteration, ha färdiga och fungerande prototyper som kan visas för kunden så att tidig återkoppling möjliggörs. Detta är exakt det sätt som vår grupp har jobbat på. I slutet av varje iteration hölls det möten mellan gruppen och gruppens kund Ericsson AB där prototyper presenterades och utveckling följdes upp. Tvisten som nämndes i introduktionen, nämligen att utveckla bra produkter på kort tid, uppstår även i detta kandidatprojekt. Med tanke på att CI är en känd lösning till denna problematik ska jag utforska CI utifrån ett sammanhang av ett kandidatprojekt. Gällande hur CI åstadkoms rent praktiskt finns det ett stort antal tillgängliga verktyg som stödjer det vilket kan medföra förvirring vid valet. Vid valet av ett verktyg bör det tas hänsyn till ett antal faktorer. Viktiga faktorer är hur mycket tid och pengar som finns tillgängliga att lägga på att sätta upp CI-miljöer. Inom detta kandidatprojekts sammanhang utgår jag från att tid och särskilt pengar inte finns i mängder och därför utesluts de kända verktygen som Jenkins [44], Travis CI [45] och CircleCI [46]. Med tanke på detta har jag också valt att utforska och diskutera ett CI-verktyg som finns helt tillgänglig för studenterna i kandidatprojektet: GitLab CI [47]. Slutligen har jag valt att analysera användningen av GitLab CI inom en webbapplikation då utveckling av sådana applikationer var den vanligaste typen av projekt som kandidatgrupperna hade tillgängliga att välja bland. Det särskilda fokuset på automatiserad testning av React-komponenter beror på att utveckling av front-end i min kandidatgrupp ligger under mitt ansvar. 48

58 A.3. Metod A.3 Metod Under detta avsnitt beskrivs de tillvägagångssätt som använts vid skrivandet av detta bidrag. A.3.1 Litteraturstudie Till denna studie införskaffades information via vetenskapliga artiklar och elektroniska källor. Artiklar hittades främst via sökverktyget Google Scholar. Sökfrasen som ledde till de önskade artiklarna var: continuous integration. Urvalet av träffarna gjordes baserat på vilka som författaren ansåg ha ett bra djup på innehåll. De elektroniska källorna som denna rapport använde sig av var dokumentation från ramverken GitLab CI, React och Jest. A.3.2 Undersökning Slutligen, i syfte att koppla det behandlade ämnet, CI, till kandidatprojektet i fråga har det valts att göra en mindre undersökning i form av en enkät. Denna enkät skapades med hjälp av Google Forms och skickades ut till studenter i kursen TDDD96 och blev besvarad av 11 personer. Frågorna som ställdes på enkäten står under denna paragraf. Frågetexten är skrivna i fetstil medan svarsalternativen står under respektive fråga inom parenteserna. 1. Hur bedömer du att mjukvaruutvecklingen gick i din grupp på en skala 1 till 5 (där 1 är mycket dåligt och 5 är mycket bra)? (Betyg 1 till 5) 2. Välj de 3 största anledningarna till varför utvecklingen gick som det gick. (Frekvent integration av moduler/bra kommunikation mellan olika teams/primärt fokus på att fixa arbetsstoppande fel/regelbundna gruppmöten/regelbundna kundmöten/iterativt arbetssätt/annat) 3. Har du jobbat på andra mjukvaruprojekt där arbetssättet skilde sig från nuvarande kandidatprojektets arbetssätt? (Ja/Nej) 4. Om du svarade ja på den tidigare frågan: hur bra eller dåligt gick utvecklingen jämfört med nuvarande kandidatprojektet? (Fri text) A.4 Teori Denna del av studien presenterar de undersökta områden genom att referera till existerande vetenskapliga artiklar och andra källor. Till att börja med presenteras vad begreppet CI är och innebär med särskild fokus på praktiker som anses viktiga inom CI. Vidare behandlas på vilket sätt denna praxis kan omsättas i praktik gällande utveckling av React-komponenter i verktyget GitLab CI. A.4.1 Continuous integration: definition och vanliga praktiker. Continuous integration (CI) är en utvecklingspraxis inom mjukvaruutveckling där utvecklare integrerar sina ändringar med resten av systemet minst en gång per dag. Vid integration byggs systemet om och alla tester måste godkännas för att ändringarna ska tas in som en ny del av det uppdaterade systemet. De stora målen som denna praxis vill åstadkomma är: att öka förutsägbarhet av koden genom att fixa mindre integrationsfel oftare; att förbättra kommunikation mellan utvecklare av olika enheter; att minska tids- och ekonomiförluster 49

59 A.4. Teori som ofta sker vid sällsynta integrationer [48]. Ursprungligen var CI en av de tolv förslagna praktikerna inom i utvecklingsfilosofin extreme programming [49] som togs fram av Kent Beck, men den kan även tillämpas för sig. Idén bakom CI är enkel men kräver i sin tur en del praktiker som måste följas. Till att börja med är den mest kända praktiken i CI att integrera sin kod dagligen. Varje genomförd ändring ska läggas upp och integreras till resten av systemet. Detta ersätter den kända vanan att hålla sig till sin egen lokala branch och utveckla funktioner under en lång period för att sedan integrera till resten av systemet. Fördelen med att integrera dagligen är att integrationsfel blir betydligt enklare att felsöka vid små ändringar [50]. Dessutom bidrar de mer frekventa integrationerna till kommunikationen mellan olika utvecklingsteam då de tvingas att ta kontakt ifall något fel mellan deras enheter uppstår [51]. Ytterligare en praktik som kännetecknar CI är att bygga om kodbasen vid varje ny ändring. Ett vanligt sätt att åstadkomma detta är med hjälp av en CI-server. Denna server har till uppdrag att lyssna efter ändringar i kodbasen. När en ändring väl upptäcks det vill säga när en utvecklare lägger upp sin kod exekverar servern en rad kommandon för att initiera ett build som kompilerar och testar kodbasen. Därefter jämförs testernas resultat med förväntat resultat. När resultaten inte är konsekventa med varandra skickas det ett ärende till utvecklaren som får i uppdrag att korrigera detta integrationsfel [51]. Slutligen ska korrigering av trasiga builds prioriteras framför all annan utveckling. Om ett misslyckat build inte korrigeras genast stoppas alla andra utvecklare från att testa sina ändringar gentemot resten av systemet. Det blir svårare att ta reda på orsaken till felet vilket leder till frustration. Alltså är det ytterst viktigt att prioritera fix av trasiga builds högt då CI förutsätter att man alltid utvecklar på en stabil kodbas [51]. A.4.2 React React är ett JavaScript-bibliotek som används för att bygga webbgränssnitt. En stark sida hos React är dess modularitet: gränssnittens komponenter kan skapas separat och hantera sina egna tillstånd. Detta medför en förenkling av byggandet av mer komplexa gränssnitt samt återanvändandet av färdigskrivna komponenter [21]. A.4.3 Jest Jest är en så kallat test runner vilket innebär att det exekverar tester och sammanfattar deras resultat. Dessutom är Jest ett assertion-bibliotek, vilket innebär att det innehåller kontrollfunktioner som kan anropas för att säkerställa att testernas resultat blir som förväntat [52]. A.4.4 jsdom Detta är en förenklad webbläsare med begränsade funktionalitet vars mål är att effektivisera testning av front-end. Begränsningarna hos jsdom är: det är inte kapabelt att framställa visuellt innehåll; det är inte kapabelt att beräkna var komponenter läggs ut som ett resultat av CSS; etc. Det används av Jest för att komma åt och ändra elementen i ett HTML-dokument [53]. A.4.5 Testning av React-komponenter Testning av React-komponenter kan delas upp i två kategorier: rendering av komponenter i en förenklad testmiljö följd av kontroller som kontrollerar om det erhållna resultatet var som förväntat och körning av hela applikationen i en realistisk webbläsare. Denna del av avsnittet ska fokusera på och presentera hur det förstnämnda sättet att testa komponenter 50

60 A.4. Teori kan realiseras [54]. Det förstnämnda sättet att testa React-komponenter har tre beståndsdelar: en test runner (Jest), ett assertion-bibliotek (också Jest) och en förenklad webbläsare (jsdom) [54]. Koden som ses i listing 2 visar ett enkelt test av en React-komponent som användes i grupp 1:s projekt. import React from 'react'; import { unmountcomponentatnode, render } from 'react-dom'; import { act } from 'react-dom/test-utils'; import StartButton from '../components/header/startbutton'; let container = null; // For each test, we want to render our React tree to a DOM element. beforeeach(() => { container = document.createelement("div"); document.body.appendchild(container); }); // When the test ends, clean up and unmount the tree from the document. aftereach(() => { unmountcomponentatnode(container); container.remove(); container = null; }); // Function containing tests. First render then assert. it("tests if Start-button renders and acts as it should", () => { act(() => { render(<startbutton />, container); }); expect(container.textcontent).tobe("start"); }); act(() => { container.dispatchevent(new MouseEvent("click")); }); expect(container.textcontent(tobe("proceed to Start page"))); Listing 2: React-text-exempel A.4.6 GitLab CI Som tidigare nämnts finns det ett stort antal tillgängliga verktyg vars mål är att underlätta implementation av CI i mjukvaruprojekt. Ett av dessa verktyg, som finns helt tillgängligt för studenter i detta kandidatprojekt, är GitLab CI. Detta är ett verktyg som finns inbyggt i GitLab och vars mål är att stödja mjukvaruutveckling enligt praxisen CI [47]. Funktionerna som erbjuds av GitLab CI är många: stöd för automatiserade tester, verifiering av kodkvalitet, prestandatester, etc. Som tidigare nämnts i A.1.3 ska det endast tas upp den delen av GitLab CI som anses intressant för att åstadkomma rapportens syfte med att gå igenom automatiserad testning. Allt som krävs för att sätta igång en CI-miljö, där automatiserade testningar körs, är att deklarera en.yaml-fil där pipelinens stages med tillhörande testfiler (så kallade scripts) finns beskrivna. Vid varje ny push till projektet sätts pipelinen 51

61 A.5. Resultat igång och testerna körs [47]. För en pipeline bestående av två stages ser.yaml-filen ut som koden i listing 3. stages: - build - test build: stage: build script: - npm run build test_react: stage: test script: - echo "This scipt runs all React-tests in tests " - npm test Listing 3: pipeline exempel Denna fil skapar en pipeline som den i figur A.1. De omslutande lådorna representerar stages och de inneslutna lådorna är filerna som körs under sin tillhörande stage. Figur A.1: Pipeline skapad av ovanstående.yaml-fil. A.5 Resultat I detta avsnitten kommer resultaten av bidraget att presenteras. A.5.1 Litteraturstudie Resultatet av litteraturstudien är den information som hittas i avsnitt A.4. A.5.2 Undersökning Enkäten som beskrivs i A.3 besvarades av 11 studenter. I detta avsnitt ska en sammanfattning av de insamlade svaren att presenteras. 1. Hur bedömer du att mjukvaruutvecklingen gick i din grupp på en skala 1 till 5 (där 1 är mycket dåligt och 5 är mycket bra)? På denna fråga svarade 54.5% av enkätdeltagarna med att mjukvaruutvecklingen i sina 52

62 A.6. Diskussion respektive grupper gick mycket bra (betyg 5), medan 36.4% svarade med att det gick bra (betyg 4) och 9.1% svarade med att det gick varken bra eller dåligt (betyg 3). 2. Välj de 3 största anledningarna till varför utvecklingen gick som det gick. Den största anledningen till varför mjukvaruutvecklingen gick bra enligt 81.8% av enkätdeltagarna var bra kommunikation mellan olika teams följd av frekvent integration av moduler med 72.7%. Därefter fick regelbundna gruppmöten och iterativt arbetssätt röster från 54.5% av deltagarna medan primärt fokus på att hantera arbetsstoppande fel fick 27%. Övriga svar var god användning av kanban-bräda och motiverade utvecklare med både 9.1%. Se en grafisk representation av det beskriva resultatet i figur A.2. Figur A.2: Svar på en av enkätens frågor. 3. Har du jobbat på andra mjukvaruprojekt där arbetssättet skilde sig från nuvarande kandidatprojektets arbetssätt? På denna fråga svarade 90% av deltagarna med ett ja medan resterande deltagare svarade med ett nej. 4. Om du svarade ja på den tidigare frågan: hur bra eller dåligt gick utvecklingen jämfört med nuvarande kandidatprojektet? Enkätdeltagarna svarade med att nuvarande projektet gick bättre jämfört med tidigare projekt på grund av förbättring i någon eller några av följande faktorer: integration av moduler, kommunikation, iterativ utveckling, tester och versionshantering. Till att börja med, den faktor som nämndes mest i svaren på fråga 4 var en frekvent integration av moduler. Enligt enkätdeltagarna ledde detta till bättre kommunikation mellan projektmedlemmar och mer förståelse av kod skrivna av övriga projektmedlemmar. Det menas även att det blev enklare att se helheten av projektet. Därefter, ytterligare en faktor som angavs ofta i svaren var att det iterativa arbetssättet som förespråkas i kursen förbättrade utvecklingen. Dessutom beskrevs kunnighet i att versionshantera som en framgångsfaktor. Sist av allt nämndes det att commits till samma branch utan granskning ledde till att många fel behövde lösas direkt. A.6 Diskussion Under detta avsnitt ska först rapportens erhållna resultat diskuteras utgående från de ställda frågeställningarna i avsnitt A.1.2. Därefter diskuteras rapportens metod som står i avsnitt A.3. 53

63 A.6. Diskussion A.6.1 Resultat De två följande avsnitten innehåller en diskussion och analys av resultaten för varje frågeställning. På vilka sätt påverkar CI:s principer arbetet och därmed slutprodukten i ett kandidatprojekt i programvaruutveckling? För att diskutera denna frågeställning ska detta avsnitt utnyttja den genomförda undersökningen. De insamlade svaren på utvärderingsfrågorna ska analyseras och kopplas till rapportens teori i avsnitt A.4. Till att börja med är det förväntat att den stora majoriteten av enkätdeltagarnas svar på fråga 1 ( Hur bedömer du att mjukvaruutvecklingen gick i din grupp på en skala 1 till 5? ) var övervägande positivt: medelbetyget på denna fråga var 4.41 av 5, där 5 tydde på att arbetet gick mycket bra. Detta resultatet var något som förväntades av skribenten med vetskap om att cirka hälften av enkätdeltagarna tillhörde kandidatgrupp 1 och där anses arbetet ha varit framgångsrikt. Därefter är det värt att lägga märka till de intressanta resultaten i fråga 2 och fråga 4. I fråga 2 var den näst mest röstade anledningen, med röster från 72.7% av deltagarna, frekvent integration av modulerna, som är precis den första CI-principen som tas upp i avsnitt A.4. Ännu mer intressant är att se i undersökningen att det mest röstade alternativet i fråga 2 var bra kommunikation mellan olika teams med röster från 81.8% av studenterna, och samtidigt att i fråga 4 se att det finns en tydlig koppling mellan bra kommunikation och frekvent integration. Ett betydande antal deltagare svarade med att den frekventa integrationen av modulerna förbättrade kommunikationen mellan olika arbetsgrupper och den allmänna förståelsen för projektet i sin helhet blev större. Denna företeelse - att frekventa integrationer har som konsekvens förbättrad kommunikation - är också något som togs upp i teorin och som förutsägs av CI då utvecklarna tvingas att ta kontakt med varandra vid integrationsfel. Sist av allt tar vi upp ett avvikande svar som gavs till fråga 4 som lydde att commits till samma branch utan utomstående granskning ledde till många fel som behövde fixas direkt. Det framgick inte i svaret om studenten menade att det var positivt att fixa felen direkt eller om det var något som ställde till problem. Om svaret analyseras ur ett perspektiv som har CI:s principer i åtanke, går det att dra slutsatsen om att det är en bra sak att felen som uppstår måste fixas genomgående. I teori-avsnittet tas det upp att korrigering av trasiga builds måste prioriteras framför alla annan utveckling. Slutligen, med tanke på att fokus på att fixa arbetsstoppande fel var en anledning som valdes av 27.3% av enkätdeltagarna, kan det dras slutsatsen om att utveckla på en och samma branch är ett framgångsskäl enligt studenterna vilket stämmer överens med den ovannämnda CI-principen. På detta vis kan mjukvaran korrigeras vid varje ändring vilket leder till att utvecklingen alltid sker på en fungerande bas. Hur lämpar sig GitLab CI för automatiserad testning av React-komponenter? Detta avsnitt baserars på resultaten som presenteras i teori-avsnittet, speciellt i genomgången av hur automatiserade testningar läggs i GitLab CI. Det är påtagligen enkelt att använda GitLab CI vid automatiserade testningar av Reactkomponenter. Allt som krävs är att skapa React-tester som det står i punkten A.4.5 och att lägga in dem i en mapp inuti den utvecklade React-appen. Därefter räcker det att deklarera en.yaml-fil där det deklareras i vilken ordning moduler importeras och byggs och tester körs. I och med att scriptet npm test hittar alla tester som finns deklarerade inuti testmap- 54

64 A.7. Slutsatser pen körs alla tester av React-komponenter tillsammans, och därefter ges en sammanfattning i GitLab:s terminal om hur testerna gick. A.6.2 Metod Den genomförda litteraturstudien som anges i A.3 angående CI hade gott om publicerade vetenskapliga artiklar tillgängliga. Samtidigt behandlas det nyare ämnen som testning av React-komponenter via verktyget Gitlab CI, vilka är mer tekniska och vars officiella dokumentation finns tillgänglig elektroniskt. Således anses en litteraturstudie av både vetenskapliga artiklar och elektroniska källor passa väl i rapportens sammanhang. När det kommer till den genomförda undersökningen, i och med att rapporten ämnar till att analysera påverkan av CI:s principer i ett kandidatprojekt i programvaruutveckling bedöms det vara rimligt att fråga studenterna hur mjukvaruutvecklingen gick i deras respektive grupper. Det bedöms för övrigt att antal deltagare i enkäten (11, cirka 10% av studenterna i årets upplaga av TDDD96) inte var tillräckligt stort för att hitta ett generellt mönster för alla grupper i kandidatprojektet. Det hade alltså varit bättre om svar från fler studenter hade samlats in. Å andra sidan kan enkätresultatet tolkas som att det faktiskt finns en trend eftersom de insamlade svaren var märkbart eniga. A.7 Slutsatser I detta kapitel presenteras rapportens slutsatser. A.7.1 Sammanfattande svar på frågeställningar Under detta avsnitt presenteras sammanfattande svar till rapportens frågeställningar i A.1.2. Vad är CI:s påverkan på arbetet och därmed slutprodukten i ett kandidatprojekt i programvaruutveckling? Påverkan av CI:s principer på arbetet är markant, vilket undersökningen antydde på. För det första förbättras kommunikationen mellan olika arbetsgrupper. För det andra förbättras den allmänna förståelsen för slutprodukten som en helhet och för varandras utvecklade moduler. För det tredje blir korrigering av fel betydligt enklare i och med att det sker längs hela utvecklingsprocessen och inte endast i större intervall. Felen är på så sätt mer lokaliserade och lätta att hitta och korrigera. Alla ovanstående faktorer är saker som gjorde sig uppenbara under utvecklingsprocessen i gruppen som jag var en del av och därmed ska jag hålla CI:s principer i åtanke i framtida mjukvaruutvecklingsprojekt oavsett omfattning av projekt. Hur lämpar sig GitLab CI för automatiserad testning av React-komponenter? Som tidigare nämnts i avsnitt A.6 är GitLab CI ett mycket bra sätt att hantera automatisering av tester på, särskilt när det kommer till testning av React-applikationer. Allt som krävs är att deklarera en.yaml-fil och lägga in de tester som ska köras. Därefter körs dessa tester automatiskt varje gång som ett nytt push görs till GitLab. Avslutningsvis vill jag nämna att utvecklingen av grupp 1:s webbsida med React tog lång tid med tanke på att endast ett fåtal gruppmedlemmar hade tidigare erfarenhet av att jobba med webbutveckling i React. Dessutom ställdes det höga krav på webbsidans utseende och användarvänlighet. Detta ledde till att mycket tid las på att utveckla webbsidan vilket lämnade lite tid till att utveckla de faktiska React-testerna. Således skrevs endast ett fåtal tester. Den 55

65 A.7. Slutsatser undersökta frågan, däremot, är besvarad med tanke på att det faktiskt var mycket enkelt att automatisera testerna efter att de skapats. A.7.2 Framåtblick Detta bidrag kom fram till att tillämpandet av CI:s principer är i många fall av stor hjälp till kandidatgrupper och bör därför utnyttjas för ett framgångsrikt genomförande av ett kandidatprojekt inom programvaruutveckling. Å andra sidan, när det kommer till att automatisera React-tester, är min upplevelse att det inte fanns tillräckligt med tid för att skapa behjälpliga tester av React-komponenter då det i vårt fall var enklare att endast testa komponenterna manuellt. Framtida relaterade frågeställningar som skulle kunna tas upp som en följd av detta bidrag vore till exempel en mer detaljerad genomgång om hur tester av frontend kan skapas och om det ens är aktuellt i projekt av omfattning liknande ett kandidatprojekt i programvaruutveckling vid Linköpings universitet. 56

66 B Johan Ehinger Kryptering av relationsdatabaser B.1 Inledning Dagens läge med allt fler tjänster via molnet och den fortsatta användningen och utökningen av servrar kombinerat med allt snabbare datorer och internet gör att allt mer information sparas på en annan plats än den lokala datorn. Vad händer med denna information? Finns den tillgänglig för alla eller hur skyddas den? Det blir allt mer viktigt att skydda känslig information från att vara läsbar för tredje part [55]. I den här delen kommer användningen av kryptering av relationsdatabaser för att skydda känslig data att utforska. Kryptering är ingen ny idé. Redan under romartiden användes kryptering av brev och texter för att endast vara läsbar för rätt person. Och denna tanke att bara en viss person eller grupp skall ha tillgång till informationen har inte dött ut. I dagens läge har vi gått bort från brev och in i tekniken, men samma problem kvarstår. Med EU:s förordningar om GDPR (General Data Protecton Regulation) och företag som vill skydda sina affärshemliheter och kunders information har frågan blivit viktigare än någonsin [56]. B.1.1 Syfte Syftet med denna del i kandidatrapporten är att lyfta en egen frågeställning kring något som rör projektet i helhet. Denna del kommer behandla kryptering av data sparad i relationsdatabaser. B.1.2 Frågeställning 1. Vilka metoder finns det för kryptering av relationsdatabaser? 2. Vilka är för- och nackdelarna med respektive metod? 3. Vilken metod hade passat bäst vid en eventuell vidareutvekling av projektet? 57

67 B.2. Bakgrund Frågeställning 1 Frågan om vilka metoder det finns för kryptering av relationsdatabaser syftar till att svara på vilka som är de mest relevanta metoderna inom ramarna av projektet. Relevanta metoder syftar på kryptering i samband med SQL då detta används i projektet. Det finns många olika metoder att lyfta fram inom kryptering och SQL och därför kommer en hel del sållas bort direkt och bara de mest erkänt relevanta metoderna lyftas som svar på frågan. Se Avgränsningar B.1.3 för resonemangen kring detta. Frågeställning 2 Att jämföra de olika metoderna och väga för- och nackdelar mot varandra kommer ge en bra överblick över vilka metoder som potentiellt skulle kunna användas i projektet framöver. Frågeställning 3 Det system som gruppen utvecklar använder en relationsdatabas skriven i SQL. Vilken metod för att kryptera sparad i denna databas hade varit bäst passad för vårt projekt? B.1.3 Avgränsningar Denna del kommer ej att behandla alternativen kring kommunikation mellan databas och användaren. Det går även att kryptera även denna del av ett system, men detta alternativ kommer ej behandlas i frågeställningen och resultatet. I punkt B.1.2 ställs en bred fråga om vilka alternativ som finns bland kryptering av relationsdatabaser. För att rapporten ska hålla sig till ämnet och inte bli för lång kommer en hel del metoder att sållas bort direkt, innan de nämns i denna rapport. De metoder och alternativ som kommer att tas upp är endast de som på ytan kan kopplas till projektet på ett logiskt sätt. De metoder som kommer att vara med i rapporten kommer således att vara de redan erkänt bra sätten att kryptera på medan experimentella metoder eller dåligt testade metoder tillhör de som sållas bort. B.1.4 Ordlista 1. SQL - Structured Query Language är ett programmeringsspråk för hantering av relationsdatabaser. 2. GDPR - General Data Protection Regulation eller på svenska dataskyddsförordningen. 3. DDM - Dynamic Data Maskning, eller på svenska dynamisk datamaskning. 4. AE - Always Encrypted, eller på svenska alltid krypterad. 5. TDE - Transparent Data Encryption, eller på svenska transparent datakryptering. 6. CLE - Cell Level Encryption. 7. Databasfält - Ett databasfält är den grundläggande enheten för informationsinmatning i en databas. B.2 Bakgrund Ett stort företag med flera tusen anställda har ofta stora lokaler för alla anställda. Allt från lager och fabriksgolv till huvudkontor har lokaldata sparad någonstans. Är det som för kunden till vårt projekt så finns denna lokaldata sparad på en relationsdatabas. Alla elektriska system uppkopplade till internet har en risk att bli utsatta för dataintrångsattacker från obehöriga parter. Det finns många anledningar till att en tredje part skulle vilja ha tillgång till 58

68 B.3. Teori Figur B.1: DDM exempel. ett företags lokaler och planlösning. Kanske håller de på att orkrestrera en terrorattack, vill själva lösa planlösningen effektivare eller kanske bara ha tillgång till lokalerna för att kunna stjäla något inuti. Det kan också vara så att det är Sveriges försvarsmakt som hela tiden vill hindra att känslig information om hur lokalerna i deras anläggningar ser ut inte kommer i främmande händer. Det finns alltså många anledningar till att ett företag eller organisation anser att informationen om dess lokaler borde hanteras som känslig information. Datakryptering blir också allt viktigare i samhället eftersom teknologi blir enklare och enklare för alla att använda samtidigt som allt mer information blir sparad elektroniskt. EU har också tagit beslut om förordningar kring GDPR (General Data Protection Regulation) och företag arbetar aktivt mot detta. I projektet använder gruppen SQL för att hantera relationsdatabasen för systemet. Denna databas har tagit hänsyn till säkerhet och bevarande av personlig data. Systemet kommer att innehålla personuppgifter som namn, e-post och lösenord men också känslig lokaldata. Det ligger i kundens intresse att skydda denna data och som det ser ut nu skyddas den bakom hashade lösenord med lösenordsskyddade delar i systemet. B.3 Teori I denna del behandlas de relevanta metoderna för kryptering av relationsdatabaser. B.3.1 Dynamic Data Masking (DDM) Dynamic Data Masking eller på svenska dynamisk datamaskering handlar om att maskera data för användare som inte är behöriga. Målet är att förhindra åtkomsten för obehöriga till den känsliga informationen genom att låta användaren själv ange exakt hur mycket av informationen som ska avslöjas. Detta ger minimal påverkan på programnivå och är en principbaserad säkerhetsfunktion som fungerar genom att gömma känslig information i resultatet från frågor till databasfältet. Detta innebär egentligen att databasen blir oförändrad men information kan gömmas för obehöriga ändå [57]. Ett exempel på när DDM kan användas är vid supportlinjer hos företag. Många företag och organisationer identifierar sina kunder med hjälp av till exempel personnummer. Det är helt 59

69 B.3. Teori onödigt för personalen att se hela kundens personnummer och det är då DDM kommer in och byter ut viss information mot XXXX se figur B.1. Detta förhindrar att känslig information enkelt kan avläsas av personal eftersom viss information är utbytt mot X, samtidigt som personalen kan göra de sökningar inom systemet som de måste för att identifiera kunden [58]. Det finns fyra funktioner definierade för kolumner i relationsdatabaser, dessa fyra funktioner skyddar data på lite olika sätt och nedan följer förklaringar på hur de gör det [59]. B Default() Den första funktionen som existerar kallas för default. Om utvecklaren inte är intresserad av att skapa ett eget mönster för att gömma data kan hen genom att kalla på default få en hög säkerhet utan att behöva lägga mycket tid på det. Default påverkar 4 stycken datatyper i SQL-tabellen. Vid en String tar den och skyddar informationen genom att byta ut tecken mot XXXX (vid färre tecken än 4 blir det mindre X). Numeriska värden blir utbytta mot 0 så det inte går att läsa ut den riktiga informationen. När default stöter på ett datumvärde eller tidsvärde byter den ut detta mot eller 00:00: Och vid binära värden används ASCII värdet 0 (NULL-värde). 2. () -funktionen är lite lättare, den kan användas när endast mejladressen för en användare skall döljas för obehöriga. Den fungerar så att den visar första tecknet och "@"i mejladressen. Sedan byter ut allt annat mot X och lägger till ".com"efter. Till exempel axxx@xxxx.com 3. Random() Random tar vilket värde som helst och inom ett spann och byter ut dessa mot slumpmässigt värde. Exempel: WITH (FUNCTION = random([start range], [end range]) ) 4. Partial() Partial fungerar lite som random men här kan utvecklaren välja exakt vad som skall bytas ut och till vad. Partial kommer att visa första och sista tecknet och byta ut allt emellan mot det som utvecklaren specificerar [58]. Always Encrypted (AE) Always Encrypted (AE), eller på svenska alltid krypterad, fungerar som det skulle kunna förväntas utifrån namnet. Informationen som skickas från användaren till databasen blir krypterad med en nyckel för att förhindra att obehöriga kan läsa av datan i databasen. Detta är speciellt användbart i system där användare sparar undan viktig information som till exempel bankkortsnummer, personnummer, adresser och så vidare, samtidigt som människor skall jobba med och underhålla denna information och då kunna detta utan att kunna läsa informationen. Att spara undan informationen som krypterad gör det möjligt för team att arbeta i databasen utan att kunna se vad som är sparat [60]. AE löser också problemet med vilande data. Vid eventuell stöld av de fysiska datan går inte denna läsa då informationen blev krypterad redan på klientisdan. B.3.3 Transparent Data Encryption (TDE) Transparent Data Encryption (TDE) krypterar de fysiska filerna i databasen. Vid avsaknaden av originalkrypteringscertifieringen och masternyckeln kan inte informationen läsas om filerna blir stulna eller kopierade in i en annan server. 60

70 B.3. Teori Metoden går ut på att kryptera informationen när den skrivs in i databasen. När denna sedan blir till exempel säkerhetskopierad är fortfarande informationen krypterad och detta ökar då säkerheten eftersom en enkel överföring av data inte räcker för att läsa den [61]. TDE fokuserar mest på att lösa problemet med data at rest [62], alltså information sparad någonstans, till exempel i ett fysiskt varuhus, hårdiskar, kalkylark, databaser etcetera. Metoden krypterar datan som sparas undan och för att läsa den igen måste rätt nyckel användas [63]. TDE använder sig av AES algoritmen (Advanced Encryption Standard) för att kryptera databasen. Detta gör att utvecklaren inte behöver ändra på mycket i systemet för att implementera TDE. Metoden krypterar löpande informationen som skickas från klient till servern och det är på detta sätt som datan skyddas från att läsas av obehöriga. Det som skilljer TDE mot AE är hur nycklarna hanteras, TDE kan ses lite som ett hotell. En kund alltså en person som använder systemet får en egen nyckel till sitt rum. Hen kan då när som helst låsa upp eller låsa sitt rum alltså kryptera eller avkryptera sin egna data. Men personalenen på hotellet har också en master nyckel som går till alla dörrar ifall de skulle behöva låsa upp något. Alltså kan personalen eller i detta fall utvecklarna också avkryptera eller kryptera informationen [64]. B.3.4 Cell Level Encryption (CLE) CLE har som fokus att ha en serie av inbyggda nyckelhierarkier. För att implementera CLEhierarkin i systemet måste en omstrukturering göras av hela systemets olika delar. Detta är inte det enda som måste ändras i uppbyggnaden av systemet; hur data sparas måste också ses över på grund av att all data måste sparas som varbinary [65] och sedan göras om till orginaldatan igen när denna läses [63]. Det finns lite olika sätt att välja kryptering på inom CLE [66], och det är viktigt att välja rätt metod för rätt projekt. Det är också viktigt att förstå sig på de olika säkerhetsnivåerna. Att prioritera säkerheten tillräckligt högt är viktigt inom alla system. Nedan följer de olika alternativen för kryptering i CLE: 1. Passphrase Detta är det minst säkra alternativet. Passphrase är ett lösenord som skulle kunna innehålla mellanslag. Metoden kräver att du använder samma lösenord som nyckel när du krypterar och avkrypterar datan. Utvecklare bör också kryptera själva passphrase:n, annars är denna information tillgänglig i systemets metadata. 2. Asymmetric key Denna metod är förhållandevis säker då den använder en nyckel för att kryptera informationen och en annan nyckel för att avkryptera datan. Problemet med metoden är dess prestanda, stor mängd data blir svårt att kryptera då det tar lång tid. Det tar lång tid eftersom en funktion först skall användas med en nyckel för själva krypteringen, sedan ska en annan funktion använda en annan nyckel för att avkryptera datan. 3. Symmetric key Detta fungerar som Asymmetric key, men med en skillnad: Symetric key använder samma nyckel när den krypterar och avkrypterar. Generellt ger den god prestanda i de flesta applikationer. Den största skillnaden mellan Symmetric key och passphrase är att när passphrase används genererar denna en symmetric key utifrån den passphrase:n som väljs, men i symmetric key väljs denna själv direkt. 4. Certificate Ger god prestanda och säkerhet i de flesta system. Certificate kan kopplas till en enskild 61

71 B.4. Metod användare om man så önskar. Funktionen krypterar med certifikatets publika nyckel och sedan måste informationen avkrypteras med hjälp av certifikatets privat nyckel. Detta kan göra att metoden inte lämpar sig för stora databaser. B.4 Metod Metoden som kommer att användas i denna rapport är att undersöka litteratur, därifrån lista de olika för- och nackdelarna med de olika metoderna för kryptering och sedan väga dessa emot varandra. Tiden för eftersökningar är högst begränsad och den sökmotor som används är Google och specifikt Google Scholar för att få fram relevant litteratur snabbt. Även IEEEportalen har använts. Efter en sökning i sökmotorn hade gjorts så gjordes ett urval bland träffarna genom att väga rubrikerna på sidorna mot varandra. En mer relevant rubrik för frågan som ställdes innan sökning valdes framför en rubrik som kanske inte stämde in med frågan. B.5 Resultat I detta avsnitt behandlas resultatet utifrån litteraturstudien. B.5.1 DDM Fördelarna med DDM är att metoden lätt går att applicera på redan färdiga system utan större förändring i relationsdatabasen [58]. Det finns också stora fördelar i att låta vissa roller kunna se all information om personer + att låta vissa bara se någon bokstav i namnet etc. Det är också en fördel att ha stor flexibilitet i vad som skall visas och döljas. Metoden kommer också med nackdelar som till exempel att den mestadels fokuserar på persondata. I projektet ingår många olika typer av sparad data: kartor, accesser, persondata, osv. Detta gör att metoden är svår att applicera på hela projektet [67]. B.5.2 AE Fördelarna med att alltid ha relationsdatabasen krypterad är många. Utvecklare kan arbeta med databasen trots att användare har sparat känslig information i den eftersom datan inte är läsbar för utvecklarna. Detta gör att systemet kan vara igång samtidigt som förändringar görs. Om det skulle vara så att inte AE används kan detta leda till att när utvecklarna sitter och arbetar med databasen kan de då läsa av känslig information om användare. Detta leder till att som användare av ett system som implementerat AE går det enkelt och säkert att spara data på till exempel molnet eller andra tredjepartens hanterare. En till fördel är att det skulle gå att kryptera kartinformation (som är aktuellt i gruppens produkt) detta gör också att underhållsarbete skulle kunna överlåtas till externt företag utan att känslig data kring lokaler läcker ut till obehöriga. AE kommer med nackdelar också. En av dem är att eftersom all data i hela databasen är krypterad kan detta leda till att det är svårt att jobba med informationen ur ett utvecklingsperspektiv. Eftersom den personal som underhåller databasen inte kan läsa av någon sparad information blir det svårt att strukturera om i systemet. Det är svårt att flytta information när det inte ens går att se vilken typ av data det är. Därför brukar det ofta vara så att AE borde reserveras för sådan information som verkligen är känslig [68]. B.5.3 TDE Fördelarna med TDE är att den löser kryptering för hela systemet och precis som i AE är datan alltid krypterad. Detta ger systemet skydd mot stöld av den fysiskt sparade datan, 62

72 B.6. Diskussion skydd mot otillåten kopiering av datan från tredje part och hinder för obehöriga att läsa informationen rakt av i databasen. Metoden tillåter också att utvecklare kan jobba med systemet samtidigt som användare sparar undan information i databasen. Detta eftersom TDE krypterar redan vid klienten. Det ger systemet stor säkerhet och användare kan försäkra sig om att deras data kan sparas säkert på till exempel molnet [68]. TDE kommer med några nackdelar också, en är att TDE alltid borde ställas mot AE. De två metoderna är mycket lika och det kan ta mycket tid att bestämma vilken som skall användas [69]. B.5.4 CLE Fördelarna med CLE är att den erbjuder bra kryptering genom alla steg av applikationen. Nackdelarna är dock stora då en fullständig ändring av systemet krävs för att få in krypteringen på alla ställen/celler. Om istället ett nytt system skall utvecklas så kan det vara fördelaktigt att börja med att implementera CLE från början [70]. CLE erbjuder då god säkerhet på alla nivåer och stor frihet för utvecklare att bestämma hur och var det ska krypteras [66]. B.6 Diskussion I vårt projektarbete om visuell hantering av behörigheter till lokaler har säkerhet för sparad data varit i fokus. De lösningar vi har använt oss av räcker för att erbjuda bra säkerhet inom systemets krav som en demoapplikation. Vid eventuell vidareutveckling mot färdig produkt kan det bli användbart att implementera resultatet i databasen för att skydda personliga uppgifter mer än i nuläget. Resultatet är baserat på en litteraturstudie gjord under begränsad tid. Detta kan medföra att vissa källor inte hittats eller att vissa källor inte varit de mest relevanta för ämnet. Men mest information kommer från dokumentation av de olika metoderna vilket beskriver hur funktionerna fungerar och utifrån det kan en slutsats dras. B.6.1 Frågeställning 1 De alternativ som lyfts i resultatdelen är väldokumenterade och allmänt erkända för att erbjuda bra dokumentation, säkerhet och anses vara relativt enkla att implementera. B.6.2 Frågeställning 2 Fördelarna med alla metoder är att alla krypterar informationen som skall skickas till relationsdatabasen. De gör detta på olika sätt och det är svårt att säga om det är så att en metod är bättre än den andra. Detta på grund av att det beror på vad organisationen som skall använda systemet tycker är viktigast att skydda. Vill de skydda persondata, lokaldata eller annan typ av data. Fördelarna med alla metoder är således individuella för varje metod och alla metoder gör jobbet bra. Nackdelarna med de olika metoderna avspeglas ofta i implementationen av respektive metod. I de flesta fall är det svårt att implementera metoden i ett redan färdigt system. Vissa metoder kräver mindre jobb att implementera än andra medan vissa kräver en komplett omstrukturering av systemet. Om det istället var ett nytt system som skulle implementeras hade många av nackdelarna kunnat undvikas genom att ta hänsyn till metodens implementationssteg. 63

73 B.7. Slutsatser B.6.3 Frågeställning 3 Utifrån resultatet hade den enklaste metoden att implementera varit DDM. Detta eftersom den inte kräver någon större omstrukturering av systemet samt dess enkla hantering av kryptering och avkryptering. Det finns stora fördelar med att låta några roller i systemet bara se liten del av personuppgifter till exempel en approver kanske inte behöver se exakta namnet på den anställda när denna söker access till ett rum. En admin kan behöva se all information om alla användare och en reader kanske inte ska kunna se mer än bara andra anställdas e-post. Med DDM ges friheten för att ändra vilken roll som ser vad från företag till företag vid eventuell vidareutveckling, problemet hamnar istället vid kartinformationen, då DDM passar för persondata men systemet innehåller även data för karthantering. Om prioriteten skiftas bort från persondatan i systemet och istället flyttas till kartaninformationen så borde antingen AE eller TDE användas. Dessa metoder gör att ett lejt företag kan användas för att sköta systemet då de inte kan läsa av informationen spara i relationsdatabasen. B.6.4 Problem och förbättringar Då undersökningen baserades på en litteraturstudie finns det alltid utrymme för förbättring. att undersöka fler källor, jämföra mer metoder mot varandra och ge studien mer tid är bara några av de många förbättringarna som skulle kunna ha gjorts. Det problem som arbetet stötte på var låsta dokument bakom betalväggar. Många lovande källor var tvungna att väljas bort på grund av just denna anledning. En annan påverkan på resultatet var tidsbegränsning. Denna rapport är en del i ett större kandidatarbete med max 400 timmar som skall läggas ner. Därför har inte alltid efterforskningar hamnat i fokus. B.7 Slutsatser Här redovisas de slutsatser som kan dras utifrån resultatet i denna rapport. B.7.1 Frågeställning 1 Slutsatsen som kan dras från frågan: "Vilka metoder finns det för kryptering av relationsdatabaser?"är att det beror lite på hur databasen är skriven. Den databas som skrevs i vårt projekt är en relationsdatabas skriven i SQL. Detta gjorde att de relevanta metoderna ofta kommer från Microsoft. B.7.2 Frågeställning 2 Slutsatsen som kan dras från frågan: "Vilka är för- och nackdelarna med respektive metod?"är att nackdelarna ofta har att göra med implementationen av metoden. Om istället systemet hade designats med en viss krypteringsmetod i åtanke hade många nackdelar kunnat undvikas. Fördelarna är många med varje metod. Alla krypterar den sparade datan. Vissa är bra för att skydda hela databasen mot obehörig läsning av informationen. Andra tillåter olika användare att se olika saker beroende på roll i systemet. Att väga metoderna mot varandra kan göras från olika utgångspunkter och mål och då kommer olika egenskaper vara åtråvärda. B.7.3 Frågeställning 3 Beroende på vad som prioriteras i systemet finns det olika svar att ge. Ett företag som helst vill skydda persondata kan vilja välja DDM, men för ett företag som har känslig lokaldata kan AE eller TDE vara aktuella. En kombination av dessa kan vara det ultimata. Kryptera 64

74 B.7. Slutsatser lokaldatan med hjälp av AE och sedan skydda persondatan med DDM kan bli en kraftfull kombination. 65

75 C Jesper Jensen Utveckling av mjukvara på distans C.1 Inledning Den 18 mars 2020 bestämde Linköpings universitet officiellt att sätta alla studier på distans. Anledningen till detta var COVID-19-epidemin som härjade världen runt [71]. Beslutet ledde till att alla studierelaterade aktiviter började göras hemifrån för både studenter och undervisande. Detta beslut togs halvvägs in kursen TDDD96 Kandidatprojekt i programvaruutveckling och ledde då till stora ändringar i hur projektgrupperna behövde arbeta. Det blev revideringar i arbetsmetoden internt inom varje grupp och externt med möten med kunden och de examinationsmoment som var planerade under kursens gång. Men även under dessa omständigheter fortsatte arbetet [72]. C.1.1 Syfte Denna rapport ämnar att undersöka de problem som uppstod under övergången till distansarbete och de verktyg som användes för att lösa dessa problem. Rapporten fokuserar mycket på verktyget Zoom som användes för digitala möten och examination inom kursen i jämförelse med dem innan distansläget. C.1.2 C.1.3 Frågeställning 1. Vilka verktyg finns det som kan användas för att underlätta utveckling på distans? Hur arbetar man med verktygen? 2. Vilka för- och nackdelar finns det med att arbeta på distans i en projektgrupp? Avgränsningar Denna rapport kommer att utgå i stor del från de grupper som arbetat med sitt kandidatarbete i kursen TDDD96 på Linköpings universitet. Det betyder att den data som används för rapporten kommer från en homogen grupp av studenter, och det finns därför en risk att resultaten inte är representativa för vad som är mest effektivt i en arbetsmiljö på ett företag. 66

76 C.2. Bakgrund Denna rapport täcker endast verktygen Discord, Google Hangouts, Microsoft Teams, Skype och Zoom. Det finns en stor mängd verktyg som kan användas för att underlätta distansarbete genom att tillåta användare hålla möten på distans eller underlätta utveckling. Denna rapport fokuserar mest på de studenter som gjorde kursen TDDD96 under våren 2020 och tar då bara hänsyn till de verktyg som var mest relevanta för deras studier. C.1.4 Ordlista 1. COVID-19 - COVID-19 står för coronavirus disease 2019 och är en sjukdom orsakad av det nya viruset SARS-coronavirus-2. Sjukdomen orsakar för de flesta en luftvägsinfektion där symptomen kan variera stort från person till person. Totalt personer har blivit diagnoserade med COVID-19 vid tidpunkten datan hämtades där av dem har dött [73]. De mest vanliga symptomen enligt Sveriges Folkhälsomyndighet är [74]: hosta feber andningsbesvär snuva nästäppa halsont huvudvärk illamående muskel- och ledvärk På grund av dess symptom har COVID-19 jämförts med säsongsinfluensan. Den största anledningen att COVID-19 blivit en stor epidemi är att inga människor har utvecklat immunitet mot denna typ av virus. För att minska effekten av säsongsinfluensan finns det vaccin och läkemedel och befolkningar har byggt upp immunitet mot olika varianter av influensavirus då det existerat så länge. Vid tidpunkten när denna rapport skrevs fanns det inget vaccin mot COVID-19 [74]. C.2 Bakgrund När LiU beslutade att kursen TDDD96 - och alla andra kurser - skulle slutföra allt arbete på distans uppstod det i början en del osäkerhet bland studenterna om hur upplägget skulle bli. Det blev förändringar i examinerade moment och alla presentationer och möten med personal skulle ske på distans med hjälp av verktyget Zoom. Kursen skulle primärt använda sig av Zoom men också av Microsoft Teams om det var några förhinder med Zoom. Utöver detta behövde projektgrupperna komma på nya sätt att hantera utveckling och interna möten då majoriteten av allt arbete nu behövde ske på distans. Det fanns en stor mängd av verktyg till hands för att underlätta distansarbetet men med nya lösningar kom också nya problem. C.3 Metod Här beskrivs de tillvägagångssätt som har använts för att besvara frågeställningen. För denna rapport används till största delen en enkätundersökning för att besvara frågeställningen men rapporten använder sig också av en mindre litteraturstudie för att bilda teoriavsnittet. 67

77 C.3. Metod C.3.1 Undersökning En undersökning genomfördes med syfte att ta reda på hur olika grupper arbetar på distans, hur de nyttjar olika kommunikationsverktyg och hur de löser de problem som uppstår. Undersökningen gjordes genom en enkät som skickades ut och besvarades av 155 personer. Enkäten var främst riktad mot studenter i kursen TDDD96 och besvarades av majoriteten av studenterna i kursen. En del av svaren kom dock från folk utanför universitetet. Enkäten skapades med hjälp av Google Forms och skickades ut till studenter och kontakter genom en länk. Enkäten hade mestadels kryssfrågor för att resultaten enklare skulle kunna avläsas. Enkäten med de ställda frågorna följer nedan. Varje fråga är i fetstil och svarsalternativen står under i vanlig text. Svarsalternativen annat och fri text låter respondenten själv formulera och skriva ner sitt svar. Om en fråga börjar med vilka kan flera alternativ väljas medan frågor som börjar med vilket ger bara ett alternativ. 1. Vilka är de största fördelarna med att arbeta på distans tycker du? Effektivitet, matvanor, raster, arbetstider, socialt umgänge, arbetsmiljö, ergonomi, annat. 2. Vilka är de största nackdelarna med att arbeta på distans tycker du? Effektivitet, matvanor, raster, arbetstider, socialt umgänge, arbetsmiljö, ergonomi, annat. 3. Vilka av följande verktyg har du använt för att underlätta distansarbetet? Zoom, Microsoft Teams, Google Hangouts, Skype, Discord, annat. 4. Vilket av följande verktyg skulle du valt att använda för ett möte med cirka åtta personer? Zoom, Microsoft Teams, Google Hangouts, Skype, Discord, annat. För kommande frågor är X svaret från fråga 4 5. Hur bra är Xs användarvänlighet enligt dig? 1-7 där 1 är väldigt dåligt och 7 är väldigt bra. 6. Har X tillräckligt med funktionaliteter enligt dig? 1-7 där 1 är behöver många fler och 7 behöver inga fler. 7. Hur bra är Xs säkerhet enligt dig? 1-7 där 1 är väldigt dåligt och 7 är väldigt bra. 8. Tycker du att X fungerar lika bra med 2 personer som med flera? 1-7 där 1 är inte alls och 7 är lika bra. 9. Vilka funktionaliteter tycket du att X saknar? Fri text. 10. Har du arbetat i en projektgrupp på distans? Ja, nej. Följande frågor kommer endast om respondenten svarade Ja på fråga Hur har arbetet gått för dig och din projektgrupp efter övergången till distans jämfört med innan? 1-7 där 1 är mycket sämre och 7 är mycket bättre. 68

78 C.4. Teori 12. Hur bestämde ni som grupp vilka verktyg som skulle användas? Tidigare erfarenheter, testade oss fram, valde universitetets rekommendation (Zoom/ Microsoft Teams), valde mitt företags rekommendation, annat. 13. Vilket verktyg använde ni för utveckling? Zoom, Microsoft Teams, Google Hangout, Skype, Discord, annat. 14. Vilket verktyg använde ni för interna möten? Zoom, Microsoft Teams, Google Hangout, Skype, Discord, annat. 15. Vilket verktyg använde ni för kundmöten? Zoom, Microsoft Teams, Google Hangout, Skype, Discord, annat. 16. Vilket verktyg använde ni för handledarmöten? Zoom, Microsoft Teams, Google Hangout, Skype, Discord, annat. 17. Vilket verktyg använde ni för annat? Zoom, Microsoft Teams, Google Hangout, Skype, Discord, annat. 18. Hur har tidsfördelningen i gruppen förändrats genom att arbeta på distans istället för på plats? 1-7 där 1 är mycket sämre och 7 är mycket bättre. 19. Hur har inlärningen för gruppmedlemmarna förändrats genom att arbeta på distans istället för på plats? 1-7 där 1 är mycket sämre och 7 är mycket bättre. 20. Hur har gruppens mentala inställning till arbetet förändrats genom att arbeta på distans istället för på plats? 1-7 där 1 är mycket sämre och 7 är mycket bättre. 21. Hur har grupprocesser som att lösa problem och ta beslut förändrats genom att arbeta på distans istället för på plats? 1-7 där 1 är mycket sämre och 7 är mycket bättre. 22. Har du något du skulle vilja tillägga? Fri text C.3.2 Litteraturstudie För att ta reda på hur de olika kommunkationsverktygen har skiljt sig åt har en mindre litteraturstudie genomförts. Studien har fokuserat på de största säljpunkterna för varje verktyg samtidigt som den jämför antalet användare per verktyg. Datan har samlats med hjälp av sökverktyget Google och exempel på sökord som har använts är Zoom, Microsoft Teams, Google Hangouts antal användare, Teams vs Zoom med flera. Google Scholar har användts för att hitta artiklar om COVID-19 med sökord COVID-19. Artiklarna och webbplatserna som valdes var dem som ansågs mest relevant för den teori som behövdes för att besvara frågeställningen. Alla källor valdes från första Google sidan som kom upp efter sökningen. C.4 Teori Teorin täcker de områden vars bakgrund behöver utvecklas och förklaras för att ge en förståelse för de begrepp och verktyg som rapporten redogör för. För att hålla möten på distans krävs någon typ av plattform eller verktyg. Information om varje plattform står under avsnitt C

79 C.4. Teori C.4.1 Onlinemöten På grund av distansläget går det i de flesta fall inte längre att hålla möten i stor grupp. Istället byter man till verktyg som tillåter onlinemöten och videokonferenser. Varje deltagare behöver endast en dator eller en mobil för att hålla ett distansmöte. Det är dock ofta rekommenderat att deltagare har en webbkamera för att försöka återskapa känslan av ett riktigt möte. Zoom Zoom är ett snabbt växande program för onlinemöten som under året 2020 gick från 10 miljoner till 200 miljoner användare på bara 3 månader. Den största anledning till detta är att det började användas på skolor och universitet för att hålla lektioner, föreläsningar och andra studierelaterade aktiviteter när skolor bytte till distansläge under COVID-19 epidemin. Zoom tillåter onlinemöten med över 100 personer närvarande för gratisversionen och upp till 500 för en kostnad. Detta är nästan ett måste för högskolor och universitet då många föreläsningar har upp mot 250 studenter närvarande. Användargränssnittet är väldigt självförklarande och lätt att lära sig vilket gjorde det till ett bra alternativ när skolor snabbt behövde byta till en distanslösning [75]. Med mer än 90 tusen skolor hela världen över som använder Zoom Vid tidpunkten när denna rapport skrevs visar sig Zoom vara en starkt växande konkurrent till de redan etablerade företagens liknande tjänster [75]. Microsoft Teams Microsoft Teams är en välkänd plattform för både chatt, onlinemöten och fillagring för projektgrupper. Teams används i många stora företag - som till exempel Ericsson och Volvo - inte bara för sagda egenskaper utan också för plattformens integration med Office 365. Detta erbjuder en mängd av olika produkter till sina användare som till exempel Microsoft Outlook för att läsa, skriva och skicka mejl och Microsoft Word, ett av världens största ordbehandlingsprogram. Teams har en gräns på max 250 personer i ett möte [76]. Google Hangouts Google Hangouts är en kommunikationsplattform av Google som ersatte tre tidigare Google medelandetjänster: Google Talk, Huddle och Hangouts [77]. Som i Teams och Zoom går det att skapa grupper för chatt och videomöten. Hangouts stödjer upp till 25 personer för videomöten och 150 för vanlig chatt. Eftersom platformen är från Google har den bra stöd för användare med redan existerande gmail-konton. Användare kan då snabbt starta samtal eller onlinemöten med kontakter som redan har gmail-konton [78]. Discord Discord är en plattform avsedd för att underlätta kommunikationen inom spelföreningar. På grund av detta har plattformen stort fokus på text- och röstchatt men har också stöd för videochatt (dock väldigt begränsat). Discord fungerar genom att användare kan skapa egna servrar som personer kan bli inbjudna till. Detta är väldigt likt de team som går att skapa på Microsoft Teams och de grupper som går att skapa i Zoom. Varje server är uppbyggd av olika text- och röstkanaler där användare kan kommunicera med varandra. Det som är speciellt med röstkanalerna i Discord är att alla användare på servern kan se vilka människor som är aktiva i en röstkanal. Detta gör det lätt att snabbt hoppa in i en kanal och så kan andra gå med när det passar dem istället för att man behöver ringa upp varje medlem [79]. Skype Skype är en kommunikationsplatform - numera ägd av Microsoft - som är specialiserad på videochatt och röstsamtal. Skype har existerat sedan 2003 [80] vilket är markant längre än dess 70

80 C.5. Resultat konkurrenter. Till exempel skapades Google Hangouts och Microsoft Teams 2013 respektive 2016 [81], [77]. Skype har länge varit en standard för kommunikation inom både stora och små företag. Mer än 42 tusen företag använder idag Skype vilket är en extremt stor siffra jämfört med till exempel Zoom som har ungefär 22 tusen eller Google Hangouts som är nere vid cirka två tusen [82]. Microsoft har dock meddelat att Skype för företag kommer avslutas i slutet av juli Microsoft uppmuntrar nu sina kunder att börja använda Microsoft Teams istället [83]. C.5 Resultat Här beskrivs resultatet utifrån den metod specificerade i avsnitt C.3. C.5.1 Undersökning Enkäten besvarades av totalt 155 personer. Detta avsnitt fokuserar på de frågor i enkäten som är relevanta för att svara på rapportens frågeställning. Svarsalternativ med mindre än 5 svar har tagits bort från diagrammen för att göra dem tydligare. 1. Vilka är de största fördelarna med att arbeta på distans tycker du? Den största fördelen med att arbeta på distans var arbetstiderna vilket blev valt av mer än hälften av respondenterna (51.9%). Följt nära därpå var effektivitet (41.9%) och lite längre ner kom raster (25.8%), matvanor (21.3%) och arbetsmiljö (19.4?%). Ergonomi (9%) och socialt umgänge (3.9%) blev valt som en fördel av en liten minoritet. 2. Vilka är de största nackdelarna med att arbeta på distans tycker du? Socialt umgänge var solklart den största nackdelen med att arbeta på distans då det blev valt av mer än 4 av 5 respondenter (83.2%). Därefter kom ergonomi (39.3%), arbetsmiljö (35.5%) och effektivitet (32.2%). De som blev valda minst var raster (21.3%), matvanor (18.1%) och arbetstider (14.8%). Figur C.1: Grupperat stapeldiagram med för- och nackdelar med distansarbet från svaren i fråga 1 och Vilka av följande verktyg har du använt för att underlätta distansarbetet? Resultat illustreras i figur C.2. På det givna svarsalternativet annat svarade 16 personer (10%) Slack vilket var en tillräckligt stor andel för att kräva en egen stapel. 4. Vilket av följande verktyg skulle du valt att använda för ett möte med cirka åtta personer? Resultat illustreras i figur C.3. 71

81 C.5. Resultat Figur C.2: Stapeldiagram för frågan om vilka verktyg som underlätta distansarbetet. Figur C.3: Stapeldiagram för vilket verktyg som är bäst för ett möte med åtta personer. 72

82 C.5. Resultat 10. Har du arbetat i en projektgrupp på distans? Av alla som svarade på enkäten så hade 95 personer (61%) arbetat i projektgrupp på distans och frågorna besvaras då bara av max 95 personer. Resultat illustreras i figur C.4. Figur C.4: Tårtdiagram för andelen som arbetat i projektgrupp på distans. 11. Hur har arbetet gått för dig och din projektgrupp efter övergången till distans jämfört med innan? 87 personer svarade på frågan och mer än hälften tyckte det gick lika bra eller bättre än innan. Resultat illustreras i figur C.5. Figur C.5: Stapeldiagram för hur bra arbetet gick efter övergången till distans. 73

83 C.5. Resultat 12. Hur bestämde ni som grupp vilka verktyg som skulle användas? Majoriteten valde antingen sitt företags eller universitetets rekommenderade verktyg. Resultat illustreras i figur C.6. Figur C.6: Stapeldiagram för metoden att välja verktyg bestämdes. Fråga resultat illustreras i figur C.7. Figur C.7: Grupperade stapeldiagram för de verktyg som användes i olika situationer. 74

84 C.6. Diskussion C.5.2 Litteraturstudie Litteraturstudiens resultat är den teori som finns i C.4. C.6 Diskussion Här diskuteras de framtagna resultatet och den metoden som används. C.6.1 Resultat Svaren på för- och nackdelar med att arbeta på distans säger tydligt att den största nackdelen är socialt umgänge. Att hålla all kommunikation på distans blir mycket jobbigt efter en längre tid. Det går fortfarande att spendera samma tid med varandra på raster och pauser men det blir inte samma känsla som att träffas personligen. Det kan också bli att man går ut mindre då allt arbete sker i hemmet vilket minskar socialt umgänge ytterligare. Nästa stora nackdel var ergonomi. Att arbete hemifrån kan vara mycket bekvämt men det betyder inte att det är ergonomiskt. Många arbetsplatser och skolor ser till att arbetsplatsen är ergonomisk genom bra stolar och lämplig belysning. Detta är dock inte alltid sant i hushållet. Linköpings universitet har en 15 minuters rast per timma vilket får studenter att gå runt och röra på sig och socialisera. När man arbetar hemifrån kan det bli att man glömmer bort att ta raster och arbetar flera timmar i streck. Att arbeta på distans betyder också att man inte behöver ta sig fram och tillbaks till arbetet vilket för många speciellt studenter på LiU är en cykeltur eller promenad vilket är bra för kroppen. Det var 14 personer som tyckte att ergonomi istället var en fördel med distansarbete och detta kan bero på att respondenterna har en plats i hemmet som redan är ergonomisk. Detta är dock en minoritet av de som svarade. Den största fördelen med distansarbetet var arbetstider. Att arbeta på distans ger en mycket större frihet för att planera sin arbetsdag. Om det passar bättre med individens personliga schema kan hen lägga fler timmar på kvällen och mindre på morgonen eller vice versa. Det är också lättare att planera anndra aktiviteter runt arbetet då man kan gå direkt från hemmet och inte från arbetsplatsen. För resterande svarsalternativ var skillnaden i antal svar på för- och nackdelar inte tillräckligt stor så det var svårt att dra slutsatser utifrån den datan. En gemensam faktor i alla svar på frågor som handlade om verktyg var Zoom. Zoom verkar som det klart mest använda verktyget av de som svarade på enkätten. Zoom var det verktyg som användes mest i alla situationer. Detta betyder att Zoom fungerar bra för respondenterna i både små grupper som utveckling och till stora som till exempel sammanstrålningar. Det är dock svårt att veta om Zoom faktiskt är det mest effektiva verktyget då många valde att använda det endast för att det är universitets rekommendation. Att Zoom faktiskt fungerade bra är ganska säkert eftersom respondenterna nog snabbt skulle byta verktyg annars. Den enda situationen som Zoom nästan inte kom först i var kundmöten. Där var Microsoft Teams endast tre svar bakom Zoom. Detta är för att många företag använder Teams för att kommunicera inom företaget. Om man också räknar med Skypes svar (11 personer), eftersom företag just nu håller på att byta över från Skype till Teams, så ser Teams ut som en stark kandidat för kundmöten. Discord användes som mest i utvecklingssyfte, dock fortfarande inte lika mycket som Zoom men mer än Teams och Google Hangouts. Discord har fördelen att det är lätt att snabbt gå in i en kanal med de som man behöver arbeta med, och detta är troligtvis en av de största anledningarna till att det används. För större möten verkade Discord inte som ett lika attraktivt alternativ vilket förmodligen beror på att plattformen saknar support 75

85 C.7. Slutsatser för bra videochatt. Majoriteten av de som svarade på enkäten tyckte att arbetet hade gått lika bra som innan övergången till distans eller till och med bättre. Endast 17 personer (19.1%) tyckte att arbetet hade gått lite sämre medan resterande kände ingen skillnad eller att arbetet gått bättre. Detta säger då att bytet till distansarbetet för majoriteten av de som svarade är en positiv händelse. Detta går dock lite mot resultaten om för- och nackdelar med distansarbete då det verkade vara mer negativa saker än positiva. Det kan dock betyda att den största fördelen med distansarbete som var arbetstider har mer vikt bakom sig än alla andra faktorer och resulterar i bättre resultat inom projekt. Det kan också varit någon fördel som enkäten inte lyckades utvinna från respondenterna. C.6.2 Metod Vid sammanställningen av resultatet från enkäten var det några problem som uppstod vid en del av frågorna. På fråga om vilka verktyg som användes i vissa situationer blev det en stor mängd av personerna som svarade annat. Detta beror troligtvis på att en del av svaren kom från personer som inte studerade på LiU utan istället arbetade på ett företag och då använde andra verktyg. Dessa svar skulle kunna filtreras om det hade frågats om respondenten studerade på LiU eller inte. Ett liknande problem uppstod vid frågan om vilka verktyg respondenten använde för handledarmöten då de som arbetar på företag inte har en handledare och därför inte har handledarmöten. Detta gör det svårt att veta om svaren reflekterar verkligheten eller inte. Litteraturundersökningen fungerade bra med det syftet som var i åtanke. Det vill säga att skapa ett grundläggande teori avsnitt om de verktyg som jämfördes i enkäten. En nackdel med undersökningen är att den kanske är för grundläggande för många som kommer läsa rapporten. Många människor inom arbetslivet har redan kunskapen om vad till exempel Skype och Teams är för något och ger då ingen ny information. Det är dock fortfarande viktigt att teoriavsnittet finns eftersom enkäten och jämförelsen av verktyg bygger på att läsaren känner till dem. C.7 Slutsatser Här redovisas slutsatserna till rapportens frågeställningarna med hjlälp av resultatet och disskusionen. C.7.1 Vilka verktyg finns som kan användas för att underlätta utveckling på distans? Hur arbetar man med verktygen? Zoom är ett extremt bra verktyg som fungerar i både små och störa möten, för utveckling och föreläsningar. Microsoft Teams fungerar bra och används redan på många företag runt om i världen. Teams har också fördelen att många användare som kommer sluta använda Skype 2021 kommer börja använda Teams. Discord kan vara värt att tänka på som ett alternativ vid utveckling men är inte rekommenderat för stora möten. C.7.2 Vilka för- och nackdelar finns det med att arbeta på distans i en projektgrupp? Största fördelen med att arbete på distans är arbetstider då det blev enklare att planera andra aktiviteter runt arbetet. Den absolut största nackdelen med distansarbete var socialt umgänge men också ergonomin. 76

86 D Ludvig Joborn Kritiska krav: En fallstudie D.1 Inledning Hållbar utveckling är ett av de hetaste och viktigaste diskussionsämnena på global, samhällsoch individnivå. Vår tids största utmaning är att skapa en framtid som kommer att kunna lösa flera globala problem under tidspress. Ett av många initiativ som berör dessa utmaningar är Förenta Nationernas (FN) hållbarhetsmål till 2030 där FN listar dessa utmaningar. FN vill med dessa mål inspirera världen till att bygga en hållbar framtida civilisation. Ett misslyckande att uppfylla av dessa mål kan orsaka allvarliga konsekvenser på global skala. [84] Det ter sig inte helt orimligt att flera av dessa utmaningar kommer att lösas genom teknologiska framsteg, där mjukvara tagit en alltmer större och central roll i vår fortsatta teknikutveckling. Men kraftfullare mjukvara leder oundvikligen till att den kan användas till ondo med allt kraftfullare konsekvenser. Exempel på mjukvaruteknik som användes till både ondo och godo är bildbehandling. Denna teknik har redan implementerats auktoritära övervakningssystem och passar perfekt till AI-styrda drönare med skjutvapen och 100 % träffsäkerhet. Samtidigt har bildigenkänning framgångsrikt applicerats på detektion av cancertumörer inom vården och används till utveckling av farkoststyrning för säkrare trafik. D.1.1 Syfte Syftet med denna undersökning är att utforska processen för kravhantering (eng. Requirements engineering) i relation till ett ramverk som är tänkt att inspirera till att utöka denna process med tankar om social hållbarhet, som är en aspekt av hållbar utveckling. Ramverket Critical Systems Heuristics (CSH) kommer att användas för att analysera projektet relaterat till denna rapport och dess kravspecifikationen utifrån olika aspekter av social hållbarhet, med fokus på vilka intressegruppers perspektiv som har och borde forma systemets utveckling. Genom denna analys kan aspekter av social hållbarhet som systemet inte tagit i åtanke uppdagas och sedan reflekteras över. 77

87 D.2. Bakgrund D.1.2 Frågeställningar 1. Bland alla som potentiellt kommer påverkas av systemet som byggts, vilka påverkade grupper saknar en röst i kravhanteringen? 2. Givet resultaten av (1.), vilka aspekter av projektet skulle kunna förändras av att inkludera dessa påverkade gruppers åsikter och perspektiv? 3. Kan processen för kravhantering utökas för att ta hänsyn till aspekter av social hållbarhet genom att applicera Critical Systems Heuristics? 4. Vilka är för- och nackdelarna med att inkludera Critical Systems Heuristics i kravhanteringsprocessen? D.1.3 Avgränsningar Denna rapport utgår från den kravspecifikation och kravhantering som ingick i detta projektarbete. Andra kravspecifikationer och processer för kravhantering kommer ej att beaktas. Undersökningen kommer även att begränsa sig till att endast undersöka ramverket CSH och hur användning av denna modell kan påverka processen för kravhantering och kravspecifikationen för just detta projekt. Undersökningen kommer behandla systemet som utvecklats som om det var planerat att sättas i bruk vid färdigställning. D.1.4 Ordlista Critical Systems Heuristic (CSH): Ett ramverk för kritisk granskning av ett generellt systems avsedda omfattning. Kravhantering: Processen för skapande och underhåll av en kravspecifikation inom mjukvaruprojekt. D.2 Bakgrund Vid konstruktionen av ett mjukvarusystem har kravhantering en erkänt avgörande roll för systemets design inom programvaruutveckling. Eftersom kravhantering ofta används som hörnsten inom systemdesign så har den även en genomgående påverkan på det slutgiltiga systemets kvalitet [85]. Det som ingår i kravhantering kommer därmed att påverka systemets implementation. Med detta i åtanke är det av intresse att undersöka processen för kravhantering och reflektera över vilka typer av system som denna process implicerar och, ännu mer intressant, vad som processen inte implicerar. Med andra ord: Vilka intressanta aspekter av ett mjukvarusystem saknar en plats inom kravhantering? Vid utvecklingen av systemet som ligger till grund för denna kandidatrapport så fanns ett annat lokalbehörighetshanteringssytem redan i drift. Men missnöje med det gamla systemet ledde till önskemål om alternativ, vilket i sin tur ledde till utvecklingen av systemet som behandlats i denna undersökning. Därav baserades många av de designbeslut som gjordes i detta system på vad som var bra och vad som var dåligt med det äldre systemet. Många av de antaganden om vad som utgör ett bra lokalbehörighetshanteringssystem kommer från kundens erfarenheter med det äldre systemet. Det är viktigt att veta att under kravhanteringen för detta projekt så hade projektgruppen endast en person som utgångspunkt för skapandet kravspecifikationen. Denna persons perspektiv har varit mycket givande vid kravframställningen. Men frågan är: Givet att vi endast har kunden att utgå från, vilka perspektiv går vi miste om? Eller ännu mer intressant: Finns det personer vars intressen går emot de intressen som vår kund har? 78

88 D.3. Teori D.3 Teori I detta avsnitt ges en teoretisk bakgrund till de begrepp och modeller som rapporten använder sig av. Första avsnittet handlar om hållbar mjukvaruutveckling och det andra om Critical Systems Heuristics. D.3.1 Hållbar utveckling och mjukvara Hållbar utveckling är en princip som syftar till att mänskliga rättigheter och mänsklig utveckling ska uppfyllas medan vi upprätthåller de ekosystem som tillgodoser samhällens och människors behov. Men andra ord så vill man upprätta en människa-ekosystem-jämvikt. Hållbar utveckling avser då även den utveckling som behöver åstadkommas för att nå denna jämvikt. Förenta Nationernas 17 hållbarhetsmål för 2030 fångar de relevanta utmaningarna för det kommande decenniet. I denna rapport betyder hållbar mjukvara sådan som bidrar till uppfyllandet av hållbarhetsmålen. D.3.2 Critical Systems Heuristics Eftersom mjukvara får en alltmer central roll i den moderna världen så ställs det nya krav på förmågan hos mjukvaruutvecklare att ta hänsyn till moraliska och etiska frågor på samhällsoch individnivå. Det område inom mjukvaruutveckling som ter sig bäst lämpat för att hantera dessa nya krav är kravhantering [86]. CSH är ett ramverk utvecklat av Werner Ulrich och grundas på idén om avgränsningskritik (eng. Boundary Critique). Avgränsningskritik innebär att granska de avgränsningar som (medvetet eller omedvetet) anses vara inom systemets omfång (dvs vilka effekter systemet har på omgivningen den placeras inom) och sedan reflektera i över vilken utsträckning dessa avgränsningar tar hänsyn till de kategorier av människor som skulle påverkas av systemets implementation. CSH tar hänsyn till två aspekter av selektivitet vad gäller systemets avgränsningar: normativ och empirisk. Normativ selektivitet sker när avgränsningar görs med resonemang om hur systemet bör vara. Även avgränsningar om vilka fakta och tillvägagångssätt som borde anses relevanta är aspekter av normativ selektivitet. Empirisk selektivitet omfattar då aspekter som redan ingår systemets avgränsningar [87, p.7]. CSH identifierar fyra grundläggande gränsfrågor (eng. boundary issues) kring ett påstående som rör en given avgränsning: Motivationsgrund - Varifrån kommer känslan av syfte och värde? Maktgrund - Vem har kontroll över vad som händer och vad som behövs för framgång? Kunskapsgrund - Vilka erfarheter och vilken expertis stödjer påståendet? Legitimitetsgrund - Var ligger legitimiteten? Tillsammans utgör dessa frågor ett påståendes målmedvetenhetsanatomi. Inom ramarna för CSH så anses dessa frågor vara essentiella för tankfull praxis inom de flesta situationer som omfattar beslutsfattande [87, p.8-9]. För var och ett av dessa gränsproblem identifieras tre aspekter: Intressenter - Vilka människor har intresse av situationen genom att vara involverade och/eller påverkade? Angelägenhet - Vilken angelägenhet associeras med intressenten i fråga? Svårigheter - Vilka svårigheter uppstår i samband med angelägenheterna i fråga? 79

89 D.4. Metod Sources of influence Sources of motivation Tabell D.1: Gränskategorierna som de definieras i CSH. Boundary judgements informing a system of interest (S) Social roles Specific concerns Key problems (Stakeholders) (Stakes) (Stakeholding issues) 1. Beneficiary: Who ought to be/is the intended beneficiary of the system (S)? 2. Purpose: What ought to be/is the purpose of S? 3. Measure of improvement: What ought to be/is S s measure of success? The involved Sources of control 4. Decision maker: Who ought to be/is in control of the conditions of success of S? 5. Resources: What conditions of success ought to be/are under the control of S? 6. Decision evironment: What conditions of success ought to be/are outside the control of the decision maker? Sources of knowledge Sources of legitimacy 10. Witness: Who ought to be/is representing the interests of those negatively affected by but not involved with S? 8. Expertise: What ought to be/are relevant new knowledge and skills for S? 11. Emancipation: What ought to be/are the opportunities for the interests of those negatively affected to have expression and freedom from the worldview of S? 7. Expert: Who ought to be/is providing relevant knowledge and skills for S? 9. Guarantor: What ought to be/are regarded as assurances of successful implementation? 12. Worldview: What space ought to be/is available for reconciling differing worldviews regarding S among those involved and affected? The affected När man kombinerar gränsproblemen med deras aspekter får man frågematrisen som visas i tabell D.1 [87, p.11]. Frågorna är formulerade för att relatera till både empirisk och normativ selektivitet. D.4 Metod Undersökningen skedde i tre steg. Först kommer CSH-modellen att appliceras på detta projekt för att undersöka de avgränsningar som gjorts i samband med skapandet av kravspecifikationen och hur avgränsningarna kan utökas. Resultaten av detta kommer sedan att användas för att reflektera över hur systemet skulle kunna påverkas av att utöka avgränsningarna. Till sist evalueras värdet i att använda CSH som en utökning av klassisk kravhantering. Se bilaga I för kravspecifikationen som togs fram i detta projekt. D.5 Resultat I detta avsnitt redovisas mina svar på CSH-frågorna och en sammanfattning av intervjun med representanten för ej inkluderade intressegrupper. Se tabell D.1 för frågeformuleringarna. 80

90 D.5. Resultat D.5.1 Mina svar på CSH-frågeställningarna Systemet som utvecklats i detta projekt betecknas som S nedan. a) besvarar hur läget är och b) besvarar hur (jag anser att) det borde vara. 1. a) Den största vinnaren av S är tänkt att vara administratörerna som administrerar lokalbehörigheterna på kundens kontor. Mer brett sett så ska alla som jobbar på kundens kontor gynnas av effektivt användande av detta system. Vi hoppas att detta system ska vara nyttigt för lokalvårdare, extern inhyrd personal (till exempel reparatörer) och alla som ska röra sig på kundens kontor. Framförallt kommer detta att gynna de som är ansvariga för säkerheten i lokalerna, då detta verktyg kommer att ge dem ökade möjligheter att ge avgränsade behörigheter snabbt. b) Vi vill främst att administratörerna ska gynnas av S, då det ska effektivisera lokalbehörighetshantering. (Diverse) Anställda hos kunden ska även ha nytta av detta system då det ska bli enklare att beställa rum. Säkerhetscheferna bör även de gynnas av ökad grad av säkerhet och minskat antal säkerhetsrisker från mänskliga misstag. 2. a) Huvudsyftet med S är att underlätta den administrativa bördan för systemets administratörer. Det är för nuvarande tänkt att underlätta lokalbehörighetssökandeprocessen för alla involverade. b) S borde ge mer överskådlighet och säkerhetskontroll över lokalerna, för att maximalt kunna begränsa obehörigas tillgång till säkerhetszoner. 3. a) Systemets framgång mäts av i hur stor utsträckning som systemadministratörer hos kunden upplever att S är enklare att lära och framförallt använda än det gamla systemet. Det mäts även av hur mycket lättare användningen av systemet upplevs vara bland anställda hos kunden. b) Systemets framgång borde även mätas av hur administratörer och andra med intresse för säkerhet inom kundens lokaler anser att systemet underlättar underhållandet av god säkerhet kring hantering av lokalbehörigheter. 4. a) För nuvarande är det säkerhetscheferna hos kunden som är de som utvärderar systemet och avgör vilka kriterier som anses relevanta för utvärderingen av S. b) Administratörerna som använder och ansvarar för systemets underhåll bör vara de som avgör kriterierna och huruvida dessa uppfylls. Generella gruppen anställda hos kunden (uteslutande de tidigare nämnda grupperna) bör även representeras i utvärderingen av S. 5. a) Säkerhetscheferna är de som sköter kontakten med utvecklingsteamet, vilket ger dem maximal kontroll över utformningen av S. b) Administratörerna som är tänkta att främst ansvara för underhåll och användandet av S borde kunna ge sina åsikter om de lösningar som utvecklingsteamet utformat åt dem. Idealt sett så sker arbetet i tätt samarbete med administratörer så lösningar kan göras för att maximera deras trivsel och effektivitet med S. 6. a) För nuvarande kontrollerar säkerhetscheferna i princip alla relevanta aspekter av projektets mått på framgång. b) Säkerhetscheferna bör inte avgöra hur välanpassat S ter sig för administratörer. Deras möjlighet till att uttala sig om hur systemet är att använda för generella kategorin anställd hos kunden bör begränsas. (Men inte slopas!) 7. a) Säkerhetscheferna (och administratörerna i en mindre utsträckning) är experter på hur säkerheten i dessa system bör skötas. 81

91 D.6. Diskussion b) Administratörer för liknande system och de som administrerar det nuvarande systemet kan anses vara experter på vad som gör ett system som S bra och vad som gör det dåligt (vanliga problem/misstag, funktioner som saknas, etcetera). 8. a) För närvarande konsulteras inga experter. b) En expert på användarbarhet och/eller underhållbarhet skulle kunna konsulteras för att ge input om vad som gör S användbart och underhållbart. En expert på datasäkerhet skulle kunna konsulteras för att hjälpa till med att reflektera över aspekter som gör vårt system säkert för intrång! (Ny aspekt av mätbar framgång, mäta systemets säkerhet!) 9. a) Säkerhetscheferna antas kunna leda utvecklingen av S till ett användbart och säkert system. De kan antas även kunna avgöra huruvida systemet är användbart för gruppen anställda hos kunden. b) Konsensus bland administratörer ter sig som ett utmärkt mått för S användarbarhet och underhållbarhet hos administratörer. S bör även testas och bekräftas att följa standarder och praxis som finns tillgängliga för att bekräfta att systemet är skyddat från logistikfel och intrång. 10. a) För närvarande anses det att ingen grupp av människor kommer att påverkas negativt om S uppfyller de mål som satts upp. Obehöriga påverkas negativt men deras talan är föga intressant i detta sammanhang. b) Vem för talan för fysiskt funktionsnedsatta? Hur kommer de påverkas? 11. a) Ej tillämpbar, ty ingen grupp identifierades. b) En expert och/eller en talesperson för funktionsnedsatta borde konsulteras. 12. a) I slutändan är systemet designat för Erikssons lokaler så det är de i beslutsposition på Eriksson som avgör systemets framtid. Om det är utanför deras intresse att ta hänsyn till funktionsnedsatta så är det så det kommer att bli. b) Att involvera administratörer under utvecklingen av systemet är inte en stor ansträngning och borde göras. Någon bör kunna förespråka funktionsnedsatta människors möjligheter att besöka lokalerna. D.6 Diskussion Nedan diskuteras denna individuella dels metod och resultat. D.6.1 Generella tankar Efter att ha besvarat CSH-frågeställningarna framgick det väldigt tydligt att det saknades feedback från IT-administratörer, vilket jag hade tankar om redan före applicerandet av CSH. Det som dock överaskade mig var allvarligheten och utsträckningen av hur denna intressegrupps (eller till och med målgrupps) intressen inte var tillgodosedda i den tidigare kravhanteringsprocessen. Från utvecklarnas (vår) och kundens sida visade det sig att det var väldigt mycket vi antog om hur IT-administratörerna ville ha detta system! Det fanns ingen garanti över huvud taget för att de antaganden vi gjorde om hur systemet borde utformas faktiskt reflekterade vad en IT-administratör anser utgör ett bra IT-system. Dessutom framgick det även att säkerhet har prioriterats väldigt lågt. Kravspecifikationen specificerar att lösenord ska krypteras, att inmatningar ska kontrolleras, att det ska finnas en systemlogg och att det ska gå att rensa persondata för användare som tas bort. Men dessa åtgärder är väldigt basala och ger inga bra garantier för ett säkert system. Vi har nöjt oss med 82

92 D.6. Diskussion att lösenorden är krypterade men testar inte hur väl krypteringen fungerar. Dessutom har två av kraven prioritet 2, vilket innebär att de implementeras i mån av tid efter allt av prioritet 1 är avklarat. För att förbättra och fastställa säkerhet i vår webbapplikation så kunde vi exempelvis utgått från OWASPs top tio säkerhetsrisker för webbapplikationer och implementera åtgärder som motverkar dessa säkerhetsrisker [88]. För mer om hur kryptering skulle kunna implementeras mer utförligt i detta projekt, se kapitel B. För mer om hur persondata kan hanteras på ett säkert sätt i linje med GDPR, se kapitel H. Analysen gav även att rörelsehindrade personers möjligheter att röra sig i lokalerna inte hade tagit med i beräkning alls. Det är möjligt att detta inte kommer ge något annat än att kundens lokaler redan är välanpassade för rörelsehindrade, men eftersom ingen diskussion kring detta uppstått i samband med kravhanteringen så är det en outforskad aspekt av hur systemet skulle påverka denna grupp. Jag kan tänka mig att accessgrupper kan vara till bra hjälp för denna grupp, då man kan ge de access till korridorer och hissar som underlättar deras lokalåtkomst, men detta har inte reflekterats över. D.6.2 Reflektioner kring frågeställning 1 Undersökningen visar att IT-administratörer, som är den tänkta målgruppen för detta system, har exkluderats från att ge åsikter om projektet. Inte heller har någon hänsys tagits till hur systemet ska anpassas efter behoven hos fysiskt funktionsnedsatta. D.6.3 Reflektioner kring frågeställning 2 Den största aspekten hos systemet som skulle kunna påverkas av inkluderandet av ITadministratörer i skapandet av kravspecifikationen är användbarheten. IT-administratörerna är (troligen) experter på vad som gör deras IT-system enkla respektive svåra att använda. Det är fullkomligt rimligt att flera av de problem som IT-administratörerna upplever med det nuvarande systemet inte åtgärdas som en konsekvens av att deras synpunkter inte inkluderats i kravanalysen. Hade fysiskt funktionsnedsattas behov tagits i beaktande vid utformandet av systemet hade troligtvis funktionen för accessgrupper fått mer uppmärksamhet och spelat en mer central roll i utvecklingen av systemet. Sedan framkom även att det saknas mätbarhet för systemets säkerhet. Samtliga användare av systemet påverkas av dess säkerhetsprofil och därmed bör någon form av säkerhetsexpertis involveras i kravhanteringsprocessen. För att förbättra säkerhetsprofilen hos systemet behöver exempelvis autentisering undersökas huruvida den är robust nog (och eventuellt bör robustifieras) och systemets databas behöver krypteras för att inte läcka känslig information. Exakt vad som skulle förändras är oklart, eftersom denna analys inte skett i något större djup inom kravhanteringen. D.6.4 Reflektioner kring frågeställning 3 och 4 Genom att tvinga användaren av CSH att reflektera kring och besvara frågor som rör icke involverade parter och aspekter inom kravhanteringsprocessen så agerar CSH som en utmärkt utökning av klassisk kravhantering för att ta hänsyn till social hållbarhet. Klassisk kravhantering ter sig nämligen väldigt receptiv till utökade perspektiv kring social hållbarhet, då dessa designbegränsningar hjälper till att forma en produkt som är socialt hållbar. En tänkbar nackdel med CSH är att då det saknas en expert på användandet av CSH så kan bakgrunden till frågorna i tabell D.1 vara oklar och användandet av frågorna kan missförstås. 83

93 D.7. Slutsatser D.6.5 Undersökningens brister och potentiella förbättringar En naturlig utökning av denna undersökning är att ta kontakt med en IT-administratör hos kunden och sedan diskutera hur systemet som utvecklas ska formas för att passa deras behov och önskemål. I brist på bra möjligheter att kontakta dessa och på tiden som därför skulle krävas för denna kontakt så begränsas undersökningens omfattning. Det vore även av intresse att kunna revidera kravspecifikationen utifrån ovannämnda diskussioner. Det ter sig naturligt att sedan upprepa hela processen med att applicera CSH, hitta grupper att diskutera med och sedan revidera kravspecifikationen ett antal gånger. På detta sätt kan jag progressivt utöka omfattningen av de aspekter av social hållbarhet som kravspecifikationen tar hänsyn till. En annan begränsning av denna undersökning är att den utförts av en enskild individ som inte har någon tidigare erfarenhet eller utbildning inom användandet av CSH. Inte heller har jag någon utbildning inom systemteori. Detta begränsar omfattningen av den diskussion och de slutsatser som kan dras utifrån denna undersökning. Undersökningen skulle gynnas av att diskutera systemteori och CSH med en utbildad systemteoretiker. D.7 Slutsatser D.7.1 Frågeställning 1 Funktionsnedsatta och framförallt IT-administratörerna saknar tydligt en röst i framställningen av kravhanteringen. D.7.2 Frågeställning 2 Genom att involvera IT-administratörer förväntas användbarheten kunna förbättras eftersom de utgör systemets användare och besitter på expertisen om vad som utgör ett bra lokalhanteringssystem. D.7.3 Frågeställning 3 CSH ter sig som en väldigt lämplig utökning av kravhantering för att ta hänsyn till aspekter av social hållbarhet. D.7.4 Frågeställning 4 CSH ter sig som ett lämpligt verktyg för att utöka klassisk kravhantering för att ta hänsyn till aspekter av social hållbarhet, framförallt när det gäller identifierandet av persongrupper som (obefogat) exkluderats från att påverka kravspcifikationen. En tänkbar nackdel med att använda CSH är att det krävs en förståelse för ramverkets bakgrund för att kunna använda denna på ett effektivt sätt. 84

94 E Gustav Malmström Agil systemutveckling med Scrum i ett mindre projekt E.1 Inledning Det finns många sätt att jobba i ett projekt. Något de flesta metoder har gemensamt är att försöka underlätta och strukturera arbetet. Det kan kännas naturligt att utveckla och färdigställa en del i taget, innan man fortsätter med nästa del i projektet. En vanlig modell för att jobba på detta sätt kallas vattenfallsmodellen [89]. En annan projektmodell är att arbeta iterativt med begränsningar i form av tidsintervall. Scrum är en av de projektmodeller som syftar till att vara iterativ [90]. Gruppens arbete i projektet följde till en början vattenfallsmodellen när dokument skrevs. Efter några veckor valdes Scrum som iterativt ramverk. Planerna för gruppens iterativa processer hade tagits fram och iterationer i form av sprintar började användas. Att jobba iterativt var nytt för en stor del av projektgruppen. Därför var det av intresse hur gruppmedlemmarna upplevt att arbetet har gått och vilka erfarenheter som kunde tas med till framtiden. En intressant aspekt av gruppens sprintplanering var att sprintarna var olika långa, men minst en vecka långa. Gruppen tog beslutet att det var mer lämpligt att planera tiden för sprintar med avseende på de extra lediga dagar som vårens många helgdagar innebär. Till exempel så fick sprinten veckan efter påsk färre dagar. E.1.1 Syfte Syftet med denna rapport är att undersöka för- och nackdelar med att jobba agilt med hjälp av metoden Scrum i ett mindre mjukvaruprojekt. Undersökningen är en studie i hur projektmedlemmar upplevt att jobba med ett agilt arbetsätt och hur det har påverkat gruppens arbete. E.1.2 Frågeställning 1. Hur användes Scrum i vårt projekt? 2. Följde gruppen den plan som varje sprint hade? 85

95 E.2. Bakgrund E Hur är relationen mellan gruppens produktivitet och längden av en sprint? Avgränsningar Den data som används i rapporten kommer från enkäter och intervjuer som gruppmedlemmarna svarar på efter varje sprint. Rapporten håller sig till den agila processen Scrum då det inte fanns tillräckligt med tid i projektet att testa andra agila processer. Resultatet i undersökningen är baserat på kunskap från projektgruppens möten, dokument, observationer av arbetet och en enkät. Enkäten beskrivs mer i detalj i avsnitt E.4.4. Rapporten behandlar sprint 1 till 7, och även viss granskning av sprint 8. Detta på grund av att undersökningen behöver få in data från enkäter och att rapporten nästan färdigställts under sprint 8 och slutgiltigt sammanställts under sprint 9. Sprint 1, 2, 3 och 5 avviker något då knappt någon programmering skedde under dessa. Fokuset under dessa sprintar var istället dokumentskrivande och upplärning i de verktyg som projektet skulle använda. Därför kommer störst fokus i den här delen av rapporten ligga på sprintarna 4, 6 och 7. E.2 Bakgrund Projektet som ligger till underlag i undersökningen var uppdelat i flera iterationer, så kallade sprintar. Efter varje sprint utvärderade gruppen individuellt vad som gick bra, vad som gick mindre bra och anledningarna till detta. Den första iterationen i projektet skilde sig ifrån de efterkommande då den inte använde en agil process utan mer liknade vattenfallsmodellen. Anledningen till det är att gruppen under denna period skrev dokument, planerade arbetet och undersökte vilka arbetsprocesser projektet skulle välja att använda. E.3 Teori I detta avsnitt ges en teoretisk bakgrund till de begrepp och modeller som rapporten använder sig av. E.3.1 Agil mjukvaruutveckling Agil mjukvaruutveckling är ett samlingsnamn för ramverk och metoder som är baserade på principerna som förklaras i Manifesto for Agile Software Development [19]. Sammanfattningsvis säger det att man ska värdesätta anpassning till förändringar framför att följa en plan. Agilt arbetsätt värdesätter dem som gör det faktiska arbetet och att samarbetet mellan dessa ska fungera på bästa sätt. Namnet Agilt kommer från ideen att snabbt anpassa sig till förändringar i en växlande miljö [91]. E.3.2 Scrum Scrum är ett populärt ramverk för att arbeta agilt i större projekt [92]. Scrum möjliggör arbetstekniker så arbetsgruppen kontinuerligt kan förbättra produkten, projektgruppen och arbetsmiljön. Ramverket Scrum består av ett arbetslag (Team) som består av olika roller. Arbetslagets roller är: en Scrummästare, en produktägare, och utvecklingsteamet. Scrum rekommenderar fyra till tio personer i ett utvecklingsteam. Scrummästarens uppdrag är att se till att arbetslaget följer ramverkets processer. Produktägarens ansvar är att uppdatera backlogen och se till att den uppdateras när nya aktiviteter upptäcks. En iteration i Scrum kallas för en sprint. En sprint är vanligtvis mellan två och fyra veckor långa. Sprintar består av ett större planeringsmöte i början av sprinten och ett utvärderingsmöte i slutet. Under sprinten hålls korta dagliga möten, så kallade standup-möten, där varje gruppmedlem berättar vad som händer 86

96 E.3. Teori för att ge överblick för resten av gruppen. Det finns två Backlogs i Scrum, product backlog, som består av aktiviteter som ska göras i projektet och sprint backlog, som består av de aktiviteter som ska göras under den nuvarande sprinten. E.3.3 GitLab-tavlor GitLab-tavlor är ett webb-baserat verktyg integrerat i GitLab för samarbete inom ett projekt [93]. Projektet kan delas upp i flera tavlor och med hjälp av taggar kan aktiviteter sorteras till områden. Varje tavla kan delas upp i kolumner för olika status på aktiviteterna som ligger under dem. En aktivitet kan exempelvis läggas till på tavlan för den nuvarande sprinten och genom att sedan flytta aktiviteterna mellan kolumnerna kan utvecklingen av aktiviteten följas under sprintens gång. I figur E.1 ses ett exempel på en GitLab-tavla. De fyra kolumnerna används för att visa vilken status aktiviteten har. Om en aktivitet kör fast och en ny aktivitet plockas från To Do läggs aktiviteten som kört fast i On Hold för att visa att den är påbörjad men inte pågående. Figur E.1: Exempel på en GitLab-tavla. E.3.4 Scrum Burndown charts En burndown chart i Scrum är en graf som visualiserar hur arbetet framskridit under en sprint. På x-axeln är sprintens tid från start till slut och på y-axeln visas hur mycket arbete som är kvar. Vanligt mått är antalet aktiviteter kvar i sprinten eller hur många timmar som är kvar att lägga på sprinten [94]. I figur E.2 ses ett exempel på en burndown chart. Figur E.2: Exempel på en burndown chart. 87

97 E.4. Metod E.4 Metod Informationen för rapporten samlades via en litteraturstuide, gruppens egna erfarenheter av arbetsprocessen med informationen från sprintgranskningsenkäter och information från en enkät om hur upplevelsen varit att arbeta med sprintar, kompletterad av intervjuer. För att hitta allmän information och källor som inte är publicerade i vetenskapliga tidskrifter har Google använts. E.4.1 Litteraturstuide En litteraturstudie har gjorts för att jämföra gruppens arbetssätt med Scrum med vad publicerade artiklar skrivit om ämnet. För att hitta informationen till litteraturstudien har sökfunktionen i IEEExplore [95] använts, medsökord som Scrum och agile development. Efter sökningen gjordes ett urval bland träffarna genom att väga träffarnas rubriker mot varandra. En rubrik som var mer relevant för att besvara frågeställningarna prioriterades. Resultatens abstrakt användes sedan för att göra valet mellan de artiklar som ansågs intressanta utifrån det tidigare urvalet mot frågeställningen. Ifall artikeln fortfarande var intressant lästes artikeln och användes sedan eventuellt som källa i rapporten. E.4.2 Arbetsprocess För att få en bild av hur projektarbetet har genomförts har gruppens arbetsprocess sammanställts. För att göra detta har gruppens interna planeringsdokument för arbetet lästs, granskats och sammanställts tillsammans med författarens egna upplevelser av arbetet. E.4.3 Sprintgranskning För att undersöka hur arbetet gått i projektets sprintar hämtades information från interna dokument. Projektgruppen hade flera intressanta dokument som kan ge en bild av arbetet. För att visualisera arbetet grafiskt för hur en sprint genomförts har burndown charts skapats och använts. Dessa kunde smidigt skapas med hjälp av GitLab. Efter varje sprint har sprintgranskningar gjorts för att utvärdera arbetet. Detta har gjorts för att få bättre inblick i hur processer fungerade och ifall några förändringar behövt göras. Sprintgranskningen har i huvudsak bestått av två moment: en enkät om erfarenhetsuppfångst och ett kodgranskningsmöte. Burndown chart För varje sprint går det att få fram Burndown chart från GitLab-tavorna. Dessa har använts för att få en överblick över hur arbetet för sprintarna såg ut och hur arbetet utvecklades både under och mellan sprintarna [96]. Enkät - Sprintutvärdering Projektets kvalitetssamordnare gav ut en enkät efter varje sprint som gruppen svarade på. Fokus på enkäten var hur senaste sprinten hade gått och vad gruppmedlemmen skulle vilja förbättra till nästa sprint. Kvalitetssamordnaren sammanfattade sen enkätsvaren och ett kortare möte hölls med sammanfattning och diskussion kring dem. Dessa frågor var med i enkäten: 1. Hur tyckte du arbetet gick för gruppen överlag denna sprint? Med skala från: Arbetet gick mycket dåligt denna sprint. till: Arbetet gick mycket bra denna sprint., med en följdfråga för mer beskrivning. 88

98 E.4. Metod 2. Vad tycker du fungerade bäst inom gruppens arbete? Kort beskrivning. 3. Vad tycker du fungerade mindre bra inom gruppens arbete? Kort beskrivning. 4. Hur tyckte du arbetet som du var ansvarig för gick denna sprint? Med skala från: Arbetet gick mycket dåligt denna sprint. till: Arbetet gick mycket bra denna sprint., med en följdfråga för mer beskrivning. 5. Varför tror du det gick som det gick? Kort beskrivning. 6. Vad tycker du fungerade bäst inom ditt arbete? Kort beskrivning. 7. Vad tycker du fungerade mindre bra inom ditt arbete? Kort beskrivning. 8. Lärde du dig mycket nytt denna sprint? Med skala från: Jag lärde mig ingenting denna sprint. till: Jag lärde mig massa nya saker denna sprint., med följdfrågor om vad man lärt sig och vad anledningen till att lärandet gick som det gick. 9. Vad tror du att gruppen och du själv skulle kunna göra för att förbättra ditt lärande till nästa sprint? Kort beskrivning. Kort beskrivning var avsett som svar från 3 till 5 meningar. E.4.4 Enkätundersökning Gruppmedlemmarna svarade på enkäterna om hur arbetet och samarbetet fungerat under sprinten. Frågorna som besvarades i enkäten var: 1. Hur tyckte du det som helhet var att jobba med sprintar i Scrum? Textfråga med tanken att svaren skulle vara från 3 till 5 meningar. 2. Hur bra tyckte du gruppen följde de planer som sattes upp inför sprinten? Med skala 1 till 5 med följdfråga vad som hade kunnat göras bättre. 3. Hur bra koll hade du på vad ditt ansvar var under sprinten? Med skala 1 till 5 med följdfråga vad som hade kunnat göras bättre. 4. Hur bra koll hade du på de andra gruppmedlemmarnas aktiviteter under sprinten? Med skala 1 till 5 med följdfråga hur viktigt det ansågs att det var och vad som hade göras för att få bättre koll på det. 5. Hur bra funkade samarbetet med integrationen mellan undergrupperna (databas, server & frontend) under sprinten? Med skala 1 till 5 med följdfråga vad som hade kunnat göras bättre. 6. Hur mycket använde du tavlorna i GitLab? Med skala 1 till 5 med följdfråga vad som hade kunnat göras bättre. 7. Tyckte du tavlorna borde använts mer eller mindre? Med skala 1 till 5 med följdfråga vad som hade kunnat göras bättre. 89

99 E.5. Resultat E Hur bra struktur tyckte du sprinten hade? Med skala 1 till 5 med följdfråga vad gruppen hade kunnat vinna mer på att strukturera upp bättre. 9. Föredrar du längre eller kortare sprintar? Med skala 1 till 5 med följdfrågor om hur produktiviteten påverkades av längden på sprinten och vad som ansågs om de varierade längderna på projektets sprintar. Kompletterande intervju till enkätundersökningen För att komplettera svaren på enkätundersökningen i avsnit E.4.4 hölls intervjuer med gruppmedlemmar. Dessa intervjuer användes för att säkerhetställa att de som svarade på enkäterna uppfattade frågorna på samma sätt som författaren. E.5 Resultat I detta avsnitt kommer resultatet redovisas utifrån de metoder som beskrivits i avsnitt E.4. E.5.1 Arbetsprocess Projektgruppens arbetsprocess har varierat mycket under projektet. Till en början arbetade gruppen efter en löst definerad vattenfallsmodell tills en plan för iterationer togs fram och arbetet övergick till att arbete i sprintar med Scrum som modell. Den första tiden när gruppen arbetade efter vattenfallsmodellen var arbetsprocesser på väg att skapas och allt fokus låg på att skriva de första dokumenten. Gruppen hade väldefinierade mål att jobba efter, men målen var dock väldigt stora, som till exempel: Skriv klart projektplanen. Då arbetsprocesserna för Scrum hade skrivits och börjat användas startade gruppen sin första sprint. Det var första gången som flertalet av gruppmedlemmarna jobbade efter en iterativ arbetsprocess. Det blev en ny upplevelse för många. För varje sprint gruppen jobbade förbättrades processer och rutiner kring dessa. E.5.2 Sprintgranskning För att redovisa ett resultat från projektets sprintar beskrivs arbetet under sprinten och vad som gjorts under sprinten. De första sprintarna kommer granskas som en enda stor sprint, detta då processer för arbetet inte varit helt genomarbetade och arbetet mest bestod av att skriva dokument. Sprint 1, 2 och 3 Sprint 1, 2 och 3 bestod av att skriva dokument och ta fram processer för arbetsgången. I slutet av sprint 3 skedde lite kodande, men då till stor del för att påbörja upplärningen av programmeringsspråk och ramverk. Sprint 4 Sprint 4 var gruppens första sprint med kodningsdelen av mjukvaruutvecklingen i fokus. Målet för sprinten var att ta fram en prototyp med alla de reader-funktionaliteter som ska användas i programmet. Sprinten nådde sitt mål och en prototyp med reader-funktionaliteten kunde presenteras för kunden. Burndown charten i figur E.3 visar framfarten av aktiviteter för sprinten. GitLab-tavlan hade ganska få aktiviteter i början av sprinten men i mitten tillkom 90

100 E.5. Resultat många nya aktiviteter. Sprint 4 var en längre sprint som sträckte sig över två veckor, på ca 10 arbetsdagar. 91

101 E.5. Resultat Figur E.3: Burndown chart från sprint 4. Sprint 5 För Sprint 5 var fokus att skriva kandidatrapporten och därför uppstod ett avbrott med kodandet. Burndown charten är inte intressant för denna sprint då GitLab-tavlorna inte användes. Även denna sprint, likt sprint 1, 2 och 3, hade stora aktiviteter som: Skriv klart första avsnitten på individuella delen vilka bedömdes att GitLab-tavlorna inte gav ett mervärde till. Sprint 5 var fem arbetsdagar lång. Sprint 6 Målet för sprint 6 var att ta fram en prototyp med alla de approver-funktionaliteter som ska användas i programmet. Sprinten nådde sitt mål och en prototyp med approver-funktionaliteten kunde visas för kunden. I Burndown charten i figur E.4 visar framfarten av aktiviteter för sprinten. Inför denna sprint kan man se i figuren att det hade definierats fler aktiviteter i starten av sprinten. Sprint 6 var planerad att vara fem arbetsdagar lång, men då några gruppmedlemmar ville arbeta över helgen så syns aktiviteter för sprinten senare än sprintens slut i burndown charten. Sprint 7 Målet för sprint 7 var att ta fram en prototyp med alla de Admin-funktionaliteter som ska användas i programmet. Alltså skulle denna prototyp kunna göra allt som förväntas av Figur E.4: Burndown chart från sprint 6. 92

102 E.5. Resultat produkten. Denna sprint var gruppens kortaste på endast 3 dagar, men då några gruppmedlemmar ville arbeta över helgen så syns aktiviteter för sprinten senare än sprintens slut i burndown charten. Gruppen upplevde att det blev lite stressigt med en så pass kort sprint. Vissa processer fick inte heller plats under sprinten, så kodgranskning blev istället i starten av sprint 8. I Burndown charten i figur E.5 ses framfarten av aktiviteter för sprinten. Figur E.5: Burndown chart från sprint 7. Sprint 8 För sprint 8 var fokus att skriva klart kandidatraporten vilket gjorde att det blev ett avbrott i programmeringen. Då rutiner för GitLab-tavlorna hade förbättrats användes tavlan till skillnad från den tidigare dokumentsprinten, sprint 5. Burndown charten i figur E.6 visar framfarten av aktiviteter, det är ganska jämt under hela sprinten, detta beror på att i starten av sprinten skapades för stora aktiviteter för att vara användbara men under sprintens gång delades de upp till mindre mer användbara aktiviteter. Sprint 8 var fem arbetsdagar lång. Figur E.6: Burndown chart från sprint 8. Sprint 9 feature freeze Sprint 9 är slutspurten av projektet och då denna rapport skrivs under arbetets gång kommer denna sprint inte hinna granskas i rappporten. Gruppen kontrollerade under sprint 9 att alla prioritet 1-krav var uppfyllda. Under denna sprint hade gruppen sin feature freeze. 93

103 E.6. Diskussion E.5.3 Enkätundersökning Enkäten som beskrivs i avsnitt E.4.4 visade en uppskattning av Scrum och det det iterativa arbetssätt gruppen följde under projektets gång. Många ansåg att det passade strukturen på projektet och att det var skönt med korta deadlines att jobba efter. Planen som sattes inför sprintarna följdes bra men många hade velat ha mer planering i början av sprintarna. De som svarade ansåg att de hade bra koll på sitt ansvarsområde men tyckte att GitLab-tavlorna skulle användas mer i arbetet. Hur påverkades din produktivitet av längden på sprinten? Svaren på frågan var lite varierade, vissa ansåg att det blev bättre med en längre sprint och vissa tvärt om. Majoriteten tyckte sprintar på 6 till 9 dagar var optimalt. Vad anser du om att ha varierande längder på sprintarna? Svaren var lite varierade på denna fråga, några ansåg att det inte påverkade produktiviteten medan andra ansåg att det fanns en optimal längd för sin egna produktivitet. Många ansåg att det var bra att sprintarna i projektet varierade då det gav gruppen erfarenhet om hur produktivitet kan variera med varierande längder på sprintar. Det uppfattades också som positivt att variera sprintar efter hur mycket arbete som skulle göras och att passa in sprintar efter hur det passar med extra lediga dagar, till exempel röda dagar. E.5.4 Kompletterande intervju till Enkätundersökning En kort intervju om hur frågorna tolkades hölls. De intervjuade hade uppfattat frågorna och svarat på dem likt det sätt som var tänkt när de skrevs. E.6 Diskussion A. Mundra et al. [97] redogör för hur de tycker en grupp inom Scrum ska vara strukturerad och fungera. Enligt författarna är anledningen till Scrums popularitet förmågan att vara flexibel och förmågan att anpassa sig till förändringar i krav. Författarna skriver att en grupp ska bestå av en Scrummästare, en produktägare, max sex stycken utvecklare och en heltidstestare. Vidare skriver de att även specialistrollen kan användas om gruppen kräver extra kompetens inom något område, några exempel de ger på dessa roller är arkitekt och UI-designer. Författarna tycker att det ger en lagom gruppstorlek på maximalt tio personer eller, som de skriver, tillräckligt många för att få plats i ett rum. De skriver att för att jobba som bäst i Scrum ska det vara små och samlade grupper. Författarna anser att produktägaren är den viktigaste rollen inom gruppen då de menar att den för arbetet framåt och ger ett perspektiv från kunden. Artikeln tar upp att en Scrumgrupp ska ha minst en testare per tre utvecklare. Det mål de vill att testaren ska ha är inte att försöka förstöra produkten utan hjälpa utvecklarna att andvika att göra kritiska fel. Om man jämför projektgruppens arbete med det beskrivet i [97] så finns både skillnader och likheter i arbetsprocessen. Gruppen i projektet är strukturerad annorlunda mot vad som beskrivs i artikeln; den största skillnaden var att hela gruppen hade rollen som utvecklare där Scrummästaren också utvecklade. Även rollen som testare var anorlunda då den togs av hela gruppen där alla gruppmedlemmarna skrev tester för sin egna kod istället för en dedikerad testare för gruppen. En annan stor skillnad är att projektet inte haft någon produktägare, den rollen har istället delats mellan projektmedlemmarna. Alla i gruppen har varit med i framtagningen av aktiviteter och har kunnat lägga till aktiviteter till backlogen under projektets gång. Testtrollen har också sett annorlunda ut ifrån gruppens perspektiv då istället för en testare har en testansvarig sett till att de andra utvecklarna skrivit tester och rapporterat in 94

104 E.6. Diskussion vad de testat. Gruppmedlemmarna hade ansvarsområden på ett sätt som liknar det artikeln beskriver kring specialistroller. R. T. Hans [98] skriver om hur Scrum har testats i projekt för studenter. I projekten som författaren har granskat är ofta Scrummästaren för projektgruppen inte en student utan till exempel en mentor eller lärare för gruppen. Projekten som inte leds av studenter hade svårare att jobba agilt. Artikeln har jämfört hur arbetet såg ut mot grupper där studenter själva har fått agera Scrummästare och noterat hur dessa hade fungerat. Författaren drar ingen konkret slutsats utöver att författaren sett mönstret att grupperna fungerat bättre och fått bättre resultat med en student som Scrummästare. Det ska ha gett de egenledda grupperna chans att friare hitta metoder och processer som fungerar för gruppen. Om man jämför hur arbetet i projektet har varit strukturerat med vad som skrivs i [98] så fås en förståelse varför projektgruppen släpptes så pass fri för att hitta egna metoder och processer i projektarbetet. I min mening så har projektet tjänat på denna frihet, både för själva projektarbetet och för erfarenheter av hur en grupp ska strukturera ett projekt. En intressant utökning av artikelns undersökning skulle vara ifall det som i detta projekt finns en handledare som stöd för gruppen och hur detta kan påverka en grupps agila arbete. E.6.1 Enkätundersökning Enkätundersökningen hade som mål att ge en bättre inblick i vad gruppen tyckte om det agila utvecklingssättet som helhet. Det kom inte som en överraskning att åsikterna om Scrum var positiva då gruppen reflekterat och pratat om det på möten och arbete under projektets gång. Det finns flera sätt att förbättra undersökningen, ett exempel på förbättring skulle vara att ha fler frågor med flervalsalternativ istället för fritextalternativt som komplement till fritexten. Egna erfarenheter av enkäter säger att det blir bättre för respondenten att svara på frågor ställda på detta sätt och på så sätt kan det bli lättare att dra slutsatser från enkäten. E.6.2 Intervju Intervjuerna som hölls var väldigt korta, men uppfattningen av dem var att de ändå var nyttiga att hålla. De som intervjuades hade liknande uppfattning om frågorna som tanken var när de skrevs vilket var positivt för resultatet från enkäten. E.6.3 Analys av resultatet Resultatet av rapporten visar att projektgruppen har uppskattat att arbeta efter Scrummodellen. Gruppen har haft möjlighet att agera flexibelt mot problem som dykt upp under sprintar och de aktiviteter som inte hunnit med under en sprint har inte glömts bort då de flyttats till backloggen av nästa sprint. Utvärderingarna som gruppen gjort efter sprintarna verkar ge resultat då arbetet och processerna inom gruppen har kunnat förändras och arbetet har flutit på bättre och bättre under projektets framfart. Sprintmål har hjälpt gruppen att fokusera på vad som var viktigt för iterationen. E.6.4 Burndown charts I graferna som presenterades i avsnitt E.5.2 ses skillnader mellan sprintar där kurvan lutar mer konsekvent nedåt i de senare sprintarna. Det syns i de tidigare sprintarna att flera aktiviteter skapades under sprinten och i de senare skapades majoriteten i början av sprintarna. Gruppens processer för sprintplanering upplevdes som bättre under arbetets gång och graferna överensstämmer med detta. 95

105 E.7. Slutsatser Det som inte syns i graferna är hur stor en backlog var för en sprint. Detta hade varit intressant att veta då det hade gett mer inblick hur många aktiviteter som inte hanns med. Det hade också varit intressant att se hur många aktiviteter som skapats och stängts under sprinten. Graferna i rapporten visar bara summan av aktiviteter per dag men under arbetet observerades att i många sprintar skapades och avslutades flera aktiviteter under sprintens gång vilket tyvärr inte syns så tydligt i graferna. Någon form av kompletterande graf över skapade och avslutade aktiviteter hade förbättrat resultatet. Med tidsuppskattning för en sprint skulle det gå att skapa en annan sorts burndown chart där tidsåtgång per aktivitet ligger på x-axeln istället för antalet aktiviteter. E.6.5 Problem och förbättringar Projektgruppen stötte på vissa problem under projektarbetet. Under de tidigare sprintarna användes GitLab-tavlorna inte så mycket och de aktiviteter som fanns var så stora att det var mer mål än aktiviteter. Gruppen saknade vissa processer för arbetet och de som fanns följdes inte som planerat. Men i takt med projektarbetets framfart fungerade sprintarna bättre och processer började följas och förändrades för att passa gruppens behov. Även GitLab-tavlorna började användas mer. Något som kan förbättras är tiden det tar för gruppen att hitta dessa processer som fungerar, en lösning skulle vara att ha flera små korta sprintar i starten av projektet för att testa flera olika processer tidigt. E.7 Slutsatser Här dras slutsatser och ges svar på frågeställningarna utifrån avsnitt E.4 och E.5. E.7.1 Frågeställningar Här dras slutsatser på frågeställningarna som togs upp i avsnitt E.1.2. Hur användes Scrum i vårt projekt? Hur gick det? Vilka delar av Scrum användes och vilka valdes bort? De fösta sprintarna handlade om att skapa processer för Scrum och att skriva dokument. Projektgruppens arbete med Scrum kom först igång under sprint 4 och tog full fart vid sprint 5. Sprintarna i projektet varierade mellan att vara två veckor och tre dagar långa, något som berodde på att gruppen satte upp olika stora sprintmål som bedömdes kräva olika mycket tid. De kortare arbetsveckorna på grund av alla röda dagar i april och maj spelade också in i beslutet då projektgruppen ville försöka undvika att ha sprintar över långhelger. Delar som dagliga standup-möten i gruppen valdes bort då det bedömdes för tidskrävande att samlas hela gruppen. Med det distansläge som projektet tog under period två av terminen så skulle dagliga standup-möten inte varit lika tidskrävande och lokalberoende men de valdes ändå bort då gruppmedlemmarna kände att de hade tillräcklig med insyn i vad de andra gruppmedlemmarna gjorde. Gruppen använde sig inte av tidsuppskattning av aktiviteter när de skapades. Följde gruppen den plan som varje sprint hade? Metoden Scrum följdes till stor del, men vissa kompromisser gjordes. Den största kompromissen var att gruppen saknade produktägare. Istället agerade hela gruppen produktägare då alla föreslog aktiviteter för att klara de sprintmål som gemensamt satts. Under sprinten fick projektmedlemmar lägga till aktiviteter till GitLab-tavlan utan att gruppen haft något planeringsmöte vilket inte följer metoden Scrum. Utöver dessa kompromisser av Scrum bedöms gruppen ha följt Scrums arbetsmetodik. 96

106 E.7. Slutsatser Hur är relationen mellan gruppens produktion och längden av en sprint? Överlag verkade inte variation på sprintars längd påverka produktiviteten hos gruppen. Något som påpekades vid den kortaste sprinten på tre arbetsdagar var att det kändes stressigt men gruppen klarade fortfarande av sitt sprintmål. Det negativa med så korta sprintar var att vissa processer som kodgranskning inte hann hållas under sprinten. Gruppens upplevelse av sprintar på fem till tio arbetsdagar var väldigt lika och produktiviteten under dessa upplevdes som lika stor. E.7.2 Övergripande slutsatser De generella slutsatser som kan dras i rapporten är att projektgruppen ansåg att projektet lämpade sig att arbeta efter modellen Scrum och att projektgruppen uppskattade att arbetet följde den modellen. Valet att inte ha en produktägare har fungerat för gruppen även om det var en rekommendation att ha den rollen i undersökningarna. Det förbättringsförslag som gruppen kommer ta med sig till framtida projekt är att ta fram processer tidigare men framförallt följa dessa mer noggrant då gruppen upplevt att dessa processer bidrar till ökad produktivt i arbetet. 97

107 F Anders Ryefalk React med och utan Redux F.1 Inledning Webbapplikationer blir viktigare och viktigare i dagens uppkopplade samhälle. Intresset för dessa applikationer grundar sig i att arkitekturen medför ett antal önskvärda egenskaper. Ett exempel på en önskvärd egenskap är portabilitet. Portabiliteten härstammar från att alla system som har tillgång till en modern webbläsare kan köra samma kod. Egenskapen gäller även koden som körs på den server som tillhandahåller hemsidan. Även detta blir mer och mer portabelt genom bland annat utveckling av verktyg som till exempel Docker. Då väldigt mycket av arbetet med att göra kod kompatibel med hårdvara görs genom ramverk och bibliotek blir koden väldigt lätt att underhålla (om det ramverk som används överlever den konstant snabba utvecklingen). I takt med att intresset växer, växer även komplexiteten hos applikationerna i sig. När en webbapplikation växer blir det svårare och svårare att hantera applikationens tillstånd, vilket ofta kan leda till svårlösta buggar [99]. En lösning som många valt att använda idag är React tillsammans med Redux [100]. F.1.1 Syfte Syftet med denna undersökning är att ta fram för- och nackdelar med att använda tillståndshanteraren Redux tillsammans med React. Detta jämförs med att bara använda React utan en extern tillståndshanterare. F.1.2 F.1.3 Frågeställning 1. Hur kan Redux användas för att skapa bättre kodstruktur? 2. Reducerar Redux antalet svårlösta buggar i ett projekt? 3. Vilka anledningar finns det till att välja att inte använda Redux i ett projekt? Avgränsningar Rapporten kommer endast att beröra Redux tillsammans med React och inte Redux som ett fristående ramverk. Projektets medlemmar har ingen tidigare erfarenhet av Redux. Detta kommer antagligen att påverka delarna av undersökningen som rör egen implementation. 98

108 F.2. Teori Resultaten och diskussion kommer i huvudsak utgå från detta projekt för att minska omfattningen. F.1.4 Ordlista 1. boilerplate är kod som är på en låg abstraktionsnivå. 2. const är ett nyckelord i React som innebär att värdet hos en variabel inte kan förändras endast ersättas. Exempelvis allokeras en ny lista istället för att uppdatera den existerande. 3. Docker är ett program till för att köra virtuella miljöer. 4. hook är en funktion i React som returnerar en referens till ett const objekt. 5. payload är data som skickas med i en request, i Redux fall en action. 6. scope är en del av ett program där en variabel är definierad. F.2 Teori I detta avsnitt finns grundläggande läsning till de resultat som diskuteras. Här kommer endast aspekter av React som är relevant för Redux tas upp. För vidare grundläggande läsning finns välskriven dokumentation för React. [101] F.2.1 React React har två huvudsakliga sätt att definiera komponenter. Det klassiska sättet är med klasser som i listing 4. Här definieras en klass som tar in props (argument) till en konstruktor som skapar komponentens interna tillstånd. Detta tillstånd kan sedan uppdateras med funktionen setstate. Klassen innehåller alltid funktionen render som används när React vill veta hur komponenten ska ritas ut. class acomponent extends React.Component { constructor(props) { super(props); this.state = { mydata: 1 }; } //... somemethod() { this.setstate({ mydata: props.data }); } //... render() { <div></div> } } Listing 4: Klassexempel Samma funktionalitet kan från och med React 16.8 även skrivas med funktionella komponenter och React Hooks [102]. I listing 5 definieras istället två const-referenser med hjälp av en hook, usestate. I detta fall motsvarar thing objektet this.state från listing 4. setthing är en referens till en funktion med samma syfte som this.setstate. Då komponenten i detta fall är en funktion och inte en klass så ersätts render med en return med samma innehåll. 99

109 F.2. Teori function afunctioncomponent(props) { const [thing, setthing] = usestate({ mydata: 1 }); //... somemethod() { setthing({mydata: props.data}); } //... return ( <div></div> ); } export default afunctioncomponent; Listing 5: Hooksexempel F.2.2 Redux Redux är ett Javascriptramverk för tillsåndshantering för webbapplikationer som kan användas helt fristående [103]. Redux gör det lätt att identifiera hur applikationens tillstånd förändrts och vad som orsakade denna förändring. Redux uppnår detta genom att sätta ett antal regler. Tillståndet måste vara immutable. Det betyder inte att tillståndet inte kan uppdateras, men det betyder däremot att komplexa datatyper som till exempel listor inte får återanvändas med nytt innehåll, istället måste ett nytt objekt skapas och sparas. Alla förändringar av tillståndet måste göras genom en action. Dessa hanteras av en reducer som definierar hur en given action förändrar tillståndet. reducern måste vara en funktion utan sidoeffekter (eng. pure function) [104]. Komponent dispatch useselector action reducer store Figur F.1: Schematisk bild av Redux arkitektur. Store Redux store innehåller hela applikationens tillstånd (eller åtminstone det som behöver delas mellan komponenter). Det implementeras ofta som en trädstruktur, med vanliga Javascriptobjekt (JSON format). Här knyts reducers och eventuell mellanvara samman. Den tillhandahåller även metoder för att skicka actions och för att plocka ut state [104]. Mer om hur detta går till i kod under rubriken React-Redux. 100

110 F.3. Metod Actions Actions är definierade som JavaScript-objekt. Dessa definierar vad vi önskar göra med applikationens tillstånd. De måste alltid innehålla fältet type för att en reducer ska kunna veta hur den ska uppdatera tillståndet. Utöver detta kan användaren definiera ett antal ytterligare fält med information som reducern kan använda. Dessa kan ha vilka namn som helst men praxis är att använda fältet payload för extra information som skickas med. Actions kan definieras direkt i koden där de skickas till Redux, men oftast används action creators, som är funktioner som returnerar action-objekt. Detta bidrar till bättre inkapsling och lättare läsning av koden [104]. Reducers Reducers är som tidigare nämnt bara funktioner utan sidoeffekter. De tar in en action som ett argument och utifrån de givna reglerna så returnerar den det uppdaterade tillståndet. Notera att inget händer med det gamla tillståndet; objektet det är sparat i förändras inte, men det ersätts i Redux store. Att skriva en reducer för hela applikationen är möjligt men det blir lätt oöverskådligt. Därför används ofta funktionen combinereducers. Denna kombinerar flera olika reducers och ser till att en action kommer till rätt funktion. Detta gör att koden kan delas upp baserat på vilken del av Redux store en reducer behöver arbeta på [104]. Mellanvara Mellanvara är programvara som appliceras på varje action innan den skickas till sin reducer. Här kan både egenskriven kod och mellanvara från bibliotek användas. Vanliga användningsområden för detta är loggning, och möjligheten att definiera asynkrona actions (med hjälp av till exempel Thunk som kommer tas upp senare) [104]. F.2.3 React-Redux React och Redux kan effektivt användas genom API:et react-redux [105]. Detta API skapar språkbindningar (eng. language bindings) mellan React och Redux. Språkbindingar är bara en teknisk term för att React tillhandahåller nyckelord i sin egen syntax som gör att applikationen kan interagera med Redux. Som nämnts tidigare finns det två huvudsätt att använda React: klass- och funktionskomponenter. Detta förändrar även hur komponenterna interagerar med Redux på några väsentliga punkter. All annan kod, actions, reducers och store är likadan oberoende av vilken arkitektur som väljs, vilket gör den användbar oavsett. I projektet har React-hooks använts, så kontrasten mellan användning av antingen endast Hooks eller dessa i kombination med Redux är vad som kommer att undersökas i resterande delar av rapporten. F.3 Metod Undersökningen innehåller två huvuddelar. Dels ett försök att implementera Redux i gruppens projekt och dels att göra en bedömning av hur det påverkat kodbasen. Detta kommer att göras utifrån kvalitetsmåttet underhållbarhet. Detta innebär att följande parametrar kommer att undersökas: 1. Läsbarhet 2. Förståelse för vad som pågår i applikationen som helhet. 3. Hur lätt är det att expandera projektet med ny funktionalitet? 101

111 F.4. Resultat Information för hur Redux bör implementeras i projektet kommer att samlas in från ramverkens dokumentation, artiklar, videor, och forum där problem som uppstått i andra projekt diskuteras. Under tiden kommer experimentella implementationer göras för att se vilken information som är lämplig att använda i projektet. F.4 Resultat Då det inte finns ett lämpligt sätt att referera till källor mitt i ett kodexempel så kommer källorna istället presenteras i en summering i detta stycke. All relevant information kan hittas i React-Redux dokumentation [105], men det finns några andra källor som hjälpte till med förståelsen. Till att börja med kommer en god grundförståelse från en video som summerar ämnet väl [106]. Videon är dock ifrån när hooks inte ännu var introducerat till React, så hur interaktionen med komponenter går till fick istället hämtas från en annan källa. Detta hämtades då från två olika artiklar som går igenom hur Redux kan uppdateras till att använda hooks [107] och hur det kan användas tillsammans med Thunk [108]. Men det saknas information i artiklarna om hur felhantering kan se ut när actions struktureras med action creators, vilket beskrivs väldigt tydligt och väl i Redux egen dokumentation om att reducera mängden boilerplate [109]. I listing 6 definieras Redux store. initialstate definierar ingångsvärdena för applikationen. Dessa kan även definieras för varje reducer som kan hittas i listing 9. I listing 7 definieras en reducer som skapats med funktionen combinereducers, med denna kan vi som nämndes i teorin kombinera flera reducers. Sist tar applikationen in mellanvara, dessa kan listas under middleware och appliceras med applymiddleware(). För att debugga kan Redux devtools användas, dessa läggas då till med hjälp av compose() och en installering i webbläsaren. import {createstore, applymiddleware, compose } from 'redux'; import thunk from 'redux-thunk'; import rootreducer from './reducers'; const initialstate = {}; // Thunk is used to be able to make async calls in actions. const middleware = [thunk]; /** * Sets up the store, and conects it so that Redux devtools may be used. */ const store = createstore( rootreducer, initialstate, compose( applymiddleware(...middleware), window. REDUX_DEVTOOLS_EXTENSION && window. REDUX_DEVTOOLS_EXTENSION () ) ); export default store; Listing 6: store.js Actions definieras som tidigare nämnt som JavaScript objekt. Type har i projektet definierats som konstanter med samma namn som text-strängen de innehåller, vilket minskar frekven- 102

112 F.4. Resultat import {combinereducers} from 'redux'; import reducer from './reducer'; import otherreducer from './ohterreducer'; export default combinereducers({ things: reducer, otherthings: otherreducer, }); Listing 7: rootreducer.js sen av stavfel. Stavfel kan nämligen leda till att en action misstolkas. Den kan läsas som en annan action eller inte existera i reducern, så den går till default. Båda dessa fall leder till en inkorrekt uppdatering. I listing 8 så finns exempel på två typer av action creators. De vanliga som returnerar en action direkt, dessa skickar endast in en type till reducern och eventuellt extra data för att använda i applikationens tillstånd. Den andra typen kräver att mellanvaran Thunk används. Här skickas data in och funktionen returnerar en funktion, istället för ett action objekt. Denna funktion fångas då upp av Thunk där den får in argumentet dispatch. Dispatch skickar en action till store och reducers på samma sätt som kan göras direkt från en komponent. Detta ger möjligheten till att använda asynkrona funktioner eller att processera den data som skickas med ytterligare innan den skickas till reducers. I detta fall visas ett exempel på hur det kan se ut i projektet där en action skickas före funktionen så det syns att den startat. Sedan kommer en sucess eller fail action att skickas när det asynkrona anropet är klart. export const ACTION_NAME = 'ACTION_NAME' export const actionname = (data) => { return { type: ACTION_NAME, payload: data } } export const ASYNC_ACTION_NAME = 'ASYNC_ACTION_NAME' export const ASYNC_ACTION_NAME_SUCCESS = 'ASYNC_ACTION_NAME_SUCCESS' export const ASYNC_ACTION_NAME_FAIL = 'ASYNC_ACTION_NAME_FAIL' export const asyncactionname = (data) => async(dispatch) => { dispatch({type: ASYNC_ACTION_NAME}) someasyncfunction(data).then(response => dispatch({ type: ASYNC_ACTION_NAME_SUCCESS, payload: response })).catch(error => dispatch({ type: ASYNC_ACTION_NAME_FAIL, payload: error })) } Listing 8: actions.js I listing 9 kan vi se ett exempel på en reducer som tar hand om de actions som finns i listing 8. Här visas endast att båda de actions som tidigare definierats sparar sin payload i data1 och da- 103

113 F.4. Resultat ta2. Dessa kan självklart sparas i godtyckliga JavaScript objekt. Dessa bör dock definieras på något sätt i initialstate så att de inte saknas när komponenterna som använder dem renderas. Det är också god praxis eftersom det gör det tydligare vad reducern arbetar med för data. Flaggan loading är ett sätt att visa till exempel en spinner för att visa att applikationen väntar på något. Error kan användas dels för att visa något för användaren direkt om vad de gjort för fel, men kan också användas för att se vad som gått fel genom felsökning med Redux dev tools. import { ACTION_NAME ASYNC_ACTION_NAME ASYNC_ACTION_NAME_SUCCESS ASYNC_ACTION_NAME_FAIL } from './actions.js' const initialstate = { loading: false, error: null, data1: {}, data2: {}, } export default function(state = initialstate, {type, payload}) { switch(type){ case ACTION_NAME: return {...state, data1: payload } case ASYNC_ACTION_NAME: return {...state, loading: true, error: null, } case ASYNC_ACTION_NAME_SUCCESS: return {...state, loading: false, data2: payload } case ASYNC_ACTION_NAME_FAIL: return {...state, loading: false, error: payload, } } } Listing 9: reducer.js I listing 10 finns en enkel exempelkomponent som använder sig av de två actions som definierats i listing 8. För att kunna skicka en action till applikationens store används dispatch. Denna hämtas genom en hook usedispatch som ger en funktionsreferens. Till denna funktion 104

114 F.4. Resultat skickas en action. somedata och asyncinfo är exempel-data som egentligen ska komma från någon annanstans, men fungerar för detta exempel. Sedan har vi två vanliga sätt att använda actions. Först genom useeffect som kallas på när dispatch förändras. Dispatch förändras endast när komponenten laddas in första gången, men useeffect körs även vid rendering om något annat av funktionens argument ändras. Detta gör att till exempel en asynkron funktion kan kallas på, för att hämta data från en server. Dynamisk information kan då visas när komponenten renderas. En action kan också köras av en subscription som till exempel onclick i komponenten som renderas. import React, { useeffect, usestate } from 'react' import { usedispatch, useselector } from 'react-redux' import {actionname, asyncactionname } form './actions' mycomponent(props) { const dispatch = usedispatch(); const data1 = useselector(state => state.things.data1); const data2 = useselector(state => state.things.data2); const [somedata, ] = usestate({...}) //some interesting data const [asyncinfo, ] = usestate({...}) //some interesting data useeffect(() => { dispatch(asyncactionname(asyncinfo)) }, [dispatch]) return ( <div> somecodethatshowsdata1(data1) somecodethatshowsdata2(data2) </div> <button onclick={actionname(somedata)})> Save some data </button> ) } export default mycomponent; Listing 10: component.js I projektet användes endast mellanvaran thunk. Det fanns planer på att använda egenskriven mellanvara för bland annat loggning. Detta prioriterades dock ner då det fanns viktigare funktioner som var kravsatta. Mellanvara är dock en viktig del i Redux så detta kommer beskrivas utifrån ett välskrivet kapitel om mellanvara i en bok om Redux. För att Redux ska godta mellanvaran behöver den följa den korrekta funktions signaturen ses i listing 11. Store är helt enkelt applikationens tillstånd och kan användas för att ta beslut utifrån det föregående tillståndet eller titta på det nya. Next används för att skicka vidare den action som dispatchas så den kan hanteras av resterande mellanvara och till sist reducern. Action är en helt vanlig Redux action som exemplifierats tidigare i rapporten. Med denna mall kan all mellanvara skrivas. Kom även ihåg att även om bara type och payload är de enda element som omnämnts tidigare kan vilka taggar som helst skickas med i en action. Så behöver mellanvaran någon metadata är det bara att skapa en ny tagg och skicka med den, om det inte känns som att datan hör hemma i payload. [110] 105

115 F.4. Resultat const logger = store => next => action => { console.group(action.type); console.log('dispatching: ', action); const result = next(action); console.log('next state: ', store.getstate()); console.groupend(action.type); return result; }; export default logger; Listing 11: middleware.js 106

116 F.5. Diskussion F.5 Diskussion Här kommer resultatet att diskuteras utifrån rapportens frågeställningar och metoden kommer utvärderas. F.5.1 Metod Det fungerade väl att hitta information om React och Redux då det finns väldigt många artiklar om dem, men den var ofta för hur Redux interagerar med klasser och inte hooks eftersom det är ett relativt nytt tillägg i React. Detta gjorde att det var svårare att samla in information för att kunna börja implementera Redux i projektet, eftersom kodbasen var skriven med hooks. Det rena överflödet av information gjorde att det i början var svårt att veta vad som var mest lämpligt för projektet. Men när det väl var tydligt vad skillnaderna mellan de olika tankesätten var för uppdelningen av Redux koden, gick det väldigt bra att lägga till Redux i projektet. Processen att extrahera kod och tillstånd till Redux gick väldigt lätt och smärtfritt, och det blev lättare och lättare alt eftersom gruppen lärde sig mer och boilerplate extraherades från både komponenter och Redux kod. F.5.2 Fråga 1 - Hur kan Redux användas för att skapa bättre kodstruktur? Mängden boilerplate och bakgrundslogik som tidigare skrevs direkt i komponenten har kunnat abstraheras ut till funktioner i Redux istället. Detta har märkts mest där asynkrona anrop till server använts för att hämta dynamisk information. Dessa blir ofta stora och innehåller felhantering med mera som inte behöver synas i komponenten. Det blir ofta bättre för läsbarhetens skull att visa en enkel fetchthisfromserver istället för att skriva koden direkt i komponenten. Detta kan även lösas genom att bryta ut funktionen ur komponenten, vilket dock leder till att extra argument behöver skickas med i funktionen. Ett exempel på där extra argument gör det mer komplicerat är när setern som ges av hooken usestate behöver andvändas, då funktionen inte längre ingår i den funktionella komponentens scope. Detta löses i Redux fall i reducern då den har tillgång till applikationens tillstånd. F.5.3 Fråga 2 - Reducerar Redux antalet svårlösta buggar i ett projekt? Ett verktyg som kan användas tack vare Redux är Redux devtools, som ger en väldigt tydlig överblick över hur applikationens tillstånd förändras över tid. Detta har hjälpt till att förstå varför applikationen visar vad den gör och hur den förändrats över tid. Det ger en tydlig bild av alla applikationens värden i en lättnavigerad trädstruktur, jämfört med att lägga in console.log(interestingvalue) i koden för att försöka få ut vilket värde en komponent innehåller. Användande av textitconsole.log() blir snabbt svåröversiktligt då det är lätt att skriva ut ett värde många gånger, på grund av att komponenten renderas om, eller att värdet loggas innan det förändrats. Denna typ av loggning kan vara användbar i tidig utveckling, men kan om man inte är försiktig leda till andra typer av fel. Ett nära besläktat problem, som inte löser buggar i sig men som gör det lättare att hitta dem, är att all interaktion med ett värde i store endast kan göras genom actions (ofta bara en) som kan hittas genom reducern. Detta gör att om det förekommer ett värde som är oväntat finns det bara ett fåtal platser att leta. Med hjälp av tidigare nämnda devtools kan detta ofta betyda att läsa en action, och i sin tur komponenten som sände den om den använder indata från komponenten. Detta är även sant när vanliga hooks används då de endast kan uppdateras genom den konstanta set referensen som skapas med usestate. Detta ger en viss möjlighet att upptäcka var en förändring skett. Dessa referenser kan skickas som props till sub-komponenter för att förändra värdet. Det går fortfarande att se vilka komponenter som kan ändra värdet, men inte lika tydligt var i koden denna förändring kommer ifrån som när 107

117 F.6. Slutsatser Redux används. Detta gör det lättare att hitta buggar men gör dem inte lättare att lösa. Projektgruppen såg att några svårlösta buggar inte längre förekom när Redux användes. Exempel på dessa är komponenter med gammal data eller utebliven rendering efter att tillståndet uppdaterats. Detta på grund av att alla komponenter där ett värde som hämtats med useselector renderas om när värdet uppdaterats. Redux löser båda problemen ovan, då komponenten inte kan innehålla gammal information (om denna skickats till store med dispatch), och information kan inte heller undvika att renderas då detta sker då värdet uppdateras. Buggarna kan självklart undvikas utan att använda Redux, men det är lättare att råka skapa dem på grund av kapplöpning mellan funktioner, eller liknande problem som kan förekomma i realtidsystem med asynkrona funktioner. Därmed reducerar Redux i denna aspekten antalet av en av de klassiskt svåraste buggarna att hitta. F.5.4 Fråga 3 - Vilka anledningar finns det till att välja att inte använda Redux i ett projekt? Redux är i huvudsak användbart när många komponenter behöver interagera med varandra. Detta problem kan även lösas genom att lyfta upp tillståndet till närmaste komponent där alla komponenter som behöver det givna tillståndet kan få tillgång till det. Tillståndet delas sedan genom att referenserna för att visa och skriva till objektet, skickas som props. Om komponenten rimligtvis kan innehålla tillståndet utan att det blir ologiskt kan detta vara ett alternativ. Ett exempel på när detta inte gäller som förekom i projektet var när id till ett rum behöver lyftas från kartan till en gemensam sida, för att skickas till ett formulär. Men denna sida förekom inte för alla instanser för kartan så det skulle då behöva lyftas till applikationsnivå. Då kom gruppen fram till att Redux var ett enklare alternativ. Ett annat problem som kan tas i åtanke är storleken av vad som behöver laddas in och hållas i minne. Vid användning av Redux, om applikationen är stor och de olika delarna behöver väldigt olika information så existerar ofta mycket extra information som inte används fortfarande kvar i Redux store. Detta kan lösas genom att onödig information städas undan men kommer dock aldrig att bli lika effektivt som att en komponent automatiskt går ur scope när den inte längre renderas. Vid den här typen av diskussion tas även storleken av av applikationen upp. Storleken av Redux är dock inte i närheten lika stor som React. Hastigheten hos Redux kan tas upp som ett problem, men om det används korrekt finns inga tecken på att det blir en flaskhals. F.6 Slutsatser Helhetsintrycket av Redux är väldigt gott, och rekommenderas att användas av alla utom de enklaste webbapplikationerna. F.6.1 Fråga 1 - Hur kan Redux användas för att skapa bättre kodstruktur? Redux ger en tydlig uppdelning av logik och komponentens rendering. Detta ger en bättre bild av var kod hör hemma och gör det mycket lättare att återanvända kod och att veta var ny kod bör placeras. Att lägga till en ny action kräver väldigt lite arbete och den har, om korrekt tillagd inga sidoeffekter. F.6.2 Fråga 2 - Reducerar Redux antalet svårlösta buggar i ett projekt? Ja, efter att Redux började användas i projektet löstes ett antal tidskritiska buggar endast genom de garantier som Redux kommer med. Det ger även kraftfulla verktyg för att felsöka och hitta de fel som finns i applikationen. 108

118 F.6. Slutsatser F.6.3 Fråga 3 - Vilka anledningar finns det till att välja att inte använda Redux i ett projekt? Det finns väldigt få, för att börja använda Redux krävs ett antal extra filer och boilerplate. Är applikationen väldigt liten är detta onödigt. Men även en applikation av storleken i projektet har dragit stor nytta av Redux så gränsen för storleken av applikationen är låg. Är denna boilerplate välskriven är den lätt att återanvända i framtida projekt så investeringen blir lägre efter första gången. Med detta tackar jag för din tid och önskar dig lycka till med dina egna försök med React och Redux. 109

119 G Mårten Walter Affärsmodeller för mjukvarusystem I det här individuella bidraget redogörs för olika affärsmodeller för mjukvaruleverantörer att ta betalt för ett mjukvarusystem. Bidraget försöker också föra en diskussion om vilken affärsmodell som hypotetiskt hade varit bäst lämpad för det i projektet utvecklade systemet för visuell hantering av behörigheter till lokaler. G.1 Inledning Utveckling och underhåll av ett mjukvarusystem måste, åtminstone i näringslivssammanhang, vara ekonomiskt motiverat och genomförbart. Därför är det viktigt att välja en bra och passande affärsmodell för att ta betalt för ett system. Här gäller det förstås att ta hänsyn till vilken typ av kund som systemet är avsett för; en annan verksamhet (Business-to-Business) eller slutkonsumenter direkt (Business-to-Consumer)? Ifall kunden är en annan verksamhet blir det också en fråga om ifall det är produkten (systemet) i sig som säljs och till exempel huruvida kunden har ensamrätt till denna eller konsulttjänster som innefattar utveckling och underhåll av en produkt i kundens ägo, eller någon kombination av de båda. G.1.1 Syfte Syftet med bidraget är att redogöra för några olika väletablerade affärsmodeller för mjukvarusystem som skulle kunna vara aktuella för det system för visuell hantering av behörigheter till lokaler som utvecklats av gruppen. G.1.2 Frågeställning Bidraget ämnar besvara följande frågor: 1. Vad kännetecknar affärsmodellerna licensering, betalning per användningsenhet och prenumerationsbetalning? 2. Vad kännetecknar affärsmodeller för öppen mjukvara? 110

120 G.2. Bakgrund G.2 Bakgrund I kandidatprojektet är företaget Ericsson kunden som efterfrågar ett system för visuell hantering av behörigheter till lokaler som antagligen skulle tillämpas på en basis som hade berört hela företaget (och inte bara en avgränsad avdelning, etc.). Detaljerna i projektet och i systemet är baserade på de förutsättningar och behov som Ericsson har vad det gäller just lokalbehörighetshantering. Vidare består kandidatgruppen av åtta medlemmar och skulle kunna liknas vid ett litet konsultföretag eller ett team på ett konsultföretag; huvudsaken är att kandidatgruppen (hypotetiskt) och Ericsson har egna intressen med projektet. De affärsmodeller som redogörs för och diskuteras i det här bidraget kommer i någon mån att utgå från dessa delvis hypotetiska förutsättningar. Vidare avser kandidatgruppen att tillgängliggöra projektet under en öppen mjukvara-licens en aspekt som också undersöks i det här bidraget. G.3 Teori I det här avsnittet redogörs för teori med relevans för några olika affärsmodeller för mjukvarusystem. G.3.1 On-premises On-premises är ett alternativ för distribuering av en mjukvaruprodukt. Som namnet antyder innebär on-premises att mjukvaran installeras och körs på kundens egen hårdvara i dennes egna lokaler, snarare än via molnet [111]. On-premises-lösningar lämpar sig bland annat väl när mjukvaruprodukten innebär krav på hög prestanda och innefattar tunga beräkningar [112]. Vidare kan on-premises vara bra ifall produkten hanterar känsliga data (t.ex. personuppgifter) eftersom kunden då kan behålla dessa data i tryggt förvar inom sin egen IT-infrastruktur och inte behöver riskera att den komprometteras hos eller på grund av användandet av en molnleverantör. Mjukvara som är ämnad att användas på fältet, där en stabil nätverksuppkoppling inte går att ta för givet, lämpar sig också att distribueras som en on-premises-lösning. För en mjukvaruleverantör innebär on-premises-distribution att stort ansvar överlämnas på kunden vad det gäller installation och underhåll, och inte minst datasäkerhet. G.3.2 Software as a Service Software as a Service (SaaS) är ett annat vanligt sätt för en mjukvaruleverantör att erbjuda sin produkt till kunder [113]. Tvärtemot on-premises-lösningar innebär SaaS att mjukvaruleverantören gör sin produkt tillgänglig som en on-demand-tjänst över internet, och att hantering av data och exekvering sker på leverantörens egna (eller valda) IT-infrastruktur, snarare än på kundens. I SaaS-lösningar har mjukvaruleverantören ensamt ansvar för att garantera tillgänglighet samt att underhålla och uppdatera mjukvaran och behöver bara göra det på ett ställe: på sin egen IT-infrastruktur. Det innebär att kunder både slipper sådan arbetsbörda och eventuella oförutsedda kostnader som den hade inneburit, och istället kan lägga tid och fokus på samt göra investeringar i den egna verksamheten. G.3.3 Öppen mjukvara-licensering Öppen mjukvara-licensering (eng. Open Source Software Licensing) är en licensfamilj för mjukvara vilka ställer krav på att mjukvarans källkod ska vara läsbar och öppet tillgänglig, att mjukvaran får distribueras fritt, att härledda arbeten tillåts och uppmuntras samt att ingen diskriminering mot personer, grupper eller fält sker [114]. Härledda arbeten kan eventuellt behöva publiceras under samma öppen mjukvara-licens som ursprungsmjukvaran, beroende på den specifika licensen. Behovet av öppen mjukvara-licensering uppstod när utvecklare och leverantörer av mjukvara ville tillåta och uppmuntra samarbete och vidareutveckling 111

121 G.4. Metod av sin mjukvara. Kommersiella utgivningslicensalternativ ansågs då för restriktiva och icketillåtande av samarbete mellan olika aktörer. Samtidigt var alternativet att låta mjukvaran vara olicensierad inte heller gångbart, eftersom den då riskerades att plockas upp och bli upphovsrättskyddad av någon annan. Öppen mjukvara-licensering syftar alltså till att skydda och upprätthålla en mjukvaras frihet genom upphovsrättslagar. G.4 Metod För att besvara frågeställningen om vilka väletablerade affärsmodeller det finns för mjukvarusystem och för öppen mjukvara har en litteraturstudie gjorts. Referenserna i bidraget består i synnerhet av granskade (eng. peer-reviewed) artiklar som publicerats i tidskrifter eller i samband med konferenser (eng. conference proceedings). Sådana artiklar har hittats med hjälp av Google Scholar och sökordssträngar som software revenue models, software as a service och open source revenue models. Artiklar med titlar som matchade söksträngarna (och i viss mån frågeställningen) bra och som hade relativt högt antal citeringar valdes ut, varpå deras abstract lästes och innehållsförteckning sågs över. Ifall artiklarnas abstract och innehållsförteckning verkade relevanta lästes artiklarna i sin helhet och användes sedan eventuellt som källor i rapporten. G.5 Resultat I det här avsnittet redogörs bidragets resultat; vilka några väletablerade affärsmodeller för mjukvarusystem och öppen mjukvara är. G.5.1 Licensering Ett traditionellt sätt att ta betalt för programvara är med licensering (eller licensbetalning) [115]. Kunden betalar då för en licens för varje användare eller dator som ska kunna nyttja programvaran vilken då installeras och används lokalt hos kunden (on-premises). För mjukvaruleverantören är det framförallt de höga initiala licensbetalningarna som utgör den största delen av inkomsterna i denna modell, även om det också är vanligt att ta ut en underhållsavgift för teknisk support och versionsuppdateringar. De höga initiala licensbetalningarna ger upphov till både för- och nackdelar i affärsmodellen [115]. De innebär en större investering för kunderna; sådan att de kommer vara mindre benägna att också eller vid ett senare tillfälle investera i konkurrerande mjukvaruleverantörers eventuella alternativ. Tack vare dem blir det också enklare och går snabbare för mjukvaruleverantören att få igen kostnader och investeringar för utvecklingsarbetet. Det är finansiellt mindre riskfyllt ur den aspekten. Myntets baksida är dock att inte särskilt mycket inkomster erhålls från kunden efter eller utöver den initiala licensbetalningen. I och med att licensering vanligen tillämpas i on premises-situationer tillkommer även mer indirekta affärsmässiga nackdelar, som riskerna för att kunden missanvänder licenser och piratkopierar mjukvaran. [115]. För kunden innebär det däremot å ena sidan att data kan förvaras säkert lokalt, men å andra sidan att en egen IT-infrastruktur med lagringsutrymme och beräkningskapacitet måste finnas tillgänglig för att en on premises-lösning ska vara möjlig. Vidare finns det också vissa för- och nackdelar med själva licenseringsbetalningssättet för kunden: Om kunden avser använda mjukvaran under en lång tid, gärna som en kärna i sin verksamhet, och i icke-varierande skala kan den höga initiala licenskostnaden i längden bli billigare än andra affärsmodellsalternativ speciellt eftersom den tillåter prisförhandling mellan parterna. Men det gäller då att kunden har (och inte minst godkänner) en budget som tillåter en sådan stor investering; och som tidigare nämnt blir det dyrt för kunden att ångra 112

122 G.5. Resultat sig och att utforska andra, konkurrerande alternativ. För mjukvaruleverantören kan licensering anses vara en lämplig affärsmodell när kunden är en stor verksamhet, den potentiella kundmålgruppen är liten och när risken för piratkopiering och missanvändning av licenser anses låg [115]. För kunden kan licensering vara att föredra då mjukvaran kommer att användas frekvent och som en kärna i verksamheten, när budgeten tillåter och när det kommer finnas behov av att skräddarsy mjukvaran. G.5.2 Betalning per användningsenhet Ett annat sätt att ta betalt för mjukvara är med en affärsmodell baserad på att kunden betalar per användningsenhet, där användningsenhet till exempel kan vara exekveringstid eller antalet gånger en viss typ av uppgift har genomförts [115]. Denna affärsmodell lämpar sig, till skillnad från licensering, inte särskilt väl som en on-premesis-lösning utan förutsätter snarare att mjukvaran levereras som en Software as a Service-lösning, så att mjukvaruleverantören kan administrera kundernas användning och ta betalt därefter. Betalning per användningsenhet gör att hänsyn kan tas till olika verksamheters olika behov av en mjukvara samt deras förutsättningar att införskaffa den, och således att den potentiella kundmålgruppen blir större [115]. Andra fördelar med betalning per användningsenhet för mjukvaruleverantören är att en nätverkseffekt enklare kan uppstå där kännedomen om mjukvaran i branschen ökar med antalet kunder och leder till att potentiella kunders sökkostnader blir lägre. Tack vare att affärsmodellen medför att mjukvaran levereras som en Software as a Service-lösning renderas dessutom risken för piratkopiering till närmare obefintlighet. Till skillnad från licenseringsaffärsmodellen innebär dock betalning per användningsenhet en större finansiell risk för mjukvaruleverantören gällande att få igen kostnader och investeringar för utvecklingsarbetet (tillräckligt snabbt eller överhuvudtaget) [115]. Dessutom behöver kunden inte nödvändigtvis ha begått en stor investering vid införskaffandet av mjukvaran, vilket innebär att de kan vara mer benägna att också eller vid ett senare tillfälle investera i konkurrerande mjukvaruleverantörers eventuella alternativ. Betalning per användningsenhet kräver också att mjukvaruleverantören lägger resurser på att registrera och upprätthålla information om alla kunders användning av mjukvaran, sådan att kunderna kan debiteras korrekt och att de ges möjlighet att kontrollera att så också är fallet. För kunden finns många fördelar med betalning per användningsenhet [115]: Betalning för mjukvaran blir en driftkostnad snarare än en kapitalinvestering (det kan dock vara svårt att uppskatta användningsmängd och därmed kostnad i förväg). Det passar bättre för användning i varierad skala, och tillåter test och utvärdering av lämplighet i verksamheten utan ett alltför stort åtagande. Att mjukvaran levereras som en Software as a Service-lösning innebär också att kunden inte behöver tänka på installationer, underhåll och uppdateringar och att behovet av egen IT-personal och IT-infrastruktur inte är lika stort. En konsekvens av detta är dock att kundens potentiellt känsliga data förvaras någon annanstans, bortom kundens egen kontroll. Vidare brukar mjukvaruleverantörer som tillämpar betalning per användningsenhet ofta ha samma, icke förhandlingsbara, prissättning för alla kunder. För mjukvaruleverarantören kan betalning per användningsenhet vara en lämplig affärsmodell när den tilltänkta kundmålgruppen är stor men kunderna i sig är små eller medelstora verksamheter och när risken för piratkopiering och missanvändning av licenser bedöms vara hög [115]. För kunden kan betalning per användningsenhet vara att föredra då mjukvaran bara är tänkt att användas sporadiskt och önskas vara lätt att använda och inte behöva vara skräddarsydd samt när det finns begränsade resurser att investera i mjukvara med. 113

123 G.6. Diskussion G.5.3 Prenumerationsbetalning Ett ytterligare sätt att ta betalt för mjukvara är med en affärsmodell baserad på prenumerationsbetalning, där kunden debiteras en avgift för att få använda mjukvaran under en begränsad kalendertid [115]. I många avseenden är prenumerationsbetalning likt betalning per användningsenhet, inte minst i det att mjukvaran då med fördel levereras som en Software as a Service-lösning. De två affärsmodellerna delar alltså många för- och nackdelar, men till skillnad från betalning per användningsenhet behöver en mjukvaruleverantör som tillämpar en prenumerationsbaserad affärsmodell inte registrera och upprätthålla information kring kunders användning av mjukvaran, eftersom denna nu inte ligger till grund för debiteringen. Vidare ger en prenumerationsbetalningsbaserad affärsmodell mjukvaruleverantören större prissättningsflexibilitet, där potentiella prisparametrar till exempel kan vara prenumerationslängd, antalet användare som ska kunna nyttja mjukvaran, olika funktionalitetsskikt eller kundverksamhetens storlek och förutsättningar [115]. För kunden innebär prenumerationsbetalning större möjligheter till prisförhandling än med betalning per användningsenhet. Den totala kostnaden blir även förutsägbar, vilket gör det enkelt att budgetera för mjukvaran, och tillåter väldefinierad tidsbegränsad användning (till exempel för ett tidsbegränsat projekt, eller för en temporärt inhyrd specialist). För mjukvaruleverantören kan prenumerationsbetalning vara en bra och flexibel medelväg som lämpar sig både för små och stora potentiella kundverksamheter [115]. För kunden är prenumerationsbetalning också en bra, allsidig betalningsmodell som framförallt tillåter full och detaljerad evaluering av mjukvarans totala kostnad. G.5.4 Affärsmodeller för öppen mjukvara Affärsmodeller för öppen mjukvara kräver viss kreativitet eftersom öppen mjukvaralicensensering tillåter alla eventuella kunder som köper mjukvaran att ge bort den eller själva sälja den vidare varför vanliga, licensbaserade affärsmodeller inte kan tillämpas [114]. En anledning till att licensera mjukvara med en öppen mjukvara-licens är för att möjliggöra och uppmuntra bidrag från allmänheten. Att då försöka profitera på dessa bidrag riskerar att försämra engagemanget för mjukvaran från allmänheten. Affärsmodeller för öppen mjukvara går snarare ut på att profitera på kompletterande produkter och tjänster vid sidan av mjukvaran. En sådan affärsmodell för öppen mjukvara är att erbjuda och sälja support för en mjukvara som i sig är gratis [114]. En öppen mjukvara kan också användas som lockvara i förhoppning att sälja andra relaterade, kommersiella mjukvaror. Om leverantören däremot inriktar sig på försäljning av hårdvara i första hand kan tillhörande drivrutinsmjukvara licenseras som öppen mjukvara med förhoppningen att den underhålls av allmänheten. Ett ytterligare alternativ är att leverantören först säljer mjukvaran under kommersiell licens med förhoppningen att få igen kostnader och investeringar för utvecklingen, men senare låter den övergå till att bli en lockvara licensierad som öppen mjukvara. G.6 Diskussion Många aspekter av det i projektet utvecklade systemet och det faktum att Ericsson är kund gör att en on-premises-lösning och en affärsmodell baserad på licensiering hade varit aktuell. Idén till systemet kommer från Ericsson baserat på deras behov, och kravspecifikationen för systemet har tagits fram enbart med Ericssons önskemål och förutsättningar i åtanke. Därför är det osäkert hur attraktivt systemet hade varit för andra verksamheter och därmed kan projektet anses uppfylla kriterier som talar till en licenseringsaffärsmodells fördel (kunden är en 114

124 G.7. Slutsatser stor verksamhet och den potentiella kundmålgruppen är liten). Vidare hanterar systemet persondata som kan anses känslig, vilket kan vara anledning till att välja en on-premises-lösning för att kunna förvara datan säkert lokalt. Att Ericsson redan har befintlig IT-infrastruktur som skulle kunna användas i detta syfte är rimligt att anta. Hantering av lokalbehörigheter är säkerhetskritiskt och behöver ske konstant, därför kan det av tillförlitlighetsskäl också vara fördelaktigt med en on-premises-lösning eftersom systemets backend då kan köras på Ericssons intranät och risken med att inte ha ständig stabil nätverksuppkoppling därmed undvikas. Däremot finns det mycket i systemets arkitektoniska natur som hade gjort det väl lämpat att distribueras som en Software as a Service-lösning (och därmed aktualiserat någon av affärsmodellerna betalning per användningsenhet och prenumerationsbetalning): Systemets frontend är en webbapplikation och är det enda delsystem som kunden behöver hantera för att använda systemet i sin helhet. Systemet ställer heller inga höga prestandakrav och behöver inte utföra tunga beräkningar; det är heller inte utvecklat med tydliga och mätbara användningsenheter i åtanke varför en affärsmodell baserad på prenumerationsbetalning eventuellt hade varit ännu mer aktuell vid en SaaS-distributionslösning. För att en affärsmodell förknippad med SaaS skulle vara det främsta alternativet hade dock systemet behövt vara mer generellt sådant att den potentiella kundmålgruppen varit större och kundverksamheterna i sig kunnat vara mindre. Affärsmodeller för öppen mjukvara-licensierade system går främst ut på att profitera på kompletterande produkter (t.ex. hårdvara) och tjänster (t.ex. support) vid sidan av den levererade mjukvaruprodukten. Det i projektet utvecklade systemet har dock ingen tydlig öppning för hårdvaruförsäljning (Ericsson har redan kortläsarsystem på plats), och är inte heller tillräckligt avancerat för att andra aktörer inte ska kunna erbjuda bättre support till ett utkonkurrerande pris; varför en affärsmodell baserad på öppen mjukvara inte hade varit lämplig för projektet. G.6.1 Diskussion av metod I bidragets resultatdel användes enbart två artiklar som publicerats i tidsskrifter eller i samband med konferenser. Anledningen till det var att informationen i artiklarna var av stor relevans för att kunna besvara frågeställningen och för att de och de källor som refereras till i artiklarna ansågs trovärdiga. Den fakta och de slutsatser som presenteras i artiklarna ansågs också underbyggas av sunda och förnuftiga resonemang. Hade större källkritik varit önskvärd hade en marknadsundersökning kunnat göras för att till exempel undersöka de påstådda sambanden mellan mjukvaruleverantörer, deras kunder/kundmålgrupper och de valda affärsmodellerna. Vidare hade citeringarna av artiklarna kunnat undersökas, för att se om någon försökt motsäga eller komplettera artiklarnas innehåll. G.7 Slutsatser I det här avsnittet dras sammanfattande slutsatser och svar på bidragets frågeställning. Vad kännetecknar affärsmodellerna licensering, betalning per användningsenhet och prenumerationsbetalning? Licensiering är en traditionell affärsmodell för mjukvarusystem där kunden köper en licens för varje användare eller dator som ska kunna nyttja mjukvaran. Höga initiala licensbetalningar utgör den största delen av inkomsterna i denna modell. Licensiering lämpar sig väl när mjukvaruprodukten avses distribueras som en on-premises-lösning, när kundmålgruppen 115

125 G.7. Slutsatser är stora verksamheter eller om mjukvaran förväntas hantera känsliga data. Betalning per användningsenhet är en affärsmodell baserad på att kunden betalar per en viss användningsenhet, till exempel exekveringstid eller antalet gånger en viss typ av uppgift har genomförts. Prenumerationsbetalning liknar betalning per användningsenhet, men bygger på att kunden betalar en förutbestämd avgift för att få använda mjukvaran under en begränsad kalendertid. Ifall någon av dessa två affärsmodeller tillämpas kan mjukvaruprodukten med fördel distribueras som en Software as a Service. Projektets kund, Ericsson, och deras förutsättningar och det system som utvecklats kan anses vara bäst lämpade för en on-premises-lösning och en affärsmodell baserad på licensiering. Vad kännetecknar affärsmodeller för öppen mjukvara? Ett av de främsta incitamenten till att licensera sin mjukvaruprodukt med en öppen mjukvara-licens är att dra nytta av bidrag från allmänheten. Affärsmodeller för öppen mjukvara går främst ut på att sälja kompletterande produkter (t.ex. hårdvara) och tjänster (t.ex. support) vid sidan av den levererade mjukvaruprodukten, något som det i projektet framtagna systemet inte är anpassat för. 116

126 H Johannes Wilson Mjukvarusystem efter dataskyddsförordningen H.1 Inledning Dataskyddsförordningen eller som den har blivit mer känd som GDPR är en förordning som är tänkt att stärka individers rättigheter gällande deras personuppgifter. Eftersom mjukvara ofta hanterar personuppgifter i olika former så har förordningen ställt många nya krav på mjukvara. Det kan handla om hur man får ta emot, lagra och bearbeta personuppgifter, och personuppgifterna kan gälla alla tänkbara sorters data såsom namn, e-postaddresser, personnummer, bilder eller platsdata. Då systemet som utvecklas i projektet är designat att hantera vissa uppgifter om personer bör systemet följa de krav på hanteringen av personuppgifter som dataskyddsförordningen ställer. I den här delen undersöks hur det mjukvarusystem som har utvecklats i projektet klarar de krav på personuppgiftshantering som ställs av GDPR, och hur ett företag skulle kunna använda systemet på ett sätt som uppfyller kraven. H.1.1 Syfte Då integritetsskydd fått allt större plats i lagstiftningen krävs att utvecklingen av mjukvara anpassas, och för det krävs att utvecklare känner till vad som gäller. Denna individuella del syftar till att ge en tydligare bild av vilka regler som gäller för mjukvarusystem vid hantering av personuppgifter genom att analysera hur några av de viktigaste punkterna i dataskyddsförordningen kan tolkas med avseende på ett mindre mjukvaruprojekt. Syftet är också att säkerställa att kvaliteten på systemet uppfyller kraven i dataskyddsförordningen. Texten behandlar också vilket arbete som kvarstår vid behandling av personuppgifter för ett företag som tänker använda ett system likt det vi utvecklat. Detta för att kunna ge en inblick i det arbete som ett verkligt företag skulle behöva göra men som inte är just nu är applicerbart på vårt system. H.1.2 Frågeställning I denna rapport besvaras följande frågeställningar: 1. Uppfyller systemet Visual1ze kraven på hantering av personuppgifter som dataskyddsförordningen ställer? 117

127 H.2. Bakgrund 2. Hur kan systemet Visual1ze användas på ett sätt som uppfyller kraven som dataskyddsförordningen ställer? 3. Vilka ytterligare krav borde ställas på systemet för att bättre följa de riktlinjer som dataskyddsförordningen och datainspektionen ger? H.1.3 Avgränsningar Denna rapportdel är avgränsad till att endast bearbeta de delar av dataskyddsförordningen som är relevanta för ett mjukvaruprojekt. Den behandlar alltså inte delar utöver de som kan appliceras på utveckling, underhåll och användning av mjukvaran i Visual1ze. Endast dataskyddsförordningen kommer att diskuteras. Annan lagstiftning som gäller hantering av personuppgifter eller datasäkerhet behandlas inte här. H.1.4 Ordlista GDPR: Dataskyddsförordningen, från engelskans General Data Protection Regulation Datainspektionen: Statlig myndighet som arbetar med att skapa förutsättningar för att behandlingen av personuppgifter inte medför otillbörligt intrång i enskildas personliga integritet. (Regeringen.se, [116]) H.2 Bakgrund Den 25 maj 2018 ([117], artikel 99) antogs dataskyddsförordningen. Dataskyddsförordningen syftar till att stärka individens rättigheter när det gäller andras hantering av ens personuppgifter. Bland annat gör dataskydsförordningen det olagligt att hantera personuppgifter utan att ha rimliga skäl till det eller att personen har godkänt användningen ([117], artikel 6). Under tiden mellan att förordningen röstades igenom och att den trädde i kraft i hela den europeiska unionen var många tvungna att ändra sin hantering av personuppgifter. Många ändrade sina policyer, och perioden strax efteråt kännetecknades av ett bombardemang av e-post från olika onlinetjänster som alla samtidigt skickade ut sina nya avtal. Vissa webbplatser valde att helt stänga ner för alla användare i EU av rädsla för att inte kunna nå upp till de nya kraven [118]. Brott mot dataskyddsförordningen resulterar i sanktioner. Den 13 december 2019 beslutade datainspektionen om att företaget Nusvar behövde betala en sanktionsavgift på euro [...] för brott mot kreditupplysningslagen och dataskyddsförordningen [119]. Enligt datainspektionen ligger övre gränsen för hur mycket man kan behöva betala i sanktionsavgift på 20 miljoner euro eller, om det gäller ett företag, fyra procent av den globala årsomsättningen, beroende på vilket belopp som är högst [120]. Att göra fel innebär inte bara en risk för användares personuppgifter utan kan också bli en risk för en organisations verksamhet och är något varje utvecklare bör vara medveten om. Utmaningarna med säker hantering av personuppgifter är många. Generellt så har integritet och säkerhet sällan haft högsta prioritet under utveckling av mjukvara, vilket hade krävts för att kunna säkra dessa aspekter. Att lyfta dem till centrala delar av utvecklingsprocessen är något som blivit känt som inbyggt dataskydd (eng. Privacy by Design). Att integrera denna metodik i utvecklingsarbetet kräver att både ingenjörer och chefer är involverade i processen [121]. 118

128 H.3. Teori H.3 Teori Här tas fakta upp som är relevant för projektdelen. Avsnittet är uppdelat i två delar, först behandlas de artiklar i dataskyddsförordningen som används för att svara på frågeställningarna, därefter tas relevant teori om datasäkerhet upp kortfattat. H.3.1 Dataskyddsförordningen Här beskrivs några centrala punkter från dataskyddsförordningen. Personuppgifter I stort sett all data som kan kopplas till en person är en personuppgift [122]. Vissa personuppgifter klassas som extra känsliga och för att dessa ska få hanteras ställs extra hårda krav. Hanteringen av känsliga personuppgifter förbjuds i stort sett om inte hanteringen är väl motiverad, som för rättsäkerhet eller hälso- och sjukvård [123]. Känsliga uppgifter kan vara information om en persons hälsa, politiska åsikt eller etnicitet, men kan också vara så kallade biometriska data som fingeravtryck eller ansiktsbilder [124]. Personuppgiftsansvarig Personuppgiftsansvarig är den som behandlar personuppgifterna, men är typiskt sett inte en enskild person utan kan vara ett bolag eller en myndighet. Det kan också vara en grupp av flera personer på ett bolag. Alla som behandlar personuppgifter måste se till att det görs i enlighet med dataskyddsförordningen [125]. Rättslig grund Enligt Datainspektionen kräver GDPR att personuppgifter ska behandlas efter ett av följande syften: 1. Personen har lämnat samtycke. 2. Personen har ingått i ett avtal. 3. Ändamålet för att samla in personuppgifterna är så pass viktiga att de väger tyngre än personens intressen. 4. Personuppgifterna måste behandlas av juridiska skäl. 5. Personuppgifterna behandlas för syfte i allmänt intresse eller för myndighetsverksamhet. 6. Personuppgifterna måste behandlas för att skydda någon som inte kan lämna samtycke. [126] Av dessa är det främst 1-4 som är relevanta för ett privat företag. Att basera syftet på samtycke kan vara problematiskt av flera orsaker. Först kräver det att insamlingen är frivillig, och kan alltså inte vara nödvändig för funktionalitet. Dessutom måste beslutet ske på lika villkor. På datainspektionens hemsida lyfts ett exempel där en app begär åtkomst till GPS-data för beteendelokaliserad marknadsföring. Då appen inte går att använda utan godkännande sker beslutet inte på lika villkor, och samtycke kan därför inte användas som motivering till datainsamlingen. Ytterligare svårigheter uppstår då personen förutsätts kunna ångra sitt godkännande [127]. Avtal kan användas när personerna vars uppgifter behandlas ingår i ett avtal med den personuppgiftsansvarige. Datainspektionen har skrivit följande om detta: 119

129 H.3. Teori Som arbetsgivare får ni behandla personuppgifter om en anställd för att kunna uppfylla anställningsavtalet, till exempel för löneberäkning, registrering av sjukfrånvaro eller i ett flextidssystem [128]. På samma sätt kan personuppgifter samlas in i syfte att upprätthålla ett avtal med en kund. Här är det viktigt att endast uppgifter som är nödvändiga för avtalet behandlas. Lagring och insamling En viktig punkt i dataskyddsförorningen är att endast nödvändig data ska hanteras. I detta ingår det att data inte ska sparas längre än nödvändigt såväl som att det inte ska samlas in mer data än vad som behövs. Enligt GDPR får datainsamling bara ske på motiverade grunder, men det gäller även att all användning av data sker på samma grund som på vilken den samlades in. Det är inte acceptabelt att samla in data om personer i ett syfte för att sen använda data till något helt annat eller sälja till tredje part. Ifall en personuppgift får användas till ett visst syfte beror också delvis på hur viktigt syftet är. Om en personuppgift används för att öka datasäkerheten kan det vara motiverat även om personuppgiften inte är nödvändig för systemets funktionalitet, förutsatt att personuppgiften inte är för känslig. Det motsatta kan också gälla: en personuppgift kan vara för känslig för att få användas till ett visst syfte, även ifall personuppgiften är nödvändig. Enligt ett tillsynsbeslut av Datainspektionen så bröt en skola i Skellefteå mot GDPR när de testade ett system för automatisk närvarokontroll genom maskinell ansiktsigenkänning. Detta då syftet som var att underlätta närvarokontroll inte vägde upp mot att ansiktsbilderna klassades som känslig biometrisk data [129]. trots att eleverna hade gett tillåtelse så bedömde inte Datainspektionen det som tillräckligt, eftersom eleverna och skolan inte står på lika villkor och det kan ha lett till att eleverna kände sig tvingade att ge samtycke. Transparens Dataskyddsförordningen beskriver också att en person ska kunna begära följande om sina personuppgifter: H.3.2 Personen har rätt att få sina uppgifter rättade. Personen har rätt att få ett utdrag av de personuppgifter som behandlas. Personen har rätt att få sina uppgifter borttagna. Datasäkerhet Dataskyddsförordningen beskriver att nödvändiga åtgärder måste tas för att personuppgifter ska vara skyddade. Inga specifika krav ställs på vilket skydd som ska finnas på plats, men en personuppgiftsansvarig förväntas använda applicerbar teknik och använda dataskydd som standard. Hashfunktion Att hashsummera lösenorden är en form av skydd för att dölja vilket lösenord en person använder. Vilket lösenord en person använder är ofta känsligt inte bara för att det låter en person logga in på deras konto, men också eftersom personer har en tendens att återanvända lösenord. Ifall lösenord läcker ut innebär det en säkerhetsrisk för alla personer som använder liknande lösenord, efter som att dessa går att använda i en dictionary attack. Genom att endast spara ett lösenords hashsuma går det att dölja vad det ursprungliga lösenordet var, och på så sätt minskas både konsekvenserna av en attack och intresset av att göra en attack. 120

130 H.4. Metod Databaskryptering Ett antal olika sätt att kryptera en relationsdatabas diskuteras i avsnittet av Johan Ehinger, se kapitel B. H.4 Metod För att besvara frågeställningarna kommer en checklista från Datainspektionen att användas. Checklistan finns på deras webbplats och ska be en bild av ifall de grundläggande principerna från dataskyddsförordningen efterlevs. Checklistan ser ut som följande: (punktlistan nedan är ett citat) Bestäm ändamålet: Varför ska ni behandla personuppgifter? Vad är ert syfte? Hitta en rättslig grund: Vilken rättslig grund i dataskyddsförordningen stödjer ni er på när ni behandlar personuppgifter? Informera de registrerade: Är informationen lätt att hitta och är den lätt att förstå för de registrerade? Ha rätt uppgifter: Behandlar ni bara de personuppgifter som ni behöver för ändamålet? Har ni för mycket personuppgifter? Skydda personuppgifterna: Har ni vidtagit tillräckliga tekniska och organisatoriska säkerhetsåtgärder? Har ni gjort en risk- och sårbarhetsanalys? Radera uppgifter: Har ni rutiner för att radera personuppgifter när de inte längre behövs för ändamålet? Visa att ni gör rätt: Har ni dokumenterat er personuppgiftsbehandling, inklusive beslut och överväganden? Har ni skapat interna riktlinjer för dataskydd och hantering av personuppgifter? [130] För att kraven från GDPR ska vara uppfyllda ska alla dessa punkter vara uppfyllda, och vi kan därför svara på frågeställning 1 och 2 genom att undersöka ifall en kund som ska använda systemet Visual1ze i verklig verksamhet skulle kunna uppfylla punkterna i checklistan ovan. Varje rubrik i resultatavsnittet går igenom en av punkterna i checklistan. Rubrikerna är i ordning av punkterna och är namngivna ändamål, rättslig grund, information till de registrerade, val av personuppgifter, skydd, radering och transparens. För att besvara frågeställning 3 kommer ett antal förbättringsförslag på Visual1ze att presenteras som skulle kunna öka kompatibiliteten med GDPR. Dessa förbättringsförslag kommer att fokusera på den databaslösning vi har valt att använda för systemet. Förbättringsförslagen är sammanställda under rubrik H.5.8. H.5 Resultat Under resultat visas den bedömning som gjorts uppdelat efter den checklista som beskrevs under metod. H.5.1 Ändamål Syftet med systemet Visual1ze är att effektivisera och underlätta användningen av säkerhetssystem på ett företag på ett sätt som minskar fel och säkerhetsbrister. Syftet är väldefinierat och beskrivs i detalj i inledningen till denna rapport. 121

131 H.5. Resultat H.5.2 Rättslig grund Systemet Visual1ze sparar användarnas namn, e-postadress, och en hashsumma av deras lösenord. Utöver det sparas deras behörigheter, förfrågningar och eventuellt ansvarsområde i fallet då användaren är en approver. All data som har med behörigheterna och ansvarsområden att göra kan ses som nödvändiga för anställningen. Därför är lagringen av behörigheterna i enlighet med dataskyddsförordningen i syfte att uppfylla anställningsavtalet, och sparas med avtalet som rättslig grund. Inga av de uppgifter som sparas klassas som känsliga personuppgifter. Alla personuppgifter som behandlas bör göra det i enlighet med ett syfte, däribland de uppgifter som systemet använder för inloggning i systemet. Dessa uppgifter är dock inte en nödvändighet för anställningen i samma utsträckning som behörigheterna till lokalerna är. Dessa personuppgifter lagras för att de anställda ska kunna använda funktionalitet för att söka och se över behörigheter. Dessa kan ses som en del av nödvändiga arbetsuppgifter hos de anställda, men att en e-postadress används som inloggningsuppgift är inte en nödvändighet. E-postadressen fyller endast ett syfte ifall den används för att skicka e-post till en person, annars är e-postadressen en onödig personuppgift då den skulle kunna ersättas med ett användarnamn. Här kan det spela roll ifall e-postadressen är privat eller om adressen redan är kopplad till deras anställning. Om e-postadressen är ett arbetskonto är den ingen data som inte redan skulle finnas tillgänglig på arbetsplatsen, så att lagra den under anställningen i inloggningssyfte är ingen inskränkning för användaren. H.5.3 Information till de registrerade En del av det som krävs för att uppfylla kraven i dataskyddsförordningen handlar om att kunna visa dokumentation för personen som beskriver hur deras uppgifter samlas in och används. Detta ansvar faller delvis på den tänkta kunden i och med att de behöver integrera ett nytt system som Visual1ze i sin interna personuppgiftspolicy. Den tekniska dokumentationen som behövs för att kunna besvara vilka personuppgifter som lagras och hur de används kan hittas i denna rapport och därmed finns det goda förutsättningar för att uppfylla det kravet. H.5.4 Val av personuppgifter Förutom i fallet med e-postaddress har mängden personuppgifter som behöver sparas i systemet minimerats till den nivå som det går för att systemet fortfarande ska kunna fungera med full funktionalitet. H.5.5 Skydd Lösenorden sparas krypterat i databasen, vilket innebär att ingen kan få tillgång till vilka lösenord som används, även i fallet av en attack. Kryptering av relationsdatabasen bedömdes inte vara nödvändig för att skydda datan i databasen eftersom att ingen data är särskilt känslig. En attack skulle endast ge information om de anställdas namn och e-post vilket inte är tillräckligt för att motivera varför en attack skulle göras. Det är viktigt att se till att ingen data är tillgänglig för någon utomstående. Då systemet endast ska användas av anställda på företaget bör det bara vara tillgängligt inifrån företaget. Gränssnittet bör inte vara åtkomligt utifrån internet utan bara på företagets lokala nätverk. Att kryptera databasen är inte nödvändigt. Det är fullt tillräckligt att se till att endast en grupp personuppgiftsansvariga på företaget har tillgång till databasen. Hade databasen innehållit känsligare data hade det kunnat vara lämpligt att kryptera den, men under antagandet att tjänsten bara är tillgänglig för personer inom företaget är skadan mycket liten ifall 122

132 H.6. Diskussion det skulle finnas någon säkerhetsbrist i systemet. För att skydda de anställda är det en fördel att ha en logg som bokför ändringar i databasen. Detta underlättar så att det vid eventuella missbruk av systemet går att se hur någon gick tillväga. En sådan logg får inte gå att ändra av någon, bör inte innehålla mer personuppgifter än nödvändigt och bör endast lagras under begränsad tid. Databasen bör också säkerhetskopieras med jämna mellanrum, men säkerhetskopior bör endast lagras en viss tid efter de är tagna. Även en säkerhetskopia lagrar personuppgifter, så en säkerhetskopia bör endast sparas så länge som krävs för att det alltid ska gå att återställa systemet till en fungerande version. H.5.6 Radering För att personuppgifter inte ska lagras långt efter en anställning bör det gå att radera en person ur systemet. Personer som inte längre är bundna till ett anställnigsavtal får inte längre lagras i systemet eftersom den rättsliga grunden för lagringen inte längre gäller. Ansvaret faller på personuppgiftsansvarig att se till att en anställd tas bort ur systemet efter anställningen upphört. Radering av personuppgifter är något som systemet redan klarar av. En admin kan radera användare från systemet, och då tas all data bort som går att koppla till den användaren. H.5.7 Transparens Den sista punkten i Datainspektionens checklista gäller företagets riktlinjer för personuppgifter. Ett företag har ansvar att kunna visa att de har tagit nödvändiga åtgärder för att skydda personuppgifter som behandlas. Denna rapport kan användas som en grund för att analysera dessa krav, men ansvaret att dokumentera detta faller på det företag som väljer att använda systemet. H.5.8 Förbättringsåtgärder De anställda bör kunna få tillgång till vilka uppgifter som finns lagrade om dem, och bör kunna få dem rättade om fel har uppstått. I fallet Visual1ze bör alltså användarna kunna ändra sin e-post och sitt namn ifall de har blivit felstavade exempelvis. Arkitekturen hindrar inte det, men detta går inte att göra direkt genom gränssnittet. Det kan dock göras av en personuppgiftansvarig med åtkomst till databasen. Automatisering av detta skulle kunna läggas till i systemet. Som nämndes under H.5.5 bör åtkomst till databasen vara begränsad på ett företag, all databasaktivitet bör lagras en tid i en logg, och databasen bör ha en säkerhetskopia tillgänglig. H.6 Diskussion Mycket av den bedömning som gjorts är baserad på de riktlinjer som Datainspektionen har publicerat på sin hemsida. Även om Datainspektionen är en trovärdig källa så finns det en risk med att inte göra bedömningen baserat på lagtexten i sin helhet eftersom att det kan vara saker i dataskyddsförordningen som är relevanta men som inte Datainspektionen lyfter. Resultatet är endast relevant ifall de riktlinjer som Datainspektionen gett ut är heltäckande. Det bör också poängteras att tolkningen av lagtexten som gjorts troligtvis inte ger en tillförlitlig bild av hur lagen tillämpas i praktiken. Endast fåtal exempel finns att tillgå på tillsynsbeslut som Datainspektionen har gjort, och det är i första hand dessa som exemplifierar hur lagarna tillämpas. 123

133 H.7. Slutsatser H.7 Slutsatser Enligt den bedömning som gjorts här är det fullt möjligt för ett företag att kunna använda systemet Visual1ze och motivera hanteringen av personuppgifter på ett sätt som godkänns av dataskyddsförordningen. Visst arbete krävs från företagets sida för att nå full kompatibilitet, främst för att säkerställa säkerheten i systemet, och för att säkerställa att personer tas bort ur systemet efter upphörd anställning. Svaren till frågeställningarna kan sammanfattas som följande: 1. Systemet Visual1ze uppfyller kraven på hantering av personuppgifter som dataskyddsförordningen ställer. 2. Systemet Visual1ze kan användas på ett sätt som uppfyller kraven som dataskyddsförordningen ställer genom att begränsa användningen av systemet till de på företaget, radera användare vars anställning upphört, och genom att implementera en logg och säkerhetskopiering av databasen. 3. De krav som borde ställas på systemet för att bättre följa dataskyddsförordningens och datainspektionens riktlinjer är att användare borde kunna få tillgång till vilka personuppgifter som behandlas om dem i systemet, det borde finnas en logg och säkerhetskopiering av databasen bör ske regelbundet. 124

134 Litteratur [1] Kandidatprojekt i programvaruutveckling, 15 hp (TDDD96). [Läst ]. URL: [2] Brandskydd och säkerhet Trygga lösningar som fungerar när de behövs. [ ]. URL: [3] Passersystem. [Läst ]. Safeguard. URL: www. safeguard. se/ passersystem/. [4] R. Chandramouli David F. F. D. Richard Kuhn. Role based access control. Artech House INC, [5] R. S. Sandhu och P. Samarati. Access control: principle and practice. I: IEEE Communications Magazine 32.9 (1994), s URL: document/ [6] H. L. Feinstein R. S. Sandhu E. J. Coyne och C. E. Youman. Role-based access control models. I: Computer 29.2 (1996), s URL: document/ [7] E. F. Codd. A Relational Model of Data for Large Shared Data Banks. I: Commun. ACM 13.6 (juni 1970), s ISSN: DOI: / URL: [8] MySQL 8.0 Reference Manual. [Läst ]. Oracle Corporation and/or its affiliates URL: https : / / dev. mysql. com / doc / refman / 8. 0 / en / sql - statements.html. [9] Olaf Hartig. Enhanced Entity Relationship (EER) Modeling. [Läst ]. Linköpings universitet URL: https : / / www. ida. liu. se / ~TDDD37 / fo / DBTechnology pdf. [10] Eva R. Ragnemalm. Databaser - design och programmering. [Läst ]. Linköpings universitet. URL: FoRelModellWeb10.pdf. [11] Dataskyddsförordningen (GDPR). [Läst ]. Datainspektionen URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen/. 125

135 Litteratur [12] Andy Green. Ransomware and the GDPR. I: Network Security (mars 2017), s DOI: /s (17) URL: /s (17) [13] Password Hashing. [Läst ]. Oracle URL: docs. oracle. com / cd / E26180 _ 01 / Platform. 94 / ATGPersProgGuide / html / s0506passwordhashing01.html. [14] Diomidis Spinellis. Git. I: IEEE Software (2012), s DOI: /MS [15] About GitLab. [Läst ]. URL: isgitlab/. [16] GitLab IDA information. [Läst ]. URL: https : / / www. ida. liu. se / gitlab/. [17] Slack. [Läst ]. URL: [18] Zoom. [Läst ]. URL: [19] Manifesto for agile software development. [Läst ] URL: https : / / agilemanifesto.org/. [20] Vincent Driessen. A successful Git branching model. [Läst ] URL: [21] React. [Läst ]. URL: [22] Johan Leitet. Single Page Applications. [Läst ]. Linnéuniversitetet. URL: http : / / coursepress. lnu. se / kurs / webbteknik - ii / forelasningar / single-page-applications/. [23] Material UI. [Läst ]. URL: [24] Flask. [Läst ]. URL: [25] Foreword - Flask Documentation (1.1.x). [Läst ]. URL: https : / / flask. palletsprojects.com/en/1.1.x/foreword/#what-does-micro-mean. [26] Mario Hoyos. What is an ORM and Why You Should Use it. [Läst ] URL: [27] The Python SQL Toolkit and Object Relational Mapper. [Läst ] URL: [28] Flask-SQLAlchemy. [Läst ] URL: https :// flask - sqlalchemy. palletsprojects.com/en/2.x/. [29] What Is SQLite? [Läst ] URL: html. [30] SQLite vs PostgreSQL - Which database to use and why. [Läst ] URL: [31] PostgreSQL: The World s Most Advanced Open Source Relational Database. [Läst ] URL: [32] Transaktioner. [Läst ] URL: http : / / www. databasteknik. se / webbkursen/transaktioner/index.html. [33] HTML Standard FAQ. [Läst ]. Web Hypertext Application Technology Working Group. URL: [34] Cascading Style Sheets. [Läst ]. World Wide Web Consortium. URL: https: // 126

136 Litteratur [35] Sandahl Kristian. What is a system anatomy? Föreläsningsslide URL: https: // [36] L. Williams. Integrating pair programming into a software development process. I: Proceedings 14th Conference on Software Engineering Education and Training. In search of a software engineering profession (Cat. No.PR01059). 2001, s URL: ieeexplore.ieee.org/document/ [37] Visual Studio Live Share. [Läst ]. URL: https : / / visualstudio. microsoft.com/services/live-share/. [38] Three-Tiered Distribution URL: https ://docs.microsoft. com /en - us / previous-versions/msp-n-p/ff647546%28v%3dpandp.10%29. [39] React-Konva. [Läst ] URL: index.html. [40] Canvas. [Läst ]. URL: https : / / developer. mozilla. org / en - US / docs/web/api/canvas_api. [41] Evan Czaplicki. Elm. [Läst ]. URL: [42] Django Software Foundation. Django. [Läst ]. URL: https : / / www. djangoproject.com/. [43] Bootstrap team. Bootstrap. [Läst ]. URL: [44] Jenkins. [Läst ]. URL: [45] Travis. [Läst ]. URL: [46] Circle. [Läst ]. URL: [47] GitLab CI. [Läst ]. URL: [48] Continuous practices. [Läst ]. URL: theory/09continuous%20practices% pdf. [49] K. Beck. Embracing change with extreme programming. I: Computer (1999), s [50] M. Meyer. Continuous Integration and Its Tools. I: IEEE Software 3 (2014). [51] Practices of Continuous Integration. [Läst ]. URL: https : / / martinfowler. com / articles / continuousintegration. html # PracticesOfContinuousIntegration. [52] Jest. [Läst ]. URL: [53] jsdom. [Läst ]. URL: [54] React testing. [Läst ]. URL: html. [55] A. Y. Mahmoud och M. N. A. Alqumboz. Encryption Based On Multilevel Security for Relational Database EBMSR. I: 2019 International Conference on Promising Electronic Technologies (ICPET). 2019, s [56] Europeiska unionens officiella tidning. EUROPAPARLAMENTETS OCH RÅDETS FÖRORDNING (EU) 2016/679. [Läst ]. Europeiska Unionen URL: https : / / eur - lex. europa. eu / legal - content / SV / TXT /?uri = OJ : L : 2016:119:TOC. [57] Microsoft SQL Docs team. Dynamic Data Maskings. [Läst ]. Microsoft URL: security/dynamic-data-masking?view=sql-server-ver

137 Litteratur [58] Microsoft SQL Docs team. Dynamisk data maskning för Azure SQL Database och Azure Synapse Analytics. [Läst ]. Microsoft URL: https : / / docs. microsoft.com/sv- se/azure/sql- database/sql- database- dynamicdata-masking-get-started. [59] SQL Server 2016 (New feature): How to use Dynamic Data Masking URL: https: // (hämtad ). [60] Microsoft SQL Docs team. Always Encrypted. [Läst ]. Microsoft URL: https : / / docs. microsoft. com / en - us / sql / relational - databases / security/encryption/always-encrypted-database-engine?view=sqlserver-ver15. [61] Microsoft. Transparent data encryption (TDE). Microsoft URL: microsoft. com / en - us / previous - versions / sql / sql - server / bb934049(v=sql.110)?redirectedfrom=msdn. [62] Margaret Rouse. Data at rest. TechTarget URL: https : / / searchstorage. techtarget.com/definition/data-at-rest. [63] Ken Mafli. SQL SERVER TDE VS CELL-LEVEL ENCRYPTION: A BRIEF COMPARI- SON. Townsend URL: https : / / info. townsendsecurity. com / sql - server-tde-vs-cell-level-encryption-a-brief-comparison. [64] Sourav Mukherjee. Popular SQL Server Database Encryption Choices. I: SSRG International Journal of Computer Science and Engineering (SSRG-IJCSE) (2018), s. 2. [65] MariaDB. VARBINARY. MariaDB URL: https : / / mariadb. com / kb / en / varbinary/. [66] Basit Aalishan Masood-Al-Farooq. Using Cell-Level Encryption in SQL Server. SQL servercentral URL: [67] Sourav Mukherjee. Popular SQL Server Database Encryption Choices. I: SSRG International Journal of Computer Science and Engineering (SSRG-IJCSE) (2018), s [68] Alice Kupcik. Transparent data encryption or always encrypted? Microsoft URL: https : / / azure. microsoft. com / es - es / blog / transparent - data - encryption-or-always-encrypted/. [69] Robert Sheldon. Encrypting SQL Server: Transparent Data Encryption (TDE). Wikipedia URL: https : / / www. red - gate. com / simple - talk / sql / sql - development/encrypting-sql-server-transparent-data-encryptiontde/. [70] Don Rubin Art Rask och Bill Neumann. Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server Bara relevant innan Microsoft URL: us/previous- versions/ sql / sql - server / administrator / cc966395(v = technet. 10 )?redirectedfrom=msdn. [71] Andrea Remuzzi och Giuseppe Remuzzi. COVID-19 and Italy: what next? I: The Lancet (2020), s DOI: [72] LiU i distansläge till höstterminens start URL: Personal/coronavirus?l=sv. [73] COVID-19 situation update worldwide, as of 4 May ECDC URL: www. ecdc. europa. eu / en / geographical - distribution ncov - cases. 128

138 Litteratur [74] Frågor och svar om covid-19 (coronavirus). Folkhälsomyndigheten URL: https: / / www. folkhalsomyndigheten. se / smittskydd - beredskap / utbrott / aktuella-utbrott/covid-19/fragor-och-svar/. [75] Subrat Patnaik. Zoom s daily active users jumped from 10 million to over 200 million in 3 months URL: daily- active-users-jumped-from-10-million-to-over-200-million-in-3- months/. [76] Microsoft Teams vs Zoom: Why You Should Consider Both URL: www. unifysquare.com/blog/microsoft- teams- vs- zoom- which- platformis-better-for-your-organization/. [77] Google Hangouts URL: com/definition/google-hangouts. [78] Steven John. Here s how many people can be in a Google Hangout call at a time, and how to start a video or phone call URL: [79] What is Discord? : Everything you need to know about the popular group-chatting platform URL: is- discord?r=us& IR=T. [80] What Is Skype and How Does It Work? URL: what-is-skype [81] Introducing Microsoft Teams the chat-based workspace in Office URL: https: / / www. microsoft. com / en - us / microsoft / blog / 2016 / 11 / 02 / introducing - microsoft - teams - the - chat - based - workspace - in - office-365/. [82] Unified Communications products URL: https : / / enlyft. com / tech / unified-communications. [83] Skype for Business Online Service Ending in 2 Years URL: com/articles/2019/07/30/microsoft- ending- skype- for- businessonline-service.aspx. [84] Systainable Development Goals for [Läst ]. United Nations. URL: https: //sustainabledevelopment.un.org/?menu=1300. [85] Abhijit Chakraborty, Mrinal Baowaly, Utsho A Arefín och Ali Newaz Bahar. The Role of Requirement Engineering in Software Development Life Cycle. I: Journal of Emerging Trends in Computing and Information Sciences 3 (maj 2012), s [86] C. Becker, R. Chitchyan S. Betz, L. Duboc, S. M. Easterbrook, B. Penzenstadler och C. C. Venters. Requirements: The key to sustainability. I: IEEE Software 33(1) (jan. 2016). DOI: /MS [87] W. Ulrich. A Brief Introduction to Critical Systems Heuristics (CSH). I: Web site of the ECOSESNSUS project (okt. 2005). [Läst ]. URL: open.ac.uk/ecosensus/publications/ulrich_csh_intro.pdf. [88] OWASP Top Ten. [Läst ]. OWASP. URL: https : / / owasp. org / www - project-top-ten/. [89] Waterfall Software Development Model. [Läst ] URL: www. oxagile.com/article/the-waterfall-model/. [90] Jeff Sutherland Ken Schwaber. The Scrum Guide. [Läst ] URL: https: //scrumguides.org/scrum-guide.html. [91] Agile 101. [Läst ] URL: https : / / www. agilealliance. org / agile101/. 129

139 Litteratur [92] Martin Comstedt. Grunderna i Scrum roller, begrepp och aktiviteter. [Läst ] URL: [93] Introducing the GitLab Issue Board. [Läst ] URL: https : / / about. gitlab.com/stages-devops-lifecycle/issueboard/. [94] Understanding the Scrum Burndown Chart. [Läst ] URL: https : / / [95] Advancing Technology for Humanity. [Läst ] URL: https : / / ieeexplore.ieee.org/xplore/home.jsp. [96] Burndown Charts. [Läst ] URL: user/project/milestones/burndown_charts.html. [97] A. Mundra, S. Misra och C. A. Dhawale. Practical Scrum-Scrum Team: Way to Produce Successful and Quality Software. I: th International Conference on Computational Science and Its Applications. Juni 2013, s [98] R. T. Hans. Work in Progress - The Impact of the Student Scrum Master on Quality and Delivery Time on Students Projects. I: 2017 International Conference on Learning and Teaching in Computing and Engineering (LaTICE). April 2017, s [99] Motivation. [Läst ] URL: https : / / redux. js. org / introduction/motivation. [100] Thinkster. RealWorld example apps. [Läst ] URL: com/gothinkster/realworld. [101] React. [Läst ]. Facebook Inc URL: getting-started.html. [102] Introducing Hooks. [Läst ] URL: https : //reactjs. org /docs / hooks-intro.html. [103] [Läst ]. URL: [104] React and Redux. [Läst ]. Carl von Ossietzky University of Oldenburg URL: reader-seminar-ws2016.pdf#page=14. [105] [Läst ] URL: [106] Redux Crash Course With React. [Läst ]. Traversity Media URL: https: // [107] How to convert your existing Redux containers to Hooks. [Läst ] URL: [108] How to Fetch Data in React Redux using Hooks. [Läst ] URL: https: //reactgo.com/redux-hooks-fetch-data/. [109] [Läst ] URL: [110] Will Faurot Marc Garreau. Redux in Action. ISBN Manning Publications, 2018, s [111] on-premises. [Läst ]. IT-ord. URL: ord.idg.se/ord/onpremises/. [112] Anastasia Yaskevich. Software Business Models: What Works for Your Product? [Läst ]. ScienceSoft. URL: www. scnsoft. com/ blog/ softwarebusiness-models-explained. 130

140 Litteratur [113] Bret Waters. Software as a service: A look at the customer benefits. I: Journal of Digital Asset Management 1.1 (jan. 2005), s DOI: /palgrave.dam URL: [114] Risto Rajala och Jussi Nissilä. Revenue Models in the Open Source Software Business. I: Handbook of Research on Open Source Software. IGI Global, 2007, s DOI: / ch042. URL: ch042. [115] A. Ojala. Software-as-a-Service Revenue Models. I: IT Professional 15.3 (2013), s [116] Datainspektionen - Regeringen.se. [Läst ]. URL: https : / / www. regeringen.se/myndigheter-med-flera/datainspektionen/. [117] Europeiska unionens officiella tidning. EUROPAPARLAMENTETS OCH RÅDETS FÖRORDNING (EU) 2016/679. [Läst ]. Europeiska Unionen URL: https : / / eur - lex. europa. eu / legal - content / SV / TXT /?uri = OJ : L : 2016:119:TOC. [118] Barbara Kollmeyer. Chicago Tribune, Los Angeles Times go dark in Europe after GDPR fail. [Läst ] URL: https : / / www. marketwatch. com / story / chicago- tribune- la- times- go- dark- in- europe- after- gdpr- fail [119] Tillsynsbeslut. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen.se/om-oss/arbetssatt/tillsyn/tillsynsbeslut/. [120] Vad kan tillsynen leda till? [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / om - oss / arbetssatt / tillsyn / vad - kan - tillsynen-leda-till/. [121] Sarah Spiekermann. The Challenges of Privacy by Design. I: Commun. ACM 55.7 (juli 2012), s ISSN: DOI: / URL: https: //doi.org/ / [122] Vad är egentligen en personuppgift? [Läst ]. Datainspektionen. URL: https: // www. datainspektionen. se/ vagledningar/ en- introduktion- tilldataskyddsforordningen/vad-ar-en-personuppgift/. [123] När känsliga personuppgifter får behandlas. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen/ kansliga- personuppgifter/ nar- kansligapersonuppgifter-far-behandlas/. [124] Detta är känsliga personuppgifter. [Läst ]. Datainspektionen. URL: www. datainspektionen. se/ lagar-- regler/ dataskyddsforordningen/ kansliga-personuppgifter/detta-ar-kansliga-personuppgifter/. [125] Personuppgiftsansvariga och personuppgiftsbiträden. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen / personuppgiftsansvariga - och - personuppgiftsbitraden/. [126] Rättslig grund för personuppgiftsbehandling. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen/rattslig-grund/. [127] Samtycke. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen / rattslig-grund/samtycke/. 131

141 Litteratur [128] Avtal med den registrerade. [Läst ]. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen / rattslig-grund/avtal-med-den-registrerade/. [129] Tillsyn enligt EU:s dataskyddsförordning 2016/679 ansiktsigenkänning för närvarokontroll av elever. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / globalassets / dokument / beslut / beslut - ansiktsigenkanning- for- narvarokontroll- av- elever- dnr- di pdf. [130] Dataskyddsförordningens grundläggande principer. [Läst ]. Datainspektionen. URL: https : / / www. datainspektionen. se / lagar -- regler / dataskyddsforordningen/grundlaggande-principer/. 132

142 I Bilaga 1: Kravspecifikation 133

143 TDDD96 15 maj I N T R O D U K T I O N I kravspecifikationen tas upp de krav som finns på projektet. Dessa krav har diskuterats och arbetats fram av projektgruppen och beställaren. 1.1 Syfte Syftet med denna kravspecifikation är att vara ett underlag för kommunikation mellan kunden och projektgruppen angående de krav som ställs på det byggda systemet. Målgruppen för dokumentet är kunden och projektgruppen. Kravspecifikationen ska nyttjas av projektgruppen för att planera sitt arbete på ett sådant sätt att åtminstone alla grundkrav uppfylls. Kraven är skrivna entydigt och på ett mätbart sätt som gör det enkelt att avgöra om kraven är uppfyllda. Slutligen har varje krav en prioritet, vilket förklaras närmare i avsnitt Omfattning Projektet - Visuell hantering av behörigheter till lokaler - är ett kandidatprojekt i programvaruutveckling vid Linköpings universitet med Ericsson som kund. Det system som byggs kommer att bli ett interaktivt webbaserat gränssnitt för hantering av behörigheter till lokaler. Gränssnittet är designat och byggt till att användas på datorer - alltså inte på mobiltelefoner eller andra typer av enheter. Det skall finnas roller i systemet där varje roll har sina specifika funktioner. Exempelvis skall de användare som tillhör rollen med lägsta behörighetsnivån kunna lägga beställningar på rum som de önskar få tillträde till. Vidare skall de användare som har ansvar för lokaler kunna bevilja eller frånta tillträden till rum. Övriga systemfunktioner beskrivs närmare i avsnitt 2.1. Systemet skall utgå från en karta över ett hus i Linköpings universitet. Se kartan i figur 1. Figur 1: Karta över byggnaden B-huset vid Linköpings universitet. 1 TDDD96 Kandidatprojekt i programvaruutveckling Kravspecifikation 134