Båtforening på nett. Prosjektrapport

Transkript

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

2 PROSJEKT NR Studieprogram: Ingeniør/informasjonsteknologi/Anvendt Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Båtforening på nett DATO 29/05/2009 ANTALL SIDER / BILAG 92 PROSJEKTDELTAKERE Frode Sørensen, s Vegard Skipnes, s Rade Vuckovic, s INTERN VEILEDER Steinar Johannesen OPPDRAGSGIVER Bonefish KONTAKTPERSON Erik Jagland 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. Siden skal være enkel og lett anvendelig. 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. 3 STIKKORD Webutvikling Båtforening PHP

3 Forord 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. Vi vil benytte anledningen til å takke vår oppdragsgiver Erik Jagland, representant for Bonefish. 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 Rade Vuckovic Vegard Skipnes Frode Sørensen

4 Innhold 1. Prosessrapport 2. Produktrapport 3. Brukerveiledning 4. Testrapport 5. Vedlegg: 1. Forprosjektrapport 2. Statusrapport 3. Arbeidsstatistikk

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

6 Prosessrapport 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

7 Prosessrapport 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

8 Prosessrapport 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

9 Prosessrapport 8 KILDEHENVISNING Internett Bøker Side 5

10 Prosessrapport 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

11 Prosessrapport 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

12 Prosessrapport 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

13 Prosessrapport 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

14 Prosessrapport 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

15 Prosessrapport 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

16 Prosessrapport 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

17 Prosessrapport 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

18 Prosessrapport 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

19 Prosessrapport 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

20 Prosessrapport 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

21 Prosessrapport 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

22 Prosessrapport 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

23 Prosessrapport 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

24 Prosessrapport 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

25 Prosessrapport 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

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

27 Prosessrapport 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

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

29 Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet til gruppe 36 våren Det kan være av interesse, for å kunne lettere skjønne hvorfor vi har laget systemet slik som det har blitt, å lese prosessrapporten før du leser denne rapporten. I denne rapporten vil du få en oversikt over hvordan systemet er oppbygd. Dvs. mappe og filsturkturen på nettsiden og hvordan du kan benytte deg av det for å lage egne utvidelser til systemet. Vi vil også kort komme inn på hva brukeren ser. For nærmere informasjon om hvordan nettsiden fungerer henviser vi til brukerveiledningen som er laget til nettsiden. Dette dokumentet er beregnet på utviklere og eventuelt systemadministratorer, og er derfor lagt opp slik at leseren bør ha kunnskap om PHP/programmering, HTML, CSS, JavaScript, og hvordan en Apache webserver fungerer. Side 2

30 Produktrapport 2 Beskrivelse av systemet Vi har laget en nettside som skal være enkel å bygge ut og kopiere til andre nettsteder. Vi har bygget systemet fra bunnen av og har dermed laget et sett med regler som man bør, som systemadministrator, være klar over for å kunne utnytte systemets potensiale. Man kan si at systemet vi har laget er et enkelt CMS-system. CMS står for Content Management System, altså et system for styring av innhold. Et slik system er ofte populært å ha på større nettsider. Et kjennetegn på et CMS-system er at brukergrensesnittet er laget slik at man ikke behøver å kunne kode for å publisere innhold. Hele idéen med systemet er at man enkelt skal kunne utvide og utvikle systemet videre. Vi vil i slutten av dette dokumentet gå mer konkret inn på hvordan du kan opprette en ny nettside med systemet og momenter som da må prioriteres. Side 3

31 Produktrapport 3 Innhold 1 Sammendrag Beskrivelse av systemet Innhold Teknologi Programmeringsspråk Database Server Presentasjon Utviklingsmetodikk Sikkerhet Tilgjenglighet Innloggingsinformasjon Websidens oppbygning htaccess Oppbygging Moduler System Template Filstuktur Moduler System Template Database mod_gjestebok mod_infoside mod_kategorier mod_medlemmer mod_nyheter Kravspesifikasjon Opprinnelige systemkrav Systemet i dag Hvordan opprette et nytt nettsted med dette systemet? Systemkrav Steg-for-steg Side 4

32 Produktrapport 4 Teknologi 4.1 Programmeringsspråk PHP er et programmeringsspråk tilpasset for å lage dynamiske nettsider. Dette kjører direkte på server, og man skriver kun ut HTML-kode som blir oversent til klientens PC. Det var et krav fra vår oppdragsgiver at vi skulle benytte PHP, derfor vurderte vi ikke alternativer. All logikk i vårt prosjekt er derfor skrevet i dette språket. Vi benyttet PHP versjon 5.2 (den siste versjonen). Den støtter bl.a. objektorientert programmering mye bedre enn tidligere versjoner. Den håndtere også bedre XMLgjennomgang ved bruk av en utvidelse kalt "SimpleXML". Dette er forbedringer som vi i liten grad har benyttet oss av i dette prosjektet. Filene forventes derfor også å kunne fungere på servere med tidligere versjoner av PHP. Av sikkerhetsmessige årsaker har vi valgt å skrive de aller fleste av PHP-filene med endelsen.inc (ikke.php som er vanlig) og disse blir kun inkludert i andre filer. 4.2 Database MySql er et Sql-basert ("strukturert spørrespråk") database. Kildekoden er tilgjengelig, men det eies av Sun Microsystems og all utvikling drives av de. MySql kan kjøreres på mange forskjellige servere og det er mange språk som kan koble seg opp til databasen enkelt. Vi tør påstå at MySql er den mest brukte databaseløsningen som er fritt tilgjengelig. Det er et krav fra Bonefish at vi skal benytte MySql i dette prosjektet, og dette syntes også gruppen var et fornuftig valg. Vi har ikke opplevd problemer med dette valget under prosjektet. Konkret hvilke tabeller vi satte opp finner du senere i denne rapporten. 4.3 Server Vi har benyttet Apache webserver (Debian) for utvikling og testing i dette prosjektet. 4.4 Presentasjon Vi har benyttet forskjellige tekonologier til å presentere dataen. HTML (4.01) er en defacto standard for visning av nettsider og alt vises i dette språket. Egne CSS-filer benyttes i størst mulig grad, i tillegg har vi benyttet JavaScript i noen utvalgte tilfeller. 4.5 Utviklingsmetodikk Vi benyttet Scrum som utviklingsmetodikk for prosjektet. For å få muligheten til å gjøre det var vi avhengig av å lage et fleksiblet system hvor det er lett å utvikle bit-for-bit. Arbeidsmetoden har vært avgjørende for utviklingen av dette produktet. Side 5

