Entobutikk PROSJEKT NR TILGJENGELIGHET Åpen. Telefon: Telefaks:

Transkript

1 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Nettbutikk i ASP.NET(C#) DATO ANTALL SIDER / BILAG 138 sider PROSJEKTDELTAKERE Madia Kalsoom (s153424) Sawen Mohammad Ahmed (s156163) Anzor Aslambekovitsj Akhmiev (s156146) Mariam Bourass (s153446) INTERN VEILEDER Kirsten Ribu, Førstelektor, Datafag, HIO OPPDRAGSGIVER Entobutikk KONTAKTPERSON Ali Khuram Asif SAMMENDRAG Prosjektet består av å utvikle en brukervennlig nettbutikk som tilbyr en rekke funksjoner for Administrator, kunde og gjest. 3 STIKKORD Administrator(Admin) Bestillings- og betalingssystem Logginn for Admin og Kunde 1

2 2 Entobutikk

3 UTVIKLING AV NETTBUTIKK I ASP.NET(C#) VÅR 2011 LAGET AV: Madia Kalsoom Anzor Aslambekovitsj Akhmiev Sawen Mohammad Ahmed Mariam Bourass 3

4 4 Entobutikk

5 KAPITTEL 1 FORORD Denne hovedprosjektrapporten ble utviklet for hovedprosjektet ved Høgskolen i Oslo, avd. for ingeniørutdanning våren Rapporten omhandler en nettbutikk som er utviklet i ASP.NET, c#. Nettbutikken er utviklet for et privateid firma, Entobutikk. Rapporten er beregnet for sensorer, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i utfordringer, løsninger på disse og arbeidsmetoder i prosjektet. Rapporten er delt opp i FØLGENDE DELER: 1. KRAVSPESIFIKASJON 2. PRODUKTRAPPORT 3. TESTRAPPORT 4. PROSESSRAPPORT 5. BRUKERMANUAL 6. VEDLEGG I begynnelsen av hver del rapport har vi introdusert oppgaven og bakgrunnen, slik at enhver som ikke har lest andre del rapporter kan få oversikt eller innblikk i hva prosjektet går ut på. Dette er bare å informere leseren om hva bakgrunnen er for prosjektet, hvilken mål og rammer det er utsatt for. 5

6 INNHOLDSFORTEGNELSE TITTELSIDE... 1 FORORD... 5 INNHOLDSFORTEGNELSE KRAVSPESIFIKASJON DELKAPITTEL INNLEDNING OPPDELING AV KRAV SPORBARHET PRIORITET DELKAPITTEL INTRODUKSJON TIL OPPGAVEN BAKGRUNN OM HOVEDPROSJEKTET DELKAPITTEL SYSTEMKRAV RAMMEKRAV FUNKSJONELLEKRAV ANDRE KRAV USE CASE DIAGRAM USE CASE BEKSRIVELSER DESIGNKRAV DELKAPITTEL TEKNISKE KRAV DELKAPITTEL KRAV TIL DOKUMENTASJON PRODUKTRAPPORT DELKAPITTEL FORORD DELKAPITTEL INNLEDNING OM BEDRIFTEN MÅL RAMMEBETINGELSER

7 2.4 KRAVSPESIFIKASJON OG PRODUKT DELKAPITTEL OPPBYGNING AV SYSTEMET DELKAPITTEL PRODUKTBESKRIVELSE DELKAPITTEL TEKNOLOGI UTVIKLINGSMILJØ VERKTØY DELKAPITTEL BRUKERGRENSESNITT DESIGN FILHIERARKI DELKAPITTEL PROGRAMMERINGEN DELKAPITTEL DATABASE DATABASESTRUKTUR DATABASEMODELL TABELLER DELKAPITTEL SIKKERHET DELKAPITTEL AVSLUTTNING PRODUKTETS FREMTID KONKLUSJON DELKAPITTEL ORDLISTE DELKAPITTEL KILDER TESTRAPPORT DELKAPITTEL FORORD DELKAPITTEL INNLEDNING DELKAPITTEL

8 FUNKSJONALITETSTESTING DELKAPITTEL SKJERMBILDE AV FORSKJELLIGE NETTLESERE DELKAPITTEL INSTANT VALIDERING DELKAPITTEL KONKLUSJON PROSESSRAPPORT DELKAPITTEL FORORD DELKAPITTEL INNLEDNING PROSJEKTGRUPPEN OM BEDRIFTEN DAGENS SITUASJON MÅL RAMMEBETINGELSER DELKAPITTEL PLANLEGGING OG METODE VALG AV PROSJEKTOPPGAVEN FORPROSJEKTET PLANLEGGING OG ARBEIDSFORDELING FREMDRIFTSPLAN OG ARBEIDSPLAN MØTEREFERATER KRAVSPESIFIKASJON RISIKOPLAN TEKNOLOGI DELKAPITTEL UTVIKLINGSPROSESS SAMARBEID STARTFASEN VALG AV DESIGN OG STRUKTUR UTVIKLINGSFASEN USE CASE MODELL DESIGN OG STRUKTUR DATABASEN

9 5.4 SLUTTFASEN TESTING DOKUMENTASJON DELKAPITTEL UTFORDRINGER SERVERTILKOBLING BETALINGSSYSTEM SAMME FUNKSJONALITET I NETTLESERE DELKAPITTEL KRAVSPESIFIKASJON OG DENS ROLLE DELKAPITTEL AVSLUTNING EVALUERING AV PROSJEKTGRUPPE PRODUKTETS FREMTID KONKLUSJON DELKAPITTEL ORDLISTE DELKAPITTEL KILDER BRUKERMANUAL DELKAPITTEL FORORD DELKAPITTEL ADMINISTRATOR LOGGINN PRODUKTER VARERETUR KUNDE REDIGERE KATEGORI ORDREHISTORIKK SILVERLIGHT LOGGUT DELKAPITTEL KUNDE REGISTRERE NY KUNDE LOGGE INN OG ENDRE INFO

10 3.2 KJØPE PRODUKT KONKLUSJON VEDLEGG VEDLEGG 1 AVTALE-OPPDRAG VEDLEGG 2 SAMARBEIDSAVTALE VEDLEGG 3 ARBEIDSPLAN VEDLEGG 4 FREMDRIFTSPLAN VEDLEGG 5 RISIKOPLAN

11 1. KRAVSPESIFIKASJON VÅR

12 DELKAPITTEL 1 INNLEDNING Kravspesifikasjonen er svært nyttig sett i forhold til produktet vi ønsker å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet og forteller oss hva vi skal lage, og hvordan produktet prinsipielt skal fungere. Den tar også for seg noen av komponentene vi kommer til å bruke, samt komponentene vi skal ta utgangspunkt i. Dette dokumentet skal gi alle parter et innsyn i hvordan oppdragsgiver og prosjektgruppen har utdypet oppgavebeskrivelsen, ved å definere hvilke krav som oppgaveløsningen skal oppfylle. Det vil bli utført en analyse av behovet som systemet skal ivareta, og etter å ha lest gjennom dette dokumentet skal man ha skaffet seg en forståelse for behovene vi ønsker å dekke. 1.1 OPPDELING AV KRAV Prosjektgruppen har fastslått å forenkle fremstillingen av kravene i dette dokumentet. På grunnlag av dette har man valgt å dele inn kravene i følgende deler: Rammekrav Funksjonelle krav Use Case modell Designkrav Teknisk krav 1.2 SPORBARHET Kravspesifikasjonen er konstruert med tanke på sporbarhet. Hvert krav har fått tildelt sitt unike krav ID. På denne måten kan lett finne tilbake til kravet på et senere tidspunkt. Tabell gir en illustrasjon av kravtypene som danner grunnlaget for oppbygningen av krav ID. FORKORTEL SE KR KF KA KD KT KRAVTYPE Rammekrav Funksjonelle krav Andre krav Design krav Tekniske krav 12

13 Krav ID-en er bygget opp slik: KTX, hvor K står for krav, T står for kravtype, og X er et tall. 1.3 PRIORITET I dette dokumentet har vi valgt å klassifisere prioriteten på alle krav. Hvert krav har enten høy, middels eller lav prioritet. 13

14 DELKAPITTEL 2 INTRODUKSJON TIL OPPGAVEN Prosjektoppgaven er selve ryggraden til kravspesifikasjonen. På grunnlag av dette er det betydningsfullt å gi leseren en kort introduksjon til selve prosjektoppgaven, slik at man kan se kravene som er beskrevet i dette dokumentet i sammenheng til oppgaven. Derfor vil vi i dette kapittelet gi en kort innføring i selve prosjektoppgaven. 2.1 BAKGRUNN Entobutikk er en privateid og familiedrevet nettbutikk som selger produkter innenfor data, helse og velvære. Bedriften importerer varene direkte fra fabrikker i Asia, spesielt fra Kina. Deres hovedfokus er høy kvalitet produkter med gode priser, og god service til hver enkelt kunde. Per i dag benytter bedriften en eksisterende nettside for å selge produktene sine. Nettsiden er kodet med enkel html-kode. Denne nettsiden viser alle produkter og produktbeskrivelse, men kan bare kjøpe produkter via telefon eller epost. Den mangler enkelte funksjoner og løsninger som kunne ha gjort det bedre for både kunder og administrator, som f. eks innloggingsrutiner, layout, brukervennlighet, handlekurv og historikk. Entobutikk ønsker en bedre og komplett nettbutikk med flere funksjoner for kunder og administrator. 2.3 OM HOVEDPROSJEKTET Prosjektet gjennomføres som hovedprosjekt ved Høgskolen i Oslo, avd. for ingeniørutdanning våren 2010 i samarbeid med Entobutikk. Det skal utvikles en enkel og brukervennlig nettside som er lettere å bruke/lese og oppdatere. Her får kunder mulighet til å se/endre på sin historikk og personlige opplysninger. Administrator skal få kunne oppdatere siden, få oversikt over produkter og kunder uten at vedkommende må kunne programmering. Vi skal finne en mer avansert løsning enn den nåværende, med hensyn på brukervennlighet, sikkerhet, brukergrensesnitt, og med flere funksjoner enn den nåværende nettbutikk tilbyr. 14

15 DELKAPITTEL 3 SYSTEMKRAV Dette kapittelet beskriver krav til systemets oppsett, design, funksjonalitet og utviklingsmiljø vi synes passer best til å utvikle dette systemet. Alle krav til nettbutikken ble utviklet ut fra diskusjonen med oppdragsgiver og ekstern veileder, Kirsten Ribu. 3.1 RAMMEKRAV Det stilles en rekke pålitelighetskrav og lisenskrav til produktet. Derfor har prosjektgruppen valgt å utlede rammekrav, som kan ses i sammenheng med produktet som skal utvikles i løpet av dette prosjektet. Slik ser følgende rammekravene ut: Applikasjonen skal kobles opp mot en Sql server, som også støtter.net. Løsningen skal implementeres i ASP.Net. Det skal være mulig å kjøre løsningen fra skolens server og oppdragsgivers server. Løsningen må kunne hvert fall kjøres i Internet Explorer, Mozilla Firefox, Chrome, Opera og safari. Man skal ikke være avhengig av spesialisert programvare eller maskinvare for å få tilgang til nettbutikken. Alt som kodes i XHTML skal kunne valideres på FUNKSJONELLEKRAV Dette delkapitelet tar for seg de funksjonelle kravene for systemet vi skal utvikle. De funksjonelle kravene er definert som krav som spesifiserer de faktiske funksjonene et system skal utføre. Med andre ord skal det beskrives hvordan systemet skal fungere og hvordan det skal håndtere forskjellige situasjoner. Systemet skal ha tre brukertyper: administrator, kunde og gjest. Slik skal funksjonene deres være: Admin Prioritet - Skal ha eget grensesnitt som skal være enkel å bruke. Høy - Administrere produkter, kategorier, kunder og bilder. Høy 15

16 - Ha tilgang til ordreliste. Høy - Ha tilgang til ordrehistorikk. Høy - Slette en ordre/kunde. Høy - Ha eget logginnfunksjon samt eget URL. Høy - Liste ut alle produkter og kunder Middels - Ha oversikt over varelageret Middels Kunder Prioritet - Registrere seg for å bli kunde. Høy - Legge til et eller flere produkter i handlekurven. Høy - Slette produkter fra handlekurven. Høy - Kjøpe produkter ved å betale via PayPal eller faktura. Høy - Endre personlige opplysninger. Høy - Ha egen logginn funksjon. Høy - Når kunde har kjøpt et produkt, skal han få kvittering i epost Middels for betaling. - Se sin egen ordrehistorikk. Middels - Ha tilgang til å se produkter og deres beskrivelse. Høy - Ha tilgang til online chat. Veldig lav Gjester/anonyme Prioritet - Lese aktuelle nyheter på hovedsiden. Høy - Ha tilgang til å se produkter og deres beskrivelse. Høy - Legge til et eller flere produkter i handlekurven. Høy - Slette produkter fra handlekurven. Høy - Kjøpe produkter ved å betale via PayPal eller faktura. Høy - Trenger ikke å registrere seg. Middels 16

17 Systemet skal også ha andre funksjoner som følgende: Produkter Prioritet - Registreres, endres og legges inn i database av Admin. Høy - Hvert produkt skal få unik ID(tall). Høy - IDen skal brukes til å legge, slette og endre produktet i Høy databasen. - Alle produkter skal ha minst en kategori. Høy - Retur av produkter skal registreres i databasen. Middels - Hvert produkt som selges skal være mulig å spore opp via Lav posten. - Hvert produkt kan ha maksimum seks bilder. Hvor bildene skal Høy vises med silverlight/flash. - Alle produkter skal inneholde pris, bilde og spesifikasjoner. Høy Kategori Prioritet - Registreres, endres og legges inn i database av Admin. Høy - Hver kategori skal få unik ID(tall). Høy - Iden skal brukes til å legge, slette og endre kategorien i Høy databasen. - Alle kategorier skal ha minste et produkt. Høy - Alle kategorier trenger ikke ha underkategorier. Middels Handlekurv Prioritet - Handlekurven skal regne ut total prisen for alle produktene Høy - Frakt skal regnes ut ifra hvor mange/store produkter det er. Høy - Handlekurven skal automatisk kobles til betalingssystem. Middels Søk funksjonen - Vanlig søk: kunde og gjest skal kunne utføre søk ved å skrive søkeord i søkefeltet. - Avansert søk: kunde og gjest skal kunne søke etter produkter i forhold til produktnavn, produktid, kategori og lignende. Prioritet Høy Lav 17

18 Ordrebekreftelse funksjonen - Systemet skal kunne sende e-post med ordrebekreftelse til kunden etter at betalingen har blitt bekreftet. Prioritet Høy Bestillingsbekreftelse funksjonen - Systemet skal kunne sende e-post med betalingsbekreftelse til entobutikk etter at betalingen har blitt bekreftet og dataene har blitt sendt til databasen. Prioritet Høy Kontakt funksjonen Prioritet - Kunden skal kunne sende elektronisk melding til entobutikk. Lav 3.3 ANDRE KRAV Her lister vi opp de øvrige funksjonene som nettbutikken skal ha: Øvrige funksjoner Prioritet - Kontrasten mellom tekst og bakgrunn skal være bra, sånn at det Høy ikke skal være vanskelig å lese teksten for døve/blinde. - Fargetemaet på nettsiden skal ikke være for lys eller for mørk. Middels - Skrift: samme font over hele nettbutikken, ikke kursiv Høy - Bakgrunnen skal være hvit Høy - Tittel på nettbutikk skal være i rød skrift etter ønske fra oppdragsgiver. Høy - Tre-klikksregelen skal følges. Man skal aldri måtte klikke mer enn tre Middels ganger for å finne informasjonen man er ute etter. - Alle registreringer og endringer skal registreres i databasen. Høy - Layout til hele nettbutikken kan endres med hensyn på farger. Lav - All kode skal dokumenteres skikkelig for videreutvikling av Middels nettbutikken. - Lage forståelige og lett lesbare instruksjoner. Høy 18

19 3.4 USE CASE DIAGRAM 19

20 3.3.1 USE CASE BEKSRIVELSER Use case - Se produkter Use case Se produkter Aktør Trigger Admin, kunde, gjest Brukeren velger å gå på hjemmesiden entobutikk.no, ønsker å se produktene Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Brukeren går på nettsiden og ser produkter Fikk sett produktene. Fikk ikke sett produktene. 1. Brukeren taster nettadressen 2. Systemet sjekker om nettadressen eksisterer 3. Nettsiden blir åpnet 4. Brukeren velger kategori og produkter for å se 2. Nettadressen eksisterer ikke 2.a: Systemet informerer brukeren om at nettadressen ikke ble funnet 3. Nettsiden er nede 3.a:Systemet informerer brukeren å prøve igjen senere - Nettadressen må være riktig skrevet. Use case - Se ordrehistorikk Use case Se ordrehistorikk Aktør Admin, kunde Trigger Kunden velger å logge seg inn i hjemmesiden og se ordrehistorikk Pre betingelser Post betingelser Normal hendelsesflyt Kunden er logget inn og ser ordrehistorikk Fikk se ordrehistorikk Fikk ikke sett ordrehistorikk 1. Systemet ber om brukernavn og passord 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Kunden velger å se ordrehistorikk 4. Systemet returnerer lagret ordrehistorikk Variasjoner Relatert 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Kunden finner ingen ordrehistorikk 3.a:Systemet informerer kunden om at han ikke har noen ordrehistorikk - Dersom det er en eksisterende kunde, må brukernavn og passord være 20

21 informasjon riktig, ellers må kunden registrere seg. Use case Ordreliste Use case Ordreliste Aktør Admin Trigger Admin vil se ordrelisten Pre betingelser Post betingelser Normal hendelsesflyt Admin ser ordrelisten Får sett ordrelisten Får ikke sett ordrelisten 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin velger å se ordreliste 4. Systemet returnerer lagret ordreliste Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin finner ingen ordreliste 3.a:Systemet informerer admin om det ikke finnes noen ordreliste - Nettadressen må være riktig skrevet. Use case - Bestille produkt Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Bestille produkt Paypal, kunde, gjest Bruker vil bestille produkt Bruker bestiller produkt Får bestilt produkt Får ikke bestilt produkt 1. Bruker velger produkt 2. Systemet sjekker om produktet er på lager 3. Bruker betaler, paypal 4. Systemet registrer ordren 5. Systemet bekrefter registrert ordre Variasjoner 2. Produktet finnes ikke på lager 21

22 Relatert informasjon 2.a: Systemet informerer bruker om å prøve senere eller evt. når varen er på lager 3. Paypal fungerer ikke som den skal 3.a:Systemet informerer bruker om bestillingen ikke ble utført - Må betale online Use case - Redigere produkt Use case Redigere produkt Aktør Admin Trigger Admin vil redigere produkt Pre betingelser Post betingelser Normal hendelsesflyt Admin redigerer produkt Får redigert produkt Får ikke redigert produkt 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin redigerer produkt 4. Systemet bekrefter redigering av produkt Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert produkt 3.a:Systemet informerer admin om å prøve igjen senere - Admin må være innlogeet Use case - Redigere info Use case Aktør Trigger Pre betingelser Post betingelser Redigere informasjon Kunde Bruker vil redigere info Bruker redigerer info Får redigert info Får ikke redigert info Normal hendelsesflyt 1. Systemet ber om brukernavn og passord (for 22

23 kunde) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Bruker redigerer info 4. Systemet bekrefter redigering av informasjon Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert informasjon 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget Use case - Redigere kunderegister Use case Redigere kundereg. Aktør Admin Trigger Admin vil redigere kunderegister Pre betingelser Post betingelser Admin redigerer kunderegister Får redigert kundereg. Får ikke redigert kundereg. Normal hendelsesflyt 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin får redigert kunderegister 4. Systemet bekrefter redigering av kunderegister Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert kunderegister 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget 23

24 Use case Se kundeliste Use case Se kundeliste Aktør Admin Trigger Admin vil se kundelisten Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Admin ser kundelisten Får sett kundelisten Får ikke sett kundelisten 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin får sett kundeliste 4. Systemet sender ut kundelisten 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke sett kundelisten 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget Use case - Betaling Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Betaling Paypal, Kunde, Gjest Bruker betaler bestilt produkt via PayPal Bruker betaler produkt Får betalt produkt Får ikke betalt produkt 1. Bruker godkjenner bestilling 2. Bruker betaler, paypal 3. Systemet registrer ordren 4. Systemet bekrefter registrert ordre 2. Betaling kan ikke gjennomføres 2.a: Systemet informerer bruker om bestillingen ikke ble utført - Betaler online via PayPal ELLER - Få tilsendt faktura 24

25 3.5 DESIGNKRAV Hovedkravet til designet var at løsningen skulle være brukervennlig, enkel å bruke, strukturert. Prosjektgruppen har bestemt å lage masterpage med manylinje øverst på siden, og kategorimeny og søkefunksjonen til venstre siden. Helt øverst har vi tenkt å ha logoen til bedriften og søkfunksjonen helt til høyre på siden. Dette gjør at menyen blir statisk og er en del av grunndesignet som gjør den tilgjengelig uansett hvor man er på nettbutikken. Øverste meny har følgende struktur: - Hjem link som vil føre brukeren til hovedsiden. - Om bedriften link som vil føre brukeren til Om oss siden. - Min konto link som vil føre brukeren til Min konto siden. - Handlekurv link som vil føre brukeren til Handlekurven siden. - Logg inn link som vil føre brukeren til Logg inn siden. - Produkter link som vil føre brukeren til nye produkter siden. - Kontakt oss link som vil føre brukeren til Kontakt oss siden. Søkefelt skal være tilgjengelig uansett hvor man er i løsningen. Det skal være mulig å kunne søke på nøkkelord og finne produkter man leter etter. I tillegg må man ta hensyn til hva som lar seg utføre når man planlegger design. Programmet skal designes på en slik måte at det er fleksibelt og enkelt lar seg bygges videre på. 25

26 Vi har laget ett utkast av designet, som etter hvert vil bli endret: 26

27 DELKAPITTEL 4 TEKNISKE KRAV Utviklingsprogram: Visual Studio 2010, php Expression silverlight, Expression studio 4. Programmeringsspråk: ASP.Net/c#, HTML, CSS. Database: MySQL. Andre programmer: Office pakke, photoshop, paint, Snagit. Gruppen har friheten til å velge selv fremgangsmåten og programmering språket. Valget stod mellom PHP og ASP.Net. Ut fra erfaringene og etter flere diskusjoner i gruppen bestemte vi oss for å velge ASP.Net og MySQL. Vi har tenkt til å bruker vanlig html, ASP.Net/C#, CSS og mysql database for å utvikle systemet. Disse verktøyene gjør det mulig å lage en funksjonell og brukervennlig nettbutikk for brukerne. 27

28 DELKAPITTEL 5 KRAV TIL DOKUMENTASJON I hele prosjektperioden skal det føres en prosjektdokumentasjon som beskriver hva som blir gjort og når de ulike oppgavene blir utført. Vårt ferdige prosjekt skal inneholde følgende dokumenter: - Kravspesifikasjon - Prosessrapport - Produktrapport - Testrapport - Brukerveiledning I tillegg til dette skal dokumentasjonen legges inn i koden i form av velvalgte navn på datafelt, variabler og funksjoner, samt forklarende avsnitt foran de kodeavsnitt som ikke er tilstrekkelig selvforklarende. 28

29 29 Entobutikk

30 2. PRODUKTRAPPORT VÅR

31 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner og databasearkitektur. Meningen med denne rapporten er å få full oversikt over systemet vi har laget. Rapporten er beregnet for personer som skal vedlikeholde, installere, endre, markedsføre eller drive støtte på systemet. Sammen med prosessrapport og kravspesifikasjon skal denne rapporten gi helhetlig inntrykk av arbeidet som er utført og det produktresultat som er oppnådd. For å forstå hele rapporten bør leseren ha gode kunnskaper om ASP.NET teknologien, erfaring med webprogrammering og grunnleggende forståelse for databaser. Generell IT kunnskaper innenfor data og systemutvikling kan også være en fordel. 31

32 DELKAPITTEL 2 INNLEDNING I denne del kapitelet vil du finne forklaring om produktets bakgrunn og mål for produktet vi har klart å utvikle i samhold med kravspesifikasjon. 2.1 OM BEDRIFTEN Entobutikk er en privateid og familiedrevet nettbutikk som selger produkter innenfor data, helse og velvære. Bedriften importerer varene direkte fra fabrikker i Asia, spesielt fra Kina. Deres hovedfokus er høy kvalitet produkter med gode priser, og god service til hver enkelt kunde. Entobutikk har sterkt fokus på kundene, og derfor har de 100 % fornøyde kunder. Alle produktene selges med 1 års fabrikk garanti. Per i dag benytter bedriften en eksisterende nettside for å selge produktene sine. Nettsiden er kodet med enkel html-kode. Men den mangler enkelte funksjoner og løsninger som kunne ha gjort det bedre for både kunder og administrator, som f. eks innloggingsrutiner, layout, brukervennlighet, handlekurv og historikk. 2.2 MÅL Vårt mål er å lage en bedre og komplett nettbutikken for bedriften med flere funksjoner for kunder, gjester og administrator. Løsningen vår skal ha hensiktsmessig brukergrensesnitt slik at det blir så enkelt som mulig å bruke det. I og med ingen i bedriften kan avansert programmering, skal ikke løsningen kreve noen forkunnskaper innen for programmering eller avansert databruk. Systemet har tre forskjellige brukere som Admin, kunder og gjester, samt skal systemet også ha produkter og kategorier. Slik ser målene ut: Admin - Admin skal ha eget grensesnitt som skal være enkel samtidig skal den administrere produkter, kategorier, kunder og bilder. - Admin skal også få tilgang til ordreliste til hver enkelt kunde samt mulighet til å bekrefte eller slette en ordre. - Admin skal ha sitt eget logginnfunksjon. 32

33 Kunder - Registrere seg for å bli kunde, legge til et eller flere produkter i handlekurv, slette/fjerne produkter fra handlekurv og kjøpe produkter ved å betale. - Endre personlige opplysninger når som helst, en hver endring må registreres i databasen. - Skal ha egen logginnfunksjon. Gjester/anonyme - Lese aktuelle nyheter på hovedsidene, bla i produkter. - Får mulighet til å legge til produkter i handlekurven, slette og kjøpe produkter ved å betale. - Trenger ikke å registrere seg. Produkter - Registreres, endres og legges inn i database av Admin. - Hvert produkt skal få unik ID(tall) som man kan brukes til å legge, slette og endre produktet. - Alle produkter skal ha minst en kategori. Kategori - Registreres, endres og legges inn i database av Admin. - Hver kategori skal få unik ID(tall) som man kan brukes til å legge, slette og endre kategorien. - Alle kategorier skal ha minste et produkt. 33

34 2.3 RAMMEBETINGELSER Når det gjelder rammebetingelser var det tid som ble viktigst og påvirket valg av funksjonalitet. All funksjonalitet var vurdert med hensyn på tidsbegrensninger. Systemet var bestemt å lages relativt enkelt med mulighet for å utvides til noe ganske avansert. Gruppen hadde en diskusjon med oppdragsgiver og satt opp en liste over all funksjonalitet som vi kunne tenke oss systemet kunne ha, så prioriterte vi denne listen og utførte så mye vi rakk. Underveis la vi også til nye ideer til funksjonalitet som vi kom på og forandret på designet. Her lister vi opp rammebetingelsene vi kom fram til: Applikasjonen skal kobles opp mot en Sql server, som også støtter.net. Løsningen skal implementeres i ASP.Net. Det skal være mulig å kjøre løsningen fra skolens server og oppdragsgivers server. Løsningen må kunne hvert fall kjøres i Internet Explorer, Mozilla Firefox og Netscape. 2.4 KRAVSPESIFIKASJON OG PRODUKT Etter flere måneder med programmering og planlegging har vi laget vårt sluttprodukt som inneholder Admin-side, kunde og gjestesider. Nettbutikken er utviklet med utgangspunkt i kravspesifikasjonen som ble laget i starten av prosjektet. Hele løsningen er ikke bare bundet til kravspesifikasjonen, vi har også tatt med våre ideer i henhold til tekniske, funksjonelle og design kravene. 34

35 DELKAPITTEL 3 OPPBYGNING AV SYSTEMET Applikasjonen vår er bygget opp med lagdelt arkitektur som inneholder tre lag, blant annet presentasjonslag, virksomhetslogikk og dataaksess. Lagdeling gir en strukturert system samtidig som den kan gi maksimal ytelse. Alle informasjonsobjektene i systemet ligger i databasen. Presentasjonslaget er basert på XML output fra database- og virksomhetslogikklagene. Dette laget styrer hvordan informasjonsobjektene presenteres for brukeren gjennom XHTML. Formateringen av informasjonsobjektene blir gjennomført ved å benytte XSLT stilark for å konvertere XML til ønsket format som HTML og XHTML. Virksomhetslaget har alle funksjoner som ikke direkte berører grensesnittet. Dette laget inneholder logikken som knytter ulike informasjonsobjekter og applikasjoner sammen. Komponenter som er definert i dette laget bruker tjenestene i dataaksesslaget. Virksomhetslogikken mottar http forespørsler for behandling, og som sender informasjonsobjekter tilbake til klienten. Dette laget består av BLL og MODEL. I BLL blir dataene validert for å se om alle felter er riktig utfylt. Alle data som skal inn i databasen skal valideres med SQL injeksjon i BLL. Alle validerte data blir overført til DAL(dataaksesslag). MODEL gir kobling mellom presentasjons- og dataaksesslaget. I dataaksesslaget ligger alt som har sammenheng med database, laget tar imot forespørsler om uthenting, lagring og sletting av informasjonsobjekter i databasen. Dataaksesslaget er representert i DAL og benytter ADO.NET. Dataaksesslaget sørger for at dataoperasjonene er skjult for lagene som er over. Når man kjøper et produkt sender alle dataene til BLL, disse blir godkjent(validert) og overført inn i databasen gjennom DAL. Ved overføringen fra databasen til applikasjonen skjer gjennom DAL og via MODEL. Nedenfor kan man se figur av hvordan systemet er bygget opp. 35

36 Figur 1: lagdeling av systemet. 36

37 DELKAPITTEL 4 PRODUKTBESKRIVELSE Nettbutikken vi har utviklet har tre roller som er gjest, kunde og administrator. Gjestsidene har alle tilganger til, her kan man se alle produkter og se produktbeskrivelser samtidig som man har lov til å sette produktene i handlekurven og kjøpe de. Man må ikke være logget inn som kunde for å foreta en bestilling/betaling. Forskjell mellom gjest og kundesidene er at kunde har mulighet til å se ordrehistorikk og endre personlige opplysninger ved å logge seg inn med brukernavn og passord, mens gjest ikke har mulighet til disse sidene. Administratorsidene er bare tilgjengelige for Admin, ingen andre. Her har administrator en rekke muligheter som oppdatering/oppretting av kundeopplysninger, ordrer, produkter og dets innhold. Administrator har eget log inn funksjon med eget brukernavn og passord. Administrator kan liste opp alle kunder, ordrer og produkter som kan søkes opp ved søkefunksjonen. 37

38 DELKAPITTEL 5 TEKNOLOGI I denne del kapitlet beskrives de verktøyene og teknologiene som gruppen har benyttet for å utvikle systemet. 5.1 UTVIKLINGSMILJØ Ved utvikling av nettbutikken har vi brukt Microsoft ASP.NET sammen med C# som programmeringsspråk. For å hente informasjon/data fra databasen har vi brukt LINQ to SQL og SQL. I tillegg til dette har vi også brukt Javascript og Ajax i administratorsidene og produktsidene. I Admin har vi brukt for å kunne laste opp flere produktbilder og i på produktsidene har vi brukt for å forstørre bilder av produktet slik at bare bilde vises på skjermen. CSS brukte vi gjennom hele nettbutikken for å designe nettbutikken med henhold til tekst, bilder, farger, knapper, felter og alt annet som skulle integreres på nettsiden. Vi har også tatt nytte av AJAX extentions for å forbedre funksjonalitet i ASP.NET. Gjennom hele utviklingen har vi brukt ADO.NET som brukes i dataaksesslaget(dal) metodene til å få kobling mellom applikasjonen og SQL server til å få tak i dataene. Nedenfor kan man se figur av hvordan hele systemet fungerer: 38

39 Figur 2: ASP.NET teknologi. 39

40 5.2 VERKTØY Gruppen har brukt Microsoft Visual Studio 2010 for å utvikle nettbutikken, her får man mulighet til å kjøre programmet(debugging) samtidig som man kan feilsøke og endre underveis. Figur 3: Microsoft Visual Studio

41 Videre har vi brukt ArgoUML for å tegne Use Case modell for systemet. Figur 4: ArgoUML. 41

42 Vi har også et annet nyttig verktøy, Microsoft Office Visio 2007 for å lage forskjellige diagrammer i systemet. Figur 5: Microsoft Visio. 42

43 Vi har også brukt Paint for å justere og redigere bilder og diagrammer vi har laget. Figur 6: Paint. 43

44 DELKAPITTEL 6 BRUKERGRENSESNITT I dette kapitelet blir det beskrevet hvordan brukergrensesnittet er og filhierarki er bygget opp. 6.1 DESIGN Designet til nettbutikken er veldig enkel med menylinje over og en menylinje på venstre side. I øverste menyen står det søk, Forside, Om entobutikk, Kundesenter og Hjelp. I venstre menyen står alle produktkategoriene, ved å trykke på dem kommer man til alle produkter som tilhører denne kategorien. Alle kategoriene og produktene blir hentet fra databasen. For å lage den menyen har vi brukt treeview i navigasjon. Layout til nettbutikken er enkel og brukervennlig, men samme font over hele systemet. Her er et par GUI eksempler fra nettbutikken: 7. Hovedsiden til nettbutikken.(home.aspx) 44

45 8. Kontaktoss.aspx. 9. Produkter.aspx 45

46 6.2 FILHIERARKI Her har man oversikt over alle mappene og filene som er lagt opp i systemet. 10. Filhierarki. 46

47 DELKAPITTEL 7 PROGRAMMERINGEN Denne delen beskriver hvilken funksjon utgjør hver mappe og fil. Grunnet begrenset tid har vi bare tatt utgangspunkt i DAL, MODEL og BLL. Mappen DAL innheholder metoder som kobler applikasjonen med SQL server. Filen DBNEttbutikk.designer.cs blir opprettet automatisk når vi oppretter databasen og den inneholder alle koblinger mot databasen. Den har på en måte opprettet connection mellom alle tabellene. Filen KategoriRep.cs inneholder alle de metodene som er nødvendig for å vise kategorier og sjekke om kategorien og underkategorien finnes. Den inneholder også metoder som endrer, sletter og redigerer kategorier. Filen KundeRep.cs inneholder alle metodene som sletter, oppretter, viser, søker og viser personlig informasjon til kunder. Her finnes det også en metode for at kunden kan endre sin personlige informasjon. Filen ProduktData.cs inneholder metoder som viser produkter innenfor et gitt kategori eller underkategori, viser produkter for gitt innparameter, en treeveiw metode som viser alle kategorier og underkategorier ved bruk av SQL og mange andre metoder for å redigere produkt, sette inn ny bestilling, hent bestilling, sette inn ny ordre og slette ordre. Filen Sikkerhet.cs inneholder en metode som lager hash, registrerer bruker, sjekker om brukernavn er i bruk og logginn. Filen SikkerhetRepStub.cs er en klasse som later som om den er en database, og gjør ikke noe annet enn at den returnerer noen data og noen statuser. Den inneholder da alle metodene som er definert i Sikkerhet klassen. Filen KundeRepStub inneholder samme som SikkerhetsRepstub, bare at den inneholder kun de metodene som er definert i KundeRep. IKundeRep.cs er en interface som begge altså KundeRep og KundeRepStub klassene implementerer. Denne klassen inneholder også alle de metodene som er definert i KundeRep. Isikkerhet inneholder samme som IkundeRep bare at den definerer kun de metodene som er definert i Sikkerhet klassen. 47

48 KategoriKontroll.cs inneholder metoder som kobler til DAL for å bruke eller sjekker Filen KategoriKontroll.cs inneholder metoder som kobler til DAL for eksempel for å bruke eller sjekke om en kategori eller underkategori finnes, også finner den og returnerer til websidene(presentasjonslaget). Filen KundeKontroll.cs inneholder metoder som kobler til DAL for eksempel for å bruke eller sjekke om en kunde finnes, også finner den og returnerer til websidene(presentasjonslaget). Filen KategoriKontroll.cs inneholder metoder som kobler til DAL for eksempel for å bruke eller sjekke om en produkt eller produktinfo finnes, også finner den og returnerer til websidene(presentasjonslaget). Filen SikkerhetsKontroll.cs inneholder metoder som kobler til DAL for eksempel til å sjekke om alle felter er fylt ut, eller om feltene som blir endret, ble riktig registrert. 48

49 MODEL inneholder alle de nødvendige klassene som brukes til å overføre dataene fra DAL til BLL og til websidene, og omvendt. Filen KategoriOgunderKat.cs inneholder tom klasse som inneholder attributter til kategorier og underkategorier. Filen Kunder.cs inneholder tom klasse som inneholder attributter til kunder og alt informasjon om kunder. Filen nybestilling.cs inneholder tom klasse som inneholder attributter til ordrer. Filen Produkt.cs inneholder tom klasse som inneholder attributter til produkter og alt annen produktinformasjon. Filen ProduktKategori.cs inneholder tom klasse som inneholder attributter til kategorinavn og kategorinummer. Filen ProdUnderKategori.cs inneholder tom klasse som inneholder attributter til underkategori og kategori. 49

50 DELKAPITTEL 8 DATABASE Denne delen beskriver hvordan databasen er bygget opp, hvordan man kan kommunisere med databasen og hvilke tabeller som i den. 8.1 DATABASESTRUKTUR Databasen vår er designet med MS Visual Studio og inneholder 8 tabeller hvor alle tabellene er på 3NF. Slik unngår man redundans og en entitet kan lett utvides med koblinger mot nye entiteter. Når databasen er på tredje normalform kan man lett skille mellom entiteten og rolle enn å lage nye oppføringer for hver rolle, kan man bruke den samme entitetens unike ID over hele systemet. 8.2 DATABASEMODELL Figuren nedenfor viser hvilke tabeller som er i databasen og hvordan de er knyttet til hverandre. 50

51 8.3 TABELLER Nedenfor ser man forskjellige figurer som beskriver databasens tabeller. Her får man oversikt over hvilke attributter som har blitt opprettet og hvordan de har blitt definert. BestillingsTable Denne tabellen innheholder alt info en bestilling og primærnøkkelen er BestillingsID. KategoriTilProd Denne tabellen inneholder info om kategori, primærnøkkel er KatNr. Kunde Denne tabellen inneholder alle opplysninger om en kunde, og primærnøkkelen er KundeNr. Ordre Denne tabellen inneholder all info om en gitt ordre, primærnøkkelen er OrdreNr. 51

52 Odrelinje Denne tabellen er mellomleddet til vare og ordre. Her er OdreNr og VareNr som primærnøkler og fremmednøkler. Poststed postnr(primærnøkkel) til en kunde. Denne tabellen er koblet til kundetabellen og inneholder poststed og Produkter Denne tabellen inneholder all informasjon om produkter, og primærnøkkelen er VareNr. UnderKategori primærnøkkelen er UnderKatID. Denne tabellen er koblet til kategoritabellen og har en kategorinavn og underkategorinavn, 52

53 DELKAPITTEL 9 SIKKERHET Når man utvikler store systemer, er det veldig viktig å ha sikkerhet. Vi bruker SHA256 til å lage en hash til passordet, det vil si å kryptere passord. Nedenfor kan dere se hvordan den metoden er utviklet: Vi har også brukt en metode som sjekker alle felter for SQL injection. Det vil si hvis du for eksempel prøver å skrive DROP, SELECT, INSERT, DELETE i logginn feltene så blir disse erstattet med tom tekst. Slik ser følgende kode ut: 53

54 DELKAPITTEL 10 AVSLUTTNING Dette kapitelet tar for seg produktets fremtid og gruppes vurderinger av produktresultat PRODUKTETS FREMTID Det er gode muligheter til å videreutvikle nettbutikken, men hensyn på funksjoner og applikasjoner. For eksempel kan det integreres en online Chat applikasjon for kunder. Det er også mulighet for å videreutvikle designet til nettbutikken. Alle utviklere som kjenner til ASP.Net kan ta over systemet for å legge til nye moduler og funksjoner KONKLUSJON Vi har utviklet nettbutikk for entobutikk som fungerer med hensyn på funksjonelle og tekniske krav. Systemet vi har utviklet, inneholder en Adminside, kundesider og gjestsider. Gruppen har jobbet gjennom hele prosjektet og er nå ferdige med det endelige produktet. I løpet av hele utviklingsperioden har vi tillagt oss nye kunnskaper og erfaringer. Vi er veldig fornøyd med resultatet, og håper at vår oppdragsgiver blir fornøyd med arbeidet vi har gjort og at han kan ta i bruk sitt nye nettbutikk. For å få en helhetlig oversikt over systemet og resultatet, må man lese både prosessrapport og produktrapport. 54

55 DELKAPITTEL 11 ORDLISTE Microsoft Office Visio 2007: er program for Microsoft Windows som bruker vektorgrafikk til å lage diagrammer. Microsoft Visual Studio 2010: er verktøy utviklet fra Microsoft og blir brukt til å utvikle nettsider, web-applikasjoner og andre webtjenester. Dette programmet støtter ulike programmeringspråk som Visual C++, Visual C#, Visual J#, ASP.NET og Visual Basic.NET. ASP.NET: er webapplikasjonsrammeverk(.net) som er utviklet av Microsoft og er bygget på Common Language Runtime(CLR)..NET gir mulighet til å programmere dynamiske websider og webapplikasjoner. #C: uttales som C sharp, er objektorientert programmeringsspråk utviklet av Microsoft innen. NET. C# er basert på programmeringsspråkene Java og C++. ArgoUML: er et diagram-program som er skrevet i Java og brukes til å lage UML(Unified Modeling Language) diagrammer. Paint: er utviklet av Microsoft og er grafikk maleri program som brukes til å åpne og lagre filer som JPEG, GIF og PNG. PayPal: er en betalingssystem på nett som kan brukes til å kunne overføre penger over internett. CSS: står for Cascading Style Sheets og brukes til å definere utseende på filer som er skrevet i HTML eller XML, man har mulighet til å endre farge og oppsett ved hjelp av stilark. ADO.NET: blir brukt i DAL(dataaksess lager) metodene til å få kobling mellom applikasjonen og SQL server for å få tilgang til dataene. JavaScript: er en funksjonell programmeringsspråk som brukes til å gi forbedret brukergrensesnitt og dynamiske websider. JavaScript bruker C syntaks. XHTML: står for Extensible HyperText Markup Language og brukes til å formatere nettsider med hypertext og annet informasjon. XML: står for Extensible Markup Language og er videreføring av SGML, XML blir brukt til deling av strukturerte data mellom informasjonssytemer. AJAX extentions: er utviklet av Microsoft og brukes i ASP.NET til å implementere Ajax funksjonalitet. 55

56 DELKAPITTEL 12 KILDER 1. Forelesninger fra Webapplikasjoner faget. 2. Informasjon fra entobutikk. 3. Internett. 4. Wikipedia. Bøker 1. Programming ASP.NET 3,5: Liberhy, Hur Witz and Maharry, Fourth edition. October Kompendiet: Dokumentasjonsstandard for Hovedprosjekter i DATA/IT, IU, Høgskolen i Oslo, Ann-Mari Torvatn, januar Systemutvikling, Applikasjoner og databaser, Thor E.Hasle, 2008, Cappelen Akademisk Forlag. 4. Databaser: Kjell Toft Hansen og Tore Mallaug, 2008 utgave, Cappelen. 5. Head First SQL: Lynn Beighley, O RELLY. 56

57 57 Entobutikk

58 3. TESTRAPPORT VÅR

59 DELKAPITTEL 1 FORORD Denne testrapport er skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo, ingeniørutdanning, våren Rapporten beskriver testingen av hele nettbutikken vi har bygget opp. Men for å få mer utfyllende informasjon om prosessen, produktet og bruk av produktet må man lese prosess-, produkt- og brukerrapporten som er selvstendige dokumenter. Testrapporten er interessant for sensorer, veileder, oppdragsgiver og andre personer som har interesse for å lese om testingen av nettbutikken vår. 59

60 DELKAPITTEL 2 INNLEDNING Dette dokumentet er ment for å gi informasjon om hvordan tester har blitt utført, samt hva som har vært resultatet av disse testene. Testrapporten danner grunnlaget for at prosjektgruppen skal klare å måle om vi har møtt kravene som ble fastsatt i kravspesifikasjonen og Use Casene. Vi har fokusert mest på funksjonaliteten til systemet. Testrapporten fungerer også som kvalitetssikring på at systemet faktisk fungerer som den skal og at den har funksjonalitet som er tiltenkt. Rapporten kan også være nyttig for videreutvikling og vedlikeholde applikasjoner, slik at det er lettere å finne eventuelle feil. Med andre ord vil dette dokumentet i hovedsak gi en detaljert beskrivelse av hvordan testene har blitt utført. 60

61 DELKAPITTEL 3 FUNKSJONALITETSTESTING For å teste om all funksjonalitet fungerer som den skal, har vi tatt utgangspunkt i Use casene som ble utarbeidet i kravspesifikasjonen. Her har vi testet om alle kravene er oppfylt, og bevist det ved å ta bilder av skjermen. Use case - Se produkter Use case Se produkter Aktør Admin, kunde, gjest Prebetingelse Brukeren velger å gå på hjemmesiden entobutikk.no, ønsker å se produktene Postbetingele Brukeren går på nettsiden og ser produkter Normal hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Nettbutikken inneholder link til produktoversikt 2. Bruker trykker på knapen Produkter for å se alle produkter og Hjem for å se noen av dem, eller eventuelt velge kategori for å se produkter innenfor en valgt kategori. Dersom: 1. Liste over alle produkter vises 2. Hvert produkt har et bilde, pris, antall og kjøp knapp 3. Mulig å lese mer om spesifikasjoner 61

62 Use case - Søk Use case Aktør Prebetingelse Søk Admin, kunde, gjest Brukeren ønsker å søke etter produkter i nettbutikken etter søkeord Postbetingelser Brukeren finner ønskede produkter Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Systemet inneholder enkelt søkefelt. 2. Bruker skriver et søkeord i søkefeltet. 3. Bruker trykker på Søk knappen. Dersom: 1. Angitt søkeord gir treff i programmet. 62

63 Use case Bestille produkt Use case Aktør Prebetingelse Bestille produkt Kunde, gjest Bruker ønsker å legge produkt inn i handlevognen Postbetingelser Produktet blir lagt inn i handlevognen Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Bruker velger en vare. 2. Bruker trykker på Kjøp -knappen. 3. Produktet flyttes til Handlevognen. Dersom: 1. Bruker trykker på Kjøp -knappen produktet flyttes til Handlevognen 63

64 Use case Fjerne produkt fra handlevogn Use case Fjerne produkt fra handlevognen Aktør Kunde, gjest Prebetingelse Bruker ønsker å slette produkt fra Handlevognen Postbetingelser Produktet slettes fra Handlevognen Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Bruker velger et produkt i Handlevognen. 2. Bruker trykker på Fjern -knappen. 3. Produktet slettes fra Handlevognen. Derson: 1. Bruker trykker på Fjern -knapen i handlevognen og produktet forsvinner fra handlekurven. 64

65 Use case Logg inn som kunde Use case Aktør Prebetingelse Logge inn som kunde Kunde Kunde får logget seg inn Postbetingelser Produktet slettes fra Handlevognen Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Systemet spør om brukernavn og passord. 2. Kunde skriver inn brukernavn og passord. 3. Kunde får tilgang til Min konto i tilfelle brukernavn og passord er riktige. 4. Kunde får ikke tilgang til Min konto og får beskjed om at brukernavn og passord er feil Dersom: 1. Kunde taster inn gyldig brukernavn og passord og man får logget seg på. 2. Kunde taster inn ugyldig brukernavn og passord og man ikke får logget seg på. 65

66 Use case Skjekk personlig info Use case Aktør Prebetingelse Skjekk personlig info Kunde Kunde ønsker å ha oversikt over kundeinfo Postbetingelser Kunde har oversikt over kundeinfo Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Kunde må være pålogget 2. Kunde trykker på Gå til -knappen under Profil i Min konto 3. Kunde går til Personlig informasjon. Derson: 1. Personlig informasjon vises 66

67 Use case Skjekk ordrehistorikk Use case Aktør Prebetingelse Skjekk ordrehistorikk Kunde Kunde ønsker å ha oversikt over alle ordre Postbetingelser Kunde har oversikt over alle ordre Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Kunde må være pålogget 2. Kunde trykker på Gå til -knappen under Mine ordre i Min konto 3. Kunde går Mine ordre Derson: 1. Alle ordre vises Adminsiden: Use case Logg inn som administrator Use case Aktør Prebetingelse Logg inn som administrator Admin Admin ønsker å logge seg inn Postbetingelser Admin får logget seg inn Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Systemet spør om brukernavn og passord. 2. Administrator skriver inn brukernavn og passord. 3. Administrator får tilgang til systemet i tilfelle brukernavn og passord er riktige. 4. Administrator får ikke tilgang til systemet og får beskjed om at brukernavn eller passord er feil. Dersom: 1. Administrator taster inn gyldig brukernavn og passord og man får logget seg på. 2. Administrator taster inn ugyldig brukernavn og passord og man ikke får logget seg på. 67

68 Use case Vise produktliste Use case Aktør Prebetingelse Vise produktliste Admin Admin ønsker å få liste over alle produkter Postbetingelser Admin får liste over alle produkter Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin trykker på Produkt og Produktliste -knappen, deretter velge kategori Derson: 1. Alle produktene listes opp, etter valgt kategori 68

69 Use case Rediger produkt (registrere, endre og slette) Use case Aktør Prebetingelse Rediger produkt Admin Admin ønsker å redigere produkt Postbetingelser Admin får redigert produkt Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin peker på Produkt og trykker på Rediger produkt -knappen 2. Admin velger enten feltet REGISTRER, ENDRE eller SLETTE. 3. Admin flyller inn feltene og får utført redigering Dersom: 1. Man får fylt ut alle felter 69

70 Use case Vise kundeliste Use case Aktør Prebetingelse Vise produktliste Admin Admin ønsker å få liste over alle produkter Postbetingelser Admin får liste over alle produkter Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin trykker på Produkt og Produktliste -knappen, deretter velge kategori Dersom: 1. Alle produktene listes opp, etter valgt kategori 70

71 Use case Rediger kunde (registrere og slette) Use case Aktør Prebetingelse Rediger kunde Admin Admin ønsker å redigere kunde Postbetingelser Admin får redigert kunde Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin peker på Kunde og trykke på Rediger kunde -knappen, deretter velge å registrere, slette eller vise kundeliste Dersom: 1. Kunde blir registrert 2. Kunde blir slettet 3. Kundeliste blir vist 71

72 Use case Vareretur Use case Aktør Prebetingelse Vareretur Admin Admin ønsker å registrere vareretur Postbetingelser Admin får registrert vareretur Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin trykker på Vareretur 2. Admin fyller inn feltene Derson: 1. Der returnerte varen blir lagt til I lagret 72

73 Use case Rediger kategori (registrere, endre og slette) Use case Aktør Prebetingelse Rediger kategori Admin Admin ønsker å redigere kategori Postbetingelser Admin får redigert kategori Hendelsesflyt Test er gjennomført og kravet er oppfylt 1. Admin trykker på Rediger kategori -knappen 2. Admin velger enten feltet Registrer, Endre Slette 3. Admin flyller inn feltene og får utført redigering Dersom: 1. Man får fylt ut alle felter Use case Ordrehistorikk (Ordre bekreftelse, Oversikt over bestillinger og Mest solgte produkter) Use case Aktør Prebetingelse Ordrehistorikk Admin Admin ønsker å bekrefte ordre, se liste over bestillinger og liste over mest solgte produkter Postbetingelser Admin får bekreftet ordre, får ut liste over betillinger og liste over mest solgte produkter Hendelsesflyt 1. Admin trykker på Ordrehistorikk -knappen, deretter velge et felt 2. Admin trykker på knappene for å se listene 73

74 Test er gjennomført og kravet er oppfylt 74

75 DELKAPITTEL 4 SKJERMBILDE AV FORSKJELLIGE NETTLESERE Et av kravene til oppdragsgiveren var at løsningen skal fungere i de mest brukte nettlesere. Derfor har vi testet om nettbutikken fungerer i flest brukte nettlesere som Internett Explorer, Mozilla Firefox, Google Chrome, Opera og Safari. 1. Mozilla Firefox: 75

76 2. Internett Explorer: 3. Google Chrome: 76

77 4. Opera: 5. Safari: 77

78 DELKAPITTEL 5 INSTANT VALIDERING Vi har brukt instant validering, altså får brukeren beskjed dersom han/hun ikke har fylt ut alle feltene. Slik sparer man tid samt som man får en bedre brukeropplevelse. Vi har instant validering i Admin sidene og i brukersidene. Nedenfor kan dere se eksempel på hvordan det fungerer. 1. Bruker siden: hvis du vil registrere seg og ikke fyller alle felter, eller ikke fyller inn riktige felter så får man følgende vindu: 78

79 2. Admin side: hvis man vil registrere nytt produkt for eksempel, og ikke fyller ut feltene får man følgende beskjed: Hvis man ikke fyller inn produktnavn får man advarseltegn når man prøver å registrere nytt produkt. På den måten kan man ikke unngå feil, og man får fullstendig registrering. 79

80 DELKAPITTEL 6 KONKLUSJON Løsningene er nesten helt feilfrie. Testingen vi har gjort har blitt utført med utgangspunkt i kravspesifikasjon og Usecase modellen vi har brukt. Vi har prioritert kravene som oppdragsgiveren har gitt, og de har vi klart å tilfredsstille. Man kan se av resultatene at det er grunn til å være fornøyd med løsningene. 80

81 81 Entobutikk

82 6.PROSESSRAPPORT VÅR

83 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen i Oslo, avd. for ingeniørutdanning våren Her beskrives det også hvordan arbeidet er fullført, hvilke utfordringer vi gikk gjennom og hvilket fundament det bygger på. I tillegg til dette forteller dokumentet i hvilken grad gruppemedlemmene har tilegnet seg kvalifiserte problemløsningsmetoder og arbeidsmetoder, og hvilken faglig utvikling vi har gjennomgått. Rapporten er beregnet for sensorer, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i utfordringer, løsninger på disse og arbeidsmetoder i prosjektet. Prosessrapporten er delt opp i hovedkapitler som planlegging og metode, utviklingsprosess og kravspesifikasjonen og dens rolle. Samt inneholder rapporten en innledning, avslutning, ordliste med datatekniske og prosessrelaterte ord og kildeoversikt. I vedlegg finner man avtale om prosjektoppgave, arbeidsplan og fremdriftsplan. Når det gjelder teknisk og beskrivelse av produktet og dets oppbygning er det dypere beskrevet i Produktrapporten. 83

84 DELKAPITTEL 3 INNLEDNING I denne del kapitelet forklares den faglige og bedriftsmessige bakgrunnen for prosjektet: gruppebeskrivelse, om bedriften, dagens situasjon, mål og rammebetingelser. 3.1 PROSJEKTGRUPPEN Gruppen vår bestod av fire studenter hvor alle er fra dataingeniør linjen. Gruppeleder var Madia Kalsoom(3AA), Mariam Bourass(3AA), Sawen Mohammad Ahmed(3AB) og Anzor Aslambekovitsj Akhmiev(3AB). Alle studentene var fra bachelorstudiet ved Høgskolen i Oslo avd. for Ingeniørutdanning. Vi alle valgte å jobbe sammen fordi vi hadde tidligere samarbeidet i flere prosjekter samt vi hadde sammenfallende oppgaveønsker, målsetninger og faglige interesse. 3.2 OM BEDRIFTEN Entobutikk er en privateid og familiedrevet nettbutikk som selger produkter innenfor data, helse og velvære. Bedriften importerer varene direkte fra fabrikker i Asia, spesielt fra Kina. Deres hovedfokus er høy kvalitet produkter med gode priser, og god service til hver enkelt kunde. Entobutikk har sterkt fokus på kundene, og derfor har de 100% fornøyde kunder. De har 14 dagers returrett/åpenkjøp. Alle produktene selges med 1 års fabrikk garanti. Ved reklamasjoner bytter entobutikk varen(e) eller returner pengene etter kundens ønske. 3.3 DAGENS SITUASJON Per i dag benytter bedriften en eksisterende nettside for å selge produktene sine. Denne nettsiden viser alle produkter og produktbeskrivelse, samt at man har mulighet til å kjøpe dem. Nettsiden er kodet med enkel html-kode. Men den mangler enkelte funksjoner og løsninger som kunne ha gjort det bedre for både kunder og administrator, som f. eks innloggingsrutiner, layout, brukervennlighet, handlekurv og historikk. Vår løsning vil bli en bedre og komplett nettbutikk for bedriften med flere funksjoner for kunder og administrator. Gruppen skulle lage en enkel og brukervennlig nettside som er lettere å bruke/lese og oppdatere. Her får kunder mulighet til å se/endre på sin historikk og personlige opplysninger. Administrator skal få kunne oppdatere siden, få oversikt over produkter og kunder uten at vedkommende må kunne programmering. 84

85 Vi skulle finne en mer avansert løsning enn den nåværende, med hensyn på brukervennlighet, sikkerhet, brukergrensesnitt, og med flere funksjoner enn den nåværende nettbutikk tilbyr. 3.4 MÅL Målet med oppgaven var å utvikle en profesjonell nettbutikk som kan gi flere og nye muligheter til kunder, administrasjon og gjester. Løsningen vår skal ha hensiktsmessig brukergrensesnitt slik at det blir så enkelt som mulig å bruke det. I og med ingen i bedriften kan avansert programmering, skal ikke løsningen kreve noen forkunnskaper innen for programmering eller avansert databruk. Entobutikk vil dele produktene sine i kategorier, slik at det blir enklere for dem å registrere et nytt produkt i en kategori. Admin skal kunne lagre ordre til en kunde, skrive ut kvittering av ordre i etikett, denne funksjonen skal være integrert i nettbutikken. Oppdragsgiveren vil også ha en søkemotor i nettbutikken for Admin som gir muligheten til å søke alt innen nettbutikken sånn som kunde, dato, produkt og produktnøkkel(id). Entobutikk krever også at løsningen skal regne ut moms på alle prisene til produktene automatisk når Admin legger det inn ut på nettbutikken. Når brukeren kjøper et produkt skal også momsgrunnlaget vises på kvitteringen. 3.5 RAMMEBETINGELSER Når det gjelder rammebetingelser var det tid som ble viktigst og påvirket valg av funksjonalitet. All funksjonalitet var vurdert med hensyn på tidsbegrensninger. Systemet var bestemt å lages relativt enkelt med mulighet for å utvides til noe ganske avansert. Gruppen hadde en diskusjon med oppdragsgiver og satt opp en liste over all funksjonalitet som vi kunne tenke oss systemet kunne ha, så prioriterte vi denne listen og utførte så mye vi rakk. Underveis la vi også til nye ideer til funksjonalitet som vi kom på og forandret på designet. Her lister vi opp rammebetingelsene vi kom fram til: Applikasjonen skal kobles opp mot en Sql server, som også støtter.net. Løsningen skal implementeres i ASP.Net. Det skal være mulig å kjøre løsningen fra skolens server og oppdragsgivers server. Løsningen må kunne hvert fall kjøres i Internet Explorer, Mozilla Firefox og Netscape. 85

86 DELKAPITTEL 4 PLANLEGGING OG METODE Planleggingsfasen var veldig viktig for oss og hadde en avgjørende betydning i forhold til hvor lang tid vi skulle bruke på prosjektet. 4.1 VALG AV PROSJEKTOPPGAVEN Før hovedprosjektet startet hadde vi avtalt på forhånd om å jobbe sammen. Derfor avtalte vi et gruppemøte der vi diskuterte alternative prosjektoppgaver. Vi hadde planlagt å programmere, og lage noe som kunne anvendes av en bedrift. Vi hadde ingen spesielle krav når det gjaldt prosjektoppgaven, men derimot var programmeringsspråket et spennende tema for oss. Vi ville ha enten PHP eller ASP.Net, flertallet i gruppa kunne ASP.Net og fåtall kunne PHP. Prosjektgruppen ville også at applikasjonen skulle utvikles med mest populære teknologi, og det var jo ASP.Net. Derfor valgte vi til slutt ASP.Net, siden det er stort etterspørsel for det i markedet og dessuten ville vi lære mer om dette. Vi så på forskjellige bedrifter og fikk kontakt med entobutikk gjennom en av gruppemedlemmene Madia Kalsoom. Entobutikk hadde et tilbud til oss om å lage en nettbutikk til deres eksisterende nettbutikk, med mulighet for nettbasert betalingssystem. Etter å ha lest gjennom oppgaveteksten, avtalte vi møte med oppdragsgiveren for å få bedre innblikk i hva oppgaven gikk ut på. Etter møtet var alle i gruppen fornøyde med oppdraget, pga prosjektets omfang og de forskjellige faglige utfordringene den hadde. Gruppen innså med engang hvor mye vi kunne lære av dette prosjektet og valgte å gå videre med dette oppdraget. 4.2 FORPROSJEKTET Det første vi gjorde i prosjektet var å lage statusrapport. Når den var godkjent begynte vi å opparbeide en prosjektskisse, forløpende ble den godkjent som hovedprosjekt og vi fikk vår intern veileder. Da vi fikk prosjektet godkjent, skrevet samarbeidsavtale og hadde skrevet kontrakt med oppdragsgiver begynte vi umiddelbart å jobbe med forprosjektrapporten. Formålet med denne rapporten var å skaffe oss en grov oversikt over hva problemområdet er, hva målene i 86

87 prosjektet er, rammebetingelsene og retningslinjer for gruppa. For å få totalt forståelse i dette, avtalte vi et nytt møte med oppdragsgiver slik at vi kunne finne ut om problemene kunne løses innenfor de rammene som var aktuelle. Selvfølgelig måtte vi begrense problemet i forhold til tids- og teknologiske rammer. Forprosjektet ble avsluttet da vi leverte arbeidsplan, fremdriftsplan og forprosjektrapport. 4.3 PLANLEGGING OG ARBEIDSFORDELING Da vi hadde levert forprosjektrapporten kom vi ganske godt i gang med planleggingsfasen. Siden planlegging var svært viktig del av prosjektet deltok alle gruppemedlemmene i planleggingsfasen. Her ble det diskutert hvordan nettbutikken skulle bygges opp, hva det skulle inneholde, utforming av brukergrensesnittet og ikke minst våre kunnskaper i faglige områder. For å få styr på alt dette, utformet vi derfor arbeids- og fremdriftsplan FREMDRIFTSPLAN OG ARBEIDSPLAN Det var ikke lett å planlegge alt i detalj på et såpass tidlig stadium i prosjektet, derfor utarbeidet vi en arbeidsplan. Dette førte til en gjennomtenking av problemene på forhånd og sikret en oversikt som gjorde det mye lettere å innhente eventuelle forsinkelser og fullføre arbeidet i tide. Under utarbeiding av fremdriftsplan ble vi enige om å ha faste gruppemøter, en gang i uka. Fordi en stor del av utvikling ble utført hjemme, vi pleide å utdele oppgaver og jobbe med dem. Deretter pleide vi å treffes på skolen ved gruppemøter, analysere det som ble gjort, fikse på eventuelle feil, diskuterte videre arbeid og fordele oppgaver. Vi tenkte også å bruke meste tiden på å jobbe gjennom prosjektet, ved å ha mindre faste møter. Gjennom fremdriftsplanen ser alt nesten perfekt ut men likevel fikk vi dårlig tid på slutten av prosjektet. Men vi klarte å utvikle meste av funksjonalitet som vi hadde planlagt. Det burde kanskje vært estimert og brukt mer tid på design og testing av systemet. Arbeids- og fremdriftsplan var til veldig stort hjelp for å holde frister, ha oversikt og for ikke å gå glipp av viktige deler av prosjektet. Vi brukte begge dokumentene aktiv gjennom hele prosjektgjennomføringen. Man finner fremdriftsplan og arbeidsplan under styringsdokumentene. 87

88 4.4 MØTEREFERATER Gruppen vår skrev ikke prosjektdagbok, i stedet skrev vi alle viktige stadiene og hendelsene inn i våre møtereferater som vi hadde hver uke. Som sagt hadde vi faste gruppemøter, og gjennom dem fikk vi alltid innblikk i hva som hadde skjedd og hva som skulle skje. Dermed noterte møtereferent alt som ble diskutert i møtet, og sendte det aktivt gjennom e-post til alle gruppemedlemmene. Samtidig ble møtereferatene oppdatert på gruppas hjemmeside, slik at alle har tilgang til dem. Dette har gitt oss et godt grunnlag og har gjort det enklere for oss å skrive prosessrapporten. 4.5 KRAVSPESIFIKASJON Kravspesifikasjonen var svært nyttig sett i forhold til produktet vi ønsket å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet og forteller oss hva vi skal lage, og hvordan produktet prinsipielt skal fungere. Dette dokumentet ga alle parter et innsyn i hvordan oppdragsgiver og prosjektgruppen har utdypet oppgavebeskrivelsen, ved å definere hvilke krav som oppgaveløsningen skal oppfylle. Gjennom kravspesifikasjon fikk vi dekket alle ønskene og behovene oppdragsgiver hadde til dette prosjektet. En mer utfyllende kravspesifikasjon er utledet i eget dokument, under styringsdokumentene. 4.6 RISIKOPLAN Hvor du har planlegging av et stor eller små prosjekt, må man alltid se etter risikoer som kan inntreffe den. Vi har laget en oversiktlig risikoplan hvor vi har prøvd å identifisere og vurdere de viktigste risikoene ved prosjektet vårt. Denne planen forteller hvor stor sannsynlighet det er for at en risiko inntreffer, hvordan man kan forebygge den og hvilket tiltak det finnes hvis noe oppstår. Grunnet risikoplanets omfang har vi valgt å legge den i styringsdokumenter, slik at det ikke går ut over rapportens rekkevidde. 4.7 TEKNOLOGI Som sagt valgte vi en teknologi som er riktig i forhold til systemets kompatibilitet og nettbutikkens fremtid. Vi har tidligere nevnt av ASP.Net er for tiden veldig populær teknologi for å lage interaktive og brukervennlige websider. Denne teknologien er utviklet av Microsoft, og dens løsninger kan kjøres på alle servere som støtter Windows. ASP.Net gjør det enklere og raskere å lage moderne og avanserte applikasjoner. Dette kan være web, multimedia, og bedriftsløsninger med tjenesteorientert arkitektur. Per i dag ser vi at 88

89 nesten 60 % av alle nye prosjekter benytter ASP.Net, og når vi så at den er så stor i bruk, valgte vi denne teknologi. Ikke minste spilte det en stor rolle for oss at alle gruppemedlemmene gjennomførte faget Webapplikasjoner i forrige semesteret og fikk en del kunnskaper og erfaringer som vi kunne få bruk for i dette prosjektet. For å kunne utvikle systemet i ASP.Net brukte vi utviklingsverktøy Microsoft Visual Studio 2010, LINQ to SQL og SQL som database. 89

90 DELKAPITTEL 5 UTVIKLINGSPROSESS Utviklingsprosess beskriver hvilken faser prosjektet hatt gjennom utviklingen, hvilket valg vi har tatt for oppbyggingen og funksjonen i nettbutikken og hvilke utfordringer vi møtte. 5.1 SAMARBEID I starten av prosjektet skrev vi sammen samarbeidsavtale for at det ikke skal oppstå noen problemer i samarbeidet. Gjennom hele prosjektperioden har gruppa vår hatt et godt samarbeid som er preget av god kommunikasjon og forståelse av andres problemer. Vi har hjulpet hverandre med å komme ut av vanskelige situasjoner, og har hatt stort stå på vilje. Videre har vi hatt godt samarbeid og god kommunikasjon med oppdragsgiver gjennom tilbakemeldinger fra Madia med entobutikk. Samarbeidsavtale kan man finne i styringsdokumentene. 5.2 STARTFASEN Selve utviklingsprosessen starten med å sitte og diskutere sammen om kunnskaper gruppa hadde, programmeringsspråk og utviklingsmiljø. Målet vårt var å finne om vi kunne utvikle alt av funksjonalitet i løpet av hele prosjektperioden VALG AV DESIGN OG STRUKTUR Når det gjelder design og struktur måtte vi ta hensyn til døve og blinde slik at de også får tilgang til nettbutikken. Dermed stod vi ikke i fritt for valg av utseende, farger og diverse ting. Samt skulle designet også tilpasse de funksjonelle kravene vi hadde utarbeidet sammen med entobutikk. I starten lagde vi enkel designskisse på hvordan nettbutikken ville se ut. Designskisse består av flere bilder som har representert aspx sidene. Designskisse er vedlagt. 90

91 5.3 UTVIKLINGSFASEN I denne prosessen utarbeidet i nettbutikkens hoveddel og utviklet dens database. Utviklingsfasen var også den mest produktive perioden i prosjektarbeidet vårt USE CASE MODELL Nedenfor har vi illustrert use case modell som ble aktivt brukt gjennom hele utviklingsprosessen. Denne modellen beskriver systemets funksjonalitet og er beskrevet mer utfyllende i kravspesifikasjon. Modellen vi har laget under inneholder: Se produkter, Se ordrehistorikk, Ordreliste, Bestille produkt av kunde, Redigere Produkter av Admin, Registrere info, Redigere kunderegister og Se kundeliste. 1.Use Case modell. 91

92 5.3.2 DESIGN OG STRUKTUR Gruppen har brukt veldig mye tid på å designe og strukturere nettbutikken. Som sagt skulle nettbutikken utvikles med hensyn for de blinde og døve. Samt skulle den være brukervennlig, enkel og fin design. Vi stod i fritt om å velge strukturen til nettbutikken da oppdragsgiveren ikke hadde noe krav om dette. Nedenfor ser dere bilder om hvordan det så ut. 2. Hovedsiden. 92

93 3. Kontakt oss. 4. Produkt siden. 93

94 5.3.3 DATABASEN For oss var det veldig viktig å bli ferdig med databasen for å videreutvikle systemet. I forbindelse med det hadde vi flere møter med oppdragsgiver for å få full informasjon om hva som kunne være med. Vi måtte tenke godt gjennom alle entitetene og attributtene før vi skulle fylle ut tabellene med data og begynne å kode. Fordi lager man ikke en presis database i forhold til behovet, kan dette føre til at tabellene må forandres midt i utviklingen og forårsake forandringer av hele programmet. Dermed lagde vi databasemodell som var veldig viktig i forhold til planlegging av en database. Anzor var ansvarlig for videreutvikling av databasen. Databasemodellen ser dere under men mer utfyllende beskrivelse finner man i produktrapporten. 94

95 5.4 SLUTTFASEN I sluttfasen brukte vi meste tiden på testing av systemet og ferdigstillelsen av dokumentasjonen TESTING Mye av testing foregikk parallelt med programmeringen. Fordi når vi lagde en funksjon, kunne vi ikke gå videre med det før vi ikke hadde testet den eller feilsøkt den. Dermed gikk mye av tiden under programmeringsfasen under feilsøking og testing av systemet. Mer om testing finner man i testrapport hvor det er beskrevet slags kvalitetssikring som er gjennomført: hvilke tester som er utført og hvilke feil det er testet med hensyn på DOKUMENTASJON Dokumentasjonen har vi jobbet med gjennom hele prosjektperioden. Vi begynte med status rapport, prosjektskisse også forprosjektrapporten før prosjektet starten. Senere utarbeidet vi kravspesifikasjon, risikoplan, arbeids- og fremdriftsplan. Videre har vi hele veien utført møtereferater, og endret på kravspesifikasjonen. Gruppen begynte å jobbe med sluttdokumentasjon så snart vi kom litt over halvveis i prosjektperioden, men det ble mye oppdateringer samtidig som systemet ble utviklet. På slutten av prosjektet har vi brukt meste parten av tiden med testing og redigering av sluttdokumentasjon. 95

96 DELKAPITTEL 6 UTFORDRINGER I denne delen av rapporten tar vi for seg utfordringer gruppen møtte under hele prosjektperioden. Samtidig har vi også prøvd å finne løsninger til 6.1 SERVERTILKOBLING Løsningen vår skulle utvikles med ASP.Net, og da må den kjøres med en Microsoft Server. Oppdragsgiver kjøper servertjenester hos som kun tilbyr MySQL database. Utfordringen ble å få løsningen til å fungere med bedriftens database. Resultatet ble at oppdragsgiveren måtte kjøpe nye servertjenester hos Webhuset, som tilbyr Microsoft server og som kan integrere med løsningen vår. 6.2 BETALINGSSYSTEM Vi har jobbet mye for å kunne implementere en bankbetalingsløsning i betalingssystemet. Siden vi tidligere aldri hadde jobbet med betalingssystemer som PayPal og DIBS, kom vi på en rekke utfordringer med tanke på sikkerhet, ryddighet og godkjenning av betalingen. Vi hadde ikke kunnskap om hvordan vi kunne integrere hele betalings- og godkjenningssystemet i løsningen vår. Resultatet ble at vi kontaktet PayPal og fikk en rekke opplysninger om hvordan vi kunne implementere det inn i løsningen vår. 6.3 SAMME FUNKSJONALITET I NETTLESERE I følge statistikken bruker 80 % av brukerne Internet Explorer, og 20 % bruker andre typer nettlesere. Etter krav fra oppdragsgiveren skulle løsningen fungere i de fleste nettlesere. Følgende nettlesere har vi testet: - Mozilla FireFox - Microsoft Internet Explorer - Netscape Browser Største utfordringen her var spesielt design, om hvordan de forskjellige nettlesere tolker designregler i stilark. Derfor har vi prøvd å spesifisere alle verdier i stilarket for å få best mulig resultat. 96

97 DELKAPITTEL 7 KRAVSPESIFIKASJON OG DENS ROLLE Kravspesifikasjonen har vært en god veiledning for oss gjennom prosjektet. Alle kravene var godt gjennomtenkt før arbeidet med utviklingen startet. Vi har underveis gjort endringer i kravspesifikasjonen i forhold til funksjonelle krav. Vi mener at kravspesifikasjonen samsvarer med det produktet som vi har beskrevet i produktdokumentasjonen. 97

98 DELKAPITTEL 8 AVSLUTNING Dette kapitelet tar for seg gruppas vurderinger av prosjektresultatene i henhold til prosjektmål, produktutvikling og fremtid. 8.1 EVALUERING AV PROSJEKTGRUPPE Gjennom prosjektperioden har vi gjort stor innsats og har lært mye nytt. Vi har fått mange erfaringer som vi kan ta med oss videre i arbeidslivet. Gruppen har hatt en brattlæringskurve, har settet oss i nye teknologier og verktøyer samt som vi har lært mye om prosjektarbeid og samarbeid. Vi er svært fornøyd med resultatet, selv om vi kunne ha brukt mer tid på testing og finpussing. Systemet er i bruk og fungerer med de fleste funksjonene. 8.2 PRODUKTETS FREMTID Vi har utviklet en nettbutikk til som entobutikk kan ta i bruk med engang vi har overført systemet på deres server. Det er gode muligheter til å videre utvikle nettbutikken, men hensyn på funksjoner og applikasjoner. Alle utviklere som kjenner til ASP.Net kan ta over systemet for å legge til nye moduler og funksjoner. 8.3 KONKLUSJON Gruppen mener at prosjektet var vellykket, vi har oppnådd samtlige mål for prosjektet og er godt fornøyd med gjennomføringen og resultatet. Selv om det var et par ting vi ville ha gjort mer av, f. eks testing med hensyn på enhetstest. Vi har laget nettbutikk for entobutikk som tilsvarer kravene vi har fått fra arbeidsgiveren. For gjennomføringen av prosjektet har vi brukt Microsoft Visual Studio og Microsoft Office Visio 2007, Paint, ArgoUML, og har fått mer erfaring i bruken av disse programmene. Gjennom prosjektet har vi fått nye kunnskaper og gode erfaringer når det gjelder planlegging, organisering, implementering og gjennomføring av prosjektet. Vi har hatt god samarbeid og hatt god kommunikasjon med hverandre innad i gruppen men også med veileder og oppdragsgiver. Dette har hatt stort betydning for utfallet av prosjektet. 98

99 Vi har hatt mye fokus med oppbygning av databasen, dermed har vi brukt mye tid på dette og dets planlegging. Men vi har godt fulgt arbeidsplan og fremdriftsplan for å ha oversikt over om vi er i rute eller ikke. Gruppen har tatt med alle de viktigste hovedtemaene og synspunktene i prosjektarbeidet i dette dokumentet(prosessrapport), som er oversiktelig og strukturert. Gruppen mener dette har vært veldig lærerikt og spennende prosjekt å jobbe med. 99

100 DELKAPITTEL 9 ORDLISTE Use case modell: blir laget i UML(Unified Modeling Language) og blir brukt til å gi en grafisk oversikt over funksjonaliteten i systemet i form av aktører og deres mål. Microsoft Office Visio 2007: er program for Microsoft Windows som bruker vektorgrafikk til å lage diagrammer. Microsoft Visual Studio 2010: er verktøy utviklet fra Microsoft og blir brukt til å utvikle nettsider, web-applikasjoner og andre webtjenester. Dette programmet støtter ulike programmeringspråk som Visual C++, Visual C#, Visual J#, ASP.NET og Visual Basic.NET. ASP.NET: er webapplikasjonsrammeverk(.net) som er utviklet av Microsoft og er bygget på Common Language Runtime(CLR)..NET gir mulighet til å programmere dynamiske websider og webapplikasjoner. #C: uttales som C sharp, er objektorientert programmeringsspråk utviklet av Microsoft innen. NET. C# er basert på programmeringsspråkene Java og C++. ArgoUML: er et diagram-program som er skrevet i Java og brukes til å lage UML(Unified Modeling Language) diagrammer. Paint: er utviklet av Microsoft og er grafikk maleri program som brukes til å åpne og lagre filer som JPEG, GIF og PNG. PayPal: er en betalingssystem på nett som kan brukes til å kunne overføre penger over internett. 100

101 DELKAPITTEL 10 KILDER 5. Forelesninger fra Webapplikasjoner faget. 6. Informasjon fra entobutikk. 7. Internett. 8. Wikipedia. Bøker 6. Programming ASP.NET 3,5: Liberhy, Hur Witz and Maharry, Fourth edition. October Kompendiet: Dokumentasjonsstandard for Hovedprosjekter i DATA/IT, IU, Høgskolen i Oslo, Ann-Mari Torvatn, januar Systemutvikling, Applikasjoner og databaser, Thor E.Hasle, 2008, Cappelen Akademisk Forlag. 101

102 102 Entobutikk

103 5.BRUKERMANUAL VÅR

104 DELKAPITTEL 1 FORORD Denne brukermanual inneholder instrukser til hvordan nettbutikken entobutikk fungerer. Rapporten er delt opp i tre deler som er Admin, Kunde og nettbutikken. Rapporten er beregnet for sensorer, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i systemet. 104

105 DELKAPITTEL 2 ADMINISTRATOR 2.1 LOGGINN Administrator har fått eget url som er bare tilgjengelig for han. URL ser følgende ut: Når man trykker på denne linken vil du komme til innlogging side hvor du blir bedt om å taste inn brukernavn og passord, som man kan se i kommende bilde: Brukernavnet er : entobutikk@entobutikk.no Passordet er: ento Trykk dertter Logg inn knappen, da er du logget inn og får følgende bilde opp: 105

106 2.2 PRODUKTER Admin får som sagt legge til nye produkter, endre på eksisterende produkter og slette produkter. For å gjøre noe av det må man trykke på produkter også velge Redigere produkter. Da vil du få opp følgende bilde: Her får man tre alternativer. 1. REGISTRER: gir deg mulighet til å registrere nye produkter, ved å fylle inn følgende data: 106

107 Her kan du også laste opp bilde av produktet også trykke på Registrer knappen, da er produktet registrert i databasen. 2. ENDRE: her kan du endre på et produkt ved å søke etter produktets navn. For eksempel kan du taste inn produktnavn Acer, da vil du få følgende resultat: 107

108 Videre kan du endre produktets innhold som følgende: Tilslutt må du taste inn produkt ID til det produktet du vil endre. 108

109 3. SLETTE: her kan du slette et produkt ved å fylle inn produktets navn og produkt ID, og deretter trykke på slett knappen. Da vil du få melding om sletting ble vellykket 2.3 VARERETUR Ofte kan det hende at et produkt blir returnert av en kunde. Og da må Admin registere det returnerte produktet inn i databasen. Dette gjør du ved å legge inn produktet navn, ID og antall. Vinduet du får opp, ser slik ut: 109

110 2.4 KUNDE Admin har mulighet til å liste ut alle kundene, redigere kunde og slette dem. For å registrere nye kunder må man trykke på kunde Registrering : Da vil man få opp følgende vindu: Her fyller man inn all informasjon om kunde og trykker på Registrer knappen, dermed vil en kunde blir registrert i systemet. Det blir også opprettet en kundenr automatisk i det man registrer ny kunde. 110

111 For å slette en kunde kan man trykke på kunde slett. Her kan man søke etter kunde sin fornavn og deretter fylle inn kundenummer og trykke på slette. Når man trykker på knappen, vil kunden bli slettet fra hele systemet og fra databasen. Slik ser vinduet for slett funksjonen: Admin kan også liste opp alle kundene, slik ser lista ut: 111

112 2.5 REDIGERE KATEGORI Her får man to valgmuligheter, ene er å registrere nytt kategori og andre er Endre/slette eksisterende kategori. Når du registrerer nytt kategori kan du også registrere ny underkategori, men det er ikke påbudt. Fordi ikke alle kategorier har en underkategori, er det fritt valg om å registrere underkategori. Ny kategori blir registrer i databasen. Når du vil slette en kategori kan man gjøre det ved hjelp av endre/slett knappen. Her må du fylle inn kategori ID og underkategori ID hvis det eksisterer. Sletting av kategori berører også databasen, altså vil den bli sletten av databasen. For å endre kategorinavn, kan man taste inn kategori ID og taste inn nytt navn. Slik ser vinduet: 112

113 2.6 ORDREHISTORIKK Admin kan se ordre/bestilling som en kunde har sendt. Altså når en kunde kjøper et produkt så kommer det produktet inn i ordreliste/bestillingsliste hos Admin, og da må Admin bekrefte eller slette denne ordre. Slik ser vinduet ut for en ordreliste: Admin har også mulighet til å se mest solgte produkter, da vil liste se følgende ut: 2.7 SILVERLIGHT Her kan Admin legge til nye bilder og tekst som skal vises i animasjonen på hovedsiden til nettbutikken. 2.8 LOGGUT Ved å trykke på logg ut blir man logget ut av hele systemet og logge seg inn på nytt for å få tilgang til Administratorside. 113

114 DELKAPITTEL 3 KUNDE Kunder har mulighet til å besøke nettbutikken med følgende URL: Slik ser hovedsiden ut: Helt øverst på siden ser man denne logg inn vinduet, her kan man logge seg inn som kunde med gyldig e- post adresse og passord. Hvis man er ny bruker eller har glemt passord så trykker man på ny bruker/glemt passord. 114

115 3.1 REGISTRERE NY KUNDE For å registrere ny kunde trykker man på nybruker/glemt passord. Og deretter fyller ut alle feltene som ser følgende ut: 3.2 LOGGE INN OG ENDRE INFO Etter å ha registrert seg får man beskjed om at du er nå kunde hos oss. Og dermed kan man logge seg inn med e-post og passord. Når man er logget inn som kunde, trykker man på min konto og da har man mulighet til å se på sine eldre bestillinger eller endre personlig informasjon. Slik ser vinduet ut: 115

116 Ved å velge første alternativet Profil Gå til får man følgende vindu: Her kan man endre hele informasjonen, altså passord, adresse, navn og mye mer. Etter å ha endret informasjon trykker man på Oppdater slik at informasjonen blir vellykket endret. En kunde kan også se sin ordrehistorikk ved å velge andre alternativet Mine ordre Gå til. Da får man frem alle ordrer en kunde har bestilt tidligere. 116

117 3.2 KJØPE PRODUKT For å få oversikt over produkter må man gå til menyen på venstre side, her kan man trykke på en kategori og underkategori. Da vil du oversikt over alle produkter som tilhører den enkelte kategorien. Slik ser vinduet ut: For å få mer informasjon om et produkt, trykk mer om produktet. Da får man følgende vindu: 117

118 For å kjøpe et produkt, trykker man på kjøp knappen. Da blir produktet lagt inn i handlekurven. Og for å fullføre kjøpet trykker man på handlekurven helt øverst på høyresiden. Da vil vinduet se slik ut: Her får man vite hvor mye frakt er og hvor mye produktet koster. For å slette produktet fra handlekurven kan man trykke på fjern under Antall. For å betale for kjøpet, trykker man på Neste da får man beskjed om logge inn eller registrere seg som gjest: 1) Hvis man trykker på jeg er gjest, blir du videresendt til registreringssiden, men da har du ikke alle muligheter som en kunde har, som for eksempel Endre personlig informasjon eller å se ordrehistorikk. 2) Hvis man logger inn får man følgende valg: 118

