BACHELORPROSJEKT. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1 PROSJEKT NR. 37 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL DATO Bravo Booking ANTALL SIDER / BILAG 78 sider / 1 (zippet kildekode) PROSJEKTDELTAKERE Joakim Hanssen Lund, s Johannes Strige, s Synne Storhaug, s INTERN VEILEDER Ismail Hassan Ismail.Hassan@hioa.no OPPDRAGSGIVER Bravo Solutions KONTAKTPERSON Lars Andrup-Næss lars@bravoso.no SAMMENDRAG Android og ios applikasjon for booking av møterom i små/mellomstore bedrifter. Hybridutviklet med Xamarin.Forms. Er Office 365 integret ved hjelp av Microsoft Graph API. 3 STIKKORD Xamarin Microsoft Graph API Office 365

2 Høgskolen i Oslo og Akershus Fakultet for Teknologi, Kunst og Design Hovedprosjekt i Informasjonsteknologi 2017 Bravo Booking Sluttrapport Gruppe 37: Joakim Hanssen Lund Johannes Strige Synne Storhaug Veileder: Ismail Hassen Oppdragsgiver: Bravo Solutions AS Kontaktperson: Lars Andrup-Næss

3 Innhold 1 Innledning 2 Prosessdokumentasjon 3 Produktdokumentasjon 4 Vedlegg - Kravspesifikasjon - Bruker- og adminveiledning - Ordliste - Referanseliste

4 Innledning Forord Denne rapporten inneholder all dokumentasjon av arbeidet til gruppe 37 ved bachelorprosjektet i Informasjonsteknologi, ved Høgskolen i Oslo og Akershus, våren Vi takker Bravo Solutions og var kontaktperson Lars Andrup-Næss, for samarbeidet rundt dette prosjektet. Leserveiledning Sluttrapporten inneholder prosessdokumentasjon og prosjektdokumentasjon, samt andre vedlegg vedrørende prosjektet. Det anbefales å lese de ulike dokumentene i den rekkefølgen vi har lagt dem i for å få bedre forståelse for prosjektet. Prosessdokumentasjonen er første del av sluttraporten og skal formidle hvordan gruppen har arbeidet med oppgaven. Produktdokumentasjonen er andre del av sluttrapporten og skal beskrive sluttproduktets funksjonalitet og virkemåte. Vedlegg som kravspesifikasjon, bruker- og adminveiledning, ordliste og litteraturliste er også inkludert.

5 Høgskolen i Oslo og Akershus Fakultet for Teknologi, Kunst og Design Hovedprosjekt i Informasjonsteknologi 2017 Gruppe 37 Prosessdokumentasjon

6 Prosessdokumentasjon 1 Forord I prosessdokumentasjonen ønsker vi å gi et bilde av måten gruppen vår gjennomførte arbeidet med hovedprosjektet på. Her beskriver vi viktige valg vi har tatt, hva vi har tatt hensyn til og hvilke utfordringer det har bydd på. Dokumentasjonen er skrevet på en slik måte at det forutsettes en viss teknisk kompetanse hos leseren. Vi gir likevel forklaringer der vi føler det nødvendig, og har lagt ved en teknisk ordbok. Prosessdokumentasjon består av fem hoveddeler: Innledning - presenterer essensiell informasjon om valg av oppdragsgiver, oppgave og bakgrunn for oppgaven. Planlegging og metode - består av beskrivelse av forarbeid og planlegging rundt prosjektet. Inneholder blant annet beskrivelse på hva vi har tatt hensyn til med tanke på valg av teknologier, programmeringsspråk, utviklingsmiljø og utviklingsmetodikk. Utviklingsprosessen - beskriver utviklingsfasene i detalj, og hva som har blitt foretatt av hver av dem. Kravspesifikasjonen - beskriver vi hvordan vi har forholdt oss til kravspesifikasjonen og dens rolle i prosjektet vårt. Avslutning - inneholder drøfting av gruppens utbytte gjennom arbeidet med prosjektet. 1

7 Prosessdokumentasjon Innhold 1 Forord 1 2 Innledning Presentasjon Gruppe Oppdragsgiver Kontaktpersoner Dagens situasjon Vårt prosjekt Målgruppe 6 3 Planlegging og metode Valg av teknologi Xamarin Microsoft Graph API Azure AD MacinCloud Programmeringsspråk Integrert utviklingsmiljø (IDE) Utviklingsmetodikk Smidig metodikk Verktøy Trello Slack Google Drive & Docs GitHub Arbeidsprosess Arbeidssted Møter Fremdriftsplan Prosjektdagbok Valgfag og motivasjon 14 4 Utviklingsprosessen Pre-fase Startfase MVVM arkitektur Dropper web-løsning, fokuserer på ios og Android Xamarin.Android og Xamarin.iOS Kunnskap og læring Utviklingsfase

8 Prosessdokumentasjon Xamarin.Forms Azure og API Logg inn funksjonen Modeller Utviklingsfase Utfordringer med API rettigheter Spørringer til APIet Mal for oppsett Office 365 Rom Avsluttende fase Kalender Testing Dokumentering Design Fargevalg og logo Universell utforming Informasjonsarkitektur 21 5 Kravspesifikasjon Prioriterte oppgaver Endring i kravspesifikasjonen Ikke implementert Konklusjon 24 6 Avslutning Sluttproduktet Arbeidsfordeling og samarbeid Oppdragsgiver Læringsutbytte Hva kunne vi gjort annerledes Hva er vi stolte av Konklusjon Ord fra oppdragsgiver 26 3

9 Prosessdokumentasjon 2 Innledning 2.1 Presentasjon Oppdragsgiver Prosjekttittel Oppgave Bravo Solutions AS Bravo Booking Målet med prosjektet er å utvikle en applikasjon for enkel og rask booking av møterom innad i en bedrift. Periode Gruppenummer 37 Gruppemedlemmer Joakim Hanssen Lund s Johannes Strige s Synne Storhaug s Intern veileder Nettside Ismail Hassan Gruppe 37 Gruppen består av Joakim Hanssen Lund, Johannes Strige og Synne Storhaug. Alle er studenter ved HiOA, og går siste semester ved bachelorstudiet i Informasjonsteknologi. Gjennom snart 3 år har vi jobbet på gruppe flere ganger, og vi ønsket derfor å danne en gruppe sammen ved hovedprosjektet også. Vi kjenner hverandres sterke og mindre sterke sider, og utgjør dermed et godt team. 2.3 Oppdragsgiver Dette prosjektet utføres i samarbeid med Bravo Solutions og søsterselskapet Bravo Audiovisual. Bravo Solutions AS er en ung leverandør av skytjenester med fokus på fleksible og moderne IT-løsninger for digitalisering av bedrifters arbeidshverdag. Bravo Solutions jobber mye med Office 365 og Azure. De har stort fokus på at kundenes medarbeidere skal få nødvendig opplæring og motivasjon for å ta i bruk ny teknologi. Solutions leverer 4

10 Prosessdokumentasjon komplette IT-løsninger og fungerer som en one-stop shop for både hardware, software og support. 2.4 Kontaktpersoner Veileder ved HiOA Ismail Hassan Tlf: Kontaktperson ved Bravo Solutions AS Lars Andrup-Næss lars@bravoso.no Tlf: Dagens situasjon I dagens samfunn ser vi i stadig større grad utvikling av apper som løser og holder orden på hverdagslige gjøremål, både på jobb og hos den enkelte privatperson. Innad i bedrifter er det stor etterspørsel etter gode verktøy som forenkler dagligdagse gjøremål. Hos Bravo er dette også tilfellet. Bravo og flere av deres kunder bruker i dag en Outlook/Office 365 kalender løsning for booking av møterom. Dette ser vi at også mange andre bedrifter gjør. Det dreier seg om å invitere møterommet (som har en egen mailkonto ) inn i kalenderen, der møterommet (eller admin av det) aksepterer i kalenderen om rommet er ledig for det gitte tidspunktet. Det var her ideen fikk sitt utspring. Hva hvis Bravo kunne tilby sine ansatte, samarbeidspartnere og kunder, en lettere og mer effektiv måte å booke møterom på. Effektiv møteromsbooking er noe stort sett alle bedrifter har nytte av, uavhengig av størrelse eller antall ansatte. Det finnes allerede flere eksempler på slike web-apper blant andre Office 365, Teem, Skedda. Flere av disse inneholder en rekke avanserte funksjonaliteter som kan virke tungvint for brukere som kun skal bruke det til et enkelt formål, altså booke et møterom. Det enkle er ofte det beste. I tillegg jobber Bravo aller mest mot SMB markedet og her kan det fort virke lite interessant å bruke midler på avanserte systemer for booking av møterom når Det vi har i dag fungerer. Dermed valgte vi å gå for en enklere løsning med simplisitet i fokus. Som studenter ved HiOA, har også vi støtt bort i sammenhenger hvor det hadde vært gunstig med en effektiv måte å få booket gruppe- og møterom på. HiOAs løsning er faktisk et godt eksempel på hvor tungvint det kan være for å få utført en simpel oppgave. Løsningen gjør det den skal, men har etter vårt syn også mange ekstra funksjoner som gjør det vanskeligere å sjekke hvilke rom som er ledige og booke et av dem. Vi kan derfor se for oss HiOA og andre skoler som potensielle målgrupper for et ferdig utviklet produkt. Vi har også gjort noe kvalitativ research i form av å snakke med kolleger, venner, familie og andre studenter om hvordan de syntes booking av møterom fungerer på deres jobb eller skole. Her fikk vi også motivasjon og bekreftelse på at løsningen vår virkelig kan være noe folk ønsker seg særlig i form av simplifisert møteromsbooking. 5

11 Prosessdokumentasjon 2.6 Vårt prosjekt Prosjektet handler om utviklingen av en app til booking av møterom. Dette er en løsning som Bravo Solutions og søster-bedriften Bravo Audiovisual har sett etter for å kunne etablere seg som forhandler av, men som det muligens vil være mer gunstig å kunne levere selvstendig. Det er her vi og vårt bachelorprosjekt kommer inn, oppgaven er å lage en app hvor man kan se hvilke av bedriftens møterom som er opptatt og booke et ledig rom. Helt i begynnelsen hadde vi tenkt at prosjektet først og fremst skulle være en webapp, og om mulig ved hybrid utvikling også en ios og Android app. Etter et møte med Bravo, kom vi sammen frem til at vi heller skulle fokusere på å utvikle app-løsningen da web delen av appen allerede eksisterer. Dette ettersom vi bygger appen på Office 365/Microsoft Graph API (Application Programming Interface), og Office online med (Outlook) kalenderen vil dermed fungere som webgrensesnitt. På grunn av dette er det gjort store endringer i applikasjonen fra forprosjektet til slutten av prosjektet. 2.7 Målgruppe Helt i starten av prosjektet var tanken å fokusere på de litt mindre bedriftene, ettersom vi prøvde å begrense omfanget av oppgaven og ikke ta på oss for mye arbeid. Dette med tanke på tidsperspektivet, og det faktum at det var mye ny teknologi å sette seg inn i. Om vi skulle utvikle appen med fokus på større bedrifter kreves det gjerne mer omfattende arbeid. Det kan tenkes at de store bedriftene har andre krav til en slik applikasjon enn de små bedriftene. Etter et møte med Bravo kom vi derimot frem til at vi ikke burde avgrense til de mindre bedriftene, men ha like mye fokus på store bedrifter. Ettersom det er her det er størst behov for en effektiv måte å booke og holde styr på alle møterommene. Små bedrifter har gjerne færre møterom å velge mellom. Noen bedrifter nøyer seg også med å si ifra til kollegaer om at man skal ha møte på et visst møterom på et gitt tidspunkt, siden de ikke har råd eller ønske om å prioritere en digital løsning for dette. Det kan også tenkes at små bedrifter holder de fleste møter hos kundene og samarbeidspartnerne sine, og dermed ikke har like stort behov for et slikt system. Store bedrifter har som oftest flere møterom, gjerne på ulike lokasjoner om arbeidsplassen består av flere bygg. De har gjerne flere kunder og samarbeidspartnere de gjerne skulle hatt mulighet til å booke rom sammen med eller for. Da er det ikke like lett å tilfeldig finne et ledig møterom, eller avtale med de andre i bedriften når hvem skal ha hvilket rom. Med større bedrifter kommer det også flere ansatte, flere møterom, flere kunder, større møterom, møterom med flere ulike løsninger/utstyr osv. Det lønner seg da å ha en oversiktlig måte å holde orden på hvilke rom som er ledig og opptatt. Derfor har vi valgt å utvikle applikasjonen med hensyn på både små og store bedrifter. Med det mener vi at vi kommer til å ha hovedfokus på små/mellomstore bedrifter, og setter ulike begrensninger på applikasjonens funksjonalitet ut i fra disse. Samt ha større bedrifter i 6

12 Prosessdokumentasjon bakhodet, og legge til rette for at det skal være lett å tilpasse applikasjonen slik at den passer den enkelte bedrift. Data om møterommene som er registrert hos bedriftene henter vi fra Office 365 via APIet. 3 Planlegging og metode 3.1 Valg av teknologi Valg av de ulike teknologiene er tatt med tanke på hvilke teknologier som vil gjøre det lettere å utvikle applikasjonen og utgi den på de plattformene vi og Bravo ønsker. Samt hvilke teknologier som vil gjøre applikasjonen mest mulig effektiv, skalerbar og relevant. Det at vi får mulighet til å lære oss nye teknologier som kan være relevante i fremtidige arbeidssituasjoner er også med på å avgjøre valgene av teknologier. Det forelå ingen krav om hvilke teknologier vi skulle benytte verken fra oppdragsgiver eller HiOA, men vi har blant annet tatt i bruk Microsoft Graph API etter tips fra Bravo Xamarin Vi hadde som mål om å utvikle en løsning som er mulig å utgi på de to mest brukte mobilplattformene; ios og Android. Det finnes flere teknologier som gjør dette mulig, blant annet NativeScript og Xamarin. De gjør det imidlertid på ulike måter. NativeScript bruker Angular, TypeScript eller moderne JavaScript for å lage effektive native brukergrensesnitt. På denne måten kan man dele kodebase med en webapplikasjon. Man kan også bruke en god del av tidligere erfaring fra utvikling av webapplikasjoner, dersom man har det. Xamarin bruker felles C# kodebase, slik kan utviklere bruke Xamarin-verktøy til å hybrid utvikle Android-, ios- og Windows-apper med native brukergrensesnitt og dele kode på tvers av flere plattformer. Vi ble anbefalt å bruke Xamarin av flere bekjente. Samtidig har vi sett på andre eksempler/applikasjoner som er utviklet med Xamarin. Begge teknologiene tillater moderne hybrid-native utvikling, uten å benytte seg av den eldre metoden med for hybrid utvikling. Nemlig å bruke WebViews, her bruker man web teknologier (HTML, CSS, JavaScript) for å utvikle noe som ser ut som en app men fungerer til dels likt som en nettside. Etter research og diskusjoner om hva vi skulle bruke, ble vi til slutt enige om å gå får Xamarin ettersom vi har mer kjennskap til C# enn JavaScript. Vi tenkte det var smart å ta i bruk en teknologi der programmeringsspråket som anvendes var godt kjent blant gruppemedlemmene fra før. Slik at det ikke blir for mye nytt å sette seg inn i Microsoft Graph API Vi hadde først sett for oss at importering av nødvendig informasjon angående møterommene til de ulike bedriftene skulle skje via et Excel dokument hvor en ansvarlig i bedriften skulle føre inn møterommene. Excel dokumentet skulle importeres til appen (databasen), slik at vi i lett kunne få nødvendig informasjon om møterommene; navn, utstyr, kapasitet osv. Planen var også å bruke Microsofts skybaserte database; Microsoft Azure SQL Database, til håndtering av databaser og lagring av data. Bravo anbefalte oss å heller ta i bruk et API, slik at vi lett kunne hente ut den informasjonen vi trengte om møterom i bedriftene. Dette 7

