Innhold Forord 1. Innledning 1.1 Innloggingsinformasjon LM Dahl Webshop Database 1.2 Gruppen 1.3 Oppdragsgiver 1.3.

Størrelse: px
Begynne med side:

Download "Innhold Forord 1. Innledning 1.1 Innloggingsinformasjon 1.1.1 LM Dahl Webshop 1.1.2 Database 1.2 Gruppen 1.3 Oppdragsgiver 1.3."

Transkript

1 1

2 2

3 Innhold Forord 1. Innledning 1.1 Innloggingsinformasjon LM Dahl Webshop Database 1.2 Gruppen 1.3 Oppdragsgiver Om LM Dahl Ingeniørfirma AS ERP system 1.4 Oppgaven 1.5 Mål for prosjektet Hovedmål Andre mål 2. Forprosjektrapport Presentasjon Sammendrag Dagens situasjon Salg Produkt & Lager Mål og rammebetingelser Løsninger / alternativer Analyse av virkninger 3. Kravspesifikasjon 3.1 Systemkrav 3.2 Krav til design 3.3 Krav til universell utforming 3.4 Krav til koden 3.5 Krav til dokumentasjon 3.6 Funksjonelle krav Administrator Kunder Uregistrerte kunder (gjester) Produkter Kategorier Handlevogn Ordre Kontakt 3.7 Use case Diagram Beskrivelser 3

4 4. Prosessdokumentasjon 4.1. Planlegging og metode Hvordan angripe oppgaven Metode Fremdriftsplan Arbeidsmetodikk Risikoanalyse Utvikling av kravspesifikasjon Prosjektets hjemmeside og dagbok 4.2. Utvikling Samarbeid under utvikling Valg av database og nettsidestruktur Designvalg DNR (Do Not Resuscitate) Point of no return Testing Utfordringer 4.3 Konklusjon 5. Produktdokumenetasjon 5.1 Forord 5.2. Teknologier Rammebetingelser Språk Beskrivelse av teknologi Utviklingsmiljø Nettlesere Mamut-connect (Xlink) 5.3. Samsvar mellom kravspesifikasjon og produkt 5.4 Nettsidens oppbygning og virkemåte Nettsidens struktur Funksjonalitet bak produktbestilling Komunikasjon med mamut Databasestruktur Databasen: Tabeller og relasjoner Kommunikasjon med database 5.5 Hovedfunksjonalitet og sekundærfunksjonalitet 5.6 Sikkerhet 5.7 Krav til miljø 5.8 Videreutvikling Tilrettelegging for videreutvikling Anbefalt videreutvikling 5.9 Revidert usecase Main success scenario 4

5 6. Brukerveiledning 6.1 Forord 6.2 Brukerveiledning (beskrivelse av nettsiden) Toppmeny Forside Produktside Handlevogn Ordrefullføring Min side Administratorkontrollpanelet Logg inn / Logg ut Signup Glemt brukernavn / Glemt passord Kontakt oss Kontaktskjema Vedlegg Vedlegg 1 Fremdriftsplan Vedlegg 2 Arbeidsplan Aktivitet Beskrivelse Ferdig Vedlegg 3 Risikoanalyse Hendelse Sannsynlighet Konsekvens Løsning Vedlegg 4 Databaseiterasjoner Vedlegg 5 Kildekode 5

6 Forord Denne rapporten dokumenterer gjennomføringen av Gruppe 34 sitt hovedprosjekt LM Dahl Webshop ved Høgskolen i Oslo og Akershus våren Dette inkluderer planlegging, arbeidsmetoder, arbeidsfordeling og håndtering av problemer underveis. Gruppen består av fire personer som studerer anvendt datateknologi, dette prosjektet er den avsluttende oppgaven i utdanningen. Oppgaven går ut på å utvikle en Nettbutikk for LM Dahl ingeniørfirma A/S som er en leverandør av boltsveisutstyr, festemidler, sveise- og instustriforheng m.m. Denne bedriften driver med salg, men er avhengig av at kunder gjennomfører bestillinger over telefon eller lignende. En nettbutikk vil forhåpentligvis optimalisere bedriftens salgsprosess, og gi de ansatte tid til å utføre andre oppgaver. Beskrivelsen av utviklingen er primært ment for sensor, men kan også gi gode instrukser til andre om hvordan man utvikler en nettside fra bunnen av, da den beskriver oppgaven, målene, utviklingprosessen, produktet, testingen og instrukser for drifting og bruk av nettsiden. Det vil være nødvendig med kunnskap om web-programmering for å forstå deler av rapporten. 6

7 1. Innledning 1.1 Innloggingsinformasjon Under følger innloggingsinformasjon for henholdsvis Administratorkonto og Brukerkonto. Vi har lagt ved dette slik at sensor, og eventuelt andre, skal kunne enkelt logge seg inn på siden. Brukerkontoer kan opprettes igjennom signup -siden som man finner ved å trykke på logg inn -knappen. Vi anbefaler sterkt at man oppretter en egen firma- og brukerkonto slik at en ekte epostadresse blir registrert. Dette gjør at funksjonalitet som passordgjennopprettelse og ordrebekreftelse fungerer. Administratorkontoer kan ikke opprettes fra signupskjemaet, og derfor må kontoen vi har lagt ved benyttes for å teste adminfunksjonalitet. Vi har lagt inn eksempeldata i form av firma, brukere, ordre, adresser, produkter o.l for å gi en mer realistisk opplevelse til den innloggede brukeren LM Dahl Webshop Administratorkonto: Brukernavn: administrator Passord: Gruppe34 Brukerkonto Brukernavn: brukerkonto Passord: Gruppe Database Hvis det er behov for å få tilgang til databasen er informasjonen som er nødvendig for å gjøre dette oppgitt her. Denne brukeren har kun leserettigheter, da dette er bedriftens egen database. Hvis det er behov for mer en leserettigheter vennligst kontakt en av gruppens medlemmer. Databasens adresse: https://phpmyadmin.surftown.com/navigation.php?lang=no-utf-8&server=18&convcharset=iso &collation_connection=utf8_unicode_ci&token=d7cdfbb cc3cd23dd6e542e7b6 Database server: mydb18.surf-town.net Databasenavn: LMDahl_nettbutikk Brukernavn: LMDahl_leser Passord: dfpodf6594 7

8 1.2 Gruppen Gruppen består av Bjørn Bergan, Abdi Baisa, Magnus Dahl Hegge og Mads Larsen. Alle gruppens medlemmer studerer anvendt datateknologi ved Høgskolen i Oslo og Akershus. Gruppemedlemmene har arbeidet sammen under hele utdanningsperioden med unntak av et semester hvor Magnus Dahl Hegge studerte i Australia. Samarbeidet har alltid fungert meget godt, og gruppemedlemmene ønsket å jobbe videre sammen med hovedprosjektoppgaven, da man så for seg at dette ville gi et bra resultat. For å gjennomføre et prosjekt av denne typen var det behov for en god arbeidsfordeling og en fagforståelse innenfor flere emner. Kunnskapsfordelingen i gruppen har alltid vært særdeles kurant for prosjektarbeid, da noen gruppemedlemmer er gode på php, html og css, mens andre er gode på prosjektplanlegging og dokumentering av arbeid. 1.3 Oppdragsgiver Om LM Dahl Ingeniørfirma AS LM Dahl Ingeniørfirma AS, herved LM Dahl, ble etablert i 1976 og driver primært med salg av boltsveiseapparater og forbruksvarer som brukes til brannisolering og offshoreindustri, men er også i mindre grad involvert i andre bransjer. Bedriften har spesialisert seg i et svært begrenset område, og står som en av de største leverandørene av denne type produkter i Norge. LM Dahl har sin kundebase i land som Saudi Arabia og India, i tillegg til land i Skandinavia, men de har kun tre faste ansatte som håndterer den daglige driften. Per dagsdato opererer LM Dahl med inngående telefon- og faxsalg. En av bedriftens ansatte mottar bestillingen og plotter inn nødvendig data i bedriftens ERP-system 1. Dette er en særdeles tungvinn arbeidsmetodikk, og kan skape en flaskehals under tider med stor pågang ERP system LM Dahl bruker Mamut Business Software Enterprise E5, herved Mamut, som sitt ERP, CRM 2 og SRM 3 system. Mamut håndterer varelageret, fakturaer, ordre og kundebilder og blir kjørt lokalt på virksomhetens server 1 Enterprise resource planning (ERP) er en betegnelse på programvare som støtter opp som et flertall av en bedrifts virksomhetsområder, som produksjon, lager, salg, innkjøp og økonomi. 2 Kunderelasjonshåndtering er programvare for å håndtere kunderelasjoner og relasjoner til ansatte. 3 Supplier relationship managment er programvare for å håndtere relasjoner mellom bedriften og tredjepart. 8

9 1.4 Oppgaven Oppgaven går ut på å utvikle en nettbutikk for LM Dahl, som i tillegg kan erstatte den nåværende nettsiden, som inneholder generell informasjon om bedriften, kontaktinformasjon og en oversikt over produkter bedriften tilbyr. Nettbutikken tar utgangspunkt i siden slik den er i dag, men all dens funksjonalitet vil lages fra bunnen av ved hjelp av PHP, HTML, CSS, SQL og Javascript (se seksjon for beskrivelse av teknologier brukt). Bedriften bruker salgsverktøyet Mamut for å registrere kjøp og lagerbeholdning, og det vil være nødvendig å sørge for kommunikasjon mellom nettbutikkens database og Mamuts egen database. Bedriften har krav til produktet som skal produseres. Dette inkluderer at priser ikke skal være synlig for brukere som ikke er registrert som kunder, at brukere må tilhøre et firma som blir registrert som kunde og at firmaer må godkjennes som kunde av LM Dahl, som i tillegg aktiverer firmaet som registrert kunde før de kan logge inn på nettsiden. Dette er krav nettsiden må møte før bedriften kan ta den i bruk. Bakgrunnen for at at denne oppgaven ble valgt var at alle gruppemedlemmene ønsket å arbeide med et prosjekt hvor man utviklet et produkt, og en nettbutikk virket som et fornuftig alternativ siden det vil kreve mer funksjonalitet enn det en vanlig nettside gjør, både med tanke på interaksjon med nettsiden, og nettsidens kommunikasjon med databaser. 1.5 Mål for prosjektet Hovedmål Gruppen har som sine to hovedmål å lage et produkt som tilfredstiller kravspesifikasjonen som ble laget i planleggingsfasen, og å levere et produkt som vi er fornøyde med, og som oppdragsgiver vil kunne bruke i lang tid fremover Andre mål Andre mål for prosjektet inkluderer: Nettsiden er godt nok utviklet til at bedriften kan ta det i bruk slik den er når den leveres til sensor uten at det er behov for videreutvikling. Lære mer om system- og nettsideutvikling. Få flere erfaringer som kan bli nyttige i arbeidslivet. Utnytte resursser og kunnskap som vi har tilegnet oss iløpet av utdanningen 9

10 2. Forprosjektrapport Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste semester på Høyskolen i Oslo og Akershus. Gruppens medlemmer er Magnus Dahl Hegge, Mads Larsen, Abdi Baisa og Bjørn Bergan. Prosjektoppgaven som skal løses har gruppen valgt selv og fått godkjent av høyskolen. Oppgaven går ut på å utvikle en ny nettside med integrert nettbestillingsfunksjon for LM Dahl Ingeniørfirma AS. Hovedfokuset for prosjektet vil være nettbutikken, men vi vil vurdere verdien av å utvikle hele siden på nytt etterhvert som vi får klarlagt hva oppdragsgiver ønsker av funksjonalitet. LM Dahl Ingeniørfirma AS ble etablert i 1976 og har sin hovedvirksomhet i å importere boltsveiserapparater med tilhørende utstyr, rettet mot offshore og bygningsindustrien. Det er et forholdsvis lite firma med kun 4 ansatte, men det er et av de største firmaene i sin bransje i Norge. De leverer produkter til India, Saudi-Arabia og Skandinavia. Veileder Steinar Johannesen epost: Kontaktperson Leiv M. Dahl, Daglig leder Tlf : , epost: Nettside: Sammendrag Vi vil jobbe med å utvikle en ny nettside for LM Dahl med integrert nettbestillingsfunksjon. Hovedfokuset for prosjektet vil være nettbutikken, men vi vil vurdere verdien av å utvikle hele siden på nytt etterhvert som vi får klarlagt hva oppdragsgiver ønsker av funksjonalitet. For øyeblikket har ikke LM Dahl en nettbutikk, kun et generelt kartotek over varer på nettsiden, hvor det ikke står noe om lagerstatus o.l. Siden LM Dahl bruker Mammut som salgsverktøy vil vi forsøke å utvikle en applikasjon som kommuniserer direkte med dette fra nettsiden. Da kan kunder legge inn en bestilling som vil automatisk bli registrert i salgsverktøyet. Dette krever at vi setter oss inn i hvordan Mammut fungerer og hvilke muligheter vi har for å manipulere data i programmet. Dagens situasjon I dag er LM Dahl kun representert på internett i form av en generell informasjonsnettside. Der kan man kan lese om bedriften og få kontaktinformasjon og lignende, men ikke bestille varer eller få informasjon om nøyaktig hvilke varer som er tilgjengelig. Vareoversikten er begrenset til et generelt kartotek og det er derfor ingen informasjon om lagerstatus. Bestillinger gjøres over 10

11 telefon eller epost, da dette er den eneste måten bedriften i dag har å gjennomføre dette på. Dette er ikke en optimal måte å gjøre dette på da ansatte må ta i mot bestillinger selv, i steden for at dette skjer automatisk. LM Dahl bruker Mamut som ERP og CRS system. Her registreres alle bestillinger manuellt, innkjøp, og regnskapet. Mamut er delt inn i moduler; De modulene som brukes oftest er: Salg Salgsmodulen brukes for å registrere og vise ordre. Her registrerer man ordre, fakturerer ordre, registrerer varer som levert, samt oppfølging. 11

12 Produkt & Lager Her kan man se lagerstatus på produkter, legge til, og redigere produkter. Her registreres også varetellinger. 12

