TIDRAPPORTERINGSSYSTEM

1(23) Mälardalens Högskola Västerås 2003-12-15 Institutionen för Datateknik Examensarbete i Datateknik, C-nivå Handledare (Idt): Filip Sebek Handledare (företag): Mohammed El Shobaki TIDRAPPORTERINGSSYSTEM Ulf Carlsson 6701218-7011 ucn98005@student.mdh.se Martin Warholm 790710-0494 mwm98012@student.mdh.se

2(23) SAMMANFATTNING Denna rapport beskriver ett examensarbete i ämnet datateknik vid Mälardalens högskola i Västerås. Resultatet är en webbapplikation för tidrapportering som är utvecklad för Shobaki System Solutions HB och är anpassad för anställda på högskolan. Tidrapporteringssystemet bygger på klient-server arkitektur med en MYSQL databas som hanterar obegränsat antal användare. Inrapportering sker via webbläsare och möjlighet finns även att göra dessa när datorn ej är uppkopplad mot internet. Rapporten ger inledningsvis en presentation av liknande produkter som finns på marknaden. Vidare beskrivs applikationen som gjorts, relevant teori inom de tekniker som använts (såsom databaser, utvecklingsmiljö, skriptspråket PHP och cookies). En analys av resultatet tas upp och vidare beskrivs hur designen av databasen lades upp för att få en så stabil och robust produkt som möjligt.

3(23) Förord Merparten av examensarbetet utfördes sommaren 2002 men slutfördes helt under höstterminen 2003. Vi vill tacka vår handledare, Mohhamed El Shobaki, för synpunkter och råd angående design och databaser. Dessutom vill vi tacka vår handledare på Idt, Filip Sebek, för synpunkter på rapporten.

4(23) Innehåll 1 Bakgrund...6 1.1 Syfte...6 1.2 Andra Produkter...6 1.2.1 Beskrivning av Artologik TM:s produkt TIME 6 1.2.2 Hur används TIME av företag och organisationer... 1.2.3 Olika roller i TIME 7 1.2.4 Fördelar med TIME 8 1.2.5 Nackdelar med TIME 8 1.3 Vår Webbapplikaton för tidrapportering...8 1.3.1 Uppbyggnad 8 1.3.2 Tidrapportering 8 1.3.3 Rapporter 9 1.3.4 Administration 9 1.3.4.1 Befogenheter 9 2 Relevant Teori...9 2.1 Databas...9 2.1.1 Förklaring 10 2.1.2 Fördelar med att använda en databas 10 2.1.3 Databashanteringssystem, DBMS 10 2.1.4 Relationsdatabas 11 2.1.4.1 Fördelar med relationsdatabas 11 2.1.4.2 Primärnyckelfält 11 2.1.5 Klient/server arkitektur 12 2.2 Utvecklingsmiljö...12 2.2.1 Plattform 12 2.2.2 LAMP-plattformen 12 2.2.3 PHP 13 2.2.4 MySQL 13 2.3 Cookie...13 2.3.2 Introduktion till cookies. 13

5(23) 2.3.2 Session cookie 14 2.3.3 Var finns en cookie? 14 2.3.4 Var sparas en cookie? 14 2.3.5 Vad innehåller en cookie? 14 3 Problembeskrivning...15 3.1 Avgränsning...15 3.1.2 Tidsplanering 15 3.1.3 Specifikation 15 3.1.3.1 Tidrapportering 15 3.1.3.2 Användarklasser 15 3.1.3.3 Användarinställningar 16 3.1.3.4 Tidrapporter 16 3.1.3.5 Systemkonfiguration (endast admin) 16 3.1.3.6 Offline tidrapportering 16 3.1.3.7 Användarkonfiguration (endast admin) 16 4 Problemanalys...17 5 Modell/Metod...17 6 Lösning...17 7 Resultat...18 7.1 Analys av resultat...18 7.2 Design av databas...18 7.2.1 Datamodellering 19 7.3 Implementation...19 7.4 Testning...19 7.5 Framtida arbete...19 8 Summering och slutsatser...20 9 Referenser...21 10 Billagor...22

