HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1 F r edr i khoem Gr el l a nd, s L i nes ør ens en, s J a s mi nee nni ngga r r y, s T orander sgus t a v s en, s

2 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Sir Jerky Leap DATO 23. mai 2008 ANTALL SIDER 146 PROSJEKTDELTAKERE Fredrik Hoem Grelland, s Tor Anders Gustavsen, s Line Sørensen, s Jasmine En-Ning Garry, s 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

3 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: 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.

4 Sammendrag Hovedprosjektet Sir Jerky Leap ble utført ved Høgskolen i Oslo, avdeling for ingeniørutdanning, våren 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.

5 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.

6 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

7 Prosessdokumentasjon for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) Prosessdokumentasjon for Sir Jerky Leap 1

8 Innholdsfortegnelse 1. Forord Innledning Gruppen Om bedriften Bakgrunn for oppgaven Mål Sir Jerky Leap! Fasene i prosjekt Planlegging Innledende arbeid Første tanker Fremdriftsplan og arbeidsplan Metode Kravspesifikasjon Utviklingsprosessen Kompetansetilegning Design Bakgrunn for designet Utvikling Utfordringer Optimalisering av GUI Personlig-visning Innhold i TOC (Table Of Content) Tab-funksjon Ikoner «Mus-over-funksjonen» Mappestruktur Implementasjon Databasestruktur Prototype og Scriptacolous Sorterbare trekkspill-lister Bakgrunn Forarbeide Utvikling Utfordringer Interaktivitet Brukerdifferansiering Kondisjonell lasting av innhold Oppdatering av listen Løsninger Interaktivitet Brukerdifferansiering Kondisjonell lasting av innhold Oppdatering av listen Testing Samarbeid Samarbeid med oppdragsgiver og sluttbrukerne Veiledning fra Høgskolen i Oslo Prosessdokumentasjon for Sir Jerky Leap 2

9 6. Konklusjon 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. Prosessdokumentasjon for Sir Jerky Leap 3

10 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 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 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 VGnetts «Rampelys» og den franske nyhetsnettsiden « Bedriften samarbeider også med Scanpix/NTB. Prosessdokumentasjon for Sir Jerky Leap 4

11 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 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. Prosessdokumentasjon for Sir Jerky Leap 5

12 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. Prosessdokumentasjon for Sir Jerky Leap 6

13 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 Prosessdokumentasjon for Sir Jerky Leap 7

14 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 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 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. Prosessdokumentasjon for Sir Jerky Leap 8

15 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 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. Prosessdokumentasjon for Sir Jerky Leap 9

16 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 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 10 Prosessdokumentasjon for Sir Jerky Leap

17 sluttdokumentasjonen 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 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 Apache HTTP Server PHP MySQL Memcached Prototype 1.6 Scriptaculous Zend Studio 6.0 BETA DBDesigner 4.0 Navicat 8 for MySQL Mozilla Firefox x Firebug 1.x Beskrivelse Webserver Programmeringsspråk (server-side) DBMS (database management system) System for caching av databasekall på webserver Rammeverk som gir objektdreven tilnærming til JavaScript JavaScript-rammeverk basert på Prototype. Integrert utviklingsmiljø for PHP, basert på Eclipse. Databasemodelleringsverktøy for MySQL Databaseadministreringsverktøy for Windows Webleser Utviklingsverktøy for Mozilla Firefox Prosessdokumentasjon for Sir Jerky Leap 11

18 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. Prosessdokumentasjon for Sir Jerky Leap 12

19 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 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 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: Prosessdokumentasjon for Sir Jerky Leap 13

20 AccordionEditList Prosessdokumentasjon for Sir Jerky Leap 14

21 «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: Prosessdokumentasjon for Sir Jerky Leap 15

22 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; 16 Prosessdokumentasjon for Sir Jerky Leap

23 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 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. Prosessdokumentasjon for Sir Jerky Leap 17

24 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: Prosessdokumentasjon for Sir Jerky Leap 18

25 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: Prosessdokumentasjon for Sir Jerky Leap 19

26 Vi videreutviklet denne løsningen, og under vises slik den ser ut i programmet: 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 Prosessdokumentasjon for Sir Jerky Leap 20

27 oppdateringsindikator 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 Prosessdokumentasjon for Sir Jerky Leap 21

28 «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 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. Prosessdokumentasjon for Sir Jerky Leap 22

29 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 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 23 Prosessdokumentasjon for Sir Jerky Leap

30 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 databasetabellnavnet. 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. Prosessdokumentasjon for Sir Jerky Leap 24

31 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. Prosessdokumentasjon for Sir Jerky Leap 25

