Utveckling av system för ledighetsplanering

Department of Computer and Information Science

Examensarbete

Utveckling av system för ledighetsplanering

av

Gustav Pettersson

Marcus Nordlander Wiik

LIU-IDA/LITH-EX-G--13/041--SE

2013-09-20

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Examensarbete

Utveckling av system för ledighetsplanering

av

Gustav Pettersson

Marcus Nordlander Wiik

LIU-IDA/LITH-EX-G--13/041--SE

2013-09-20

3

Sammanfattning

Vacation 2.0 är ett ledighetsansökningssystem utvecklat hos CGI i Linköping för deras Linköping- och Norrköpingskontor. Med Vacation 2.0 kan anställda boka in kommande semester, föräldraledighet samt jour. Vacation 2.0 ger HR-avdelningen en översikt över tillgänglig personal genom en

sammanställning av alla arbetsgruppers ledighetsansökningar. Systemet underhålls av en

administratör som har behörighet att administrera arbetsgrupper och ändra anställdas existerande ledighetsansökningar. De anställda som är ansvariga för en grupp eller är anställd på HR-avdelningen kan ges behörigheten av systemadministratören.

Kraven för systemet togs fram genom intervjuer med anställda som vi sedan utvärderade. Det slutgiltiga systemet uppfyller de krav som framkom samt har ett modernt gränssnitt som är lättöverskådligt. För att säkerställa att systemet uppfyllde kraven utfördes genomgående användartester av CGI:s testgrupp.

Systemutvecklingen följde en utvecklingsmetodik som inspirerades av Scrum och Extreme Programming. Systemet är utvecklat i ASP.NET Web Forms med språket C# på serversidan och JavaScript med biblioteket jQuery används för klientsidan. Vacation 2.0 använder sig av en SQL-databas som hanterades med Microsoft SQL Server Management Studio 2012.

Innehållsförteckning

1 Inledning ... 6

1.1 Motivering ... 6

1.2 Syfte ... 6

1.3 Målgrupp... 6

1.4 Avgränsningar, direktiv och förutsättningar ... 7

1.5 Språkbruk ... 7

2 Bakgrund ... 8

2.1 Beställaren ... 8

2.2 Befintliga system inom ledighetsplanering... 8

3 Metod ... 13

3.1 Arbetsprocessen ... 13

3.1.1 Förarbetet ... 13

3.1.2 Val av språk, ramverk och miljö ... 14

3.1.3 Implementation ... 15 3.1.4 Testning... 15 3.1.5 Versionshantering ... 16 3.1.6 Kodstandard ... 16 3.2 Metodteori ... 17 3.2.1 Extreme Programming, XP ... 17 3.2.2 Scrum ... 18 3.2.3 Wireframe ... 18 3.2.4 Intervjuer ... 19 4 Resultat ... 20 4.1 Vacation 2.0 ... 20 4.1.1 Gränssnitt ... 20 4.1.2 Tekniskbeskrivning ... 24 5 Diskussion ... 26

5.1 Verktyg och ramverk ... 26

5.2 Tekniska lösningar... 27

5.3 Subversion ... 28

5.4 Befintliga systemet ... 29

5

5.6 Begränsningar ... 29

5.7 Krav ... 30

5.8 Arbetssätt ... 30

5.9 Vidareutveckling och underhåll ... 31

6 Slutsats ... 32

Referenser ... 33

1 Inledning

1.1 Motivering

CGI:s Linköping- och Norrköpingkontor använder ett webbaserat internt system för att boka in sin ledighet. Det nuvarande systemet anses idag av dem anställda vara föråldrat och fungerar inte som önskat med den redan implementerade funktionaliteten. Under de år som systemet har används så har det blivit tydligt att det även finns mycket funktionalitet som det inte finns behov av. Den överflödiga funktionaliteten gör systemet i många fall krångligt och svårt att förstå. Därför är det önskvärt att systemet blir mer lättförståeligt och dess gränssnitt mer självförklarande.

1.2 Syfte

Det övergripande syftet är att de anställda på kontoret ska kunna göra sin ledighetsansökan via ett system utan att behöva läsa några långa instruktioner eller behöva fråga en tidigare anställd om hur systemet fungerar. Administratörerna ska även snabbt och smidigt kunna göra en sammanställning av ledighetsansökningar för olika arbetsgrupper. Sammanställningen ska användas för att kunna kontrollera den kompetens och mängd resurser grupperna har under semesterperioderna. Den manuella administrationen som krävs i det nuvarande systemet ska automatiseras så mycket som möjligt med hjälp av befintliga databaser och medarbetarregister. Systemet ska uppdateras till ett modernare och mer använt programmeringsspråk och ramverk så att ändringar enkelt kan göras av en anställd vid behov.

För projektet har vi satt upp några personliga mål vad vi vill uppnå med projektet. Ett av målen var att vi ville arbeta med någonting nytt för att bredda vår kunskap inom systemutveckling. Vi ville helst inte bara arbeta med ett nytt programmeringsspråk utan också pröva nya utvecklingsmiljöer och ramverk.

Målet med projektet är att utveckla ett system färdigt för lansering innan projekttidens slut. Vacation 2.0 ska vara stabilt och komplettera de brister som finns i CGI:s nuvarande system. Systemet ska kunna hantera ledighetsansökningar på ett sådant sätt så förtagets administration ska kunna planera semesterperioderna.

Genom nära kontakter med beställaren vill vi få en inblick i hur systemutveckling fungerar på större företag och vilka steg som måste genomgås för att kunna skapa ett fullständigt system.

Som en del i projektet ska vi ta fram vår egen kravformulering för systemet baserats på förtagets anställdas åsikter.

1.3 Målgrupp

Målgruppen av den här rapporten är studenter som är i slutskedet av sin utbildning inom

datavetenskap och programmering. Ingenjörer som ämnar underhålla Vacation 2.0. Utvecklare som planerar att utveckla ett ledighetsplaneringsystem.

7

1.4 Avgränsningar, direktiv och förutsättningar

Majoriteten av de anställda på CGI använder sig av Internet Explorer som standardwebbläsare. Datorerna som används på kontoret levereras med version 8.0 av Internet Explorer och det är även den lägsta versionen som systemet ska stödja. Detta gör att många HTML5- och CSS3-funktioner inte fungerar [1].

Systemet ska köras på CGI:s intranät vilket gör att det inte går att nå utifrån. Systemet använder sig av Windows-login för att identifiera användare så en förutsättning för att kunna använda systemet är att man kör ett operativsystem som är Windows-baserat samt är inloggad med sitt användarnamn [2].

Vi ville undersöka möjligheten att koppla vårt system mot företagets lönesystem. Det såg dock inte företaget som ett behov samt ansåg att det skulle vara för tidskrävande då säkerheten av systemet skulle behöva göras betydligt starkare.

1.5 Språkbruk

Windows-login – Med Windows-login menar vi Integrated Windows Authentication. In-House – Med in-house menar vi systemutveckling som sker direkt på kontoret. Checka ut – Med checka ut menar vi att hämta senaste versionen ifrån repositoryt. Commita – Med commita menar vi att spara arbetskopian till repositoryt.

Cleanade – Med cleanade menar vi att rensa projektet från alla temporära filer.

Repositoryt – Med repositoryt så menar vi en försvenskad, bestämd nominativ böjning av engelskans ord repository.

2 Bakgrund

2.1 Beställaren

Beställaren är Logica som är ett IT-konsultföretag med ca 5500 medarbetare i Sverige. Globalt ca 77000 medarbetare som från ett år tillbaka är en del av CGI [3]. I Östergötland har Logica kontor i Linköping och Norrköping och är dryga 200 medarbetare. Logica jobbar med Application

management, in-house systemutvecklingsprojekt samt som resurser i deras kunders IT-projekt [4]. Under projektets gång så slutfördes integrationen av Logica till CGI, vilket resulterade i namnbyte till CGI.

2.2 Befintliga system inom ledighetsplanering

