HOVEDPROSJEKT. Desking av forhåndsbestemte søketreff Åpen

Like dokumenter
Brukermanual for administrasjonsverktøy Gruppe: 08-03

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Bachelorprosjekt i informasjonsteknologi, vår 2017

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

PROSESSDOKUMENTASJON

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Bachelorprosjekt 2015

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

HOVEDPROSJEKT I DATA VÅR 2011

Dokument 1 - Sammendrag

1 Forord. Kravspesifikasjon

Del IV: Prosessdokumentasjon

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Testrapport Prosjekt nr Det Norske Veritas

Testrapport. Studentevalueringssystem

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt. Accenture Rune Waage,

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

Studentdrevet innovasjon

Oblig 5 Webutvikling. Av Thomas Gitlevaag

PROSESSDOKUMENTASJON

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Sluttrapport NMT-Pekeboka Signe Torp

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)

Forprosjektrapport. Gruppe Januar 2016

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

Testrapport for Sir Jerky Leap

Produktrapport Gruppe 9

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.

Forprosjekt. Høgskolen i Oslo, våren

1. Introduksjon. Glis 13/02/2018

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

Gruppe Forprosjekt. Gruppe 15

Forord. Sammendrag. Kap. 1: Bakgrunn og målsetting for prosjektet. Kap. 2: Prosjektgjennomføring. Kap. 3: Resultatvurdering

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren Testrapport

Forprosjektrapport gruppe 20

TESTRAPPORT - PRODSYS

S y s t e m d o k u m e n t a s j o n

Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Moduler Løsning og alternativer...

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

lettlest utgave Brukerundersøkelse ved Signos virksomheter Hovedprosjekt

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

fleksibilitet når det gjelder geografisk plassering og etablerte arbeidsrutiner. Qubic cms

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Pillbox Punchline

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Repository Self Service. Hovedoppgave våren 2010

Forprosjektrapport ElevApp

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven Prosessdokumentasjon - Alternativ 1

Fakultet for Teknologi

HOVEDPROSJEKT HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

Produksjonssettingsrapport

Kravspesifikasjon. Forord

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

Forprosjektrapport For gruppe 20:

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10

Sangkort - norsk med tegnstøtte

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Public 2013 Aker Solutions Page 1 of 5

4.5 Kravspesifikasjon

innenfor grafisk design i fremtiden. Dette fordi jeg selv ønsker at jeg en dag vil bli en av dem.

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

1. Forord Innholdsfortegnelse innledning Funksjonelle egenskaper og krav Spesifikke krav av delsystemer...

PROSJEKTDAGBOK GRUPPE 28

Forprosjektrapport for bacheloroppgave i data og informasjonsteknologi

Use Case Modeller. Administrator og standardbruker

Gruppe 43. Hoved-Prosjekt Forprosjekt

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

OBLIG 2 WEBUTVIKLING

Kandidat nr. 1, 2 og 3

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

GRUPPEMEDLEMMER FOR BACHELOROPPGAVE 5E. Mikael Brevik (22 år) Greger Lervik (21 år) Marius Krakeli (21 år)

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK

Forprosjektrapport Bacheloroppgave 2017

Testdokumentasjon. Testdokumentasjon Side 1

Forprosjektrapport. Høgskolen i Oslo Våren Dr.Klikk. Gruppe 25. Håkon Drange s Lars Hetland s127681

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Innstallasjon og oppsett av Wordpress

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

Forprosjektrapport. Gruppe 31

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon Innholdsfortegnelse

1. Forord 2. Leserveiledning

FORPROSJEKT RAPPORT PRESENTASJON

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007.

Kravspesifikasjon. Forord

Transkript:

PROSJEKT NR. 08-03 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKTETS TITTEL HOVEDPROSJEKT Desking av forhåndsbestemte søketreff DATO 23. Mai 2008 ANTALL SIDER / BILAG PROSJEKTDELTAKERE Marius Aulie (s139795) Asle Nødtvedt (s122433) INTERN VEILEDER Steinar Johannesen OPPDRAGSGIVER ABC Startsiden KONTAKTPERSON Hilde Vik SAMMENDRAG Oppgaven går ut på å lage et verktøy for redaksjonsmedarbeiderne til ABC Startsiden. Applikasjonen som er lagd er to-delt. Et brukergrensesnitt for redaksjonen og en motor som blir kjørt når noen søker på http://www.abcsok.no. Applikasjonen er skrevet i rammeverket Catalyst, programmeringsspråket PERL og MySQL er brukt som database. Applikasjonen er i bruk av redaksjonen og motoren venter på å bli implimentert av utviklingsavdeling til ABC Startsiden. 3 STIKKORD Catalyst DBIx::Class Desking av søketreff

