Innledning. Analysedelen i prosjektet tar for seg ulike javascript rammeverk, deres kvaliteter og svakheter vurdert opp mot hverandre.

Størrelse: px
Begynne med side:

Download "Innledning. Analysedelen i prosjektet tar for seg ulike javascript rammeverk, deres kvaliteter og svakheter vurdert opp mot hverandre."

Transkript

1 Page 1 of 139

2 Page 2 of 139

3 Innledning PROSJEKT NR. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Brukeropplevelse og front-end teknologi PROSJEKTDELTAKERE Helene Kristiansen S Kim Meisingset S Henrik Volden S Vibeke Johnsen S TILGJENGELIGHET Åpen DATO 27 Mai 2014 ANTALL SIDER / BILAG 139 / 42 INTERN VEILEDER Ynge Lindsjørn Telefon: Telefaks: OPPDRAGSGIVER Accenture KONTAKTPERSON Henning Engen SAMMENDRAG Analysedelen i prosjektet tar for seg ulike javascript rammeverk, deres kvaliteter og svakheter vurdert opp mot hverandre. Prototypen gir en mulig løsning på to problemstillinger for siden «Min bedrift 2.0» på Telenor. Arbeidsmetode, visualiseringsteknikker, spørreundersøkelse og brukertester vil bli fremstilt i rapporten og er en begrunnelse for designvalg. 3 STIKKORD Front-end rammeverk Analyse Prototype Page 3 of 139

4 Innledning Forord Som avslutning av bachelorgraden på HIOA, har vi i en gruppe bestående av fire studenter utarbeidet et hovedprosjekt. Hovedprosjektet skal gi oss en viss forståelse av hvordan det er å jobbe med et prosjekt, som er relevant i forhold til arbeidslivet. Her vil vi få innsikt i hvordan det er å jobbe i IT-bransjen, og vi vil tilegne oss fagkunnskap som kan gi oss fortrinn i et konkurransepreget arbeidsmarked. Gruppen tok selv kontakt med oppdragsgiver Accenture, og vi satt pris på at vi fikk mulighet til å utvikle noe for dem. Sluttproduktet skal ha en nytteverdi for oppdragsgiver, og vi skal levere dokumentasjon av prosess og resultat. Relevant forskning og faglitteratur skal også være presentert som en del av dokumentasjonen. Hovedargumentasjonen for valget av Accenture var at vi fikk mulighet til å kartlegge et produkt som skal brukes av mange, og utforske nye teknologier, samt arbeide mot en reell målgruppe. Oppgaven ble også tilpasset de kvalifikasjonene prosjektgruppa hadde fra studiene. Å jobbe med denne prosjektoppgaven vil gi oss en ny kompetanse, og mulighet til å arbeide med et tema som er svært aktuelt for vår studieretning. Dette dokumentet er i hovedsak ment for sensor og oppdragsgiver. Rapporten er også tenkt for personer som skal implementere eller videreutvikle systemet Min Bedrift 2.0. Prosjektrapporten krever lite bakgrunnskompetanse innen IT, men noen IT-relaterte terminologier fremtrer i rapporten. Ønsker leseren en mer grundig og detaljert beskrivelse av Min Bedrift 2.0, finner man denne i produktbeskrivelsen. Vi vil gjerne rette en takk til vår oppdragsgiver Accenture, ved Henning Engen som veileder med god oppfølging og støtte. Vi vil også takke Yngve Lindsjørn som veileder ved Høgskolen i Oslo og Akershus (HiOA). Page 4 of 139

5 Innledning Sammendrag Telenor baserer seg på nettbaserte tjenester, både for enkeltpersoner og bedrifter. På grunn av lav konversjonsrate (forholdet mellom antall besøkende som utførte en ønsket handling) på sin bedriftsside, har Telenor bestemt seg for å fornye siden sin, og gjøre denne mer brukervennlig. Accenture har fått i oppdrag å lage en ny front-end løsning til denne siden, og det er gjennom dem vi har fått dette prosjektet til vår bacheloroppgave. I denne rapporten skal vi presentere både en analyse av fem rammeverk og implementasjon av en prototype vi har utviklet.vi introduserer oppbyggingen og de valg som er tatt for å oppnå de funksjonene som har vært ønskelig å ha med på nettsiden. Gruppen har ut i fra problemstillingen satt krav og mål til oppgaven. Selve oppgaven fra Accenture baserte seg mest på analysen av rammeverk, og hviket som egnet seg best. De hadde få ønsker til selve utformingen av løsningen. Men fra Høgskolen i Oslo og Akershus hadde vi som krav til bacheloroppgaven at vi måtte utforme en reell løsning, som blant annet en nettside. Vi valgte derfor å definere en problemstilling, sette opp kravspesifikasjoner, og fastsette hvilke funksjoner som skulle være med i utformingen. Dette for å få en intensjon på hvordan sluttresutatet skulle se ut. Problemstilling: Hvordan kan et moderne web-rammeverk være med på å bedre brukervennligheten, på en web-applikasjon? Videre tar rapporten for seg hvordan vi har analysert ulike rammevert, og hvordan vi kom frem til det endelige resultatet. Deretter viser vi utformingen av både low-fidelity og highfidelity prototyper. I rapporten finnes også en spørreundersøkelse som viser forskjellige visualiseringer, og en prototype av selve nettsiden. Prototypen er offentlig og inneholder derfor ikke Telenor sine logoer selv om problemstillingen er reell for deres nettsider. Brukervennlighet er et viktig begrep i vår rapport. Begge prototypene våre baserer seg på hva Page 5 of 139

6 Innledning som er viktig for brukerne, og her utdyper vi de ulike underpunktene videre. Vi har prøvd å få en viss forståelse på hvem brukerne er og brukernes behov. Dette kan gi oss et bedre utganspunkt for å lage et vellykket produkt. Det presenteres også betydningsfulle elementer for utviklingen, da spesielt med tanke på de forskjellige oppgavene som sluttproduktet skal vise. Brukertester er gjort av begge prototypene, både ved en kvantitativ og en kvalitativ undersøkelse. Rapporten er delt inn i fem deler: 1. Kravspesifikasjoner 2. Prosessdokumentasjon 3. Produktdokumentasjon 4. Testdokumentasjon 5. Konklusjon Nederst i rapporten finner du vedlegg. De er ment som et oppslag og attester, hvor du kan finne mer informasjon om forskjellige deler av rapporten. Page 6 of 139

7 Innledning Innholdsfortegnelse 1.0 Innledning Presentasjon av oppdragsgiver Beskrivelse av prosjektet Målsetninger for Telenor Målsetninger for Accenture Problemstilling Mål og rammebetingelser Kravspesifikasjoner Oppdragsgiver krav Funksjonelle krav Tekniske krav Universell Utforming Ikke Funksjonelle krav Eksterne krav Dokumentasjonskrav Prosessrapport Dagens situasjon Dokumentasjon & planlegging Styringsdokumenter Risikoplanlegging Samarbeidsavtale Prosesskontroll Scrum Jira Dropbox Facebook Alternative metodikker Utviklingsprosessen Arbeidsprosessen Jira Page 7 of 139

8 Innledning Sprint 0: Behovs- & løsningsbeskrivelsesfase Sprint 1-4: Iterativ konstruksjonsfase Sprint Arbeidet med Scrum Teknikker Utfordringer Personlig utfordringer Faglig utfordringer Forhold til arbeidsgiver Accenture Endringer i kravspesifikasjoner Produktrapport Min Bedrift Funksjonaliteter Analyse Analyse av rammeverk Valg av rammeverk Diagrammer Aktivitetsdiagram Use case Universell Utforming Implementering Programmeringsspråk Design Database design Teknisk løsning Mulige utvidelse av Min Bedrift Evaluering av løsning og prosjekt Evaluering av teknisk løsning Evaluering av prosjektgjennomføring Oppdragsgivers evaluering av løsningen Testdokumentasjon Spørreundersøkelse Page 8 of 139

9 Innledning 6.2 Brukertest Brukerveiledning Konklusjon Løsning i henhold til problemstilling Litteraturliste Figurliste Vedlegg Vedlegg 1: Visualiseringer Vedlegg 2: Teknikker Vedlegg 3: Scrum Vedlegg 4: Alternative metodikker Vedlegg 5: Aktivitetsdiagram Vedlegg 6: Use Case beskrivelser Vedlegg 7: Resultater spørreundersøkelse Vedlegg 8: Brukertest Vedlegg 9: Personvernserklæring Page 9 of 139

10 Innledning 1.0 Innledning Denne bachelor oppgaven er skrevet av fire personer; Vibeke Johnson, Helene Kristiansen, Kim Meisingset og Henrik Volden. Vi studerer alle Anvendt datateknologi på Høyskolen i Oslo og Akershus. Medlemmene har vært en gruppe også på tidligere prosjekter siden høsten 2012 og samarbeidet har fungert godt. Grunnen til at gruppa fungerer bra er at vi har ulike egenskaper og forskjellige interessepunkter. Det er enkelt å fordele ansvarsområdene da vi har selvregulerende posisjoner i gruppa som entreprenøren, administratoren, produsenten og integratoren. 1.1 Presentasjon av oppdragsgiver Accenture er en bedrift som tilbyr tjenester innenfor rådgivning, teknologi og outsourcing. Firmaet har per dags dato rundt 1000 ansatte i Norge, og over ansatte i mer enn 120 land (Accenture, 2014). Ved hjelp av sin brede kompetanse innenfor alle bransje- og forretningsfunksjoner, hjelper Accenture i samarbeid med sine kunder, å utvikle produkter av god kvalitet. Accenture leier ut konsulenter til ulike prosjekter i mange forskjellige bedrifter både nasjonalt og globalt Beskrivelse av prosjektet Ansatte fra Accenture er leid inn som konsulenter på et prosjekt for Telenor, som går ut på å ad id i B d i 2 0. i b d i 2 0 da v av d væ d id i B d i D id m b d i d i T og skal fungere som en side hvor kunden selv kan gå inn og hente ønsket informasjon, samt endre på abonnementer. Dette halvåret har vi jobbet gjennom Accenture med å levere en prototype på en front-end løsning for Telenor sin bedriftside. Gruppen var ikke med på å utvikle den endelige løsningen, da dette er et stort prosjekt over et lengre tidsløp, men jobbet parallellt med Accentures team på Telenor. Oppgaven vår består av to deler som begge har fokus mot denne front-end løsning. Den ene delen var å lage en analyse av ulike front-end rammeverk, med fokus på enkelte kriterier gruppen selv kom frem til. Den andre delen gikk ut på å lage en prototype. Denne prototypen skulle bruke et av rammeverkene som ble vurdert i analysen. Prototypen Page 10 of 139

11 Innledning skulle fokusere på noen bestemte funksjoner og krav som gruppen selv valgte. Etter et møte med User Experience teamet til Accenture, fikk vi klarhet i hvilke spesifikasjoner som Telenor sine kunder var mest opptatt av. Med informasjon fra dette møte valgte gruppen fokusområde for prototypens funksjoner Målsetninger for Telenor Telenor ønsker ut fra Accenture sitt prosjekt å oppnå en økning på andel brukere på nettsiden «Min bedrift 2.0». De ønsker i større grad å oppnå at bedriftene benytter nettsiden, fremfor å ringe inn til support hos Telenor, for å utføre oppgaver de også kan utføre på nettsiden Målsetninger for Accenture Accenture har et tett partnerskap med Telenor hvor blant annet videreutvikling av Telenor sine webløsninger er i fokus. Slik som situasjonen er i dag, jobber Telenor med en moderniseringsprosess, hvor flere digitale kanalsystemer (front end løsninger) skal få et a i ø D da m Acc a vi E m d i B d i 2 0, hv a b v m d b i m, ø m d m d teknologi som f.eks. JavaScript-rammeverket Angular.js, HTML5 og CSS3 (Porto, 2013). Accentures har tidlig jobbet mye med prosjekter rettet mot back-end, men ønsker nå å også jobbe med front-end rettede prosjekter. Accenture har som målsetning å utføre et slikt prosjekt etter kundens standard og også jobbe med fremtidige front-end prosjekter for Telenor. Page 11 of 139

12 Innledning 1.2 Problemstilling Hvordan kan et moderne web-rammeverk være med på å bedre brukervennligheten, på en web-applikasjon? Begrepsavklaring fra problemstilling - Rammeverk: Rammeverk er bygget på en reell eller konsept basert struktur. Den fungerer som en oppskrift på hvordan man stegvis skal kunne utvide strukturen videre. I datasystemer er ofte rammeverket en lagdelt struktur som viser til hvilke programmer som blir brukt i prosjektet (Margaret Rouse, 2005a). Vi har i vår oppgave benyttet oss av ulike programmeringsverktøy, og arbeidet med disse for å utforme det endelige resultatet, som vist i produktrapporten. - Front-end: Front-end løsning forklarer hvordan brukeren (menneske eller et program) karakterisere programgrensesnitt og tjenester i forhold til tidligere grensesnitt. Med en frontend løsning mener vi hvordan brukeren kommuniserer direkte med programmet (Margaret Rouse, 2005b). For eksempel når vi skal bestille mobiltjenester på nett, og bruker er direkte inne på nettsiden for å gjør dette selv. Back-end løsning er det som skjer bak kulissene, som bruker ikke samhandler med direkte, og som kobler sammen front-end og back-end aktivitetene. - Brukervennlighet: Med brukervennlighet som også er omtalt som brukskvalitet mener vi hvor lett det er å lære seg å bruke nettsiden. Nettsiden skal også være effektiv, behagelig å bruke, lett å huske over tid og minimalisere sjansene for feilbruk (Sandnes, 2011b). Standarden ISO definerer brukervennlighet slik (fritt oversatt): At et produkt kan brukes av bestemte brukere for å oppnå et spesifikt mål med effektivitet og tilfredshet i brukskonteksten (Sandnes, 2011a). Page 12 of 139

13 Innledning 1.3 Mål og rammebetingelser Målet med denne oppgaven er å produsere en analyse bestående av 5 front-end rammeverk, og videre utvikle en prototype med det rammeverket som oppnådde høyest poengsum på analysen. Vi skal også definere ønskede funksjoner som kan bidra til bedre brukervennlighet. Ved hjelp av prototypen skal vi teste hvordan dette rammeverket fungerer i praksis og brukerteste denne på de ulike funksjonene og design. Målet er å finne ut om rammeverket valgt er godt egnet for front-end rettet utvikling for bedrifter, og eventuelt hva som fungerer bra og mindre bra med rammeverket. Page 13 of 139

14 Kravspesifikasjon 2.0 Kravspesifikasjoner Kravspesifikasjoner er å definere sammen med oppdragsgiver hvilket type krav som gjelder for systemet som skal lages. Det er de krav som kartlegger rammer og retningslinjer som er gjeldende for prosjektet. Kravspesifikasjonene fungerer som et styringsdokument på hva som skal utføres, hvordan det skal virke, og hvordan sluttresultatet skal se ut. Dette gjelder krav til funksjonelle og ikke-funksjonelle krav, arbeidsprosess og kvalitetssikring. 2.1 Oppdragsgiver krav Ettersom oppgaven fra arbeidsgiver er litt åpen ble det ikke utformet noen bestemt kravspesifikasjon, men heller noen punkter som gruppen kunne ta utgangspunktet i, da problemstillingen ble utformet. Gjennomføre i samarbeid med prosjektet Min Bedrift 2.0, en analyse av hvilke utviklingsspråk og tekniske rammeverk som løser best utvalgte behov sett fra brukerens ståsted. Studentene vil sammen med User Experience teamet fra Min Bedrift 2.0 komme frem til en til to typiske funksjonaliteter som brukeren har behov for i dagens webgrensesnitt. Og benytte dette som målepunkt igjennom oppgaven for å vurdere ulike teknologiløsninger eller prototype/utvikle selv nytt konsept (F.eks. scrolling av lange lister og kontinuerlig feedback til bruker). Vurderinger av løsningen skal ta for seg funksjonelle og ikke-funksjonelle krav. Utover disse står studentene fritt til å trekke inn andre kriterier de mener er relevante. 2.2 Funksjonelle krav De funksjonelle kravene bestemmer hvordan systemet skal oppføre seg, hva vi kan forvente av systemet. Funksjonelle krav skal kunne vise til hva fremtidens systemer vil akseptere, og hvilke inndata som igjen vil produsere et resultat på disse utdataene. Vi har i vår oppgave delt opp de funksjonelle kravene i tre forskjellige kategorier. Page 14 of 139

15 Kravspesifikasjon Brukerens krav - Hovedkravet for nettsiden er at kundene skal kunne sjekke abonnementene, opprette nye abonnementer og sjekke fakturaer. - Kundene skal kunne se fakturaer fra de to siste årene. - Kundene skal enkelt kunne lære seg å bruke nettsiden. - Kundene skal kunne bestille nytt abonnement ved å velge ferdig utfylte maler for abonnementer eller et egendefinert skjema. Administrative krav - Kundene skal få opp riktig abonnement når de velger forhåndsutfylt abonnement. - Kundene skal få en god oversikt over forbruket til alle ansatte i bedriften for den aktuelle måneden. Systemkrav - Feilmeldinger skal dukke opp ved feil i systemet eller ved inntasting av feil informasjon, som for eksempel ved å ikke taste inn riktig dato. - Kundene skal kunne få en bekreftelse på at de har utført en handling på nettsiden. Som evt. bestille nytt abonnement, eller slette et abonnement. - Det skal være mulig å komme tilbake til hovedsiden når man trykker på bedriftens ikon og på hjem knappen. - All bestillingsinformasjon skal kunne lagres i en database som tilhører systemet. - Fakturaer skal vises som et PDF dokument. Page 15 of 139

16 Kravspesifikasjon 2.3 Tekniske krav - Nettsiden skal utvikles med et moderne rammeverk. - Som et utviklingsverktøy skal det brukes javascript rammeverk som baserer seg på MVC (Model View Controller) prinsippet. - Datalagring skal foregå i en MySQL database. 2.4 Universell Utforming Vi har prøvd å oppfylle kravene i WCAG og sett på de fleste retningslinjene. Vi har ikke fulgt opp alle kravene men prøvd å gjennomføre med grunnlag av vår kompetanse. De datatekniske løsningene vi har klart å implementere er: Siden inneholder informasjon for Telenor sine bedrifts kunder. Nettsiden er blitt skrevet veldig enkelt og oversiktlig slik at flest mulig brukergrupper kan forstå teksten (W3C, 2008)(retningslinje 3.1). Svart skrift på hvit bakgrunn gjør at svarte fargen reflekteres veldig godt. Det blir en veldig god kombinasjon mellom bakgrunnen og teksten (W3C, 2008)(Retningslinje 1.4.6). Oversiktlig plassering av knapper midt på siden og bruk av farger. Riktig bruk av overskrifter og valg av skrifttype gjør siden mer brukervennlig. Vi har ikke tatt med flash på websiden, for dette kan virke forstyrrende på bruker. Page 16 of 139

17 Kravspesifikasjon 2.5 Ikke Funksjonelle krav Ikke- funksjonelle krav gir en bedre beskrivelse av hvordan ytelsen av systemet fungerer. Det forklarer egenskapene til systemet ytterligere, og spesifiserer alle de øvrige krav som ikke dekkes av de funksjonelle kravene. For å bedømme vilkårene for driften av et system, har vi delt de inn med underkategorier som skal utdypes. Produktkrav - Brukervennlighet går under kategorien Usability Requirements: Nettsiden skal være brukervennlig, det vil si at det skal være lett å lære seg å bruke. Siden skal gi umiddelbare tilbakemeldinger på brukers handlinger, og gi gode tilbakemeldinger på brukers valg. - Ytelsekrav går under kategorien Efficiency Requirement: Systemet skal ha stor nok lagringskapasitet i databasen slik at det ikke blir tregt under bestilling av nye mobil abonnementer, sjekking av faktura osv. uansett stor pågang/ belastning. - Sikkerhetskrav går under kategorien Security Requirement: Nettsiden skal være sikker å bruke, ved å ha passord og brukernavn ved innlogging. Passe på at sensitiv informasjon ikke kommer på avveie. - Pålitelighet går under kategorien Dependaility Requirements: Nettsiden skal sjekkes for eventuelle feil ved å for eksempel se på tiden det tar mellom feil som oppstår i systemet. Om systemet feiler mye er dette et tegn på at systemet ikke er pålitelig i forhold til bruker. Se om systemet skal være tilgjengelig for bruker 24 timer i døgnet eller om det er begrenset tilgang for bruker. Page 17 of 139

