NETTBUTIKK FOR HELSEPERSONELL

Størrelse: px
Begynne med side:

Download "NETTBUTIKK FOR HELSEPERSONELL"

Transkript

1 NETTBUTIKK FOR HELSEPERSONELL Hovedprosjekt ved Høgskolen i Oslo og Akershus Våren 2015 Hanna Tekie Roza Moustafa Camilla Kaasi

2 Denne siden er blank med hensikt. 1-2

3 PROSJEKT NR. 14 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET OFFENTLIG Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL DATO NETTBUTIKK FOR HELSEPERSONELL PROSJEKTDELTAKERE ANTALL SIDER / BILAG 100 INTERN VEILEDER ROZA MOUSTAFA CAMILLA KAASI HANNA TEKIE G. ANTHONY GIANNOUMIS OPPDRAGSGIVER KONTAKTPERSON DR. AKRAM ORG.NR.: MOHAMMED USMAN AKRAM TLF. NR.: SAMMENDRAG Nettbutikk hvor helsepersonell kan kjøpe artikler. 3 STIKKORD NETTBUTIKK HELSEPERSONELL.NET 1-3

4 Denne siden er blank med hensikt. 1-4

5 Forord Denne sluttrapporten er utarbeidet i forbindelse med hovedprosjektet ved Høgskolen i Oslo og Akershus våren Rapporten er utarbeidet av gruppemedlemmene Roza Moustafa, Hanna Tekie og Camilla Kaasi. Hovedprosjektet har basert seg på å utvikle en nettbutikk for helsepersonell, og ble tilbudt gruppen av oppdragsgiver Dr. Akram høsten Parallelt med utviklingen har vi utført en spørreundersøkelse for å kartlegge vaner hos helsepersonell i forbindelse med kjøp av medisinsk utstyr og uniformer på internett. Vi ønsker å takke alle som har medvirket i prosjektet. En spesiell takk rettes til veileder G. Anthony Giannoumis for hans støtte og ekspertise dette semesteret. I tillegg ønsker vi å takke Sindre Wigre for nyttige tilbakemeldinger på rapporten underveis. Sist men ikke minst ønsker vi å takke alle sykepleiestudentene ved høgskolen som tok seg tid til å besvare spørreundersøkelsen vi utførte i forbindelse med hovedprosjektet. Roza Moustafa Hanna Tekie Camilla Kaasi Oslo,

6 Denne siden er blank med hensikt. 1-6

7 Innholdsfortegnelse 1 Innledning Prosessrapport Spørreundersøkelsen Produktrapport Referanser Brukerveiledning Vedlegg

8 1 Innledning 1.1 Om gruppen Gruppen består av tre studenter ved Høgskolen i Oslo og Akershus som gjennomfører denne oppgaven som hovedprosjekt våren Vi ble kjent med hverandre gjennom første semester på høgskolen, og har samarbeidet ved flere anledninger i løpet av studieperioden. Ettersom vi kjente hverandre godt og tidligere samarbeid har fungert bra, var det naturlig å jobbe sammen på hovedprosjektet. Gruppen består av: Camilla Kaasi 25 år Student ved Ingeniørfag - data Fungerte som kontaktperson med intern veileder. Roza Moustafa 22 år Student ved Ingeniørfag - data Fungerte som Scrum-master og kontaktperson med oppdragsgiver. Hanna Tekie 24 år Student ved Ingeniørfag - data Fungerte som kontaktperson med prosjektansvarlig/faglærer. 1.2 Oppdragsgiver Oppdragsgiver er en lege som driver flere enkeltmannsforetak knyttet til profesjonen sin. Han jobber som turnuslege og er fra februar 2015 ansatt ved sykehuset i Telemark. Vi kom i kontakt med han ved å vise interesse for hans prosjektforslag Bestilling av vaksiner". Prosjektet handler om å oppgradere en utdatert informasjonsside for vaksinering til noe mer moderne og brukervennlig. Det viste seg at dette prosjektet var utdelt til noen andre, men han kunne tilby oss et annet prosjekt, Nettbutikk for helsepersonell. Oppgaven går ut på å utvikle en nettbutikk - med tilhørende administrerende verktøy - for salg av medisinsk utstyr og uniformer. 1-8

9 2 Prosessrapport 2.1 Innledning Organisering av arbeid Scrum Arbeidsflyten i Scrum Hvorfor Scrum Fremdriftsplan Risikoplan Utvikling av oppgaven Kravspesifikasjon Design Teknologi Back- end teknologi C#/ASP.NET Front end teknologi Arktitektur MVC Verktøy Visual Studio Git Trello Ansvar og samarbeid Arbeidsfordeling Møter og kommunikasjon Dokumentasjon Google Drive Scrum møter Dagbok Gjennomføringen av Scrum Scrum- møter Sprinter Hva vi ville gjort annerledes Kundehåndtering Forhold til oppdragsgiver Leveringer Ny teknologi Utfordringer med AngularJS

