1. Problemformulering! 4 2. Mål for projekt! 4 3. Brugere af systemet! Deltagere i projektet! Uddannelse af brugere!

Transkript

1

2 Indledning Dette projekt gik ud på, at designe og udvikle en hjemmeside til en kunde, som havde et problem med deres hidtidige løsning. Der skulle hermed laves en rapport, som forklarede problemet bag den hidtidige løsning og hvad den nye løsning skulle kunne. Hertil skulle der derfor vælges en udviklingsmodel, som skulle følges og opbygningen af det nye system skulle dokumenteres. Indholdsfortegnelse 1. Problemformulering! 4 2. Mål for projekt! 4 3. Brugere af systemet! Deltagere i projektet! Uddannelse af brugere! Information til medarbejderene! 5 4. Valg af udviklingsmodel! 5 5 Foreløbig afgrænsninger! Mindmap! Context Diagram! Valg af kerne til hjemmeside! 6 6. Kravspecifikation! Medarbejderne! Brugervenlighed! Systemet! Vedligeholdelse! Økonomi! Sikkerhed! Kompatibilitet! Anskaffelse! 9 7. De første økonomiske overslag! 9 Sebastian Nyholm! HTX 3A! 2/39

3 8. Projekttidsplan! Gantkort! Milepæle! Analyse! Flowdiagram! E/R Diagram! Normalisering! Datadictionary! Konstruktion! Designfasen! Udviklingsfasen! Forklaring af kodning! Implementering! Test og afprøvning! Revision! Bilag! 31 Sebastian Nyholm! HTX 3A! 3/39

4 1. Problemformulering Køkto er en isenkræmmer og de har haft en stor tilbagegang i salget i den seneste tid, grundet den udvikling vi har i dag. Tidligere foretog folk deres indkøb i byen, men som tiden er gået, er internettet og webshoppene blevet mere og mere populære og har derfor tiltrukket en stor del af kunderne. Køkto er her blevet overhalet og de bliver derfor nødt til at få lavet en hjemmeside, så de kan begynde at komme ind på e-handlen og få deres kunder tilbage, for ellers kan de ikke forsætte med positive tal. 2. Mål for projekt Målet med projektet er at få lavet en hjemmeside og identitet til Køkto, så de kan komme ind på markedet igen og få deres retmæssige kunder tilbage. Underforstået skal Køkto altså efter en vis tid begynde at få overskud igen, så de ikke bliver nødt til at lukke ned. 3. Brugere af systemet Herunder kan de grupper af folk, som skal være med ind over projektet ses samt hvilke uddannelser brugerne skal have og hvilke informationer der skal strømme mellem medarbejderne. 3.1 Deltagere i projektet Systemudviklingen skal foregå i samarbejde med Køktos markedsføring, økonomiafdelingen, vareafdelingen, kunder og udviklerne bag hjemmesiden. Dette projekt vil derfor have en lille gruppe af personer, som hver i sær skal være med til at klare en given opgave. Markedsføringen skal være med til at lave en identitet og de skal kunne ændre tilbud og reklamer på hjemmesiden. Økonomiafdelingen skal holde styr på økonomien bag projektet og kunne udtrække fakturer fra databasen. Vareafdelingen skal kunne gå ind på hjemmesiden og oprette produkter. Afdelingerne skal derfor have lidt indsigt i hvordan siden fungere, men udviklerne bag hjemmesiden vil holde den ved lige. Til selve udviklingen af hjemmesiden, skal der også være nogle kunder, som kan afprøve systemets funktionalitet, da det er vigtigt, at det er nemt for brugerne at finde rundt på hjemmesiden, tilføje ting til indkøbskurven og købe dem. I dette projekt vil det dog være eleven selv der skal stå for det meste, da det er et skoleprojekt. Sebastian Nyholm! HTX 3A! 4/39

