Dokument 2 - Produktdokumentasjon

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

Innholdsfortegnelse Produktdokumentasjon 1 1. Om produktet 1 2. Rammebetingelser 2 2.1 Utredning av krav 2 2.2 Endringer av krav 2 2.3 Samsvar mellom kravspesifikasjon og ferdig produkt 3 2.4 Teknologi 3 3. Produktets oppbygging og virkemåte 5 3.1 Funksjonalitet 5 3.2 Brukergrensesnitt 6 3.3 Sentral teknologi 9 3.4 Teknisk arkitektur 10 3.5 Databasearkitektur 11 3.6 Bruk av tredjeparts kode 12 4. Testing 13 4.1 Enhetstest 13 4.2 Brukertest 13 4.3 Systemtest 14 4.4 Bruk av ilab i testing 14 5. Metode og planlegging 16 5.1 Utviklingsmetode 16 Dokument 2 - Produktdokumentasjon

5.2 Utviklingsmiljø 17 5.3 Backup 18 5.4 Versjonskontroll 18 5.5 Risikovurdering 19 Dokument 2 - Produktdokumentasjon

Produktdokumentasjon Produktdokumentasjonen skal redegjøre for produktets funksjonalitet, tekniske oppbygging, og skal gi en detaljert beskrivelse av løsningens utforming og dens virkemåte. Produktdokumentasjonen beskriver følgende punkter: Rammebetingelser Oppbygning og virkemåte Brukergrensesnitt Teknologi Testing Metode og planlegging Produktdokumentasjonen er frittstående og kan leses uten å ha tidligere kjennskap til produktet eller prosjektet. 1. Om produktet «Automatnett» er en web-applikasjon til bruk for ansatte i Uno-X Automat til å lese dokumentasjon, manualer og nyheter. Produktet inneholder en innloggingsmodul hvor brukeren må autentiseres med brukernavn og passkode for å få tilgang til innhold og tjenester. Det er mulig for bruker å lese meldinger, delta i forum og sende inn skjemaer. Brukerne som har administrator-rettigheter på systemet får adgang til et panel hvor de kan sende meldinger, publisere, slette og endre både artikler og dokumenter. Administratorene har også mulighet til å se innloggingsstatistikk for alle brukere på systemet. Produktet omtalt i dokumentasjonen har fått navnet «Automatnett», som er det samme navnet bedriften benytter på sin gamle CMS-løsning. Bakgrunnen for produktet var at Uno-X Automat ønsket å få utviklet en ny CMS-løsning på grunn av flere problemer de opplever ved bruk av sin nåværende løsning. I tillegg hadde de ønsker for ny funksjonalitet, og isteden for å utbedre det eksisterende «Automatnett» ble det bestemt at det skulle lages et nytt fra bunnen av. Oppdragsgiver så dette som en mulighet for å få omstrukturert og ryddet opp i innholdet slik at de kunne få en mer relevant CMS-løsning som ansatte hadde bedre nytte av. Dokument 2 - Produktdokumentasjon 1

2. Rammebetingelser Rammebetingelsene beskriver de begrensningene som ble etablert i planleggingsfasen for utviklingen av produktet. Interne og eksterne forutsetninger setter grenser for produktet fra et teknisk og bruksmessig perspektiv, men forteller også hva produktet burde gjøre. For prosjektet inngikk det rammebetingelser for teknologi og krav. 2.1 Utredning av krav Det har innledningsvis i prosjektet blitt brukt mye tid på å forstå hva oppdragsgiver har behov for i en ny løsning, og ikke minst hva som er mangelfullt ved det eksisterende systemet. Det er utført brukertester og intervjuer i forbindelse med kartleggingen. Se vedlegg 9 for testrapport. Resultatet av de foretatte undersøkelser tilsier at den eksisterende løsningen til Uno-X Automat ikke oppfyller oppdragsgivers krav til brukervennlighet. Løsningen har ikke blitt utviklet med tanke på å kunne benyttes på smarttelefon eller nettbrett. Under utredning av krav ble det tydelig at slik funksjonalitet er sentral for oppdragsgiver for å sikre at produktet er tilgjengelig og kan forbli en viktig informasjonskanal i bedriften. Basert på innledende undersøkelser, intervjuer, UseCase-modellering og forståelse av eksisterende løsnings svakheter, ble det fastsatt en rekke funksjonelle og ikke-funksjonelle krav til ny løsning. En stor andel av de ikke-funksjonelle kravene relateres til optimalisering av brukergrensesnitt med hensyn på brukervennlighet, samt «cross-platform»-kompatibilitet og responsivt design. Det meste av funksjonalitet fra den eksisterende løsningen ønskes videreført til den nye løsningen, men i en ny og bedre innpakning. Derfor vil mange av de funksjonelle kravene være identiske for de to løsningene, samtidig som det vil være større forskjell på de ikke-funksjonelle kravene. Se vedlegg 3 for kravspesifikasjon for løsningen. Se vedlegg 7 for UseCase-modell og beskrivelser 2.2 Endringer av krav Kravspesifikasjonen gjennomgikk flere iterasjoner i planleggingsfasen før en fullstendig kravspesifikasjon ble godkjent av oppdragsgiver. Endringer i kravspesifikasjonen var et resultat av samtaler og innspill fra begge parter, og kom som en følge av at oppdragsgivers ønsker for funksjonalitet endret seg gjennom prosessen. Dokument 2 - Produktdokumentasjon 2

