Dokument 3 - Prosessdokumentasjon

Størrelse: px
Begynne med side:

Download "Dokument 3 - Prosessdokumentasjon"

Transkript

1 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

2 Innholdsfortegnelse Prosessdokumentasjon 1 1. Prosjektgruppen Gruppesammensetning Arbeidsforhold Kommunikasjon Arbeidsfordeling 2 2. Planlegging og metodikk Dokumentasjon Versjonskontroll Backup-løsning Prosjekthjemmeside Prosjektdagbok Risikoplan Arbeids- og fremdriftsplan Utviklingsmetode 4 3. Utviklingsprosessen Gjennomgående aktiviteter Idéfasen Forprosjektfasen Utførelsesfasen Testfasen 6 Dokument 3 - Prosessdokumentasjon

3 3.6 Avslutningsfasen Diskusjon rundt utviklingsprosess 6 4. Vurdering av teknisk arkitektur 7 5. Vurdering av brukergrensesnitt 7 6. Vurdering av kravspesifikasjon 8 7. Vurdering av testing 8 8. Avslutning Produktet Læringsutbytte Konklusjon 10 Dokument 3 - Prosessdokumentasjon

4 Prosessdokumentasjon Målet med prosessdokumentasjonen er å gi et innblikk i prosessen rundt utviklingen av «Automatnett» for Uno-X Automat AS. Dokumentet skal forklare og begrunne prosessen fra idé til utviklet produkt. Her inngår vurderinger om valg vi har foretatt underveis, tanker om styrker og svakheter i løsningen, og en helhetlig vurdering av løsningen og gjennomføringen av prosjektet. 1. Prosjektgruppen 1.1 Gruppesammensetning Gruppen i denne prosjektoppgaven består av 4 studenter fra linjen Anvendt Datateknologi ved HiOA. Gruppen har samarbeidet på andre prosjekter tidligere i studiet og samarbeidet har ført til gode faglige resultater. Blant annet vant vi konkurransen for mest originale ide- og posterdesign i faget Universell Utforming, I tillegg til gode faglige resultater føler medlemmene i gruppen at vi har oppnådd god kommunikasjon og et samspill der alle bidrar. Dette spilte en avgjørende rolle i avgjørelsen om å gjennomføre prosjektoppgaven sammen. 1.2 Arbeidsforhold Uno-X Automat stilte et grupperom til disposisjon slik at vi hadde et sted å arbeide gjennom prosjektets gang. Gruppen ble enige om å ha tirsdag, torsdag, og fredag som faste dager hvor vi møttes hos oppdragsgiver. Disse dagene ble primært brukt til fordeling av arbeidsoppgaver, planlegging og diskusjoner i tillegg til at hver av oss jobbet med individuelle arbeidsoppgaver. Gruppen var fornøyd med denne fordelingen ettersom det gav oss en mulighet for å hjelpe hverandre med problemer en ikke klarte å løse på egenhånd. I tillegg åpnet det en mulighet for å la to medlemmer samarbeide om å programmere på samme modul eller skrive dokumentasjon i fellesskap. Det var viktig for oss å få innarbeidet faste rutiner ettersom det kunne forenkle organiseringen av arbeidsoppgaver og effektivisere gjennomføringen av disse innenfor normal tid. Ved å ha en fast arbeidsplass og faste dager hvor vi jobbet sammen kunne vi skape en rutine for prosjektarbeidet som alle forholdt seg til. 1.3 Kommunikasjon Når vi ikke har vært samlet har kommunikasjon internt i gruppen foregått hovedsaklig på epost, men også prosjektdagboken har blitt benyttet til å videreformidle informasjon. Dokument 3 - Prosessdokumentasjon 1

