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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Detaljer

KRAVSPESIFIKASJON 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

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

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

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

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

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

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

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

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

Kravspesifikasjon. Forord

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

Detaljer

Hovedprosjekt 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

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

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

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

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

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

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

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

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

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

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

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

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

1. Presentasjon av prosjekt. Forord

1. Presentasjon av prosjekt. Forord 1. Presentasjon av prosjekt Forord Dette prosjektet har strukket seg over et semester på Høgskolen i Oslo og Akershus, institutt for Informasjonsteknologi. Prosjektet har vært et utfordrende, men samtidig

Detaljer

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

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

Detaljer

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

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

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

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

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

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

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

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

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

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

Detaljer

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

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

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

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

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

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

References Hovedprosjekt ved Høgskolen i Oslo 2010 Testrapport

References Hovedprosjekt ved Høgskolen i Oslo 2010 Testrapport Innholdsfortegnelse Testdokumentasjon... 3 Innledning... 3 Brukertester... 3 Brukertest av filer... 3 Brukertest av lenker... 4 Brukertest av notater... 5 Enhetstester... 7 Konklusjon... 8 2 S ide Testdokumentasjon

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

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016 Forprosjektrapport Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Våren 2016 Gruppe 24 Jon Gillingsrud og Christoffer André Belgen Fredriksen Veileder Thor E. Hasle thor.hasle@hioa.no

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

Forprosjektrapport Hovedprosjekt våren 2015 HiOA

Forprosjektrapport Hovedprosjekt våren 2015 HiOA Forprosjektrapport Hovedprosjekt våren 2015 HiOA Gruppe 9 Innhold 1. Presentasjon.... 3 2. Sammendrag.... 3 3. Dagens situasjon... 4 4. Mål og rammebetingelser... 5 5. Løsninger/Alternativer.. 6 6. Analyse

Detaljer

Forprosjektrapport. Gruppe 3, Anvendt Datateknologi våren 2016

Forprosjektrapport. Gruppe 3, Anvendt Datateknologi våren 2016 Forprosjektrapport Gruppe 3, Anvendt Datateknologi våren 2016 1. Presentasjon 2. Sammendrag 3. Dagens situasjon 4. Mål og rammebetingelser 5. Løsninger/alternativer 6. Analyse av virkninger 1. Presentasjon

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

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

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

Detaljer

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

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

Detaljer

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

Forprosjektrapport. Bachelorprosjekt ved Høgskolen i Oslo og Akershus, våren Gruppe 11. Mohamed el Morabeti, s198748

Forprosjektrapport. Bachelorprosjekt ved Høgskolen i Oslo og Akershus, våren Gruppe 11. Mohamed el Morabeti, s198748 Forprosjektrapport Bachelorprosjekt ved Høgskolen i Oslo og Akershus, våren 2016 Gruppe 11 Mohamed el Morabeti, s198748 Hotan Shahidi-Nejad, s236770 Arlen Syver Wasserman, s193956 Studentparlamentet 1

Detaljer

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

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

Detaljer

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

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

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Prosessdokumentasjon

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Prosessdokumentasjon HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe 10 27.05.2014 Forord Formålet med denne rapporten skal være å gi leseren en innsikt

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

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

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

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

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

Detaljer

Pajtim Aslani s Oslo, 2016 Kujtim Aslani s { } NDC Videos. Forprosjektrapport. Gruppe 30 Pajtim Aslani s Kujtim Aslani s188878

Pajtim Aslani s Oslo, 2016 Kujtim Aslani s { } NDC Videos. Forprosjektrapport. Gruppe 30 Pajtim Aslani s Kujtim Aslani s188878 Pajtim Aslani s198588 Oslo, 2016 Kujtim Aslani s188878 { } NDC Videos Forprosjektrapport Gruppe 30 Pajtim Aslani s198588 Kujtim Aslani s188878 Innholdsfortegnelse 1 Presentasjon 1.1 Oppdragsgiver 1.1.1

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

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

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

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

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

Detaljer

Mobile apps for Android and ios platforms Forprosjekt

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

Detaljer

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

emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype

emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype Velkommen! Program for presentasjonen: Bakgrunn for og hensikt med prosjektet Prosjektgruppen og interessenter Prosjektplanen

Detaljer