Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Transkript

1 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s Nikolai Godager s Einar Drivdal s Chau Quoc Quo Do s147792

2 PROSJEKT NR.: Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: Telefaks: SLUTTDOKUMENTASJON HOVEDPROSJEKTETS TITTEL: Dekklåven DATO: 31. mai 2008 ANTALL SIDER: 49 PROSJEKTDELTAKERE: Chau Quoc Do, Einar Drivdal, Nikolai Godager og Kevin Holmvik INTERN VEILEDER: Steinar Johanessen OPPDRAGSGIVER: Dekklåven KONTAKTPERSONER: Dag Terje Bjørlo tlf: SAMMENDRAG Prosjektet har gått ut på å lage et nettbasert system for Dekklåven, som tilbyr salg av dekk og felger. Dekklåven tilbyr også andre tjenester som service og lagring av dekk. TITTELSIDE STIKKORD: Nettbutikk, Reservasjon av servicetimer, Dekkhotell

3 2 FORORD 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 tett samhold 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.

4 Innholdsfortegnelse 1 TITTELSIDE FORORD... Error! Bookmark not defined. 3 INNLEDNING Om bedriften Dagens situasjon Mål for prosjektet Oppdraggiver krav Funksjonelle krav Andre krav Tekniske krav KRAVSPESIFIKASJON Systemkrav Funksjonelle krav Krav til nettbutikk Krav til reservasjonssystem Krav til dekkhotell Krav til Nettverkskalender Tekniske krav Datalagring Design Brukegrensesnittet Kode krav Krav til dokumentasjon Videreutvikling Produktet PRODUKTInnledning Dagens situasjon Våre infrastrukturelle ønsker om endring Mål for prosjektet Samsvar mellom kravspesifikasjon og produktet Teknologi... 15

5 5.2.3 Beskrivelse av teknologi Dekkhotell Datastruktur Om dataflyten: Oppbygging og virkemåte for Dekkhotell Nettverkskalender Datastruktur Oppbygging og virkemåte for Nettverkskalender Nettbutikk Planlegging Analyse av Visma Dataflyt Konklusjon Planlegging og metode Planlegging Framdriftsplan Prosjektansvarskart Metoder Fossefallsmetoden Verktøy Database Språk Utviklingsprosseen Valg av prosjekt Faser i prosjektet Forprosjekt Forskjellige hoveddeler Reservasjon av servicetimer Webshop Hjemmeside Ugjort arbeid Konklusjon Oppsummering... 49

6 8.2 Produkts fremtid Hva kunne blitt gjort annerledes?... 49

7 1 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 de trengte en oppdatert hjemmeside og en applikasjon for registrering av dekkhotell. Etter litt diskusjon innad gruppen ble det vedtatt at vi skulle lage bestilling og reserveringsystem, 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å. 1.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 utfører dekkskift for kundene med tilbud om lagring av dekkene for sesongen. 1.2 DAGENS SITUASJON Dekklåven AS har i dag 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. 1.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.

8 Reservasjon av servicetimer o Kunder skal ha muligheten til å reservere time hos Dekklåven. Nettverkskalender 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. 1.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 et lite 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. 1.5 FUNKSJONELLE KRAV 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. 1.6 ANDRE KRAV Funksjonalitet som kan implementeres: Mulighet for å betale med kredittkort. 1.7 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.

9 2 KRAVSPESIFIKASJON 2.1 SYSTEMKRAV FUNKSJONELLE KRAV Før vi kan begynne å starte med den tekniske biten for prosjektoppgaven, er det greit å ha en oversikt over de kravene som har blitt lagt frem av oppdragsgiveren og av oss selv. Derfor har laget et oversiktlig funksjonelt krav for prosjektoppgaven KRAV TIL NETTBUTIKK Nettbutikken skal være direkte knyttet opp imot bedriftens økonomisystem Visma Global. Når bryteren Publiser på nett aktiveres I Global skal artikkelen automatisk publiseres på nettbutikken. Bildene som ligger som artikkelvedlegg I Visma skal legges ut som enhetsbilde på netbutikken. Det skal være mulig å lagre en annen prisprofil på nett en den som er standard butikkpris ved lokalkjøp I Visma. Nettbutikken skal ikke vise nøyaktig lagerstatus slik som økonomisystemet gjør, men begrense det til: o Tomt, forventet på lager: XXDatoXX, o Færre enn 10, o Flere enn 10, o Flere enn 100 Det skal være mulig å handle med kredittkort KRAV TIL RESERVASJONSSYSTEM Kunden skal ha muligheten til å reservere timer hos verkstedet. Systemet skal kunne oppdateres snarest en reservasjon har blitt opprettet, for å unngå dobbelbooking. For at kunden skal ha muligheten for å opprette en reservasjon, må kunden selv være pålogget.