13 Mål og rammebetingelser Vårt hovedmål for prosjektet er å lage en fullt fungerende nettbutikk. Dette inkluderer å universelt utforme nettsiden for å gjøre den tilgjengelig for brukergruppen, ha et pent design og et høyt sikkerhetsnivå på alle områder. Vi vil også forsøke å gjøre det mulig for nettbutikken og kommunisere direkte med mamut for å gjøre bedriftens bestillingsystem mer effektivt enn med dagens løsning. Vi vil under hele prosjektet forsøke å utvikle systemet på en måte som fører til at det blir enkelt å drifte og ikke krever store ekstrautgifter for bedriften. Rammebetingelsene i vårt prosjekt er hovedsakelig tidsbegrensninger. Oppgaven skal leveres 30.05, og da skal alt være klart til at LM Dahl kan ta over driftingen. Vi vil også ha begrenset med penger til disposisjon, noe som fører til at vi ikke kan overstige budsjettet, men må forsøke å utvikle alt på den rimelige måten så lenge det er en god nok løsning. Gruppen har også begrenset kunnskap til mamut, noe som kan regnes som en rammebetingelse, men vi vil forsøke å lære så mye som mulig om dette programmet underveis i prosjektet for å oppnå målet om at nettbutikken skal kommunisere med mamut. Løsninger / alternativer Vi vil først besøke bedriften og analysere nøyaktig dagens situasjon for å få oversikt over problemområdene. Deretter vil vi lage en kravspesifikasjon som konkret forklarer hva vi vil gjøre. Denne vil vi vise til bedriften for å forsikre oss om at begge parter er enige. Den ideelle løsningen vil være en fullt fungerende universelt utformet nettbutikk som kommuniserer med mamut. Denne løsningen er nøyaktig hva bedriften ønsker og vil være det vi arbeider for. Vi vil bruke resultatene av analysene, HTML5, CSS og SQL for å oppnå dette. FTP vil bli brukt for å laste filer opp og ned til server. Hvordan vi skal oppnå kommunikasjon med mamut er det fortsatt usikkerhet rundt, siden gruppen ikke har erfaring med mamut. Dette vil vi forsøke å oppnå underveis i utviklingen. Den eneste alternative løsningsmodellen må brukes i tilfeller hvor vår ideelle løsning ikke kan oppnåes. Vi ser for oss at det mest sannsynlige tilfelle dette kan skje er hvis mamut integrasjon viser seg å være umulig. Vi har ingen konkret plan for hvordan vi skal håndtere dette, men vil i dette tilfelle gå tilbake til våre analyser av bedriftens systemer og forsøke å finne en annen effektiv måte å gå frem på som ikke krever at nettsiden må kommunisere automatisk med mamut.. Den generelle løsningen er ikke komplisert, siden utviklingen av en nettside går ut på å først finne ut hva som kreves, så utvikle en prototype, teste, rette feil og så implementere. 13

14 Analyse av virkninger Når det gjelder virkningen av de forskjellige løsningsalternativene vil vi forsøke å oppnå det samme målet, og virkningen vil derfor ikke være særlig merkbart på det ferdige produktet. Vanskeligheter med å kommunisere med mamut kan føre til vanskeligheter i utviklingsprosessen, og noe forsinkelser hvis det blir vanskelig å finne alternativer. Målet vil jo da være å finne alternativer som oppleves mer eller mindre på samme måte når oppgaven er ferdig. 14

15 3. Kravspesifikasjon 3.1 Systemkrav De følgende punktene er generelle systemkrav vi stiller til prosjektet. Punktene dekker essensen av hva vi mener er de viktigste kravene. Kunder må registrere seg for å få tilgang til å bruke butikken. Alle kunder må registrere seg som brukere på vegne av et firma. Firmaer må godkjennes av LM Dahl og aktiveres før firmaets brukere kan bruke butikken. Logger man inn som administrator erstattes min side med kontrollpanel som gir administrator tilgang til administratorfunksjoner. Kunder skal ikke ha tilgang til administratorkontrollpanelet Innlogging skal lagres, slik at man forblir logget inn til man logger ut. Firmaer og brukerkontoer som har gjennomført ordre skal ikke kunnne slettes fra systemet. Alt siden tar imot som input skal valideres før det lagres. All tekst som vises på siden skal hentes fra en xml fil. I xml filen skal tekststringene lagres med engelsk navn, slik at man lett kan lage versjoner av siden på andre språk en norsk ved å lage en ny xml fil og erstatte de norske tekststringene med tekststringer på andre språk. 3.2 Krav til design Hovedkravet for designet på den nye siden er å forsøke å beholde så mye av originaldesignet som mulig, med eventuelle forbedringer der det er nødvendig. Dette er fordi LM Dahls nettsider har et pent og ryddig design, og oppdragsgiver ønsket å ikke skremme bort gamle kunder ved å ha et helt ukjent design på den nye siden. I tillegg til dette skulle nettsiden reflektere bedriftens primærprosess i form av utseende og stilart. Butikken skal ha et design som er laget med tanke på universell utforming Designet skal beholde fargene fra LM Dahls gamle nettsider, blå, grå, hvit og lyseblå Ingen popupsider skal forstyrre brukere av siden Vi skal ikke bruke flash i sidens design Det skal ikke være videofiler inkludert i sidens design Designet skal være minimalistisk, men funskjonsrikt Funksjonene skal være letthåndterlige Siden skal inneholde minst mulig tekst Siden skal være designet ut i fra et F-mønster, med menyer vertikalt på venstre side og horisontalt på toppen av siden. Innhold skal vises samlet på midten av siden. Dette mønsteret er ofte brukt på moderne nettsider, og brukere vil kjenne designet igjen lett. Nettsiden skal benytte samme font på alle sider. 15

16 3.3 Krav til universell utforming Universell utforming er vanskelig å oppnå, da det involverer å lage ett produkt hvor alt kan brukes av alle brukergrupper med minst mulig variasjon. For å virkelig oppnå dette må man gjennomføre svært mange brukertester, og forarbeidet krever mye tid. Vi ser ikke for oss av vi har mulighet til å gjennomføre dette innenfor tidsrammene som er satt for prosjektet, men vi vil forsøke å utforme nettsidens funksjoner så universelt som mulig under hele utvilkingsprosessen. Krav til universell utforming vi vil forsøke å tilfredstille underveis: Farger skal være valgt med tanke på fargeblinde og svaksynte Internettsidene skal fungere godt med zoom funksjoner med tanke på svaksynte. Eventuelle bilder skal ha en relevant beskrivelse. Siden skal være enkel å navigere, og det skal kreves få tastetrykk for å navigere seg frem til det man leter etter. 3.4 Krav til koden Ved å følge disse prinsippene og retningslinjene vil vi forsøke å møte kravene for effektiv og ryddig koding. Da vil andre ha mulighet til å forstå hva som har blitt gjort. Koden skal være oversiktlig og ryddig, med relevante navn på funksjoner og filer. Alle funksjoner skal kommenteres tydelig, så man kan se hva funksjonen gjør selv om man ikke forstår selve koden. Fil- og mappestruktur skal være ryddig Relevante og oversiktlige navn på filer og mapper. 3.5 Krav til dokumentasjon Høyskolens maler for dokumentasjon skal følges, med eventuelle ekstra punkter etter behov. Hvis vi ønsker å inkludere punkter som ikke er satt opp i malen vil vi forsvare bruken av punktet. Vi skal føre dagbok over hva vi gjør underveis i prosjektet for å ha oversikt over hva som har blitt gjort, og når. Dokumentasjonen skal beskrive hvorfor vi har tatt valgene vi har gjort underveis i utviklingen. 16

17 3.6 Funksjonelle krav Administrator Administrator skal ha tilgang til administratorkontrollpanel. Fra kontrollpanelet skal administrator ha mulighet til å: Søke opp og se på, redigere, aktivere/deaktivere og slette produkter. Søke opp og se på, redigere og slette produktkategorier. Legge produkter i kategorier. Se ordrehistorikk. Slette ordre hvis ordren ikke er behandlet. Se på firmainformasjon og aktivere/deaktivere firmakontoer. Søke opp, se på, redigere og slette brukerkontoinformasjon. Deaktivere brukerkontoer hvis brukerkonto ikke kan slettes. Aktivere brukerkontoer. Opprette nye brukerkontoer, og gi disse adminrettigheter hvis det er nødvendig. Ha oversikt over varelager Kunder Med kunder menes personer som har registrert seg med et firma og en brukerkonto, og både firmaet og brukerkontoen er aktivert. Kunder skal ha tilgang til å: Se på produktinformasjon og produktkategorier. Legge til, redigere og slette leveringsadresser. Legge til, redigere og slette faktureringsadresser. Se på informasjonen som er lagret om brukerens firma og endre dette. Se hvilke andre brukerkontoer som er registrert med kundens firma. Opprette nye brukerkontoer knyttet til firmaet. Redigere brukerkonoinformasjonen Endre passord for brukerkontoen Se ordre som er registrert på brukerkontoen Endre, eller slette, ordre som er registrert på brukerkontoen hvis ordren ikke er behandlet av LM Dahl. Legge produkter i handlekurv. Fjerne produkter fra handlekurv. Gjennomføre bestillinger. Logge inn som kunde. Logge ut. 17

18 3.6.3 Uregistrerte kunder (gjester) LM Dahl krever at man må opprette en brukerkonto og få denne godkjent før man får lov til å se detaljert produktinformasjon, lagerbeholding og pris. Dette betyr at uregistrerte personer kun får tilgang til å: Se hovedsiden. Se en produktside med begrenset informasjon. Se kontaktsiden. Registrere seg som kunde Produkter Fordi LM Dahl selger hundrevis av produkter, og disse allerede er registrert i Mamuts database, vil nettsidens database importere produktene derfra. Dette fører til at nettsidens database må utformes med tanke på hvordan produktinformasjonen er lagret i Mamut. Alle produkter i produkttabellen skal ha en unik ID. Alle produkter skal ha en pris. Produkter skal ha informasjon om lagerantall Et produkt skal ha en overkategoriid. Et produkt skal ha en kategoriid. Et produkt skal ha en underkategoriid Kategorier I Mamut er produkter lagret i kategorier. I databasen skal: Hver overkategori ha en unik id. Hver kategori ha en unik id. Hver kategori inneholde ID til overkategorien kategorien tilhører. Hver underkategori ha en unik ID. Hver underkategori skal inneholde ID til kategorien underkategorien tilhører Handlevogn Handlevognen skal være tilgjengelig for innloggede kunder, og skal være synlig, eller linket til, på alle sidene i nettbutikken. Produkter som legges i handlekurv skal lagres i session. Handlekurven skal opprettes når et produkt legges i handlekurv. Kun den brukeren som er logget inn skal ha tilgang til å se innholdet i sin handlekurv. 18

19 3.6.7 Ordre Ordredetaljer skal lagres i ordretabellen i databasen Ordre skal være satt som åpen og dermed være tilgjengelig for endring og sletting frem til LM Dahl behandler ordren. Når ordren er behandlet skal den være utilgjengelig for endring og sletting Kontakt Kontaktinformasjonen fra LM Dahls gamle nettsider skal inkluderes i LM Dahls nye nettsider. Det inneholder da: Et skjema for å sende epost direkte til LM Dahl Kartoversikt over hvor LM Dahl holder til Kontaktinformasjon med åpningstider 19

20 3.7 Use case I denne delen av rapporten vil du finne Use Case diagram for main success scenario og tekstlige beskrivelser for dette Diagram 20

21 3.7.2 Beskrivelser Use case: Logg inn Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Logge inn Gjest Gjest vil logge seg inn Gjest må være registrert som kunde firmakonto må være aktivert av admin Gjest får logget inn Gjest får ikke logget inn 1. Gjest taster nettadressen 2. Gjest trykker logg inn 3. Gjest fyller inn brukernavn og passord 4. System sjekker brukernavn og passord 5. Gjest blir logget inn og blir kunde 3.a Skriver feil brukernavn eller passord 4.a Brukernavn finnes ikke 4.b System ber gjest prøve igjen Brukernavn og passord må være skrevet riktig Gjest må være registrert kunde og firmaet må være aktivert 21

22 Use case: Se produkter uten pris Use case Se produkter uten pris Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Gjest Gjest vil se produkter via hjemmesiden Gjest ser produkter Har tilgang til internett Får sett produkter Får ikke sett produkter 1. Gjest taster nettadressen 2. Systemet sjekker om nettadressen eksisterer 3. Nettsiden blir åpnet 4. Brukeren velger kategori av produkt han ønsker å 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 om å prøve igjen senere. - Nettadressen må være riktig skrevet. 22

23 Use case: Førstegangs registrering Use case Førstegangs registrering Aktør: Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Gjest Gjest vil bli kunde Gjest blir kunde Gjest får registrert seg Gjest får ikke registrert seg 1. Gjest taster inn nettadressen 2. Gjest velger registrere seg 3. Gjest fyller ut firma og brukerpersonalia i skjema 4. Skjema sendes til Admin 5. Admin bekrefter registreringen. 3. Personalia blir fylt ut feil 3.a: Bruker retter feil i skjema 5. Admin bekrefter ikke registreringen Nettadressen må være skrevet rett Skjema må fylles ut korrekt. 23

24 Use case: Bestille produkter Use case Bestille produkter Aktør: Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Kunde Kunde vil bestille et produkt Kunde må være registrert Kunde må være innlogget Firmakonto må være aktivert Kunde får ordrebekreftelse Kunde får mail Kunde får leveringsbekreftelse Kunde får ikke bestillt 1. Kunde logger inn via nettsiden 2. Kunde velger varer 3. System sjekker om varen er på lager 4. Kunde bekrefter handlekurven 5. Kunde velger fakturaadresse 6. Kunde velger leveringsadresse 7. Admin mottar ordre 9. System sender ordrebekreftelse på mail 10. System sender leveringsbekreftelse 3.a Produkt finnes ikke på lager 3.b Varen må bestilles 3.c Produkt er utgått 5.a Feil info fylles inn, ber kunde fylle inn korrekt info 6.a Feil info fylles inn, ber kunde fylle inn korrekt info Kunden må være registrert Kundefirma må være godkjent av admin Kunden må være logget inn Kunde velger selv antall varer 24

25 Use case: Endre personinfo Use case Endre personinfo Aktør: Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Kunde, Admin Kunde vil endre personinfo Kunde må være registrert Kunde må være innlogget Kundekonto må være aktivert Kunde får bekreftelse på at info er endret Kunde får endret personinfo Kunde får ikke endret info 1. Kunde/Admin logger inn via nettsiden 2. System sjekker brukernavn og passord 3. Kunde/Admin endrer personinfo 4. Kunde/Admin lagrer endringer 5. Kunde/Admin får bekreftelse på endringene 1.a Brukernavnet finnes ikke 3.a Feil med database lagring 4.a Kunde får ikke lagret info pga feil i henhold til krav Kunden må være registrert Kunden må være godkjent av admin Kunden må være logget inn Admin må være logget inn 25