10 Utvikling av funksjonalitet Utfordringer Bruk av verktøy Kravspesifikasjonen og oppnåelse av mål Prioritert bort Mangler Fremgang Endringer i fremdriftsplan Avslutning Refleksjon Fremtiden

11 2.1 Innledning Vi var i dialog med vår oppdragsgiver fra og med oktober Alle i gruppen var godt kjent med oppgavebeskrivelsen da vi hadde vårt første møte i januar. Noen avgjørelser var tatt på forhånd - etter flere telefonsamtaler med oppdragsgiver: I oppgavebeskrivelsen foreslår vår oppdragsgiver en løsning med bruk av free template, med dette mente han en gratis programvare kalt Zen Cart 1 som har åpen kildekode tilpasset opprettelse og administrasjon av nettbutikker. Gruppen undersøkte hva Zen Cart var, samtidig som vi utpekte fordeler og ulemper ved å benytte nettbutikksystemet. Vi kom frem til at vi ville få mest læringsutbytte ved å utvikle nettbutikken fra bunnen av, ettersom Zen Cart ikke krever programmeringsferdigheter. Vi la frem dette til oppdragsgiver og han syns det var greit. Målet med dette var at oppgaven skulle bli mer tilpasset et bachelorprosjekt. 2.2 Organisering av arbeid Under forutsetning av at kvaliteten på produktet blir påvirket av både arbeidsmiljø og planlegging, bestemte vi oss for å bruke god tid på å sette oss inn i arbeidsmetoder - og benytte den tiden vi kan på planlegging. Ved semesterstart januar 2015 startet planleggingen for fullt. Noe av det første vi gjorde var å avtale møter med vår interne veileder og oppdragsgiver. Vi så på tidligere hovedprosjekter 2 løst av datastudenter ved Høgskolen i Oslo og Akershus, og ble inspirert av blant annet hvordan de estimerte tiden, løste oppgaven og skrev rapportene sine. 1 Zen Cart, 2 «Tidligere Prosjekter», Høgskolen i Oslo og Akershus, https://www.cs.hioa.no/data/bachelorprosjekt/tidligereprosjekter.php 2-11

12 2.3 Scrum Vi bestemte oss for å benytte Scrum 3 som rammeverk for organisering av arbeid i prosjektet. Etter å ha hatt emnet systemutvikling (DAFE2200, semester 3) fikk vi innblikk i ulike utviklingsmetoder, derav smidige prosesser som Scrum. Alle i gruppen visste altså hva Scrum innebar men ingen hadde brukt dette som utviklingsmetodikk før Arbeidsflyten i Scrum Scrum er en arbeidsmetode som fasiliterer samarbeid, kommunikasjon og framdrift mellom tre roller i et prosjekt: produkt-eier, Scrum-master og Scrum-team. Produkt-eier sitter med problemstillingen og er «stemmen» til brukergruppen. Scrum-master arrangerer daglige Scrum-møter og holder orden på arbeidsoppgaver. Et Scrum-team er utviklingsteamet. Planleggingen gjøres litt etter litt, og prosessen starter med at man har en visjon for produktet som skal utvikles. For å oppnå denne visjonen defineres et sett med arbeidsoppgaver, eller krav, som må gjennomføres. Utviklingen foregår gradvis med en serie iterasjoner 4, kalt sprinter i Scrum. Etter hver sprint leveres et inkrement 5 av produktet, og kunden kommer med tilbakemeldinger. Arbeidsoppgavene blir prioritert og estimert og lagt i en såkalt product backlog, det vil si en slags oppgaveliste med funksjonalitet som skal implementeres for en sprint av gangen. Under utviklingen holdes daglige Scrum-møter hvor hele teamet deltar og hver deltaker forteller om progresjon siden forrige møte, diskuterer problemer som har oppstått og hva de planlegger å utføre til neste dag. 3 «Prosessmodeller og smidig programvareutvikling», presentasjon fra Universitetet i Oslo, hentet , 4 Iterasjon - en syklus i utviklingen 5 Inkrement - et tillegg i funksjonaliteten som er implementert i et system 2-12

