RUTEPLANLEGGINGSSYSTEM PROSESSDOKUMENTASJON

Størrelse: px
Begynne med side:

Download "RUTEPLANLEGGINGSSYSTEM PROSESSDOKUMENTASJON"

Transkript

1 RUTEPLANLEGGINGSSYSTEM PROSESSDOKUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

2 1 FORORD Denne dokumentasjonen skal beskrive de forskjellige prosessene som inngår i arbeidet med hovedprosjektet ved Høgskolen i Oslo, avdeling for ingeniørutdanning, våren Dette dokumentet er optimalisert for papir. Vi kom i kontakt med Kraft Foods gjennom Per-Arne Baakind, som er faren til Andreas. Han er prosjektleder for et av konsernets systemer, og jobber sammen med regionsjefen for region Øst. Regionssjefene i Kraft Foods bruker excelark for å planlegge hvilke butikker selgere og fremmere skal besøke. Dette var en løsning som skulle fungere midlertidig i et par måneder, men er blitt brukt i over 4 og et halv år. Derfor håpet de at vi kunne lage en bedre løsning som de kunne bruke istede for den tungvindte løsningen i excel. Etter vårt første møte med Jarle Birkeli, ble vi enige om at dette er et ypperlig hovedprosjekt. Hensikten med prosjektet er å lage en bedre løsning enn dagens excel løsning. Vi valgte å bygge opp en løsning i nettleseren, slik at det ikke var behov for installasjon, implementasjon og stadig oppdatering av alle maskinene som inngår i systemet. Dette gjør det også enklere for alle både internt og eksternt å nå applikasjonen for å planlegge ruter, samt for selgere og fremmere å få tilgang til sine ruter. Disse er per idag manuelt printet ut hos Kraft Foods og gitt til hver enkelt selger / fremmer. Dette stiller høye krav til sikkerhet, noe som nevnes i et senere kapittel. Side 2

3 2 INNHOLDSFORTEGNELSE 1 Forord Innholdsfortegnelse Innledning Om bedriften Bakgrunn for problemet Mål med oppgaven Rammebetingelser og begrensinger Planlegging og metode Genrell planlegging Arbeidsplan og fremdriftsplan Planlegging av databasetruktur Planleggingen i praksis Verktøy Skype og Windows fjernhjelp Dropbox Visual Studio, Team Foundation og Microsoft SQL Google Docs Facebook MySQL Workbench Kommunikasjon med oppdragsgiver Metode Utviklingsprosessen Prosjektets faser Gruppedannelse og valg av oppgave Startfase innledende arbeid Side 3

4 5.1.3 Forprosjektfase Planleggingsfasen Utviklingsfasen Testfasen Dokumentasjonsfasen AvslutNingsfasen Valg om oppbygning og funksjoner Lagdelingsprinsipp Problemer og løsninger Samarbeid med oppdragsgiver Programmeringsspråk Lagdeling Nettilgang Datamodellen Ajax-popup Kravspesifikasjonen og dens rolle i prosjektet Endringer i kravspesifikasjonen Kravspesifikasjon i forhold til design og implementering Samsvar mellom kravspesifikasjon og det ferdige produktet Om resultatet Tilbakeblikk Kildereferanser Nettsider Vedlegg Datamodell første utkast Side 4

5 3 INNLEDNING 3.1 OM BEDRIFTEN Kraft Foods er en av Nordens ledende næringsmiddelbedrifter med ca ansatte i fire fabrikker. Deres sterke varemerker gjør dem til markedsleder innen kategoriene sjokolade, kaffe, kjeks og andre matvarer som sjokoladedrikker, kremost, bakeprodukter og desserter. Kraft Foods produserer blant annet varemerkene Freia, Philadelphia og Oboy. 3.2 BAKGRUNN FOR PROBLEMET I dag bruker regionssjefene hos Kraft Foods et excelark for å planlegge ruter for sine selgere og fremmere. Det er også lagt inn diverse rapportfunksjoner som for eksempel oversikt over tonnasje for hver butikk. Samtidig er hele kundedatabasen på over 4000 butikker lagt inn i samme excelark. Dette er et veldig tungt og innviklet system å jobbe med, hvor det er lett å gjøre feil. Kraft Foods vil derfor ha en enklere løsning bygget opp på en database, for å enklere kunne oppdatere og vedlikeholde informasjonen, samt forenkle arbeidsprosessen betraktelig. 3.3 MÅL MED OPPGAVEN Målet med oppgaven vil være å utvikle et webbasert ruteplanleggingssystem for Kraft Foods. Dette systemet skal gjøre det enklere å administrere og vedlikeholde data for ruter, selgere, fremmere og kunder. I tillegg å gjøre det enklere for selgere og fremmere å hente ut sine egne ruteopplysninger, samt informasjon om sine kunder. I og med at dagens løsning med excelark på mer enn 15MB er innviklet og tungt, vil noen av målene være å utvikle en løsning som er mer oversiktlig og enklere å vedlikeholde. Dagens løsning er også utsatt for utdatert kundeinformasjon, mye dobbeltlagring, samt store marginer for feil og oversrkriving av data. Per dags dato legger alle fire regionssjefene hver sin version av excelarket inn på et felles område på Kraft Foods sine servere. Dette settes da sammen til ett, og det er i denne fasen det er enkelt å overskrive hverandre data. Regionssjefene har også problemer med å huske om de lastet sist oppdaterte informasjon opp til fellesområdet, og kan iblandt glemme å gjøre dette. Andre mål med oppgaven vår blir dermed at systemet vårt skal være mindre tidkrevende enn dagens system. 3.4 RAMMEBETINGELSER OG BEGRENSINGER Etter flere møter og mail med oppdragsgiver har vi kommet frem til at vi systemet skal utvikles i Microsofts ASP.NET. All utvikling vil dermed foregå i Microsofts eget IDE (Integrated development environment), Visual Studio. Databasen vil være Microsoft SQL server. Sluttproduktet skal helst ligge på en server hos Kraft Foods, men de er usikre på om ITavdelingen vil tillate oss å legge applikasjonen på deres servere, med tanke på sikkerheten og komplekisteten i systemet. En svakhet i vårt system kan få katastrofale følger for andre applikasjoner som er tilknyttet deres servere. Dersom Kraft Foods ikke kan hoste websiden selv, vil Bjart Pedersen ordre med et eksternt webhotell. Side 5

