Prosessrapport Tittel: Grefsenhjemmet - Et godt sted å være Prosjektnr: 22 Prosjektdeltagere: s104111,munazza Butt, 3AC s107911,mona Sebri, 3AA s122357,farzana Sarwar, 3 Dato 25.5.2007 Intern veileder Geir Skjevling Oppdragsgiver Grefsenhjemmet Kontaktperson Kari-Anne Sammendrag Dette dokumentet er prosessrapporten for hovedprosjektet. Prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Grefsenhjemmet i Oslo. Grefsen hjemmet har pr i dag ingen egen informasjonsside, men er generelt omtalt under Oslo kommunes samlede nettside. Av hensyn til dette ser sykehjemmet et behov for en mer detaljert og bedre beskrivelse av hjemmets gode tjenestetilbud og særpreg. Samtidig har vi vært med på å utvikle et system for ansatte som kan sette seg på ekstra vakter via internett. Systemet er utviklet i MySQL og PHP. Systemet har primært blitt utviklet på skolens egne PC er, for senere i prosjektperioden å bli flyttet over til serveren til oppdragsgiver. Testing av systemet har primært blitt utført på skolen. Vakt systemet gir ansatte som jobber på Grefsenhjemmet mulighet til å legge inn på ønsket vakt og endre på vakter via internett. Administrator kan registrere en ansatt, endre eller slette informasjon om ansatte. Registrere vakter for turnusperioder og deretter tildele vakter til ansatte og generere vaktlister.
Forord Denne prosessrapporten forteller om hvordan vår gruppe jobbet for å utvikle hovedprosjektet vårt ved Høgskolen i Oslo, avdeling ingeniør utdanning, datalinjen, vår semesteret 2006. Oppgaven gikk ut på å utvikle hjemmesider for Grefsenhjemmet og et registrering system for ekstra vakter. Munazza Butt, Mona Sebri og Farzana Sarwar står bak utvikling av dette prosjektet. En av gruppemedlemmene har jobbet tidligere på Grefsenhjemmet og tok kontakt med dem for å høre om de hadde behov for en ny webside. De var ganske positive til dette, kom tilbake med et raskt svar. Vi følte det var ikke en så stor utfordring for oss og spurte dem mer om hva de kunne trenge hjelp til. Under et møte ble vi fortalt om hvordan registrering av ekstra vakter foregår på Grefsenhjemmet. Alt skjer på papir. Så vi kom med et forslag til et system på internett, som kunne lette arbeidet deres. Det var de veldig begeistret for, og vi bestemte oss for å utvikle både en hjemmeside og registrerings system for ekstra vakter. Rapporten er beregnet for sensor, veileder, oppdragsgiver og andre som har interesse av å få innblikk i hvordan vi har utviklet dette systemet. Det kreves at man har generelt kunnskaper om MySQL, PHP, HTML og Java script for å forstå faglige ord og uttrykk i rapporten. Vi vill gjerne rette en stor takk til følgende personer som har hjulpet og veiledet oss gjennom dette prosjektet: Geir Skjevling, vår veileder, foreleser i web-prosjekt og nettverk og systemadministrasjon.. Stor takk for all veiledning du kom med ved spørsmål og for alle praktiske råd og løsninger. Demissie Aredo, foreleser i kurset systemutvikling og relasjonsdatabaser. Stor takk til deg for at vi fikk komme for hjelp til utvikling av modeller og bruk av DB Dseigner4 på dine øvingstimer og på ditt kontor. Ronny Mandal, foreleser i webprogrammering i PHP. Takk til deg for å ta deg til for å hjelpe oss med å forstå PHP. Kari-Anne og Tone på Grefsenhjemmet, som ga oss den nødvendige informasjon for utvikling av dette prosjektet. Til slutt takk til, Ann-Mari Torvatn, første lektor ved Høgskolen i Oslo, avdeling ingeniør, for dokumentasjonsstandarden.. Oslo, 25 Mai 2007 -------------------- -------------------- ----------------------- Munazza Butt Mona Sebri Farzana Sarwar
Innholdsliste Innledning... Om bedriften.. Dagens situasjon. Mål.. Rammebetingelse. Samarbeid med brukere/oppdragsgiver Planlegging..... Generelt..... Fremtidsplan og arbeidsplan. Utviklingsprosessen.. Forprosjekt Programmering...... Test... Utfordringer i prosjektgjennomføring Logg inn Funksjonalitet.. Kvalitet. Brukervennligheten. Sikkerhet... Teknologi... Kravspesifikasjon Generelt. Endring i kravspesifikasjon. Oppsummering/konklusjon.
3 Innledning 3.1 Om bedriften Grefsenhjemmet - et sted for omsorg, trygghet og trivsel. Og er et hjem for eldre som trenger pleie, opptrening og medisinsk behandling. Grefsen hjemmet er et privat sykehjem som ligger i bydel Nordre Aker og er eiet av en stiftelse tilknyttet Grefsen menighet. Sykehjemmet har 87 plasser hvorav 17 plasser er en skjermet enhet for aldersdemente. 3.2 Dagens situasjon Grefsen hjemmet har pr i dag ingen egen informasjonsside, men er generelt omtalt under Oslo kommunes samlede nettside. Av hensyn til dette ser sykehjemmet et behov for en mer detaljert og bedre beskrivelse av hjemmets gode tjenestetilbud og særpreg. Med en slik side vil hovedfokuset først og fremst ligge på deres enhet, noe som forhåpentligvis resultere i at målgruppen finner den brukervennlig og profesjonell. Budstikka er en lokal avis som kommer en gang i måneden. Denne avisen skriver blant annet om ting som skjer/ er i prosess og som har skjedd på sykehjemmet de siste ukene. I og med at ikke all informasjon egner seg til trykk, eksempelvis viktige saker med personopplysninger, er det også et ønske om å opprette et intranett hvor slike saker kan meddeles. Ansatte på Grefsen hjemmet jobber på 11 forskjellige grupper. Hver gruppe får sine lister for ekstravakter i papirutgave. Denne ordningen er både tungvindt og lite miljøvennlig. Det er derfor ønskelig at ansatte kan registrere sine vakter via internett. Det er enkelt, fleksibelt og tidsbesparende både for ansatte og ledere. Et slikt opplegg vil kreve et innloggings system for alle ansatte, hvor en blant annet kan lett få oversikt over de ledige og besatte vaktene samt tilgang til å endre/ bytte disse. 3.2 Mål Målet med denne prosjektoppgaven var altså: - lage en egen og brukervennlig hjemmeside hvor søkere kan få god og oppdatert informasjon - utforme et intranett for ansatte - utvikle et innloggissystem samt et system for registrering av ekstra vakter - Innloggissystemet må skilles mellom vanlig ansatte og sjefer. - Vaktsystem må stille store krav til brukervennelighet da brukerne ofte kan være uerfarne databrukere.
3.4 Rammebetingelser Etter å ha vært på møter hos Grefesenhjemmet og veileder tok vi utgangspunkt i kravene vi ble enig om i forprosjekt rapporten. Men det viste seg at det ble mange forandringer underveis. 3.4.1 Minste krav til funksjonalitet Innloggingssystem for vanlig ansatte og administrator via internett Det skal være mulig å bytte passord Få sendt gammel passord tilbake på e-post Registrere, slette, endre informasjon på ansatte Brukernavn og Passord skulle sendes automatisk etter å ha registrert en ansatt. Registrere vakter ved valg av turnusperiode, gruppe, uke og dag Ansatte kan sette seg på vakter og slette dem Liste over hvem som har fått vakter Maks tre stykker kan sette seg på en bestemt vakt Administrator skal velge en av tre som får vakten 3.4.2 Andre krav Må være enkel Mulighet for å videre utvikle systemet Må være fleksibel Unngå mest mulig dobbel lagring Intranett må ikke gjøres ferdig 3.4.3 Tekniske Krav Plattform: MySQL 4.1 Programmeringsspråk: PHP, HTML og Java script. Modelleringsspråk: DB Designer 4 og UML modellering ved bruk av Rational Rose. Utviklingsmiljø: Textpad, MySQL-front og putty. Systemet skal kjøres på Internett Explorer, Mozilla firefox og Opera.
3.5 Gruppen Gruppen bestod opprinnelig av Mona og Sara. På slutten av desember fikk de forespørsel fra Munazza om å få lov til å bli med i deres gruppe, etter at en i gruppen hennes valgte likevel å ikke ta hovedprosjekt.. Det synes Mona og Sara at det var greit, for Sara hadde vært syk, og det kunne være mulig at hun sluttet på skolen. Etter noen uker fikk vi beskjed at Sara skulle slutte på skolen. Vi følgte at det ble lite med to stykker i gruppen. Farzana kom med et ønske om å ta hovedprosjektet sammen oss, siden hun også stod uten gruppe. Dermed sa Mona og Munazza ja til henne, og ble tre på gruppen. 3.5.1 Læring Alle i gruppen hadde forskjellig start med dette prosjektet. Munazza tok opp det siste året sitt etter å ha vært borte fra skolen i fire år. DB Designer 4 hadde de da ikke. Så hun måtte lære det av Farzana og Mona som hadde tatt kurset Relasjonsdatabaser året før. Samtidig møtte hun opp i øvingstimene i Relasjonsdatabaser for å få litt hjelp med å komme i gang. MYSQL Front og DB Designer 4 ble også brukt samtidig. ER - modellen ble laget i DB Designer 4, som lettest kunne synkronisere tabellen til databasen. Det ble enklere å lagre forandringer i databasen. Videre måtte oppkobling til databasen via PHP læres.. Kurset i PHP tok opp databaser ganske seint i semesteret, slik at vi måtte lese på egen hånd og spørre læreren om hjelp ved behov. Munazza kunne Rational Rose fra kurset Systemutvikling og måtte lære Farzana og Mona bruk av dette verktøyet. Både Munazza og Mona er gift og har barn. Det ble noen perioder med fravær for dem på grunn av syk barn etc.
3.5.2 Problemer/Løsninger Det hendte at vi fikk problemer med å komme inn på våre www mapper og med oppkobling til databasen på skolen. Da bestemte vi for å foreta andre oppgaver enn å jobbe med databaser. Siden alle skulle få gleden av å jobbe med hovedprosjektet, bestemt Munazza at medlemmer i gruppen skulle få oppgaver som de ville jobbe med. Hun påtok ansvaret for å utvikle registrering av vakt systemet. Mona og Farzana fikk ansvar for utvikling av web sider siden de ønsket det. Senere påtok de seg ansvaret for utvikling av innloggings systemet. Alle tre fikk egne ansvarsområder. Dermed kunne vi jobbe med hver vår del og unngikk da problematikken med å jobbe på felles filer. Alle delene ble sydd sammen på slutten som et ferdig produkt. I ettertid ser vi at dette var en god måte å løse oppgaven på. Alle var enig at vi skulle hjelpe hverandre og påta hverandres oppgaver ved behov.. Dette skulle være en fells prosjekt. Det var da viktig med støtte i gruppen. Kommunikasjon med Grefsen hjemmet forgikk over telefon og e-post. Ved behov for detaljert informasjon avtalte vi møter med dem. 3.5.3 Samarbeid med oppdragsgiver Vi har samarbeidet tett med oppdragsgiver. Har hatt mange møter og samtaler med dem. Vi forklart dem underveis hvordan vi har tenkt og hvor langt vi har kommet med prosjektet. De har godkjent material før vi fikk publisert det på nettet. All sensitiv informasjon som for eksempel om beboere ble nøye diskutert før vi kunne la det ut på nette.
4 Planlegging og metode 4.1 Planlegging av selve prosjektet Det første vi gjorde var å besøke veilederen for å spørre om omfanget til oppgaven ikke kom til å bli alt for stor for oss.. Med tanken på å utvikle en hjemmeside, intranett, innloggings system og et system for registrering av ekstra vakter virket veldig mye. Men veiledren mente at vi burde fokusere mest på selve vakt - og innloggingssystemet, og om senere vi fikk tid skulle vi jobbe med web sider senere hvis vi fikk tid. Vi prioriterte hjemmesiden og vakt- og innloggingssystemet. Grunnen var at registrering av ønskede vakter skulle utføres via internett. Og vi følte at vi kanskje gjorde en halv ferdig jobb samtidig at det ikke skulle bli en liten oppgave med bare vakt - og innloggingssystemet. Intranett tenkte vi kunne videre utvikles fra internett sidene, slik at det beste ville være å ha en hjemme side mer eller mindre helt ferdig sammen med vakt - innloggingssystemet. 4.1.2 Dokumenter som ble brukt Kravspesifikasjon var det aller første viktige dokumentet som ble utarbeidet slik at vi visste hvilke krav vi skulle oppfylle og bygge vår modeller på. Fremdriftsplanen ble satt opp tidlig i prosjektet. Sammen med denne ble det også utarbeidet en overordnet arbeidsplan. Begge disse dokumentene har blitt brukt aktivt gjennom hele prosjektet. Underveis har vi blitt forsinket med å følge planen, etter som det ikke var planlagt. Vi fikk en riktig ER- diagram som både vi og veileder var enig i ganske seint i semesteret. 4.1.3 Datamodellering Den første prioritering vi gjorde med vakt systemet var å forstå oppgaven nøyaktig og riktig slik at det ikke skulle oppstå problemer senere.. Tiden var knapp og vi kunne ikke mye PHP heller. Så vi begynte med UML modellering for å få et klarere bildet av hva utvikling av dette systemet skulle innebære. Ved bruk av Rational Rose lagde vi Use Case, sekvens diagram og klasse diagram. Alt dette virket helt greit i denne fasen, og vi fikk inntrykk av at vi kommer sikkert til å bli ferdig med dette. Når alt dette var ferdig var tiden kommet til å designe ER modellen. Vi definerte tabeller vi trodde vi trengte ut fra klasse diagrammet. Tok med attributter som vi trodde var nødvendig, definerte de attributtene vi mente var fremmednøkler og primær nøkler. Vi visste at hvis den var riktig ville ikke vi få problemer med å programmere.. Men vi visste også at vi kunne ikke forutsi at den kom til å være helt riktig ved første utkast. Iterering for modelleringen og programmering kom til å bli en del av resten av prosessen.
5 Utviklingsprosessen. 5.1 Forprosjekt Starten av prosjektet hadde vi mange tanker og ideer om hvordan ting skulle gjøre. Vi visste at vi kom til å ha en hovedprosjektoppgave for Grefsehjemmet, slik at alle på gruppen gjorde seg sine egne tanker om hvordan dette skulle løses. Under forprosjektet ble kravene og rammebetingelsene konkretisert, både sammen og med arbeidsgiver. Oppdragsgiver hadde kun ønsker på funksjonaliteten, hvordan det ble løst teknisk stod vi fritt til å velge. I felleskap ble vi enige om å utvikle prosjektet i PHP og MySQL. Dette ville gi oss mulighet til å lære oss en ny teknologi. 5.2 Designfasen: Grefsen hjemmet har fast 50 ansatt på jobben. Det var da helt sikkert at vi måtte ha en tabell som skulle inneholde all informasjon om en ansatt. Hele kjernen bak dette vakt systemet var at en ansatt måtte være registrert av en sjef for å kunne logge seg inn på systemet. En ansatt skulle få tilsendt brukernavn og passord for logge seg inn i systemet via e-post. 5.2.0 Hjemmesiden til Grefsenhjemmet Det tok tid før vi kom frem til noen løsning på hvordan vi skulle designe hjemmesiden. Vi tok hensyn til at hjemmesiden var rettet til en bestemt mål gruppe. Derfor bestemte vi oss at den hjemmesiden vi lager bør være enkelt å bruke, for brukerne har ikke så mye kunnskap til data maskiner. De hadde ikke noe informasjon på nettet, slik at vi var nødt til å avtale møter med noen ansatte ( ergoterepaut, fysioterepaut, Aktivitør, Daglige ledere) hvor vi fikk nok informasjon om Grefsenhjemmet av hver og en av dem, og vi noterte alt på papir det de fortalte oss. De fikk alt dette tilbake etter at vi hadde pent skrevet det slik at de skulle godkjenne at stoffet blir publisert, dette tok en måned før vi fikk svar tilbake. I hjemmesiden til Grefsenhjemmet har vi lagt alle informasjon om sykehjemmet som arbeidsgiveren hadde ønsket. Fra starten av hadde vi besøk til Grefsenhjemmet hvor vi tok masse bilder av både ansatte, huset og beboere. Senere ble alle disse bildene tilpasset hjemmesiden. Vi lagde galleri på disse bildene og det er en egen link på hjemmesiden som går til den. Vi har laget slik at alle ansatte og administrator kan logge seg in hvor de kan lese viktige informasjon, introduksjons programmet og printe ut taushetsplikt skjema for nye ansatte. Før var det slik at en av sjefene måtte gå og dele det ut til ansatte.
Vi har vært på onsdags treff en gang hos dem, og der fikk vi anledning å intervjue noen av Grefsenhjemmets venner, og tok bilder av dem. Det ligger under intervju linken på hjemmesiden. Vi har også egen link hvor folk kan kontakte Grefsenhjemmets venner hvis de ønsker å bli venn til Grefsenhjemmet. Vi har også tatt med noen viktige linker som går til Oslo kommunetshjemmeside hvor folk kan søke ledige stillinger, eller søke på plass i Grefsenhjemmet. 5.2.1 Brukernavn og Passord Først ble det bestemt at en ansatt skulle ha lagret sitt brukernavn og passord i en egen passord tabell og brukernavn tabell. Men for å gjøre ting enklere bestemte vi oss for at bruker navnet skulle være e-post adressen som skulle være en del av informasjon som skal registreres i Ansatt tabellen... Grunnen til at vi valgte e-post som brukernavn var at selv om folk kan ha like navn, er e-posten alltid forskjellig, slik at det ikke blir noe problem. Passord skulle genereres automatisk, isteden for at en sjef velger en passord for en ansatt... Med en gang en ansatt blir registrert skal det sendes automatisk en e-post med brukernavn og passord. Må denne måten ville en sjef slippe å ta vare på alle e-post adresser og passord og vil slippe å gjøre den jobben med å sende e-post til alle ansatt. 5.2.2 Vakt systemet Under utvikling av registrering av vakt systemet møtte vi mange utfordringer. En vakt måtte være registrert av en sjef før en ansatt kunne velge en vakt og deretter sette seg på. Det finnes 11 grupper på Grefsen hjemmet og per dag kan de ha opptil 9 ekstra vakter ledige. Vi tenkte det ville være utrolig slitsomt å gjøre 9*11=99 registreringer pr dag for alle gruppene, så vi måtte finne en enklere måte å gjøre det på. Da hjalp multiple select i select menyen masse. Med den lille koden kan man velge mange uker, grupper, dager, vakter og turnusperioder på en gang og få registrere mange vakter for mange dager ved et klikk. 5.2.3 VaktListe og VaktPlan Vi hadde fått beskjed at en ansatt kunne sette seg på vakt på andres gruppe enn sin egen når det gjaldt ekstra vakter. Og at på en bestemt vakt kunne det være opptil 3 mulige kandidater. Vi slet lenge med å finne løsningen på hvordan vi skulle gjøre, til en dag vi skjønte at alle attributtene i tabellen
VaktListe og VaktPlan skulle være primær nøkler. For da vill jo vi ikke få lagt inn en ansatt to ganger på en bestemt vakt kombinasjon. Det fant vi ut litt sent i semesteret som gjorde at resten av programmeringen ble også litt forsinket. Til da hadde vi fått utviklet 5-6 forskjellige ER modeller. Den første ERmodellen tok utgangspunkt i klassediagrammer. 5.3 Programmeringsfasen I starten av selve kodingen ble det lagt mest vekt på funksjonalitet. Brukergrensesnitt og brukervennlighet ble satt i andre rekke. Når vi ble ferdig med funksjonaliteten begynte vi å fokusere om brukervennligheten av systemet. Koding og funksjonaliteten har blitt forbedret underveise i prosjektet. Dette har ført til enkelte endringer i kravspesifikasjonen. Arbeidet har periodevis blitt gjort hver for oss for så å i felleskap diskutere videre løsninger og oppdateres på alle delene av prosjektet. 5.3.1 Registrering av ansatt Registrering av ansatte skjer i Ansatt tabellen. Alle feltene må være fylt ut før man kan sende inn skjema. Java script er brukt for å sjekke om man ikke skriver feil. Etter at formen er sendt, blir det generert et passord automatisk og lagt inn i attributtet Passord som ikke er med i formen. For det er ikke sjef som skal registrere et passord. Første insert setning ble gjort i denne filen. Å gjøre seg vant med input type felter, feiling og retting av oppkobling til databasen, bruken av Java script ble gjort her. Det tok litt tid til å finne funksjonen isnan(), som kan sjekke om data er tall eller ikke Se fil: ansatt2..php 5.3.2 Endre informasjon på en ansatt For at en administrator skal endre informasjon på en ansatt må den først skrive inn e-post adressen til en ansatt den ønsker å endre informasjon på. Deretter trykker den på knappen Hent for å hente informasjon fra databasen om den bestemte ansatt. Kan forandre på felter man ønsker og deretter trykke på knappen Legg Inn. Her hadde vi problemer med å få to knapper til å fungere. Der var nøkkelen å gi samme name verdi til begge knappene. Se fil: ansattendre..php 5.3.3 Slett en ansatt En administrator kan slette en ansatt fra sin database på grunn av oppsigelse. Vi valgte at alle e-postene som finnes i databasen, skulle vises i en select meny. Sjefen velger da den som skal slettes. Trykker på knappen Denne
ansatten skal slettes, og får da gjort det. I denne filen, ble vi kjent med å gjøre bruk av to filer for å utføre en seltt operasjon. Nøklen var også å gjøre bruk av feltet input type = 'hidden'. Se fil: slett_ansatt2.php og slett_ansatt3.php 5.3.4 Liste over hvem som har fått vakt Ved gjør valg over turnusperiode, gruppe, uke og dag får man opp enliste over hvem som har fått vakter på den dagen. Da er det bare de som har Status_1 som vises. Se fil: SjekkUtAnsattePaVakt..php og VisAnsattePaVakt 5.3.5 Registrering av vakter En vakt måtte være registrert av en sjef før en ansatt kunne sette seg på en vakt. Det finnes 11 grupper på Grefsen hjemmet der ansatte jobber. Og per dag kan de ha opptil 9 ekstra vakter ledige. Vi tenkte det ville være utrolig sjedelig å gjøre 9*11=99 registreringer pr dag for alle gruppene, så vi måtte finne en enklere måte å gjøre det på. Da hjalp select multiple name="" koden masse. Med den lille koden kan man velge mange uker, grupper, dager, vakter og turnusperioder på en gang. Og ved hjelp av foreach () for hver verdi, få registrert (får gjort insert) av mange vakter ved hjelp av ved et klikk. Vaktene blir registrert i VaktPlan Tabellen. Se fil: VelgVakt..php. 5.3.6 Vis liste over vakter for å sette seg på Neste utfordringen var at når en ansatt skulle sette seg på vakt, måtte den bare få vakter for den bestemte turnusperioden, bestemte dagen og for den bestemte gruppen den ønsket å jobbe gi. Først ble det gjort en SELECT setning for å finne alle mulige vakter for denne kombinasjonen.. Liste over vakter registrert for en bestemt kombinasjon kunne ikke bare visses i en vanlig tabell. Da ble det også brukt en select name="" denne gangen, for det skulle være bare mulig å velge bare en vakt av gangen. Den ble brukt før while($rad = mysql_fetch_object($resultat)) som ble brukt for å liste ut alle vaktene, og ble avsluttet med en "</select>\n". Se fil: VelgVakt2..php 5.3.7 Når man skal sette seg på Det burde være slik at når en ansatt valgte en vakt av lista, så skulle det være mulig å sette seg på med en gang. Men siden det er bare 3 personer som kan sette seg på en bestemt vakt kombinasjon, så må vi sjekke først med databasen om det ikke er gjort det. Det ble funnet på masse kreative ting der,
men ingenting fungerte helt perfekt til vi skjønte at funksjonen mysql_num_rows() kunne gjøre nytte her. Se fil: VelgVakt..php VelgVakt2.pho velgvakt_3 5.3.8 Sjekk ansatte satt seg på vakter Når en administrator skal sjekke hvilken ansatte har satt seg på, må den først velge ut en bestemt kombinasjon valgt ved gruppe, uke og dag. Deretter blir den sendt til en annen side som gererer lista uti fra de valgene som har blitt gjort. Listen kommer ut med all informasjon som ligger i VaktListe tabellen hvor status er 0. Ingen har fått vakt ennå. Men på slutten av hver rad blir det lagt til en radioknapp. En administrator skal velge en ansatt som får vakten ved å klikke inn i radioknappen. En ansatt er da selv ansvarlig for å sjekke om den har fått vakt. De ansatte som får en vakt får status verdien lik 1 i VaktListe tabellen. Se fil: SjekkUt Vakter.php VisVaktListe.php FikkVakt.php 5.3.9 Registrering av ulike vakt typer Her var det ikke noen spesille problemer som vi møtte. Registrering av ansatte hadde lært det meste om skulle gjøres her. Alle vakter som finnes i Grefsen hjemmet skal registreres her. Se fil:registrertypervakt..php 5.3.10 Registrering av turnusperiode En turnusperiode varer i 12 uker. Vi valgte å registrere dato fra og dato til i vanlig format.. Men inni filen blir disse verdien gjort om til timestamp. En timestamp regner ut antall sekunder fra 1970. I databasen blir det lagret som et tall, som gjør det lettere å utføre regne operasjoner. Denne koden krevde også en del tid og forståelse. Bruken av funksjoner som mktime(), list() og explode() gjorde nytten. Se fil: TurnusPeriode2..php 5.3.11 Forsiden til en administrator og en ansatt Forsiden til en administrator og en ansatt inneholder knapper som kan velges etter hva den ønsker å utføre. På denne siden ble Java script brukt på en annen måte en i ansatt2.php filen. Det løste problemet vårt for å gå inn i en fil uten å vise hovedmenyen samtidig. Buken av onclick="" var utmerket for å vise de ulike sidene. Se fil: indexa..php og indexansatte.php 5.3.12 Logg inn Enkelte tjenester i systemet var nødt til å legges bak passordbeskyttede områder. I tillegg har vi ulike roller, Ansatte og administrator. Vaktsystemet håndterer om en ansatt eller en administrator er logget inn i systemet. Ansatte skal kunne logge seg inn og se hvilke ekstra vakter som er ledig.
Hvem som har satt seg på vakt sette seg på ønsket vakt og se på lister over de som har fått ønsket vakt. I administrasjonssystemet har det blitt definert to roller, administrator og ansatt.. Måten dette har blitt løst på, er å begrense menyvalgene.. Filene for administrator ligger i et eget beskyttet mappe. 6 Funksjonalitet Vi testet produktet som ble laget i mest brukte type nettlesere som: Microsoft Internett Explorer, Mozilla, FireFox Og Opera. All funksjonalitet er testet fullt ut i alle disse nettleserne. Utfordringen har vært spesielt stor med tanke på design. Alle nettleserne har ulike måter å tolke designregler satt i stilark, hvis man ikke spesifiserer alle verdier. Noe vi har løst med å være konsekvente med regelsettingen.. Mer om testresultatene finnes i testrapporten. 6.1 Valget av teknologi og verktøy Valget falt på programmeringsspråket PHP og MySQL, fordi vi ikke hadde mye erfaring i det fra før, så dette var en utfordring for oss å få kunnskap til den teknologien. Alle i gruppa valgte webprogrammering kurset som valgfag for å lære seg de grunnleggene mellom PHP og Database systemet. Og hva som skiller programkode fra html-koden og PHP-koden. JavaScript er mye brukt for å gjøre ting enklere på forskjellige websider men er derimot ikke så pen å jobbe med. Putty er et gratisprogram som lar en koble seg til en annen maskin på nettet og kjøre koden derfra. Mysql - front - ble brukt for sjekke data mot databasen. DB Designer 4: brukt for å modellere ER - diagrammet. Paintshop: et profesjonelt bildeprogram. Programmet har hundrevis av funksjoner og er ikke så enkelt å bruke men vi har brukt den gjennom flere år. HTML: hjemmesiden ble laget ved bruk av den. PHP: ganske rask og kraftig ved bruk på nettet og er støttet av flere plattformer. MySQL: kan lastes ned gratis og er rask i bruk.. 6.2 Sikkerhetsvurderingen Det er tatt mange avveininger med tanke på sikkerheten i prosjektet. Alle websider som er tilgjengelig på nett kan være utsatt for angrep utenfra, og etter en analyse av sikkerheten ser vi muligheten for et vellykket angrep utenifra som liten.
En ansatt må være pålogget for å sette seg på vakt. Dermed sikrer vi at en ansatt ikke setter seg opp for en annen. Ansatt id blir satt automatisk når man setter seg på. 6.3 Fleksibilitet Vi har laget et enkelt system som kan tas bruk andre bedrifter som har ansatte som jobber på turnus. Systemet er utviklet opp mot en MySQLdatabase, ved å endre på databasetilkoblingen kan systemet settes i drift ved å gjøre enkle modifiseringer i SQL syntaksen. Dette systemet kan også tilpasses den enkelte firma som ønsker å bruke den. 6.4 Drift Systemet settes i drift slutten av mai 2007. Vi håper at det skal bli en suksess og at brukerne kommer til å bli fornøyde med løsninger vi har valgt. Til slutt håper vi oppdragsgiver får stor nytte av produktet vi har utviklet. 6.5 Testing Gjennom hele prosjektet har vi testet deler av prosjektet som var gjennomført og på denne måten kunne vi oppdage feilene mye lettere enn å teste bare på slutten av prosjektet. Det er jo tross alt mye enklere å rette få feil enn mange feil og vi så på denne fasen av prosjektet som en av de mest avgjørende for å få til et bra resultat. 6.4 Kravspesifikasjon 6.4.1 Generelt Kravspesifikasjonen har naturligvis vært et viktig dokument gjennom hele utviklingsfasen. Funksjonaliteten ble fastsatt av gruppa. De tekniske kravene var det også opp til gruppa å finne gode løsninger på.
6.4.2 Endringer i kravspesifikasjonen Kvaliteten i kravspesifikasjon har ført til at vi kun har gjort små endringer på den opprinnelige spesifikasjonen. Vi har ikke rukket å lage en fullstendig intranett. Men filer som ligger inne i systemet etter at man har logget seg inn og på internett kan brukes til intranett. Videre får en ansatt registrert sine vakter ut i fra en dag. Mens i kravspesifikasjonen hadde vi sagt vakt skulle settes ut i fra en dato. Ellers er de fleste krav oppfylt. 6.4.3 Forslag til videreutvikling Turnusperioden kan videre utvikles må mange måter. Det går an å programmerer på den måten at neste turnusperiode blir regnet ut automatisk. Siden en turnusperiode inneholder 12 uker og hver uke begynner på mandag, så ville ikke det være noe problem. Samtidig kunne man vise en meny over turnusperioder, som viser for eksempel en turnusperiode fram i tid. Ekstra vakter blir registrert fortløpende, gjerne 2-3 uker av gangen. Videre kunne man få opp en dato sammen med valg av dag. Dette vil gjøre enda enklere for dem å huske hvilke dager de vil jobbe. Slik systemet fungerer nå får man opp id til dagen opp. For eksempel hvis det er mandag, står det id lik en. Ved enkel SQL setning kan man gjøre det. Kanskje burde man legge inn flere Java script for å få opp feilmeldingen på en ordentlig måte. Videre kunne GUI en også videreutvikles. Lister over hvem som har fått vakter eller står i ønsket vakter kunne genereres for en uke. Istedenfor å gjøre valg av turnus, gruppe, uke, dag, kunne det komme opp et skjema for hver gruppe for en hel uke, fra mandag til søndag. Inni den kunne en ansatt sette seg på en felt, hvis den ikke er fylt. Den som har fått vakt kunne stå i grønt, de som står ønsket står i gult og de som ikke fikk vakt står i rødt. (Se Vedlegg: Ukeplan) 7 Oppsummering Hva kunne gjøres annerledes Når vi ser tilbake på det arbeidet vi har gjort, kunne en del vært gjort annerledes. For eksempel burde vi ha brukt mye mer tid på slutt dokumentasjon. Vi burde ha tatt en tur med veilederen ganske tidlig i semesteret.
Men med tanke på den kunnskap og erfaring vi har fått ved starten av prosjektet er vi veldig fornøyd med vår egen innsats. Og vi tror det er viktig å ikke gi opp når ting er vanskelig og ikke mistet motet. Tålmodighet er viktig. Med prosjekt arbeid er det viktig å lære av feil og forstå så mye som mulig. Oppsummering Vi er veldig godt fornøyde med resultatet og ser at det har vært en lærerik prosess. Vi har utviklet et komplett system som skal brukes på nettet av en kundegruppe. Det har fungert som en ekstra motivasjonsfaktor. Gruppesammensetningen og samarbeidet i gruppa har fungert godt og forskjellig syn på løsninger har bidratt til god kvalitet på produktet. Vi er veldig fornøyde med den tekniske kunnskapen vi har tilegnet oss i PHP, MySQL og Java script som kommer helt sikker til nytte i fremtiden. Konklusjon Nå som vi er i avsluttende fase så prøver vi å se tilbake og huske hvilket utgangspunkt vi hadde for å utvikle dette prosjektet, og hva har vi lært nå. I forhold til hvilket fag kunnskaper og erfaringer vi hadde med teknologiene har vi brukt har vi lært masse. Vi er mye mer bevisst på hvordan det er å jobbe med en bedrift hvor grenser og arbeidsoppgaver kan være mer diffuse en de vi blir utdelt av skolen. Vi er mer bevisst på hvor viktig det er å ta kontroll og ansvar for sin del av arbeidet. Den kanskje viktigste erfaringen vi har gjort er å innse hvor viktig det er med tydelig og utvetydig kommunikasjon. Dårlig kommunikasjon er oftere skylden i forsinkelser og feil. Vi har lært veldig mye, både om hvordan det er å jobbe med en oppdragsgiver og om å måtte ta ansvar for det man gjør. Ikke minst har vi blitt nærmere kjent med hvordan en prosjektprosess kan foregå. Prosjektet har uten tvil gjort oss mer rustet til å møte arbeidslivet. Kildehenvisning Bøker: Sven Andreas Horgen: Webprogrammering i PHP 2.utgave. Larry Ullman : PHP for the world wide web Second edition.
Internett: http://.www.mysql.com http://.www.php.net http://.www.w3schools.com Ordforklaringer: E-post Det er en elektronisk post. Fungere på samme måte som vanlig post med adresser.. Hjemmeside Oppslagsside på en persons, firmas eller organisasjons webserver Data Informasjon på en datamaskin mener man lagret informasjon som kan være tekst og tall, bilder, lyd eller video. Lenker/Linker Tekst eller grafikk man klikker på i en webside for å komme til andre sider, eller til andre steder på den samme siden. Musmarkøren forandrer seg fra en pil til en pekende hånd når man beveges over en lenke.. URL Uniform resource locater. Adressen til en webside (grefsenhjemmeside). Pass på å skrive inn adressen nøyaktig(med små/store bokstaver), de fleste nettlesere er det unødvendig å skrive inn http://.