Prosessdokumentasjon 1

Forord Prosessdokumentet vil ta for seg utviklingen av prosjektet, problemer vi har hatt underveis og hvordan vi har taklet disse problemene. Vi vil også beskrive arbeidsmetoder, rammebetingelser og hvilke verktøy vi har brukt til å løse prosjekts problemstilling. Vi tok kontakt med ABC Startsiden via Marcus Ramberg den 19.11.2007 og vi fikk straks et positivt svar. De hadde en problemstilling hvor de så fra sine logger at folk som brukte deres søkemotor ofte søkte svært generelt og utifra dette mente ABC Startsiden at det sannsynligvis var mange brukere som ikke fant frem til det de lette etter. De hadde en idè om hvordan dette kunne løses men hadde ikke selv tid til å løse dette problemet. Vi vil gjerne begynne med å takke Marcus Ramberg som ga oss prosjektet, Hilde Vik som har vært vår prosjektleder, Andreas Marienborg som har vært svært flink til å hjelp oss etter beste evne og Stian Guldhaug som har ledet testingen den siste tiden. Vi vil også takke vår veileder, Steinar Johannesen, som har gitt oss mange gode råd. 2

Innholdsfortegnelse FORORD... 2 INNHOLDSFORTEGNELSE... 3 BAKGRUNN OM BEDRIFTEN... 4 OPPGAVENS MÅL... 5 RAMMEBETINGELSER... 7 ARBEIDSFORHOLD... 7 PLANLEGGING OG METODE... 8 PLANLEGGING... 8 FRAMDRIFTSPLAN OG KRAVSPESIFIKKASJON... 8 Framdriftsplan... 9 Kravspesifikkasjon... 10 Generell... 10 Motoren... 10 Administrasjonsgrensesnittet... 11 Generell... 11 Databasen... 11 Motoren... 12 Administrasjonsgrensesnittet... 12 METODER... 13 VERKTØY... 14 RAMMEVERK... 14 DATABASE... 15 SPRÅK... 16 SUBVERSION... 16 UTVIKLINGSPROSESSEN... 17 VALG AV PROSJEKT... 17 LÆRING AV NY TEKNOLOGI... 17 UTFORDRINGER I PROSJEKTGJENNOMFØRINGEN... 19 Catalyst... 19 DBIx::Class... 19 Form Fu og YAML... 19 Oversiktelig GUI... 20 Dokumentasjon av de forskjellige verktøyene... 20 FORHOLD TIL OPPDRAGSGIVER... 20 FREMTIDEN TIL APPLIKASJONEN... 21 KONKLUSJON... 22 REFERANSER... 23 Innledning 3

Bakgrunn om bedriften ABC Startsiden ble startet av Tom Ottmar i 1996 som et hjelpeverketøy for NRK journalister. Tanken var da at Startsiden skulle være en samling av pekere hvor journalistene lettere skulle finne frem på internett. Etterhvert som trafikken økte, sluttet Tom Ottmar i NRK og startet webproduksjonsselskapet MetaMedia hvor de fortsatte utviklingen av http://www.startsiden.no. Veksten fortsatte og i 2003 ble det målt 2 millioner unike brukere i løpet av en måned. Dette gjorde Startsiden til norges mest besøkte nettsted. I dag eier Telenor 99,6% av alle aksjene i Startsiden. Veksten har fortsatt og idag består ABC Startsiden av flere nettsteder. http://www.startsiden.no http://www.startsida.no http://www.abcnyheter.no http://www.overblikk.no http://www.abcsok.no Det er sistnevnte abcsok.no vi under dette prosjektet har jobbet med. ABC Startsiden hadde allerede tenkt ut en applikasjon som de selv ikke hadde tid til å utvikle for øyeblikket. Vi fikk høre deres idè og vi fikk komme med innspill. Vi ble godt mottatt og tente straks på idèen deres. Vi fikk en kort introduksjon i verktøyet vi skulle bruke og begynte lære oss dette ved hjelp av tutorials vi fant på internett. 4