119 Dersom man velger faktura, får Admin mail om at det har kommet en ordre og må sende produktet og faktura manuelt. Men dersom man velger Betal med PayPal, får man følgende vindu: Her kan man fylle ut all informasjon og fullføre kjøpet. 119

120 KAPITTEL 2 KONKLUSJON I helheten mener vi at prosjektet var vellykket. Vi har lært utrolig mye innen programmering og prosjektarbeid. Og dette har vært ganske spennende å jobbe med. Vi har utviklet en nettbutikk som fungerer sånn som den skal, og håper derfor for at oppdragsgiveren blir glad. 120

121 6.VEDLEGG VÅR

122 122 Entobutikk

123 VEDLEGG 1 123

124 124 Entobutikk

125 125 Entobutikk

126 126 Entobutikk

127 VEDLEGG 2 SAMARBEIDSAVTALE Innledende Alle skal møte presis til avtalte gruppemøter. Man plikter til å melde fra i god tid dersom man blir forsinket, eller ikke kan komme på avtalte møter. Alle plikter til å sjekke E-post i ukedagene, eller gi beskjed om de ikke har tilgang. Ved lengre sykdom eller fravær har gruppemedlemmet plikt til å holde seg oppdatert til gruppearbeidet. Det skal gis konstruktiv kritikk innad i gruppen, men den skal være saklig og begrunnet. Hold tidsfrister. Gi beskjed eller be om hjelp dersom man ikke får gjort arbeidet man er pålagt til det tidspunktet som er gitt. Dersom gruppemedlemmet gjentatte ganger bryter reglene, vil det bli gitt først muntlig advarsel om utestengning. Hvis medlemmet ikke skjerper seg vil det bli gitt skriftlig advarsel. Eventuelt vil medlemmet bli utestengt i samarbeid med veileder. Hvis det konflikter oppstår, vil prosjektleder avgjøre. Eventuelt kan veileder Aktivitet Beskrivelse Frist/ferdig bringes inn. Ha god kommunikasjon med oppdragsgiver, veileder og mellom gruppemedlemmen VEDLEGG 3 ARBEIDSPLAN 127