13 2.3.2 Hvorfor Scrum Det vi la vekt på da vi valgte Scrum var først og fremst at vi hadde en anelse om at rammeverket var mye brukt i IT-bransjen. Gjennom studiet har vi vært på flere bedriftspresentasjoner og fagdager, og vi har fått inntrykk av at Scrum er en populær metodikk i arbeidslivet. En annen viktig grunn til at vi valgte Scrum var for å optimalisere kundeverdien. Scrum innebærer at man hele tiden er i kontakt med kunden som gir tilbakemeldinger. Dette er verdifullt for å forbedre produktet, og samtidig levere et produkt som samsvarer forventningene til både kunden og brukerne. Dette gjør Scrum til en fleksibel modell. Vi mente også at gruppen ville ha større tilfredshet av å jobbe i et Scrum-team, hvor man jobber tett sammen, bør ha god kommunikasjon og hjelpe hverandre slik at man unngår flaskehalser og overlappende arbeidsinnsats. 2.4 Fremdriftsplan Vi satte av hele januar til planlegging. Utviklingen skulle starte i februar og pågå frem til april. Vi ble enige om å ferdigstille produktet den 23. april. For å tilpasse arbeidet i denne perioden for Scrum og definere antall sprinter, passet det å ha 5 sprinter; hver sprint på en 2 ukers tidsperiode. Resten av tiden frem til leveringsfristen 26.mai skulle brukes på å bearbeide og forbedre dokumentasjonen. Vi satte opp en arbeidsplan og en fremdriftsplan med milepæler. 2.5 Risikoplan Vi utformet også en risikoplan. Av erfaring fra andre prosjekter mener vi at det er nyttig å ha en risikoplan ettersom at ting kan gå galt, og da er det greit å vite hvordan man skal forholde seg hvis et problem skal oppstå - og forhindre at de oppstår. Risikohåndtering er spesielt viktig i ITprosjekter i tilfelle problemer med dårlig definerte krav og feil estimering av tid. En risikoplan inneholder forutsatt risiko et prosjekt kan komme over, sannsynlighet, konsekvens, tiltak for å forebygge og tiltak for å håndtere utfordringer dersom de bryter ut. Se Vedlegg 3 for hele risikoplanen. 2-13

14 2.6 Utvikling av oppgaven Etter at vi hadde satt oss inn i tidligere prosjekter, satt opp en hjemmeside for gruppen, valgt arbeidsmetode og skrevet noen prosjektdokumenter var vi klare for å definere oppgaven i mindre deler. 2.7 Kravspesifikasjon Oppgaveteksten inneholdt noen krav, men vi avtale med oppdragsgiver at han skulle sende oss en mail med utfyllende krav. Etter å ha fått denne mailen fra oppdragsgiver i midten av januar 2015, startet vi med å utarbeide kravspesifikasjonen - beskrivelse av hvilke brukerfunksjoner og generell ytelse et datamaskin - eller programsystem skal ha. Kravspesifikasjon utarbeides før en datamaskin anskaffes eller et programsystem utvikles, for å sikre at brukernes behov blir dekket når det gjelder funksjonalitet, ytelse og brukervennlighet. 6 Vi delte kravene inn i mindre punkter og skrev dem som brukerhistorier 7 - en eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av systemet. Disse skrives på formen: Som en rolle ønsker jeg funksjon for å oppnå verdi. Vi delte inn brukerhistoriene i funksjonelle (hva et system skal gjøre) og ikke-funksjonelle krav (systemegenskaper og rammer) og førte opp dette i kravspesifikasjonen (se Vedlegg 1 for kravspesifikasjonen). Denne har vi brukt aktivt gjennom hele prosjektperioden. 2.8 Design Et av de høyeste kravene til produktet oppdragsgiver stilte var fint design - utseende på nettbutikken. Det ble nevnt på vårt første møte at han ville se skjelettet til nettbutikken i den første fasen av prosjektet. Vi startet derfor å diskutere designet tidlig. Oppdragsgiver viste oss forskjellige nettbutikker for helsepersonell til inspirasjon. Legebutikken 8 var den første nettbutikken han presenterte for oss. Oppdragsgiver ville ha en tilsvarende nettbutikk, men med andre fargetoner. Han viste oss også Gymo 9 og Vaktrommet Liseter, Ivar M.. (2009, 14. februar). Kravspesifikasjon: IT. I Store norske leksikon. Hentet 10. mai 2015 fra https://snl.no/kravspesifikasjon%2fit 7 8 Legebutikken, 9 Gymo, 10 Vaktrommet, 2-14

