Hovedprosjekt 2011 Granitt Grafisk AS

Hovedprosjekt 2011 Granitt Grafisk AS

Forord Dette dokumentet er dokumentasjonen på vårt hovedprosjekt ved høgskolen i Oslo vår 2011. Dette dokumentet er en beskrivelse av prosjektet og produktet fra start i januar 2011 til slutt i juni 2011. Dokumentet inneholder prosessdokumentasjon, produktdokumentasjon, testdokumentasjon og brukerdokumentasjon, og tar for seg de fleste aspekter rundt disse temaene. Dokumentet er beregnet for sensorer, veiledere og evt andre som måtte ha interesse av å lese om hovedprosjektet vårt. Det forventes å ha grunnleggende kunnskaper om systemutvikling og datateknologi av de som skal lese dette dokumentet.

Innholdsfortegnelse Forord Innholdsfortegnelse 1. Del 1 - Prosessdokumentasjon 1.1 Forord 1.2 Innholdfortegnelse for prosessdokumentasjon 1.3 Innledning 1.3.1 Om prosjektet 1.3.2 Om oppdragsgiver 1.3.3 Om gruppen 1.3.4 Mål 1.4 Planleggingsfasen 1.4.1 Sammendrag 1.4.2 Valg og rammebetingelser 1.4.3 Valg av programmeringsspråk 1.4.4 Mål og rammebetingelsene 1.4.5 Kravspesifikasjon 1.4.6 Styringsdokumenter 1.4.7 Arbeidstid 1.4.8 Milepæler 1.4.9 Manual 1.5 Metode 1.5.1 Prototyping 1.6 Implementeringsfasen 1.6.1 Oppstart 1.6.2 Databasen 1.6.3 Javasystemet

1.7 Dokumentasjonsfasen 1.8 Testfasen 1.9 Erfaringer og resultat 2. Del 2 - Produktdokumentasjon 2.1 Forord 2.2 Innholdfortegnelse for produktdokumentasjon 2.3 Presentasjon av Granitt Kalkyle 2.3.1 Innledning 2.3.2 Beskrivelse 2.3.3 Systemkrav 2.4 Teknologier 2.4.1 Biblioteker 2.4.2 Verktøy 2.5 Systemet 2.5.1 Datalaget 2.5.2 Foretningslogikklaget 2.5.3 Presentasjonslaget 2.6 Brukergrensesnitt 2.6.1 Om designet 2.6.2 Design av administrasjonsgui 2.6.3 Design av kalkylegui 2.6.4 Design av utskriften 2.7 Sikkerhet 2.7.1 Datasikkerhet 2.7.2 Backup

2.8 Databasen 2.8.1 ER-diagram 2.8.2 Tabellbeskrivelser 2.9 Videreutvikling 2.9.1 Uteblivende funksjoner 2.9.2 Ideer til utvidelser 3. Del 3 - Testdokumentasjon 3.1 Forord 3.2 Innholdfortegnelse 3.3 Hvordan dokumentet brukes 3.4 Testcases 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.4.10 3.4.11 3.4.12 3.4.13 3.4.14 3.4.15 3.4.16 3.4.17 3.4.18 3.4.19 Logge inn til system Administrere tilbud Lage nytt tilbud Kalkulere pris Endre/vise tilbud Slette tilbud Filtrering av tilbud Administrere brukere Legge til bruker Administrere ark Legge til oppføring i prislisten Redigere oppføring Slette oppføring Laste opp ny prisliste Filtrere prisliste Administrere kunder Legg til kunde Endre kundeinfo Slette kunde 3.4.20 Filtrering av kunder

6. Del 4 - Brukerdokumentasjon 4.1 Forord 4.2 Innholdfortegnelse for brukerdokumentasjon 4.3 Brukermanual 4.3.1 Administrer brukere til systemet 4.3.1.1 Legg til bruker 4.3.1.2 Endre passord til bruker 4.3.2 Administrer arktyper 4.3.2.1 Legg til arktyper 4.3.2.2 Endre arktyper 4.3.2.3 Søk etter arktyper 4.3.2.4 Slett arktyper 4.3.2.5 Last opp ny prisliste 4.3.3 Administrer kunder 4.3.3.1 Legg til kunde 4.3.3.2 Endre kunde 4.3.3.3 Søk etter kunde 4.3.3.4 Slett kunde 4.3.4 Administrer tilbud 4.3.4.1 Lag nytt tilbud 4.3.4.2 Endre tilbud 4.3.4.3 Søke etter tilbud 4.3.4.4 Slett tilbud 4.3.4.5 Skriv ut tilbud 4.3.5 Hvordan fungerer tilbudsvinduet? 4.3.5.1 Felter og knapper 4.3.5.2 Valg av arktype

5. Vedlegg Vedlegg 5.1 Diagrammer 5.1.1 Use-case Granitt Kalkyle 5.1.2 Sekvensdiagrammer 5.1.3 Klassediagram 5.1.4 Relasjonsdiagram for database 5.1.5 Databasescript Vedlegg 5.2 Styringsdokumenter 5.2.1 Kravspesifikasjon 5.2.2 Fremdriftsplan 5.2.3 Logg 5.2.4 Møtereferater med veileder 5.2.5 Møtereferater med oppdragsgiver 5.2.6 Timelister 6. Oppslag/Kilder

HOVEDPROSJEKT 2011 HØGSKOLEN I OSLO GRANITT GRAFISK PROSESSDOKUMENTASJON

1.1 Forord Dette er prosessdokumentasjonen skrevet i forbindelse med vårt hovedprosjekt ved høgskolen i Oslo våren 2011. Dette dokumentet er en beskrivelse av prosjektperioden fra start i januar 2011 til slutt i juni 2011, med hovedfokus på arbeidsprosessen. Dokumentet er beregnet for sensorer, veiledere og evt andre som måtte ha interesse av å lese om arbeidet vi har lagt ned i forbindelse med hovedprosjektet vårt. For informasjon om produktet, testing og/eller bruk av produktet henvises det til produktdokumentasjonen, testdokumentasjon og brukerdokumentasjon som følger dette dokumentet. Det forventes å ha grunnleggende kunnskaper om systemutvikling og datateknologi av de som skal lese dette dokumentet.

1.2 Innholdsfortegnelse for prosessdokumentasjon 1.1 Forord 1.2 Innholdfortegnelse for prosessdokumentasjon 1.3 Innledning 1.3.1 Om prosjektet 1.3.2 Om Oppdragsgiver 1.3.3 Om gruppen 1.3.4 Ønsket resultat 1.4 Planlegging 1.4.1 Sammendrag 1.4.2 Valg og rammebetingelser 1.4.3 Valg av programmeringsspråk 1.4.4 Mål og rammebetingelser 1.4.5 Kravspesifikasjon 1.4.6 Styringsdokumenter 1.4.7 Arbeidstid 1.4.8 Milepæler 1.4.9 Manual 1.5 Metode 1.5.1 Prototyping 1.6 Implementeringsfasen 1.6.1 Oppstart 1.6.2 Databasen 1.6.3 Java systemet 1.7 Dokumentasjonsfasen 1.8 Testfasen 1.9 Erfaringer og resultat

1.3 Innledning 1.3.1 Om prosjektet Granitt grafisk er et design og trykkefirma, etablert i Gran på Hadeland. Granitt Grafisk har vært på utkikk etter et administrasjonsverktøy for å effektivisere arbeidet sitt i forhold til kalkyler av sine tjenester. En kalkyle tar lang tid da det inngår mye regning og forståelse bak. De har per dags dato hatt et stort tidsproblem med å slå opp i produktkataloger, da det også går mye tid bort i å slå opp. De har funnet en god del løsninger på nett, men disse løsningene var veldig dyre, noe som er lite aktuellt for bedriften. Oppdragsgiver har bedt om en løsning som kalkulerer kalkyler av grafiske tjenester med enkelt tilgang til produktene digitalt. Produktleverandøren leverer også katalogen sin digitalt. Granitt Kalkyle er et gratis alternativ med et enkelt grensesnitt, som ikke krever større forståelse av data for bruk. Systemet kan kalkulere tilbuder, samt administrere disse. Kalkylen baseres på kundeinformasjon og produktinformasjon, derfor er det mulighet for administrering av dette. Det er mulig å importere data fra excel fil for produktinformasjon. All data blir lagret i en sql database. Systemet har også støtte for innlogging, for sikkerhetens skyld og for signering av kalkyler. 1.3.2 Om oppdragsgiver Vår Oppdragsgiver i dette hovedprosjektet har vært Granitt Grafisk. Granitt Grafisk as ble opprettet sommeren 2007, og eies av Paul Rief, Finn Halland og Kjetil Hansen. Navnet Granitt Grafisk bygger på to ting. Vi ville ha et navn som knytter oss geografisk til Gran. Den andre tingen var å bygge en assosiasjon til vår kompetanse og kunnskap ved å benytte en metafor. Granitt er en steinart som er sterk og holdbar. Dermed ble det navnet Granitt Grafisk. Vår forretningsidé er veldig enkel: Levere grafiske tjenester av meget høy kvalitet. Vår styrke er meget høy kompetanse, effektivitet og lave kostnader.1 1 Granitt grafisks hjemmeside www.granittgrafisk.no

1.3.3 Om gruppen Gruppen består av tre medlemmer, Joakim Haneberg Johansen, Michael Venables og Pål Georg Dahl Myran. Vi valgte å jobbe sammen i hovedprosjektet fordi vi har jobbet sammen flere ganger før i utdanningstiden, og i tillegg kjenner vi hverandre fra før av og kjenner derfor hverandres arbeidsvaner. Gruppen ble kontaktet høsten 2010 av Granitt grafisk da de var bekjent av Pål. Vi var på jakt etter et prosjekt da Granitt grafisk tilbød seg å være oppdragsgiver. Oppgaven så utfordrende ut samtidig som vi fikk en del ideer om hvordan dette kunne løses. 1.3.4 Mål Vårt mål med dette prosjektet var å utvikle et kjørbart system for kalkulering og administrering av de forskjellige aspektene ved en kalkyle.systemet skal også ta hensyn til de tekniske utregningene som er nødvendig for en komplett kalkyle. Hovedfokuset på systemet lå i å forenkle og spare tid på å kalkulere tilbuder. Systemet skulle utvikles med hensyn på en digital produkttabell, og et enkelt grensesnitt da enkelte av brukerene har mindre datakunnskaper. At systemet skulle stille til alle funksjonalitetene som var beskrevet i kravspesifikasjonen. På det personlige planet var målet å utvikle oss og tilegne oss erfaring med å jobbe i prosjekt, og kunnskaper om teknologier vi ikke kunne mye om.

1.4 Planleggingsfasen Denne delen av rapporten omhandler perioden fra 06.01.2011-04.02.2011. Dette er perioden fra vi startet prosjektet og frem til implementeringsfasen. 1.4.1 Sammendrag Med Granitt Grafisk som oppdragsgiver skal gruppen utført et hovedprosjekt, ved høgskolen i Oslo ingeniøravdelingen, der målet er å utvikle et kalkylesystem for bedriften, som kalkulerer priser og tilbuder, for å unngå mye tap av tid og resursser. Det er også hensiktsmessig for å slippe å sitte med kalkylene i papirformat, og gi mulighet til å gå tilbake i tid(historikk). 1.4.2 Valg og rammebetingelser Etter at oppgaven fra Granitt grafisk ble valgt, ble vi enige med bedriften om å ha et møte, i deres lokaler på Gran på Hadeland, der vi skulle diskutere kravene og rammene til systemet. Vi kom frem til en god del av rammene og målene vi skulle ha til prosjektet. Møtet hadde god progresjon og vi fikk et godt overblikk over hvordan vi ville bygge opp systemet, etter deres premisser. 1.4.3 Valg av Programmeringsspråk Etter valget av prosjektet lå det ingen krav på hvilke programmeringsspråk vi skulle bruke. I perioden fra vi fikk prosjektet og litt ut i forprosjektperioden brukte vi en del tid på å utforske de forskjellige teknologiene som passet systemet. Vi kom opp med at vi enten kunne utvikle et nettbasert system eller et stasjonært system. Vi konsulterte Granitt grafisk med dette og ble enige om at et stasjonært system ville passe best for dem. Dette var fordi systemet skulle kalkulere et ferdig produkt og dermed vil en del av den informasjonen som kalkuleres ikke oppgis til kunden. En annen grunn er fordi at det er de ansatte som skal kalkulere tilbudet og ikke kunden selv, og dermet er det ikke behov for et nettbasert system. Vi endte til slutt opp med å gjøre prosjektet med Java som programmeringsspråk, som alle på gruppen har god erfaring med, da dette var en del av utdanningen vår. I samsvar med at vi hadde valgt å bruke database som lagring, valgte vi å ta med et litt annet aspekt av java, Java Database Connectivity(JDBC). Dette var helt nytt for oss alle.