10 2.1.4 KRAV TIL DEKKHOTELL Det skal være mulig å lagre og endre på følgende: Navn på de forskjellige lagere Informasjon om lagringsplasser for hvert lager Navn og telefonnummer på kunder Informasjon om hvor dekkene til en kunde ligger lagret Brukeren av systemet skal kunne: Utføre oppgavene som står skrevet over Søke på navn, etternavn eller telefonnr. for å finne ut hvor dekkene til en kunde er lagret Søke på lagernummer eller plassnummer for å finne ut hvem som har dekkene sine lagret hvor KRAV TIL NETTVERKSKALENDER Det var ønskelig å få en applikasjon som gjør det mulig for bedriften å reservere timer ihht. hvilken tidsinndelinger de benytter. Applikasjonen skal kunne brukes av flere klienter lokalt. Etter dialog med bedriften ble det stilt følgende krav til applikasjonen: Oppdatering imellom klienter skal foregå i realtime Klient B skal ikke kunne overskrive en post som klient A har åpen Det skal være mulig å endre tidsintervallene på inndelingene. Det skal være ulike brukergrupper med tilhørende forskjellige rettigheter Applikasjonen skal kunne jobbe opp imot en et timebestillingssystem som skal integreres mot deres hjemmeside. Applikasjonen skal kunne brukes til å presentere historiske og fremtidige poster på storskjerm ved kundemottaket.

11 2.1.6 TEKNISKE KRAV Utvikles i MS Visual Studio 2008 med C# som programmeringsspråk. Utvikles i Qt Creator med C++ som programmeringsspråk. Lagring av database skal skje i SQL Server Management Studio Express. Applikasjonen skal kunne kjøres på en Windows Server. Nettsiden skal være utviklet ved følgende programmeringsspråk: HTML, CSS og Javascript. 2.2 DATALAGRING For å håndtere datalagring meste mulig fornuftig, har lagt frem noen krav som vi alle i gruppen har noen å tenke mens vi utvikler programmet. All data skal være skjult for andre, bare de ansatte skal ha muligheten til å se data. Database til systemet skal være normalisert DESIGN Sidene skal være mest mulig brukervennlig, oversiktlig, behagelig, profesjonelle og ryddige. For å kunne bruke siden, skal det ikke kreves noen krav fra brukerne for å kunne bruke siden. For å navigere gjennom siden, skal brukeren mest mulig komme dit ved få museklikk, og med dette gjelder det for både kundesiden og administrator siden. Siden skal være selvforklarende og enkle navigeringssystem slik at brukeren skal aldri tvile på hva han gjør BRUKEGRENSESNITTET Applikasjonene bør være så enkel og intuitiv å bruke som mulig. Det er ønskelig at en person uten videre IT-kunnskap skal kunne sette seg ned og bruke det uten problemer. Samtidig er det ikke ønskelig at dette skal gå ut over programmets funksjonalitet KODEKRAV Koden skal være oversiktelig og følge samme standard. Det skal gå frem av navnet til en metode og en variabel hva denne gjør/inneholder. For eksempel vil en metode som sletter en kunde fra databasen gjerne kalles "fjernkunde" eller "slettkunde" i stedet for noe mer kryptisk som "metode5". Koden skal også kommenteres flittig. Helst skal enhver metode og variable forklares v.h.a. kommentarer. Dette er for å gjøre jobben enklere for en vedlikeholder eller en eventuell videreutvikler av programmet.

12 2.2.4 KRAV TIL DOKUMENTASJON Det ferdige dokumentet skal beskrive alt som er blitt gjort gjennom denne prosjekt perioden. Det ferdige dokumentet skal bestå av: - Kravspesifikasjon, definering av kravene til systemet. - Prosessrapport, beskriver arbeidet i de forskjellige fasene. - Produktrapport, beskriver systemet. - Testrapport, tester som har blitt utført og resultatet. - Brukerdokumentasjon, brukerveiledning. Under prosjektoppgaven, synes vi at en dagbok er et verktøy som kan bli nyttig å bruke ved seinere tid. Derfor har vi bestemt oss for å skrive dagbok så ofte vi kan, helst hver eneste gang vi jobber sammen VIDEREUTVIKLING Hele systemet skal være programmert på en strukturert måte for fremtidlige videreutvikling. For å få systemet til å være lettere videreutvikling, skal vi kommentere mest mulig av kildekoden og et dokument som er godt bygg opp for de andre enn oss som skal videreutvikle.

13 3 PRODUKTET 3.1 PRODUKTINNLEDNING I dette dokumentet vil du finne forklaring om produktet vårt for hovedprosjekt. Her vil du nærmere forklaring om hvordan vi ha klart å utvikle produktet 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 VÅRE INFRASTRUKTURELLE ØNSKER OM ENDRING Forslag: Oppgrader internettabonnementet til en raskere linje Grunnlag: En lokal IIS server krever en rask og stabil linje for at nettbutikkbrukere skal kunne bestille varer. Resultat: Bedriftens lokasjon er mer enn 4km unna nærmeste DSLAM. Vi ser det som mest logisk å sette opp et replikasjonssystem mellom bedriftens database og webhotellets databaseserver. Forslag: Endre webhotell til UniWeb.no Grunnlag 1: Visma sin database er av type Microsoft SQL. Dersom vi skal replikere den er det av ytelsesmessige forhold en fordel å replikere den til en identisk database. Grunnlag 2: Vi ønsket å utvikle en online timebestillingsapplet i C# (.NET). Appleten må dermed kjøres på en Microsost IIS Resultat: Abonnementet hos uniweb ble opprettet. Forslag: Kjøp en lisens av Microsoft SQL Server Standard Edition Grunnlag1: Trigger/Prosedyre replikasjon er en treg og usikker måte å kopiere databaser på. Grunnlag2: SQL Server replikasjon fungerer ikke på SQLEXPRESS (krever minimum Standard Edition) Resultat: Lisens kjøpt. 13