18 Kravspesifikasjon Organisatoriske krav - Nettsiden skal følge Telenor sine standarder. - Nettsiden skal være klar for levering til angitt tidspunkt. - Nettsiden skal fungere på forskjellige plattformer/operativsystemer. - Nettsiden skal fungere i ulike nettleserne. - Nettsiden må følge datatilsynet regler. Eksterne krav - Lovgivende krav går under Legislative Requirements: Se til at nettsiden vår tilfredsstiller de lover og regler som er gjeldende for nettsider. Alle nye IKT-løsninger som er utviklet skal være universelt utformet fra 1.Juli 2014 (difi, 2013). - All sensitiv informasjon skal kunne krypteres under og etter bestilling, eller endringer. - Estetiske krav: Her ser vi om nettsiden tilfredsstiller de estetiske kravene som WCAG (Web Content Accessability Guidelines) har satt. Her kan vi evaluere kodene og sjekke denne opp mot standarder som WCAG har, og sørge for at koden er godkjent. Deretter kan vi teste om systemet fungerer som det skal ved å utføre ulike operasjoner. Dette hjelper oss å evaluere hvor godt de ulike funksjonene på nettsiden fungerer i praksis. Page 18 of 139

19 Kravspesifikasjon 2.6 Dokumentasjonskrav Gruppa skal kunne dokumentere underveis og i endelig rapport hvordan prosjektet har blitt utført. Gjennom programmet Jira føres timeantall og hvem som har fått tildelt de ulike oppgavene. Her planlegges prosjektets fremgang og det føres en logg på hvilke oppgaver som er utført. Det skal dokumenteres gjennom kravspesifikasjoner, prosessdokumentasjon, produktdokumentasjon, testresultater og styringsdokumenter. Gruppa har også brukt en prosjektdagbok som et styringsdokument til prosjektet. Her har vi skrevet om hva vi har jobbet med, hvilke utfordringer vi har møtt på, og hva vi eventuelt har trengt hjelp med av de andre gruppemedlemmene. For å se fullstendig prosjektdagbok se gruppens dokumentasjons side på nett. Page 19 of 139

20 Prosessrapport 3. 0 Prosessrapport Prosess kan defineres som et sett relaterte eller samhandlende aktiviteter som gjør om innsats til produksjon (NETCOACH, 2011) Prosessrapporten viser til utviklingen av systemet og hvordan vi har jobbet sammen for å oppnå det endelige resultatet som vist i produktrapporten. I prosessrapporten er aktiviteter gruppert sammen for å identifisere og avgrense ulike prosesser. Dette gjør at en oppdragsgiver kan fokusere på resultatene for hver gitt aktivitet (NETCOACH, 2011). Rapporten viser også systemets bruksområde, metodikker og arbeidsmetoder som er tatt i bruk under utviklingsprosessen. 3.1 Oppdragsgivers forventninger Accenture fungerer under bacheloroppgaven som oppdragsgiver. Oppgaven strekker seg mot et, og eventuelt flere prosjekter Accenture skal utføre for Telenor og andre fremtidige kunder. Accenture er per dags dato veldig flinke på back-end løsninger og jobber for tiden med å forbedre sitt kunnskapsnivå på front-end løsninger. Oppdragsgiver forventer å motta en analyse av rammeverk som eventuelt kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. I tillegg forventer de å motta en prototype med noen bestemte funksjoner (funksjonene er bestemt av gruppen selv). Accenture forventer også oppdateringer om fremdrift underveis i prosjektet. De ønsker også to fremføringer, en ved prosjektstart om hva som skal utføres og en ved prosjektets slutt om hva som faktisk har blitt utført Dagens situasjon «Min bedrift 2.0» er det som omtales for den nye front end løsningen Accenture holder på å utvikle for Telenor nå. Tidligere løsning har vært tungvindt og vanskelig for brukere å benytte for å utføre operasjoner slik som å hente ut fakturaer eller se på oversikten over samtlige abonnementer. Derfor trenger denne siden en forbedring, slik at flere benytter siden. Per dags dato er det mange som benytter tjenester som kundestøtten til Telenor, istedenfor å finne/endre informasjon selv gjennom nettsiden. Ønsket til Telenor med en oppgradering av Page 20 of 139

21 Prosessrapport front-end løsningen, er at flere bedriftskunder skal lettere og enklere finne frem på nettsiden og benytte denne til å utføre ønskede operasjoner, istedenfor å ringe kundestøtte. 3.2 Dokumentasjon & planlegging Gruppen jobbet i starten mye med prosjektplanlegging og justeringer av tidsestimeringer. Det ble også opprettet styringsdokumenter som skulle hjelpe gruppen med kontinuerlig jobbing hele veien. I den sammenheng ble det laget en milepælsplan hvor det var enkelt å sammenligne utførte oppgaver opp mot milepælene, og hvor langt vi bør ha kommet på prosjektet. Det startet bra med forprosjektsrapporten, men en så tidlig at planleggingen av milepælene hadde undervurdert tiden det faktisk tok å utføre analysen og lage prototypen. Det krevde mer tid enn vi hadde beregnet å lære seg rammeverket Angular.js. Derfor lå vi midtveis i prosjektet lenger bak en tidligere estimert. Gruppen hadde regnet ut at brukertesten av den ferdige prototypen skulle være ferdig 24. Mars, og etter dette skulle vi kun jobbe med småjusteringer og rapporten. Da gruppen så at den første tidsplanleggingen sprakk, valgte vi å heller jobbe parallelt med rapporten og prototypen. Dette førte til at den siste måneden som var satt av til rapportskriving kunne brukes til å også jobbe litt med brukertest og prototype, samtidig som rapporten ble skrevet. På denne måten klarte gruppen å hente seg inn igjen i prosjektet og ferdigstille oppgaven. Gruppen var også heldige under arbeidet hele veien med lite sykdom og mangel på oppmøte. Det var kun ved noen enkle gruppemøter at noen av medlemmene har vært syke og i de tilfellene har det blitt gitt beskjed til resten av gruppen. Dersom en ser tilbake på planleggingen av milepælene vil vi også si at planleggingen var litt dårlig med tanke på prototypen og rapporten. Milepælene viste tydelig at rapporten skulle skrives på slutten, men etter som gruppen måtte endre på dette, fikk en erfare å skrive oppgaven samtidig som arbeidet ble gjort. Dette har faktisk vært en bedre løsning enn vi vurderte under planleggingen, da det ga gruppen mulighet til å dokumentere mens ting ble utført. På denne måten fikk gruppen dokumentert nødvendig informasjon mens det skjedde, istedenfor å huske tilbake i tid for å dokumentere. Arbeidet ble også fordelt mer over tid og ga gruppen mulighet til å variere arbeidsoppgaver i større grad. Page 21 of 139

22 Prosessrapport Styringsdokumenter Milepæler 24. januar Forprosjektrapport 15. Februar Ferdig med analyse av kodespråk/rammeverk 20. Mars- Prototype ferdig og brukertester påbegynt 24. Mars Ferdig med brukertester 7. April Prototype ferdig etter endringer 22. April Rapport ferdig skrevet. 27. Mai Innlevering rapport og prototype juni - fremføring Risikoplanlegging Det var viktig ved prosjektstart å sørge for god planlegging slik at gjennomføringen av prosjektet var mulig. Derfor ble det laget en risikoplan. Denne planen gir da en vurdering av risikoen og sannsynligheten for at noe skjer, hvordan vi kan forebygge dette og eventuelle tiltak som må gjøres hvis det oppstår slike problemer. Page 22 of 139

23 Prosessrapport Type risiko Konsekvens (skala fra 0-10) Sannsynlighet i prosent Risikopoeng Forebyggende tiltak Tiltak hvis problem oppstår Sykdom maks 3dager Sykdom 1uke eller mer Sterk uenighet Gruppemedlemmer kommer ikke overens Stor mangel på kompetanse Engruppeme dlem slutter på studiet Tapt materiale Mangel på engasjement Medlemmet gjør ikke arbeidsoppga vene sine Finner ikke arbeidsplass 5 0,40 2,0 Alle passer på å få nok søvn, trening og kle seg etter været. 8 0,30 2,4 Alle passer på å få nok søvn, trening og kle seg etter været. 7 0,35 2,45 Legge klare planer, si ifra tidlig hvis man er uenig 4 0,10 0,4 Bruke tid på å bli kjent, ta pauser når fokuset på arbeidet blir dårlig 7 0,25 1,75 Begrense visjonene for arbeidet 8 0,10 0,80 Være hyggelige mot hverandre. 7 0,20 1,4 Dropbox. Flere backupbarrierer 6 0,50 3 Sosiale aktiviteter utenom gruppearbeid 6 0,25 1,5 Planlegge godt. Være klar til å levere god tid i forveien 2 0,5 1 Booke rom i lang tid fremover. Omfordele arbeidsoppgaver, evt flytte oppgaver til senere frist Omfordele arbeidsoppgaver, snakke med veileder. Avgjørelser i demokrati, spørre veileder hvis det er noe alvorlig Gruppemedlemmene jobber separat Sette av tid til å tilegne seg kompetansen som trengs. Eventuelt se etter alternative løsninger Overtales til å holde ut. Varsle veileder. Fordele arbeidet til exgruppemedlem Gjøre arbeidet på nytt Gruppa viser litt hensyn. Gi medlemmet en annen oppgave. Personen får advarsel. Flere advarsler fører til at personen blir ekskludert. Sitte i kantina, eller hjemme hos en i gruppa. Page 23 of 139

24 Prosessrapport Samarbeidsavtale En samarbeidsavtale ble laget mellom gruppemedlemmene som utgjør antall arbeidstimer, gruppemøter, møteplikt og fravær. Dette var da en avtale som alle signerte. Denne avtalen fungerer som en kontrakt mellom medlemmene og sørger for at alle gruppemedlemmene godtar arbeidsmengde og kriterier for blant annet oppmøte. Samarbeidsavtale: Vi er gruppe 31 som består av: Vibeke Grødem Johnson Henrik Volden Kim Meisingset Helene Kristiansen Ukearbeid: Mandag fredag. Jobbe rundt 28 timer per uke. Tidspunkt blir avtalt etter hver møte. Gruppemøte: Oppsummerer arbeidet som er blir gjort. Eventuelle problemer og utfordringer som oppstår. Uenigheter diskuteres frem til beste løsning. Alle tar initiativet og ha sine meninger. Samarbeid og oppmuntring skal skje jevnlig. Tildeler oppgaver dersom det er behov for det. Møteplikt: Alle er pliktig til å møte opp presist. Prosjektlederen har ansvaret for at alle gruppemedlemmene møter opp. Ved endringer av tidspunkt eller sted, skal alle bli informert fortest mulig. Page 24 of 139

25 Prosessrapport Fravær: Dersom noen av gruppemedlemmene ikke kan møte opp over lengre tid, må arbeidsfordeling vurderes på nytt for denne sprinten. Dersom en i gruppen ikke gjør tildelte oppgaver, blir denne personen utvist fra gruppen etter 2 advarsler. Denne samarbeidsavtalen har under dette prosjektet fungert godt. Gruppen har ikke hatt noen problemer med verken oppmøte eller fravær og alle har jobbet med sine arbeidsoppgaver. 3.3 Prosesskontroll Under punktet prosesskontroll ligger beskrivelser på hvordan vi har arbeidet, ved å bruke scrum som metodikk. Det kommer også frem hvilke programmer vi har brukt for å holde kontroll på hva som skulle gjøres, hvem som skulle gjøre oppgavene og når en skulle være ferdig med oppgavene. Vi sier også noe om hvordan vi har delt filer og hvordan vi har holdt kontakt gjennom sosiale medier som Facebook Scrum Gruppen har valgt å benytte seg av Scrum som en fremdriftsmetode. Dette fordi vi har brukt Scrum-metodikken i tidligere studentprosjekter, og det blir også brukt i andre prosjekter hos Accenture. For en videre utdypning av Scrum metodikken se vedlegg 3. Scrum behandler problemene som oppstår underveis. Dette er fint i forhold til vårt prosjekt der verken teamet eller oppdragsgiver er helt sikre på hvordan resultatet skal bli. Scrum gjør det også mulig å endre og tilpasse elementer i prosjektet etter hvert som det utvikles, og passer fint i forhold til brukertesting og koding (Cohn, 2012). Styringsdokumentene som produseres i forbindelse med Scrum kalles artefakter. Slik som Mike Cohn beskriver på sin nettside om «Scrum Team» er det ingen faste definerte roller innad i gruppa, men vi har definert noen ansvarsområder som hver enkelt har. Scrum likestiller alle teammedlemmene, noe gruppen synes er en god måte å arbeide på. Her er det ikke bare en person som tar avgjørelsene, og alle er med på å bidra til å gjøre Page 25 of 139

26 Prosessrapport forandringer der det er nødvendig. Hvis en i gruppen får problemer med å utføre oppgaven sin, er det Scrum Master som løser dette. Det er viktig at teamets medlemmer holdes oppdatert om alt i prosessen så vi blir ferdig med målene til hver sprint, og v h w da id i G en har valgt i denne oppgaven å ha sprinter på tre uker, med nesten 4 arbeidsdager hver uke. Hver sprint avsluttes på en fredag, og en ny sprint starter på en mandag. Fredag skal produktet fra sprinten vises til produkt i, a i vi w, og mandag begynner en ny sprint med nye sprint backlog oppgaver. Prosjektroller: Produkteier SCRUM-master Telenor Team Ekstern veileder Intern veileder Henning Engen (Accenture) Henrik H. Volden Henrik Volden, Kim Meisingset, Helene Kristiansen, Vibeke Johnson Henning Engen (Accenture) Yngve Lindsjørn (HIOA) Jira Jira er et prosjekt og oppgavestyringsverktøy utviklet av Australske Atlassian, som startet opp i 2002 (Atlassian, 2013c). Atlassian har etter oppstarten utviklet seg til å være en stor aktør innenfor administrasjon av software og prosjektutvikling. Programmet Jira er selve grunnsteinen i Atlassian sitt produkttilbud, hvor også blant annet versjonskontrollprogrammet Bitbucket tilbys (Atlassian, 2013b). Atlassian har over kunder bestående av både små og store bedrifter, for eksempel populære bedrifter som facebook, twitter og ebay er blant disse (Atlassian, 2013d). Første utgaven av Jira ble lansert samme år som Atlassian startet opp, nå etter 12 år har versjon 6 blitt lansert. Verktøyet er lisensbasert, men med mulighet for å få gratis lisens om formålet ikke er å tjene penger på det man utvikler (Atlassian, 2013a). Jira skal gjøre håndteringen av sprinter, oppgaver og andre deler av prosjektplanleggingen enklere og mer oversiktelig (Atlassian, 2013e). Ved å benytte seg av Jira vil vi i prosjektet lettere holde kontroll over utviklingen, med tanke på tidsbruk, og eventuelle feil og mangler som ofte dukker opp i både store og små prosjekter. Figur 1 viser hvordan et scrum board kan se ut underveis i et prosjekt, oppgavene som skal gjøres samles i en sprint, og blir derfra dratt Page 26 of 139

27 Prosessrapport inn i forskjellige faser. Når alle oppgavene er dratt over i kolonnen Done, er i prinsippet sprinten fullført. Jira er nettbasert, slik at man alltid har mulighet til å oppdatere planene og sjekke fremdriften (Atlassian, 2013f). Figur 1: Illustrasjon av vår Jira under sprint Dropbox Dropbox har vært et hjelpemiddel som gruppen har benyttet for å få til et smidig samarbeid. Dropbox ble grunnlagt i 2007 av Drew Houston og Arash Ferdowsi, på grunnlag av at ikke var så effektivt når en jobbet på flere maskiner samtidig (Dropbox, 2014). Dropbox gir oss da mulighet til å lagre filer i et filarkiv som er på egen pc, men det lagres hos dropbox (Bratvold & Alnæs, 2010). Dropbox gjør det også mulig å dele for eksempel dokumenter og bilder med andre personer, slik at flere har tilgang til de samme dokumentene (Dropbox, Udefinert). Det er selvfølgelig ditt eget valg hvem som har tilgang til denne informasjonen. For vår del har dropbox fungert godt under hele prosjektet, og vi har på denne måten kunne dele informasjon og kode mellom alle parter. For eksempel ved sykdom eller fravær har vi fortsatt hatt mulighet til å jobbe videre med prosjektet, og andre gruppemedlemmer kan gå inn og se på det nyeste arbeidet hele tiden. I tillegg har dropbox gitt oss mulighet til å dele en del av dokumentene med veilederene våre på Accenture og HiOA, slik at de hele tiden kan få oppdaterte dokumenter tilgjengelig. Det Page 27 of 139

28 Prosessrapport var positivt da det ikke alltid er nødvendig å sende all dokumentasjon hele veien, men heller at veileder selv kan se dersom han ønsker det Facebook Facebook har også blitt benyttet under prosjektet som et kommunikasjonsverktøy. Der har vi opprettet en privat gruppe, kun for gruppemedlemmene. Her har vi delt nyttige lenker med hverandre og avtalt gruppemøter. Det har vært en enkel måte for alle å holde oversikten over møtetiden og for kommunikasjon mellom medlemmene Alternative metodikker Gruppen valgte også å se inn på to alternative metodikker som Vannfall og Kanban metodikken. For mer utfyllende beskrivelse på disse metodikkene se vedlegg 4. På grunn av valg av oppdragsgiver, og at Accenture jobber mest med Scrum metodikken, valgte gruppa å følge arbeidsmetodene som oppdragsgiver er mest kjent med. 3.4 Utviklingsprosessen I utviklingsprosessen viser vi på hvilken måte vi har jobbet for å komme frem til det endelige resultatet. Her forklarer vi hvordan gruppen har arbeidet fra a-å for å bli ferdig med å utvikle prototypen og skrive dokumentasjonen. Med den iterative utviklingen vi har valgt, har vi vært åpne for endringer i tidsplanleggingen underveis i utviklingen. Page 28 of 139

29 Prosessrapport Arbeidsprosessen Jira Så hvorfor skal vi ta i bruk Jira? Vi ble introdusert for Jira allerede på første møte med vår veileder på Accenture. Det var tydelig at dette var redskap Accenture ønsket at vi benyttet oss av, da dette er et verktøy bedriften har erfaringer med fra før. Siden vi gjennom studiene har fått et godt innblikk i Scrum som et rammeverk for prosjektstyring, var anbefalingen om å benytte Jira ganske optimal for vår del. Da en kan legge til flere brukere i hvert prosjekt, kan både veiledere ved Accenture og Hioa følge med på utviklingen. Noe som er til stor hjelp for alle parter i prosjektet. Vi hadde litt problemer med å få en lisens til programmet, da dialogen med kundebehandlerne hos Atlassian gikk litt sakte. Løsningen kom etter et par uker, da veilederen vår hos Accenture ordnet lisens gjennom firmaet. Ingen av gruppemedlemmene hadde erfaring med Jira eller Atlassian fra før, og startet derfor med blanke ark. Etter noen timer med utforskning av programmet fikk vi relativt god kontroll over de mulighetene og funksjonene som er tilgjengelig. Under denne prosessen kom kunnskapene våre om Scrum metodikken godt med. Under oppstarten av den første sprinten var det uvant og krevende å holde Jira oppdatert. Det var også en prosess å tenke hvordan vi skulle dele inn oppgavene, slik at hver oppgave hadde en overkommelig arbeidsmengde. Bruk av Jira krevde et møte med planlegging av kommende sprint og tidsestimering. Det var til å begynne med uvant, men etter hvert som gruppen jobbet med planleggingen, ble dette enklere. Vi ser at planleggingen av tiden ble bedre og bedre jo lenger ut i prosjektet vi kom og at arbeidet ble jevnere fordelt over 3 uker, på de siste sprintene. Figur 2: Burndownchart av sprinter i Jira Det viser også burndownchartet som lages under sprinten. Den grønne linjen viser hva som blir gjort og den rød linjen viser oppgaver som er igjen. I Figur 2 ser en ved sprint 4 tydelig at Page 29 of 139