1.4.4 Mål og rammebetingelsene Som nevnt tidligere ble målene og rammebetingelsene bestemt hovedsaklig under det første møtet. Bedriften hadde en ide om hvordan systemet skulle se ut, og vi diskuterte og kom til enighet om hva og hvordan ting skulle gjøres. En del rammer ble også satt av skolen. Rammebetingelser Utvikles i Java med JDBC Utvikles til bruk i Windows Lokalt system Prosjektperiode på fem måneder Mål Opparbeide erfaring med arbeid i prosjekt. Opparbeide erfaring med nye og gamle teknologier og samskjøre disse( Java, JDBC, mysql). Levere et godt og kjørbart system, som tilfredsstiller Granitt grafisk's krav. Granitt grafisk hadde kun en rammebetingelse å komme med. Det var at vi hadde jevnlige møter, slik at de kan se hvordan systemet ble underveis, og være med på å forme systemet slik de ville ha det. Dette syntes vi også var en god idè. 1.4.5 Kravspesifikasjon Under det første møtet ble vi enige om noen av de mest grunnleggende kravene. Vi hadde også flere møter i løpet av planleggingsfasen, kom frem til en del krav. Vi valgte å holde kravene åpne siden bedriften ville være med å styre hvordan utviklingen skulle gå underveis, og dermed ville en del av kravene forandre seg underveis som hva bedriften så og fikk intrykk av. Funksjonalitet,systemkonstruksjon og dokumentasjonskrav ble definert av gruppen selv, under diskusjon med de ansatte i Granitt grafisk. Kravene ble definert slik at bedriften og gruppen skulle få et bedre innblikk i hvordan det komplette systemet faktisk skulle se ut. Systemet ble bestemt at skulle inneholde to hoveddeler, Selve kalkyledelen og Administrasjonsdelen. Se vedlegg 5.2.1(kravspesifikasjon).

1.4.6 Styringsdokumenter Det første gruppen startet med i forbindelse med Planleggingsfasen var å sette opp en kortfattet arbeidsplan i grove trekk og en fremdriftsplan i sammenheng med arbeidsplanen. Følgende styringsdokumenter følger som vedlegg: Kravspesifikasjon Arbeidsplan og fremdriftsplan Loggbok Møtereferater med veileder Møtereferater med oppdragsgiver Timeliste Forprosjektrapport Prosjektskissen se vedlegg 5.2.1 se vedlegg 5.2.2 se vedlegg 5.2.3 se vedlegg 5.2.4 se vedlegg 5.2.5 se vedlegg 5.2.6 se prosjektsiden. se prosjektsiden. Beskrivelse av hvert dokument følger under. Prosjektsiden finner du på adressen: www.stud.iu.hio.no/~s156152 Kravspesifikasjonen er beskrevet tidligere i dokumentet. Arbeidsplanen og fremdriftsplanen ble også utviklet i sammenheng med forprosjektet. Arbeidsplanen ble bare en grov skisse over hvilke elementer som måtte være med i prosjektets omfang. Denne ble kortfattet, men ga oss hjelp til å utvikle fremdriftsplanen. Fremdriftsplanen ble det lagt en god del tid i, da dette skulle vise seg å være et viktig verktøy under prosjektperioden. Fremdriftsplanen hjalp oss å sette tiden i perspektiv og holde de "deadlinene" vi satt for oss selv. Dette gjorde også at vi jobbet mer effektivt, da vi hadde tidspress på oss. Loggboken har blitt oppdatert underveis i prosjektet. Der er det blitt oppført alt som var av interesse for gruppen under prosjektperioden. Alt fra detaljer i programmet til arbeidsperioden etc. Hensikten med dette dokumentet er å gi oss muligheten til å gå tilbake å se på problemer og ideer som er kommet opp underveis. Dermed kunne vi bruke dette når ting skulle rettes opp eller vi skulle bruke dette til dokumentasjonen. Referater. Ved hvert møte med veileder/ oppdragsgiver ble det tatt referater. Dette var hovedsakelig for å kunne gå tilbake til ideer og problemer som ble diskutert. Dette dokumentet var til stor hjelp for gruppen, da all sammarbeid og diskusjon med bedriften ble holdt muntlig. Dette gav oss muligheten til å bearbeide og forstå utregninger og begreper i senere tid.

Timeliste. Gruppen satt opp en timeliste, for å holde oversikt over tiden, som skulle stemme overens med fagets omfang. Timelisten ble utfyllt en gang i uken etter de arbeidstidene som ble satt opp i dagboken. Forprosjektet. Etter de første møtene var det tid for forprosjektet. Dette skulle resultere i en rapport. Rapporten var et resultat av undersøkelsene vi gjorde hos oppdragsgiver, der vi tok for oss dagens situasjon for bedriften. Vi satte oss inn i problemstillingen og fikk et overblikk over hvordan problemet skulle løses. Prosjektskissen ble påbegynnt i november. Dokumentet hadde leveransefrist. Prosjektskissens hensikt er å gi et kortfattet men konsistent overblikk over problemstillingen og situasjonen hos oppdragsgiver. Gruppen har har løst problemer og oppgaver slik som beskrevet i styringsdokumentene, med andre ord har mindre problemer ikke blitt forelagt veilederen. 1.4.7 Arbeidstid Vi har fra første stund vært opptatt av å styre arbeidet med prosjektet mest mulig likt en reell jobbsituasjon bl.a for å forberede oss til arbeidslivet. Derfor har vi satt oss faste arbeidsdager, med faste arbeidstider. Alle på gruppen har jobber ved siden av studiene, men med litt organisering gikk dette greit. Alle på gruppen matematikk som valgfag i tillegg til hovedprosjektet. Derfor ble det satt av et par timer hver mandag og torsdag til arbeid med valgfag. I grove trekk ble timeplanen som følger: Mandag: Tirsdag: Onsdag: Torsdag: Fredag: 10.00-14.30 10.00-16.00 10.00-16.00 10.00-14.30 10.00-16.00 En del untak har forekommet under arbeidsperioden, som å komme senere og jobbe lengre.

1.4.8 Milepæler Underveis i prosjektet avtalte vi med oppdragsgiveren at vi skulle ha et par milepæler, slik at de kunne se og vurdere det vi hadde så langt. Vi satte oss da mål om hvor langt vi skulle komme i prosessen, frem til disse milepælene. 1.4.9 Manual Grunnet lite kompetanse hos enkelte av de ansatte i bedriften, og for å informere de ansatte om funksjonaliteten til systemet, har vi valgt å lage en detaljert brukermanual. Manualen tar for seg funksjonene i systemet og hvordan man styrer seg frem til disse. Se brukerrapporten for utdyping.

1.5 Metode Vi har ikke spesiellt fulgt noen utviklingsmetoder, men ettersom oppdragsgiver var interessert i å se produktet underveis, så fallt arbeidsmetoden vår automatisk tilbake på prototyping. 1.5.1 Prototyping En prototype er en utviklingsmodell bygget for å teste produktet og for å finne feil og forandringer man kan lære av. Produktet blir en alfaversjon der bare få deler av systemet er tatt med per versjon. Utviklingen foregår i følgende syklus: Figur 1.5.1-1: skisse av Prototypingmodellen Visualiser er fasen der forståelse av brukeren og dens behov, og kartlegge disse. Implementer er fasen der du utvikler en prototype for å teste de løsningene utviklingen har kommet frem til. Evaluer er fasen der du får tilbakemelding på prototypen fra brukeren. Det er viktig å forstå at evalueringen må dekke kundens krav, så fremt dette er mulig. Denne metoden er for å ha et kjørbart produkt til en hver tid i prosjektperioden. Hvis det skulle oppstå problemer med prosjeketet, vil da kunden ha et produkt, som de kan bruke eller videreutvikle i senere tid.

1.6 Implementeringsfasen Denne delen av rapporten tar for seg perioden fra 04.02.2011 21.04.2011. Denne fasen har varighet fra Planleggingsfasens slutt og til dokumentasjonsfasen. Denne fasen tar for seg databasebehandling, programmering, testing og debugging. 1.6.1 Oppstart Etter en måned med planlegging og dokumentasjon, var gruppen spesielt engasjerte i å sette i gang med programmeringen. Gruppen følte seg godt forberedt på å utvikle, med et godt innblikk på hvordan systemet skulle se ut. Vi så tidlig fordelen med det grundige arbeidet vi hadde lagt ned i planleggingsfasen, og vi hadde stort sett alltid noe å se tilbake på når det oppstod usikkerheter. 1.6.2 Databasen På grunn av den store mengden data vi skulle lagre var det første vi måtte ha på plass, en database for lagring av all dataen. Dataen vi hadde å jobbe med var gitt i en stor excel fil, så databasestrukturen var nesten gitt på forhånd. I tillegg til tabellen med arktypene, så skulle vi implementere tabeller med brukere, kunder og kalkyler. Vi satt opp en logisk databasemodell( se vedlegg 5.4.1) på hvordan vi ville ha databasen vår, for så å implementere en testdatabase på vår egen server.

1.6.3 Java systemet Før vi startet å programmere, måtte systemet modelleres. I dette la vi mye tid og arbeid. Vi startet opp med å lage en detaljert use-case av hele systemet. Use-case er en beskrivelse av alle hendelsene som skjer i systemet. Dette brukes for å planlegge hvordan sekvensene i systemet skal legges. Etter use-casene var mer eller mindre klare startet vi på å lage et sekvensdiagram av casene. Sekvensdiagram er en beskrivelse av rekkefølgen på hendelser i programmet, og er en forberedelse til et klassediagram. Underveis i prosessen måtte vi ofte gå tilbake å endre på use-casene, da vi fikk et bedre perspektiv på systemet. Etter use-casen og sekvensdiagrammet var ferdig stod bare klassediagrammet igjen. Klassediagrammet brukes som et logisk kart over hvordan de forskjellige klassene i programmet henger sammen. Figur 1.6.3-1: Klassediagram av Granitt Kalkyle( forenklet versjon).

Da modelleringen var i god gang startet vi å programmere. Vi var ganske ivrige på å starte, da vi hadde lagt så mye arbeid i å planlegge. Vi programmerte med hensyn på prototyping. Etter tre uker var den første alpha versjonen ute. Den inneholdt administrasjonsdelen og grensesnittet til kalkyledelen. Denne versjonen inneholdt mange bugs og det skulle mange endringer til før versjon to var klar. Vi hadde på forhånd avtalt å holde et møte med bedriften, og vi ble enige om at dette var et passende tidspunkt. Etter møtet med Granitt grafisk fikk vi kunngjort endringene vi måtte utføre og fikk en peker på hvordan videre utvikling ville bli. Etter ca to uker med videre arbeid på systemet, begynte vi på selve kalkyleutregningen. På forrige møte med bedriften bestemte vi oss for å prøve å ta med at programmet selv skulle beregne antall ark som trengs før behandling ved gitte detaljer om hvordan opplaget skulle være. Hvis vi ikke fikk tid skulle vi bare legge tekstfelter så det bare var å fylle inn informasjon. Grunnen til at vi kun skulle "prøve" oss på dette var fordi det ligger mye forståelse og utregning, og mange detaljer å ta hensyn til. Blandt annet fiberretning på arket og om du skal skjære et større ark for å utnytte mest mulig av dette osv. Vi satte oss først ned og lagde en kalkyle for hånd etter bedriftens oppskrift. Deretter regnet vi oss frem til en formel for arkutregningen. Dette tok nesten en hel uke. Vi implementerte så dette i programmet, og fant tilfellene som ikke ble tatt med. To uker før påske ble det et nytt møte med Granitt grafisk, nå for å vise frem den nye og forhåpentligvis den siste versjonen av programmet.

1.7 Dokumentasjonsfasen Denne delen av prosessrapporten handler om utformingen av de ulike rapportene. Den siste uken før påsken før påske innså vi at vi hadde litt knapp tid til dokumentasjonen. Derfor begynnte vi allerede denne uken med å sette opp dokumentene parallellt med den siste "finishen" på utviklingen. Vi hadde allerede skrevet mye dokumentasjon tidligere i prosjektperioden og vi følte derfor at vi hadde en god mengde materialer å jobbe ut i fra. Allerede før påske hadde vi kommet så vidt det var i gang med dokumentasjonen. Grunnet andre eksamener kunne vi ikke legge så mye arbeid i prosjektet i uken før påsken og i påsken. Derfor valgte vi å starte litt før med dokumentasjonen, slik at vi hadde et godt grunnlag til vi skulle begynne. Til å begynne med delte vi opp rapporten i ulike deler, slik at arbeidet fremover kunne være noe mer uavhengig enn før. Dette ble godt utnyttet, da gruppemedlemmene kunne jobbe klarere hjemme hver for seg, for så å sammenslå de de hadde arbeidet med. Alle på gruppen hadde forskjellige måter å skrive på, men det er blitt lagt mye vekt på konsistens i form av like konvensjoner og referanser. Det ble også lagt mye vekt på godt språk. Oppdatering internt i gruppen på hva som hadde blitt gjort fra gang til gang, og intern korrektur har vært med på å la dette bli gjennomført. Vi har lagt stor vekt på lesbarheten i dokumentet. For at det skulle bli Enkelt og lettforståelig, men samtidig spennende på en akademisk måte, tok vi i bruk en del illustrasjoner og figuerer, for å utrykke oss.

