HOVEDPROSJEKT Åpen. Telefon: Telefaks: Nettside for Amped on Nutrition. Eva Hadler Vihovde

Transkript

1 PROSJEKT NR. Studieprogram: Anvendt datateknologi og Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Nettside for Amped on Nutrition DATO ANTALL SIDER / BILAG 127 / 3 PROSJEKTDELTAKERE Mads Aune Dahlen Hussein Yusuf Abdi Ahmed Abdi Warsame Simen Johansen s s s s INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Amped on Nutrition KONTAKTPERSON May-Liss Urang SAMMENDRAG Nettsiden for Amped on Nutrition er en dynamisk nettside som inneholder informasjon og nyheter fra bedriften. Bedriften er et helsekostforretning og gjennom denne nettsiden har de nå muligheten for å selge deres varer direkte fra den integrerte nettbutikken som er utviklet. Bedriftens kunder kan med dette produktet registrere seg på nettsiden og handle alle varer de trenger. For bedriften er det nå mulighet for å oppdatere og vedlikeholde nettsiden på enkel og effektiv måte. 3 STIKKORD Nettside & administrasjon Nettbutikk HTML, PHP & CSS

2

3 INNHOLD I SLUTTRAPPORTEN Sluttrapporten inneholder følgende dokumenter og kan leses i følgende rekkefølge: Presentasjon Produktdokumentasjon Utviklingsdokumentasjon Prosessdokumentasjon Testdokumentasjon Brukerveiledning Kravspesifikasjon Ordforklaringer, vedlegg og kilder Presentasjon 1

4 Presentasjon 2

5 Presentasjon Forord Dette er en presentasjon av sluttrapporten for hovedprosjekt oppgaven skrevet av gruppe 2 ved Høgskolen i Oslo og Akershus, avdeling for ingeniørutdanning. Rapporten er et produkt av prosjektarbeid og utvikling av en webløsning. Prosjektet har vært et utfordrende og krevende arbeid, som har resultert i en komplett nettside og nettbutikk for vår oppdragsgiver og deres brukere. Vi ønsker å gi en stor takk til May-Liss Urang fra Statsbygg, som har vært vår eksterne veileder fra oppdragsgiver. Takk for alle dine gode råd og den tilretteleggingen du har gitt oss for dette prosjektet. Vi vil også gi en spesiell takk til vår veileder fra Høgskolen i Oslo og Akershus, Eva Hadler Vihovde. Du har gitt oss en veldig god veiledning gjennom hele prosjektperioden. Vi anbefaler at dette dokumentet leses i sin helhet før man leser videre på de andre del dokumentene i denne rapporten. Dette dokumentet beskriver gruppen, oppdragsgiver, bakgrunn og mål for prosjektet i sin helhet, samt gis det også en kort og oversiktlig presentasjon av sluttproduktet. Videre fra dette dokumentet anbefaler vi at man fortsetter med produktdokumentasjonen som beskriver hvordan produktet fungerer og er i sin helhet i dag, før man går videre til dokumentasjonen av utvikling og prosess. På slutten av denne rapporten foreligger den endelige kravspesifikasjonen, testrapport, brukerveiledning og kildehenvisninger. Presentasjon 3

6 INNHOLD Forord... 3 INNHOLD OM PROSJEKTGRUPPEN OG ANSVARSOMRÅDER Prosjektgruppen Gruppens medlemmer Ansvarsområder innad i prosjektgruppen OM OPPDRAGSGIVER Oppdragsgiver Bedriftens bakgrunn MÅL OG RAMMEBETINGELSER SLUTTPRODUKTET... 8 Presentasjon 4

7 1 OM PROSJEKTGRUPPEN OG ANSVARSOMRÅDER 1.1 PROSJEKTGRUPPEN Prosjektgruppen består av totalt fire studenter. Vi er tre stykker fra Anvendt Datateknologi, og en fra Informasjonsteknologi. Gruppen ble dannet på grunnlag av godt samarbeid gjennom de siste tre årene i forskjellige fag. Alle i gruppen kjenner godt til hverandre og hvordan alle arbeider i et prosjekt. Dermed ble det et enkelt valg å danne en hovedprosjekt gruppe sammen. 1.2 GRUPPENS MEDLEMMER Navn Studentnummer Studielinje Hussein Yusuf Abdi S Anvendt Datateknologi Mads Dahlen Aune S Anvendt Datateknologi Ahmed Abdi Warsame S Informasjonsteknologi Simen Johansen S Anvendt Datateknologi 1.3 ANSVARSOMRÅDER INNAD I PROSJEKTGRUPPEN Prosjektets områder er som følgende: Utvikling del 1 (HTML og CSS: Nettsiden og Administrasjonsside for ansatte) Utvikling del 2 (PHP: Nettbutikk og andre funksjoner) Utvikling del 3 (Database: MySQL) Design o Nettside o Administrasjonsside o Databasemodellering Presentasjon 5

8 Dokumentasjon o Forprosjekt o Kravspesifikasjon o Prosessrapport o Produktrapport o Brukermanual o Testrapport Ansvarsområde Utvikling 1 (HTML og CSS: Nettside & Adminside) Utvikling 2 (PHP: Nett og admin side funksjoner) Utvikling 3 (Database) Design Dokumentasjon Navn Mads Dahlen Aune Hussein Yusuf Abdi & Ahmed Abdi Warsame Hussein Yusuf Abdi & Ahmed Abdi Warsame Simen Johansen Alle 2 OM OPPDRAGSGIVER 2.1 OPPDRAGSGIVER Bedriften vi skriver hovedprosjekt oppgave for heter Amped On Nutrition. Bedriften er en helsekostforretning som er lokalisert på Quadra Island, utenfor Vancouver i Canada. Bedriften ble etablert i 2004 av Barbara Mindell, som i dag forsatt er eier. I dag driver Barbara Mindell butikken sammen med hennes svigerdatter Anette Grundvig fra Norge. De spesialiserer seg på salg av økologisk mat og velvære produkter, samtidig importerer de og selger Janus ull fra Norge. Ved siden av alt dette arrangerer bedriften også diverse kurs, som for eksempel matlagning. Presentasjon 6

9 2.2 BEDRIFTENS BAKGRUNN Amped on Nutrition har i dag en veldig statisk nettside som består av kategorier med produkter, informasjon om lokasjon og kontaktinformasjon. Bedriften ønsker å utvide nettsiden med netthandel og gjøre den mye mer dynamisk, dette er da på grunnlag av stor etterspørsel fra deres kunder. Det bedriften ønsker i hovedsak er en dynamisk nettside som tilbyr visning av alle produkter, visning av nyheter og tilbud og en nettbutikk integrert i nettsiden. De ansatte i bedriften har også lite IT-kunnskaper og trenger hjelp med vedlikehold og oppdatering av nettsiden og dens data. Derfor er det i tillegg behov for utarbeidelse av gode og enkle brukermanualer for enkle administrasjons oppgaver som redigering av produkter, priser, nyheter, tilbud og annet informasjon på nettsiden. 3 MÅL OG RAMMEBETINGELSER På Quadra Island i Canada er Amped on Nutrition en kjent butikk. Behovet for en nettbutikk, en moderne nettside, som er dynamisk og tilbyr bedriften et ansikt på internettet, er nødvending og stort. Det som er ønskelig for dette hovedprosjektet er å utvikle nettopp dette, og det finnes krav og betingelser til utviklingen av både nettsiden, nettbutikken og administrasjonssiden for de ansatte. Hovedmålet er å gjøre butikken enda mer tilgjengelig enn det den er i dag, og tilby brukere en mulighet for å handle via internettet. Sentrale mål for oppgaven er å utvikle en nettside som inneholder informasjon om bedriften, produktene bedriften selger, kategorier av produkter, kontaktskjema, nettbutikk med betalingsløsning og en administrasjonsside hvor de ansatte kan utføre enkle oppdateringer på nettsiden. Presentasjon 7