26 Use case: Se ordrehistorikk Use case Se ordrehistorikk Aktør: Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Kunde, Admin Kunde eller admin vil se ordehistorikk Kunde må være registrert Kunde må være innlogget Kunde konto må være aktivert Kunde må ha bestillt minst 1 gang Admin må være innlogget Kunde, Admin fikk sett ordrehistorikk Kunde, Admin fikk ikke sett ordrehistorikk 1. Kunde, Admin logger inn via nettsiden 2. System sjekker brukernavn/passord 3. Kunde, Admin velger å se ordrehistorikk 4. Kunde, Admin får returnert ordrehistorikk fra databasen 1.a Brukernavn eksisterer ikke 1.b Passord er feil 3.a Kunde har ikke bestillt noen varer Kunden må være registrert Kunden må være godkjent av admin Kunden må være logget inn Kunden må ha bestillt minst 1 vare 26

27 Use case: Redigere produkter Use case Redigere produkter Aktør Trigger Pre-Betingelser Post-Betingelser Normal Hendelsesflyt Variasjoner Relatert informasjon Admin Admin vil endre produktinfo Admin redigerer produkt Admin må være logget inn Admin får endret produktinfo Admin får ikke endret produktinfo 1. Admin logger inn 2. Admin velger produkt som skal oppdateres/endres 3. Admin utfører operasjoner 4. Admin lagrer endringen 5. Endring blir lagret i database 6. Systemet gir bedskjed om at endringene er lagret 1.a Admin får ikke logget inn 3.a Admin får ikke endret produktet 3.b Systemet ber admin prøve igjen senere 4.a Admin får ikke lagret endringene 4.b Systemet ber admin prøve igjen senere 5. Systemet gir ingen tilbakemelding på at endringene er gjort Admin må være innlogget 27

28 Use case: Redigere brukere Use case Redigere brukere Aktør Trigger Pre-Betingelser Post-Betingelser Normal Hendelsesflyt Variasjoner Relatert informasjon Admin Admin vil redigere brukere Admin redigerer brukere Admin får redigert bruker Admin får ikke redigert bruker 1. Admin logger inn 1. Admin velger rediger bruker 2. Admin utfører operasjon. 3. Systemet gir tilbakemelding om at endringen er utført 1. Admin finner ikke bruker som skal redigeres 3. Systemet gir ikke tilbakemelding om at endring er utført 3.a Systemet ber Admin prøve igjen. Admin må være logget inn 28

29 Use case: Redigere ordre Use case Redigere ordre Aktør Trigger Pre-Betingelser Post-Betingelser Normal Hendelsesflyt Variasjoner Relatert informasjon: Admin, Kunde Kunde forespør endring av ordre Admin redigerer ordre Admin får redigert ordre Admin får ikke redigert ordre 1. Kunde tar kontakt angående endring av ordre. 2. Admin velger ordre som skal redigeres. 3. Admin foretar endring. 4. Admin informerer kunde om endring. 3. Admin får ikke endret ordre da den allerede er sendt. 3.a Kunde sender ordre i retur og bestiller på nytt Kunde må ha bestilt noe Admin må være logget inn. 29

30 4. Prosessdokumentasjon 4.1. Planlegging og metode I denne delen av rapporten vil vi beskrive hvordan vi gikk frem for å planlegge prosjektet, valg vi tok før vi startet med arbeidet, hvilke metoder vi brukte, utfordringer vi møtte på underveis og rammene vi arbeidet innenfor Hvordan angripe oppgaven Gruppen har mye erfaring med samarbeid, da vi har jobbet sammen over flere år. Det første vi måtte sette oss inn i var prosjektets omfang og hvor mange arbeidstimer som måtte føres. Vi forsto fort at dette kom til å bli en særdeles tung oppgave, og at det ville kreve en mer strukturert fremgangsmåte enn vi har operert med tidligere. Vi vurderte de forskjellige aspektene av prosjektet individuelt og kom frem til at det ville være nødvendig å delegere ansvar ut til det gruppemedlemmet som har mest kunnskap om ett gitt område. På denne måten vil ett gruppemedlem ha hovedansvaret for et spesifikt område, men vil kunne innvolvere andre medlemmer for å få en jobb gjort. Selv om dette gruppemedlemmet har hovedansvaret, skal alle gruppemedlemmene til en hver tid ha oversikt over hva som blir gjort, slik at hvis hovedmedlemmet ikke har mulighet til å jobbe, så kan et annet medlem ta over. Etter at vi opprettet styringsdokumentene måtte vi oppdatere kunnskapen vår om de aktuelle programmeringspråkene. Vi så på gamle innleveringer og eksamener for å pusse opp hukommelsen, og begynte å forestille oss hvilke utfordringer som vi kunne møte på Metode Under planleggingsfasen benyttet vi oss av fossefallsmodellen 4. Dette gjorde vi for å følge kravene satt av HiOA. Da arbeidet kom i gang, gikk vi bort ifra denne modellen for mer passende metoder. Vi så på flere alternativer innenfor agile systemutviklingsmetoder og kom frem til at SCRUM 5 ville være best egnet for oss i kombinasjon med extreme Programming (XP 6 ). SCRUM følger enigheten vi kom til tidlig om at vi skal delegere oppgaver til enkeltpersoner i gruppen, da det kort forklaret går ut på å håndtere én oppgave om gangen. XP ble tatt i bruk ved særdeles krevende problemstillinger, slik at vi kunne overkomme vanskeligheter uten å videre påvirke tidstabellen. Aspektet ved XP som vi tok i bruk var det enkle prinsippet om å 4 I Fossefallsmodellen gjennomføres prosjektet i distinkte faser, hvor resultatet av en fase er grunnlag for arbeidet i neste fase. I tillegg er det grunnlag for å ta beslutninger om prosjektets videre fremdrift. 5 SCRUM er et rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer 6 extreme Programming (XP) er en systemutviklingsmetode som er utformet for å være så fleksibel som mulig 30

31 være villig til å forkaste ideer. Dersom vi sto fast, ville gruppen bruke tid på å finne en løsning, samtidig som vi var villige til å forkaste ideen, og komme med en helt ny fremgangsmåte som unngår problemet helt. Vi hadde ikke behov for en møteplan da vi til en hver tid jobbet side om side. Om det var spørsmål, eller problemer, var gruppen tilgjengelig for å håndtere saken. Vi sto også i den unike situasjonen at ett av gruppemedlemmene våre er ansatt i LM Dahl. Vanligvis ville gruppen ha holdt kontakt med oppdragsgiver igjennom et bindeledd som representerer bedriftens interesser. Dette bindeleddet ble ikke nødvendig da det ansatte medlemmet hadde blitt gitt ansvaret for nettsidens utvikling av LM Dahl, og hadde fått tilnærmet carte blanche i henhold til designvalg og funksjonalitet. Dette gjorde at det sjeldent, om ikke aldri, var nødvendig med møter imellom gruppen og arbeidsgiver. Hvis LM Dahl hadde spesifikke ønsker, ble dette tatt med medlemmet og tatt videre til resten av gruppen. Siden medlemmet opererer med LM Dahls interesser, kunne han ta avgjørelser raskt, uten å ta kontakt med oppdragsgiver Fremdriftsplan Fremdriftsplanen ble utviklet tidlig i prosjektet, og tar for seg i grove trekk hvilke tanker vi satt oss for prosjektets gang. Planen viser hvor mye tid som blir disponert til de forskjellige fasene og målene. Vi ville forsøke å følge denne planen så lenge det lot seg gjøre, men da vi ikke hadde fått helt grep om hvordan det endelige resultatet ville bli, så vi oss nødt til å kunne endre denne planen etter behov. Vedlegg 1: Fremdriftsplan Vi satt opp en arbeidsplan som gir en oversikt over de individuelle målene for prosjektet. Her skrev vi opp nøyaktige tidsfrister for hvert enkelt mål i prosjektet med en beskrivelse. Vedlegg 2: Arbeidsplan Arbeidsmetodikk Før vi satt i gang med selve arbeidet, måtte vi komme frem til en løsning for hvordan vi ville jobbe. Etter å ha diskutert forskjellige løsninger, bestemte vi oss for å jobbe side om side til en hver tid. Håpet var at dette ville gjøre jobben enklere å komme igjennom, da det å kunne få kontinuerlig input fra andre medlemmer under arbeidet vil føre til mindre uenigheter underveis, og at vi brukte mindre tid på segmenter med kode som ikke kom til å bli tatt i bruk. Vi så på forskjellige type verktøy for å best gjennomføre oppgaven. Vi trengte ett sett med verktøy for dokumenthåndtering, og ett for koding. Det viste seg at det var vanskeligere å finne frem til den beste løsningen enn vi først hadde trodd. Dokumenthåndteringsverktøy definerer vi som programmer, eller kontorpakker, vi tar i bruk for å utforme de forskjellige styringsdokumentene i prosjektet. Rapporten, og dens underseksjoner, utformes ved hjelp av Google Docs(GD 7 ), som nå har byttet navn til Google Drive. Vi har mye erfaring med bruk av GD i prosjektsammenheng, og har utformet brorparten 7 Google Docs, eller Google Dokumenter som det kalles på norsk, er en gratis webbasert kontorpakke som inneholder programmer som tekstbehandling, regneark og presentasjoner. 31

32 av våre oppgaver ved hjelp av dette verktøyet. GD gir oss muligheten til at flere personer kan redigere i ett dokument i sanntid. I tillegg til denne funksjonaliteten kan man finne tilbake til eldre versjoner av dokumentet ved hjelp av historieloggen. Tidlig i utviklingen benyttet vi oss av Dropbox 8 for å dele filer gruppen imellom, men da google endret Google Docs til Google Drive, gikk vi over til å bruke Google Drive. For å lage UML delen av prosjektet benyttet vi oss av Microsoft Visio (Visio 9 ). Ved hjelp av programmets grafiske muligheter ble Use Case modellen utformet. De tekslige use casene ble utformet i GD. Ved å benytte oss av Microsoft Project(MP 10 ) ble fremdrifsplanen skrevet som et Ganttskjema 11. Ved å bruke Google Sites(GS 12 ) kunne vi generere en hjemmeside for gruppen. Her vil all informasjon om gruppen, styringsdokumenter og kode bli lagt ut i tillegg til dagbok. Ved prosjektetsstart brukte alle forskjellige programmer for koding. Gruppemedlemmene hadde utviklet et forhold til disse programmene, og alle hadde meninger om hvorfor akkurat deres program var bedre egnet for oppgaven. Vi kom til en enighet om å bruke Notepad++ for å kode. Dette skapte problemer i forhold til å jobbe opp imot en FTP, da det var stor fare for overskrivning av andres arbeid, og man måtte hele tiden hente inn ny kode manuelt. Vi begynte å lete etter en bedre løsning da vi hadde opprettet de nødvendige styringsdokumentene. Det var en enighet om at vi ville ha en GD lignende løsning, slik at flere medlemmer kan kode i den samme filen uten frykt for å overskrive andres innhold. Det neste alternativet vi så på var Eclipse 13. Eclipse har muligheter for plugins som gir GD lignende verktøy, i vårt tilfellet brukte vi Saros 14. Vi hadde store problemer med Saros fordi vi måtte koble oss opp mot en ekstern chat-server for å kunne redigere i et dokument samtidig. Dette skapte store problemer, da chat-serveren vi brukte, google chat, koblet seg til flere ganger i sekundet per session, og gjorde at all RAM på datamaskinene ble brukt for å håndtere situasjonen. Vi fant senere ut at google chat ikke var egnet for denne typen arbeid, og at vi burde ha brukt en annen chat server. Etter at Eclipse feilet, ble Netbeans 15 utprøvd. Det som gjorde NetBeans attraktivt for oss var muligheten til å benytte oss av Git 16. Dette gav oss tilgang på konflikthåndtering ved sammensmelting av kode flere har jobbet med. Vi fant ingen problemer med NetBeans, og ble 8 Dropbox er en fildelingstjeneste som tilbyr skylagring, filsynkronisering og tjener programvare. 9 Microsoft Visio er et kommersielt program for Windows som bruker vektorgrafikk for å skape diagrammer. 10 Microsoft projet er et prosjektstyringsprogram designet for å hjelpe prosjektledere å utvikle en slagplan. 11 Gant-skjema er en type søylediagram som illustrerer et prosjekts tidsplan ved å vise start og sluttpunkt for enkeltoppgaver i prosjektet. 12 Google Sites er et wiki- og websideoppretningsverktøy. Det er designet etter samme prinsipp som Google docs. En enkel kit for å lage en webside hvor flere medlemmer i en gruppe kan samarbeide om filer. 13 Eclipse er et rammeverk hovedsakelig ment for å lage utviklingsmiljøer for programvare 14 Saros er en Eclipse plug-in for samarbeidsredigering av filer. Det kan bli brukt som en enkel kodeleser til et samarbeidsverktøy for redigering av kode. 15 NetBeans er et IDE (integrated development environment) 16 Git er et versjonskontrollsystem. Det kjennetegnes ved å være distrubert og ikke mappehierarki-basert. 32

33 enige om at dette var den beste løsningen. For å opprette databasen ble den nødvendige strukturen generert i MySQL Workbench 17 og implementert igjennom phpmyadmin 18. Vi valgte denne løsningen for å lett kunne gjøre endringer i databasen, da workbench gir oss et visuelt inntrykk av databasen og genererer de nødvendige sqlsetningene fra denne visuelle representasjonen. Deretter blir disse setningene eksportert til phpmyadmin, som oppretter databasen, hvor vi kan administrere og endre på databasen etter behov Risikoanalyse Tabellen viser en generell risikoanalyse for prosjektet. Den inneholder en beskrivelse av risiki, sannnsynlighetsgrad for hver enkelt, konsekvensene de får og en foreslått løsning. Målet med en risikoplan som denne er å sørge for at gruppen er godt forbredt hvis problemer oppstår. Vi har inkludert vår beregning av sannsynlighet for hver av tabellens risiki, hvor 1 er lav sannsynlighet og 10 er meget høy sannsynlighet. Vedlegg 3: Risikoanalyse Utvikling av kravspesifikasjon Kravspesifikasjonen ble utviklet etter samtale mellom oppdragsgiver og gruppen. Vi kom frem til de kravene vi mente var mest relevant for prosjektet, og oppdragsgiver kom med innspill om hva de ønsket ut av den nye nettsiden. Ved uenigheter satt vi oppdragsgiver ønsker over våre egne, men ved praktiske problemer måtte vi megle frem en løsning som tilfredsstilte våre, og oppdragsgivers, krav. Spesifikasjonen er et eget punkt i denne rapporten Prosjektets hjemmeside og dagbok Vi opprettet en hjemmeside for prosjektet på LM Dahl sine servere ved hjelp av Google sites i planleggingsfasen. Ved hjelp av dette enkle verktøyet kunne vi oppdatere og endre hjemmesiden. Alle styringsdokumenter og dagboksoppdateringer ble lastet opp hit. Ved prosjektetstart ble vi enige om at dagboken burde bli oppdatert med to til tre dagers mellomrom. Dagboken inneholder informasjon om oppnådde mål og problemer underveis. 17 Workbench er et visuelt databasedesignsverktøy som integrerer sql-utvikling og administrasjon, databasedesign, utvikling og vedlikehold i ett IDE. 18 phpmyadmin er et web-basert administrasjonsverktøy for MySQL-databaser, skrevet i PHP og utgitt som åpen kildekode. 33

