Hovedprosjekt våren 2009

Transkript

1 Hovedprosjekt våren 2009 Prosjektrapport Timereg Gruppe 18 Mads E. Eide og Petter B. Falch Page 1 of 42

2 TILGJENGELIGHET Student.iu.hio.no/hovedprosjekt er/2009/data/18/ PROSJEKT NR. 18 Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Timereg DATO ANTALL SIDER / BILAG 42 PROSJEKTDELTAKERE Mads Erling Eide og Petter Bjerke Falch INTERN VEILEDER Kjetil Grønning OPPDRAGSGIVER KONE Norge AS KONTAKTPERSON Vidar Nordbø SAMMENDRAG Dette er prosjektrapporten til vårt hovedprosjekt ved høyskolen i Oslo Denne rapporten består av to rapporter, en prosessrapport og en produktrapport. I tilegg består den av diverse vedlegg, disse er kravspesifikasjon, forprosjektrapport, prosjektdagbok, prosjektskisse, fremdriftsplan og arbeidsplan. Det ferdige resultatet av prosjektet ligger på: student.kursreg.net testbruker kan logge inn med brukernavn: og passord: Prosjektsiden til prosjektet ligger på: Student.iu.hio.no/hovedprosjekter/2009/data/18/ 3 stikkord PDA, Timeregistrering og webutvikling Page 2 of 42

3 Innholdsfortegnelse Innholdsfortegnelse... 3 Prosessrapport Forord Innledning Fakta om KONE Bakgrunn for oppgaven Mål med prosjektet Rammebetingelser og begrensninger Minstekrav til funksjonalitet Andre krav Krav til design Tekniske krav Gruppen Planlegging og metode Planlegging av selve prosjektet Planlegging av databasen Egenopplæring Rutiner og arbeidsmetoder Roller og ansvar Forhold til oppdragsgiver Om utviklingsprosessen Prosjektets faser Startfasen Implementeringen Testingen Avslutningsfasen Page 3 of 42

4 7.0 Kravspesifikasjonen og dens rolle Endringer fra første versjon Avslutning Sluttord Oppsummering og konklusjon Hva kunne vært gjort annerledes? Systemets framtid Kildeliste Produktrapport Forord Systemkrav og Systemteknologi Systemkrav Dagens situasjon Teknologier Prosjekt- og timeregistreringssystemet Prosjektregistrering Timeregistrering Administrasjonssystem Vis timer og skriv til en.csv-fil Beskrivelse av databasen ansatt ansatt_has_prosjekt femabsolutter lonnsart lonnskategori members prosjekt Page 4 of 42

5 8.0 Kildehenvisninger Tabell og figurhenvisninger Tabellhenvisninger Figurhenvisninger Vedlegg 1: Vedlegg 2: Vedlegg 3: Vedlegg 4: Vedlegg 5: Vedlegg 6: Kravspesifikasjon Forprosjekt Prosjektdagbok Prosjektskisse arbeidsplan Fremdriftsplan Page 5 of 42

6 Prosessrapport 3.0 Forord Dette er prosessdokumentasjonen som beskriver hvordan vi jobbet med hovedprosjektet ved Høgskolen i Oslo våren Gruppen består av to perosner Mads Erling Eide og Petter Bjerke Falch. Vi har studert og arbeidet lenge sammen, og arbeider godt som gruppe. Kone hadde lagt ut prosjektet på skolen nettsider, og vi fikk tak i prosjektet kjapt. Vi syntes det virket interessant og var fornøyd med prosjektvalget. Tidligere ble timer registrert for hånd ved hjelp av en timeregistreringsbok, noe som var tungvint og lite effektiv. Da vi fikk muligheten til å gjøre noe med dette, tok vi denne. Det er noen som har hjulpet oss med dette prosjektet, og de vil vi takke. Kjetil Grønning, som var vår veileder gjennom prosjektet, og som hjalp oss i å komme i gang med prosjektet. Vidar Nordbø og Rune Skaiaa som vi hadde kontakt med hos KONE. De har vært til god hjelp med og gitt oss muligheten til å gjennomføre dette prosjektet. Ann-Mari Torvatn for heftet Dokumentasjonsstandard som vi har brukt masse under rapportskrivingen. Oslo, 26 mai 2009 Mads Erling Eide Petter Bjerke Falch Page 6 of 42

