Innholdsfortegnelse. Kravspesifikasjon... 2 Prosessrapport... 7 Produktrapport Testrapport Brukermanual... 82

Transkript

1 Innholdsfortegnelse Kravspesifikasjon... 2 Prosessrapport... 7 Produktrapport Testrapport Brukermanual

2 Kravspesifikasjon 1 Presentasjon Tittel: Kundedatabase for Infonor AS Oppgave: Utvikle en database for den nye avdelingen for salg av webknapper og bannere på tv2torget Prosjektperiode: 25. oktober juni 2007 Gruppemedlemmer: Andreas F. Rønning, Christian Lunden, Andreas Hetland Oppdragsgiver: Infonor AS Veileder: Geir Skjevling Kontaktperson: Andre Pettersen 2 Bakgrunn 2.1 Innledning Dettet hovedprosjekt gjennomføres ved avdelingen for ingeniørutdanning ved HiO, i samarbeid med firmaet Infonor AS sin nyoppstartede avdeling for salg av webknapper og bannere. Oppgaven er å opprette en kundedatabase som vil forenkle arbeidsdagen for de ansatte, ved å gi dem mindre papirarbeid samt bedre oversikt over kunder, produkter og selgere. 2.2 Om bedriften Infonor AS er salgsagent for tv2torget, tv2 sitt eget rubrikkannonsemarked. Tv2torget har annonser på tv2 tekst-tv og som er videre linket til alle sidene i tv2 konsernet ( etc.) Bedriften har rundt 50 heltidsansatte som jobber mot bedrifter og næringslivet, samt ca 100 deltidsansatte på kveldstid, hovedsaklig studenter, som selger annonser til det private markedet. 2.3 Bakgrunnen for prosjektet Den nyoppstartede avdelingen for webknapper og bannere på internett, samt bannere på tv2 tekst-tv, har behov for et internt system for å holde orden på en økende kundedatabase. Behovet er ikke 100 % kartlagt enda, så vi vil antageligvis komme med noen endringer underveis. Det er ønske om et system som kan være tilgjengelig for flere brukere i bedriften, fra forskjellige pc-er på nettverket. Det er ønske om et system som kan være tilgjengelig for flere brukere i bedriften, fra forskjellige pc-er på nettverket. Det er også et sterkt behov for å ha bedre oversikt over nøyaktig hvor på en bedrifts annonse/banner befinner seg. Det er mange kategorier og undersider, og per dags dato ingen god ordning for å holde oversikt over dette. 2

3 3 Forord Denne kravspesifikasjonen beskriver betingelsene for prosjektet Kundedatabase for Infonor AS. Kravene til funksjonalitet og rammebetingelser, samt brukergrensesnitt, er beskrevet under. Hovedkravene har blitt spesifisert av Infonor AS. I tillegg kom vi med noen forslag til krav til systemet, som ble godkjent av oppdragsgiver. Vår oppgave blir å løse disse på best mulig måte. 4 Innholdsfortegnelse 1 Presentasjon Bakgrunn Innledning Om bedriften Bakgrunnen for prosjektet Forord Innholdsfortegnelse Systemkrav Krav til registreringssystem Krav til adminsystem Krav til søkemotor Tekniske krav Krav til design Generelle designkrav Designkrav registreringssystem Designkrav adminsystem Designkrav søkesystem Krav til kode Krav til dokumentasjon Utvidelse

4 5 Systemkrav Behovet til oppdragsgiver er å kunne registrere sine kunder på en lettere og mer effektiv måte. Nye kunder registreres manuelt, etter en telefonsamtale mellom kunde og selger. Selgerne som skal bruke programmet jobber på provisjon, og har derfor ikke noe ønske om å bruke mye tid på administrativt arbeid. Overgangen fra papir til webbasert registreringssystem minker sannsynligheten for menneskelige feil. Systemet vil gi tilbakemeldinger om noen felter er feilaktig utfylt. 5.1 Krav til registreringssystem Ansatte skal kunne registrere kunden med nødvendig person- og salgsopplysninger for hvert enkelt salg Ansatte skal kunne registre om kunden har betalt hele beløpet eller eventuelt har noe i rest Det skal registres hvor lenge annonser og bannere skal være i sending Det skal være mulig å registre hvem av de ansatte som har gjort de ulike salgene slik at kan være mulig å få ut en statistikk over dette Automatisk generere ordrebekreftelse, samt sende den ut på mail til kunden 5.2 Krav til adminsystem Det skal være mulig å logge seg inn på systemet som administrator ved ønske om å slette kunde, samt endre kundeinformasjon Her skal det også være mulig å opprette ny selger og adminkonto 5.3 Krav til søkemotor Søkemotoren skal enkelt kunne søke fram kunder, selgere og annen informasjon i systemet Det skal også være mulig å finne ut hvor lenge en annonse skal være ute i sending, samt hvor på kundens produkt(er) befinner seg 5.4 Tekniske krav Utvikles med php Lagring av data går i en MySQL database Applikasjonen skal kunne kjøre på en Windows server Programmet som brukes er PHP Designer 2007 og FrontPage All data er passordbeskyttet og er kun til bruk av ansatte i Infonor 4

5 6 Krav til design 6.1 Generelle designkrav Det viktigste er at det er et brukervennlig grensesnitt Det skal komme tydelig frem hva de forskjellige menyvalg utfører. Det skal være mulig å benytte dette systemet uten å ha veldig gode forkunnskaper i data Utseendet skal være rent og oversiktlig, og det skal være lett å navigere seg i systemet 6.2 Designkrav registreringssystem De ansatte får opp et skjema for registrering av kunder og salg Her får man forståelige feilmeldinger til skjermen om det skulle være noe som ikke er skrevet inn eller skrevet inn feil Det skal være enkelt å forstå hva man skal gjøre til enhver tid, fra første tekstboks er fylt ut, til det skal lagres For at man skal vite hvilke felter som må fylles ut, skal det plasseres en liten rød stjerne ved siden av disse feltene 6.3 Designkrav adminsystem Adminsiden aksesseres ved å trykke på Adminlinken på toppmenyen. Det skal da komme opp en side med login Videre ved vellykket pålogging, får admin opp ulike valg: o Legge til ny admin o Legge til ny selger o Endre kundeinformasjon o Slette kunde 6.4 Designkrav søkesystem Søkesiden skal være oversiktlig og lett forståelig med tanke på hva ansatte ønsker å hente fram av informasjon Når det gjelder søk på salg, skal det ikke være nødvendig å få opp all informasjon om salget, men kun de viktigste opplysningene. Det skal være mulig å kunne hente fram all informasjon om det er ønskelig Banneret skal være lett å lokalisere. Det skal være mulig å få opp banneret enten man søker på kunde, selger eller salg. 5