5 Kommunikasjon med oppdragsgiver har foregått via epost, men også i stor grad muntlig ettersom vi var tilstede på bedriften flere ganger i uken. Gjennom forprosjektfasen hadde vi møter med oppdragsgiver hvor vi diskuterte utformingen av løsningen, hvilken funksjonalitet de ønsket og prioriteringen disse skulle ha i utviklingsfasen. Det var viktig for oss å få klare tilbakemeldinger fra oppdragsgiver på ulike avgjørelser i forprosjektet, slik at det ikke oppsto misforståelser som førte til forsinkelser i utviklingsfasen. Vi opplevde at oppdragsgiver var aktiv gjennom prosjektperioden med tilbakemeldinger og forslag til endringer. Innad i gruppen var det åpen kommunikasjon gjennom hele prosjektet. I forprosjektet hadde vi ofte diskusjon om avgjørelser tilknyttet funksjonalitet og utforming av løsningen. Gjennom tidligere prosjektarbeid har vi blitt vant til å innhente synspunkter fra hverandre og er vant med å alltid kunne få respons og tilbakemeldinger på individuelt arbeid. Vi opplevde at det spesielt under programmeringen var viktig med tilbakemeldinger på måten funksjonaliteten ble utviklet. Alle hadde sine synspunkter på hvordan noe skulle se ut eller fungere i løsningen, og diskusjon og refleksjon var viktige virkemidler for å komme frem til et godt resultat. 1.4 Arbeidsfordeling Gruppeleder hadde ansvaret med å fordele arbeidsoppgaver til gruppens medlemmer og sørge for at alle hadde noe å jobbe med til en hver tid. Vi begynte hver uke med en felles gjennomgang av hvordan vi lå an med de individuelle arbeidsoppgavene, og hvilke arbeidsoppgaver som gjensto innenfor den aktuelle sprinten. For å sørge for at frister ble overholdt i henhold til arbeidsplanen var gruppeleder flink til å påminne om dette over epost, i tillegg til å informere muntlig. 2. Planlegging og metodikk 2.1 Dokumentasjon Arbeidet med å skrive dokumentasjon ble fordelt innad i gruppen, der hver person fikk ansvaret for å skrive og holde sitt ansvarsområde oppdatert underveis i prosjektet. Vi organiserte dokumentasjonen gjennom en felles mappe i Dropbox, som alle medlemmene av gruppen hadde tilgang til. Vi har fra tidligere prosjekter erfart hvor nyttig Dropbox kan være fordi det sørger for at alle medlemmer alltid har tilgang til den nyeste versjonen av et dokument. Gruppen har gjennom prosjektet fått erfare hvor viktig dokumentasjon er for hele prosessen. Prosjektets omfang har medført at vi flere ganger har måttet gå gjennom dokumentasjonen for å finne igjen ulike detaljer vi ikke klarte å huske. Vi har også erfart at dokumentasjon er mer tidkrevende enn det vi først antok. Spesielt sluttdokumentasjonen har vært en tidkrevende prosess, og vi skulle ønske at vi hadde beregnet mer tid til dette da vi planla prosjektet. Dokument 3 - Prosessdokumentasjon 2

6 2.2 Versjonskontroll Versjonskontroll ble benyttet til å holde orden på endringer som ble foretatt i produktets kildekode. Gruppen valgte å bruke SVN-tjenesten Assembla som sentralt lagringssted for Subversion repository. SVN-klienten Versions ble brukt til å håndtere hvert av gruppemedlemmenes lokale arbeidskopi. Programmet oppdaterte alle endringer foretatt på en gruppemedlemmenes lokale kopier, opp mot versjonen som lå lagret eksternt på Assembla. Vi syntes Versions var intuitivt og det gikk greit for alle i gruppen å lære seg å bruke programmet. Det ble opprettet en rutine for oppdatering av hovedkopien der ingen skulle legge til endringer mot hovedkopien på Assembla uten at det var gjennomgått i fellesskap først. Dette var for å sørge for en viss kvalitetskontroll, der vi anså arbeidet for å være fullført da det var lagt til i løsningen. 2.3 Backup-løsning Gruppen valgte å bruke den cloud-baserte lagringstjenesten Dropbox til fellesområde for lagring av filer og dokumenter i prosjektarbeidet. Dropbox tilbyr automatisk backup av filer slik at man kan finne tilbake til tidligere versjoner av et dokument. I tillegg blir alle filer synkronisert mot hvert gruppemedlem ved endringer. Dropbox innebygde backup-funksjon fungerer som en enkel versjonkontroll ved at det er mulig å returnere til tidligere versjoner av et dokument og ha oversikt over hvilken person som sist hadde endret filen. For gruppen var det viktig å sikre oss mot datatap som følge av at flere personer arbeidet på de samme kopiene, for dette kunne føre til at informasjon ble overskrevet eller slettet fra dokumentet. I tillegg tok gruppeleder daglig sikkerhetskopier av dokumenter og kildekode på en ekstern harddisk. Vi ønsket å sikre oss ved å ha en ekstra sikkerhetskopi å gå tilbake til, hvis det oppsto et problem med de eksterne lagringsløsningene. 2.4 Prosjekthjemmeside Ved oppstarten av hovedprosjektet ble det opprettet en prosjekthjemmeside, for å presentere rapporter og dokumentasjon fortløpende i prosjektet. Målet for siden var å holde veileder og oppdragsgiver oppdatert på hvordan vi lå an, og eventuelt informere andre studenter om hva prosjektet vårt omhandlet. 2.5 Prosjektdagbok Gruppen har ført en prosjektdagbok der vi har dokumentert daglige hendelser, informasjon fra møter med oppdragsgiver/veileder og kontroll av arbeidstimer for hvert medlem av gruppen. Prosjektdagboken har vært en viktig komponent for å holde kontroll på arbeidsoppgaver, og dokumentere muntlige tilbakemeldinger fra oppdragsgiver. For gruppen var det viktig å ha et felles dokument hvor vi kunne dokumentere daglige fremdrift og holde alle i gruppen oppdatert på all informasjonen vi mottok fra oppdragsgiver og veileder. Dokument 3 - Prosessdokumentasjon 3