7 4.0 Innledning Her vil vi si litt om bakgrunnen for prosjektet og litt hvorfor vi valgte akkurat dette prosjektet. Vi skriver litt om bedriften, bakgrunn for oppgaven, bekskrivelse av gruppen og rammekravene til oppgaven. 4.1 Fakta om KONE KONE er et globalt konsern i sterk vekst med røtter i Finland. KONE er størst i Skandinavia, nest størst i Norge, og markedsleder på leveranse av nye heiser i Norge gjennom en årrekke. De har i dag ca. 250 ansatte hvorav ca. 180 har sitt arbeid ute i feltet. Hovedkontoret er på Kjelsås i Oslo, men har avdelinger over hele landet. KONE har et velfungerende samarbeid med skoler og utdanningsinstitusjoner lokalt og nasjonalt på ulike nivå. KONE har ansatte som arbeider i felten, på lageret, på verkstedet og på kontorer på Kjelsås. 4.2 Bakgrunn for oppgaven De ansatte i KONE som jobber i felten, er utrustet med en PDA hver. Denne hjelper de ansatte med diverse administrative oppgaver, som gjør hverdagen enklere for de ansatte. Det den ikke gjør er å kunne registrere 5 absolutter og timer som de ansatte bruker i felten. Dette gjøres på ark, og blir registrert av folk på kontoret som taster inn dette manuelt i et system. Oppgaven vi har tatt på oss går ut på å lage et timeforbuksregistreringssystem via et PDA og web grensesnitt. Det er over 100 ansatte i KONE, og det ønskes et system som hjelper de med registrering av timeforbruket sitt via den allerede utdelte PDA-telefonen HTC PANDA 6300 PDA ene skal kunne registrere tidsforbruk via et enkelt grensesnitt på PDA, løsningen skal gjøre ved hjelp av PHP eller lignende. Tidsforbruket skal registreres med antall timer, kategori, dato, og et tekstfelt. Det er et begrenset antall kategorier. Etter at dataen er tastet inn på PDA en skal den lastes over til en database som ligger på en nettserver KONE allerede har. Serveren kan benytte MySQL eller MS SQL. Databasen skal ha et grensesnitt for en administrator som nås via PC. Administratoren skal kunne laste ned registrert informasjon rutinemessig. 4.3 Mål med prosjektet Målet for dette prosjektet er å utvikle en løsning for KONE slik at de har mulighet for å foreta timeregistrering via PDA og web. I tillegg til å utvikle det nettbaserte systemet, vil vi utvikle databasen som skal ha kontakt med den webbaserte løsningen. Informasjon som skal lagres tilsvarer det arket man fyller ut i dag med informasjon om prosjetkt, ansatt, timer osv. KONE ser for seg at systemet skal utvikles i PHP og MySQL eller MS SQL, og det sannsynlige valget for oss ligger da på MySQL, da vi har brukt dette på skolen. Page 7 of 42

8 I tillegg til å registrere informasjon skal det være muligheter for en administrator å få tilgang til informasjon via en nettside. Vi i gruppen har liten kompetanse når det gjelder utvikling av nettsteder til PDA/mobil, så mye av tiden de første ukene vil bli brukt til å utvikle egne kunnskaper rundt dette. Et viktig mål for oss er å få ferdig selve produktet, men like så viktig er læringsmålene. Med læringsmålene mener vi det vi kommer til å lære i løpet av prosjeketet. Vi håper at når dette prosjektet er ferdig, sitter vi igjen med masse ny kunnskap. 4.4 Rammebetingelser og begrensninger Etter møter med oppdragsgiver og veileder, har gruppen diskutert seg fram til følgende rammebetingelser Minstekrav til funksjonalitet Systemet skulle kunne: Enkelt registrere all informasjon som trengs for en timeregistering. Registrere 5 absolutter. Kun med avkryssningsbokser. Ha mulighet til å printe ut lister med timeregistreringer Gi korte, informative feilmeldinger. Ikke tillate bruker å gjøre katastrofale feil. Ha to forskjellige type brukere, standard bruker og administrator Andre krav Andre krav til systemet: Kunne oppdateres og videreutvikles. Forhindre dobbeltregistrering i databasen Krav til design Krav til designet er at det skal være enkelt og lett forståelig. Man skal ikke behøve å noen større datakunnskaper. Det skal være enkle feilmeldinger og alt som kan forstyrre brukeren i å utføre oppgaven sin må tas vekk Tekniske krav Systemet skal utvikles til/med: Plattform: Apache/1.3.29, Unix PHP/4.3.4, MySQL 4.1. Programmeringsspråk: PHP og SQL Page 8 of 42