15 Vi noterte oss linkene og ble kjent med nettbutikkenes oppbygging og design. Alle hadde mye til felles spesielt venstrestilt meny, søkefelt på toppen og en annonse med tilbud på forsiden. Vi ble enige om at vi skulle utvikle en nettbutikk som så mer moderne ut enn disse tre. Samtidig var det delte meninger om hvor mye vår nettbutikk skulle ligne på de som allerede eksisterer. For å få frem flere idéer skisserte hvert gruppemedlem et forslag som vi la frem for hverandre og diskuterte. Denne diskusjonen fikk frem hvor mye brukerne egentlig har å si for designet av en nettbutikk. Vi visste ingenting om brukergruppens handlemønster på nett: Når trenger de nye produkter? Hva foretrekker de at skal fremheves av produkter? Bryr de seg om reklame? Alle disse spørsmålene har noe å si for hvordan nettbutikken skal se ut til slutt. Derfor bestemte vi oss for å tilpasse nettbutikken så mye som mulig til brukergruppen. For at dette skulle skje, måtte vi bli bedre kjent med brukergruppen. Vi bestemte oss for at hvert gruppemedlem skulle snakke med bekjente leger og medisinstudenter - der vi tok opp en del punkter som var vanlig for dem når de handler på nett. Ved å ta utgangspunkt i dette, utviklet gruppen tre forskjellige designforslag. Se Vedlegg 5 for disse. Vi var ikke helt fornøyd med designforslagene, og følte ikke vi var klare for til å legge dem frem for oppdragiver. Vi ønsket å bruke mer tid på design, ettersom oppdragsgiver legger veldig stor vekt på dette. Vi innså at vi hadde behov for ytterligere informasjon om målgruppen, og ble enige om at en spørreundersøkelse ville gi oss god informasjon om hva de foretrekker. Vi bestemte oss for at utfallet skulle ha veldig mye å si for våre avgjørelser angående design. Se Spørreundersøkelsen for mer informasjon. 2.9 Teknologi Når det kommer til å utvikle en webapplikasjon, finnes det mange ulike språk, teknologier og rammeverk å velge mellom. Vår løsning er en todelt webapplikasjon som består av back-end og front-end. Back-end er en betegnelse brukt om server-siden av et program. Her skjer alt brukeren ikke ser. Back-end håndterer lagring, oppdatering og endring av data. 2-15

16 Front-end er en betegnelse brukt om klient-siden av et program. Dette er brukergrensesnittet - den delen av programmet brukeren kommuniserer med Back-end teknologi Vi vurderte både C# og Java ved valg av back-end teknologi. I løpet av studiet har vi fått kjennskap til begge programmeringsspråkene. Java har vi brukt mest, vi har hatt undervisning i programmeringsspråket som enkeltemnet Programmering (DAPE1400) og benyttet det i et tidligere prosjekt gjennom emnet Programutvikling (DATS1600). C# har vi erfaring med fra emnet Webapplikasjoner (ITPE3200, semester 5), i forbindelse med en webapplikasjon - der vi brukte C# på serversiden. C#/ASP.NET Vi bestemte oss for å utvikle ved hjelp av C#, ettersom det er en fordel at vi har anvendt C# på tilsvarende måte som vi kommer til å gjøre under dette prosjektet. Videre ønsket vi å ta i bruk.net-rammeverket, som er tett integrert med C# Front end teknologi «Front end-løsningen» består av en kombinasjon av HTML, Javascript og CSS (stilark for HTML). HTML, formateringsspråk benyttet for å lage hypertekst-dokumenter på World Wide Web. Koder, kalt tagger (eng. tags), angir funksjonen til en tekst, det vil si om den er en overskrift, et vanlig tekstavsnitt, en tabell, en punktliste eller en lenke til annen tekst. 11 Vi ønsket å utvikle en «Single Page Application» 12 - en applikasjon som laster en enkel HTMLside, som oppdateres dynamisk etter brukerens interaksjoner. Det finnes flere ulike Javascriptrammeverk man kan benytte seg av under utviklingen av en «Single Page Application». Disse inneholder forhåndsdefinerte metoder som bidrar til å avlaste kodingen på klient-siden. AngularJS 11 Liseter, Ivar M. & Rossen, Eirik. (2009, 24. mars). Html. I Store norske leksikon. Hentet fra https://snl.no/html 12 Mike Wasson, MSDN Magazine, Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET, https://msdn.microsoft.com/en-us/magazine/dn aspx 2-16

17 I emnet Webapplikasjoner (ITPE3200) fikk vi en grunnleggende introduksjon til AngularJS 13 helt på slutten av semesteret. AngularJS er et Javascript-rammeverk utviklet av Google for å løse de utfordringene som oppstår under utvikling av Single Page Application. Vårt inntrykk var at AngularJS er et nytt og spennende rammeverk, men vi hadde ikke nok pensum med det, og fikk dermed aldri ordentlig grep om rammeverket. Likevel - for å få mest mulig læringsutbytte - bestemte vi oss for å bruke AngularJS til utvikling av front end-delen. I tillegg har vi fått et inntrykk av at AngularJS er veldig relevant for arbeidslivet. Bootstrap 3 Vi bestemte oss også for å bruke Bootstrap 3 14 som er et front-end rammeverk bestående av HTML, CSS og Javascript. Bootstrap er utviklet av Twitter, og inneholder ferdig CSS kode man kan legge til i et prosjekt for å designe utseende av applikasjoner. Noen fordeler med Bootstrap er: - Man slipper å bruke for mye tid på grunnleggende ting under utformingen - Automatisk tilpasset visning på mobiltelefoner - Bra for senere vedlikehold - Gir en ryddig struktur i HTML-koden - Responsivt design Arktitektur Ettersom AngularJS er et MVC-basert rammeverk, og våre erfaringer med MVC-modellen har vært gode tidligere, besluttet vi å bygge opp prosjektet etter denne modellen. AngularJS bruker en variasjon av MVC og MVVM. 13 Wikipedia contributors, "AngularJS," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015) 14 Chris-Håvard Berge, CHB Studios, Tre nettressurser til webutvikling, besøkt , 15 Responsiv design - kan vises på alle skjermstørrelser 2-17