34 4.2. Utvikling I denne delen av rapporten finner du informasjon om prosjektforeløpet etter planleggingsfasen og valg som ble tatt underveis Samarbeid under utvikling Som nevnt tidligere bestemte vi oss for å jobbe side om side til en hver tid. Vi opprettet en felles kalender i google calendar hvor vi alle førte opp de dagene vi kunne være på skolen, arrangementer vi hadde på kveldene og hvilke helger vi ikke var tilgjengelige. Når det var mulig for alle, møttes vi på skolen. I begynnelsen fikk vi ikke utrettet så mye som vi ønsket. Dette var på grunn av forskjellige ambisjonsnivå innad i gruppen, og det tok lengre tid før hele gruppen sto sammen om hva vi ville oppnå. Selv om oppmøtet var bra, ble ikke mye utrettet på daglig basis. Dette førte til at gruppemedlemmene som startet tidlig med arbeidet satt seg inn i de mest kompliserte, og for oss ukjente, aspektene ved prosjektet. Da databasen skulle designes begynte samarbeidet å komme i gang. Ingen på gruppen var spesielt gode til å designe databaser, så vi trengte input og hjelp fra alle medlemmene for å opprette de nødvendige tabellene. Mengde arbeid utført per dag begynte å øke helt frem til påsken nærmet seg. I ukene før påske ble ett av gruppemedlemmene utilgjengelig grunnet sykdom. Det tok lengre tid før gruppen ble fulltallige igjen, da ett annet gruppemedlemmene måtte dra hjem i ferien. Etter påske satt gruppen seg ned igjen og prøvde å få oversikt over det helhetlige bilde av prosjektet. Mye hadde blitt gjort, men det var fortsatt en lang vei igjen å gå. Medlemmene ble mer fokuserte på oppgaven og jobbet strukturert og effektivt. Medlemmene kjenner hverandre godt og selv om det ikke virker som om samarbeidet er optimalt, vet vi hvordan vi skal jobbe opp imot hverandres styrker og svakheter. Den siste måneden av prosjektet har samarbeidet vært utmerket, og flyten har vært bra. Vi har aldri vært i tvil om at vi vil kunne levere et godt produkt, og vi har dyttet hverandre i riktig retning når det har vært nødvendig. 34

35 Valg av database og nettsidestruktur Vi så på typen data som skulle lagres og innså at en relasjonsdatabase var det eneste realistiske alternativet. Etterhvert som vi kom kom lengre inn i arbeidsprossesen, måtte vi gjøre mange små endringer, og noen vesentlige endringer, i databasens struktur. Databasen ble redesignet to ganger. Først fordi den inneholdt feil relatert til produktbeskrivelser, så vi måtte opprette en egen tabell for beskrivelsene, og en tabell mellom Produktabellen og Beskrivelsestabellen. Det andre tilfellet hvor vi kom frem til at databasen måtte redesignes var da vi oppdaget at nettsidens menysystem krevde en annerledes struktur på produktenes kategorier. Kategorier ble da splittet opp i tre tabeller. Vi har under hele utviklingen hatt et ønske om at nettsiden skulle være en kombinasjon av nettbutikk og produktkatalog. Derfor måtte siden struktureres med produktsidene i fokus. Vedlegg 4: Databaseiterasjoner Designvalg LM Dahl har stilt klare krav til hvordan de ønsker at deres nettside skal se ut. Disse kravene har vi overholdt, og har i tillegg forsøkt å forbedre originaldesignet der det er mulig. Da det er en nettbutikk vi skal utvikle, har vi sett på eksisterende nettbutikker for å komme frem til hvilke elementer som går igjen, hvilke av de som fungerer, og hvilke vi bør vike unna. Det var et ønske fra arbeidsgiver om at vi skulle beholde det originale fargetemaet der det var mulig, og ikke foreta vesentlige strukturelle endringer som gjør siden utkjent for gamle kunder. LM Dahl hadde en vision om at siden skulle beholde et formelt, men industrielt, design som er lettnavigert for både kunder og administratorer. Vi vil oppnå dette ved å holde siden simplistisk. Dette medfører at det ikke vil bli tatt i bruk flash, video, eller andre type animasjoner som kan forstyrre brukeren. Menyene skal være interaktive, med gode hint og hjelpemidler, slik at en bruker alltid vet hva en knapp vil gjøre. I stil med LM Dahls ønsker vil siden være zoomvennlig, da demografien de jobber imot har varierende alder fra ung til eldre. Vi ønsket også å ha lave maskinkrav til siden, da det kan brukes eldre datamaskiner som ikke håndterer uforsvarlige mengder med grafikk. Siden skal kunne operere i alle nettlesere. Ved eventuelle tilfeller hvor sidens kode ikke kan leses riktig, skal alternative løsninger implementeres. Eksempelvis skal den innebygde phpfunksjonen striptags benyttes for å fjerne HTML i eposter hvor mottaker kun har mulighet til å vise epost i plaintext. 35

36 DNR (Do Not Resuscitate) Vi oppdaget tidlig at det var viktig å være villig til å forkaste ideer. Det å vite når en idé av forskjellige årsaker var ugjennomførbar, eller tenkt ut feil, kunne spare oss for mye tid. Eksempelvis redesignet vi databasen ved flere anledninger. I førsteutkastet av databasen opprettet vi de nødvendige tabellene utifra informasjonen vi hadde om systemet. Senere oppdaget vi at relasjonene ble feil da vi var avhengige av å kunne hente ut informasjon fra flere tabeller for å legge inn produktbeskrivelser. Halvveis igjennom prosjektet oppdaget vi at Mamut hadde en spesifikk måte å sende informasjon til databasen på, og dette krevde at vi satt opp databasen på nytt. Ved alle disse anledningene forkastet vi det gamle uten større disputer innad i gruppen. Det var aldri et tilfelle hvor et gruppemedlem nektet å forkaste en idè, noe som gjorde at vi sjeldent satt oss fast i feil spor over lengre tid Point of no return Selv om vi alltid var klare til å forkaste ideer, var det viktig for oss å sette et punkt for når det ikke lengre kunne gjøres større endringer i koden. Dette ble gjort for å forsikre oss om at vi kunne ferdigstille de viktigste segmentene av koden, og tilstrekkelig tilfredsstille oppdragsgivers ønsker. Vi fortsatte å kode forbi dette tidspunktet, men Point of no return ble satt til Testing Det ble planlagt to former for testing av produktet som skulle foregå under utviklingen. Den første formen for testing, interntesting, gikk ut på testing av nettsidens funksjonalitet under konstruksjon. Hver gang en funksjon ble utviklet skulle den testes, noe som er naturlig når man arbeider med kode. I tillegg skulle alle funksjoner bli grundig testet for å undersøke om de fungerte som de skulle når de var ferdige. Den andre formen for testing som ble planlagt var eksterntesting. Dette skulle foregå i prosjektets siste fase, da sidens funksjonalitet ble ferdig og sett på som klar til lansering. Da det i siste fase av prosjektet ble lagt vekt på å utvikle et så ferdig produkt som mulig, kom vi til en enighet med oppdragsgiver om at denne formen for testingen kunne ventes med. LM Dahl mente at et produkt som var så nær ferdig som mulig, med gode muligheter for videreutvikling, var et bedre alternativ enn et produkt som hadde større begrensninger, men hadde gjennomført omfattende brukertesting. Ekstern brukertesting ble notert som ett av punktene gruppen anbefaler for videreutviklingen av nettsiden. Da det ble avgjort at det ikke skulle gjennomføres noen organisert form for eksterntesting i stor skala, valgte vi å gjennomføre den med mindre paneler underveis i prosjektets siste fase. Dette foregikk ved å få venner og bekjente til å teste nettsiden og skrive ned lister over eventuelle problemer de møtte på. På denne måten fikk vi testdata som vi kunne bruke til å forbedre nettsiden, til tross for mindre bruk av eksterntesting i sluttfasen. 36

37 Utfordringer Underveis har vi møtt på en mengde utfordringer. Den første, og kanskje den mest vesentlige, har vært å tilegne seg den nødvendige kunnskapen som skulle til for å gjennomføre prosjektet. I utgangspunktet hadde ingen av medlemmene mer erfaring med språkene vi skulle programmere med, verktøyene vi skulle ta i bruk, med unntak av Google Docs, og heller ikke håndtering av et prosjekt på denne størrelsen enn vi hadde fått igjennom utdanningen. Vi innså at det vi har lært ville hovedsaklig bli brukt som et fundament å bygge på. Det ble en svært vanskelig prosess å sette seg inn i de forskjellige delene av prosjektet, da vi bevisst valgte å utføre det på en fremmed måte. Tanken bak dette var å gi oss nye erfaringer innenfor webutvikling, som kunne komme til nytte i arbeidslivet senere, selv om vi forsto at læringskurven kom til å bli meget bratt og, til tider, på grensen til uhåndterlig. Det som fremsto som mest problematisk og utfordrende var Mamut-integrasjonen mot nettsiden. For at LM Dahl skulle kunne bruke nettsiden effektivt måtte denne modulen bli utviklet. Måten Mamut var konfigurert på gav oss en indikasjon på at dette krevde et kunnskapsnivå som var mye høyere enn vi hadde forutsett. Vi klarte rett og slett ikke å skrive den nødvendige koden for å få Mamut sin database til å kommunisere med vår database. Vi brukte en del tid på dette før vi fant ut at det ble for komplisert. Etter en samtale med oppdragsgiver ble vi enige om å undersøke om det fantes en ferdig modul for dette hos Mamut. Det viste seg at løsningen Mamut kunne tilby var alt for kostbar, da den involverte å kjøpe hele kildekoden til programmet. Mamut fortalte oss at denne løsningen var ment for bedrifter som jobbet med utvikling av flere typer moduler til Mamut for videresalg, og foreslo at vi tok kontakt med en av disse bedriftene. Vi kontaktet tredjepartsleverandører av moduler og kom frem til en løsning som tilfredstilte oppdragsgiver og gruppen. 4.3 Konklusjon Prosjektforeløpet har gitt oss en mengde erfaring innenfor flere emner. Når vi ser på hva vi har fått utrettet, og hva vi ønsket å oppnå, ser vi oss fornøyde med det endelige resultatet. Ved å utnytte nye ressurser som GiT og avanserte NetBeans funksjoner har vi fått en bedre forståelse for hvordan et prosjekt av denne størrelsen skal håndteres og dokumenteres. Særskilte områder i prosessen som vi kunne ha håndtert bedre er planleggingen. Når vi ser tilbake på startfasen, kommer det klart frem at vi ikke hadde like god oversikt som vi trodde. Dette forårsaket at problemer dukket opp senere som kunne ha vært unngått ved en bedre utviklet kravspesifikasjon. Vi kunne også ha satt opp en mer strukturert plan for samarbeidet for å unngå lengre perioder uten relevant fremgang. Utfra tidligere erfaringer kunne vi ikke se et behov for en formell samarbeidsavtale, men når vi ser tilbake på dette prosjektet forstår vi hvorfor det kunne ha vært lurt. En samarbeidsavtale krever at vi garanterer våre tjenester til gruppen og prosjektet, at vi utfører de oppgavene vi blir tildelt og at vi står til disposisjon for gruppen med mindre ekstraordinære omstendigheter inntreffer. Hvis vi hadde hatt en samarbeidsavtale som vi alle respekterte, ville vi kunnet unngå perioder med lite fremgang. Selv om samarbeidet ikke alltid har vært optimalt, har vi allikevel prøvd å møte hverandres krav, men med varierende grader av suksess. 37

38 5. Produktdokumenetasjon 5.1 Forord Denne produktdokumentasjonen er primært ment for de som skal vedlikeholde, videreutvikle, drifte og modifisere nettsiden. Hensikten med denne rapporten er å gi en detaljert oversikt over nettsiden vi har laget. Innholdet vil til tider være svært teknisk og vil kreve god forståelse av php, sql, html, css og objektorientert programmering. Sammen med kravspesifikasjon og prosessdokumentasjon vil denne rapporten gi en beskrivelse av prosjektet vi har gjennomført Teknologier Rammebetingelser LM Dahl hadde ingen krav til hva slags teknologi som kunne bli brukt av nettbutikken. De eneste rammebetingelsene som gjaldt for bruk av teknologi i dette prosjektet var derfor de rammebetingelsene gruppen selv ønsket. Dette åpnet for muligheten til å bruke de teknologiene gruppen selv var mest komfortable med Språk En rekke språk har blitt benyttet under utviklingsprosessen, men hovedfokus har vært på PHP, da det har blitt brukt til å lage nettsidens funksjonalitet. PHP ble valgt fordi det var språket som passet best til å løse oppgaven. HTML ble brukt for å vise sidens innhold i form av skjema, men i tilfeller hvor vi ønsket mer dynamisk interaksjon på nettsidene brukte vi jquery. Dette var fordi jquery er en mer effektiv måte å oppnå det man har behov for enn javascript. Eksempel på bruk av HTML i kombinasjon med jquery er Logg inn -knappen. Her åpner menyen seg og legger seg under Logg-inn -knappen, for å så forsvinne igjen hvis man trykker et annet sted på siden. JQuery ble også brukt for å lage mer interaktive menyer på de fleste av nettbutikkens sider. Det ble tidlig i prosjektet tatt en avgjørelse om at vi skulle sette oss inn i, og bruke, HTML5. Mange aspekter av HTML har blitt forbedret i HTML5, og gjorde deler av utviklingen enklere, som igjen resulterte i en bedre nettside. Det oppsto problemer da HTML5 var såpass nytt, og noen nettlesere, særlig Internet Explorer, slet med å tolke deler av koden. Et eksempel på dette er HTML5 sin placeholder funksjon, som ikke fungerte i Internet explorer, og vi måtte derfor ta i bruk jquery for å få et godt resultat. For å gi nettsiden et pent utseende brukte vi CSS3. Dette var det eneste realistiske alternativet for å oppnå et profesjonelt utseende, da det ikke finnes noen andre språk som oppnår samme resultat. I likhet med HTML5 var CSS3 nytt da prosjektet ble gjennomført, og ikke alle funksjoner var støttet av alle nettlesere. Vi valgte derfor å bruke en kombinasjon av CSS 2.1 og CSS3. Et eksempel på dette er utseende på knappene til siden, som Internet explorer ikke kunne håndtere med CSS3 styling. For å sammenligne stringverdier i valideringsprosessen har vi brukt Regex til å 38