6 7 Krav til kode Våre krav til koden er: God og oversiktlig kode, da det er viktig for å holde vedlikehold av systemet, samt at eventuelle oppdateringer og utvidelser av andre i fremtiden lettere kan utføres Relevante og forklarende kommentarer slik at det blir lettere å finne fram i koden, samt å forstå hva som blir utført i koden 8 Krav til dokumentasjon Det skal føres dagbok gjennom hele prosjektet Hele prosjektet skal dokumenteres gjennom o prosessrapport o produktrapport o testrapport o kravspesifikasjon o brukermanual Det skal være gjennomgående font og størrelse på brødtekst og overskrifter på alt som dokumenteres 9 Utvidelse I samarbeid med Aktiv Kapital, kunne finne ut om kunden har betalt hele beløpet eller eventuelt hvor mye kunden har i rest 6

7 Prosessrapport 1 Forord Prosessrapporten beskriver gruppens arbeid og hvordan vi har jobbet fram mot det endelige produktet, hovedprosjekt ved Høgskolen i Oslo, avdelingen for ingeniør, datalinjen Medlemmene på gruppa er: Andreas Hetland Christian Lunden Andreas Frøhne Rønning Vår oppdragsgiver er en avdeling for webbaserte bannere og webknapper, hos Infonor AS. Infonor er salgsagent for tv2torget, TV2 sitt eget rubrikkannonsemarked. Dagens system er basert på manuelt utfylte skjemaer, og oppbevaring i permer. Vårt mål har vært å forenkle dette, ved å lage en database for registrering av avdelingens egne kunder. Et av gruppemedlemmene er ansatt ved bedriften og behovet for et enklere registreringssystem er tydelig tilstedet. Vi tok kontakt med oppdragsgiver og la opp et forslag for et nytt system de kunne være fornøyde med. Registrering går fortere og enklere, det er mindre mulighet for menneskelige feil, det er mulig å fort kunne søke fram ønskelige opplysninger og webknappene vil være mye enklere å lokalisere. Dokumentet er optimalisert for papir og er beregnet for sensor, veileder og oppdragsgiver, samt andre som måtte være interesserte. Vi vil gjerne takke følgende personer for deres hjelp og veiledingen gjennom hele fasen: Intern veileder, Geir Skjevling, som har støttet og fulgt oss opp gjennom hele hovedprosjektet Kontaktperson, Andre Pettersen, ved Infonor for hans krav og synspunkter til oppgaven Kontaktperson, Anders Tautra, ved Infonor avdeling for webknapp for hans ideer og tanker Ann-Mari Torvatn som med sin dokumentasjonstandard for hovedprosjekt har vært til stor hjelp gjennom hele perioden 7

8 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Innledning Om bedriften Dagens situasjon Mål Rammebetingelser Krav til registreringssystem Krav til adminsystem Krav til søkemotor Tekniske krav Planlegging og metode Planlegging Planlegging av selve prosjektet Planlegging av databasen Implementering av systemet Systemtilgang Planlegging i praksis Metode Systemering Verktøy Tilbakemeldinger Utviklingsprosessen Prosjektstart Dialog med oppdragsgiver Prosjektets faser Innledende arbeid Forprosjektfasen Planleggingsfasen Lærefasen Programmeringsfasen Testfasen Dokumentasjonsfasen Avslutningsfasen Faglige problemer/utfordringer Tilbakeblikk Løsninger på oppståtte problemer Uforskyldte problemer Kravspesifikasjon Endringer fra første versjon Kravspesifikasjonens rolle Kravspesifikasjonen i dag Avvik Konklusjon Oppsummering Hva kunne vært gjort bedre Kildehenvisning

9 3 Innledning 3.1. Om bedriften Infonor AS er salgsagent for tv2torget, tv2 sitt eget rubrikkannonsemarked. Tv2torget har annonser på tv2 tekst-tv og som er videre linket til alle sidene i tv2 konsernet ( etc.) Bedriften har rundt 50 heltidsansatte som jobber mot bedrifter og næringslivet, samt ca 100 deltidsansatte på kveldstid, hovedsaklig studenter, som selger annonser til det private markedet. 3.2 Dagens situasjon Den nyoppstartede avdelingen for webknapper og bannere på internett, samt bannere på tv2 tekst-tv, har behov for et internt system for å holde orden på en økende kundedatabase. Behovet er ikke 100 % kartlagt enda, så vi vil antageligvis komme med noen endringer underveis. Det er ønske om et system som kan være tilgjengelig for flere brukere i bedriften, fra forskjellige pc-er på nettverket. Det er også et sterkt behov for å ha bedre oversikt over nøyaktig hvor på en bedrifts annonse/banner befinner seg. Det er mange kategorier og undersider, og per dags dato ingen god ordning for å holde oversikt over dette. 3.3 Mål Målet med oppgaven er å lage en database med informasjon om kundene til webknappavdelingen til Infonor og deres produkter. Systemet skal: Holde orden på kunder og deres produkter Ha oversikt over hvilken periode annonser og bannere skal være i sending Registrere om kunden har betalt, og eventuelt hvor mye de har i rest. Kunne lokalisere hvor i systemet disse produktene befinner seg Lett kunne finne bedriftens selgere og deres tilhørende kunder Lagre bannere/webknapper til eventuelt senere bruk Inneholde en søkemotor for kunder, selgere og bedrifter Automatisk generere ordrebekreftelser 3.4 Rammebetingelser Programmet må kunne kommunisere med en MySQL database. Programmet skal ligge på Infonor sin server, og være tilgjengelig for alle på nettverket Windows plattform Brukervennlig GUI 9

10 3.5 Krav til registreringssystem Ansatte skal kunne registrere kunden med personopplysninger som navn, adresse, telefon og annen personalia Ansatte skal også kunne registre om kunden har betalt hele beløpet eller eventuelt har noe i rest I tillegg skal det registres hvor lenge annonser og bannere skal være i sending Det skal også være mulig å registre hvem av de ansatte som har gjort de ulike salgene slik at kan være mulig å få ut en statistikk over dette 3.6 Krav til adminsystem Det skal være mulig å logge seg inn på systemet som administrator Admin skal kunne slette og endre kunder, samt legge til adminkonto og ny selger 3.7 Krav til søkemotor Søkemotoren skal enkelt kunne søke fram kunder, selgere og annen informasjon i systemet Det skal også være mulig å finne ut hvor lenge en annonse skal være ute i sending, samt hvor kundes produkt(er) befinner seg 3.8 Tekniske krav Utvikles med PHP Lagring av data går i en MySQL database Applikasjonen skal kunne kjøre på en Windows server Programmet som brukes er PHP Designer

