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 Telefaks: 22 45 32 05 PROSESSDOKUMENTASJON HOVEDPROSJEKTETS TITTEL: Dekklåven DATO: 31. mai 2008 23. mai 2008 ANTALL SIDER / BILAG: PROSJEKTDELTAKERE: Chau Quoc Do, Einar Drivdal, Nikolai Godager og Kevin Holmvik INTERN VEILEDER: Steinar Johannessen OPPDRAGSGIVER: Dekklåven KONTAKTPERSONER: Dag Terje Bjørlo tlf: 62 35 50 20 SAMMENDRAG Denne rapporten inneholder dokumentasjon som har blitt produsert i forbindelse med hovedprosjektet våren 2010 ved Høgskolen i Oslo, avdeling for dataingeniør. Den tar for seg et nettbasert system for Dekklåven og skal kunne bestille dekk og felger, reservere servicetimer og dekkhotell. Dekkhotell er en selvstendig applikasjon som tar for seg av lagring av dekk. Arbeidsprosessen under prosjektperioden er også dokumentert. STIKKORD: Nettbutikk, Reservasjon av servicetimer, Dekkhotell

1 FORORD Hensikten med dette dokumentet er å beskrive gruppens arbeid under gruppens arbeid og metoder som ble tatt i bruk i hovedprosjektoppgave ved Høgskolen i Oslo, avdeling for dataingeniør. Prosessrapporten vil ta for seg om hvordan gruppa har kommet frem til det endelige produktet. Vi vil beskrive arbeidsmetoder, rammebetingelse, valg av prosjektoppgaven og hvilke verktøy vi har brukt til å løse prosjekts problemstilling. I tillegg vil den fortelle om motgangen vi har møtt underveis, og hva vi har lært om prosessen. Denne rapporten er egnet for sensor, veileder, oppdragsgiver og andre som er interessert i våres løsning. Dette dokumentet er optimert for papirutskrift.

Innholdsfortegnelse 1 Forord... 3 2 Sammendrag... 2 3 Innledning... 3 3.1 Om bedriften... 3 3.2 Dagens situasjon... 3 3.3 Mål for prosjektet... 3 3.4 Oppdraggiver krav... 4 3.5 Rammebetingelse... 4 3.6 Funksjonelle krav... 4 3.7 Andre krav... 4 3.8 Tekniske krav... 4 4 Planlegging og metode... 5 4.1 Planlegging... 5 4.2 Framdriftsplan... 5 4.3 Prosjektansvarskart... 7 4.4 Metoder... 8 4.4.1 Fossefallsmetoden... 8 4.4.2 Verktøy... 9 4.4.3 Database... 9 4.4.4 Språk...10 5 Utviklingsprosseen...11 5.1 Valg av prosjekt...11 5.2 Faser i prosjektet...11 5.2.1 Forprosjekt...11 5.3 Forskjellige hoveddeler...11 5.3.1 Nettverkskalender...11 5.3.2 Reservasjon av servicetimer...11 5.3.3 Webshop...12 5.3.4 Dekkhotell...12 5.3.5 Hjemmeside...12 5.3.6 Ugjort arbeid...13 6 Kravspesifikasjon...14 6.1 Kravspesifikasjonens rolle...14 7 Konklusjon...15 7.1 Oppsummering...15 7.2 Produkts fremtid...15 7.3 Hva kunne blitt gjort annerledes?...15 1