Kravene ble ikke endret etter at denne planleggingsfasen var over, men på grunn av mengden funksjonalitet og prosjektets begrensede tidsperiode, ble det avtalt at en strek skulle settes i kravspesifikasjonen på det punkt det ble antatt at utviklingen ville ha nådd ved utgang av utviklingsfasen. Strekens funksjon var å definere den overkommelige mengde arbeid i prosjektet, og dermed sørge for at oppdragsgivers forventninger sto i samsvar med prosjektgruppens vurderinger. Strekens plassering ble valgt etter beregninger rundt antatt produksjonstid for de for de forskjellige modulene i produktet. Funksjonalitet under streken skulle implementeres hvis de øvrige kravene ble gjennomført og det gjensto nødvendig med tid. Streken omfattet kun bruker-delen av de funksjonelle-kravene og setter et skille i kravspesifikasjonen etter punkt nummer 8. 2.3 Samsvar mellom kravspesifikasjon og ferdig produkt Funksjonaliteten i produktet ble utviklet og implementert i den rekkefølgen den står oppført i kravspesifikasjonen. Når utviklingsfasen var ferdig hadde krav nummer 8 under bruker-delen blitt gjennomført og implementert i produktet. De påfølgende punktene (nr. 9 til og med nr. 12) befant seg under streken som var avtalt med oppdragsgiver og ettersom det ikke var avsatt mer tid til utvikling i arbeidsplanen ble ikke disse gjennomført. Kravene beskrevet under admin-delen av de funksjonelle-kravene var også implementert i produktet ved fullføring av utviklingsfasen. Siden for å lese kontaktinformasjon om organisasjonen (Ref. vedlegg 3, kravspesifikasjon punkt 12 ) ble også en del av det ferdige produktet til tross for at denne var plassert under streken avtalt med oppdragsgiver. Denne funksjonen samsvarer ikke med kravspesifikasjonen, da den avviker fra kravet om å benytte spørring mot XML-skjema for å hente ut informasjonen på siden. Mangel på tid førte til at alt innholdet ble hardkodet på siden istedet. Til tross for at denne funksjonaliteten ikke var en prioritert del av kravspesifikasjonen, ble det valgt å implementere denne fordi det hadde en praktisk nytteverdi for ansatte å ha tilgang til denne informasjonen. Alle de ikke-funksjonelle kravene samsvarer med kravspesifikasjonen. 2.4 Teknologi I prosjektbeskrivelsen hadde ikke Uno-X Automat nedsatt noen krav for hvilken teknologi som skulle benyttes i produktet. Derfor ble de teknologiske kravene vedtatt ut fra hva som virket hensiktsmessig for å oppnå den funksjonaliteten som var ønsket av oppdragsgiver. Følgende teknologi er brukt i produktet: HTML5 markup og CSS3. PHP Serverside applikasjonslogikk JavaScript klientside applikasjonslogikk. MySQL database. Vurdering som ble foretatt på valg av teknologi gikk ut på at oppdragsgiver allerede benyttet flere systemer basert på PHP og MySQL. Dette ga den fordelen at det var kompetanse på Dokument 2 - Produktdokumentasjon 3