33 Produktrapport 4.6 Sikkerhet Vi har bygget systemet for å kunne være mest mulig sikkert i forhold til å ta over innhold på nettsiden (sikkerhet mot Cross-site scripting). En viktig del er å skjule hvor filene egentlig ligger. Dette gjør vi ved å benytte en.htaccess-fil. Den omdirigerer forespørselene fra URL til riktig fil. Alle forespørsler som ikke er korrekte blir rutet til forsiden. Systemet har også en del klare svakheter. Ved innlogging så kreves det kun fire siffer som passord. Dette blir et svakt passord. Passordet sendes i tillegg ukryptert og passordet ligger også ukryptert i databasen. I tillegg kan det i enkelte inputfelter være mulig å skrive kode som kan gjøre skade på siden og databasen. 4.7 Tilgjenglighet Det viktigste vi har gjort i forhold til tilgjenglighet er å følge standardene, satt av World Wide Web Consortium (W3C). Vi har benyttet Firefox Developer Toolbar for å kontrollere koden. I forhold til tilgjenglighet så mangler det noe på metainformasjon (som beskrivelse av de enkelte sidene). Dette er noe vi ikke har implementert og dermed vil den ikke godkjenne tilgjengligheten for sidene. Side 6

34 Produktrapport 5 Innloggingsinformasjon Som du ser av skjermbildet over så vil brukeren oppleve en vanlig nettside, med menyer og innholdsinformasjon. Øverste menyen vises kun til de som har spesielle rettigheter. Ønsker du å teste ut nettsiden mer utførlig kan du benytte følgende informasjon for å logge på: Følgende brukernavn kan benyttes for å logge inn på tjenestene: Systemadministrator: 4@4.com Manager: 3@3.com Publiserer: 2@2.com Registrert: 1@1.com Alle benytter samme passord: Side 7

35 Produktrapport 6 Websidens oppbygning Nettsidens utseende blir styrt av templates (maler). Dette systemet inneholder i dag kun en enkelt mal, men det er enkelt å kopiere designet slik det er og lage flere forskjellige maler. Nettsiden, slik den vises i Standard template er bygget opp av CSS-elementer. Enkelt kan vi si at den er bygget opp slik: Administratormeny Hode Overmeny Midten (M) Hoyremeny (H) Alt innhold (moduler) vil bli vist i midten. Footer Side 8

36 Produktrapport 7 htaccess For å forenkle logistikken, samt av sikkerhetsmessige årsaker, har vi valgt å benytte aktiv omdirigering av URL på nettstedet. URLen brukeren opplever er annerledes enn filbanen, som skjer på server nivå..htaccess er en fil som overstyrer serveren, med lokale regler som gjelder i mappen denne fila ligger i. Vi har kun benyttet.htaccess-fila til å omdirigere trafikk i URL, men det er også mulig å benytte den til andre ting. Slik ser deler av fila ut: Indikerer hvilken regel. Adressen man i virkligheten blir sendt til. URL-adressen som er innskrevet. Avslutter videre travarsering. Htaccess fungerer på følgende måte: Du skriver f.eks i URLen følgende adresse: Serveren vil da begynne å traversere denne listen, ovenifra og ned. I nest siste linje på utklippet over finner den ^Kontakt$. Etter $-tegnet finner den adressen du blir sendt til. Du vil bli vist filen /Template/Standard/index.php. Denne filen henter så parameterene som er medsendt ( modul=kontakt&side=index.php ) noe som gjør at filen kan inkludere /Moduler/Kontakt/index.php i midten (fra forrige figur). Vi har også i noen tilfeller benyttet en form for Regex for å kunne sjekke forskjellige variable sendt via url og på den måten vidresende korrekt. Les mer om.htaccess-fil på Side 9

