Hovedprosjekt våren 2011 gruppe 10

Hovedprosjekt våren 2011 gruppe 10 Endre Gulbrandsen s150690

PROSJEKT NR. 2011 10 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong DATO 31. mai 2011 ANTALL SIDER / BILAG 65 PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER Linda Sjåstad v / Hårgalleriet Hønefoss KONTAKTPERSON Linda Sjåstad lindasj7@hotmail.com SAMMENDRAG Dette er sluttdokumentasjonen til hovedprosjektet for gruppe 10 ved Høgskolen i Oslo 2011. Rapporten inneholder to dokumenter, en prosessrapport og en produktrapport. 3 STIKKORD Timebestilling Frisør Online

PROSESSDOKUMENTASJON

INNHOLD Innhold 1 Innledning... 4 2 BESKRIVELSE AV INNVOLVERTE PARTER... 5 2.1 Prosjektgruppen... 5 2.2 Hårgalleriet... 5 2.3 Intern veileder... 5 3 Metodikk... 6 3.1 Smidig utviklingsmetodikk... 6 4 Oppstartsfasen... 7 4.1 Kravspesifikasjon... 7 4.2 Use Case... 7 4.3 Prosjektplan... 8 4.4 Risikoanalyse... 9 4.5 Prosjektnettsted og prosjektdagbok... 13 5 Beskrivelse av arbeidsflyten... 14 5.1 Månedlig fremdrift... 14 5.2 Kontakt med involverte parter... 15 5.2.1 Intern veileder... 15 5.2.2 Kontakt med oppdragsgiver... 15 8 Utviklingsarbeidet... Feil! Bokmerke er ikke definert. 8.1 Kodestandard... Feil! Bokmerke er ikke definert. 8.2 Prototyping av brukergrensesnittet... Feil! Bokmerke er ikke definert. 9 Testing... Feil! Bokmerke er ikke definert. 10 Avslutningsfase... 16 11 Konklusjon... Feil! Bokmerke er ikke definert. 12 Kilder... 16

Vedlegg... 17

1 Innledning Denne rapporten inneholder prosessdokumentasjon for mitt hovedprosjekt ved Høgskolen i Oslo, våren 2011. Mitt oppdrag har vært å lage et system for frisørsalong, primært for en frisør som ikke er helt fornøyd med dagens system. Dette systemet kan også vurderes å tas i bruk av hele firmaet dersom det blir en suksess. Til å veilede meg har jeg hatt god hjelp fra min interne veileder fra HiO, Tor Krattebøl. Applikasjonen er utviklet ved hjelp av PHP og MySQL. Jeg vil rette en takk til Linda Sjåstad som har vært essensiell i prosessen med å utvikle kravspesifikasjonen, og en stor takk til Tor Krattebøl for veldig bra veiledning underveis.

2 BESKRIVELSE AV INNVOLVERTE PARTER 2.1 Prosjektgruppen Prosjektgruppen har bestått av følgende medlem: - Endre Gulbrandsen (s150690) 2.2 Hårgalleriet Hårgalleriet er en populær frisørsalong med to avdelinger i Hønefoss. Disse ligger på Kuben kjøpesenter og sentrumskvartalet. Bedriften har 7 ansatte som har en hektisk hverdag med stor tilstrømning av kunder. Linda Sjåstad er frisør i Hårgalleriet og dette systemet er designet etter hennes ønsker og behov. Hun tilbyr alt innen hårpleie. Min kontaktperson har vært Linda Sjåstad. 2.3 Intern veileder Min interne veileder fra HIO har vært Tor Krattebøl

3 Metodikk Jeg ble tipset fra intern veileder om at jeg kunne bruke testdrevet utvikling på dette prosjektet. Jeg valgte å ikke gjøre dette fordi jeg var alene og var nødt til å prioritere. Som metode valgte jeg å bruke smidig utviklingsmetodikk. Etter å ha lest en av fjorårets prosessdokumentasjoner så fant jeg det slik at den metoden de hadde brukt ville passe bra på dette prosjektet også. 3.1 Smidig utviklingsmetodikk Smidig utviklingsmetodikk bygger i hovedsak på fire utviklingsprinsipper(beedle, et al.,2011): - Individer og samspill fremfor prosesser og verktøy - Fungerende programvare fremfor omfattende dokumentasjon - Kundesamarbeid fremfor kontraktforhandlinger - Respondere på endringer fremfor å følge en plan Når man jobber smidig, er det viktig å levere del leveranser underveis slik at kunden kan ytre ønske om endringer. Jeg har hatt kontinuerlig kontakt med oppdragsgiver under hele prosjektet, hvor hun har fått prøve systemet og komme med innspill.

