Forprosjektrapport gruppe 3

Transkript

1 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.

2 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.

3 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

4 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.

5 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

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

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

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