2 SAMMENDRAG Prosjektoppgaven gikk ut på å designe et nettbasert system bestående av bestilling av dekk og felger, reservasjon av servicetimer og en brukevennlig hjemmeside. Samtidlig en applikasjon for lagring av dekk. Oppgaven fikk vi tildelt av Dekklåven AS. Systemet skal brukes til å gjøre det lettere for nye og gamle kunder til å se hva Dekklåven har å tilby på verkstedet. Applikasjonen er for de ansatte hos Dekklåven, med oversiktlig informasjon om lagringsplass. Målet med vårt hovedprosjekt har vært å lage et solid webbasert grensesnitt for Dekklåven AS, som skal forenkle jobben med bestilling, reservasjon og lagring. Programmet egner seg for kunder med behov for tjeneste hos Dekklåven, mens de administrerte tjenester for de ansatte. Underveis i prosjektgjennomføringen fikk vi et tilbakeslag om at det var ikke mulig å lage en webshop under prosjektperioden. En av grunnene var at Dekklåven har i dag ikke har en oversiktlig over lagerbeholdning, og med dette ville det vært vanskelig å opprette en webshop for å la kunden ha muligheten til å kjøpe en vare. Andre grunner har blitt nærmere forklart i utviklingsprosessen. Det å ha oversikt over hva vi skulle utvikle og hva det innebar, krevde mange timer med samtaler innad gruppen og med kontaktpersonen fra Dekklåven. Noen forslag ble fremlagt og forkastet etter som innsikten vokste. Tilslutt endte vi opp med system bestående av bestilling, reservasjon, dekkhotell og en ny hjemmeside. Disse skal installeres hos Dekklåven AS som befinner seg i Brummundal. Gruppen vår består av fire studenter, samtlige fra dataingeniørlinjen på Høgskolen i Oslo. Vi har jobbet sammen ved tidligere anledninger og har lært å kjenne hverandre, ikke minst når det gjelder kompetansefelt og arbeidskapasitet. Arbeidsoppgavene har stort blitt delegert for den enkelte kompetansefelt. I gruppe med fire medlemmer, vil det vanligvis oppstå uenigheter og konflikter. Men vi har likevel bevart et tettsamhold og et godt samarbeid, tross det var en del konflikter underveis. Alle diskusjoner og konflikter ble løst ved hjelp av avstemming. Hovedprosjektet har uten tvil gitt oss mye, både kunnskap og erfaringer. Vi har lært om teknologi, prosjektgjennomføring og om samarbeid. Viktigst av alt er at vi sitter igjen i dag med et godt produkt. Et produkt som er henhold til kravene fra oppdragsgiver. I rapporten finner man beskrivelse av dette systemet og dokumentasjon av arbeidsprosessen gjennom hele prosjektperioden. 2

3 INNLEDNING Da vi dannet gruppen for hovedprosjektet kom vi frem til at vi ønsket en database og nettbasert oppgave hvis det var mulig. Dermed tok vi kontakt med Dekklåven AS som hadde bruk for en sånn type system. Vi tilbød oss å lage en bestilling og reservering system først, men siden vi så at dem trengte et oppdatert hjemme side og en applikasjon for registrering av dekkhotell. Etter litt diskusjon innad gruppen ble det vedtatt at vi skulle lage bestilling og reservering system, samt en ny hjemmeside og en applikasjon for dekkhotell og administratorverktøy I denne rapporten har vi dokumentert hele arbeidsprosessen under prosjektperioden. Man vil finne beskrivelser av de systemutviklingsmetoder som er brukt i prosjektet, utviklingsprosessen, arbeidsprosessen og annen informasjon rundt selve arbeidsprosessen og prosjektet. Kravspesifikasjonen er å finne i denne rapporten, som både prosjekt- og produktrapporten bygger på. 3.1 OM BEDRIFTEN Dekklåven AS norskdrivende bedrift som leverer tjenester innenfor salg av dekk og felger, utfører dekkskift og lagring av dekk. Dekklåven AS ble etablert i Brummundal i 2002, og har i dag flere verksteder omkring Oslo området. I dag selger bedriften dekk og felger med importert fra Asia, og utgjør bare dekkskift for kundene. 3.2 DAGENS SITUASJON Dekklåven AS har i dag bare kjøp av dekk og felger ved lageret sitt, og dette krever ganske stor kapasitet av ansatte og mye manuelt arbeid. Ved lagring av dekk, har de i dag oppbevart informasjonen i et Excel-dokument og noe som gjør det lite fleksibelt. Håndtering av servicetimer, har de i dag måtte la kundene møte opp og la dem vente til det er ledig time. 3.3 MÅL FOR PROSJEKTET Målet for dette prosjektet har vært å utvikle et nettbasert system med wehshop, dekkhotell, servicebestilling, nettverkskalender og en ny hjemmeside. Med disse applikasjonene vil det kunne gjøre hverdagen til både de ansatte og kundene lettere for å nå bedriftens tjenester. Vi lagde noen hovedpunkter over hva vi hadde da til følgende mål for hver av oppgavene: Webshop o Skal kunne kjøpe fra hjemmeside. o Lager beholdning skal oppdateres når en kunde har handlet. o Det skal være mulig å betale med visa. o Bare autoriserte personer har tilgang til å hente ut ordrer. Dekkhotell o Skal la brukere kunne få muligheten til å registrere nye lagringsplass. o Et søkbart system for å finne lagringsplass. Reservasjon av servicetimer o Kunder skal ha muligheten til å reservere time hos Dekklåven. Nettverkskalender 3