30 Prosessrapport oppgavene er større og arbeidet er ikke jevnt fordelt. Ved sprint 6 ser en hele tiden at den røde og grønne streken jobber seg mot hverandre og arbeidet er jevnt hele veien under sprinten. Burndownchartet er noe som Jira lager automatisk mens en jobber i det og det er også en av fordelene ved å benytte et slik program for en god arbeidsflyt. Det gir en bra oversikt over hver sprint og man kan se progresjon på en god måte. Det finnes også andre diagrammer i Jira som vi kan benytte oss av, men for vår del var burndownchartet det som ga oss best oversikt Sprint 0: Behovs- & løsningsbeskrivelsesfase Under oppstart hadde vi ingen sprint, men en arbeidsprosess for å komme frem til hvordan vi ville arbeide. Det var her vi utviklet tanken om sprinter på 3 uker, slik at det ble nok tid til å utføre en del oppgaver i hver sprint. For korte sprinter fant gruppen ut at ville kreve mye tid ved planlegging og avslutningen av hver sprint og at det muligens ville føre til mer arbeid med sprintplanlegging enn reelt arbeid med oppgaven. Etter dette startet gruppen sprintarbeidet Sprint 1-4: Iterativ konstruksjonsfase Under disse sprintene ble det startet opp et arbeids- og utviklingsmiljø. Det ble utformet en forprosjektsrapport og problemstillingen ble satt. Styringsdokumentasjon og kravspesifikasjoner ble laget. En papirprototype skulle ferdigstilles innen sprint 4 var ferdig. Analysen av kodespråkene skulle også ferdigstilles i disse sprintene. Videre skulle utviklingen av prototypen være i gang og det skulle også gjennomføres en spørreundersøkelse. Det ble også tydelig ved de første sprintene av milepælsplanen som var laget før sprintstart ikke ville fungere helt. Gruppen lå lenger bak skjema i forhold til denne og bestemte tidlig at rapporten derfor skulle oppdateres underveis i prosjektet, istedenfor å ha en måneds arbeid med rapporten i de siste sprintene. Resultatet av arbeid etter sprint 1 var at forprosjektsrapporten og styringsdokumentasjonen kom på plass. En fikk også startet på oppgaven med visualisering etter et møte med en representant for User Experience teamet til Accenture. Utfordringen videre var å finne ut hvilke visualisering og hvilke funksjoner som vi ville fokusere på under analysen og prototypen. Page 30 of 139

31 Prosessrapport Dette gikk vi da videre med i sprint 2 hvor arbeidet med ulike visualiseringsteknikker ble påbegynt. Planleggingen av de funksjonene som skulle være fokus ble også utført og et skjema for analysen ble satt opp. I rapporten ble det skrevet om Scrum metodikken som vi skulle benytte oss av og gruppen undersøkte også hvilke andre metodikker som var mulig å benytte seg av, for å være sikker på at Scrum passet best for oss. I sprint 3 ble det laget analyse av Angular, Can, Backbone og Ember. Dette ble siden omformulert til en tallskala som ble fyllt inn i analyseskjemaet. Det ble startet på et reisverk med HTML 5 og CSS3. Dette ble utviklet slik at mer informasjon kunne settes inn etterhvert som gruppen arbeidet med det som skulle passe inn på siden. Det ble laget skisser for visualiseringen og noen alternativer ble forkastet etter en vurdering. En del designvalg skulle også utformes her og det ble brukt lengre tid en beregnet på dette. Gruppen kom med ulike forslag som ble forkastet siden og lagde deretter nye forslag. Dette førte til at vi kom litt bak skjema i forhold til tid og utvikling. Sprint 4 inneholdt en spørreundersøkelse for visualiseringsteknikkene gruppen kom frem til. Spørreundersøkelsen ville gi et objektivt og bedre grunnlag for valg av endelig teknikk i forhold til hva forbruker prefererte. Analysen ble utvidet med rammeverket Meteor, og analysen ble ferdigstilt. Angular.js fikk høyest poengsum og arbeidet med å lære seg rammeverket ble påbegynt. Dette skulle da brukes i prototypen for noen funksjoner, slik at en kunne se hvordan rammeverket fungerte i praksis. I rapporten ble det skrevet om metodikkene Vannfall og Kanban og om hvordan Jira fungerer. Page 31 of 139

32 Prosessrapport Sprint 5 Sprint 5 inneholdt mye arbeid for å ferdigstille prosjektet. Gruppen hadde en midtveispresentasjon for veileder på HIOA. I rapporten ble det skrevet om brukertesten og visualiseringsteknikkene benyttet. Design/utforming av knapper til prototypen ble utformet. Ettersom gruppen lå litt bak var det mye utvikling i denne sprinten og det gikk mer tid en forventet med på å lære seg Angular.js. Derfor måtte noen oppgaver overføres til sprint 6, da vi ikke klarte å ferdigstille alle oppgavene planlagt i sprinten. Dette var en undervurdering fra vår side som første til at gruppen lå mer bak skjema Sprint 6 7: Avslutnings fasen Ved sprint 6 var det mye arbeid som måtte gjøres for å fullføre prosjektet. Alle sidene på prototypen måtte settes opp med riktig informasjon. Utfordringen ved denne sprinten var å få databasen til å fungere sammen med prototypen. Men gruppen valgte fortsatt å utvikle prototypen med Angular.js. Det var også en utfordring hele veien ettersom alt som ble gjort i dette rammeverket fortsatt var ganske nytt og ukjent terreng. Men etterhvert som gruppen jobbet med språket, gikk det bedre. I rapporten ble det satt opp en korrekt disposisjon av prosjektrapporten og tekstene som allerede var skrevet ble plassert riktig. Under denne sprinten var det fortsatt stort fokus på å skrive videre på rapporten. Sprint 6 ble også brukt til å utføre en brukertest med prototypen som var utformet. Det ble utført på slutten av sprinten, men var viktig for gruppen. Testingen ville da vise hva som var gjort riktig og hva som kunne vært endret på ved prototypen. Sprint 7 var siste og endelige sprint. Denne sprinten var kortere enn de andre sprintene på 3 uker på grunn av tidsfristen for å ferdigstille prototype og rapport. Derfor var det kun rapporten som gjensto å få fullstendig ferdig og trykket opp. Sprint 7 varte i litt mer enn en uke (inkluderer da helgen) og inneholdt siste arbeid som måtte til for at vi skulle være fornøyd med endelig resultat. Sprinten inneholdt også en presentasjon som ble utført for oppdragsgiveren Accenture. Page 32 of 139

33 Prosessrapport Arbeidet med Scrum Gruppen har fra starten av prosjektet jobbet med den agile metoden Scrum. I begynnelsen var det vanskelig å finne ut hvor lange sprintene skulle være, så vi begynte med 4 ukers sprinter. Etter noen uker merket vi at dette var litt lange sprinter, og valgte å gå ned til tre uker per sprint. Da vi til slutt fikk fikset med Jira programmet av vår oppdragsgiver, gjorde dette det lettere for oss å jobbe med Scrum metoden. Ved hjelp av Jira fikk vi mulighet til å planlegge bedre, og hadde oppgaver liggende i produkt backloggen. Vi prøvde å få til møter på begynnelsen av en sprint og på slutten og dette gikk som regel greit. Ved problemer med møte på start av hver sprint løste vi det med å snakke på telefon eller facebook. Når vi møttes hadde vi daily standup meetings. Dette gikk fint da vi alle i gruppa er vant med å fortelle hverandre hvordan vi jobber, og hvilke vanskeligheter vi eventuelt har støtt på i oppgaven vår. Generelt har det gått bra for oss å jobbe med den agile metoden. Det var fint for gruppen å ha mulighet til å gå tilbake å rette på feil og mangler som brukertesten avdekket. Vi hadde også mulighet til å forlenge noen oppgaver til neste sprint, da det viste seg at vi trengte mer tid på disse. Page 33 of 139

34 Prosessrapport 3.5 Teknikker Under teknikker beskriver vi de viktigste fremgangsmåtene gruppen har brukt som et hjelpemiddel, for å løse ulike utfordringer som har oppstått i løpet av prosjektet. Vi har brukt brainstorming som en teknikk gjennom hele prosjektet. Denne teknikken har vært til hjelp når vi har hatt behov for endringer eller nye ideer ved nettsiden. Penn og papir har vært våre redskaper når det kommer til brainstorming prosessen. Vi satt sammen å tegnet de ulike sidene til nettstedet, og hvordan vi ville at disse skulle se ut, som vist i Figur 3. Her vises hvordan vi vil at side tre av opprette abonnement og side fire av abonnement skal vise for kundene. Opprette abonnement skal ha funksjonen hvor en tilbyr ferdigstilte maler med Lite, Middels og Stort. Det skal også være mulig å lage sitt egendefinerte abonnement. Side fire på abonnement skal vise forbruk ved hjelp av en graf, og nederst skal det vise hvilket type abonnement du har. Flere bilder av brainstorming, se vedlegg 2 (Teknikker). Figur 3: Forslag til prototypens oppsett under brainstorming prosessen Page 34 of 139

35 Prosessrapport Visualiseringsteknikker Problemstillingen gikk ut på hvordan vi skulle visualisere dataene på en god måte slik at kunden forstår hvilket forbruk de har per måned. Som rådata er dette ulike tallverdier og tekstbasert informasjon. Dette gir ikke alltid bruker en oversikt ved et raskt blikk på tabellen. Derfor var det ønskelig få til en god fremstilling som ga kunden mulighet til å få oversikt over forbruket ved et raskt blikk. Visualiseringsteknikken brukte vi for å komme frem til visualiseringen som ble brukt i prototypen. Dette var en stor del av siden vi skulle utvikle og det gikk derfor en del tid med på dette. Når det er flere enn en variabel som blir brukt for å analysere noe kaller vi dette multivariate data(spence, 2013). Dataene over forbruket for et abonnement er såkalte multivariate data. Derfor kan vi benytte ulike visualiseringer som gjør det mulig å fremstille disse dataene på en god måte. I tillegg til å jobbe med ulike visualiserings teknikker, valgte vi også å benytte representasjonsmetodene til J. Bertin. Han beskriver hvordan dataene kan oppfattes med assosiasjoner, hvordan du velger å skille dataene fra hverandre med for eksempel ulike farger. Rangeringen av data ser da ordnet ut og visualiseringen viser størrelsesforskjeller mellom dataene på en lett måte (Spence, 2013). Hele veien under de ulike visualiseringsteknikkene har vi representert det faktiske forbruket til kunden med en farge og det forbruket som er inkludert i et abonnement med en annen farge. Dermed kan vi enkelt vise kunden forskjellen på dataen. Det ble utviklet fire visualiseringsteknikker og utført en spørreundersøkelse på disse i etterkant. Dette kan du lese mer om under punktet 6.0 Testdokumentasjon. Første teknikk som ble testet var ett stjerneplott (se Figur 5). Det multivariate stjerneplottet viser et vilkårlig antall variabler på de radiale aksene, her vist som de ulike komponentene ringeminutter, MMS, datatrafikk og SMS. Attributtene vil da være for eksempel antall SMS som er sendt og antall SMS som er inkludert i abonnementet. Attributtene representerer forbruket på antall SMS, MMS, data og ringeminutter og koordinataksene treffes i origo. Origo representerer at det ikke er noe forbruk tilgjengelig Figur 4: Sjernediagram Page 35 of 139

36 Prosessrapport eller brukt, og jo lenger opp på aksene en befinner seg, jo høyere er forbruket. Dette viser da sammenhengen mellom de ulike attributtene og hvordan de er i forhold til hverandre og samtidig i forhold til det inkluderte i abonnementet. På denne måten skal det være lett å sammenlikne hvor langt innenfor eller utenfor forbruket en er i forhold til det inkluderte. Meningen er at du skal ha mulighet til å hente ut informasjon raskt uten å bruke for mye tid på visualiseringen. Den andre visualiseringen vi valgte å utføre var et sirkeldiagram (se Error! eference source not found. ). Her representerer hver sirkel en av attributtene (SMS, MMS, ringeminutter og dataforbruk). Dermed vil for eksempel sirkelen med SMS Figur 5: Visualiseringsforslag1 (Sirkeldiagram) representerer antall SMS som er inkludert i abonnementet og ringen fyller seg mer opp ettersom forbruket øker (nærmer seg 100%). Dersom forbruket er høyere enn det som er inkludert, vil sirkelen fylle seg opp og starte på en ny sirkel (over 100 %) slik som dataforbruket er i visualisering 2 (se Figur 33). Meningen her var at denne visualiseringen skulle være dynamisk og fylle seg opp mens brukeren så på visualiseringen. Dette ble selvfølgelig ikke presentert i spørreundersøkelsen, men figuren ble visuelt fremstilt. Den tredje visualiseringen var et barchart som også er utformet som et mosaikk-plot (se Figur 6). Et mosaikk plot er en grafisk fremstilling som gir deg mulighet til å vise relasjoner av to eller flere kategorier med ulike variabler (JMP, 2014). I vårt barchart blir det fremstilt med to ulike farger hvor mye som er brukt og hvor mye som er igjen av det inkluderte i forbruket. Og dersom forbruket overskrider det som er inkludert i abonnementet vil barcharten bevege seg forbi den normale linjen. Figur 6: Visualiseringsteknikk 3 (Barchart) Page 36 of 139

37 Prosessrapport Den siste visualiseringen var nesten som en barchart, bare vertikal og kalles for et søylediagram (se Figur 7). Her visualiserer vi også med barer slik som i barchartet ovenfor, noe som hjelper til med å representere diskrete verdier og støtter brukers sammenlikning. Ønsket her er å hjelpe leser med å fokusere på individuelle verdier og sammenligne verdiene opp mot hverandre, noe barer hjelper til å gjøre. Det var filosofen Rene Descartes som utviklet dette todimensjonale koordinatsystemet, der du har en vannrett akse og en loddrett akse. I vårt søylediagram blir dette representert med SMS, MMS, ringeminutter og dataforbruk langs den Figur 7: Visualiseringsteknikk 4 (søylediagram) vannrette aksen og forbruket stiger langs den loddrette aksen. Men det var Wiliam Playfair som på slutten av 1800-tallet utviklet dette til et grafisk middel for kommunikasjon av kvantitative data (Few, 2013). Ettersom dette da har vært en grafisk fremstilling som har eksistert i mange år og brukere kjenner til, var det greit å ha med denne visualiseringen også. Noe som også kom frem som en preferanse for mange under spørreundersøkelsen (se vedlegg 7 for resultater av spørreundersøkelsen og punkt 6.1 for forklaring av spørreundersøkelsen). Page 37 of 139

38 Prosessrapport Prototypen i ba m di a b a m, vi ma E er et utkast til hvordan et ferdig produkt vil se ut og fungere. For i d ima mi d b d vi i a d a i b b i d av vi i D i ma m vi, ma a b a i, da a a d vi mid vi d ma a utvikle. Vi deler prototyper inn i to hovedkategorier High-fidelity og Low-fidelity (Memmel, 2011) v i h- id i b a ma vi d a m di vi d w- id i d im a a bi i, i a ma a a id ø endringer underveis. I denne oppgaven har vi benyttet oss av to forskjellige typer prototyper, en Low-fidelity og en High-fidelity. Spørreundersøkelsen går under Low-fidelity, der vi har tegnet inn de ulike visualiseringene og funnet ut hva bruker synes er best å bruke. For mer informasjon om disse, se vedlegg 1 (visualiseringer) og vedlegg 7 (spørreundersøkelsen). High-fidelity prototypen er laget ved hjelp av ulike kodespråk. Denne skal ligne mest mulig på det endelig resultatet, og skal hjelpe oss å finne ut eventuelle feil og mangler som kan rettes på til det endelige produktet lages. Dette gjøres ved hjelp av en brukertest, der man ser på hvordan bruker kommuniserer med nettsiden (For mer utfyllende dokumentasjon av brukertesten, se vedlegg 8). Page 38 of 139

39 Prosessrapport 3.6 Utfordringer Her vil det foreligge en utbedring av faglige og personlige utfordringer som har oppstått under prosjektets levetid. Det vil også her blitt redegjort for hvordan gruppen valgte å løse disse utfordringene, og hvorfor det ble gjort på denne måten Personlig utfordringer Gruppen har som tidligere nevnt jobbet sammen på prosjekter før dette og kjenner hverandre derfor ganske godt. Dette gir oss da en god mulighet til å klare å si ifra når det er noe man føler fungerer mindre greit, slik at det lett kan løses uten større konflikter. En av utfordringene som har vart gjennom hele prosjektet, har vært et fag som har pågått parallelt med dette prosjektet, og har til tider krevd mye tid. Siden gruppen også jobbet sammen på dette, var løsningen at man innimellom måtte dele gruppen i to, slik at noe hele tiden ble produsert på begge prosjektene. Videre har også et av gruppemedlemmene fått barn i januar, noe som bød på utfordringer ingen av medlemmene tidligere hadde møtt på. Det ble en utfordring med kontinuerlige møter på skolen, noe som førte til at det ble løst med å heller ha møter hjemme hos dette gruppemedlemmet. Den løsningen har fungert godt for gruppen, da reiseveien ikke ble lengre og vi samtidig kunne ha like hyppige møter og arbeidsøkter som tidligere. Page 39 of 139

40 Prosessrapport Faglig utfordringer Gruppen har under prosjektet møtt på noen faglige utfordringer. Under utdanningen på høyskolen har ikke gruppen hatt så mange fag som inkluderer mye utvikling, men heller fag som fokuserer på brukervennlighet. Dette ble da en utfordring for gruppen når vi under prosjektet skulle lære oss et nytt rammeverk, og tilegne oss kunnskap som vi ikke satt inne med fra før av. Den første utfordringen som oppsto faglig kom tidlig i prosjektet. Oppgaven fra Accenture var forholdsvis vid og ga oss rom til å definere en problemstilling selv. Dette første til mye arbeid for å faktisk forstå oppgaven og lage en problemstilling som ikke ble for omfattende. Videre var en av de store utfordringene våre å lære oss et rammeverk vi ikke kunne fra tidligere av. Det krevde at vi satt oss inn i hvordan man bruker rammeverket under utvikling. Oppgaven var overkommelig, men en utfordring da dette var noe nytt og ukjent. Det tok oss lengre tid enn forventet å mestre rammeverket nok til å starte utviklingen, og det førte til at vi lå litt bak tidsplanleggingen i forhold til sprintene. På slutten støtte vi på en utfordring med å få databasen til å fungere, ettersom vi aldri hadde satt opp denne typen database før. Databasen som ble valgt av gruppen for å fungere med prosjektet var MongoDB, en NoSQL database. Etter å ha jobbet en stund med denne databasen, fant vi ut at problemene vi hadde var knyttet opp mot serveren til HiOA. Vi kunne ikke benytte denne databasen, da vi ikke har tillatelse til å legge inn nødvendige programmer på skolens server. Derfor måtte vi gå tilbake til start og lage en database med MySQL, noe vi tidligere har jobbet med. Utfordringen da var å få denne databasen til å snakke med Angular.js rammeverket, slik at riktig informasjon ble tilgjengelig. Page 40 of 139

41 Prosessrapport 3.7 Forhold til arbeidsgiver Accenture Vi har hele tiden hatt en dialog med vår veileder på Accenture. Han har vært disponibel på e- post for spørsmål og annet når vi har hatt behov for å avklare noe. I tillegg har vi under hele prosjektet hatt møter med Henning Engen. Møtene var etter behov mer hyppige i oppstartsfasen, da mye informasjon og forståelse for prosjektet skulle på plass. Etter hvert som behovet ble mindre, har møtene vært satt til slutten av hver sprint, slik at gruppen har kunne vise til nye resultater og videre utvikling. Da har vi også fått tips til hva fokuset for neste sprint bør være. 3.8 Endringer i kravspesifikasjoner Oppgaven som ble gitt fra Accenture (oppdragsgiver) har vært en veldig åpen oppgave, med mulighet for oss til å selv velge hovedfokus for oppgaven. Dette har hatt en betydning med tanke på at kravspesifikasjonen da ikke har endret seg. Det er heller forståelse av oppgaven som har tatt lang tid for gruppen. Med en åpen oppgave var det største utfordring å forstå hva oppgaven bør inkludere og hvor fokuset skal ligge. Kravspesifikasjonen ble ikke endret, men vår forståelse av oppgaven ble etter litt arbeid tydeligere? Page 41 of 139

42 Produktrapport 4.0 Produktrapport Et produkt er noe som er skapt gjennom produksjonsprosessen og som viser til de forventningene en oppdragsgiver har til resultatet. Produktet kan deles opp i ulike kategorier som Figur 8 viser. Behovet som kunden har til produktet heter basisproduktet (Sander, 2014). D d v w b id vi ha utformet. Deretter går du gjennom flere kategorier som beskriver hvilke forventninger kunden har til produktet og hvilke fremtidige planer som kan forventes av produktet. I denne produktrapporten beskrives det hvordan Min bedrift 2.0 er bygget opp, og hvilke teknologier som er brukt for å oppnå det endelige resultatet. Vi har valgt å dele opp produktrapporten med en analyse del, og en del som beskriver oppbyggingen av produktet. Dette fordi analysedelen har vært en stor del av selve kravspesifikasjonen til oppgaven. Figur 8: Produkt kategorier 4.1 Min Bedrift 2.0 Min bedrift 2.0 er en utviklet versjon av Telenors tidligere side Min bedrift. Den er fortsatt under utvikling av Accenture da dette er et forholdsvis stort prosjekt som skal ferdigstilles. Nettsiden inneholder mange funksjoner og løsninger for bruker, for å gi bedriftskunder muligheten til å holde orden og styr på sin egen bedrifts utgifter hos Telenor. Tidligere har denne siden vært stor og tung for bruker å benytte, noe som fører til at de fleste bedriftskunder heller ringer til kundestøtte dersom de ønsker noe. Telenors ønske med dette prosjekter er at Min bedrift 2.0 skal bli mye lettere å benytte, slik at færre ringer inn til kundestøtte hos Telenor. Derfor er målet at front-end utviklingen skal ha bruker i fokus. Page 42 of 139