dette i bedriften, slik at løsningen enkelt kunne driftes og videreutvikles internt. Samtidig var dette teknologi prosjektgruppen hadde mye erfaring med fra tidligere. Dokument 2 - Produktdokumentasjon 4

3. Produktets oppbygging og virkemåte 3.1 Funksjonalitet Automatnett er en løsning for deling av informasjon internt blant Uno-X Automat s ansatte. Hvilken funksjonalitet løsningen skulle inneholde ble definert i samarbeid med oppdragsgiver. Metoder som ble brukt i kartleggingen var samtaler med ansatte, testing av eksisterende løsning og UseCase-modellering. Figur 3.1 viser et overordnet UseCase-diagram for systemet. Uno-X Automat AS CMS 1.Innlogging med brukernavn og digipass <include> Basert på endret kravspesifikasjon pr. 25/1.2013 Oppdatert 5/2-2013 Oppdaterer brukerstatistikk <include> 4.Lese innhold 2.Lese brukerstatistikk 3.Publisere/ administrere innhold 5.Lese dokumenter 6.Publisere/ administrere dokumenter Bruker 7.Les/skriv i forum Admin 8.Søke på informasjon i løsningen 9.Publisere/ administrere bilder 10.Se på bilder i galleri 11.Se på dynamisk, statistisk data 12.Finne kontaktinfor masjon 14.Levere skjemaer elektronisk 13.Skrive ut informasjon 15.Lese en tråd i forum 17.Motta/lese beskjeder 16.Rediger poster i forum 19.Slette egne poster i forum 18.Sende beskjeder 20.Slette innhold i forum Figur 3.1 - Overordnet UseCasediagram for løsningen Dokument 2 - Produktdokumentasjon 5

Versjon 1.0 av Automatnett har følgende funksjonalitet: Publisere artikler /Lese artikler Publisere dokumenter / Lese eller laste ned dokumenter Redigere / slette dokumenter Søke i artikler og dokumenter Sende og motta meldinger i en meldingsinnboks Delta i forum Visning av brukerstatistikk for løsningen Sende inn elektroniske skjemaer (suksesshistorier, vannpeiling, bestilling) Oppslag på kontakter Se vedlegg 1 for brukermanual med detaljerte beskrivelser av funksjonaliteten. 3.2 Brukergrensesnitt Responsivt design Hovedfokus under utviklingen av nye Automatnett har vært på at løsningen skal fungere like bra på alle typer moderne enheter - smarttelefoner, nettbrett og PC er. Det må tas hensyn til en mengde størrelsesfaktorer og skjermstørrelser, i tillegg til forskjellige operativsystemer og nettlesere. Å lage produkter som fungerer prikkfritt med så mange variabler er ingen triviell oppgave, og problemstillingen er ikke unik for dette prosjektet. En løsning på problemet kalles responsivt design, og innebærer det lages én løsning som er adaptiv og tilpasser seg formatet til enheten som benyttes (Ref. 1). Det finnes flere HTML/CSS-rammeverk som kan være til nytte ved utvikling av responsive løsninger. Automatnett baserer seg på rammeverket «Twitter Bootstrap» som i sin tid ble laget av utviklerne av mikroblogg-tjenesten «Twitter» for å sørge for raskere koding og et konsistent design for deres løsninger. «Twitter Bootstrap» er åpen kildekode og det er mulig for alle å bruke rammeverket i kommersiell sammenheng, samt å gjøre egne endringer i koden. En ikke-responsiv løsning vil vises likt uavhengig av skjermstørrelse og enhet løsningen brukes på. Dette kan være problematisk da for eksempel interaktive elementer blir vanskelige å benytte på små skjermer, og teksten kan bli vanskelig å lese. Ofte ender utviklere opp med å lage separate løsninger for PC er og mobile enheter. Tanken bak responsivt design er at produktets innhold skal presenteres på optimalt vis på hver enkelt enhet, uten behov for å skrive separat kode. Dette kan føre til at noen elementer ser annerledes ut, og oppfører seg annerledes fra en enhet til en annen. Det er under utviklingen av Automatnett lagt stor vekt på gjenkjennelsesfaktoren mellom visningen på de forskjellige enhetene, slik at brukerne skal få følelsen av å jobbe i samme applikasjon, uavhengig av om de bruker en mobiltelefon eller en PC. Figur 3.2.1 og 3.2.2 viser hvordan Automatnett presenterer identisk informasjon på forskjellige enheter. Dokument 2 - Produktdokumentasjon 6