39 undersøke om tekst inneholder tegn vi ønsker, eller ikke ønsker, å lagre. og har vært til stor hjelp med dette Beskrivelse av teknologi PHP PHP (forkortelse for Hypertext Preprocessor) er et scriptspråk med åpen kildekode som er spesielt egnet for webutvikling og kan bygges inn i HTML. PHP skiller seg fra f.eks javascript ved at koden kjøres på serveren. Dette betyr at klienten vil motta resultatet av koden uten at den noen gang ser php kildekoden. PHP er kjent for å være svært lett å komme i gang med, men tilbyr også avansert funksjoner for mer profesjonelle programmerere. HTML HTML(forkortelse for HyperText Markup Language) er et markeringsspråk (markup language) som brukes til å strukturere informasjon som skal vises på en nettside. HTML er bygget opp av tags, som nettlesere tolker og bruker til å forstå hvordan en nettside skal se ut og inneholde. CSS CSS (forkotrelse for Cascading Style Sheets) er et språk som brukes til å definere utseende på filer skrevet i HTML og XML. Dette inkluderer farger, fonter, posisjonering og lignende. CSS kan skilles ut i en egen fil eller integreres i selve dokumentet. REGEX Regex (forkortelse for Regular Expression) er et språk som brukes for å sette dynamiske regler for sammenligning av strenger. Dette brukes for å undersøke om strenger innehoder det man ønsker at den skal inneholde, eller ikke inneholder det man ikke ønsker at den skal inneholde. jquery jquery er et JavaScript-bibliotek utviklet for å forenkle klientscriptingen av HTML. jquery brukes fordi man kan oppnå samme resultat som med javascript men med mindre, og mer effektiv kode. 39

40 Netbeans Netbeans er et gratis IDE (Integrated Development Environment) med åpen kildekode. Netbeans inneholder alle verktøyene man trenger for å utvikle med Java, C/C++, PHP, Javascript og Groovy. At Netbeans er IDE betyr at programmet er mer prosjektorientert, så man får en sammenheng mellom filer, i motsetning til en editor som kun ser på en fil av gangen. Git Git er et versjonskontrollsystem påbegynt av linus Torvalds. Git er nyttig i tilfeller hvor flere personer skal redigere de samme filene, da man kan lagre lokalt, men pushe og pulle når man ønsker det, og dermed flette sammen endringene som har blitt gjort. Fig illustrasjon av Gits funksjonalitet i vårt prosjekt. PhpMyAdmin PhpMyAdmin er et webbasert administrasjonsverktøy for MySQL databaser skrevet i PHP. PHPMyAdmin har åpen kildekode. MySQL Workbench MySQL Workbench er et visuelt verktøy for databaseutvikling. Worbench tilbyr muligheten til å tegne opp databaser og relasjoner og genrerer kode ut i fra dette. 40

41 Utviklingsmiljø Til utvikling av selve nettsiden har vi primært brukt netbeans. Netbeans har fungert utmerket i sammenheng med både PHP, HTML og CSS. Netbeans ble spesielt nyttig da det har integrert støtte for Git, som vi har brukt for å sikre mot overskriving av data. Nettbeans inneholder en rekke andre funksjoner som har vært verdifulle for oss. Støtte for å dokumentere kode i henhold til PHP sin dokumentasjonsstandard har gjort funksjonene mer oversiktelig, refaktorering, finn bruk, og snarvei til å gå til deklareringen av variabler har gjort skriving av kode mer effektivt og innebygget støtte til kodevalidering (inkl. støtte for XML validering) og god og oversiktelig versjons og endringshåndtering har gjort retting av feil enkelt. MySQL Workbench ha oss muligheten til å designe databasen ved hjelp av et visuelt overblikk. Dette var nyttig både når vi designet den originale databasen, og når vi redesignet den senere i prosessen. For å administrere databasen etter den var designet ble PHPMyAdmin brukt Nettlesere Kompatibilitet med ulike nettlesere var et sentralt mål for oppgaven. Under hele utviklingsprosessen ble siden derfor testet i en rekke nettlesere for å bekrefte at ingen funksjonalitet ble tapt, eller at utseende ble forvrengt ved bruk av en annen nettleser enn det utvikler har brukt. For å begrense dette til et realistisk mål, forholdt vi oss hovedsaklig til de tre største nettleserene i verden; Firefox, Internet Explorer og Chrome. Nettsiden benytter noe jquery, men all funksjonalitet er også tilgjengelig med en nettleser som ikke støtter javascript Mamut-connect (Xlink) For å kommunisere med Mamut tok vi kontakt med en leverandør av tredjepartsmoduler, excommerce. Som nevnt tidligere i rapporten, ble løsningen Mamut tilbød oss for kostbar, og ville i tillegg være for teknisk utfordrende for oss å gjennomføre. excommerce produserer moduler for bl.a Mamut og nettbutikker, og kunne tilby en modul som vi kunne tilpasse våre behov. Modulen, som heter Connect-Mamut, er et program som kjøres på samme server som Mamut, og brukes til å sende informasjon fra og til en nettside og Mamut. Modulen genererer XML-filer som sendes til et php-script som postdata. Den kan også sende en beskjed til php scriptet, hvor den ber om få XMLdata sendt i retur. Da nettsiden er passiv, er det connectmamut som initierer samtalen. Modulen skal håndtere all trafikk imellom Mamut og nettsiden som relaterer til informasjon i Mamut sin database, og utvalgte deler av nettsidens database. Søken etter en aktuell modul ble foretatt i prosjektets begynnelse. Vi undersøkte deler av markedet, men endte på excommerce sin løsning da deres presentasjon gav oss et særdeles godt inntrykk av modulen. En annen avgjørende faktor for valget var at excommerce tilbød ett års gratis forbruk da vi er en studentgruppe og bisto med support underveis i utviklingen 41

42 5.3. Samsvar mellom kravspesifikasjon og produkt Generelt møtte det ferdige produkter kravene fra kravspesifikasjonen, men det finnes noen unntak hvor kravene endret seg eller ikke ble møtt. Blandt disse er endringer i krav til registrering og tilgangskontroll dominerende, da dette førte til endringer som resulterte i at fire krav fra kravspesifikasjonen ikke ble møtt. De originale kravene: Kunder må registrere seg for å få tilgang til å bruke butikken Firmaer må godkjennes av LM Dahl og aktiveres før firmaets brukere kan bruke butikken Uregistrerte brukere får kun tilgang til en begrenset visning av produktsidene. Da produktsidene ble opprettet kom LM Dahl frem til at de ikke ønsket å inkludere priser på produkter i nettbutikken. Dette var fordi LM Dahls kunder er firmaer, og det eksisterer svært mange rabattavtaler. Hvis priser skulle føres opp på siden ville de ikke være korrekte for alle kundene. Da priser ikke lenger skulle inkluderes, kom det frem at det var nettopp priser som var hovedårsaken til at tilgang til produktinformasjon skulle begrenses til registrerte, aktiverte og godkjente kunder. Når priser ikke lenger var inkludert, var det ikke lenger behov for å ha en så streng tilgangskontroll. Det nye oppsettet ble at man har tilgang til produktsidene og legg i handlevogn -funksjonen selv om man ikke er logget inn, men hvis man ønsker å gå videre fra handlevogn til Be om tilbud eller Bestill produkter må man logge seg inn. I tillegg til dette ble kravene om å føre dagbok om alt vi gjorde under prosjektarbeidet ikke møtt, dette var delvis fordi vi innad i gruppen ikke følte at dagboken var nødvendig, men særlig fordi vi brukte utviklingsverktøyet NetBeans som har en loggføringsfunksjon som gir god oversikt over hva som har blitt gjort. 42

43 5.4 Nettsidens oppbygning og virkemåte Nettsidens struktur Nettsiden er bygget rundt de fem hovedsidene; Hjem (forsiden), Produkter (nettbutikkens produktsider), Min side (administrering av brukerkonto for vanlige brukere), kontrollpanel (administrators sider) og Logg inn sidene som signup siden (registrering), glemt brukernavn og glemt passord er en del av. Overblikk av nettsidens struktur : Hjem Produkter Produkter i overkategori Min side (bruker) Firma Produkter i overkategori / kategori Produkter i overkategori / kategori / underkategori overkategori / kategori / underkategori / produktdetaljer Mine firmadetaljer Rediger firma Mine Faktureringsadresser Legg til ny faktureringsadresser Rediger faktureringsadresse Mine leveringsadresser Legg til ny leveringsadresse Rediger leveringsadresse Bruker Opprett ny bruker Rediger min bruker Endre passord Ordre Se mine ordre Rediger ordre Slett ordre Kontrollpanel (administrator) Bruker Legg til ny bruker Brukersøk Rediger brukerkonto Firma Aktiver firma Legg til firma Firmasøk Firmadetaljer Rediger firma Ordre Ordresøk 43

44 Ordredetaljer Produkt Behandle kategorier Produktsøk Produktdetaljer Rediger produkt Logg inn Signup (registreringsskjema) Glemt brukernavn Glemt passord Resett passord Funksjonalitet bak produktbestilling Produktbestilling er nettsidens hovedoppgave og inneholder den mest kompliserte funksjonaliteten. Når produktsiden åpnes ser man produktforsiden og en meny på venstre side. Produktene som vises her er listet opp i et stort rutenett. Dette er produktene som i databasens Produktertabell har verdien 1 i feltet featured. Dette er en boolean verdi som LM Dahl kan gi fra administratorkontrollpanelet. På denne måten kan man vise spesielle produkter man ønsker at skal fange kundenes oppmerksomhet på forsiden. Menyen bygges ved å hente overkategorier, kategorier og underkategorier for alle produkter i databasen Disse sorteres ved å kjøre en foreach-løkke som viser alle kategorier som tilhører de forskjellige overkategoriene, og alle underkategoriene som tilhører de forskjellig kategoriene. Ved å lage menyen på denne måten vil ikke utvidelse av vareutvalget kreve endring av koden, da nye kategorier automatisk vil oppdatere menyen. Klikker man på en overkategori utvides menyen for å vise kategoriene den inneholder, og produktene med denne overkategorien listes opp. På samme måte vises underkategoriene som tilhører kategorien, og produkter med denne kategorien listes opp hvis man klikker på en kategori. Hvis man til slutt velger en underkategori vises kun produkter av denne underkategorien. På denne måten gjør nettsiden det enkelt å navigere seg frem til riktig produkt hvis man har kunnskap om hva man leter etter. Dette skjer ved å gi databasekommunikasjonsfilen, dbadapter, begrensninger i innparameteret til den gjeldende funksjonen, slik at spørringen returnerer færre resultater. Alle produkter på siden vises med bilde, varenummer, produktnavn, en antallboks og en legg i handlevogn -knapp. Alle sider som lister opp produkter tilbyr muligheten til å sortere etter varenummer, eller produktnavn. Dette skjer ved å benytte ASC og DESC i sql spørresetningen. Siden lister opp produkter ved å benytte Produkterklassens hentforsok funksjon, som bruker dbadapterfunksjonen produktsok, for å hente varenummer fra databasen. Deretter kjører produkterobjektet en foreachløkke på hvert varenummer, hvor produktobjekt opprettes, 44

45 og kontstruktøren til produktobjektene kjører spørring mot databasen for å hente informasjon om produktene basert på varenummer. Disse produktobjektene har getmetoder som returnerer ferdig htmlkode for å se på et produkt, mens produkterobjektene har getmetoder som returnerer flere typer visninger av produktlister. Hvis man er logget inn og klikker på Legg i handlevogn -knappen, blir man sendt til handlevognsiden. Her blir et handlevognobjekt opprettet, som inneholder produktobjekt og kundeobjekt. Et kundeobjekt er en utvidelse av firmaobjekt, som inneholder egenskapene til et firma og en bruker. Hvis man ikke er logget inn blir kun produktobjektet puttet i handlevogn. Handlevognobjektet lagres i en sesjonsvariabel. På handlevognsiden har man mulighet til å endre antall produkter, det oppdaterer produktobjektet. Man kan også fjerne produkter og tømme handlevognen, som kjører unset på sesjon sin handlevognvariabel. Man kan gå tilbake til produktsidene, eller velge neste, som sender innloggede brukere til ordrefullføringssiden, og ikke innloggede brukere til en logg inn side. På ordrefullføringssiden velger man leverings- og faktureringsadressen man ønsker å bruke på ordren fra en nedtrekksmeny, adressene som er satt som standard er allerede valgt. Man kan også velge å fylle inn noe i Merk ordren med feltet. Velger man her å bestille produktene opprettes et ordreobjekt som inneholder en handlevognobjektets produktarray, leveringsadresseid, faktureringsadresseid, og kundeobjektets brukerid og generell ordreinformasjon. Dette objektet benyttes til å lagre ordreinformasjon i databasetabellene Ordre og ProduktOrdre. Man blir deretter sendt til en ordredetaljer side som viser informasjon om ordren man nettopp gjennomførte, og en bestillingsbekreftelse sendes til kundens og LM Dahs epostadresser. Ordredetaljer er også tilgjengelig fra brukerenes Min side og administratorenes kontrollpanel. Velger man be om tilbud fra ordrefullføringssiden vil en epost bli sendt til LM Dahl som brukes for å gi en pris på varene en bedrift ønsker å bestille. Denne informasjonen lagres ikke i databasen Komunikasjon med mamut Mamut-connect vil håndtere kommunikasjon mellom Mamut og nettsiden. Ved å eksportere produkter fra Mamut til nettsidens database vil produktkatalogen kunne oppdateres lett. Kolonnen mamutid i nettsidedatabasetabellen Produkt er det samme ID som produktet er registrert med i Mamut, og blir brukt som varenummer i nettsidens og Mamuts database. Mamut-connect gjør dette ved å sende en XML-formatert poststream med de nødvendige data. Dette inkluderer varenummer, pris, navn og andre kjernedata, som blir lagret i nettsidens database. Mamut-Connect skal også håndtere ordreimport fra nettsiden til Mamut. Med faste intervaller, vil ordredata bli overført fra nettsidens database til Mamuts database for enklere ordrehåndtering. Denne implementasjonen har vi ikke lagt inn for øyeblikket, da arbeidsgiver ønsket å beholde det gamle systemet for ordremottagelse inntill videre. 45

46 Databasestruktur Databasens tabeller i alfabetisk rekkefølge: Beskrivelser Brukere Fakturaadresser Firma Kategorier Leveringsadresser Ordre Overkategorier ProduktBeskrivelser Produkter ProduktOrdre Underkategorier Illustrasjonen viser et overblikk av databasens struktur, hvor tabellene er sentralisert rundt de to viktigste tabellene; Produkt og Ordre. Fig Illustrasjon av databasestruktur. Overblikk. 46