11 4 Planlegging og metode 4.1 Planlegging Planlegging av selve prosjektet Selve prosjektet startet da vi oktober og november 2006 begynte med henholdsvis statusrapport og prosjektskisse. Det ble på dette tidspunktet klart hva vi skulle utvikle. Planlegging av selve prosjektet startet rett over nyttår med forprosjektfasen. Her gikk vi dypere inn på utviklingen av prosjektet. Vi opprettet mål og rammebetingelser, samt alternativer til løsning. Gjennom flere møter med arbeidsgiver ble ønsker og krav til systemet kartlagt. Ut fra dette startet vi utformingen av kravspesifikasjonen. I løpet av januar utarbeidet vi en arbeidsplan og fremdriftsplan. Arbeidsplanen beskrev fasene gruppa skulle gjennom og når de skulle være ferdige. Dette la grunnlaget for fremdriftsplanen. Vi satte opp tidsfrister og mål slik at de skulle være så realistiske som mulig. Prosjekthjemmesiden vår ble utviklet under denne startfasen. Siden lå først ute på hjemmeområdet til et av gruppemedlemmene, men ble lagt ut på tildelt område på cube for hovedprosjekt mot slutten av startfasen. Vi følte at det å ha et førsteutkast av kravspesifikasjonen så tidlig som mulig ville være lønnsomt, med tanke på å fort danne oss et bilde av systemet som skulle utvikles. Vi tok kontakt med oppdragsgiver for å samkjøre kravspesifikasjonen med deres tanker og ønsker, samt få eventuelle nye ønsker eller ideer Planlegging av databasen Ut i fra kravspesifikasjonen begynte vi å planlegge databasen ved å sette opp et ER-diagram, hvor vi førte opp alle tabellene systemet trenger. Deretter opprettet vi en-til-mange relasjoner mellom tabellene. Neste steg var å legge til de variablene vi følte var nødvendige for så å definere primærnøkler og fremmednøkler. Vi følte på dette tidspunktet at vi hadde et godt utgangspunkt for utviklingen av databasen Implementering av systemet Oppdragsgiver hadde ingen spesielle ønsker verken til utviklingsspråk eller utviklingsverktøy. Vi bestemte oss for å utvikle systemet ved bruk av PHP og MySQL, samt noe bruk av JavaScript. Det var ikke fast bestemt på forhånd at JavaScript skulle implementeres, men vi fant tidlig i prosessen at det ville være gunstig for oppgaven vår å implementere dette med i løsningen. For å opprette databasen vår benyttet vi oss av MySQL Query Browser. Vi følte at dette var et godt og stabilt vertkøy for å sette opp databasen og dens relasjoner Systemtilgang Vi bestemt oss tidlig for tilgangen til systemet skulle deles i to parter, admin og ansatt. Admin skulle ha alle rettigheter til alle kunder, mens ansatt kun har rettigheter til å endre sine egne 11

12 kunder. Første tanke var å ha en startside med login hvor man entrer systemet enten som admin eller ansatt. Men siden de ansatte får de rettighetene han skal ha ved å logge seg inn på pc en, valgte vi å kun legge til en login for administrator. Ved å logge seg inn her får han tilgang til de valgene man skal ha som administrator Planlegging i praksis Ved å lage en god og detaljert fremdriftsplan, er det mye lettere å ha kontroll på arbeidet, samt å få gjort det man skal innen de satte tidsfristene. Klarer man å følge disse til punkt og prikke er det veldig bra. Men det er dessverre ikke alltid like lett, da sykdommer og andre uforutsigbare hendelser kan dukke opp. Forutsigbare hendelser, som vinterferie og påskeferie, prøvde vi å ta hensyn til da vi satt opp arbeidsplanen og fremdriftsplan. 4.2 Metode Systemering Det oppdragsgiver ville ha, var en applikasjon til lokalt bruk. De var ikke ute etter å en web applikasjon for å publisere på web. De ønsker at databasen kun skulle være tilgjengelig for de ansatte, på nettverket. Slik situasjonen var hos oppdragsgiver når kunder skulle legges til, ble et skjema med kundeinformasjon fylt ut og levert videre til fakturering. Vi fant ut at det ville være veldig gunstig å lage et registreringsskjema som lignet det de var kjent med fra tidligere. Dette ble da prototypen vi gikk ut ifra, noe som gjør skjemaet vi utviklet gjenkjennelig for de ansatte. Grunnen til at vi valgte å gjøre det slik var for å spare tid hos oppdragsgiver, med tanke på å bli kjent med et nytt system Verktøy De verktøyene vi har benyttet for å utvikle systemet vårt er følgende: MySQL Query Browser MySQL server 5.2 PHP Designer 2007 Apache http server FrontPage 2003 Vi valgte disse vertøyene ut ifra forkunnskaper og kvalitet. Når det gjelder verktøy innen MySQL, bestemte vi oss for å benytte oss av det de nyeste produktene som var tilgjengelige. Vi var fornøyd med den nyeste versjonen av PHP Designer, men verktøyet kunne ha vært noe bedre med tanke på tilbakemeldinger, som for eksempel feilmeldinger. Til syvende og sist har verktøyet vært en god ressurs. 12

13 4.2.3 Tilbakemeldinger Vi har hatt god kommunikasjon med oppdragsgiver gjennom hele perioden. Et av gruppemedlemmene er ansatt hos oppdragsgiver så det har vært jevnlig kontakt. Ellers har vi hatt møter da det var nødvendig blant annet for å snakke om den endelige kravspesifikasjonen, samt utseende av systemet. Vi har også kommunisert via e-post, telefon og MSN Messenger. 5 Utviklingsprosessen 5.1 Prosjektstart Vi er en gruppe som har jobbet fast sammen i 2 år, så valget av gruppemedlemmer falt ganske naturlig da vi skulle starte hovedprosjektet. Da vi skulle bestemme oss for prosjektoppgave, startet vi med å kontakte noen av bedriftene som hadde sendt forslag til skolen, uten å få tilslag på noe særlig av interesse. Så vi fant fort ut at det ville være bedre å komme opp med et eget forslag. Et av gruppemedlemmene kom istedenfor opp med et bra prosjekt for sin egen arbeidsgiver, Infonor AS, hvor han har jobbet deltid i en del år. 5.2 Dialog med oppdragsgiver Siden et av medlemmene av gruppa jobber for oppdragsgiver, hadde vi en ganske god ide om hvilke krav og ønsker som ville stilt til systemets funksjonalitet. Vi hadde et møte med kontaktpersonen i Infonor tidlig i januar, hvor mer konkrete ønsker ble skrevet ned og vi utarbeidet en kravspesifikasjon. Etter dette har vi hatt en jevnlig dialog, hvor gruppa har tatt opp saker og spørsmål underveis som det har dukket opp. 5.3 Prosjektets faser Innledende arbeid Gruppas første jobb var å finne et passende prosjekt vi alle ønsket å jobbe med. Vi startet med å sende e-post til et par av oppdragsgiverne som hadde kommet med forsalg til skolen, uten at vi fikk tilslag på disse øyeblikkelig. Da vi skjønte at de mest populære oppdragene fort ble revet bort, kom vi opp med en ide om å gjøre et prosjekt for Infonor AS, hvor en av gruppemedlemmene jobber deltid, ved siden av studiene. Prosjekthjemmeside En midlertidig hjemmeside for prosjektet ble opprettet og lagt ut på et av gruppemedlemmenes hjemmeområde på skolen Statusrapport Statusrapport var ferdigskrevet og publisert 27/10/06 Prosjektskisse En skisse som beskrev oppdragsgiver, gruppemedlemmer og prosjektet ble publisert på prosjekthjemmesiden 01/12/06 13