128 Statusrapport Beskrivelse av hva vi ønsker å ha i prosjektet og valg av grupper. 29.okt.2010 kl 1500 Prosjektskisse Beskrivelse av prosjekt og arbeidsgiver. 02.des.2010 Prosjektside Lage hjemmeside for prosjektet hvor all 20.jan.2011 dokumentasjon legges ut. Forprosjektrapport Grundig og utfyllende beskrivelse av prosjektmål, 28.jan.2011 rammebetingelser, løsninger og analyser. Arbeidsplan Totalt oversikt over hva som skal gjøres i prosjektet 24.jan.2011 med oppgitte frister. Fremdriftsplan Totalt oversikt over tidsfordeling av arbeidet. 22.jan.2011 Utvikling Sette opp database Oppretter en database med tabeller og koblinger. Uke 7 Læring LINQ/MySQL db Repetisjon/lære mer/oppfriske metoder. Før prosjektstart ASP.NET Repetisjon/lære mer/oppfriske metoder. Før prosjektstart Nødvendige programinstallasjon Laste ned riktig program, verktøy, samle ressurser. Før prosjektstart Kravspesifikasjon Datainnsamling Dataanalyse Kravspesifikasjon Design Kundesystem Adminsystem Historikk/statistikk Kontakter oppdragsgiver for å få med seg flere krav, behov og evt. ønsker Analysere datainnsamlingen med tanke på begrensninger, design, sikkerhet og brukerkvalitet. Begynner å skrive fullstendig kravspesifikasjon med hensyn på dataanalysen. Lage et godt og brukervennlig grensesnitt, kan endres underveis med flere ideer. Lage registrering og bestillingssystem for kunder som bruker nettstedet. Lage adminside for selve oppdragsgiveren med loginn funksjon. Lager statistikk om varer, kunder og ordrer for admin. Uke 5 Uke 5 Uke 5- Uke 6 Uke 10 Uke 12 Uke 13 Uke 15 Testing og feilsøking Brukertest Lar interne og eksterne personer teste nettbutikken, ser om det dukker opp feil eller om den er brukervennlig. Uke 17 Databasetest Tester databasen om den fungerer som den skal. Uke 17 Finpusse kode Sørger for at koden er fullstendig og oversiktelig. Uke 17 Dokumentasjon Prosjektdagbok Fører prosjektdagbok gjennom hele prosjektet. 29.mai.2011 Lager Lager en veiledningsdokument for oppdragsgiver. Uke

129 brukermanual Sluttrapport Skriver prosess, produkt og testrapport. 29.mai.2011 Avslutning Forberede Gjøre oss klar til presentasjon, gjøre klar Uke 23 presentasjon presentasjonsmåte. Presentasjon Presentere hovedprosjektet frem for sensor. Uke

130 VEDLEGG 4 FREMDRIFTSPLAN 130