10 4 SLUTTPRODUKTET Sluttproduktet er en webløsning, som består av en nettside med en nettbutikk. Webløsningen består først og fremst av en dynamisk nettside som inneholder nyheter fra bedriften, en nettbutikk med visning av alle produkter og produkt kategorier, registrerings side for kunder, og informasjon om bedriften samt kontaktinformasjon. Figur 1: Forside av nettsiden ( Når brukeren kommer inn til siden, blir han/hun møtt med de nyeste nyhetene fra bedriften, og et valg av de mest populære produktene. Videre fra her, kan brukeren gå til en nyhet, et produkt, nettbutikken, About Us seksjonen eller innlogging til brukerens egen brukerkonto. Figur 2: Forside av administrasjonssiden ( Andre del av sluttproduktet er administrasjonssiden for de ansatte som vedlikeholder og oppdaterer nettsiden. Dette er en side som de ansatte, de som har tilgang, kan logge inn til og administrere nettsiden med oppdateringer og endringer. For detaljert beskrivelse av sluttproduktet henviser vi leseren til produktdokumentasjon. Presentasjon 8

11 Presentasjon 9

12 PRODUKTDOKUMENTASJON DEL II AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Produktdokumentasjon 1

13 FORORD Produktdokumentasjonen inneholder en beskrivelse av Amped on nutrition. Her redegjør vi for alle delene av produktet vi har utviklet. Databasen, nettsiden/nettbutikken og administrasjons siden. Vi går inn i dybden på oppbygningen av det endelige produktet og dens virkemåte i dag. Vi skal se nærmere på hvordan strukturer og relasjoner i databasen er satt opp. Denne delen av dokumentasjonen er skrevet for en person som har inngående kunnskap om programmering og databasestrukturer. Ordspråket vi har brukt kan oppleves teknisk for leseren, derfor er det en forutsetning at leseren har kunnskap om teknologien. Ved hjelp av denne produktdokumentasjonen skal vedkommende få en inngående kunnskap om produktet som beskrives. Produktdokumentasjon 2

14 INNHOLD FORORD BESKRIVELSE AV PRODUKTET En beskrivelse av produktet Hva produktet er ment for NETTSIDENS OPPBYGGING & VIRKEMÅTE ADMINISTRASJON SIDENS OPPBYGGING & VIRKEMÅTE PROGRAMMERING & VERKTØY Programmeringsspråk verktøy DATABASE Arkitektur Datastruktur og relasjon Tabeller i databasen WEB-ARKITEKTUR Brukervennlighet Universell utforming Navigasjon og søk Søking Tilgjengelighet på flere plattformer SIKKERHET VIDEREUTVIKLING Produktdokumentasjon 3

15 1 BESKRIVELSE AV PRODUKTET Dette kapitlet gir en beskrivelse av produktet, hvilke deler det består av og hvem produktet er laget for. Kapitlet beskriver også hva hensikten med sluttproduktet er. 1.1 EN BESKRIVELSE AV PRODUKTET Produktet er en total nettside/nettbutikk løsning for en Canadisk helsekostforretning. Produktet har en nettbutikk løsning samt en administrator løsning. Hensikten med utviklingen av produktet er å opprette en løsning for arbeidsgiver som gjør produktene de selger og markedsfører mer tilgjengelig for en større gruppe potensielle kjøpere. Samtidig utvikle ett produkt som har en lang levetid og er enkel for arbeidsgiver å vedlikeholde. Produktet er utviklet i samarbeid med bedriftens kontaktperson i Norge. Kontaktpersonen har hatt en jevnlig dialog med oppdragsgiver. De har satt noen parametere på hvordan de vil at det endelige produktet skal fremstå. Med hovedvekt på at produktene de selger skal komme bedre frem, samt en nettbutikk løsning som gjør det enklere for dem med tanke på logistikk. Årsaken til dette er at bedriften i dag mottar bestillinger på epost og telefon. Hensikten med å lage en total-løsning er at kunden skal kunne gjøre alle de nødvendige operasjonene for å drive en dynamisk nettbutikk på egenhånd. Produktdokumentasjon 4

16 1.2 HVA PRODUKTET ER MENT FOR Nettsiden er først og fremst en plattform for å øke salget på produktlinjen de annonserer. Vi har bygget opp nettsiden slik at kundene lett skal kunne finne de produktene de er på jakt etter. Vi har også lagt vekt på å få synliggjort promoterte og populære produkter. Forsiden gir en god oversikt over hva bedriften har å tilby. Videre har vi laget en utvidet søkefunksjon som er tilknyttet databasen. Her kan kundene spesifisere sine søk slik at de finner de varene som de ønsker å kjøpe. Man kan også søke innenfor flere kategorier. Varene blir hentet fra databasen og kunden kan videre legge de i sin egen handlekurv. Brukeren har en profil som blir opprettet slik at man kan få tilgang på sin egen kjøpshistorikk. Brukergrensesnittet er laget med ett moderne design som fremstår rent og pent. Slik at brukerne skal ha en god oversikt. Produktene er presentert med både bilder og informasjonstekst. I tillegg til en butikk er det også en nyhetsportal som blir styrt av oppdragsgiver, dette holder brukerne oppdatert rundt emnet og gjør siden mer dynamisk. Brukeren kan også bruke sosiale medier som er koblet opp mot siden til å dele informasjon fra siden. Produktdokumentasjon 5

17 2 NETTSIDENS OPPBYGGING & VIRKEMÅTE Dette kapitlet gir en beskrivelse av hvordan nettsiden er bygd opp og hvordan den skal fungere. Figur 1: Forside av nettside Nettsiden er bygd opp slik at produktene er i fokus. Når brukeren kommer inn på forsiden vil han bli presentert med de promoterte produktene. Hvert produkt vil ha en link til en side med mer informasjon om produktet og en knapp som viser pris, og ved å trykke på denne knappen legges produktet rett i handlevognen. Vi har valgt å gjøre det slik at uansett hvor brukeren ser et produkt på nettsiden, så skal det være mulig å legge dette produktet i handlevognen uten å måtte navigere videre. Vi har observert at på en del nettbutikker, så må man ofte klikke seg inn på selve produktet for å kunne legge det i handlekurven, men vi vil at kunden skal kunne legge produktet i handlekurven med en gang han ser produktet han ønsker. Produktdokumentasjon 6

18 Figur 2: Menyvalg på nettsiden I menyen på toppen har vi få linker. Disse linkene beskriver godt hvor de fører til. Mange nettbutikker har et hav av linker i menyen som ofte kan gjøre at brukeren blir usikker på hvor han må klikke hen for å komme dit han vil. For eksempel i vår meny så har vi "Store", som forteller brukeren at han kommer til selve nettbutikken. Ved å klikke på "Store" kommer brukeren inn på en ny side hvor han får oversikt over alle produktene og kan filtrere på kategorier eller søke. Alle sidene som hører til "Store" er likt utformet slik at det skal virke sømløst for brukeren. Brukeren vil ikke ha en forskjellig side hvis han for eksempel søker eller filtrerer på kategori. Brukeren vil ha en side som viser de produktene etter brukerens kriterier og som brukeren kjenner igjen og vet hvordan han skal navigere. Figur 3: Store (nettbutikken) Produktdokumentasjon 7

19 Figur 4: Om bedrift siden på nettsiden Hovedfokuset til nettsiden skal være å selge produkter, men siden Amped on Nutrition også har en fysisk butikk som tilbyr andre tjenester har vi valgt å synliggjøre butikken ved å legge til et stort kart på bunnen av hver side som viser hvor butikken holder til. Man kan også få mye informasjon om hva Amped on Nutrition tilbyr, hvem de er og kontaktinformasjon på "About Us" siden. Figur 5: Dashboard s (kundekonto) hovedside Produktdokumentasjon 8

20 På nettsiden har kundene et eget område kalt dashboard hvor de kan se alle sine ordre og få detaljer om disse. For eksempel hvilke produkter de har bestilt og status på ordren. Her kan de også endre sin kundeinformasjon, epost og passord. For å få tilgang til kundens dashboard må kunden registrere seg. Under headeren på høyre side har kunden hele tiden tilgang til sin handlekurv. Her står også det totale beløpet som de har handlet for. Ved å trykke på "View cart" kommer kunden til handlekurven sin og kan se produkter som de har lagt til, pris, totalpris og antall per produkt. Man trenger ikke være logget inn for å få tilgang til handlekurven. Kunden kan også trykke på checkout for å gå rett til betalingssiden. Figur 6: Header som tillater visning av handlekurv Figur 7: Handlekurv Figur 8: Registrering og innlogging Produktdokumentasjon 9

21 3 ADMINISTRASJON SIDENS OPPBYGGING & VIRKEMÅTE Figur 9: Administrasjon oversikt Øverst har vi menylinjen som linker til de forskjellige delene av administrasjonssiden. Denne menylinjen er lik for alle sider på administrasjonssiden. Figur 10: Menyvalg på administrasjonssiden På forsiden finner vi en oversikt over de siste ubehandlede ordrene. Vi ser for oss at å administrere ordre kommer til å være hovedbruken av administrasjonssiden og valgte derfor å plassere dette på forsiden. Herfra kan brukeren gå direkte til en ordre for å se detaljer og endre status. Figur 11: Visning av de siste ordre på administrasjonssiden Flyten på de andre delene av administrasjonssiden er forholdsvis like. Man klikker seg inn på den delen man vil administrere, fra menylinjen, og får da opp en liste over elementer som tilhører den delen. For eksempel under nyheter får man opp en liste over alle nyheter og det samme gjelder for produkter også videre. Herfra kan man gå videre inn på hvert enkelt element for å se flere detaljer, endre eller slette. Produktdokumentasjon 10

22 Figur 12: Lag/Edit/Slett nyheter Figur 13: Lag/Søk produkter Administrasjonssiden er delt opp i flere deler, hvor hver del tar for seg en oppgave på siden. For eksempel nyheter. På denne delen av siden kan administrator lese, legge til, endre eller slette nyheter. Samtidig kan administratorer også legge til nye produkter under Products fanen. Prosessen for dette er veldig enkel. Administratoren trykker «New Product» og må da fylle inn det nye produktets informasjon som navn, pris, produktets brand og kategori samt en beskrivelse av produktet. Eksisterende administratorer kan også legge til nye ansatte som skal administrere nettsiden. Alt som blir lagt til eller endret fra denne administrasjonssiden, går direkte til databasen og om det blir gjort endringer i nyheter eller produkter så blir det også lagt til i nettsiden. Figur 14: Lag/Edit/Slett ansatte Produktdokumentasjon 11

23 4 PROGRAMMERING & VERKTØY Dette kapitlet gir en beskrivelse av hva slags programmeringsspråk vi har benyttet i utviklingen av webløsningen, samt hva slags verktøy vi har brukt til dette. 4.1 PROGRAMMERINGSSPRÅK Figur 15: HTML & CSS (WIKI) Nettsiden er bygd opp på forskjellige programmeringsspråk. Limet i nettsiden er PHP som holder alt sammen og serverer brukeren det den spør etter. PHP blir også brukt for all logikk på nettsiden som for eksempel å kalkulere total pris ut i fra pris og skatt. På front-end har vi brukt HTML og CSS (som i teorien ikke er programmeringsspråk) for å gi brukerne et pent og brukervennlig grafisk brukergrensesnitt. For å kode i CSS har vi brukt preprocessoren SASS. Vi har også brukt JavaScript for å få en bedre flyt i brukergrensesnittet og for å spare brukeren for noen page reloads. For eksempel når brukeren skal fjerne noe fra sin handlevogn så brukes JavaScript for å spørre brukeren om han er sikker på om han vil fjerne dette produktet uten å måtte navigere til en ny side som gjør det samme. For spørringer mot databasen bruker vi SQL. Figur 16: MySQL & PHP 4.2 VERKTØY For å spare litt tid og slippe å finne opp hjulet på nytt har vi brukt noen verktøy. Et av punktene i kravspesifikasjonen sier at nettsiden skal fungere på flere plattformer. For å få til dette har vi brukt et CSS rammeverk kalt Foundation som gir oss en rekke klasser for å styre høyde/bredde og antall elementer på en rad på forskjellige skjermstørrelser. Dette rammeverket beskriver vi mer i utviklingsdokumentet. Produktdokumentasjon 12

24 Siden PHP trenger en server for å fungere har vi brukt et standard oppsett, populært kalt WAMP/LAMP. Dette gir oss en Apache server, en MySQL database og installerer PHP. For å administrere databasen brukte vi PhpMyAdmin. Valget av program for å skrive kode var opp til hver enkelt student. Dette fordi man jobber mest effektiv ved å bruke det programmet man er mest vant med. Tre av studentene brukte NetBeans som er et IDE, mens en brukte SublimeText 2 som er en avansert tekst editor. 5 DATABASE Dette kapitlet beskriver oppbyggingen av databasen. Vi beskriver datastrukturen, relasjoner og tabellenes innhold. 5.1 ARKITEKTUR Tegningen nedenfor viser hvordan en tradisjonell n-tier webapplikasjon fungerer. 1 Figur 17: 1 Kilde for ovenfor tegningen: Produktdokumentasjon 13

25 Besøkende bruker en nettleser for eksempel Internett Explorer for å koble til nettsiden/nettbutikken via en HTTP (Hyper Text Transfer Protocol) som innebærer en forespørsel om å få koble til web serveren. Deretter prosesserer webserveren PHP kodene, som henter data fra databasen (MySQL i vårt tilfelle) og lager HTML av disse dataene som tilslutt sendes tilbake via HTTP til nettleseren (klient-siden). Klientsiden får da returnert tilbake webinnhold som CSS, JavaScript, bilder og HTML filer. 5.2 DATASTRUKTUR OG RELASJON Vår database er designet etter tredje normalform. Strukturen i databasen er utviklet slik at all data ikke blir avhengig av data som ikke er en del av en nøkkel. Dette valget ble gjort for å slippe at det skapes redundanser i databasen. Figur 18: DATABASE E/R MODELL Produktdokumentasjon 14

26 5.3 TABELLER I DATABASEN Databasen for nettsiden består av totalt 11 tabeller. Tabellene inneholder informasjon om produkt, kunder og ansatte. Disse er knyttet sammen der produkt er den som har flest relasjoner til resten av tabellene. Nedenfor følger det en beskrivelse av databasens tabeller. Product Denne tabellen består av 7 koloner: ProductID, ProductName, Price, Tax, Totalprice, BrandID, og Description. Tabellen inneholder en egen rad for et hvert produkt i tabellen. Enhver rad har sin unike primærnøkkel, som er ProductID i dette tilfellet. Deretter er tabellen koblet til brand tabellen som er fremmednøkkel i Product tabellen. Hvilke data som registreres for et produkt er for eksempel relatert til hvilket brand som produktet tilhører og dette bestemmes av fremmednøkkelen. Figur 19: Relasjoner database Produktdokumentasjon 15

27 Brand Brand tabellen består av kolonnene BrandID og Brandname, der BrandID er primærnøkkelen. Dette er relatert til hvilken brand produktet tilhører og dette bestemmes av primærnøkkelen. Tabellen er fremmednøkkel mot Product tabellen. Category Category tabellen består av kolonnene CategoryID og CategoryName. Tabellen Category inneholder alle mulige kategorier et produkt kan tilhøre. En kategori må ha en unik primærnøkkel og et kategorinavn. Primærnøkkelen er fremmednøkkel mot CategoryID i Products_Category. News Tabellen News er ment for at den skal lagre alle nyheter som blir publisert, den består av følgende attributter. NewsID (primærnøkkelen). Newstitle - tittelen til nyheten som er publisert. NewsContent fritekst. NewsDate datoen for når nyheten blir publisert. Products_category Denne tabellen består av to fremmednøkler ProductID og CategoryID. Denne er opprettet da ett produkt kan tilhøre flere kategorier. Orders Orders tabellen inneholder kundenes bestillinger fra nettbutikken, den består av følgende attributter. OrderID - (Primærnøkkel) OrderDate Dato for når produktet ble bestilt. Produktdokumentasjon 16

28 DeliveryDate - Datoen for når produktet leveres. PaidDate Dato for når produktet er betalt. CustomerID - (Fremmednøkkel) Hvilken kunde bestillingen tilhører. Status Viser ordrens status. OrderDetail OrderDetailID - (Primærnøkkel) Quantity Antall enheter av produkt. UnitPrice Prisen for en enhet av produktet. OrderID (Fremmednøkkel). ProductID (fremmednøkkel). Employee Employee er tabellen som inneholder data om administratorer. Attributtet EmployeePosition beskriver hvilke rettigheter denne administratoren har. EmployeeID - (Primærnøkkel) Firstname Lastname Password EmployeePosition Produktdokumentasjon 17

29 Customer Customer tabellen inneholder kundeinformasjon som epost, passord og andre nyttige data. CustomerID (Primærnøkkel) Firstname Lastname Phonenr Adresse Postalcode (fremmednøkkel) City Country Password - hash av passord Produktdokumentasjon 18

30 6 WEB-ARKITEKTUR Dette kapitlet beskriver hvordan vi har utviklet webløsningen med tanke på universell utforming, brukervennlighet, navigasjon og søk. 6.1 BRUKERVENNLIGHET I en tidlig fase i utviklingen ble vi enige om at brukergrensesnittet skulle utvikles med henhold til prinsippene i universell utforming. Valg av farger og kontraster var viktige faktorer for å oppnå brukervennlighet for fargeblinde. På dashboard-delen har vi valgt at menyvalget View Orders skulle liste ut alle bestillinger, i en tabell, utført av en bestemt kunde. Tabellen inneholder en liten presentasjon av ordrene med overskriftene OrderID, OrderDate og Status med en link til en side med flere detaljer om denne orderen, som kundeopplysninger, hvilke produkter bestillingen inneholder og en oppsummert totalsum av valgte produkter. 6.2 UNIVERSELL UTFORMING Vi har valgt en nøytral farge for nettsiden, både med tanke på layout, knapper og tekst, som har god kontrast og er passende for svaksynte og fargeblinde. Et av de viktigste målene ved utforming av en slik nettside med nettbutikkløsning er universell utforming. Da vi startet prosjektplanleggingen, ønsket vi å lage noe som alle ulike brukere kunne ha nytte av. Derfor bestemte vi oss for å lage en nettside som oppfyller kravene til universell utforming. Det var veldig mye vi måtte tenke på når vi utviklet nettsiden. Design, layout, plassering og størrelse på bilder, navigasjon og produktbeskrivelse var noe som vi måtte regulere etter kravene. Vi følte at det viktigste var at nettsiden skulle være oversiktlig, at det skulle gi brukeren en god opplevelse og at alle de forskjellige brukergruppene kunne få muligheten til å ta nettsiden i bruk. Produktdokumentasjon 19

31 Når vi startet på utviklingen av nettsiden, var vi fast bestemt på at den eneste måten vi kunne gjøre det enklere for brukeren/kunden var å forenkle lesbarheten, forenkle navigasjonen, kjøpe og administratorens prosessen. Spesielt når vi lager en informasjonsside integrert med nettbutikkløsning som består av produkter med bilder og beskrivelser. Vi bestemte oss derfor å lage en navigasjonsbar, som til enhver tid viser brukeren/kunden hvor på nettsiden han/hun er. Navigasjonsbaren er også lett å se, ettersom at vi plasserte den på toppen av siden. Vi valgte også å lage nettsiden etter det berømte F-mønstret, hvor kunden først legger merke til hoved overskriften og de ferskeste nyhetene også videre nedover til de promoterte produktene. Dette føler vi gir kunden en god oversikt over nettsiden. Med dette i ettertanke, føler vi at vi har oppnådd målene vi satte i planleggingsfasen om brukervennlighet og universell utforming. Det første utkastet 2 av nettsiden var ikke akkurat utviklet med mye tanke på brukervennlighet og universell utforming, og det fikk vi også tydelig beskjed om da vi presenterte nettsiden for oppdragsgiveren. I ettertid har vi gjort endringer for å forbedre dette. 2 Referer til utviklingsdokumentasjonen kapittel 1.2 Produktdokumentasjon 20

32 6.3 NAVIGASJON OG SØK Figur 20: Veiviser nettside Navigasjon på nettsiden er så enkel og tydelig at brukeren kan se hvor man er til enhver tid. For eksempel hvis man ser på et produkt, så kan man se i det venstre hjørnet under logoen på nettsiden, hvor man befinner seg og i hvilket kategori produktet tilhører. Produktets navn står også på navigasjonsbaren. Stien gir god lesbarhet og viser tydelig hvor på nettsiden man er SØKING Figur 21: Søkefunksjon nettside Nettsiden tar også høyde for søkefunksjonalitet både på nettsiden og admin-delen, der man skriver inn søkerordet og deretter får tilbake resultater med produkter eller en passende melding hvis den ikke fant noen produkter. Vi har tatt også høyde for filtrering av ordre på administrasjonssiden. Dette bidrar også til at de kan holde oversikt over hvilke måneder det er flest bestillinger. Figur 22: Filtrering av visning på produkter etter måned Produktdokumentasjon 21

33 6.4 TILGJENGELIGHET PÅ FLERE PLATTFORMER En nettside er avhengig av å fungere i flere nettlesere, men også blant nyere håndholdte teknologier som for eksempel smarttelefoner og tablets. Da man som regel er uvitende om hvilken nettleser eller plattform kunden besøker nettsiden fra, har vi tatt høyde for å tilpasse nettsiden til forskjellige skjermstørrelser. Nettsiden vår fungerer på samtlige av de største produktene fra Apple og Google (mobil plattformene som Android og ios) og de største nettleserne som Chrome, FireFox og Internet Explorer. Figur 23: Slik ser forsiden av nettsiden på en Iphone. Produktdokumentasjon 22

34 7 SIKKERHET Sikker sending av data og beskyttelse av private opplysninger om kunder var et viktig punkt under utviklingen av nettsiden. I begynnelsen av prosjektet, da vi diskuterte med vår oppdragsgiver, fikk vi beskjed om at bedriften ønsket en innloggingsside både for kunder og ansatte som skal administrere nettsiden. Disse delene av webløsningen måtte dermed sikres. Informasjon om disse funksjonene som vi utviklet for sikring av innlogging, kan vi av sikkerhetsmessige årsaker ikke oppgi i dette dokumentet, men disse kan ses i kildekoden under filene «Customer.class.php» og «functions.php». For kryptering av innlogging benyttet vi krypteringsalgoritmen BLOWFISH, med salt for å hashe passordet. For betalingsløsning valgte oppdragsgiver tilslutt med å bruke Pay-Pal. Pay- Pal er en kjent betalingsløsning for mange nettbutikker over hele verden, og fungerer i dag som en sikker betalingsløsning. Denne funksjonaliteten har vi ikke implementert, og dette forklarer vi mer om i neste kapittel om videreutvikling. 8 VIDEREUTVIKLING Dette kapitlet omhandler hvordan webløsningen kan videreutvikles. Vi vil i dette kapitlet beskrive hva vi ikke har hatt tid til å implementere i webløsningen, samt i hvilken retning og hva som kan videreutvikles. Fordi hele nettsiden er bygd opp på et fleksibelt rammeverk når det gjelder design, så er det enkelt å legge til nye moduler uten å ødelegge eksisterende design. Vi har også brukt objekt orientert programmering som gjør at man enkelt kan gå inn i en klasse og utvide funksjonaliteten. Ved videreutvikling av dette produktet ser vi for oss at på forsiden av administrasjonssiden kan være nyttig med noen moduler som viser kjøpsstatistikk og antall besøkende, i tillegg til de siste ubehandlede ordrene. Produktdokumentasjon 23

35 Det viktigste for en nettbutikk er at kunden får betalt, slik at butikken tjener penger. For at kunden skal få den beste opplevelsen og ville komme tilbake må betalingsløsningen være så problemfri som mulig. Det innebærer at den er enkel og at den støtter de betalingsløsningene kunden bruker. I fremtiden ser vi for oss at nettbutikken får støtte for flere betalingsløsninger enn Pay-Pal, som er den eneste planlagte betalingsløsningen. På grunn av mangel på tid, måtte vi nedprioritere noen funksjonaliteter på nettsiden. På sluttproduktet har vi valgt å ikke implementere Pay-Pal løsningen, dette er som sagt ikke en vanskelig løsning å implementere og nettsiden er lagt opp slik at det er enkelt å flette inn uten for mye arbeid. Vi har også valgt å ikke implementere produktbilder, dette er fordi det eksisterer mange produkter i produktlisten til bedriften, og dette arbeidet ville tatt for mye tid. For å forenkle dette arbeidet har vi opprettet en rad i produkt tabellen i databasen som er satt av til bilder, og i fremtiden kan dette lett implementeres. Sletting av brukerkontoer er heller ikke implementert i sluttproduktet, men dette er også en lett funksjon som kan legges til. I tillegg til dette eksisterer det noen små «bugs» på nettsiden, men vi har klart å produsere et produkt som inneholder alle ønskede krav fra oppdragsgiver og som vi selv er veldig fornøyd med. Alle bilder av nettsiden i denne rapporten, som vi bruker, kan vike fra sluttproduktet. Da noe funksjonalitet ble implementert ved enden av dokumentasjonsfasen. Dette gjelder hovedsakelig visning av nyheter, som i sluttproduktet er flyttet øverst på forsiden. I databasen er det også gjort endringer. Tabellene Commentary og PostalCode har blitt fjernet fra sluttproduktet. Produktdokumentasjon 24

36 Produktdokumentasjon 25

37 UTVIKLING DEL III AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Utviklingsdokumentasjon 1

38 FORORD I utviklingsdokumentasjonen redegjør vi for det tekniske aspektet ved nettsiden. Her skal vi forklare utviklingsprosessen rent teknisk som hvilke valg som ble gjort under designet og programmeringen av nettsiden, litt om hvilke rammeverk og biblioteker som vi har brukt og hvilke utfordringer vi støtte på underveis i utviklingen. Denne delen av dokumentasjonen forutsetter at leseren har inngående kunnskap om design og utvikling av nettsider. Ordspråket kan oppleves som teknisk så det vil derfor være begreper som leseren må ha kjennskap til for å få fult utbytte av dokumentasjonen. Utviklingsdokumentasjon 1

39 INNHOLD FORORD DESIGN Wireframes Forsiden Store Produktliste Produktvisning Mockup Kodet HTML og CSS Administratorpanelet Testing og redesign STRUKTUR I KILDEKODEN Klasser Mappestruktur RAMMEVERK OG BIBLIOTEKER Foundation jquery Google APIs FontAwesome Disqus UTFORDRINGER Programmering Databasen Design KRAVSPESIFIKASJONEN OG DENS ROLLE Endringer Samsvar mellom kravspesifikasjon og produktet Nettsiden Utviklingsdokumentasjon 2

40 1 DESIGN I dette avsnittet skal vi gå igjennom utviklingen av designet fra start til slutt og se på hvilke vurderinger og endringer som ble gjort underveis. Figur 1: Wireframes Utviklingsdokumentasjon 3

41 1.1 WIREFRAMES For å lage wireframes så har man flere forskjellige valg. Man kan lage tradisjonelle skisser med pen og papir, bruke et online skisse verktøy eller man kan gå for noe litt mer high end som Photoshop. Vi valgte å gå for det som ville gjøre jobben enklest og på kortest mulig tid og endte opp med å skissere alle sidene i Mockflow. Vi tenkte at vi ville gå for en litt mer utradisjonell nettbutikk. En blanding mellom informativ nettside og nettbutikk FORSIDEN Da vi fikk oppgaven og hadde et møte med oppdragsgiver fikk vi beskjed om at de ønsket en nettbutikk som ikke var som alle andre nettbutikker. Den måtte skille seg litt ut både på oppsett og farger. Vi lagde oss derfor en oversikt over hvordan de store og populære helsekostbutikkene så ut på nett. Både norske og utenlandske. Resultatet var at mange slike nettbutikker hadde en rotete navigasjonsmeny og veldig mange elementer på forsiden som gjorde det vanskelig å få oversikt på nettsiden. Derfor valgte vi å ha en litt roligere forside, med en banner som viser hvilken bedrift de har kommet til og en kort og presis navigasjonsmeny. Deretter vise noen av de mest populære produktene og så en nyhetsseksjon STORE Under «Store» tenkte vi hovedsakelig at brukerne skulle bli presentert med et sett med kategorier, som de kunne navigere seg videre inn på for å se produkter som ligger i den kategorien for å få en klar navigasjonsstruktur. Herfra skulle man også kunne søke etter produkter i en bestemt kategori eller i alle kategorier. Vi gikk senere bort fra denne ideen etter at vi testet og redesignet, som man kan lese mer om i kapitelet «Testing og redesign», fordi vi ikke fant det brukervennlig nok. Utviklingsdokumentasjon 4

42 1.1.3 PRODUKTLISTE På denne siden tenkte vi at brukerne skulle bli presentert med produktene, under den kategorien de valgte, i en liste. For hvert produkt ser man navnet på produktet, en kort beskrivelse og en knapp med pris på produktet og som vil legge produktet i handlekurven om brukeren klikker på den. Navnet på produktet er også en link til en side hvor man blir presentert med mer informasjon om produktet PRODUKTVISNING På produktvisningssiden tenkte vi at brukerne skulle bli presentert med et stort bilde av produktet og et sidepanel med pris, en knapp for å legge til i handlekurven og mulighet for å dele produktet på Twitter og Facebook. Under denne seksjonen er det et område hvor man får en mer detaljert beskrivelse av produktet og det er opp til administratorene hva de vil skrive om hvert produkt. Utviklingsdokumentasjon 5

43 Figur 2: Mockup av forsiden Utviklingsdokumentasjon 6

44 1.2 MOCKUP Etter at vi har fått med alle hovedelementene og funnet ut hvor og hvordan de skal plasseres så kan vi gå over til en mockup. Denne prototypen skal være mer avansert enn wireframing. I wireframing skal man ikke ta høyde for farge, form eller andre designelementer. I en mockup skal man gå ut i fra wireframes og legge til design på modulene og elementene. For å få en oversikt over synligheten og blikkfang er det vanlig at mockups er designet i grayscale. Elementer som skal være godt synlige er mørkere enn elementer som ikke er så viktige. Som man kan se av bildet over så er strukturen omtrent den samme som på wireframe. Alle knappene skal være godt synlig da det er disse som gir funksjonalitet til nettstedet og er viktige for at brukerne skal få gjort det de vil. I mockupen valgte vi også legge til noen flere elementer på forsiden. I footeren er vi plassert menyen til høyre og en knapp til venstre, som tar brukeren til Amped on Nutrition sin facebook side, samt et kart over Quadra Island. Vi valgte å ta med Facebook-knappen i footeren fordi det er et vanlig bruksmønster at man plasserer sosiale linker og tilleggsinformasjon i footeren og fordi vi så at de er veldig aktive på Facebook og at det da er naturlig at brukerne kan være interessert i å ta del i det. Utviklingsdokumentasjon 7

45 Figur 3: Første versjon av nettsiden Utviklingsdokumentasjon 8

46 1.3 KODET HTML OG CSS Når formen og plasseringen av elementene har tatt form gikk vi over til en prototype som vil si at vi skal designe det slik vi tenker at sluttproduktet skal se ut. Siden vi skal lage en nettside valgte vi å begynne å implementere dette rett i HTML og CSS. Vanligvis gjøres dette steget i f. eks Photoshop og implementerer designet i HTML og CSS når man er helt ferdig. Vi valgte å gå rett på HTML og CSS fordi vi har mer erfaring med dette enn Photoshop og fant ut at vi kunne spare tid uten at det fikk konsekvenser for designet. En annen grunn var at vi skulle bruke et CSS rammeverk for grid og da var det lettere å implementere designet rett i HTML og CSS enn å måtte legge opp griden fra bunnen av i Photoshop. Dette gjør det også enklere å flytte på eller endre elementer underveis da det ofte bare er å endre noen få tall i HTML klassene eller flytte noen tags, enn å flytte hele layers i Photoshop. 1.4 ADMINISTRATORPANELET Når vi utviklet administratorpanelet valgte vi å gå for en enkel og oversiktlig løsning ved å bruke elementer fra Foundation rammeverket som navigasjonsmenyen. Målet var å lage en så brukervennlig løsning som mulig og at det da ikke krevde så fancy design i motsetning til resten av nettsiden som skal lokke brukere og trenger mer «eyecandy». Ved å gi brukerne av administratorpanelet kun den funksjonaliteten de trenger og ingen overflødige input-felter minsker vi sjansen for feil og forvirring. Oppgavene er enkle og alle oppgaver som krever input fra brukerne har kun felter, med gode labels, for det som er nødvendig for å få utført oppgaven. 1.5 TESTING OG REDESIGN Etter å ha vist vår kodet prototype til oppdragsgiver kom vi frem til flere endringer som burde gjøres. Det vi fant ut på møtet var at fargene vi hadde valgt varierte veldig fra skjerm til skjerm og at fargeskjemaet vi hadde valgt ikke passet på nettsiden på eldre skjermer. Oppdragsgiver syntes også at banneret (se bildet i 1.2) tok for mye oppmerksomhet bort fra produktene. Vi valgte da å flytte dette banneret til «About us» siden hvor vi i ettertid ser at dette passer mye bedre. Utviklingsdokumentasjon 9

47 Siden fargeskjemaet vårt feilet valgte vi å gå for et mer trygt og elegant fargevalg som gir nettsiden vår et mer moderne uttrykk. Vi valgte også å kjøre et mer minimalistisk flatt design som er veldig inn for tiden. Mye av nettsiden ble rett og slett redesignet, men med samme struktur i bunn. Vi valgte å sette sammen kategorisiden og produktlistesiden til en side hvor man får en liste over populære produkter med et sidepanel hvor man kan navigere til en kategori og vil da få en ny liste med produkter fra den kategorien. Vi gjorde dette for å minske antall klikk før brukeren fikk opp en liste med produkter. Kategorisiden tok altfor mye plass og ble bare overflødig navigasjonsflyten. 2 STRUKTUR I KILDEKODEN I dette avsnittet skal vi vise hvordan vi har strukturert kildekoden vår og hvilke praksiser som er brukt. 2.1 KLASSER På back end har vi delt objektene på nettsiden inn i klasser som har ansvaret for det objektet. class Cart {} class Category {} class Customer {} class Employee {} class MenuItem {} class News {} class Order {} class Page {} class Product {} Utviklingsdokumentasjon 10

48 Figur 4: Illustrasjon av alle klassene Hvert objekt har en egen klasse som beskriver dette produktet og gir det funksjonalitet. Ved å samle objektene inn i klasser gjør vi det enklere for de som skal videreutvikle systemet og legge til mer funksjonalitet. Skal man f. eks legge til en ny funksjon for nyheter så vet programmereren at han må se i News klassen og gjøre endringer der. class News { public $id; public $title; public $content; public $date; public function construct( $id = null, $title, $content, $date = null) { $this->id = $id; $this->title = $title; $this->content = $content; $this->date = $date; } public function date ( $format) { $dt = new DateTime ( $this->date); return $dt->format ( $format); } public function getexcerpt() { return substr ( $this->content, 0, 140 ). ".."; } public function create() { /* */ } public static function delete ( $NewsID) { /* */ } } public function update() { /* */ } Figur 5: Utdrag fra News klassen Utviklingsdokumentasjon 11

49 Over kan man se metodene til News klassen. Alle klassene har en constructor metode som setter i gang klassen og passer på at klassen har de verdiene den skal. De fleste klassene har disse metodene: Create() Delete() Update() Som tar seg av oppretting, sletting og oppdatering av objektet i databasen. I tillegg har noen klasser sine egne metoder for å behandle data, som f. eks News klassen over som har en egen metode (getexcerpt()) for å lage et utdrag av nyheten. 2.2 MAPPESTRUKTUR På et nettsted kan det fort bli mange filer og det er viktig med en god mappestruktur for å holde oversikt. Vi har delt inn kildekoden til nettstedet i flere mapper som sier noe om hva filene er og blir brukt til. Mappestrukturen blir også brukt for å lage oversiktlige URLs. Figur 6: Mappestrukturen til prosjektet Utviklingsdokumentasjon 12

50 Under root har vi lagt alle filene som styrer de vanlige sidene, men siden både adminpanelet og dashboardet krever flere filer for å fungere har vi valgt å legge de i egne mapper. Dette gjør også at URLen blir lettlest noe som også er bra for SEO. Filer som brukes under produksjon, men som ikke skal være med i live versjonen legges under app. Dette er vanligvis filer som i seg selv ikke vil fungere live, men som genererer en fil som blir lagt i public f. eks SASS og LESS som gjør det lettere og skrive CSS men som må igjennom en preprocessor for å generere en CSS fil. Det kunne også f. eks vært CoffeScripts som er en preprocessor for javascript. Mappen inc inneholder alle filer som kun skal inkluderes og som ikke vil fungere på egenhånd som f. eks templates, eller views som de fleste kaller det nå til dags, og klasser. I denne mappen har vi også lagt database konfigurasjonsfilen og en functions.php som inneholder en håndfull nyttige funksjoner. I public legger vi alt som vi vil at skal være offentlig for brukerne som bilder, stylesheets og javascript. Hvis vi hadde noen dokumenter eller andre filer som brukerne kunne laste ned ville de også bli lagt her. 3 RAMMEVERK OG BIBLIOTEKER I dette avsnittet skal vi gå igjennom de rammeverkene og bibliotekene vi har brukt for å bygge nettsiden. 3.1 FOUNDATION Vi har valgt å bruke CSS rammeverket Foundation som er utviklet av Zurb. Dette rammeverket gir oss verktøy for å styre hvordan nettsiden skal se ut på forskjellige plattformer uten å måtte lage en helt egen nettside for mobil eller nettbrett. Foundation inneholder mange forskjellige elementer for å utvikle nettsider, men vi bruker hovedsakelig deres grid modul. Utviklingsdokumentasjon 13

51 Denne modulen gir oss en.row og.columns klasse samt noen klasser for å bestemme bredde på elementer. Denne gridmodulen er bygget på 12 kolonner som vil si at vi alltid vil ha tilgang til 12 kolonner uansett hvor bred eller smal skjermen til brukeren her. Hvis vi ser på «Store» på nettsiden så har den et sidepanel og et panel for hovedinnhold. <div </div> class="row"> <div <div class="medium-3 columns"></div> class="medium-9 columns"></div> Figur 7: Illustrasjon av Foundation rammeverket Som vi kan se av koden over så er sidepanelet 3/12 kolonner og hovedinnholdet er 9/12 kolonner. Vi har satt det slik at siden skal ha en maks bredde på 1000px og Foundation kalkulerer da ut hvor bred 1/12 er. Navnet på klassene som bestemmer bredde er består av to ting. Hvilken skjermstørrelse denne klassen har ansvaret for og hvor mange kolonner. Det vil si at man kan ha flere klasser som bestemmer bredde på et element. For å ta "Store" siden som eksempel igjen. Vi har bygd den opp slik at på skjermer større enn mobilskjermer så skal sidepanelet ta 3 kolonner og hovedinnholdet ta 9 kolonner, men hvis brukeren besøker siden fra en mobil så vil brukeren få en side hvor sidepanelet og hovedinnholdet er 12 kolonner (altså 100 % bredde) og de legger seg under hverandre. Figur 8: Desktop versjon til høyre, mobil versjon til venstre Utviklingsdokumentasjon 14

52 3.2 JQUERY jquery er et javascript bibliotek som gir oss noen gode funksjoner for å gi oss cross-browser funksjonalitet som f. eks eventhandlers. Nettlesere har forskjellige måter å implementere eventhandlers og jquery gir oss en funksjon som fungerer i alle browsere. Vi har brukt jquery for å passet på at javascriptene våre ikke kjører før hele siden er lastet slik at scriptet har tilgang til alle elementene på siden. Det brukes også for å skjule eller vise kategoridelen av sidepanelet og for å gi brukeren muligheten til å konfirmere at de vil slette et element. $(function() { $('.toggle-dropdown').on('click', function(event) { var ielm = $('i', $(this)); if(ielm.attr('class') == 'fa fa-chevron-down') { ielm.removeclass('fa-chevron-down').addclass('fa-chevron-up'); } else { ielm.removeclass('fa-chevron-up').addclass('fa-chevron-down'); } $(this).parent().find('ul').toggle(); }); }); event.preventdefault(); Figur 9: Funksjonen for å skjule og vise kategorilisten Her er et utdrag av funksjonen som skjuler eller viser kategoridelen i sidepanelet. Den bytter også klasse på elementet som bestemmer hvilken vei pilen skal vise. Skulle vi ha skrevet dette i vanilla javascript ville det blitt betydelig mer å skrive med tanke på at man må sjekke hvilken browser som kjører scriptet og bruke funksjoner deretter. 3.3 GOOGLE APIS For å vise kartet i bunnen av nettsiden har brukt et Google API kalt maps som gir oss funksjoner for å vise et interaktivt kart som er zoomet inn på det stedet vi vil. Vi har valgt å Utviklingsdokumentasjon 15

53 bruke dette i stedet for et bilde fordi det gir brukeren mulighet til å navigere rundt den posisjonen vi har satt og se det i forhold til der de bor. function initialize() { var advocado = [{"featuretype":"water","elementtype":"geom /*..*/ var mapcanvas = document.getelementbyid("map-canvas"), latlng = new google.maps.latlng( , ), mapoptions = { center: latlng, zoom:15, maptypeid:google.maps.maptypeid.roadmap, styles: advocado }, map = new google.maps.map(mapcanvas, mapoptions); } var marker = new google.maps.marker({ position: latlng, map: map, title: 'Amped On Nutrition' }); google.maps.event.adddomlistener(window, 'load', initialize); Bilde 10: Funksjonen for å vise Google Maps i footeren Her er funksjonen som starter kartet. Funksjonen setter noen variabler som f. eks koordinater, hva slags type kart, stil og hvilket element vi ønsker å feste kartet til. Så mates dette inn i noen Google funksjoner som gir oss et interaktivt kart. 3.4 FONTAWESOME FontAwesome er en icon-font som gir oss muligheten til å bruke vector ikoner som skalerer. Ikonene er baket inn i en font og derfor støttet av eldre browsere. Dette gjør også at vi kan sette farge og størrelse på fontene uten av det blir dårlig kvalitet. 3.5 DISQUS For å implementere kommentarer til produktene, valgte vi å gå for Disqus som er et rammeverk som tar for seg administrasjonen av kommentarer. Utviklingsdokumentasjon 16

54 4 UTFORDRINGER I dette avsnittet skal vi trekke frem hvilke utfordringer vi møtte under utviklingen av prosjektet og hvordan vi løste de. 4.1 PROGRAMMERING En av de største utfordringene vi hadde var å samkjøre kodingen til alle sammen og å legge inn det hver enkelt student hadde gjort til en stor løsning. Hovedsakelig jobbet det en student på en bestemt funksjon, men flere funksjoner kunne ha bruke samme klasse og det ble derfor en utfordring og slå sammen de forskjellige versjonene av klassen uten å ødelegge noe for noen. Vi hadde satt krav om at det skulle programmeres objekt orientert, men vi hadde ingen retningslinjer på hvilke mønstre eller programmerings paradigme vi skulle bruke så det kunne være store forskjeller i koden. Siden PHP er et så løst programmeringsspråk så finnes det tusen måter å gjøre en ting på. Utfordringen her var å endre kodesnutter slik at de var noenlunde like og fulgte et mønster. At vi hadde forskjellig kodestil har ikke noe å si for funksjonaliteten til nettsiden, men har mye å si for videreutvikling noe vi har måttet ta høyde for i prosjektet. 4.2 DATABASEN Tid har vært en stor utfordring i dette prosjektet. Når det gjelder databasen så fikk vi en liste med 283 produkter som vi skulle legge inn i databasen og tilsvarende med bilder. Det ble en utfordring å få lagt alle detaljene om disse produktene (med bilde) i databasen og vi bestemte oss derfor for kun å legge inn 70 produkter slik at vi hadde noe teste med uten at det tok for mye av vår tid som vi kunne bruke på andre viktige oppgaver. Resten av produktene fikk oppdragsgiver legge inn når prosjektet var ferdig. Utviklingsdokumentasjon 17

55 4.3 DESIGN Vi hadde også noen utfordringer med designet av nettsiden siden den skulle fungere på både desktop, nettbrett og mobil. Utfordringer her var plassen. Vi ønsket samme funksjonalitet på alle plattformene men f. eks å vise en kategoriliste på 22 kategorier tar veldig mye plass på en mobil siden elementene er stablet under hverandre. Vi ønsket også at denne listen skulle, som standard, være åpen på desktop og nettbrett, men lukket på mobil. Vi løste denne utfordringen ved å lage en kategoriliste som en accordion hvor man må trykke på «Categories» knappen for at listen med kategorier skal åpne seg på mobil. Foundation ga oss også noen hendige klasser som vi kunne bruke for å skjule listen som standard på mobil men vise den på desktop og nettbrett. 5 KRAVSPESIFIKASJONEN OG DENS ROLLE Kravspesifikasjonen har vært et viktig dokument for oss under dette prosjektet og har fungert som en veiviser. Innholdet av kravspesifikasjonen ble i størst grad bestemt av oppdragsgiver, og er et dokument som definerer prosjektets rammer og webløsningens funksjonalitet og utseende. Under forprosjektet og begynnelsen av utviklingsprosessen ble kravspesifikasjonen flere ganger endret og optimalisert, og grunnen til dette var hovedsakelig av at oppdragsgiver enten ønsket flere funksjoner i webløsningen, eller ønsket endringer i layout av nettsiden. Samtidig, jo lengre ut i utviklingsprosessen og jo tydeligere webløsningen vår ble for oppdragsgiver, dukket det opp flere ønsker om endringer i forhold til utformingen av nettsiden. Dermed var kravspesifikasjonen et dynamisk dokument gjennom hele prosjektperioden. 5.1 ENDRINGER Endringer som dukket opp under prosjektperioden var mesteparten av tilfellene i funksjonalitet og utforming av nettsiden. Disse endringene ble oppført i kravspesifikasjonen. Sammenhengende var det ikke veldig mange endringer, det oppsto som regel ønsker om småendringer etter møter med kontaktperson fra oppdragsgiver. Utviklingsdokumentasjon 18

56 5.2 SAMSVAR MELLOM KRAVSPESIFIKASJON OG PRODUKTET Det er en klar sammenheng mellom kravspesifikasjonen og sluttproduktet. Utviklingen av produktet var utviklet i lys av kravspesifikasjonen og de funksjonelle og ikke funksjonelle kravene satt av oppdragsgiver. Vi har oppnådd målene satt i kravspesifikasjonen i produktet og fullført alle funksjonelle og designmessige kravene i nettsiden og administrasjonssiden NETTSIDEN Kravene for nettsiden fra oppdragsgiver var en dynamisk nettside, som tilbyr muligheter for å legge ut nyheter, tilbud og annet nyttig informasjon på en veldig enkel måte. På sluttproduktets nettside er det nå mulig for oppdragsgiver å gjennomføre disse oppgavene som ble spesifisert i kravspesifikasjonen: Oppdatere nettsiden med nyheter/tilbud Endre priser Endre produktinformasjon Slette produkter Legge til nye produkter Se alle ordre Sette status på ordre For vanlige brukere/kunder er det nå mulig å gjennomføre disse oppgavene: Registrering Se alle produkter Kjøpe produkter Skrive kommentarer om produkter Skrive en beskjed til bedriften gjennom en kontaktskjema Administrere sine kjøp gjennom kunde Dashboard Endre kontoinformasjon gjennom kunde Dashboard Dette er kravene til produktet, og disse kravene ble utviklet i kravspesifikasjonen. I tillegg til disse funksjonelle kravene, tilfredsstiller produktet de ikke-funksjonelle kravene som omhandler Utviklingsdokumentasjon 19

57 Hele webløsningen skal være på engelsk Webløsningen skal være utformet i lyse delikate farger Logo skal ikke endres Brukerdokumentasjon for oppdragsgiver skal lages slik at de kan sette seg inn i administrasjonen av nettsiden Utviklingsdokumentasjon 20

58 Utviklingsdokumentasjon 21

59 PROSESSDOKUMENTASJON DEL IV AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Prosessdokumentasjon 0

60 FORORD Dette dokumentet forteller detaljert om vår arbeidsprosess gjennom hele prosjektperioden. Prosessdokumentasjonen er delt opp i fem hoveddeler: Planlegging og metode: Beskriver forholdene rundt planlegging av prosjektet og hvilke metoder vi har benyttet for å forenkle arbeidsoppgavene og tiden. Dette kapitlet forteller litt også om hva slags verktøy og teknologier vi har benyttet gjennom prosjektperioden. Kommunikasjon: Beskriver kommunikasjonen mellom alle gruppemedlemmer, med veileder fra HIOA, med veileder fra oppdragsgiver og med oppdragsgiver. Utviklingsprosessen: Tar for seg de forskjellige fasene av prosjektet, og beskriver veien fra konseptutviklingen til programmeringen av sluttproduktene. Kapitlet beskriver også hvilke utfordringer gruppen har møtt på. Avsluttende del: I denne delen summerer vi opp våre refleksjoner og tanker rundt prosjektet. Vi beskriver nytte av sluttproduktet for oss og for oppdragsgiver og samt læringsutbyttet vi har fått av dette prosjektet. Prosessdokumentasjon 1

61 INNHOLD FORORD Styringsdokumenter Risikoplanlegging Fremdriftsplan Kravspesifikasjon Smidig utviklingsmetodikk Verktøy og teknologi Whatsapp Trello Dropbox KOMMUNIKASJON Kommunikasjon i gruppen Kommunikasjon med intern veileder Kommunikasjon med ekstern veileder Kommunikasjon med oppdragsgiver UTVIKLINGSPROSESSEN Om utviklingsprosessen Forarbeid og forprosjektfasen Kunnskapstilegning Implementeringsfasen Designfasen Sprint Sprint Utviklingsfasen Sprint Sprint Dokumentasjonsfasen AVSLUTTENDE DEL Kommentarer fra oppdragsgiver Produktets verdi For Kunder For Oppdragsgiver For Gruppen - Læringsutbytte Konklusjon Prosessdokumentasjon 2

62 1 PLANLEGGING, METODE, VERKTØY & TEKNOLOGI Dette kapitlet omhandler planleggingen og metoder som vi har benyttet under prosjektet. Vi tar for oss hvilke styringsdokumenter som vi har benyttet, samt hvilke metoder vi har bygget prosjektet rundt. Vi beskriver også kort om hvilke styringsverktøy vi brukt. 1.1 STYRINGSDOKUMENTER Styringsdokumenter er nødvendige i et hvert prosjekt, og spiller en stor rolle som veivisere. Det kapitlet beskriver de forskjellige styringsdokumentene vi har benyttet underveis, samt valg av utviklingsmetode. 1.2 RISIKOPLANLEGGING Risikoplan er et dokument som beskriver forskjellig problemer og utfordringer som kan oppstå underveis, hva konsekvensen av disse er og hvordan disse skal håndteres. I begynnelsen av prosjektet utarbeidet vi ulike tiltak for de utfordringene og hindringene som mulig kunne oppstå og har forholdt oss etter disse gjennom prosjektet. For detaljert informasjon og innsyn til hele planen, se vedlegg 3.1 i dokumentet «ordforklaring, kilder og vedlegg». 1.3 FREMDRIFTSPLAN Fremdriftsplanen er et tids orientert dokument, som beskriver ulike aktiviteter, mål og milepæler som skal utføres og nås innen visse tider. Dette dokumentet ble laget i starten av prosjektet, under forprosjekt perioden, og har vært et viktig dokument som vi har jobbet etter. For mer detaljert informasjon og innsyn til hele planen, se vedlegget 3.2 i dokumentet «ordforklaring, kilder og vedlegg». Prosessdokumentasjon 3

63 1.4 KRAVSPESIFIKASJON Kravspesifikasjonen er et dokument som beskriver hvilke krav oppdragsgiver har til systemet. Dokumentet har fungert som en avtale mellom oss og oppdragsgiver og dermed blitt et viktig styringsdokument. Den inneholder viktige punkter for hva som må utføres og ofte også i hvilken grad det skal utvikles. Derfor har vi inkludert mange punkter fra kravspesifikasjonen inn i Scrum prosessen. 1.5 SMIDIG UTVIKLINGSMETODIKK I startfasen av prosjektet diskuterte vi innad i gruppen hvilke utviklingsmetoder vi skulle bygge prosjektet vårt rundt. Det å gjennomføre et prosjekt uten rammer for hvordan det skal utføres fører til uoversiktlige planer, aktiviteter og dårlige resultater. Prosjektoppgaven vår er en utviklingsoppgave hvor det er fastsatte krav til hvordan systemet skal se ut og hvordan det skal fungere, og i og med at oppgaven utføres for en oppdragsgiver regnet vi med at det kan dukke opp endringer i krav senere i utviklingsperioden. Det mest naturlige valget av metode for utvikling var smidig utvikling, med fokus på Scrum som prosjektmetode. Figur 1: Scrum prosess ( Prosessdokumentasjon 4

64 1.6 VERKTØY OG TEKNOLOGI Dette delkapitlet omhandler verktøy og teknologi. Vi beskriver her hvilke verktøy og teknologi vi har benyttet for kommunikasjon, organisering og planlegging WHATSAPP Whatsapp er en mobil applikasjon som er tilgjengelig for Apple ios og Andriod telefoner. Applikasjonen tillater gruppe-chat, hvor flere mennesker kan tekste sammen gratis over et wifi-nettverk. Vi brukte denne applikasjonen nesten hver eneste dag, da vi var fra hverandre. Vi brukte applikasjonen til planlegging av møtetider, sted og korte oppdateringer på arbeid som vi har gjort. Figur 2: WhatsApp logo TRELLO Trello er internettbasert web-applikasjon som tillater prosjektstyring og organisering for flere brukere. Vi brukte Trello for oppsetting av Scrum og Sprint tasker. Gjennom Trello fikk vi laget en god oversikt over backlogen, hvilke oppgaver som er i sprint og hvem som utfører hva til enhver tid. Figur 3: Trello logo Prosessdokumentasjon 5

65 1.6.3 DROPBOX Dropbox er en applikasjonen som tilbyr deling av filer over internett. Vi har brukt Dropbox til lagring og deling av dokumenter som vi har skrevet under prosjektperioden. Fordelen med å bruke dropbox er at det kan installeres på din egen maskin og dermed har man alle filene tilgjengelige til enhver tid. Figur 4: Dropbox logo 2 KOMMUNIKASJON Her beskrives hvordan kommunikasjonen fungerte mellom alle parter som har vært involvert i prosjektet, innad i gruppen, med intern veileder og oppdragsgiver. 2.1 KOMMUNIKASJON I GRUPPEN Vi som gruppe benyttet i hovedsak to metoder for kommunikasjon, mobil og pc. Mesteparten av kommunikasjon mellom hverandre når vi ikke var sammen på skolen gikk gjennom mobil applikasjonen WhatsApp. Gjennom denne mobilapplikasjonen lagde vi en gruppe chat, hvor vi kommuniserte daglig. På pc lagde vi en privat facebook gruppe. Gjennom disse to kommunikasjonsverktøyene delte vi ideer, spørsmål og diskusjoner gjennom hele prosjektperioden. I begynnelsen av prosjektet, på høsten, lagde vi også en internettside for prosjektet vårt. Denne ble brukt til oppføring av prosjektdagbok, og andre diverse dokumenter. ( Prosessdokumentasjon 6

66 2.2 KOMMUNIKASJON MED INTERN VEILEDER Eva Hadler Vihovde har vært vår intern veileder fra Høgskolen i Oslo og Akershus. Kommunikasjonen med henne har vært veldig god gjennom hele prosjektet perioden. Vi har hatt faste møter med Eva hver andre uke, der hun har gitt oss mange gode råd og veiledet oss riktig vei. 2.3 KOMMUNIKASJON MED EKSTERN VEILEDER Vår eksterne veileder har vært May-Liss Urang fra Statsbygg. May-Liss Urang har vært oppdragsgivers kontaktperson og den som har vært ansvarlig for administrering av deres nettside. Vi har hatt en veldig god dialog med May-Liss og har hatt jevnlig møter med henne for å vise frem våre ideer og løsninger. Utenom våre møter med May-Liss har vi hatt jevnlig kommunikasjon gjennom epost. 2.4 KOMMUNIKASJON MED OPPDRAGSGIVER Vi har ikke hatt kommunikasjon med oppdragsgiver direkte, men gjennom eksterne veilederen May-Liss Urang. Bedriften befinner seg i Canada og de har benyttet May-Liss som deres kontaktperson her i Norge, derfor har all kommunikasjon med oppdragsgiver gått gjennom May-Liss. Prosessdokumentasjon 7

67 3 UTVIKLINGSPROSESSEN I dette kapitlet ønsker vi å fremheve utviklingsprosessen av prosjektet. Vi beskriver her de ulike fasene av utviklingen. Fasene er delt inn i tre forprosjektet, implementeringsfasen og dokumentasjonsfasen. Fasene er satt opp i kronologisk rekkefølge, og bygger på fremdriften av prosjektet. 3.1 OM UTVIKLINGSPROSESSEN For å tydeliggjøre og gi enklere forståelse av vår utviklingsprosess, har vi satt opp prosjektet i ulike faser. Ved å dele opp prosjektet på denne måten, hjalp det oss med å få bedre oversikt over prosjektløpet med tanke på tid og hva som må utføres innen visse frister. Dette kapitlet inneholder mer detaljert beskrivelse av hver fase og hvordan disse fasene har utløpt for oss. 3.2 FORARBEID OG FORPROSJEKTFASEN I begynnelsen av prosjektet, en gang på høsten 2013, dannet vi sammen denne gruppen. Det var mer en selvfølge at vi fire skulle jobbe sammen i en gruppe på hovedprosjektet, ettersom vi har jobbet sammen på andre prosjekter gjennom studietiden her på Høgskolen. Det startet med at vi gikk gjennom mange ulike oppdragsgivere som Høgskolen listet ut og tok kontakt med flere av dem. Vi ble raskt enige om at vi ønsket å jobbe med en oppgave innen webutvikling, og oppgaven fra Amped on Nutrition virket meget spennende. Det førte til at vi sendte en forespørsel om et møte med kontaktpersonen for bedriften, og møtte med henne for å presentere oss selv og diskutere oppgaven. Etter dette møte fikk vi valget om å jobbe med dette prosjektet og vi sa gledelig ja. Vi signerte avtale om samarbeid med Amped on Nutrition tidlig på høsten, og med dette så hadde vi god tid til idemyldring og lage en prosjektskisse. Vi hadde fått en veldig god innføring om oppgaven av May-Liss Urang, og det førte også til at vi tidlig fikk ta fatt på prosjekt arbeidet. Vi fikk dermed levert prosjektskissen i god tid før fristen i desember. Prosessdokumentasjon 8

68 I januar startet arbeidet for fult, vi startet med jevnlige møter med vår intern og ekstern veileder. På denne tiden var vi avhengige av å ha tilstrekkelige møter med oppdragsgiveren, for å samle så mye som mulig informasjon om bedriften og hva de ønsket av oss. Etter masse informasjonsinnsamling fra bedriften, skrev vi en forprosjektrapport med fremdriftsplan og arbeidsplan samt et kravspesifikasjons dokument. Fra februar og ut våren jobbet vi dermed ut ifra disse dokumentene som vi leverte i startfasen av prosjektet KUNNSKAPSTILEGNING Prosjektet vårt krevde at vi måtte fordype oss mye innen web programmering og databasehåndtering. Disse fagene har vi tidligere hatt, så det var ikke helt ukjent for oss. En av oss på gruppen har hatt erfaringer med å lage nettsider, men ingen av oss hadde noen gang laget en nettside med nettbutikk, så dette var det nye området av kunnskap vi måtte tilegne oss som en gruppe. 3.3 IMPLEMENTERINGSFASEN Etter forprosjektperioden, kunne vi gå over til implementeringsfasen. Vi følte at vi nå hadde en god oversikt over kravspesifikasjon og et helhetlig bilde av hva som måtte utvikles av oss for å oppnå et godt resultat og møte forventingene fra oppdragsgiver. Implementeringsfasen besto av to deler, med totalt fire sprinter. Første del var en designfase, andre del var en utviklingsfase, og hver sprint varte i ca. 14 dager DESIGNFASEN Prosessdokumentasjon 9

69 Vi startet med designfasen først, hvor vi lagde utkaster og skisser til databasestrukturen med E/R modell, skissering av nettsidene (hovedsiden og aller dens undersider og administrasjonssiden) samt design av utseende av webløsningen. Alle design oppgaver ble lagt til i Scrum backlogen og kjørt i en sprint. Etter sprinten gjennomførte vi møter med oppdragsgiver for å vise frem arbeidet vi hadde gjort. Etter flere utkast av design løsninger og skisser kunne vi gå videre til neste fase av implementeringen, som var selve programmeringsdelen. Vi startet med å bygge opp databasen med alle dens tabeller og relasjoner, og la inn 70 produkter fra produktlisten vi hadde fått fra oppdragsgiver. Når databasen var satt opp, kunne vi gå videre til utviklingen av nettsiden og administrasjonssiden SPRINT 1 I den første sprinten, gikk mesteparten av arbeidet ut på kartlegging av de forskjellige delsystemene som skulle utvikles. Vi hadde i denne sprinten fem hovedoppgaver: Opprette database Skissere database tabeller og relasjoner Ferdig implementere databasen med alle tabeller og relasjoner Skissere nettsiden og dens undersider Skissere admin siden Dette var en viktig sprint for oss, fordi under denne sprinten fikk vi et bilde av alle ideene vi hadde. Det ga oss mer inspirasjon og motivasjon til jobbe mer med prosjektet. Alle oppgavene under denne sprinten ble fullført og vi fikk illustrert våre resultater til oppdragsgiver. Prosessdokumentasjon 10

70 Figur 5: Wireframe av nettside SPRINT 2 I den andre sprinten under designfasen omhandlet oppgavene mer om fysiske modeller, sammenknytting av database og nettsidene og de første utkastene til nettsidene. Oppgavene i denne sprinten var: Utvikle nettsiden i første utkast Utvikle adminsiden i første utkast Knytte databasen til nettsidene Designe layouter til nettsiden I denne sprinten var det ikke mye funksjonalitet som ble utviklet og dermed var det ikke behov for mye testing. Men, utseende av nettsiden var noe som var viktig for oppdragsgiver. De ønsket en nettside med delikate lyse farger. Vi designet dermed to forskjellige utkaster og viste disse frem til oppdragsgiver og fikk tilbakemeldinger om hvilke av de to som appellerte mest. Prosessdokumentasjon 11

71 Figur 6: Use Case Customer Prosessdokumentasjon 12

72 Figur 7: Use Case Administrator Prosessdokumentasjon 13

73 3.3.4 UTVIKLINGSFASEN Utviklingsfasen var den fasen som tok mest tid, men også den tiden som vi fikk gjort mest arbeid. Arbeids og fremdriftsplanen vi laget under forprosjektarbeidet kom til veldig stor nytte under utviklingsfasen. De dokumentene sammen med de oppsatte sprintene ga oss et oversiktlig bilde over hva vi har gjort og hva som gjenstår. Det bidro til mindre stress og bedre resultater. Ved å også ha «inkrementelle» leveranser å vise frem til oppdragsgiver, sparte oss mye tid for endringer på slutten av prosjektperioden SPRINT 3 I sprint 3 startet vi for fult med programmeringsdelen av webløsningen, og delen av webløsningen som skulle utvikles under denne sprinten var nettsiden, med alle dens undersider og funksjoner. Målet for sprinten var at det meste av funksjonaliteten for nettsiden skulle utvikles og implementeres. Dette er oppgavene vi fikk utført under denne sprinten: Utvikle forside Utvikle nettbutikk: o Legge til produkt i handlekurv o Fjerne produkt fra handlekurv o Øke antall av produkt i handlekurv o Søke blant produkter o Velg produkt fra spesifikt kategori o Betalingsløsning Utvikle kontaktskjema Prosessdokumentasjon 14

74 Utvikle Dashboard (Brukerportal): o Logg inn o Se alle ordre o Brukerdetaljer o Endre bruker epost o Endre bruker passord o Logg ut Etter at sprinten endte, hadde vi nå fått et fysisk produkt. Vi hadde noe som vi kunne vise frem til oppdragsgiver, og få deres tilbakemelding. Oppdragsgiver var veldig optimistisk og positiv engasjert i fremdriften av utviklingen på nettsiden. Vi utviklet nettsiden under denne sprinten nøye etter kravspesifikasjonen, på grunn av dette eksisterte det ikke store behov for endringer i funksjonalitet. Det var kun små endringer som vi måtte gjøre, og det var i form for farger og layout av nettsiden SPRINT 4 I fjerde sprint ble meste av arbeidet satt av til utviklingen av administrasjonssiden. Denne delen av webløsningen som vi skal levere til oppdragsgiver er en viktig del. Utformingen og forståelsen av denne siden måtte være så enkel som mulig, ettersom brukerne av siden ikke har stor erfaring med generell databruk. Administrasjonssiden funksjoner som måtte utvikles var: Lage bruker Logge inn Lage/endre/slette nyheter Lage/endre/slette produkter Prosessdokumentasjon 15

75 Lage/endre/slette kategorier Administrere ordre Etter sprinten hadde vi en nettside å vise frem til oppdragsgiver. Vi lagde en side som inneholder mye funksjonalitet, men som samtidig har et veldig enkelt design og layout slik at bruken er forståelig for brukergruppen. 3.4 DOKUMENTASJONSFASEN Siste fase av utviklingsprosessen gikk av til dokumentasjonen av prosjektet. På denne tiden hadde vi klart å bli ferdig med mesteparten av utviklingen av produktet og vi hadde ca. en måned til rådighet for dokumentasjon. Selve dokumentasjonsarbeidet var mye, og det var mange rapporter som måtte skrives. Heldigvis, hadde vi skrevet masse notater og ført mye informasjon inn i dagboken vår stort sett gjennom hele prosjektperioden. Det førte til at vi fikk en god oversikt over hva vi hadde gjort til hvilken tid. Dokumentasjonsfasen var en den fasen hvor alle jobbet med det samme arbeidet, tidligere under de forrige fasene delte vi oss ofte opp, fordi det var flere arbeidsområder og dermed ble det mer effektivt å dele opp arbeidet. I dokumentasjonsfasen fikk vi veldig gode råd fra vår interne veileder fra HIOA, og vi startet tidlig med å sette opp de forskjellige de ulike rapportene og deres innholdsfortegnelser. Dette gjorde at vi fikk et tydeligere bilde over hvordan sluttrapporten kommer til å se ut, samt hva som måtte skrives. Da vi startet å skrive lagde vi ulike utkaster til vår veileder fra HIOA, og fikk hver gang gode kritikk til hva som måtte endres og hva som måtte være med. På grunnlag av dette føler vi at denne fasen, som er en veldig viktig fase, gikk veldig bra for oss. Fasen ble ikke like stressende som vi forutså, og det har veldig mye å gjøre med hvordan vi som gruppe innledet arbeidet til denne fasen. Prosessdokumentasjon 16

76 4 AVSLUTTENDE DEL Dette kapitlet av prosessdokumentasjonen beskriver våre siste tanker og oppsummering. Vi tar for oss samarbeidet innad i gruppen, belyser oppdragsgivers tanker, produktets verdi og konklusjon. 4.1 KOMMENTARER FRA OPPDRAGSGIVER «Oppdragsgiver har testet produktet og kom med følgende kommentarer: Veldig lys og fin nettside. Kunne tenke oss noen flere bilder under About us. Ønsker nyheter plasser på toppen av siden. Veldig fint at de mest populære produktene vises foran på nettsiden. Nettbutikken er lett å finne frem i. Liker inndelingen med kategorier. Adminpanelet var enkelt å bruke. Lett å legge ut nyhet, endre m.m. Men kunne godt tenke oss at det var mulig å legge til et bilde til en nyhet. Litt problemer med å legge ut nye produkter i nettbutikken da det ikke var mulig å slette eller endre på riktig måte, eller å opprette ny Brand eller Category når vi testet. Veldig fornøyd med det vi har sett så langt.» - Oppdragsgiver 4.2 PRODUKTETS VERDI FOR KUNDER Kundene eller brukerne av produktet er en av to parter av brukerområdet som har mest nytte av produktet, og de er også en sentral målgruppe. Vi har utviklet en nettside som er lett å forstå, lett å bruke, som er oversiktlig og brukervennlig. For en fremtidig kunde av denne webløsningen tror vi opplevelsen blir ganske bra. Vår hensikt var å utvikle nettbutikken på en slik måte at den blir lett å bruke og at kundene har en god oversikt over bedriftens varer og deres egne kjøp. Vi håper at produktet blir noe som kunder i fremtiden ønsker å benytte seg av og vi føler at vi har lagt det frem til at dette kan oppnås. Prosessdokumentasjon 17

77 4.2.2 FOR OPPDRAGSGIVER Før prosjektet hadde oppdragsgiver en statisk nettside, som kun tilbød deres kunder lett informasjon om bedriften, deres varer og kontaktinformasjon. Det var ingen mulighet for bedriften å selge deres varer over nettsiden, og deres nettside var lite interaktivt. Med dette produktet har bedriften en dynamisk nettside, som tilbyr et bedre innsyn til bedriften og hva de tilbyr. Nettsiden har ikke minst en nettbutikk, som gir bedriften muligheten for å ekspandere deres bedrift. Med produktet følger i tillegg en lettvint og forståelig administrasjonsside, som tilbyr bedriften en enkel måte å kontinuerlig oppdatere deres nettside med nye produkter og nyheter FOR GRUPPEN - LÆRINGSUTBYTTE For vår egen del har vi fått et stort læringsutbytte i form av dette prosjektet. Vår evne til å arbeide strukturert og organisert har økt som et resultat av utviklingen av dette produktet. Vi har fått erfaring med å jobbe og levere et produkt for en ekstern aktør og overholdt vår avtale med oppdragsgiver. I form for læringsutbytte av utvikling, har vi gjennom dette prosjektet gått i dybden og tilegnet oss enda mer kunnskap om webutvikling, med spesialisering innen for PHP, HTML og CSS. Vi har fått veldig mye bruk for forkunnskapene vi hadde i disse områdene gjennom tidligere fag, men samtidig har produktets verdi resultert i et større verdi for oss innenfor disse fagområdene av webutvikling. Prosessdokumentasjon 18

78 4.3 KONKLUSJON Samarbeidet i gruppen har vært veldig bra gjennom hele prosjektperioden. Det har oppstått tider hvor arbeidet har vært hektisk, men på grunnlag av vårt kjennskap til hverandre har vi klart å komme oss gjennom disse tidene ganske bra. Vi har tidligere jobbet sammen på gruppe under andre fag, og har dermed erfaring med hvordan hver enkelt jobber. Dette gjorde at vi mye lettere kunne planlegge og utføre prosjektet på en effektiv måte. Vi er veldig fornøyde med vårt arbeid og sluttproduktet som vi har utviklet sammen. Prosjektet har hatt en varighet på litt over et semester, og den tiden har gått veldig fort. Til tross for dette, når vi nå er ved vegs ende, føles det som om vi har vært gjennom alle tre årene. Vi har hatt veldig stor nytte for kunnskapene vi har tilegnet oss fra tidligere stadier av studiet, alt fra systemutvikling, prosjektplanlegging, programmering og design. Mest tilfredsstillende er det faktumet at vi har klart å oppnå målene som var satt i forkant av prosjektet, og vi er veldig tilfreds med både produktet, prosessarbeidet rundt utviklingen og vår egen utvikling. Prosessdokumentasjon 19

79 Prosessdokumentasjon 20

80 TESTRAPPORT DEL V AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Testrapport 0

81 Forord Dette dokumentet er ment for sensor, oppdragsgiver og veileder. VI anbefaler at leseren har gjort seg kjent med presentasjon og produktdokumentet. Ved kjennskap til disse dokumentene kan testrapporten leses selvstendig. Testrapporten beskriver de ulike testene som er gjennomført, hvordan disse ble utført og resultatene av disse. Testrapport 1

82 INNHOLD 1 Testing Test av kode Testbeskrivelse Funksjonstesting Kunde registrering Handlekurv Dashboard (Kunde konto) Integrasjonstesting Database Admin: Ordre Admin: News Admin: Employee Admin: Product Konklusjon... 8 Testrapport 2

83 1 Testing Formålet med testingen er å utelukke så mange som mulige feil med produktet, og være i stand til å levere et produkt som er sikkert og godt utviklet for videre bruk. Vi har gjennom utviklingen av produktet gjennomført små tester av funksjoner og integrasjon mellom backend og front-end. Utover i denne testrapporten skal vi fremlegge generell test av kode, test av funksjoner og integrasjonstest. 1.1 TEST AV KODE All programkode ble utviklet gjennom flere sprinter, og under disse sprintene ble koden testet i iterasjoner før sprinten kunne avsluttes. 1.2 TESTBESKRIVELSE Det som skulle testes her, var hele nettsiden det vil da si test av all HTML og CSS kode. Test av PHP funksjoner på nettsiden, og teste kode på administrasjonssiden. Testen ble gjennomført i flere nettlesere og forskjellige skjermstørrelser. All kode fungerte fint, utenom noen PHP funksjoner som vi beskriver nærmere under integrasjonstest (kapittel 3). Testrapport 3

84 2 Funksjonstesting Sluttproduktet består av mange funksjoner fordelt på to forskjellige nettsider og samspillet med en database i bakgrunnen. Nedenfor vil vi beskrive testingen av de viktigste funksjonene på nettsiden og resultatene av testen. 2.1 KUNDE REGISTRERING Krav Resultat Kommentar Bruker må legge inn fornavn Bruker må legge inn etternavn Bruker må legge inn epost OK OK OK Bruker må legge inn passord Bruker må legge inn adresse Bruker må legge inn postnr Bruker må legge inn by Bruker må legge inn land Når bruker har lagt inn alt ovenfor og velger Register skal brukeren lagres i kundedatabasen og få mulighet til å logge inn på kundesiden. OK OK OK OK OK OK Testrapport 4

85 2.2 HANDLEKURV Krav Resultat Kommentar Legge til et produkt i handlekurv Øke kvantitet Slette et produkt fra handlekurv Forsett handling av produkter med handlekurv i bakgrunnen. Handlekurven skal oppdateres også i bakgrunnen Søk gjennom Store og finn produkt OK OK OK OK OK Fungerer fint, men om bruker går bort fra store siden forsvinner handlekurv oversikten 2.3 DASHBOARD (KUNDE KONTO) Krav Resultat Kommentar Logg inn Se oversikt Se ordre Se brukerkonto informasjon Endre brukerkonto informasjon OK OK OK OK Endre epost Endre passord OK OK Slette brukerkonto FEIL Brukerkontoen kan ikke slettes permanent Logg ut OK Testrapport 5

86 3 Integrasjonstesting 3.1 DATABASE Databasens tabeller fungerer fint med integrasjonen med nettsidene. I noen av deler av databasen blir ikke innsatt rad og kolonner overført til nettsiden. Dette gjelder på produkter og bilder. Sletting av produkt var en del av feilene oppdragsgiver fikk da de testet. Denne feilen skal være rettet og fungere optimalt nå. Bilder til produkter har vi ikke fått til tid til å implementere i løsningen da dette ble nedprioritert på grunn av tid. Resten av databasen fungerer optimalt og databasespørringene gir riktig resultater. 3.2 ADMIN: ORDRE Krav Resultat Kommentar Se ordre oversikt OK Se spesifikk ordre detaljer OK Marker ordre som Pending OK Print ut ordre detaljer OK Filtrer ordre oversikt på måned OK Testrapport 6

87 3.3 ADMIN: NEWS Krav Resultat Kommentar Lag en nyhet OK Dato nyheten blir publisert på nettsiden oppdateres ikke hver gang Editer en eksisterende nyhet Slett en nyhet OK OK 3.4 ADMIN: EMPLOYEE Krav Resultat Kommentar Lag en ny ansatt OK Editer ansatt navn OK Editer ansatt posisjon OK Editer ansatt epost OK Slett ansatt OK Testrapport 7

88 3.5 ADMIN: PRODUCT Krav Resultat Kommentar Legg til et nytt produkt Endre produkt pris Endre produkt navn Endre produkt beskrivelse Slett produkt Legg til et bilde med produktet OK OK OK OK OK FEIL Fungerer ikke optimalt. Denne delen av utviklingen ble foretatt på slutten og dermed ble det ikke prioritert. Dette er mer forklart under utviklingsdokumentasjonen og videreutvikling i prosessen. 4 Konklusjon Testene ble gjort av oss under utviklingen av produktet, samt har vi fått hele nettsiden og administrasjonssiden testet av oppdragsgiver i Canada. Testene har bidratt til at vi har et sluttprodukt med få feil, men det eksisterer fortsatt noen små «bugs» og mangler i noen av funksjonene. Disse har vi valgt å nedprioritere ettersom omfanget og konsekvensen av dem ikke er stor. I videreutviklings kapittelet under prosessdokumentasjonen har vi beskrevet disse manglende i detalj, årsak til at de ikke er med i løsningen og hvordan vi har tilrettelagt for at de kan implementeres i videreutviklingen av produktet. Resultatene fra testene viste at ønsket funksjonalitet fra oppdragsgiver var godt utviklet og enkelt å forstå for de ansatte som skal vedlikeholde. Testrapport 8

89 Testrapport 9

90 BRUKERVEILEDNING DEL VI AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Brukerveiledning 0

91 Forord Brukerveiledningen er et hjelpemiddel oppdragsgiver kan bruke for å sette seg inn i bruk av administrasjonssiden. Her beskriver vi alle funksjonene administrasjonssiden tilbyr delt opp i kapitler. Hver funksjon har en steg for steg forklaring som har som mål å gjøre det enkelt for brukeren å bruke de enkelte funksjonene. Det er også bilder til vært av kapitelene, slik at brukeren skal kjenne seg igjen i funksjonen. Brukerveiledning 1

92 INNHOLD Forord INNLOGGING LOGGE INN OVERVIEW... 4 Få oversikt ORDERS... 5 Sende ordre... 5 Printe ordre... 5 Filtrere ordrer NEWS... 7 Legge til nyhet... 7 Slette nyhet... 7 Redigere nyhet EMPLOYEES... 9 Legge til ansatte... 9 Slette ansatte... 9 Redigere ansatte Products Søke produkt Redigere produkt Slette produkt Legge til produkt LOGOUT Brukerveiledning 2

93 1 INNLOGGING For å kunne administrere administrasjonssiden må man ha en bruker og ett passord. 1.1 LOGGE INN Steg 1: Skriv inn rett e-post og passord Steg 2: Trykk på login nederst i boksen Figur 1 Login ( Brukerveiledning 3

94 2 OVERVIEW Oversikten viser de siste ordreaktivitetene. Her listes alle ordrene opp. Videre kan man trykke på view. Da får man mer informasjon om den enkelte ordren. Få oversikt Steg 1: Scroll nedover siden, her har du en samlet oversikt over de nyeste ordrene som har kommet inn Steg 2: Trykk på view, dette valget er farget blått og er en snarvei til å få mer informasjon om hver enkelt ordre. Figur 2 overview ( Brukerveiledning 4

95 3 ORDERS Ordren har mange av de samme funksjonene som oversikten. Her kan man filtrere ut tidsrom på måned. Trykker man på April, så får man opp alle ordrene som er plassert i denne måneden. Her kan man også trykke på view, der finner man også mer informasjon om denne ordren. Sende ordre Steg 1: Trykk på View Steg 2: Trykk på Mark as sent øverst til høre på ordresiden Steg 3: Ønskes det en forandring på ordrestatusen Steg 4: Ønskes det å forandre på ordrestatusen trykkes det på Mark as pending oppe til høyre på den røde knappen. Printe ordre Steg 1: Trykk på view Steg 2: Trykk på print this page, dette er den blå knappen som befinner seg på høre side. Filtrere ordrer Steg 1: Trykk på ønsket måned eller år. Steg 2: Velg ordre ut i fra filtreringen Brukerveiledning 5

96 Figur 3 Order ( Figur 4 Order( Brukerveiledning 6

97 4 NEWS Her redigerer man nyheter som skal vises på nettsiden. Legge til nyhet Steg 1: Trykk på create news Steg 2: Legg til ønsket tekst i nyhets-boksen, tittel og innhold Steg 3: Trykk Create. Slette nyhet Steg 1: Trykk på delete nederst til høre i boksen. Steg 2: På spørsmål vil du virkelig slette nyheten trykk ja. Redigere nyhet Steg 1: Trykk edit nederst til høyre i nyhetsboksen. Steg 2: Oppdater ønskelig tekst i nyhets-boksen Steg 3: Trykk update når ønskelig tekst er oppdatert. Figur 5 News ( Brukerveiledning 7

98 Figur 6 ( Brukerveiledning 8

99 5 EMPLOYEES Her administreres info om de ansatte i bedriften. Som i forrige kapittel er det en delete og edit funksjon. Her slettes det en ansatte eller så redigeres informasjon om den enkelte. Den grønne knappen oppe til høyre hjørne brukes til å legge til eller fjerne ansatte. Legge til ansatte Steg 1: Trykk på den grønne knappen Add Employee Steg 2: Legg til ønsket informasjon og rettigheter til den ansatte Steg 3: Trykk på den blå create knappen nederst på siden. (Se figur nummer 7 ) Slette ansatte Steg 1: Trykk delete i den boksen den ansatte befinner seg i. Steg 2: Trykk OK når spørsmålet vil du virkelig slette den ansatte kommer opp. Redigere ansatte Steg 1: Trykk rediger i den boksen den ansatte befinner seg i Steg 2: Fyll ut eller bytt ut informasjon om den ansatte Brukerveiledning 9

100 Figur 7 Employees ( Figur 8 Add Employee ( Brukerveiledning 10

101 6 Products Søke produkt Steg 1: Lokaliser søkeboksen på høre side. Steg 2: Skriv inn ønsket søkeord. Søkeboksen generere alternativer basert på varer i databasen Steg 3: Sorter etter ønsket kategori ved å bruke listen tilhøre på siden. Steg 4: Trykk på ønsket produkt. Redigere produkt Steg 1: Trykk på ønsket produkt Steg 2 : Trykk på Edit nederst på siden Steg 3: Fyll inn ønsket informasjon, samt ønsket bilde-fil Steg 4: Trykk på update knappen,denne er blå og befinner seg nederst til venstre på siden. Slette produkt Steg 1: Velg produktet du ønsker å slette Steg 2: Trykk på den røde delete knappen Steg 3: Velg OK når du får spørsmålet vil du virkelig slette produktet Legge til produkt Steg 1: Trykk på den grønne knappen som heter new product Steg 2: Legg til øsnket informasjon samt den bildefilen som hører til produktet. Steg 3: Trykk på knappen som heter Create nederst på siden Brukerveiledning 11

102 Figur 9 Search product ( Brukerveiledning 12

103 Figur: 10 Update product ( Brukerveiledning 13

104 7 LOGOUT Steg 1: For å logge ut av adminsiden trykker man på logout øverst i høyre hjørne. Da blir man automatisk logget ut av siden og sendt til innloggingsboksen. Figur 11 Logout ( Brukerveiledning 14

105 Brukerveiledning 15

106 KRAVSPESIFIKASJON DEL VII AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP

107 FORORD Dette dokumentet inneholder retningslinjer for vår gruppe og beskriver betingelsene for utviklingen av vårt prosjekt «Nettside for Amped On Nutrition». I dokumentet er det beskrevet om de funksjonelle og ikke funksjonelle krav til utviklingen av prosjektet. Kravspesifikasjonen er skrevet i samråd med oppdragsgiver og inneholder kravene ønsket av oppdragsgiver, samt gruppens egne forutsetninger og mål med utviklingen av sluttproduktet. Kravspesifikasjonen skal brukes av gruppen som et styringsdokument, og eventuelle endringer underveis i prosjektet vil innføres i dette dokumentet. Dette dokumentet er beregnet i hovedsak for gruppen og oppdragsgiveren, men er også tilgjengelig for andre som ønsker innsikt i prosjektet og dens formål.

108 INNHOLDSFORTEGNELSE Forord PRESENTASJON Gruppens medlemmer Oppdragsgiver Kontaktperson VEILEDER HIOA BAKGRUNN LESER VEILEDNING SYSTEMBESKRIVELSE RAMMEVERK I SYSTEMET SYSTEMKRAV Funkjonellekrav Ønsket funksjonalitet Programvare og serverkrav Ikke Funksjonelle krav DELSYSTEMER KRAV... 8

109 1 PRESENTASJON Hovedprosjekttittel: Nettside for Amped On Nutrition Oppgave: Utvikle en nettside med integrert nettbutikk og enkle betalings, registerings, administrerings løsninger. 1.1 GRUPPENS MEDLEMMER Hussein Abdi Mads Dahlen Aune Simen Johansen Ahmed Abdi Warsame 1.2 OPPDRAGSGIVER Amped On Nutrition Plaza Rd. Box 337, Quathiaski Cove, Canada 1.3 KONTAKTPERSON May Liss Urang Statsbygg 1.4 VEILEDER HIOA Eva Hadler Vihovde Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus

110 2 BAKGRUNN Utvikling av ny nettside for Amped on Nutrition. Liten helsekost butikk utenfor Vancouver. Sitasjonen per dags dato er at bedriften mangler en nettbutikk løsning som fungerer samt et mer moderne grensesnitt på hjemmesiden. Hensikten med produktet er å utvikle nettbutikkløsningen slik at salget av produkter kan ekspandere og nå nye kunder. Hovedtrekkene ved denne oppgaven er å definere de kravene som er satt i forbindelse med prosjektet. 3 LESER VEILEDNING Kravspesifikasjonen skal være med på å forklare nettsidens og handelsløsningens mål og funksjonalitet. Vår gruppe skal følge kravspesifikasjonen som en veileder for å holde seg til innenfor de forhånd bestemte kravene, rammene og eventuelt oppfyll. Vi forventer at den skal fungere som en «rød tråd», og håper til som en rettesnor mellom gruppen og oppdragsgiveren om hva som skal gjøres igjennom hele prosjektperioden. 4 SYSTEMBESKRIVELSE Målet for oppgaven er å gi bedriften en mer moderne nettside med en nettbutikk løsning integrert i den nye nettsiden, slik at bedriften kan selge deres varer til kunder over nettet. Samtidig ønsker bedriften å gjøre seg selv mer synlig i markedet og trenger derfor en nettside som gjenspeiler bedriftens «image». Nettsiden bør inneha kontaktskjema og kunderegistrering slik at kunde kan registre seg automatisk og derfor kunne seg en unik logg fra sine handlinger. Det skal også utvikles gode brukermanualdokumentasjon som er tilpasset bedriftens ledelse og ansatte slik at de kan selv oppdatere og drive nettsiden etter vår utvikling er ferdig på egenhånd.

111 5 RAMMEVERK I SYSTEMET Oversikt over rammeverk i systemet: Skal kunne holdes vedlike uten å ha grunnleggende kjennskap til programmering Skal kunne utvides av andre på et senere tidspunkt Brukerhåndbok over systemet Engelsk språklig innhold Må fungere med nåværende server installasjon som krever PHP og MySQL Brukerne skal selv kunne legge ut, endre og slette nyheter og produkter 5.1 SYSTEMKRAV Denne delen beskriver kravene som er grunnlaget for nettstedet Amped on Nutrition som vi utvikler FUNKJONELLEKRAV Innloggingsmodul på alle brukerkontoer administrator (r, w, x) ansatte (r, w) og kunde(r) skal være beskyttet med kryptert passord. Løsningen skal ha en administratorside for å enkelt kunne legge til, redigere (tilgangsrettigheter) eller slette brukere. Løsningen skal ha en administratorside til å legge til, redigere, eller slette produkts data/bilder og kategori. Administratorsiden skal ha et grensesnitt, validerings funksjonalitet og hjelpetekst og tilpasset skjermstørrelser.

112 All data som skrives/føres inn via kontaktskjema, bestillingsskjema skal krypteres og valideres på klientsiden. Gode feilhåndtering og passende melding når uhell finner sted. En database som gir tilgang til å legge inn brukeres data, produkts data, kundes data, bestillinger og betalings data. Manualer for administrator og for brukere. All tekst på nettsiden skal være på engelsk språk. Nettsiden skal være i «lyse delikate farger» ØNSKET FUNKSJONALITET Nettsiden skal være brukervennlig og følger gode retningslinjer tankene i universell utforming. Brukerne skal til enhver tid vite hvor de befinner seg i nettsiden ved hjelp av brødsmulesti. Optimalisere søking. Nettsiden kunne vises i Sidemaps modus. Dynamisk oppdatering på handlekurven med JavaScript ved f. eks antall og total pris (pris*moms). Nettsiden skal være optimalisert for IE 9.0, og nyeste versjon av Apple Safari, Google Chrome og Mozilla Firefox PROGRAMVARE OG SERVERKRAV OOP PHP 5.6+ og MySQL. Server som støtter hovedsakelig PHP og MYSQL.

113 5.1.4 IKKE FUNKSJONELLE KRAV Administrasjons sidenes grensesnitt skal være tilpasset alle skjermstørrelser. Kildekoden skal være ryddig, strukturert, godt kommentert og gjøre det enkelt for videreutvikling. Nettsiden bør være uavhengig av plattform og bygges hovedsakelig på OOP PHP Nettsiden skal være optimalisert for IE 9.0, og nyeste versjon av Apple Safari, Google Chrome og Mozilla Firefox. Dokumentasjon og kildekoden kan være på norsk men nettløsningen må være på engelsk. Systemet skal utvikles med smidig utvikling (Scrum). Bedriftens logo skal ikke endres Bilder skal være representative for det som selges av produkter i butikken 5.2 DELSYSTEMER KRAV Adminpanel Kreve innlogging Adminpanel -> Forside Liste nyeste bestillinger Søke i alle bestillinger Legge til produkt Legge til nyhet

114 Statistikk Antall varer på lager Antall varer solgt Per mnd Uke År Adminpanel -> Nyheter Se alle nyheter Opprette nyhet Endre nyhet Deaktivere nyhet Søke blant alle nyheter Adminpanel -> Produkter Se alle produkter Se lagerbeholdning Filtrere på merke, pris og kategori Søke blant produkter Deaktivere produkt Endre produkt Endre lagerbeholdning Endre pris Legge til produkt Toppliste over mest solgte (produkt, kategori)

115 Adminpanel -> Bestillinger Søke på navn, epost, ordrenr Endre bestilling Slette bestilling Sette bestilling som (mottatt, plukket, sendt) Forside Liste de 5 mest populære produktene Liste 3 nyeste nyhetene Store Liste alle kategoriene Liste alle produkter Liste alle produkter etter filter (kategori, merke, pris) Vise lagerstatus per produkt Legg i handlekurv Produktside Liste produktinformasjonen Legge vare i handlekurv hvis vare på lager Brukerkommentarer Skrive kommentar Handlekurven Endre, slette varer Behandle kundeinformasjon (Navn, adresse, epost, telefon, betalingsopplysninger)

116 Bygge ordre basert på info om produkter, kunde og betalingsopplysninger og legge ordre til ordrelisten Nullstille handlekurv Systemfunksjoner Skal kunne liste produkter med pris (kalkulert ut i fra pris + moms) fra databasen Loggføre alle bestillinger Kreve innlogging til administrasjonspanelet Vise forståelige feilmeldinger ved feil Sikre integritet Holde styr på lagerstatus

117

118 Ordforklaring, kilder og vedlegg DEL VIII AMPED ON NUTRITION Nettside Nettbutikk HTML CSS PHP Ordforklaringer, kilder og vedlegg 0

119 FORORD Dette dokumentet er ment som et oppslagsverk for leseren. Her vil alle forklaringer på diverse tekniske ord finnes, samt en kildeliste. I tillegg er alle vedleggene for prosjektplanlegging og styring samlet her. Ordforklaringer, kilder og vedlegg 1

120 INNHOLD FORORD ORDFORKLARINGER KILDER VEDLEGG Risikoplan Fremdriftsplan Samarbeidskontrakt... 9 Ordforklaringer, kilder og vedlegg 2

121 1 ORDFORKLARINGER Tema MySQL SQL PHP HTML CSS MySQL WORKBENCH NETBEANS IDE JAVASCRIPT FOUNDATION N-TIER PRIMÆRNØKKEL Forklaring Databasespråk som er brukt i kodingen av databasen i Amped on Nutrition. Structured Query Language (SQL) er et programmeringsspråk brukt til å kommunisere med relasjonsdatabaser. Programmeringsspråket som er brukt i kodingen av funksjonalitetene til nettsiden og admin delen. HyperText Markup Language (HTML) er et markeringsspråk for formatering av nettsider. Cascading Style Sheets (CSS) er et markeringsspråk for å kunne endre design på websider. MySQL Workbench er en visuell database design verktøy og ble brukt til å konstruere databasen. Integrated Development Environment er programvare som tilbyr omfattende verktøy for programmering og programutvikling. JavaScript er et skriptspråk som er best til kjent til å tilføre visuelle utforminger til nettsider. Foundation er en gratis samling av verktøy for å lage websider og webapplikasjoner. Den inneholder HTML og CSS-baserte designmaler for typografi, skjemaer, knapper, navigasjon og andre grensesnittkomponenter, samt valgfrie Javascript-utvidelser. En n-tier programmet er en som er fordelt på tre eller flere separate datamaskiner i et distribuert nettverk. En primærnøkkel er det bestemte settet med attributter i en relasjon som er valgt blant relasjonens kandidatnøkler. FREMMEDNØKKEL HTTP En fremmednøkkel i en relasjon er et sett med attributter som opptrer som en primærnøkkel i en annen relasjon. HTTP tar seg av kommunikasjonen mellom en webserver og en nettleser. HTTP brukes for å sende forespørsler fra en webklient (en nettleser) til en web server, retur webinnhold (nettsider) fra serveren til klienten. Ordforklaringer, kilder og vedlegg 3

122 2 KILDER Tema Tradisjonell n-tier webapplikasjon arkitektur. Seven principles of design Kilde Produktdokumentasjon figur 17 Stone, Jarret, Woodroffe, Minocha, "User Interface Design and Evaluation", Elsevier Inc., Smidig utvikling PHP HTML CSS MYSQL SCRUM FOUNDATION Interactive Design Designing Interactive Systems, David Benyon, Second Edition Ordforklaringer, kilder og vedlegg 4

123 3 VEDLEGG 3.1 Risikoplan Hva kan være hindringer? Sykdom Tidsproblem (kapasitet) Missnøye/Uenigheter Utbrenthet Prioriteringsfeil Oppdragsgivers krav endres (-/+) Hva er konsekvensene og hvor stor er sannsynligheten for at disse risikoene oppstår? 1. Sykdom: Langtids sykdom: Sannsynlighet: Liten. Konsekvenser: Kan være store. Gruppen må endre ansvarsfordeling, og dette kan gi tapt tidsressurser. Kortidssykdom: Sannsynlighet: Moderat. Konsekvenser: Kan være varierte, ut i fra oppstart og varighet på sykdommen. Tapt tidsressurser. 1. Tidsproblem: Sannsynslighet: moderat. Konsekvensene: Gruppen får ikke tilstrekkelig tid til å utføre de planlagte arbeidsoppgavene, og til å nå de forskjellige målene. 1. Missnøye/uenigheter: Sannsynslighet: Lav. Konsekvensene: Dynamikken i gruppen kan bli endret, og dette kan påvirke resultatene til gruppen. 1. Utbrenthet: Ordforklaringer, kilder og vedlegg 5

124 Sannsynlighet: Lav. Konsekvensene: Dersom et gruppemedlem ikke meddeler at en er sliten eller mangler energi til å utføre oppgavene, kan det føre til at gruppen taper mye tid og det også kan føre til missnøye eller sykdom i gruppen. 1. Prioriteringsfeil Sannsynlighet: Moderat. Konsekvenser: Dårlige resultater, dårligere karakter. 1. Oppdragsgivers krav endres(-/+) Sannsynlighet: lav. ta vurdering til hvorvidt eksisterende implementasjoner er gjenværende. Ny planleggingsfase. Hvordan kan vi unngå/forebygge disse risikoene? Sykdom: Det gjelder å fordele ansvar så godt som mulig, dersom langtids-sykdom skulle oppstå må de andre gruppemedlemmene overta likt på det som går tapt. Ved korttids-sykdom gjelder det å si ifra i god tid, og de andre friske medlemmene må ta flere arbeidsoppgaver i den perioden sykdommen varer. Tidsproblem: Det er aldri lett å forutse hvor mye tid en må bruke på en oppgave. Dersom det skulle bli for mye å gjøre på en oppgave for et gruppemedlem eller for hele gruppen så må dette tas opp så fort som mulig i gruppen, slik at oppgavene kan omfordeles eller oppgavene kan deles opp til flere gruppemedlemmer. Misnøye/uenigheter: Viktig å ha klare roller og godt ansvarsfordeling. Kommunikasjon er en viktig nøkkel til suksess, samtidig har gruppen ordnet en samarbeidsavtale og denne må følges. Gruppen må vise respekt ovenfor hverandre, høre på andres meninger og ha forståelse for hverandre. Dersom dette ikke holder mål, må gruppen ta kontakt med lærer. Utbrenthet Viktig å vite at en jobber i en gruppe, det vil si at en må ta hensyn til andre. Ta godt vare på seg selv, spise godt og få nok søvn. Dersom en føler seg utbrent eller har mangel på energi/motivasjon, så må dette sies til gruppen så fort som mulig slik at, det ikke påvirker gruppens fremgang. Ordforklaringer, kilder og vedlegg 6

125 Prioriteringsfeil Det kan fort glemmes ting som må bli utført, og det er gruppens ansvar og dekke alle mulige aspekter ved prosjektet. Viktig med faste avtaletider og gruppemøter hvor det skal diskuteres fremgang i prosjektet, og gjennomgang av oppgaver som har blitt gjennomført og oppgaver som skal gjennomføres. Dersom for eksempel oppgaven med å dokumentere blir nedprioritert og dette «glemmes» må alle andre oppgaver nedprioriteres til denne oppgaven er fullført. Oppdragsgivers krav endres (-/+) Ha jevnlig kontakt med oppdragsgiver og oppdatere hvor langt utviklingsprosessen har kommet, og dermed gi rom for innspill for videreutvikling. Ha prioriteringer på funksjonaliteten og følge den. Ekstrafunksjonalitet som ikke er vesentlig kan ting med lav prioritet utelukkes fra prosjektet. Ordforklaringer, kilder og vedlegg 7

126 3.2 Fremdriftsplan Ordforklaringer, kilder og vedlegg 8