Ledighetsplaneringsystem används främst för att planera företags arbetsstyrka vid semestertäta perioder. På företagen är det de ansvariga för personalstyrkans jobb att se till att det alltid finns en tillräcklig arbetsstyrka på plats, därför har dom stor användning av system som underlättar planering och schemaläggning. Typiskt för dessa system är att de anställda kan skicka in ledighetsansökningar som de ansvariga sedan kan behandla och att de ansvariga kan få ut någon form av

beläggningsrapport.

Figur 1. Ledighetsplaneringssystemet WhosOff. http://www.whosoff.com/features/

WhosOff är ett webbaserat ledighetsplaneringsystem som låter de ansvariga på företaget själv skapa olika typer av ledighetsansökningar som de anställda kan rapportera in [5].

Ledighetsrapporteringarna kan sedan godkännas eller nekas av de ansvariga. I systemet så kan de ansvariga generera olika rapporter för att skapa en översikt över de anställdas ledighetsansökningar. Systemet har en iCal Feed som gör det möjligt för de ansvariga att få ledighetsrapporter ifrån valda arbetsgrupper eller anställda till egna kalendrar [6]. WhosOff är en prenumerationstjänst där priset är baserat på antalet användare och betalas månadsvis. Figur 1 visar WhosOff.

9

Figur 2. LeaveWizard är ett ledighetsplaneringssystem och en insticksmodul till Microsoft Outlook.

http://www.leavewizard.com/Features.aspx

LeaveWizard är ett webbaserat ledighetsplaneringssystem hårt knutet till Microsoft Outlook [7]. Genom integration till Microsoft Outlook så kan systemet användas med de anställdas Outlook-konton. Systemet är flexibelt och kan ställas in för att fungerar med företagets anpassade arbetsveckor och har även funktioner för att hantera lokalbokningar på företaget. Systemet har verktyg för att skapa en bra översikt på olika arbetsgruppers ledighetsansökningar. LeaveWizard är en prenumerationstjänst där priset är baserat på det maximala antalet användare och betalas månadsvis. Figur 2 visar LeaveWizard.

Figur 3. Staff Leave Planner är ett ledighetsbokningssystem som kan integreras i Microsoft Excel.

http://www.dhxsoft.com/index.php

Staff Leave Planner är ett ledighetsplaneringssystem som är program för Microsoft Excel [8]. Systemet ger administratören stor valmöjlighet gällande utseendet på ledighetsrapporterna.

Systemet bygger på att det endast är administratörerna själva som använder systemet och manuellt matar in alla anställdas ledighetsansökningar. Staff Leave Planner är ett program utvecklat för att fungera i 12 månader, var på en ny version måste köpas in. Programmet finns i olika versioner beroende på hur många anställda som programmet är avsätt att hantera. Figur 3 visar Staff Leave Planner.

11

Figur 4. Personalkollen. https://personalkollen.se/om-personalkollen/

Personalkollen är ett webbaserat personal- och lönesystem inriktat mot restaurangbranschen [9]. Utöver funktioner knutna till lönehantering används systemet för att planera och schemalägga verksamheten. I systemet kan administratören lägga in planerad ledighet för de anställda och generera översiktsrapporter. Systemet har en integrerad stämpelklocka som de anställda skriver in sig genom och på så sätt får systemet på en gång reda på om någon uteblir från schemalagd tid. Personalkollen är en prenumerationstjänst där priset är baserat på antalet användare och betalas månadsvis. Figur 4 Personalkollen.

Figur 5. FlexiStation är ett närvaroövervakningssystem med ledighetsansökningsfunktioner.

http://www.nchsoftware.com/flexi/index.html

FlexiServer tillsammans med FlexiStation är ett program som hanterar närvaroövervakning samt ledighetsansökningar [10]. Genom FlexiStation kan de anställda logga in och då tidrapporternas användares arbetstid automatisk in. FlexiStation gör det även möjligt för de anställda skicka in ledighetsansökningar som HR-avdelningen sedan kan behandla med FlexiServer. FlexiServer finns i tre olika versioner beroende på hur många stationer den ska hantera och mjukvaran innebär en engångskostnad. Figur visar FlexiStation.

De flesta befintliga system är väldigt breda och generella samt oftast utvecklade så att användare är beroende av underhåll ifrån försäljaren. CGI ville ha ett smalare system som mer passade deras behov och även kunde vidareutvecklas för nya behov om så önskas. Systemen som finns är alla väldigt lika var det gäller funktionalitet och utseende. Den funktionalitet som faktiskt är relevant för CGI i dessa system är något de skulle kunna göra själva. Som ett IT-konsultföretag så har de många utvecklare som skulle kunna stå för underhåll och vidareutvecklingen av ett sådant system. Att betala en prenumerationskostnad för ett system som inte är skräddarsytt för CGI:s behov och för underhåll som de enkelt kunde stå själva, var inte aktuellt.

Stora företag har oftast egna interna system som utomstående har svårt att ta del av, mindre företag hanterar det ofta genom enkla formulär eller muntliga överenskommelser. Den fullständiga nyttan av sådana här system ser man oftast bara två gånger per år, då de stora ledighetsperioderna sker. Det gör det onödigt att betala för en tjänst, speciellt för ett företag som har kompetensen själva att utveckla ett sådant system efter egna behov och kan stå för underhåll och framtida utveckling.

13

3 Metod

Vi satt på CGI:s Linköpingkontor och arbetade, det här gjorde att vi alltid hade vår handledare nära tillhands och kunde snabbt och flexibelt få respons ifrån de anställda på CGI. Vi satt alltid bredvid varandra och arbetade under samma arbetstider. Detta gjorde att vi själva smidigt kunde diskutera lösningar och problem mellan varandra. Vi satt oftast och arbetade parallellt för att dra nytta av tiden så bra som möjligt men vi satt även under vissa moment och parprogrammerade. Arbetet gjordes mot korta uppsatta mål som hela tiden betades av och uppdaterades. Vi och vår handledare hade tillgång till samma repository för projektet som tillförde att handledaren ständigt kunde ha en koll hur långt vi hade kommit och att vi enkelt kunde testa kod skriven av den andra personen.

3.1 Arbetsprocessen

Figur 6. Projektets olika faser.

3.1.1 Förarbetet

Vi startade projektet med att utvärdera det befintliga bokningssystemet som CGI använde. Vi gick igenom systemet både som användare och administratörer och förde anteckningar om åsikter vi hade, så som gränssnitt och funktionalitet. Med vår utvärdering som bas tog vi fram ett

intervjuupplägg som vi utförde intervjuer med. Intervjuerna utförde vi sedan på en representativ skara av de anställda hos CGI. Intervjuerna var ostrukturerade och fokusen låg på att höra de anställdas egna formulerade åsikter om systemet. Efter intervjuerna gick vi igenom de anställdas åsikter och gjorde en sammanställning av vad vi såg som de anställdas gemensamma krav. Figur 6 visar arbetsprocessen.

Utefter den samanställningen och våra egna personliga åsikter så skissade vi upp Wireframes över vårt system [11]. Dom här Wireframes som vi gjorde visade vi upp för vår handledare samt de två administratörer som var mest insatta i det nuvarande systemet. Vi lyssnade på deras åsikter och förslag och därefter uppdaterade vi vår skiss utefter dessa. Baserat på skisserna så formulerade vi ett kravdokument och lade upp en preliminär tidsplan. Första punken på tidsplanen var att utvärdera vilka språk, ramverk och miljöer vi skulle använda. Figur 7 visar en Wireframe på en semestertabell.

Figur 7. Wireframe över semestertabellen.

3.1.2 Val av språk, ramverk och miljö

Vi hade fria tyglar gällande valet av utvecklingsspråk, utvecklingsmiljöer och ramverk. Vi undersökte vilken kompetens som fanns inom företaget och vad de anställda var mest vana med. Vi tänkte också på vad vi själva ville använda. En önskan från vår sida var att lära oss något nytt som vi inte använt innan samt att det skulle vara relativt nytt och välutbrett i allmänhet bland programmerare. ASP.NET MVC används flitigt på Linköpingkontoret så vår handledare föreslog att vi skulle överväga att implementera systemet i ASP.NET MVC [12]. Gamla systemet var skrivet i ASP.NET Web Forms med VB.NET som Server Side-språk vilket automatisk gjorde att vi även ville läsa mer och utforska ASP.NET Web Forms vidare [13]. Vi läste om ASP.NET MVC och Web Forms och gjorde Microsofts .NET