4 Oppstartsfasen Da prosjektet satt i gang for fullt etter jul så hadde jeg egentlig vurdert å bruke.net rammeverket til dette prosjektet. Men ved litt prøvelse fant jeg ut at jeg er mye bedre i PHP programmering og at resultatet ville bli bedre dersom jeg valgte denne teknologien. 4.1 Kravspesifikasjon Jeg visste på forhånd at kravspesifikasjonen ville bli ekstra viktig for min del i og med at jeg jobbet alene på dette prosjektet. Jeg måtte skape klarhet med oppdragsgiver i forhold til hva som skulle leveres og hva som ikke kunne leveres i forhold til tidsrammen. Vi var enige om at den funksjonaliteten som jeg ikke rakk under prosjektperioden kunne legges til senere om ønskelig. Kravspesifikasjonen beskriver hvilke krav som settes til systemet. Disse kravene kan beskrives som funksjonelle krav og ikke-funksjonelle krav. De funksjonelle kravene beskriver en handling som systemet skal utføre, mens de ikke funksjonelle kravene beskriver egenskaper systemet skal ha. Siden jeg brukte smidig utvikling så lagde jeg en kravspesifikasjon med funksjonelle krav som stod i tråd med hva oppdragsgiver hadde tenkt seg. Disse kravene reforhandlet vi underveis da jeg så mer tydelig hva som var realistisk å rekke innenfor prosjektperioden. Jeg hadde hele tiden fokus på at oppdragsgiver skulle være fornøyd. 4.2 Use Case Jeg utarbeidet Use Case basert på de funksjonelle kravene som ble spesifisert i kravspesifikasjonen. Jeg valgte å lage et overordnet og et detaljert Use Case. I tillegg lagde jeg beskrivelser for hvert tilfelle. Eksempel på oppsett av Use Case beskrivelse: 1.1.1 Legg til bestilling Use Case Aktør Trigger Pre-betingelser Legg til bestilling Ansatt Ansatt ønsker å legge til ny bestilling En kunde vil bestille time

Post-betingelser Ny time blir lagt til ellers må det oppstå feilmelding Normal hendelsesflyt 1. Ansatt søker opp ledig tid * 2. Det sjekkes om kunden er registrert fra før ** 3. Kunden registreres på ledig time 4. Systemet lagrer informasjon i database 5. Det gis melding om prosessen var suksessfull eller om det oppstod feil Variasjoner * Ansatt kan velge å søke etter ledig tid ** Dersom kunde ikke finnes fra før må det registreres ny kunde Relatert informasjon Oversikt over eksisterende kunder kan finnes via en rullgardinmeny 4.3 Prosjektplan Jeg lagde en prosjektplan i MS Project som lå tilgjengelig på nettsiden under hele prosjektet. MS Project er laget spesielt for det formålet å holde styr på hva som skal gjøres, hvem som har ansvaret og når fristen for leveranse er.

Den tidsmessige planleggingen av dette prosjektet var viktig. Fremdriftsplanen var veldig god å ha underveis for å holde fremdriften oppe og se det hele i perspektiv. Noen av tidsfristene var satt av HiO: - Forprosjekt leveransen - Leveranse av sluttrapporten - Presentasjonen Milepælene og leveransen av de andre artifaktene bestemte jeg selv tidlig i prosjektet. 4.4 Risikoanalyse En risikoanalyse utformes tidlig i et prosjekt for å luke ut potensielle trusler som kan føre til at prosjektet i blir en fiasko. En stor risiko i dette prosjektet var tid. Det var mye å gjøre og kun meg selv til å gjøre det. Det at jeg hadde kontinuerlig kontakt med kunden gjorde at vi kommuniserte underveis og jeg fikk ført prosjektet i havn i tide. Og det gikk så vidt!

