Forprosjektrapport gruppe 3



Like dokumenter
NILS Mobil. Prosjektdokumentasjon S 1

1 Forord. Kravspesifikasjon

Innledende Analyse Del 1.2

Bachelorprosjekt i informasjonsteknologi, vår 2017

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjekt gruppe 13

Huldt & Lillevik Ansattportal. - en tilleggsmodul til Huldt & Lillevik Lønn. Teknisk beskrivelse

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

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

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

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

Forprosjekt. Accenture Rune Waage,

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Gruppe 30

Studentdrevet innovasjon

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

S y s t e m d o k u m e n t a s j o n

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

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

FORPROSJEKT. Gruppemedlemmer: Raja Zulqurnine Ali Muddasar Hussain (Gruppeleder/Prosjektleder) Zain-Ul-Mubin Mushtaq Christopher Llanes Reyes

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Bachelorprosjekt 2015

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

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

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

KRAVSPESIFIKASJON FOR SOSIORAMA

4.5 Kravspesifikasjon

Gruppe 43. Hoved-Prosjekt Forprosjekt

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

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

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan

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

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

ISY Park Go og nye ISY Park. Endre Lykke, NoIS

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Public 2013 Aker Solutions Page 1 of 5

Vanlige spørsmål. GallupPanelet. TNS Panel-app. TNS Juni 2015 v.1.3

Gruppe Forprosjekt. Gruppe 15

Dokument 1 - Sammendrag

Høgskolen i Oslo og Akershus

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

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

Forprosjektrapport. Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe

VEDLEGG 1 KRAVSPESIFIKASJON

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

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

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

PROSESSDOKUMENTASJON

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

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Kravspesifikasjon. Forord

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

Presentasjon. Kristian Hewlett- Packard

Forprosjektrapport ElevApp

Testrapport Prosjekt nr Det Norske Veritas

Aktive hyller (Ref # )

4.1. Kravspesifikasjon

Kravspesifikasjon MetaView

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

K-Nett. Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon. av Erik Mathiessen

Del VII: Kravspesifikasjon

Hovedprosjekt våren 2007

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

Del IV: Prosessdokumentasjon

1. Forord 2. Leserveiledning

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

Innledende Analyse Del 1: Prosjektbeskrivelse (versjon 2)

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

HOVEDPROSJEKT HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1. Forord Innholdsfortegnelse innledning Funksjonelle egenskaper og krav Spesifikke krav av delsystemer...

Forprosjektrapport for bacheloroppgave i data og informasjonsteknologi

Forprosjektrapport. Gruppe Januar 2016

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK

Forprosjektrapport. Sammendrag. Hovedoppgave våren 2019 Gruppe 3

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

Forprosjektrapport MetaView

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

SOFTWARE REQUIREMENT & DESIGN DOCUMENT. Home Automation System. Nickolas Helgeland, Jon Erik Nordskog og Kristian Sande Sjølyst

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

WebSmart. Trond E. Nilsen Select AS

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren Testrapport

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

Teknisk Presentasjon Kun for autoriserte partnere.

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

Policy vedrørende informasjonskapsler og annen tilsvarende teknologi

Kravspesifikasjon

1. Intro om SharePoint 2013

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

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

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato:

Bilag 3: Beskrivelse av det som skal driftes

Team2 Requirements & Design Document Værsystem

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Forord

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Internett

Kommunikasjonsbærere Mobil/GPRS. Toveiskommunikasjon EBL temadager Gardermoen mai 2008 Harald Salhusvik Jenssen gsm.

Forprosjekt for Accentures Overvåkningssystem

Transkript:

Forprosjektrapport gruppe 3 Presentasjon: Tittel: NILS Mobil Oppgave: Utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning til logistikk og prosess-systemet NILS Periode: 5. januar 2011 til 31. mai 2011 Prosjektgruppe: 3 Prosjektmedlemmer: Rune Sandersen, Khai Quang Nguyen og Hafsteinn Thor Ingason Veileder: Geir Skjevling Oppdragsgiver: Goodtech Kontaktpersoner: Øystein Myhre, Harald Pedersen Sammendrag: NILS-Mobil er et hovedprosjekt for IT studenter ved Høsgskolen i Oslo. Goodtech har sammen med Nasjonalmuseet utviklet logistikksystemet «Nasjonalmuseets Interne Logistikk System», for å holde kontroll med hvor gjenstander befinner seg, hvilken prosess de til enhver tid er i og hvilke hendelser de har vært med på. Oppgaven vår er å utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Vi gjør dette ved å utvikle en interaktiv webapplikasjon optimalisert for nettlesere i smart-telefoner. Dagens Situasjon: Goodtech har fra før laget en løsning for nasjonalmuseet, NILS(Nasjonalmuseets Interne Logistikk System) for å holde kontroll med hvor gjenstander er, hvilken prosess de er i, og hvilke hendelser de har vært med på. Hovedhensikten med NILS er at det skal holde rede på hvor gjenstander er til envær tid, dette gir Nasjonalmuseet oversikt over logistikkflyt og lokasjon for sine gjenstander. Systemet er hendelsesbasert og bygd opp rundt problemstillinger som «Hva har skjedd med hvilke gjenstander, når, og hvem gjorde det». NILS ble oprinnelig brukt for store flyttinger og er skreddersydd for masse-registrering i denne typen prosjekter. I senere tid har det dukket opp nye behov for kontroll over mindre flyttinger, og det er et ønske om et system som gjør dette arbeidet lettere, ved bruken av mobile enheter istedenfor PCer. Oppdragsgiver: Kunden er Nasjonalmuseet. Goodtech er vår oppdragsgiver og vil vedlikeholde og videreutvikle systemet etter levering. Om Goodtech Goodtech ASA er et norsk teknologi- og ingeniørkonsern som er notert på Oslo Børs. Selskapet leverer løsninger til industri og offentlig forvaltning, miljøprosjekter innenfor vann, avløp og energigjenvinning, samt tilhørende produkter og produktteknologier. Selskapet er representert med kontorer i flere geografiske regioner i Norden og Tyskland. Konsernet representerer flere internasjonale produsenter og deres produkter i det nordiske markedet. Goodtech har over 1000 ansatte hvor hovedtyngden av de ansatte er ingeniører og tekniske spesialister som gir konsernet en betydelig gjennomføringsevne i sine prosjekter.

Om nasjonalmuseet Nasjonalmuseet samler og bevarer, stiller ut og formidler landets mest omfattende samlinger av kunst, arkitektur og design. Museet viser faste utstillinger med verk fra egen samling og skiftende utstillinger med innlånte og egne verk. Museets visningssteder i Oslo er Nasjonalgalleriet, Museet for samtidskunst, Nasjonalmuseet Arkitektur og Kunstindustrimuseet. Utstillingsprogrammet omfatter også vandreutstillinger i inn- og utland. Eksisterende Løsning: NILS-kjernen er den grunnleggende dataprogramvaren og er baser på en industrialisert standard for logistikk og prosesstyring, kjernen består av en database, som lagrer hva som skjer med hvilke gjenstander, et serverprogram med et Java-API og en klient som kjører lokalt på brukerens maskin. NILS klienten er et program som kjører på brukerens datamaskin og brukes til å identifisere gjenstander, og å registrere hva som skjer med dem. Hendelser som NILS kan håndtere er inventering og plassering. Klienten kobler seg opp til NILS-Tjeneren gjennom en portal. Tjeneren er der logikken relatert til databseendringer ligger. Løsningen benytter seg av strekkoder, der alle relevante gjenstander har en strekkode forbundet med seg. Ved å registrere endring av lokasjon til gjenstander med strekkoder får man oversikt over hvor gjenstander er nå, og hvor de har vært tidligere. Teknisk informasjon: Klienten og tjeneren er skrevet i Java. Det er en 3 lags løsning bygd opp av Model View og Controller. Rammeverket brukt i NILS er Spring MVC. Spring MVC kan brukes i alle Java applikasjoner, og det er også extensions for bygging av webapplikasjoner med Java EE platformen, gruppen kommer til å utvikle webapplikasjonens funksjonalitet med bruk av Spring MVC, og på denne måten få erfaring med et mye brukt rammeverk og samtidig utvikle noe som lett kan brukes med det eksisterende NILS systemet. Illustrasjon av typisk MVC arkitektur.

Arkitektur skisse av NILS(denne er veldig simpel, jeg kunne ha laget noe tilsvarende jsp arkitekturskissen lenger nede men vet ikke hvor detaljert det bør være, kunne skrevet mer om spring mvc også) Mål og rammebetingelser Mål: Målet med oppgaven er å utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Løsningen vi har valgt for oppgaven har vi kommet frem til gjennom analysering av behov, dialog med brukere, beskrivelse av bruks-eksempler og kartlegging og valg av teknologisk løsning maskinvare og arkitektur. Rammebetingelser: Applikasjonen skal lages i Java Vi kommer til å utvikle webapplikasjonen i Java, ved bruk av JavaServer Pages samt teknologier med åpen kildekode NILS har et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan man kommunisere over HTTP med kjernesystemet. NILS systemet har en tjener som snakker med databasen, vi kommer til å benytte oss av samme tjener. Strekkoder benyttes som informasjonsbærer, dette betyr at informasjonen fra strekkoden bestemmer hvilken lokasjon man er på, og hvilken gjenstand det dreier seg om. Alle gjenstander brukt i NILS har sin egen strekkode, og alle lokasjoner er strekkodemerket. Vi vil benytte oss av åpne standarder og åpen kildekode i størst mulig grad Goodtech s infrastruktur for systemutvikling vil benyttes. Sentrale verktøy er: Scrum, Maven, Subversion, Hudson og Artifactory

Metodikk: Under utvikling av systemet bruker vi Scrum, en smidig prosjektmetodikk. Smidig er en fellesbetegnelse på prosjektarbeidsmetoder med fokus på kundenes skiftende behov, og med krav om fortløpende produksjon av løsninger som fungerer. Scrum metoden går kort ut på at man begynner med en kort liste av ferdige krav og tilpasser denne listen med behov underveis. Grunnlaget for utvikling av IT-funksjoner med scrum er user-stories, de som skal bruke det nye systemet beskriver sine behov, og disse ender opp i konkrete utviklingsoppgaver. Løsninger /alternativer: Vi kom tidlig i prosjektet frem til to alternativer til løsning av oppgaven, disse var en Web- Applikasjon eller en Android applikasjon. Webapplikasjon med JSP: Web-applikasjon utviklet med JSP(Java Server Pages): JSP brukes for å utvikle interaktive web sider med Java og er en alternativ løsning for NILS-Mobil. JSP tar bruk av MVC arkitekturen(model View Controller). Dette fungerer veldig overfladisk ved at applikasjonen er kontrollert av en sentral controller. Controlleren delegerer requests fra nettleseren til passende request handler. Brukeren vil benytte seg av webappen for bruk av NILS gjennom nettleseren på mobilen.

Klient på Android telefoner: Den lokale applikasjonen utvikles i Java og vil snakke med en webservice som gjør arbeidet med å snakke med NILS sin eksisterende server-applikasjon. Denne løsningen er helt avhengig av at koblingen mellom Android applikasjonen og Webserveren fungerer bra. Viktige punkter for vår løsning er at den i tilegg til å tilfredsstille de funksjonelle kravene må være tilgjengelig, ha intuitivt grensesnitt, og være responsiv. Tilgjengelighet: En lokal android applikasjon vil ikke være mer tilgjengelig en en ren webapplikasjon da android appen fortsatt må koble seg til en webservice. Lokale klienter har flere begrensninger en web-applikasjoner fordi man må ha den fysiske enheten applikasjonen er installert på for å benytte seg av den lokale klienten. Web applikasjoner er brukbare der man har en nettleser og vinner derfor når det kommer til tilgjengelighet, spesielt med tanke på html5 som også gir mulighet for offline bruk. Grensesnitt: Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web-Applikasjoner, men hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. Så selv om grensesnittet er viktig er det ikke faktoren som bestemmer om vi går for en Web- Applikasjon eller Android applikasjon Brukervennelighet, gjør applikasjonen det som trengs(kravene): Funksjonaliteten til en Web-Applikasjon vil være begrenset med tanke på at det ikke er mulig å manipulere enheten som blir brukt, eller oprette et grensesnitt mot strekkodeleseren, men grunnfunksjonaliteten er fortsatt tilstede da alle strekkodelesere er konfigurert til å gi ut strekkoden i det området som er merket på skjermen, på samme måte som tastetrykk fra et keyboard. En Android applikasjon ville vært mer brukervennelig med tanke på dette, men innebærer også at man er låst til Android og de strekkodeleserene interfacet er satt opp for, mens en web applikasjon vil fungere så lenge strekkoden blir lest, eller skrevet, inn i en tekstboks. Det er muligheter for å automatisere merking av tekstbokser og automatasjon ved hjelp av feks JavaScript i en web-applikasjon, så selv om Android vinner på brukervennelighet mener vi at en

webapplikasjon er det beste alternativet med tanke på platform/hardware uavhengighet Responsitivitet: De fleste lokale applikasjoner er mer responsive en webapplikasjoner(avhengig av hardware på enheten), men med dagens utbredelse av relativt høy båndbredde tror vi ikke responsiviteten til web applikasjonen kommer til å være et problem. Android applikasjonen ville likevel vært avhengig av en webservice på dette området så hastigheten på nettverket ville fortsatt hatt mye å si. I tilegg til argumentene ovenfor satt vi opp en liste med punkter for eller imot de to løsningene for å komme frem til en beslutning. Poeng rangeres 0-100 Krav/egenskap Webapplikasjon Poeng Android Poeng Aksessering og tilgjengelighet Installasjon og oppdatering av software Arbeidsfordeling Web applikasjoner kan bli aksessert fra alle enheter som har tilgang til internett. Hvis man har tilgang til en PC, telefon eller tablet vil man kunne bruke applikasjonen Oppdatering av web-applikasjonen skjer uten at brukere må installere eller laste ned noe. Webapplikasjonen kan oppdateres uten å distribuere eller installere software på klienter. Arbeid blir tatt hånd om av webapplikasjonen(ute nom javascript som kjører lokalt) 90 Platform og versjonsavhengighet. Nasjonalmuseet må forholde seg til android telefoner for brukere av NILS- Mobil. Hvis et interface skrives mot en strekkodeler blir man bundet til den hardwaren, man er også bundet til android mobiler fremover. 50 Oppdatering av software innebærer at brukere må laste ned klienten på nytt istedenfor at web applikasjonen forandrer seg(distribusjon). Applikasjoner må bli installert på hver enhet 0 En webservice vil ta seg av mesteparten av arbeidet, android applikasjonen må ta seg av http -90-50 0

Bruk av eksisterende API Ved utvikling av webapplikasjon kan vi gjennbruke NILS API'et Brukervennelighet Ikke mulig å manipulere enheten som blir brukt, eller oprette et grensesnitt mot strekkodeleseren, men grunnfunksjonalite ten er fortsatt tilstede Grensesnitt Responsitivitet Sikkerhet Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web- Applikasjoner, men hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. GUI på android vil være helt tilpasset mobilen, dette kan muligens gi en litt bedre opplevelse Helt avhengig av nettverkshastighet, det er mulig at en webapplikasjon vil føles litt tregere en en ren android applikasjon Kryptering eller sikring på en annen måte må 0 Ved utvikling av android applikasjon kan vi fortsatt bruke NILS API'et for webservicen -60 Mer brukervennelig med tanke på dette, en android applikasjon vil ha full kontroll over oppførselen til mobilen og man kan derfor kontrollere enheten og opprette grensesnitt mot strekkodelesere 0 60-20 20-10 De fleste lokale applikasjoner er mer responsive en webapplikasjoner(av hengig av hardware på enheten), men avhengigheten av å koble til en webservice gjør at dette ikke betyr mye, brukeren er fortsatt avhengig av nettverkshastigheten 0 0 10

skje i begge tilfeller da informasjon må sendes over nett Sum 50-50