5 3.2 Uddannelse af brugere Køktos medarbejdere behøver ikke den store IT uddannelse for at kunne håndtere dette, men en forståelse af IT og simple koder kan blive nyttigt. Kunderne behøver ingen uddannelse, da det skal være en webshop. De skal dog kunne finde ud af at bruge nettet og betale online. 3.3 Information til medarbejderene Medarbejderne skal kende målet for projektet. I dette tilfælde er det en ny identitet og en hjemmeside til Køkto. Informationer mellem medarbejderne skal også være flydende og der skal være forståelse mellem de forskellige parter. 4. Valg af udviklingsmodel Da dette projekt omhandler både udviklere, Køktos ansatte og kunder og herunder deres teknologi, de opgaver de beskæftiger sig med, personerne og strukturen i firmaet, er der tale om, at projektet berøre alle fire berøringsflader i Leavitts model. Dette vil sige, at det er et forholdsvis stort projekt. Dette medfører at fasemodellen er blevet valgt som udviklingsmodel og herunder FAKIR-modellen, da der er en tidsbegrænsning på projektet. Man kan derfor ikke side og prøve sig frem, da det vil tage for lang tid og muligvis ikke ende op med noget sammenhængene. Der vil dog blive brugt lidt iterativt til programmeringen, da man her skal prøve sig frem, for ikke at fejle i koderne. En anden grund til at fasemodellen er blevet valgt er, at hjemmesiden skal testes af kunderne samt medarbejdere og fungere så den er nem og håndterlig at arbejde med. 5 Foreløbig afgrænsninger I det følgende vil man kunne se et mindmap og et context diagram, som giver en ide om, hvilke afgrænsninger der vil være i projektet og tilsidst vil der blive forklaret hvilken kerne hjemmesiden vil blive opbygget af. Sebastian Nyholm! HTX 3A! 5/39

6 5.1 Mindmap Mindmappet viser grundstrukturen over hjemmesiden og hvilke ting der regnes med vil blive implementeret i den. 5.2 Context Diagram I context diagrammet kan man se, at kunderne skal kunne foretage en bestilling. Hermed skal Køkto sende kunden en fakture, hvorpå kunden kan se ordren. Hvis Køkto ikke lægger inde med varen, skal de konktake leverandøren og lave en ordre der og leverandøren skal dermed sende en følgeseddel. 5.3 Valg af kerne til hjemmeside Projektet skal laves fra bunden af, da Køkto havde tænkt sig at begynde på en frisk. Dvs. at der ikke vil blive taget et eksisterende system, som bare skal tilpasses. Man kunne dog komme ind på CMS systemer, som f.eks. Magento eller Wordpress, da de giver en god, solid og håndterlig backend, men da dette projekt går ud på at udvikle sit eget, vil dette ikke tages i brug. 6. Kravspecifikation Herunder kan der ses hvilke krav, der vil blive stillet til produktet, som projektet ender ud med. Sebastian Nyholm! HTX 3A! 6/39

7 6.1 Medarbejderne Medarbejderne skal kunne håndtere hjemmesiden og databasen uden de store problemer. Der regnes med, at medarbejderne får et lille kursus til at lære dette. Medarbejderne skal herefter kunne lære de nyansatte, som kommer senere, at bruge hjemmesiden og databasen og lave de udtræk der er brug for. De medarbejdere som arbejder med hjemmesiden, skal ud over deres egen uddannelse, som har gjort, at de enten kan finde ud af økonomien eller sørger for varelageret, skal også have en forståelse af lidt IT. Dette har dog en minimalt indflydelse, da de får et lille begynderkursus i det de skal kunne. Det kan dog give problemer for medarbejderne i forhold til at beholde jobbet, hvis ikke de kan finde ud af det. 6.2 Brugervenlighed Da dette er en webshop, som handler med køkkenudstyr, vil den primære målgruppe være kvinder i alderen år. Denne målgruppe har normalt styr på de moderne medier og kan finde ud af at navigere rundt på hjemmesider og finde frem til det de søger. Kravende til hjemmesiden er derfor også, at den skal være nem at navigere rundt på og det skal være nemt at søge efter de produkter man leder efter. I den primære målgruppe må der derfor ikke forekomme de store problemer. Mænd i den samme alder eller unge skal også kunne klare disse krav, dog er de i anden række, i forhold til ændringer, da de ikke er den primære målgruppe. Ældre kunder skal helst også kunne klare det, men her er kravende ikke helt så høje, da de ofte ikke har helt så meget styr på de moderne medier samt at de også oftest foretrækker at handle i fysiske butikker. Navigationen og det at finde frem til måden man skal lede efter et produkt på, må ikke tage meget mere end 20 sekunder, hvis der arbejdes på det. Det regnes dog med, at dette vil tage omkring sekunder for den gennemsnitlige bruger. Hjemmesiden skal også være hurtig at lære. Dette skal gerne tage samme tid, som det øvrige. Hvis man har været væk fra siden længe, er kravende det samme. 6.3 Systemet Systemet skal fungere optimalt, uden store fejl. Alt dataudtræk skal være i orden, men de informationer, som priser og tekster, som er lagret i databasen, kan der forekomme fejl i, hvilket ikke vil være et stort problem, men det regnes dog med, at der er tjek på det alligevel. Sebastian Nyholm! HTX 3A! 7/39