Figur 3.2.1 - nyhetsvisning på PC, mobiltelefon og nettbrett Dokument 2 - Produktdokumentasjon 7

Figur 3.2.2- Menyvalg på mobiltelefon og PC Det ble innledningsvis i utviklingsfasen brukt mye tid på å finne det optimale designet for løsningen. Se vedlegg 13 for et utvalg tidlige prototyper av løsningen. Universell utforming «Universell utforming» går ut på å lage løsninger som kan benyttes av alle brukere, uten behov for spesielle tilpasninger. Begrepet er ikke knyttet opp mot informasjonsteknologi spesielt, og vil være like aktuelt innen andre områder, som for eksempel arkitektur. Diskriminerings- og tilgjengelighetsloven, kunngjort 20.6.2008, pålegger offentlig og privat virksomhet å målrettet fremme universell utforming innenfor virksomheten. 1 i loven sier følgende: «Lovens formål er å fremme likestilling og likeverd, sikre like muligheter og rettigheter til samfunnsdeltakelse for alle, uavhengig av funksjonsevne, og hindre diskriminering på grunn av nedsatt funksjonevne. Loven skal bidra til nedbygging av samfunnsskapte funksjonshemmende barrierer og hindre at nye skapes.» (Ref. 2) Loven gjelder enheter hvis virksomhet er rettet mot almenheten, og brudd på plikten til universell utforming regnes som diskriminering. Uavhengig av om Automatnett faller inn under lovens bestemmelser har det for prosjektet, i samråd med oppdragsgiver, blitt vurdert som hensiktsmessig å følge utforme løsningen mest mulig universelt. Dokument 2 - Produktdokumentasjon 8

WCAG 2.0 Under utviklingen av Automatnett har WCAG 2.0-retningslinjer blitt fulgt for å besørge universell tilgjengelighet i sluttproduktet. WCAG-standarden (Web Content Accessibility Guidelines) er et sett bestående av 12 retningslinjer som benyttes for å sikre at web-løsninger har tilfredsstillende tilgjengelighet for brukere med og uten funksjonsnedsettelser. WCAG er utviklet av W3C (the World Wide Web Consortium), en organisasjon hvis primære aktivitet er å utvikle protokoller og retningslinjer for videre utvikling av World Wide Web. (Ref. 3) Automatnett oppfyller alle grunnkrav (nivå A) i WCAG-standarden der disse har relevans til produktet, og i tillegg oppfyller mange elementer kravene til nivå AA og AAA. Det er fokusert på følgende punkter for å optimalisere brukergrensesnittet for universell tilgjengelighet i henhold til WCAG-retningslinjer: Bilder publisert i løsningen har mulighet for innlegging av alternativ-tekst (alt-tag) Øvrig innhold ikke representert som tekst har mulighet for innlegging av tekst-beskrivelser Kontrast mellom skrift og bakgrunn er optimalisert. Kontrast vil på det meste av tekst være 7:1 som tilsvarer nivå AAA, men er noe lavere i menyene (5,7:1, nivå AA) Kontrastforhold mot ulike typer fargeblindhet. Mulighet for endring av skriftstørrelse ved bruk av tastatur-snarveier (ctrl + /-). Innholdet skalerer optimalt opptil 140% på de fleste nettlesere (gjelder ordinær PC) Responsivt design optimaliserer til en hver tid visning ut i fra skjermstørrelse, uten at informasjon eller struktur går tapt. Strukturering av menyer for lettfattelig navigering, for lav kognitiv belastning. Menyer har hovedsaklig kun 2 nivåer «Stifinner» gir bruker en visuell indikasjon på plassering i menystruktur. Stor avstand mellom navigerbare elementer for enkel betjening Forutsigbar sidestruktur som er felles for hele løsningen. Luftig design med kun nødvendig og relevant informasjon presentert Informative feilmeldinger til bruker ved feil inntastet brukerdata Informative feilmeldinger til bruker ved feil under prosessering av data Kompatibilitet med eksisterende teknologiske løsninger 3.3 Sentral teknologi Automatnett er utviklet som en ren web-applikasjon. Det vil si at produktet har mange likhetstrekk til en ordinær applikasjon installert på en mobil enhet eller en datamaskin. Web-applikasjonen kjøres i en nettleser og majoriteten av prosessering og lagring foretas på en sentral server ved hjelp av internett-kommunikasjon. En installert applikasjon, i motsetning foretar majoriteten av prosessering lokalt på brukerens maskin. En slik applikasjon må tilpasses en mengde forskjellige operativsystemer og enheter, mens web-applikasjonen er plattform-uavhengig. Dokument 2 - Produktdokumentasjon 9