Oppgavens mål Redaksjonen har lenge sett at mange søker på generelle enkelt ord som gjør det vanskelig for brukeren å finne informasjonen brukeren leter etter. For å gjøre abcsok.no mer brukervennlig for brukere som har liten erfaring med å søke på internett ville redaksjonen hjelpe disse med anbefalte søketreff der det passer seg. Redaksjonen ville ha er verktøy der de kan legge inn ord/setninger inn i en database og ved hjelp av databasen vise brukeren forskjellige søketreff som de følte at brukerne kunne ha nytte av. Abcsok.no er en søkemotor som benytter seg av Yahoo sin søketeknologi. Idèen var å lage et alternativt søketreff fremfor de vanlige søketreffene man vil få med Yahoo sin søketeknologi. Tanken var at redaksjonen skulle kunne legge inn ord/setning og definere treffene selv fremfor å bruke Yahoo sin søkemotor. Hver gang en bruker søker på abcsok.no vil applikasjonen kjøres og hvis ordet/setningen er lagt inn av redaksjonen vil brukeren bli presentert med en side som applikasjonen lager men som er satt sammen av personen som har lagt inn ordet/setningen i applikasjonen. Utfordringen til redaksjonen blir å ha søketreffene så objektive som mulig og bruke denne applikasjonen som et informasjons verktøy og hjelpemiddel for brukere som ikke definere søkene sine bra nok til å få den informasjonen de leter etter. Det er kun første søketreffsiden som blir generert av applikasjonen og de resterende sidene vil komme fra Yahoo sin søkemotor. Startsiden var klar helt fra begynnelsen av prosjektet at vi ikke kom til å rekke å lage en fullgod appllkasjon. Dette prosjektet ble derfor sett på som fase1 av flere faser. I beste fall fikk de implementert en funksjon inn i ABCSøk, i værste fall hadde de en god plattfor å bygge videre på 5

Dette prosjektets mål ble derfor å lage en applikasjon hvor man kunne definere forskjellige verdier i en database, bruke relasjonene i databasen til å traversere gjennom den og hente relevant data i forskjellige tabeller. Den skulle innholde et administrasjonsgrensesnitt og en rask og effektiv søkemotor som på sikt kunne integreres mot ABCSøk Programmets flyt 6

Rammebetingelser Vi må benytte ABC Startsidens eksisterende teknologi. De har basert sine sider og søkemotoren på Catalyst, som er laget i Perl med MVC-rammeverket som modell. Applikasjonen vi utvikler må: Søkemotoren må: Benytte Catalyst Gi et svar tilbake til Startsidens kontroller innen 1 sekund, den må gi output en i RSS, den må kunne parse inputen (søkeordet) etter bestemte regler Skalere over flere servere. Administrasjonsgrensesnittet må: Ha et enkelt og pedagogisk grensensitt. Sørge for at hvert søk har en eier. Gi hvert søk en (eventuelt ingen) utløpsdato. Ha en logg over endringer. Arbeidsforhold Ingen av oss hadde jobbet noe særlig med et rammeverk og vi skjønte tidlig at det ville være nok av utfordringer. Vi begynte å jobbe hjemme med tutorialene hvor vi prøvde å lage en liten applikasjon. Vi fant fort ut at dokumentasjonen var tynn og for noen av modulene vi skulle bruke eksisterte det verken oppdatert dokumentasjon eller eksempler som var gode nok og rettet mot det vi skulle bruke de til. Det var mye frustrasjon til tider, men etterhvert som vi kom oss igjennom problemene vokste også mestringsfølelsen og dette ga oss motivasjon og inspirasjon. I begynnelsen av februar fikk vi eget kontor og laptoper på Startsiden AS. Dette hjalp oss mye ettersom vi kunne få bedre hjelp til forståelsen og applikasjonen vi skulle lage. 1. Mars sluttet Marcus Ramberg i Startsiden og det var da kun en utvikler igjen som kjente Catalyst. Vi trodde dette ikke ville påvirke oss noe særlig men etterhvert gjorde det dette. Vi skjønte fort at den andre personen som var igjen var veldig opptatt og hadde mye å gjøre. Terskelen for å spørre spørsmål ble høyere ettersom vi ikke ville bry dem med spørsmål vi kunne finne svar på selv ved hjelp av internett. I etterkant av prosjektet er det nok vi som må ta på oss skylden for at vi følte dette. Det viste seg etterhvert at de var mer enn glad for å hjelpe oss. 7