6 4 PLANLEGGING OG METODE 4.1 GENRELL PLANLEGGING Gruppemedlemmene i hovedprosjektet var klart lenge før vi i det hele tatt startet med å finne en oppgave. Medlemmene på gruppen har jobbet mye med hverandre i de foregående semesterne ved Høgskolen i Oslo. Selve valg av prosjekt og oppdragsgiver ble gjort høsten 2010, da vi møtte Jarle Birkeli, regionssjef i Kraft Foods. Dermed hadde vi i utgangspunktet god tid til å planlegge prosjektet sammen med oppdraggiver. På det første møtet med oppdragsgiver fikk vi innsikt i hva som skulle utvikles, og vi hadde kun en muntlig avtale på at vi skulle gjennomføre prosjektet. Vi fikk raskt opp en prosjekthjemmeside der alle dokumentene til prosjektet publiseres fortløpende. Da vi signerte kontrakten med Kraft Foods helt i starten av 2011, kom vi i gang med den virkelige planleggingen av prosjektet. Vi fikk nå tilgang til excelarkene de brukte for å planlegge ruter og det var først nå vi forsto hvor mye det var som skulle gjøres. Det var derfor viktig for oss å få den informasjonen vi trengte om rammeverk, servertilgang, svar på spørsmål om excel-arkene og datamodellen. Dette viste seg å være vanskelig. Kraft Foods brukte lang tid på å svare, og ofte fikk vi kun svar på deler av spørsmålene. Det viste seg også at IT-avdelingen i Kraft Foods heller ikke vær særlig samarbeidsvillige og fortalte oss at de ikke hadde noen webserver hvor vi kunne implementere systemet. Dette fordi de ikke viste noe om sikkerheten i vårt system, og ikke ville ødelegge andre essensielle systemer på deres servere. Det ble dermed vanskelig for oss planlegge noe om selve utviklingen av prosjektet, siden vi ikke fikk noe informasjon om type server og lignende. Dette førte til at vi ikke kunne starte utviklingen på grunnlag av at vi da ikke visste hvilket programmeringsspråk vi kom til å bruke. 4.2 ARBEIDSPLAN OG FREMDRIFTSPLAN Arbeidsplanen og fremdriftsplanen ble laget i slutten av januar. Vi hadde dermed sett for oss hvilke deler av prosjektet som skulle være påbegynt til hvilke tider og når de skulle være ferdige. Disse planene var realistiske anslag på hvor lang tid hver fase i prosjektet ville ta. Det var derfor viktig å følge fristene slik at vi ikke kom til å havne på etterskudd, og dermed få hastverk med utviklingen av løsningen. Desverre tok datainnsamlingen svært lang tid, både fordi excelarkene var kompliserte og fordi det var til dels dårlig kommunikasjon fra Kraft Foods sin side. Disse dokumentene vil derfor avvike noe i forhold til hvilke tidsfrister vi hadde planlagt. 4.3 PLANLEGGING AV DATABASETRUKTUR Det skulle over 4000 kunder inn i databasen med forskjellige ruter og statistikk linket opp til hver av dem. Det var derfor viktig å lage en god plan over hvordan vi kunne løse dette. Vi fikk utskrifter fra en av databasene til Kraft Foods, og planla utifra disse hvordan vi skulle løse blant annet importering og oppdateringer av databasen. Utskriftene kom i form av excelark og vi ble dermed enige om at disse kunne brukes til importering og oppdatering av databasen. Allikevel var strukturen komplisert, og vi endret hele oppbygningen av databasen på ett tidspunkt da vi klarte å utarbeide en løsning vi syntes var bedre. Dette tok mye ekstra tid, men i forhold til resultatet var det verdt det ekstra bryet. 4.4 PLANLEGGINGEN I PRAKSIS Da vi hadde satt opp fremdriftsplanen og arbeidsplanen følte vi at vi hadde god tid på oss til å gjennomføre prosjektet. Vi hadde tatt hensyns til andre fag vi tok samtidig, og ferier vi skulle ha. Det tok dessverre kort tid før vi allerede hadde brutt flere av tidsfristene. I forhold til arbeidsplanen var vi i rute helt frem til vi startet med datainnsamlingen, som leder videre til kravspesifikasjon og deretter selve utviklingen av løsningen. Datainnsamlingen stoppet hele prosessen i Side 6

7 prosjektet, og vi fikk dermed ikke kommet skikkelig i gang med utviklingen av løsningen. Det var også en del misforståelser angående databasemodellen. En god del av arbeidet som ble gjort her ble dermed ubrukelig og vi måtte gjøre dette på nytt. 4.5 VERKTØY Vi benyttet en rekke verktøy gjennom hele hovedprosjektet. De fleste av dem har vi kjennskap til fra før. Vi slapp dermed å bruke tid på å lære oss nye verktøy og kunne heller fokusere på å utvikle løsningen og jobbe med dokumentene til prosjektet. Verktøyene vi benyttet oss av under arbeidet med hovedprosjektet er: Skype. For møter over nett, da medlemmene av gruppa bor på forskjellige plasser, slapp vi å bruke unødvendig mye tid på reising. Dropbox. Til backup og deling av dokumenter innad i gruppa. Visual Studio. Til utvikling av løsningen. Team Foundation Server. For versjonskontroll av utviklingen. Microsoft SQL. For databaseløsningen. Google Docs. Ble brukt dersom flere arbeidet på det samme dokumentet samtidig. Facebooks hemmelige grupper. Ble brukt for å legge ut oppdateringer om prosjektet, og for å avtale møter internt i gruppa. MySQL Workbench. Ble brukt til design av databasemodellen SKYPE OG WINDOWS FJERNHJELP Vi valgte å bruke Skype når vi jobbet hver for oss. Dette er et utmerket verktøy for å snakke og skrive til hverandre. Verktøyet er gratis og det eneste man trenger er nettilgang. Det er også en funksjon for å se hverandres skjermer, men denne fungerte dårlig, og ga dårlig bildekvalitet. Vi valgte derfor å benytte oss av fjernhjelpen som er innebygd i Windows 7. I fjernhjelpen som følger med Windows 7 er det mulig å ta kontrollen over pcen til den man hjelper, og det er meget enkelt å bruke DROPBOX Dropbox ble brukt for lagring av alt som har med prosjektet å gjøre. Her lagret vi alle dokumenter, notater, bilder og lignende som ble brukt. Alt annet enn selve kildekoden ble lagret her. Dropbox fungerer også som versjonskontroll, da man kan gå tilbake til tidligere versjoner av et dokument. Det er ikke mulig at flere jobber på samme dokument, da blir det laget to versjoner av samme dokument og man må velge hvilket dokument man vil ta vare på. Dropbox er gratis om man kun vil ha 5gb lagring, dette holder i massevis for å lagre dokumenter så vi har ikke hatt noe behov for mer lagringsplass her VISUAL STUDIO, TEAM FOUNDATION OG MICROSOFT SQL Da vi til slutt valgte å utvikle systemet i ASP.net endte vi også opp med å bruke Visual Studio. Dette er et IDE som er til stor hjelp i programmeringen. ASP kan til tider være vanskelig da det veldig omfattende, men med Visual Studio får man god hjelp i og det gjør programmeringsbiten litt enklere. Team Foundation ble brukt for versjonskontroll for kildekoden, samtidig fungerer dette som backup da filene blir lagret på forskjellige steder. Versjonskontrollen fungerer slik at man må sjekke ut filer for å kunne bruke dem, da er det kun personen som har sjekket ut filene som som kan bruke dem.andre brukere kan se filene men ikke skrive til dem. Når man er ferdig med filene sjekker man de inn og da er filene tilgjengelig for andre brukere. For databasen brukte vi Microsoft SQL. Alle disse komponentene er laget for Side 7

8 hverandre, og fungerer meget godt sammen. Valgene ble derfor enkle da vi først hadde bestemt oss for å utvikle i ASP.net GOOGLE DOCS Vi brukte Google Docs dersom flere hadde behov for å skrive til de samme dokumentene samtidig. Google Docs fungerer relativt greit, men mangler selvfølgelig mange av funksjonene man finner i Microsoft Office. De dokumentene som ble skrevet av flere personer samtidig, ble først skrevet i Google Docs, før vi kopierte innholdet inn i et Word dokument og la til dokumentstilene FACEBOOK Alle avtaler innad i gruppen ble laget her. Vi benyttet oss av Facebooks hemmelige grupper, slik at kun gruppemedlemmene hadde tilgang til informasjonen publisert her. Dersom vi skulle bruke Skype til å arbeide sammen, avtalte vi dette på Facebook. Dette gjorde også skriving av dagbok enklere, dersom vi glemte å skrive ned hva vi gjode i dagboken kunne vi bare se igjennom hva som sto på veggen til Facebookgruppen vår. Denne løsningen fungerte meget godt, og det var enkelt for alle å følge med på hvilke planer gruppen hadde MYSQL WORKBENCH For å designe databasemodellen brukte vi MySQL Workbench. Dette er et program vi har brukt i tidligere prosjekter på skolen. Vi valgte å bruke dette programmet fordi vi har kjennskap til det, og fordi vi mener at vi får et bra resultat ut av det. Databasemodellen har hjulpet oss mye i underveis. Om vi har lurt på hva som henger sammen i databasen har vi bare tatt frem bildet av databasemodellen. 4.6 KOMMUNIKASJON MED OPPDRAGSGIVER I begynnelsen av prosjektet var kommunikasjonen med oppdragsgiver veldig god. Vi snakket med Kraft Foods om hva de ønsket seg av løsningen, og hva vi var i stand til å utvikle for dem. Vi utvekslet ideer og forslag om hvordan ting kunne løses. Det tok ikke lang tid før begge parter var enige om at en webløsning ville være det beste alternativet. Tilbakemeldinger på kravspesifikasjon var også god og vi fikk planlagt hva løsningen skulle inneholde. I startfasen av prosjektet var det som sagt god kommunikasjon. Etter hvert, og som skrevet tidligere i dette dokumentet, har ikke kommunikasjonen med oppdragsgiver vært av topp kvalitet. Vi ser i etterkant at vi kanskje burde ha tatt initiativ til flere møter med oppdragsgiver, slik at vi kunne ha lagt mer press på datainnsamlingsbiten. I prosjektdagboken går det klart frem at vi sendte mange purringer per mail angående forskjellige spørsmål som vi ikke hadde fått skikkelig svar på. Men på tross av dette fikk vi ikke noe svar. Konsekvensene av dette ble misforståelser og mye ekstra arbeid. Neste gang vi jobber med et prosjekt, kommer vi til å bruke lenger tid på planlegging av datainnsamling, slik at vi har et klart bilde av hvilke data vi trenger for å få oversikt over systemet. Men den eksisterende løsningen til Kraft Foods var komplisert, og vi forstod ikke helt i starten hva dette egentlig gikk ut på. Derfor gikk innsamlingen av data litt i rykk og napp, og ble kanskje ikke planlagt så godt som den burde. Dette er ting vi har tatt til ettertanke og som vi har fått mye lærdom fra. Det er viktig med bra kommunikasjon for å få en god flyt i prosjektprosessen. Vi føler at denne flyten helt klart ville blitt bedre dersom kommunikasjonen med opdragsgiver hadde vært bedre. 4.7 METODE I begynnelsen av prosjektet planla vi å jobbe etter Scrum-modellen. Denne er spesielt godt egnet for å utvikle komplekse systemer, akkurat som vårt Ruteplanleggingssystem. Modellen baserer seg på faser på alt ifra en uke, og helt opp til en måned - kalt en Sprint. I forkant av en Sprint plukkes noen av funksjonene som skal implementeres ut fra en Side 8