9 Utviklingsmiljø:WAMP, Apache, phpeditor, MySQL Workbench 5.0 Systemet skal: Kunne kjøres i de fire store nettleserne; Internett Explorer, Opera, Safari og Mozilla Firefox. Publiseres på web. 4.5 Gruppen Gruppen består av to personer, Mads Erling Eide og Petter Bjerke Falch. Gruppemedlemmene har arbeidet sammen før og samarbeidet har fungert meget tilfredsstillende. Gruppen er klar for hardt arbeid, og lære mange nye ting. 5.0 Planlegging og metode Her skal vi skrive om hvordan vi planla prosjektet og hva slags metode vi har brukt for å gjennomføre det. 5.1 Planlegging av selve prosjektet Prosjektet som skulle være våren 2009, startet allerede litt høsten Da skulle vi lage en statusrapport, danne gruppe og etter hvert skaffe oss et prosjekt. Vi så på skolens sider at det var lagt ut et prosjekt som omhandlet firmaet KONE. Vi sendte de en mail, og fikk raskt godkjenning til å ta dette prosjektet. 4. desember var prosjektvalget tatt. Selv om vi var tidlig ute med å skaffe oss prosjekt, var det ikke like enkelt å få avtalt noe møte med KONE, dette fordi at de ønsket å ha med noen personer på prosjektet som ikke var ledig før i starten av februar. Etter dette var det å sette i gang med framdrifts- og arbeidsplan. Dette utviklet vi kjapt, da vi hadde allerede mistet en del tid. Det var viktig for oss å sette gode tidsfrister og ha en god plan, noe vi føler at vi fikk til. Dette var også viktig da det ved siden av hovedprosjektet, også var fler småprosjekter i faget it-tjenester. Vi begynte samtidig på kravspesifikasjonen, da den var viktig for hvordan hele prosjektet ble seende ut. Denne ble utviklet sammen med arbeidsgiver og veileder. Selv om det ble laget et første utkast av kravspesifikasjonen tidlig, var vi klar over at denne kom til å bli endret etter som vi dannet oss et bilde av hele prosjektet. 5.2 Planlegging av databasen Planleggning av databasen var meget viktig for fortsettelsen av prosjektarbeidet. Dette er grunnpilaren i prosjektet, og blir det feil her, vil det følge oss på veien. Vi begynte med å tegne opp en ER-modell. Dette ut ifra kravspesifikasjonen vår. Vi tegnet opp de tabellene vi mente vi trengte og relasjonene mellom disse. Etter dette måtte vi sette inn gode navn på feltene i tabellene. En viktig del var også å sette på riktig datatyper, primær -og fremmednøkler. I utviklingen av programvare og databaser, er det viktig å drive aktiv iterajson. Det vil si at man hele Page 9 of 42

