Båtforening på nett. Prosessrapport

Transkript

1 Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Prosessrapport

2 1 Sammendrag Hovedprosjektet gjennomføres våren 2009 som en del av utdanningen ved Høgskolen i Oslo, avdeling for ingeniørutdanning. Prosjektet går ut på å planlegge og utvikle en webside for bruk av ansatte, medlemmer, styret, gjester osv. i båtforeninger. Bonefish.no gjorde i 2005 et forprosjekt og en pilotside for en båtforening denne ble tatt meget godt imot, men er nå utdatert og derfor er det ønskelig å utvikle en slik webside på nytt og tilby denne til flere båtforeninger. Side 2

3 2 Forord Denne rapporten omhandler hovedprosjektet for gruppe 36 og hvordan arbeidsprosessen i dette prosjektet har vært. Denne hovedprosjektoppgaven kom i stand gjennom bedriften Bonefish.no. Samarbeidet med denne bedriften startet ved at et medlem av prosjektgruppen vår kontaktet Bonefish.no og forhørte seg om muligheten for å gjennomføre et hovedprosjekt. Prosjektgruppen ble satt sammen av tre studenter fra forskjellige studieretninger ved IU. En fra dataingeniør, en fra Informasjonsteknologi og en fra Anvendt Datateknologi. Denne sammensetningen gjorde gruppen allsidig og interessant, samtidig som den garanterte en prosjektgjennomføring med forskjellige synspunkter, interesser og forutsetninger. Gruppe 36 Båtforening på nett Side 3

4 3 Innhold 1 SAMMENDRAG FORORD INNHOLD INNLEDNING PLANLEGGING OG METODE Valg av prosjekt Forprosjekt Fremdriftsplan Arbeidsmetode Fase Fase Fase Prosjektdagbok Prosjektrutiner Timelister Risikostyring Prosjektverktøy UTVIKLINGSPROSESSEN Innledende utvikling Selve utviklingsfasen Backlog Filstruktur og oppbygning Sikkerhet Utseende og design Testing Faglige utfordringer Oppdragsgiver Prosjektgruppa AVSLUTNING Hva har vi lært Konklusjon Side 4

5 8 KILDEHENVISNING Internett Bøker Side 5

6 4 Innledning Dette hovedprosjektet gjennomføres våren 2009 som en del av utdanningen ved Høgskolen i Oslo, avdeling for ingeniørutdanning. Prosjektet går ut på å planlegge og utvikle en webside for bruk av ansatte, medlemmer, styret, gjester osv. i båtforeninger. Bonefish.no gjorde i 2005 et forprosjekt og en pilotside for en båtforening denne ble tatt meget godt imot, men er nå utdatert og derfor er det ønskelig å utvikle en slik webside på nytt og tilby denne til flere båtforeninger. I dag har nettsiden innloggingsfunksjon for medlemmer, nyheter, og gjestebok. Medlemmer kan skrive i gjestebok, kontakte administrator, lese nyheter, få informasjon om været og veikart osv. Registrering av nye medlemmer gjøres av lokal administrator. Det legges vekt på at løsningen skal være mest mulig brukervennlig. En bruker uten forkunnskaper skal kunne benytte seg av all den funksjonalitet websiden byr på. Bonefish.no er en liten bedrift som designer og utvikler brukervennlige websider for administrering og publisering av innhold. Systemene benyttes av små og store virksomheter med ulike behov for kommunikasjon via web og andre digitale kanaler. I tillegg til å utvikle nettsider og innhold kan bedriften bidra med tjenester som profilering, systemutvikling, rådgivning og veiledning, samt kommunikasjonsløsninger. Systemet vi har lagd har blitt utviklet på Bonefish sin server og vi har benyttet programmeringsspråk som PHP, HTML, CSS og JavaScript. I tillegg har vi benyttet MySQL som databasesystem. Rettighetshaver til ideen og prosjektet er ESJ Invest v/ Erik Jagland. Side 6