6(23) Inledning Examensarbetets syfte var att ta fram ett webbaserat, databasdrivet tidrapporteringssystem. I systemet ska användaren kunna rapportera tid för olika arbetsuppgifter under dagen. Systemet ska även kunna skapa rapporter. 1 Bakgrund I dagens moderna IT-samhälle har den traditionella stämpelklockan eller pappersbaserad tidsredovisning blivit en allt mer föråldrad lösning för många yrkesgrupper. Flexibla arbetsmiljöer, arbetstider, distansarbete och arbete i olika projekt är några faktorer som gör dessa lösningar otillräckliga. 1.1 Syfte Personalen på IDT har i flera år rapporterat tid i ett formulär gjort i excel. Syftet med examensarbetet var att konstruera ett system för tidrapportering. Detta skall vara användarvänligt och framför allt webbaserat. Det skall hantera obegränsat antal användare och rapportera tid för flera projekt i olika projektkategorier. All information skall lagras i en databas. I uppgiften ingår det att utveckla och implementera datamodellen för systemet samt ta fram ett användarvänligt gränssnitt för klienten på en valfri plattform. 1.2 Andra Produkter För att få en jämförelse mellan vilka produkter som redan finns på marknaden gjordes en undersökning. Med Internet kommer nya möjligheter att kommunicera och interagera. Detta skapar utrymme för en rad nya produktidéer. Utifrån detta resonemang har ArtologikTM skapats och utvecklats. Just enkelheten är Artologiks motto. Artologik TM är en produktserie med webbaserade program som är skapade för dess enkla hanterbarhet. Med Artologik TM kan en webbansvarig skapa interaktivitet på webben utan kunskap om tekniken. Artologiks webbplats är plattformen för distributionen av programmen. Artologik TM lägger ner stor vikt vid att skapa enkelhet för användaren utan att för den skull vara utan avancerade funktioner. Produkterna är från början tekniskt förberedda för flera olika språk genom att all information ligger i databasen. Deras mål är att etablera sig på den globala marknaden. 1.2.1 Beskrivning av Artologik TM:s produkt TIME Citat från Artologiks hemsida: Har du svårt att få dina medarbetare att registrera sin tid? Får du sitta i efterhand och försöka komma ihåg vad du gjort? Anledningen är troligen att du använder dig av ett klumpigt och svårhanterligt system. Det finns ett enkelt sätt registrera tid. TIME har inga krångliga funktioner och är mycket lätt att lära sig. Med nya TIME 2.0 blir tidrapporteringen en rutin som alla snabbt kan lära sig att använda och uppskatta.

7(23) Bland nyheterna: Du kan ta ut rapporter hur du vill med nya rapportgeneratorn. Uppgifter för lön kan exporteras direkt till ditt löneprogram. Tid registreras direkt på webben, nu även med tidkoder för övertid, sjukfrånvaro etc. De som rapporterar i systemet kan alltså vara geografiskt skilda både i tid och rum. Med TIME får du en snabb överblick över hur mycket tid som lagts ner i aktuella projekt. Med TIME kan du som projektledare enkelt se vem som jobbat med vad och när. Uppgifterna kan bilda underlag till offerter, fakturor och löneberäkningar mm. (Slut citat). 1.2.2 Hur används TIME av företag och organisationer TIME kan användas på olika sätt av organisationer och företag. Programmet passar även små företag, med några anställda, men även stora företag med tusentals anställda. Programmet kan användas för rapportering på löpande projekt, eller på fördefinierade projekt. 1.2.3 Olika roller i TIME Det finns tre olika roller i TIME. Rollerna är projektdeltagare, projektledare och administratör. Projektdeltagaren: Håller koll på egna arbetsuppgifter Rapporterar tid Tar fram månadsrapport Söker projekt, kunder och projektdeltagare Registrerar semester och frånvaro Projektledaren: Lägger upp projekt och administrerar aktiviteter Följer projektdeltagarnas tidrapportering Förändrar budgeten för projekten Följer rapporterna Tar fram löneunderlag, registreringsrapport samt faktureringsunderlag Administratör: Hantera alla uppgifter om användare, kunder, leverantörer, projekt, varor/tjänster, aktiviteter samt den egna organisationen. Lägger in nya användare, kunder och leverantörer Lägger in nya projekt. Ser förbrukad tid för de olika projekten Lägger in nya Varor/tjänster för ett projekt. Lägger in uppgifter om den egna organisationen Lägger in kontonummer och resultatenheter för bokföringen.