1.8 Testfasen Dette kapittelet omhandler testfasen i prosjektet, og hvordan dette ble utført. Ved nesten hvert møte med Granitt Grafisk hadde gruppen en tidlig prototype som vi kunne vise bedriften. Ved disse møtene fikk vi gode tilbakemeldinger som vi brukte for å rette opp feil og forbedre systemet. I tillegg implementerte vi en betaversjon av Granitt Kalkyle hos Granitt Grafisk for testing, uken før påske. Dette fikk vi tilbakemeldinger på og brukte videre i debugging av systemet. Ukene etter påske fikk vi fullført use-casene komplett, med alle de funksjonene som ikke stod på kravspesifikasjonen. Dette brukte vi som grunnlag for å lage en testrapport. Denne rapportene baserte seg på use-casene ved vanelig flyt og de spesielle flytene vef hver eneste use-case. Dermed fikk vi dekken alle eventuelle hull og feil i koden ved de funksjonelle delene. De fleste mulighetene for å skrive feil informasjon i feltene var dekket under utviklingen. Dermed brukte vi ikke mye tid på å teste på feil "inputs".

1.9 Erfaringer og resultat Gruppen har i løpet av prosjektsperioden utviklet og levert et produkt som oppfyller den kravspesifikasjonen vi selv har utarbeidet i sammarbeid med vår arbeidsgiver. Problemer og utfordringer underveis har blitt løst på en systematisk og fornuftig måte, og både arbeidsgiver og gruppen selv er svert fornøyd med sluttresultatet. Gruppen har satt fokus på en jevn arbeidsflyt, og fordelt jobben utover prosjektets arbeidsperiode. Vi har også et timeantall som er fordelt jevnt og svarer til fagets studiepoeng. Gruppen har lagt vekt på å simulere et "virkelig" prosjekt, og annså da tidsfordelingen som en viktig del av arbeidsstrategien. Dersom det hadde vært mer tid tilgjengelig hadde vi implementert utvidelsene som står beskrevet i produktrapporten. Prosessen har fokusert hovedsakelig på dokumentasjonen, men også på implementeringen. Skulle ting vært gjort annerledes ville vi kanskje brukt litt mer tid på planleggingen av programstrukturen, da vi måtte endre en del underveis i programmeringen. Vi løste dette, men tapte en del arbeidstimer på dette. Men tiltross for dette hadde vi ellers et godt grunnlag, da forprosjektet var grundig gjort og sparte oss mye tid på implementeringen av programmet.

HOVEDPROSJEKT 2011 HØGSKOLEN I OSLO GRANITT GRAFISK PRODUKTDOKUMENTASJON

2.1 Forord Dette er produktdokumentasjon skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo våren 2011. Dokumentet beskriver systemet Granitt Kalkyle med hovedfokus på den tekniske utførelsen av systemet. Dokumentet er beregnet for sensorer, veiledere og andre personer som måtte ha interesse av å lese om hvordan Granitt Kalkyle er bygd opp. Det anbefales å lese prosessdokumentasjonen før du tar for deg denne delen. Med dette dokumentet vil vi prøve å beskrive omfanget og den datatekniske vansklighetsgraden av prosjektet. Forutsetningen til leseren av dette dokumentet er at leseren har grunnleggende kompetanse innen programmering og datateknologi. Dermed følger kjennskap til ord og fagspesifikke utrykk innen disse feltene. En del fagutrykk kommer også fra grafisk og trykkeri bransjen.

2.2 Innholdfortegnelse for produktdokumentasjon 2.1 Forord 2.2 Innholdfortegnelse for produktdokumentasjon 2.3 Presentasjon av Granitt Kalkyle 2.3.1 Innledning 2.3.2 Beskrivelse 2.3.3 Systemkrav 2.4 Teknologier 2.4.1 Biblioteker 2.4.2 Verktøy 2.5 Systemet 2.5.1 Datalaget 2.5.2 Foretningslogikklaget 2.5.3 Presentasjonslaget 2.6 Brukergrensesnitt 2.6.1 Om designet 2.6.2 Design av administrasjonsgui 2.6.3 Design av kalkylegui 2.6.4 Design av utskriften 2.7 Sikkerhet 2.7.1 Datasikkerhet 2.7.2 Backup 2.8 Databasen 2.8.1 ER-diagram 2.8.2 Tabellbeskrivelser 2.9 Videreutvikling 2.9.1 Uteblivende funksjoner 2.9.2 Ideer til utvidelser

2.3 Presentasjon av GranittKalkyle 2.3.1 Innledning Hva er granitt Kalkyle? Hvordan er det bygd opp? Hvilke deler består det av? Dette er spørsmål som dette dokumentet dekker. Det vil ta for seg løsningene vi valgte og hvorfor vi valgte disse. Granitt kalkyle er et middels-stort program som er programmert i Java. Med ca 10000 linjer med kode fordelt på 18 klasser er det vanskelig å gi et raskt overblikk. Derfor har vi valgt å beskrive systemet lagvis, med funksjonaliteten i fokus. Vi har også brukt diagrammer og use-cases som beskrivelse av systemet. 2.3.2 Beskrivelse Målet med dette prosjektet har vært å lage et kalkyleverktøy som forenkler kalkyleutregningen på trykk av grafiske tjenester til Granitt grafisk. Dette verktøyet har fått navnet GranittKalkyle og innehar bl.a følgende funksjoner: Legge til brukere: Det kan i programmet legges til flere nye brukere av systemet, slik at granittkalkyle enkelt kan kunne benyttes av flere. Denne informasjonen brukes også til utskriften for å informere om hvilke ansatte som har laget den gitte kalkylen. Kundeadministrasjon: Granitt grafisk kan ved hjelp av granittkalkyle lagre kontaktinformasjon for kunder som ønsker en grafisk tjeneste. Administrasjonen tillater å endre eller å slette kunder. Informasjonen er gjort søkbar for at Granitt Grafisk kjapt skal kunne hente ut data fra tidligere kunder. Produktadministrasjon: Ved hjelp av granittkalkyle kan Granitt Grafisk enkelt hente ut data om produkter fra sin hovedleverandør papyrus. Den dataen kan endres eller slettes, og det kan legges inn nye oppføringer. Ved å laste ned papyrus sin produktkatalog kan GranittKalkyle brukes til å oppdatere produktdatabasen, og dermed forenkle kalkyleprosessen. Informasjonen her er også gjort søkbar, slik at man slipper å lete igjennom den lange tabellen av produkter.

Kalkyleadministrasjon: Ved utregning av kalkyle i granittkalkyle slipper du de tunge utregningene ved Grafisk trykk. Da er det bare å fylle ut informasjonen som trengs, så gjør programmet det for deg. Her er det også lagt inn muligheten for å gå inn å se på gamle kalkyler. Søking gjør det enklere å slå opp hvis det er mange kalkyler å se igjennom. Historikk: GranittKalkyle har oversikt over alle kunder, produkter og kalkyler som lagres i systemet og holder en historikk på dette. På denne måten Kan Granitt Grafisk raskt skaffe seg oversikt over hvilke kalkyler de har tilbudt til hvilke kunder, og hvilke produkter disse innnebærer. 2.3.3 Systemkrav GranittKalkyle er bygd opp i Java og krever at du har installert Java JRE eller JDE versjon 5 eller nyere. GranittKalkyle er ikke spesiellt resurskrevende, og det er derfor ikke nødvendig med en spesiellt kraftig datamaskin, men på grunn av mye datalagring anbefales det å ha minimum 512MB. Noe databehandling, med unntak av opplastning av ny prisliste til databasen og utregning av pris er grunnen til minnebruket. Det anbefales å ha en skjærmoppløsning på 1280*800 eller større, da det er mye informasjon som vises på skjærmen av gangen. Som annet krav anbefales det å ha en pdf-converter som skriver, da dette gir en mye penere utskrift av kalkylen.

2.4 Teknologier I de neste delkapittelene vil vi presentere de forskjellige teknologiene og verktøyene vi har brukt under utviklingsprosessen. 2.4.1 Biblioteker Vi har brukt mange forskjellige biblioteker til det ferdige produktet av Granitt Kalkyle. De aller fleste bibliotekene medfølger i JRE( JavaSE 1.6), men vi har brukt et par biblioteker forutenom disse: Java Excel API: Er hentet fra http://www.java2s.com/ Lisens: GNU Library or Lesser General Public License(LGPL) Dette er et bibliotek som muligheten for å lese fra og skrive til Microsoft Excelark. I vårt tilfelle er dette biblioteket brukt for å lese et Excelark, for deretter å konvertere tabellen i Excelfilen til en database. Forutsetningen for dette er at excelfilens tabell er på en spesifisert form som er lik den formen databasen har, og at informasjonen i tabellen har gyldige verdier. "Exceptions" i henhold til dette er tatt hensyn til. JDBC( Java DataBase Connectivity API) type 4 driver: Er hentet fra http://www.mysql.com/ Lisens: GNU General Public License, version 2 Dette er en databasedriver som konverterer JDBC kall direkte til databasen. Dette er også kalt en "tynndriver". Denne teknologien kommuniserer via socketer og trenger ingen translasjon mellom driver og database. Den er også platformuavhengig. JDBC driveren brukes for kommunikasjon mellom java aplikasjonen og databasen.

2.4.2 Verktøy Vi har brukt en rekke verktøy i utviklingen vår: MySQL workbench: Et verktøy vi brukte for å lage ER diagrammer. Vi valgte å bruke dette verktøyet fordi det gir en enkel oversikt og vi har erfaring med det fra tidligere prosjekter. MySQL community server: Grunnet at vi har hatt erfaringer med mysql tidligere, og at vi trengte en gratis, fritt tilgjengelig database som vi kunne kjøre på testserveren våres, valgte vi dette verktøyet. Den er svært enkel å sette opp på alle platformer. Tilkobling til mysql server gjør databasehåndtering svært enkel da serveren håndterer generering av tabeller etc. Eclipse: Eclipse er vårt valgte IDE( Integrated Development Enviroment). Grunnen til dette valget var fordi vi tidligere har utviklet i dette, og vi følte oss trygge på det. Det er lett å utvikle og teste java i Eclipse, og det er enkelt å forstå feilmeldinger. Putty: Putty er en opensource terminal emulator, som virker som en klient for ssh, telnet osv. For oss har putty fungert som et mellomledd, ved testing og redigering på serveren og databasen. VioletUML: VioletUML er et UML( Universal Modelling Language)-verktøy, som brukes for å modellere data-applikasjoner og programmer. Dette verktøyet fant vi veldig enkelt og brukervennlig, da vi skulle lage use-cases, sekvensdiagrammer og klassediagrammer. OpenOffice 3.1: Vi har brukt Calc- og Writer-delen av OpenOffice under prosjektets gang til å dekke behovene våre for tekstbehandling og regneark. Regnearket er brukt for å lage planer osv, mens tekstbehandlingen dekket dokumentasjonen.

2.5 Systemet Granitt Kalkyle er delt inn i 3 deler. Disse er betegnet som "lag" og inneholder følgende: Datalaget: Inneholder alle klasser som ordner og konverterer dataen slik at det er klart til behanling etterpå. ForetningslogikkLaget: Den delen av systemet som håndterer selve kalkuleringen av de nødvendige dataene. PresentasjonsLaget: GUI klasser som gjør det mulig å visualisere og bruke systemet. Figur 2.5-1: Lagvis skjema for Granitt Kalkyle

2.5.1 Datalaget I det nederste laget mot SQL-databasen finner vi klassene som ordner og konverterer dataene til nødvendige formater. Se figur 4.5-1. Laget jobber opp mot SQL-databasen og fungerer som et slags mellomledd mellom databehandlingen og databasen. For databaseskjema, se vedlegg 5.4.1. Datalaget inneholder klassene "handledb" og "readexcel"(se javadoc, prosjektsidenwww.stud.iu.hio.no/~s156152). Dette laget kan igjen deles inn i to underlag, databaselaget og excellaget. Excellaget består av en klasse "readexcel", som kommuniserer med et excelbibliotek. Hensikten med dette laget er å konverterer en excelfil til databasen. Filen filtrerer ut data og legger dette i tabeller som samsvarer med det som er definert i systemet. Databaselaget kommuniserer med databasen og lagrer, endrer eller fjerner data, alt etter hva som er ønskelig. Dette laget består av en klasse, "handledb", som kommuniserer med et bibliotek. Biblioteket er som nevnt tidligere en databasedriver som konverterer JDBC kall til databasebehandlinger. Denne driveren ligger i systemet og konverterer dataen til og fra databasen, slik at du ikke trenger noe mellomledd. 2.5.2 ForretningslogikkLaget Foretningslogikklagets hensikt er å kalkulere en kalkyle, basert på fremgangsmåten til Granitt Grafisk. Dette er satt som et eget lag fordi den ikke skal være avhengig av presentasjonslaget, men kun av datalaget. Med dette mener vi at all data skal kunne behandles hvis de kommer igjennom presentasjonslaget, og at foretningslogikken skal ta for seg alle tilfeller av kalkulering som måtte forekomme. Forretningslogikken er kun satt i en klasse. Denne klassen tar de innkommende prisene for ark, etterbehandling, farger etc, og regner ut totalsummen med hensyn på antall opplag og arbeidstimer. Grunnlaget for utregningen ligger i størrelsen på trykkmaskinen til Granitt Grafisk. Grunnet at de har begrenset størrelse på trykkmaskinen, er det enkelte ganger mer økonomisk for dem å gå til innkjøp av ark i større dimensjoner enn maskinen deres, for så å dele arkene opp selv. Kalkulasjonen tar for seg alle størrelser og dimensjoner på den valgte arktypen og regner da ut den mest økonomiske størrelsen å kjøpe inn for det valgte antall opplag.