7 5 Planlegging og metode 5.1 Valg av prosjekt Veien til det endelige prosjektet var lengre og litt mer kronglete enn forventet. Prosjektet var ennå ikke klart da prosjektskissene skulle leveres 5. desember Prosjektgruppen var heller ikke dannet, og det var den heller ikke da gruppemedlem Frode innledet samtaler med Bonefish tidlig i desember angående prosjektet. Etter at Erik Jagland hadde presentert ideen om prosjektet, startet arbeidet med å få dannet den endelige prosjektgruppen. Vegard og Frode hadde jobbet sammen tidligere med et prosjekt i faget Universell Utforming, og dannet 5. januar prosjektgruppen. Til sist kom det endelige gruppemedlemmet Rade også til. Kort tid etter hadde gruppen sitt første møte med oppdragsgiver hvor grunntanken bak prosjektet, førsteutkastet til kravspesifikasjonen og tekniske utfordringer ble lagt frem. På dette møtet ble det klart at dette ble vårt hovedprosjekt. Vi satte umiddelbart i gang med prosjektskissen som var første innlevering. 5.2 Forprosjekt Etter at prosjektskissen ble godkjent, kunne vi begynne arbeide med forprosjektet. Vi lå allerede litt bak forventet fremdrift ettersom det hadde tatt litt tid å få organisert gruppe og prosjekt. En grov analyse over hva som skulle utvikles og hva som eventuelt måtte nedprioriteres ble utført i samarbeid med oppdragsgiver slik at vi etterhvert fikk fullstendig oversikt over prosjektets omfang. Etter presentasjonen av prosjektet fra oppdragsgiver var vi blitt klar over at noen av oss måtte tilegne seg noe ny teknologi. Vegard som har gått Informasjonsteknologi hadde et vesentlig bedre utgangspunkt for webprogrammering enn Rade og Frode. Vi måtte sette oss ordentlig inn i PHP, SQL og JavaScript. For Frode som har gått Anvendt Datateknologi var selve prosjektprosessen en like stor del av prosjektet som webprogrammeringen, på grunn av forkunnskapene. Vi bestemte oss også for å benytte oss av systemutviklingsmetoden Scrum, som vi følte passet best til vår utvikling. Allerede i forprosjektperioden begynte vi med enkel systemutvikling og noe programmering. PHP var litt vanskelig i starten for noen av oss, og tok litt mer tid en forventet. Men med hint og tips fra oppdragsgiver og gruppemedlem Vegard gikk det etterhvert lettere. Forprosjektet la til slutt grunnlaget for forprosjektrapporten, som er lagt ved prosjektets sluttrapport som et vedlegg. Side 7

8 5.3 Fremdriftsplan Under arbeidet med forprosjektrapporten ble vi fort enige om at vi trengte en fremdriftsplan å forholde oss til gjennom prosjektet. Den skulle inneholde de milepælene vi så for oss samt en dato for ferdigstilling av disse. Utformingen av denne planen ble gjort med utgangspunkt i kravspesifikasjonen fra oppdragsgiver og det ble lagt stor vekt på at planen skulle være veiledende, og behandles som et levende dokument. Det var ikke alle milepælene som ble nådd til fristen som var sagt. Blant annet hadde vi satt fristen for ferdig utviklet løsning til 30. april, for å sette fokus på rapportskriving den siste tiden. Dette gikk ikke i orden, og vi holdt på med finpuss av løsningen til et godt stykke ut i mai. Fremdriftsplanen ble en del av forprosjektrapporten, og er lagt ved denne sluttrapporten som et vedlegg. 5.4 Arbeidsmetode Som utviklingsmetodikk valgte vi å benytte oss av Scrum-metoden. Dette er en populær utviklingsmetodikk som ofte blir brukt i dag. Den er iterativ, og det gjør det enkelt å gjøre endringer underveis. Metoden gir også et godt grunnlag for fortløpende og kontinuerlige oppdateringer på hvordan man ligger an i utviklingen, noe som gjør det veldig lett for oppdragsgiver og prosjektdeltakere å måle prosjektets fremdrift. I henhold til denne metodikken er det ikke krav om spesifikasjoner eller detaljert planlegging av arbeidsoppgavene i prosjektgjennomføringen. Allikevel valgte vi altså å sette opp en fremdriftsplan for å visualisere en del av prosjektets forestilte milepæler. Vi brukte denne metoden kun i utviklingsdelen av prosjektet. Mot slutten av prosjektet var det stort sett rapportskriving og sluttføring som stod i fokus. Som vi skrev i forprosjektrapporten så vi for oss tre forskjellige arbeidsfaser som stilte forskjellige krav til arbeidsmetodene Fase 1 (varighet 1 måned) Begynte med forprosjektrapporten og arbeidet videre med kravspesifikasjonen. Andre halvdel av denne fasen gikk blant annet med til prototyping, oppsett av ikke funksjonelle krav og utvelgelse av hvilke arbeidsverktøy prosjektgruppen skulle benytte seg av. Da forprosjektrapporten ble levert inn, følte vi oss klare til å starte utviklingen og det virkelige prosjektarbeidet. Vi var godt fornøyd med jobben som var gjort frem til da, og hadde fått gode tilbakemeldinger fra oppdragsgiver. Side 8