8(23) 1.2.4 Fördelar med TIME Organisationen kan delas in i resultatenheter och användargrupper. Underlag till fakturering och beräkning av offerter kan skapas. Användaren kan lägga in en egen logo på fakturan. Löneberäkningar kan skapas med export direkt till användarens löneprogram. Flerspråkighet. Språket kan bytas utan att informationen behöver ändras. Användaren kan arbeta med samma dokument i olika språk. Ovanstående flerspråkighet ser vi som en stor fördel. 1.2.5 Nackdelar med TIME Det står ingenstans i dokumentation av TIME att den klarar offline rapportering vilket vi ser som en nackdel. 1.3 Vår Webbapplikaton för tidrapportering 1.3.1 Uppbyggnad Produkten består huvudsakligen av tre olika delar: Tidrapportering Rapporter Administration 1.3.2 Tidrapportering Rapportera tid: Användaren väljer kategori, eventuellt projekt och specifikation samt skriver in antalet timmar. Rapportera period: Användaren väljer kategori, eventuellt projekt och specifikation samt väljer mellan vilka datum perioden varar. Tid rapporteras endast in på vardagar, ej lördagar och söndagar samt dagar som registrerats som ledighetsdagar i systemet. Stämpla in / stämpla ut: Användaren väljer kategori, eventuellt projekt och specifikation samt stämplar in. Ett speciellt lunchavdrag kan definieras och detta dras av automatiskt om användaren är instämplad mellan kl.12 och 13. Om användaren ej stämplat ut innan midnatt antar systemet att man glömt att stämpla ut och registrerar 8 timmar i systemet.

9(23) 1.3.3 Rapporter Det finns möjlighet att se tre rapporter för inrapporterad tid: månadsrapport, årsrapport samt grupprapport. I månadsrapporten räknas summan ihop för de kategorier - projekt -specifikationer som gjorts den månaden. Det finns tre olika detaljnivåer på månadsrapporten: Kategorier Kategorier - projekt Kategorier - projekt - specifikation I grupprapporten, som endast superuser och admin kan läsa, summeras tiderna som personerna i olika grupper lagt ner på olika projekt för respektive grupp. 1.3.4 Administration I vårt system finns tre olika befogenheter i likhet med Artologiks TIME, user, superuser och admin. Dock skiljer sig befogenheterna mellan systemen något. 1.3.4.1 Befogenheter User: Rapportera in tid och modifiera/ta bort dessa ur systemet. Vidare kan man se månads- och årsrapport samt modifiera egna projekt/specifikationer. Superuser: Som user men kan dessutom modifiera grupper samt se grupprapporter. Admin: Som superuser men kan dessutom modifiera kategorier, användare, behörighet mm 2 Relevant Teori 2.1 Databas

10(23) 2.1.1 Förklaring En databas kan sammanfattas som en förvaringsplats för ordnat samlat data av olika slag. Dessa data hör ihop på något sätt. Användaren ska enkelt och snabbt kunna plocka fram och även lägga till nytt data. En databas är bestående, dvs. data försvinner inte när programmet avslutas och strömmen slås av. Användargränssnittet för tidrapporteringen är frikopplad från den centrala databasen, d.v.s. klient server arkitektur. Servern är huvuddelen av systemet och det är den som hanterar databasen. Klienten är den del som användaren använder sig av för att kommunicera med servern. 2.1.2 Fördelar med att använda en databas Snabbhet Det går betydligt snabbare att söka i en databas än i en vanlig fil. Enkelhet Det är enklare att lägga till, ta bort och manipulera data i en databas än i en vanlig fil. En databas hanterar också automatiskt den problematik som uppstår när flera användare vill komma åt samma data samtidigt. Flexibilitet En databas är mycket mer flexibel än en fil. Det går att lagra både binär- och textdata i en och samma databas. Skalbarhet Det är enkelt att bygga ut systemet. Vid behov av att databasen skall klara av hög belastning kan denna läggas ut på flera servrar. Distribuerbarhet Eftersom de flesta databashanteringssystem är utvecklade enligt klient/server-arkitektur finns möjlighet att hantera databaser från vilken värddator som helst. Säkerhet Det är enklare att skydda lagrad data i en databas i jämförelse med en fil. En databas är skyddad med ett användarnamn och lösenord. Innehållet kan även krypteras med olika metoder för att uppnå hög säkerhet. Databasen kan också ligga på en speciellt skyddad server. De flesta större moderna webbsidor är idag drivna av databaser. De lagrar innehållet till webbsidan i en databas. Det gör dem enklare att utveckla och underhålla. 2.1.3 Databashanteringssystem, DBMS Mellan databasen och användaren finns ett mjukvarulager som kallas databashanterare eller databashanteringssystem (DBMS). Detta hanterar all begäran om access till databasen. En generell funktion som den tillhandahåller är att skydda användarna från hårdvarunivån. Det är också vanligt att en databashanterare innehåller verktyg för att bygga applikationer. En applikation är kombinationen av formulär, rapporter och frågor som ger gränssnittet mot användaren. Fördelen med att använda databashanterare är att det är kraftfullt då komplicerade uppgifter kan utföras på ett enkelt och flexibelt sätt. Några kända exempel på databashanterare är Oracle, Microsoft Access,

