Datavetenskap. Viktor Samuelsson, Gustaf Åhs. Certifieringswebb. Examensarbete 2017:06

Datavetenskap Viktor Samuelsson, Gustaf Åhs Certifieringswebb Examensarbete 2017:06

Denna rapport är skriven som en del av det arbete som krävs för att erhålla en kandidatexamen i datavetenskap. Allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt identifierat och inget material är inkluderat som tidigare använts för erhållande av annan examen. Viktor Samuelsson, Gustaf Åhs Godkänd, Juni 7, 2017 Handledare: Donald F. Ross Examinator: Lothar Fritsch iii

Sammanfattning I denna uppsats presenteras allt arbete för att utveckla en webbapplikation, allt från att ta fram en kravspecifikation till implementering och demonstration av en prototyp. Tillgängligheten för en webbapplikation kan komma med diverse restriktioner. Restriktionen i detta fallet är att tillgång endast ges till de användare som är anställda hos Sogeti Karlstad och finns inlagda på den server som finns hos företaget. Tillgång till applikationen för andra kontor i Sverige är ännu ej implementerat. Målet med utvecklingen av webbapplikationen är att förenkla hanteringen av certifieringar som i dagsläget görs genom ett Excelark som administratören använder sig av samt att förbättra tillgängligheten till informationen för de anställda hos Sogeti. Ett viktigt krav som ställdes var att skapa en form av tävlingskänsla hos de anställda för att kunna öka tagandet av certifieringar, vilket resulterar i värde för så väl företaget som anställd. I uppsatsens två sista kapitel utvärderas projektets tekniska och icke tekniska delar både i sin helhet och i viss detalj för olika moment i projektet. Nyttig information både för deltagarna i projektet så väl som för framtida studenter om vad som kan vara bra att tänka på både innan man åtar sig ett projekt och när man ska starta upp ett projekt. Alla de essentiella krav i kravspecifikationen uppfylldes vilket resulterade i ett lyckat projekt. v

Abstract This report presents the work performed to develop a web application, ranging from producing a requirements specification to the implementation and a demonstration of a prototype. The availability of a web application may come with various restrictions. The restriction in this case is that access is only given to employees at Sogeti Karlstad listed on the company s server. Access to the application by other offices in Sweden is not yet implemented. The goal of the development of this particular web application is to simplify the management of certificates currently using Excel spreadsheets and improve accessibility of the information for Sogeti employees. An important requirement was to create a sense of competition among employees in order to increase the number of certificates taken, which results in increased value for Sogeti as well as for those employees. In the last two chapters of the report, the project s technical and non-technical parts are evaluated both in their entirety and in some detail of different parts of the project. This information can be useful for future students about what to take into consideration before committing to a new project. All of the essential requirements in the requirement specification were fulfilled which led to a successful project. vi

Tack Vi vill tacka vår handledare på Karlstad universitet, Donald F. Ross, för den ovärderliga hjälp han bistod med, som korrekturläsning av uppsatsen samt värdefulla synpunkter till projektet. Vi vill även tacka Åsa Maspers, Mats Persson och Thomas Heder som har agerat kunder och handledare samt bistått med värdefull hjälp. Till sist vill vi tacka Sogeti för att vi fick chansen att genomföra vårt examensarbete hos dem. vii

Innehåll 1 Introduktion 1 1.1 Projektöverblick................................. 1 1.2 Disposition................................... 1 2 Bakgrund 3 2.1 Sogeti...................................... 3 2.2 Problem..................................... 3 2.3 Syfte....................................... 4 2.4 Prototyp..................................... 4 2.5 Mål........................................ 4 2.6 Tekniker..................................... 5 2.6.1 MVC................................... 5 2.6.2 ASP.NET & ASP.NET MVC Framework............... 6 2.6.3 Bootstrap................................ 6 2.6.4 Entity Framework............................ 6 2.7 Verktyg..................................... 7 2.7.1 Visual Studio 2015 Enterprise..................... 7 2.7.2 SQL Server Management........................ 7 2.7.3 Team Foundation Server (TFS).................... 7 2.8 Sammanfattning................................ 8 3 Förarbete 9 3.1 Introduktion................................... 9 3.2 Kravhantering.................................. 9 3.2.1 Kravspecifikation............................ 9 3.2.2 Workshop................................ 9 3.2.3 Slutlig kravspecification........................ 10 viii

3.3 Databasmodell................................. 10 3.4 Scrum...................................... 12 3.5 Team Foundation Server (TFS)........................ 12 3.6 Sammanfattning................................ 13 4 Projektdesign 14 4.1 Introduktion................................... 14 4.2 Databasdesign.................................. 14 4.3 SQL Manager.................................. 15 4.4 Scrum...................................... 16 4.5 Databasmodeller................................ 17 4.6 Kopplingsmodeller............................... 18 4.7 Kopplingstabeller................................ 19 4.8 Vyer....................................... 20 4.9 Sprintar..................................... 20 4.9.1 Sprint 1................................. 21 4.9.2 Sprint 2................................. 21 4.9.3 Sprint 3................................. 22 4.9.4 Sprint 4................................. 23 4.10 Sammanfattning................................ 23 5 Projektimplementering 24 5.1 Introduktion................................... 24 5.2 Implementeringstekniker av databasen.................... 24 5.2.1 Code first................................ 24 5.2.2 Database first.............................. 24 5.3 Sprintar..................................... 25 5.3.1 Sprint 1................................. 25 ix

5.3.2 Sprint 2................................. 26 5.3.3 Sprint 3................................. 28 5.3.4 Sprint 4................................. 34 5.4 Problem & Inlärningströskel.......................... 35 5.4.1 Code first vs Database first...................... 35 5.4.2 Dynamisk funktionalitet........................ 36 5.5 Sammanfattning................................ 36 6 Utvärdering 38 6.1 Sprintar..................................... 38 6.1.1 Sprint 0................................. 38 6.1.2 Sprint 1................................. 39 6.1.3 Sprint 2................................. 39 6.1.4 Sprint 3................................. 39 6.1.5 Sprint 4................................. 40 6.2 Demonstration................................. 40 6.3 Tillvägagångssätt................................ 41 6.4 Sammanfattning................................ 42 7 Slutsats 43 7.1 Projektsammanfattning............................. 43 7.2 Utvecklingsmiljö................................. 43 7.3 Databas..................................... 44 7.4 Vidareutveckling................................ 44 7.5 Prototypens framtid.............................. 44 Referenser 45 A 47 x

