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

Størrelse: px
Begynne med side:

Download "HOVEDPROSJEKT 2009-1. Åpen. Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo"

Transkript

1

2

3 PROSJEKT NR Studieprogram: Bachelorstudium i informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL AirDog PROSJEKTDELTAKERE Pelle Bjerkestrand Hans Magnus Inderberg Tore Lervik Egil Paulsen S S S S DATO ANTALL SIDER / BILAG 170/3 INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Bekk Consulting AS ( KONTAKTPERSON Ole Christian Langfjæran SAMMENDRAG 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. 3 STIKKORD Hundeportal Web-applikasjon Flex

4

5 Forord Denne rapporten er en sammenslåing av all dokumentasjon gjort i forbindelse med hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo, våren Prosjektet er gitt av Bekk Consulting AS, som også stiller med to veiledere. Valget falt på dette prosjektet da vi mente det ville gi oss innsikt i hvordan programutvikling skjer i arbeidslivet, samt muligheter til å benytte moderne teknologier og verktøy. Rapporten er delt inn i flere hoveddeler: prosess, produkt med brukerveiledning, krav og test. I tillegg følger det med en rekke vedlegg. Hver del kan leses uavhengig av de andre og har egen innholdsfortegnelse og sidenummerering. Prosessrapport gir innsikt i hvordan vi arbeidet, hvilke valg vi tok og hvorfor. Produktrapport inneholder teknisk informasjon om applikasjonens oppbygging og virkemåte, samt hvordan det kan brukes, installeres, vedlikeholdes og videreutvikles. Brukermanual gir innføring i programmets virkemåte og funksjoner. Kravspesifikasjon presenterer kravene satt til prosjektet av oppdragsgiver og oppdragsgivers kunder. Testrapport tar for seg testing av applikasjonen og resultatet av dette. Kilder Vedlegg er samlet i slutten av rapporten, og inneholder ordliste, dagbok og referater. Kildekoden er både åpen og gratis, og ligger tilgjengelig for alle på code.google.com/p/airdog. Prosjektet er aktivt og koden er derfor under utvikling. Kildekoden slik den var ved innlevering av oppgaven ligger tilgjengelig på prosjektets hjemmeside: student.iu.hio.no/hovedprosjekter/2009/data/01/ Systemet brukes per i dag av to klubber og er tilgjengelig på airdog.no. En testkonto med fiktiv klubb er satt opp til bruk for sensor: Brukernavn Passord sensor@hio.no K4zi5Ab Rapporten er optimalisert for å kunne leses på papir i A4-format. Den er også tilgjengelig som PDF på prosjektets hjemmeside. Vi anbefaler å starte med prosessrapporten for å få et inntrykk av prosjektets omfang. Vi takker veilederne Ole Christian Langfjæran og Erlend Opdahl fra Bekk, samt HiOs veileder Eva Hadler Vihovde, for all hjelp og konstruktiv kritikk underveis.

6

7 Prosessrapport

8 Prosessrapport 2

9 Prosessrapport 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. Prosessrapporten 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

10 Prosessrapport 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

11 Prosessrapport 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

12 Prosessrapport Utvikling Ferdigstilling Produktet Konklusjon

13 Prosessrapport 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

14 Prosessrapport 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

15 Prosessrapport 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

16 Prosessrapport 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

17 Prosessrapport 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

18 Prosessrapport 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

19 Prosessrapport 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

20 Prosessrapport 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

21 Prosessrapport 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

22 Prosessrapport 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

23 Prosessrapport 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

24 Prosessrapport 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

25 Prosessrapport 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

26 Prosessrapport 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

27 Prosessrapport 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

28 Prosessrapport 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

29 Prosessrapport 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

30 Prosessrapport 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

31 Prosessrapport 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

32 Prosessrapport 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

33 Prosessrapport 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

34 Prosessrapport 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

35 Prosessrapport 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

36 Prosessrapport 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

37 Prosessrapport 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

38 Prosessrapport 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

39 Prosessrapport 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

40 Prosessrapport 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

41 Prosessrapport 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

42 Prosessrapport 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

43 Prosessrapport 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

44 Prosessrapport 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

45 Prosessrapport 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

46 Prosessrapport 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

47 Prosessrapport 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

48 Prosessrapport 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

49 Prosessrapport 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

50 Prosessrapport 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

51 Prosessrapport 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

52 Prosessrapport 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

53 Prosessrapport 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

54 Prosessrapport 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

55 Prosessrapport 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

56 Prosessrapport 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

57 Prosessrapport 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

58 Prosessrapport 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

59 Prosessrapport 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

60 Prosessrapport 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

61 Prosessrapport 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

62 Prosessrapport 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

63 Prosessrapport 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

64 Prosessrapport 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

65 Prosessrapport Konklusjon Den endelige løsningen resulterte i det vi mener er en god funksjon som gir brukeren kontroll over hva som blir importert. Det gis tilbakemelding til brukeren om hva applikasjonen gjør og hva som eventuelt er feil, samt valg der applikasjonen selv ikke har mulighet til å vite hva som er den ønskede handlingen. Løsningen er i tillegg laget på en slik måte at man enkelt kan legge til nye filstrukturer hvis NKK kommer med nye eller oppdaterte filer Årbok Årbokfunksjonaliteten ble sett på som den store stygge ulven, både av oppdragsgivere og av oss som utviklere. User storyen var beskrevet som følger: Som en administrator skal jeg kunne generere Word dokumenter i årbokformat slik at jeg kan enklere kan lage en årbok for et gitt år Akseptansekriterer Gitt at jeg er en administrator når jeg velger å eksportere til Årbok og velger år skal jeg få mulighet til å laste ned et rikt tekstformatert dokument som inneholder alle hannhunder som har avkom som har deltatt i jaktprøver det valgte året Gitt at jeg er en administrator når jeg inne på en hund og velger eksporter til årbokformat og velger år skal jeg få mulighet til å laste ned et rikt tekstformatert dokument som inneholder alle kull og jaktresultat for det valgte året for den valgte hunden I vanskelighetsgrad var denne funksjonen estimert til åtte poeng. Dette var ikke en prioritert user story og oppdragsgiver regnet ikke med å få med denne i det endelige produktet. Etter hvert som vi fikk mer trening i programmering, fikk vi bedre tid enn ventet og valgte å starte på denne. "Ekstra hyggelig var det å se at de ble ferdige med brukerhistorien for Årboka, som før prosjektstart var fryktet å være for omfangsrik til å kunne utføres innenfor tiden." - Bekk Siden verken ActionScript eller PHP hadde innebygde funksjoner for eksportering til ønsket Microsoft Word-standard, var dette noe vi måtte bygge fra bunnen av. Først måtte vi lage maler og dele opp disse med plassholdere for at vi senere skulle kunne fylle disse med gyldig informasjon. 59

66 Prosessrapport Vi startet med å undersøke om det fantes informasjon om hvordan Word , RTF- og Word filer var bygd opp, og om det fantes noen eksisterende løsninger. Det viste seg at det fantes mange tidligere løsninger på dette, men de passet ikke vårt behov. Word 2007 er bygget opp ved hjelp av XML og kunne vært et godt valg. Vi valgte heller å gå for RTF, da dette formatet både er plattformuavhengig og ukomprimert. Man trenger heller ingen komplisert parser for å redigere det, noe man ville trengt for filer i Word 2007-format. Vi så også på hvilken informasjon som skulle inn i dokumentet, og laget et skjema for å få en bedre oversikt over dette. Se Figur 58. En årbok er bygd opp av lister: hunder, kull, kullenes hunder, avkom og jaktprøver. Det vi gjorde var å dele opp disse listene i forskjellige maler. Slik kunne vi bruke disse malene i en for loop og sette dem sammen til en tekststreng for til slutt å sende denne strengen tilbake til klienten som en doc-fil. Denne filen er egentlig er en rtf-fil, men med endret filetternavn slik at den vil åpne seg i Microsoft Word. Dette var ønskelig fra oppdragsgivers side. Vi opplevde denne oppgaven som både spennende og utfordrende. Vi mener, ved å sammenligne flere mulige løsninger, at vi klarte å løse problemet på en effektiv og god måte. Figur 58. Årbokstruktur 6.3 Sluttfasen Ved prosjektperiodens slutt måtte vi stoppe utviklingen og konsentrere oss om å optimalisere det vi hadde laget. AirDog hadde stort utvidelsespotensiale, men måtte begrenses for den relativt korte prosjektperioden vi hadde. Her vil vi ta for oss den avsluttende delen hvor vi fokuserte på å implementere det vi hadde laget Optimalisering for produksjon Før vi kunne levere produktet sørget vi for å forbedre ytelsen til applikasjonen. Vi brukte en del hjelpemidler som vi vil gjøre rede for her Feilmeldinger Detaljerte feilmeldinger var et glimrende hjelpemiddel under utviklingen, og det gjorde at man enklere kunne spore feil i koden som ikke nødvendigvis var tydelige. Applikasjonen var delt i to hoveddeler, klienten som var laget i Flex og serverdelen som var laget i PHP. Denne oppdelingen gjorde at det ble vanskelig å feilsøke hva som skjedde på serverdelen hvis klienten ikke fikk svar. I serverdelen hadde vi under utviklingen slått på ekstra feilmeldinger ved å sette ini_set("display_errors", "on");. Slike feilmeldinger var gode å ha under utvikling, men for andre brukere kunne de være både forstyrrende og gi mer informasjon enn det som var ønskelig. Det 60

67 Prosessrapport kunne også gjøre mulig for en bruker å finne svakheter i applikasjonen som kunne utnyttes til andre formål en det som var tiltenkt Loggføring av SQL Under utviklingen benyttet vi oss av en måte å loggføre overføringene mellom serverdelen og databasen. Dette står nærmere forklart i Optimalisering av MySQL. Ved hjelp av denne metoden fant vi mange løsninger som gjorde søk mot databasen opptil flere ganger raskere. Loggføring hjalp oss å løse flere generelle problemer underveis, blant annet problemer med importering av dat-filer. Loggføringen krevde mye ressurser og burde ikke brukes på annet enn testmaskinene under utviklingen Konklusjon Under utviklingen har vi brukt hjelpemidler for å gjøre feilsøking og optimalisering lettere. Dette har fungert på en tilfredsstillende måte. Hjelpemidlene har til tider vært svært viktig for oss, men for sluttbrukere vil de både være forstyrrende og unødvendige. 61

68 Prosessrapport 7 Kravspesifikasjonen og dens rolle Kravspesifikasjonen skal gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til systemet som skal utvikles. Videre har kravspesifikasjonen definert prosjektets rammer og krav til brukervennlighet, kvalitetssikring og sikring av data. I dette kapittelet vil vi gjøre rede for hvilken rolle kravspesifikasjonen har hatt for prosessen, hvordan den ble utformet og på hvilken måte kravspesifikasjonen gjenspeiler det endelige produktet. 7.1 Bakgrunn for kravspesifikasjonen Prosjektet har fulgt smidig utviklingsmetodikk. Dette har som konsekvens for kravspesifikasjonen at vi ikke har hatt et ferdig styringsdokument. Likevel hadde prosjektet fra et tidlig tidspunkt satte rammer når det gjaldt forbehold om sikkerhet, kompatibilitet og bruk av utviklingsverktøy. Smidig utviklingsmetodikk er omtalt nærmere i kapittelet Planlegging og metode Rammekrav I praksis ble systemets rammekrav satt i startfasen av prosjektet. Det ble under de første møtene vedtatt hvordan vi skulle forholde oss til sikkerhet, kompatibilitet, struktur og verktøy. Brukergruppen til applikasjonen kom til å være stor. Dette betyr at brukerne i utgangspunktet kunne ha stor spredning når det gjaldt kjennskap til internett og web-appikasjoner. Dette satte krav til kompatibilitet for flere ulike plattformer og nettlesere. Det satte også krav til brukervennlighet med hensyn til konvensjoner og selvinstruerende funksjonalitet i applikasjonen. Dette førte til at brukeropplevelse ble tatt hensyn til under hele utviklingsfasen, og det ble dermed gjort prototypetesting og jevnlige brukertester på programmet ettersom det tok form. Da systemet skulle håndtere informasjon om reelle brukere og persondata registrert i NKK sin database, ville en del opplysninger karakteriseres som sensitive. Videre kom systemet til å ha en rekke funksjoner som ikke skulle være tilgjengelig for alle brukere. For å unngå misbruk av data ble det vedtatt å tildele roller til alle brukerne av systemet. Ulike brukere ville ha ulike behov, og derfor skulle systemet la det være mulig å skreddersy roller ved å bestemme hvilke rettigheter hver rolle skal ha. Fokus på sikkerhet og håndtering av data førte til en sikrere systemarkitektur og krav til rettigheter sikret applikasjonen bedre mot tap og misbruk av data. Oppdragsgiver hadde på forhånd krav til selve koden og muligheter for vedlikehold etter at systemet var ferdig levert. Systemet skulle programmeres til å være skalerbart og samtidig mulig for en utenforstående utvikler å sette seg inn i. Dermed måtte vi følge prinsipper fra kjente designmønstre. Det ble bestemt at vi skulle følge MVCS som designmønster for dens fleksibilitet og oversikt. Dette førte til at vi kunne utvikle med stor frihet på hver våre komponenter, og likevel få et stort, men oversiktlig system. Mer om MVCS er omtalt i kapittelet Utviklingsfasen. Da vi tidlig bestemte oss for en oversiktlig systemarkitektur med et godt fundament møtte vi også kravet om at systemet skulle ha muligheter for fremtidige utvidelser. Strukturen vi la opp til er modulbasert slik at det er mulig å skifte både tjener og klient. Bruk av Zend rammeverket på tjenersiden gjør det også mulig å skifte database fra MySQL til for eksempel Oracle. Zend rammeverket er nærmere omtalt i kapittelet Utviklingsfasen. 62

69 Prosessrapport Vi fulgte disse rammekravene uten at det hemmet fleksibiliteten ved å jobbe etter smidig utviklingsmetodikk. Å ha klare rammer satt på et tidlig stadium ga oss god styring for å utvikle et solid fundament til applikasjonen, men ikke nødvendigvis hvordan applikasjonen i seg selv ville se ut og fungere til slutt. Dermed kunne vi bygge på et allerede fungerende fundament og levere fungerende kode for hver iterasjon Levende styringsdokument Foruten satte rammekrav, har kravspesifikasjonen formet seg etter hvert som oppdragsgiver har begjært funksjonelle krav for hver iterasjon. Under selve utviklingsperioden og på iterasjonsmøtene har vi derimot benyttet oss av planleggingsverktøyet Pivotal Tracker et verktøy spesielt tilpasset smidig utviklingsmetodikk. Pivotal Tracker håndterer user stories som fungerer som funksjonelle krav. Pivotal Tracker blir grundig omtalt under Planleggingsverktøy i kapittelet Planlegging og metode. Hver user story lagt frem av oppdragsgiver ble så oversatt som et funksjonelt krav i kravspesifikasjonen. Selv om Pivotal Tracker var det umiddelbare styringsdokumentet brukt av både oss og oppdragsgiver, ble kravspesifikasjonen brukt til å dokumentere de krav som ble etterfulgt og implementert. På denne måten fungerte kravspesifikasjonen som et levende styringsdokument som bekreftet endringer etter som oppdragsgiver prioriterte funksjonalitet. 7.2 Vår erfaring med kravspesifikasjonen Slik vi har jobbet opp mot kravspesifikasjonen i forhold til smidig utviklingsmetodikk, har det ført til fleksibilitet, men også forutsigbarhet. Gjennom hele tiden å ha oversikt over hvilke funksjonelle krav som lå i Pivotal Tracker-listen, kunne vi under iterasjonsmøtene estimere og prioritere hvilke funksjonelle krav som skulle være med i kravspesifikasjonen. Vi oppdaterte kravspesifikasjon etter hvert iterasjonsmøte, slik at det var realistisk å gjennomføre de funksjonelle kravene. Vi mener at å jobbe på denne måten var den mest egnede med tanke på hvor fleksibel utviklingsmetodikken krevde at vi var. Likevel, ved å følge rammekrav som var satt i startfasen sikret vi kontinuitet og forutsigbarhet i både kode og arbeidsmetode. Dette mener vi bekrefter at smidig utviklingsmetodikk ikke er rotete, men tilpasningsdyktig innenfor forhåndsbestemte rammekrav. Endringer i kravspesifikasjonen på prosjekter er svært vanlig. Å følge en kravspesifikasjon som får lagt til funksjonelle krav fortløpende som resultat av smidig utviklingsmetodikk har for oss fungert bra. 7.3 Kravspesifikasjonen og det endelige produktet Bak kravspesifikasjonen som styringsdokument lå en rekke forventninger til produktet vi leverte. Her vil vi reflektere rundt kravspesifikasjon og det endelige produktet Oppfyllelse av krav Alle storyene som ble lagt frem per iterasjon ble fullført. I kapittelet Smidig utviklingsmetodikk nevnes det at user storyes fungerer som funksjonelle krav til systemet. Kravene listes i utgangspunktet opp som en svært optimistisk ønskeliste av en rekke funksjoner. Det var ikke forventet av oppdragsgiver at vi skulle klare å levere alle funksjoner ved prosjektets slutt. Det var opp til oppdragsgiver å prioritere hvilken funksjonalitet de ønsket å ha implementert for å kunne benytte 63

70 Prosessrapport seg av produktet så langt det ble ferdig. Likevel klarte vi å levere langt flere funksjoner enn hva som var regnet med i utgangspunktet. Funksjonelle krav som ikke ble implementert til fordel for prioritert funksjonalitet, blir nærmere omtalt i kapittelet Utvidelsesmuligheter under Estimert funksjonalitet Tilbakemelding fra oppdragsgiver Da vi ikke gikk ut fra en tradisjonell kravspesifikasjon, men fulgte en Scrum-basert smidig utviklingsmetodikk, ville den endelige kravspesifikasjonen i form av user storyer alltid stemme med ferdig produkt. På den andre siden fikk vi gode tilbakemeldinger både på antall gjennomførte user storyer og det ferdige produktet. Hvorvidt kravspesifikasjonen stemmer overrens med produktet kan vurderes etter måten løsningen tilfredstiller kravene til oppdragsgiver. Sitatene som følger kan leses i sin helhet under delkapittelet Ord fra eksterne veiledere: "Noen er såpass fornøyd med løsningen at de ønsker at den skal presenteres slik den er i dag for alle klubbene!" "Ekstra hyggelig var det å se at de ble ferdige med brukerhistorien for Årboka, som før prosjektstart var fryktet å være for omfangsrik til å kunne utføres innenfor tiden." "De overrasket oss [...]" "Det viktigste kravet [...] må også sies å være opprettholdt. Bra!" 7.4 Konklusjon Kravspesifikasjonen spilte en sentral rolle for oss da det gjaldt å definere prosjektets rammer og omfang. Prosjektets rammer var definert på en måte som gjorde at utviklingen av selve programmet sin funksjonalitet var fleksibel og tilpasningsdyktig. Videre fungerte kravspesifikasjonen som et styringsdokument parallelt til planleggingsverktøyet Pivotal Tracker, som var et viktig hjelpeverktøy når det gjaldt å organisere, estimere og prioritere de funksjonelle krav som så ble en del av kravspesifikasjonen. Dette var en effektiv måte å forholde seg til et styringsdokument som, ikke bare i et prosjekt som følger smidig utviklingsmetodikk, tilføyes endringer fortløpende under hele prosjektperioden. Ved at vi leverte mer funksjonalitet enn oppdragsgiver hadde estimert, mener vi at produktet i høyeste grad samsvarer med forventningene fra oppdragsgiver og dermed tilfredstiller de funksjonelle krav som er listet opp i kravspesifikasjonen. Basert på tilbakemeldingen fra oppdragsgiver og brukerne av applikasjonen, legger vi til grunn at vårt produkt samsvarer med, og inneholdt mer enn, kravspesifikasjonen og forventningene til oppdragsgiver. 64

71 Prosessrapport 8 Avsluttende del Avslutningsvis vil vi reflektere hva vi og oppdragsgivers mener om prosjektet. Vi vil oppsummere prosessen og arbeidsfordelingen, og helt til slutt si noen ord om det endelige produktet. 8.1 Ord fra eksterne veiledere Figur 59. Kopi av attest fra Bekk 65

72 Prosessrapport 8.2 Samarbeid i gruppen Gruppen har jobbet sammen før, kjenner hverandre godt og har samme ambisjonsnivå. Samtidig er gruppen satt sammen av fire meget forskjellige personer, der hver enkelt har sterke meninger om det meste. Vi mener at denne unike sammensetningen har gjort at samarbeidet har fungert meget godt i løpet av prosjektets fem måneder. Selv om gruppen har en tendens til å være uenige, kommer vi alltid frem til en felles løsning som vi da mener er den beste. Dette fører til at det vi leverer ofte er mer gjennomført og at de fleste funksjoner og detaljer i produktet er gjennomtenkt. Sykefravær, ferier og dager der noen er litt mindre produktive enn vanlig overses ikke, men tidligere erfaringer med samme gruppe gjør at alle medlemmene stoler på at hver enkelt gjør sin del av arbeidet. Dette har gitt gruppemedlemmene større frihet og et ønske om å gjøre sitt beste istedenfor at arbeidet føles som en plikt. Motivasjonen har derfor vært høy, og humøret godt, gjennom hele prosjektperioden Arbeidsfordeling Vi har jobbet etter smidig utviklingsmetodikk og dette har preget vår arbeidsfordeling positivt. Med dette mener vi at alle har fått deltatt i alle deler av prosjektet, og alle har fått en samlet forståelse over hele prosessen. Dette har ført til at hver og en har kunnet hoppe fra en rolle en dag til en annen rolle en annen dag. Det er naturlig at hvert enkelt gruppemedlem vil føle seg mer komfortabel i en viss rolle, og også søke etter denne. Den generelle rolleinndelingen er forklart nedenfor Egil Paulsen Egil er en dyktig kunstner og filmskaper som, naturlig nok, har stor interesse for brukeropplevelse og HCI. Han har holdt mest på med GUI-utforming og -programmering og er den som har tatt ansvaret for prosessstyringsdokumenter underveis i prosjektet Hans Magnus Inderberg Hans Magnus har stor interesse for både programmering og HCI. Han er flink til å oppfatte status for prosjektet som helhet og fungerer dermed ofte som en motivator. I tillegg har han sittet mest med programmering, rammeverk og arkitektur på serversiden Tore Lervik Tore er en hardbarket programmerer som ved siden av studiene bruker mye tid på utvikling i Visual Studio med.net-rammeverket. Han tok ansvaret for mye av den underliggende tekniske arkitekturen. Han fikk prisen Microsoft Most Valuable Professional 2009 for hans arbeid innen virtualisering Pelle Bjerkestrand Pelle har programmert mye på klientsiden og har ofte vært innom andre sin kode og rettet feil. Han har vært gruppens talsmann og har hatt et godt overblikk over hele applikasjonen. Han har tidligere gått allmennlærerstudiet og fungert som gruppens oppslagsverk for rettskriving og grammatikk. 8.3 Veiledning fra HiO Ved å jobbe etter smidig utviklingsmetodikk hadde tradisjonell dokumentasjon liten eller ingen betydning når det gjaldt å følge standarder. Oppdragsgiver krevde heller ikke noen form for dokumentasjon annet enn at koden vår helst skulle kunne være selvforklarende og uten kommentarer. For oss førte dette til at det ble bestemt at så å si all dokumentasjon skulle bli 66

73 Prosessrapport produsert i mai måned, etter all koding var ferdig. Vi hadde likevel ukentlige møter med vår veileder, Eva H. Vihovde, der vi diskuterte sluttdokumentasjonens oppbygning, form og innhold samt hvordan dette skulle beherskes. Etter hvert uteble noen av de ukentlige møtene, da veileder mente vi var, i programmeringsperioden, selvgående. Kontakten ble da opprettholdt via e-post. Av all dokumentasjon, skiller kravspesifikasjonen seg ut som noe som var problematisk for oss. Diskusjoner rundt hvordan vi skal oversette begreper fra smidig utviklingsmetodikk som user story samt oppdragsgivers og kundenes ønsker, til krav som gir mening i en kravspesifikasjon har vært lange og mangfoldige. Her har vi dratt nytte av Evas erfaringer som veileder til tidligere hovedprosjekter og vi mener at vi sammen har kommet fram til en god løsning på problemet med denne oversettelsen. Mer om kravspesifikasjonen vil ble gjort rede for i kapittelet Kravspesifikasjonens rolle. Figur 60. De som påvirker kravspesifikasjonen Vi mener at vi har hatt god nytte av Evas veiledning og at dokumentasjonsperioden både ville ha vært vanskeligere og mer frustrerende uten hennes hjelp. Etter innlevering av denne rapporten skal vi gjøre flere prøvepresentasjoner for å forberede oss til endelig presentasjon for sensor. Her er det lagt opp til veiledning rettet mot innhold, regi og tidsbruk på de forskjellige delene. 8.4 Refleksjonsnotat Når vi ser tilbake på prosjektperioden opplever vi at vi deler den opp i faser. Vi kaller de planlegging og oppstart, utvikling og ferdigstilling. Vi vil her prøve å formidle våre tanker, refleksjoner og erfaringer rundt disse fasene. Videre vil vi si noen ord om det ferdige produktet Planlegging og oppstart Den første av disse fasene består av, som navnet antyder, planleggingen før semesteret begynte og oppstarten til selve prosjektet. Det å ha oppdragsgivere, kunder og veiledere å forholde seg til mener vi var nyttig for oss, da det ble skapt et tydeligere bilde av hvordan arbeidslivet er. Her møtte vi mange tekniske utfordringer i oppsett av servere og læring av nye programmeringsspråk. Disse utfordringene føler vi "løste seg selv" da vi jobbet aktivt med de hver eneste dag. Videre fikk vi rettet forestillinger rundt rollen både oppdragsgivers og høgskolens veiledere ville ha. Der vi først så for oss et aktivt samarbeid med opplæring hos oppdragsgiver med konkrete tilbakemeldinger på kodestruktur og annen teknisk assistanse, fikk vi heller nærmere full tillit og frihet til å være selvgående. I begynnelsen var dette uvant og frustrerende, men etterhvert skjønte vi at vi faktisk hadde forutsetninger for å kunne være vår egne sjefer og frykten for å ta valg som kunne skape konsekvenser for andre dabbet av Utvikling Begynnelsen av utviklingsfasen kan beskrives med stikkord som usikkerhet, prøving, feiling og frustrasjon. Etter hvert som vi ble mer og mer sikre i det vi drev på med endret disse begrepene seg 67

74 Prosessrapport til noen med mer positiv klang. Utviklingen fikk da god flyt og gikk raskere enn vi hadde forestilt oss. Dette førte til økt motivasjon, og også glede, av å løse vanskelige oppgaver knyttet til prosjektet. Vi mener at den smidige utvilkingsmetodikken, der tradisjonell gruppestruktur med én gruppeleder ikke eksisterer, var noe som førte til økt arbeidslyst, samhold og eierskapsfølelse for produktet. Dessuten var produktet vi skulle lage en helhetlig løsning som bød på varierte oppgaver Ferdigstilling For ferdigstilling av produktet hadde vi satt fristen til 1.mai. I løpet av siste iterasjon var noen av oppgavene å rydde i koden og optimalisere for den endelige leveransen. Resten av prosjektperioden var satt av til å jobbe med dokumentasjonen. Fordi vi hadde satt klare frister for hva som skulle være ferdig når, hadde vi klare milepæler å følge. Iterasjone la opp til disse fristene allerede fra starten av, og sørget for å sikre et jevnt arbeidstempo. Da iterasjonsintervallene var såpass korte, var det enklere å vurdere tidsbruken for oppgaver realistisk. På grunnlag av dette, klarte å holde tidsrammer på en god måte. Vi benyttet mye tid av møtene med skolens veileder til å diskutere problemstillinger rundt dokumentasjonen. Dette gjorde at vi, allerede tidlig i prosjektperioden, skrev delrapporter som veileder ga oss tilbakemelding på. Dette førte til at vi var bedre forberedt på dokumentasjonsdelen, og gjorde oss observant på hva vi mente var viktig å få med i sluttrapporten Produktet Til slutt vil vi reflektere over det ferdige produktet. Vi har i denne rapporten lagt vekt på prosessen i å utvikle dette programmet. Her vil vi drøfte kvalitetene til AirDog. Ut i fra veiledernes og brukernes tilbakemeldinger, har vi fått et intrykk av at applikasjonen har blitt godt mottatt. AirDog er i drift på airdog.no og brukes allerede av klubbenes medlemmer. Programmet skalerer bra, har en rekke utvidelsesmuligheter og potensiale for å brukes i andre sammenhenger. Vi har tilegnet oss gode erfaringer til å utvikle en større applikasjon, og AirDog introdusert oss for en rekke utfordringer og problemstillinger som vi vil dra nytte av i arbeidslivet Konklusjon Basert på våre tanker og erfaringer med de ulike fasene, mener vi at vi har hatt en fin og engasjerende prosjektperiode. Vi støtte på mange utfordringer, men vi hadde en god progresjon innenfor satte tidsrammer. Det har vært gøy å jobbe sammen i gruppen og sammen med trivelige veiledere. I tillegg til å måtte sette oss inn i nye og spennende teknologier, har vi lært mye nyttig når det kommer til prosjektstyring og samarbeid. Produktet i sin helhet har blitt godt mottatt av sluttbrukerne, og noen av tilbakemeldingene vi har mottat er: Godt gjennomtenkt, god struktur, brukervennlig og solid. Dette bekrefter også den følelsen vi alle sitter igjen med, da vi har lagt mye arbeid i prosjektet. Vi mener vi leverte et godt produkt som vi er stolte av. 68

75 Produktrapport

76 Produktrapport 2

77 Produktrapport 1 Forord Denne rapporten er prosjektets produktrapport og redegjør for programmets virkemåte, funksjonalitet og tekniske oppbygging både på klient- og serversiden. Rapporten er beregnet for sensor og veileder, men kan også leses av andre interessenter. Det vil være en fordel for leser å ha datatekniske kunnskaper knyttet til programutvikling. Rapporten er beregnet på personer som allerede er kjent med de benyttede teknologiene, men som ønsker bedre kjennskap til oppbygningen av applikasjonen. Rapporten gjør rede for sentrale deler i programmets under følgende hovedtemaer: Struktur i kildekoden på klient- og serversiden Forklarer programmets oppbygning og virkemåte Adgangs- og rettighetskontroll Tar for seg sikkerhetsmekanismer i forhold til brukerne av systemet Zend Framework Tar for seg rammeverket som støtter sentrale deler i programmet, og hvordan det er benyttet Feilsøking i Flex, PHP og PHP sammen med Flex Gir innsikt i teknikker på hvordan en som utvikler kan forholde seg til utviklingsmiljøet Utvidelsesmuligheter Gjør rede for allerede planlagt funksjonalitet for programmet, samt muligheter for andre bruksområder hvor løsningen kan sees på som generisk Prosessrapporten vil gi en dypere beskrivelse av utviklingsperioden og den benyttede metodikken. Vedlagt finnes en ordbok der leseren kan slå opp datatekniske og prosessrelaterte ord og uttrykk som er nevnt her. 3

78 Produktrapport 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 Krav for installasjon og drift av programmet Server Klient Struktur i kildekoden på klientsiden Presentasjonslaget Sesjonslaget Kontrollerlaget Servicelaget Modellene Historieklassen Renderklassene Struktur i kildekoden på serversiden index.php AMF-protokollen Model Controller ValiderBruker Database Filopplaster

79 Produktrapport FilopplastController ImportParserController Parser BildeendringController Årbok AarbokController Verktøy Databasestruktur Adgangs- og rettighetskontroll Adgangskontroll Rettighetskontroll Databasen Zend Framework Zend_Amf Eksempel Zend_Auth Zend_Db Zend_Feed Nyhetsleser Klientside Serverside Feilsøking i Flex Feil som oppdages av Flex Builder Feilmeldinger i Flash Player Feil som gjør at applikasjonen ikke starter FlexUnit Feilsøking i PHP Logging av verdier Meldinger til klienten PHPUnit Feilsøking mellom PHP og Flex Charles

80 Produktrapport 15 Kravspesifikasjonen og det endelige produktet Oppfyllelse av krav Tilbakemelding fra oppdragsgiver Utvidelsesmuligheter Endringer i eksisterende funksjonalitet Nyhetsleser Caching Estimert funksjonalitet Ny funksjonalitet Helse Favoritthunder Andre bruksområder Konklusjon

81 Produktrapport 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 har Figur 1. AirDog-logo 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. 7

82 Produktrapport Veileder Ole Christian Langfjæran sitt system benyttes av denne klubben. 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

83 Produktrapport 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

84 Produktrapport 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

85 Produktrapport 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

86 Produktrapport 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

87 Produktrapport 5 Krav for installasjon og drift av programmet 5.1 Server Programmet er skrevet i PHP og benytter en MySQL-database. Dette krever en webserver med PHP med utvidelsen MySQLi og en MySQL-database installert. 5.2 Klient Klientsiden av programmet vil kreve at brukeren kjører en hvilken som helst nettleser kompatibel med Adobe Flash Player versjon 10 eller nyere. Flash Player 10 kjører per dags dato på Microsoft Windows, Apple Mac OS X, Sun Solaris og Linux. Minimumskrav for Flash Player 10 hentet fra Adobe sine nettsider: Windows Macintosh Linux Intel Pentium II 450MHz, AMD Athlon 600MHz or faster processor (or equivalent) PowerPC G3 500MHz or faster processor Intel Core Duo 1.33GHz or faster processor Modern processor (800MHz or faster) 128MB of RAM 128MB of RAM 512MB of RAM, 128MB of graphics memory 13

88 Produktrapport 6 Struktur i kildekoden på klientsiden Her tar vi for oss struktureringen av kode i Flex-applikasjonen. Applikasjonens hovedklasser benytter seg av en MVCS-struktur for å skille de forskjellige delene. Vi betegner de ulike komponentene i MVCS strukturen som presentasjonslag, kontrollerlag, servicelag og modeller. Applikasjonen starter med AirDogMain.mxml som instansierer MainComponents.mxml for logikk og lagring, og MainView.mxml for presentasjonslaget. Components-klassen som er instansiert av AirDogMain gjennom MainComponents, er tilgjengelig globalt i applikasjonen. Dette gjør det mulig å kalle på service, historie, session eller controller ved å bruke no.airdog.services.components.instance.<klassenavn> i kildekoden. Figur 16. Filstruktur 6.1 Presentasjonslaget Presentasjonslaget tar for seg alle visninger i applikasjonen. Laget inneholder ingen større funksjoner, og all logikk som kan trekkes ut skal ligge i kontrollerlaget. Layout for brukergrensesnittet skal ligge her mens design skal ligge i stil.css. Laget starter med MainView.mxml som inneholder brukergrensesnittet for applikasjonen. 14

89 Produktrapport Stilark Filen stil.css ligger under AirDogMain.mxml og inneholder alle stilene som blir benyttet av presentasjonslaget. Stilene angir hvordan applikasjonen skal se ut og hvordan elementer som knapper og tekst skal vises i brukergrensesnittet. Et eksempel tatt fra stil.css.viewmeny { backgroundcolor: #e5ecf3; paddingbottom: 4; paddingleft: 4; paddingright: 4; paddingtop: 4; verticalalign: middle; } Her ser man at bakgrunnsfargen er satt til #e5ecf3, det er en 4-piksel stor padding rundt, og at elementet er plassert vertikalt i midten. 6.2 Sesjonslaget Data for applikasjonen ligger lagret i sesjonslaget. Laget er instansiert av Components.as og er tilgjengelig for alle klassene i applikasjonen. Data som skal vises i presentasjonslaget blir lagret her slik at kontrollerlaget kan manipulere informasjonen uten å røre presentasjonslaget. 6.3 Kontrollerlaget Kontrollerlaget tar for seg all logikk i applikasjonen. Presentasjonslaget kan spørre kontrollerlaget om å utføre en funksjon, som igjen vil oppdatere sesjonslaget slik at presentasjonslaget viser den nye informasjonen. Dette gjør at kontrollerlaget ikke kjenner til presentasjonslaget og er på ingen måte bundet til den ene presentasjonen. Dette gjør det enkelt å endre presentasjonslag slik at man kan konvertere en applikasjon til for eksempel en web-applikasjon. 6.4 Servicelaget Dette laget er på mange måter et underlag av kontrollerlaget, og står for logikken mot eksterne tjenester. Dette laget har som mål å kommunisere mellom applikasjonen og eksterne tjenester over en gitt protokoll. Grunnen til at dette laget er separert fra kontrollerlaget, er at man enkelt skal kunne bytte ut laget for å benytte seg av andre protokoller eller måter å kommunisere eksternt. 6.5 Modellene Modellene brukes i hele applikasjonen og sendes også fram og tilbake mellom klient- og tjenerdelen. Modellene inneholder en spesiell markering i starten av klassen for å si hvilket objekt de representerer på serverdelen. En slik markering kan se ut som dette: [RemoteClass(alias="AmfHund")] 15

90 Produktrapport Modellobjektene er brukt av de fleste klassene i applikasjonen, og vi har derfor valgt ikke å knytte dem til noen spesiell del. 6.6 Historieklassen Historieklassen tar for seg implementeringen av fram- og tilbakeknapp i applikasjonen. Flash har ingen innebygd måte å lagre tilstander i besøkshistorien, så applikasjonen setter manuelt disse bokmerkene med hjelp fra denne klassen. 6.7 Renderklassene Renderklassene er presentasjonsklasser som tar for seg visningen av et objekt. Disse klassene gjør det mulig å effektivt bytte ut hvordan en tabell presenterer informasjonen. 16

91 Produktrapport 7 Struktur i kildekoden på serversiden Her tar vi for oss struktureringen av kode på serversiden der vi vil gå gjennom hovedkomponentene bak systemet. PHP-delen av applikasjonen er delt inn i to lag. Applikasjonens logikk utføres i Kontrollerlaget, mens all kommunikasjon mot databasen utføres i databaselaget. Flex-klienten fungerer som presentasjonslaget. Figur 17. Filstruktur 7.1 index.php Index.php brukes til å definere hvilke funksjoner som er tilgjengelig for Flex-applikasjonen over AMFprotokollen. I tillegg defineres modellene i index.php slik at Flex-applikasjonen sine modeller samsvarer med de på serversiden. Her defineres hver kontrollerklasse samt de forskjellige modellene som benyttes. Et eksempel på hvordan dette gjøres vises under. $server = new Zend_Amf_Server(); $server->setclass("hundcontroller"); $server->setclassmap("amfhund", "AmfHund"); 17

92 Produktrapport AMF-protokollen AMF (Action Message Format) er et binærformat som baserer seg løst på SOAP (Simple Object Access Protocol). AMF brukes primært til å sende data mellom en Adobe Flash-klient og en server. AMF tilgjengeliggjør svar av typen objekter og er den protokollen vi har benyttet mest Model Model-klassene brukes til å definere egenlagde objekter. Disse defineres på både server- og klientsiden slik at de kan sendes over AMF-protokollen Controller Controller-klassene inneholder de metodene som er tilgjengelig over AMF-protokollen som klienten benytter seg av. Det er i dette laget at brukerrettigheter blir kontrollert før handlinger i databaselaget blir utført. I tillegg er det i dette laget selve logikken blir utført, samt oversettelse mellom databasesvar og AMF-objekter. Et eksempel på en funksjon i en kontroller public function eksempelfunksjon($brukerepost, $brukerpassord, $klubbid) { If (ValiderBruker::validerBrukerRettighet($this->database, $brukerpassord, $klubbid, "rettighet")) { // Utføre handlinge return $informasjonen; } $feilkode = 1; throw(new Exception('Du har ikke denne rettigheten', $feilkode)); } $brukerepost, Hver funksjon i kontrollerlaget er åpent tilgjengelig, det er derfor viktig og starte funksjonen med å autentisere brukeren som ønsker å utføre handlingen ValiderBruker ValiderBruker-klassen inneholder funksjoner for autentisering. Den funksjonen som blir brukt mest i denne klassen er validerbrukerrettighet, som brukes til å sjekke om brukeren har rettighet til å utføre gitt handling. Brukervalidering er nødvendig siden funksjonene tilgjengelig over AMFprotokollen er tilgjengelige for alle. Hvis en bruker har verdien superadmin satt i databasen, vil rettigheten alltid bli validert Database Databaselaget tar for seg all kommunikasjon mellom applikasjonen og databasen, og det er her databasespesifikk logikk utføres. Dette laget er lagt for seg selv slik at man ikke skal trenge å endre noe i andre deler av applikasjonen hvis databasen endres. I vårt databaselag har vi benyttet oss av Zend_Db til å kommunisere med MySQL-databasen. 18

93 Produktrapport Zend_Db Zend_Db gir en god kodestruktur på databasespørringer, og rammeverket støtter i tillegg flere andre databasetyper som for eksempel Oracle, SQLLite, MSSQL og DB2. Et eksempel på en databasespørring i Zend_DB $select = $this->database->select() ->from(array('h'=>'nkk_hund'), array('h.*')) ->where('h.raseid=?', $klubbid) ->where('h.navn LIKE "%"?"%" OR h.hundid LIKE "%"?"%"', $soketekst) ->limit(100, 0) ->order('h.navn ASC'); return $this->database->fetchall($select); Dette eksempelet returnerer alle hunder fra databasen nkk_hund hvor raseid stemmer med $klubbid og navn eller hundid inneholder ordet i $soketekst Tilkobling Zend_Db bruker et databaseobjekt for å koble til en spesifikk database. Vi lagde en egen tilkoblingsklasse som har én funksjon: gettilkobling(). Denne funksjonen tas i bruk for å hente en tilkobling til databasen. Databaseobjektet definerer verdier som adapter, host, brukernavn, passord og databasenavn, og kan brukes til å definere andre særegenheter som trengs ved oppkobling til en database. Adapterverdien definerer hvilken type database som skal kobles opp mot. Siden prosjektet vårt ligger åpent på Google Code måtte vi være forsiktig med å lagre sensitiv databaseinformasjon i en tilgjengelig fil. Tilkoblingsklassen henter derfor disse opplysningene fra en fil som ligger utenfor prosjektet. På den måten vil ikke tilkoblingsinformasjon bli lastet opp til Google Code. Et eksempel på databaseobjekt $db = new Zend_Db_Adapter_Pdo_Mysql(array( 'host' => ' ', 'username' => 'webuser', 'password' => 'xxxxxxxx', 'dbname' => 'test')); 19

94 Produktrapport 7.2 Filopplaster Opplastning av filer til serveren skjer ikke over AMF-protokollen, men over vanlig HTTP. Denne funksjonen brukes til å laste opp bilder av hunder, samt dat-filer som skal inn i databasen. Figur 18. Filstruktur FilopplastController FilopplastController.php mottar filen som blir sendt fra Flex-applikasjonen. Den sjekker om filen er en dat-fil eller et bilde av en hund, og utfører nødvendige operasjoner ImportParserController I denne filen sjekkes det for hvilken type dat-fil som er blitt lastet opp slik at innholdet kan legges inn i riktig databasetabell. FilvaliderController blir brukt til å finne ut hvilken type det er før hver rad blir kjørt gjennom parserklassen, for så å bli lagt inn i databasen ved hjelp av databaseklassene Parser Parser-klassene tar imot én og én rad fra dat-filen, og konverterer innholdet til en liste som kan puttes inn i databasen BildeendringController FilopplastController.php kan også motta bildefiler. Disse filene blir sendt til BildeendringController.php som genererer én stor og én liten versjon av bildet, som så blir navngitt med den aktuelle hunden sin hundid, og lagret. 20

95 Produktrapport 7.3 Årbok I applikasjonen kan man generere årbok for et gitt år, for enten en eller alle hundene i klubben. En årbok inneholder hunder som har avkom som har hatt jaktprøve i det angitte året. Hunden listes opp med informasjon om seg selv, der avkom grupperes i kull. Det vises jaktprøvestatistikk for hver hund i hvert kull. Aarbok.php mottar forespørselen gjennom vanlig HTTP, og returnerer verdien den får fra AarbokController.php som den utgir for å være en doc-fil. Figur 19. Filstruktur AarbokController AarbokController.php sin lag_rtf()-funksjon genererer teksten som blir til årboken brukeren mottar. Først henter den alle hundene ut fra de gitte kriteriene, for så å hente alle kullene med avkom for hver av hundene. lag_rtf() bruker maler som ligger i no/airdog/assets til å generere den gyldige doc-filen som til slutt blir returnert til brukeren. Diagrammet viser hvordan systemet bygger opp årboken. Først hentes listen med hunder, som igjen henter kulloversikten og kullisten med avkom. For hvert avkom i kullisten blir så jaktprøvene for det aktuelle året hentet fra databasen. Figur 20. Årbokstruktur 7.4 Verktøy Verktøy-klassen er en hjelpeklasse. Den inneholder funksjoner som datokonvertering, logging og årboken sin RTF-sammenfletter. Alle funksjoner som kan gjenbrukes, men ikke har noen bestemt tilhørlighet, legges i denne klassen. 21

96 Produktrapport 8 Databasestruktur Databasestrukturen består av to hovedgrupper, AirDog-tabellene som er for applikasjonen, og dattabellene som representerer informasjonen som kommer fra NKK sine dat-filer. AirDog-tabellene inneholder applikasjonen sin informasjon om hvilke klubber, brukere, roller og rettigheter som finnes. En bruker kan som vist være medlem av flere klubber, og også kunne ha flere roller i den samme klubben. Ved innlogging settes alle rettigheter sammen slik at en bruker med flere roller får alle rettighetene fra de forskjellige rollene i klubben. I tillegg inneholder AirDog-tabellene en datreferanse-tabell. Denne tabellen brukes som problematisk import og er nevnt i avsnittet Struktur og kildekode på serversiden, samt i prosessrapporten under Import av data fra NKK. Dat-tabellene er én til én i forhold til de originale dat-filene fra NKK. Dette er gjort for å sikre best mulig kompatibilitet, samt unngå normaliseringer som senere vil kunne gjøre tabellene ubrukelige i forhold til nye formater på NKK sine dat-filer. For ER-diagram av databasen, se Figur 21 på neste side. 22

97 Produktrapport Figur 21. ER-diagram av databasen 23

98 Produktrapport 9 Adgangs- og rettighetskontroll Adgangskontrollen benytter seg av Zend_Auth, mens rettighetskontrollen er egenskrevet. Dette kapittelet vil først ta for seg adgangskontroll for så å redegjøre for rettighetskontroll. 9.1 Adgangskontroll Når brukere logger inn i applikasjonen sendes et brukerobjekt fra klient til LoggInnController.php. Dette objektet inneholder brukerens e-post og passord. Disse blir sjekket opp mot innholdet i MySQL-tabellen ad_bruker. public function logginn(amfbruker $bruker) { $autentisering = new Zend_Auth_Adapter_DbTable($this->database); $autentisering ->settablename('ad_bruker') ->setidentitycolumn('epost') ->setcredentialcolumn('passord'); $epost = htmlspecialchars($bruker->epost); $pass = sha1(htmlspecialchars($bruker->passord)); if($epost == ""){ return "FEIL_BRUKERNAVN_PASSORD"; } else { $autentisering->setidentity($epost)->setcredential($pass); } $resultat = $autentisering->authenticate(); Innholdet i $resultat sjekkes så for feilmeldinger med $resultat->getcode() der et nyopprettet brukerobjekt blir sendt tilbake til klienten hvis innloggingen er vellykket. switch ($resultat->getcode()) { /*spesifikke feilmeldinger*/ case Zend_Auth_Result::SUCCESS: $r = $autentisering->getresultrowobject(); $bruker->epost = $r->epost; $bruker->fornavn = $r->fornavn; $bruker->etternavn = $r->etternavn; $bruker->superadmin = $r->superadmin; } break; return $bruker; 24

99 Produktrapport Bruker vil da, i klienten, få opp en liste bestående av tilgjengelige klubber. Rettighetene populeres når brukeren velger klubb. Ved utlogging slettes identiteten til brukeren fra gjeldende instans på server. public function loggut() { Zend_Auth::getInstance()->clearIdentity(); return true; } 9.2 Rettighetskontroll Brukerobjektet på klientsiden inkluderer variabler for hver eneste rettighet. Disse finnes ikke i objektet på serversiden, men genereres når brukeren velger klubb i innloggingsskjermen. Til dette brukes ACLController.php der funksjonaliteten for å hente ut rettigheter ligger i den inkluderte ValiderBruker.php. Når bruker har valgt ønsket klubb, kjøres det en rekke funksjoner. public function settbrukersklubb($raseid, $brukerepost, $brukerpassord) public function hentbrukersroller($brukerepost, $brukerpassord, $klubbid) public function hentbrukersrettigheter($brukerepost, $brukerpassord, $klubbid) Vi skal her se nærmere på hentbrukersrettigheter($brukerepost, $brukerpassord, $klubbid). Denne funksjonen gjør først en sjekk for å se om bruker er superadministrator. I det tilfelle settes alle rettigheter til true og sendes tilbake til klient som et AmfRettigheter-objekt. if(validerbruker::validersuperadmin($this->database, $brukerepost, $brukerpassord)) { $tmp = new AmfRettigheter(); $tmp->lese = true; /*alle de andre rettighetene*/ } return $tmp; 25

100 Produktrapport Hvis bruker ikke er superadministrator, vil hver eneste rettighet sjekkes før de samles i samme type objekt og returneres til klient. if(validerbruker::validerbrukeren($this->database, $brukerepost, $brukerpassord)) { $db = new ACLDatabase(); $rettigheter = $db->hentbrukersrettigheter($brukerepost, $klubbid); $tmp = new AmfRettigheter(); foreach($rettigheter as $r) { if($r['navn'] == "lese") $tmp->lese = true; /*alle de adnre rettighetene*/ } >legginnjaktprove >arrangementer } if($tmp->redigerhund $tmp->importerdatabase $tmp- $tmp->rollerettighethandtering $tmp->klubbrollebrukerhandtering $tmp->administrerebackup $tmp->importerdatabase $tmp- $tmp->lagaarbok) $tmp->administrere = true; return $tmp; Den siste sjekken i koden over setter administrere til true hvis brukeren har rettigheter som gjør at administratormenyen skal vises i klienten. 26

101 Produktrapport 9.3 Databasen Diagrammet under viser relasjonene mellom brukere, roller og klubber. Figur 22. ER-diagram av AirDog-tabellene Roller kan ha fra null til mange rettigheter Brukere kan være registrert i fra null til mange klubber Brukere kan ha fra null til mange roller i hver klubb hun eller han er registrert i Sammen med ad_bruker_klubb_rolle_link er ad_rolle_rettighet_link de sentrale tabellene med tanke på oppslag. Det er disse som blir spurt hver gang systemet trenger å sjekke om en bestemt bruker har en bestemt rettighet eller er medlem i en bestemt klubb. Legg merke til at vi valgte å ikke benytte oss av arv. Dette valget tok vi for å unngå problematikk som kan oppstå når en rolle det arves fra endrer seg. Hver enkelt rolle og dens rettigheter er derfor isolert fra, og upåvirket av, de andre. 27

102 Produktrapport 10 Zend Framework Rammeverket er utviklet av Zend Technologies og ble for første gang annonsert i oktober Den første testutgaven kom i april Kildekoden er fri og gratis og har mange frivillige bidragsytere. I tillegg har Google og IBM også sponset noe av utviklingen. Rammeverket baserer seg på «ved behov»-prinsippet, noe som gjør at brukere kan ta i bruk delene av rammeverket som trengs i applikasjonen brukeren utvikler og forkaste de modulene som ikke er relevante. Tar man i bruk hele rammeverket, vil man merke at det er bygget opp for å følge MVC-arkitekturen (Model, View, Controller). I det enkle så betyr det at en skiller objektdefinisjonene (Model), design og layout i brukergrensesnittet (View) og forretningslogikken (Controller) fra hverandre. I vår applikasjon er følgende moduler brukt: 10.1 Zend_Amf Zend_Amf gir AMF3 (Action Message Format) støtte til Zend rammeverket. AMF3 er kompatibel med Flash Player 9 og oppover. AMF (Action Message Format) er en måte å sende objekter frem og tilbake mellom klienten og serveren på. Å serialisere objektene til en kompakt binær representasjon for så å sende dem gir bedre ytelse og økt sikkerhet i forhold til for eksempel å gjøre de om til XML. AMF-objekter kan overføres med både HTTP- og HTTPS-protokollen. Zend_Amf fungerer som en AMF oversetter slik at serveren kan respondere på prosedyrekallene Adobe Flash Player sender. For å fungere må både server og klient ha definert hvilke objekter som tilsvarer hverandre på begge sider. Dette kalles mapping, og AS3-objektet må inneholde minst det PHP-objektet består av. 28

103 Produktrapport Eksempel ActionScript 3 package no.airdog.model { import mx.collections.arraycollection; [RemoteClass(alias="AmfBruker")] [Bindable] public class Bruker { public var epost:string; public var fornavn:string; public var etternavn:string; public var passord:string; public var innlogget:boolean = false; public var sattklubb:klubb; public var klubber:arraycollection; public var superadmin:boolean; public var roller:arraycollection; public var rettigheter:rettigheter; } } PHP <?php class AmfBruker { public $epost; public $fornavn; public $etternavn; public $passord; public $superadmin; } 10.2 Zend_Auth Denne modulen gir et API for autentisering. Den håndterer kun autentisering og ikke autorisering. Autentisering er å finne ut om en bruker er den han utgir seg for å være, mens autorisering er tilgangskontroll. Dette gjøres ofte ved hjelp av brukernavn og passord. 29

104 Produktrapport 10.3 Zend_Db Zend_Db sitter som et lag mellom databasen og logikken i PHP. Dette gjør at typen database kan byttes ut uten å endre spørringer, da disse er skrevet i Zends eget databasespråk og oversettes, sikres og optimaliseres dynamisk. Zend_Db har støtte for IBM DB2, MySQL, Oracle, MsSQL, PostgreSQL og SQLite. Et eksempel på en konfigurasjon kan være slik: return array( 'webhost' => ' 'database' => array( 'adapter' => 'Mysqli', 'params' => array( 'host' => 'localhost', 'username' => 'test', 'password' => 'air', 'dbname' => 'airdog', 'profiler' => false))); Hvis vi ville byttet til IBM DB2 endrer vi kun 'adapter' => 'Mysqli' til 'adapter' => 'Db2'. Eksempel på standard SQL satt opp mot Zend_Db-syntaks: SQL-spørring SELECT p."product_id", p."product_name", l.* FROM "products" AS p JOIN "line_items" AS l ON p.product_id = l.product_id Zend_Db-spørring $select = $db->select() ->from(array('p' => 'products'), array('product_id', 'product_name')) ->join(array('l' => 'line_items'), 'p.product_id = l.product_id'); 10.4 Zend_Feed Zend_Feed muliggjør rask oversetting av RSS1-, RSS2-, og Atom-feeds til objekter som kan behandles og sendes videre til klienten. I vår applikasjon gjøres hver nyhet om til et egendefinert AMF3-objekt som det kan sendes en array av tilbake til klienten. 30

105 Produktrapport 11 Nyhetsleser Nyhetsleseren er implementert både på server- og klientsiden. Vi vil her gå gjennom koden i begge. Leserene populerer lister med nyhetsobjekter generert fra en klubb sin RSS-feed. ActionScript PHP [RemoteClass(alias="AmfNyhet")] [Bindable] public class Nyhet { public var tittel:string; public var tekst:string; public var dato:string; public var url:string; } class AmfNyhet { public $tittel; public $tekst; public $dato; public $url; } Tabellen viser nyhetsobjektet som blir definert for å hentes inn til klienten (ActionScript) Klientside Vi vil her kun gå gjennom leserens logikk, ikke utseende. Leseren er naturlig nok skrevet i ActionScript og MXML. Den baserer seg på Adobes egne biblioteker for XML og RSS2.0. import com.adobe.utils.xmlutil; import com.adobe.xml.syndication.rss.item20; import com.adobe.xml.syndication.rss.rss20; NyheterView.mxml, som leseren heter, lytter på den satte klubbens RSS og oppdaterer seg selv ved endring. <view:nyheterview rssurl="{components.instance.session.bruker.sattklubb.rss}"/> [Bindable] private var _rssurl:string; public function set rssurl(url:string):void { _rssurl = url; hentnyheter(); } 31

106 Produktrapport Her kjøres funksjonen hentnyheter() som nuller ut nyhetslisten og setter i gang HTTPServicen som henter klubbens RSS direkte fra klubbens side. public function hentnyheter():void { if(_rssurl!= null) { nyhetsliste.removeall(); rssparse.send(); } } HTTPServicen definerer funksjoner som kjøres ved resultat og feiling. <mx:httpservice id="rssparse" url="{_rssurl}" result="rss_handler(event)" fault="rss_fault_handler(event)"/> rss_handler() er en stor funksjon, men vi vil her vise det viktigste. Resten av funksjonen itererer gjennom klubbens nyheter, stripper HTML, lager nyhetsobjekter og legger dem til nyhetslisten. private function rss_handler(event:resultevent):void { var xmlstring:string = event.message.body.tostring(); if(xmlutil.isvalidxml(xmlstring)) { var rss:rss20 = new RSS20; rss.parse(xmlstring); var items:array = rss.items; rss_fault_handler() viser feilen i nyhetslisten. private function rss_fault_handler(event:faultevent):void { var tom:nyhet = new Nyhet; tom.tittel = "Feil"; tom.tekst = "Klubben har en ugyldig RSS"; tom.url = ""; tom.dato = ""; nyhetsliste.additem(tom); } Videre finnes funksjonene riktighoyde() som mottar felter og setter høyden på dem lik innholdet, og lesnyhet() som er koblet opp mot en knapp på hver nyhet som sender bruker til nyhetens URL. 32

107 Produktrapport 11.2 Serverside Logikken her ligger i filene NyhetController.php og NyhetDatabase.php. NyhetDatabase.php har kun én funksjon som benyttes i denne sammenheng, hentrss($klubbid), som returnerer klubbens RSS URL. Dette, og bruken av Zend_Feed, vises under. $nd = new NyhetDatabase(); $rss = $nd->hentrss($klubbid); $ret = array(); if(trim($rss['rss'])!= '') { try { $feed = new Zend_Feed_RSS($rss['rss']); } Bruken av Zend_Feed_RSS gjøres direkte, da vi vet at klubbens feed er RSS. Zend_Feed::import($rss['rss']) fungerer på RSS1.0, RSS2.0 og Atom, men vi opplevde det som merkbart tregere. Videre fanges et eventuelt unntak (exception) på vanlig måte. $feed gåes så gjennom der det lages nyhetsobjekter som populerer en liste som sendes tilbake til klienten. foreach($feed as $nyhet) { $tmp = new AmfNyhet(); $tmp->tittel = $nyhet->title(); if(trim($nyhet->description())!= '') { $tmp->tekst = substr(trim(strip_tags($nyhet->description())), 0, 197).'...'; } else { $tmp->tekst = null; } $tmp->dato = $nyhet->pubdate(); $tmp->url = $nyhet->link(); $ret[] = $tmp; } Denne implementeringen sikrer nyhetsleveranse til klienten uansett om klienten har støtte for å hente RSS direkte eller ikke. 33

108 Produktrapport 12 Feilsøking i Flex Her vil vi gå gjennom metoder vi har benyttet oss av mens vi har brukt Flex som programmeringsplattform. Noen feiltyper oppdages av utviklingsmiljøet, mens andre vil resultere i at Flash Player viser en feilmelding. Alvorlige feil kan føre til at applikasjonen ikke starter opp i det hele tatt, og da uten noen form for melding Feil som oppdages av Flex Builder Syntaksfeil er den enkleste formen for feil. Det er også den typen feil som er lettest for Flex Builder å oppdage. Videre kan også utviklingsmiljøet oppdage forsøk på å bruke udefinerte funksjoner, objekter og liknende. Figuren under viser hvordan Flex Builder viser utvikleren hvor det er slike feil. Figur 23. Flex Builder Vi ser her at det er en rekke indikatorer på at det er en feil i kildekoden: Flex Navigator-fanen viser en rød X på filer som inneholder feil Koderedigeringsvinduet har en større X på linjer med feil Koderedigeringsvinduet har også markert ved rullefeltet, hvor i filen feilen befinner seg Problems-fanen gir detaljert informasjon om feilen SVN-fanen markerer feil på samme måte som Flex Navigator-fanen, men kun for filer som er annerledes enn på serveren 34

109 Produktrapport Alle disse indikatorene gjør det relativt enkelt å finne feil og rette på de i Flex Builder. Flex Builder nekter også å kompilere kildekoden så lenge den finner feil Feilmeldinger i Flash Player Feil knyttet til referanser til usatte verdier (null pointer exception), samt andre feil som kan skje under kjøring, vises med debuggingsinfo direkte i Flash Player. Meldingen viser da en feilkode og spesifiserer hva slags type feil som skjedde. Her vises en feilmelding knyttet til et uhåndtert IOErrorEvent der applikasjonen ikke finner en fil som er spesifisert med ekstern URL inne i kildekoden. Figur 24. Feilmelding i Flash Player De andre tilfellene Flash Player har vist feilmeldinger har vært når det har vært uoverensstemmelser mellom server og klient. Dette står det mer om i kapittelet Feilsøking mellom Flex og PHP Feil som gjør at applikasjonen ikke starter Når Flash-applikasjonen starter opp, kjøres det først en egen kodesnutt som laster resten av applikasjonen. Denne koden genererer lasteskjermen og kjører i en strippet utgave av det miljøet applikasjonen lastes inn i. Feil her vil ikke bli oppdaget av utviklingsmiljøet og vil heller ikke generere noen feilmeldinger fra Flash Player. 35

110 Produktrapport Figur 25. Laster.as inneholder mange kommentarer for å prøve å unngå kodefeil Lasteren følger standarden for den første versjonen av ActionScript slik at den er være kompatible med alle versjonene av Flash. Oppførselen til lasteren minner oss om at ActionScript er et scriptspråk og i utgangspunktet ikke objektorientert, da verdier må deklareres og settes før kan bli brukt. Alle komponenter, inkludert de enkle TextField og TextFormat, må også importeres før de kan bli brukt. Disse, og alle andre feil i lasterkoden, vil ikke resultere i et kræsj, men kun vise blank skjerm i nettleseren. 36

111 Produktrapport 12.4 FlexUnit I tillegg til programmatiske feil, er det også ønskelig å teste for funksjonelle feil. Dette kan gjøres ved å ta i bruk Adobes FlexUnit. Man skriver da egne testklasser for hver klasse i programmet ellers. Man sammenlikner så ønsket resultat opp mot faktisk resultat. FlexUnit vil da si fra om funksjonene gjør det de er ment til å gjøre. Figur 26. Her ser vi resultatet av testing av avkomsobjektet 37

112 Produktrapport 13 Feilsøking i PHP Feilsøking i PHP byr på utfordringer da ingen kompilator viser feilmeldinger og retter syntaks. Derfor vil vi her kort gjøre rede for metoder og hjelpemidler vi benyttet under feilsøking Logging av verdier Vi benyttet oss av en selvlaget loggfunksjon som lagret variabler til fil. På den måten kunne vi se om variablene inneholdt det de skulle Meldinger til klienten Det er ikke alle feil i PHP som sender en feilmelding tilbake til klienten. Slike feil kan være vanskelige å rette da serverdelen bare stopper uten at klienten noen gang får svar. Vi løste dette problemet med å sette inn en kodesnutt i PHP-koden som viste en feilmelding på klientsiden. Ved å flytte snutten rundt i koden, kunne vi lett se hvilke funksjoner som resulterte i at snutten ikke lenger viste noen feilmelding. Figur 27. Feilmelding i applikasjonen For å vise en feilmelding skrives kodesnutten: throw(new Exception('Feilen ligger ikke her', "1")); 13.3 PHPUnit Da PHP er et scriptspråk er det ingen kompilator som gir feilmeldinger ved bygging av koden. Det kan derfor ligge syntaksfeil i kildekoden som ikke kommer til syne før den spesifikke funksjonen blir kjørt. Med PHPUnit kan man lage logiske tester som kjører funksjonene i scriptet. På en slik måte at man få 38

113 Produktrapport en oversikt over hvilken kode som fungerer, og hvilken kode som inneholder feil. Her er et eksempel på en testklasse. Figur 28. Testklasse i PHP I dette tilfellet skal vi teste om klassen FilvaliderController returnerer riktig verdi. Funksjonen assertequals brukes til dette og kan skrives på denne måten: $fv = new FilvaliderController(); $this->assertequals("eier", $fv-> getfiltypefrafil (dirname( FILE ).'/../../../../dummyfiler/eier.dat')); Hvis assertequals returnerer true i dette tilfellet så vil «Console»-vinduet vise at testen er godkjent. Hvis ikke, vil den vise dette: PHPUnit by Sebastian Bergmann. F. Time: 0 seconds There was 1 failure: 1) testgetfiltypefrafil(filvalidercontrollertest) Failed asserting that two strings are equal. expected string <Eier2> difference <?> got string <Eier> /no/airdog/controller/filvalidercontrollertest.php:11 FAILURES! Tests: 2, Assertions: 14, Failures: 1. På denne måten kan en feilsøke i koden på en effektiv måte. 39

114 Produktrapport 14 Feilsøking mellom PHP og Flex Ved feilsøking av hva som blir sendt mellom klient og server er det ikke alltid mulig å bruke de teknikkene som er beskrevet i kapitlene: Feilsøking i PHP og Feilsøking i Flex. Noen ganger må en se på de pakkene som blir sendt mellom klient og server. Vi vil her gjøre rede for en metode som lot oss feilsøke i trafikken som går mellom PHP og Flex Charles Charles er et program som fungerer som en HTTP-proxy. Programmet overvåker trafikk slik at man enkelt kan se hva som blir overført mellom klient og server. Charles har innbygget støtte for å overvåke flere overføringsformater. Flash Player bruker blant annet AMF0 og AMF3. Charles kan også brukes til å sjekke tidsbruk ved overføringer. Noe som var nyttig da vi ville effektivisere applikasjonen. Figur 29. Charles Figur 29 viser en oversikt over hva som blir sendt over AMF når en bruker gjør et hundesøk. 40

115 Produktrapport 15 Kravspesifikasjonen og det endelige produktet Bak kravspesifikasjonen som styringsdokument lå en rekke forventninger til produktet vi leverte. Her vil vi reflektere rundt kravspesifikasjon og det endelige produktet. Mer om kravspesifikasjonen som styringsdokument er omtalt i prosessrapporten Oppfyllelse av krav Alle storyene som ble lagt frem per iterasjon ble fullført. I kapittelet Smidig utviklingsmetodikk nevnes det at user storyes fungerer som funksjonelle krav til systemet. Kravene listes i utgangspunktet opp som en svært optimistisk ønskeliste av en rekke funksjoner. Det var ikke forventet av oppdragsgiver at vi skulle klare å levere alle funksjoner ved prosjektets slutt. Det var opp til oppdragsgiver å prioritere hvilken funksjonalitet de ønsket å ha implementert for å kunne benytte seg av produktet så langt det ble ferdig. Likevel klarte vi å levere langt flere funksjoner enn hva som var regnet med i utgangspunktet. Funksjonelle krav som ikke ble implementert til fordel for prioritert funksjonalitet, blir nærmere omtalt i kapittelet Utvidelsesmuligheter under Estimert funksjonalitet Tilbakemelding fra oppdragsgiver Da vi ikke gikk ut fra en tradisjonell kravspesifikasjon, men fulgte en Scrum-basert smidig utviklingsmetodikk, ville den endelige kravspesifikasjonen i form av user storyer alltid stemme med ferdig produkt. På den andre siden fikk vi gode tilbakemeldinger både på antall gjennomførte user storyer og det ferdige produktet. Hvorvidt kravspesifikasjonen stemmer overrens med produktet kan vurderes etter måten løsningen tilfredstiller kravene til oppdragsgiver. Sitatene som følger kan leses i sin helhet under delkapittelet Ord fra eksterne veiledere: "Noen er såpass fornøyd med løsningen at de ønsker at den skal presenteres slik den er i dag for alle klubbene!" "Ekstra hyggelig var det å se at de ble ferdige med brukerhistorien for Årboka, som før prosjektstart var fryktet å være for omfangsrik til å kunne utføres innenfor tiden." "De overrasket oss [...]" "Det viktigste kravet [...] må også sies å være opprettholdt. Bra!" - Bekk 41

116 Produktrapport 16 Utvidelsesmuligheter Dette kapittelet vil ta for seg tanker rundt hvilke funksjoner som kan utvides, endres eller legges til. Først vil vi redegjøre for endringer av eksisterende funskjonalitet. Videre vil vi presentere user storyene som ligger i prosjektets backlog i Pivotal Tracker. Etter dette vil vi foreslå ny funksjonalitet. Til slutt vil vi ta for oss hvilke andre bruksområder vi mener kan være aktuelle for systemet Endringer i eksisterende funksjonalitet Nyhetsleser Slik det er i dag er nyhetsleseren implementert i to versjoner: en er skrevet i ActionScript på klientsiden, mens den andre er skrevet i PHP på serversiden. Det er gjort slik fordi produksjonsserveren mangler noe for få leseren implementert i PHP til å fungere. Akkurat hva det er vet vi ikke, da vi ikke hadde tilgang til konfigurasjonsfilene eller oppsettet ellers på produksjonsserveren. Vi regner med at det vil, med små endringer i serverens konfigurasjon, være mulig å ta i bruk nyhetsleseren. Denne vil hente nyheter, lage nyhetsobjekter og sende en liste av disse til klientene. Det vil da ikke være nødvendig å implementere en nyhetsleser for hver eneste plattform klienten eventuelt oversettes til. Denne listen kan også caches på serversiden slik at et kall til server ikke nødvendigvis resulterer i henting og parsing av nyheter Caching Under utvikling prioriterte vi sanntidsinformasjon fremfor caching uten å vite endelige spesifikasjoner for produksjonsserver. Vi ser nå at mange av spørringene og utregningene som skjer på serveren er tunge og bruker lengre tid enn optimalt. Det kan opprettes egne tabeller der alle, eller de tyngste, utregningene som foretas blir mellomlagret. Dette kan gjøres slik at utregningene blir kjørt: I perioder med lav trafikk Av administratorer som har rettighet til det Ved innlegging eller endring av informasjon andre steder i databasen Ved første spørring som krever det etter et gitt tidsintervall siden forrige Punktene over kan også kombineres og utvides. Tiden det tar før klient får svar fra server kan bli kraftig redusert som resultat av dette, da det i beste fall kun foretas enkle spørringer uten noen utregninger. 42

117 Produktrapport Estimert funksjonalitet Oppdragsgiver hadde i utgangspunktet flere user storyer, altså funksjonelle krav, enn det som var regnet med å få gjennomført. Likevel ble kravene estimert og lagt i backlog for eventuell senere utvidelse. Vi vil ikke gå nærmere inn på disse enn å liste dem opp her da de ikke er tatt med i kravspesifikasjonen. En bruker skal kunne: Sammenligne to hunders avkomsstatistikker Lage valpeannonse som vises på en oppslagstavle Se rasens utstillingsresultater for et gitt år Avlstallsrapport for alle hunder for å finne gode avlstall HQ-gjennomsnitter for avkom med filter for tisper, hannhunder og minimum antall avkom Skrive SQL-spørringer i applikasjonen og se resultater i en datagrid for å lage personlige rapporter, gitt at spørringene ikke endrer eller henter sensitive data Administrator skal kunne: Redigere person Redigere arrangør Redigere veterinær Redigere kull Oppdatere databasen med nye HQ- og avlsverdier Oppdatere databasen med genotypetall for epilepsi Låse Last opp-knappen under opplasting slik at det ikke er mulig å laste opp to filer samtidig Redigere utstillingsresultat Deploye applikasjonen automatisk til airdog.no ved utvikling slik at den kan testes 43

118 Produktrapport 16.2 Ny funksjonalitet Vi gjør her rede for mulig ny funksjonalitet som er relevant til brukerne av applikasjonen Helse En egen visning for helse kan legges til hundenes profil der man kan se informasjon om vaksiner, operasjoner, sykdommer og andre hendelser som gir inntrykk av hundens helsetilstand. Denne informasjonen ligger tilgjengelig i dat-filene NKK gir fra seg. Det er ikke avklart om dette er konfidensielt eller privilegert informasjon som kun få sentrale medlemmer i klubbene, eller eier, får lov til å benytte seg av Favoritthunder Vi ser for oss at en bruker skal kunne ha en liste med sine egne favoritthunder slik at brukere har rask tilgang til de hundene hun eller han er mest interessert i å følge med på. Dette kan igjen utvides med mappestruktur eller et kategoribasert system med flere lister Andre bruksområder Med få eller enkle modifikasjoner kan AirDog benyttes av helt andre brukergrupper. Eksempler på dette kan være: Idrettslag Hvis et idrettslag ønsker å holde styr på konkurranseresultater kan de registrere personer i systemet og registrere konkurranseresultater i stedet for jaktprøveresultater. Stamtreet kunne bli gjort om til fremvisning av konkurranseresultater, slik at det blir vist deltagere i en cup, semifinaler og finale. Rankinglisten kan også være en sentral rolle i et slikt system Familier Her kan man registrere familiemedlemmer istedenfor hunder. Funksjonene avkom og stamtre kunne da bli tatt i bruk for å få en oversikt over sin egen, og andres, familie. Systemer som dette kan bidra til økt effektivitet når det gjelder slektsforskning. En kan også se for seg at jaktprøver kunne bli brukt som en oversikt over en families oppgaver. Som for eksempel å gå ut med søppel, vaske hus, vaske klær og lignende Konklusjon Vi mener AirDog har stort utvidelsespotensial både når det gjelder ny funksjonalitet og konvertering til liknende bruksområder. AirDog har allerede en rekke planlagte funksjoner som under vår prosjektperiode ble nedprioritert, men er fortsatt aktuelle for sluttbrukerne. I dat-filene fra NKK ligger det fortsatt mer data som kan utnyttes, så AirDog har potensial til å få en rekke nye funksjoner dersom behovet skulle være der. AirDogs oppbygning er løst såpass generisk at det, med enklere modifikasjoner, er mulig å lage nye løsninger til andre formål. Med dette mener vi at vi har laget et solid fundament med stort utvidelsespotensial. 44

119 Brukermanual

120 Brukermanual 2

121 Brukermanual 1 Forord AirDog er en applikasjon for visning av hundeklubbers hunder ved hjelp av data levert av NKK. Applikasjonen lar deg søke etter hunder på navn og id, se informasjon om hunden, og se rapporter for klubben. Applikasjonen er utformet for brukere i alle aldere, og har klare farge- og kontrastvalg. Musepekeren brukes til navigering slik at det kreves minimalt med forkunnskaper om applikasjonen. Applikasjonen benytter seg av mange NKK-spesifikke begreper, og det er anbefalt at man har noe kunnskap til NKK sin terminologi. Manualen tar for seg hvordan man benytter de forskjellige funksjonene i applikasjonen. Noen av funksjonene er forbeholdt brukere med administratorrettigheter. Disse funksjonene er ikke nødvendigvis tilgjengelige for vanlige brukere. Brukere med administratorrettigheter kan i sine klubber velge hvilke funksjoner som er tilgjengelig for vanlige brukere slik at de selv kan skreddersy klubbmedlemmers rettigheter. Applikasjonen visualiserer hundedata levert av NKK for de respektive klubbene. Ut fra informasjonen kan applikasjonen vise informasjon som stamtre, jaktresultater og avkom for en gitt hund. I tillegg kan applikasjonen generere rapporter for de forskjellige klubbene basert på informasjonen i databasen. Det er også mulig å oppdatere databasen med ny informasjon fra NKK direkte i applikasjonen ved å laste opp flate databasefiler som er distribuert av NKK. Applikasjonen har et klokkeikon som musepekeren blir byttet ut med når applikasjonen venter på svar fra den sentrale tjeneren. Dette ikonet er for å signalisere at informasjonen fra tjeneren ikke har kommet tilbake ennå slik at man får en tilbakemelding på hva applikasjonen driver med. 3

122 Brukermanual Innholdsliste 1 Forord... 3 Innholdsliste Generelt Informasjonsbobler Knapper Eksportering til Excel Handlinger Logge inn som gjest Logge inn Logge ut Søk etter hund Endre visningsstørrelse ved søk Endre brukerinformasjon Hundeprofil Se jaktprøver for en hund Se avkom for en hund Se stamtre for en hund Se utstillinger for en hund Se prøvestatistikk for en hund Legg til bilde for en hund Rediger informasjonen for en hund Lag årbok for en hund Lag årbok Årsgjennomsnitt Jaktresultater Fiktivt stamtre

123 Brukermanual 3.12 Cup Administrere brukere Administrere roller Laste opp dat-filer fra NKK Legg inn jaktprøve Sikkerhetskopiering Arrangementer for jaktprøver Endre klubbinformasjon

124 Brukermanual 2 Generelt 2.1 Informasjonsbobler Flere steder I applikasjonen kan man se informasjonsbobler, disse er ment for å gi en kort introduksjon til funksjonene tilgjengelig i visningen. Noen ganger står også det blå ikonet alene uten noen medfølgende tekst, man kan da holde musepekeren over ikonet for å se den medfølgende teksten. Figur 1. Informasjonsboble 2.2 Knapper Knapper har sitt særpreg gjennom hele applikasjonen ved at alle har ikoner og tekst. Definert bakgrunn vises når musepekeren holdes over for å indikere at de er klikkbare. Figur 2. Knapper 2.3 Eksportering til Excel Mange av tabellene i applikasjonen kan eksporteres som Excel-regneark. Tabellene som støtter dette har en knapp med ett Excel-ikon og teksten Eksporter oppe til høyre for tabellen. Figur 3. Eksporter-knapp 6

125 Brukermanual 3 Handlinger Applikasjonen inneholder handlinger som lar brukeren hente informasjon fra den sentrale tjeneren. Handlingene benytter seg av rettigheter slik at forskjellige instruksjoner er tilgjengelig for forskjellige personer i applikasjonen. Vi vil her redegjøre for de handlingene tilgjengelig i applikasjonen. Figur 4. Visningsdiagram viser en oversikt over alle visningene i applikasjonen. Visningene er navngitt etter handlingene som er tilgjengelige gjennom via toppmenyen. Figur 4. Visningsdiagram 7

126 Brukermanual 3.1 Logge inn som gjest Noen hundeklubber kan ha gitt gjestebrukeren tilgang til sine sider. Ved å trykke på knappen Gjest ved innlogging logger applikasjonen brukeren inn som gjest og en liste med gjestebrukeren sine klubber dukker opp. Velg deretter den klubben du ønsker å gå inn på. 3.2 Logge inn Skriv inn ditt brukernavn og passord i innloggingsfeltet på applikasjonen, trykk så på Logg innknappen som vises i innloggingsfeltet. Ved gyldig innlogging vises en liste over klubbene man har tilgang til. Figur 5. Innlogging 3.3 Logge ut For å logge ut trykker man på Logg ut-knappen oppe i høyre hjørnet. Applikasjonen viser innloggingsskjermen og ingen informasjon om brukeren vil lenger være tilgjengelig. 8

127 Brukermanual 3.4 Søk etter hund Oppe i høyre hjørnet av applikasjonen finner man tekstfeltet for søk. Her fyller man inn navn eller identifikasjonsnummer, eller deler av disse, på hunden man ønsker å finne, og klikker så på forstørrelsesglasset til høyre i tekstfeltet for å utføre søket. Figur 6. Søkefelt Søkeresultatet dukker så opp med de hundene som stemte med søkekriteriet. Her kan man klikke på den hunden man søkte etter for å komme inn på hundeprofilen og se informasjon om hunden Figur 7. Søkeresultat, detaljert visning 3.5 Endre visningsstørrelse ved søk Når man søker etter en hund kan man velge Detaljert eller Kompakt visning. Standardvisning er den detaljerte visningen hvor også bildet av hunden er synlig. Den kompakte visningen er 1/3 av standardhøyden og viser ikke hunden sitt bilde. Figur 8. Søkeresultat, kompakt visning 9

128 Brukermanual 3.6 Endre brukerinformasjon For å endre brukerinformasjon klikker man på Min profil knappen oppe i høyre hjørnet. Her kan man endre e-post, fornavn og etternavn. Av sikkerhetsmessige hensyn vises ikke passordet i passordfeltet. Hvis man trykker Lagre uten å fylle inn noe i passordfeltene vil ikke passordet endres. Ønsker man derimot å endre passordet skriver man inn det nye passordet i både Passord- og Bekreft passord-feltene. Figur 9. Rediger bruker 3.7 Hundeprofil Etter å ha søkt etter en hund kan man klikke på ønsket hund, for å vise profilen dens. Her kan man se informasjon og statistikk om hunden, basert på informasjon fra databasen. Figur 10. Hundeprofilens hovedside 10

129 Brukermanual Se jaktprøver for en hund For å se jaktprøver for en hund må man først klikk seg inn på profilen til hunden. Deretter dukker det opp en ekstra menylinje for hunden øverst i applikasjonen. Klikk så på Jaktprøver-knappen for å vise hundens jaktprøver. Nederst i vinduet vises en summering av alle jaktprøvene for den valgte hunden. Figur 11. Jaktprøver 11

130 Brukermanual Se avkom for en hund For å se avkom for en hund må man først klikk seg inn på profilen til hunden. Deretter dukker det opp en ekstra menylinje for hunden øverst i applikasjonen. Klikk så på Avkom-knappen for å vise hundens avkom. En hund kan ha flere avkom med forskjellige partnere i forskjellige kull. Avkomlisten for en hund grupperer avkommene ut fra kull slik at man får en god oversikt på hvilke avkom som er fra samme kull. Figur 12. Kull 12

131 Brukermanual Se stamtre for en hund For å se stamtre for en hund må man først klikke seg inn på hundeprofilen til hunden. Deretter dukker det opp en ekstra menylinje for hunden øverst i applikasjonen. Klikk så på Stamtre-knappen for å vise hundens stamtre. Stamtreet viser hanner med blå bakgrunn og hunner med rosa bakgrunn. Listen viser opptil 3 generasjoner bakover i tid. Her kan man også trykke på en hund for å navigere til hundeprofilen for den valgte hunden. Figur 13. Stamtre Se utstillinger for en hund For å se utstillinger for en hund må man først klikk seg inn på hundeprofilen til hunden. Deretter dukker det opp en ekstra menylinje for hunden øverst i applikasjonen. Klikk så på Utstilling-knappen for å vise hundens utstillinger. Figur 14. Utstillinger 13

132 Brukermanual Se prøvestatistikk for en hund For å se prøvestatistikk for en hund må man først klikke seg inn på hundeprofilen til hunden. Deretter dukker det opp en ekstra menylinje for hunden øverst i applikasjonen. Klikk så på Prøvestatistikkknappen for å vise hunden sin prøvestatistikk. Prøvestatistikk er summerte jaktprøveresultater gruppert på de forskjellige klassene UK, DERBY, AK og VK. Figur 15. Prøvestatistikk Legg til bilde for en hund Hver hund kan ha et eget bilde i applikasjonen som vises som miniatyr i søkeresultatet og inne på hundeprofilen. For å endre dette bildet klikker man seg først inn på profilen til den valgte hunden, for så å klikke på Legg til bilde-knappen. NB: Denne funksjonen krever rettigheten redigerhund. Figur 16. Hundeprofilens hovedside 14

133 Brukermanual Rediger informasjonen for en hund For å redigere informasjonen til en hund må man først klikk seg inn på hundeprofilen til hunden. Deretter klikker man på Rediger hund-knappen slik at dialogen med data om hunden dukker opp. De grå feltene i dialogen er informasjonsfelter generert av angitt informasjon og kan ikke redigeres. NB: Denne funksjonen krever rettigheten redigerhund. Figur 17. Hunderedigering 15

134 Brukermanual Lag årbok for en hund Årbok for en gitt hund er lik årboken for klubben, bortsett fra at i denne årboken listes kun kull fra den valgte hunden. For å generere årboken for en gitt hund går man inn på hundeprofilen til den valgte hunden og trykker på Lag årbok-knappen. Se Lag årbok under, for mer informasjon. NB: Denne funksjonen krever rettigheten lagaarbok. Figur 18. Hundeprofilens hovedside 3.8 Lag årbok Applikasjonen kan generere en klubbårbok for et gitt år. Denne årboken viser alle hunder som har avkom som har hatt jaktprøver det angitte året. Avkom listes i kull med informasjon om partneren og når de ble født. I tillegg listes alle jaktprøvene for det aktuelle året for hver enkel t avkom sammen med totalt antall jaktprøver. For å lage en årbok klikker man på Admin for så å klikke på Årbok-knappen. NB Denne funksjonen krever rettigheten lagaarbok. Denne funksjonen kan ta over 20 minutter å utføre, da en full årbok ofte er på over 500 sider. Figur 19. Årbok 16

135 Brukermanual 3.9 Årsgjennomsnitt For å lage en liste med årsgjennomsnitter for en klubb klikker man på Rapporter og klikker på Årsgjennomsnitt-knappen. Her skriver man inn et årstall og eventuelt navnet på en hund. Ved å klikke Søk vil applikasjonen hente alle hunder som stemmer med de angitte kriteriene. Figur 20. Årsgjennomsnitt 3.10 Jaktresultater Jaktresultater lister opp totalt antall jaktresultater i klubben for et gitt år. For å vise jaktresultater klikker man på Rapporter og klikker på Jaktresultater-knappen. Tabellen viser antall plasseringer i de forskjellige klassene for et gitt år. I tillegg vises en jaktprøvesummering for hele klubben for det angitte året, øverst i visningen. Figur 21. Jaktresultater 17

136 Brukermanual 3.11 Fiktivt stamtre Man kan generere et fiktivt stamtre mellom to hunder for å se hvordan stamtreet til et mulig avkom vil bli. For å lage et fiktivt stamtre klikker man på Rapporter og klikker på Fiktivt stamtre-knappen. Så fyller man ut far og mor sine ID-er og hvor mange generasjoner bakover man ønsker å se. Figur 22. Fiktivt Stamtre 18

137 Brukermanual 3.12 Cup Cuplisten genererer en rangering over de beste hundene i klubben for den angitte tidsperioden. For å vise cuplisten klikker man på rapporter og velger Cup-knappen. Så velger man hvilken tidsperiode man ønker å hente prøver fra, og klikker så på Hent liste. Hver hund i cuplisten har knappen Plasseringer. Klikker man på denne knappen vises alle jaktprøver hunden har vært med på i løpet av den angitte tidsperioden. Figur 23. Cup 3.13 Administrere brukere Under Admin-menyen kan man administrere brukere som er lagt til. Her kan man legge til nye brukere, og legge til og fjerne en bruker fra roller. Legg til bruker For å legge til en ny bruker klikker man på Legg til bruker-knappen oppe til høyre på visningen. Så skriver man inn informasjonen om brukeren i dialogen og trykker på Lagre. Figur 24. Brukerredigering 19

138 Brukermanual Legg til bruker i rolle For å legge til en bruker i en rolle drar man brukeren med musepekeren fra listen på høyre side over i rollen på venstre side. Brukeren blir da lagt til i rollen. Figur 25. Dra og slipp Fjern bruker fra rolle For å fjerne en bruker fra en rolle drar man brukeren med musepekeren fra den valgte rollen og over til brukerlisten på høyre side. Brukeren blir da fjernet fra rollen. NB: Denne funksjonen krever rettigheten klubbrollebrukerhandtering. Figur 26. Brukerhåndtering 20

139 Brukermanual 3.14 Administrere roller En klubb kan ha flere roller slik at man enkelt kan definere et sett med rettigheter som flere brukere kan ha. Rollen Gjest kan for eksempel ha rettigheten lese slik at alle brukere som har rollen Gjest i klubben kan utføre de vanligste handlingene i applikasjonen som å søke eller se på hunder. Lage en ny rolle For å lage en ny rolle skriver man inn navn på rollen og beskrivelse opp til venstre og trykker Legg til. Fjerne en rolle For å fjerne en rolle klikker man på knappen under rollen med samme navn. For eksempel vil rollen Admin sin knapp hete Slett rollen Admin. Legge til en rettighet i en rolle For å legge til en rettighet i en rolle drar man rettigheten fra listen på høyre siden over i den valgte rollen. Rettigheten blir da lagt til rollen. Fjerne en rettighet fra en rolle For å fjerne en rettighet fra en rolle drar man rettigheten fra den valgte rollen og over til listen på høyre side. Rettigheten blir da fjernet fra rollen. NB: Denne funksjonen krever rettigheten rollerettighethandtering. Figur 27. Rettighetshåndtering 21

140 Brukermanual 3.15 Laste opp dat-filer fra NKK Applikasjonen støtter å importere dat-filer som leveres av NKK. Disse filene inneholder rådata eksportert fra NKK sin egen database. Ved å klikke på Admin og så klikke på.dat-knappen kan man laste opp filene man har fått fra NKK. Applikasjonen tar imot alle filer av typen dat og finner automatisk ut hvilken database på tjeneren denne filen skal inn i. Hvis innhold i filen allerede finnes i databasen vil nødvendig tilbakemelding bli gitt til brukeren slik at man har oversikt over hvilke handlinger som blir utført. Hvis et innlegg har blitt manuelt redigert i applikasjonen, vil man få spørsmål om man vil overskrive eller beholde den redigerte informasjonen. Velger man å beholde informasjonen, vil ny informasjon fra dat-filer for dette innlegget automatisk bli ignorert slik at det manuelle innlegget har prioritet over NKK sine eksporterte data. NB: Denne funksjonen krever rettigheten importerdatabase. Figur 28. Opplasting av dat-filer 22

141 Brukermanual 3.16 Legg inn jaktprøve For å legge til en jaktprøve klikker man først på Admin for så å klikke på Jaktprøve-knappen. I dialogen fyller man inn feltene og klikker Lagre. NB: Denne funksjonen krever rettigheten legginnjaktprove. Figur 29. Legge inn jaktprøve 23

142 Brukermanual 3.17 Sikkerhetskopiering Applikasjonen støtter å ta sikkerhetskopi av databasen slik at man kan ta vare på informasjonen hvis databasen skulle bli korrupt. Først klikker man på Admin for så å klikke på Backup-knappen. Ta sikkerhetskopi Her kan man skrive inn et eget navn på sikkerhetskopien og klikke Ta sikkerhetskopi, deretter blir det tatt en komplett sikkerhetskopi av databasen som blir navngitt med dagens dato samt navnet som ble angitt i tekstfeltet. Gjenopprette tabeller For å gjenopprette en tidligere sikkerhetskopi velger man den ønskede sikkerhetskopien i listen til høyre, så velger man de tabellene man ønsker å gjenopprette og klikke på Gjenopprett merkede tabeller. NB: Denne funksjonen krever rettigheten administrerebackup. Figur 30. Backup 24

143 Brukermanual 3.18 Arrangementer for jaktprøver Jaktprøvene fra NKK kommer med et prøvenummer, dette nummeret er identifikasjonsnummeret til et arrangement som har vært. Ved å klikke på Admin og klikke på Arrangement-knappen kan man legge til en beskrivelse for et prøvenummer. For eksempel kan dette gjøre at man ser Asker NM istedenfor jaktprøvenummeret NB: Denne funksjonen krever rettigheten arrangementer. Figur 31. Arrangement 3.19 Endre klubbinformasjon Ved å klikke på navnet til klubben oppe i høyre hjørne av applikasjonen dukker det opp en dialog som lar deg redigere klubben sin informasjon. RSS-feltet er adressen til klubbens RSS-feed. Forsidetekstfeltet innholder teksten som vises på applikasjonens hovedside. Feltet støtter grunnleggende HTML. NB: Denne funksjonen krever rettigheten redigerklubb. Figur 32. Rediger klubb 25

144 Brukermanual 26

145 Kravspesifikasjon

146 Kravspesifikasjon 2

147 Kravspesifikasjon 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til systemet som skal lages. Videre har kravspesifikasjonen definert prosjektets rammer og krav til brukervennlighet, kvalitetssikring og sikring av data. Utviklingsprosessen foregår etter smidig utviklingsmetodikk. Å jobbe smidig vil si å levere produktet fortløpende i delleveranser slik at deler av funksjonaliteten blir implementert og kan tas i bruk av kunden. Kravspesifikasjonen er basert på de funksjonelle og praktiske krav som er kom underveis i prosjektets iterasjoner. Kravene ble gitt som user storyer fra oppdragsgiver. Mer om utviklingsprosessen med bruk av user storyer er omtalt i prosessrapporten. Listen av user storyer fungerer som en ønskebrønn med ulik funksjonalitet som systemet kunne hatt. Listen med user storyer er i utgangspunktet lengre enn hva kunden forventer å få, så det er opp til kunden å prioritere hva som skal implementeres. Kravspesifikasjonen har under prosjektperioden fungert som et styringsdokument som har endret seg fortløpende. Da vi har oppdatert kravspesifikasjonen når vi har fått nye oppgaver har aldri kravspesifikasjonen vært fullstendig fra prosjektets start, men bevisst bekreftet endringer underveis. 1.1 Leserveiledning Som nevnt er det blitt jobbet etter en smidig utviklingsmetodikk der kravene er listet opp som user storyer gitt fra oppdragsgiver. Disse storyene er blitt overført til kravspesifikasjonen slik at den står som styringsdokumentet til prosjektet. 3

148 Kravspesifikasjon 2 Innhold 1 Forord Leserveiledning Innhold Innledning... 6 Gruppen... 6 Oppdragsgiver og kunde... 6 Bakgrunn for oppgaven... 7 Mål for oppgaven Funksjonelle krav for systemet En bruker skal kunne En administrator skal kunne En superbruker skal kunne Dat-filene sin struktur Eier Fugl Hdsykdom Hund Kull Oppdrett Person Premie Utstilling Veteriner Aasykdom Rammekrav i systemet Kunden Sikring av tap, ødeleggelse, tyveri og misbruk av data Kompatibilitet Krav til design og brukervennlighet Krav til kode og vedlikehold Fremtidig utvidelse av systemet Andre krav

149 Kravspesifikasjon 7.1 Lave driftskostnader og bruk av åpen kildekode Adobe Flex Pivotal Tracker Google Code

150 Kravspesifikasjon 3 Innledning Denne innledningen inneholder bakgrunnsinformasjon for prosjektet og finnes i både prosess- og produktdokumentasjon. Her presenterer vi først gruppen, oppdragsgiver og kunde. Videre går vi mer i detalj om bakgrunnen for, og målet med, oppgaven. 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å. 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. 6

151 Kravspesifikasjon 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. 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. 7

152 Kravspesifikasjon 4 Funksjonelle krav for systemet 4.1 En bruker skal kunne o logge seg inn for å få personlige innstillinger for applikasjonen o o o o o o o o o o o o o o o o o o o autentiseres med roller for å kunne få tilgang til hundedata søke etter hund for å kunne velge å se hundens profil se en hund sin profil slik at man kan se hundens data og resultater se avkom for en hund gitt at hunden har avkom se jaktprøver og oppsummering for en hund slik at man kan lese resultater se stamtavlen til en valgt hund se en liste over hunder slik at man kan finne en hund se avlstall for alle hunder slik at man kan finne hunder med gode avlstall se årsgjennomsnitter for en rase eller en hund for ett gitt år se alle utstillingsresultater for en hund se siste resultater for cup der hunder rangeres etter poeng fra sine jaktprøver se hele rasens jaktprøveresultater for et gitt år se prøvestatistikk på en stamgren for en hund eksportere alle rapporter (lister med data i systemet) til Excel-format velge to hunder og se den fiktive stamtavlen de utgjør bruke historikk ved å navigere frem- og tilbakeknappene til nettleseren markere og kopiere hundens ID i søkeresultatet redigere egen e-post (brukernavn), passord og navn lese nyheter importert fra klubbenes egne sider via RSS. 4.2 En administrator skal kunne o oppdatere databasen med data fra NKK o o o o o o o o legge til midlertidige resultater inntil neste import av data fra NKK håndtere problematisk import av data slik at redigerte data i systemet ikke overskrives av feil data fra NKK redigere data for en hund slik at man kan rette på data som er feil legge inn bilde av en hund på hundens profil redigere data for en jaktprøve slik at man kan rette på data som er feil kjenne igjen jaktprøveskjema slik det ser ut i virkeligheten administrere roller og rettigheter i et oversiktlig grensesnitt ta sikkerhetskopi av databasen slik at bruker- og hundedata ikke går tapt 8

153 Kravspesifikasjon o o o o o o o o o o rulle tilbake en backup dersom noe skulle gå galt legge til en bruker slette en bruker generere Word-dokument i årbokformat for en hund generere Word-dokument i årbokformat for alle hanner for et gitt år generere Word-dokument i årbokformat for alle tisper for et gitt år redigere roller tilordnet brukere i et oversiktlig grensesnitt redigere informasjon om aktuell klubb legge til en litterær jaktprøvekritikk til jaktprøvene i tillegg til standardverdiene fra jaktprøveskjemaet fylle inn sted og navn på arrangementer i en tabell der de i utgangspunktet bare har en ID slik at arrangementer blir lettere å kjenne igjen 4.3 En superbruker skal kunne o ha tilgang til all funksjonalitet i alle klubber i systemet 9

154 Kravspesifikasjon 5 Dat-filene sin struktur Dat-filene fra NKK har ingen direkte kobling til hverandre slik en normalisert relasjonsdatabase har. Likevel er det en logisk sammenheng i filene. Tabellene skal gjenskape dat-filenes struktur. Her vises første linje i hver dat-fil: 5.1 Eier EIER HUID RAID 5.2 Fugl ProeveNr ProveDato PartiNr Klasse PEID_Domm1 PEID_Domm2 HUID SlippTid EgneStand EgneS toekk TomStand MakkerStand MakkerStoekk JaktLyst Fart Stil Selvstendighet Bredde Reviering Samarbeid Pres_Upresis Pres_NoeUpresis Pres_Presis Reis_Nekter Reis_Noelende Reis_Villig Reis _Djerv Sek_Stjeler Sek_Spontan App_IkkeGodkj App_Godkj Rapp_Innkalt Rapp_Spont Premiegra d CERTIFIKAT RegAv RegDato RAID 5.3 Hdsykdom AvlestAv Betaling Diagnose DiagnoseKode EndretAv HDID HUID IdMerket IdMerkerKode Kode L idelse LidelseKode PEID RAID RegAv SekHoyre SekHoyreKode SekVenstre SekVenstreKode Send es VEID RontgenDato AvlestDato 5.4 Hund RAID KUID HUID Tittel Navn HUIDFar HUIDMor IDNR FargeBeskrivelse FargeVariant AD HD Ha arlag IDMerk Kjoenn PEID EndretAv EndretDato RegDato Stoerrelse 5.5 Kull KUID HUIDFar HUIDMor PEIDOppdretter EndretDato Foedt RAID 5.6 Oppdrett KUID Oppdretter RAID 5.7 Person PEID Navn Adresse1 Adresse2 Adresse3 Postnr Landkode RAID Status Telefon1 EndretDato Reg Dato Foedt 5.8 Premie DOID UTID HUID Katalognr PEIDdommer Klasse Kjonn RAID IM KIP JK JKK UK UKK BK BKK AK AKK VK CHK CHKK VTK VTKK HP CK CC CA BIK BIR BIM 5.9 Utstilling UTID KLID PEID RegDato RegAv Navn Adresse1 Adresse2 Postnr SpesialAdresse UtstillingDato U tstillingsted ArrangoerNavn1 ArrangoerNavn2 OverfoertDato 5.10 Veteriner VEID PEID Adresse1 Adresse2 Adresse3 Postnr Telefon Telefax KlinikkNavn RegDato RegAv End retav 10

155 Kravspesifikasjon 5.11 Aasykdom VEID AAID DiagnoseKode IdMerkerKode LidelseKode SekHoyreKode SekVenstreKode EndretAv R egav AvlestAv Betaling Diagnose HUID IdFeil IdMerket Kode Lidelse PEID Purring RAID Retur S ekhoyre SekVenstre Sendes AvlestDato RontgenDato 11

156 Kravspesifikasjon 6 Rammekrav i systemet Vi vil her gjøre rede for oppgavens begrensninger i forhold til omfang og bruksområde. Vi tar for oss krav om sikring av data, kompatibilitet, brukervennlighet, kodestruktur og tilrettelegging for vedlikehold. 6.1 Kunden I første omgang vil dette være fuglehundklubbene Norsk Pointerklub (NPK) og Norsk Breton Klubb (NBK). Disse klubbene forholder seg til oppdragsgiver slik at kommunikasjonskanalen alltid går gjennom Bekk. Løsningen skal legges opp generisk slik at flere klubber også kan ta i bruk AirDog. 6.2 Sikring av tap, ødeleggelse, tyveri og misbruk av data Da NKK sine data har spesielle rettigheter og inneholder sensitive persondata, er det nødvendig å sette krav til sikkerhet Håndtering av passord Passord må håndteres på en slik måte at de ikke kan misbrukes. Ved innlogging og forespørsler skal ikke passord sendes i klartekst. Passord skal hashes i databasen slik at ikke de kan leses av andre Rettigheter og roller Brukere skal tildeles roller. Roller har ulike rettigheter som sikrer at kun de med gitte roller kan få tilgang til restriktive deler i systemet. En administrator har en brukerrolle og en administratorrolle der administratorrollen gir fler rettigheter. Hvis brukeren ikke har rettighetene som kreves blir han enten nektet tilgang ved å gi en beskjed eller bare skjule den funksjonaliteten som brukeren ikke har tilgang til. Rettighetene kan dere strø rundt om i applikasjonen og derpå spørre innlogget bruker om han har de rettighetene. Ala user.harrettighet(kan_se_personer) - Ole Christian Langfjæran, Bekk Systemet skal ha rollene: Superbruker som har tilgang til alle funksjoner og hundeklubber. Administrator som har tilgang til alle funksjoner innenfor den klubben han er medlem i. Disse er definert nærmere under krav til administratorrollen. Bruker har brukerrettigheter som er de krav beskrevet for brukersystemet. Gjest vil være en begrenset brukeropplevelse med lite eller ingen tilgang til hund- og persondata Sikkhertskopiering Det skal være mulig å ta sikkerhetskopier av databasen i applikasjonen slik at bruker- og hundedata ikke går tapt. 12

157 Kravspesifikasjon 6.3 Kompatibilitet Applikasjonen skal kunne kjøres på dagens mest brukte operativsystemene: Windows, Mac OS X og Linux. 6.4 Krav til design og brukervennlighet Brukervennlighet Systemet skal kunne brukes av personer med lite eller ingen opplæring. Med det menes at systemet skal være selvforklarende så langt det er mulig forutsatt at brukerne har grunnleggende kjennskaper til de begreper og fagtermer relatert til fuglehunder Brukertester Systemet skal testes av reelle brukere i klubbene underveis i utviklingen Frem- og tilbakeknapp For mindre forvirring skal det være mulig å navigere frem og tilbake med knappene i nettleseren. På denne måten blir det ikke frem og tilbakeknapp i applikasjonen i tillegg til i nettleseren. 6.5 Krav til kode og vedlikehold Deploye til airdog.no Prosjektgruppen skal kunne deploye applikasjonen til airdog.no slik at den kan testes. Under utviklingen skal det jevnlig legges ut delleveranser av systemet på prosjektets produksjonsserver airdog.no. Kunden skal kunne teste ut og tidlig vurdere brukeropplevelsen til applikasjonen Remote object Prosjektet skal benytte PHP som serverdel for Flex som klient. Systemet skal kunne sende objekter mellom klient og server for å unngå å sende ren tekst. Dette skal sikre systemet mot oppsnapping, fabrikkering og modifisering av datastrømmen samt å optimalisere ytelsen til systemet Designmønstre Systemet skal kunne være skalerbart og enkelt å vedlikeholde. Det skal være mulig for en annen utvikler å kunne sette seg inn i kildekoden uten å måtte bruke store ressurser på å finne ut hvordan systemet fungerer. For å støtte opp til kravet ovenfor skal kildekodens struktur baseres på kjente og fleksible designmønstre som gjør applikasjonen skalerbar og samtidig oversiktlig. Systemets designmønster skal følge Model View Controller Service prinsippet ved å skille presentasjon og datamodell og støtte opp applikasjonen ved hjelp av kontrollere og servertjenester. Det vil da være mulig å bytte ulike komponenter uten å måtte endre store deler av systemet. 13 Figur 4. Overordnet arkitektur

158 Kravspesifikasjon 6.6 Fremtidig utvidelse av systemet Systemet vil driftes av veilederne fra Bekk. Dette stiller krav til at systemet er strukturert på en oversiktlig måte Oppbygning Det stilles krav til et godt fundament i programmet. Fokus på god arkitektur som er modulær og lett og utvide. Det skal være mulig for en utenforstående for systemet å kunne raskt sette seg inn i arkitekturen og systemets virkemåte. 7 Andre krav Vi lister her opp verktøy og hjelpemidler som skal benyttes i utviklingen av applikasjonen. 7.1 Lave driftskostnader og bruk av åpen kildekode Systemet skal ha lave driftskostnader. Hundeklubbene er ikke interessert i å betale for dyre webhotell for å drifte applikasjonen. Det må være med i vurderingen om hvilken web-teknologi som skal benyttes i løsningen. Det skal vurderes alternativer som er åpne og gratis. 7.2 Adobe Flex Bekk er interessert i å få laget applikasjonen med Adobe Flex teknologi. Adobe Flex er en Flash-basert teknologi som lager Flash-baserte web-grensesnitt. I utviklingen skal det benyttes Flex 3, som den nyeste utgaven fra Adobe. 7.3 Pivotal Tracker Pivotal Tracker skal benyttes som planlegging- og styringsverktøy under utviklingsperioden. 7.4 Google Code Systemet skal være åpent og gratis og ligge tilgjengelig på Google Code. Koden skal lastes opp og være tilgjengelig for alle. 14

159 Testrapport

160 Testrapport 2

161 Testrapport 1 Innledning Vi har jobbet i en iterativ utviklingsprosess og hver funksjon i applikasjonen har blitt fortløpende testet før den har blitt godkjent i Pivotal Tracker. Testene i denne rapporten er utført på den endelige versjonen av den Denne rapporten har for hensikt å avdekke eventuelle feil som ikke har blitt oppdaget tidligere, eller feil i allerede godkjente funksjoner som har kommet av endringer i andre funksjoner. Brukertestene er tester som er manuelt utført, mens PHPUnit sammendraget er systematiske tester som ligger i kildekoden. Klient o Intel Core 2 Duo 2.0Ghz prosessor o 2048MB Systemminne o Microsoft Windows 7 o Internet Explorer 8 Server o Fedora Linux o Apache

162 Testrapport 2 Brukertest av systemet Testingen er delt opp i bruker- og administrative funksjoner. 2.1 Brukertester Funksjon Test Kommentar Logge inn som gjest Velg <Gjest> knappen og OK deretter en av klubbene som dukker opp i listen. Trykke <les> på en nyhet Velg <Les> knappen på en OK fra klubben nyhet i klubben sin nyhetsliste. Søke etter en hund med Trykk søk i søkefeltet uten å OK teksten skrive inn noe tekst. Søke etter en hund med Skriv fig i søkeboksen og OK teksten fig trykk søk. Velge Kompakt visning i Trykk - Kompakt -knappen i OK søkeresultatet søkeresultatet. Velge Detaljert visning i Trykk + Detaljert -knappen i OK søkeresultatet søkeresultatet. Velge en hund i listen Velg en hund i søkeresultatet. OK Velge jaktprøver for en Trykk på <Jaktprøver> når man OK hund er inne på en hund. Velge Avkom for en hund Trykk på <Avkom> når man er OK men noe tregt inne på en hund. Velge stamtre for en hund Trykk på <Stamtre> når man er OK inne på en hund. Velge utstilling for en hund Trykk på <Utstilling> når man er OK inne på en hund. Velge prøvestatistikk for en Trykk på <Prøvestatistikk> når OK men noe tregt hund man er inne på en hund. Trykke på en hund i Trykk på en hund i OK stamtrelisten stamtrelisten som dukker opp. Vise årsgjenomsnitter for Trykk på <Årsgjennomsnitter> i OK en hund Rapporter. Vise årsgjennomsnitt for Trykk på <Årsgjennomsnitter> i OK alle hunder i 2008 Rapporter og velg året Vise jaktresultater for 2008 Trykk på <Jaktresultater> i OK Rapporter og velg året 2008 Vise fiktivt stamtre mellom Trykk på <Fiktivt stamtre> i OK 2 hunder Rapporter og skriv inn 2 hundeid-er. Vise cup-resultater for Trykk på <Cup> i Rapporter og OK men noe treg/tung klubben i 2008 velg året Trykke på Hjem knappen Trykk på <Hjem> OK Trykke på Logg Ut Trykk på <Logg ut> OK 4

163 Testrapport 2.2 Administrative tester Funksjon Test Kommentar Logge inn som Logg inn som en gyldig OK administrator administrator og velg en av klubbene Velge <Min profil> og Velg <Min profil> og rediger OK redigere egen informasjon egen informasjon. Velge klubben sin Velg < Klubben sitt navn > og OK informasjon se at informasjonen stemmer. Redigere klubben sin Velg < Klubben sitt navn > og OK informasjon rediger informasjonen. Redigere en hund man er Velg <Rediger hund> når man OK inne på profilsiden til. er inne på en hund. Legg til bilde for en hund Velg <Last opp bilde> når man OK er inne på en hund. Lag årbok for en hund Velger <Lag Årbok> når man er OK men noe treg inne på en hund. Lag årbok for en klubb Velg <Årbok> i OK men treg administrasjonsfeltet. Legge til et arrangement for en jaktprøve Velg <Arrangementer> i administrasjonsmenyen. OK Ta sikkerhetskopi av databasen Gjenopprette sikkerhetskopier Legge til en jaktprøve Velg <Backup> i administrasjonsmenyen og ta en sikkerhetskopi. Velg noen tabeller i en sikkerhetskopi og velg <Gjenopprett>. Velg <Jaktprøve> og skriv inn korrekt informasjon Velg <.DAT> og last opp en.dat fil som kommer fra NKK. Last opp en.dat fil som OK kommer fra NKK Lage en ny rolle Opprett en rolle. OK Legge til rettigheter i den Dra den ønskede rettigheten OK nye rollen. over i den nye rollen. Fjern rettighet fra en rolle Dra den ønskede rettigheten OK over fra rollen og inn i listen med rettigheter. Legge til en ny bruker Velg <Legg til bruker> og skriv OK inn informasjon om den nye brukeren. Gi en bruker en rolle Dra brukere over i en rolle. OK Slett en bruker Velg slett på en bruker i listen med brukere. OK OK OK OK 5

164 Testrapport 3 PHPUnit sammendrag PHPUnit er et rammeverk for testing av kode i PHP. Rammeverket er beskrevet i prosessrapporten under testdrevet utvikling. Her er et sammendrag av alle testene som har blitt implementert med PHPUnit. Klasse Funksjon Kommentar testgeteierarray OK testgeteierlistearray OK EierParserTest testgeteierlistearrayfrafil OK testvalidereierlistefrafil OK testvalidereierliste OK FuglParserTest OK testgetfugllistearray OK FuglParserTest testgetfugllistearrayfrafil OK testvaliderfugllistefrafil OK testvaliderfuglliste OK testgetfugldatabasesomdat OK testgethdsykdomarray OK testgethdsykdomlistearray OK HdsykdomParserTest testgethdsykdomlistearrayfrafil OK testvaliderhdsykdomlistefrafil OK testvaliderhdsykdomliste OK testgethundarray OK testgethundelistearray OK HundParserTest testgethundelistearrayfrafil OK testvaliderhundelistefrafil OK testvaliderhundeliste OK testgethunddatabasesomdat OK testgetkullarray OK testgetkulllistearray OK KullParserTest testgetkulllistearrayfrafil OK testvaliderkulllistefrafil OK testvaliderkullliste OK testgetoppdrettarray OK testgetoppdrettlistearray OK OppdrettParserTest testgetoppdrettlistearrayfrafil OK testvalideroppdrettlistefrafil OK testvalideroppdrettliste OK testgetoyesykdomarray OK testgetoyesykdomlistearray OK OyesykdomParserTest testgetoyesykdomlistearrayfrafil OK testvalideroyesykdomlistefrafil OK testvalideroyesykdomliste OK testgetpersonarray OK PersonParserTest testgetpersonlistearray OK testgetpersonlistearrayfrafil OK testvaliderpersonlistefrafil OK 6

165 Testrapport PremieParserTest UtstillignParserTest VerktoyTest VeterinerParserTest AasykdomParserTest FilvaliderControllerTest testvaliderpersonliste testgetpersondatabasesomdat testgetpremiearray testgetpremielistearray testgetpremielistearrayfrafil testvaliderpremielistefrafil testvaliderpremieliste testgetpremiedatabasesomdat testgetutstillingarray testgetutstillinglistearray testgetutstillinglistearrayfrafil testvaliderutstillinglistefrafil testvaliderutstillingliste testgetutstillingdatabasesomdat testkonverterdattildatabasedato testkonverterdatabasetildatdato testgetveterinerarray testgetveterinerlistearray testgetveterinerlistearrayfrafil testvaliderveterinerlistefrafil testvaliderveterinerliste testgetaasykdomarray testgetaasykdomlistearray testgetaasykdomlistearrayfrafil testvalideraasykdomlistefrafil testvalideraasykdomliste testgetfiltypefrafil testgetfiltypecontroller OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK 4 Konklusjon Testrapporten har gitt oss en god oversikt som viser at alle funksjonene i applikasjonen fungerer som de skal. PHPUnit sine tester gir oss et kjapt og godt resultat, og som er enkelt å utføre ved senere tester. 7

166 Testrapport 8

167 Kilder

168 Kilder 2

169 Kilder AirDog Pivotal Tracker Google Code Hjem - Hovedprosjekt Verktøy Pivotal Tracker Microsoft SharePoint Adobe Flex Zend Framework Subversion Subclipse MySQL PHP.net PHPUnit Smidig utvikling Agile software development Scrum 3

170 Kilder Manifesto for Agile Software Development Agile Alliance The new methodology Uploader Flex 3 - Adobe Flex 3 Help tions_9.html Flex 3 - Adobe Flex 3 Help tions_7.html Flex and PHP File Upload Eksportering til Word og Excel Converting Flex 3 Datagrid to Excel Sheet Creating Word Documents on the fly Can i convert MySQL db records into microsoft word documents Exporting to Excel from DataGrid As3xls s Excel sample Source of DataGridCopy Paul Kukeil s Excel sample 4

171 Kilder MVCS joeberkovitz.com» MVCS Zend Using Zend_Acl with a database backend Zend Framework: Documentation Build a better Login with Adobe Flex, Zend_Amf, Zend_Auth, and Zend_Acl Zend_Acl and storing roles and resources in a DB Free Zend Framework Screencasts PDF Generating PDF Forms From a Flex Application With PHP PHP- Deep Linking Flex 3 - Adobe Flex 3 Help Flex and Deep Linking Programming Flex 3: Chapter 20, Embedding Flex Applications in a Browser er20.html?page=5 DumpSQL PHP backup of a mysql database 5

172 Kilder Dragging Removing items from a Flex DataGrid control using the DragManager class Skinning Yahoo! and Flex: Feel Good In Your Own Skin Adobe Flex, Themes und Skins, Java Enterprise, LiveCycle Data Service Skinning Adobe Adobe Flex 3 Component Explorer Adobe Flex 3 Component Explorer Flex 3 - Adobe Flex 3 Help Flex 3 - Adobe Flex 3 Help Adobe - Flex Developer Center - Learn Flex and PHP The Official Flex Team Blog: Flex and PHP Flex 3 - Adobe Flex 3 Help - Blogger Kevin Hoyt RemoteObject using AMFPHP and Actionscript 3 «Gerton s Corner 6

173 Kilder Advanced Paging and Filtering in Flex Datagrid Mihai CORLAN How to Create a crossdomain.xml file Wade Arnold Inspirasjon AS2 - Dynamic gallery with paging system html DOPE Awards // Flash Website Awards 50 Beautiful And User-Friendly Navigation Menus About Flex Experiments and news around Adobe Flash How to debug Flex/AIR and PHP applications Usability challenges on web-based-communities Account sign-in: 8 big mistakes Making a Rich Web Application usable Adobe Flash Catalyst beskrivelser av feltene til nye jaktprøveskjemaer. 7

174 Kilder AMF SOAP Zend_Amf component proposal Zend_Db_Select documentation Zends PHP-rammeverk lansert i dag Zend Framework Zend Framwork Introduction 8

175 Vedlegg

176

177 Vedlegg Ordliste Ordliste ActiveX - ActiveX-kontroller er små programmer, noen ganger også kalt tillegg, som brukes på internett. Laget av Microsoft og kun kompatibelt med deres programvare. Ikke så kompatibelt med nyere operativsystemer eller nettlesere. Adobe Flex - Adobes SDK for å lage Flash-programmer. Adobe AIR - En operativsystemuavhengig runtime-modul som gir utviklere muligheten til å bruke velkjente webteknologier til å lage avanserte internettprogrammer for utrulling til skrivebordet. ActionScript - Et programmeringsspråk basert på ECMAScript. I begynnelsen var det kun brukt til manipulering av 2D-grafikk i Flash-animasjoner mens det nå i versjon 3, har mulighet til å utgjøre logikkdelen i moderne webapplikasjoner. Apache - Kort for Apache HTTP Server. Fri, gratis og A-en i LAMP-systemet. Backlog - En liste med oppgaver som er satt til side. C#.NET - Programmeringsspråket C# i rammeverket.net av Microsoft. Coda - En utviklingsmiljø for Mac OS X. CruiseControl - Et program for å utføre automatisert testing av kildekode. Flash - Refererer til programvaren Adobe Flash Player, og Adobe Flash Professional, som utvikles og distribueres av Adobe Systems. Adobe Flash Professional blir brukt for å lage innhold som kan spilles av på nettlesere som har Flash Player installert. Flash støtter vektor- og pikselgrafikk og har også et eget scriptspråk: ActionScript. Fri - Kildekoden er åpen og fritt tilgjengelig. GUI - Graphical User Interface. Grafisk brukergrensesnitt. Handoff-programmering - Å gi videre kode til en annen utvikler som kan programmere videre. Dette er nyttig når for eksempel en utvikler står fast i et problem og har sett seg blind på koden. Hashing - Å generere en numerisk kode for en tekststreng. Lages ved hjelp av en algoritme som gjør det svært usansynlig at to forskjellige tekststrenger vil få den samme hash-verdien. Hash-verdier av samme type vil alltid ha samme lengde. I praksis kan dette være nyttig for å aksessere oppføringer i en tabell hurtig eller for enveis-kryptering. Sistnevnte kan brukes for å lagre passord på en sikker måte, og å kontrollere at en datafil ikke har blitt tuklet med. HCI - Human Computer Interaction. På norsk: MMI (Menneske Maskin Interaksjon). Fagfelt som omhandler interaksjonen mellom mennesker og (data)maskiner. IDE - Integrated Development Environment. På norsk: utviklingsmiljø. Omfattende programvare som fungerer som programmereres hovedverktøy under utvikling.

178 Vedlegg Ordliste LAMP - Linux, Apache, MySQL, PHP/Perl/Python. Et vanlig oppsett for å få en fungerende webserver. Maven - Automatisert bygging av kildekode MSSQL - SQL-språk utviklet av Microsoft. MVCS - Model, View, Controller, Service. Viser til fil- og kildekodestrukturen i programmer. MXML - Språk introdusert av Macromedia. Brukes til å legge ut brukergrensesnittelementer i Flex. MySQL - Fritt og gratis SQL-basert databasesystem som er lisensiert under GPL. Denne databasetjeneren er veldig mye brukt, og er M-en i LAMP-systemet..NET - Microsofts rammeverk for utvikling av web-, skrivebord- og mobilapplikasjoner. Parse - Å oversette data fra et format til et annet. PHP - Et scriptspråk som kjøres på serversiden. Ofte P-en i LAMP-systemet. phpbb - Et åpent og gratis forumplattform utviklet i PHP. Pivotal Tracker - En webløsning som håndterer user storyer i forbindelse med smidig utvikling. Remote object - Konsept som gjør det mulig å, fra klient, gjøre kall til funksjoner på server. Scrum - en utviklingsmetodikk som i hovedsak brukes innenfor programvareutvikling. Scrum kan integreres med alle iterative og inkrementelle systemutviklingsmetoder. SDK - Software Development Kit SGML - Standard Generalized Markup Language. Metaspråk som er en ISO-standard (8879:1986). Gir abstrakt syntaks som kan implementeres som konkret syntaks i andre språk. SQL - Structured Query Language. Databasespråk som brukes til å hente ut, slette, legge til eller oppdatere data fra en server. Visual Studio - Microsofts egen IDE for utvikling. XML - Extensible Markup Language. Et universelt og utvidbart merkespråk og en forenklet videreføring av SGML. Brukes til deling av strukturerte data mellom informasjonssystemer, særlig over internett. Zend Framework - Et åpent rammeverk som bygger videre på PHP sin funksjonalitet. WordPress - En bloggplattform utviklet i PHP.

179 Vedlegg Dagbok Dagbok Uredigert arbeidsdokument rett fra prosjektsiden. Kronologisk rekkefølge Prosjektskissen Prosjektskissen er nå lagt ut under Rapporter. Mulighet for endringer eller spesifiseringer etter oppstartmøtet mandag 8. desember Første møte med alle etter juleferie Gjort: Satt opp prosjekt hjemmesiden Satt opp en ubuntu server til maven Prøv første flex tutorial Laget timeliste mal Diskutert hva som skal gjøres denne uken Neste møte: Finne ut om vi kan få grupperom Øve mer på flex Sette opp maven Tirsdag Gjort: Sett mer på eclipse Sjekket litt rundt for å finne et toolbar/rich text editor og fant to alternativer til sharepoint: Ender med å prøve den siste. Nå fungerer toolbar til firefox også Lagt til "Om gruppen" side Onsdag Gjort: Sett på Flex-mojos til Maven Sett mer på Flex

180 Vedlegg Dagbok Sett på Bamboo Signert og levert kontrakt til skolen Fått bekreftet studieveileder Frode Eika Sandnes Mandag Vært i møte hos Bekk og diskutert de første user storiene vi skal gjøre. Gjort: Lagt til prosjektrelaterte lenker slik at de er lettere å nå fra prosjektsiden. Lagt inn Apache2, PHP, MySQL og PHPMyAdmin på testserveren Jobbet med å få Google Code prosjektet til å fungere i Eclipse Tirsdag Gjort: Vi har fått Eclipse til å samarbeide med Google Code. Bruker Eclipse med Subclipse plug-in. o Man bruker subclipse til å hente kildekoden fra Google Code og inn i Eclipse. Man velger Google Code prosjektet og velger Checkout. Så velger man å lage et nytt Flex prosjekt. Etter å ha opprettet Flex prosjektet redigerer vi egenskapene for prosjektet og setter Source path til src/main/flex. Så høyreklikker man på mainairdog.mxml og velger "Set as default application". Bamboo koster penger, så vi har oppdaget et gratis alternativ CruiseControl som vi holder på å prøve ut.â Maven2 og CruiseControl viser seg å være lettere å sette opp på Windows enn i Linux og vi har valgt å bytte ut testserveren med en Windowsmaskin i stedet. Testprogrammene som skal innstalleres er Subversion, Maven2 og CruiseControl. o Subversion brukes til å hente siste versjon av kildekoden ifra Google Code. o Maven2 brukes til å bygge og testkjøre kildekoden og rapportere om feil. o CruiseControl styrer Subversion og Maven2 slik at nedlastning og bygging av kode kan skje automatisk og sier ifra over e-post hvis noe er galt. Laget utkast kravspesifikasjon og forprosjektrapport. o Forprosjektrapporten foreslår å beskrive dagens situasjon. I og med at oppgaven i hovedtrekk blir å behandle og presentere data fra Norsk Kennelklubb. o Trenger en datamodell for å beskrive dagens situasjon og løsning. Regner med å få en mer fullkommen beskrivelse fra BEKK så fort som mulig. [edit] har nå fått databasefil Vi har jobbet med Flex programmeringseksempler og tester o Lært å lage en RSS-reader ved bruk av httpservice, databinding og bruk av DataGrid.

181 Vedlegg Dagbok o Custom DataGrid som populeres med enkelt hundeobjekt. Oppretter nye hunder ved å fylle inn skjema. Satt opp ny testserver for maven2 med cruiscontrol o Installert Maven fra og fulgt installasjonsguiden på samme side. o Installert Java JDK fra o Installert SVN fra for å kunne hente siste versjon av kildekoden fra Google Code. o Installert CruiseControl fra o Jobbet med å konfigurere CruiseControl. Mål for imorgen: Jobbe videre på forprosjektrapporten o Beskrive ytterligere Dagens situasjon Kartlegge data i databasefilen for å tegne et bilde av hva som skal være med i HundeProfil- og VisAlleHundersidene. Lage noen utkast til HundeProfil- og VisAlleHundersidene Onsdag Gjort: Jobbet videre med CruiseControl. Konfigurasjonen ser ut til å fungere, men vi sliter med at Flexunit får timeout under kjøring av Maven. Gjort dokumentmappen Diverse usynlig for personer som ikke er innlogget. Dette er gjort siden mappen inneholder sensitive data. Har fått Maven sin test til å fungere. Problemet var at Adobe Flash debugger ikke var installert på maskinen. CruiseControl er nå oppe og kjører på etter at problemet med flexunit timeout ble utbedret. Holder på å lage utkast til Hundeprofil- og Hundelisteskjermbildene i Flex Builder samtidig som å tegne ned ideer på papir. Diskuterte bruksmønstre og behov. Må etter hvert høre med "fuglehundbrukere" hva de vil foretrekke å se først. Jobber med et problem i Flex builder, bruk av klasser og metoder. Rammeverket er fortsatt ukjent men ting faller på plass. Mål til imorgen: Få på plass Dagens Situasjon i forstudiet Torsdag Gjort: Begynt på "Om gruppen siden". Vi skriver kort motivasjon for oss selv, presentasjon av BEKK som oppdragsgiver og aktuelle hundeklubber. Begynte å se mer på test driven development.

182 Vedlegg Dagbok Bekk ønsker at kildenkoden i prosjektet skal skrives på norsk. Bekk skriver de fleste prosjekter de har imot norske kunder på norsk og ønsket at vårt prosjekt fulgte samme rettningslinjer. Vi har vurdert saken og gått med på at kildekode og syntaks skal skrives på norsk men uten bokstavene æøå som byttes ut med eoa. Vi har satt sammen et veiledningsdokument for strukturen av kode i Flex Builder som beskriver hvordan syntaksen i prosjektet skal skrives. Dokumentet ligger under mappen Diverse (Kreves innlogging for å se mappen). Har jobbet med VisAlleHunder-viewen hvor det er blitt eksperimentert DataGrid og custom ItemRender. Skal vurdere List fremover før vi tar en avgjørelse. Har jobbet med Shared Objects og Dateformater, hyperlenker i Flex, Events, Custom Alert og try/catch. Jobbet med forprosjektrapporten. Mål til neste gang: Jobbe med forprosjektrapport og analyse Gå mer inn i Testing Mandag Gjort: Jobbet med forprosjektrapporten, fordelt oppgaver Lest om testing og debugging Har jobbet med å få Maven riktig satt opp, dvs å teste flex prosjektene Har tatt kontakt med ny veileder, ubekreftet Eva Hadler Vihovde Forøvrig også undersøkt diverse masterstudier og ting ikke direkte knyttet til oppgaven. Mål til neste gang: Forprosjektrapport o Dagens situasjon 90% o Mål og rammebetingelser o Argumentere for metodikk Smidig Vurdere PHP-rammeverk Tirsdag Gjort: Jobbet med forprosjektrapporten o Dagens situasjon o Prosjektets mål og rammer o Løsninger o Sammendrag Studert Flex med PHP og XML

183 Vedlegg Dagbok Onsdag Gjort: Vi har sett på Zend rammeverket til PHP som muliggjør lettere samarbeid mellom Flex og PHP. Jobbet videre med forsprosjektsrapporten. Jobbet videre med HundeListe.mxml Har gjort ferdig utkast av Forprosjektrapporten o Sendt til Eva for evt. tilbakemelding på fredag Eksperimentert videre med "hundeprofil" og "vis alle hunder"-sidene Torsdag Hadde et problem med datagrid ikke ville loade data inne i en TabNavigator men fikset det ved å sette creationpolicy="all" i TabNavigatoren. Den policyen sier at alle barna til containeren skal lages og initialisert. Jobbet med VisProfil-siden og implementerte en datagrid av dummyjaktprøvedata.â Â Prøve å om strukturen og lage objekter fra dummydata før vi har databasen implementert. Studere mer om objekter og ActionScript Mål til fredag: Få tilbakemelding om forprosjektrapport Få kontroll over objektorientert actionscript-programmering Teste å få visallehunder til å navigere til en vishundeprofil Fredag Flex og PHP med Zend Flex progressbar med visualisering av konseptklokke. Ble kjent med nye controllere og pakket til AIR installasjonsfil Møte med nye veileder Eva Vihovde o Avtalt møte med BEKK mandag Mandag - BEKK, Veileder og HundeController For utvikling i Flex der kravet er å lage brukersider før logikk lager vi metoder i controlleractionscript. Disse genererer og returnerer en fiktiv ArrayCollection med data som er lik det eksisterende domenet. Disse metodene blir senere endret slik at de henter objekter fra php-tjenestene. Cruisecontrol er nå oppe og kjører stabilt på

184 Vedlegg Dagbok Lagt til Automatisk Bygging oppe til høyre på hovedsiden som viser status fra CruiseControl ved hjelp av SharePoint sin XML leser og RSS Tirsdag - MVCS Lagt opp referat fra møtet igår Møtet resulterte i innføring av MVCS (Model, View, Controller, Service)-praksis for bedre struktur og oversikt. Jobbet med nye controllere og renders for VisHund. Føles rotete å gjøre alle elementer til renders. Finne komponenter som vil gjenbrukes fortløpende? Vi har skisset opp mulige layoutkonsepter og sett på aktuelle skjermbilder. Ved å liste opp skjermbilder har vi kunnet sette opp tilstandsdiagram for navigering rundt om i applikasjonen. Har undersøkt mulighetene for Paging i DataGridsene med hunder. Siden det er tusenvis av hunder må vi organisere og presentere dataene på en ryddig måte. Foreløpig fant vi biblioteker og kodeeksempler på dette. mål til imorgen Prøve med HundeListe og paging. Jobbe videre med layoutkonsept Se på remote object for dummydata? Onsdag - Zend, prototyping Endret HundController til å bruke Amf til PHP ved hjelp av Zend og laget php-side for serveren. Konfigurert automagisk bygging av PHP ved hjelp av CruiseControl. Det ble vedtatt å lage en grundig studie for prototypen som vil resultere i en minirapport som en del av dokumentasjonen. Ved å legge vekt på målgruppen, applikasjonens omfang og struktur vil dette forstudiet være svært nyttig når vi setter sammen sidene. Vi ser på det som viktig å, på et tidlig stadie, sikre kontinuitet og brukervennlighet slik at det ikke blir tvil senere. Studiet vil munne ut i en low-fidelity prototype evt. laget i papir Torsdag Sett over og levert forprosjektrapporten Jobbet videre med HundParser og fått PHP sitt PHPUnit testrammeverk til å fungere med CruiseControl. Lagt inn PHPUnit på klienten slik at PHP-koden kan testes fra eclipse før den overføres til Google Code. Forprosjektrapporten ligger nå ute under mappen Rapporter.

185 Vedlegg Dagbok Mandag Laget KullParser, EierParser og PersonParser samt medfølgende testklasser Alle kan teste lokalt nå, et lite tutorial om hvordan:â Sett på mvsc Diskutert logo og ui Prototyping Kartlegging av skjermbilder Deltok på FlexCamp Norway o Mange spennende nyheter og interessante foredragsholdere, deriblant vår egen veileder Ole. o HelloGroup presenterte beta av Flash Catalyst, et program som enkelt lager prototyper og deretter implementerer de i ferdig dummykode. Vi har tatt kontakt for å få bruke en demo Tirsdag - Nye T-skjorter og klar for parsing Gruppen har nå komplett sett med "<Flex:Camp Norway2009/>-"-T-skjorter (!) Sendt mail til HelloCompany om Adobe FC o Fikk svar, vi skal få demo-utgave så fort som mulig. Parserne til.dat-filene er ferdig.â Laget validator til hund.dat-filen. Denne sjekker at filtypen og strukturen stemmer overens med de andre.â Jobbet med layoutkonseptet. Diskutert hovedmenyen, skisset opp undermenyer og ikoner. Veileder Eva kom innom og ga tilbakemelding om forprosjektrapporten. o Punkter lagt i Rapporter-mappen o Avtale fast møtedag fredag Laget uploader for backend som får data fra uploader i Flex. Denne uploaderen skal benyttes til å laste opp.dat-filene fra NKK. Mål til imorgen: Lage ferdig validatorer til.dat-filene Onsdag - filopplaster og prototyping Gjort ferdig alle parserne for dat-filene Laget en filvaliderer som returnerer hvilken type dat-fil den bestemte filen er av Filopplasteren i Flex fungerer sammen med PHP-filopplaster. Må skrives tester til. Det var utfordringer med Flex Events i forhold til browsere. Vi tester applikasjonen i localhost i WAMP (windows) og MAMP (mac). Kommet et godt stykke på prototypen. Jobbet med skjermbilder og oversikt over viewsammensetninger/navigasjon. Vi produserer enkle skjermbilder som tilfredstiller userstories. Imorgen:

186 Vedlegg Dagbok Skrive tester til filopplaster Flex/PHP Jobbe videre med prototypen Forberede presentasjon av forprosjektet som skal holdes på fredag. Maks 10min Torsdag Gjort ferdig førsteutkastet av databasen i forhold til NKK sine.dat filer Laget databasefunksjoner i PHP for hund og kull-tabellene Sett på MVC-strukurering og hvordan dette kan gjøres på best mulig måte med Flex Dokumentert den sålangt ferdige prototypen for UI. Fredag Jobbet med å sette sammen en Flex MVCS demo for å få et bedre overblikk over Flex sine Best Practices o Trykk her for å laste ned demoen Omstrukturering i kode for at den skal passe til MVCS På gruppemøtet med veileder ble oppgaver som skal være ferdig til neste møte presentert: Visuell modell av prosjektet Hva som er blitt gjort av hvem siden sist Planen videre for prosjektet Mandag Skrev på prototype rapport Skrev på kravspekk Skrev på forprosjektrapporten Fjernet unødvendig kode Laget MVCS oversikt førsteutkast Laget oversikt over link flow til views Vi var i møte med bekk Tirsdag - veileder, gantt, søk Jobbet med fremdriftsplanen. Til det ble det utprøvd den nye programvaren ConceptDraw - et program som tegner opp det meste av diagrammer og figurer. Dette programmet har vi benyttet til å tegne opp og få en oversikt over alle views til prototypen og linke disse viewsene seg imellom med piler. I tilfellet å lage en fremdriftsplan liksom et gantt-diagram egnet det seg bedre med Excel/Numbers(mac). Skrev møtereferat fra møtet med BEKK på mandag 9.feb. Møte med veileder Eva: o Oppsummerte uken o Presenterte modell av prosjektets arkitektur o Demonstrerte prototypen av UI

187 Vedlegg Dagbok o Fikk "Søk etter hund" til å fungere med mock Mål for imorgen Søk på alle felter i Hund Få til en mock login med predefinerte brukere og roller Onsdag - AMF, Søk og Styling Jobbet med AMF send Søk fungerer på navn, eier osv Jobbet med å få til autentisering; Session vs. Token Få oversikt over styling og layout i Flex Torsdag - flex, php, Zend VI har begynt å ta i bruk Zend rammeverket For autentisering har vi tatt i bruk Zend auth adaptor og zend acl på server. Som sender rollene over til applikasjonen For databasen har vi begynt å ta i bruk Zend_Db. På den måten kan vi bytte ut databasen og slippe å skrive om spørringene i phpn Skrevet om MySql spørringene til Zend_Db spørringer Laget jaktresultatet. Laget oppstart/loading-side for applikasjonen som skal embedde GUI-elementer som ikoner, logoer og mulige illustrasjoner. Eksperimentert med stiler og overordnet tema. Sett på mulige grafer for stamtre Mandag Bruker, rolle og rettigheter i database Admin UI for endring av roller SQL->ZendDB Tirsdag Sql til Zend DB Div gui Autentisering Onsdag Omgjort til Zend DB i hunddb ferdig o Må sjekke om insert, update og delete fungerer Fikset henthund Fikset på logginnview

188 Vedlegg Dagbok Sett på hva vi skal lagre om de forskjellige klubbene o Har laget "klasse" diagrammer på ark Torsdag Autentisering Autorisering Zend Auth Zend Acl GUI DB design Mandag - Zend acl, BEKK og hundesamlinger Avskrevet Zend ACL og lager heller en egen rollestyring o Grunnen er at Zend ACL har sine fordeler i felt som ikke vi kommer til å bruke, for eksempel arv. Dermed vil det bli for mye funksjonalitet og koding i forhold til vinningen for vår del. Vært på måte med Bekk o Avklart en del med dbn i forhold til klubb o Estimert user stories o Satt mål og hatt egenvurdering av arbeid Mål for tisdag: o Få opp bygging mot airdog o Fullføre uferdige oppgaver som ligger litt etter o Skrive mer på kravspekk o Være mer besluttsomme og ta flere forutsetninger Tirsdag - acl, eva Lagt opp applikasjonen på produksjonsserver. Automatisk deploy på kan bli vanskelig og kanskje overdrevet da vi legger opp ny versjon maks 1 gang per dag? Fått igang en innloggingsside der den innloggede velger den klubb han er innrullert ved. Småfiks i gui Avkomsliste for hund Skrevet på referat og kravspesifikasjon Møte med Eva o Begynne å se langsiktig på produktdokumentasjonen o Raske smarte løsninger Onsdag - Kravspek, roller og stamtavle Levert førsteutkast til kravspesifikasjonen o Var uferdig og dekket de pågående og fullførte user-stories som et forsøk på å ha et mer relevant styringsdokument

189 Vedlegg Dagbok Roller og rettigheter o Brukere kan søke etter hunder i den klubben de er logget inn i o Brukere blir sjekket for rettigheter i deres rolle o Superbruker får alle rettigheter og blir ikke sjekket for hvilken klubb han vil logges inn i. Stamtavle o Begynt på stamtavle som sjekker hundens mor og far rekursivt. Altså vises hundens mor og far, mor og fars mor og far gitt at de har mor og far :) o Laget en versjon i front end som i View kaller henthund() etter utregning o Laget en versjon i backend som skal sende array til flex Torsdag - UTF-8 Det oppsto et problem med søking etter norske bokstaver æøå i databasen gjennom Zend db. Løsning finner du her: Stamtre ferdig o Vi gikk for en php løsning. Det blir kjappere og det blir ikke hvis en skulle ønske å bytte ut fronten med noe annet enn flex Mandag Oppdater jaktresultater rot i synken begynt på RedigerHund Utstillingsresultater Slett jaktresultater Rediger jaktprøve Skriver feilmeldinger via php Husk å skru av ene alert boxen i AbstraktServiceobjekt.as, den er kun til debugging! Tirsdag Jobbet med optimalisering av MySQL databasen o Søk i databasen ble veldig tregt etter at 5000 hunder ble lagt inn. Har optimalisert databasen slik at søket nå tar 0.07 sekunder i forhold til tidligere 29 sekunder. For mer informasjon se Optimalisering av MySQL Database.doc under Diverse Jobbet videre med importering av hund.dat filer o Fikset konvertering av dat-filer til utf8-format Fullføre rediger hund Temp data av resultater inn Onsdag - gui og skjemaer Dagens lesning

190 Vedlegg Dagbok beskrivelser av feltene til nye jaktprøveskjemaer. Grei kilde for tooltips Gjort Viser seg å fortsatt være problemer på produksjonsserveren selv da det er installert mysqli Redigere hundedata på hundprofilsiden til databasen. o Må tilpasses til eget "redigerhund"-vindu.â Gjort mye gui i dag.â o HCI o Registrering av jaktprøver og oppdateringer av jaktprøver har fått en overhalling Kom over et problem der du må sette accordion sin creationpolicy til all for å nå alle feltene Torsdag RedigerHund Litt gui og css fiks Tirsdag - redigerhund, redigerjaktprøve, GUI Møte med veileder Eva o Noen fiks på kravspek o Synliggjøre roller og brukerne til systemet; bruk figurer o Skrive mer om valg av programmer og løsninger Redigere hundâ o Kjønn: enten eller boolâ o Eiers id: ingen som vet. Redigere jaktprøve o Endringer i det nye skjemaet o Størrelse Skjemaet har fått nærmere fullskjermvisning for mer oversikt og plass til alle 41 feltene(!) o Grupperinger Nyere grupperinger som skal kunne samsvare med papirskjemaene som brukes idag. Det er også tatt hensyn til den kommende 2009-standarden o Nye konsepter At prosadelen skal være synlig alltid i skjemaet er begrunnet med at den som fyller inn data kan jevnt over skifte til å skrive oppsummeringstekst. Hvis den som fyller inn prosatekst ønsker å gløtte over i de ulike datafeltene og bla om i underskjemaene, mister man ikke tekstfeltet av syne og arbeidsprosessen kan gå jevnere.

191 Vedlegg Dagbok Onsdag Historikk, frem og tilbake-navigasjon o Påbegynt med bruk av deep-linking RedigerJaktprøve o Ferdig med gui o Lagt til nye tekstfeltet Kritikk i databasen o Nye gui fungerer opp mot backend Kravspesifikasjon o Har gjort endringer ihht tilbakemelding fra veileder Eva o Lagt om på funksjonelle krav, stikkordsform og strøket user-stories o Flytter dokumentasjon om user-stories til prosessdokumentasjonen helt o Mer om krav til bruk av verktøy og teknologi, bl.a egne krav til systemet o Mer om sikring for tap, misbruk og roller Ryddet i koden o Fjerning av ubrukte funksjoner i backend og omegn Admininstratorpanel for håndtering av roller Dokumentasjon o Referat fra iterasjon 5 lagt opp Torsdag - skjemaer, rollehåndtering og prosessdokumentasjon Utbedret stamtre o Tittel og Id er synlig på stamtrenodene og penere satt opp Rollehåndteringspanel Jaktprøve skjema o Det nye jaktprøveskjemaet ble ikke godkjent da det ønskes å ligne enda mer på papirskjemaet. o Nytt skjema ferdig Prosessdokumentasjon o Om pivotal tracker-verktøy o Om smidig utvikling med user stories og iterasjonsmøter, poker planning Om skinning Har funnet ut en lett og grei måte å skinne appen vår på: Så sjekker dere ut hvordan skinne i illustator. Er sinnsykt digg måte å gjøre det på. Lagt opp et eksempel i appen vår også. God helg:) Mandag Skinning

192 Vedlegg Dagbok o Utforsker muligheten for å "skinne" applikasjonen ved å integrere adobe illustrator cs4 og photoshop cs4. Photoshop fungerte dårlig pga. bitmap grafikk som skalerer dårlig i kompilering. JaktprøveVindu Roller og rettigheter med søppelbøtte Tirsdag Prosessrapport o Om flex og skinning o Om pivotal tracker verktøy Jaktprøvevindu o Hund vises ved hundid. Validerer om hund er fylt inn og at hund eksisterer i databasen o Ny server Velkommen til prosjektsiden på den nye serveren. Alt skal fungere som før bortsett fra at den endelige adressen nå blir og ikke NB: Problemer med å logge inn? home\bruker har blitt byttet om til lervik\bruker Tore Onsdag Kopier hundid o Dobbelklikk kan være forvirrende og hører ikke hjemme i en web-applikasjon da man aldri dobbelklikker på lenker etc. o Nå fungerer hundid-kolonnen slik at du kan markere tekst og kopiere (ctrl+c) uten å måtte uønsket hoppe inn på profilsiden. RedigerBruker Backup o Gjort ferdig backupløsning som lar administrator ta en kopi av hele databasen. o Viser en liste over tidligere kopier og lar administrator velge hvilke tabeller som skal bli gjennopprettet. case med testserver, endrer et felt på jaktprøver og lagrer, får flere identiske poster o Problem lå i spørringene da provenr ikke er unikt. Se Oppgaver>Kildekode Torsdag Rediger bruker slik at det sendes et gammelt og et nytt objekt av brukeren uavhengig av session. Stor oppdatering på GUI og skinning fra Adobe Illustrator CS4

193 Vedlegg Dagbok o Søkefelt o Brukerhåndtering o Omorganisert topmeny, bort med tabs, inn med viewstack og spesielt panel for admin o Flere småting og ikoner Begynt på utkast av prosessdokumentasjon Fikset HentKlubber sin SQL syntaks o Hvis en bruker hadde flere roller i en klubb ble klubben listet opp flere ganger under "Velg klubb" vinduet Fikset sql spørring på slett bruker på rolle i klubb. Problemet var at metode navnet var endret men ikke navnene på metode kallene. Oppdaterte filen mot Airdog.no klokken 21: Fredag Skrevet om Rettighetshåndteringen o Før: Løsningen vi hadde før var en array på bruker med rettigheter og dette ble tungvindt i forhold til å sette visible osv til true false i viewet o Nå: har bruker en modell rettigheter i seg og en kan sjekke disse verdiene i stedet.â o I backend krevde dette omskriving av ACLController og en ny modell klasse som heter AmfRettigheter Mandag Rediger Jaktprøve sender ikke med den gamle jaktprøven slik at primærnøkler kan endres. Møte med BEKKs veiledere o Referat lagt opp Tirsdag - zend bug Fikk et problem og brukte lang tid på å debugge det. o Det som skjer er når Flexen sender en modell som ikke er lik php siden så tryner phpn uten å si hvor den tryner o Problemet: På rediger din egen bruker så sendte vi med modell:bruker fra flex. Når Dette ble sendt over zend amf så kræsjen den siden bruker modellen på flex siden som ble sendt ikke var lik amfbruker på php siden Etter oppfordring fra tilbakemelding er det skjedd en del fiks på GUI o ButtonBar-admin-kolonnen for jaktprøvelisten ble separert til to ikoner som fungerer for knapper. Lagt til et nytt ikon som lar bruker lese jaktprøvekritikk fra et uredigerbart skjema o Søppelbøtten er fjernet og forklaring på dra og slipp funksjonalitet er lagt til. Nå fjernes brukere og rettigheter ved å dra dem tilbake dit de kom fra.. o HundId vises i avkomsliste Redigerbruker fungerer

194 Vedlegg Dagbok Rettet en bug der du trykket LegginnJaktprøve før du hadde vist noen jaktprøver. Problemet var at sessionobjektet som jaktprøve view kan hende ikke er satt og en fikk nullpointer ex. Så bare sjekket om det var satt eller ikke. Fikset litt på dat opplasting view og på backup view Torsdag Når man skriver tester i phpunit så må alle metoder starte med test(funksjonnavnet) Huske på regelen: Ikke skriv tester for ting som er vanskelig å teste;) Skriv tester for parsere Har drevet med retting av jaktprøve. Da vi måtte ta var på det gamle når vi redigerte en jaktprøve sine primærnøkler slik at en kunne finne hvilke som skulle bli redigert i dbn. Det samme er gjort på brukeren. Driver med importeringen Mandag jobbet med o ny løsning av menyen i gui o avlstall o rasens jaktresultater o problematisk import o rankingliste Problem oppsto for Windows-gutta Prøver fisk med å sende en respons (echo) ofte nok til at den ikke tryner.:) Løsningen kom og problemet oppsto! Det viser seg at løsningen for å fixen flash player buggen for firefox på windows skapte et problem med Safari. Safari slutter å lytte på serveren i løpet av rundt 8000 svar fra den. Men firefox på windows må ha et visst antall svar fra serveren for å holde tilkoblingen oppe. Løsningen kan være å finne et mellom ting som fungerer på begge browsere Det som skjedde er at Safari kutter når den får for mye informasjon fra server på kort tid. Mens Firefox kutter når den får for lite informasjon på kort tid

195 Vedlegg Dagbok Charles Hadde et problem med å lytte på localhost trafikk i Charles. Løsningen er å skrive i stedet.â Grunnen til at den ikke greier å lytte på localhost trafikken uten. etter er fordi noen systemer er hard kodet slik at de ikke bruker proxy i localhost Onsdag Referat fra iterasjonsmøte 7 lagt opp Ordnet ny UTF8Konverterer som fungerer både med OS X og Windows. o Denne gjør at &Aelig;ØÅ blir riktig i databasen uansett tegnsett på den orginale filen. Gjort ferdig Excel eksport funksjon for DataGrid-objekter i Flex. o Funksjonen er lagt til ved Jaktprøver, Avkom og utstillinger for en gitt hund Torsdag Begynt på arrangementtabell for jaktprøver Rasens jaktresultater Aarbok og excel eksport Cup-funksjon Mandag - årsrapport og fiks Jobbet med å generere årbok (til rtf) Begynt igjen med prosessrapport, legge opp struktur og mal Fikset jaktprøvevindu o input-felter som ble for store ved sist styling ble nå mindre o Ved klikk på lagreknapp lukkes vinduet automatisk (slipper nå å benytte avbrytknapp Mandag - siste iterasjon Møte med BEKK, siste iterasjon Parser til bilder av alle hunder. Går igjennom mappe og endrer til rett størrelse på en hel bildedump Tirsdag - pivotal og wordpress Satt opp nytt Pivotal prosjekt for å holde styr på sluttdokumentasjonen o Dette grunnet at oppgaver-seksjonen på prosjektsiden vår har vært tungvint og vanskelig å holde seg ajour i forhold til pivotal.

196 Vedlegg Dagbok o Fortsetter som før å føre dagbok og dele filer på prosjektsiden, men lager en forenklet presentasjonside som vil ligge på skolens server. Antageligvis blir dette en wordpress-side. RSS-fungerer (!) da den måtte kodes på klientsiden istedenfor backend.â o Dette ble lettere da det ble brukt Adobe's egne ActionScript CoreLib og XMLsyndication. Fikk på plass en velkomsttekst for hver klubbside o Nye felter på klubb i databasen, rss og forsidetekst Rydding av kode o embedding, css etc Onsdag - Flexfiks, presentasjon, prosessdokumentasjon Presenterte prosjektet på underkant av et kvarter. Gikk forsåvidt bra. Grei flyt, fikk spørsmål om hva vi hadde laget systemet i. Hvem var kunden. Begynt å rense opp flex-koden ved å fornorske navn på funksjoner og lignende, dra ut all styling til css og gi noen filer nytt navn (eks. mockcontroller) Satt opp et system for håndtering av sluttdokumentasjon. Vi benytter Pivotal Tracker for å liste opp kapitler og delkapitler som må skrives. o Hver story er entenâ lablet som PROSESS, PRODUKT eller KRAVSPEK. På denne måten kan vi dele kapitlene hver for oss og ha oversikt over hvem som skriver hva. o Hver story vil ha et tilsvarende word-dokument i mappen Sluttdokumentasjon. I denne mappen er dokumentene sortertâ i undermapper med samme navn som storyenesâ labelâ Torsdag - airdog.no "Endelig" versjon av AirDog lagt ut på airdog.no Mandag - dokumentasjon, dokumentasjon, dokumentasjon jobber med delkapitler til prosessdokumentasjon Tirsdag - dokumentasjon Det arbeides flittig med dokumentasjon. Delkapitlet 'Planlegging og metode' er nesten ferdig Onsdag - Fredag Dokumentasjon, dokumentasjon, dokumentasjon

197 Vedlegg Dagbok Skrevet mye på prosessdokumentasjon, jobber også med produkt. Kravspesifikasjonen er ferdig og skal sammenlignes med det endelige produktet. Har sendt utkast til veileder av den midlertidige rapporten Siste møte med Bekk? Sted: Borggården Biffrestaurant

198 Vedlegg Dagbok

199 Referat Møte tittel: Første oppgave møte Dato: Tid: 09:00 Sted: Bekk Tilstedet: Ikke tilstede: Egil Paulsen Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Hege Melgård Christian Schwarz Saker: Mål mot neste møte: Bli kjent Ordne TFS tilgang til veiledere Utdype oppgaven Undersøke muligheter for møte- og arbeidsrom Avklare forventninger på skolen. Vinkle oppgaven til studenters interesser Notater: Gruppen og veilederne fortalte kort om deres bakgrunn og interesser. Veileder Ole fortalte om sin tidligere erfaring med oppgaven og forklarte problematikken som er idag i forhold til OS kompabilitet. Vi følger BEKK anmodning om å jobbe Smidig. Siden vi semesteret ikke er mer en et par måneder har vi korte intervaller på 1-2 uker. Jobber iterativt basert på krav fra brukerhistorier. Vi diskuterte mulighetene for programmeringsspråk. Java vs php, fordeler ved hosting, kunnskap o.l. Ole som har ekspertise i Flex og Air vil tilby kursing. Han foreslo å ta en dag i desember med kursing. Eksempel på datafil fra NKKs databaser ble presentert av Erlend. Erlend advarte om feil, nøkkelsammensetninger og annet andre hensyn i forhold til radene i datafilen. Prosjektsiden, dagbok og mulighet for å bruke tfs ble nevnt. Har laget sharepoint for web, se prosjekt.mindre.net. Referent: Egil Paulsen

200

201 Referat Møte tittel: Førjulsmøte Dato: Tid: 09:00 Sted: Bekk Tilstedet: Egil Paulsen Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Saker: Valg av språk (PHP eller.net) Navn på prosjektet Hvordan prosjektet skal utformes Diskutere utviklingsverktøy Notater: Ikke tilstedet: Mål mot neste møte: Se på user stories og planlegge litt Erlend og andre skal tenke på krav og user stories Vi skal ha satt opp maven server Poker planning Server Erlend (produksjonssever) en møte å dele alt mellom klubbene Snakkes med Jon på funk om brukervennlighet OC/Erlend prøve å opprette et google code prosjekt Taushetserklæring persondata Gruppen og veilederne diskuterer valg av språk (PHP eller.net) imot flex. Mindre driftskostnader og større støtte imot flex gjør at PHP blir valgt. Navn på prosjektet blir diskutert. AirDog og FlexDog blir nevnt. Brukersentrert utforming, legge vekt på hci og universiell utforming. Stor brukergruppe 30-65, utforming må gjøres enkelt. Diskutere bruk av utviklingsverktøy (Open Source) Eclipse med flexbuilder plugin FlexBuilder Subversion GoogleCode Git? GIRA, kanskje? Maven til å bygge flex Bruke Messenger til rask kommunikasjon og E-post til andre forespørsler. Messenger E-post Referent: Hans Magnus Inderberg

202

203 Referat Møte tittel: Krav til oppgaven. Estimat Dato: Tid: 09:00 11:00 Sted: Bekk Tilstedet: Ikke tilstedet: Egil Paulsen Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Saker: Mål til neste møte: Oppsummere uken Første iterasjon 2 user storyes Pivotaltracker Oppsett og alt annet som skal til før vi kommer i gang Forprosjektrapport Finne ut hvordan vi skal få dokumentasjonen Fremgangsmåte Påbegynt forprosjektrapport Subversion Estimater Notater: Oppsummerte forrige uke og nevnte erfaringer fra flex og maven. Flex virker uvant både syntaksmessig og i editor, men virker bra å jobbe med. Diskuterte sammensetningen med maven og google code evt bamboo. Skaff subversion klient for build og check outscrum. Nyttige lenker: Maven for php Maven for flex Flex reference Flex component explorer Ole og Erlend introduserte Pivotaltracker med ferdige userstories. Valgte ut et par ønskede userstories og diskuterte estimater for disse. Prøvde såkalt poker-planning hvor alle kaster verdikort basert på antatt arbeid/kompleksitet. Valgte user stories: 1. Vis hundeprofil 2. Vis alle hunder 3. Bamboo server Gikk kort igjennom noen punkter om forprosjektrapporten og ble enige om å ha et siste møte før innlevering tirsdag 27 januar. Planen videre er å lage Flex-skjermbilder først for å forestille seg backend senere, poeng å ikke gå på viddene.. lage dummydata og fokusere på features. Velger user-story og legger den i backlog Lurt: legge til en impediment ting som dukker opp (chores ) Referent: Egil Paulsen

204

205 Referat Møte tittel: Førjulsmøte Dato: Tid: 15:00 Sted: Bekk, Festningen Tilstedet: Ikke tilstede: Egil Paulsen Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Eva Hadler Vihovde Saker: Mål mot neste møte: Bekk blir kjent med veileder Få ferdig forprosjektrapport og skrive Diskuterer målsettinger for prosjektets kravspesifikasjon involverte Diskturerer presentasjon av hund Estimerte for ny sprint Notater: Møtet startet 1500 med at vi letet etter ledige møterom ved BEKKs lokaler. Veileder Eva dukket opp og introduserte hennes rolle i hovedprosjektet. Veileder fra HIO legger vekt på dokumentasjon av prosjektet, prosjektets fremgang og å få synliggjort prosessen. Det ble gjort et poeng i at veileder ikke fungerer som prosjektgruppens femte medlem. BEKK har som interesse i prosjektet å ha igjen, om ikke helt ferdig, et system de kan ha glede av og utvikle videre på. BEKK har som mål å lære fra seg litt av hvordan det fungerer i arbeidslivet da også sett i et rekrutteringsperspektiv. I prosjektets gang vil hver av dem representere en hundeklubb og vil derfor være kunden i dette tilfellet. Møtet holdt også av en diskusjon ang. presentasjon av data. Problemet i utgangspunktet er av prosjektgruppen ikke har en videre interesse for fuglehunder og er derfor vanskeligere å forestille seg hvilke hundedata er mer relevant enn andre. F.eks tok diskusjonen for seg hvilke datafelt som er relevante å se i HundeListe. Vi fant en prioritert rekkefølge som [tittel(usorterbart)] Navn (sorter), foreldre, eier (sorter), oppdretter (sorter), kjønn. Selve applikasjonen vil bli benyttet både i en websidecontainer og som air-desktop-applikasjon. Det er ønsket at layoutet er dynamisk, altså tilpasser seg vindustørrelsen, og at minimumstørrelsene er 800x600 piksler. Videre eksperimentering vil bestemme om det også vil tas i bruk maksimumstørrelser. BEKK spanderte pizza påfulgt med kodedemonstrasjon fra Ole. Introduserer [Bindable] og enhetstesting. Ble gjennomgått en ny runde estimering og såkalt poker planning for nye to ukers sprint. VisProfil -story skal fullføres. Introduserte nye stories som overordnet prototype av design, remote object m/php, Oppdatere data for hunder fra NKK. Referent: Egil Paulsen

206

207 Referat Møte tittel: Iterasjonsmøte 3 Dato: Tid: 15:00 Sted: Bekk, Øyen Tilstedet: Ikke tilstede: Egil Paulsen Eva Hadler Vihovde Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Saker: Mål mot neste møte: Oppsumere iterasjonen Levere neste sprint Presenterte prototype Diskuterte prototype Gikk igjennom kode Estimerte ny iterasjon Notater: Møtet startet 1500 med at vi presenterte en tidlig prototype for brukergrensesnittet. Dette var noe som virket uvant på veilederne. Veilederne Ole og Erlend fungerte som testpersonen og fikk klikke seg rundt i papirapplikasjonen. 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 de to slik vi hadde laget. Vi fikk nyttig tilbakemelding om sidene som kan tas i betraktning til neste design. Videre gjorde vi en undersøkelse på skjermoppløsningen til brukerne av det tidligere systemet. 99,4% har over 800x600 skjermoppløsning, derfor kan vi trygt bruke et bredere skjermbilde for å få plass til mer. Vi satte en standard på 960px som maks bredde. Dette er fordi man kan regne noen rammer som går inn fra en 1024px bredde. Dette er ting som nettleserens rammer, scrollbar og lignende. På grunn av at systemets funksjonalitet også vil ta for seg administratorrettigheter, er det viktig å kunne autentisere for brukerroller. Det ble avgjort å lage en login der man kan velge ferdige brukere med ulike roller. Det var et ønske om å lage dette i et tidlig stadie slik at applikasjonen kan skalere og bygges riktig. Noen brukere vil for eksempel kunne få begrensninger som ikke lese eier- og oppdretteropplysninger. Veileder Ole gikk igjennom koden og den nye strukturen satt opp etter inspirasjon fra MVCS-mønsteret. Han var veldig fornøyd. Noen småjusteringer kan gjøres etter hvert. Slik strukturen så ut var det bare å fortsette. Siste del av møtet gikk til estimering av nye user-stories. Stories Det ble estimert Deploying til airdog.no, Autentisering, Søk etter hund, Vis jaktprøve, Stamtavle, Se avkom. For neste sprint skulle de fire førstnevnte leveres. Referent: Egil Paulsen

208

209 Referat Møte tittel: Iterasjonsmøte 3 Dato: Tid: 15:00 Sted: Bekk, Øyen Tilstedet: Ikke tilstede: Egil Paulsen Eva Hadler Vihovde Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Saker: Mål mot neste møte: Oppsummerte iterasjonen Levere neste sprint Halv bemanning Applikasjonen så langt Klarere avgjørelser Notater: Møtet startet med oppsummering av foregående iterasjon. Gruppen hadde vært redusert med til tider 50% pga. Tore hadde vært syk og Egil hadde vært bortreist et par dager. Videre hadde ikke gruppen klart å levere alle 29 poeng som var estimert. Dette kom av mindre arbeidskraft, vanskelige og kompliserte profilsiden Jaktprøve, avkom, helse, utstilling Avkomstatestikk Egenstatus Avlsindeks Nkk bryr seg ikke Flere hundeklubber Finnes "fuglehundklubber" som tar inn flere raser i en klubb Gjøre så enkelt som mulig, indeksere klubbene etter rasens id Php filtrerer de hundene man skal se I session settes hvilken raseid man opererer med Må bruke denne som parameter til php Konklusjon - lage en superbruker ved å ha admin rolle i alle klubber Retrospektiv Lage tilbakemeldingsystem Feks. Lapper Do more, do less, stop, works Vi følte at vi brukte mye tid på diskusjon om hva kunden vil ha. Generisk oppgave, abstraher og skriv om vår løsning i den store sammenhengen. Se om vår arkitektur, løsning, lag (mvcs) osv, kan sees på som en løsning man kan lære av. Skriv rapporten i opphøyd form. Skriv en lærebok om hvordan man løser et slikt type problem. Referent: Egil Paulsen

210

211 Referat Møte tittel: Iterasjonsmøte 3 Dato: Tid: 15:00 Sted: Bekk Tilstedet: Ikke tilstede: Egil Paulsen Eva Hadler Vihovde Tore Lervik Pelle Bjerkestrand Hans Magnus Inderberg Erlend Oppdahl Ole Christian Langfjæran Saker: Mål mot neste møte: Oppsummerte iterasjonen Levere neste sprint Estimering og prioritering av mål Notater: Møtet startet med oppsummering av foregående iterasjon. Estimerte ferdig alle user-storiesene for å kunne få oversikt over hvor mye som gjenstår til hovedrelease. Det var som ventet for mye funksjonalitet å implementere, så det var nå mulig å begynne å prioritere realistiske mål i forhold til leveringsfristen. Pivotaltracker-verktøyet genererte en burn-down-graf som viser progresjonen til prosjektet og deleveransene. Hver leveranse har så og så mange poeng. Ettersom poengene blir godkjent, trekkes de fra helt til de er null og prosjektet er fullstendig levert. Denne iterasjonen viste seg å være god da det ble unnagjort mange poeng i tillegg til at gruppen var nedbemannet. Det gode resultatet kommer også av at iterasjonen bar preg av mye programmering, og ferre oppgaver som serverkonfigurasjon, integrering og prosjektrapporter. Grafen viser dagens status. Progresjonen har gjort et kraftg hopp etter den siste iterasjonen. Det ble vedtatt å levere løsningene på user-stories fortløpende under iterasjonene. Det motiveres med at det vil gå mindre tid på gjennomgang av leveransen for å så avgjøre om de er godkjent/ikke godkjent. Møtene vil gå fortere ved å levere umiddelbart, får direkte tilbakemelding, enklere å rette opp feil og bruke mindre tid på møtene. Videre gjør dette at vi kan ta i bruk de nye leveransene på produksjonsserveren slik at kunden får testet dem. Referent: Egil Paulsen

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009 2 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

Detaljer

FORPROSJEKTRAPPORT. (+47) 482 32 249 egil.paulsen@gmail.com. Tore Lervik (+47) 470 10 713 tore@mindre.net

FORPROSJEKTRAPPORT. (+47) 482 32 249 egil.paulsen@gmail.com. Tore Lervik (+47) 470 10 713 tore@mindre.net AIRDOG FORPROSJEKTRAPPORT PRESENTASJON Sted og dato Oslo, Feb 9, 2009 Prosjektets tittel Gruppemedlemmer Oppdragsgiver Veiledere, BEKK Kontaktperson, BEKK Veileder, HiO AirDog Egil Paulsen (+47) 482 32

Detaljer

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009 2 1 Innledning Vi har jobbet i en iterativ utviklingsprosess og hver funksjon i applikasjonen har blitt fortløpende testet før den har blitt godkjent i Pivotal Tracker. Testene i denne rapporten er utført

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

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

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009 2 1 Forord AirDog er en applikasjon for visning av hundeklubbers hunder ved hjelp av data levert av NKK. Applikasjonen lar deg søke etter hunder på navn og id, se informasjon om hunden, og se rapporter

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

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

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Sluttrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

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

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

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

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

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

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

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

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Forprosjektrapport gruppe 20

Forprosjektrapport gruppe 20 Høgskolen i Oslo og Akershus Forprosjektrapport gruppe 20 PlaNet Knut Magnus Elde s189160 Kristoffer Ylven Westgaard s189143 22.01.2015 Innhold 1. Sammendrag... 3 2. Dagens situasjon... 3 3. Mål og rammebetingelser...

Detaljer

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

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio. Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen

Detaljer

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

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

1 Forord. Kravspesifikasjon

1 Forord. Kravspesifikasjon [Type text] [Type text] 3/5 Hovedprosjekt ingeniørutdanningen 09 Kravspesifikasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 6 Intern veileder

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

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

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

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

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK 2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor

Detaljer

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

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem

Detaljer

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

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

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

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007. PROSJEKT NR. 2007-16 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Panther

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

Gruppe 43. Hoved-Prosjekt Forprosjekt Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141

Detaljer

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

Use Case Modeller. Administrator og standardbruker

Use Case Modeller. Administrator og standardbruker Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet

Detaljer

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

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

Bachelorprosjekt 2017

Bachelorprosjekt 2017 Bachelorprosjekt 2017 Høgskolen i Oslo og Akershus Gruppe 41 Kristan Munter Simonsen (s236789) Andreas Jacobsen (s236778) Jamal Lakbir (s236722) 1 Innholdsfortegnelse Forprosjekt... 3 Presentasjon... 3

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

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

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Testrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

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

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324

Detaljer

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Kravspesifikasjon for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra.

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra. Visjonsdokument 1 Introduksjon Dette prosjektet er gitt av Svend Andreas Horgen, og gjennomføres som en prosjektoppgave i faget TDAT3022-A 14H Systemutviklingsprosjekt ved HiST, AiTEL. Hensikten med dette

Detaljer

Forprosjektrapport ElevApp

Forprosjektrapport ElevApp Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

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

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

Detaljer

KRAVSPESIFIKASJON v.1.2

KRAVSPESIFIKASJON v.1.2 KRAVSPESIFIKASJON v.1.2 PROKAP Prosjektstyringsverktøy for kapasitetsplanlegging G r u p p e 2 6 A n d r é S t e n e r s e n B j a r t e A u n e O l s e n C h r i s t i a n S t r å t h H e n r i k H o

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Bacheloroppgave 2017 Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon

Detaljer

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Kristiansund. Bedriften tilbyr engineering og maskintekniske

Detaljer

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

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle

Detaljer

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

InfoRed Publisering. - produktbeskrivelse.  TalkPool WebServices Postboks Åneby InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,

Detaljer

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord. Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

Detaljer

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

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål

Detaljer

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Pedagogisk regnskapssystem

Pedagogisk regnskapssystem av Benjamin Dehli og Jørgen Tellnes Innhold 1 Innledning 2 Om forprosjektet 2.1 Forprosjektgruppen 2.2 Målsetninger med forprosjektet 3 Beskrivelse av hovedprosjektet 3.1 Arbeidstittel 3.2 Prosjektgruppe

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

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

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

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

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Testdokumentasjon. Testdokumentasjon Side 1

Testdokumentasjon. Testdokumentasjon Side 1 Testdokumentasjon Testdokumentasjon Side 1 1. Innledning Dette er en testrapport som er laget for å teste applikasjonene for ios og Android plattformer. Den vil være delt opp i 4 deler. Den første delen

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

SiteGen CMS. Innføringsmanual

SiteGen CMS. Innføringsmanual SiteGen CMS Innføringsmanual Copyright Barlind Solutions AS 2008 Hva er SiteGen CMS? SiteGen CMS er et såkalt content-management-system; eller med litt andre ord et publiseringssystem. Det kan brukes til

Detaljer

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

Detaljer

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive,

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive, 1. Last ned og installer XAMPP. 2. Sjekk at alt fungerer. 3. MySQL. Vi begynner med databaseserveren, MySQL. Gå til DOS klarmelding eller ledetekst (finnes under tilbehør på startmenyen om du ikke som

Detaljer

Bruksanvisning for Diabetesdagboka

Bruksanvisning for Diabetesdagboka Bruksanvisning for Diabetesdagboka Introduksjon Diabetesdagboka er et selvhjelpsverktøy for deg som har diabetes, utviklet av Nasjonalt senter for samhandling og telemedisin (NST). Diabetesdagboka gir

Detaljer

Styringsdokumenter. Studentevalueringssystem

Styringsdokumenter. Studentevalueringssystem Styringsdokumenter Studentevalueringssystem Forord Dette er en samling av alle styringsdokumentene gjennom prosjekt perioden. Styringsdokumentene er satt opp i rekkefølge i forhold til perioden de ble

Detaljer

Kravspesifikasjon

Kravspesifikasjon 24.05.2017 Kravspesifikasjon Gruppe 10 BACHELORPROSJEKT 2017 INNHOLDSFORTEGNELSE 1 PRESENTASJON... 3 2 OM BAKGRUNNEN... 3 3 FORORD... 4 4 LESERVEILEDNING... 4 5 KORT SYSTEMBESKRIVELSE... 4 6 RAMMEKRAV...

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Testdokumentasjon Presentasjon

Testdokumentasjon Presentasjon Testdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe 10 26.05.2014 Forord Denne rapporten oppsummerer vårt arbeid med FôrIt CDS. Under skriver

Detaljer

Testdokumentasjon. Testingen utføres for å utelukke mest mulig feil i systemet.

Testdokumentasjon. Testingen utføres for å utelukke mest mulig feil i systemet. PROSJEKT NR. 2007-30 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 Testdokumentasjon

Detaljer

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681 Forprosjektrapport Høgskolen i Oslo Våren 2007-02-02 Dr.Klikk Gruppe 25 Håkon Drange s130167 Lars Hetland s127681 Innholdsfortegnelse PRESENTASJON... 2 SAMMENDRAG... 2 OM BEDRIFTEN... 2 DAGENS SITUASJON...

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

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

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan 2/3/2014 INSTITUTT FOR INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS FÔRIT CDS Mikkel Sannes Nylend Shahariar Kabir Bhuiyan Stian Strøm Anderssen Denne siden skal være blank. 1 Presentasjon Prosjektgruppe:

Detaljer

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. 1 Sammendrag Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. Vår oppdragsgiver, ABTF hadde et ønske om en større web

Detaljer

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

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android 6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision

Detaljer

Kap 11 Planlegging og dokumentasjon s 310

Kap 11 Planlegging og dokumentasjon s 310 Kap 11 Planlegging og dokumentasjon s 310 11.1 Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid:

Detaljer