47 5.4.5 Databasen: Tabeller og relasjoner Databasen består av 12 tabeller, hvor to av tabellene har oppstått som en følge av splittelse av mange til mange relasjoner. Dette inkluderer ProduktOrdre, som er en tabell mellom Produkter og Ordre, og ProduktBeskrivelse, som er en tabell mellom Produkter og Beskrivelser. Databasen oppfyller ikke alle normaliseringskrav, da postadresser ikke er skilt ut i en egen tabell. Dette ble ikke gjort fordi LM Dahl har mange kunder i utlandet og det derfor ikke var mulig med en tabell som inneholdt alle postadresser som kunne bli valgt. Behovet var derfor ikke stort nok til å skille ut postadresse til at vi inkluderte det i denne versjonen av databasen. Databasens tabeller: Brukere I denne tabellen lagres informasjon om brukerkontoer som brukernavn, passord, fornavn og etternavn. Hver brukerkonto har en unik id. Hver brukerkonto inneholder også et felt for firmaid til firmaet brukerkontoen er knyttet til. Denne blir hentet fra firmatabellen. Det er her vi setter f.eks aktivbruker til 0 hvis brukerkontoen skal deaktiveres. Firma Denne tabellen inneholder informasjon om firmaer som er registrerte som kunder av nettbutikken. Dette inkluderer kontaktinformasjon og en unik id. Overkategorier, Kategorier og Underkategorier Alle produkter nettsiden inneholder må ha en overkategori, kategori og underkategori. Tabellen inneholder et kategoribilde for underkategori som erstatter produktbilde hvis produktets bilde ikke eksisterer. Den inneholder også et sett med ID og beskrivelser som benyttes av nettbutikken, og ett sett med ID og kategorier som brukes av mamut. Hver kategori inneholder ID til kategorien som er over. Leveringsadresser Denne tabellen inneholder all informasjon man trenger for å levere et produkt og et boolean felt for å sette adressen som standard. Leveringsadresser er knyttet til firma og inneholder derfor firmaid. Fakturaadresser Denne tabellen er bygget opp på samme måte som leveringsadresser. Produkter Denne tabellen inneholder informasjon om produkter. Produktene får en unik id. I tillegg til dette blir mamuts id lagret her, dette bruker nettsiden som varenummer. Tabellen inneholder boolean felt for aktivprodukt som gjør det mulig å deaktivere produkter som ikke lenger er tilgjengelig. Produkttabellen henter inn id fra alle de tre kategoritabellene. 47

48 Beskrivelser Nettsidens produkter kan ha mange beskrivelser, som dimensjoner, spesifikasjoner og lignende. I denne tabellen lagres disse. Hver beskrivelse, f.eks. lengde, vil få en beskrivelsesid, en tittel, som i dette tilfelle ville vært lengde, og en beskrivelse som er selve verdien. ProduktBeskrivelser Da et produkt kan ha mange beskrivelser,og en beskrivelse kan gjelde for mange produkter, ble denne tabellen opprettet. Den inneholder beskrivelsesid og produktid, og knytter på denne måten sammen de to tabellene. Ordre Ordretabellen innehoder informasjon man må lagre om ordre, som en unik ordreid, bestillingsdato, boolean felt for om ordren er åpen og lignende. Ordretabellen henter inn brukerid fra brukeretabellen, fakturaadresseid fra fakturaadressetabellen og leveringsadresseid fra leveringsadressetabellen. ProduktOrdre Da en ordre kan inneholde mange produkter, og et produkt kan finnes i mange ordre, ble denne tabellen opprettet for å splitte mange til mange relasjonen. Den inneholder produktid, ordreid og antall av hvert produkt i en ordre. Relasjonene Relasjonene mellom disse tabellene er satt opp for å skape en sammenheng mellom dataene i databasen. I tilfeller hvor det har oppstått mange til mange relasjoner har vi, som nevnt tidligere spilltet disse, og laget tabeller som fungerer som en kobling Kommunikasjon med database Kommunikasjon med databasen foregår via funksjoner i filen dbadapter.php. Disse funksjonene er laget for å gjennomføre spesifikke oppgaver, noen er svært enkle, mens andre er mer avanserte. Funksjonene i dbadapter benytter klassen Mysql.class.php, som er en modifisert versjon av en åpen kildekodeklasse vi hentet fra t= Mysql klassens hensikt er å forenkle tilkobling til, og kommunikasjon med, databasen og sørge for at kun en tilkobling mot databasen er åpen av gangen. For at funksjonene skal returnere data på en måte vi ønsker å arbeide med bruker de QueryResult klassen som i likhet med Mysql.class.php er en modifisert versjon av en åpen kildekode klasse vi hentet fra QueryResult klassens hensikt er å gjøre det enklere å behandle resultater fra spørringer mot databasen. Dbadapter sine funksjoner har blitt opprettet etter behov, men eksisterende funksjoner har blitt brukt i tilfeller hvor dette var mulig. Dbadapter inneholder svært mange funksjoner, bl.a. en veldig generell funksjon med navn sjekkomfinnes som tar tabellnavn, kolonnenavn og en verdi som innparameter, og undersøker om verdien finnes i kolonnen i tabellen. 48

49 Kildekode for funksjonen sjekkomfinnes: function sjekkomfinnes($tabell, $kolonne, $string, $kolonne2=null, $string2=null){ $db = Mysql::singleton(); $string = $db->sanitize($string); $kolonne = $db->sanitize_noquotes($kolonne); $tabell = $db->sanitize_noquotes($tabell); if(isset($kolonne2) && isset($string2)) { $string2 = $db->sanitize($string2); $kolonne2 = $db->sanitize_noquotes($kolonne2); $resultat =$db->select("select $kolonne FROM $tabell WHERE $kolonne = $string AND $kolonne2 = $string2;"); } else { $resultat =$db->select("select $kolonne FROM $tabell WHERE $kolonne = $string;"); } if($resultat!==false) { if($resultat===0) return($resultat); else return $resultat->getnumrows(); } else return false; } Som man ser er dette en meget allsidig funksjon. Det er viktig å merke seg at her brukes $db = Mysql::singleton() til å undersøke at det ikke er en åpen database tilkobling, for så å åpne en tilkobling. Etter dette blir sanitize funksjonen fra mysql klassen brukt til å fjerne uønskede tegn og mellomrom fra verdiene funksjonen får inn. Til slutt kan man se at getnumrows() blir brukt på resultatet av spørringen. Denne brukes ved at man får et resultatobjekt av mysql klassen og funksjonen getnumrows returnerer antall rader som ble telt i resultatobjektet sin konstruktør. Et annet eksempel på en dbadapterfunksjon er den mer kompliserte finnbruker som brukes til å hente ut informasjon fra brukere tabellen. 49

50 Kildekode for dbadapter funksjonen finnbruker: function finnbruker($brukerid=null,$brukernavn=null,$admin=null, $like=null, $firmaaktivert=true, $brukeraktivert=true,$sorteretter=null,$retning=null){ $db= Mysql::singleton(); // Klargjør dataene if (isset($brukernavn) AND isset($like)) $brukernavn = $db->sanitize_noquotes($brukernavn); elseif (isset($brukernavn)) $brukernavn = $db->sanitize($brukernavn); if (isset($brukerid)) $db->sanitize($brukerid); if (isset($admin)) { if (is_numeric($admin)) { $db->sanitize($admin); } elseif (is_bool($admin)) { $admin = ($admin)? 1:0; $admin = $db->sanitize($admin); } else die("admin must be a Tinyint (0 or 1) or a Boolean value"); } if (isset($firmaaktivert)) { if (is_numeric($firmaaktivert)) { $firmaaktivert = $db->sanitize($firmaaktivert); } elseif (is_bool($firmaaktivert)) { $firmaaktivert = ($firmaaktivert)? 1:0; $firmaaktivert = $db->sanitize($firmaaktivert); } else die("firmaaktivert must be a Tinyint (0 or 1) or a Boolean value"); } if(isset($brukeraktivert)) { if (is_numeric($brukeraktivert)) { $brukeraktivert = $db->sanitize($brukeraktivert); } elseif (is_bool($brukeraktivert)) { $brukeraktivert = ($brukeraktivert)? 1:0; $brukeraktivert = $db->sanitize($brukeraktivert); } else die("brukeraktivert must be a Tinyint (0 or 1) or a Boolean value"); } // Bygger WHERE setningen if (isset($brukerid) AND isset($brukernavn)){ $hvor = " WHERE ".InstDB::KOL_BR_BRUKERID." = $brukerid and ".InstDB::KOL_BR_BRUKERNAVN." = $brukernavn "; $hvor.= (isset($admin))? "AND ".InstDB::KOL_BR_ADMIN." = $admin":""; $hvor.= (isset($firmaaktivert))? "AND ".InstDB::KOL_FIR_AKTIVERT." =$firmaaktivert ":""; $hvor.= (isset($brukeraktivert))? "AND ".InstDB::KOL_BR_AKTIV." =$brukeraktivert ":""; } elseif (isset($brukerid)) { $hvor = "WHERE ".InstDB::KOL_BR_BRUKERID." = $brukerid "; $hvor.= (isset($admin))? "AND ".InstDB::KOL_BR_ADMIN." = $admin":""; $hvor.= (isset($firmaaktivert))? "AND ".InstDB::KOL_FIR_AKTIVERT." =$firmaaktivert ":""; $hvor.= (isset($brukeraktivert))? "AND ".InstDB::KOL_BR_AKTIV." =$brukeraktivert ":""; } elseif (isset($brukernavn)) { $hvor = "WHERE ".InstDB::KOL_BR_BRUKERNAVN.""; if(isset($like)) $hvor.=" LIKE '%$brukernavn%'"; else $hvor.= " = $brukernavn "; $hvor.= (isset($admin))? "AND ".InstDB::KOL_BR_ADMIN." = $admin":""; 50

51 $hvor.= (isset($firmaaktivert))? "AND ".InstDB::KOL_FIR_AKTIVERT." =$firmaaktivert ":""; $hvor.= (isset($brukeraktivert))? "AND ".InstDB::KOL_BR_AKTIV." =$brukeraktivert ":""; } elseif (isset($admin)) { $hvor = "WHERE ".InstDB::KOL_BR_ADMIN." = $admin"; $hvor.= (isset($firmaaktivert))? "AND ".InstDB::KOL_FIR_AKTIVERT." =$firmaaktivert ":""; $hvor.= (isset($brukeraktivert))? "AND ".InstDB::KOL_BR_AKTIV." =$brukeraktivert ":""; } elseif (isset($firmaaktivert)) { $hvor = "WHERE ".InstDB::KOL_FIR_AKTIVERT." =$firmaaktivert "; $hvor.= (isset($brukeraktivert))? "AND ".InstDB::KOL_BR_AKTIV." =$brukeraktivert ":""; } elseif (isset($brukeraktivert)) { $hvor = "WHERE ".InstDB::KOL_BR_AKTIV." =$brukeraktivert "; } else { $hvor = "WHERE 1"; } $hvor.= " AND ".InstDB::KOL_FIR_ID." = ".InstDB::KOL_BR_FIRMAID." "; //if(isset($aktiv)) $sql = "SELECT ".InstDB::KOL_BR_BRUKERID." as '".InstDB::KOL_BR_BRUKERID."', ".InstDB::KOL_BR_BRUKERNAVN." as '".InstDB::KOL_BR_BRUKERNAVN."', ".InstDB::KOL_BR_FORNAVN." as '".InstDB::KOL_BR_FORNAVN."', ".InstDB::KOL_BR_ETTERNAVN." as '".InstDB::KOL_BR_ETTERNAVN."', ".InstDB::KOL_BR_EPOST." as '".InstDB::KOL_BR_EPOST."', ".InstDB::KOL_BR_ADMIN." as '".InstDB::KOL_BR_ADMIN."', ".InstDB::KOL_BR_SESJONID." as '".InstDB::KOL_BR_SESJONID."', ".InstDB::KOL_BR_FIRMAID." as '".InstDB::KOL_BR_FIRMAID."', ".InstDB::KOL_FIR_NAVN." as '".InstDB::KOL_FIR_NAVN."', ".InstDB::KOL_BR_AKTIV." as '".InstDB::KOL_BR_AKTIV."' FROM ".InstDB::TAB_Brukere.", ".InstDB::TAB_Firma." $hvor;"; } $resultat = $db->select($sql); if ($resultat) { if(isset($brukerid) (isset($brukernavn) AND!isset($like) ) ) return $resultat->getrow(0); else return $resultat->getarray(); } else return FALSE; Denne funksjonen er mer avansert fordi den i tillegg til å bruke mysql::singleton() og sanitize som andre funksjoner, også bygger opp spørresetningen basert på hvilke innparameter den har fått. På denne måten kan vi bruke den samme dbadapterfunksjonen til å hente ut forskjellige data. Til slutt kan man se at også her brukes getrow, men her brukes også funksjonen getarray. Denne funksjonen returnerer dataen i form av et array som inneholder et assosiativt array for hver rad. Dette gjør at informasjonen er lett tilgjengelig etter den er hentet ut av databasen. 51

52 5.5 Hovedfunksjonalitet og sekundærfunksjonalitet Hovedfunksjonalitet Se produkter Finne frem til produkter Legge produkt i handlevogn Gjennomføre bestilling / be om tilbud Sekundærfunksjonalitet Toppmeny Navigere til: Forsiden (Hjem) Produkter Kontrollpanel / Min side Logg inn / Logg ut Glemt passord Glemt brukernavn Signup Min side Forsiden inneholder oppsumert informasjon om: Brukerkonto Firmainformasjon Leveringsadresser Faktureringsadresser Ordrehistorikk Meny: Firma Se firmadetaljer og brukerkontoer tilknyttet firmaet Redigere firmadetaljer Se, redigere, legge til nye faktureringsadresser Se, redigere, legge til nye leveringsadresser Bruker Opprette nye brukerkontoer tilknyttet brukers firma Redigere brukerkontoinformasjon Endre brukerkontoens passord Ordre Se firmaets ordre Se detaljert ordreinformasjon 52

53 Administratorkontrollpanelet Meny: Bruker Legge til nye brukere til firmaer Søke opp brukere Redigere og slette brukerkonto Firma Aktivere firmaer Registrere nytt firma Søke opp firmaer Se firmadetaljer og brukere tilknyttet firma Redigere firmainformasjon Ordre Se ordre liste Søke opp ordre Se ordredetaljer og slette ordre Produkt Behandle produktkategorier Søke opp produkter Se produktdetaljer Rediger produktinformasjon Signup Registrere firma med brukerkonto Glemt passord sender epost til bruker, autogenererer passord Glemt brukernavn bruker epostadresse til å finne brukernavn, sender dette til epostadresse. 53

