Plutselig Webapp. Bachelorprosjekt Bernt Kristoffer Helland Jonas Myren Mo Torstein Frogner Vahid Khairkhah

Transkript

1 Plutselig Webapp Bachelorprosjekt 2015 Bernt Kristoffer Helland Jonas Myren Mo Torstein Frogner Vahid Khairkhah

2 Side 2

3 PROSJEKT NR. 23 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Offentlig Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Plutselig Webapp DATO 24. mai 2015 ANTALL SIDER / BILAG PROSJEKTDELTAKERE Vahid Khairkhah Torstein Frogner Jonas Myren Mo Bernt Kristoffer Helland s184775@stud.hioa.no s162273@stud.hioa.no s188089@stud.hioa.no s188106@stud.hioa.no INTERN VEILEDER Ismail Hassan OPPDRAGSGIVER Pizza Plutselig KONTAKTPERSON Mansour Jam, , mansor.jam@live.no SAMMENDRAG Plutselig Webapp, en webapplikasjon for pizzabutikken Pizza Plutselig. 3 STIKKORD CMS AngularJS Single page application Side 3

4 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, produktdokumentasjon, 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

5 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

6 Innholdsfortegnelse Forord 4 Leserveiledning 4 Oppsummering 4 Primærfunksjonaliteten til applikasjonen 5 Innholdsfortegnelse 6 Kapittel 1 - Kravspesifikasjon Forord Presentasjon Bakgrunnen Motivasjon Funksjonalitet Kort systembeskrivelse Rammekrav i systemet Funksjonelle krav Ikke-funksjonelle krav 19 Kapittel 2 - Prosessdokumentasjon Forord Forberedelser og planlegging Valget av oppgaven Definere oppgaven og omfang Finne riktig rammeverk Oppstartfasen Milepælsplan Utviklingsverktøy Microsoft Visual Studio Ultimate Dia Bitbucket Trello Dropbox Notepad Testmiljø Doxygen Microsoft Word Facebook Utviklingsmetodikk Innledning Daglige utfordringer Dagboken Scrumbrett Versjonskontroll Møter med veileder 30 Side 6

7 2.4.7 Møter med oppdragsgiver Gruppesiden Kravspesifikasjonen Forklaring Endringer i kravspesifikasjonen Samsvar mellom opprinnelig og endelig kravspesifikasjon Fremdriftsplan Innledning Utviklingsfasene Tidsberegning Samspillet mellom fremdriftsplan og scrumbrett Designutvikling Utformingen av designet Endelig design Refleksjoner til produktet Innledning Ting vi ville gjort annerledes Tverrfaglig utbytte Veien videre Nytteverdi for oppdragsgiver Oppdragsgivers tilbakemelding Oppsummering og konklusjoner Risiko og svakheter 42 Kapittel 3 - Produktdokumentasjon Forord Beskrivelse av webapplikasjonen Kort om Byggeklosser Sentrale datastrukturer i applikasjonen Innledning MVC De sentrale modellene Modellrelasjoner Funksjoner og metoder Lagdeling Hvorfor lagdeling Lagdeling i MVC Programmets virkemåte Oppstart av webapplikasjonen Admin i nettleseren Kundehandlinger i bruk Spesifikke handlinger i bruk Design Innledning Oppdragsgivers ønsker 53 Side 7

8 3.6.3 Brukergrensesnitt (UI) Brukeropplevelse (UX) Responsivt design (optimalisert for alle enheter) Universell utforming Rammeverk og teknologier tatt i bruk Sikkerhet Passordsikring Databasesikkerhet Backup og Rollback-plan Systemkrav Klient Server Samsvar mellom kravspesifikasjon og det ferdige produktet Fordeler og ulemper med en skreddersydd applikasjon 58 Kapittel 4 - Testdokumentasjon Forord Enhetstesting Formål med testen Utførte tester Gjenstående testing Utforming av testen Kjøring av enhetstester Resultater og tiltak Brukertest Formål med testen Utforming av testen Resultater og tiltak fra test utført av potensielle kunder Resultater og tiltak fra admintest utført av oppdragsgiver Ad hoc-testing Gjennomføring av testing Resultater av testen Konklusjon av testen 69 Kapittel 5 - Brukerveiledning Forord Terminologi Innledning Veiledningen Bruker og admin Administrasjon For kunder 86 Kapittel 6 - Oppslag Figurer Tabeller Bilder Kilder 94 Side 8

9 Kapittel 7 - Teknisk evaluering Forord Utviklingsverktøy AngularJS Versjon Beskrivelse av rammeverket Hvorfor AngularJS? Model Databasestruktur Databaseaksess View HTML CSS, Bootplus og design Google Analytics Metadata Controller AngularJS JSON Sikkerhet Våre vurderinger, og utviklingspotensiale Bruker og bestilling Sikkerhetsvurdering Øvrig Brukerveiledning for server og database Server Driftsoppgaver på serveren Database FTP-server Alias Pakkereferanser 115 Kapittel 8 - Vedlegg Prosjektdagbok oktober november november januar januar januar januar januar januar januar januar februar februar Side 9

10 23. februar februar mars mars mars mars mars april april april april april april mai mai mai mai mai mai mai mai mai mai Fremdriftsplan Fremdriftsplan for implementering Fremdriftsplan for testing og rapport Møter med oppdragsgiver 137 Møtereferat 22. januar 2015 (Planleggingsfase) 137 Møtereferat 29. januar 2014 (Kontraktsignering) 138 Møtereferat 13. mars 2015 (Nye krav) 138 Møtereferat 22. april 2015 (Visning av prototype) 139 Møtereferat 11. mai 2015 (Gjennomgang av forbedret prototype) 139 Møtereferat 14. mai 2015 (Brukertesting / pilot) Brukertest Kildekode og anvisninger til kjørbar versjon For fysisk sluttrapport For digital sluttrapport 148 Side 10

11 Side 11

12 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: Definisjon: Plutselig Webapp 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. Gruppemedlemmer: Torstein Frogner Bernt Kristoffer Helland Vahid Khairkhah Jonas Myren Mo Gruppenummer: 23 Oppdragsgiver: Kontaktperson: Intern veileder: Pizza Plutselig, Ullevålsveien Oslo Mansour Jam mansor.jam@live.no Ismail Hassan Ismail.Hassan@hioa.no Side 12

13 1.3 Bakgrunnen 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 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 maskinuavhengig. 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

14 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

15 Verktøy som skal brukes i utviklingen er: Notepad++. Dia / ArgoUML for tegninger av diagrammer og uml-er. Visual Studio Ultimate 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. 2 A En administrator skal kunne opprette en ny pizza. 3 A En administrator skal kunne se en oversikt over lagrede pizzaer. 4 A En administrator skal kunne opprette en ny ingrediens. 5 A En administrator skal kunne se en oversikt over lagrede ingredienser. Administrator skal kunne logge inn med en privat bruker, som har tilgang til styringsfunksjoner i applikasjonen. 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. Administrator skal kunne se en oversikt over alle pizzaer som er lagret i databasen, med visning av alle detaljer. Administrator skal kunne velge navn og pris for en ny ingrediens, og lagre den i databasen. Pris lagres for kunne bruke bestillingsfunksjonen (B-krav). Administrator skal kunne se en oversikt over alle ingredienser som er laget i databasen, med visning av alle detaljer. Side 15

16 6 A En administrator skal kunne opprette et nytt tilbehør. 7 A En administrator skal kunne se en oversikt over lagrede tilbehør. 8 A En administrator skal kunne endre lagrede varer og ingredienser. 9 A En administrator skal kunne slette lagrede varer. 10 A En pizza skal kunne inneholde flere priskategorier (stor, liten og glutenfri). 11 A En administrator skal kunne opprette en nyhet. 12 A En administrator skal kunne se en oversikt over lagrede nyheter. 13 A En administrator skal kunne opprette en informasjonsside, som gir et nytt valg i navigasjonsmenyen. 14 A En administrator skal kunne se en oversikt over lagrede informasjonssider. 15 A En administrator skal kunne endre og slette en nyhet. Administrator skal kunne velge navn og pris for nytt tilbehør (brus ol.), og lagre varen i databasen. Administrator skal kunne se en oversikt over alle tilbehør som er laget i databasen, med visning av alle detaljer. Administrator skal kunne gjøre endringer i navn, pris og eventuellt ingredienser for en vare som er lagret i databasen. Administrator skal kunne slette varer fra databasen via applikasjonen. Pizzaer kan komme i tre kategorier, stor, liten og glutenfri. Administrator skal kunne sette pris for alle kategorier. Administrator skal kunne opprette en nyhet, som vil lagres i databasen. En nyhet skal vises i nyhetssiden. Administrator skal kunne se en oversikt over alle nyheter som er laget i databasen, med visning av alle detaljer. Administrator skal kunne opprette en ny informasjonsside, som vil lagres i databasen. En ny informasjonsside oppretter et nytt navigasjonsmenyvalg. Administrator skal kunne se en oversikt over alle informasjonssider som er laget i databasen, med visning av alle detaljer. Administrator skal kunne endre og slette en nyhet, via applikasjonen. Ved å slette en nyhet fra databsen, vil den også bli slettet fra nyhetssiden. Side 16

17 16 A En administrator skal kunne endre og slette en informasjonsside. 17 B En administrator skal kunne ha oversikt over databaselogger. 18 B En administrator skal kunne ha oversikt over loggføring av feil. 19 B Muligheten til å skrive ut innkommende bestillinger automatisk via en liten printer. 20 B En kunde skal kunne opprette en bruker. 21 B En bruker skal kunne logge inn. 22 B En administrator skal kunne opprette, endre og slette brukere. Administrator skal kunne endre og slette en informasjonsside, via applikasjonen. Ved å slette en informasjonsside fra databasen, vil den også bli slettet fra navigasjonsmenyen. Loggføring av databasehendelser, som administrator skal kunne ha oversikt over. Loggføring av feilmeldinger til fil, som administrator skal kunne ha oversikt over. Oppdragsgiver ønsker bestillingene skrevet ut på på papir. Kunde skal kunne opprette en bruker med adresse, telefonnummer, epostadresse og passord. Brukeren skal kunne logge inn med e-post og passord. Må logge inn for å få tilgang til bestilling vi applikasjonen. Administrator skal kunne opprette nye brukere, endre brukere, og slette 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. 25 B En kunde skal kunne bestille pizza. Profiler til hver enkelt bruker skal være beskyttet. Rollene skal være forhåndsdefinerte. 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

18 komponere en egen pizza. 27 B En bruker skal kunne se sin egen profil, og gjøre endringer. pizza. Velger mellom ingredienser og bunn. 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 finne ut hvordan han kan ta kontakt med butikken. Telefonnummeret skal være lett tilgjengelig. For eksempel i bunn av siden. Tabell 1.1 : Funksjonelle krav i kravspesifikasjon. Side 18

19 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. 39 A En bruker skal ikke måtte bruke mer enn tre klikk i menyen for å komme til ønsket menyvalg 40 A Nettsiden skal kunne tilpasse seg forskjellige enheter og nettlesere. 41 A Systemet skal kunne videreutvikles. 42 B Siden skal være søkemotoroptimalisert 43 B Systemet skal ha et innbydende og funksjonelt design Webapplikasjonen skal respondere raskt og ikke oppleves tregt Menyhierarkiet ikke har mer enn to til tre forgreninger Det skal være en dynamisk design og enhet uavhengig. Systemet skal utvikles etter standarder og god praksis slik at videreutvikling er mulig. Ved bruk av meta-tagger. 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

20 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 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

21 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 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 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 1 skal rette problemene. 1 Emm, D. (2013, 3. juli). Java Exploits - Do You Need to Be Worried? The Huffington Post. Hentet fra Side 21

22 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 2 kjente sårbarheter som lett kan oppdages ved hjelp av automatiserte verktøy. Cyberkriminelle har lenge oppdaget disse sikkerhetshullene, med over WordPress-kontoer som ble hacket i Figur 2.1: De forskjellige CMS-enes markedsandel. Da vi gjorde undersøkelser rundt sårbarheten til en rekke standardiserte CMS-løsninger, fant vi 4 ut at hackere anser de å være attraktive mål ettersom de er bygget i åpen kildekode. 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:// 3 Cassetto, O. (2014, 11. september). Why CMS Platforms Are Common Hacking Targets (and what to do about it). 4 Cassetto, O. (2014, 11. september). Why CMS Platforms Are Common Hacking Targets (and what to do about it). Side 22

23 bruke malwaredistribuering som resulterer i at nettsiden til slutt havner på Google og andre 5 søkemotorer sine svartlister. 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 Side 23

24 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 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. 6 Tuliper, A. (2011, desember). Hack-Proofing Your ASP.NET Applications. MSDN Magazine. Hentet fra Side 24

25 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

26 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: 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 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 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å 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 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

27 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 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 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 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 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 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

28 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 Dagboken Dagboken har vært i kontinuerlig oppdatering fra begynnelse av hovedprosjektet, 01.oktober 2014 frem til innlevering 26. Mai 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

29 Dagboken er lagt som vedlegg i delkapittel 8.1 med oppdatering frem til trykking av sluttrapporten 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 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

30 Bilde 2.2: Commit fra bitbuckets source tree for dokumentasjon Møter med veileder Første møte med veileder var den 21. januar 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 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

31 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 Gruppesiden Gruppesiden ble oppdatert under hver innlevering for at dokumenter skulle være tilgjengelig for oppdragsgiver. 2.5 Kravspesifikasjonen 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 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 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

32 2.6 Fremdriftsplan 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 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 Tidsberegning Vårt hovedprosjekt har 20 studiepoeng som er 2/3 av arbeidsuken. Det tilsvarer at hvert gruppemedlem skal bruke 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

33 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 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

34 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

35 2.7 Designutvikling 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 7 ignorert av brukeren. 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 Side 35

36 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

37 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

38 Bilde 2.11: Utkast til infoside med kart. Bilde 2.12.: Forside, med gammel logo. Side 38

39 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 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 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

40 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 Programmeringsstrukturer og fordeling av koden i klasser for effektivisering av kode. Webprosjekt DAFE1200 HTML og CSS, universell utforming og nettsideoppbygging. Databaser DATS 1500 Databaseoppbygging og SQL-spørringer. Programutvikling DATS1600 Utvikling av komplekse applikasjoner. Algoritmer og datastruktur DATS2300 Logisk oppsett av datastrukturer og algoritmer i webapplikasjonen for sortering i databasen. Operativsystemer DATS2500 Backup og krypteringsmekanismer. Systemutvikling DAFE2200 Utviklingsmetodikk og prosjektarbeid. Planlegging. Nettverk og systemadministrasjon DATS2400 Server og domenekunnskaper Webapplikasjoner ITPE3200.Net Framework og C#-programmering. Datasikkerhet 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 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

41 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 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 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 / 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

42 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 Sannsynlighet Konsekvens Tiltak Gjennomføring av alle krav i kravspesifikasjonen 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. Overstigning i budsjettet Anklaget for plagiat Nettsiden blir hacket Egenkapital og økonomiske støtte ikke rekker på grunn av komplikasjoner og driftskostnader Andre har allerede utviklet den samme ideen både i Norge eller andre land. Personlige informasjon blir misbrukt av en hacker. 5% Webapplikasjonen blir kostbart å drifte. 1% Man kan fort komme i en rett sak for copyright. Samt kan den ha økonomiske konsekvenser 30% Personlig informasjon blir brukt i ulovlige sammenhenger. Nettsiden blir utilgjengelig eller deaktivert. Få en prisoveslag over leverandører som tilbyr drifttjenester og velge den mest aktuelle i henhold til pris og tilgjengelighet. Laget egen CMS løsning for oppdragsgiver. Tvinge brukere til å kommunisere via https og passordsjekking for databaseaksess. Tabell 2.3: Liste over risiko og tiltak knyttet til prosjektet. Side 42

43 Side 43

44 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 Beskrivelse av webapplikasjonen 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 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

45 Plassering # Oppgave Navn Kommentar Back end Front end 1 Applikasjons -rammeverk Microsoft.NET Framework.Net Framework er et rammeverk for utvikling av webapplikasjoner. 2 MVC-rammeverk ASP.NET MVC 5 ASP.NET MVC 5 er rammeverket som har blitt brukt til å implementere MVC strukturen. 3 Database SQL, LINQ, Entity Framework SQL Database. Lagring av data. Med linq syntax, strukturert ved hjelp av Entity Framework. 4 Back end språk Microsoft visual C# Programmeringsspråket C# (C-Sharp) har blitt brukt for å utforme backend. 5 Funksjonalitet i view. JavaScript (AngularJS) AngularJS er et JavaScript rammeverk for single page applikasjoner. Brukt til å utvikle en RESTful webapplikasjon. 6 Visning av hypertekst HTML5 HTML5 er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. 7 Design CSS3 (Bootplus) Bootplus er brukt til design av nettsiden. CSS-rammeverk som bygger på Bootstrap. Øvrig 8 Overføring av data JSON JSON har blitt brukt til overføring av data mellom databasen og modellene. Tabell 3.1: Plassering av komponenter. 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

46 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. to-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 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 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 8 controlleren, som kommuniserer mellom modellen og view-et. 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 Side 46

47 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

48 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 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

49 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 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 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 T 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 F T I F R F

50 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

51 3.4 Lagdeling Hvorfor lagdeling Hovedgrunnen til at applikasjonen er lagdelt er at det vil forenkle utvikling og videreutvikling 9 av systemet. 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 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 11 (DAL). Dataaksesslaget (DAL). Dataaksesslaget har som oppgave å hente lagret data fra for eksempel en database. Tar i mot 12 spørringer, og sender etterspurt data til modellene, via forretningslogikklaget (BLL). 9 Stack Overflow. (2008). What is the purpose of a Data Access Layer? Hentet fra 10 Loose coupling. (2015). Wikipedia. Hentet fra 11 Business Logic. (2015). Wikipedia. Hentet fra 12 Data Access Layer. (2015). Wikipedia. Hentet fra Side 51

52 3.5 Programmets virkemåte 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 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 Kundehandlinger i bruk Alle kundehandlinger vil skje i 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 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

53 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. Man velger produkter fra pizza-menyen, og eventuellt tilbehør. 2. Velger til bestilling. 3. En sjekk om man er logget inn, for å kunne fullføre en bestilling. 4. Eventuell innlogging/registrering av ny bruker. 5. Fullfører bestillingen, som blir lagret i databasen og sendt til restauranten. 3.6 Design 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 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

54 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 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 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 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 13 Side 54

55 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 Ikke-tekstlig innhold Meningsfylt rekkefølge Bruk av farge Endring av tekststørrelse Bilder av tekst Språk på siden 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: ( ) 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

56 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 Rammeverk og teknologier tatt i bruk Det er tatt i bruk følgende teknologier og rammeverket i designprosessen: Teknologinavn Beskrivelse Hvor er den brukt Bootplus Angular Et CSS-rammeverk som gir større og bedre funksjonsmuligheter. Et JavaScript-bibliotek som lar oss utvide vårt program raskere, mer lesbar. Rammeverket fungerer godt med andre bibliotek. Brukes for å gi utseende til HTML-filene. Brukt til å uttrykke bilder, animasjon og opplasting av data i en mer elegant måte. Bitter (font) En font vi fant på Google Fonts. Brukt til visning av tekstene i webapplikasjonens. Tabell 3.4: Design og rammeverk. 3.7 Sikkerhet 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 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

57 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 gruppemedlemmers 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 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

58 Vi anbefaler å bruke den nyeste versjonen av følgende nettlesere: Google Chrome, Internett Explorer, Mozilla Firefox, Opera eller Safari 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 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

59 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 Side 59

60 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 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 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 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

61 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 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

62 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; beforeeach ( module ( 'App' )); 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

63 14 }, 15 { 16 "infoheadline" : "Åpningstider", 17 "infotext" : "Åpningstider", 18 }, 19 ] 20 ); 21 //act 22 scope. allinfopages (); 23 httpbackend. flush (); //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

64 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 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

65 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

66 Bilde 4.5: Vellykkede tester. 4.3 Brukertest 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 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

67 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 Er det enkelt å finne frem til pizzameny? Er det enkelt å finne frem åpning- og leveringstider? Er det enkelt å finne kontaktinformasjon? Er det enkelt å finne frem adresse? Er menyen oversiktlig og lesbar? Klarer du å finne frem nyheter på siden, og gir den mer verdi? Er tekststørrelsen på nettsiden leselig? Hva synes dere om designet? F I V G L U Kommentar/Forbedring 2 2 T4: Bilde av hvert pizza. Og ekstra tilbehør T2:Please Write my name under kontakt person. 2 2 T4: Lengre oppe på siden ville det vært fint med en google kart å klikke inn på T1:Bilder av Pizza nyheter. T3:Ville hatt det på forsiden. T4:Legge de frem på en mer interessant måte, litt mer elegant T1:For store bokstaver. T2:The size of nyheter text has to be changed to size of kontakt oss. 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? Tabell 4.1: Resultat av brukertest på front end-siden. 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. Tiltak: Tilbakemeldinger fra brukere blir presentert for oppdragsgiver og besluttninger som tas vil bli implementert i sluttproduktet. Side 67

68 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 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 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

69 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 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

70 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

71 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 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

72 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

73 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

74 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

75 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 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

76 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

77 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

78 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

79 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

80 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

81 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

82 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

83 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

84 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

85 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

86 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

87 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

88 Nyheter Her vil kunder finne nyheter om restauranten. Bilde 5.25 : Nyheter. Side 88

89 Informasjonsside I navigasjonsmenyen vil kunder finne informasjonssider, som for eksempel Åpningstider. Bilde 5.26 : Et eksempel på en informasjonsside. Side 89

90 Bilde 5.27: Skjermbilde av en informasjonsside. Bilde 5.28 : Skjermbilde av en informasjonsside. Side 90

91 Side 91

92 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

93 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: 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

94 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: Trello: Webapp vs CMS: CMS angrep: Enhetstest: mcity/ Weblishtech (Server og domene leverandør) Dropbox Link: Angular: Side 94

95 MVC Framework UML og Arkitektur: Universell utforming: Bootplus: Visual Studio: Webstorm Smidig, scrum metodikk ) Egne dokumentasjoner: r%2c%20osv.docx?dl=0 Informasjonsarkitektur: Side 95

96 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 Versjon Applikasjonen er skrevet i versjon 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 Beskrivelse av rammeverket 14 AngularJS er et rammeverk for å utvikle såkalte "single-page applications". 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 15 komponentene. 14 AngularJS. (2015). Wikipedia. Hentet fra 15 AngularJS. (2015). What are Scopes? Hentet fra Side 96

97 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. 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. 18 AngularJS lar applikasjonen ta i bruk "two-way data-binding". 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: 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. 16 Representational state transfer (2015). Wikipedia. Hentet fra 17 Stack Overflow (2014). What exactly is RESTful programming? Hentet fra 18 AngularJS. (2015). Data Binding. Hentet fra Side 97

98 7.4 Model 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 19 tredje normalform (3NF), og Boyce-Codd-normalform (BCNF). 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 Side 98

99 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 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 20 rammeverket, som gir muligheten til å bruke native data querying i løsningen. 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 = k. 11 }). ToList (); 12 return allusers; 13 } Figur 7.3: LinQ. 20 Language Integrated Query. (2015). Wikipedia. Hentet fra Side 99

100 7.5 View 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

101 Bilde 7.2: Viser hva som kommer når man bruker Angular-koden {{Item.itemName}} og {{Item.itemPrice}} 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 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 21 Angular-utviklede nettsider. 21 Angulartics. (2015). Hentet fra Side 101

102 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 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

103 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 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

104 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> </ 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. }}</ 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 HTML JSON 22 Løsningen benytter JSON for overføring av data mellom server og klient. 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 Side 104

105 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 $scope. , 11 password : $scope. password 12 }; $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 å 23 kommunisere med applikasjonen via HTTPS. 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. 23 Stack Overflow. (2013). How to use HTTPS in AngularJS. Hentet fra Side 105

106 7.8 Våre vurderinger, og utviklingspotensiale 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 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 24 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. Side 106

107 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 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

108 Bilde 7.4: File Manager som viser vårt opplastede prosjekt på servern og dens plassering Driftsoppgaver på serveren. Services: Dersom Error 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 Path W3SVC World Wide Web Publishing Service Tabell 7.1: Nødvendig service som må kjøres for at websiden skal fungere. Provides Web connectivity and administration through the Internet Information Services Manager C:\Windows\system32\svc host.exe -k iissvcs Side 108

109 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

110 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

111 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: 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

112 Bilde 7.8: Påloggingsvindu til Database management. Bilde 7.9: Bildet av pålogget bruker i Database managemenet. Side 112

113 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) 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: FTP Server: FTP Server IP: (Administrator) ftp.pizzaplutselig.no Bilde 7.10: Påloggingsinformasjon for FTP-server. Side 113

114 Bilde 7.11: FTP-konto. Bilde 7.12: FileZilla er et FTP-verktøy brukt til å overføre prosjektet til serveren. Side 114

115 7.9.5 Alias Når oppdraggiver bestemmer seg for å ta i bruk webapplikasjonen vil peke på index.html og vil bli opprettet et alias som peker på admin.html slik oppdragsgiver kan bruke denne 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 A 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 Den gir attributter,som brukes til å definere metadata for gjenstander som benyttes som datakilder. versjon Inneholder klasser og grensesnitt som støtter ASP.NET Model View Controller (MVC) rammeverk for å lage webapplikasjoner. Version Gir klasser og grensesnitt støtte for spørringer via LINQ. Versjon Brukes til å implementere JSON i rammeverket. Versjon Inneholder klasser av HTTP-attributter. Version Inneholder klasser og grensesnitt knyttet til enheter for web-leverandører. Version B L L M R X X X X X X X X X X X X X X X X X X X X X X X D C A S Side 115

116 Bootplus-responsive.css Stilsett for responsivt design på nettside. Bootplus.css Stilsett for design av nettside. X Bootstrap.css Populært og mye brukt stilsett. X Angular-mocks.js Enhetstesting i Angular. X Angular.js JavaScript -lassebibliotek X Bootstrap.js JavaScript-designreferanse X Jquery js Jquery intellisense.js Jquery min.js Jquery min.map Tabell 7.2: Liste over noen av referansene som er brukt i prosjektet. Rask, lite og funksjonsrikt Javascript-bibliotek. Det gjør ting som HTML-dokument traversering og manipulasjon, event håndtering, animasjon, og Ajax enklere. X X X X X Side 116

117 Side 117

118 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 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

119 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 ikkefunksjonelle 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 kravspesifikasjonen. 29. januar 2015 Vi skrev under kontrakten. Jobbet videre med kravspesifikasjonen. Side 119

120 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

121 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 enddelen 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

122 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 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 mai 2015 Feilsøking fortsetter, tidligere feil blir rettet opp. Forbedring av utsende og tekstutskrift (Front end). Dokumentasjonsarbeid fortsetter. Side 122

123 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 webapplikasjonen. 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 sluttresultatet 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 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

124 8.2 Fremdriftsplan Fremdriftsplan for implementering Arbeidsplan og fremdriftsplan Vårt hovedprosjekt har 20 studiepoeng som er 2/3 av arbeidsuken. Dette tilsvarer 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 Planlegging, opplæring, implementering og dokumentering av systemet Enhetstesting, forbedring, dokumentasjon av test og resultat. Utbedringer basert på testresultater Dokumentasjonsarbeid uke og 3 dager 150 Finskriving og dobbelsjekking Ca 2 uke 100 Lage presentasjon av prosjektet Totalt 1600 Tabell 8.1: Tidsestimering. # Oppgave Hvor Frist Status 1 Statusrapport På nettet Levert 2 Prosjektskisse På nettet Levert 3 Forprosjekt På nettet Levert 4 Prosjektrapport I ekspedisjonen kl Levert 5 Presentasjon Auditorium Gjenstår Tabell 8.2: Prosjektets tidsfrister. Side 124

125 Tidsberegning for kravspesifikasjon: Spr-i nt Nr Pr i Krav Spesifisering V T J B Gj. snit t Status 1 1 A En administrator skal kunne logge inn. Administrator skal kunne logge inn med en privat bruker, som har tilgang til styringsfunksjoner i applikasjonen Utført. 1 2 A En administrator skal kunne opprette en ny pizza. 1 3 A En administrator skal kunne se en oversikt over lagrede pizzaer. 1 4 A En administrator skal kunne opprette en ny ingrediens. 1 5 A En administrator skal kunne se en oversikt over lagrede ingredienser. 1 6 A En administrator skal kunne opprette et nytt tilbehør. 1 7 A En administrator skal kunne se en oversikt over lagrede tilbehør. 1 8 A En administrator skal kunne endre lagrede varer og ingredienser. 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 Utført. Administrator skal kunne se en oversikt over alle pizzaer som er lagret i databasen, med visning av alle detaljer Utført. Administrator skal kunne ,3 Utført. velge navn og pris for en ny ingrediens, og lagre den i databasen. Pris lagres for kunne bruke bestillingsfunksjonen (B-krav). Administrator skal kunne se en oversikt over alle ingredienser som er laget i databasen, med visning av alle detaljer ,3 Utført. Administrator skal kunne velge navn og pris for nytt tilbehør (brus ol.), og lagre varen i databasen ,5 Utført. Administrator skal kunne se en oversikt over alle tilbehør som er laget i databasen, med visning av alle detaljer Utført. Administrator skal kunne Utført. gjøre endringer i navn, pris og eventuellt ingredienser for en vare som er lagret i databasen. 1 9 A En administrator skal kunne slette lagrede varer. Administrator skal kunne slette varer fra databasen via applikasjonen Utført. Side 125

126 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 Utført. Sammen med sprint 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. Utført A En administrator skal kunne se en oversikt over lagrede nyheter A En administrator skal kunne opprette en informasjonsside, som gir et nytt valg i navigasjonsmenyen. Administrator skal kunne se en oversikt over alle nyheter som er laget i databasen, med visning av alle detaljer Utført. Sammen med sprint 2 Administrator skal kunne opprette en ny informasjonsside, som vil lagres i databasen. En ny informasjonsside oppretter et nytt navigasjonsmenyvalg Utført A En administrator skal kunne se en oversikt over lagrede informasjonssider A En administrator skal kunne endre og slette en nyhet. Administrator skal kunne se en oversikt over alle informasjonssider som er laget i databasen, med visning av alle detaljer. Administrator skal kunne endre og slette en nyhet, via applikasjonen. Ved å slette en nyhet fra databsen, vil den også bli slettet fra nyhetssiden Utført. Sammen med sprint Utført A En administrator skal kunne endre og slette en informasjonsside. Administrator skal kunne endre og slette en informasjonsside, via applikasjonen. Ved å slette en informasjonsside fra databasen, vil den også bli slettet fra navigasjonsmenyen Utført. Sammen med sprint B En administrator skal kunne ha oversikt over databaselogger. Loggføring av databasehendelser, som administrator skal kunne ha oversikt over Utført, men ikke implementert. Oppdragsgiver ønsket ikke denne funksjonen B En administrator skal kunne ha oversikt over loggføring av feil B Muligheten til å skrive ut innkommende bestillinger automatisk via en liten printer. Loggføring av feilmeldinger Utført, men kun til fil, som administrator tilgjengelig for skal kunne ha oversikt over. utvikler. Oppdragsgiver ønsker bestillingene skrevet ut på på papir ,8 Ikke utført. Side 126

127 2 20 B En kunde skal kunne opprette en bruker B En bruker skal kunne logge inn B En administrator skal kunne opprette, endre og slette brukere B En administrator skal kunne se en oversikt over registrerte brukere B Systemet skal forhindre uautorisert tilgang til kundeinformasjon. Kunde skal kunne opprette en bruker med adresse, telefonnummer, epostadresse og passord Utført, men ikke implementert. Venter på punkt 19. Brukeren skal kunne logge Utført, men ikke inn med e-post og passord. Må logge inn for å få tilgang til bestilling vi applikasjonen. implementert. Venter på punkt 19. Administrator skal kunne opprette nye brukere, endre brukere, og slette brukere fra databasen. Kun en administrator skal ha tilgang til disse funksjonene. Profiler til hver enkelt bruker skal være beskyttet. Rollene skal være forhåndsdefinerte Utført, men ikke implementert. Venter på punkt Utført, men ikke implementert. Venter på punkt ,5 Utført, men ikke implementert. Venter på punkt B En kunde skal kunne bestille pizza. Kunder som er logget inn skal kunne legge inn en bestilling via applikasjonen ,3 Utført, men ikke implementert. Venter på punkt B En kunde skal kunne komponere en egen pizza B En bruker skal kunne se sin egen profil, og gjøre endringer B En bruker skal kunne slette sin egen brukerkonto B En kunde skal ikke ha tilgang til andre brukerkontoer B En bruker skal kunne velge størrelse på pizza B En bruker skal kunne velge glutenfri pizzabunn B En bruker skal også kunne kjøpe tilbehør, som brus og En kunde skal kunne komponere egen pizza ,3 Utført, men ikke implementert. Velger mellom ingredienser og bunn. Venter på punkt 19. Egen kundeprofil ,3 Utført, men ikke implementert. Venter på punkt 19. Kunden skal ikke ha mulighet til å se eller gjøre endringer på andres profiler Utført, men ikke implementert. Venter på punkt Utført, men ikke implementert. Venter på punkt Utført Utført Utført. Side 127

128 dressing B En bruker skal kunne bestille flere varer C En bruker skal kunne velge om pizzaen skal kjøres ut eller ikke C En bruker skal kunne finne ut hvordan han kan ta kontakt med butikken Utført Utført. Telefonnummeret skal være lett tilgjengelig. For eksempel i en footer, i en tittel, eller andre passende steder Utført A Applikasjonen skal inneholde mulighet for å analysere brukeratferd via Google Analytics Utført A Systemet skal være brukervennlig og raskt. Webapplikasjonen skal respondere raskt og ikke oppleves tregt Utført 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 Utført A Nettsiden skal kunne tilpasse seg forskjellige enheter og nettlesere. Det skal være en dynamisk Utført. design og enhet uavhengig A Systemet skal kunne videreutvikles. 41 B Siden skal være søkemotoroptimalisert Systemet skal utvikles etter Utført. standarder og god praksis slik at videreutvikling er mulig. Applikasjonen skal blant Delvis utført. annet ta i bruk meta-tagger C Spørringer til databasen skal ikke ta mer enn 3 sek ved normal bruk. 43 C Systemet skal ha et innbydende og funksjonelt design Spørringer mot databasen skal hente så lite som mulig slik at en spørring ikke tar med enn 3 sekunder Utført. Oppdragsgiver og kunder av systemet synes designet er rent, pent og satt opp slik at det er lett å gjøre oppgaven sin Utført. Totalt antall timer brukt av gruppemedlemmer: Gjennomsnitt tidsbruk for funksjonelle og ikke funksjonelle krav har vært ca 600 timer. Tabell 8.3: Tidsberegning for kravspesifikasjon. Side 128

129 Sprinter Ukenr. # Antall timer Oppsummering Implementert Oppgaver som er overført til andre sprinter Gruppen har utført mange av punkter som var i sprinten og resterende underpunkter ble overført til neste sprint nr 3 og Underpunkter fra forrige sprint er utført samt en god del av punktene i sprint # Gruppen har delvis dekket punktene fra sprint 2 som var knyttet til brukers profil. Noen av kravene jobbes parallelt med i sprint 3 og Design og ikke funksjonelle krav er hovedpunktene som det jobbes med i denne uken Gruppen utfører de resterende punktene fra forrige sprint samt starter testing av produktet Tabell 8.4: Timer overført til neste sprint. 93 % Krav nr 12,13,14 utført parallelt med sprint 3 og % 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 (Utkast av prosjektet og Økt kravspesifikasjon). 89 % Gruppen har implementert mange av kravspesifikasjonene som er i denne fasen. Kun et krav ikke er implementert. 90 % Ønsket kravspesifikasjon i henhold til denne sprinten er utført, noen er implementert og andre implementeres før levering av prosjektet til oppdragsgiver. 100 % Tester knyttet til sprinter og unittesting er utført. Bilde 8.1: Scrumtavle som viser ferdigstilling av forprosjektdokumentet og kravspesifikasjon. Uke 3, 2015 Side 129

130 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

131 Bilde 8.4: Liste over utførte krav i kravspesifikasjonen. Side 131

132 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

133 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 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. En liste over Brukerhistorier er opprettet og levert til oppdragsgiver til testing. 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. Parallelt med sprint 4 Parallelt med sprint 4 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. 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. Side 133

134 - Sikkerhetsteste pålogging Her tester gruppen registrering av verdier, nyheter og relevante informasjon i databasen. Vi klarte å opprette, endre, slette og liste ut pizza og ingrediens, nyheter, infopage og andre relevante funksjoner. Det var små problemer relatert til tegneoppsett. Parallelt med sprint 5 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. Enhetstesting er utført og resultat er lastet opp under enhetstesting i kapittel og 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 21 Levering av rapport til trykking senest 20. mai. Vi dro til oppdragsgiver og fikk med oss siste ønskede endringer og levert et brukertestdokument for at han skal kunne teste applikasjonen. Gruppen jobbet videre med å ferdigstille rapporten. Leverer bachelor oppgaven 26.Mai. Parallelt med sprint 5 Tabell 8.5 : Fremdriftsplan over testing og dokumentasjonslevering. Side 134

135 Bilde 8.7: Scrumtavle for testing. Side 135

136 Bilde 8.8: Liste over utførte Black-box-tester. Bilde 8.9: Liste over utførte Black-box-tester. Side 136