14 3.2 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 o Ansatte skal ha mulighet til å opprette/endre/slette reservasjoner o Skal kunne presentere data om hva som skjer nå og hva som skjer snart på en storskjerm i værkstedet. Hjemmeside o Skal være en oversiktlig side. o Siden skal være mest mulig brukevennlig. 14

15 3.2.1 SAMSVAR MELLOM KRAVSPESIFIKASJON OG PRODUKTET Etter flere måneder med programmering og planlegging har vi nå kommet frem til et sluttprodukt, vi selv er fornøyd med resultatet. I produktet vil nå inneholde en ny hjemmeside, reservasjon for servicetimer, dekkhotell og nettverkskalender for håndtering av den administrerte delen. Om vi har klart å følge kravspesifikasjon, vil vi selv si at vi har klart det bra. Vi har ikke klart å opprette en webshop for bedriften, siden det var litt problemer fra arbeidsgiveren vår fylle kravene for at en webshop skulle til. Siden en webshop var blitt skrevet i kravspesifikasjonen, er det bare de punktene som hører til webshop som ikke har blitt oppfylt. Dette har vi da tatt med vår oppdragsgiver, og vi selv har lovet bedriften å fullføre hele prosjektet når oppdragsgiveren har fått på plass kravene for å lage en nettbutikk TEKNOLOGI Siden oppdragsgiveren lot oss stå ganske fritt til å velge type teknologi vi skulle bruke, valget falt ganske fort at vi skulle bruke MS Visual Studio 2008 og Qt Creator. Grunnen til at vi har falt for valget av disse to, er for at vi bestemte å velge den plattformen vi følte oss mest trygg på og samtidlig fornye kunnskapene, BESKRIVELSE AV TEKNOLOGI MS Visual Studio 2008 MS Visual Studio 2008 har vært til bruk for det meste i vårt hovedprosjekt, siden det er raskere og enklere å lage en nettbasert applikasjon. Dette er fordi MS Visual Studio inneholder mange ferdige kontroller og komponenter for funksjoner som ofte er brukt på en webside. I Figur 1.1 vil det vise hvordan MS Visual Studio 2008 blitt tatt i bruk. 15

16 Fig 1.1 MS Visual Studio 2008 MS SQL Server Management Studio Express Dette programmet, med det noe lange navnet, gir et grensesnitt mot databasene på serveren. Dette gjør det enkelt å sette opp en database med tabeller uten å måtte skrive koden i SQL. Qt Framework Qt er et brukergrensesnitt - rammeverk opprinnelig laget for C++. Det ble først utviklet av norske Trolltech før det ble overtatt av Nokia i Det inneholder en rekke biblioteker som gjør bl.a. UI -oppsett og databasebehandling enkelt. Qt Creator Qt Creator er programmet applikasjonen er laget med. Programmet er egentlig ment for å enkelt sette opp brukergrensesnitt. Det gjør man ved å dra de forskjellige enhetene ut på et brett og så genererer programmet kode for dette oppsettet. For denne applikasjonen er all kode skrevet selv, men programmet er brukt da det gir et fint grensesnitt som gir muligheten for å bruke en del snarveier og har en fin "gjettefunksjon" som gjør at det går raskere å kode. Figur 1.2 viser Qt Creator i bruk: 16

17 Fig 1.2 Qt Creator C++ C++ er et multiparadigme - programmeringsspråk videreutviklet fra C av dansken Bjarne Stroustrup. Det har bl.a. støtte for objekt - orientert programmering, noe som passer fint, da applikasjonen gjerne skal være mulig å videreutvikle. C# (C Sharp) C# er et programmeringsspråk for objektorientert programmering, er utviklet bla. for programmering i.net.(asp). C# er basert på programmeringsspråkene ene C++ og Java. SQL SQL, som de fleste mener står for Structured Query Language, er et databasebehandlingsspråk. Det har vært viktig å ha kjennskap til da applikasjonen benytter seg av databaser. 17

18 3.3 DEKKHOTELL DATASTRUKTUR OM DATAFLYTEN: Fig 2 Fig 2 viser hvordan applikasjonen skriver og henter data fra/til databasen via en server via ODBCgrensesnittet Om databasen: Databasens oppsett var viktig for hvordan applikasjonen skulle fungere. Den var derfor noe av det første som ble laget. Den har gjennomgått små endringer, men er i hovedtrekk lik føsteutkastet. Den ble først designet i Database Designer 4, et program det er enkelt å sette en E/R-modell opp i, vist i figur 3.1: 18

19 Fig 3.1 Databasen består altså av de fire tabellene Kunde, KundePlass, Plass og Lager. Til å sette opp databasen, definere tabellene og legge inn data brukte jeg MS SQL Server Studio Express. Skjermdumpene som kommer i neste segment er tatt derifra og viser tabellen med data fra testeprosessen som illustrerer hvordan det vil se ut når applikasjonen er i bruk. Jeg vil kort gå gjennom bakgrunnen for hver av tabellene: Kunde Fig