37 Produktrapport 8 Oppbygging Systemet er bygget opp basert på trelagsarkitektur, men med noe utradisjonell mappestruktur. 8.1 Moduler Hele systemet er bygget opp på at man lager moduler for hver nettside man ønsker med funksjoner, ikke ulikt OpenSource CMS-systemer som finnes på nettet (Joomla, Draupal ol.). Modulene inneholder filer for alle tre lagene. Dvs. den har en egen fil som inneholder SQLspørringer (f.eks. SQL_modulnavn.inc). Gjøres spørringen mot andre typer databaser enn MySQL, eller spørringens utvalg ønskes endret, så kan dette gjøres i den filen. Filen med SQL-spørringer skal alltid starte med SQL_. Filen er skrevet som en PHP-fil. Modulen har egne filer for logikk. De er skrevet i språket PHP. Alle PHP-filer har endelsen.inc. For å presentere dataene kan man legge til CSS-filer og JavaScript-filer også i samme mappe. For at disse filene skal inkluderes i nettsiden automatisk så må filnavnet være det samme som modulen/ mappen det ligger i. 8.2 System For å ivareta mulighet for å benytte filer på tvers av moduler så er det opprettet en System - mappe. 8.3 Template Systemet legger til rette for å benytte ulike templates, altså maler, for enkelt å kunne endre utseende på nettsiden. Det er i utgangspunktet bare opprettet en template for denne løsningen ( Standard ). For å kunne endre template må det gjøres endringer i.htaccess-filen. Side 10

38 Produktrapport 9 Filstuktur Her vises de tre hovedmappene, med undermapper. Vi vil nå fortløpende gå igjennom hva de enkelte mappene inneholder: Side 11

39 Produktrapport 9.1 Moduler Autentisering Beskrivelse: Mulighet for å logge inn og ut av nettsiden. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Vegard Kontrollert av: Frode Infosider Beskrivelse: Mulighet for å lage infosider (nettsider) og legge den til i menystrukturen. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Vegard Kontrollert av: Rade Side 12

40 Produktrapport Kategorier Beskrivelse: Legger inn lenker i menyene, og mulighet for å endre disse. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Vegard Kontrollert av: Frode Gjestebok Beskrivelse: Mulighet for å legge inn en kommentar i en gjestebok og lese tidligere innlagte kommentarer. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Rade Kontrollert av: Vegard Side 13

41 Produktrapport Medlemmer Beskrivelse: Mulighet for å legge til medlemmer/ tilgang, og endre dette i etterkant. Nytt medlem får automatisk tilsendt pin-kode. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Frode Kontrollert av: Vegard Kontakt Beskrivelse: Mulighet for å fylle ut et kontaktskjema og få det sendt via e-post. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Frode Kontrollert av: Vegard Side 14

42 Produktrapport Nyheter Beskrivelse: Mulighet for å legge inn og se nyheter. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: Rade Utført av: Vegard Kontrollert av: Rade Side 15

43 Produktrapport 9.2 System Denne mappen brukes for å dele filer på tvers av modulene/ templates Bilder Elementer Tiny_MCE er direkte kopiert fra Den søger for et mer attraktivt brukergrensesnitt ved skriving i teaxarea-felt Funksjoner Side 16

44 Produktrapport 9.3 Template Standard Beskrivelse: Viser hele nettstedet. Styrer alt innhold som skal inkluderes. Inneholder filer som sørger for overmeny, administratormeny, logo/navn, høyremenyen og footer. Kontroll: Filsturktur: OK Ryddig kode: OK Kommentarer: OK Godkjent CSS: Ok 2.1 Godkjent HTML: OK 4.01 Brukerveiledning: n/a Utført av: Vegard Kontrollert av: Frode Side 17

45 Produktrapport 10 Database Som nevnt tidligere i rapporten så benyttet vi en MySQL-database i dette prosjektet. Basert på måten vi valgte å bygge systemet så har hver enkelt utvikler lagt til tabeller i databasen etter behov. De tre første bokstavene etterfulgt av en underlinje indikerer hvor i mappestrykturen tabellen hører hjemme. mod_ = Moduler sys_ = System tmp_ = Template Databasen inneholdt følgende tabeller ved prosjektets ferdigstillelse: 10.1 mod_gjestebok Benyttes for å legge inn kommentarer i gjesteboka mod_infoside Benyttes for å lage en infoside (nettside). Side 18

46 Produktrapport 10.3 mod_kategorier Brukes for å legge inn kategorier til Administratormenyen og Overmenyen (hovedmenyen), men tilhørende underkategorier mod_medlemmer Benyttes for å holde oversikt over medlemmer med navn, roller, mm mod_nyheter Tabell for å lagre nyheter som vises på forsiden. Side 19

47 Produktrapport 12 Kravspesifikasjon 12.1 Opprinnelige systemkrav For båtforeningen Medlemsregister Nyheter Informasjonssider Eget design fra template Mulighet for å legge inn egen logo Gjestebok For medlemmer Logge inn med brukernavn(e-postadresse) Lese nyheter Lese informasjon Mulighet for å besøke andre båtforeninger og skrive i gjestebok For administratorer Legge til og administrere båtforeninger For gjester Se liste over båtforeninger Lese åpen informasjon om disse 12.2 Systemet i dag Systemet som står ferdig ved endt prosjekt er helt i tråd med oppdragsgivers krav. Vi er meget fornøyde med det endelige produktet og hvordan vi har tilfredsstilt de kravene som ble satt ved prosjektstart. Kravspesifikasjonen har ikke blitt endret fra den første versjonen, men den har helt siden vi ble presentert med den blitt behandlet som et levende dokument. Innholdet og kravene er hele tiden blitt evaluert i samråd med oppdragsgiver med tanke på tid til disposisjon, ferdighetsnivå innenfor programmering og utvikling, samt brukerenes behov. Side 20