10 tiden går fram og tilbake slik at man får utviklet et godt system. Når det gjaldt databasen så begynte vi med et utkast, som vi utvilket videre i flere omganger. Og selvom vi følte vi begynte med et godt utgangspunkt føler vi at resultatet ble ganske annerledes. I starten hadde vi databasen liggende på en server som het frac.dk. Deretter fikk vi lagt den ut der den skulle liggende, nemlig på en server hos webhuset.no. 4.3 Planlegginsverktøy For å kunne gjennomføre en god planlegging er man ofte nødt til å bruke noen verktøy. Det finnes mange slike planleggingsverktøy med mange funksjoner, men vi holdt oss til MS project. Dette er en enkel applikasjon som vi brukte til å lage fremdrifts og arbeidsplan. I tilegg benyttet vi oss av MS word og MSN messenger. Word brukte vi til å skrive rapporter, og det meste annet, og messenger for kontakt i gruppen når det var mindre ting som skulle planlegges. 5.3 Egenopplæring Selv om vi går et datastudie, og har god opplæring innenfor mye, så finnes det så uendelig mye mer å lære innenfor data. Vi skulle ta fatt på php og mysql, og selv om vi har vært brukt dette før, var det tydeligvis mye vi ikke kunne. Som så mange ganger før, fant vi ut at den beste måten å lære seg dette på var å bare starte. Derfor satt vi oss ned og begynte å programmere. Fordi det var så mye nytt vi skulle lære oss så fant vi ut at vi skulle fordele litt arbeid og kunnskap. Det ble slik at den ene kosentrerte seg mest om mysql og databasen, mens den andre gikk løs på php og websidene. 5.4 Rutiner og arbeidsmetoder For å få en kontinuitet i arbeidet med et slikt stort prosjekt er det viktig å ha faste holdepunkter. Derfor avtalte vi tidlig i prosjektfasen faste arbeidsdager og holdepunkter, som skulle strukturere oss og holde oss litt i tøylene. Det gikk greit i starten, men etter hvert funket ikke dette helt. Måten vi da arbeidet på var å fordele arbeidet og jobbe hjemme, og deretter avtale å møtes når vi trengte å samkordinere oss. Da også begge arbeider ved siden av studiet, var vi nødt til å være fleksible i forhold til hverandre. 5.5 Roller og ansvar I starten av prosjekt fordelte vi noen få roller og ansvar. Mads ble leder, mens Petter fikk en sekretærrolle. Måten vi fordelte arbeidet på var å dele det opp i programmeringen av sidene, og arbeidet med databasen. Petter fikk ansvar for databasen, mens Mads tok ansvar for programmeringen. 5.6 Forhold til oppdragsgiver Vi startet med et møte hos KONE i februar der vi satt oss ned og fikk godt igjennom hele systemet, del for del. Etter dette har kontakten med KONE kun vært via epost og mobiltelefon. Selv om det ikke har vært mye kontakt, føler vi at det har vært nok, og vi har fått svar på det vi trenger.det har vært tilfeller det har tatt mye tid å få svar, men dette har hatt sine praktiske grunner. Blant annet at oppdragsiver har vært bortreist over lengre tid. Page 10 of 42

11 6.0 Om utviklingsprosessen 6.1 Prosjektets faser For å enklere forstå hvordan vi har arbeidet med prosjektet, har vi delt inn prosjektet i faser. Det er flere faser, og de forklares nærmere her Startfasen Det var tre viktig dokumenter som skulle levers i startfasen av prosjektet. Disse var statusrapport, som var en rapport på hvor langt man har kommet i valg av prosjekt. Deretter var det prosjektskissen, som var en foreløpig presisering av prosjektet, slik at man begynne å ramme inn hva man skal gjøre. Tilslutt, og viktigst var forprosjektet. Forprosjektet besto i å bestemme så nøyaktig og presist som mulig hva problemområdet i prosjektet besto av. Dette for å forstå bedre hvor stort prosjektet var, og om man i det hele tatt kan ta fatt på prosjektet. Tilslutt skulle det leveres en forprosjektrapport, sammen med en arbeids og fremdriftsplan. Prosjektet begynte i desember Vi besteme oss for å arbeide sammen, og valget av prosjekt tok vi ganske tidlig. Allerede i desember var valget tatt. Desverre så fikk vi ikke møtt KONE før i februar, da de ikke hadde mulighet til å møtes oss før, så vi kom i gang litt sent. Det vi gjorde etter å hatt møte med KONE var å utarbeide en kravspesifikasjon og begynne å arbeide utifra den. I starten var det også viktig å få samlet inn informsjon om det vi skulle gjøre. Det første vi ville finne ut av var KONE. Ingen av oss hadde hørt om firmaet før, så der for besøkte vi nettsidene dems for å finne ut mer om de. Deretter var det viktig å fastslå hvem som skulle bruke systemet, og dems kunnkskaper rundt databruk. Her fant vi ut at de ansatte som skulle utnytte seg av systemet hadde sprikende itkunnskaper. Noe som ville si at vi måtte være veldig flinke til å lage et enkelt og brukervennelig grensesnitt, uten noe ekstra og kompliserende faktorer. Før møtet med KONE hadde vi skrevet ned spørsmål og ting vi lurte på rundt systemet, slik at vi var godt forberedt når vi kom til møtet. Vi var fornøyd med det vi hadde fått ut av møtet, og klare til å jobbe med oppgaven Implementeringen Måten vi arbeidet på og programmerte på var at vi programmerte en og en del av systemet og testet dette etter hvert som det ble ferdig. Fordi at man vi ikke var drevne programmerere har vi også måtte lære oss masse gjennom å gjøre, noe som gjorde at programmeringen tok mye tid. Databasen var tidlig ferdig, men den har måtte endres underveis. Under selve programmeringen har vi stått fast mange ganger, og ofte er løsningen å se på koden en gang til. Det er ofte små feil, som tar lang tid å finne ut av. I tilegg har vi hatt problemer med datatyper i forhold websidene. En datatype har vært date. Denne datatypen har et bestemt format , som vi hadde problemer med å få endret. Men vi mener vi har klart å løse de fleste problemer på en god og tilfredsstillende måte. Page 11 of 42