20 Tabellen vis i figur 3.2 er til for lagring av informasjon om kundene, som her mer konkret er personer som benytter seg av Dekklåvens tilbud om å lagre dekk for dem avhengig av sesong. Primærnøkkelen er Id, som gis automatisk av systemet (auto increment). Dette er for å ha en unik identifisering for hver kunde. Ellers lagres navn og nummer, som folk husker bedre enn en Id og som gjør at man kan komme i kontakt med kunden. Tabellen har en n:m-relasjon med tabellen Plass da en kunde kan ha flere lagringsplasser og en plass kan i tidens løp benyttes av forskjellige kunder. Plass Fig 3.3 I tabellen, som vises i figur 3.3, lagres informasjon man trenger å vite om en plass hvor et sett med dekk ligger. Et lager (Lager_Id) har et sett med plasser (Plass), som igjen har et undersett med plasser (UnderPlass). Kolonnen "Ledig" er av typen bit og kan inneholde verdiene 1 eller 0. Dette vises som True og False i Studio Express der de henholdsvis representerer 1 og 0, logisk nok. Disse to tabeller er koblet sammen ved hjelp av en database kalt KundePlass: KundePlass Fig 3.4 I tabellen som vises i figur 3.4, er plassen hvor kunden har fått lagret sine dekk beskrevet. Det kan se litt rått/grovt ut så i programmet vises navnet på kunden i stedet for Kunde_Id. Lager Tabellen Lager er enkel. Den har en kolonne, Id, som er primærnøkkel og settes automatisk. I tillegg har den en kolonne som heter "Kommentar", hvor man kan skrive en kommentar som gir mening for de som jobber der. For eksempel hvor lageret ligger/hvilket lager det er. 20

21 3.3.3 OPPBYGGING OG VIRKEMÅTE FOR DEKKHOTELL Programmet består av 4 hovedklasser som henger sammen som vist nedenfor: Fig 4 Pilene i figur 4 indikerer at klassene det pekes på ligger i klassene det pekes fra. Oppbygging og virkemåte Dialogen Dette er klassen hvor hovedbrukergrensesnittet ligger, vist i figur 5.1: Fig

22 Den består av en rekke layouts som er lagt i forholt til hverandre. Et eksempel: linjelayouten.addwidget(etternavn); linjelayouten.addstretch(); linjelayouten.addwidget(etternavnle); Her legges labelen "Etternavn" og LineEditen "etternavnle" etter hverandre horisontalt. Det samme skjer med "Fornavn" og "Tlf", som man kan se under "Søk:" i midten til høyre. Disse tre layoutene legges så i en layout for hele høyre segment: hoyrelayout.addwidget(knappeboks); hoyrelayout.addspacing(100); hoyrelayout.addwidget(soeklabel); hoyrelayout.addlayout(&linjelayouten); hoyrelayout.addlayout(&linjelayoutto); hoyrelayout.addlayout(&linjelayouttre); hoyrelayout.addstretch(); hoyrelayout.addlayout(&knapplayout); Knappene nedenfor den store tabellen som tar opp mesteparten av plassen skiftes ut etter hva som er naturlig i henhold til innholdet i tabellen. Dette endres ved at brukeren kan skifte mellom hva han vil se oppe i høyre hjørne. Radioknappene der er bundet sammen med metoder som endrer på oppsettet for Uiet: connect(kunde,signal(clicked()),dbv,slot(kundeview())); connect(kunde,signal(clicked()),dbv,slot(oppdater())); connect(kunde,signal(clicked()),this,slot(kundelayout())); Når kunde, som er navnet på radioknappen med tilhørende label "Kunde" blir trykket på, sender den ut signalet clicked(). Som jeg her binder sammen med metoden kundeview() og oppdater() fra DBView, som kort fortalt setter tabellen til å vise informasjon om alle kunder. Tilslutt binder jeg signalet til en metode i Dialogen som setter opp Layoutet slik at knappene passer overens med at det er info om kunder i tabellen. Tabellen er klassen DBView. DBView DBViews har Qt-klassen QTableView, som er en tabellklasse som kan inneholde og presentere forskjellige typer informasjon, som hovedwidget. Klassen inneholder fire forskjellige modeller som innehar informasjonen til hver av tabellene i databasen. En av dem er en QsqlRelationalTableModel, kalt model: model = new QSqlRelationalTableModel(this); model->settable("kundeplass"); model->setrelation(0,qsqlrelation("kunde","id","enavn")); model->setsort(0,qt::ascendingorder); model->setheaderdata(0, Qt::Horizontal, "Navn"); model->setheaderdata(1, Qt::Horizontal, "Plass"); model->setheaderdata(2, Qt::Horizontal, "UnderPlass"); model->setheaderdata(3, Qt::Horizontal, "Lager"); model->select(); 22