7 2.6 Risikoplan I forprosjektfasen gjennomførte gruppen en utredning og analyse over hvilke potensielle risikoer prosjektet kunne stå ovenfor. Hensikten var å vurdere sannsynligheten for at ulike risikoer skulle inntreffe, være klar over hvilke tiltak vi kunne iverksette for å senke risko, og ikke minst hvilke tiltak som kunne iverksettes dersom risiko oppsto. Vi utredet og diskuterte risikoene i fellesskap, og spesielt viktig var det å få inn alternative synspunkter på sannsynlighetsgraden til hver enkelt risiko. Etterhvert som vi fortsatte gjennom de forskjellige fasene av prosjektet, oppsto det endringer i risikoenes sannsynlighet og konsekvenser. Det ville eksempelvis ha en langt større konsekvens for oppgaven dersom vi opplevde tap av data mot slutten av prosjektet enn dersom det samme skulle skje innledningsvis. Konsekvensen av sykdom eller fravær blant gruppemedlemmer ville også ha en langt større konsekvens mot slutten av prosjektet da tidsfristene var korte og arbeidsmengden var stor. Heldigvis opplevde ikke gruppen at noen av risikoene påvirket prosjektarbeidet. Vi hadde noen tilfeller av mangel på tid, og det førte til at vi ved et par anledninger overskred fristene vi hadde satt på iterasjonene i arbeidsplanen. Konsekvensen var derimot liten fordi vi hadde beregnet litt ekstra tid innenfor hver fase av prosjektet slik at ikke hele prosjektgjennomføringen skulle bli påvirket av mindre avvik. Se vedlegg 4 for risikoplan 2.7 Arbeids- og fremdriftsplan Prosjektarbeidet har blitt organisert gjennom en arbeidsplan og en fremdriftsplan. Gjennom arbeidsplanen delte vi prosjektet inn i flere faser med ulike arbeidsoppgaver tilknyttet hver av dem. Rekkefølgen på arbeidsoppgavene ble påvirket av kravspesifikasjonen fordi vi i samarbeid med oppdragsgiver hadde prioritert rekkefølgen på mye av funksjonaliteten som skulle utvikles for løsningen. Punktene beskrevet i arbeidsplanen ble også videreført i en fremdriftsplan. Fremdriftsplanen for prosjektet er presentert i et Gantt-diagram og dette gir et mer overordnet bilde av prosjektet presentert på en lettfattelig måte. Arbeidet vi nedla i arbeids- og fremdriftsplanen resulterte i at vi hadde en tydelig plan å forholde oss til gjennom hele prosjektet. Arbeidsplanen var til stor nytte for oss ettersom det forenklet organiseringen og fordelingen av arbeidsoppgaver. Se vedlegg 10 for fremdriftsplan, og vedlegg 11 for arbeidsplan 2.8 Utviklingsmetode Se produktdokumentasjon punkt 5.1 Vi var fornøyde med utviklingsmodellen vi benyttet i prosjektet, og noe av grunnen til det var at vi hadde tilpasset modellen etter de behovene vi anslo helt i oppstarten. Det var ikke hensiktsmessig for oss å gjennomføre domene-modellering slik som FDD foreslår, da det allerede eksisterte en løsning for bedriften som inneholdt mye av funksjonaliteten og innhold Dokument 3 - Prosessdokumentasjon 4

