HOVEDPROSJEKT. Telefon: Telefaks:

Transkript

1 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 12 TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Amnesty International Face2Face - Norway DATO ANTALL SIDER / BILAG 153 PROSJEKTDELTAKERE Simen Sveen, Ozaire Faraz Sajid og Phi Thanh Pham Long INTERN VEILEDER Siri Kessel og Simen Hasselknippe OPPDRAGSGIVER Amnesty International Norway - Oslo KONTAKTPERSON Aamir Ashraf SAMMENDRAG Amnesty International Face2Face - Norway er en webapplikasjon utviklet for å forenkle arbeidet til de ansatte innenfor Face2Face og Fieldmarketing prosjektet. Sentrale funksjoner er: Registrering og visning av ulike form for statistikk. Registrering og visning av timelister og ferier/fravær Tilgjengelig for bruk på mobile enheter Utviklet for videreutvikling 3 STIKKORD ASP.NET Scrum Statistikk 1

2 2

3 Dokumentoversikt Sammendrag... 4 Produktdokumentasjon... 9 Prosessdokumentasjon Vedlegg Referanseliste Figurliste

4 Sammendrag Det viktigste for et hovedprosjektarbeid er å gi studenter en god arbeidserfaring og samtidig lære dem essensen av nettverksoppbygning i næringslivet. Avtalen med Amnesty International Norge kom i stand høsten 2012, med prosjektoppstart og innleveringsfrist Faget gir totalt 20 studiepoeng. Vi vil takke vår kontaktperson i Amnesty, Aamir Ashraf og Amnesty Oslo`s Prosjekt Koordinator Richard Dwomoh som delte av sine erfaringer med oss under hele prosjektet. Vi vil også takke vår veileder ved HiOA, Siri Kessel og Simen Hasselknippe som hele tiden har sørget for at prosjektet holdt stø kurs mot mål. Denne oppgaven dokumenterer applikasjonen som har blitt utviklet for Amnesty International Norge og prosessen bak utviklingen. Amnesty er en organisasjon som kjemper for menneskerettigheter verden rundt og appelerer enhver enkelt person i å delta og støtte visjonen deres gjennom medlemskap, donasjon og gaver. Applikasjonen, som er utviklet, heter Amnesty Face2Face hvor Face 2 Face er navnet på et av flere prosjektarbeid Amnesty driver med. Om gruppen Gruppen består av tre studenter fra både Dataingeniør- og Informasjonsteknologi-studiene. Grunnen til at vi valgte å jobbe sammen var fordi vi tidligere hadde utviklet flere prosjekter under studieløpet ved Høgskolen i Oslo og Akershus. Alle medlemmene er gode på forskjellige fagområder men allikevel har vi felles faglige interesser som styrker oss som en gruppe. 4

5 Problemstilling Amnesty og prosjektgruppen utviklet i koalisjon en problemstilling for oppgaven: Amnesty Face2Face skal være en brukervennlig webapplikasjon for registrering av timelister og statistikker men samtidig være en intern lukket applikasjon ment for å lette papirarbeidet innenfor Face2Face og FieldMarketing avdelingen". Bakgrunn for prosjektet Amnesty hadde lenge strevet med en ordetlig web-løsning for de ansatte og ikke minst de administrerende. Ved hjelp av kontaktpersonen vår fikk Amnesty forespørsel om det var mulig at en gruppe bachelor-studenter løste problemet deres og slik kom oppgaven i våre hender. Etter diskusjon mellom begge partene kom vi frem til at en helt ny applikasjon måtte lages fra bunnen. Dette var fordi vi vil kunne sikre kvalitet gjennom hele produktet og gi fra oss et godt utgangspunkt for videreutvikling. I samarbeid med Amnesty ble det gjort en rekke valg for å sikre at rammen rundt prosjektet var av god kvalitet. Det har hele tiden vært et mål for Amnesty å kunne videreutvikle applikasjonen, da de ønsker å legge til mer funksjonalitet etterhvert og gjøre produktet tilgjengelig for flere prosjekter og avdelinger senere. Siden de ønsker å kunne bruke applikasjonen på flere enheter og plattformer valgte vi derfor en webapplikasjon som den beste løsningen for dette. Produkt Amnesty er en applikasjon ment for å digitalisere papirarbeidet og minske arbeidsmengden til de ansatte under prosjektavdelingen. Det er fire ulike brukernivå i web-applikasjonen: PM er en Prosjekt Medarbeider TL er en Team Leder TLA er en Team Leder med Administrerende rettigheter PK er Prosjektkoordinator 5

6 Videre er det to tre typer statistikker: F2F Statistikk for Face2Face avdelingen FM Statistikk for FieldMarketing avdelingen Bruker statistikk Den store utfordringen har vært å overføre de statistikkene Amnesty hadde på excel-ark over på en web-applikasjon. Applikasjonen er i utgangspunktet utviklet for bruk i vanlige nettlesere, men siden den er tilgjengelig over internett er den også optimalisert for nettbrett og smarttelefoner. Prosess Utvikling av prosessen med Amnesty Face2Face startet i oktober 2012 da ble vi kontaktet av Amnesty. De hadde vår kontaktinformasjon etter at vi hadde meldt interesse for samarbeid via kontaktpersonen vår. Siden vi hadde et par andre prosjekter vi vurderte, samlet gruppen seg og diskuterte de ulike alternativene. Amnesty`s oppgave skilte seg ut fordi den var teknisk kompleks og stilte ingen krav til programmeringsspråk, rammeverk eller teknologi. Dermed stod gruppen fritt for å diskutere med og i enighet bestemme hva den beste løsningen ville være for et slikt prosjektarbeid. Det ble derfor med engang bestemt at dette var oppgaven vi ville jobbe med det neste halvåret. I starten av prosjektet la vi opp en overordnet plan. Vi fulgte utviklingsmetodikken Scrum og skulle operere med sprinter på 2 uker som tilslutt ville resultere i et ferdig produkt. Gjennom hele prosessen har veilederne og kontaktpersonene fra Amnesty vært tilgjengelig dersom vi skulle trenge det. Deres råd og tips angående dokumentasjon, kodearbeid og testing har vært mer enn hjelpsomme og har kun styrket produktets kvalitet. Etter at prosjektperioden har endt har vi et produkt som løser den generelle problematikken til Amnesty. Applikasjonen legger videre til rette for enkel videreutvikling ved at vi har benyttet oss av MVC-prinsippet som gjør at lagene er uavhengige. 6

7 I denne prosjekperioden har alle medlemmer fått en god erfaring med alle fasene i et prosjekt. Det gjelder fra å forholde seg til krav fra oppdragsgiver til gjennomføring og dokumentasjon av prosjektet. Applikasjonen settes i produksjon hos Amnesty i løpet av juni 2013 etter at serveren til applikasjonen er satt opp. 7

8 8

9 Produktdokumentasjon 9

