AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

Transkript

1

2

3

4 2

5 1 Forord Denne rapporten redegjør for hvordan vi har jobbet, hvilken metodikk vi har fulgt, hvilke verktøy vi har brukt og hvilke nye teknologier vi måtte sette oss inn i. Videre vil vi drøfte effekten av de valg vi gjorde underveis i prosessen. Rapporten er beregnet for sensor og veileder, men kan også leses av andre interessenter. Det vil være en fordel for leser å ha kunnskaper knyttet til programutvikling, da rapporten innholder tekniske begreper. en er delt opp i flere underkapittler: Planlegging og metode, Utviklingsprosessen og Kravspesifikasjon og dens rolle. Det er også en innledning før, og en avslutning etter, dette. Det anbefales at dokumentet leses i rekkefølgen det presenteres her. Planlegging og metode Tar for seg hvilke planleggings- og utviklingsverktøy som ble benyttet, samt prosjektets utviklingsmetodikk. Utviklingsprosessen Forklarer hvordan vi opplevde å bruke valgte arkitekturer, teknologier og språk. Kravspesifikasjonen og dens rolle Presenterer hvilken rolle kravspesifikasjonen har hatt i løpet av prosessen, hvordan den ble utformet og på hvilken måte den gjenspeiler det ferdige produktet. Produktrapporten gir en dypere teknisk beskrivelse av produktet og dets oppbygning. Vedlagt finnes en ordbok der leseren kan slå opp datatekniske og prosessrelaterte ord og uttrykk som er nevnt i denne rapporten. 3

6 2 Innhold 1 Forord Innhold Innledning Gruppen Oppdragsgiver og kunde Bekk Norsk Pointerklub (NPK) Norsk Breton Klubb (NBK) Bakgrunn for oppgaven Mål for oppgaven Beskrivelse av programmet Planlegging og metode Benyttede verktøy, teknologier og metodikk Ukjente Kjente Planleggingsverktøy og metodikk Fremdriftsplan SharePoint Services Smidig utviklingsmetodikk Pivotal Tracker Fil- og kodedeling Arbeidsforhold Kommunikasjon Dokumentasjon Dagbok Møtereferater Versjonskontroll Utviklingsprosessen Startfasen Oppsett av server Koding på norsk Utviklingsfasen

7 6.2.1 Backup-funksjonen Eksportering til Excel Forventninger i forhold til funksjonalitet og GUI Prototyping Flex og grensesnittprogrammering Frem- og tilbakeknapp MVCS Optimalisering av MySQL Overgangen til Zend Framework PHP som scriptspråk Testdrevet utvikling Import av data fra NKK Tegnsettproblematikk Bruker-, rolle- og rettighetshåndtering Årbok Sluttfasen Optimalisering for produksjon Konklusjon Kravspesifikasjonen og dens rolle Bakgrunn for kravspesifikasjonen Rammekrav Levende styringsdokument Vår erfaring med kravspesifikasjonen Kravspesifikasjonen og det endelige produktet Oppfyllelse av krav Tilbakemelding fra oppdragsgiver Konklusjon Avsluttende del Ord fra eksterne veiledere Samarbeid i gruppen Arbeidsfordeling Veiledning fra HiO Refleksjonsnotat Planlegging og oppstart

8 8.4.2 Utvikling Ferdigstilling Produktet Konklusjon

9 3 Innledning Denne innledningen inneholder bakgrunnsinformasjon for prosjektet og finnes i både prosess- og produktrapport. Her presenterer vi først gruppen, oppdragsgiver og kunde. Videre går vi mer i detalj om bakgrunnen for, og målet med, oppgaven. 3.1 Gruppen Gruppen bestod av Hans Magnus Inderberg, Egil Paulsen, Tore Lervik og Pelle Christoffer Bjerkestrand. Medlemmene kjente hverandre fra før og har jobbet sammen ved flere anledninger. Forventningene til hverandre var basert på egne erfaringer gjort over de to foregående årene og er derfor realistiske. Vi valgte å danne denne gruppen da vi hadde god kommunikasjon, et godt samarbeid og likt ambisjonsnivå. 3.2 Oppdragsgiver og kunde I denne oppgaven er det et skille mellom kunde og oppdragsgiver. Kundene er Norsk Pointerklub og Norsk Breton Klubb, mens Bekk fungerte som vår oppdragsgiver og vil vedlikeholde systemet etter levering Bekk Bekk Consulting AS er et norsk konsulentselskap som leverer rådgivnings-, teknologi- og forvaltningstjenester til store offentlige og private virksomheter. Selskapet har i dag 210 ansatte og er en del av ErgoGroup - et kraftsenter i Norden innen teknologi. Bekk stilte med to veiledere til prosjektet: Erlend Opdahl og Ole Christian Langfjæran. Ole er utvikler og er Bekk sin ekspert på Adobe Flex-teknologi. Ole hadde som sin bacheloroppgave å utforme det eksisterende systemet som nå er utdatert. Erlend er selv fuglehundeier og har kontakter i miljøet. På denne måten har de som oppdragsgiver god innsikt i kundens situasjon Norsk Pointerklub (NPK) Pointeren i Norge representerer en liten, men sunn hunderase. Det registreres rundt 300 valper i året. Rasen har få alvorlige arvelige defekter, noe som skyldes at NPK har god kontroll over rasen, og avler på sunne og friske bruksdyr. Det er svært få pointereiere som ikke driver med jakt og hundesport, og dette har ført til at de jaktlige egenskapene alltid Figur 1. AirDog-logo har hatt høyeste prioritet for oppdretterne her i landet. Figur 2. NPK-logo Klubben har i dag ca. 950 medlemmer. Veileder Erlend Opdahl er medlem i Norsk Pointerklub Norsk Breton Klubb (NBK) Breton er en liten hunderase, så vel i størrelse som i antall, i Norge. Breton er den minste av de stående fuglehundrasene. Det skal være en kvikk, livlig og våken hund med energiske, kraftige bevegelser uten å virke tung. Klubben har i dag ca. 900 medlemmer. Veileder Ole Christian Langfjæran sitt system benyttes av denne klubben. 7

10 3.3 Bakgrunn for oppgaven Veileder Ole Christian Langfjæran hadde fra før laget en løsning for å vise informasjon om hunder, raser og jaktresultater fra Norsk Kennel Klubb. Løsningen blir benyttet av Norsk Breton Klubb. Dagens løsning er ikke god nok og det ønskes bedre statistikkmuligheter. For eksempel ønskes bedre muligheter for å redigere på data som ofte er feil, og å legge inn egne data. Videre ønskes bedre kompatibilitet da dagens løsning avhenger av utdatert teknologi som ActiveX i Windows XP. 3.4 Mål for oppgaven Målet med prosjektet er å utvikle et nytt system for hundeklubber som er tilknyttet Norsk Kennel Klubb (NKK). I første omgang vil dette være NPK og NBK. Systemet som skal utvikles skal erstatte det nåværende systemet og, om mulig, tilby nye funksjoner. Samtidig er det viktig at systemet kan brukes med lite eller ingen opplæring, av medlemmer av NPK og NBK. Figur 3. NKK-logo Systemet skal: Kunne kjøres på "alle" OS (Windows 2000/XP/Vista/7, Mac OS X og Linux) Parse datafilene NKK sender ut Beskytte dataene for innsyn av uvedkommende Systemet bør: Være relativt billig å drifte, vedlikeholde og utvide Kunne fullstendig erstatte det nåværende systemet Med tanke på målene og rammene står vi ikke helt fritt til å velge akkurat hvilke tekniske løsninger vi vil. Plattformuavhengighet og kravet om billig drifting betyr at åpne gratisalternativer som LAMPsystemet (Linux, Apache, MySQL, PHP/Perl/Python) blir favorisert over lukkede løsninger som Windows Server, C#.NET og MSSQL. 8

11 4 Beskrivelse av programmet Vi vil i dette kapittelet gjøre rede for den overordnede strukturen og funksjonaliteten som tilbys i AirDog-applikasjonen slik at leseren vil få større utbytte av senere kapitler. Figur 4. Hovedside AirDog er en web-applikasjon for rapportering og statistikk strømlinjet mot data levert fra Norsk Kennel Klubb. Applikasjonen er innledningsvis tilpasset fuglehundklubbene Norsk Pointerklub og Norsk Breton Klubb, men applikasjonen er laget generisk og kan enkelt tas i bruk av andre klubber. Systemet er i drift og har i startfasen registrert over hunder jaktprøver utstillinger kull personer oppdrettere veterinærer «Vi er meget fornøyd» - Bekk Applikasjonen lar klubbmedlemmer se klubbens hunders profiler, hvor på det vises jakt- og utstillingsresultater fra alle stevner hunden har deltatt på. Videre er det mulig å lese av stamtavlen til en hund, samt liste opp hundens avkom sortert etter kull. 9

12 Figur 5. Hundprofil Figur 6. Jaktprøver «Noen [...] ønsker at den skal presenteres slik den er i dag for alle klubbene» - Bekk Figur 7. Avkom AirDog tilbyr også kraftige statistiske utregninger. Applikasjonen kan generere statistiske data over alle klubbens hunder. Statistiske data kan være gjennomsnittsresultater og premiegrad for jaktprøver i ulike klasser, én eller alle hunders viltfinnerevne, kåring av beste hund i cup og mye mer. Brukerne kan også lese nyheter fra klubbenes egne sider som blir importert til applikasjonen i sanntid. Figur 8. Rasens jaktresultater Figur 9. Cup Bak alt dette ligger også en rekke administratorfunksjoner for å oppdatere data fra NKK. Blant annet kan man som administrator tildele roller til brukerne av systemet. Rollene kan også skreddersys av administrator slik at brukerne av systemet ikke svekker sikkerheten. 10

13 Figur 10. Brukerhåndtering Figur 11. Dat-opplastning Hvis en følger pilene i Figur 12 vil en se at disse viser en menystruktur og hvordan alle visningene henger sammen. Visningene er omtalt i brukermanualen. «Studentene utviklet [seg] gradvis til å bli meget dyktige» - Bekk Figur 12. Programmets visninger Figur 13. Jaktprøveregistrering Figur 14. Backup Applikasjonens over godt strukturerte kodelinjer er åpne og gratis slik at hvem som helst kan bruke eller utvide dem. 11

14 Figur 15. Systemets struktur Denne enkle strukturen ga oss en byggestein for dette store og komplekse programmet. Strukturen kan sees som en samlet enhet, men kan også brytes ned til server og klient. Dette vil bli gjort bedre rede for i produktrapporten. «Det er med glede vi gir [gruppen] våre beste anbefalinger!» - Bekk 12

15 5 Planlegging og metode I dette kapittelet vil vi presentere hvilke verktøy, hvilke teknologier og hvilken utviklingsmetodikk vi benyttet oss av. Videre vil vi utdype hvordan vi brukte verktøyene og teknologiene knyttet til prosessen. Til slutt vil vi gå nærmere inn på fil- og kodedeling, fysiske arbeidsforhold og kommunikasjon både innad i gruppen og mellom gruppen, oppdragsgiver og veileder. Vi vil forklare grundig benyttede verktøy, teknologier og metodikk. Dette har vi gjort fordi vi mener det hadde stor innvirkning på prosessen og det ferdige produktet. 5.1 Benyttede verktøy, teknologier og metodikk Mange av verktøyene og teknologiene vi benyttet oss av var helt nye for oss. Det er derfor skrevet en introduksjonstekst til hver av dem. De fleste tekniske verktøy og teknologier tilknyttet til selve kodingen vil bli omtalt i produktrapporten, mens de mer prosessrelaterte vil bli nærmere omtalt etter denne introduksjonen Ukjente I dette delkapittelet gjør vi rede for verktøy, teknologi og metodikk som vi ikke hadde kjennskap til fra før Flex 3 Flex 3 består av MXML og ActionScript 3 (AS3). Selv om begge disse språkene var nye for oss, hadde vi sett og brukt liknende før. MXML er et XML-basert språk for å definere brukergrensesnitt, ikke ulikt HTML. AS3 er et scriptspråk basert på ECMAScript og brukes til å programmere logikken på klientsiden. Selv om det er et scriptspråk, likner AS3 på Java, C# og andre objektorienterte språk. MXML og ActionScript kompileres til en Flash-applikasjon (.swf) som kjøres på klienten. Å benytte Flex 3 var et krav fra oppdragsgivers side, da veilederne de stilte hadde bred kompetanse på dette området Flex Builder Flex Builder er utviklet av Adobe for å gjøre det lettere å lage applikasjoner basert på Flexteknologien. Programmet er basert på Eclipse og finnes også som utvidelse. Flex Builder koster penger, men er gratis for studenter. Grunnene til å benytte Flex Builder er at det, i tillegg til å være Adobes offisielle utviklingsmiljø, var det eneste miljøet vi fant med støtte for kodefullføring og - oppslag samt syntakssjekk både for AS3 og MXML Zend Framework PHP, med deler av Zend-rammeverket, brukes på serveren. Disse snakker med databasen og utveksler informasjon fra og til klientene. Modulene vi tok i bruk var: Zend_Amf Zend_Auth Zend_Db Zend_Feed Det brede utvalget av moduler til Zend-rammeverket gjorde at vi valgte dette fremfor andre 13