Planlegging og metode Planlegging Etter at vi hadde hatt vårt første møte med Startsiden startet vi straks på planleggingen. Vi avtale også et nytt møte med Startsiden hvor vi gikk igjennom alle verktøyene vi skulle bruke. Det viste seg fort at disse verktøyene var helt nye for oss og at de var vanskelig å bruke. Vi brukte mye tid på forståelse i begynnelsen. Vi satt sammen en framdriftsplan som vi fort skjønte at vi måtte endre. Vi begynt allerede i desember med å jobbe med tutorialene til de forskjellige verktøyene. Det viste seg at rammeverket vi skulle bruke var dårlig dokumentert og guidene vi fant gjorde ting på helt forskjellige måter enn det vi skulle gjøre. Etterhvert som vi kom oss igjennom tutorialene lagde vi en grov fremdriftsplan i samarbeid med Startsiden. Vi hadde tenkt å utarbeide en mer detaljert fremdriftsplan ut i fra denne, men merket fort at utfordringene vi hadde med rammeverket gjorde fremdriften svært uforutsigbar. Vi holdt oss derfor til denne grove planen. Selv om den var grov gav den en god oversikt og førte til at vi hadde følelse av kontroll over fremdriften. Vi holdt oss da også innenfor rammen som var satt bortsett fra helt mot slutten da vi måtte utsette kodefrysen med 14 dager. Applikasjonen vi skulle lage består av to mindre applikasjoner. Den ene er brukergrensesnittet som redaksjonen på Startsiden skal administrere applikasjonen med, den andre er en søkemotor som vil genere en RSS feed. Vi så at disse applikasjonene var tilnærmet like store så vi delte oppgaven i to og gjorde hver vår. Siden vi bare var to på gruppa bestemte vi oss for å avtale fortløpende når vi skulle møtes. I begynnelsen satt vi hjemme hos hverandre og etter at vi fikk eget kontor hos Startsiden fungerte det bra å møte opp der. Framdriftsplan og kravspesifikkasjon Tanken fra dag en var at dette prosjektet er fase 1 av det ferdige produktet. Vi var fleksible med tanke på hva som skulle implenteres. Det var en tanke at i fase 1 av applikasjonen skulle implementere de viktigste funksjonene og ha en produkt som fungerte. 8

Framdriftsplan Helt i starten av prosjektet var oppgaven ganske diffus for oss. Vi viste at Startsiden brukte Perl og at prosjekrapporten skulle leveres i mai. I starten av januar hadde vi et møte med Startsiden, hvor vi blant annet lagde en grov fremdriftsplan. Tanken var at vi skulle skrive en mer detaljert plan etter hvert som vi fikk mer oversikt over omfanget av prosjektet. Problemet var det at vi på grunn av utfordringene rundt rammeverket aldri fikk noe særlig oversikt over prosjektets omfang. Vi visste derfor ikke hvilke utfordringer som lå oss i vente og hvor lang tid vi ville bruke på å løse disse. Det ble derfor til at vi beholdt den grove framdriftsplanen. Januar Kravspek må være ferdig Påbegynt applikasjons design Database design må være godkjent, men endringer kan komme Startsiden leverer eksempel på RSS Februar Mars April Mai Grafisk design ferdig. HTML/CSS mal levert fra startsiden Prototyp på søkemotor ferdig Utvikle administrasjonsgrensesnittet Database designet er klart og låses Kodefrys 15.april Bugfix Overføring til drift og utvikling avdelingen på startsiden Rapport til skolen 9

Kravspesifikkasjon I dette prosjektet ble det tidlig klart at denne applikasjon måtte utvikles i flere faser. Dette prosjektet er bare fase1 og derfor vil noe av kravspesifikasjone raskt kunne bli flyttet til fase2 Følgende kravspesifikasjon har blitt utarbeidet i samarbeid med ABC Startsidens utviklere. Den ble utarbeidet tidlig i prosjektet som et grunnlag for videre arbeid og bør vel ikke brukes til sammenligning mot det ferdige programmet Det er utarbeidet tre kravspesifikasjoner; En generell for hele prosjektet, og en for hver av de to applikasjonene. Generell 2 Applikasjoner En motor som genererer RSS og et administrasjonsgrensesnitt som definerer reglene for søk. Datamodellen må være gjenbrukbar utenfor applikasjonene. Må validere standarder som er brukt. Må finnes et sett med automatiserte tester. Må være dokumentert fra utviklernivå. Motoren Motoren må ha en respons tid innen et sekund Skal kunne søke i spesifiserte datakilder og statiske resultater Skal returnere RSS Må kunne skaleres over flere web-servere Output skal kunne parses av Net::Search::RSS Må forstå enkelt query-formatting ( quoting AND/OR ) Matche et eller flere ord uavhengig av rekkefølge Må kunne returnere flere sider med resultater 10