9 liste over gjeldende krav til prosjektet, kalt en Product backlog (Produktkø). Listen som plukkes ut, og som skal implementeres i løpet av en Sprint kalles Sprint blacklog (Sprintkø). Under gjennomføringen av prosjektet skal det holdes daglige møter med Scrum Master hvor alle som er med i teamet skal delta. Møtet skal være kort (rundt et kvarter), og i løpet av dette møtet skal alle medlemmene av teamet gi uttrykk for tre forhold: Hva er gjort siden forrige scrum møte? Hva skal gjøres før neste møte? Hva har (eventuelt) vært til hinder for at gruppemedlemmet var effektiv i implementeringen av funksjonalitet? Denne metoden var veldig godt egnet til vårt prosjekt, men vi var avhengige av regelmessige møter med oppdragsgiver. Kraft Foods hadde ikke ressurser nok til å kunne gi oss disse møtene, som burde blitt holdt en gang i uka. I perioder kunne det gå opptil flere uker før vi fikk svar på våre henvendelser. En løsning på dette problemet kunne vært å simulere kunden disse ukene, men på grunn av at det ble såpass få uker vi faktisk fikk avholdt et møte med de, så vi oss nødt til å forkaste denne metoden. Dette førte blandt annet til et tilbakesteg i utviklingen vår. Vi var nødt til å legge om strategien for prosjektet, og vi var blitt holdt igjen på grunnlag av mangelfull informasjon fra oppdragsgiver. Dermed så vi oss nødt til å benytte fossefallsmodellen. Denne modellen er absolutt ikke ideel for vårt prosjekt, som er et såpass stort og komplekst system. Men på grunn av omstendighetene med lite informasjon fra oppdragsgiver, og mye tid gått bort til å vente på svar, endte vi opp med denne modellen. Fossefallsmodellen gjennomføres i distinkte faser, hvor resultatet av hver fase danner grunnlag for arbeidet i kommende fase, samt grunnlag for beslutninger som omhandler prosjektets fremdrift. Hver fase er klart definert med både hensikt og arbeidsmessig fokus. De ulike fasene i fossefallsmetoden er forstudie, analyse, design og programmering, innføring og forvaltning. Forstudie går ut på å definere prosjektmålet, hva som skal gjøres i prosjektet. Hva bakgrunnen for at prosjektet ble satt igang er. Her definerer vi også rammebetingelsene for prosjektet, samt om prosjektet kommer til å møte spesielle utfordringer. Gruppemedlemmene får også tildelt ansvarsroller i denne perioden. En må ta det overordnede ansvaret og styre gruppen som en gruppeleder. En må stå ansvarlig for at brukergrensesnittet lever opp til forventningene, en må stå ansvarlig for at den funksjonaliteten som vi har lovet blir levert, og en må være ansvarlig for at all nædvendig dokumentasjon blir skrevet. Å ha en av rollene vil ikke si at det kun er det gruppemedlemmet som skal jobbe med den gitte oppgaven, men det er dette gruppemedlemmet som har ansvaret for at det blir gjort. I analysen skal det beskrives i detalj hva slags system som skal lages. Her skal det bestemmes hva systemet skal gjøre, hvordan det skal se ut, og hvordan det skal virke. Dette blir gjort igjennom kravspesifikasjonen vi skrev tidlig i prosjektet. Kravspesifikasjonen ble vist til oppdragsgiver i denne fasen, hvor vi opplyste dem om funksjonaliteten vi skulle legge til rette for på en slik måte at de forstod hva som skulle bli gjort. I design og programmeringsfasen definerte vi først mal på hvordan alle sidene skulle se ut. Her satte vi opp vanlige designelementer som går igjen på de fleste sidene som logo, hovedmeny, overskrifter, tabeller og lignende. Etter dette begynte vi å programmere grunnstrukturen i systemet. Dette innebar blandt annet Masterpagen (den ytre delen av applikasjonen som inneholder logo, hovedmeny, og avgrensningen til inneholdet). Funksjonalitet for å logge inn på siden, samt avgrensede områder for brukere som er logget inn, og de ulike brukergruppene. Og å sette elementene som ble definert under designutviklingen i live ved hjelp av HTML-attributter og Stilark (css). Innføringsfasen er fasen hvor vi overfører det vi har laget til oppdragsgiver. For vårt system kan vi si at målet for denne fasen er å sette systemet i daglig drift hos Kraft Foods på en slik måte at: Brukerne kan systemet Side 9

10 Brukerne stoler på systemet Brukerne har nytte av sytemet For at vi skal kunne infri disse målene må selvfølgelig riktig system utvikles, med riktig funksjonalitet uten feil og mangler. På grunn av at vi kom såpass sent igang med prosjektet, så vi oss nødt til å kutte ut noen av tilleggsønskene til Kraft Foods for å få systemet ferdig i tide. Her vil vi også gjennomføre en brukeropplæring på systemet, samt gjennomføre en fullstendig installasjon og import av nødvendig data / programvare på deres servere (Her inngår da programvaren for å kunne lese fra excel-filer, samt importere post-tabellen fra posten.no inn i deres database). Forvaltningsfasen går ut på at vi i tillegg til å levere det ferdige systemet til Kraft Foods, også legger ved tilstrekkelig dokumentasjon til at systemet kan holdes igang lenge etter at vi er ferdige. Denne dokumentasjonen skal blant annet bidra til at systemet vi har implementert brukes på riktig måte, og oppfører seg korrekt, uten feil og mangler. Derfor inneholder denne dokumentasjonen informasjon som er nødvendig for å kunne bruke systemet, vedlikeholde systemet og for å kunne holde det i daglig drift. Dokumentasjonen er skrevet på en slik måte at målgruppen forstår det som er skrevet. Det vi leverer til Kraft Foods av dokumentasjon er en brukermanual som inneholder brukerdokumentasjonen ment for brukerne av systemet. Her blir all funksjonaliteten beskrevet, som hvordan man setter opp ruter, hvordan man viser ruter, hvordan man legger til nye brukere, hvordan man endrer frekvensene på butikker og lignende. Vi leverer også en produktdokumentasjon som inneholder både informasjon for daglig drift av systemet, og systemdokumentasjon for å vedlikeholde og eventuelt videreutvikle systemet i senere tid. Side 10