13 Prosessdokumentasjon forutsetter at bedriftene har tatt i bruk Office 365 og registrert møterommene, da det er her vi henter denne informasjonen fra. Ved å ta i bruk APIet slapp vi altså å opprette vår egen database (Azure SQL Database) og importering fra Excell. Vi fant ut at Microsoft Graph API gir oss tilgang til brukerens Office 365 kontakter og kalendere, samt annen data vi trenger til applikasjonens funksjonalitet. Microsoft Graph ble et naturlig valg ettersom Microsoft har begynt å fase ut det tidligere brukte alternativet Azure AD Graph API. Appen blir på denne måten integrert med bedriftens (forhåpentligvis) allerede eksisterende Azure AD og Office 365 løsning. Grunnen til at vi bestemte oss for å bruke dette APIet var altså fordi det effektiviserer utviklingen og applikasjonen. Dette gjør at bedrifter kan bruke systemet de muligens har fra før av (Office 365) for booking av møterom, på en enklere og mer effektiv måte. Det er altså ingen behov for store prosesser med å bytte løsning eller omfattende opplæring. Ansatte trenger bare å laste ned Appen og den vil fungere mot det allerede eksisterende systemet og deres kalendere. Selv om APIet gjør disse tingene enklere for oss og for appen var dette en helt ny teknologi for alle på gruppen, og krevde dermed en del research og opplæring. Det kan være en tidkrevende prosess å sette seg inn i nye teknologier, men vi tenkte at utbytte av å beherske dette APIet ville være nyttig for oss i fremtidige prosjekter. Når læringsprosessen er over vil vi ha et effektivt verktøy i form av APIet, som vi kan bruke til å gjøre operasjoner som ellers ville krevd timer med utvikling Azure AD Ettersom vi tok i bruk Microsoft Graph API som kan sees på som et API til Azure AD, måtte vi naturligvis også bruke Azure AD. Innstillingene vi gjør i Azure AD gir oss mulighet til å bruke APIet på rett måte. Vi måtte også registrere applikasjonen i Azure AD for å kunne bruke Microsofts globale innloggingstjeneste (login.microsoftonline.com) MacinCloud Siden vi hybrid utvikler applikasjonen må vi kunne teste applikasjonen på begge plattformene. Samtidig må vi gjøre enkle endringer i GUIen (Grafisk brukergrensesnitt) / Viewet, fra Android til ios. For å gjøre dette må vi kjøre en virtuell iphone på en Mac som er koblet opp mot Visual Studio. Ettersom ingen på gruppen hadde en Mac fikk vi tilgang på en MacinCloud bruker fra HiOA. MacinCloud fungerer som en skybasert Mac, hvor vi kan koble oss på med eksternt skrivebord fra vår egen PC. Dette gjør det mulig for oss å utvikle en ios applikasjon selv om vi ikke har en fysisk Mac maskin. 3.2 Programmeringsspråk Når det gjelder programmeringsspråk er det lurt å velge et språk man har litt erfaring med og føler seg komfortabel med ettersom hele prosjektet baseres på dette. Om man velger et språk man ikke har erfaring med, vil en god del av tiden gå med til å lære seg dette språket. For oss ble det naturlig å velge C# av mange grunner. C# er et objektorientert språk utviklet av Microsoft, og er basert på Java, et programmeringsspråk alle på gruppa er godt kjent 8

14 Prosessdokumentasjon med. I tillegg hadde vi et fag forrige semester hvor vi brukte C#, og føler dermed at vi har nok erfaring for å basere hovedprosjektet vårt på dette programmeringsspråket. Visual Studio støtter C#, og blir ofte brukt sammen. Dette er fordi Microsoft utviklet C# som en del av.net. C# er også mye brukt for applikasjoner ettersom det er spesielt designet for å kunne brukes på mange forskjellige plattformer. Dette er antagelig også grunnen til at Xamarin tar i bruk C# som språket for applikasjoner. Det at Xamarin bruker C# er nok den største grunnen til at vi valgte å bruke C#, man kan altså si at vi valgte programmeringsspråk på bakgrunn av teknologiene vi bruker (Xamarin, Microsoft Graph API). I tillegg til C#, bruker vi XAML (Extensible Application Markup Language) som også er utviklet av Microsoft. XAML er en deklarativ versjon av XML (Extensible Markup Language) og er språket bak den visuelle representasjonen av programmet vi utvikler. Det vil si brukergrensesnittet/frontend. XAML er den mest brukte løsningen for å lage et brukergrensesnitt i Xamarin.Forms, og passer spesielt bra for applikasjoner som bruker MVVM arkitektur. 3.3 Integrert utviklingsmiljø (IDE) I og med at vi skal utvikle applikasjonen i C# med Xamarin ble Microsoft Visual Studio et naturlig valg av utviklingsmiljø. Visual studio er et av to alternativer hvor man kan utvikle applikasjoner med Xamarin. Den andre er Xamarin studio, som etter Microsofts oppkjøp av Xamarin fases ut. Det var dermed et enkelt valg for oss da alle gruppemedlemmene også har utviklet prosjekter i VS før, da i versjon Under arbeidet med hovedprosjektet ble det publisert en ny versjon 2017, som vi tok i bruk underveis. Visual studio har også gode muligheter for å kjøre emulator for både Android og ios, noe man må gjøre for å teste og se hvordan designet på applikasjonen ser ut når man utvikler mobile apper med Xamarin. 3.4 Utviklingsmetodikk Det var opp til oss å velge hvilken metodikk vi ville arbeide etter. Det eneste vi visste fra begynnelsen av var at vi ikke ville benytte oss av fossefallsmetoden ettersom den setter strengere krav om en fastsatt (statisk) kravspesifikasjon. Vi ønsket en mer flytende utviklingsmetodikk som ville passe bedre for utviklere uten mye erfaring med rigide metoder. Vi hadde heller ikke mye erfaring med den tradisjonelle måten å bruke Scrum eller Kanban på Smidig metodikk Ettersom vi var med på å utbedre deler av oppdragsgivers kravspesifikasjon var den ikke veldig rigid. Det var altså godt mulig for oss å velge en smidig utviklingsmetodikk. På denne måten var det mulig for å oss ta utviklingsrelaterte besluttninger underveis samt at Bravo kunne komme med nærmere spesifiserte krav. I tillegg er dette et utviklingsmetodisk prinsipp nært måten vi er vant med å jobbe på. 9

15 Prosessdokumentasjon Smidig utvikling handler om fleksibilitet og tar ofte i bruk raske iterasjoner. Kanban er en metode innenfor smidig utvikling, som bygger på kontinuerlig forbedring og fokuserer på forholdet mellom arbeidsmengde og mengden av tilgjengelig arbeidskraft. Her vurderes det hele tiden hva som er viktigst å implementere for at programmet skal kunne bli levert så fort som mulig. I hver inkrementasjon bygges det en ny funksjon som blir analysert og testet, om det trengs endringer legges de til i en ny iterasjon. En etter en legger man til nye funksjoner på denne måten. Og gradvis bygger man på dem slik at de matcher kravet som stilles til funksjonaliteten. Det er viktig å hele tiden ha et program som fungerer, slik at man har noe å levere når tiden renner ut. Man kaster ikke bort tid på unødvendige funksjonaliteter. Ettersom det legges vekt på kun nødvendige funksjoner for å kunne levere så raskt som mulig. 3.5 Verktøy Når man jobber på prosjekt av denne størrelsen med flere gruppemedlemmer, kan det være lurt å benytte seg av ulike verktøy for å forenklere og effektivisere kommunikasjon, dokumentasjon, versjonskontroll og sikkerhetskopiering/backup. Her vil vi begrunne hvorfor vi har valgt de ulike verktøyene Trello Under større utviklingsprosjekter med flere utviklere, kan det være smart å ta i bruk verktøy som forenkler organisering og fordeling av alle de ulike oppgavene som må utføres. Trello er et slikt verktøy som kan gi oversikt og organisere både forarbeid, implementering og dokumentasjon vedrørende prosjektet. Fra det store bildet og helt ned til minste detalj. Trello kan ansees som en digital versjon av den gamle tavla med post-it lapper ofte brukt med smidig metodikk i tidligere år. I og med at Trello er digital, er den enklere å bruke for utviklere som ikke sitter på samme lokasjon hele tiden. Samt at man kan legge inn sjekklister og vedlegg på hvert kort (post-it lapp). Trello har også god funksjonalitet for sammenkobling med Slack for å sømløst sende meldinger om oppgaver. Man har også lett tilgjengelig historikk og arkiv oversikt over oppgaver som allerede er utført. Dette er god praksis å kunne ved utviklingsprosjekter og det er nyttig å ha god kjennskap til slike verktøy i fremtidige arbeidssituasjoner. Vi ble etter noe research enige om at Trello ville være et godt verktøy for oss å bruke og vi følte at vi trengte et Product management verktøy. Den overordnede hensikten med å bruke Trello er å få en oversikt over hvem som har blitt tildelt de ulike oppgavene, tidsfrister for de, hvilke av de som er kritiske/(haster minst eller mest). Å kunne fordele arbeidet mellom gruppemedlemmene og å ha oversikt over hva hver enkelt person jobber med har gjort samarbeidet lettere. Dette gjorde arbeidet mer effektivt ettersom alle har tidsfrister å forholde seg til, og gruppemedlemmene kan jobbe selvstendig med de oppgavene som er tildelt en selv. 10

16 Prosessdokumentasjon Figur 1: Utklipp fra programmeringstavlen i Trello. Her har vi markert kortene på tavlen med ulike farger for å indikere hvilke del av utviklingen de hører til. Gule kort tilhører frontend, mens kort med rød farge tilhører backend Slack Når man jobber med et slikt prosjekt i et team er kommunikasjon mellom gruppen en viktig faktor for å få best mulig resultat. Ved tidligere prosjekter hvor vi har vært samme gruppe, har vi nøyd oss med å kommunisere via facebook chat (eller muntlig) ettersom dette er en plattform de fleste sjekker jevnlig, og man får varsler om nye meldinger. Likevel er ikke facebook helt optimalt ettersom det også blir brukt til sosial prat, og derfor er det lett å bli distrahert. Facebooks chat mangler også en del funksjonaliteter som vi ønsket ved en kommunikasjonsløsning. På grunnlag av dette valgte vi å ta i bruk et annet kommunikasjonsmiddel til vårt bachelorprosjekt. Siden vi allerede hadde vurdert å bruke Trello og Github, synes vi det var mest praktisk å velge et kommunikasjonsverktøy som kan kobles opp mot løsninger vi allerede bruker. Slack er et kommukiasjonsmiddel som gir mulighet til å koble til andre løsninger ofte brukt i utvikling som GitHub og Trello. I begynnelsen brukte vi det mest til å dele linker til ulike ressurser og markere/highlighte informasjonen vi brukte hyppig. Vi koblet Trello og Slack sammen, slik at vi får varsler på Slack når ulike gjøremål i Trello er gjennomført. Dermed kunne vi følge med når en ny brukerhistorie ble lagt til backloggen, eller hvis et gruppemedlem var blitt ferdig med en oppgave (flyttet fra in progress til done). Vi koblet også Slack sammen med GitHub, slik at man får varsler når noe blir commitet eller noen ber om merge. Dette ga oss en god oversikt over oppgaver eller funksjoner som ble utført eller lagt til. De gangene vi ikke satt sammen og jobbet kunne vi dermed lett få beskjed når noen hadde gjort en endring en annen ventet på. Dette er kanskje spesielt nyttig for team som ikke sitter sammen eller kanskje jobber i forskjellige tidssoner. 11

17 Prosessdokumentasjon Med slack og github koblet sammen hadde vi også en god og oversiktlig liste over hva som var gjort i det siste. Denne listen er som alle andre Slack kanaler søkbar og mulig å pinne innlegg i. Figur 2: Bilde av GitHub kanalen i Slack I utgangspunktet var vi ikke så kjent med verktøyene Trello og Slack, dermed satt vi mye sammen og arbeidet i begynnelsen av prosjektet og Slack ble mest brukt til å dele ressurser. Etterhvert ble arbeidsoppgavene tydeligere og vi delte dem mer opp, noe som gjorde det mulig for oss å jobbe mer selvstendig og fra forskjellige steder. Da ble det mer aktuelt å bruke disse verktøyene flittig og vi har absolutt sett nyttigheten med dette. Det har gjort det enklere å samarbeide om jobben til tross for at vi av og til ikke har jobbet på samme sted Google Drive & Docs En stor del av dette utviklingsprosjektet er å dokumentere arbeidsprosessen og produktet. Dette har vi valgt å gjøre i Google Docs som tillater sanntidsredigering for alle gruppemedlemmene i samme dokument. Ved hjelp av dette tekstbehandlingsprogrammet har alle hatt mulighet til å jobbe med dokumentering underveis og samtidig. I tillegg er alle godt kjent med Google Docs fra før av, og ved å velge dette verktøyet sparte vi tid ved at vi slapp å sette oss inn i et nytt verktøy. Vi vurderte å bruke Latex, som er en mer avansert teksteditor for dokumentering av teknisk og vitenskapelig prosjekter. Men med tanke på tidsrammene ville vi ikke prioritere å bruke tid på å sette oss inn i et tekstredigeringsverktøy ettersom vi hadde mange andre teknologier å lære oss. Vi fant heller ingen store fordeler ved å bruke Latex. Google Docs kan med plugins gjøre det meste Latex kan. Google Docs funksjon for kommentarer, historikk, sanntidsredigering og funksjon for forslag om endringer er vi også godt fornøyd med. Med sanntidsredigeringen kan vi enkelt be om hjelp om vi sliter med en formulering eller lignende, og de andre kan lett hoppe til hvor du er for å umiddelbart få oversikt over hva du skriver/ser på. Funksjonen for kommentarer og forslag om endringer gjør det enkelt for oss å be om en kommentar eller stille et spørsmål om teksten selv om vi ikke sitter sammen. De andre kan senere gå inn å se på kommentarene for så å svare på de eller godkjenne editeringene. 12

