SluttRapport Komplett dokumentasjon i faget Informatikk 1 Prosjekt AS CD Magasinet

2009 SluttRapport Komplett dokumentasjon i faget Informatikk 1 Prosjekt AS CD Magasinet MusicSurfer aka MuSu Utviklere av prosjektet Sebastian Strømnes Eskil Espås Ugelstad Christoffer Framstad Lokrheim Fredrik Lundsrud Håkon Wahl Engen BADR5 DASDOS Jügend 27.11.2009

SluttRapport BADR 5 Forord Vi i gruppen har nå i to måneder jobbet med dette prosjektet, og i løpet av denne perioden har vi utviklet oss, ikke bare som utvikler, men også som ledere og teamarbeidere. Gruppen har hatt sine diskusjoner innen alt fra design til god kodeskikk og størrelsen på databasen, og mange endringer er blitt gjort. Vi føler vi har levert et produkt vi kan være stolte av. Men det har ikke bare vært ren plankekjøring, vi har fortvilt oss over koden der det i hodene våre har virket logisk, men det har krasjet når vi tester funksjonene. Badr 5 aka DasDos Jügend vil gjerne takke alle som har medvirket, testet og hjulpet oss gjennom dette prosjektet, og vi er stolte over å kunne presentere MuSu. 2

SluttRapport BADR 5 Innholdsfortegnelse Forord... 2 Kap. 1 Innledning... 4 Kap. 2 Nytt datasystem for AS CD-magasinet... 5 2.1 Bakgrunn, problembeskrivelse... 5 2.2 Oversikt over systemets hovedfunksjoner... 5 2.3 Sammendrag og henvisning til siste versjon av forstudierapporten... 5 2.4 Sammendrag og henvisning til siste versjon av brukerkravdokumentet... 6 2.5 Sammendrag og henvisning til siste versjon av systemkravdokumentet... 6 2.6 Sammendrag og henvisning til brukerveiledning... 7 2.7 Programsystemet, det ferdige systemet... 7 2.8 Spesielle kommentarer... 8 Kap. 3 Oppsummering av prosjektarbeidet... 8 3.1 Evaluering av prosjektgjennomføringen... 9 3.2 Evaluering av gruppesamarbeidet... 9 3.3 Oppsummering av brukte timer... 10 3.4 Forslag til videre arbeid... 11 Litteraturliste og referangseliste... 12 Vedlegg 1 Vedlegg 2 Vedlegg 3 Vedlegg 4 Vedlegg 5 Vedlegg 6 Vedlegg 7 Vedlegg 8 Vedlegg 9 Vedlegg 10 Vedlegg 11 Vedlegg 12 Vedlegg 13 Forstudiedokument Brukerkravdokument Systemkravdokument CD med kjørbare filer Arbeidskontrakt Timelister Statusrapporter og ukerapporter Møteinnkallinger og møtereferater SQL Script Brukerveiledning Tilbakemeldinger fra beta testere Referat fra ekstraordinært prosjektmøte Arbeidsfordeling 3

SluttRapport BADR 5 Kap. 1 Innledning Målet med dette prosjektet var å utvikle et system som bedrer arbeidsrutinene hos den fiktive bedriften AS CD-Magasinet. Det skal ta seg av en rekke oppgaver som før har krevd mye ressurser hos de ansatte. Prosjektperioden skulle strekke seg over en tidsepoke på 9 uker. Oppgaven vår var å produsere et helt nytt databasesystem der vi skrev programkoden i Visual studio med programmeringsspråket Visual basic.net, opprette en database med MySQL og flere typer modeller i MS Visio. Vi brukte i tillegg Modelator til dette arbeidet. Til dokumentasjonsarbeidet brukte vi Etherpad, som er et nettbasert samskrivningsverktøy, i stor skala. Innad i gruppa var det like lite erfaringer blant alle gruppemedlemmene, nå ved prosjektets slutt er forskjellen betraktelig annerledes. Ingen i prosjektgruppa hadde fra før av drevet med Visual Basic, MS Visio eller MySQL. Det skal også nevnes at arbeidsinnsatsen har vært meget forskjellig fra person til person i prosjektgruppen. Siden arbeidsinnsatsen har vært så varierende har det vært umulig for alle medlemmene og kunne sette sitt avtrykk på det materialet som er produsert. Dette har medført til at tre personer har skrevet all form for programmering, både når det kommer til sql og vb.net kode. Når det kommer til dokumentasjonen har alle bidratt til deler av arbeidet, men det er helt klart at mesteparten er utført av de tre førstnevnte. Når det gjelder programmeringskoden, har prosjektgruppa utforsket ting utenom pensum. Vi har brukt hjelpemidler som fagbøker, leksjoner utgitt i faget, og internett når vi har lett etter kode som passer våre systemskriterier. I tillegg til selve databasesystemet som er det viktigste i prosjektet, skulle det skrives dokumentasjon over alle prosjektets faser, for å vise hvordan systemet er ment å fungere. Rapportene gir i tillegg en pekepinne til hvordan prosjektgruppen har ligget an i utviklingen. Forstudierapporten skal fortelle oss om det i hele tatt var forsvarlig å gjennomføre dette prosjektet og viser til hensiktsmessige tiltak. Brukerkravdokumentet er en dyp beskrivelse av hva brukerne i AS CD-magasinet krever av den endelige prototypen og det endelige databasesystemet. Systemkravdokumentet beskriver spesifikt hva man kan og ikke kan gjøre med systemet. Sluttrapporten vår har som hensikt å gi brukerveilederne blant annet en tilbakemelding på gode og dårlige arbeidsmetoder i prosjektarbeidet og samarbeidsprosessen, hvordan arbeidet i gruppa har foregått, men den skal også vise til det endelige og helhetlige resultatet av hvordan programmet fungerer. 4

SluttRapport BADR 5 Kap. 2 Nytt datasystem for AS CD-magasinet 2.1 Bakgrunn, problembeskrivelse Plateforetningen tilbyr salg i butikken og bestilling via telefon eller e-post. Applikasjonen skal brukes til salg av varer, oppdatering av beholdning og administrative oppgaver som å skrive ut rapporter og fortjeneste. I databasen er det oversikt over alle ansatte, hva slags produkter butikken selger og har, hva slags status varene har(lagervare, bestillingsvare eller utgått - vare). I tillegg til de ansatte skal det også være kunderegistrering og kundebestilling. I nåværende system har man dårlig oversikt over hvor i butikkene platene befinner seg, men med det nye datasystemet har man en lett tilgang til et oversiktskart som vil fjerne dette problemet for godt, slik at en slipper å lete seg fram til hvor i butikken varene ligger. Det nye datasystemet skal forenkle de manuelle arbeidsrutinene til de ansatte, og da vil arbeidet mer eller mindre gå automatisk for seg. I tillegg til datasystemet har det blitt skrivet en del rapporter og laget et ganntdiagram, som er en rød snor gjennom prosjektets gang. Diagrammet estimerer og fordeler timene innen den angitte tidsrammen på de ulike fagfeltene. 2.2 Oversikt over systemets hovedfunksjoner En database som lagrer informasjonen til AS CD-Magasinet. Login med kryptert passord for å sikre at uvedkommende ikke kan ta i bruk systemet. Salg som tar både kassesalg og kundebestillinger. Søk som lar sluttbrukere søke gjennom AS CD-Magasinets varer. Vareadministrasjon som lar sluttbruker oppdatere data på varer og opprette nye varer. Varemottak for å ta i mot varer fra bestillinger. Administrasjon for å legge til brukere, endre brukere, slette brukere. Generere rapporter fortløpende ut i fra den nyeste informasjonen som ligger i databasen. Enkel innkjøpsfunksjon som gir deg mulighet til å bestille varer fra leverandører. Skrive ut kvittering fra salg og bestillinger Parentchild oppbygd program. 2.3 Sammendrag og henvisning til siste versjon av forstudierapporten Forstudiet er en analyse som kartlegger om man bør starte arbeidet med å utvikle et nytt system for AS CD-Magasinet. Det blir kartlagt og laget prosjektmål, risikoanalyse, kostnytte analyse, oppdragsgivers behov, rammebetingelser, kritiske suksessfaktorer, retningslinjer og til slutt blir en prosjektorganisasjon presentert. Dagens situasjon i AS CD-Magasinet er at det er mange manuelle rutiner som tar tid og er en betydelig belastning kostnadsmessig. Risikoanalysen viser ingen farer med store konsekvenser og høy sannsynlighet. Kostnytte analysen viser en vekst i AS CD-Magasinets omsetning om det blir implementert et nytt datasystem. Ut i fra behovene som blir presentert og resultatene fra risiko og kostnytte analysen blir det anbefalt at systemutviklingen av et nytt datasystem hos AS CD-Magasinet bør iverksettes. Forstudiet ligger vedlagt som vedlegg 1. 5

SluttRapport BADR 5 2.4 Sammendrag og henvisning til siste versjon av brukerkravdokumentet Brukerkravdokumentet er et dokument som skal gi leseren en rask og enkel beskrivelse av hvilke krav og forutsetninger, som ligger til grunn for de valgene prosjektgruppa har tatt når utviklingen av prosjektet har vært i gang. Dokumentet skal samtidig gi leserne en felles forståelse av hvilke krav arbeidsgiver har satt. Det spesifiseres hva sluttbrukerne krever av systemet, og hvilke rutiner som forutsettes. UseCase modellen blir for første gang introdusert her, denne modellen viser hvem som kan gjøre hva, på hvilke premisser. Det blir i tillegg opplyst om hvordan systemet takler sikkerhet med tanke på adgangskontroll, sikkerhetskopiering, pålitelighet, feilfrekvens og konsekvenser. Brukeregenskaper, kapasitet og grensesnitt mot andre datasystemer blir også beskrevet nærmere. Brukerkravdokumentet gir også en kort innføring til prototypen av prosjektet. Minner straks om at dette kun er en prototype, og hvis du som leser er på jakt etter brukerveiledningen til dagens system. Dette finnes under vedlegg 3 Systemkravdokumentet, eller vedlegg 10 Brukerveiledningen. 2.5 Sammendrag og henvisning til siste versjon av systemkravdokumentet Systemkravdokumentet er dokumentasjon som skal gi leseren en oversikt over hvilke krav og betingelser utviklergruppen jobber for å oppnå. Prosjektet går ut på å effektivisere og bidra til å øke inntekten til AS CD-Magasinet, ved å utvikle en applikasjon som oppdaterer beholdning, gjør salgsprosessen enklere, ha en god oversikt over varene ute i butikken og endre en varens data uten og gå gjennom en lang og tidkrevende manuell prosess. Applikasjonen skal bygges på en innlogging, som bidrar til å øke sikkerheten og hindre adgang til data som kan misbrukes. Etter innloggingsfasen vil man få tilgang av et utvalg av muligheter avhengig av tilgangsnivå. Programmet er bygget opp på den måten at for hver gang en bruker skal hente ut informasjon kobler man opp mot databasen, henter eller endrer data avhengig av hvilken operasjon brukeren utfører og deretter lukker tilkobling etter hver SQL spørring. Dette gjør at applikasjonen er flerbrukervennlig. Dokumentet inneholder en UseCase modell som beskriver valgmuligheter ved forskjellige hendelsesforeløp. ERmodellen er lagt med for å få en fullstendig oversikt over hvordan databasen er bygd opp. Kapittel 6 går dypere inn på selve bruken av programmet, der det også er beskrivende tekst og bilder som viser de ulike funksjonene. Noen krav til egenskaper i applikasjonen er: - Adgangskontroll og kryptering - Pålitelighet og konsekvenser ved eventuelle feil (tilbakemelding hvis kritiske felt ikke er fylt ut riktig). Noen krav til brukeregenskaper: - Bruken av det nye systemet krever at de ansatte har generell innsikt i data, Web og en generell har forståelse for bruk av Microsoft Windows. 6

SluttRapport BADR 5 Noen krav til utstyr: Alt gammelt utstyr kan i hovedsak brukes om igjen, men det bør gjennomføres en servicerunde på alt utstyr for å forhindre feil ved implementering det nye systemet. Systemet krever generelt liten lagringsplass siden det er minimalt av data som lagres på det lokale systemet. Serveren med databasen vil være plassert hos utviklerne slik at en trygg drift kan sikres videre etter implementering. Noen krav til applikasjoner Krever selvfølgelig MuSu installert på maskinene som skal brukes. Mysql Connector v6.1.3 ODBC Connector v5.1.6 32bit eller 64bit avhengig av operativsystemet som blir brukt. 32bit er mest sannsynlig i dette tilfellet. MuSu krever internett tilgang under alle faser av daglig bruk. Windows XP med SP3 eller nyere. Andre krav: Arbeidsgiver må søke datatilsynet for å kunne lagre personopplysninger av de ansatte. Se side 7 i det fullstendige systemkravdokumentet 2.6 Sammendrag og henvisning til brukerveiledning Brukermanualen kan leses fra http://tihlde.org/~sebastis/prosjekt/dokumentasjon/brukerveiledning.docx ellers så finner man en versjon i vedlegg 10. Her vil man i detalj kunne lese hva hver funksjon i programmet gjør, og hva det viser. Vi har også kort forklart hvilke muligheter man har i programmet. Brukermanualen består av screenshots og forklaring til disse. 2.7 Programsystemet, det ferdige systemet I det ferdige systemet har brukeren anledning til å registrere nye brukere i programmet MuSu, søke opp en vare ved enten å angi et varenummer(eks: 70030) eller et EAN-nummer(eks: 1248163264128) og å opprette nye varer. Når det opprettes en ny vare må brukeren angi et nytt EAN-nummer. Når en søker etter en vare vil en få svar på hvor stor beholdningen av varen er, om varen er på lager, om den i det hele tatt finnes i butikken, i hvilken etasje den er lagerført og om varen er utsolgt. Det er for brukeren mulig å kjøpe inn flere varer av en allerede registrert vare. Man kan selge den hvis den er på lager, og man kan redigere hver enkelt vare hvis det skulle være nødvendig. Programmet har mange ferdig installerte rapporter som brukerne kan bruke for å belære seg om dagens situasjon. Her kan vi nevne ting som, beste ansatt, års sammenligning, sorterte salg per kunde eller mest solgte vare time for time. 7

SluttRapport BADR 5 2.8 Spesielle kommentarer SERVER: BRUKERNAVN: PASSORD: DATABASE: mysql.stud.aitel.hist.no music_server jugend music_surfer Det oppfordres til IKKE å kjøre dette scriptet på vår database, da dette vil forårsake tap av data våres test brukere har lagt til. Scriptet inneholder kun de verdiene som ligger lagret når programmet blir utgitt til test brukerne. Det er opprettet e-post kontoer til bedriften, som sender og mottar kvitteringer på bestillinger gjort via programmet MuSu. Vi oppfordrer til å sjekke dette ut. Brukernavn og passord er ramset opp under. Brukernavn sekretær e-post: sekretaer.cdmagasinet@gmail.com Passord sekretær e-post: DasDosJugend Brukernavn Bedrift e-post: CDMagasinet@gmail.com Passord Bedrift e-post: musicsurfer Leverandør e-post: Brukernavn Hovedlager e-post: hovedlager@gmail.com Passord Hovedlager e-post: hemmelig Angående utskriftsfunksjonen i Salg og Innkjøp så må ønsket skriver bli satt til default før man skriver ut. På rapportene kan man velge ønsket skriver igjennom programmet. Kap. 3 Oppsummering av prosjektarbeidet Det har vært utrolig lærerikt og krevende å jobbe med dette prosjektet. Gruppen har utviklet seg innenfor både VB, DB og PRS. Det har vært enkelte utfordrende øyeblikk i forbindelse med gruppedynamikken grunnet fravær, men vi har presset på og lært mye fra dette. Det å jobbe i en gruppe som består i utgangspunktet av helt ukjente personer har vært en fin måte å bli kjent med hverandre, og utvikle en felles eierskapsfølelsen seg i mellom til produktet vi har jobbet med. I resten av dette kapitelet vil vi gå nærmere inn på de ulike sidene av prosjektet og hvordan vi føler det har gått. 8

SluttRapport BADR 5 3.1 Evaluering av prosjektgjennomføringen Noe som er veldig positivt med gjennomføring av dette prosjektet er at det har blitt lagt ned mye hardt arbeid for å få ferdig prosjektet. Deler av gruppa har sittet opptil 6-12 timer daglig, og har gått over den tillatte maks tiden og har i tillegg til dette å oversteget den tillatte overtidstiden på 10 %. Årsaken til dette er for å dekke de gjenværende oppgavene som ikke er, eller har blitt utført av andre på gruppa. Ikke alle på gruppa har deltatt i like stor grad for å gjennomføre prosjektarbeidet. Som en følge av dette har det blitt vedtatt individuell karaktersetting. Dette ble enstemmig vedtatt av alle oppmøtte på møtet den 19.11.2009. Referat følger som vedlegg 12 i dette dokumentet. Forstudie: Positivt: Gannt Diagrammet, kostnytte og ER modellen er vi veldig fornøyd med. Gruppedynamikken var også svært god under utarbeidingen av forstudiet. Det var en jevn innsatts fra gruppens deltakere. Negativt: Det å lage en rapport på antatte prognoser uten mye informasjon om oppdragsgiver, og uten tidligere erfaringer var en svært utfordrende prosess. Brukerkravdokument: Positivt: Dette var det første dokumentet hvor vi hadde mer håndfast data. Introduksjon av prototypen og kommenteringen til prototypen løfter uten tvil moralen i prosjektgruppen. Det å få satt våre krav ned på papir ble en finn veileder i det videre arbeidet med prosjektet. Negativt: Gruppen følte at brukerkravdokumentet ble litt repeterende i forhold til hva vi presenterte i forstudiet. Systemkravdokument: Positivt: Når vi startet med dette dokumentet hadde vi kommet godt i gang med kodingen av programmet, og det var fint å få begynne å sette krav til systemet vi jobbet med. Dokumentet ble en fin introduksjon til iso-9126-1. Negativt: Mye av systemkravdokumentet var repeterende i forhold til brukerkravdokumentet. 3.2 Evaluering av gruppesamarbeidet Positivt: Gruppen har hatt en god tone fra start til slutt, og vi har lært hverandre å kjenne, slik at vi vet når vi trenger pauser og når vi må stå på å jobbe. Selv om vi har hatt våre ulikheter og forskjellig erfaringer fra tidligere har vi lært å bygge på hverandres styrker og personligheter. Eskil, Christoffer og Sebastian har jobbet jevnt og trutt med prosjektet fra start til slutt, med litt variert innsats fra Fredrik og Håkon. Etter det ekstraordinære møtet skjerpet Håkon seg og har sittet og jobbet med prosjektet på lik linje med Eskil, Christoffer og Sebastian. Negativt: Gruppen startet veldig bra med godt oppmøte fra samtlige. Etter hvert har det vist seg at interessen for å møte opp på skolen og delta i samarbeidet har dalt hos enkelte. Fredrik har vært fraværende i deler av prosjektet og dette kan du se ved hjelp av timelistene i vedlegg 6, dette vil også komme frem av arbeidsfordelingen i vedlegg 13. Det er derimot et punkt vi vil ta opp som går direkte på selvkritikk om oss selv. Dette går på vår risikoanalyse av fraværende oppmøte, tidlig ute så vi en mulig trend rundt dette. Og vi skulle ønske vi hadde tatt raskere tak i denne trenden og informert både vedkommende og veileder om situasjonen. 9

SluttRapport BADR 5 3.3 Oppsummering av brukte timer Her vil vi oppfordre til å se nærmere på vedlegg 13, som omhandler arbeidsfordelingen i prosjektet. Her vil det komme tydelig fram hvem som har gjort hvilke deler av prosjektets oppgaver, og hvem som har stått for hovedmengden av oppgaveløsningen. Det som kan nevnes her går mer på hvordan timene hvert enkelt medlem har skrevet ned, faktisk er brukt. Om de minuttene bare er sløst bort eller brukt effektivt. Og her må vi, uten noen form for å bevise våre påstander så klart, påstå at timene er vel anvendt. Dette selv om vi har tilfeller hvor utviklerne har for mange oppførte timer i forhold til "taket" på 150 timer. Vi har utviklet et system som inkluderer mange finurlige funksjoner, og vi vil konkludere med at vi har gjort et godt stykke arbeid i løpet av dette prosjektet. Ut ifra sammenligning mellom Ganntdiagram og timelistene, har vi brukt 72 timer mer på Prosjektrettet systemarbeid enn estimert, på Databaser har vi brukt 28,75 timer mindre, og på Visual Basic har vi brukt 183,25 timer mindre enn forventet. Sistenevnte skyldes rett og slett at det kun har vært 3 av 5 som har programmert. Hadde arbeidsinnsatsen vært lik på hos samtidlige medlemmer i prosjektgruppen hadde vi hatt flere timer totalt og vi hadde også kommet fram til et helt annet produkt. Vi vil også nevne at alle milepæler har blitt nådd innenfor de gitte tidsrammer og dette er vi som gruppe svært fornøyd med. Gruppen hadde ingen erfaringer fra før når det kommer til å estimere timeforbruk i et slikt prosjekt. 10

SluttRapport BADR 5 3.4 Forslag til videre arbeid Salg hadde fått et ekstra grensesnitt tilpasset kassasalg, og touch skjermer. Deretter hadde vi gjort om på måten hele systemet behandler bestillinger fra leverandører. Det vi kunne tenke oss er at når man utfører en bestilling, lagrer man dette til et referansenummer, som senere kan brukes til å registrere hvilke varer man har fått inn til butikken. Innkjøp skulle vært knyttet mye tettere opp i mot de enkelte leverandørene sitt varesortiment. Med også å knytte en frekvensskala til det enkelte produkt, som butikken fører, ville vi også kunne generere automatiske lister over hvilke varer som måtte bestilles, ut i fra hvor mye en vare selger. Dette ville vært praktisk med tanke på at det er alltid enkelte nye varer som selger som varmt hvetebrød i denne bransjen. Alle varer burde få knyttet til seg en fremmednøkkel, som viser til leverandørens standard leveringstid på sine produkter. Dette ville gitt et bedre bestillingsforslag, siden det vil bli tatt hensyn til salgsfrekvens og forventet leveringstid. En slik totalfunksjon vil kreve at vi legger til en frekvens tabell som gir faste kriterier for når en vare skal bestilles. Og deretter å sette en fremmednøkkel fra tabellen til alle varer ut i fra hvor høyfrekvent salget på den enkelte vare er. Et godt faktureringssystem burde også blitt lagt til i programmet. Hvis vi skulle brukt vb til dette hadde vi tatt en nærmere titt på Microsoft Dynamic AX sin løsning, men muligheten er nok stor for at vi heller hadde siktet til en ekstern løsning på faktureringsdelen. Hadde vi hatt bedre tid, ville vi ha utvidet med både å registrere og hente verdier fra to databaser, i stedet for å hente fra bare en. På denne måten hadde vi da kunnet ha hatt en backup hvis en av databasene plutselig skulle oppleve problemer. Eksperimentere med Apples utviklingsplattform hadde vi nok også tatt tak på for å utvikle en enkel applikasjon, for søk i vareregistret, oppgi priser, vareplassering osv. Det kunne også hende vi her hadde lagd et grensesnitt for butikkens ansatte for å utføre enkle funksjoner alà varemottak. Skulle produktet blitt lagt ut for salg, ville vi også ha knyttet brukere opp i mot den enkelte ansatte, slik at hver ansatt har et unikt brukernavn og passord. Dette ville kun medført en liten endring i databasen og en liten endring av vb.net kode. En innføring av Tooltip på alle knapper og ikke minst tekstfelt ville vært hensiktsmessig. Og i en forlengelse av dette ville vi ha lagt til flere Contextmenyer i alle deler av programmet. Kort oppsummert: Touchskjerm grensesnitt for salg. Et komplett bestillingssystem. Program lager forslag på bestillingsvarer ut i fra beholdning og hvor stor frekvensen på innkjøpet skal være. Fakturerings system. Backup løsning. Mobile plattformer. Utvide brukervennligheten. 11