54 5.6 Sikkerhet Nettsiden inneholder en rekke sikkerhetstiltak som man må sette seg inn i for å forstå nettsidens kompleksitet. Sidens sikkerhetsfunksjoner har flere oppgaver, blant annet sørger de for å begrense brukeres tilgang, beskytte data som passord, personlig informasjon, ordrehistorikk og beskytteler siden mot angrep. Sidens sikkerhetstiltak inkluderer: En selvutviklet url-kontroller Tilgangskontroll Innlogging Inputvalidering Fjerning av uønskede tegn før lagring Krav til passordkompleksitet Krav til unike verdier Deaktivering av brukerkontoer Hashing av passord Det første sikkerhetstiltaket er sidens spesiallagede URL-kontroller som man kan finne i index.php. URL-kontrollerens oppgave er å styre trafikken på siden til rett sted, og å sende med informasjon til neste side i tilfeller hvor dette er nødvendig. For å få den fuksjonaliteten som var ønsket ble denne konstruert fra bunnen av og modifisert underveis. Dette har også gjort det mulig å lage adresser til undersider som inneholder ønskelig informasjon. Et eksempel på dette er muligheten til å ha products/produktnavn, eller brukere/brukernavn, som adresse, for å så ta med seg brukernavnet fra adressen som innparameter i funksjonen som blir kalt på. URL-kontrolleren er et betydelig sikkerhetstiltak da den krever at brukeren er innlogget for å se sider spesifikke sider, og at brukeren er administrator i tilfeller hvor dette er påkrevet. Et eksempel på dette er administratorkontrollpanelet, hvor URL-kontrolleren krever at brukeren er en administrator for å få tilgang. Hvis man ikke oppfyller dette kravet vises en tekst som forklarer at man ikke har tilgang til å se sidens innhold. For å undersøke om brukeren er logget inn, sjekkes sessions og cookies. Når man logger inn får man man to cookies sin blir navngitt 1 og 2, urelevante navn er valgt pga security by obscurity prinsippet, som inneholder hashede verdier. Fra cookiene får man tak i brukerid og sesjonsid. På denne måten har sidene en effektiv form for tilgangskontroll. For å sørge for enda strengere tilgangskontroll er viktige filer, som administratorkontrollpanelet, plassert i undermapper. Rettighetene på disse undermappene er satt til 700 slik at kun eier av filene har tilgang. I tillegg benyttes filen.htaccess som sikkerhetstiltak for å gjøre det umulig å navigere til en mappe ved å skrive inn navnet på mappen i URL-feltet. Kildekoden til URL-kontrolleren er for stor til å vise her, hvis det er ønskelig å studere denne ligger koden i filen index.php. For å hindre at uønskede tegn, eller informasjon, blir lagret i databasen benyttes to sikkerhetstiltak. Den første av disse er inputvalidering, som genereres ved hjelp av valideringsklassen. Denne inneholder en rekke funksjoner som utfører validering på input. 54

55 Dette inkluderer passordkompleksitet, epostadressers format, om felt vi krever at er unike ikke er lagret i databasen tidligere, at felt vi krever fylles ut og mye annet. På denne måten sikrer nettsiden at riktig informasjon blir lagret. Det andre sikkerhetstiltaket nettsiden bruker i denne sammenhengen er mysql-klassens sanitize funksjoner; sanitize, sanitize_array og sanitize_noquotes. Dette er funksjoner som fjerner uønskede tegn og mellomrom i tekst. Før informasjon lagres i databasen fra dbadapter brukes disse funksjonene på dataen. Administrator har mulighet til å deaktivere brukerkontoer og firmaer fra administratorkontrollpanelet, dette er for å sikre i tilfeller hvor en bruker mister kontroll over sin brukerkonto. Et siste sikkerhetstiltak vi vil nevne er lagring av passord. Når en bruker oppretter en konto vil det måtte krypteres for å sikres. Krypteringen foregår ved hjelp av funksjonen krypterpassord i filen funksjoner.php. Denne funksjonen generer krypteringen i tre steg. Først vil den bruke variablen salt, som er en tilfeldighetsgenerator som tar den nøyaktige tiden kunden trykker på submit-knappen i millisekunder, legger til en tekststring vi definerte selv og brukernavnet til kunden. Denne variablen blir lagt inn i en ny variabel, hash, som hasher salt og kundens passord i en streng. Deretter krypteres hash med en 256bits kryptering som blir loopet titusen ganger. Til slutt blir det returnert salt med den krypterte hash stringen som et endelig resultat av passordkrypteringen. Dette blir så lagret i databasen som kundens passord. Denne krypteringsmetoden gjelder for alle passord på siden. Passordgjennoppretning kan gjøres igjennom glemt passord siden. Selve gjennoppretningen er ikke et sikkerhetstiltakt, men er mer ment som nødvendig funksjonalitet. Vi velger å ta med dette for å disktuere sikkerhet rundt passordgjennoppretningsrutinene. Hvis en bruker glemmer sitt passord, og ber om å få det resatt, så vil det sendes ut en epost til den registrerte adressen til brukernavnet. Hvis eposten er feil vil det ikke fungere å gjennopprette passordet på denne måten, og det må tas direkte kontakt med LM Dahl. Hvis eposten er riktig, vil brukeren motta en epost med en link til en gjennoprettingsside. Ved å trykke på denne linken vil brukerens gamle passord bli fjernet fra databasen, og en ny side vil åpne seg som inneholder et tilfeldig generert passord. Dette passordet kan brukeren logge seg inn med og endre fra mine sider. 55

56 Kildekode for sanitize funksjonen: public function sanitize($input) { $input = trim($input); if(!is_numeric($input)) { if(get_magic_quotes_gpc()) { $input = stripslashes($input); } $input= strip_tags($input); if(substr($input, 0, 1)!="'" && substr($input, -1, 1)!="'") $input = "'". mysql_real_escape_string($input). "'"; else $input = mysql_real_escape_string($input); } return($input); } Eksempel på valideringsfunksjon: Kildekode for valideringsfunksjonen validate_password: function validate_password($password) { $bret = FALSE; if (preg_match("/^ (?!.*(.)\1{3}) ( (?=.*[\d]) (?=.*[a-zæøå]) (?=.*[A-ZÆØÅ]) (?=.*[a-zæøå]) (?=.*[A-ZÆØÅ]) (?=.*[^\w\d\s]) (?=.*[\d]) (?=.*[A-ZÆØÅ]) (?=.*[^\w\d\s]) (?=.*[\d]) (?=.*[a-zæøå]) (?=.*[^\w\d\s]) ).{7,45} $/", $password)) $bret = TRUE; return $bret; } 56

57 5.7 Krav til miljø Nettbutikkens krav er i likhet med de fleste nettsider hovedsakelig krav til serverens oppetid og stabilitet, både for webserver og mysqlserver. Nettbutikken krever også PHP5, noe som er et krav til server. For administratores del, kreves Mamut og Mamut-Connect for å få nettsiden til å fungere, da det er her vareinformasjon hentes fra. Krav til brukere er minimale, hvis man ser bort i fra det opplagte som internettilgang og andre selvfølgeligheter. Nettbutikken benytter jquery, noe som betyr at den krever javascriptstøtte i nettleser for å fungere optimalt, men alle moderne nettlesere har dette. Det kan forekomme noe variasjon i utseende grunnet forskjellig søtte for HTM5 og CSS3 i nettlesere, men sidens funksjonalitet blir ikke berørt av dette. To av nettsidens funksjoner, glemt brukernavn og glemt passord, krever en gyldig epostadresse man har tilgang til. Hvis man ikke har tilgang til epostadressen man har registrert på nettsiden, vil man ikke ha tilgang til å se eposter fra LM Dahl Webshop. 5.8 Videreutvikling Videreutviklingsmuligheter har vært svært viktig under arbeidet med LM Dahl Webshop. Siden ble laget med tanke på at det skulle være mulig å oppnå dens fulle potensiale selv om prosjektets tidsrammer ikke strakk til. En rekke ting ble lagt til rette for å sørge for at produktet skulle være et så godt grunnlag som mulig. Her presenteres disse tiltakene og våre anbefalinger til videreutvikling Tilrettelegging for videreutvikling Under utviklingsprosessen har vi gjort en flere valg for å tilrettelegge for fremtidige utviklere. Dette er ikke begrenset til funksjoner alene, men gjelder også selve oppbygningen til nettsiden. Vi har hele tiden holdt oss til en modulert struktur, noe som gjør at gjenbruk av funksjoner blir meget mulig. Det mest betydelige valgene er plassering av stringer i en XML-fil, slik at det lett kan opprettes versjoner av nettsiden på andre språk. Vi har også brukt konstanter i bl.a sql-spørringer, slik at det ikke er nødvendig å endre alle spørringer hvis man modifiserer databasen, man trenger kun å endre konstantenes verdi. Vi har forsøkt å holde koden ryddig, og har kommentert alle funksjoner underveis. Håpet er at dette vill gjøre det enklere for fremtidige utviklere å forstå vårt arbeid. I tilegg til dette finnes det en rekke mindre tilrettelegginger vi har skrevet inn i koden, men de er ikke nødvendigvis inkludert alle steder det kan være behov for de. Et eksempel på dette er funksjonen sidevelger. Den kan brukes i sammenheng med søkefunksjoner til å begrense antall treff som vises per side. Den legger til neste side -knapper og sidenummer i form av side X av Y. Vi ser for oss at sidevelger kan være aktuell ved flere anledninger enn den er inkludert på nå. Vi har under hele prosessen brukt GIT, et verktøy som gjør det mulig å lese en loggføring for hele utviklingen, og gjør arbeidet generelt lett tilgjengelig for fremtidige utviklere så lenge de har tilgang til koden. Vi vil sterkt anbefale at eventuelle utviklere som skal fortsette arbeidet med nettsiden benytter dette. 57

58 5.8.2 Anbefalt videreutvikling Tiltak som kan bli gjort for å forbedre siden ved videreutvikling er varierte, men noen kan være særdeles viktige med tanke på å drive en internasjonal nettbutikk. Vi har notert ned det vi mener er det viktigste, men det er flere tiltak som kan gjøres på siden for å forbedre opplevelsen for brukere og bedriften. Det første som bør implementeres er flere språk, spesielt engelsk. Flere av bedriftens kunder kommer fra utlandet, og det bli da helt nødvendig å ha siden oversatt til engelsk. Disse kundene må for øyeblikket ta kontakt med LM Dahl direkte for å kjøpe produkter, noe som ikke er optimalt i henhold til bedriftens ønsker. Andre funksjoner som bør legges til, men som ikke er en direkte nødvendighet, er å åpne for at priser som er relevante for den aktuelle innloggede bedriften skal vises, og muligheten til å redigere åpne ordre for både admin og brukere. Det er tilrettelagt slik at å implementere de nødvendige funksjonene ikke blir en stor oppgave for de som skal videreutvikle nettsiden. Det finnes flere videreutviklingsmuligheter med hensikt om å universelt utforme nettsiden. Den vi mener er høyest prioritert er en mulighet for å aktivere høykontrastfarger på nettsiden. Mange av LM Dahls kunder er eldre og det er stor sannsynlighet for at flere er svaksynte. Ved å implementere en høykontrastfunksjon kan det hjelpe brukere å navigere nettsiden. Vi vil også påpeke, med universell utforming i tankene, at det bør utvikles en automatisk utbytting av CSS-filer på siden. Hvis siden oppdager at brukeren surfer fra et nettbrett, eller en smarttelefon, så vil den automatisk endre CSS-filene slik at siden blir vist korrekt på alle platformer. I produkttabellen står det oppført lagerantallet for hvert produkt. Noen produkter lagres med det faktiske antallet, mens andre lagres på en standardform som opererer med 1000 som grunntall. Dette er fordi produkter som pinner og bolter er små varer som bestilles i store mengder av gangen. På grunn av dette vises lagerantall på en noe utydelig måte på nettsiden. Dette er noe som burde bli endret slik at det blir lettere forståelig og tilfredstiller oppdragsgivers ønsker 58

59 5.9 Revidert usecase Usecase for nettsidens funksjonalitet Fig Use case for nettsidens funksjonalitet. Se vedlegg 6 for høyoppløsningsversjon. 59

60 5.9.2 Main success scenario Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Main success scenario: Bruker gjennomfører bestilling Bruker Bruker vil bestille produkt Bruker må være registrert Bruker har en gyldig brukerkonto Bruker mottar bestillingsbekreftelse Bruker mottar ordrebekreftelse Bruker mottar ordre 1. Bruker åpner produktsiden 2. Bruker finner produkt 3. Bruker legger produkt i handlevogn 4. Bruker velger antall 5. Bruker går videre fra handlevogn 6. Bruker velger leverings og faktureringsadresser 7. Bruker bestiller produkter 2.a.Bruker finner ikke produkt 4.a bruker velger antall 0 5.a. Bruker ikke logget inn 5.a.1 Blir bedt om å logge seg inn. 5.b. Bruker har ikke konto 5.b.1 Bruker registerer seg 5.b.2 Bruker logger inn. Brukeren må ha tilgang til epostadressen han / hun har registert for å få mail. 60

61 6. Brukerveiledning 6.1 Forord Denne brukerveiledningen er ikke ment for å gi full oversikt over nettbutikkens funksjonaitet, men en kort gjennomgang av nettsiden, dens innhold og grunnleggende funksjoner. Ønsker man bedre innsikt i nettsidens oppbygning se del 4. Produktdokumentasjon. 6.2 Brukerveiledning (beskrivelse av nettsiden) Toppmeny Fig oppmeny ikke logget inn Fig Toppmeny logget inn Toppmenyen er inkludert i alle sider og har hovedansvaret for navigering på nettsiden. I tillegg til denne finnes det relevante menyvalg i venstremenyen på hver av undersidene. Toppmenyen inneholder lenker til Hjem, Produktsiden, adminkontrollpanel / min side, kontakt oss og logg inn / logg ut. Toppmenyen viser også et søkefelt, hvor man kan søke i vareutvalget, oversikt over hvor man er på sidene og antall varer i handlevogn. 61

62 Forside Fig Forsiden ikke logget inn 62

63 Fig Forsiden, åpen logg inn boks Forsiden er det første man møter når man går til nettbutikken. Den inneholder generell informasjon om LM Dahl. 63

64 Produktside Fig Produktside, kategorivisning 64

65 Fig Produktside, underkategorivisning 65