16 rammeverk som hadde det vi trengte, men som kanskje ville komme til kort med tanke på senere utvidelser MVCS (Model, View, Controller, Service) Denne arkitekturen er basert på det velkjente MVC, men skiller ut Service fra Controller der Service er den eneste delen av applikasjonen som kan snakke med omverdenen. I vårt tilfelle er omverdenen serverdelen som er skrevet i PHP, men det kan også være andre applikasjoner, web services osv. Vi ønsket en så modulbasert oppbygning som mulig, der deler av koden kunne byttes ut eller skrives om uten at det påvirket resten. MVCS virket derfor som et logisk valg Google Code, Subversion og Subclipse Da oppdragsgiver ønsket å bruke Google Code til oppbevaring av kildekode, satt vi oss inn i versjonskontrollsystemet Subversion som benyttes der. Subclipse sørger for integrering av Subversion i utviklingsmiljøet Eclipse PHPUnit, FlexUnit, Maven og CruiseControl PHPUnit og FlexUnit brukes til å kunne kjøre tester mot PHP- og Flex-kodens klasser. Verktøyene fungerer ved at man lager en testklasse til klassen som skal testes og, i den, angir tester den skal utføre. Funksjonene vil så returnere sann eller usann alt etter som testene ble vellykkete eller ikke. Maven bygger kildekoden og utfører tester angitt i kildekoden, mens CruiseControl automatiserer både Maven, PHPUnit og FlexUnit. Med disse verktøyene kunne vi hele tiden ha oversikt over utfallet av testene. Bruken av disse var ikke et krav, men et ønske fra oppdragsgivers side, da de mente dette ville gi oss nyttige erfaringer med teknologier som brukes i arbeidslivet Smidig utviklingsmetodikk og Pivotal Tracker Smidig utvikling har blitt nevnt i forelesninger og vi har hatt en presentasjon av det hos Bekk tidligere. Å benytte seg av denne måten å arbeide på var nytt for oss, da de andre prosjektene ved skolen har benyttet seg av fossefallmetodikk. Da mye i prosjektet var nytt for oss, ønsket vi å følge en metodikk som muliggjør raske endringer og vendinger i kode, arkitektur og rammeverk. Programmet Pivotal Tracker er laget for smidig utvikling og fungerer som en virtuell Post-it-vegg der user storyer defineres, estimeres, diskuteres og revideres. Det var et ønske fra oppdragsgivers side at vi jobbet smidig, og med Pivotal Tracker, slik de er vant til Adobe Catalyst Adobe Catalyst var under prosjektperioden, i lukket beta. Vi hørte for første gang om verktøyet tidlig i prosjektperioden da vi deltok på Flex Camp Norway. Etter dette kontaktet vi foreleser med ønske om å få tak i en betanøkkel. Dessverre tok det for lang tid før vi fikk betanøkkelen og vi endte med å bruke papir og blyant til prototyping. Adobe Catalyst er et verktøy for interaksjonsdesign som gjør det enkelt å skape brukergrensesnitt til applikasjoner og lage interaksjon uten å måtte kode. All grafikk lagd med Adobe sine grafiske verktøy kan importeres direkte til Catalyst og dermed omskapes til dynamiske elementer som knapper og forms. 14

17 Når prosjektet er ferdig, med design og dynamikk lagt til med Catalyst, kan det publiseres som Flashfil eller AIR-applikasjon. Når neste versjon av Flex Builder kommer, kan en koble programkoden direkte til designet som er laget i Adobe Catalyst. På den måten kan man skille design og layout helt fra funksjonskode samtidig som prototypen kan utvikles videre og knyttes direkte til ferdig produkt. Figur 16. Øystein Wika - Flash Catalyst demo under Flex:Camp Norway Kjente I dette delkapittelet gjør vi rede for verktøy og teknologi som vi hadde kjennskap til fra før Eclipse Utviklingsmiljøet Eclipse er åpent og gratis, og er laget for å støtte en mengde språk og funksjoner gjennom utvidelser. Dette har ført til at Eclipse har fått et betydelig fotfeste som utviklingsmiljø og er støttet av store firmaer som IBM, QNX, Red Hat, SuSE, Ericsson, HP og Intel. Vi ble introdusert for Eclipse allerede i første semester av studiet, men da som Java-utviklingsmiljø. Bruken av Eclipse var et krav, da Flex Builder er en utvidelse til dette miljøet PHP og MySQL Scriptspråket PHP har vi tatt som eget fag. MySQL har blitt brukt som database i alle kurs vi har hatt der det krevdes programmering mot databaser. I tillegg har vi benyttet oss av begge disse i egne prosjekter utenfor skolen. Vi er kjent med bruken av disse, da vi har erfaring med å bygge applikasjoner fra bunnen av. Videre har vi laget utvidelser til allerede eksisterende plattformer, som WordPress og phpbb. 15

18 Erfaring og lave driftskostnader ved PHP og MySQL, førte til at valget falt på disse. 5.2 Planleggingsverktøy og metodikk Vi har i hovedsak benyttet to planleggingsverktøy for dette prosjektet. Webportalen SharePoint Services ble brukt til planlegging og oppfølging av selve prosjektet, mens Pivotal Tracker ble brukt til planlegging og oppfølging av applikasjonens funksjoner. I starten av prosjektet laget vi først en enkel fremdriftsplan basert på innleveringsfrister. Prosjektspesifikke oppgaver ble ført opp på SharePoint-siden, mens krav for selve applikasjonen ble ført opp på Pivotal Tracker. Med Pivotal Tracker kunne både vi og veilederne legge inn de funksjonene som applikasjonen skulle ha, og vi fikk en god oversikt over hva som skulle gjøres og hvor god tid vi hadde. Oppgavene ble rangert etter prioritet slik at eventuelle problemer med å nå deadline ikke skulle kunne resultere i tap av viktig funksjonalitet Fremdriftsplan Planen formet og definerte iterasjonslengder og frister, samt ga et estimat på når vi måtte regne med å presentere prosjektet. Det viste seg å være en fordel å kunne ha en visuell oversikt på høyt nivå, for å få en tydeligere representasjon av tidsbruk og frister, da vi senere tok i bruk Pivotal Tracker og SharePoint. Figur 17. Prosjektperiodens første halvdel 16

19 Figur 18. Prosjektperiodens andre halvdel SharePoint Services SharePoint Services er en gratis webportal utviklet av Microsoft for å gjøre det enkelt for grupper å arbeide og dele dokumenter på et felles sted. Portalen kan skreddersys og gjør det mulig å legge til dokumentbibliotek, kalendere, oppgaver, lister og mange andre moduler. Modulene er kalt Web Parts og kan konfigureres til å gjøre nesten hva som helst. Dette har ført til at vi har kunnet sette opp prosjektsiden vår med ønsket funksjonalitet uten å bruke andre moduler enn de som kommer med produktet. I tillegg til alle modulene er SharePoint godt integrert med Office-pakken til Microsoft. Dette gjør at man enkelt kan redigere dokumenter på prosjektsiden som om de skulle befinne seg lokalt. Figur 19. SharePoint 17

20 5.2.3 Smidig utviklingsmetodikk Utviklingsprosessen har foregått etter smidig metodikk. Vi mener at i alle større prosjekter vil det være viktig å ha en prosjektplan og en fungerende metodikk for å holde oversikt over prosjektets status og progresjon. Det vil her bli gjort rede for valg av utviklingsmetodikk og vår erfaring Smidig utvikling Å jobbe smidig vil si å levere produktet fortløpende i delleveranser slik at deler av funksjonaliteten blir implementert og kan tas i bruk av kunden. Hensikten med smidig utvikling er å ha mulighet til å fortløpende inspisere og revurdere krav fra kunden. Utviklergruppen skal hele tiden kunne tilpasse seg kundens ønsker, som kan forandre seg, etter at deler av systemet er kommet på plass eller behovene og situasjonen endrer seg. Når man jobber smidig velger man å bryte opp problemet i mindre biter med lite planlegging istedenfor langsiktig og grundig planlegging. Det er ikke satt kun én endelig leveransedato, men også flere delleveranser frem til prosjektet anses som ferdig. Utviklingsgrupper som jobber smidig karakteriseres som små, på 5-9 personer, der gruppemedlemmene operer på tvers av fagfelt og hver har sine spesialiserte roller. Dette er typisk roller som designer, utvikler, tester og teknisk kommunikator Iterasjoner En delleveranse gjøres ved enden av en iterasjon. Iterasjonene er som små delprosjekter som tar for seg planlegging, systemkravsanalyse, design og koding for så å godkjennes av oppdragsgiver. Det som leveres er funksjonalitet som kan tas i bruk av kunden, slik at systemet hele tiden vil fungere, men få mer og mer funksjonalitet. Dette sikrer kontinuerlig tilbakemelding slik at det som leveres stemmer overens med kundens forventninger som helhet, samt at det tillater å raskt gjøre endringer i prosjektet. Vanlig lengde på en iterasjon pleier å være mellom én og fire uker. Hver iterasjon har en startfase hvor det foretas en analyse av problemet. Slutten av iterasjonen går med til retting av feil og testing. Den største produktiviteten er i midten av iterasjonen. Figur 20. Iterasjonsmodell illustrerer abstrakt hvordan en iterasjon foregår. Kunden sitter på en Product Backlog, altså en liste av ønsket funksjonalitet til programmet. Hver funksjonalitet er på forhånd estimert med vanskelighetspoeng slik at en passe stor arbeidsmengde kan velges ut under det aktuelle iterasjonsmøtet. Den valgte mengden legges i Sprint Backlog, som er funksjonaliteten utviklerne skal fokusere på i Sprint og ha ferdig til iterasjonens slutt. 18

21 Figur 20. Iterasjonsmodell Leveranser Hver iterasjon ender med et iterasjonsmøte hvor delleveransen blir presentert. Oppdragsgiver kvalitetsvurderer og bestemmer om kravene tilfredstilles. Hvis leveransen møter kravene, kan utviklerne jobbe videre på neste leveranse. Hvis ikke kravene møtes må utviklerne utbedre leveransen og få den godkjent til neste iterasjonsmøte User story User storyer fungerer som en ønskebrønn med ulik funksjonalitet som systemet gjerne skulle hatt. Listen med user storyer er i utgangspunktet overambisiøs, så det er opp til kunden og utviklernes prestasjonsevne å prioritere hva som skal implementeres. Hensikten med en user story er å gi en kort beskrivelse av en funksjonalitet i systemet sett fra brukerens perspektiv. En user story sier hvem som gjør, hva som gjøres og hvorfor det gjøres. Ved å lese dette høyt for seg selv som utvikler vil man forstå i større grad hva som skal kunne gjøres og hvorfor. Det er ikke nok for en utvikler å bare få noe til å fungere, men det skal fungere på en slik måte at det tilfredstiller den brukeren som skal benytte seg av det. Eksempel på en user story: Som en bruker skal jeg å kunne se en liste over alle hunder slik at jeg kan finne en hund User storyene fungerer som et funksjonelt krav. De blir kategorisert under brukersystem, adminsystem, rammekrav, krav til design og vedlikehold Estimering For å kunne måle fremgang og antall timer det tar å levere en løsning, må user storyene estimeres. Ved å estimere hver av disse som en oppgave, kan man legge sammen alle user storyer og beregne samlet tidsforbruk. Det finnes mange metoder å estimere oppgaver på. Blant disse er poker planning. Poker planning gjøres ved at man i felleskap går gjennom en user story, for så å kaste hvert sitt kort på bordet. 19