8 Systemet skal være tilfredsstillende, i forhold til tilgængelig, hvilket betyder, at det skal have en oppetid på 97-99%. 6.4 Vedligeholdelse Når hjemmesiden er færdig, skal brugen af vedligeholdelse være minimal. Den skal dog optimeres med tiden, eftersom der kommer nye standarder. Vedligeholdelse af webserver og hostnavn sker hos en udbyder. 6.5 Økonomi Med hjemmesiden regnes det med at omsætningen stiger. Omkostningerne til hjemmesiden skal være minimale, hvilket også er grunden til at vedligeholdelsen skal være minimal. Webserver og hostnavn regnes ikke med at ændre sig, så dette vil bare være det årlige abonnement. De omkostninger der er i de kursuser, som medarbejdere skal have for at kunne håndtere hjemmesiden, skal også være små, da det gerne skulle være overskueligt at lære hurtigt og efterhånden skal medarbejderne også kunne lære de nye medarbejdere det, i stedet for at de skal have kursuser udefra. 6.6 Sikkerhed Der vil være en persondatapolitik, som indbefatter kundernes data. Den data der bliver lagret om dem, skal være i sikkerhed og må kun bruges af kunderne selv. Login-systemet hos medarbejderne skal også være sikkert, så her skal passwords krypteres, så de ikke kan blive opsnappet af uvedkommende. 6.7 Kompatibilitet Systemet skal være kompatibelt til diverse browsere, herunder Internet Explorer, Google Chrome, Firefox, Safari og Opera. Systemet skal også fungere, hvis browserne opdateres, men dette plejer normalt ikke at hindre hjemmesiden i at fungere. Hvis det skulle hindre siden i at vise noget korrekt, skal dette løses, ved hjælp af vedligeholdelse. Sebastian Nyholm! HTX 3A! 8/39

9 6.8 Anskaffelse Da hjemmesiden og identiteten bliver lavet af mig selv, vil der ikke forekomme noget udbudsmateriale eller indhentning af nogle tilbud. Forhandlinger vil der heller ikke være nogle af og kontrakten findes ikke. Implementering og test af hjemmesiden vil ske af mig selv og i givet fald nogle brugere. Andre øjne på produktet er her nødvendigt, da fejl og mangler skal findes og man ofte overseer noget selv eller ikke har sammen opfattelse af ting. 7. De første økonomiske overslag Til dette projekt er der beregnet en arbejdstid på 36 timer i skolen og 50 timer hjemme af en enkelt elev. Dette er til udarbejdelse af en rapport over projektet samt et færdigt produkt. Ud over elevens timer, skal der også være nogle ansatte i firmaet, som skal kunne bruge produktet. Det vil derfor sige, at der skal afsættes et par timer til de nødvendige ansatte, så de kan håndtere produktet uden at skulle have en livesupporter til rådighed. 8. Projekttidsplan Tidsplanen over projektet er blevet sat op i et gantkort samt et milepælsskema, så man kan følge fremgangen i projektet og se om det følger tidsplanen. 8.1 Gantkort Aktivitet Uge 6 Uge 8 Uge 9 Uge 10 Uge 11 Uge 12 Uge 14 Uge 15 Uge 16 Uge 17 Uge 18 Uge 19 Foranalyse 1 1 Analyse 2 2 Kravspecifikation 3 3 Systemdesign System- og brugertest Implementering 6 6 Test og aflevering 7 Revision 8 8 Sebastian Nyholm! HTX 3A! 9/39