Administrasjonsgrensesnittet Startsiden leverer et statisk html-design som implementeres av gruppen Må validere input fra brukere Må kunne autoriseres mot startsidens Single Sign-On system Må være enkel å bruke (gi gode feilmeldinger, virke vennlig) Støtte å registrere søkeord, liste opp søkeord, slette og endre Live Preview. Søkeord må tidsbegrenses Vise: Mine søkeord og alle søkeord (basert på innlogget bruker) Søkeord må kunne bulk-overføres til nye eier (kan skyves til fase-2) Alle brukere kan redigere alt. Endringslogg som registrerer endringer Man må kunne søke i endringslogg. Et søkeord returnerer x antall resultater basert på et sett regler Regler behandles i rekkefølge Rekkefølgen på reglene må kunne endres enkelt. Regler kan returnere statiske eller dynamiske elementer Statiske elementer er generert i grensesnittet. Hente statistikk fra Omniture (oversikt over de meste brukte søkeordene på abcsok) (Nice to have feature) Automatisk e-post rapportering om endringer / søkeord som er i ferd med å gå ut (ukentlig) Etter hvert som prosjektet skred frem har det blitt naturlig å modifisere kravspesifikasjonen slik at den gjenspeiler det som er naturlig å rekke i fase 1. Den reviderte kravspesifikasjonen innholder både elementer som må være med og elementer som absolutt bør være med. Generell 2 Applikasjoner En motor som genererer RSS og et administrasjonsgrensesnitt som definerer reglene for søk. Datamodellen må være gjenbrukbar utenfor applikasjonene. Må validere standarder som er brukt. Bør finnes et sett med automatiserte tester. Må være dokumentert fra utviklernivå. Databasen Må være designet slik at det er enkelt å legge til tabeller Lower-case og underscore mellom ordene MySQL database 11

Motoren Motoren må ha en respons tid innen et sekund Skal kunne søke i spesifiserte datakilder + statiske resultater Skal returnere RSS (i et view) Må kunne skaleres over flere web-servere Output skal kunne parses av Net::Search::RSS Matche et eller flere ord uavhengig av rekkefølge Administrasjonsgrensesnittet Startsiden leverer et statisk html-design som implementeres av gruppen Må validere input fra brukere Må være enkel å bruke (gi gode feilmeldinger, virke vennlig) Støtte å registrere søkeord, liste opp søkeord og endre Søkeord må tidsbegrenses Vise: Mine søkeord og alle søkeord (basert på innlogget bruker) Alle brukere kan redigere alt. Endringslogg som registrerer endringer Et søkeord returnerer x antall resultater basert på et sett regler Regler behandles i rekkefølge Rekkefølgen på reglene må kunne endres enkelt. Regler kan returnere statiske eller dynamiske elementer Statiske elementer er generert i grensesnittet. 12

Metoder Etter at vi satt sammen kravspesifikasjonene begynte vi å tenke på hvilke arbeidsmetoder vi ville bruke. Vi diskuter mye rundt dette tema og kom frem til at vi ikke ville bruke fossefallsmetoden ettersom Startsiden fortløpende kom med ønsker om funksjoner som skulle implementeres i applikasjonen. Dette gjorde det krevende for oss og vi var nødt til å være dynamiske i hvordan vi jobbet. Vi kom frem til at vi ville bruke en modifisert utgave av fossefallsmodellen hvor vi hele tiden hadde mulighet til å gå tilbake til tidligere faser og implementere eventuelt nye funksjoner. For at dette skulle fungere var vi avhengig av å ha en god oversikt og gjøre oss ferdig med en funksjon om gangen. Innsamling av krav Implementering Analyse / design Testing Utvikling 13

Verktøy Under utviklingen av denne applikasjon har det vært mye nytt å lære. Vi har jobbet lokalt på to laptoper med Ubuntu Linux som operativ system. For at samarbeidet skulle fungere optimalt har vi brukt SubVersion. Ved hjelp av SubVersion har vi kunnet hatt oppdaterte versjoner av begges applikasjon. Rammeverk Rammeverket vi har brukt til denne applikasjonen heter Catalyst. Dette er et open-source rammeverk for programmingersspråket PERL. Catalyst er basert på to hovedprinsipper; DRY, som står for Don t repeate yourself, og fleksibilitet. Dette rammeverket kan for mange være vannskelig å lære seg fordi det er laget for å være så fleksibelt som mulig. Dette gjør at det finnes veldig mange måter å gjøre ting på, noe som i begynnelsen kan gjør at det tar tid å finne ut hva man synes fungerer best. Igjennom hele prosjektet har vært lært nye ting om rammeverket og dette har gjort at vi har vært nødt til å gå tilbake å gjøre ting på nytt. 14

