HOVEDPROSJEKT. Telefon: Telefaks:

Størrelse: px
Begynne med side:

Download "HOVEDPROSJEKT. Telefon: 22 45 32 00 Telefaks: 22 45 32 05"

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

Forprosjekt - Gruppe 12. Hovedprosjekt av

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

Detaljer

Dokument 1 - Sammendrag

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

Detaljer

Kravspesifikasjon. Forord

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

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

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

Detaljer

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

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

Detaljer

PROSESSDOKUMENTASJON

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

Detaljer

Dokument 3 - Prosessdokumentasjon

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

Detaljer

Del IV: Prosessdokumentasjon

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

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

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Bachelorprosjekt 2015

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

Detaljer

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

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

Detaljer

Produktrapport Gruppe 9

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

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

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

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen

Detaljer

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

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

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

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

Detaljer

Del VII: Kravspesifikasjon

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

Detaljer

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

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

Detaljer

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

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

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

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

Detaljer

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

Detaljer

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

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

Detaljer

PROSESSDOKUMENTASJON

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

Detaljer

[GILJE SELSKAPSLOKALER]

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

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

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

Detaljer

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

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

Detaljer

[GILJE SELSKAPSLOKALER]

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

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

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

Detaljer

1. Forord 2. Leserveiledning

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

Detaljer

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

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

Detaljer

Høgskolen i Oslo og Akershus

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Vedlegg Side 83 av 155

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

Detaljer

Båtforening på nett. Produktrapport

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

Detaljer

Styringsdokumenter. Forord

Styringsdokumenter. Forord 8 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble

Detaljer

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

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

Detaljer

Forprosjektrapport MetaView

Forprosjektrapport MetaView Forprosjektrapport MetaView BACHELOROPPGAVE VÅREN 2014 Presentasjon Tittel: MetaView Oppgave: Utvikle en Windows 8 applikasjon som skal forenkle en liten del av MetaVision. Et verktøy for sykehus, leger

Detaljer

Forprosjekt gruppe 13

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

Detaljer

Testrapport. Studentevalueringssystem

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

Detaljer

Kravspesifikasjon Innholdsfortegnelse

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

Detaljer

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

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

Detaljer

Kandidat nr. 1, 2 og 3

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

Detaljer

Gruppe 33 - Hovedprosjekt

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

Detaljer

Brukermanual. Studentevalueringssystem

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

Detaljer

Entobutikk 2.PRODUKTRAPPORT VÅR 2011

Entobutikk 2.PRODUKTRAPPORT VÅR 2011 2.PRODUKTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1 ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days

Detaljer

Presentasjon. Kristian Hewlett- Packard 29.05.2012

Presentasjon. Kristian Hewlett- Packard 29.05.2012 2012 Presentasjon Kristian Hewlett- Packard 29.05.2012 1 Innledning Denne innledningen inneholder informasjon om gruppen, samt bakgrunn og mål for oppgaven og en introduksjon til temaet. 1.1 Gruppen Vår

Detaljer

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

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

Detaljer

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic Kravspesifikasjon 1 Prosjektfakta Prosjekttittel: Medlemsregister for YXD-Kurdistan Prosjektnummer: 07 09 Gruppemedlemmer: Oppdragsgiver: Kontaktperson: Intern veileder: Asad Fattahi Ernad Fajkovic YXD-Kurdistan

Detaljer

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

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

Detaljer

Produktdokumentasjon

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

Detaljer

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Håkon Bogsrud Anders Høye Karlsen Alexander Borgen Saxevik Bacheloroppgave vår 2012 IT-støttet bedriftsutvikling Oppgavenummer:

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

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

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

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

Detaljer

Testrapport for Sir Jerky Leap

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

Detaljer

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008 IT-infrastruktur Kravspesifikasjon Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 2 PROSJEKT NR. 08-08

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Pedagogisk regnskapssystem

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

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

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

Detaljer

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Produktrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Produktrapport 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 1 2 Produktdokumentasjon... 2 3 Beskrivelse av mobilapplikasjonen...

Detaljer

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

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg

Detaljer

Prosjektdagbok Gruppe 18

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Skøyen, 23.01.14 Gruppe 11

Skøyen, 23.01.14 Gruppe 11 Forprosjektrapport Produktkvalitet, visitnorway.com Sammendrag Vi skal gjennomføre et produktkvalitetsprosjekt hos Creuna i forbindelse med visitnorway.com, Innovasjon Norges turistinformasjonsside. Prosjektet

Detaljer

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

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

Detaljer

Kravspesifikasjon. Forord

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

Detaljer

Vedlegg LMC intranett

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

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

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

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

Detaljer

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

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

Detaljer

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

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

Detaljer

Mobile apps for Android and ios platforms Forprosjekt

Mobile apps for Android and ios platforms Forprosjekt Mobile apps for Android and ios platforms Forprosjekt Presentasjon : Hovedprosjekt gruppe 17 Høgskolen i Oslo og Akershus Deltakere : Anders Nordli Knudsen Maha Sami Laham Kedar Nassir Shyto Hussain Salbi

Detaljer

Forprosjektrapport gruppe 3

Forprosjektrapport gruppe 3 Forprosjektrapport gruppe 3 Presentasjon: Tittel: NILS Mobil Oppgave: Utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

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

Detaljer