8 vi skulle videreføre. For oss var det viktigere å finne ut hva som skulle utgjøre kjernefunksjonaliteten i den nye løsningen og hvordan vi kunne endre eller forbedre det som skulle videreføres fra den gamle løsningen. Derfor valgte vi å fokusere på brukerens behov for funksjonalitet fremfor å utforske domene på nytt. 3. Utviklingsprosessen Helt i starten av prosjektet fant vi ut hvilke krav og hvilket omfang prosjektet ville ha. Vi bestemte hva slags arbeidsmetoder vi skulle bruke og hva slags utviklingsverktøy og metoder som skulle brukes. Etter møte med oppdragsgiver fikk vi et innblikk i hvordan de ville ha det, og laget prototyper utifra disse ønskene. Vi kom frem til at vi ville lage en web-applikasjon med Twitter Bootstrap som rammeverk. Da løsningen skulle fungere på ulike plattformer var det essensielt å velge et rammeverk som tilbød responsivt design. 3.1 Gjennomgående aktiviteter Vi har ført dagbok, hvor vi har ført inn hva hvert gruppemedlem har gjort, samt antall timer dette har tatt. I dagboken ble det også skrevet opp korte referater fra møte med veileder og oppdragsgiver. Vi har hatt møte med veileder en gang i uken. 3.2 Idéfasen I denne fasen innledet vi samarbeidet med oppdragsgiver og vi fikk en overordnet forståelse av oppgavens omfang. Vi orienterte oss om hvilke verktøy vi måtte beherske for å gjennomføre prosjektet. Vi fant også ut hvilket program vi skulle bruke for versjonskontroll, og vi ble enige om «Versions» som versjonskontroll og «Assembla» som lagringsverktøy. 3.3 Forprosjektfasen Vi laget innledningsvis en gruppeavtale, hvor det ble satt klare regler for samarbeidet innad i gruppen. Dette var en kontrakt som ble underskrevet av alle medlemmene på gruppen. Ved å lage en gruppeavtale fikk vi en enighet i gruppa om hva som ble krevd av oss, og hva konsekvensene var om vi ikke oppfylte disse kravene. Videre startet vi arbeidet med å kartlegge krav og ønsket funksjonalitet for produktet vi skulle lage. Vi foretok en brukerundersøkelse, gjennomførte samtaler med ansatte og vi testet løsningen for å avdekke svakheter og forbedringspotensiale. Vi analyserte deretter dataene vi samlet inn. Vi laget forprosjektrapport, innledende UseCase, innledende kravspesifikasjon, og ansvarsfordeling for prosjektet. Arbeidsplan og fremdriftsplan ble også laget i denne fasen. Ved å foreta disse innledende aktivitetene ble vi bedre forberedt til å starte på oppgaven. Vi fikk en bedre forståelse av hva som skulle gjøres, og hvordan. Dokument 3 - Prosessdokumentasjon 5

9 3.4 Utførelsesfasen I denne fasen utarbeidet vi designforslag, strukturerte menyene og innhold. Vi laget design til grensesnitt og applikasjonslogikk. Database ble designet og opprettet og vi laget alle modulene som skulle være med på siden. Da vi skulle komme frem til designet, jobbet alle hver for seg for å komme opp med ulike designforslag. Vi var innom tanken på å lage en løsning som kun inneholdt ikoner på forsiden, men valgte bort dette forslaget da dette designet ikke ville utnyttet datamaskinens skjermstørrelse på en god måte. Vi var også inne på tanken på å lage en «slide-meny» for mobil, men dette designet ble forkastet da det ikke var stabilt nok. Da vi skulle lage de forskjellige modulene, fordelte vi de på gruppens medlemmer. Enkle moduler ble stort sett laget av en person, mens de større ble laget parvis. Grunnen til at vi jobbet parvis på enkelte moduler, var for å få flere innspill på hvordan modulen skulle se ut og hva slags funksjonalitet som skulle være med. Men, selv om det var to som laget en modul, hadde alle gruppens medlemmer lov til å komme med innspill. 3.5 Testfasen Se punkt 4 i produktdokumentasjonen. Da testfasen begynte var all funksjonalitet implementert i henhold til kravspesifikasjonen. Det ble utført systemtest på all kode for å sjekke at den samsvarte med UseCase-beskrivelser og kravspesifikasjon. Videre ble det utført test av løsningen på ilab for å sammenlikne med den eksisterende (gamle) løsningen, som vi testet i forprosjektfasen. Avslutningsvis ble det avholdt brukertest/fritest med ansatte fra Uno-X for å finne ut hva de syntes om løsningen. 3.6 Avslutningsfasen I denne fasen ble dokumentasjonen skrevet og presentasjon av prosjekt laget. Arbeidet ble fordelt av gruppeleder på en slik måte at alle skulle få en lik mengde å skrive om. 3.7 Diskusjon rundt utviklingsprosess Utviklingsprosessen har fungert veldig bra. Vi fikk en god start etter nyttår og tok oss god tid til å bearbeide krav og informasjon før vi startet på design og koding. På denne måten fikk vi definert oppgaven godt og greide å sette opp realistiske arbeids og fremdrifts-planer. Vi brukte mye tid på å anslå tidsforbruket relatert til design og koding av de forskjellige modulene i systemet. I ettertid ser vi at estimatene stemte godt overens med virkeligheten. Noen moduler tok litt lenger tid å fullføre enn antatt, mens andre tok litt mindre tid. Alt i alt var vi ferdig med produktet på den tiden vi hadde avsatt. Hvis det er en ting vi har feilberegnet må det være hvor lang tid det faktisk tar å dokumentere et prosjekt. Samtlige gruppemedlemmer skulle nok helst sett at vi hadde kommet i gang med dette tidligere. Dokument 3 - Prosessdokumentasjon 6