14 Prosjektdagbok Vi skrev ned alt arbeid vi gjorde i en prosjektdagbok fra dag én. Dette har hjulpet oss i å holde oversikt over alt arbeid vi har gjort, og til hvilken tid Forprosjektfasen Forprosjektdelen begynte rett etter nyttår. Her satt vi opp en plan over hvordan vi ville disponere tiden, og gjorde oss opp noen meninger om fordeling av arbeidsoppgaver. Arbeidsplan I arbeidsplanen satt vi opp alt arbeid som måtte gjøres med prosjektet, med en forklaring til de forskjellige punktene. Vi satt også opp en oversikt over hvilke uker vi ville bruke til de forskjellige oppgavene. Fremdriftsplan Fremdriftsplanen satt vi ned på grunnlag av arbeidsplanen. Her prøvde vi å beregne når vi ville være ferdig med forskjellige arbeidsoppgaver og hvor mye tid vi skulle sette av til hver av dem. Forprosjektrapport Forprosjektrapporten er utarbeidet etter at forprosjektfasen er sluttet. Dette er en mer detaljert prosjektskisse, hvor vi også utredet mål for prosjektet, rammebetingelser, hvordan vi ville løse prosjektet, samt en analyse av hvordan prosjektet skal implementeres i bedriften. Veileder Alle gruppene fikk tildelt en intern veileder Planleggingsfasen Her planla vi selve systemet vi skulle utvikle. Dette gjorde vi ut i fra en kombinasjon av ønsker fra oppdragsgiver, tid vi hadde til disposisjon og hvilke ideer vi selv hadde til systemet. Kravspesifikasjon Kravspesifikasjonen ble skrevet etter av vi i samarbeid med oppdragsgiver fikk ned alle ønsker og tekniske krav til systemet. Database Vi begynte å skissere databasen på ark ganske tidlig, og utformet et ER-diagram, som vi senere brukte til å opprette den ferdige databasen. Brukergrensesnitt Skjemaet for registrering av nye kunder er basert på et skjema bedriften benytter seg av fra før. Vi ønsket å benytte et skjema som var mest mulig likt dagens, for å gjøre det enklest mulig for brukerne å komme i gang. Utseende på GUI ellers skisserte vi på ark, før rammene ble laget i FrontPage med HTML. 14

15 5.3.4 Lærefasen PHP og MySQL er verktøy vi er temmelig kjent med fra før, da vi har vært borti disse fra før i faget Relasjonsdatabaser. Videre har vi brukt forskjellige ressurser fra internett for å friske opp kunnskapene, samt til finne svar på problemer som har dukket opp underveis Programmeringsfasen Starten ble preget av en del problemer med oppsett av MySQL og PHP. Da dette var i orden var det nødvendig å få opp et brukergrensesnitt, for å kunne begynne kodingen. En enkel ramme av programmet ble laget, og programmering av funksjonalitet kunne begynne. Vi har funnet det naturlig å programmere etter en iterativ modell, hvor vi har gjort små endringer på programmets forskjellige funksjoner etter hvert som problemer eller løsninger har dukket opp. Programmeringen i startfasen bar hovedsakelig preg av å få funksjonaliteten på plass. Etter hvert som produktet har tatt form har vi konsentrert oss mer om brukervennlighet og design. Vi hadde instrukser fra oppdragsgiver om å lage et så enkelt og brukervennlig design som mulig. Selgerne som skal bruke programmet jobber på provisjon, og har derfor ikke noe ønske om å bruke mye tid på administrativt arbeid. På grunnlag av dette har brukergrensesnittet og designet av systemet hele tiden vært laget med tanke på effektivitet og brukervennlighet. Arbeidet har stort sett foregått på skolen i fellesskap, men med bestemte individuelle oppgaver. Vi har funnet det nyttig å arbeide samlet da det har vært lett å ta opp problemer og spørsmål med resten av gruppa, med en gang noe har dukket opp. På grunn av tidvis dårlig arbeidsforhold, mye grunnet situasjonen med fraflyttingen fra skolen, har vi også funnet det fordelaktig å jobbe individuelt hjemme. Da har vi på forhånd tildelt arbeidsoppgaver, for så å samkjøre arbeidet på skolen dagen etter Testfasen Grundig testing av et system er en viktig prosess for feilsøking. Vi har testet systemets funksjoner underveis i programmeringsfasen, men ønsket en mer formell testing av det ferdige produktet. Vi valgte derfor å teste tre personer med forskjellig bakgrunn og kompetanse; veileder for hovedprosjektet, ansatt ved oppdragsgiver og en student ved HiO. Testingen gikk ut på at vi satte opp noen naturlige scenarioer for å få testet alle funksjonene til programmet, for deretter å få testpersonene til å gjennomføre dette med minst mulig assistanse. På denne måten får vi både undersøkt at alt virker som det skal, og at GUI er brukervennlig. 15