Punkt: Risiko: 1 Uenighet om hva skal lages Grad av risiko: Middels Dersom uenighet oppstår vil det være viktig å kommunisere med kunde slik at det ikke oppstår misforståelser. Use Case og low fidelity prototyper vil være viktige elementer for å synliggjøre for kunden hvordan system vil fungere og se ut. Dette vil være med på å minske risiko for uenighet om hva som skal lages. 2 Dersom det som er realistisk å oppnå i løpet av prosjektperioden ikke tilfredsstiller de krav som kunden stiller. Middels Dersom kundens krav til funksjonalitet er større enn hva prosjektets tidsperiode tillater vil det være viktig å kunne komme til en enighet om hvilke funksjoner som er essensielle for at systemet skal være interessant for kunden å ta i bruk. Det er viktig at dette blir kartlagt på et tidlig stadium ved hjelp av å utforme en nøye gjennomtenkt kravspesifikasjon. 3 Feilberegning av tid i forhold fremdriftsplanen Høy

Den største risikoen for dette prosjektet er at tiden ikke strekker til. Det er vanskelig å beregne nøyaktig i forkant hvor lang tid utformingen av nettstedet vil ta. Det er kritisk for prosjektet at det ikke blir tatt vann over hodet og at det samtales med veileder fra høyskolen i Oslo om hva som er realistisk å gjennomføre på den avsatte prosjektperioden. 4 Langvarig sykdom i prosjektperioden Liten Dersom det skulle oppstå langvarig sykdom fra prosjektgruppen så vil dette påvirke prosjektet i den grad at man havner på etterskudd i forhold til fremdriftsplanen. Men det er lite sannsynlig at noe slikt inntreffer. Skulle kunden bli syk slik at det blir vanskelig å møtes finnes det muligheter å kommunisere via for eksempel e-post. 5 Arbeidet hoper seg opp og blir lite oversiktelig Middels Et annet aspekt å tenke over er at det er mye dokumentasjon som skal produseres ved siden av selve implementeringen av systemet. For at det ikke skal

oppstå kaos er det viktig av fremdriftsplanen holdes og at man støtter seg til rammeverket UML. 6 Forstå kundens behov Middels Det å forstå kundens behov vil være viktig for å oppnå suksess. Dette kan gjøres ved å oppsøke salongen, være med og observere hvilke prosesser som foregår samt være i tett dialog med kunden. 7 Liten grad av universell utforming Middels Hentet fra lovdata.no står det i 11. Plikt til universell utforming av informasjons- og kommunikasjonsteknologi (IKT) Nye IKT-løsninger som underbygger virksomhetens alminnelige funksjoner, og som er hovedløsninger rettet mot eller stillet til rådighet for allmennheten, skal være universelt utformet fra og med 1. juli 2011, men likevel tidligst tolv måneder etter at det foreligger standarder eller retningslinjer for innholdet i plikten. For eksisterende IKTløsninger gjelder plikten fra 1.

januar 2021. Plikten omfatter ikke IKT-løsninger der utformingen reguleres av annen lovgivning. Dette betyr at det må tas hensyn til at systemet skal brukes av alle og må derfor være universelt utformet. Det er viktig at man ikke overser dette i løpet av den travle prosjektperioden som ligger foran oss. 8 Kompleks funksjonalitet Middels - Høy Det kan være at deler av funksjonaliteten er kompleks å implementere. Det vil være lurt på et tidlig stadium å kartlegge disse og ha alternative løsninger i bakhånd. 4.5 Prosjektnettsted og prosjektdagbok Jeg opprettet en nettside hvor alle dokumentene ble publisert underveis slik at intern veileder og andre studenter fikk tilgang til disse.

5 Beskrivelse av arbeidsflyten 5.1 Månedlig fremdrift Prosessen med å utvikle systemet startet i januar 2011. Jeg bestemte meg for å fokusere på god planlegging slik at jeg skulle få en god flyt i prosjektet. Januar Januar måned gikk med til å utarbeide en fremdriftsplan, gjøre analyse, utarbeide kravspesifikasjon og Use Case. Jeg hadde god kommunikasjon med intern veileder og oppdragsgiver. Leveranse for denne måneden var forprosjektrapport. Februar I februar utarbeidet jeg low fidelity prototype sammen med oppdragsgiver slik at de designmessige ønskene ble ivaretatt. Første milepæl var enighet om hva som skulle lages. Denne ble satt etter planen 8. februar 2011. Deretter startet jeg jobben med å utforme klassediagram og sette opp databasen. Mot slutten av februar startet jeg med å programmere. Jeg visste at dette ville bli den mest tidkrevende delen av prosjektet og ville komme i gang så tidlig som mulig med dette. Mars Hele måneden gikk med til hovedsakelig programmering og testing opp mot kunden. April Store deler av april gikk med på å teste og utbedre system på en iterativ måte. Mai 4 mai hadde jeg satt som milepæl å være ferdig med produktet slik at resten av måneden kunne gå med til å skrive sluttrapporten. Jeg fikk senere vite at jeg kunne utbedre produktet frem til presentasjonen den 16. juni. På bakgrunn av dette så fortsatte jeg å forbedre produktet etter den 4. mai.