48 Produktrapport 13 Hvordan opprette et nytt nettsted med dette systemet? 13.1 Systemkrav Løsningen anbefales med følgende teknologi: PHP Apache (Debian) MySQL Steg-for-steg 1. Overfør filene som er vedlagt på CD til ditt nettsted. 2. Sørg for å opprette en database og bruk SQLen i filen _DB_baat for å opprette tabellene. 3. Endre til din (avsenders) e-postadresse i /Moduler/Kontakt/config.php og /Moduler/Medlemmer/MedlemLagttil.inc. 4. Tilpassing av designet gjør du i mappen /Template/Standard/. Side 21

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

50 Brukerveiledning 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

51 Brukerveiledning 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. Intern veileder for dette prosjektet er Steinar Johannesen og han har vært til god hjelp. I prosjektet har vi også jobbet tett med Erik Jagland, som har vært vår kontaktperson hos oppdragsgiver. Gruppen vil gjerne benytte anledningen til å rette en spesiell takk til han og tiden han har satt av til oss og dette prosjektet. Gruppe 36 Båtforening på nett Side 3

52 Brukerveiledning 3 Innhold 1 Sammendrag Forord Oversikt over systemet Logg inn Webområdeoversikt Nyheter Kategori Infosider Medlemmer TinyMCE Side 4

53 Brukerveiledning 4 Oversikt over systemet 4.1 Logg inn Dette er logg inn siden. For å få tilgang til systemet må man skrive inn e-post og passord. Punkt for punkt: Skriv inn e-post 2. Skriv inn passord 3. Klikk logg inn 3 Kommentar: Hvert medlem som registreres får brukernavn, passord og en rolle. (se punkt 4.6.1) Rollene er: Gjest, Registrert, Publiserer, Manager og Systemadministrator. Rollene gir forskjellige rettigheter: - Gjest kan bare se hovedmenyen og trenger ikke å logge seg på. - Registrert kan se mer av hovedmenyen. - Publiserer kan se mer av hovedmenyen og legge til nyheter i administratormenyen. - Manager kan administrere hovedmenyen og administratormenyen. - Systemadministrator kan administrere hovedmenyen og administratormenyen. Side 5

54 Brukerveiledning 4.2 Webområdeoversikt 1 2 Her er en oversikt over webområde. Her kan man velge elementer i administratormenyen (1) eller hovedmenyen (2). Side 6

55 Brukerveiledning 4.3 Nyheter Her er et eksempel på en nyhet. 1 2 Her kan man enten redigere (1) nyheten eller slette (2) nyheten. Punkt for punkt: 1. Klikk rediger(1) for å endre nyheten (se punkt 4.3.2) 2. Klikk slett(2) for å slette nyheten. (Avslutter og sletter nyheten). Side 7

56 Brukerveiledning Nyheter Legg til Her kan du legge til nyheten: 1 2 Punkt for punkt: 1. Skriv inn tittel. Maks 100 tegn. 2. Skriv inn ingress. Maks 500 tegn. 3. Skriv inn nyheten Ditt navn står automatisk. Maks 40 tegn. (Standard er innlogget bruker). 5. Klikk Legg inn nyhet. (Avslutter og nyheten publiseres). 4 5 Side 8

57 Brukerveiledning Nyheter - endre/redigere Her kan du endre nyheten: 1 Punkt for punkt: 1. Skriv inn tittel. Maks 100 tegn Skriv inn ingress. Maks 500 tegn. 3. Skriv inn nyheten. 4. Ditt navn står automatisk. Maks 40 tegn. (Standard er innlogget bruker) Klikk Oppdater nyhet. (Avslutter og nyheten publiseres). 4 5 Side 9

58 Brukerveiledning 4.4 Kategori Kommentar: Her er en oversikt over alle kategorier til hovedmenyen og administratormenyen. Kategoriene gjelder kun for Manager. Her kan man redigere (1) en kategori eller slette (2) en kategori. Punkt for punkt: 1. Klikk rediger (1) for å endre kategori. (se punkt 4.4.2) 2. Klikk slett (2) for å slette kategori (Avslutter og sletter kategori). Side 10

59 Brukerveiledning Kategori - Legg til Her kan du legge til ny kategori: Punkt for punkt: 1. Skriv inn kategorinavn Maks 20 tegn. 2. Skriv inn lenkeadresse (Kontakt systemadministrator for riktig lenkeadresse). 3. Skriv inn prioritet (tall fra o - 99) 4. Velg hvilken meny kategorien skal legges til. 5. Velg adgangsnivå til kategorien 6. Klikk på Legg inn/oppdater (Avslutter og legger til kategorien). Side 11

60 Brukerveiledning Kategori endre/redigere Her kan du endre kategoriene: Punkt for punkt: 1. Skriv inn kategorinavn Maks 20 tegn. 2. Skriv inn lenkeadresse (Kontakt systemadministrator for riktig lenkeadresse). 3. Skriv inn prioritet (tall fra o - 99) 4. Velg hvilken meny kategorien skal legges til. 5. Velg adgangsnivå til kategorien 6. Klikk på Legg inn/oppdater (Avslutter og endrer kategorien). Side 12

61 Brukerveiledning 4.5 Infosider 1 2 Her er et eksempel på en infoside. Her kan man enten redigere (1) infosiden eller slette (2) infosiden. Punkt for punkt: 1. Klikk rediger(1) hvis du ønsker å endre infosiden (se punkt 4.5.2) 2. Klikk slett(2) for å slette infosiden. (Avslutter og sletter infosiden). Side 13