43 Produktrapport Funksjonaliteter Oppdragsgiver ønsket å få en analyse av rammeverk fra gruppen. Denne analysen skal da kunne benyttes som et grunnlag for ulike rammeverk ved senere prosjekter Accenture utfører for Telenor. Oppdragsgiver ønsket at noen konkrete funksjonaliteter skulle testes ved prototypen gruppen utviklet. Hvilke funksjonaliteter dette skulle være var opp til gruppen selv. Men det var User Experience teamet til Accenture som ga gruppen ulike alternativer på funksjonalitet. 4.2 Analyse Å analysere er å vurdere data eller informasjon ved hjelp av en systematisk undersøkelse. Her undersøker vi fem rammeverk, hva de kan utføre, for så å bryte de ned i forskjellige bestanddeler og dermed gi grunnlag for beslutningstaking og problemløsning Analyse av rammeverk For å lage en analyse av ulike rammeverk var det viktig å finne ut hvilke kriterier som var nødvendig at det håndterte. Dette ble vurdert opp mot hva som var ønskelig å utføre på siden som skulle benytte et av rammeverkene, og hvilke begrensinger det eventuelt hadde. Andre ikke funksjonelle krav slik som testbarhet, ytelse, modenhet, størrelse, sikkerhet og liknende var også viktig for å komme frem til et rammeverk som kunne passe inn når analysen var ferdig (Maus, 2010). For å forstå bedre hva som er lagt i de ulike kriteriene til kodespråkene har hvert kriterie fått en liten forklarende tekst under etterfulgt av analyseskjemaet (se figur 9, 10 og 11). Testbarhet: Testing er noe som utføres likt som koding. Som Hughes & Cotterell skriver om i boken sin er dette noe som kan gjøres med automatiske testverktøy og kan videre sørge for at ny kode ikke skaper error mot eksisterende kode. Videre er det beskrevet at i denne sammenhengen er det interessant om det eksisterer enhetstesting, som fokuserer på koden som en utvikler akkurat har skrevet. Dette sørger for god kvalitet når prosjektet blir komplekst og dimensjonen er stor (Hughes & Cotterell, 2009). Page 43 of 139

44 Produktrapport Modenhet: Ettersom feil ved rammeverket er rapportert og rettet blir rammeverket mer modent ettersom defaults forekommer sjeldnere (Hughes & Cotterell, 2009). Derfor er det viktig å vurdere hvor modent et språk er. Dersom et språk er veldig nytt, vil det også inneholde flere feil og mangler enn dersom det er kommet flere oppdaterte versjoner tilgjengelig. Ved å se på modenheten kan man sikre seg et rammeverk som har rettet de største feilene. Ytelse: Ved å vurdere ytelse mener vi hvor bra et rammeverk fungerer. Det er en vurdering av om systemet klarer å opprettholde sitt ytelsesnivå, slik at det kan regnes som pålitelig (Hughes & Cotterell, 2009) Fleksibilitet: En annen styrke ved rammeverket som var viktig var fleksibilitet. Det vil si rammeverkets evne til å endre seg. Fleksibilitet gir rom til å vokse og endre seg i forhold til brukers ønsker i fremtiden. Og det blir enkelt å senere gå inn og legge til noe kunden ønsker skal opprettes i systemet. Vanskelighetsgrad: Vanskelighetsgrad går i større grad ut på selve utviklingen og det som vurderes her er hvor vanskelig det faktisk er å lære seg rammeverket. Vurderingen er om det er enkelt eller vanskelig og om det tar lang tid før man eventuelt behersker koden. Størrelse og opprettholdelse: Her ser man på om rammeverket er stort og eventuelt tungt og om det blir opprettholdt og videreutviklet per dags dato. Nettleser kompatibilitet og mobil/tablet kompatibilitet, touch events: Ved dette punktet blir kompatibiliteten mot ulike nettlesere og plattformer vurdert. Det er viktig ettersom man ønsker at systemet/endelig produkt skal fungere mot flere ulike plattformer og nettlesere. Brukere av et system benytter ofte ulike nettlesere og plattformer for å utføre de samme oppgavene i systemet. Sikkerhet: Sikkerhet er alltid viktig og det gjelder også med tanke på kodespråk som velges. Det er et viktig element for å bidra til å hindre tilgang til systemet for uautoriserte brukere. Store feil ved rammeverke kan resultere i sikkerhetshull som gjør det lettere for hackere å få tilgang (Conklin, White, Williams, Davis, & Cothren, 2012). Page 44 of 139

45 Produktrapport Økosystem / plug-ins: Et økosystem / plug-ins er applikasjoner som øker evnen til å håndtere nye datatyper og ny funksjonalitet (Conklin et al., 2012). Det er viktig ettersom vi var ute etter front-end løsninger og dette bidrar til muligheten for mer funksjonalitet på siden. Ved siden av de ikke funksjonelle kravene var det også noen funksjonelle krav som vi la vekt på under analysen. Det var følgende: visuelle grafikse fremstillinger, lister og en dropdown meny. Dette var elementer som var viktig for å kunne lage en god prototype som tilfredsstilte kravene til frond-end løsningen. Og det var et fokusområde at rammeverket som ble valgt til å brukes videre etter analysen hadde disse redskapene, slik at vi fikk lagd innholdet som trengtes på prototypen. Etter å ha funnet kriteriene som er nevnt ovenfor, var det viktig å finne rammeverkene som skulle vurderes opp mot kriteriene. Det ble valgt noen rammeverk som var helt nye og noen rammeverk som har eksistert i noen år nå, men alle var rammeverk som benyttes på front-end løsninger. Vi som gruppe kom da frem til at følgende språk som skulle vurderes var Angluar, Backbone, Can, Ember og Meteor. Det ble deretter innhentet nødvendig informasjon om hvert språk, med en skriftlig analyse av hvordan språket oppfører seg og hva som fungerer og ikke fungerer. Videre ble denne analysen lagt inn i et skjema med alle de andre rammeverkene, der vurderingene gjort i analysen ble overført til tall. På denne måten kunne man sammenlikne dataene enklere. I tillegg til å lage en skala fra 1-6 med hvor bra rammeverket kan utføre de ulike kriteriene, ble det også lagt inn relevanse i vurderingsskjemaet. Med relevanse mener vi at det er mulig å legge inn en relevanse melllom 1-3 på de ulike kriteriene for å øke viktigheten av dette punktet. For eksempel kan en si at dersom sikkerhet er et viktig kriterie for oppgaven som skal utføres, så vil den få en høyere relevanse (f.eks 3), slik at det kriteriet teller mer enn for eksempel et annet. Dette kan en se i analysen (se figur 9, 10 og 11) vi utførte hvor modenhet var et viktig kriterie så det fikk relevanse 2, derfor blir tallene som representerer hvor modent de ulike rammeverkene er ganget med 2. Dette fører til at relevansen kan ha en avgjørende faktor på den totale poengsummen til et rammeverk. Slik kan analysen brukes gjentatte ganger med de samme rammeverkene, på ulike prosjektet, ved at en endrer hvilke kriterier som er viktigst i det angitte prosjektet. Page 45 of 139

46 Produktrapport Figur 9: Analyseskjema Page 46 of 139

47 Produktrapport Figur 10: Analyseskjema Page 47 of 139

48 Produktrapport Figur 11: Analyseskjema Page 48 of 139

49 Produktrapport Under denne analysen (figur 9, 10 og 11) følger en detaljert analysebeskrivelse av hvert rammeverk som er vurdert: CanJS CanJS er et javascript rammeverk som er forholdsvis lett å lære seg. Går du inn på nettstedet får du det meste av informasjon du trenger for å lære deg CanJS (canjs, udatert). Det er få nettsider som er laget i CanJS, og på grunn av dette kan det virke som om dette språket er en uprøvd løsning. Men CanJS har mer backing enn hva som vises, og det er en utvinning av JavaScript MVC biblioteket som har eksistert siden 2008 (canjs, udatert). CanJS tillater deg å integrere andre biblioteker med minimal anstrengelse, her kan du for eksempel bruke Nagler uten problem. Det kan virke som CanJS har et lite bibliotek, men det gir deg alt du trenger for å lage en klientside applikasjon. CanJS har også forskjellige pakker som can.construct, can.observe, can.model, can.ejs, can.view, can.control og can.route (canjs, 2012). Rammeverket ha b m a b v d i D ha i m b d i d h d i i nettleserens URL-hash. CanJS viser også bindinger ved hjelp av observerbare objekter. Her oppdateres siden automatisk når det blir endringer i et objekt (Porto, 2013). Det vi d vi i i i vi i m b i d a d vi i vi a d i i vi Det eneste CanJS ikke mestrer ø v i bi di D b vi P h endringer i observerbare objekter automatisk som for eksempel i et skjema (Porto, 2013). Den viktigste grunnen for å bruke CanJS er at du lærer deg programmet lett. Grunnen til at mange ikke bruker rammeverket over lengre tid er at det bare er knyttet til ett selskap (bitovi) og en person (Justin Meyer). Store prosjekter trenger mer tyngde av større bidragsytere, og det kan virke som CanJS har stagnert iforhold til dette. Page 49 of 139

50 Produktrapport Backbone.js Backbone er et MVC javascript rammeverk, og kommuniserer med dataene som skal presenteres gjennom et RESTful JASON interface (Public, 2014a). Noe som vil si at man bruker JASON (JavaScript Object Nation) til å interagere gjennom HTTP-standaren ved hjelp av POST, GET, PUT og DELETE (Tijms, 2013). I 2010 ble den første utgaven av Backbone lansert, men dette var ikke en stabil utgave, og inneholdt som de fleste andre beta versjoner feil og mangler. 3 år senere ble versjon lansert, og rammeverket var nå langt mer stabilt. For å kunne ta i bruk Backbone er man avhenig av Underscore.js (Public, 2014a), som er et JavaScript med mange funksjonelle hjelpemidler for å få Bacbone til å fungere optimalt (Public, 2014d). Ved første øyekast kan Backbone se ut som et lite og enkelt rammeverk, men på grunn av avhengigheten av andre biblioteker er ikke nødvendigvis dette tilfellet. Rammeverket har mange brukere, derfor er prossessen med å finne informasjon eller hjelp mindre krevende. Som vi kan se inne på Backbone sin egen informasjonsside (Public, 2014b), er det mange større aktører som har benyttet seg av Backbone i sine nettløsninger. Denne informasjonssiden inneholder også det meste en nybegynner skulle trenge av informasjon for å komme i gang med Backbone prosjektene sine. Tilgjengelig informasjon er i grunnen svært viktig hvis man benytter seg av backbone, da bruk av manuell kode utenfor det standariserte rammeverket kan komme godt til nytte for å utføre mer komplekse funksjoner (f.eks. view bindings). Det er nettopp på dette punktet at backbone skiller seg fra en del andre javascript rammeverk, det er en lettvekter som skal brukes i kombinasjon med andre biblioteker. Page 50 of 139

51 Produktrapport AngularJS Angular er et javascriptrammeverk som er veldig i vinden for tiden. Det gjør det mulig å gjøre nettsider veldig dynamiske og det ser veldig bra ut. Det også veldig lett å lære seg og bruke de mest enkle funskjonene, men kan kanskje virke litt mer komplisert så fort man beveger seg mot de litt mer tyngre oppgavene man skal gjøre. Nettsiden til Angular er et veldig godt verktøy for å lære seg og bruke dette rammeverket, den innholder alt i fra tutorials (både filmer og tekstlige) til eksterne sider som bruker Angular (Google, ). Disse sidene innholder mange fancy funksjonaliteter som Angular tilbyr og gir den som skal utvilke en side et veldig godt inntrykk av Angular. På grunn av visse funskjoner som modularitet og dependency injections som brukes av Angular for å gjøre testingen enkel og fører til testbar kode. Rammeverket er veldig fastsatt, ved at en må følge standarder, men disse standardene er også noe som gjør rammeverket veldig bra. Det er også en av grunnene til at det er et veldig testbart rammeverk (Porto, 2013). Angular blir støttet og opprettholdt av google, dette sier noe om at det er et rammeverk som trolig er kommet for å bli en stund og at det er til å stole på (Google, ). Det finnes veldig mange sider som snakker om Angular og som gir nyttig informasjon i forhold til angular som et verktøy. Dette blir ofte diskutetert og nevnt på sider som StackOverflow (Stackoverflow, 2014a). Angular har et veldig stort økosystem, noe som vil si at det har mange plug-ins, som kan være med på å gjøre en side både bedre, og at den ser bedre ut visuelt. En kan for eksempel bruke bootstrap som et tillegg til Angular som gjør det veldig kult/bra å se på sidene og gir mange gode funksjonaliteter. På den negative siden har vi det at det kanskje ikke har verdens beste ytelse slik det er i dag, på grunn av alle sjekkene som blir gjort mot objektene. Det har et ganske stort bibliotek som er på 80k, men det trenger ingen andre en dets egne bibliotek for å fungere. Det er som sagt et veldig fastsatt rammeverk og må skrives/kodes på visse måter i forhold til mange andre rammeverk som er litt «løsere», når det kommer til hvordan ting skal settes opp og skrives. Men trives man med dette kan dette også være noe positivt. Page 51 of 139

52 Produktrapport Ember.js Ember er som Angular et veldig fastsatt rammeverk, men det trenger flere biblioteker for å fungere. Ember trenger jquery og HandelbarsJS for at det skal fungere, noe som gjør at det blir et veldig stort og tungt rammeverk. Bibliotekene er på hele 269k som er det største av alle de rammeverkene vi har sett på i denne analysen (Inc, 2014). Det er ifølge flere kilder et veldig tungt språk å sette seg inn i, men har en først forstått hvordan det skal gjøres skal det være veldig greit å bruke. Det er også et veldig produktivt rammeverk, når en først har lært seg hva en skal skrive gjør den mye automatisk for deg. Som for eksempel følger en rammverkets standarder vil ting så og si gå automatisk. Ember har et veldig stort miljø, som vil si at det er mye omtalt på store sider som IRC, StackOverflow og at det er har mange instruksjonsvideoer og tekstlige tutorials (Stackoverflow, 2014b). Dette er veldig positivt i forhold til at det er så mye og finne om rammeverket, noe som gjør at det er enklere å lære seg og å bruke det. Ember har et lite økosystem enda, men flere kilder sier at dette er noe som er under utvikling siden Ember er så mye brukt av flere store aktører. Økosystem vil si ting som plug-ins osv. som vil være med på å stryke Ember som et rammeverk. Etter å ha søkt endel og prøvd å finne ut om hvor god ytelse det har fant vi ut at Ember ikke er et av de raskeste rammverkene. Vi fant for eksempel en animasjon som gjør det samme både i Ember og Backbone og man ser tydlig at Ember sin animasjon går mye tregere enn Backbone (Piotr & Oskar, udefinert). Men ellers får den ikke noe annet enn positive tilbakemeldinger på animasjoner fra andre kilder (Porto, 2013). Ember er et ganske så nytt rammeverk og ble lansert i 2011, og har gjort ganske mange store endringer siden det ble lansert. Det blir derfor ofte omtalt som et mindre modent rammeverk sammenlignet med f.eks Backbone og Angular. Det blir omtalt som et veldig trygt rammverk og bruke i forhold til memoryleaks og andre sikkerhetsbrudd, så lenge en følger de standardene som utviklerene har lagt opp til. Det er også veldig bra i forhold til testing, mye på grunn av at det er en så standardisert måte å skrive koden på. Det finnes flere mulige måter å tester Ember på. Det har både egne testfunskjoner og en kan bruke andre rammeverk til å Page 52 of 139

53 Produktrapport teste (Billups, 2014). Meteor.js Meteor er et javascript rammeverk som er relativt ferskt. Det ble introdusert i 2012, og var tilgjengelig i forholdsvis stabil utgave i slutten av 2013 (Krill, 2013).Det vil si at det stadig oppdages feil og mangler som utviklerne av rammeverket jobber med å rette opp. Det er på dette punktet Meteor kan ha en fremtid. I følge GitHub, repositoryen til Meteor, er det allerede 253 releases av rammeverket og 6297 commits (GitHub, 2014b). Uten å legge for mye i disse tallene, gir det oss et inntrykk av at det er stor interesse for rammeverket. Noe som gir stor sannsynlighet for at rammeverket vil klare seg over tid. Javascriptet som utvikles ved hjelp av Meteor, kan både kjøres hos klient og på server siden, da ved hjelp av Node.js (GitHub, 2014c). Men inntil videre er det flere punkter som gjør at Meteor ikke fremstår som det tryggeste valget av rammeverk for viktige bedriftsrelaterte prosjekter. Som for eksempel mangelen på støtte av andre databaser enn MongoDB. Dette er noe utviklerne ønsker å implementere i senere utgaver av rammeverket. En annen ting som Meteor mangler er offisiell støtte for Windows. Dette er også noe som er under utvikling i følge Meteor roadmap på trello (Public, 2014c). Hvis en ser på tilbakemeldinger på nettet, er det en ganske entydig mening om at rammeverket er blandt de lettere å lære seg, og da interessen er stor er også veien for å få hjelp kortere. I forhold til sikkerhet stiller ikke Meteor så bra når man som bruker ikke har gjort endringer i filene som følger med installasjonen. Når Meteor installeres, er pakkene autopublish og innsecure inkludert (GitHub, 2014a). Pakkene gir klienten skrive og lese rettigheter til serveren. Disse pakkene må derfor slettes hvis man ønsker å øke sikkerheten, men kan være greie å ha hvis formålet bare er å leke og utforske mulighetene rammeverket gir. I forhold til nettleserkompatiblitet stiller Meteor ganske normalt, og støtter alle de store nettleserne. Begrensningene viser seg ofte å være i Internett Explorer, men her har Meteor støtte i hvertfall tilbake til IE6. Når det kommer til mobil kompatiblitet og touch events, er Page 53 of 139

54 Produktrapport Meteor relativt bra. I oppstarten var for eksempel ikke touch events mulig, men dette er nå rettet opp (Colllin, 2014). Men det er enkelte funksjonaliteter som ikke fungerer som de skal, disse er planlagt å rettes opp i. For eksempel i android er det foreløplig en uønsket highlighting ved at siden ikke blir tilgjengelig før man har trykket en gang på linken man ønsker Valg av rammeverk Vår analyse konkluderte med at Angular var best egnet for prosjektet vi skulle utføre utifra de kriteriene vi hadde gitt for analysen. Derfor har vi valgt å produsere en prototype som benytter dette rammeverket videre i oppgaven. På denne måten kan vi teste om rammeverket fungerer slik vi ønsker, se punkt for hele analysen. 4.4 Diagrammer For å oppnå godt design på prototypen var det viktig å planlegge hvordan en går frem for å opprette nettsidene. Diagrammer kommer derfor godt med. Det hjelper til med å forstå hvordan navigeringen mellom nettsidene og funksjoner skal fungere, hvordan oppsettet av databasen skal se ut og eventuelle problemer med kommunikasjon mellom bruker og system Klassediagram Vi har valgt å lage et klassediagram som viser attributtene vi har i vår tabell i databasen, for å legge til et nytt abonnement. Databasen vår består kun av disse attributtene per dags dato, men klassediagrammet ville vært mer forklarende hvis vi hadde hatt flere tabeller og ikke bare kunder tabellen. Et klassediagram sier hva slags attributter som ligger i en tabell (Grønning, 2008). Som i dette tilfelle er: Fornavn, Etternavn, Fødselsdato, Nummer, Abonnement, TilleggSikker, TilleggSky og Datapakke som vi kan se ut av figur 12. Hadde vi hatt flere tabeller ville en også kunne sett relasjonene mellom de forskjellige tabellene. Figur 12: Klassediagram Page 54 of 139

55 Produktrapport Aktivitetsdiagram Figur 13: Aktivitetsdiagram forklarer fremgang for opprettelse av abonnement Som et hjelpemiddel for planleggingen og oppsettet av prototypen ble det utviklet flere aktivitetsdiagram som forklarer trafikkflyten i ulike oppgaver for systemet. Figur 13 viser et av aktivitetsdiagrammene som ble laget. I dette aktivitetsdiagrammet ser vi hvordan bruker kan bevege seg på nettsiden fra hovedsiden, og frem til innsending av bestilling for et abonnement. Dette er en nyttig modell som gir oss mulighet til å se oppsettet på siden. Her ser vi hvordan brukeren navigerer seg frem og tilbake for å utføre en gitt oppgave. På denne måten blir eventuelle navigeringsproblemer som fører til at en person ikke kommer seg videre i systemet avduket. For flere aktivitetsdiagram knyttet til prototypen, se vedlegg 5. Page 55 of 139