10 1. Foranalyse går ud på at samle information om projektet og beskrive hvilke rammer der er. 2. Analyse går mere i dybden end foranalysen. Her kan der beskrives hvilke ting der er brug for og hvilke krav der er til det endelige produkt. 3. Kravspecifikation er der hvor man opstiller de krav der er til produktet. 4. Systemdesign er når selve produktet skal designes og laves. 5. System- og brugertest er når produktet skal testes for fejl og mangler samt om det er brugervenlig i den forstand om de kan håndtere det. 6. Implementeringen er når produktet skal implementeres i firmaet. 7. Test og aflevering er når det hele produktet skal testes og afleveres til Køkto. 8. Revisionen er når produktet har været i drift i en aftalt periode og det tages op til en diskusion. 8.2 Milepæle Planlagt sluttidspunkt Aktivitet Køktos hjemmeside Milepæle Uge 8 Foranalyse Skal være færdig Uge 9 Analyse Skal være færdig Uge 10 Kravspecifikation Skal være færdig Uge 16 Systemdesign Skal være færdig Uge 17 System- og brugertest Skal være færdig Uge 18 Implementering Skal være færdig Uge 18 Test og aflevering Skal være færdig Uge 19 Revision Skal være færdig Sebastian Nyholm! HTX 3A! 10/39

11 Udskriv søgningen til kunden Smid vare i kurv Kunde indtaster data IT Eksamen! 08/05/ Analyse Her vil ideer og diagrammer for hjemmesidens struktur blive dannet og forklaret, da det giver et grundlag for selve hjemmesidens opbygning. 9.1 Flowdiagram Kunde Søgning 1. Indtastning Søgekriterier 2. Sammenlign og print 3. Smid vare i kurv Kundeinfo Vareinfo Varer Ordre Ordre kommer i gang Kombiner 4. Sammenlign kundeinfo og kurv Kunde nr. Ordren bliver bekræftet eller sat i lkø alt efter om varen er hjemme Odren bekræftes sendt 6. Modtagelse af vare og opdatering Opdatering Vare tjekkes 5. Sammenlign varer og ordre ikke hjemme Bestil vare, hvis Odre skal tjekkes Solgte vare noteres Faktura af solgte vare Status Regnskab Liste af nye vare Leverandør 7. Modtagelse af fakture og indtastning Opdater Faktura I flowdiagramet kan man se hvordan alt data skal flyde rundt inde i systemet. Dette er dog kun et midlertidligt udkast, da det sandsynligvis vil ændre sig i løbet af designperioden. I denne skitse, vil en kunde begynde med at søge efter noget og derved vil søgningen og databasens ord blive sammenlignet og de steder hvor der er et match vil der blive printet noget på siden. Herefter kan kunden smide varen i kurven og søge igen. Når kunden køber varen, vil der blive tjekket om der allerede er en identisk kunde. Hvis tilfældet er ja, vil denne data blive hentet fra databasen og hvis tilfældet er nej, vil der blive oprettet en ny. Ordren vil herefter blive placeret i en ordre tabel, som skal kobles sammen med kunden og de vare der bliver købt. Mens dette sker, vil der også være en tabel, som holder styr på hvor meget der er blevet solgt af hver ting, så man ved hvad der er populært. Samtidig tjekkes der for om varerne er på lager og hvis dette ikke er tilfældet vil Køkto blive informeret om, at de skal bestille nogle vare hos leverandøren. Kunden vil herefter blive informeret om, at ordren er blevet sat i værks eller sat i kø. Sebastian Nyholm! HTX 3A! 11/39