Systemet er basert på stabil og velprøvd, samt lett tilgjengelig teknologi: HTML, CSS, PHP, MySQL og JavaScript. Dette medfører at sluttbrukeren skal kunne ta løsningen i bruk uten andre forutsetninger enn en rimelig oppdatert nettleser. Systemansvarlig vil kunne sette systemet i drift i et produksjonsmiljø som har installert en bransjestandard web-tjener, som for eksempel Apache. Presentasjonsdelen av Automatnett er skrevet i HTML og CSS, og følger de nyeste standardene for visning og presentasjon av informasjon i nettleser, HTML5 og CSS3. JavaScript brukes til klientside-validering av data som sendes fra bruker, samt visuelle virkemidler som dynamiske menyer og pop-up bokser med informasjon. Kjernen i systemet, applikasjonslogikken, kjøres på web-tjeneren og er programmert i PHP. Applikasjonslogikken er ansvarlig for å kommunisere mot databasen som inneholder systemets data. Informasjon brukeren skriver inn i skjemaer kan legges inn i databaser, og informasjon som allerede er lagret i systemet kan hentes ut, prosesseres og vises på skjermen. PHP er designet spesielt med tanke på å kunne lage dynamiske web-løsninger og har svært mye innebygget funksjonalitet tilpasset dette bruksområdet. Automatnett benytter en MySQL database til lagring av informasjon. Dette medfører at systemet må ha en MySQL-server installert og tilgjengelig. All informasjon i systemet, fra menystruktur til artikler og dokumenter er lagret i databasen. 3.4 Teknisk arkitektur Løsningen er utarbeidet med fokus på tydelig skille mellom presentasjons- og applikasjonslagene. Dette fører til ryddig kildekode, som vil forenkle senere endringer i både løsningens brukergrensesnitt og applikasjonslogikk. (Data til/fra nettleser) Presentasjonslogikk (HTML/PHP) Metodekall Liste av objekter Applikasjonslogikk (PHP) SQL-kommando Tabelldata Database Figur 3.4.1 - systemarkitektur Løsningen er objektorientert, noe som innebærer at applikasjonens datastrukturer er organisert i klasser som har sine respektive ansvarsområder og funksjonalitet. Alle operasjoner på data foregår ved hjelp av kall til disse klassene. Visningsfilene, som inneholder HTML-koden og som tolkes av nettleseren, inneholder minimalt med applikasjonslogikk. Dette begrenses til: Dokument 2 - Produktdokumentasjon 10

Oppretting av objekter Kall på metoder av objekter og klasser Utpakking av data som returneres fra databasen. Inkludering av filer Se vedlegg 5 for klassediagram for løsningen. Se vedlegg 6 for sekvensdiagrammer. Figur 3.4.2 viser eksempel på bruk av PHP-kode inni «HTML-markup» i presentasjons-øyemed. Et kall til «ArticleRegister»-klassen henter 10 nyhetsartikler fra databasen. De returnerte artiklene (i et array av artikkelobjekter) pakkes ut og listes på skjerm ved hjelp av en enkel løkke. Selv om applikasjonslogikken programmert i PHP tar seg av henting av informasjonen, foregår formatering av innholdet ved bruk av HTML/CSS Figur 3.4.2 - kodeeksempel. Bruk av PHP til utpakking av data for presentasjon. 3.5 Databasearkitektur Løsningen baserer seg på en MySQL-relasjonsdatabase. Alle tabeller benytter «innodb»-databasemotor. InnoDB er valgt da denne tilbyr høy dataintegritet gjennom bruk av fremmednøkler og transaksjoner. Databasen er designet ved hjelp av «MySQL Workbench». Dokument 2 - Produktdokumentasjon 11