18 Prosessdokumentasjon Når det kommer til Google Drive var det her vi lagret alle dokumentene vi brukte til rapporten og forprosjekt (word, diagrammer, bilder, andre dokumenter). Slik får vi en samlet mappe i skyen som alle har tilgang til og som oppdateres automatisk GitHub Vi var alle sammen enige om at et versjonskontrollsystem var noe vi behøvde og ettersom vi alle har god erfaring med Git, som er av typen distribuert versjonskontrollsystem (hver person sitter med en kopi av kodebasen og deler endringer med hverandre) ble valget enkelt: GitHub. Vi har også vært innom Bitbucket, men følte oss mest trygg og erfaren med GitHub. GitHub tar hånd om versjonskontroll, kildekode og fildeling. Dette kan gjøres både via terminal, GUI eller IDEens funksjonalitet for Git. Vi brukte terminal til store merges (sammenslåing av filer) etter mange endringer. Men vi er mest erfaren med å gjøre pushing og pulling (operasjonene som deler eller henter filer fra/til de andre på gruppen) i IDEens verktøy. Git i terminal kan ved noen tilfeller være mer effektivt, men vi har ikke mye erfaring med dette så det ville bare ha bydd på enda en ekstra ting å sette seg inn i. GitHub er en av de største i bransjen, og vi ville derfor benytte anledning til å bli enda bedre kjent med verktøyet. Det at GitHub enkelt kan kobles sammen med Visual studio var også noe som gjorde valget av versjonskontroll lettere. 3.6 Arbeidsprosess Arbeidssted Vi har brukt skolen som arbeidssted for vårt prosjekt. Vi kunne gjerne ha tenkt oss å sitte på kontoret til Bravo under arbeidet med prosjektet. Men ettersom de har lite plass fra før av så var dette vanskelig å få til. Vi har vært flinke til å møtes, diskutere og ta avgjørelse i plenum. Selv om vi har delt opp noen av deloppgavene, har vi jobbet mest samlet og alle har vært inkludert i alle de ulike delene av prosjektet selv om vi alle selvfølgelig har hatt ansvar for ulike deler av prosjektet Møter Vi har hatt møter med intern veileder de gangene vi eller han har hatt et ønske om å møtes. For vår del har det mest handlet om å bruke tiden effektivt på prosjektet. Vi har samlet opp spørsmål underveis og spurt veileder om disse ved møtene. På denne måten har vi hatt muligheten til å ta møter med veileder kun når det har vært sterkt behov for å møtes. Utenom et par møter for å få deres innspill på vinkling, hva vi burde fokusere på av funksjonalitet og design, har vi ikke hatt mange møter med Bravo etter starten av prosjektarbeidet (desember-februar). Grunnen til dette er at Johannes jobber for Bravo, og har både fungert som direkte ledd inn i bedriften og har hatt mulighet til mail, telefon og fysisk kontakt med kontaktpersonen vår og andre ressurser hos Bravo. 13

19 Prosessdokumentasjon Fremdriftsplan En plan for datoer der de ulike arbeidsoppgavene burde være ferdig innen er utrolig nyttig når man jobber på et prosjekt som dette, og fordeler oppgaver som er avhengige av hverandre mellom gruppemedlemmene. Vi støtte under utviklingen på et problem med rettigheter mellom applikasjonen og APIet som ikke tillot oss å holde en like rigid fremdriftsplan som vi ønsket. Dette var et problem som gjorde at andre deler av applikasjonen vi utviklet ikke kunne testes. Da vi senere fikk løst dette problemet tok vi opp fremdriftsplanen igjen. Vi er dermed klar over at vi ikke hadde ikke like stram plan som vi burde hatt, og som kanskje er vanlig i arbeidslivet. Og vi ville nok fått et bedre bilde av hvor mye tid vi hadde til rådighet og trengte ved å holde en strammere plan Prosjektdagbok Vi opprettet et dokument som fungerte som en dagbok, hvor vi førte opp alle møter, hva vi gjorde på møtene og avgjørelser vi tok. Grunnen til at vi gjorde dette var for at dokumenteringen skulle bli lettere, ved å ha et arkiv å gå tilbake i for å kunne beskrive utviklingsprosessen, hvilke utfordringer vi har møtt på og endringer vi har måttet gjøre. Under har vi oppsummert de viktigste detaljene ved hver fase av prosjektet Valgfag og motivasjon Ved siden av bachelorprosjektet har alle gruppemedlemmene hatt to andre valgfag. Fagene har jevnlig hatt obligatoriske innleveringer og prøver, som dermed har krevd en del tid vi helst skulle ha brukt på dette prosjektet. Under arbeidet med prosjektet har vi støtt på et par utfordringer, blant annet angående rettigheter til APIet. Dette satt vi med ganske lenge og her kjente vi at motivasjonen ble svekket ettersom dette egentlig var et lite problem, som hindret mye framgang. Vi hadde sett for oss at APIet skulle gjøre jobben mer effektiv, men det føltes i en periode heller som at vi endte opp med å bruke mer tid på å lære APIet enn hva vi sparte på å bruke det. 4 Utviklingsprosessen Vi har delt utviklingsprosessen inn i fem ulike faser. Det har skjedd en del endringer i løpet av prosjektet både angående krav til applikasjonen, hvordan vi skal lage den og hvordan den skal se ut. Det vil si at vi hadde en periode (omtales som Pre-fase) hvor vi startet så vidt med løsningen, men deler måtte slettes pga endringene som ble gjort. Derfor er det den andre fasen i prosessen som anses som startfasen for utvikling. Denne blir etterfulgt av to utviklingsfaser hvor mye av implementeringen og største del av utviklingen skjedde. Applikasjonen ferdigstilles i den avsluttende fasen og det meste av tiden her blir satt av til dokumentasjonen. Design av brukergrensesnitt blir beskrevet i en egen seksjonen helt til slutt. 14

20 Prosessdokumentasjon 4.1 Pre-fase Denne fasen skjedde i januar. Dette var helt i starten av prosjektet da planen først og fremst var å fokusere på å utvikle en web-app for møteromsbooking. Og deretter bruke Xamarin til å også utvikle til Android og ios. Til dette opprettet vi et Xamarin prosjekt i Visual Studio, ettersom vi hadde planer om å lage en løsning som stod for seg selv, begynte vi å opprette klasser, modeller og noen metoder, samt å planlegge database oppsettet. Vi hadde også startet på separate views til android, ios og webapplikasjonen. Vi satt oss inn i store deler av Xamarin, da vi hadde kommet fram til at vi ville prøve å utvikle en ios og Android løsning i tillegg om tiden strakk til. Da tenkte vi at backend koden ville være delt mellom alle plattformene, mens brukergrensesnittet blir utviklet individuelt for hver plattform. Vi planla å bruke Microsofts skybaserte database; Microsoft Azure SQL Database. 4.2 Startfase Startfasen er første del av arbeidet mot den endelige løsningen vår, og varer hele februar. Det begynner med at vi er på møte med Bravo, hvor vi kommer frem til et par endringer som bør gjøres. Etter dette møtet med Bravo lagde vi også en tekstlig skisse for oss selv, som vi kunne bruke til å få et litt mer konkret bilde av hvordan de forskjellige sidene av applikasjonen skulle se ut og hva de skulle inneholde. Den tekstlige skissen gjengis her, slik vi skrev den på dette tidspunktet. Den kan altså være noe forvirrende for andre enn gruppen, men vi valgte å inkludere den likevel. 15

21 Prosessdokumentasjon Figur 3: Bildeutsnitt av tekstlig skisse. Fane1-3 er hovedsidene i appen og innrykkene representerer det fanen skal inneholde. F.eks er hvor mange personer et element i tab1: book NÅ MVVM arkitektur Vi valgte å bruke MVVM (Model View ViewModel) program arkitektur ettersom det er den mest brukte arkitekturen for Xamarin (og Xamarin.Forms) applikasjoner. Dette er også naturlig ettersom hvordan Xamarin fungerer. Ideen er at man med MVVM kan portere ViewModellen og Modellen til hvilken som helst plattform man ønsker å utgi appen på, og da bare bytte ut Viewet. Denne måten å utvikle på, skrive en kodebase og portere den til plattformene man ønsker å bruke er den mest sentrale delen av Xamarin Dropper web-løsning, fokuserer på ios og Android Som nevnt tidligere i rapporten kom vi sammen med Bravo fram til at vi burde skifte fokus til kun å utvikle mobilapplikasjonene. Det ville dessuten ikke vært nok tid til å gjennomføre 16

22 Prosessdokumentasjon begge deler (utvikle både web-applikasjon og mobilapplikasjonene) med tanke på den tidkrevende læringsprosessen vi hadde fremfor oss. Bravo var tydelige på at de var mer interesserte i en løsning for mobil plattformene. Til dette mente Bravo vi burde benytte oss av Microsoft Graph API og Office 365. Et web-grensesnitt vil dermed ikke være nødvendig ettersom brukerne vil ha tilgang til å booke møterom via mail, Outlook klient (mobil, PC, Mac) og Office 365 online. Dette er også måten de fleste som har tilgang til møteromsbooking med Office 365 gjør det i dag. De vil dermed ikke behøve å sette seg inn i en ny webapplikasjon. Dette anser vi som en stor fordel, alle disse bedriftene har også allerede noe av infrastrukturen de vil trenge for å ta i bruk applikasjonen. I og med at vi allerede hadde gjort en del utvikling med utgangspunkt om at vi skulle ha en webapplikasjon før vi tok denne avgjørelsen sammen med Bravo, måtte vi forkaste det meste av frontend relatert til webapplikasjonen. Fra dette tidspunktet setter vi Android og ios løsningene som hovedmålet med prosjektet Xamarin.Android og Xamarin.iOS På dette tidspunktet bruker vi Xamarin til å lage en felles backend, men ulikt grafisk grensesnitt for Android og ios. En på gruppa har allerede erfaring med utvikling av Android applikasjoner, så han frisker opp minnet om denne typen utvikling. Vi venter en liten stund på å få tilgang på en MacinCloud bruker som må brukes til utviklingen av ios versjonen av applikasjonen. En på gruppa fikk ansvaret på ios frontend utviklingen. Det ble brukt mye tid på å sette seg inn i storyboards og UIViewControllere. De første skissene av brukergrensesnittet ble laget Kunnskap og læring Store deler av startfasen ble brukt til å bli kjent med ulike teknologier vi har valgt å arbeide med. Siden vi nå har gått bort fra web-løsningen, må vi sette oss godt inn i Xamarin som skal benyttes til å utvikle for mobilplattformene. For å lære oss teknologiene på riktig måte har vi brukt offisiell dokumentasjon fra aktørene/utgiverne som kilder. Både Xamarin og Microsoft har masse god dokumentasjon som beskriver hvordan man bruker teknologiene best mulig. Xamarin Forums ble også godt brukt. Dette er et forum hvor folk legger ut spørsmål ang Xamarin, og folk fra Xamarin Teamet legger ut eksempler og svar. Ellers har det gått mye i video-tutorials og Stack Overflow. 4.3 Utviklingsfase 1 Utviklingsfase 1 startet i slutten av februar. Vi begynte smått å implementere både frontend og den første funksjonaliteten. Det første som ble gjort var å opprette strukturen for applikasjonens visuelle presentasjon. En meny, alle de tilhørende sidene og noen elementer 17

23 Prosessdokumentasjon på disse sidene. Det ble laget et par utkast av brukergrensesnittet, før vi bestemte oss for det endelige utseendet. Mer om besultninger angående dette finnes i et eget punkt Xamarin.Forms I slutten av februar fant vi ut at det er mye som kan gjøres enklere ved å benytte Xamarin.Forms rammeverket., som gjør det enklere å utvikle native brukergrensesnitt for ios og Android med en felles C# eller XAML kode. Siden vi allerede hadde mistet en del tid pga andre endringer i prosjektet, var dette en mer effektiv måte å løse det på. Det føltes unødvendig å bruke tid på å programmere to ulike grensesnitt for applikasjonene. Figur 4: Illustrerer forskjellen mellom tradisjonell bruk av Xamarin og Xamarin.Forms Azure og API Vi registrerer appen i Azure AD slik at applikasjonen får rettigheter til å bruke APIet på vegne av den innloggede brukeren. Vi får da en clientid fra Azure som applikasjonen sender brukeren til for innlogging i Microsofts globale innloggings plattform login.microsoftonline.com. Azure AD brukes altså for å bestemme hvilke rettigheter applikasjonen skal ha, på vegne av den innloggede brukeren. I vårt tilfelle er det viktig at applikasjonen kan sende mail, se kalenderen til brukeren og andre brukere på domenet Logg inn funksjonen Når vi hadde registrert appen i Azure AD var det mulig å legge inn en innloggingsfunksjon i appen. Ettersom vi nå kunne legge ved appens clientid når vi sender brukeren til Microsoft sin innloggingsside, slik at Microsoft kunne kjenne igjen appen og vite hvilke rettigheter den trenger Modeller Etterhvert som vi lærte mer om Microsoft graph API og hva som blir returnert fra diverse spørringer, begynte vi å lage modeller for diverse verdier vi hadde bruk for. For å hente en liste over rom fra Microsoft graph må vi gjøre en spørring etter brukere, ettersom møterommene er registrert som dette og ikke en egen type rom. Derfor lagde vi en 18

24 Prosessdokumentasjon rommodell (RoomModel.cs) som er basert på de feltene som returneres når man henter brukere. Vi har også lagd to modeller av events, som vi også henter fra APIet. Den ene (CalendarModel.cs) brukes når vi henter alle kommende events for en bruker/møterom. Den andre (SendModel.cs) brukes når vi har behov for å opprette en event, denne har flere punkter ferdig utfylt i det den blir opprettet, blant annet innlogget brukers epost og navn. 4.4 Utviklingsfase 2 Utviklingsfase 2 strekker seg fra mars til april. Det er i denne fasen det meste av koden blir implementert og vi føler endelig at vi er skikkelig i gang med utviklingen etter mye frem og tilbake. Brukergrensesnittet er nesten ferdig, og det handler nå mest om å gjøre den siste finpussen på design. Som nevnt i avsnittet om fremdriftsplan, møtte vi på et problem med applikasjonens rettigheter mot APIet, vi får i fase 2 endelig løst dette problemet. Noe som gjør at den siste delen av utviklingen går mye raskere Utfordringer med API rettigheter Problemet med rettigheter mot APIet handlet om at brukeren vi testet med ikke var administrator i domenet vi brukte for testing. Vi brukte skolebruker, hotmail bruker og Johannes s bruker hos Bravo, men ingen av disse var administratorbrukere. Applikasjonen fikk dermed ikke rettigheter til å hente ut informasjon fra andre brukeres kalendere. Dette gjorde at spørringene vi gjorde mot APIet kom tilbake med error om ingen rettigheter. Vi fikk senere løst dette ved å få tilgang på en administrator bruker fra Bravo Spørringer til APIet Etter at vi fikk tilgang til en admin bruker og ga appen de rettighetene vi hadde behov for, kunne vi begynne å legge inn API spørringer der vi hadde behov for det. Dette gir oss tilgang til brukerens kalender og oversikt over andre brukere på samme domene. Vi bruker spørringene til å finne møterommene og hendelser i kalenderen til både møterom og brukeren. Disse spørringene tar vi i bruk for å: Sjekke om et rom er ledig, om det er stort nok; la brukeren booke rom med en gang, eller booke et valgt rom Mal for oppsett Office 365 Rom Etter å ha jobbet litt med Microsoft graph API fant vi ut at APIet har sine begrensninger, for vår app handlet dette i hovedsak om at møterommene blir sendt som brukere. Dette betyr at det ikke var noen måte å hente de spesielle atributtene som registreres på møterommene i Office 365, samt at vi ikke bare kan hente møterom. Vi ble nødt til å lage spesielle regler for hvordan møterommene registreres, slik at appen kan filtrere de ut blant brukere etter å hentet de fra APIet. 4.5 Avsluttende fase Den siste og avsluttende fasen brer seg utover mai måned, og prosjektet begynner å nærme seg slutten. Et par avgjørelser ang brukergrensesnittet må tas, siste finpuss av backend implementeringer, men mesteparten av tiden blir brukt til dokumentasjonen. 19