12 6.1.3 Testingen Vi har hele tiden testet systemet med fikitve data. Dette er data som har blitt lagt inn fra egen hukommelse, og slettet igjen. Det vi deriomt ikke har fått tid til, da prosjektet ble mer tidkrevende enn vi har trodd var å gjennomføre en full brukertest hos KONE. Vi håper og tror at vi får gjort dette etter prosjektperioden Avslutningsfasen Avslutningsfasen har bestått i å fullføre systemet, og skrive dokumentasjonen. Å skrive slik dokumentasjon er ikke dagligdags for noen av oss, så det har vært mye fram og tilbake med tanke på formuleringer og måter å gjøre dokumentasjonen på. I tilegg har avslutningsfasen bydd på noen småproblemer når det gjelder kodingen. Det vi gjorde, som var lurt, var å skrive en smørbrødliste over ting som måtte tas tak i, og fordele ansvar ut ifra dette. Dette ble gjort, og vi fikk fikset alt smått og stort som trengtes før prosjektslutt. Dette gjorde faktisk at prosjektet ble ferdig to dager før tiden. 7.0 Kravspesifikasjonen og dens rolle Det viktigste dokumentet i et slikt prosjekt, er kravspesifikasjonen. Den er grunnlaget for alt som gjøres. Vi begynte tidlig med den, men vi fikk ikke satt den skikkelig før etter møtet med KONE i februar. Det som var så fint med kravspesifikasjonen var at vi fikk det vi skulle gjøre ned på ark. Vi var kanskje litt dårlig til å følge opp kravspesifikasjonen, men vi føler at sluttproduktet vårt samsvarer godt med de kravene kravspesifikasjonen inneholder. 7.1 Endringer fra første versjon Kravspesifikasjonen har blitt endret flere ganger, da vi har måtte kutte litt ned på hvor mye som skulle implementeres i systemtet. Men alikevel så er den ganske lik den første som ble laget, noe som betyr at vi lagde et godt første utkast. 8.0 Avslutning Her kommer noen avsluttende ord, og oppsummering på hvordan vi har opplevd å jobbe med et slikt stort prosjekt. Og tilslutt en konklusjon. 8.1 Sluttord Dette prosjektet har vært en stor utfordring, som vi følte vi ble kastet ut i. Men å bli kastet ut i noe, er ofte positivt. Det betyr at man er nødt til å lære masse nytt. Og det har vi gjort. Ikke minst å arbeide mot en bedrift er en viktig lærdom før man skal ut i arbeidslivet. Vi er selv fornøyd med å ha kommet i mål med prosjektet, selv om det til tider har vært hektisk. 8.2 Oppsummering og konklusjon I et slikt prosjekt så lærer man masse. Det er ofte slik at det ikke alltid er resultatet av prosjektet som er viktigst, men selv prosessen. Og det føler jeg også i dette prosjektet. Vi har lært utrolig mye når det gjelder å jobbe sammen, og jobbe sammen mot en bedrift. Vi har lært masse om å utnytte de ressursene man har til rådighet og ikke minst å fordele de. Vi har selvfølgelig også blitt mye bedre på Page 12 of 42