22 Tallverdien til kortet indikerer hvor høyt hver enkelt mener vanskelighetsgraden til storyen ligger. Den som kaster kortet med høyest tallverdi argumenterer for hva hun eller han mener gjør at storyen anses som vanskelig. Den som gir lavest gjør det samme. Deretter kaster alle på nytt helt til alle kaster kort med samme verdi og har forståelse for de komplikasjoner som kan forekomme. Figur 21. Planning poker Prioritering Har prosjektet en satt leveringsdato og tiden for utvikling er for knapp, må kunden prioritere hvilke user storyer som skal implementeres. Ofte er listen av user storyer i utgangspunktet overambisiøs (noe kunden er fullt klar over): det er da opp til kunden å vise evne til å prioritere realistisk Fordeler og ulemper med smidig utviklingsmetodikk Smidig utviklingsmetodikk står i kontrast til vannfallsmetodikk og kan fremstå som kontroversiell og uryddig. Å jobbe smidig kan fremstå som å ha mangel på struktur og legger lite til rette for nødvendig dokumentasjon. Samtidig leder smidig utvikling til en høyere møtefrekvens som kan bety større kostnader. Videre anses det som vanskelig å estimere en user story realistisk, siden utviklerne i starten av prosjektet kjenner lite eller ingenting til hele systemets omfang og krav. Smidig utviklingsmetodikk er først og fremst funksjonalitetsdrevet og baserer seg på en setning om hva man som bruker skal kunne gjøre. Ikke-funksjonelle krav er vanskelige å oversette til user storyer. Disiplinerte utviklere kan likevel utnytte potensialet i smidig utvikling ved å møte forventningene til kunden ettersom det jevnlig leveres brukbar kode. Å levere fungerende kode jevnlig gir et bedre inntrykk av fremgangen, og kunden vil umiddelbart erfare hvorvidt løsningen møter kravene. Forutsatt at utviklerne er motiverte og kan stoles på, kan de selv forme små selvorganiserte grupper som dynamisk tilpasser seg forholdene Hvorfor vi valgte smidig utviklingsmetodikk Det ble bestemt allerede på første møte med oppdragsgiver Bekk, at vi skulle følge denne metodikken. Bekk jobber mest etter smidig utviklingsmetodikk hos egne kunder, og ønsket å videreføre praksisen til vårt prosjekt. Vi så på prosjektperioden som for kort til å kunne gjennomføre prosjektet etter vannfallsmetoden. Vannfallsmetoden baserer seg på den tradisjonelle ingeniørmetodikken hvor nøye analyse og design 20

23 opptar all tid før man i det hele tatt programmerer og implementerer programmet. Det ville med andre ord gått lang tid innen vi hadde fått tilbakemelding om løsningen oppfylte forventningene til kunden. Smidig utvikling stiller store krav til samarbeid innad i en gruppe. Å benytte seg av en smidig metodikk vil bety at vi som utviklere klarer, gjennom møter sammen med oppdragsgiver, å analysere og planlegge løsninger på egenhånd innad i gruppen. Vi så på dette som en utfordring. Det ville bidra til at vi som studenter ville modnes og bli mer selvgående og kritiske til hva og hvordan vi løser problemer. Innad i gruppen hadde vi forskjellige interessefelt som gjorde rollefordelingen naturlig. Vi har erfart fra veiledere og forelesere at smidig utvikling er en metodikk som øker i popularitet Hvordan vi brukte smidig utviklingsmetodikk Basert på de kunnskaper vi tok til oss om smidig utvikling og de ønskene oppdragsgiver hadde for prosjektet, satte vi oss ned og laget en iterasjonsplan. Bekk sine veiledere kunne ha iterasjonsmøte en fast gang per uke, så det å ha rullerende møtedager tettere enn syv dager ville ikke fungert. Iterasjoner på tre uker er for lenge, og vil ikke gi mange nok iterasjoner til å få en kontinuerlig fremgang i prosjektet. Siden vår prosjektperiode var på under fire måneder har det vært naturlig å ha iterasjoner med to ukers varighet. Vi delte prosjektperioden frem til 1. mai inn i åtte iterasjoner. Første iterasjon ble satt allerede til uke 3. Mellom hver iterasjon holdt Bekk, som oppdragsgiver, iterasjonsmøte hvor vi gikk igjennom delleveranse, fikk tilbakemelding og ga status til prosjektet. Videre estimerte vi user storyer. Hos Bekk benyttes poker planning til å estimere user storyer. Vi ble introdusert for denne metoden ved første iterasjonsmøte og brukte den til å estimere de første user storyer. Under de første iterasjonsmøtene estimerte vi alle user storyene med poker planning. På denne måten fikk vi et overordnet estimat over hele prosjektet og gjorde det mulig å dele det opp i iterasjoner. For å organisere iterasjonene med alle user storyene, benyttet vi oss av planleggingsverktøyet Pivotal Tracker. Med Pivotal Tracker kunne vi opprette, estimere og kategorisere funksjonelle krav som user storyer. Pivotal Tracker la automatisk opp et utvalg user storyer basert på prioritet og estimert vanskelighetsgrad for hver iterasjon. På denne måten fikk vi opp en plan med user storyer å fullføre for hver iterasjon. Pivotal Tracker er forklart nærmere i delkapittelet Pivotal Tracker. 21

24 Vår erfaring med smidig utviklingsmetodikk Å jobbe smidig var en ny og uvant måte for oss, og det har vært en interessant omstilling fordi vi som studenter har blitt lært opp til tradisjonell vannfallsmetodikk. Vi fikk mulighet til å begynne å skrive kode veldig tidlig i prosessen, noe vi var svært spent på med tanke på de nye språkene og utviklingsverktøyene vi skulle bruke. Vi erfarer likevel at å få begynne å utvikle tidlig gir resultater og gir oss mulighet til å forutse hva det endelige produktet vil bli. Pivotal Tracker som planleggingsverktøy fungerte overraskende bra som hjelpeprogram for smidig utviklingsmetodikk. Pivotal Tracker hjalp til å organisere alle funksjonelle krav etter prioritet og estimert vanskelighetsgrad. Det har vært passe store iterasjoner med tid til forarbeid, utvikling og testing. Arbeidsmengden var naturlig da hastigheten ble målt etter hva vi leverte for hver iterasjon. Siden vi lærte mer etter hvert, klarte vi å levere mer og mer for hver iterasjon. Arbeidsmengden økte altså ikke på grunn av tidspress, men etter vår egen progresjonsevne. Våre valg av utviklingsverktøy og iterasjonsintervall ga gode rammer for prosjektstyringen. Da både utviklingsverktøyene, integreringen av de ulike komponentene og programmeringsspråket i seg selv var helt nye for oss, var planen å starte tidlig å levere enkel funksjonalitet som kunne utbedres ved senere iterasjoner. På denne måten ble læringskurven omvendt eksponentiell. Satt i kontrast med den eksponentielle kurven ser vi at progresjonen ble større ettersom kunnskapen økte. Figur 22. Forhold mellom læring og kode 22

25 Grafen nedenfor er en innspurtsgraf hentet fra Pivotal Tracker som viser prosjektets tidsrom ved x- aksen og antall oppnådde poeng ved y-aksen (godkjent fungerende kode). Figur 23. Burn-down-graf Figur 23 viser at vi ved de første iterasjonene oppnådde få poeng. Men etter hvert som vi ble mer kjent med verktøyene, teknologiene og metodikken, økte antall oppnådde poeng drastisk. Foruten påskeferien, som vises som en flat linje rundt begynnelsen av april, stuper kurven ned mot leveringsdato. Kurven viser også at kommunikasjonen mellom oppdragsgiver og oss som utviklere ble tettere. Metodikken viste seg å fungere: Da vi hadde levert kode, kunne oppdragsgiver umiddelbart evaluere og godkjenne Pivotal Tracker I dette delkapittelet vil vi gjøre rede for planleggingsverktøyet Pivotal Tracker. Verktøyet har hatt stor betydning for prosessen. Vi går derfor grundig gjennom verktøyets virkemåte, hvordan vi benyttet oss av det og drøfte erfaringer. Pivotal Tracker er et planleggingsverktøy tilpasset smidig utviklingsmetodikk. Dette hjelper prosjektgrupper å samarbeide, og det kan tilpasses de mange forandringer som skjer underveis fra kunden. En user story er en funksjon eller oppgave som skal utføres i henhold til gitte spesifikasjoner. Styrken til verktøyet ligger i det fleksible oppsettet og at endringer og nye planer kan settes til verks umiddelbart. En user story kan også tildeles en i gruppen slik at man får en god oversikt over hvem som tar for seg hvilke oppgaver. Smidig utviklingsmetodikk og bruken av user storyer blir utdypet i kapittelet Smidig utviklingsmetodikk. 23

26 Figur 24. Pivotal Tracker Hvordan Pivotal Tracker fungerer Pivotal Tracker har et web-basert brukerpanel som oppdateres umiddelbart ved endringer. Alle på prosjektgruppen kan derfor hele tiden logge seg på og holde seg oppdatert på hvilke user storyer som er aktuelle og se status på disse. I Backlog legges alle tenkelige user storyer for prosjektet. De estimeres etter vanskelighetsgrad og omfang, med poeng 1, 2, 3, 5 eller 8. En user story med 8 poeng regnes som en svært omfattende oppgave. Figur 25. User storyer For hver iterasjon velges et antall user storyer slik at summen av vanskelighetspoeng blir passende for prosjektgruppens progresjonsevne. Har gruppen sett for seg fravær under denne perioden skal kravene senkes til et realistisk nivå. Ved å gjøre dette får man et bilde av hva utviklerne i gruppen kan få til på en iterasjon basert på estimerte poeng. Pivotal Tracker justerer automatisk antall poeng per iterasjon ut fra hvor mange poeng gruppen fikk godkjent i de foregående iterasjonene. Figur 26. Aktive user storyer Ved iterasjonens slutt presenteres løsningene på user storyer og oppdragsgiver enten godkjenner dem eller etterlyser forbedringer. Da det ikke har vært tid til å presentere de nye leveransene i 24

27 møter, har gruppen kunnet trykke «finish» slik at oppdragsgiver kan vurdere leveransen fra et annet sted. Det er da mulig å legge ved kommentarer til leveransen for bedre respons. Eksempel på dette kan sees i figur nedenfor. Figur 27. Rediger user story Pivotal Tracker har også innebygget grafverktøy for å visualisere progresjonen. Under vises et eksempel av en såkalt burn-down-chart. Jo mer man kommer i gang med et prosjekt og får innvilget poeng, jo nærmere mål kommer man. Den grønne linjen foreslår normalprogresjonen som må holdes for å kunne komme i mål ved endelig leveringsdato. 25

28 Figur 28. Burn-down-graf Rollen Pivotal Tracker har spilt for oss Pivotal Tracker har vært et viktig verktøy for oss under hele prosjektets gang. Siden det ligger på internett har alle i gruppen samt veilederne hatt tilgang til oppdatert informasjon. Pivotal Tracker har gitt oss god oversikt over oppgaver som må gjøres og hvor vi ligger an for å komme i mål. Det har vært enkelt å fordele oppgaver mellom oss da vi hele tiden har kunnet sett hvem som har påtatt seg en oppgave. Vi kunne også se når en oppgave var fullført og ventet på respons. Siden planleggingsverktøyet lå tilgjengelig på internett var det mulig for oppdragsgiver å følge med på fremgangen og godkjenne levert kode umiddelbart etter at den var levert. Dette gjorde at vi ikke måtte vente til neste iterasjonsmøte for å få respons, noe som ville bremset fremgangen da ikke alle problemer ville ligge like ferskt i minnet. Pivotal Tracker var enkelt å oppdatere av alle involverte og fungerte som et levende styringsdokument. I tillegg til utviklingen benyttet vi også Pivotal Tracker til å legge opp arbeidet med sluttdokumentasjonen. Her la vi opp delkapittler som vi så for oss skulle være med, estimerte disse og fikk lagt opp en plan på hva som skulle skrives Fil- og kodedeling På et prosjekt der vi som en gruppe på fire medlemmer der alle skulle ta del i programmering og rapportskriving, var det viktig å effektivt kunne utveksle filer og kode. 26