11(23) MySQL, Microsoft SQL Server. Några vanliga typer av databashanteringssystem är: relationsdatabas, objektorienterad databas och objektrelationsdatabas. 2.1.4 Relationsdatabas En relationsdatabas lagrar data i tabeller med namngivna kolumner. Data lagras inte på samma sätt som de kommer att användas. De sammanställs och visas på olika sätt. Med hjälp av namnen på kolumnerna går det att skapa relationer mellan olika tabeller. Relationerna används till att hitta kopplad information som lagrats mellan dessa. En DBMS som hanterar relationsdatabaser får tillägget R för relational och blir alltså RDBMS. Relationsdatabaser har utvecklats sen många år tillbaka och har fått en stor spridning. Idag är därför relationsdatabaser helt dominerande. Det finns tre olika typer av relationer mellan tabeller 1:1 relation ( en till en ) 1:n relation ( en till många ) n:n relation ( många till många ) 2.1.4.1 Fördelar med relationsdatabas Snabbt och enkelt söka upp och ställa samman information som lagras i separata tabeller. 2.1.4.2 Primärnyckelfält För att kunna sammanställa information som lagras i flera separata tabeller måste tabellerna innehålla ett fält eller en uppsättning av fält som unikt identifierar de enskilda raderna eller posterna i tabellen. Det är ofta ett unikt ID-nummer. I databasterminologin kallas denna information för tabellens primärnyckel. Tre viktiga saker att tänka på vid skapande av primärnyckelfält: Det får inte förekomma duplicerade värden i ett primärnyckelfält. Av denna anledning väljs förslagsvis inte en persons efternamn. Primärnycklarna används vid sökande i databasen. Detta bör då inte vara för långt. Primärnyckelns storlek påverkar också söktiden i databasen. Ju mindre storlek som används för fältvärdena desto snabbare utförs operationerna Om det av någon anledning inte går att hitta en unik identifierare för tabellen, kan ett fält som numrerar posterna i löpande ordning användas.

12(23) 2.1.5 Klient/server arkitektur HTTP Data bas Klient (webbläsare) Webbserver (databas) 2.2 Utvecklingsmiljö 2.2.1 Plattform Klienten är programmet som frågar servern om något, t.ex. skicka en webbsida. Det är alltid den som tar initiativ för överföringen som kallas klient. Servern är den del som utför det klienten begär. Det spelar ingen roll åt vilket håll data skickas. Klient/server- metoden används endast på applikationsskiktet. HTTP är en förkortning för Hypertext Transfer Protocol. Det protokollet används på Internet för att skicka hypertext, d.v.s. webbsidor. HTTP är protokollet som hanterar datat som skickas mellan en webbklient och en webbserver. Vanligen brukar begreppet plattform vara synonymt med operativsystem. Men ibland inkluderar begreppet också de program som körs i operativsystemet och vilken hårdvara mjukvaran körs på. När vi i denna rapport skriver om plattform menas operativsystem och webbserver tillsammans. Denna definition görs eftersom det språk som använts mest i detta arbete, d.v.s. PHP (se 2.2.4), är hårt kopplat till en webbserver. Det är så att PHP körs som en modul till webbservern och är då en del av webbservern, istället för ett fristående program. De personer som har utvecklat PHP har försökt att göra kopplingen till operativsystemet så löst som möjligt. Det har varit en bidragande faktor till att PHP i princip går att köra på vilket operativsystem som helst. 2.2.2 LAMP-plattformen LAMP-plattformen använder sig av webbservern Apache och är vanligaste plattformen att köra PHP på. I detta arbete användes Red Hat Linux som serverplattform. Det är en förkortning för Linux, Apache, MySQL, PHP. Dessa mjukvaror tillsammans har bildat en webbplattform som blir allt mer använd.