13 programmering av php og sql. Å ha et slikt prosjekt er en fantastisk måte å lære på, og vi har lært mye mer enn vi ville om vi hadde hatt dette som ren undervisning Hva kunne vært gjort annerledes? Et spørsmål man må stille seg etter å ha jobbet så lenge med et prosjekt, er hva kunne vi gjort annerledes? Dette er et viktig spørsmål som er meget viktig i en avslutningsprosess av et stort prosjekt. Vi har stilt oss dette spørsmålet og kommet fram til noen punkter vi mener kunne vært gjort annerledes. Bedre samarbeid med veileder er noe vi har savnet. Dette er vår feil, da vi ikke har tatt oss tid til dette. Veileder har sannsynligvis hatt kunnskap vi kunne hatt bruk for, og vi angrer litt på at vi ikke har fått utnyttet denne. Vi kunne nok også ha fordelt tiden bedre. Problemet vårt er at vi har kun vært to på prosjektet. I tilegg jobber begge mellom to og tre dager i uken, så tiden har vært litt knapp Systemets framtid Vi håper selvfølgelig KONE ønsker å ta i bruk systemet, men det er nok noen ting som bør testes bedre før de tar det i bruk. Men vi er på god vei og vi vil gjerne gjøre dette ferdig etter prosjektperioden, på fritiden, slik at KONE får et fullgodt system. Page 13 of 42

14 9.0 Kildeliste Ann-Mari Torvatn Dokumentasjonsstandard Page 14 of 42

15 3.0 Forord Produktrapport Dette dokumentet er en beskrivelse av systemet vi har laget i forbindelse med hovedprosjektet ved Høyskolen I Oslo for KONE Norge AS. Dette er produktdokumentasjonen som beskriver oppbygging og virkemåte av systemet timereg. Dokumentet er ment for de som skal videreutvilke, vedlikehold og bruke systemet. Dokumentet er skrevet så detaljert som mulig, for å vise hva vi har lagd. Prosjektet startet med at KONE trengte et verktøy for å registrere timene de ansatte brukte ute i felten.i tilegg skulle vi lage en liten applikasjon som registrer de fem absoluttene til KONE. Etter endt arbeidsdag så skal alle timer de ansatte bruker på arbeidet registreres. Disse timene er av forskjellig art, og de skal registreres med hver sin kode. Disse kodene er definert av KONE på forhånd. I registreringssystemet skal man også kunne vise timene som er brukt og skrive de ut til en fil som skal kunne importeres inn i excel. De fem absoluttene er absolutter som må være oppfylt for at en montør kan begynne på et heisprosjekt. I denne rapporten tar vi for oss programmets virkemåte, en detaljert gjennomgang av programmet og en gjennomgang av databasen. Tilslutt kommer kilder, figur og tabellliste. All kildekode kommer til å være lagt med på cden som følger med rapporten. For å teste ut systemet gå inn på student.kursreg.net og benytt deg av brukernavn og passord Systemkrav og Systemteknologi Oppgaven i seg selv bestod i å utvikle et system spesielt egnet for PDA webgrensesnitt, derfor var vi tidlig ute med å undersøke rammebetingelsene dette medfører. Webutvikling for mobile enheter er et ungt fag som er i kraftig vekst etter hvert som teknologien for disse enhetene har utviklet seg enormt på bare kort tid. Vi har begge erfaring med webutvikling og arbeid med sql og databaser fra studier, men vi var fortsatt nødt til å tilpasse dette for PDA grensesnitt. 4.1 Systemkrav Webutvikling spesielt rettet mot mobile enheter setter noen begrensninger når det gjelder grafikk og kompleksitet, sidene må kunne laste enkelt og se ryddig ut for brukeren. Page 15 of 42

