SluttRapport - Tihlde

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 Forstudiedokument
Vedlegg 2 Brukerkravdokument
Vedlegg 3 Systemkravdokument
Vedlegg 4 CD med kjørbare filer
Vedlegg 5 Arbeidskontrakt
Vedlegg 6 Timelister
Vedlegg 7 Statusrapporter og ukerapporter
Vedlegg 8 Møteinnkallinger og møtereferater
Vedlegg 9 SQL Script
Vedlegg 10 Brukerveiledning
Vedlegg 11 Tilbakemeldinger fra beta testere
Vedlegg 12 Referat fra ekstraordinært prosjektmøte
Vedlegg 13 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: mysql.stud.aitel.hist.no
BRUKERNAVN: music_server
PASSORD: jugend
DATABASE: 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 som viser sannsynlighet i forhold til konsekvens i de problemene vi antar kan oppstå.
Risikoanalyse 1 Oppnå kompetanse
K
o
n
s
e
k
v
e
n
s
e
r
10
9
8
7
6
5
4
3
2
1
0
8
10
5
3
7
0 2 4 6 8 10
Sannsynlighet
9
1 2
6
4
2Sykdom/Fravær
3 Publiseringsmangler
4 Dataregistreringsfeil
5 Korrupt
rapporteringssystem
6 Store
vedlikeholdskostnader
7 Redundans
8 Komplett datatap
9 Feilestimert effektivitet
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 26 621
kr 434 601 kr 1 973 441
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
1% av provisjonen kr 225 000
10 % provisjon kr 2 250 000
Lønn til 13 selger kr 2 370 000
Lønn per selger kr 182 308
Lønn til Daglig leder kr 470 000
Lønn til sekretær kr 300 000
Totale lønnskostnader kr 3 140 000
Lønn til sekretær kr 300 000
1 % av provisjonen kr 249 750
9 % provisjon kr 2 247 750
Lønn til 11 selger kr 2 367 750
Lønn per selger kr 215 250
Lønn til Daglig leder kr 470 000
Lønn til sekretær kr 300 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
*
Sekretær
Daglig leder
*
*
*
*
*
*
Figur 6.1. UseCase Diagram.
*
selger
dagligLeder
*
*
*
brukerKontroll
«uses»
«uses»
*
«uses»
«uses»
Inntekt
Salg
____
retur av vare
administrasjon
«uses»
«uses»
endreBruker
System
Innlogging
__________
brukernavn og passord
kan være feil
*
*
«uses»
«extends»
*
vareRegister
*
«extends»
*
leggTilBruker
slettBruker
feilBruker
«extends»
*
*
returAvVare
*
«uses»
vareAdministrasjon
«uses»
«uses» *
*
*
*
*
*
innkjøp
sekretær
kunde
søk
Rapport generering
* *
*
Kunde
*
Selger
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.2
Figur 4.1
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.8
Figur 4.7
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:
Salg
Søk
Plantegning
Økonomi
Vareadministrasjon
Figur 2.1 Innkjøp
Administrasjon
flyt
Database
Alle undervinduer i
applikasjonen har direkte
oppkobling opp mot
databasen
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?
Hvor lett er det å
gjøre endringer i
programmet?
Figur 3.1
Flyttbar
het
Vedlike
holdsve
nnlig
Er de ønskede
funksjonene
tilgjengelige i
programmet?
Funksjo
nalitet
ISO
9126-1
Effektivi
tet
Hvor effektivt er
programmet?
Hvor stabilt /
pålitelig er
programmet?
Pålitelig
het
Brukerv
ennlig
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
*
Sekretær
Daglig leder
*
*
*
*
*
*
*
selger
dagligLeder
*
*
*
brukerKontroll
«uses»
«uses»
*
«uses»
«uses»
Inntekt
Salg
____
retur av vare
administrasjon
«uses»
«uses»
endreBruker
System
Innlogging
__________
brukernavn og passord
kan være feil
*
*
«uses»
«extends»
*
vareRegister
*
«extends»
*
leggTilBruker
slettBruker
feilBruker
«extends»
*
*
returAvVare
*
«uses»
vareAdministrasjon
«uses»
«uses» *
*
*
*
*
*
innkjøp
sekretær
kunde
søk
Rapport generering
* *
*
Kunde
*
Selger
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
AnsattID
Personnr
Etternavn
Fornavn
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
Primærnøkkel for entiteten
Ansatt. Unikt nummer for hver
enkelt ansatt
Er relevant for
lønnsutbetalinger og skatt hos
den ansatte
Oversikt over de ansattes
etternavn
Oversikt over de ansattes
fornavn
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
Ansatt
Automatisk generert av
MySQL
int(11), auto_increment Ingen
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
BestillingsID
LeverandOrID
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
Primærnøkkel for entiteten
Bestilling. Uniktnummer som
alle bestillinger får. Betydning
for bestillingsprosessen
Unikt leverandørnummer som
knyttes opp i mot en bestilling
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
15
char(4) ingen
Ansatt Hentes inn fra de ansatte varchar(11 ingen
Ansatt
Bestilling
Bestilling
Settes av administrator.
Fremmednøkkel fra
entiteten Bruker
Automatisk generert av
MySQL
Automatisk generert av
MySQL. Fremmednøkkel
fra entiteten LeverandOr
varchar(30) ingen
int(11), auto_increment ingen
int(11) ingen
Brukernavn
Primærnøkkel for entiteten
Bruker. Brukes ved pålogging
Bruker Settes av administrator.
varchar(30)
ingen
Passord Brukes ved pålogging Bruker Settes av administrator. varchar(30) ingen
Admin
Angir tilgangsnivå til bruker i
programmet.
Bruker Settes av adminstrator. char(1) ingen

Systemkravdokument BADR 5
Varenr
Antall_spor
Artist
Varenr
Aldersgrense
Bildeformat
Format
LeverandOrID
Navn
Kontonr
Post_nr
Primærnøkkel og
fremmednøkkel. Knytter cd
spesifikk informasjon opp imot
en vare i entiteten Produkt.
Har verdien som viser antall
spor det er på en cd
Navn på artisten til en cd.
Viktig om man søker på
artistnavn
Primærnøkkel og
fremmednøkkel. Knytter dvd
og blueray spesifikk
informasjon opp imot en vare i
entiteten Produkt
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
Cd
Cd
Cd
DVD_BlueRay
DVD_BlueRay
DVD_BlueRay
Automatisk generert av
MySQL
Cd platen eller eventuelt
leverandør
Cd platen eller eventuelt
leverandør
Automatisk generert av
MySQL
Leverandør eller
dvd/blueray platen selv
Leverandør eller
dvd/blueray platen selv
16
int(11) ingen
int(11) ingen
varchar(30) ingen
int(11) ingen
int(11) ingen
varchar(7) 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

Systemkravdokument BADR 5
Adresse
LokLagID
LokButID
Post_nr
Poststed
Varenr
EANKode
Format
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
Primærnøkkel for entiteten
Produkt. Unik identifikator et
produkt.
Unik identifikator for et
produkt
Avgjør hvilken type vare det
er. CD, DVD eller BlueRay
LeverandOrID Leverandøren varchar(30) ingen
LokasjonPALager
LokasjonIButikk
Post
Post
Produkt
Produkt
Bygget hos AS CD-
Magasinet.
Etasje og reoler hos AS CD-
Magasinet
Portalservice.no med
modifikasjoner fra BADR5
Portalservice.no med
modifikasjoner fra BADR5
Automatisk generert av
MySQL
Leverandøren eller selve
varen
17
varchar(30)
char(4) ingen
char(4) ingen
varchar(30) ingen
int(11), auto_increment ingen
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
InnkjOpspris
Avanse
Url eller relativ bane til bilde
av cover til cd, dvd eller
blueray
Prisen det koster å kjøpe inn
varen
Hvor mye mer en innkjøpspris
man ønsker å selge varen for i
prosent
Produkt
DVD og BlueRay: imdb.com
CD: amazon.com
varchar(250) ingen
Produkt Leverandøren int(11) ingen
Produkt
Innkjøper eller eventuelt
økonomisk ansvarlig
int(11) ingen

Systemkravdokument BADR 5
Beholdning
LeverandOrID
LokButID
LokLagID
Sjanger_navn
Varenr
BestillingsID
Antall
SalgsID
KundeID
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
Primærnøkkel og
fremmednøkkel fra entiteten
Bestilling. Knytter en bestilling
til et produkt
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
Produkt
Produkt
Produkt
Settes ved mottak av vare
og automatisk ved salg
Automatisk generert av
MySQL
Hardkodet inn ut i fra
plantegning
18
int(11) ingen
int(11) ingen
varchar(30) ingen
Produkt Antall etasjer varchar(30) ingen
Produkt
Leverandør eller
produktets embalasje
varchar(30) ingen
ProduktBestilling Innkjøper int(11) ingen
ProduktBestilling
Entiteten Bestilling, blir
automatisk generert for
hvert enkelt salg av MySQL
int(11) ingen
ProduktBestilling Innkjøper int(11) ingen
Salg
Salg
Automatisk generert av
MySQL
Automatisk generert av
MySQL
int(11), auto_increment ingen
int(11) ingen

Systemkravdokument BADR 5
AnsattID
TotalPris
Ar
Dato
Klokkeslett
Varenr
SalgsID
Antall
Sjanger_navn
Fremmednøkkel fra entiteten
Ansatt. Knytter ansatt opp i
mot null eller flere salg
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
Salg
Automatisk generert av
MySQL
Automatisk beregnet av
programmet.
19
int(11) ingen
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

Systemkravdokument BADR 5
5.2 Logisk Datamodell

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

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

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

Systemkravdokument BADR 5
LeverandOr
LeverandOrID Id Ndv INTEGER
Navn VARCHAR(30)
Kontonr 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
Bruker
LokLagID Id Ndv INTEGER
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.
Forklaring 6.2
Detter for å illustrere hvordan loadingen på programmet kunne
ha foregått, hvis programmet hadde vært mer omfattende
Figur 6.1 Login
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.
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.3 Kontrollpanelet
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.
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.7 Administrasjon
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.
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.9 Innkjøp
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
Forvaltningsdokumentasjon
- Hentet fra Mal Systemkravdokument
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.
_____________________ ____________________
Eskil E. Uglestad Håkon W. Engen
_____________________ ____________________
Sebastian Strømnes Fredrik Lundsrud
_____________________
Christoffer F. Lokrheim
Dato: 30.09.2009
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 Fikk utdelt oppgaven. Ordnet arbeidskontrakt. Fordelte oppgaver.
Prosjektstatus OK
Resultat Ferdigstilt timeliste og arbeidskontrakt.
Antall timer arbeid utført i uken 7 timer
Økonomi OK
Samarbeid OK
Problemer OK
Tiltak OK
Oppgaver neste uke 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
Gruppemøte med faglærer. Ferdig utkast av GUI og start laging av database. Startet
arbeid med brukerkravdokument
Antall timer arbeid utført i uken 38,5 timer
Økonomi OK
Samarbeid OK
Problemer
Tiltak
OK
Oppgaver neste uke
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
Kom fram til etter gruppemøte med Jan at det blir individuell vurdering av
prosjektkarakter pågrunn av ujavn arbeidsinnsats innad i gruppa
Oppgaver neste uke 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
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
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
7
Sum
uke
Sum
uke
Sum
uke

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
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
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
8
Sum
uke
Sum
uke
Sum
uke

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
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
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
9
Sum
uke
Sum
uke
Sum
uke

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 Godkjenning innkalling og saksliste
Sak nr 02 / 12.10 Gjennomgang av Arbeidskontrakt
Sak nr 03 / 12.10 Gjennomgang av Forstudierapport
Sak nr 04 / 12.10 Gjennomgang av Gannt Diagram
Sak nr 05 / 12.10 Kommentarer fra veileder
Sak nr 06 / 12.10 Prosjektstatus (framgang, gruppedynamikk, etc.)
Sak nr 07 / 12.10 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 Godkjenning innkalling og saksliste
Sak nr 02 / 26.10 Gjennomgang av Brukerkravsdokumentet
Sak nr 03 / 26.10 Gjennomgang av Utkast GUI
Sak nr 04 / 26.10 Kommentarer fra veileder
Sak nr 05 / 26.10 Prosjektstatus (framgang, gruppedynamikk, etc.)
Sak nr 06 / 26.10 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 Godkjenning innkalling og saksliste
Sak nr 02 / 09.11 Gjennomgang av Brukerkravsdokumentet
Sak nr 03 / 09.11 Gjennomgang av Utkast GUI
Sak nr 04 / 09.11 Kommentarer fra veileder
Sak nr 05 / 09.11 Prosjektstatus (framgang, gruppedynamikk, etc.)
Sak nr 06 / 09.11 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 Godkjenning innkalling og saksliste
Godkjent.
Sak nr 02 / 12.10 Gjennomgang av Arbeidskontrakt
Ble ikke gjort.
Sak nr 03 / 12.10 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.
Sak nr 04 / 12.10 Gjennomgang av Gannt Diagram
Endre Gant-diagrammet fra dager til timer.
Sak nr 05 / 12.10 Kommentarer fra veileder
Fikk en del innspill som er listet i sak 03.
Sak nr 06 / 12.10 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.
Sak nr 07 / 12.10 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 Godkjenning innkalling og saksliste
Godkjent
Sak nr 02 / 12.10 Gjennomgang av Brukerkravsdokumentet
Ingen tiltak.
Sak nr 03 / 12.10 Gjennomgang av Utkast GUI
Vær mer konkret når det gjelder brukergrensesnittet, blant annet at det skal lages i
VB. NET.
Sak nr 04 / 12.10 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 Prosjektstatus (framgang, gruppedynamikk, etc.)
Fortsett den gode progresjonen, men må vel fremdeles gjøre noe med fraværet som
bør reduseres.
Sak nr 06 / 12.10 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
1
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.
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 Christoffer
Gannt Diagram Eskil
Use Case Fredrik, revidert og redigert av Sebastian
Kost Nytte Sebastian
ISO modell Eskil og Christoffer
Timediagram Christoffer
Mal Timelister Håkon
Prototype Eskil
Mal Tilbakemld Christoffer
Grafisk ansvarlig 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
1
120
100
80
60
40
20
0
Eskil Sebastian Christoffer Håkon Fredrik
0 50 100 150 200 250 300 350
Fredrik
7 %
Håkon
10 %
Christoffer
31 %
Eskil
26 %
Sebastian
26 %
PRS
DB
VB
VB
DB
PRS