10 4. Vurdering av teknisk arkitektur Se punkt 3.4 i produktdokumentasjonen Oppdragsgiver hadde et ønske om at prosjektet ble laget med Model-view-controller designmønster. (MVC). Bruken av MVC tilfører ryddighet og struktur til koden. Likevel gjorde vi en vurdering hvor vi kom frem til at det var vanskelig å implementere MVC uten å benytte et rammeverk. Da ingen av gruppens medlemmer hadde kjennskap til noen PHP-rammeverk fra tidligere ble dette vurdert som for tidkrevende å komme igang med. Vi valgte derfor å utelate MVC-mønsteret. I samråd med veileder valgte vi i stedet å lage en egen løsning som har mye av de samme kvalitetene, med hovedvekt på høy separasjon mellom presentasjon og logikk. Vi valgte å kode løsningen objektorientert da vi mente dette ville føre til ryddigere kode, og at det ble muligheter for en del kode-gjenbruk. Det var ikke alle på gruppen som kunne like mye objektorientering fra tidligere, disse sitter nå igjen med mye tilegnet informasjon fra prosjektet. Vi har fått et prosjekt som har en ryddig og oversiktlig struktur, noe vi neppe hadde greid med rent proseduralt design. 5. Vurdering av brukergrensesnitt Se punkt 3.2 i produktdokumentasjonen Da vi designet brukergrensesnittet hadde vi et mål om et rent og lettfattelig design. Vi brukte Twitter Bootstrap som rammeverk for løsningen da dette rammeverket skalerer godt på ulike plattformer. Vi brukte jquery/javascript for å gjøre løsningen mer interaktiv, og for å forbedre brukeropplevelsen. Da vi testet den gamle løsningen, fant vi ut at den gamle løsningen hadde en uoversiktlig meny med veldig mange undermenyer. Vi valgte derfor å ha en enkel menystruktur på den nye løsningen, med få undermenyer. Vi har også lagt stor vekt på at systemet skal gi oversiktlige tilbakemeldinger når en operasjon blir utført. (Se figur 5.1. og 5.2). Strukturen er satt opp slik at alle sider har gjennomgående likt design, for å gi brukeren en enklere navigering. Brukergrensesnittet skal oppføre seg nogen lunde likt på alle de ulike plattformene det kan kjøres på. Figur Advarsel før sletting av artikkel Dokument 3 - Prosessdokumentasjon 7

11 Figur melding om at artikkel er slettet Grafisk sett er brukergrensesnittet laget i farger som gjenspeiler bedriftens uttrykk. Likevel oppfyller brukergrensesnittet standarden for leselighet (WCAG 2.0). 6. Vurdering av kravspesifikasjon Vi har i startfasen av prosjektet jobbet mye med å utforme kravspesifikasjonen. Dette er et viktig dokument som setter rammer for de oppgavene som skal utføres. Vi har holdt oss til noen punkter som er beskrevet under da vi utformet kravspesifikasjonen. Alle krav i kravspesifikasjonen har vært mulige å oppfylle. Vi satt en strek ved det vi mener var realistisk at vi skulle klare å fullføre med tanke på den tiden vi hadde til rådighet. Å sette en strek i listen over krav var også med på å avklare overfor oppdragsgiver hva som var realistisk å oppnå i prosjektperioden. Vi har gått igjennom alle krav i kravspesifikasjonen og har i tett samarbeid med oppdragsgiver kommet frem til det som er endelig versjon. Ved å få kravspesifikasjonen signert og godkjent av vår oppdragsgiver har det ikke vært mulighet for at noe kan "bestemmes senere" i kravspesifikasjonen. For at kravspesifikasjonen skulle være konsistent utformet vi den slik at alle krav var mulige å oppfylle, ingen krav ble utelukket av andre krav i spesifikasjonen. Det foreligger i sluttproduktet minimalt med avvik fra kravspesifikasjonen. Det eneste punktet som ikke er oppfylt er støtte for Opera Mini-nettleser. Dette viser seg å være utenfor vår kontroll da denne nettleseren ikke er kompatibel med deler av Twitter Bootstrap-koden. Det har innenfor prosjektets rammer ikke vært mulig å lage en spesialtilpasset løsning for en enkelt nettleser. Øvrige punkter er innfridd frem til det punktet der vi i satte sluttstrek i forbindelse med med behandlingen av kravspesifikasjonen. 7. Vurdering av testing Vi har gjennom hele prosjektet, men spesielt i utviklingsfasen gjort tester i ulike nettlesere, på ulike plattformer. Vi har utført systemtester, brukertester og ilab test. Alle moduler i produktet ble testet individuelt før de ble implementert med resten av koden. Vi har ved avslutningen av hver sprint testet for å få produktet vårt så feilfritt som mulig. Dokument 3 - Prosessdokumentasjon 8