16 Vi skulle få tilgang til server via Webhuset, disse tilbyr Mysql database, PHP og phpmyadmin med tilkobling via SSH. Vi bruker hovedsakelig HTML, og benytter PHP for oppkobling og håndtering av innhold i databasen. 4.2 Dagens situasjon Når KONEs servicemedarbeidere er ute på oppdrag har de med seg en blankett for å fylle ut diverse informasjon om oppdraget: Prosjekt registreres med nettverksnr Dato Lønnsart En kort tekst som beskriver oppdraget Antall timer Etter timene er registrert blir blankettene levert videre til lønningsansvarlige som har en stor jobb med å sortere ut og registrere data manuelt fra hver enkelt blankett. Hvert prosjekt er også registrert med et skjema om 5 absolutter. Disse absoluttene forteller om heissjakten er klargjort for servicearbeideren. Alle timer må registreres på en lønnsart som avgjør lønnsnivået, dette feltet inneholdt mange muligheter og koder. Vi måtte derfor strukturere feltet opp i deler, på lønnskontoret har de kun behov for å se kodene, mens for arbeiderne vil kodene ikke gi mye mening. Servicearbeiderne vil først få velge ut ifra en lønnskategori, deretter vil man få velge lønnsart ut i fra kategorien, alt i tekst. Det har lenge vært ønskelig å ta i bruk PDA for å digitalisere denne prosessen, og det er denne rollen vårt system er ment å fylle. Det vil erstatte dagens papirversjon av timeregistrering og effektivisere databehandlingen ved at det enkelt kan importeres til et Excel-dokument. Det vil også være mulig å lese av registrerte timer umiddelbart etter at registreringen er gjort, og det vil til en hver tid være mulig og sortere ut timer ut i fra ønsket tidsperiode og behandle tallene direkte i Excel-dokumentet. 4.3 Teknologier For å kunne lage systemet var vi nødt til å ta i bruk flere utviklingsverktøy og programmeringspråk. Fordi dette systemet skal brukes på web så var vi nødt til å bruke programmeringspråk som PHP PHP er et dynamisk, tolket og løst typet programmeringsspråk hovedsakelig brukt for å utvikle dynamiske nettsider. PHPs syntaks ligner C og Perl. Den vanligste implementasjonen av PHP er en fri Page 16 of 42

17 og åpen versjon skrevet i C og distribuert av The PHP Group via php.net og SourceForge. En annen fri og åpen implementasjon, som muliggjør kompilering av PHP-kode til maskinkode, er utviklet av Roadsend Inc.(wikipedia.no) HTML HyperText Markup Language (HTML, hypertekstmarkeringsspråk) er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. HTML benyttes til å strukturere informasjon angi noe tekst som overskrifter, avsnitt, lister og så videre og kan, i en viss grad, brukes til å beskrive utseende og semantikk i et dokument. HTMLs grammatiske struktur er HTML DTD som ble skapt ved å gjøre bruk av SGML syntaks, som er en internasjonal standard for tekstformatering (ISO 8879).(wikipedia.no) CSS Cascades tyle sheet (CSS) er et språk som benyttes for å definere utseende på filer skrevet i HTML. Da det i starten var uklart om PDA ene kunne lese CSS fra fil la vi all CSS inline. Sql Structured Query Language (SQL) er et språk som benyttes til å formulere og kjøre operasjoner mot relasjonsdatabaser. De fleste av dagens databasesystemer tilbyr SQL som kontrollgrensesnitt. Disse språkene er typiske språk for utvikling av slike systemer, og de tilfredstilte våre arbeidskrav. I utviklingen av systemet brukte vi følgende programmer, som forenkler programmeringen. Dreamweaver Dette brukte vi hovedsaklig i all webprogrammering. Altså både php, html og mysql. Dreamweaver er et kraftig verktøy samtidig som det er enkelt å bruke og favoritten vår når vi jobber med webutvikling. Mysql workbench 5.0 Vi trengte et program for å lage modellen til databasen. Her fant vi dette gratis programmet. Det fungerte bra og databasen ble slik vi ville ha den. 5. Prosjekt- og timeregistreringssystemet Systemet er hovedsakelig to deler som er bygd opp på en felles modul. Vi har prosjektdelen som blir brukt av servicemedarbeider i felten, også er det administrasjonssystem som blir brukt av lønningskontoret, begge via et web-grensesnitt. I tilegg ligger det en login-applikasjon. Når man logger inn i systemet vil man bli tildelt en meny ut i fra hvilken rettighet man er satt til. Dette er altså bare en peker som leder brukeren til riktig meny, ikke en sikkerhetsfunksjon!! Page 17 of 42