23 SetTable() angir hvilken tabell fra databasen den skal bruke. SetRelation setter en relasjon mellom tabellen og en annen tabell som har relasjon i databasen, slik at man kan representere informasjon fra begge tabeller på likt. Her blir det f.eks. Ssatt en relajson til "Kunde" og "Id" fra "Kunde" vises i stedet som "Enavn" fra samme tabell. Dette fører til at "Kunde_Id" i "KundePlass" blir vist som "Enavn" fra "Kunde". Informasjonen i modellen vises i QtableViewet kalt "view". Det skiftes enkelt mellom modellene ved å knytte modellen til viewet med metoden setmodel(). Klassen DBView inneholder også noen viktige metoder, bl.a. for å fjerne kunder fra databasen. Dette skjer i metioden fjernkunde(qmodelindex index). Hovedtrekkene i den er: QSqlRecord rec = kundemodel->record(index.row()); QsqlRecord trekker ut en rekke fra en av modellene, så de blir en kopi av en rekke i en av tabellene i databasen. Hvilken rekke dette er er avhengig av hvilken index som blir sent til metoden. Indexen som er indexen til den rekken som er uthevet i tabellen i det modellen blir kalt. FjernKunde blir kalt av at knappen "Fjern Kunde" trykkes på. Da blir indexen til den kunden som er valgt sent til metoden og informasjon om denne kunden havner i QsqlRecord rec. Brukeren blir først spurt om han virkelig vil slette brukeren, hvis ja går metoden videre for å sjekke om kunden som skal slettes har noen dekk på lageret: QString str = "Kunde_Id = "; str.append(rec.value(0).tostring()); model->setfilter(str); model->select(); Qstringen "Kunde_Id = " får lagt til seg første verdi i rec, som er Id til kunden som er valgt. Str er nå f.eks. "Kunde_Id = 11". setfilter(str) fungerer som en WHERE str i modellen og modellen vil etterpå inneholde info om kunden som har Id lik 11. Brukeren blir informert og bedt om å ordne opp i det dersom kunden han prøver å fjerne er registrert med dekk på lageret. Hvis ikke: str.remove(0,6); editmodel->settable("kunde"); editmodel->setfilter(str); editmodel->select(); editmodel->removerows(0, 1); editmodel->submitall(); "Kunde_" fjernes fra str og det blir satt som filter i modellen som nå inneholder tabellen "Kunde". Der blir den slettet med removerows(0,1) som sletter alle rader fra indeks null helt til én i tilfelle en feil skulle ha gjort at flere rader ble med. DBView inneholder en egen klasse som fungerer som et skjema for å legge til Kunder i databasen: 23

24 LeggTilKunde Fig 5.2 Klassen, hvis brukergrensesnitt er vist i figur 5.2, sitt mål er hovedsaklig å legge en kunde til i tabellen "Kunde" if(linediten->text().length()>0 && lineditto->text().length()>0 && linedittre->text().length()>0) { } modell->insertrow(0); modell->setdata(modell->index(0,1), linedittre->text()); modell->setdata(modell->index(0,2), linediten->text()); modell->setdata(modell->index(0,3), modell->submitall(); lineditto->text()); emit closing(); this->close(); Dersom alle feltene er fylt ut settes en tom rad inn i modellen som inneholder tabellen "Kunde". Den blir fylt med data fra feltene og det blir lagret til databasen med submitall(). 24

25 LEGGTILLAGERPLASS Fig 5..3 Denne klassen, vist i figur 5.3, gjør mye av det samme som LeggTilKunde. Man velger en ledig plass og trykker på en knapp "Registrér lagerplass" slik at vinduet kommer opp og man velger en person som skal ha lagerplassen med "Velg Kunde". Dersom det er en ny kunde benytter man seg av "Legg til ny kunde" som åpner opp et LeggTilKunde-vindu. Dersom vinduet blir lukket uten at man har valgt en kunde blir ingenting endret i databasen. Main Main er klassen hvor Dialogen blir instansiert og hvor applikasjonen blir koblet til databasen. Det skjer slik: QSqlDatabase db = QSqlDatabase::addDatabase("QODBC"); db.sethostname("localhost"); db.setdatabasename("dekklaaven"); db.setusername("admin"); db.setpassword("administrator"); Dette er koden jeg har brukt til å koble meg på den lokale databasen på maskinen min. Databasenavnet blir her navnet på ODBC-linken mellom applikasjonen og databaseserveren. 25

26 3.4 NETTVERKSKALENDER DATASTRUKTUR OM DATAFLYTEN For å unngå å bruke unødvendige ressurser til oppdatering av C# sine datagridview (for presentasjon av inndelingsdata) valgte vi å mellomlagre all data som er presentert på skjermen via en timerfunksjon som kontinuerlig gjør nye spørringer mot databasen. Hvor rask oppdateringsfrekvensen mellom bufferen og databasen er valgte vi å legge som et radioknappalternativ ved pålogging hvor en kan velge mellom tilhørende valg: Puls Hastighet Notat Lav 5000ms Tilpasset for VPN Medium 500ms Rask 100ms Krever rask klient Vi fant det mest naturlig å presentere de ulike formene ved tabcontrols. For å gjøre utviklingen av designet mer fleksibelt lagde vi separate UserControls til hver tabpage som vi knyttet sammen I designerfilen som tabcontrolen lå I (HovedVindu.Designer). Generelt ønsket vi å bruke et nøytralt fargevalg på layotet. Vi ønsket å gjøre alle farge, font og størrelsesmessige innstillinger brukerspesifikke. Dette løste vi ved å opprette profilvariabler i program.resources som skriver til xml uten at en trenger å håndtere dette selv. Når brukeren avslutter applikasjonen lagres også vinduspossisjoneringen lokalt slik at den blir identisk ved neste oppstart. Applikasjonen er tilpasset 800x600 oppløsning som minimum, og skalerer seg dynamisk dersom skjermen er større i form av at de mest essensielle enhetene skaleres oppover. tabpage Navn Beskrivelse 1 Kalender Her lagres, endres og vises data i alle inndelingene. 2 Intradag Denne siden er konstruert for å vise historie/fremtidige poster på storskjerm 3 Inndelinger Her kan administratorbrukere opprette nye eller slette inndelinger. 4 Status For presentasjon av statistikk 26