62 Brukerveiledning Infosider legg til ny side Her kan du legge til ny infoside: Punkt for punkt: 1 1. Skriv inn tittel. Maks 100 tegn 2. Skriv inn tekst. 3. Velg kategori. 4. Velg adgangsnivå (Ditt navn står automatisk). Maks 40 tegn. 6. Klikk Legg inn infoside. Avslutter og publiserer infosiden Side 14

63 Brukerveiledning Infosider endre/redigere Her kan du endre infosiden: 1 Punkt for punkt: 1. Skriv inn tittel. Maks 100 tegn 2 2. Skriv inn tekst. 3. Velg kategori. 4. Velg adgangsnivå. 5. (Ditt navn står automatisk). Maks 40 tegn. 6. Klikk Oppdater infoside. Avslutter og publiserer infosiden Side 15

64 Brukerveiledning 4.6 Medlemmer Her er en oversikt over medlemmer: 1 2 Punkt for punkt: 1. Klikk rediger(1) hvis du ønsker å endre medlemmer (se punkt 4.6.2) 2. Klikk slett(2) hvis du ønsker å slette medlemmer. (Avslutter og sletter medlem). Side 16

65 Brukerveiledning Medlemmer legg til Her kan du legge til medlem: Punkt for punkt: 1. Skriv inn medlemsnr. 2. Skriv inn medlemsnavn. Maks 40 tegn. 3. Skriv inn adresse. Maks 40 tegn. 4. Skriv inn postnr. 5. Skriv inn poststed. Maks 40 tegn. 6. Skriv inn telefonnr. 7. Skriv inn e-post. Maks 40 tegn. 8. Velg rolle. 9. Klikk Send. (Avslutter og legger til medlem). Side 17

66 Brukerveiledning Medlemmer endre/oppdatere Her kan du endre/redigere medlem: Punkt for punkt: 1. Skriv inn medlemsnr. 2. Skriv inn medlemsnavn. Maks 40 tegn. 3. Skriv inn adresse. Maks 40 tegn. 4. Skriv inn postnr. 5. Skriv inn poststed. Maks 40 tegn. 6. Skriv inn telefonnr Skriv inn e-post. Maks 40 tegn. 8. Velg rolle. 9. Klikk Send. (Avslutter og endrer medlem). Side 18

67 Brukerveiledning 4.7 TinyMCE TinyMCE-menyen er tilgjengelig i to av systemets moduler; legg til nyhet og legg til infoside. En tabell som forklarer litt om funksjonene til TinyMCE: Side 19

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

69 Testrapport 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

70 Testrapport 2 Innledning 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. Det er også en slags forsikring for oppdragsgiver på at systemet fungerer slik det er meningen at det skal. Vi testet de enkelte modulene i løsningen som enkeltløsninger så snart de var ferdige, og etter hvert som de ble integrert i totalløsningen. Testingen ble utført internt i prosjektgruppa, og hele gruppen var involvert i samtlige tester. Ved feil eller mangler i de aktuelle modulene ble det rettet opp i med en gang, før vi gikk videre med neste modul. 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. Gruppen testet samtlige tilgjengelige funksjoner ved løsningen, og det er denne testen som danner grunnlaget for testrapporten. Side 3

71 Testrapport 3 Innhold 1 SAMMENDRAG INNLEDNING INNHOLD TESTING Nyhetsmodul Gjestebokmodul Autentiseringsmodul Infosidemodul Kontaktmodul Kategorimodul Medlemsmodul OPPSUMMERING... 8 Side 4

72 Testrapport 4 Testing 4.1 Nyhetsmodul Funksjon Beskrivelse Resultat Lese nyheter Lese nyheter på siden, både som gjest og som innlogget bruker OK Skrive nyheter Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK Redigere Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK nyheter Slette nyheter Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK 4.2 Gjestebokmodul Funksjon Beskrivelse Resultat Lese gjestebok Lese gjennom gjesteboka, både som gjest og som innlogget bruker OK Skrive i gjestebok Som gjest og bruker med publiseringsrettigheter OK Side 5

73 Testrapport 4.3 Autentiseringsmodul Funksjon Beskrivelse Resultat Logge inn Fylle inn navn og passord OK Feilmeldinger Ved feil brukernavn eller passord OK Brukernivåer Gir riktig menyer og riktig muligheter til riktig brukernivå. OK 4.4 Infosidemodul Funksjon Beskrivelse Resultat Lese infosider Lese infosider, både som gjest og som innlogget bruker OK Opprette infoside Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK Redigere infoside Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK Slette infoside Som bruker med publiseringsrettigheter(publiserer, manager, admin) OK 4.5 Kontaktmodul Funksjon Beskrivelse Resultat Fylle inn skjema Som gjest og som innlogget bruker OK Feilmeldinger Ved ukomplett utfylling av informasjon i skjema OK Sende skjema Mailfunksjon som sender skjema til administrators OK Side 6

74 Testrapport 4.6 Kategorimodul Funksjon Beskrivelse Resultat Legg til kategori Legge til en kategori på menyene OK Redigere kategori Redigere en av kategoriene i menyene OK Slette kategori Slette en av kategoriene i menyene OK 4.7 Medlemsmodul Funksjon Beskrivelse Resultat Se medlem Som registrert bruker se medlemsliste OK Legg til medlem Legge til medlem i medlemsliste OK Sende passord Sender passord til medlemmets oppgitte e-post OK Redigere medlem Redigere medlemsinfo i medlemslisten OK Slette medlem Slette et medlem fra medlemslisten OK Side 7