Alle tabeller er på tredje normalform (3NF). Dette innebærer følgende: Alle verdier er «atomære» (1NF) Ingen attributter er partielt avhengige av primærnøkkelen (2NF) Ingen transitive funksjonelle avhengigheter Se vedlegg 8 for ER-diagram over løsningen. 3.6 Bruk av tredjeparts kode Majoriteten av koden som produktet bygger på er produsert av medlemmene i prosjektgruppen selv. Under følger en beskrivelse av kodeelementer som er hentet fra tredjepartsutviklere. All kode er benyttet med tillatelse. jquery-datepicker og placeholders.js publiseres med MIT-lisens, mens Twitter Bootstrap publiseres med Apache 2-lisens. Twitter Bootstrap Twitter bootstrap er et rammeverk for utvikling av responsive web-sider. Rammeverket består av CSS stilark og JavaScript / jquery-kode. Twitter inc 2012. (Ref. 4) jquery-datepicker Datovelger som viser en klikkbar kalender på skjermen i forbindelse med valg av datoer. Består av JavaScript / jquery-kode. The jquery foundation 2012. (Ref. 5) placeholders.js Internet Explorer 8 og 9 støtter ikke «placeholders» i HTML inputfelt. Denne koden benyttes for å aktivere tilsvarende funksjonalitet i disse nettleserne ved hjelp av JavaScript. James Allardice 2012. (Ref. 6) Dokument 2 - Produktdokumentasjon 12

4. Testing For å kvalitetssikre løsningen har det blitt foretatt en rekke tester. Disse testene tar for seg både den tekniske funksjonaliteten i løsningen, samt brukeropplevelsen. Ved å utføre disse testene har det vært mulig å avdekke om det var noe som måtte endres i løsningen, både funksjonelt og visuelt. Se vedlegg 9 for testrapport. 4.1 Enhetstest Enhetstesting har ikke blitt utført i form av skrevne tester med kontrolldata for hver enkelt enhet, men alle enheter (klasser, moduler eller metoder) har blitt testet av utvikler fortløpende i utviklingen. Det har blitt kontrollert at inn-data og ut-data stemmer overens med spesifikasjon, og at lagring er konsistent slik at når filer opprettes eller fjernes på server opprettes eller eventuelt fjernes oppføring i databasen. 4.2 Brukertest Det har blitt utført brukertester på ny og gammel løsning for å kartlegge problemområder, positive og negative aspekter, samt å måle hvor god den nye løsningen er sammenliknet med den eksisterende løsningen. Tester har blitt utført på ansatte ved Uno-X Automat samt medlemmer av prosjektgruppen og studenter ved Høgskolen i Oslo og Akershus. Det har blitt utført kvalitativ testing og kvantitativ testing. Kvalitativ testing: For å få tilbakemelding på produktet fra reelle brukere, ble det utført intervjuer og fritester av løsningen med ansatte fra Uno-X. Dette ble gjort for å kvalitetssikre løsningen, både med tanke på utseende, samt brukervennlighet. Testpersonene fikk oppgaver som var relatert til oppretting og sletting av innhold og til navigering i løsningen, men fikk spillerom til å utforske løsningen. Underveis i testingen ble det utført uformelle intervjuer, hvor testbruker fikk gi tilbakemeldinger på hvordan brukeropplevelsen var, og om det var noe testpersonene ville ha endret i løsningen. Produktet ble testet på personer i flere aldersgrupper, med forskjellige datakunnskaper. Kvantitativ testing: Direkte sammenlikning mellom ny og gammel løsning ble utført på testpersoner fra prosjektgruppen og studenter ved Høgskolen i Oslo og Akershus. Denne testen har hatt større fokus på tallfesting, for eksempel tidsbruk for å løse konkrete oppgaver, og antall klikk brukt. Dokument 2 - Produktdokumentasjon 13