A.1 Förklaring av kravspecifikation........................ 47 A.1.1 Certifieringar och titlar......................... 47 A.1.2 Användare och administratör..................... 47 A.1.3 Sökning och filtrering.......................... 48 A.1.4 Gamification/Statistik......................... 48 A.1.5 Språk och autentisering......................... 48 A.2 Kravspecifikation................................ 49 B 52 B.1 Bilder...................................... 52 xi

Figurer 2.1 MVC-arkitekturen och en användares interaktion............... 5 3.1 Första databasmodellen............................ 11 3.2 De moment som ingår i Scrum [14]....................... 12 4.1 Jämförelse av implementeringsteknikerna Code first och Database first... 15 4.2 De tre huvudentiteter som utgör projektet................... 17 4.3 Certifieringar bundna till Titel 1........................ 18 5.1 Redigering av en anställd............................ 25 5.2 Tabell över de anställda och dropdownmeny för administratör........ 26 5.3 Bindning mellan Certifiering och Anställd................... 27 5.4 Titel väljs genom val i dropdownlistan..................... 27 5.5 Titel väljs genom sökning i dropdownlistan.................. 28 5.6 My Certificates på My Page.......................... 29 5.7 My Progress på My Page............................ 30 5.8 Graf över tagna certifieringar under året, månad för månad......... 31 5.9 Topplistor alla anställda............................ 32 5.10 Topplistor lokalt kontor............................. 33 5.11 Topplistor kontor................................ 34 5.12 Sökning på kontor vars namn innehåller G.................. 35 B.1 Topplistor regioner............................... 52 B.2 Topplistor kontor................................ 52 B.3 Sida för Titlar och Certifieringar........................ 53 xii

1 Introduktion Projektet kommer att utföras tillsammans med Sogeti Karlstad, som kommer att agera både kund och mentor under de 20 veckor som projektet kommer att ta. Projektets centrala del kommer att vara hanteringen av så kallade certifieringar och titlar som är en form av kompetensbevis som en anställd hos Sogeti kan ta. Dessa bevis ger värde för både företag och anställd. Sogetis värde i detta är att bevisen kan visas upp gentemot en kund för att påvisa att den kompetens som behövs för ett uppdrag faktiskt finns inom företaget och på så sätt öka sina chanser till att få in ett uppdrag. Den anställdes värde ligger dels i en ekonomisk ersättning vid erhållandet av en certifiering samt att denne ökar sitt värde för företaget och på så sätt kan ta på sig fler typer av uppdrag. 1.1 Projektöverblick Syftet med detta projektet är att ta fram en webbapplikation till Sogeti för att underlätta den hantering och tillgänglighet av certifieringar och titlar som idag görs genom ett Excelark. Dagens lösning försvårar båda dessa delar på grund av att arket lagras lokalt hos en administratör som manuellt måste lägga till eller uppdatera det för att det ska vara aktuellt gentemot kunder. För att få tillgång till informationen i arket krävs det att administratören skickar hela arket till den person som vill ha det och denne får då bilda sig en uppfattning av vilka olika certifieringar som är tagna då det inte är helt lätt att utläsa vem som har tagit vilken certifiering. Tanken blir då att automatisera de delar som är möjliga samt att göra tydandet av informationen lättare. 1.2 Disposition Kapitel 2 går igenom bakgrunden till projektet, de problem som ligger till grund för projektet, syftet och målet gentemot Sogeti samt vilka tekniker och verktyg som kommer att användas för att ta fram webbapplikationen. 1

Kapitel 3 går igenom det förarbete som gjorts i form av en workshop tillsammans med kunden för att ta fram en kravspecifikation, modellering av en databasmodell och planering för hur projektet ska bedrivas. Kapitel 4 går igenom designen av databasen och verktyget för att underlätta detta arbete, databasens tabeller, användandet av Scrum [1], den tänkta designen för den visuella delen av applikationen samt en genomgång av vilka implementeringskrav som har åtagits i de fyra olika sprintarna (sektion 6.1 ). Kapitel 5 går igenom olika implementeringstekniker av databaser, vad som faktiskt har implementerats i de fyra sprintarna och problem eller inlärningströsklar som har uppstått under projektets gång. Kapitel 6 går igenom en utvärdering av projektet sprint för sprint, skillnaden mellan vad som var tänkt att hinnas med och vad som faktiskt hanns med, de demonstrationer som har gjorts för kunden samt en utvärdering av de tillvägagångssätt som projektet har bedrivits på. Kapitel 7 går igenom en sammanfattning över de icke-tekniska bitarna av projektet, vilka slutsatser som dragits efter projektets slut för implementeringen av databasen, vidareutveckling av applikationens nuvarande skick samt den framtid som applikationen väntas ha. 2

2 Bakgrund I detta kapitel presenteras Sogeti som företag, både lokalt och nationellt, de problem som ligger till grund för det examensarbete som har utförts, den prototyp som har tänkts som lösning till problemet, syfte och mål med arbetet i sin helhet samt de tekniker och verktyg som har använts under projektet. 2.1 Sogeti Sogeti [15] är ett dotterbolag till koncernen Cap Gemini SA [3]. Sogeti är ett globalt företag som verkar i 15 länder med över 20 000 anställda. Inom Sverige arbetar cirka 1150 personer fördelat på 21 kontor varav i Karlstad över 50 personer. Sogeti erbjuder IT-konsulttjänster på den lokala marknaden där Karlstadkontorets främsta arbetsområden är inom Business Intelligence, industriell IT samt webb- och integrationslösningar, i största mån med hjälp av Microsofts plattformsverktyg.net och SQL Server. Sogeti Karlstad arbetar tillsammans med Microsoft och har i dagsläget högsta partnerstatus. Nivån på partnerstatus hos Microsoft avgörs utifrån hur många certifieringar ifrån Microsoft ett företag har. Certifieringarna i Sogeti Karlstads mening är ett medel som används för att bevisa att de anställda konsulterna bemästrar den kompetens de påstår att de har, inför arbetsuppdrag, men även som nämnt ovan, för att behålla den partnerstatus Sogeti Karlstad har i dagsläget. 2.2 Problem Genom att Sogeti använder sig av ett Excelbaserat program försvårar det enkla uppgifter som underhåll och visualisering av data. Underhåll försvåras i den aspekten då det inte finns någon koppling till databas och kan därför inte spara undan certifieringar, titlar eller anställda, utan administratören måste lägga till dessa manuellt. Visualiseringen represen- 3

teras i form av att de anställda spaltas upp i kolumner och certifieringarna får egna rader, med hjälp av ett kryss markeras de certifieringar en anställd innehar. 2.3 Syfte Syftet med detta arbete är att framställa en prototyp som förhoppningsvis ska kunna ersätta Sogetis nuvarande lösning. Prototypen är tänkt att underlätta för företaget att få en bättre översikt över sina anställdas certifieringar och titlar. Processer som hantering, tillgänglighet samt visualisering är tänkt att förbättras markant för både administratören och de anställda. Som det ser ut i dagsläget är den aktuella lösningen inte optimal för ändamålet. 2.4 Prototyp Prototypen som ska utvecklas kommer i första hand att bidra till en bättre tillgänglighet då prototypen kommer att vara webbaserad. Certifieringar, titlar och anställda matas in i olika formulär där respektive information också medföljer, detta lagras sedan i en kopplad SQL-databas. Inloggning på prototypen kommer att ske i form av AD-inloggning [7] där användaren verifieras med hjälp av Windowsautentisering. Administratören kan välja att ta bort, redigera och tilldela certifieringar och titlar som finns i databasen. Gamification [18] är en egenskap som finns i form av statistik och topplistor i prototypen för att motivera de anställda att ta fler certifieringar samt titlar. 2.5 Mål Målet med det här arbetet är att framställa en så funktionell prototyp som möjligt till Sogeti. Funktionell i benämningen att uppgifter som hantering, tillgänglighet och visualisering ska ha förbättrats och i och med det medföra till mindre underhållningsarbete. Implementeringen i utvecklingsstadiet kommer att ta hänsyn till vidareutveckling av prototypen. 4

Med detta menas att det ska vara enkelt att i ett senare stadie kunna utöka prototypens funktionalitet. Ett mer långsiktigt mål som uppdragstagarna tillsammans med Sogeti har framfört är att de övriga 20 kontoren runtom i Sverige ska börja använda detta verktyg. Detta ska i sin tur ska kunna leda till att statistikfunktionalitet enkelt ska kunna visualisera och jämföra alla de certifieringar som tagits av anställda. 2.6 Tekniker Under följande punkter beskrivs de olika tekniker, ramverk och implementeringsspråk som har använts i projektet. 2.6.1 MVC Model-View-Controller [20] är ett arkitekturmönster som används som ryggrad i detta arbete. Figur 2.1: MVC-arkitekturen och en användares interaktion. Den huvudsakliga anledningen till varför MVC används är för att skapa ett oberoende 5

mellan de olika datalagren. Detta i sig medför till att större modifikationer kan göras utan att påverka hela arbetet. Dessutom blir det lättare att strukturera och underhålla arbetet under implementeringen. 2.6.2 ASP.NET & ASP.NET MVC Framework ASP.NET [8] är ett ramverk skapat av Microsoft som används för att skapa dynamiska webbsidor. ASP.NET har en tydlig koppling till.net-ramverket. Tillsammans med IIS (Internet Information Server) arbetar ASP.NET för att generera innehåll som reagerar på klientförfrågningar. ASP.NET ger tillgång till alla.net klasser, komponenter och databaser. ASP.NET MVC Framework [9] är ett ramverket som bygger på ASP.NET och MVC-arkitekturen vilket förenklar för utvecklaren att få kontroll över den HTML som genereras samt att arkitekturen blir lättare att testa och återanvända. 2.6.3 Bootstrap Bootstrap [6] är ett ramverk som innefattar HTML, CSS och JavaScript. HTML tillsammans med CSS har skapat den genomgående designen på prototypen. Sedan har JavaScript tillsammans med CSS bildat det dynamiska innehållet i prototypen, till exempel dialogrutor vid knapptryck. 2.6.4 Entity Framework Entity Framework [17] är ett ramverk för objekt- och relationsmappning för ADO.NET men var tidigare en del av.net ramverket. Sedan version 6 av Entity Framework släpptes har det separerats från.net ramverket. Detta projekt har använt sig av Entity Framework 4.5.2 och på så sätt har ASP.NET ramverket kunnat användas tillsammans med Entity Framework. Genom att mappa objekt och relationer skapas kopplingar mellan de databastabeller som har skapats i ett separat projekt. Utifrån dessa databastabeller skapas den databas som information hämtas ifrån eller läggs till i. 6

2.7 Verktyg Under följande undersektioner beskrivs de olika verktyg som har använts under projektet. 2.7.1 Visual Studio 2015 Enterprise Visual Studio [19] är en programutvecklingsmiljö som använts i störst utsträckning i hela arbetet. I Visual Studio ingår kompilatorer för språken Visual Basic.NET, C++, F# och C#. C# är det språk som har använts för projektet. Det är genom Visual Studio som all implementering kommer att ske. 2.7.2 SQL Server Management SQL Server Management [11] är en integrerad miljö som huvudsakligen har använts för att få åtkomst, modifiera, underhålla och hantera data i SQL-databasen. Genom att det är integrerat tillsammans med Visual Studio får man en direkt återkoppling vid modifikationer eller implementeringar. 2.7.3 Team Foundation Server (TFS) TFS [12] är en platform som Microsoft har tagit fram för att underlätta samarbete under mjukvaruutveckling. Under arbetet användes TFS tillsammans med Visual Studio för att underlätta hanteringen och implementeringen av prototypen. Git [4] var det versionshanteringsverktyg som användes. Under arbetets gång har Git varit den centrala lagringspunkten för prototypen. Med hjälp av ett versionshanteringsverktyg har arbetets gång underlättats då modifikationer eller nya implementeringar med enkelhet kunnat överses eller ändras på. TFS har också används för att strukturera och planera arbetet. Med hjälp av TFS inbyggda verktyg för agil utveckling har arbetet kunnat visualiseras på en delad dashboard, där olika uppgifter och diverse information har visats. Arbetet har därför varit lätt att följa och strukturera. 7

2.8 Sammanfattning I dagsläget sitter Sogeti Karlstad med ett Excel-program för att hantera de certifieringar de anställda konsulterna innehar. Problemet med detta är att programmet medför svårigheter dels för det administrativa arbetet men även för överblicken av de tagna certifieringarna. Tanken med detta projekt är att ta fram en prototyp som är webbaserad och förenklar arbetet kring samt visningen av de anställdas certifieringar. Kapitlet innefattar även de olika verktyg och tekniker som har använts under projektets gång. 8

3 Förarbete 3.1 Introduktion I detta kapitel presenteras det förarbete som krävdes innan projektet kunde ta sin början. I förarbetet ingår uppsättandet av de verktyg som tillhandahölls, förberedandet av den kravspecifikation Sogeti hade tagit fram och på vilket sätt uppdragstagarna skulle ta detta arbete framåt. 3.2 Kravhantering 3.2.1 Kravspecifikation Sogeti Karlstad hade från början tagit fram en väldigt koncis och öppen kravspecifikation, som i första hand skulle gälla som en beskrivning av själva projektet. Utifrån den fick uppdragstagarna en god idé om vad som förväntades. I beskrivningen var en punkt att exjobbarna skulle ta fram en mer detaljerad kravspecifikation genom en workshop. 3.2.2 Workshop En kravinsamling genomfördes i form av en workshop som uppdragstagarna, tillsammans med Sogeti, deltog i. Sogeti fick under denna process presentera den lösningen de i dagsläget använde sig av dvs Excelarket. Utifrån presentationen belystes de problem som den lösningen bidrog till och hur dessa skulle kunna adresseras. Under workshopen framkom ett antal olika krav på vad Sogeti önskade sig att prototypen skulle kunna utföra. Dessa krav har sedan renskrivits och strukturerats. Kravspecifikationen lämnades efter detta till Sogeti som fick granska den och utifrån detta, prioritera varje krav. Deltagarna i workshopen bestod av produktinnehavarna samt exjobbarna. Genom att flera personer med varierande perspektiv medverkade i workshopen kunde olika lösningar och idéer framföras och beslutas om. 9

3.2.3 Slutlig kravspecification Den slutliga kravspecifikationen finns i Bilaga A.1. En plan över vad som skulle finnas med i prototypen, då angreppssättet för den funktionalitet som skulle implementeras var väldigt fri, så länge den låg inom ramarna för de ramverk och programmeringsspråk som Sogeti beslutat om. Projektet delades in i två olika listor med krav, en kärnlista och en optionslista. Kärnlistan består av de krav som uppdragstagarna tillsammans med Sogeti anser vara vitala för att prototypen ska kunna fylla sitt syfte och som uppdragstagarna trodde sig hinna med under projektets gång. Krav som ingår i kärnlistan är bland annat funktionalitet för att kunna lägga till, ta bort och redigera de olika certifieringarna och titlarna. Optionslistan består av de krav som uppdragstagarna tillsammans med Sogeti ansåg vara användbara men inte vitala för prototypen. Från optionslistan kunde krav hämtas och arbetas med ifall de uppsatta kraven under en sprint var avklarade. Krav som ingår i optionslistan är bland annat att hämta information om certifieringar och titlar ifrån respektive återförsäljares hemsida. 3.3 Databasmodell För att få en djupare förståelse för hur databasen för projektet skulle se ut skapades och utvärderades en modell av den. Vid en första granskning av relationsmodellen tyckte Sogeti att den såg något tunn ut, för få modeller och kopplingar, detta diskuterades igenom och det skapades några fler kopplingar och modeller. Arbetet fortsatte sedan med mer begrundande över modeller och kopplingar där uppdragstagarna sedan kunde bestämma vilka olika komponenter relationsmodellen skulle innefatta. Efter ett beslut visualiserades tabellerna och kopplades ihop med varandra, genom kopplingstabeller. Relationerna baserades på vad uppdragstagarna ansåg var en rimlig koppling. Efter att tabellerna var skapade och kopplade infördes attributen för respektive tabell. 10

Figur 3.1: Första databasmodellen Databasmodellen, figur 3.1, kom att ligga som grund för implementeringen av den riktiga databasen. Databasen kontra modellen i det slutliga stadiet blev modifierad på grund av att vissa aspekter inte hade överlagts tillräckligt ordentligt. 11

3.4 Scrum Projektet bedrevs med hjälp av scrum [1] som utvecklingsmetod. Processen delades in i 4 sprintar à 3 veckor. Figur 3.2: De moment som ingår i Scrum [14]. I slutet på varje sprint presenterades det genomförda arbetet för samtliga involverade. Önskemål, idéer och modifieringar kunde då framföras. Efter att demonstationen var genomförd presenterades vad som skulle innefatta nästkommande sprint, efter överenskommelse med Sogeti påbörjades planeringsprocessen för den nästkommande sprinten och mål handlades. 3.5 Team Foundation Server (TFS) TFS har använts som ett hjälpmedel under projektet. Till en början var det tänkt att allting associerat med sprintarna skulle lagras här. Så blev inte fallet eftersom projektet var relativt litet och det märktes därför snabbt att det endast blivit omständligt. TFS har huvudsakligen används i syfte att hantera ett git-repository där hämtning och lagring av nya uppdateringar skett. 12

3.6 Sammanfattning Förarbetet för projektet blev indelat i två olika delar, den första i form av en grovdragen kravspecifikation som gavs ut av Sogeti som beskrivning för projektet. Den andra delen var en workshop som hölls av projektdeltagarna för att kunna ta fram en mer detaljerad kravspecifikation som senare strukturerades så att Sogeti kunde granska och prioritera listan. Efter att kravspecifikationen var godkänd delades de olika kraven in i två olika listor, en kärnlista och en optionslista. Kärnlistan är den funktionalitet som projektdeltagarna tror sig kunna hinna med under projektets tid. Projektet delades sedan in i fyra sprintar, varav projektdeltagarna åtog sig delar från kärnlistan inför sprintarna. En databasmodell designades som en grund för den riktiga databasen som implementerades. TFS har använts som hjälpmedel under projektet, mestadels i bakgrunden då all hämtning och lagring av data går via ett git-repository som är lagrat på Sogetis TFS. 13

4 Projektdesign 4.1 Introduktion Sogetis lösning för hantering av certifieringar och titlar bestod av ett Excelark med ett antal flikar. Idén med denna prototyp var att förenkla användandet för både administrativa personer såväl som för användare då Excel-lösningen var både svåråtkomlig för användarna och svårhanterad för de administrativa personerna som ska föra in data. Ett krav för prototypen var att det skulle väcka en tävlingskänsla att gå in och använda applikationen. En tävlingskänsla i form av att vilja ta mer certifieringar än sina kollegor. Designen var med andra ord tvungen att bli enkel, så att inte användaren blir överöst med information och på så vis tröttnar, samtidigt som den var tvungen att vara attraktiv så att det skapas ett intresse för att använda applikationen och i slutändan att fler certifieringar tas av de anställda. 4.2 Databasdesign Databasdesignen var en komponent av projektet som krävde begrundan. Till en början spekulerades det i vilka olika delar som var nödvändiga och användbara för designen. Efter att insamlingsprocessen av nödvändiga komponenter var avklarad påbörjades modelleringen av databasen. Genom att modellera den innan implementeringsstadiet skapades en visuell representation och bättre underlag för fortsatt arbete. Databasen implementerades i första stadiet genom Code first [16] tillsammans med Migrations [10]. Detta ändrades efter förslag från Sogeti. 14

Figur 4.1: Jämförelse av implementeringsteknikerna Code first och Database first. Code first är ett tillvägagångssätt som lämpar sig för mindre projekt. Valet att konstruera en databas från början och sedan publicera den till projektet med hjälp av SQL Manager var därför i vårat tycke bättre. Dels för att få en bättre struktur och översikt över databasen, men också för att ta del av nya kunskaper som kommer att vara mer användbara i arbetslivet. 4.3 SQL Manager För att underlätta databashanteringen avsevärt har SQL Manager [11] använts. Med hjälp av programmet kan hantering och manipulation av data genomföras utan några större påverkningar av involverade program. 15

4.4 Scrum Arbetsupplägget för projektet delades in i, vad uppdragstagarna tyckte var mest optimalt, sprintar varande 3 veckor. På det sättet blev implementeringsprocessen varken för lång eller för kortvarig. Det resulterade i att arbetet fortlöpte effektivt och kunde granskas av Sogeti i slutet av varje sprint med hjälp av en demonstration. Demonstationen i största utsträckning gick ut på att demonstrera för Sogeti vad som hade genomförts under sprinten, och vad som var kvar i projektet. Scrum har bedrivits precis som utvecklingsmetodiken förespråkar det vill säga agilt. Det agila tillvägagångssättet har kombinerats tillsammans med iterativt och inkrementellt angreppssätt. Den iterativa arbetsformen har utmärkt sig i att arbeta i cykler för att förbättra en funktion genom prototyp, test, analys och förbättring. Den största fördelen som uppdragstagarna ansåg med att arbeta agilt är att man är mottaglig för förändrade krav i processens gång. I många fall täcker inte förstudien alla de krav som Sogeti begär eller vill ha, det var en av anledningarna till varför projektet inte utfördes enligt vattenfallsmetoden [22], det vill säga sekventiellt. Det inkrementella arbetssättet har utnyttjats hela projektet och bidragit till en stabil och välfungerande kod. 16

4.5 Databasmodeller De tre huvuddelarna i prototypen är användare, certifieringar och titlar, Figur 4.2: De tre huvudentiteter som utgör projektet. dessa tre modeller är cirkelkopplade med varandra. En användare kan ha flera titlar och certifieringar, en certifiering kan ingå i flera titlar och innehas av flera användare samt att en titel kan utgöras av flera certifieringar och innehas av flera användare. Users Modell som representerar användarna i prototypen. Användarna i sig kan inneha certifieringar och titlar. Ett visst antal certifieringar kan ingå i en titel som en användare har. Därav finns det en koppling mellan Users, Titles och Certificates. En användare har även ett attribut Offices. Titles Modell som representerar titlarna i prototypen. En titel kan bestå av ett visst antal certifieringar därav kopplingen mellan Titles och Certificates, vilket illustreras i figur 4.3. 17

Figur 4.3: Certifieringar bundna till Titel 1 Certificates Modell som representerar certifieringarna i prototypen. En eller flera certifieringar kan ingå i en eller flera titlar (figur 4.3 ) och kan ägas av en eller flera användare. Därav kopplingen mellan Certificates, Titles och Users. Vendors Modell som representerar utfärdare av en specifik certifiering eller titel. Därav koppling mellan Vendors, Certificates och Users. Offices Modell som representerar de kontor som finns i Sverige. En användare jobbar på något kontor, därav kopplingen mellan Offices och Users. Divisions Modell som representerar uppdelningen av kontoren. Det finns tre områden, norr, svea och syd som kontoren är uppdelade i. Därav kopplingen mellan Divisions och Offices. 4.6 Kopplingsmodeller En kopplingsmodell är en utökad modell där två modeller finns med som attribut tillsammans med ett eller fler attribut. En kopplingsmodell används när det inte räcker med att referera modellerna mellan varandra utan till exempel ett visst datum som kopplingen 18