o Skal gjøre det mulig å opprette/redigere/slette reservasjoner o Skal kunne presentere nåværende aktivitet på storskjerm i værkstedet o Skal kunne generere ulike tidsintervaller for kalenderen Hjemmeside o Skal være en oversiktlig side. o Siden skal være mest mulig brukevennlig. 3.4 OPPDRAGGIVER KRAV Vår oppdragsgiver Dekklåven AS, hadde ikke noen spesielle ønsker om de tekniske kravene. Derfor sto vi ganske fri til å utforme applikasjonene og utseende. Etter hvert som vi hadde lagd enkle tester av applikasjonene, fikk vår oppdragsgiver en liten blikk på hva han ville få i ettertid. Noen forslag ble tatt i bruk og noen ble forkastet. Siden vår oppdragsgiver befant seg i Brummundal, var kontakten mellom oss og oppdragsgiver vært stort sett gjennom e-post og telefon. 3.5 RAMMEBETINGELSE Etter møtet med oppdragsgiver, har gruppen vår diskutert til følgende rammebetingelse. 3.6 FUNKSJONELLE KRAV Siden vi ikke kan regne med at alle har like mye datakompetanse, derfor skal vi ha stor fokus på brukevennligheten for å gjøre det lettere for brukerne. Systemet bør inneholde: Mulighet for kunde å kjøpe dekk og felger. Mulighet for kunde å reservere plass for lagring av dekk og felger. Mulighet for kunde å bestille servicetimer. Her kan kunden f.eks. velge årsak for service. Et administrasjonsverktøy hvor brukeren kan legge inn nye varer, og endre pris på ulike varer. Et grensesnitt for ansatte hvor de kan få en oversikt over dagens nye bestilling for lagring av dekk og felger. Et grensesnitt for ansatte hvor de kan få en oversikt over dagens servicetimer, der brukeren har muligheten for å skrive ut. Mulighet for brukerne å hente ut historikk for salg, dekkhotell og service timer. 3.7 ANDRE KRAV Funksjonalitet som kan implementeres: Mulighet for å betale med kredittkort. 3.8 TEKNISKE KRAV Som rammebetingelse har vi valgt å følge den gamle databasen til bedriften, som er laget i Visma. For å implementere database, har vi valgt å bruke Zpider til å integrere løsningen. Nettsiden for bedriften skal kunne støtte alle nettlesere. 4

4 PLANLEGGING OG METODE 4.1 PLANLEGGING Etter at vi hadde fått litt informasjon fra Dekklåven AS på e-post, startet vi startet vi straks med planlegging. Vi avtalte rask et møte med Dekklåven AS i Brummundal hvor vi skulle legge frem vårt forslag om hvordan systemet skulle se ut, og samtidlig fikk vi et innblikk på hvordan de operer med rutines deres i dag. Etter å vært på besøk hos Dekklåven, lagde vi en fremtidsplan. Vi tenkte at vi skulle lage en detaljert fremdriftsplan, men merket ganske fort at utfordringene vi fikk gjorde at fremdriften ville bli svært forutsigbart. Vi holdt derfor til denne første versjonen av framtidsplanen. Selv om det ikke ble lagd noen detaljert framtidsplan, ga den første versjonen en god oversikt og første at vi hadde kontroll over fremdriften. Etter vært som fremdriftsplanen ble lagd, fikk vi lagd en arbeidsplan. Arbeidsplanen ble lagd på grunn av at vi ønsket at hver prosjektdeltager skulle få ansvar på hva som skal gjøres, og hvordan fremdriften skal være. Siden vi var fire i gruppen, visste vi at det var vanskelig å ha faste dager. Vi bestemte oss derfor i første fase i prosjektet, skulle vi ha møte minst to ganger i uken. Grunnen til at vi hadde to faste dager, var fordi alle vi hadde et valgfag som skulle tas ved siden av hovedprosjektet. I begynnelsen av mars da vi ble litt tryggere i våre studiefag ved siden av, begynte vi å møte regelmessig hver dag. 4.2 FRAMDRIFTSPLAN I begynnelsen av prosjektet ble det klar for oss hva som skulle gjøres, og når ting måtte bli ferdig for å nå tidsfristen. Vi lagde først et utkast av framtidsplanen, der vi førte opp de nødvendige punktene som måtte gjøres innen et visst tidspunkt. Vi vurdert deretter å lage et detaljert framtidsplan, men siden utfordringene for fremdriften ble ganske forutsigbart, holdt vi til det første utkastet. I Tabell 2.1 er den oversikt over videre framdrift for prosjektarbeidet. Den viser hvilke deler av oppgaven er estimert til. Tabell 2.1 Oversikt over utviklingen. 5