66 Fig Produktsiden, produktdetaljer Produktsiden viser det som kalles featured produkter. Dette er et utvalg av varer som i databasen har fått verdien 1 i booleanfeltet featured i produktabellen. På denne måten kan LM Dahl velge hvilke varer de ønsker at kundene skal se når de åpner produktsidene. Produktsiden har en venstremeny som viser produktenes overkategori. Åpner man en av disse vises alle produkter med denne overkategorien, men grunnet spørringstid viser siden kun 20 produkter av gangen, med mulighet til å bla til neste side. Man får også en oversikt over kategorier som har denne overkategorien. Klikker man på en av kategoriene vises alle produkter av denne kategorien på samme måte som når man klikker på overkategori, men nå vises underkategoriene i menyen og siden viser en beskrivelse av hva kategorien er. Klikker man på underkategorien vises kun produkter av denne underkategorien på siden. Man har hele tiden mulighet til å sortere produktlisten etter varenummer eller produktnavn. Alle produkter på produktsidene vises med bilde av produktet hvis dette er tilgjengelig, hvis ikke vises underkategoribilde. Produktet vises også med varenummer, produktnavn, en boks hvor man kan bestemme antall og en legg i handlevognknapp. Produktnavnet er lenke til en side som viser produktdetaljer. 66

67 Handlevogn Fig Handlevogn med produkter Produkter man har i handlevognen vises med bilde, produktnavn, varenummer, underkategorinavn og lagerantall. Handlevognsiden gir mulighet til å endre antall man ønsker av hvert produkt ved hjelp av en input boks og en oppdater handlevogn knapp. Man kan også fjerne produkter fra handlevognen, eller tømme den helt. For å gjøre det enkelt å legge produkter i handlevognen, for så å fortsette å handle, har siden en tilbake til produkter knapp. Neste knappen sender bruker til bekreft ordre siden som er beskrevet i neste punkt (4.2.5). 67

68 Ordrefullføring Fig Ordrefullføringsside Når man går videre fra handlevognsiden vises Bestill produkter / be om tilbud siden. Herfra kan man velge leveringsadresse og fakturaadresse fra en nedtrekksmeny. Adressene som er satt som standard blir da vist. Ønsker man å legge til nye adresser er også det mulig herfra. For å gjennomføre bestillingen, eller gi beskjed til LM Dahl om at man ønsker et tilbud på disse varene, bruker man knappene nederst på siden. 68

69 Min side Fig Min side, med åpen meny Fig Mine leveringsadresser 69

70 Fig Ordredetaljer Dette er siden hvor brukere kan redigere sin informasjon. Forsiden viser en oversikt over brukerens opplysninger og ordre. Bruker man menyen til venstre kan man se på og redigere brukerkonto, adresser og firmadetaljer. Det er også mulig å lage flere brukerkontoer herfra, disse blir automatisk brukerkonto for firmaet brukeren er en del av. Velger man Ordre i venstremenyen kan man se på brukerkontoens ordre. Hvis ordren er åpen, dvs ikke behandlet av LM Dahl, kan ordren slettes. De tilgjengelige funksjonene fra min side er: Se på og rediger firmadetaljer Se på, legge til nye redigere og slette leveringsadresser Se på, legge til nye redigere og slette faktureringsadresser Opprett ny brukerkonto for innlogget brukers firma Rediger brukerkonto Endre passord Se firmaets ordre Slett ordre hvis åpen 70

71 Administratorkontrollpanelet Fig Administratorkontrollpanel, ordreliste 71

72 Fig Administratorkontrollpanel, Produktsøk, med åpen kategoriredigeringsskjema 72

73 Fig Administratorkontrollpanel, rediger produktbeskrivelser Fra dette kontrollpanelet får man tilgang til nettsidenes administratorfunksjoner. Venstremenyen på denne siden er delt opp i; Bruker, Firma, Ordre og Produkt. Under hver av disse finner man søkefunksjoner, redigerfunksjoner og lignende. Administrator har herfra mulighet til å: Lage brukerkontoer Søke opp og se detaljert brukerkontoinformasjon Redigere brukerkontoer Flytte brukerkontoer mellom firmaer Slette / deaktivere brukerkontoer Aktivere / deaktivere firmaer Registrere nye firmaer Søke opp opp og redigere firmaer. Søke opp og se på ordredetaljer Behandle og legge til nye produktkategorier Søke opp produkter, se produktdetaljer og redigere disse. 73

74 Logg inn / Logg ut Fig login boks Logg inn -boksen vises når man klikker på logg inn i toppmenyen. Denne boksen inneholder et felt for brukernavn og et felt for passord. I tillegg til dette inneholder den lenker til registrer deg - siden (signup), glemt brukernavn -siden og glemt passord -siden. 74

75 6.2.9 Signup Fig Registreringsside Signupsiden er nettbutikkens registreringsside. Her kan man registrere et firma og opprette en brukerkonto for dette ved å skrive inn personinformasjon. Et firma kan ha flere brukere, en bruker kan bare ha ett firma. 75

76 Glemt brukernavn / Glemt passord Fig Glemt brukernavn Fig Glemt passord På glemt passord -siden fylles det inn brukernavn som benyttes av siden til å finne brukerens registrerte epostadresse. Det sendes så ut en epost som inkluderer en lenke hvor brukeren får oppgitt et autogenerert passord. Dette passordet kan logges inn med, og endres fra min side. På glemt brukernavn -siden kan man skrive inn en epostadresse. Denne epostadressen blir brukt til å finne brukernavnet i database og dette blir sendt til brukerens epost. 76

77 Kontakt oss Fig Kontaktside Denne siden inneholder generell kontaktinformasjon om LM Dahl, som adresse, telefonnummer og lignende. Siden inneholder også et kart, som viser hvor bedriften holder til. Dette er et google maps kart, og hvis man klikker på Vis større kart vil man bli sendt til google maps sine sider. Telefonnummer er en telefonlink, dette betyr at hvis man ser på siden fra en mobitelefon vil telefonen forstå at dette er et telefonnummer. Klikker man på Kontakt oss blir man sendt til kontaktskjema siden. 77

78 Kontaktskjema Fig Kontaktskjema Denne siden viser et skjema, hvor man kan fylle ut informasjon og en henvendelse. Klikker man på send vil en epost bli sendt til LM Dahl med denne informasjonen og for brukeren vises en takk for din henvendelse side. 78

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549 Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

DinVikar - Bruker Manual

DinVikar - Bruker Manual DinVikar - Bruker Manual Utvikliet av Fosen-Utvikling AS I samarbeid med Alvens AS Skrevet av: Jonas Kirkemyr Innhold 1 Introduksjon................................................... 4 I Systemet 2 Systemet......................................................

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post.

Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post. Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post. - Konfigurasjon Klikk på Konfigurasjon i menyen helt til venstre, og deretter Min butikk.

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 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

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Håkon Bogsrud Anders Høye Karlsen Alexander Borgen Saxevik Bacheloroppgave vår 2012 IT-støttet bedriftsutvikling Oppgavenummer:

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

CharityDoctors. Brukermanuel

CharityDoctors. Brukermanuel CharityDoctors Side 2 1. FORORD Dette er en brukerdokumentasjon som ble skrevet i forbindelse med vår hovedprosjekt ved Høgskolen i Oslo våren 2011. Dokumentet beskriver bruk av Charity Doctors bestilling

Detaljer

Presentasjon av bachelorprosjekt

Presentasjon av bachelorprosjekt Presentasjon av bachelorprosjekt Oppgave 008E: Utvikling av dynamisk nettsted med portefølje, showreel og nettbutikk, for profilering av multimediaselskap. Oppdragstaker: Morten Nyutstumo (BAIN) Veileder:

Detaljer

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

DOKUMENTASJON E-post oppsett

DOKUMENTASJON E-post oppsett DOKUMENTASJON E-post oppsett Oppsett av e-post konto Veiledningen viser innstillinger for Microsoft Outlook 2013, og oppkobling mot server kan gjøres med POP3 (lagre e-post lokalt på maskin) eller IMAP

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Eksamen i Internetteknologi Fagkode: IVA1379

Eksamen i Internetteknologi Fagkode: IVA1379 Høgskolen i Narvik Side 1 av 5 Eksamen i Internetteknologi Fagkode: IVA1379 Tid: Mandag, 07.06.04, 9:00-12:00 Tillatte hjelpemidler: Alle trykte og skrevne hjelpemidler tillatt. Eksamen består av 4 oppgaver

Detaljer

Mamut Enterprise Partner Web Kunde og Partner Web

Mamut Enterprise Partner Web Kunde og Partner Web Mamut Enterprise Partner Web Kunde og Partner Web Dette er en innføring i hvordan du bruker tilleggsproduktet Mamut Enterprise Kunde- og Partner Web. Først vil det bli gjennomgått hva du kan få ut av din

Detaljer

Seksjoner, kategorier og artikler

Seksjoner, kategorier og artikler Seksjoner, kategorier og artikler Seksjoner, kategorier og artikler En av de viktigste delene av en nettside er innholdet. Nå som vi har en blank installasjon, la oss få inn noen artikler på siden. Artikler

Detaljer

Brukermanual til Domenia Norges webshop

Brukermanual til Domenia Norges webshop Brukermanual til Domenia Norges webshop Du finner din webshop på adressen dittdomenenavn.no/nettbutikk (f.eks www.domenia.no/nettbutikk). 1. Login For å gjøre endringer i nettbutikken din, må du logge

Detaljer

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Prosessrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil

Detaljer

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009 Nettside, Webshop og Beregningsmodell Hovedprosjekt våren [Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

Detaljer

Entobutikk 2.PRODUKTRAPPORT VÅR 2011

Entobutikk 2.PRODUKTRAPPORT VÅR 2011 2.PRODUKTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

Brukermanual til PlanNET

Brukermanual til PlanNET Brukermanual til PlanNET Plandents netthandel Handle raskt og enkelt på www.plannet.no Mars 2016 Side 1 av 19 Innhold Innlogging... 3 Startsiden... 3 Navigeringsmenyen... 3 Søkefelt... 4 Hurtigbestilling...

Detaljer

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

Detaljer

SiteGen CMS. Innføringsmanual

SiteGen CMS. Innføringsmanual SiteGen CMS Innføringsmanual Copyright Barlind Solutions AS 2008 Hva er SiteGen CMS? SiteGen CMS er et såkalt content-management-system; eller med litt andre ord et publiseringssystem. Det kan brukes til

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri. Av Anders Refsahl

Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri. Av Anders Refsahl Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri Av Anders Refsahl Innhold Firma/Oppgavestiller Problemstilling Hvorfor denne oppgaven Løsning av oppgaven Resultater Videre arbeid Firma/Oppgavestiller

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

Detaljer

Få din egen hjemmeside

Få din egen hjemmeside I dette avsnittet lærer du å bygge din egen hjemmeside legge til tekst og bilder lage din egen design legge en bakgrunn på hjemmesiden I neste nummer får du hjelp til å bygge en større hjemmeside til en

Detaljer

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

Detaljer

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015 Brukerveiledning For importapplikasjon til Naturbase Versjon 17. mars 2015 Innhold 1. Innledning... 2 1.1 Rutiner for å legge data inn i Naturbase... 2 1.2 Leveranseinstrukser... 3 2. Om leveranse av data

Detaljer

WP-WATCHER WORDPRESS SIKKERHET

WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei! Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp! Jeg

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

Zpider WebShop. Denne veiledningen viser bruken av Nettbutikk for Flis Fram AB, men fremgangsmåten er lik for begge butikkene.

Zpider WebShop. Denne veiledningen viser bruken av Nettbutikk for Flis Fram AB, men fremgangsmåten er lik for begge butikkene. Zpider WebShop Denne veiledningen viser bruken av Nettbutikk for Flis Fram AB, men fremgangsmåten er lik for begge butikkene. Du kommer nå til påloggingsbildet for Flis Fram AB. Skriv inn Brukernavn og

Detaljer

Innstallasjon og oppsett av Wordpress

Innstallasjon og oppsett av Wordpress Del 1 - Installasjon og oppsett Innstallasjon og oppsett av Wordpress Wordpress har blitt en veldig populær publiseringsplattform for websider. Uten særlige tekniske ferdigheter kan man sette opp profesjonelle

Detaljer

Brukerdokumentasjon for Administrator og andre brukere fra PT

Brukerdokumentasjon for Administrator og andre brukere fra PT Brukerdokumentasjon for Administrator og andre brukere fra PT Innholdsfortegnelse Innlogging...3 Forside...4 Menyen...4 Oversikt over utstyret...6 Rediger utstyr...7 Opprett nytt utstyr...9 Søk etter utstyr...

Detaljer

Elsmart Brukerveiledning Nettmelding for Installatører

Elsmart Brukerveiledning Nettmelding for Installatører Elsmart Brukerveiledning Nettmelding for Installatører Nettmelding Brukerveiledning Generell 0.5.doc Side 1 av (26) Innledning Dette er den generelle brukerveiledningen til Elsmart Nettmelding. Denne veiledningen

Detaljer

Administrasjon av saker. - Redigere saker med standard mal

Administrasjon av saker. - Redigere saker med standard mal Administrasjon av saker - Redigere saker med standard mal Admin V3 September 2015 INNLEDNING... 3 HVA ER EN ARTIKKEL?... 4 FANE: INNHOLD... 4 Felter i en standard artikkel... 5 LAGE EN NY ARTIKKEL... 6

Detaljer

Brukerveiledning. Madison Møbler Nettbutikk

Brukerveiledning. Madison Møbler Nettbutikk Brukerveiledning Madison Møbler Nettbutikk 1 1. Forord 1.1 Produktet Produktet er i denne manualen nettbutikken www.madison-mobler.no. Dette er en nettbutikk som skal gi brukerne mulighet til å handle

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet

Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet Innholdsfortegnelse Innlogging...3 Forside...4 Menyen...4 Oversikt over utstyret...5 Rediger utstyr...6 Opprett

Detaljer

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING 1 Word 1.1 Gjør ting raskt med Fortell meg det Du vil legge merke til en tekstboks på båndet i Word 2016 med teksten Fortell meg hva du vil gjøre.

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

WEBUTVIKLING OBLIG 4. Installasjon

WEBUTVIKLING OBLIG 4. Installasjon WEBUTVIKLING OBLIG 4 Installasjon 1. Jeg lastet ned MAMP gratis fra www.mamp.info og installerte på maskinen. Trykker så på Start Server og ser at det fungerer når Apache Server og MySQL Server lyser grønt.

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Brukermanual til PlanNET

Brukermanual til PlanNET Brukermanual til PlanNET Plandents nye netthandel Handle raskt og enkelt på www.plannet.no side 1 Innholdsfortegnelse Inlogging... 2 Startsiden... 3 Søke etter produkter... 3 Hurtigbestilling... 5 Produktsiden...

Detaljer

Brukerveiledning for Vesuv

Brukerveiledning for Vesuv Brukerveiledning for Vesuv Innhold Pålogging... 3 Registrering av ny bruker... 3 Glemt passord... 4 Startsiden... 5 Nytt utbrudd... 6 Nedtrekksmenyer... 6 Obligatoriske felt... 7 Spørsmål vises og fjernes...

Detaljer