27 Modellering og Design Selve kalenderen (til høyre på bildet) viser kun de dagene som er blitt generert under Inndelinger Funksjonalitet og Sikkerhet Applikasjonen skal være enkel å bruke samt logisk annlagt. Vi fikk relavtivt frie tøyler når det gjaldt utformingen så vi ønsket å begrense funksjonene til det minimale etter hva hver enkelt bruker har behov for. tabpage4 (Inndelinger, bilde under) Viser vår schedueler som genererer fremtidige inndelinger. Integritetsmessig er det viktig at det ikke skal være mulig å opprette 2 individuelle inndelinger som kolliderer. Vi har derfor lagt vekt på utfyllende feilbeskrivelser dersom tilfellet skulle oppstå. Under Instillinger er det flere spesifikke detaljer som kan endres, deriblant når en varsling skal intreffe for at ny generering må foretas OM DATABASEN Databasen ble designet med 27

28 MS SQL Server Management Studio og inneholder 4 tabeller i relasjon, samt en spesifikk tabell [dbo].konfigurasjon som inneholder 40 kolonner med spesifikk informasjon over fremtidige inndelinger Databasen består av følgende tabeller: UserPrivelege, UserRole, Bestillinger og LanBrukere. 28

29 Bestillinger I Figuren 6.1 vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur 6.1Definering av tabellen Bestillinger Tabellen bestillinger inneholder alle reservasjoner i kalenderen. For å opprette en reservasjon, har kunden muligheten til å opprette. Men det er ikke bare kunden som har muligheten til det, de ansatte har selv fri tillatelse for å opprette en reservasjon, enten det er via administratorverktøyet eller brukergrensesnittet på hjemmesiden. LanBrukere I Figuren 6.2 vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur 6.2 Definering av tabellen LanBrukere Tabellen LanBrukere 29

30 håndtere brukerinformasjonen til de som kan logge på administrasjonsapplikasjonen. 30

31 UserPrivelege I Figuren 6.3 vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur 6.3 Definering av tabellen UserPrivelege Tabellen UserPrivelege definerer de ulike privelegiumene en rolle kan ha. Tabellen UserRole binder en rolle til et sett med privelegier. I Figuren 6.4 vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur 6.4 Definering av tabellen UserRole. UserRole er en enkel tabell hvor det viser hvilke type roller det er i systemet, og hvilket tillatelse hver rolle har. Nettverkskalender 31

32 3.4.2 OPPBYGGING OG VIRKEMÅTE FOR NETTVERKSKALENDER To innledende paradokser Det første paradokset vi møtte var at det er to ulike fremgangsmåter for å lage en nettverkskalender på, hru: Metode1: Generere SQL data on-the-fly Beskrivelse: Når en bruker velger en kalenderinndeling vil applikasjonen først se om dagen eksisterer, deretter vise dagen ved eksistens eller generere inndeling ved non eksistens. Styrke: 1. SQL databasen vil kun inneholde tabeller med relevant data. 2. Data I uendelig fremtid kan genereres (pr. definisjon også en svakhet) Svakhet: 1. Applikasjonen vil bli tregere siden det må kontrolleres om inndelingen eksisterer hver gang en ny dag skal vises. 2. Større databasetrafikk Metode2: Forhåndsgenererte inndelinger Styrke: 1. Switching mellom dager vil gå raskt. 2. Klientene trenger kun å ha tilgang til å oppdatere eksisterende poster. 3. Lettere å håndtere spesielle virkedager (i.e. bevegelige helligdager) Svakhet: 1. Store inndelinger vil kreve mye maskinkraft å generere. I.E: En bedrift åpner 0800 og stenger 1800, de ønsker 5min intervaller som skal utspennes over 2 forskjellige porter/betjeninger. Det gir oss følgende regnestykke: (10timer x (60/5) inndelinger pr.time) x 2 porter x 365dager x 3år = unike rader 2. Mye tomrom vil eksistere i databasen. Ved å konstruere begge strukturene fra begynnelsen av kunne vi konkludere med at metode2 var ytelsesmessig overlegen. I vårt testeksempel ble en dag med 20 inndelinger gjennomsnittlig lastet på 200ms ved metode 1 mot 25ms ved metode2. 32