Hovedfokus denne måneden var å skrive ferdig denne rapporten for å rekke leveranse den 31. mai. 5.2 Kontakt med involverte parter 5.2.1 Intern veileder Jeg hadde ukentlige samtaler med intern veileder hovedsakelig via telefon. Jeg fikk hjelp til problemer tilknyttet utvikling av systemet, programmering relaterte spørsmål og svar på hvordan jeg skulle utforme dokumentasjonen. 5.2.2 Kontakt med oppdragsgiver Kontakt med oppdragsgiver var gjennom møter og e-post. Dette fungerte utmerket og uten godt samarbeid og forståelse fra oppdragsgiver så ville det vært vanskelig for meg å gjennomføre prosjektet.

6 Avslutningsfase 6.1 Ferdigstillelse av prosjektet Når sluttrapporten ble levert den 31. mai 2011 var systemet grovt sett ferdig. Jeg gjorde kun små oppdateringer frem til presentasjonen den 16. juni. 7 Konklusjon Dette prosjektet har vært en stor jobb med mye frustrasjon, følelse av vann over hodet og store utfordringer. Alt i alt har det vært veldig lærerikt. I og med at jeg har jobbet alene så har jeg lært mye om meg selv, press, arbeidsrutiner og PHP syntaks. Jeg har vært veldig heldig med veileder og oppdragsgiver. God kommunikasjon har gjort at jeg har kunnet prestere godt og gitt meg tro på at dette skulle gå(selv om det til tider så mørkt ut). Målene jeg satt meg var at oppdragsgiver skulle bli fornøyd, å lære meg smidig utviklingsmetode samt å utvikle et onlinebasert system. Oppdragsgiver er fornøyd med resultatet så jeg kan si at jeg har oppfylt disse målene. 8 Kilder Wikipedia. (2011, 5. mai) PHP Hypertext Preprocessor. Hentet fra http://no.wikipedia.org/wiki/php Horgen, S.A. (2007). Webprogrammering i PHP (2. utg., 3. oppl.). Gyldendal Norsk Forlag

Vedlegg 1 Risikoanalyse Punkt: Risiko: 1 Uenighet om hva skal lages Grad av risiko: Middels Dersom uenighet oppstår vil det være viktig å kommunisere med kunde slik at det ikke oppstår misforståelser. Use Case og low fidelity prototyper vil være viktige elementer for å synliggjøre for kunden hvordan system vil fungere og se ut. Dette vil være med på å minske risiko for uenighet om hva som skal lages. 2 Dersom det som er realistisk å oppnå i løpet av prosjektperioden ikke tilfredsstiller de krav som kunden stiller. Middels Dersom kundens krav til funksjonalitet er større enn hva prosjektets tidsperiode tillater vil det være viktig å kunne komme til en enighet om hvilke funksjoner som er essensielle for at systemet skal være interessant for kunden å ta i bruk. Det er viktig at dette blir kartlagt på et tidlig stadium ved hjelp av å utforme en nøye gjennomtenkt kravspesifikasjon. 3 Feilberegning av tid i forhold fremdriftsplanen Høy

Den største risikoen for dette prosjektet er at tiden ikke strekker til. Det er vanskelig å beregne nøyaktig i forkant hvor lang tid utformingen av nettstedet vil ta. Det er kritisk for prosjektet at det ikke blir tatt vann over hodet og at det samtales med veileder fra høyskolen i Oslo om hva som er realistisk å gjennomføre på den avsatte prosjektperioden. 4 Langvarig sykdom i prosjektperioden Liten Dersom det skulle oppstå langvarig sykdom fra prosjektgruppen så vil dette påvirke prosjektet i den grad at man havner på etterskudd i forhold til fremdriftsplanen. Men det er lite sannsynlig at noe slikt inntreffer. Skulle kunden bli syk slik at det blir vanskelig å møtes finnes det muligheter å kommunisere via for eksempel e-post. 5 Arbeidet hoper seg opp og blir lite oversiktelig Middels Et annet aspekt å tenke over er at det er mye dokumentasjon som skal produseres ved siden av selve implementeringen av