18 MVC MVC 16 er et designmønster for utvikling av webapplikasjoner. Arkitekturen skiller mellom modell og brukergrensesnitt, og kan kort oppsummeres slik: Model - holder på data View - viser frem data Controller - flytter på data MVC er populært fordi den reduserer kompleksiteten i arkitekturen, øker fleksibilitet og sørger for enklere vedlikehold i koden. MVVM En nyere variant av MVC er MVVM 17 mønster. Denne består av: Model - holder på data ViewModel - en abstrakt representasjon av View View - viser, og sender data til, ViewModel 2.11 Verktøy Ettersom oppdragsgiver ikke satte noen krav til hvordan vi skal utvikle nettbutikken - i forbindelse med valg av verktøy og teknologi - er mange av valgene vi har tatt basert på hva vi lærte var best praksis gjennom studiet. De fleste verktøyene vi har tatt i bruk, har vi enten fått høre om i forelesninger eller gjennom bedriftspresentasjoner. I denne delen er en kort oversikt over hvilke verktøy som har blitt brukt. 16 Tutorials Point, AngularJS MVC Architecture, 17 Mike Wasson, MSDN Magazine, Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET, https://msdn.microsoft.com/en-us/magazine/dn aspx 2-18

19 Visual Studio Visual Studio 18 er et integrert utviklingsmiljø levert av Microsoft. Utviklingsmiljøet brukes ofte for å utvikle programmer for Windows, men er også ofte brukt for å utvikle websider og webapplikasjoner. Alle på gruppen hadde erfaring med Visual Studio fra tidligere. Siden Visual Studio er levert av Microsoft, og en del av.net rammeverket, passer det godt til teknologien vi har valgt Git For håndtering av versjonskontroll tok vi i bruk noe vi kjenner fra før - Git. NTNU 19 beskriver tjenesten slik: Git er et verktøy for versjonskontroll og kodedeling. Det vil blant annet si at du kan lagre hele historikken til hvordan kode har utviklet seg, og gå tilbake til et hvilket som helst punkt Trello Vi ble kjent med Trello 20 da vi hadde en gjeste-foreleser fra Bekk i emnet Webapplikasjoner (ITPE3200). Han presenterte et Scrum-prosjekt der teamet brukte Trello. Etter dette undersøkte vi hvordan tjenesten fungerte og kom frem til at det ville være et nyttig verktøy for prosjektstyring. Trello er et web-basert prosjektstyringsverktøy levert av Fog Creek Software. I Trello er prosjekter representert som ulike brett, som inneholder forskjellige lister. Listene inneholder kort som kan flyttes mellom dem. 21 I vårt prosjekt inneholdt hvert kort en brukerhistorie fra «product backlogen» som ble tilknyttet eierskap. Oppgavene er sortert og ordnet i den rekkefølgen vi forventer å utvikle dem, og flyttet gjennom listene Må gjøres, Pågående, Under Testing og Ferdig. 18 Wikipedia contributors, "Microsoft Visual Studio," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 19 «Git versjonskontroll», NTNU, https://www.ntnu.no/wiki/display/plab/git+-+versjonskontroll 20 Trello, https://trello.com 21 Wikipedia contributors, "Trello," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 2-19