25 Prosessdokumentasjon Kalender I fanen kalt Rom er det som nevnt en liste over alle møterommene i bedriften. Når man trykker på et spesifikt møterom hadde vi tenkt at brukeren skulle få se en kalender lik den som er i outlook, for å vise hvilke tidspunkt rommet er ledig og opptatt. Vi har jo benyttet oss av Xamarin.Forms og tenkte at det ikke ville bli noe problem ettersom implementering av alt annet i frontend hadde gått bra. Men vi finner ut at Xamarin.Forms rett og slett ikke har noe element for kalender, og det blir for tidkrevende å lage en kalender manuelt på dette tidspunktet. Vi innser at vi må droppe denne funksjonaliteten, og endrer derfor litt på resten av fanen også. Vi ender heller opp med at man bare får informasjon om rommet når man trykker på det, og dette fungerer helt fint. I tillegg så vil denne funksjonaliteten være tilgjengelig i web-grensesnittet, og dermed gjør det ikke så mye at den ikke kom med i applikasjonen Testing Vi begynner å se på testing av applikasjonen. Gjennom hele utviklingsprosessen har vi gjort enkle brukertester og tester på dataene vi håndterer. Mer om dette blir dekket i en egen del i produktdokumentasjonen Dokumentering Vi har jobbet litt med dokumentering ved siden av kodingen helt fra starten av, men det er nå vi alle har dokumentasjonen som hovedfokus. Ettersom alle hadde hovedansvar for en spesifikk del av oppgaven har vi bestemt at alle skal tilføye informasjon om det de har gjort underveis der det passer seg. Etter at dokumentasjonen har begynt å ta form går vi gjennom hele teksten sammen. Vi kommer med forslag til forbedringer og tar sammen de avgjørelser som er nødvendig å ta i felleskap. Dette gjør vi for å forsikre oss om at alle er enige, fornøyde og har bidratt like mye med det vi til slutt skal levere. 4.6 Design Bravo hadde ingen spesifikke designkrav til oss, og vi har derfor valgt å fokusere på funksjonalitet over design. Vi har likevel diskutert valg av design i mindre grad, og har kommet til enighet om at vi vil ha et enkelt og ryddig brukergrensesnitt. Vår applikasjon krever interaksjon med brukeren for å kunne utføre det tiltenkte målet. Derfor har det vært viktig for oss å ha selvforklarende labels der det er behov for det. Vi har gjort litt research, og sjekket ut flere andre eksempler og har fått inspirasjon fra andre populære apper. Vi har tatt utgangspunkt i kjente og kjære elementer hos dagens apper, som brukerne er godt kjent med fra før. Dette gjør applikasjonen mer brukervennlig for folk flest, de slipper å sette seg inn i et nytt avansert brukergrensesnitt. 20

26 Prosessdokumentasjon Fargevalg og logo Som nevnt hadde ikke Bravo noen store spesifikke krav til design, men de ønsket at fargevalgene skulle stå i stil med Bravos eksisterende profil, fargevalget ble dermed enkelt: Oransje. Fargen er hovedfargen i Bravo (solutions) konsept. Ellers har vi kombinert det med lyseblå, ettersom Bravo også bruker denne fargen til nettsiden deres. Appen skal ha en logo for Bravo Solutions i Apple Appstore og Android Play store Universell utforming Figur 5 : Logo Vi var klare på at vi skulle følge kravene om universell utforming da vi utviklet appen, slik at den skal være tilgjengelig for alle eventuelle brukere. Da vi valgte fargekombinasjon testet vi det på for å forsikre oss om at de ikke forårsaket komplikasjoner hos svaksynte og/eller fargeblinde. Oransje og lyseblå skaper nok kontrast til mørkegrå, og er derfor et sikkert valg Informasjonsarkitektur En viktig faktor ved utvikling av applikasjoner er hvordan informasjonsarkitekturen er bygd opp. Det vil blant annet si hvordan innholdet er organisert, hvilke navigeringsmuligheter som finnes, bruken av labels og navngivning, ikoner mm. Kort fortalt vil det si strukturen til applikasjonen, som skal hjelpe folk å forstå hvor de befinner seg og hvordan de navigerer seg til ønsket informasjon eller tjeneste, til enhver tid. Applikasjonen inneholder ikke så mye tekstlig informasjon, men det er likevel viktig å være bevisst på bruken av labels. En label vi si en merkelapp som representerer en blokk med informasjon. For at appen vår skal fremstå som brukervennlig, noe som er hovedmålet, burde labelene virke selvforklarende for alle brukere. I tillegg burde det være lett å forstå hvordan interaksjonen med appen skal foregå. Navigeringen i applikasjonen er viktig for at brukerne skal kunne bruke applikasjonen på best mulig måte. Vi har valgt å bruke en fane-meny, som hovedmeny og navigeringssystem. Ettersom applikasjonen vår har et simplistisk design, og ikke inneholder så mye mer enn hovedfunksjonaliteten som er å booke et møterom, passer dette mønsteret bra. Navigeringen mellom fanene burde også være selvforklarende for målgruppen, ettersom dette er en type meny som er mye brukt i andre apper og vi går utifra at de fleste har erfaring med bruk av applikasjoner på smarttelefoner. Fane-menyen er global og vil si at den er gjennomgående og synlig uansett hvilke side man står på, med andre ord vet brukerne alltid hvor de befinner seg. Den fanen man befinner seg i vil være markert. Ved å bruke denne type meny ønsker vi selvsagt at det fort skal fremgå for brukeren hva slags muligheter appen tilbyr. Her kommer vi igjen innpå det med å bruke selvforklarende labels, for hvis vi ikke har dette, vil vi miste nytte med menyen. Book nå og Min profil går vi ut at er selvforklarende for alle. Den eneste fanen som kan virke tvetydig er Rom, som 21

27 Prosessdokumentasjon gir en oversikt over alle møterommene i bedriften. Vi kunne nok kalt den Romoversikt eller Møterom-oversikt for å være sikre på at flest mulig forstår. På mobilapplikasjoner blir det ofte brukt ikoner istedenfor lange tekstlige labels for å indikere hvilken informasjon eller funksjonalitet som finnes her. Vi vurderte å bruke ikoner i navigeringsmenyen, men kom frem til at det fort blir forvirrende når man bruker ikon for å beskrive Rom og Book nå. For å indikere å gjøre en ny booking kunne vi brukt plusstegn-ikon, men dette signaliserer fremdeles ikke helt riktig funksjonalitet for oss, ettersom man skal booke møterom til umiddelbar bruk. Dermed holdt vi oss til tekstlige labels i hovedmeny. Men på fanen Min profil har vi lagt inn eksempler på bruk av ikoner. Tannhjul-ikonet illustrerer innstillinger. Avatar-ikonet indikerer at du befinner deg på Min profil. Pilen som peker ut av en boks indikere logg ut. Dette er innarbeidede ikoner, som er lett gjenkjennelige for nærmest alle som bruker apper. 5 Kravspesifikasjon Prosjektideen ble utviklet av gruppen vår og Bravo i fellesskap. I vårt tilfelle hadde oppdragsgiver få spesifikke krav til prosjektet vårt i starten. Etter et par møter med Bravo har vi sammen kommet frem til de funksjonelle og ikke-funksjonelle kravene vedrørende prosjektet. Utviklingen av den endelige kravspesifikasjonen har dermed skjedd underveis. Formålet med kravspesifikasjonen er at den skal fungere som en kontrakt mellom oss og oppdragsgiver, og var med på å avgrense/definere oppgaven. Vi rangerte prioritering på alle de funksjonelle og ikke-funksjonelle kravene. De hjalp oss å holde riktig fokus gjennom utviklingen, og gjøre riktige prioriteringer på implementeringen av funksjonaliteter, i forhold til tidsperspektivet. Kravspesifikasjonen har med andre ord vært fleksibel og åpen for endringer. Den fullstendige kravspesifikasjonen kan sees som vedlegg i sluttrapporten. 5.1 Prioriterte oppgaver En av de viktigste oppgavene var å bli kjent med hvordan vi skulle bruke APIet. Microsoft graph API var relativt enkelt å lære seg spørringene for ved hjelp av Graph Explorer: kunne vi teste diverse spørringer før vi hadde implementert disse i appen. Den største utfordringen gikk ut på å finne de riktige rettighetene og teste med disse. Så fort vi fant ut av problemet med rettigheter var APIet et av de mest nyttige verktøyene for utviklingen. Hovedfokuset vårt har vært å utvikle til to plattformer, ios og Android. For å muliggjøre dette brukte vi Xamarin. Dette førte til at en annen viktig oppgave var å sette seg inn i denne teknologien. Vi har prioritert å utvikle en applikasjon som fungerer på to plattformer, over at appen inneholder masse storslåtte og avanserte funksjonaliteter. Formålet var å lage en brukervennlig og simpel applikasjon som booker et møterom. Enkelt og greit. Vi har derfor brukt mer tid på å få til dette enn å implementere ekstra funksjonalitet med lav prioritet for å kunne ha et ferdig produkt klar til levering så fort som mulig. Denne prioriteringen samsvarer med hvordan smidig metodikk og kanban fungerer. 22

28 Prosessdokumentasjon 5.2 Endring i kravspesifikasjonen Selvom kravspesifkiajsonen har vært i stadig foradring og utvikling hadde vi et førsteutkast hvor det ble gjort noen større endringer og prioriteringer. Enten på grunnlag av at vi har funnet bedre løsninger, at det ikke har vært nødvendig likevel eller ikke har hatt tid til det. Det å ta i bruk API var ikke en endring i kravspesifikasjonen i seg selv men førte til andre endringer. I det vi tok i bruk API ble appen umiddelbart mer tilkoblet Office 365 systemet, dette førte til endringer som at vi ikke lenger hadde behov for en egen database, og at vi slapp å lage flere av metodene og klassene som vi hadde sett for oss i kravspesifikasjonen. Isteden ble mer tid dedikert til å sette seg inn i dette. Hovedmålet med prosjektet var å utvikle en web applikasjon som tar for seg booking av møterom, og om vi hadde tid også mobilplattform applikasjoner. Ettersom det allerede finnes en måte for å booke møterom via outlook, ble fokus rettet mot ios og Android. Dette innebar at mange av funksjonalitetene vedrørende webløsningen falt bort, og vi måtte omformulere noen av kravene. F.eks Importering av rominfo fra excel og invitere eksterne brukere ble fjernet. Noen funksjonaliteter falt bort pga bedre løsninger, ikke tilstrekkelig tid eller at de ikke var nødvendig. Funksjonaliteter med lav prioritet ble idéer til videreutvikling. 5.3 Ikke implementert Noen av de funksjonelle kravene som hadde mindre prioritering, har ikke blitt implementert pga mangel på tid. Se listen under for de funksjonalitetene som mangler i applikasjonen. Den fullstendige kravspesifikasjonen finnes som vedlegg, og her ligger alle krav, (innfridd eller ikke). Driftsmelding om møterommene ( lavt prioritert, mer en idé til videreutvikling) Applikasjonen skal gi varsler i god tid før møtet ( lavt prioritert, mer en idé til videreutvikling) Brukere skal kunne endre på preferanser for booking av møterom ( lavt prioritert, mer en idé til videreutvikling) Kansellere et møte (dette kan uansett gjøres i Outlook) Kalenderen var en viktig funksjonalitete som vi ikke fikk implementert pga liten tid og at det var mer tidkrevende enn antatt Brukere skal kunne filtrere oversikten over alle møterom 23

29 Prosessdokumentasjon 5.4 Konklusjon Å ha såpass frie tøyler for kravspesifikasjon som vi har hatt kan by på utfordringer. Av og til hadde det vært greiere å bare bli fortalt akkurat hva man skal gjøre, og hvordan. Bravo har ikke den faglige kompetansen til å gi oss slike krav, de er ikke utviklere. Og vi har derfor tatt mange avgjørelser selv, som i ettertid har blitt diskutert i fellesskap med Bravo og blitt godkjent av dem. 6 Avslutning 6.1 Sluttproduktet Gjennom arbeidet med prosjektet har vi jobbet intensivt og målbevisst for å nå kravene til oppdragsgiver. Vi har oppfylt de fleste kravene med høy prioritering i kravspesifikasjonen. Den ferdige applikasjonen kan tas i bruk av oppdragsgivers til formålet å kunne booke et møterom akkurat nå. Sluttprodukt har noen mangler. F.eks en ganske viktig funksjonalitet var at man skulle kunne booke rommet, ved å se kalenderen for rommet. Så selv om applikasjonen fungerer anbefaler vi noe videreutvikling og tilretteleggelse før den eventuelt tas i bruk av bedrifter. Vi ser på sluttproduktet som en fungerende prototype/alpha versjon av den endelige applikasjonen. Det er ikke helt klart for det selgende markedet enda, og krever noen endringer for at det skal bli mer attraktiv for bedrifter å investere i. Tilretteleggelsene som må gjøres handler om å ta enkelte policy avgjørelser før man tar applikasjonen i bruk. Men dette blir opp til bedriften å avgjøre, fra vår side mener vi at applikasjonen kan tas i bruk som den er. Den fungerer altså til hovedformålet; sjekke ledige møterom nå, booke rom nå. 6.2 Arbeidsfordeling og samarbeid Det ble naturlig for oss å bruke skolens lokaler til vår arbeidsplass. Som nevnt over har vi brukt Slack som kommunikasjonsverktøy, men også Facebook chat (mest uformelt om når og hvor vi skal møtes). Vi har brukt Trello til å fordele arbeidsoppgavene oss i mellom. Vi har alltid møttes og jobbet sammen om de store oppgavene, og tatt avgjørelser sammen. Vi har jobbet mest samlet fordi vi tror det er viktig med åpen dialog /god kommunikasjon under utvikling og dokumentering. Dette hjelper oss å bli samkjørte i det vi jobber med. 6.3 Oppdragsgiver Siden oppdragsgiver ikke hadde noen absolutte krav til prosjektet vårt i begynnelsen, har det vært viktig for oss å ha god kontakt med Bravo. Siden Johannes jobber sammen med kontaktpersonene våre hos Bravo og ser dem ukentlig, og de har jevnlig snakket sammen om prosjektet. Har vi hatt en god dialog med Bravo uten å ha møte med de hver uke. Ellers har vi også hatt et par felles møter med hele gruppen og Bravo. Det kunne vært praktisk for oss å få låne lokalene deres, slik at hele gruppen jobbet tettere på kontaktpersonene våre i Bravo og kunne fått hjelp av dem. Men Bravo har liten plass til 24