29 Google Code Iterasjonsmønsteret vårt, samt antall personer i gruppen, førte til at vi trengte en sikker måte å holde kildekoden samlet uten at data kunne gå tapt. Valget falt på Google Code da dette var både ønsket av oppdragsgiver og sikkert. Da prosjektet er åpen kildekode er Google Code gratis i bruk. Selv om kildekoden ligger fritt tilgjengelig, må det gis tilgang av en administrator for å kunne oppdatere den. Google Code bruker Subversion som holder rede på hvem som sjekker inn hvilken kode, samt konflikter som må løses hvis to eller flere programmerere ønsker å sjekke inn endringer på samme fil. Med utvidelsen Subclipse til Eclipse fungerer inn- og utsjekking sømløst inne i selve utviklingsmiljøet Maven og CruiseControl I tillegg har vi også benyttet oss av en Maven-byggeserver som henter oppdateringer automatisk fra Google Code og kjører tester med PHPUnit angitt i kildekoden. Denne serveren sier så fra om koden klarer å kjøre eller hvilke tester som eventuelt får feil. Figur 29. Kildekodeflyt viser integreringen av utviklingsverktøyet Eclipse hvor det lastes opp kildekode til Google Code hvor koden CruiseControl så kjører tester på Maven med PHPUnit og FlexUnit. 5.3 Arbeidsforhold Figur 29. Kildekodeflyt Før prosjektet startet hadde vi et ønske om fast arbeidsplass og -tid. Dette viste seg å være vanskelig å gjennomføre, da hverken skolen eller oppdragsgiver hadde rom til disposisjon. Løsningen ble å møte opp klokken åtte på skolen hver dag fra mandag til torsdag for alltid å få plass på det samme grupperommet. Denne måten å gjøre det på ga tydelige rammer med tanke på arbeidsplass og -tid, slik vi i utgangspunktet ønsket. Geografisk nærhet til skolens veileder og veileders fellesmøter var også et pluss, da det ikke gikk med unødvendig tid til reise. Selve programmeringen foregikk på flere forskjellige måter: par-, solo- og handoff-programmering. Fordi vi alle satt på samme sted til samme tid, ble dialogene rundt problemene som oppsto mer effektive enn om vi hadde blitt nødt til å ty til e-post eller lynmeldinger. Videre hadde vi også mulighet til å sette oss ved hverandres maskiner for effektiv handoff-programmering. Oppstarts- og iterasjonsmøtene ble holdt i Bekk sine lokaler på Vippetangen i Oslo. Gåavstand til Høgskolen i Oslo var absolutt en fordel, da vi kunne jobbe med prosjektet nesten en hel dag selv om det var møte den aktuelle dagen. På iterasjonsmøtene tok vi opp hvilke user storyer som skulle tas med i neste iterasjon og rangerte disse etter prioritet. Den overordnede arkitekturen for programmet ble diskutert på disse møtene, mens valg relatert til struktur i hver enkelt funksjon ble tatt av gruppen underveis i utviklingen. 5.4 Kommunikasjon Innad i gruppen har kommunikasjonen hovedsakelig gått muntlig da vi har sittet og jobbet sammen på prosjektet. Ved sykefravær og andre komplikasjoner som hindret gruppemedlemmers nærvær, har lynmeldinger og tekstmeldinger blitt brukt for å holde kontakten. 27

30 Dagboken på prosjekthjemmesiden har også blitt brukt som referat på arbeid som har blitt utført og som en oversikt over hva vi har gjort. Dette førte til et tett og oppdatert samarbeid innad i gruppen, selv når noen var borte på grunn av sykdom. Kommunikasjon mellom gruppen og oppdragsgiver har gått via flere kanaler. Kommentar- og varslingsfunksjonene på user storyer i Pivotal Tracker sikret raske tilbakemeldinger fra oppdragsgiver kort tid etter at endringer ble gjort. Videre brukte vi også lynmeldinger til diskusjoner og spørsmål som var viktige å få avklart mens vi jobbet, der det ikke var hensiktsmessig å vente til neste iterasjonsmøte. Ulempen ved lynmeldinger er at de kan være vanskelig å dokumentere. Informasjon som var av slik natur at vi mest sannsynlig ville trenge å ha tilgang til det, for å lese og eventuelt diskutere det på nytt, har gått over e-post. Dette gjorde at kommentarer som «Denne ser ikke ut til å fungere ordentlig» ikke har blitt sendt som en egen e-post, men i stedet lagt til tilhørende user story. Det har vært viktig for oss å holde en god struktur på hva slags informasjon er gått via hvilke kanaler slik at viktige beslutninger har blitt dokumentert. Oppdragsgivers veiledere stod for tilbakemeldinger fra testere og videreformidlet disse på iterasjonsmøtene. Disse reglene vi satte for oss selv førte til større flyt og fleksibilitet enn om vi kun hadde fått tilbakemeldinger under iterasjonsmøtene. 5.5 Dokumentasjon Med tanke på sluttdokumentasjonen og oppfølging av progresjon har vi ført dagbok, møtereferater og brukt versjonskontroll på både dokumenter og kildekode. For å få til dette har vi brukt blant Microsoft Word og SharePoint Dagbok Dagboken er brukt som et hjelpemiddel for å huske hva, hvordan og når en bestemt oppgave ble utført. Vi har også ført vanskeligheter, problemer og løsningene vi har kommet fram til. Den har også blitt brukt som er verktøy for å sette seg inn i hva de forskjellige gruppemedlemmene har gjort. På den måten har det vært enkelt å ta opp igjen oppgaver til andre gruppemedlemmer mye raskere. I tillegg har dagboken hjulpet oss med dokumentasjonen Møtereferater Referatene har for oss fungert som en påminnelse om hvilke oppgaver vi skulle fokusere på. Samtidig som har de inneholdt en overordnet strategi for hvordan vi skulle jobbe raskere i neste iterasjon Versjonskontroll Versjonskontrollen i SharePoint fungerer slik at tidligere versjoner av dokumenter, i sin helhet, blir tatt vare på. Dette gjør det mulig å enkelt gå tilbake til tidligere versjoner av et dokument hvis de siste endringene ikke skulle passe, eller noe har blitt feilaktig fjernet. På den måten kunne vi redigere dokumenter uten å tenke over at det vi gjorde ikke nødvendigvis samsvarte med det de andre gruppemedlemmene ønsket. 28

31 6 Utviklingsprosessen Her vil gå igjennom og gjøre rede for de viktigste hendelsene for prosjektet. Vi tar for oss problemformuleringer, hva som var vanskelig og hvilken effekt våre avgjørelser hadde for prosjektet. 6.1 Startfasen Startfasen var preget av mye ny teknologi og en del omstillinger. Vi gjør her rede for de tekniske forberedelsene vi gjorde og våre erfaringer fra disse Oppsett av server I starten av prosjektet satte vi opp prosjektside med SharePoint og byggeserver med CruiseControl. SharePoint inneholder mange forskjellige verktøy, og her satt vi opp dagbok, kalender, oppgaver og dokumentbibliotek. CruiseControl fungerer som en automatisk tester for applikasjonen, og denne satt vi opp til å kjøre hver gang vi lastet opp en ny revisjon til Google Code. Begge programmene er godt forklart i Planlegging og metode SharePoint SharePoint satte vi opp i starten av desember for at den skulle fungere som prosjektside under utviklingsfasen. Vi valgte å gjøre prosjektsiden så åpen som mulig, og det var kun sensitive dokumenter som krevde innlogging. Prosjektsiden har fungert godt. Vi har hatt god oversikt og kontroll på prosjektdokumentene. I tillegg har venner og kjente likt at vi har gjort prosjektet åpent på en slik måte at de enkelt kan følge med på utviklingen. Prosjektsiden vil fortsatt være tilgjengelig på prosjekt.mindre.net i tiden etter levering. Figur 30. SharePoint 29

32 CruiseControl Vi satte opp CruiseControl for automatisk bygging og testing av applikasjonen. Systemet laster ned endringer og tester applikasjonen, før den til slutt gir en detaljert beskrivelse av resultatet. Systemet hjalp oss til enkelt å kunne se feil i kildekoden uten at vi manuelt måtte teste alle funksjonene i applikasjonen. Figur 31. CruiseControl Koding på norsk Det var et krav fra oppdragsgiver at koden skulle være så selvforklarende som mulig. Å ha norske funksjon-, variabel- og filnavn var en del av dette. Da ingen av oss hadde kodet slik tidligere, var det uvant og tok tid å venne seg til. Videre hadde vi ingen standard å følge med tanke på hvilke norske ord som skulle brukes. Koden ble vanskeligere å tyde når det var blanding av to språk. //dette er en kort forklaring på hva _verdi er private var _verdi:string; //denne funksjonen setter _verdi til nyverdi og gjør noe annet i tillegg public function set verdi(var nyverdi:string) { private _verdi = nyverdi; //kode som gjør noe annet i tillegg } På grunn av vår bruk av kjente kodestrukturer som MVCS, og annet som har akronymer som forklarer hva det er, var det noen ting vi valgte å ikke oversette til norsk. På grunn av dette heter det, i AirDogs kildekode, Controller og ikke Kontroller. Vår mening er at koding bør gjøres i det språket programmeringsspråket benytter seg av. Dette vil føre til bedre flyt i koding, feilsøking og vedlikehold. Programmet kan dermed også tas i bruk, og utvides, av de som ikke kan norsk. 30

33 6.2 Utviklingsfasen Utviklingsfasen beskriver vi her som den viktigste perioden når det gjaldt å produsere det faktiske produktet. Her vil vi ta for oss uforutsette problemer og utfordringer som dukket opp, og hvordan vi løste utfordringer som en del av oppgaven. Utviklingsfasen startet ved første møte med oppdragsgiver og vi ble satt til å levere enkel funksjonalitet allerede da. Startfasen gikk derfor parallelt med utviklingsfasen i begynnelsen av prosjektperioden Backup-funksjonen Et av kravene fra oppdragsgiver var å sikre data i applikasjonen. Det skulle være mulig å ta en backup av all hundedata. Her vil vi gjøre rede for hvordan vi løste dette. Backup-funksjonen tar for seg sikkerhetskopiering av databasen og gjenopprettelse av denne. Under planleggingen av funksjonen bestemte vi at den skulle være enkel for brukeren og at den kun skulle ta backup av hele databasen og ikke én og én tabell. Gjenopprettelse for hver enkelt tabell skulle skje ved hjelp av sjekkbokser. Grunnen til at vi valgte å la backup-funksjonen ta vare på hele databasen var for å effektivisere funksjonen for både bruker og for det bakenforliggende systemet. Dette ble mer effektivt da det ikke ble nødvendig og ta i bruk tredjepartsprogrammer for å ta backup av deler fra databasen. Figur 32. Backup 31

34 Gjenopprettelsesfunksjonen er laget slik at brukeren kan huke av én og én sjekkboks for så å klikke Gjenopprett merkede tabeller. På den måten sikrer vi at bruker ikke trykker på en knapp som gjenoppretter alle og dermed skriver over tabeller som ikke skal skrives over. Figur 33. Backup Backup-funksjonen er nødvendig da dette er en flerbrukerapplikasjon der flere har rettigheter til å endre innhold. Den sikrer at brukere kan gjøre uforutsette endringer uten kritiske følger. Backup-funksjonen tar backup til samme server som applikasjonen ligger på. Dermed har en ikke en sikkerhet for at selskapet som driver serveren ikke mister data. Vi anbefaler derfor å lagre en duplikat av sikkerhetskopien et annet sted. Vi bestemte oss for ikke å lage en automatisk backup-funksjon, da veilederne ikke så behovet for dette. Funksjonen er klargjort for en slik utvidelse slik at det lett kan implementeres i applikasjonen ved en senere anledning. Dette kan gjøres ved at strukturen i koden og backup-funksjonen kan kalles fra hvilken som helst annen applikasjon, funksjon eller server. På den måten kan man sette en timer som kjører funksjonen daglig Eksportering til Excel Mange av brukerne samler på informasjon om sine hunder fra systemet. Det har derfor vært ønskelig å kunne eksportere informasjon i applikasjonen til Excel-regneark Implementering Det ble drøftet hvordan vi skulle eksportere informasjonen om en hund til et regneark som brukeren kunne laste ned. Det første forslaget var å lage en egen funksjon på serversiden som hentet ut den samme informasjonen som ble vist på klientsiden, og presenterte den som et regneark. Valget falt til slutt på å lage en abstrakt funksjon på klientsiden. Funksjonen lagde en csv-tekst (comma-separated values) ved å iterere gjennom cellene i den valgte tabellen. Denne teksten ble så sendt til Excel.php på serversiden. Teksten blir så sendt tilbake til brukeren som et Exceldokument. Dette gjør at applikasjonen kan eksportere informasjon fra alle tabeller uten at det implementeres ekstra funksjoner på serversiden. 32