13(23) Apache är världens mest använda webbserver och finns till de flesta operativsystemen. Samma utvecklare har även konstruerat programmeringsspråket PHP som också funkar bäst under Apache och Linux. Främst körs Apache i Linux/Unix men det finns distributioner för Windows. 2.2.3 PHP PHP är ett mycket bra programmeringsspråk för att hantera databaser. Det är ett relativt enkelt, men ändå kraftfullt språk. Syntaxen har stora likheter med språket C. Det krävs att en webbserver är installerad för att koden ska kunna tolkas. Servern gör om det till HTML kod, som den egna webbläsaren förstår. Med hjälp av PHP sker kommunikationen med enkla funktioner mot ett stort antal databaser. Det är det språket som har det största stödet för databaser. Dessutom har det stöd för ODBC, vilket ett flertal databaser använder idag. Det har också inbyggt stöd för databasen MySQL, och just kombinationen mellan dessa är både lättanvänd och kraftfull. Det har uppmärksammats i detta arbete. Ända sedan PHP släpptes på marknaden har den distribuerats som öppen källkod. Med det menas att vem som helst får ladda ner koden från Internet, använda och modifiera den och sprida den vidare utan att det kostar något. Mycket tack vare det så jobbar en del programmerare ideellt med att utveckla den öppna källkoden. Med den hjälpen kommer det ständigt nya uppdateringar och buggfixar. 2.2.4 MySQL MySQL är ett relationsdatabashanteringssystem. Det är väldigt snabbt, pålitligt och lätt att använda, och kan användas tillsammans med nästan alla programmeringsspråk. För att komma åt data i databaserna använder sig MySQL av SQL (Structured Query Language) som är det vanligaste standardiserade språket för detta ändamål. En stor nackdel med MySQL är att det i sin nuvarande version saknar många viktiga funktioner som triggers, vyer, transaktionshantering och sub-selects. 2.3 Cookie I detta arbete har det använts en hel del cookies för en del formulär. För den ovane vid detta begrepp kommer här en liten introduktion. 2.3.2 Introduktion till cookies. Cookies är en teknik för att på klientens dator spara en del information, så att datorn minns denna nästa gång en användare kommer till samma sida. Tillämpningarna kan vara många, men generellt sett så används en cookie för mellanlagring av data, för att kunna flytta över information från en sida till en annan.

14(23) 2.3.2 Session cookie Det är en cookie som bara används under ett besök på en webbplats. Om den innehåller data från inloggningssidan på en lösenordsskyddad webbplats, kommer användaren kunna surfa på sidorna utan att behöva mata in namn och lösenord på nytt. 2.3.3 Var finns en cookie? En cookie kan vara helt klientbaserad. Den sparas och hanteras helt av script på webbsidorna, som körs i webbläsaren. Ingen information för hanteringen behöver då skickas över nätet. Cookien sparas på klientdatorns hårddisk, så att den kan hämtas, nästa gång den behövs. Från början var det tänkt att cookies endast skulle hanteras på detta sätt, då fördelen är att man slipper skicka något över nätet. Detta kan dels gå snabbare och i vissa fall även vara säkrare. Många gånger är dock cookien serverbaserad. På klientdatorn har det då sparats ett id-nummer, som är en referens till en databas på serverdatorn. Då cookien ska hämtas används id-numret för att hämta info ur databasen. Nackdelen med detta är att det blir mer kommunikation över nätet och att användaren kan känna sig utlämnad, då information om denne sparas på en annan server någonstans i världen. Fördelen, för den som skapat webbsidan, är då det motsatta, d.v.s. att man kan samla information om användaren. Det kan vara att användaren fyller i formulär på olika sidor. Detta samlas ihop i en cookie, som sedan hämtas av ett serverbaserat program, istället för att formulärets innehåll skickas till programmet. 2.3.4 Var sparas en cookie? En cookie sparas i en s.k. cookiefil som ligger tillsammans med programinställningarna för webbläsaren. Exakt hur det ser ut, beror på vilken webbläsare det är och i vilket operativsystem den körs. Varje cookie får ett upphörandedatum när den skapas. I annat fall skulle snabbt cookiefilen bli alltför stor. Man bör inte sätta detta datum längre än vad som kan tänkas vara rimligt, vilket kan bero på hur ofta en användare kan tänkas besöka sidan med cookien och hur pass intressant det är att spara info från förra besöket. En del cookies används endast tillfälligt under en session (t.ex. för mellanlagring mellan två sidor) och de upphör så fort webbläsaren avslutas. Då går webbläsaren igenom hela cookiefilen och kontrollerar upphörandedatum, för att se vilka cookies som ska finnas kvar och vilka som ska rensas ut. 2.3.5 Vad innehåller en cookie? En cookie kan endast utnyttjas av den sida eller domän som skapat den. Därför finns sidans domän (domain) med i cookiefilen. Det går också att begränsa den, så att den endast kan utnyttjas av en bestämd katalog eller sida i domänen. Detta görs genom att ange en sökväg (path), som är tom om ingen begränsning finns. Det kan finnas flera cookies som hör till samma sida eller domän, så varje cookie ges ett namn (name). Förutom detta finns också cookiens värde (value) och upphörandedatum (expire date) givet i GMT (Greenwich-tid). Det finns också möjlighet att ange att cookien endast får användas under förhållanden som webbläsaren anser vara säkra (secure). Exempel på cookies: Domain Path Name Value Expire Date Secure www.idt.mdh.se /media/ Kurs kod,termin Wed 8-Aug-2003 12:00:00 GMT FALSE.mdh.se / User Kalle läser Fri 6-Sep-2002 17:45:00 GMT FALSE