32 Uten Prototype og Scriptaculous ville vi ikke vært i stand til å levere en dynamisk webapplikasjon på den tiden vi hadde til rådighet Sorterbare trekkspill-lister Sir Jerky Leap benytter trekkspill-lister, heretter kalt en Accordion, for å representere oppgavelister 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 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,[ 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 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 Prosessdokumentasjon for Sir Jerky Leap 26

33 grunnfunksjonaliteten var nødvendig for å møte de kravene vi hadde til listen Utfordringer 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 Brukerdifferansiering Brukere med forskjellig tilgangsnivå skulle kun ha tilgang til, og vise de funksjoner som er tilgjengelige for brukeren 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 Oppdatering av listen Det skulle være mulig å oppdatere deler av listen med nytt eller endret innhold. Prosessdokumentasjon for Sir Jerky Leap 27

34 Løsninger 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 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 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 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 flimmereffekt 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 28 Prosessdokumentasjon for Sir Jerky Leap

35 innlastingsindikator 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. Prosessdokumentasjon for Sir Jerky Leap 29

36 5. Samarbeid Her beskrives samarbeidet mellom gruppen og veileder samt gruppens samarbeid med oppdragsgiver 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 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. Prosessdokumentasjon for Sir Jerky Leap 30

37 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. Prosessdokumentasjon for Sir Jerky Leap 31

38 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. Prosessdokumentasjon for Sir Jerky Leap 32

39 Produktdokumentasjon for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) Produktdokumentasjon for Sir Jerky Leap 1

40 Innholdsfortegnelse Forord Innledning Gruppen Om bedriften Bakgrunn for oppgaven Beskrivelse av produktet Benyttede Teknologier, språk, og rammeverk Datastrukturer Database ER-diagram Tabeller Tabellen «tasks» Tabellen «contents» Tabellen «resources» Tabellen «users» Tabellen «task_user» Tabellen «task_content» Tabellen «task_resource» Persistenslag med Memcached Memcached Persisterte objekter Oppgavetreet «Tasks» «User» «nav_tab» og «active_tab» Lagring av status på oppgaver i en fane Systemets oppbygging Hovedkomponenter Visning Navigasjon Oppdatering Tilstand Klasse- og filstrukturer SJLController TaskController SJLProcessor Modell-laget Templates Tags TaskList Virkemåte Opprettelse Utvidelser TOCList Tabs Design Grafikk og fargebruk Farger Ikoner

41 6. Adgangs- og brukerkontroll Utvidelsesmuligheter Tilrettelegging Database

42 1. Forord Dette dokumentet er produktdokumentasjonen til Sir Jerky Leap, vårt hovedprosjekt våren 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. 4

43 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 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 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 VGnetts «Rampelys» og den franske nyhetsnettsiden « Bedriften samarbeider også med Scanpix/NTB 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. 5

44 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. 6

45 2.5. Benyttede Teknologier, språk, og rammeverk. Programvare / Teknologi Apache HTTP Server PHP MySQL Memcached AFW Prototype 1.6 Scriptaculous Zend Studio 6.0 BETA DBDesigner 4.0 Navicat 8 for MySQL Mozilla Firefox x Firebug 1.x Tortoise SVN 1.4.x HTML CSS Beskrivelse Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk Rammeverk som gir objektdreven tilnærming til JavaScript JavaScript-rammeverk basert på Prototype. Integrert utviklingsmiljø for PHP, basert på Eclipse. Databasemodelleringsverktøy for MySQL Databaseadministreringsverktøy for Windows Webleser Utviklingsverktøy for Mozilla Firefox Versjonskontroll HyperText Markup Language Cascading Style Sheets 7

46 3. Datastrukturer Dette kapittelet omtaler oppbyggingingen og logikken bak Sir Jerk Leaps to datastrukturer, database, og persistenslager basert på Memcached Database Vi har benyttet nyeste tilgjengelige versjon av MySQL, versjon , for å drifte vår applikasjon ER-diagram Diagrammet under viser relasjonene mellom tabellene i databasen. 8

47 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 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 Feltet «Sort» definerer i hvilken rekkefølge oppgavene skal vises. 9

48 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 innholdsoppføringen det faktiske innholdet 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 10

49 kun «Text» og «Image» i enumfeltet, men det er også lagt opp til «URL», og «Note» som mulige ressurstyper 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 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. 11

50 Tabellen «task_content» Denne tabellen er kobling mellom tabellene «tasks» og «contents» og utgjør mange-til-mange relasjonen mellom disse Tabellen «task_resource» Denne tabellen er kobling mellom tabellene «tasks» og «resources» og utgjør mange-til-mange relasjonen mellom disse. 12

51 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 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 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. 13

52 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. 14

53 «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. 15

54 «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». 16

55 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

56 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 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 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 «bunnoppgave» 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. 18

57 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 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 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. 19

58 4.2. Klasse- og filstrukturer I dette delkapittelet vil vi belyse viktige moduler i Sir Jerky Leap 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