12 Vi fant under de ulike innledende testene raskt ut at løsningen Uno-X bruker i dag ikke var optimalt strukturert og at mye informasjon på siden var plassert ulogisk i forhold til hva man hadde tenkt seg. Vi har i ny versjon av Automatnett jobbet med bedre menystruktur, nytt utseende, bedre søkefunksjon, bedre forum samt at siden skalerer bedre på alle enheter som nettbrett, desktop og mobil. Vi har tatt den samme testen vi tok på «gamle» Automatnett også på den nye Automatnett løsningen. Vi er godt fornøyd med resultatene av våre tester på ny løsning og har fått gode tilbakemeldinger fra våre oppdragsgivere da de testet. Ilab-testene bekreftet at den nye løsningen har forenklet og gjort det lettere å bruke Automatnett med nytt utseende og ny eller forbedret funksjonalitet. Det har også blitt lettere for administratorer hos Uno-X å oppdatere siden i forhold til gammel løsning som brukte Lotus Notes som verktøy for oppdatering av siden. Testingen var ganske omfattende og tok mye tid. Vi har gjennomført brukertester, systemtester og testet løsningen vår på ilab en ved HIOA. Vi har hatt hjelp fra en ekstern testperson da vi testet Automatnett, men har gjort de fleste testene selv. Ved å teste fortløpende og ved avslutning av hver sprint har vi klart å sikre kvaliteten på produktet vårt. Ikke bare testingen på ilab, men også de andre testene har ført til at vi har avdekket mange punkter som har blitt bedre på ny versjon. 8. Avslutning 8.1 Produktet Vi har utviklet en ny CMS-løsning for Uno-X som baserer seg på et eksisterende system. Nye Automatnett har hovedvekt på brukervennlighet og skalerer bra på nettbrett, mobil og desktop. Vi har brukt rammeverket Twitter Bootstrap og benyttet oss av mulighetene for responsiv CSS. Det vil si at løsningen tilpasses den enheten den brukes på. Dette er noe som ikke fungerte bra på den gamle versjonene av Automatnett og som nå fremstår som svært forbedret. I tillegg til å forenkle bruken på nye Automatnett i forhold til den gamle løsningen, har vi implementert mer funksjonalitet og forbedret utseende. Vi har blant annet forenklet innsending av skjemaer som fra før var gjort manuelt og nå kan gjøres elektronisk. Vi tror løsningen vil kunne være til stor nytte for oppdragsgiver og at den kan effektivisere de ansattes hverdag betraktelig. 8.2 Læringsutbytte Vi har hatt en bratt læringskurve siden oppstart av prosjektet. Vi har allikevel hatt en god plattform å støtte oss på med tanke på den kunnskapen vi har tilegnet oss gjennom studiene ved Høgskolen i Oslo og Akershus. Samarbeidet med Uno-X har vært en forsmak på hva som kan vente oss i en fremtidig jobbsituasjon og hvordan det er å jobbe som IT-konsulent i Dokument 3 - Prosessdokumentasjon 9

13 praksis. Vi har også gjennom de ulike fasene i prosjektet måttet tilegne oss ny kunnskap om ulike problemstillingene som har dukket opp. 8.3 Konklusjon Dette er det mest omfattende prosjektet noen av oss har deltatt i så langt. Vi har benyttet oss av velkjente metoder og tatt i bruk vår egen agile utviklingsmetode som tar utgangspunkt i utviklingsmetoden «Feature-driven Development». Vi har sammen med vår veileder og oppdragsgivere hatt en åpen dialog og fått tilbakemeldinger gjennom hele prosessen med å lage det nye systemet. Vi støtte på flest utfordringer i oppstarten og da vi begynte med programmeringsfasen og utvikling av funksjonalitet. Her var det mye nytt å lære på kort tid. Etterhvert som vi ble tryggere på bruken av vår utviklingsmetode, Twitter Bootstrap rammeverket, lagdeling av den nye løsningen og arbeidsoppgaver ble fordelt, fortonet arbeidet seg mye lettere og mer lystbetont. Vi har klart å styre unna de mest kritiske risikoene i prosjektet. Vi har hatt god kontroll hele veien, men det har alltid vært et ønske om å få til litt mer før man avslutter. Dette til tross for at vi har fått implementert alle de funksjonene vi ble enige om på forhånd. Vi er stolte av produktet vårt. Vi er godt fornøyd med prosjektperioden og gruppens innsats. Vi er også godt fornøyd med veiledning og oppfølging vi har fått fra vår oppdragsgiver og fra veileder ved skolen. Dokument 3 - Prosessdokumentasjon 10

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

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

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

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

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

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

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

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

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

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

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

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

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

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

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

Detaljer

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

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

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

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1 HiOA TDK Ingeniørfag data DATS1600 Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 - Prosessdokumentasjon - Alternativ 1 - Forsikring - Gruppe #14 Studentnavn Marius Alexander Skjolden Hans Christian

Detaljer

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Forprosjektrapport Hovedprosjekt våren 2009 Gruppenr. H09E03 Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Styre- og loggsystem for en testjigg HØGSKOLEN I ØSTFOLD Avdeling for ingeniørfag Postadresse:

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

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

Gruppe 43. Hoved-Prosjekt Forprosjekt Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de

Detaljer

Forprosjektrapport ElevApp

Forprosjektrapport ElevApp Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse

Detaljer

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

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

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

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

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