15(23) Den första kan endast användas av sidor i katalogen multimedia på domänen www.idt.mdh.se. Den andra cookien kan användas av alla sidor som ingår i domäner som slutar på.mdh.se 3 Problembeskrivning Examensarbetet gick ut på att ta fram ett webbaserat tidrapporteringssystem som gör det möjligt för användaren oavsett om man är på arbetsplatsen, tjänsteresan eller arbetar hemifrån, att rapportera tid för olika ändamål. Vidare ska systemet hantera deltidsarbete, frånvaro, sjukledighet, semester samt generera månads- och årsrapporter. 3.1 Avgränsning Eftersom två personer utförde examensarbetet skulle två olika användargränssnitt implementeras. Att systemet skulle hantera inrapporteringar offline ansågs vara en viktig del i systemet. 3.1.2 Tidsplanering Med våra handläggare lade vi upp en tidsplanering, (se bilaga A) för de tio veckorna. Den ansågs rimlig vid den tidpunkten. Men närmare slutet på arbetet så ansågs att optimismen gällande tiden för hela projektet var lite i överkant. Enligt tidsplaneringen så skulle buggfixning och rapportskrivande vara de två sista veckorna. Dock visade det sig att det tog tid att få allt att fungera tillfredsställande. Det kan medges att det blev stressigt mot slutet. 3.1.3 Specifikation 3.1.3.1 Tidrapportering Tjänstgöringsgrad ska finnas lagrad för varje dag som timmar och minuter. På sidan där man skriver in den tid man jobbat så ska även resten av dagens inmatade tider stå. Bredvid varje tidspost ska det finnas en knapp för att ta bort eller modifiera en inrapportering. Olika sätt att rapportera tid: Skriva in antalet jobbade timmar. Stämpelklocka. Det ska finnas möjlighet till automatiskt avdrag för lunch. Tid för lunch ska kunna specificeras. Om användaren inte stämplat ut vid midnatt så ska värdet 8 timmar läggas in i databasen. Om en instämpling sträcker sig av lunch så ska tiden för lunch, som ska kunna specificeras dagligen, automatiskt dras bort när användaren stämplar ut. Användaren ska även meddelas om avdraget. Skriva in ett datum intervall (Ex. semester). Ex. 2002-06-18-2002-06-28. Tiden som rapporteras varje dag ska vara samma som tjänstgöringsgraden. Tid rapporteras inte in lördag/söndag eller på dagar som finns i listan över ledighetsdagar. 3.1.3.2 Användarklasser Tre klasser: User: Får administrera inrapporerad, projekt och specifikationer

16(23) Superuser: Som user men får dessutom administrera grupper samt se grupprapporter. Admin: Som superuser men får dessutom administrera kategorier och användare. 3.1.3.3 Användarinställningar Lägg till/modifiera/ ta bort projektnamn. Lägg till/modifiera/ ta bort specifikation. Om ett projekt tas bort måste även dess specifikationer tas bort. Om ett projektnamn eller en specifikation tas bort så kommer det endast försvinna i projekt/specifikationstabell.dock ska det finnas möjlighet för en administratör att gå in och rensa övrig data för projektet ur databasen. 3.1.3.4 Tidrapporter Vanliga användare ska kunna få upp två typer av rapporter: månadsrapport och årsrapport. Detaljnivån ska kunna bestämmas av användaren: Visa bara kategorier, visa kategorier och projekt, visa kategorier, projekt och specifikationer. Superuser ska förutom sina egna rapporter också ha möjlighet att se grupprapporter. På dessa ska även summan av användarnas tider räknas ihop. 3.1.3.5 Systemkonfiguration (endast admin) Defaultskapade kategorier. Dessa kategorier är globala för alla användare. Ledighetsdagar ska sparas i en lista. Dessa skall gå att ändra. Dessa inställningar kommer vara globala dvs påverka samtliga användare i systemet. 3.1.3.6 Offline tidrapportering Systemet ska även kunna användas när användaren ej är uppkopplad mot internet. Detta medför att en hel del data måste lagras lokalt på användarens hårddisk i form av cookies. Den information som måste sparas är kategorinamn, projektnamn och specifikationer. Varje inrapportering som sker i offlineläge lagras lokalt. När användaren sedan går online läggs dessa automatiskt in i systemet. 3.1.3.7 Användarkonfiguration (endast admin) Lägga till/modifiera/ta bort användare (namn, e-mail, lösenord) Tilldela superuser/admin rättigheter (endast admin) Lägga till/modifiera/ta bort grupp.