30 Prosessdokumentasjon overs, og kontaktpersonene har heller ikke den faglige (programmerings) kompetansen som vi kunne kunne trengt for å få hjelp av de. Vi skulle gjerne sett at Bravo hadde noen innad hos de med litt mer programmeringskompetanse slik at vi kunne fått hjelp av de med utviklingsmessige problemer. Men vi føler at de har hjulpet oss med det de har hatt forutsetningene for. Og vi har til slutt fått løst det meste. 6.4 Læringsutbytte Før dette prosjektet hadde kun en av gruppemedlemmene direkte erfaring med apputvikling for mobil (Android), men vi hadde alle erfaring med C#. Vi har lært utrolig mye, men ikke bare om apputvikling. Vi har lært oss en hel rekke nye teknologier. Det å jobbe på et så stort prosjekt med en gruppe kan være utfordrende. Heldigvis har vi arbeidet mye sammen før og har vært fornøyd med resultatene vi har fått. Med tanke på hvor krevende prosjektet er og tidsrammen rundt det, har vi lært mye: vi har brukt mye tid på å finne ut av rammeverk og teknologier, dette har gått litt utover vår tid til å programmere løsningen. Hadde vi gjort dette igjen hadde vi nok gjort ting litt annerledes. Under utviklingsprosessen følte vi til tider at vi hadde tatt på oss for mange nye ting, men vi føler at sluttresultatet er bra. Spesielt med tanke på hvordan appen fungerer og hva vi har lært. 6.5 Hva kunne vi gjort annerledes Å jobbe på gruppe på bacheloroppgaven kan være utfordrende på mange vis. Man har ulike forventninger, ønsker og intensjoner om hvordan både arbeidsprosessen skal foregå og hvordan sluttproduktet skal se ut. Vi har heldigvis jobbet på en gruppe der alle gruppemedlemmene kjenner hverandre godt fra før av, og vi har som regel alltid kommet til en beslutning sammen. Vi ble enige med Bravo om å starte på utviklingen før vi tok et møte om hvordan vi hadde tenkt å løse oppgaven. Etter en stund hadde vi det første møte hvor personen med mest teknisk kompetanse om utvikling fra Bravo ble involvert i veiledningen til prosjektet vårt. Her kom de med et par endringer som vi burde gjøre, spesifikt og størst var endringen om å bruke Microsoft Graph API. Noe som førte til at vi etter ca to måneders jobbing følte vi måtte gjøre store endringer. Ikke nødvendigvis fordi vi hadde gjort feil, men fordi vi fant ut at ved å bruke APIet kunne løse prosjektet på en mer effektiv måte. Først fikk vi altså inntrykk av at oppdragsgiver ikke hadde noe spesifikke krav til prosjektet, men det betyr jo ikke at de ikke har innspill. De ga oss masse råd og veiledning som vi gjerne skulle hatt tidligere i prosjektet. Vi har virkelig fått en lærepenge på viktigheten med kommunikasjon og jevnlige møter med oppdragsgiver. Det er jo tross alt de vi utvikler for. Vi valgte smidig utvikling til prosjektet vårt, men denne metodikken greide vi ikke å følge like godt som vi ønsket, ettersom vi manglet håndfast erfaring med smidig utvikling. Gjennom prosjektet har vi hatt mange baller i luften på en gang, deloppgaver ble påbegynt men ikke ferdigstilt og det har føltes overveldende med så mye uferdig arbeid til tider. Dermed måtte vi ofte gå tilbake til tidligere oppgaver for å fullføre dem, vi burde altså fulgt retningslinjene for utviklingsmetodikken strengere. Hadde vi satt tydelige mål per arbeidsdag, og unngått å 25

31 Prosessdokumentasjon jobbe med flere deloppgaver samtidig hadde arbeidet med prosjektet vårt blitt mer effektivt. Under smidig utvikling er det viktig å jobbe tett på oppdragsgiver, ettersom endringer fort kan skje og man hele tiden må prioritere hva som er viktigst. Vi hadde mye kontakt med oppdragsgiver, men har ikke vært så flinke å vise frem midlertidig applikasjon og diskutere mulige løsninger rundt den. Dette har litt å gjøre med at vi ikke arbeidet på deres lokaler og de ikke alltid har hatt tid til å møte oss for slike ting. 6.6 Hva er vi stolte av Vi er stolte av at vi har klart å lage en godt fungerende applikasjon, uten mye hjelp fra oppdragsgiver. Som nevnt skulle vi gjerne sett at vi hadde hatt mulighet til å få enda litt mer hjelp fra de. Men vi er stolte av at vi har klart dette på en selvstendig og god måte. Det at vi har lært så mye som vi har, om de enkelte teknologiene, og utvikling generelt er noe vi også tar med oss. Xamarin, Microsoft Graph API, Azure AD og Office 365 løsningene er de tingene vi har lært mest om. Vi føler at om vi skulle startet utviklingen på nytt nå, med all den kompetansen vi har opparbeidet oss. Ville vi klart oppgaven mye raskere, enklere og bedre. 6.7 Konklusjon Vi fikk tips fra Bravo om å gå for API siden dette er mer effektivt enn å kode alt selv. Vi antok at dette kom til å føre til mer effektiv bruk av tid, selv om vi kom til å bruke mye tid på å lære oss dette. Vi havnet i en situasjon hvor vi har brukt mer tid på å lære oss nye teknologier, enn å faktisk anvende teknologiene. Vi skulle gjerne sett at vi heller kunne ha brukt en del av teknologiene vi har lært i løpet av studiet, enn å lære oss nye teknologier. Men i og med at dette også er en del av utdanningen, er vi inneforstått med at det under arbeidet med bacheloren bør forventes at en del tid går med til læringsprosessen for teknologier vi må kunne for bachelorprosjektet. Men vi har kanskje valgt litt for mange nye teknologier å sette oss inn i, med tanke på tidsperspektivet av bacheloroppgaven. Vi har også erfart at det å jobbe på et slikt prosjekt ofte innebærer det å ha store ambisjoner i starten, man har mange gode ideer til funksjonaliteter appen bør ha, men så innser man etter en stund at det ikke alltid er like realistisk i forhold til tidsrammen. 6.8 Ord fra oppdragsgiver Johannes Strige, Joakim Hanssen Lund og Synne Storhaug tok kontakt med Bravo Gruppen ifm deres hovedprosjekt. Vi hadde møte angående hva slags applikasjon de skulle utvikle og vi ble enig om at de skulle utvikle en app som håndterer møteroms booking. Dette er en app vi ser det er behov for i markedet og som vi kan levere til våre kunder. Det har vært noen møter mellom guppen og Bravo hvor vi har diskutert mulig problemstillinger og funksjoner. Jeg er imponert over hvordan gruppen har løst oppgaven, de har jobbet selvstendig og resultatet er uten tvil noe vi kan bruke ut mot våre kunder. Samarbeidet har utelukkende vært en positiv opplevelse fra Bravo sin side og vi er meget fornøyd med sluttresultatet. - Lars Andrup-Næss, Bravo Solutions 26

32 Høgskolen i Oslo og Akershus Fakultet for Teknologi, Kunst og Design Hovedprosjekt i Informasjonsteknologi 2017 Gruppe 37 Produktdokumentasjon

33 Produktdokumentasjon 1 Forord Produktdokumentasjonens formål er å gi sensor, veileder, eventuelle videreutviklere, vedlikeholdere og andre som har interesse av å studere sluttrapporten, en detaljert beskrivelse av applikasjonens funksjonalitet, virkemåte og andre aspekter rundt applikasjonen. Det anvendes derfor et teknisk språk og vi har lagt ved en ordliste dersom det er noen ord som krever nærmere forklaring. For eventuelle videreutviklere og vedlikeholdere anbefales det kunnskap om Xamarin.Forms, Microsoft Graph API, Android eller ios emulator og gjerne noe erfaring med Office 365/Azure AD. Denne dokumentasjonen består av hoveddelene: Produktbeskrivelse - her beskrives sluttproduktet og dets funksjonalitet i detalj. Teknologi - inneholder beskrivelse av hvordan vi har brukt teknologiene, og kort om programmeringsspråk bruk til frontend og backend. Oppbygging og virkemåte - applikasjonens oppbygging, funksjon og teknologi. Samsvar mellom produkt og kravspesifikasjon - en beskrivelse av hvilke krav som er oppfylt, ikke oppfylt og begrunnelse for dette. Sikkerhet ved applikasjonen - sikkerhetsaspekter rundt applikasjonen. Installasjon for videreutvikling og lokal kjøring - installasjon for videreutvikling og lokal kjøring på enhet eller emulator. Testing - beskrivelse av hvordan vi har gått frem med tanke på testing av applikasjonen. Videreutvikling - her beskriver vi idéer og tilrettelegging for videreutvikling. 1

34 Produktdokumentasjon Innhold 1 Forord 1 2 Produktbeskrivelse Logg inn Book et ledig rom nå Oversikt over ledige rom Oversikt og booking på spesifikt rom Booke rom på ønsket tid Oversikt over kommende møter 11 3 Teknologi Xamarin Microsoft Graph API Azure AD Frontend - XAML Backend - C# 14 4 Oppbygging og virkemåte Model-View-ViewModel (MVVM) Klassediagram for applikasjonen Applikasjonsstruktur Databaser Teknisk beskrivelse av funksjonalitet Modeller Lister Filtrering Picker API spørringer Get-Spørringer Post-Spørringer Logg inn 22 5 Samsvar mellom produkt og kravspesifikasjon Krav som ikke er oppfylt i sluttproduktet Kalender Filtrering av romoversikt Kansellere booking 24 6 Sikkerhet ved applikasjonen Brukerhåndtering 25 7 Installasjon for videreutvikling og lokal kjøring 25 8 Testing 26 2

35 Produktdokumentasjon 8.1 Mål med testing Enhetskonfigurasjoner og verktøy Testplan Sikkerhetstesting Brukertesting Enhetstestning 28 9 Videreutvikling 28 3

36 Produktdokumentasjon 2 Produktbeskrivelse Bravo Booking er en applikasjon for ios og Android som lar brukere booke og se ledige møterom i bedriften til brukeren. Appen tar i bruk Microsoft Office 365 sitt allerede utviklede system for møter og kalendere, og lar brukeren bruke sin smarttelefon til lett og effektivt booking av et møterom. Bravo Booking kan benyttes av ansatte i bedrifter som har implementert løsningen i deres system. Det stilles en forutsetning om å ha enten en ios eller Android smarttelefon, og en Office 365 mailadresse for å anvende appen. Når man logger inn får man mulighet til å booke møterom i bedriften, se en oversikt over ledige møterom og en oversikt over ens kommende møter. Siden målgruppen til appen er ansatte i bedrifter (der løsningen allerede er implementert) skal applikasjonen fungere intuitivt for enhver bruker, og ikke kreve veiledning før bruk. Smarttelefoner og apper florerer rundt oss i samfunnet, og blir brukt av de fleste opptil flere ganger om dagen. Vi lever i et mer og mer digitalt samfunn og vår applikasjon er ment å være lett gjenkjennelig til dens formål. Vi vil nå gi en forklaring på alle funksjonalitetene ved hjelp av brukerhistorier, skjermbilder og ulike UML-diagrammer. Hovedfunksjonalitetene som beskrives vil kunne inneholde flere krav, representert som brukerhistorier, ettersom de henger sammen. 2.1 Logg inn Som bruker ønsker jeg å logge inn på appen via min Office 365 konto - prioritet: høy Startsiden til applikasjonen er en innloggingsside, med en logg inn knapp. Brukeren blir sendt videre til Microsofts globale innloggingsside (login.microsoftonline.com) etter å ha trykket på knappen. Herfra fyller man ut brukernavn og passord til en Office 365 konto. Dersom innloggingen godkjennes blir infoen om brukeren sendt tilbake fra Microsoft, og lagres av appen på enheten. Dette blir gjort i form av en kryptert token slik at brukernavn og passord fortsatt er sikret. Brukeren blir da henvist til hjemmesiden i appen (BookNowPage). 4

37 Produktdokumentasjon Figur nr 1: Sekvensdiagram for logg inn funksjonaliteten. Figur 2: Første side i appen. Figur 3: Microsofts globale innloggingsside. 5

38 Produktdokumentasjon Figur 4: Aktivitetsdiagram for innlogging og book nå. 6

39 Produktdokumentasjon 2.2 Book et ledig rom nå Som bruker ønsker jeg å booke et rom nå - prioritet: høy Som bruker ønsker jeg å velge antall personer, starttidspunkt og varighet for møterommet som skal bookes - prioritet: middels Applikasjonen skal booke møterom ved å invitere rom via Office prioritet: høy Etter man har logget inn kommer man direkte inn på Book nå fanen i hovedmenyen. Dette skjermbildet består av tre labels, tre Picker-komponenter og en knapp. Brukeren velger antall personer, starttidspunkt og varighet. Picker elementene (fungerer som en popup med valgmuligheter man blar gjennom) har allerede default verdier. Når brukeren har valgt ønskede verdier for møtet som skal bookes, kan Book Nå knappen klikkes på. Da sendes parametrene som er valgt fra brukergrensesnittet til backend som håndterer dette. Metoden heter BookNow_OnClicked og er plassert i BookNowPage.xaml.cs. Derfra sendes det en spørring om å finne alle møterom i bedriften til APIet, og møterommene returneres. En ny spørring om å finne alle events på møterommene blir sendt, og igjen returnert. Om metoden finner et ledig rom med de gitte parametrene blir bookingen gjennomført, og brukeren får en beskjed om dette. Dersom det ikke finnes noen ledige rom med disse betingelsene, vil brukeren få en beskjed om at det ikke finnes noen ledige rom som passer de valgte kriteriene. Om rommet ble booket får brukeren informasjon om hvilket rom det er. Filtrering av rom: appen lar brukeren velge antall personer mellom 1 og 10 som ønsker møterommet. Dette avgjør hvilke rom en kan få booket. Appen vil kun booke møterom som har like stor eller større kapasitet enn antallet personer brukeren har valgt. Valgene kan også enkelt utvides til å legge inn valg for mer enn 10 personer om det skulle være nødvendig. Brukeren kan også velge ønsket starttidspunkt for bookingen, og varighet for møte. Disse har tre valg hver, men kan enkelt utvides. 7

40 Produktdokumentasjon Figur 5: Sekvensdiagram for book-nå funksjonaliteten. Figur 6: Book nå fanen (BookNowPage.xaml.cs). 8

41 Produktdokumentasjon 2.3 Oversikt over ledige rom Som bruker ønsker jeg å se en oversikt over alle møterommene i bedriften - prioritet: middels Som bruker ønsker jeg å se hvilke møterom som er ledige eller opptatt akkurat nå - prioritet: middels Den andre fanen i hovedmenyen heter Rom og er en liste som gir oversikt over alle møterommene i bedriften. I denne listen sjekkes det om hvert rom er ledig eller ikke, og statusen vises før navnet på rommet i listen. Det vises også navn og kapasitet om hvert av rommene i bedriften, slik at brukeren kan velge det rommet som passer best. Det er på denne siden mulig å klikke på møterommene, og brukeren sendes da videre til en ny side med info om rommet, der det også er mulig å booke på bestemt dato og tid. Figur 7: Oversikt over alle møterom i en (eksempel) bedrift. 9

42 Produktdokumentasjon 2.4 Oversikt og booking på spesifikt rom Som bruker ønsker jeg å se informasjon om et spesifikt rom - prioritet: middels Som bruker ønsker jeg å booke et spesifikt rom - prioritet: middels Som bruker ønsker jeg å booke et rom på ønsket dato - prioritet: midd els Når man klikker på et spesifikt rom i fanen for alle rommene kommer man til siden med rom informasjon. På denne siden kan man også booke rommet nå eller for et spesifikt tidspunkt ved hjelp av et DatePicker element for dato og et TimePicker element for tid. En bruker kan ha behov for selv å gå inn å sjekke kapasiteten på et spesifikt rom. Denne siden kan utvides enkelt dersom registrerer flere verdier på rommet. Figur 8: Rom informasjon og mulighet for å booke et rom på tid og dato. 10