systemet. For at det ikke skal oppstå kaos er det viktig av fremdriftsplanen holdes og at man støtter seg til rammeverket UML. 6 Forstå kundens behov Middels Det å forstå kundens behov vil være viktig for å oppnå suksess. Dette kan gjøres ved å oppsøke salongen, være med og observere hvilke prosesser som foregår samt være i tett dialog med kunden. 7 Liten grad av universell utforming Middels Hentet fra lovdata.no står det i 11. Plikt til universell utforming av informasjons- og kommunikasjonsteknologi (IKT) Nye IKT-løsninger som underbygger virksomhetens alminnelige funksjoner, og som er hovedløsninger rettet mot eller stillet til rådighet for allmennheten, skal være universelt utformet fra og med 1. juli 2011, men likevel tidligst tolv måneder etter at det foreligger standarder eller retningslinjer for innholdet i plikten. For eksisterende IKT-

løsninger gjelder plikten fra 1. januar 2021. Plikten omfatter ikke IKT-løsninger der utformingen reguleres av annen lovgivning. Dette betyr at det må tas hensyn til at systemet skal brukes av alle og må derfor være universelt utformet. Det er viktig at man ikke overser dette i løpet av den travle prosjektperioden som ligger foran oss. 8 Kompleks funksjonalitet Middels - Høy Det kan være at deler av funksjonaliteten er kompleks å implementere. Det vil være lurt på et tidlig stadium å kartlegge disse og ha alternative løsninger i bakhånd.

Produktdokumentasjon 1

Innhold 1 Innledning... 5 2 Beskrivelse av produktet... 6 Timebok... 6 Kunderegister... 6 Ny time... 7 Kasse... 8 Dagens oppgjør... 8 Andre funksjoner... 8 2.1 Brukergrensesnitt og design... 9 2.1.1 Mål... 9 2.1.2 Designvalg... 9 2.1.3 Meny... 9 2.1.4 Fonter og farger... 10 3 Applikasjonsarkitektur... 11 3.1 Domene / klassediagram... 11 3.2 Sikkerhet... 11 3.2.1 Feilsider... 12 4 Planlegging og forberedelser... 12 4.1 Valg av oppgave... 12 4.2 Dagens situasjon for oppdragsgiver... 12 4.3 Analyse... 12 4.4 Mål og rammebetingelser... 12 4.4.1 Tid... 13 4.4.2 Ressurser... 13 4.4.3 Kunnskap... 13 5 Teknologier... 13 5.1 Utviklingsteknologier... 13 5.1.1 Valg av utviklingsverktøy... 13 5.1.2 PHP (Hypertext Preprocessor)... 14 5.1.3 MySQL... 14 5.2 Andre tekniske hjelpemidler... 14 5.2.1 Microsoft Paint... 14 5.2.2 MS Project... 14 2

6 Teknisk arkitektur... 15 6.1 Applikasjonen... 15 6.2 MySQL... 15 6.3 Fastname Webhotell... 15 7 Testing... 16 Vedlegg 1 Kravspesifikasjon... 17 Vedlegg 2 Use Case beskrivelser... 25 Vedlegg 3 Akseptansetester... 31 Vedlegg 4 Brukerdokumentasjon... 34 Brukerveiledning Fame IT... 34 1 Timebok... 34 1.1 Velg dato for timebok... 34 2 Time bestillinger... 34 2.1 Ny time... 34 2.1.1 Allerede registret kunde... 34 2.1.2 Ny kunde... 35 Og følg veiledningen i punkt 2.1.1 Allerede registret kunde... 35 2.2 Endre time... 35 2.3 Avbestill time... 36 3 Kasse... 36 3.1 Ta i mot betaling... 36 4 Oppgjør... 36 4.1 Dagens oppgjør... 36 4.2 Rapporter... 37 4.3 Budsjett... 37 5 Register... 37 5.1 Kunde register... 37 5.2 Produkter... 37 5.3 Ansatte... 38 5.3.1 registrer ny ansatt... 38 5.3.2 Se på info om ansatt... 38 5.3.3 Endre opplysninger på ansatt... 38 5.3.4 Slett ansatt... 38 5.4 Gavekort... 39 3