17(23) Lägga till användare till gruppen. 4 Problemanalys Nedan beskrivs en del problem som uppstått under arbetets gång. Offline: Hur sker rapporteringen när man inte är uppkopplad på Internet? Hur sker kontrollen om användaren är online eller offline? Hur sparas data på användarens dator? Hur kommer man åt data som sparats? Hur många rapporteringer kan sparas innan uppkoppling sker mot Internet igen? Hur överföres data mellan klientens JavaScript-variabler till serverns PHP-variabler? 5 Modell/Metod 6 Lösning I arkivmenyn för webbläsaren kryssas valet i för att arbeta offline. Genom att använda webbsidan för tidrapporteringen kan formuläret fyllas i precis som vid onlinerapportering. I formuläret finns ett script som känner av om det finns någon direktuppkoppling till internet. Om inget sådant finns sker inrapporteringen med ett JavaScript där all data tas om hand. För att spara data som skrivs in i formuläret används en s.k. cookie. All information som rapporteras in, skrivs också till cookien. Det är lätt att hämta och hantera information från denna. Det görs med hjälp av JavaScript. Hur många rapporteringer som kan ske, bestäms av hur många cookies som kan sparas: per webbsida och totalt på hårddisken. Av informationen som finns på Internet så kan 20 cookies sparas per webbsida, max antal är 300 på hårddisken och varje cookie kan max innehålla 4 kb data. Med den informationen sattes en gräns på 200 rapporteringar offline. Problemet med variablerna är att PHP-koden körs först på servern, sedan skickas sidan till den egna webbläsaren, och det är först i webbläsaren som JavaScriptet körs. Vid offlinerapportering finns ett JavaScript som hanterar all data som skrivits in. JavaScriptet skriver all data till en cookie. I cookien lagras all data som en enda hel sträng med ett mellanslag mellan varje ord. Innan ny data skrivs in finns en koll om det redan finns inrapporterat data. I så fall skrivs det nya datat in tillsammans med det gamla i cookien. All data som skrivits in finns i samma cookie med ett speciellt namn och ett s.k. upphörandedatum (se begrepp 4.1.4). Blir det för mycket data i cookien förstörs den och all data går förlorad.

18(23) I offlineformuläret får det inte förekomma någon PHP-kod alls. PHP scriptet får själv läsa från cookien vid synkronisering från offline, in till sina variabler. Det enda PHP behöver veta, är namnet på cookien. 7 Resultat 7.1 Analys av resultat Målet med arbetet har uppnåtts. Den färdiga webbapplikationen för tidrapportering är verkställd och kravspecifikationen har följts. Efter hand har en del ändringar gjorts. Användargränssnittet har jobbats fram under arbetets gång i samtal med kund. Gränssnittet är gjort så lätthanterligt som möjligt, utan att för den skull vara utan avancerade funktioner. 7.2 Design av databas Som design var det modelleringen av databasen som tog tid. En bra modellering är själva grunden för att det ska bli en stabil och säker webbapplikation. Så på den lades det ned ett antal timmar på. Arbetets design delades in i fem steg. Steg 1: Bestämma syftet för databasen Syftet talar om vilken information som eftersöks från databasen. Utifrån detta bestämdes vilka ämnen som det behövdes lagras data om (som blev databasens tabeller), och vilka fakta som ska lagras om respektive ämne (fält i databasen). Samtal fördes med kunden om databasens användningsområde och vilken information de vill få från denna. Steg 2: Bestämma tabeller När syftet var uppnått för databasen kunde informationen delas upp i separata ämnen. Dessa kom att bli egna tabeller i databasen. Att bestämma dessa var det svåraste i utformningsprocessen. Det beror på att resultaten som förväntas få ut från databasen, inte nödvändigtvis ger någon ledtråd om strukturen på tabellerna som ska producera dem. Steg 3: Bestämma fält Här bestämdes vilken information som respektive tabell skulle innehålla. De olika kategorierna kallas fält och visas som kolumner i tabellen. Några grundregler för bestämmande av fält. Se till att fälten i tabellen direkt relaterar till tabellens ämnesområde. Ett fält som beskriver ämnet för en annan tabell hör hemma i den andra tabellen. Om samma information upprepas i olika tabeller betyder det att en del tabeller innehåller onödiga fält. Ta inte med härledda eller beräknade data För det mesta vill man inte lagra resultat av beräkningar i tabeller. Detta kan göras när ett resultat ska visas. Ta med all information som behövs Det är lätt att försumma viktig information. I utformningsprocessen som gjordes i början