56 Produktrapport Use case ca b m i i a m m kunden og system. Det forklarer hvilke komponenter aktørene kommuniserer med D av m dia amm, m b i b a hv da stem fungerer i praksis (Margaret Rouse, 2007). I tillegg til et use case diagram bruker man gjerne en use case beskrivelse, som forklarer hvordan forløpet i m B iv a v a a iv m d a b m t use case viser hvordan bruker interagerer med systemet. Vi har tre forskjellige use case beskrivelser. De beskriver hvordan bruker sjekker abonnement, laster ned faktura og oppretter abonnement. Under viser vi hvordan bruker sjekker abonnementet sitt. De to andre use case beskrivelsene kan du finne under use case i vedlegg 6. Page 56 of 139

57 Produktrapport Use Case Navn MinBedrift 2.0 prototype Sjekke abonnement Aktører Trigger Bruker av nettsiden, systemet (database) Bruker logger inn i systemet Prebetingelser 1. Brukeren har tilgang til en firmakonto i MinBedrift 2. Brukeren har et eller flere aktive abonnementer Postbetingelser Bruker har fått ønsket informasjon om et enkelt abonnemnet Normalflyt (Hovedflyt) 1. Bruker trykker på «abonnement» knappen 2. Listen over alle abonnementer vises 3. Bruker velger ønsket abonnement 4. Graf og utvidet informasjon vises for bruker Variasjoner (Alternativer og feil) 1. a) Bruker trykker ikke på «abonnement» knappen - Bruker navigerer gjennom hovedmeny 2. a) Listen over abonnementer vises ikke - Bruker må oppdatere siden - Ingen kontakt med database, systemansvarlig varsles 4. a) Bruker får ikke opp korrekt informasjon om abonnement - Bruker må oppdatere siden - System ansvarlig må varsles Page 57 of 139

58 Produktrapport 4.5 Universell Utforming For å gjøre produktet brukervennlig har vi benyttet oss av flere forskjellige metoder. Som alle bidrar på forskjellige måter, slik at produktet blir mest mulig tilgjengelig for alle. Vi har derfor valgt å trekke frem enkelte tiltak vi har gjort for å gi produktet en universell utforming. Figur 14: Figur av opprett abonnement Vi har benyttet oss av store og tydelige ikoner på hovedknappene (se figur 14), slik at brukeren enklere skal forstå hva som ligger bak. Dette bidrar blant annet også for personer med dysleksi, synsvansker, og ikke minst for personer som har utfordringer med koordinasjon eller skjelvinger, da det kan være utfordrende å treffe små linker eller knapper. Bruk av alternativ tekst på bilder i Html er med på la diverse programmer med «tekst til tale» forstå hva et bilde gjør, hvordan det ser ut og hvor en eventuell link vil føre brukeren. Brukeren som benytter seg av slike programmer vil få den alternative teksten til bildet lest opp, svært praktisk for svaksynte/blinde personer. Under kan vi se hvordan vi har bruk alternativ tekst i vår oppgave. Figur 15 viser hvordan vi har tatt i bruk alt-taggen på et bilde element inne i en hyperlink tagg (<a>). Figur 15: Visning av alt tekst tagger på prototypen Vi har også benyttet oss av hjelpemidler i grafen som viser en person sitt forbruk. Som en innebygd funksjon i grafen får brukeren presentert ulike data etter hvor på grafen brukeren fører pekeren. Vi ser på figur 16 at informasjon om hvor mange minutter av totalen som er igjen på abonnementet kommer i et tekstfelt. Slike fuksjoner øker brukervennligheten på generell basis, men har ikke en direkte funksjon for personer med funksjonsnedsettelser. Page 58 of 139

59 Produktrapport Figur 16: Eksempel på fremstilling av et forbruk i prototypen Vi har også gjennomgående hatt et ønske om å minimere mengden informasjon som vises på skjermen samtidig. Dette for at bruker skal ha mindre å forholde seg til på en gang, men heller få spesifisere selv hvilken informasjon som skal vises. En måte vi har valgt å gjøre dette på er ved å benytte drop-down menyer som skjuler utvidet informasjon. Her er det da viktig at informasjonen grupperes på naturlig og lett forståelig måte. På figur 17 ser vi hvordan vi har informasjonen skjult, men samtidig tydelig definert, slik at bruker ikke må lete etter informasjonen. Figur 17: Dropdown meny fra prototypen Det er med færre forstyrrende elementer på siden enklere å fokusere på den viktige informasjonen, noe som kan være til stor nytte for personer med konsentrasjonsvansker. Page 59 of 139

60 Produktrapport Ved rapporten har vi også valgt å fokusere på at denne skal være universelt utformet. Dette er gjort ved at overskrifter benytter automatiske headinger i word dokumentet og at alle figurer er lagt inn med en alternativ «alt» tekst under formatering. Med dette vil figurer og overskrifter leses opp ved et tekst til tale program som en overskrift og bildene får en tittel og forklaring. 4.6 Implementering Ved implementering mener vi at du setter programmererne i arbeid. Det er her systemet blir kodet. Opprinnelig benyttes dette for å gjennomføre et konsept. Frem til dette punktet er det ikke laget noe software/hardware som kan leveres til kunden. Det meste frem til dette punktet er bare skisser, ideer og analyser på hvordan en skal utføre de ulike oppgavene. Under implementeringen begynner selve kodingen av systemet som skal leveres til kunden Programmeringsspråk Vi har benyttet oss av flere ulike programmeringsspråk og rammeverk under utviklingen av prototypen. Dette for å få gjennomført og satt til liv, de funksjoner og ideer som vi har hatt et ønske om at skal være en del av prototypen. Grunnstammen i prototypen består av HTML5 og CSS (CSS3), med i hovedsak Angular.js funksjonalitet bygget oppå slik som oppgaven legger opp til. I tillegg har vi blitt nødt til å ta i bruk PHP, grunnleggende for å kommuniserer med MySQL database på skolens server. Med tanke på den grafiske fremstillingen av forbruket til en enkelt person i en bedrift, har vi benyttet oss av et javascript rammeverk som heter Highcharts. Gruppen valgte å ta med HTML og CSS under dette punktet selv om dette ikke kalles programmeringsspråk, men henholdsvis Markup Language(HTML) og Stylesheet Language(CSS). Page 60 of 139

61 Produktrapport Html Som nevnt er grunnstammen i prototypen bygget på HTML5 og CSS, som er grunnleggende i svært mange nettsteder (Quackit, Udefinert). Html5 (Hypertext Markup Language) er en videreutvikling av HTML 4 standarden, og erstatter denne samt XHTML og HTML DOM Level 2 (W3Schools, Udefinert-b). HTML går i utgangspunktet ut på å definere elementer/tagger som definerer dataene som taggen inneholder, slik at nettleseren kan forstå hvordan informasjonen skal vises til brukeren (Margaret Rouse, 2005c). Da HTML5 er anbefalt av W3C (Berjon et al., 2014) er det naturlig for oss å benytte oss av dette språket for å får god funksjonalitet i samtlige nettlesere, og få en trygghet på at vårt arbeid blir presentert gjennom et stabilt språk. Vi har som gruppe god kjennskap til HTML, derfor har ikke denne delen av utviklingen av prototypen gitt oss nevneverdige utfordringer. Vi har i stor grad benyttet oss av «div» tagger med «id» (identitet) og «class» (klasser), for å Figur 18: HTML kode fra prototypen kunne styre elementene gjennom stilarket som følger med. Som vis på figur 18 ser vi hvordan vi har definert id og klasser i html filen. Vi vil ikke gå videre inn på hvordan vi har benyttet Html i prototypen vår, da dette er relativt elementært og noe som ligger til grunn i de fleste nettsider. Page 61 of 139

62 Produktrapport CSS CSS (Cascading Style Sheets) er en standard som skal utfylle HTML hva angår stil og utforming (Garshol, 1999). Det er i CSS dokumentet W3C ønsker at utviklerne skal definere hvordan HTML elementene skal fremstå for brukerne. Da også CSS er anbefalt av W3C (Bos, Lie, Lilley, & Jacobs, 1998), er det her også naturlig for å benytte oss av denne metoden for å definere hvordan elementene fra HTML koden skal fremstå. Grunnen til at vi nevner CSS3 er fordi dette er en utvidet standard av CSS2, med nye fuksjonaliteter som skal gjøre kombinasjonen av HTML og CSS mer kraftfull (W3Schools, Udefinert-a). Som for eksempel funksjonen «border-radius», som vi har benyttet i vår løsning. Dette er en funksjon som gir utvikleren mulighet til å definere hvor avrundete hjørnene på et element skal være. CSS har vi også benyttet ved flere anledninger gjennom fag på høgskolen. Vi har benyttet oss av enkelte funksjoner fra den relativt nye standarden CSS3, da hendholdsvis «box-shadow» og «border-radius». Dette legger til skygge effekt og runde hjørner på de elementene hvor man ønsker dette. Selve arbeidet med stilarkene har ikke vært videre problematiske for vår del, sett bort ifra at det blir en del prøving og feiling før utformingen av nettstedet blir slik man ønsker. Page 62 of 139

63 Produktrapport Angular Selve kjernen i hele oppgaven vår var å benytte Angular.js i enkelte funksjoner på siden, for å vise litt av potensialet i dette javascript rammeverket. For mer utfyllende informasjon rundt Angular.js, se tilbake på analysedelen tidligere i rapporten. I oppgaven vår vil Angular.js tilføre en større grad av dynamisk innhold, som for eksempel ved bilde/reklame slideshow, listing av abonnementsdata og dropdown funksjonalitet. Da vi ikke hadde noe grunnlag for å utvikle noe i Angular.js, var det utfordrende å få dette til å fungere riktig. På figur Figur 19: Kodesnutt av Angular scriptet for dropdown menyen 19 ser vi hvordan scriptet til en enkel dropdown meny kan se ut i Angular.js, denne koden er forøvrig hentet fra vår prototype. På bakgrunn av denne lille koden, skjønner vi at en med relativt lite kode kan lage kompliserte funksjoner ved hjelp av Angular.js. Da en lignende dropdown fuksjonalitet utviklet med kun Html og CSS ville gitt svært mange kodelinjer. Page 63 of 139

64 Produktrapport PHP/Mysql Vi har også benyttet oss av PHP (Hypertext Preprocessor), et script språk som er spesielt designet for å kunne brukes med Html (PHP, 2014). PHP er et språk vi har blitt ganske godt kjent med etter å ha hatt dette som et emne i et par semester. Allikevel var det i utgangspunktet ikke planlagt at PHP skulle få en stor rolle i dette prosjektet. Men da vi skulle koble front-end delen av prototypen med MySQL databasen som ligger i bakgrunnen, ble PHP svært aktuelt å benytte seg av. Både direkte mellom databasen og html elementene, men også mellom Angular scriptet og databasen. På figur 20 ser vi hvordan vi har brukt PHP til å knytte kontakt med databasen som ligger på hjemmeområdet til høgskolen. Scriptet starter ved at det kommer et signal fra bruker om å sette noe inn eller hente noe ut fra databasen, som for eksempel når en ny bruker skal opprettes. Figur 20: PHP kodesnutt demonstrerer tilkobling til databasen Page 64 of 139

65 Produktrapport Highcharts Et av delmålene i oppgaven vår var å presentere data over mobil forbruket til en person, gjennom en grafisk fremstilling. Skulle vi programmert en dynamisk graf i Angular, ville vi ikke rukket å gjøre annet gjennom dette prosjektet. Da dette ville blitt en svært tidkrevende og komplisert prosess. Vi har derfor benyttet oss av et javascript rammeverk som er spesielt utviklet til dette formålet, ved navn Highcharts. Highcharts er et tilgjengelig gratis for ikke kommersiell bruk, som for eksempel skole prosjekter (Highcharts, udefinert). Noe vårt prosjekt er, da vårt produkt er en prototype kun utviklet for denne oppgaven. Highcharts er skrevet i ren javascript, og utviklet av Highsoft AS (Highsoft, 2013), et norsk basert utviklingsteam. Highcharts tilbyr en rekke demoer av de mulighetene man får ved å benytte seg av rammeverket (Highcharts, 2013), noe som gir en kickstart på utviklingen for brukerne. Disse demoene hjalp også oss for å få utviklet en graf som gir den fremstillingen vi ønsket i vårt prosjekt. Figur 21: Kodesnutt av highchartet for stolpediagrammet Når det kommer til vår bruk av Highcharts rammeverket, har det i hovedsak handlet om å skjønne hvordan de forskjellige elementene i skriptet henger sammen. Slik at vi klarer å bruke funksjonaliteten på den måten vi ønsker, og få visualisert de dataene vi vil presentere. Siden ingen av gruppe medlemmene har bred kunnskap om javascript, og da særlig ikke Highcharts, merket vi at små endringer i utgangspunktet kunne ta lang tid. Eksempelvis da vi ønsket å endre farger på søylene i grafen. På figur 21ser vi hvordan vi har definert kategoriene Data, SMS, MIN og MMS. Vi ser også hvordan de forskjellige verdiene på hver søyle i diagrammet blir bestemt. Page 65 of 139

66 Produktrapport Design Design er viktig for at nettsiden skal være enkel og navigeringsoversiktlig. Her var det viktig å få frem de tre hovedkategoriene. Forsiden skulle bestå av tre store firkantede knapper med hver sin forklarende figur. Denne figuren skulle representere temaet for knappen, f.eks. telefon til abonnement. Dette for å gjøre det enkelt for bruker å forstå hvilken side du kommer til hvis du trykker på knappen. I tillegg til design på knappen er det en forklarende beskrivelse på knappen. For å få knappene til å virke enda mer interaktive, brukte vi funksjonene CSS: h v S c I tillegg til knappene på forsiden, ville vi lage et holdbart rammeverk rundt hele nettstedet. Med dette mener vi at skjelettet til sidene skal være brukervennlig. Rammeverket skal følge Dr. Jack Nielsens studier om øye-bevegelses mønstre i å lese nettsider (Chapman, 2010). Dr. J. Nielsen fant ut at internettbrukere, i stort flertall, leser innholdet på websider i et F- mønster. Det vil si at man leser overskriften først, deretter skumleser man litt under samtidig som man følger venstre siden nedover. Bildet til høyre her viser resultatene fra undersøkelsen til Dr. Nielsen. Her ser man tydelig at innhold på høyre siden blir i stor grad neglisjert (Chapman, 2010). Figur 22: Dr. J. Nielsens illustrasjon av lesemøster på web P av d ha vi va v i i v id Sid ab m vi a m d d i, i, midd a v i høyre. Også på faktura siden er alt mer venstrestilt, og du ser året 2014 stå først. Fargevalg har også vært viktig for nettsiden, da vi har i tankene at nettsiden skal brukes til bedriftskunder. Det skal være nøytrale farger, og bruk av Telenor sine farger skal være fremtredende. Derfor har vi valgt å bruke Telenor sin blå farge, og resten av siden i grå toner. Page 66 of 139

67 Produktrapport Photoshop Vi har valgt å bruke verktøyet Adobe Photoshop for å lage knapper til websiden. Adobe Photoshop er et avansert data program som blir flittig brukt av grafikere og illustratører for å redigere bilder. Men det kan også brukes til å lage ulike grafiske fremstillinger av for eksempel knapper til webside, som vi har gjort. Photoshop legger til rette for flere muligheter innenfor farge separeringer, pantone-farger og fargestyring (Wesley & Umstot, 2012). Dette er noe av grunnen til vi valgte å utforme knappene våre i Photoshop. Fargene vil bli korrekt gjengitt på websiden når det lagres, og det er også mulighet å lagre bildene i Adobe Image Ready som er optimalisert for Internett. Først lagte vi en side med ulike farge nyanser (figur 23Figur 23), disse fargen var tatt ut ifra den eksisterende siden til Telenor. Deretter fant vi ikoner på Internett som vi utformet videre. Vi laget ulike prototyper av knappene, med skriften og bakgrunnen i ulike farger for å se hvilke som passet best på Internett siden (figur 24). Figur 23: Fargeskalaer Figur 24: Utforming av knapper Page 67 of 139

68 Produktrapport Database design Databasen som vi har benyttet oss av i prototypen vi har utformet er laget i MySQL som er et query basert språk (Oracle, 2014). Som vil si at informasjonen blir lagt inn i databasen, for så og skrive querys (eller spørringer som vi ofte sier på norsk), som returner ønsket informasjon fra databasen. Slik vi har bygd opp siden, er det ikke nødvendig med flere enn en tabell i databasen, denne tabellen har vi valgt å kalle for Kunder. Den består av følgende felter: Figur 25: Databasen for prototypen Feltene under Field i tabellen er de som blir fylt ut og lagt til i databasen når en legger til et nytt abonnement. Uansett om man bruker malene eller om man oppretter et egendefinert abonnement. Vi lister bare ut informasjon som fornavn, etternavn, nummer og abonnementstype på siden hvor alle abonnenter er listet ut. Vi ønsket egentlig å bruke en NoSQL database, dette fordi det samarbeider veldig bra med AngularJS og er veldig enkelt å bruke. Databasen vi hadde tenkt å benytte oss av heter MongoDB og er en dokumentbasert database (MongoDB, ). Som vil si at en bare trenger og opprette dokumenter som oppdateres på serveren. Her vil du få tilgang til informasjonen i «riktig» format i forhold til det Angular operer med som er JSON. Men på grunn av restriksjoner på skolens server angående hva vi har lov til å legge inn av programmer, måtte vi bruke MySQL i stedet. MySQL er litt mer tungvindt å bruke i forhold til samarbeidet med Angular og dens funksjoner som listing av informasjon og å legge til i databasen. Disse er funksjoner som vi bruker i prototypen vår. Men MySQL er en database Page 68 of 139

69 Produktrapport alle fire i gruppen har jobbet med før og har god kjennskap til på grunn av et fag på skolen. Derfor var det en grei oppgave å opprette databasen og koble til. Det som var problemet vårt var å få informasjonen på riktig på format, og å få loadet den på riktig måte. Etter litt søking og et par mislykkede forsøk fikk vi det endelig til å fungere slik som det skulle. Det gikk litt mere tid på å få opp en database enn vi hadde planlagt. Vi fikk ikke bruk for noe vi hadde brukt tid på å lære oss. En annen faktor var at vi ikke fikk til og vise frem det som lå i MySQL databasen på riktig måte Teknisk løsning Vår prototype ble utviklet med fokus på de to funksjonene vi ønsket å få testet på vår nettside. Den første funksjonaliteten vi ønsket å lage var en side som ga bruker mulighet til å opprette et nytt abonnement. Dette skal gi mulighet for å bestille et abonnement ved å bare legge inn navn og fødselsdato eller muligheten for å opprette et egendefinerte abonnementer. Det andre punktet var å fremstille dagens forbruk for de ulike abonnementene, ved hjelp av en visualisering. Da oppgaven om å utforme en prototype ble utført for å tilfredsstille Høgskolen i Oslo og Akershus sine krav til bacheloroppgave, har gruppen valgt å ikke benytte logo eller annen tilknytning direkte til Telenors merkevare i prototypen. Dette var et valg som ble gjort for at prototypen skulle kunne være tilgjengelig på nettsidene til HiOA. Prototypen startet med en forside før bruker var logget inn. Denne forsiden skulle da inkludere flere bilder med tilbud for bedrifskunder. Dette er en side alle har mulighet til å se uansett om man er bedriftskunde eller ikke. Videre logger en seg inn med brukernavn og passord øvest på høyre side av prototypen. Per dags dato er dette ikke en sikker innlogging da gruppen ikke har hatt dette som fokusområde. Men det er en illusjon av at hensikten med prototypen skal være en sikker innlogging for kundene. Prototypen gir automatisk omdirigering til startsiden for en bruker som er logget inn. Page 69 of 139

70 Produktrapport Figur 26: Førsteside før innlogging Førsteside etter innlogging Bedriften man logger inn som da er «Dagens næringsliv», men tall og regninger er alle fiktive. De er kun brukt for å vise bruker reelle data. Som bruker så er meningen at du skal få oppgitt alle alternativer tilgjengelig på siden ved hjelp av store knapper. Dette skal da gi alle brukere god mulighet til å finne frem, ved å velge favoritter som skal vises som store knapper. Slik som prototypen er i dag finnes det tre knapper som dirigerer bruker videre på siden. Disse knappene er linker til sidene abonnement, faktura og opprett abonnement. På siden ser man også en logo som går igjen flere steder. Logoen vises øverst på siden i den blå linjen, i fane feltet og øverst i det hvite feltet midt på siden sammen med skriften Telecom. Telecom er et fiktivt selskap vi har valgt å bruke. Dette for at siden skal se så reell ut som mulig m d i v d id av ba, m vi i a d vi a id vi ha i v a i a i i ba i ø id, etter innlogging. Dette er noe de fleste sider i dag har, og vi har valgt å ta det med på vår side også. Den blå linjen har også logg inn og logg ut funskjonen. Kunden logger ut av siden ved å trykke på navnet sitt, der det vises at du er logget inn. På førstesiden er det også en hovedmeny som også er global. Hovedmenyen inneholder linker til de andre sidene som finnes på vår prototype, så en kan enkelt navigere seg frem og tilbake. Nederst på siden er det også en global meny, med den samme funksjonen som hovedmenyen. Denne leder også til de forskjellige sidene vi har i vår prototype. Vi har også valgt å ta med navnet på bedriften som er logget inn på siden, som prototypen vår viser, Dagens Næringsliv. Hvilket selskap som er logget inn står rett over skillelinjen som er over knappene. På abonnement siden har vi alle de globale menyene, og de andre globale feltene. I tillegg til disse, har vi byttet ut knappene med en liste hvor alle abonnementene i den gitte bedriften er Page 70 of 139