43 Produktdokumentasjon 2.5 Booke rom på ønsket tid Som bruker ønsker jeg å booke et ledig rom på ønsket tid - prioritet: høy Ettersom applikasjonen er ment til å effektivisere oppgaven av å booke et møterom, er det oftest i situasjoner hvor en trenger møterommet på kort varsel at en vil ha størst bruk for appen. Dermed har vi kun alternativer for booking av møterom i løpet av den neste timen. Om du ønsker et møte senere enn det, bruker du heller Outlook kalenderen til booking. Dersom bedriften ønsker å bruke appen til booking senere enn den neste timen, kan appens funksjonalitet utvides for dette. Vi kunne gjerne utvidet med flere valgmuligheter for booking innen samme dag. Men denne funksjonaliteten ville vi heller lagt inn som en kalender for booking, dette nevnes under Samsvar mellom produkt og kravspesifikasjon. Figur 9: Picker element for valg av starttidspunkt. 2.6 Oversikt over kommende møter Som bruker ønsker jeg å se en oversikt over mine kommende møter - prioritet: lav Den siste fanen i menyen heter Min profil. Her kan man se informasjon om brukeren som er logget inn. Denne fanen inneholder også en liste med kommende møter for brukeren. Hver booking er presentert med nødvendig informasjon, som klokkeslett, dato og hvor møtet finner sted (hvilket rom). Andre ting denne fanen også inneholder er en knapp for innstillinger og en logg ut knapp. 11

44 Produktdokumentasjon Figur 10: Skjermbilde av Min profil fanen. 3 Teknologi I denne delen vi vil utdype hvordan vi har brukt hovedteknologiene, samt hvordan vi har utviklet backend og frontend. 3.1 Xamarin For å oppnå native utvikling benytter vi oss av en relativt ny teknologi: Xamarin, muliggjør utvikling av en native applikasjon på en hybrid måte. Dette betyr at applikasjoner som tar i bruk denne teknologien skal kunne være like effektive som applikasjoner utviklet spesifikt for kun én enkelt plattform. Det passet spesielt godt at Microsoft nylig hadde kjøpt opp Xamarin ettersom applikasjonen vår bygger på Microsoft Graph API, Azure AD og Office 365 brukere/ressurser. Dette førte til bedre integrasjon og dokumentasjon mellom disse teknologiene. 12

45 Produktdokumentasjon 3.2 Microsoft Graph API Microsoft Graph API er et applikasjonsprogrammeringsgrensesnitt laget av Microsoft, som gjør det mulig for oss å utveksle data på tvers av Microsofts programmer og prosjektet vårt. Det blir også lettere å utvikle nye applikasjoner om man har tilgang på et API, fordi det ofte gis forbindelse og adgang til ulike byggeklosser som trengs i utviklingen. Måten vi bruker APIet på er hovedsakelig spørringer som gjør det mulig for oss å hente informasjon om rommene. Denne informasjonen bruker vi til å finne ut hvilke rom som er registrert på domenet, hvilke hendelser brukeren og rommene har kommende, og til å booke et møte. Dette gir oss tilgang til et allerede eksisterende system for lagring av brukere, rom og hendelser. APIet fungerer da som en database for vår app. Tross alle mulighetene APIet har gitt appen vår, har det også noen manglende funksjoner som vi skulle ønsket, og egentlig hadde forventet at den skulle ha. For eksempel så blir et rom, som registreres som ressurs av typen rom i Office Admin Center, behandlet som en bruker i APIet. Vi kan dermed ikke skille mellom brukere og rom på måten vi forventet (usertype). Dette medfører at vi ikke får hente de verdiene vi skulle ønsket fra Office 365 ressursen. 3.3 Azure AD Microsoft Azure Active Directory er Microsofts multi-tenant skybaserte katalogtjeneste for håndtering av brukere, brukerrettigheter og ressurskontroll. Til IT administratorer tilbyr Azure AD kostnadseffektive og lettbrukelige løsninger for å gi ansatte og kunder Single sign-on tilgang til tusenvis av SaaS (Software as a Service) sky applikasjoner. I vårt tilfelle gjør Azure AD det mulig for oss å nesten kun fokusere på å bygge applikasjonen, ved å gjøre det raskt og enkelt for oss å implementere applikasjonen med en av verdens beste katalogtjenester, som allerede brukes av millioner av organisasjoner verden over. Alle bedrifter som har tatt i bruk Office 365 har også en Azure AD tenant, dette er noe som gjør det lettere for oss å distribuere applikasjonen til mindre bedrifter. Disse bedriftene har kanskje ikke midler til rådighet for å investere i ny infrastruktur for å få tilgang til en slik tjeneste. Men siden applikasjonen vår tar i bruk Office 365/Azure AD via APIet, slipper bedrifter som har tatt i bruk Office 365 å investere i ny infrastruktur for å ta i bruk applikasjonen vår. Brukerne av applikasjonen vil på grunn av Azure AD kunne bruke sin jobb e-postkonto (Office 365 konto) til å logge seg på applikasjonen. Microsoft Azure AD og Office 365 kommer naturligvis med en god del sikkerhetsrutiner, monitorerings løsninger og rapporteringsløsninger. Ikke alle disse vil ha noe å gjøre med applikasjonen vår direkte. Men det at ansatte bruker samme pålogging i applikasjonen som de gjør for jobb e-postkontoen deres, gjør at passordstyrken er ivaretatt, samt om de glemmer passordet kan de enkelt opprette et nytt fra Office 365s nettsider. Passordstyrken er ivaretatt ved at et sterkt passord er et kreves for alle Office 365 bruker. 13

46 Produktdokumentasjon 3.4 Frontend - XAML XAML står for Extensible Application Markup Language, og er Microsofts deklarative versjon av XML. Språket beskriver GUIen til applikasjoner. Tidligere ble det brukt samme språk for å utvikle backend og frontend, men XAML er i likhet med HTML, en enkel måte å utvikle GUI på. Syntaksen til XAML kan også minne en del om HTML. Frontend delen av utvikling er i utgangspunktet blitt utviklet i XAML. Vi har blant annet brukt StackLayout og Grid til å plassere de ulike elementene i riktig posisjon på siden. 3.5 Backend - C# C# er et objektorientert programmeringsspråk. Dette er språket vi tar i bruk når vi utviklet applikasjonen. Alle modeller og backend filene er programmert i C# og har derfor.cs filendelser. C# er basert på på Java. Derfor deler det også mange av kjennetegnene til java. C# er en del av Microsoft sin.net initiativ, og er som regel det som brukes når man tar i bruk.net rammeverket. 4 Oppbygging og virkemåte I denne delen av dokumentasjonen vil vi gå gjennom hvordan applikasjonen er bygd opp og forklare de ulike komponentene som til sammen utgjør vår applikasjon. Her vil vi gå i dybden for å forklare hvilke komponenter og elementer som er brukt i applikasjonen, hvordan vi har brukt de og hvordan de fungerer. 4.1 Model-View-ViewModel (MVVM) I prosessdokumentasjonen nevnte vi at vi har valgt MVVM arkitektur til å bygge opp applikasjonen vår. I MVVM arkitektur er det et klart skille mellom utformingen av brukergrensesnittet og presentasjonslogikken. Ved å separere disse to lagene tilrettelegger man blant annet for lettere utvikling, testing, vedlikehold og videreutvikling av applikasjonen. En backend eller frontend utvikler kan jobbe uforstyrret med sin del av applikasjonen uten å komplisere andres arbeid. Når brukergrensesnittet i XAML ikke er tett koblet opp til koden bak, er det enkelt for designere å utøve den friheten de trenger for å være kreative og lage et bra produkt. For vår del var ikke design en så viktig del av prosjektet, men vi ønsker likevel å tilrettelegge for å kunne jobbe på selvstendige deler av koden. Dette øker applikasjonens testbarheten. Ved å flytte brukergrensesnittets logikk til en egen klasse, uavhengig av en brukergrensesnitt-teknologien, blir enhetstesting mye lettere. 14

47 Produktdokumentasjon Figur 11: Illustrasjon av MVVM arkitektur. 15

48 Produktdokumentasjon 4.2 Klassediagram for applikasjonen Figur 12: Klassediagram. Dette diagrammet illustrerer relasjonene mellom klassene som tas i bruk av applikasjonen. Klassene og verdiene i dem er basert på det som returneres etter API spørringene. Modellene våre er basert på klassene event og user, de andre klassene er en del av event klassen som vist i klassediagrammet. 16

49 Produktdokumentasjon 4.3 Applikasjonsstruktur Når vi opprettet en Xamarin løsning i Visual Studio fikk vi valget om hvilke prosjekter vi ønsket å opprette. Basert på prosjektets mål valgte vi tre prosjekter: Hovedprosjektet (Portable), Android prosjekt (.droid), og ios prosjekt (.ios). Ettersom vi valgte å lage felles grensesnitt mellom Android og ios ligger det aller meste av koden i hovedprosjektet. Dersom man skulle tatt i bruk plattform-spesifikke elementer kan man legge inn dette i.ios og.droid prosjektene. All kode i Portable tas i bruk av.droid og.ios prosjektene ved hjelp av Xamarin. Ved å utvikle på denne måten har vi innfridd det ikke-funksjonelle kravet om å utvikle for Android og ios. Figur 13: Bilde av Solution Explorer Databaser Appen har ikke behov for å lagre informasjon om brukerne eller bookinger, derfor tar vi ikke i bruk noen database. All informasjon som er viktig for appen lagres i brukerens Office 365 domene, og appen henter informasjonen den trenger herfra gjennom APIet. På denne måten bruker vi indirekte Office 365 databasen til å hente og lagre den informasjonen vi trenger. 4.4 Teknisk beskrivelse av funksjonalitet Nedenfor gis det beskrivelse av elementer og funksjoner som tas i bruk av appen. Her er beskrivelsene detaljert og tekniske. Vi går trinnvis gjennom hvor og hvordan, elementene og funksjonene brukes. 17

50 Produktdokumentasjon Modeller Resultatet fra Microsoft Graph API er en Json string, dette må overføres til modeller før vi kan bruke dataen. Derfor tar vi i bruk forskjellige modeller når vi kommuniserer med APIet. Disse modellene består av de samme variablene som er definert i Microsoft Graph. Vi tar i bruk tre forskjellige modeller, to av disse er basert på user sin event i Graph. Dette er CalenderModel.cs og SendModel.cs. De har variablene for beskrivelse, start, slutt, og deltakerne. Forskjellen mellom disse kommer i form av at sendmodel har utfylt noen verdier i konstruktøren slik at brukeren blir lagt inn som vert, og at tidssonen blir lagt inn som UTC. I CalenderModel er variablene ikke utfylt med noe, slik at de kan få verdier fra APIet. RoomModel.cs er basert på Graph sine users, dette kommer av at Microsoft Graph ser på rom som brukere. Denne modellen har derfor verdier for e-post, navn og Id. E-post er nødvendig for å invitere rommene til eventen som opprettes. Id er dét som brukes av APIet for å få eventene fra rommenes kalendere Lister Når vi får resultatet fra spørringer til Microsoft Graph får vi tilbake en Json string. Etter å ha deserialisert denne er det ofte vi får en gruppe av verdier. Dette lagrer vi i lister som kan brukes til å hente den informasjonen vi trenger. Vi bruker både enkle arrays og LinkedList. De fleste listene brukt i applikasjonen er ikke synlige for brukerne ettersom de brukes for å finne spesifikke elementer. var data = JsonConvert. DeserializeObject < RoomModel >( medata ); var users = from user in data. value select user; List < RoomModel. value2 > filter = users. ToList < RoomModel. value2 >(); Denne kodebiten viser opprettingen av listen. Her har vi nettopp hentet svar fra Microsoft Graph API og vi konverterer informasjonen fra en Json string til en liste av typen RoomModel. Lista kan så filtreres for den informasjonen vi ser etter Filtrering Listen sorteres så etter filtere vi bruker for å finne møterommene. Dette gjøres ved hjelp av en for løkke som sjekker navnet på alle registrerte e-postadresser og om de følger de satte reglene til hvordan et møterom skal være navngitt. for ( int i = 0 ; i < filter. Count - 1 ; i ++) { char c = filter [ i ]. DisplayName [ filter [ i ]. DisplayName. Length - 1 ]; if (!( Char. IsNumber ( c ))) { filter. RemoveAt ( i ); i --; } } RoomModel. value2 [] a = filter. ToArray (); 18

51 Produktdokumentasjon Etter listen er sortert og filtrert kan vi enkelt ta den i bruk. Dette gjøres både i backend for å finne informasjon i listen, og når vi ønsker å liste elementer for brukeren. Vi lister elementer for brukeren to plasser i applikasjonen; fanen Rom viser liste over ledige og ikke ledige møterom akkurat nå, og Min profil viser liste over fremtidige møter. For å vise disse til brukeren tar vi i bruk et ListView element i XAML filen, og gir den RoomModel arrayet som kilde. Figur 14: ListView med elementer Picker Når brukerne skal booke et møterom må de først gjøre noen valg. Disse valgene utføres ved hjelp av XAML elementet Picker. Denne har en startverdi definert i XAML filen, men blir utfylt i cs filen (BookNowPage.xaml.cs). NumberOfPersonsPicker. Items. Add ( "1 personer" ); NumberOfPersonsPicker. Items. Add ( "2 personer" ); NumberOfPersonsPicker. Items. Add ( "3 personer" ); NumberOfPersonsPicker. Items. Add ( "4 personer" ); NumberOfPersonsPicker. Items. Add ( "5 personer" ); NumberOfPersonsPicker. Items. Add ( "6 personer" ); NumberOfPersonsPicker. Items. Add ( "7 personer" ); NumberOfPersonsPicker. Items. Add ( "8 personer" ); NumberOfPersonsPicker. Items. Add ( "9 personer" ); NumberOfPersonsPicker. Items. Add ( "10 personer" ); StartTimePicker. Items. Add ( "Akkurat nå" ); StartTimePicker. Items. Add ( "Neste halvtime" ); StartTimePicker. Items. Add ( "Neste hele time" ); DurationPicker. Items. Add ( "1 time" ); DurationPicker. Items. Add ( "2 timer" ); DurationPicker. Items. Add ( "3 timer" ); Picker elementet brukes i BookNowPage filene (XAML og cs), til å bestemme antall personer, når møtet skal starte og hvor lenge møte skal vare. Brukeren kan klikke på 19

52 Produktdokumentasjon elementet for å få flere valg. Disse valgene vises til brukeren i form av en popup der brukere kan bla gjennom valgene. Ettersom målet med appen er å gjøre det effektivt og hurtig å booke et møterom har vi begrenset antall valg i picker elementene på BookNowPage. Når brukeren har valgt ønsket antall personer, starttidspunkt og varighet, og har trykket Book NÅ! knappen, blir denne informasjonen sendt til en metode i cs filen. Figur 15: Picker for antall personer I RoomInfoPage tar vi også i bruk picker elementer. Her bruker vi elementene TimePicker og DatePicker. Disse er lingnende pickerene i BookNowPage, men har istedenfor faste elementer. Timepicker har verdiene for timer og minutter i døgnet. DatePicker har valg av datoer som lagres i DateTime formatet. Verdiene i Datepicker og Timepicker slås sammen til en DateTime som blir sendt videre til cs metoden når brukeren trykker på Book knappen. 20