Prisalgoritme prisalgoritmen kalkulerer ut den endelige prisen på ett produkt rundet opp til nærmeste heltall. Det ferdige produktets størrelse regnes om til en størrelse som går opp i et default A+ format, som er det formatet trykkmaskinen til oppdragsgiver håndterer, slik at programmet kan regne ut det formatet som trengs. Dette formatet har størrelse 450x320 mm. Antall trykkplater, etterbehandlingspris, faste priser på arbeidstid som går med til trykking, og designtid er nødvendig informasjon for å regne ut prisen. Systemet regner alltid med hensyn på det billigste alternativet, men det er ikke alltid dette er det beste alternativet til bedriften. En spesiell funksjon som ikke er med en bedre utnyttelse av ark ved trykking på 2 sideflater på en gang. Dette går bare på ark som skal bare trykkes i 2 sider. Vanskelig å implementere ettersom det foregår i et begrenset antall ordre. Denne teknikken kalles på fagspråket "omslagning". Fiberretningen på arket er også en viktig faktor i utregningen. Fiberretningen er den veien alle fibrene ligger i arket. Hvis arket skal brettes skal det alltid brettes langs fiberretningen. Hvis fiberretningen brytes vil brettekanten til arket få en stygg utstående kant, og blir da uprosfesjonellt og stygt å se på. Det blir også et problem hvis du har et produkt på flere enn 4 sider, da det er behov for sammenstifting i de ødelagte kantene. Dette er det også tatt hensyn til i programmet. Systemet regner ut algoritmen i 5 ledd: 1. Først finner den ut hvor mange av eksemplaret som går opp i trykkmaskinens defaultformat. Trykkemaskinens kapasitet. Dette rundet opp til nærmeste heltall gir oss da antall ark som trengs for å utføre ett eksemplar. format på netto produkt formatforhold standard format på trykkmaskin Dette forholdet blir regnet ut i to tilfeller. Enten bredde * lengde, eller lengde * bredde. Det tallet som gir størst verdi gir da det rimeligste oppsettet av format. antall sider netto produkt /2 =antall ark i defaultformat formatforhold Antall ark i defaultformat må da multipliseres med opplaget. Dette sier hvor mange ark som trengs for hele opplaget.

2. Deretter må vi finne antall trykkplater som trengs for hele trykket. Dette finner vi ved å multiplisere antall ark med antall farger foran og bak, som vist i formelen under. antall ark i defaultformat antall farger foran antall farger bak =antall trykkplater antallet trykkplater blir multiplisert for å få trykkprisen. 3. Nå trenger vi å finne prisen som er rimeligst med den type ark og gramvekt som er valgt for arket (dette er vanligvis de aller største formatene som kan bestilles). antall ark brutto format pris brutto format = papirpris 1000 ark Systemet sjekker da alle prisene i databasen som det er mulig å benytte, og tar vare på verdier om det rimeligste alternativet. Om dette lagres info om formatet, mengde ark og pris. Prisen som hentes ut er alltid per 1000 ark, prisene her tar også bare hensyn til palleprisen, som er den rimeligste. 4. Etterbehandlingsprisen regnes så ut. Det er forskjellige satser til forskjellige utregninger. Antall timer med etterbehandlig multipliseres med satsen for den valgte etterbehandlingen. 5. Tilslutt legges alle prisene i sammen til en totalsum. Totalsum= papirpris trykkpris etterbehandling arbeidstid designtid

Figur 2.5.2-2: Sekvensdiagram for kalkulering av mest optimale arkdimensjon.

2.5.3 Presentasjonslaget Granitt Kalkyle er et system som baserer seg hovedsakelig på å forenkle arbeidet for brukeren. Derfor er grensesnittet en essensiell del av dette systemet. Presentasjonslaget består av en rekke GUI-klasser som jobber hierarkisk sammen, for å få en god dataflyt i programmet. Data er tatt vare på i kommunikasjon mellom vinduene ved å mellomlagre dem i opprettelse av nye vindu. public AdminGUI(JFrame parentgui) { parent = parentgui; initcomponents(); } figur 2.5.3-1: Eksempel på at vi mellomlagrer forelder GUIen. Dette gjøres for å kunne utføre operasjoner på det foregående vinduet mens du er i et gjeldene vindu, f. eks. gjøre det usynlig, uskalerbart, sette fokus på osv. For en detaljert liste av klassene henviser vi til javadokumentasjonen på prosjektsiden.

2.6 Brukergrensesnitt Dette kapittelet tar for seg våre valg i belysning av hvilke, hvordan og hvorfor vi tok valgene. Modeller og diagrammer av systemet finner du i vedlegg 5.1.1-5.1.3. 2.6.1 Om designet Målet med designet på Granitt Kalkyle var å få et enkelt manøvrerbart system som ikke skulle bli alt for komplekst for brukeren. I tillegg til dette ville vi at systemet skulle være 100% brukerstyrt, slik at brukeren hadde mulighet til å administrere hele databasen på egenhånd. Det første du får beskjed om når du starter programmet er å logge deg inn, med brukernavn og passord. Deretter sendes du videre til hovedvinduet. Dette vinduet har 3 navigeringsknapper, samt en topmeny og Granitt Grafisks logo. Figur 2.6.1-1: Hovedvinduet

Toppmenyen er tredelt. Den første delen åpner et vindu der du kan legge til nye brukere i systemet, hvis det for eksempel skulle komme nye ansatte i firmaet etc. Den andre delen har to knapper. Den ene dirigerer deg til kundeadministreringsvinduet og den andre dirigerer deg til produktadministreringsvinduet. Til slutt har du en knapp som lukker systemet på en sikker måte for deg. Dette er illustrert i figur 4.6.1-2 som vist under. Figur 2.6.1-2: Toppmenyen i hovedvinduet

2.6.2 design av administrasjonsgui I administrasjonsvinduene har vi valgt å presentere dataene i tabeller. Dette for å få en god oversikt over dataene, samt å enkelt kunne legge til, endre eller fjerne data. Under tabellene følger det en del knapper samt et søkefelt. Knappene er funksjonene du kan utføre på dataene i tabellen. Vi har i helhet, valgt å bruke et pop-up design gjennom systemet for å få presentert kun den nødvendige informasjonen av gangen. Det vil si at hver gang det aktiveres en knapp, vil et nytt vindu dukke opp der den nødvendige informasjonen vil ligge. Alle vinduene for dataadministrering er bygd opp likt, med kun noen få funksjonelle forskjeller i hvert vindu. Administrer tilbud Tilbudsadministreringsvinduet viser en tabell med alle registrerte tilbud. Hvert tilbud har en unik ID, tittel, kundenavn og datoen det ble opprettet. Tilbud kan søkes etter ved å skrive inn søkeparametre i feltet nederst i vinduet. Kolonner som er huket av blir inkludert i søket, mens andre kolonner vil bli utelatt. For å endre et tilbud kan man dobbeltklikke på raden i tabellen, høyreklikke og deretter velge "rediger" fra menyen, eller bruke knappen nederst i vinduet. Figur 2.6.2-1: KalkyleAdminGUI-vinduet

Administrer produkt Produktadministreringsvinduet inneholder en tabell med alle registrerte arktyper. Arktypene er hentet fra en excel-fil som blir gitt ut av arkleverandøren. For å laste opp ny prisliste trykker man på "Last opp ny prisliste..." og velger filen man ønsker å laste opp. For å manuelt redigere en arktype kan man dobbeltklikke på raden, høyreklikke og velge "rediger..." fra menyen eller bruke knappen nederst i vinduet. Hver kolonne kan sorteres ved å trykke på tittelen til kolonnen. Tabellen vil bli sortert alfabetisk eller numerisk avhengig av typen som lagres i kolonnen. Figur 2.6.2-2: AdminGUI-vinduet

Administrer kunder Kundeadministreringsvinduet viser en tabell over alle registrerte kunder. Hver kunde har en unik ID, navn, addresse, postnummer, poststed, telefon og epost. Redigering av innlegg og søking foregår på samme måte som i produktadministreringsvinduet. Figur 2.6.2-3: CustomerAdminGUI-vinduet

2.6.3 design av KalkyleGUI KalkyleGUI klassen, er det grensesnittet som brukeren vil ha mest med å gjøre. Det er da viktig å ta hensyn til brukervennlighet. Det er sentralt i dette vinduet. Vi har valgt å designe vinduet, med en sekvensiell rekke av paneler under hverandre, der hvert panel inneholder kategorisert informasjon som er nødvendig for en kalkyle, som vist i figur 2.6.3-1. Figur 2.6.3-1: KalkyleGUI-vinduet

2.6.4 design av Utskriften Utskriften er en viktig del av Granitt Kalkyle. Det er den som blir leddet mellom Granitt Grafisk og kunden. Derfor er det lagt mye arbeid i det grafiske ved utskriften. Utskriften er bygd opp i tre paneler, header, footer og hovedpanelet. Hovedpanelet er igjen delt inn i tre deler. Header inneholder generell info om tilbudet. Hovedpanelet inneholder kundeinfo, kalkyleinfo og prisen på tilbudet. Footer inneholder kontaktinformasjon til bedriften. Utskriften bør være kompatibel til å enkelt kunne benyttes til å sendes ut som brev, brett av arket bør da få fram navn og adresse til kunden som mottaker prisforespørselen. Figur 2.6.4-1: Eksempel på en ferdig utskrift(nedskalert versjon).

2.7 Sikkerhet 2.7.1 Datasikkerhet Vi har ikke tatt mye hensyn til sikkerheten til Granitt Kalkyle. Dette er fordi Granitt grafisk ønsket et lukket system med et program og en lokal database, som ikke ikke kommuniserte over nettet. Vi har derimot lagt inn et innloggingsystem, med brukernavn og passord. Passordet er ikke kryptert, men dette systemet er lagt til for en eventuell videreutvikling i senere tid. Figur 2.7.1-1: Forenklet kodesnutt av innlogging i LoginGui-klassen

2.7.2 Backup Med hensyn til mengden data som behandles i Granitt Kalkyle er det essensiellt med backup. Vi har valgt å la SQL-serveren ta seg av backupen, ved at vi satt opp et periodisk tidsprogram der databasen blir sikkerhetskopiert til en ekstern server. Dette gjør at hvis det skulle oppstå dataproblemer, så er sikkerheten for at dataen ikke er tapt mye større.

2.8 Databasen 2.8.1 ER-diagram Her ser du sammenhengen mellom kunder, kalkyler og produkter. Figur 2.8.1-1: ER-diagram av databasen. Viser relasjoner mellom de forskjellige entitetene.

2.8.2 Tabellbeskrivelser Kunde Kundetabellen blir brukt til å lagre/endre/hente ut kontaktinformasjon om kunden. Datatyper for de forskjellige attributtene er vist i figur 4.8.2-1. Kunde Kolonnenavn Datatype Nullbar KundeNr Integer(primær) Nei Fornavn Varchar(45) Nei Etternavn Varchar(45) Ja Adresse Varchar(45) Nei E-post Varchar(45) Ja PostNr Varchar(45) Nei Poststed Varchar(45) Nei Figur 2.8.2-1: Kundetabell Kalkyler Kalkyletabellen blir brukt til å lagre informasjon fra en ferdig kalkulert kalkyle. Kalkyletabellen er relatert til Kundetabellen ved kundenr( figur 4.8.1-1). Datatyper for de forskjellige attributtene er vist i figur 4.8.2-2. Kalkyler Kolonnenavn Datatype Nullbar KalkyleNr Integer(primær) Nei Kunde.KundeNr Integer Nei Format Nei Varchar(45) Etterbehandling Varchar(45) Figur 2.8.2-2: Kalkyletabell Ja

KalkyleDel Kalkyledeltabellen brukes til å lagre informasjon om hver delkalkyle( omslag, innmat annet), med relasjon til Prislistetabellen. Datatyper for de forskjellige attributtene er vist i figur 2.8.2-3. KalkyleDel Kolonnenavn Datatype Nullbar KalkyleDelNr Integer(primær) Nei Kalkyle.KalkyleNr Integer Nei Prisliste.ArtNr Integer Nei Delbeskrivelse Varchar(45) Ja Sider Integer Nei Farger Varchar(45) Nei Figur 2.8.2-3:KalkyledelTabell