71 Produktrapport listet ut. I denne listen vises fornavn, etternavn, nummer og abonnementstype. Alle navn og nummer i listen linker bruker videre til abonnementsidene, hvor vi har de grafiske fremstillingene. En kunde kan også gjøre et søk på navn eller nummer. Da vil listen oppdatere seg automatisk etterhvert som en skriver inn det kunden vil søke på. På andre siden av søkefeltet er det en teller som forteller bruker hvor mange abonnement som er i listen. En annen ting vi kan se har endret seg på denne siden, er at vi har fått en brødsmulesti der bedriftsnavnet sto på førstesiden. Denne kan hjelpe kundene med å vise hvor på siden de er og gjøre det enklere og navigere seg tilbake til det en ønsker å se på. Figur 27: Fremstilling av abonnementer Velger kunden å klikke på et av abonnementene i listen, får de opp en side hvor en ser hver enkelt brukers forbruk. Det er her en av de funskjonalitetene som vi ble enig med user experience teamet til Accenture om kommer frem. Det er den visuelle fremstillingen av forbruket for en enkelt bruker. Den er dynamisk, så kundene kan velge om informasjonen som skal vises er det de har brukt, det som er igjen, det som er overskredet eller alle tre samtidig. Det er et stolpediagram som justeres etter hver enkelt brukers forbruk. Under fremstillingen vises en dropdown-meny. Denne kan en klikke på, for å få opp mer detaljert informasjon om ekstra kostnader, og totalprisen for inneværende måned. På andre siden under fremstillingen har vi lagt inn en funksjon som vi har gitt navnet bestill nytt sim-kort. Dette var noe som kom Page 71 of 139

72 Produktrapport frem av brukertesten vi var med på hos Accenture, at var noe kunden brukte mye og ville ha lett tilgjengelig på nettsiden. Figur 28: Fremstilling av forbruket til en kunde Faktura siden innholder fakturakopier fra to år tilbake i tid. Det er et krav til Telenor at alle kunder skal ha fakturakopier fra to år tilbake. Slik løsningen til Telenor ser ut i dag, er det veldig mange kunder som ringer inn og bestiller dette, så de får det i posten. Begrunnelsen for dette var at det var vanskelig å finne en løsning slik situasjonen er i dag. Så dette var noe vi mente burde være veldig enkelt, og vi har prøvd å lage en løsning. Vi har valgt å legge de tre siste fakturaene i en «hurtigmeny», dette fordi kundene skal kunne se at regningene er betalt, og at de skal kunne gå inn og se at tallene stemmer. Disse fakturaene er bare noe vi har laget selv, og er selvsagt ikke reelle. Under «hurtigmenyen» finner kunden tre dropdown-menyer for de to siste årene. En meny for 2014, en for 2013 og en for Klikker kunden på en av disse kommer det opp en liste hvor de kan velge faktura for måneden de er på jakt etter. Page 72 of 139

73 Produktrapport Figur 29: Fakturalister Velger kundene å gå til siden som heter opprett abonnement får de opp fire knapper en kan trykke på. Dette er den andre funksjonaliteten vi ønsket og ha med på siden. Vi føler vi har løst denne på en fin måte og endte opp med et godt resultat. En for egendefinerte abonnement og de tre andre som er lite, middels og stort som er maler hvor kunden fyller inn navn og fødselsdato. Figur 30: Knapper for malene på opprett nytt abonnement Klikker kunden på en av disse knappene lastes et skjema opp i feltet under knappene. Hvis kunden klikker på egendefinert får de opp at en må fylle ut fornavn, etternavn, fødselsdato, hvilken abonnementspakke som skal være gunnpakken. Kunden velger deretter flere tilleggtjenester, som de ønsker å ha inkludert i pakken, som for eksempel skytjenester og datapakker osv. Disse tilleggstjenestene velger de ved å klikke på en radiobutton eller i sjekk Page 73 of 139

74 Produktrapport boksen, som er ved siden av tilbudet kunden ønsker skal være med i pakken. Hvis kunden oppretter et abonnement ved å bruke malene lite, middels eller stort er det bare fornavn, etternavn og fødselsdato de trenger å fylle ut. På malene står det også hva som inngår i de forskjellige abonnementspakkene. Figur 31: Egendefinert mal for oppretting av nytt abonnement Figur 32: Mal for opprettelse av abonnementet "Lite" 4.8 Mulige utvidelse av Min Bedrift 2.0 Siden i dag er bare en prototype i forhold til hva som egentlig bør være med i en fullverdig løsning. Gruppen har hatt mange ideer på hvilke funksjoner som skal være med i prototypen. Dette måtte begrenses for å bli ferdig med selve utformingen av løsningen. En ide var at kundene skal kunne velge hvilke snarveier som skal være på førstesiden etter innloggingen. Kunden kan her velge sine egne favoritter som skal vises på denne siden. Dette fordi kundene skal kunne jobbe raskest og enklest mulig i forhold til hva de ønsker å utføre på siden. En fullverdig applikasjon vil ha flere funksjoner av knapper enn det vi har, og da mener vi at kundene skal kunne velge hvilke av disse som skal ligge på førstesiden deres. Vi har erfart etter å ha vært med på brukertesten til Acccenture for Telenor sin nye løsning MinBedrift 2.0, at kundene har veldig ulike behov på en slik side. Noen kunder er bare interessert i å se forbruk og regningene deres. Andre er mer opptatt av at de enkelt skal kunne gå inn og endre på abonnementer, og bestille tilleggstjenester som nye sim-kort, datapakker osv. Vi mener at det kan være hendig med en funksjon, som hjelper deg og velge dine egne snarveier. Mange bedrifter som nettbanker tilbyr allerede dette sine kunder. Page 74 of 139

75 Produktrapport Vi har også flere funksjoner som sletting og endring av abonnementer, som funksjoner å ha med på nettsiden. Dette for at kundene selv skal kunne gå inn på siden og bruke den til å gjøre slike ting selv. Det skal ikke være nødvendig for kunde å ringe inn og betale penger for at en på kundesenteret skal gjøre den jobben. Disse funksjonene må selvsagt være godt synlig, og enkle å bruke. Dette for at kundene skal velge å gjøre dette selv, hvis ikke vil mange fortsette og ringe inn for å få dette gjort. En annen funksjon vi mener burde være på en slik side er en slags logg funksjon som viser hva som er blitt gjort av endringer på kundens side. Denne vil da vise at et abonnement er blitt slettet eller om det har blitt gjort noen endringer på de abonnementene som kunden har. Den vil også vise dato og tid endringene har blitt gjort på. Slik siden er i dag har vi ikke en optimal logg inn, denne er bare satt inn som en «dummie», for dette er noe som absolutt bør være med på en slik side. På grunn av prototypen har vi valgt å ikke ta med denne funksjonen. Dette for at det skal være enkelt å få sett siden og at det ikke skulle bli noen feil på grunn av denne funksjonen. Sikkerhet er selvsagt også viktig for at kundene skal kunne stole på siden, og at uautoriserte personer ikke skal ha tilgang til en slik side. Hvem som helst skal ikke kunne gå inn og endre på abonnementer, og eventuelt ødelegge for en bedrift. Så en sikker og god logg inn må være på plass på siden, før siden implementeres og kundene tar den i bruk. Page 75 of 139

76 Evaluering 5.0 Evaluering av løsning og prosjekt Med evaluering mener vi hvordan prosjektet ser ut i forhold til de kravspesifikasjonene vi har satt. Er det dette kunden vil ha? Fungerer systemet slik det er tenkt ut at det skal? Rett og slett om man har fått til det man skal i følge kravspesifikasjonene. 5.1 Evaluering av teknisk løsning Etter gjennomføringen av prosjektet vil gruppen vurdere den prototypen som en god løsningen. Den tekniske løsningen skulle etter vår evne gi oss mulighet til å teste brukervennlighet og funksjonalitet, for så å vurdere dette opp mot problemstillingen. Dette føler gruppen at er mulig å utføre på prototypen, da vi får testet både ønsket funksjonalitet og brukervennlighet. Optimalt sett burde vi tilført flere funksjoner for å gjøre prototypen mer tilnærmet lik et ferdig produkt. Men dette ble ikke innført da fokuset ikke var på å videreutvikle siden, men konsentrere seg om funksjonene gruppen hadde definert tidligere i prosjektet. Denne delen presterte gruppen å løse på en god måte i forhold til kompetansen som lå til grunn. Vi er fornøyde med kunnskapen vi har tilegnet oss innen javascript. Med bakgrunn innen brukerrettede fag var programmeringskunnskaper en av svakhetene til gruppen ved starten av prosjektet, men gjennom arbeid har prototypens kompleksistet økt i takt med vårt ferdighetsnivå. Page 76 of 139

77 Evaluering 5.2 Evaluering av prosjektgjennomføring Som nevnt tidligere så har samarbeidet i gruppa gått veldig fint. Vi har klart å fordele oppgavene i forhold til hvilke interesse punkter de forskjellige prosjektdeltagerne har. Gruppa har gjennom hele prosjektperioden jobbet med utviklingsprosessen Scrum, og vi har klart å fortsette denne prosessen gjennom hele prosjektet, se punkt 3.3. Takket være godt samarbeid har vi klart å fullføre rapporten og lage en prototype som vi er fornøyd med, og som tilfredsstiller de krav vi og oppdragsgiver har satt. Vi har stått ganske fritt til å velge de funksjonene vi selv mener er nyttig på nettsiden. Dette har gitt oss nye muligheter til å analysere moderne rammeverk, utarbeide ideer rundt design og arbeide med brukervennlighet på nettsiden. Dette har stilt krav til gruppen om å sette seg inn i ukjente teknologier, og gitt oss nye spennende utfordringer. Vi har også hatt mulighet til å være med User experience teamet på brukertester de utførte. Dette hjalp oss med videre utforming og inspirasjon til vår egen brukertest som vi skulle utføre. Gruppen har hatt noen små endringer i fremdriftsplanen siden vi satt den opp i begynnelsen av prosjektet. Vi brukte mer tid enn estimert i starten med å definere selve oppgaven, dette fordi vi var usikre på hvordan vi skulle løse oppgaven. Etter møte med User Experience teamet til Accenture, klarte vi å definere hvilke funksjoner vi skulle satse på. De første ukene av prosjektet ble litt uproduktive på grunn av usikkerheten, og det vi fikk gjort var å lage styringsdokumenter. Her a d vi i i a, mid idi mi æ a ama b id a i i a ha i a, vi ha b i a vi ha a di vi ha d væ mi ima m d avæ i ad i a, hvi d ha væ, ha vi ø dette med god kommunikasjon imellom oss så fremgangen ikke skulle stagnere. Gruppen brukte også mye tid på å tenke på fargevalg og bakgrunnen til selve siden, noe som viste seg å være litt unødvendig for selve løsningen vår. Resultatet av oppgaven vipper mer mot brukervennlighet, og løsning opp mot funksjonene. Etter analysen av rammeverk fant vi ut hvilket rammeverk vi ville bruke i løsningen. Her gikk det også mer tid enn gruppa hadde estimert, i forhold til at Angular var et vanskelig Page 77 of 139

78 Evaluering rammeverk å sette seg inn i. For å hente inn tid fant gruppa ut at vi skulle bruke HTML, CSS og PHP i noe av utformingen av prototypen, se punkt 4.6 Dette fordi vi er kjent med disse programmeringsspråkene fra studiene. Det førte til at gruppa igjen klarte å hente inn tid, og ferdigstille prototypen til brukertesting. Vi skulle gjerne ha utført flere brukertester etter at vi endret på nettsiden etter den første brukertesten, men dette fikk vi ikke tid til på grunn av sprekk i fremdriftsplanen. Samarbeidet med veileder hos Accenture har gått veldig fint og han har fungert som en produkteier for gruppa. Vi har hatt sprint backlog møter med han, der vi har gått igjennom progresjonen av prosjektet, problemer vi skulle ha løst, eller hva som måtte utføres. Han jobber selv som utvikler, og kan mye om rammeverket Angular, men mindre om brukervennlighet og hvilke funksjoner som er viktig på en nettside. Hvis det var noe han ikke kunne hjelpe oss med, satt han oss i kontakt med noen på Accenture som kunne hjelpe oss, som for eksempel User Experience teamet. Page 78 of 139

79 Evaluering 5.3 Oppdragsgivers evaluering av løsningen Veileders tilbakemelding Gruppen fikk i oppgave å gjennomføre et analyseprosjekt av fremtidsrettet webteknologier knytte opp mot brukeropplevelse. Oppdragsgiver var Accenture AS og et av deres prosjektteam hos Telenor Norge. Gruppen har hatt fri tilgang til Accentures lokaler på Fornebu og hatt jevnlig veiledning fra en fast veileder samt andre ressurspersoner fra Acc Ex i c Gruppen har jobbet selvstendig og selv tatt initiativ til å booke møter med ressurspersoner i firmaet og skaffet nødvendig inspirasjon og avklaringer. De har jobbet agilt(scrum) igjennom hele prosjektet, med tre ukers sprinter, og jevnlige møter med veileder for å demonstrere forrige sprint og planlegge neste. Gruppen hadde to presentasjoner for en styringsgruppe bestående av ca. 10 personer i løpet av prosjektet. Den første presentasjonen gikk på å presentere sin forståelse av oppgaven og deres plan for gjennomføring. Den siste gikk på å presentere resultatet av oppgaven og sine erfaringer underveis. Styringsgruppens tilbakemeldinger var generelt positive, men spesielt gruppens evne til å ta en i utgangspunktet åpen oppgave og gjøre den konkret og verdiskapende ble trukket frem som store pluss. Gruppen har på en god måte tatt oppgaven og gjort den til sin egen og vist et stort engasjement. Oppdragsgiver er godt fornøyd med gruppen. Henning Engen TGP ADI Accenture Norway Page 79 of 139

80 Testdokumentasjon 6.0 Testdokumentasjon Testingen av systemet er en viktig del av utviklingen av et produktet. Ved hjelp av testing kan man finne ut hva som fungerer og ikke. Systemet testes for mulig feil som kan oppstå og for uventede feil. Hvis uventede feil oppstår, kan man gå tilbake til starten av utviklingen og se etter mulige feilmeldinger. Her er det viktig å teste de funksjonelle og de ikke-funksjonelle kravene. Og om de fungerer i praksis slik de er beskrevet i kravspesifikasjonene. 6.1 Spørreundersøkelse Det var ønskelig å få litt brukerinnsikt i forhold til dataene som skulle fremstilles grafisk. Derfor ble det valgt å gjennomføre en spørreundersøkelse. Spørreundersøkelsen var anonym slik at vi ville få flest mulig ærlige svar. Det viktigste med undersøkelsen var å få svar på hvilke visualisering forbrukeren foretrakk og om vedkommende klarte å forstå dataen i de ulike grafene. Spørreundersøkelser er en av de brukerinnsiktsstudiene som benyttes for å skape gode brukeropplevelser og derfor var det viktig å planlegge undersøkelsen nøye (Bergem, 2013). Det var flere elementer å tenke på da. Slik som Bergem foreslår i sin oppskrift for spørreundersøkelser var det for eksempel viktig å informere eventuelle svarpersoner hvor lang tid det omtrentlig ville ta å gjennomføre spørreundersøkelsen, samt sørge for gode og presise spørsmål og en god rekkefølge på plasseringen av spørsmålene. For at testpersonene skulle få et klart bilde av visualiseringene, var fremvisning av figurene viktig, videre stilte vi også noen oppfølgingsspørsmål til hver av figurene. På denne måten fikk vi svar på om testpersonene hadde forstått dataene figuren representerte eller om visualiseringen bare var «pen å se på». Etter at testpersonen hadde sett på alle figurene og svart på oppfølgingsspørsmåle,t var siste spørsmål hvilke figur de hadde foretrukket å få presentert på sine fakturasider, og svaret vi fikk her var at 44 % ønsket visualisering 4 og resten av svarene var jevnt fordelt mellom de 3 andre visualiseringene (se Figur 33). Page 80 of 139

81 Testdokumentasjon Figur 33: Bilde av visualiseringsteknikkene Ovenfor i figur 33 ser en de fire visualiseringene som ble brukt i spørreundersøkelsen. De viser alle data som representerer forbruket på et abonnement over en måneds tid. Ved de ulike figurene er det ulike deler av abonnementet som har overskredet det inkluderte for den måneden. Med dette menes at ved den første visualiseringen har personen som tilhører dette abonnementet brukt mer ringeminutter enn det som er inkludert i abonnementet. Dette fører til at det blir ekstra påløpte kostnader. Ved visualisering 2 overskrider databruken det totale inkludert. Visualisering 3 overskrider totalforbruket på antall SMS, mens visualisering 4 fremstiller et overskredet forbruk på antall ringeminutter. Hele poenget med å lage det slik at figurene fremstilte ulike data, var for å få testpersonen til å faktisk se på figuren. Ved å vise til ulik data på de forskjellige visualiseringene måtte testpersonen se nøye på hver enkelt figur før personen svarte. Spørsmålet som skulle luke ut dette var følgende «Dersom dette hadde vært ditt abonnement ville du?», under var det flere Page 81 of 139

82 Testdokumentasjon alternativer som foreslo både å øke eller redusere forbruket for ringeminutter, SMS, MMS og dataforbruk. Ettersom hver visualisering hadde ulike svar som var mer riktige enn andre, kunne en se om testpersonene faktisk hadde forstått den reelle dataen som figurene visualiserte eller om informasjonen var misforstått. Alt i alt var det visualisering 4 som kom best ut av spørreundersøkelsen i forhold til hvilke graf forbruker foretrakk. Derfor ble denne visualiseringen benyttet i den ferdige prototypen som skulle fremstille forbruket til hver enkelt person. For å se resultatet av spørreundersøkelsen, se vedlegg Brukertest B i ha d m a d a i b av m m d av i idd vi utfører brukertester er det viktig at en tester produktet, i at en a b i d d a i e scenarioer for brukerne kan utviklere avdekke mangler og begrensninger i produktet. Her er det vi i i d a hva b a ø, m ba b v m ø i av b d v di a b, m d av di vi d E b av d m va id m d va h m d mi m Gruppa har foretatt en kvalitativ brukertest med åtte personer. Her har vi observert hvilke valg brukerne foretar seg i de gitte oppgaven. På denne måten får gruppa testet om den nye løsningen er med å forenkle bruken av nettstedet. Brukeren fikk før testen et dokument som avklarte hvordan gruppen hadde tenkt til å behandle informasjonen innhentet under testen. Dette dokumentet finnes som vedlegg 9, personvernserklæring. Før gruppen gikk i gang med brukertesten, var det viktig å kartlegge hvordan den skulle utføres.vi lagde generelle spørsmål og oppgaver som bruker skulle utføre i sammenheng ned brukertesten. Deretter skulle vi observere hvordan testpersonen klarte å utføre disse oppgaven, vannsklighetsgrad, tastetrykk og eventuelle problemer. Som en avslutning fikk testpersonen komme med eventuelle innvirkninger, fortelle hvordan vedkommende opplevde prototypen og om det eventuelt var noe de mente kunne forbedres. Deretter takket vi for at personen hadde tatt seg tid til å utføre denne brukertesten med oss. Page 82 of 139