35 Konklusjon Løsningen vi kom fram til har gitt en god og generisk funksjon som kan eksportere informasjon fra alle tabeller i applikasjonen uten å måtte skrive egen kode for hver tabell. I tillegg er løsningen utformet på en slik måte at brukeren ikke blir sendt bort fra AirDog Forventninger i forhold til funksjonalitet og GUI Vi startet tidlig å se for oss hvordan AirDog skulle se ut og hvilke funksjoner applikasjonen skulle inneholde, noe som resulterte i mange diskusjoner. Det viste seg etter noen iterasjoner og møter med veilederne at vår forestilling av applikasjonens art var forskjellig fra det veilederne hadde sett for seg. Vi så for oss en applikasjon for hundeeiere, der de kunne ha oversikt over sine hunder. Det skulle ligne et nettsamfunn med Facebook-liknende funksjonalitet. Det skulle bli mulig for en hundeeier å være innlogget, se sine hunder, se på andre hunder, legge inn favoritthunder og bli venner med andre hundeeiere. Det viste seg at AirDog ikke skulle være som et nettsamfunn hvor brukerne hadde kontakt med hverandre. Hunder skulle ikke være knyttet til brukerne i form av eierskap. AirDog skulle være en oversikt over hunder der brukere kunne klikke seg inn på en hundeprofil og studere informasjon og statistikk. Noen brukere skulle ha spesielle roller og rettigheter for å kunne redigere hundedata. Administrator skulle ha en måte å gi brukere disse rettighetene. AirDog skulle kunne benyttes allerede etter første iterasjon. Dette gjorde at oppklaringen av hvordan AirDog skulle formes skjedde tidlig. Det var ingen funksjonalitet som måtte fjernes, endres eller legges til etter oppklaringen. I tillegg til dette ble vi nødt til å lage retningslinjer for hva vi skulle gjøre i hver user story. Vi brukte mye tid i starten på å diskutere hver user story i den store sammenhengen. Dette tok vi opp med veilederne og ble fort enige om at vi skulle forholde oss til det som sto i oppgaveteksten og ikke noe mer. Etter at vi fikk innarbeidet dette gikk vi fra å få til 8-10 poeng per iterasjon til 20-30, og prosjektet fikk en god fart. Vi har opplevd at smidig utviklingsmetodikk har vært en fordel for oss i flere av disse situasjonene. Det gjorde at vi raskt kom inn på riktig spor og minimalt med tid ble sløst bort Prototyping Dette kapittelet gjør rede for forstudiet vårt som gikk ut på å designe, realisere og evaluere en low fidelity-prototyp av produktets brukergrensesnitt. Rapporten tar for seg første del av utformingen av prototypen og prototypetesting, før utvikling av selve produktet. Videre gjøres det rede for verdien av de tilbakemeldingene vi fikk fra prototyping og hvilken rolle det spilte for det ferdige produktet Analyse I dag brukes internett til å kommunisere med andre samt mange andre ulike gjøremål. Nettsamfunn inntar store deler av denne aktiviteten. Her deles video, bilder av en selv og venner, kunst og musikk i ofte store brukergrupper. 33

36 Applikasjonen bærer preg av et nettsamfunn da det deles informasjon som oppdateres jevnlig. Brukergruppen har en felles interesse for fuglehund, men vil bruke systemet etter forskjellige behov. For noen vil fokuset ligge på jaktresultater, mens det for andre vil være viktig å se på utstillingsresultater Design og realisering For å få en grundig evaluering og kunne ta bedre avgjørelser ved grensesnittprogrammering, valgte vi å gjøre en prototypetest med kommende brukere av applikasjonen. Design, realisering og brukertesting ble dokumentert ved hjelp av tekst og bilder Mål for design og realisering Vi skulle designe et enkelt brukergrensesnitt. Grensesnittet var ikke ment for å bli tilpasset til funksjons- eller utviklingshemmede. Vi har hatt som mål å utvikle en brukersentrert applikasjon hvor: Brukergrensesnittet først og fremst fungerer for voksne hundeeiere Bruker skulle ikke trenge spesielle forkunnskaper bortsett fra begreper relatert til fuglehunder Ikoner skulle illustrere hver funksjon, i tillegg til tekst på hver funksjonsknapp AirDog skulle ha rik funksjonalitet. Vi fokuserte innledningsvis på: Opplisting av hunder Visning av hundeprofiler Søk etter hunder Brukersider/Preferanser Meny/Navigasjon Valpeannonser Mål for prototypetesting Vi skulle finne negative og positive sider ved low fidelity-protoypen. Dette gjorde vi ved å få tilbakemeldinger og deretter vurdere endringer i designet som så skulle resultere i forbedringer. For å få til dette sørget vi for å: Ha en low fidelity-prototype ferdig som kunne gi gode retningslinjer for utforming av produktet Ha en assistent, konferansier, maskin og observatør under testen Rekruttere testpanel 34

37 Vi ville med tanke på dette ha: To prototypetestere En prototypetest Mål for evaluering Vi hadde som mål å evaluere vår low fidelity-prototype og prosessen vi gikk igjennom, for å ende opp med et brukergrensesnitt som tilfredsstilte de krav vi satte innledningsvis Krav for mål Vi skulle: Være åpne for selvkritikk Henvise til bilder Under følger en oversikt over metodene vi har brukt for å nå våre mål Design og realisering 1. Planlegging og analyse Analyserte problemet nøye og diskuterte målet 2. Utkast Vi startet med tankemyldring, diskusjon rundt konsepter og skissering av utkast. Dette gjorde vi grovt med blyant og papir. 3. Design Vi laget aktivitetsdiagrammer og planla hvordan vi skulle forholde oss til disse punktene: Affordances Hukommelse og gjenkjenning Oppstykking Gestaltprinsipper for layout Farger Konsistenthet Kontrast Mentale modeller Metaforer Prinsipper for organisering av innhold Navigering 35

38 4. Realisering Vi tegnet skisser og lagde papirmodeller av tenkte skjermbilder. Dette gjorde vi for enklere å kunne jobbe med justeringer av størrelser, farger og layout Prototypetesting De forskjellige rollene fordelte vi slik: Assistent - Til disposisjon for testpersonen Konferansier - Har dialog med testpersonen Maskin - Fiktiv maskin som styrer skjermbilder og mottar kommandoer Observatør - Sitter på utsiden og observerer hva testpersonen gjør og reagerer Manuskript Starte opp applikasjonen Finn egne hunder Se på valpeannonser Lag valpeannonse for egen hund Evaluering Her diskuterer vi prototypen ut fra resultatene av brukertesten. Vi bruker disse resultatene til å finne sammenheng mellom punktene vi har prøvd å forholde oss til i design- og realiseringsfasen Design og realisering Vi så på positive og negative sider ved den eksisterende løsningen for Breton. Negative sider var at informasjonen ble presentert med lite variasjon og med en høy detaljkonsentrasjon. Med dette menes mange felt, flere kolonner og lite gruppering av informasjon. Positive sider var at sidene var meget godt utrustet med informasjon. Preget av å være som et Excel-ark gjorde søk og innhenting av informasjon raskere dersom man visste hvor man skulle lete. Facebook og YouTube er nettsamfunn som går under termen nettapplikasjoner. Nettapplikasjoner er en sammensetning av statiske sider og funksjonalitet fra vanlige desktop-applikasjoner. Der desktopapplikasjoner gjerne er laget som verktøy for å utføre en oppgave, vil bruksmønsteret til AirDog også likne det å surfe på nettsider Applikasjon vs. webside Vi måtte definere klare skiller mellom knapper og lenker. Noen av problemstillingene vi sto ovenfor var om alle knapper skulle være koblet til funksjonalitet, eller om de også kunne brukes til å navigere. Ved konsekvent å bruke lenker til navigering ville brukeren kunne forutse programmets oppførsel. Det ble bestemt at knapper skal utføre handlinger kun i den aktuelle visningen brukeren ser. 36

39 Bruk av ikoner Bruk av ikoner gjør knapper og funksjoner lettere gjenkjennbare. Ikoner hever brukeropplevelsen, men er sjelden selvforklarende fordi brukerne kan ha ulik bakgrunn og derfor tolke dem galt. Ikoner skulle derfor alltid suppleres med tekst. Figur 34. Eksempel på knappen Hentliste som har et listeikon Ukjente begreper Selv om målgruppen er kjent med hunder, oppdrett og helse, er kanskje ikke alle kjent med begreper som ADHD og hoftedysplasi. Vi ville derfor gi en kort definisjon av hva begreper som HQ står for ved å benytte tooltips/snakkebobler til dette Logo Det første utkastet av logoen liknet en ballonghund. Ballongkonseptet ble videreført i neste utkast med faktiske ballonger som skulle forestille en pote. Dette ble droppet til fordel for å lage noe som liknet Adobe AIR-logoen, men beholdt idéen med bruk av pote. Figur 35. Logoevolusjon 37

40 Design av skjermbilder Vi så tidlig for oss at applikasjonen skulle inneholde en rekke nøkkelskjermbilder. Protypen skulle redegjøre for et utvalg av disse Hovedsidens toppmeny Figur 36. Tidlig papirprototype av menybaren Menybaren ble designet for å være konsistent og alltid tilstede i applikasjonen. Menybaren skulle hjelpe brukeren å finne frem i systemet. Den måtte være enkel å forstå, tilgjengelig og ha en rekke tidsbesparende funksjoner. Menybaren skulle inneholde et knappefelt der nedtrekksmenyer skulle inneholde funksjoner relatert til hverandre. Knappene var ment å være responderende slik at når man holder over dem med markøren viser de umiddelbart undermenyene. Dette var for å unngå at brukeren ikke finner alle funksjoner som er tilgjengelig i systemet. Figur 37. Prototype av navigasjonen Ved å klikke på hovedknappene vises det en standardvisning for den funksjonsgruppen, men alle disse sidene skulle også ha undermenyene tilgjengelig. Dette er vanlig praksis i nettsamfunn som Facebook og YouTube og skal forsikre at brukeren kommer videre og kan lete etter undersider på siden som kommer opp. Aftenposten.no benytter seg også av dette. 38

41 Figur 38. Prototype av navigasjonen Figur over viser valgmulighetene som skulle dukke opp under menybaren. Dette er de samme valgmulighetene som vises som nedtrekksknappen dersom man holder over den og ikke umiddelbart velger å klikke på den Søk Menybaren hadde et søkefelt som skulle kunne finne hunder etter hundens navn eller eier. Søkefeltet ble plassert i menybaren for å være lett tilgjengelig Logo Helt til venstre på menybaren plasserte vi produktets logo med navn. I tillegg til profilering av produktet sto også navnet på hundeklubben man som bruker er innlogget i. Dette skaper oversikt og tilhørighet til applikasjonen Hovedside AirDogs hovedside vil, hvis ikke innlogget, kreve innloggingsopplysninger og eventuelt vise en kort beskrivelse av systemet, hjelp osv. AirDog, i innlogget status, var ment å gi et sammendrag av brukerprofilen til den som er innlogget og tilby en rekke snarveier til mest brukte funksjoner. Har brukeren hund vil hundene kunne listes opp. Det var tenkt at det skulle være et område for nyheter om nye jaktresultater og lignende, men dette var foreløpig ikke et konkret ønske fra oppdragsgiver. Dette kunne blitt lagt til som en RSS-leser fra klubbenes egne nettsider. 39

42 Hundeside Figur 39. Hundesøk Figur viser hundesiden som skulle gi brukeren mulighet til å liste opp søkeresultater, egne hunder og se valpeannonser Mine hunder Listen oppgir informasjon etter prioritering på en rad: [tittel(usorterbart)] Navn (sortér), foreldre, eier (sortér), oppdretter (sortér), kjønn, Ved å ha én hund per rad ville øynene lettere lete nedover mens man ser på navn. Mer detaljert informasjon som eier og oppdretter ble plassert til høyre på raden da det også er relevant for raskt leting. Hver rad fikk også et miniatyrbilde av hunden. Selv om rasens hunder vil se relativt like ut i lite format, er det lettere å gjenkjenne et bilde tatt i en spesiell vinkel i tillegg til hundens navn. Å bruke bilde ga også applikasjonen ansikt og bidrar til brukeropplevelsen Hundprofilside Klikket man seg inn på en på en hund i listen kom man til Figur 40. Prototype av hundeprofil hundens profilside. Profilsiden ble inndelt i to hovedseksjoner: presentasjon og samlinger av data tilknyttet hunden. 40