16 5.3.7 Dokumentasjonsfasen Mot slutten av programmeringsfasen begynte vi dokumentasjonsfasen. Her skulle vi sluttføre styringsdokumentene og skrive sluttrapport. Statusrapport, prosjektskisse, prosjektrapport, arbeidsplan, fremdriftsplan, forprosjektrapport og kravspesifikasjon var alle skrevet i forprosjektfasen og underveis i programmeringsfasen, og trengte bare noen få endringer og rettskriving. Med sluttrapporten begynte vi med produktrapporten og prosessrapporten i programmeringsfasen. Det har vært veldig fint å jobbe med disse underveis, for å få ned detaljer mens de enda var friskt i minne. Produktrapporten er hovedsaklig beregnet på de som skal oppdatere og vedlikeholde systemet, og er en grundig beskrivelse av programmets oppbygning, filer i systemet og forklaring på noen vesentlige funksjoner og kommandoer. Prosessrapporten dokumenterer hele prosessen vi har gått gjennom, fra planlegningen i oktober til sluttdokumentasjonen i mai. Ellers har dokumentasjonsfasen bestått av å lage testrapport, samt å sette sammen brukermanualen Avslutningsfasen Siste del av prosjektet startet vi 14 dager før levering. Her har vi satt sammen alle dokumentene, korrekturlest dokumentasjonen, skrevet ut dokumentasjon i 4 eksemplarer. Vi startet også på planlegging av muntlig presentasjon. 5.4 Faglige problemer/utfordringer Tilbakeblikk Vi skulle ikke lage et program som skulle erstatte dagens database, men et tilleggsprogram for en avdeling. Vår største utfordring i forhold til dette har vært problematikken med kundenummer. Problemet ligger i at kunden ikke har et kundenummer når vi skal registrere den i vårt system, men det er viktig at den senere blir tildelt riktig kundenummer i forhold til hoved-systemet. I planleggingsfasen ble det ytret et ønske fra oppdragsgiver om en mulighet for å ha oversikt over kundens innbetalinger og hvor mye de har i eventuell rest. Dette har vist seg å bli problematisk på grunn av at Infonor benytter seg av en ekstern fakturaadministrasjon, Aktiv Kapital. Vi ønsket å ha mulighet automatisk generering av ordrebekreftelse, for så å sende dette med e-post til kunden. Dette har bydd på problemer, siden vi ikke har hatt tilgang til en mail-server på skolens nettverk. 16

17 5.4.2 Løsninger på oppståtte problemer Måten vi har løst kundenummerproblematikken har vært at man er nødt til å manuelt skrive inn det tildelte kundenummeret når man skal laste opp et banner. Dette vil passe perfekt inn i dagens rutiner, og kunder blir tildelt riktig kundenummer. Betalingsoversikt har vi ikke implementert, da dette rett og slett ikke lot seg gjøre. I stedet får bedriften fortsette å benytte seg av dagens system, som fungerer veldig bra. Utsendelse av e-post har heller ikke blitt implementert. Her må også bedriften fortsette med å bruke dagens system, hvor ordrebekreftelser lages manuelt og sende fra ordinær e-postklient Uforskyldte problemer Gruppen har ikke støtt på noen store problemer underveis. Eneste nevneverdige må være litt problemer i starten med å få Apache til å fungere på alle gruppemedlemmenes private datamaskiner, på grunn av forskjellige versjoner av Windows. Vi har også tidvis hatt litt problemer med å finne arbeidsplass og arbeidsro på skolen, på grunn av situasjonen med fraflyttingen og oppussing av gamlebygget. 6 Kravspesifikasjon Kravspesifikasjonen ble dannet etter møte med oppdragsgiver, der vi fikk høre eventuelle ønsker og krav de hadde, samtidig som vi la frem våre ideer og synspunkter. Selv om kravspesifikasjon skal ses på som en kontrakt mellom prosjektgruppen og oppdragsgiver, er det muligheter for forbedring om det skulle komme opp bedre ideer og løsninger. 6.1 Endringer fra første versjon Første versjonen ble skrevet i forprosjektfasen og ble dannet etter hvordan oppdragsgiver og vår gruppe så for seg hvordan systemet ville se ut. Allerede i startfasen under kodingen av systemet, fant vi ut at enkelte krav var vage og noen funksjoner ikke var helt optimale. Derfor bestemte gruppen seg for å ordne et møte til med oppdragsgiver for å klargjøre enkelte punkter og vurdere eventuelle endringer som skulle tas. 6.2 Kravspesifikasjonens rolle I første fase av prosjektet visste vi at vi måtte lage en god kravspesifikasjon for å ha et godt grunnlag som vi kunne bygge videre på. Dette gjorde det enklere for oss å holde rede på hvordan vi lå an og hva som måtte gjøres. Samtidig fant vi ut underveis at noen punkter i kravspesifikasjonen måtte forbedres slik at vi kunne oppnå et best mulig resultat. Under selve utviklingen av systemet, brukte vi kravspesifikasjonen som et oppslagsverk. Dette var fordi det hendte at noen av oss glemte hva som var neste gjøremål eller de krav som ble stilt for en funksjon. 17

18 I designet ble det lagt stor vekt på det som sto i kravspesifikasjonen at det skulle være et brukervennlig GUI. Oppdragsgiver ville også at det skulle være lett å navigere og finne fram uten at en måtte ha veldige gode forkunnskaper i data. 6.3 Kravspesifikasjonen i dag Dagens versjon av kravspesifikasjonen er bortimot oppfylt. Kun to av punktene lot seg ikke gjøre eller var noe uklart fra tidlig i prosessen. Avvikene står forklart nærmere i punktet under, men kravet om betaling lot seg ikke gjøre da dette, som nevnt tidligere, går via Aktiv Kapital. Det andre punktet skyltes litt dårlig kommunikasjon med tanke på systemtilgang. Vi føler allikevel at dette punktet ble løst på en bra måte i etterkant Avvik Registrering Et av våre krav til registreringssystemet var at vi ønsket at det skulle være mulig registre om kunden har betalt hele beløpet eller eventuelt har noe i rest. Vi oppdaget at dette ville være et problem, da det går gjennom Aktiv Kapital, og vi valgte å gå vekk fra dette kravet. Systemtilgang Et annet krav vi fort oppdaget at måtte endres, var systemtilgangen. Vi så får oss at de skulle være to brukere på systemet, admin og ansatt. Slik det er hos oppdragsgiver, får brukeren ulike rettigheter ved pålogging på pc en. Dermed ble det ikke nødvendig med en ny pålogging på vårt system. Vi valgte da å lage kun en admin logginn hvor det er mulig og endre og slette kunder på systemet, samt å legge til ny selger og admin. Ordrebekreftelse Opprinnelig var det ønskelig å generere en ordrebekreftelse automatisk, for så å kunne sende den pr e-post eller skrive den ut, for å sende den pr post. Vi får skrevet bekreftelsen til skjerm, og får skrevet den ut på ark. Men vi har ikke fått til å sende ut ordrebekreftelsen på e-post, da dette ikke lar seg gjøre på skolens netteverk. Vi har fremdeles ett håp om å dette til å fungere når vi får implementert systemet hos Infonor, hvor vi kan bruke deres mail-server. 18

