Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.
1 Sammendrag Prosjektet utføres som hovedprosjekt ved HiO (Høgskolen i Oslo) for oppdragsgiver Nomedia Norge. Oppgaven består av videreutvikling av moduler til CMS (Content Management System) for bonefish.no. Dette systemet skal gjøre det enklere for både de ansatte og kundene ved oppretting av nye websider og oppdatering av eksisterende websider. 2
2 Forord Denne rapporten omhandler hovedprosjektet for gruppe 08-23 og hvordan arbeidsprosessen i dette prosjektet har vært. Denne hovedprosjektoppgaven fikk vi igjennom Nomedia Norge på grunn av et tidligere skolerelatert prosjekt vi har hatt i samarbeid med firmaet. Den gangen laget vi en webside (www.selvbetjeningslageret.no) i samarbeid med designere fra firmaet som vi hadde personlig kjennskap til fra før. Intern veileder for dette prosjektet er Demissie Aredo og han har vært til god hjelp. I prosjektet har vi også jobbet tett med Kyrre Amundsen: designer / prosjektleder i Nomedia, og vi i gruppen vil gjerne benytte anledningen til å rette en spesiell takk til han og tiden han har satt av til oss og dette hovedprosjektet. Gruppe 08-23 Utvikling av moduler til bonefish.no CMS 3
3 Innhold 1 Sammendrag... 2 2 Forord... 3 3 Innhold... 4 4 Innledning... 5 5 Planlegging og metode... 6 5.1 Valg av prosjekt... 6 5.2 Forprosjekt... 6 5.3 Arbeid og fremdriftsplan... 7 5.4 Kundeundersøkelse... 7 5.5 Arbeidsmetoden... 7 5.6 Prosjektdagbok... 8 5.7 Prosjektstyring... 8 5.7.1 Arbeid og fremtidsplan... 8 5.7.2 Risikoplanlegging... 8 5.8 Verktøy vi brukte i prosjektperioden... 10 6 Utviklingsprosessen... 12 6.1 Utviklingsfasene... 12 6.1.1 Forprosjektet... 12 6.1.2 Programutvikling... 12 6.2 Faglige utfordringer... 14 6.3 Arbeidsgiverforhold... 14 7 Kravspesifikasjon... 15 7.1 Endringer fra første versjon... 15 7.2 Kravspesifikasjonens rolle under design og implementering... 15 7.3 Kravspesifikasjonen i dag... 15 7.3.1 Avvik... 16 8 Avslutning... 17 4
4 Innledning Nomedia Norge leverer flere forskjellige tjenester til privat, bedrifter og det offentlige. Nomedia er et firma sammensatt av 3 selvstendig næringsdrivende som ønsket å samarbeide for å kunne nå ut til et bredere kundesegment, samt å få et bredere produktspekter. Nomedia ble stiftet våren 2007 men eierne har vært i bransjen siden 90-tallet. Bedriften er delt opp i 2 avdelinger Hurum IT og bonefish.no, samtidig som de er deltakere i andre prosjekter. Hurum IT Leverer IT-løsninger til private, bedrifter og offentlige instanser i Hurum. De driver med salg, service, support, drift og rådgivning i forhold til dette. Bonefish.no er den delen av Nomedia Norge dette hovedprosjektet er knyttet til. Bonefish.no leverer websider og webløsninger primært til bedrifter. Bonefish.no har hele Norge som nedslagsfelt, og satser høyt på design og enkel funksjonalitet. Bonefish.no leverer også skreddersydde websystemer og løsninger etter kundens ønske. Bonefish.no bruker i dag et utdatert CMS som er tungvindt i bruk. Det tar lang tid å implementere nye sider inn i systemet, dette gjøres i dag manuelt. Funksjonaliteten inne i systemet er enkelt, men noe uoversiktlig. Ulempen med dagens system er at det er lite skalerbart, det passer kun til enkle websider. Dette er noe bonefish.no ønsker å endre slik at de kan tilby et bredere spekter av websider. Vi skal lage moduler til et system som gjør at alle brukerne kan gjøre alle oppgaver direkte i nettleseren. Systemet skal kunne tilpasses hver enkelt bruker og løsning via en konfigurasjonsmodul. For å videreutvikle systemet skal vi utføre en undersøkelse blant eksisterende kunder for å finne ut om hvilken funksjonalitet og muligheter de savner i det eksisterende systemet, samt vurdere muligheten for å implementere savnet funksjonalitet og muligheter til de nye komponentene. Bonefish.no utvikler på LAMP (Linux, Apache, mysql, PHP) plattformen. Vi kommer til å følge samme plattform i forhold til å kunne tilpasse og integrere systemene. LAMP er en open-source plattform. Vi benytter oss av bonefish.no sin eksisterende serverpark for utvikling og testing av det vi lager. Fordelen med å utnytte LAMP som plattform er at det er gratis, det finnes mye informasjon, diskusjonsgrupper og inspirasjon på internett samtidig som LAMP er en kraftig og funksjonell plattform som passer perfekt til denne type system. 5
5 Planlegging og metode 5.1 Valg av prosjekt Valget av dette prosjektet falt ganske naturlig for oss og vi visste tidlig at det var bonefish.no vi skulle jobbe for. Vi hadde nemlig samarbeidet med dette firmaet før i faget Moderne systemutviklingsmetoder som vi hadde 1.semester i det 3.studieåret. Da laget vi en webside (www.selvbetjeningslageret.no) i samarbeid med en designer i firmaet. Vi fikk beskjed om at dersom begge partene var fornøyd med samarbeidet så hadde de et prosjekt som kunne passe godt som hovedprosjektoppgave. Da vi ble ferdige med websiden www.selvbetjeningslageret.no presenterte bonefish.no deres forslag til hovedprosjektoppgave for oss. Vi synes alle det virket spennende. Vi takket ja og laget en prosjektskisse for å få godkjent prosjektet fra skolen. Vi i gruppen har tidligere arbeidet sammen i mange skoleprosjekter igjennom hele studietiden og det falt oss også naturlig denne gangen å benytte oss av den gode kjemien i gruppen. 5.2 Forprosjekt Etter at prosjektskissen var godkjent kunne vi begynne arbeide med forprosjektet. Vi satset på å komme tidlig i gang og startet allerede 4.januar med forprosjektet. En grov analyse over hva som måtte gjøres og hva vi ville rekke å gjøre ble utført i samarbeid med oppdragsgiver slik at vi tidlig fikk oversikt over omfanget av prosjektet. Under forprosjektet støtte vi ikke på de helt store problemene eller uenigheter med oppdragsgiver. Den gode kjemien fra forrige prosjekt så ut til å legge et godt grunnlag for det neste også. Etter presentasjonen av hovedprosjektet hos bonefish.no var vi blitt klar over at vi måtte lære oss noe ny teknologi. Vi måtte sette oss ytterligere inn i PHP, SQL og javascript. Spesielt PHP kunnskapene vi fikk i faget Webprogrammering måtte videreutvikles, da mye av programmeringen ble gjort i relativt komplisert PHP. Allerede i denne forprosjektperioden begynte vi med det. Noe PHP var litt vanskelig i starten og tok litt mer tid en forventet men med hint og tips fra oppdragsgiver på forhånd om hva som var viktig kom vi greit igjennom det i løpet av en 3-4 ukers tid uten å støte på større problemer. Det viste seg å være tid godt brukt senere i prosjektet. 6
5.3 Arbeid og fremdriftsplan Utformingen av den endelige arbeid og fremdriftsplan startet i samme periode som kravspesifikasjonen. Vi hadde tidligere i prosjektet laget en grov papirversjon men vi følte at det ville være fordelaktig/nødvendig å spesifisere dokumentene mere. Arbeidet med disse dokumentene var ikke like omfattende som arbeidet med kravspesifikasjon, men tok allikevel flere uker. Dette fordi vi i samme periode også utformet kravspesifikasjonen. 5.4 Kundeundersøkelse Kundeundersøkelsen ble gjennomført tidlig i prosjektgjennomføringen. Dette fordi den ville være med å danne kravspesifikasjon. Dette er en undersøkelse der vi gjennom kunder av bonefish.no har fått kjørt en test av det eksisterende systemet, og belyst svakhetene ved denne løsningen. Dette har vi videre bearbeidet, og ut fra resultatet får vi en pekepinn på hva som må vektlegges i kravspesifikasjonen og senere i systemet. For å gjøre dette lettest mulig så gjennomførte vi denne undersøkelsen ute hos de kundene som var villig til å gjennomføre den. Dette var seks av kundene til bonefish.no. Kundeundersøkelsen i sin helhet er lagt som vedlegg og ligger også på prosjektets hjemmeside. 5.5 Arbeidsmetoden Det kan være greit å benytte seg av en bestemt prosessmetode i et stort prosjekt. Den prosessmodellen vi har ligget nærmest er scrum, men det er vanskelig følge en slik prosessmetode til punkt og prikke da man bare er 3 personer på gruppa. I et scrum prosjekt vil det være lagt opp til daglige sprinter og gjøremål, mens i dette prosjektet kan man si at sprintene varte en uke av gangen. Dette fungerte greit for oss i dette prosjektet men vi føler egentlig ikke at det har vært helt nødvendig for oss med en slik prosessmetode for å få dette prosjektet til å fungere. 7
5.6 Prosjektdagbok Prosjektdagboken er blitt ført hver dag eller hver gang vi har gjort arbeid på prosjektet. Prosjektdagboken har vært svært nyttig for selve sluttrapporten og utformingen av den. Dette hjelper til å ha oversikt over ting som har skjedd gjennom prosjektperioden og når man har gjort hva. Selve prosjektdagboken ligger som vedlegg og på hovedprosjektets nettside. 5.7 Prosjektstyring 5.7.1 Arbeid og fremtidsplan Arbeid og fremdriftsplanen viste seg å være til god hjelp under hele prosjektet. Med en oversiktlig fremdriftsplan var det lett å holde seg orientert om hvilke arbeidsoppgaver man hadde i de forskjellige periodene, og hvor lang tid man har til hver oppgave. Fremdriftsplanen var godt beregnet tidsmessig. Selv om det var til tider mye arbeid fikk ingen store problemer med å forholde oss til den. Det samme gjaldt arbeidsplanen. Fristene og arbeidsoppgavene vi hadde satt var store men realistiske og hjalp oss med å arbeide jevnt med prosjektet slik at vi ikke satt igjen med for mye arbeid siste uken. Arbeidsplanen og fremdriftsplanen ligger som vedlegg og på hovedprosjektets nettside. 5.7.2 Risikoplanlegging Vi valgte også å lage en oversikt over ting som kunne gå galt i prosjektet og estimere hvor stor risikoen var for dette og en strategi dersom noe skulle gå galt. Vi har hatt gode erfaringer med dette fra foregående prosjekter og mente derfor dette var smart. Risiko Sannsyn lighet Følger Sykdom 20 % Andre i gruppen må ta mer ansvar for ting som opprinnelig ikke var deres område. Strategi Ha muligheter for å kunne jobbe hjemmefra slik at tap av tid ved sykdom 8
blir minimal. Tap av data 5 % Forsinkelser i prosjektet da tapt data må utarbeides på nytt Konflikter i gruppen 10 % Dårlig arbeidsmoral og samarbeidsevne i gruppen Ikke sett omfanget av oppgaven 15 % Arbeidet blir mer tidkrevende enn antatt og fristen blir dermed vanskeligere å overholde. Endring i behov 1 % En del planlegging og utarbeiding av data må gjøres om. Forsinket spesifikasjon 5 % Starten av utformingen må utsettes til spesifikasjonen er klar. Feilberegning av tid/ dårlig tid mot slutten av prosjektet 30 % Prosjektet vil kreve høyere arbeidsrate mot slutten av prosjektet. Gode backuprutiner. Gruppekontrakt inngått før prosjektstart. Skaffe oss oversikten over arbedisomfanget og hva vi rekker ved prosjektstart slik at vi ikke tar på oss for mye arbeid. Kunden er meget klar på behovene til modulene og om det skulle bli noen vil de være av liten karakter. Meget liten sannsynlighet for at det skal bli noe problem. Alternative arbeidsoppgaver mens kravspesifikasjonen blir nærmere utformet. Skaffe oss god oversikt over arbeidsomfanget ved prosjektstart. Lage gode styringsdokumenter og overholde fristene vi har satt oss i arbeid og fremdriftsplanen. 9
I dette prosjektet var vi godt forberedt og slapp derfor å bruke mye tid og krefter på store omstillinger i prosjektet som følger av uforutsette problemer. 5.8 Verktøy vi brukte i prosjektperioden Messenger/MSN: Kommunikasjonsprogram for live samtaler for planlegging, møter og annen prosjektrelatert kommunikasjon. PHP Designer: Program for php programmering og utforming av nettside. Microsoft Excel: Brukt til å lage dokumenter som arbeid og fremdriftsplan. Microsoft Word: Rapportskriving, møtereferat, osv. Google docs og Google kalender: For deling av dokumenter som arbeid og fremdriftsplan, og kalender med frister og lignende tidlig i prosjektet. Winscp: Ftp-program for opplasting av filer til servere for å kunne arbeide hjemmefra med utiklingen av modulene og hjemmesiden. Utvikling UltraEdit Teksteditor for Windows, programmering (PHP, HTML, CSS) Photoshop Bildebehandling Server Debian Linux 2.6.18 Operativsystem 10
Apache 2.2.3 Open-source webserver phpmyadmin Open-source databaseprogram PHP 5.2 Programmeringsspråk MySQL 5.0.32 Databaseserver 11
6 Utviklingsprosessen 6.1 Utviklingsfasene 6.1.1 Forprosjektet Under forprosjekt jobbet vi mye sammen med oppdragsgiver og oppgavene ble gjort mer konkrete slik at vi kunne begynne på brukerundersøkelsen og kravspesifikasjon. Oppdragsgiver utvikler på LAMP plattformen (Linux, Apache, MySQL & PHP) og derfor brukte vi også den samme plattformen for og lett kunne tilpasse systemene. LAMP plattformen er en open-source plattform. LAMP plattformen passet oss godt i forhold til fag vi tidligere hadde hatt i studietiden, men vi måtte allikevel bruke noen av de første ukene til å sette oss inn i mer avanserte deler av teknologiene. 6.1.2 Programutvikling 6.1.2.1 Funksjonsutvikling Da vi var ferdige med den planleggingsfasen (brukerundersøkelse, arbeidsplan, fremdriftsplan og kravspesifikasjon) kunne vi endelig begynne med selve utviklingen av programmet/modulene. For å begynne med selve utviklingen måtte vi koble oss på bonefish.no sin server som opererte på LAMP plattformen. På bonefish.no sin server benyttet vi oss av følgende program under utviklingen: Debian Linux 2.6.18, Apache 2.2.3, phpmyadmin, PHP 5.2, MySQL 5.0.32 6.1.2.2 Versjonskontroll Vi vurderte også flere programmer for versjonskontroll. Slike programmer hjelper brukerne å holde oversikten over de forskjellige versjonene. Versjonshistorikken fungerer som backup og logg der men kan se hvem som har gjort hva og når. Versjonskontrollen hindrer også en bruker å skrive til samme linje som en annen bruker samtidig. 12
Etter nøye vurdering kom vi fram at vi ikke trengte et versjonskontrollprogram. Vi var bare 3 på gruppen og ved å ta backup ofte og god kommunikasjon så kunne dette problemet løses uten flere tilleggsprogrammer å sette seg inn i. Dersom dette skulle vært et større prosjekt med 5-6 programmerere eller mer ser vi at det ville vært fordelaktig med et slikt program. 6.1.2.3 Funksjonalitet og design Første fase i programutviklingen dreide seg i all hovedsak om å få funksjonaliteten på plass. Kravspesifikasjonen ble brukt som mal for hvilke funksjonaliteter vi skulle utvikle og vi jobbet oss igjennom den bit for bit. Da vi begynte å komme oss igjennom det meste av funksjonaliteten kunne vi begynne å tenke på design og integrering. Kyrre Amundsen, prosjektleder/designer i bonefish.no, hadde laget et design for CMS modulene som vi etter hvert skulle implementere funksjonaliteten vår inn i. Føringer for designet ble gitt ved bildefiler og profilmanual. En profilmanual er retningslinjer for bruken av logoer, fonter, fontstørrelser og farger for et nettsted eller firma. I dette tilfellet bonefish.no Selve integreringen gikk veldig bra og Kyrre var tilgjengelig på telefon og mail for mindre uklarheter om designet. Denne delen tok mindre tid enn utviklingen av selve funksjonaliteten, noe som var bra med tanke på tidskjemaet vi hadde satt oss og vi kunne da bruke litt av tiden til å begynne å tenke på prosjektrapporten Under selve utviklingen har vi arbeidet både hjemmefra og på skolen. Vi har også disponert møterom hos bonefish.no, men har brukt det til møter med Kyrre Amundsen når det har vært behov for det. 6.1.2.5 Testing Testing er en viktig og nær del av programutviklingen. Grundig testing hjelper utviklerne å se deler av koden som bør forbedres og gjør programmet mer brukervennlig og stabilt. Vi valgte å foreta generell testingen fortløpende imens utviklingen pågikk. Testingen var intern. Det vil si testpersonene var oss i gruppa og ansatte i bonefish.no. Bonefish.no ville nemlig ikke vise frem et uferdig system på grunn av sikkerhetsmessige årsaker. Da vi var ferdige med kodingen gikk vi igjennom hele programmet igjen og utformet testrapporten. 13
6.2 Faglige utfordringer Dette prosjektet har bydd på noen faglige utfordringer. Vi måtte lære oss og mer avansert PHP, SQL, HTML og CSS enn det vi kunne fra før. Det var mye å lære på kort tid men vi hadde tatt dette med i beregning i starten av prosjektet og allerede under forprosjektet var vi godt i gang med å sette oss inn i teknologiene. Kravene til dokumentasjonen i prosjektet var større i dette prosjektet enn det vi har erfart fra foregående prosjekter. Vi arbeidet ut med utgangspunkt i styringsdokumentene vi hadde laget for prosjektet og ser nå grunnen til at dokumentasjon er viktig i større prosjektet som dette. Det finnes mange forskjellige nettlesere på markedet i dag, men vi har blitt enige med bonefish.no å optimalisere CMS modulene for Mozilla Firefox. Det har gått veldig bra men vi har også prøvd å få til designet så godt som mulig for Microsoft Internet Explorer. Noe som kan være vanskelig til tider, men vi føler vi har fått til på en tilfredsstillende måte. 6.3 Arbeidsgiverforhold Forhold mellom arbeidsgiver og ansatt kan i enkelte tilfeller være avgjørende for om prosjektet blir en suksess eller et feilskjær. Bonefish.no har vært en veldig positiv bedrift å jobbe med i dette hovedprosjektet og kan anbefales til alle fremtidige arbeidssøkere. I forkant av prosjektet håpet vi på at vi skulle dra med oss den samme gode kjemien fra forrige prosjekt med bonefish.no. Vi er glade for å kunne si at vi gjorde det og føler at dette har på virket resultatet av sluttproduktet til det positive. Vi var også i to anledninger ute og spiste middag med ansatte i bonefish.no der selve prosjektet ikke var i fokus. 14
7 Kravspesifikasjon Etter arbeidet med forprosjektet hadde vi fått en god peker på hva bonefish.no hadde satt seg som krav til modulene vi skulle utvikle. Vi kunne da begynne på kravspesifikasjonen. Vi hadde to møter på bonefish.no om kravspesifikasjonen og den ble utformet til et endelig dokument igjennom flere iterasjoner. Kravspesifikasjonen skal fungere som en slags kontrakt mellom prosjektgruppen og det er viktig å komme til enighet om et realistisk prosjekt med verken for lite eller for mye å gjøre. Kravspesifikasjonen skal i all hovedsak følges nøye men det er også viktig at den ikke er skrevet i stein, altså at det er mulig å gjøre mindre endringer i den etter hvert som prosjektet går fremover og problemer eller nye ideer dukker opp. 7.1 Endringer fra første versjon Allerede mens vi utformet forprosjektet fikk vi inntrykket av oppdragsgiver at de visste veldig godt hvilke krav de satte seg til modulene og hadde planlagt dette for en god tid tilbake. Kravspesifikasjonen er ikke blitt endret noe fra den første versjonen men den er blitt noe mer detaljert fra det den var i forprosjektfasen da vi allerede hadde en overordnet kravspesifikasjon. Den nåværende kravspesifikasjonen er den første endelige versjonen. Vi er veldig fornøyd med at vi slapp å gjøre endringer med den utover i prosjektet selv om vi var forberedt på nettopp det. 7.2 Kravspesifikasjonens rolle under design og implementering Vi brukte kravspesifikasjonen som en mal under design og implementeringsdelen slik som vi gjorde under utviklingen av funksjonsdelen av systemet. Design og implementeringsdelen var kortere enn utviklingen av funksjonene. Designdelen hadde allerede en del krav i form av bildefiler utviklet av Kyrre Amundsen fra bonefish.no og bonefish.no sin profilmanual. 7.3 Kravspesifikasjonen i dag Når vi går igjennom kravspesifikasjonen i dag kan vi se at vi har oppfylt alle punktene og målene vi satte oss tidlig i prosjektet. Tidligere i prosjektet var det ikke like lett å se 15
viktigheten av dokumenter som arbeidsplan, fremdriftsplan og kravspesifikasjon. Når man ser tilbake på tiden som har gått ser man lettere viktighetsgraden av styringsdokumentene vi laget tidlig i prosjektet og hvorfor man lager dem. 7.3.1 Avvik Vi er stolte over å kunne påstå at det ikke er noen avvik fra kravspesifikasjonen som var ferdig 28.02.2008. Målene vi satt oss var store men realistiske, og kravspesifikasjonen og de andre styringsdokumentene har satt press på oss slik at vi har jobbet bra under hele prosjektet. 16
8 Avslutning Det er snart syv måneder siden vi satte oss ned for å skrive de første ordene i dette prosjektet, og tiden har gått meget fort, men det har vært en lærerik og hektisk periode i studie. Vi har programmert en webside og laget dokumentasjonen rundt dette. Det har vært mye å gjøre, og i ettertid har vi skjønt at prosjektet har vært stort. Vi har likevel kommet oss igjennom det, og både arbeidsgiver og vi selv er godt fornøyd med sluttresultatet. Oppdragsgiver har vært en veldig fin hjelp gjennom prosjektperioden, da vi har hatt meget god kommunikasjon hele tiden, og gode diskusjoner/samtaler om hvordan sluttresultatet skal se ut. Den veiledningen Kyrre har gitt oss underveis har vært veldig bra, og hjulpet oss til ett bra resultat. Når det gjelder det vi har utviklet i prosjektperioden så er det moduler i ett CMS. Dette er noe som bonefish.no skal bruke videre og selge til kunder. De modulene vi har laget fungerer, men bonefish.no må videreutvikle noen flere moduler før det er ett helt ferdig produkt. Som gruppe har vi vært igjennom mange skoleprosjekter før og lært mye om prosjektarbeid av det. I dette prosjektet har vi som gruppe lært mye om prosjektarbeid i arbeidslivet og hvordan det fungerer i praksis. Vi tar med oss disse erfaringene i bagasjen til dagen vi skal ut i jobbrelaterte prosjekter. 17