Gruppe Forprosjekt. Gruppe 15

Gruppe Forprosjekt. Gruppe 15 Forprosjekt Gruppe 15 Marius Ylven Westgaard - s236797 - Anvendt Datateknologi Lise Janbu Eide - s236361 - Dataingeniør Lavanja Jeyenthiran - s236346 - Dataingeniør Kristian Pedersen - s236728 - Anvendt

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

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål

Detaljer

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Bacheloroppgave 2017 Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon

Detaljer

Steg for steg. Sånn tar du backup av Macen din

Steg for steg. Sånn tar du backup av Macen din Steg for steg Sånn tar du backup av Macen din «Being too busy to worry about backup is like being too busy driving a car to put on a seatbelt.» For de fleste fungerer Macen som et arkiv, fullt av bilder,

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

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

Dokument 2 - Produktdokumentasjon

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

Detaljer

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser) Arbeidsplan En arbeidsplan er en måte å få oversikt over de ulike fasene i prosjektet. I arbeidsplanen har vi delt arbeidet i naturlige faser og detaljert disse med estimert tidsbruk. Hovedfasene er startfasen,

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

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens

Detaljer

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

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

Forprosjektrapport H10E02 25.03.2010. Tilknytning av små vindkraftverk til 22 kv fordelingsnett. Gruppemedlemmer:

Forprosjektrapport H10E02 25.03.2010. Tilknytning av små vindkraftverk til 22 kv fordelingsnett. Gruppemedlemmer: Forprosjektrapport Tilknytning av små vindkraftverk til 22 kv fordelingsnett. H10E02 25.03.2010 Gruppemedlemmer: Markus Fagerås Stian Dahle Johansen Stein Ove Jensen HØGSKOLEN I ØSTFOLD Avdeling for ingeniørfag

Detaljer

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016

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

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

Mandag : Onsdag : Torsdag : Mandag :

Mandag : Onsdag : Torsdag : Mandag : Prosjektdagbok Mandag 13.01.2014: - Oppmøte på Accenture. Pratet med veileder om oppgaven og avtalte at vi skulle starte med problemstilling, møteintervall og formulering av oppgaven. Tidsperspektivet

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

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

PROSJEKTDAGBOK GRUPPE 28

PROSJEKTDAGBOK GRUPPE 28 PROSJEKTDAGBOK GRUPPE 28 Uke 43-25.10.2009 Tid/Sted P35 Gruppen består av 5 medlemmer. Vi hadde en bli kjent opplegg i dag. Arbeider med å levere inn statusrapporten til fredag 30.10.2009. Uke 48-29.11.2009

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

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar

Detaljer

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324

Detaljer

Bachelorprosjekt 2017

Bachelorprosjekt 2017 Bachelorprosjekt 2017 Høgskolen i Oslo og Akershus Gruppe 41 Kristan Munter Simonsen (s236789) Andreas Jacobsen (s236778) Jamal Lakbir (s236722) 1 Innholdsfortegnelse Forprosjekt... 3 Presentasjon... 3

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

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

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. Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe 15 25.01.2012

Forprosjektrapport. Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe 15 25.01.2012 2012 Forprosjektrapport Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe 15 25.01.2012 1 Innhold 2 Presentasjon... 3 3 Sammendrag... 3 4 Dagens situasjon...

Detaljer

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem

Detaljer

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

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

Detaljer

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

Testdokumentasjon Presentasjon

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

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android 6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision

Detaljer

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

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

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

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

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

Detaljer

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018 Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018 Utvikling av Spires Medlemsregister Gruppe 2, medlemmer Etternavn Fornavn og mellomnavn Studentnummer

Detaljer

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00) Dagbok Januar Uke 2 (7.1-11.1) Vi har lest halvveis på standard dokumentasjon og jobbet med forprosjektrapport. Vi har hatt vårt første møte med den interne veilederen vår Tor Hasle. Vi fortalte om at

Detaljer

Hovedprosjekt. Høgskolen i Oslo og Akershus Våren Gruppe 3 Forprosjektrapport

Hovedprosjekt. Høgskolen i Oslo og Akershus Våren Gruppe 3 Forprosjektrapport Hovedprosjekt Høgskolen i Oslo og Akershus Våren 2012 Gruppe 3 Forprosjektrapport INNHOLDSFORTEGNELSE Presentasjon... 3 Gruppen... 3 Bedriften... 3 Sammendrag... 4 Dagens situasjon... 4 Native-applikasjon...

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

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

PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300

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

Detaljer

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

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

Forprosjektrapport. Gruppe 31

Forprosjektrapport. Gruppe 31 Forprosjektrapport Gruppe 31 1 Presentasjon Oppgave: Finne et kodespråk som kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. Periode: 14. januar til

Detaljer

Forprosjektrapport gruppe 20