4.3 Systemtest En systemtest har blitt utført for å teste at løsningen oppfyller de kravene som er satt i kravspesifikasjonen og UseCase-beskrivelsen. En systemtest sjekker om funksjonene i løsningen gjør det de skal utifra de input-dataene som blir gitt. Et eksempel på disse input-dataene kan være hva som skrives inn i feltene ved innlogging. Om det skrives inn riktig kombinasjon av brukernavn og passord skal brukeren logges inn. Skrives det inn feil brukernavn eller passord skal brukeren IKKE logges inn, men få en beskjed på skjermen om at brukernavn og/eller passord er feil. Utifra systemtesten som ble foretatt, kom det frem at løsningens funksjoner virket som de skulle. Alle funksjonene i løsningen ble testet. 4.4 Bruk av ilab i testing ilab er et rom på Høgskolen i Oslo og Akershus hvor det benyttes en datamaskin som har en eye-tracker tilkoblet. En eye-tracker er en maskin som registrerer brukerens øye-bevegelser på skjermen og lager video/bilder som viser disse bevegelsene. (Ref. testrapport, vedlegg 9.2). Ved å teste begge løsningene med en eye-tracker, er det lett å se hvilke elementer på skjermen som tiltrekker seg brukerens oppmerksomhet. Dette er en utmerket måte for å finne ut om løsningen har logisk struktur, og at de viktigste elementene på løsningen er det som fanger brukerens oppmerksomhet. Ved å sammenligne testresultatene fra de to løsningene, kan det på en enkel måte analyseres om den nye løsningen er mer logisk enn den gamle. ilab en ble benyttet i forbindelse med kvantitativ brukertesting av ny og gammel løsning. Figur 4.4.1 - Eyetracker - bestilling av vare i gammel løsning Dokument 2 - Produktdokumentasjon 14

Figur 4.4.2 - Eyetracker - bestilling av vare i ny løsning Figur 4.4.1 og Figur 4.4.2 viser blikk-fokus målt med Eyetracker på henholdsvis gammel og ny løsning... Oppsummering av testresultater fra ilab Resultatene fra testing på ilab gir informasjon om hvilke forbedringer som har blitt oppnådd gjennom utviklingen av den nye løsningen, sett i forhold til eksisterende løsning. Test av eksisterende løsning ble foretatt ved prosjektets oppstart og har også vært et viktig verktøy i forbindelse med innhenting av krav, og for å legge grunnlag for design av brukergrensesnittet på ny løsning. Test av ny løsning ble foretatt i testfasen etter at det meste av funksjonalitet var på plass. Ved sammenlikning av resultatene fra testene er det tydelige forbedringer å spore både med hensyn på tidsbruk og antall klikk. Disse resultatene forsterkes også av resultatene fra EyeTracker-testen, som viser klart mindre «blikk-vandring» ved bruk av den nye utgaven enn den gamle. Dette viser at endringer gjort i brukergrensesnitt og innholdsstruktur har hatt den effekten som var ønsket for prosjektet. Dokument 2 - Produktdokumentasjon 15

5. Metode og planlegging 5.1 Utviklingsmetode Feature-Driven-Development (Ref. 7) er valgt som utgangspunkt for utviklingsmetode i dette prosjektet. FDD er basert på anbefalte fremgangsmåter innen programutvikling. Hovedfokus er på å levere definerte, velfungerende software-komponenter innenfor korte iterasjoner / sprinter. Gangen i et FDD-prosjekt vil typisk være: Utvikle overordnet modell av system Lage liste over funksjonalitet Plan-by-feature (sette opp rekkefølge / prioritet) på funksjonaliteten Design-by-feature (plukke ut funksjonalitet som skal designes innen en iterasjon) Build-by-feature (programmere utvalgt funksjonalitet som er designet) De to siste punktene gjentas i iterasjoner. Det har i dette prosjektet blitt besluttet å benytte en egen utgave av FDD tilpasset prosjektets størrelse og type. I dette hovedprosjektet har det blitt jobbet UseCase-orientert, og det er derfor blitt valgt å basere prosjektet på UseCase-modellering i oppstartsfasen, fremfor domene-modellering, som er en av FDD s anbefalte fremgangsmåter. Videre har det blitt foretatt vurderinger som utelukker følgende andre anbefalte fremgangsmåter, som etter prosjektgruppens vurdering, passer bedre for større prosjekter: Individual Class Ownership: forskjellige stykker eller grupperinger av koden er tildelt en enkelt eier. Eieren er ansvarlig for konsistens, ytelse, og konseptuell integritet av klassen. Feature Teams: Gruppebasert samarbeid om å lage funksjonalitet i sprinter. Begrunnelse for tilpasninger av FDD-modellen er som følger: Produktet oppdragsgiver ønsket seg var ved innledende møter klart definert med hensyn på ønsket funksjonalitet. Det eksisterte allerede en løsning innenfor området, så det virket mer nyttig å fokusere på endring/forbedring av funksjonalitet enn å utforske domenet på nytt. «Individual Class Ownership» og «Feature Teams» ble vurdert som mer hensiktsmessig benyttet i større prosjekter med flere ansatte, og det ble vurdert at det i dette tilfellet ville generere betydelige mengder dokumentasjon og byråkrati, og mindre fokus på utvikling av produktet. Prosjektgruppens endringer resulterer i en lettvektsmodell, som i høy grad er «feature driven», med fokus på å kunne levere fungerende programkode i deler, med stor fokus på produktet og kun det nødvendigste av dokumentasjon. Dokument 2 - Produktdokumentasjon 16