tutorials för båda verktygen. Handledaren på företaget hade demonstrationer om både ASP.NET MVC och Web Forms och gick in mer på djupet på hur verktygen fungerar och vad deras styrkor och svagheter ligger. Med hänsyn till detta valde vi att göra systemet i Web Forms. Eftersom vi valde att arbeta med .NET så valde vi även arbetsmiljön Microsoft Visual Studio [14].

Nu när vi valt vårt primära ramverk så började vi undersöka olika widgets för kalendrar och vilka bibliotek som inkluderade en kalender som skulle passa våra skisser bäst [15]. I Visual Studio så är det väldigt smidigt att installera olika slags paket som till exempel hjälper en inkludera

JavaScriptbibliotek där många funktioner lätt kan användas med Toolbox i Visual Studios. Den första kalendern vi prövade var en del av paketet ASP.NET AJAX Control Toolkitoch dess grundfunktioner fungerade bra men vi hade problem med att skräddarsy den visuellt som vi ville [16]. Därför valde vi istället datepicker ifrån jQueryUI som fungerade bra och efter en tid av experimentering så kom vi fram till att den även var väldigt flexibel, både i det grafiska gränssnittet och funktionellt [17].

15

3.1.3 Implementation

Vi gjorde en skiss på systemets databas genom ER-diagram och tabellskisser. Systemet vi hade skissat upp krävde ingen invecklad databas för att fungera, vilket medförde att tabellskissen var enkel att komma fram till. Vi använde oss av verktyget Microsoft SQL Manager Studio 2012 då vår handledare förespråkade det och eftersom vi inte hade några tidigare preferenser så valde vi att inte utvärdera andra verktyg utan använde oss av det rekommenderade [18]. Verktyget fungerade bra och med hjälp utav det kunde vi skapa våra tabeller, relationer och stored procedures väldigt snabbt och smidigt.

Vi började därefter skapa ett kodskelett av systemet för att få navigeringen av sidan att fungera som vi ville samt att få rätt filstruktur och struktur överlag, innan vi började implementera all

funktionalitet. Detta gjorde även att vi kunde arbeta parallellt med systemet för att effektivisera arbetet och få snabbt upp en grund av systemets funktionalitet. Vi hade en bild av vad systemet skulle teknisk klara av, så därför lade vi fokus på att implementera så mycket av de funktionella kraven vi kunde innan vi började på den grafiska biten.

Ett av kraven som ställdes på systemet var att det skulle vara användarvänligt och lättförståeligt vilket gjorde att vi lade mycket tid på att möta dessa kriterier. Vi fokuserade på ett enkelt flöde i systemet och användaren skulle intuitivt veta var man skulle kicka för att system skulle utföra önskad uppgift. Den visuella kommunikationen som systemet kräver för att uppnå detta var stor del av vad vi arbetade med efter vi hade lyckats implementera de funktionella kraven. Vi designade det grafiska gränssnittet så att användarens fokus drogs mot sidans huvudfunktion för att stegvis gå vidare i processen. När tiden för projektet började lida som sitt slut och vi var nöjda med vårt system så började vi kolla på vad som skulle kunna effektiviseras och snyggas till i koden.

3.1.4 Testning

Vi har kontinuerligt utfört tester av systemet under implementationens gång. När vi gjorde den funktionella delen av systemet gjorde vi även ett enkel grafiskt gränssnitt för att testa funktionen i fråga. En del i av att göra systemet lättförståeligt och förklarande är att ge användaren relevant och koncis respons av vad som händer och som ska göras. För att uppnå detta implementerade vi en samling meddelanden som vi även använde vid testning. Implementationen av dessa meddelanden tillförde även att vi märkte av fel och risksituationer som användaren skulle kunna stöta på.

Som en del av testningen lade vi upp systemet på en intern testserver där alla anställda skulle kunna komma åt och titta på systemet. Anledningen till det här var att se hur systemet betedde sig i en riktig miljö, då vi tidigare bara hade kört systemet på våra lokalt emulerade serverar.

I slutet av projektet lämnades systemet över till två stycken erfarna systemtestare på företaget. Dom gick igenom och testade systemet under två dagar och lämnade en informell rapport över av dem hade hittat för fel samt egna åsikter om systemet. Vi hade sedan ett möte med testarna där vi gick igenom testrapporten och gick igenom systemet samt kom fram till vilka ändringar vi skulle göra till den slutliga lanseringen.

3.1.5 Versionshantering

För versionshantering undersökte vi två möjligheter, SVN-klienten TortoiseSVN och Visual Studio pluginet AnkhSVN [19],[20]. Vår handledare på företaget rekommenderade TortoiseSVN då han var van med att använda detta program. Vi ville dock undersöka möjligheten att ha en SVN-plugin till Visual Studio då vi hoppades att det skulle göra versionshanteringen mer lättåtkomlig och smidigare. Vi installerade AnkhSVN och testade att använda det för att checka ut nuvarande systemet men stötte på problem som vi inte riktigt förstod. Eftersom AnkhSVN visade problem redan från start så övergav vi vår plan och började använda TortoiseSVN som både vår handledare och vi själva hade använt sen innan.

Vi började därefter skapa en ny branch för det nuvarande projektet där det säkert skulle ligga kvar. Vi gjorde även en ny trunk för vårt nya projekt som vi skulle arbeta emot. Vi hade inga exakta

tidsbestämmelser när vi commita men vi hade som regel att vi skulle göra en commit så fort vi hade något nytt som fungerade som tänkt.

3.1.6 Kodstandard

Det ställdes inte krav på någon speciell kodstandard av företaget därför valde vi själva vilken standard vi ville använda oss utav. För oss var det viktigt att ha en bra standard för variabelnamn, klassnamn, parameternamn samt filnamn. Vi hittade två standarder som vi tyckte hade bra regler för dessa. För ASP.NET och C# koden så följde vi Microsofts officiella standard och för vanlig HTML, CSS samt JavaScript så följde vi Googles styleguide [21]-[23]. Anledningen till att vi valde Microsofts standard var för att vi använde Microsofts egen utvecklingsmiljö till ramverket ASP.NET samt att det blir mer enhetligt att följa den standard då all autogenererad kod följer den. Anledningen till att vi valde Googles style guide till HTML, CSS samt JavaScript var att den är välanvänd bland

webbutvecklare världen över samt de riktlinjerna angående just namngivning stämde överens med de exempel som finns på bland annat jQuerys hemsida [24].

17

3.2 Metodteori

3.2.1 Extreme Programming, XP

Extreme Programming är en metodik för systemutveckling. Metodiken lägger, till skillnad från de traditionella metodikerna, högre värde på anpassbarhet än förutsägbarhet [25]. Huvudsakliga målet med metodiken är att sänka kostnaderna för förändring, detta gör den genom att introducera värderingar, principer och praxis till utövarna.

De fem värderingarna som metodiken belyser och kretsar kring är:

 Kommunikation

 Enkelhet

 Återkoppling

 Mod

 Respekt

Principerna som utgör grunden för Extreme Programming grundar sig på de fem värderingarna och syftar till att främja beslutfattande i utvecklingsprojekt.

Extreme Programming har tolv praxis som kan grupperas in till fyra områden.

 Återkoppling o Parprogrammering o Planeringsprocessen o Testdriven utveckling o Hela teamet  Kontinuerlig process o Kontinuerlig integration o Designförbättring o Små releaser  Delad förståelse o Kodstandard

o Gemensamt ägande av kod o Enkel design

o Systemmetafor

 Välfärd

o Hållbart tempo

Extreme Programming beskriver fyra aktiviteter. Dessa är kodning, testning, kommunikation och design.

3.2.2 Scrum

Scrum används ofta vid agil mjukvaruutveckling och är mycket som ett ramverk, istället för en

metodik [26]. Scrum är en samling av riktlinjer som övergripande styr utvecklingsprocessen, vilket gör att det används tillsammans med andra metodiker som till exempel Extreme Programming.

Målet med Scrum är att tackla vanliga problem som uppstår i moderna utvecklingsprojekt. Ständigt ändrade krav i projektet är något som Scrum hanterar bra med dess delmål men som andra

metodiker inte alltid hanterar så bra då de ofta sätter mål i början av projektet och sen inte är lika flexibla.

Scrum vilar på fyra värderingar som användarna förväntas ta till sig, dessa är centrala för metodiken och dess tillämpning.

 Individer och interaktion över processer och verktyg

 Fungerande mjukvara över omfattande dokumentation

 Kundsamarbete över kontraktsförhandlingar

 Agera på förändring över att strikt följa en plan

Scrum-processen kan delas in i tre övergripande faser. Den första är planeringsfasen där projektets mål och övergripande design planeras. Sedan följer en rad iterativa sprintcykler där själva

utvecklingen genomförs, sprintarnas uppsättning bestäms med avseende till projektets

förutsättningar. Sprintarna upprepas fram till dess att utvecklingen är klar och processen avslutas med en avslutningsfas där lösa trådar knyts ihop och produkten släpps.

En sprint sträcker sig oftast över en period av två till fyra veckor och kan i sig delas in i tre olika faser. Den har en planeringsfas där kommande sprint planeras, backlogen gås igenom och arbetet

prioriteras. Sedan följer en utvecklingsfas. Under denna fas bockas backloggen av och dagliga möten hålls i teamet där kommande arbeten och problem diskuteras. Sprinten avslutas med en

utvärderingsfas där sprintens arbete demonstreras och utvärderas, här justeras även projektet vid behov.

3.2.3 Wireframe

En Wireframe är en visuell guide som används för att representera ett systems grunddelar och hur dessa delar fungerar tillsammans. Dom tre grunddelarna är informations-, interaktions- och

navigationsdesign. Informationsdesignen behandlar hur information ska hanteras och presenteras i systemet så att information tydligt och effektivt visas för användaren. Interaktionsdesignen handlar om hur användaren interagera med systemet och vilka verktyg som användaren använder för detta. Navigationsdesign beskriver hur användaren navigerar sig genom flödet av systemets beståndsdelar. Att skapa Wireframes är ett effektivt sätt att snabbt skapa prototyper av system och samtidigt mäta det praktiska designkonceptet. Till en början görs ofta Wireframes med hjälp av papper och penna. För större projekt används ofta olika program för att skapa Wireframes, detta gör arbetet smidigare för ett större projekt. Wireframes är oftast svart-vita för att inte fokusen på det praktiska

19

3.2.4 Intervjuer

En intervju är en konversation med ändamål att anskaffa information och kan ske efter ostrukturerade, semistrukturerade eller strukturerade former [27]-[30].

Strukturerade intervjuer följer en noga framtagen mall så att alla intervjuade får samma frågor, i samma följd. Till frågorna ges ofta förvalda svarsalternativ så att det lätt skall gå att analysera och få fram ett resultat, men kan även ge möjlighet till öppna svar. Ett bra exempel på hur den

strukturerade intervjuformen används är statistiska undersökningar, där det är viktigt att allt sker på ett konsekvent sätt för att kunna ge ett analyserbart resultat.

Semistrukturerade intervjuer följer snarare ett tema än en mall, vilket öppnar upp för att mer flexibla frågor tillkommer under intervjun.

Den ostrukturerade metoden bygger på frågor som lätt anpassas efter den intervjuades

förutsättningar och reaktioner på frågorna. Metoden är inte speciellt välanvänd då den ger stor bredd både vad gäller frågor och svar, vilket ger svåranalyserade resultat.

4 Resultat

4.1 Vacation 2.0

Vacation 2.0 är ett webbaserat ledighetshanteringssystem för ett medelstort kontor som körs på kontorets intranät. Vacation 2.0 hämtar sina användare ifrån förtagets personalregister och kräver därför ingen registrering av användare. Vacation 2.0 låter användaren boka frånvaro på tre olika sätt; ledighet, föräldraledighet och jour. I Vacation 2.0 kan användaren också få fram sammanställningar av alla arbetsgruppers ledighetsansökningar och på så vis få fram en översiktsbild över förtagets arbetsstyrka.

4.1.1 Gränssnitt

Systemet består utav tre stycken moduler varutav två stycken är tillgängliga för alla användare och en bara för administratörer. Användaren kan navigera mellan de olika modulerna genom en meny som finns på alla sidor. Är användaren administratör så tillkommer ett extra menyval för de administratörssidor som finns.

Bokningssidan är den första sidan som användaren kommer till. På den här sidan kan användaren boka in sin önskade ledighet genom att välja datum för ledigheten samt vilken typ av ledighet användaren önskar. Det går att boka in tre olika typer av ledighet i systemet; semester,

föräldraledighet och jour. På den här sidan finns även alla gjorda registreringar tillgängliga så att användaren kan ändra eller ta bort dem helt. Figur 8 visar bokningssidan.

Figur 8. Bokningssidan i Vacation 2.0.

21 För att boka in en semesterledighet så börjar användaren att välja start- och slutdatum ifrån

respektive kalender och sedan väljer användaren typ av ledighet genom att trycka på knappen semester. Sedan för att slutföra bokningen så trycker användaren på ”spara bokning”-knappen. För att ändra på en bokning så trycker användaren på bokningens ändra knapp ifrån listan över gjorda bokningar. När bokningen är vald så väljer användaren nytt start- och slutdatum samt typ och trycker på ”spara ändrad bokning”-knappen för att spara ändringen. För att ta bort en bokning så trycker användaren på ”ta bort”-knappen för en bokning ur listan över bokningar och bekräftar genom att trycka ja på dialogrutan som visas.

Den andra sidan som är tillgänglig för alla användare är en sida som ger användaren möjligheten att generera ledighetsscheman för olika arbetsgrupper. På sidan möts användaren utav ett

ledighetsschema över alla grupper som användaren är med i. Härifrån har även användaren en möjlighet att gå vidareför att söka upp andra ledighetsscheman för arbetsgrupper för att sedan spara dem i personliga listor. Figur 9 visar ett exempel på semestertabellen.

För att visa en tabell över ledighet så väljer användaren först start- och slutdatum för att bestämma spannet på semestertabellen. När det är gjort så väljer användaren en grupp ifrån listan med

arbetsgrupper och trycker sedan på knappen ”Lägg till grupp” för att visa gruppens tabell. Namnet på listan användaren vill spara skrivs in i textfältet och sparas sedan genom att trycka på knappen ”Spara till ny lista”. Figur 10 visar den avancerade vyn.

Figur 10. Semestertabellens avancerade vy.

Administratörsfunktionerna är uppdelade så att varje verktyg har sin egen sida. Det finns en sida där användaren kan söka efter andra medarbetare i personalregistret för att ge administratörsrättigheter samt en sida med en lista över administratörer där användaren kan ta bort

administratörrättigheterna ifrån en medarbetare i listan. Det finns en sida där användaren kan skapa arbetsgrupper och när en ny grupp skapas så omdirigeras användaren till en sida för att editera grupper. På denna sida kan användaren ta bort och lägga till medarbetare i arbetsgrupper. Det finns även en sida för att ta bort arbetsgrupper från lista över grupper som även går att söka i. Den sista administratörssidan är till för att redigera andra medarbetares ledighetsansökningar. Detta görs genom att användaren omdirigeras till bokningssidan men med ett extra verktygsfält för att söka upp och ändra andra medarbetares bokningar.

23

Figur 11. Administratörsverktyget används för att ändra medarbetares ledighetsansökningar.

För att ändra en medarbetarens bokningar så trycker användaren på Admin i huvudmenyn och väljer sedan ”Andra andras bokningar” i undermenyn för att komma till verktyget. Administratören ser då ett verktyg likt sin egen bokningssida men med ett verktygsfält för att välja andra medarbetare. Medarbetaren vars boknings man ska ändra på skrivs in i textfältet och sedan trycker