11 5 UTVIKLINGSPROSESSEN 5.1 PROSJEKTETS FASER Vi har vært igjennom flere faser under utviklingen av løsningen. Vi vil her gå igjennom de forskjellige fasene i prosjektet GRUPPEDANNELSE OG VALG AV OPPGAVE Alle gruppemedlemmene har arbeidet mye sammen i prosjekter og forskjellige fag fra før. Alle studerer også informasjonsteknologi og går i samme klasse. Dette vil si at vi kjenner hverandres styrker og svakheter godt, og vi visste dermed at samarbeidet i gruppa ville fungere bra. Da vi skulle velge oppgave så vi først igjennom forslagene fra skolen, men ingen av disse falt helt i smak. Vi var også ivrige etter å finne noe på egenhånd, slik at vi kanskje kunne skaffe oss noen referanser til senere bruk. Vi var veldig tidlig klar over at Kraft Foods hadde en mulig oppgave for oss, men vi var usikre på omfanget og trodde kanskje at oppgaven var litt liten. Etter første møte med Kraft Foods forsto vi raskt at oppgaven var veldig omfattende og et bra utgangspunkt for en hovedprosjektoppgave. Dermed valgte vi å arbeide med Kraft Foods om Ruteplanleggingssystemet som i hovedsak skulle brukes av regionssjefene. Vi ble også tildelt en intern veileder fra Høgskolen I Oslo, Alexander Yngling. Vi hadde første møte med han i midten av januar Vår kontaktperson i Kraft Foods var først Jarle Birkeli, men ble senere erstattet av Bjart Pedersen. Dette passet oss veldig bra, da det var Bjart som for over 4 år siden hadde utviklet løsningen med excel-arkene STARTFASE INNLEDENDE ARBEID Det første vi gjorde rent praktisk, etter at vi hadde dannet gruppe og funnet en oppgave, var å sette sammen en prosjekthjemmeside. Denne ble lagt på en av gruppemedlemmenes private domener. Deretter laget vi statusrapporten og en prosjektskisse som ble lagt ut på prosjekthjemmesiden i god tid før fristene gikk ut. Det ble også opprettet en dagbok som vi delte via dropbox. I denne skrev vi ned alt arbeid vi gjorde dag for dag, med dato, klokkeslett og personer som deltok. Statusrapporten og prosjektskissen ble også utarbeidet og levert. Dette ble gjort i startfasen: Prosjektdagbok Tildelt veileder Prosjekthjemmeside Statusrapport Prosjektskisse FORPROSJEKTFASE Under forprosjektet fikk vi innblikk i hvem som skulle bruke løsningen. Det viste seg at mange av brukerne ikke var spesielt datakyndige. Vi forsto derfor med en gang at brukervennlighet kom til å bli viktig. Brukerne av løsningen vil, i tillegg til regionssjefene i Krafts Foods, være ca 50 selgere og ca 120 salgsfremmere, alle med ulike datakunnskaper. Dermed kunne vi dra nytte av faget Menneske Maskin og Interaksjon som alle på gruppa har gjennomført. Vi diskuterte frem og tilbake om løsningen skulle være webbasert eller om den skulle være i form av en lokalt kjørende applikasjon. I diskusjon med oppdragsgiver kom vi frem til at en webapplikasjon uten tvil ville være det enkleste. Med tanke på at det vil være i underkant 200 brukere spredd rundt i hele Norge, vil det være tungvindt å installere et program for hver bruker. Med løsningen vi har kommet frem til trenger brukerne kun en nettleser på en datamaskin, og Side 11

12 et brukernavn med tilhørende passord. Dermed kan løsningen bli brukt omtrent overalt, avhengig av om dette kjører på Kraft Foods intranett eller om det blir lagt på en ekstern webserver tilgjengelig via internett. Oppdragsgiver hadde på dette tidspunktet ikke funnet ut hvilket programmeringsspråk vi kunne benytte. Derfor antok vi i forprosjektet at vi kom til å måtte skrive løsningen i PHP (PHP: Hypertext Preprocessor) og MySQL. Vi hadde fortalt oppdragsgiver at vi gjerne ville bruke ASP (Active Server Pages) eller JSP (Java Server Pages), da disse løsningene ofte blir mer oversiktelige. Vi kom frem til at vi kunne bruke ASP etter at forprosjektet var ferdig. Vi kom frem til i samarbeid med oppdragsgiver at systemet bør inneholde følgende: Mulighet for selgere og fremmere å hente rute- og kundeinformasjon. Mulighet for regionssjefene å administrere ruter, og organisere selgere og fremmere. Et grensesnitt for regionssjefene til å hente ut ulike rapporter. Mulighet for administrator å endre, slette, og legge til nye kunder. Det ble også nevnt fra oppdragsgiver at det kunne være ønskelig med ett eget GUI for mobile løsninger i fremtiden. Vi ble enige om at dette kunne implementeres hvis vi hadde tid, og at dette derfor ikke ville være i fokus. Møtene med oppdrasgiver i forprosjektfasen første til at vi fikk signert standaravtalen fra skolen. Dette er en avtale som formelt sett er mellom Høgskolen I Oslo og oppdragsgiver. Vi lagde en arbeidsplan med de forskjellige fasene i prosjektet. I dette dokumentet ble det utarbeidet grove tidsfrister for når de forskjellige fasene i prosjektet skulle være ferdig. Utifra arbeidsplanen lagde vi en fremdriftsplan med realistiske mål for når de forskjellige oppgavene i prosjektet skulle være ferdig. Alt arbeidet i forprosjektfasen førte til forprosjektrapporten. Dette dokumentet inneholder bland annet mål for prosjektet, rammebetingelser, forskjellige løsninger på oppgaven og en kort analyse av dette. Dette ble gjort i forprosjektfasen: Arbeidsplan Framdriftsplan Standaravtale Forprosjektrapport PLANLEGGINGSFASEN Det ble gjort en del planlegging i forhold til gruppemedlemmer og oppgavevalg helt i starten av prosjektet. Dette gikk i hovedsak ut på hvordan prosjektet i grove trekk skulle gjennomføres. I denne fasen hadde vi noen møter med oppdragsgiver, i tillegg ble det kommunisert mye via mail. Vi fant ut hvilke brukergrupper løsningen hadde behov for, og hvilke rettigheter disse skulle ha. Det ble i tillegg planlagt en rekke krav til systemet som la grunnlaget for kravspesifikasjonen. De viktigste kravene handlet om brukere, importering av database, funksjonalitet for regionssjefene, serverkrav, serverkapasitet og brukervennlighet. Side 12

13 Vi planla så godt det lot seg gjøre hvordan databaseoppbyggingen skulle se ut. Arbeidet med databasen tok lang tid, og datamodellen ble bygget opp flere ganger. Dette var på grunn av at det hele tiden dukket opp nye elementer fra oppdragsgiver som førte til at datamodellen ikke ville fungere. Det ble etterhvert laget et utkast til brukergrensesnittet som ble presentert for oppdragsgiver. Dette utkastet ble tatt godt imot, og kun noen små endringer ble gjort. Brukergrensesnittet ble laget relativt raskt i Photoshop, det vil si at vi kun viste frem bilder av hvordan løsningen ville se ut. Dette ble gjort i planleggingsfasen: Kravspesifikasjon Brukergrensesnitt Database UTVIKLINGSFASEN Som tidligere nevnt hadde vi en del kommunikasjonsproblemer i starten av prosjektet. Dette førte til at vi kom litt sent i gang med utviklingen. Men vi løste det ved at vi arbeidet hver for oss, mens vi pratet med hverandre over skype. Dersom noen trengte hjelp av de andre på gruppa bruke vi fjernhjelp som er innebygget i Windows til dette. Vi løste dette slik fordi gruppemedlemmene bor ett stykke fra hverandre, og vi slipper dermed å bruke tid på å reise. Selv om mesteparten av arbeidet ble gjort over skype, hadde vi også flere møter der alle på gruppa var samlet. Under disse møtene diskuterte vi forskjellige ting som design, brukergrensesnitt, og hvordan vi kunne løse vanskelige problemer. Under denne fasen arbeidet vi med kodingen av ruteplanleggingsverktøyet, og vi følte at i kunne konsentrere oss bedre dersom vi fikk sitte for oss selv i fred og ro TESTFASEN I testfasen fokuserte vi på å teste metoder og funksjonalitet i systemet ved hjelp av forskjellige forskjellige testmetoder. Vi begynte testingen tidlig i utviklingsprosessen, med testing av data access laget som inneholdt metoder som hentet/endret data fra databasen ved hjelp av LINQ-to-SQL. Denne testmetoden kalles white-box testing, hvor man bruker kjennskap til koden for å kjøre testene. Vi testet også brukergrensesnittet i en viss grad hos oppdragsgiver tidlig i utviklingsprosessen. Oppdragsgiver fikk se forskjellige skjermbilder av det planlagte brukergrensesnittet, og ga stort sett bare positive tilbakemeldinger, men allikevel var det noen småting som de ønsket å endre på, for eksempel hvilke menyvalg hver brukergruppe skulle ha tilgang til. Senere i utviklingsprosessen, da de fleste metodene i data access laget var ferdig laget og testet, tok vi for oss testing av presentasjonslaget. Her brukte vi såkalt black-box testing, hvor vi matet systemet med testdata for å sjekke hvilken tilbakemelding vi fikk. Validering av inputfelter, for eksempel at man prøver å sende inn en bokstav i et felt hvor bare tall er tillatt er et eksempel på denne testingen. Da får man skrevet ut en beskrivende feilmelding DOKUMENTASJONSFASEN Side 13

