accepteras. Det resulterade i att allting som låg i huvudgrenen testades en extra gång och kontrollerades följa den uppsatta standarden.
4.3.10
Riskanalys
I samband med projektstarten gjordes en riskanalys. Tabell 4.5 visar de risker som projekt- gruppen identifierade, där sannolikhet och konsekvens rangordnades på en skala 1-5 där 5 är högst och 1 är lägst. Projektgruppen arbetade under projektets gång med dessa risker i åtanke, där varje projektmedlem försökte hantera riskerna på ett rimligt vis för att minimera deras påverkan på projektet.
Tabell 4.5: Riskanalys
Riskbeskrivning Sannolikhet Konsekvens Total på-
verkan Åtgärd
Dålig gruppsam-
manhållning 2 5 10
Samtal med handledare/ kursansvarig
Kursavhopp 1 3 3
Omplanering, eventuellt minska på aktiviteter. I sista hand omförhandla med kund
Missförstånd med
kund 4 2 8
Kontinuerlig avstämning med kund
Serverfel 2 2 4 Tillhandahålla ny server
Lokalbrist 2 4 8 Diskussion med kursan-
svarig Webbapplikationen
fungerar inte i alla webbläsare
1 5 5 Programmera mot kun-
dens webbläsare
4.4
Metod för att fånga erfarenheter
Arbetssättet gav goda förutsättningar för alla medlemmar att dra lärdom av varandras arbete. Under de veckovisa genomgångarna fick var och en av medlemmarna förklara vad de gjort under den senaste veckan. Då fanns även tillfälle för de övriga medlemmarna att ställa frågor om de var nyfikna på någonting.
I slutet av varje sprint hölls en sprintåterblick för att gruppmedlemmarna gemensamt skulle reflektera över erfarenheter från den gångna sprinten. På så sätt kunde de komma fram till vad som skulle kunna göras annorlunda under nästa sprint. Under alla möten fördes även protokoll vilket innebar att om en projektmedlem var frånvarande så fanns ändå möjligheten att ta del av det som togs upp.
5
Resultat
I detta kapitel presenteras projektets resultat. I resultatet ingår en systembeskrivning av det slutgiltiga systemet, vad projektet har för värde för kunden, de gemensamma erfarenheterna som fåtts under projektet samt en översikt över de individuella bidragen.
5.1
Systembeskrivning
Systemet är en webbapplikation, med tillhörande databas, för att kunna registrera och spåra kort, handlingar och leveranser samt generera och hantera kvittenser för kort och handlingar. Systemet är även till för att lätt kunna se inventeringsunderlag och skriva ut relevanta doku- ment i PDF-format. En användare av systemet kan med hjälp av ett webbgränssnitt registrera nya kort, handlingar och leveranser. Kort och handlingar kan sedan kvitteras ut och spåras för att se var dessa finns just nu och se vem som använder dem. Leveranser kan inte kvitte- ras eftersom dessa är dokument som är skapta internt på företaget och levererade till andra företag.
5.1.1
Ingående delsystem
Webbapplikationen består av tre delar. En front-end applikation som har utvecklats i ram- verket Angular 5, en API back-end som är skriven i TypeScript (NodeJS) och en MariaDB databas, se figur 5.1. Hela applikationen körs på en Ubuntu 16.04 server.
I front-end används färdiga komponenter från biblioteken Bootstrap 4 och Material Design for Angular för bland annat knappar, inmatningsfält och modaler. Webbapplikationen är en single-page application.
5.1. Systembeskrivning
5.1.2
Systemanatomi
Den systemanatomi som projektgruppen tog fram i början av projektet har med tiden utveck- lats och använts som underlag för systemets funktionalitet och uppbyggnad. Systemanato- min kan ses i figur 5.2.
Kommunikation Hårdvara Serverfunktioner Display Tjänster Registrera handlingar Generera dokument Registrera kvittenser Användar- inloggning Utforska innehåll Lista
innehåll Lista loggar
Filtrera Ändra innehåll Användar- inloggning input Kvittenser input Välja dokument- innehåll Handlingar input Kvittens i pdf Logga in användare Generera dokument Spara dokument Registrera kvittens i databas Registrera handling i databas Ändra i databas Hämta information Kommunikation med server Ström Figur 5.2: Systemanatomi
5.1.3
Användarhantering
För att använda webbapplikationen krävs ett användarkonto. En användare eller administ- ratör loggar in till sitt konto med hjälp av sitt unika användarnamn och ett lösenord.
Vanliga användare
En vanlig användare har tillgång till två olika vyer. Den första är en vy över kort och hand- lingar som användaren har kvitterat ut. Den andra är en vy där användaren kan utföra egen- kontroller, vilket innebär att användaren intygar att ett kort eller en handling finns där det ska vara.
5.1. Systembeskrivning
Administratörer
Administratörsanvändare skiljer sig från vanliga användare genom att dessa användare inte kan ha några kort eller handlingar utkvitterade till sig. Istället är det administratörerna som kvitterar ut kort och handlingar till vanliga användare.
Kort, handlingar och leveranser har egna vyer med tabeller där administratören kan lägga till eller ändra objekt av respektive typ. Administratören har även en vy för att göra en invente- ring. En inventering bekräftar att ett kort eller en handling finns där det ska vara. Detta liknar en egenkontroll, som görs av en vanlig användare, men är istället gjord av en administratör. För att se vad som tidigare har gjorts finns det en vy för loggar. Det finns även en vy som visar alla användare där administratören kan lägga till nya användare eller ändra information som rör en befintlig användare. Till sist finns en vy som visar alla kort- och handlingstyper där administratören kan lägga till nya typer eller ändra information om befintliga typer.
Back-end hantering
När en ny användare ska läggas till i databasen skapas en hash av lösenordet som angivits genom att hashfunktionen bcrypt appliceras på lösenordssträngen. Sedan sparas aldrig det faktiska lösenordet i databasen utan bara dess hashvärde. När en användare gör ett inlogg- ningsförsök appliceras samma hashfunktion på det angivna lösenordet och resultatet jämförs med det som finns lagrat i databasen. Om strängarna är lika betyder det att lösenordet som angivits måste vara lika med det ursprungliga lösenordet. Genom att aldrig spara de faktis- ka lösenorden i databasen skyddas användarna om en obehörig skulle stjäla lösenorden från databasen.
5.1.4
UI-design
Fokuset för webbapplikationens UI-design är att den ska vara lätt att använda och samtidigt ha en simpel design. Det ska vara enkelt för en användare att navigera och uppnå det an- vändaren vill med så få knapptryck som möjligt. Detta möjliggjordes, efter att användaren loggat in i webbapplikationen, genom en tydlig meny till vänster som kan ses i figur 5.3. Genom denna meny, som alltid är synlig, kan användaren navigera till alla flikar i webbap- plikationen. När en flik väljs visas information till höger om menyn. Fokus har lagts på att de olika flikarna ska vara enhetliga i sin design, därav visas alla flikars information i form av tabeller, se figur 5.4.
5.1. Systembeskrivning
Figur 5.3: Meny till vänster i webbapplikationen
Figur 5.4: Tabell med information om handlingar
5.1.5
UX-design
Målet med webbapplikationens UX-design var att alla klickbara element skulle vara tydliga och att det skulle vara enkelt att förstå vad som händer när användaren klickar på en specifik knapp. För att beskriva hur webbapplikationen fungerar visas tre typiska användningsfall som webbapplikationen kommer att användas till. Alla användningsfall är utförda av en ad- ministratörsanvändare.
5.1. Systembeskrivning
1. Kvittera ut ett specifikt kort
Det första en användare ser i webbapplikationen är en inloggningssida. När en användare ska kvittera ut ett kort behöver användaren först logga in. Detta görs genom att fylla i använ- daruppgifter i fälten för användarnamn och lösenord samt sedan klicka på logga in, se figur 5.5.
Figur 5.5: Inloggningssida
Efter att användaren loggat in klickar användaren på fliken kort. En tabell med alla tillgäng- liga eller utkvitterade kort visas då till höger om menyn, se figur 5.6.
5.1. Systembeskrivning
Eftersom användaren vill kvittera ut ett specifikt kort filtrerar användaren på det unika kort- id som kortet har genom att skriva detta kort-id i sökfältet. Det aktuella kortet är nu det enda kortet som finns kvar i tabellen, se figur 5.7.
Figur 5.7: Tabell med kort filtrerat på ett kort-id
Användaren klickar på knappen KVITTERA UT. En modal kommer då upp som visar infor- mation om kortet och ber användaren fylla i användarnamn, datum och ny förvaringsplats för kortet, se figur 5.8.
5.1. Systembeskrivning
Det finns också möjlighet att skriva en kommentar och att generera en kvittens i form av ett PDF-dokument. När användaren klickar på KVITTERA UT i modalen kvitteras kortet ut. Om alternativet att generera kvittens är ifyllt får användaren två val, att ladda ned dokumentet eller att öppna det i en ny flik i webbläsaren, se figur 5.9.
Figur 5.9: Modal för val gällande PDF-dokument
2. Skriva ut en specifik inventeringslista och verifiera inventering
I detta användningsfall utförs samma inloggning som i det förra fallet. Efter inloggningen klickar användaren på fliken inventering. En tabell med alla tillgängliga eller utkvitterade kort och handlingar visas då till höger om menyn, se figur 5.10.
5.1. Systembeskrivning
Användaren vill i det här fallet inventera alla kort av typen GEID och sorterar därför efter typ genom att klicka på fältet typ, se figur 5.11.
Figur 5.11: Sortering efter typ av kort
Användaren markerar sedan alla kort av typen GEID genom att klicka på kryssrutan på ra- den, se figur 5.12.
Figur 5.12: Alla kort av typen GEID är markerade
Sedan klickar användaren på knappen Generera PDF. En modal kommer då upp som frågar användaren om en PDF ska genereras från de framfiltrerade resultatet eller de markerade
5.1. Systembeskrivning
Figur 5.13: Valmöjlighet vid generering av PDF-dokument från inventeringstabellen
Användaren får sedan två val, att ladda ned PDF-dokumentet eller att öppna det i en ny flik i webbläsaren. Användaren laddar ned dokumentet och stänger modalen. Efter att användaren fysiskt har inventerat korten klickar användaren på knappen Verifiera. Efter att användaren har bekräftat verifieringen i en modal är verifieringen genomförd vilket kan ses genom att datumet för senaste verifieringen har uppdaterats, se figur 5.14.
5.1. Systembeskrivning
3. Lägga till en ny handling i systemet
Även i detta användarfall måste inloggning utföras, precis som i de tidigare fallen. När detta är gjort klickar användaren på fliken handlingar, se figur 5.15.
Figur 5.15: Tabell med handlingar
Användaren klickar nu på knappen Lägg till ny handling. Det kommer då upp en modal som ber användaren fylla i 7 obligatoriska informationsfält för handlingen. Det finns även möjlig- het att lägga till en kommentar, se figur 5.16.
5.1. Systembeskrivning
När modalen är korrekt ifylld klickar användaren på knappen SPARA. Handlingen är nu tillagd i systemet. För att visa mer detaljer kring handlingen kan användaren klicka på hand- lingens rad i tabellen. En modal kommer då upp som visar alla detaljer kring handlingen, se figur 5.17.
Figur 5.17: Modal för detaljer om en handling
5.1.6
PDF-generering
Vid genereringen av en PDF skickas all relevant data till servern där den stoppas in i en mall. Detta gäller för alla kvittenser, inventeringar och liststrukturer. PDF:erna i detta projekt genereras med hjälp av biblioteken html-pdf och ejs [23, 24].
Vid utkvittering skapas två nästan identiska sidor, en för registratorn och en för användaren, exempel på användarkopian kan ses i figur 5.18. På användarkopian finns utöver information om kortet och plats för signaturer, även utrymmen för att göra egenkontroller. Det innebär alltså att en användare kan manuellt verifiera att kortet eller handlingen fortfarande finns där det ska vara utan att behöva logga in i SecTrack. Skillnaden mellan registratorkopian och användarkopian är att registratorkopian inte innehåller några fält för egenkontroller.
Då PDF:erna för inventeringen och listorna inte har någon bestämd storlek behövs mallar som kunde ha en dynamisk storlek. På så sätt kan mallarna fyllas i med en större mängd objekt i taget. Efter att mallen sedan konverteras till den slutgiltiga PDF:en syns typen och ID:t för kortet eller handlingen, platsen objektet förvaras på, vilken användare, om någon, som har hand om kortet eller handlingen och den kommentar som tillhör objektet. Ett exempel på en sådan lista kan ses i figur 5.19.
5.1. Systembeskrivning
5.1. Systembeskrivning
Figur 5.19: Inventeringsmall
5.1.7
Databasstruktur
För att lagra all data i SecTrack användes en databas med 14 olika tabeller. De primära tabel- lerna, som utgör hälften av alla tabeller, är de tabeller som innehåller objekt för att visas upp i någon av webbapplikationens tabellistor. I figur 5.20 visas databasens primära tabeller samt deras fält. De kvarvarande sju sekundära tabellerna innehåller objekttyper. Figur 5.21 visar databasens sekundära tabeller samt deras fält.
5.1. Systembeskrivning
Figur 5.20: Databasens primära tabeller
5.1. Systembeskrivning
Figur 5.22: Fullständig struktur med länkar för tabellen Dokument
I databasen finns flera fält länkade till andra fält. Exempelvis länkar fältet Dokumenttyp ID i tabellen Dokument till fältet ID som finns i tabellen Dokumenttyp. Den fullständiga strukturen med länkar för tabellen Dokument visualiseras i figur 5.22. På liknande sätt är andra tabeller länkade till olika delar av databasen, vilket medför att ingen data i databasen dupliceras. De olika fältens syfte i de olika tabellerna är följande:
• Aktiv kvittens: Länk till fältet ID i tabell Kvittens.
• Användarnamn: Användarnamn för att logga in i systemet. • Användartyp ID: Länk till fältet ID i tabell Användartyp. • Avsändare ID: Länk till fältet ID i tabell Användare.
• Dokument ID: Länk till fältet ID i tabell Dokument. Enbart ett av fälten Kort ID och Dokument ID kan ha ett värde som indexerar mot respektive tabell. Vilket fält som är aktivt bestäms av fältet Objekt typ ID.
• Dokument datum: Daterat datum på objektet.
5.1. Systembeskrivning
• Dokumenttyp ID: Länk till fältet ID i tabell Dokumenttyp. • ID: Unik identifierare för varje objekt i respektive tabell.
• Kommentar: En eventuell kommentar till objektet som kan till exempel beskriva vad objektet är till för eller vad en användare får göra.
• Kort ID: Länk till fältet ID i tabell Kort. • Kortnummer: Unikt serienummer för ett kort. • Korttyp ID: Länk till fältet ID i tabell Korttyp. • Logg data: Beskrivning av händelsen för loggen. • Logg datum: Datum som loggen fördes in i databasen. • Loggtext: En beskrivning av vad loggningstypen innebär. • Loggtyp ID: Länk till fältet ID i tabell Loggtyp.
• Lösenord: Krypterat lösenord för att logga in i systemet. • Mejl: Kontoinnehavarens mejladress.
• Modifierat datum: Datum som objektet senast är modifierad i databasen, exempelvis då objektet bytte förvaringsplats eller kvitterades.
• Mottagare: Mottagare av leveransen.
• Namn (Användare): Förnamn och efternamn för kontoinnehavaren. • Namn: Namn eller beskrivning på objektet.
• Objekt typ ID: Länk till fältet ID i tabell Objekttyp för att specificera vilken typ objektet är, exempelvis ett kort eller en handling.
• PDF namn: Namn på genererad PDF.
• Plats: En fysisk plats som objektet förvaras när den inte används.
• Registrerat datum: Datumet som dokumentet registreras som inkommet, ej nödvän- digtvis samma datum som dokumentet förs in i databasen.
• Senast verifierad: Datum då objektet senast verifierades. • Skapat datum: Datum som objektet är inlagd i databasen. • Skickat datum: Datumet då objektet skickades.
• Slut datum: Datum för inkvittering av ett objekt. • Start datum: Datum för utkvittering av ett objekt.
• Status ID: Länk till fältet ID i tabell Statustyp som beskriver vilket tillstånd objektet befinner sig i. Exempel på status är utkvitterat och arkiverat.
• Sändare: Personen eller organisationen som skickat dokumentet. • Utgångsdatum: Utgångsdatum för ett kort.
5.2. Värde för kunden
5.2
Värde för kunden
Projektet har givit värde för kunden genom att de fått tillgång till ett bättre alternativ till deras nuvarande system. Produkten kommer förbättra effektiviteten i arbetet och underlätta organiseringen. En annan värdefull aspekt med projektet är att det är enkelt att vidareutveck- la systemet. Detta eftersom systemet är utvecklat med det modulära ramverket Angular och levererades med dokumentation som beskriver det. Kunden kan själv lägga till funktionalitet som de känner saknas eller kommer på vid ett senare tillfälle.
5.3
Gemensamma erfarenheter
Projektets medlemmar hade sedan tidigare erfarenhet av att arbeta i grupp, men aldrig i ett mjukvaruprojekt av den här storleken. För att alla projektmedlemmar skulle kunna arbeta effektivt i gruppen krävdes att projektmedlemmarna höll god kontakt med varandra. Detta för att försöka undvika att samma arbete utfördes på flera håll, eller på ett onödigt krångligt sätt. Projektgruppen försökte ofta sitta tillsammans och arbeta, men eftersom att det vid vissa tillfällen inte fanns en ledig lokal så var detta inte alltid möjligt. Flera medlemmar i gruppen tyckte också att det var enklare att programmera hemifrån, där en bättre dator fanns tillgäng- lig. Detta ledde till att gruppen arbetade tillsammans mer sällan mot slutet av projektet. Kon- takt mellan gruppmedlemmar hölls då via Slack och möten, vilket fungerade bra, men det hade troligtvis fungerat bättre om gruppen arbetat tillsammans eftersom kommunikationen då blir smidigare.
Alla medlemmar i projektet hade någon form av tidigare erfarenhet gällande versionshan- tering, dock saknade vissa projektmedlemmar erfarenhet av utvecklingsmodellen Feature Branch Workflow som projektgruppen använde sig av. Detta ledde ibland till väldigt stora sammanfogningsförfrågningar, som vidare ledde till många konflikter i koden. Ibland hände det att flera sammanfogningsförfrågningar hamnade i kö, vilket hade som konsekvens att projektmedlemmen som skickat in sin sammanfogningsförfrågan sist, fick revidera sin kod att passa med den projektmedlem som skickat in sin kod först. Dessa konflikter ledde till att de möten vi hade för att granska och slå samman kod ibland tog väldigt lång tid.
Samtliga projektmedlemmar har lärt sig mycket inom webbprogrammering, speciellt med ramverket Angular 5. Flera av projektmedlemmarna hade ingen tidigare erfarenhet av var- ken webbprogrammering eller Angular, vilket ledde till en stor ökning i kunskap inom des- sa områden. En av projektmedlemmarna hade sedan tidigare erfarenhet av både webbpro- grammering och Angular vilket var till stor hjälp för projektgruppen, speciellt i början av utvecklingen. Projektgruppen har under hela projektet bytt erfarenheter och försökt hjälpa varandra med problem som uppstått. Detta har bidragit till en god gruppdynamik och ett bra kunskapsutbyte mellan samtliga projektmedlemmar.
För flera av projektmedlemmarna var detta första gången som de arbetade med iterationer och Scrum. Det har varit en givande erfarenhet, speciellt eftersom planeringen av projektet skett kontinuerligt istället för vid projektets start. Detta medförde även att hela projektgrup- pen blev involverad i alla moment av planeringen, vilket gett en bättre helhetsblick över projektet för alla projektmedlemmar.