12 9.2 E/R- & Datastrukturdiagram Ud fra ovenstående flowdiagram er følgende E/R diagram lavet: Her kan det første udsnit af E/R diagramet ses. Her kan man se, at det er en mange til mange kardinalitet, hvilket betyder, at der skal oprettes en relationstabel. Indtil videre vil der derfor være tre tabeller i alt. Hvis man indsætter nogle rækker i disse tabeller, vil det derfor komme til at se ud som følgende: I disse tabeller kan det ses, at hvis en kunde køber en vare, vil den blive linket via ordretabellen til den egentlige vare. fk_ står for foreign key, og betyder, at den hænger sammen med den oprindelige. Der opstår dog et problem her, hvis en kunde gerne vil købe mere end en vare, da der i dette tilfælde skal oprettes to ordrer, da en ordre kun kan indeholde et product_id. Der skal derfor laves en tabel yderligere. Det vil nu være muligt for en kunde at bestille mere end en vare pr. ordre og order_date og order_time er blevet taget med i orders tabellen, så man kan holde styr på hvornår ordren er lavet samt, så man kan finde den præcise ordre, når man skal oprette og opdatere de andre tabeller i forhold til ordren. Hvis man udvider varetabellen, vil den også få nogle flere rækker. Sebastian Nyholm! HTX 3A! 12/39

13 Her kan det ses, at product_brand og product_category er punkter, som gerne må indholde mere data, hvilket gør, at der vil blive oprettet tabeller til dem hver i sær. Der er en m-m kardinalitet mellem kategorier og vare, da en vare godt kan lægge under flere kategorier og en kategori godt kan have flere vare. Der er en 1-m kardinalitet mellem vare og brands, da en vare kun kan have et brand, mens et brand godt kan have flere vare. Her kan det ses, hvordan tabellerne skal designes. Her kan man se, hvordan brands- og kategoritabellerne blive koblet sammen. Grundet m-m kardinaliteten, bliver kategorier-vare lavet og grundet 1-m kardinaliteten, bliver brands koblet direkte sammen med vare. En sidste tabel der mangler at blive nævnt i dette emne, er den tabel der holder styr på hvor meget der er blevet solgt af hver ting. Den vil komme til at blive koblet sammen med varer-tabellen på følgende måde. Sebastian Nyholm! HTX 3A! 13/39

14 sold_pieces kolonnen kunne også være blevet optaget inden i varer-tabellen for at slippe for en tabel, men for at holde en adskillelse af informationerne er det blevet valgt at give den sin egen tabel. Der er også nogle resterende tabeller, men de er ikke koblet sammen med nogle andre. Dette forklares under systemdesign. En oversigt over alle tabellerne og deres relationer kan ses i bilag Normalisering Der er ikke meget normalisering at lave, da tabellerne allerede opfylder de fleste krav inden for dette. En tabel er på 1. normalform, hvis: Tabellen har en nøgle. Alle tabellens poster har det samme antal felter. Disse kriterier er opfyldt. I 2. normalform, fjerner man redundans, da redundans medføre at databasen fylder mere, besværliggør opdateringer og kan medføre inkonsistens i databasen. Inkonsistens er når data optræder forskelligt flere steder i databasen. På 2. normalform deler man derfor tabellen op i flere tabeller. Disse kriterier er også opfyldt, hvilket kunde og ordre tabellerne kan være et eksempel på. Hvis de to tabeller ikke var delt i to ville en kunde optræde flere gange i træk, for hver ordre kunden havde foretaget sig og dette ville medfører redundans, da de samme data ville optræde flere steder i databasen. For at en tabel er på 3. normalform skal tabellen være på 2. normalform og alle tabellens felter, som ikke er nøglefelter, må kun være afhængig af tabellens nøglefelt (id). Dette er også blevet gjort på flere af tabellerne, men i kundetabellen optræder postnr. og by navn, hvilket i realiteten afhænger af hinanden, men da kunder kan lave tastefejl, er det blevet valgt, at lade dem være uafhængige af hinanden, så ordren kan sammenlignes, hvis en tastefejl skulle ske. Sebastian Nyholm! HTX 3A! 14/39