14 Denne fasen foregikk under hele prosjektet og handler om alle dokumenter som ble skrevet. I dokumentene finner man informasjon om alt fra valg av oppgave til ferdig utviklet produkt STYRINGSDOKUMENTER Med unntak av prosjektdagboken ble alle styringsdokumentene skrevet tidlig i prosjektet, denne ble skrevet fra start til slutt. I styringsdokumentasjonen inngår følgende dokumenter: Use case Use case hendelser Arbeidsplan Dagbok Forprosjekt Fremdriftsplan Gantt diagram Kravspesifikasjon Prosjektavtale Prosjektskisse Statusrapport SLUTTDOKUMENTASJON Vi startet med å skrive prosessdokumentasjonen. Denne tar for seg alle prosessene i prosjektet, fra idé til ferdig produkt. I og med at man går igjennom hele prosjektet når man skal skrive dette dokumentet, fikk vi en repetisjon og et godt overblikk over alt vi hadde gjort. Dette hjalp oss når vi skulle skrive produktdokumentasjonen fordi vi da viste i detalj hvilke prosesser vi hadde vært igjennom, og hvordan vi hadde jobbet med disse. Produktdokumentasjonen er beregnet på den teknisk ansvarlige som skal installere, vedelikeholde og modifisere systemet. Dette er en person som ikke har vært med under utviklingen av produktet og det vil dermed være meget viktig at det er beskrevet i detalj alt fra hvordan systemet er laget, til hvordan det kan videreutvikles. Det er også beskrevet hvordan systemet skal installeres, og hvilke krav som stilles til server. Dokumentet kan også være nyttig for de som eventuelt skal drive brukersupport. Brukerdokumentasjonen er beregnet på de som skal bruke systemet. Dette skal fungere som en bruksanvising, og skal beskrive hvordan man benytter seg av systemets funksjonalitet. I brukerdokumentasjonen har vi skrevet om hvilke funksjoner de ulike brukergruppene har, og hvordan de skal bruke disse funksjonene. I sluttdokumentasjon ingår følgende dokumenter: Prosessdokumentasjon Produktdokumentasjon Brukerdokumentasjon Side 14

15 5.1.9 AVSLUTNINGSFASEN Dokumentasjonen ble nedprioritert mot slutten av prosjkektet til fordel for utviklingsfasen, da vi fikk dårlig tid mot slutten. Derfor ble ca 40% av all dokumentasjon skrevet de siste 4 dagene før deadline for trykking 25. mai. Dokumentasjonen kan bære preg av dette, men alle gruppemedlemmene har jobbet på spreng for at dokumentasjonen skal holde en høy standard allikevel. Dokumentene er gjennomgått for skrivefeil, og disposisjon i rapporten er endret flere ganger for å få satt opp dokumentene i riktig rekkefølge. Dokumentene måtte også endres stilmessig, overskrifter, fonter og skriftstørrelser ble samordnet slik at dokumentene skulle se like ut. Deretter ble alle dokumentene gjort klare for levering. Vi har dessverre ikke fått implementert systemet hos oppdragsgiveren i skrivende stund. Dette er fordi utviklingsfasen kom for tett opptil deadline for prosjektrapporten. Vi må også nevne at vi var på møte hos Kraft Foods i midten av april, og da avtalte vi hva slags server oppdragsgiver måtte skaffe. På møtet vi hadde med de 23. mai hadde de enda ikke ordnet server, så det er ikke klart for implementering. Vi håper de får ordnet dette innen presentasjonen skal holdes 15. juni, slik at vi kan melde at systemet er implementert og tatt i bruk. 5.2 VALG OM OPPBYGNING OG FUNKSJONER LAGDELINGSPRINSIPP Som sagt kom vi frem til at vi skulle bruke ASP og Visual Stuido. For å få en mest mulig ryddig kode som kan vidreutvikles er det viktig å bruke ett lagdelingsprinspp. Vi hadde i begynnelsen tenkt til å bruke Model Veiw Controller (MVC). Dette er et lagdelingsprinsipp som er innebygd i Visual Studio, men siden ingen av oss hadde brukt dette før tok det for lang tid å lære dette. Vi endte dermed opp å bruke en litt mer manuell løsning, som inneholder Model, Data Access Layer (DAL) og et presentasjonslag. Dette er en metode vi har brukt før i tidligere prosjekter, som vi lærte i.net kurset, og derfor slapp vi å bruke tid på å lære oss noe nytt. Dette er en litt mer tungvindt løsning i forhold til MVC, men vi kom frem til at vi ville spare tid på å bruke ett prinsipp som vi allerede kunne. Som nevnt tidligere var vi allerede godt på etterskudd da vi begynte kodingen. Dermed prioriterte vi å komme i gang så fort som mulig, fremfor å lære oss et nytt lagdelingsprinsipp. Grunnen til at vi ikke tenkte på lagdelingsprinsipp før vi begynte med kodingen, var at vi ikke visste hvilket programmeringsspråk vi skulle bruke. Og lagdelingen vil bli noe forskjellig i forskjellige programmeringsspråk. Uansett påvirker ikke lagdelignen sluttproduktet, kun måten vi arbeider på. 5.3 PROBLEMER OG LØSNINGER Under prosjektet støtte vi på noen problemer. Under har vi skrevet ned de største problemene som oppsto SAMARBEID MED OPPDRAGSGIVER Det var som sagt noen kommunikasjonsproblemer med oppdragsgiver i starten av prosjeketet. Dette gjorde at vi tapte en del tid som skulle blitt brukt på utvikling av løsningen. Etterhvert fikk vi ny kontaktperson hos oppdragsgiver og kommunikasjonsproblemene løste seg. Vi fikk uansett god nok tid til utviklingen, men vår avtale med oppdragsgiver om å levere prosjektet innen 1. mai ble ikke holdt. Dette var ikke et stort problem for hverken oppdragsgiver eller prosjektgruppen, men vi fikk ikke like god tid på dokumentasjon og testing som vi hadde ønsket PROGRAMMERINGSSPRÅK Side 15