33 Beskrivelse av klasser Programmet består av en HovedVindu klasse inneholder en tabcontrol som initialiserer alle andre klassene ved en suksesfull pålogging. HovedVindu.Cs inneholder også funksjonaliteten som sprer seg over alle tabpagene, hru. print/søk/meny/avslutt samt filskriving for å lagre profildata (farge/font instillinger) lokalt til XML. Login.Cs Dette er en egen applikasjonsform som kalles fra HovedVindu.Cs før komponentene I HovedVindu.Cs blir initialisert. Dersom påloggingen er vellykket lagres det brukerrelatert data tilbake til ressursfilen Program.Resources som benyttes videre for presentasjon av riktig layout ihht. innloggedes rettigheter. UserControlKalender.Cs Dette er den første kontrollen som lastes etter en vellykket pålogging. Den inneholder litt over 2000 linjer med spesifikk data UserControlIntradag.Cs Denne klassen inneholder nødvendige metoder for presentasjon av intradagen til Storskjerm. Den ligger under tabpage UserControlInndelinger.Cs Her ligger alle metodene bak generering av inndelingsdata. UserControlStatus.Cs Inneholder en oversikt over bl.a. antall innloggede brukere, antall lagrede poster, dager igjenn før kalenderen utløper (før ny generering må foretas). SQLMetoder.Cs Her ligger det spesifikke sqlmetoder som er tilbruk i mer enn 1 klasse. Deriblant metoden sikkertekst(string s) som returnerer en bool som representerer om teksten som skal settes inn I databasen er injectionsikker. UserControllInnstillinger.Cs Denne UserControlen lastes via applikasjonsformen Instillinger.cs. Kontrollen inneholder innstillinger som berører alle de andre tabsidene. Properties.Resources Visual Studio sitt XML lager for brukerprofiler Beta testing 33

34 Første betaversjonen vi installerte hos Dekklåven la vi inn med en oppdateringspeker mot vårt hjemmeområde på HiO. Under hele betaperioden publiserte vi nye versjoner hvor beta applikasjonen benyttet PULL prinsipp for å søke etter nye oppdateringer mot HiO ved oppstart. Vi anbefalte bedriften å fortsette den ordinære bokføringen av timebestillinger i exceldokumenter de første 2 ukene av testperioden Etter den første måneden begynte det å bli færre oppdateringer og vi fjærnet dermed linken mot HiO for at applikasjonen skal fremtre raskere ved oppstart. Vi brukte deretter Advanced Installer som installasjonsprogram og tilføyde en enkel EULA. 34