15 9.4 Datadictionary Her kan ses, hvilke værdier alle rækkerne i tabellerne i databasens skal have. Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn admins Nr Relaterer til ingen Datanavn Datatype Format Egenskaber 1 admin_id INT auto++ Max 11 tegn 2 admin_username Varchar Max 55 tegn Unik Unik 3 admin_password Varchar Max 255 tegn Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn admin_menus Nr Relaterer til ingen Datanavn Datatype Format Egenskaber 1 admin_menu_id INT auto++ Max 11 tegn Unik 2 admin_menu_parent_id INT Max 11 tegn 3 admin_menu_title Varchar Max 55 tegn 4 admin_menu_link Varchar Max 255 tegn Sebastian Nyholm! HTX 3A! 15/39

16 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn brands Nr Relaterer til products Datanavn Datatype Format Egenskaber 1 brand_id INT auto++ Max 11 tegn Unik 2 brand_name Varchar Max 55 tegn 3 brand_description Varchar Max 255 tegn 4 brand_img Varchar Max 255 tegn 5 brand_link Varchar Max 255 tegn Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn categories Nr Relaterer til categories_products - products Datanavn Datatype Format Egenskaber 1 category_id INT auto++ Max 11 tegn Unik 2 category_name Varchar Max 55 tegn 3 category_description Varchar Max 255 tegn 4 category_img Varchar Max 255 tegn 5 category_link Varchar Max 255 tegn Sebastian Nyholm! HTX 3A! 16/39

17 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn categories_products Relaterer til categories - products Nr Datanavn Datatype Format Egenskaber 1 id INT auto++ Max 11 tegn 2 fk_product_id INT Max 11 tegn 3 fk_category_id INT Max 11 tegn Unik Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn customers Nr Relaterer til orders Datanavn Datatype Format Egenskaber 1 customer_id INT auto++ Max 11 tegn Unik 2 customer_name Varchar Max 55 tegn 3 customer_address Varchar Max 55 tegn 4 customer_zip INT Max 11 tegn 5 customer_city Varchar Max 55 tegn 6 customer_ Varchar Max 255 tegn 7 customer_phone INT Max 11 tegn Sebastian Nyholm! HTX 3A! 17/39

18 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn Relaterer til menus Nr Datanavn Datatype Format Egenskaber 1 menu_id INT auto++ Max 11 tegn Unik 2 parent_id INT Max 11 tegn 3 title Varchar Max 255 tegn 4 link Varchar Max 255 tegn Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn Relaterer til opening_hours Nr Datanavn Datatype Format Egenskaber 1 opening_hours_id INT auto++ Max 11 tegn Unik 2 days Varchar Max 55 tegn 3 time Varchar Max 55 tegn Sebastian Nyholm! HTX 3A! 18/39

19 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn orders Nr Relaterer til customers - orders_products Datanavn Datatype Format Egenskaber 1 order_id INT auto++ Max 11 tegn 2 fk_customer_id Varchar Max 11 tegn Unik 3 order_data Date 4 order_time Varchar Max 11 tegn 5 order_total_amount Int Max 11 tegn Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn orders_products Nr Relaterer til orders - products Datanavn Datatype Format Egenskaber 1 id INT auto++ Max 11 tegn 2 fk_order_id INT Max 11 tegn 3 fk_product_id INT Max 11 tegn Unik 4 order_product_pieces INT Max 11 tegn Sebastian Nyholm! HTX 3A! 19/39

20 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn products Nr Relaterer til orders_products - category_products - brands - sold Datanavn Datatype Format Egenskaber 1 product_id INT auto++ Max 11 tegn 2 fk_brand_id INT Max 11 tegn 3 product_title Varchar Max 255 tegn Unik 4 product_pieces INT Max 11 tegn 5 normalprice Varchar Max 11 tegn 6 saleprice Varchar Max 11 tegn 7 onsale Varchar Max 1 tegn 8 product_link Varchar Max 255 tegn 9 product_img Varchar Max 255 tegn 10 product_description TEXT Sebastian Nyholm! HTX 3A! 20/39