18 Skjema for 5 absolutter er bygd opp som en ekstern applikasjon, da det var ønskelig at det skulle være mulig å registrere timer på et prosjekt uten at 5 absolutter var registrert. 5.1 Prosjektregistrering Dette er selve kjernen i timeregistreringen, ingen timer vil kunne bli registrert på et prosjekt hvis ikke nettverksnummer ligger til grunn. Prosjektene knyttes til arbeidsnummeret som et skjult felt og gjør at det ikke er mulig å lagre prosjekt for en annen bruker. For å registrere nytt prosjekt logger brukeren seg på systemet og går til linken <registrer nytt prosjekt>. Som bilde 1.0 viser blir hvert prosjekt lagret med nettverksnummer, dato og lokasjon. Nettverksnummeret er 11 siffer og unikt for hver heis/prosjekt. Når brukeren registrerer ønsket prosjekt vil en kontrollstruktur sjekke om nettversnummeret inneholder riktig antall siffer. Deretter vil brukeren få skrevet registrert innhold til skjermen. Det vil kun være nødvendig å registrere et prosjekt en gang. 5.2 Timeregistrering Som nevnt i pkt 5.1 vil det ikke være mulig å registrere timer før selve prosjektet er lagret i databasen. Når prosjektet først er registrert en gang vil det dukke opp i opsjonene man har for valg av nettverksnummer i timeregistreringen. Timeregistrering er en prosess på totalt 3 steg: Figur 1: Prosjektreg 1. Valg av dato, nettverksnummer og lønnskategori vist i Figur 2: timereg 1 Figur 2.0 Dato: er forvalgt til dagens dato, men kan enkelt endres ved hjelp av en oversiktlig nedtrekksliste Nettverksnummer: er forvalgt siste anvendte nr, opsjonene her er basert på lagret informasjon fra prosjektregistrering. Om man ikke finner ønsket nettverksnr i nedtrekkslisten må man trykke på <NY> og gjennomføre pkt 5.1. Lønnskategori: er som nevnt pkt 4.2 en gruppering av lønnsarter for å gjøre det mer brukervennlig. 2. Valg av Lønnsart, Antall timer og fritekst (som vist i Figur 3.0) Lønnsart: er figurert som tekst og opsjonene her er avhengig av hva som blir valgt i steg 1 for Lønnskategori. Finner man ikke den lønnsarten man trenger har man valget for å gjøre endringer. Page 18 of 42

19 Antall timer: brukeren skriver inn antall timer i feltet Fri text: her kan det legges til en liten beskrivelse eller tileggsnote av arbeidet som er gjort. Figur 3: timereg 2 3. Siste steget for timeregistreringen er en oppsummering og bekreftelse på de valg som er gjort i pkt 1 og pkt 2. Dette er gjort som et sikkerhetstillegg for at informasjon blir riktig, og er siste mulighet for å gjøre endringer før man bekrefter og lagrer timer i databasen. Siste valget man har i menyen for servicearbeiderne er muligheten til å fjerne nettverksnummer fra nedtrekkslisten. Denne muligheten er lagt til for at ikke nedtrekkslisten skal bli enormt lang og uoversiktlig over tid. Man kan kun slette sine egne lagrede prosjekter. 6.0 Administrasjonssystem Det er laget noen funksjoner for administrator: Vis timer / Skrive timer til Excel Legge til ansatte med passord Slette ansatt Vise alle registrerte prosjekter 6.1 Vis timer og skriv til en.csv-fil Denne funksjonen er ment for å effektivisere arbeidet med å samle inn registrerte timer (Figur 4). Det vil først være en funksjon som velger ønsket tidsforløp på utskriften. Datoene er forvalgt dagens dato men kan enkelt navigeres via nedtrekkslisten. Deretter vil det bli skrevet ut en liste som inneholder: Arbeidsnummer Lønnsart (i kode) Dato Timer Så får man mulighet til å skrive listen til en.csv-fil (Comma separated values). Dette gjør at data enkelt kan importeres til Excel slik at den kan behandles som ønskelig i form av tabeller og analyse. Page 19 of 42 Figur 4: adminsystem

20 Page 20 of 42