9 5.4.2 Fase 2 (varighet 3 måneder) Dette var selve utviklingsfasen hvor selve produktet vårt ble til. Her jobbet vi i ukessprinter og med utgangspunkt i Scrum-metoden. Programmoduler ble utviklet og arbeidet med, testet og evaluert i en- eller to-ukers perioder, som illustrert på tegningen under. Denne fasen bestod av mye individuelt arbeid med modulene man hadde ansvaret for, men også ukentlige møter hvor løsninger ble evaluert og hvor gruppemedlemmene kunne hjelpe hverandre Fase 3 (varighet 1 måned) I denne fasen ble det satt fokus på rapportskriving og teknisk etterarbeid på produktet. Selve løsningen var stort sett klar, men det ble gjort en del endringer i forhold til rent design og utseende. Det ble også avholdt møter med både oppdragsgiver og veileder for å forsikre oss om at prosjektet var i rute og at produktet holdt mål. Side 9

10 5.5 Prosjektdagbok Prosjektdagboken er blitt ført hver dag hvor vi har hatt samlet gruppeaktivitet i form av nettmøte eller møte på skolen. Dagboken har vært svært nyttig for utformingen av selve sluttrapporten og evalueringen av gruppens arbeid. Den gir en god oversikt over ting som har skjedd gjennom prosjektperioden, og arbeidet som har blitt gjort. Selve prosjektdagboken er ikke en selvstendig del av prosessrapporten, men er kun ment som et internt styringsdokument. Dagboken ligger derfor tilgjengelig på hovedprosjektets hjemmeside. 5.6 Prosjektrutiner Prosjektgruppen ble tidlig i dette prosjektet enige om å ta utgangspunkt i en rytme på ett møte i uken i tillegg til den individuelle utviklingen. Disse møtene ble stort sett avholdt torsdag morgen, for å evaluere sist ukes arbeid samt å fordele den kommende ukens oppgaver. I tillegg til dette faste møtet på skolen, hadde vi ofte nettmøter, hvor gruppen kommuniserte over MSN(Windows Live Messenger). Vi hadde ikke noen faste tider for møte med oppdragsgiver, men avtale hvert enkelt møte for seg. Samme ordning gjaldt med veileder Steinar Johannesen. 5.7 Timelister Prosjektgruppen har under hele tiden ført timelister på prosjektets hjemmeside. Bakgrunnen for dette er et ønske om å visualisere for gruppen hvem som har gjort hva, og om det eventuelt er store forskjeller i arbeidsbelastningen for prosjektmedlemmene. Timelistene ble ført elektronisk ved hjelp av gruppens hjemmeside. Etter så godt som fullført prosjekt eksisterte det ingen store forskjeller blant prosjektmedlemmene. Timelistene faller inn under kategorien styringsdokumenter, og er således ikke publisert som en del av denne rapporten. Utarbeidet arbeidsstatistikk er derimot lagt ved rapporten som et vedlegg. Side 10