Forprosjektrapport gruppe 20 Høgskolen i Oslo og Akershus Forprosjektrapport gruppe 20 PlaNet Knut Magnus Elde s189160 Kristoffer Ylven Westgaard s189143 22.01.2015 Innhold 1. Sammendrag... 3 2. Dagens situasjon... 3 3. Mål og rammebetingelser...

Detaljer

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

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

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

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

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

WillWest Smøredatabase

WillWest Smøredatabase Vedlegg WillWest Smøredatabase GRUPPE 21 FORFATTERE: BREKKLUND, PÅL E. LARSEN, MARTIN WESTGAARD, CHRISTIAN S. 1 Innholdsliste Vedlegg... 1 Innholdsliste... 2 1 Forord... 3 2 Databasemodeller... 4 3 Styringsdokumenter...

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

Gruppelogg for hovedprosjekt 2009

Gruppelogg for hovedprosjekt 2009 Gruppelogg for hovedprosjekt 2009 Før det endelige valget på prosjektet ble tatt brukte gruppen en del tid på å finne forskjellige muligheter for oppgaveemner. Det ble blant annet kontaktet Hafslund produksjon

Detaljer

Kunnskapssenteret. Flytskjema

Kunnskapssenteret. Flytskjema Kunnskapssenteret Flytskjema Et flytskjema er et verktøy for å kartlegge arbeidsprosessene i en organisasjon eller mellom flere organisasjoner. Ved å reflektere sammen over flytskjemaet kan man utvikle

Detaljer

MakerSpace Event System

MakerSpace Event System 18. Januar 2019 Bachelor gruppe 11: Amanda Kristine Hansen Anders Tidemann Norli Dexter Winther Smith Innholdsfortegnelse Prosjektpresentasjon 3 Innledning 4 Bachelorgrupp a 4 Amanda Kristine Hansen 4

Detaljer

FORPROSJEKT. Gruppemedlemmer: Raja Zulqurnine Ali Muddasar Hussain (Gruppeleder/Prosjektleder) Zain-Ul-Mubin Mushtaq Christopher Llanes Reyes

FORPROSJEKT. Gruppemedlemmer: Raja Zulqurnine Ali Muddasar Hussain (Gruppeleder/Prosjektleder) Zain-Ul-Mubin Mushtaq Christopher Llanes Reyes FORPROSJEKT I denne rapporten gjør vi analyse for hvor mye arbeid som kan gjøres. Rapporten skal også avgrense prosjektet med en mer presis beskrivelse. Den vil i tillegg blant annet inneholde teknologi

Detaljer

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

Detaljer

Kvalitetskrav til løsninger

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

Detaljer

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

Forprosjektsrapport MMS - MakeSpace Management System BO19-G03

Forprosjektsrapport MMS - MakeSpace Management System BO19-G03 Forprosjektsrapport MMS - MakeSpace Management System BO19-G03 Andreas Harnes Celina Marie Kristiansen Magnus Klerck Morten Offerdal Kvigne 21. januar 2019 1 Innhold 1 Prosjektgruppen 3 2 Oppdragsgiver

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

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

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

Fag ITD 33506 Bildebehandling og mønstergjenkjenning. mandag 28. oktober til fredag 15. november 2013

Fag ITD 33506 Bildebehandling og mønstergjenkjenning. mandag 28. oktober til fredag 15. november 2013 Høgskolen i Østfold Avdeling for informasjonsteknologi Fag ITD33506 Bildebehandling og mønstergjenkjenning PROSJEKTOPPGAVE Halden, Remmen 02.10.2013 Fil : Skrevet ut av : sl 02.10.2013 09:27:00 Antall

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

Repository Self Service. Hovedoppgave våren 2010

Repository Self Service. Hovedoppgave våren 2010 Forprosjektrapport for Repository Self Service Hovedoppgave våren 2010 Christer Berg (070604 07HBDRA) Ron Stangvik (070427 07HBDRA) 1 Innholdsfortegnelse 1. MÅL OG RAMMER...3 1.1. Bakgrunn...3 1.2. Prosjektmål...3

Detaljer

Nøtterøy kommune Bjønnesåsen bo- og behandlingssenter

Nøtterøy kommune Bjønnesåsen bo- og behandlingssenter Nøtterøy kommune Bjønnesåsen bo- og behandlingssenter Elin-K-samsplllprosjektet v/sissel Skarsgaard Nors Sykepleierforbund Postboks 456, Sentrum 0104 OSLO Saksbehandler: Direl

Detaljer

Forprosjektrapport. Sammendrag. Hovedoppgave våren 2019 Gruppe 3

Forprosjektrapport. Sammendrag. Hovedoppgave våren 2019 Gruppe 3 Forprosjektrapport Hovedoppgave våren 2019 Gruppe 3 Sammendrag Vi skal overføre en eksisterende nettside over på en ny plattform samt legge til noe tilleggsfunksjonalitet. Hovedutfordringene ved den eksisterende

Detaljer