skedde eller antal kopplingar av detta slag. UserCertificates Modell som kopplar samman en användare med en certifiering. Denna modell finns som attribut hos Users och Certificates. UserTitles Modell som kopplar samman en användare med en titel. Denna modell finns som attribut hos Users och Titles. TitleCertificates Modell som kopplar samman en titel med en certifiering. Denna modell finns som attribut hos Titles och Certificates. 4.7 Kopplingstabeller En kopplingstabell ligger endast i databasen men är inte en egen modell. I en modell finns den som attribut i form av den modell som den befintliga modellen ska kopplas samman med. Kopplingstabeller används när endast modellerna behöver finnas med som referenser till varandra. CertificateVendors Modellerna Certificates och Vendors ligger som attribut i varandras modeller. TitleVendors Modellerna Titles och Vendors ligger som attribut i varandras modeller. UserOffices Modellerna Users och Offices ligger som attribut i varandras modeller. UserDivisions Modellerna Offices och Divisions ligger som attribut i varandras modeller. 19

4.8 Vyer Prototypen är en så kallad Single Page Application (SPA) [21] där en huvudvy ligger i bakgrunden med en menyrad för åtkomst till andra delar i applikationen. Varje val i menyn består av en egen vy med funktionalitet i sig. Sidan är dock anpassad så att för de användare som har tagit certifieringar får en egen profilsida där titlar och certifieringar visas tillsammans med diverse statistik. De användare som inte är registrerade med certifieringar loggas in som gäster och kan ta del av generell statistik och andras profilsidor. För att få tillgång till den administrativa delen krävs det att den inloggade användaren har rollen Admin och kan på så vis göra ändringar i applikationen. Vyerna är tänkt att vara uppdelade i tre olika grupper, Home, User och Admin, där alla tre kommer att dela en grundvy för navigation i applikationen. Home-vyerna är tänkta till startsidor där användaren välkomnas med en kort text och statistik över certifieringar, samt att all offentlig statistik är tänkt att finnas samlat under ett menyval. Då endast de som har tagit certifieringar kommer att finnas registrerade blir de tilldelade en egen sida där samlad statistik om dem själva finns. Denna ligger under Usergruppen. Den sista gruppen av vyer är endast tillgänglig för den eller de administrativa personen/personerna som hanterar både certifieringar och användare. Tanken var att göra det så simpelt som möjligt att lägga till, ta bort eller redigera alla modeller och kopplingar. Med andra ord så låg inte designen som första prioritering på dessa vyer då funktionaliteten vägde betydligt mer. 4.9 Sprintar Projektet började med att en detaljerad kravlista skulle tas fram genom en workshop. Utifrån kravlistan delades alla krav in i två olika delar, en kärndel och en optionsdel. Det uppsatta målet för projektet var att hinna klart med implementeringen av kärndelen. Förhoppningarna var att även implementeringen av optionsdelen skulle hinnas klart men 20

detta låg inte inplanerat inom tidsramen för projektet utan något som kunde implementeras ifall att en sprint blev klar tidigare än förväntat. 4.9.1 Sprint 1 Den första sprinten är tänkt att börja med att sätta upp databasen och dess modeller samt att implementera den basfunktionalitet som behöver finnas, så som tilläggning, borttagning och redigering av de olika modellerna. En punkt på kravlistan var även att applikationen ska vara på engelska. Sprint 1 kommer förmodligen att bli den sprint som kommer synas mest för användaren då den basfunktionalitet som ingår i den första sprinten innebär en hel del front-end visning av de olika modellerna. 4.9.2 Sprint 2 Den andra sprinten är tänkt att binda ihop modellerna då det finns relationskopplingar mellan modellerna. Detta betyder att en användare och en certifiering ska kunna kopplas samman i en kopplingstabell där ID:t för respektive modell läggs in. Implementering av en så kallad AD-inloggning har även åtagits, vilket betyder att alla på kontoret ligger på en server hos Sogeti redan och ska kunna autentiseras mot servern med sina användarnamn för att få tillgång till applikationen. Om en anställd loggar in på sin dator med användarnamn testexempel och går in på applikationen kollar då applikationen mot server ifall användarnamnet finns. 21

4.9.3 Sprint 3 Den tredje sprinten är tänkt att fokusera på statistisk funktionalitet. Statistiken kommer att användas dels för att de anställda ska få en överblick över vilka certifieringar och titlar denne har, men också för att motivera de anställda att ta flera certifieringar. Det är tänkt att implementera statistik på den personliga sidan där användaren kan se sina certifieringar och titlar. Antalet tagna certifieringar och titlar har bestämts att visualiseras i form av en progress bar. I samband med statistiken ska även gamification införas, det kommer att visualiseras genom en topp 5 för följande kategorier: För året För alla totalt (aktiva) Personer Certifieringar Kontor Lokalt Division Nationellt Totalt antal certifieringar Lokalt Division Nationellt 22

4.9.4 Sprint 4 Den fjärde sprinten är tänkt att spendera mer tid på front-end för att övergå från statiskt innehåll till mer dynamiskt. I samma process kom även fokus att läggas på det visuella, det vill säga prototypens design. Eftersom alla de förgående sprintarna kom att, till största del, fokusera på back-end lämpade det sig att prioritera den sista sprinten på att få en sammansättning och en komplett prototyp av back-end-funktionalitet likaväl som stilren och fungerande front-end-funktionalitet. 4.10 Sammanfattning Befintlig hantering av certifieringar hos Sogeti bestod av ett Excelark som administrativ personal hanterade. Då detta inte var någon optimal lösning för varken administratörer eller anställda var tanken att hantering av certifieringar skulle förbättras genom en webbapplikation. Genom en enkel och attraktiv design var förhoppningarna att de anställda skulle få upp intresset för att ta fler certifieringar. Prototypen är uppbyggd av tre huvudmodeller: användare, certifieringar och titlar. Alla dessa är cirkelkopplade med varandra, med detta menas att alla har kopplingar till och från varandra. Prototypen består även av diverse modeller och kopplingsmodeller som binder samman applikationen. En modellreferens används för att sammankoppla de olika modellerna med varandra. Prototypen är en så kallad SPA (Single Page Application) där alla delar av applikationen ska kunna nås oavsett var i applikationen användaren befinner sig. Projektet bedrevs agilt under fyra sprintar à tre veckor. 23

