Forord Denne rapporten skal fortelle om prosessen for prosjektarbeidet vårt, hvordan vi har jobbet og gått frem fra begynnelse til slutt i forhold til blant annet hvordan vi har planlagt og arbeidet. Den vil også gi innsikt i hvilke verktøy vi har benyttet oss av og hvilke rammebetingelser vi har hatt å jobbe innenfor. Hovedfokuset i oppgaven ligger på databasesystemet. Denne rapporten er egnet for sensor, veileder, oppdragsgiver og andre som er interessert i prosessen for vårt arbeid. Vi tok kontakt med flere bedrifter, og en av tilbakemeldingene vi fikk var fra Nor dagligvare import som fortalte at de har behov for et databasesystem som ordner fakturer, ansattregistrering, leverandørregistrering, totalt kjøp, og diverse andre funksjoner som er mer nøyaktig spesifisert i kravsepesifikasjonen. De hadde også behov for en webside, siden de ikke hadde en fra før. Etter første møte bestemte vi oss for at vi skulle jobbe med prosjektet fra Nor dagligvare import. Underveis i prosjektet fikk vi flere krav spesifisert fra oppdragsgiveren, og prosessen var slik at hver gang vi var ferdig med en funksjon så kom oppdragsgiveren med nye funksjoner. Det har derfor blitt mange forandringer underveis prosessen, og vi hadde flere møter med oppdragsgiveren. Hver gang vi var ferdig med en funksjon måtte vi teste det i bedriften med noen praktiske oppgaver, for eksampel i faktura registrering. Det kom mange nye funksjoner etter hvert, og til slutt testet vi hele systemet i bedriften og det fungerte på en veldig tilfredsstillende måte. 1
Innholdsfortegnelse 1. Innledning... 3 1.1 Gruppen... 3 1.2 Arbeidsgivers bedrift... 3 1.3 Dagens situasjon... 3 1.4 Mål for prosjektets utforming... 4 1.5 Faglige mål... 5 1.6 Rammebetingelser... 5 1.7 Oppdragsgivers krav... 9 2. Planlegging og metode... 10 2.1 Valgt systemutviklingsmetode... 10 2.2 Verktøy... 11 2.3 Programmeringsspråk... 12 2.4 Fremdriftsplan... 12 2.5 Risikoanalyse... 13 2.6 Tilegne seg ny kunnskap... 16 2.7 Tilbakemelding fra oppdragsgiver... 16 3.Utviklingsprosessen... 16 3.1 Prosjektstart... 16 3.2 Valg av oppdragsgiver... 16 3.3 Oppbygging av program... 17 3.4 Forhold gruppe- arbeidsgiver gjennom prosessen... 17 3.5 Design webside... 17 3.6 Design database... 18 3.7 Risikoplan... 20 3.8 Backup... 21 3.9 Testing... 21 4. Kravspesifikasjonen og dens rolle... 21 4.1 Endringer på kravspesifikasjon... 22 4.2 Kravspesifikasjon for utvikling i design og implementering... 22 4.3 Samsvar mellom kravspesifikasjon og produktet i produktdokumentasjon?... 22 5. Hvorfor velge Web-basert system:... 22 6. Ikke-funksjonelle krav:... 24 7. Dokumentasjonskrav:... 25 8. Oppsummering og konklusjon... 25 2
1. Innledning Dette kapittelet vil gi informasjon om gruppa, bedriften og bedriftens situasjon, hvilke mål og rammer vi har hatt for prosjektet og hvilke krav arbeidsgiver har gitt oss. 1.1 Gruppen Gruppen ble dannet ved at to av oss kjente hverandre fra før, mens en kom inn litt senere, etter at oppgaven hadde blitt valgt. Vi måtte være minst 3 på gruppen og den siste personen manglet fortsatt gruppe så da ble han med på gruppe 9. Navn Studentnummer Email Kawa Hassan s154121 S154121@stud.hio.no Ahmed Elmir s155502 S155502@stud.hio.no Sindre Tørå s154545 S154545@stud.hio.no 1.2 Arbeidsgivers bedrift Nor Dagligvarer Import AS har tusenvis av kunder og produkter og over 30 ulike leverandører. Bedriften selger og importerer produkter for næringslivet i Norge og de består av avdelinger som blant annet frukt og grønt, kjøttavdelinger og tørrvarer. De har butikker og lager i Oslo. 1.3 Dagens situasjon Nor Dagligvarer Import AS har per dags dato ikke et databasesystem som kan hjelpe de med å få oversikt over bedriften. I dag har de blant annet problemer med at hvis fakturaer har blitt betalt to ganger så er det vanskelig for dem å få oversikt over dette siden de ikke har et databasesystem som kan hjelpe dem med å gi de oversikt over betalte og ubetalte fakturaer. Siden bedriften har mer enn 40 leverandører er det vanskelig å finne frem til spesifikke faktura som er betalt og levert til regnskapet. Det er også tungvint å finne for eksempel 3
telefonnummer eller adresse til spesifikke leverandører eller kunder siden de ikke er registrert i en database. Bedriften har heller ikke en egen webside hvor de blant annet kan reklamere for egne produkter og hvor kunder kan registrere seg og bestille. 1.4 Mål for prosjektets utforming Bedriften ønsker at vi skal lage et godt databasesystem og en webside som vil hjelpe bedriften med å få bedre oversikt over blant annet fakturaer, gjøre det enklere å kommunisere med ansatte/kunder/leverandører med mer, informere kunder om tilbud og nye produkter, øke lønnsomheten for bedriften og lette arbeidet generelt til både ansatte og kunder. Vi har hatt følgende hovedmål for websiden og databasen (mer detaljert oversikt over dette i kravspesifikasjonen): Database o Mulighet for å registrere: Kunder Leverandører Fakturaer Bestillinger Timelister o Søkefunksjoner o Admin-funksjoner Registrere/slette Webside: www.nordagligvare.no o Login-muligheter Admin Vanlig bruker o Blogg For ansatte Eget passord o Kundeside Legge inn tilbakemeldinger 4
1.5 Faglige mål Sette oss mer inn i og utvikle oss mer innenfor bruk av MySQL og å lage databasesystemer Videreutvikle oss i websideutforming med HTML og PHP Samarbeide direkte med en reell bedrift om å utføre en konkret jobb for dem Forberede oss for mulig fremtidige jobbsituasjoner Få bedre kunnskap om å utforme kravspesifikasjoner og testdokumentasjon Å utforme et produkt som kan bli benyttet av en faktisk bedrift, og ikke bare en tenkt oppgave som vi har gjort i tidligere fag 1.6 Rammebetingelser I samråd med oppdragsgiveren vår så fant vi ut av hvilke krav og funksjoner databasen og websiden skulle bestå av. Databasen og websiden skulle være oversiktlige, lette å sette seg inn i og ha mulighet for å utvikles videre etter vi hadde ferdigstilt prosjektet vårt. Vi måtte også tilpasse og begrense prosjektet i forhold til hvor lang tid vi hadde og kom frem til ett størrelsesformat vi følte oss komfortable med. Det er veldig vanskelig å forutsi nøyaktig hvor lang tid man bruker på ett prosjekt så vi belaget oss på at vi måtte komme til å gjøre endringer med omfanget av prosjektet underveis i prosessen. Vi bestemte oss også for hvilke funksjonaliteter og oppgaver som var hovedprioritet og så kunne vi eventuelt legge til annet underveis. Vi har også diskutert med oppdragsgiver om at vi skal ha ett domene for websiden og databasen, og er blitt enige om at dette skal kjøpes. Vi bestemte oss for å benytte PHP, MySQL og HTML for å løse prosjektet. Vi har lært oss å kjenne bedriftens verdikjedeaktiviteter: Bedriftens verdikjedeaktiviteter: I. Støtteaktiviteter: Økonomi: bedriften har en butikk i sentrum av Oslo, og ett lager. Personal: 12 ansatte 5
II. Lønn: Primæraktiviteter: OLFI: MPS: Service: Eieren vet det er lite økonomisk lønnsomt om de fortsetter på samme måten, og de ønsker en løsning. Det må da legges en strategi for forandring(ikt løsning). Målet er å integrere IKT med foretning slik skjemaet viser: 6
Rammebetingelsene skal fungere i samspill med bedriftens strategi som er knyttet til bedriftens IT-strategi: A: ORGANISASJON Medarbeidere Organisasjonsstruktur Rollestruktur Selskapsstruktur Geografisk struktur D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur B: PROSESSER Primær prosesser Støtteprosesser Prosesstruktur E: TEKN. UTSTYR PC-er, Tjenermaskiner Operativsystemer Nettverk/Skrivere Teknisk infrastruktur C: DATA Grunndata Datastruktur De 5 elementene i PSO hos Nor dagligvarer import AS: 1. Virksomhetsperspektivet: Organisasjon: bedriften har 12 ansatte, styreleder og dagligleder. Vi anbefaler en person som er butikk- ansvarlig: En person bør være ansvarlig for butikkdata i bedriften. Ikke nødvendigvis en veldig IT dyktig person (selv om det er en fordel), men en ryddig og fokusert person. Ofte er det vellykket å rekruttere en slik person fra butikken. Da har man også butikkerfaring. Denne personen har ansvar for vedlikehold av grunndata, rutiner for bruk av systemet, support, oppfølging av butikker osv. - en IT ansvarlig person: Denne personen tar avgjørelser rundt valg av programvare og maskinvare, budsjettering, IT strategi, igangsetting av prosjekter osv. Avhengig av kjedens størrelse kan dette være den samme som er butikk dataansvarlig. Den IT ansvarlige bør ha god IT kompetanse og god 7
innsikt i hva IT investeringen skal benyttes til. Data: datamaskiner, database, opplæring av ansatte for bruk de maskinene. F. eks: Når man selger en vare i kassen så trenger vi blant annet å vite hvilken butikk du er i, hvilke ansatte som er innlogget, hvilken vare det er og betalingsmiddel som blir brukt. Alt dette er grunndata som ligger i systemet før man registrerer salget i kassen. Fra datamaskinen får man dato og tid for når noe registreres. Når man så kombinerer disse får en ut et salg i kassen som for eksempel sier at i butikk Storgata den 25. Mars kl. 11:33, har "ansatts navn" solgt en stykk Coca Cola til 15 kroner. Betalingen skjedde med 100 kroner ved bankkort som betalingsmiddel som ga kunden 85 kroner tilbake i kontant. Det er ved å analysere alle disse tusenvis av registreringene at du kan få vite mest mulig om virksomheten din og dermed få et fortrinn foran konkurrentene. For eksempel: Når på dagen selger vi mest? Hva tjener vi på varene? Har vi for mange ansatte? Har det noe effekt å profilere denne varen ved siden av kassen? Hvordan gjorde vi det forrige måned sammenlignet med fjoråret? Mulighetene er uendelige, men felles for de alle er at grunndataene som ligger i systemet må være så korrekte som mulig, ellers blir tallene du får ut av systemet i beste fall unøyaktige, noen ganger helt feil. Har en vare for lav innkjøpspris vil det virke som om du tjener mer enn du faktisk gjør. Prosesser: bedriftens styreleder tar de viktigste valgene, dagligleder tar ansvar for at alle ansatte gjør jobben sin slik at de er effektive og det ikke blir bortkastet arbeidstid. Butikken med definerte rutinebeskrivelser og et opplegg for opplæring av de ansatte får en rekke gevinster: - De ansatte kommer raskt i gang og gjør ting på lik måte. 8
- Man kan enkelt flytte ansatte mellom butikkene - Ting gjøres på riktig måte, slipper å bruke tid på å rydde opp i feil i ettertid. 2. Systemperspektivet: Systemer: For database/programmer har bedriften valgt 24seven Office som løsning. En butikks datainvestering er en langsiktig investering. Mange kjeder har hatt samme leverandør i over 10 år. Må du flytte til en annen leverandør er det en kostbar affære. Regn også med at en del historiske data går tapt på veien. Av den grunn bør man forsøke å finne firma som passer deg og din bedriftskultur. Det bør også være en fornuftig balanse mellom din butikks størrelse og leverandørenes størrelse. En kjede på 10 butikker får kanskje ikke all verdens oppmerksomhet fra de største IT leverandørene, men kan være en viktig kunde for et mindre firma. Ikke alt kan reguleres gjennom avtaler og et godt samarbeidsforhold mellom kjeden og dens partnere får de daglige utfordringene til å gå mye lettere. Teknisk utstyr: bedriften bruker internett som nettverk, skrivere, skannere osv. 1.7 Oppdragsgivers krav Oppdragsgiveren vår har tenkt å bruke open source Linux i bedriften og skal ha databasen på en Linux- maskin. Linux har støtte for PHP så da har de mulighet for å implementere flere andre funksjoner. For eksempel kan de bruke Network file system for å mounte filer midlertidig til en ansatt på en annen ip adresse. Siden. NET ikke støtter Linux så er det vår valgte løsning som vi synes passer best. Oppdragsgiveren skal ha databasen på en Linux maskin i bedriften og ikke i domenet, så Linux er den eneste løsningen for denne oppgaven, og vi har relativt god erfaring med Linux servere. Vi kan derfor implementere dette på en skikkelig måte, og synes vi har valgt riktig løsning for oppgaven. 9
2. Planlegging og metode Dette kapittelet handler om hvilke verktøy og programmeringsspråk vi har benyttet oss av, fremdriftsplan, risikoanalyse, hvordan vi samarbeidet med oppdragsgiver underveis og hva slags kunnskap vi måtte tilegne oss underveis. 2.1 Valgt systemutviklingsmetode Prosessmodell som velges er avhengig av type prosjekt, størrelse og omfang. Gruppemedlemmene er kommet til enighet om å bruke UP(Unified Process) for vi synes den vil passe best for prosjektets mål og prosjektets fremgang. Vi vurderte en kombinasjon av UP og XP(Extreme Programming) som vi tenkte ville gi oss en bra modellerings prosess for å bruke i prosjektet. Men vi valgte til slutt å bruke UP-modellen fordi vi ble enige om at denne modellen passer best til prosjektet vårt, prosessen beskriver hvem som gjør hva, hvordan og når. Denne strukturen passer godt for vårt prosjekt. UP er en agil utviklingsmetode, og det er en avansert metode som er en adaptiv arbeidsmåte, med rask respons på endrede behov i prosessen. I prosjektet hadde vi disse fasene: Idefasen som vi brukte til prosjektskisse (oppdragsgiver beskrev prosjektet: hva går prosjektet ut på), og ordnet kravspesifikasjon. Det er kommet andre/flere krav etter det. Utdypningsfase som for oss vært planlegging (fullføre fremdriftsplan, styringsdokument og planlegging- og arbeidsprosess), forprosjekt (møte med oppdragsgiver, krav om utviklingsverktøy), fullføre kravspesifikasjon og analyse og design (arbeid med de alternative løsningene og jobbe med database modellering og koding). Konstruksjonsfase: datastruktur/ database modellering, implementering, programmering og testing. 10
2.2 Verktøy MySQL Dette er et SQL-basert databaseadministrasjonssystem som kjøres som en server og gir flerbruker-tilgang til et visst antall databaser. MySQL er åpen kode og brukes ofte i forbindelse med skriptspråk som blant annet Perl, PHP, Java, C, og C++. Ganttproject Ganttproject er GPL-lisensiert prosjekthåndteringsverktøy som kan brukes til å produsere Gantt-diagram. IBM Rational Rose: Rational Rose programvare hjelper oss å lage use cases, klasse diagrammer og sekvensdiagrammer. Vi hadde andre mulighet å bruke andre programvare som DIA (vi har brukt dette før, men vi syntes at rational rose er mer fleksibelt og mer komplett enn de andre programvarene). WAMP Server: Vi valgte wamp server 2 fordi den er gratis og den kan bruke både Windows og Linux operativsystem, og fordi vi er vant til den serveren. Og det inkluder Apache (2.2.17), PHP (5.3.3), MySQL (5.5.8), PHPMyadmin (3.2.0.1), SQLBuddy (1.3.2). PHP Designer 2007: Vi brukte php designer 2007 for php programmering og teste koder. Grunnen til det er at vi er vant til det programmet fra før, og vi kan bruke det til andre programmering språk som HTML, CSS og JAVA. Mysql workbench 5.2.33b: Vi valgte mysql workbench som verktøy til å designe tabeller på database. Det er et gratis program, og vi har brukt det før. Den gir DBAs og utviklere et integrert verktøy for miljø: - Databasedesign og modellering sql development. - Database administrasjon(erstatter mysql administrator). 11
Joomla: Vi hadde to muligheter, enten lage en web side selv, eller bruke det som finnes som joomla eller wordpress. Til slutt ble websiden konstruert med Joomla 1.5 som publiseringsverktøy. Joomla er et GPL lisensiert publiseringsverktøy basert på åpen kildekode. www.joomla.org 2.3 Programmeringsspråk Vi har valgt å benytte PHP først og fremst fordi Linux har støtte for PHP og dette er det oppdragsgiveren vår har benyttet seg av. De fleste servere støtter også PHP. I gruppen har vi litt erfaring med PHP fra Bachelorstudiet Anvendt Datateknologi på Høgskolen i Oslo, og vi ønsket å videreutvikle oss selv videre innenfor PHP. Samtidig HTML og CSS Vi har også brukt java skript til å lage side hvor man logge seg inn på både admin og ansatte. 2.4 Fremdriftsplan Vi fikk laget en fremdriftsplan tidlig i prosessen og formulert milepælene for å ha en tydelig oversikt over hvordan vi skulle gå frem og hvordan vi burde ligge ann i henhold til de ulike oppgavene underveis i prosessen. Fremdriftsplanen ble fremstilt ved et Gantt-diagram i programmet Ganttproject (se under). Det har vært litt vanskelig å følge, fordi noen oppgaver tok lengre tid enn vi trodde, men vi greide å holde planen likevel. 12
2.5 Risikoanalyse Som med fremdriftsplanen så utformet vi en risikoanalyse tidlig i prosjektet for å være forberedt på ulike hindringer/redusere de negative konsekvensene av uforutsette hendelser. Å 13
lage risikoplan er noe som har blitt lagt frem som oppgave for oss i flere fag underveis i utdanningen i Anvendt Datateknologi på HiO og dette har vi erfart er et viktig dokument. 1= Liten til ingen risiko 5= Middels risiko 10= Høy til sannsynlig risiko. Risiko - Hvilken uforutsett hendelse som kan skje som vil påvirke prosjektet Sannsynlighet - Hvor stor sjansen er for at hendelsen skjer. Skadeomfang - Hvor store blir konsekvensene/skadene av det inntrufne. Konsekvenser - På hvilke måter vil hendelsen påvirke prosjektet. Forebygging - Hva som kan gjøres for å unngå at hendelsen skjer. Håndtering - På hvilken måte hendelsen skal håndteres om den skjer. 14
15
2.6 Tilegne seg ny kunnskap Som med det meste så lærer man seg mye mens man jobber med nye ting. Prosjektet har vært en spennende utfordring for oss i forhold til å utføre et komplett arbeid med å bruke ting vi har lært på disse tre årene med skole. I tillegg er det en god forberedelse til arbeidslivet etter skolen, som krever samarbeid med et team, med oppdragsgiver, arbeidsrammer og tiden som er nødvendig for å fullføre en oppgave. En av de viktigste tingene vi har lært oss/fått mer erfaring med er å være selvstendig og få mulighet til å utvikle seg selv gjennom prosjektet. Vi måte lære mer om blant annet Wamp server og kombinasjon mellom HTML, CSS og PHP. 2.7 Tilbakemelding fra oppdragsgiver Vi har hatt en kontinuerlig kontakt med oppdragsgiver hovedsakelig gjennom en person i gruppen, og vi har fått mye positiv tilbakemelding hver gang vi har utført en del av prosjektet, spesielt når det er nye ting som er presentert for ham. 3.Utviklingsprosessen I denne delen vil vi fortelle om utviklingsfaser for prosjektet vårt, valg og oppbygging av database og webside og andre valg vi har foretatt oss. 3.1 Prosjektstart Vi tok kontakt med flere firmaer og bedrifter deriblant Steria, Nor Import AS, et tannlegesenter og Grosso LTD. Vi ønsket oss et prosjekt hvor vi kunne benytte oss av teknologi som PHP, databaser, HTML, nettverk eller Perl-scripting. 3.2 Valg av oppdragsgiver Vi fikk to tilbakemeldinger fra bedrifter som ønsket å samarbeide med oss. En bedrift hadde behov for et system som lagrer informasjon for telefonsamtaler i en database, slik at alle 16
kundene kunne ha sin egen innloggingsside på websiden til bedriften hvor de kunne få informasjon og oversikt over sine samtaler, tider og andre funksjoner om kunden og samtalen. En annen bedrift ønsket en database som skal registrere varer som kommer på lageret. Databasen skal derimot ikke kobles opp mot internett, men datamaskinene på bedriften og maskinene de ansatte hadde hjemme skulle kunne kobles opp mot hverandre. Det var viktig for oss å ha et prosjekt i Oslo- området fordi vi jobber og bor her, og da blir det enklere å ha møter med oppdragsgiveren. Valget vårt falt derfor på den siste bedriften, som da er Nor Import AS. I samarbeid med oppdragsgiveren satt vi opp betingelser og mål for produktet de ønsket at vi skulle lage for dem. 3.3 Oppbygging av program I begynnelsen begynte vi å samle informasjon om PHP, MYSQL, WAMP og HTML. Etter at vi har samlet nok informasjon om disse, så begynte vi med programmeringen. Vi har prøvd mange forskjellige måter for å komme frem til riktig løsning(kode). Grafen var den vanskeligste av funksjonene. Grunnen til dette er at det var vanskelig å få den til å fungere med andre sider i systemet, men vi fant frem til en løsning etter hvert. 3.4 Forhold gruppe- arbeidsgiver gjennom prosessen Vi hadde et godt forhold med arbeidsgiver under hele prosessen. De hadde ikke forventet at de skulle få et databasesystem gratis, men at de måtte betale mye for å få et slik system, samt en webside. De hadde som nevnt tidligere problemer med dobbelt betaling, men med bruk av systemet som vi laget kan de nå enkelt finne alle fakturer som er dobbelt betalt, eller ved bruk av databasesystemet ikke registrere en faktura flere ganger. Spesielt dette, men også flere andre nyttige funksjoner er de veldig glade og lettet over å få. 3.5 Design webside Generelt skal designet være spenstig, enkelt og oversiktlig. Det skal være kortest mulig vei til informasjon og tjenester man har bruk for. 17
Design på delsider baseres på grunndesignet til hovedsiden, men det skal fremgå visuelt at man er i en delside, for eksempel med egen farge. Informasjonen skal så langt det lar seg gjøre porsjoneres og fremkomme til riktig tidspunkt. Grensesnittet skal bygges på bakgrunn av info fra testbrukere uten datakunnskap. Joomla er en praktisk løsning som gjør dette mulig, og i tillegg skaffet vi et domenenavn(www.nordagligvare.no), men vi fikk ikke lagt websiden ut på dette domenenavnet innen fristen, delvis grunnet fordi vi ikke fikk rett kode fra de vi kjøpte domenet hos(one.com) og fordi vi gjorde dette litt sent. Men websiden skal lastes opp så snart vi får de riktige kodene fra One.com 3.6 Design database Det første som må tenkes gjennom er hvilken informasjon databasen trenger å gi oversikt over(hvilke entiteter og attributter man trenger). Det er viktig å ha tenkt nøye gjennom dette før man begynner å fylle ut tabeller med data og kode for å unngå store forandringer underveis slik at tabellene må endres. Database skal være strukturert etter en arvbasert relasjonsmodell og normalisert slik at man unngår redundans og en entitet lett kan utvides med koblinger mot nye entiteter etter behov. Ved å modellere databasen på denne måten passer man også på å skille mellom entiteten og eventuelle roller entiteten kan ha inne. Dette er spesielt viktig for videre utvidelse og integrering av databasen. Man må også tenke på DBHS (databasehåndteringssystem) som er et verktøy for å lagre og finne igjen store mengder delte data over lang tid på en sikker og effektiv måte for mange samtidige brukere. Databasesystem som er DBHS plus database. Databaseadministrator (DBA) som har ansvaret for den daglige driften av et databasesystem. Tabeller: Admin (id, navn, adress, tlf, e-mail, her) Faktura (id, faktura nr, leverandor navn, dato, ordre nr, beløp, beskrivelse, forfalsdato, antall dager igjen). 18
Leverandor (id, leverandor navn, tlf, type av, e-mail, adress, kontaktperson, beskrivelse) Varer (id, produktnavn, pris, laverandor, antall, expire, beskrivelse). Ansatte (id, navn, tlf, e-mail, adress, avdeling, født, ansatt fra, beskrivelse). Bruker (id, navn, e-mail, her). Logg inn/out (navn, logget inn, logget out). Her (idher, navn, data, tid). Database ER-modell: 19
3.7 Risikoplan Som nevnt i oppgavens del 4.4 så utførte vi en risikoanalyse. Den mest kritiske risikoene vi møtte på var å gjøre prosjektet for stort. Midt i/ mot slutten av prosessen så fikk vi problemer med at vi ikke hadde så mye tid igjen, og derfor måtte nedjustere prosjektet noe i henhold til 20
risikoplanen. Vi prøvde også å kontinuerlig justere prosjektets størrelse, også i henhold til risikoplan, men det er vanskelig å forutsi hvor det kan dukke opp problemer som vil forsinke prosjektet. Risikoen med det største skadeoomfanget var helt klart datatap og datatekniske problemer. Vi hadde som nevnt tidligere gode rutiner for å ta backup, men vi møtte heldigvis ikke på noe problemer av dette slaget. 3.8 Backup Backup er en veldig viktig del av prosjektarbeidet, som også er spesifisert i risikoplanen vår på side 31 under risikoen Datatap og datatekniske problemer. Tap av data kan skje på mange ulike måter: Datamaskinen kan krasje, få virus, bli stjelt, bli hacket(trojan), mistet eller ødelagt på andre måter. For å senke risikoen for å miste alt arbeidet vi har gjort underveis i prosessen så tok vi backup av arbeidet vi utførte etter hver gang. Backupen ble gjort via eksterne servere som Dropbox og mail, eller ved lagring på minnepinne i tillegg til på maskinene der arbeidet opprinnelig ble lagret. 3.9 Testing Testing av databasen ble gjort hele tiden underveis mens vi kodet. Vi kodet litt, deretter testet gruppemedlemmene som kodet det, om det fungerte etter ønskelige mål. Da vi anså databasen som sluttført testet alle på gruppen at alt fungerte som det skal. Vi fikk i tillegg venner og bekjente til å forsøke databasen vår og se om alt fungerte tilfredsstillende. Mer detaljer for testingen finnes i dokumentet Testdokumentasjon. 4. Kravspesifikasjonen og dens rolle Dette avsnittet vil som overskriften sier, fortelle om kravspesifikasjonen, hvordan den er forandret og benyttet og om det er samsvar mellom kravspesifikasjon og produktet som beskrives i produktdokumentasjonen. 21
4.1 Endringer på kravspesifikasjon Kravspesifikasjon har blitt endret fra første versjon. Først kunne kunden bestille varer gjennom bedriftens hjemmeside, med handlekurv og betaling. Men bedriften mente at denne fasen er for tidlig på grunn av at ansatte/administrator ikke er klar for det. Det har derfor ikke blitt noen elektronikkhandel i først omgang (kanskje det kan utvikles i fremtiden), så det har blitt kuttet ned til at kunden skal få informasjon om butikken, varer etc.. 4.2 Kravspesifikasjon for utvikling i design og implementering For utviklere (innen design) må man ha hjemmeside der en kunde kan bestille eller handle gjennom internett (e-handel), med alle standarder for sikkerhet for handelen. For implementering har vi laget alle dokumentene strukturert slik at det blir lett å utvikle det videre med å legge til mer funksjonalitet på hjemmesiden. 4.3 Samsvar mellom kravspesifikasjon og produktet i produktdokumentasjon? Vi har programmert alle funksjonene etter de kravene som vi fikk fra oppdragsgiver, derfor er det godt samsvar med kravspesifikasjon og produktet. Man kan se tilbake på produktdokumentasjon og kravspesifikasjondokumentet og se at det er samsvar mellom dem. 5. Hvorfor velge Web-basert system: Det finnes mange grunner til å velge et web- basert system: Et web-basert økonomi og administrasjonssystem er et komplett forretningsstyringssystem der alle modulene ligger på en webserver. Hvem som helst rundt om i verden kan få tilgang til systemet ved hjelp av en enkel nettleser, og på den måten kunne styre sitt firma. I stedet for å 22
investere store summer i hardware (maskinpark) og software (programmer), betaler brukeren et mindre beløp, som en leiekostnad, hver måned. Det er mange fordeler ved å velge en webbasert løsning. Mange av disse er presentert under dette: Man trenger kun en nettleser For å benytte seg av et web-basert system trenger man kun en nettleser på en hvilken som helst PC og tilgang til Internett (bredbånd anbefales). Dette gjør systemet enkelt å implementere gjennom hele organisasjonen. Brukere vil også få tilgang til systemet via PCer på for eksempel flyplasser og Internett cafe. Lavere kostnader forbundet med programvare Man eliminerer behovet for å investere i dyr programvare og betale høye årlige avgifter for oppgraderinger av programvaren. Lavere kostnader forbundet med maskinvare Man eliminerer behovet for å investere i, og implementere, servere og nettverk. Løpende kostnader i forbindelse med å oppgradere og vedlikeholde nettverket elimineres også. Kortere implementeringstid Impementeringstiden blir betydelig redusert fordi systemet allerede er oppe og går. Alt man har behov for å gjøre er å logge seg på systemet og man er igang. Behovet for kurs og opplæring vil forbli det samme uavhengig av om man systemet kjøres lokalt eller via web. Lavere kostnader ved flere lokasjoner Tidligere har selskaper som er lokalisert på flere forskjellige geografiske steder vært nødt til å investere i dyre løsninger, som for eksempel Citrix, for å imøtekomme behov for å få felles tilgang fra alle lokasjonene. Disse løsningene viser seg ofte å være for dyre for mange små selskaper. Med et web-basert system kan selv de minste selskaper oppnå fordelene ved å kjøre ett felles system uavhengig av lokasjon til en fornuftig pris. Jobb hjemme Et web- basert system er perfekt for selskaper som ønsker å imøtekomme ansattes ønsker om å kunne jobbe hjemmefra. 23
6. Ikke-funksjonelle krav: Dette er de funksjoner eller krav som angir kriterier som kan brukes til å bedømme driften av et system, i stedet for spesiell oppførsel. Dette bør være i kontrast med funksjonelle krav som definerer bestemt atferd eller funksjoner. Generelt, funksjonelle krav definerer hva et system er ment å gjøre, mens ikke-funksjonelle krav definerer hvordan et system er ment å være. Funksjonelle krav er som regel i form av systemet skal, mens ikke-funksjonelle krav er systemet skal være. For Nor dagligvarer import AS er de ikke funksjonelle krav dette: På grunn av bedriftens strategi som er å være mer organisert og modernisert har vi satt krav som er ikke-funksjonelle i begynnelsen av dette prosjektet, f. eks systemet skal være klar for at kunden skal kunne bestille varer og betale med nettet. Systemet skal være mer kompetitivt: med det menes at nettside skal være mer profesjonell(sikkerhet, bilder, linker, reklame ). Alt dette kommer også med bedriftens IT-strategi som gjør at outsourcing (f.eks. 24sevenoffice) er uaktuelt i begynnelsen av dette prosjektet: Det vi mener med dette er fakturering, regnskap forlate dette til eksterne hos bedriften som er spesialisert i disse områdene. Outsourcing innbærer implementering som bedriftens ansatte ikke er klar for(opplæring). IT- strategi Bedriften bruker lite IT, og ledelsen ønsker å utnytte de IKT- løsningene som finnes og som kan passe godt til virksomheten, slik at de får mindre kostnader ved å bruke systemet. Det er også naturlig å disponere IKT -strategien i følgende tre temaer: Applikasjoner og data (Brukerprogramvare og databaser) Teknisk infrastruktur (datamaskiner, nettverk og operativsystemer) IKT -styring (IKT -organisering, forvaltningsprosesser, uviklings -prosesser og planprosesser) 24