11 5.9 Risikostyring I samtlige prosjekter denne gruppen har gjennomført på HiO har vi blitt oppfordret til å utforme en risikovurdering for det aktuelle prosjektet. Vi ble derfor raskt enige om å gjøre det også i hovedprosjektet vårt. Denne vurderingen er utarbeidet på bakgrunn av samtaler innad i gruppen og erfaring fra tidligere prosjekter. Risiko Sannsynlighet Følger Strategi Sykdom 25 % Andre i gruppen må ta mer ansvar for ting som opprinnelig ikke var deres område. Tap av data 5 % Arbeid må gjøres på nytt, og kan sette tidsfrister i fare. Konflikter i gruppen 10 % Dårlig stemning fører til svakere arbeidsmoral og samarbeidsevne i gruppen. God kommunikasjon. Hele gruppen må ha mulighet og kunnskap til å støtte de andres arbeid ved sykdom. Strenge backup-regler, og gode rutiner på dokumentdeling i gruppen. Arbeidskontrakt og et inkluderende arbeidsmiljø. Dårlig forståelse av prosjektets omfang. Endring i kravspesifikasjon fra oppdragsgiver Forsinkelser hos oppdragsgiver, skolen eller andre utenforstående som skal hjelpe med prosjektet. Tidspress og i overkant mye arbeid rett før innlevering 15 % Arbeidet blir mer omfattende enn først antatt og deadline blir dermed vanskeligere å overholde. 10% Planlegging og ekstraarbeid må gjøres unna og vil koste tid og innsats. 15% Fører til venting og frustrasjon i gruppen, og fører til en stresset arbeidssituasjon. 20% Kan føre til et stresset arbeidsmiljø, slurvete arbeid og halvveis-løsninger. Solid forarbeid, god kommunikasjon og gode arbeidsrutiner er viktig. Oppdragsgiver er meget klar på kravspesifikasjonen og dersom det blir endringer vil disse være av liten skala og forårsake få problemer. God kommunikasjon med alle instanser, og evnen til å stille krav på gruppas vegne. Lage solide arbeids- og fremdriftsplaner, og overholde fristene som er satt i disse. Risikoanalysen gjorde oss bevisste på ting som kunne spille en rolle i prosjektet, og satte ting som for eksempel gode backup-rutiner og intern kommunikasjon formelt på dagsorden. Side 11

12 5.10 Prosjektverktøy Windows Live Messenger: Kommunikasjonsprogram for tekstbaserte samtaler over nettet, brukt til planlegging, nettmøter og annen prosjektrelatert kommunikasjon. NetBeans IDE 6.5: Utviklingsplattform for nettbaserte løsninger som forenkler koding og programmering. Microsoft Excel: Brukt til å lage dokumenter som fremdriftsplan, risikoanalyse og andre interne arbeidsdokumenter. Microsoft Word: Tekstbehandlingsprogram, brukt for å skrive sluttrapporter, møtereferater og prosjektdagboken. HTML 4.01 Transitional: Markeringsspråk for formattering av nettsider. Joomla: Publiseringsverktøy for nettsteder. Brukt til å utvikle og administrere prosjektets hjemmeside. Core FTP Lite: Ftp-program for deling av filer. Brukt til å logge på oppdragsgivers server slik at utviklingen av modulene og nettsiden kunne gjøres Side 12

13 phpmyadmin: PHP-programmert databaseverktøy. Brukt til å administrere prosjektets database. PHP 5.2: Webprogrammeringsspråk MySQL : SQL-basert databaseadministrasjonssystem. Apache Debian: Open-source webserver-program Side 13

14 6 Utviklingsprosessen 6.1 Innledende utvikling Den innledende utviklingen startet allerede under arbeidet med forprosjektet. Da ble det jobbet med databaseskisse, low-fidelity prototype og enkle forslag til design. Ut i fra kravspesifikasjonen vi hadde fått fra oppdragsgiver hadde vi klart for oss hva som skulle gjøres. Etter innlevering av forprosjektrapporten fortsatte denne innledende utviklingen en liten periode. Her møtte prosjektet sin første store utfordring, i form av sykdom hos oppdragsgiver. Vår kontaktperson i Bonefish, Erik Jagland, ble syk og var sykemeldt i en periode ca. en måned. Dette medførte at gruppen først fikk server- og databasetilgang i midten av mars, noe som forsinket utviklingen vår ganske drastisk. 6.2 Selve utviklingsfasen Vi kom jo på grunn av oppdragsgivers sykdom veldig sent i gang med vår planlagte utvikling, og det kostet gruppa en del tid til utvikling. Vi vurderte fortløpende å endre kravspesifikasjonen i forhold til tapt tid, men valgte å beholde den originale utgaven. Så snart server- og databasetilgang var på plass, kom gruppen endelig i gang med utvikling i henhold til de rutiner som var fastsatt og basert på scrum-metoden. Vi hadde så noen gode møter med oppdragsgiver som var en god støtte for oss. I disse møtene ble ferdige moduler fremvist og evaluert av oppdragsgiver. Dette ga oss en god kvalitetssikring av løsningene vi hadde utviklet. Modulene for nettstedet ble utviklet, evaluert og testet uke for uke, og etterhvert begynte det å likne en ferdig løsning. På de ukentlige møtene ble løsningene sydd sammen og problemer ble løst i fellesskap. Her skylder gruppen en stor takk til gruppemedlem Vegard Skipnes, som har tatt hovedstøyten når det gjelder å få de forskjellige modulene til å fungere som en samkjørt løsning. Side 14