21 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn Relaterer til services Nr Datanavn Datatype Format Egenskaber 1 service_id INT auto++ Max 11 tegn Unik 2 parent_id INT Max 11 tegn 3 service_name Varchar Max 55 tegn 4 service_information TEXT 5 service_link Varchar Max 55 tegn 6 service_img Varchar Max 55 tegn Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn Relaterer til side_banner Nr Datanavn Datatype Format Egenskaber 1 side_banner_id INT auto++ Max 11 tegn Unik 2 side_banner_title Varchar Max 55 tegn 3 side_banner_img Varchar Max 255 tegn 4 side_banner_link Varchar Max 255 tegn Sebastian Nyholm! HTX 3A! 21/39

22 Systemnavn Dato Udført af Projektstyring uge 9 Sebastian Nyholm Tabelnavn sold Nr Relaterer til products Datanavn Datatype Format Egenskaber 1 sold_id INT auto++ Max 11 tegn 2 fk_product_id INT Max 11 tegn 3 sold_pieces INT Max 11 tegn Unik Hermed er alle tabellerne i databasen blevet lavet, i form af datatyper og rækker. 10. Konstruktion 10.1 Designfasen I designfasen blev logoet først designet, da det giver dem deres grundidentitet. Bilag 1 viser logoet. Denne identitet (farver, former, tekst, osv.) skal nemlig gå igen gennem hele deres hjemmeside, så det hele går op i en højere enhed og ikke bare er tilfældige farver der er smidt ind, hvor det nu så godt ud. Hjemmesiden er herefter blevet designet i photoshop og senere blevet implementeret på deres hjemmeside i form af html og php. Designet er dog kun retningslinjer for kodningen, da der oftest bliver foretaget små ændringer fra designperioden og til selve kodningen. I bilag 2, 3, 4 og 5 kan disse designs ses. Man kan se den grønne farve fra logoet går igen ved informationer, da denne farve er rolig og giver en naturlig fornemmelse. Den orange farve er ikke synlig på nogle af disse billeder, men den er blevet implementeret i koderne, så den optræder når et produkt er på tilbud. Denne farve repræsentere nemlig varme og energi og giver kunderne en lyst til at købe tingene. Den blå farve er brugt under kundeservice i få tilfælde, da den repræsentere troværdighed og pålidelighed. Her skal Køkto nemlig vise at de er en seriøs virksomhed og at det er sikkert at handle hos dem. Denne farve kan også først ses på hjemmesiden. Ud over det grafiske design er der også hjemmesidens struktur, som handler om, hvordan folk skal kunne bevæge sig rundt på hjemmesiden. Her er det nemlig vigtigt at man finder en overskuelig måde for folk at bevæge sig rundt på, så kunderne ikke bliver forvirret og Sebastian Nyholm! HTX 3A! 22/39