Prosjektets nedskalerte versjon av FDD ser slik ut: Forprosjekt: Innhente krav til løsning lage prioritert liste over funksjonalitet på grunnlag av krav lage overordnet UseCase for løsningen Per iterasjon: plukke ut overkommelig mengde funksjonalitet for en iterasjon arbeidsfordeling design av funksjonalitet (utdype usecase) programmere funksjonalitet test/gjennomgang av kode levere ferdig funksjonalitet iterasjoner Planleggingsfasen: -Kravinnhenting -Lage prioritert kravliste -Lage overordnet UseCase for løsning Utviklingsfasen: -Plukke ut funksjonalitet -Fordele arbeid -Design av funksjonalitet -Programmere funksjonalitet -Test gjennomgang av kode -Levere ferdig funksjonalitet Testfasen: -Systemtest -Brukertest -Akseptansetest Figur 5.1 - Illustrasjon av utviklingsmetode 5.2 Utviklingsmiljø Utvikling av ny funksjonalitet har foregått ved hjelp av XAMPP s AMP-stack for Mac. Nyutviklet funksjonalitet i beta-testing har underveis vært tilgjengelig via en webserver betjent av «domeneshop.no». Dokument 2 - Produktdokumentasjon 17

Daglig backup til ekstern disk Lokale maskiner benyttet under utviklingen XAMPP SVN XAMPP SVN XAMPP SVN XAMPP SVN SVN-repository (assembla.com) SVN = Subversion Versjonskontroll XAMPP = Apache, MySQL, PHP-stack Mac OS X (localhost) LAMP = Linux, Apache, MySQL, PHP-stack WEB-server for testing LAMP (domeneshop.no) Figur 5.2 - Illustrasjon av utviklingsmiljø 5.3 Backup Tap av data har vært en av mange risikofaktorer i hovedprosjektet. Det har underveis i prosjektet blitt tatt backup daglig til ekstern harddisk av all kildekode. Dette har blitt gjort automatisk ved hjelp av Apple Time Machine som tar inkrementell backup av filer slik at de kan gjenopprettes på et senere tidspunkt hvis det skulle være behov for det. Dropbox er blitt benyttet til lagring av dokumentasjon i prosjektet og har også mekanismer for backup. Dropbox sikkerhetskopierer filene automatisk ved endringer. Den primære kopien som er på datamaskinens harddisk er synkronisert på nettet og en kopi av denne er så lagret for sikkerhet skyld. Dropbox tar også backup av alle slettede og endrede filer. Alle filer som synkroniseres med Dropbox blir kryptert og lagret sikkert på Amazon Simple Storage Service (S3) over flere datasentre. 5.4 Versjonskontroll «Subversion / SVN» (Ref. 8) har blitt benyttet som versjonkontrollsystem for å holde rede på utviklingshistorien til hovedprosjektets kildekode. «Versions for Mac OSX» har blitt benyttet som grafisk interface for SVN, for å forenkle samhandlingen med systemet som ellers er kommandolinje-basert. Dokument 2 - Produktdokumentasjon 18

Et sentralt SVN-repository har vært hostet på «assembla.com» som er en gratis lagringstjeneste for SVN/GIT-repositories. 5.5 Risikovurdering Det har i prosjektets planleggingsfase blitt foretatt en risikovurdering av prosjektet. Denne har blitt oppdatert ved oppstart av sprinter og faser. Se vedlegg 4 for risikoplan for prosjektet. Dokument 2 - Produktdokumentasjon 19