Startsiden bruker dette rammeverket til http://www.abcsok.no hvor vår applikasjon skulle implementeres. Vi hadde aldri brukt dette rammeverket før og det viste seg å være stort og vanskelig å lære seg. Vi skulle få en innføring i dette av Startsiden, men vi endte med å lære oss dette selv og spørre spørsmål etter hvert som de kom. I tillegg til Catalyst har vi brukt flere moduler fra http://www.cpan.org. Her finnes det mange bra moduler man kan bruke i Catalyst. Problemet er ofte at disse modulene kan være dårlig dokumentert og det tar tid å lære seg hvordan de fungerer. Modulene vi har brukt er: DBIx::Class o Dette er en module som transformerer SQL tabeller til PERL objekter. FormFu o Dette er en module som vi har brukt til å presentere HTML-Forms og validere input fra brukeren. YAML o Dette er en konfigurasjonsfil som FormFu tolker. DateTime o Module som lager objekt av tid. Kan konvertere enkelt fra en tidsperiode til en annen. Kan også gjøre vanskelige sammenligninger med forskjellige tidsformater. Database Som database har vi brukt MySQL. For testing er denne er installert på en Debian server, men vi har under utviklingen kjørt lokale kopier på laptopene våre. Vi har begge to erfaring med SQL databaser så installasjon og vedlikehold har gått greit.database designet var det først vi lagde og det har det har uungåelig vært noen endringer underveis.de største av disse har vært: id-feltet i desksearch settes til auto_increment Tabellen searchengine ble lagt for å fjerne redundans i forhold til konfigurasjon av de dynamiske søkene User tabellen ble lagt til for å lagre navn og epost adresse til bruker som logget på gjennom startsidens single sign-on løsning. 15

Språk PERL5 o Plattform uavhengig programmeringsspråk. Dette er det programmeringsspråket vi har brukt mest under utviklingen. HTML, CSS og Javascript o Brukes i administrasjonsgrensesnittet for å lage sidene SubVersion SubVersion har vært brukt flittig under hele utviklingen. Dette er en versjonskontroll applikasjon hvor det er mulig å se på forandringer igjennom hele utviklingsperioden. Det har vært helt nødvendig for oss å bruke dette ettersom all utvikling har skjedd lokalt på hver vår datamaskin men var fortsatt avhengig å ha begge applikasjonene installert for at hele produktet skulle fungere. 16

Utviklingsprosessen Valg av prosjekt Vi var veldig spent når vi skulle lete etter et prosjekt. Vi brukte god tid på å finne et prosjekt som vi ville like. Vi tok kontakt med ABC Startsiden og spurte om de hadde et prosjekt som kunne passe for to studenter. De hadde en idè som de selv ikke hadde tid til å utvikle for øyeblikket og dette passet bra for oss. Vi syntes prosjektet hørtes spennende ut fordi det skulle lages med open source teknologi og med Linux som plattform. Læring av ny teknologi Etter at vi hadde hatt vårt første møte med ABC Startsiden var vi veldig spent. Vi visste at det var mye nytt vi måtte lære og hadde nok ikke fått full oversikt over hvor mye det faktisk var. Vi begynte straks å utvikle enkle test applikasjoner for å lære oss hvordan rammeverket og modulene vi skulle bruke fungerte. Dette tok lengre tid enn først antatt. Dokumentasjonen var tynn og nivået som krevdes for å få en forståelse var høy. Etter hvert som vi lærte mer og fikk en bredere forståelse støtte vi hele tiden på nye ting vi måtte lære oss. Vi har hele tiden måtte selv ta ansvar for å lære oss rammeverket og modulene vi skulle bruke. Dette har gjort at til tider har vi måttet jobbe med motivasjonen vår og holdt motet oppe. Vi begynte hjemme med å installere en ubuntu Linux server som vi utvikling på. Her lagde vi å små applikasjoner som kunne lese fra en MySQL database og vise innholdet på HTML form. På denne måten lærte vi hvordan Catalyst og modulen DBIx::Class fungerte. I februar fikk vi kontor hos ABC Startsiden og det var på dette tidspunktet at vi begynte å få ordentlige tilbakemeldinger fra utviklerne på startsiden. Blant annet hadde vi ikke helt forstått DBIx og mye av koden kunne og legges i schema-klassen. Vi hadde allerede kommet i gang med applikasjonen og var tvunget til å endre mye kode. Det skjedde flere ganger gjennom prosjektet at en av oss hadde begynt på en løsning for å så få beskjed om Dette kan du gjøre enklere på. måten. Dette er selvsagt veldig lærerikt, men også ganske frustrerende til tider. Før vi begynte med dette prosjektet hadde vi god kjennskap til Linux og har brukt det flittig i lang tid. Men dette var første gang noen av oss skulle utvikle en større applikasjon på dette operativ systemet. Vi lærte mye av dette og så mange fordeler med utvikling på en Linux plattform. Når vi begynte dette prosjektet hos ABC Startsiden var tanken at Marcus Ramberg, som er release manager for Catalyst, skulle gå grundig igjennom dette rammeverket med oss. Og i den første fasen av prosjektet var Marcus Ramberg også flittig med å planlegge. Vi lærte mye om Catalyst og planlegging av programvare prosjekter av han. Ved juletider sa Marcus Ramberg opp 17