53 Produktdokumentasjon Figur nr 16: DatePicker i RoomInfoPage API spørringer Get-Spørringer Vi tar i bruk API spørringer for det meste av backend funksjoner. Dette gjøres ved at vi lager en HttpClient variabel og legger inn authentication token, for så å Clienten med graph spørringen: var client = new HttpClient (); client. DefaultRequestHeaders. Accept. Add ( new MediaTypeWithQualityHeaderValue ( "application/json" )); client. DefaultRequestHeaders. Authorization = new AuthenticationHeaderValue ( "Bearer", App. AuthenticationResult. AccessToken ); var medata = await client. GetStringAsync ( " e,'m')" ); var data = JsonConvert. DeserializeObject < RoomModel >( medata ); De fleste av spørringene vi sender til APIet er Get spørringer. Get spørringer er spørringer der vi henter info fra APIet om noe bestemt. Dette varierer fra liste over brukere til å hent ut info om events. Get spørringer resulterer i en return av typen Json string. For at infoen skal kunne tas i bruk er blir så omgjort til objekter av riktig type fra Json string, dersom det er flere elementer blir dette lagret i en liste Post-Spørringer Når vi oppretter møter i BookNowPage og i RomInfoPage tar vi i bruk Post spørringer. Post spørringer er for å skrive noe til APIet. Dette gjøres på en litt annen måte ettersom det her er 21