83 Testdokumentasjon Vi fikk gode tilbakemeldinger, og førsteinntrykket for siden var at den virket veldig enkel å bruke. De var lett å forstå at de tre ikonene midt på siden var knapper. Det brukerne vektla var at siden virket litt uproff og gammeldags. Videre skulle brukerne navigere seg frem til faktura for Januar 2014 å se om denne var betalt. Dette brukte de fleste testpersonene bare ett klikk på, noe som er veldig bra. Men etter dette var det ikke alle som så at informasjonen lå øverst på siden. Da de ble klar over dette, var de veldig fornøyde, og mente at både eldre og yngre hadde forstått dette etter ett besøk. En ny oppgave var å laste ned faktura for Juli Dette var en enkel oppgave for testpersonene, de trykket rett på fakturakopi ved hjelp av pilen, og lastet ned denne. Vi testet også om bruker kunne finne ut hvordan forbruket var til en gitt person, Beate Johnsen. Her navigerte noen brukere seg tilbake til forsiden og trykket på ikon, mens andre valgte å gå til menyen for å gå direkte til abonnement siden. Etter dette brukte noen søkefeltet, og andre va c d id i av b a B a J h hadd høyt forbruk av data, og burde bytte til et abonnement med mer data inkludert. Noen d i m b vi ha, va ha m i h i m S informasjon om det aktuelle abonnementet. De ville også gjerne ha mulighet til å få mer informasjon om abonnementet her. Vi spurte også testpersonene om hvordan brukerne opplevde den grafiske fremstillingen av abonnementet. Her testet vi en bruker som var fargeblind, i forhold til hvordan han så fargene på grafen. Da fikk vi til svar at han så overforbruk med fargen lyseblå. Grønnfargen viste eplegrønn, og den svarte fargen så vinrød ut. Det vil si at bruker enkelt klarte å se forskjell på de ulike fargen vi hadde valgt. De andre testpersonene likte godt grafen, og syns det var veldig bra at de hadde mulighet til å se bare forbruk hvis de ville det. Noen av testpersonene ville foretrukket andre farger på grafens kategorier. Å opprette et nytt abonnement var enkelt å utføre for bruker. De skulle legge inn informasjon for Per Sivertsen. Noen brukere benyttet her brødstien for å navigere seg tilbake til hovedsiden. Deretter la de inn informasjon under opprette abonnement, og fikk frem ny informasjon i listen over abonnementer. Her ønsket noen brukere at de kunne få en pop-up Page 83 of 139

84 Testdokumentasjon box, for å få tilbakemelding på at det nye abonnementet var opprette. Som en avslutning på brukertesten spurte vi hvordan bruker opplevde siden, helhets inntykket. Brukerne likte godt at siden var enkel å bruke, de fant fort frem til hva de skulle gjøre. En brukervennlig, men litt kjedelig utformet side. 6.3 Brukerveiledning Dette er en beskrivelse av hva systemet gjør og hvordan bruker skal gå frem for å utføre sine oppgaver i prototypen. Poenget med prototypen er arbeidet med de to funksjonalitetene gruppen har utført. Derfor vises bare de tre kategoriene bestille abonnement, faktura og opprette abonnement. For å oppnå ønskede mål må bruker navigere på siden enten ved hjelp av store knapper eller ved hjelp av drop-down menyen i høyre hjørne. Alle prosedyrene som kan utføres er først mulig etter innlogging fra hovedsiden. Videre er implementeringsfasen en viktig del av prosessen med å få systemet til å fungere. Dette gjelder også for Telenor, hvor veiledning kan føre til en god navigering og orientering for brukere av systemet. Ved bra veiledning vil bruker beherske oppgavene en kan utføre og jobbe på en enkel måte med navigeringen rundt på sidene. Dette er derfor også viktig med tanke på videre utvidelser av prototypen, ved å eventuelt tilføre flere kategorier for kunden å velge. Uøvde brukere Meningen med å lage prototypen så enkel, er slik at nye og uøvde brukere skal ha gode muligheter for å meste oppgaver en kan utføre i dette systemet uten forutsetninger. Det vil selvfølgelig være en forskjell mellom brukere som har jobbet litt med systemet og nye brukere, da erfarne brukere vet hvor de skal se. Men utfordringen er at nye brukere også skal klare navigeringen frem til riktig side enkelt. Page 84 of 139

85 Testdokumentasjon Øvede brukere Øvede brukere vil enklere komme seg fra startsiden til ønsket side uten å trykke rundt i systemet. En erfaren bruker vil vite hvor informasjonen ligger ettersom bruker har benyttet systemet før og kan da enkelt lære andre til hvordan de skal finne samme informasjon. Forkunnskaper Prototypen er utvidet slik at det ikke trengs spesielle forkunnskaper innen teknologi og IT for å benytte systemet. Men en må ha grunnleggende kunnskaper om hvordan en benytter pc for å klare navigering og forståelse av siden. Det er benyttet enkel terminologi slik som «faktura» og «abonnement» for navigering på siden, sik at brukeren ikke skal trenge spesielle forkunnskaper. Brukeren av en slik prototype er mennesker som jobber i firmaer med fakturaer og håndtering av bedriftens abonnementer. Avhengig av hva slags arbeidsoppgaver og hvor stort firmaet er, har hver enkel bruker ulike arbeidsoppgaver og preferanser de benytter systemet for. Derfor ble prototypen designet slik at de ulike funksjonene skulle komme like godt frem på siden. Ved videreutvikling ville egendefinert forside vært mulig, slik at bruker kunne valgt snarvei med de knappene som selv er mest aktuelle for bruker. Notasjon og terminologier Her vil det fremkomme en oversikt over de ulike ikonene og tegnene brukt på siden for å symbolisere for bruker hva som er tilgjengelig. Når det kommer til terminologien benyttet til disse ikonene er dette brukervennlige og enkle begreper som en kjenner godt fra dagligdagse sammenhenger. Figur 34: Ikon for abonnement Ikonet viser et nettbrett og en mobiltelefon. Symboliserer abonnementer og muligheten for å se forbruket. Page 85 of 139

86 Testdokumentasjon Ikonet er to ark som er vist med teksten «Faktura» under. Dette er knappen for å komme frem til sidene med fakturaer. Figur 35: Ikon for fakturaer Ikonet viser omrisset av en person og et pluss tegn. Dette viser bruker at en opprettet et nytt abonnement ved å benytte denne knappen. Figur 36: Ikon for oppretting av nytt abonnement Figur 37: Hovedmenyen Ved hovedmenyen er det også fremvist et ikon med en liste for å vise at det finnes mer informasjon tilgjengelig under denne knappen. Figur 38: Knapp med endring etter trykk Alle knappene en kan trykke på for å få utvidet informasjon inneholder en pil som endrer retning (peker nedover) når informasjonsfeltet er åpent og mer informasjon er tilgjengelig for lesing. Page 86 of 139

87 Testdokumentasjon Hvilke problemer tar systemet sikte på å løse? Programmet skal kunne opprette nye abonnementer, vise forbruket til abonnementene som tilhører den bedriften, bestille nytt simkort og se hvilke fakturaer som er betalt/utestående og finne fakturakopier. Ved flere av disse oppgavene som bruker utfører vil det komme tilbakemelding. - Dersom en bestiller nytt simkort vil det komme pop-up boks som spør om du er sikker på at du vil bestille et nytt simkort, her kan du trykke ok eller avbryt. Ved å trykke ok kommer det melding under bestillingsknappen at et nytt simkort er bestilt. - Ved bestilling av nytt abonnement vil bruker få feilmelding om at tilstrekkelig informasjon ikke er utfylt, dersom felter som må fylles ut ikke er utfyllt. - Når et abonnement er bestilt vil bruker få tilbakemelding på at det nye abonnementet er lagret i databasen. - Ved å bevege musen over grafen med informasjon om et forbruk vil en forklarende tekst med informasjon over tallene en ser komme opp. Det vil typisk så følgende; Fri SMS: brukt denne måneden 120, totalt 150. Prosedyre for å hente ut fakturakopi eller se om faktura er betalt/forfallt: Bruker er logget inn på hovedsiden for innlogget bruker. Der finnes tre knapper hvor bruker velger knapp med teksten «Faktura». Deretter vil bruker bli redirigert over til en ny side som viser informasjon over fakturaer som ikke er betalt og nye fakturaer. Under dette feltet finnes tre knapper hvor det ligger fakturakopier i pdf formater med historikk på 2 år tilbake i tid. Prosedyre for å opprette et nytt abonnement: Logger inn på hovedsiden for innlogget bruker. Derfra navigerer bruker seg enten ved hjelp av menyen på høyre side (da ved å trykke på «opprett abonnement») eller ved å trykke på knappen «opprett abonnement». Bruker blir uansett valg sendt videre til ny side det det finnes fire alternativer. Det første alternativet er: Page 87 of 139

88 Testdokumentasjon 1. Egendefinert: Her kan bruker selv definere hva som skal være med i abonnementet eller ikke. Bruker fyller ut aktuelt navn og nummer, og krysser videre av nedover skjemaet på hvilke abonnement og eventuelt tilleggspakker abonnementet skal ha. 2. Lite: Dette valget gir deg mulighet til å bestille et abonnement med lite forbruk der du kun må fylle ut feltene fornavn, etternavn og fødselsdato. 3. Middels: Dette valget gir deg mulighet til å bestille et abonnement med litt mer inkludert forbruk enn «lite». Input feltene som må fylles ut her er fornavn, etternavn og fødselsdato 4. Stort: Dette er et abonnement for kunder som bruker telefonen mye og inkluderer mer i abonnementet enn både «Lite» og «Middels». Input feltene er fortsatt kun fornavn, etternavn og fødselsdato. Prosedyre for å se forbruket til ulike abonnementer: For å utføre denne prosedyren går man inn på kappen «Abonnement» fra hovedsiden som innlogget. Det vil da komme opp en liste med navn og telefonnummer for alle som har abonnement i bedriften. Enten kan man finne aktuell person ved å scrolle ned til riktig navn eller bruker søkefeltet for å skrive inn telefonnummer, fornavn eller etternavn. Klikk deretter inn på aktuell person. Her vises informasjon om hvilket abonnement og hva fastprisen per mnd er. En graf med det mest vanlige forbruket vil komme opp (datatrafikk, ringeminutter, SMS og MMS). En kan velge å se hvor mye som er overskredet, hvor mye som er igjen av inkludert forbruk for den aktuelle måneden og hvor mye som er brukt den måneden eller velge å kun se på ett av elementene ved å klikke bort de to andre. Under kan en trykke frem utvidet informasjon om forbruket. Og på vestre siden kan en bestille nytt simkort for det aktuelle abonnementet. Page 88 of 139

89 Testdokumentasjon Vedlikehold Vedlikehold av et slikt system er viktig for at systemet både skal være sikret mot angrep i form av virus, hacking osv. Men også at de skal kunne få hjelp hvis det er noe de ikke forstår. Det kan hende de har avtalt at leverandør skal levere oppdateringer kontinuerlig, hvor de retter opp feil som ikke er oppdaget i testingen osv. I forhold til Telenor er sikkerheten veldig viktig både for deres kunder og for dem selv. Kunder legger inn sensitiv informasjon som for eksempel personnummer som man ikke vil at allmennheten skal kunne se. Page 89 of 139

90 Konklusjon 7.0 Konklusjon Her vil vår vurdering av eget prosjekt, med tanke på måloppnåelse og problemstilling bli drøftet. Konklusjonen er en beslutning tatt på bakgrunn av våre premisser, undersøkelser, observasjoner og erfaringer under prosjektet. Refleksjon og begrunnelse for hva gruppen har kommet frem til, er viktig for videre læring og mestring av fremtidige prosjekter. loppn else or prosjekt r ppen Etter brukertest og fremføring av oppgaven for Accenture har vi fått tilbakemeldinger som indikerer på at vi har levert en bra løsning, som møter både gruppa og oppdragsgivers krav. Brukertesten resulterte i at nye krav ble satt. Dette var krav fra brukere om hvilken informasjon som skulle vises på siden, se punkt 6.2. Noen av kravene ble endret på, men en ny brukertest var ikke mulig å gjennomføre innenfor prosjektets tidsrom. Oppdragsgiver var likevel tilfreds med løsning av problemstilling, prosjektgruppen og resultatet, se punkt 5.3. Mangel på spesifikke krav til oppgaven fra oppdragsgiver, gjorde at gruppa brukte lang tid på å utforme selve oppgaven. Vi har hatt møte med User Experience teamet, og veileder ved Accenture som har hjulpet oss med videre forskning og til å snevre inn oppgaven. Det har vært utfordrende å finne en problemstilling som ikke ble alt for åpen, i forhold til tiden vi hadde til disposisjon. I begynnelsen ble denne veldig uoversiktlig, og mange elementer skulle være med i utformingen av produktet. Men til slutt, etter x antall problemstillinger mener vi at vi har klart å lage en relevant problemstilling, som viser til det produktet vi har utformet. Gjennom rapporten og utformingen av produktet har vi tilegnet oss nok kunnskap og erfaring underveis til va d Gruppen har fått oppleve hendelser i forhold til prosjektet, da vi har hatt forsinkelser i forhold til utformingen av prototypen. For oss har dette vært en lærerik opplevelse, hvordan vi skulle løse dette, og hvilke andre oppgaver som vi eventuelt måtte utsette. Dette er reelle faktorer som kan skje i jobbsammenheng, noe som er nytt for mange av oss, men som gjør oss styrket Page 90 of 139

91 Konklusjon med tanke på arbeidslivet videre. 7.2 Løsning i henhold til problemstilling For å svare på problemstillingen v da a et moderne web-rammeverk være med på å bedre brukervennligheten, på en gitt web-applikasjon? vurderte gruppen nyere rammeverk for front-end teknologier i en analyse, og testet et av disse rammeverkene i en prototype. Noen av funksjonalitetene ble da produsert med Angular. Dette var rammeverket som fikk best resultater ut i fra gruppens analyse. Derfor er konklusjonen på bakgrunn av vår erfaring med rammeverkene og testing, i samarbeid med design og visualiseringsteknikker, at nye rammeverk kan bidra til å øke brukervennligheten. Nettsidene virker i større grad mer dynamiske og interaktive ovenfor bruker. Dette kan vi for eksempel se på prototypen, der Angular er benyttet i koden for å liste ut alle abonnementene. Listen blir da oppdatert samtidig som bruker skriver inn søkeinformasjon, noe som gir bruker tilbakemelding samtidig som de jobber med systemet. Slik tilbakemelding gir bruker beskjed om at systemet reagerer på input som blir gitt, og bedrer brukervennlighet ved å gi bruker tilbakemelding. Ved at systemet reagerer på en slik måte vil også føre til at bruker av nettsiden får søkeresultatene på samme side som søkefunksjonen, istedenfor å redigere bruker til en ny side med søkeresultater. Dette hindrer flere klikk fra bruker dypere inn i nettsiden. Oppdatering av søk mens bruker skriver informasjonen, vil også føre til færre klikk for bruker for å nå ønsket informasjon. Dette skaper en bedre forståelse av hvor bruker til en hver tid befinner seg. I tillegg gir også kode med nyere rammeverk muligheten til mer animasjon, som selvfølgelig må modereres for å beholde brukervennlighet. Så endelig konklusjon vil for gruppen være at nyere rammeverk kan være en god bidragsyter for å oppnå brukervennlighet på en web-applikasjon, men vil ikke alene føre til dette. Det er sammen med godt design, prinsipper for universell utforming og andre hensyn på webapplikasjonen mulig å oppnå ønsket brukervennlighet. Trendene innen nye rammeverk for front-end løsninger gir oss en større mulighet til å utføre nettsider på en slik god måte. Page 91 of 139

92 Litteraturliste 8.0 Litteraturliste Accenture. (2014). About Accenture Retrieved , from Atlassian. (2013a). Atlassian Community License Request. Retrieved 08. Mai 2014, from https://www.atlassian.com/software/views/community-license-request Atlassian. (2013b). Bitbucket. Retrieved 08 Mai 2014, from https://www.atlassian.com/software/bitbucket/overview Atlassian. (2013c). Company: About us. Retrieved 08. Mai 2014, from https://www.atlassian.com/company Atlassian. (2013d). Company: Customers Retrieved 08. Mai 2014, from https://www.atlassian.com/company/customers Atlassian. (2013e). Jira. Retrieved , from https://www.atlassian.com/software/jira Atlassian. (2013f). JIRA Architectural Overview. Retrieved , from https://developer.atlassian.com/display/jiradev/jira+architectural+overview Bergem, A. L. (2013). 9 tips hvis du skal gjennomføre en spørreundersøkelse. Retrieved from Berjon, R., Faulkner, S., Leithead, T., Navara, E. D., O'Conner, E., Pfeiffer, S., & Hickson, I. (2014). HTML5: A vocabulary and associated APIs for HTML and XHTML. Retrieved 25. Mai 2014, from Billups, T. (2014). Ember.js Testing Retrieved 21. Mai 2014, from Bos, B., Lie, H. W., Lilley, C., & Jacobs, I. (1998). Cascadin Style Sheets, level 2: CSS2 Spesification Retrieved 25. Mai 2014, from Bratvold, E., & Alnæs, S. (2010). Hva er dropbox? Retrieved , from canjs. (2012). Why CanJS?, 3.Mars 2014, from canjs. (udatert). CanJS. 3.Mars 2014, from Chan, K. (2013). Scrum Methodology vs. Agile Methodology. Retrieved 08 Mai 2014, from Chapman, C. (2010). Six Revisions. 18.Mai 2014, from Choudhury, A. (2012). Agile Vs Waterfall. Retrieved 08. Mai 2014, from Cohn, M. (2012). Scrum team. Retrieved 08. Mai 2014, from Colllin. (2014). Meteor Web Apps on Mobile. Retrieved 19. Mai 2014, from https://github.com/awwx/misc/wiki/meteor-web-apps-on-mobile Conklin, W. A., White, G., Williams, D., Davis, R., & Cothren, C. (2012). Principles of Computer Security: CompTIA Security+TM and Beyond (3 ed.). USA: The McGraw-Hill Companies. Contributor, T. (2009). What is Best, Scrum or Kanban? difi. (2013). Universell utforming. 18.Mai 2014, from Dropbox. (2014). About dropbox , from https://www.dropbox.com/about Dropbox. (Udefinert). Dropbox tour. Retrieved 08. Mai 2014, from https://www.dropbox.com/tour Page 92 of 139

93 Litteraturliste Few, S. (2013). Data Visualization for Human Perception Retrieved from Garshol, L. M. (1999). En introduksjon til CSS. Retrieved 25. Mai 2014, from GitHub. (2014a). Data and security Retrieved 19. Mai 2014, from GitHub. (2014b). Meteor. Retrieved 19. Mai 2014, from https://github.com/meteor/meteor GitHub. (2014c). Meteor Retrieved 19. Mai 2014, from Google. ( ). Angularjs. Retrieved 21. Mai 2014, from https://angularjs.org/ Grønning, K. (2008). Klassediagrammer. 25.Mai 2014, from Gundersen, D. (2014). Kanban. Retrieved 08. Mai 2014, from Highcharts. (2013). Highcharts. 25.Mai 2014, from Highcharts. (udefinert). Highchart. 25.Mai 2014, from Highsoft. (2013). Hightsoft. 25.Mai 2014, from Hughes, B., & Cotterell, M. (2009). Software Project Management (5 ed.). Berkshire: McGraw-Hill Education. Inc, T. (2014). A framework for creating ambitious web applications Retrieved 21. Mai 2014, from JMP. (2014). Mosaic Plot. Retrieved 08. mai 2014, from Joyce, D. (2009). Kanban for Software Engineering Retrieved 08. Mai 2014, from 242.pdf Krill, P. (2013). Meteor aims to make JavaScript programming fun again. Retrieved 19. Mai 2014, from Maus, A. (2010). Kravhåndtering. Retrieved 08. Mai 2014, from Forelesning4-Kravh%C3%A5nteringv2010.pdf Memmel, T. (2011). User Interface Prototyping - Low- and High-Fidelity Prototyping Today. 18.Mai 2014, from MongoDB. ( ). The MongoDB 2.6 Manual Retrieved 19. Mai 2014, from NETCOACH. (2011). Hva er en prosess og prosessbasert styringssystem?, 13.Mai 2014, from Oracle. (2014). General information Retrieved 19. Mai 2014, from PHP. (2014). What is PHP?, 25.Mai 2014, from Piotr, & Oskar. (udefinert). Frameworks & Extentions. Retrieved 21. Mai 2014, from Porto, S. (2013). A comparison of Angular, Backbone, CanJS and Ember. 3.Mars 2014, from Public. (2014a). Backbone.js. Retrieved 19. Mai 2014, from Public. (2014b). Backbone.js: Examples Retrieved 19. Mai 2014, from Page 93 of 139