75 Testrapport 5 Oppsummering Denne rapporten er altså en oppsummering av gruppens endelige systemtest, hvor løsningen var ferdigstilt og alt skulle fungere. Som man kan se av resultatene er det grunn til å være fornøyd med løsningen, og testene avdekket ingen problemer for prosjektet. Side 8

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

77 Presentasjon Tittel: Båtforening på nett Oppgave: Planlegge og utvikle en webside for båtforeninger Periode: 5. Januar Mai 2009 Prosjektgruppe: Gruppe 36 Prosjektmedlemmer: Vegard Skipnes, Rade Vuckovic og Frode Sørensen Veileder: Steinar Johannesen, Førsteamanuensis ved Høgskolen i Oslo Oppdragsgiver: Bonefish.no Kontaktperson: Erik Jagland, utvikler ved Bonefish.no 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. Websiden vil bli utviklet på Bonefish sine servere og vi vil benytte programmeringsspråk som PHP, HTML, CSS og javascript. I tillegg vil vi benytte MySQL som databasesystem. Rettighetshaver til ideen og prosjektet er ESJ Invest v/ Erik Jagland. Om bedriften Bonefish er en liten bedrift som designer og utvikler brukervennlige websider for administrering og publisering av innhold. Systemet 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. Dagens situasjon I dag har nettsiden innlogginsfunksjon 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å

78 at løsningen skal være mest mulig brukervennlig. En bruker uten forkunnskaper skal kunne benytte seg av all den funksjonalitet websiden byr på. Vi ser på dette som en spennende oppgave, samtidig svært utfordrende og lærerikt. Mål og rammebetingelser Utviklingsmetodikk Som utviklingsmetodikk har vi valg tå benytte oss av Scrum. Dette er en populær utviklingsmetodikk i markedet i dag. Den er iterativ, og man har dermed lett for å gjøre endinger underveis. Det er også fortløpende oppdatering på hvordan man ligger an i utviklingen, noe som gjøre det veldig lett for oppdragsgiver å se hvordan prosjektet ligger an. I henhold til denne metodikken er det ikke krav om spesifikasjoner eller detaljert planlegging av arbeidsoppgavene i prosjektgjennomføringen. Vi har allikevel valgt å sette opp en ca. fremdriftsplan med når vi ser for oss de forskjellige hovedbolkene bør være ferdige (se senere i dokumentet). Vi kan forklare arbeidsprosessen grafisk på denne måten: I starten vil vi samle alle ønsker og idèer til løsningen i en liste. Det kalles for produktets backlog. Vi plukker så ut det som har høyest prioriteres hver uke. Dette kalles å lage en Sprint backlog(her forkortet Sprintlog). Vi har avtale om å møtes hver torsdag kl for å gjennomgå hvilke oppgaver som skal plukkes ut og for å presentere for hverandre hvilke oppgaver vi har gjort/ ikke har fått gjort i uken som har gått. Erik (oppdragsgiver) følger med fra sitt kontor underveis, og vi har løpende kontakt med han for eventuelle korrigeringer. Etter en uke skal en oppgave leveres ferdig implementert på nettsiden med all koding, kommentarerer til kodingen, riktig struktur på kodingen (refactoring), brukerveiledning og alt skal være ferdig testet. Gruppen kommuniserer via MSN, tlf og e-post underveis i en sprint for oppdateringer og hjelp til vurdering og koding. Vi har satt opp 15 timer pr person som minimumskrav til arbeidsmengde pr uke. Ønsker man å ta fri må man jobbe mer i andre uker.

79 Vi kan ikke begnytte Scrum-tankegangen i begynnelsen og avslutningen av dette prosjektet. Vi har derfor delt prosjektet opp i 3 faser. Fase 1 (varighet 1 måned) Beggynner med forprosjektrapporten som skal være innlevert 30. januar. Andre halvdel av denne fasen vil gå med til prototyping, oppsett av ikke funksjonelle krav, utvelgelse av arbeidsverktøy, oppsett av server og oppsett av produktbacklog + eventuelt annet vi har behov for før vi starter selve utviklingen. Fase 2 (varighet 3 måneder) Her vil vi kjøre ukessprinter hvor vi utvikler løsningen, som forklart tidligere. Fase 3 (varighet 1 måned) Her vil vi avslutte arbeidet. Det meste av dokumentasjon skal gjøres i sammen med utviklingen, men det er behov for å sette isammen rapporten, foreta en evaluering av hele prosjektet, samt å få rapporten ferdigstilt og levert. Andre halvdel av fasen går med til forberedelse av presentasjonen.