20 2.12 Ansvar og samarbeid Ettersom gruppen har samarbeidet tidligere, visste vi at fordeling av oppgaver er nøkkelen til et godt samarbeid. Vi hadde den fordelen at vi kjente til gruppemedlemmenes sterke og svake sider, noe som gjorde det enklere å fordele oppgaver - både slik at alle løser noe de mestrer og utfordres Arbeidsfordeling Når det gjelder utviklingen av nettbutikken, jobbet alle medlemmene med back-end, front-end, design og dokumentasjon. Vi ønsket at alle skulle få mest mulig læringsutbytte, og delte ikke ansvar slik at én satt med back-end; det hadde resultert i at dette medlemmet hadde blitt veldig god i C# men ikke mestret front-end teknologien AngularJS i like stor grad. Vi forsøkte å dele brukerhistoriene likt mellom oss. Brukerhistoriene er likevel så forskjellige og krever ulike ferdigheter, at vi ofte har hjulpet hverandre og byttet på oppgavene. Dette har ført til at vi har delt mye kunnskap - og praktisert tettere samarbeid enn om vi hadde jobbet mer individuelt Møter og kommunikasjon Vi hadde flere møter med både intern veileder og oppdragsgiver. I tillegg ble det utvekslet mail kontinuerlig. Vi bestemte at de kun skulle forholde seg til en kontaktperson fra gruppen for utveksling av mail, og eventuelle telefonsamtaler. Gruppen har hatt jevnlig kontakt med veileder gjennom hele prosjektperioden. Under disse møtene fikk vi veiledning om hvordan vi skal lage spørreundersøkelse og analysere resultatet, og hvor viktig det er å behandle kunder riktig. Gruppen er veldig fornøyd med å ha han som veileder. Grunnet en travel tidsplan hos oppdragsgiver har vi ikke hatt så mange møter med han som vi hadde planlagt. For det meste holdt vi kontakten via e-post. Hittil har vi hatt møte med han to ganger i planleggingsfasen og en gang under utviklingen av produktet. 2-20

21 2.14 Dokumentasjon Google Drive Vi brukte Google Drive 22 som verktøy for å holde orden på alle filene vi har hatt gjennom prosjektet. Google Drive er en fillagrings- og synkroniseringstjeneste utviklet av Google. Tjenesten tillater brukere å lagre alle slags filer på en 15 GB gratis lagringsplass - som kan deles med andre brukere. Google Drive gir god støtte for samarbeid. Alle på gruppen kunne opprette, se, redigere og kommentere dokumenter. Hver dokument har også en tilhørende logg over alle endringer slik at man hele tiden har en oversikt over hvem som har endret hva og når. Vi lagret alle salgs dokumenter knyttet til prosjektet i Google Drive, men også for eksempel back-up filer og nyttige videoer Scrum møter Vi utnevnte et gruppemedlem til å fungere som Scrum-master gjennom prosjektperioden. Gruppen opprettet en mal som Scrum-master benyttet etter hvert møte for å skrive et kort referat. Disse referatene ble brukt som en slags logg over hva som var gjort og hvilke problemer vi støtte på underveis Dagbok Gjennom prosjektperioden har vi skrevet dagbokinnlegg på gruppesiden vår. Denne inneholder punkter fra møtene med veileder og oppdragsgiver, samt alle avgjørelser vi har tatt som ikke har noe med koding å gjøre - samt ting som ikke kommer frem ved Scrum-møter. 22 Wikipedia contributors, "Google Drive," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 2-21

22 2.15 Gjennomføringen av Scrum Tiden vi hadde satt av for utvikling i fremdriftsplanen var fem sprinter; hver sprint på en to-ukers tidsperiode. Disse sprintene startet med at vi plukket ut de høyst prioriterte brukerhistoriene fra kravspesifikasjonen, og fordelte de på gruppemedlemmene. Arbeid tilknyttet brukerhistoriene ble tidsestimert og lagt i product backlog. Ved estimering benyttet vi oss av planning poker som vi også ble kjent med gjennom emnet systemutvikling (DAFE2200, semester 3). Planning poker fungerer slik at hvert gruppemedlem har en kortstokk med tall som representerer estimater. Alle velger det estimatet de mener oppgaven trenger, og snur kortene på bordet for å avsløre svaret. Dersom det er noen store avvik skal valget begrunnes og gruppen estimerer på nytt. Vi brukte PlanningPoker, en applikasjon som kan lastes ned fra App Store Scrum-møter Hver dag møttes gruppen til et daglig Scrum-møte der hvert medlem svarte på følgende spørsmål: 1) Hva har du gjort siden i går? 2) Hva skal du gjøre i løpet av dagen? 3) Har det oppstått noen problemer eller hindringer? Disse møtene skulle være korte; hensikten er å få en kjapp oversikt og motivasjon på starten av dagen. Vi planla å bruke rundt minutter på hvert møte, men de ble ofte mer tidkrevende enn forventet. Grunnen til dette var at vi gjorde referat av alle møtene, og at vi tok opp diskusjoner og andre problemstillinger i løpet tiden også. Scrum-møtene ble vanligvis holdt, men en gang i blant kunne gruppen sitte hver for seg og jobbe, og da ble det litt mer utfordrende å få til disse møtene Sprinter Vi forsøkte å følge sprintene og gjøre alt som måtte implementeres innenfor hver sprint så langt det strakk til. 2-22