5.4.1 Registrer nytt gave kort på allerede registrert kunde... 39 5.4.2 Registrer nytt gavekort på ny kunde... 39 Følg først punktene i 2.1.2 Ny kunde... 39 Der etter punktene i 5.4.1 Registrer nytt gave kort på allerede registrert kunde... 39 5.4.3 register for solgte gavekort... 39 6 kunde... 40 6.1 registrer ny kunde... 40 6.2 slett kunde... 40 6.3 Endre kunde... 40 6.4 Se bestilte behandlinger... 41 6.5 Se tidligere behandlinger... 41 6.6 Send e-post til kunde... 41 6.7 Se ubetalte faktura... 42 7 Notat... 42 7.1 Legg inn nytt notat... 42 7.2 Kalender... 42 7.3 Dagens gjøremål... 43 7.4 Modell liste... 43 7.5 Linker... 43 4

1 Innledning Denne rapporten inneholder produktdokumentasjon for mitt hovedprosjekt ved Høgskolen i Oslo, våren 2011. Rapporten beskriver hvordan produktet er bygd opp og hvilke tekniske komponenter som er brukt i utviklingen. I tillegg inneholder rapporten testdokumentasjon, samt installasjonsveiledning og brukerdokumentasjon. 5

2 Beskrivelse av produktet Dette systemet er et timebestillingssystem for frisørsalong laget spesielt for frisør Linda Sjåstad ved Hårgalleriet i Hønefoss. Systemet er en webapplikasjon som er utviklet i PHP med MySQL database. Timebok Timeboken lagrer timebestillinger som er lagt inn av frisør, og lister disse basert på valg av dato. Det er mulig å legge til, endre og slette timebestillinger. Kunderegister Systemet inneholder et kunderegister med informasjon om kundene. Det er mulig å legge til, endre og slette kunde. I tillegg kan man se tidligere behandlinger og fremtidige behandlinger, samt sende e- post til kunden. 6

Ny time En sentral funksjonalitet er å legge til ny time. Dersom kunden eksisterer kan det legges in timebestilling med ønsket behandling, dato, tid, frisør og ønsket påminnelse. 7

Kasse Kassen er betalingsbilde hvor frisøren registrerer om kunden har betalt eller ikke. Her listes behandlinger som ikke er betalt sortert på valgt kunde. Dagens oppgjør Dersom kunden har betalt for dagens behandling så vil dette listes under dagens oppgjør. Her vises totalt inntak for dagen, med og uten moms. Andre funksjoner Systemet inneholder tilsvarende skjermbilder for følgende funksjonalitet: - Produkter - Ansatte - Gavekort - Notat - Modell liste 8

- Linker - Dagens gjøremål 2.1 Brukergrensesnitt og design 2.1.1 Mål Oppdragsgiver var klar på at design var en viktig faktor ved utforming av nettsidene. Hun ønsket seg et 50 talls inspirert utseende med pastellfarger. Applikasjonen måtte kjøre online slik at den var tilgjengelig overalt. Videre ønsket oppdragsgiver knapper for å navigere seg rundt i systemet. Både knapper og sider skulle stå i stil gjennom hele applikasjonen. 2.1.2 Designvalg Ved innlogging vises FameIT logoen og man tas direkte til timebok siden. Her listes dagens kunder basert på hvilken frisør som er innlogget. Selv om dette systemet skal brukes foreløpig av kun èn frisør, så er det lagt opp på denne måten slik at flere kan bruke systemet etter hvert. 2.1.3 Meny Menyen er konsistent gjennom sidene i systemet. Den er lagt slik at den lister hovedfunksjonene, men videre menyer til under-funksjoner. 9

2.1.4 Fonter og farger Oppdragsgiver ønsket seg pastellfarger og den rosa fargen preger systemet på slik måte at det blir et slags kjennemerke. Fargen er litt sjokkerende ved første øyekast, men man venner seg faktisk til den etter hvert (jeg burde vite det). Font typen som går igjen på knappene og menyen er av typen Rockwell. 10

3 Applikasjonsarkitektur 3.1 Domene / klassediagram Jeg designet et klassediagram som senere ble implementert i MySQL via phpmyadmin. 3.2 Sikkerhet Sikkerhetsmekanismen i systemet er begrenset til en innloggingsfunksjon. Kun brukere av systemet har tilgang via brukernavn og passord. I tillegg så er det egen lenke til innloggingssiden som kun 11

