sfesjl )pfn (sfmmboe t +btnjof &o /joh (bssz t -jof...

Fredrik Hoem Grelland, s135595 Jasmine En-Ning Garry, s135600 Line Sørensen, s135590 Tor Anders Gustavsen, s127668

HOVEDPROSJEKT

HOVEDPROSJEKTETS TITTEL

Sir Jerky Leap

DATO

23. mai 2008

ANTALL SIDER

146

PROSJEKTDELTAKERE

Fredrik Hoem Grelland, s135595

Tor Anders Gustavsen, s127668

Line Sørensen, s135590

Jasmine En-Ning Garry, s135600

INTERN VEILEDER

Eva H. Vihovde

OPPDRAGSGIVER

Aptoma AS

KONTAKTPERSON

Geir Berset

SAMMENDRAG

Oppgaven har gått ut på å lage et innovativt, webbasert grensesnitt for oppgavestyring. Systemet forenkler

jobben med planlegging og styring av prosjekter.

Systemet er primært utviklet for intern bruk hos Aptoma AS, men er utviklet med tanke på videreutvikling for å

legges til i Aptomas produktportefølje. Sir Jerky Leap er utviklet for å være et generisk og modulært system, da

dette er essensielt for systemets hensikt som et avansert oppgavestyringssystem.

I bunnen av applikasjonen ligger en database av typen MySQL. Back-end er utviklet med objektorientert PHP og

arbeidsgivers eget PHP-rammeverk, AFW. Brukergrensesnittet er utviklet ved hjelp av HTML, CSS og JavaScript.

Vi har også benyttet Prototype og Scriptaculous, to JavaScript-rammeverk spesialdesignet for å gjøre websider

dynamiske.

Det har gått med mye arbeid til å lære ny teknologi og forstå nye prinsipper. Resultatet har blitt et

gjennomført produkt som utnytter fordelene med de nye prinsippene og rammeverkene på en god måte.

3 STIKKORD

AFW

Webapplikasjon

AJAX

Studieprogram:

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

2008 - 16

TILGJENGELIGHET

Åpen

Telefon: 22 45 32 00

Telefaks: 22 45 32 05

Forord

Denne rapporten inneholder alle dokumenter som har blitt produsert i forbindelse med vårt hovedprosjekt, Sir Jerky

Leap. Hovedprosjektet er et samarbeid mellom vår oppdragsgiver Aptoma, og Høgskolen i Oslo, avdeling for

ingeniørutdanning. Valget falt på dette prosjektet, da vi likte utfordringene det kunne gi oss. Vi fikk muligheten til å

utvikle et helt nytt produkt, og følge systemutviklingsprosessen fra start til slutt. Utfordringene knyttet til å lære seg

«nye» teknologier og utviklingsmetoder var en annen avgjørende grunn til at dette prosjektet ble valgt.

Rapporten er delt opp i fire hoveddeler; prossessdokumentasjon, produktdokumentasjon, kravspesifikasjon og

testrapport. Hver del har sin egen innholdsfortegnelse, og kan leses som selvstendige dokumenter, uavhengig de andre

delene.

Vi anbefaler likevel å lese prosessrapporten først. På side 6-7 i prosessrapporten gis en kort innføring i selve produktet.

Denne er viktig lesning om man vil danne seg et bilde av produktet og dets funksjonalitet. Prosessdokumentasjonen skal

forøvrig gi et inntrykk av hvordan prosjektet er gjennomført, hvilke valg som er tatt, og hvorfor.

Produktdokumentasjonen gir en teknisk beskrivelse av systemet, og er myntet på de som har behov for å sette seg inn i

systemets oppbygging, funksjonalitet og virkemåte. Denne delen er også ment som et oppslagsverk som kan benyttes

parallelt med prossessdokumentasjonen, og de andre dokumentene for øvrig.

Vedlagt følger en CD-ROM som inneholder all kildekode i prosjektet, samt en digital versjon av denne teksten.

Vedleggene er samlet i sin helhet i siste del av rapporten. Gitt dokumentenes selvstendige karakter, kan og vil det

forekomme gjentakelser i teksten. Fremmedord og tekniske uttrykk er markert i kursiv, og er nærmere beskrevet i

dataordboken, i vedlegg 9. Denne rapporten er optimalisert for papirutskrift.

Systemet kan utprøves på vår demonstrasjonsserver.

URL: http://88.87.34.75/sjl/.

Brukernavn: sensor

Passord: forsensor

Avslutningsvis vil vi sende en stor takk til vår veileder Eva H. Vihovde for all verdifull hjelp og konstruktiv kritikk. En

stor takk går også til Aptoma og Geir Berset for utmerket samarbeid i prosjektperioden.

http://88.87.34.75/sjl/

Sammendrag

Hovedprosjektet Sir Jerky Leap ble utført ved Høgskolen i Oslo, avdeling for ingeniørutdanning, våren 2008. Prosjektet

har gått ut på å utvikle et webbasert grensesnitt for oppgavestyring, til bruk for organisasjoner med behov for effektiv

organisering av prosjekter og oppgaver.

Oppdragsgiver har vært Aptoma AS. Aptomas satsningsområde er dynamiske webapplikasjoner beregnet for

avisselskaper og mediale bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-TV,

visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus.

Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver, føre timer og registrere ferier.

Å jobbe på tvers av 4-5 ulike programmer, er tidkrevende og lite effektivt. Oppdragsgiver hadde ønske om å effektivisere

dette arbeidet, og vi ble bedt om å utvikle et program som kunne være «limet» mellom de ulike programmene. Produktet

vi har utviklet erstatter en del eksisterende funksjonalitet, men introduserer også ny funksjonalitet for å gjøre

oppgavestyringen effektiv. Oppdragsgiver skal etter planen videreutvikle systemet og integrere det ytterligere mot de

andre verktøyene. Dataordboken i vedlegg 9 omtaler disse verktøyene nærmere. For en kjapp innføring i produktet, se

side 6 i prosessrapporten.

Et av systemets store fortrinn er det interaktive brukergrensesnittet. Utviklingen av dette har forutsatt visse kunnskaper

om grafisk design og HCI. Den grafiske utformingen er likevel ikke vårt kjerneområde, og vi stiller ikke med samme

forutsetninger som en profesjonell designer ville gjort.

I prosjektet har vi benyttet en rekke ulike rammeverk. Systemets bakende er utviklet ved hjelp av objektorientert PHP,

godt hjulpet av oppdragsgivers eget rammeverk, AFW. Brukergrensesnittet er laget i HTML og CSS, mens JavaScript har

blitt brukt til å gjøre interaksjonen mellom bakende og brukergrensesnitt dynamisk og asynkron. Til sistnevnte formål har

vi benyttet to JavaScript-rammeverk, Prototype og Scriptaculous. Databasen som ligger i bunn er av typen MySQL.

En av hovedutfordringene har vært å følge prinsippene bak MVC, nemlig å skille kode fra design. Enkelte ganger har

dette vært vanskelig, da noen elementer har befinnet seg i skjæringspunktet mellom hva som er design og hva som er

programkode. Likevel har vi fulgt disse prinsippene så langt det har vært mulig.

Skolen har tidligere kurset oss innen PHP, MySQL og JavaScript. Kursene har imidlertid vært for innføringer å regne, og

de forhåndskunnskapene vi stilte med i forkant, har ikke kunnet måle seg med nivået på utfordingene vi har møtt

underveis. Vi hadde heller ingen erfaring med bruk av de omtalte rammeverkene, og hele gruppen har derfor måttet

fordype seg både i teknologier og rammeverk.

Gruppen har bestått av fire studenter, samtlige fra informatikklinjen på høgskolen. Vi har jobbet sammen ved tidligere

anledninger og har lært hverandre å kjenne, ikke minst når det gjelder kompetansefelt og arbeidskapasitet.

Gruppemedlemmene har i stor grad utfylt hverandre, og arbeidsoppgaver har blitt delegert for best å utnytte den enkeltes

spisskompetanse. I en gruppe med fire medlemmer, delt på tvers av kjønn, vil det nødvendigvis oppstå uenigheter og

konflikter. Å forvente noe annet vil være illusorisk. Vi har likevel bevart et tett samhold og et godt samarbeidsklima,

tross enkelte uenigheter underveis. Alle diskusjoner og uoverenstemmelser tilknyttet prosjektet har blitt løst i plenum ved

hjelp av avstemming.

Hovedprosjektet har uten tvil gitt oss mye, både kunnskaper og erfaringer. Vi har lært om teknologier og

systemutvikling, om samarbeid og prosjektgjennomføring. Viktigst av alt er likevel vissheten om at vi sitter igjen med et

godt produkt. Et produkt i henhold til kravene fastsatt av vår oppdragsgiver.

Innholdsfortegnelse

Prosessdokumentasjon

Produktdokumentasjon

Kravspesifikasjon

Testrapport

Vedlegg

1 Kilder

2 Prosjektskisse

3 Fremdriftsplan

4 Forprosjektrapport

5 Skjermbilder

6 Utvidelser

7 ADP

8 AFW-dokumentasjon

9 Dataordbok

1

Prosessdokumentasjon for Sir Jerky Leap


Jasmine Garry (s135600)

Line Sørensen (s135590)

Fredrik Hoem Grelland (s135595)

Tor Anders Gustavsen (s127668)

2


Innholdsfortegnelse 1. Forord ........................................................................................................................................... 3 2. Innledning .................................................................................................................................... 4

2.1. Gruppen ................................................................................................................................ 4 2.2. Om bedriften ........................................................................................................................ 4

2.3. Bakgrunn for oppgaven ........................................................................................................ 5 2.4. Mål ....................................................................................................................................... 5

3. Sir Jerky Leap! ............................................................................................................................. 6 4. Fasene i prosjekt........................................................................................................................... 8

4.1. Planlegging........................................................................................................................... 8

4.1.1. Innledende arbeid ........................................................................................................... 8 4.1.1.1. Første tanker ........................................................................................................... 9 4.1.1.2. Fremdriftsplan og arbeidsplan ................................................................................ 9

4.1.2. Metode ......................................................................................................................... 10 4.1.3. Kravspesifikasjon ......................................................................................................... 10

4.2. Utviklingsprosessen ........................................................................................................... 11 4.2.1. Kompetansetilegning ................................................................................................... 11 4.2.2. Design .......................................................................................................................... 13

4.2.2.1. Bakgrunn for designet ........................................................................................... 13

4.2.2.2. Utvikling ............................................................................................................... 13 4.2.2.3. Utfordringer .......................................................................................................... 17

4.2.2.3.1. Optimalisering av GUI .................................................................................... 17 4.2.2.3.2. Personlig-visning ............................................................................................. 18 4.2.2.3.3. Innhold i TOC (Table Of Content) .................................................................. 19

4.2.2.3.4. Tab-funksjon .................................................................................................... 20 4.2.2.3.5. Ikoner............................................................................................................... 21

4.2.2.3.6. «Mus-over-funksjonen» .................................................................................. 22 4.2.2.3.7. Mappestruktur ................................................................................................. 22

4.2.3. Implementasjon ............................................................................................................ 23 4.2.3.1. Databasestruktur ................................................................................................... 23

4.2.3.2. Prototype og Scriptacolous. .................................................................................. 25 4.2.3.3. Sorterbare trekkspill-lister .................................................................................... 26

4.2.3.3.1. Bakgrunn ......................................................................................................... 26 4.2.3.3.2. Forarbeide ........................................................................................................ 26 4.2.3.3.3. Utvikling .......................................................................................................... 26 4.2.3.3.4. Utfordringer ..................................................................................................... 27

4.2.3.3.4.1. Interaktivitet ............................................................................................. 27 4.2.3.3.4.2. Brukerdifferansiering ............................................................................... 27 4.2.3.3.4.3. Kondisjonell lasting av innhold ................................................................ 27

4.2.3.3.4.4. Oppdatering av listen................................................................................ 27 4.2.3.3.5. Løsninger ......................................................................................................... 28

4.2.3.3.5.1. Interaktivitet ............................................................................................. 28

4.2.3.3.5.2. Brukerdifferansiering ............................................................................... 28

4.2.3.3.5.3. Kondisjonell lasting av innhold ................................................................ 28 4.2.3.3.5.4. Oppdatering av listen................................................................................ 28

4.2.4. Testing .......................................................................................................................... 29 5. Samarbeid................................................................................................................................... 30

5.1. Samarbeid med oppdragsgiver og sluttbrukerne ................................................................ 30 5.2. Veiledning fra Høgskolen i Oslo ........................................................................................ 30

3


6. Konklusjon ................................................................................................................................. 31

1. Forord Med denne rapporten vil vi fortelle hva vi har gjort og hvordan vi har jobbet for å komme frem til

det endelige produktet. Vi vil utdype og redegjøre for hvilke teknikker og metoder som er brukt for

å komme frem til de ulike løsningene.

Rapporten er beregnet for sensor, veileder og arbeidsgiver, samt andre som har interesse av å sette

seg inn i arbeidsmetodikken vi har brukt. Vi forutsetter at leser er datakyndig.

Prosessdokumentasjonen er delt opp i slik: Innledning, produkt, fasene i prosjektet, samarbeid og

konklusjon. Vi anbefales at dokumentene leses i denne rekkefølgen.

Vi henviser til produktdokumentasjonen som gir en dypere teknisk beskrivelse av produktet og

systemets oppbygning. Vi har lagt ved en ordbok hvor leseren kan slå opp ord og uttrykk som er

nevnt i denne rapporten. I teksten er disse markert i kursiv. Vedlagt ligger også

styringsdokumentene og andre dokumenter som kan være nyttige for å forstå programmet og

prosessen vi har vært igjennom.

4


2. Innledning

Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Vi begynner med å

presentere hvem som har utført prosjektet, etterfulgt av en mer detaljert beskrivelse av bedriften og

bakgrunn for oppgaven. Dette kapittelet avsluttes med målene vi satt for Sir Jerky Leap.

2.1. Gruppen

Gruppen bak produktet Sir Jerky Leap består av Tor Anders Gustavsen, Fredrik Hoem Grelland,

Jasmine En-Ning Garry og Line Sørensen. Gruppemedlemmene har flere ganger jobbet sammen på

prosjekter, og har derfor et godt og innøvd samarbeid. Vi valgte å arbeide sammen også på dette

prosjektet nettopp på grunn av godt samarbeid, at vi utfyller hverandre, har samme ambisjonsnivå

og ønsket samme type oppgave.

Gruppens første utfordring var å finne et passende prosjekt. Vi satt oss ned i fellesskap og gikk

igjennom de prosjektforslagene som forelå på hjemmesiden til dataavdelingen ved Høgskolen i

Oslo. Utviklingsfirmaet Aptoma AS hadde kontaktet skolen og lagt frem to hovedprosjektoppgaver.

Vi fant prosjektoppgaven Sir Jerky Leap interessant, ikke minst på grunn av utfordringene knyttet

til denne oppgaven.

2.2. Om bedriften

Aptoma AS utvikler dynamiske webapplikasjoner, rettet mot større avisselskaper og mediale

bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-tv, visuell

produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus.

Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har VG-TV og Listefeber. I tillegg

har bedriften utviket et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VG-

netts «Rampelys» og den franske nyhetsnettsiden «www.20minutes.fr». Bedriften samarbeider også

med Scanpix/NTB.

5


2.3. Bakgrunn for oppgaven

Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver, føre

timer og registrere ferier. Å jobbe på tvers av mange ulike programmer, er tidkrevende og lite

effektivt. Oppdragsgiver hadde ønske om å gjøre arbeidet smartere, og vi ble bedt om å utvikle et

oppgavestyringsverktøy med vekt på effektivitet.

2.4. Mål

Målet med oppgaven var å lage et solid og innovativt, webbasert grensesnitt for oppgavestyring.

Systemet skal forenkle jobben med planlegging og styring av prosjekter. Sir Jerky Leap, som vi har

utviklet, er i utgangspunktet laget internt for bedriften, men har muligheter for utvidelse slik at det

kan tilpasses andre firmaer med ulike behov. At systemet er generisk og modulært, er derfor helt

essensielt. Det ble stilt store krav til brukergrensesnittet.

Vi ønsket å unngå en applikasjon med for mye informasjon og funksjonalitet på en gang.

Forskjellene mellom en brukervennlig applikasjon og en tung applikasjon blir tydeliggjort i figuren

over.

6


3. Sir Jerky Leap!

Sir Jerky Leap er en webbasert applikasjon i skjæringspunktet mellom en oppgaveliste og et

fullverdig oppgavestyringsverktøy. Programmet egner seg for organisasjoner og privatpersoner med

behov for å administrere oppgaver på en smart og effektiv måte.

Med sitt enkle og intuitive design, gjør Sir Jerky Leap

oppgavestyring enkelt, uten påtrengende elementer.

Ajax-teknologi gir applikasjonen et interaktivt

brukergrensesnitt. Applikasjonen er responsiv og dynamisk,

og bærer i så måte preg av en vindusapplikasjon.

Sir Jerky Leap er utviklet med fokus på enkelthet. Brukeren gis tilgang til de verktøy som til

enhver tid kreves, men ikke mer. Programmets funksjonalitet og valgmuligheter blir

presentert for brukeren basert på kontekst og roller. Man unngår eventuelle forvirrelser, og

reduserer grensesnittets kompleksitet.

Prosjekter og underprosjekter, med tilhørende oppgaver blir

strukturert hierarkisk. Strukturen gjør det enkelt å navigere

seg frem og tilbake mellom ulike prosjekter og oppgaver.

Oppgaver gis innhold etter eget ønske. Dette er foreløpig

begrenset til tekst og bilde, men kan i prinsippet være alle

typer data.

Oppgaver tilknyttet innhold får sin egen innholdsfortegnelse, heretter kalt TOC (table of

contents). Innholdsfortegnelsen i ekspandert form, gir en formattert visning av oppgavens

innhold, og egner seg ypperlig som dokumentasjon til den

enkelte oppgave.

Prosjekter og oppgaver, samt innhold i TOC, kan enkelt

sorteres og flyttes på med dra-og-slipp-metoden.

7


Som første produkt innen genren, legger Sir Jerky Leap opp til

fanebasert arbeidsflyt. Alle prosjekter og oppgaver, uansett

hierarkisk plassering, kan åpnes i faner. Man holder lettere

oversikt, og bevarer simplisiteten i brukergrensesnittet.

Sir Jerky Leap gjør det enkelt å delegere arbeidsoppgaver.

Brukere med administrative rettigheter kan ved få museklikk

tildele andre brukere oppgaver.

“Make everything as simple as possible, but not simpler.”

- Albert Einstein

8


4. Fasene i prosjekt

Denne delen av dokumentet omhandler de forskjellige fasene vi har vært gjennom for å komme

frem til det endelige produktet. Kapittelet er delt opp i fire deler: planlegging, utvikling,

utfordringer og dokumentasjon.

4.1. Planlegging

Vi vil her forsøke å gi et innblikk i hvordan vi valgte oppgaven, hvordan planleggingsfasen har

vært, og hvilke beslutninger som ble tatt og hvorfor.

4.1.1. Innledende arbeid

Tidlig i november 2007 tok vi kontakt med Geir Berset ved Aptoma AS, angående prosjektet Sir

Jerky Leap. Firmaet hadde ennå ikke engasjert noen gruppe til oppgaven og vi ble innkallt til et

møte. Vi syntes oppgaven hørtes spennende ut og bekreftet kort tid etter at vi gjerne ville ha

prosjektoppgaven. Det ble opprettet en Aptoma-mailadresse og en egen konto på Aptoma AS sitt

intranett for hver av oss. Dette gjorde at vi fikk tilgang til dokumenter og lignende som kunne være

aktuelle for prosjektet.

Vi var i gang med planleggingen i januar, og vi ble raskt enige om at vi skulle ha en kjernetid alle

ukedager mellom 10:00 og 15:00, med mindre man hadde gyldig fravær. Eventuelle fravær skulle

på forhånd legges inn i Google Kalender og godkjennes av de øvrige gruppemedlemmene. Da vi er

en morgentrøtt gjeng fant vi ut at vi måtte bli enige om en måte å få alle på skolen tidsnok. Vi ble da

enige om å «bøtelegge» hver person med 50 kr per halvtime han/hun var forsinket. Pengene i denne

potten skulle gå til sosiale sammenkomster for alle gruppemedlemmene.

Gruppen startet på første fasen av prosjektet, forprosjektet, rett etter nyttår. Vi avtalte et møte med

veileder, Eva Hadler Vihovde, og ble enige om ukentlige møter inntil vi var godt igang med

implementasjonen. Oppdragsgiver hadde lagt ut en kravspesifikasjon på intranettet og denne gjorde

at vi kom raskt i gang med vår forprosjektrapport. Underveis i arbeidet med denne rapporten fant vi

en god del ting i oppdragsgivers kravspesifikasjon som vi ville endre. Vi kontaktet da

oppdragsgiver og la frem våre ideer. Oppdragsgiver var som oftest enig i våre forslag. Hvis ikke,

ble det inngått et kompromiss.

9


4.1.1.1. Første tanker

Allerede ved første titt på oppgaven Sir Jerky Leap visste vi at det kom til å bli et utfordrende og

spennende prosjekt. Vi hadde mange meninger om prosjektet og om hvordan vi kunne løse det. Vi

så med en gang store muligheter for Sir Jerky Leap og lagde oss tanker rundt hvordan vi skulle

utvikle et webbasert oppgavestyringsverktøy med de kravene oppdragsgiver hadde satt.

Oppdragsgiver var veldig klar på at vi skulle bruke mye tid på å tenke, resonnere, diskutere, forske,

og planlegge. Vi måtte vurdere allerede eksisterende oppgavestyringsverktøy, evaluere de og finne

bedre løsninger på den samme funksjonaliteten. Det var ikke meningen at Sir Jerky Leap skulle

utvikles å framstå som et ferdig produkt innen 23. mai, men derimot leveres med en solid

«oppbygging», som lett skal kunne videreutvikles.

Vi visste at det ville oppstå problemer underveis, da det var mye nytt å sette seg inn i. Vi var

forberedt på å håndtere alle de utfordringer som måtte komme.

4.1.1.2. Fremdriftsplan og arbeidsplan

Fremdriftsplanen ble satt opp tidlig i prosjektet, men den var noe ufullstendig. Det ble utviklet en

overfladisk fremdriftsplan, med hovedpunkter om når hver enkelt prosjektdel burde være ferdig.

Sammen med fremdriftsplanen lagde vi en overordnet arbeidsplan. Vi var litt usikre på hva som

lønte seg å starte med. Etterhvert som vi kom i gang med prosjektet, var det lettere å se hva som

skulle gjøres og i hvilken rekkerfølge, og fremdriftsplanen og arbeidsplanen ble utvidet og

ferdigskrevet. Begge disse dokumentene har blitt brukt aktivt gjennom hele

prosjektgjennomføringen.

10


4.1.2. Metode

Aptoma AS har utvilket en egen utviklingsprosess som de har kalt ADP – Aptoma Development

Process. Oppdragsgiver så helst at vi fulgte denne prosessmetoden. Denne metoden går i korthet ut

på at all planlegging skal skje først. Deretter skal brukegrensesnittet designes før noe kode på

bakende implementeres. Testing skal skje kontinuerlig gjennom hele prosjekttiden. Under vises en

figur av Aptoma Development Process:

For nærmere beskrivelse av Aptoma Development Process, se vedlegg nr. 7.

4.1.3. Kravspesifikasjon

Kravspesifikasjonen har vært et viktig dokument gjennom prosjektfasen og har blitt utarbeidet etter

oppdragsgivers ønsker. Det fantes et utkast til kravspesifikasjonen som vi fikk da vi påbegynte

prosjektet. Da denne var noe ufullstendig og vi hadde noen innvendinger, avtalte vi et møte med

oppdragsgiver. Dette var en viktig prosess for å få frem hva deres ønsker for systemet, Sir Jerky

Leap, var. Sammen med oppdragsgiver ble funksjonene fastsatt.

Systemets rammebetingelser var i hovedsak predefinert av oppdragsgiver. Vi stod imidlertid fritt når

det gjaldt valg av blant annet IDE og modelleringsverktøy, og det var opp til gruppen å finne gode

løsninger på dette.

Det var først når vi fikk et overblikk over systemet og kunne begynne å se for oss hvordan det

skulle fungere, at vi kunne ta funksjonalitetsavgjørelser. Produktet samsvarer med

kravspesifikasjonen, slik som den er per i dag. Kravspesifikasjonen finnes i sin helhet senere i

11


sluttdokumentasjonen.

4.2. Utviklingsprosessen

Dette kapittelet omhandler de ulike utviklingsfasene vi har vært igjennom. Det blir beskrevet

utfordringer og valg vi stod overfor, hvilke løsninger vi vurderte og hvilke løsninger vi valgte.

4.2.1. Kompetansetilegning

Denne delen tar for seg hvilke verktøy og teknologier vi har tatt i bruk, samt hvilke teknologier som

var ukjente for oss og hvilke vi måtte fordype oss i.

På forhånd ble det gitt en del konkrete krav til funksjonalitet, samt visse krav til tekniske løsninger.

Det ble blant annet satt føringer for hvilke språk og rammeverk vi skulle bruke. I bunnen av

applikasjonen ligger en database av typen MySQL. Back-end er utviklet med objektorientert PHP

og arbeidsgivers eget PHP-rammeverk, AFW. Brukergrensesnittet er utviklet ved hjelp av HTML,

CSS og JavaScript. Vi har også benyttet Prototype og Scriptaculous, to JavaScript-rammeverk

spesialdesignet for å gjøre websider dynamiske. Applikasjonen er optimalisert for Mozilla Firefox,

da denne webleseren har implementert de fleste webstandarder. Her følger en detaljert oversikt over

de ulike verktøyene og språkene vi har tatt i bruk:

Programvare / Teknologi Beskrivelse

Apache HTTP Server 2.2.8 Webserver

PHP 5.2.5 Programmeringsspråk (server-side)

MySQL 5.0.45 DBMS (database management system)

Memcached 1.2.5 System for caching av databasekall på webserver

Prototype 1.6 Rammeverk som gir objektdreven tilnærming til JavaScript

Scriptaculous 1.8.1 JavaScript-rammeverk basert på Prototype.

Zend Studio 6.0 BETA Integrert utviklingsmiljø for PHP, basert på Eclipse.

DBDesigner 4.0 Databasemodelleringsverktøy for MySQL

Navicat 8 for MySQL Databaseadministreringsverktøy for Windows

Mozilla Firefox 2.0.0.x Webleser

Firebug 1.x Utviklingsverktøy for Mozilla Firefox

12


Tortoise SVN 1.4.x Versjonskontroll

Merk: Utfyllende informasjon om de ulike teknologiene finnes i ordboken, vedlegg nr. 9.

Skolen hadde allerede kurset oss med innføringer i de fleste av disse teknologiene. Det var likevel

et stort gap mellom hva vi hadde lært på forhånd, og hva som trengtes av kunnskaper for å ta fatt på

oppgaven. Basiskunnskapene har trolig gjort læringskurven noe slakere enn den ellers ville ha vært,

men vi har likevel måttet fordype oss ytterligere, ikke minst innen PHP og JavaScript.

Tidligere har vi benyttet PHP til å lage enkle kodesnutter for å gi websider dynamisk innhold. Vi

har aldri tatt i bruk objektorientert PHP, noe som er strengt nødvendig på et prosjekt av dette

omfanget.

PHP er et høynivåspråk hvis syntaks minner mye om Java og C++. Våre tidligere erfaringer med

objektorientert utvikling i blant annet Java, gjorde overgangen til PHP relativt enkel. Rammeverket

AFW, produserer objekter basert på tabeller i databasen, og legger i så måte opp til objektorientert

programmering.

I forkant var våre kunnskaper om JavaScript begrenset til det mest basale, og i forhold til denne

oppgaven svært mangelfulle. Et av hovedmålene var å gi applikasjonen et sofistikert

brukergrensesnitt. Vi ville viske ut forskjellene mellom en typisk webapplikasjon og en

vindusapplikasjon, og tilby brukeren det dynamiske og responsive brukergrensesnittet som ofte

preger sistnevnte. Dette kan ikke gjøres uten en kontinuerlig og massiv manipulering av DOM [23]

,

og det er her JavaScript kommer til sin rett. Rammeverket Prototype er utviklet med tanke på dette

formålet, og har vært uvurderlig i utviklingen av applikasjonen. Rammeverket Scriptaculous er

igjen basert på Prototype, og har hovedsakelig blitt brukt til visuelle effekter.

Alle teknologiene vi har benyttet oss av ligger åpne for allment bruk, og er stort sett grundig

dokumentert. Det har derfor ikke vært nødvendig å bruke andre oppslagsverk.

13


4.2.2. Design

Her blir designfasen beskrevet. Den tar for seg noen av de viktigste avgjørelsene vi har har tatt,

hvilke løsninger vi har valgt samt hvorfor vi valgte disse.

4.2.2.1. Bakgrunn for designet

Hovedkravet til oppdragsgiver var at Sir Jerky Leap skulle være et brukervennlig program. Firmaet

ville at alle skulle kunne bruke programmet og at det ikke kun var forbeholdt datakyndige. Ellers

hadde de ingen krav til hvordan brukergrensesnittet skulle være. Vi stod derfor fritt til å designe

dette.

Ansatte ved Aptoma AS har til nå benyttet seg av oppgavestyringsverktøyet Streber, men de finner

brukergrensesnittet til dette programmet lite brukervennlig. Det de var mest misfornøyde med, var

at all funksjonaliteten var tilgjengelig til enhver tid. De fant dette meget forstyrrende og ønsket

derfor å utvikle et nytt oppgavestyringsverktøy, Sir Jerky Leap.

Vi hentet inspirasjon fra applikasjoner som har liknende formål. Vi testet disse og fant ut hvilke

funksjonaliteter vi fant nyttige og hvilke vi ikke likte.

4.2.2.2. Utvikling

Sir Jerky Leap har vært igjennom en spennende designutvikling. Det har vært en lang vei fra å bare

eksistere på papir til å bli et webbasert, brukervennlig produkt. Oppdragsgiver ga oss to bilder til

inspirasjon, AccordionEditList og en skisse på hvordan «Edit mode» kunne se ut. Disse bildene

vises her:

14


AccordionEditList

15


«Edit mode»

Utifra disse bildene og de andre prosjektstyringsverktøyene vi testet, laget vi flere papirprototyper

av hvordan Sir Jerky Leap kunne se ut. En av de første papirprototypene vi utviklet så slik ut:

16


I det første utkastet var all funksjonaliteten synlig til enhver tid. Dette virket forstyrrende og det ble

for mye funksjonalitet å forholde seg til for bruker.

Etterhvert så vi at det måtte settes noen begrensninger i programmet. Alle brukere kunne ikke ha

tilgang til alle funksjoner, da dette kunne misbrukes. Andre brukere kunne for eksempel slette

oppgaver uten å ønske det. Vi bestemte oss derfor for å ha tre bruker-nivåer;

administrator

bruker som er tilegnet en oppgave

bruker

Det er nå begrensninger på hva brukerne kan se og gjøre. Dette gjorde at Sir Jerky Leap ble mer

oversiktlig.

De første papirprtotypene inneholdt en «rullegardin-meny» med funksjoner som «Add», «Edit» og

lignende. Brukermessig fant vi denne funksjonaliteten tungvinn, og endte i stedet opp med å bruke

en administratorlinje. Dette førte til at brukeren lett kan se hvilke funksjonaliteter som er

tilgjengelig. Her er et skjermbilde på hvordan Sir Jerky Leap nå er blitt;

17


4.2.2.3. Utfordringer

Å designe et brukervennlig brukergrensesnitt har vært den største utfordringen gjennom hele

prosjekttiden. Listen under viser noen av utfordringene vi har stått ovenfor i prosjektet.

4.2.2.3.1. Optimalisering av GUI

Dette har uten tvil vært den største utfordringen vi har hatt. Vi har gjennom hele

prosjektgjennomføringen hatt i tankene at brukerkvaliteten er avgjørende for sluttproduktet og

suksessen til produktet. Aptoma AS har til nå benyttet fem forskjellige programmer for

oppgavestyring, og ønsket et program som var lett å bruke, men allikevel hadde mye funksjonalitet.

Det å hele tiden ha fokus på brukervennligheten har derfor vært en utfordring ved utvikling av ny

funksjonalitet og implementering av dette. Vi tok en avgjørelse på å holde designet minimalistisk og

enkelt. Fargene og stilen er gjennomgående for hele systemet, noe som gjør at bruker «kjenner seg

igjen» når han beveger seg rundt i programmet. For å få best mulige brukerkvaliteter er grundig

testing utført.

18


4.2.2.3.2. Personlig-visning

I «Personal» vises de prosjektene og oppgavene brukeren er blitt tilegnet. En stor utfordring var å

finne en måte å presentere disse på, uten å presentere for mye informasjon på en gang. En bruker

kunne ikke være tilegnet oppgaver som var over bunnivå, det vil si at det måtte være en oppgave

med TOC. Vi valgte å presentere disse i tre lister, en «My assigned tasks», «My assigned tasks with

administrative privileges» og «My tasks with administrative privileges». Vi fant dette nyttig da en

bruker nødvendigvis ikke jobber på en oppgave som han er administrator for. «Brødsmulene»

forteller bruker hvilket prosjekt oppgaven ligger under. Oppgavene ligger som linker i listen og da

bruker trykker på disse, åpner oppgavene seg i en ny tab. Personligvisning vises her:

19


4.2.2.3.3. Innhold i TOC (Table Of Content)

Denne visningen var ment å erstatte dagens bruk av Wiki, det vil si et dokument som var lett å jobbe

med. Utformingen av denne visningen viste seg å bli mer utfordrende enn vi hadde forventet oss. I

de første papirprototypene ble disse tegnet som en «oppslagstavle» med innholdsbokser som kunne

flyttes. Oppslagstavlen blir vist i skissen:

Ved nærmere ettertanke fant gruppen og oppdragsgiver dette oppsettet uoversiktig. Vi ble istedet

enige om å presentere oppgavens innhold ved hjelp av en TOC (Table Of Content). Denne ble vi

enige om at skulle vise tittelen på innholdsobjektene i oppgavene, med et symbol for type

innholdsobjekt (tekst/bilde) som vist i skissen under:

20


Vi videreutviklet denne løsningen, og under vises slik den ser ut i programmet:

4.2.2.3.4. Tab-funksjon

En annen stor utfordring var å presentere prosjekter og oppgaver uten å overlesse brukeren med

informasjon. Vi valgte en løsning hvor brukeren hadde mulighet til å åpne en liste over prosjekter

gjennom «Projects -knappen», og umiddelbart kunne navigere seg nedover i trekkspillisten med

prosjekter og oppgaver. Alle oppgaver, prosjekter, og tilhørende funksjonalitet er tilgjengelig i

denne modusen. Dette tar mye skjermplass, og ved store prosjekter kan brukeren miste oversikten.

Med tab-funksjonaliteten tilgjengelig, kan man velge å åpne oppgaver i en ny tab og på denne

måten ha bedre kontroll på hva man jobber med. I tab'en står tittelen på oppgaven som er åpnet og

tittel på overordnet oppgave følger med som brødsmuler. Ved åpning av oppgave i tab eller

oppdatering av innhold i tab, blir brukeren gjort oppmerksom på dette gjennom en

21


oppdateringsindikator.

4.2.2.3.5. Ikoner

Vi har valgt å bruke bildeikoner ved de forskjellige funksjonene. Målet med disse var at brukeren

skulle forstå hva funksjonen gjorde uten å nødvendigvis lese teksten, og ikonvalg var derfor viktig.

Valgte ikoner vises i tabellen under:

Add administrator

Administrator på oppgave

Assign bruker

Assignet til oppgave

Aministrator og assignet til oppgave

Prosjekt (mappe med innhold)

Edit tittel på prosjekt

Add/edit detaljer

Move to tab

Add oppgave

Oppgave

Oppgave med underoppgaver

Åpen oppgave

Add tekst

Tekst i TOC

Add bilde

Bilde i TOC

Open/close TOC

Slette

Lukke tab

Accept/OK

Cancel

Brødsmuleindikator

22


4.2.2.3.6. «Mus-over-funksjonen»

Da det er mye funksjonalitet i applikasjonen måtte vi finne en løsning som skjulte noe av dette, slik

at det ikke ble uoversiktelig. Vi valgte «mus-over-funksjon». Nå brukeren navigerer seg igjennom

applikasjonen blir ikoner, og dermed også funksjonalitet, tydeligere når musepekeren treffer disse.

4.2.2.3.7. Mappestruktur

Dette var en funksjon vi valgte fordi det er noe de fleste brukere kan relatere seg til. Alle som har

brukt Windows er vant med å navigere seg igjennom en slik struktur.

23


4.2.3. Implementasjon

Denne delen av dokumentet beskriver de største utfordingene vi møtte på, valgene vi stod ovenfor,

hvilke løsninger vi vurderte samt hvilke løsninger vi valgte.

4.2.3.1. Databasestruktur

Fra starten var det enighet i gruppen om at Sir Jerky Leap kom til å bli en klar databasedrevet

applikasjon, og dermed satt vi relativt tidlig i gang med å utforske hvilken databasestruktur vi

trengte for å løse utfordringen vi sto ovenfor. Det viste seg snart at systemet trengte en sortert

hierarkisk trestruktur, og dette skulle vise seg å bli vår første store utfordring. De fleste vanlige

databasesystemer har per i dag ikke integrert støtte for foreldre-barn strukturer, og tilbyr kun en flat

datastruktur basert på tabeller. For å kunne jobbe opp mot en database med en slik struktur må en

dermed implementere sin egen logikk i datalageret, og deretter bearbeide disse dataene

programatisk i etterkant.

Vi så på flere mulige løsninger, fortrinnsvis disse;

1. Forelderpeker i barnet (Stakk).

2. Preordens-traversering med nodenummerering.

3. Brødsmule-indikator.

Nummer to på listen er den mest elegante løsningen, da vi kunne benytte rekusjon for å traverse

treet. Ettersom vi leste videre om denne løsningen viste det seg at denne varianten er rask på å hente

data, men vinningen går opp i spinningen ved at metoden benytter mye prosesseringskraft på å sette

inn, sortere eller slette data ved store datamengder. Dette grunnet at en må endre nummerering på

potensielt n-1 av n oppføringer.

Nummer tre på listen «brødsmuleindikator» er benyttet av flere forumvarianter, som også er

hierarkisk strukturert av natur, og baserer seg på at barn arver sin forelders brødsmuleliste, og

legger deretter til forelderen i denne listen. Slik vil en ha oversikt over hvor i hierarkiet en postering

er relativt til sin forelder. Vi valgte ikke denne varianten da vi har behov for sortering av foreldre og

barn, og et ønske om å vite hvilket nivå en oppgave er lokalisert på.

Vi valgte en variant av nummer en på listen, som har foreldrepeker, sorteringindikator, og

nivåindikator. Dette gjør at vi kan sortere en foreldergren av datalageret uten å endre flere

posteringer enn nødvendig. Videre er det, ved å inspisere en forelders datafelter, effektivt å legge til

24


nye barn.

AFW tilbyr et relativt godt abstraksjonslag mellom datalager og rammeverket, hvor en hver

tabelloppføring eksponeres i form av et refleksivt objekt av samme klasse som databasetabell-

navnet. Et hvert objekt opprettet av AFW-rammerverket får også sin egen unike identifikator, en

såkalt AFWId, og kan hentes ut hvor som helst i applikasjonen basert på dette nummeret.

I lys av dette valgte vi å basere interaksjonen mellom webgrensesnittet og bakenden av

applikasjonen på utveksling av AFWId'er.

Komplikasjonene med en slik tilnærming viste seg snart, da AFW ikke har noen form for å hente ut

hierarkiske data slik vi trengte. Vi lagde dermed en egen uthentingsrutine for å hente ut

oppgavetreet, men denne viste seg å være nokså tidkrevende.

Vi måtte videre påse at AFWId'en i webgrensesnittet alltid var en referanse til et faktisk objekt i

bakenden, og antok i utgangspunktet at AFW tildelte samme AFWId til en oppføring i datalageret

hver gang denne ble hentet. Dette viste seg fort å være gale forutsetninger, og vi vurderte å gå bort

fra AFW som enhet for objektidentifikasjon.

Etter konsultasjon med hovedutvikler på Aptoma AS ble vi gjort oppmerksomme på MemCached,

en applikasjon som kan fungere som et persisterende lag mellom webgrensesnittet og

applikasjonen. MemCached lagrer data i minnet på serveren, og er per i dag stort sett kun i bruk i

miljøer hvor samme, prosessorkrevende operasjon, gjøres meget hyppig. Et typisk eksempel på en

slik operasjon er å vise forsiden på en større nettavis.

I vår applikasjon har vi en slik prosessorkrevende operasjon ved hver eneste sidevisning, og dermed

valgte vi å minske denne lasten ved å legge oppgavetreet i minnet på serveren, og manipulere dette

parallelt med databaselaget. Dette viste seg å kreve betydelig mindre av serveren, og førte også til at

vi kunne sikre at samtidige brukere jobber på samme datasett.

25


4.2.3.2. Prototype og Scriptacolous.

Prototype er et rammeverk for Javascript som tilbyr objektdreven tilnærming til Javascript, og

utvider DOM med et vell av nyttige metoder for hurtig og oversiktelig manipulasjon av klienten i en

dynamisk webapplikasjon. Videre tilbyr Prototype kraftige Ajax-verktøy for oppdatering og

uthenting av informasjon dynamisk.

Scriptaculous er basert på Prototype og leverer ferdigutviklede komponenter som ved hjelp av

Javascript, CSS og Ajax-kall tilbyr funksjonalitet som; dra-og-slipp, autooppdaterende

nedtrekksmenyer, med mange flere.

Sir Jerky Leap er tungt basert på Scriptaculous og Prototype. All oppdatering av siden baserer seg

på Ajax-kall, og sortering av oppgave- og innholdslister er realisert med Scriptaculous Sortable

kombinert med egendefinerte metoder for å hente ut relevante data.

Den største utfordringen med å jobbe med Prototype og Scriptaculous har vært å debugge

egenskrevet kode. Tiltenkt bruk og parametere er godt dokumentert, men selve metodikken bak

koden er som oftest ikke dokumentert. Med bruk av predefinerte metoder på utradisjonelt vis, kode

som i stor grad hadde avhengigheter og mangel på gode debugingsverktøy, gikk mye av tiden med

til å inspisere DOM og saumfare kryptisk kode for å finne årsaken til eventuelle problemer.

Den største utfordringen vi møtte på var å påse at Scriptaculous sortable fungerte i hierarki, og at

oppdatering og utbytting av én sortable ikke forstyrret, og skapte problemer med de andre. Etter

mye prøving og feiling viste det seg at ved utbytting av en sortable måtte alle parametre og id'er

være identiske. Dette er nødvendig for å få slettet den foreldede listen fra DOM. Det ville vise seg at

denne oppførselen inntraff ved uønskede og ulogiske tilfeller, og førte til at vi måtte utvide Sortable

for å unngå at sortable-lister forstyrret hverandre ved oppdatering av lister som befant seg innenfor

samme nodetre i DOM.

Vår noe uvanlige tilnærming til navigasjon i applikasjonen gjennom bruk av både statiske

funksjoner og faner som representerer innhold, skapte en utfordring i å beholde tilstand i

applikasjonen på tross av at vi arbeider med en tilstandsløs protokoll. Ved hjelp av utstrakt bruk av

Prototype for å inspisere DOM og identifisere elementer i en bestemt tilstand (eks. Åpen, aktiv, i

endring, sortering, med flere) kunne vi sende tilstandsinformasjon av berørte elementer ved

oppdatering av innhold.

26


Uten Prototype og Scriptaculous ville vi ikke vært i stand til å levere en dynamisk webapplikasjon

på den tiden vi hadde til rådighet.

4.2.3.3. Sorterbare trekkspill-lister

Sir Jerky Leap benytter trekkspill-lister, heretter kalt en Accordion, for å representere oppgavelister.

4.2.3.3.1. Bakgrunn

Store deler av utfordringen vi fikk fra Aptoma AS gikk ut på å produsere et grensesnitt som var så

lite påtrengende som mulig, og lot brukeren følge sin egen arbeidsflyt. «Programmet skal tilpasse

seg brukeren.» Tilsvarende produkter, på nettet eller i skrivebordsmiljø, krever i høy grad at du

bokstavlig talt fyller ut et skjema for å opprette, endre, eller administrere oppgaver. Denne

metodikken gir brukeren liten grad av frihet til å jobbe iterativt på en oppgave, og kan føre til

mange sidevisninger og repetative oppgaver.

4.2.3.3.2. Forarbeide

Fra oppdragsgivers side var det et ønske om bruk av Accordion for å sortere oppgaver.

Inspirasjonen for denne tilnærmingen var en Accordion basert på

Scriptaculous,[http://www.stickmanlabs.com/accordion/], laget av Stickmanlabs. Aptoma AS hadde

laget en egen, sorterbar, variant av denne accordionen, AccordionEdit. For å minske

utviklingsbyrden var våre intensjoner å benytte denne i Sir Jerky Leap.

4.2.3.3.3. Utvikling

AccordionEdit er en hendig tag for å produsere en sorterbar liste som har en tittellinje og innhold.

Innholdet kommer til først til syne ved å klikke på tittellinjen og lukker seg ved å åpne en annen.

AccordionEdit har mange nyttige funksjoner, slik som; automatisk oppdatering ved endringer,

innlasting av innhold ved behov, søkefunksjonalitet og navigasjon med hurtigtaster. Det viste seg

snart at vi ikke kunne benytte disse ekstrafunksjonene, og at utvidelse av selve

http://www.stickmanlabs.com/accordion/

27


grunnfunksjonaliteten var nødvendig for å møte de kravene vi hadde til listen.

4.2.3.3.4. Utfordringer

4.2.3.3.4.1. Interaktivitet

Vi trengte en interaktiv liste, med ekstrafelter og knapper, noe man ved utviklingen av

AccordionEdit ikke hadde tatt høyde for. Mulighet for sortering av listen skulle også kunne skrues

av og på, og selve «dra-og-slipp»-funksjonaliteten skulle tilegnes et eget felt.

4.2.3.3.4.2. Brukerdifferansiering

Brukere med forskjellig tilgangsnivå skulle kun ha tilgang til, og vise de funksjoner som er

tilgjengelige for brukeren.

4.2.3.3.4.3. Kondisjonell lasting av innhold

Innhold i elementer skal lastes inn på bakgrunn av hva slags type element det er. For at dette skulle

fungere, måtte listen kunne skille mellom en liste med oppgaver, heretter kalt listeelement, og en

enkeltstående «bunnoppgave». En «bunnoppgave» har et annet utseendet og funksjonalitet enn et

listeelement, men skal kunne gjøres om til et listeelement hvis ønskelig. Bunnelementer skal også

kun lastes inn i sin helhet ved behov

4.2.3.3.4.4. Oppdatering av listen

Det skulle være mulig å oppdatere deler av listen med nytt eller endret innhold.

28


4.2.3.3.5. Løsninger

4.2.3.3.5.1. Interaktivitet

For å gjøre AccordionEdit interaktiv ble vi tvunget til å utvide selve Javascriptkoden og legge inn

våre egne funksjoner. Når man klikket på et accordionElement ville listelementet åpne eller lukke

seg, avhengig av kontekst. Dette skjedde også om vi trykket på ekstraelementene vi hadde lagt inn i

listeelementet. Dette skjedde på grunn hendelsesbobling i Javascript, og måtte avbrytes i

hendelseslytteren. I hendelseslytteren sjekket vi hvilket ekstraelement som var trykket på, utførte

tilhørende operasjoner, og avbrøt hendelsen.

4.2.3.3.5.2. Brukerdifferansiering

Ved å endre templatene, HTML-koden som produseres av Accordion, brukt til å vise listene til å

motta brukerinformasjon kunne vi utelate de elementer som ga brukeren mulighet til å endre på en

liste.

4.2.3.3.5.3. Kondisjonell lasting av innhold

AccordionEdit hadde en metode for å laste innhold i et listeelement ved åpning av listeelementet,

men var ikke laget med tanke på hierarkiske lister og ga lite frihet med tanke på hva som oppdateres

ved innlasting. Vi valgte derfor en tilnærming hvor innlasting av lister og listeelementer med lister

alltid lastes inn, mens «bunnelementer» lastes inn ved behov. Dette løste vi ved å utvide

AccordionEdit til å kjøre et Ajax-kall som lastet innhold og andre elementer etter behov.

4.2.3.3.5.4. Oppdatering av listen

Ved endringer, eksempelvis ved sortering, tillegging og sletting av et listeelement, i en liste var det

nødvendig å oppdatere denne. Grunnet at AccordionEdit ikke var tilrettelagt hierarkiske lister lå

mye av utfordringen på å beholde sorteringsfunksjonaliteten ved oppdatering. AccordionEdit var

utviklet slik at elementer først lastes synlige inn i nettleseren for så i andre rekke å manipuleres i

DOM for å lukke elementene som ikke skal være synlige for brukeren. Dette skapte en flimmer-

effekt på skjermen som trakk fokus fra brukeren, og skapte et inntrykk av at noe var galt. Det viste

seg å være en stor oppgave å endre denne oppførselen direkte i AccordionEdit, og vi valgte dermed

en tilnærming hvor alt innhold som lastes inn dynamisk, skjules og erstattes med en

29


innlastingsindikator.

4.2.4. Testing

Testrapporten ligger vedlagt i sin helhet senere i sluttdokumentasjonen. Testfasen er en viktig fase,

da det å levere et produkt uten store kodefeil er vesentlig for hvordan det oppleves for sluttbrukeren.

Det er nær umulig å levere et helt feilfritt produkt, derfor er det viktig å dokumentere hva vi testet

og hvordan. Dette gjør det lettere å vedlikeholde produktet og lettere å finne eventuelle feil som

oppstår senere.

Vi testet først brukergrensesnittet, da brukervennlighet var en viktig del av prosjektet. Vi begynte

med papirprototyper som senere utviklet seg til en HTML-prototype. Funksjonaliteten til designet

har blitt testet og godkjent av oppdragsgiver. Da vi var ferdig med programmet ble Sir Jerky Leap

testet av oppdragsgiver og sluttbrukerne for å få en bekreftelse på brukervennligheten.

Vi har testet for feil i kode kontinuerlig gjennom hele implementasjonsfasen. Etterhvert som

funksjoner ble ferdigstilt, testet vi ut disse. Dette viste seg å være til stor hjelp, da vi oppdaget

ganske fatale feil under denne testingen. Dette ble rettet opp før vi fortsatte arbeidet med andre

funksjoner. I denne fasen ble FireBug brukt aktivt. Denne viste om og hvor eventuelt feilen(e)

oppstod.

30


5. Samarbeid

Her beskrives samarbeidet mellom gruppen og veileder samt gruppens samarbeid med

oppdragsgiver.

5.1. Samarbeid med oppdragsgiver og sluttbrukerne

Vi har hatt et veldig positivt samarbeid med vår oppdragsgiver, Aptoma AS. Vi fikk tilbud om å

bruke deres lokaler, men da det stadig dukket opp ting vi måtte diskutere, og firmaet har et åpent

kontorlandskap bestemte vi oss for å reservere et grupperom på skolen. Dette rommet har vi

benyttet oss av så og si hver dag.

Vi hadde regelmessige møter med oppdragsgiveren der vi la frem forslag og løsninger til Sir Jerky

Leap. Vi fikk skryt og konstruktiv kritikk på ting vi hadde gjort bra eller mindre bra. Utenom

møtene hadde vi alltid mulighet til å kontakte både oppdragsgiver og de ansatte ved Aptoma AS for

å få tips og råd. Dette kunne skje over Skype, telefon eller mail. Dette viste seg å være veldig nyttig

for oss da vi skulle ta i bruk rammeverk og programmer som de har utviklet, og integrere vårt

produkt med disse.

5.2. Veiledning fra Høgskolen i Oslo

Vi ble tidlig enige med vår veileder, Eva Hadler Vihovde, at vi skulle ha ukentlige møter. På disse

møtene fikk vi veiledning om hvordan vi burde gå frem, hva som burde prioriteres, hvor lang tid vi

burde bruke på hver fase av prosjektet osv. I tillegg har vi sett på veiledningen til utvikling av

prosjektdokumentasjonen som meget nyttig. Vi hadde aldri vært borti et så stort og viktig prosjekt,

og vi har av den grunn ikke skrevet prosjektdokumentasjon på denne måten før. Vi har hatt god

kommunikasjon med vår veileder, og har fått god hjelp til å løse de utfordringene vi har stått

ovenfor.

Veilederen vår har allerede begynt å snakke med oss om veiledning til fremføringen, og vi har tro på

at det gode samarbeidet mellom oss og veileder vil fortsette helt til prosjektets slutt.

31


6. Konklusjon

Sluttproduktet, Sir Jerky Leap, har gruppen planlagt og utviklet på egenhånd, med unntak av

enkelte krav til funksjonalitet og brukergrensesnitt som oppdragsgiver hadde på forhånd. De ansatte

på Aptoma AS kan nå opprette prosjekt og oppgaver med tilhørende underoppgaver eller TOC. Hva

en bruker kan gjøre er avhengig av hvilke rettigheter han/hun har.

At prosjektet har vært utfordrende er det ingen tvil om. Det å sette oss inn i nye rammeverk og

prinsipper har vært en større jobb enn vi trodde. Måten vi taklet utfordringene på har vist seg å være

en viktig del av læringsprosessen. Vi har lært mye av et så omfattende prosjekt som Sir Jerky Leap,

og vi vet vi at vi kommer til å få bruk for dette i fremtiden.

Det ble bestemt, i samråd med oppdragsgiver, at det ikke var nødvendig med en brukerveiledning

da programmet vi har laget er intuitivt. Vi har derimot laget noe som heter «clean slate», som er et

forklarende bilde og vil fungere som en slags brukerveiledning. Denne skal være tilgjengelig for

bruker i oppstarten av Sir Jerky Leap.

Dette ”clean slate”er det første brukeren ser når han logger inn på applikasjonen.

I et slikt prosjekt stilles det store krav til oss som utviklere og forventningene har vært høye. Vi

føler at vi har levd opp til disse og er veldig fornøyde med det vi har produsert i løpet av

prosjektperioden.

32


Under utvikling av Sir Jerky Leap har det blitt tilrettelagt for vidreutvikling av applikasjonen,

gjennom å legge til tabeller i databasen som foreløpig ikke er i bruk, og mulighet for å produsere

objekter og strukturer av disse. Det er klargjort for implementasjon, og delvis utviklet funksjonalitet

utover det systemet tilbyr i dag. For en oversikt over disse funksjonene se vedlegg nr. 6.

1

Produktdokumentasjon for Sir Jerky Leap

Produktdokumentasjon for Sir Jerky Leap





2

Innholdsfortegnelse

.............................................................................................................................................................. 2 1. Forord ......................................................................................................................................... 4 2. Innledning ................................................................................................................................... 5

2.1. Gruppen ................................................................................................................................ 5

2.2. Om bedriften ........................................................................................................................ 5 2.3. Bakgrunn for oppgaven ........................................................................................................ 5 2.4. Beskrivelse av produktet ...................................................................................................... 6 2.5. Benyttede Teknologier, språk, og rammeverk...................................................................... 7

3. Datastrukturer ............................................................................................................................. 8

3.1. Database ............................................................................................................................... 8 3.1.1. ER-diagram .................................................................................................................. 8 3.1.2. Tabeller ......................................................................................................................... 9

3.1.2.1. Tabellen «tasks» ....................................................................................................... 9

3.1.2.2. Tabellen «contents» ............................................................................................... 10 3.1.2.3. Tabellen «resources» .............................................................................................. 10 3.1.2.4. Tabellen «users» .................................................................................................... 11

3.1.2.5. Tabellen «task_user».............................................................................................. 11 3.1.2.6. Tabellen «task_content» ........................................................................................ 12 3.1.2.7. Tabellen «task_resource» ....................................................................................... 12

3.2. Persistenslag med Memcached .......................................................................................... 13

3.2.1. Memcached ................................................................................................................ 13 3.2.2. Persisterte objekter ..................................................................................................... 13

3.2.2.1. Oppgavetreet «Tasks» ............................................................................................ 14 3.2.2.2. «User» .................................................................................................................... 15 3.2.2.3. «nav_tab» og «active_tab» .................................................................................... 16

3.2.2.4. Lagring av status på oppgaver i en fane ................................................................ 17 4. Systemets oppbygging .............................................................................................................. 18

4.1. Hovedkomponenter ............................................................................................................ 18 4.1.1. Visning ........................................................................................................................ 18

4.1.2. Navigasjon. ................................................................................................................. 19 4.1.3. Oppdatering ................................................................................................................ 19 4.1.4. Tilstand ....................................................................................................................... 19

4.2. Klasse- og filstrukturer....................................................................................................... 20

4.2.1. SJLController ............................................................................................................. 20 4.2.2. TaskController ............................................................................................................ 21 4.2.3. SJLProcessor .............................................................................................................. 21 4.2.4. Modell-laget ............................................................................................................... 21 4.2.5. Templates .................................................................................................................... 22

4.2.6. Tags ............................................................................................................................. 22 4.2.6.1. TaskList .................................................................................................................. 22

4.2.6.1.1. Virkemåte ..................................................................................................... 22

4.2.6.1.2. Opprettelse ................................................................................................... 23 4.2.6.1.3. Utvidelser ..................................................................................................... 24

4.2.6.2. TOCList ................................................................................................................. 25 4.2.6.3. Tabs ........................................................................................................................ 25

5. Design ....................................................................................................................................... 26 5.1. Grafikk og fargebruk .......................................................................................................... 26

5.1.1. Farger .......................................................................................................................... 26

5.1.2. Ikoner .......................................................................................................................... 26

3

6. Adgangs- og brukerkontroll...................................................................................................... 26 7. Utvidelsesmuligheter ................................................................................................................ 27

7.1. Tilrettelegging .................................................................................................................... 27 7.2. Database ............................................................................................................................. 27

4

1. Forord

Dette dokumentet er produktdokumentasjonen til Sir Jerky Leap, vårt hovedprosjekt våren 2008.

Hovedprosjekteter et samarbeid mellom Høgskolen i Oslo, og vår oppdragsgiver, Aptoma AS.

Produktdokumentasjonen beskriver det ferdige produktets funksjonalitet, virkemåte og oppbygging.

Sammen med prosessrapporten skal den gi et helhetlig inntrykk av arbeidet som er utført og det

produktresultatet som er oppnådd.

Dokumentets første del omtaler oppdragsgiver og hensikten med programmet, samt hva

programmet utfører helt prinsipielt. Dokumentet tar videre for seg sentrale datastrukturer, systemets

oppbygging, samt detaljerte beskrivelser av programmets moduler.

5

2. Innledning

Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Vi begynner med å

presentere hvem som har utført prosjektet, etterfulgt av en mer detaljert beskrivelse av bedriften og

bakgrunnen for oppgaven.

2.1. Gruppen

Gruppen bak produktet Sir Jerky Leap består av Tor Anders Gustavsen, Fredrik Hoem Grelland,

Jasmine En-Ning Garry og Line Sørensen. Gruppemedlemmene har flere ganger jobbet sammen på

prosjekter, og har derfor et godt og innøvd samarbeid. Vi valgte å arbeide sammen også på dette

prosjektet nettopp på grunn av godt samarbeid, at vi utfyller hverandre, har samme ambisjonsnivå

og ønsket samme type oppgave.

Gruppens første utfordring var å finne et passende prosjekt. Vi satt oss ned i fellesskap og gikk

igjennom de prosjektforslagene som forelå på hjemmesiden til dataavdelingen ved Høgskolen i

Oslo. Utviklingsfirmaet Aptoma AS hadde kontaktet skolen og lagt frem to hovedprosjektoppgaver.

Vi fant prosjektoppgaven Sir Jerky Leap interessant, ikke minst på grunn av utfordringene knyttet

til denne oppgaven.

2.2. Om bedriften


bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-tv, visuell

produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus.

Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har VG-TV og Listefeber. I tillegg

har bedriften utviket et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VG-

netts «Rampelys» og den franske nyhetsnettsiden «www.20minutes.fr». Bedriften samarbeider også

med Scanpix/NTB.

2.3. Bakgrunn for oppgaven

Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver, føre

timer og registrere ferier. Å jobbe på tvers av mange ulike programmer, er tidkrevende og lite

effektivt. Oppdragsgiver hadde ønske om å gjøre arbeidet smartere, og vi ble bedt om å utvikle et

oppgavestyringsverktøy med vekt på effektivitet.

6

2.4. Beskrivelse av produktet

Produktets hensikt er å forenkle prosjekt- og oppgavestyring. Sir Jerky Leap skal være limet

mellom flere oppgavestyringsverktøy som allerede eksisterer. Vi har hentet ideer fra disse og

implementert nyttige funksjoner for å kunne gjøre prosjekt- og oppgavestyringen så enkel og

intuitiv som mulig.

Brukerne av systemet kan enkelt opprette, endre og slette prosjekter, underprosjekter og oppgaver.

Oppgaver kan tilegnes innhold i form av tekst eller bilder. Alle oppgaver med innhold har sin egen

TOC eller innholdsliste. Denne gir en oversikt over alt innhold tilknyttet oppgaven. TOC i

ekspandert form gir en formattert visning av oppgavens innhold, og er ment å fungere som

dokumentasjon til den enkelte oppgave.

7

2.5. Benyttede Teknologier, språk, og rammeverk.

Programvare / Teknologi Beskrivelse

Apache HTTP Server 2.2.8 Webserver

PHP 5.2.5 Programmeringsspråk (server-side) PHP: Hypertext Preprocessor

MySQL 5.0.45 DBMS (database management system)

Memcached 1.2.5 System for caching av databasekall på webserver

AFW Aptoma Frame Work, Aptomas eget rammeverk

Prototype 1.6 Rammeverk som gir objektdreven tilnærming til JavaScript

Scriptaculous 1.8.1 JavaScript-rammeverk basert på Prototype.

Zend Studio 6.0 BETA Integrert utviklingsmiljø for PHP, basert på Eclipse.

DBDesigner 4.0 Databasemodelleringsverktøy for MySQL

Navicat 8 for MySQL Databaseadministreringsverktøy for Windows

Mozilla Firefox 2.0.0.x Webleser

Firebug 1.x Utviklingsverktøy for Mozilla Firefox

Tortoise SVN 1.4.x Versjonskontroll

HTML HyperText Markup Language

CSS Cascading Style Sheets

8

3. Datastrukturer

Dette kapittelet omtaler oppbyggingingen og logikken bak Sir Jerk Leaps to datastrukturer,

database, og persistenslager basert på Memcached.

3.1. Database

Vi har benyttet nyeste tilgjengelige versjon av MySQL, versjon 5.0.45, for å drifte vår applikasjon.

3.1.1. ER-diagram

Diagrammet under viser relasjonene mellom tabellene i databasen.

9

3.1.2. Tabeller

Det er fire hovedtabeller i systemet, to entitiseringstabeller for å implementere mange til

mangefunksjonalitet, samt en tabell som kobler bruker til oppgaver. Tabellene er navngitt etter

spesifikasjoner gitt av rammeverket. Entitiserings-tabellene er navngitt etter følgende mønster: x_y

betyr at x skal inneholde y.

3.1.2.1. Tabellen «tasks»

«Tasks»-tabellen inneholder oppføringer for alle oppgaver i applikasjonen. For å emulere et sortert

hierarkisk oppgavetre benytter vi feltene pid, Indent og Sort.

Feltet «pid» inneholder peker til forelder i treet. Som toppoppgave (prosjekt) er dette feltet satt til

«0». Ved sletting av en oppgave settes forelderfeltet til negativ av tidligere forelder-id. Eks. «pid =

2» blir til «pid = -2». Dette gjør vi for å beholde informasjon om tidligere forelder til en slettet

oppgave. Dette gjør at om brukeren ombestemmer seg vil det være mulig å reversere prosessen.

Feltet «Indent» markerer på hvilket nivå, hierarkisk, oppgaven ligger på i treet. Indent 0 er

toppoppgave, barn av en oppgave med «Indent = 0» får «Indent = 1.» Dette feltet er i

utgangspunktet ikke nødvendig for å lage et hierarki, men letter lasten på serveren ved produksjon

av trestrukturen som opprettes i persistenslaget, omtalt i kapittel 4.2.2.1.

Feltet «Sort» definerer i hvilken rekkefølge oppgavene skal vises.

10

3.1.2.2. Tabellen «contents»

Tabellen «contents» inneholder oppgaveinnhold. Denne tabellen har i likhet med «tasks»-tabellen et

sorteringsfelt «Sort». Dette feltet markerer i hvilken rekkefølge innhold skal vises i en oppgave. En

innholds-oppføring har også et felt «Type», en enum, som definerer om innholdet skal vises eller

ikke. Feltet «resource_id» er en peker til en oppføring i «resources»-tabellen, som gir innholds-

oppføringen det faktiske innholdet.

3.1.2.3. Tabellen «resources»

Tabellen «resources» inneholder oppføringer som definerer en ressurs. En ressurs er i bunn og

grunn en definisjon på et innholdobjekt, men i motsetning til et innholdsobjekt som kun eksisterer

for én oppgave, kan en ressurs benyttes i x antall innholdsobjekter, oppgaver, eller andre steder hvor

en trenger en referanse til innhold.

Enum-feltet «Type», definerer hva slags type ressurs oppføringen definerer. Kombinert med feltene

«Title», «Path», og «Text» kan vi definere et utall av ressurstyper. I applikasjonen benyttes pr i dag

11

kun «Text» og «Image» i enumfeltet, men det er også lagt opp til «URL», og «Note» som mulige

ressurstyper.

3.1.2.4. Tabellen «users»

«users»-tabellen inneholder minimalt med informasjon om brukeren, og benyttes kun til å vise et

navn istedet for en id i brukergrensesnittet. Feltet «id» skal her være en replika av id-feltet i

innloggingssystemet Sir Access. Les mer om Sir Access i kapittel 7 Adgangs- og brukerkontroll.

3.1.2.5. Tabellen «task_user»

Tabellen «task_user» benyttes til å tildele brukere rettigheter og arbeid på en oppgave. Feltene

«Admin» og «Assigned» gir oss kombinert med «user_id» i «tasks»-tabellen mulighet til å fastslå

rettighetene en bruker har til å endre, opprette og jobbe med en oppgave.

12

3.1.2.6. Tabellen «task_content»

Denne tabellen er kobling mellom tabellene «tasks» og «contents» og utgjør mange-til-mange

relasjonen mellom disse.

3.1.2.7. Tabellen «task_resource»

Denne tabellen er kobling mellom tabellene «tasks» og «resources» og utgjør mange-til-mange

relasjonen mellom disse.

13

3.2. Persistenslag med Memcached

Dette delkapittelet tar for seg hvordan Sir Jerky Leap benytter seg av et ekstra persistenslag som

supplement til MySQL-databasen omtalt i kapittel 4.1.

3.2.1. Memcached

Memcached er en applikasjon som fungerer som et persisterende lag mellom webgrensesnittet og

applikasjonen. Memcached lagrer ren tekst i minnet på serveren, og benyttes derfor først og fremst

for å lagre ren HTML på større nettmedier for å minske server-lasten på dynamisk produserte sider

med mange sidevisninger. AFW har innebygd funksjonalitet for å lagre og hente ut PHP-objekter

gjennom klassen Persistence.

3.2.2. Persisterte objekter

I dette avsnittet vil vi vise hvilke data som legges inn i persistenslaget, og hvordan applikasjonen

benytter seg av disse.

Figurene som representerer persistenslageret er hentet fra debug-verktøyet som følger med AFW.

14

3.2.2.1. Oppgavetreet «Tasks»

Første gang applikasjonen kjører på serveren vil oppgave-treet lastes inn i persistenslageret. I

utgangspunktet lastes kun de mest basale data inn for å minske lasten på serveren første gang

applikasjonen startes, og for å hindre unødig ventetid for førstegangsbrukeren. Etter hvert som

brukere etterspør innhold, brukerlister mye mer, vil dette legges inn i oppgave-treet. Oppgave-treet

legges inn i Memcached som en array med navn «Tasks» på applikasjonsnivå som er identisk for

alle tilkoblede brukere, istedet for sesjonsnivå som er unikt for brukeren. Dette sikrer at alle brukere

jobber på samme oppgave-tre, med samme identifikatorer, slik det ville være om vi jobbet direkte

mot databasen.

Figuren under viser oppgave-treet lastet inn i persistenslaget. Hvert prosjekt, eller topp-oppgave

ligger som et objekt i arrayen «Tasks», mens underoppgaver ligger under sin forelder i arrayen

«children». Alle objekter i dette treet har hver sin unike identifikator, AFWId, som gjør det mulig å

identifisere objekter i treet gjennom Ajax-kall uten å sende med en database-identifikator.

15

3.2.2.2. «User»

Når en bruker logger på systemet returnerer Sir Access et objekt med brukerinformasjon. Vi lagrer

dette objektet i persistenslaget på sesjonsnivå, slik at brukerinformasjonen er tilgjengelig for

applikasjonen så lenge brukeren er innlogget.

Figuren under viser det omtalte objektet lastet inn i persistenslaget.

16

3.2.2.3. «nav_tab» og «active_tab»

For å lagre hvilke faner en bruker til en hver tid har laget, og hvilket innhold disse fanene

representerer lages det en assosiativ array, med fanetittel som nøkkel, og spørrestreng som innhold

i persistenslageret. Denne informasjonen lagres på sesjons-nivå, og er unik for hver bruker.

Figuren under viser «nav_tab» med to faner, «Projects» og «Hovedprosjekt».

Det persisterte objektet «active_tab» inneholder en spørrestreng tilsvarende den til en hver tid åpne

fanen. Figuren under viser «active_tab»

Ved sammenligning av «nav_tab» og «active_tab» figurene kan vi her se at brukeren har åpnet

fanen som viser oppgaven «Hovedprosjekt».

17

3.2.2.4. Lagring av status på oppgaver i en fane

For å lagre hvilke oppgaver som er åpne, viser underoppgaver eller innhold, blir det opprettet et

objekt i persistenslaget som bærer AFWId'en til fanens innhold som navn. Dette objektet inneholder

en array med AFWId til de oppgaver som er åpne i fanen. Hver gang en fane leses inn på nytt, eller

den aktive fanen endres blir dette objektet erstattet med daværende status. Denne informasjonen

lagres på sesjons-nivå, og er unik for hver bruker.

Figuren under viser at to oppgaver som har AFWId'ene 8301 og 8308 skal være åpne om det åpnes

en fane med AFWId projects.

Figuren under viser at to oppgaver som har AFWId'ene 8301 og 8308 skal være åpne om det åpnes

en fane med AFWId 8301.

18

Om en ny fane åpnes på en oppgave som har åpne underoppgaver, vil systemet duplisere denne

informasjonen og den nye fanen vil åpne de samme oppgavene. Om man så velger å lukke oppgaver

i den foregående fanen vil ikke dette påvirke hvilke oppgaver som er åpne i den nyopprettede.

4. Systemets oppbygging

I dette kapittelet vil leseren få en dypere innføring i hvordan Sir Jerky Leap er bygd opp. I dette

kapittelet vil det hyppig refereres til rammverket AFW, og komponenter i dette. Sir Jerky Leap er

bygget på AFW, og følger derfor en MVC-metodikk for å skille; visning, forretningslogikk og

databehandling. For en inngående forklaring av AFW henviser vi til vedlegg nr. 8.

4.1. Hovedkomponenter

Før dette dokumentet går dypere inn i oppbygningen av applikasjonen vil vi belyse fire

komponenter som til sammen definerer applikasjonsflyten i Sir Jerky Leap.

Visning, navigasjon, oppdatering og tilstand er hovedkomponentene i brukergrensesnittet, og det er

disse vi har lagt størst vekt på i utviklingen av applikasjonen.

4.1.1. Visning

I Sir Jerky Leap er det lagt opp til, i all hovedsak, tre forskjellige visninger av informasjon;

listevisning, oppgavevisning og spesialvisning. Spesialvisninger er for eksempel «personal», eller

de foreløpig uimplementerte visningene «inbox», «search» og «recycle bin». Disse

visningsmodusene er distinkt forskjellige fra «projects», som vi betegner som en listevisning, og er

alle tilgjengelige fra menylinjen.

En listevisning inneholder oppgavelister i et hierarkisk oppgave-tre. Oppgaver med oppgavelister

kan åpnes nedover i hierarkiet, til en oppgave ikke lengre har underoppgaver. En slik «bunn-

oppgave» får en oppgavevisning. En oppgavevisning gir utvidet funksjonalitet til en oppgave, slik

som å legge til innhold, eller tildeling av oppgaven til et eller flere individer.

19

4.1.2. Navigasjon.

Det alle visningsmodusene har til felles er at det ikke skilles mellom dem når det kommer til

navigasjon i applikasjonen. Informasjonen som skal presenteres åpnes i en fane som bærer navnet

på oppgaven eller spesialvisningen. I en oppgavevisning kan alle oppgaver åpnes i egen fane direkte

fra visningen ved å trykke på ikonet som skal indikere legg til fane. Fanene kan åpnes eller

lukkes uavhengig av hverandre, og navigasjon mellom disse for å utføre oppgaver skal være

normalflyten i applikasjonen.

4.1.3. Oppdatering

Ved oppdatering av innhold i en listevisning, eksempelvis ved tillegging, sortering eller flytting av

oppgaver, vil alltid kun de berørte elementer oppdateres på siden. Ved å velge en slik strategi i

stedet for å oppdatere hele fanen minskes server-lasten, og brukeren blir også gjort oppmerksom på

hvilke deler av applikasjonen som oppdateres, gjennom en oppdateringsindikator.

Oppdateringsindikatoren er en enkel animert gif, og dukker opp på siden hver gang større mengder

med innhold oppdateres. Så snart oppdateringen er utført blir denne trinnvis borte, og innholdet

kommer til syne i løpet av 0.4sekunder.

4.1.4. Tilstand

Et av hovedformålene ved å velge en navigasjonsstrategi basert på faner var at brukeren skulle ha

frihet til å åpne forskjellige visninger med samme innhold, jobbe med flere oppgaver på samme tid,

og få inntrykk av å jobbe med en typisk vindusapplikasjon. For å oppnå dette trenger vi å vite

hvilke faner som er produsert og hvilken av disse som er aktiv. Vi må også vite hvilken tilstand,

åpen eller lukket, en oppgave har i en listevisning. Dette er løst ved at applikasjonen sender

elementenes tilstandsstatus tilbake til serveren hver gang en navigasjonsoperasjon blir utført, og

elementene blir så manipulert til å inneha denne tilstanden når disse bees vist igjen. Vi ønsker også

at brukeren skal kunne navigere mellom faner som inneholder samme oppgaveliste i forskjellige

nivåer uten at tilstanden til oppgavelisten forandres i annet en den aktive fanen. Dette er løst ved å

knytte oppgavetilstand til en fane.

20

4.2. Klasse- og filstrukturer

I dette delkapittelet vil vi belyse viktige moduler i Sir Jerky Leap.

4.2.1. SJLController

SJLController arver AFWController, og er den mest brukte komponenten i applikasjonen.

All kommunikasjon med nettleseren skjer ved kall til denne controlleren. I korte trekk fungerer

denne ved at den snapper opp alle kall fra nettleseren og ser etter en «Query string» som inneholder

do=something. Her er something navnet på en metode i kontrolleren som utfører ønsket

funksjonalitet. I motsetning til en vanlig web-side vil kontrolleren bestemme hvilket innhold som

returneres til nettleseren istedet for web-serveren som gir tilbakemelding basert på url. Kontrolleren

henter nødvendige data fra «SJLProcessor», forklart i kapittel 5.2.3, og velger ønsket

tilbakemelding til nettleseren ved å benytte «templates», som forklart i kapittel 5.2.5.

21

4.2.2. TaskController

TaskController er i essensen lik SJLController, da begge utvider AFWController, men kalles aldri

direkte fra nettleseren slik som SJLControlleren. TaskController er en statisk klasse som inneholder

alle metoder for å produsere oppgaver og oppgavelister.

4.2.3. SJLProcessor

SJLProcessor arver AFWProcessor og har tilgang til verktøy som letter databehandlingen mot

databasen. SJLProcessor foretar all datauthenting og datamanipulasjon i applikasjonen. Alle

forespørsler om uthenting eller manipulasjon av data fra SJL- og TaskController behandles i sin

helhet av SJLProcessor.

Processoren eksponerer ikke databasen direkte for «controllerene», men benytter klasser definert i

modell-laget for å representere en dataoppføring.

I applikasjonen har vi valgt å benytte Memcached, som gjør av vi kan persistere objekter mellom

hvert kall til applikasjonen, og «SJLprocessor» jobber mot dette laget parallelt med databasen. Mer

om Memcached og hvordan dette benyttes kan leses om i 4.2.1.

4.2.4. Modell-laget

Modell-laget inneholder klasser som benyttes av SJLProcessor for datarepresentasjon.

For at AFW skal kunne skal kunne opprette dataobjekter må det eksistere en PHP-fil med

klassedefinisjon i «model-katalogen» til applikasjonen.

PHP har støtte for refleksive klasser og AFW utnytter dette ved å kunne opprette objekter som

speiler databasen. Vi tilrettelegger for dette ved å legge filer som bærer samme navn som

databasetabellene i modell-katalogen, og AFW oppretter objekter med alle tilhørende atributter ved

behov. Det eneste kravet til innhold i en slik fil, er en klassedefinisjon. Objekter opprettet av AFW

vil, i tillegg til alle tabell-attributter, også inneholde en unik AFWId som gjør at man kan

manipulere og finne tilbake til objektet ved hjelp av AFW's innebygde metoder.

Av klassene definert i modell-katalogen benyttes foreløpig de følgene; Task, Content, Resource og

User. Da systemet primært baserer seg på oppgavelister, har vi valgt å la klassen «Task» inneholde

metoder som kan hente ut underoppgaver, innhold, brukerobjekter m.m. og legge disse inn i «task»-

objektene.

22

4.2.5. Templates

Templates, eller maler, er et samlebegrep for HTML-filer med innskutt PHP-kode som mottar data,

og basert på malen produserer HTML -kode. Templates benyttes av alle moduler som produserer

brukergrensesnitt i applikajsonen. I all hovedsak er dette Tags, og «SJLControlleren.»

4.2.6. Tags

En Tag er en klasse med tilhørende templates som har som formål å produsere et bestemt GUI-

element på websiden. I Sir Jerky Leap benytter vi tre tagger som grunnstener for visning av

innhold.

4.2.6.1. TaskList

TaskList benyttes for å produsere oppgavelister i en listevisning ref. Kap. 5.1.1. Denne taggen er en

vidreutvikling av AFW-taggen AccordionEdit, som er nevnt i kapittel 4.2.3.3. i

prosessdokumentasjonen.Tasklist-taggen er bygd opp av et knippe komponenter; klassen «Tasklist»,

templatene «tasklist.tpl», «tasklist_header.tpl», «tasklist_content.tpl» og «tasklist_js.tpl»,

javascriptkoden «tag.js», samt en statisk metode i klassen «SJLtag».

4.2.6.1.1. Virkemåte

Ved å bruke TaskList kan vi produsere interaktive sorterbare oppgavelister i en nettleser ved hjelp

av HTML, CSS, og Javascript. Listene er strukturert ved å benytte HTML-taggene <dl>, <dt> og

<dd>. <dl> definerer en liste, <dt> definerer tittel-elementet i en oppgave og <dd> definerer

innholds-elementet i en oppgave.

Eksempelvis vil en liste med to oppgaver ha en slik HTML-struktur (konseptuelt fremstilt):

<dl>

<dt> tittel-element </dt>

<dd> innholds-element </dd>

<dt> tittel-element2 </dt>

<dd> innholds-element2 </dd>

</dl>

23

Disse listene kan nestes slik at en oppgave kan inneholde underoppgaver. Dette gjøres ved å

opprette en liste inne i innholdselementet til oppgaven.

Eksempelvis vil en liste med to oppgaver, hvor oppgave nr to har tre underoppgaver ha en slik

HTML-struktur:

<dl>

<dt> tittel-element </dt>

<dd> innholds-element </dd>

<dt> tittel-element2 </dt>

<dd>

<dl>

<dt> tittel-underelement </dt>

<dd> innholds-underelement </dd>

<dt> tittel-underelement2 </dt>

<dd> innholds-underelement2 </dd>

<dt> tittel-underelement3 </dt>

<dd> innholds-underelement3 </dd>

</dl>

</dd>

</dl>

Interaktiviteten til listene realiseres ved bruk av Javascript som oppretter DOM-objekter av hver

enkelt liste når disse lastes inn i nettleseren. Det opprettes en hendelseslytter på hvert av tittel-

elementene, og denne reagerer hver gang en bruker klikker på et element. Deretter manipuleres

elementene i DOM for å oppnå ønsket visning i nettleseren, eller kjøre Ajax-kall til bakenden.

4.2.6.1.2. Opprettelse

Å opprette en oppgaveliste gjøres i korte ordedrag ved å opprette en instans av klassen TaskList,

tilegne denne et sett verdier for å sikre at denne vil være unik i nettleseren og bestemme hvilke CSS-

klasser som skal benyttes. Deretter legges elementer inn i listen ved å kalle på metoden

addElements. Denne metoden mottar to parametre, det første er en array med informasjon

nødvendig for å produsere tittelelementet, det andre er en array med innhold og eventuelle CSS-

klasser nødvendig for å produsere innholdselementet. Listen med tittel- og innholdselementer kan

24

nå benyttes i en template ved å kalle på metoden «taskList» i den statiske klassen «SJLTag» og

sende med det ferdigproduserte TaskList-objektet som parameter. HTML-kode blir så produsert på

bakgrunn av de forskjellige template-filene og den mottatte informasjonen.

4.2.6.1.3. Utvidelser

«TaskList» følger samme oppbygging som AFW-Taggen AccordionEdit, og store deler av logikken

for å generere selve trekkspill-listene er like i disse. Utvidelsene er først og fremst fremtredende i

templatene og javascriptkoden.

Det er gjort store endringer i hvilken informasjon som sendes med til addElement metoden ved

opprettelse av et listeelement. Det sendes blandt annet med en oppgaves AFWId, brukerrettigheter,

tillstandsinformasjon, og informasjon som viser om en oppgave inneholder underoppgaver i tillegg

til den informasjonen som allerede er definert gjennom AccordionEdit. Denne informasjonen blir

benyttet i sterkt utvidede templatefiler.

For å identifisere et listeelement som en oppgave i bakenden har et hvert tittelelement fått en «rel-

attribut» tilsvarende AFWId'en til oppgaven den genereres på bakgrunn av. «class-attributten» i

tittelelementene har fått flere oppføringer for blant annet å identifisere oppgaver som bunn-

oppgaver.

Tittelelementene er utvidet til å inneholde ikoner og andre GUI-elementer som utfører oppgaver

utover åpning og lukking av en oppgave, noe det ikke var tatt høyde for i AccordionEdit.

Innholdselementene er utvidet til å inneholde en administrasjonslinje som gir brukeren mulighet til

å utføre funksjoner slik som å legge til, slette, eller endre oppgaver. Denne administrasjonslinjen

blir produsert på bakgrunn av brukerens rettigheter i forhold til en oppgave, og vises kun om slike

rettigheter foreligger.

Javascriptkoden er utvidet for å kunne fange opp brukerinteraksjon og behandle elementer som ikke

var tilgjengelige i AccordionEdit. Mesteparten av de nye funksjonene har ikke direkte tilknytning til

en liste eller et listeelement, og er derfor skilt ut i egne metoder i filen «SJL.js»

25

4.2.6.2. TOCList

TOCList benyttes for å vise en innholdsliste i en «bunntask». TOCList har mye av den samme

funksjonaliteten som TaskList, men benytter andre templates og mottar andre parametre ved

opprettelse enn en taskList.

4.2.6.3. Tabs

Taggen Tabs er en utvidelse av AFWtagen med samme navn, men er kraftig modifisert for å

benyttes som et dynamisk navigasjonsverktøy, i motsetning til sin navnebror hvis hovedformål er å

produsere en statisk horisontal menylinje.

26

5. Design

Store deler av oppgaven gikk ut på å lage et system som var annerledes enn tilsvarende systemer, og

også mer brukervennlig. Hvordan vi kom frem til det endelige designet av applikasjonen kan det

leses mer om i prosessdokumentasjonen i kapittel 4.2.2.

5.1. Grafikk og fargebruk

5.1.1. Farger

Det å velge ut farger til en applikasjon kan være en krevende affære, og da ingen på gruppen har

designbakgrunn hadde vi heller ingen forkunskaper som hjalp oss med å velge ut farger, og

fargekombinasjoner. Vi benyttet derfor primært to webapplikasjoner for å velge ut farger, online

colorpicker 2.1, og Kuler fra Adobe.

Fargevalget falt på et fargetema som strekker seg fra lyse blågrønne toner til sjøgrønt i kombinasjon

med lyse gråtoner som heller mot gult i fargespekteret.Vi benyttet oss også av subtile gradienter for

å lette den visuelle overgangen mellom tettliggende elementer.

5.1.2. Ikoner

Vi benyttet oss av ikonsettet Silk, som ligger fritt tilgjengelig under Creative Commons Attribution

2.5 License. Dette ikonsettet er lite påtrengende.

6. Adgangs- og brukerkontroll

I Sir Jerky Leap har vi valgt å benytte oss av en ferdigutviklet modul fra Aptoma AS, Sir Access,

som adgangskontroll. Vi valgte å benytte Sir Access da denne allerede benyttes i andre systemer

levert av Aptoma AS. Brukerkontroll fungerer ved at et bruker objekt produsert av Sir Access legges

inn i en session-variabel, som sjekkes hver gang brukeren gjør et kall til applikasjonen. Om ikke

dette objektet er til stede, eller har vært inaktivt for lenge, blir brukeren sendt til Sir Access for

innlogging og returnert til Sir Jerky Leap ved fullført innlogging.

27

7. Utvidelsesmuligheter

7.1. Tilrettelegging

Under utvikling av Sir Jerky Leap er det tilrettelagt for vidreutvikling av applikasjonen, gjennom å

legge til tabeller i databasen som foreløpig ikke er i bruk, og mulighet for å produsere objekter og

strukturer av disse. Det er klargjort for implementasjon, og delvis utviklet funksjonalitet utover det

systemet tilbyr i dag. For en oversikt over disse funksjonene se vedlegg nr. 6.

7.2. Database

Databasen vår er klarlagt for flere funksjoner som ikke er implementert i applikasjonen ennå.

Utvidelsene det er lagt til rette for er: Linking mellom oppgaver, notater, tilegning av en

oppdragsgiver til en oppgave, timeføring på oppgaver og deling av ressurser. Figurene viser

hvordan dette er tenkt implementert på databasenivå.

1 Kravspesifikasjon for Sir Jerky Leap

Kravspesifikasjon for Sir Jerky Leap

Versjon1.0






Innholdsfortegnelse

Innholdsfortegnelse ................................................................................................................................ 2

1. Presentasjon .................................................................................................................................... 3

2. Forord .............................................................................................................................................. 4

3. Innledning ........................................................................................................................................ 5

3.1. Om bedriften ........................................................................................................................... 5

3.2. Bakgrunn for prosjektet .......................................................................................................... 5

3.3. Mål og rammebetingelser ....................................................................................................... 5

3.3.1. Mål ................................................................................................................................... 5

3.3.2. Begrensninger .................................................................................................................. 7

3.3.3. Rammebetingelser .......................................................................................................... 7

4. Systembeskrivelse ........................................................................................................................... 8

4.1. Funksjonskrav .......................................................................................................................... 8

4.1.1. Funksjonelle krav for administratorbruker ..................................................................... 8

4.1.2. Funksjonelle krav for tilegnet bruker .............................................................................. 9

4.1.3. Funksjonelle krav for bruker............................................................................................ 9

5. Teknisk beskrivelse ........................................................................................................................ 10

5.1. Oppgave................................................................................................................................. 10

5.1.1. Teknisk beskrivelse av oppgave ..................................................................................... 10

5.2. Table of contents (heretter kalt TOC) ................................................................................... 11

5.3. Innholdsobjekt ....................................................................................................................... 11

5.4. Ressurs ................................................................................................................................... 11

6. Rammekrav i systemet .................................................................................................................. 12

7. Design ............................................................................................................................................ 13

7.1. Krav til design ........................................................................................................................ 13

7.1.1. Top bar og Tab pane ...................................................................................................... 13

7.1.2. List View ......................................................................................................................... 13

7.1.3. List Item ......................................................................................................................... 14

7.1.4. Task ................................................................................................................................ 14

8. Krav til dokumentasjon ................................................................................................................. 15

9. Use case ......................................................................................................................................... 16

9.1. Bruker .................................................................................................................................... 16

9.1.1. Use case: Administrator ................................................................................................ 16

9.1.2. Use case: Tilegnet bruker .............................................................................................. 17

9.1.3. Use case: Bruker ............................................................................................................ 17

9.2. Sir Jerky Leap ......................................................................................................................... 18


1. Presentasjon

Tittel: «Sir Jerky Leap»

Oppgave: Utvikle en webbasert applikasjon som befinner seg i skjæringspunktet

mellom en enkel todo-liste og et sofistikert oppgavestyringsverktøy.

Prosjektperiode: 07. januar – 12. juni 2008

Gruppemedlemmer: Line Sørensen (s135590)




Veileder: Eva Hadler Vihovde

Oppdragsgiver: Aptoma AS

http://www.aptoma.no

Kontaktperson: Geir Berset

Tlf: 917 75 704

E-post: [email protected]


2. Forord

Denne kravspesifikasjonen beskriver hvordan Sir Jerky Leap skal fungere, hvilke funksjonelle

krav som er satt, og hvilke rammebetingelser som finnes. Aptoma har hatt ideen om dette

systemet liggende lenge, og formet en løs kravspesifikasjon ut av det. Vår kravspesifikasjon

er basert på denne, men videreutviklet av gruppen til det vi mener er den beste løsningen.

Kravspesifikasjonen vil fungere som et styringsdokument under utvikling, og eventuelt

videreutvikling av systemet. Teksten inneholder en teknisk beskrivelse med

detaljspesifiseringer av systemets objekter, der vi graver dypere i materien.


3. Innledning

3.1. Om bedriften


bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-tv,

visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus.

Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har VG-TV og Listefeber. I

tillegg har bedriften utviket et verktøy for oppsett av forsider, Dr. Front., som blir brukt på

blant annet VG-netts «Rampelys» og den franske nyhetsnettsiden «www.20minutes.fr».

Bedriften samarbeider også med Scanpix/NTB.

3.2. Bakgrunn for prosjektet

Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver,

føre timer og registrere ferier. Å jobbe på tvers av mange ulike programmer, er tidkrevende og

lite effektivt. Oppdragsgiver hadde ønske om å gjøre arbeidet smartere, og vi ble bedt om å

utvikle et oppgavestyringsverktøy med vekt på effektivitet.

3.3. Mål og rammebetingelser

3.3.1. Mål

Målet med oppgaven er å lage et solid og innovativt, webbasert grensesnitt for

oppgavestyring. Systemet skal forenkle jobben og planlegging og styring av prosjekter.

Hovedmålet vårt er å komme frem til den enkleste løsningen for brukeren. Med dette mener vi

at enhver mann skal få god utbytte av programmet, uten noe særlig kursing. Ikke at det av den


grunn ligger for mange begrensninger til programmet, for noen begrensinger mener

oppdragsgiver at det bør være.


3.3.2. Begrensninger

Man må være administrator på en oppgave for å utføre bestemte handlinger.

Innlogging/sikkerhet via SirAccess.

Man kan bare jobbe på en oppgave i samme nivå av gangen.

Det er ingen krav til hvor stor brukerbelastning Sir Jerky Leap skal håndtere.

3.3.3. Rammebetingelser

Systemets rammebetingelser er i hovedsak predefinert av oppdragsgiver, og er i så måte

bundet til å følge disse. Vi står imidlertid fritt når det gjelder valg av blant annet IDE og

modelleringsverktøy.

Tekniske krav:

Prosjektet skal gjennomføres i henhold til oppdraggivers utviklingsmodell:

Metaproject. I motsetning til mange andre prosjektstyringsmodeller, baserer

Metaproject seg på først å designe grensesnitt, for så å gå inn i en

programmeringsfase.

Applikasjonen skal være webbasert, og grensesnittet skal baseres på W3C-standarder.

Applikasjonen skal programmeres med objektorientering i PHP.

Applikasjonen skal fungere i nettlesern Mozilla Firefox.

Applikasjonen skal utvikles basert på oppdragivers eget rammeverk for MVC og AFW.

Brukerhåndtering skal realiseres ved å benytte SirAccess.


4. Systembeskrivelse

Systemet har som mål å effektivisere oppgavestyring i små og mellomstore firmaer med

prosjektbasert arbeidsflyt. Gjennom integrasjon mot turnussystemet «Atika» skal systemet

også kunne benyttes som et verktøy for å organisere og tildele oppgaver i større

organisasjoner basert på kvalifikasjoner og behovsprøvd prioritering.

4.1. Funksjonskrav

4.1.1. Funksjonelle krav for administratorbruker

Opprette oppgaver.

Gjøre brukere til administrator på en oppgave uansett nivå.

Brukeren blir da automatisk administrator på tilhørende underoppgaver.

Opprette underoppgaver.

Tilegne en «tom» oppgave til en annen bruker.

Endre oppgaver.

Sortere oppgaver.

Slette oppgaver.

Forandre tittel på oppgave.

Legge til «detaljer» til oppgave.


4.1.2. Funksjonelle krav for tilegnet bruker

Opprette TOC:

o Legge til tekst.

o Endre tekst.

o Slette tekst.

o Legge til bilde.

o Slette bilde.

o Åpne og lukke alle tekst- og bildeelementer i TOC.

o Sortere tekst- og bileelementer.

Begrensing: oppgaven må være «tom», altså på nederste nivå.

4.1.3. Funksjonelle krav for bruker

Åpne og lukke oppgave.

Se innhold i oppgave.

Åpne oppgave i tab.


5. Teknisk beskrivelse

5.1. Oppgave

Systemet skal innholde oppgaver som sorteres hierarkisk i en trestruktur. Det skal kunne

eksistere flere slike oppgavetrær i systemet. Med hierarkisk trestruktur menes at en oppgave

skal kunne ha en forelder og barn. En oppgave skal dermed kunne ha en overordnet oppgave,

samt underoppgaver.

I systemet skal man kunne opprette, flytte, fjerne og kopiere oppgaver på tvers av

oppgavetrær og hierarkisk orden.

5.1.1. Teknisk beskrivelse av oppgave

En oppgave skal ha en tittel

En oppgave skal kunne eksistere uten forelder.

En oppgave skal kunne inneholde andre oppgaver.

En oppgave skal kunne inneholde en eller flere «Innholdsobjekter»

En oppgave skal kunne ha en eller flere «ressurser».

En oppgave skal kunne ha en oppdragsgiver.

En oppgave skal kunne inneholde en eller flere «Tilegningsobjekter»


5.2. Table of contents (heretter kalt TOC)

Oppgaver på alle nivåer i systemet har sin egen TOC, bestående av en eller flere

innholdsobjekter (henvisning til innholdsvisning). I vanlig visningsmodus er TOC, som

navnet antyder, en innholdsfortegnelse som lister opp informasjon knyttet til oppgaven. TOC

kan imidlertid ekspanderes, og dermed gi en fullstendig, ferdig formatert dokumentasjon av

den enkelte oppgave.

5.3. Innholdsobjekt

Objekter av denne typen eksisterer kun i TOC, og er i praksis enten en tekst eller en referanse

til en ressurs (henvisning til ressurs). Et innholdsobjekt er sorterbart, har en tittel, et tidspunkt

som angir når det er opprettet/endret, og et flagg som indikerer typen innholdsobjekt det er

snakk om. Man skal kunne velge om et innholdsobjekt skal være synlig ved presentasjon av

TOC i andre visningsmodi, som for eksempel utskriftsformat.

5.4. Ressurs

En ressurs er en henvisning til rådata slik som tekst, bilder, URL-er, eller vedlegg som er

tilgjengelig i systemet. En ressurs kan være privat for brukeren som har lagt den inn, eller

global slik at alle kan benytte eller endre ressursen.


6. Rammekrav i systemet

Systemet skal være utvidbart og modulært. Utvidbarheten realiseres ved å lage all

funksjonalitet som en generisk plugg-inn modul.

Systemet skal kunne eksistere som en modul i et annet prosjekt slik som Atika.

Hoveddelen skal programmeres i PHP (objektorientert)

Skal bruke AFW, Prototype og Scriptaculous – rammeverk

Enkelt webgrensesnitt


7. Design

7.1. Krav til design

Vi har valgt å se på systemet i forskjellige nivåer når det gjelder funksjonelle krav.

De forskjellige nivåene er hierarkisk organisert og gir et bilde av hvilke funksjoner som skal

være tilgjengelig for brukeren i et grafisk brukergrensesnitt.

De forskjellige nivåene er:

7.1.1. Top bar og Tab pane

Dette er systemvid funksjonalitet og skal være tilgjengelig for brukeren til en hver tid. «Top

bar» gir tilgang til søkefunksjonalitet, personlig visning av tildelte oppgaver, en innboks som

fungerer som en idesamler, en søppelkasse som inneholder forkastede oppgaver og ideer og

visning av alle prosjekter. All aktivitet i «Top bar» viser seg som en fane i «Tab pane», som

gir brukeren mulighet til å bytte mellom og lukke de visninger skapt av «Top bar» og «List

view».

7.1.2. List View

Dette er en horisontal hierarkisk listestruktur som ligner på «Microsoft Windows utforsker».

Ett hvert «List item» (oppgave) kan ha innhold og andre «List items» (underoppgaver). En

slik struktur kan vises i en fane i «Tab pane» og kan representere en liste over; alle prosjekter,

ett prosjekt, eller kun en del av et prosjekt. Funksjonaliteten til «List View» er begrenset til de

oppgaver brukeren bør ha mulighet til å utføre på en liste, slik som å åpne et «List item»,

lukke et «List item», flytte et «List item», og åpne et «List item» i en ny fane. Åpne i ny fane

åpner for muligheten for å jobbe på mindre deler av ett eller flere prosjekter, og bytte mellom

disse effektivt ved hjelp av «Tab pane»


7.1.3. List Item

Et «List item» er et element i en «List view», men er i bunn og grunn en oppgave som kan ha

innhold, en overordnet oppgave og en eller flere underoppgaver. Funksjonaliteten på et «List

item» kan utføres når det er åpent i en «List view» og er begrenset til å endre tittel, markere

det for senere manipulasjon, og legge til underoppgaver.

7.1.4. Task

Dette funksjonalitetsnivået er tilgjengelig når et «List item» er åpent, og gir mulighet til å vise

og manipulere en oppgaves innhold og egenskaper.


8. Krav til dokumentasjon

Dokumentasjon av prosjektet og arbeidsprosesser skal mer eller mindre følge skolens

dokumentasjonsstandard.

Variabelnavn og kommentering av kode skal være på engelsk.


9. Use case

9.1. Bruker

Viser de forskjellige brukernivåene med rettigheter.

Antagelser/begrensninger for use case:

Bruker må være logget på.

9.1.1. Use case: Administrator

Arver brukerrettighetene til AssignedTo.

Opprette underoppgaver

Administrator-rettigheter AssignedTo-rettigheter

Tilegne brukere

<<include>> <<include>>

Opprette oppgaver

<<include>>

Endre tittel

Sortere

Administrator

Slette

AssignedTo


9.1.2. Use case: Tilegnet bruker

Arver brukerrettighetene til Bruker.

9.1.3. Use case: Bruker

Bruker

Legge til tekst

Slette tekst

Legge til bilde

Slette bilde

AssignedTo

Opprette TOC

<<include>>

<<include>>

<<include>>

<<include>>

Se og lese innhold

Bruker

Åpne oppgave i tab


9.2. Sir Jerky Leap

Viser de forskjellige systemnivåene. Se krav til design punkt 7.1.

1

Testrapport for Sir Jerky Leap






2


1. Forord

Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse med

prosjektet. Testprosessen var en del av implementasjonsprosessen og en kontinuerlig del av

utviklingen.

Denne rapporten bør leses sammen med tilhørende produktdokumentasjon og eventuelt

prosessdokumentasjonen og kravspesifikasjonen.

3


Innholdsfortegnelse

1. Forord ........................................................................................................................................... 2

2. Innledning .................................................................................................................................... 4

3. Tester ............................................................................................................................................ 4

3.1. Funksjonstesting .................................................................................................................... 4

3.1.1. Om testmetoden ............................................................................................................. 4

3.1.2. Tester og resultater ......................................................................................................... 5

3.1.2.1. Sikkerhet ................................................................................................................. 5

3.1.2.2. Verktøylinjen ........................................................................................................... 5

3.1.2.3. Project-view ............................................................................................................ 6

3.1.2.4. Personal-view ......................................................................................................... 7

3.1.2.5. Recycle bin ............................................................................................................. 7

3.1.2.6. Tab pane .................................................................................................................. 7

3.1.3. Forhold oppdaget under testing...................................................................................... 8

3.1.4. Oppsummering ............................................................................................................... 8

3.2. Brukertesting ......................................................................................................................... 9

3.2.1. Utførelse ......................................................................................................................... 9

3.2.1.1. Scenario .................................................................................................................. 9

3.2.1.2. Test-personer ......................................................................................................... 10

3.2.1.3. Resultater .............................................................................................................. 10

3.2.2. Konklusjon ................................................................................................................... 10

4


2. Innledning

Brukergrensesnittet har blitt testet nøye, da brukervennlighet var en essensiell del av applikasjonen.

Det var viktig for oppdragsgiver at systemet var ryddig og lettfattelig, så vel som at det hadde et

solid og innovativt brukergrensesnitt. Vi har hatt papirprototypetest, html-prototypetest og

sluttprodukttest. Dette hjalp oss å produsere et intuitivt oppgavestyringsverktøy.

En hovedtest av funksjonalitet og stabilitet ble gjort etter at applikasjonen var ferdig.

Alle feil som ble funnet under testing er forbedret.

Det er viktig å dokumentere testingen man har gjort for å lette arbeidet for de som skal

videreutvikle og vedlikeholde applikasjonen, slik at det er lettere å finne eventuelle feil.

I denne rapporten har vi hatt fokus på brukertesting og funksjonstesting av sluttproduktet.

3. Tester

Dette kapitlet inneholder informasjon om testene som har blitt gjennomført. Hvert underkapittel

omhandler forskjellige typer tester, og hver kategori har flere gjennomførte tester.

3.1. Funksjonstesting Det ble testet om funksjonaliteten til Sir Jerky Leap fungerte slik som forventet. Det ble testet

underveis i programmeringen, men det er også viktig å teste når applikasjonen fremstår som ferdig.

Dette fordi enkelte funksjoner kan ha blitt påvirket av andre endringer i koden.

Formålet med testingen har vært å finne svakheter i systemet, og rette på disse, slik at vi kan levere

så og si feilfritt system til oppdragsgiver.

3.1.1. Om testmetoden

Før vi testet funksjonaliteten til Sir Jerky Leap, lagde vi en tabell med oversikt over hva

programmet kunne gjøre. Til dette var kravspesifikasjonen og Use-case-beskrivelsene til stor hjelp,

samt dokumenter som har blitt skrevet underveis om funksjonaliteten til Sir Jerky Leap.

5


3.1.2. Tester og resultater

3.1.2.1. Sikkerhet

Funksjon/Handling Testet Status

Logge inn At det fungerte opp mot

SirAccess

OK

Logge inn med feil passord At det blir foretatt en sjekk opp

mot databasen.

OK (får opp feilmelding om at

enten brukernavn eller passord

er feil)

3.1.2.2. Verktøylinjen


Se «Personal» Vise en oversikt over brukers

prosjekter og oppgaver

OK

Se «Projects» Vise en oversikt over eksisterende

prosjekter og oppgaver.

OK

Se «Inbox» Vise hvilke elementer som ligger i

innboksen

Skal videreutvikles

Se «Recycle bin» At man får se hvilke prosjekter og

oppgaver som har blitt slettet.

Skal videreutvikles

Søke Mulighet for å søke etter prosjekt

og oppgave.

Skal videreutvikles

6


3.1.2.3. Project-view


Oppgave:

Add project Legge til prosjekt OK

Edit Title Endre tittelen OK

Add Task Opprette oppgave OK

Add Admin Sette bruker som administrator

Sort tasks Sortere oppgaver OK

Save sort tasks Lagre sorterte oppgaver OK

Delete tasks Slette oppgave OK

Move to tab At prosjektet/oppgaven åpner seg i tab OK

TOC (nederste nivå):

Delete TOC Slette oppgave m/TOC OK

Add text Opprette tekstfil i TOC OK

Save text Lagre tekstfil OK

Edit text Editere tekstfil OK

Delete text Slette tekstfil OK

Open/Close TOC Åpne/lukke alle tekst- og bildeelementer OK

Add image Legge til et bilde i TOC OK

Sort text Endre rekkefølgen på tekstfiler OK

Save sort text Lagre sorterte tekstfiler OK

Assign user Tildele en oppgave til bruker OK

7


3.1.2.4. Personal-view


Tasks with admistrative

privileges

Vise en liste over hvilke

oppgaver man er admin på

OK

Tasks I am assigned to Vise hvilke oppgaver bruker har

blitt tildelt

OK

Move to tab At oppgaven du velger åpner

seg i tab

OK

Finished/remove Slette prosjekt Ikke implementert

3.1.2.5. Recycle bin


Se slettet oppgaver At man får se en liste over

hvilke oppgaver som er slettet

Ikke implementert

Gjenopprette At oppgaven legger seg tilbake

der den ble opprettet

Ikke implementert

3.1.2.6. Tab pane


Oppgave åpnet i tab:

Utseendet følger med OK

Fremdeles en fungerende

administratorlinjen

OK

Sortere på alle nivåer OK

8


3.1.3. Forhold oppdaget under testing

Til tross for at vi testet kontinuerlig under utviklingsperioden, dukket det opp feil i funksjonaliteten.

Oversikten over disse viser under:

Funksjon/Handling Feil som oppstod Feilmelding

Sortere en tom

oppgave

Det gikk å flytte den tomme

oppgaven en gang, deretter låste

listen seg.

Opprette TOC Funksjonen «Add task» var

tilgjengelig etter å ha opprettet en

TOC,og trykket brukeren på «Add

task» ble TOC'en slettet

«Edit title» på

oppgave i tab

Navnet på oppgaven ble ikke endret

i «Project-view» eller i tab-tittelen

«Add task» på

oppgave i tab

Det ble ikke opprettet en oppgave. $(element) has no properties [Break

on this error] return

$(element).recursivelyCollect('nextS

ibling');

«Open in tab» Utseendet ble ikke det samme i ny

tab som i visningen brukeren var når

«move to tab» ble trykket

Feilene har blitt utbedret og testene ble utført på nytt for å forsikre at det var vellykket.

3.1.4. Oppsummering

Testing har vært utført kontinuerlig under utviklingen i tillegg til rett før innlevering av prosjektet.

Vi har utbedret alle feil som testene har avdekket. Til tross for dette er det viktig å merke seg at det

ikke nødvendigvis betyr at applikasjonen er feilfri, men vi har ikke funnet noen feil og mangler som

ikke er forbedret.

9


3.2. Brukertesting

Det ble testet om applikasjonen oppførte seg slik som brukerene forventet. Vi begynte med en

papirprototype som senere ble utviklet til en HTML-prototype, men det er som nevnt tidligere

sluttproduktet vi har testet i denne rapporten.

Vi har testet om applikasjonen var lettfattelig, slik at brukerne forstod hvordan man skulle gå frem

for å utføre spesifiserte handlinger. Vi har dokumentert hva brukerene brukte unormalt lang tid på,

hva brukeren ikke forstod og hva de forstod med en gang.

3.2.1. Utførelse

Vi har testet for alle funksjonene som er mulig å utføre. Det viktigste er hvordan systemet oppleves

som helhet, og at funksjonene er lettfattelige.

3.2.1.1. Scenario

En bruker ønsker å utvide et prosjekt ved å legge til underoppgaver og deretter jobbe på prosjektet.

Vi har testet for disse funksjonene, da de var ferdig implementert når vi utførte testen;

Logg inn som fredrik med passord jalla

Åpne project-visningen.

Opprett tre underoppgaver, med tittelene «en», «to» og «tre» under prosjektet

«arbeidsplanlegging».

Opprett en underoppgave til oppgave «en».

Legg til tekst i oppgave «to» og kall den «tester».

Legg til en setning i tekstelementet «tester» og lagre det.

Legg til nok en tekst i oppgave «to», og kall den «tester igjen».

Åpne og lukke begge tekstene samtidig.

Legg til bildet «note» som ligger på skrivebordet, gi bildet tittelen «bilde».

Assign Line til oppgave «to».

Sorter oppgave «en», «to» og «tre», slik at «en» er i midten.

Endre tittelen til oppgave «tre» til «fire».

Slett oppgave «fire».

Åpne oppgave «en» i tab.

10


Gå tilbake til prosjekt-visningen.

Åpne personal-visningen.

Åpne en oppgave du er administrator på i tab.

3.2.1.2. Test-personer

Testperson 1:

Alder: 23 år

Bakgrunnskunnskap: Ansatt hos Aptoma AS, og mulig sluttbruker. Bruker de produktene firmaet

bruker i dag. Har ikke sett prototyper, hørt ideene eller sett sluttproduktet til Sir Jerky Leap før

testen.

Testperson 2:

Alder: 34 år

Bakgrunnskunnskap: Ansatt hos Aptoma AS, og mulig sluttbruker. Bruker de produktene firmaet

bruker i dag. Har ikke sett prototyper, hørt ideene eller sett sluttproduktet til Sir Jerky Leap før

testen.

3.2.1.3. Resultater Testpersonene ble forklart testens formål og ble bedt om å utføre et og et punkt i scenarioet. Begge

kom seg i gjennom det greit, uten store problemer. De synes begge at det var et bra og behagelig

brukergrensesnitt, men noen småkommentarer hadde de. Kritikken som ble gitt var:

Fonten er for liten

Ikonene er lite intuitive og det må være tilhørende tekst til alle ikonene

Det er et rødt kryss for både slett og lukk.

Flytte admin-nøkkel foran tittel, istedetfor at den står mellom to knapper.

Accept-box, håndsom musepeker over hele.

Vi var helt enig i det som ble sagt og prøvde så godt vi kunne å forbedre dette.

3.2.2. Konklusjon

Det var på forhånd blitt testet med papirprototyper og HTML-prototypen da vi satt i gang med å

implementere designet av brukergrensesnittet. Disse testene har hjulpet oss å utvikle et godt system

med gode funksjonaliteter som er selvforklarende og dermed enkle å forstå for brukerne. Under

11


sluttprodukttestingen ble vi gjort oppmerksomme på ting testpersonene mente vi burde forbedre.

Etter disse endringene ser vi på Sir Jerky Leap som et ennå bedre produkt.

sfesjl )pfn (sfmmboe t +btnjof &o /joh (bssz t -jof...

Documents