80 Fremdriftsplan Prosjektstart Statusrapport Presentasjon av gruppen og prosjektet Prosjektskisse Detaljert beskrivelse av prosjektet Prosjektside Hjemmesiden for prosjektet ferdig utformet. Oppdateres ukentlig Forprosjekt Mål, rammebetingelser og teknologier for prosjektet Arbeidsmetode Klare regler for hvordan arbeidet skal utføres Fremdriftsplan Oversikt over tid satt av til de forskjellige aktivitetene i prosjektet Kravspesifikasjon Datainnsamling Kartlegging av krav til systemet i samarbeid med oppdragsgiver Kravspesifikasjon Renskrive og ferdigstille kravspesifikasjon Utvikling Servertilgang Ha fullstendig tilgang til arbeidsserver hos oppdragsgiver Prototype Low fidelity prototype brukergrensesnitt Databasedesign Førsteutkast til databasedesign ferdig Statusrapport Kartlegging av fremdrift, nye utfordringer og hva som er gjort Ferdig utviklet løsning All programering og teknisk arbeid gjennomført Testing & feilsøking Intern testing Dokumentasjon Testing av hele løsningen. Gjøres samtidig med at utviklingen pågår Brukermanual Brukermanual for oppdragsgiver Teknisk dokumentasjon Teknisk dokumentasjon av modulene Prosjektrapport Prosjektrapporten ferdig og hoveddelen av prosjektet er over Avslutning Forberede presentasjon Forberede presentasjon av prosjektet og demonstrasjon av modulene Presentasjon Presentasjon av prosjektet Dette er en enkel oversikt over de milepæler vi ser for oss under prosjektet. Vi gjør oppmerksom på at denne planen kun er veiledende.

81 Systemskisse Tekonologier Database Logikk MySql er et Sql-basert ("strukturert spørrespråk") database. Kildekoden er tilgjengelig, men det eies av Sun Microsystems og all utvikling drives av de. MySql kan kjøreres på mange forskjellige servere og det er mange språk som kan koble seg opp til databasen enkelt. Vi tør påstå at MySql er den mest brukte databaseløsningen som er fritt tilgjengelig. Det er et krav fra Bonefish at vi skal benytte MySql i dette prosjektet, og dette synes også gruppen er et fornuftig valg. PHP er et programmeringsspråk tilpasset for å lage dynamiske nettsider. Dette kjører direkte på server, og man skriver kun ut HTML-kode som blir oversent til klientens PC. PHP versjon 5.2 er den siste versjonen. Den støtter bl.a. objektorientert programmering mye bedre enn tidligere versjoner. Den håndtere også bedre XMLgjennomgang ved bruk av en utvidelse kalt "SimpleXML". Det finnes mye dokumentasjon på PHP, og det er dette programmeringsspråket Bonefish bruker. Det er krav fra oppdragsgiver at vi benytter dette språket i vårt prosjekt. Presentasjon Vi vil benytte forskjellige tekonologier til å presentere dataen. HTML er en selvskreven teknologi. Vi vil benytte CSS filer for layouten til nettsidene. Vi vil også ta i bruk flere CSS-filer for å kunne ha mulighet for å endre layout. For en bedre brukeropplevelse vil vi benytte JavaScript og Ajax som ett tillegg til HTML koden.

82 Den teknologien bidrar til at brukerene opplever at ting skjer i realtime. Hvis det sammme skal gjøres i PHP så må brukeren vente for hver handling han/hun gjør. Brukere Vi har midlertidig satt opp 5 forskjellige brukertyper vi ser for oss. Systemadministrator: Setter opp de forskjellige båtforeningsnettsidene (Bonefish) og har overordet adminstrasjon av disse. Manager: er hovedansvarlig hos båtforeningen som kan styre sin nettsides funksjoner/ utseende. Publiserer: Det kan være flere personer i båtforeningen som får tilgang til å publisere ting på nettsiden. Dette kan f.eks. være nyhtere. Registret: Er registrerte brukere (medlemmer) av båtforeningen. Laveste nivå av de som logger seg inn på nettsiden. Gjest: Det er de som kun kommer på nettsiden uten å ha noen tilknyttning til båtforeningen. Kravskisse fra Bonefish Bonefish har satt opp følgende funksjoner de kan tenke seg i løsningen: For båtforeninger o Medlemsregister o Nyheter o Informasjonssider o Eget design fra template (Bonefish.no designer X antall templates å velge fra) o Mulighet for å legge inn egen logo o Gjestebok For medlemmer o Logge inn Brukernavn: e-postadresse o Lese nyheter o Lese informasjon o Besøke andre båtforeninger og skrive i gjestebok For administratorer o Legge til og administrere båtforeninger For gjester o Se liste over båtforeninger o Lese åpen informasjon om disse Dette er ikke noe endelige krav og det er forståelse mellom oppdragsgiver og prosjektgruppen at det vil bli endringer i løsningen. Vi skal som nevnt utvikle løsningen smidig, og lager dermed en og en funsksjon etter de prioriteringer oppdragsgiver ønsker.

83 Konklusjon Websiden vi skal utvikle baserer seg altså på en tidligere versjon, som nå er utdatert i forhold til funksjonalitet og design. Den nye siden skal være en komplett løsning for en båtforenings medlemmer, hvor de finner all den relevante informasjonen de behøver i forhold til sin båtplass og sitt medlemskap. Løsningen vil forhåpentligvis gjøre hverdagen og båtholdet lettere og mer oversiktlig for sine brukere.

84 Statusrapport 09/3-09 Vedlegg 2 Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Statusrapport Per. 09/ Side 1

85 Statusrapport 09/ 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. Websiden vil bli utviklet på Bonefish sine servere og vi vil benytte programmeringsspråk som PHP, HTML, CSS og javascript. I tillegg vil vi benytte MySQL som databasesystem. Rettighetshaver til ideen og prosjektet er ESJ Invest v/ Erik Jagland. Side 2