5 Projektimplementering I detta kapitel presenteras den implementering som har gjorts i de olika sprintarna samt det tillvägagångssätt som implementeringen har gjorts på. 5.1 Introduktion Implementeringen av vår design har gjorts kontinuerligt genom uppdelning av arbete sinsemellan. Arbetsuppgifterna delades upp i projektet för att undvika konflikter i gitförbindelserna. Då arbetet utfördes jämsides kunde en ständigt dialog föras över designen av applikationen, både för användargränssnittet så väl som för strukturen av koden. 5.2 Implementeringstekniker av databasen 5.2.1 Code first Tillvägagångssättet för implementering genom Code first går till genom att programmeraren sätter statiska värden till attributen i den modell som ska skapas. Dessa modeller initieras sedan till en databaskontext från en egen klassfil. När projektet sedan exekverar bygger databaskontexten en databas utifrån de modeller som har initierats. Modellerna blir med andra ord databastabeller. 5.2.2 Database first Implementeringstekniken för database first fungerar på motsatt sätt. Här skapas ett nytt databasprojekt där programmeraren skapar tabeller, namnger och sätter attributvärden. Denna databas publiceras sedan så att den går att använda i nya kodprojekt. När sedan ett kodprojekt skapas integreras det databasprojekt som har skapats tidigare och utifrån de databastabeller som finns i databasen skapas modeller som sedan går att använda i 24

kodprojektet. Databasen går sedan att uppdatera genom SQL Management genom enkla SQL-frågor. Detta kan ses i sektion 4.3. 5.3 Sprintar 5.3.1 Sprint 1 Sprint 1 inleddes med att skapa databasen och dess tabeller så att det fanns en grund att börja ifrån. Utifrån databasens tabeller genererades modeller som använts i prototypen. När databasen var klar och publicerad påbörjades implementeringen av basfunktionaliteten så som tilläggning, borttagning och redigering av modellerna. Figur 5.1: Redigering av en anställd. För redigering av en modell har vi gjort en partiell vy med en modal layout så att vyn visas framför den nuvarande vyn som får ett gråaktigt lager över sig vilket kan ses i figur 5.1. 25

Figur 5.2: Tabell över de anställda och dropdownmeny för administratör. Då detta innebar att modellerna kan visas i front-end för användaren och för administratören under olika menyval, menyvalen kan ses i figur 5.2, kom projektet långt in i den visuella delen väldigt fort. Den visuella implementeringen kommer dock att avta för varje sprint som blir gjord. 5.3.2 Sprint 2 Majoriteten av tiden spenderades på den essentiella funktionaliteten i prototypen. Dessa var bland annat de olika bindningarna mellan certifieringar, titlar, användare, kontor och divisioner. En certifiering binds till en användare (figur 5.3 ) eller titel genom att välja användare eller titel i dropdownlistan som ligger över tabellen och sedan kryssa i den checkbox som tillhör den certifiering som ska bindas. 26

Figur 5.3: Bindning mellan Certifiering och Anställd. På samma sätt som när en certifiering ska bindas till en användare så väljs titeln i dropdownlistan och de certifieringar som ska bindas till denna titeln väljs genom att tillhörande checkbox kryssas i. Figur 5.4: Titel väljs genom val i dropdownlistan. 27

Sökning efter både titel och användare kan ske på två olika sätt. Det första visas i figur 5.4 medan det andra visas i figur 5.5. Figur 5.5: Titel väljs genom sökning i dropdownlistan. Det var även i denna sprint som innehållet på prototypen började omvandlas till att bli mer dynamisk. Den dynamiska funktionaliteten möjliggjordes med hjälp av AJAX [13], Angular JS [2] och tillsammans med vanligt JavaScript. Applikationen har gjorts kompatibel med AD-inloggning så att användaren autentiseras mot en server på Sogeti genom applikationen. 5.3.3 Sprint 3 Största fokus i den här sprinten var implementering av statistisk. Syftet med statistiken i prototypen är att påvisa de anställdas certifieringar och titlar för andra och på så vis undermedvetet skapa en tävlingskänsla. Statistiken är uppdelad på både den egna sidan och den allmänna statistiksidan. På användarens egna sida visas en standardbild som går att byta samt sitt fulla namn och sitt AD-ID. Under dessa finns en aktivitetsruta med hur många certifieringar samt titlar användaren har tagit. Detta representeras av siffror och framstegsmätare (progressbar). Detta kan ses i figur 5.6 och 5.7. Större delen av sidan, 28

som ligger till höger av det förstnämnda, är uppdelat under två flikar. Under fliken My Certificates på användarens personliga sida visas endast tagna certifieringar och titlar. Figur 5.6: My Certificates på My Page Medan under fliken My Progress visas vilka titlar som är tagna och hur långt det är kvar att ta de andra titlarna i form av framstegsmätare och text med vilka certifieringar som är tagna eller ej för var och en av titlarna. Detta kan ses i figur 5.7. 29

Figur 5.7: My Progress på My Page Användaren har erhållit Title 1 då samtliga certifieringarna tillhörande titeln är tagna. Alla certifieringarna för Title 2 och Java Master har ännu inte tagits samt att ingen certifiering har tagits för Title 3 i figur 5.7. 30

Figur 5.8: Graf över tagna certifieringar under året, månad för månad. Statistiken på den allmänna sidan delades även den upp under två flikar. Den första fliken Office, figur 5.8 visar en mer visualiserad bild över hur många certifieringar som har tagits under årets månader. Medan fliken Offices, figur 5.9-5.11 visar den mer tävlingsinriktade statistiken där användaren kan bläddra mellan olika tabeller för att se olika topplistor över anställda på lokal nivå, (figur 5.10 ), så väl som på nationell nivå (figur 5.9 ) men även topplistor över certifieringar och regioner. Detta kan ses i figurer 8.1-8.3 i Bilaga B.1. 31

Figur 5.9: Topplistor alla anställda I figur 5.9 visas tabeller över de fem anställda som finns registrerade i databasen som har tagit flest certifieringar totalt och flest tagna certifieringar totalt under det nuvarande året samt en full topplista över alla registrerade anställda och antalet certifieringar. 32