bruker vet om. Dette er for å skjerme systemet for eventuelle hackere som prøver å knekke koden for å logge seg inn. 3.2.1 Feilsider Dersom bruker taster feil informasjon ved innlogging eller dersom andre unntakstilfeller oppstår så blir han sendt til en side med feilmelding. Dette er viktig for at systemet skal virke på en hensiktsmessig måte. 4 Planlegging og forberedelser 4.1 Valg av oppgave Jeg bestemte meg for å søke Høgskolen i Oslo om å gjennomføre dette prosjektet høsten 2010. Etter samtale med Linda Sjåstad i Hårgalleriet, satt hun meg på ideen til å lage et system som er skreddersydd for hennes behov. Det finnes allerede gode systemer på markedet, slik at min tanke var aldri å prøve å konkurrere med disse. De systemene som finnes er altfor avanserte og velutviklede for det. Jeg har derimot forsøkt å lage et system som kan være et alternativ til allerede eksiterende systemer. Det enkle er ofte det beste. 4.2 Dagens situasjon for oppdragsgiver Det finnes allerede lignende programmer på markedet i dag, men disse inneholder på hver sin måte mangler som gjør at de ikke blir tilstrekkelige. Dette skyldes at de er tilrettelagt for forskjellige bransjer. Det er derfor ønskelig å utforme ett system som tar det beste fra hver verden og smelter det sammen til et optimalt system som er skreddersydd for frisørbransjen 4.3 Analyse 4.4 Mål og rammebetingelser Målet med prosjektet er å utvikle et online bestillingssystem for frisørsalong som fungerer optimalt i henhold til bransjens krav til funksjonalitet. Oppdragsgiver hadde ingen krav til utviklingsmetodikk, programmeringsspråk eller lignende, men løsningen måtte være online basert. I tillegg bestemte jeg meg for følgende rammebetingelser: - Bruke en smidig utviklingsmetodikk til utvikling - Utvikle applikasjonen til å kjøres på internett Oppdragsgiver så først for seg en timebok som var organisert som en tidslinje hvor man kan redigere opplysninger direkte i tabellen. Dette var en veldig avansert funksjonalitet som jeg ble enig med 12

oppdragsgiver om å eventuelt implementere senere for å ikke sette meg selv i fare for å ikke komme i mål. Målet for prosjektet var følgende: - Lage et produkt som kunden ble fornøyd med - Nyskapende design - Tilpasset funksjonalitet 4.4.1 Tid Tiden jeg hadde til rådighet var fra 03.01.2011 til 31.05.2011. På denne tiden skulle jeg utvikle et system til oppdragsgiver og skrive sluttrapport. I og med at jeg har vært alene på dette prosjektet så har tid vært et kritisk moment. Jeg har hele veien vært i fare for å ikke komme i mål, og det har vært nødvendig å avgrense nøye underveis. 4.4.2 Ressurser Tilgjengelige ressurser underveise har vært intern veileder, kontaktperson, litteratur og internett. Min interne veileder sørget for at alt gikk i henhold til prosjektplanen etter hvert som prosjektet gikk sin gang. Han kom med innspill som at jeg kunne foreta testdrevet utvikling og bidro med mye faglig innspill når det gjaldt dokumentasjon og systemutvikling. 4.4.3 Kunnskap Jeg hadde gode kunnskaper i PHP programmering fra tidligere kurs med Tor Krattebøl. I tillegg har jeg studert Webapplikasjoner høsten 2010, slik at programmeringen gikk forholdsvis greit hele veien. 5 Teknologier Skriv om hvilke teknologier du har brukt - PHP - MySQL - HTML - Photoshop - Paint - Unix server - m. m 5.1 Utviklingsteknologier 5.1.1 Valg av utviklingsverktøy Jeg valgte å bruke Adobe Dreamweaver som verktøy for å skrive PHP, CSS og HTML kode. Her finnes en del ferdiglagde komponenter som enkelt kan settes inn og det finnes også en slags intellisense 13