6

I Tabell 2.2 viser det en tabell over når de ulike oppgaver er blitt estimert til. Tabell 2.2 viser hvordan vi har estimert tiden. 4.3 PROSJEKTANSVARSKART Vi i gruppen har hele tiden hatt Kevin Holmvik som prosjektleder, siden han har bedre kontakt med oppdragsgiver. Men under prosjektet har alle hatt like mye ansvar. Vi lagde et ansvarskart slik at alle fikk minst et hovedansvarsområde. Prosjektansvarskart viser hovedoppgavene og hvilke gruppemedlem som har ansvar for disse oppgavene og er presentert i Tabell 2.3 Tabell 2.3 viser områdsansvar hver prosjektdeltager har ansvar for. Oppgave Hovedansvarlig Delansvarlig Prosjektleder Kevin Holmvik Chau Quoc Do Modelldesign Kevin Holmvik Einar Drivdal Sekretær Chau Quoc Do Nikolai Godager Bestillingssystem Kevin Holmvik Einar Drivdal Reservasjonssystem Chau Quoc Do Chau Quoc Do Dekkhotell applikasjon Einar Drivdal Einar Drivdal Webutvikler Nikolai Godager Kevin Holmvik Prosessdokumentasjon Chau Quoc Do Alle 7

Produktdokumentasjon Chau Quoc Do Alle Sluttdokumentasjon Nikolai Godager Chau Quoc Do Risikoanalyse Backup ansvarlig Fremdriftsplan Einar Drivdal Einar Drivdal Chau Quoc Do Nikolai Godager Kevin Holmvik Nikolai Godager Modell beskrivelse Kevin Holmvik Einar Drivdal Kvalitetssikring Alle 4.4 METODER 4.4.1 FOSSEFALLSMETODEN Etter vi hadde satt sammen kravspesifikasjonen begynte vi å tenke på ulike arbeidsmetoder vi ville bruke. Vi diskuterte og kom frem til at en fossefallsmetode ville passe for prosjektoppgaven, ettersom Dekklåven ønsker noen funksjoner som skal implementeres i systemet. I Figur 2.1 viser den en fossefallsmodell hvor vi har hele tiden har muligheten til å gå tilbake til tidligere faser og eventuelt implementere nye funksjoner. Figur 2.1 er en fossefallsmodell 8

4.4.2 VERKTØY Under utviklingen av systemet, har vi fått lært my nytt. Vi har alle fire jobbet på separate datamaskiner, men hele tiden jobbet mot prosjektets mål. Selv om alle fire har jobbet på separate datamaskiner, har vi alle brukt verktøy som er optimalt mot hverandre. Med verktøy har vi blant annet tatt i bruk med følgende: SQL Server Management Studio Express o Et program for å håndtere database, med dette programmet kan vi Microsoft Visual Studio 2008 o Med dette programmet har vi programmert nettverkskalenderen og reservasjon av servicetimer. Qt Creator o Et program som har blitt brukt for å kode dekkhotell applikasjonen. Adobe Photoshop CS4 o Et avansert bilderedigerings program for design, redigering og komposisjon av nye web elementer til hjemmesiden. Adobe Illustrator CS4 o For å designe bilde, logo og tekst for hjemmesiden. MySQL o Et programmeringsspråk som har blitt brukt for å koble mot databasen med MS Visual Studio 2008 og Qt Creator. Textpad o For bruk til å kode HTML og CSS for hjemmesiden. 4.4.3 DATABASE Som database, har alle vi brukt SQL Server Management Studio Express siden vi alle har erfaring med SQL database. Da vi først skulle begynne modellere database, ble det at vi først lagde et utkast av databasen. Da seinere etter vi hadde fått diskutert sammen, ble det opprettet nye tabeller og lagt frem en database med attributter. Med en database så tidlig i prosjektet, måtte vi gjøre noen enkle endringer under i prosjekt perioden. Noen enkle endringer vil det si at det ble lagt til noen attributter, eller har vi beholdt de samme tabellene underveis.) 9