54 Produktdokumentasjon nødvendig å fylle modellen med verdier for så å serialisere det til Json string før det sendes med HttpClienten i spørringen. SendModel. value2 meeting = new SendModel. value2 ( "Møte på " + a [ i ]. DisplayName, date. ToString ( "yyyy-mm-ddthh:mm:ss.fff" ), end. ToString ( "yyyy-mm-ddthh:mm:ss.fff" ), a [ i ]. Mail, a [ i ]. DisplayName ); Formatting. Indented ); string json = JsonConvert. SerializeObject ( meeting, var httpcontent = new StringContent ( json, Encoding. UTF8, "application/json" ); using ( var httpclient = new HttpClient ()) { httpclient. DefaultRequestHeaders. Accept. Add ( new MediaTypeWithQualityHeaderValue ( "application/json" )); httpclient. DefaultRequestHeaders. Authorization = new AuthenticationHeaderValue ( "Bearer", App. AuthenticationResult. AccessToken ); var httpresponse = await httpclient. PostAsync ( " httpcontent ); if ( httpresponse. Content!= null) { var send = await httpresponse. Content. ReadAsStringAsync (); MainLabel. Text = send. ToString (); } } Logg inn For første gangs innlogging sendes brukeren til en Microsoft innloggingsside, og appen venter på svar fra Microsoft angående innloggingen. Her sendes clientiden, som er hentet fra azure AD, med slik at Microsoft vet at det er appen Bravo Booking som forsøker å logge inn en bruker, og Microsoft vet hvilke rettigheter appen trenger. App. AuthenticationResult = await DependencyService. Get < IAuthenticator >(). Authenticate ( authority, graphresourceuri, clientid, returnuri ); Vi tar så i bruk en hjelpeklasse; IAuthenticator.cs som tar seg av selve autentiseringen av det svaret som Microsoft sender: Task < AuthenticationResult > Authenticate ( string authority, string resource, string clientid, string returnuri ); Dette resulterer i en Token som vi kan bruke ved alle API spørringer for å bekrefte hvem som prøver å utføre spørringen. Med denne Tokenen slipper man også å foreta innlogging på nytt neste gang man kjører appen. 22

55 Produktdokumentasjon 5 Samsvar mellom produkt og kravspesifikasjon Kravspesifikasjonen vedrørende prosjektet har endret seg en del underveis ettersom oppdragsgiver ikke hadde noen konkrete krav i starten av prosjektet. Vi har derfor utviklet smidig. I den endelige kravspesifikasjonen har vi også prioritert viktigheten/nødvendigheten med de ulike funksjonalitetene. Oppdragsgiver ønsker en applikasjon som danner grunnlag for et fremtidig verktøy for sine ansatte og salgsvare til sine kunder. Med tanke på tidsperspektivet har de derfor bare krevd de funksjonaliteter som er kritiske for at applikasjonen skal fungere, og ikke lagt så mye vekt på ekstra funksjoner og design. Ettersom en del av kravene i kravspesifikasjonen hadde lav-middels prioritering, er det et par funksjonaliteter som ikke er implementert. Vi har selvsagt hatt fokus på å implementere de funksjonaliteter som er kritiske og nødvendige for at appen skal virke til sitt formål. Omtrent alle kravene med høy prioritet er oppnådd. Vi er fornøyde med sluttproduktet til tross for at det er et par funksjonaliteter som mangler. Grunnen til at vi mangler noen av funksjonalitetene med lavere prioritet er at vi rett og slett ikke hadde tid til å implementere de på en god måte. Dette har vi formidlet til oppdragsgiver. Vi anser læringskurven som bratt og mener at vi ville fått implementert flere av de nevnte funksjonalitetene om vi hadde hatt mer kunnskap om teknologiene fra før. 5.1 Krav som ikke er oppfylt i sluttproduktet Det er ulike grunner til at noen av de funksjonelle kravene i kravspesifikasjonen ikke er oppfylt. Under gis det en liste med forklaring over kravene som ikke er med i det endelige produktet vårt. Kravene er utformet som brukerhistorier, og vil derfor avvike fra hvordan de er formulert i kravspesifikasjonen Kalender Som bruker ønsker jeg å booke et rom med en kalender - prioritet: lav At brukere skal kunne få se en kalenderoversikt over et spesifikt rom, og deretter booke rommet på ledig tid og dato, hadde middels prioritering. Planen var å importere kalenderen fra Office, slik at brukeren fikk se kommende events på samme måte som i Outlook. Dette lot seg ikke gjøre ettersom Microsoft Graph ikke lot oss hente ut hele kalenderen, men kun hendelsene som ligger i brukerne sine kalendere. Vi håpet så på å få implementert en kalender i Xamarin, for å fylle den med de hendelsene vi hentet. Vi hadde gått utifra at Xamarin.Forms skulle ha et objekt for å implementere kalenderen, og var dermed ikke så tidlig ute med denne funksjonaliteten. Men da vi skulle implementere kalenderen fant vi ut at det ikke finnes noe element for dette. I og med at vi hadde en felles GUI for ios og Android, måtte vi ha implementert et kalender element for hver av dem. Det andre alternativet hadde vært å manuelt lage en kalender i Xamarin.Forms for å løse problemet. At vi kunne løse problemet på denne måten fant vi ut litt for sent. Det ble dermed ikke implementert, ettersom hvor krevende dette ville være. 23

56 Produktdokumentasjon Ettersom vi ikke fikk implementert kalender elementet valgte vi å løse problemet ved å legge inn tid og dato pickere i rommene under Rom fanen. Dette betyr at funksjonaliteten om å booke et rom på ønsket dato er oppfylt selv om brukeren ikke kan gjøre det via en kalender. Denne løsningen ble godt mottatt av Bravo, som uttrykte at de syntes dette var en bedre løsning. I og med at en picker passer bedre på en mobilapplikasjon siden den lett lar deg bla gjennom datoer på en familiær måte. I tillegg kunne man heller ha booket i Outlook dersom man vil gjøre dette via en kalender. På grunn av at vi løste problemet på en alternativ måte, delte vi det tidligere kravet en bruker skal kunne booke et rom på ønsket dato via kalenderen opp i to ulike krav hvor kun en av dem nå er oppfylt. Kravet som ikke er oppfylt er brukerhistorien: Som bruker ønsker jeg å booke et rom med en kalender. Mens kravet om å booke på ønsket dato er oppfylt og nevnt i punkt Filtrering av romoversikt Som bruker ønsker jeg å filtrere oversikten over møterom etter gitte kriterier - prioritet: lav I fanen Rom var planen å ha en undermeny med alternativene kalender og romoversikt. Som allerede nevnt er kalenderen ikke implementert og begrunnes i avsnittet over, derfor valgte vi å droppe undermenyen. Rom inneholder på grunn av dette kun en oversikt over alle rommene i bedriften, og ikke en kalender. I kravspesifikasjonen er det presisert at listen over rommene skal kunne filtreres, ettersom brukeren kan ha behov for å søke etter rom med spesielle kriterier. Det skulle blant annet være mulig å filtrere på antall personer og utstyr, ved hjelp av sjekkbokser. Filtreringen lot seg ikke gjøre da Microsoft Office 365 ikke har noe system for å registre utstyr på rom. Utstyr kan registreres som ressurser men kan ikke kobles til et rom. Vi fant noen andre potensielle måter å gjøre dette på, men ingen som var tilstrekkelig gode nok. Her kreves det mer tid for å finne en god løsning. En potensiell løsning, kunne vært å registrere utstyr i rommets telefonnummer felt. Dette tenker vi at kan være en god løsning da de fleste rom ikke benytter telefoner lenger, og dermed ikke trenger feltet til det formålet. Feltet for telefonnummer er per i dag også et av de eneste feltene fra rom man kan hente med APIet. Kravet hadde lav prioritet, og at det er uoppfylt påvirker derfor ikke applikasjonen nevneverdig Kansellere booking Som bruker ønsker jeg å kansellere en booking - prioritet: middels At en brukeren skal ha mulighet til å kansellere en booking var først en funksjonalitet med høy prioritet når vi så for oss å lage en selvstående applikasjon. Men ettersom web-grensesnittet til Microsoft Office 365 (via kalender) uansett gjør det mulig å kansellere en booking, var dette ikke like kritisk lenger etter at vi hadde tatt i bruk APIet. At kravet ikke er oppfylt påvirker derfor ikke applikasjonen på en negativ måte. 24

57 Produktdokumentasjon 6 Sikkerhet ved applikasjonen Applikasjoner som håndterer sensitiv data og er allment tilgjengelig har et stort behov for sikkerhet. For oss er situasjonen litt annerledes. Selv om applikasjonen kommer til å ligge tilgjengelig i App Store og Google Play Store, må man ha en Office 365 bruker i et domene hos en bedrift som har tatt i bruk løsningen. Dette begrenser hvem som kan ta i bruk appen. Selv med begrenset brukerbase og mindre lagret sensitiv data er sikkerhet noe som har vært viktig å ta hensyn til under utviklingen av appen. 6.1 Brukerhåndtering I og med at vi tar i bruk Microsoft Graph API og brukere av applikasjonen allerede må være registrerte brukere av Office 365 blir det meste av sikkerhetsrutiner håndtert av Microsoft, noe som er en fordel da Microsoft har gode sikkerhetsrutiner. Det eneste som lagres av appen er en autentiserings token, denne er nødvendig ettersom den må brukes for å gjøre spørringer til APIet. Tokenen er kryptert og vi har ingen mulighet til å lese den da vi bare sender den til APIet for å autentisere den påloggede brukeren. På denne måte oppfylles også det ikke-funksjonelle kravet om at brukerens og bedriftens sikkerhet skal ivaretas. Ettersom info sendes fra appen til Microsoft og tilbake over internett er det viktig at brukerne selv kontrollerer at de er koblet til et sikret nett for å unngå at noen fanger opp sendingene. Dersom appen videreutvikles til for eksempel å kunne brukes offline til å huske kommende møter blir det mer viktig å sette fokus på sikkerhet og hvordan data lagres. 7 Installasjon for videreutvikling og lokal kjøring For å få riktig utviklingsmiljø og korrekt oppsett må man sørge for å Installere Visual Studio. (Xamarin krever dette, eller den utdaterte Xamarin Studio som vi ikke anbefaler) og Installere tilleggsteknologien Xamarin i VS. Prosjektet kan klones fra GitHub repositorien fra: For å kjøre applikasjonen må man enten ha en smarttelefon (av typen Android eller ios) koblet til Visual studio, eller ta i bruk en emulator. (Merk: kjøring på Iphone emulator krever Visual studio på en Mac, eller en Mac koblet til Visual Studio.) Android emulator: For å ta i bruk Android emulatoren i Visual studio må man åpne Android AVD fra verktøylinjen i Visual Studio. Her kan man trykke på Create for å opprette en Android enhet med ønskede innstillinger. Når en enhet er konfigurert kan man kjøre appen på emulator. Man velger å kjøre prosjektet Bravobooking.droid, og emulatoren som er konfigurert. ios emulator: 25

58 Produktdokumentasjon For å ta i bruk ios emulatoren i Visual Studio er det nødvendig å enten kjøre Visual Studio fra en Mac, eller at man har koblet en Mac til Visual Studio. MacinCloud er en mulig løsning dersom man ikke har en fysisk Mac. For å kjøre en Iphone emulator velger man prosjektet Bravobooking.iOS, velger Iphone.Simulator. For så å velge en Iphone type og kjøre appen. For å logge inn i applikasjonen er det et par krav: Mailadresse og passord til en Office 365 bruker. Admin i domenet til bruker må ha akseptert appen sine rettigheter til kalendere og brukere, og møterommene registrert på domenet må være satt opp etter reglene for appen. For testing av appen har vi opprettet et domene med møterom og brukere, dette domenet er tilgjengelig fram til: med brukernavn: Bruker@group37.onmicrosoft.com og passord Bachelor37. Potensielt problem med kjøring av applikasjonen i debugg mode er at appen gir Initialize component error. Disse errorene hindrer som regel ikke applikasjonen fra å kjøre. Dette kan løses ved å endre namespacet i xaml filen, lagre også endre det tilbake. 8 Testing 8.1 Mål med testing Testing er en viktig del av utviklingen av applikasjoner og programmer. Hensikten med å teste applikasjonen er for å kartlegge eventuelle feil, svakheter og mangler med løsningen slik at den skal kunne bli best mulig. I noen tilfeller (avhengig av hva som skal utvikles), er det oppfordret å skrive testplan allerede før implementeringen starter. Vi har derimot utført testingen på den ferdigstilte applikasjonen, med tanke på tidsrammen og at applikasjonen fungerer som en prototype. Prototyper trenger ikke være helt feilfrie. Hele poenget med å lage prototyper før det endelige sluttproduktet er for å teste det ut. 8.2 Enhetskonfigurasjoner og verktøy Følgende maskinkonfigurasjon er benyttet under brukertestingen: Lenovo PC 15 tommer - Operativsystem: Windows 10 - Visual Studio Xamarin - Android Emulator - MacinCloud via eksternt skrivebord 26

59 Produktdokumentasjon 8.3 Testplan I starten av prosjektet hadde vi planer om å gjøre grundig testing av applikasjonen, men vi lagde ikke en konkret testplan. Senere i prosjektet fant vi ut av vi ikke fikk tid til å teste applikasjonen så grundig som vi hadde tenkt i starten, noe som er et typisk scenario for mindre erfarne utviklere. Tatt i betraktning at vårt program er en prototype og at sensitive data blir håndtert av Microsoft Graph API, konkluderte vi med at det vi kunne nøye oss med å gjøre et par brukertester og enhetstester for vår løsning. Underveis i utviklingen testet vi løsningen jevnlig på både Android emulator og MacinCloud. 8.4 Sikkerhetstesting Etter som dette fungerer som en prototype, var utviklingen av funksjoner hovedfokuset vårt. Programmet krever at brukerne logger på en konto med et brukernavn og et passord. Derfor er testing også avgjørende for sikkerheten av applikasjonen. I vår situasjon er det APIet som tar seg av det meste av sikkerheten, og vi slipper dermed å bekymre oss for mye av denne delen av testing/sikkerhet. 8.5 Brukertesting Under implementeringen kan vi si at vi gjorde brukertesting jevnlig. En brukertesten er imidlertid hovedsaklig blackbox testing, noe som betyr at personen som tester ikke trenger å ha kjennskap til koden, og fordi vi er godt kjent med applikasjonen fra før, tenkte vi det ville være mer nyttig å teste det på en person som ikke har sett applikasjonen vår før, for å sjekke brukervennligheten for alle type brukere. Formålet med brukertesten var undersøke om applikasjonen fremstår som intuitiv for andre også. Det første trinnet med brukertesting er å liste opp alle mulige funksjoner/handlinger i programmet. De er oppført i kravspesifikasjonen vår, men vi har delt opp brukerhistoriene for å gjøre det enda mer tydelig for brukeren hva de kan oppnå. En enkel måte å gjennomføre dette på er å lage en sjekkliste, slik at når du kjører programmet som bruker, kan man markere hvilken funksjonaliteter som fungerer som ønsket. Utenforstående personer ble satt til å utføre alle oppgavene i testplanen uten innspill fra gruppen. Vi ville observere hvordan personene oppfattet ulike labels og beskjeder. Og om de faktisk fikk til å booke et rom uten hjelp, som er formålet med appen. Funksjonalitet Test Resultat Logge inn Logge inn på applikasjonen med gitt brukerinfo OK Velge antall personer Velge antall personer til møtet OK Velge starttidspunkt Velge starttiden for møtet OK Velge varighet Velge tidsvarigheten for møtet OK 27

60 Produktdokumentasjon Booke rom Klikke på "Book nå" knappen for å fullføre bookingen Få beskjed om booking Får en tilbakemelding på booking statusen OK Se liste over møterommene Klikke på "Rom" for å se en oversikt over møterom OK Se hvilke rom som er ledige nå Rommene som er ledige nå er markert for det OK Se egne bookinger Se informasjon om den som er logget inn Se informasjon om møterommene Booke rom på ønsket tid og dato Klikk på Min profil og se liste over fremtidige bookinger OK OK Naviger deg til Min profil, her vil informasjonen stå OK I fanen Rom, klikk på et av rommene i listen over alle møterommene, skal få informasjon om det valgte rommet I fanen Rom velges det tid og dato og klikker Book OK OK Oppgavene i testplanen er alle funksjonalitetene vi har implementert. Vi testet på ulike personer, både datakyndige og mindre datakyndige. Resultatet ble som oftest det vi ønsket og alle handlingene ble utført nesten helt uten hjelp. Den eneste plassen vi måtte gi et lite hint var når noen av testerne skulle finne oversikt over rommene. 8.6 Enhetstestning Enhetstesting gjelder testing av individuelle biter av kildekode, og skal sørge for at de individuelle delene av programmet fungerer som de skal. Vi fant ut at Xamarin har en effektiv løsning for enhetstesting av Xamarin applikasjoner ( ). VI hadde et ønske om å gjennomføre enhetstester på denne måten, men fikk ikke tid til å sette oss inn i denne løsningen. Det ikke-funksjonelle kravet om at applikasjonen skal være godt testet er lavt prioritert i kravspesifikasjonen. Ettersom Bravo ønsket en prototype/alpha var ikke enhetstestingen i hovedfokuset. 9 Videreutvikling Når det gjelder videreutvikling er det snakk om finpuss av applikasjonen, og eventuelt innføre andre enkle funksjoner til fordel for de ulike bedriftene. Det skal helst ikke suppleres med mange store funksjonaliteter ettersom hovedformålet med appen er at den skal være rett på sak, enkel å bruke/simpel og uten masse tilleggsfunksjoner som får den til å virke komplisert. Applikasjonen skal være brukervennlig. Vi har et par tanker om videreutvikling av appen. Hadde vi hatt mer tid hadde vi implementert funksjoner som gjør at appen varsler om møter. F.eks. Husk møte på rom romnavn kl Dette ville kreve lagring av data om kommende møter. 28

61 Produktdokumentasjon Mer videreutvikling kan også komme i form av flere filtervalg for møterom og muligheter for booking lengre frem i tid. Filtervalg vil kreve at man finner en måte å lagre flere attributter på møterommene i Office 365. Vi hadde også ideer som kan gjøre applikasjonen enda mer effektiv til formålet. En ny skjerm for Innstillinger, kunne latt brukeren endre på personlige standard preferanser for møterommet som skal bookes. Man kan eksempelvis sette 6 som standardverdi for antall personer, om man vanligvis er 6 eller flere personer som trenger møterom. Dette gjelder også de andre valgalternativene. Dersom utstyrslisten hadde vært på plass hadde vi hatt muligheten til å endre preferanser til å alltid prioritere et rom som har. whiteboard, projektor eller de utstyrene en måtte ønske. Da vil ikke brukerne trenge å justere valgene i Pickeren hver gang de skal booke et møterom. Denne muligheten kunne gjerne vært utformet som en egen fane i hoved-navigeringsmenyen, men vi puttet inn et ikon som indikerer innstillinger/preferanser i Min profil. 29

62 Høgskolen i Oslo og Akershus Fakultet for Teknologi, Kunst og Design Hovedprosjekt i Informasjonsteknologi 2017 Gruppe 37 Kravspesifikasjon

63 Kravspesifikasjon 1 Forord Kravspesifikasjonen vår ble ikke ferdigstilt i begynnelsen av prosjektet. Oppdragsgiver hadde få krav i begynnelsen, og vi holdt derfor mulighetene åpne ved å utvikle smidig og tillate endringer i kravspesifikasjonen underveis. Gjennom utviklingsprosessen har vi tilføyd og fjernet funksjonaliteter ettersom vi har funnet bedre løsninger og gjort prioriteringer som har blitt tatt sammen med Bravo. Vi har brukt dokumentet til å holde oss på riktig kurs under utviklingen. Dette dokumentet er vår endelige kravspesifikasjon. 1

64 Kravspesifikasjon Innhold 1 Forord 1 2 Presentasjon 3 3 Forord 4 4 Leserveiledning 4 5 Systembeskrivelse 4 6 UML-diagram 5 7 Krav til dokumentasjon 6 8 Rammekrav 6 2

65 Kravspesifikasjon 2 Presentasjon Gruppe 37 Joakim Hanssen Lund Johannes Strige Synne Storhaug Intern veileder ved HiOA Ismail Hassan Ismail.Hassan@hioa.no Tlf: Oppdragsgiver Bravo Solutions AS Tlf: Grev Wedels Plass Oslo Kontaktperson Lars Andrup-Næss lars@bravoso.no Tlf: Oppdragsgiver Dette prosjektet utføres i samarbeid med Bravo Solutions og søsterselskapet Bravo Audiovisual. Bravo Solutions AS er en ung leverandør av skytjenester med fokus på fleksible og moderne IT-løsninger for digitalisering av bedrifters arbeidshverdag. Bravo Solutions jobber mye med Office 365 og Azure. De har stor fokus på at kundenes medarbeidere skal få nødvendig opplæring og motivasjon for å ta i bruk ny teknologi. Solutions leverer komplette IT-løsninger og fungerer som en one-stop shop for både hardware, software og support. Oppgaven Bravo Solutions er interessert i en applikasjon som gjør det mulig for deres ansatte å booke møterom. Det er også aktuelte for dem å selge løsningen videre til sine kunder, hvis den videreutvikles og ferdigstilles. Har som mål å forenkle dagens løsning på problemet, med å invitere møterom i outlook kalender. Bakgrunn Prosjektideen fikk sitt utspring gjennom idemyldringen mellom gruppen og Bravo Solutions. De ansatte i Bravo har ingen effektiv måte å booke møterom på. Dagens løsningen er at de må invitere møterom i kalenderen. 3

66 Kravspesifikasjon 3 Forord Kravspesifikasjonen vår var ikke fastsatt før vi begynte å implementere løsningen. Oppdragsgiver hadde få krav i begynnelsen, og vi holdt derfor mulighetene åpne ved å utvikle smidig og tillate endringer i kravspesifikasjonen underveis. Dermed avviker den endelige kravspesifikasjonen vår en del fra førsteutkastet. Formålet med kravspesifikasjonen er at det skal være enighet om sluttproduktet mellom oppdragsgiver og gruppen vår. Bravo Solutions har uttrykket deres krav, og vi har lagt til flere underveis som de har godkjent. 4 Leserveiledning Kravspesifikasjonen inneholder ulike krav Kravspesifikasjonen er delt opp i en forklaring av hvordan systemet er bygget opp. Hvilke krav som er satt av oppdragsgiver for systemet. Disse kravene er igjen delt opp i funksjonelle og ikke-funksjonelle krav. Til slutt kommer rammebetingelsene som er satt. 5 Systembeskrivelse Bravo Solutions ønsker en applikasjon som gjør det mulig for deres ansatte og eventuelt deres kunder å kunne booke et møterom. Har som mål å forenkle og effektivisere den allerede eksisterende løsningen. Ved å ta i bruk appen oppnår man en rask og enkel måte å kunne booke møterom på i forhold til å invitere rom fra Office365 kalenderen Funksjonelle krav Nr Funksjonelle krav Prioritet 1 Applikasjonen skal booke møterom ved å invitere rom via Office 365 Høy 2 En bruker skal kunne logge inn med sin Office 365 konto Høy 3 En bruker skal kunne booke et rom nå Høy 4 En bruker skal kunne booke et rom på ønsket tid Høy 5 En bruker skal kunne velge antall personer, starttidspunkt og varighet for møterommet Middels 6 En bruker skal kunne se en oversikt over alle møterommene i bedriften Middels 7 En bruker skal kunne se om møterommene er ledige eller opptatt akkurat nå Middels 8 En bruker skal få informasjon om rommet når den klikker på et rom i listen Middels 9 En bruker skal kunne booke et rom på ønsket dato Middels 10 En bruker skal kunne booke et spesifikt rom Middels 4

67 Kravspesifikasjon 11 En bruker skal kunne booke et rom med en kalender Lav 12 En bruker skal kunne se en oversikt over kommende møter Lav 13 En bruker skal kunne kansellere en booking Lav 14 En bruker skal kunne filtrere oversikten over møterom etter gitte kriterier Lav Ikke-funksjonelle krav Nr Ikke-funksjonelle krav Prioritet 1 Applikasjonen skal være tilgjengelig for både ios og Android Høy 2 Applikasjonen skal ivareta brukerens og bedriftens sikkerhet Høy 3 Applikasjonen skal være enkel å bruke Høy 4 Applikasjonen skal være godt testet Lav 5 Applikasjonen skal gjenspeile Bravos estetiske profil Lav 6 UML-diagram 5

68 Kravspesifikasjon Figur 1: Use-case diagram. 7 Krav til dokumentasjon Bravo hadde ingen andre spesifikke krav angående dokumentasjonen av prosjektet enn de krav som HiOA stiller til hovedprosjektet. Dokumentasjonen vedrørende prosjektet skal derfor være utformet som en sluttrapport som inneholder de to hoveddelene Prosessdokumentasjon og Produktdokumentasjon, samt andre vedlegg. Ved å lese dokumentasjonen skal man lett kunne sette seg inn i arbeidet for å få god innsikt i prosessen og produktet. 8 Rammekrav Bravo hadde et ønske om at applikasjonen skulle integreres med Office 365 ettersom dette allerede er en utbredt løsning, og det er løsningen de allerede bruker i dag for booking av møterom, samt løsningen mange andre bedrifter også tar i bruk. Dette er det eneste klare rammekravet vi har fått fra Bravo. 6

69 Høgskolen i Oslo og Akershus Fakultet for Teknologi, Kunst og Design Hovedprosjekt i Informasjonsteknologi 2017 Gruppe 37 Bruker- og adminveiledning

70 Bruker- og adminveiledning Innhold 1 Forord 2 2 Innledning 2 3 Adminveiledning 2 4 Brukerveiledning Logg inn Book nå-fane Velge kriterier Booke møterom Beskjed Rom-fane Romoversikt Rom-info Min profil-fane Brukerinfo Oversikt over fremtidige bookinger 4 1

71 Bruker- og adminveiledning 1 Forord Dette er en forklarende dokumentasjon om hvordan brukere og administrator tar i bruk Bravo Booking. Veiledningen forutsetter at bedriften har tatt i bruk Office 365. Før appen kan brukes som den skal av ansatte i bedriften må admin av Office 365 domenet utføre oppsett for applikasjonen, i Office 365. Veiledning er derfor delt inn i to deler, en for brukere og en for admin. Vi mener at appen er laget intuitivt med familiære elementer og innarbeide begreper og ikoner. 2 Innledning Applikasjonen skal brukes av Bravos ansatte og mulig også kunder av dem. Brukerveiledningen vil derfor fungere som en manual for bruk av applikasjonen. Manualen er sortert kronologisk med de handlinger som er mulige å utføre for en bruker. Den skal være forholdsvis enkelt å forstå fremgangsmåten. For brukerne målgruppen går vi ut fra at de har en viss erfaring med smarttelefoner og apper. Det skal dermed ikke bli et problem for dem å forstå interaksjonen med appen. Det kreves ingen tekniske ferdigheter for å kunne benytte seg av applikasjonen som bruker. 3 Adminveiledning En admin i bedriftens Office 365 domenet må registrere rommene til bedriften som ønsker å ta i bruk Bravo Booking. Dette gjøres ved å logge seg inn i Office 365 admin center (portal.office.com/adminportal/). Her går man inn i Ressurser->Rom og utstyr og legger til alle rommene man ønsker skal inkluderes i løsningen. Rommene må legges inn etter følgende regler: Rommene må registreres med navn Mx kapasitet: y (der x er et tall fra 1 til 99 og y et tall fra 01 til 99) med kapasitet menes det hvor mange personer det er plass til i rommet. Rommene må da også ha e-postadresse lik navnet (eks. M1@gruppe37 ). Bildet under viser oppsett av eksempel-rommet M1. 2

72 Bruker- og adminveiledning 4 Brukerveiledning Vi vil nå beskrive alle handlingene brukere kan gjøre i kronologisk rekkefølge og navigering. 4.1 Logg inn Klikk på Logg inn for å bli sendt videre til Microsofts globale innloggingsside. Skriv inn brukernavn og passord til Outlook konto, og klikk på Logg inn. Hvis brukeren har skrevet inn feil brukernavn eller passord vil den få beskjed om dette. Det er mulig å tilbakestille passord via Office Book nå-fane Velge kriterier Etter å ha logget inn med riktig brukernavn og passord blir man videreført direkte til hovedfanen Book nå. Her får brukeren flere muligheter. Velg antall personer ved å klikke på default verdien i picker-feltet. På samme måte velger man også starttidspunkt og varighet Booke møterom Når møtebookingen har de ønskede verdiene klikker brukeren på Book NÅ Beskjed Brukeren vil da få beskjed om møtet ble booket eller ikke. Hvis møte ikke ble booket vil det bli gitt en forklarende tekst Det er dessverre ingen rom som passer dine kriterier som betyr at det ikke finnes ledig rom for x antall personer på gitt tid. Hvis rommet blir booket får brukeren beskjed om Rommet er booket. 3