Prisliste Prislistetabellen er generert ut i fra excelfilen som papyrus leverer en gang i året. Denne tabellen beskriver informasjon og pris om produktene fra papyrus sitt sortement. Datatyper for de forskjellige attributtene er vist i figur 2.8.2-4. Prisliste Kolonnenavn Datatype Nullbar ArtNr Integer(primær) Nei Varebeskrivelse1 Varchar(45) Ja Varebeskrivelse2 Varchar(45) Ja Gram Varchar(45) Ja Bredde Integer Nei Lengde Varchar(45) Nei Høyde Integer Ja Vekt Decimal Nei Myverdi Integer Nei Enhet-Pakkningsenhet1 Varchar(45) Ja Antall-Pakkningsenhet1 Integer Ja Enhet-Pakkningsenhet2 Varchar(45) Ja Antall-Pakkningsenhet2 Integer Ja SalgsEnhet Varchar(45) Nei SalgsprisAntall Integer Nei PrisUnder1Pall Integer Ja Pris1Pall Integer Nei Figur 2.8.2-4: PrislisteTabell(Produkttabell)

2.9 Videreutvikling Dette Kapittelet tar for seg utvidelsespotensialet til Granitt Kalkyle. 2.9.1 Uteblivende funksjoner Noen få av funksjonene til Granitt Kalkyle måtte utebli på grunn av tidsbegrensningen. Disse funksjonene uteble: Mulighet til å velge mer spesielle fargetyper(cmyk-cyan, Magenta, Yellow, Key(black)). Forskjellige fargenyanser i Kalkylevinduet, for mer oversiktlig skille på de forskjellige delene. Automatisk utregning av fakturering, basert på vekt pr ferdig produkt. 2.9.2 Ideer til utvidelser Underveis i utviklingen har vi fått mer oversikt over Granitt Kalkyle og dermed også fått mange ideer til utvidelser vi kunne tenkt oss å lage hvis vi hadde hatt muligheten. Her er en liste av disse: Støtte for bedre sikkerhet i systemet. Granitt Kalkyle er programmert så det er en enkel jobb å implementere kryptering av passord. Implementere brukeradministrering, for administrering på brukere av systemet, med sletting og endring av brukere. En superbruker, ville da gitt bedre sikkerhet i systemet. Automatisk utsending av E-post, som tilbuder etc, til kunder som har registrert dette. Visuell guide i programmet, ved f.eks en hjelp-knapp som beskriver de forskjellige feltene. Mer universell utforming, med tanke på svakerestillte i samfunnet. En web-basert løsning av systemet, som gjør systemet tilgjengelig for kunden. Redigerbar utskrift. I stedet for at utskriften blir konvertert til PDF, så kunne den konverteres til for eksempel DOC eller lignende tekstfil, så de kan redigere utskriften som dem vil.

HOVEDPROSJEKT 2011 HØGSKOLEN I OSLO GRANITT GRAFISK TESTDOKUMENTASJON

3.1 Forord Dette dokumentet skal gjøre testing av systemet enklere i forbindelse med produkttesten, og dermed sikre at programutviklingen er i hehold til ønsket design. dokumentet har som hensikt å luke ut de mest alvorlige feilen i programmet.

3.2 Innholdsfortegnelse for testdokumentasjon 3.1 Forord 3.2 Innholdfortegnelse 3.3 Hvordan dokumentet brukes 3.4 Testcases 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.4.10 3.4.11 3.4.12 3.4.13 3.4.14 3.4.15 3.4.16 3.4.17 3.4.18 3.4.19 3.4.20 Logge inn til system Administrere tilbud Lage nytt tilbud Kalkulere pris Endre/vise tilbud Slette tilbud Filtrering av tilbud Administrere brukere Legge til bruker Administrere ark Legge til oppføring i prislisten Redigere oppføring Slette oppføring Laste opp ny prisliste Filtrere prisliste Administrere kunder Legg til kunde Endre kundeinfo Slette kunde Filtrering av kunder

3.3 Hvordan dette dokumentet brukes Alle testcasene i testrapporten er numererte, og disse skal kunne testes i vilkårlig rekkefølge, gitt at du har tilgang til nødvendig vindu. det refereres i tittelen til hver testcase til casen i usecase beskrivelsen. Nr. # Beskrivelse Respons/kommentar x.x x.x I respons/komentarfeltet kan det også beskrives avvik og eventuelle feilmeldinger som er feilaktig eller ikke gitt til bruker. Nødvendige filer Det er kun én nødvendig fil for å kunne utføre alle testene, og dette gjelder kun et fåtall av testene. Den nødvendige filen er en excel fil som brukes til å oppdatere prislisten for papir i databasen. Oppdatert fil kan alltid lastes ned fra papyrus sin hjemmeside. Under testing kan det brukes brukernavn "granitt" og tilhørende passord "grafisk". 3.4 Testcases Notasjon! Ekstra kommentar # Operasjon foregår i bakgrunnen

3.4.1 Logg inn til systemet (ref: 1) Du må ha en registrert bruker og det tilhørende passordet. Nr. Beskrivelse Respons/kommentar 1.1 Start systemet Start programmet ved å kjøre kjørbar java fil 1.2 Skriv inn gyldige Innlogging skal være vellykket, og du skal brukernavn og få opp et hovedvindu. passord 1.3 Start systemet Du skal få beskjed om at innlogging feilet på nytt, men tast inn ugyldige brukernavn og passord, gjerne diverse tegn og tall 1.5 # # 1.6 Systemet får ikke Du skal få feilmelding som informerer om kontakt med feilen. databasen Avbryt pålogging Systemet skal lukke seg 3.4.2 Administrere tilbud (ref: 1.1) Du må være logget på systemet, og navigere deg til hovedvinduet. Nr. # 2.1 2.2 # Beskrivelse Respons/kommentar Velg "kalkyleoversikt" Du skal få opp et nytt vindu med oversikt over tilbud Forskjellige typer exceptions Du skal få feilmelding som som oppstår gjennom systemet, informerer om feilen. Og du blir f eks. Databasefeil. navigert til forrige fungerende vindu.

3.4.3 Lage nytt tilbud (ref: 1.1.1) Du må være logget på systemet, og navigert deg til administrasjon av tilbud eller hovedvinduet. Nr. # Beskrivelse 3.1 Velg "Lag nytt tilbud" eller "ny kalkyle" Du skal få opp et nytt vindu hvor det kan skrives inn data om kalkylen 3.2 Du taster inn gyldige data i alle nødvendige felter, og lagrer kalkylen Du skal få ut estimert pris(3.4.4) og har mulighet for å lagre kalkylen. Hadde en feil der noen tilfeller gikk gjennom uten å være gyldig. 3.3 Du lagrer kalkylen med de gyldige dataene Du får melding om at lagringen var velykket. 3.4 Du starter vinduet på nytt og taster inn ulike kombinasjoner av ugyldige data Du skal få feilmelding rundt de ugyldige dataene. Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil, feil i lagring osv. Du skal få feilmelding som informerer om feilen. Og du blir navigert til forrige fungerende vindu. 3. # Respons/kommentar 3.4.4 Kalkulere Pris (ref: 1.1.1.1 og 1.1.2.1) Du må være logget på systemet og befinne deg i kalkylevinduet og ha gyldige/ugyldige data fylt i de ulike feltene. Nr. # Beskrivelse Respons/kommentar 4.1 # Dette punktet skal skje automatisk når alle nødvendige felter er utfylt. Automatisk estimering av pris. Du skal få gitt en estimert pris basert på innfylt data. 4.2 Du har ugyldige data utfylt i deler av feltene Du skal få info om hvor de ugyldige dataene befinner seg. 4.3 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen.

3.4.5 Endre/vise tilbud (ref: 1.1.2) Du må være logget på systemet, og navigert deg til administrasjon av tilbud og funnet en lagret kalkyle Nr. # Beskrivelse Respons/kommentar 5.1 Du dobbelklikker på ønsket kalkyle eller høyreklikker og velger "vis/endre", eller trykker "vis/endre kalkyle" Du skal få opp et nytt vindu med ferdigutfylt data fra den lagrede kalkylen. 5.2 Du endrer noe data i de ferdigutfylte feltene og lagrer tilbudet. Du skal bli navigert til forrige vindu og endringene skal lagres. Hvis noe ugyldige data finnes skal du få feilmelding, og bli værende i samme vindu. 5.3 Du endrer noe data i feltene og avbryter lagring. Du skal komme til forrige vindu. Uten at noe nye data lagres. 5.4 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. Og du blir navigert til forrige fungerende vindu. 3.4.6 Slette tilbud (ref: 1.1.3) Du må være logget på systemet, og navigert deg til administrasjon av tilbud og funnet fram en lagret kalkyle. Nr. # Beskrivelse Respons/kommentar 6.1 Du trykker "slett tilbud" etter markert kalkyle, eller høyreklikker på angitt kalkyle og velger "slett", og asepterer sletting Du skal få slettet den angitte kalkylen fra databasen og bli guidet tilbake til kalkyleadministrasjonen 6.2 Samme som foregående men avbryter sletting Du skal komme tilbake til kalkyleadministrasjon og sletting avbrytes Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. Og 6. #

du blir navigert til forrige fungerende vindu. 3.4.7 Filtrering tilbud (ref: 1.1.4) Du må være logget på systemet, og navigert deg til administrasjon av tilbud Nr. # Beskrivelse Respons/kommentar 7.1 Du skriver inn ønsket søkeparameter i søkefeltet og definer hvilket søkefelt du vil benytte, og deretter trykker enter eller "søk". Tabellen skal da oppdateres i henhold til søkeparameteren 7.2 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. Og du blir navigert til forrige fungerende vindu. 3.4.8 Administrere brukere (ref: 1.2) Du må være logget på systemet, og navigert deg til hovedvinduet. samt ha en registrert bruker og det tilhørende passordet. Nr. # Beskrivelse Respons/kommentar 8.1 Du må trykke på "kundeadministrering". Du skal få opp et nytt vindu hvor innloggingsdata verifiseres. 8.2 Du skal skrive inn gyldig brukernavn og gyldig tilhørende passord. Innlogging skal være vellykket, og du skal få opp et nytt vindu. Her guides du til test 9. 8.3 Du skal nå skrive inn ugyldig brukernavn og Du skal få beskjed om at passord, i innloggingsvinduet. brukernavn og passord er feil. 8.4 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. Og du blir navigert til forrige fungerende vindu.

3.4.9 Legge til bruker (ref: 1.2.1) Du må være logget på systemet og navigert deg til administrasjon av brukere Nr. # Beskrivelse Respons/kommentar 9.1 Tast inn gyldige data for den nye brukeren Du skal få melding om at den angitte brukeren og tilhørende passord ble opprettet. 9.2 Tast inn ugyldige data for den nye brukeren, f. Eks. forskjellige passord i feltene som må være like. Du skal få feilmelding om at passordene ikke er like. 9.3 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.10 Administrere ark (ref: 1.3) Du må være logget på systemet, og navigert deg til hovedvinduet. Nr. # Beskrivelse Respons/kommentar 10.1 Du må trykke på "administrering av arktyper". Du skal få opp et nytt vindu som inneholder alle data i prislisten 10.2 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. Og du blir navigert til forrige fungerende vindu.

3.4.11 Legge til oppføring i prislisten (ref: 1.3.1) Du må være logget på systemet, og navigert deg til "Administrering av arktyper". Nr. # Beskrivelse Respons/kommentar 11.1 Du må trykke "legg til ny oppføring" 11.2 Tast inn gyldig data i alle nødvendige felter. Du skal ha mulighet for å lagre oppføringen. 11.3 Du lagrer den nye oppføringen med de gyldige dataene Du får melding om at lagringen var velykket. Og du blir navigert til forrige vindu. 11.4 Tast så inn ugyldige data i feltene. Du skal få melding om hvilke nødvendige felter som inneholder ugyldig data. 11.5 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.12 Redigere oppføring (ref: 1.3.2) Du må være logget på systemet, og navigert deg til "Administrering av arktyper". Nr. # Beskrivelse Respons/kommentar 12.1 Du dobbelklikker på ønsket oppføring eller Du skal få opp et nytt høyreklikker og velger "rediger", eller vindu med ferdigutfylt trykker "rediger oppføring" data fra den lagrede oppføringen. 12.2 # Du endrer noe data i de ferdigutfylte feltene og lagrer oppføringen. Du skal bli navigert til forrige vindu og endringene skal lagres. Hvis noe ugyldige data finnes skal du få feilmelding, og bli værende i samme vindu. 12.3 Du endrer noe data i feltene og avbryter lagring. Du skal komme til forrige vindu. Uten at noe nye data lagres.