86 Statusrapport 09/ Innhold 1 Sammendrag Om bedriften Status i forhold til fremdriftsplan Oppdragsgivers involvering Veien videre Forventet måloppnåelse... 6 Side 3

87 Statusrapport 09/ Om bedriften Bonefish er en liten bedrift som designer og utvikler brukervennlige websider for administrering og publisering av innhold. Systemet 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. Side 4

88 Statusrapport 09/ Status i forhold til fremdriftsplan I forhold til de konkrete punktene på fremdriftsplanen er vi et stykke bak forventet standpunkt. Dette skyldes at vi ennå ikke har fått tilgang til oppdragsgivers servere, noe som er et hinder i utviklingen. Arbeidet med å få tilgang og utsettelsene dette har medført har vært en smule frustrerende for prosjektgruppen. Allikevel har vi kommet frem til en prototype for brukergrensesnittet og i tillegg førsteutkastet til databasedesignet. Vi er nå i gang med innledende programmering av løsningen, og har fordelt programmeringsoppgaver i gruppen. Side 5

89 Statusrapport 09/ Oppdragsgivers involvering Rett etter ferdigstillingen av forprosjektrapporten ble vår kontaktperson hos oppdragsgiver syk. Dette har medført at vår kontakt med oppdragsgiver har vært minimal. Servertilgang, forslag til templates og tilgang til tidligere løsning er ting Bonefish skulle levere, men som vi i skrivende stund ennå ikke har fått. Oppdragsgivers fravær innebærer også at en prosjektavtale mellom HiO og Bonefish ennå ikke er underskrevet. Avtalen er ferdigskrevet av prosjektgruppen og sendt oppdragsgiver. 6 Veien videre Foreløpig ser vi ingen grunn til store forandringer i fremdriftsplanen, selv om vi ligger litt bak med vår tenkte utvikling. I følge fremdriftsplanen skal vi være ferdig med all programmering og teknisk arbeid 30/4, noe som gir oss meget god tid i forhold til rapportskriving og formell ferdigstilling av prosjektet. Denne tidsfristen kan være aktuell å utsette noe for å få alt programmeringsarbeid ferdigstilt på en tilfredsstillende måte. Faren for dette har vi forutsett i den tidlige fristen vi satte, så det vil ikke by på umiddelbare problemer. 7 Forventet måloppnåelse Det er ingen foreløpige endringer i våre endelige mål, og vi ser fortsatt for oss at prosjektet vil bli ferdigstilt på den måten vi har sett for oss. Vi er derimot klar over at prosjektets nåværende status kan føre til at vi fremover kan få behov for en revidering av prosjektmålene. Side 6

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

91 Innledning Vi vil i dette vedlegge legge frem noe statistikk som er hentet fra vårt timeregistrertingssystem, teamlog, som ble benyttet under prosjektet. Ønskes det en eksakt oversikt over hva vi har gjort de enkelte dagene så ligger dette i detalj på vår administratornettside Brukernavn: ****. Passord: ****(se innlevert rapport). Statistikken som presenteres her gjelder fra 5.januar til og med 24. mai. En sannsynlig feilkilde til disse tallene kan være ulik føring av timeregistreringen. Noen har ført opp timer fortløpende, mens andre har samlet opp og ført inn i bolker. Det kan også være individuelle forskjeller på hva vi mener hører til hvilken del av prosjektet. Hver enkelt har hatt ansvar for at de får registrert de timene de har jobbet. Arbeidsutvikling Viser en oversikt over antall timer pr måned Vegard 80 Frode Januar Februar Mars April Mai Rade Snitt pr uke Rade 9,4 Frode 8,6 Vegard 15,6 Sum 11,2 Kommentar: Januar ble en oppstartsperiode hvor det ikke ble gjort så mye. I februar hadde vi ikke tilgang til server, mens det i april hadde vi en ukes pause i forbindelse med påske.generellt vil vi si at stolpediagrammet viser at vi har jobbet jevnt i hele prosjektperioden. Til høyre er det satt opp antall timer pr uke fra uke 6 til og med uke 21 med fratrekk for 2 uker som gikk bort i vinter- og påskeferie. I forprosjektrapporten estimerte vi at vi ville bruke 15 timer i uka gjennomsnittlig. Vegard brukte dette, mens de andre lå litt under i snitt.

92 Prosjektstyring Halvparten av tiden i prosjektet har gått med til styring av prosjektet. Dette være seg opprettelse av nettside, koordinering via møter med veileder, oppdragsgiver, ol., og ikke minst føring av dokumentasjon Opplæring Nettside Koordinering Dokumentasjon Utviklingsarbeidet Innledende utv. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Avslutende utv. Timer pr sprint Innledende utv. 38 Sprint 1 75 Sprint 2 39 Sprint 3 30 Sprint 4 10 Sprint 5 33 Avslutende utv. 29 Snitt 36 Kommentar: Vi synes det generelt vises at arbeidsmengden pr sprint har vært riktig, med sprint 1 som et unntak. Dette har nok noe med at det tok ekstra tid å sette seg inn i programmeringen. Snittet er på 36 timer pr sprint. Dette er uten koordinering og noe dokumentasjon som ble registrert et annet sted. Vi hadde estimert totalt (inkl. koordinering og dokumentasjon) 45 timer pr uke/ sprint og anser dermed at vi oppnådde så godt som dette målet.