10 10

11 Innholdsfortegnelse for produktdokumentasjon Produktdokumentasjon Rammekrav Produktet Teknologien Systemet Beskrivelse av produktet Innlogging og Forside Menyvalg - Profil Menyvalg - Jobb Menyvalg - Statistikk Menyvalg - Admin Beskrivelse av brukere Brukere - PM Admin - TL, TLA og PK Brukergrensesnitt Verktøy Skisse Mobilt Støtte Arkitektur Presentasjonslaget Logikk laget(bll) Databaseaksesslaget (DAL) Virksomhetlogikk Databasestruktur Testing Brukertest Akseptansetest Planlegging og Metode Scrum Sprint

12 1 Rammekrav Høgskolen i Oslo og Akershus I dette kapittelet vil leseren få innblikk over de ulike kravene som ble satt før produktet iverksattes. 1.1 Produktet Her ser man de viktigste kravene som i utgangspunktet forteller hvordan webapplikasjonen skal fungere. For fullstendig kravspesifikasjon Se vedlegg: Endelig Kravspesifikasjon. Lage fire ulike tilgangsnivåer for applikasjonen (PM, TL, TL+Admin, PK) Lage en fungerende applikasjon som de ansatte ved Amnesty kan ta i bruk for deres markedsavdeling. Lette arbeidet ved å slippe ekstra papirarbeid og får gjort de viktigste operasjonene over nett. Innlogging med eget brukernavn og passord. Se nyheter, kampanjer og rotasjonslister. Se statistikk av ulik data med tanke på rettigheter. E-post notifikasjon Applikasjonen skal utvikles slik at det enkelt kan vedlikeholdes senere. Grundig dokumentasjon og brukerveiledning skal ferdigstilles før innlevering. Applikasjonen skal støtte både engelsk og norsk. 1.2 Teknologien I koalisjon med oppdraggiver ble det satt nødvendig krav for bruk av teknologi. Disse var: Webapplikasjonen skal utvikles i ASP.NET (C#) Skrives i HTML 5 og CSS3 Databasen vi vil bruke er MS SQL Server 2012 Javascript (JQuery rammeverk) vil anvendes og AJAX for brukervennlighet. 1.3 Systemet Minimum systemkrav som trengs for at applikasjonen skal levere ønsket funksjonalitet er: 12

13 .NET 4.5 MVC 4 Høgskolen i Oslo og Akershus MS SQL Server 2012 Amnesty har fastslått at hvis de føler behov for ny server, vil de dekke kostnadene av det. 2 Beskrivelse av produktet I dette kapittelet vil det essensielle ved produktets funksjonalitet beskrives og dets virkemåte. Kapittelet vil videre gi innsikt i de ulike brukernivåene og dets rettigheter og hvilke funksjoner de har i selve applikajonen. Hensikten er å gi en grunnleggende forståelse til applikasjonen og en innføring i brukerhierarkiet. For fullstendig beskrivelse av produktet med skjermbilder se vedlegg: Skjermbilder og skisser av programmet. 2.1 Innlogging og Forside Først og fremst skal produktet ikke være en offentlig siden, men kun internt for de ansatte. "Innloggingssiden" skal ha to datafelt (Brukernavn og passord)og mulighet for å endre språk. Standardspråk er satt til Engelsk, grunnet det multikulturelle miljøet i Amnesty og samtidig var det krav om dette. Forsiden hadde flere viktige funksjoner. Den skulle gi innsikt i hvilke oppgaver som kunne utføres og hva man kunne gjøre i applikasjonen. Man kan blant annet velge mellom notifikasjon, melding eller innstillinger på toppen. I midten har vi kampnajer og nyheter som holder brukeren oppdatert over hendelser i organisasjonen. Det er også søkemulighet på personer og steder i organisasjonen. Hovedmenyene og deres funksjonalitet vil forklares i neste avsnitt. De ulike menyvalgene er ment å virke enkle og forståelige slik at brukeren lett anvender seg til det. Alt i alt skal forsiden virke strukturert og enkel navigerbar. 2.2 Menyvalg - Profil Her vil brukeren se en egen profil etter at vedkommende er registrert som ansatt og har fått tildelt brukernavn og passord av administrasjonen. Denne er ment for å gi brukeren sin egen identitet i organisasjonen og samtidig lette kommunikasjon mellom ledere og ansatte. En overordnet leder kan slik ha styr over alle ansatte, se informasjon om vedkommende som f.eks stilling, kontrakt, telefon og slikt. 13

14 2.3 Menyvalg - Jobb Her vil brukeren har to muligheter: Registrere seg på timeliste til neste uke og se nåværende uke. Registrere fravær eller ferie. Disse to funksjonene er svært nyttige for prosjekt lederne i Amnesty. Ved hjelp av få museklikk kan en ansatt registrere seg på neste uke i timelisten. Dermed kan lederen enkelt printe timelisten og ha ordentlig struktur på hvem som jobber i hvilken tidsperiode. Hvis en ansatt skal melde seg syk, eller ta ferie kan den enkelt gjøre det ved å velge dato og legge til begrunnelse. Dette vil bli tilsendt lederen som da velger å godkjenne dette eller avvise det. 2.4 Menyvalg - Statistikk Denne funksjonen er den sentrale og primære grunnen til at Amnesty følte behov for en nettapplikasjonen. Nå kan ledere se på statistikk til de ulike prosjektdataene. I startfasen er det kun to prosjekter: F2F - Face 2 Face og FM - Field Marketing. Her kan man se statistikkrapporter for ulike tidsperioder. Det er også mulig å se statistikk for ansatte individuelt, dette kalles bruker statistikk. Dette vil hjelpe lederne i å kartlegge blant annet hvor effektive vedkommende er. 2.5 Menyvalg - Admin Her tilbys en rekke administrative verktøy. De overordnede lederne vil ha stor nytte for et slikt verktøy hvor de har kontroll over alle de viktige komponentene i programmet. 2.6 Beskrivelse av brukere Det er fire forskjellige typer brukere i systemet. De blir rangert i tall fra 1-4 hvor 1 står for høyest rettigheter og 4 står for minst rettigheter: Prosjektkoordinator - PK 1 Teamleder (Admin) - TLA 2 Teamleder - TL 3 Prosjektmedarbeidere - PM. 4 14

15 2.7 Brukere - PM Prosjekt Medarbeider (PM) er den brukeren som har minst rettigheter. Dette er brukere som er ansatt for et prosjektarbeid. 2.8 Admin -TL, TLA og PK Team Leder (TL) er den brukeren som har de minste administrative rettighetene men er over PM. Dette er teamledere som har ansatte under seg i et prosjektarbeid og har følgende rettigheter i nettapplikasjon: Team Leder Admin (TLA) er den brukeren som er over PM og TL men under PK. Denne brukeren blir er de samme some TL med fordel av at de har ekstra administrative tilgang og rettigheter. En PK kan bestemme hvem av TL som får TLA autorisasjon. Prosjekt Koordinator (PK) er den brukeren som har høyest rettighet og autorisasjon i applikasjonen. Det er kun en slik bruker per avdeling i Amnesty Norge. 3 Brukergrensesnitt Grafiskbrukergrensesnittet er brukergrensesnitt som lar brukerne samhandle via elektroniske enheter med bilder i stedet for tekst-kommandoer. Det er enkelt sagt grensesnittet mellom menneske og maskinen. Fokuset på GUI ble laget utifra brukergruppen som skulle håndtere nettapplikasjonen framfor alt. Under prosessen om å utvikle best mulig GUI program til brukeren var målet at brukergrensesnittet skulle være mest mulig konsistent. En masterpage er laget for å holde oversikt over strukturen på siden og ha rede på menyer. Masterpagen er lik på alle sider, unntatt inneholdet bare. Font, farger, størrelser på menyer er likt. Masterpage er en fordel å lage i hver nettapplikasjon man utvikler siden det blir mye lettere for de som vil endre layouten eller oppsette på siden senere. De kan da enkelt gjøre endringene på master-pagen, dermed vil det gjelde alle undersider og man slipper å gjøre det på hver side manuelt. 15

16 Nettleserbilde Figur 1: Forside-bildet av applikasjonen Se vedlegg: Skjermbilder og skisser av programmet. 3.1 Verktøy Ulike verktøy ble brukt for å øke brukeropplevelsen og interaktiviteten. jquery AJAX Twitter Bootstrap KnockoutJS jquery Dette er en åpenkilde programvare som er et biblioteket som er lagt oppå Javascript. Denne ble anvendt for interaskjon med AJAX og med tanke på brukervennlighet. Den forenkler klientskripting av HTML-kode som blant annet letter mye arbeid med tanke på dokumentnavigering og hendelsesstyring. 16

17 AJAX Det står for Asynkron Javascript og XML. Denne har som mål å gjøre sider mer interaktive og gi brukere følelse av bedre responsive sider. AJAX ble valgt fordi det lå hånd-i-hånd med produktets mål. Design messig ville dette bare forbedre siden og selve opplevelsen av den. Twitter Bootstrap Dette er en gratis sett av verktøy som kan brukes for web-løsninger og applikasjoner. Den har HTML og CSS baserte mal for blant annet fomer, knapper og andre interface komponenter. Dette verktøyet har vært til hjelp med tanke på ulike ikoner og interface. Som designkrav til produktet var målet om å ha en responsiv design og dette verktøyet har kun forsterket det. KnockoutJS Dette er en alenestående Javascript implementasjon av UI (User Interface). Denne forenkler bruk av komplekse komponenter som videre fører til at sidene virker mer responsive og samtidig øker bruker opplevelsen. 3.2 Skisse Alle skisser ble laget i programmet Balsamiq Mockups. Denne programvaren har vært svært nyttig, siden du enkelt kan visualisere det du tenker og trekke tidlige konklusjoner om flyten videre. Dette sparer ikke bare tid men hjelper også til møter med oppdragsgiver. Figur 2: Her ser man prototypen av innloggingsiden Se vedlegg: Skjermbilder og skisser i programmet. 17

18 3.3 Mobilt Støtte Som krav skulle applikasjonen støtte mobile enheter. Dette er blant annet her vi kommer nærere inn på responsivt design. Applikasjonen er testet i LG Nexus 4 men også testet vellykket i Samsung Galaxy Note 2, HTC desire HD og iphone 4S. Figur 4: Innloggingsside på mobil Figur 3: Forsiden på mobil 4.Arkitektur Det er viktig å ha en solid arkitektur på nettapplikasjonen som inneholder flere klasser og filer. Det er mange faktorer som må vurderes når man skal utvikle en applikasjon. Vurderinger som må ivaretas er ytelser, skalerbarhet og utvikling videre av produktet. Arkitekturmodellen brukt er en lagdelings arkitektur. Lagdelt arkitektur er en lag av grupperinger med klasser, pakker eller subsystemer. Hvert lag er fokusert på et felles ansvar for et hovedområde av systemet. Høyere lag bruker tjenester på lavere lag. Slik er en tre lags arkitektur: Brukergrensesnittet Applikasjonslogikk på applikasjons-server 18

19 Data på databaseserver Hvorfor lagdeling? Trenger struktur ved store applikasjoner. Oppnår seperasjon av ansvar, og av tjenester som reduserer kopling, bedrer kohesjon, øker mulighet for gjenbruk samt klarhet. Relatert kompleksitet er innkapslet og kan dekomponeres. Dele koden inn i presentasjon, virksomhets- og datalag. Flytte data mellom lagene, via objekter/variabler begge veier. Gjøre de riktige tingene i lagene, f.eks håndtere data inn og ut av aspx siden i presentasjonslaget. Lagdelingsarkitekturen gir en modell for å lage fleksible og gjenbrukbare applikasjoner. Denne applikasjonen har 3 lag som består av: Presentasjonslaget som er helt øverst, deretter kommer virksomhetslaget som er i midten og til slutt dataaksesslag helt nederst. Dette ser vi illustrert under på bildet: Figur 5: Lagdeling i arkitektur 19

20 Figuren viser hvordan lagdelingsarkitekturen er satt opp. Figuren kan tolkes som at i bunn av systemet er det en felles database og backup system for lagring av ansatt-informasjon,nyheter/kampanjer og ulike statistikk og skjemaer. Over denne lagringsenheten har man forskjellige applikasjoner som henter data fra databasen. 4.1 Presentasjonslaget Presentasjonslaget er det som vises innen bruker grensesnittet til brukeren. Presentasjonslaget består av en rekke individuelle nettsider som samarbeider og sender data til hverandre gjennom HTTP Request objekter og sesjon objekter på tjeneren. Nettsidene er skrevet som aspx nettsider. Laget består av.aspx filer. I dette laget ligger alle bilder, CSS filer og Master Page filer. Her ser man en overordnet oversikt over alle lagene i Visual Studio: Figur 6: Presentasjonslaget - Oversikt over laget Figur 7: Presentasjonslaget - Oversikt over alle komponentene i lagene 20

21 Kode eksempel - Meny Hovedmenyen bruker Filter attribute for å sette hvilken menyvalg som er valgt. Figur 8: Kode-eksempel - MenyAttribute.cs Selve attributfilteret som setter hvilken menyvalg som er valgt. MenyController bruker TempDataName for å hente hvilken som er valgt. Figur 9: Kode-eksempel - ProfileController.cs Eksempel på hvordan man setter hvilken meny som er valgt. 4.2 Logikk laget(bll) Det logiske konseptuelle nivået representerer databasen på modellnivå. Det konseptuelle nivået er en abstrakt framstilling av hele databasen. Det totale beskrivelsen som ligger i det nivået er skjemaet av alle tabeller, altså det viser hele informasjonsinnholdet i databasen. Ansvaret som ligger for dette nivået er å håndtere og validere data og server-validering er en av valideringskravene fra input data. Laget består av klassebiblotek med flere cs(c#) filer. 21

22 Figur 10: BLL - Oversikt over filer Under ser man et eksempel på hvordan presentasjonslaget bruker BLL i flere steg: Figur 11: Kode-eksempel - ServiceManager.cs Over ser man en klasse som presentasjonslaget bruker for BLL-laget: Figur 12: Kode-eksempel - BaseController.cs 22

23 Over ser man en klasse hvor alle kontrollere blir utvidet fra: Figur 13: Kode-ekesempel - NewsController.cs Over ser man et eksempel på hvordan presentasjonslaget bruker BLL. 4.3 Databaseaksesslaget (DAL) Dataaksesslaget(dal) er en lag av et dataprogram som gir forenklet tilgang til data lagret i persistente data, som en enhet-relasjonell database. DAL kan returnere en referanse til en objekt (i form av objekt-orientert programmering ) komplett med sine attributter i stedet for en rad av felt fra en database tabell. Dette gjør at klienten (eller brukeren) modulene som skal opprettes med en høyere grad av abstraksjon i stedet for å bruke kommandoer som for eksempel sette inn, slette og oppdatere og få tilgang til en bestemt tabell i en database, en klasse og noen få lagrede prosedyrer kunne dermed opprettes i databasen. Her ligger alt som har sammenheng med database, laget tar imot forespørsler om uthenting, lagring og sletting av innhold i databasen. Figur 14: DAL-laget med innholdsliste 23

24 4.4 Virksomhetlogikk Dette laget har som ansvar å holde orden og oversikt over data. Virksomhetslogikk blir brukt for å holde kontroll for verifisering av data. Laget virker i blant som et mellom lag og har som oppgave å videresende data mellom lagene under og over. 4.5 Databasestruktur Database er strukturert etter en relasjonsmodell som er normalisert slik at redundans unngår. En entitet kan lett utivides med koblinger med nye entiteter etter behov. De to viktigste strukturene i en database er tabeller og indekser. Tabeller er de strukturene som lagrer dataene i databasen. Hver tabell består av en rekke felt (kolonner) i enkelte databasemotorer. Databasestrukturen består av en hovedgruppe som vi har kalt for "User" altså Bruker. Denne utgjør alle brukerne fra de administrerende og ikke-administrerende. Tabellene inneholder videre informasjon om alle mulige entiteter som er på databasen, altså det er ingen hovedtabeller med subtabeller. Strukturen er satt opp slik at hver entitet har sin egen tabellnavn og rettigheter til brukerne, avgjørende om de er admin eller vanlig brukere. På neste side ser man en grundig og fullstending overordnet oversikt over hele databasen og dets komponenter. 24

25 Figur 15: Databasen - En fullstendig oversikt 25

26 Model ser slik ut: Figur 16: Model-laget og dets filer 5 Testing Testing av programmet foretas alltid på flere nivåer for blant annet sikring av kvalitet og oppdagelse av feil. Det er utført testing for å forsikre at applikasjonen fungerer optimalt. Testingen skal avverge feil under kjøringen av applikasjonen og dette kapittelet beskriver de forskjellige testene utført. 5.1 Brukertest Produktet er brukertestet på ulike områder i en grundig dokumentasjon. For fullstendig brukertest, se vedlegg Brukertest. 26

27 5.2 Akseptansetest Høgskolen i Oslo og Akershus Det ble utført en akseptansetest hvor det skulle kartlegges om oppdagsgiver som produktet skal overleveres til var fornøyd med produktet og "aksepterte" det. Denne testen ble desverre utført på en mer utradisjonell måte grunnet tidspress, men ga uansett ønsket tilbakemelding. Figur 17: Akseptansemodell Ved utførelsen av akseptansetesten, hadde gruppen en liste over hvordan oppdragsgiver skulle programvaren og dets ulike funksjoner. - Innlogging og forside: Forventet Oppnådd Innloggingsforsøk og opplevelse av forside Innlogging: Fin. stemmer overens med gitt kravspesifikasjon. Forside: Ok. Et par spørsmål angående de tomme områdene i kampanjer/nyheter og rotasjonslistene. Resultat: God 27

28 - Profil: Forventet Profil utseende og informasjon skal stemme overens med gitt kravspesifikasjon. Resultat: God Oppnådd Utseende: Positivt, godt! Informasjon: God. - Jobb: Forventet Oppnådd Timelister, oppmelding og registrering av Timelister og oppmelding: Bra, men med fravær/ferie er i samsvar med gitt ønske om å se forrige ukes timeliste. Inngikk kravspesifikasjon. ikke i kravspek, derfor ok. Registrere fravær/ferie: God. Resultat: God - Statistikk: Forventet Oppnådd Registrering og visning av F2F, FM og bruker FM/F2F: Ok. Total oversikt over hvor mye statistikk er i samsvar med den gitte arbeid PM, TL og PK var ønskelig, men kravspesifikasjonen. inngikk ikke krav derfor ok Brukerstatistikk: Se snitt av hvor mye PM har jobbet var ønskelig, men ingikk ikke i krav derfor ok. Resultat: Middels - Admin: Forventet Oppnådd Et admin- panel som dekker alle behov og Admin: Ok. Ingen spesiell bemerkning. krav nevnt i kravspesifikasjonen. Resultat: God For fullstendig brukertest, se vedlegg Brukertest. 28

29 6 Planlegging og Metode Her vil vi gå gjennom de ulike verktøyene og metodene som styrket prosjektet. Dette har i utviklingsprosessen, kun øket kvaliteten på sluttresultatet. 6.1 Scrum Scrum er en iterativ og inkrementell håndteringsmetode tilegnet for prosjektarbeid med programvarer. I denne metoden bestemmes kun det som skal gjøres, og ikke hvordan det skal løses eller utføres. Under ser vi hvordan dette fungerer. Figur 18: Scrum-modell Denne utviklingsprossesen har fungert best fordi selve håndtverket er godt og fører til tett samarbeid med brukerne. Det er tilegnet et team-arbeid, som på flere måter er viktig i akkurat dette prosjektet. Den beste siden ved metoden er at den vil nå kunden altså Amnesty`s forretningsmål bedre enn ved bruk av annen metode. 6.2 Sprint En sprint har svært varierende lengder, alt fra en måned til over 2 uker. Ved start av en sprint er det satt som krav å nå et fastsatt mål på en gitt tidsperiode. Dette settes opp som Backlog og er til stor nytte ved at en liste med gjøremål utredes. På slutten av sprintene evaluerer man alltid hvordan arbeidet har utformet seg. 29

30 Figur 19: Sprint Backlog Board Sprint har definert arbeidsmetoden til prosjektarbeidet på alle mulig måter. Gjøremål, oppgaver, ansvarsfordeling og frister har vært strukturerte og effektive for produktets beste. Det har på flere måter definert nettapplikasjonens kvalitet på en begrenset arbeidstid. 30

31 31

32 Prosessdokumentasjon 32

33 33

34 Innholdsfortegnelse for prosessdokumentasjon Prosessdokumentasjon Visjon og Mål Vår Visjon Produktets Mål Prosjektets Mål Bakgrunn for prosjektet Oppgavevalg Om Amnesty Norge Om Oppgaven Kravspesifikasjonen og dens rolle Første utkast Bruk av kravspesifikasjon Endelig kravspesifikasjon Samsvar med produktet Planlegging og metode Tidlig prosjektfasen Valg av utviklingsprosess (UP) Scrum som UP Sprint som hjelpeverktøy Vurdering av Sprintene Arbeidsmetoder Risikoplan Beregning og vurdering Rammeverk Arkitektur Brukergrensesnitt Testing Videreutvikling av nettsiden Konklusjon

35 1 Visjon og Mål I dette kapittelet vil vi gå gjennom visjonen og de ulike målene gruppen hadde satt før prosjektarbeid startet. 1.1 Vår Visjon Vi ser for oss at webapplikasjonen vår vil tilfredstille de ansatte ved Amnesty og effektivisere og lette arbeidet deres. Når prosjektperioden er omme, skal vi overgi produktet og levere inn dokumentasjonen. 1.2 Produktets Mål Produktet skal fungere optimalt og som planlagt. Alle krav og ønsker skal oppfylles. Applikasjonen skal være brukervennlig, ha responsivt design og være lett navigerbar. All dokumentasjon skal være grundig, presis og gjennomtenkt. Mulighet for senere utvidelser skal støttes. Videre vil vi at Amnesty liker produktet og tar bruk av produktet umiddelbart etter prosjektperioden. 1.3 Prosjektets Mål Denne hovedprosjekt oppgaven er en erfaringsfull og spennende mulighet for å kombinere alt du har lært i de tre siste årene i bacheloren. Vi har tilegnet oss nye kunnskaper innenfor nettapplikasjon, programmering og prosjektarbeid. Hovedprosjektet skal være en lærerrik prosess for alle gruppemedlemmer, hvor man lærer av mange utfordringer, spesielt knyttet til tid og ressurs. Alle gruppemedlemmer har sine sterke og svake sider. Gjennom veilederne vi har fått tildelt har vi også ønske om å få best mulig tilbakemelding, både ris og ros på alle mulige områder innenfor et bredt prosjektarbeid. Det handler om å benytte seg av kunnskapen man allerede tilegner og se hvordan man kan utvikle det på et annerledes perspektiv innenfor ditt fagområde. 35

36 2 Bakgrunn for prosjektet En bacheloroppgave er det siste steget i de tre årene du har strevet som student. Det kan også sees på som en mulighet til å vise hva du virkelig er god for eller hvorfor har du gått på høgskole de tre siste årene? Dette får man muligheten til å vise gjennom bacheloroppgave. Studenter i Institutt for informasjonsteknologi, HiOA, leverer inn prosjekter i form av produkter (Programmer/nettsider) eller rapporter (Analyser). Studentene skal finne en arbeidsgiver med et prosjekt og danne en gruppe på 2 til 5 medlemmer. 2.1 Oppgavevalg Før hovedprosjektet startet hadde vi avtalt på forhånd om å jobbe sammen. Derfor ordnet vi et møte der vi diskuterte alternative prosjektoppgaver, men kom ikke fram til noen konkrete hovedprosjektoppgave. Vi hadde planlagt å programmere, og lage noe som kunne anvendes av en bedrift. Vi hadde ingen spesielle krav når det gjaldt prosjektoppgaven, men derimot var programmeringsspråket et spennende tema for oss. Vi var åpne for implementering av hvilken som helst programmeringspråk, alt fra PHP til ASP.NET. Så lenge funksjonaliteten var fungerende og lettvint kunne den utvikles i hvilken som helst programmeringsspråk, og etter enighet tilslutt falt valget tilslutt for ASP.Net, siden det er stort etterspørsel for det i markedet og dessuten ville vi lære mer om dette siden vi allerede hadde hatt faget forrige semester. Vi så på forskjellige bedrifter og fikk kontakt med noen men det var utifra oppdragivere HiOA ga som tilbud for studentene. Utifra en venns rekommendering tok vi prat med Amnesty og de virket interesserte. De sendte oss oppgaveteksten som gruppen snakket og gikk gjennom. Deretter avtalte vi møte med oppdragsgiveren for å få bedre innblikk i hva oppgaven gikk ut på. Etter møtet var alle i gruppen fornøyde med oppdraget, pga prosjektets omfang og de forskjellige faglige utfordringene den hadde. 2.2 Om Amnesty Norge Amensty International Norge er en organisasjon som kjemper for menneskerettigheter over hele verden. Det er en medlemsstyrt organisjasjon som verken er politisk avhengig eller som mottar støtte fra statlige instanser. Amnesty har i Norge ca. 35 ansatte og ca medlemmer og aktivister. Hovedkontoret til Amnesty ligger i Oslo, men de har også avdelinger i Bergen, Trondheim, Stavanger og Tromsø. 36

37 Siden Amnesty er og fremstilles som en ideell organisasjon har de ikke som hovedformål å tjene penger. Inntektene kommer for det meste fra medlemskontingenter, innsamlinger eller som gaver. Men de har også ett eget klesmerke der de designer og produserer skate- og streetwear som de i hovedsak distribuerer til blant annet Session. 2.3 Om Oppgaven Produktet som er utviklet heter Amnesty Face2Face. Face 2 Face og Fieldmarketing er to prosjekt Amnesty Norge driver med. Navnet Amnesty Face2Face er bestemt i koalisjon mellom gruppen og oppdragsgiver. Amnesty Face2Face er en intern program som kommer til å bli brukt av Amnesty Norge, Oslo-avdelingen. Amnesty har ca. 50 ansatte som vil ha bruk for applikasjonen i hverdagsbasis. Måten Amnesty noterer eller holder oversikt over de forskjellige rapportene for eksempel timelister, ansatte og en rekke ulike statistikker blir ført inn på vanlige excel- ark via ordinære windows programmer. Amnesty har ingen nettapplikasjon og database for å holde styr på alt dette. Alt om Amnesty Face2Face og Fieldmarketing handler om papir arbeid og det skjer manuelt. Denne prosessen er både tidskrevende, uorganisert og en tung løsning for Amnesty. Amnesty`s krav og ønske er et produkt som digitaliserer alt arbeidet deres over via et web - grensesnitt. Det skal være muliget for å lagre timelister, registrere ferie/fravær, holde oversikt over en rekke statistikker og annet forfallende papirarbeid. Alt skal lagres på en database på nettapplikasjonen slik at det ligger trygt på en server som kan kontrolleres. Funksjonaliteten skal være på det høyeste nivået når det er snakk om prioritering av ønsket resultat. Dette skal dermed være et system med et enkel brukergrensesnitt, som er svært lett å navigere og anvende. Det forventes videre at bruker av programmet skal ha kun grunnleggende datakunnskaper, slik at den skal virke svært lettvint og gjenkjennelig. Selve oppgavens læringsmål er å utvikle et nytt system som skal være mer brukervennlig enn den manuelle måten og mer effektiv. Videre beskrives det mer grunnleggende hvordan produktet oppfyller de ulike målene og kravene satt i en begrenset tidsramme. 37

38 3 Kravspesifikasjonen og dens rolle I dette kapittelet går vi gjennom kravspesifikasjonen og hvilken rolle den hadde i prosjektarbeidet. 3.1 Første utkast Kravspesifikasjonen var svært nyttig sett i forhold til produktet vi ønsket å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet og forteller oss hva vi skal lage, og hvordan produktet prinsipielt skal fungere. Dette dokumentet ga alle parter et innsyn i hvordan oppdragsgiver og prosjektgruppen har utdypet oppgavebeskrivelsen, ved å definere hvilke krav som oppgaveløsningen skal oppfylle. Gjennom kravspesifikasjon fikk vi dekket alle ønskene og behovene oppdragsgiver hadde til dette prosjektet. Det første utkastet hadde kun generell informasjon om funksjonelle krav og sentrale oppgaver som applikasjonen skulle utføre: Lage fire ulike tilgangsnivåer for applikasjonen (PM, TL, TL+Admin, PK) Lage en fungerende applikasjon som de ansatte ved Amnesty kan ta i bruk for deres markedsavdeling. Lette arbeidet ved å slippe ekstra papirarbeid og får gjort de viktigste operasjonene over nett. Innlogging med eget brukernavn og passord. Se nyheter, kampanjer og rotasjonslister. Se statistikk av ulik data med tanke på rettigheter. E-post notifikasjon Applikasjonen skal utvikles slik at det enkelt kan vedlikeholdes senere. Grundig dokumentasjon og brukerveiledning skal ferdigstilles før innlevering. Utviklingsverktøy er følgende: HTML5, ASP.NET (C#), MS-SQL-Server 2012 Når vi hadde kommet i et stadiet i prosjektet hvor endringer i kravspesifikasjonen ikke kunne endres, låste vi fast dette og opplyste oppdragsgiver om dette. De var enige med våre spesifikasjoner og utredelser. 38

39 3.2 Bruk av kravspesifikasjon Vi har hatt bruk for kravspesifikasjonen under hele prosjektarbeidet. Uten denne, ville det vært umulig å kartlegge, strukturere og fordele arbeidet slik vi har gjort det. Kravspesifikasjonen har videre hjulpet i flere andre prosesser, blant annet mål, betingelser, krav og oversikt over arbeidet. Kravspesifikasjonen støttet våre sprinter, møtereferater og backlog også. Endringer og oppdateringer i kravspesifikasjonen førte til essensielle forbedringer og bedre oversiktige arbeidsplaner. Oppdragsgiver ble også informert hver gang det forekom endringer, og vi ville alltid få positive tilbakemeldinger fra dem. Enkelte ganger forekom endringer fra oppdragsgiveren, noe som kun har styrket arbeidsprosessen. 3.3 Endelig kravspesifikasjon Se vedlegg: Endelig Kravspesifikasjon 3.4 Samsvar med produktet Etter å ha sett sluttproduktet ser vi at det oppfyller kravene til den endelige kravspesifikasjonen vi satte. Alle krav og funksjoner ble implementert med unntak av utvidelser som vi allerede ved prosjekt-start var klar over, ville bli vanskelig å fullføre tidsnok. Dette er grunnen til at vi satte det som "mulige utvidelser" se vedlegg "" - "". Gruppen vår er svært fornøyd med det vi har fått til og hvordan applikasjonen ser ut. Amnesty har vært veldig positive til brukergrensensnittet og fornøyd med implementasjon av funksjonelle og ikke-funksjonelle krav. 39

40 4 Planlegging og metode Planlegningsfasen var veldig viktig for oss og hadde en avgjørende betydning i forhold til hvor lang tid vi skulle bruke på prosjektet. I denne delen vil vi legge fram hvilken verktøy, hvilke utviklingsmetodikker vi benyttet oss av. Videre vil vi utdype oss og gi et innblikk på hvordan vi har brukt de forskjellige verktøyene og hvordan teknologien ble knyttet sammen til prosessen. Til slutt vil vi gå nærmere inn på tegninger og mockups som ble laget altså bilder, fysisk og kommunikasjon både innad i gruppen og mellom gruppen, oppdragsgiveren og veilederen. 4.1 Tidlig prosjektfasen Etter at vi hadde bestemt prosjektoppgaven vår, var det første steget å planlegge utførelsen, utviklingsfasen, milepæler og fremdrifts- og arbeidsplan for oppgaven. Allerede i de første dagene hadde vi satt opp en fremdriftsplan. Slik så planen ut: Figur 20: Fremdriftsplan - Første utkast Fremdriftsplanen skal gi en oversikt over tidsfrister, kostnader og krav til leveranser/tiltak med eventuelle milepæler. Fremdriftsplanen må være realistisk, men likevel såpass ambisiøs at den gir en ønsket fremdrift for å utvikle strategien frem til implementering. Erfaringer viser at fremdriften ofte stopper opp når det ikke er nok ressurser knyttet til å nå viktige leveranser/milepæler. 40

41 Men etter hvert merket vi at denne planen ikke var konsistent nok. Den var greit for å overholde skole-frister som innlevering av forprosjekt-rapporter og andre forfallende leveranser, men ikke konkrete og bestemte nok for å dekke et omfattende prosjektarbeid som dette. Vi ville ha en ordentlig orden på hvilke arbeidsoppgaver som skulle gjøres når, samt hvilke dato det skulle vært klar til. Dette blir fremstilt i punkt 4.4 senere. Under utarbeiding av fremdriftsplan ble vi enige om å ha faste gruppemøter, to-tre ganger i uken. Fordi en stor del av utvikling ble utført på skolen i starten, pleide vi å utdele oppgaver og jobbe med dem sammen. Hvis ikke vi kunne møtes, ble det å utdele arbeidsoppgaver og jobbe hjemme. Skype-møter var normalt å ha hvor vi kunne analysere det som ble gjort, fikse på eventuelle feil, diskuterte videre arbeid og fordele oppgaver videre. Dermed gikk vi over til Sprinter, hvor vi som hjelpeverktøy hadde backlog. Vi formet dermed en fremdriftsplan som vi skulle følge og deretter skulle vår arbeidsplan være disse Sprintene. Da gjenstod det seg å bestemme utviklingsprossesen vår. 4.2 Valg av utviklingsprosess (UP) Uviklingsprosess beskriver hvilken faser prosjektet har gjennomgått utviklingen, hvilket valg vi har tatt for oppbyggingen og funksjonen i nettapplikasonen og hvilke utfordringer vi møtte. En utviklingsprosess skal føre til nye produkter/tjenester eller forbedre eksisterende. I vårt tilfelle: et nytt produkt. Som vi vet så er det mange typer prosessmodeller å velge mellom blant annet Scrum, fossefallmodell, XP og flere. Men valget av hvilken prosessmodell vi velger er avhengig av hva slags type prosjekt vi lager. Det er prosjektets størrelse og omfang som setter opp grunnlaget for valget av utviklingsmodellen. I vårt prosjekt Amnesty Norge trengte vi en iterativ modell som kan gi oss fleksibiliteten til å dele systemet til mindre systemdeler, ha en egen bruker-sider, egen admin side, begrense rettighetene til brukere, egen timelister, statistikk, printe side og slikt. Vi valgte: Scrum. 41

42 4.3 Scrum som UP Alle i gruppen hadde tidligere erfaring med denne metoden gjennom faget Systemutvikling. Fordelene med Scrum er blant annet at produktet er mer essensiell fremfor dokumentasjon og istedet for å følge en plan, er man observant på endringer som forekommer underveis. Disse fordelene virket svært tilegnet prosjektarbeidet vårt og vi iverksatte prosessen av å implementere dette fortløpende. Det er verdt å merke at Scrum ikke bare byr på positive innspill men også ulemper. Hvis oppdragsgiverne endrer planene sine underveis vil det føre til en god del ekstra arbeid, derfor er det viktig å komme overens med oppdragsgiver og følge strenge og faste arbeidsmål og dermed stadig forsikre at fremgangen følges konstruktivt og som planlagt mellom begge parter. Gruppen brukte tid på å anvende seg til denne metoden. Det var vanskelig å prioritere arbeidet og dele det opp i estimerte tidsrammer. For bruk av Scrum metoden måtte vi også ha et hjelpeverktøy, nemlig Sprinter. 4.4 Sprint som hjelpeverktøy Hjelpeverktøy Vi startet med å bruke Visual Studios nett-løsning via Team Foundation Server. Denne lot oss lage en produkt backlog. Her kunne vi legge til ulike sprinter i forskjellige tidsrammer, legge til ulike arbeidsoppgaver og fordele dem på gruppen. Vi kunne også ha styr på det som gjenstod, hvem hadde gjort hvilket arbeid og hvis en oppgave ikke ble utført til gitt sprintperiode, ble det flyttet til neste. Oppsettet var nytt, men spennende og svært nyttig. Dette fungerte gått som vår arbeidsplan for hele prosjektperioden og ga oss samtidig en iterativ modell for UP`en vår. På neste side ser vi den første arbeidsplanen gruppen laget tidlig i prosjektet: 42

43 Arbeid Beskrivelse av arbeid Tidsfrist Utført Prosjektstart Gruppen dannes Finne prosjekt Statusrapport Prosjektskisse Forprosjekt Styringsdokumenter Planlegging Database Utkast-modell Sette opp database Programmere/Design Gruppen skal dannes, prosjektet skal finnes samt skal en statusrapport og prosjektskisse være klar. Gruppen skal dannes til gitt dato. Prosjektoppgaven skal være klar til gitt dato. En utarbeidet statusrapport om gruppens status, medlemmene og samt info om bedriften og/eller valgt oppgave/ønsket oppgave. En utarbeidet prosjektskisse med ytterlig beskrivelse av bedrift og oppdragsgiver samt beskrivelse av oppgave. En utarbeidet forprosjektrapport med oversikt over mål, rammebetingelser, løsningsalternativer og analyse samt innsikt i dagens situasjon. En utarbeidet versjon av alle styringsdokumentene, altså prosjektskisse, prosjektdagbok, kravspesifikasjon og arbeidsog fremdriftsplan. Kontinuerlig planlegging av videreutvikling med hensyn til fremgang og arbeidssituasjon. En utarbeidet databaseløsning. Første utkast til databasen, enkel papir-tegning og forståelse i logikk. Ha satt opp databasen, med all nødvendig implementering og funksjonalitet. En utarbeidet og ferdigkodet produkt med tanke på

44 programmering og design. Utkast-modell (Design) Første utkast til webapplikasjonens design, enkel papir-tegning og/eller bruk av tegneprogrammer. Utføre testing Ha utført ulike tester for sikring av høy produktivkvalitet samt oppdage evt. feil eller endringer nødvendig. Brukertester Ha utført brukertester, altså testet brukeropplevelsen av produktet. Systemtester Ha utført systemtester, altså testet systemet for feil og/eller annet uventet. Slutt dokumentasjon Sluttføre alle dokumenter til levering, prosess- og produktdokumentasjon, testdokumentasjon samt brukerveiledninger. Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerveiledning Ferdigstille prosjekt Presentasjon En utarbeidet testdokumentasjon som omhandler alle utførte tester med resultater, evt. statistikker, feil og/eller andre beslutninger innen testfasen. En utarbeidet brukerveiledning som omhandler all nødvendig fremgang og forståelse av produktet som er nødvendig for brukeren. Alle innleveringskriterier skal ferdigstilles, sjekkes og klargjøres for levering. Klartgjort en muntlig presentasjon av produktet Første utkast av arbeidsplanen 44

45 Arbeidsplan er et styringsverktøy som er retningsgivende for studentene i prosjektet perioden, planen vil danne et grunnlag for forskjellige aktiviteter med en estimert tidsramme. Arbeidsplanen skal over tid sikre en jevn fordeling av gruppemedlemmene arbeidsplikt underveis. Her ser vi et eksemepel av Sprint-ordningen vi implenterte senere og endte med å bruke: Figur 21: Sprint-eksempel Backlog Etter at vi hadde bestemt oss for Sprint startet vi med å skrive en liste. Denne listen inneholdt alle arbeidsoppgavene, små, mellom-store og store. Når vi skulle legge ulike arbeidsoppgaver inn i sprintene var det via backloggen. Alle disse prioriteringene ble gjort av gruppen selv, ikke oppdragsgiver. Vi er førnøyde med ette valget siden vi oppfattet dette som den beste måten å spare tid og videre effektivisere arbeidet som skulle føre til et kvalitativt produkt. Møtene og gruppen Gruppen bestod av tre medlemmer. Gruppeleder hadde styringen og ansvaret for at alt gikk som planlagt og de ulike oppgavene ble utført på estimerte tidsrammer. Normalt skal alle ved arbeidet med Scrum, sitte med ulike arbeidsoppgaver og kun gjøre det. Siden vi var så få i gruppen følte vi at det var greit om alle hjalp hverandre og samtidig byttet på oppgaver gjennom tiden. 45

46 Ozaire Simen (Gruppeleder) Phi Hovedansvarlig Alt skriftlig arbeid fra Programmere Lage design + : møtereferater til slutt hovedsaklig designkode dokumentering samt nettapplikasjon og lage samt hjelpehånd hjelpehånd i designing database i database Fellesansvar: Koding av selve nettapplikasjonen. Delvis ansvar i dokumentasjonene (diagrammer osv). Utvikle og teste applikasjonen og kontroll sjekke alle koder og dokumenter. Presentasjon av produktet. Ansvarskart til gruppen Vi holdt også møter, hvor vi jobbet sammen i grupperommene. Vi hadde omtrent fire møter i uken hvor vi arbeidet i gjennomsnitt minst fire timer og opptil seks timer per dag. Etterhvert ble det kun to statusmøter og resten av tiden hadde vi kontakt via Skype/mobil/E-post. Ordningen vi har hatt med tanke på ansvar i gruppen og møtene vi avholdt er vi svært fornøyde med hvordan dette har utspant seg. 4.5 Vurdering av Sprintene Dette er noe gruppen valgte å gjøre for å summere og konkludere hva som gikk bra og hva som gikk galt. Dette vil være en stor læringsprosses som vil forsterke eller motbevise om bruken av sprinter var et godt valg for prosjektarbeidet eller ikke 46

47 Sprint 1 (11/02 til 20/02) Figur 22: Skjermbilde - Sprint 1 I Sprint 1 var gruppen svært ivrige å starte med autentisering, permisjoner og det å få klart design og databasen. Gjennom jevnlige møter på skolen, hadde vi god kontakt i denne periodn hvor arbeidsflyten og mengden var svært god. Vi hadde en "pang start" hvor vi allerede på slutten av februar hadde kommet et godt stykke fremover. Denne sprinten var svært effektiv og vellykket. Sprint 2 (25/02 til 11/03) Figur 23: Skjermbilde - Sprint 2 I Sprint 2 jobbet alle i gruppen stadig mer med design og kode generelt. Jobb og forsiden samt noen administrative verktøy ble utformet og kodet. Vi hadde satt opp en test server hvor vi stadig testet nettsiden og grunnleggende designet var ferdig til hele nettsiden på slutten av denne sprinten. Vi synes denne sprinten var på lik linje som sprint 1, på riktig spor og god vei. 47

48 Sprint 3 (11/03 til 25/03) Figur 24: Skjermbilde - Sprint 3 I Sprint 3 hadde vi bestemte oppgaver å utføre. Hovedsidens design og kode skulle endres og viktige endringer i registrering av statistikk. Annet forfallende arbeid og admin-panelet kom også som tilegg. Vi synes denne gangen at arbeidet ikke var helt på toppen, og at effektiviten var mindre i forhold til hvordan vi startet. På den andre siden hadde vi kommet halvveis frem til mål, men fortsatt gjenstod det mye. Sprint 4 (01/04 til 14/04) Figur 25: Skjermbilde - Sprint 4 I Sprint 4 jobbet gruppen over Skype og ellers kun få møter. Dokumentasjonsarbeid startet også i denne sprinten og vi hadde delt oppgaver mellom gruppemedlemmene jevnt. Dette var perioden viktige kode-relaterte arbeid ble utført. Alt i alt, en krevende sprint med utfordringer. 48

49 Sprint 5 (15/04 til 28/04) Figur 26: Skjermbilde - Sprint 5 I Sprint 5 realiserte gruppen at vi måtte jobbe mer enn forventet. Vi bestete å feilsøke hele systemet som snart var klar med unntak at vi måtte rette på bruker statistikk som var svrt essensiell for programmet. På slutten av denne sprinten hadde vi en første test versjon klar av hele produktet og samtidig kommet noen steg videre i dokumentasjonen. En god sprint. Sprint 6 (29/04 til 10/05) Figur 27: Skjermbilde - Sprint 6 I Sprint 6 skulle så og si alt fra og med dokumentasjon til og med selve produktet ferdigstilles. Gruppen hadde flere møter i denne siste sprinten hvor andre viktige ting som f. eks bruker tester ble utført. Etter å ha vurdert alle sprintene og sett tilbake på hver en av dem er vi fornøyde med innsatsen vår siden vi oppfylte de kravene og målene vi satte for prosjektet før det startet. 49

50 4.6 Arbeidsmetoder Gjennom disse tre årene har vi hatt flere gruppearbeid hvor vi har hatt mye erfaringer med hvordan et prosjektarbeid er satt opp hvilke arbeidsmåter kan følges. Men den tidligere erfaringen vi har hatt har vært mindre enn hovedprosjektet med tanke på omfang. I de andre prosjektene har vi hatt enklere arbeidesoppgaver, hvor vi leverte obligatoriske oppgaver og fikk tilbakemeldinger. Men her i hovedprosjektet er det mer krevende og større arbeidsmengder det er snakk om og samtidig avgjør man selv hvor mye tid man setter av til de enkelte oppgavene. Det er to metoder som blir brukt innenfor arbeidsmetoder, induktiv metode og deduktiv metode. Deduktiv metode er en arbeidsmetode der man prøver å oppnå samme suksess med f.eks design, nettside eller struktur som allerede tidligere har blitt laget, via en form av kopiering av det forige system. Derimot er induktiv metode en arbeidsmetode som går ut på å at man prøver å lære nye metoder og teknikker enn de man har lært. Arbeidsmetoden vår kan kalles en induktiv metode. Vi bygger de forskjellige komponentene for det meste helt fra "scratch", vi diskuterer med de andre i gruppen om det fungerer eller ikke og endrer på det til vi blir fornøyd eller dropper det. For utviklingen av et slikt system var induktiv metoden den beste måten siden alle i gruppen ville ta initiativet og gå fra det enkle til det generelle imotsetning til deduktiv der man går fra det generelle til det spesifikke. 4.7 Risikoplan Risikoplan er en absolutt nødvendighet, uansett om man driver med et større eller mindre prosjektarbeid. Man må alltid se etter risikoer som kan inntreffe den. Vi har laget en oversiktlig risikoplan hvor vi har prøvd å identifisere og vurdere de viktigste risikoene ved prosjektet vårt. Denne planen forteller hvor stor sannsynlighet det er for at en risiko inntreffer, hvordan man kan forebygge den og hvilket tiltak det finnes hvis noe oppstår. Den store risikoen vi merket var blant annet problemer med HiOA nettverket og grupperom. Noen dager var det umulig å finne rom og andre dager sviktet nettverket, som gjorde at det iblant ble mindre effektive dager på skolen. Risikoplanen vår har blitt justert og revidert flere ganger gjennom prosjektets omfang. For fullstendig risikoplan se vedlegg Risikoplan 50