4.4.4 SPRÅK C# o Dette er det programmeringsspråket som har blitt brukt mest under utviklingen. Qt o Dette programmeringsspråket har blitt brukt for å opprette applikasjonen Dekkhotell MySQL o For å sette spørringer mot databasen. HTML, CSS, Javascript o Brukes for å utvikle hjemmesiden. 10

5 UTVIKLINGSPROSSEEN 5.1 VALG AV PROSJEKT Vi var første ganske spente når vi skulle lete etter en prosjektoppgave. Vi fikk høre at et firma i Brummundal trengte et system som de ikke hadde kapasitet til å utføre. Vi synes oppgaven fra Dekklåven hørtes interessant ut, siden vi alle i gruppen hadde fra før tenkt å lage et nettbasert system. 5.2 FASER I PROSJEKTET Siden selve hovedprosjekt oppgaven var ganske stor i seg selv, måtte vi ha ulike faser for å kunne dokumentere arbeidet vårt. For innledninger faser, ble følgende gjort: Prosjekthjemmeside For å legge ut dokumenter vi har gjort underveis, dette er fordi det skal gjøre det lettere for arbeidsgiveren eller veiledning skal ha tilgang til dokumentene. Statusrapport Denne var en del av prosjektet innledende fase, og dette ble ferdig utviklet og lagt på prosjektets hjemmeside den 30. oktober 2009. Prosjektskisse En beskrivelse av prosjektet med informasjon om kommunikasjon mellom oppdragsgiveren og gruppemedlemmene. Denne ble ferdigstilt, og lagt ut på prosjektets hjemmeside den 4. desember 2009. 5.2.1 FORPROSJEKT Forprosjektfasen ble påbegynt rett etter nyttår. Denne fasen ble viktig for oss for å kunne disponere tiden godt og planla 5.3 FORSKJELLIGE HOVEDDELER 5.3.1 NETTVERKSKALENDER 5.3.2 RESERVASJON AV SERVICETIMER For denne applikasjonen har vi valgt å bruke MS Visual Studio 2008 som plattform, det var vi fordi så at det var mest fornuftig siden vi hadde noe lunde erfaringer fra tidligere. 5.3.2.1 Oppbyggingen Læring Gjennom hele prosjektperioden har vi kunne tilegnet oss kunnskap ved å lage denne applikasjonen. Dette gjelder ikke bare det vi har lært ved utvikling av selve applikasjonen, men for å få den til å fungere mot nettverkskalenderen. I tillegg har vi merket at det har blitt tatt i bruk nye teknologier som ingen av gruppen har tatt i bruk før, og dette ser vi som en nyttig erfaring for alle oss som kan ta dette med videre. Implementering 11

Det første vi gjorde da vi skulle lage reservasjonsapplikasjonen var å opprette en MS SQL database. Etter databasen var opprettet, begynte vi på programmerings biten hvor vi hadde mange diskusjoner om hvordan oppsettet av applikasjonen skulle være. Dermed falt valget for at vi skulle bare ha en oversiktlig timeplan hvor kunden kan se når kunden kan reservere time. Programmering av brukergrensesnitt var det første fokuset siden vår oppdragsgiver hadde gitt oss klar beskjed om at det skulle være brukevennlig. Utfordring 5.3.3 WEBSHOP 5.3.4 DEKKHOTELL 5.3.5 HJEMMESIDE For å begynne med, var alle i gruppen ganske klar over hvordan hjemmesiden skulle være. Vi bestemte oss for å lage en ny hjemmeside, men den nye hjemmeside skulle fortsatt være litt preget over den gamle siden. En annen grunn var at en i gruppen hadde mer kunnskap til Flash enn Silverlight, 5.3.5.1 Konstruksjonen Vi valgte å programmere hjemmesiden ved hjelp av HTML, CSS, Flash, JQuery og Java Script. Vi valgte å ikke bruke Silverlight, dette er fordi vi følte at Flash ville fungere like bra til det bruksområde vi hadde tenkt. 5.3.5.2 Testing Hele prosjektoppgaven vår har blitt testet for brukevennlighet, og den applikasjonen som har blitt test mest grundig var administrasjonsapplikasjonen. Siden applikasjonen skulle styres hele systemet. Den viktigste testingen ble gjort hos Dekklåven selv, vi fikk noen av de ansatte til å prøve systemet. Tilbakemeldingene fra hver test person, ble dokumentert for videre forbedringer. 5.3.5.3 Optimalt for nettlesere Siden det er flest kunder som skal bruke systemet, må vi regne med at ikke alle bruke Firefox som standard nettleser. Derfor måtte vi ta høyde for dem som bruker andre nettlesere. Vi har testet på følgende nettlesere: Microsoft Internet Explorer Mozilla Firefox Opera All funksjonalitet er blitt testet fullt ut i alle nettleserne. Resultatet har blitt forskjellige, med tanke på design på hjemmesiden. 12