43 Presentasjonsdelen viste bilde og detaljert informasjon om hunden. Detaljert informasjon ble presentert i samme rekkefølge som foregående listevisning og videre de nye opplysningene som mor, far, eier, kjønn, farge osv. Eier ville være en lenke til eierprofilsiden. Nedenfor presentasjonsdelen ble det vist utdrag av lister registrert på hunden. Listene hadde de siste jakt-, utstilling- og helseresultater med gjennomsnitt, og stamtavle Valpeannonser Valpeannonser ga mulighet til å lese om valper og parringsønsker Nyeste valpeannonser Nye valpeannonser ble skissert som en vanlig hundeliste, men med en utvidet notis under raden med navn, tittel osv. Notisen ville beskrevet hva annonsen gjaldt som brukeren selv ville lagt inn. Dreier det seg om at en eier tilbyr en hann for parring, kunne man ha klikket på knappen for fiktiv stamtavle Fiktiv stamtavle Her ville man få se opplistet et fiktivt stamtre der man kunne klikke seg inn profilen for hver av hundene. Før stamtreet får man opp en liste av egne hunder man kunne sette opp i stamtreet etter passende kjønn. Stamtreet ville da vist så langt de hunder som er registrert i databasen Lage valpeannonse Ved å klikke på Lag valpeliste på hundeprofilsiden ville det blitt vist hundens sammendrag som en liste og et tekstfelt under der bruker kunne skrive hva annonsen gjelder. Funksjonaliteten rundt valpeannonser ble nedprioritert av oppdragsgiver til fordel for andre mer aktuelle funksjoner Eierprofil Eierprofilsiden skulle vise eiers hunder, personopplysninger og en lenke til innstillinger. At eierens hunder listes opp også på denne siden var for å gjøre innholdet mer tilgjengelig og bruksmønsteret mer fleksibelt. Hundene ble listet opp på samme måte som på hundesiden for konsistenthet. 41

44 Figur 41. Eierprofil Figur over viser utkast til eierprofilsiden. Eierforholdet mellom bruker og hunder ble nedprioritert i den endelige versjonen da vinklingen til applikasjonens art ble endret Overordnede prinsipper for design For å sikre kontinuitet og forutsigbarhet i brukeropplevelsen, laget vi noen gjennomgående prinsipper for designet. Valg av for eksempel farger i rett kontekst vil lede brukeren til rett forestilling om hva som foregår og hvilke muligheter som finnes Gjennomgående prinsipper i design Applikasjonens temafarger ble endret flere ganger i løpet av prosjektperioden. Men det ble tidlig bestemt signalfarger som skulle brukes konsekvent i brukersidene, uavhengig av fargetemaet. For knapper, lenker, menyer og områder relatert til funksjonalitet ble det benyttet blåtoner. Figur 42. Skille mellom meny og funksjonalitet For advarsler, tips og forklaringer ble det benyttet gult da denne står i kontrast med blå og fanger også oppmerksomheten til brukeren. 42

45 Figur 43. Snakkeboble og infotekstfelt Tilbakemelding fra prototypetest Det ble tidlig i prosjektperioden avholdt en test av en tidlig versjon av prototype på iterasjonsmøtet 9. Februar Dette var uvant for veilederne. Veilederne Ole og Erlend fungerte som testpersoner og fikk klikke seg rundt i papirprototypen. Prototypetesten ledet inn i spørsmål om navigasjon, bruksmønstre etc. Veilederne kunne tenke seg å ha undermenyer presentert som ribbons lignende office 2007, og ikke en blanding av nedtrekksmenyer og arkfaner slik vi hadde laget. Vi fikk nyttig tilbakemelding om sidene som kunne tas i betraktning til neste design Prototypens virkninger Her vil vi ta for oss likheter og gode løsninger som overlevde fram til det ferdige produktet. Vi gjør rede for gode løsninger og filtrerer hva som fungerte i prototypen og som var verdt å ha med videre. Ikke all funksjonalitet som ble tegnet ned i prototypen ble implementert i det ferdige produktet. Dette var fordi ikke all funksjonalitet hadde like høy prioritet, samt at kravspesifikasjonen har endret seg siden de første iterasjonene Søk Søkefunksjonen og dens opplisting av resultater har sin likhet fra de tidligere skissene. Figur 44. Prototype av søkeresultat Figur nedenfor viser resultatet slik det ble seende ut da løsningen var levert. Oppsett av titler, navn og bilder er likt den opprinnelige prototypen. Skjermens bredde samt plassering av informasjon på de andre datafeltene ble endret til fordel for å kunne lese raskt vertikalt i kolonnene. Videre ble det etter hvert ønskelig å vise hundens ID i søkeresultatet som man kunne markere og kopiere. 43

46 Figur 45. Søkeresultat Hundprofil Hundens profilside var ment å vise informasjon om hunden og dens jakt- og utstillingsresultater. For å strukturere dette på en oversiktlig og effektiv måtte, krevdes mye eksperimentering og testing. Profilsiden skulle vise hundens jaktprøver, avkom, stamtre, ustilling og andre statistiske data. Det som skulle vises besto gjennomgående av lister med resultater. Flere av disse listene kunne gå over ti til tjue linjer. Problematikk rundt skjermplass ble dermed sentral. Løsningen ble å legge undersider til hundeprofilen og heller vise et sammendrag som standardvisning for hund. Valg av undersider ble listet opp horisontalt over hundesiden. Figur 46. Prototype av hundprofil Den endelige visningen har ikke mange likheter bortsett fra bildeplasseringen og sammendragstabellen, men å skisse opp muligheter og eksperimentere med måter å strukturere 44

47 informasjon på, ga ideer om hvilke retninger layoutet kunne ta. Figur 47. Hundprofil Idéen om å benytte faner eller undersider stilt opp som knapper over den aktive siden, ble brukt flere steder. Denne måten å dele inn sider på ble også benyttet til navigasjonen, der Hunder-knappen i øverste blå felt fikk sine relaterte knapper i det grønne feltet nedenfor. Figur nedenfor viser hvordan menyhierarkiet henger sammen. Figur 48. Flyt i menysystemet Våre erfaringer med prototypetesting Vi jobbet med prototyping og testing i et tidlig stadium, og dro erfaringer derfra som påvirket grensesnittprogrammeringen videre i utviklingsfasen. Da vi laget prototypen og testet denne med oppdragsgiver, fikk vi umiddelbart bekreftet om vår egen forestilling av applikasjonens utseende og flyt stemte med oppdragsgivers egen forestilling. Oppdragsgiver likte første visningen av prototypen, men hadde klare meninger om hvordan de mente man skulle navigere i applikasjonen. Dette gjorde at vi tidlig kunne luke ut designfeil og unngå misforståelser angående vinklingen av applikasjonens art. På grunn av arbeidsmengde og fokus på det faglige innen programmering, kunne vi bare ta oss tid til én prototypetest. Ideelt ville prototypetesting foregått iterativt med et større testpanel. Likevel opplevdes det nyttig å lage en prototype. 45

48 Det ble enklere å forholde seg abstrakt til brukervennlighet før vi begynte å jobbe med ferdige komponenter fra Flex og bruke det vi mente kunne passe. Vi valgte å designe en best mulig løsning uavhengig av Flex sine begrensninger, og deretter prøve å implementere så likt som mulig. I tillegg til at Flex har sine begrensninger av hva som er mulig å få til i et brukergrensesnitt, hadde vi også begrensninger på hva vi kunne få til å lage på et så tidlig stadium. Muligheten til å lage en konseptuell skisse sparte oss tid. Dette var fordi vi ikke hadde noen erfaring med å utvikle i Flex i startperioden. Dette ga oss tid til å få bedre kjennskap til styling og layout med Flex før levering Konklusjon Prototypetesting på et tidlig stadium ga oss et godt innblikk i problemer og utfordringer i forhold til brukergrensesnittet. Vi fikk tidlig luket ut designfeil som kunne forvirre brukeren samtidig som at alle fikk en klarere forestilling om hva vi skulle lage Flex og grensesnittprogrammering Siden programmet vi laget er en nettapplikasjon, vil mye fokus ligge på presentasjonsdelen. Et av kriteriene stilt til prosjektet har vært brukervennlighet. I tillegg til forretningslogikk, har AirDogprosjektet tatt for seg grensesnittprogrammering da dette er en applikasjon for en større brukergruppe. Applikasjonen hadde behov for et gjennomført utseende for å sikre kontinuitet. Prosjektet hadde derfor behov for å skreddersy utseendet på de ulike komponentene i presentasjonsdelen CSS Cascading Style Sheets (CSS) er et språk som brukes til å definere utseende på filer skrevet i HTML eller XML. CSS skiller struktur og stil, slik at oppsett, farger og annen stilinformasjon beskrives uavhengig av layout. Flex opererer med CSS for å modifisere utseendet til sine GUI-komponenter. Fordelen med CSS er at man enklere definerer utseendet på komponenter eller spesifikke komponenter i en ekstern fil. Endringer i CSS-filen endrer alle komponenter relatert til dette dokumentet. Figur 49. CSS Integrere Adobe Creative Suite med grensesnittprogrammering Mulighetene for å skreddersy komponentenes utseende i CSS er likevel begrenset. Derimot er det mulig å lage temaer direkte i et bildebehandlingsprogram for så å importere dem inn i Flex Builder slik at man erstatter standardutseendet i applikasjonen. Disse temaene blir eksportert til en Flash-fil som Flex leser fra og tematiserer sine komponenter. Adobe Creative Suite 4 er en kolleksjon med programmer og tjenester som gjør det mulig å produsere arbeid for trykte medier, internett, interaktive enheter, video, lyd og mobilenheter. 46 Figur 50. Adobe Illustrator fil for design

49 Et utvalg produkter fra Creative Suite-kolleksjonen støtter design av temaer til Flex GUI-komponenter og produserer ferdige Flash- og css-filer som integreres med hovedapplikasjonen. Et av disse er Adobe Illustrator: et illustrasjonsprogram som opererer med vektorgrafikk som kan skaleres i alle størrelser uten å miste informasjon slik som bitmap-grafikk gjør. Flash benytter også vektorgrafikk, og er derfor overførbart til Flex. Temaer kan importeres enten som swf-filer, bitmap-filer eller vektorbaserte bilder. Man kan definere utseendet på alle tilstandene som for eksempel når en knapp holdes over med musen eller når en knapp er nedpresset. En knapp har i alt åtte tilstander som kan tilpasses Hvordan vi benyttet oss av dette For å styre utseendet til presentasjonslaget har vi i stor grad benyttet oss av CSS. Grunnen er at det er kodebasert og er enkelt å endre. Vi benyttet oss av Adobe Illustrator. Illustrator brukes til å redigere utseendet på enkelte komponenter for å skape et gjennomgående tema for applikasjonen Hvordan det har fungert for oss For oss har det vært nyttig å kunne separere design fra layout slik at de som jobber med layout ikke vil bli direkte påvirket eller i veien for de som jobber med design. CSS i Flex har vært mest brukt da alle på gruppen har erfaring fra CSS i kombinasjon med HTML. Det var til stor hjelp å kunne forme ulike komponenter i Adobe Illustrator, da det kan være vanskelig eller umulig å nå alle deler i en komponent med kun CSS. Å jobbe med Adobe Illustrator var en effektiv måte å produsere temaer til knapper og andre kontrollere Frem- og tilbakeknapp Under utviklingen ble det klart at brukerne ønsket en måte å navigere seg tilbake på. Da klienten er en Flash-applikasjon, oppfører den seg på mange måter mer som et skrivebordsapplikasjon enn en nettside. Det ble derfor klart at vi måtte implementere våre egne frem- og tilbakefunksjoner Implementering Vi så på forskjellige måter å implementere historiefunksjonaliteten på. En løsning var å lage applikasjonen på en slik måte at hver handling gir et nytt historiepunkt. Dette fungerer godt, men applikasjonen må da være strukturert riktig for å støtte dette. Da vår applikasjon ikke er strukturert slik, ville denne typen historiefunksjonalitet krevd omstrukturering av hele applikasjonen. Løsningen vi til slutt valgte var å lagre sesjonsobjektet (modellaget) i applikasjonen hver gang vi laget et nytt historiepunkt. Løsningen krevde at vi hadde en liste med disse objektene, og hentet riktig sesjonsobjekt ut fra det historiepunkt vi valgte. For ikke å ta opp for mye av brukeren sitt minne lagde vi funksjonen slik at ble det eldste innlegget slettet når listen ble større enn 20 innlegg Konklusjon Løsningen vi kom frem til gjorde det mulig for brukeren å bruke nettleseren sine fram- og tilbakeknapper. I tillegg fikk vi implementert funksjonaliteten uten å endre på applikasjonen sin grunnstruktur. Vi har også fått god innsikt i hvordan vi kan implementere lignende historiefunksjonalitet i vanlige applikasjoner som ikke kjøres i noen nettleser MVCS Å lage et program er i seg selv ikke vanskelig så lenge man kjenner til programmeringspråket og kan skrive fungerende kode. Det finnes utallige eksempler på Internett. Vi har allerede erfaringer fra 47