sin jobb i ABC Startsiden og ble veldig opptatt med å avslutte påbegynte prosjekter. Vi mistet derfor en god mentor som hadde vært veldig kjekk å ha under dette prosjektet. Det viste seg også fort at det bare var en person igjen på ABC Startsiden som kunne denne teknologien. Dette gjorde det og vannskeligere for oss ettersom vi aldri fikk den innføringen vi var lovet. Selv om læringsprosessen har vært tung og lang sitter vi igjen med en god følelse av denne tiden. Vi har lært mange nye ting og vi er veldig fornøyd med prosjektet vi valgte. 18

Utfordringer i prosjektgjennomføringen Vi støttet på flere utfordringer i løpet av prosjekttiden. Alle verktøyene vi skulle bruke var nye for oss og vi hadde hele tiden mye å lære. Den største utfordringen vår var å lære oss hvordan Catalyst fungerte. Dette tok lengre tid enn vi hadde regnet med. Problemet lå i at vi aldri hadde jobbet i et MVC rammeverk før og fleksibiliteten i Catalyst gjorde det vanskelig og finne den beste måten å utvikle applikasjonen på. Desto mer ferdig applikasjonen ble desto flere tilbakemeldinger fikk vi. Dette gjorte at vi flere ganger måtte gå igjennom kode som vi lenge hadde sett på som ferdig. Vi fikk da ofte også behov for å sette oss ned å ta en ny gjennomgang av programmet for å finne ut hvordan vil skulle bygge det opp. Catalyst Catalyst er rammeverket vi har brukt til utviklingen av applikasjonen. Det er hovedsakelig laget i PERL for PERL. Dokumentasjonen ligger på http://www.cpan.org og denne deler av denne dokumentasjonener samlet og gitt ut på bokform. Catalyst er lagd for å være mest mulig fleksibelt og dette gjør at det også kan være vanskelig å sette seg inn i. Dokumentasjonen var ikke rettet mot måten vi skulle bruke Catalyst på og viste hovedsakelig enkle funsjoner. Siden vår applikasjon var mye større og mer kompleks var vi nødt til å bruke test & feiling metoden. Dette tok mye tid og energi. DBIx::Class Dette er en PERL module for SQL databaser. DBIx::Class lager PERL objekter av SQL tabeller og dette er svært nyttig når man lager større applikasjoner med database tilkoblinger. Dette er en svært nyttig module og den har mange nyttige funksjoner for samhandling med SQL tabellene. Form Fu og YAML Form Fu trengte vi til administrasjonsgrensesnittet. Problemet her oppsto når vi fant ut at dokumentasjonen gjaldt en eldre versjon. FormFu er fortsatt beta så dokumentasjonen til versjonen vi måtte bruke eksisterte ikke. YAML er et markup language som benyttes for å konfigurere FormFu. Problemet som oppstod her var at dokumentasjonen som fantes tok i svært liten grad for seg hvordan man bruker YAML 19

for å definere FormFu filer. Uten tilgang til startsidens kildekode bibliotek hadde det vært en umulig oppgave. Det ble mange timer og uker med saumfaring av udokumentert kildekode for å få html-formene til å bli slik de er i dag. Jeg antar at 3-4 uker av kodetiden gikk med til det. Oversiktelig GUI Det var viktig for både oss og startsiden at administrasjonsgrensesnittet hadde en oversiktelit og hyggelig layout. I samarbeid med web-designere på startsiden kom vi frem til et design som både vi og redaksjonen på startsiden var fornøyd med. Selv om det fremdeles er forbedrings potensiale. Dokumentasjon av de forskjellige verktøyene Moduler som vi skulle bruke i rammeverket var så dårlig dokumentert at vi endte med å lese kildekode for å finne ut hvordan ting skulle gjøres. Her endte vi opp med mye prøving og feiling før vi kunne få en oversikt over hvordan ting burde gjøres. Ettersom det bare var en person igjen på Startsiden som hadde kunnskap om disse modulene og rammeverket var det vannskelig å få god hjelp. I denne fasen gikk arbeidet vårt sakte og vi måtte legge flere timer inn i tidsplanen enn det vi hadde planlagt. Forhold til oppdragsgiver Etter vårt prosjekt sitter vi igjen med et veldig godt inntrykk av ABC Startsiden. Vi ble tatt veldig godt i mot og behandlet akkurat som de andre arbeidstakerne. Vi fikk eget kontor når vi begynte på utviklingen for alvor. Dette hjalp oss mye ettersom det var lettere å spørre om hjelp. Vi har også blitt involvert i sosiale eventer utenfor arbeidstiden. 20