12.4 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.13 Slette oppføring (ref: 1.3.3) Du må være logget på systemet, og navigert deg til "Administrering av arktyper". Nr. # Beskrivelse Respons/kommentar 13.1 Du trykker "slett oppføring" etter å markere oppføring, eller høyreklikker på angitt oppføring og velger "slett", og asepterer sletting Du skal få slettet den angitte kalkylen fra databasen og bli guidet tilbake til Arkadministrasjon 13.2 Samme som foregående men avbryter sletting Du skal komme tilbake til Arkadministrasjon og sletting avbrytes 13.3 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.14 Laste opp ny prisliste (ref: 1.3.4) Du må være logget på systemet, og navigert deg til "Administrering av arktyper". Nr. Beskrivelse Respons/kommentar 14.1! Du trykker "Last opp ny prisliste" og angir en gyldig excel fil (gyldig fil er hentet fra papyrus sine sider) Systemet skal laste opp listen til databasen som inneholder data om priser. Underveis skal brukeren se fremgangen i prosessen. (Opplastingsalgoritmen er noe treg!) 14.2 Samme som i forrige punkt, bare du nå angir en ugyldig fil Du skal få beskjed om at den gitte filen ikke er gyldig for systemet. 14. # # Forskjellige typer exceptions som oppstår Du skal få feilmelding som gjennom systemet, f eks. Databasefeil, feil i informerer om feilen. excel bibliotek osv.

3.4.15 Filtrere prislisten (ref: 1.3.5) Du må være logget på systemet, og navigert deg til "Administrering av arktyper". Nr. # Beskrivelse Respons/kommentar 15.1 Du skriver inn ønsket søkeparameter av varebeskrivelse i søkefeltet, og deretter trykker enter eller "søk". Tabellen skal da oppdateres i henhold til søkeparameteren 15.2 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.16 Administrere kunder (ref: 1.4) Du må være logget på systemet, og navigert deg til hovedvinduet. Nr. # Beskrivelse Respons/kommentar 16.1 Du trykker "kundeadministrering" Du skal få opp et nytt vindu som inneholder alle data om registrerte kunder. 16.2 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.17 Legge til kunde (ref: 1.4.1) Du må være logget på systemet, og navigert deg til "kundeadministrering". Nr. # Beskrivelse Respons/kommentar 17.1 Du må trykke "ny kunde" 17.2 Tast inn gyldig data i alle nødvendige felter. Du skal nå ha mulighet for å lagre oppføringen. 17.3 Du lagrer den nye oppføringen med de gyldige dataene Du får melding om at lagringen var velykket. Og du blir navigert til forrige vindu. 17.4 Tast så inn ugyldige data i feltene. Du skal få melding om hvilke nødvendige felter som inneholder ugyldig

data. 17.5 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.18 Endre kundeinfo (ref: 1.4.2) Du må være logget på systemet, og navigert deg til "kundeadministrering". Nr. # Beskrivelse Respons/kommentar 18.1 Du dobbelklikker på ønsket kunde eller høyreklikker og velger "rediger", eller trykker "rediger kunde" Du skal få opp et nytt vindu med ferdigutfylt data fra den lagrede kunden. 18.2 # Du endrer noe data i de ferdigutfylte feltene og lagrer oppføringen. Du skal bli navigert til forrige vindu og endringene skal lagres. Hvis noe ugyldige data finnes skal du få feilmelding, og bli værende i samme vindu. 18.3 Du endrer noe data i feltene og avbryter lagring. Du skal komme til forrige vindu. Uten at noe nye data lagres. 18.4 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.19 Slette kunde (ref: 1.4.3) Du må være logget på systemet, og navigert deg til "kundeadministrering". Nr. # Beskrivelse Respons/kommentar 19.1 Du trykker "slett kunde" etter å markere kunden, eller høyreklikker på angitt kunde og velger "slett", og asepterer sletting Du skal få slettet den angitte kunden fra databasen og bli guidet tilbake til kundeadministrasjon 19.2 Samme som foregående men avbryter sletting Du skal komme tilbake til kundeadministrasjon og

sletting avbrytes. 19.3 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen. 3.4.20 Filtrering av kunder (ref: 1.4.4) Du må være logget på systemet, og navigert deg til "kundeadministrering". Nr. # Beskrivelse Respons/kommentar 20.1 Du skriver inn ønsket søkeparameter av navn i søkefeltet, og deretter trykker enter eller "søk". Tabellen skal da oppdateres i henhold til søkeparameteren 20.2 # Forskjellige typer exceptions som oppstår gjennom systemet, f eks. Databasefeil osv. Du skal få feilmelding som informerer om feilen.

HOVEDPROSJEKT 2011 HØGSKOLEN I OSLO GRANITT GRAFISK BRUKERDOKUMENTASJON

4.1 Forord Dette er brukerdokumentasjonen skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo våren 2011. Dokumentet beskriver bruk av Granitt Kalkyle, og er skrevet for brukerne av systemet. Brukerdokumentasjonen er en brukerveiledning som er utviklet for å veilede brukeren til systemet.

4.2 Innholdfortegnelse for brukerdokumentasjon 4.1 Forord 4.2 Innholdfortegnelse for brukerdokumentasjon 4.3 Brukermanual 4.3.1 Administrer brukere til systemet 4.3.1.1 Legg til bruker 4.3.1.2 Endre passord til bruker 4.3.2 Administrer arktyper 4.3.2.1 Legg til arktyper 4.3.2.2 Endre arktyper 4.3.2.3 Søk etter arktyper 4.3.2.4 Slett arktyper 4.3.2.5 Last opp ny prisliste 4.3.3 Administrer kunder 4.3.3.1 Legg til kunde 4.3.3.2 Endre kunde 4.3.3.3 Søk etter kunde 4.3.3.4 Slett kunde 4.3.4 Administrer tilbud 4.3.4.1 Lag nytt tilbud 4.3.4.2 Endre tilbud 4.3.4.3 Søke etter tilbud 4.3.4.4 Slett tilbud 4.3.4.5 Skriv ut tilbud 4.3.5 Hvordan fungerer tilbudsvinduet? 4.3.5.1 Felter og knapper 4.3.5.2 Valg av arktype

4.3 Brukermanual 4.3.1 Administrere brukere til systemet 4.3.1.1 Legg til bruker til systemet For å legge til en ny bruker i systemet, velg «Administrering...» og deretter «Ny bruker til systemet...» Fyll deretter inn ønsket brukernavn og passord for ny bruker.

4.3.1.2 Endre passord til bruker For å endre passord til bruker, følg samme steg som i 4.3.1.1 og oppgi ønsket nytt passord med eksisterende brukernavn. 4.3.2 Administrere arktyper For å åpne vinduet som administrerer arktyper, velg «Administrasjon...» og deretter «Administrering av arktyper...».

4.3.2.1 Legg til ny arktype For å legge til ny arktype, velg «Legg til oppføring...» i administreringsvinduet. Fyll inn informasjon om arktypen og trykk OK.

4.3.2.2 Endre arktype For å endre en arktype, velg en oppføring fra tabellen og trykk på «Endre oppføring...» Følg deretter samme steg som i 4.3.2.1 4.3.2.3 Søke etter arktype For å søke etter arktype, velg feltet «Søk etter varebeskrivelse:». Fyll inn søkeparametere og trykk enter eller på «Søk...»

4.3.2.4 Slett arktype For å slette arktype, velg en oppføring fra tabellen og velg «Slett oppføring...» 4.3.2.5 Last opp ny liste For å laste opp ny liste med arktyper, velg «Last opp ny prisliste...» og velg filen som inneholder arktypene.

4.3.3 Administrering av kunder For å åpne kundeadministreringsvinduet, velg «Administrering...» og deretter «Kundeadministrering...» 4.3.3.1 Legg til kunde For å legge til en kunde, velg «Legg til kunde...».

Fyll inn informasjon om kunden og trykk OK. 4.3.3.2 Endre kunde For å endre en kunde, velg en oppføring fra tabellen og velg «Endre kunde...». Følg samme steg som i 4.3.3.1.

4.3.3.3 Søk etter kunde For å søke etter en kunde, velg feltet «Søk etter navn» og skriv inn søkeparameterene. Trykk deretter på enter eller «Søk». 4.3.3.4 Slett kunde For å slette en kunde, velg en oppføring fra tabellen og velg «Slett kunde...».

4.3.4 Administrering av tilbud For å åpne vinduet som administrerer tilbud, velg «Tilbudsoversikt» fra startvinduet. 4.3.4.1 Lag nytt tilbud For å lage et nytt tilbud, velg «Lag nytt tilbud» direkte fra startvinduet, eller gå først inn på «Tilbudsoversikt» og deretter «Nytt tilbud...»

Fyll inn info til tilbudet og lagre. 4.3.4.2 Endre tilbud For å endre et tilbud, gå inn på «Tilbudsoversikt». Velg et tilbud fra tabellen og trykk «Endre tilbud...». Følg samme steg som i 4.3.4.1

4.3.4.3 Søke etter tilbud For å søke etter et tilbud, kryss av ønskede felter og skriv inn søkeparameterene. Trykk enter eller «Søk...». 4.3.4.4 Slett tilbud For å slette et tilbud, velg et tilbud fra tabellen og trykk «Slett tilbud...».

4.3.4.5 Skriv ut et tilbud For å skrive ut et tilbud, åpne tilbudet ved å velge det fra tabellen og velg «Vis/endre tilbud...». Velg deretter «Skriv ut...» Velg «Ja».

4.3.5 Hvordan funker tilbudsvinduet? 4.3.5.1 Felter og knapper A. Trykk her hvis kunden ikke allerede eksisterer og må opprettes B. Fyll inn navn på kunden du vil søke etter, og trykk på C D. Navnet på tilbudet E. Antall opplag som skal produseres F/G. Bredde og lengde på produktet. H. Trykk her for å velge standardformat på produktet (A4 etc.)

I. Trykk her for å legge til arktype J. Kryss av ønsket etterbehandling og antall timer etterbehandlingen vil ta K. Skriv inn ønsket avanse i prosent. L. Skriv inn rabatt fra arkleverandøren M. Trykk for å lagre. N. Trykk for å avbryte og gå tilbake til tilbudsadministreringsvinduet O. Trykk for å skrive ut tilbudet. 4.3.5.2 Valg av arktype Ved å velge «Legg til arktype...» åpnes Delkalkylevinduet. Fyll inn type, antall sider og antall farger og legg til arktypen.

For å søke etter en arktype, skriv inn navnet på produktet i feltet og trykk «Søk...». Velg tykkelsen (gram/m3) på arket og trykk OK. Delen vil da være lagt til det overordnede tilbudet.

4.3.5.3 Endring og sletting av del For å endre delen, velg «Endre...» fra vinduet. Delkalkylevinduet vil åpnes. Trykk OK etter du har gjort endringene. For å slette delen, velg «Slett...» og trykk ja.

HOVEDPROSJEKT 2011 HØGSKOLEN I OSLO GRANITT GRAFISK VEDLEGG

Innholdfortegnelse for vedlegg Vedlegg 5.1 Diagrammer 5.1.1 Use-case Granitt Kalkyle 5.1.2 Sekvensdiagrammer 5.1.3 Klassediagram 5.1.4 Relasjonsdiagram for database 5.1.5 Databasescript Vedlegg 5.2 Styringsdokumenter 5.2.1 Kravspesifikasjon 5.2.2 Fremdriftsplan 5.2.3 Logg 5.2.4 Møtereferater med veileder 5.2.5 Møtereferater med oppdragsgiver 5.2.6 Timelister

Vedlegg 5.1 - Diagrammer 5.1.1 Use-case Granitt Kalkyle Use case 1 Logg inn til programmet Aktør Person Trigger: Bruker ønsker å logge inn til programmet Pre betingelse Bruker har valgt å starte programmet Postbetingelse Brukeren får logget inn og vises hovedvindu, ellers oppstår det feilmelding. Hendelseflyt 1.Systemet startes og ber om brukernavn og passord av brukeren 2.Bruker fyller inn feltene for brukernavn og passord 3.Systemet sjekker om brukernavn og passord er riktig. 4. Systemet gir brukeren adgang til programmet hvis bruker er autentisert. Variasjon 3a. Systemet får ikke kontakt med databasen. 3a1. Systemet informerer brukeren med en passende feilmelding. 3b. Brukernavn og passord er feil. 3b1.Systemet informerer brukeren med en passende feilmelding. Use case 1.1 Administrere tilbud Aktør Bruker Trigger: Bruker ønsker å administrere tilbud Pre betingelse Bruker har valgt å gå inn til kalkyleoversikten, ved å trykke på tilhørende knapp Postbetingelse Brukeren får opp oversikt over lagrede tilbud ellers oppstår det feilmelding Hendelseflyt 1. Programmet åpner et nytt tilbudoversikts vindu 2.Programmet henter ut data for alle registrerte tilbud fra databasen. Variasjon 2a. Systemet får ikke kontakt med databasen. 2a1. Systemet informerer brukeren med en feilmelding.