50 programmeringsfagene på skolen med å få til små fungerende programmer. Vi innså tidlig at vi måtte undersøke ulike arkitekturer og programmeringsmetodikker for å kunne realisere AirDog-prosjektet. Vi vil her gjøre rede for valget av kodestruktur. MVCS står for Model View Controller Service og er en arkitektur for strukturering av kode. Arkitekturen baserer seg på at alle generelle funksjoner skal ligge i kontrollerlaget, og skal i tillegg ikke endre direkte på objekter i presentasjonslaget. Applikasjonen vår sentrerer seg rundt det å hente verdier fra en database og vise disse verdiene til brukeren. Strukturen passet derfor godt med hvordan vi ønsket å konstruere applikasjonens virkemåte. Når brukeren trykker på en knapp i presentasjonslaget kaller den en funksjon i kontrolleren som enten utfører handlingen eller kaller servicelaget som igjen kaller på den sentrale serveren. Svaret som kommer tilbake blir så tolket og lagret i modellaget slik at presentasjonslaget kan vise en formatert visning av de hentede verdiene. I små applikasjoner kan denne metodikken virke noe tungvindt, men den gjør at større applikasjoner får en god og oversiktlig struktur, samt at lag enkelt kan byttes ut for å støtte andre eller nyere teknologier. I tillegg muliggjør arkitekturen at man enkelt kan lage funksjoner i presentasjonslaget hvor de medfølgende funksjonene i kontrollerlaget setter fiktive testdata i modellen. Et annet medlem i gruppen kan så gå inn og implementere kontrollerlaget uten å ha jobbet med eller ha særlig kjennskap til hvordan presentasjonslaget fungerer. Figur 51. MVCS-arkitektur Oppbygning Model - Modell Modellaget inneholder verdiene for applikasjonen. Verdiene ville vanligvis ligget direkte i presentasjonslaget, men for å gjøre kontrollerlaget uavhengig av presentasjonslaget blir det benyttet et generelt modellag mellom. 48

51 View - Presentasjon Presentasjonslaget er det laget som sluttbrukeren ser og kan manipulere. Dette laget kan hente og sette verdier i modellen samt be kontrollerlaget utføre funksjoner Controller - Kontroller Kontrollerlaget tar seg av alle funksjoner og er selve kjernen i applikasjonen. Kontrollerlaget kjenner ikke til presentasjonslaget og kan dermed lett settes sammen med andre presentasjonslag Service - Service Servicelaget er et underlag av kontrollerlaget. Eneste forskjellen mellom kontroller- og servicelaget er at servicelaget brukes til å snakke mot andre tjenester som for eksempel en web service Hvorfor vi brukte MVCS Vi visste allerede fra begynnelsen at vi kom til å jobbe etter smidig utviklingsmetodikk, så programmets struktur måtte være fleksibel nok til å kunne gjøre vesentlige endringer gjennom flere iterasjoner. I tillegg til å være robust for endringer, måtte programmet legges opp slik at det kunne skalere effektivt uten å miste oversikt. Alle på gruppen måtte ha en felles forståelse for programmets struktur og raskt kunne forstå andres kode. Denne forståelsen er også viktig da andre utviklere kan få i oppgave å vedlikeholde eller utvide programmet etter prosjektets slutt. Vi startet med å lese oss opp i ulike arkitekturer, og med råd fra våre veiledere falt valget på MVCS Konklusjon Strukturen har fungert godt for oss og resultert i at gruppemedlemmer har kunnet utvikle effektivt på applikasjonen samtidig uten konflikter. Arkitekturen har gjort at kildekoden beholdt sin opprinnelige struktur, selv om applikasjonen etter hvert vokste.. Det har derfor vært lettere å ha oversikt selv mot slutten av prosjektet Optimalisering av MySQL Ved importering av dat-filer fra NKK oppdaget vi at databasespørringer ble langsomme når databasen inneholdt mer enn 5000 rader. Ved importering av flere filer ble databasen så treig at det ikke var mulig selv for kun én bruker å søke i databasen. Vi vil her gjøre rede for hvordan vi evaluerte og løste flaskehalser mot databasen Evaluering Vår applikasjon består av en klient (Flex) og en server (PHP og MySQL). Dette gjorde at optimalisering av databasen måtte skje ved at kall fra klient ble evaluert når de kjørte på server. Vi brukte Zend_Db til alle databasekall i PHP-en, og kunne dermed bruke en metode kalt profilering. For å bruke profilering la vi til 'profiler' => true i Tilkobling.php slik at Zend slo det på. 49

52 I tillegg la vi denne kodesnutten under funksjonen som kjøres i PHP slik at spørringene lagres i debug.txt og kunne sjekkes for problemer. $profiler = $this->database->getprofiler(); $profile = ''; foreach($profiler -> getqueryprofiles() as $query) { $profile.= $query -> getquery(). "\r\n". 'Time: '. $query -> getelapsedsecs(). '\r\n\r\n'; } $fp = fopen("debug.txt", "w"); fwrite($fp, $profile); fclose($fp); Ved å legge med dette fikk vi filen debug.txt på serveren, som ved første kjøring spyttet ut dette. SELECT `ad_bruker`.* FROM `ad_bruker` Time: SELECT `rr`.`ad_rettighet_navn` FROM Time: SELECT `hmor`.`navn` AS `hundmornavn`, `hfar`.`navn` AS `hundfarnavn`, `h`.* FROM `NKK_hund` Time: De første spørringene tok kort tid, mens den siste spørringen, som var selve søket, tok hele 29 sekunder å utføre. Dette var uakseptabelt for en applikasjon skulle ligge på nett og brukes av flere personer samtidig Løsning Debug.txt inneholdt ikke bare hvor lang tid det tok å utføre en spørring, men også selve spørringen. Vi kunne da åpne MySQL-konsollen og utføre spørringene direkte på databasen. Ved å sette EXPLAIN foran spørringen returnerte MySQL dette. Figur 52. Hundesøk før optimalisering Spørringen hentet alle hunder samt hundens mor og far sitt navn hvis disse fantes. Problemet her var at MySQL sammenlignet alle hunder i databasen mot hmor og hfar. For hver hund som ble funnet ble rader sjekket mot hmor og hfar. Spørringen ble altså N*(rader*2) lang. 50

53 Ved å sette hundid i tabellen nkk_hund til Index slik at ingen rader i nkk_hund kunne ha lik hundid ble EXPLAIN resultatet slik. Figur 53. Hundesøk etter optimalisering Figur 53. Hundesøk etter optimaliseringviser at hmor og hfar sine rader er 1 da det kun finnes en mor og en far til hver hund. Spørringen ble da N*2 lang. Etter å ha endret dette så debug.txt nå slik ut. SELECT `ad_bruker`.* FROM `ad_bruker` WHERE (epost='gjest') Time: SELECT `rr`.`ad_rettighet_navn` FROM Time: SELECT `hmor`.`navn` AS `hundmornavn`, `hfar`.`navn` AS `hundfarnavn`, `h`.* Time: Overgangen til Zend Framework Allerede i slutten av januar begynte vi å vurdere å bruke Zend Framework på serversiden. Her gjør vi rede for hvorfor vi valgte dette. I begynnelsen benyttet vi oss kun av Zend_Amf for å ha en måte å sende objekter mellom klient og server. I februar valgte å ta i bruk flere deler av rammeverket, deriblant Zend_Auth, Zend_Acl og Zend_Db. Zend_Acl ble droppet til fordel for en egenkodet løsning, da vi ikke hadde behov for en rekke av Zend_Acl sine avanserte funksjoner, som for eksempel arv. Zend_Db bød på flere utfordringer og en større oversettelsesjobb enn først antatt. Hovedutfordringen bestod av æøå-problematikk i forhold til søk i databasen. Problemet var at Zend_Db ignorerte disse tegnene. Figur 54. Grafisk visning av æøå-problematikk Første kolonne (navn) viser en insert-setning der 'å' har kommet via Zend_Amf Andre kolonne (navnq) viser en insert-setning der 'å' er skrevet som en streng Tredje kolonne (navnqu) viser en insert-setning der 'å' har kommet via Zend_Amf og det er brukt quoteinto Fjerde kolonne (navnquo) viser en insert-setning der 'å' har kommet via Zend_Amf og det er brukt quoteidentifier 51

54 Løsningen ble å gjøre spørringen "$database->query( SET NAMES UTF8 );" før alle andre spørringer. Dette settes opp i Tilkobling.php slik som vist nedenfor. public function gettilkobling() { try { $database = Zend_Db::factory($this->config->database); $database->query('set NAMES UTF8'); } return $database; } catch ( Zend_database_Exception $e) { return "Feil med tilkobling: ". get_class($e). "\nmelding: ". $e->getmessage(); } Videre tok vi også i bruk Zend_Feed i nyhetsfunksjonen. Her hadde vi problemer med at det ikke fungerte på produksjonsserveren, men på alle andre testservere. Funksjonaliteten er derfor implementert i sin helhet både i ActionScript i klienten og i PHP med Zend_Feed på server, slik at man senere lett kan endre hvilken av de som leverer nyheter til brukergrensesnittet Konklusjon Vi mener bruken av utvalgte komponenter fra Zend Framework resulterer i ryddigere, mer strømlinjet og raskere kode som andre enklere kan sette seg inn i PHP som scriptspråk Det ble valgt å bruke PHP på serverdelen av applikasjonen etter vurdering sammen med veileder. Hovedgrunnen for valg av PHP på serverdelen var at det kunne kjøre på Linux og hadde god støtte for MySQL som vi benyttet som database. Vi vil her gjøre rede for våre erfaringer med PHP som scriptspråk. PHP er konstruert for å være fleksibelt og kjørbart på flere plattformer. Språket støttes av både Apache og IIS, og kan kjøres på blant annet Linux, Windows, FreeBSD og OS X. Dette var fordelaktig under utvikling og testing, da gruppen var delt mellom brukere av Microsoft Windows (både Vista og 7) og Mac OS X, mens produksjonsserveren benytter seg av Linux som operativsystem. Å bruke et slikt scriptspråk på flere plattformer har bydd på flere utfordringer. Det viste seg at ikke alle funksjoner oppførte seg likt på de forskjellige plattformene, og noen var til og med ikke implementert alle steder. I hovedsak gjaldt dette funksjoner som hadde med filer og mapper å gjøre, men også noen generelle funksjoner fungerte ulikt på de forskjellige plattformene. Et eksempel på dette er hvordan PHP går gjennom lister. På produksjonsserveren hadde vi først problemer med at måten vi gikk gjennom lister på, resulterte i at serveren stoppet opp. De fleste av disse problemene har vært enkle å fikse med en gang vi har blitt oppmerksom på dem, men det er uansett ikke optimalt at funksjoner kan oppføre seg annerledes på produksjonsserveren. 52

55 Et annet problem vi måtte forholde oss til var tegnsett. Tegnsett er ikke generelt for PHP, men et problem som ofte dukker opp når man utvikler plattformuavhengige applikasjoner. Tegnsettet UTF-8 ble derfor valgt å bruke på all tekst i applikasjonen slik at databasen ikke endret eller mistolket tegn som æøå. Vi valgte derfor å lage en oversetter som gjorde om all tekst fra standardtegnsettene de ulike operativsystemene benytter seg av, til UTF-8. I det hele har PHP vært tilstrekkelig for å nå vårt mål. Selv om vi fikk problemer med tegnsett og plattformavhengighet, var det fullt mulig å løse dette. Fleksibiliteten når det kom til plattformer gjorde at alle på gruppen kunne programmere på serverdelen selv om det ble benyttet ulike operativsystemer. PHP er gratis, noe som gjorde at vi møtte kravet om at systemet skulle ha minst mulig driftskostnader Testdrevet utvikling Under utviklingen laget vi testklasser for enkelt å kunne teste funksjonalitet automatisk for hver bygging. Vi fulgte testdrevne utviklingsprinsipper og gjør her rede for testmetodene vi brukte Testdrevet utviklingsmetodikk Testdrevet utvikling er en utviklingsmetodikk som passer med smidig utviklingsmetodikk. Det blir først skrevet testfunksjoner som dekker den nye funksjonaliteten som skal implementeres for en iterasjon. Testene slår naturlig nok feil ved første kjøring da ingen fungerende kode er implementert. Deretter skrives koden slik at resultatene tilfredsstiller de krav som stilles av testene. Ved å skrive testene først, har man som utvikler en klar oppfatning om hva som er ønskelig med koden. Man vil også hele tiden ha oversikt hvis senere kode eller optimalisering slår negativt ut på testresultatet. På denne måten kan man si at testene kvalitetsikrer resultatet PHPUnit Testfunksjoner kan implementeres når en funksjon i hovedsak ikke er avhengig av andre for å fungere. En databasefunksjon er for eksempel ofte vanskelig å teste, mens funksjoner som kun gjør utregninger er de mest ideelle. En testklasse inneholder testfunksjoner som tar for seg enkelte funksjoner. Testene baserer seg på å sammenligne funksjonen sine returverdier mot statiske verdier. Hver funksjon i testklassen representerer en funksjon i den aktuelle klassen. Denne funksjonen kan inneholde en eller flere tester, slik at alle testene kun blir gyldig vis funksjonen gjør det den skal. Hvis funksjonen heter hentfiler vil testfunksjonen hete testhentfiler, dette gjør at det er enkelt å se hvilken funksjon som er testet Hvordan vi utviklet med bruk av testing Mye av databehandlingen i applikasjonen skjer ved utveksling mellom presentasjon og databasen. Det har derfor vært mange såkalte ikke-testbare funksjoner. Parserklassene som brukes til importering av dat-filer har derimot mye funksjonalitet som ikke benytter seg av andre lag i applikasjonen. Det har derfor vært ideelt å skrive tester for disse klassene. 53