SluttRapport BADR 5 Litteraturliste og referanseliste Verktøy - Filezilla FTP program - Dropbox Fildelingsprogram - Etherpad.com Sammskrivningsverktøy - Microsoft Office Skrive og regne applikasjon - Modelator database modellator - Microsoft Visio 2007 database modellator - Notepad++ Skriveverktøy, med støtte for programmering og skriptspråk - Notepad Skriveverktøy - Microsoft Visual Studio 2008 Tegne verktøy - phpmyadmin - Teamviewer Fjerntilkobling og ekstern skrivebordsløsning - Skype video, tekst og snakkeverktøy - Spotify musikkavspillingsverktøy - Battlefieldheroes.com spill som sørger for underholdning og god arbeidsmoral i gruppa - Adobe Reader.pdf fremvisning av dokumenter - Paint.NET gratis tegneprogram med gode funksjoner på linje med adobe photoshop - Win Rar komprimering og filpakknings -verktøy - My sql connector 6,1,3 driver som i bidrar til sql oppkobling - ODBC connector 5.1.6 driver for å kunne bruke Crystal Report mot databasen - Snippingtool bildeutklippsverktøy Litteratur - Databaser 2. utgave av Kjell Toft Hansen og Tore Mallaug 975-82-05-381-05-6 - Oppslagsverket wikipedia.com - Oppslagsverket google.com - Oppslagsverket youtube.com - Dokumentasjonsverket MSDN 12

2009 Vedlegg 1 Forstudie Nytt datasystem AS CD-Magasinet Hensikten med forstudiet er å kartlegge om det er lønnsomt å implementere et nytt datasystem hos AS CD-Magasinet. Den omfatter også tiltak som vi mener vil være hensiktsmessige. Utviklere av prosjektet Sebastian Strømnes Eskil Espås Ugelstad Christoffer Framstad Lokrheim Fredrik Lundsrud Håkon Wahl Engen BADR5 DASDOS Jügend 26.11.2009

Forstudie BADR - 5 Innholdsfortegnelse 1 Introduksjon hensikten med dokumentet... 3 2 Bakgrunn for prosjektet.... 4 2.1 Beskrivelse av problemer og behov... 4 2.2 Kort om dagens systemer og rutiner... 4 3 Prosjektmål... 5 3.1 Effektmål... 5 3.2 Resultatmål... 5 3.3 Prosessmål... 6 3.4 Prosjektets omfang... 6 4 Rammebetingelser.... 7 5 Kritiske suksessfaktorer... 8 6 Risikoanalyse... 9 7 Kost /Nytte... 11 7.1 Effektmål... 11 7.2 Kvantifiserbar nytte... 11 7.3 Ikke kvantifiserbar nytte... 11 7.4 Bortfall av direkte kostnader... 11 7.5 Estimerte kostnader... 11 7.6 Sammenstillig kost/nytte... 11 7.7 Konklusjon kost/nytte... 13 8 Retningslinjer og standarder... 14 8.1 Dokumentasjon... 14 8.2 Programmering... 14 8.3 Database... 14 9 Prosjektorganisasjon... 15 10. Anbefalinger og videre arbeid... 16 Referanser... 16 11 Vedlegg... 17 Gannt Diagram... 17 ER Modell... 18 2

Forstudie BADR - 5 1 Introduksjon hensikten med dokumentet Hensikten med rapporten er å fortelle oppdragsgiver hvordan dagens situasjon faktisk er, vi skal se på hva vi kan forbedre hos AS CD-Magasinet. Vi vil gi våre anbefalinger vedrørende utvikling av et nytt system samt foreslå eventuelle tiltak for å bedre oppdragsgivers bedrift. 1. Introduksjon: Her kan du lese hensikten med dokumentet og hovedinnholdet i forstudierapporten. 2. Bakgrunn for prosjektet: Her står hovedhensikten med det nye systemet, hvorfor AS CD- Magasinet trenger et nytt system og litt om hva som er dagens utfordringer 3. Prosjektmål: Her står det vi kan oppnå med det nye systemet og hvilke resultater dette vil gi. 4. Rammebetingelser: Under dette kapittelet vil begrensningene til prosjektet bli presisert. 5. Kritiske suksessfaktorer: Her står det beskrevet hva som kreves av de ansatte hos oppdragsgiver, og hva programmet må kunne håndtere for at prosjektet skal bli en suksess. 6. Risikoanalyse: Her har vi satt opp de ti mest sannsynlige hendelsene som prosjektgruppen kan støte på. 7. Kost/Nytte: Her er det satt opp et regnskap over bedriftens økonomi med og uten det planlagte systemet. Det er i tillegg beskrevet hva man kan forvente seg av effektmål etter en vellykket innføring av det nye systemet. 8. Retningslinjer og standarder: Her står de ulike tidsfristene, hvordan dokumentene skal lagres, hvordan programmeringen skal foregå. Dette er rett og slett retningslinjer som prosjektgruppen må forholde seg til. 9. Prosjektorganisasjon: Her står det hvilke personer som har et spesifikt arbeidsområde og ansvar. 10. Anbefalinger og videre arbeid: Prosjektgruppens anbefalinger om å investere i dette nye systemet. 11. Vedlegg: Gant Diagram og ER Modell. 3

Forstudie BADR - 5 2 Bakgrunn for prosjektet. Hovedpoenget er å utvikle et system som bedrer arbeidsrutinene hos AS CD-Magasinet. Det skal ta seg av en rekke oppgaver som før har krevd mye ressurser fra de ansatte. 2.1 Beskrivelse av problemer og behov Alle platene er i en katalog som er tilgjengelig i butikken i et regneark. Hver gang butikken kjører salg/kampanjepriser må utsalgsprisene i katalogen oppdateres. Alle plater i katalogen lagerføres og bestilling av nye plater skjer når lagerbeholdningen synker til et visst nivå. Bestillingsgrensen er forskjellig for ulike platekategorier. Dette krever at en har god oversikt over varebeholdningen, noe som er vanskelig og tidkrevende med manuelle rutiner. Butikken har ikke noe system til å automatisere kundenes forespørsler. Når en kunde kjøper eller bestiller plater, blir platene hentet fra butikken og/eller lageret, og det skrives en ordreseddel. Skulle det være tomt for én eller flere plater, blir det laget en rapport som varsler om dette. I dagens situasjon er det vanskelig å holde oversikt over avansen til platene, siden katalogen kun inneholder utsalgsprisen. Innkjøpsprisene har butikken ingen felles oversikt over. Butikken har m.a.o. ingen god oversikt over hvilke plater de har størst fortjeneste på. Ofte er det vanskelig for butikkansatte å vite hvor de ulike platene står i butikken. I dagens situasjon finnes det ingen klar oversikt over dette, noe som medfører at mye tid går med til leting etter ulike plater i butikken og på lageret. Hvis firmaet skal være i stand til å håndtere en forventet veksten i salget og forbli i de eksisterende lokaler, er det nødvendig å gå til anskaffelse av et datasystem for å få automatisert flest mulig av dagens manuelle rutiner. 2.2 Kort om dagens systemer og rutiner Utgangspunktet er å lage et skreddersydd program til AS CD-Magasinet. Butikken tilbyr kun salg av fysiske plater direkte til kunden i butikken, eller ved at kunden bestiller plater via telefon eller e-post til butikken. Butikken tilbyr ikke nedlasting av musikkfiler. Brukerne er i hovedsak bedriftens ansatte. Jan Harald Nilsen og Tore Mallaug vil ha ansvaret for forvaltning og drift hos kunden. 4

Forstudie BADR - 5 3 Prosjektmål Prosjektets mål er grunnlag for: Å bli enige med oppdragsgiver om hva som skal bli resultatet av prosjektet. Å kunne planlegge å styre. Å kunne vurdere i ettertid om resultatet av prosjektet ble slik som avtalt med oppdragsgiver. Å få en felles forståelse i prosjektgruppa for hva jobben går ut på. - Hentet fra Mal forstudierapport 3.1 Effektmål Effektmål effekten av prosjekt. Effektmål beskriver hva oppdragsgiver vil oppnå med prosjektet. Effektmål kan være knyttet til organisasjonens strategiske planer eller taktiske planer. - Hentet fra Mal forstudierapport Det forventes fra firmaet at arbeidskapasiteten til selgerne øker så mye at det er tilstrekkelig med 11, mot dagens 13, selgere etter implementering. Dette gjør at provisjonen til selgerne kan reduseres til 9 %, mot dagens 10 %, uten at de går ned i lønn. Som et resultat av innvesteringen i et nytt system, forventes det å gi en bedre kundebehandling og derav forventes det at det skal gi en salgsøkning på 5 % mer enn det som var tilfellet det siste året. Redusere behovet for arbeidskraft med to årsverk. Redusere sykefravær med 10 % som et resultat av mindre belastning på de ansatte. Bedre oversikten av avansen på hver enkelt vare med 100 %. Dette øker til 100 % fordi det eksisterer ingen oversikt per i dag. Redusere de manuelle rutinene i bedriften med 30 %. Systemet gir en bedre lagringsoversikt og fjerner således overlagringskostnader med 16 % 3.2 Resultatmål Resultatmål resultatet av prosjektet. Resultatmålet beskriver hva som konkret skal foreligge som resultat når prosjektet er ferdig. - Hentet fra Mal forstudierapport Systemet skal være ferdig implementert innen 30. november 2009, som er en absolutt frist.. Implementere et vareregister hos AS CD Magasinet som er utviklet i MySQL. Implementere en sluttbrukerapplikasjon hos AS CD-Magasinet som snakker opp i mot vareregisteret. GUI som er laget i Visual Basic. 5

Forstudie BADR - 5 3.3 Prosessmål Prosessmål. Dette er mål som ikke er knyttet direkte til det prosjektet skal produsere, men til den prosessen prosjektet skal igjennom for å produsere. Kort formulert kan vi si at prosessmål er mål for den effekten prosjektarbeidet skal ha på prosjektdeltagerne og vil være en kombinasjon av individuelle og kollektive forventninger til prosjektet. - Hentet fra Mal forstudierapport Alle medlemmene skal ha deltatt i prosjektet. Prosjektets medlemmer skal utvikle sin kompetanse til å dokumentere prosjektarbeid. Oppnå en bedre forståelse av omfanget som ligger bak systemutvikling. Øke samarbeidsevnen til hvert enkelt prosjektmedlem. Prosjektets medlemmer skal utvikle bedre kompetanse i systemutvikling. Alle medlemmene skal utvikle en bedre kompetanse innen programmering i VB.Net og behandling av MySQL. Komme fram til en løsning der alle er enig. 3.4 Prosjektets omfang Prosjektgruppen skal jobbe med å utvikle et system ved hjelp av VB.Net, MySQL og dokumentere arbeidet etter god PRS standard. Systemutviklingen skal tilfredsstille kravene som er presentert prosjektets medlemmer. Systemutviklingen er estimert til å ta 600 timer. System skal ikke utvikles ved hjelp av andre høynivåspråk en VB.Net. Systemet skal ikke utvikles i andre databaseverktøy en MySQL. Prosjektgruppen skal ikke drive brukeropplæring 6

Forstudie BADR - 5 4 Rammebetingelser. Det som setter krav og begrensninger til dette prosjektet er: Prosjektet skal være komplett og overleveres den 30. Nov 2009 til oppdragsgiver. Prosjektet har et tak på maks 150 timer per ansatt. Systemet skal utvikles i ved hjelp av MySQL, VB.NET Visual Studio og MS Visio (eller tilsvarende).» Det skal implementeres funksjonalitet for å registrere plater og bestillinger av plater fra Visual Basic-grensesnittet inn i databasen (én eller flere skriveoperasjoner mot databasen).» Funksjonalitet (én eller flere) for å få ut statistikk over salget (én eller flere leseoperasjoner mot databasen), inkludert oversikt over avansen.» Det skal i tillegg lages brukergrensesnitt til resten av funksjonaliteten, men det er ikke et krav at disse skal implementeres ferdig.» Databasen opprettes i sin helhet i MySQL I arbeidet med å utvikle systemet skal dere følge én bestemt utviklingsmodell som er dokumentert i en egen plan. Her går det fram hvilke faser systemutviklingsarbeidet skal deles inn i og hvilke del rapporter og dokumentasjon dere skal produsere underveis og til hvilke tidspunkt. I tillegg til dokumentasjonen i utviklingsmodellen skal besvarelsen inneholde eksempler på kildekode som viser hvordan lese- og skriveoperasjoner mot databasen er programmert, samt alle SQL-setninger. Det skal leveres en sluttrapport som i tillegg til del rapportene skal inneholde en evaluering av selve teamarbeidet. Her skal teamet oppsummere erfaringer med prosjektarbeidet og med samarbeidet i teamet. - Disse opplysningene er utdrag og direkte avskrift fra problembeskrivelsen prosjektgruppen har mottatt. 7

Forstudie BADR - 5 5 Kritiske suksessfaktorer Brukerne for programmet burde ha en ansatt, en superbruker/ driftsansvarlig, som forstår hvordan programmet virker skulle det dukke opp mindre problemer for rask fiksing ved kontakt med utviklerne. Programmet burde være såpas enkelt å bruke at alle ansatte med minimal forståelse for data kan utnytte programmet til ønskelig grad. Ved lansering må de tiltenkte brukerne introduseres for brukergrensesnittet for å gjøre overgangen til det nye systemet så smertefritt som mulig. Databasen må ha en fortløpende oppdatert oversikt av varebeholdningen slik at det kutter drastisk ned på behovet for ansattes tidsbruk på manuelle rutiner. Databasen burde inneholde oversikt over hvor platene befinner seg i butikkens reoler og lagerplassering for å kutte ned på tid brukt på manuell leting. Løsningen må kjøre en automatisert statistikk på fortjeneste av de forskjellige platene og platekategoriene for å gjøre det lettere for kjeden å satse på de områdene med mest fortjeneste. Det må avsettes nødvendige midler til opplæring, drifting og videreutvikling av systemet. 8

Forstudie BADR - 5 6 Risikoanalyse Forhold som kan hindre at prosjekt lykkes. 1. Prosjektgruppen er nyetablert og kan få problemer med å oppnå kompetansen og skaffe de ressursene som er nødvendig for gjennomføringen av selve prosjektet. 2. Det kan oppstå sykdom/fravær i prosjektgruppa som vil sette overholdelsen av gitte tidsfrister i fare, og kan også medføre et mye dårligere resultat enn forventet. 3. Systemet kan ha alvorlige mangler ved implementering. 4. Vi kjenner ikke datakvaliteten i eksisterende dataregister, det kan bety problemer når vi skal laste over data. 5. Rapportsystemet kan generere rapporter som ikke samsvarer med aktuelle tall. 6. Vedlikeholdskostnadene av systemet kan bli større en antatt. 7. Redundans kan oppstå i databasen. 8. Hvis både databasen og backupsystemet krasjer medfører dette tap av viktig data/informasjon som ligger i databasen. 9. Effektiviteten øker ikke slik det er estimert. 10. Prosjektet kan overskride linjeorganisasjonens kostnadsrammer. Figur 6.1. Risikoanalyse Risikoanalyse som viser sannsynlighet i forhold til konsekvens i de problemene vi antar kan oppstå. 1 Oppnå kompetanse 2Sykdom/Fravær K o n s e k v e n s e r 10 9 8 7 6 5 4 3 2 1 8 10 5 3 7 9 1 2 6 4 3 Publiseringsmangler 4 Dataregistreringsfeil 5 Korrupt rapporteringssystem 6 Store vedlikeholdskostnader 7 Redundans 8 Komplett datatap 9 Feilestimert effektivitet 0 0 2 4 6 8 10 Sannsynlighet 10 Overskride kostnadsrammer 9

Forstudie BADR - 5 Mer detaljert om hvert enkelt punkt 1. Prosjektets medlemmer er ferske i dette fagfeltet og bringer med seg liten til ingen erfaring fra før av. Dette kan medføre hindringer i spesielt programmeringen av selve programmet. Sannsynligheten for at dette denne risikoen inntreffer er ganske høy, men det forventes kun å ha moderat innvirkning på systemutviklingen, siden vi er i et skolemiljø. Løsninger kan være å søke hjelp hos lærere, profesjonelle innenfor fagfeltet prosjektgruppen kjenner personlig eller få tips og hint fra studenter på et høyere plan. 2. Sannsynligheten er svært høy her og konsekvensene moderate. Mulig effekt av denne risikoen er at arbeidsbelastningen blir skeiv. Dette kan skape et dårligere arbeidsmiljø innad i prosjektgruppen. Det vil være viktig å ha stort fokus på god varsling og samtaler for å forebygge dette. 3. Mangler ved implementering er et bekymringspunkt som kan medføre forsinket oppstart og kostnadsoverskridelser. Ved hjelp av grundig testing og debugging kan dette unngås 4. Usikkerhet rundt registeret som brukes nå og kvaliteten på dataen som finnes der kan skape problemer ved konvertering til MySQL løsningen. Denne risikoen er uforutsigbar og må løses fortløpende under utvikling. 5. Ved programmering kan formlene ha små mangler som ikke gir riktige rapporter ut til sluttbrukeren. Dette kan medføre feilbestillinger og ikke korrekt fortjeneste på varer. Konsekvensene av en slik feil kan bli svært store. Her må det testes og debugges grundig for å unngå dette. 6. Etter implementering kan kostnadene for vedlikehold og drift vise seg å bli større en antatt. Dette kan gjøre hele systemet ulønnsomt om kostnadene skulle vise seg å være mye høyere en antatt. Kostnadene kan holdes nede ved hjelp av gode rutiner og planlegging. Forstudie, systemkrav og brukerkrav er viktige verktøy for å avdekke dette. 7. Dobbeltlagring er et problem som det er lite sannsynlighet for vil oppstå, men konsekvensene kan fort bli store. Dette kan unnsåes ved hjelp ER-diagram og relasjonsskjema. En annen viktig faktor blir selve opprettingen av databasen. 8. Ved datatap kan konsekvensene bli veldig store. Tidrammen kan ryke om dette skulle inntreffe og kostnadene kan øke. Informasjon som vi ikke kan sette noen verdi på kan også gå tapt. Sannsynligheten for at noe slikt skal oppstå er liten og kan holdes liten ved gode backuprutiner. 9. Systemet kan vise seg å være mindre tidsbesparende en antatt. Vi anser dette til å kunne oppstå, og at konsekvensene er middels. Dette kan medføre at den eventuelle nedbemanningen ikke kan gjennomføres slik det er planlagt. For å unngå dette må det en sluttbrukerapplikasjon testes grundig, debugges og strømlinjeformes for best mulig arbeidsflyt. 10. Kostnader er alltid estimater og kan overskrides. Konsekvensene av dette er økte kostnader for kunde og oss. I verste tilfelle kan dette medføre at prosjektet blir ulønnsomt. Ved en tett oppfølging og strukturerte arbeidsrutiner kan dette unngås. Vi kan av dette dra en slutning som at dette prosjekt kan gjennomføres uten store risikoer. De faktorene der sannsynligheten er relativt høy har ikke konsekvensene så mye å si. Og der risikoen er høy er konsekvensene relativt lave. Ut i fra disse faktorene ser vi ingen grunn til å stoppe utviklingsprosessen på grunnlag av risikoene som er nevnt. 10

Forstudie BADR - 5 7 Kost /Nytte Dette er en viktig del av beslutningsgrunnlaget for om prosjektet skal gjennomføres. Hensikten er å avgjøre om nytten av prosjektet er verdt kostnadene ved å gjennomføre det. - Hentet fra Mal forstudierapport 7.1 Effektmål Det forventes fra firmaet at arbeidskapasiteten til selgerne øker så mye at det er tilstrekkelig med 11, mot dagens 13, selgere i fremtiden. Dette gjør at provisjonen til selgerne kan reduseres til 9 %, mot dagens 10 %, uten at de går ned i lønn. Som et resultat av innvesteringen i et nytt system, forventes det å gi en bedre kundebehandling og derav forventes det at det skal gi en salgsøkning på 5 % mer enn det som var tilfellet det siste året. Redusere behovet for arbeidskraft med to årsverk. Redusere sykefravær med 10 % som et resultat av mindre belastning på de ansatte. Bedre oversikten av avansen på hver enkelt vare med 100 %. Redusere de manuelle rutinene bedriften med 30 %. Systemet gir en bedre lagringsoversikt og fjerner således overlagringskostnader med 16 % 7.2 Kvantifiserbar nytte Øke omsetningen med 11 %, 5 % med nytt system og 6 % fra tidligere år. Årlig omsetningen vil øke med 2 855 093 kroner andre år, 2 771 134 tredje år, 2 669 476 kroner fjerde år og 2 548 426 kroner femte år. Øke effektiviteten hos selgerne, ved at selgerne slipper å manuelt redigere Excel arket. 7.3 Ikke kvantifiserbar nytte Mer tilfredsstilte kunder, dette blant annet fordi det tar mye kortere tid og ekspedere hver enkelt kunde. De enkle arbeidsoppgavene kan gi de ansatte bedre arbeidslyst og trivsel. 7.4 Bortfall av direkte kostnader Bortfall av kostnader, ved å gi de to mest ineffektive arbeiderne avskjed. 7.5 Estimerte kostnader Se regneark for kostnader ved innføring av det nye systemet, i tillegg til lisensavtaler og vedlikehold av systemet de kommende årene. 7.6 Sammenstilling kost/nytte - se regneark. 11

Forstudie BADR - 5 Kost / Nytte År1 År2 År3 År4 År5 Sum Kvantifiserbar nytte n1 n2 n3 n4 N Bortfall kostnader k1 k2 k3 k4 K Sum nytte n1+k1 n2+k2 n2+k3 n2+k4 n+k Utviklingskostnader Y Drifts- og forventingskostnader x1 x2 x3 x4 X Sum kostnader x1 x2 x3 x4 Y+X Beregnet nytte(nytte - kostnader) -Y (n1+k1) -x1 (n2+k2) -x2 (n3+k3) -x3 (n4+k4) -x4 N+K-Y+X År1 År2 År3 År4 År5 Sum Kvantifiserbar nytte kr 22 500 000 kr 24 975 000 kr 26 223 750 kr 27 534 938 kr 28 911 684 kr 130 145 372 Bortfall kostnader kr 345 824 kr 380 093 kr 397 384 kr 415 539 kr 434 601 kr 1 973 441 kr 26 621 Sum nytte kr 25 355 093 134 kr 27 950 476 kr 29 346 286 kr 132 118 813 Utviklingskostnader kr 712 500 kr 712 500 Drifts- og forventingskostnader kr 142 500 kr 142 500 kr 142 500 kr 142 500 kr 570 000 Sum kostnader kr 142 500 kr 142 500 kr 142 500 kr 142 500 kr 1 282 500 Beregnet nytte(nytte - kostnader) kr -712 500 kr 25 212 593 kr 26 478 634 kr 27 807 976 kr 29 203 786 kr 131 976 313 Timepris kr 950 Antall timer kr 150 Antall personer 5 Totalt antall timer kr 750 Total lønn per person kr 142 500 Total kostnad for implementering av nytt system kr 712 500 Videre driftskostnader, 20 % av totalkostnaden ved innføring kr 142 500 12