Use case 1.1.1 Lage nytt tilbud Aktør Bruker Trigger: Bruker ønsker å lage nytt tilbud Pre betingelse Bruker har valgt å legge til nytt tilbud ved å trykke tilhørende knapp i tilbudoversikten Postbetingelse Systemet lagrer et nytt tilbud ellers oppstår feilmelding Hendelseflyt 1.Systemet starter nytt vindu så bruker kan legge til nødvendig data for tilbudet. 2.Systemet verifiserer feltene 3.Systemet lagrer tilbudet med ferdigutfylt data i databasen, bruker får verifiseringsmelding. Variasjon 2a. Systemet får feil input. 2a1.Systemet ber brukeren om å fylle ut alle nødvendige felter med riktige verdier. 3a. Systemet får ikke kontakt med databasen. 3a1. Systemet informerer brukeren med en passende feilmelding. 3b. Feil i lagring har oppstått. 3b1. Bruker får en passende feilmelding. Use case 1.1.1.1 og 1.1.2.1 Kalkulere Pris Aktør Bruker Trigger: Bruker ønsker Pre betingelse Dette skjer automatisk når felter er fylt ut Postbetingelse Systemet viser brukereren et estimat av prisen for gjeldende ordre, ellers oppstår feilmelding Hendelseflyt 1. Systemet Validering av input 2. Systemet mater data gjennom en priskalkuleringalgoritme 3. Systemet lagrer og viser prisen i kalkylegui. Variasjon 1a. Ugyldig input 1a1. Feilmelding gis til bruker. 1a. Programmet får ikke kontakt med databasen. 1a1. Programmet informerer brukeren med en passende feilmelding.

Use case 1.1.2 Endre/vise tilbud Aktør Bruker Trigger: Bruker ønsker å endre/vise et angitt tilbud Pre betingelse Bruker har valgt å endre/vise et angitt tilbud ved å trykke tilhørende knapp i tilbudoversikten Postbetingelse Brukeren får opp et vindu med all ønskelig informasjon om det gitte tilbudet ellers oppstår feilmelding Hendelseflyt 1.Systemet henter ut all data om den angitte kalkylen fra databasen. 2.Systemet gjengir denne informasjonen til brukeren i et nytt vindu. Variasjon 1a. Programmet får ikke kontakt med databasen. 1a1. Programmet informerer brukeren med en passende feilmelding. Use case 1.1.3 Slette tilbud Aktør Bruker Trigger: Bruker ønsker å slette en angitt kalkyle Pre betingelse Bruker har valgt å slette en angitt kalkyle ved å trykke tilhørende knapp i tilbudoversikten Postbetingelse Systemet sletter tilbudet fra databasen ellers oppstår feilmelding, ellers avbrytes sletting. Hendelseflyt 1. Systemet verifiserer valg fra bruker gjennom et vindu. 2. Systemet sletter angitte data fra databasen, og tabellen i tilbudoversikten oppdateres heretter. Variasjon 1a. Bruker avbryter sletting 1a1. Systemet avbryter forespørselen om sletting, og bruker kommer til opprinnelig sted. 2a. Systemet får ikke kontakt med databasen. 2a1. Systemet informerer brukeren med en passende feilmelding.

Use case 1.1.4 Filtrering tilbud Aktør Bruker Trigger: Bruker ønsker å søke etter gitte søkeparametre Pre betingelse Bruker har valgt å søke ved å skrive ønsket søkeparametre i tilbudoversikten og deretter taste «enter» eller trykke tilhørende søkeknapp. Postbetingelse Systemet oppdaterer tabellen i vinduet med gitte søkeparametre ellers oppstår feilmelding Hendelseflyt 1. Systemet utfører spørring mot databasen med gitt filter. 2. Systemet oppdaterer tabellen i henhold til resultatet av spørringen. Variasjon 1a. Systemet får ikke kontakt med databasen. 1a1. Systemet informerer brukeren med en passende feilmelding. Use case 1.2 Administrere brukere Aktør Bruker Trigger: Bruker ønsker å administrere brukere av systemet Pre betingelse Bruker har valgt administrere brukere, ved å trykke tilhørende knapp i hovedvinduet ellers oppstår feilmelding Postbetingelse Brukeren kan administrere brukere i et nytt vindu ellers feilmelding oppstår Hendelseflyt 1. Systemet ber om brukernavn og passord 2.Bruker fyller inn feltene for brukernavn og passord 3.Systemet sjekker om brukernavn og passord er gyldige mot databasen. 4. Systemet gir brukeren adgang til administrasjon av brukere Variasjon 3a. Systemet får ikke kontakt med databasen. 3a1. Systemet informerer brukeren med en passende feilmelding. 3b.Brukernavn og passord er ugyldig 3b1.Programmet informerer brukeren ved en passende feilmelding

Use case 1.2.1 Legge til bruker Aktør Brukeradministrator Trigger: Brukeradministrator ønsker å legge til nye brukere av systemet Pre betingelse Bruker har valgt å trykke på tilhørende knapp «legg til bruker». Postbetingelse Systemet legger til ny bruker med utfylt informasjon ellers oppstår feilmelding Hendelseflyt 1.Systemet ber bruker om å fylle inn informasjon om ny bruker og passord til brukeren 2.Systemet validerer brukernavnet og passordet 3.Informasjonen sendes og skrives til i databasen. Variasjon 2a.Brukernavn og passord er duplisert/ugyldig 2a1.Programmet informerer brukeren ved en passende feilmelding 3a. Systemet får ikke kontakt med databasen. 3a1. Systemet informerer brukeren med en passende feilmelding. Use case 1.3 Administrere ark Aktør Bruker Trigger: Bruker ønsker å få tilgang til tabell for papir Pre betingelse Bruker har valgt å trykke tilhørende knapp i hovedvinduet Postbetingelse Bruker kan administrere prislisten i et nytt vindu ellers oppstår feilmelding Hendelseflyt 1. Systemet starter administrasjonvinduet. 2. Systemet Kontakter databasen og henter ut data fra prislisten der. 2. Systemet laster inn dataene fra databasen i en tabell, og viser det i administrasjonvinduet. Variasjon 1a. Systemet får ikke kontakt med databasen. 1a1. Systemet informerer brukeren med en passende feilmelding.

Use case 1.3.1 Legge til oppføring i prislisten Aktør Bruker Trigger: Bruker ønsker å legge til en ny oppføring i prislisten Pre betingelse Bruker har valgt å trykke tilhørende knapp i arkadministrasjon Postbetingelse Systemet legger til ny oppføring i databasen, ellers oppstår feilmelding. Hendelseflyt 1. Systemet starter nytt vindu der bruker kan legge til nødvendige data. 2. Systemet sjekker om det er gyldige verdier i utfylte felter, og validerer mot databasen. 3.Systemet lagrer den nye oppføringen i databasen. Variasjon 2a. Bruker skriver inn ugyldige verdier 2a1.Systemet informerer brukeren med en passende feilmelding. 2b. Systemet får ikke kontakt med databasen. 2b1. Systemet informerer brukeren med en passende feilmelding. 2c. Ikke validert mot databasen (ikke unik id nummer osv.). 2c1. Brukeren får en passende feilmelding. 3a samme som 2b, 3a1 samme som 2b1 Use case 1.3.2 Redigere oppføring Aktør Bruker Trigger: Bruker ønsker å redigere en oppføring i prislisten Pre betingelse Bruker har valgt å trykke tilhørende knapp i arkadministrasjon Postbetingelse Systemet får redigert en angitt oppføring, ellers oppstår det feilmelding. Hendelseflyt 1.Systemet starter nytt vindu som, og henter registrerte data om angitt oppføring, og gir bruker mulighet for å fylle ut ny informasjon. 2. Systemet validerer input. 3. Systemet lagrer den endret oppføringen i databasen, og systemet mottar verifisering av endringen. Variasjon 2a. Ugyldig input. 2a1.Systemet informerer brukeren med en passende feilmelding. *2b. Systemet får ikke kontakt med databasen.

2b1. Systemet informerer brukeren med en passende feilmelding. 3a. som i punkt 2b* Use case 1.3.3 Slette oppføring Aktør Bruker Trigger: Bruker ønsker å slette valgt oppføring Pre betingelse Bruker har valgt å trykke tilhørende knapp i arkadministrasjon Postbetingelse Systemet sletter angitt oppføring, ellers oppstår feilmelding. Hendelseflyt 1.Systemet verifiserer valg fra bruker 2.Systemet sletter den gitte oppføringen i databasen. Variasjon 1a. Bruker avbryter sletting 1a1. Systemet avbryter forespørselen om sletting, og bruker kommer til opprinnelig sted. 2a. Programmet får ikke kontakt med databasen. 2a1. Programmet informerer brukeren med en passende feilmelding. Use case 1.3.4 Laste opp ny prisliste Aktør Bruker Trigger: Bruker ønsker å fornye databasen mot en gitt excel fil (fil gitt er hentet fra papyrus) Pre betingelse Bruker har valgt å trykke tilhørende knapp i arkadministrasjon Postbetingelse Brukeren får oppdatert prislisten mot den gitte excel filen, ellers oppstår feilmelding Hendelseflyt 1. Systemet ber brukeren om filområdet der filen befinner seg. 2. Systemet verifiserer angitt fil deretter leses filen. 3. Systemet kobler seg mot databasen og mellomlagrer så alle data i en midlertidig tabell i databasen, samtidig som det leses fra filen?. 4. Systemet overskriver den riktige tabellen med den midlertidige, og sletter mellomlagringen fra 3, verifisering returneres. Variasjon 2a.Angitt Fil av brukeren er ugyldig. 2a1. Bruker får en passende feilmelding. *2b. Programmet får ikke kontakt med databasen.

*2b1. Programmet informerer brukeren med en passende feilmelding. *Samme kan skje i 3 og 4. Use case 1.3.5 Filtrere prisliste Aktør Bruker Trigger: Bruker ønsker å søke etter gitte parametere (Varebeskrivelse) Pre betingelse Bruker har valgt å trykke tilhørende knapp eller «enter» i arkadministrasjon. Postbetingelse Brukeren blir vist en redusert tabell med hensyn på søkeparametrene. Hendelseflyt 1.Brukeren skriver inn ønsket søkeparameter. 2.Systemet filtrerer ut tabellen med hensyn på denne parameteren ved hjelp av databasen Variasjon 2a. Ugyldig søkeparameter 2a1. Systemet gir en passende feilmelding til bruker. 2b. Programmet får ikke kontakt med databasen. 2b1. Programmet informerer brukeren med en passende feilmelding. Use case 1.4 Administrere kunder Aktør Bruker Trigger: Bruker ønsker å administrere kunder Pre betingelse Bruker har valgt å trykke tilhørende knapp i hovedvinduet. Postbetingelse Brukeren får et vindu med oversikt over kundene, her kan man legge til, slette og endre kunder, ellers oppstår feilmelding. Hendelseflyt 1.Systemet åpnet et nytt vindu og henter ut data om registrerte kunder i databasen. 2.Systemet fyller inn disse dataene i en tabell i vinduet. Variasjon 1a. Systemet får ikke kontakt med databasen. 1a1. Systemet informerer brukeren med en passende feilmelding.

Use case 1.4.1 Legg til Kunde Aktør Bruker Trigger: Bruker ønsker å legge til ny kunde Pre betingelse Bruker har valgt å trykke tilhørende knapp i kundeadministrasjon vinduet. Postbetingelse Systemet legger til en ny kunde i kundetabellen, ellers oppstår feilmelding. Hendelseflyt 1. Systemet åpner et nytt Vindu der bruker kan fylle ut nødvendige data. 2.Systemet validerer inndata. 3.Systemet lagrer oppføringen i databasen. Variasjon 2a. Ugyldige inndata. 2a1. Systemet informerer brukeren med en passende feilmelding. 3a. Systemet får ikke kontakt med databasen. 3a1. Systemet informerer brukeren med en passende feilmelding. Use case 1.4.2 Endre Kundeinfo Aktør Bruker Trigger: Bruker ønsker å redigere en angitt kunde Pre betingelse Bruker har valgt å trykke tilhørende knapp i kundeadministrasjon vinduet. Postbetingelse Systemet har redigert en gitt oppføring med inntastet data, ellers oppstår feilmelding. Hendelseflyt 1. Systemet åpner et nytt Vindu der bruker kan fylle ut nødvendige data. 2.Systemet validerer inndata. 3.Systemet redigerer oppføringen i databasen. Variasjon 2a. Ugyldig input. 2a1.Systemet informerer brukeren med en passende feilmelding. 3a. Programmet får ikke kontakt med databasen. 3a1. Programmet informerer brukeren med en passende feilmelding.

Use case 1.4.3 Slette Kunde Aktør Bruker Trigger: Bruker ønsker å slette valgt kunde Pre betingelse Bruker har valgt å trykke tilhørende knapp i kundeadministrasjon vinduet. Postbetingelse Systemet sletter angitt kunde, ellers oppstår feilmelding. Hendelseflyt 1.Systemet verifiserer valg fra bruker. 2.Systemet sletter den angitte kunden i databasen. Variasjon 1a. Bruker avbryter sletting 1a1. Systemet avbryter forespørselen om sletting, og bruker kommer til opprinnelig sted. 2a. Programmet får ikke kontakt med databasen. 2a1. Programmet informerer brukeren med en passende feilmelding. Use case 1.4.4 Filtrering av kunder Aktør Bruker Trigger: Bruker ønsker å søke etter angitt kunde Pre betingelse Bruker har valgt å trykke tilhørende knapp eller «enter» i kundeadministrasjon vinduet. Postbetingelse Brukeren blir vist en redusert tabell med hensyn på søkeparametrene. Hendelseflyt 1.Brukeren skriver inn ønsket søkeparameter 2.Systemet filtrerer ut tabellen med hensyn på denne parameteren. Variasjon 2a. Ugyldig søkeparameter 2a1. Systemet gir en passende feilmelding til bruker. 2a. Programmet får ikke kontakt med databasen. 2a1. Programmet informerer brukeren med en passende feilmelding.

5.1.2 Sekvensdiagramer Sekvensdiagram 1: Logge inn i programmet. Sekvensdiagram 2: Administrere tilbud.

Sekvensdiagram 3: Lage nytt tilbud. Sekvensdiagram 4: Kalkulere pris.

Sekvensdiagram 5: Endre/ vise tilbud. Sekvensdiagram 6: Slette tilbud. Sekvensdiagram 7: Filtrering/søk tilbud.

Sekvensdiagram 8: Administrere brukere. Sekvensdiagram 9: Legge til bruker. Sekvensdiagram 10: Administrere ark.

Sekvensdiagram 11: Legge til oppføring i prislisten. Sekvensdiagram 12: Redigere oppføring i prislisten.

Sekvensdiagram 13: Slette oppføring i prislisten. Sekvensdiagram 14: Laste opp ny prisliste. Sekvensdiagram 15: Filtrere/ søke i prislisten.

Sekvensdiagram 16: Administrere kunder. Sekvensdiagram 17: Legge til ny kunde. Sekvensdiagram 18: Endre kundeinfo.

Sekvensdiagram 19: Slette kunde. Sekvensdiagram 20: Filtrering/søking i kunderegisteret.

5.1.3 Klassediagram Klassediagram1: Forenklett klassediagram delt opp i pakker.

Klassediagram2: Detaljert klassediagram av kalkyleadmin pakken. Klassediagram3: Detaljert klassediagram av arkadmin pakken.

5.1.4 Relasjonsdiagram for database.

5.1.5 Databasescript Dette scriptet er designet av en autogenerering av den ferdigstillte databasen vår. ------ MySQL dump 10.13 Distrib 5.1.37, for debian-linux-gnu (i486) Host: localhost Database: project -----------------------------------------------------Server version 5.1.37-1ubuntu5.5 /*!40101 /*!40101 /*!40101 /*!40101 /*!40103 /*!40103 /*!40014 /*!40014 /*!40101 /*!40111 SET SET SET SET SET SET SET SET SET SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; NAMES utf8 */; @OLD_TIME_ZONE=@@TIME_ZONE */; TIME_ZONE='+00:00' */; @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; DROP TABLE IF EXISTS `access`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `access` ( `brukernavn` varchar(64) DEFAULT NULL, `passord` varchar(64) DEFAULT NULL, UNIQUE KEY `brukernavn` (`brukernavn`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; LOCK TABLES `access` /*!40000 ALTER TABLE INSERT INTO `access` /*!40000 ALTER TABLE UNLOCK TABLES; WRITE; `access` DISABLE KEYS */; VALUES ('granitt','grafisk'); `access` ENABLE KEYS */; DROP TABLE IF EXISTS `kalkyledel`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `kalkyledel` ( `kalkyledelnr` int(10) NOT NULL DEFAULT '0', `kalkylenr` int(10) DEFAULT NULL, `ArtNr` varchar(45) DEFAULT NULL, `delbeskrivelse` varchar(128) DEFAULT NULL, `Sider` int(10) DEFAULT NULL, `Farger` varchar(45) DEFAULT NULL, PRIMARY KEY (`kalkyledelnr`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; LOCK TABLES `kalkyledel` WRITE; /*!40000 ALTER TABLE `kalkyledel` DISABLE KEYS */; /*!40000 ALTER TABLE `kalkyledel` ENABLE KEYS */; UNLOCK TABLES; DROP TABLE IF EXISTS `kalkyler`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `kalkyler` ( `kalknr` int(16) NOT NULL DEFAULT '0', `knr` int(16) DEFAULT NULL, `Format` varchar(45) DEFAULT NULL, `Etterbehandling` varchar(1024) DEFAULT NULL, `Tittel` varchar(64) DEFAULT NULL, `Dato` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `opplag` int(10) DEFAULT NULL, `EtterBTimer` varchar(64) DEFAULT NULL, PRIMARY KEY (`kalknr`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; LOCK TABLES `kalkyler` WRITE; /*!40000 ALTER TABLE `kalkyler` DISABLE KEYS */; /*!40000 ALTER TABLE `kalkyler` ENABLE KEYS */; UNLOCK TABLES; DROP TABLE IF EXISTS `kunde`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `kunde` ( `knr` int(10) NOT NULL DEFAULT '0', `Fornavn` varchar(128) DEFAULT NULL, `Etternavn` varchar(128) DEFAULT NULL, `Addresse` varchar(1024) DEFAULT NULL, `PostNr` varchar(4) DEFAULT NULL, `Poststed` varchar(128) DEFAULT NULL, `epost` varchar(1024) DEFAULT NULL, `tlf` varchar(32) DEFAULT NULL, PRIMARY KEY (`knr`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; LOCK TABLES `kunde` WRITE; /*!40000 ALTER TABLE `kunde` DISABLE KEYS */; /*!40000 ALTER TABLE `kunde` ENABLE KEYS */; UNLOCK TABLES; DROP TABLE IF EXISTS `prisliste`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `prisliste` ( `ArtNr` int(10) NOT NULL DEFAULT '0', `Varebeskrivelse1` varchar(1024) DEFAULT NULL, `Varebeskrivelse2` varchar(1024) DEFAULT NULL, `Gram` int(10) DEFAULT NULL, `Bredde` int(10) DEFAULT NULL, `Lengde` int(10) DEFAULT NULL, `HÃ yde` int(10) DEFAULT NULL, `Vekt` decimal(10,1) DEFAULT NULL, `MyVerdi` int(10) DEFAULT NULL, `EnhetPakningsenhet1` varchar(1024) DEFAULT NULL, `AntallPakningsenhet1` varchar(1024) DEFAULT NULL, `EnhetPakningsenhet2` varchar(1024) DEFAULT NULL, `AntallPakningsenhet2` varchar(1024) DEFAULT NULL, `EnhetPall` varchar(1024) DEFAULT NULL, `AntallTransportPakning` int(10) DEFAULT NULL, `Salgsenhet` varchar(1024) DEFAULT NULL, `Salgsprisantall` int(10) DEFAULT NULL, `PrisUnder1Pall` int(10) DEFAULT NULL, `Pris1Pall` int(10) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; LOCK TABLES `prisliste` WRITE; /*!40000 ALTER TABLE `prisliste` DISABLE KEYS */; /*!40000 ALTER TABLE `prisliste` ENABLE KEYS */; UNLOCK TABLES; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; /*!40101 /*!40014 /*!40014 /*!40101 /*!40101 /*!40101 /*!40111 SET SET SET SET SET SET SET SQL_MODE=@OLD_SQL_MODE */; FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */; CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; SQL_NOTES=@OLD_SQL_NOTES */;

Vedlegg 5.2 Styringsdokumenter 5.2.1 Kravspesifikasjon 1.Innledning 1.1 Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables Oppdragsgiver: Granitt Grafisk AS Kontaktperson: Kjetil Hansen,Telefon: 613 90 700 Mobil: 900 34 045 kjetil@granittgrafisk.no Veileder: Ulf Uttersrud

1.2 Bakgrunn Etter fem semestre som Dataingeniørstudenter ved Høgskolen i Oslo, skal vårt sjette og siste semester brukes til å utføre et valgfritt hovedprosjekt. I følge høgskolen hjemmesider skal studentene etter fullført hovedprosjekt ha kompetanse til å utvikle ferdighetter i å løse, på en selvstendig og systematisk måte, et praktisk orientert og omfattende prosjekt, basert på oppdragsgivers krav. Studentene skal og demonstrere at de kan omsette sine kunnskaper til praktiske løsninger. De skal kunne produsere tilfredsstillende dokumentasjon for dataprogrammer og datasystemer både når det gjelder produkt, drift og bruk med tilpasning til de ulike mottakerne av denne dokumentasjonen, og de skal kunne beskrive sin egen arbeidsprosess hensiktsmessig etter gitte standarder. Da gruppen skulle velge hovedprosjekt hadde den noen spesifikke ønsker om hva den ville at prosjektet skulle bestå av. Studentene gikk gjennom de prosjektene som lå ute på skolens hjemmesider, og søkte på de som var interessante. Deretter tok en av studentene kontakt med en bekjent, som driver Granitt Grafisk AS, et gafisk design firma, der de hadde et prosjekt til gruppen. Bedriften holder til på Gran i Hadeland, der vi var på et møte og fikk et lite innblikk i deres hverdag. Etter litt diskusjon av oppgaven, så falt den i interesse for gruppen. 2. Forord Hensikten med dette dokumentet er å beskrive betingelsene og rammene rundt kalkylesystemet til granitt grafisk AS. Funksjonalitet,systemkonstruksjon og dokumentasjonskrav er definert av Gruppen selv, med noen innlegg fra Granitt grafisk. Dokumentet er tilegnet arbeidsgiver og gruppen for oversikt over hva systemet skal inneholde og hvilke krav som skal stilles til det. Dokumentet skal gi et bedre innblikk i hvordan det komplette systemet faktisk skal se ut.

3. Innholdsfortegnelse 1.Innledning 1.1 Presentasjon 1.2 Bakgrunn 2. Forord 3. Innholdfortegnelse 4. Systemkrav 4.1 Funksjonelle krav til kalkyledel 4.2 Funksjonelle krav til administrasjonsdel 4.3 Krav til teknologi 5. Rammekrav 5.1 Sikringskrav 5.2 Krav til bruk og brukervennlighet 6. Krav til dokumentasjon 7. Fremtidige utvidelser av systemet

4. Systemkrav 4.1 Funksjonelle krav til kalkyledel Systemet skal kunne lage en kalkyle av en prisforespørsel med og uten MVA, med hensyn på opplag, format, papir, farger, etterbehandling og arbeidstid. Papirpris skal hentes frem ved å definere papirtype, størrelse og vekt. Papirtyper og format skal bestemmes av en produktdatabase generert ut i fra papyrus sin produktkatalog. Fargetypene skal være de typene Granitt grafisk kan tilby. Systemet skal gi mulighet for utskrift og lagring av kalkylen. Etterbehandling skal inneholde stifting, falsing, skjæring, hulling og innbinding med kalkulering av pris på disse tjenestene basert på opplag. 4.2 Funksjonelle krav til administrasjonsdel Administrator skal sikkert kunne logge inn på systemet, med brukernavn og passord. Systemet skal kunne laste opp prisliste og legge den inn i produktdatabasen. Systemet skal kunne legge til, endre og slette produkter fra databasen. Systemet skal kunne søke etter et produkt ved angitt informasjon. 4.3 Krav til Teknologi Systemet skal utvikles i Java med jre 1.6 Lagring skal skje i mysql dist. 5.1.37 ver 14.14 Applikasjonen skal kunne kjøre på en Windows platform.

5. Rammekrav 5.1 Sikringskrav Databasehåndteringssystemet har mulighet for gjennopretting av databasen. Innlogging med sikkert brukernavn og passord skal sikre systemet for misbruk av data og tyveri. Rammene for kapasiteten til dataene begrenses av minne og diskplass. 5.2 Krav til bruk og brukervennlighet Systemet skal være oversiktig og lett å manøvrere. Informasjonen skal presenteres så fremt det lar seg gjøre til riktig tidspunkt, som bestemt av oppdragsgiver. 6. Krav til dokumentasjon 6.1 Krav til dokumentasjon Det skal føres dagbok for hver dag gruppen jobber med prosjektet og timeplan oppdateres deretter. Det skal skrives referater for alle møter med arbeidsgiver og veileder. Dokumentasjonen skal følge standard for dokumentasjon for hovedprosjekt i data/it utgitt av Høgskolen i Oslo. Ferdigstillt prosjekt skal dokumenteres med: Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon(rapport) Kravspesifikasjon Brukerdokumentasjon(manual)

7. Fremtidige utvidelser av systemet Beregne vekt per produkt ut i fra angitt papirtype og opplag etc. Implementering av metode for å kalkulere hvor mange ark som trengs i for å dekke et opplag, avhengig av arkformatet og hvordan man deler arket. Administrere kalkyler og kunder, med historikk. Statistikkverktøy for oversikt over kundekalkyler.

5.2.2 Fremdriftsplan