15 6.3 Backlog I begynnelsen av utviklingsprosessen satte gruppen opp en prioriteringsliste for å fastslå hvilke funksjoner som måtte på plass og hva som eventuelt kunne nedprioriteres. Denne listen er det man i Scrum-metoden kaller en backlog. Backloggen fungerer som et styringsdokument for utviklingen og ble behandlet som et levende dokument. Vi hadde flere møter underveis i prosjektet for å korrigere backloggen opp i mot utviklingens fremdrift. Oppdragsgiver var med på flesteparten av disse møtene for å holde seg oppdatert på prosjektet og for å forsikre seg om at systemet ble utviklet i tråd med bedriftens ønsker. Oppgave Prioritering Grunnskisse m/prototype 1 Gjestebok 2 Innloggingstjeneste 2 Medlemsliste med kontaktinfo 2 Templates 3 Kontaktskjema 3 Nyhetsside 4 Administratormeny 5 Om Båtforeningen(Infoside) 6 Værmelding 6 Kart 7 Søkemuligheter Aktivitetskalender Bildegalleri Dette er den endelige backloggen, med modulene satt opp i forhold til prioritet. Listen er i denne rapporten sortert etter denne prioriteringen for enkelhets skyld. Disse prioriteringene er endelige, og de tre nederste modulene ble til slutt bortprioritert fra prosjektet av oppdragsgiver. Side 15

16 6.3 Filstruktur og oppbygning Før selve utviklingen startet hadde vi allerede tatt en avgjørelse på hvordan systemet skulle bygges opp og hvordan filstrukturen skulle se ut. Momenter vi ville prioritere under utviklingen var oversiktlighet, enkelhet og forutsigbarhet i forhold til plassering av filer og moduler. Vi ente opp med en filstruktur helt i tråd med den vi hadde sett for oss. Systemet består nå av tre hovedmapper: Den største hovedmappen er mappen Moduler, som inneholder alle de forskjellige funksjonene som løsningen tilbyr. Denne oppbygningen er meget enkel og oversiktlig, og er på den måten meget godt tilrettelagt for en videreutvikling og påbygning av systemet. Mappen System med for eksempel databasetilkobling og andre felles funksjoner for systemet. Mappen Templates inneholder filer som genererer løsningens utseende og generelle layout. 6.4 Sikkerhet Løsningen og alle modulene er passordbeskyttet og tilbyr også flere brukernivåer, for eksempel registrert, publiserer, manager eller systemadministrator. Sikkerheten i dette systemet er i stor grad det samme som den forrige løsningen som bonefish.no utviklet. I kravskissen fra oppdragsgiver var det ikke spesifisert noen sikkerhetskrav bortsett fra en enkel innloggingsfunksjon. Derfor har dette heller ikke vært en veldig stor prioritering fra gruppens side. Brukere logger nå inn på løsningen ved å oppgi epost-adresse samt en automatisk generert pin-kode som de får tilsendt når de blir lagt til som brukere i medlemslisten. Det eksisterer ingen krypteringsfunksjoner rundt denne pin-koden, og den blir sendt ukryptert til brukerne og lagret ukryptert i systemdatabasen. Dette er i utgangspunktet en svakhet, men har som tidligere nevnt ikke vært noen prioritet for prosjektgruppa. Dette har også blitt diskutert og belyst i møter med oppdragsgiver, som aldri har hatt dette som en høy prioritet. Side 16