19 7 Konklusjon 7.1 Oppsummering Når prosjektet nærmer seg slutten, og vi snart skal levere, er hele gruppa enige om at vi er godt fornøyd med resultatet. Samarbeidet i gruppa har også fungert veldig bra. Vi har erfart hvordan god planlegging og strukturering av arbeidet har gitt resultater, og sett hvordan systemet vårt har utviklet seg fra en ide til et ferdig produkt, noe som har vært meget tilfredsstillende. 7.2 Hva kunne vært gjort bedre Etter å ha jobbet med et prosjekt over lang tid har vi plukket opp noen nye erfaringer. Blant annet viktigheten av å være nøyaktig helt fra starten, for å slippe følgefeil som må rettes opp mot slutten. Vi har også forstått at det har vært mulig å få subsidiert programvare fra skolen, noe vi kunne hatt behov for. 8 Kildehenvisning

20 Produktrapport 1 Forord Denne produktdokumentasjonen er ment for de som skal markedsføre, vedlikeholde og oppdatere registrerings- og adminsystemet, samt søkemotoren. Denne dokumentasjonen går dypere inn på hvordan hele systemet er bygd opp og satt sammen. Det er benyttet noen tekniske og IT relaterte terminologier så kjenneskap til disse vil være nødvendig. 20

21 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Innledning Om bedriften Dagens situasjon Mål Rammebetingelser Konklusjon Produktet Hensikt Toppmenyen Beskrivelse av registreringssystem Beskrivelse av adminsystem Beskrivelse av søkemotoren Beskrivelse av ordrebekreftelse Beskrivelse av banner upload Beskrivelse av gjensalg Krav og installasjon Installasjon av Apache webserver Installasjon av PHP Installasjon av MySQL Server Teknologi Apache webserver HTML PHP MySQL SQL Datastruktur og oppbygning Databasestruktur Tabellforklaringer Kunde Ansatt Banner Salg Admin Salg_kunde Programmets oppbygning Dagens system Tilpassing Funksjoner Datofunksjonen MySQL INSERT MySQL søk Selgernavn og Poststed Unikt filnavn og opplasting av banner Mappestruktur og filer Adminmappen

22 7.4.2 Gjensalgmappen Regkundemappen Stilarkmappen Searchmappen Uploadmappen

23 3 Innledning 3.1. Om bedriften Infonor AS er salgsagent for tv2torget, tv2 sitt eget rubrikkannonsemarked. Tv2torget har annonser på tv2 tekst-tv og som er videre linket til alle sidene i tv2 konsernet ( etc.) Bedriften har rundt 50 heltidsansatte som jobber mot bedrifter og næringslivet, samt ca 100 deltidsansatte på kveldstid, hovedsaklig studenter, som selger annonser til det private markedet. 3.2 Dagens situasjon Den nyoppstartede avdelingen for webknapper og bannere på internett, samt bannere på tv2 tekst-tv, har behov for et internt system for å holde orden på en økende kundedatabase. Behovet er ikke 100 % kartlagt enda, så vi vil antageligvis komme med noen endringer underveis. Det er ønske om et system som kan være tilgjengelig for flere brukere i bedriften, fra forskjellige pc-er på nettverket. Det er også et sterkt behov for å ha bedre oversikt over nøyaktig hvor på en bedrifts annonse/banner befinner seg. Det er mange kategorier og undersider, og per dags dato ingen god ordning for å holde oversikt over dette. 3.3 Mål Målet med oppgaven er å lage en database med informasjon om kundene til webknappavdelingen til Infonor og deres produkter. Databasen skal: Holde orden på kunder og deres produkter Ha oversikt over hvilken periode annonser og bannere skal være i sending Registrere om kunden har betalt, og eventuelt hvor mye de har i rest. Kunne lokalisere hvor i systemet disse produktene befinner seg Lett kunne finne bedriftens selgere og deres tilhørende kunder Lagre bannere/webknapper til eventuelt senere bruk Inneholde en søkemotor for kunder, selgere og bedrifter Automatisk generere ordrebekreftelser 3.4 Rammebetingelser Programmet må kunne kommunisere med en MySQL database. Programmet skal ligge på Infonor sin server, og være tilgjengelig for alle på nettverket Windows plattform Brukervennlig GUI 23

24 3.5 Konklusjon Det nye systemet vil gjøre hverdagen lette for Infonor med tanke på tid og papirarbeid. gjøre det lette for de ansatte og finn fram informasjon om kunder og deres produkter, samt kunne lokalisere disse produktene. helt enkelt gi Infonor en bedre søkemotor på en enklere måte registrere kunder rett inn i en database 4 Produktet 4.1 Hensikt En av hensiktene med systemet vårt er enkle hverdagen og være tidsbesparende for oppdragsgiver, Infonor. Dagens system er basert på manuelt utfylte skjemaer og oppbevaring i permer. Vi ønsket å lage kundedatabase for å få bedre oversikt over alle kunder, samt registre kunder på en enklere og mer oversiktlig måte. En annen hensikt med produktet vårt er at det skal være lett å lokalisere informasjon om kunder, ansatte og web-bannere til kundene. Det skal være mulig for oppdragsgiver å endre og slette kunde etter ønske fra databasen, kun administrator har rettigheter. 4.2 Toppmenyen På toppmenyen vår har vi valgt å plassere linkene til hovedsidene i systemet. Vi plasserte ikoner over disse linkene for å øke forståelsen av systemet. Disse ikonene er en form for metaforer som gir gjenkjennelse og tydeligere uttrykk for hva de ulike linkene utfører. En blyant symboliserer å skrive. I vårt tilfelle betyr det å skrive inn kundeinformasjon og salgsinformasjon man trenger for å Registrere kunde og salg En PDA (Personal Digital Assistent) kan symbolisere noe visuelt, en skjerm. Vi brukt dette ikonet til banneret da dette er det synlige produktet til kunden En skanner kan symbolisere og legge inn noe som eksisterer fra før. Vi har valg å bruke dette ikonet ved registrering av et gjensalg En lommelykt kan symbolisere hjelp for å finne fram til noe. I vårt system betyr det å søke fram ønsket informasjon Fig 1: Menyvalg Hånden som holder jorda kan symbolisere noen som har full kontroll. I vårt tilfelle en administrator som har alle rettigheter 24

25 4.3 Beskrivelse av registreringssystem Det første de ansatte får opp når systemet kjøres, er en indexside hvor ansatte kan velge ønsket operasjon. Det første som må gjøres er å trykke på linken CREATE-script. Dette fordi da opprettes en database med nødvendige tabeller. For å registrere ny kunde, trykker man på liken Registrer ny kunde og salg. Da for man opp et skjema som skal fylles ut: Fig 2: Skjema for Registrer Ny Kunde og Salg 25

