Sluttrapport – Gruppe 26 24.05.2020 1 Bachelorprosjekt 2020 Rombookingsystem for TietoEvry Gruppe 26 Cato Hilmi Akay s326326 Fredrik Haugerud Pedersen s306631 Nikita Petrovs s325918 Victor Klougman Pishva s325871 Sluttrapport – Gruppe 26 24.05.2020 2 BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Rombookingsystem DATO 24.05.2020 ANTALL SIDER / BILAG PROSJEKTDELTAKERE Cato Hilmi Akay (s326326) Fredrik Haugerud Pedersen (s306631) Nikita Petrovs (s325918) Victor Klougman Pishva (s325871) INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER TietoEvry KONTAKTPERSON Trond - Ivar Maanum SAMMENDRAG Gruppen har utviklet et rombookingssystem beregnet for bedrifter med hyppig møtevirksomhet, der hensikten er å gjøre rombookingsprosessen så enkel og effektiv som overhodet mulig for sluttbrukeren. Løsningen kommer i form av et backend REST API utviklet i Java/Spring Boot, og en klientapplikasjon utviklet i Javascript rammeverket React, og er beregnet på integrasjon i systemer som benytter seg av Azure Active Directory. 3 STIKKORD Rombooking Azure Webapplikasjon Institutt for Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse : Holbergs plass , Oslo Telefon: 22 45 32 00 PROSJEKT NR. 26 TILGJENGELIGHET Åpen Sluttrapport – Gruppe 26 24.05.2020 3 Forord Denne rapporten er sluttproduktet av vårt bachelorprosjekt ved OsloMet – Storbyuniversitetet våren 2020, hvor vi har utviklet to separate applikasjoner som til sammen utgjør en løsning. Rapporten er hovedsakelig beregnet på lesere med en forståelse for informasjonsteknologi og programmering, da spesielt utvikling av webapplikasjoner . Sentrale kapitler er forsøkt tilrettelagt for les ere med få eller ingen forhåndskunnskaper, mens mer teknisk orienterte seksjoner prøver å ta høyde for at leseren ikke er kjent med alle teknologier eller konsepter. For en leser som kun er interessert i en innføring i prosjektets bakgrunn og resultat, anbefales det å lese kapittel 1, 2, 3 og 9. For leseren som ønsker en mer grundig forståelse av løsningen anbefales det å lese rapporten i sin helhet i kronologisk rekkefølge. Dokumentet er tilrettelagt for digital lesning med lenker som peker ti l andre steder i rapporten, og henvisning til eksterne innlegg og artikler for å forklare enkelte konsepter og teknologier. Det anbefales derfor å lese på en digital enhet med en Internett - tilkobling. Det er derimot ikke et problem å lese rapporten i sin h elhet på papirformat. Lenker til eksterne artikler, eller andre deler av rapporten, forekommer som tekst med blå skrift og understrek Henvisning til kilder forekommer som et siffer med parentes rundt (1) En liste over alle kilder er å finne i vedlegg E - K ilder Fremmedord og faguttrykk står i kursiv , og er første gang de forekommer i teksten annotert med et opphøyd siffer 1 og en medfølgende fotnote tekst på bunnen av siden. Kommentarer til teksten er også annotert på denne måten, men står ikke i kursiv. 1 Eksempel på fotnotetekst Sluttrapport – Gruppe 26 24.05.2020 4 Innholdsfortegnelse Forord ................................ ................................ ................................ ................................ ......... 3 1 Innledning ................................ ................................ ................................ ............................... 8 1.1 Gruppen ................................ ................................ ................................ ........................... 8 1.2 Veiledere ................................ ................................ ................................ ........................ 10 1.2.1 Veileder fra OsloMet ................................ ................................ ............................... 10 1.2.2 Veiledere fra TietoEvry ................................ ................................ ........................... 10 1.3 Oppdragsgiver ................................ ................................ ................................ ................ 11 2 Problemstilling og omfang ................................ ................................ ................................ .... 12 2.1 Bakgrunn for prosjektet og dagens situasjon ................................ ................................ 12 2.1.1 Dagens løsning ................................ ................................ ................................ ........ 12 2.2 Problems tilling og prosjektets omfang ................................ ................................ .......... 14 2.2.1 Målgruppe ................................ ................................ ................................ ............... 14 2.2.2 Avgrensninger ................................ ................................ ................................ ......... 15 3 Resultat ................................ ................................ ................................ ................................ 16 3.1 Rombookingsløsningen ................................ ................................ ................................ .. 16 3.2 Unde r Panseret ................................ ................................ ................................ .............. 19 3.2.1 Utfordringer ................................ ................................ ................................ ............ 19 3.3 Metrikk og Akseptansetesting ................................ ................................ ....................... 20 3.3.1 Metriske Verdier ................................ ................................ ................................ ..... 20 3.3.2 Akseptansetesting ................................ ................................ ................................ ... 22 4 Metodikk og Planlegg ing ................................ ................................ ................................ ....... 23 4.1 Kravspesifikasjon ................................ ................................ ................................ ............ 23 4.1.1 Samtaler med kunden ................................ ................................ ............................. 23 4.1.2 Fu nksjonelle og ikke - funksjonelle krav ................................ ................................ ... 24 4.1.3 Krav til Dokumentasjon ................................ ................................ ........................... 25 4.2 Brukerhistorier ................................ ................................ ................................ ............... 26 4.3 Metodikk ................................ ................................ ................................ ........................ 27 4.3.1 Scrum ................................ ................................ ................................ ...................... 27 4.3.2 Implementasjon av Scrum - metodikken ................................ ................................ .. 29 4.3.3 Planning Poker ................................ ................................ ................................ ........ 31 4.3.4 Sprintene ................................ ................................ ................................ ................. 31 5 Teknologier og Verktøy ................................ ................................ ................................ ......... 33 5.1 Java og Spring Boot ................................ ................................ ................................ ........ 34 5.1.1 Andre teknologier i backend ................................ ................................ ................... 34 Sluttrapport – Gruppe 26 24.05.2020 5 5.1.2 Retningslinjer Java ................................ ................................ ................................ .. 36 5.2 Javascript og React ................................ ................................ ................................ ......... 37 5.2.1 Retningslinjer Javascript ................................ ................................ ......................... 38 5. 3 Databaser ................................ ................................ ................................ ....................... 39 5.4 Infrastruktur, Versjonskontroll og Prosjektstyring ................................ ........................ 40 5.4.1 Utfordringer med Infrastruktur ................................ ................................ .............. 41 5.4.2 Retningslinjer for Git ................................ ................................ ............................... 42 6 Pr oduktpresentasjon: Backend ................................ ................................ ............................. 44 6.1 Prosjektstruktur og Lagdeling ................................ ................................ ........................ 44 6.1.1 Domain ................................ ................................ ................................ .................... 45 6.1.2 Repositories ................................ ................................ ................................ ............ 45 6.1.3 Services ................................ ................................ ................................ ................... 46 6.1.4 Web ................................ ................................ ................................ ......................... 46 6.1.5 Data Transfer Objects ................................ ................................ ............................. 46 6.1.6 Utilities ................................ ................................ ................................ .................... 47 6.1.7 Scheduler ................................ ................................ ................................ ................ 47 6.1.8 Constants ................................ ................................ ................................ ................ 47 6.2 Profiler ................................ ................................ ................................ ............................ 47 6.3 Testing ................................ ................................ ................................ ............................ 48 7. Produktpresentasjon: Frontend ................................ ................................ ........................... 49 7.1 Mappestruktur ................................ ................................ ................................ ............... 49 7.1.1 Rotnivå ................................ ................................ ................................ .................... 49 7.1.2 SRC ................................ ................................ ................................ .......................... 49 7.2 Design og universell utforming ................................ ................................ ...................... 51 7.2.1 MMI ................................ ................................ ................................ ......................... 51 7.2.2 Responsivt design ................................ ................................ ................................ ... 51 7.2.3 Fargevalg ................................ ................................ ................................ ................. 52 7.2.4 Tilretteleggelse for funksjonsnedsettelser ................................ ............................. 52 7.3 Formater og ikoner ................................ ................................ ................................ ........ 53 7.4 Øvrig design ................................ ................................ ................................ ................... 54 7.5 Testing ................................ ................................ ................................ ............................ 54 8 Videreutvikling og Forbedringer ................................ ................................ ........................... 55 8.1 Frontend ................................ ................................ ................................ ......................... 55 8.1.1 State Management ................................ ................................ ................................ 55 8.1.2 Type Script ................................ ................................ ................................ ............... 56 Sluttrapport – Gruppe 26 24.05.2020 6 8.2 Backend ................................ ................................ ................................ .......................... 56 8.2.1 Overgang til .NET ................................ ................................ ................................ .... 56 8.3 Funksjonalitet ................................ ................................ ................................ ................. 56 8.3.1 Reservas jonskort ................................ ................................ ................................ ..... 56 8.3.2 Finn mitt møte ................................ ................................ ................................ ........ 57 8.3.3 Fremtidig booking ................................ ................................ ................................ ... 57 8.3.4 Tekstfelt med info om reservasjonen ................................ ................................ ..... 57 8.3.5 Legge til deltagere ................................ ................................ ................................ ... 58 8.3.6 Valg av ønsket utstyr ................................ ................................ ............................... 58 8.4 Øvrig videreutvikling ................................ ................................ ................................ ...... 58 8.4.1 Native app ................................ ................................ ................................ ............... 58 8.4.2 Publisering på Microsoft Teams ................................ ................................ ............. 59 9. Avslutning ................................ ................................ ................................ ............................. 60 Vedlegg A – Veiledninger ................................ ................................ ................................ ......... 61 A.1 Brukerveiledning ................................ ................................ ................................ ............ 61 A.2 Brukerveiledning til oppsett av Microsoft miljøet ................................ ........................ 71 A.2.1 Microsoft 365 ................................ ................................ ................................ ......... 71 A.3 Oppsett av Azure, Bitbucket og Docker ................................ ................................ ....... 104 Vedlegg B – Flytdiagram ................................ ................................ ................................ ........ 108 Vedlegg C – Testrapporter ................................ ................................ ................................ ..... 109 C.1 Akseptansetesting ................................ ................................ ................................ ........ 109 C.2 Enhets - og Integrasjonstester ................................ ................................ ...................... 114 C.2.1 Sluttrapport for Testing: Frontend ................................ ................................ ....... 117 C.2.2 Sluttrapport for Testing: Backend ................................ ................................ ........ 119 Vedlegg D – Retningslinjer ................................ ................................ ................................ ..... 122 D.1 Retningslinjer Java og Spring ................................ ................................ ....................... 122 D.2 Retningslinjer JavaScript ................................ ................................ .............................. 126 D.3 Retn ingslinjer Git ................................ ................................ ................................ ......... 129 Vedlegg E – Sprinter og planlegging ................................ ................................ ...................... 132 E.1 Sprint 1 ................................ ................................ ................................ ......................... 132 E.2 Sprint 2 ................................ ................................ ................................ ......................... 133 E.3 Sprint 3: ................................ ................................ ................................ ........................ 135 E.4 Sprint 4 ................................ ................................ ................................ ......................... 136 E.5 Visualisering av Sprinter ................................ ................................ ............................... 138 Vedlegg F – Tekniske forklaringer ................................ ................................ .......................... 139 Sluttrapport – Gruppe 26 24.05.2020 7 F.1 Forklaring av backend services ................................ ................................ .................... 139 F.2 Microsoft Azure og Microsoft 365 ................................ ................................ ............... 141 Vedlegg E - Kilder ................................ ................................ ................................ ................... 147 Sluttrapport – Gruppe 26 24.05.2020 8 1 Innledning Vi i gruppe 26 hadde som ønske å bruke bachelorprosjektet til å utvikle en webapplikasjon 2 , hvor hensikten var å lære oss markedsrelevante kunnskaper vi kan ta med oss inn i arbeidslivet. Med denne forutsetningen kontaktet vi flere av konsulenthusene i Osloområdet før vi til slutt bestemte oss for å utføre prosjektet for TietoEvry på Fornebu. I korte trekk har vi ved bruk av populære teknologier i dagens profesjonelle utviklermarked produsert et rombookingssystem for møtevirksomhet. Dette er koblet opp mot Microsoft Office 365, hvor fokuset ligger på å kunne reservere rom fort og effektivt med minimal input fra brukeren. 1.1 Gruppen Cato Hilmi Akay catohilmi @ hot mail.com | 99 39 95 61 Cato studerer anvendt datateknologi, og har en bakgrunn som selger og idrettsutøver, med interesse for IT og datateknologi. I løpet av studiets gang har han valgt et mer programmeringsrettet løp enn den gjennomsnittlige anvendt - studenten. Samtidig har han jobbet som studentassistent i emnet Webutvikling og Inkluderende Design, og vært mentor for studenter som trenger ekstra tilretteleg g in g. Han sitter derfor igjen med en sterk kompetanse innen frontend - utvikling, met et fokus på å produsere brukervennlig teknologi. Fredrik Pedersen fredrikhp@gmail.com | 99 50 41 12 Fredrik er en dataingeniørstudent med bakgrunn i mediefag, og en livslang interesse for teknologi og dataspill. Han har i løpet av studiet jobbet som Orakel (studentassistent for alle førsteårsfag) ved OsloMet, og som webutvikler for Forum Market Services Jobberfaringen kombinert med studiet og flere egenprosjekter gjør at han har god kontroll over infrastruktur, front - og backend utvikling. 2 En Webapplikasjon er en nettside som kan ta imot og reagere på data Sluttrapport – Gruppe 26 24.05.2020 9 Nikita Petrovs nikitapetrovs98 @ g mail .com | 40 09 85 81 Nikita er dataingeniørstudent, og er gruppens logisk ster keste medlem. Når et komplekst problem må løses er det han som får jobben, og dukker alltid opp med en fungerende løsning kort tid senere. Hans evne til å enkelt tilegne seg nye kunnskaper gjør at han fort kan settes inn der han trengs, og har på mange måt er vært gruppens joker. Victor Klougman Pishva victor.pishva@gmail.com | 99 15 49 99 Victor studerer dataingeniørfag, og har tidligere studert til å bli byggingeniør ved Høgskolen i Østfold Han er en blid og utadvendt person som brenner for å lage enkle og brukervennlige løsninger. Han valgte å bytte studieretning siden han alltid har hatt interesse for teknologi og det å hjelpe andre med tekniske løsninger. I ettertid har han i tillegg valgt å gjøre ferdig byggingeniørgraden ved siden av datastudiet, og fullfører begge gradene våren 2020. I løpet av studiet har han jobbet som IT support for Coop, promotør for IT - studie r, Orakel og studentassistent i faget Webutvikling og Inkluderende Design ved OsloMe t , og har dermed en god sans for frontend - utvikling. Gruppens medlemmer har i løpet av studiet samarbeidet i flere emner og har god kommunikasjon og tone innad. Ved oppstart av prosjektet ble det gjort inndelinger i ansvarsområder for hvert gruppemedlem, basert på enkeltpersonens kunnskap og ønsker. Fredrik og Nikita ble satt til å jobbe med backend 3 , mens Cato og Victor fikk ansvar for frontend 4 I praksis har alle gruppens medlemmer bidratt etter beste evne på alle områder 3 Backend er serversiden av løsningen og sørger for lagring og håndtering av data. 4 Frontend er klientsiden av en løsning, og har i oppgave å formatere data o g vise det frem til en bruker i et grafisk grensesnitt. Sluttrapport – Gruppe 26 24.05.2020 10 1. 2 Veiledere 1. 2 .1 Veileder fra OsloMet Eva Hadler Vihovde evahadler.vihovde@oslomet.no | 67 23 86 66 Stilling: Førstelektor - Programmering - Diskret Matematikk - Software Testing Vi kontaktet Eva basert på at hun har lang erfaring med å veilede bacheloroppgaver, samt ryktet h un har på seg for å være en flink veileder. Hun har bidratt mye til hvordan vi tilnærmet oss oppgaven og utforming av rapporten. 1. 2 .2 Veiledere fra TietoEvry Trond - Ivar Maanum trond.ivar.manuum@evry.com | 91 76 70 07 Stilling: Head of Application Management Trond - Ivar har fungert som oppdragsgiver og intern ressurs i TietoEvry. Han har bistått gruppen med å komme i kontakt med korr ekte fagpersoner og avdelinger, samt anskaffelse av ressurser for å løse administrative og faglige problemer. Sluttrapport – Gruppe 26 24.05.2020 11 Susanne Vernersson susanne.vernersson@evry.com | 90 98 97 74 Stilling: Senior Consultant/Software Developer Susanne har vært gruppens primære kontaktperson og prosjektveileder fra TietoEvry. De gangene hun fikk deltatt på møter tok hun rollen som produkteier, og har ellers fulgt gruppen gjennom prosjektperioden. Med sin kompetanse som fullstack utvikler 5 har hu n kommet med innspill og teoretiske tilnærmingsmåter, spesielt til systemutviklingsprosessen. Hun har også bidratt til at gruppen har kommet i kontakt med personer innad i TietoEvry. 1. 3 Oppdragsgiver T ietoEvry er et internasjonalt IT, software og konsulentfirma med hovedmarked i Nord - Europa , hvis visjon er “ Creating digital advantage for tomorrow’s leaders ” (1) Her til lands var de kjent som Evry inntil 5. desember 2019, d a de ble fusjonert med finske Tieto. Som TietoEvry tilbyr de et bredt utvalg av IT - tjenester innenfor utvikling, drift og vedlikehold av nye og eksisterende tjenester, i tillegg til konsulent - og rådgivningstjenester. De har over 8800 ansatte, fordelt på n i land (2) med flere store kundegrupper innenfor bank og finans, offentlig sektor, helse, varehandel , kommunikasjon, media og IT mm. (3) For prosjektet vårt hadde TietoEvry, nærmere bestemt avdelingen Application Innovation, rollen som både oppdragsgiver og kunde. 5 En fullstack utvikler er en person som jobber med både klient - og server - programvare. Figur 1 : TietoEvry Logo Sluttrapport – Gruppe 26 24.05.2020 12 2 Problemstilling og o mfang I denne seksjonen vil vi gjøre rede for dagens situasjon når det angår møterombooking i TietoEvry, hvilke konkrete problemer de ønsket å få løst, og hvordan. De t vil også bli redegjort for avgrensninger som ble satt fra kundens side, basert på hva de ønsket at vi skulle oppnå i løpet av prosjektperioden 2 1 Bakgrunn for p rosjektet og d agens s ituasjon TietoEvry på Fornebu huser i dag over tusen ansatt e fordelt på to bygg. Begge byggene har fem etasjer med 4 - 5 seksjoner hver, og opptil titalls møterom i hver seksjon. Bedriften har en hyppig møtekultur, og for å kunne holde styring hvem, hva, hvor og når møter foregår har de tatt i bruk Microsofts Office 365 - løsning. Dette gir ansatte muligheten til å opprette hendelser med deltagere, tid og sted som legges inn i Outlook - kalenderen deres. Dagens løsning oppleves av mange hos TietoEvry som tungvint, og medfører irritasjonsmomenter og tidstap for de ansatte, noe som kan påvirke både pris og leveranse til bedriftens kunder. TietoEvry ønsker i denne sammenheng å tilby et alternativ til den nåværende løsningen. At de selv opplever problemer med Microsofts løsning har også åpnet dem for tanken om å utvikl e et kommersielt produkt som løser disse problemene, hvor vår løsning blir å regne som et internt pilotprosjekt. 2.1.1 Dagens l øsning I den nåværende løsningen må de ansatte benytte seg av Outlook i nettleser eller via en dedikert desktop applikasjon for å opprette en hendelse. Et av stegene er å velge hvilket rom de ønsker til hvilken tid, og måten dette er løst på i Outlook er at brukerne får en liste med alle rommene i systemet (se figur 2 på neste side) Listens utseende varierer ut ifr a om man bruker nettleseren eller desktop applikasjonen, men det er uansett lange lister og relevant informasjon er ikke tydelig fremhevet Sluttrapport – Gruppe 26 24.05.2020 13 Figur 2 : Evrys romliste i Outlooks desktop applikasjon Løsningen er noe ryddigere i Outlooks telefonapp , da man får opp en liste med utvalgte rom som er ledige til tiden man prøver å opprette et møte. Denne listen viser derimot ikke alle ledige rom, noe som kan være uheldig dersom man virkelig ikke vil ha et av de rommene som dukker opp. For å komplementere reservasjoner igjennom Outlook er det hos TietoEvry blitt investert i et system hvor det er plassert touchskjermer utenfor hvert møterom . Vi disse skjermene går det an å se rommets kalender og reservere det . Ulempen med den ne løsningen er at man må fysisk gå til rommet for å finne ut om det er ledig, og er det ikke det må man lete videre. Dagens løsning oppfattes av flere ansatte som tungvint, og for de som ikke er kjent i alle byggets etasjer er det også vanskelig å vite nøyaktig hvor et rom man har reservert befinner seg Figur 3 : Romlisten i Outlooks mobilapplikasjon Sluttrapport – Gruppe 26 24.05.2020 14 2.2 Problemstilling og p rosjektets o mfang Vil det være mulig å booke møterom med minimal bruk av tid, samtidig som det tas hensyn til brukernes foretrukne romkriterier? Dette var problemstillingen som oppdragsgiver presenterte oss med da vi først møttes for å utarbeide oppgaven. De ønsket i så f all at løsningen skulle komme i form av en webapplikasjo n som integreres med det eksisterende Office 365 - systemet, og skulle fungere som et alternativt tilbud til systemet deres ansatte allerede bruker til daglig. Det ble i tillegg vektlagt at det skulle v ære fokus på å oppnå et brukervennlig og Responsivt design 6 På den funksjonelle siden kom vi til enighet om at produktet gjerne skulle ha så mye som mulig av funksjonaliteten som finnes for reservasjon av rom i Outlook, i tillegg til andre ideer vi kom f rem til sammen. Vi går nærmere inn på disse i delkapittel 4.1 . Når det kom til systemutviklingsprosessen ønsket de at vi tok i bruk smidig metodikk, da dette er måten deres egne utviklerteam jobber på. A v den grunn fikk vi ikke utlevert en konkret kravspe sifikasjon 7 utover de ønskede funksjonalitetene. Vi fikk ellers helt frie tøyler når det kom til valg av teknologier og hvordan vi ønsket å jobbe med prosjektet. 2.2.1 Målgruppe Selv om oppgaven i utgangspunktet skal fokusere på å produsere en rombookingsløsning for de ansatte hos TietoEvry, så ble det også ytret et ønske om å legge til rette for videreutvikling s lik at løsningen kan selges som et produkt til andre bedrifter med lignende behov. Målgruppen er derfor så bredt definert som « alle ansatte i store bedrifter », og kan derfor være alt fra unge og teknisk kompetente mennesker, til eldre personer som sjeldent bruker datateknologi til annet enn i jobbsammenheng. Ut ifra denne målgruppen trakk vi følgende slutninger: 1. Et enkelt og profesjonelt design vil være viktig. 2. Vi kan forvente at brukere vil ha tilgang på opplæring og veiledning hvis de skal bruke applikasjonen, men den skal i utgangspunktet være veldig enkel å bruke. I løpet av utviklingen ble dermed designfilosofien at alle personer, uavhengig av tekn isk kompetanse, skal kunne bruke løsningen uten å måtte få en lengre innføring. 6 Responsivt design gjør nettsiden brukervennlig, og skalerbar på flere enheter 7 Kravspesifikasjon omhandler å identifisere kundens behov og krav for å utvikle en løsning Sluttrapport – Gruppe 26 24.05.2020 15 2.2. 2 Avgrensninger Det ble også avklart under det første møtet med oppdragsgiver at vi i skulle ha fokus på å utvikle et solid p roof of c oncept 8 , og ikke en produksjonsk lar 9 applikasjon. Dette gjorde at prioriteringene vår e kunne ligge i å utvikle funksjonalitet og løsninger på problemstillingen , i stedet for å gjøre applikasjonen klar til å tas i bruk av reelle forbrukere. En skulle selvsagt tilrettelegge så godt en kunne for å ha en produksjonsklar applikasjon, men dersom det dukket opp problemer relatert til dette skulle de nedprioriteres elle r direkte skyves til side. Vi kommer til å påpeke senere i rapporten en del valg som ble gjort av hensyn til denne føringen. 8 Proof of concept er en realisering av en idé, som viser at idéen er gjennomførbar i praksis 9 Klar til å tas i bruk av forbrukere og at man kan stole på at applikasjonen kan betjene reell bruke rtrafikk. Sluttrapport – Gruppe 26 24.05.2020 16 3 Resultat I denne seksjonen vil vi l egge frem resultatet av prosjektperioden, i form av en overordnet gjennomgang av produktet vårt, og hvorvidt det er en løsning på problemstillingen vi fikk presentert. For en mer teknisk gjennomgang av teknologiene og komponentene i løsningen, se kapittel 5 - Teknologier og Verktøy , kapittel 6 - Produktpresentasjon: Backend og kapittel 7 - Produktpresentasjon: Frontend 3.1 Rombookingsløsningen Løsningen vi har utviklet i løpet av prosjektperioden er det vi kaller en I nstant B ooking webapplikasjon . Det kreves først at brukeren logger inn med sin Microsoft - konto knyttet til en bedrift , og deretter kan brukeren reservere rom på cirka ti sekunder med så lite som tre klikk 10 fra man står logget inn på forsiden til man har bekreftet en booking. Vi implementere også en separat modul for statistikk, slik at brukere kan se hvilke rom og tider som er travlest, og så ledelsen kan se hvilke rom som blir hyppigst brukt dersom det skulle være behov for ominnredning av kontorlandskapet. 10 Ti sekunder og tre klikk d ersom man ikke legger inne noen preferanser og lar løsningen finne et tilfeldig rom Figur 4 : Flytdiagram for hele løsningen En større versjon finnes under vedl egg Sluttrapport – Gruppe 26 24.05.2020 17 I flytdiagrammet ovenfor illustreres alle veiene en bruker kan ta ved bruk av løsningen. Som nevnt tidligere starter hele prosessen med at brukeren åpner nettsiden og blir bedt om å logge inn med sin Microsoft - bedriftskonto. Etter en vellykket innlogging befinner brukeren seg på hovedmenyen, hvor en velger mellom modulene Statistikk og Instant Bo oking. I korte trekk, så vil brukeren ved valg av Instant Booking bli tatt til et skjermbilde hvor den får legge inn sine ønskede preferanser (plassering, varighet og romstørrelse). Systemet finner et rom ut ifra disse og gir brukeren et forslag til en bo oking, sammen med et bilde av hvor rommet befinner seg. Systemet vil på veien dit kontrollere om brukeren har en hendelse innenfor den gitte tidsrammen, og i tillegg gi brukeren valg om å få et alternativt rom dersom det ikke er noe ledig som matcher bruke rens preferanser. Til slutt gjenstår det for brukeren å bekrefte om den ønsker at rommet skal reserveres. Figur 5 : Hovedmenyen i løsningen Sluttrapport – Gruppe 26 24.05.2020 18 Statistikkmodulen er noe enklere. Ved valg av statistikk på hovedmenyen vil brukeren bli tatt til et skjermbilde med en nedtrekks liste, hvor den kan velge mellom alle tilgjengelige former for statistikk. Når en statistikk er valgt blir det tegnet en graf f or brukeren. For en mer gjennomgående veiledning av løsningen i sin helhet, se brukerveiledningen Figur 6 : Bekreftelsessiden for rombookinger Figur 7 : Statistikksiden med en graf Sluttrapport – Gruppe 26 24.05.2020 19 3.2 Under Panseret Nøyaktig hvilke språk, rammeverk 11 og andre teknologier som er brukt for å utvikle løsningen vil vi som sagt komme tilbake til senere i rapporten , men allikevel å gi et generelt overblikk her. I korte trekk består bookingsystemet av et backend REST API 12 skrevet i Java rammeverket Spring Boot, som kommuniserer med Microsoft sine systemer på Azure, og vår egen database. Dette REST APIet inneholder algoritmer for å søke etter korrekt data og formatere den, med endepunkter som klientapplikasjonen kan kalle for å iverksette de forskjellige pro sessene. Klientapplikasjonen er skrevet i Javascript rammeverket React. Denne delen av løsningen er ansvarlig for å håndtere innlogging til Microsoft - systemene, gjøre kall til serverapplikasjonen, og å lage det grafiske brukergrensesnittet som dataene fra serverapplikasjonen vises frem i. 3.2.1 Utfordringer Mange av utfordringene i utviklingsprosessen lå i å få til kontakten med Microsoft sine systemer, og at vi måtte lære oss Spring - rammeverket og Javascript med React fra grunnen av, samtidig som vi job bet med prosjektet. Når det kommer til Microsoft Azure og APIene deres, så er disse vel dokumentert, men utfordringen ligger i å vite hva man skal lete etter når man aldri har jobbet med plattformen tidligere. Hele plattformen er også i stadig utvikling, n oe som fører til at dokumentasjonen ofte er utdatert, og gjør at det ofte ikke finnes noen veiledning på hvordan verktøyene skal brukes. Kombiner dette med at Microsoft selv oppfordrer til bruk av deres eget .NET - rammeverk for utvikling, og har dermed doku mentasjon og guider basert på .NET, så fikk vi med vår Java - applikasjon flere utfordringer å løse. Vi kommer til å gå dypere inn i hele oppsettet og utfordringene rundt bruken av Microsofts plattform i kapittel 5 – Tekn ologier og Verktøy 11 Et programrammeverk er e n konkret eller konseptuell plattform for utvikling av programvare , hvor det finnes ferdig funksjonalitet s om kan overstyres eller utvides av programmereren. 12 Programmeringsgrensesnitt (API) som bruker HTTP - forespørsler til å hente (GET), legge inn (POST), oppdatere (PUT) og slette (DELETE) data. Sluttrapport – Gruppe 26 24.05.2020 20 3. 3 Metrikk og Akseptansetesting For å kunne avgjøre om løsningen vår løser problemstillingen vi fikk fremstilt har vi gått frem på to måter; metriske data og akseptansetesting. Vi brukte begge tilnærmingene fordi tallene om hvor lang tid en person bruker på å gjennomføre en oppgave etter å ha fått en kort innføring i hvordan programmet fungerer, sier lite om den generelle brukeropplevelsen og hvorvidt vedkommende likte løsningen. Ved en akseptansetest utsetter man derimot personen blindt for løsningen, og var i våre tilfeller i samtale med testobjektet mens den utfører testene. Testobjektet bl e de rmed utsatt for utvendig støy, og k u n ne komme til å bruke lengre tid eller trykke feil, noe som ikke gir like mye håndfast data til om vi har løst kravene til effektivitet. Merk at testene for tidsbruk og antall klikk ble utført etter produksjonsstopp i sl utten av april, og den noe mer omfattende akseptansetestingen ble utført etter vi hadde produsert et minimum viable product ( MVP ) 13 i slutten av mars. Denne MVPen hadde i hovedsak ikke statistikkmodulen eller muligheten til å legge inn andre preferanser en n romstørrelse, da de funksjonalitetene ble utviklet i løpet av april. 3. 3 .1 Metriske Verdier Den metriske dataen ble fremkalt ved å få ansatte hos TietoEvry til å lage rombookinger, først ved bruk av Outlook (både nettleser og desktop applikasjon), og så ved bruk av vår løsning. Det vi målte var tid brukt for å gjennomføre en rombooking, samt antall klikk vedkommende måtte foreta seg. Alle brukerne var i varierende grad kjent med Outlook sine systemer, og hadde fått prøve vår applikasjo n noen ganger før vi utførte testene. Scenarioene som ble utført i både Outlook og i vår applikasjon var følgende: - Book et vilkårlig rom fra nærmeste hele eller halve time, en time frem i tid. - Book et rom i første etasje, seksjon f, med kapasitet til 14 p ersoner fra nærmeste hele eller halve time, en time frem i tid. 13 En MVP inneholder nøkkelfunksjonalitet som muliggjør at løsningen kan brukes og ingen annen funksjonalitet.