16 Det var i starten uklart hvilket programmeringsspråk vi kom til å benytte. Vi hadde valgt oss tre alternativer: PHP, ASP eller JSP. Oppdragsgiver var ikke sikker på hva slags server løsningen kom til å kjøre på. Derfor måtte de finne ut av det før vi avgjorde hvilket programmeringsspråk som ville bli brukt LAGDELING Vi hadde i utgangspunktet tenkt til å bruke Model View Controller (MVC), men da vi prøvde å sette opp dette i Visual Studio støtte vi på en del problemer. Løsningen på dette ble å forkaste MVC og gå over til en lignende løsning, som vi hadde lært i.net kurset i fjor. Istedet for å inneholde Model, View og Controller som MVC gjør, inneholder vår løsning nesten det samme (vi vet ikke navnet på denne løsningen, men det var en løsning vi lærte i foregående kurs, og den er bygget på samme prinsippet som MVC). Model inneholder samme som Model i MVC, DAL inneholder samme som Controller i MVC, og presentasjonslaget vårt inneholder det samme som View i MVC. Som vist er det bygget på samme prinsippet, men det er allikevel noen små forskjeller fra standard MVC NETTILGANG Helt i slutten av utviklingsfasen fikk et gruppemedlem problemer med internettilgangen hjemme. Dette var i forbindelse med oppgradering fra ADSL til VDSL. Gruppearbeidet har i hovedsak foregått over Skype, og vi har koblet oss til skolen via VPN for å kunne bruke Team Foundation serveren. Vi prøvde å løse nettproblemet via 3G tilkobling, men dette fungerte dårlig sammen med skolens VPN. Derfor måtte vi en periode samles hos en av gruppemedlemmene for at alle skulle kunne jobbe på prosjektet samtidig. Dette førte til at det ble litt mindre fleksibilitet i arbeidet, men det løste seg heldigvis ganske fort DATAMODELLEN Det var en del problemer under designet av datamodellen. For det første tok det lang tid før vi fikk en god oversikt over det gamle systemets datamodell, samt datamodellen fra AraWin som er databasen vi skal importere data fra. Dette gjorde at flere utkast til databasemodellen ble forkastet og mye arbeid ble dermed bortkastet. Det kom også en del ny informasjon underveis fra oppdragsgiver som første til endringer av modellen. Vi endte opp med å ha møte med oppdragsgiver, der vi ble enige om en absolutt siste frist for endringer slik at vi slapp flere tidkrevende inngrep. For å vise hva som er gjort på nytt har vi lagt med første utkast av datamodellen (se vedlegg Datamodell første utkast ) AJAX-POPUP I starten av prosjektet ble vi enige med arbeidsgiver om å bruke så mye smarte løsninger som mulig. Arbeidsgiveren hadde vel ikke så stor innsikt i hva dette egentlig betød, men gruppemeldemmene så for seg mye Ajax og JavaScript. Den største smarte løsningen vi hadde planer om å bruke var en Ajax-popup som inneholdt all informasjon om en butikk. Tanken var at når man så på en ruteoversikt og klikket på en butikk, fikk man opp ett vindu uten at siden lastet på nytt. Vinduet skulle legge seg oppå ruteoversikten og vise informasjonen direkte. Ett av gruppemedlemmene har litt mer greie på Ajax enn de andre, derfor fikk han i oppgave å lage denne løsningen. Løsningen ble laget fungerende, og data ble hentet ut fra databasen, men vi fikk ikke til å lagre endringene som skulle gjøres med dataene. Grunnen til at Side 16

17 dette ikke fungerte som planlagt er at ASP bruker en såkalt HTML-form for å sende informasjon imellom sidene, og når det da dukket opp en ny form inne i en annen form i HTML-koden, overskrev de hverandre. Dette førte til at vi fikk en Javascript-feilmelding. Vi kunne heller ikke droppe denne formen i den nye siden som ble inkludert, da dette ville føre til at ASP og C# koden ikke ville bli utført. Derfor måtte vi etter mye prøving og feiling innse at denne løsningen måtte fjernes og erstattes med en standard ASP.NET side. All denne jobbingen med ajax-popupen tok utrolig mye tid og krefter hos gruppemeldlemmene, og det er veldig synd at vi ikke klarte å få til en fungerende løsning på dette. Side 17

18 6 KRAVSPESIFIKASJONEN OG DENS ROLLE I PROSJEKTET 6.1 ENDRINGER I KRAVSPESIFIKASJONEN Det er ikke blitt utført noen betydelige endringer i kravspesifikasjoner underveis i prosjektet. Rammebetingelsene ble såpass klart definert i startfasen, slik at vi ikke ble nødt til å endringer på kravspesifikasjonen. Det har allikevel kommet endel ønsker og innspill fra oppdragsgiver, som har ført til noe ekstra funksjonalitet, samt større endringer i datamodellen. 6.2 KRAVSPESIFIKASJON I FORHOLD TIL DESIGN OG IMPLEMENTERING Vi satt ingen klare retningslinjer for design i kravspesifikasjonen. Hovedpunktene rundt brukergrensesnitt sier at vi skal bruke ajax-løsninger og drop-down menyer og lignende. Og dette har vi gjort der det er hensiktsmessig. Kraft Foods hadde ingen store krav til brukergrensesnitt utover dette, derfor har vi fått arbeide slik vi selv ønsker på dette punktet. Vi synes allikevel at sluttproduktet holder en god standard når det gjelder brukergrensesnitt. Begrunnelsen for denne påstanden er at systemet er gjennomført med tydelige knapper, linker, kontraster og lite forstyrrende elementer for brukeren. 6.3 SAMSVAR MELLOM KRAVSPESIFIKASJON OG DET FERDIGE PRODUKTET Dette punktet er nøye gjennomgått i produktdokumentasjonen. Derfor henviser vi til hovedpunkt 8 i Produktdokumentasjonen for detaljert beskrivelse av samsvar mellom kravspesifikasjon og ferdit produkt. Kort oppsummert samsvarer sluttproduktet godt med kravspesifikasjonen. Noen punkter har fått en litt annen løsning enn forventet, men det betyr ikke nødvendigvis at det er noen dårligere løsning. Vi har på et par punkter valgt en enklere utvei grunnet dårlig tid, men i hovedsak er alle endringer fra kravspesifikasjonen gjort da vi mener alternativet er en bedre løsning på problemstillingen. Side 18

19 7 OM RESULTATET Vi er veldig fornøyde med resultatet av vårt hovedprosjekt, da vi mener vi har klart å oppfylle kravene som oppdragsgiver hadde godkjent til systemet på en tilfredsstillende måte. Vi ser samtidig at det er store videreutviklingsog forbedringsmuligheter i systemet, slik at systemet kan bli enda bedre. Hadde vi hatt bedre tid i avslutningsfasen skulle vi helt klart ha gjort en del ting annerledes, men vi har klart å levere et komplett produkt og må se oss fornøyd med det. Noen punkter for funksjonalitet som oppdragsgiver kom med ønske om etter at siste kravspekk var ferdig, men som vi desverre ikke fikk tid til å gjennomføre er: Eget brukergrensesnitt for mobiltelefon, slik at man kan se sin egen rute via mobilen Mulighet til å vise ruta på et kart Utskrifter av forskjellige lister og rapporter i systemet Tilslutt mener vi at systemet har nådd målene som ble satt for en første versjon av dette produktet. Side 19

20 8 TILBAKEBLIKK Vi føler at vi har fått veldig mye ut av dette prosjektet. Vi har lært mye om blant annet databaser, LINQ-to-SQL, asp.net og hvordan vi sammen kan jobbe effektivt på et større prosjekt uten at vi mister oversikten over de forskjellige delene ved hjelp av Visual Studio og Team Foundation Server. Prosjektet har også vært en spennende utfordring, hvor vi har fått muligheten til å vise at vi kan mestre å lage et meningsfylt produkt til en oppdragsgiver vi ikke var kjent med fra før. Vi har hatt en del kommunikasjonsproblemer med oppdragsgiver, noe som blir nevnt flere steder i prosjektrapporten. Dette førte til unødvendig lite tid i slutten av prosjektfasen, tid som vi kunne brukt til å forbedre det ferdige produktet og til å teste systemet eksternt hos oppdragsgiver. Vi har fått testet alt vi har kunnet fått teste internt, men skulle gjerne latt oppdragsgiver testet systemet noen uker, da det som regel dukker opp noe først når sluttbrukeren begynner å bruke systemet. Når det gjelder prosessen med utvikling av de ulike dokumentasjonsdelene, starter vi tidlig med produsering av dokumenter. Vi ønsket å fordele dette over en lengre periode, slik at ikke all dokumentasjonen måtte bli skrevet mot slutten av prosjektet. Dette klarte vi å følge ganske bra helt til programmeringsfasen begynte. Programmeringen tok overhånd på grunn av lite tid, derfor ble endel dokumentasjonsskriving i sluttfasen. Dette er ting vi føler at vi ikke fikk gjort så mye med, og vi har ikke hatt mer enn et par dager på å revidere og sluttstille prosjektrapporten før innlevering. Når vi ser tilbake på kommunikasjonsproblemene underveis i prosjektet, burde vi nok mast litt mer på oppdragsgiver for å få den informasjonen vi trengte, spesielt under datainnsamlingsfasen. Det er i hovedsak dette som førte til at vi fikk såpass lite tid på slutten da vi hele tiden underveis måtte gjøre store endringer i blant annet datamodellen på grunn av misforståelser. Dette har vi tatt stor lærdom av, og kommer til å ta med videre i prosjekter senere i arbeidslivet. Side 20