Forstudie BADR - 5 Sett at omsetningen øker med 11% Årsomsetning kr 22 500 000 Årsomsetning kr 24 975 000 Resultat før skatt kr 3 500 000 Resultat før skatt kr 3 158 625 Firmaets bemanning: Firmaets bemanning: Antall ansatte 15 Antall ansatte 13 Lønn til 13 selgere kr 120 000 +10 % provisjon Lønn til 11 selgere kr 120 000 +9 % provisjon Lønn til Daglig leder kr 470 000 Lønn til Daglig leder kr 470 000 Lønn til sekretær kr 300 000 Lønn til sekretær kr 300 000 1% av provisjonen kr 225 000 1 % av provisjonen kr 249 750 10 % provisjon kr 2 250 000 9 % provisjon kr 2 247 750 Lønn til 13 selger kr 2 370 000 Lønn til 11 selger kr 2 367 750 Lønn per selger kr 182 308 Lønn per selger kr 215 250 Lønn til Daglig leder kr 470 000 Lønn til Daglig leder kr 470 000 Lønn til sekretær kr 300 000 Lønn til sekretær kr 300 000 Totale lønnskostnader kr 3 140 000 Totale lønnskostnader kr 3 137 750 År1 År2 År3 År4 År5 Årsomsetningen uten innføring kr 22 500 000 kr 23 850 000 kr 25 281 000 kr 26 797 860 kr 28 405 732 Årsomsetningen med innføring kr 25 355 093 kr 26 621 134 kr 27 950 476 kr 29 346 286 Differanse kr 2 855 093 kr 2 771 134 kr 2 669 476 kr 2 548 426 Sum differanse kr 10 844 129 7.7 Konklusjon kost/nytte Første året vil det ikke være den store endringen, men bedriften får en ekstra kostnad som gjør at vi som utviklere kan begynne oppgaven. Uten endringer vil dagens system gi et 23,8 millioners overskudd, men med det nye systemet vil neste års omsetning ha økt til 25,3 millioners. dvs. 2,8 millioner mer i omsetning det første året. Deretter vil omsetningen stagnere noe, med vil like vel øke med tanke på sparte kostnader og økt årlig omsetning. Total differanse på 5 års perioden vil være 12 477 093 kroner i løpet av en fem års periode. 13

Forstudie BADR - 5 8 Retningslinjer og standarder Denne delen finner vi retningslinjer og standarder for prosjektet. Prosjektgruppen forholder seg til de punktene som er skrevet i dette kapitelet gjennom hele prosjekt perioden. 8.1 Dokumentasjon All dokumentasjon skal foreligge elektronisk på vår ftp-server minst en dag før innlevering. OpenOffice brukere skal lagre dokumentasjonen i.doc format. Dokumentasjonsansvarlig skal revidere alle dokumenter og korrigere ved behov. http://dasdos.etherpad.com/, som er et web basert samskrivningsverktøy, som brukes for å godkjenne dokumentasjonstekst før opplasting til ftp-server. Dokumentmaler som blir utarbeidet skal ligge på ftp-serveren under dokumentasjonsmappen. Times New Roman skal brukes som skrift type på ordinær tekst. Påkrevd dokumentasjon og dato når den skal foreligge: Arbeidskontrakt Skal leveres den 14.10.2009 Forstudierapport Skal leveres den 14.10.2009 Gannt-diagram Skal leveres den 14.10.2009 ER modell Skal leveres den 14.10.2009 Brukerkravdokumentasjon Skal leveres den 28.10.2009 Systemkravdokumentasjon Skal leveres den 11.11.2009 Brukerveiledning Skal leveres den 30.11.2009 Sluttrapport Skal leveres den 30.11.2009 8.2 Programmering Programmering skal foregå i høynivåspråket VisualBasic.Net og Visual Studio skal brukes som utviklingsmiljø. All programmering som prosjektets medlemmer utfører skal starte med en kommentar som innholder dato, initialer og om det er start eller redigering av kode. Kommentaren plasseres øverst i formen om ikke det er nødvendig med nøyaktig merking. Beskrivende kommentarer skal alltid brukes når man programmerer. Når noen av prosjektets medlemmer endrer på kode skal dette kommenteres med initialer, dato og endringens art i toppen av skjemaet. Ny kode skal lastes opp til ftp-serveren. Variabler skal ha navn etter camelcasing prinsippet og starte med forbokstaven i deklareringen. Alle variabler skal også ha beskrivende navn. 8.3 Database Databasen skal lages i MySQL og med phpmyadmin som utviklingsmiljø. Alle tabeller og attributter som lages skal ha beskrivende navn. 14

Forstudie BADR - 5 9 Prosjektorganisasjon Her skal vi se på hvem som er med i prosjektet, og hvilke roller de har. Prosjektgruppen vil gjøre alt arbeidet og lage forslag til å tjene kundens ønsker. Kvalitetskontroll vil bli gjort av en veileder (lærerne) som vurderer kvaliteten fra et akademisk synspunkt. Prosjektlederen vil for dette prosjektet vil være Sebastian, vi vil bytte ved neste prosjekt. Referansegruppen fra brukerne (lærerne) vil vurdere resultatet sett fra oppdragsgivers side. Prosjektmedlemmene fordeler arbeidet slik at oppgaver blir gitt av prosjektleder, medlemmet lager så utkast av oppgaven. Så blir alle utkastene gjennomgått og perfeksjonert av hele gruppa. Figur 9.2. Prosjektorganisasjon. Viser fordeling av sentrale personer i prosjektfasen. 15

Forstudie BADR - 5 10. Anbefalinger og videre arbeid Her vil vi oppsummere og gi referanser de faktorene vi legger til grunn for våre anbefalinger Produktet som tilbys vil tillate bedriften i nåværende lokaler, det vil redusere behovet for arbeidskraft med 2 årsverk. Uten å øke belastningen på vær enkelt medarbeider, i tillegg til å unngå et økt varelager, som er en stor risiko. Figur 10.1 Resultat etter fem år med innført system mot fem år med videre bruk av dagens system. Som vi ser er det av våre tall mulig og spare inn 10,8 millioner kroner de første fem årene. Ut i fra kost nytte analysen, vil innføringen av systemet øke årlig omsetningen med kroner 10 844 129 i løpet av en 5 års periode, sett at man allerede er i år1 av innføringsperioden, hvor det ikke blir innført noen endringer, men utviklingen av systemet har startet. I år2 vil omsetningen øke med kroner 2 855 093. Videre øker omsetningen og i år5 vil omsetningen ha økt med hele 2 548 426 kroner i forhold til år5 uten innføring. Første året vil det ikke være den store endringen, men bedriften får en ekstra kostnad som gjør at vi som utviklere kan begynne oppgaven. Uten endringer vil dagens system gi 23,8 millioner i overskudd, men med det nye systemet vil neste års omsetning ha økt til 25,3 millioners. dvs. 2,8 millioner mer i omsetning det første året. Deretter vil omsetningen stagnere noe, med vil like vel øke med tanke på sparte kostnader og økt årlig omsetning. Vi i Badr5 anbefaler på det sterkeste at prosjektet videreføres innenfor de gitte rammene. Vi ser store fordeler ved en suksessfull gjennomføring av dette for begge parter. Referanser Problembeskrivelse https://www.itslearning.com//file/fs_folderfile.aspx?folderfileid=779897 Leksjoner i faget PRS https://www.itslearning.com//folder/process_folder.aspx?folderid=754112 Etherpad.com https://dasdos.etherpad.com/1 (1-12) Arbeidsplan http://tihlde.org/~sebastis/prosjekt/arbeidsplan.html Mal Forstudie https://www.itslearning.com/main.aspx?courseid=7822 16

Forstudie BADR - 5 11 Vedlegg Gannt Diagram 17

ER Modell

Brukerkrav 2009 dokument BADR 5 Vedlegg 2 Brukerkrav dokument Nytt datasystem hos AS CD-Magasinet Hensikten med brukerkrav dokumentet er å kartlegge hva AS CD-Magasinet forventer å ha mulighet til med det nye systemet MusicSurfer. Utviklere av prosjektet Sebastian Strømnes Eskil Espås Ugelstad Christoffer Framstad Lokrheim Fredrik Lundsrud Håkon Wahl Engen BADR5 DASDOS Jügend 26.11.2009

Brukerkrav dokument BADR - 5 1 Introduksjon - Hensikten med dokumentet Dette dokumentet skal gi leseren en rask og grundig beskrivelse av hvilke krav og forutsetninger som ligger til grunnlag for de valgene prosjektgruppa tar og har tatt i utviklingen av systemet. Det skal samtidig gi leserne en felles forståelse av brukerkravene hos oppdragsgiver og utviklingsgruppe. Dokumentet inneholder også en kort introduksjon til prototypen. 1.1 Litt om hvordan dokumentet skal tolkes Dokumentet skal tolkes som en enkel forklaring av våre grunntanker om brukernes og veiledernes krav til prosjektet. Vi håper at ved å ha lest forstudie dokumentet og brukerkravdokumentet, skal leseren ha et klart bilde av hvordan prosjektgruppen tror oppgaven ønskes utført. Prosjektgruppen håper også på klare tilbakemeldinger fra brukere og veiledere på de enkelte funksjonene i sikt om konstant forbedring av programmet frem til lansering. 1.2 Oversikt over innholdet Innholdsfortegnelse 1 Introduksjon - Hensikten med dokumentet... 2 1.1 Litt om hvordan dokumentet skal tolkes... 2 1.2 Oversikt over innholdet... 2 2 Overordnet prosjektbeskrivelse/systembeskrivelse... 3 3 Krav til nytt system... 4 3.1 Krav til funksjoner... 5 3.2 Krav til datainnhold og overordnet lagringsstruktur... 11 3.3 Krav til egenskaper... 11 4 Kort introduksjon til prototypen av brukergrensesnittet... 14 5 Reviderte resultater fra forrige fase... 19 5.1 Reviderte prosjektmål... 19 5.2 Reviderte rammebetingelser... 19 5.3 Revidert risikoanalyse... 19 5.4 Revidert fase og milepælsplan... 19 5.5 Revidert ER modell... 19 Referanser... 19 2

Brukerkrav dokument BADR - 5 2 Overordnet prosjektbeskrivelse/systembeskrivelse Utgangspunktet er å lage et skreddersydd program til den aktuelle bedriften. Butikken tilbyr kun salg av fysiske plater direkte til kunden i butikken, eller ved at kunden bestiller plater via telefon eller e-post til butikken. Butikken tilbyr ikke nedlasting av musikkfiler. Informasjon om alle platene finnes i dag i en katalog som er tilgjengelig i butikken i et regneark. Hver gang butikken kjører salg/kampanjepriser må utsalgsprisene i katalogen oppdateres. Alle plater i katalogen lagerføres og bestilling av nye plater skjer når lagerbeholdningen synker til et visst nivå. Bestillingsgrensen er forskjellig for ulike platekategorier. Dette krever at en har god oversikt over varebeholdningen, noe som er vanskelig og tidkrevende med manuelle rutiner. Butikken har ikke noe system til å automatisere kundenes forespørsler. Når en kunde kjøper eller bestiller plater, blir platene hentet fra butikken og/eller lageret, og det skrives en ordreseddel. Skulle det være tomt for én eller flere plater, blir det laget en restordre. I dagens situasjon er det vanskelig å holde oversikt over avansen til platene, siden katalogen kun inneholder utsalgsprisen. Innkjøpsprisene har butikken ingen felles oversikt over. Butikken har m.a.o. ingen god oversikt over hvilke plater de har størst fortjeneste på. Ofte er det vanskelig for butikkansatte å vite hvor de ulike platene står i butikken. I dagens situasjon finnes det ingen klar oversikt over dette, noe som medfører at mye tid går med til leting etter ulike plater i butikken og på lageret. Hvis firmaet skal være i stand til å håndtere en forventet vekst i salget og forbli i de eksisterende lokaler, er det nødvendig å gå til anskaffelse av et datasystem for å få automatisert flest mulig av dagens manuelle rutiner. Brukerne er i hovedsak bedriftens ansatte og kunder, hvor tilgangsnivået skilles mellom kunder, selgere, sekretær og bedriftens sjef (administrator). Det ferdig utviklede systemet skal kunne hjelpe AS CD-Magasinet med alle de ovennevnte problemstillingene. Det skal forenkle de daglige rutinene, og forbedre bedriftens plassutnytting. Prosjektgruppen består av Sebastian Strømnes, Eskil Espås Ugelstad, Christoffer Framstad Lokrheim, Fredrik Lundsrud og Håkon Wahl Engen. Jan Harald Nilsen er organisatorisk leder. 3

Brukerkrav dokument BADR - 5 3 Krav til nytt system Dette dokumentet skal spesifisere hva brukerne krever av oss som utviklere til å få et system som fungerer i praksis og ikke bare i teorien. Systemet skal være brukervennlig på alle punkter og virke kjent for alle som har vært borti lignende systemer. Mulighetene for de forskjellige brukerne skal være begrenset, men daglig leder, systemansvarlig og sekretær skal ha tilgang til alt, slik at det er lett å registrere og vedlikeholde systemet. Butikkmedarbeiderne skal ha begrenset tilgang, men muligheten til å ta seg av mye av de praktiske gjøremålene som må til for å vedlikeholde systemet for organiseringen i butikken. Brukeren ønsker å ha en oversiktlig og enkel søkefunksjon som raskt kan taes i bruk og har kort søketid. Søkefunksjonen skal henvise til aktuelle rapporter som lagerbeholdning, plassering i butikk i tillegg til å vise aktuell informasjon om den aktuelle varen. Varer skal registreres med EAN nummer og et varenummer. Begge skal kunne brukes som referanse til en spesifikk vare. Systemet har da med andre ord muligheten til å utvide funksjonaliteten ved å kunne bruke strekkode leser, men denne tilleggs modulen må bedriften selv gå til investering i. 4

Brukerkrav dokument BADR - 5 3.1 Krav til funksjoner selger dagligleder «uses» * «uses» System Innlogging brukernavn og passord kan være feil * * feilbruker «extends» «uses» * * * sekretær kunde «uses» Inntekt «extends» returavvare ** * * * Salg retur av vare * * Kunde Sekretær * vareregister * «extends» «uses» * * * * * * * søk * Daglig leder * * * administrasjon «uses» * vareadministrasjon «uses» innkjøp Selger * brukerkontroll «uses» leggtilbruker * Rapport generering «uses» «uses» slettbruker endrebruker Figur 6.1. UseCase Diagram. 5

Brukerkrav dokument BADR - 5 Dette er en tekstlig forklaring på hver eneste Use Case i diagrammet, hvert punkt forklarer hva hver Use Case blir brukt til. Navn: Innlogging Mål: Å logge inn som selger, administrator eller sekretær, man kan også få tilgang til søk og vareplassering ved å aktivere kunde -inngangsdøren. Aktører: Det er selger, administrator og sekretær Trigger: Når personen skal logge inn Pre Betingelse: Skrive inn riktig brukernavn og passord Post betingelser: Logge inn som forskjellige aktører, avhengig av type aktør vil en bruker få tilgang til færre eller flere rettigheter i programmet, hvis brukernavn/passord er feil, vil brukeren ikke klare å logge inn. Hovedløp: Aktøren får tilgang til systemet og kan bruke visse alternativer f.eks. salg eller vareregister Sideløp(variasjoner): Aktøren kommer ikke inn i systemet og blir bedt om å taste inn korrekt brukernavn og passord. Navn: dagligleder Mål: Logge inn som daglig leder Aktører: Daglig Leder Trigger: Daglig leder logger inn og får tilgang til alle vinduer Pre Betingelse: Riktig brukernavn og passord kreves for å logge inn som daglig leder Post betingelser: Daglig leder logger inn og får tilgang til administrasjons rettighetene, dvs. endre, opprette og slette brukere, samt diverse statistikker over salg og økonomi. Dette gjelder kun daglig leder. Hovedløp: Aktøren kommer inn på systemet og tar i bruk administrasjons delen av programmet og f.eks. sletter en selger fra brukerlisten som nettopp har sagt opp jobben. Sideløp(variasjoner): Hvis daglig leder logger inn på systemet så får daglig leder full tilgang til alle aspekter Relatert informasjon: Daglig leder og sekretær er den eneste som får tilgang til flere aspekter av programmet enn det selgeren får. Dette er for å forhindre misbruk av systemet. Navn: Salg Mål: Kunne registrere et salg av en plate, slik at det trekkes fra et antall fra varelageret og sørge for at prisen som blir betalt er riktig. Aktører: Selger Trigger: Kunden initierer et salg, der selger leser inn strekkoden og oppgir prisen til kunden, og sørger for at pengene blir lagt i kassen eller at kortet blir trukket. Pre Betingelse: Kunden kommer med ønsket vare, varen blir registrert av selger og penger blir utvekslet mellom de to, enten via kort eller kontant. Post betingelser: Selger registrer handelen og kunden får ønsket vare. Deretter blir det automatisk fjernet ønsket antall varer fra varelageret. Hovedløp: Kunden får varen og selgeren får penger, i form av kort eller kontant, med den forutsetning av varen er på lager. Sideløp(variasjoner): Kunden har ikke nok penger eller at varen er utsolgt, eller varen ikke lenger blir lagerført. Relatert informasjon: Hvis varen ikke er i lageret eller det er utsolgt vil selger registrere dette eventuelt bestille nytt/mer fra leverandør, hvis varens status fortsatt er satt til lagervare. 6

Brukerkrav dokument BADR - 5 Navn: Inntekt Mål: Vise en statistikk over solgte varer Aktører: sekretær og daglig leder Trigger: Varer er blitt solgt og aktørene ønsker en oversikt over antall solgte eller inntekten innenfor en periode, f.eks. desember måneden. Pre Betingelse: Varer må ha blitt solgt for at systemet skal kunne brukes. Post betingelser: Aktøren kan skrive ut en kopi slik at det kan lagres som dokumentasjon over antall solgte/inntekt Hovedløp: Aktøren får en oversikt over inntekten slik at statistikken kan brukes for å bestille flere varer. Sideløp(variasjoner): Dårlig salg av plater og/ eller lite i inntekter Relatert informasjon: Svært behjelpelig oversikt over hva som har blitt solgt og antall solgte, slik at det blir lettere å bestille flere varer fra leverandør. Navn: returavvare Mål: Kunden ønsker å returnere en vare Aktører: kunde og selger Trigger: Kunden ønsker og bytte vare Pre Betingelse: Kunden trenger kvittering og et produkt med ubrutt forseiling, hvis ikke kan ikke kunden returnere varen siden varen kan ha blitt misbrukt. Post betingelser: Selger gir pengene tilbake til kunden, dvs. siste utsalgspris og varen returneres til selger og registreres igjen i butikkens beholdning. Hovedløp: Selger mottar varen og leser den inn i systemet ved hjelp av en strekkode. Deretter får man opp informasjon av varen og kunden får pengene det kostet og kjøpe varen ved siste utsalgspris. Sideløp: Brutt forsegling eller mangel på kvittering fører til at kunden ikke kan returnere varen. Relatert informasjon: Krav til retur av vare er ubrutt forsegling eventuelt kvittering. Navn: administrasjon Mål: Lar dagligleder og sekretær få en oversikt over diverse undergrupper som hjelper til med en oversikt over økonomi, selgere og innkjøp. Aktører: Sekretær og daglig leder Trigger: Sekretær eller daglig leder logger inn for å få tilgang til områdene. Pre Betingelse: Krever riktig brukernavn og passord Post betingelser: Aktøren får tilgang til områder som er lukket for selgerne Hovedløp: Personen logger inn og får muligheten til og endre brukere, få en oversikt, bestille nye varer fra leverandør og får en oversikt over økonomien. Sideløp: Relatert informasjon: Sekretær og daglig leder er de eneste med tilgang til denne funksjonen. 7

Brukerkrav dokument BADR - 5 Navn: leggtilbruker Mål: Å legge til en ny bruker som kan logge på systemet Aktører: Daglig leder og sekretær Trigger: En ny ansatt har startet i bedriften og trenger tilgang til systemet for å begynne å arbeidet. Pre Betingelse: Krever en ny ansatt Post betingelser: Brukeren blir opprettet av daglig leder, og er klar til bruk like etter opprettelse. Hovedløp: Sekretær eller daglig leder oppretter og selger er klar til opplæring av systemet etter kort tid. Sideløp(variasjoner): Det blir gjort feil i opprettelsen av brukeren, som kan føre til at det tar lengre tid enn normalt. Relatert informasjon: Ny brukere kan til dags dato ikke få endret sin adgangstillatelse, slik at en selger med mye tillit kan få tildelt flere alternativer f.eks. Tilgang til delen kalt innkjøp. Navn:slettBruker Mål: slette en bruker fra systemet. Aktører: Daglig leder, sekretær og selger Trigger: En bruker slutter i bedriften og hans brukernavn/ passord må dermed fjernes fra systemet. Pre Betingelse: En selger må slutte eller sparkes Post betingelser: Det vil dermed være en mindre selger i bedriften. Hovedløp: Det finnes en mindre selger i bedriften etter at daglig leder eller sekretær har fjernet personen fra systemet. Sideløp(variasjoner): Feil bruker fjernes. Relatert informasjon: Bruker kan legges til igjen, men da må all informasjon legges inn på nytt. Navn: endrebruker Mål: Endre en bruker i systemet Aktører: Daglig leder, sekretær og selger Trigger: En bruker ønsker f.eks. å endre passord Pre Betingelse: brukeren må være registrert i systemet og ønsker endringen. Post betingelser: Passordet er endret og det nye passordet brukes for å logge på systemet. Kan blitt skrevet inn feil både av selger og av aktøren som endrer passordet. Hovedløp: Passordet endres og er klar til bruk, uten at det er skrevet inn feil fra noen av aktørenes side. Sideløp(variasjoner): Passordet skrives inn feil fra daglig leder eller sekretærs side, selger kan derfor ikke logge på systemet. Relatert informasjon: Brukes til og endre informasjon om selger, f.eks. telefon adresse osv. 8

Brukerkrav dokument BADR - 5 Navn: vareregister Mål: Få en oversikt over vareregisteret. Aktører: Selger, daglig leder eller sekretær Trigger: Aktørene ønsker en oversikt over vareregisteret Pre Betingelse: Aktørene vil lete frem et bestemt produkt for å sjekke varelagerbeholdning. Post betingelser: Ønsket vare blir funnet fram fra registeret og kan endres eller skrive ut eventuelle statistikker. Hovedløp: Aktøren får en oversikt over all informasjon om ønsket vare. Sideløp(variasjoner): Hvis aktøren skriver feil EAN nummer eller navn på vare vil aktøren enten få frem en annen vare eller ikke finne noe som helst. Relatert informasjon: vareregister er koblet opp mot søk, slik at man enkelt kan søke i vareregisteret. Navn: søk Mål: Hensikten er å finne varer i registeret ved hjelp av en enkelt søk. Aktører: Alle aktørene kan initiere et søk, men hovedsakelig sekretær, daglig leder selger og kunde. Trigger: En kunde ønsker å vite detaljert informasjon om en vare, eller daglig leder ønsker å finne ut om varebeholdningen til en vare. Pre Betingelse: Varen er på lager, eller er blitt bestilt fra leverandør. ERGO den ligger lagret i bedriftens datasystem. Post betingelser: Den bestemte varen er blitt funnet. Hovedløp: Informasjonen som letes opp kan bli formidlet videre til kunden gjennom selger. Eller daglig leder har fått den informasjonen han/hun trenger for å kunne bruke informasjonen videre. Sideløp(variasjoner): Varen er ikke på lager eller i registeret, og det ikke blitt opprettet noen informasjon om varen slik at det ikke finnes informasjon om videre bestillinger, eventuelt ikke ta inn mere av varen for å hindre en for stor varebeholdning Relatert informasjon: Hvis daglig leder ser at det ikke er blitt solgt mye av varen, velger daglig leder og ikke bestille mer fra leverandør for å unngå å ha et for stort varelager som man ikke får solgt videre til kundene. Navn: innkjøp Mål: Hensikten er å få en oversikt over hva som er blitt kjøpt inn, hva som trengs og kjøpes inn og hva som er blitt solgt. Aktører: daglig leder, sekretær eller selger Trigger: Selger melder om at produktet er utsolgt eller at det er lite igjen i varebeholdning og daglig leder/sekretær leser ut ifra statistikken at det er mangel på varen Pre Betingelse: Mangel av varen i lageret eller lav varebeholdning Post betingelser: Vare blir bestilt fra leverandør og ved neste varelevring blir produktet levert hos butikken. Hovedløp: Varen med lav lagerbeholdning blir bestilt fra leverandør med uti fra en beregning gjort på kjøpstall fra tidligere kvartal. Sideløp(variasjoner): Beskriv spesialtilfelle (unntak fra normal hendelsesflyt) separat. Format: if betingelse ="true" then konsekvens Relatert informasjon: for eksempel ikke-funksjonelle krav ("svartid må være bedre enn 10 sekunder") 9

Brukerkrav dokument BADR - 5 Navn: Plantegning Mål: Få en oversikt over hyllene ute i butikken Aktører: Selger, daglig leder og sekretær Trigger: Selger vil finne en plate som er i butikken Pre Betingelse: Platen finnes i butikken Post betingelser: Platen vises i butikken eller så vises den ikke, selger finner platen eller så finner han den ikke. Hovedløp: Selger søker etter platen og finner den i en hylle ute i butikken Sideløp(variasjoner): Platen er blitt flyttet av en kunde, eller platen er blitt flyttet av en selger uten at platen er blitt registrert endret. Navn: Rapporter Mål: Få en oversikt over antall solgte varer, inntekter og kostnader. Aktører: Sekretær og daglig leder Trigger: Daglig leder ønsker å ta en titt på hvor mye bedriften har tjent Pre Betingelse: Bedriften har solgt plater. Post betingelser: Aktøren får en oversikt over antall solgte av en eller flere varer, tillegg til overskuddet, inntekter - kostnader, hvis bedriften ar solgt noen varer. Hovedløp: Aktøren får en oversikt som viser inntekter og kostnader, samt hva overskuddet er i tillegg til egenkapital og hva bedriften skylder leverandører. Sideløp(variasjoner): Aktøren bestiller varer fra en ny leverandør som ikke er inne i systemet. Relatert informasjon: Det kreves at aktøren bestiller varer fra leverandører som er registrert i systemet. Navn: vareadministrasjon Mål: Administrere vareregisteret Aktører: Daglig leder og sekretær Trigger: Sekretær og gjøre endringer på en vare, slette, endre legge til. Pre Betingelse: Varen må være registret. Post betingelser: Varen er blitt endret, feil i vareregistreringen kan være mulig Hovedløp: Varen blir endret og blir oppdatert fortløpende, og ny salgspris er klar. Sideløp(variasjoner): Skrivefeil kan føre til at produktet blir dyrere enn ment. Relatert informasjon: Kun daglig leder og sekretær ar tilgang til denne funksjonen i programmet. 10

Brukerkrav dokument BADR - 5 3.2 Krav til datainnhold og overordnet lagringsstruktur Systemet skal inneholde opplysninger om : Leverandørene Personalia til de ansatte Nødvendig informasjon om de kundene som bestiller produkter Div statistikker. Bla. varer som må bestilles, mest solgte og avanse Produkt informasjon Salg Varer Bestillinger 3.3 Krav til egenskaper Sikkerhet, adgangskontroll o Adgang vil bli begrenset med kryptert passordbeskyttelse hvor hver ansatt stiller til ansvar med brukernavn og passord. o Passord blir kryptert med en krypteringsnøkkel kun de innerste medlemmene av prosjektgruppen har kunnskaper til. Deretter sendt som en kryptert streng over nettet. Når en bruker skal logge på blir det inntastede passordet kryptert med samme nøkkel og sammenlignet med det hentede krypterte passordet. Personnr til de ansatte blir også kryptert når det blir lagt inn i databasen. Dette for å sikre personene mot identitetstyveri Automatiske sikkerhetskopier o All kritisk data vil bli lagret i databasen. Prosjektgruppen har ikke rettigheter inne i MySQL miljøet for å laga automatiske backup løsninger. Pålitelighet, feilfrekvens og konsekvenser ved feil o Så godt det lar seg gjøre vil brukerne få opp gode og beskrivende meldinger når systemet ikke forstår hva brukeren prøver å oppnå. o Der brukeren møter på kritiske løsninger for hvordan vårt utviklings verktøy behandler data, og man kan oppnå at programmet henger seg opp (krasje), vil vi lage nye veier rundt disse bugsene, og programmet kommer da til og forklare brukeren hva som ikke går og for eksempel hvordan han/hun må skrive inn sine data. o Produktet vil ha meget stor pålitelighet, og man kan regne med en oppetid på ca 100 prosent. Den eneste faktoren som kan forårsake en liten nedetid er under implementering av oppdateringer av systemet. 11

Brukerkrav dokument BADR - 5 Brukeregenskaper o Selger Valg av forskjellige salgstyper, kort eller kontant Søk ved hjelp av EAN nummer, varenummer og titler En lettere måte å oppdatere utsalgspris, og plassering i butikken/lager Selv oppdaterende oversikt av platebeholdningen Automatisere kundens forespørsler o Daglig leder/sekretær Registrere, endre og slette varer Oversikt over avansen Oversikt over innkjøpspris Oversikt over fortjeneste Mulighet for å endre og slette brukere/passord Ha et enkelt bestillingsvindu, der man registrerer varer som det må bestilles flere av fra leverandør Kapasitet, datavolum, transaksjonsvolum o Programmet har stor kapasitet utover det systemet trenger, det er også et lite datavolum som skal lagres siden det hovedsakelig er korte tekst entry's som lagres og hentes. Transaksjonsvolumet blir derfor også lite, så det vil tappe lite av brukerens nettverk. Grensesnitt mot andre systemer, standarder for databeskrivelse o Systemet lages med Visual Basic.net i Visual Studio og vil derfor bare virke opp mot Windows systemer. Men tvilsomt at det vil fungere opp mot Windows 9x systemene uten.net. 12

Brukerkrav dokument BADR - 5 Figur 3.1. Kopi av ER modell. Den er laget med kråkefotnotasjonen slik som vi finner i den norsk utviklede applikasjonen Modelator. 13

Brukerkrav dokument BADR - 5 4 Kort introduksjon til prototypen av brukergrensesnittet Prototypen er laget med hovedvekt på at man ikke skal ha så mange vinduer oppe. Fargevalget er satt til systemstandard i Windows, men kan endres etter kundens ønske. Det er brukt parentform og childform får å få til dette. Dette gir brukere fordelen med at man har alle vinduer i et hovedvindu. Dette gir muligheter for å jobbe med flere prosesser samtidlig. Prototypen gir også muligheter til å åpne flere vinduer av det samme type med tanke på flere søk eller separate salg på en gang. Prototypen ligger tilgjengelig testing her: http://tihlde.org/~sebastis/prosjekt/utvikling/prototype.rar Det er viktig å understrekke at dette er en prototype og store endringer kan fortsatt bli gjort på programmet etter kundens ønsker og prosjektgruppens vurderinger. Bilder fra prototypen og kommentarer til de: Login vinduet er første vindu man møter ved oppstart. Dette vinduet krever to input før man kommer videre. Disse inputene er brukernavn og passord. I prototypen kan brukernavn "q" og passord "q" brukes. Avhenging av hvilken bruker man logger inn med så vil tilgangen være forskjellig. Trykk på loginknappen for å verifisere ditt brukernavn og passord. Dette er hovedvinduet i programmet. I dette vinduet vil alle andre vinduer man åpner ligge. Ved oppstart vil salgsvinduet som standard bli åpnet i hovedvinduet. Menyen på toppen brukes til å åpne, administrere og ordne vinduer i hovedvinduet. Figur 4.1 Figur 4.2 14

Brukerkrav dokument BADR 5 Dette er vinduet som brukes ved salg. Ved salg har man mulighet til å velge å registrere varer ved hjelp av varenummer eller EAN. EAN er default ved oppstart slik at man kan lese inn strekkoder. Betallingsformer som aksepteres er kort, kontant eller kundebestlling om det er ordre over tlf eller e-post. Ved registrering av salg så vil varene bli lagt i listboksen. Det er også mulig å fjerne varer fra listboksen ved å trykke angre siste eller markere linjen og høyreklikke. Da vil en meny komme opp. Når salget er sluttført kan man trykke på kvitterings knappen for kvittering om kunden ønsker det. Søke vinduet er delt inn i tre deler, en for søk etter vare, en for informasjon av den valgte vare og en for vareadministrasjon som man ønsker å endre på Figur 4.3 informasjonen som ligger i databasen på en spesifikk vare. Det gis valgmuligheter for å søke etter CD, DVD og BlueRay. Alle søk havner i en listeboks som gjør det lett å velge den riktige varen. Når man har valgt varen man vil ha vil informasjon komme opp til høyre for søket. All informasjon som ligger på varen i databasen vil komme opp her. Figur 4.4

Brukerkrav dokument BADR 5 Dette er en plantegning over bygget som vil være knyttet opp til lokasjonene til de enkelte varer. Lokasjonene er delt opp i reoler. Dette vinduet vil kun daglig leder og sekretær ha tilgang til. Her kan man kunne endre passordet til brukere, legge til brukere og slette brukere. Figur 4.5 Figur 4.6

Brukerkrav dokument BADR - 5 Dette vinduet vil kun daglig leder og sekretær ha tilgang til. Økonomi vinduet vil man kunne generere diverse rapporter ut i fra hva man velger i dropdown listen. Kan skrives til fil eller til skriver. Dette vinduet vil kun daglig leder og sekretær ha tilgang til. Alle bestillinger av varer registreres her. Her kan man velge å legge til varer til bestillinger ved hjelp av varenummer eller EAN. Bestillinger kan skrives til skjerm, fil og skriver. Man kan også angre enkelt linjer ved hjelp av og høyreklikke ønsket vare i listboksen. Figur 4.7 Figur 4.8 17

Brukerkrav dokument BADR - 5 Dette vinduet vil kun daglig leder og sekretær ha tilgang til. I dette vinduet kan man endre attributtene til varene som ligger i databasen. Vareadministrasjon gir også mulighet til å legge til ny vare og slette varer. Ved innhenting av vare informasjon så kan man benytte varenummer eller EAN. Alle endringer man utfører kan lagres og endringen vil overskrive den informasjonen som lå i databasen på den varen man jobbet med. Dette er et oversiktsbilde som viser alle de Figur 4.9 forskjellige vinduene åpne og ordnet ved hjelp av cascade. Vinduer kan også ordnes vertikalt og horisontalt. Figur 4.10 18

Brukerkrav dokument BADR - 5 5 Reviderte resultater fra forrige fase Her finner vi reviderte punkter fra forstudie fasen ved at vi har kommentert eventuelle endringer. Prosjektgruppen har gjennomgått prosjektmål, rammebetingelser, risikoanalysen, milepælsplanen og ER modellen. 5.1 Reviderte prosjektmål Ingen reviderte prosjektmål, må komme skikkelig i gang med det faktiske arbeidet før dette kan bli aktuelt. 5.2 Reviderte rammebetingelser Det har ikke blitt noen endringer på rammebetingelsene. 5.3 Revidert risikoanalyse Ingen endringer ved dette tidspunkt. Vi anser de risiko punktene som er beskrevet i forstudie til å forsatt være gjeldende. Det har heller ikke dukket opp nye problemer eller slått oss at det er andre ting vi står i risiko for. 5.4 Revidert fase og milepælsplan Fase og milepælsplan er fastsatte datorer og har derfor ikke fleksibilitet til å kunne bli forandret. 5.5 Revidert ER modell Det har ikke vært noen endringer på ER modellen siden den ble vist i siste utgave av forstudiet. Referanser Mal brukerkravdokument https://www.itslearning.com/main.aspx?courseid=7822 Leksjoner i faget PRS https://www.itslearning.com//folder/process_folder.aspx?folderid=754112 19

Systemkravdokument 2009 BADR 5 Vedlegg 3 Systemkrav dokument Nytt datasystem hos AS CD-Magasinet Systemkrav dokumentet presenterer løsninger på krav og betingelser gitt av AS CD- Magasinet. Den legger også retningslinjer for videre drift. Utviklere av prosjektet Sebastian Strømnes Eskil Espås Ugelstad Christoffer Framstad Lokrheim Fredrik Lundsrud Håkon Wahl Engen BADR5 DASDOS Jügend 26.11.2009

Systemkravdokument BADR 5 1 Hensikten med dokumentet Det er med dette dokumentet meningen å gi leseren en dokumentasjon på hvilke krav og betingelser prosjektgruppen jobber for å oppnå. Punkt 2 overordnet prosjektbeskrivelse vil man finne en kort beskrivelse av det nye systemet samt en oversikt over hvilke endringer dette vil føre til i organisasjonen og for personalet. Punkt 3 vil vi gå nærmere inn på detaljerte krav til egenskaper der utviklerene reviderer systemets krav til egenskaper. Punkt 4 har tre punkter der man skal beskrive funksjonaliteten med bruk av Use Case modell, bruksmønsteret og en tekstlig spesifikasjon av modellen. Punkt 5 går dypere inn på databeskrivelsen og ER- modellen. Punkt 6 gir en beskrivelse av grensesnittet med skjermbilder der vi grafisk viser frem hva vi vil implementere. Punkt 7 beskriver hva slags krav som stilles til systemkonstuksjonen. Punkt 8 gir en oversikt over hva slags krav utviklerne har til dokumentasjonen som skal leveres med systemet. Punkt 9 forteller litt om kravene som blir satt til manuelle arbeidsrutiner. Punkt 10 er en oversikt over om utviklerne har utviklet applikasjonen i henhold til det som er spesifisert av brukerne. Punkt 11 er en oversikt over reviderte resultater fra forstudiet. 2

Systemkravdokument BADR 5 Innholdsfortegnelse 1 Hensikten med dokumentet... 2 2 Overordnet prosjektbeskrivelse / systembeskrivelse... 4 2.1 Kort overordnet beskrivelse av det nye systemet... 4 2.2 Organisatoriske og personellmessige konsekvenser... 5 3 Detaljerte krav til egenskaper... 6 3.1 Kvalitetsmodell... 7 4 Spesifikasjon av systemets funksjonelle egenskaper... 9 4.1 Funksjonell beskrivelse med bruk av Use Case modell... 9 4.1.1 Beskrivelse av Use Case (bruksmønster.)... 10 5 Databasebeskrivelse... 14 5.1 Dataelementbeskrivelsen... 14 5.2 Logisk Datamodell... 20 6 Beskrivelse av Grensesnittet... 26 6.1 Skjermbilder... 26 7 Krav til systemkonstruksjon... 31 8 Krav til dokumentasjon... 32 9 Krav til manuelle arbeidsrutiner... 33 10 Regler for godkjenningsprøve... 34 11 Reviderte resultater fra forstudiet... 35 11.1 Reviderte prosjektmål... 35 11.2 Reviderte rammebetingelser... 35 11.3 Revidert risikoanalyse... 35 11.4 Revidert fase og milepælsplan... 35 Referanser... 35 3

Systemkravdokument BADR 5 2 Overordnet prosjektbeskrivelse / systembeskrivelse Årsaken til at prosjektet ble opprettet var for å effektivisere og øke inntekten, samt senke sykefraværet i bedriften til AS CD-magasinets utsalgssted. Det nye systemet skal inneholde funksjoner til å effektivisere oppdateringer i databasen som inneholder informasjon om varer, kundebestilling, salg, inntekt, avanse, selgere og lagerbeholdning. Systemet vi utvikler skal effektivisere mange av de gamle rutinene samt, sørge for gode oversiktelige rapporter. Prosjektgruppen er de som hovedsakelig deltar i prosjektet som utviklere, samt veilederne og oppdragsgiver som setter begrensninger og gir feedback til prosjektgruppen for å komme med kritikk og hjelp videre til å forbedre produktet. 2.1 Kort overordnet beskrivelse av det nye systemet Det første man møter når man åpner programmet er å få opp en innlogging, etter vellykket innlogging, vil man få opp et nytt tomt vindu, med en meny der man velger hvilket vindu man vil åpne. Under den ene dropdownboksen vil man finne Salg, Søk, Vareadministrasjon, Varemottak, Logg Ut og Avslutt. I neste undermeny er det mulighet for å velge det vinduet som skal vises, hvis det feks er flere vinduer åpnet. I undermenyen som heter Admin er det en oversikt over Administrasjonen, som gir en oversikt over brukere, der det er mulighet for å endre og slette brukere. Under samme meny finnes det også oversikt over Rapporter og Innkjøp. Under neste tab finnes det en mulighet som automatisk ordner vinduene du har åpnet innad i programmet. Applikasjon: Kontrollpanel: flyt Database Salg Søk Plantegning Økonomi Alle undervinduer i applikasjonen har direkte oppkobling opp mot databasen Vareadministrasjon Figur 2.1 Innkjøp Administrasjon 4

Systemkravdokument BADR 5 2.2 Organisatoriske og personellmessige konsekvenser Salg vil gå fortere siden varer er lette og lete frem fra databasen i søk funksjonen som er implementert, samt oversikten over varer i butikken og på lager og muligheten til å legge til vare fra søkevinduet til salgsvinduet. Daglig leder og sekretær får muligheten til å se på rapportene som blir generert. Det vil bli lettere og legge til nye brukere siden all informasjon kan enkelt opprettes og lagres i databasen via programmet. De forskjellige brukerne av systemet vil få fire forskjellige adgangsnivåer, der 0 er kunde, 1 er selger, 2 er sekretær og 3 er daglig leder. Jo høyere adgangsnivå en bruker har jo flere nivåer av tilgang vil en bruker få. Det vil si at en kunde kun får tilgang til søk i varelager og plantegning av butikken, mens sekretæren får tilgang til alt bortsett fra det og kunne endre brukere. De forskjellige brukerne av systemet trenger forskjellige fagkunnskaper: Selgerne trenger kun allmenn datakunnskaper, bruk av systemet kan fort gjennomgås ved opplæring og det meste er selvforklarende. Sekretæren trenger allmenn datakunnskaper samt økonomisk innsikt. Om sekretæren mangler dette kan dette gjennomgås ved opplæring. Daglig leder trenger allmenn datakunnskaper, ha en lederrolle og god organisering innad i bedriften, med tanke på timelister og arbeidstider. Organisasjonen vil bli effektivisert både i salgsavdelingen, men også i administrasjonsavdelingen. Årsaken til dette er systemet som har funksjoner som automatiserer og gjør enkle handlinger mer oversiktlig og forståelig. 5

Systemkravdokument BADR 5 3 Detaljerte krav til egenskaper Reviderte detaljer ved krav til egenskaper. Endringer er markert med rødt. Sikkerhet, adgangskontroll o Adgang vil bli begrenset med passordbeskyttelse hvor hver ansatt stiller til ansvar med eget brukernavn og passord. o Kryptering av sensitiv informasjon, slik som personnummer til bedriftens ansatte, samt kryptering ved innlogging. Automatiske sikkerhetskopier o All kritisk data vil bli lagret i databasen, derav har databasen eget backup system som garanterer sikkerhetskopier av brukers data. Pålitelighet, feilfrekvens og konsekvenser ved feil o Så godt det lar seg gjøre vil brukerne få opp gode og beskrivende meldinger når systemet ikke forstår hva brukeren prøver å oppnå. o Der brukeren møter på kritiske løsninger for hvordan vårt utviklings verktøy behandler data, og man kan risikere at programmet henger seg opp (krasje), vil vi lage nye veier rundt disse bugsene, og programmet kommer da til og forklare brukeren hva som ikke går og for eksempel hvordan han/hun må skrive inn sine data. o Produktet vil ha meget stor pålitelighet, og man kan regne med en oppetid på oppimot 100 prosent. Den eneste faktoren som kan forårsake en liten nedetid er under implementering av oppdateringer av systemet. Dette vil ikke være noe problem, da dette kan gjøres utenom bedriftens åpningstid. Brukeregenskaper o Selger Valg av forskjellige salgstyper, kort, kontant og bestilling Søk ved hjelp av EAN nummer, varenummer og titler En lettere måte å oppdatere utsalgspris, og plassering i butikken/lager Selv oppdaterende oversikt av platebeholdningen Automatisere kundens forespørsler o Daglig leder/sekretær Registrere, endre og slette varer Oversikt over avansen Oversikt over innkjøpspris Oversikt over fortjeneste Mulighet for å endre og slette brukere/passord Ha et enkelt bestillingsvindu, der man registrerer varer som det må bestilles flere av fra leverandør Og et enkelt vindu for å endre beholdningen til en vare som allerede finnes i databasen, når varer kommer fra leverandøren, dette krever at varen allerede er registrert i databasen. 6

Systemkravdokument BADR 5 Kapasitet, datavolum, transaksjonsvolum o Programmet har stor kapasitet utover det systemet trenger, det er også et lite datavolum som skal lagres siden det hovedsakelig er korte tekst entry's som lagres og hentes. Transaksjonsvolumet blir derfor også lite, så det vil tappe lite av brukerens nettverk. Grensesnitt mot andre systemer, standarder for databeskrivelse o Systemet lages med Visual Basic.net i Visual Studio og vil derfor bare virke opp mot Windows systemer. Men tvilsomt at det vil fungere opp mot Windows 9x systemene uten.net. Personopplysningsloven For å kunne resgistrere personopplysninger, i databasen må bedriften søke om lov. Under personopplysninger legger vi navn, adresse, personnr, email, telefon og kontonummer. Alle personopplysninger som skal lagres og kan knyttes tilbake til en person, går inn under personopplysningsloven. Bedriften skal lagre denne informasjonen for å kunne blant annet betale lønn til de ansatte og holde styr på antall brukere i systemet. AS CD-Magasinet må derfor søke lov om å lagre informasjon om deres ansatte i en database. Se link til lovdata.no og wikipedia.no http://www.lovdata.no/all/hl-20000414-031.html http://no.wikipedia.org/wiki/personopplysningsloven 3.1 Kvalitetsmodell ISO 9126-1 Hvor lett er det å overføre programmet til andre plattformer? Er de ønskede funksjonene tilgjengelige i programmet? Hvor stabilt / pålitelig er programmet? Funksjo nalitet Flyttbar het Vedlike holdsve nnlig ISO 9126-1 Pålitelig het Brukerv ennlig Hvor lett er det å gjøre endringer i programmet? Figur 3.1 Effektivi tet Hvor effektivt er programmet? Er programmet lett å bruke? 7

Systemkravdokument BADR 5 Funksjonalitet Funksjonene prosjektgruppen har fastsatt for å imøtegå oppdragsgivers betingelser og krav. - Et sett av attributter avhenger av eksistensen av et sett av funksjoner og deres spesifiserte egenskaper. Funksjonene er de som tilfredsstiller fastsatte eller underforståtte behov.» Nøyaktighet» Samsvarende» Sikkerhet» Kapasitet» Fleksibilitet Pålitelighet Hva brukerne kan forvente av systemet med tanke på oppetid og robusthet. - Et sett med attributter som bæres av evnen til programvaren for å opprettholde sitt nivå av ytelse under uttalte forutsetninger for en angitt periode.» Stabilitet» Gjenoppretting» Feil toleranse Brukervennlighet Hvordan brukeren vil kunne læres opp i effektiv bruk av systemet. - Et sett med attributter som avhenger av den innsatsen som kreves for bruk, og på individuell vurdering av slik bruk, med et uttalt eller stilltiende sett av brukere.» Opplæringsvennlig» Selvforklarende Effektivitet Hvordan brukeren vil kunne jobbe sammen med systemet. - Et sett med attributter som avhenger av forholdet mellom nivået på ytelsen til programvaren og hvor mye ressurser som brukes under angitt vilkår.» Oppførsel over tid» Database samsvar» Lite ressurskrevende Vedlikeholdsvennlig- Hvor lett det er for en superbruker å utføre oppdateringer og eventuelle endringer i systemet. - Et sett med attributter som avhenger av den innsatsen som trengs for å lage spesifiserte modifikasjoner.» Stabilitet» Analyserbart» Endringsvennlighet» Testbart Flyttbarhet Hva systemet med lette endringer skal kunne takle av andre platformer. - Et sett med attributter som avhenger av evnen programvaren trenger for å overføres fra ett miljø til et annet.» Innføringsvennlighet» Erstatningsvennlighet» Tilpassningsvennlighet - Hentet fra Wikipedia.com 8

Systemkravdokument BADR 5 4 Spesifikasjon av systemets funksjonelle egenskaper Introduksjon til Use Case modellen med kommentarer. 4.1 Funksjonell beskrivelse med bruk av Use Case modell selger dagligleder «uses» * «uses» System Innlogging brukernavn og passord kan være feil * * feilbruker «extends» «uses» * * * sekretær kunde «uses» Inntekt «extends» returavvare ** * * * Salg retur av vare * * Kunde Sekretær * vareregister * «extends» «uses» * * * * * * * søk * Daglig leder * * * administrasjon «uses» * vareadministrasjon «uses» innkjøp Selger * brukerkontroll «uses» leggtilbruker * Rapport generering «uses» «uses» slettbruker endrebruker Figur 4.1

Systemkravdokument BADR 5 4.1.1 Beskrivelse av Use Case (bruksmønster.) Dette er en tekstlig forklaring på hver eneste Use Case i diagrammet, hvert punkt forklarer hva hver Use Case blir brukt til. Navn: Innlogging Mål: Å logge inn som selger, administrator eller sekretær, man kan også få tilgang til søk og vareplassering ved å aktivere kunde inngangsdøren. Aktører: Det er selger, administrator og sekretær Trigger: Når personen skal logge inn Pre Betingelse: Skrive inn riktig brukernavn og passord Post betingelser: Logge inn som forskjellige aktører, avhengig av type aktør vil en bruker få tilgang til færre eller flere rettigheter i programmet, hvis brukernavn/passord er feil, vil brukeren ikke klare å logge inn. Hovedløp: Aktøren får tilgang til systemet og kan bruke visse alternativer f.eks. salg eller vareregister Sideløp(variasjoner): Aktøren kommer ikke inn i systemet og blir bedt om å taste inn korrekt brukernavn og passord. Navn: dagligleder Mål: Logge inn som daglig leder Aktører: Daglig Leder Trigger: Daglig leder logger inn og får tilgang til alle vinduer Pre Betingelse: Riktig brukernavn og passord kreves for å logge inn som daglig leder Post betingelser: Daglig leder logger inn og får tilgang til administrasjons rettighetene, dvs. endre, opprette og slette brukere, samt diverse statistikker over salg og økonomi. Dette gjelder kun daglig leder. Hovedløp: Aktøren kommer inn på systemet og tar i bruk administrasjons delen av programmet og f.eks. sletter en selger fra brukerlisten som nettopp har sagt opp jobben. Sideløp(variasjoner): Hvis daglig leder logger inn på systemet så får daglig leder full tilgang til alle aspekter Relatert informasjon: Daglig leder og sekretær er den eneste som får tilgang til flere aspekter av programmet enn det selgeren får. Dette er for å forhindre misbruk av systemet. Navn: Salg Mål: Kunne registrere et salg av en plate, slik at det trekkes fra et antall fra varelageret og sørge for at prisen som blir betalt er riktig. Aktører: Selger Trigger: Kunden initierer et salg, der selger leser inn strekkoden og oppgir prisen til kunden, og sørger for at pengene blir lagt i kassen eller at kortet blir trukket. Pre Betingelse: Kunden kommer med ønsket vare, varen blir registrert av selger og penger blir utvekslet mellom de to, enten via kort eller kontant. Post betingelser: Selger registrer handelen og kunden får ønsket vare. Deretter blir det automatisk fjernet ønsket antall varer fra varelageret. Hovedløp: Kunden får varen og selgeren får penger, i form av kort eller kontant, med den forutsetning av varen er på lager. Sideløp(variasjoner): Kunden har ikke nok penger eller at varen er utsolgt, eller varen ikke lenger blir lagerført. Relatert informasjon: Hvis varen ikke er i lageret eller det er utsolgt vil selger registrere dette eventuelt bestille nytt/mer fra leverandør, hvis varens status fortsatt er satt til lagervare. Navn: Inntekt Mål: Vise en statistikk over solgte varer 10

Systemkravdokument BADR 5 Aktører: sekretær og daglig leder Trigger: Varer er blitt solgt og aktørene ønsker en oversikt over antall solgte eller inntekten innenfor en periode, f.eks. desember måneden. Pre Betingelse: Varer må ha blitt solgt for at systemet skal kunne brukes. Post betingelser: Aktøren kan skrive ut en kopi slik at det kan lagres som dokumentasjon over antall solgte/inntekt Hovedløp: Aktøren får en oversikt over inntekten slik at statistikken kan brukes for å bestille flere varer. Sideløp(variasjoner): Dårlig salg av plater og/ eller lite i inntekter Relatert informasjon: Svært behjelpelig oversikt over hva som har blitt solgt og antall solgte, slik at det blir lettere å bestille flere varer fra leverandør. Navn: returavvare Mål: Kunden ønsker å returnere en vare Aktører: kunde og selger Trigger: Kunden ønsker og bytte vare Pre Betingelse: Kunden trenger kvittering og et produkt med ubrutt forseiling, hvis ikke kan ikke kunden returnere varen siden varen kan ha blitt misbrukt. Post betingelser: Selger gir pengene tilbake til kunden, dvs. siste utsalgspris og varen returneres til selger og registreres igjen i butikkens beholdning. Hovedløp: Selger mottar varen og leser den inn i systemet ved hjelp av en strekkode. Deretter får man opp informasjon av varen og kunden får pengene det kostet og kjøpe varen ved siste utsalgspris. Sideløp: Brutt forsegling eller mangel på kvittering fører til at kunden ikke kan returnere varen. Relatert informasjon: Krav til retur av vare er ubrutt forsegling eventuelt kvittering. Navn: administrasjon Mål: Lar dagligleder og sekretær få en oversikt over diverse undergrupper som hjelper til med en oversikt over økonomi, selgere og innkjøp. Aktører: Sekretær og daglig leder Trigger: Sekretær eller daglig leder logger inn for å få tilgang til områdene. Pre Betingelse: Krever riktig brukernavn og passord Post betingelser: Aktøren får tilgang til områder som er lukket for selgerne Hovedløp: Personen logger inn og får muligheten til og endre brukere, få en oversikt, bestille nye varer fra leverandør og får en oversikt over økonomien. Sideløp: Relatert informasjon: Sekretær og daglig leder er de eneste med tilgang til denne funksjonen. Navn: leggtilbruker Mål: Å legge til en ny bruker som kan logge på systemet Aktører: Daglig leder og sekretær Trigger: En ny ansatt har startet i bedriften og trenger tilgang til systemet for å begynne å arbeidet. Pre Betingelse: Krever en ny ansatt Post betingelser: Brukeren blir opprettet av daglig leder, og er klar til bruk like etter opprettelse. Hovedløp: Sekretær eller daglig leder oppretter og selger er klar til opplæring av systemet etter kort tid. Sideløp(variasjoner): Det blir gjort feil i opprettelsen av brukeren, som kan føre til at det tar lengre tid enn normalt. Relatert informasjon: Ny brukere kan til dags dato ikke få endret sin adgangstillatelse, slik at en selger med mye tillit kan få tildelt flere alternativer f.eks. Tilgang til delen kalt innkjøp. 11

Systemkravdokument BADR 5 Navn:slettBruker Mål: slette en bruker fra systemet. Aktører: Daglig leder, sekretær og selger Trigger: En bruker slutter i bedriften og hans brukernavn/ passord må dermed fjernes fra systemet. Pre Betingelse: En selger må slutte eller sparkes Post betingelser: Det vil dermed være en mindre selger i bedriften. Hovedløp: Det finnes en mindre selger i bedriften etter at daglig leder eller sekretær har fjernet personen fra systemet. Sideløp(variasjoner): Feil bruker fjernes. Relatert informasjon: Bruker kan legges til igjen, men da må all informasjon legges inn på nytt. Navn: endrebruker Mål: Endre en bruker i systemet Aktører: Daglig leder, sekretær og selger Trigger: En bruker ønsker f.eks. å endre passord Pre Betingelse: brukeren må være registrert i systemet og ønsker endringen. Post betingelser: Passordet er endret og det nye passordet brukes for å logge på systemet. Kan blitt skrevet inn feil både av selger og av aktøren som endrer passordet. Hovedløp: Passordet endres og er klar til bruk, uten at det er skrevet inn feil fra noen av aktørenes side. Sideløp(variasjoner): Passordet skrives inn feil fra daglig leder eller sekretærs side, selger kan derfor ikke logge på systemet. Relatert informasjon: Brukes til og endre informasjon om selger, f.eks. telefon adresse osv. Navn: vareregister Mål: Få en oversikt over vareregisteret. Aktører: Selger, daglig leder eller sekretær Trigger: Aktørene ønsker en oversikt over vareregisteret Pre Betingelse: Aktørene vil lete frem et bestemt produkt for å sjekke varelagerbeholdning. Post betingelser: Ønsket vare blir funnet fram fra registeret og kan endres eller skrive ut eventuelle statistikker. Hovedløp: Aktøren får en oversikt over all informasjon om ønsket vare. Sideløp(variasjoner): Hvis aktøren skriver feil EAN nummer eller navn på vare vil aktøren enten få frem en annen vare eller ikke finne noe som helst. Relatert informasjon: vareregister er koblet opp mot søk, slik at man enkelt kan søke i vareregisteret. Navn: søk Mål: Hensikten er å finne varer i registeret ved hjelp av en enkelt søk. Aktører: Alle aktørene kan initiere et søk, men hovedsakelig sekretær, daglig leder selger og kunde. Trigger: En kunde ønsker å vite detaljert informasjon om en vare, eller daglig leder ønsker å finne ut om varebeholdningen til en vare. Pre Betingelse: Varen er på lager, eller er blitt bestilt fra leverandør. ERGO den ligger lagret i bedriftens datasystem. Post betingelser: Den bestemte varen er blitt funnet. Hovedløp: Informasjonen som letes opp kan bli formidlet videre til kunden gjennom selger. Eller daglig leder har fått den informasjonen han/hun trenger for å kunne bruke informasjonen videre. Sideløp(variasjoner): Varen er ikke på lager eller i registeret, og det ikke blitt opprettet noen informasjon om varen slik at det ikke finnes informasjon om videre bestillinger, eventuelt ikke ta inn mere av varen for å hindre en for stor varebeholdning Relatert informasjon: Hvis daglig leder ser at det ikke er blitt solgt mye av varen, velger daglig leder og ikke bestille mer fra leverandør for å unngå å ha et for stort varelager som man ikke får solgt videre til kundene. 12

Systemkravdokument BADR 5 Navn: innkjøp Mål: Hensikten er å få en oversikt over hva som er blitt kjøpt inn, hva som trengs og kjøpes inn og hva som er blitt solgt. Aktører: daglig leder, sekretær eller selger Trigger: Selger melder om at produktet er utsolgt eller at det er lite igjen i varebeholdning og daglig leder/sekretær leser ut ifra statistikken at det er mangel på varen Pre Betingelse: Mangel av varen i lageret eller lav varebeholdning Post betingelser: Vare blir bestilt fra leverandør og ved neste varelevring blir produktet levert hos butikken. Hovedløp: Varen med lav lagerbeholdning blir bestilt fra leverandør med uti fra en beregning gjort på kjøpstall fra tidligere kvartal. Sideløp(variasjoner): Beskriv spesialtilfelle (unntak fra normal hendelsesflyt) separat. Format: if betingelse ="true" then konsekvens Relatert informasjon: for eksempel ikke-funksjonelle krav ("svartid må være bedre enn 10 sekunder") Navn: Plantegning Mål: Få en oversikt over hyllene ute i butikken Aktører: Selger, daglig leder og sekretær Trigger: Selger vil finne en plate som er i butikken Pre Betingelse: Platen finnes i butikken Post betingelser: Platen vises i butikken eller så vises den ikke, selger finner platen eller så finner han den ikke. Hovedløp: Selger søker etter platen og finner den i en hylle ute i butikken Sideløp(variasjoner): Platen er blitt flyttet av en kunde, eller platen er blitt flyttet av en selger uten at platen er blitt registrert endret. Navn: Rapporter Mål: Få en oversikt over antall solgte varer, inntekter og kostnader. Aktører: Sekretær og daglig leder Trigger: Daglig leder ønsker å ta en titt på hvor mye bedriften har tjent Pre Betingelse: Bedriften har solgt plater. Post betingelser: Aktøren får en oversikt over antall solgte av en eller flere varer, tillegg til overskuddet, inntekter - kostnader, hvis bedriften ar solgt noen varer. Hovedløp: Aktøren får en oversikt som viser inntekter og kostnader, samt hva overskuddet er i tillegg til egenkapital og hva bedriften skylder leverandører. Sideløp(variasjoner): Aktøren bestiller varer fra en ny leverandør som ikke er inne i systemet. Relatert informasjon: Det kreves at aktøren bestiller varer fra leverandører som er registrert i systemet. Navn: vareadministrasjon Mål: Administrere vareregisteret Aktører: Daglig leder og sekretær Trigger: Sekretær og gjøre endringer på en vare, slette, endre legge til. Pre Betingelse: Varen må være registret. Post betingelser: Varen er blitt endret, feil i vareregistreringen kan være mulig Hovedløp: Varen blir endret og blir oppdatert fortløpende, og ny salgspris er klar. Sideløp(variasjoner): Skrivefeil kan føre til at produktet blir dyrere enn ment. Relatert informasjon: Kun daglig leder og sekretær ar tilgang til denne funksjonen i programmet. 13

Systemkravdokument BADR 5 5 Databasebeskrivelse 5.1 Dataelementbeskrivelsen KundeID Fornavn Navn Betydning Befinner seg i entitet Kilde Format Sikkerhet Etternavn Epost Tlf Primærnøkkel for entiteten Kunde. Unikt nummer for hver regitrerte kunde Lagrer den aktuelle kundens fornavn Lagrer den aktuelle kundens fornavn Lagrer den aktuelle kundens fornavn Lagrer den aktuelle kundens telefon nummer Kunde Automatisk generert av MySQL Int(11), auto_increment ingen Kunde Den aktuelle kunde varchar(30) ingen Kunde Den aktuelle kunde varchar(30) ingen Kunde Den aktuelle kunde varchar(30) ingen Kunde Den aktuelle kunde Integer(8) ingen AnsattID Primærnøkkel for entiteten Ansatt. Unikt nummer for hver enkelt ansatt Ansatt Automatisk generert av MySQL int(11), auto_increment Ingen Personnr Etternavn Fornavn Er relevant for lønnsutbetalinger og skatt hos den ansatte Oversikt over de ansattes etternavn Oversikt over de ansattes fornavn Ansatt Hentes inn fra de ansatte varchar(11) MD5 Ansatt Hentes inn fra de ansatte varchar(30) ingen Ansatt Hentes inn fra de ansatte varchar(30) ingen

Systemkravdokument BADR 5 Epost Tlf Adresse Post_nr Kontonr Brukernavn Oversikt over de ansattes epost Oversikt over de ansattes personlige telefonnummer. Oversikt over de ansattes hjemme adresse Oversikt over de ansattes postnummer knyttet til deres hjemmeadresse Oversikt over de ansattes kontonummer. Relevant ved utbetaling av lønn Brukernavnet brukes ved pålogging av programmet som blir levert Ansatt Hentes inn fra de ansatte varchar(30) ingen Ansatt Hentes inn fra de ansatte int(8) ingen Ansatt Hentes inn fra de ansatte varchar(30) ingen Ansatt Hentes inn fra de ansatte. Fremmednøkkel fra entiteten Post char(4) ingen Ansatt Hentes inn fra de ansatte varchar(11 ingen Ansatt Settes av administrator. Fremmednøkkel fra entiteten Bruker varchar(30) ingen BestillingsID Primærnøkkel for entiteten Bestilling. Uniktnummer som alle bestillinger får. Betydning for bestillingsprosessen Bestilling Automatisk generert av MySQL int(11), auto_increment ingen LeverandOrID Unikt leverandørnummer som knyttes opp i mot en bestilling Bestilling Automatisk generert av MySQL. Fremmednøkkel fra entiteten LeverandOr Primærnøkkel for entiteten Brukernavn Bruker Settes av administrator. ingen Bruker. Brukes ved pålogging varchar(30) Passord Brukes ved pålogging Bruker Settes av administrator. varchar(30) ingen Admin Angir tilgangsnivå til bruker i programmet. int(11) ingen Bruker Settes av adminstrator. char(1) ingen 15

Systemkravdokument BADR 5 Varenr Primærnøkkel og fremmednøkkel. Knytter cd spesifikk informasjon opp imot en vare i entiteten Produkt. Cd Automatisk generert av MySQL int(11) ingen Antall_spor Har verdien som viser antall spor det er på en cd Cd Cd platen eller eventuelt leverandør int(11) ingen Artist Navn på artisten til en cd. Viktig om man søker på artistnavn Cd Cd platen eller eventuelt leverandør varchar(30) ingen Varenr Primærnøkkel og fremmednøkkel. Knytter dvd og blueray spesifikk informasjon opp imot en vare i entiteten Produkt DVD_BlueRay Automatisk generert av MySQL int(11) ingen Aldersgrense Bildeformat Format LeverandOrID Navn Kontonr Post_nr Essentiell for å hindre salg til mindreårige Angir hvilken format det er på bildet til filmen Primærnøkkel for entiteten Format Primærnøkkel for entiteten LeverandOrID Navnet til den aktuelle leverandøren Kontonummeret til den aktuelle leverandøren Postnummeret til den aktuelle leverandøren DVD_BlueRay DVD_BlueRay Leverandør eller dvd/blueray platen selv Leverandør eller dvd/blueray platen selv int(11) varchar(7) ingen ingen Format Leverandør varchar(30) ingen LeverandOrID Automatisk generert av MySQL Int(11), auto_increment ingen LeverandOrID Leverandøren varchar(30) ingen LeverandOrID Leverandøren int(11) ingen LeverandOrID Leverandøren char(4) ingen 16

Systemkravdokument BADR 5 Adresse LokLagID LokButID Post_nr Poststed Adressen til den aktuelle leverandøren Angir lokasjonen på en vare i lageret. 1etg eller 2etg Primærnøkkel for entiteten LokasjonIButikk Primærnøkkel for entiteten Post Entitetstype for alle poststeder i Norge LeverandOrID Leverandøren varchar(30) ingen LokasjonPALager LokasjonIButikk Post Post Bygget hos AS CD- Magasinet. Etasje og reoler hos AS CD- Magasinet Portalservice.no med modifikasjoner fra BADR5 Portalservice.no med modifikasjoner fra BADR5 varchar(30) char(4) char(4) varchar(30) ingen ingen ingen Varenr Primærnøkkel for entiteten Produkt. Unik identifikator et produkt. Produkt Automatisk generert av MySQL int(11), auto_increment ingen EANKode Format Unik identifikator for et produkt Avgjør hvilken type vare det er. CD, DVD eller BlueRay Produkt Leverandøren eller selve varen varchar(13) ingen Produkt Leverandøren varchar(30) ingen Tittel Navnet på albumet eller filmen Produkt Leverandøren varchar(70) ingen Produsent Hvem har produsert produktet Produkt Leverandøren varchar(30) ingen UtgivelsesAr År for utgivelse av produktet Produkt Leverandøren char(4) ingen Bilde Url eller relativ bane til bilde av cover til cd, dvd eller blueray Produkt DVD og BlueRay: imdb.com CD: amazon.com varchar(250) ingen InnkjOpspris Prisen det koster å kjøpe inn varen Produkt Leverandøren int(11) ingen Avanse Hvor mye mer en innkjøpspris man ønsker å selge varen for i prosent Produkt Innkjøper eller eventuelt økonomisk ansvarlig int(11) ingen 17

Systemkravdokument BADR 5 Beholdning LeverandOrID LokButID LokLagID Sjanger_navn Varenr Har verdien for den aktuelle beholdningen på varen Knytter produktet til leverandøren av produktet Beskriver lokasjonen i butikken til et produkt. Beskriver i hvilken etasje man finner varen Beskriver hvilken sjanger et produkt tilhører Primærnøkkel og fremmednøkkel fra entiteten Produkt. Knytter varernummer til en bestilling Produkt Produkt Produkt Settes ved mottak av vare og automatisk ved salg Automatisk generert av MySQL Hardkodet inn ut i fra plantegning int(11) int(11) varchar(30) ingen ingen ingen Produkt Antall etasjer varchar(30) ingen Produkt Leverandør eller produktets embalasje varchar(30) ingen ProduktBestilling Innkjøper int(11) ingen BestillingsID Primærnøkkel og fremmednøkkel fra entiteten Bestilling. Knytter en bestilling til et produkt ProduktBestilling Entiteten Bestilling, blir automatisk generert for hvert enkelt salg av MySQL int(11) ingen Antall SalgsID KundeID Beskriver antallet av en vare i en bestilling Primærnøkkel for entiteten Salg. Unik identifikator for hvert enkelt salg. Fremmednøkkel fra entiteten Kunde. Knytter kunde opp i mot null eller flere salg ProduktBestilling Innkjøper int(11) ingen Salg Salg Automatisk generert av MySQL Automatisk generert av MySQL int(11), auto_increment int(11) ingen ingen 18

Systemkravdokument BADR 5 AnsattID Fremmednøkkel fra entiteten Ansatt. Knytter ansatt opp i mot null eller flere salg Salg Automatisk generert av MySQL int(11) ingen TotalPris Ar Dato Klokkeslett Varenr SalgsID Antall Sjanger_navn Den totaleprisen kunden måtte betale ved det spesifikke salget Et årstall som blir knyttet opp i mot et salg En dato som blir knyttet opp i mot et salg Et klokkeslett som blir knyttet opp i mot et salg Primærnøkkel og fremmednøkkel fra entiteten Produkt. Knytter varernummer til et salg Fremmednøkkel fra entiteten Salg. Knytter salget opp i mot i mot et produkt Beskriver antallet av en vare i et Primærnøkkel for entiteten Sjanger. Innholder alle sjangerene man kan knytte til et produkt Salg Automatisk beregnet av programmet. decimal(5,2) ingen Salg Årstall for salget int(11) ingen Salg Datoen for salget varchar(5) ingen Salg Klokketslettet for salget varchar(5) ingen SalgProdukt Selger int(11) ingen SalgProdukt Automatisk generert av MySQL int(11) ingen SalgProdukt Selger int(11) ingen Sjanger Leverandør eller emalasje fra produkt varchar(30) ingen 19

Systemkravdokument BADR 5 5.2 Logisk Datamodell

Systemkravdokument BADR 5 Entitetstypeliste Format Format Id Ndv VARCHAR(30) Produkt Varenr Id Ndv INTEGER EANKode INTEGER *Format Ndv VARCHAR(30) Tittel Produsent UtgivelsesAr Bilde InnkjOpspris Avanse Beholdning VARCHAR(30) VARCHAR(30) CHAR(4) VARCHAR(250) DECIMAL(5,2) INTEGER INTEGER *LeverandOrID Ndv INTEGER *LokButID *LokLagID INTEGER INTEGER Ansatt *Sjanger_navn Ndv VARCHAR(30) AnsattID Id Ndv INTEGER Etternavn Fornavn Email Telefon Addresse VARCHAR(30) VARCHAR(30) VARCHAR(30) INTEGER VARCHAR(30) *Post_nr Ndv CHAR(4) *Brukernavn Ndv VARCHAR(30) BedriftInfo 21

Systemkravdokument BADR 5 Navn Id Ndv VARCHAR(30) Logo Tlf Adresse VARCHAR(250) INTEGER VARCHAR(30) *Post_nr Ndv CHAR(4) Salg SalgsID Id Ndv INTEGER *KundeID INTEGER *AnsattID Ndv INTEGER TotalPris VARCHAR(5) Ar CHAR (4) Dato Klokkeslett VARCHAR(5) VARCHAR(5) Kunde KundeID Id Ndv INTEGER Navn Email Tlf VARCHAR(30) VARCHAR(30) INTEGER *Post_nr Ndv CHAR(4) Sjanger Sjanger_navn Id Ndv VARCHAR(30) Cd *Varenr Id Ndv INTEGER Antall_spor Artist INTEGER VARCHAR(30) DVD_BlueRay 22

Systemkravdokument BADR 5 *Varenr Id Ndv INTEGER Aldersgrense Bildeformat INTEGER VARCHAR(5) Post Post_nr Id Ndv CHAR(4) Poststed Kommunenummer Kommune Fylkenummer Fylke VARCHAR(30) INTEGER VARCHAR(30) INTEGER VARCHAR(30) SalgProdukt *Varenr Id Ndv INTEGER *SalgsID Id Ndv INTEGER Antall Spilletid INTEGER INTEGER 23

Systemkravdokument BADR 5 LeverandOr LeverandOrID Id Ndv INTEGER Navn Kontonr VARCHAR(30) INTEGER *Post_nr Ndv CHAR(4) Adresse VARCHAR(30) Bestilling BestillingsID Id Ndv INTEGER *LeverandOrID Ndv INTEGER ProduktBestilling *Varenr Id Ndv INTEGER *BestillingsID Id Ndv INTEGER Antall INTEGER LokasjonIButikk LokButID Id Ndv INTEGER LokasjonPALager LokLagID Id Ndv INTEGER Bruker Brukernavn Id Ndv VARCHAR(30) Passord VARCHAR(30) 24

Systemkravdokument BADR 5 Relasjonsskjema: BEDRIFTSINFO (Navn, Logo, Tlf, Adresse, Post_nr*) POST (Post_nr, Poststed, Kommunenummer, Kommune, Fylkesnummer, Fylke) ANSATT (AnsattID, Etternavn, Fornavn, Email, Telefon, Adresse, Post_nr*, Brukernavn*) BRUKER (Brukernavn, Passord) LEVERANDØR (LeverandOrID, Navn, Kontonr, Adresse, Post_nr*) KUNDE (KundeID, Navn, Email, Tlf, Post_nr*) SALG (SalgID, Total_pris, Ar, Dato, Klokkeslett, KundeID*, AnsattID*) PRODUKT (Varenr, EANKode, Tittel, Produsent, UtgivelsesAr, Bilde, InnkjOpspris, Avanse, Beholdning, Nasjonalitet, Format*, LeverandOrID*, LokButID*, LokLagID*, Sjanger_navn*) BESTILLING (BestillingsID, Leverand0rID*) PRODUKT_BESTILLING (Varenr*, BestillingsID*, Antall) SALG_PRODUKT (Varenr*, SalgsID*, Antall) FORMAT (Format) SJANGER (Sjanger_navn) CD (Varenr*, Antall_spor, Artist) DVD_BlueRay (Varenr*, Aldersgrense, Bildeformat) LOKASJONIBUTIKK (LokButID) LOKASJONPALAGER (LokLagID) Vi i prosjektgruppen har argumentert frem og tilbake om tabellen POST burde normaliseres bedre enn det den er nå (Kommune og Fylke er ikke i samsvar med normaliseringsreglene da dette vil oppstå mange gjentagende verdier). Og har, på grunn av store mengder data i denne tabellen, kommet fram til å ikke normalisere den videre. Dette er da fordi funksjoner som søk ville tatt ugunstig mye lengre tid. Samtidig som man ikke møter på noen store farer ved å la den stå slik den er. Resten av databasen er normalisert etter BCNF, og etter definisjonen på BCNF er den da også på 3NF slik som som forespurt. 25

Systemkravdokument BADR 5 6 Beskrivelse av Grensesnittet Her vil vi vise fra GUI og fortelle litt om hvordan de forskjellige vinduene fungerer. Bilder er hentet fra MusicSurver v 1.0 6.1 Skjermbilder Prototypen er laget med hovedvekt på at man ikke skal ha så mange vinduer oppe. Fargevalget er satt til systemstandard i Windows, men kan endres etter kundens ønske. Det er brukt parentform og childform får å få til dette. Dette gir brukere fordelen med at man har alle vinduer i et hovedvindu. Dette gir muligheter for å jobbe med flere prosesser samtidlig. Prototypen gir også muligheter til å åpne flere vinduer av det samme type med tanke på flere søk eller separate salg på en gang. Prototypen ligger tilgjengelig testing her: http://tihlde.org/~sebastis/prosjekt/utvikling/prototype.rar Det er viktig å understrekke at dette er en prototype og store endringer kan fortsatt bli gjort på programmet etter kundens ønsker og prosjektgruppens vurderinger. Bilder fra prototypen og kommentarer til de: Forklaring 6.1 Login vinduet er første vindu man møter ved oppstart. Dette vinduet krever to input før man kommer videre. Disse inputene er brukernavn og passord. I prototypen kan brukernavn "q" og passord "q" brukes. Avhenging av hvilken bruker man logger inn med så vil tilgangen være forskjellig. Trykk på login knappen for å verifisere ditt brukernavn og passord. Figur 6.1 Login Forklaring 6.2 Detter for å illustrere hvordan loadingen på programmet kunne ha foregått, hvis programmet hadde vært mer omfattende Figur 6.2 Load 26

Systemkravdokument BADR 5 Forklaring 6.3 Dette er hovedvinduet i programmet. I dette vinduet vil alle andre vinduer man åpner ligge. Ved oppstart vil salgsvinduet som standard bli åpnet i hovedvinduet. Menyen på toppen brukes til å åpne, administrere og ordne vinduer i hovedvinduet. Figur 6.3 Kontrollpanelet Forklaring 6.4 Dette er vinduet som brukes ved salg. Ved salg har man mulighet til å velge å registrere varer ved hjelp av varenummer eller EAN. EAN er default ved oppstart slik at man kan lese inn strekkoder. Betallingsformer som aksepteres er kort, kontant eller kundebestlling om det er ordre over tlf eller e-post. Ved registrering av salg så vil varene bli lagt i listboksen. Det er også mulig å fjerne varer fra listboksen ved å trykke angre siste eller markere linjen og høyreklikke. Da vil en meny komme opp. Når salget er sluttført kan man trykke på kvitterings knappen for kvittering om kunden ønsker det. Figur 6.4 Salg 27

Systemkravdokument BADR 5 Forklaring 6.5 Søke vinduet er delt inn i tre deler, en for søk etter vare, en for informasjon av den valgte vare og en for vareadministrasjon som man ønsker å endre på informasjonen som ligger i databasen på en spesifikk vare. Det gis valgmuligheter for å søke etter CD, DVD og BlueRay. Alle søk havner i en listeboks som gjør det lett å velge den riktige varen. Når man har valgt varen man vil ha vil informasjon komme opp til høyre for søket. All informasjon som ligger på varen i databasen vil komme opp her. Figur 6.5 Søk Forklaring 6.6 Varemottak der man endrer beholdningen i butikken, dette krever at varen allerede er registrert i databasen. Figur 6.6 Varemottak 28

Systemkravdokument BADR 5 Forklaring 6.7 Dette vinduet vil kun daglig leder ha tilgang til. Her kan man kunne endre passordet til brukere, legge til brukere og slette brukere. Figur 6.7 Administrasjon Forklaring 6.8 Dette vinduet vil kun daglig leder og sekretær ha tilgang til. Økonomi vinduet vil man kunne generere diverse rapporter ut i fra hva man velger i dropdown listen. Kan skrives til fil eller til skriver. Figur 6.8 Rapporter 29

Systemkravdokument BADR 5 Forklaring 6.9 Dette vinduet vil kun daglig leder ha tilgang til. Alle bestillinger av varer registreres her. Her kan man velge å legge til varer til bestillinger ved hjelp av varenummer eller EAN. Bestillinger kan skrives til skjerm, fil og skriver. Man kan også angre enkelt linjer ved hjelp av og høyreklikke ønsket vare i listboksen. Figur 6.9 Innkjøp Forklaring 6.10 Dette vinduet vil alle bortsett fra kunden ha tilgang til. I dette vinduet kan man endre attributtene til varene som ligger i databasen. Vareadministrasjon gir også mulighet til å legge til ny vare og slette varer. Ved innhenting av vare informasjon så kan man benytte varenummer eller EAN. Alle endringer man utfører kan lagres og endringen vil overskrive den informasjonen som lå i databasen på den varen man jobbet med. Figur 6.10 VareAdministrasjon 30

Systemkravdokument BADR 5 Forklaring 6.11 Dette er et oversiktsbilde som viser alle de forskjellige vinduene åpne og ordnet ved hjelp av cascade. Vinduer kan også ordnes vertikalt og horisontalt. Figur 6.11 Oversiktsbilde 31

Systemkravdokument BADR 5 7 Krav til systemkonstruksjon Alt eksisterende utstyr som kan brukes, kan benyttes til å kjøre programmet. Vi som utviklere har fått i oppgave å lage en applikasjon som skal brukes ved hjelp av salg, lager osv. Dette krever flere maskiner med datatilgang, Vi som utviklere ser for oss 6 maskiner, tre til salg, en maskin som skal stå ute i butikken der kunden kan søke i varebeholdningen, en maskin til daglig leder og en maskin til sekretæren. Deretter kreves det nettilgang på alle maskiner for å få tilgang til databasen, samt tre eller fire strekkodelesere. Service av disse maskinene bør gjennomføres før implementering av systemet, deretter blir servicen utført jevnelig av utviklerne etter implementeringen. To maskiner helst bærbare skal stå på kontoret, en stasjonær maskin skal stå plassert ute i butikken og 3 maskiner skal stå plassert i kassen. Basisprogrammene skal være MuSu (Music Surfer), som er programmet vi har utviklet, valgfritt OS, helst Vista eller nyere, valgfri nettleser (ikke Internett Explorer) som har phpmyadmin som standard hjemmeside for å administrere databasen på et høyere nivå enn med MuSu. I tillegg trengs det et avspillingsprogram som kan spille av musikk i lokalet, f.eks. Itunes, Spotify, Winamp og Windows Media Player. I tillegg trengs det to ekstra applikasjoner for å kunne utnytte de fulle mulighetene av MuSu. 8 Krav til dokumentasjon Følgende dokumentasjon vil bli levert sammen med systemet samme dag som implementeringen starter. Brukerveiledning Driftsdokumentasjon - Hentet fra Mal Systemkravdokument Forvaltningsdokumentasjon 32

Systemkravdokument BADR 5 9 Krav til manuelle arbeidsrutiner Det er viktig at bruker skriver inn data i samsvar med brukermanualen slik at man unngår at uriktige data. Det er også viktig og skrive inn verdiene i riktig format slik det er definert i brukermanalen. Når det kommer til oppbevaring av varer, så må disse lokasjonene alltid oppdateres i programmet når en vare blir flyttet på. Dette gjelder også når det kommer til lager lokasjonene. Pass på og aldri logge på en arbeidsstasjon ment for kundene med et adgangsnivå høyere enn 0. Dette er fordi det er fort gjort å glemme å logge av. Dermed vil kundene kunne gå inn og gjøre kritiske endringer i dagens dataflyt. Dette fordi backup utføres på nattestid. Systemet på lageret er manuelt, systemet henviser kun til hvilken etasje varen er lagret. Det er viktig og alltid logge av systemet (Gjelder ikke Kunde brukere) når man forlater arbeidsstasjonen. Dette er for å ivareta sikkerheten til programmet 33

Systemkravdokument BADR 5 10 Regler for godkjenningsprøve Følgende krav må innfries ved godkjenningstesten: 1. Strategi: Testen kjøres hos AS CD-Magasinet på deres datamaskiner. Dato: 27-29 november. Klokken: Fredag 18:00-22:00 Lørdag 09:00-18:00 Søndag 09:00-18:00 (evalueringsmøte fra klokken 12.00) 2. Data Gjennomfører det samme salgene og innkjøpene fra de siste 14 dagene slik at man får testet aktuell data. Eventuelle feil blir rettet fortløpende etter hvert som de blir rapportert inn. BADR5 stiller med tre personer hos AS CD- Magasinet og har to som står standby for feilretting. Oppdragsgiver skaffer testdata i form av varedata, salgsdata og innkjøpsdata. Testdatabasen blir satt opp av BADR5 den 26. november og testes i forkant for full funksjonalitet. 3. Deltagere: Daglig leder: Sørger for at alle testdata er tilgjengelig for BADR5, holder overordnet tilsyn av testen sammen med prosjektleder. Rapporterer inn eventuelle feil til standbygruppen for feiloppretting. Innkjøpsansvarlig: Simulerer bestillingsprosedyren sammen med en representant fra BADR5, og rapporterer eventuelle feil til daglig leder. Selgere: Simulerer salg sammen med en representant fra BADR5, og rapporterer eventuelle feil til daglig leder. 4. Overordnede godkjenningskritterier: Det skal være ingen kritiske stopp av systemet i løpet av simuleringen. Responstiden fra databasen skal ikke overstige 2 sekund i 95% av tilfellene. 98 % av alle data skal ha blitt registrert korrekt i databasen. Testen skal være ferdig innen de gitte tidsrammer. 5. Ved en eventuell ikke godkjent test: Møte med begge parter hvor man går gjennom videre drift. Går igjennom hva som gjorde at testen ikke ble vellykket og prosjektgruppen presenterer en tidsramme for å få fjernet feilene. Prosjektgruppen vil også gi en overslag på eventuelle tileggskostnader som faller utenom den inngåtte kontrakten med AS CD-Magasinet. 34

Systemkravdokument BADR 5 11 Reviderte resultater fra forstudiet Her skriver vi ned hvilke endringer vi har måtte utføre på foregående arbeid som har med prosjektet og gjøre. 11.1 Reviderte prosjektmål Ingen reviderte prosjektmål. 11.2 Reviderte rammebetingelser Ingen reviderte rammebetingelser 11.3 Revidert risikoanalyse Ingen endringer på dette tidspunktet. Vi har derimot erfart at punkt 2 angående sykdoms og fravær stemmer. 11.4 Revidert fase og milepælsplan Fase og milepælsplan er fastsatte datorer og har derfor ikke fleksibilitet til å kunne bli forandret. Ergo. Ingen endring. Referanser Mal brukerkravdokument https://www.itslearning.com/main.aspx?courseid=7822 Leksjoner i faget PRS https://www.itslearning.com//folder/process_folder.aspx?folderid=754112 Wikipedia http://en.wikipedia.org/wiki/iso_9126#quality_model Personvernloven http://www.lovdata.no/all/hl-20000414-031.html http://no.wikipedia.org/wiki/personopplysningsloven 35

Systemkravdokument 2009 BADR 5 Vedlegg 4 CD Cd inneholder: Fullt script, elektroniske filer av sluttrapport med alle vedlegg, ferdig program og programkode for prosjektet. BADR5 DASDOS Jügend 27.11.2009 36

Systemkravdokument 2009 BADR 5 Vedlegg 5 Arbeidskontrakt Arbeidskontrakt mellom medlemmene av BADR 5 Vedrørende prosjekt IT1, 1 semester. BADR5 DASDOS Jügend 26.11.2009

Arbeidskontrakt BADR 5 Arbeidskontrakt for prosjektgruppa Das DOS Jügend Arbeidsgruppa Das DOS Jügend omfatter Eskil Espås Ugelstad, Håkon Wahl Engen, Sebastian Strømnes, Fredrik Lundsrud og Christoffer Lokrheim. Hensikten med gruppa Samarbeide på øvinger for å maksimere læringsutnyttelsen i studiegangen. Dette er for å optimalisere potensiell eksamenskarakter, B+. Vi ser dette som en realistisk karrakter. Vi vil venne oss til å arbeide i grupper for å sørge for et godt samarbeid resten av året. Gruppen skal også virke som en hjørnestein i prosjektet. Mål for prosjektet Vi skal stå i faget til beste evne mens vi utnytter hverandres styrker og ekspertise. Ved å jobbe i Team med god kommunikasjon og organisering vil vi bygge en god grunnstruktur for studiegangen. Rollefordeling Sebastian tar leder ansvaret og vil lede møter med faglærer og interne møter når vi starter prosjektet. Håkon er i utgangspunktet vår faste sekretær og har også det overordnede ansvaret for timelister. Christoffer har ansvaret for møteinnkallinger og har et overordnet ansvar for databasen i prosjektet. Eskil har et overordnet ansvar for VB.Net koden. Fredrik har overordnet ansvar for all dokumentasjon. Prosedyrer Ved innkalling til møter vil vi bruke student-mail og SMS, vi velger å holde oss til 2 kanaler for å holde det oversiktlig. Møtene vil forekomme på skolen og alltid i fysisk form. Vi vil samles etter forelesningene for å samle tanker, ideer og problemer. Deretter for å jobbe med oppgavene som ligger for hånden. Dette fordi skolen er en naturlig møteplass, og et lett tilgjengelig sted å samles for å arbeide med oppgaver. Vi vil ha en ordstyrer ved møtene for å holde møtet på rett kjør, og for å komme raskt igjennom agendaen. Ordstyrer bestemmes før møtet. Konflikter i gruppa konfronteres så fort som mulig med alle tilstede, tilføyer punkter etter erfaring. Baksnakking og hets er ikke akseptabelt, vi er voksne mennesker. Alle beslutninger skal være under enighet fra hele gruppen, dette håper vi vil lære oss å inngå kompromiss ved uenigheter. Gruppen skal alltid skrive referat fra møtene vi har med faglærer. Angående rapportering av timelistene, må alle medlemmene ta ansvar for å levere dette til ansvarlig ajourføres. Innlevering av timelister og statusrapport til faglærer vil foregå på mandager. All programmering skal være kommentert og merket med initialer ved start og slutt. Variabler skal være bygd opp etter "camel casing" prinsippet og starte med forbokstaven til deklareringen. 2

Arbeidskontrakt BADR 5 Kommentering av hverandres arbeid vil bli gjort ved hjelp av dasdos.etherpad.com. Gruppemøter Fravær skal varsles muntlig ansikt til ansikt eller over telefon, den som ikke møter er også ansvarlig for å bekrefte at alle på gruppa har registrert ditt fravær. Hvis en person er borte flere dager på rad ringer gruppa for å finne en konkret løsning på problemet, eventuelt hjelpe til. Under møter settes mobil på lydløs, viktige telefoner kan prioriteres ved nødstilfelle. Vi skal sørge for at alle blir hørt, alle meninger og innspill er verdige for diskusjon. Dato: 30.09.2009 Eskil E. Uglestad Håkon W. Engen Sebastian Strømnes Fredrik Lundsrud Christoffer F. Lokrheim 3

2009 Systemkravdokument BADR 5 Vedlegg 6 Timelister Fullstendig samling av timelistene BADR5 DASDOS Jügend 27.11.2009

Timeliste Christoffer Framstad Lokrheim Ukenr.: 40 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 1 Ukenr.: 41 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 2 2 5 9 Ukesum 9 Totalsum 10 Ukenr.: 42 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 4,5 4 1 Ukesum 9,5 Totalsum 19,5 2

Timeliste Christoffer Framstad Lokrheim Ukenr.: 43 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 7 3 10 Ukesum 10 Totalsum 29,5 Ukenr.: 44 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 10 6 5 1 22 Ukesum 22 Totalsum 51,5 Ukenr.: 45 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 10 1 5 16 Visual Basic 6 6 Prosjektrettet systemarbeid Ukesum 22 Totalsum 73,5 3

Timeliste Christoffer Framstad Lokrheim Ukenr.: 46 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 11,5 4 15,5 Ukesum 15,5 Totalsum 89 Ukenr.: 47 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 2 4 6 Visual Basic 1,75 12,5 8,75 12,5 6,5 1 43 Prosjektrettet systemarbeid 1 1 Ukesum 50 Totalsum 139 Ukenr.: 48 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1,25 5 2 2 10,25 Visual Basic 7 9,25 2 5 23,25 Prosjektrettet systemarbeid 9 6 15 Ukesum 48,5 Totalsum 187,5 4

Timeliste Eskil Espås Ugelstad Ukenr.: 40 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 1 Ukenr.: 41 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 3 7,5 10,5 Ukesum 10,5 Totalsum 11,5 Ukenr.: 42 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 4 4 Prosjektrettet systemarbeid 4,5 4,5 Ukesum 8,5 Totalsum 20 5

Timeliste Eskil Espås Ugelstad Ukenr.: 43 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 7 7 14 Prosjektrettet systemarbeid Ukesum 14 Totalsum 34 Ukenr.: 44 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 1 Visual Basic 5 2 7 Prosjektrettet systemarbeid 4 4 Ukesum 12 Totalsum 46 Ukenr.: 45 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 2 2 4 Visual Basic 7 8 15 Prosjektrettet systemarbeid Ukesum 19 Totalsum 65 6

Timeliste Eskil Espås Ugelstad Ukenr.: 46 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1,5 1,5 Visual Basic 4 4 Prosjektrettet systemarbeid 9,5 9,5 Ukesum 15 Totalsum 80 Ukenr.: 47 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 2 1 3 Visual Basic 10 6 6 3,5 25,5 Prosjektrettet systemarbeid Ukesum 28,5 Totalsum 108,5 Ukenr.: 48 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 2 1 1 5 Visual Basic 2 10 8 3 4 27 Prosjektrettet systemarbeid 3 8 7 18 Ukesum 50 Totalsum 158,5 7

Timeliste Sebastian Strømnes Ukenr.: 40 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 1 Ukenr.: 41 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 2 7,5 9,5 Ukesum 9,5 Totalsum 10,5 Ukenr.: 42 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 0 Prosjektrettet systemarbeid 4,5 4 8,5 Ukesum 8,5 Totalsum 19 8

Timeliste Sebastian Strømnes Ukenr.: 43 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 5 7 12 Ukesum 12 Totalsum 31 Ukenr.: 44 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 10 6 16 Ukesum 16 Totalsum 47 Ukenr.: 45 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 1 Visual Basic 3 3 6 Prosjektrettet systemarbeid 7 3 10 Ukesum 17 Totalsum 64 9

Timeliste Sebastian Strømnes Ukenr.: 46 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1,5 1,5 Visual Basic 4 4 Prosjektrettet systemarbeid 9,5 9,5 Ukesum 15 Totalsum 79 Ukenr.: 47 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 2 1 2 5 Visual Basic 10 7 6 23 Prosjektrettet systemarbeid 0 Ukesum 28 Totalsum 107 Ukenr.: 48 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 4 3 1 9 Visual Basic 2 8 8 2 6,5 26,5 Prosjektrettet systemarbeid 9 6 15 Ukesum 50,5 Totalsum 157,5 10

Timeliste Håkon W. Engen Ukenr.: 40 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 1 Ukenr.: 41 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 2,5 4,5 7 Ukesum 7 Totalsum 8 Ukenr.: 42 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 4 4 Prosjektrettet systemarbeid Ukesum 4 Totalsum 12 11

Timeliste Håkon W. Engen Ukenr.: 43 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 13 Ukenr.: 44 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 6 6 Ukesum 6 Totalsum 19 Ukenr.: 45 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 3 3 Ukesum 3 Totalsum 22 12

Timeliste Håkon W. Engen Ukenr.: 46 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 3 3 Ukesum 3 Totalsum 25 Ukenr.: 47 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 2 1 3 Ukesum 3 Totalsum 28 Ukenr.: 48 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 6 6 Visual Basic Prosjektrettet systemarbeid 2 6 3 2 9 6 28 Ukesum 34 Totalsum 62 13

Timeliste Fredrik Lundsrud Ukenr.: 40 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 3 3 Ukesum 3 Totalsum 3 Ukenr.: 41 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 2,5 5 7,5 Ukesum 7,5 Totalsum 10,5 Ukenr.: 42 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 1 Visual Basic 1 1 Prosjektrettet systemarbeid 4 2 6 Ukesum 8 Totalsum 18,5 14

Timeliste Fredrik Lundsrud Ukenr.: 43 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 3 1 4 Prosjektrettet systemarbeid 2 2 4 Ukesum 8 Totalsum 26,5 Ukenr.: 44 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 2 2 Prosjektrettet systemarbeid 3 3 Ukesum 5 Totalsum 31,5 Ukenr.: 45 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid 1 1 Ukesum 1 Totalsum 32,5 15

Timeliste Fredrik Lundsrud Ukenr.: 46 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL 1 1 Visual Basic 2 2 Prosjektrettet systemarbeid 4 4 Ukesum 7 Totalsum 39,5 Ukenr.: 47 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic 1 4 5 Prosjektrettet systemarbeid Ukesum 5 Totalsum 44,5 Ukenr.: 48 Arbeidsart Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag SUM Merknad My SQL Visual Basic Prosjektrettet systemarbeid Ukesum Totalsum 44,5 16

2009 Vedlegg 7 Status rapport og Gruppe timelister Fullstendig samling av statusrapportene og gruppetimelistene som ble laget i sammenheng med prosjektet 1 semester IT1 BADR5 DASDOS Jügend 26.11.2009

StatusRapporter BADR 5 Statusrapport Uke 40 Gjennomført siste uke Prosjektstatus Resultat Antall timer arbeid utført i uken Økonomi Samarbeid Problemer Tiltak Oppgaver neste uke Fikk utdelt oppgaven. Ordnet arbeidskontrakt. Fordelte oppgaver. OK Ferdigstilt timeliste og arbeidskontrakt. 7 timer OK OK OK OK Forstudierapport, Ganntdiagram Statusrapport Uke 41 Gjennomført siste uke Jobbet med forstudierapporten Prosjektstatus OK Resultat Nesten ferdig med forstudie Antall timer arbeid utført i uken 43,5 timer Økonomi OK Samarbeid OK Problemer OK Tiltak Gjøre små endringer på forstudierapporten etter møtet med Jan. Oppgaver neste uke Innlevering av forstudierapport og arbeidskontrakt. Starte arbeidet med utkast til GUI og skrive relasjonsskjema 2

StatusRapporter BADR 5 Statusrapport Uke 42 Gjennomført siste uke Fullførte forstudierapporten Prosjektstatus OK Resultat Antall timer arbeid utført i uken Økonomi Samarbeid Problemer Tiltak Oppgaver neste uke Gruppemøte med faglærer. Ferdig utkast av GUI og start laging av database. Startet arbeid med brukerkravdokument 38,5 timer OK OK OK Få ferdigstilt GUI og starter med relasjonsskjema for databasen. Få ferdigstilt brukerkravdokument om vi kan få til noen der. Statusrapport Uke 43 Gjennomført siste uke Fullførte forstudierapporten og fikk den godkjent Prosjektstatus OK Resultat Puttet mer vb kode i prototypen, startet brukerkravdokumentet Antall timer arbeid utført i uken 45 timer Økonomi OK Samarbeid OK Problemer OK Tiltak Oppgaver neste uke Bør få ferdigstilt brukerkravdokumentet 3

StatusRapporter BADR 5 Statusrapport Uke 44 Gjennomført siste uke Jobbet med GUI og startet med relasjonsskjema for databasen Prosjektstatus OK Resultat Fullførte den første prototypen og ferdigstilte brukerkravdokumentet og prototypen Antall timer arbeid utført i uken 61 Økonomi OK Samarbeid OK Problemer Litt fravær Tiltak Fraværet kan kan og bør minskes Oppgaver neste uke Uvisst Statusrapport Uke 45 Gjennomført siste uke Fullførte den første prototypen og ferdigstilte brukerkravdokumentet og prototypen Prosjektstatus OK Resultat ER modellen ble justert og det ble jobbet mer med vb koden. Antall timer arbeid utført i uken 62 Økonomi OK Samarbeid OK Problemer Fravær Tiltak Fraværet bør fremdeles kunne reduseres Oppgaver neste uke Systemkravdokument 4

StatusRapporter BADR 5 Statusrapport Uke 46 Gjennomført siste uke Systemkravdokument, koblet VB til database Prosjektstatus OK Resultat Systemkravdokument Antall timer arbeid utført i uken 55,5 timer Økonomi OK Samarbeid OK Problemer Veldig ujevn arbeidsinnsats Tiltak Oppgaver neste uke Kom fram til etter gruppemøte med Jan at det blir individuell vurdering av prosjektkarakter pågrunn av ujavn arbeidsinnsats innad i gruppa E-post vedlegg, Vareadministrering, Salg(kvittering, nullstille) Statusrapport Uke 47 Gjennomført siste uke E-post vedlegg, Vareadministrering, Salg(kvittering, nullstill bestilling) Prosjektstatus OK Resultat E-post vedlegg, Vareadministrering, Salg(kvittering, nullstill bestilling) Antall timer arbeid utført i uken 114,5 timer Økonomi OK Samarbeid OK Problemer Ujevn arbeidsinnsats Tiltak Oppgaver neste uke Kom fram til etter gruppemøte med Jan at det blir individuell vurdering av prosjektkarakter pågrunn av ujevn arbeidsinnsats innad i gruppa 5

StatusRapporter BADR 5 Statusrapport Uke 48 Gjennomført siste uke Ferdigstille programmet, sluttrapport Prosjektstatus OK Resultat Sluttrapport og det fullstendige programmet. Mye debugging Antall timer arbeid utført i uken 183 timer Økonomi OK Samarbeid OK Problemer OK Tiltak OK Oppgaver neste uke Ferdig 6

Gruppe Timeliste BADR 5 Ukenr.: 40 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 1 1 1 1 3 7 Sum uke 1 1 1 1 3 7 Akkumulert sum 1 1 1 1 3 7 Sum uke Ukenr.: 41 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 0 Visual Basic 0 Prosjektrettet systemarbeid 10,5 9,5 9 7 7,5 43,5 Sum uke 10,5 9,5 9 7 7,5 43,5 Akkumulert sum 11,5 10,5 10 8 10,5 50,5 Sum uke Ukenr.: 42 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 1 1 Visual Basic 4 4 1 9 Prosjektrettet systemarbeid 4,5 8,5 9,5 6 28,5 Sum uke 8,5 8,5 9,5 4 8 38,5 Akkumulert sum 20 19 19,5 12 18,5 89 Sum uke 7

Gruppe Timeliste BADR 5 Ukenr.: 43 Hovedaktivitet My SQL Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik Visual Basic 14 4 18 Prosjektrettet systemarbeid 12 10 1 4 27 Sum uke 14 12 10 1 8 45 Akkumulert sum 34 31 29,5 13 26,5 134 Sum uke Ukenr.: 44 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 1 1 Visual Basic 7 3 10 Prosjektrettet systemarbeid 4 16 22 6 2 50 Sum uke 12 16 22 6 5 61 Akkumulert sum 46 47 51,5 19 31,5 195 Sum uke Ukenr.: 45 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 4 1 16 21 Visual Basic 15 6 6 27 Prosjektrettet systemarbeid 10 3 1 14 Sum uke 19 17 22 3 1 62 Akkumulert sum 65 64 73,5 22 32,5 257 Sum uke 8

Gruppe Timeliste BADR 5 Ukenr.: 46 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 1,5 1,5 1 4 Visual Basic 4 4 2 10 Prosjektrettet systemarbeid 9,5 9,5 15,5 3 4 41,5 Sum uke 15 15 15,5 3 7 55,5 Akkumulert sum 80 79 89 25 39,5 312,5 Sum uke Ukenr.: 47 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 3 5 6 14 Visual Basic 25,5 23 43 5 96,5 Prosjektrettet systemarbeid 1 3 4 Sum uke 28,5 28 50 3 5 114,5 Akkumulert sum 108,5 107 139 28 44,5 427 Sum uke Ukenr.: 48 Hovedaktivitet Timer Eskil Timer Sebastian Timer Christoffer Timer Håkon Timer Fredrik My SQL 5 9 10,25 6 30,25 Visual Basic 27 26,5 23,25 76,75 Prosjektrettet systemarbeid 18 15 15 28 76 Sum uke 50 50,5 48,5 34 0 183 Akkumulert sum 158,5 157,5 187,5 62 44,5 610 Sum uke 9

2009 Vedlegg 8 Innkallinger og referater Samtlige innkallinger og referater fra prosjektmøtene BADR5 DASDOS Jügend 26.11.2009

Innkallinger til Prosjektmøte BADR 5 Innkalling til Prosjektmøte 12.10.2009 TIDSPUNKT OG STED: 09:45 P-LAB Innkalte Samtlige medlemmer av Gruppe 5 BADR» Engen, Håkon Wahl» Lundsrud, Fredrik» Strømnes, Sebastian» Ugelstad, Eskil Espås» Lokrheim, Christoffer Framstad Jan H. Nilsen eller Tore Mallaug Merknader Møteleder: Strømnes, Sebastian (Leder BADR 5) Møtereferent: Engen, Håkon Saksliste Sak nr 01 / 12.10 Sak nr 02 / 12.10 Sak nr 03 / 12.10 Sak nr 04 / 12.10 Sak nr 05 / 12.10 Sak nr 06 / 12.10 Sak nr 07 / 12.10 Godkjenning innkalling og saksliste Gjennomgang av Arbeidskontrakt Gjennomgang av Forstudierapport Gjennomgang av Gannt Diagram Kommentarer fra veileder Prosjektstatus (framgang, gruppedynamikk, etc.) Eventuelt Møtet planlegges avsluttet ca kl. 10:05 Ta kontakt med undertegnede dersom du ikke har anledning til å komme Mvh Christoffer Framstad Lokrheim Trondheim 07.10.2009 2

Innkallinger til Prosjektmøte BADR 5 Innkalling til Prosjektmøte 26.10.2009 TIDSPUNKT OG STED: 13:00 GRUPPEROM I 2 ETA. Innkalte Samtlige medlemmer av Gruppe 5 BADR» Engen, Håkon Wahl» Lundsrud, Fredrik» Strømnes, Sebastian» Ugelstad, Eskil Espås» Lokrheim, Christoffer Framstad Jan H. Nilsen Merknader Møteleder: Strømnes, Sebastian (Leder BADR 5) Møtereferent: Engen, Håkon Saksliste Sak nr 01 / 26.10 Sak nr 02 / 26.10 Sak nr 03 / 26.10 Sak nr 04 / 26.10 Sak nr 05 / 26.10 Sak nr 06 / 26.10 Godkjenning innkalling og saksliste Gjennomgang av Brukerkravsdokumentet Gjennomgang av Utkast GUI Kommentarer fra veileder Prosjektstatus (framgang, gruppedynamikk, etc.) Eventuelt Møtet planlegges avsluttet ca kl. 13:30 Ta kontakt med undertegnede dersom du ikke har anledning til å komme Mvh Christoffer Framstad Lokrheim Trondheim 17.10.2009 3

Innkallinger til Prosjektmøte BADR 5 Innkalling til Prosjektmøte 09.11.2009 TIDSPUNKT OG STED: 09:30 GRUPPEROM 2 ETG. Innkalte Samtlige medlemmer av Gruppe 5 BADR» Engen, Håkon Wahl» Lundsrud, Fredrik» Strømnes, Sebastian» Ugelstad, Eskil Espås» Lokrheim, Christoffer Framstad Jan H. Nilsen Merknader Møteleder: Strømnes, Sebastian (Leder BADR 5) Møtereferent: Engen, Håkon Saksliste Sak nr 01 / 09.11 Sak nr 02 / 09.11 Sak nr 03 / 09.11 Sak nr 04 / 09.11 Sak nr 05 / 09.11 Sak nr 06 / 09.11 Godkjenning innkalling og saksliste Gjennomgang av Brukerkravsdokumentet Gjennomgang av Utkast GUI Kommentarer fra veileder Prosjektstatus (framgang, gruppedynamikk, etc.) Eventuelt Møtet planlegges avsluttet ca kl. 10:00 Ta kontakt med undertegnede dersom du ikke har anledning til å komme. Mvh Christoffer Framstad Lokrheim Trondheim 05.11.2009 4

Innkallinger til Prosjektmøte BADR 5 Innkalling til Prosjektmøte 19.11.2009 TIDSPUNKT OG STED: 13:00-13:30 GRUPPEROM 2 ETG. Nilsen, Jan Harald 17.11.2009 14:56 Fra Eskil Espås Ugelstad; Håkon Wahl Engen; Fredrik Lundsrud; Sebastian Strømnes; Til Christoffer F Lokrheim Hei Det er kommet oss for øre at ikke alle i gruppe 5 deltar like aktivt i arbeidet med prosjektet. Dersom dette er tilfelle vil det kunne medføre at gruppa vurderes indivduelt, når det gjelder karakterer på prosjektet. Det vil da være nødvendig at hver enklet spesifiserer sine bidrag slik at faglærerne kan vurdere det hver enkelt har gjort. Slike indivduelle vurderinger har vært gjort tidligere og generelt sett så ønsker ikke AITeL at noen grupper skal ha såkalte sleeping partners. Vi foreslår derfor at vi tar et gruppemøte slik at alle synspunkter i gruppa kan komme fram og blir enig om videre framdrift og vurderingsform. Tid: Torsdag 19.11.2009 kl 1300-1330. Møtested: Møterommet i 2. etasje mvh Jan 5

Referat fra prosjektmøter BADR5 Referat prosjektmøte 12.10.2009 TIDSPUNKT OG STED: 09:45 P-LAB Tilstede Engen, Håkon Wahl Lundsrud, Fredrik Ugelstad, Eskil Espås Lokrheim, Christoffer Framstad Jan H. Nilsen (Veileder) Frafall Strømnes, Sebastian Merknader Møteleder: Lokrheim, Christoffer Framstad Møtereferent: Ugelstad, Eskil Espås Saksliste Sak nr 01 / 12.10 Sak nr 02 / 12.10 Sak nr 03 / 12.10 Sak nr 04 / 12.10 Sak nr 05 / 12.10 Sak nr 06 / 12.10 Sak nr 07 / 12.10 Godkjenning innkalling og saksliste Godkjent. Gjennomgang av Arbeidskontrakt Ble ikke gjort. Gjennomgang av Forstudierapport Jan H. Nilsen kom med kommentarer ting vi lurte på. Vi kommer til å endre drift og forventningskostnader til 20% og omsetningsøkning fra 17% til 11%. Utdype avanse punktet i effektmål bedre. Sette navn på prosjektdeltakere på forsiden. Mer grundig del 10 i forstudiet. Utdype med nøkkeltall fra kost/nytte. Gjennomgang av Gannt Diagram Endre Gant-diagrammet fra dager til timer. Kommentarer fra veileder Fikk en del innspill som er listet i sak 03. Prosjektstatus (framgang, gruppedynamikk, etc.) Vi har fått en fin start og satser på å fortsette den gode trenden. Vi må få bedre rutiner rundt fravær. Tar et møte på dette. Eventuelt Ingen punkter på eventuelt. Møtet ble avsluttet kl. 10:05 Mvh Eskil Espås Ugelstad Trondheim 12.10.2009 6

Referat fra prosjektmøter BADR5 Møtereferat 26.10.09 TIDSPUNKT OG STED: 13:00 GRUPPEROM I 2. ETA. Tilstede - Håkon Engen - Eskil Ugelstad - Sebastian Strømnes - Kristoffer Lokrheim - Fredrik Lundsrud - Jan H. Nilsen Frafall - Absolutt ingen frafall denne gangen Merknader Møteleder: Strømnes, Sebastian(Leder BADR 5) Møtereferent: Engen, Håkon 7

Referat fra prosjektmøter BADR5 Saksliste Sak nr 01 / 12.10 Sak nr 02 / 12.10 Sak nr 03 / 12.10 Sak nr 04 / 12.10 Godkjenning innkalling og saksliste Godkjent Gjennomgang av Brukerkravsdokumentet Ingen tiltak. Gjennomgang av Utkast GUI Vær mer konkret når det gjelder brukergrensesnittet, blant annet at det skal lages i VB. NET. Kommentarer fra veileder Bør følge malen når det gjelder Innholdsfortegnelsen, innholdsfortegnelsen bør være i henhold til malen. Rammebetingelser kan tas bort. Ta med konklusjon og konsekvenser i risikoanalysen. Kunne gjerne sagt mer om samarbeidsverktøyet vi bruker. Ha med referanser i referanselista. Se på prosjektmålene og ta med dem i arbeidskontrakten. Gjør arbeidskontrakten mer punktvis slik at den blir mer oversiktlig. Kunne laget en tabell for hvem som har de ulike rollene og hva rollene innebærer. Sak nr 05 / 12.10 Sak nr 06 / 12.10 Prosjektstatus (framgang, gruppedynamikk, etc.) Fortsett den gode progresjonen, men må vel fremdeles gjøre noe med fraværet som bør reduseres. Eventuelt Ingen punkter Møtet ble avsluttet kl. 13:40 Mvh Håkon Wahl Engen Trondheim 26.10.2009 8

Referat fra prosjektmøter BADR5 Referat til Prosjektmøte 09.11.2009 TIDSPUNKT OG STED: 09:30 GRUPPEROM 2 ETG. Tilstede Samtlige medlemmer av Gruppe 5 BADR» Strømnes, Sebastian» Ugelstad, Eskil Espås» Lokrheim, Christoffer Framstad» Lundsrud, Fredrik Jan H. Nilsen Frafall» Engen, Wahl Engen Merknader Møteleder: Strømnes, Sebastian (Leder BADR 5) Møtereferent: Ugelstad, Eskil Saksliste Sak nr 01 / 09.11 Godkjenning innkalling og saksliste -OK Sak nr 02 / 09.11 Gjennomgang av Brukerkravsdokumentet - Små endringer på kapitell 2. - Legge til nivå 0 slik at kunder kan søke på varer. - Bruk konkrete navn i UseCase diagrammet. Sak nr 03 / 09.11 Gjennomgang av Utkast GUI - Statestikk av søk Sak nr 04 / 09.11 Kommentarer fra veileder - Vi trenger ikke normalisere post tabellen. - Vi har kommet godt i gang. Sak nr 05 / 09.11 Prosjektstatus (framgang, gruppedynamikk, etc.) - Sak nr 06 / 09.11 Eventuelt - Spørsmål angående personvern loven. - Tenk i gjennom personvernloven og dra en tolkning ut i fra den. Vi er ikke jurister så vi må bare ta tak i problemet og tolke det selv. Møtet ble avsluttet ca kl. 10:00 Mvh Eskil Espås Ugelstad Trondheim 05.11.2009 9

Referat fra prosjektmøter BADR5 Referat til Prosjektmøte 19.11.2009 TIDSPUNKT OG STED: 13:00-13:30 GRUPPEROM 2 ETG. Fra Nilsen, Jan Harald 19.11.2009 16:23 Eskil Espås Ugelstad; Håkon Wahl Engen; Fredrik Lundsrud; Sebastian Strømnes; Til Christoffer F Lokrheim Hei Her kommer et kort referat fra møtet i dag angående vurdering/karatersetting av innsatsen i prosjektet i IT1. Tilstede: Sebastian, Christoffer, Eskil og Håkon. Fraværende: Fredrik Arbeidsinnsatsen og tilstedeværelsen i prosjektarbeidet i gruppa ble bekrevet og diskutert av alle de frammøtte. På grunn av ulik innsats fra enkeltmedlemmene var alle enige om følgende: Det mest retferdige vil være en indiduell karaktersetting på prosjektet blandt gruppemedlemmene. Dette ble derfor vedtatt av alle på møtet. For at dette skal bli mulig må hvert enkelt gruppemedlem kunne dokumentere hva han har gjort, alene eller sammen med andre. Rapportene og koden må vise hvem som har gjort hva. Gruppa må gjøre dette i fellesskap og bli enige om denne fordelingen og det må komme klart fram slik at veilederne kan forstå hvem som har gjort hva. Dersom noen har innsigelser eller synspunkter som ikke er kommet fram, må dette tas opp med veileder, Jan, og det må eventuelt kalles inn til et nytt møte. mvh Jan 10

2009 Vedlegg 9 SQL Script Viser opprettelse av tabeller, innlegging av data, spørringer etc. BADR5 DASDOS Jügend 26.11.2009

SQL Script BADR5 Prosjektgruppen ser det veldig ugunstig å publisere scriptet i sin helhet i utskrevet form, dette fordi det består av 5548 linjer. Vi har derfor valgt å gi ut et utdrag av forskjellige seksjoner i dette vedlegget. Den fullstendige versjonen av scriptet vil ligge vedlagt på CD og kan i tillegg leses fra http://tihlde.org/~sebastis/prosjekt/dokumentasjon/script.txt Innholdsfortegnelse -- S l e t t a l l e g a m l e d a t a.... 3 -- L a g a l l e t a b e l l e r.... 3 -- I n n f ø r f r e m m e d n ø k le r.... 4 -- E n d r i n g e r i d a t a b a s e n.... 4 -- O p p r e t t e I n d e x... 4 -- L e g g t i l v e r d i e r.... 5 * EKSEMPLER PÅ SPØRRINGER.... 6 2

SQL Script BADR5 -- S l e t t a l l e g a m l e d a t a. DROP TABLE IF EXISTS BedriftInfo; DROP TABLE IF EXISTS SalgProdukt; DROP TABLE IF EXISTS Cd; DROP TABLE IF EXISTS DVD_BlueRay; DROP TABLE IF EXISTS ProduktBestilling; DROP TABLE IF EXISTS Produkt;. -- L a g a l l e t a b e l l e r. CREATE TABLE Format ( Format VARCHAR(30) NOT NULL, PRIMARY KEY (Format )) TYPE=INNODB; CREATE TABLE Produkt ( Varenr INTEGER NOT NULL AUTO_INCREMENT, EANKode VARCHAR(13), Format VARCHAR(30) NOT NULL, Tittel VARCHAR(70), Produsent VARCHAR(30), UtgivelsesAr CHAR(4), Bilde VARCHAR(250), InnkjOpspris DECIMAL(7,2), Avanse DECIMAL(5,2), Beholdning INTEGER, LeverandOrID INTEGER NOT NULL, LokButID CHAR(4), LokLagID VARCHAR(5), Sjanger_navn VARCHAR(30) NOT NULL, Status VARCHAR (30) NOT NULL, PRIMARY KEY (Varenr)) TYPE=INNODB; CREATE TABLE Ansatt ( AnsattID INTEGER NOT NULL auto_increment, Personnr VARCHAR(11), Etternavn VARCHAR(30), Fornavn VARCHAR(30), Epost VARCHAR(30), Tlf CHAR(8), Addresse VARCHAR(30), Post_nr CHAR(4) NOT NULL, Kontonr VARCHAR (11), PRIMARY KEY (AnsattID )) TYPE=INNODB; 3

SQL Script BADR5 -- I n n f ø r f r e m m e d n ø k le r. ALTER TABLE Produkt ADD FOREIGN KEY (Format) REFERENCES Format (Format); ALTER TABLE Salg ADDFOREIGN KEY (KundeID) REFERENCES Kunde (KundeID); ALTER TABLE Produkt ADD FOREIGN KEY (Sjanger_navn) REFERENCES Sjanger (Sjanger_navn); -- E n d r i n g e r i d a t a b a s e n. ALTER TABLE Bruker ADD Admin CHAR(1); -- O p p r e t t e I n d e x CREATE INDEX FK1_Format_Produkt ON Produkt (Format); CREATE INDEX FK2_Kunde_Salg ON Salg (KundeID); CREATE INDEX FK3_Sjanger_Produkt ON Produkt (Sjanger_navn); 4

SQL Script BADR5 -- L e g g t i l v e r d i e r. INSERT INTO `Post` VALUES ('0001', 'Oslo', 301, 'Oslo', 3, 'Oslo'), ('1000', 'Oslo', 301, 'Oslo', 3, 'Oslo'), ('1001', 'Oslo', 301, 'Oslo', 3, 'Oslo'), ('1003', 'Oslo', 301, 'Oslo', 3, 'Oslo'), INSERT INTO Bruker VALUES ('selger', 'Ua0XXkhJ+HCJcgdhjT+qnQ==', '1'), ('sekretær', 'eogaeikkwu8xupcv3uny07zwbps1e8v4', '2'), ('admin', 'D2/lbeRybw7cxCY6dtCMUUPKA9601zd+', '3'), ('q', 'N108lO/gTtw=', '3'), ('beta', '8DQ0Pfcly4k1H3mRUSOccg==', '2'); INSERT INTO Format VALUES ('CD'), ('DVD'),('BLUERAY'); --Her lurer vi MYSQL tjeneren til å starte neste verdi på 70000. INSERT INTO Produkt VALUES ('69999', '', 'CD', '','', '', '', '', '', '', '1', '0101', '1 Etg.', 'mujazz', 'Lagervare'); DELETE FROM Produkt WHERE Varenr= '69999'; INSERT INTO Produkt VALUES ('', '7311250082528', 'DVD', 'Il bueno, il brutto, il cattivo', 'Arturo', '1967', 'http://ia.mediaimdb.com/images/m/mv5bmje2mze5mte5nv5bml5banbnxkftztcwodi4oduymq@@._v1._sx10 0_SY138_.jpg', '39', '95,00', '13', '1', '0100', '1 Etg.', 'moaction', 'Lagervare') ('', '7335656682528', 'CD', 'It Is What It Is', 'Artistry Music', '2009', 'http://ecx.imagesamazon.com/images/i/51djzs3b2yl._sl160_aa160_.jpg', '79', '110,00', '7', '1', '0214', '2 Etg.', 'mujazz', 'Lagervare'), INSERT INTO Cd VALUES ('70001', '13', 'Brian Bromberg'), INSERT INTO Salg VALUES ('', '1', '10', '156,00', '2009', '20', '11', '11', '40', '54'); INSERT INTO SalgProdukt VALUES (70007, 1, 3); UPDATE Produkt SET Beholdning = (Beholdning - 3) WHERE Varenr = '70007'; 5

SQL Script BADR5 /* EKSEMPLER PÅ SPØRRINGER. -- P r o d u k t - A n t a l l s o l g t e SELECT sp.varenr, p.tittel, p.beholdning, SUM(sp.Antall) as 'Antall solgte' FROM SalgProdukt sp JOIN Produkt p ON sp.varenr = p.varenr GROUP BY sp.varenr -- M N D O M S E T N I N G P E R Å R SELECT s.maned, SUM(s.TotalPris) AS '{?na}', SUM(sa.TotalPris) AS '{?for}' FROM Salg s JOIN Salg sa ON s.maned = sa.maned WHERE sa.ar = '{?for}' AND s.ar = '{?na}' GROUP BY s.maned --'{?for}' og '{?na}' er koden som forteller systemet at dette er et parameter. -- E N S P Ø R R I N G E N E B R U K T I S Ø K E F U N K S J O N E N SELECT p.varenr, p.eankode, p.tittel, c.artist, p.utgivelsesar FROM Produkt p JOIN Cd c ON c.varenr = p.varenr WHERE p.varenr LIKE '%70000%' OR p.eankode LIKE '%70000%' OR p.format LIKE '%70000%' OR p.tittel LIKE '%70000%' OR p.sjanger_navn LIKE '%70000%' OR c.artist LIKE '%70000%' */ 6

2009 Vedlegg 10 Brukerveiledning Omfattende beskrivelse av programmets funksjoner og bruksområder BADR 5 DASDOS Jügend 26.11.2009

Brukerveiledning BADR5 Velkommen som bruker av MusicSurfer 1.0 også kalt MuSu. Takk for at De/Dere valgte MusicSurfer. Dette dokumentet er en brukermanual for sluttbrukere av programmet. Dokumentet vil ta for seg bilde for bilde de ulike funksjonene du finner i programmet og hvordan du som sluttbruker skal kan ta i bruk MusicSurfer på en mest mulig effektiv måte. Bildene er merket med nummer og en nummerert kommentar som beskriver området på bilde. Innholdsfortegnelse Brukerveiledning MusicSurfer 1.0 1 1 Login... 2 2 Søk... 3 3 Kontrollpanel... 4 4 Salg... 5 5 Vareadministrasjon... 6 6 Varemottak... 7 7 Administrasjon... 8 8 Rapporter... 9 9 Innkjøp... 10 1 Login Figur 1 viser vinduet for login. 1. Her fylles brukernavn inn. 2. Her fylles passord inn. 3. Knappen for å logge inn om du bruker brukernavn og passord. 4. Knappen lar deg logge inn uten brukernavn og passord. 5. Lukker programmet. Figur 1 2

Brukerveiledning BADR5 2 Søk Figur 2 viser søk vinduet som standardvindu i programmet ved oppstart. Vinduet åpnes under fil søk. 1. Velg hva du vil søke på. 2. Felt for å skrive det man vil søke på. La stå tomt om du vil ha alle varer. 3. Trykk på søk for å gjennomføre søket. 4. Tømmer boksen med informasjon fra et søk. 5. Lister opp ditt søk. Kan også klikke på en vare her og informasjon om varen vil komme opp i nr 8. 6. Gir deg muligheten til å legge en valgt vare rett i kurven i Salg. 7. Skjuler og viser deg en plantegning over lokalet. 8. Fylles med informasjon fra valgt vare. 9. Plantegning over lokalet. Figur 2 3

Brukerveiledning BADR5 3 Kontrollpanel Figur 3 viser modervinduet som har alle andre vinduer som for eksempel Søk, Salg, Vareadministrasjon osv. 1. Gir deg tilgang til salg, søk, vareadministrasjon, varemottak, logg ut og avslutt. 2. Bringer frem det valgte vinduet fra listen. Fint om du har mange vinduer og vil ha et som ligger skjult bak et annet. 3. Gir deg tilgang til administrasjon, innkjøp og rapporter 4. Organiserer alle vinduene som er åpnet horisontalt, vertikalt eller cascade. Figur 3 4

Brukerveiledning BADR5 4 Salg Figur 4 viser vinduet som håndterer alt av salg og returer. Vinduet åpnes under fil salg. 1. Merk av for kassa for salg over skranke og kundebestilling for bestillinger fra kunder pr telefon eller epost. 2. Velg ditt ansatte nummer. 3. Felt for å skrive inn EAN eller varenummer. 4. Felt for å skrive inn antallet man vil selge. 5. Legger ønsket solgt vare i kurven. 6. Fjerner den valgte varen fra kurven. 7. Tilbakemeldings område om ting går som det skal eller om feil oppstår ved salg. 8. Oppretter en ny kunde. 9. Lister opp varer som er ønsket solgt. Blir referert til som kurven. 10. Skriv inn beløpet kunden betaler i kontant for å få opp hvor mye han skal ha tilbake. 11. Gjennomfører salget/returen med de varene som ligger i kurven. 12. Brukes når varer skal returneres. Bruk denne i stede for 5 ved retur. 13. Skriver ut kvittering fra før salget blir gjennomført om det er ønskelig. Det blir også spurt om man vil skrive ut kvittering Figur 4 når man trykker på nr 11. 14. Tømmer kurven for innhold. 5

Brukerveiledning BADR5 5 Vareadministrasjon Figur 5 viser vinduet som gir tilgang til å endre på data på valgte varer og opprette nye varer. Vinduet åpnes under fil vareadministrasjon. 1. Skriv inn EAN eller varenummer her. 2. Henter frem informasjon om nr 1 er fylt inn. 3. Klikk her om det skal opprettes en ny vare. 4. Viser varenummeret. Varenummer blir automatisk laget av databasen ved oppretting av ny vare. 5. Felt for EAN nummeret. 6. Felt for titler på cd og filmer. 7. Felt for navn på produsent av vare. 8. Velg format på varen her. CD,DVD og BluRay. 9. Felt som angir året varen er utgitt. 10. Angi innkjøpspris her. 11. Ønsket avanse på varen. Figur 5 12. Angi aktuell beholdning. 13. Url til cover bilde. 14. Setter sjangeren på varen. 15. Setter leverandøren av varen. 16. Angi lokasjonen til varen. 17. Velg hvilket lager man finner varen i. 18. Setter status på varen. Lagervare, bestillingsvare eller utgått. 19. Aldersgrense på film. 20. Bildeformatet til filmen. 21. Artist til en cd. 22. Antall spor på en cd. 23. Lagrer eventuelle endringer. 24. Tømmer skjemaet for informasjon. 25. Åpner varemottak. 6

Brukerveiledning BADR5 6 Varemottak Figur 6 viser vinduet for mottak av varer. Her kan man øke ta i mot varer som ankommer butikken og øke beholdningen på dem. Vinduet åpnes under fil varemottak. 1. Skriv inn EAN eller varenummer. 2. Skriv inn antallet man vil øke beholdningen med. 3. Gjennomfører oppdatering på beholdningen. 4. Lister opp alle varer som det er økt beholdning på og antallet det er økt med. Figur 6 7

Brukerveiledning BADR5 7 Administrasjon Figur 7 viser administrasjonsvinduet. Her kan man endre, slette og opprette brukere. Det er kun administrator som har tilgang til dette vinduet. Vinduet åpnes under admin administrasjon 1. Velg brukernavn som det ønskes å skifte passord på. 2. Angi ønsket nytt passord. 3. Angi passordet igjen for å sikre at passordet ble det ønskete passordet. 4. Gjennomfør endringen av passord. 5. Angi ønsket passord ved brukeroppretting. 6. Angi passordet til den nye brukeren. 7. Gjennomfører opprettingen av brukeren. 8. Velg brukeren du vil slette. 9. Gjennomfører slettingen av valgt bruker. Figur 7 8

Brukerveiledning BADR5 8 Rapporter Figur 8 viser vinduet for alle rapportene som kan genereres. Dette vinduet vil ikke selgere ha tilgang til. Vinduet åpnes under admin rapporter. 1. Velg ønsket rapport type. 2. Henter frem den rapporten som ble valgt i 1. 3. Området hvor rapporten kommer frem. Det er innbygd en del funksjoner i selve rapporten. Du kan lagre rapporten i ulike formater (doc, pdf osv.) Skrive de ut ved å trykke på skriver ikonet. Oppdatere rapporten slik at den laster inn de nyeste dataene fra databasen. Figur 8 9

Brukerveiledning BADR5 9 Innkjøp Figur 9 viser vinduet hvor bestilling av varer kan gjøres. Vinduet åpnes under admin innkjøp. 1. Velg leverandøren det skal bestilles varer fra. 2. Skriv inn EAN eller varenummeret på vare som skal bestilles. 3. Angi antallet som skal bestilles. 4. Legger angitt vare til bestillingen. 5. Fjerne siste vare som er lagt til bestillingen. 6. Viser varene som er lagt til i bestillingen. 7. Gjennomfører bestillingen av varer. Sender ut epost og gir deg mulighet til å skrive ut bestillingen. Figur 9 10

Tilbakemeldinger 2009 Badr5 Vedlegg 11 Tilbakemeldinger Tilbakemeldinger fra betatestere Noen tilbakemeldinger er ikke vedlagt da de ble levert som pdf filer til oss. Pdf tilbakemeldinger ligger vedlagt på CD platen som er vedlegg nr 4. 1 BADR 5 DASDOS Jügend 27.11.2009

2 [26.11.2009] [Dag Lokrheim ] [2750 Gran] BADR 5 Aitel ved HIST Jeg erklærer herved - At jeg har deltatt i verifiseringsarbeidet til BADR 5 aka DasDos Jügend. I mitt arbeid har jeg brukt programmet MuSu for å prøve å belaste produktet prosjektgruppen har laget. Hensikten med dette var at jeg prøvde ut systemet, med en den hensikten å kunne gi prosjektgruppen en tilbakemelding på hvordan jeg har oppfattet systemet, hvordan det var og sette seg inn i, hvor lett det var, om jeg oppdaget feil, og sist men ikke minst, om jeg greide å finne kritiske feil ved systemet. [Jeg har funnet at programmet ser ut til dekke mange behov i en tenkt musikkforetning ] [Dag Lokrheim] [Dag Lokrheim] []Daglig leder [Naturmedisinsk Senter Gjøvik]

3 26.11.09 Jonas Bendik Søreng BADR 5 Aitel ved HIST Jeg erklærer herved - At jeg har deltatt i verifiseringsarbeidet til BADR 5 aka DasDos Jügend. I mitt arbeid har jeg brukt programmet MuSu for å prøve å belaste produktet prosjektgruppen har laget. Hensikten med dette var at jeg prøvde ut systemet, med en den hensikten å kunne gi prosjektgruppen en tilbakemelding på hvordan jeg har oppfattet systemet, hvordan det var og sette seg inn i, hvor lett det var, om jeg oppdaget feil, og sist men ikke minst, om jeg greide å finne kritiske feil ved systemet. Kunne ikke søke etter Miley Cyrus, til tross for at CD'en hennes 'Breakout' var i CD listen Blueray er feil skrevet, heter Blu-ray Plantegning var moro! Får feilmelding om jeg prøver å legge til 2 ting i kurven. Savner en 'legg til flere varer'-knapp i kurvvinduet. Varebestilling/Innkjøp var veldig lett å skjønne. Kudos! Savner kanskje en 'bestill' knapp når man søker etter varen, så informasjonen kommer opp med en gang. Vareregistrering var litt verre, men mulig jeg er inkompetent. Skrev inn feil i innkjøpspris etc. I hvert fall sa programmet det til meg. Morro å prøve! Lykke til videre. Jonas Bendik Søreng Den Harbaldne

4 [26.11.2009] [Kari Framstad Lokrheim ] [2750 Gran] BADR 5 Aitel ved HIST Jeg erklærer herved - At jeg har deltatt i verifiseringsarbeidet til BADR 5 aka DasDos Jügend. I mitt arbeid har jeg brukt programmet MuSu for å prøve å belaste produktet prosjektgruppen har laget. Hensikten med dette var at jeg prøvde ut systemet, med en den hensikten å kunne gi prosjektgruppen en tilbakemelding på hvordan jeg har oppfattet systemet, hvordan det var og sette seg inn i, hvor lett det var, om jeg oppdaget feil, og sist men ikke minst, om jeg greide å finne kritiske feil ved systemet. [Likte godt at man kan søke opp det man leter etter og se lagerbeholdning og hvor det befinner seg. I salget burde kanskje feltet for veksle stått ved siden av salg. Programmet har generelt mange muligheter både for kunde og ansatte/drivere.] [Kari Framstad Lokrheim] [Kari Framstad Lokrheim] [Salgssjef] [Avisen Hadeland]

5 25.11.09 Karoline Malde BADR 5 Aitel ved HIST Jeg erklærer herved - At jeg har deltatt i verifiseringsarbeidet til BADR 5 aka DasDos Jügend. I mitt arbeid har jeg brukt programmet MuSu for å prøve å belaste produktet prosjektgruppen har laget. Hensikten med dette var at jeg prøvde ut systemet, med en den hensikten å kunne gi prosjektgruppen en tilbakemelding på hvordan jeg har oppfattet systemet, hvordan det var og sette seg inn i, hvor lett det var, om jeg oppdaget feil, og sist men ikke minst, om jeg greide å finne kritiske feil ved systemet. Burde være en link til legg i handlekurv fra søkemotoren, så man slipper å åpne nytt vindu via Filknappen. I salgvinduet bør det gå an å skrive inn navn på produkt i tilleg til varenummer og EAN i søksfeltet. Ville vært praktisk med en dra-slipp funksjon av produkt mellom søk- og salgvinduet. salgknappen i salg burde heller hete utfør eller liknende. Pga ved retur er det ikke et salg. Feilmelding. Som fåes hvis man ikke har valgt ansatt i salgsvinduet må endres. Kunde bestilling er ETT ORD! I salgsvinduet. I kundebestilling er det veldig uklart hva kunden blir lagret som. Ikke godt nok å få et nummer, når ikke det blir opplyst om hvilket kundenummer den nyopprettede kunden er etter registreringen. Står heller ingen steder at 1 er kassa. Det hadde jeg ikke skjønt. Sende mail til kunde om bestilling Hva gjør vekslefunksjonen mellom ansattid og kundeid. Burde være rett over totalsum. Hvorfor kan man kun søke i enten CD eller DVD. Burde vært en søk i hele butikken -funksjon. Antall i salg burde ha standard på 1. Heller endres hvis det er større antall. Hvis man i salgsvinduet trykker på legg til uten å ha skrevet inn produktkode kommer uforståelig feilmelding. Stå på! Bra side Korporal Malde ATAS

6 27.11.09 Ole P. Hval Pb 54, 2711 Gran BADR 5 Aitel ved HIST Jeg erklærer herved - At jeg har deltatt i verifiseringsarbeidet til BADR 5 aka DasDos Jügend. I mitt arbeid har jeg brukt programmet MuSu for å prøve å belaste produktet prosjektgruppen har laget. Hensikten med dette var at jeg prøvde ut systemet, med en den hensikten å kunne gi prosjektgruppen en tilbakemelding på hvordan jeg har oppfattet systemet, hvordan det var og sette seg inn i, hvor lett det var, om jeg oppdaget feil, og sist men ikke minst, om jeg greide å finne kritiske feil ved systemet. Installasjon var enkel og godt beskrevet. Greit brukergrensesnitt. Søk av varer var fleksibelt og enkelt. Det var ett valg for opprettelse av kunder som jeg ikke fant igjen bruk for senere. Det burde ha foreslått neste ledige kundenr automatisk.... med ønske om en fortsatt fin dag Ole P. Hval Senior Systemkonsulent JohNET Datasystemer AS Postboks 54, N-2711 Gran +47 61 33 88 50 Telefon +47 907 76 811 Mobil +47 61 33 88 40 Sentral ole.hval@johnet.no www.johnet.no Kart

1 Vedlegg 12 Referat fra Prosjektmøte 19.11.2009 Sitat fra utsendt melding Its Learning Fra: Nilsen, Jan Harald 19.11.2009 16:23 Til: Eskil Espås Ugelstad; Håkon Wahl Engen; Fredrik Lundsrud; Sebastian Strømnes; Christoffer F Lokrheim Hei Her kommer et kort referat fra møtet i dag angående vurdering/karatersetting av innsatsen i prosjektet i IT1. Tilstede: Sebastian, Christoffer, Eskil og Håkon. Fraværende: Fredrik Arbeidsinnsatsen og tilstedeværelsen i prosjektarbeidet i gruppa ble bekrevet og diskutert av alle de frammøtte. På grunn av ulik innsats fra enkeltmedlemmene var alle enige om følgende: Det mest retferdige vil være en indiduell karaktersetting på prosjektet blandt gruppemedlemmene. Dette ble derfor vedtatt av alle på møtet. For at dette skal bli mulig må hvert enkelt gruppemedlem kunne dokumentere hva han har gjort, alene eller sammen med andre. Rapportene og koden må vise hvem som har gjort hva. Gruppa må gjøre dette i fellesskap og bli enige om denne fordelingen og det må komme klart fram slik at veilederne kan forstå hvem som har gjort hva. Dersom noen har innsigelser eller synspunkter som ikke er kommet fram, må dette tas opp med veileder, Jan, og det må eventuelt kalles inn til et nytt møte. mvh Jan

1 Vedlegg 13. Arbeidsfordeling Forstudie. Her kan det kommenteres at samtlige gruppemedlemmer var med og jobbet tilnærmet like mye. Brukerkravdokument: 1 Introduksjon - Hensikt med dokumentet Christoffer og Fredrik 1.1 Litt om hvordan dokumentet skal tolkes Fredrik 2 Overordnet prosjektbeskrivelse/systembeskrivelse Christoffer 3 Krav til nytt system Sebastian 3.1 Krav til funksjoner Sebastian 3.2 Krav til datainnhold og overordnet lagringsstruktur Christoffer 3.3 Krav til egenskaper Sebastian, Christoffer og Fredrik 4 Kort introduksjon til prototypen av brukergrensesnittet Eskil 5 Reviderte resultater fra forrige fase 5.1 Reviderte prosjektmål Håkon 5.2 Reviderte rammebetingelser Håkon 5.3 Revidert risikoanalyse Eskil 5.4 Revidert fase og milepælsplan 5.5 Revidert ER - modell Christoffer Systemkravdokument: Hele dette dokumentet har blitt utarbeidet av Sebastian, Christoffer og Eskil. Statusrapporter og Timelisteføring Hovedansvaret har ligget på enkelt mann, og deretter har Håkon hatt ansvaret for å sette listene sammen til en gruppe liste. Han har også hatt ansvaret for statusrapportføring. Brukerveiledning Skrevet av Eskil, med hjelp fra Sebastian Innkalling og Referater Innkallingene er skrevet av Christoffer, og referatene er skrevet av Håkon. Dokumentansvar Alle produkter er skrevet av flere personer, men arbeidet med å sette alt sammen til ferdige dokumenter er gjort av Christoffer.

2 Modeller ER Modell Gannt Diagram Use Case Kost Nytte ISO modell Timediagram Mal Timelister Prototype Mal Tilbakemld Grafisk ansvarlig Christoffer Eskil Fredrik, revidert og redigert av Sebastian Sebastian Eskil og Christoffer Christoffer Håkon Eskil Christoffer Sebastian SQL Script All jobb gjort av Christoffer med hjelp fra Sebastian og Eskil. Håkon har i tillegg hjulpet til med å legge inn en del test verdier. VB.Net kode Laget kun av Eskil, Sebastian og Christoffer

3 PRS DB VB Andel Eskil 48 14,5 96 158,5 Sebastian 81,5 16,5 59,5 157,5 Christoffer 83 32,25 72,25 187,5 Håkon 52 6 4 62 Fredrik 27,5 2 15 44,5 SUM 292 71,25 246,75 610 120 100 80 60 40 PRS DB VB 20 0 Eskil Sebastian Christoffer Håkon Fredrik 1 VB DB PRS 0 50 100 150 200 250 300 350 Fredrik 7 % Håkon 10 % Eskil 26 % Christoffer 31 % Sebastian 26 %