administratören på knappen ”byt medlem” för att välja medarbetare. Sidan populeras med den valda medarbetarens bokningar och administratören kan nu göra vilka ändringar som helts, som om administratören var medarbetaren i frågan. Figur 11 visar administratörsverktyget.

4.1.2 Tekniskbeskrivning

Figur 12. Databasstrukturen i Vacation 2.0.

Vacation 2.0 har en SQL databas med sex stycken tabeller som är förklarade i figuren ovan.

Databasen är framtagen för att minimera duplicering av data och hanterar endast information som är relevant för Vacation 2.0. Databasen körs på en server som ligger i CGI:s intranät för Linköping- och Norrköpingkontoret. Figur 12 visar databasstrukturen.

Figur 13. Anrops- och svarsstruktur i Vacation 2.0.

Det skapas ett postback event genom till exempel en knapptryckning eller via JavaScript sedan så skickas en efterfrågan efter en URL via HTTP POST. Servern tar sedan emot förfrågningen och börjar skapa webbsidan baserat på det innehåll i alla taggar den har fått ifrån .aspx-filen. Nästa steg är att alla ASP.NET Controls populeras med information från View State-datan. ASP.NET Controls är alla ASP-specifika taggar för generering av websidor. Figur 13 visar Anrops- och svarsstruktur i Vacation 2.0. Admins ID adID GroupMembers ID groupID adID Groups ID name PersonalList ID listName groupName adID Registrations ID startDate endDate adID regTypeID RegistrationTypes ID typeName

25 Sidans initieringskod körs följt av den eventspecifika koden, till exempel ASP.NET funktionen onClick. I många fall så kräver eventspecifika koden att systemet kommunicerar med systemet databas. Vacation 2.0 har en hjälpklass skriven i C# som sköter all kommunikation mellan systemet och databasen. Denna kommunikation sker genom att hjälpklassen kallar på stored procedures som är lagrade i databasen. I Vacation 2.0 finns det även en hjälpklass för kommunikation till

personalregistret, även denna klass är skriven i C#. Klassen har ett antal funktioner implementerade för att sköta LDAP-uppslagningar som används för att hämta information om medarbetare [31]. För att verifiera användaren så jämför vi informationen som vi får utav Windows Autentisering med den information vi får från personalregistret.

Figur 14. Abstraktionsmodell för Vacation 2.0.

När servern förbereder dess svar på förfrågan börjar den med att spara all information om ASP.NET Controls i view state-datan. För att sedan renderar sidan i ren HTML som skickas till klienten, som kan läsas av dess webbläsare. Figur 14 visar Abstraktionsmodell för Vacation 2.0.

5 Diskussion

5.1 Verktyg och ramverk

Tidigare när vi har arbetat med webbaserade projekt så har vi oftast inte använt oss av någon form av ramverk utan utvecklat med till exempel JavaScript och PHP i någon enklare utvecklingsmiljö som NotePad++ [32]. Det enda ramverket för webutveckling vi har gått djupare in på är JavaEE, men att använda det i det här projektet uteslöt vi ganska fort då vi var inställda på att lära oss ett ramverk som vi inte använt sen innan [33]. Det nuvarande systemet är skrivet i en äldre version av ASP.NET Web Forms. Efter en ingående introduktion av ASP.NET Web Forms samt ASP.NET MVC så kände vi att det här var något vi ville lära oss mer utav.

Fördelen med ASP.NET Web Forms är att man får en bättre översikt om vad som sker bakom kulisserna och man har även ett större inflytande över strukturen av projektet. ASP.NET MVC gör väldigt mycket i bakgrunden som man slipper tänka på och ger en mer fast struktur som ska följas. Strukturen som ASP.NET MVC ger är väldigt användbart vid just större projekt men vi ansåg att vi inte behövde det, då vårt projekt var relativt litet. Att mycket av arbetet automatisk sker i bakgrunden kan vara väldigt skönt för utvecklaren men vi ville gärna bestämma mer själva då vi skulle lära oss ett nytt ramverk. ASP.NET Web Forms uppfattade vi som den mer grundläggande varianten av dem både och eftersom vi var helt oerfarna av ASP.NET sen innan så ansåg vi samt vår handledare att ASP.NET Web Forms var det givna valet för att kanske vid framtida projekt använda ASP.NET MVC då vi skulle förstå bättre hur allt hänger ihop bakom kulisserna.

Ska man utveckla för ASP.NET Web Forms så känns det ganska självklart att används Microsofts utvecklingsmiljö Visual Studio, som vi även har använt oss av tidige i vår utbildning. Det är även den utvecklingsmiljö som används i störst utsträckning på förtaget.

Det finns många verktyg som man kan använda för att hantera SQL databaser. Vi valde Microsoft SQL Server Management Studio 2012 eftersom vår handledare rekommenderade det stark samt att det redan var installerat på datorerna vi hade blivit tilldelade av företaget. Programmet fungerade väldigt bra och därför såg vi ingen anledning till att undersöka några andra alternativa program för detta ändamål.

De flesta hemsidor idag använder sig av någon form av kod som körs på klientsidan och JavaScript är det absolut vanligaste språket som denna kod är skriven i [34]. Eftersom vi båda har tidigare

erfarenhet av JavaScript och även biblioteket jQuery så kändes det som en ganska naturligt val att använda oss av det för vår klientkörda kod.

I det nuvarande systemet så används plugin-verktyget AJAX Control Toolkit till ASP.NET för till exempel kalendrarna som används för att välja datum samt används för sökfunktion mot

användartabellen i databasen. Microsoft har även många exempel för detta plugin på deras hemsida och det blev den största anledningen till att vi började experimentera med detta plugin. Vi fick dock fort många problem och implementationen började kändes överdrivet komplext för dessa delar. Eftersom även jQueryUI har många bra exempel på vad vi ville göra med kalendrarna och

databassökningen så gick vi över till att försöka implementera dessa i vårt system. Detta gick betydligt enklare och jQueryUI har även ett grafiskt gränssnitt som vi tycker passade bra in på vår sida utan att behöva ändra för mycket på det.

27 Vi kom tidigt fram till att vi ville använda CGI:s personalregister för uppslagning av användare i vårt system. Främsta anledningen till det här var att det gamla systemet hade en egen databas som med tiden hade blivit inaktuell och blivit fylld med korrupt data.

Vi tyckte att det skulle vara väldigt behändigt att använda personalregistret, då det gav oss all information vi behövde veta om de anställda och mycket mer. Att vi hade så mycket överflödig information gav oss ibland vissa problem. Även avsaknad av information orsakade vissa problem. Vi förutsatte att viss information fanns för varje anställd i registret men för några så saknades dessa. Därför var vi tvungna att alltid kontrollerna att den här informationen fanns för att den anställda i frågan skulle få använda systemet.

Ifall vi inte skulle bli beviljade åtkomst till personalregistret så undersökte vi andra alternativa lösningar. Det mest aktuella alternativet skulle vara att ha en egen databas för de anställda som skulle få använda systemet, på liknade sätt som i det nuvarande systemet. Då vi snabbt blev beviljade åtkomst behövde vi inte denna lösning vilket även skulle göra arbetet lättare för administratörerna, då den manuella inmatningen med att lägga till och ta bort användare från systemet inte behövs.

5.2 Tekniska lösningar

Vi har abstraherad bort många delar av vår kod för att göra det lättare för andra att sätta sig in i koden samt för att göra vårt arbete lättare och mer effektivt. Abstraktionen har hjälpt oss minimera risken för duplicerad kod och gjort det yttersta lagret av koden mer verbaliserad. En stor del av abstraktionen är att vi i det översta lagret inte gör direkta anrop till databasen eller personalregistret utan anropar hjälpklasser som gör det istället.

Vi har använt oss av JavaScript widgets för att göra vårt arbete enklare och mer effektivt. Genom att använda de här verktygen får man en bra abstraktion men det gör även att det kan vara svårt att modifiera verktygen efter ett exakt behov. Hade vi haft tid att skaffa den kompetens som behövts hade vi gjort mycket av det här helt själva och skapat verktyg för att kunnat realisera våra

systemskisser till fullo.

I Vacation 2.0 har vi valt att begränsa och styra användarens val för inmatning i systemet, vilket har gjort att vi kunnat göra många antaganden i vår kod gällande till exempel kontroller av datatyper och format på parametrar. Detta har gjort vårt arbete enklare och smidigare samt fungerar bra med hur systemet ser ut idag. Det kan dock resultera i problem om det byggs ut eller ändras.

Databasen till Vacation 2.0 designade vi efter eget tycke och efter tidigare lärdomar om

databasdesign. Det här gav en databas som vi är nöjda med som innehöll relevant data samt hade en struktur som passade systemets nuvarande behov. Databasen kontrollerandes även av vår

handledare och sågs som en bra lösning även från hans sida. Som en ytterligare bekräftelse på vår design av databasen så har vi i efterhand analyserat den och kommit fram till att databasens struktur har normalformen 3NF [35].

Under projektets gång så har vi hela tiden testat delfunktioner i systemet med enkla visuella

inmatningar och tester innan vi har lagt upp det på SVN [36]. Det här tillvägagångssättet gjorde att vi sparade in väldigt mycket tid som annars skulle ha används till att skriva testfall. Tillvägagångssättet medför även ett riskmoment då man ofta förbiser sina egna brister. För att minska risken för sådana situationer såg vi till att testa varandras kod. Vid slutet av projektet gjorde vi även heltäckande

testningar av systemet för att upptäcka eventuella fel vi missat. Till den här testningen tog vi även in utomstående testare som kunde se systemet från ett nytt perspektiv och hitta fel som vi kan ha missat. Vi tyckte att det här tillvägagångssättet fungerade bra för vårt projekt men om systemet skulle ha fått en publik lansering eller ha haft annorlunda kopplingar till andra interna system så skulle vi behöva ha gjort mer utförliga testningar med hjälp av till exempel enhetstestningar [37]. ASP.NET Web Forms har fungerat väldigt bra för uppgiften och vi har haft tillgång till utförlig

dokumentation. Då ASP.NET Web Forms hade en så bra dokumentation och var lätt att komma igång med så anser vi att ASP.NET Web Forms var ett bra val för någon med lite erfarenhet av

webutveckling med .NET-ramverket. Har man dock tidigare erfarenhet av webutveckling med .NET anser vi att man bör använda sig av ASP.NET MVC då det är mer framtaget för skalbara projekt, vilket underlättar för eventuella framtida behov vid expandering. ASP.NET Web Forms var ett bra val för oss till det här projektet men skulle vi göra om projektet med den kunskapen vi besitter nu så skulle vi valt ASP.NET MVC på grund av dess expanderingsmöjligheter.

Arbetet följde en grov tidsplan som vi lade upp i början av projektet. Vi höll tidsramen som vi hade satt vid planeringen för implementationen av Vacation 2.0 dock så blev implementationen

uppskjuten på grund av uppstartsfasen. Anledningen till detta var att det tog längre tid än lovat att få vår utrustning levererad.

Deployen tog längre tid än vi hade uppskattat på grund av skillnaderna mellan utvecklingsmiljö och realmiljön samt den mänskliga faktorn. Vi utvecklade vår databas för SQL Server 2012 medan realmiljön använde SQL Server 2000, detta medförde att några stored procedures inte fungerade som förväntat [38]. Ett problem som kom fram när systemet lämnade våra lokala servrar var navigeringsproblem då länkarna inte tog hänsyn till applikationsdomänen, vår existerande lösning utgick istället ifrån serverns domän. Ett annat problem som uppstod var krypteringskonflikter då det ibland uppstod situationer där uppkopplingen växlade mellan serverns nätverkskort, vilket gav olika maskinnycklar.

I projektet så har vi fått uppleva fördröjningar på grund av den mänskliga faktorn redan från starten. Vår utrustning blev levererad senare än lovat, vilket orsakade en kort förskjutning av

implementationen. När vi sedan skulle lägga upp Vacation 2.0 på realmiljön för att kunna göra de sista testerna av systemet så tog kommunikationen mellan kontorets systemadministratör och vår handledare längre tid än vi hade förutspått. Systemadministratören gav vår handledare rättigheter att uppdatera Vacation 2.0 på realmiljön men eftersom det inte var vi själva som gjorde

uppdateringarna så blev det även där en del fördröjning. Vi blev tilldelade några systemtestare som skulle mer utförligt testa Vacation 2.0. Det tog dock några dagar innan de hade tid att sitta med systemet samt några dagar till efter det innan de var redo att presentera vad de hade för resultat för oss.

5.3 Subversion

Företaget hade ett SVN repository för interna projekt som de rekommenderade oss att använda för vår versionshantering av projektet. Det finns väldigt många hjälpmedel för att sköta

versionshantering men eftersom vi är vana med att använda SVN bestämde vi att använda oss utav det och därmed inte utforska andra möjligheter. För att få en smidig och lättillgänglig

versionshantering så ville vi integrerat vår versionshantering med ett plugin i utvecklingsmiljön. AnkhSVN är ett välanvänt plugin för Visual Studio som vi hoppades skulle hjälpa oss med detta. Dock

29 uppstod det problem med att binda repositoryt med AnkhSVN och vi ville inte slösa bort tid på att försöka lösa problemen vi hade. Därför valde vi att använda oss utav TortoiseSVN vilket är något vi har erfarenhet utav innan och fungerade bra för projektet.

5.4 Befintliga systemet

CGI har ett befintligt system som används för ledighetsansökan. I det befintliga systemet så kan inte en administratör ta bort användare via systemets gränssnitt. Detta görs istället genom att skriva över användarens information med en blank rad, vilket resulterade i att systemets databas innehåller väldigt många felaktiga tabellrader. Systemets gränssnitt kändes väldigt ogenomtänkt och har en väldigt osammanhängande navigation. Inte ens systemets administratörer som har använt systemet sen lansering är helt säkra på var de ska trycka på för att utföra vissa uppgifter. I systemet ska

administratörerna bevilja varje ledighetsansökan vilket är en funktion som aldrig används utan utreds genom en muntlig dialog med administratören och den personen som sökt om ledighet. Det finns även fler funktioner i systemet som inte användes eller inte har något syfte. Genom att granska systemets kod och utseende så fick vi en bra bild över vad vi behövde implementera i vårt system. Vi insåg också att största bristen i nuvarande systemet ligger i administratörsverktygen och att vi behövde lägga mer fokus på det för att göra dem användarvänligare så att vårt system skulle användas som vi har tänkt oss.

5.5 Mål

I projektet hade vi tre övergripande mål som vi ville uppnå vid projektets slut. Vi ville lära oss något nytt och breda våra kunskaper, vi ville att systemet vi arbetade med skulle bli klart och skulle vara stabilt. Vi ville även få en inblick över hur utvecklingsprojekt fungerar ute på företag.

Vi tycker att vi har nått vårt mål med att bredda våra kunskapare då vi har arbetat med nya ramverk och utvecklingsmiljöer som vi inte haft stor erfarenhet utav innan. ASP.NET Web Forms som vi har arbetat med var helt nytt för oss innan projektets start. Vi har lärt oss mycket av hur det fungerar samt känner oss säkra nog för att kunna använda det igen för kommande projekt. Vi har även arbetat med jQuery, CSS samt SQL, dessa verktyg har vi arbetat med tidigare men i och med detta projekt så har vi fått djupare kunskap inom dessa områden.

Under projektet har vi fått inblick hur företag arbetar med systemutveckling och vilka processer som ingår i arbetet. Även vårt projekt har följt dessa processer och genom detta gett oss ett färdigt och stabilt system. Vi känner oss nu säkra i tillvägagångsättet som förtaget använder samt de verktyg som vi lärt oss och skulle kunna arbeta mer med dessa i framtiden.

5.6 Begränsningar