35 Oppbygning og virkemåte for online reservasjon av timer Navigeringsmodell Figuren 7.1 viser flyten i reservasjonssystemet. For å starte reservasjonen må kunden ha valgt en bestemt dato for å se når det er ledige reservasjoner. Kunden har hele tiden muligheten til å velge en annen dato til seinere tid. For videre reservasjon, må kunden da velge det tidspunktet som passer og den ledige plassen som er ledig på det tidspunktet. Når en bruker har valgt dato, tid og plass, vil det sende brukeren til neste steg hvor det blir å skrive kommentarer til verkstedet. For å foreta en reservasjon, må brukeren gjennomføre fire skjermbilder. Figur 7.1 navigering for reservasjon. Steg 1: Forside Når man har fått valgt Timebooking fra hovedmenyen, vil man komme til forside for reservasjon. Steg 2: Logg inn/registrere ny bruker Før en bruker kan velge dato for reservasjon, må bruke ha autorisert tilgang for å kunne reservere. Dette vil si at brukeren må enten være logget som kunde eller administrator. Hvis brukeren ikke har innlogging, kan brukeren eventuelt opprette en konto. Steg 3: Velge dato Her må brukeren velge en dato for å kunne navigere seg videre i prosessen. For at det skal bli reservert på samme dato som brukeren har valgt har det blitt bruke med følgende metode for å kontrollere at brukeren valgt riktig dato. Deretter vil den videre hente timeplanen for det valgte dagen. private void LoadData() { if (! (calbestillingdato.selecteddate == DateTime.MinValue)) { 35

36 // En validert dato har blitt valgt i kalenderen. Henter TimePlanen og binder den til TimePlan control. TimePlan1.DataSource = BestillingManager.GetValgAvTime(calBestillingDato.SelectedDate); TimePlan1.ValgtDato = calbestillingdato.selecteddate; TimePlan1.DataBind(); } } Steg 3: Velge tid og plass Etter å ha valgt en validert dato, vil brukeren bli sendt videre til timeplan hvor brukeren vil få en oversikkt over når det er ledige servicetimer på verkstedet.i Figuren 7.2 er det et eksempel på hvordan en timeplan med en plan over ledige timer. Figur 7.2 Servicebestilling 36

37 3.5 NETTBUTIKK PLANLEGGING Vi begynte å planlegge nettbuttikken tidlig i prosjektet, og fikk tidlig øye på Visma sin egne netthandelløsning med navn Visma Zpider. Etter dialog med en av norges ledende Vismaforhandlere fikk vi en hyggelig pris på produktet og godkjent det av Dekklåven. Fordelene ved å ta ibruk Zpider var mange, deriblant at vi kan bruke Visma Global som de ansatte allerede kjenner til for å administrere store deler av nettbutikken. Noen dager etter dette kom fakturaen I posten med en pris som var på ett 6 siffret beløp og endte på 12ganger mer enn hva vi I utgangspunktet ble tilbudt. Lettere sjokkert tok vi kontakt med forhandleren og fikk høre at det var en prisøkning som Visma Norge hadde lagt på sin ehandelløsning og som de dermed ikke kunne gjøre noe med. Dette resulterte i at vi måtte begynne å se oss over gjerdet etter andre løsninger. Etter et kort møte med vår bedrift kom vi til enighet om at løsningen ble for dyr og at vi skulle forsøke å lage en egen løsning som leser ut nettbutikk relatert aktivitet fra visma ANALYSE AV VISMA Visma benytter Microsoft Sql Server til å holde kustus på dataene. Ved å logge seg på databasen via Management Studio kunne vi se følgende: 1. Databasen består av 389 forkjellige Tabeller og 51 ulike prosedyrer. 2. Relasjonene mellom tabellene er applikasjonshåndtert, de fremgår dermed ikke I databasen. Koneskvensen av dette er at vi må selv finne hvilken relasjoner som er skapt mellom de forskjellige tabellene som er nødvendige for å bruke en nettbutikk interaktivt mot Visma Global. For å finne hvor de nødvendige postene som er relatert til eshop legger seg begynte vi med å skape 1 ny artikkel med artikkelnr Når vi opprettet denne artikkelen la vi inn et bilde ved navn Image1.jpg som vedlegg til artikkelen. Deretter sjekket vi av for publiser på nett og tok en ny backup av Visma sin SQL database for å finne relasjonene. Ved å bruke en egen prosedyre for å gjennomføre et søk igjennom alle tabeller og tilhørende kolonner I databasen etter artikkel 3100 og bildenavn mini.jpg (se vedlegg 1 for prosedyre) fant vi følgende data: Funn etter Artikkel 3100: [dbo].dekklven.article.showonwebyesno (tinyint) ble endret til fra 0 til 1 Funn etter Bilde mini.jpg [dbo].dekklven.savedpictures.picturename (image) ble endret til mini.jpg Relasjonen til de 2 overnevnte fant vi I [dbo]. Dekklven.Event der Keyvalue (Artikkelnr) var linket med DocumentPointer (PictureId fra SavedPictures). Ved å fortsette søk etter bla. Enheter I lagerbeholdning, artikler I bestilling, kampanjepriser, enhetsvekt etc kunne vi tegne oss ett bilde av hvilken tabeller vi trenger å manipulere for å få Visma til å administrere hvilken artikler som skal publiseres på nett. 37

38 3.5.3 DATAFLYT De aller fleste som oppretter en egen nettbutikk mot en lokal database setter opp en egen server mot internet (heretter forkortet IIS). I dekklåvens tilfelle hvor de er begrenset til en 1024/256kbit linje vil dette være en dårlig løsning som videre fører til misfornøyde kunder. Alternativ A) Egen webserver Siden Dekklåven ikke har egen IIS og deres internettlinje er alt for liten til at det er aktuelt å sette opp en, fant vi kun èn fornuftig måte å opprette nettbutikken på. Via databasereplikasjon. Alternativ B) Replikert database KONKLUSJON Under analysen av de andre tabellene vi trengte for å skape en komplett replikasjon fant vi ut at bedriften må foreta en ny fysisk lageropptelling av alle artikler i lagerbeholdningen, da artikler med beholdning i form av bokstaver eller negative tall er vanskelige å håndtere I en nettbutikk. Dette samt at alle artiklene må taes bilde av under samme lysforhold (fotoboks) var det ønskelig fra Dekklåven sin side å engasjere oss til å fullføre nettbutikken som en sommerjobb i tråd med at de skal oppgradere/bytte alle sine maskiner samt flytte kontorlokalene sine i nevnte periode. 38

39 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 Figur 8.1 er den oversikt over videre framdrift for prosjektarbeidet. Den viser hvilke deler av oppgaven er estimert til. 39

40 Fig 8.1 Oversikt over utviklingen. 40

41 I Figur 8.2 viser det en tabell over når de ulike oppgaver er blitt estimert til. Fig 8.2 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 Fig 8.3 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 41

42 Webutvikler Nikolai Godager Kevin Holmvik Prosessdokumentasjon Chau Quoc Do Produktdokumentasjon Chau Quoc Do Alle Alle Sluttdokumentasjon Nikolai Godager Chau Quoc Do Risikoanalyse Einar Drivdal Nikolai Godager Backup ansvarlig Einar Drivdal Kevin Holmvik Fremdriftsplan Chau Quoc Do Nikolai Godager Modell beskrivelse Kevin Holmvik Einar Drivdal Kvalitetssikring Alle Fig 8.3 Ansvarsområder 4.4 METODER 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 9.1 viser den en fossefallsmodell hvor vi har hele tiden har muligheten til å gå tilbake til tidligere faser og eventuelt implementere nye funksjoner. 42

43 Fig 9.1 Fig 9.1 Fossefallsmetoden 43

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

45 4.4.4 SPRÅK C# o Dette er det programmeringsspråket som har blitt brukt mest under utviklingen. C++ med 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. 45

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