1. No category

 Plutselig Webapp _____________________________________________________________________________________________________
Bachelorprosjekt 2015 _____________________________ Bernt Kristoffer Helland Jonas Myren Mo Torstein Frogner Vahid Khairkhah Side 2 PROSJEKT NR. 23 TILGJENGELIGHET: Offentlig Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo
Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Plutselig Webapp 24. mai 2015 ANTALL SIDER / BILAG PROSJEKTDELTAKERE INTERN VEILEDER Vahid Khairkhah [email protected] Torstein Frogner [email protected] Jonas Myren Mo [email protected] Bernt Kristoffer Helland [email protected] Ismail Hassan OPPDRAGSGIVER KONTAKTPERSON Pizza Plutselig Mansour Jam, 954 79 171, [email protected] SAMMENDRAG Plutselig Webapp, en webapplikasjon for pizzabutikken Pizza Plutselig. 3 STIKKORD CMS AngularJS Single page application Side 3 Forord Dette er sluttdokumentasjonen til gruppe 23 som består av Vahid Khairkhah, Torstein Frogner, Jonas Myren Mo og Bernt Kristoffer Helland. Produktet er en webapplikasjon som er et resultat av oppdragsgivers krav og ønsker. Vi vil takke Mansour Jam, oppdragsgiver, for muligheten vi har fått ved å få lov til å utvikle en webapplikasjon som forenkler hans utfordringer med nettsiden. Oppdragsgiver har gitt oss stort rom for valg av teknologi og for det er vi veldig takknemlige. Leserveiledning Gruppen har sitt beste å følge Høgskolen i Oslo og Akershus’ dokumentstandard med små endringer der det var hensiktsmessig. Rapporten er bygd på kapitlene kravspesifikasjon, prosessdokumentasjon, produktdokument- asjon, testdokumentasjon og brukerveiledning. Det er tatt hensyn til faglig språk slik at man ikke trenger stor teknisk innsikt for lesing av hoveddelene av rapporten, uten at det skal ha påvirking på forståelsen av de tekniske innholdet. For ikke å utelukke personer med større teknisk innsikt har vi tatt for oss kapittel 7, hvor vi forklarer nærmere den kodetekniske strukturen, litt om hvorfor vi har gjort som vi har gjort og oppbyggingen i webapplikasjonen. Vedlagt i den fysiske sluttrapporten er det en CD med komplett kildekode og anvisning til den kjørbare webapplikasjon. Oppsummering Pizza Plutselig er en pizza butikk som tilbyr henting og levering av pizza til private og bedrifter. Deres arbeidshverdag er å lage pizza for kunder som skal hente dem eller få dem utkjørt. Oppdragsgiver har fått nettsiden som presang fra et familiemedlem. Hver gang han ønsker å utføre endringer må han kontakte vedkommende for bistand, noe som er veldig tungvint og tidskrevende. Som ofte stemmer ikke prisene i nettsiden og butikken samt at nyheter i nettsiden ofte er utdaterte. Oppdragsgiver ønsker å kunne effektivisere endringer i nettsiden og samtidig ikke være en byrde for den tidligere utvikleren. Plutselig Webapp er en webbasert applikasjon utviklet for og i samarbeid med oppdragsgiver. Applikasjonen tar for seg de utfordringer og misnøyer oppdragsgiver har hatt og gir dem muligheten til innholdsendring som tidligere har vært personavhengig. Ved å bytte ut deres gamle nettside med en webapplikasjon har vi sammen med oppdragsgiver tro på at det vil gi arbeidshverdagen et løft. Side 4 Primærfunksjonene til applikasjonen ●
●
●
●
●
●
●
●
Opprette, se og endre priser. Opprette, se og endre kunder. Opprette, se, slette og endre nye pizza i menyen. Opprette, se, slette og endre nye tilbehør i menyen. Opprette, se, slette og endre nyheter. Opprette, se, slette og endre inforsider/navigasjonsmeny. Logge på med admin og utføre ønskede endringer som er nevnt i punktene ovenfor. Informere kunder om åpningstider, priser, leveranser og produkter. Side 5 Innholdsfortegnelse Forord
Leserveiledning
Oppsummering
Primærfunksjonaliteten til applikasjonen
Innholdsfortegnelse
Kapittel 1 - Kravspesifikasjon
1.1 Forord
1.2 Presentasjon
1.3 Bakgrunnen
1.3.1 Motivasjon
1.3.2 Funksjonalitet
1.4 Kort systembeskrivelse
1.5 Rammekrav i systemet
1.6 Funksjonelle krav
1.7 Ikke-funksjonelle krav
Kapittel 2 - Prosessdokumentasjon
2.1 Forord
2.2 Forberedelser og planlegging
2.2.1 Valget av oppgaven
2.2.2 Definere oppgaven og omfang
2.2.3 Finne riktig rammeverk
2.2.4 Oppstartfasen
2.2.5 Milepælsplan
2.3 Utviklingsverktøy
2.3.1 Microsoft Visual Studio Ultimate 2013
2.3.2 Dia.
2.3.3 Bitbucket
2.3.4 Trello
2.3.5 Dropbox
2.3.6 Notepad++
2.3.7 Testmiljø
2.3.8 Doxygen
2.3.9 Microsoft Word
2.3.10 Facebook
2.4 Utviklingsmetodikk
2.4.1 Innledning
2.4.2 Daglige utfordringer
2.4.3 Dagboken
2.4.4 Scrumbrett
2.4.5 Versjonskontroll
2.4.6 Møter med veileder
Side 6 4 4 4 5 6 12 12 12 13 13 13 13 14 15 19 20 20 20 20 21 21 21 24 26 26 26 26 26 26 27 27 27 27 27 27 27 28 28 29 29 30 2.4.7 Møter med oppdragsgiver
2.4.8 Gruppesiden
2.5 Kravspesifikasjonen
2.5.1 Forklaring
2.5.2 Endringer i kravspesifikasjonen
2.5.3 Samsvar mellom opprinnelig og endelig kravspesifikasjon
2.6 Fremdriftsplan
2.6.1 Innledning
2.6.2 Utviklingsfasene
2.6.3 Tidsberegning
2.6.4 Samspillet mellom fremdriftsplan og scrumbrett
2.7 Designutvikling
2.7.1 Utformingen av designet
2.7.2 Endelig design
2.8 Refleksjoner til produktet
2.8.1 Innledning
2.8.2 Ting vi ville gjort annerledes
2.8.3 Tverrfaglig utbytte
2.8.4 Veien videre
2.8.5 Nytteverdi for oppdragsgiver
2.8.6 Oppdragsgivers tilbakemelding
2.8.7 Oppsummering og konklusjoner
2.9 Risiko og svakheter
Kapittel 3 - Produktdokumentasjon
3.1 Forord
3.2 Beskrivelse av webapplikasjonen
3.2.1 Kort om
3.2.2 Byggeklosser
3.3 Sentrale datastrukturer i applikasjonen
3.3.1 Innledning
3.3.2 MVC
3.3.3 De sentrale modellene
3.3.4 Modellrelasjoner
3.3.5 Funksjoner og metoder
3.4 Lagdeling
3.4.1 Hvorfor lagdeling
3.4.2 Lagdeling i MVC
3.5 Programmets virkemåte
3.5.1 Oppstart av webapplikasjonen
3.5.2 Admin i nettleseren
3.5.3 Kundehandlinger i bruk
3.5.4 Spesifikke handlinger i bruk
3.6 Design
3.6.1 Innledning
3.6.2 Oppdragsgivers ønsker
Side 7 30 31 31 31 31 31 32 32 32 32 33 35 35 39 39 39 39 40 40 41 41 41
42 44 44 44 44 44 46 46 46 48 49 49 51 51 51 52 52 52 52 52 53 53 53 3.6.3 Brukergrensesnitt (UI)
3.6.4 Brukeropplevelse (UX)
3.6.5 Responsivt design (optimalisert for alle enheter)
3.6.6 Universell utforming
3.6.7 Rammeverk og teknologier tatt i bruk
3.7 Sikkerhet
3.7.1 Passordsikring
3.7.2 Databasesikkerhet
3.7.3 Backup og Rollback-plan
3.8 Systemkrav
3.8.1 Klient
3.8.2 Server
3.9 Samsvar mellom kravspesifikasjon og det ferdige produktet
3.10 Fordeler og ulemper med en skreddersydd applikasjon
Kapittel 4 - Testdokumentasjon
4.1 Forord
4.2 Enhetstesting
4.2.1 Formål med testen
4.2.2 Utførte tester
4.2.3 Gjenstående testing
4.2.4 Utforming av testen
4.2.8 Kjøring av enhetstester
4.2.9 Resultater og tiltak
4.3 Brukertest
4.3.1 Formål med testen
4.3.2 Utforming av testen
4.3.3 Resultater og tiltak fra test utført av potensielle kunder
4.3.4 Resultater og tiltak fra admintest utført av oppdragsgiver
4.4 Ad hoc-testing
4.4.1 Gjennomføring av testing
4.4.2 Resultater av testen
4.4.3 Konklusjon av testen
Kapittel 5 - Brukerveiledning
5.1 Forord
5.2 Terminologi
5.3 Innledning
5.4 Veiledningen
5.4.1 Bruker og admin
5.4.3 Administrasjon
5.4.4 For kunder
Kapittel 6 - Oppslag
6.1 Figurer
6.2 Tabeller
6.3 Bilder
6.4 Kilder
Side 8 54 54 54 54 56 56 56 56 57 57 57 58 58 58 60 60 60 60 60 60 61 64 64 66 66 66 67 68
68 68 68 69 70 70 70 70 71 71 75 86 92 92 92 93 94 Kapittel 7 - Teknisk evaluering
7.1 Forord
7.2 Utviklingsverktøy
7.3 AngularJS
7.3.1 Versjon
7.3.2 Beskrivelse av rammeverket
7.3.3 Hvorfor AngularJS?
7.4 Model
7.4.1 Databasestruktur
7.4.2 Databaseaksess
7.5 View
7.5.1 HTML5
7.5.2 CSS, Bootplus og design
7.5.3 Google Analytics
7.5.4 Metadata
7.6 Controller
7.6.1 AngularJS
7.6.2 JSON
7.7 Sikkerhet
7.8 Våre vurderinger, og utviklingspotensiale
7.8.1 Bruker og bestilling
7.8.2 Sikkerhetsvurdering
7.8.3 Øvrig
7.9 Brukerveiledning for server og database.
7.9.1 Server
7.9.2 Driftsoppgaver på serveren.
7.9.3 Database
7.9.4 FTP-server
7.9.5 Alias
7.10 Pakkereferanser
Kapittel 8 - Vedlegg
8.1 Prosjektdagbok
1. oktober 2014
1. november 2014
25. november 2014
8. januar 2015
14. januar 2015
19. januar 2015
21. januar 2015
22. januar 2015
25. januar 2015
26. januar 2015
29. januar 2015
1. februar 2015
3. februar 2015
Side 9 96 96 96 96 96 96 97 98 98 99 100 100 101 101 102 103 103 104 105 106 106 106 107 107 107 108 110 113 115 115 118 118 118 118 118 118 119 119 119 119 119 119 119 120 120 23. februar 2015
25. februar 2015
2 .mars 2015
16. mars 2015
18. mars 2015
23. mars 2015
25. mars 2015
8. april 2015
9. april 2015
14. april 2015
22. april 2015
26. april 2015
29. april 2015
1. mai 2015
2. mai 2015
3. mai 2015 - 10. mai 2015
11. mai 2015
12. mai 2015
13. mai 2015
14. mai 2015
15. mai 2015
18. mai 2015
8.2 Fremdriftsplan
8.2.1 Fremdriftsplan for implementering
8.2.2 Fremdriftsplan for testing og rapport
8.3 Møter med oppdragsgiver
Møtereferat 22. januar 2015 (Planleggingsfase)
Møtereferat 29. januar 2014 (Kontraktsignering)
Møtereferat 13. mars 2015 (Nye krav)
Møtereferat 22. april 2015 (Visning av prototype)
Møtereferat 11. mai 2015 (Gjennomgang av forbedret prototype)
Møtereferat 14. mai 2015 (Brukertesting / pilot)
8.4 Brukertest
8.5 Kildekode og anvisninger til kjørbar versjon
8.5.1 For fysisk sluttrapport
8.5.2 For digital sluttrapport
Side 10 120 120 120 121 121 121 121
121 121
122 122 122 122 122 122 122 123 123 123 123 123 123 124 124 133 137 137 138 138 139 139 140 140 148 148 148 Side 11 Kapittel 1 - Kravspesifikasjon 1.1 Forord Denne kravspesifikasjonen er ment som en hjelp til gruppemedlemmene, veileder og oppdragsgiver for å viske ut eventuell tvil om hva som skal lages. Ved å definere avgrensinger, funksjonalitet og nytteverdi av hva som skal lages øker vi forståelsesevnen til alle parter. Denne kravspesifikasjonen har vært til god hjelp i tilfeller hvor vi har vært usikre på om en funksjon er med i omfanget av prosjektet eller ikke. 1.2 Presentasjon Tittel: Plutselig Webapp Definisjon: Plutselig Webapp er en webapplikasjon som skal lagre informasjon om diverse pizzaer som blir tilbudt og eventuelt ha en bestillingsmulighet. Oppdragsgiver ønsker seg Google Analytics slik at han får en innsikt i hvordan besøkende bruker nettsiden, hvordan de ankom nettstedet, og hvordan man kan få besøkende til å komme tilbake. Dessuten ønsker oppdragsgiver å kunne endre nettsiden, blant annet priser, produkter, legge til nye tilbud og nyheter med mer. Dersom oppdragsgiver ikke ønsker seg ekstra funksjonaliteter som er lagt til vil de bli deaktivert/fjernet ved overlevering av produktet. Gruppe- medlemmer: Torstein Frogner Bernt Kristoffer Helland Vahid Khairkhah Jonas Myren Mo Gruppenummer: 23 Oppdragsgiver: Pizza Plutselig, Ullevålsveien 14 0171 Oslo Kontaktperson: Mansour Jam 954 79 171 [email protected] Intern veileder: Ismail Hassan [email protected] Side 12 1.3 Bakgrunnen 1.3.1 Motivasjon Plutselig Webapp er en nettapplikasjon for oppdragsgiver Pizza Plutselig. Webapplikasjonen skal løse utfordringene oppdragsgiver har hatt, som er enklere utfylling og endring i priser, produkter og nyheter. Dette vil hjelpe oppdragsgiver med å kunne utføre oppgavene uavhengig av personer med IT-bakgrunn. I løpet av 10 år har det ikke vært store forbedringer av selve nettsiden fordi det har vært et krevende arbeid for oppdragsgiver. 1.3.2 Funksjonalitet Webapplikasjonen skal ha muligheten for at den ansvarlige hos oppdragsgiver skal kunne logge seg inn og utføre endringer som ble nevnt ovenfor. Per i dag gjøres disse endringer av oppdragsgivers svoger, som har vært en tungvint prosess og personavhengighet. Kunder skal kunne få opp nettsiden og lese seg frem og skaffe seg overblikk over meny, åpningstider og daglige tilbud. Senere vil det bli implementert bestillings muligheter gjennom nettsiden. Det blir tildelt roller som administrator med redigeringsmulighet eller vanlig bruker som gir leserrettighet og senere bestillingsrettighet. Den skal ha søkemotoroptimalisering slik at man kan få treff på webapplikasjonen når man søker «pizza i Oslo» i Google, dette er også en avtale kunden skal inngå med Google. Applikasjonen skal være nettbasert med responsivt design og den skal være maskin- uavhengig. Dette vil si så lenge en enhet er koblet til internett vil det være mulig å få opp en leselig versjon av nettsiden i nettleser. 1.4 Kort systembeskrivelse Webapplikasjonen vil ha informasjon om organisasjonen, veibeskrivelse, leveringstider og leveringsmuligheter, åpningstider og annen informasjon som kan være relevant for kunden. Kunden skal kunne se en liste med forskjellige valgmuligheter, som vil veilede brukeren til riktig sted. Menyen skal være lik hele veien, slik at man ikke må tilbake til startskjermen for å komme til en “hovedmeny”. Administrator vil få tilgang til å kunne opprette, endre, slette og liste opp all tekst i sitt adminpanel uten å han skal behøve å ha noen IT-kompetanse. Her er et par eksempler for opprettelse, endringer og sletting: Priser, produkter (pizza, tilbehør og ingredients), nyheter og navigasjonsmeny. Side 13 1.5 Rammekrav i systemet Det er satt følgende rammekrav og forutsetninger: ● Webapplikasjonen krever nettleser for at det skal være mulig å bruke den. ● Nettlesere kan være av type Mozilla Firefox, Microsoft Internet Explorer, Google Chrome og lignende, samt mobilnettlesere. ● Webapplikasjonen er ikke avhengig av utstyrstype. ● Internett-tilgang er et krav for at webapplikasjonen skal vises. ● Webapplikasjonen vil bli lastet opp i webhotellet som oppdragsgiver bruker. ● Oppdragsgiver og leverandør har ansvaret for systemets oppetid. Figur 1.1 : Domenemodell. Figur 1.2 : Aktivitetsdiagram. Side 14 Verktøy som skal brukes i utviklingen er: ● Notepad++. ● Dia / ArgoUML for tegninger av diagrammer og uml-er. ● Visual Studio Ultimate 2013. ● Bitbucket. ● Webstorm. Programmeringsspråk som blir benyttet i utviklingen: ● HTML5 ● CSS3 / Bootplus ● JavaScript/ JQuery ● AngularJS ● Database (SQL) ● C# ● JSON ​
1.6 Funksjonelle krav Nr. Prioritet Krav Spesifisering 1 A En administrator skal kunne logge inn. Administrator skal kunne logge inn med en privat bruker, som har tilgang til styringsfunksjoner i applikasjonen. 2 A En administrator skal kunne opprette en ny pizza. Administrator skal kunne velge navn, pris og ingredienser for en ny pizza, og lagre den i databasen. Det er forutsatt at ingredienser allerede er opprettet. 3 A En administrator skal kunne se en oversikt over lagrede pizzaer. Administrator skal kunne se en oversikt over alle pizzaer som er lagret i databasen, med visning av alle detaljer. 4 A En administrator skal kunne opprette en ny ingrediens. Administrator skal kunne velge navn og pris for en ny ingrediens, og lagre den i databasen. Pris lagres for kunne bruke bestillingsfunksjonen (B-krav). 5 A En administrator skal kunne se en oversikt over lagrede ingredienser. Administrator skal kunne se en oversikt over alle ingredienser som er laget i databasen, med visning av alle detaljer. Side 15 6 A En administrator skal kunne opprette et nytt tilbehør. Administrator skal kunne velge navn og pris for nytt tilbehør (brus ol.), og lagre varen i databasen. 7 A En administrator skal kunne se en oversikt over lagrede tilbehør. Administrator skal kunne se en oversikt over alle tilbehør som er laget i databasen, med visning av alle detaljer. 8 A En administrator skal kunne endre lagrede varer og ingredienser. Administrator skal kunne gjøre endringer i navn, pris og eventuellt ingredienser for en vare som er lagret i databasen. 9 A En administrator skal kunne slette lagrede varer. Administrator skal kunne slette varer fra databasen via applikasjonen. 10 A En pizza skal kunne inneholde flere priskategorier (stor, liten og glutenfri). Pizzaer kan komme i tre kategorier, stor, liten og glutenfri. Administrator skal kunne sette pris for alle kategorier. 11 A En administrator skal kunne opprette en nyhet. Administrator skal kunne opprette en nyhet, som vil lagres i databasen. En nyhet skal vises i nyhetssiden. 12 A En administrator skal kunne se en oversikt over lagrede nyheter. Administrator skal kunne se en oversikt over alle nyheter som er laget i databasen, med visning av alle detaljer. 13 A En administrator skal kunne opprette en informasjonsside, som gir et nytt valg i navigasjonsmenyen. Administrator skal kunne opprette en ny informasjonsside, som vil lagres i databasen. En ny informasjonsside oppretter et nytt navigasjonsmenyvalg. 14 A En administrator skal kunne se en oversikt over lagrede informasjonssider. Administrator skal kunne se en oversikt over alle informasjonssider som er laget i databasen, med visning av alle detaljer. 15 A En administrator skal Administrator skal kunne endre og kunne endre og slette en slette en nyhet, via applikasjonen. nyhet. Ved å slette en nyhet fra databsen, vil den også bli slettet fra nyhetssiden. Side 16 16 A En administrator skal Administrator skal kunne endre og kunne endre og slette en slette en informasjonsside, via informasjonsside. applikasjonen. Ved å slette en informasjonsside fra databasen, vil den også bli slettet fra navigasjonsmenyen. 17 B En administrator skal kunne ha oversikt over databaselogger. Loggføring av databasehendelser, som administrator skal kunne ha oversikt over. 18 B En administrator skal kunne ha oversikt over loggføring av feil. Loggføring av feilmeldinger til fil, som administrator skal kunne ha oversikt over. 19 B Muligheten til å skrive ut Oppdragsgiver ønsker bestillingene innkommende skrevet ut på på papir. bestillinger automatisk via en liten printer. 20 B En kunde skal kunne opprette en bruker. Kunde skal kunne opprette en bruker med adresse, telefonnummer, epostadresse og passord. 21 B En bruker skal kunne logge inn. Brukeren skal kunne logge inn med e-post og passord. Må logge inn for å få tilgang til bestilling vi applikasjonen. 22 B En administrator skal Administrator skal kunne opprette kunne opprette, endre og nye brukere, endre brukere, og slette slette brukere. brukere fra databasen. Kun en administrator skal ha tilgang til disse funksjonene. 23 B En administrator skal kunne se en oversikt over registrerte brukere. 24 B Systemet skal forhindre uautorisert tilgang til kundeinformasjon. Profiler til hver enkelt bruker skal være beskyttet. Rollene skal være forhåndsdefinerte. 25 B En kunde skal kunne bestille pizza. Kunder som er logget inn skal kunne legge inn en bestilling via applikasjonen. 26 B En kunde skal kunne En kunde skal kunne komponere egen Side 17 komponere en egen pizza. pizza. Velger mellom ingredienser og bunn. 27 B En bruker skal kunne se sin egen profil, og gjøre endringer. Egen kundeprofil. 28 B En bruker skal kunne slette sin egen brukerkonto. 29 B En kunde skal ikke ha tilgang til andre brukerkontoer. Kunden skal ikke ha mulighet til å se eller gjøre endringer på andres profiler. 30 B En bruker skal kunne velge størrelse på pizza. 31 B En bruker skal kunne velge glutenfri pizzabunn. 32 B En bruker skal også kunne kjøpe tilbehør, som brus og dressing. 33 B En bruker skal kunne bestille flere varer. 34 C En administrator skal kunne laste opp bilder til informasjonssidene og nyhetene. 35 C En bruker skal kunne velge om pizzaen skal kjøres ut eller ikke. 36 C En bruker skal kunne Telefonnummeret skal være lett finne ut hvordan han kan tilgjengelig. For eksempel i bunn av ta kontakt med butikken. siden. ​
Tabell 1.1 : Funksjonelle krav i kravspesifikasjon. Side 18 1.7 Ikke-funksjonelle krav Aktivitet Nr. Prioritet Krav Spesifisering 37 A Applikasjonen skal inneholde mulighet for å analysere brukeratferd via Google Analytics. 38 A Systemet skal være brukervennlig og raskt. Webapplikasjonen skal respondere raskt og ikke oppleves tregt 39 A En bruker skal ikke måtte bruke mer enn tre klikk i menyen for å komme til ønsket menyvalg Menyhierarkiet ikke har mer enn to til tre forgreninger 40 A Nettsiden skal kunne tilpasse seg forskjellige enheter og nettlesere. Det skal være en dynamisk design og enhet uavhengig. 41 A Systemet skal kunne videreutvikles. Systemet skal utvikles etter standarder og “god praksis” slik at videreutvikling er mulig. 42 B Siden skal være søkemotoroptimalisert Ved bruk av meta-tagger. 43 B Systemet skal ha et innbydende og funksjonelt design Vi vil følge WCAG, og oppdragsgivers ønsker. 44 C Spørringer til databasen skal ikke ta mer enn 3 sek ved normal bruk. Tabell 1.2: Ikke-funksjonelle krav i kravspesifikasjon. Merk! Krav med prioritet lavere enn A blir ikke prioritert som en del av fremdriftsplanen for hovedprosjektets rammer, men kan være aktuelle for videreutvikling av webapplikasjonen. Statusen for hvert krav er dokumentert i fremdriftsplanen. Side 19 Kapittel 2 - Prosessdokumentasjon 2.1 Forord Prosessdokumentasjonen vil gi innblikk i arbeidsmåter og arbeidsprosesser som er benyttet for å oppnå målene beskrevet i kravspesifikasjonen, som vi sammen med arbeidsgiver har kommet frem til. Her vil vi forklare nærmere om utfordringer vi har møtt på vegen og hvordan disse ble håndtert. 2.2 Forberedelser og planlegging 2.2.1 Valget av oppgaven I midten av 2014 startet gruppen vår å sende ut forespørsler om bacheloroppgave til selskapene Bekk, NSB, Accenture og Steria. Steria hadde dessverre ingen ordning da de primært driver med løsningsarkitektur og prosessrådgivning for andre bedrifter. De leier ut konsulenter til andre firmaer for å tilrettelegge deres IT-strategi, og hjelper dem med å effektivisere IT-løsninger. Vi var dessverre for sent ute for å få utdelt oppgaver fra Bekk og Accenture, da vår gruppe ble stiftet i begynnelsen av oktober. De hadde utdelt sine oppgaver til grupper som var tidligere ute. Vi hørte med NSB om de så for seg å dele ut et av prosjektene sine som bacheloroppgave. De svarte positivt på dette, men da vi forsøkte å kontakte prosjekteier og systemeier for å få til et møte, hadde de dessverre ikke tid til å planlegge et nytt prosjekt før slutten av året. Dette fordi NSB Persontog var midt i et stort prosjekt med migrering og implementering av nye IT-systemer, blant annet FIDO. Etter en prat med Tor Krattebøl, høgskolelektor på HIOA, fikk vi vite at vi kan se etter oppgave hos private aktører. Gruppen ble introdusert til Pizza Plutselig gjennom en venn. Oppdragsgiver så etter en effektiv måte å kunne endre informasjonen på nettsiden sin. Dette ville hjelpe oppdragsgiver i å være mindre avhengig av personer med IT-kompetanse. Oppgaven hadde som formål å løse oppdragsgivers nettsideutfordringer. Etter noe mailkorrespondanse om hva et hovedprosjekt innebar for begge parter med Tor Krattebøl, ble vi enig om at denne oppgaven ville være både en utfordrende og spennende bacheloroppgave som ville gi oss stor grad av frihet i løsningen, med stort ansvar. Side 20 2.2.2 Definere oppgaven og omfang Gruppen startet med klargjøring av oppgaven og dens omfang ut i fra tidligere informasjon vi har hatt om prosjektet. Dette innebar ulike ideer om hvordan det best skulle løses ut fra et teknisk ståsted og hvor omfattende det skulle være. Etter møte med arbeidsgiver den 22. januar 2015 fikk vi en liten gjennomgang av hvordan oppdragsgiver løser sine utfordringer i dag, og at han ønsker seg en løsning hvor han kunne endre nyheter, produkter og priser på en enkel måte, slik at oppdragsgiver kunne være personuavhengig. Oppdragsgiver ønsket seg en enkel nettside som skulle passe til selskapets logo, samtidig som det skulle være enkelt for kunder å navigere seg rundt. Oppdragsgivers ønske var grunnlaget for vår kravspesifikasjon. 2.2.3 Finne riktig rammeverk Før gruppen valgte teknologi undersøkte vi de forskjellige rammeverkene. Vi lagde et tankekart med teknologier vi hadde kjennskap til gjennom studier og ukjente teknologier som vi støtte på gjennom nettsøking. Alternativer vi hadde var å utvikle webapplikasjonen vår i Java, HTML 5, PHP eller ved hjelp av en CMS (Content Management System)-løsning. Våre kriterier var å levere en webapplikasjon med høy sikkerhet og at det skulle være enkelt for oppdragsgiver å ta i bruk. Vi har valgt å løse oppgaven ved hjelp av Microsoft .Net Framework og AngularJS, da begge har støtte for MVC-arkitektur med integrert støtte for enhetstesting. 2.2.4 Oppstartfasen Gruppen diskuterte utviklingsmetodikkene fossefall og smidig, som vi har lært oss i faget systemutvikling. Det var naturlig å velge en smidig metodikk, da det ville gi både effektivitet og produktivitet i utviklingen av webapplikasjonen. For å kunne jobbe med scrum så vi etter utviklingsverktøy som kunne hjelpe oss. Verktøyet Trello ga oss muligheten til å lage scrum-tavle med mulighet for sprinter og oppgaver. Vi valgte dette verktøyet med bakgrunn i tilgjengelighet på både nett og mobil. Det ble opprettet noen predefinerte oppgaver for å finne styrker og svakheter i de ulike rammeverkene som skulle ivareta våre kriterier i en webapplikasjon, nemlig høy sikkerhet og at det skulle være lett for oppdragsgiver å ta i bruk. Java? Det har vært mange saker om sikkerhetsproblemer ved Java. Et problem er selve risikoen med programmet, et annet er at det virker som folk har vanskelig for å installere oppdateringer som skal rette problemene.1 1
Emm, D. (2013, 3. juli). Java Exploits - Do You Need to Be Worried? ​
The Huffington Post​
. Hentet fra http://www.huffingtonpost.co.uk/david-emm/java-exploits-should-you-be-worried_b_2817826.html Side 21 Siden vi ikke står for oppgradering av Java på servere samt ikke kjenner til sikkerhetspolicyer og oppgraderingsrutinen hos oppdragsgivers webhotell-leverandør, velger vi bort utvikling av webapplikasjon i Java. HTML? HTML ville være en uoversiktlig og lang tekstside som ikke egnet seg til den oppdragsgiver ønsket seg, nemlig enkel bruk og produktivitet uten å trenge IT-erfaring. CMS? En CMS (Content Management System), for eksempel Wordpress, Joomla og Drupal, ville muligens være gode alternativer for utvikling av en nettside for oppdragsgiver. Men foruten spørsmål om en CMS virkelig er enkel nok for kunden så kommer også spørsmålet om sikkerhet. En undersøkelse fra WP White Security viser at 73% av alle WordPress-installasjoner hadde kjente sårbarheter som lett kan oppdages ved hjelp av automatiserte verktøy.2 Cyberkriminelle har lenge oppdaget disse sikkerhetshullene, med over 170 000 WordPress-kontoer som ble hacket i 2012. Figur 2.1: De forskjellige CMS-enes markedsandel. 3
Da vi gjorde undersøkelser rundt sårbarheten til en rekke standardiserte CMS-løsninger, fant vi ut at hackere anser de å være attraktive mål ettersom de er bygget i åpen kildekode.4 Det er viktig å nevne at slike løsninger tilbyr flere fordeler, for eksempel utvidelser som gir utvidet funksjonalitet. Siden CMS-løsninger er populære vil hackere verden over se etter sårbarheter ved CMS og angripe dem. Det finnes mye skadelig programvare som er designet for å ramme CMS-løsninger. En vanlig måte å ramme en CMS-løsninger på er via malware og DDOS-zombier. Da kan hackere ved hjelp av administratorpassord deaktivere nettsiden, eller 2
Abela, R. (2013, 24. september). Statistics Show Why WordPress is a Popular Hacker Target. ​
WP White Security​
. h​
ttp://www.wpwhitesecurity.com/wordpress-security-news-updates/statistics-70-percent-wordpress-installations-vulnerable/ 3
Cassetto, O. (2014, 11. september). Why CMS Platforms Are Common Hacking Targets (and what to do about it). https://www.incapsula.com/blog/cms-security-tips.html 4
​
Cassetto, O. (2014, 11. september). Why CMS Platforms Are Common Hacking Targets (and what to do about it). https://www.incapsula.com/blog/cms-security-tips.html Side 22 bruke malwaredistribuering som resulterer i at nettsiden til slutt havner på Google og andre søkemotorer sine svartlister.5 Det ble også stilt spørsmål om ulike CMS-utvidelser og temaer gjør nettsiden mer utsatt for angrep. Disse er ofte utviklet av en tredjepart, og kan innføre et ekstra sett med sårbarheter. En fersk studie kom frem til at over 20 % av de femti mest populære WordPress-utvidelsene var utsatt for angrep. Vi har likevel gjort en vurdering av hvordan oppdragsgiver kan sikre seg mot angrep, om vi velger en standardisert løsning. ● Man kan lage en tidsplan for å oppdatere løsningen, installerte utvidelser og temaer. Dette vil sørge for at alle komponenter er oppdaterte til enhver tid. De fleste standardiserte-løsningene vil vanligvis vise en melding når en ny oppdatering er tilgjengelig. ● Ta jevnlige backup av databasen. Dette bør utføres minimum ukentlig. ● Ikke bruke vanlige administratornavn (for eksempel "admin"), og bruke sterke passord (minst syv tegn, med en kombinasjon av store og små bokstaver, samt både bokstaver og tall). ● Bruk en utvidelse for sterk autentisering, eller to-faktorautentisering (2FA) for et ekstra lag med beskyttelse. En slik løsning vil være uønsket ettersom oppdragsgiver ikke har kapasitet til å utføre jevnlige oppdateringer. De resterende punktene på listen kan vi tilby med en skreddersydd løsning som tar høyde for sikerhetsrisikoene nevnt ovenfor. Det vil påvirke oppdragsgiver dersom nettsiden blir utsatt for angrep og blir utilgjengelig. Dette vil føre til økonomiske kostnader og tap av kunder. Derfor har vi i samarbeid med oppdragsgiver bestemt oss for å utelukke en CMS-løsning. Hva vi endte opp med. For å ivareta sikkerheten og brukervennligheten til sluttproduktet har gruppen bestemt seg for å utvikle vår webapplikasjon i Microsoft .NET. Vi bestemte oss for å lage en single-page application (SPA) hvor vi benyttet MVC (Model-View-Controller)-arkitektur med AngularJS i front og database i back end. Vi er veldig klar over at det ikke finnes en bombesikker løsning og samtidig har vi god kjennskap til at webapplikasjon med SQL kan utsettes for SQL-injeksjon og parametermanipulering, samt «cross-site-scripting» og «cross-site request»-forfalskning. Tiltakene vi har tatt i bruk er blant annet å erstatte streker og sitater, bruke flerlagsstruktur med MVC-rammeverk som forhindrer noen i å tukling med verdien, men også forhindrer klientsideskript fra å legitimt endre en verdi. Disse sikkerhetsutvidelser for MVC lar oss 5
Gurung, V. (2014, 8. august). DDOS Vulnerability in WordPress and Durpal CMS. ​
Cyber Kendra.​
Hentet fra http://www.cyberkendra.com/2014/08/ddos-vulnerability-in-wordpress-and.html Side 23 kryptere et nøkkelfelt på en side ved hjelp av asymmetrisk kryptering som deretter brukes til å sammenligne mot et tekstfelt på siden for å hindre sabotasje. 6 2.2.5 Milepælsplan Gjennom prosjektet har vi jobbet mot våre mål som var fordelt i tre milepæler. I denne del kapittelen forklarer vi nærmere milepælene. Gantt-skjema for bachelorprojekt: Milepælen forteller om tidsfrister for viktigste deler av prosjektet. Den sier noe om starttiden og antall dager vi har til rådighet. Dette var en en enkelt måte å ha oversikt over tiden og hvor langt vi har kommet påvei. Figur 2.2: Gantt-skjema for bachelorprosjekt. Gantt-skjema for for design, implementering og testing Gruppen opprettet et milepæl for å ha oversikt over design-, implementering -, og testingfasen. En slik milepæl var til hjelp for å kunne måle vår teknisk fremgang. Tuliper, A. (2011, desember). Hack-Proofing Your ASP.NET Applications. ​
MSDN Magazine.​
Hentet fra ​
https://msdn.microsoft.com/en-us/magazine/hh580736.aspx 6
Side 24 Figur 2.3: Gantt-skjema for design, implementering og testing av webapplikasjonen. Gantt-skjema for dokumentasjon Gruppen opprettet en milepælsplan som gikk på starttiden på dokumentasjon, og antall gjenstående dager til levering. Milepælen har hjulpet oss med å opprettholde tiden. Figur 2.4: Gantt-skjema for dokumentasjon. Side 25 2.3 Utviklingsverktøy For å ha en smidig og strukturert tilnærming til utviklingen, spilte valg av verktøy en viktig rolle for oss da vi ønsket å lage et godt produkt for Pizza Plutselig. Følgende programvare er benyttet under utviklingen: 2.3.1 Microsoft Visual Studio Ultimate 2013 Vi har brukt Microsoft Visual Studio til å utvikle vårt program. Dette utviklingsverktøyet har støtte for en rekke programspråk. Verktøyet fins både i gratis (Visual Express) og kommersiell versjon. Høgskolen i Oslo og Akershus har sponset oss med 3 års gratis lisens for Ultimat-utgaven, noe vi er takknemlige for. Verktøyet er ganske populær blant utviklere som jobber med utvikling av .NET-applikasjoner. Som navnet sier er dette et Microsoft produkt som forutsetter at man har en Windows-pc. Det er dessverre ikke tilgengelig for Mac brukere. 2.3.2 Dia. Dia er et gratis modelleringsverktøy som ble brukt til å tegne relasjoner mellom klasser og databaser. Verktøyet er en industristandard for datarelatert modellering og objektmodellering. Dia bruker et grensesnitt som er likt bilebehandlingsverktøyet GIMP. 2.3.3 Bitbucket Bitbucket er et populært versjonhåndteringssystem brukt i utvikling av åpen kildekode, som baserer seg på git. Fordelen med dette verktøyet er at utviklere kan jobbe på samme prosjekt og synkronisere med hverandre, det forutsetter at ikke alle jobber med samme metode. Dette ga oss muligheten til å jobbe selvstendig og uavhengig av gruppens tilstedeværelse. Det er mulig å gå tilbake til tidligere versjoner av koden dersom uhell skulle oppstå. 2.3.4 Trello Prosjekt- og organiseringsverktøy som egner seg for smidig utvikling. Dette ble brukt primært til å ha oversikt over alle ulike sprinter og backlogger til enhver tid i utviklingen. 2.3.5 Dropbox Det ble opprettet en delt mappe i skylageringstjenesten Dropbox som felles samlingspunkt som gruppemedlemmene benyttet for lagring av dokumenter og nyttig informasjon som gruppen kunne ha interesse av. Side 26 2.3.6 Notepad++ Programmet ble brukt til kodevisning, redigering og dokumentering. Dette er en fri kode editor som har støtte for flere språk og utvidet funksjonalitet blant annet å farge sette koder noe vi trengte da vi har hatt mange klasser og brukt flere program kodene C#, HTML og JavaScript. 2.3.7 Testmiljø For det meste har vi bare testet hvordan koden har fungert lokalt på hver våres datamaskiner. Vi har testet på forskjellige nettlesere, både på mobil og laptop. 2.3.8 Doxygen Doxygen er et verktøy brukt for generering av dokumentasjon fra kommenterte C# kilder, men den støtter andre populære programspråk som blant andre C, C++, PHP, Java og Python. Dette verktøyet kan generere en dokumentasjonsnettside i HTML eller en offline referansehåndbok fra et sett av dokumenterte kildefiler. Siden dokumentasjonen blir hentet direkte fra kildene, gjø det det mye lettere å holde dokumentasjon i samsvar med kildekoden. 2.3.9 Microsoft Word Microsoft Word er et tekstbehandlingsprogram som er produsert av Microsoft, som vi har benyttet til utarbeidelse av dokumentasjon. Som verdens mest brukte tekstbehandlingsverktøy får man en rekke funksjonalitet som er nyttig når man skal behandle en tekst. 2.3.10 Facebook Facebook er et sosialt medium som vi har benyttet for å kommunisere oss i mellom. Kommunikasjon gjennom en slik kanal er mye enklere da alle kan se hva som blir diskutert/avtalt. Dessuten kan man gå tilbake for å se over kommunikasjonslogger og historikken. 2.4 Utviklingsmetodikk 2.4.1 Innledning Fra starten av prosjektet har vi vært bevisst på å dokumentere og loggføre både arbeidet og kommunikasjonen slik at man kan ha et godt fundament for prosessdokumentering og ikke minst se hvilke beslutninger vi har tatt tidligere i prosessen. Vår innsats baserte seg på smidig metodikk, og scrum er brukt som utviklingsmetode, hvor oppgavene var fordelt i sprinter. Side 27 2.4.2 Daglige utfordringer Gruppens største hverdagsutfordring knyttet til webapplikasjonen har vært den tekniske utviklingen. Til tider ønsket vi en fagperson som kunne bistå med råd og hjelp for å forenkle utviklingen. Vi har klart å løse utfordringene våre gjennom bruk av Google og bruk av tidligere faglærer. En annen utfordring har vært Bitbucket og synkronisering av koden mellom gruppene. Bitbucket er en plattform hvor man kan ta i bruk «versjonskontroll», som essensielt betyr at hver utvikler i gruppen kan jobbe individuelt med prosjektet, og deretter sette sammen all koden når det trengs. Utfordringen med dette er at ingen på gruppen hadde noe som helst kjennskap til hvordan man skulle bruke et versjonskontrollverktøy, som førte til at vi hadde problemer med å synkronisere filene slik at koden ble slått sammen sømløst. Grunnen til at vi valgte å bruke versjonskontroll er fordi det er et svært viktig aspekt av et prosjekt som dette, og burde egentlig benyttes i alle tilfeller der det er mulig. Enhetstesting har også vært en del av prosjektet vi har hatt utfordringer med, på grunn av manglende kjennskap til AngularJS. Vi fant ut etter hvert at for å gjøre enhetstesting i Angularjs, måtte man bruke litt andre teknikker enn for eksempel i vanlig MVC og web-api. Enhetstesting er viktig med tanke på at man vil være sikker på at alle metodene man har i koden sin fungerer som det skal. Dette vil si for eksempel at en bruker blir opprettet riktig, i applikasjonen eller at man kan slette en bruker uten at det skjer noe krøll med resten av strukturen. Å gjøre nettsiden sikker var en utfordring med tanke på hvor mange mulige måter man kan hacke en nettside. Problemet til å begynne med var å gjøre det slik at funksjonene i back-end(dvs. database) kun var mulig å aksessere for administratorer og ingen andre uvedkommende. I begynnelsen av prosjektet nevnte oppdragsgiver at vi hadde frie tøyler til å lage nettsiden slik vi ville, så lenge informasjonen var lett tilgjengelig. Men når kravspesifikasjonen endret seg og vi fant ut at vi måtte gjøre ting litt annerledes, var ikke oppdragsgiver helt med på endringene. Dette ble en utfordring med tanke på at vi måtte følge ønskene til oppdragsgiver, samtidig som at vi måtte finne best mulig løsning på våres problemer i forhold til utviklingen av prosjektet. 2.4.3 Dagboken Dagboken har vært i kontinuerlig oppdatering fra begynnelse av hovedprosjektet, 01.oktober 2014 frem til innlevering 26. Mai 2015. Dette for å ha oversikt over hva som er gjort, hvilke utfordringer vi har hatt og fremtidige planer. Alt ble loggført i dagboken både tekniske og ikke tekniske helt frem til Trello ble tatt i bruk, da ble vår tekniske planer ført til Trello i våre scrumbrett mens vi fortsatt loggførte våre oppmøte, aktivitet og kommunikasjon i dagboken. Side 28 Dagboken er lagt som vedlegg i delkapittel 8.1 med oppdatering frem til trykking av slutt- rapporten. 2.4.4 Scrumbrett Trello ble brukt som verktøy for å ha oversikt over alle aktiviteter og sprinter som var ført i vårt scrumbrett. Dette var til stort hjalp særlig med organisering og orientering av arbeidet som skulle utføres til enhver tid. Vi ble strukturerte og både på det pågående arbeidet og fremtidige oppgaver samtidig som man har en historikk over utførte arbeid som man kunne gå tilbake til. Ikke minst kunne deltakere se hvilke oppgaver er utført av andre i gruppen uten at vi trengte å være fysisk på samme sted. I delkapittel 8.2 under Fremdriftsplan har vi lagt ut noen av sprintene våre. 2.4.5 Versjonskontroll Webapplikasjonen er implementert og lastet opp i Bitbucket hvor vi har historikk over endringer som er gjort til en hver tid og samtidig som det gir oss muligheten til å gå tilbake til tidligere versjon ved behov. Koden vil ikke være tilgjengelig for andre enn gruppen da vi har valgt å ikke publisere og tilgjengelig gjøre koden for public. Commits Commit er en referanse som legges ved hver opplasting av applikasjonen slik at man kan ka versikt over hver endring som er utført. Denne koden legges inn i versjonskontrollen (inn i repositoryet) som sendes inn med en tekststreng som beskriver enderinger som er utført. Bilde 2.1: Commit-graf for bitbucket-repository. Side 29 Bilde 2.2: Commit fra bitbuckets source tree for dokumentasjon. 2.4.6 Møter med veileder Første møte med veileder var den 21. januar 2015. Vi hadde mange møter utover semesteret og fikk god veiledning, særlig med hensyn til dokumentasjon. I det andre møtet var oppdragsgiver med for underskriving av kontrakt. 2.4.7 Møter med oppdragsgiver Vi hadde to møter med oppdragsgiver før vi hadde en prototype hvor vi kunne få tilbakemelding på produktet. Under vårt første møte forklarte oppdragsgiver om utfordringer han hadde i sin nåværende løsning og hvilke funksjonaliteter han så for seg i sin nye løsning. Gruppen noterte ned innspill og temaer som oppdragsgiver ønsket seg, og lagde et møtereferat basert på disse notatene. Referatene ble videre sendt til oppdragsgiver for å utelukke eventuelle misforståelser og som en bekreftelse på hva som ble gjennomgått og hvilke konklusjoner som ble tatt. Møtene med oppdragsgiver ga oss viktige innspill i utviklingen av applikasjonen. I første møte fikk vi oversikt over utfordringer arbeidsgiver har, hvordan disse utfordringer ble løst med eksisterende løsning og i andre møte viste vi frem vår webapplikasjon for å se om vi har klart å forenkle oppdragsgivers IT-hverdag og løse deres problemer. Side 30 Oppgaven begynte å endre retning fra en informativ nettside med mulighet for å endre innholdet til å bli en fullstendig nettbutikk med betalingsmuligheter og knytninger til å kunne skrive ut ordre. Gruppen tok imot utfordringen med forbehold om å utføre dette dersom tiden var tilstrekkelig. På et tidspunkt måtte vi avgrense oppgaven slik at den implementerte versjonen skulle være velfungerende, mens de resterende forslagene vil være en del av utviklingspotensialet i webapplikasjonen. 2.4.8 Gruppesiden Gruppesiden ble oppdatert under hver innlevering for at dokumenter skulle være tilgjengelig for oppdragsgiver. 2.5 Kravspesifikasjonen 2.5.1 Forklaring Kravspesifikasjonen ble satt opp med en rekke punkter som var gitt prioriteringer merket med bokstavene A, B og C. A var høyest prioritert, og var de funksjonene oppdragsgiver ønsket seg fremst av alt. Deretter kom B-prioriterte krav, som oppdragsgiver kunne tenke seg noen mulige løsninger på om tiden strakk til. Og til slutt C, som ikke var essensielle. Eksempel på et A-krav, var muligheten til å endre pizzaer i menyen. Et eksempel på et B-krav var muligheten til å opprette en egen bruker. C-krav omhandlet i hovedsak utseende, og utforming. 2.5.2 Endringer i kravspesifikasjonen Etter utformingen av kravspesifikasjonen i sammarbeid med oppdragsgiver utviklet prosjektet seg til å bli noe mer enn bare en informativ nettside. Applikasjonen endret retning til å bli en nettbutikk med fullstendig bestillingssystem. Det ble opprettet flere A-krav som omhandlet brukere og bestilling av pizza. Senere ble det besluttet å sette bestillingssystemet på vent, og disse kravene ble nedgradert til B-krav. 2.5.3 Samsvar mellom opprinnelig og endelig kravspesifikasjon Som forklart over har kravspesifikasjonen endret seg underveis i prosessen. Oppdragsgiver endte opp med en applikasjon som stemte godt overens med det første utkastet, ettersom flere av de nye kravene senere ble revurdert. Alle A-kravene i kravspesifikasjonen ble oppfylt, både de funksjonelle og ikke-funksjonelle. Side 31 2.6 Fremdriftsplan 2.6.1 Innledning Fremdriftsplanen ble oppdatert etter at vi avsluttet hver sprint, både under implementering av webapplikasjonen og under testing. Aktivitetene endret status fra «To do» til «Doing», og til slutt ble den flyttet til «Done». Dette ga både veileder og oss en god oversikt over backlogger, samt aktive- og utførte aktiviteter. 2.6.2 Utviklingsfasene Planleggingsfase: Vår første del av prosjektet var planleggingsfasen, hvor statusrapport, prosjektskisse og forprosjektrapport ble dokumentert. Fremdriftsplanen var ikke utarbeidet i denne fasen. Kravsamling og designfase: ​
I samarbeid med oppdragsgiver utarbeidet vi en kravspesifikasjon som kunne dekke de fleste behov som oppdragsgiver hadde. Samtidig så vi på en del nettsider for å ha et utgangspunkt for hvordan designen bør se ut. Dessuten bestemte vi oss i denne fasen for hvilken utviklingsmetode og hvilke utviklingsverktøy vi skulle bruke. Utvikling og implementeringsfase: I denne fasen lagde vi oversikt over sprinter, og i hver sprint ble det lagt en god del brukerhistorier. Deretter lagde vi en fremdriftsplan for sprintene for å ha et standpunkt for videre jobbing. Dette ble også brukt som en milepæl slik at vi til en hver tid visste hvor lang tid vi har til å utføre et arbeid samt hvordan vi skulle planlegge neste backlog. Testingsfase: En del av testingen var knyttet til kravspesifikasjonen og en god del var enhetstesting som gikk ut på testing av kodene og ikke funksjonaliteter. Derfor bestemte vi oss for å ha en egen sprint og egen fremdriftsplan for denne fasen. 2.6.3 Tidsberegning Vårt hovedprosjekt har 20 studiepoeng som er 2/3 av arbeidsuken. Det tilsvarer at hvert gruppemedlem skal bruke 20-25 arbeidstimer på oppgaven. Timene blir brukt til blant annet planlegging, teknologivalg og egenlæring, programmering, testing og dokumentasjonsarbeid. Vi har satt som mål å være ferdig til 1. mai 2015 slik at ved eventuelle avvik kan vi ha rom til å utføre nødvendige endringer. Dersom ingen avvik oppstår vil vi bruke tiden til utbedring av produktet. Estimert tidsbruk vil være cirka 1600 timer totalt for oppgaven. Vi har en tabell som representerer gruppens tidsplan i kapittel 8, tabell 8.1. Side 32 Planning poker Siden gruppen hadde bestemt seg for å bruke smidig utviklingsmetodikk fremfor fossefallsmetoden var det naturlig å benytte seg av planning poker. Tiden ble estimert hver for oss basert på våre tidligere erfaringer, styrker og svakheter. Til slutt kunne vi ta et gjennomsnitt for hvor mye tid vi så for oss til å bruke i hver oppgave i hver sprint. Vi hadde sett for oss 15 prosent feilmargin på tidsberegningen. 2.6.4 Samspillet mellom fremdriftsplan og scrumbrett En kontinuerlig oppdatering i fremdriftsplanene sammen med scrumbrettet ga oss et godt bilde på hvor langt vi har kommet og hvor mye som står igjen. Vi tok for oss et gitt antall krav fra kravspesifikasjonen som gruppen jobbet med. Bildet nedefor viser et utkast av fremdriftsplanen. Se kapittel 8 for den endelige tabellen. Tabell 2.1: Utkast av fremdriftsplanen. Side 33 Bilde 2.3: Viser scrumbrettet og alle planlagte sprinter.(Føste utkast). Bilde 2.4: Viser scrumbrettet og alle planlagte sprinter i mindre deloppgaver. Side 34 2.7 Designutvikling 2.7.1 Utformingen av designet Når vi satte oss ned i begynnelsen av utviklingsfasen, prøvde vi å komme med argumenter på hvordan nettsiden skulle se ut visuelt. Etter litt forskning på hvordan brukere oppfører seg på en nettside, fant vi ut at vi burde gå for en nettside som i utgangspunktet er forutsigbar. Dette var fordi mange brukere beveger synet og leser på nettsider koherent. Dette vil si at hvis man ikke har en oversiktlig nettside, kan det påvirke flyten til brukeren ettersom han eller hun i utgangspunktet forventer at alle internettsider har samme oppsett. Jakob Nielsen i Nielsen Norman Group, gjorde et eksperiment blandt 232 brukere og flere tusen nettsider. Konklusjonen de kom frem til var at de fleste brukere beveger synet i en slags F-form. Noe som gjør at viktig informasjon nederst til høyre på internettsiden kan risikeres å bli ignorert av brukeren.7 På dette grunnlaget valgte vi å sette opp viktig informasjon og menyvalg øverst på nettsiden i form av en «global meny». Globale menyer holder seg som regel på toppen av nettsiden, og består av kategorivalg/menyvalg som ligger ved siden av hverandre. Dette fant vi ut var den eneste menyen vi trengte på nettsiden, ettersom at vi ikke vil ha for mye valg og menyer som kan påvirke den simple strukturen vi ville gå for. Vi produserte en wireframe som kunne hjelpe oss å få en oversikt over hvordan vi skulle sette opp nettsiden designmessig. Bilde 2.5: Wireframe av nettsiden. 7
Nielsen, J. (2006, 17. april). ​
Nielsen Norman Group. ​
Hentet fra http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/ Side 35 Når det gjelder plassering av innholdet på siden så gikk vi for et utseende som kunne holdes forutsigbar uavhengig av hvilken kategori brukeren befant seg i (meny eller selskap). Det vil si at “Hovedområde for tekst på nettsiden” alltid vil være på samme sted samtidig som at den globale menyen ikke forandrer eller flytter på seg. Vi valgte å bruke HTML, Bootstrap-baserte Bootplus og AngularJS da applikasjonen skulle kjøres på nettet. Det ble nevnt av oppdragsgiver å ivareta mest mulig av deres tidligere design slik at nettsiden skulle ha minst mulig blinkende bilder eller distraheringer. Vi valgte å beholde fargen da oppdragsgivers logo og butikk har samme fargeoppsett. Vi har tilbudt oppdragsgiver karuseller som skulle vise frem bilde av pizza, men dette var ikke noe oppdragsgiver ønsket. Følgende design var prototypen som ble presentert for oppdragsgiver. I denne tidsperioden var designen av produktet under utvikling. Bilde 2.6: Utkast til menyen. Bilde 2.7: Utkast til brukerregistrering. Side 36 Bilde 2.8: Utkast til påloggingsvindu. Bilde 2.9: Utkast til administrasjonsvisning av pizzaer. Bilde 2.10: Utkast til opprettelse av pizza. Side 37 Bilde 2.11: Utkast til infoside med kart. Bilde 2.12.: Forside, med gammel logo. Side 38 2.7.2 Endelig design Ovenfor kan man se bilder av det endelige designet. Bilde 2.11 viser forsiden til pizzaplutselig.no. På dette bildet har logoen øverst til venstre ingen tekst. Oppdragsgiver ønsket en logo med tekst så dette ble senere endret. Oppdragsgiver ønsket også oransje sider, med hvit tekst. Ettersom at vi ville prøve å følge WCAG-standarden angående universell utforming(se 3.6.6, punkt 1.1.1) så godt vi kan, prøvde Vi å argumenterte for at bruk av svart skrift på hvit bakgrunn vil være mer hensiktsmessig, ettersom det vil øke lesbarheten. Vi fikk overbevist oppdragsgiver om å gå for denne løsningen. 2.8 Refleksjoner til produktet 2.8.1 Innledning Arbeidet med dette prosjektet har vært interessant og lærerikt, samtidig som det har vært krevende og utfordrende. Til slutt fikk vi laget et sluttprodukt som både arbeidsgiver og gruppen er fornøyd med. Arbeidet var intensivt og målrettet mot et sluttprodukt som bedriften skulle ha nytte av, og hvor vi lærte å være profesjonelle med å utvikle en webapplikasjon. Gruppen har tilegnet seg god innsikt i hvordan det er å utføre oppgaver for reelle bedrifter fremfor obligatoriske oppgaver vi tidligere har jobbet med. Slik kommer man nærmere samfunnsbehovet og utfordringer som brukere har i sin IT-hverdag. Dette er kunnskap og erfaring som er viktig og som har stor verdi for nyutdannede studenter. 2.8.2 Ting vi ville gjort annerledes Gruppen kan i ettertid si at vi brukte litt lang tid på programmeringen, både back-end og front-end. Samkjøringen mellom programmeringen av disse kunne også vært bedre, og gruppen ville sannsynligvis fått bedre tid til sluttdokumentasjon og testing om vi hadde løst dette bedre i starten. Selv om vi føler det gir et ekstra lag av sikkerhet er vi også usikre på om vi ville lagdelt prosjektet om vi skulle startet på nytt. Vi ville nok også vurdert om vi faktisk skulle programmere i Visual Studio. Vi brukte programmet i faget Webapplikasjoner, og synes det er et ålreit program å bruke, men det viser seg at servere ikke har så god støtte for Microsoft-utviklede produkter. De fleste webhotell bruker Apache for Unix-utviklede programmer, som vårt prosjekt ikke støtter. Side 39 2.8.3 Tverrfaglig utbytte I dette prosjektet arbeidet fikk vi svært god utbytte av tidligere fagkunnskaper vi hadde egnet oss ved Høgskolen i Oslo og Akershus. Kursene har gitt oss en forståelse for å kunne utvikle kunnskapen vår videre. Samtidig måtte vi hente manglende kunnskap og eventuelle informasjon fra internett. Tabellen under er en liste over kurs vi har fått bruk for og hvilket utbytte vi har hatt av dem i dette prosjektet. Kursnavn Kurs-kode Bruksområder i vårt prosjekt Programmering DAPE1400 Webprosjekt Databaser Programutvikling Algoritmer og datastruktur Operativsystemer Systemutvikling Nettverk og systemadministrasjon Webapplikasjoner Datasikkerhet DAFE1200 Programmeringsstrukturer og fordeling av koden i klasser for effektivisering av kode. HTML og CSS, universell utforming og nettsideoppbygging. DATS 1500 Databaseoppbygging og SQL-spørringer. DATS1600 Utvikling av komplekse applikasjoner. DATS2300 Logisk oppsett av datastrukturer og algoritmer i webapplikasjonen for sortering i databasen. DATS2500 Backup og krypteringsmekanismer. DAFE2200 Utviklingsmetodikk og prosjektarbeid. Planlegging. DATS2400 Server og domenekunnskaper ITPE3200 .Net Framework og C#-programmering. ITPE3100 Kryptering og hashing av passord, sikkerhet rundt webapplikasjon Informasjonsarkitektur ADSE2400 Struktur på nettsiden med hensyn til brukervennlighet og arkitektur. Tabell 2.2: Liste over fag som er benyttet for utvikling av prosjektet. Utbyttet vårt har mest vært erfaringene og kunnskapene vi har fått som vi vil benytte oss av i arbeidslivet. Bortsett fra det så har vi lært å være kreative med å tilegne oss kunnskap om ukjente teknologier, og samtidig være nøye med bruk av dem. Vi har også lært hvordan man planlegger og delegerer arbeidsoppgaver og hvordan det er å ha interne og eksterne samhandlinger. Så vi tar med oss kunnskap og erfaringer vi har tilegnet oss i dette prosjektet videre. 2.8.4 Veien videre Oppdragsgiver ventet spent på å ta i bruk den implementerte webapplikasjonen så fort som mulig. Ettersom gruppemedlemmene var usikre på om prototypen egner seg for produksjonssetting per dags dato ble vi enig om å presentere våre bekymringer for Side 40 oppdragsgiver. Etter samtale med oppdragsgiver bestemte vi oss for å vente med produksjonssetting av applikasjonen, da ikke alle funksjonaliteter er implementert samt at designen trenger utbedring. Oppdragsgiver ønsker at utviklingen av webapplikasjonen fortsetter for å legge til manglende funksjonalitet, samt vedlikehold og forbedring av allerede implementerte funksjonaliteter. Både vi og oppdragsgiver ser frem til å få oppgradert webapplikasjonen videre. 2.8.5 Nytteverdi for oppdragsgiver Oppdragsgivers nåværende løsning har vært lite effektiv, med dertil stor grad av frustrasjon. Etter det vi har forstått fra oppdragsgivers føltes det som at endringsprosesser har vært tungvint og meget personavhengig. Av koden ser vi at det er en HTML-side, hvor man må inn i HTML-koden for å endre informasjon. Etter testing av webapplikasjonens prototype viste oppdragsgiver en stor interesse for å ta i brukt et produkt som var skreddsydd for han, noe som vil resultere i bedre bruk av tid og økt produktivitet. 2.8.6 Oppdragsgivers tilbakemelding Pizza Plutselig AS website creation Regarding the creation of website for Pizza Plutselig As, I like to confirm that I have had several meetings with the group and many issues were discussed in our meetings. They have implemented all the important parts which were of my concern, improved the parts which needed extra improvements and they are still in contact with me in order to complete the requirements. I, therefore, like to thank them for the good job they have done. Pizza Plutselig As Mansor Jam 22469222 / 95479009 2.8.7 Oppsummering og konklusjoner Gruppen er fornøyd med hele prosessen, alt fra valg av oppgave, utfordringer knyttet til utviklingen og frem til ferdigstilling av rapporten. Vårt valg av utviklingsverktøy og utviklingsmetodikk egnet seg til oppgaven og gruppen. Vi ser webapplikasjonen som et vellykket og ferdig produkt da den dekker alle kravene som ble satt i begynnelsen av planleggingsfasen. Side 41 2.9 Risiko og svakheter Prosjektet er ressurskrevende og kan ha økonomiske påvirkninger når det kommer til anskaffelse av utstyr og arbeidskraft. I startfasen jobber hele gruppen med dette prosjektet men ettersom vi har frist for å levere oppgaven er det ikke sikkert at vi rekker å fullføre alle kravspesifikasjoner som kommer gjennomveis. Da blir oppdragsgiver nødt til å betale et firma for videreutvikling av webapplikasjonen. For at webapplikasjonen skal kunne brukes er vi nødt til å leie webhotel hos en leverandør som tilbyr IIS løsning og MS SQL database. Dette vil bli noe dyrere å drifte og vil derfor ha økr kostnad for oppdragsgiver. Tidligere erfaringer og prosjekterer viser at det er få prosjekter som blir tatt i bruk etter lanseringutgivelse og på bakgrunn av dette anbefaler vi at det tas en grundig gjennomgang over kravspesifikasjoner og analyse av produktet før man investerer videre i prosjektet. Gruppen har stor tro på at prosjektet lykkes dersom det planlegges og analyseres riktig, samtidig som man er bevist på at endringer kan skje underveis. Risiko Forklaring Sannsynlig- het Konsekvens Tiltak Gjennom- føring av alle krav i kravspesi- fikasjonen At alle krav som er satt fra begynnelsen og eventulle krav som har kommet underveis ikke blir fullført. 30% Hele eller deler av prosjektet blir mislykket. Utføre krav med prioritet A slik oppdragsgiver kan ta i bruk webapplikasjonen da disse kravene var meget viktig. Dessuten tilrettelegge applikasjonen slik den kan utvikles senere av andre utviklere. Over- stigning i budsjettet Egenkapital og økonomiske støtte ikke rekker på grunn av komplikasjoner og driftskostnader 5% Webapplikasjonen blir Få en prisoveslag over kostbart å drifte. leverandører som tilbyr drifttjenester og velge den mest aktuelle i henhold til pris og tilgjengelighet. Anklaget for plagiat Andre har allerede utviklet den samme ideen både i Norge eller
andre land. 1% Man kan fort komme i Laget egen CMS løsning for en rett sak for oppdragsgiver. copyright. Samt kan den ha økonomiske konsekvenser Nettsiden blir Personlige informasjon hacket blir misbrukt av en hacker. 30% Personlig informasjon
blir brukt i ulovlige sammenhenger. Nettsiden blir utilgjengelig eller deaktivert. Tabell 2.3: Liste over risiko og tiltak knyttet til prosjektet. Side 42 Tvinge brukere til å kommunisere via https og passordsjekking for databaseaksess. Side 43 Kapittel 3 - Produktdokumentasjon 3.1 Forord Dette kapittelet tar for seg de viktigste elementene i løsningen, og prøver å gi en helhetlig forståelse av applikasjonen. Det inneholder forklaring av hensikten med løsningen, og dens fordeler og ulemper i forhold til alternative løsninger som finnes på markedet. Det inneholder også forklaringer på de forskjellige komponentenes oppgaver, og deres plassering. Det vil først og fremst gi en forklaring av det endelige produktet, ikke en dybdeanalyse av teknologien bak. For en teknisk evaluering, les kapittel 7. 3.2 Beskrivelse av webapplikasjonen 3.2.1 Kort om Webapplikasjonen har som hovedformål å presentere informasjon og nyheter om restauranten Pizza Plutselig. Kunder skal kunne finne informasjon om produkter og priser, åpningstider, og eventuelle nyheter. Hensikten med løsningen er at oppdragsgiver enkelt skal kunne redigere innholdet i siden, etterhvert som for eksempel prisene i restauranten endres, eller om det er forandringer i åpningstidene. Målet med løsningen er å forenkle oppdragsgivers hverdag, samtidig som den gir han noen valgmuligheter i forhold til nettsidens utforming. Slik hans nåværende situasjon er, må han kontakte utvikler for å gjøre endringer. Videre er hensikten å kunne tilby bestilling fra applikasjonen. Det vil gi kundene muligheten til å registrere en bruker, med informasjon om utleveringsadresse om ønskelig. 3.2.2 Byggeklosser Webapplikasjonen er utviklet i Microsoft sitt .Net-rammeverk, med en SQL-database for lagering av informasjon. C#, HTML5, Bootplus ​
(CSS), AngularJS (JavaScript) er språkene og rammeverkene tatt i bruk under utvikling av produktet. Side 44 Plassering # Oppgave Back end Front end Øvrig Navn 1 Applikasjons -rammeverk Microsoft .NET Framework ASP.NET MVC 5 2 MVC-rammeverk 3 Database SQL, LINQ, Entity Framework 4 Back end språk Microsoft visual C# 5 Funksjonalitet i view. JavaScript (AngularJS) 6 Visning av hypertekst HTML5 7 Design CSS3 (Bootplus) 8 Overføring av data JSON Tabell 3.1: Plassering av komponenter. Kommentar .Net Framework er et rammeverk for utvikling av webapplikasjoner. ASP.NET MVC 5 er rammeverket som har blitt brukt til å implementere MVC strukturen. SQL Database. Lagring av data. Med linQ syntax, strukturert ved hjelp av Entity Framework. Programmeringsspråket C# (C-Sharp) har blitt brukt for å utforme backend. AngularJS er et JavaScript rammeverk for single page applikasjoner. Brukt til å utvikle en RESTful webapplikasjon. HTML5 er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. Bootplus er brukt til design av nettsiden. CSS-rammeverk som bygger på Bootstrap. JSON har blitt brukt til overføring av data mellom databasen og modellene. Kort forklaring av de forskjellige rammeverkene og språkene tatt i bruk under utvikling av prosjektet: 1. .NET Framework (lest dot net) er et utviklings​
rammeverk fra Microsoft som primært kjører på Windows-platformer. Rammeverket inneholder et stort klassebibliotek kjent som Framework Class Library (FCL). Det er designet for å forlenge Common Language Runtime (CLR), som er en virtuell enhet som tar seg av utførelsen av .NET programmer. Disse to (FCL og CLR) er hovedkomponentene i rammeverket. Rammeverkets hensikt er å forenkle systemutvikling. 2. ASP.NET MVC 5 er rammeverket som har blit tatt i bruk for å implementere MVC-strukturen i applikasjonen. ASP.NET støtter tre forskjellige utviklingsmodeller: Websider, MVC (Model View Controller) og Web Forms. 3. SQL er et programmeringsspråk designet for å håndtere data som er lagret i en relasjonsdatabase. Applikasjonen bruker en relasjonsdatabase, med linQ-syntax for å utforme spørringene. Databasen blir opprettet etter “code first”-prinsippet, ved hjelp av Entity Framework, som er en del av .NET. 4. C# ​
(les C Sharp) er programmeringsspråket som har blitt brukt til å utforme “back end”-komponenter i løsningen. For eksempel funksjoner som hånderer databaseaksess. Side 45 C# er e​
t ​
programmeringsspråk som omfatter imperativ, deklarative, funksjonelle, generiske, objektorientert (klasse-basert), og komponentorientert programmering disipliner. Det er ment å være en enkel, moderne, generell, objekt orientert programmeringsspråk. 5. Angular​
Js ​
er et strukturelt rammeverk for dynamiske webapplikasjoner, utviklet og vedlikeholdt av Google. Den lar deg bruke HTML som mal, og utvide HTML syntaks for å uttrykke programmets komponenter klart og konsist. t​
o-veis data binding og “​dependency injection”​
eliminerer mye av koden man ellers ville h​
a skrevet. 6. HTML5 er e​
t markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. HTML er brukt for å strukturere og presentere innhold for World Wide Web. 7. Bootplus er e​
n fri og åpen kildekodesamling. Det er et CSS-rammeverk som bygger på Twitter Bootstrap​
, og inneholder CSS-baserte designmaler for typografi, skjemaer, knapper, navigasjon og andre grensesnittkomponenter, samt valgfrie Javascript-utvidelser. Dette rammeverket har som mål å ​
forenkle​
webutvikling. Bootplus forenkler arbeidet med å gjøre nettsiden responsiv, altså at siden skal se bra ut med forskjellige størrelser. 3.3 Sentrale datastrukturer i applikasjonen 3.3.1 Innledning For å få en bedre forståelse av applikasjonen, er det essesiellt å forstå de grunnelggende strukturene applikasjonen er bygget etter. Den viktigste hovedstrukturen som har blitt fulgt er model-view-controller, som har blitt implementert ved hjelp av ASP.NET MVC 5. Databasen har blitt strukturert ved help av Entity Framework, og ved hjelp av rettningslinjer som kalles normalisering. Dette er ingen teknisk forklaring av disse strukturene. For teknisk evaluering les kapittel 7. 3.3.2 MVC MVC står for Model-view-controller. Det er et designmønster som deler programmet opp i en modelldel, hvor koden som kjører programmet ligger, en view-del, hvor utseendet ligger og controlleren, som kommuniserer mellom modellen og view-et.8 MVC-mønsteret ble først formulert av Trygve Reenskaug, professor emeritus ved Universitetet i Oslo. Vi har brukt rammeverket ASP.NET MVC 5 for å implementere MVC i koden vår. Lagdelingen MVC tilby gir gode vilkår for noen som eventuellt skal videreutvikle applikasjonen. Model Modellene representerer objektene som behandles i webapplikasjonen. Man kan ha fast struktur på objektene man initierer ved å gjenbruke en modell. Dette vil også bidra med å kunne gjenbruke koder flere steder i webapplikasjonen. 8
Model-view-controller. (2013). ​
Wikipedia.​
Hentet fra ​
http://no.wikipedia.org/wiki/Model-view-controller Side 46 En model varsler sine tilknyttede views og controllere når en endring finner sted. Dette vil resultere at views produserer oppdaterte data som blir vist til nettleseren. View Den visuelle delen av applikasjonen som møter brukere kalles views. Viewene får sine data fra controllere i form av modeller og omformer de til HTML som igjen vises i brukerens nettleser. Alle handlinger i webapplikasjonen er knyttet til et view, hvor mye av innholdet som brukeren får frem på siden er avhengig av hvilken tilstand modellen det blir forespurt om befinner seg i. Controller En controller kan sende kommandoer til modellen for å oppdatere modellens tilstand (for eksempel redigere navnet på et produkt). Den kan også sende kommandoer til det tilknyttede View-et for å endre visningen av modellen (for eksempel ved å bla gjennom menyen). Controllere har koordineringsansvaret som tar imot henvendelser fra brukeren og henter frem alle modeller som skal til for å generere etterspurt side, og eventuelle annen data som skal vises. Figur 3.1: Kommunikasjon mellom lagene i webapplikasjonen. (MVC Model). 1. En bruker leser View, som presenter model. 2. Ved hjelp av to-veis databinding blir view og model oppdatert dynamisk. Det vil si at når et view endres av bruker vil endringene forplante seg til model, og motsatt. 3. AngularJS setter utgangspunktet for scope-objektene, og gir de atferd. Angular-scopet er limet mellom klient (View) og server (AngularJS). 4. Når model lagres til databasen blir objektene JSON-serialisert og sendt via controller til databasen. 5. Når en bruker henter data fra databasen blir model fyllt av data som hentes på samme måten som punkt 4. Side 47 3.3.3 De sentrale modellene Item (Gir arv til pizza og tilbehør) Item er modellen for varene i applikasjonen. Denne er kun en overordnet modell som gir arv videre til modellene for pizzaer og andre varer som selges hos oppdragsgiver. Enhver vare som er representert i menyen i restauranten følger item-mønsteret. Ingredient Dette er modellen for ingredienser man kan velge til en pizza i restauranten. Denne brukes når oppdragsgiver oppretter en pizza til menyen. Han velger navn på pizzaen, pris for de forskjellige størrelsene, og ingrediensene som hører til git pizza. Relasjonene mellom pizza og ingrediens lagres i en relasjonstabell, “IngredientsInPizza”. Planen er å også ta i bruk denne modellen når bestilling blir implementert. Da kan en kunde velge en egenkomponert pizza hvor de selv kan velge mellom alle ingrediensene. Denne funksjonaliteten ligger på vent til vi har utviklet en tilfredstillende måte å presentere bestillinger for oppdragsgiver. Les mer om dette i delkapittel 3.9. “Samsvar mellom kravspesifikasjon og det ferdige produktet”. Admin Modell som representerer en administrator i applikasjonen. Denne inneholder kun epost og passord. Muligheten til å opprette, eller endre en admin er ikke implementert i koden. Det er opprettet egen tabell for admin av sikkerhetsmessige årsaker. User Representerer en kunde i applikasjonen. Gir kunder muligheten til å sende inn en bestilling via applikasjonen (ingen betaling), og registrere utleveringsadresse om ønskelig. Er ikke implementert på nåværende tidspunkt. Order Modellen for en bestilling. Blir tatt i bruk for å utforme en bestilling, som inneholder varer (Items), en sluttsum og en dato. Enhver bestilling er knyttet til en bruker (kunde). Denne er på nåværende tidspunkt ikke implementert, men er ferdig utviklet. Les mer om dette i delkapittelet 3.9. Og for en teknisk evaluering av problemstillingen les delkapittel 7.8.1. Infopage Målet var å gi oppdragsgiver muligheten til å redigere navigasjonsmenyen. Derfor opprettet vi “Infopage” hvor informasjon om restauranten kan deles opp i ulike sider, som lagres til databasen. Disse sidene vi utforme navigasjonsmenyen, sammen med noen fastsatte menyvalg, som for eksempel “meny” for pizzamenyen. Slik kan oppdragsgiver enkelt redigere, legge til, eller fjerne informasjonssider fra siden sin. Et eksempel på en slik siden kan være “Åpningstider”. Side 48 News Modell for nyheter. Oppdragsgiver ønket muligheten til å legge ut nyheter om restauranten. Som for eksemplel endringer i åpningstidene. Han ønsket også muligheten til å fjerne gamle nyheter, eller redigere eksisterende nyheter om noen av de ble feil eller upresise. 3.3.4 Modellrelasjoner Admin har relasjon til Infopages, og News. Hver Infopage og News blir lagret av en admin. Dette er for å kunne loggføre, og holde oversikt om oppdragsgiver velger å gi adminrettigheter til andre enn seg selv. Items har relasjoner til Ingredients og Orders. Til Ingredients, fordi en pizza skal ha ingredienser. Til Orders for betillinger. Users har relasjon til Orders for bestillinger. Dette er hovedrelasjonene mellom modellene i applikasjonen. Se illustrasjon i kapittel 7. 3.3.5 Funksjoner og metoder Dette underkapittelet vil gi en oversikt over handlinger som kan utføres av applikasjonen. Adminhandlinger Adminhandlinger er handlinger som utføres av administratoren. Dette kan være å opprette, endre og slette pizzaer, ingredienser, tilbehør, nyheter, navigasjonsmeny. I den versjonen hvor admin har bestillingsmuligheter kan han endre og slette brukere og resette passord. Disse handlingene kan kun utføres av brukere med administratorrolle. Besøkende - Kundehandlinger Besøkshandlinger er handlinger som utføres av personer som besøker nettsiden. Dette kan være alt fra de som skal handle til de som skal få informasjon. Tabell AT = Admintilgang, FT= Fri tilgang, IF= Implementert funksjon, RF= Reservert funksjon som kan implementeres senere ved ønske. Handling Beskrivelse A
F
I
R
T T F F start Laster databasen ved første besøk x x x getAdminForm Skjema for registrering av admin x createAdmin Opprett ny administrator x getRegForm Skjema for registrering av bruker x x createUser Opprett ny bruker x x getAllUsers Henter alle brukere x x deleteUser Slett bruker x x getUserToChange Henter bruker for endring x x changeUser Endrer bruker x x getLoginForm Henter skjema for innlogging x x x login Brukerinnlogging x x logout Utlogging x x x getLoginFormAdmin Henter skjema for innlogging for adminer x Side 49 loginAdmin Admininnlogging x x getInfoForm Henter skjema for ny infoside x x createInfoPage Oppretter ny infoside x x getAllInfoPages Henter alle infosider x x x getInfoPage Henter én infoside x x x getAllInfoPagesAdmin Henter alle infosider for adminbruk x x deleteInfoPage Sletter infoside. x x getInfoPageToChange Henter infoside for endring x x changeInfoPage Endrer infoside x x getNewsForm Henter skjema for ny nyhetsside x x createNews Oppretter nyhetside x x getAllNews Henter alle nyheter x x x getAllNewsAdmin Henter alle nyheter for adminbruk x x getNewsText Henter én nyhet x x deleteNews Sletter en nyhet x x getNewsToChange Henter nyhet som kan endres x x changeNews Endrer nyhet x x getItemForm Henter skjema for tilbehør x x createItem Oppretter et nytt tilbehør x x getAllItems Henter alt tilbehør x x x getAllItemsAdmin Henter alt tilbehør for adminbruk x x deleteItem Slett tilbehør x x getItemToChange Henter tilbehør for endring x x changeItem Endrer tilbehør x x getPizzaForm Henter skjema for pizza x x addIngredient Legger til ingerdiens i pizza x x removeIngredient Fjerner ingrediens fra en pizza x x createPizza Oppretter pizza x x getAllPizzas Henter alle pizzaer x x x getAllPizzasAdmin Henter alle pizzaer for adminbruk x x deletePizza Slett pizza x x getPizzaToChange Henter pizza som kan endres x x changePizza Endrer pizza x x getIngredientForm Henter skjema for ingrediens x x createIngredient Oppretter ingrediens x x getAllIngredients Henter alle ingredienser x x x getAllIngredientsAdmin Henter alle ingredienser for adminbruk x x deleteIngredient Slett ingrediens x x getIngredientToChange Henter ingrediens som kan endres x x changeIngredient Endrer ingrediens x x Tabell 3.2: Liste over alle handlinger. Side 50 3.4 Lagdeling 3.4.1 Hvorfor lagdeling Hovedgrunnen til at applikasjonen er lagdelt er at det vil forenkle utvikling og videreutvikling av systemet.9 Ved å lagdele applikasjonen med et dataaksesslag og et forretningslogikklag vil man forhindre at eventuelle oppdateringer og videreutvikling vil tvinge utvikler til å måtte omskrive flere deler av systemet. Kort sagt er målet å isolere presentasjonslagskoden, database-koden og forretningslogikken fra hverandre. Dette begrepet kalles “Loose coupling”. 10
Figur 3.2: Oversikt over hvordan lagdelingen er strukturert. 3.4.2 Lagdeling i MVC I MVC-arkitekturen deler man applikasjonen opp i Model (forretningslogikk), View (presentasjonslag) og Controller (dataaksess). Dette er en struktur som går godt overns med lagdelingen vi har valgt for applikasjonen. Et dataaksesslag, et forettningslogiklag, og modeller. Kontroller i en lagdelt applikasjon. Oppgaven til en kontroller er å kommunisere mellom lagene. Den tar i mot handlinger fra presentasjonslaget (View), og sender de videre til forretningslogikklaget (BLL). Forretningslogikklaget (BLL) og modellene. Modellene i løsningen er designet etter forretningslogikken. Det vil si at modellene representerer aktører, varer og øvrige objekter i oppdragsgivers foretak, som for eksempel en pizza. Disse modellene blir fylt med data fra en database, og presentert i presentasjonslaget (View). Forretningslogikklaget (BLL) tar seg av spørringer fra modellene til dataaksesslaget (DAL).11 Dataaksesslaget (DAL). Dataaksesslaget har som oppgave å hente lagret data fra for eksempel en database. Tar i mot spørringer, og sender etterspurt data til modellene, via forretningslogikklaget (BLL).12 Stack Overflow. (2008). ​
What is the purpose of a Data Access Layer?​
Hentet fra http://stackoverflow.com/questions/59942/what-is-the-purpose-of-a-data-access-layer 10
Loose coupling. (2015). ​
Wikipedia. ​
Hentet fra ​
http://en.wikipedia.org/wiki/Loose_coupling 11 ​
Business Logic. (2015). ​
Wikipedia.​
Hentet fra ​
http://en.wikipedia.org/wiki/Business_logic 9
12
Data Access Layer. (2015). ​
Wikipedia.​
Hentet fra ​
http://en.wikipedia.org/wiki/Data_access_layer Side 51 3.5 Programmets virkemåte 3.5.1 Oppstart av webapplikasjonen Når en bruker navigerer til siden pizzaplutselig.no vil han få opp visningen av index.html. Her vil applikasjonen starte lasting dra databasen for å fremvise navigasjonsmenyen og pizza-menyen. AngularJS-kontrolleren definerer modellene og fyller data fra databasen. Viewet viser modellene i nettleseren. Samme skjer for en admin, men admin må manuellt navigere til admin.html, hvor man vi få muligheten til å gjøre en admin-innlogging. Etter innlogging får man tilgang til et adminpanel, med valgmuligheter for styring av CMS-løsningen. 3.5.2 Admin i nettleseren Administratorhandlinger vil kun være tilgjengelig i admin.html-delen av applikasjonen. Vi valgte å lage egen admin.html, som en midlertidig løsning på noen sikkerhetsproblemer angående visninger i applikasjonen. Les mer om dette i delkapittel 7.8. 3.5.3 Kundehandlinger i bruk Alle kundehandlinger vil skje i www.pizzaplutselig.no/index.html, som er siden man blir navigert til når man skriver pizzaplutselig.no i nettleseren. Her vil ingen adminhandlinger være tilgjengelig. Ettersom applikasjonen er “single-page” vil alt skje i samme .html-visning. JavaScript avgjør hva som blir presentert for brukeren, etterhvert som han/hun utfører handlinger i applikasjonen. Les mer om JavaScript (AngularJS) i kapittel 7. 3.5.4 Spesifikke handlinger i bruk Et eksempel på en admin-handling er opprettelse av en pizza til pizza-menyen. Man velger handlingene ut fra et admin-panel. Figur 3.3: Administratorhandling, opprette pizza. Side 52 Velger handlingen “Create Pizza”. 1. Fyller ut modellen. 2. Når man lagrer skjer en admin-sjekk. 3. Lagrer pizza til databasen. Et eksemplel på en kundehandling kan være å bestille varer. Man velger handlinger fra navigasjonsmenyen. Figur 3.4: Brukerhandling, bestilling. 1.
2.
3.
4.
5.
Man velger produkter fra pizza-menyen, og eventuellt tilbehør. Velger til bestilling. En sjekk om man er logget inn, for å kunne fullføre en bestilling. Eventuell innlogging/registrering av ny bruker. Fullfører bestillingen, som blir lagret i databasen og sendt til restauranten. 3.6 Design 3.6.1 Innledning I denne delen av dokumentasjonen vil det bli gått nærmere inn på valg tatt i henhold til design, brukergrensesnitt og brukeropplevelse. Det har blitt utført en brukertest med oppdragsgiver som kan leses under testdokumentasjonen, kapittel 4. 3.6.2 Oppdragsgivers ønsker Gruppen valgte fra starten av prosjektet å involvere oppdragsgiver i designprosessen. Ved å la oppdragsgiver ta del i denne prosessen ville vi lettere kunne oppnå ønsket resultat, samtidig som oppdragsgivers ønsker ble ivaretatt. Oppdragsgiver ønsket å beholde deler av designet fra den nåværende løsningen, som for eksempel bakgrunnsfarge, font, bilder og en navigasjonsmeny. Vi har hatt to til tre møter vedrørende design av produktet med oppdragsgiver der han gav oss gode tilbakemeldinger på hva slags design han så for seg, samt endringer og forbedringsforslag til designet underveis i utviklingen. Side 53 3.6.3 Brukergrensesnitt (UI) Oppdragsgiver hadde ønske om å ivareta farger og skrifttype da det skulle samsvare med butikkens fargesetting og logo. Disse kravene kom allerede i planleggingsfasen og la grunnlaget for vårt design. Det ble presentert muligheten til å sette animasjoner og rullerende bilder i nettsiden, men oppdragsgiver ønske ikke dette. Derfor valgte vi å fokusere på elementer som rette linjer og gode kontraster for å skape et oversiktlig og rent bilde av webapplikasjonen. Bilde 3.1 : Bilde av oppdragsgivers restaurant. 3.6.4 Brukeropplevelse (UX) Vi har bedt fire brukere (kunder) teste webapplikasjonens grensesnitt. Testen gikk ut på funksjonalitet, enkelhet, design og tilgjengelighet. Resultatet er dokumentert i kapittel 4 under delkapittel 4.3.3. 3.6.5 Responsivt design (optimalisert for alle enheter) Å utvikle en responsiv og dynamisk nettside var ikke en del av kravene vi ble gitt fra oppdragsgiver. Men vi vurderte at dette var nødvendig, da mange bruker nettbrett og mobiltelefon til å lese nettsider. Ved å utvikle en responsiv løsning fikk vi muligheten til å fokusere på et produkt fremfor flere. Dette vil også forenkle oppdragsgivers hverdag ettersom han kun må gjøre endringer et sted. 3.6.6 Universell utforming Siden vi lever i en verden med forskjellig behov er det nødvendig å utvikle et produkt som følger kravene for universell utforming.13 Dette var ikke et krav fra oppdragsgiver, men det var naturlig at vi studenter formet nettsiden i denne retningen. Direktoratet for forvaltning og IKT. (2014). ​
Krav til nettløsninger (WCAG).​
Hentet fra http://uu.difi.no/veiledning/nettsider/krav-til-nettlosninger/krav-wcag 13
Side 54 Nedenfor er en tabell med WCAG-kravene som er relevane for applikasjonen, og hvordan vi har oppfyllt disse. WCAG-krav nr Kravbeskrivelse (WCAG) Implementering i prosjekt 1.1.1 Ikke-tekstlig innhold Alt ikke-tekstlig innhold som presenteres for brukeren, har et tekstalternativ som har samme formål, med unntak av noen få situasjoner. Når rekkefølgen som innholdet presenteres i, påvirker meningsinnholdet, kan en korrekt leserekkefølge bestemmes programmeringsmessig. Farge blir ikke benyttet som det eneste visuelle virkemiddelet for å formidle informasjon, angi en handling, be om respons eller skille ut et visuelt element. Med unntak av teksting og bilder av tekst kan tekst forstørres opp til 200 % uten bruk av kompenserende teknologi og uten at innhold eller funksjonalitet går tapt. Hvis teknologien som brukes kan håndtere den visuelle presentasjonen, brukes det tekst i stedet for bilder av tekst til å formidle informasjon, unntatt i 2 tilfeller. Standard naturlig språk på hver webside kan bestemmes programmeringsmessig. I applikasjonen har det blitt tatt hensyn til døve og blinde ved å presentere all tekst lesbar for tekst til tale verktøy. Blant annet: (​
http://www.readspeaker.com/nb/​
) 1.3.2 Meningsfylt rekkefølge 1.4.1 Bruk av farge 1.4.4 Endring av tekststørrelse 1.4.5 Bilder av tekst 3.1.1 Språk på siden Applikasjonen har blitt utviklet slik at det skal være mulig å legge opp viktig informasjon der det er mest relevant. Alle handlinger i applikasjonen er markert med tekst. Slik at fargesvake også skal kunne forstå hensikten med valget. Applikasjonen har et brukergrensesnitt som lar brukere forstørre teksten ved hjelp av nettleseren. Vi har prøvd å unngå tekst i bilder. Bortsett fra det ene kravet fra oppdragsgiver som var bildet under kart. Applikasjonen tar i bruk norsk bokmål som nettsidespråk for kunder. Administrasjonsdelen er skrevet på engelsk ettersom dette er språket oppdragsgiver er mest komfortabel med. Vi har tatt hensyn til kunder med dysleksi, ved å bruke en lett lesbar skrifttype. Side 55 3.3.3 Forslag ved feil Hvis en inndatafeil oppdages automatisk og det finnes forslag til hvordan den kan rettes, presenteres forslagene for brukeren, med mindre dette innebærer risiko for sikkerheten eller formålet med innholdet. Når man taster inn feil type tekst eller unnlater å skrive symboler og antall minimale og maksimale tegn vil vedkommende få beskjed på skjermen. Det gis beskjed til brukeren når vedkommende taster feil brukernavn og passord. Tabell 3.3: Universell utforming innført i prosjektet sammenlignet med WCAG. 3.6.7 Rammeverk og teknologier tatt i bruk Det er tatt i bruk følgende teknologier og rammeverket i designprosessen: Teknologinavn Bootplus Angular Bitter (font) Beskrivelse Et CSS-rammeverk som gir større og bedre funksjons- muligheter. Et JavaScript-bibliotek som lar oss utvide vårt program raskere, mer lesbar. Rammeverket fungerer godt med andre bibliotek. En font vi fant på Google Fonts. Tabell 3.4: Design og rammeverk. Hvor er den brukt Brukes for å gi utseende til HTML-filene. Brukt til å uttrykke bilder, animasjon og opplasting av data i en mer elegant måte. Brukt til visning av tekstene i webapplikasjonens. 3.7 Sikkerhet 3.7.1 Passordsikring For å sikre passordene har vi valgt å lagre en hashet versjon av passordene i databasen. Inputfeltene har “type = password” satt, slik at passordene ikke vises i plain text i nettleseren. Dette for å sikre at passordene kan bli lest av uvedkommende. Såkalt “social engineering”. Les mer om sikring av passord i kapittel 7. 3.7.2 Databasesikkerhet Databasen blir opprettet av applikasjonen når den prodsettes. Planen er at det skal bli lagret sikkehetskopier av databasen hver dag. For mer informasjon se delkapittel 7.9.2, hvor vi har forklart hvilke databasetyper levereandøren tilbyr og hvordan det er tenkt satt opp. Side 56 3.7.3 Backup og Rollback-plan Gjennom prosjektet: For å forhindre eventuelle uhell, blant annet tap av programkoder og dokumentasjon, har vi benyttet oss av Bitbucket for å ta backup. I tillegg har gruppen hver sin lokale backup i egen datamaskiner, samt at vi ofte har kopiert viktige koder og dokumenter relatert til prosjektet i Dropbox-mappen. Det å kunne ha en trygg backup av prosjektet til enhver tid var essensielt og en meget viktig del av utviklingen. I begynnelsen av prosjektet har gruppen blitt enig om å ta høyde for følgende utsagn: ● Hva om Bitbucket skulle legges ned eller være utilgjengelig. ● Hva om Visual Studio skulle krasje og prosjektet bli korruptert eller tapt. ● Hva om våre pc-er skulle kræsje eller bli utsatt for tyveri eller annet uhell. ● Hva om vi endrer informasjonen i koden og kommer i konflikt med andre gruppe- medlemmers programoppdateringer. ● Hva om en av gruppemedlemmene blir utsatt for ulykke og dermed blir utilgjengelig. Slike gjenopprettingspunkter har vært til stor hjelp da en av gruppemedlemene uheldigvis var utsatt for diskkræsj på pc-en sin. Bootmanager var ikke tilgjengelig for å starte opp pc-en, noe som resulterte i full formatering av harddisk og reinstallasjon av operativsystemet. Et annet tilfelle var at hver gang Visual Studio kræsje, kunne gruppen klone eller synkronisere prosjektet. De siste endringer man har gjort før krasjet som ikke var synkronisert gikk tapt. Etter at prosjektet er levert: Etter avtale med oppdragsgivers leverandør ble vi enig om å ta backup av filene en gang per døgn i form av snapshots av hele miljøet. Dette kan hjelpe kunden å gå tilbake til en tidligere versjon dersom uhellet skulle oppstå. Leverandøren nevnte at det tas daglige backup av webløsninger de har installert da dette inngår i avtalen. 3.8 Systemkrav 3.8.1 Klient Webapplikasjonen er nettbasert og for at denne skal aksesseres trenger vi en nettleser med JavaScript støtte. Applikasjonen er implementert hos oppdragsgivers IT leverandør og vil være tilgjengelig bare når man har internettforbindelse, da denne er lastet opp i en Windows server med IIS Støtte i skyen. Applikasjonen har et dynamisk designprinsipp og vil skalerer seg til ulike skjermstørrelser uavhengig av enheten. Side 57 Vi anbefaler å bruke den nyeste versjonen av følgende nettlesere: Google Chrome, Internett Explorer, Mozilla Firefox, Opera eller Safari. 3.8.2 Server Siden .net Framwork er et Microsoft-produkt, er det naturlig å bruke Windows IIS webserver. Servere som er kompatible med vår webapplikasjon er Windows server 2003 med alle Service Pack, 2008, 2008 R2, 2012 og 2012 R2 i alle edition fra Standard til Enterprice og krever IIS 6 eller nyere. Vi foretrekker å bruke Windows-server på grunn av optimalisering, effektivitet og integrasjonsmuligheter. Vi er ikke bundet til Windows da det finnes andre alternativer dersom man ønsker å kjøre applikasjonen i et Unix-miljø. Et velkjent system er Mono, som kan kjøres på Apache eller Tomcat i et Unix-miljø, og som gir oss samme mulighet som Windows Server IIS. 3.9 Samsvar mellom kravspesifikasjon og det ferdige produktet I den opprinnelige kravspesifikasjonen var det primært ønsket fra oppdragsgiver å kunne redigere all informasjon på nettsiden. Kravspesifikasjonen bestod av en liste med funksjonelle og ikke-funksjonelle krav som vi kom frem til i samarbeid med oppdragsgiver. Kravene ble prioritert med bokstaver fra A til C etter hvor essensielle de forskjellige kravene var (se 2.5.1). Alle A-prioritetskravene ble utført og levert til oppdragsgiver i første utkast av webapplikasjonen. Krav med B- og C-prioritet er kodet, men ikke alle er implementert (se 8.2.1). Vi vil se på muligheten for å implementere de resterende hvis oppdragsgiver bestemmer seg for å ta de i bruk. Det viktigste B-kravet var bestillinger. Dette var et krav vi i utgangspunktet hadde satt som et A-krav, men senere endret til B, etter oppdragsgivers ønske. Planen var å sende bestillinger via mail. Vi ble senere gjort oppmerksomme på at dette ikke ville oppfylle oppdragsgivers ønsker. Ettersom oppdragsgiver ofte er på jobb alene har han ikke kapasitet til å holde oversikt over mange kilder for bestillinger inn til restauranten. Vi ble derfor nødt til å se etter andre løsninger for hvordan vi enkelt kan presentere bestillingene. Det har vi ennå ikke funnet. For en teknisk evaluering av denne problemstillingen les delkapittel 7.8.1. 3.10 Fordeler og ulemper med en skreddersydd applikasjon Vi vurderte fordeler og ulemper ved å lage en skreddersydd applikasjon fremfor en standardisert løsning. En ulempe ved en egenutviklet applikasjon vil være oppdateringer. De standardiserte løsningene vil kunne tilby jevnlige oppdateringer av programvaren, noe vi ikke kan garantere. Problemet med en slik løsning er at oppdragsgiver ikke er veldig datakyndig. Han ønsket seg derfor en enklere løsning enn de som finnes på markedet. Derfor valgte vi å skreddersy en Side 58 løsning etter oppdragsgivers ønsker. Sikkerheten har også vært dårlig i de standardiserte løsningene, spesielt ved de eksterne utvidelsene. Les mer om dette i delkapittel 2.2.4. Side 59 Kapittel 4 - Testdokumentasjon 4.1 Forord I testdokumentasjonen skal vi gå i dybden på hvordan tester kan utføres, og hvorfor man tar i bruk forskjellige typer tester under prosjektutviklingen. Det finnes flere forskjellige tester man kan utføre for å se om de ulike delene i webapplikasjonen fungerer som de skal. Det er i utgangspunktet tre forskjellige tester vi skal gjøre rede for i dette dokumentet. Dette er enhetstesting, brukertesting og ad hoc-testing. 4.2 Enhetstesting 4.2.1 Formål med testen Enhetstesting vil foregå i koden som ligger i bakgrunn. Her vil man gå gjennom alle funksjonene som webapplikasjonen er bygget opp av, det vil si at man vil lage testvariabler som er av samme oppsett som koden, for å sjekke om man får ut de sluttverdiene man er ute etter. I tillegg til å se etter feil i programmet, er enhetstesting også veldig nyttig som en slags dokumentasjon for videreutviklere som skal legge til funksjoner i programmet. Enhetstesting er veldig populært, grunnet at man kan finne hull eller bugs i koden man ikke kan finne så lett ved å teste «manuelt» i nettleseren for eksempel. 4.2.2 Utførte tester I prosjektet har vi prøvd å legge vekt på å teste programmet i sin helhet. Dette føler vi er svært viktig når vi har planlagt å utvikle et robust produkt som vi vil skal være så feilfritt som mulig. Metoder som manipulerer datafelter i databasen vil vi teste så mye som mulig, ettersom det å legge inn informasjon og å hente ut informasjon fra databasen, er en stor del av prosessen i webapplikasjonen. Eksempler på dette kan være å hente ut alle brukere i databasen, å legge til brukere i databasen eller å endre en bruker fra databasen. 4.2.3 Gjenstående testing I forhold til minstekravet oppdragsgiver la frem har vi implementert alt av funksjonalitet og design som trengs. Når det kommer til gjenstående testing, vil det for det meste bestå av funksjoner som vi hadde planer om å videreutvikle på siden. Dette er funksjoner som for Side 60 eksempel å opprette en vanlig brukerkonto, samt det å legge til og endre varer man har lagt til i handlekurven. Fremgangsmåten for å teste disse metodene ville vært tilsvarende de forrige enhetstestene vi har utviklet i prosjektet. 4.2.4 Utforming av testen Vi har valgt å lage en egen mappe som heter «Test» i prosjektet, som inneholder alle scriptene vi vil teste. Dette er for å gjøre det mer oversiktlig enn å bare ha testscriptene lagt inn sammen med alle de andre filene i prosjektet. Bilde 4.1: Oversikt over testene. Når man skal enhetsteste i AngularJS er det viktig at metodene man vil bruke fra andre script er gjort tilgjengelige (ekvivalent av å gjøre “public”) for selve testscriptet. Dette er fordi enhetstesten krever metoder som skal brukes i oppsettet av testen, samtidig som man refererer til de rammeverkene man trenger i testen. Dependency injection “Dependency injection” er en måte å gjøre en metode uavhengig av variabler eller objekter som andre metoder lager eller sender videre. Dette betyr i helhet at du kan lage testmetoder som ikke krever databaseaksess eller variabler som de vanligvis ville trengt for å fungere. Dette er en praksis som er vanlig i enhetstesting for å lage tester raskt og effektivt. Hovedsaklig betyr dette at testen som kjøres er isolert fra databasen, men at de fortsatt tester om metodene returnerer det vi vil, ettersom testen fortsatt tar i bruk metoder og parametre fra controller.js. Side 61 1​
​
/// <reference path="../scripts/angular.js" /> ​
2​
​
/// <reference path="../scripts/angular‐mocks.js" /> ​
3​
​
/// <reference path="../scripts/App/Controller.js" /> ​
4​
​
/// <reference path="../scripts/angulartics.js" /> ​
5​
​
/// <reference path="../scripts/angulartics‐ga.js" /> 6 ​
7​
describe​
(​
'Infopagetest:'​
,​
​
function​
​
()​
{ 8 ​
9​
​
//start setup ​
10​
​
var​
httpBackend​
,​
scope​
,​
createController; ​
11 ​
12​
beforeEach​
(​
module​
(​
'App'​
)); ​
13 ​
14​
beforeEach​
(​
inject​
(​
function​
​
(​
$injector​
)​
{ ​
15​
httpBackend ​
=​
$injector​
.​
get​
(​
'$httpBackend'​
); ​
16​
scope ​
=​
$injector​
.​
get​
(​
'$rootScope'​
); ​
17​
​
var​
$controller ​
=​
$injector​
.​
get​
(​
'$controller'​
); ​
18​
createController ​
=​
​
function​
​
()​
{ ​
19​
​
return​
$controller​
(​
'AppController'​
,​
​
{​
​
'$scope'​
:​
scope ​
}); ​
20​
​
}; ​
21​
​
})); ​
22​
​
// end setup Figur 4.1: Oppsett av testkontroller. Øverst i denne kodesnutten, importerer vi forskjellige rammeverk, og testverktøy for å kunne kjøre enhetstesten. Dette gjør vi ved å “referere” til de. /// <reference path="../scripts/angular.js" /> Angular.js trenger vi for å implementere selve Angular-rammeverket i koden. Denne referansen er essensiell for å få programkoden til å bruke Angular-biblioteket. ///<reference path="../scripts/angular‐mocks.js" /> angular-mocks.js brukes for å lage avhengighet i test-scriptet. ///<reference path="../scripts/App/Controller.js" /> Denne linjen refererer til angular-controlleren, hvor man finner alle javascript-funksjoner som setter utgangspunktet for scope-objektene, og gir de atferd. De resterende referansene er nødvendig for å få testen til å kjøre når man har implementert Google Analytics. ​
1​
it​
(​
"1 skal returnere 3 ingredienser."​
,​
​
function​
​
()​
{ ​
2​
​
//arrange ​
3​
​
var​
​
Controller​
​
=​
​
new​
createController​
(); 4 ​
5​
httpBackend​
.​
when​
(​
'GET'​
,​
​
'/api/Info/'​
).​
respond( ​
6​
[ ​
7​
{ ​
8​
​
"infoHeadline"​
:​
​
"Kart", ​
9​
​
"infoText"​
:​
​
"Kart", ​
10​
​
}, ​
11​
{ ​
12​
​
"infoHeadline"​
:​
​
"Om Plutselig", ​
13​
​
"infoText"​
:​
​
"Om Plutselig", Side 62 ​
14​
​
}, ​
15​
{ ​
16​
​
"infoHeadline"​
:​
​
"Åpningstider", ​
17​
​
"infoText"​
:​
​
"Åpningstider", ​
18​
​
}, ​
19​
] ​
20​
​
); ​
21​
​
//act ​
22​
scope​
.​
allInfoPages​
(); ​
23​
httpBackend​
.​
flush​
(); ​
24 ​
25​
​
//assert ​
26​
expect​
(​
scope​
.​
InfoPages​
.​
length​
).​
toBe​
(​
3​
); ​
27​
expect​
(​
scope​
.​
InfoPages​
[​
2​
].​
infoHeadline​
).​
toBe​
(​
"Åpningstider"​
); ​
28​
​
}); Figur 4.2: Oppbygging av de individuelle testene. Alle de individuelle testene er satt opp i tre forskjellige steg: Arrange: I dette steget starter testen ved å sette opp objektene og strukturen som skal utføres for at testen skal kjøres. I tillegg til dette er det også mulig å sette opp et forventet resultat, som kan gjenbrukes i det siste steget av testen «assert». Act: ​
Her kalles de funksjonene som er nødvendig for at testen skal kunne kjøre gjennom oppsettet i arrange-steget. Det er svært viktig at testscriptet har tilgang til metodene som skal brukes i denne delen. Assert: ​
Denne delen er det siste som skjer i den individuelle testen. Det vil si at den sjekker om det forventede resultatetet som er satt opp i arrange faktisk stemmer med det som er skrevet ut. Ut ifra dette kan man eventuelt få en feilmelding dersom resultatet avviker fra ønsket resultat. Chutzpah (Testvindu) Chutzpah er en egen utvidelse i Visual Studio som gjør det mulig å se testresultatene visuelt i testvinduet. Det finnes mange forskjellige muligheter når det kommer til plugins og programvare i Visual Studio, men grunnen til at vi valgte Chutzpah er fordi det er bra nok til vårt forbruk, i tillegg til at det er den plugin vi har fått opplæring i, i tidligere kurs. Bilde 4.2: Implementert Chutzpah i prosjektet. Side 63 4.2.8 Kjøring av enhetstester Man kjører enhetstesten ved å trykke på «test» i menyen øverst hvor man vil få frem flere valg. Her kan man velge «run» som gir deg mulighet til å velge forskjellige tester som skal kjøres. Man kan for eksempel velge å bare kjøre gjennom tester som har resultert i feilmeldinger, eller så er det mulig å kjøre alle testene som er utviklet. Bilde 4.3: Hvordan kjøre testen. 4.2.9 Resultater og tiltak Tilsammen har vi 30 tester som bruker mellom 5 og 7 sekunder på å kjøre gjennom alle. Antall sekunder testen bruker på å kjøres gjennom, vil variere fra datamaskin til datamaskin, siden testen kjøres lokalt. I utviklingsprosessen av enhetstestene kom vi over flere problemer og feil vi måtte rette opp i. Når vi prøvde å kjøre testene fikk vi bare beskjed om at testene ikke fant referanser og dermed ikke klarte å initialiseres. Etter litt feilsøking fant vi ut av at testene måtte settes opp med en spesifikk fremgangsmåte. Mesteparten av feilene lå i at vi ikke hadde satt riktige referanser og satt opp mappestrukturen feilfritt i prosjektet. Dette førte til at vi ikke fikk angular-mocks.js til å finne enhetstest-filene vi hadde satt opp, som igjen resulterte i at vi fikk svært kryptiske feilmeldinger i loggen. Etter at vi fikk satt opp strukturen riktig, gikk alle testene gjennom og kjører som de skal, samt at de tester positivt på de verdiene vi er ute etter å få ut. Side 64 Bilde 4.4: Liste over tester som kan utføres. Viser også antall vellykkede tester. Testene blir satt opp i listeform, som vist på bildet. I denne listen kan man klikke på de individuelle testene, for å se på kildekoden til de respektive testene, eller eventuelt feilsøke, om testen ikke går gjennom. I tillegg til denne listen får man opp et output-vindu, som viser hvor testen har blitt gjort og eksakt hvor lang tid testen har brukt på å kjøre gjennom. Side 65 Bilde 4.5: Vellykkede tester. 4.3 Brukertest 4.3.1 Formål med testen Brukertesten baserte seg på at oppdragsgiver skulle teste ut en prototype av produktet, med hensikt på at han skulle gi oss tilbakemeldinger på hva han synes var positivt og negativt med produktet, eventuelt forskjellige aspekter av nettsiden han ville skulle se annerledes ut. Dette følte vi kunne gå inn under en «black box test» ettersom oppdragsgiver ikke kommer fra en teknisk bakgrunn og har generelt lite kunnskap når det kommer til de programmerte elementene som ligger i back end. Dette betyr generelt at oppdragsgiver er mer interessert i hvordan sluttproduktet ender opp og hvordan det kan være til nytte for han, fremfor hvordan produktet blir utviklet. Brukertesten skal gi en pekepinn på hvordan vi ligger an i forhold til kravspesifikasjonen og hva oppdragsgiver ønsker i sluttproduktet. Dette gjør det lettere for oss som utviklere å lage et produkt som tilfredsstiller oppdragsgivers krav når det kommer til navigering av nettsiden og hvordan nettsiden oppfører seg ved normal bruk. 4.3.2 Utforming av testen Vi har laget et skjema med forskjellige spørsmål som setter fokus på alle de aspektene oppdragsgiver mener er viktige på internettsiden, samt andre spørsmål som kan gi oss som utviklere et steg i riktig retning når det kommer til brukervennlighet og design på siden. På skjemaet har vi delt opp besvarelsen i to deler. Den ene delen var satt opp med forskjellige vanskelighetsgrader, hvor oppdragsgiver kunne huke av det svaralternativet som passet han best. Valgmulighetene for vanskelighetsgrad ble rangert i fire forskjellige trinn: «vanskelig», «greit», «lett» til «utmerket». I tillegg til dette hadde vi en egen boks oppdragsgiver kunne huke av på om en funksjon ikke fungerte som den skulle. Den andre delen av besvarelsen bestod av et tekstfelt hvor oppdragsgiver kunne skrive en egen detaljert besvarelse, hvor han kunne legge inn en kommentar om hva han synes så langt om produktet, i tillegg til et felt for forbedring av hva vi allerede har implementert i webapplikasjonen. Side 66 4.3.3 Resultater og tiltak fra test utført av potensielle kunder I dette delkapittelet tar vi for oss et spørreundersøkelse med 4 deltakere. Resultatet er som følger: T1: test nr 1. T2: test nr 2. T3: test nr 3. T4: test nr 4. FI=Fungerer ikke, V= Vanskelig, G= greit, L= Lett, U= Utmerket. Spørsmål F V G L U Kommentar/Forbedring I Er det enkelt å finne frem til pizzameny? 2 2 T4: Bilde av hvert pizza. Og ekstra tilbehør. Er det enkelt å finne frem åpning- og leveringstider? 2 2 Er det enkelt å finne kontaktinformasjon? 3 1 T2:Please Write my name under kontakt person. Er det enkelt å finne frem adresse? 2 2 T4: Lengre oppe på siden ville det vært fint med en google kart å klikke inn på. Er menyen oversiktlig og lesbar? 1 3 Klarer du å finne frem nyheter på siden, og gir den mer verdi? 2 1 1 T1:Bilder av Pizza nyheter. T3:Ville hatt det på forsiden. T4:Legge de frem på en mer interessant måte, litt mer elegant. Er tekststørrelsen på nettsiden leselig? 1 2 1 T1:For store bokstaver. T2:The size of nyheter text has to be changed to size of kontakt oss. Hva synes dere om designet? 2 2 T1:Litt for gammeldags. T2:Like to have a better logo( in the middle). Little thicker logo and brighter color. T4: Nettsiden kan bli mer spennende og lokkende ved å tilføre bilder og en tydelig logo. Er det andre ting dere mener vi bør tenke på angående nettsiden? T1: Modernisere den litt. T2:Would be nice to have more picture of pizza shown on google. T3:Design. T4: Ha egen slagord. Kanskje føre opp selskapets verdier og historie. Tabell 4.1: Resultat av brukertest på front end-siden. Tiltak: Tilbakemeldinger fra brukere blir presentert for oppdragsgiver og besluttninger som tas vil bli implementert i sluttproduktet. Side 67 4.3.4 Resultater og tiltak fra admintest utført av oppdragsgiver Resultat: Etter at oppdragsgiver testet vår pilot versjon av programmet var han meget fornøyd med funksjonaliteten. Han var meget overasket over hvor enkelt det gikk ann å opprette, endre eller slette informasjon. Endringer han ønsket seg er følgende: ● Endre pizza plutselig fra nr 21 til øverst i lista uten nr. ● Teste om footer med åpningstider og levering vil se bra ut visuelt. ● Skrive liten størrelse foran navnet til GlutenFri pizza slik ved bestilling unngår kunder misforståelser. ● Teksten i Nyhetstørrelse skal være lik størrelse som kontakt oss. ● Logo skal flyttes til midten av siden og få annerledes fage. (Bildet av ønsket logo er tatt i fra google) ● logo skal være større. Tiltak: ● Plutselig selvvalgt er lagt øvertst i lista. ● Footer er testet, men det blir ikke så oversiktlig. Dette er noe vi skal vise til oppdragsgiver før produksjonsetting. ● Det er skrevet (Liten Str) foran Glutenfri pizza. ● Tekststørrelsen på nyhet og kontakt oss er likt. ● Ny log er opprettet og vil bli plasert til midten av siden etter tilbakemelding fra oppdragsgiver. 4.4 Ad hoc-testing 4.4.1 Gjennomføring av testing Ad hoc-testing går ut på å se om nettsiden fungerer som den skal ved å gå gjennom funksjonaliteten for hånd. Det kan være god praksis å ta i bruk ad hoc når man ikke har en høyt prioritert eller spesifikk liste å gå gjennom i test-fasen av prosjektet. I tillegg til dette kan det være lurt å ta i bruk Ad hoc-testing hvis det er begrenset med tid. 4.4.2 Resultater av testen De forskjellige aspektene av nettsiden som testes i en ad hoc-test vil variere svært mye, ettersom testen ikke følger et formelt oppsett eller en liste. Derfor kan det virke som testene og resultatene er tilfeldige. Test som har vært vellykket: ● List infopage: OK Side 68 ● Endre infopage: OK ● Slett infopage: OK, velkommenbildet kommer opp. ● List alle nyhet: OK Feil oppdaget under testing: ● Under create news fikk vi ikke lagret teksten inkludert tall. ● Under create infopage fikk vi ikke lagret teksten inkludert tall, semikolon og andre tegn. ● Vi kunne ikke bruke Enter-knappen i infopage eller newspage. ● Vi kunne ikke bruke vanlig kolon i Newspage og Infopage ● Vi kunne ikke bruke vanlig kolon i pizza navnet ● Man får ikke lov å bruke linjeskift i Nyheter og Info page sine meldingsboks. ● Man får ikke lov å bruke utropstegn eller parentes i meldingsfelt under Infopages. Forbedringspunkter: ● Større skrift. ● Mer mellomrom i meny og tilbehør. ● Mulig å bruke bare enkelt tall istedenfor minimalt med 2 tall i pizza priser. 4.4.3 Konklusjon av testen En Ad hoc test hjelper oss med å finne generelle bugs på nettsiden. Det er en god måte å fordele resurser på når det er flere som er innblandet i å teste prosjektet. Selv om det ikke er en substitusjon for brukertest eller enhetstesting, hjalp det gruppen å finne frem tilfeldige feil som nødvendigvis ikke var tenkt over på forhånd. Alle feil som ble oppdaget under testing av produktet ble utarbeidet og rettet og forbedringspunkter er forbedret. Side 69 Kapittel 5 - Brukerveiledning 5.1 Forord Dette kapittelet skal gi en veiledning til sluttbruker for hvordan han eller hun bruker systemet. Først og fremst for en eventuell administrator, altså oppdragsgiver. Hensikten er at dette dokumentet skal være en tilstrekkelig forklaring av systemets funksjoner, for en bruker uten nevneverdige datakunnskaper. 5.2 Terminologi Oppdragsgiver
Applikasjonen
Bruker
Administrator
Aktivitet/handling
Input
Database
Pizza Plutselig (Mansour Jam). Webapplikasjonen. Nettsiden. En kunde, som kan opprette en bruker. Oppdragsgiver. Funksjoner i applikasjonen. Tekst i et felt, skrevet inn av bruker eller administrator. Hvor informasjon lagres. Pizzaer, infosider osv.
5.3 Innledning Applikasjonen har som hovedoppgave å være en informativ side for kunder av restauranten, samt en god løsning for å kunne endre informasjon for oppdragsgiver. Webapplikasjonen har følgende funksjonalitet: ● Informere om produkter som Pizza Plutselig tilbyr. ● Redigering av denne informasjonen. ● Opprette en profil. ● Registrere en bestilling. Som hovedoppgave skal applikasjonen informere kundene om hva pizzaplutselig tilbyr av produkter. I tillegg vil oppdragsgiver kunne endre blant annet produkter, nyheter og informasjon. Side 70 Applikasjonen er enhetsuavhengig og vil derfor fungere med alle enheter med internettforbindelse og en nettleser. Bildene i dette kapittelet ble tatt før produktet var ferdigutviklet. Det vil derfor være noen bilder hvor tekst (knapper ol.) er på norsk, og noen hvor de er på engelsk. Dette fordi oppdragsgiver snakker engelsk. 5.4 Veiledningen 5.4.1 Bruker og admin Opprette administrator Det er ikke ønskelig at muligheten for å opprette administratorer skal ligge tilgjengelig ute på nettet. Derfor er opprettelse av administrator-brukere noe som gjøres manuellet under implementering av systemet hos oppdragsgiver. Oppdragsgiver får muligheten til å opprette så mange administratorer han har behov for, deretter vil denne funksjonaliteten gjøres utilgjengelig. Opprette bruker Man kan opprette en vanlig bruker under menyevalget “Registrer bruker”. Denne funksjonen er foreløpig ikke implementert i den ferdige løsningen. Bilde 5.1: Registrering av bruker. Side 71 Dersom man skriver ugyldig input i noen av feltene vil brukeren få beskjed om dette og utførelse av handlingen vil være hindret. Se bildet nedenfor. Bilde 5.2 : Inputvalidering. Vise profil Man skal kunne se sin egen profil. Denne vil kun inneholde den informasjonen som er lagret om gitt bruker, samt mulighet til å endre, eller å slette brukeren. Side 72 Endre bruker Når man trykker på “Endre”-knappen kommer det opp et allerede utfylt skjema hvor man kan endre det man ønsker. For å lagre endringene trykker man på “Endre”. Bilde 5.3: Skjermbilde for endring av bruker. Slette bruker I profilvisningen vil man få muligheten til å velge “Slett” for å slette brukeren sin.. Bilde 5.4: Skjermbilde for sletting av bruker. En administrator vil også ha muligheten til å endre og slette brukere, som vist ovenfor. Side 73 Logge inn En administrator kan logge seg inn på nettsiden ved å navigere til admin.html-delen av applikasjonen. Her vil man få muligeten til å logge inn som administrator. Bilde 5.5: Skjermbilde av innloggingssiden. Når man er innlogget vil man få tilgang til et administrasjonspanel. Se nedenfor. Bilde 5.6: Skjermbilde av adminpanel. Side 74 Logge ut Man kan logge seg ut ved å trykke på “Logout”-knappen. Bilde 5.7 : Logout Tilbakestilling av passord Det er ikke mulig å endre passordet til en administrator, av sikkerhetsmessige årsaker. Om en administrator mister sitt eget passord må utvikler kontaktes. Vanlige brukere vil få et midlertidig passord tilsendt, og vil deretter måtte endre passord når de logger inn. 5.4.3 Administrasjon Opprette en ingrediens En administrator kan opprette en ingrediens ved hjelp av “Create Ingredient” valget. Der vil man lage et navn til ingredienten og legge til ønsket pris. Prisen blir brukt til å regne ut prisen på en egenkomponert pizza. Bilde 5.8: Skjermbilde for opprettelse av ingrediens. Side 75 Administrasjonsvisning av ingredienser Alle ingredienser som er opprettet kan du finne under “List all ingredients”. Disse vil vises i en tabell. Bilde 5.9: Skjermbilde som viser liste over ingredienser. Endre eller slette en ingrediens Under “List all ingredients” vil en administrator kunne velge å endre eller slette en ingrediens. Bilde 5.10: Skjermbilde som viser opprettelse av ingrdiens. Side 76 Opprette en pizza Under “Create Pizza” kan man opprette pizza og legge til pris for liten, stor og glutenfri. Når disse er utfylt så kan man velge hvilke ingredienser som skal være på pizzaen. Man velger dem ved å klikke på dem. Da vil de komme under “added ingredients”-feltet og få fargen rødt. Hvis man vil fjerne en ingrediens kan man trykke på den røde knappen med ingrediensnavnet. Når man er ferdig trykker man “Lagre”. Bilde 5.11: Skjermbilde for opprettelse av pizza. Side 77 Administrasjonsvisning av pizzaer Velger man “List all pizzas” vil man få en liste over alle pizzaer som er lagret i databasen. Bilde 5.12: Skjermbilde som viser liste over alle pizzaer. Side 78 Endre eller slette en pizza I “List all Pizzas”-vinduet vil en administrator få muligheten til å endre eller slette en pizza. Trykker man på “Slett”- knappen vil pizzaen slettes fra menyen, og databasen. Dersom man ønsker å endre ingrediensene, pris eller navnet på en pizza, velger man “Endre” og utfører ønsket endring. Deretter velger man “Lagre” for å utføre endringene. Endringene vil lagres til databasen. Bilde 5.13: Skjermbilde som viser alternativene for endring av pizza. Side 79 Opprette tilbehør Under “Create item” kan man lage ønsket tilbehør og legge til pris. Bilde 5.14: Skjermbilde som viser opprettelse av tilbehør. Administrasjonsvisning av tilbehør Trykker man på “List all items” så vil man få liste over alt tilbehør som er lagret i databasen. Bilde 5.15 : Skjermbilde viser liste over tilbehør. Side 80 Endre eller slette tilbehør Under “List all items” får man mulighet til å endre eller slette tilbehøret. Trykker man på “Slett”-knappen vil varen slettes. Hvis man ønsker å endre tilbehør og/eller pris trykker man på “Endre”-knappen, og utfører ønsket endring, deretter trykker man “Lagre” for å lagre endringene til databasen. Bilde 5.16: Skjermbilde viser endring av en eller flere tilbehør. Opprette en nyhet Under “Create News” kan man opprette en nyhet. Man skriver en tittel til nyheten, samt ønsket tekst. Bilde 5.17: Skjermbilde for opprettelse av nyhet. Side 81 Administrasjonsvisning av nyhetene Man velger “List all news” for å få en liste over alle nyheter som er lagret i databasen. Bilde 5.18: Skjermbilde som viser liste over alle nyheter. Side 82 Endre og slette nyheter Under “List all news” kan en administrator velge å slette, eller endre en nyhet. For å slette en nyhet trykker man “Slett”. Ønsker man å endre en nyhet trykker man på “Endre”, utfører ønsket endring, og lagrer de til databasen ved å trykke “Endre”. Se bildet nedenfor. Bilde 5.19: Skjermbilde for endring av nyhet. Side 83 Opprette en informasjonsside Under “Create infopage” kan man opprette en ny informasjonsside. Ved å gjøre dette vil man også opprette et nytt valg i navigasjonsmenyen. Man skriver inn ønsket tittel og tekst. Det er tittelen som blir det nye navigasjonsmenyvalget. Dette valget vil navigere en bruker til siden hvor teksten vises. Bilde nedenfor viser opprettelse av en ny informasjonsside. Bilde 5.20: Skjermbildet som viser opprettelse av ny infoside. Side 84 Administrasjonsvining av informasjonssider Trykker man på “List all infopages” vil man få opp en liste over alle informasjonssider som er opprettet. Man vil kun få opp sidenene som er opprettet av administrator. Noen av navigasjonsvalgene er faste og kan ikke endres eller fjernes, For eksempel pizzamenyen. Bilde 5.21: Skjermbilde som viser liste over infosider. Endre og slette informasjonsside Under “List all infopages” kan en administrator velge å slette eller endre en informasjonsside. For å slette en nyhet trykker man “Slett”. Ønsker man å endre en nyhet trykker man på “Endre”, utfører ønsket endring, og lagrer de til databasen ved å trykke “Endre”. Se bildet nedenfor. Bilde 5.22: Skjermbilde for å vise endring av infoside. Side 85 5.4.4 For kunder Denne delen av brukerveiledningen vil vise hvordan en kunde kan bruke siden. Meny Under meny får kunder oversikt over pizzaene i menyen, med pris for liten, stor og glutenfri pizza. Dette vil bli forsiden til pizzaplutselig.no. Bilde 5.23 : Forsiden. Side 86 Tilbehør Når en kunde velger “Tilbehør fra navigasjonmenyen vil man få en liste over alt tilbehør og mineralvann som butikken tilbyr. Bilde 5.24: Tilbehør. Side 87 Nyheter Her vil kunder finne nyheter om restauranten. Bilde 5.25 : Nyheter. Side 88 Informasjonsside I navigasjonsmenyen vil kunder finne informasjonssider, som for eksempel “Åpningstider”. Bilde 5.26 : Et eksempel på en informasjonsside. Side 89 Bilde 5.27: Skjermbilde av en informasjonsside. Bilde 5.28 : Skjermbilde av en informasjonsside. Side 90 Side 91 Kapittel 6 - Oppslag 6.1 Figurer Liste over alle figurer. Figur 1.1 : Domenemodell. Figur 1.2 : Aktivitetsdiagram. Figur 2.1: De forskjellige CMS-enes markedsandel. Figur 2.2: Gantt-skjema for bachelorprosjekt. Figur 2.3: Gantt-skjema for design, implementering og testing av webapplikasjonen. Figur 2.4: Gantt-skjema for dokumentasjon. Figur 3.1: Kommunikasjon mellom lagene i webapplikasjonen. (MVC Model). Figur 3.2: Oversikt over hvordan lagdelingen er strukturert. Figur 3.3: Administratorhandling, opprette pizza. Figur 3.4: Brukerhandling, bestilling. Figur 4.1: Oppsett av testkontroller. Figur 4.2: Oppbygging av de individuelle testene. Figur 7.1: Domenemodell. Figur 7.2: User-modell. Figur 7.3: LinQ. Figur 7.4: Eksempel på kode som benytter HTML, CSS og Angular-kode. Figur 7.5: Eksempel på bruk av scope i Angular. Figur 7.6: Eksempel som viser implementering av Angulartics i koden. Figur 7.7: Metadata. Figur 7.8: AngularJS-funksjon. Figur 7.9: AngularJS og HTML. Figur 7.10: JSON. Figur 7.11: Angular og JSON. Figur 7.12: Connection string. 6.2 Tabeller Liste over alle tabeller. Tabell 1.1 : Funksjonelle krav i kravspesifikasjon. Tabell 1.2: Ikke-funksjonelle krav i kravspesifikasjon. Tabell 2.1: Utkast av fremdriftsplanen Tabell 2.2: Liste over fag som er benyttet for utvikling av prosjektet. Tabell 2.3: Liste over risiko og tiltak knyttet til prosjektet. Tabell 3.1: Plassering av komponenter. Tabell 3.2: Liste over alle handlinger. Tabell 3.3: Universell utforming innført i prosjektet sammenlignet med WCAG. Tabell 3.4: Design og rammeverk. Tabell 4.1: Resultat av brukertest på front end-siden. Tabell 7.1: Nødvendig service som må kjøres for at websiden skal fungere. Tabell 7.2: Liste over alle referanser som er brukt i prosjektet. Tabell 8.1: Tidsestimering. Tabell 8.2: Prosjektets tidsfrister. Tabell 8.3: Tidsberegning for kravspesifikasjon. Tabell 8.4: Timer overført til neste sprint. Tabell 8.5 : Fremdriftsplan over testing og dokumentasjonslevering. Side 92 6.3 Bilder Liste over alle bilder. Bilde 2.1: Commit-graf for bitbucket-repository. Bilde 2.2: Commit fra bitbuckets source tree for dokumentasjon. Bilde 2.3: Viser scrumbrettet og alle planlagte sprinter.(Føste utkast). Bilde 2.4: Viser scrumbrettet og alle planlagte sprinter i mindre deloppgaver. Bilde 2.5: Wireframe av nettsiden. Bilde 2.6: Utkast til menyen. Bilde 2.7: Utkast til brukerregistrering. Bilde 2.8: Utkast til påloggingsvindu. Bilde 2.9: Utkast til administrasjonsvisning av pizzaer. Bilde 2.10: Utkast til opprettelse av pizza”. Bilde 2.11: Utkast til infoside med kart. Bilde 2.12.: Forside, med gammel logo. Bilde 3.1 : Bilde av oppdragsgivers butikk. Bilde 4.1: Oversikt over testene. Bilde 4.2: Implementert Chutzpah i prosjektet. Bilde 4.3: Hvordan kjøre testen. Bilde 4.4: Liste over tester som kan utføres. Viser også antall vellykkede tester. Bilde 4.5: Vellykkede tester. Bilde 5.1: Registrering av bruker. Bilde 5.2 : Inputvalidering. Bilde 5.3: Skjermbilde for endring av bruker. Bilde 5.4: Skjermbilde for sletting av bruker. Bilde 5.5: Skjermbilde av innloggingssiden. Bilde 5.6: Skjermbilde av adminpanel. Bilde 5.7 : Logout Bilde 5.8: Skjermbilde for opprettelse av ingrediens. Bilde 5.9: Skjermbilde som viser liste over ingredienser. Bilde 5.10: Skjermbilde som viser opprettelse av ingrdiens. Bilde 5.11: Skjermbilde for opprettelse av pizza. Bilde 5.12: Skjermbilde som viser liste over alle pizzaer. Bilde 5.13: Skjermbilde som viser alternativene for endring av pizza. Bilde 5.14: Skjermbilde som viser opprettelse av tilbehør. Bilde 5.15 : Skjermbilde viser liste over tilbehør. Bilde 5.16: Skjermbilde viser endring av en eller flere tilbehør. Bilde 5.17: Skjermbilde for opprettelse av nyhet. Bilde 5.18: Skjermbilde som viser liste over alle nyheter. Bilde 5.19: Skjermbilde for endring av nyhet. Bilde 5.20: Skjermbildet som viser opprettelse av ny infoside. Bilde 5.21: Skjermbilde som viser liste over infosider. Bilde 5.22: Skjermbilde for å vise endring av ny side. Bilde 5.23 : Forsiden. Bilde 5.24: Tilbehør. Bilde 5.25 : Nyheter​
. Bilde 5.26 : Et eksempel på en informasjonsside. Bilde 5.27: Skjermbilde for kontaktsiden. Bilde 5.28 : Skjermbilde av en informasjonsside. Bilde 7.1: Hentet fra: https://docs.angularjs.org/guide/databinding. Bilde 7.2: Viser hva som kommer når man bruker Angular-koden {{Item.itemName}} og {{Item.itemPrice}}. Bilde 7.3: Servernavn og ip-adresse. Bilde 7.4: File Manager som viser vårt opplastede prosjekt på servern og dens plassering.. Bilde 7.5 : Restart av Website inn i Internet Information Services (IIS) Manager fra en Windows 2008 server. Bilde 7.6: Viser hvilke databasetyper leverandøren tilbyr. Bilde 7.7: Når man oppretter databasen kan man koble til den med brukeren som er opprettet. (Brukeren er fjernet fra bildet). Side 93 Bilde 7.8: Påloggingsvindu til Database management. Bilde 7.9: Bildet av pålogget bruker i Database managemenet. Bilde 7.10: Påloggingsinformasjon for FTP-server. Bilde 7.11: FTP-konto. Bilde 7.12: FileZilla er et FTP-verktøy brukt til å overføre prosjektet til serveren. Bilde 8.1: Scrumbrett som viser ferdigstilling av forprosjektdokumentet og kravspesifikasjon. Uke 3, 2015 Bilde 8.2: Viser brukerhistorier over alle punkt i sprint 1 til 4. En tidligere versjon av kravspesifikasjon. Bilde 8.3: Viser brukerhistorier over alle punkt i sprint 3 – 5 og presentasjonssprint. Bilde 8.4: Liste over utførte krav i kravspesifikasjonen. Bilde 8.5: Oppdatert liste over nye og oppdaterte krav i kravspesifikasjonen. Uke 19. Bilde 8.6: Oppdatert liste over nye og oppdaterte krav i kravspesifikasjonen. Uke 19. Bilde 8.7: Scrumtavle for testing. Bilde 8.8: Liste over utførte Black-box-tester. Bilde 8.9: Liste over utførte Black-box-tester. Bilde 8.10: Syv sider med skjema for administratortester. 6.4 Kilder Bitbucket: https://bitbucket.org/ https://www.youtube.com/watch?v=BtEvnE79jxY Trello: https://trello.com/ Webapp vs CMS: http://www.pixelhuset.dk/fordele-og-ulemper-ved-wordpress-cms http://www.thesitewizard.com/gettingstarted/difference-cms-site-builder.shtml CMS angrep: http://www.scmagazineuk.com/wordpress-plug-ins-open-to-attack/article/405916/ https://nakedsecurity.sophos.com/2015/04/08/fbi-warns-wordpress-users-of-isis-threat-patchand-update-now/ Enhetstest: https://visualstudiogallery.msdn.microsoft.com/f8741f04-bae4-4900-81c7-7c9bfb9ed1fe http://matthewmanela.com/projects/Chutzpah/ https://blogs.endjin.com/2014/09/unit-testing-angularjs-with-visual-studio-resharper-and-tea
mcity/ Weblishtech (Server og domene leverandør) https://ssl.weblishtech.no/default.asp Dropbox Link: https://www.dropbox.com/sh/1kr1xkl9zau14qv/AAD8pDJWYSN-AQUdLH1PKMeHa?dl=0 Angular: Side 94 http://stackoverflow.com/search?q=angular http://www.codeitive.com/0mxVUgjqWj/angular-http-404-status.html MVC https://msdn.microsoft.com/en-us/library/dd381412(v=vs.108).aspx http://mvcsecurity.codeplex.com http://www.asp.net/mvc http://www.w3schools.com/aspnet/mvc_intro.asp .NET Framework http://en.wikipedia.org/wiki/.NET_Framework_version_history UML og Arkitektur: http://thejunga.com/artifact2.html Universell utforming: http://www.w3.org/WAI/intro/wcag http://www.w3.org/TR/WCAG20/ http://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines http://www.w3.org/Translations/WCAG20-no/ Bootplus: http://aozora.github.io/bootplus/ http://aozora.github.io/bootplus/components.html Visual Studio: https://www.visualstudio.com Webstorm https://www.jetbrains.com/webstorm/ http://wildermuth.com/2014/12/13/Visual_Studio_and_WebStorm_Am_I_Mad Smidig, scrum metodikk http://en.wikipedia.org/wiki/Scrum_(software_development​
) http://www.nsp.ntnu.no/files/pages/521/20081022-smidig-prosjektmetodikk[1].pdf Egne dokumentasjoner: https://www.dropbox.com/s/donm5rl2muqgge7/Scrum%2C%20planningpoker%2C%20interalle
r%2C%20osv.docx?dl=0 Informasjonsarkitektur: http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/ Side 95 Kapittel 7 - Teknisk evaluering 7.1 Forord Dette kapittelet tar for seg løsningen vi har laget på et mer teknisk plan, med hovedfokus mot rammeverket AngularJS. Dette kapittelet vil bygge videre på produktdokumentasjonen. Kapittelet vil også ta for seg databasestruktur og databaseaksess, hvordan komponentene i løsningen kommuniserer, rammeverk for CSS, og vurderinger rundt de viktigste valgene vi i gruppen har tatt i forhold til noen av disse punktene. Til slutt gjøres noen vurderinger om videre utvikling av applikasjonen, og eventuelle svakheter i det ferdige produktet. 7.2 Utviklingsverktøy Programvaren som har blitt brukt for å utvikle applikasjonen er Microsoft Visual Studio 2013, og Visual Studio express. Dette er programmer som Microsoft lanserer, og er skreddersydd for utvikling av applikasjoner som kjører på Windows-platformer. 7.3 AngularJS 7.3.1 Versjon Applikasjonen er skrevet i versjon 1.3.15. Den stabile utgaven av denne versjonen ble utgitt da vi var i startfasen av front end-utviklingen. Vi valgte derfor å oppdatere til denne nye versjonen, ettersom det ikke ville ha noen påvirkning på allerede utviklede komponenter i applikasjonen. 7.3.2 Beskrivelse av rammeverket AngularJS er et rammeverk for å utvikle såkalte "single-page applications".14 Det vil si en webside med dynamisk oppdatering av data. Angular leser HTML, og binder input og output til javascript-modeller. Disse modellene sine variable kan manipuleres i koden, eller hentes fra JSON ressurser. Målet er å isolere klient fra server, og isolere Document Object Model (DOM) fra applikasjonslogikken. I AngularJS er scope et eget objekt, noe som er forskjellig fra hvordan uttrykket scope brukes ellers innen informatikk. Scopet refererer til applikasjonsmodellen. Man kan se på scopet som limet mellom controller og view. Det vil si at scopet blir brukt til kommunikasjon mellom disse komponentene.15 14
AngularJS. (2015). ​
Wikipedia.​
Hentet fra ​
http://en.wikipedia.org/wiki/AngularJS 15
​
AngularJS. (2015). ​
What are Scopes? ​
Hentet fra ​
https://docs.angularjs.org/guide/scope Side 96 Applikasjonen er RESTful, det vil si at applikasjonen bruker en base URL, JSONP for overføring av data, og standard HTTP metoder som GET, PUT, POST, og DELETE.16 17 Dette gir enklere koblinger mellom klient og server-komponenter. Målet er å oppnå "stateless connection", som gir bedre ytelse. Dette vil også si at det ikke blir lagret data i sessions, noe som igjen gir nye utfordringer med å opprettholde en bruker som er logget inn. AngularJS lar applikasjonen ta i bruk "two-way data-binding".18 Det vil si at når modellen oppdateres, gjør også UI det, og når UI-elementer endres forplanter disse endringene seg til modellen. Dette er en av de viktigste grunnene til at vi valgte AngularJS, ettersom det reduserer mengden kode vi må skrive. Muligheten til gjenbruk av HTML-kode, og dependency injection er også noe som redusere mengden kode. Bilde 7.1: Hentet fra: https://docs.angularjs.org/guide/databinding. 7.3.3 Hvorfor AngularJS? Vi ville lage en RESTful, stateless, single page application, fordi det er dette som er det nyeste innen webløsninger, fordi det gir rask henting og oppdatering av data, og god ytelse. Vi vurderte noen andre rammeverk for single page applikasjoner, som Polymer og backbone.js, men valgte AngularJS da vi så på dette som den mest stabile, og hyppigst vedlikeholdte løsningen, og på grunn av toveis databinding. En av de negative sidene med AngularJS er en annonsert kommende oppdatering av AngularJS som vil endre hele rammeverket. Representational state transfer (2015). ​
Wikipedia.​
Hentet fra http://en.wikipedia.org/wiki/Representational_state_transfer 17
Stack Overflow (2014). ​
What exactly is RESTful programming?​
Hentet fra http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming 18
​
​
AngularJS. (2015). ​
Data Binding. ​
Hentet fra ​
https://docs.angularjs.org/guide/databinding 16
Side 97 7.4 Model 7.4.1 Databasestruktur Figur 7.1: Domememodell. Bildet over viser databasestrukturen vi endte opp med. Den er noe forandre fra den vi presenterte i kravspesifikasjonen, grunnet endringer i produktet av sikkerhetsmessige årsaker, og endringer som oppdragsgiver ønsket. Databasestrukturen til applikasjonen er skrevet i C# etter “code first”-prinsippet, ved hjelp av Entity Framework, med mål om å oppnå minimum tredje normalform (3NF), og Boyce-Codd-normalform (BCNF).19 For å oppnå dette har vi fulgt følgene punkter: ● Alle attributter skal være atomære. Det vil si at en kolonne ikke skal kunne inneholde mer enn én verdi (1NF). ● Tabeller ikke har attributter som er delvis avhengige av primærnøkkel (2NF). ● Tabellene ikke inneholder transitive funksjonelle avhengigheter (3NF). ● Enhver determinant er en nøkkel (BCNF). 19
Database normalization. (2015). ​
Wikipedia​
. Hentet fra ​
http://en.wikipedia.org/wiki/Database_normalization Side 98 Det har derfor blitt tatt noen grep for å unngå duplikater og avhengigheter når det kom til ingredienser som hører til en pizza, og varer som hører til en ordre. Det har blitt laget en tabell som heter “Orderlines”, og en egen tabell som heter “IngredientsInPizza” for å oppnå dette. I disse tabellene ligger relasjonene mellom varer og en ordre, og relasjonene mellom ingredienser og pizzaene de hører til. Det finnes også en egen tabell for poststeder for å oppnå 3NF. Det er også opprettet noen tabeller som arver sine attributter. “Miscs” (tilbehør) og “Pizzas” arver attributter fra “Items”. Det ble også vurdert å ta i bruk arv for “Users” og “Admins”, men valget falt på å lage en egen tabell for “Admins” av sikkerhetsmessige årsaker. Ettersom målet var å utvikle en CMS-løsning med muligheten til å redigere navigasjonsmenyen øverst i siden, har det også blitt laget en tabell “InfoPages” som brukes til å opprette menyvalgene, og oppbevare innholdet i disse sidene. Nedenfor er et eksempel fra modellen. 1​
​
public​
​
class​
​
User 2​
{ 3​
​
[​
Display​
(​
Name​
​
=​
​
"Kundenummer"​
)] 4​
​
public​
​
int​
id ​
{​
​
get​
;​
​
set​
;​
} 5 6​
​
[​
Display​
(​
Name​
​
=​
​
"Fornavn"​
)] 7​
​
[​
Required​
(​
ErrorMessage​
​
=​
​
"Fornavn må oppgis"​
)] 8​
​
public​
​
string​
firstname ​
{​
​
get​
;​
​
set​
;​
} Figur 7.2: User-modell. 7.4.2 Databaseaksess Metodene som aksesserer databasen er skrevet i C#, med LinQ-syntaks for å hente informasjon fra tabellene, og fylle ut modellene som brukes av front end. LinQ er et komponent i .NET rammeverket, som gir muligheten til å bruke “native data querying” i løsningen.20 Ettersom databasen som blir tatt i bruk i denne løsningen er en SQL database, brukes ikke LinQ sine egne spørrefunksjoner opp mot denne. LinQ oversetter spørringene til klassiske SQL-spørringer, som sendes til serveren. Nedenfor er et eksempel på en LinQ spørring. Denne henter alle “Users” fra tabellen, og returnerer en liste over resultatet. 1​
​
public​
​
List​
<​
User​
>​
getAllUsers​
() 2​
{ 3​
​
List​
<​
User​
>​
allUsers ​
=​
db​
.​
Users​
.​
Select​
(​
k ​
=>​
​
new​
​
User​
() 4​
{ 5​
id ​
=​
k​
.​
id, 6​
firstname ​
=​
k​
.​
Firstname, 7​
surname ​
=​
k​
.​
Surname, 8​
address ​
=​
k​
.​
Address, 9​
postalCode ​
=​
k​
.​
PostalCode, 10​
email ​
=​
k​
.​
Email 11​
​
}).​
ToList​
(); 12​
​
return​
allUsers; 13​
} Figur 7.3: LinQ. 20
Language Integrated Query. (2015). ​
Wikipedia. ​
Hentet fra ​
http://en.wikipedia.org/wiki/Language_Integrated_Query Side 99 7.5 View 7.5.1 HTML5 HTML5 er markeringsspråket vi har brukt for å vise nettsiden. Vi har kun benyttet det på index.html og admin.html. Vi har tatt inn kode for å få det til å fungere med AngularJS. Særlig viktig er ng-show og ng-repeat, som fungerer sammen med koden i Angular-filen Controller.js. I eksempelet under listes alle items om brukeren trykker på tilbehør. ​
1​
​
<!‐‐​
​
Show​
items​
‐‐> ​
2​
​
<​
div ​
class​
=​
"span8"​
ng​
‐​
show​
=​
"showAllItems"> ​
3 <​
h3 ​
class​
=​
"newsheader"​
>​
Tilbeh​
ø​
r​
</​
h3> ​
4 <​
table ​
class​
=​
"pizza"> ​
5 <tr> ​
6 <​
td ​
class​
=​
"pizzaname"​
></​
td> ​
7 <​
td ​
class​
=​
"pizzapricetext"> ​
8 <b>​
Pris​
</​
b> ​
9 </​
td> 10 </​
tr> 11 </​
table> 12 <​
div ng​
‐​
repeat​
=​
"Item in Items"> 13 <​
table ​
class​
=​
"pizza"> 14 <tr> 15 <​
td ​
class​
=​
"pizzaname"> 16 {{​
Item​
.​
itemName​
}} 17 </​
td> 18 <​
td ​
class​
=​
"pizzaprice"> 19 {{​
Item​
.​
itemPrice​
}} 20 <​
/td><br/> 21 </​
tr> 22 </​
table> 23 </​
div> 24​
​
</​
div> Figur 7.4: Eksempel på kode som benytter HTML, CSS og Angular-kode. I dette eksempelet ser vi ng-show=”showAllItems”. Når en bruker trykker på Items har vi laget en Angular-funksjon som gjør at akkurat denne koden vises. Noe av Angular-koden fra funksjonen getAllItems() i Controller.js: 1​
$scope​
.​
Items​
​
=​
​
Items; 2​
$scope​
.​
showAllItems ​
=​
​
true; Figur 7.5: Eksempel på bruk av scope i Angular. Scopet showAllItems er ellers satt til false. Ng-repeat=”Item in Items” fungerer som en for-løkke som viser alle rader i databasen. {{Item.itemName}} viser navnet til Itemet, omtrent som “SELECT itemName FROM Item” ville gjort det i SQL. Det samme gjelder {{Item.itemPrice}}. På selve nettsiden vises dette: Side 100 Bilde 7.2: Viser hva som kommer når man bruker Angular-koden {{Item.itemName}} og {{Item.itemPrice}}. 7.5.2 CSS, Bootplus og design For utseende på nettsiden har vi benyttet oss av stilspråket CSS, som benyttes av så å si alle nettsider. Vi brukte rammeverket Bootplus, som bygger på Twitter Bootstrap. Samtidig la vi inn egen kode for elementer som var viktig for vår side. En av de store forskjellene på Bootplus og Bootstrap er grid-løsningen, eller i hvertfall navnet på dem. Vår erfaring er at Bootplus’ grid-løsning er mer responsiv, med kortere navn og litt enklere bruk. Designen er enkel, og skal bruke kort tid på å laste. Fordelen med “single page”-applikasjon er at hele siden lastes når man kommer på siden, slik at trykking rundt på siden går fort. 7.5.3 Google Analytics Oppdragsgiver var veldig interessert i å ha Google Analytics på nettsiden. Google Analytics er en ekstern webapplikasjon som lager statistikk basert på besøk på nettsiden. Den viser også hva som klikkes på, og hvor. Google Analytics er ikke laget for “single page”-applikasjoner, men heller for sider hvor du tas til en ny side når du trykker på en lenke. For å komme forbi dette problemet benyttet vi oss av utvidelsen Angulartics, som skal hjelpe Google Analytics å fungere sammen med Angular-utviklede nettsider.21 21
Angulartics. (2015). Hentet fra ​
http://luisfarzati.github.io/angulartics/ Side 101 1​
​
<​
li ​
class​
=​
"section"> 2 <​
a ng​
‐​
click​
=​
"allPizzas()"​
ng​
‐​
show​
=​
"ShowMenuButton"​
analytics​
‐​
on​
=​
"click"​
analytics​
‐​
event​
=​
"Meny"> 3 Meny 4 </​
a> 5​
​
</​
li> Figur 7.6: Eksempel som viser implementering av Angulartics i koden. I figur 7.7 legges det til to Angulartics-spesifikke kommandoer i a-taggen. Ved klikk på lenka tas man til pizzamenyen. Samtidig vil Google Analytics registrere at man har trykket på meny-lenka, og legge det til i programmet. 7.5.4 Metadata Formål med metadata Den generelle forklaringen på metadata er at det er «data om data». Det betyr rett og slett at det finnes informasjon som beskriver forskjellige aspekter av nettsiden. Dette kan være alt fra hva slags språk som er brukt til en beskrivelse av hva slags format som er brukt på et bilde inne på nettsiden. Hva slags metadata som er brukt, varierer fra nettside til nettside, ettersom det er valgfritt hvor mye metadata man vil ta i bruk. Metadata er utviklet for nettleseren som skal finne frem informasjon til brukeren. Om det er satt opp tilstrekkelig med metadata på nettsiden, er det muligheter for at nettleseren tar tak i meta-taggene og setter det opp som et resultat til brukeren. Det er altså ikke brukeren, men nettleseren som tar seg av bruken når det kommer til meta-tags. For eksempel kan nettsider som inneholder bilder av kunstverk sette opp metadata på bildene iforhold til hvem som har laget bildene, opphavsrett, og hvor stort bildet er. På denne måten kan nettleseren finne frem relevant informasjon ved å lete i meta-taggene som settes til bildet. Pizza plutselig og metadata Vi har tatt i bruk noen meta-tagger vi føler er nødvendig for siden, men utover de essensielle har vi ikke brukt overflødig mange meta-tagger, ettersom vi ikke føler det er unødvendig med altfor mange. Det finnes søkemotorer som ikke bruker meta-tagger like mye som andre, og på grunn av dette har vi valgt å holde det til det grunnleggende. 1​
​
<​
meta http​
‐​
equiv​
=​
"X‐UA‐Compatible"​
content​
=​
"IE=edge,chrome=1"​
> 2​
​
<​
meta name​
=​
"title"​
content​
=​
"Pizza Plutselig ‐ Pizza ‐ Levering ‐ Take out ‐ Oslo"> 3​
​
<​
meta name​
=​
"description"​
content​
=​
"Vi leverer rykende fersk pizza i hele oslo området, toppet 4 med gode råvarer over en italiensk tynn pizzabunn!"​
> 5​
​
<​
meta name​
=​
"viewport"​
content​
=​
"width=device‐width, initial‐scale=1.0"> 6​
​
<​
meta name​
=​
"author"​
content​
=​
""> 7​
​
<​
meta http​
‐​
equiv​
=​
"content‐type"​
content​
=​
"text/html; charset=utf‐8"​
> 8​
​
<​
meta http​
‐​
equiv​
=​
"Content‐Language"​
content​
=​
"nb‐NO"> Figur 7.7: Metadata Her ser man et utklipp av noen meta-tagger vi har implementert i programkoden vår. <meta name=''description'' > og <meta name=''title'' > er de vi har tatt mest hensyn til, ettersom at populære søkemotorer som google, har et bibliotek med meta-tagger den bruker eksklusivt, og vil ikke gjenkjenne andre meta-tagger man eventuelt vil bruke på nettsiden. Side 102 Dublin Core Dublin core inneholder et formelt oppsett av elementer som skal settes inn i meta-taggen. pr. dags dato finnes det 15 forskjellige elementer. Ut ifra disse bruker vi Title: Skal rett og slett bare inneholde navnet til bedriften, pluss eventuelt et slagord. Description: Skal inneholde en beskrivelse av nettsiden, her er det god praksis å bruke fulle setninger som gir mening iforhold til nettsiden. Type: Beskriver hva slags type web-dokumenter som er brukt på nettsiden og hva slags tegnsett som er brukt (utf-8 i vårt tilfelle). Language: Denne forklarer rett og slett hva slags språk siden benytter seg av. 7.6 Controller 7.6.1 AngularJS AngularJS jobber opp mot modellene som formes fra databasespørringene. Nedenfor ser vi en angularfunksjon, som henter, og lister ut alle “Users” som ligger i databasetabellen. Det gjøres også en passord-sjekk (linje 7) før hentingen skjer (linje 9), for at metoden ikke skal kunne bli misbrukt av uvedkommende. 1​
$scope​
.​
AllUsers​
​
=​
​
function​
​
()​
{ 2​
getAllUsers​
(); 3​
} 4​
​
function​
getAllUsers​
()​
{ 5​
console​
.​
log​
(​
"Inne i AllUsers"​
); 6​
hideAll​
(); 7​
$http​
.​
put​
(​
urlAdmin​
,​
$scope​
.​
user​
). 8​
success​
(​
function​
(​
user​
)​
{ 9​
$http​
.​
get​
(​
urlUser​
). 10​
success​
(​
function​
​
(​
allUsers​
)​
{ 11​
$scope​
.​
users ​
=​
allUsers; 12​
$scope​
.​
showUsers ​
=​
​
true; 13​
​
}). 14​
error​
(​
function​
​
(​
data​
,​
status​
)​
{ 15​
console​
.​
log​
(​
status ​
+​
data​
); 16​
​
}); 17​
​
}). 18​
error​
(​
function​
​
(​
data​
,​
status​
)​
{ 19​
console​
.​
log​
(​
status ​
+​
data​
); 20​
​
}); 21​
​
}; Figur 7.8: AngularJS-funksjon. Side 103 Nedenfor er et lite utsnitt av HTML-kode som presenterer informasjonen som ligger i AngularJS-scopet etter at funksjonen ovenfor har blitt kjørt. Koden nedenfor blir brukt til visning av alle registrerte “Users”, som kun en admin skal ha tilgang til. ​
1​
​
<!‐‐​
​
User​
​
‐‐> ​
2​
​
<​
div ​
class​
=​
"col‐sm‐4 col‐sm‐offset‐1"​
ng​
‐​
show​
=​
"showUsers"> ​
3​
​
<​
table ​
class​
=​
"table table‐bordered table‐condensed"> ​
4 <thead> ​
5​
​
<tr> ​
6​
​
<th>​
Id​
</​
th> ​
7​
​
<th>​
Fornavn​
</​
th> ​
8​
​
<th>​
Etternavn​
</​
th> ​
9​
​
<th>​
Adresse​
</​
th> 10​
​
<th>​
Postnr​
</​
th> 11​
​
<th>​
Poststed​
</​
th> 12​
​
<th>​
Email​
</​
th> 13​
​
</​
tr> 14​
​
</​
thead> 15​
​
<​
tbody ng​
‐​
repeat​
=​
"user in users"> 16​
​
<tr> 17​
​
<td>​
{{​
user​
.​
id​
}}</​
td> 18​
​
<td>​
{{​
user​
.​
firstname​
}}</​
td> 19​
​
<td>​
{{​
user​
.​
surname​
}}</​
td> 20​
​
<td>​
{{​
user​
.​
address​
}}</​
td> 21​
​
<td>​
{{​
user​
.​
postalCode​
}}</​
td> 22​
​
<td>​
{{​
city​
.​
city​
}}</​
td> 23​
​
<td>​
{{​
user​
.​
email​
}}</​
td> 24​
​
<td>​
<​
button ​
class​
=​
"btn btn‐danger"​
ng​
‐​
click​
=​
"deleteUser(user.id)"> 25 ​
Slett 26​
​
<​
/button></​
td> 27​
​
<td>​
<​
button ​
class​
=​
"btn btn‐success"​
ng​
‐​
click​
=​
"getUserToChange(user.id)"> 28 ​
Endre 29 <​
/button></​
td> 30​
​
</​
tr> 31​
​
</​
tbody> 32​
​
</​
table> 33​
​
</​
div> Figur 7.9: AngularJS og HTML5. 7.6.2 JSON Løsningen benytter JSON for overføring av data mellom server og klient.22 Bildet nedenfor viser hvordan JSON serialization blir tatt i bruk for å sende data fra server til klient. 1​
​
public​
​
HttpResponseMessage​
​
GetAll​
() 2​
{ 3​
​
List​
<​
User​
>​
allUsers ​
=​
UBLL​
.​
getAllUsers​
(); 4 5​
​
var​
​
Json​
​
=​
​
new​
​
JavaScriptSerializer​
(); 6​
​
string​
​
JsonString​
​
=​
​
Json​
.​
Serialize​
(​
allUsers​
); 7 8​
​
return​
​
new​
​
HttpResponseMessage​
() 9​
{ 10​
​
Content​
​
=​
​
new​
​
StringContent​
(​
JsonString​
,​
​
Encoding​
.​
UTF8​
,​
​
"application/json"​
), 11​
​
StatusCode​
​
=​
​
HttpStatusCode​
.​
OK 12​
​
}; 13​
} Figur 7.10: JSON. 22
JSON. (2015). ​
Wikipedia.​
Hentet fra ​
http://en.wikipedia.org/wiki/JSON Side 104 1​
$scope​
.​
createUser ​
=​
​
function​
​
()​
{ 2 3​
console​
.​
log​
(​
"Create User"​
); 4​
​
var​
​
User​
​
=​
{ 5​
firstname​
:​
$scope​
.​
firstname, 6​
surname​
:​
$scope​
.​
surname, 7​
address​
:​
$scope​
.​
address, 8​
city​
:​
$scope​
.​
city, 9​
postalCode​
:​
$scope​
.​
postalCode, 10​
email​
:​
$scope​
.​
email, 11​
password​
:​
$scope​
.​
password 12​
​
}; 13 14​
$http​
.​
post​
(​
urlUser​
,​
​
User​
). 15​
success​
(​
function​
​
(​
data​
)​
{ 16​
$scope​
.​
showRegForm ​
=​
​
false; 17​
$scope​
.​
saveUserButton ​
=​
​
false; 18​
console​
.​
log​
(​
User​
); 19​
​
}). 20​
error​
(​
function​
​
(​
data​
,​
status​
)​
{ 21​
console​
.​
log​
(​
status ​
+​
data​
); 22​
​
}); 23​
​
}; Figur 7.11: Angular og JSON. Figur 7.11 viser opprettelsen av et objekt som sendes fra klient til server. JSON (JavaScript Object Notation) er et format som bruker lesbar tekst til å overføre objekter som består av parede attributtverdier. Brukes som et alternativ til XML. 7.7 Sikkerhet Når det kommer til sikkerhet har hovedfokus ligget på å sikkre databasen, og databaseaksess. Både fra DOM-manipulasjon og SQL-injeksjoner. DOM-manipulasjon har vi sikkret oss mot ved å sjekke passord før en sensitiv handlig utføres. Lagring av passord i databasen gjøres ved å lagre en hashet versjon av passordet i tabellen. Videre når en passord-sjekk skjer, hashes input og sjekkes opp mot hashen som er lagret i databasetabellene. Slik oppnår man at passorden eksisterer i plaint-text i så kort tid som mulig. For hashing av passordene blir algoritmen SHA256 tatt i bruk. Det er satt minimum passordlengde til syv tegn, og muligheten til å bruke tall og bokstaver. SQL-injeksjoner blir tatt hånd om ved hjelp av input-validering og regular expressions (ng-pattern, som er AngularJs sin regex. syntax). Kun de mest essensielle spesialtegnene er tillatt. Når siden etterhvert kjører på en server er planen at brukere og admin skal tvinges til å kommunisere med applikasjonen via HTTPS.23 Det vil gi økt sikkerhet når det kommer til blandt annet passordutveksling, ettersom pakkeoverføringene blir kryptert. Dette er noe vi fortsatt jobber mot. Stack Overflow. (2013). ​
How to use HTTPS in AngularJS.​
Hentet fra http://stackoverflow.com/questions/18839524/how-to-use-https-in-angularjs 23
Side 105 7.8 Våre vurderinger, og utviklingspotensiale 7.8.1 Bruker og bestilling Mange av figurene i dette kapittelet er fra tabellen og objektene til en “User”. Det ble senere besluttet at vi skulle fjerne muligheten til å registrere en bruker og sende inn en bestilling via applikasjonen midlertidig til vi har klart å utvikle en tilfredstillende løsning når det gjelder presentasjon av bestillinger. Oppdragsgiver vil ikke ha en løsning hvor han må holde oversikt over innkommende bestillinger fra flere enn en kilde. Med dette mener han at han ikke ønsker flere fysiske områder han må ha oversikt over. Oppdragsgiver har allerede en avtale gående med “Just Eat”, som han ikke vil avbryte av diverse årsaker. Vi må derfor finne en løsning som enten kan integrere måten vårt bestillingssystem presenterer bestillingene, med det allerede eksisterende systemet, eller finne en annen måte å gjøre det enkelt for oppdragsgiver å holde oversikt. For eksempel noe lignende systemet fra “Just Eat”, som fysisk kan plasseres i nærheten av det allerede eksisterende systemet i oppdragsgivers lokale. Ettersom systemet vi utvikler vil bli en konkurrent til “Just Eat” ser vi det som umulig å integrere vårt system med deres. Den eneste aktuelle løsningen vil derfor bli å utvikle en måte å presentere bestillingene som ligner det han allerede har, som oppdragsgiver kan plassere ved siden av. Systemet han allerede har er en liten printer som skriver ut bestillinger etterhvert som de kommer inn. I utgangspunktet så vi på mulighetene for å sende bestillinger via mail, men vi ble etterhvert gjort oppmerksomme på at dette ikke ville oppfylle oppdragsgivers ønsker. Vi fikk derfor for kort tid til å ferdigutvikle løsningen nevnt ovenfor, og besluttet å begrense prosjektet for å fokusere på å ferdigutvikle høyere prioriterte komponenter. Les kravspesifikasjonen. 7.8.2 Sikkerhetsvurdering Sikkerheten er også et aspekt vi har vurdert at trenger videreutvikling. Vi er fornøyde med sikringen av databasen, men det finnes ikke tilstrekkelig sikring av de visuelle delene i applikasjonen. Det vil si at javascriptet som applikasjonen bruker for å avgjøre hva som skal fremvises kan manipuleres. Dette kan gjøres via konsollen i nettleseren. Med minimum kunnskap om JavaScript og AngularJS vil man kunne få fremvist HTML-kode som kun er ment for en admin. I utgangspunktet er dette ikke ønskelig, men vi har ikke prioritert å begrense dette, ettersom all informasjon, og alle funksjoner vil være utilgjengelige. Det er kun den visuelle visningen av knapper og tomme tabeller som er tilgjengelig. For å gi den visuelle delen av applikasjonen tilstrekkelig sikring, vil vi implementere bruken av “ng-if” tester, og “ngRoute” for å navigere uvedkommende vekk fra begrensede områder.24 Scholz, G. (2014, 9. desember). Authentication made simple in Single Page AngularJS Applications. ​
The Brew Pub. http://brewhouse.io/blog/2014/12/09/authentication-made-simple-in-single-page-angularjs-applications.html 24
Side 106 7.8.3 Øvrig Utover dette vil implementering av manglende B og C-krav fra kravspesifikasjonen være de neste stegene for applikasjonen. Og eventuelle nye ønsker fra oppdragsgiver. 7.9 Brukerveiledning for server og database. 7.9.1 Server Serveren hos weblishtech har 2 alias og har 2 nettverkskort. Bilde 7.3: Servernavn og ip-adresse. Webapplikasjonen som vi har lastet opp på serveren ligger under mappen D:\webfarm\pizzaplutselig.no\wwwroot\plutseligWebApp og har størrelse på ca 210MB. Side 107 Bilde 7.4: File Manager som viser vårt opplastede prosjekt på servern og dens plassering. 7.9.2 Driftsoppgaver på serveren. Services: Dersom Error - 404 kommer opp eller hvis siden er utilgjengelig, må et par punkter sjekkes av server leverandøren. Det er viktig at følgende service kjører på serveren: Service Navn Visnings navn Beskrivelse W3SVC World Wide Web Publishing Service Provides Web connectivity C:\Windows\system32\svc
and administration host.exe -k iissvcs through the Internet Information Services Manager Tabell 7.1: Nødvendig service som må kjøres for at websiden skal fungere. Side 108 Path For å stoppe og starte IIS for å få opp siden kan man prøve følgende instruks: 1. Starte å stopp gjennom en UI: a. Start IIS manager og naviger ned til siten. b. I action panel, klikk start hvis man ønsker å starte web server eller stop dersom man ønsker å stoppe eller restart ved ønske. Bilde 7.5 : Restart av Website inn i Internet Information Services (IIS) Manager fra en Windows 2008 server. 2. Start og stopp via kommandolinjen: a. Open Kommando linjen fra Start menyen på serveren, eller skriv cmd i kjør feltet. Dette må startes med administrator bruker. b. I Kommando linjen kan man skrive “net stop WAS” og deretter enter, skriv “Y” og enter for å stoppe W3SVC. c. For å restarte webserveren skriv “net start W3SVC” og deretter enter. 2. Restarte IIS ved evntuelle hent fra kommando linjen: a. Open Kommando linjen fra Start menyen på serveren, eller skriv cmd i kjør feltet. Dette må startes med administrator bruker. b. Skriv “IIS Reset” og deretter Enter. Når dette er utført så vil IIS servicen restarte seg. Side 109 7.9.3 Database Leverandøren tilbyr oss bruk av database tjeneste som gir oss muligheten å gå fra en lokal base til en ekstern database hvor det tas daglige snapshot og backup av. Database alternativer som tilbys er følgende: Bilde 7.6: Viser hvilke databasetyper leverandøren tilbyr. For vår del var det naturlig å benytte seg av Microsoft SQL Server 2005, men for at dette skal fungere må vi utføre følgende endring: Endre connectionStrings i Web.config under \wwwroot\plutseligWebApp\Plutselig <connectionStrings> <add​
​
name​
=​
"Plutselig"​
​
connectionString​
=​
"Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|Plutselig.mdf;Integrated Security=True"​
​
providerName​
=​
"System.Data.SqlClient"​
​
/> <add​
​
name​
=​
"Plutselig"​
​
connectionString​
=​
"Data Source=mssql01.weblishtech.no\SQLEXPRESS);Databse=Plutselig.mdf;uid:****;pwd=****;Mult
ipleActiveResultSets=true"​
​
providerName​
=​
"System.Data.SqlClient"​
​
/> </connectionStrings> Figur 7.12: Connection string. Under ConnectionStrings har den lokale databasen navnet Add name="Plutselig" og den eksterne databasen hos leverandøren navnet Add ​
name="Plutselig1" . Side 110 Vi har brukt fire stjerner, ”****” , i dokumentasjonen foran brukerid og passord (uid, pwd) for å ivareta sikkerheten. For å koble seg til databasen som er installert i en MS SQL server 2005 kan man bruke følgende link: ​
http://sql1.weblishtech.no/default.aspx Et annet alternativ er å trykke på linken foran Webadmin, market med hvit for å skjule admin brukeren. Bilde 7.7: Når man oppretter databasen kan man koble til den med brukeren som er opprettet.(Brukeren er fjernet fra bildet). Deretter blir man viderelenket til online Management studio for microsoft SQL server som leverandøren tilbyr: Side 111 Bilde 7.8: Påloggingsvindu til Database management. Bilde 7.9: Bildet av pålogget bruker i Database managemenet. Side 112 Når man er pålogget i SQL Management Studio vil man kunne: ● Legge til nye brukere i databasen (Database Owner, DB creator og mange andre) ● Ta snapshot eller backup av databasen. ● Lage nye spørring mot databasen, CVS import, etc. ● Monitorere aktiviteter mot databasen. (Ligger under Managmenet—Activity monitor). ● Sjekke Error logger. (Under Managmenet—Error Log). ● Endre layout, språk, display og datagrid page size under. (Under Prefrences). 7.9.4 FTP-server Det lar seg å bruke ftp programmer som Filezila eller WinScp for å koble seg mot filpathet der filene ligger. Følgende informasjon skal brukes under opplasting av filer: FTP Username: (Administrator) FTP Server: ftp.pizzaplutselig.no FTP Server IP: 46.16.48.210 Bilde 7.10: Påloggingsinformasjon for FTP-server. Side 113 Bilde 7.11: FTP-konto. Bilde 7.12: FileZilla er et FTP-verktøy brukt til å overføre prosjektet til serveren. Side 114 7.9.5 Alias Når oppdraggiver bestemmer seg for å ta i bruk webapplikasjonen vil “ ​
www.pizzaplutselig.no​
” peke på index.html og vil bli opprettet et alias som peker på admin.html slik oppdragsgiver kan bruke denne. 7.10 Pakkereferanser Som pakkebehandligsverktøy har vi brukt det integrerte verktøyet “NuGet” i Visual Studio. Når man utvikler en applikasjon i Visual Studio vil det være nødvendig å importere eksterne biblioteker for at systemet skal kunne ta de i bruk. Her er en tabell over de viktigste pakkene som er importert. M = Model References. DAL = Data Access Layer References. BLL = Business Logic Layer References. MR = Main References. DC = Design Content References. AS = Angular Script References. Pakkenavn Beskrivelse M D B M D A
A L R C S L L EntityFramework EntityFramework.SqlServer System.ComponentModel.DataAnnot
ations System.Web.MVC System.linq Newtonsoft.Json System.Net.Http System.Web.Entity Verktøy for Visual Studio og Entity Framework Runtime. Versjon 6 Verktøy for Visual Studio, Sql database og Entity Framework Runtime. Versjon 6.0.0.0 Den gir attributter,som brukes til å definere metadata for gjenstander som benyttes som datakilder. versjon 4.0.0.0 Inneholder klasser og grensesnitt som støtter ASP.NET Model View Controller (MVC) rammeverk for å lage webapplikasjoner. Version 5.2.0.0 Gir klasser og grensesnitt støtte for spørringer via LINQ. Versjon 4.0.0.0 Brukes til å implementere JSON i rammeverket. Versjon 6.0.0.0 Inneholder klasser av HTTP-attributter. Version 4.0.0.0 Inneholder klasser og grensesnitt knyttet til enheter for web-leverandører. Version 4.0.0.0 Side 115 X X X X X X X X X X X X X X X X X X X X X X X Bootplus-responsive.css Bootplus.css Bootstrap.css Angular-mocks.js Angular.js Bootstrap.js Jquery-2.1.3.js Jquery-2.1.3.intellisense.js Jquery-2.1.3.min.js Jquery-2.1.3.min.map Stilsett for responsivt design på nettside. Stilsett for design av nettside. Populært og mye brukt stilsett. Enhetstesting i Angular. JavaScript -lassebibliotek JavaScript-designreferanse Rask, lite og funksjonsrikt Javascript-bibliotek. Det gjør ting som HTML-dokument traversering og manipulasjon, event håndtering, animasjon, og Ajax enklere. Tabell 7.2: Liste over noen av referansene som er brukt i prosjektet. Side 116 X X X X X X X X X X Side 117 Kapittel 8 - Vedlegg 8.1 Prosjektdagbok 1. oktober 2014 Vahid har vært i kontakt med NSB Persontog Trafikk, NSB fellestjeneste og Jernbaneverket om de har oppdrag vi kan ta på oss. Etter flere møter med IT-sjefene og ansvarlige der så det ut som oppgavene enten var så store og kompliserte at man burde samarbeide med tre-fire forskjellige leverandører og interessenter for å få til løsningen eller så var oppgavene veldig små. I tillegg hadde de ikke anledning til å utdele oppgave før midten av våren 2015 da de var opptatt med implementering av et nytt mobilsystem. 1. november 2014 Det ble sendt søknad til Bekk, Steria og Accenture for å se på mulighetene for hovedprosjektoppgave. Det var litt seint hos Accenture og en veldig lang intervjuprosess. Hos Bekk var alle oppgaver som var tilgjengelige tatt. Steria driver med rådgivning og mindre systemutvikling i Norge. 25. november 2014 Vi fikk tips om å lage en nettside for Pizza Plutselig av en venn. Da vi kontaktet eier Mansour Jam var han meget positivt til vårt forslag. Gruppen og oppdragsgiver ble enige om å lage en bedre og mer effektiv nettside for hans bedrift Pizza Plutselig. 26. november 2014 Gruppen jobber med statusrapporten og prosjektskissen, og klargjør disse til innlevering. Fristen er 5. desember 2014. 8. januar 2015 Vi hadde et møte hvor vi satte opp en milepælsplan for forprosjektet, med tidsfrister og delegering av oppgaver. Vi kartlegget litt rundt opplegget fremover, og planla vårt første møte med veileder. Vi bestemte oss for å ikke starte ordentlig med kodeløsninger før vi har snakket med veileder og oppdragsgiver. Fremdriftsplan og arbeidsplan opprettes. Side 118 14. januar 2015 Gruppen startet med å lage kravspesifikasjonsstrukturen. Gruppen er blitt enig om å ha en god backup-rutine av prosjektet, slik at vi ikke mister noe hvis uhell skulle oppstå. Dokumentasjoner oppdateres. 19. januar 2015 Vi har alle sammen jobbet med hver vår del i forprosjektet og samlet inn informasjon om prosjektet. Laget oppgaver i Trello slik at vi kunne se vår fremgang. 21. januar 2015 Vårt første møte med veileder Ismail Hassan. Sammen med Ismail tok vi også en prat med Tor Krattebøl hvor vi diskuterte bredden på prosjektet. Vi fikk noen tips om teknologi og hvordan vi skulle gå frem. Vi jobbet videre med forprosjektet. 22. januar 2015 Gruppen samlet seg for å gjør ferdig hele forprosjektet og se over den før levering. På kvelden hadde vi et møte med oppdragsgiver hvor vi fikk skrevet ned en del av funksjonelle og ikke- funksjonelle krav han ønsket seg. Det ble avtalt å ha et møte med oppdragsgiver og veileder onsdag den 29. januar 2015 for å skrive under kontrakten. 25. januar 2015 Ny sprint ble opprettet i Trello. Arbeidet med kravspesifikasjonsdokumentet ble delt mellom gruppemedlemmer. 26. januar 2015 Torstein og Jonas hadde møte mens de andre jobbet hjemme. Det ble jobbet med krav- spesifikasjonen. 29. januar 2015 Vi skrev under kontrakten. Jobbet videre med kravspesifikasjonen. Side 119 1. februar 2015 Vi hadde møte og ble enig om hvilken informasjon som skal ligge i databasen. Lagde ferdig aktivitetsdiagram og domenemodellen. Vi gikk gjennom smidig utvikling og ble enig om å bruke scrum som utviklingsmetode. Lagde en liste over fordeler og svakheter ved CMS og MVC. Jonas tok på seg oppgaven med å lage databasen. Vahid skal lage en grundig analyse over hvorfor vi bruker MVC som utviklingsverktøy samt også lage en liste over viktig informasjon om scrum. 3. februar 2015 Vi fikk satt opp et par oppgaver å jobbe med fremover i en sprint, blant annet IngredientsDB.cs og UserDB.cs. Vi er enda ikke helt sikre på hvordan vi skal legge opp databasen på alle punktene, men vi har funnet ut vi bare må prøve og feile til vi finner en løsning. 23. februar 2015 Vi har satt opp lagdeling i Visual Studio og sett litt på hvordan vi skal håndtere dette med enhetstesting i AngularJS. Jobbing med databasen fortsetter. 25. februar 2015 Vi satte opp et møte med veileder angående hvilken retning vi burde føre prosjektet, grunnet mye usikkerhet om back-end. Etter møtet fikk vi litt mer klarhet i hvordan vi skulle takle de forskjellige problemene som var relatert til databasen og AngularJS-scopes. 2 .mars 2015 I dag fortsatte vi arbeidet controllerne, mens database modellene er ferdige. Vi føler at vi har fått en liten fremgang i prosjektet, og sitter med litt mer oversikt over oppbyggingen i programmet. Vi har også sett litt på enhetstesting, og må prøve å få til en test-løsning på programmet. Vi gjør klar en mindre del av applikasjonen klar som en prototype som vi kan representere for oppdragsgiver. 13. mars 2015 Møte med oppdragsgiver. Det ble presentert prototype av applikasjonen til oppdragsgiver. ● Oppdragsgiver kom med ønske om nye krav, funksjonsendringer og forbedringer: ● Ønske om å kunne registrere flere ansatte under administratorsiden, slik at flere ansatte kan utføre endringer i nettsiden. ● Ønske om bestillingsmulighet for kunder. Hvor pizza skulle være primært for henting, eller eget tekstfelt for levering. Om mulig å integrere løsningen slik at bestillingen ble sendt som en utskrift til butikkens nåværende labelprint som er levert av «Just Eat». Side 120 ● Opprettelse av kundekonto slik at kundene kunne se sine tidligere bestillinger og endre profil. ● Ønske om å gi muligheten til å lage egne navigasjonsmenyer, i tilfelle han skulle ønske å opprette en meny. Etter samtale med oppdragsgiver ble vi enig om at det som vi får tid blir implementert og gjenstående krav kan bli utført senere enten av gruppen eller andre utviklere. 16. mars 2015 Ble ferdig med å programmere alle DAL og BLL-klassene. Neste steg er å gjøre ferdig alle controllere, slik at back end-delen mer eller mindre er ferdig. 18. mars 2015 Vi har kommet et steg videre i enhetstestingen. Dette vil si at vi har fått mer forståelse på hvordan Jasmine og PhantomJS fungerer sammen med Visual Studio. Vi må enda vente litt med enhetstesting fordi vi ikke har helt kommet igang med front end- delen av prosjektet (AngularJS). 23. mars 2015 Vi prøver å lage en handlekurv som vil fungere med AngularJS, det er mulig vi må sitte en stund for å få til dette. Det er mulig vi må lære oss hvordan vi implementere GUID (Global unique identifier) eller UUID (Universally unique identifier). 25. mars 2015 Vi hadde møte med veileder Ismail Hassan hvor vi blant annet avtalte at vi skulle ha en forbedret prototype klar til å vise frem på neste møte etter påske. 8. april 2015 Vi har endret litt på designet til nettsiden (CSS). I tillegg har vi fått satt opp noen infosider som kreves for at admin skal kunne legge til nyhetssider eller lignende. Ellers har vi litt problemer med oppretting av databasen i programmet. Dette fører til at alt annet blir satt på vent ettersom det er avhengig av databasen. 9. april 2015 Etter litt feilsøking fant vi ut at vi hadde en liten syntaksfeil i global.asax som forårsaket at databasen ikke ville opprettes. Etter litt endringer fikk vi til å sette opp databasen, samt å legge inn et objekt. Gruppen starter dokumentering av sluttrapporten. Side 121 14. april 2015 Idag har vi jobbet med å sette opp infopages og fortsetter med å skrive angularfunksjoner. Vi tenkte at vi også ville prøve å få satt opp databasen slik at den synes på bitbucket. 22. april 2015 Hadde møte med oppdragsgiver angående prototype og videre valg av design. Snakket litt om funksjonaliteten til nettsiden og hvordan vi burde gå videre i utviklingen. I dette møtet ble det nevnt ønske om å stoppe implementeringen av bestillingsmuligheten da oppdragsgiver ikke har nok kapasitet til å ta imot bestillinger fra denne kilden. 26. april 2015 Vi hadde gruppemøte og diskuterte videre hvordan vi skal løse et par av problemene vi har i strukturen og oppbyggingen av nettsiden. 29. april 2015 Hadde et møte med veileder hvor vi fikk et par tips angående logging av feilmeldinger på nettsiden, og at vi burde satse høyt på dokumentasjonen ettersom den burde være ferdig til 15. mai 2015. Vi fikk også litt mer innblikk i hvordan vi burde presentere produktet vårt via dokumentasjonen. Det vil si at vi burde selge det, men på en ærlig måte. 1. mai 2015 I dag begynte vi å sikre metodene ettersom vi er ferdig med å lage alle metodene som er nødvendige. Vi har brukt litt lenger tid på å bli ferdig med front-end enn det vi hadde trodd, fordi AngularJS er et ukjent territorium for oss på gruppa. Ellers har vi jobbet flittig med dokumentasjonen. 2. mai 2015 Gruppen har brukt meste parten av tiden til feilsøking og skrevet ned feil vi har funnet. Dokumentasjonsarbeidet fortsetter. Ferdig med å lage brukertestoppgave som oppdragsgiver skal svare på når vi tester. 3. mai 2015 - 10. mai 2015 Feilsøking fortsetter, tidligere feil blir rettet opp. Forbedring av utsende og tekstutskrift (Front end). Dokumentasjonsarbeid fortsetter. Side 122 11. mai 2015 I møte med oppdragsgiver ble ny versjon av prototype presentert hvor tidligere feil var rettet. Alle funksjonaliteter ble testet av Vahid og fremvist til oppdragsgiver. Det var bare positive tilbakemeldinger. Oppdragsgiver likte hvor enkelt han kunne utføre endringer i web- applikasjonen. Vi ble enig om at Vahid tar med en liste med spørsmål hvor oppdragsgiver tester og gir karakter på brukervennlighetsgraden. Testen vil leveres til oppdragsgiver i form av papir, og slutt- resultatet blir lastet opp. 12. mai 2015 Gruppen arbeider videre med dokumentasjon. Feilsøking rundt komplikasjoner på serveren hos Weblishtech. 13. mai 2015 Gruppen arbeider videre med dokumentasjon. Vi har bestemt oss for å videreutvikle produktet senere, så vi kan bruke gjenstående tid til utbedring av dokumentasjonen. Kontaktet oppdragsgiver for å teste applikasjonen. Han vil gå gjennom cirka 30 spørsmål. 14. mai 2015 Møte med oppdragsgiver vedrørende pilottesting og funksjonalitetstesting. Oppdragsgiver fikk testet funksjonaliteten og kom med ønsket forbedringspunkter. På samme dag ble det tatt fire andre tester med vanlige brukere om design, funksjonalitet og informasjonstilgjengelighet. Disse ble dokumentert og ligger i Dropbox-linken under punkt 8.4. 15. mai 2015 Gruppen fortsetter med dokumentasjon og resultat av testinger er skrevet i sluttrapporten. 18. mai 2015 I dag har vi jobbet eksklusivt med sluttrapporten og alt som har med innholdet å gjøre. Vi har blitt enige om at vi ikke skal legge til mer tekst, men heller fokusere på å bli ferdig med formatering og utseende på teksten, ettersom vi føler det er viktig når vi skal levere inn prosjektet. Side 123 8.2 Fremdriftsplan 8.2.1 Fremdriftsplan for implementering Arbeidsplan og fremdriftsplan Vårt hovedprosjekt har 20 studiepoeng som er 2/3 av arbeidsuken. Dette tilsvarer 20-25 arbeidstimer per medlem som skal brukes på oppgaven. Timene er ment å bruke til planlegging, teknologi valgt, egenlæring, programmering, testing, feilsøking, forbedring og dokumentasjonsarbeid. Vi har satt som mål å være ferdig til 1. mai 2015 slik ved eventuelle avvik kan vi ha rom til å utføre nødvendige endringer. Dersom ingen avvik oppstår vil vi bruke tiden til utbedring av produktet. Estimert tidsbruk vil være ca 1600 timer totalt for oppgaven. Følgende tabell representerer vår tidsplan for gruppen. Tidsramme Antall uker Antall timer brukt i denne perioden Arbeidsoppgaver 01.01 – 01.05 16 700 Planlegging, opplæring, implementering og dokumentering av systemet 01.04 – 01.05 4 300 Enhetstesting, forbedring, dokumentasjon av test og resultat. Utbedringer basert på testresultater. 30.03 – 15.05 7 350 Dokumentasjonsarbeid 15.05 – 25.05 1 uke og 3 dager 150 Finskriving og dobbelsjekking 27.05 – 08.06 Ca 2 uke 100 Lage presentasjon av prosjektet Totalt 1600 Tabell 8.1: Tidsestimering. # Oppgave Hvor Frist Status 1 Statusrapport På nettet 24.10.2014 Levert 2 Prosjektskisse På nettet 5.12.2014 Levert 3 Forprosjekt På nettet 23.1.2015 Levert 4 Prosjektrapport I ekspedisjonen 26.5.2015 kl. 12.00 Levert 5 Presentasjon Auditorium 8.6 - 11.6.2015 Gjenstår Tabell 8.2: Prosjektets tidsfrister. Side 124 Tidsberegning for kravspesifikasjon: Spr-i Nr nt Pr
i Krav Spesifisering V T J B Gj. Status snit
t 1 1 A En administrator skal kunne logge inn. Administrator skal kunne 11 15 10 6 11 Utført. logge inn med en privat bruker, som har tilgang til styringsfunksjoner i applikasjonen. 1 2 A En administrator skal kunne opprette en ny pizza. Administrator skal kunne 10 12 16 10 12 Utført. velge navn, pris og ingredienser for en ny pizza, og lagre den i databasen. Det er forutsatt at ingredienser allerede er opprettet. 1 3 A En administrator skal kunne se en oversikt over lagrede pizzaer. Administrator skal kunne 12 11 16 9 12 Utført. se en oversikt over alle pizzaer som er lagret i databasen, med visning av alle detaljer. 1 4 A En administrator skal kunne opprette en ny ingrediens. Administrator skal kunne 3 velge navn og pris for en ny
ingrediens, og lagre den i databasen. Pris lagres for kunne bruke bestillingsfunksjonen (B-krav). 6 5 3 4,3 Utført. 1 5 A En administrator skal kunne se en oversikt over lagrede ingredienser. Administrator skal kunne 4 se en oversikt over alle ingredienser som er laget i databasen, med visning av alle detaljer. 3 4 2 3,3 Utført. 1 6 A En administrator skal kunne opprette et nytt tilbehør. Administrator skal kunne 5 velge navn og pris for nytt tilbehør (brus ol.), og lagre varen i databasen. 7 9 5 6,5 Utført. 1 7 A En administrator skal kunne se en oversikt over lagrede tilbehør. Administrator skal kunne 9 se en oversikt over alle tilbehør som er laget i databasen, med visning av alle detaljer. 10 12 15 12 Utført. 1 8 A En administrator skal kunne endre lagrede varer og ingredienser. Administrator skal kunne 5 gjøre endringer i navn, pris og eventuellt ingredienser for en vare som er lagret i databasen. 6 7 10 7 Utført. 1 9 A En administrator skal kunne slette lagrede varer. Administrator skal kunne 7 slette varer fra databasen via applikasjonen. 8 9 8 8 Utført. Side 125 1 10 A En pizza skal kunne inneholde flere priskategorier (stor, liten og glutenfri). Pizzaer kan komme i tre kategorier, stor, liten og glutenfri. Administrator skal kunne sette pris for alle kategorier. 1 11 A En administrator skal kunne opprette en nyhet. Administrator skal kunne opprette en nyhet, som vil lagres i databasen. En nyhet
skal vises i nyhetssiden. 1 12 A En administrator skal kunne se en oversikt over lagrede nyheter. Administrator skal kunne 15 12 14 16 14 Utført. Sammen
se en oversikt over alle med sprint 2 nyheter som er laget i databasen, med visning av alle detaljer. 1 13 A En administrator skal kunne opprette en informasjonsside, som gir et nytt valg i navigasjonsmenyen. Administrator skal kunne 16 17 19 15 17 Utført. opprette en ny informasjonsside, som vil lagres i databasen. En ny informasjonsside oppretter
et nytt navigasjonsmenyvalg. 1 14 A En administrator skal kunne se en oversikt over lagrede informasjonssider. Administrator skal kunne 20 25 26 18 22 Utført. Sammen
se en oversikt over alle med sprint 2 informasjonssider som er laget i databasen, med visning av alle detaljer. 1 15 A En administrator skal kunne endre og slette en nyhet. Administrator skal kunne 12 16 14 20 16 Utført. endre og slette en nyhet, via applikasjonen. Ved å slette en nyhet fra databsen, vil den også bli slettet fra nyhetssiden. 1 16 A En administrator skal kunne endre og slette en informasjonsside. Administrator skal kunne 17 18 20 12 17 Utført. Sammen
endre og slette en med sprint 2 informasjonsside, via applikasjonen. Ved å slette en informasjonsside fra databasen, vil den også bli slettet fra navigasjonsmenyen. 2 17 B En administrator skal kunne ha oversikt over databaselogger. Loggføring av 16 17 19 15 17 Utført, men ikke
databasehendelser, som implementert. administrator skal kunne Oppdragsgiver ha oversikt over. ønsket ikke denne funksjonen. 2 18 B En administrator skal kunne ha oversikt over loggføring av feil. Loggføring av feilmeldinger10 11 13 10 11 Utført, men kun
til fil, som administrator tilgjengelig for skal kunne ha oversikt over.
utvikler. 2 19 B Muligheten til å skrive ut innkommende bestillinger automatisk via en liten printer. Oppdragsgiver ønsker 4 bestillingene skrevet ut på på papir. Side 126 19 18 20 18 19 Utført. Sammen
med sprint 2 7 9 Utført. 7 6,8 Ikke utført. 2 20 B En kunde skal kunne opprette en bruker. Kunde skal kunne opprette 9 en bruker med adresse, telefonnummer, epostadresse og passord. 8 5 6 7 Utført, men ikke
implementert. Venter på punkt
19. 2 21 B En bruker skal kunne logge Brukeren skal kunne logge 15 18 16 18 17 Utført, men ikke
inn. inn med e-post og passord.
implementert. Må logge inn for å få Venter på punkt
tilgang til bestilling vi 19. applikasjonen. 2 22 B En administrator skal kunne opprette, endre og slette brukere. Administrator skal kunne 14 12 13 17 14 Utført, men ikke
opprette nye brukere, implementert. endre brukere, og slette Venter på punkt
brukere fra databasen. Kun 19. en administrator skal ha tilgang til disse funksjonene. 2 23 B En administrator skal kunne se en oversikt over registrerte brukere. 2 24 B Systemet skal forhindre uautorisert tilgang til kundeinformasjon. Profiler til hver enkelt 5 bruker skal være beskyttet. Rollene skal være forhåndsdefinerte. 5 8 8 6,5 Utført, men ikke
implementert. Venter på punkt
19. 2 25 B En kunde skal kunne bestille pizza. Kunder som er logget inn 4 skal kunne legge inn en bestilling via applikasjonen. 4 9 8 6,3 Utført, men ikke
implementert. Venter på punkt
19. 2 26 B En kunde skal kunne komponere en egen pizza. En kunde skal kunne 6 komponere egen pizza. Velger mellom ingredienser
og bunn. 7 6 6 6,3 Utført, men ikke
implementert. Venter på punkt
19. 2 27 B En bruker skal kunne se sin Egen kundeprofil. egen profil, og gjøre endringer. 7 8 9 9 8,3 Utført, men ikke
implementert. Venter på punkt
19. 2 28 B En bruker skal kunne slette sin egen brukerkonto. 5 6 9 4 6 2 29 B En kunde skal ikke ha tilgang til andre brukerkontoer. 2 30 B En bruker skal kunne velge størrelse på pizza. 14 14 15 16 15 Utført. 2 31 B En bruker skal kunne velge glutenfri pizzabunn. 12 10 10 12 11 Utført. 2 32 B En bruker skal også kunne kjøpe tilbehør, som brus og 7 13 17 12 17 15 Utført, men ikke
implementert. Venter på punkt
19. Utført, men ikke
implementert. Venter på punkt
19. Kunden skal ikke ha 15 15 12 12 14 Utført, men ikke
mulighet til å se eller gjøre implementert. endringer på andres Venter på punkt
profiler. 19. Side 127 7 7 7 7 Utført. dressing. 2 33 B En bruker skal kunne bestille flere varer. 19 17 14 16 17 Utført. ​
3 34 C En bruker skal kunne velge om pizzaen skal kjøres ut eller ikke. 29 36 36 27 32 Utført. 3 35 C En bruker skal kunne finne Telefonnummeret skal 16 17 19 15 17 Utført. ut hvordan han kan ta være lett tilgjengelig. For kontakt med butikken. eksempel i en footer, i en tittel, eller andre passende steder. 4 36 A Applikasjonen skal inneholde mulighet for å analysere brukeratferd via Google Analytics. 30 37 39 32 35 Utført. 37 A Systemet skal være brukervennlig og raskt. Webapplikasjonen skal respondere raskt og ikke oppleves tregt 19 17 19 17 18 Utført 38 A En bruker skal ikke måtte bruke mer enn tre klikk i menyen for å komme til ønsket menyvalg Menyhierarkiet ikke har mer enn to til tre forgreninger 29 27 26 29 28 Utført. 39 A Nettsiden skal kunne tilpasse seg forskjellige enheter og nettlesere. Det skal være en dynamisk 25 40 40 25 33 Utført. design og enhet uavhengig.
40 A Systemet skal kunne videreutvikles. Systemet skal utvikles etter30 38 30 31 32 Utført. standarder og “god praksis”
slik at videreutvikling er mulig. 41 B Siden skal være søkemotoroptimalisert Applikasjonen skal blant 25 25 30 26 27 Delvis utført. annet ta i bruk meta-tagger.
42 C Spørringer til databasen skal ikke ta mer enn 3 sek ved normal bruk. Spørringer mot databasen 40 34 34 40 37 Utført. skal hente så lite som mulig
slik at en spørring ikke tar med enn 3 sekunder 43 C Systemet skal ha et Oppdragsgiver og kunder 16 17 19 15 17 Utført. innbydende og funksjonelt av systemet synes designet design er rent, pent og satt opp slik
at det er lett å gjøre oppgaven sin. 1 4 1 4 1 4 1 4 1 4 2 4 3 4 3 Totalt antall timer brukt av gruppemedlemmer: 567 621 641 582 602 Gjennomsnitt tidsbruk for funksjonelle og ikke funksjonelle krav har vært ca 600 timer. Tabell 8.3: Tidsberegning for kravspesifikasjon. Side 128 Sprinter Ukenr. # Antall timer Oppsummering Imple- Oppgaver som er overført til andre mentert sprinter 3-6 1 146 Gruppen har utført mange av punkter som var i sprinten og resterende underpunkter ble overført til neste sprint nr 3 og 4. 93 % Krav nr 12,13,14 utført parallelt med sprint 3 og 4. 6 -12 2 150 Underpunkter fra forrige sprint er utført samt en god del av punktene i sprint #2. 71 % Kravspesifikasjonenei denne sprinten er utført men ikke implementert da oppdragsgiver ikke vil ta dem i bruk i første omgang. Ref: Møte referat 20.03.2014 (Utkast av prosjektet og Økt kravspesifikasjon). 12-14 3 81 Gruppen har delvis dekket punktene fra sprint 2 som var knyttet til brukers profil. Noen av kravene jobbes parallelt med i sprint 3 og 4. 89 % Gruppen har implementert mange av kravspesifikasjonene som er i denne fasen. Kun et krav ikke er implementert. 14-19 4 209 Design og ikke funksjonelle krav er hovedpunktene som det jobbes med i denne uken. 90 % Ønsket kravspesifikasjon i henhold til denne sprinten er utført, noen er implementert og andre implementeres før levering av prosjektet til oppdragsgiver. 13-20 5 300 Gruppen utfører de resterende punktene fra forrige sprint samt starter testing av produktet 100 % Tester knyttet til sprinter og unittesting er utført. Tabell 8.4: Timer overført til neste sprint. Bilde 8.1: Scrumtavle som viser ferdigstilling av forprosjektdokumentet og kravspesifikasjon. Uke 3, 2015 Side 129 Bilde 8.2: Viser brukerhistorier over alle punkt i sprint 1 til 4. En tidligere versjon av kravspesifikasjon. Bilde 8.3: Viser brukerhistorier over alle punkt i sprint 3 – 5 og presentasjonssprint. Side 130 Bilde 8.4: Liste over utførte krav i kravspesifikasjonen. Side 131 Oppdatert scrumtavle som samsvarer med kravspesifikasjonen Etter hvert som kravspesifikasjonen endret seg har vi også endret sprintene. Bilde 8.5: Oppdatert liste over nye og oppdaterte krav i kravspesifikasjonen. Uke 19. Bilde 8.6: Oppdatert liste over nye og oppdaterte krav i kravspesifikasjonen. Uke 19. Side 132 8.2.2 Fremdriftsplan for testing og rapport Her følger en oversikt over hvordan vi arbeidet med sprintene​
. Sprinter (se bilde 8.5 og 8.6) Ukenr. Beskrivelse Oppsummering Kommentar 14 Lage en liste med brukertest som skal dekke alle brukerhistorier som vi har hatt. Det blir en test som effektiviserer oppdragsgivers produktkrav. Basert på disse punktene kan vi vite om hva som fungerer og hva som ikke fungerer. En liste over Brukerhistorier er opprettet og levert til oppdragsgiver til testing. Parallelt med sprint 4 15-16 White-box testing: - Lagring, endring og sletting av verdier inn og fra databasen. - Teste relasjonen mellom MVC lagene og rette ev terror mellom klassene. - Teste både MVC og Angular controllere og kvalitet sikre kommunikasjonen mellom klassene. - Teste HTML og CSS/bootstraps kodene for å utelukke evt kode feil. Black-box testing. - Opprette, redigere og slette en bruker. - Endre, slette og opprette nye produkter. - Legge til og fjerne en nyhet. - Teste google analytics - Teste og navigere inne i navigasjonsmeny og se om man ikke kommer til et annet sted enn forventet link. Gruppen har opprettet en list med punkter som skulle testes. Disse går ut på både White og Black box testing. Under Whitebox testing har vi opprettet, endret, slettet informasjon fra nettsiden og sjekket om de samtidig ble fjernet fra databasen. Vi har sent database spørring for å se om kontrollere fungerer nøyaktig som de er ment til og at informasjonen vi får ut er riktig. Vi har kjørt unittesting på Kontrollere i MVC modellen og alle lagene sender informasjon til riktig sted. I Black box testingen har vi opprettet, endret slettet pizza, ingrediens, nyhet, infopage, brukere, tilbehør og alt fungerte, og de kosmetiske feilene ble rettet. Vi har dokumentert resultatet av testene i kapittel 4. Parallelt med sprint 4 Side 133 -
Sikkerhetsteste pålogging. 16-19 Her tester gruppen registrering av verdier, nyheter og relevante informasjon i databasen. Starte enhetstesting. Forbedring av koden ved alvorlige feil eller mangel. Fullfører enhetstesting. Implementere applikasjonen på oppdragsgivers webserver (Windows) med støtte for .NET. Teste nettsiden med forskjellige enheter. Vi klarte å opprette, endre, slette og Parallelt med sprint 5 liste ut pizza og ingrediens, nyheter, infopage og andre relevante funksjoner. Det var små problemer relatert til tegneoppsett. Enhetstesting er utført og resultat er lastet opp under enhetstesting i kapittel 4.2.8 og 4.2.9 i sluttrapporten. Vi har implementert løsningen på serveren der oppdragsgiver kjøper sin domene og server tjenester. Implementeringen har møtt problemer som går ut på kompatibilitets modus. Vi tar tak i problemet rett etter at sluttrapporten er levert. 20 Dra til oppdragsgiver med ferdig produkt og rette feil og endre til ønsket design. Ferdigstille rapport Vi dro til oppdragsgiver og fikk med oss Parallelt med sprint 5 siste ønskede endringer og levert et brukertestdokument for at han skal kunne teste applikasjonen. Gruppen jobbet videre med å ferdigstille rapporten. 21 Levering av rapport til trykking senest 20. mai. Leverer bachelor oppgaven 26.Mai. Tabell 8.5 : Fremdriftsplan over testing og dokumentasjonslevering. Side 134 Bilde 8.7: Scrumtavle for testing. Side 135 Bilde 8.8: Liste over utførte Black-box-tester. Bilde 8.9: Liste over utførte Black-box-tester. Side 136 8.3 Møter med oppdragsgiver Møtereferat 22. januar 2015 (Planleggingsfase) Deltakere fra gruppe 23: ● Vahid Khairkhah ● Torstein Frogner ● Jonas Myren Mo ● Bernt Kristoffer Helland Oppdragsgiver: ● Mansour Jam Møtet med oppdragsgiver gikk ut på å diskutere løsningen han ønsker seg og notert ønskede krav. Det ble presenter en del nettsider, blant annet Peppes, Flamenco og Dolly Dimple’s, slik at oppdragsgiver kunne ha et utgangspunkt når det kommer til design. Det ble avtalt å ha et møte med oppdragsgiver og veileder onsdag den 29. januar 2015 for å skrive under kontrakten. Følgende punkt ble diskutert: ● Vi fikk innblikk over måten oppdragsgiver utfører endringer i sitt nåværende system. Det viste seg at oppdragsgiver er veldig avhengig av andre personer med IT-bakgrunn for å endre sin nåværende løsning da alt er hardkodet i HTML. Hovedpunkter som kom frem i møtet var: ● Oppdragsgiver sliter med å få endre priser i nettsiden. Siden matvarepriser og driftskostnader økes, må dette balanseres i salgspriser. ● Det kommer stadig nye pizzaer og endring i produkter. Det er ønskelig å få kunne endre disse med mindre enn fem taste klikk i nettsiden. ● Da det er mange barer i nærheten av butikken som oppdragsgiver har avtale med så er det fint at dette kan informeres ut til kundene. ● Oppdragsgiver ønsker seg egen meny for å kunne informere om dagens tilbud. ● Menyen skal være leselig og informativ. ● Det skal legges ny funksjon som viser glutenfripriser da dette er nytt. ● Bruker ønsker å ha tilknytning til Google Analytics, for å følge mønsteret til besøkende. I senere omgang vil han ha en avtale med Google der han betaler for antall klikk og besøk på nettsiden. Denne funksjonen blir implementert når oppdragsgiver ønsker å sette den nye løsningen i produksjon og deaktivere sin gamle. Oppdragsgiver ønsker seg ikke de forslagene vi hadde rundt valg av nettsideløsning og ønsket seg en forbedret utgave av nåværende design for å ivareta organisasjonens logo og design. Det ble ikke sendt møtereferat etter enighet med oppdragsgiver. Det ble bestemt at møtereferater skal brukes av gruppen til egen utviklingsprosess. Side 137 Møtereferat 29. januar 2014 (Kontraktsignering) Deltakere fra gruppe 23: ● Torstein Frogner ● Jonas Myren Mo ● Bernt Kristoffer Helland Oppdragsgiver: ● Mansour Jam Veileder: ● Ismail Hussain Etter krav fra HIOA så var det obligatorisk å skrive under en avtale om prosjektoppgaven. Avtalen handler om samarbeid mellom studenter, veileder og oppdragsgiver. Møtereferat 13. mars 2015 (Nye krav) Deltakere fra gruppe 23: ● Vahid Khairkhah Oppdragsgiver: ● Mansour Jam Det ble presentert en prototype av applikasjonen til oppdragsgiver. ● Oppdragsgiver kom med ønske om nye krav, funksjonsendringer og forbedringer: ● Ønske om å kunne registrere flere ansatte under administrator siden, slik flere ansatte kan utføre endringer i nettsiden. ● Ønske om bestillingsmulighet for kunder. Om mulig å integrere løsningen slik at bestillingen ble sendt som en utskrift til butikkens nåværende labelprinter som er levert av «Just Eat». ● Opprettelse av kundekonto slik at kundene kunne se sine tidligere bestillinger og endre profil. ● Ønske om å gi muligheten til å lage egne infosider, i tilfelle han skulle ønske å opprette en meny. Etter samtale med oppdragsgiver ble vi enig om at det som vi får tid blir implementert og at gjenstående krav kan bli utført senere, enten av gruppen eller andre utviklere. Side 138 Møtereferat 22. april 2015 (Visning av prototype) Deltakere fra gruppe 23: ● Vahid Khairkhah ● Jonas Myren Mo Oppdragsgiver: ● Mansour Jam I møtet med oppdragsgiver ble ny versjon av prototypen presentert. Snakket litt om funksjonaliteten til nettsiden og hvordan vi burde gå videre i utviklingen. ● Oppdragsgiver ønsket seg følgende endring: ● En annerledes logo. ● Oransje farge på hele nettsiden med svart tekst, men vi klarte å overbevise han om at dette ikke er lurt med tanke på universell utforming. ● Implementere bilde av pizzatesten fra Oslopuls’ pizzatest ● I dette møtet ble det nevnt ønske om å stoppe implementeringen av bestillings- muligheten da kunden ikke har nok kapasitet til å ta imot bestillinger fra denne kilden. Møtereferat 11. mai 2015 (Gjennomgang av forbedret prototype) Deltakere fra gruppe 23: ● Vahid Khairkhah Oppdragsgiver: ● Mansour Jam I møte med oppdragsgiver ble ny versjon av prototype presentert hvor tidligere feil var rettet. Alle funksjonaliteter ble testet av Vahid og fremvist til oppdragsgiver. Det var bare positive tilbakemeldinger. Oppdragsgiver likte hvor enkelt han kan utføre endringer i webapplikasjonen. Vi ble enig om at Vahid tar med en liste med spørsmål hvor oppdragsgiver tester og karakteriserer brukervennlighetsgraden. Testen vil leveres til oppdragsgiver i form av papir og sluttresultatet blir lastet opp. Side 139 Møtereferat 14. mai 2015 (Brukertesting / pilot) Deltakere fra gruppe 23: ● Vahid Khairkhah Oppdragsgiver: ● Mansour Jam Vi har vist frem pilotprogrammet for oppdragsgiver. Oppdragsgiver fikk til sammen 40 spørsmål relatert til kravspesifikasjonen og testet ut funksjonalitetene. Oppdragsgiver var meget positiv til resultatet og hadde noen kosmetiske forbedrings punkter som han ønsket seg for vi går i produksjon. Det meste var relatert til design. Detter er dokumentert i testdokumentasjonen i kapittel 4. 8.4 Brukertest Kunde Testene kan leses ved å følge lenken i fotnoten.25 Administrator Oppdragsgiver har svart på til sammen 32 spørsmål som omhandlet funksjonaliteten til applikasjonen: 25
Brukertest. ​
Gruppe 23.​
Hentet fra h​
ttps://www.dropbox.com/sh/g1h1j6u4tdnovmq/AABUHA2SFys-yEnPMt8T0_u6a?dl=0 Side 140 Side 141 Side 142 Side 143 Side 144 Side 145 Side 146 Bilde 8.10: Syv sider med skjema for administratortester. Side 147 8.5 Kildekode og anvisninger til kjørbar versjon 8.5.1 For fysisk sluttrapport Sammen med sluttrapporten blir det levert en CD med komplett kildekode for webapplikasjonen. Les filen README.txt på CDen og følg instruksjoner. 8.5.2 For digital sluttrapport Sluttrapporten vil være tilgjengelig på prosjektsiden vår på hioa.no. Når oppdragsgiver bestemmer seg for å produksjonsette applikasjonen, vil den ta over for den eksisterende løsningen og vil den være tilgjengelig på www.pizzzaplutselig.no. Side 148