23 Utfordringer med sprinter Vår største utfordring under sprintene var å fullføre alle oppgavene i product backlog. Dette skyldtes oftest at det dukket opp problemer som stoppet fremgang i utviklingen. Vi opplevde også ved enkelttilfeller at vår estimering ikke stemte overens med tiden vi faktisk brukte på en brukerhistorie. I starten av utviklingsperioden fokuserte vi på å løse problemene når de dukket opp, og dette ble en slags flaskehals for enkeltpersoner; man ble sittende over tid med underordnede problemer, noe som hindret framgang i arbeidet. En annen utfordring med sprinter vi ikke var forberedt på, var at strukturen kunne bli verre etterhvert som funksjonalitet ble lagt til. Vi måtte derfor også bruke tid på å restrukturere systemet underveis i utviklingen Hva vi ville gjort annerledes Vi skulle gjerne omdefinert brukerhistoriene i product backlog, slik at den heller hadde bestått av en liste med arbeidsoppgaver som beskriver hva som må implementeres for å lage produktet basert på brukerhistorien, heller enn en beskrivelse av selve brukerhistorien. På den måten ville arbeidet med å utarbeide hvilke funksjonaliteter hver brukerhistorie etterlyser, og dessuten hvordan det skulle løses teknisk flyttes frem i tid og bli en del av planleggingen. Dette hadde gitt en mye bedre oversikt over hva som skulle gjøres, ettersom vi synes brukerhistoriene ofte var for vage og inneholdt for mye funksjonalitet som måtte implementeres. Basert på erfaringer gjennom utviklingen, tror vi at vi kunne satt av kortere sprinter med en tidsperiode på for eksempel en uke. Da kunne vi fordelt færre arbeidsoppgaver i hver sprint, og det ville vært enklere å se hvordan vi ligger an. Det hadde også vært en idé å rangere arbeidsoppgavene fra lett til vanskelig. Det tar vanligvis litt tid før en får forståelse og grep på teknikken og logikken bak et språk. Starter man med å kode funksjonalitet som ikke er så utfordrende i starten, vender man seg til språket man skriver i - dette kan hjelpe veldig når man nærmer seg de vanskelige oppgavene. 2-23

24 Å starte med store og utfordrende funksjonaliteter for å få på plass de grunnleggende delene med en gang, var som sagt med på å skape flaskehalser i vårt prosjekt. Men etterhvert i prosjektet satte vi store problemene litt på vent før vi senere tok tak i dem igjen, og løste de senere. Dette tror vi skyldes at vi i mellomtiden fikk enda mer grep på logikken Kundehåndtering Kundehåndtering er noe intern veileder oppfordret oss til å ta veldig seriøst. I de fleste bransjer så vel som IT-bransjen er det fornøyde kunder som gir bra omdømme. Ettersom Scrum gir god mulighet for å inkludere og samarbeide var planen å vektlegge dette for å skape et så godt forhold til oppdragsgiver som mulig Forhold til oppdragsgiver Helt fra starten var forholdet til oppdragsgiver veldig bra. Praten gikk godt for seg. Vi passet på å være høflige både på møter og e-post. Oppdragsgiver kom med forslag og innspill så vel som vi også presenterte idéer og løsningsmetoder. I tillegg fikk han hele tiden oppfølging på e-post angående hva vi hadde pratet om, og hva vi lurte på videre Leveringer Gruppen hadde to store møter med oppdragsgiver før utviklingen, og planen videre etter det var å møte oppdragsgiver for å levere inkrement etter hver sprint. Oppdragsgiver informerte om at disse møtene kunne bare holdes i helgene - ettersom han er turnuslege og gjennomfører turnustjenester i andre byer på arbeidsdagene. Vi syns dette var greit og prøvde å være så fleksible som mulig. Arbeidsplanen til oppdragsgiver forandret seg gjennom prosjektperioden, og det ble mer og mer utfordrende med leveringer. Til slutt fikk vi kun levert ett inkrement etter den første sprinten, og dette var gjennom et Skypemøte. Oppdragsgiver var lite tilgjengelig resten av prosjektperioden, og vi prøvde å respektere hans hektiske timeplan og forholdt oss til å sende e-post. Dette gjorde at det ble mindre tilbakemeldinger fra legen enn det vi forventet, men vi fikk veldig positive tilbakemeldinger etter første levering, noe som var betryggende for resten av utviklingen. 2-24

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

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

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

1 Del I: Presentasjon

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

Detaljer

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

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

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

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

Del VII: Kravspesifikasjon

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

Detaljer

FORPROSJEKT 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

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

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

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

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

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

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

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

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

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

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

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

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

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

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

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

Detaljer