21 10 KILDEREFERANSER 10.1 NETTSIDER Wikipedia - Scrum (12.mai.2011). Hentet fra Høgskolen i Sør-Trøndelag (u.å). Maler og standarder [Fossefallsmdellen]. Hentet fra Metode - Scrum: Metode - Fossefallsmetoden: Skype og Windows fjernhjelp - Skype: Windows fjernhjelp: Dropbox: Visual Studio, team Foundation og Microsoft SQL: MSDN via skoeln + skolens servere Google Docs: Facebook: MySQL Workbench: Side 21

22 9 VEDLEGG 9.1 DATAMODELL FØRSTE UTKAST Den nåværende løsningen i excel inneholder 5 ark i selgertabellen ( Ansatt info, Oppsummering, Butikkinfo, Butikkinfo HZ og Snitt tid pr besøk ), og 5 ark i fremmeretabellen ( Initialer, Arawintall, Butikkinfo, Blank rute og Ansatt info). Selgertabell Ansatt info Fremmeretabell Ansatt info Side 22

23 Fremmeretabell Initialer Kraft foods bruker for tiden to uavhengige excel-ark for å føre ansattinformasjon om selgerne og fremmerne sine ( Fremmerne jobber for selgerne ). Vi har sett på denne løsningen, og funnet ut at det lagres mye av den samme informasjonen for både fremmere og selgere, og velger derfor å slå disse sammen til en Ansatt-tabell. Nåværende løsning er bygget på at fremmernummeret og selgernummeret starter med regionstilhørigheten, for deretter å inneholde et unikt nummer. Dette bryter med første normalform ved at verdien ikke er atomær. Vi har kommet frem til følgende tabell for å løse dette problemet. Ansattetabellen Beskrivelse av feltene: id dette er primærnøkkelen i tabellen. Vi har valgt denne løsningen istede for selger/fremmernummeret som brukt tidligere, fordi dette ville skapt problemer i tabellen da formatet på disse er forskjellig. Region_*id Dette er id en som indikerer hvilken region den ansatte tilhører. Denne variabelen blir hentet fra Regionstabellen. fornavn Fornavnet til den ansatte. etternavn Etternavnet til den ansatte. Brukergruppe_*id Dette er id en som indikerer hvilken brukergruppe den ansatte tilhører. Denne variabelen blir hentet fra Brukergruppetabellen. telefonnummer Den ansattes telefonnummer. epost Den ansattes epost (må ikke fylles ut). initialer Den ansattes initialer (hentes ut ifra fornavn og etternavn via egen funksjon). brukernavn Felt for brukernavn til systemet for den ansatte. passord Felt for passord til systemet for den ansatte. selgerhz Felt kun for selgere. Sier om det er en HZ-selger eller ikke (0 = nei, 1 = ja) HZ = Hot Zone. Fremmeretabellen Vi har laget en fremmertabell som inneholder informasjon kun for fremmere. Denne tabellen kobler samtidig fremmeren til selgeren. Side 23

24 Beskrivelse av feltene: Ansatt_*id Dette er id en hentet fra ansatt-tabellen til selgeren. Ansatt_*id1 Dette er id en hentet fra ansatt-tabellen til fremmeren. stillingprosent Dette er stillingsprosenten til fremmeren (sier om han har en 50% stilling, 80% stilling osv.). kommentar Evt. Kommentarer. Fremmeretabell / Selgeretabell Butikkinfo 1 av 2 Fremmeretabell / Selgertabell Butikkinfo 2 av 2 Kraft foods bruker denne løsningen i excel-arkene sine (både for fremmere og selgere), og dette forårsaker mye dobbeltlagring. For eksempel blir selgernavnet og kundenavnet repetert mange ganger, og det ligger samme informasjon i begge arkene. Siden informasjonen er lik, fant vi det best å slå disse sammen for en felles løsning. Utifra informasjonen over har vi kommet opp med følgende tabeller: Butikktabellen Følgende tabell viser informasjonen om de ulike butikkene Beskrivelse av feltene: *knr Kundenummeret til de ulike butikkene. Dette er primærnøkkelen i tabellen. kundenavn Kundenavnet. F.eks (Coop Obs Bjerke, Meny Oslo City, osv). Side 24

25 Region_*id Id en til regionen butikken tilhører. Adresse Adressen til kunden. Post_*postNr Postnummeret til kunden. Dette er fremmednøkkel, og er koblet til tabellen Post hvor vi henter ut poststed. Grossist:*grossistId id en til grossisten. Dette er en fremmednøkkel som er koblet til tabellen Grossist. Profil_*profilId id en til profilen. F.eks (Kiwi, Coop Mega,osv). Besøksfrekvens Dette er et tall som sier hvor ofte butikken besøkes i uka (1,0 = en gang i uka, 0,5 = annenhver uke, osv). tidibutikkperbesøk Antatt tid brukt i butikken (i minutter). Grossisttabellen Følgende tabell viser oversikt over alle grossistene. Beskrivelse av feltene: *grossistid Id en til de forskjellige grossistene. Navn Grossistnavnet. Kjede_*kjedeId Id en til kjeden grossisten er koblet til. Dette er en fremmednøkkel som er koblet til Kjedetabellen. Kjedetabellen Tabell som viser en oversikt over alle kjedene. Beskrivelse av feltene: *kjedeid Id en til kjeden. Navn Navnet til kjeden. Profiltabellen Tabell som viser en oversikt over alle profilene i systemet. Beskrivelse av feltene: *profilid Id en til profilen. Navn Navnet til profilen. Kjede_*kjedeId Fremmednøkkel som kobler profilen til kjeden. Denne er hentet fra Kjedetabellen. Posttabellen Posttabellen som er en oversikt over alle postnummer og poststeder i norge (hentes direkte og lastes ned fra posten.no). Side 25

26 Beskrivelse av feltene: *postnr Postnummeret. Fungerer som primærnøkkel og er unik for alle instansene i tabellen. Poststed Poststedet postnummeret tilhører. Fylke Fylket postnummeret tilhører. I tillegg så vi oss nødt til å opprette endel andre tabeller for å kunne følge alle normalformer, og for å lage en riktig databasemodell. Følgende tabeller er blitt opprettet i tillegg: SelgerButikk Dette er en tabell som kobler de ulike butikken til hver enkelt selger (hvilken butikk selgeren har ansvaret for), samt hvis selgeren eventuelt har en fremmer i denne butikken. Beskrivelse av feltene: Butikk_*kNr Kundenummeret til butikken. Dette er en del av primærnøkkelen. Ansatt_*id Id en til selgeren som har ansvaret for butikken. Dette er en del av primærnøkkelen. Ansatt_*id1 Hvis selgeren eventuelt har en fremmer på denne butikken, er dette id en til denne fremmeren. Regiontabellen Dette er en tabell som holder oversikt over de ulike regionene Kraft Foods opererer med, samt navnet på disse. Beskrivelse av feltene: *id Dette er regions iden. Denne blir brukt i blandt annet Ansattabellen og Butikktabellen for å si hvilken region disse tilhører. Navn Navnet på regionen. Brukergruppetabellen Dette er en tabell som lister opp de ulike brukergruppene med tilhørende tilgang til systemet (Eksempler på brukergrupper: Regionssjef, vareleveringsansvarlig, Selger, osv): Beskrivelse av feltene: *id Dette er den unike id en til brukergruppen. Tittel Tittelene på brukergruppen (Eksempel: Regionssjef). Tilgang_*id id en til tilgangen denne brukergruppen har (Hva denne brukergruppen skal ha tilgang til å gjøre i systemet). Hvis f.eks Regionssjef og Vareleveringsansvarlig skal ha samme tilgang i systemet, uten å ligge i samme brukergruppe (varleveringssjef er ikke en regionssjef). Side 26

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

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

RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON

RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 CONTENTS 1 Innledning... 4 1.1 Presentasjon... 4 1.2 Om bedriften...

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

HOVEDPROSJEKT VÅR PROSJEKTDAGBOK

HOVEDPROSJEKT VÅR PROSJEKTDAGBOK HOVEDPROSJEKT VÅR 2011 - PROSJEKTDAGBOK OPPDRAGSGIVER: KRAFT FOODS NORGE AS GRUPPENR: 18 GRUPPEMEDLEMMER: - S155485-3IA - TOR ANDREAS BAAKIND - S155484-3IA - MORTEN EVJE - S148229-3IA - ANDERS GABRIELSEN

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

RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON

RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON RUTEPLANLEGGINGSSYSTEM TESTDUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Testdokumentasjonen har som formål å beskrive all testing som

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

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

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

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

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

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

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

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

Dokument 1 - Sammendrag

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

Detaljer

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

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

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

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

Detaljer

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

Prosjektdagbok hovedprosjekt våren 09

Prosjektdagbok hovedprosjekt våren 09 Prosjektdagbok hovedprosjekt våren 09 Man 25. Mai 09 Planlegging og arbeid med sluttføring Sluttføring av grensesnitt, arbeid med dokumentasjon og detaljplanlegging av sluttføring. Ons 21. Mai 09 Arbeid

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

Kandidat nr. 1, 2 og 3

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

Detaljer

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

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

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

Produktrapport Gruppe 9

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

Detaljer

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

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

Oblig 5 Webutvikling. Av Thomas Gitlevaag

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

Detaljer

Dokument 3 - Prosessdokumentasjon

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

Detaljer

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

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 for Sir Jerky Leap

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

Detaljer

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

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

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

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

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

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

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

Detaljer

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006 PRESENTASJON Prosjektnr: 43E Prosjektnavn: BILs nettsider Elev: Jone Tveitane Dato: 17.12.2006 1 INNHOLDSFORTEGNELSE 1 OPPGAVESTILLER... 3 2 PROBLEMSTILLING... 3 3 HVORFOR DENNE OPPGAVE... 3 4 HVORDAN

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

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

Hvis du gjenkjenner ett av disse to bildene over så er dere på vår ASP-server.

Hvis du gjenkjenner ett av disse to bildene over så er dere på vår ASP-server. 1 1 Introduksjon Denne veiledningen gir en liten oversikt over noen feilsituasjoner med printer og utskrifter. Årsakene til problemet kan være ganske mange, og det vil derfor være praktisk umulig å kunne

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

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

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

Detaljer

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

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

Detaljer

Høgskolen i Oslo og Akershus

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

Detaljer

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

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

Detaljer

En enkel lærerveiledning

En enkel lærerveiledning En enkel lærerveiledning ~ 1 ~ Innhold INNLEDNING... 3 Hva?... 3 Hvorfor?... 3 INN- og UTLOGGING... 4 Innlogging... 4 Utlogging... 5 Lærerinnlogging/-utlogging... 5 OUTLOOK / EPOST... 6 Skrive epost...

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

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

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell.

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell. statusrapport 2 I produksjon av webside for skjerdingen høyfjellshotell STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell 1 29. APRIL 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen

Detaljer

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

InfoRed Publisering. - produktbeskrivelse.  TalkPool WebServices Postboks Åneby InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,

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

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

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

Detaljer

Prosjektdagbok Oktober 2009 November 2009 Desember 2009 Januar 2010 (Uke 1)

Prosjektdagbok Oktober 2009 November 2009 Desember 2009 Januar 2010 (Uke 1) Prosjektdagbok (Vi valgte og ikke legge ut dagboken på en felles fil som anbefalt da vi har jobbet mye sammen før og viste at vi kunne stole på hverandre. Eventuelle ubehagligheter tok vi heller opp på

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

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

Forprosjektrapport Gruppe 30 Forprosjektrapport Gruppe 30 Gruppemedlemmer: Eyvind Nielsen s177748 Ullvar Brekke s236375 Kristoffer Pettersen s239404 Innhold Presentasjon... 3 Sammendrag... 3 Dagens situasjon... 3 Mål... 3 Rammebetingelser...

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

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

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

Detaljer

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

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport. Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter

Detaljer

K-Nett. Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon. av Erik Mathiessen

K-Nett. Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon. av Erik Mathiessen K-Nett Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon av Erik Mathiessen Om oppgavestiller NVE er et direktorat underlagt Olje- og energidepartementet

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

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

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741)

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Prosjektdagbok Gruppe 9 Gruppemedlemmer Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Månedsoppsummering: Mai Arbeidet har vært tungt siden vi har måttet flytte

Detaljer

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2 Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av

Detaljer

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg Forprosjektrapport Presentasjon Tittel Bakerman AS Website Oppgave Utvikle ett websted for Bakerman AS der hvor de kan promotere seg selv og kommunisere med kundene sine. Periode 4. Januar 2010 til 17.

Detaljer

Vedlegg LMC intranett

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

Detaljer

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

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus, Bachelorprosjekt ved Institutt for informasjonsteknologi, våren 2017 Høgskolen i Oslo og Akershus, 19.01.2017 Gruppe 44 Håkon Andre Sylte Garnes, Tobias Hallèn, Gaurab J. Gurung Forprosjektrapport Presentasjon

Detaljer

Humanware. Trekker Breeze versjon 2.0.0.

Humanware. Trekker Breeze versjon 2.0.0. Humanware Trekker Breeze versjon 2.0.0. Humanware er stolte av å kunne introdusere versjon 2.0 av Trekker Breeze talende GPS. Denne oppgraderingen er gratis for alle Trekker Breeze brukere. Programmet

Detaljer

Forprosjekt. Høgskolen i Oslo, våren

Forprosjekt. Høgskolen i Oslo, våren Forprosjekt Høgskolen i Oslo, våren 2011 ------------------------------------------ Presentasjon Tittel: Oppgave: Database og nettside for Nor Dagligvarer Import AS Utvikle et databasesystem for bedriften

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

Use Case Modeller. Administrator og standardbruker

Use Case Modeller. Administrator og standardbruker Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet

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

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

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113) Forprosjektrapport Gruppe 14 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren 2015 Sted: Høgskolen i Oslo og Akershus Dato: 23.01.2015 Tittel: Gruppemedlemmer: Oppgave: Oppdragsgiver:

Detaljer

WP-WATCHER WORDPRESS SIKKERHET

WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei! Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp! Jeg

Detaljer

!!!!!!!!!!!! !!!!!!!!!!! WP-WATCHER WORDPRESS SIKKERHET

!!!!!!!!!!!! !!!!!!!!!!! WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp Jeg

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

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

PROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning

PROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning PROGRAMUTVIKLINGSPLAN Big Data and Machine Learning Innholdsfortegnelse Produkt beskrivelse... 1 Team beskrivelse... 2 Prosjektets kunnskapskrav... 2 Medlemmer og roller... 2 Program prosessmodell beskrivelse...

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

Hvor og hvordan lagrer du mediafilene dine?

Hvor og hvordan lagrer du mediafilene dine? Beskriv din digitale infrastruktur, med tilhørende arbeidsflyt. Hvor og hvordan lagrer du mediafilene dine? Hva gjør du med back-up? Hva slags online lagringsløsning har du valgt? Hvordan finner du fram

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

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

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

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

Rapport til undersøkelse i sosiologi og sosialantropologi

Rapport til undersøkelse i sosiologi og sosialantropologi Rapport til undersøkelse i sosiologi og sosialantropologi Problemstilling: Er det en sammenheng mellom kjønn og hva de velger å gjøre etter videregående? Er det noen hindringer for ønske av utdanning og

Detaljer

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

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

Detaljer

TESTRAPPORT - PRODSYS

TESTRAPPORT - PRODSYS TESTRAPPORT - PRODSYS PRODSYS-DATASYSTEM FOR ÅS PRODUKSJONSLAB AS GRUPPE 12 CHRISTOPHER CONRADI STEFFEN DIEDRICHSEN ROMAN KOVALENKO INFORMASJONSTEKNOLOGI, INGENIØRUTDANNINGEN, HØYSKOLEN I OSLO 1. FORORD

Detaljer