19(23) information samlades in kontrollerades att de verkligen fanns med i de aktuella tabellerna. Steg 4: Bestämma relationer I det här skedet avgjordes hur data i en tabell ska relatera till en annan tabell. Ska det läggas till fält i tabellerna eller, när relationerna fastställs, ska det skapas nya tabeller. Steg 5: Förfina databasens design Kontroller gjordes för att eventuellt finna fel i utformningen. Tabellerna fylldes med exempeldata för att se om resultaten var det önskade. Justeringar av designen gjordes efter behov. Det är lätt att ändra databasens design när den är skapad, men det är svårare att ändra i tabeller sedan de fyllts med data och skapat formulär och rapporter. Av denna anledning var det extra viktigt att det finns en bra design innan arbetet hunnit alltför långt. 7.2.1 Datamodellering (Se bilaga B). 7.3 Implementation När väl modelleringen var färdig, så var det dags att sätta sig in i själva programmerandet. Eftersom ingen utav oss hade programmerat vare sig Javascript eller PHP förut, så tog det lite tid att sätta sig in i det. Men med böckers hjälp, och Internet så var inte det heller så svårt. Eftersom PHP liknar programspråket C, så var det inte så svårt att efter ett tag börja arbetet av webbapplikationen. 7.4 Testning Systemet har testats flertalet gånger. Administreringen av kategorier, projekt, specifikationer, användare och grupper använder sig av samma princip och dessa fungerar som de ska. Provdata har använt för att kontrollera att systemet inte sluta fungera vid felaktig indata. Rapporterna har testats genom att fylla databasen med testdata och sen kontrollera alla beräkningar och utskrifter. Inrapportering av data har testats på flera sätt. Dels att kontrollerna för felaktigt inmatad data fungerar, dels att ändring av inmatad tid fungerar och att borttagning av inmatad tid fungerar. 7.5 Framtida arbete Förutom att förfina hela applikationen med färger som tilltalar användaren så togs det upp vid examinationen att offlinerapporteringen kunde förbättras genom att ha samma funktioner som online rapportering. Detta framgick inte av kravspecifikationen. Funktioner kan läggas till för att ändra eller ta bort inskrivet data i offlineformuläret. Nu kan bara data ändras eller tas bort efter uppkoppling sker igen mot databasen.

20(23) 8 Summering och slutsatser Examensarbetets syfte var att få fram ett färdigt webbaserat system för tidrapportering. Det hanterar obegränsat antal användare och användaren kan rapportera tid för flera projekt i olika projektkategorier. Tre olika nivåer på användare finns. Vanlig användare, user, rapporterar tid för olika kategorier. Tre val finns för vilken rapportering som känns lämplig. Vanlig tidrapportering där timmarna skrivs in, rapportera för en hel period där perioden mellan två datum gäller eller stämpla in/stämpla ut, som en vanlig stämpelklocka. Rapporter för varje månads inrapporteringar samt för hela året kan tas fram. Superuser, nivån över user, kan dessutom skapa olika grupper av användare, där även en rapport för respektive grupp och gruppmedlem tas fram för de olika projekt de deltagit i. Admin, den högsta nivån, kan dessutom administrera användare i databasen. Lägga till och ta bort användare samt tilldela lösenord till alla olika användare. All information sköts genom en databas där all data är lagrad. Användarna loggar in med användarnamn och lösenord, och kan sedan använda systemet till fullo. Det finns möjlighet att ändra eller ta bort rapporteringar innan dessa läggs in i databasen. Systemet kan även användas när användaren ej har tillgång till internet uppkoppling. Därför lagras en del data lokalt på användarens hårddisk. Det sker med hjälp utav cookies. När sen uppkoppling sker, så synkroniseras datat från användaren när tidrapportering skett offline. Datat läggs därefter direkt in i databasen.