Vi fick väldigt få begränsningar och direktiv ifrån CGI vilket var på både gott och ont. Friheten gjorde att vi fick bestämma vad vi skulle göra och hur vi skulle göra det, vilket gjorde att systemet blev mer personligt. Det gjorde även att vi var tvungna att lägga mycket tid av projektet på moment som brukar vara färdiga innan man börjar. Det gjorde att vi fick mindre tid till implementation av systemet. Vi var till exempel tvungna att spendera tid på att ta fram krav och begräsningar av projektet samt att göra en grafisk skiss av projektet, vilket oftast görs utav personer med en annan utbildning och arbetsroll.

Vi gjorde en begränsning till att intranätet skulle användas vilket underlättade vår implementation. Det gjorde att vi inte behövande tänkta på säkerheten till samma utsträckning som om det skulle

vara en publik hemsida. Vi kan därefter även göra vissa antagande om användarna, som till exempel att de finns i personalregistret då de redan har loggat in med sina personliga Windows-login. Vi tänkte att den här begräsningen var bra eftersom det underlättade vårt arbete med

implementationen men det gör även att systemet har svårigheter att växa till ett större och mer utbrett system.

En förutsättning som CGI ställde var att systemet funktionellt skulle vara bakåtkompatibelt med Internet Explorer version 8. Redan från början så gillade vi inte det här kravet då det medförde problem med design då det inte stödjer så mycket av de nya funktionerna för HTML5 och CSS3. Vi utvecklade och testade systemet främst i webbläsaren Google Chrome då vi ändå ville utveckla systemet med hjälp av HTML5 och CSS3 samt att Chrome har ett mycket bra utvecklarverktyg inbyggt i webbläsaren som vi är vana att använda sen innan. Vi försökte få systemet att se så likt ut som möjligt i Internet Explorer 8 som det gjorde i Chrome men fick göra några kompromisser. Vi lyckades uppfylla kravet då all funktionalitet var intakt även i Internet Explorer 8 men det grafiska gränssnittet skilde sig en del ifrån hur systemet ser ut på nyare webbläsare.

Ett önskemål som kom fram i intervjuerna var att systemet skulle vara åtkomligt på mobila enheter så som smartphones, gärna i form av en applikation. Detta prioriterades bort då det skulle ha medfört väldigt mycket extrajobb med säkerhet och plattformsanpassning.

Vi som utvecklare, tyckte att det skulle vart kul att implementera någon form av direktkoppling till lönesystemet. Den här idén insåg vi ganska snabbt att det skulle kräva för stor arbetsinsats, samt att det framgick ifrån intervjuerna att de anställda samt administratörerna inte kände något behov utav det.

5.7 Krav

Till projektet fick vi i uppgift att ta fram vår egen kravspecifikation, vilket vi gjorde genom

systemutvärdering, skisser och intervjuer. Det här tyckte vi var ett bra sätt för att få fram vad vi samt användarna skulle vilja få ut av systemet. Intervjuerna vi höll hade en ostrukturerad struktur för att inte styra in de intervjuade på en specifik riktlinje utan få fram en mer spontan åsikt om systemet. Det gjorde att vi fick höra mer av deras egna tankar och åsikter om systemet, vilket var vårt mål med intervjuerna. Vi valde sedan att dela upp de krav vi hade sammanställt i tre olika prioritetsgrupper som var grundläggande krav, personliga krav samt systemutökande krav.

Av kraven vi tog fram så lyckades vi uppfylla alla grundkrav utom ett. Det kravet som inte uppfylldes var att varje arbetsgrupp skulle vara kopplade till en gruppansvarig. Det här kravet var inte något som hade kommit ifrån intervjuerna utan något vi tyckte själva tyckte skulle vara bra att ha, men under arbetets gång så prioriterade vi bort detta krav för få tid att kunna uppfylla de andra kraven. Utöver grundkraven hann vi även med ett urval av de utökade kraven samt ett ytterligare krav som vi kom på under arbetets gång.

5.8 Arbetssätt

Vi valde att utföra ostrukturerade intervjuer för att få en bredd på de intervjuades åsikter. Det här gjorde till viss del att vi även fick många irrelevanta svar som var svåra att kategorisera. Det krävde mer tid från oss att sammanställda resultatet än om vi valt en mer strukturerad teknik. Vi kände också att det var viktigt att lämna det öppet för de anställda att prata fritt då vi inte var så insatta i vilka behov som fanns. Hade vi valt en semistrukturerad eller strukturerad teknik så hade vi

31 antagligen fått en mer enhetlig svarsgrund att formulera kraven efter men eftersom vi inte visste vad vi skulle ha frågat efter i en sådan intervju så valde vi bort det alternativet.

I vår utbildning har vi fått erfarenhet av Extreme Programming och Scrum vilket vi har blivit

inspirerade av i det här projektet. Även om vi inte har följ någon av metoderna fullt ut så har vi tagit de delar vi tyckte passade bra in på projektet. Vi är vana att arbeta med de metoderna och vi är även vana att arbeta tillsammans sen innan. Vi vet därför vilka delar vi trivs med och anser är viktiga att följa.

5.9 Vidareutveckling och underhåll

Då de nuvarande kraven på systemet är uppfyllda är det svårt att spekulera i vad Vacation 2.0 skulle kunna utökas med i form av funktionalitet. En av utökningarna som vi har funderat på är att knyta Vacation 2.0 till fler interna användarsystem. En sådan utökning skulle antagligen resultera i merarbete för att kunna garantera att Vacation 2.0 ger ifrån sig rätt data. I nuvarande version av Vacation 2.0 så är till exempel typ och formatkontrollerna inte så strikta vilket skulle kunna vara viktigare i andra system.

En möjlighet skulle vara att Vacation 2.0 sprids till flera orter för att användas på fler kontor. Skulle det användas en gemensam databas för att genomföra denna spridning så skulle det innebära att vår implementation skulle behöva omstruktureras för att uppfylla de nya kraven men vi ser inte det som någon omöjlig uppgift. Skulle systemet användas som det gör nu och ha en egen databas per kontor så skulle det däremot inte medföra någon ytterligare insattas utöver lanseringen av systemet till det nya kontoret.

Det kommer alltid krävas en viss mängd underhåll för system av den här slaget i form av till exempel serverunderhåll eller ominstallation vid serverbyte. I övrigt så kommer inte Vacation 2.0 kräva något speciellt underhållsarbete.

Vacation 2.0 förlitar sig på att Integrated Windows Authentication används som det gör med de nuvarande Windowsoperativsystemen. Det här är något som systemadministratörerna behöver ha kännedom om vid framtida operativsystems uppdateringar då annorlunda tillvägagångsätt kan ske vid inloggningshantering.

Företagets personalregister förväntas se ut och fungera som det gör på nuvarande sätt för att systemet ska fungera. Det är viktigt att ha kännedom om att vårt system fungerar på det viset ifall personalregistrets struktur någon gång i framtiden skulle ändras. Det skulle då innebära att Vacation 2.0 skulle behöva ändras för att matcha det nya personalregistret.

6 Slutsats

Vacation 2.0 är ett system som hanterar företagets ledighetsansökningar. Med systemet kan man ansöka om ledighet och ansvariga löneadministratörer får en överblick över medarbetarnas ledighetsansökningar. Vacation 2.0 låter de ansvariga organisera medarbetare i grupper och kan därmed planera semesterbeläggningen på ett effektivt sätt. Informationen som Vacation 2.0 hanterar går att dela med sig genom exportering till Excel-dokument. Systemet har ett modernt gränssnitt som är lättöverskådligt och som användaren intuitivt kan använda sig av. Genom

automatisk autentisering underlättas inloggningen. Vacation 2.0 kommunicerar med CGI:s befintliga företagssystem och databaser vilket bör minsta underhållsproblematiken.

Det har säkerhetsställts att Vacation 2.0 uppfyller CGI:s behov då genomgående användartester av CGI:s systemtestare har genomförts. Systemet används för närvarande hos CGI:s Linköping- och Norrköpingskontor och är lätt att vidareutveckla och expandera vid behov.

33

Referenser