Fremtiden til applikasjonen Dette har vært en applikasjon som ABC Startsiden har villet ta i bruk fra første stund. Det ble nok noe preget av at de ble underbemannet under prosjekttiden, men dette løste seg etter hvert bra. Det er nok fremdeles forbedringer som burde gjøres til neste versjon av applikasjonen. Dette skyldes nok at vi mot slutten måtte konsentrere oss om å få en fungerende applikasjon innenfor kravspesifikasjonene. Applikasjonen er den dag i dag ferdig som en versjon 1. Vi har fortsatt god kontakt med ABC Startsiden og føler at vi har noen forbedringer som vi har lyst til å utføre før vi gir oss med dette prosjektet. Dette har vi lyst til selv om rapporten er levert og prosjektet er avsluttet i skolens regi. 21

Konklusjon Når vi ser tilbake på prosjektet som en helhet ser vi at det er mange ting som kunne vært gjort anderledes. Vi gjorde nok alt for lite undersøkelser om verktøyene vi skulle bruke. Vi kunne svært lite om disse verktøyene fra før av og dette så vi bare på som en positiv ting. Det vi ikke tenkte på var om det var nok dokumentasjon og om det var noen bøker vi kunne lese for å lære oss de forskjellige verktøyene. Når vi først begynte fant vi ut at det fantes bare en bok om rammeverket og denne var svært tynn. Vi gjorde heller ikke nok undersøkelser om hvilke andre verktøy enn selve rammeverket vi skulle bruke. Dette ser vi i etterkant at vi burde ha gjort med en gang. Etter dette er sagt har det vært en svært lærerik tid og vi føler ikke at alle timene vi har lett etter informasjon har vært bortkastet. Heller derimot. Dette prosjektet har gått ut på å lage et verktøy til redaksjonen til ABC Startsiden. Det har vært et svært lærerikt prosjekt for begge studentene. I begynnelsen av prosjektet var det nok noen missforståelser om hvor mye erfaring vi hadde med å jobbe i et rammeverk. Vi ser at måten prosjektet begynte på gjorde at vi fikk mange tunge stunder når vi skulle lære oss dette rammeverket. Innføringen vi fikk var muntlig og dette gjorde at kunnskapen Startsiden prøvde å gi oss ikke satt skikkelig før vi hadde jobbet en stund med forskjellige eksempler. Dette gjorde at vi tapte tid i henhold til framdriftsplanen. Det var en utfordring å få tid til å gjøre prosjektet så andre fag på skolen og annen jobb i tillegg måtte til tider vike. Alt i alt er vi veldig fornøyd med prosjektet og vi har lært veldig mye. Det var veldig synd at personen som skulle gi oss en innføring i rammeverket og de modulene vi skulle bruke sluttet så tidlig i prosjektperioden. Vi var hele tiden inneforstått med at dette skulle være fase 1 av applikasjonen og dette har vi klart. Vi har endt opp med en fungerene applikasjon som er under testing av redaksjonen. De har kommet med mange positive tilbakemeldinger og virker svært fornøyd med verktøyet de har fått. Applikasjonen er idag fortsatt under testing av redaksjonen og skal være det til utviklingsavdelingen i ABC Startsiden har tid til å implimentere applikasjonen. Dette håper vi vil skje så fort som mulig. Det blir veldig morsomt å se vår applikasjon i bruk. 22

Referanser Catalyst - http://search.cpan.org/~mramberg/catalyst-runtime-5.7013/lib/catalyst.pm DBIx::Class - http://search.cpan.org/~ash/dbix-class-0.08010/lib/dbix/class.pm FormFu - http://search.cpan.org/~dmaki/catalyst-model-formfu-0.01001/lib/catalyst/model/formfu.pm YAML - http://search.cpan.org/~ingy/yaml-0.66/lib/yaml.pm SubVersion - http://subversion.tigris.org/ 23