56 Et eksempel på en testfunksjon i PHPUnit function testvalidereierliste() { $hp = new EierParser(); } $this->asserttrue($hp->validereierliste("eier HUID RAID")); $this->assertfalse($hp->validereierliste("eier HOID RAID")); $this->assertfalse($hp->validereierliste("")); $this->assertfalse($hp->validereierliste("false")); Testklassene ble laget med PHPUnit sitt testrammeverk og kan kjøres både i CruiseControl og Eclipse Konklusjon Ved å lage tester for alle parserklassene fikk vi en god indikasjon på at alle dat-filene ble oversatt korrekt. Dette resulterte i at implementeringen av importeringen gikk bra, og vi kunne tidlig fastslå at informasjonen i databasen var konsistent med innholdet i dat-filene. Testrammeverket PHPUnit fungerer godt sammen med utregning, men fungerer dårlig med funksjoner som presenterer eller jobber mot databaselag Import av data fra NKK Applikasjonen baserer seg på å vise prosessert hundedata fra en sentral database. Disse dataene kommer opprinnelig fra NKK og blir gitt til klubbene som filer. De forskjellige filene inneholder informasjon som hunder, jaktprøver eller hvem som er eier av de forskjellige hundene. Disse dat-filene er flate tekstfiler hvor hver kolonne er separert med pipe ( ) og hver rad er plassert på hver sin linje. I tillegg kan en rad gå igjen hvis raden senere har blitt oppdatert av NKK. Dette gjør at filene både kan inneholde samme data flere ganger, og også korrupt data som ikke stemmer med strukturen. Det har derfor vært viktig å lage en god importeringsfunksjon som er fleksibel og gir forståelige tilbakemeldinger ved feil i filen Generelt Vi valgte å løse importering av data på en slik måte at det skulle være enkelt å legge til nye filstrukturer fra NKK. Først valideres den første linjen i filen mot en generell klasse. Denne returnerer hvilke type fil det er snakk om ut fra den første linjen i filen. Ut fra dette svaret velges hvilken kontroller- og oversettelsesklasse som skal benyttes. Til slutt bruker man de valgte klassene på hver linje i filen. Denne metoden gjør det mulig for brukeren å laste opp filer uten å angi hvilken type fil det er som blir lastet opp. For hver linje i filen sjekkes det om oversetterklassen returnerer riktig lengde, og at innlegget sitt klubbnummer stemmer med klubben man er innlogget i. Hvis noe er feil får brukeren tilbake en feilmelding som sier hva som gikk galt med linjen. 54

57 Figur 55. Opplastning av dat-filer Oppdatert informasjon Når man importerer en dat-fil, skal all informasjon i databasen bli oppdatert med innholdet i filen. Dette sørger for at nye dat-filer oppdaterer gamle innlegg i databasen. Det hender at brukere har redigert eller lagt inn informasjon i applikasjonen på egenhånd. Slike innlegg skal ikke bli oppdatert når man laster opp en ny dat-fil. Applikasjonen løser dette med å markere redigerte innlegg slik at den vet hvilken informasjon som kommer fra en bruker og hva som har blitt lagt inn ved hjelp av importeringen. Når man laster opp en fil som inneholder redigert innhold vil applikasjonen spørre hva man ønsker å gjøre med disse innleggene. Velger man å overskrive vil innholdet bli overskrevet og markeringen om at innlegget var redigert blir ikke lenger synlig. Lar man være å overskrive blir informasjon om innlegget lagt i en felles dat-referansetabell, slik at applikasjonen automatisk ignorerer innlegget neste gang man prøver å importere det. I tillegg var det ønskelig at innlegg som ble slettet i applikasjonen ikke skulle legge seg inn på nytt neste gang man lastet opp en dat-fil. Ved sletting av innlegg blir de også lagt til i referansetabellen slik at innlegget ikke blir lagt inn på nytt ved neste importering. Referansetabellen inneholder en kort hash av innlegget og originalteksten. Hashen er på 40 tegn og er primærnøkkelen for tabellen. Dette er for å optimalisere tabellen for raske søk. Tabellen er felles for de forskjellige NKK-tabellene. Det ble derfor valgt også å inkludere originalteksten slik at man enkelt kan finne igjen et innlegg. 55

58 Hvordan vi kom frem til denne løsningen Bekk ønsket en enkel måte å legge inn filene fra NKK i databasen. I tillegg ønsket de en løsning som prioriterte innlegg laget av eller redigert av brukeren i forhold til innleggene som fulgte med datfilen Vår løsning Den første løsningen ble en filopplaster som sendte filen til serveren. Serveren gikk så gjennom filen og la inn hvert innlegg i databasen. Hvis innlegget fantes fra før ble det overskrevet. Etter diskusjon med oppdragsgiver kom vi fram til at vi trengte en mulighet til å prioritere brukerredigerte innlegg over innleggene som lå i NKK sine filer. I tillegg ønsket vi å ignorere slettede innlegg ved nye opplastninger. Vår løsning ble å lage en felles tabell for alle innlegg som ikke skulle overskrives av importeringen. Når man slettet en fil ble det i referansentabellen lagt til en referanse. Dette gjorde at det originale innlegget ville det bli ignorert ved nye opplastninger. Vi valgte å lage en hash av innlegget som vi brukte som primærnøkkel. En hash er en unik verdi med fast lengde som representerer en større verdi. Fordi vi brukte hashen av verdien istedenfor selve verdien går det mye raskere å sjekke mot tabellen Utfordringer Importeringen hadde en utfordring som vi ble nødt til å løse: hva slags feilmeldinger gir man tilbake til brukeren når man har importert over innlegg og noen er feil? Her ønsket vi en god og brukervennlig måte å vise tilbakemeldinger til brukeren. Resultatet ble en samlet liste hvor antall nye, oppdaterte og ignorerte innlegg ble vist, samt eventuelle feilmeldinger som programmet selv ikke kunne løse. Med hver feilmelding ble også innlegget som forårsaket det gitt med. Oppdragsgivers ønske om å kunne ignorere slettede og redigerte innlegg bød på en utfordring når det gjaldt implementeringen sin vanskelighetsgrad. Importeringen av filer var allerede ferdig og vi ble nødt til å finne en god måte å løse problemstillingen på uten skrive om alle funksjonene. Løsningen ble her dat-referansetabellen som hjalp oss til enkelt å kunne søke opp innlegg Erfaringer Vi hadde noen problemer underveis med å få en stabil tilkobling mellom klient og server under opplastning av filer. Med Safari i OS X ville ikke dialogen vises hvis tilbakemeldingen på serveren var tom, mens med Firefox i Windows ble koblingen brutt etter 29 sekunder hvis serveren ikke hadde svart klienten ennå. Det var en ny erfaring for oss å oppdage at Flash ikke oppførte seg likt i alle nettlesere og på alle operativsystemer. I starten av prosjektet ble funksjonene i klassene navngitt ut fra hvilken klasse de tilhørte. Funksjonen som genererte arrayet til et hundeinnlegg het for eksempel henthundearray og lå i HundParser klassen. Dette gjorde at hver klasse for en dat-fil hadde forskjellige funksjonsnavn selv om alle i grunn kunne vært arvet fra den samme funksjonen. Etter første versjon av importeringen endret vi alle funksjonnavnene til å være generiske. henthundarray og hentjaktprovearray ble for 56

59 eksempel begge omgjort til hentarray. Dette gjorde at vi enklere kunne skrive generiske funksjoner som fungerte på tvers av de forskjellige klassene Tegnsettproblematikk Håndtering av tegnsett på tvers av plattformer byr ofte på problemer. Her vil vi gjøre rede for problemer relatert til vårt prosjekt og den løsningen vi kom fram til. Tegnsett definerer hvilken bokstav en verdi utgjør. Windows bruker sitt eget tegnsett, mens Mac OS X og Linux ofte bruker UTF-8. I tillegg finnes det andre tegnsett for språk som arabisk, kinesisk og lignende. De skandinaviske tegnene æ, ø og å er for eksempel ikke like på Windows og Linux. Applikasjonen vår er utviklet til å fungere på flere plattformer, og vi måtte ta høyde for at brukeren sitter på en maskin med et annet tegnsett. UTF-8 er et tegnsett hvor hvert tegn består av to eller fire byte. I tillegg er de 128 første tegnene identiske med ASCII-tegnsettet slik at det amerikanske alfabetet blir likt uten å konvertere teksten mellom ASCII og UTF-8. Vi valgte tidlig at all informasjonen i databasen skulle lagres med dette tegnsettet. For å sikre oss at all informasjon fra brukeren blir lagret korrekt, laget vi en funksjon som oversatte tekst til UTF-8. Denne funksjonen er nødvendig da blant annet Windows sitt tegnsett behandler de skandinaviske tegnene annerledes enn hva UTF-8 gjør. Uten å konvertere teksten ville teksten æøå blitt noe slik som aeo..a,. i UTF Konklusjon Å kunne gjengi tekst korrekt på tvers av plattformer har vært kritisk for å kunne muliggjøre applikasjonen vår. Med hjelpefunksjonen for å konvertere all tekst til UTF-8 har vi kunnet forsikre oss om at all tekst blir gjengitt korrekt i applikasjonen Bruker-, rolle- og rettighetshåndtering Oppdragsgiver krevde at vi skulle ha en oversiktlig håndtering av brukere, roller og rettigheter. Applikasjonen bygger på at brukerne har tilgang til funksjoner basert på rollen de har, med rettighetene rollen har fått tildelt. Disse rettighetene aktiverer eller deaktiverer både funksjonaliteten og GUI-delen som er knyttet til funksjonaliteten, i applikasjonen. Dette gjøres for å sikre at brukerne ikke får tilgang til mer enn de har lov til. Vi gjør her rede for hvordan vi løste håndteringen av dette Håndtering Vi brukte mye tid på å finne en god løsning på hvordan administrator kunne gi en rolle rettigheter og hvordan brukere kunne få tildelt roller. Kravet fra veilederne var at vi skulle bruke drag & drop til dette. Vi startet med å se på andre eksisterende løsninger og, naturlig nok, ble Pivotal Tracker et sted å starte. Vi drøftet om vi skulle la flerklubbadministratorer gi roller til brukere av en annen klubb enn den han eller hun selv var logget inn hos. For å gjøre det enklest mulig for alle administratorer og for å forhindre feil droppet vi dette. Roller er universelle for alle klubbene. Hvis roller blir opprettet i en klubb så vil administratorer logget inn hos andre klubber kunne gi de rollene til brukere i klubben de er logget inn hos. 57

60 For å gi rettigheter til en opprettet rolle dras rettigheten fra høyre og droppes over den bestemte rollen. For å slette en rettighet til en rolle dras den tilbake til rettighetslisten og droppes der. Figur 56. Roller og rettigheter Det samme prinsippet er overført til rollehåndtering for brukere. Her ligger brukerne, istedenfor rettigheten, på høyre side og en kan dra brukere inn i spesifikke roller. Figur 57. Brukeradministrasjon Brukere kan også slettes og redigeres. Siden applikasjonen ikke tilbyr åpen registrering, har administrator her mulighet til å legge til nye brukere. Dette sikrer oversikt over hvilke brukere som har tilgang til systemet. 58