17 6.5 Utseende og design Når det gjelder løsningens utseende var det hele tiden et usikkerhetsmoment. Prosjektgruppen ble forespeilet noen templates-eksempler fra oppdragsgiver for å bruke i løsningen. Dette hadde gitt oss et klart, visuelt bilde av hvordan oppdragsgiver så for seg at nettsiden kunne se ut. På grunn av oppdragsgivers sykdom fikk gruppen aldri noen templates, og dette satte press på oss for å komme frem til et design på egen hånd. Men etterhvert som funksjonaliteten på løsningen økte kom vi også nærmere og nærmere en endelig avgjørelse på hvordan siden skulle se ut. Våre ideer ble lagt fram for oppdragsgiver og godkjent med kun noen få, mindre endringer. 6.6 Testing Testing av systemet er helt vesentlig under utviklingen av en løsning tilsvarende den vi har laget. Grundig testing av systemet både som helhet og av systemets enkelte moduler gir utviklerne en god tilbakemelding på hva som fungerer bra og hva som eventuelt må utbedres. Vi testet de enkelte modulene i løsningen som enkeltløsninger så snart de var ferdige, og etterhvert som de ble integrert i totalløsningen. Testingen ble utført internt i prosjektgruppa, og hele gruppen var involvert i samtlige tester. Etter at systemet var ferdig og klar for levering gjennomførte vi en endelig test for å forsikre oss om at løsninger er funksjonibel og brukervennlig. Det er denne testen som danner grunnlaget for testrapporten. 6.7 Faglige utfordringer Som tidligere påpekt ble det raskt klart at noen av medlemmene i denne prosjektgruppen ikke hadde de beste forutsetningene for å gjennomføre en oppgave som denne. Det ble satt av tid til læring og prøving av webprogrammering i begynnelsen av prosjektet, og mye av tiden som gikk tapt pga. oppdragsgivers sykdom ble også brukt til egenstudier innen PHP, CSS og MySQL. En viktig del av hovedprosjektet er dokumentasjonen som skal følge med. På HiO har vi erfart at dette vektlegges i alle fag og prosjekter vi har vært involvert i, men behovet er kanskje ikke så stort i de mindre oppgavene som er skrevet. Hovedprosjektet er derimot såpass stort og går over så lang tid at dokumentasjon av både utviklingen og prosessen underveis er særdeles viktig. Det virker som et ork å dokumentere alt underveis, spesielt ettersom styringsdokumentene ikke er en del av den endelige leveransen, men rapportene som leveres inn på slutten av dette hovedprosjektet kunne aldri blitt lagd dersom ikke styringsdokumentene hadde blitt prioritert slik de har. Side 17

18 6.8 Oppdragsgiver I prosjekter som dette med en oppdragsgiver og en ekstern prosjektgruppe er det særdeles viktig at forholdet dem imellom prioriteres og at det er åpen kommunikasjon dem imellom. Dette er kritisk for å få prosjektet til å fungere optimalt. Vårt prosjekt ble som tidligere nevnt litt lammet en periode i februar og begynnelsen av mars, ettersom vår oppdragsgiver ble sykemeldt og ikke var tilgjengelig for oss. Dette skapte usikkerhet hos oss som gruppe, men ble til slutt en nyttig erfaring. Vi ble nødt til å ta flere initiativ på egen hånd og fikk erfare hvordan et prosjekt faktisk i verste fall kan falle sammen dersom ting som dette ikke løses. I vår risikoanalyse hadde vi nemlig ikke tatt høyde for sykdom og fravær hos oppdragsgiver, bare internt i gruppa. Nå skal det sies at totalopplevelsen av å jobbe med Bonefish.no og Erik Jagland har vært positiv, og Erik har etter at han var tilbake vært til god hjelp for gruppen. Side 18

19 6.9 Prosjektgruppa Gruppen vår ble som tidligere nevnt dannet på en litt tilfeldig måte. Vegard og Frode hadde jobbet litt sammen tidligere i et annet fag på HiO, mens Rade ikke hadde jobbet med noen av gruppens medlemmer. Det eksisterte ingen avtale om å jobbe sammen på hovedoppgaven mellom Vegard og Frode, men etter at Frode hadde vært på et innledende møte med Erik Jagland, kom Vegard med. Kort tid etter tok Rade kontakt og lurte på om han kunne være en del av prosjektet. Alle tre medlemmene har tatt forskjellige utdannelser på HiO. Vegard har gått Informasjonsteknologi, Rade har gått på Dataingeniør og Frode har tatt Anvendt Datateknologi. Dette gir tre helt forskjellige forutsetninger for prosjektarbeidet og har vært en kilde både til frustrasjon, men også inspirasjon i form av flere forskjellige synspunkter og innstilling til arbeidet. Det at ingen av oss tre kjente hverandre spesielt godt før prosjektets start har også hatt både positiv og negativ innvirkning på gruppa. Positiv i den forstand at man blir kjent med nye mennesker og lærer nye ting, negativ på den måten at man ikke kjenner hverandres arbeidsvaner og stil. Gruppen har imidlertid vært klar over utfordringene knyttet til dette, og har hele tiden vært åpne med tanke på tilbakemeldinger og kommunikasjon. Side 19