Testrapport 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

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

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

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

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

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

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010 1 0 Prosjekt 7.Januar, 2010 til fordypning Eva-Anita Thorsen 2MKA Halvårs-rapport 0.1 innhold 2 INFO SIDE Innhold 2 Innledning 3 Hoveddel 4-8 Avslutning 9 Logg 10-12 Bakside 13 0.2 innledning 3 Innledning

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

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

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

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

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

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

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

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

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

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

KRAVSPESIFIKASJON FORORD

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

Detaljer

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

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

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

4.5 Kravspesifikasjon

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

Detaljer

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

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

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

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

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

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

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

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

Detaljer

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

DRAFT. Martin Lyckander

DRAFT. Martin Lyckander Kravspesifikasjon Target release 1.0 Epic Document status Document owner DRAFT Martin Lyckander Designer Developers QA Forord Hensikten med en kravspesifikasjon er at den skal fungere som et styringsdokument

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

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

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

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

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

SLUTTRAPPORT. Glenn Bjørlo. Bedriftspraksis. Høgskolen i Østfold. Halden

SLUTTRAPPORT. Glenn Bjørlo. Bedriftspraksis. Høgskolen i Østfold. Halden SLUTTRAPPORT Glenn Bjørlo Bedriftspraksis Høgskolen i Østfold Halden 01.12.2014 INNHOLD Overskrift Sidetall Introduksjon 3 Beskrivelse 4 Refleksjon 6 Vedlegg 1: Timebruk 9 Vedlegg 2: Attest 12 Introduksjon

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

Studentweb3. Kathy Haugen 15. april 2015

Studentweb3. Kathy Haugen 15. april 2015 Studentweb3 Kathy Haugen 15. april 2015 Hva er Studentweb? Studentweb er en webapplikasjon for studenter. StudentWeb lar studentene få tilgang til sine studiedata, utføre studieadministrative rutiner og

Detaljer

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand Web fundamentals Webdesign 17. januar 2008 Monica Strand Webdesign 17. januar 2008 1 Web design Fagområdet Web design inneholder flere disipliner Grafisk design Informasjonsdesign Brukergrensesnittdesign

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

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

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

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

Administrasjon av saker. - Redigere saker med standard mal

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

Detaljer

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING 23. JANUAR 2015 FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING Innholdsfortegnelse Presentasjon... 2 Sammendrag... 2 Dagens situasjon... 2 Mål og rammebetingelser... 2 Mål...

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. Gruppe 34. Magnus Dahl Hegge s153549

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

Detaljer

Kjørehjelperen Testdokumentasjon

Kjørehjelperen Testdokumentasjon 2013 Kjørehjelperen Testdokumentasjon Høgskolen i Oslo og Akershus Henrik Hermansen og Lars Smeby Gruppe 8 26.05.2013 Forord Dette dokumentet tar for seg to forskjellige ting. Først forklares det hvordan

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

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

Installere JBuilder Foundation i Mandrake Linux 10.0

Installere JBuilder Foundation i Mandrake Linux 10.0 Installere JBuilder Foundation i Mandrake Linux 10.0 Installasjon av JBuilder Foundation på Linux (dekker her spesifikt fremgangen ved bruk av Mandrake Linux 10.0, men distribusjon vil gjøre liten eller

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

3. Prosessrapport. Forord

3. Prosessrapport. Forord 3. Prosessrapport Forord Prosessrapporten er utarbeidet i forbindelse med hovedprosjekt våren 2015 ved Høgskolen i Oslo og Akershus. I denne rapporten vil vi beskrive prosessen bak utviklingen av publiserings-

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

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

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

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

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

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

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

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

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

Produktinformasjon WIPS publiseringsløsning

Produktinformasjon WIPS publiseringsløsning Enkel og effektiv publisering på på nett! Produktinformasjon WIPS publiseringsløsning WIPS publiseringsløsninger - Oversikt WIPS Start Standard PRO PRO med intranett Fleksibel forside * * * * 1 stk designmal

Detaljer

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

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

Detaljer

Mobil rapportering for Android og ios PROSESSRAPPORT. Deviations and Reporting

Mobil rapportering for Android og ios PROSESSRAPPORT. Deviations and Reporting Mobil rapportering for Android og ios PROSESSRAPPORT Deviations and Reporting FORORD Vi ønsker å takke vår veileder Simen Hasselknippe for veldig god veiledning gjennom hele prosjektet, resultatet hadde

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

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) Prosjektdagbok Dagbok

Detaljer

2. Beskrivelse av mulige prosjektoppgaver

2. Beskrivelse av mulige prosjektoppgaver Avanserte databaser (øving 9, 10, 11 & 12) Tore Mallaug 25.01.2008 Opphavsrett:Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO326D Avanserte Databaser INNLEVERINGSFRISTER (Obligatorisk

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

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer