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



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

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

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

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Bachelorprosjekt i informasjonsteknologi, vår 2017

Del IV: Prosessdokumentasjon

Forprosjektrapport. Gruppe Januar 2016

Del VII: Kravspesifikasjon

Bachelorprosjekt 2015

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Forprosjektrapport ElevApp

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

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

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

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

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

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

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Hovedprosjekt Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

FORPROSJEKT RAPPORT PRESENTASJON

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Bachelorprosjekt ved Høgskolen i Oslo og Akershus, våren Gruppe 11. Mohamed el Morabeti, s198748

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Gruppe Forprosjekt. Gruppe 15

Studentdrevet innovasjon

4.5 Kravspesifikasjon

VEDLEGG 1 KRAVSPESIFIKASJON

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

1. Forord 2. Leserveiledning

Dokument 1 - Sammendrag

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

Forprosjekt. Accenture Rune Waage,

Forprosjekt. Høgskolen i Oslo, våren

FORPROSJEKT BACHELOROPPGAVE 2018 KATRINE ALMÅS GINELLE ZAPANTA IGNACIO CHRISTINE LANGELO LIEN FREDRIK NODLAND

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

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

Gruppe 43. Hoved-Prosjekt Forprosjekt

PROSESSDOKUMENTASJON

1 Del I: Presentasjon

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

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

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

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

Produktrapport Gruppe 9

Høgskolen i Oslo og Akershus

HOVEDPROSJEKT HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

Forprosjektrapport gruppe 20

Testrapport Prosjekt nr Det Norske Veritas

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

Kap 11 Planlegging og dokumentasjon s 310

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Kravspesifikasjon. Forord

Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren Skrevet av:

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Forprosjektrapport. Sammendrag. Hovedoppgave våren 2019 Gruppe 3

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Bachelorprosjekt 2017

Forprosjektrapport Gruppe 30

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

4.1. Kravspesifikasjon

11 Planlegging og dokumentasjon

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

Skøyen, Gruppe 11

Forprosjektrapport. Gruppe 31

Forprosjektrapport GRUPPE 4: SHIFTWORKERS

Kravspesifikasjon Gruppe nr ABTF

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02

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

Presentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2. Sammendrag 3. Dagens situasjon 3 ServiceNow 3 Coop 3. Mål og rammebetingelser 3 Mål 3 Teknologier 4

Forprosjekt - Gruppe 12. Hovedprosjekt av

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Moduler Løsning og alternativer...

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm

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

Kravspesifikasjon. Forord

KRAVSPESIFIKASJON FORORD

Dennis Myhre Oblig 4 Wordpress Dokumentering og Eksamensoppgaver

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

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Kravspesifikasjon Hovedprosjekt Arki-ban.no Gruppe 6 Vår 2015 Av Murtada alamir

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

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER]

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

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.

Forprosjektrapport. Høgskolen i Oslo Våren Dr.Klikk. Gruppe 25. Håkon Drange s Lars Hetland s127681

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

Vedlegg Side 83 av 155

Webutvikling Høst 2016

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Forprosjekt. Bacheloroppgave Gruppe 17

Kravspesifikasjon. Forord

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

Transkript:

Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no Definisjon: Pizzaplutselig er en web-applikasjon som skal lagre informasjon om diverse ting som blir tilbydd og mulighet for bestilling. Oppdragsgiver ønsker seg Google Analytics slik at han får en innsikt i hvordan besøkende bruker nettsiden, hvordan de kom til nettstedet og hvordan man kan få besøkende til å komme til komme tilbake. Dessuten ønsker oppdragsgiver å kunne endre i nettsiden, blant annet priser, produkter, legge til nye tilbud, nyheter og mer. I løsningen vil det bli implementert registrering av brukere og bestillings-muligheter. Gruppemedlemmer: Torstein Frogner Bernt Kristoffer Helland Vahid Khairkhah Jonas Myren Mo Gruppenummer: 23 Oppdragsgiver: Kontaktperson: Intern veileder: Pizza Plutselig, Ullevålsveien 14, 0171 Oslo Mansour Jam 954 79 171 mansor.jam@live.no Høgskolelektor Ismail Hassan Ismail.Hassan@hioa.no

Sammendrag Hos Web Archive kan man finne nettsiden til Pizza Plutselig helt tilbake til 30. desember 2002. 1 På disse tolv årene har ikke nettsiden forandret seg i det hele tatt. Nettsiden er laget som en vennetjeneste til oppdragsgiver, og oppdragsgiver har liten kunnskap om hvordan han kan oppdatere siden. Oppdragsgiver ønsker ny nettside med en adminløsning som gjør det mulig for han å endre meny, forside, bilder og andre relevante ting. Dagens situasjon 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 tidkrevende. Oppdragsgiver ønsker å kunne effektivisere endringer i nettsiden og samtidig ikke være en byrde for den tidligere utvikleren. Etter første møte med oppdragsgiver fikk vi vite at oppdragsgiver primært ønsker en løsning der han kan endre mye av informasjonen, blant annet priser, meny og nyheter. I tillegg til denne funksjonaliteten, ønsker oppdragsgiver å kunne overvåke hvor mye trafikk som går gjennom siden, og gjøre beslutninger relatert til siden basert på en trafikk-analyse. Oppdragsgiver har vært i kontakt med Google og etter samtalen de har hatt fikk vår gruppe en mail om å bruke Google Analytics og Wordpress. Wordpress er en av de mest brukte CMS løsninger blant organisasjoner, private foretak, bloggere og andre og har en rekke gode fordeler blant annet ferdige løsninger, plug-ins, funksjonaliteter som kan tas i bruk og som også er gratis, men det finnes ulemper som vi syns det var greit å advare oppdragsgiveren på før han bestemmer teknologien. Blant de ulempene finner vi patching og oppgraderinger som kommer for Wordpress for å ivareta sikkerheten. Dersom oppdragsgiver ikke får med seg disse, eller ikke veit hvordan de skal testes før implementering vil deres nettside og eventuelle informasjon være veldig sårbare. Et annet aspekt ved saken er hackere som har langt større kjennskap til en slik CMS-løsning sammenlignet med andre alternativer. Det finnes automatiserte hacker-verktøy som angriper Wordpress sine nettsider. Sist men ikke minst er kompatibiliteten mellom plug-ins, ikke alle kan implementeres og fungere sammen. Sikkerhet er et viktig tema i dagens samfunn og er et nasjonsansvar. Vi som utviklere har et ansvar å levere en løsning med høyere sikkerhetsgrad for å minke eventuelle trusler. Derfor har vi diskutert for oss i mellom, og kom frem til at vi skulle bruke en MVC løsning hvor viktig informasjon ligger langt inne i systemet og vanskeligere å få tak i, blant annet profil informasjon, transaksjoner, bestillinger etc. Vi vil sette opp en liste med alle funksjonalitetene og prioritere disse for å kunne gi oppdragsgiver et sikkert og komfortabelt system i forhold til tiden vi har til rådighet. Under prosjektet vil vi ha kontinuerlige møter med både vår veileder Ismail Hassan og Oppdragsgiver Mansour Jam, slik vi kan presentere våre ideer og få tilbakemelding på fremgangen, løsningen, 1 http://web.archive.org/web/19980315000000*/http://www.pizzaplutselig.no/

funksjonalitetene eller utfordringer som dukker opp. I slike møter kan vi for gripe inn i endringer som kommer basert på brukerhistorier og få dem i vår design og implementerings prosesser, slik løsningen kan møte oppdragsgiveres forventninger og være brukervennlig. Vi håper å kunne engasjere oppdragsgiver med å komme med flere kravspesifikasjoner som han kanskje ikke har tenkt på. Vi har allerede etablert og tatt i bruk en chattekanal gjennom Facebook og cloudlagring i Dropbox. Dessuten bruker vi prosjekt- og oppgaveorganiseringsverktøyet Trello (scrum-brett) med konkrete punkter og mål med angitte frister. Vi vil bruke versjonskontroll med enten Github, Bitbucket eller Team Foundation. Vi har et designutkast som vi skal presentere for oppdragsgiver i vårt neste møte for å se om det samsvarer med det kunden forestiller seg.

Mål, utfordringer og løsninger # Mål Utfordring Løsning(er) 1 Muligheter for endringer i databasen, samt endring av nettside-info. Se på muligheten for å kunne endre layout. 2 Sikker lagring av bruker/produktinformasjon. 3 Designe en høyest mulig normalisert, og kompleks nok database. Vi vet ikke hvordan vi skal få opp nettsiden slik at en administrator kan endre layout. Følge regler og retningslinjer gitt fra datatilsynet. Utvikle en så kompleks og dynamisk database at dette ikke hindrer oppdragsgivers ønske om funksjonalitet. Databasen skal ha minst mulig duplikater, og ha minimum tredje normalform. -Se på løsninger ved hjelp av javascript og css. -Bruke påloggings-system for bruker. -Hashe passord. -Blokkering av bruker etter antall feilinnlogginger og gjenoppretting vie epost. -Krav om sterke passord eller passord med små, store bokstaver og tall -Bruk av LINQ database. -Planlegge og designe databasen med en domenemodell osv. -Følge alle kravene for første, andre, og tredje normalform. 4 Utskrift av bestillinger til en ekstern device. 5 Muligheter for å analysere datatrafikk (Google Analytics) 6 Hosting av webserver og database Oppdragsgiver ønsker utskrift av bestillinger fortløpende. Gjerne på en liten «labelprinter» eller lignende løsning som de bruker pr i dag fra JustEat. En annen mulighet er å få bestillingen tilsendt til mailkonto med automatisk print funksjon. At vårt produkt er kompatibelt med Google Analytics. Dersom det ikke lar seg gjøre å flytte alt på nåværende webhotell som oppdragsgiver bruker, vil utfordringen bli kostnader relatert til å implementere løsningen. Om nåværende server er god nok for å lese vårt.net prosjekt. -Sette opp en automatisk utskrift av bestillinger som kommer inn i Oppdragsgivers bestilling mailboks. -Bruke en miniprinter. -Legge til javascript i alle sidene -Leie webserver og database-lagring på oppdragsgivers bekostning. -Finne et gratis webhotell løsning som kan gi brukeren en gitt størrelse både til lagring og trafikk.

Generelt om målene: Vi har i første omgang satt opp en del punkter som vi syns det var viktig å få med. Men det vil muligens komme nye mål eller krysset bort noe av de ovennevnte mål. De største utfordringene kan bli videresending av bestillinger til et apparat som oppdragsgiver kan benytte seg i butikken, lage en nettside hvor det er enkelt å endre design og omplasseres. Basert på gruppemedlemmenes bakgrunnskunnskap er vi ikke helt sikre på om enkelte deler av prosjektet lar seg gjøre med gratisverktøy eller om man trenger lisensbelagte rammeverk og programvare for å iverksette og muliggjøre dette. De ovennevnte punkter er de mest utfordrende punkter i prosjektet. Vi ønsker i tillegg å ha følgende trivielle mål: Utvikle et brukervennlig og ryddig design hvor vi tar hensyn til Universell utforming. Responsivt design. Administrator bruker som kan endre og legge til nye brukere. Tilfredsstille alle (brukerhistorier) som blir meldt til oss av oppdragsgiver og ansatte. Rammebetingelser Programmeringsspråk: C# HTML5 CSS3 Verktøy: MySQL / LINQ Javascript JQuery Angular / Polymer Microsoft Visual Studio 2013 Netbeans Trello Dia Microsoft Azure

Utviklingsmetode For at vi skal kunne være mest mulig effektive har vi besluttet å benytte en smidig metode, som for eksempel scrum, til dette prosjektet. Vi vil bruke Trello som en scrum-tavle. Her vil vi sette opp hovedpunkter, og underpunkter for prosjektet. Disse vil bli fordelt mellom medlemmene av gruppen. Ettersom vi har gruppemedlemmer som har heltidsjobb ved siden av studiene vil det bli en utfordring å koordinere arbeidet, derfor vil Trello-tavlen være til stor hjelp. Vi planlegger å holde gruppemøter med alle tilstede minst en gang i uken, så lenge dette lar seg gjøre. Vi skal også ha møte med veileder en gang i uken. Før vi setter i gang med selve utviklingsprosessen vil vi sette opp en kravspesifikasjon, som inneholder blant annet funksjonelle og ikke-funksjonelle krav, utfra hva vi ser på som nødvendig og gjennomførbart. Vi kommer til å sette sammen en prioritert liste med brukerhistorier, som vi vil ha som utgangspunkt. Så må vi finne en metode for å anslå hvor lang tid det vil ta og utvikle komponentene. Med for eksempel "planning poker". Vi vil definere sprinter ut i fra denne kravspesifikasjonen, og fordele disse etter hvor hver og en av oss har sine erfaringer og kompetanse. Nye punkter kan også komme til å bli definert underveis i prosjektet. Vi har kommet fram til at analyse vil bli svært viktig, ettersom det er naturlig at vi kommer til å måtte forsvare valgene vi har tatt. Vi kommer derfor til å gjøre gode vurderinger rundt alle valgene vi tar, slik at vi på best mulig måte skal kunne begrunne disse. Virkninger for oppdragsgiver For oppdragsgiver vil vår løsning være intuitiv og enkel å redigere for ytterligere bruk. Fra kundens perspektiv vil det være oversiktlig å bestille matretter, samt at restauranten vil få beskjed om at en bestilling har tatt plass så fort kunden har skrevet inn all nødvendig informasjon. Kunden skal også kunne lage en bruker og ta i bruk en innloggingsfunksjon som lagrer tidligere bestillinger slik at brukeren ikke må skrive inn all informasjon hver gang man bestiller mat. Det skal være mulighet for oppdragsgiver å manipulere oppsettet av forsiden, uten at han eller hun må endre noe ved hjelp av programmering. Dette vil si at menyer og lignende kan plasseres fritt frem der hvor oppdragsgiver ønsker. Dette vil gi en simpel plattform som kan være svært brukervennlig. Konklusjon Etter vårt første møte med intern veileder fikk vi avklart noen spørsmål vi hadde vedrørende størrelsen på oppgaven. Vi føler nå at vi har et grunnlag å jobbe utfra.