20 7 Avslutning 7.1 Hva har vi lært Når vi nå har avsluttet arbeidet med vårt hovedprosjekt, er det naturlig å reflektere litt over hva som er gjort og hva vi eventuelt står igjen med. Hva har dette prosjektet gitt oss av faglig input, og har vi fått brukt mye av den kunnskapen vi har tilegnet oss i løpet av 3 år på HiO. Vi på gruppa er enige om at arbeidet med dette prosjektet har vært veldig relevant i forhold til tidligere prosjekter og kurs vi har gjennomført. Det er hovedsaklig tre fagfelt vi har jobbet med i dette prosjektet; prosjektarbeid og ledelse, webprogrammering og rapportskriving/dokumentering. Webprogrammering har helt klart vært det feltet hvor vi har hatt størst potensial og hvor vi har lært mest de siste månedene. Inngående bruk av PHP, HTML og MySQL har gitt oss en klart bredere kompetanse enn ved prosjektstart. Prosjektarbeid og ledelse er noe vi har kommet borti i så godt som alle gjennomførte kurs og fag ved HiO. Det er et enormt utfordrende og spennende fagfelt, og det er interessant å se at selv om retningslinjer og inngangsverdier for et prosjekt ofte er de samme, blir dynamikken, arbeidsvanene og ledelsen aldri helt lik. Det menneskelige aspektet ved prosjektarbeid er minst like interessant og viktig som den tekniske biten. Rapportskriving og dokumentasjon er også noe som man i løpet av 3 år som student på HiO har fått en viss rutine på. Men som tidligere nevnt er det sjelden vi som studenter er med på såpass store prosjekter som dette har vært. Og spesielt på grunn av prosjektets omfang og størrelse, har dokumentasjonen underveis vært enormt viktig og lærerikt. I et lite prosjekt på et par uker er ikke styringsdokumentasjonen like viktig og fremtredende, men det har blitt helt klart for oss at dette er en stor del av et prosjektarbeid. Side 20

21 7.2 Konklusjon Etter et helt semester med jobb kan vi nå presentere det ferdige produktet. Det har vært en lang vei, fra det første møtet mellom oppdragsgiver og Frode i desember 08 til sluttføring av rapportene sent i mai 09. Det har som forventet vært veldig mye jobb med dette prosjektet, og det har vært perioder hvor vi faktisk har lurt på om vi skulle komme i mål med alt. Vi har fra å være tre personer som kom sammen for å fullføre hovedprosjektet, blitt et team hvor alle bidrar og kommuniserer godt med hverandre. Det er alltid gøy å se hvordan et vellykket prosjekt binder folk sammen og bidrar til nye og gode relasjoner. Helt til slutt i denne rapporten vil vi benytte anledningen til å takke vår oppdragsgiver Erik Jagland, representant for Bonefish.no. Han har vært til stor hjelp for oss. Vår veileder, Steinar Johannesen, skal også ha en takk for å ha kommet med nyttige innspill i forbindelse med prosjektet vårt. Gruppe 36 Ingeniørutdanningen, Høgskolen i Oslo 22. Mai, 2009 Side 21

22 8 Kildehenvisning 8.1 Internett Generell informasjon Kode benyttet på nettsiden Server Programmering CSS Scrum &ei=FKB0SZWtNovKiQLxxPizBQ&q=scrum&hl=no Side 22

23 8.2 Bøker Horgen, S.A., 2003 Webprogrammering i PHP Gyldendal akademiske og Tisip. Gutmans, A., Bakken, S.S. og Rethans, D., 2004 PHP 5 Power Programming Prentice Hall. Negrino, T. og Smith, D., 2007 JavaScript & Ajax Peachit Press. Castro, E., 2003 HTML for the world wide web Peachit Press. Adams, C. med flere, 2007 The Art & Sciens of CSS Sitepoint Pty. Ltd. Andrew, R., 2007 The CSS anthology Sitepoint Pty. Ltd. Kristoffersen, B., 2007 Databasesystemer Universitetsforlaget AS. Gurholt, G. og Hasle, T.E., 2003 Grunnleggende systemutvikling J.W.Cappelens Forlag as. Torvatn, Ann-Mari, 2007 Dokumentstandard for hovedprosjekter ved HiO Seksjon for data- og allmennfag, IU, Høgskolen i Oslo Side 23