Bookingsystem for Making Waves
Bookingsystem for Making Waves Gruppe 31 Mathias Faanes Olsen s188066 Snorri Hansson Engen s188094 Hovedprosjekt våren 2015 26.05.2015 1 PROSJEKT NR. Gruppe 31 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Telefon: 22 45 32 00 Telefaks: 22 45 32 05 BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Bookingsystem for Making Waves – En mobilapplikasjon som kommuniserer med eksterne sensorer plassert i møterom 26. mai 2015 ANTALL SIDER / BILAG 71 PROSJEKTDELTAKERE INTERN VEILEDER Mathias Faanes Olsen – s188066 Snorri Hansson Engen – s188094 Torunn Gjester OPPDRAGSGIVER KONTAKTPERSON Making Waves Kristoffer Sundmyhr SAMMENDRAG Utvikle en brukervennlig Android mobilapplikasjon som kommuniserer med eksterne sensorer for booking av møterom i Office 365. Applikasjonen skal vise hvilke møterom det ikke er aktivitet i for så å la brukeren booke et ledig rom med sin Office 365 konto. 3 STIKKORD Hardware Office 365 Android mobilapplikasjon 2 Forord Dette er en rapport som beskriver hvordan planleggingen og utviklingsprosessen foregikk under prosjektperioden for Making Waves. Prosjektet er et avsluttende hovedprosjekt i bachelorstudium i Dataingeniør ved Høgskolen i Oslo og Akershus, våren 2015. Vår oppdragsgiver, Making Waves, ønsker en mobilapplikasjon som skal forhindre møteromskonflikter ved å ha en nåtidsoversikt over hvilke rom som ikke har aktivitet. Denne rapporten er delt opp i tre hoveddeler: Valg av hardware og implementasjon av sensorsystem o Forteller hvordan hardware-siden av systemet henger sammen. Kommunikasjon med eksterne systemer o Forteller om hvordan systemet kommuniserer med Office 365 Android mobilapplikasjon o Forteller om hvordan de overnevnte punktene kommer sammen og blir presentert i en mobilapplikasjon Vi vil takke vår veileder Torunn Gjester ved HiOA for god oppfølging under prosjektperioden. Vi vil også rette en takk til Kristoffer Sundmyhr som har vært vår kontaktperson hos Making Waves. Dokumentasjonen er også tilgjengelig på: http://www.snorri.no/bachelor2015 3 Innholdsfortegnelse Forord .............................................................................................................................................. 3 Innledning ........................................................................................................................................... 7 Making Room ................................................................................................................................ 7 Oppdragsgiver .............................................................................................................................. 7 Bakgrunn ........................................................................................................................................ 7 Mål..................................................................................................................................................... 8 Effektmål.................................................................................................................................... 8 Resultatmål ............................................................................................................................... 8 Læringsmål ............................................................................................................................... 8 Kravspesifikasjon ........................................................................................................................ 9 Hovedelementer fra kravspesifikasjonen:.................................................................... 9 Milepælsplan .............................................................................................................................. 10 Teknisk tegning av systemet ............................................................................................... 11 Valg av Hardware og Implementasjon av Sensorsystem .............................................. 12 Mikrokontrollere ................................................................................................................. 13 Vurdering av kontrollere .................................................................................................. 14 Hardware-implementasjon .................................................................................................. 20 Gateway ................................................................................................................................... 20 Raspberry Pi A+ ................................................................................................................... 21 Moteino-Gateway ................................................................................................................ 23 Sensor ...................................................................................................................................... 25 Moteino-Sensor .................................................................................................................... 25 Database.................................................................................................................................. 26 Kommunikasjon med Eksterne Systemer ........................................................................... 27 Microsoft Office 365 ........................................................................................................... 28 Outlook .................................................................................................................................... 29 Microsoft Azure og Azure Active Directory............................................................... 29 Microsoft Office 365 Exchange Online ........................................................................ 31 Android Mobilapplikasjon ......................................................................................................... 32 Use Case Modell ........................................................................................................................ 33 Detaljert beskrivelse av Use-Caset «Book rom» .......................................................... 34 Spørreundersøkelse ................................................................................................................ 35 Designvalg og utforming ....................................................................................................... 38 Skjermbilde #1 – Login ..................................................................................................... 38 4 Skjermbilde #2 – Azure Active Directory Login ...................................................... 38 Skjermbilde #3 - Booking................................................................................................. 38 Skjermbilde #4 – Pågående møte ................................................................................. 39 Generelt ................................................................................................................................... 39 Android ........................................................................................................................................ 41 AndroidManifest.xml .............................................................................................................. 41 Gradle............................................................................................................................................ 41 Constants.java............................................................................................................................ 42 Office 365 SDK for Android .................................................................................................. 42 LoginActivity .............................................................................................................................. 43 MainActivity.java ...................................................................................................................... 44 LiveMeetingActivity ................................................................................................................ 45 Konklusjon .................................................................................................................................. 46 Måloppnåelse ........................................................................................................................ 46 Konklusjon av produkt ...................................................................................................... 46 Prosessrapport .............................................................................................................................. 47 Sammendrag .............................................................................................................................. 48 Innledning ................................................................................................................................... 49 Om gruppen ................................................................................................................................ 49 Om bedriften .............................................................................................................................. 49 Planlegging og Metode ........................................................................................................... 50 Verktøy ......................................................................................................................................... 51 Utfordringer ............................................................................................................................... 51 Utvikling av Applikasjonen................................................................................................... 51 Samarbeid ................................................................................................................................... 51 Veiledning ................................................................................................................................... 52 Konklusjon .................................................................................................................................. 52 Kilder og lenker ............................................................................................................................. 53 Internett ....................................................................................................................................... 53 Vedlegg .............................................................................................................................................. 54 Vedlegg 1 ..................................................................................................................................... 54 Kravspesifikasjon ................................................................................................................ 54 Vedlegg 2 ..................................................................................................................................... 56 Office 365 hovedportal ...................................................................................................... 56 Vedlegg 3 ..................................................................................................................................... 57 Windows Azure Portal ...................................................................................................... 57 5 Vedlegg 4 ..................................................................................................................................... 58 Figur av Administrasjonsportalen til Exchange ...................................................... 58 Vedlegg 5 ..................................................................................................................................... 58 Oversikt over rommene i Administrasjonsportalen til Exchange .................... 59 Vedlegg 6 ..................................................................................................................................... 59 Hvordan opprette rom i Exchange ............................................................................... 60 Spørreundersøkelsen......................................................................................................... 61 Vedlegg 8 ..................................................................................................................................... 62 Svar på spørreundersøkelsen ......................................................................................... 63 Vedlegg 9 ..................................................................................................................................... 63 Tidlig skisse av applikasjonens hendelsesforløp .................................................... 67 Detaljert beskrivelse av Use-Case ................................................................................. 68 Vedlegg 11................................................................................................................................... 70 MIT-Lisensen......................................................................................................................... 70 Vedlegg 12................................................................................................................................... 71 3D-Modelleringer av deksel til romsensor ................................................................ 71 6 Innledning Making Room Making Room er et system som viser hvilke møterom det ikke er aktivitet i ved hjelp av bevegelsessensorer, uavhengig om rommet står oppført som opptatt eller ikke. Oppdragsgiver Vår oppdragsgiver, Making Waves, er et selskap som spesialiserer seg på digital tjenesteutvikling og innovasjon. Making Waves har avdelinger for rådgivning, design, teknologi, innholdsproduksjon og drift. De er en digital innovasjonspartner for mange av Nordens største merkevarer og offentlige virksomheter som f.eks. Regjeringen, NorgesGruppen, NSB, Norrønna og Sparebank 1 Forsikring. Selskapet har spesielt mange utmerkelser når det gjelder gode webløsninger og nettsider. Figur 1 Logo Making Waves Bakgrunn Under et møte i midten av desember 2014 presenterte to representanter fra Making Waves sin problemstilling for oss. De ansatte hadde utfordringer med å finne et ledig møterom når det var behov for å ha et møte på kort varsel. I dagens system logger de ansatte seg inn i Outlook for å få oversikt over hvilke møterom som er ledige til hvilket tidspunkt. Problemet oppstår når et avtalt møte blir avlyst. Ettersom møtene bookes i Outlook må de også kanselleres i Outlook, noe som sjeldent blir gjort. Møterom som er ledige står oppført som opptatt og det blir vanskelig for de ansatte å finne et ledig møterom på en rask og enkel måte. I møtet med Making Waves ble det drøftet mulige løsninger på dette problemet. Vi kom frem til at det er nødvendig å utvikle en løsning som gjør det mulig å se om det er aktivitet på de forskjellige rommene uavhengig av om de står oppført som opptatt eller ikke. I dagens samfunn hvor man alltid har telefonen innenfor rekkevidde vil det være naturlig at løsningen utvikles for mobile-enheter. For å avgjøre hvilke rom det er aktivitet i ser vi for oss at en form for sensor blir installert i rommene og disse kommuniserer med en mobilapplikasjon. 7 Mål Effektmål 1. Effektivisere møtebookingprosessen 2. Mer effektiv bruk av møterom. Resultatmål Oppdragsgiver ønsker en mobilapplikasjon hvor det skal være mulig å booke et møterom på en enkel og tidseffektiv måte. Mobilapplikasjonen skal kommunisere med trådløse sensorer plassert i møterommene. Dette vil gi en nåtidsoversikt over hvilke møterom det ikke er aktivitet i slik at man enkelt kan finne et ledig møterom uten å måtte gå rundt på huset og lete etter et. Det er derfor et resultatmål at vi skal utforske forskjellige sensorløsninger og implementere den vi finner best tilpasset vårt prosjekt. Ettersom Making Waves har et møtebookingssystem fra før, er et annet resultatmål at det skal kommunisere med dette. Mobilapplikasjonen blir ikke en erstatning, men heller et supplement til allerede eksisterende systemer. Læringsmål Vi har satt oss flere læringsmål vi ønsker å nå i prosjektperioden. Et av hovedmålene er at vi skal ta til oss ny læring om kommunikasjon mellom hardware og eksterne systemer. Dette for å være bedre rustet til å takle problemstillinger innenfor nye teknologier når vi skal ut i det faktiske arbeidsmarkedet. Et annet mål er at vi skal benytte den kunnskapen vi har opparbeidet oss i årene som dataingeniør-studenter, fra emner som teknologiledelse, applikasjonsutvikling, systemutvikling, databaser og operativsystemer. Det å jobbe i team på et større prosjekt over lenger tid er god erfaring vi også forhåpentligvis tar med oss etter prosjektperioden. I tillegg til dette ønsker vi også å forbedre kunnskap rundt dokumentering av større prosjekter og å få kjennskap til hvordan arbeidsdagen som systemutvikler/programutvikler er. 8 Kravspesifikasjon Vi laget en kravspesifikasjon for å få klarhet i hva systemet skal utføre. Kravspesifikasjonen definerer alle grensesnitt og funksjonalitet og blir således vårt viktigste arbeidsdokument for å nå ønsket resultat. Kravspesifikasjonen fungerer også som en avtale mellom prosjektgruppa og oppdragsgiver om hva som skal kreves av systemet. Dette for å opprettholde åpenhet mellom partene og at vi vet hva som forventes av hverandre. Hovedelementer fra kravspesifikasjonen: - Undersøke og konkludere med et passende sensorsystem Bevegelsessensorene skal detektere bevegelse. Bevegelsessensorene skal gjøre sensordataene tilgjengelig for mobilapplikasjonen. Brukere skal kunne logge inn på mobilapplikasjonen med sin eksisterende Making Waves konto. Brukere skal kunne se hvilke møterom det ikke er bevegelse i. Mobilapplikasjonen skal kunne kommunisere med de eksisterende systemene til Making Waves. Brukere skal kunne booke ledige møterom. Hele kravspesifikasjonen kan sees i vedlegg 1. 9 Milepælsplan Mathias og Snorri Mathias Snorri Tittel Research Innkjøp Planlegging Uke 1 Uke 2 Uke 3 Uke 4 Uke 7 Uke 8 Uke 9 Uke 10 Uke 11 Uke 12 Uke 13 Uke 14 Uke 5 Uke 6 Uke 15 Uke 16 Implementering Sensor Gateway Database Uke Uke17 19 Applikasjon Sensor kommunikasjon Ekstern kommunikasjon GUI (Graphical User Interface) Testing Dokumentasjon Vi har utviklet en milepælsplan som viser hvordan vi har planlagt at arbeidet skal foregå fremover. Vi har delt planen inn i hoveddeler som er forholdsvis isolerte, slik at vi kan klargjøre en del før vi beveger oss over på neste. Første fase består av research rundt forskjellige sensorsystemer og valg av sensorsystemet vi ønsker å gå videre med. Når valg av sensor er gjort har vi satt av 4 uker til implementering og testing av sensorsystemene. Etter at implementeringen er gjort ser vi for oss at vi kan begynne med applikasjonen. Her inngår både kommunikasjon med sensorsystemet, kommunikasjon med eksterne systemer, utvikling av et godt visuelt brukergrensesnitt og testing av applikasjonen. Under hele prosessen blir det ført dokumentasjon av begge gruppemedlemmene. 10 Teknisk tegning av systemet Figur 2 Teknisk tegning Helt i starten av research perioden skisset vi opp en tegning av hvordan vi så for oss systemets kommunikasjonsflyt. Den tekniske tegningen blir gjengitt i detalj under implementasjon av sensorsystem og kommunikasjon med eksterne systemer. 11 Valg av Hardware og Implementasjon av Sensorsystem 12 Mikrokontrollere Hvorfor trenger vi mikrokontrollere? Vi bestemte oss tidlig for at vi ville avgjøre romaktivitet ved hjelp av bevegelsessensorer. Siden ett av kravene til oppgaven var at systemet skal være mest mulig brukervennlig å installere kom vi frem til at vi ville videreformidle sensordata ved hjelp av mikrokontrollere og bruk av “Internet of Things”. Internet of Things Internet of Things er et nettverk av objekter som har fått innbygd elektronikk, programvare, sensorer etc. for å gjøre det mulig å utveksle data med en operator og/eller en annen tilkoblet enhet. Hver enhet(thing) er unikt identifiserbar gjennom dets innebygde datasystem, og er i stand til å kommunisere sammen innenfor den eksisterende internett-infrastrukturen. Begrepet “Internet of Things” ble først introdusert av briten Kevin Ashton, i 1999. Figur 3 Internet of Things IoT er forventet å kunne tilby tilkobling av alle slags enheter, systemer og tjenester. Sammenkoblingen av disse enhetene er ventet å kunne tilby automatisering innen nesten alle felt. I følge Gartner Ink. (amerikansk rådgivnings og forskningsselskap) vil Internet of Things bestå av opp mot 26 milliarder enheter i år 2020, andre estimerer med at det vil være så mange som 30 milliarder enheter tilkoblet[1]. Internet of Things enheter kan brukes til å overvåke og kontrollere mekaniske og elektroniske systemer. Dette kommer til å bli mer og mer synlig på det private markedet i årene som kommer. Innenfor Home Automation kommer vi til å se en markant økningen av “smarte” hjem ved hjelp av IoT. Man kan gjøre alt fra å starte kaffetrakteren til å sette opp sitt eget sikkerhetssystem ved hjelp av diverse sensorer og kameraer. Det er her prosjektet vårt kommer inn i bildet. Vi vil ved hjelp av mikrokontrollere koblet sammen med en PIR-sensor (Passive Infrared-sensor) og et batteri kunne overvåke aktiviteten i de forskjellige møterommene og publisere dataene på nett for så å hente det ned igjen med applikasjonen. 13 Vurdering av kontrollere Etter det ble klart at sensordata skal videreformidles ved hjelp av mikrokontrollere var neste steg å finne ut hva slags mikrokontroller som ville passet best til vår kravspesifikasjon. Mot slutten av research-perioden sto valget mellom kontrollere fra 3 forskjellige leverandører, samt en som Making Waves tidligere hadde kjøpt inn. Under finner du et sammendrag av fordeler og ulemper med de forskjellige kontrollerne, og til slutt en konklusjon for valget som ble tatt. Spark IO Spark IO ble grunnlagt i 2012 i California og fikk i gang finansieringen av sin første modell, Spark Core, ved hjelp av en Kickstarter kampanje. Firmaets fokus går på å utvikle verktøy som gjør det lettere å få hardware på internett. Spark Core Figur 4 Spark Core Nøkkelegenskaper “On-board”-WiFi Fordeler Mulig å publisere data direkte til web-server Cloud-programming: build.spark.io Med internett-tilgang har du alltid utviklingsmiljøet ditt tilgjengelig. Open source All kildekode er gjort tilgjengelig og bibliotekene deres oppdateres ofte. Spark IO har et stort forum på nettsiden sin hvor man kan se andres prosjekter og få innspill. Annet Ulemper Krever mye strøm. Det vil være vanskelig å bruke Core 8-10 timer om dagen over lenger tid på batteri uten å måtte skifte det hyppig. Du er avhengig av internetttilgang, og kan ikke laste opp kode offline. Dersom Spark IO f.eks. skulle gå konkurs vil løsningen være vanskelig å vedlikeholde. Ingen ulemper Vår vurdering Spark Core er en god kandidat til prosjektet. Den er innovativ med dens “on-board”-WiFi, men ettersom det sannsynligvis vil påvirke batteri-levetiden betraktelig kan det også bli grunnen til at den faller bort. 14 Arduino Arduino er et open source hardware/software firma som bl.a. bygger digitale komponenter man kan sette sammen. Dette er den leverandøren som hadde størst utvalg og et solid grunnlag ettersom de har vært i drift i 10 år. De har et stort utvalg komponenter man kan sette sammen for å utføre forskjellige operasjoner. Figur 5 Arduino Uno Arduiono Uno Nøkkelegenskaper Arduino IDE Open source Fordeler Deres eget gratis utviklingsmiljø er enkelt å sette seg inn i og gjør det lett å overvåke tilkoblet kontroller. Ulemper All kildekode er gjort tilgjengelig og det finnes mange tutorials som kan tilpasses vårt behov. Annet Ettersom firmaet har vært i Prisen på Arduino Uno har drift i 10 år er det grunn til å en litt høy pris i forhold tro de har fått opp et stabilt tilsvarende kontrollere. og pålitelig system med kontrollere, komponenter og utviklingsmiljø. Krever tilleggskomponenter for å sende data Arduino Uno er forholdsvis stor i størrelse. Vår vurdering Arduino har et solid grunnlag på markedet og er anerkjent i prosjekter som omhandler Internet of Things. Dessverre er både størrelse og ytelse noe som gjør at vi stiller oss tvilende til at dette er det rette produktet til vårt bruk. 15 Tessl Tessl er en kontroller som ble presentert for oss av en ansatt i Making Waves. Det er noe de hadde kjøpt inn for en liten stund tilbake for å leke litt med. Tessl er bygget på JavaScript og vi kom ganske fort frem til at dette kun var et leketøy for webutviklere med ganske begrenset bruksområde utenfor det som alt lå klart. Men den fungerte allikevel godt som et verktøy for å få litt større forståelse rundt hvordan en mikrokontroller fungerer med analoge inputs og outputs o.l. Figur 6 Tessl Vår vurdering Vi avgjorde ganske tidlig at Tessl var for begrenset til vårt behov og hadde kun nytte som et læringsverktøy mens vi ventet på at de andre produktene skulle ankomme. 16 LowPowerLabs LowPowerLabs ble grunnlagt av Felix Ruso i Canton, Michigan. Felix jobbet tidligere som en web-utvikler med interesse for elektronikk. Når han skulle i gang med et hjemme-automasjons prosjekt hvor han hadde planer om å sette opp et nettverk med Arduinoer kom han på tanken at han ikke trengte å bruke alt Arduinoen hadde å tilby, samt at det ville ta mer plass enn nødvendig og koste mer enn det burde. Han valgte i den anledning å lage en klone av Arduinoen som han strippet for komponenter for å få en mer beleilig størrelse og en lavere pris. Han kunne etter kort tid si opp jobben sin og leve på LowPowerLabs. Figur 7 Moteino R4 Moteino R4 Nøkkelegenskaper RF(Radiofrekvens)-chip Bruker Arduino IDE Open source Gateway - Siden Moteinoen ikke har WiFi er den nødt til å ha en egen gateway for å kunne kommunisere med omverdenen. Fordeler Energieffektiv måte for Moteinoen å sende data seg imellom. Ved å bruke Arduino IDE til utvikling har man allerede klart et solid miljø. All kildekode er gjort tilgjengelig og Felix har mange eksempler på bruk på sin hjemmeside Fordelen med dette er at vi vil ha total kontroll over dataene som utveksles Ulemper Rekkevidden kan ikke forventes å dekke flere etasjer. Det vil kreve mye ekstra arbeid og sette opp en stødig gateway Annet Felix er lett tilgjengelig per mail og vi opplever å raskt få gode svar på spørsmål. Vår vurdering Moteino R4 er som sagt en klone av Arduino Uno, men uten alle ekstra komponenter vi ikke har bruk for i vårt prosjekt, noe som gjør den mindre og mer energieffektiv. Den har en lav kostnad og selv om det vil kreve en del ekstra jobb med gateway virker dette som en god løsning for prosjektet 17 To løsninger Etter research-perioden var over i slutten av uke 3 sto vi igjen med to alternative løsninger. Den første, Spark Core, var vi i tvil om ville være optimal i forhold til batterilevetid. Den store fordelen med Spark er at den har “on-board” WiFi, men dette er også ulempen. Desto kraftigere komponenter du har på, desto større krav settes til batteri. Men ettersom “on-board” WiFi var en veldig interessant måte å løse hardware-problemstillingen valgte vi å gi det et forsøk. En annen mulig utfordring med Spark Core er at det er en førstegenerasjonskontroller fra Spark IO, den første med “on-board” WiFi. Og som det ofte er med 1. generasjons-produkter så vil det høyst sannsynlig dukke opp problemer underveis som bærer preg av dette. Løsning nr. 2 var åpenbar. Moteino R4. Moteino er som tidligere nevnt, en Arduino klone. Dette gjør at den virker som en stabil løsning. Den bygger på en mikrokontroller som har vært på markedet en stund, den er open source og virker som den tryggeste løsningen. Det at den ikke har WiFi gjør at strømforsynings-utfordringen blir betydelig mindre. Det den derimot har er en radiofrekvens sender/mottaker. Moteino R4 er en transceiver. Det vil si at den kan like gjerne være en sender som en mottaker. Radiofrekvens-chippen krever langt mindre strøm enn en WiFi-chip. Et røft regnestykke viser at Moteinoen tilpasset vårt bruk vil kunne være operativ i 3-5 måneder på et 9V batteri før det må byttes. Ettersom Moteinoen ikke har WiFi blir vi nødt til å sette opp en gateway for å kunne gjøre rom-statuser tilgjengelig for applikasjonen. Gatewayen utgjør en Raspberry Pi og en Moteino som vil fungere som en receiver i stedet for en transmitter som de andre Moteinoene som er tilkoblet PIR-sensoren. Kommunikasjon Rammeverk Open source Annet Pris Spark Core WiFi build.spark.io ✓ Moteino R4 Radiofrekvenser Arduino IDE ✓ 19 USD 13 USD 18 Konklusjon Da planleggingsfasen gikk mot slutten i uke 6 hadde vi fått testet begge løsningene og konklusjonen var klar. Spark Core krever for mye strøm. Skal den tilkobles et batteri er man nødt til å lade eller bytte batteriet hyppig. Dette sammen med at Spark IO enda ikke har et offline utviklingsmiljø klart, gjør at Spark Core faller bort og vi vil fortsette prosjektet med Moteino R4. Dersom dette prosjektet skulle blitt utført noen år frem i tid ville nok konklusjonen blitt en annen. Vår vurdering er at Spark Core er ikke klar for denne oppgaven per dags dato. 19 Hardware-implementasjon Figur 8 Teknisk tegning av hardware-side Gateway Da det ble klart at Moteino R4 var kontrolleren vi skulle bruke, ble det også klart at det måtte settes opp en gateway for å få publisert sensordata online. Gatewayen vil være en sammensetting Figur 9 Gateway-Moteino + Raspberry Pi av en Raspberry Pi A+ og en Moteino R4 som fungerer som en receiver og vil motta data fra andre sensor-Moteinoer i radiofrekvens-nettverket. 20 Raspberry Pi A+ Raspberry Pi er en liten datamaskin som er bygget på et enkelt kretskort knapt større enn et kredittkort. Den kan kobles til en monitor ved hjelp av HDMI og fungerer på samme måte som en vanlig datamaskin. Selskapet bak Raspberry Pi er Raspberry Pi Foundation som ble grunnlagt for å oppmuntre til å lære grunnleggende databehandling i skolen. Figur 10 Raspberry Pi A+ Raspberry Pi A+ har kun en USB-inngang, men dette kan enkelt utvides ved hjelp av en USB-hub. Noe vi også ble nødt til å gjøre slik at vi kunne koble til nødvendige verktøy som tastatur, mus, WiFi og lignende under utviklingen. Ved å gi Pi’en WiFi åpnet det også muligheten for å bruke SSH (secure shell), noe som gjør arbeidet med å programmere på Pi’en lettere. Operativsystem vi valgte å gå for heter Raspbian og bygger på det universelle operativsystemet Debian (Linux distribution), som har et godt rykte på seg for å være et stabilt og sikkert operativsystem for Raspberry Pi. Raspberry Pi’ens oppgave vil være å lese data fra USB(serial)-porten som Moteinoen er tilkoblet og deretter skrive de mottatte dataene til databasen som ligger på en webserver ved hjelp av et PHP(Hypertext Preprocessor)-script kalt index.php. Dette løste vi ved å installere en NginX og en Socket.io websocket server på Raspberry Pien. Websocketen blir proxyet igjennom NginX ved hjelp av javascriptet gateway.js slik at vi får en live feed med sensordata som index.php kan plukke opp. Figur 10 Utdrag 1 fra gateway.js 21 Figur 11 Utdrag 2 fra gateway.js NginX er en gratis open source HTTP server med høy ytelse samt en IMAP/POP3 proxy server. NginX er nå host for litt over 12% av aktive nettsider over alle domener. Den er kjent for sin høye ytelse, stabilitet, stort utvalg av funksjoner, enkel konfigurasjon og lavt ressursforbruk. NginX står i bakgrunnen på flere høyprofilerte sider som Netflix, Hulu, GitHub, SoundCloud og mange flere. Socket.IO er et JavaScript bibliotek for realtime web-applikasjoner og er hendelsesdrevet. Det vil si at det kun vil reagere dersom en forhåndsdefinert handling forekommer. Som i vårt tilfelle vil være når en sensor detekterer en bevegelse. I index.php ligger det ”if-else” statements til de respektive rommene som følger med på hvilken status rommet har. Hvis det er bevegelse i rommet så vil scriptet fange opp dette gjennom data som kommer via socketen hvor 1 representerer opptatt og 0 representerer ledig. Deretter vil et kort Ajax-script trigge en PHP-fil som skriver statusen videre til databasen. Figur 12 Utdrag fra index.php 22 Moteino-Gateway Figur 13 Moteino R4 + Raspberry Pi A+ Moteinoen vil, som tidligere nevnt, fungere som en receiver på Gateway delen. Det vil si at den er i stand til å ta imot og prosessere data. Moteinoen har en radiofrekvens-chip loddet på seg. Dette gjør det mulig å lytte til og ta imot data over radiofrekvenser. I vårt tilfelle er Moteinoen satt til å lytte på 433MHZ, noe som betyr at den kun vil være i stand til å fange opp data som broadcastes på denne kanalen. Figur 14 Utdrag 1 fra mw_gateway.ino Figur 14 viser et utdrag fra koden som ligger på Gateway-Moteinoen hvor NODEID, NETWORKID og FREQUENCY blir definert 23 Figur 15 Utdrag 2 fra mw_gateway.ino I utdrag 2 vist i figur 15, blir serial-porten mellom Moteinoen og Raspberry Pien åpnet og Moteinoen står klar for å lytte på RF69_433MHZ. Hvis den mottar data fra en sensornode ute i nettverket vil den umiddelbart skrive dataen videre gjennom serial-porten til Raspberry Pien. 24 Sensor Moteino-Sensor På sensorsiden har vi valgt å lodde en PIR-sensor fast til en Moteino som skal fungere som en transmitter. Sensoren har 3 ledninger tilkoblet, en fungerer som gnd(jord), en som 5V for å tilføre nødvendig strøm og en som output. Disse 3 ledningene er loddet fast til hver sin respektive plass på Moteinoen som vist nedenfor i Figur 17. Figur 16 Sensor-side PIR-sensoren har et pyroelement som oppfatter infrarødt lys. Foran pyroelementet er det festet en linse som deler opp synsfeltet slik at den lettere kan oppfatte varme objekter som beveger seg i rommet. Når sensoren oppfatter bevegelse sender den en “høy” puls fra sin digitale OUTPUT videre til Moteinoens digitale INPUT for så å forbli “høy” i 8 sekunder etter siste bevegelse er oppfattet. Dette for å unngå at sensoren skal bytte fra “høy”(bevegelse) til “lav”(ingen bevegelse) bare fordi det er noen sekunder uten bevegelse i rommet. Figur 17 Moteino R4 + PIR-sensor Moteinoen har både digitale og analoge INPUT/OUTPUT-pins. PIR-sensoren skal kobles til en digital INPUT på Moteinoen da den har en digital OUTPUT. Når sensoren sender en “høy” puls til Moteinoens INPUT vil et “if-statement” plassert inne i en loop på Moteinoen slå til. Og deretter broadcaste dette videre til Gateway-Moteinoen sammen med Sensor-Moteinoen sin id som refererer til hvilket rom sensoren er plassert. Moteinoen har 9 digitale INPUT/OUTPUT-pins og det er ingen forskjell hvilken pin PIR-sensorens ouput-ledning er loddet fast til så lenge riktig pin blir deklarert i koden som ligger på Moteinoen. 25 Figur 18 Utdrag 1 fra mw_sensor.ino Figur 19 Utdrag 2 fra mw_sensor.ino Først blir lokale variabler NODEID, GATEWAYID, FREQUENCY og MOTIONPIN definert. NODEID er den unike ID til hver sensor, dette for at gateway skal kunne skille mellom hvilke sensorer den mottar informasjon fra. GATEWAYID er ID til gatewayen som vi ønsker å sende informasjonen til. FREQUENCY er den infrarøde frekvensen vi sender informasjon over til gateway. Når bevegelse blir detektert blir digitalWrite(EXTLED, HIGH) utført. Dette gir instruks til den monterte LED på Moteino-sensoren om at den skal lyse slik at vi som utviklere kan følge med på at alt er i orden mellom sensor og kontroller. Dette blir etterfulgt av selve sendingen av informasjon med sprintf(sendBuf, ‘’Bevegelse oppdaget’’, BATstr). Radiosenderen blir så bedt om å slå seg av igjen (radio.sleep()) og den monterte LED på Moteino-sensoren blir slått av (digitalWrite(EXTLED,LOW)). Database For at informasjon om hvilke rom det er bevegelse i skal være tilgjengelig for applikasjonen har vi valgt å lagre sensoraktivitetene på en MySQL-database som ligger på vår webserver. I denne databasen ligger det en enkel tabell. Se figur 21. Etter et møte med oppdragsgiver kom vi til enighet om å droppe databasen hver kveld. Dette for å unngå en eventuell konflikt med Datatilsynet vedrørende lagring av data. Figur 21 Tabell i databasen room_db Figur 20 Database 26 Kommunikasjon med Eksterne Systemer 27 Figur 22 Server-side Når man booker et møterom gjennom applikasjonen Making Room skjer det en stegvis prosess som består av flere ledd og som kommuniserer med ulike eksterne systemer. I denne delen av rapporten vil vi forklare litt nærmere om de ulike interne og eksterne systemene, og hvordan vi har tatt de i bruk i mobilapplikasjonen Making Room. Microsoft Office 365 Office 365 er Microsofts plattform for skybasert programvare med månedlige avgifter. For private brukere gir Figur 23 Office 365 tjenesten tilgang til skytjenesten OneDrive for lagring av personlige dokumenter og filer, og man får adgang til å benytte seg av de velkjente Microsoft Office programmene som Excel, Word, PowerPoint og Outlook. For større selskaper gir Office 365 tilgang til skybaserte serverløsninger som Exchange Server Online, Lync og SharePoint i tillegg til de kjente Microsoft Office programpakkene. De skybaserte serverløsningene kommer med egne administrasjonsløsninger som gjør det enklere for systemansvarlige i de gitte selskapene å kontrollere flyten av informasjon, dokumenter, filer og epost innad. Making Waves har per dags dato ikke gått over til Microsoft Office 365, men benytter seg av programvare som krever fysiske servere i lokalene deres. De har planer om å gå over til Office 365 i løpet av året ettersom dette vil skape større 28 trygghet for systemet og gjøre det lettere å administrere. Making Waves har utrykket ønske om at vi skal utvikle en applikasjon som tar i bruk de skybaserte serverløsningene som ligger i Office 365. Vi opprettet en gratis privat Office 365-konto for å bruke som test-område[2]. På denne måten slapp vi unødvendig bekymring for å forstyrre de interne systemene til Making Waves. Et skjermbilde av Office 365 sin hovedportal kan sees i vedlegg 2. Ved hjelp av denne test-kontoen fikk vi tilgang til Outlook, Exchange Online og Azure. Dette er de tre eksterne systemene vi har kommunikasjon med i mobilapplikasjonen og som vil bli forklart ytterligere i rapporten. Outlook Microsoft Outlook er Microsofts e-post-klient. Her kan brukere bl.a. sende og motta e-post, sjekke kalenderen sin, vedlikeholde kontakter og avtale møter i kalenderen. Man kan få tilgang til Outlook ved hjelp av en Office 365-konto. Vi har bruk for Outlook fordi dette er de ansatte i Making Waves’ nåværende måte å reservere rom og avtale møter på. Når brukere booker et møte i mobilapplikasjonen Making Room, skal dette vises i deres Outlook-kalender. Microsoft Azure og Azure Active Directory Microsoft Azure er en del av Microsofts programpakke som man får tilgang til ved hjelp av en Office 365-konto[3]. Azure er en plattform for det som kalles «cloud computing». «Cloud computing» vil si at man Figur 24 Azure Active Directory kan bygge, administrere og distribuere programvare og servicetjenester ved hjelp av en skytjeneste. I Azure kan du sette opp virtuelle maskiner, installere SQL-databaser og administrere et selskaps Active Directory. Et skjermbilde av et typisk Azure-vindu kan se ut som vist i vedlegg 3. Det kan være mange grunner til at et selskap ønsker å gå over til en skybasert hverdag. Hovedsakelig er det to elementer som spiller inn; pris og sikkerhet. Det å ha et privat serverrom er mye dyrere enn å betale et mindre månedlig beløp for Azure og Office 365. Man trenger ikke drive vedlikehold på det, og sannsynligheten for nedetid er svært liten. Sikkerheten går på at ingen vil kunne fysisk bryte seg inn og stjele informasjonen direkte fra serverne dine. Dette setter allikevel nye krav til at man har dyktige administratorer som gir riktige brukerrettigheter til de ansatte. Active Directory (AD) er Microsofts katalogtjeneste. Her blir objekter sortert etter kategorier, mapper og grupper for lettere å kunne betjene disse i brukerens system. AD kan håndtere brukere, datamaskiner, applikasjoner, brukerrettigheter og andre ressurser og tjenester. Et eksempel på dette er hvis en har 10 datamaskiner i sirkulasjon og 2 som er satt til å være reserve. Disse vil 29 da naturlig bli sortert under to forskjellige mapper, en for de i sirkulasjon og en for de som er satt som reserve. Samme gjelder brukere av systemet. Man kan kategorisere etter avdelinger, geografiske plasseringer eller brukertilgang. AD er et kraftig verktøy når man skal kartlegge systemet sitt. Microsoft Azure har som tidligere nevnt mulighet til å opprette og vedlikeholde Active Directory. Disse heter Azure Active Directory (AAD). Den er akkurat som de eldre formene for AD, men skybasert. Dvs. databasen ligger på Microsofts servere istedenfor å ligge lokalt. AAD kommer Figur 25 også med utvidet funksjonalitet og med et enklere Autentisering grensesnitt enn de eldre formene for AD. Ettersom Making Waves skal migrere over til et skybasert system, ble vi nødt til å opprette en AAD vi kunne koble vår mobilapplikasjon mot. For at brukere av mobilapplikasjonen Making Room skal kunne booke rom og få dette vist i sin Outlook-kalender må både brukeren av mobilapplikasjonen og mobilapplikasjonen selv være elementer i AAD. Grunnen til dette er at mobilapplikasjonen må få kontakt med de andre elementene som er tilknyttet den ansattes konto, ref. Outlook og SharePoint, og at mobilapplikasjonen må få kontakt med de andre servertjenestene som er tilknyttet denne Azure Active Directoryen, ref. Exchange Online. Brukerne må være en del av AAD for at de skal kunne logge inn i mobilapplikasjonen med brukernavn og passord. For å knytte en applikasjonen til riktig AAD tildeles en «klient-ID» når man registrerer en ny applikasjon. Denne i tillegg til en «redirect uri» må sendes med når man prøver å knytte seg opp mot Azure Active Directory fra mobilapplikasjonen. Mer om dette i dokumentasjonen av Android applikasjonen. Det bestemmes hvilke tilganger applikasjonen skal ha til eksterne systemer via AAD. Her kan en f.eks. bestemme om applikasjonen skal kunne lese de andre brukernes kontaktinformasjon, sende epost på vegne av, eller legge inn avtaler i den innloggedes kalender. Ettersom applikasjonen vår skal kunne registrere avtaler på vegne av den innloggede brukeren og sende epost fra deres konto har vi gitt Making Room følgende brukertillatelser i vår AAD: - Windows Azure Active Directory tillatelser: o Read and write directory data o Enable sign-on and read users’ profiles o Access your organization’s directory - Office 365 Exchange Online tillatelser: o Read and write user calendars o Send mail as user o Access mailboxes as the signed-in user via Exchange Web Services o Read and write user contacts 30 Microsoft Office 365 Exchange Online Exchange Online er en programpakke fra Microsoft som består av flere viktige tjenester tilknyttet vårt prosjekt. Hovedelementene i Exchange Online er en e-posttjener og kalender- og kontaktprogramvare som alle befinner seg i skytjenesten til Office 365. Exchange Online har en administrasjonsportal på nettet hvor en kan opprette nye epostkasser for både brukere og ressurser, endre brukerrettigheter og administrere e-postflyten inn og ut av sitt eget system. Figur 26 Exchange Online For vår oppgave har det vært behandlingene av rommene som har vært viktigst. I Exchange Online oppretter man det som heter “resource-mailboxes”. Dette er epostkasser som ikke er for sluttbrukere. Disse blir tildelt de respektive møterommene det skal bookes møter mot i Outlook. Skjermbilde av administrasjonsportalen til Exchange Online kan sees som vedlegg 4. Når man skal avtale et møte i Outlook, velger man tid og sted møte skal være og inviterer de som skal delta på møtet. Rommet møtet skal være på blir så lagt til som “deltaker” på møtet. Rommet vil så motta en e-post om hvilket tidspunkt møtet skal finne sted. Rommet vil deretter “sjekke” om det er opptatt i det aktuelle tidsrommet. Er det ingen planlagte møter vil det sette seg selv som opptatt i den valgte tidsperioden, slik at det ikke skal være mulig å bli dobbeltbooket. Om rommet ikke er ledig, vil den som sender invitasjonen få en epost fra rommet som sier at det ikke er ledig for øyeblikket og invitasjonen vil bli avslått. I Android mobilapplikasjonen Making Room skal brukeren få opplyst hvilke rom som ikke er blitt booket av andre brukere, eller de som er booket men ikke har noen detektert bevegelse. Om rommet er booket, men det ikke er detektert bevegelse skal bruker bli møtt med en melding om at han/hun kan ta en titt og se om det er noen der. En mer detaljert forklaring angående dette kommer i mobilapplikasjons-dokumentasjonen. Exchange Online har en oversikt over rommene man har opprettet via administrasjonsportalen. Her kan man få oppdatert informasjon om hvor rommene ligger, navn og e-post, i tillegg til ekstraopplysninger om hva rommene tilbyr av utstyr (prosjektor, størrelse o.l.). Skjermbilde av oversikt over rommene i Administrasjons-portalen til Exchange kan sees i vedlegg 5. Exchange Online har egendefinerte metoder for å legge til rom, dette gjør det enkelt for en eventuell administrator å legge til de ønskede ressursene man har behov for. Når man legger til et rom egendefinerer man navn på rommet, epostadresse, plassering, telefon og kapasitet. For å se hvordan prosessen med oppretting av rom foregår i Exchange Online se vedlegg 6. 31 Android Mobilapplikasjon 32 Siste del av prosjektet omhandler utviklingen av mobilapplikasjonen som har fått navnet “Making Room”, inspirert av Making Waves sine mange ordspill på navnet deres. Use Case Modell Figur 27 UML Use Case-Modell for sluttbruker Figuren over er en use case-modell for mobilapplikasjonen Making Room. Her ser vi hvilke Use Case’r som kan bli utført av sluttbruker, nemlig logge inn i applikasjonen, reservere rom, kansellere reservasjonen, utvide reservasjonen med 15 minutter og se rom som ikke har bevegelse i seg. 33 Detaljert beskrivelse av Use-Caset «Book rom» Use Case Aktør Prebetingelser Postbetingelser Hendelsesflyt Variasjoner Booke rom Sluttbruker Bruker vil booke rom Bruker er innlogget Bruker er inne i applikasjonen Bruker har booket rom 1. Bruker velger hvor lenge han/hun vil ha et møterom 2. Bruker velger et passende møterom som er ledig 3. Bruker trykker på “book rom” -knappen 4. Rommet er nå booket. 1. Ingen møterom er ledige a. Bruker må vente til et rom blir frigitt b. Bruker kan prøve på nytt 2. Varigheten som er oppgitt passer ikke med noen av rommene som er ledig nå. a. Bruker kan vente til et rom blir ledig med passende varighet. b. Bruker kan endre varighet av bookingen. c. Bruker kan prøve å booke på nytt. 34 Spørreundersøkelse Før vi begynte med utviklingen og design av applikasjonen var det viktig for oss å kartlegge bruken av møtebooking hos Making Waves i dag. Ønsker om funksjonalitet ved en eventuell møtebookingsapplikasjon og om de ansatte i selskapet i det heletatt kunne tenkt seg å bruke en møtebookingsapplikasjon. Vi bestemte oss derfor for å lage en spørreundersøkelse som vi sendte til alle ansatte ved Making Waves i Norge. Spørsmålene vi stilte de ansatte i spørreundersøkelsen er som følger: - - - - Hvilken avdeling jobber du i? o Client Operations o Content & Communications o Experience Design o Lifecycle o Sales o Technology o Annet Hvor ofte skjer det at... o du avbooker et møterom når ditt møte blir avlyst? Ofte Noen ganger Aldri o det er ingen ledige møterom når du trenger det? Ofte Noen ganger Aldri o alle møterom er opptatt, du leter I bygget og finner et ledig? Ofte Noen ganger Aldri o du har behov for å finne et møterom umiddelbart? Ofte Noen ganger Aldri Hvor ofte booker du møterom? o Hver dag o Et par ganger I uken o Et par ganger I måneden o Sjeldnere enn et par ganger I måneden Er en møteromsapplikasjon noe du ser behovet for og selv ville brukt? o Ja o Nei Har du noen funksjonalitetsforslag for en slik applikasjon? 35 Med disse spørsmålene klarer vi å lokalisere problemområder, kartlegge bruksvaner og samle inn data om ønsker fra de ansatte. Det var 76 personer som svarte på spørreundersøkelsen spredt over alle avdelingene til Making Waves. Vi fikk størst respons fra Technology-avdelingen som sto for nesten 40% av svarene. Experience Design og Client Operations lå bak med henholdsvis 22% og 15% av responsen. Ved å analysere svarene vi har fått inn ser vi fort at dette er en applikasjon det er behov for. Over 50% avbooker aldri eller kun noen ganger når et møte blir avlyst. Samtidig ser vi at over 95% har erfart at det enten ofte(41%) eller noen ganger(55%) ikke er noen ledige møterom når de trenger det. På spørsmål om de finner et ledig møterom selv om det står at alle er opptatt, så svarer over 85% at de har opplevd dette flere ganger. Dette kan vise til at det er mange som ikke kansellerer rommene de har booket ved en tidligere anledning. Alle bortsett fra en av de som svarte på undersøkelsen har opplevd noen ganger eller oftere at de behøver å finne et ledig møterom umiddelbart. Dette styrker våre tanker om at dette er en applikasjon som Making Waves kan dra nytte av og som vil bedre de ansattes hverdag. Når det gjelder hvor ofte de ansatte booker møterom er det veldig stort sprik i tallene. 23% av de spurte svarte de booker møterom sjeldnere enn et par ganger i måneden. Men vi ser samtidig at nesten 60% av de spurte booker et møterom et par ganger i uken eller oftere, så behovet er fremdeles tilstedeværende. 36 Figur 28 Spørreundersøkelse Det siste og mest avgjørende kartleggingsspørsmålet gir en god pekepinn på at de ansatte ønsker seg en slik mobilapplikasjon og at de ser behovet. Av funksjonalitetsforslagene vi fikk inn var det et par som gikk igjen. Den mest etterspurte funksjonen er at mobilapplikasjonen skal være rask og enkel i bruk. Vi bestemte oss derfor for å fokusere på at det skal være færrest mulig klikk for å utføre en booking i applikasjonen. Den nest meste etterspurte funksjonen var at applikasjonen burde vise hvor mange det er plass til i de enkelte møterommene. Disse behovene blir det tatt høy for i designet av applikasjonen. Alle svar og spørreundersøkelsen kan sees i vedlegg 7 og vedlegg 8 37 Designvalg og utforming Før utviklingen av applikasjonen startet ble det tatt noen valg med hensyn til design og utforming. På bakgrunn av informasjon vi hadde samlet inn under spørreundersøkelsen satte vi i gang med designet. Vi har gått gjennom flere iterasjoner av designet. Noen av de tidligste utformingene kan sees som vedlegg 9. Disse designvalgene gjør den daglige bruken av mobilapplikasjonen enklere for brukerne ved at de kan booke rom mer effektivt. Valgene fungerte også som retningslinjer da vi gikk videre med utviklingen av applikasjonen. Designvalgene er delt opp etter skjermbilde (eller “aktivitet”) som brukeren møter i den naturlige gangen. Vi har fått hjelp av vår kontaktperson, Kristoffer Sundmyhr, hos Making Waves med det visuelle designet av applikasjonen. Metoder og operasjoner kan det leses om i Use-Casene som ligger i vedlegg 10. Skjermbilde #1 – Login Det første som skal møte brukeren er et skjermbilde med en knapp som hentyder til at her skal man klikke for å logge inn på applikasjonen. Det skal være i tilsvarende stil som Making Waves profil. Det vil derfor være mye kontraster av svart og hvitt med innslag av grønn (heksadesimal fargekode ligger under generelt). Skjermbilde #2 – Azure Active Directory Login Ved førstegangsbruk eller når brukeren selv har logget ut av Office 365, skal brukeren få dette vinduet når han/hun trykker på login-knappen på første skjermbilde. Da vil det komme opp et standardisert loginvindu fra Microsoft. Dette er et tvunget steg for at vi skal kunne benytte oss av de eksterne systemene. Her skal brukeren fylle inn brukernavn og passord for å logge på Office 365. Dette er et vindu som har svart tekst på hvit bakgrunn. Ved innlogging på Making Waves sine systemer skal Making Waves’ logo bli vist øverst i bildet. Etter at brukeren har skrevet inn sin brukernavn og passord og trykket på “sign in” vil applikasjonen gå videre til skjermbilde #3. Dersom brukeren har brukt mobilapplikasjonen tidligere og ikke logget ut, vil klikk på login-knappen i første skjermbilde føre direkte til bookingvinduet. Dette for å spare brukeren for unødvendige mange klikk ved at påloggingsinformasjon blir lagret fra tidligere pålogginger. Skjermbilde #3 - Booking I det tredje skjermbildet vil store deler av bruken foregå. Her vil det være valg om hvor lenge et møte skal vare, hvilket rom man ønsker å booke, oppdatert informasjon om hvilke rom som er ledige, samt booke det valgte møterommet. Fargevalgene vil følge de samme retningslinjene som i det første skjermbildet, med mørke kontraster og bruk av grønnfarge for å fremheve elementer. Det vil være et ikon for utlogging øverst i venstre hjørne av skjermen og et ikon for oppdatering av rominformasjon øverst til høyre. Dette er plasseringer vi føler er naturlige fra bruken av andre applikasjoner med liknende funksjoner. Knappen for å booke rom skal være grønn og dekke nederste del av skjermen. 38 Dette er et hovedelement i designet og det skal derfor være tydelig at denne knappen fører til neste skjermbilde. Tidsrom og møterom som sluttbrukeren skal velge ligger i horisontale lister med “swipe”-funksjoner. Dette for å forenkle, hurtiggjøre og gjøre disse prosessene mer naturlig. Skjermbilde #4 – Pågående møte Dette er det siste skjermbildet i applikasjonen. Her vil det bli vist hvor lenge det er igjen av møtet med stor tekst midt på skjermen sammen med en animasjon som visualiserer dette. Har brukeren et pågående møte er dette det eneste skjermbildet som vises i applikasjonen. Det vil i tillegg være to knapper, en for å kansellere møtet og en for å legge til 15 ekstra minutter hvis det er nødvendig. Alle elementer på denne skjermen er store og tydelige. Det skal ikke være noe andre elementer som kan rote til skjermbildet. “Kansellere møte”-knappen er rød siden fargen rød er en konvensjon i samfunnet om fare/stopp. Når møtet er ferdig skal brukeren bli sendt tilbake til skjermbilde #3. Generelt Antall klikk Vi har fokusert på at denne applikasjon skal være enkel og rask i bruk. Vi har derfor satt krav til at det skal være maks 5 klikk for å oppnå ønsket resultat. Dette vil spare sluttbrukerne for tid og sannsynligvis øke deres lyst til å benytte seg av applikasjonen. Ved å lagre informasjon om tidligere innlogginger, benytte oss av “swipe”-funksjoner og “ett-klikk”-løsninger bidrar vi til en raskere booking. Layout Vi har bygget applikasjonen slik at den skal fungere i stående format. Det er slik de aller fleste bruker applikasjoner på sine telefoner. Å bruke applikasjonen stående gjør det enklere for brukere å benytte en hånd når de skal booke et møterom (litt avhengig av skjermstørrelse). Fargevalg, fonter, bilder Making Waves har en solid og klar designprofil. Vi har derfor valgt å ta utgangspunkt i fargebruk, fonter og bilder som de bruker ellers I selskapet. I tillegg til dette benytter vi oss av logoen deres og navnet “Making Waves” for ytterligere å styrke profilen deres og bidra til merkevarebygging. Farger - Grønn (#50ddb9) - Rød(#D84154) - Sort(#1E1E1D) - Lysegrå(#787877) Fonter - Aften Screen SC Regular (Størrelser: 18,25,45) - Aften Screen Bold (Størrelser: 25,30,40,90) 39 Applikasjonskart Figur 29 Applikasjonskart av Making Room Dette er et enkelt applikasjonskart som viser noe av flyten i mobilapplikasjonen Making Room. Constants.java, CalenderSnippets.java, JSONParser.java og CircularCountdown.java er alle hjelpeklasser. AndroidManifest.xml og Build.gradle er begge filer som bidrar til å bygge mobilapplikasjonen riktig da denne blir installert på mobiltelefoner, og som inneholder informasjon om Android-versjon o.l. 40 Android Android er et mobiloperativsystem som er basert på Linux og utviklet av Google. Operativsystemet er utviklet for bruk på touchtelefoner og nettbrett. Google har selv gått ut med tall på at det er over 1 milliard månedlige Android-brukere [4]. Når man utvikler applikasjoner for Android-plattformen, skriver man koden sin i Java. Java er et objektorientert programmeringsspråk som er godt utbredt. AndroidManifest.xml AndroidManifest.xml er en fil alle Android-prosjekter inneholder. Manifestet består av informasjon om hvordan mobilapplikasjonen er bygget opp og noen primære tillatelser som applikasjonen behøver for å fungere. I tillegg til dette, blir applikasjonsnavnet og logoen som kommer på telefonens applikasjon-skuff satt her. Når mobilapplikasjonen blir installert på en mobiltelefon, ser mobilen på manifestet for hvordan hierarkiet i applikasjonen er. Gradle Gradle er Androids verktøy for å bygge applikasjoner ved bruk av Android-applikasjonens kildekode. I Gradle-filene som ligger i Android Studio-prosjekter blir informasjon om hvilke Android-versjoner applikasjonen retter seg mot, satt, og informasjon om eksterne avhengigheter definert. Disse avhengighetene gjør oss i stand til å bruke verktøy som ikke kommer innebygget i Android Studio. Figur 29 Gradle:dependencies I Making Room benytter vi oss av eksterne avhengigheter som Microsoft har utviklet. Ettersom vi definerer disse i Gradle-filen til vår applikasjon, kan vi benytte oss av metoder som retter seg mot Outlook, Azure Active Directory og andre Office 365-systemer. 41 Constants.java Figur 30 Constants.java Constants.java er en hjelpeklasse til resten av applikasjonen. Her ligger forskjellige URL’er, stringer og ID’er som resten av applikasjonen bruker mye. Blant de viktigste variablene finner vi CLIENT_ID og REDIRECT_URI. CLIENT_ID er den unikt identifiserende kombinasjonen av tall og bokstaver som ble generert da vi opprettet applikasjonen, som brukes til å kommunisere med Azure Active Directory for å hente ut brukerinformasjon. Denne, i kombinasjon med REDIRECT_URI, gjør at vi kan koble oss til de interne systemene til Making Waves og hente ut, skrive eller endre den informasjonen vi trenger. Office 365 SDK for Android Office 365 er vår hovedkommunikasjonsåre for å hente ut informasjon og for autentisering av brukere, og vi behøver derfor en måte å kommunisere med dette på en effektiv måte. For å kunne kommunisere med eksterne systemer hos Making Waves via mobilapplikasjonen, måtte vi ta I bruk en 3. parts SDK (Software Development Kit). Det viste seg tidkrevende å finne et passende verktøy som utførte de oppgavene vi behøvde. Vi prøvde oss først frem med EWS-Java-API, som står for Exchange Web Services Java Application Programming Interface. Her fikk vi løst noen av oppgavene, som f.eks. booking av møter og sending av e-post, men det oppsto store konflikter som ikke lot seg løse med autentiseringen av brukerne. Vi gjorde også et forsøk på webløsninger som kunne overføres og tilpasses Android, men disse ga ikke den responsiviteten vi ønsket I vår mobilapplikasjon, og ble derfor skrinlagt. Det ble nylig sluppet et Microsoft-utviklet SDK for å kommunisere med Office 365 via Android-enheter ved navn “Office 365 SDK for Android”. Denne SDK’en er open source (Norsk: åpen kildekode), vil si at koden som ligger til grunne ligger åpent ute og mer eller mindre hvem som helst kan benytte seg av den. Office 365 SDK for Android går under MIT-lisensen, hvilket kan leses i sin helhet som vedlegg 11. MIT-lisensen sier i korte trekk at man kan bruke kildekoden så lenge man har med en kopi av lisensteksten i hver utgave av programvaren. I tillegg til en ren SDK, har utviklere hos Microsoft lagt ut flere nyttige metoder som man kan bruke mot Office 365. Disse hjelpemetodene ble lagt under prosjektet O365-Android-Snippets på Github. Disse har vi tilpasset vårt formål og brukt i vårt prosjekt. 42 LoginActivity Den første aktiviteten man møter i applikasjonen er loginvinduet. Hovedfunksjonen med dette vinduet er å sørge for autentiseringen av brukere, for å være sikker på at de er skikket til å få bruke applikasjonen. Vinduet følger designmalene til Making Waves med passende bakgrunn, fargevalg og font. Når man trykker login-knappen i bunnen av skjermbildet, blir metoden connectToO365() kalt. Denne metoden kjører flere hjelpemetoder som sjekker bl.a. CLIENT_ID og REDIRECT_URI før den sender deg til Microsofts innlogging mot Azure AD. Her blir brukeren bedt om å fylle inn deres brukernavn og passord til det interne systemet til Making Waves, før de blir sendt videre til neste skjermbilde. Om det har seg slik at brukeren har logget på applikasjonen på deres mobiltelefon tidligere, så vil klikk på “login-knappen” føre de direkte videre til neste skjermbilde uten at de behøver å logge seg inn. Brukerinformasjonen blir da lagret lokalt på telefonen for å spare brukeren for unødvendig mange klikk, og det kutter ned på tiden det tar en bruker å booke et møte gjennom applikasjonen. Om brukeren har logget ut av applikasjonen ved en tidligere anledning, må de logge inn igjen slik som de gjør første gang de brukte Making Room. Figur 32 connectTo0365() 43 MainActivity.java MainActivity.java er hovedaktiviteten i applikasjonen. Det er her brukeren får informasjon om hvilke rom det ikke er aktivitet i og hvilke rom som ikke er oppført som opptatt i AAD. Brukeren starter med å velge møtets varighet. I betaversjonen vil ”30 min” være forhåndsvalgt, men dette er åpent for endring etter hvert som bruksmønsteret blir kartlagt. Når brukeren trykker på ”oppdater”-symbolet i øvre høyre hjørne, kalles metoden doInBackground() i den indre klassen LoadAllRooms som extender AsyncTask. Her blir først et JSONObject satt til å utføre en HttpRequest som henter inn rommene som er oppført i sensortabellen med hver sin respektive status. Figur 33 JSONObject Klassen AsyncTask gjør det mulig å utføre bakgrunnsoperasjoner og publisere resultater på UI-tråden uten å manipulere tråder. Når applikasjonen først starter opp, vil LoadAllRooms() bli kalt fra onCreate(), men deretter må bruker oppdatere manuelt. Etter at bruker har trykket på ”oppdater”, fylles den horisontale listen med rom uten aktivitet, og bruker vil få mulighet til å velge ønsket rom. Hvis rommet ikke står oppført som opptatt i AAD, kan bruker booke rommet. Er det derimot allerede booket, vil bruker bli møtt med en ”AlertDialog”, hvor han får beskjed om at noen allerede har booket rommet, men siden det ikke er aktivitet der, kan han/hun ta en titt for å se om det er ledig. Når bruker har valgt møtets varighet og et ledig rom han/hun ønsker, kan brukeren trykke ”book rom”-knappen for å booke rommet. Når knappen trykkes, blir metoden createCalendarEvent(Event eventToCreate) kjørt. Her blir eventet ”eventToCreate” sendt med som parameter. Eventet har parametere for tidspunktet av møtet og hvem som skal delta. Tidsperioden brukeren har valgt, blir sendt med som tiden, og det valgte rommet blir satt som deltaker på møtet. Figur 34 createCalendarEvent 44 LiveMeetingActivity LiveMeetingActivity.java er den siste aktiviteten som brukere møter når de skal booke møter i Making Room. Skjermbildet består av 3 hovedelementer. En timer for hvor lenge det er igjen av det aktive møtet, en knapp for å utvide møtet med 15 minutter (om mulig) og en knapp for å kansellere møtet. Om et møte er aktivt, vil ikke brukeren kunne gå tilbake fra dette skjermbildet, men må kansellere møtet først. Dette er gjort for å forhindre at en bruker prøver å booke to møterom samtidig. Metoden som blir kjørt når en bruker trykker på “avslutt møte”-knappen heter deleteCalendarEvent(String eventId). Denne metoden henter eventID’en til det pågående møtet og avslutter det ved bruk av hjelpemetoder som ligger i Office 365 SDK for Android. Figur 35 deleteCalendarEvent() Når det gjelder utvidelse av møteromsbookingen, foregår dette i to omganger. Først blir det sjekket at det gjeldende møterommet er ledig de neste 15 minuttene for så at det blir booket et nytt møte som varer disse 15 minuttene. Det er createCalendarEvent(Event eventToCreate) som blir utført når man skal opprette dette møtet på nytt. Her sender man med et event-objekt som har en varighet på 15 minutter som parameter. Det siste elementet i denne aktiviteten er nedtellingen. Dette er et objekt som vi oppretter i en hjelpeklasse som heter CircularCountdown.java. Her bruker vi Androids egne Paint-objekter for å tegne og animere nedtellingen. I hjelpeklassen setter vi farge, fonter og varighet. Varighet for denne nedtellingen, altså den tiden brukeren har valgt at møtet skal vare, blir sendt med som et ekstra parameter fra MainActivity.java. Applikasjonen skal, som nevnt, hente ut status på rommene fra en MySQL-database som ligger på en webserver. 45 Konklusjon Måloppnåelse Vi hadde satt oss mange mål å nå i prosjektperioden. Vi har nådd flere av disse. Vi har lært gode måter å kommunisere mellom hardware og eksterne systemer. Ved hjelp av websockets, PHP og radiofrekvenser får vi sendt data fra sensorer og vist det i et forståelig format. Vi har fått benyttet og utviklet kunnskapen vi har opparbeidet oss i årene som dataingeniørstudenter. Vi har fått en dypere forståelse for Android-programmering, mikrokontrollere og systemutvikling generelt. I tillegg til dette, har vi fått god erfaring med å jobbe i team. Vi har fordelt arbeidsoppgaver og kommunisert tett gjennom hele prosjektperioden. Dessuten har vi fått godt innblikk i hvordan arbeidsdagen som systemutvikler kan være. Konklusjon av produkt I begynnelsen av prosjektperioden satte vi oss en del resultatmål og effektmål vi ønsket å oppnå med produktet. Mobilapplikasjonen kommuniserer i dag med trådløse sensorer, som skal bli plassert i møterommene. Vi har også fått gjort god research rundt forskjellige sensorløsninger for å finne den løsningen som passer best til dette formålet. Hardware har blitt implementert, og dette kommuniserer med både mobilapplikasjonen og eksterne systemer. Mobilapplikasjonen kommuniserer i dag med vårt testmiljø, i påvente av at Making Waves skal gå over til Office 365. Av effektmål ønsket vi å oppnå en mer effektiv bruk av møterom. Dette håper vi å se når mobilapplikasjonen etter hvert blir tatt i bruk. I videre utvikling av systemet ser vi for oss at sensorene får et 3D-printet deksel som skjuler komponentene den består av. Vi har fått laget en 3D-modellering av et slikt deksel som skisse for hvordan dette kan se ut. Et par skjermbilder av denne modellen kan sees i vedlegg 12. For fremtidige utviklere av systemet er dataen som sensorene detekterer lett tilgjengelig for andre plattformer som iOS og Windows Phone. 46 Prosessrapport Bookingsystem for Making Waves Snorri Engen – s188094 Mathias Faanes Olsen – s188066 47 Sammendrag Etter en kort intervjurunde ble denne oppgaven tildelt oss fra Making Waves. Vi fikk en veileder etter at vi hadde fått klarsignal fra MW om at de ønsket oss som gruppe. Dette skjedde november-desember 2014. Kort tid etter dette begynte vi med å løse oppgaven i dette hovedprosjektet. Ettersom dette prosjektet besto av mye nytt var det vanskelig å beregne tid. Vi gjorde likevel et forsøk på å forholde oss til 14-dagers planer med inndelte oppgaver som man skulle gjøre i løpet av disse to ukene. Hvordan dette fungerte og hvordan samarbeidet i gruppa har vært kan det leses videre om i prosessrapporten. Innholdsfortegnelse Sammendrag .............................................................................................................................. 47 Innledning ................................................................................................................................... 48 Om gruppen ................................................................................................................................ 49 Om bedriften .............................................................................................................................. 49 Planlegging og Metode ........................................................................................................... 49 Verktøy ......................................................................................................................................... 51 Utfordringer ............................................................................................................................... 51 Utvikling av Applikasjonen................................................................................................... 51 Samarbeid ................................................................................................................................... 51 Veiledning ................................................................................................................................... 52 Konklusjon .................................................................................................................................. 52 48 Innledning Prosessrapporten består av informasjon om hvordan vi har arbeidet med hovedprosjektsoppgaven. Her vil det også forekomme opplysninger om bachelorgruppen, om bedriften vi utvikler produktet for, planlegging og metode. Om gruppen Gruppen som har jobbet med dette prosjektet består av Mathias Faanes Olsen og Snorri Engen. Vi studerer begge Ingeniørfag Data v/ Høgskolen i Oslo og Akershus. Vi sendte ut søknader til flere bedrifter tidlig høsten 2014 om at vi hadde et ønske om å skrive bachelor for deres bedrift. 24. oktober mottok vi en e-post fra Making Waves om at de ønsket å ha et intervju med oss hvor vi ville diskutere den potensielle oppgaven. Det var flere som responderte på søknadene våre, men det var oppgaven hos Making Waves som appellerte mest. 14. november fikk vi bekreftet at vi hadde fått oppgaven og vi kunne sette i gang med undersøkingen. Vi har arbeidet i gruppe sammen flere ganger tidligere de siste årene i løpet av utdannelsen vår. Vi kjenner derfor godt til både hverandres sterke og svake sider. Gruppen har fått utfordret seg veldig mye i arbeidet med dette prosjektet når det kommer til nye felt og systemer, men vi har samtidig fått nytte av mange av de emnene vi har hatt opp gjennom den 3årige utdannelsen vår. Om bedriften Making Waves (MW) er eksperter på digital tjenesteutvikling og innovasjon. MW har avdelinger for rådgivning, design, teknologi, innholdsproduksjon og drift. MW er en digital innovasjonspartner for mange av Nordens største merkevarer og offentlige virksomheter. Blant deres kunder finner man Regjeringen, NorgesGruppen, NSB, Norrønna og Sparebank 1 Forsikring. MW spesialiserer seg på gode brukerløsninger og god design. Making Waves har kontorer både i Oslo og Krakow og åpnet nettopp i desember 2014 kontorer i Stockholm også. Figur: Making Waves - Logo 49 Planlegging og Metode Utviklingsmodell Vi ønsket tidlig å benytte oss av en form for utviklingsmodell, men innså ganske raskt at Fossefall eller Scrum ikke ville fungere så bra ettersom vi beveget oss stort sett i ukjent terreng. Derfor ble tidsestimeringen en vanskelig oppgave. Vi bestemte oss for å ha dele prosjektet opp i 3 isolerte faser. Når vi sa oss ferdig med den ene, kunne vi bruke informasjonen vi lærte i denne i neste fase av prosjektet. Vi hadde samtidig noen 14-dagersplaner som vi kontinuerlig oppdaterte for å se hva vi skulle jobbe med videre og hva som var blitt gjort i Produkt Hardware Applikasjonsutvikling Reasearch Figur: Fasene i vår utviklingsmodell denne fasen av prosjektet. Vi har valgt å kalle denne metoden for «Tripp-trapp-modellen». Hvert trinn er isolert, men samtidig så bygger de på hverandre til å skape et helhetlig resultat tilslutt. I 14-dagersplanene tok vi for oss innhenting av informasjon, testing, implementasjon og dokumentasjon for hver deloppgave vi skulle implementerte. 50 Verktøy Android Studio – Plattform for utvikling av android-applikasjoner Xamarin Studio – Plattform for utvikling av kryssplatform-applikasjoner FileZilla – Program for tilkobling til og bruk av FTP Sublime Text 2 – Program for utvikling av mindre kodesnutter (PHP, JavaScript, Python, C, HTML, CSS) Word – Tekstbehandlingsprogram for dokumentasjon Google Drive – Overføring av filer mellom gruppemedlemmer Google Docs – Nettleserbasert redigering av dokumentasjon på en åpen plattform. Google Sheet – Nettleserbasert regneark Dropbox – Skybasert lagringstjeneste Slack – Nettleserbasert kommunikasjonsverktøy mellom deltakere og kontaktperson i MW. Balsamiq – Wireframe/Mockup/Prototypingsverktøy for visualisering. Raspbian 3.18 – Operativsystem på Raspberry Pi som utfører alle oppgaver den skal gjøre. www.spark.io/build – Utviklingsplattformen for spark.io-løsningene. Utfordringer Kravspesifikasjonen fra oppdragsgiver for denne oppgaven var veldig åpen. En kombinasjon av dette og at mye var helt nytt for gruppemedlemmene medførte til at mye måtte testes ut før vi falt for en løsning som vi var fornøyd med. Dette gjaldt spesielt hvilken hardware-plattform vi skulle gå for og kommunikasjonen med MW sitt system. Mye tid gikk bort på dette, men vi ser ikke på dette som bortkastet ettersom vi fikk mye viktig læring på forskjellige områder. I tillegg til dette ble tidsestimering et problem, men vi føler vi fikk kontroll da vi benyttet oss av vår utviklingsmodell. Utvikling av Applikasjonen Utviklingen av selve applikasjonen har vært spennende. Vi har fått benyttet oss av læring vi har hatt fra emner som applikasjonsutvikling, systemutvikling, databaser og sikkerhet fra HiOA. Vi har fått en dypere forståelse for applikasjonsutvikling og hvordan man skal kommunisere med fysiske objekter/sensorer fra en digital plattform. Vi har måtte fokusere mer på brukeropplevelse og personvern enn tidligere, ettersom sluttproduktet er noe de ansatte hos MW skal bruke i sin arbeidshverdag. Samarbeid Som nevnt tidligere, så kjenner vi hverandre godt fra før. Vi har jobbet sammen på prosjekter tidligere og vet hvordan vi jobber best. Vi begynte tidlig i prosjektprosessen med daglige møter både på kontorplassene vi hadde fått utdelt hos MW, men også på skolen, hvor vi drøftet løsninger og designvalg for applikasjonen. Dette foregikk gjennom hele de to første fasene av prosjektet hvor vi planla og utviklet hardware/den fysiske biten av prosjektet. Da vi beveget oss over i den avsluttende fasen gikk vi over til å jobbe mer selvstendig ettersom dette var mer kjent for oss. Vi snakket fremdeles sammen daglig over e-post, tekstmeldinger og Slack. 51 Begge gruppemedlemmer har fått tatt del i alle aspekter av prosjektet og har derfor fått maksimal læringsutbytte. Kommunikasjonen har vært god og vi har vært hyppige med å gi hverandre tilbakemeldinger og innspill på hvordan vi føler ting kunne vært gjort annerledes eller om oppgaver er blitt godt utført. Veiledning Intern veileder Vi har hatt høgskolelektor Torunn Gjester som vår interne veileder fra Høgskolen i Oslo og Akershus. Det har vært ukentlige møter hver tirsdag med Torunn. I disse møtene har vi hatt samtaler om hva vi har arbeidet med de siste ukene, hva vi burde fokusere på fremover og fått tips til hvordan vi skal gå frem med dokumentasjonen i forhold til prosjektprosessen. Vi forsøkte tidlig i prosessen å lage 14-dagersplaner for vår veileder slik at hun kunne være litt oppdatert på hva vi gjorde, men ettersom disse var i konstant endring falt disse litt bort. Disse møtene har vært til stor hjelp hva det gjelder input og Torunn som støttespiller i denne prosjektperioden. Ekstern veileder Making Waves utnevnte Kristoffer Sundmyhr som vår kontaktperson i bedriften. Kristoffer jobber som front-end utvikler og har jobbet i MW snart 2 år. Hver mandag har det vært møter med Kristoffer hvor vi har gått gjennom hva vi har gjort og hva som ligger foran oss. Denne applikasjonen er dypt inne i back-endmiljøer, og vi fikk derfor ikke benyttet oss så mye av Kristoffer sin ekspertise hva det gjelder utviklingen, men han kom med mye innspill på prosjektprosessen ettersom han jobber i prosjekter til daglig. Konklusjon Prosessen med å jobbe med dette produktet har vært veldig lærerikt for oss. Vi har lært mye faglig sett, om systemutvikling, programmering, applikasjonsutvikling og sikkerhet. Vi har lært en del om det å arbeide tett sammen om et prosjekt over lang tid og vi har lært noe om hverandre. Bortsett fra det rent faglige, så er det å ha erfaring med prosjektoppgaver helt klart det viktigste vi tar med oss etter å ha ferdigstilt dette produktet. Det å arbeide systematisk og å planlegge godt i forveien er gull verdt. Vi tar med oss ny lærdom om maskinvare og hvordan dette kommuniserer med digitale komponenter som vi utvikler selv. Det har dessuten vært veldig interessant å ha en oppdragsgiver som gir oss en oppgave med spesifikke krav som vi må tilfredsstille. Vi er stolte over produktet vi har laget og gleder oss til å se det i bruk hos Making Waves i tiden som kommer. 52 Kilder og lenker Internett [1]: http://www.gartner.com/newsroom/id/2636073 [2]: http://products.office.com/nb-no/try [3]: https://manage.windowsazure.com/ [4]: http://www.techspot.com/news/57228-google-shows-off-new-version-ofandroid-announces-1-billion-active-monthly-users.html Følgende ble brukt som oppslagsverk gjennom hele perioden: URL: http://www.w3schools.com/ URL: http://developer.android.com URL: https://hc.apache.org/ URL: https://community.particle.io/ URL: https://lowpowerlab.com/forum/ URL: https://github.com/OfficeDev/Office-365-SDK-for-Android URL: https://github.com/OfficeDev/O365-Android-Snippets 53 Vedlegg Vedlegg 1 Kravspesifikasjon Funksjonelle krav til applikasjonen fra Making Waves Brukernavn og passord skal settes i Office 365 Azure AD Gjenkjenne bruker etter første innlogging Bruker skal kunne logge ut Bruker skal kunne oppdatere sensordata Bruker skal ha oversikt over tilgjengelige rom Rom som allerede er booket, men uten aktivitet skal vises men ikke være mulig å booke. Booke møte gjennom Office 365 Bruker skal kunne kansellere møte Bruker skal kunne se hvor lenge det er igjen av møtet Utvide møtets varighet Er det booket et møte skal det ikke være mulig å booke et nytt uten å kansellere pågående møte Applikasjonen skal ha 3 skjermbilder inkludert “Logg inn” Funksjonelle krav til sensorsystem Sensor skal detektere bevegelser Sensor skal ha en rekkevidde på minimum 5 meter Systemet skal lagre sensordata på en database Sensor skal gå på batteri Sensor skal ikke være sjenerende Sensor skal gi synlig signal når bevegelse er oppdaget Systemet skal kunne benyttes av andre plattformer Funksjonelle krav til kommunikasjon med eksterne systemer Applikasjonen skal kommunisere med det nåværende bookingsystemet til Making Waves. Applikasjonen skal kunne hente ut møterom fra Exchange Online serveren til Making Waves. Pålogging skal fungere ved at brukere benytter seg av sin Office 365konto. 54 Personvern Sensordatabasen skal tømmes en gang i døgnet Det skal ikke lagres noe personopplysninger i MySQL databasen. Krav til kode Alle metoder skal kommenteres forståelig for andre utviklere Selvforklarende metode-navn Koden skal optimaliseres for videre utvikling All tekst skal lagres i strings.xml for enkel endring av språk Universell utforming Applikasjonen skal være lett forståelig Applikasjonen fungere med minimal brukerinteraksjon Applikasjonen skal ikke har unødvendig forstyrrende elementer Tilrettelagt for endring av språk. Tekniske krav Programmeringsspråk: Java, PHP, JavaScript, Python, C Markeringsspråk: Extensible Markup Language (XML) Databasekommunikasjon: MySQL, Exchange Online, Azure Active Directory Ikke-funksjonelle krav Prosjektet skal dokumenteres etter HiOA sine standarder Dokumentasjon skal være ferdig innen gitt tidsfrist Betaversjon av applikasjon skal være klar innen gitt tidsfrist Prosjektperioden skal følge milepælplanen 55 Vedlegg 2 Office 365 hovedportal 56 Vedlegg 3 Windows Azure Portal 57 Vedlegg 4 Figur av Administrasjonsportalen til Exchange 58 Vedlegg 5 Oversikt over rommene i Administrasjonsportalen til Exchange 59 Vedlegg 6 Hvordan opprette rom i Exchange 60 Vedlegg 7 Spørreundersøkelsen 61 62 Vedlegg 8 Svar på spørreundersøkelsen 63 64 65 66 Vedlegg 9 Tidlig skisse av applikasjonens hendelsesforløp 67 Vedlegg 10 Detaljert beskrivelse av Use-Case Use Case Aktør Prebetingelser Postbetingelser Hendelsesflyt Variasjoner Logg Inn Sluttbruker Bruker vil logge inn Bruker er logget inn 1. Bruker åpner applikasjonen 2. Bruker skriver inn epost og passord 3. Bruker trykker “login”-knappen 4. Epost og passord blir sjekket opp mot “credentials” som ligger i Office 365 Azure AD 5. Bruker blir logget inn i systemet 1. Bruker har glemt passord a. Bruker må kontakte systemansvarlig for reset av passord 2. Bruker fyller inn feil passord a. Bruker blir bedt om å fylle inn korrekt passord b. Bruker får forsøke på nytt 3. Bruker fyller inn feil e-post a. Bruker blir bedt om å fylle inn gyldig e-post b. Bruker får forsøke på nytt 4. Autentiseringssystem er nede a. Systemet gir feilmelding som vises på skjerm i applikasjon b. Bruker får forsøke på nytt 5. Bruker har ikke e-post eller brukernavn a. Bruker må kontakte systemansvarlig for å motta innloggingsinformasjon 6. Bruker trykker “avbryt”-knappen a. Bruker blir sendt tilbake til hovedside 68 Use Case Aktør Prebetingelser Postbetingelser Hendelsesflyt Variasjoner Use Case Aktør Prebetingelser Postbetingelser Hendelsesflyt Variasjoner Kansellere møte Sluttbruker Bruker vil avslutte møte Bruker har en gyldig booking pågående Bruker er innlogget Bruker er inne i applikasjonen Bruker har kansellert møtet 1. Bruker har “aktivt møte” -siden oppe 2. Bruker trykker “Avslutt møtet”-knappen 3. Møtet blir avsluttet 4. Rommet blir frigjort 5. Bruker blir sendt tilbake til “book rom” -side. 1. Systemfeil gjør at man ikke får avsluttet møte tidligere enn satt opp a. Bruker får feilmelding i applikasjon om at rommet ikke kan frigis tidligere pga feil i systemet. Utvide romreservasjon med 15 min Sluttbruker Bruker vil utvide tiden møte skal vare Bruker har gyldig booking pågående Bruker er innlogget Bruker er inne i applikasjonen Bruker har forlenget møtet sitt med 15 min 1. Bruker har “aktivt møte” -siden oppe 2. Bruker trykker på “+15”-knappen 3. Bruker får spørsmål om de vil utvide reservasjonen med 15 minutter 4. Bruker trykker “ok” 5. Varigheten til reservasjonen blir økt med 15 minutter 6. Bruker kommer tilbake til “aktivt møte” -siden 1. Andre har booket et møte i gjeldende tidspunkt a. Bruker får feilmelding med beskjed om at +15 ikke går ettersom det er opptatt. b. Bruker sendes tilbake til “aktivt møte” -side. c. Reservasjon blir ikke utvidet. 2. Bruker skal selv ha møte innen de neste 15 minuttene a. Bruker får feilmelding med beskjed om at +15 ikke går ettersom bruker har andre møter. b. Bruker sendes tilbake til “aktivt møte” -side c. Reservasjon blir ikke utvidet 69 Vedlegg 11 MIT-Lisensen Copyright (c) <year> <copyright holders> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 70 Vedlegg 12 3D-Modelleringer av deksel til romsensor 71
© Copyright 2024