Figur 5.10: Topplistor lokalt kontor figur 5.10 visar likadana topplistor som figur 5.9 över de fem anställda som tagit flest certifieringar inom de olika kategorierna med skillnaden att det endast visas anställda från den inloggade användarens kontor. 33

Figur 5.11: Topplistor kontor figur 5.11 visar tabeller för kontoren som finns registrerade i databasen. Dessa tabeller visar topplistor över flest certifieringar som är tagna totalt och som även är aktiva, flest certifieringar tagna det nuvarande året samt en full topplista över de registrerade kontorens antal tagna certifieringar. 5.3.4 Sprint 4 Denna sprint har huvudsakligen inneburit att modifiera prototypens statiska presentationsläge till mer dynamiskt och användarvänligt, därav har arbetet i denna sprint inte spenderats så mycket på back-end utan en större utsträckning på front-end istället. 34

Figur 5.12: Sökning på kontor vars namn innehåller G. Listor och värden kan därför nu uppdateras i realtid utan att behöva ladda om hela sidor. Anledningen till varför huvudfokus låg på front-end var dels för att all funktionalitet var avklarad men också för att få en användarvänlig och presentabel design och i och med det få en bättre helhet på prototypen. 5.4 Problem & Inlärningströskel 5.4.1 Code first vs Database first Det första problemet som stöttes på var valet mellan Migrations Code first eller Database first, som beskrivs i sektion 4.2, då tidigare arbete endast har utförts utifrån Migrations implementeringsteknik valdes detta projekt att angripas på liknande vis. Problemet kom när uppbyggnaden av databasen var gjord. Det blev väldigt märkbart att hanteringen av databasen försvårades avsevärt då användandet av SQL Management inte var tillgängligt för Migrations, pga att SQL Management inte stöds av Migrations, eller kopplingstabeller, då Migrations inte genererar några kopplingstabeller. Lösningen blev att hela projektet slopades för att byggas upp på nytt genom Database first. Processen för att bygga upp en databas kan ses i sektion 5.2.2. 35

5.4.2 Dynamisk funktionalitet En av de större utmaningarna under projektet var att förändra den statiska implementeringen till dynamiskt. Detta innebar att förändra back-end-funktionaliteten och istället flytta den till front-end och skriva om den i form av AJAX och Angular JS. Om man ser till tidsaspekten var implementeringen absolut inte lika tidskrävande jämförelsevis med den tid det tog att lära sig det. Tyvärr var det ingen av oss som hade god kunskap om frontend-funktionalitet och därför tog det längre tid än väntat att modifiera funktionaliteten. Beräknad inlärningstid sträckte sig mellan en till två veckor men visade sig bli tre till fyra. Under projektets gång har diskussioner och resonemang med anställda på Sogeti angående kunskap och tillvägagångssätt för diverse aspekter av prototypen uppkommit. Övergången till den dynamiska implementeringen påbörjades först med ramverket Vue JS [5]. Detta var en rekommendation som mottogs och påbörjades att implementera. Dessvärre efter ett tag märktes det att det skulle bli alldeles för omfattande att sätta sig in i det på så pass kort tid. Därför bestämdes det att tekniker som till viss del kändes till, så som AJAX och Angular JS, skulle användas. Genom att byta angreppssätt minskades inte enbart tiden för resultat utan kunskapen om AJAX och Angular JS växte. 5.5 Sammanfattning Tillvägagångssätten för Code first och Database first gås igenom och jämförs. Vad för implementeringen som faktiskt blev gjord under de fyra olika sprintarna som att i sprint 1 gjordes basfunktionalitet där det ingick funktionalitet för tilläggning, borttagning och redigering av modellerna. I den andra sprinten implementerades kopplingsfunktionalitet mellan modellerna och AD-inloggning. I den tredje sprinten lades största vikt på mer statistisk funktionalitet för gamificationkravet som finns med på kravlistan i Bilaga A.2 punkt 7. I den fjärde och sista sprinten gjordes applikationen mer dynamisk så att sidor inte behöver laddas om varje gång en användare ska utföra en funktion i applikationen. 36

De problem och inlärningströsklar som har uppstått under projektets gång gås igenom i slutet av detta kapitel för att läsaren ska kunna bilda sig en uppfattning av den tidigare kompetens som fanns samt de utmaningar som uppdragstagarna har ställts inför. 37

6 Utvärdering 6.1 Sprintar Att bedriva projektet i flera olika delprocesser har bidragit till ett strukturerat och noggrant genomfört arbete. Genom att dela upp implementeringsprocessen i flera stadier har full fokus på specifik funktionalitet kunnat tillsättas. Tidsramen för samtliga sprintar har varit en realistisk och bra tidssättning för att genomföra de satta målen. I slutet av varje sprint genomfördes en demonstration för samtliga involverade på Sogeti. Efter varje demonstration utförde examensarbetarna ett retrospektiv där relevanta saker lyftes fram till exempel vad som hade genomförts bra i sprinten, vad som kunde förbättras och vad som skulle tänkas på inför nästkommande sprint. Retrospektiven bidrog till en bättre struktur och planering för projektet och var en vital del för att projektet skulle kunna fortgå. 6.1.1 Sprint 0 I denna sprinten genomfördes allt förarbete för projektet. Sprinten började med kravinsamling som utfördes genom en workshop tillsammans med samtliga involverade. Kraven strukturerades samt prioriterades sedan. Utifrån kraven skapades en preliminär databasmodell som blev utgångspunkten för den slutgiltiga implementerade databasen. Utöver det organisatoriska förarbetet genomfördes även praktiskt, detta infattade installation av utvecklingsmiljö, operativsystem och integration av samtliga plug-ins. Sprinten i uppdragstagarnas mening genomfördes utan några problem och gav en bra utgångspunkt inför den faktiska implementeringen för nästkommande sprint. Förarbetet är bland de viktigaste processerna i ett projekt. Därför var uppdragstagarna medvetna om att det var viktigt att arbetet genomfördes så noggrant som möjligt för att få en djupare förståelse för vad kunden verkligen ville ha. Slutresultatet av sprinten var en mycket god grund och lämnade bra förutsättningar för fortsatt arbete i sprint 1. 38