23 ender steder de ikke ønskede. Det er derfor vigtigt at der bliver lavet en retningslinje for, hvordan siden skal opbygges og hvilke sider der skal kobles sammen. På bilag 6 kan et diagram ses for den designede struktur. Tanken bag dette design var, at det skulle være nemt for brugeren at finde produkterne fra forsiden, så kunden får lyst til at handle der. Det skulle også være nemt at bevæge sig rundt på siden og ensformigt, hvilket er grunden til at toppen af alle siderne, også kaldet en header er identiske og indholder en fast menu. Samtidig skulle det også være nemt for kunden at finde informationer om Køkto og deres handlingsmåde under kundeservice, hvilket er grunden til, at bunden af hver eneste side, også kaldet en footer, har en menu med kundeservice, så man kan komme direkte til det ønskede, hvis man har spørgsmål, fra hvilken som helst side. Det er også blevet valgt, at næsten alt på hjemmesiden i form af billeder, tekst og links, skal være database udtræk. Dette er også grunden til, at der under E/R diagrammer, blev nævnt, at der også var nogle andre tabeller, som kunne ses i bilag 7. Grunden til dette er blevet valgt er, at man så ikke behøver gå ind i html en eller php en for at ændre en ting, men at det kan gøres ved brug af databasen Udviklingsfasen Til at begynde med, skal databaserne laves ud fra normaliseringens resultat og fyldes op med data. Efter dette skal hjemmesiden kodes. Her vil forsiden først blive lavet og generelt for alle siderne, vil de blive opbygget af <div> tags, som er små firkantede bokse, som man kan placere som man vil, ud fra et tilhørende stylesheet. Når disse bokse er placeret ordenligt, kan man begynde at indsætte tekster, billeder, priser osv. ud fra udtrak fra databasen. Hele denne opsætning sker ud fra de designs, som er blevet lavet af siderne. Der er dog ingen koder, som er blevet lavet på forhånd, hvilket gør, at man bliver nødt til at gå iterativt til værks, for at få det til at virke. Efter forsiden er blevet lavet, kan den deles op i tre separate dokumenter. En header, en footer og en indexfil. Headeren og footeren bliver lavet, da det skal gå igen på alle siderne og ved at lave separate dokumenter for disse, behøvede man ikke kopiere dem ind på de næste sider. Man kan her include dem i stedet i toppen og i bunden og derved spare en masse kodning. Indexfilen er det, som kan ses specielt på forsiden mellem headeren og footeren, ligesom alle undersiderne også vil have deres specielle indhold mellem headeren og footeren. Alle undersiderne kan herefter kodes, men her begynder man som nævnt, med at include headeren og footeren, hvilket gør, at man begynder med en allerede predesignet side, hvor indholdet mellem top og bund kun skal kodes. Dette gør, at man sparer en vis tid på Sebastian Nyholm! HTX 3A! 23/39

24 kodningen og ud over det, gør en header og en footer også, at designet vil være fast og ikke flytte sig eller ændre sig. Footeren vil selvfølgelig flytte sig lidt i højden, da alle siderne ikke har samme højde, men andre ændringer vil ikke kunne ske Forklaring af kodning På hjemmesiden er der en række sider, som alle indholder html, CSS og php. Alt kodningen vil derfor ikke blive forklaret, men lidt af hver slags vil blive forklaret, så man har en chance for at forstå det resterende. Først vil det mest brugte html blive brugt, da dette er nemmest at forstå. <div id= navn > </div> Denne tag laver en firkant, som nævnt tidligere og bruges til at bygge hjemmesiden op af. Man kan ved hjælp af et stylesheet, som er koblet sammen med dokumentet, nemt ændre størrelser, former og farver mm. på div en, hvis det ønskes. <ul>! <li></li>! <li></li> </ul> Denne tag bygges punkter op med. <ul> begynder punktrækken, mens <li> er den der laver hver enkelt punkt. Disse tags bruges også til at lave menuer med, hvilket bruges en del på siden. Man kan også style denne som det ønskes. For lige at se et eksempel på et stylesheet er her et uddrag fra en. #menu {! width: 711px;! height: 50px;! float: left; } #menu ul {! list-style: none;! float: right;! margin-top: 20px; } Sebastian Nyholm! HTX 3A! 24/39

25 #menu ul li {! float: left; } #menu ul li a {! color: black;! text-decoration: none;!! padding: 10px;! font-size: 16px; } #menu ul li a:hover {! padding: 10px;! background-color: black;! color: white; } Denne del af stylesheetet styler hovedmenuen på hjemmesiden, som lægger under en div kaldet menu. De resterende ting indenfor html en vil ikke blive forklaret her, da det er meget simple tags. Mere info om dem kan findes på Php en er den lidt mere indviklet del af kodningen, men her vil nogle uddrag fra siden blive eksemplificeret. <?php! // Start the session! session_start();?> Denne kode står i toppen af hver side. Den begynder enten en ny periode på hjemmesiden for den enkelte besøgene eller henter ældre oplysninger om den besøgene, som gemmes i form af cookies. På Køkto s hjemmeside bruges denne til indkøbskurven, så den husker hvilke varer der er i den eller til backenden, hvor den kan tjekke om man er logget ind eller ej. <?php! php include_once('inc/header.php');?> Sebastian Nyholm! HTX 3A! 25/39