94 Litteraturliste Public. (2014c). Meteor Roadmap Retrieved 19. Mai 2014, from https://trello.com/b/hjbdflxp/meteor-roadmap Public. (2014d). Underscore.js. Retrieved 19. Mai 2014, from Quackit. (Udefinert). Build a Website. Retrieved 25. Mai 2014, from Riel, A. J. (2013). 1.3 The Waterfall model Object-Oriented Design Heuristics. Retrieved from Rouse, M. (2005a). Framework. Retrieved 13.Mai 2014, from Rouse, M. (2005b). front-end. Retrieved 13.Mai 2014, from Rouse, M. (2005c). HTML (Hyper Text Markup Language). Retrieved 25. Mai 2014, from Rouse, M. (2007). Definition Use case. 18.Mai 2014, from Sander, K. (2014). Hva er et produkt?, 13.Mai 2014, from Sandnes, F. E. (2011a). Brukergrensesnitt og universell utforming Universell utforming av IKTsystemer: Brukergrensesnitt for alle (pp. 16). OSLO: Universitetsforlaget. Sandnes, F. E. (2011b). Universell utforming av IKT-systemer: Brukergrensesnitt for alle. OSLO: Universitetsforlaget. Spence, R. (2013). Information visualization: design for interaction (2 ed.). New Jersey: Prentice Hall Stackoverflow. (2014a). Stackoverflow; Angular. Retrieved 21. Mai 2014, from Stackoverflow. (2014b). Stackoverflow: Ember. Retrieved 21. Mai 2014, from Tijms, A. (2013). What is JSON REST interface Retrieved 19. Mai 2014, from W3C. (2008). Web Content Accessibility Guidelines (WCAG) Mai 2014, from W3Schools. (Udefinert-a). CSS3 Introduction Retrieved 25. Mai 2014, from W3Schools. (Udefinert-b). HTML5 Introduction Retrieved 25. Mai 2014, from Wesley, F., & Umstot, M. (2012). Introduction to Adobe Photoshop. Retrieved 07. Mai 2014, from Page 94 of 139

95 Litteraturliste Page 95 of 139

96 Figurliste 9.0 Figurliste Figur 1: Illustrasjon av vår Jira under sprint Figur 2: Burndownchart av sprinter i Jira Figur 3: Forslag til prototypens oppsett under brainstorming prosessen Figur 4: Visualiseringsteknikk 2 (sirkeldiagram)... Error! Bookmark not defined. Figur 5: Visualiseringsforslag1 (Stjerneplott) Figur 6: Visualiseringsteknikk 3 (Barchart) Figur 7: Visualiseringsteknikk 4 (søylediagram) Figur 8: Produkt kategorier Figur 9: Analyseskjema Figur 10: Analyseskjema Figur 11: Analyseskjema Figur 12: Klassediagram Figur 13: Aktivitetsdiagram forklarer fremgang for opprettelse av abonnement Figur 14: Figur av opprett abonnement Figur 15: Visning av alt tekst tagger på prototypen Figur 16: Eksempel på fremstilling av et forbruk i prototypen Figur 17: Dropdown meny fra prototypen Figur 18: HTML kode fra prototypen Figur 19: Kodesnutt av Angular scriptet for dropdown menyen Figur 20: PHP kodesnutt demonstrerer tilkobling til databasen Figur 21: Kodesnutt av highchartet for stolpediagrammet Figur 22: Dr. J. Nielsens illustrasjon av lesemøster på web Figur 23: Fargeskalaer Figur 24: Utforming av knapper Figur 25: Databasen for prototypen Figur 26: Førsteside før innlogging Førsteside etter innlogging Figur 27: Fremstilling av abonnementer Figur 28: Fremstilling av forbruket til en kunde Figur 29: Fakturalister Figur 30: Knapper for malene på opprett nytt abonnement Figur 31: Egendefinert mal for oppretting av nytt abonnement Figur 32: Mal for opprettelse av abonnementet "Lite" Figur 33: Bilde av visualiseringsteknikkene Figur 34: Ikon for abonnement Figur 35: Ikon for fakturaer Figur 36: Ikon for oppretting av nytt abonnement Figur 37: Hovedmenyen Figur 38: Knapp med endring etter trykk Figur 39: SCRUMs prosess (hentet fra Mountain Goat Software)... Error! Bookmark not defined. Figur 40: Arbeidsflyt ved Kanban Figur 41: Modell av vannfallmetoden og Agil metode Page 96 of 139

97 Vedlegg 10.0 Vedlegg 10.1 Vedlegg 1: Visualiseringer Page 97 of 139

98 Vedlegg Page 98 of 139

99 Vedlegg Page 99 of 139

100 Vedlegg Page 100 of 139

101 Vedlegg 10.2 Vedlegg 2: Teknikker Page 101 of 139

102 Vedlegg Page 102 of 139

103 Vedlegg Page 103 of 139

104 Vedlegg 10.3 Vedlegg 3: Scrum Scrum metodikken er en arbeidsmetode som blir brukt i ulike prosjekter. Her jobber teamet m d a b id m d i, m i m a av i ø v problemer som kan oppstå. Sprinter er en produksjonsperiode som kan vare fra 1-4 uker der hver sprint avsluttes med en presentasjon av det som har blitt utført til produkteier (Chan, 2013). Produkteieren er kundens representant og bestemmer hva det ferdige produktet skal inneholde. Videre forklarer Chan (2013) at hver sprint inneholder oppgaver fra produkt backlogen som skal utføres i den aktuelle sprinten. Produkt backlogen er en prioritert liste med oppgaver som skal utføres før det endelige resultatet er ferdig. Produkt backlogen kan endres med tiden når vi jobber videre i prosjektet, mens en sprint backlog ikke kan endres når sprinten er i gang (Chan, 2013). Som figur 1 viser, så starter Scrum-metodikken med produkt backlogen. Så sendes de valgte oppgavene videre til sprint backlog for å utføres den sprinten. Deretter gjennomføres disse oppgavene i sprinten, før vi går tilbake til produkt backlogen å henter nye oppgaver til neste sprint backlog. Scrum bruker også en brundowngraf for en grafisk fremstilling av hvor mange timer som er blitt brukt på prosjektet. Program som kan brukes til dette er eventuelt JIRA(Atlassian, 2013e). Et viktig arbeidsverktøy i bruken av Scrum er daily standup Scrum møter(chan, 2013). Dette er daglige møter som varer fra minutter der teammedlemmene svarer på tre spørsmål hver. Hva har du gjort siden forrige møte? Hva skal du gjøre før neste møte? Er det noe som hindrer deg i å få utført arbeidet? Dett e vil være med på å sikre frem drift en av prosjektet, og se om det er noen omprioriteringer av ressurser som behøves. Figur 39: SCRUMs prosess (hentet fra Mountain Goat Software) Page 104 of 139

105 Vedlegg 10.4 Vedlegg 4: Alternative metodikker Kanban Kanban er en metodikk som benyttes for å se helheten i en prosess. Poenget er da å se prosjektet i starten, og ikke påbegynne for mange oppgaver samtidig, men heller jobbe seg systematisk fremover. Det ligger en kø-teori bak denne metodikken, noe som innebærer at de ulike teamene har en maks på antall arbeidsoppgaver som kan utføres samtidig (Contributor, 2009). Dersom en oppgave er ferdig utført, vil den gå videre til neste team dersom teamet har ledig plass på sin del av tavlen. Dersom neste team ikke har ledig plass, blir oppgaven værende på sin nåværende plass, frem til det oppstår ledig kapasitet ved det nye teamet. Ved denne måten å arbeide på vil man oppdage om arbeidsflyten fungerer som den skal, dersom flere oppgaver blir stående for lenge på vent (Contributor, 2009). Noen av de viktigste prinsippene i Kanban er å begrense arbeidet, få resultatene gjennom hele prosessen og øke gjennomstrømningen. Kvalitet skal være i arbeid fra start, og ikke legges inn underveis. Med Kanban som metodikk, er hovedfokus å jobbe med mindre oppgaver innenfor en prosess. Uttrykket just-in-time er mye brukt innenfor denne metodikken, og kommer av prinsippet ved å ikke kjøpe inn mer enn du trenger, ikke utføre oppgaver som ikke er nødvendig akkurat nå, og ikke skrive kode som ikke kan testes på det stadiet i prosjektet (Gundersen, 2014). På denne måten utfører man kun de nødvendige oppgavene for å fortsette en jevn arbeidsflyt. Figuren nedenfor viser verdien av en god flyt i et kanban prosjekt. De grønne tekstfeltene representerer blokker der arbeidet tilføyer verdi og blokker ved den røde teksten viser områder der arbeidsoppgaver ikke gir verdi under prosessen (Joyce, 2009). Figur 40: Arbeidsflyt ved Kanban Page 105 of 139

106 Vedlegg Vannfall Vannfallmetodikken er en tradisjonell utviklingsmetodikk som blir flittig brukt i programvareutvikling. Riel (2013) beskriver i sin bok «The Waterfall model Object-Oriented Design Heuristics» hvordan teamet jobber steg for steg, og modellen starter ofte med å analysere selve oppgaven, deretter å utforme resultatet av analysen. Videre starter teamet med koding, og så testes denne koden. I siste steg skal programvaren vedlikeholdes, og personer må læres opp i hvordan dette fungerer (Riel, 2013). Problemet med vannfallmetodikken er at det er vanskelig å gå tilbake til forrige steg for å rette på eventuelle feil som kunden påpeker (Choudhury, 2012). Derfor er det viktig i vannfallmetodikken å jobbe systematisk for å da v b id i i vi i a K ad a b i hvi systemutviklerne må tilbake og rette på koder. Her er det også viktig at alle teammedlemmene jobber i likt tempo, så det ikke danner seg en flaskehals. Den Agile metodikken som Scrum gjør programvareutviklingen mer feilfri og mindre feilaktige i forhold til vannfallmetodikken, som bare har mulighet til å teste b av vi i gsmodulen (Choudhury, 2012). Med den Agile metodikken er det lettere å forutse hvilke utfordringer man kan støte på underveis i systemutviklingen. Fleksibiliteten til den Agile metodikken gjør det også mulig å gå tilbake og rette på eventuelle feil eller mangler som kunden påpeker. Dette gjør at den Agile metodikken er mer tilbøyelig i forhold til kundens krav, og gir derfor bedre kundetilfredshet. Figur 3 viser vannfallmetodikken til venstre, og den Agile måten å jobbe på til høyre. Page 106 of 139

107 Vedlegg Figur 41: Modell av vannfallmetoden og Agil metode Page 107 of 139

108 Vedlegg 10.5 Vedlegg 5: Aktivitetsdiagram Page 108 of 139

109 Vedlegg Page 109 of 139

110 Vedlegg 10.6 Vedlegg 6: Use Case beskrivelser Use Case Navn MinBedrift 2.0 prototype Laste ned faktura Aktører Trigger Bruker av nettsiden, systemet (database) Bruker logger inn i systemet Prebetingelser 1. Brukeren har tilgang til en firmakonto i MinBedrift 2. Brukeren har en eller flere fakturaer i systmet Postbetingelser Bruker har lastet ned kopi av PDF Normalflyt (Hovedflyt) 1. Bruker trykker på «Faktura» knappen 2. Feltet med «siste fakturaer» vises, samt dropdown meny for fakturaer 2012, 2013 og Bruker åpner dropdown liste for ønsket år 4. Bruker trykker på link til ønsket faktura 5. Faktura lastes ned i PDF format Page 110 of 139

111 Vedlegg Variasjoner (Alternativer og feil) 1. a) Bruker trykker ikke på «Faktura» knappen - Bruker navigerer gjennom hovedmeny 2. a)feltet med siste fakturaer og/eller dropdown vises ikke - Bruker må oppdatere siden - Ingen fakturaer vises, systemansvarlig varsles 4. a) Fakturaer vises ikke i dropdown listen - Bruker må oppdatere siden - System ansvarlig må varsles 5. a) Faktura blir ikke vist hos bruker - Bruker må endre instillinger for adobe tillegg til nettleser. b) Feil i link til PDF, finner ikke PDF - Bruker må oppdatere siden - Ingen fakturaer vises, systemansvarlig varsles Page 111 of 139

112 Vedlegg Use Case Navn MinBedrift 2.0 prototype Opprette nytt abonnement Aktører Trigger Bruker av nettsiden, systemet (database) Bruker logger inn i systemet Prebetingelser 1. Brukeren har tilgang til en firmakonto i MinBedrift Postbetingelser Bruker har opprettet nytt abonnement, og dette er lagret i databasen Normalflyt (Hovedflyt) 1. Bruker trykker på «Opprett Abonnement» knappen 2. Velger egendefinert abonnement 3. Systemet henter skjema for utfylling 4. Bruker fyller inn nødvendig og ønsket informasjon 5. Bruker trykker send 6.Systemet lagrer informasjonen i databasen Page 112 of 139

113 Vedlegg Variasjoner (Alternativer og feil) 1. a) Bruker trykker ikke på «Opprett Abonnement» knappen - Bruker navigerer gjennom hovedmeny 2. a)bruker velger ikke egendefinert - Bruker velger liten, middels eller stor forhåndsdefinert mal. Flyten fortsetter med punkt a) Systemet finne ikke skjema - Bruker må oppdatere siden - System ansvarlig må varsles 5. a) Skjema ikke fylt ut riktig - Systemet gir feilmelding og bruker må fylle ut på nytt b) Systemet får ikke kontakt med databasen - Bruker må oppdatere siden - Systemansvarlig varsles Page 113 of 139

114 Vedlegg 10.7 Vedlegg 7: Resultater spørreundersøkelse Mobil abonnement Dette er en brukerundersøkelse som omhandler visualiseringer om ditt forbruk for mobil abonnement. Undersøkelsen tar omtrent 2-3 minutter, takker for svar. Page 114 of 139

115 Vedlegg Page 115 of 139

116 Vedlegg Page 116 of 139

117 Vedlegg Figur 1: Page 117 of 139

118 Vedlegg Page 118 of 139

119 Vedlegg Figur 2: Første sirkel er hva som er inkludert i abonnementet ditt, den andre er påløpte kostnader. Page 119 of 139

120 Vedlegg Page 120 of 139

121 Vedlegg Page 121 of 139

122 Vedlegg Page 122 of 139

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

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

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

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

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

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

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. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

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

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

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

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

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

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

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

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

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

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

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

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

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

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

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

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

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

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

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm Hovedprosjekt i informasjonsteknologi 2016 Høyskolen i Oslo og Akershus Forprosjektrapport Digitalt læreverktøy for Cappelen Damm Gruppe 26 Sofia Aittamaa - s198580@stud.hioa.no Petter Lysne - s198579@stud.hioa.no

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

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

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

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON 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

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

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

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

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

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

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

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

Forprosjekt - Gruppe 12. Hovedprosjekt av

Forprosjekt - Gruppe 12. Hovedprosjekt av FORSIDE A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S Forprosjekt - Gruppe 12 Hovedprosjekt av S AJ ID, OZAI RE (S 1711 9 7), S VEEN, S IMEN (S171208),

Detaljer

Prosjektplan. Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013

Prosjektplan. Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013 Prosjektplan Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013 0. Innholdsfortegnelse 0. INNHOLDSFORTEGNELSE... 2 1. MÅL OG RAMMER... 3 1.0. BAKGRUNN...

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. DAGBOK Uke 43: Torsdag 28/10 Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. Uke 44: Mandag 1/11 Gruppen utformet den første statusrapporten til prosjektet.

Detaljer

Forprosjektsrapport. Bachelor 08HBMEMA. Daniel Hakkebo, Mia Orderløkken og Kaja Premer 1/2/2011

Forprosjektsrapport. Bachelor 08HBMEMA. Daniel Hakkebo, Mia Orderløkken og Kaja Premer 1/2/2011 Forprosjektsrapport Bachelor 08HBMEMA Daniel Hakkebo, Mia Orderløkken og Kaja Premer 1/2/2011 Innholdsfortegnelse 1 Prosjektbeskrivelse... 2 1.1 Problemstilling:... 2 1.2 Oppgavebeskrivelse... 2 1.3 Bakgrunn...

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

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300

PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300 Mal for prosjektbeskrivelse PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300 Evt. detaljer i vedlegg med referanse frå de ulike delene Prosjekt (tittel): Sol energi. Dato, signatur:.. Lasse Moen Ola Sundt Melheim....

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

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

2 Innholdsfortegnelse

2 Innholdsfortegnelse Kravspesifikasjon 1 Forord Kravspesifikasjonen er ment å sees i sammenheng med gruppas forventninger til sitt eget sluttprodukt. Den er altså like mye våre egne krav som krav stilt av arbeidsgiver. Vi

Detaljer

Ny designmanual og ny StudentWeb. Brukerforum 2012 Kathy Foss Haugen

Ny designmanual og ny StudentWeb. Brukerforum 2012 Kathy Foss Haugen Ny designmanual og ny StudentWeb Brukerforum 2012 Kathy Foss Haugen Felles uttrykk på nett FUN-prosjekt i Seksjon for utvikling av nasjonale informasjonssystemer (SUN) NetLife Research AS Prosjekt Designmanual

Detaljer

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjon Innholdsfortegnelse Kravspesifikasjon Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:... 2 1.3 Kontaktsperson hos Retriever:... 2 1.4 Veileder:... 2 1.5 Bakgrunn... 3 2. Om Kravspesifikasjonen...

Detaljer

Uansett hvilken håndbok du benytter vil fremgangsmåten være den samme. I denne veiledningen benytter vi personalhåndboken som eksempel.

Uansett hvilken håndbok du benytter vil fremgangsmåten være den samme. I denne veiledningen benytter vi personalhåndboken som eksempel. Velkommen som bruker av nettbaserte håndbøker fra Hovedorganisasjonen Virke. Våre nettbaserte håndbøker kan tilpasses din virksomhet. De er redigerbare, samtidig blir de automatisk oppdatert med nye lover

Detaljer

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Supplerende Kommunikasjon Assistent (SKA) Bachelorprosjektet går

Detaljer

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG SCRUM Smidig prosjektledelse og utvikling 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG HVORDAN SPISER DU EN ELEFANT? EN BIT AV GANGEN 'HOW WILL YOU LIVE, RAMBO?'

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 28.03.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Fremdriftsplan Generelt om tidsberegning Som grunnlag for vår tidsberegninger

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

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling Obligatorisk oppgave 1: Foranalyse og Kravhåndtering LarsMartin Hejll 5611 Systemutvikling Høgskolen i Telemark Oppgave 1: Bakgrunn for systemet LarsMartin Hejll A) Ved å sentralisere bookingsystemet til

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

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

Forprosjekt. Profilhåndbok for Kommunikasjon 1. Hovedprosjekt ved Høgskolen i Gjøvik. Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne

Forprosjekt. Profilhåndbok for Kommunikasjon 1. Hovedprosjekt ved Høgskolen i Gjøvik. Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne Forprosjekt Profilhåndbok for Kommunikasjon 1 Hovedprosjekt ved Høgskolen i Gjøvik Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne Innhold Forprosjektrapport 5 Bakgrunn 5 Mål 5 Omfang 6 Avgrensninger

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

Kvalitetskrav til løsninger

Kvalitetskrav til løsninger Prosjektoppgaven Kvalitetskrav til løsninger Noen retningslinjer for å styre beslutningene deres finnes i form av hva brukere forlanger av software (og hardware): Brukbarhet. - Produktet skal være selvforklarende

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

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

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015

Forprosjektrapport. Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015 Forprosjektrapport Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse av

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

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

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

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

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

Vedlegg LMC intranett

Vedlegg LMC intranett Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:

Detaljer

µθωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ρτψυιοπασδφγηϕκλζξχϖβνµθωερτψυιο πασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγ ξχϖβνµθωερτψυιοπασδφγηϕκλζξχϖβν

µθωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ρτψυιοπασδφγηϕκλζξχϖβνµθωερτψυιο πασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγ ξχϖβνµθωερτψυιοπασδφγηϕκλζξχϖβν θωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ψυιοπασδφγηϕκλζξχϖβνµθωερτψυιοπ ασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγη ϕκλζξχϖβνµθωερτψυιοπασδφγηϕκλζξχ Prosjektplan / Arbeidsplan ϖβνµθωερτψυιοπασδφγηϕκλζξχϖβνµθ Bacheloroppgave

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

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

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

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

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Testdokumentasjon. Gruppe 9

Testdokumentasjon. Gruppe 9 Innholdsfortegnelse 1.Innledning... 3 2.Test av systemet... 3 3.Test med brukermanual av utenforstående... 7 4.Konklusjon... 8 2 1.Innledning Testdokumentasjonen er et dokument som beskriver vår endelige

Detaljer

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport. Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

Forprosjekt bachelor-oppgave 2012

Forprosjekt bachelor-oppgave 2012 Forprosjekt bachelor-oppgave 2012 Oppgave nr. 4.- Styring av instrumenter. Skrevet av Jan Ingar Sethre. 1 Innhold 1. Mål og rammer... 3 1.1 Bakgrunn... 3 1.2 Mål for prosjektet... 3 1.3 Rammer og forutsetninger...

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

Administrasjon av saker. - Redigere saker med standard mal

Administrasjon av saker. - Redigere saker med standard mal Administrasjon av saker - Redigere saker med standard mal Admin V3 September 2015 INNLEDNING... 3 HVA ER EN ARTIKKEL?... 4 FANE: INNHOLD... 4 Felter i en standard artikkel... 5 LAGE EN NY ARTIKKEL... 6

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

Detaljer

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549 Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer