Prosessrapport. Studass. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Transkript

1 Prosessrapport Studass Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo,

2 1 Forord Dette er prosessrapporten utarbeidet i forbindelse med hovedprosjekt våren 2014 ved Høgskolen i Oslo og Akershus. Rapporten beskriver utviklingen av en webapplikasjon som gir studenter ved høyere utdanning i Norge mulighet til å stille hverandre spørsmål og svare på disse. Applikasjonen er utviklet for konsulentfirmaet Accenture. Vi fikk tildelt to veiledere derifra ved prosjektstart som også fungerte som produkteiere. Prosessrapporten er ment for å gi bakgrunnen for utviklingen av oppgaven, hvordan applikasjonen ble utviklet, og de valgene som ble tatt i forkant og underveis som førte til det endelige produktet. Ordbruken i rapporten forutsetter at leseren er kjent med utviklingsmetodikker og teknologi som ikke er nærmere beskrevet i dette dokumentet. Ved behov kan ordlisten i vedlegg brukes som referanse. I denne ordlisten finnes forklaring på datatekniske begreper, og oversikt over hva vi legger i ord og uttrykk som brukes gjentatte ganger for å forklare utviklingsprosessen. Rapporten kan leses som et selvstendig dokument, men innledningen til sluttrapporten og produktrapporten er anbefalt som støttelitteratur, da applikasjonens funksjonalitet og formål er omtalt i meget korte trekk i dette dokumentet, men i større detalj der. 1.1 Rapportens inndeling Rapporten er strukturert i fire hoveddeler. Bakgrunn: Kort introduksjon om hvem vi i gruppen er, hvem vi har laget oppgaven for og hvordan oppgaven ble til. Planlegging: Beskriver hva som ble gjort i planleggingsfasen av prosjektet. Her kan man lese om hvordan kravspesifikasjonen ble utarbeidet, hvilke avveininger som ble tatt angående valg av teknologi og arkitektur til å utvikle produktet, valg av utviklingsmetodikk og hvordan vi planla å gjennomføre dette, prosessen vi hadde når designet ble utarbeidet og hvordan vi prioriterte når vi satte opp en fremdriftsplan. Disse kapitlene presenterer vurderinger vi gjorde før utviklingen begynte. Utviklingsprosessen: Her diskuterer vi hvordan prosjektet ble gjennomført i forhold til slik vi planla og hvordan fremdriftsplanen ble fulgt. Her er det spesielt lagt fokus på utfordringer vi møtte underveis i utviklingen og valg vi var nødt til å ta. Avsluttende del: Inneholder en oppsummering av prosjektet og trekker frem ting som vi mener har fungert spesielt godt, og ting som har fungert mindre godt.

3 Innhold 1 Forord Rapportens inndeling Bakgrunn Gruppen Oppdragsgiver Oppgaven Planlegging Utarbeidelse av kravspesifikasjon Design Valg av metodikk Smidig metodikk og Scrum TDD (Test Driven Development) Prosjektstyringsverktøy Valg av teknologi Java AngularJS og Bootstrap Arkitektur Valg av verktøy Fremdriftsplan Utviklingsprosessen Dokumentasjon Prosjektdagbok Møtereferater Benyttet metodikk Arbeidsfordeling Scrum Testdrevet utvikling Akseptansetesting Fremdrift Samarbeid Sluttproduktet Nettsiden Design API-et Videreutvikling... 29

4 6 Konklusjon Bruken av Scrum Samarbeid i gruppen Bruken av TDD Referanseliste... 31

5 2 Bakgrunn Dette kapitlet gir en kort oversikt over oppgaven som har blitt arbeidet med, hvem oppgaven har blitt utviklet for og hvem som har utviklet den. 2.1 Gruppen Gruppen som utviklet oppgaven besto av fire studenter fra studiet «Ingeniørfag Data». Vi ble kjent i begynnelsen av første året på studiet og har jobbet sammen på flere prosjekter gjennom hele studietiden. Vi bestemte oss tidlig høsten 2013 for at vi skulle skrive hovedprosjektoppgave sammen. Vi hadde tidligere blant annet utviklet webapplikasjoner basert på.net-plattformen i gruppe. Vi hadde erfart tidligere at kommunikasjon og samarbeid oss imellom fungerte bra. Vi hadde tidligere klart å gi hverandre gode og konstruktive tilbakemeldinger, og erfart at det var mulig å være ærlig mot hverandre uten at noen tok seg nær. Dette mente vi la et godt grunnlag for et omfattende samarbeid. Vi var enige om at vi ønsket å utvikle et produkt i vårt hovedprosjekt 2.2 Oppdragsgiver Oppgaven er utviklet for det internasjonale konsulentfirmaet Accenture. De tilbyr konsulenttjenester i store deler av verden, blant annet innenfor drift, utvikling og rådgivning. Vi kom i kontakt med Accenture høsten 2013, ble invitert på intervju og fikk kort tid etter tilbud om å skrive bachelor-oppgave for dem. Vi fikk tildelt to veiledere fra de som skulle veilede oss og fungere som produkteiere gjennom prosjektperioden. Når det refereres til «Accenture» senere i rapporten er det disse to vi sikter til med mindre noe annet kommer klart frem. 2.3 Oppgaven På intervjuet hos Accenture fikk vi presentert flere potensielle oppgaver. Vi ble spesielt interessert i et par av disse, og fikk betenkningstid til å bestemme hvilken oppgave vi ønsket å jobbe med i tillegg til å komme med forslag til potensielle oppgaver selv. I desember ytret vi ønske om å jobbe med en av oppgavene vi hadde fått foreslått på intervjuet. En kort tid før oppstartsmøte hos Accenture januar 2014 fikk vi beskjed om at oppgaven vi hadde ønsket å jobbe med dessverre ikke var tilgjengelig lenger. Vi arbeidet derfor med noen av idéene vi hadde hatt før jul og kom frem til et par alternative oppgavebeskrivelser som ble oversendt Accenture. To konsulenter hos Accenture så behovet vi beskrev i oppgavebeskrivelsen. Arbeidet kunne dermed begynne med å definere en kravspesifikasjon til vår prosjektoppgave, en spørsmålstjeneste for studenter ved høyere utdanning i Norge.

6 3 Planlegging Etter møtet hos Accenture i januar hvor vi fikk tildelt veiledere begynte arbeidet med å planlegge prosjektperioden. Vi utarbeidet en kravspesifikasjon, bestemte oss for teknologier vi skulle benytte og hvordan fremdriftsplanen skulle se ut. 3.1 Utarbeidelse av kravspesifikasjon Det første vi gjorde ved prosjektstart var å utarbeide et utkast til kravspesifikasjon. Vi definerte oppgaveteksten, funksjonelle krav, og ikke-funksjonelle krav til applikasjonen. Dette førsteutkastet presenterte vi for Accenture og kom frem til en endelig kravspesifikasjon vi skulle basere oss på i prosjektet. Denne kravspesifikasjonen sto sentralt i hele resten av prosjektet, da mesteparten av all utvikling baserte seg på funksjonalitet beskrevet i denne. Sentrale punkter i kravspesifikasjonen: Brukere skal stille spørsmål og få disse besvart av andre brukere Brukere skal gi feedback på stilte spørsmål ved å gi disse enten pluss- eller minus-poeng. Spørsmål skal kunne «tagges» med tags som beskriver innholdet Applikasjonen skal kunne benyttes både på PC og mobil, ha et design som fungerer godt på forskjellige skjermstørrelser. 3.2 Design Webapplikasjonen skulle ha lignende funksjonalitet som eksisterende spørsmålssider, ikke ulikt StackOverflow 1 og Yahoo Answers 2. Vi lot oss inspirere av elementer i deres design som vi mente fungerer godt. Vi hadde allikevel fokus på å gjøre vår applikasjon unik og lettgjenkjennelig for brukere. En av måtene vi ville gjøre dette på var ved bruk av en unik fargepalett som ga god kontrast mellom de forskjellige elementene slik at innhold skulle være lettlest. Vi ønsket å basere vårt design på forskjellige bokser, og bruke dette til å skille de forskjellige komponentene fra hverandre. Vi utarbeidet skisser for hvordan nettsiden skulle se ut i en tidlig fase av planleggingen. Det ble bestemt at «nylig stilte spørsmål» skulle være en sentral del av nettsiden for å gjøre det enkelt for en bruker å se alle spørsmål som blir stilt, selv om ikke alle spørsmål er like relevante for enhver. Vi så for oss et scenario hvor en bruker besøkte nettsiden med intensjonen om å opprette et spørsmål. Ettersom nylige stilte spørsmål ville være det første brukeren fikk øye på, kunne det hende at det stod noen spørsmål der som brukeren kunne svare på, selv om det ikke var innenfor et fagfelt han eller hun normalt ville søkt seg frem til. Tanken bak dette var at dette ville bidra til at flere spørsmål blir besvart. Ettersom mye av kjernefunksjonaliteten dreier seg om at brukere skal kunne finne frem til det han eller hun lurer på ville vi at søkefeltet skulle være godt synlig, prege mye av nettsiden og være tilgjengelig hele tiden. Figuren under viser skissen av forsiden

7 Figur[3.1] Skisse 1 Forside Vi bestemte at en «kom i gang» sjekkliste skulle være på forsiden. Denne skulle vise brukere funksjonalitet tilgjengelig på siden og gi de en enkel innføring i hvordan de kunne bruke den. Vi diskuterte også litt videre hva mer vi kunne fylle ut forsiden med og kom frem til at populære tags kunne være relevant. Tanken her var å liste ut de taggene som ble tagget i flest spørsmål for å gjøre det enklere for brukere å finne frem til emner som det var stor interesse for. Figuren under er en skisse som viser hvordan vi bestemte oss for at et spørsmål skulle se ut. Figur[3.2] Skisse 2 Tråd

8 Den øverste boksen er selve spørsmålet med tittel i overskriften, i tillegg til taggene spørsmålet har fått. Boksen under er et svar på spørsmålet. Vi bestemte oss for å gå for pluss- og minus-knapper for poengsystemet vårt. «Piler» eller «tomler» er mye brukt på andre sider som benytter seg av et poenggivningssystem med to mulige måter å dømme innhold på, men vi mener at bruk av pluss og minus-tegn er det mest intuitive. Et tidlig krav til produktet var at det skulle utvikles én applikasjon som skulle fungere like godt på alle plattformer. Applikasjonen skulle oppleves som om det var en applikasjon tilpasset mobil for en bruker med lavoppløst skjerm. Vi så for oss her at den samme visuelle stilen skulle bevares, men at alle elementer skulle fylle ut hele bredden av skjermen på de mindre enhetene. Figur [x.x] er en skisse som viser hvordan vi så for oss at det skulle se ut for brukeren når han eller hun har søkt etter taggen «HiOA». Figur [x.x] er en skisse som viser det samme, men på mobil. Den samme visuelle stilen er iveretatt, men elementene er strukket ut til full bredde på mobil visning. Figur[3.3] Skisse 3 Tråder tagget med tråden «HiOA» blir listet ut

9 Figur[3.4] Skisse 4 Mobilvisning av tråder tagget med «HiOA» listet ut

10 3.3 Valg av metodikk Allerede før oppgaven var bestemt bestemte vi oss for at vi skulle benytte oss av Scrum som arbeidsmetode. Vi hadde et inntrykk av at dette var ett av de mest brukte metodikkene i arbeidslivet, så vi mente at det var et godt valg. I samråd med Accenture og veileder på HiOA bestemte vi oss også for å jobbe med test-drevet utvikling Smidig metodikk og Scrum Ett av gruppemedlemmene hadde tidligere erfaring med Scrum etter å ha jobbet med et utviklingsprosjekt sammen med fire andre utviklere og hadde positive erfaringer med denne arbeidsmetoden. Det viktigste for oss da vi bestemte oss for metodikk var at det skulle øke sannsynligheten for å komme i mål med et godt produkt som levde opp til forventningene til oppdragsgiver. Med Scrum arbeider man i «sprinter» (korte perioder) der man ved slutten av hver sprint ønsker å ha et fullstendig produkt å vise frem til oppdragsgiver for å avdekke eventuelle misforståelser når kravspesifikasjonen ble utarbeidet. De arbeidsoppgavene som blir satt opp i en sprint skal være ferdig når sprinten er ferdig. Vi planla en sprintlengde på to uker, med totalt seks sprinter gjennom hele prosjektperioden. Etter at kravspesifikasjonen hadde blitt ferdigstilt og godkjent av oppdragsgiver utledet vi brukerhistorier fra denne. Disse brukerhistoriene ble lagt i en liste kalt «backlog». En backlog er en liste over alle brukerhistorier og funksjonalitet som skal implementeres og brukes ved arbeid med Scrum. Før hver påbegynte sprint flyttes de viktigste brukerhistoriene fra backlog en over til sprinten og det er utelukkende disse som skal arbeides med i den perioden en sprint går over TDD (Test Driven Development) Testdrevet utvikling går ut på at man følger et mønster når man utvikler, der man skriver en test som beskriver ønsket resultat av en metode før metoden implementeres. Stegene man følger er: 1. Skriv en test. 2. Kjør alle testene Se at test skrevet i punkt 1 feiler. 3. Skriv minst mulig kode for å få testen til å passere. 4. Kjør alle testene Se at test skrevet i punkt 1 ikke feiler. 5. Skriv om koden skrevet i punkt 3. Denne måten å utvikle på krever at utvikleren må tenke nøye gjennom hva koden skal gjøre før den skrives, for å kunne skrive en god test. I tillegg hjelper en slik metodikk til med å skape en godt testet kodebase, slik at man kan legge til ny funksjonalitet til systemet i etterkant med mindre hodebry. Ved implementasjon av ny funksjonalitet kan man kjøre alle testene på nytt og verifisere at den nye funksjonaliteten ikke har ødelagt noe av den gamle. Det var Accenture som foreslo at vi skulle drive testdrevet utvikling. Vi diskuterte dette og leste om andres erfaringer med samme metodikk før vi bestemte at dette var et godt valg for oss. Utbredelsen i arbeidslivet og merverdien som en slik metodikk bringer, gjorde beslutningen enkel. Valget av å benytte TDD spilte en stor rolle i vårt valg av rammeverk da applikasjonens skulle utvikles. I løpet av planleggingsfasen fant vi oss selv i en situasjon der vi skulle utvikle et produkt ved hjelp av delvis ukjente metodikker og delvis ukjente rammeverk. Vi diskuterte derfor muligheten for å legge TDD på vent inntil vi hadde en litt mer grunnleggende forståelse for teknologien som skulle benyttes og kom frem til at vi skulle gjøre dette hvis TDD så ut til å påvirke vår fremgang.

11 3.3.3 Prosjektstyringsverktøy Etter å ha bestemt oss for å utvikle i Scrum fikk vi råd om å benytte oss av «Atlassian» 3 sine løsninger, Jira 4 og Confluence 5 som prosjektstyringsverktøy. Vi bestemte oss for å benytte en plugin til Jira kalt «Agile» 6. Agile gir tilgang til en online backlog, mulighet for planlegging av sprinter, tidsestimering av brukerhistorier, samt et online «storyboard». På dette storyboardet kan man flytte på brukerhistorier mellom kolonner som indikerer om de jobbes med, er ferdige eller enda ikke påbegynt. I tillegg til å tilby disse verktøyene kan man generere støttedokumenter slik som «burndown-grafer» som gir en grafisk fremvisning av fremdriften i en sprint. Confluence er en wiki-løsning med avansert tekst-formaterings-støtte. Vi bestemte tidlig at all dokumentasjon og støttelitteratur underveis i prosjektet skulle opprettes og lagres der siden de da kunne gjøres tilgjengelig også for Accenture og veileder på HiOA uten å måtte sende dokumenter over mail. Vi planla også å skrive detaljerte prosjektdagbøker for å logge arbeid underveis i prosjektet. 3.4 Valg av teknologi Da kravspesifikasjonen var ferdigstilt og godkjent av oppdragsgiver måtte vi bestemme oss for hvilken teknologi som skulle benyttes i utviklingen. På møtet med de eksterne veilederne fra Accenture ble det foreslått at vi skulle utvikle en to-delt applikasjon, med en frontend i AngularJS som kommuniserte med et REST-API, en backend, utviklet i Java Java Vår tidligere, og eneste, erfaring med utvikling av avanserte web-applikasjoner var ved hjelp av C#/Asp.net, så dette ble tidlig vurdert som et alternativ for server-logikken. Vi hadde et møte med Accenture etter ferdigstillelsen av kravspesifikasjon der vi foreslo å utvikle applikasjonen ved hjelp av C# og.net-rammeverket. Etter møtet med Accenture vurderte vi deres forslag med å utvikle et REST-API i Java. De hadde mest erfaring med Java-utvikling og mente dette var en god løsning. De tilbød seg også å være behjelpelige med tips og hint hvis vi mot formodning skulle sette oss helt fast. En av fordelene vi fant ved å velge Java i stedet for.net-miljøet var plattformuavhengighet..net har linux-støtte ved hjelp av eksterne biblioteker, men kan ikke måle seg med Java sin støtte på tvers av alle plattformer. Dette var et hensyn som var naturlig å ta siden vi kom til å utvikle både på windows og på OSX. Ved å velge en Java-basert løsning ville vi også få større valgfrihet i forhold til hvilket hosting-selskap vi ønsket å publisere applikasjonen til. Vi hadde litt tidligere erfaring med Java, men ikke til webutvikling. Vi leste om forskjellige alternativer og tilgjengelige biblioteker man kunne benytte for å utvikle et REST-API i Java. Vi kom frem til at dette ville være et godt valg, med tilstrekkelig mange oppdaterte læringsressurser på nett

12 Kombinasjonen av plattformuavhengighet, vår tidligere erfaring med språket og et inntrykk av at det var mange ressurser tilgjengelig på nett gjorde at vi bestemte oss for å utvikle REST-API-et i Java i stedet for.net AngularJS og Bootstrap 3 Under arbeidet med kravspesifikasjonen ble det klart at applikasjonen skulle være tilpasset både PC og mobil, noe som førte til at vi bestemte oss for å benytte Bootstrap 3 som CSS-rammeverk da dette er utviklet spesielt for å støtte skjermer av forskjellig størrelse. Tidlig i prosessen vurderte vi å bruke javascript-rammeverket AngularJS 7 til å lage nettsiden. Vår oppfatning var at dette var et rammeverk med store muligheter for å lage interaktive nettsider. Vi fikk inntrykk av at dette var veldig populært og fant mange læringsressurser som indikerte at dette ville være overkommelig å lære seg. Nettsiden til rammeverket lover blant annet god støtte for testing av logikken, enkel data-binding og en fornuftig modell. Totalinntrykket vårt av rammeverket var at det kunne være svært aktuelt å lære seg for å stille bedre forberedt til arbeidslivet Arkitektur Etter å ha bestemt hvilke teknologier som skulle benyttes til å utvikle nettsiden og REST-API-et måtte vi ta en vurdering på hvordan de to delene skulle bygges opp. Siden vi tidligere hadde bestemt oss for å drive test-drevet utvikling valgte vi arkitektur deretter. Vår tidligere erfaring med å utvikle webapplikasjoner etter en MVC-modell og erfaring fra å teste webapplikasjoner utviklet etter denne modellen gjorde at vi bestemte oss for dette uten videre diskusjon. AngularJS legger til rette for å utvikle nettsider etter en lignende arkitektur, MVVM, så vi valgte å følge rammeverkets anbefalte tilnærming. Etter å ha undersøkt de forskjellige alternativene man hadde ved utvikling av REST-API-er i Java var det helt klart beste alternativet å utvikle en «servlet». En servlet kan publiseres til forskjellige servletcontainere, som for eksempel Jetty eller Tomcat Valg av verktøy Vi ønsket å ha et komplett utviklings- og produksjons-miljø slik at deling av kode og publisering av applikasjonen skulle være så smertefritt som mulig Versjonskontroll Det ble ytret et ønske om at vi skulle benytte oss av Accentures interne versjonskontroll-løsning, kalt Innersource, som er basert på Git. Vi hadde tidligere erfaring med Git og så ikke for oss at dette skulle bli noe problem Bygg- og avhengighets-verktøy Når man utvikler en Java-applikasjon er det vanlig at man benytter seg av et bygg- og avhengighetsverktøy slik som Maven eller Gradle, da bruken av eksterne biblioteker kan tilby mye funksjonalitet for liten innsats og på sikt forbedre produktet. Ved å benytte slike verktøy gjør man prosessen enklere ved at man ikke må laste ned og konfigurere eksterne biblioteker manuelt. Avhengigheter kan defineres i en konfigurasjonsfil og verktøyet kan ta seg av nedlasting av riktig versjon. Vi vurderte Maven og Gradle opp mot hverandre. Vi fikk inntrykk av at Maven var mer utbredt, men at Gradle var nyere, hadde økende popularitet og enklere konfigurasjon. Undersøkelser vi gjorde ga oss et inntrykk av at Gradle hadde bedre innebygd støtte for å konfigurere bygging av applikasjoner. 7

13 Siden vi kom til å benytte oss av teknologi og verktøy vi manglet erfaring med gjorde vi vurderingen at det ville være lurt å minimere bruken av for mange forskjellige verktøy. Da Gradle også har støtte for å benytte seg av alle biblioteker gjort tilgjengelig for Maven valgte vi å benytte oss av dette Publiserings-verktøy og produksjonsmiljø Jenkins 8 ble valgt som publiseringsverktøy. Jenkins kan konfigureres til å hente ned kildekode fra et Git-repository og kjøre Gradle-scripts. I tillegg er det mange plugins til Jenkins som blant annet kan konfigureres til å logge seg inn på en server som kjører Tomcat og publisere en servlet til denne. Vi fikk tilgang til en nyinstallert Jenkins-instans på en virtuell server hos Amazon ved prosjektstart og så ikke noen grunn til å ikke benytte denne. 3.5 Fremdriftsplan Etter beslutningene om valg av metodikk, teknologi og verktøy var tatt, satte vi i gang med oppsett av en fremdriftsplan. Vi ble enige om at utviklingen av produktet skulle pågå frem til 25 April, og at produktet skulle være ferdigstilt på dette tidspunktet. Dokumentasjonen skulle utarbeides da og frem til en uke før innlevering, altså 21 Mai. Vi satt opp en milepælsplan basert på antallet sprinter vi satte opp, innlevering av dokumentasjon til trykk og frist for innlevering av hele prosjektet satt av HiOA. Figur [3.5] Milepælsplan Vi startet selve utviklingen av produktet 28 Januar og bestemte at prototype skulle være ferdigstilt ved utløp av sprint 1. De neste sprintene frem til siste sprint skulle bygge på brukerhistorier hentet fra backlog. Sprint 6, den siste sprinten, skulle kun gå i å fikse identifiserte bugs fra tidligere sprinter og finpuss på applikasjonen. Ingen ny funksjonalitet skulle legges til i denne sprinten, med mindre det var funksjonalitet som nesten var ferdigstilt tidligere i prosjektperioden. Om det var tilfelle bestemte vi oss for at det da var akseptabelt at ett eller to av gruppemedlemmene brukte deler av denne sprinten til å gjøre den funksjonaliteten ferdig. 8

14 4 Utviklingsprosessen I dette kapitlet presenteres hvordan prosjektet ble gjennomført, hvordan gjennomføringen endret seg i forhold til det som ble planlagt i planleggingsfasen og hva som forårsaket endringene. 4.1 Dokumentasjon Prosjektdagbok Vi hadde på forhånd planlagt å skrive detaljerte prosjektdagbøker underveis, men etter å ha blitt vant til å bruke Jira gikk vi over til å logge mesteparten av arbeidet der. Jira hadde støtte for at man kunne logge antall timer til hver deloppgave i en brukerhistorie. Dette gjorde det lett for oss i etterkant å se hvor mye tid vi brukte på implementasjonen av en brukerhistorie og differansen mellom estimert tid. På bakgrunn av merverdien vi fikk ved å logge arbeid i Jira valgte vi å ikke bruke ekstra tid på å skrive detaljert prosjektdagbok med arbeidslogg, men kun føre inn notater og arbeid som ikke var relatert til spesielle brukerhistorier i dagboken.

15 4.1.2 Møtereferater Vi hadde møter både med Accenture og veileder på HiOA med jevne mellomrom. I forkant av hvert måte utarbeidet vi et forslag til agenda i et møtereferat-dokument på Jira. I etterkant av møtet ble dette dokumentet utfylt med selve referatet og en kort oppsummering, slik at informasjon som kom frem på disse møtene ikke skulle bli tapt. Vi hadde stor nytte av disse møtereferatene da tilbakemeldingene vi fikk på møtene var med på å forme videreutviklingen av applikasjonen i tillegg til å styre vårt fokus ved prioritering av brukerhistoriene til sprintene. Dato: Sted: NAV Agenda Tittel Mål Kommentar Få underskrevet kontrakter Undersøke ang. rolle som produkteier Vise frem det vi har nå Få feedback(der det trengs) Få ned noen punkter ang hva "workshopen" skal inneholde Oppsummering: Vi viste frem prosjektet til veilederne, og gikk gjennom hvordan ting fungerte. Fikk unnagjort kontraktskriving. Referat: Gjennomgang av prosjektet, koden vi hadde til nå, og hvordan vi har løst forskjellige ting. På forespørselen om Accenture-gutta vil fungere som en realistisk produkteier fikk vi positiv feedback. Vi ble enige om at det ikke lenger var nødvendig å ha møter hver uke, men at det var bedre å ha ha møte med demo etter hver sprint. Angående workshop ble vi enige om at vi skal finne noen punkter vi har lyst til å jobbe med, som vi kan få veiledning på. Én idé for tema er workshop på TDD Figur 4.1 Eksempel på møtereferat 4.2 Benyttet metodikk Gjennom nesten hele prosjektet, sett bort ifra enkeltdager der vi jobbet ekstra for å nå en tidsfrist, la vi opp arbeidsdagene våre etter tradisjonell modell, med arbeidsdag fra Hele gruppen møtte opp på skolen for å jobbe sammen. Vi møttes minst fire dager i uken for å jobbe med prosjektet. På grunn av andre fag, jobb og andre hendelser var vi ikke fulltallige hver dag, men ved prosjektslutt hadde alle gruppemedlemmene tilnærmet likt antall timer benyttet på prosjektarbeidet.

16 4.2.1 Arbeidsfordeling I utviklingsperioden fordelte vi arbeidet i to, der halve gruppen fokuserte på utviklingen av AngularJSapplikasjonen, og den andre halvdelen fokuserte på REST-API-et og utviklingen i Java. Vi satt tett sammen og diskuterte mye underveis i utviklingsprosessen, så alle hadde hele tiden basiskunnskap nok i begge deler av applikasjonen til å bedrive enkel feilretting. Denne arbeidsfordelingen mener vi fungerte svært godt underveis, da den la til rette for at vi kunne spesialisere oss i større grad på hver vår plattform og produsere god kode med større effektivitet Scrum Arbeid med Scrum var nytt for flere av oss i gruppen. Vi hadde enkelte startvansker og tok oss selv i å flere ganger gå vekk i fra sentrale prinsipper i metodikken. I deler av prosjektet holdt vi daglige «standup»-møter, korte møter der vi presenterte hva hver av oss hadde gjort forrige dag og hva vi skulle jobbe med den dagen. Fra tid til annen ble disse møtene gjennomført på en uformell måte ved at vi snakket sammen gjennom hele dagen og etter endt arbeidstid. Metodikken vi fulgte var ikke utelukkende tradisjonell Scrum. Det viktigste for oss var å fokusere på smidige prinsipper, ha fokus på konstant fremgang i utviklingen, inkrementell utvikling og mange leveranser i tillegg til et fokus på å gjøre pragmatiske valg underveis. Dette for å forsikre oss om at et fungerende produkt kunne levers ved prosjektslutt. Vi mener at vår pragmatiske tilnærming vises i de valgene vi gjorde underveis, da vi prioriterte bort enkelte aspekter som voldte oss problemer og hindret effektivt arbeid. Det ble for eksempel i de første sprintene lagt mindre fokus på testdrevet utvikling for å kunne levere en fungerende prototype tidlig, da vi hadde problemer med rammeverkene som skulle kjøre testene for oss. Før hver sprint gikk vi gjennom backlogen og omprioriterte denne. Deretter valgte vi de viktigste brukerhistoriene, lagde tidsestimater og bestemte at disse skulle implementeres i løpet av sprinten. Ved slutten av hver sprint kjørte vi en demo for produkteiere hvor vi presenterte applikasjonen, viste endringer, diskuterte tekniske løsninger og fikk tilbakemelding på vår planlegging av påfølgende sprint. De brukerhistoriene vi ikke rakk å implementere fullstendig ble ved sprint-slutt overført til backlogen, slik at disse kunne bli tatt med i neste sprint Bruk av Jira Agile En svakhet ved Jira Agile, som vi benyttet som prosjektstyringsverktøy, er at dette ikke tok hensyn til antall timer vi logget på hver brukerhistorie ved generering av burndown-grafer. Siden vi hadde delt fokus på utvikling av API-et og utviklingen av nettsiden hadde vi flere tilfeller der brukerhistorier ble stående i sprint-oversikten som uferdig, fordi det manglet små endringer enten i API-et eller i nettsiden. Dette gjorde det vanskeligere å dra nytte ut av burndown-grafene da disse ga ofte ga et skjevt bilde av hvor mye arbeid som gjensto per brukerhistorie.

17 Figur [4.2] Burndown-grafen for sprint 4 Hadde vi delt opp brukerhistoriene våre til å ha en brukerhistorie for utvikling av funksjonalitet av API-et og en brukerhistorie for utvikling av nettsiden ville vi unngått problemet over. Fordi vi tidvis hadde tekniske problemer i begge deler av applikasjonen ble brukerhistorier overført til neste sprint selv om det kun manglet små detaljer Forbedringspotensial Vi mener at vi burde vært strengere mot oss selv og fokusert mer på å holde faste standup-møter for å opprettholde en god rutine, da vi i en enkeltperiode ikke hadde formelle standup-møter flere dager på rad. I det tilfellet førte det ikke til noe stort problem, men vi erfarte at når man først begynner å gå vekk i fra enkle rutiner, er det lettere å også gå vekk i fra andre. I retrospekt er vi enige om at vi burde vært flinkere til å jobbe mot hurtig ferdigstilling av en og en brukerhistorie, da dette ville gitt en mer realistisk oversikt over hvordan vi lå an i utviklingen. Vi mener allikevel at fremdriften var god og at det er uunngåelig at man må vente på hverandre når man følger en utviklingsmodell der man deler opp gruppen og fokuserer på hver sin del av applikasjonen. Vi burde før utviklingen av hver enkelt brukerhistorie som innebar arbeid både i API-et og på nettsiden utarbeidet en enkel oversikt over hvordan JSON-objektene som skulle sendes de i mellom skulle se ut. Når vi arbeidet med disse brukerhistoriene ble ofte API-et ferdigstilt før arbeidet med AngularJS-delen begynte. Dette førte til at vi ved flere tilfeller måtte gå tilbake for å endre API-et fordi vi hadde oversett informasjon som måtte sendes da dette ble utviklet. Ved å utarbeide en mer detaljert oversikt over JSON-objektene kunne vi sørget for en mer strømlinjeformet utviklingsprosess der man hadde sluppet å hoppe frem og tilbake mellom brukerhistorier for å ferdigstille disse. De neste underkapitlene beskriver arbeidet utført og eventuelle utfordringer verdt å trekke frem i hver sprint gjennom hele prosjektet, samt andre ting verdt å trekke frem fra sprinten. Brukerhistoriene som blir referert til i dette kapitlet har en navnekode på formen HP-{*tall*}. Dette er identifikatoren brukerhistorien fikk når denne ble opprettet i Jira. Disse er ikke sekvensielle, eller i noen bestemt rekkefølge, da opprettelse av under-oppgaver på disse brukerhistoriene.

18 Brukerhistorier Sprint 1 HP-5 Som en bruker ønsker jeg å kunne logge inn HP-7 HP-8 HP-10 HP-14 HP-22 HP-24 Som en bruker ønsker jeg å kunne registrere meg Som en bruker ønsker jeg å kunne logge ut fra siden uansett hva jeg gjør Som innlogget bruker ønsker jeg å kunne opprette et spørsmål Sette opp et test-miljø Look & Feel på websiden Som en bruker ønsker jeg å lese spørsmål stilt av andre I sprint 1 kom vi sent i gang med både programmeringen og bruk av Scrum metodikken. Store deler av tiden gikk med på å sette opp og konfigurere et uviklingsmiljø. Vi fikk påbegynt implementasjon av design basert på tidligere utarbeidet skisser, og visning av opprettede spørsmål både front-end og back-end. Vi bestemte oss for å vente med registrering av bruker og innloggingsfunksjonalitet ettersom vi mente det var viktigere å få på plass en fungerende prototype med utkast til design, opprettelse av spørsmål og visning av opprettede spørsmål. Brukerhistoriene som gjaldt registrering og innlogging ble derfor flyttet til sprint 2. Som en følge at vi ikke fikk 100% ferdigstilt de andre brukerhistoriene ble disse også flyttet over i sprint Brukerhistorier Sprint 2 HP-5 Som en bruker ønsker jeg å kunne logge inn HP-7 HP-8 HP-9 HP-10 HP-11 HP-12 HP-13 HP-22 HP-23 HP-24 HP-42 HP-61 Som en bruker ønsker jeg å kunne registrere meg Som en bruker ønsker jeg å kunne logge ut fra siden uansett hva jeg gjør Som en bruker ønsker jeg å kunne nullstille mitt passord Som innlogget bruker ønsker jeg å kunne opprette et spørsmål Som innlogget bruker ønsker jeg å kunne redigere mine egne innlegg Som innlogget bruker ønsker jeg å kunne svare på spørsmål som allerede har blitt opprettet Som innlogget bruker ønsker jeg å kunne gi spørsmål rating basert på innhold Look & Feel på websiden Look & Feel - tilpasset mobile enheter Som en bruker ønsker jeg å lese spørsmål stilt av andre Som utvikler ønsker jeg å ha "mal"-funksjonalitet på menyer o.l. Dokumentere funksjonalitet etter møte Under sprint 2 fikk vi på plass ferdigstilt registreringsfunksjonalitet med et utkast til design. Opprettelse av spørsmål og svar funksjonalitet ble også implementert. Dette ble i den omgangen gjort slik at bruker ID måtte fylles inn for å opprette og svare på spørsmål ettersom innlogginsfunksjonaliten fortsatt ikke var på plass. Design, frontend og backend funksjonalitet ble også ferdigstilt for å kunne lese opprettede spørsmål. Når det gjaldt innlogging fikk vi implementert dette i databasen samt håndert passord kryptering backend. Frontend ble også knyttet opp mot backend for å skrive inn påloggingsinformasjon. Under

19 denne sprinten slet vi en del med å finne den riktige autentiseringsmetoden. Dette på grunn av lite kunnskap om hva som var det beste alternativet for dette ved applikasjoner som benytter seg av et RESTfult-api. Det gikk derfor mye tid til undersøkelse av dette og lesing av artikler for å prøve å finne ut det som var best å bruke. Ettersom det tok en god del tid uten at vi kom noen vei bestemte vi oss for at vi flyttet denne brukerhistorien over til sprint 3 for å unngå at fremdriften stoppet helt opp. Dette betød at også brukerhistoriene som hadde som forutsetning at brukeren var innlogget ble flyttet til neste sprint. Vi tok også avgjørelsen om at vi avventet med brukerhistorier angående design da vi anså å få på plass fungerende funksjonalitet som viktigere. Derfor ble Look and feel tilpasset mobile enheter også flyttet til neste sprint.

20 Brukerhistorier Sprint 3 HP-5 Som en bruker ønsker jeg å kunne logge inn HP-8 HP-9 HP-11 HP-13 HP-17 HP-18 HP-73 HP-76 HP-77 HP-79 Som en bruker ønsker jeg å kunne logge ut fra siden uansett hva jeg gjør Som en bruker ønsker jeg å kunne nullstille mitt passord Som innlogget bruker ønsker jeg å kunne redigere mine egne innlegg Som innlogget bruker ønsker jeg å kunne gi spørsmål et rating basert på innhold Som en bruker ønsker jeg å kunne tagge mine egne spørsmål med merkelapper Som innlogget bruker ønsker jeg å kunne slette mine egne innlegg Som en bruker ønsker jeg at siden skal huske at jeg har logget inn Som en bruker ønsker jeg å finne frem i innlegg ved hjelp av en søkefunksjon i trådtitler Som en bruker ønsker jeg å kunne finne spørsmål basert på hvilke tags tråden har Som en front-end utvikler ønsker jeg at REST-apiet skal benytte seg av HAL I sprint 3 jobbet vi en god del videre med autentisering av bruker. Vi hadde fortsatt utfordringer med å velge den riktige autentiserings-metoden, og prøvde ut forskjellige metoder. Vi satte inn alle ressursene våre på dette noe som førte til at resten av brukerhistoriene ble satt på vent. Vi fikk dette nesten ferdigstilt, men kom ikke helt i mål, og ble nødt til å flytte denne videre til neste sprint sammen med resterende brukerhistorier Brukerhistorier Sprint 4 HP-5 Som en bruker ønsker jeg å kunne logge inn HP-8 HP-9 HP-11 HP-13 HP-17 HP-18 HP-73 HP-76 HP-77 HP-79 HP-102 HP-131 Som en bruker ønsker jeg å kunne logge ut fra siden uansett hva jeg gjør Som en bruker ønsker jeg å kunne nullstille mitt passord Som innlogget bruker ønsker jeg å kunne redigere mine egne innlegg Som innlogget bruker ønsker jeg å kunne gi spørsmål et rating basert på innhold Som en bruker ønsker jeg å kunne tagge mine egne spørsmål med merkelapper Som innlogget bruker ønsker jeg å kunne slette mine egne innlegg Som en bruker ønsker jeg at siden skal huske at jeg har logget inn Som en bruker ønsker jeg å finne frem i innlegg ved hjelp av en søkefunksjon i trådtitler Som en bruker ønsker jeg å kunne finne spørsmål basert på hvilke tags tråden har Som en front-end utvikler ønsker jeg at REST-apiet skal benytte seg av HAL Som en bruker ønsker jeg å endre informasjon om seg selv Kræsjer pga for mange connections i databasen En dag inn i sprint 4 var innlogginsfunksjonalitet på plass noe som gjorde at vi fikk fullført alle brukerhistorier som krevde innlogging og fremdriften fikk en mye bedre flyt. Alle brukerhistorer i denne sprinten ble implementert.

21 Brukerhistorier Sprint 5 HP-15 Som innlogget bruker ønsker jeg å redigere mine egne svar HP-20 HP-78 HP-140 HP-141 HP-142 HP-143 HP-145 HP-146 HP-147 HP-148 HP-149 HP-150 HP-153 HP-172 HP-189 Som en bruker ønsker jeg å kunne velge skoletilhørighet Som en bruker ønsker jeg å finne frem til spørsmål ved å søke i deres innhold Som en eier ønsker jeg at nye brukere skal verifisere epost Som en bruker ønsker jeg å kunne sortere spørsmål etter antall poeng Som en bruker ønsker jeg å kunne søke etter flere sammenslåtte tags Som en bruker ønsker jeg å kunne pinne tags Som en bruker ønsker jeg å kunne kommentere innlegg Som innlogget bruker ønsker jeg å kunne gi poeng til svar Som innlogget bruker ønsker jeg å kunne velge beste svar på mitt innlegg Som en bruker ønsker jeg at svar er sortert etter høyeste poengsum Som en bruker ønsker jeg et varslingsystem Som en eier ønsker jeg at siden skal være brukervennlig Som en eier ønsker jeg å kunne ha moderator/admin funksjonalitet Som en bruker vil jeg slette mitt svar Som bruker vil jeg at dato skal vise klokkeslett Fikk gjennomført en del brukerhistorier som en innlogget bruker får redigere innlegg, sortere spørsmål etter poeng, innlogget bruker gi poeng til svar, velge beste svar, sortere svar etter poengsum, slette svar I sprint 6 fikk vi implementert en god del brukerhistorier som at en innlogget bruker kunne redigere sine egne innlegg, gi poeng til svar, velge et beste svar på sitt spørsmål og også slette svar. Sortering etter poeng på tråder og svar ble også implementert. Vi ble også nesten ferdig med brukerhistorien som gjaldt skoletilhørighet. Vi fikk opprettet databasetabell og gjort alle nødvendige modifiseringer back-end, samt implementert at en bruker kunne velge skole ved registrering. Her manglet vi kun front-end at en bruker kunne velge å ikke være student ved registrering, og at en bruker kunne fjerne skoletilhørighet i etterkan. Brukerhistorier som søking basert på tags og kommentering av innlegg var også nesten ferdigstilt. Ved søking basert på tags ble all front-end funksjonalitet implementert ferdig. Kommentering av innlegg manglet kun å at feltet ble tømt etter opprettelse. «Som en eier ønsker jeg at siden skal være brukervennlig» ble brukt som en brukerhistorie hvor vi fikk fikset en del på designet. Denne ble nesten ferdig og manglet bare småprik som en knapp i tillegg til å kunne trykke enter-tasten for å opprette en kommentar. Vi ble i neste sprint enige om at vi kun ønsket å bruke enter-tast for opprettelse av kommentar.

22 Brukerhistorier Sprint 6 HP-20 Som en bruker ønsker jeg å kunne velge skoletilhørighet HP-23 HP-78 HP-139 HP-140 HP-142 HP-143 HP-144 HP-145 HP-149 HP-150 HP-151 HP-152 HP-153 HP-154 HP-189 HP-218 Look & Feel - tilpasset mobile enheter Som en bruker ønsker jeg å finne frem til spørsmål ved å søke i deres innhold Som en bruker ønsker jeg at trafikken skal gå over SSL slik at mine brukerdetaljer er trygge Som en eier ønsker jeg at nye brukere skal verifisere epost Som en bruker ønsker jeg å kunne søke etter flere sammenslåtte tags Som en bruker ønsker jeg å kunne pinne tags Som en bruker ønsker jeg å kunne formatere egne innlegg Som en bruker ønsker jeg å kunne kommentere innlegg Som en bruker ønsker jeg et varslingsystem Som en eier ønsker jeg at siden skal være brukervennlig Som en eier ønsker jeg en epost tjener på serveren Som en ny bruker ønsker jeg å få en guidet tur gjennom funksjonaliteten på siden Som en eier ønsker jeg å kunne ha moderator/admin funksjonalitet Som en bruker ønsker jeg å kunne se innlegg stilt av spesifikke brukere Som bruker vil jeg at dato skal vise klokkeslett Som en innlogget bruker ønsker jeg å kunne slette mine kommentarer Sprint 6 var den siste sprinten. Vi gjorde en vurdering av viktighet her ettersom tiden begynte å bli knapp. Vi bestemte at brukerhistoriene «Som en eier ønsker jeg at nye brukere skal verifisere epost», «Som en eier ønsker jeg at nye brukere skal verifisere epost» og «Som bruker vil jeg at dato skal vise klokkeslett» ikke skulle prioriteres da vi mente at disse ikke var kritisk funksjonalitet som krevdes for å nå målet vårt Testdrevet utvikling Underveis i prosjektet hadde vi en del utfordringer forbundet med å følge testdrevet utvikling. Siden tankegangen og arbeidsmetoden var ny for oss bestemte vi oss for at vi skulle ha en helt grunnleggende prototype, en nettside som kunne hente ut spørsmål fra et REST-API, før vi forsøkte å følge denne metodikken. Etter at den fungerende prototypen var på plass forsøkte vi å gå over til testdreven utvikling. Siden vi utviklet en to-delt applikasjon, en nettside og et REST-API var det naturlig å skrive enhetstester til begge Backend Mot slutten av sprint 2 hadde mente vi at vi hadde tilstrekkelig kunnskap til å nå gå over til testdreven utvikling av API-et. Siden all logikk i API-et også på dette tidlige tidspunktet var avhengig av data og en datakilde, måtte vi bruke tid på å finne et bibliotek som kunne hjelpe oss med «dependency Injection» for at testingen kunne foregå uavhengig av databasen, slik at reelle data ikke skulle bli berørt ved testkjøring.

23 Siden vi hadde valgt å utvikle API-et etter en MVC-modell var koden som skulle enhetstestes laget i de klassene som til sammen utgjorde kontroller-laget i applikasjonen. Etter å ha fått dependency injection-rammeverket til å fungere sammen med prototypen gikk vi gradvis over til testdreven utvikling. I den første tiden etter overgangen ble enkelte metoder utviklet etter tradisjonell metode fordi vi fant det vanskelig å skrive gode tester på forhånd. Etter å ha opparbeidet litt erfaring foregikk all utvikling testdrevet. Underveis erfarte vi at dette var en metode som potensielt sparte oss for mye ekstra arbeid ved undersøkelse av bugs. Vi klarte ved flere anledninger å fastslå at årsaken til bugs og programkræsj var i implementasjonen som snakket med MySQL-databasen, siden testene på denne programlogikken passerte med test-dataene. Hvis vi oppdaget mangler i testene etter at koden var implementert, som oftest i form av en ny bug, skrev vi en ny test som sjekket etter ønsket atferd, men feilet som en følge av bugen. Deretter refaktorerte vi koden og kjørte testene på nytt. På denne måten økte antall tester kontinuerlig, og hjalp oss med å identifisere flere bugs som vi ikke var forberedte på etter å ha implementert ny funksjonalitet Frontend I slutten av sprint 2 forsøkte vi å også utvikle enhetstester til den prototypen vi hadde utviklet. Vi brukte en stund på å finne et fungerende miljø og verktøy å kjøre testene i, inkludert testmiljøet og test-verktøyet selv foreslått av teamet bak AngularJS. Etter en full uke med prøving og feiling uten noen nevneverdig fremgang måtte vi fastslå at vi manglet noe grunnleggende forståelse for hvordan testing av AngularJS-applikasjoner skal foregå, spesielt med tanke på opprettelse av test-data ved «mocking». I følge rammeverkets hjemmeside er det utviklet med fokus på å tilrettelegge for enkel testing, men våre undersøkelser på nett avdekket at det var mange som også hadde problemer med det samme, spesielt hvis man skulle teste mot et REST-API. Etter å ha brukt så lang tid på å forsøke å få testingen til å fungere måtte vi ta en beslutning om vi skulle fortsette å jobbe mot målet om å drive TDD både i frontend og backend. Logikken i nettsiden handler er stort sett uthenting av data fra REST-APIet og visning av denne, i tillegg til logikk for forskjellig sideoppbygning avhengig av innloggingsstatus. Vi mente at feil i dette ville avdekkes ved aktiv bruk av siden, akseptansetesting og manuell testing, Da vi bestemte oss for å stoppe forsøket på å enhetsteste AngularJS håpet vi å kunne komme tilbake til dette punktet ved et senere tidspunkt i prosjektet, når vår forståelse av rammeverket var bedre. Dette ble vurdert flere ganger mot slutten av prosjektet, men hver gang mente vi at det var bedre å fokusere på implementasjon og finpussing av annen funksjonalitet. 4.3 Akseptansetesting Ved slutten av sprint 6 ble det utarbeidet en akseptansetest som ble oversendt en av veilederne hos Accenture, som gjennomførte denne. Denne tok høyde for all funksjonalitet som var ferdig på det tidspunktet og ble gjennomført på den publiserte applikasjonen. Vi fikk da tilbakemelding på at enkelte deler av applikasjonen ikke fungerte som ønsket. Vi hadde nok tid ved siden av arbeidet med dokumentasjonen, så vi fikk utbedret de oppdagede feilene. I etterkant her flere av gruppemedlemmene gått gjennom samme akseptansetest flere ganger, både på mobil og pc, i forskjellige nettlesere.

24 Vi burde ha utarbeidet akseptansetesten på et tidligere tidspunkt, slik at denne kunne blitt gjennomført jevnlig på de forskjellige brukerhistoriene som ble implementert underveis i utviklingsperioden. I vårt tilfelle var det ingen alvorlige feil som ble oppdaget. Alle feilene tok kort tid å rette opp og det fikk derfor ikke noen konsekvens at akseptansetesten ble gjennomført for alle brukerhistoriene samtidig mot prosjektets slutt. 4.4 Fremdrift Figur [4.3] - Gant-diagram Bildet over viser vår faktiske fremgang i prosjektet, de forskjellige fasene og hvor mye tid brukt på hver aktivitet. Legg spesielt merke til endringen i lengden av sprint 5 og 6. Sprint 5 ble forlenget med en uke da vårt demo-møte med Accenture ble utsatt på grunn av påsken. Sprint 6 ble også forlenget for å få på plass funksjonalitet vi ønsket å ha implementert ved prosjektslutt. I denne sprinten var det kun to medlemmer som jobbet på prosjektet av gangen, mens de to andre fokuserte på arbeid med dokumentasjonen. 4.5 Samarbeid Når man kjenner hverandre så godt som det vi i gruppen gjør, og omgås på sosiale arenaer i tillegg til ved arbeidet på prosjekt, er det en fare for at det blir en glidende overgang mellom disse. Dette var noe vi kunne vært bedre på, da vi i perioder kunne ta lunsjpauser som gikk ut over tiden som ble benyttet til å jobbe med prosjektet. Vi var klar over dette underveis og forsøkte å kompensere ved å sitte lenger noen dager, men dette er ikke en god løsning i lengden da dette går ut over konsentrasjonen og kvaliteten på det som produseres. 5 Sluttproduktet I dette kapitlet kommer vi med oppsummerende kommentarer om hva vi mener om det endelige produktet, hva vi har fått til godt og hva som kan forbedres. For en detaljert beskrivelse av implementert funksjonalitet kan produktrapporten leses. 5.1 Nettsiden Vi er veldig fornøyd med brukeropplevelsen man får ved å besøke nettsiden. Vi mener at applikasjonen oppleves som svært responsiv både ved bruk på mobil og på pc. Vi mener også at vi nådde vårt design-mål med å ha en lettgjenkjennelig nettside. Den minimalistiske stilen setter innholdet i fokus, og det endelige utseendet er nært det utseendet vi så for oss ved prosjektets start. Når man benytter seg av nye rammeverk, og lærer disse på egenhånd, er fare for feillæring. Vårt fokus på å hele tiden levere ny funksjonalitet på webapplikasjonen kan ha ført til at det som blir

25 ansett som beste praksis ved utvikling av AngularJS-applikasjoner ikke alltid har blitt fulgt, og kodekvaliteten avhenger sterkt av når i prosjektperioden den ble skrevet. Vi mener allikevel at kvaliteten til applikasjonen sett under ett er god. Vi er misfornøyd med at vi ikke fikk utviklet nettsiden testdrevet, spesielt siden dette var en av grunnene til at AngularJS ble valgt som rammeverk. Vi mener derfor at vi ikke fullt ut fikk utnyttet rammeverkets potensiale Design Vi har beholdt mye av den samme visuelle stilen vi bestemte oss for helt i starten av prosessen da vi utarbeidet skissene. Nylig stilte spørsmål og søkefeltet er plassert slikt som vi i opprinnelig hadde sett for oss, sentralt i midten av nettsidens forside. Se figur [x.x] og [x.x]. Dette er noe vi tenkte nøye gjennom før vi utarbeidet skissene og dette reflekteres i det ferdige produktet. Når det gjelder visning av et spørsmål er den visuelle stilen også ivaretatt her. Se figur [x.x] og [x.x]. Vi har flyttet ut den planlagte brukerguide «sjekklisten» fra forsiden og plassert den i en utvidbar/sammenleggbar tekstboks i menyen under menyvalget «Om Studass». Se figur [x.x]. Dette gjorde vi for det første for å få enda mer fokus på nylige stilte spørsmål på siden. Nylig stilite «boksen» har også fått utvidet funksjonalitet som vi syntes burde stå i fokus. Denne funksjonaliteten er blant annet at du kan i tillegg til dato sortere etter poeng og tittel. Faner kan opprettes for en innlogget bruker slik at han eller hun kan følge med på spørsmål stilt med bestemte tagger. En annen faktor som spilte inn på denne avgjørelsen om å flytte ut brukerguiden er visning på mobil. Ved å flytte denne i en utvidbar/sammenleggbar tekstboks ble det mye mer brukervennlig for mobil, og få endringer måtte gjøres for få denne tilpasset på de ulike skjermstørrelsene. Se figur [x.x]. Oversikten over «populære» tags bestemte vi oss for å ikke ha med ettersom vi i senere tid så at denne ikke var så relevant for en bruker. Vi så heller at en bruker skulle kunne få følge tags han eller hun synes er interessante.

26 Figur[5.1] Skisse av forside utarbeidet tidlig i prosessen Figur[5.2] Skjermbildet av forsiden til det ferdige produket

27 Figur[5.4] Bildet av brukerguide til det ferdige produktet Til venstre figur [5.5] Forsiden på mobil, Til venstre figur [5.6] Brukerguide på mobil

28 Figur[5.7] Skisse av et spørsmål utarbeidet tidlig i prosessen Figur [5.8] Skjermbildet av et spørsmål til det ferdige produktet

29 5.2 API-et Vi er fornøyd med de ressursene som tilbys av API-et, at disse er strukturert på en god måte, og at det vil være intuitivt for nye utviklere å finne de forskjellige ressursene ved hjelp av den utarbeidede API-oversikten(se vedlegg 6 Fullstendig oversikt over API et) og de prinsippene vi har fulgt ved utarbeidelse av API-et(Disse er beskrevet i Produktrapporten). MVC-arkitekturen var et godt valg for utvikling av et REST-API. Vi baserte arkitekturen på våre erfaringer fra «Webapplikasjoner i C#/.NET» vi hadde tatt på HiOA tidligere og følte oss derfor mye mer komfortable med oppbygning og fremgangsmåte i utviklingen av API-et i forhold til utviklingen av selve nettsiden. Bruken av dependency injection for å abstrahere bort direkte avhengighet av en database mener vi er en svært god løsning. Man kan i teorien skrive en helt ny implementasjon basert på interfacene vi har definert og endre noen få konfigurasjonsfiler for å kjøre løsningen på en helt annerledes databaseløsning. Applikasjonen kjører ved prosjektslutt med en MySQL-instans, men kunne like godt for eksempel kjørt på en dokument-basert database slik som MongoDB i stedet for en relasjonsdatabase. Vi mener vi gjorde rette valg ved å bruke de benyttede rammeverkene. Disse ble i hovedsak valgt for å kombinere avansert funksjonalitet med en overkommelig læringskurve. Vi ble ikke nødt til å bytte ut et rammeverk med et annet underveis, og ingen av rammeverkene ga oss nevneverdig trøbbel sett bort i fra startfasen hvor alt var helt nytt for oss. Vi er svært fornøyd med testdekningen av API-et da vi tror at mesteparten av feilene som kan inntreffe under kjøring blir testet. Ved manuell gjennomgang av testdeknings-rapportene avdekket vi at de stiene i programmet som ikke ble testet var svært vanskelig å teste, da disse ofte kom som en følge av Exceptions som ikke er lett å manipulere frem i en test-setting. 5.3 Videreutvikling Deler av funksjonaliteten utarbeidet i kravspesifikasjonen har ikke blitt implementert, slik som ønsket om å kunne formatere spørsmål og svar. Vi planla at dette kunne gjøres med et open-source bibliotek, men var ikke effektive nok i utviklingen til å implementere dette selv. I tillegg ble det i planleggingsfasen diskutert mulighet for å vise, og sortere brukere etter antall mottatte poeng på spørsmål og svar de har stilt, for å skape en slags status. Dette er funksjonalitet som ikke krever endringer i databasen, så det burde være problemfritt å implementere selv etter at applikasjonen har vært i produksjon i lengre tid.