26 Vi tok utgangspunkt i papiroppsettet oppdragsgiver benyttet for registrering av kunder fra tidligere. Vi valgte å gjøre dette slik at systemet skulle være gjenkjennelig for de ansatte. Skjema for kunderegistreringen er opprettet slik at stort sett alle felter må fylles ut av ansatte. Det er lagt inn valideringer som sørger for at riktig informasjon blir skrevet inn i riktige felter. Telefonnummer kan for eksempel ikke være annet en tall. Hvis det skulle forekomme at det som er fylt ut, er feil, for man opp feilmeldinger som forklarer hvorfor. Disse valideringstestene er veldig sentrale for oppbygningen av registreringssystemet vårt. Informasjonen de ansatte plotter inn i skjemaet blir sendt til databasen. Fig 3: Nummervalidering Vi har også implementert en funksjon for å forenkle registreringsprosessen med tanke på dato. Hvor mange dager skal webbannerne ligge ute, samt fra- og til-dato. Det vi gjorde var å lage en funksjon som beregner dette problemet automatisk. Når man plotter inn for eksempel 90 dager i feltet til antall dager og trykker på neste felt, kommer dagens dato automastisk opp. Når man går til neste felt igjen, beregnes dagens dato med 90 dager senere og den genererte datoen kommer fram i tildatofeltet. Det er mulig å skrive inn en annen dato enn dagens i fradatofelten. Da beregnes antall dager ut ifra denne datoen. Trinn1: Trinn 2: Trinn 3: Endre dagens dato: Trinn 1: Trinn 2: Fig 4: Datoinput 26

27 Når det gjelder krav til hvilke felter som må fylles ut, har vi valgt å sette en liten rød stjerne ved siden av de boksene. Dette valgte vi å gjøre fordi de fleste som har litt datakunnskaper innen registrering på nett, har sett dette før og er kjent med det. Felter hvor disse stjernene ikke forekommer, er valgfrie. Fig 5: Nødvendige felter Når det skal registreres hvor webknappen skal ligge, er det tre muligheter å velge mellom. Den ene er forsiden, mens de to andre er henholdsvis kategoriside og underside. Forside er selvforklarende, mens kategoriside menes det at webknappen skal kunne ligge for eksempel under kategorien Bil. Underside er igjen en kategoriside for kategori som for eksempel Peugeot, som da er en underside av kategorien Bil. Det er mulig å velge alle tre, forside, kategoriside og underside, hvis det er ønsket. Har man valgt enten kategoriside eller underside, må man også fylle ut hvilken side. Skulle dette ikke bli fylt ut, får man som nevnt tidligere en feilmelding. Fig 6: Feltvalidering Når man trykker på lagre, sendes informasjonen til riktige tabeller og man får opp en utskriftsside med en unik salgsid. Nederst på siden er det en printknapp som skriver ut skjemaet. Denne utskriften har vi valgt å gi hvit bakgrunn med tanke på at det skal skrives ut mange av disse: 27

28 Fig 7: Utskrift Registrert Ny Kunde og Salg 4.4 Beskrivelse av adminsystem Da vi skulle gå i gang med denne prosessen hadde vi som utgangspunkt å ha en startside hvor oppdragsgiver kunne logge seg inn som admin eller ansatt. Etter samtaler med oppdragsgiver fant vi ut at vi måtte gjøre noen modifikasjoner. Måten det ble gjort på hos oppdragsgiver var at man logget seg inn på pc en med sitt eget brukernavn og fikk tildelt rettigheter deretter. Det vi ble enige om gjøre da, var å implementere en innloggingsside hvor kun admin kunne logge inn å gjøre ønskede valg. Når administrator er logget på, er det mulig å endre og slette de kundene som måtte være ønsket, samt legge til ny admin og selger. 28

29 I det man trykker på Adminlinken på toppmenyen, får man opp en login: Fig 8: Logg inn Denne logginnsiden sender data som blir skrevet inn til sjekklogin.php, hvor det blir sjekket opp mot databasen. For å få til dette benyttet vi oss av PHP sine innebygde funksjoner, for å koble applikasjonen til database og for å sjekke opp mot databasen om data stemte overens. Validering av data blir utført med bruk av PHP session, der brukernavn og passord blir midlertidig lagret i egne session variabler for så å kunne hente det opp til senere bruk. Dette blir også brukt til for å sende en tilbakemelding til brukeren at brukernavn og passord stemmer og at man da kommer videre til selve adminmenyen. Passordet blir kryptert ved bruk av md5 funksjonen i php for å få et sikrere system. Dette gjør vi for at det ikke skal kunne leses ut ifra databasen hva passordet til de forskjellige administratorene er. 29

30 Fig 9: Administrator menyen Et av valgene en admin kan gjøre på dette systemet er å legge til en adminkonto. Fig 10: Opprett ny adminkonto Her blir også data lagret i sessionvariabler og sendt videre til regadmin.php. Feltene blir sjekket at de ikke er tomme før det blir lagt til noe i databasen. Dette gjøres ved hjelp av en innebygd funksjon i PHP empty(). Spørringen til databasen som foregår i regadmin.php om det eksisterer en admin ved samme navn fra før, blir også lagt til i en sessionvariabel. Før variabelen kommer så langt blir det sjekket om den inneholder kun små eller store bokstaver, dette gjøres ved hjelp av ereg(). Dette er en funksjon som sjekker om stringen/variablen 30

31 inneholder det du setter den til å inneholde. Passordet som blir valgt, krypters ved hjelp av PHP sin md5 funksjon og deretter lagt inn i databasen. Til slutt blir alle disse variablene sendt tilbake om en sjekk slår til eller etter at alle data har blir prosessert i koden. Da får brukeren en tilbakemelding på om han har fått registrert en ny admin eller om han da har gjort noen feil. Valg nummer to er å legge til en selgerkonto: Fig 11: Opprett ny selger Data som blir skrevet inn her blir sendt videre ved hjelp av HTML variabler som $_POST og blir satt til andre variabler i regselger.php. Som i regadmin.php benytter vi empty() funksjonen for å forhindre at det ikke blir lagret tomme felter i databasen. Videre blir det sjekket ved hjelp av ereg() funksjonen om det er tall fra 0 til 9 i selgernummeret eller ikke. Om det ikke er tilfelle vil det bli lagt til i sessionvariabel at det ikke gikk og sendt tilbake som feilmelding. SQL spørringen vil også sjekke i databasen om det finnes en selger fra før med samme selgernummer og gi en tilbakemelding i form av sessionvariabler. Neste valg er å endre kundeinformasjon. Første steg er å skrive inn ønsket kundenummer i feltet og trykke på knappen Hent. 31