5.3.5.4 Brukervennlighet Gjennom systematisk jobbing gjennom hele prosjektperiode med testing, har sluttproduktet fått en tilfredsstillende brukerkvalitet. Siden brukervennlig sto størst i fokus hos oss, var det veldig viktig for oss at vi lagde hjemmeside som kan navigere raskt gjennom. Dermed ble brukerkvaliteten et tema som har blitt lagt mye arbeid gjennom prosjektgjennomføringen. 5.3.6 UGJORT ARBEID Da vi fikk tilbud om å lage et system for Dekklåven AS, ble det enighet mellom gruppen og oppdragsgiver at en webshop skulle være med som en del av prosjektet. Etter hvert som ukene gikk, fikk vi tilbakemeldinger fra Dekklåven at webshop ikke var aktuelt for øyeblikket. Med følgende grunner var på grunn av lager flytting og stadig nye lagerbeholdninger. 13

6 KRAVSPESIFIKASJON Før vi begynte med den tekniske biten av prosjektet, måtte vi opprette en kravspesifikasjon som et styringsdokument for hele prosjektperioden. Med første utkast av kravspesifikasjonen ble det lagt fram til oppdragsgiveren, og noen små endringer små endringer måtte endres og skrevet om. Den oppdaterte kravspesifikasjonen er et selvstendig dokument og er å finne som en del av sluttrapporten. 6.1 KRAVSPESIFIKASJONENS ROLLE Kravspesifikasjonen har hatt en sentral rolle i utviklingen av denne løsningen, ved tvil og andre tilfeller har vi kunne sett tilbake til dokumentet. Selv har vi alltid visst at kravspesifikasjonen skulle bli en sentral rolle ved tidligere erfaringer, har vi denne gangen brukt ekstra godt tid for å utvikle det. Vi merket ganske fort at den ekstra tiden som har blitt brukt, var meget stor fordel for arbeidet vårt. Vi hadde hele tiden muligheten til å se gjennom kravspesifikasjonen og følge med om vi følger med de punktene som gruppen har blitt enig om. 14

7 KONKLUSJON Etter flere måneder med hardt arbeid, har vi nå klart å fremføre et godt produkt som vi selv og vår oppdragsgiver ble fornøyd med. 7.1 OPPSUMMERING Vi er selv godt fornøyd med resultatet på hovedprosjektet, selv om det ikke ble lagd noen nettbutikk. Vi ser selv på helheten at vi alle har hatt en lærerik prosess. At vi har utviklet et system som skal brukes på nettet av en stor kundegruppe. Gruppen og samarbeidet innad gruppen har fungert godt som vi forutså det, siden vi har jobbet sammen siden første klasse på høgskolen.. Vi er veldig godt fornøyd med den tekniske kunnskapen vi har fått ved dette prosjektet, som vi vet at det vil komme til nytte for fremtiden. 7.2 PRODUKTS FREMTID Hjemmeside med integrert reservasjonsbestilling og oversiktlig over Dekklåvens produkter har nå blitt ferdigstilt og Dekklåven skal snarest ta det for bruk snarest som mulig. I første omgang vil systemet sånn den er ferdigstilt, men etter hvert som Dekklåven har fått lagerbeholdningen skal vi deretter programmere nettbutikken for dem. Selve systemet har mulighet til å videreutvikle med en ny funksjonalitet og eventuelt optimaliseres etter hvert som dette blir nødvendig. 7.3 HVA KUNNE BLITT GJORT ANNERLEDES? Vi ville selvfølgelig ønske å opprette en nettbutikk, men dette lot seg ikke gjøre siden vår oppdragsgiver ikke hadde muligheten til oppfylle kravene våre for å kunne opprette en nettbutikk. Selv om vi helst ville ha en nettbutikk som er ferdigstilt i prosjektperioden, måtte vi ta hensyn til vår oppdragsgiver. Siden vi ikke har fått ferdigstilt alle kravene fra kravspesifikasjon, har vi i gruppen tenkt å gjøre ferdig med prosjektoppgaven til seinere tid når arbeidsgiver har muligheten til å få på plass kravene våre. 15