[1] DeepBlueSky (2013-03-05). HTML5 & CSS3 Support [Online]. http://www.findmebyip.com/litmus/ [2] Wikipedia (2013-03-05). Integrated Windows Authentication[Online].

http://en.wikipedia.org/wiki/Integrated_Windows_Authentication

[3] Logica (2013-03-05). CGI och Logica [Online]. http://www.logica.se/we-are-logica/about-logica/ [ny 4] Wikipedia (2013-05-07). Application lifecycle management [Online].

http://en.wikipedia.org/wiki/Application_management

[5] WhosOff (2013-03-05). Features[Online]. http://www.whosoff.com/features/

[6] F. Dawson & D. Stenerson (2013-03-28). Internet Calendaring and Scheduling Core Object Specification (iCalendar)[Online]. http://www.ietf.org/rfc/rfc2445.txt

[7] LeaveWizard (2013-03-05). What LeaveWizard helps you to do [Online]. http://www.leavewizard.com/Features.aspx

[8] dhxsoft (2013-03-05). The Staff Leave Planner[Online]. http://www.dhxsoft.com/index.php [9] Situ AB (2013-03-28). Om Personalkollen[Online]. https://personalkollen.se/om-personalkollen/ [10] NCH Software (2013-03-28). FlexiServer Productivity & Attendance Software [Online].

http://www.nchsoftware.com/flexi/index.html

[11] Dan M. Brown, Communicating Design: Developing Web Site Documentation for Design and Planning, 2nd Edition. New Riders, 2010.

[12] Microsoft Corporation (2013-03-06). ASP.NET MVC Overview [Online]. http://msdn.microsoft.com/en-us/library/dd381412(VS.98).aspx

[13] Microsoft Corporation (2013-03-06). What is Web Forms [Online]. http://www.asp.net/web-forms/what-is-web-forms

[14] Wikipedia (2013-03-06). Microsoft Visual Studio [Online]. http://en.wikipedia.org/wiki/Microsoft_Visual_Studio

[15] Wikipedia (2013-03-07). GUI widget [Online]. http://en.wikipedia.org/wiki/GUI_widget [16] Microsoft Corporation (2013-03-06). ASP.NET AJAX Control Toolkit [Online].

http://www.asp.net/ajaxLibrary/AjaxControlToolkitSampleSite/Default.aspx [17] jQuery (2013-03-06). About jQuery UI [Online]. http://jqueryui.com/about/ [18] Wikipedia (2013-03-06). SQL Server Management Studio [Online].

http://en.wikipedia.org/wiki/SQL_Server_Management_Studio

[19] The TortoiseSVN Team (2013-03-06). About TortoiseSVN [Online]. http://tortoisesvn.net/about.html

[21] Microsoft Corporation (2013-03-06). Capitalization Conventions [Online]. http://msdn.microsoft.com/en-us/library/ms229043.aspx

[22] Google (2013-03-06). Google HTML/CSS Style Guide [Online]. http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

[23] Google (2013-03-06). Google JavaScript Style Guide [Online]. http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

[24] Wikipedia (2013-03-06). jQuery [Online]. http://en.wikipedia.org/wiki/JQuery

[25] Kent Beck och Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd Edition. Addison-Wesley, 2004.

[26] Mike Cohn, Succeeding with Agile: Software Development Using Scrum, 1st Edition. Addison-Wesley Professional, 2009.

[27] Wikipedia (2013-03-05). Interview [Online]. http://en.wikipedia.org/wiki/Interview [28] Wikipedia (2013-03-05). Structured Interview [Online].

http://en.wikipedia.org/wiki/Structured_interview

[29] Wikipedia (2013-03-05). Semi-structured interview [Online]. http://en.wikipedia.org/wiki/Semi-structured_interview

[30] Wikipedia (2013-03-05). Unstructured interview [Online]. http://en.wikipedia.org/wiki/Unstructured_interview

[31] K. Zeilenga, Ed. OpenLDAP Foundation (2013-03-07). Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map [Online]. https://tools.ietf.org/html/rfc4510

[32] Don Ho (2013-03-06). About [Online]. http://notepad-plus-plus.org/ [33] Oracle (2013-03-06). Java EE at a Glance [Online].

http://www.oracle.com/technetwork/java/javaee/overview/index.html

[34] BuiltWith (2013-03-07). JavaScript Usage Statistics Overview of statistics for JavaScript technologies [Online]. http://trends.builtwith.com/javascript

[35] Microsoft Corporation (2013-03-06). Description of the database normalization basics [Online]. http://support.microsoft.com/kb/283878

[36] Wikipedia (2013-03-06). Apache Subversion [Online]. http://en.wikipedia.org/wiki/Apache_Subversion

[37] Wikipedia (2013-03-07) Unit testing [Online]. http://en.wikipedia.org/wiki/Unit_testing [38] Wikipedia (2013-03-06) Microsoft SQL Server [Online].

http://en.wikipedia.org/wiki/Microsoft_SQL_Server

35

Appendix

Kravspecifikation

Grundläggande krav

 Det finns ett behov av att kunna se minst 3 månaders semester för enskild medarbetare eller projektgrupp.

 Det finns ett behov av att ha en dynamisk överblicksida. Det ska på ett smidigt sätt gå att välja vilka projektgrupper eller medarbetare som ska visas.

 Det har uttrycks behov av att användaren ska ha stor möjlighet till att själv välja vilka projektgrupper som syns och hur dom är sorterade på sidan.

 Användarna vill också kunna söka bland grupper på ett smidigt sätt, t.ex. få fram alla grupper där användaren själv är med i.

 Det finns ett behov av att på en projektgrupps överblick kunna se om någon har jour, alltså inte är på plats fysiskt men jobbar hemifrån.

 Det finns ett behov av att göra registreringen simpel och lättförsåtlig genom att minsta mängden val och information som kommer upp vid registrering.

 Nuvarande månad ska visas vid registrering och det skall inte kunna registreras något bakåt i tiden.

 Det skall endast finnas så många sorters ledighetsregistreringar som det finns behov för. För det existerande systemet är dessa; ledighet, beredskap och föräldraledighet.

 Det skall vara enkelt att lägga till och ta bort medarbetare i systemet.

 Det skall även vara lätt att skapa, redigera och ta bort projektgrupper.

 Det är viktigt att medarbetarnas namn och inte användar-ID används och visas på korrekt sätt i systemet.

Systemutökande krav

 Undersöka ifall systemet behöver stödja den gamla strukturen vad användar-ID.

 Det finns ett behov av at kunna se röda dagar i semestertabellen.

 Det finns ett behov av att kunna se veckonummer i semestertabellen.

 Det finns ett behov av att kunna exportera semesteröverblicken till användarvänliga format, som t.ex. Excel.

 Gruppansvarig för en vald grupp ska visas tydligt.

 Det finns ett behov av att kunna skriva ut semesteröverblicken direkt, utan exportering.

 Knyta projektgrupper till t.ex. arbetsort eller kontor.

 Som användare skapa och spara egna listor över vad personen i fråga vill se i semestertabellen.

 Ge administratörer möjlighet att låsa eller bevilja registreringar.

 Kunna ändra registreringar genom semestertabellen.

 Kunna boka in spann av flera olika ledighetsansökningar i samma ansökan.

 Koppla samman vårt system så att det direkt påverkar förtagets lönesystem.

 Flera användarnivåer. Olika behörigheter beroende på olika nivåer av administratörer och roller.

Utvecklarnas önskemål

 Att som användare kunna se hur många semesterdagar man har kvar och hur många man har tagit ut.

 Ett kontrollsystemsystem så att en medarbetare inte ska behöva flytta sin semester ifall personen i fråga nyligen behövt göra det.

 Som användare specificera vilken roll man har i olika grupper.

 En personlig användarprofilsida där användaren i fråga kan se personlig information som t.ex. listor över arbetsgrupper, antal semesterdagar kvar, arbetsroll i olika grupper, osv.

 Mail-avisering till administratörer angående ledighetsansökningar ifrån användare.

 Synkning till Google-kalander samt bekräftelse via Google-kalender eller Outlook.

37 På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinä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 det 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 http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on 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: http://www.ep.liu.se/