32 Fig 12: Endre kundeinformasjon Skulle kundenummeret som ble skrevet inn ikke eksistere, får man opp en feilmelding som sier at kunden ikke eksisterer. Denne feilmeldingen blir synlig i to sekunder. En header Refresh sørger for nettopp dette og man kommer tilbake til adminmenyen. Eksisterer kunden hentes all informasjon om kunden fram slik som vist over. Da er det mulig å endre ønskede felter. Når disse feltene er endret, trykker man på Lagreknappen og de nye opplysningene sendes til databasen. På samme måte som ved feilmelding, får man nå en bekreftelse som sier at kunden er oppdatert og header Refresh går tilbake til adminmenyen etter to sekunder Siste valget admin kan gjøre, er å slette en kunde om dette er nødvendig. På samme måte som endre kunde, skriver man inn kundenummer man ønsker å slette. Eksisterer ikke kunden med gitt kundenummer får man opp samme feilmelding som ved endre kunde. Hvis kunden eksisterer får man opp en meldingsboks som spør om man er sikker på om man vil slette ønsket kunde slik som vist under: Fig 13: Slett kunde 32

33 4.5 Beskrivelse av søkemotoren Oppdragsgiver ønsker å ha en enkel søkemotor som lett skal kunne få opp ønskelig informasjon. De ville at det lett skulle være mulig å lokalisere kunder, selger og banner. De ønsket at det skulle være mulig å søke fram bedrifter og deres banner(e). Vi valgte og opprette en egen side for denne søkemoter hvor man kan velge blant: Søke fram kunder Søke fram salg Søke fram bannere Skal man søke etter bedriftens kunder, er det mulig å søke ut ifra kundenummer, kundenavn og telefonnummer. Ønsker man informasjon om salg, kan man søke fram selgerens salg og kundens kjøp ved å skrive inn henholdsvis selgernummer og kundenummer. Fig 14: Skjema for søk Det er tre måter å hente fram bannere på. Den ene måten er direkte søk på banner ut ifra kundenummer, mens den andre måten er å søke på kunde. Da vil man få opp ønsket kunde og deres informasjon, samt en link man kan klikke på for å se tilhørende banner. Den siste måten er å søke på salg. Trykker man på linken [mer info] finner man banneret og plasseringen. 33

34 Søk på Kunde: Fig 15: Resultat kundesøk Søk på Salg: Fig 16: Resultat selgersøk 34

35 Søk på Banner: Fig 17: Resultat bannersøk Grunnen til at vi har gjort det slik, er fordi det var et stort ønske om at bannerne lett skulle kunne lokaliseres. Med det mener vi at tidligere var det et problem for bedriften å vite til en hver tid hvor bannerne til kundene befant seg på nettet. Kunder ringte inn til bedriften for å finne ut hvor deres banner lå på nettsiden og det var problematisk å gi ønskede opplysninger tilbake. Nå er dette ikke lenger et problem, da pathen til webbanneret kommer fram ved et enkelt søk. Når kunden nå ringer for å finne ut dette, søker ansatte etter banner og det kommer opp om den ligger på forsiden, kategoriside og hvilken, samt underside og hvilken. Når man søker på salg, enten på selgernummer eller kundenummer kommer ikke all informasjon opp på en side. Kun de viktigste opplysningene er synlig. Ønsker man all informasjon om salget, trykker man på linken [mer info]. Se Fig 16: Resultat selgersøk 35

36 Idet man trykker på [mer info] kommer denne siden fram: Fig 18: Mer info 4.6 Beskrivelse av ordrebekreftelse Får å skrive ut en ordrebekreftelse for ønsket kunde med riktig selger, må man gå inn på søk. Deretter å søke på selger for å få opp alle salgene denne selgeren har gjort. Det er også mulig å søke på Kunde under salg. Når man trykker på linken [mer info] tilhørende ønsket kunde, får man opp all informasjon om kunden, salget og selger. Nederst på siden er det en ny link [lag ordrebekreftelse] som sender deg til en side med informasjonen og en bekreftelse, samt en logo av tv2torget. Denne siden kan skrives ut og sendes til kunde ved å trykke på henholdsvis knappen Print. Siden har hvit bakgrunn da dette dokumentet vil bli skrevet ut ofte. 36

37 Fig 19: Ordrebekreftelse 37

38 4.7 Beskrivelse av banner upload Bannerne kundene vil legge ut på nettet, blir ikke registrert under registrering av kunde og salg. Etter kunde og salg er registrert, får kunden tildelt et kundenummer, samt en unik salgid. Disse er nødvendige ved opplasting av banner. Dette er hvordan siden laste opp banner ser ut: Fig 20: Last opp banner Etter at kundenummer og salgid er fylt ut, må banneret lokaliseres og hentes fram. Når disse tre feltene er utfylt, trykker man på knappen Last opp! Salgid får man når Registrering av kunde og salg er utført. Det vi da har valgt å gjøre er å automatisk opprette en mappe for hver enkelt kunde hvor banneret blir plassert. Denne mappen blir automatisk tildelt navn som er det samme som kundenummeret slik som vist under: Fig 21: Mappe med banner 38

39 4.8 Beskrivelse av gjensalg Skal man registre et gjensalg for en eksisterende kunde, er første steg å trykke på linken Registrer Gjensalg på toppmenyen. Da får man opp en side som ber om at kundenummer må skrives inn. Eksisterer det ingen kunde med gitt kundenummer, kommer det fram en feilmelding om at kunde ikke finnes. Som nevnt tidligere, sørger en header Refresh for at man automatisk kommer tilbake til siden vist under, etter en feilmelding. Fig 22: Hent ønsket kunde for gjensalg Skriver man inn et kundenummer som ligger inne i databasen, kommer samme skjema som ved Registrer Ny Kunde og Salg til syne. Forskjellen nå er at all kundeinformasjon tilhørende kundenummer allerede er fylt ut og disse tekstfeltene er låst. Grunnen til det er at kundeinformasjon ikke skal kunne endres her. Det er kun mulig for administrator. Nå skal kun et nytt salg for en eksisterende kunde registreres og sendes til databasen. Når man trykker på Lagreknappen får man opp en utskrift som er nesten helt identisk med utskriften tilhørende Registrer Ny Kunde og Salg. Den eneste forskjellen er ikke stor, men er av betydning. Kundenummeret blir synlig i utskriften i Registrer Gjensalg, da kundenummer ikke har blitt tildelt enda i Registrer Ny Kunde og salg. Les mer om dette under punkt 7 Programmets oppbygning. 39