som gjør det litt raskere å skrive kode. I tillegg så har jeg brukt dette en del før, og det var greit å slippe å sette seg inn i et nytt verktøy. 5.1.2 PHP (Hypertext Preprocessor) Jeg hadde solid kunnskap i PHP fra tidligere kurs ved HIO så denne teknologien ble et naturlig valg å velge for å programmere nettsidene. 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 og åpen versjon skrevet i C og distribuert av The PHP Group via php.net og SourceForge. (wikipedia.no, 2011) 5.1.3 MySQL Jeg har valgt å bruke MySQL som databasesystem for prosjektet. Grunnen til dette er at jeg har lært meg dette gjennom programmering i PHP. Det var uaktuelt å vurdere andre systemer fordi MySQL fungerer så bra sammen med PHP. 5.2 Andre tekniske hjelpemidler 5.2.1 Microsoft Paint Jeg trengte et program som var enkelt og raskt å bruke for å tegne skjermbilder til prototypen. Jeg testet Adobe Photoshop og MS Paint. Photoshop er et mye mer avansert program som krever forkunnskaper. MS Paint er enkelt og holdt til dette formålet. 5.2.2 MS Project Jeg brukte Ms Project for å lage fremdriftsplan for prosjektet. 14

6 Teknisk arkitektur 6.1 Applikasjonen Applikasjonen er utviklet ved hjelp av Adobe Dreamweaver og programmeringsspråket PHP. 6.2 MySQL MySQL er et relasjonsbasert databasesystem som er lisensiert under GPL (GNU General Public Licence). Dette er gratis, men er veldig populært og fungerer utmerket sammen med PHP. 6.3 Fastname Webhotell Jeg leier webhotell hos fastname.no. Jeg har registrert domenenavnet slagverker.no, og systemet kan for øyeblikket nås fra www.slagverker.no/fameit 15

7 Testing Systemet er testet kontinuerlig gjennom hele utviklingsprosessen: - Kode er testet av prosjektgruppen - Funksjonalitet er testet av oppdragsgiver - Kontinuerlige tilbakemeldinger - Iterativ utvikling 16

Vedlegg 1 Kravspesifikasjon Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER Frisør for Hårgalleriet, Linda Sjåstad KONTAKTPERSON Linda Sjåstad 17

1 Innledning 1.1 Innledning Prosjektet skal gjennomføres som hovedprosjekt ved HIO avdeling for ingeniørutdanning i samarbeid med frisør Linda Sjåstad i Hårgalleriet. Oppgaven består i å utvikle et bestillingssystem for frisørsalong som er optimalt tilpasset bransjen, og som kan administreres av de ansatte. Systemet vil utvikles ved bruk av PHP og MYSQL. 1.2 Om bedriften Hårgalleriet holder til på Hønefoss kjøpesenter (Kuben) og har også en avdeling i sentrumskvartalet på Hønefoss. Bedriften består av 7 ansatte som til daglige er spredd mellom de to avdelingene. Salongen tilbyr behandling innen alle områder av faget. Systemet leveres primært til frisør Linda Sjåstad, men dersom det er interesse blant de andre så kan det være aktuelt at salongen tar i bruk systemet. 1.3 Bakgrunn for prosjektet Det har vært uttrykt frustrasjon av de ansatte over eksisterende systemer på markedet i dag. Det eksisterer to store leverandører av systemer for frisørbransjen. Det er ønskelig å lage et system som tar det beste fra hvert av disse eksisterende systemer og tilpasser det til de krav og forventninger som frisørbransjen har til et IKT system. 18

2 Forord Denne kravspesifikasjon beskriver betingelsene for prosjektet Bestillingssystem for frisørsalong. Det beskrives hva slags funksjonalitet systemet skal inneholde og hva slags teknologi som vil bli benyttet. I tillegg beskrives krav til utseende. Det er også ytret ønske fra oppdragsgiver om hvordan layouten på systemet skal være. Krav til den tekniske løsningen vil bestemmes av prosjektgruppen. 19

3 Innholdsfortegnelse 1 Innledning... 2 1.1 Innledning... 2 1.2 Om bedriften... 2 1.3 Bakgrunn for prosjektet... 2 2 Forord...3 3 Innholdsfortegnelse...4 4 Systemkrav...5 4.1 Funksjonskrav... 5 4.2 Tilleggsfunksjoner... 6 4.3 Tekniske krav... 7 4.4 Data lagring... 7 5 Krav til Design...7 6 Krav til kode...8 7 Krav til dokumentasjon...8 8 Utvidelser...8 8.1 Eventuelle utvidelser... 8 20