Bachelorprosjekt 2015

Transkript

1 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951)

2 PROSJEKT NR. (Våren 2015) TILGJENGELIGHET Åpen Studieprogram: Informasjonsteknologi og Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL DATO 26. mai 2015 ANTALL SIDER/BILAG 51 / 1 PROSJEKTDELTAKERE Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) INTERN VEILEDER Ismail Hassan Ismail.Hassan@hioa.no OPPDRAGSGIVER Knowit KONTAKTPERSON Tobias Torrisen tobiast@gmail.com 1

3 SAMMENDRAG Prosjektet består av å utvikle et konferansesystem på Web for oppdragsgiver Knowit. Applikasjonen skal lastes rett ned i nettleseren 100% klar til bruk, helt uten at brukeren trenger å laste ned tilleggsprogramvare. Applikasjonen skal kunne redusere mengden med e post kommunikasjon i forbindelse med events/konferanser (heretter events). 3 STIKKORD Events SPA Ruby on Rails 2

4 Forord Denne rapporten inneholder hele s prosjektdokumentasjon for Bacheloroppgaven ved Høgskolen i Oslo og Akershus (HiOA) Våren Vår oppdragsgiver er Knowit. Rapporten inneholder all relevant dokumentasjon og informasjon om arbeidet/prosjektet vårt, inkludert dokumentasjon og informasjon om den endelige løsningen/single Page Applikasjonen. Dokumentet er delt inn i tre deler: Innledningen består av presentasjon av, bedrift introduksjon, bakgrunn for prosjektet, oppdragsgiverens (Knowit) krav til sluttproduktet og litt om de ulike verktøyene vi har tatt i bruk for å gjennomføre Bachelorprosjektet. Hoveddelen består av all dokumentasjon om utviklingsprosessen, skisser og om arbeidet/oppdraget. Samt begrunnelse av valgene av teknologi/språkene vi har valgt. Konklusjonen består av hva vi har lært og hvordan det har gått i prosjektet, hva som gikk bra og ikke, hva som kunne blitt gjort bedre, hva som fungerte og ikke etc. Deretter kommer kildelisten, eventuelle vedlegg og helt til slutt prosjektdagboken. Dokumentet er hovedsakelig ment for sensor og veileder. Vi takker Knowit for at vi fikk lov til å ha Bacheloroppgaven vår hos dem, inkludert Tobias Torrisen og Kristofer Walters for god beskrivelse av oppgaven, veldig god veiledning og mange nyttige og relevante tips til applikasjonen. Vi takker også vår veileder Ismail Hassan og de andre på Høgskolen i Oslo og Akershus (HiOA) for å tilby hjelp og veiledning når vi hadde behov for dette. 3

5 Forord Innholdsfortegnelse Innledning Beskrivelse av behovet Gruppen Oppdragsgiver Bakgrunn for prosjektet Kort om sluttproduktet Organisator Deltaker Verktøy og kommunikasjon Trello Github Heroku Hoveddel Teknologivalg Bakgrunn av teknologivalg Valg av programmeringsspråk Valg av utformingsspråk Valg av tekniskeverktøy Prosessdokumentasjon Begrensninger og utfordringer Kravspesifikasjon Planlegging og metoder Risikoplan User stories, Use case diagram og Use cases for systemet Brukermanual Testing Konklusjon Videre arbeid Oppdragsgiverens syn på produktet Vår egen vurdering av prosjektet Vedlegg Prosjektskisse Forprosjekt Prosjektdagbok Kilder Attest fra oppdragsgiver

6 1. Innledning Denne sluttrapporten er et resultat av Bachelorprosjektet til, som ble holdt ved Høgskolen i Oslo og Akershus (HiOA) Våren Sluttrapporten oppsummerer prosjektet i detalj. Vi har gjort vårt ytterste for å gjøre sluttrapporten både lettlest og informativ. 1.1 Beskrivelse av behovet Alle store og små bedrifter holder konferanser/events/møter (heretter events) for sine medarbeidere og samarbeidspartnere. Og i den anledning er det veldig viktig å formidle all relevant informasjon om disse events til alle deltakere, så de kan oppmøte på eventene. For at eventene går som planlagt og det ikke oppstår uforutsette problemer er informasjonsformidling om event spiller nøkkelrolle. I dag benyttes ulike hjelpemidler for å utføre slike ting, som mail (vanlig fysisk post og e post), telefon, applikasjoner osv. Hvilken måte man bruker for å invitere deltakerne passer best er avhengig av hvordan konferanse/møte det er snakk om og ikke minst hvor. Det viktigste av alt er å få svar fra de inviterte, samt hva som må legges til rette for dem. Viktigheten og nytten av en slik applikasjon kan forstås ved et lite eksempel. Det holdes en konferanse i Oslo av en vilkårlig bedrift. Ansvarlig for eventet og invitasjonene sender invitasjoner, for eksempel via e post. Men med tanke på at ikke alle er så aktive på å sjekke sine e poster, sender han også SMS/tekstmeldinger og sier i tillegg via telefonsamtaler om å sjekke e posten. Noen har sjekket e posten, noen svarer på e posten, noen svarer på melding og noen har ringt og sagt ifra om de kommer eller ikke. Det som skjer da at det blir altfor mye å gjøre for invitasjons sender, og dermed er det stor fare for at det kan oppstå kaos. For eksempel ved at noen som kommer ikke registrert, og noen som ikke kommer er registrert osv. Via en egen applikasjon kan alt kaoset i overnevnte eksempel unngås. Ved å benytte for eksempel et felles svarskjema på web, må alle som møter på eventet melde seg opp. Dette vil i stor grad redusere tidkrevende arbeid for eventholderen, slik at han/hun kan bruke tid på andre ting som å forberede seg og det man skal snakke om. I tillegg samles alle påmeldte deltakere på ett fast sted. 5

7 1.2 Gruppen Gruppen består av Tam Ha, Phillip Padiernos Næss, Gabriel Noraker Alfarrustad, Arslan Yousaf og Eivind Lund. Tam går på Informatikk, Gabriel går på Dataingeniør mens Philip, Arslan og Eivind går Anvendt datateknologi. 1.3 Oppdragsgiver Oppdragsgiveren vår for prosjektet er Knowit. Selskapet jobber med alt fra IT løsninger, design og til rådgivning. Selskapet står bak mange kjente digitale løsninger og systemer som BankID 2.0, underholdnings applikasjonen TV2 Sumo, Ruter# applikasjonen og medieavspilleren til NRK. Knowit består av ca spesialister som jobber i skjæringspunktet mellom strategi, kreativitet og teknologi. Blant disse er Tobias Torrissen som har vært vår kontaktperson i Knowit, og Kristofer Walters som er fagansvarlig for frontend hos Knowit. 1.4 Bakgrunn for prosjektet Da vi møtte vår kontaktperson i bedriften fikk vi vite at de var ikke så komfortable med dagens løsninger for å invitere folk til konferanser/møter/events. De bruker stor sett mobil og e post til dette. En annen ting var å vite tilleggsinformasjon som transport, overnattingsplaner, hvem som vil være noen dager ekstra der det holdes konferanse, hvem vil ta med en person ekstra og ta seg en liten ferie før/etter en konferanse osv. Oppdragsgiveren synes at slike ting kan være forvirrende, tidkrevende og slitsomt å avtale over telefoner, notere ned, eller ta via e post når det er betydelig mange deltakere å holde styr på. Derfor ønsker de seg et system/en applikasjon som kan benyttes til å gjøre alt dette arbeidet. Alt skal skje i nettleseren, helt uten behov for å laste ned noen form for tilleggsprogramvare. 1.5 Kort om sluttproduktet Sluttproduktet skal være en web basert løsning for å håndtere konferanser, som bedriften arrangerer både innenlands og utenlands. Det skal være en selvbetjent løsning på Web, med andre ord trenger hverken organisator eller deltakere å kommunisere over telefon eller e post for å melde seg på en konferanse/event. Web løsningen vår skal gi organisatoren og deltakere mulighet til å kommunisere på en effektiv måte. Vi har fått følgende punkter å ha med i løsningen, sortert under to kategorier: Organisator og Deltaker. 6

8 1.5.1 Organisator av et event Organisator/arrangør er ansvarlig for oppretting og organisering av konferanser/events. Denne brukeren skal kunne lage/opprette et event. Et event (en konferanse) inneholder følgende info: Navn (navn på eventet) Beskrivelse (kort beskrivelse av eventet) Dato (når eventet skal holdes) Sted (hvor eventet skal holdes) Kartreferanse (eventuell kartreferanse) Arrangør (navnet på arrangøren av eventet) Arrangør tlf nr. (telefonnummeret til arrangøren av eventet) Informasjon om transport (eventuell transportinformasjon) Informasjon om hotell/overnattingsted (eventuell hotell og overnattingsinformasjon) Etter at eventet er opprettet med denne informasjonen, skal invitasjonene for dette eventet sendes ved at senderen legger til en liste over (deltakernes) e postadresser inn i et tekstfelt. Invitasjonen sendes endelig til de oppgitte e postadressene med en lenke for å svare tilbake Deltaker av et event Når deltaker har fått invitasjon kan han/hun svare på denne ved å følge lenken, sendt med invitasjonen. Svar lenke skal inneholde følgende: Takke ja/nei. Hvis ja oppgi mobilnummer og e post adresse. Mulighet for å oppgi ekstra informasjon om å være der lenger/kortere, hotellrom og mulighet for ha med seg en ekstra person. I tillegg en mulighet for å oppgi eventuelle spesielle behov som kost, allergier osv. 7

9 1.6 Verktøy og kommunikasjon For å sikre god prosjektarbeid og kontroll på koden har vi brukt Trello, Github og Heroku. Trello fungerte ikke i lengden, men ga oss et godt eksempel på hvordan vi kunne kommunisere og snakke om utviklingsstatusen til systemet. Trello ga oss bare mer ekstrajobb, og funket ikke i vårt tilfelle. Mer om hvorfor vi valgte bort Trello under... For bedre gruppearbeid og kommunikasjon har vi som oftest brukt e post, Facebook (en egen Facebook gruppe) og mobil (ringe og SMS) som kommunikasjonsmidler Trello For få oversikt over hvordan det går med oppgaven, opprettet vi i starten en Trelloboard. Både oppdragsgiver og veilederen vår hadde tilgang til den for å se våre prosjekt aktiviteter og status. Vi begynte arbeidet ved å opprette en rekke punkter som vi så for oss at vi skulle jobbe med. Vi følte ganske fort at nytten vi hadde av dette verktøyet var veldig minimal. Ofte brukes Trello for at de ulike deltakerene skal kunne følge med på hva de andre i gruppa jobber med. I vårt prosjekt var derimot kontakten veldig tett og jevnlig gjennom hele prosessen. Vi hadde allerede opprettet en lukket Facebook gruppe hvor vi daglig hadde kontakt og la ut informasjon om hva vi jobber med og status. Dette kombinert med med jevnlige e poster med oppdragsgiveren for å oppdatere han om nye møter og progresjon, og veldig tette møter. Ofte var det ikke mer enn 3 4 dager mellom hvert møte, noe som gjorde at vi tidlig valgte å gå bort fra Trello. Vi valgte uansett å ikke slette punktene som var blitt opprettet, slik at vi kunne bruke dette til å se hva vi hadde snakket om Github Vi har brukt Github for å jobbe med koding av produktet. Måten Github fungerer på er at utvikling skjer lokalt på egen PC/Mac, deretter videresendes koden til Github, slik at samtlige av gruppemedlemmene kan kommentere og eventuelt rette koden. Ferdig fungerende og robust kode legges til felles Heroku skytjeneste. Optimalt skjer utviklingen altså slik: Lokalt > Github > Heroku. Github har også vært til stor hjelp når det gjelder å lære seg nye kode språk, samt andre nyttige guider som andre har delt med omverden. 8

10 Heroku Heroku er en skytjeneste som støtter flere programmeringsspråk, og er spesielt nyttig i webutvikling. Den har vi blitt oppmerksomme på og brukt etter anbefaling fra oppdragsgiveren vår. Det er også mulig å knytte den til en database som er støttet av tjenesten, for eksempel har vi brukt en PostgreSQL database som er støttet av Heroku. 2. Hoveddel 2.1 Teknologivalg Vi stod fritt til å ta egne teknologivalg fra oppdragsgiver sin side, men fikk en del gode eksempler og forslag fra han. Blant annet viste han et backend eksempel skrevet i Java. Etter å ha testet ut ulike teknologier i starten av prosjektet har vi tatt følgende beslutning: På brukersiden/i nettleseren skal det brukes vanlig robust HTML, CSS og JavaScript. På serversiden skal Ruby og relasjonsdatabaser (PostgreSQL) brukes. Alle i gruppen hadde ulik programmeringsbakgrunn, dermed var det litt vanskelig for oss å velge en teknologi som kunne tilpasses alle i gruppen. Samtidig hadde vi lyst til å bruke teknologi/kodespråk som vi kunne hatt stor nytte av senere Bakgrunn av teknologivalg Vi fikk gode tips angående valg av teknologi fra både intern veileder på skolen og oppdragsgiver. Vi fikk også godt inntrykk av hvilke teknologier som er mest etterspurt i disse dagene, samt kikket vi litt på jobbannonser for programmerere for å vite mer om teknologi forståelsen/språkkompetansen de krever. Grunnen til at vi brukte tid for å finne ut av det, var å jobbe med noe som kan hjelpe oss senere i arbeidslivet, og ikke minst for å finne hjelp fra andre/internett om vi opplever vanskeligheter med noen funksjon, kode osv. Vi innså at det var veldig viktig å velge noe som vi lett kan få hjelp om. 9

11 2.1.2 Valg av programmeringsspråk Valg av programmeringsspråk var litt vanskelig for oss i starten på grunn av ulik programmeringsbakgrunn i gruppen. Noen av oss var gode på Java mens andre var flinke i PHP. Java er uten tvil en av de mest populære programmeringsspråkene. Vi fikk også veldig godt inntrykk av Ruby. Etter å ha studert mye om Ruby tenkte vi å teste ut den. Da sto valget mellom Java og Ruby. Alle i gruppen hadde lyst til å tilegne ny kunnskap/kompetanse innenfor programmering, derfor valgte vi Ruby til slutt som programmeringsspråk. NB: Mange, inkludert oss blander Ruby og Ruby on Rails. Ruby er programmeringsspråk mens Ruby on Rails er et utviklingsmiljø som er skrevet i Ruby, men det er fullt mulig å skrive sine egne Ruby koder i Ruby on Rails. Vi ble kjent med Ruby on Rails via Ruby og fant ut at det var mye mer effektiv å bruke Ruby on Rails, og implementere egne koder og egne konfigurasjoner. Ruby on Rails kan sammenliknes med et skjelett hvor man har mulighet til å legge til ulike funksjoner, koder, stiler osv Valg av utformingsspråk For utforming/utseende av produktet på klientsiden, valgte vi HTML, CSS og JavaScript som er standard for de fleste nettsider/applikasjoner. Bakgrunnen for dette valget var at dette fungerte veldig bra med Ruby, og ikke minst at når man lager en applikasjon i Ruby on Rails, blir disse filene opprettet automatisk Valg av tekniske verktøy Vi brukte hovedsakelig tre tekniske hjelpemiddelverktøy: Trello, Heroku og Github. Her er en kortfattet begrunnelse for hver av disse. Trello: Brukt for oppretting av prosjektdeler, samt prioritetsmerking av delene. Heroku: Heroku er gratis å bruke for opptil 5 applikasjoner. Den tilbyr hjelp via en veiledningsmanual online, fra punkt til punkt for å komme raskere i gang. Det finnes veiledning for alle programmeringsspråkene som den støtter. For nye programmerere som oss passet den utrolig fint. Dessuten integrerer den godt med Github. Github: Github valgte vi fordi flere kunne jobbe med samme kode samtidig, uten å forstyrre hverandre. Kildekoden kan enkelt oppdateres etter at man har lagt inn nye koder. Det kan lastes 10

12 ned kildekoder som kan være behjelpelig for utviklingsprosessen. Oppdragsgiveren kan også følge med på det vi koder. 2.2 Prosessdokumentasjon Dokumentet tar leseren blant annet gjennom begrensninger vi hadde i forhold til prosjektet, inkludert ulike utfordringer vi møtte på veien og eventuelt hvordan vi løste dem. Videre går vi inn på krav til produktet og beskrivelse av hvordan vi planla prosjektet, og avslutter med utviklingsmetodene vi brukte, samt hvorfor vi valgte det vi valgte. Beskrivelse av Scrum og Kanban utviklingsmetode er med for å gi innblikk av hva det innebærer (siden de er brukt i prosjektet). Deling av prosjektet i tre deler etter prioritet er forklart og begrunnet. Prioritetstabell av prosjektdeler er ment for å gi godt helhetsoversikt for leseren Begrensninger og utfordringer Ettersom de fleste av valgene vi hadde tilgjengelige, med tanke på kodespråk og løsninger, var relativt mye nytt for oss. Og fordi vi ønsket å utvikle oss litt på kodefronten, så valgte vi løsninger som krevde at vi leste oss opp og satt oss inn i mye nytt stoff. Naturligvis ga dette oss noen utfordringer, men dette var noe vi var klare for og forberedt på fra starten av. Noen av utfordringene som har hengt over oss i ettertid, er hvordan vi skal få hele applikasjonen til å kjøre, inkludert kommunikasjonen til og fra backend/serveren. I tillegg til kodingen, måtte vi sette av nok tid og bestemme hvem som skal fullføre rapportskrivingen og annen dokumentasjon Kravspesifikasjonen Tradisjonelt i utviklingsprosjekt er det vanlig å ha flere faste forhånd satte krav som skal oppfylles. Ettersom oppdragsgiveren ikke hadde noen faste satte krav, og at vi ønsket å arbeide smidig har vi tatt en mer moderne vinkling på kravspesifikasjonene. Vi hadde tidlig et møte hvor Knowit gikk gjennom de problemstillingene de hadde, og fortalte om hvordan de gjorde det per dags dato når det kom til konferanser og events. Kanskje det eneste kravet Knowit hadde var at applikasjonen skulle være open source. Med dette mener vi alle kildekodene og løsningen som brukes er åpne på nettet. Dette gir Knowit og eventuelt andre muligheten til å videreutvikle systemet i ettertid, inkludert å bruke og modifisere kodene og løsningene vi har laget til å passe nye løsninger. Videre etter dette utarbeidet vi en prioritert liste med User stories som forklarer hva de ulike brukerne ønsker å gjøre. Formatet på disse User storiene er: 11

13 Som <brukeren> ønsker jeg <funksjonen>, slik at <nytteverdien>. 1. Som arrangøren av et event ønsker jeg å legge til nye events, slik at deltakerne kan finne og se på eventet og eventuelt melde seg på. 2. Som deltaker av et event ønsker jeg å se på events, slik at jeg eventuelt kan bestemme meg om å melde meg på ønskede event/events. 3. Som deltaker av et event ønsker jeg å sjekke tidspunktet/datoen for når et event holdes, slik at jeg vet når jeg burde dra hjemmefra. 4. Som arrangøren av et event ønsker jeg å sjekke hvem som er påmeldt hvert event, slik at at jeg kan sende dem oppdateringer eller endringer. 5. Som deltaker vil jeg stemme på et event jeg liker/anbefaler, for å gi andre deltagere tilbakemelding om hvor populært/bra eventet er. 6. Som brukeren av systemet (deltaker og arrangør) ønsker jeg å registrere meg og logge inn, slik at ingen andre enn meg har tilgang til min egen informasjon. 7. Som deltaker vil jeg at de nyeste events vises helt øverst i applikasjonen, slik at jeg slipper å scrolle opp/ned for å lete i tidligere events. 8. Som deltaker ønsker jeg å velge hvem jeg er på hotellrom med, slik at jeg havner på rom med personer jeg kommer godt overens med. Vi valgte å bruke Ruby/Ruby on Rails i backend, og JavaScript som språket som kommuniserer både med frontend og backend. På klientsiden bruker vi HTML og CSS for struktur og fin presentasjon av innholdet. PostgreSQL er det endelige databasespråket, og Heroku for å lansere det ferdige produktet. Etter mange gode tips fra oppdragsgiver, valgte vi nå å opprette kontoer og laste ned nødvendig programvare for å starte med utviklingen. Vi opprettet Github konto, Heroku konto og lastet ned Ruby on Rails sine nødvendige komponenter. 12

14 Oppdragsgiveren ville at vi bruker et format som gjør at applikasjonen kan fungere like bra på smartfelefoner og nettbrett (som ipad) slik som den gjør på PC. Med andre ord at den er responsiv og tilpasset alle skjermer den skal vises i, uten at dette var noe krav. Etter alle diskusjoner i gruppen og møter med oppdragsgiver kom vi frem til slik oppsett av systemet (bildet under). Brukeren (klienten) bruker applikasjonen i sin nettleser på mobil/pc/ipad. All kommunikasjonen til og fra klienten skjer via Internett. Ved første besøk (forespørsel) til applikasjonen laster klienten (nettleseren) ned skjelettet til applikasjonen (HTML og CSS). Deretter vil JavaScript overta og kommunikasjonen vil foregå med tjenestekall til og fra REST grensesnittet, som igjen kommuniserer med Rails serveren (Ruby) og selve databasen (PostgreSQL). 13

15 Vi bestemte oss for å lage en Singel Page Web Applikasjon (SPA). Etter å ha hørt om SPA fra oppdragsgiver og lest om det fra ulike kilder, fant vi ut at det er det som gjelder nå om dagene, og ikke minst at slike applikasjoner fungerer mye raskere enn de andre. Bruk av SPA øker brukervennligheten, fordi selve nettsiden/applikasjonen ikke trenger å lastes ned på nytt etter at den er lastet ned den første gangen. All data i nettleseren lastes kun ned en gang, og etter det er det kun data som brukeren spør etter som laster ned. Altså ikke hele siden men kun deler av siden som behøves å oppdateres Planlegging og metoder Herunder er beskrivelse av hvordan vi planla selve prosjektet og hvilke utviklingsmetoder vi brukte i starten. Inkludert hvilke utviklingsmetoder som ble erstattet, metodene vi droppet, og hvorfor. Det er også beskrivelse av prosjektdeler som utgjorde grunnlaget for både planlegging og valg av utviklingsmetoder. Planlegging startet etter at vi hadde valgt en av de valgbare oppgavene som vi fikk av oppdragsgiveren. Før vi kunne starte med utvikling fikk vi flere forslag til teknologivalg. Vi har vært så heldige med å få en oppdragsgiver som kunne vise oss ulike teknologier, og lære oss mye om gjeldende teknologier samt gi oss ett godt innblikk i hva som er mest etterspurt i arbeidsmarkedet for datastudenter. Siden oppdragsgiver ikke var helt sikker på hva han ville ha i starten, valgte vi sammen med oppdragsgiver å gå for en agile utviklingsprosess/smidig utviklingsprosess. Dette går ut på å reagere på endringer underveis i prosjektet. I motsetning til andre metoder hvor man har en stor og detaljert endelig kravspesifikasjon, så kartlegger man i samarbeid med oppdragsgiver hva behovene faktisk er. Videre etter dette bestemmer vi innad i gruppa med små innspill og diskusjoner hvordan vi kan og skal løse oppgaven. En annen grunn til at vi valgte smidig metodikk, er at vi ikke visste hvor mye tid de ulike oppgavene tok, vi planla derfor små spurter på noen uker og så fokuserte vi på at ting skulle være ferskvare. Med dette mener vi at ting ikke blir liggende halvferdig, men at vi fikk det ferdig fort og deretter gikk videre på neste oppgave. Dette sørget også for at de høyest prioriterte oppgavene ble løst først. Etter endt spurt hadde vi et møte hvor vi la frem det vi hadde jobbet med siden sist, og deretter planla vi neste spurt. Dette kalles gjerne scrum. Scrum: Rammeverk for å utvikle komplekse informasjonssystemer, men kan i prinsippet brukes til alle typer prosjekter som har en viss kompleksitet. Scrumgruppe består av tre roller: Produkteier, scrummaster og utviklingsteamet. I vårt tilfelle er Knowit produkteierer, vår 14

16 kontaktperson i Knowit er scrum master, mens vi spilte rollen som utviklingsteamet. Bildet under er en illustrasjon av denne scrummetodikken. Vi synes scrum funket veldig bra i starten av prosjektarbeidet, men etterhvert som tiden gikk følte vi at vi brukte mye tid under møtene på å planlegge neste spurt, mens vi egentlig skulle ha bruk tiden på andre ting som ga mer direkte resultat på prosjektet. Vi gikk derfor i retning av kanban og prioriterte ned sprintplanlegging og estimering som scrum utvikling foreslår. Kanban: Metodikken innebærer å begrense igangsatt arbeid. Nye ting må vente til de forrige er ferdigstilt. Videre arbeid planlegges ved avslutningen av forrige arbeid. Med andre ord tas/gjøres ting når det er behov. I vårt prosjekt tok vi tingene som hadde høyest prioritet først, og tok de andre med lavere prioritet når de forrige var ferdigstilt. Vi fikk et veldig godt råd fra oppdragsgiveren om å prioritertmerke deler av prosjektet i tre deler som følger: Høyest prioritet Middels prioritet Lavt prioritet Rapportdeling etter prioritet: Dokument del Møtereferater Notere ned liste av teknologier og verktøy som vi tar i bruk Prioritet Høyt Høyt 15

17 Organisere innholdsfortegnelsen Omskriving/renskriving av forhåndsnotert materiale (bla. fra møter) Sortering av dokumenter i rapporten Legge inn relevante bilder Oppretting av språklige feil Angi forsider til dokumenter Formatering av tekst og overskrifter Middels Middels Middels Lavt Lavt Lavt Lavt Produkt deling etter prioritet: Funksjon Opprette et event Se detaljer om et event Legge til deltakere Sende invitasjoner til deltakere Svare på invitasjoner Deltaker kan vise interesse for et event Deltaker kan gi ratings/stemme og legge inn en kommentar Deltaker kan sende sitt ønske om transport til arrangør Arrangør kan sende korte SMS meldinger Arrangør kan få tibakemeldinger etter avslutning Prioritet Høyt Høyt Høyt Høyt Høyt Middels Middels Lavt Lavt Lavt 16

18 Høyest prioritet Hovedfokus i starten av prosjektet var å begynne med ting som er av høyest prioritet. Blant dem var det å bli enige om teknologien som skal brukes, og deretter laste ned nødvendig programvare for å kunne etablere nødvendige kontoer som på Trello, Github osv. Vi begynte også å ta notater fra hvert møte fortløpende, slik at vi kunne bruke disse i møteloggen. I tillegg til de overnevnte opprettet vi liste av funksjoner i samarbeid med oppdragsgiveren vår og vurderinger etter hvor høyt eller lavt de var prioritert. Denne listen inneholdt følgende funksjonsliste: Lage et event Kunne se detaljer om event Legge til deltakere Sende invitasjoner ved å legge til flere e postadresser inn i et tekstfelt Svare på en invitasjon Og flere andre funksjoner med forbehold om endringer eller droppe noen av dem, kun hvis det blir for mye eller unødvendig. Middels prioritet Deler av prosjektet som fortjente middels prioritet for rapportskriving, var å finpusse og renskrive det som er notert under alt arbeidet som er gjort, til tidspunktet vi startet med de middels prioriterte delene av prosjektet. Vi tenkte at når vi allerede har notert ting som bare krever å bli omskrevet, kan vi utsette dette til vi er kommet mot slutten av høyt prioriterte ting. Når det gjelder produkt nyttige ting/funksjoner hadde vi følgende merket som middels prioritert: Som bruker av systemet kan man foreslå innhold til et event. Som tittel, sammendrag, varighet, format (fritekst), foredragsholders navn, foredragsholders e postadresse. Brukere av systemet er definert som deltakere for ett eller flere events som får invitasjon, eller de som skal holde foredrag (foredragsholdere). Med andre ord har de også mulighet til å spille rollen til en arrangør, ved å sende arrangøren sitt forslag om noen av de overnevnte. En slik funksjon mente oppdragsgiver er fint å ha, men vi må ikke tenke på dette i første omgang. Som deltaker har man mulighet til å vise sin interesse. Hvis det pågår flere konferanser samtidig i ulike saler i en bygning, er det fint å kunne se at hvor mange har meldt/vist sin interesse til de ulike konferansene/events, med tankene på at en arrangør kan bestille en sal med få eller mange plasser i henhold til antallet som møter. Som deltaker kan man gi ratings/stemme og legge til valgfrie kommentarer om et foredrag som skal holdes. 17

19 Lav prioritet: Ting som vi hadde tenkt å utsette helt, til vi er ferdig med alt ellers i prosjektet fortjente lavt prioritet. Når det gjelder rapportskrivingen, var det kun oss i gruppen som tok beslutninger. Med innspill og tilbakemeldinger fra både veileder og oppdragsgiver. Ting knyttet til sluttproduktet ble vi enige om i samarbeid med vår oppdragsgiver, siden det er han som skal eie produktet. For rapporten utsatte vi ting som å legge til relevante bilder og formatering av tekst overskrifter, legge til forsider for hvert nytt dokument i rapporten, plassere innholdet under riktige kategorier, til etter at vi blir ferdige med alle prosjektdokumenter. Og når det gjaldt produktrelaterte ting, fikk vi en liste fra oppdragsgiveren om hva som hadde vært greit å ha med, men som vi ikke måtte bruke tid på det hvis vi begynte å få dårlig med tid, eller ikke fikk nok tid til. Dette var følgende: En deltaker har muligheten til å gi sitt ønske om transport. Dette inkluderer ønsket om å være med på felles transport, ordne transporten selv, eller at arrangøren ordner transporten for deltaker på følgende dager. Den var en slik funksjon som etter oppdragsgiverens mening fortjener lavt prioritet. Arrangøren kan få tilbakemeldinger fra deltakere om arrangementet (for eksempel kan deltakere kommentere om maten, stedet, aktiviteter, programmet etc.). Arrangøren kan sende korte SMS meldinger/påminnelser/endringer til deltakere via systemet Risikoplan 18

20 Oversikt over mulige risikoer som kan påvirke prosjektarbeidet. Sansynlighet for at en hendelse dukker opp og alvorlighetsgrad etter at en hendelse har skjedd, er beskrevet som stor, middels og lav. Tabellen under er etterfulgt av forebyggende tiltak samt begrunnelse av sannsynlighetsgrad og alvorighetsgrad. Beskrivelse av hendelsen Konsekvens av hendelsen Sannsynlighet Alvorlighetsgrad Sykdom Kan ikke møte opp og gjennomføre sin del av arbeidet. Ved langvarig sykdom kan dette på virke store deler av prosjektet. Stor Middels Tap av gruppemedlem Noen slutter eller blir utvist. Lav Stor Uenighet Blir misfornøyd med andres meninger. Stor Lav Tekniske problemer Datamaskiner svikter, sted hvor data er lagret krasjer. Lav Stor Faglige problemer Noe vi ikke får til, koding osv. Middels Middels Sette seg for vanskelige mål Bruk av ekstra lang tid, som fører til kortere tid til å rekke fristen Lav Middels Sykdom: Sykdom kan inntreffe når som helst med tanke på det er det stor sannsynlighet at det skjer at noen i gruppen blir syke og kan ikke møte opp, og i noen tilfeller, ikke kan gjennomføre sin del av arbeidet. Alvorlighetsgrad er middels med tanke på vi har ca. 6 måneder på oss å gjøre ferdig prosjektet. Forebyggende tiltak for å ikke bli påvirket av hendelsen er at medlemmer som blir syke må gi beskjed til andre. Er han så dårlig og ikke kan jobbe hjemmefra heller, må han si ifra om det også, så kan en annen i gruppen ta over arbeidet hans. Tap av gruppemedlem: I vår gruppe er det lite sannsynlighet for at noen plutselig skal slutte eller noen blir utvist. Men om det skjer kan gruppen bli påvirket i stor grad, fordi det da blir litt ekstra å gjøre for de andre i gruppen. For å forebygge at noen skal slutte i gruppen er det fastsatt siden første møte at vi lytter på hverandre, og gi rom for andres meninger og viser respekt. For å ikke bli utvist av gruppen må alle gjennomføre sin del av arbeidet, komme tidsnok på møter. 19

21 Uenighet: Det er forstått at når det er fem ulike hjerner som jobber sammen, kan det dukke opp uenigheter blant de. Derfor er det stor sannsynlighet for at det skjer. Vi har også vurdert alvorlighetsgraden her til lav ettersom vi er alle sikre på at vi klarer å bli enige om løsninger og valg som alle på gruppen er enige i. For å forebygge konsekvenser av dette må vi respektere hverandres meninger, og hvis noen tar feil, sies det ifra til han på riktigmåte. Tekniske problemer: Datamaskiner vi jobber med kan jo svikte når som helst. Men med tanke på at alle i gruppen kan håndtere små feil og har installert antivirus på sine maskiner, er det lite sannsynlighet at vi kan oppleve slike problemer. Siden vi har det meste av arbeidet vårt lagt ut i Dropbox, Google Docs og på Github, er det lite skadelig hvis en maskin svikter og ikke minst har vi gode backup rutiner på eksterne disker (minnepenn). For å forebygge hendelsen er vi enige om å holde maskinene våre oppdatert og ta backup hver gang det skjer endringer i dokumenter/kode, samt oppdatere skyløsningene forløpende under arbeidet. Faglige problemer: Det er middels sannsynlighet for at vi møter faglige problemer med tanke på at vi får god hjelp fra veilederen vår. Dersom det trengs finner vi også flere gode guider og videoer på Internett. Om det dukker opp fagrelaterte problemer og veilederen vår ikke er tilgjengelig, og vi ikke finner noen veiledning andre steder heller, kan det skape store problemer for oss. For å forebygge det har vi bestemt oss for å gjøre ting tidligere enn å vente med de, og finne problemer i god tid før innleveringsfristen, og søke hjelp hos veilederen og andre steder. Sette seg for vanskelige mål: Det er lav sannsynlighet for at gruppen setter seg for vanskelige mål, fordi alle mål som blir satt i gruppen er satt ved en felles beslutninger. Alle er klare over hva dem kan, hva dem må bruke litt mer tid på og det som er utenfor rekkevidden deres. Med tanke på at gruppen viser interesse i å løse problemer, er det middels alvorlighetsgrad for konsekvenser, fordi alle i gruppen har vært flinke til å løse problemer så langt. Dette skal vi fortsette med senere i prosjektet også. 20

22 Ansvarskart Gruppen innså fort at det er viktig å kartlegge ansvarsfordeling på ulike områder i prosjektarbeid. Tanken bak den, var å skape ansvarsfølelse blant gruppemedlemmene, og å ha det klart hvem som skal gjørehva/bidra med hva. Tegnforklaring: X = Hoved ansvar for området O = Bidrar med Ansvarsområde Tam Gabriel Arslan Phillip Eivind Gruppeleder Kontakt med Oppdragsgiver (KnowIT) Kontakt med veileder (HiOA) X X O O O O X O O Rapportskriving X X X Gruppenettsiden X Koding X X O Språkvask, korrekturlesing Kontrollsjekk av prosjektet Levere Forprosjektet Levere Prosjektskisse Levere Hovedprosjektet Lage CD for kildekode Presentasjon av prosjektet O O X X X X X O O O X X X X O X O O O 21

23 I den gjenstående prosjekttiden måtte vi endre litt på roller for å rekke fristen, og jobbe ekstra effektivt. Vi splittet hele prosjektet i to deler, skriving av rapporten og koding. Tam og Gabriel fokuserte på produktet (koding) og Phillip, Eivind og Arslan skal fokusere på rapportskriving. Vi har alltid holdt kontinuerlig kontakt og har jevnlige møter. Fortsatt er det slik at alle er oppdaterte til en hver tid. Helt til slutt hadde vi et lengre møte hvor vi User stories, Use case diagram og Use cases for systemet User stories User stories kan gi veldig mye verdifull informasjon om hvordan et system og hvordan selve brukergrensesnittet skal se ut, ved å spørre de faktiske brukerne av systemet hva dem ønsker å bruke systemet til. Formatet for user storiene er som følgende: Som <brukeren> ønsker jeg <funksjonen>, slik at <nytteverdien>. User stories for systemet vi skal lage og bruke: 1. Som arrangøren av et event ønsker jeg å legge til nye events, slik at deltakerne kan finne og se på eventet og eventuelt melde seg på. 2. Som deltaker av et event ønsker jeg å se på events, slik at jeg eventuelt kan bestemme meg om å melde meg på ønskede event/events. 3. Som deltaker av et event ønsker jeg å sjekke tidspunktet/datoen for når et event holdes, slik jeg vet når jeg burde dra hjemmefra. 4. Som arrangøren av et event ønsker jeg å sjekke hvem som er påmeldt hvert event, slik at at jeg kan sende dem oppdateringer eller endringer. 5. Som deltaker vil jeg stemme på et event jeg likter/anbefaler, for å gi andre deltakere tilbakemelding om hvor populært/bra eventet er. 6. Som brukeren av systemet (deltaker og arrangør) ønsker jeg å registrere meg og logge inn, slik at ingen andre enn meg har tilgang til min egen informasjon. 7. Som deltaker vil jeg at de nyeste events vises helt øverst i applikasjonen, slik at jeg slipper 22

24 å scrolle opp/ned og lete i tidligere events. 8. Som deltaker ønsker jeg å velge hvem jeg er på hotellrom med, slik at jeg havner på rom med personer jeg kommer godt overens med. Use case diagram for systemet Dette Use case diagrammet viser hva brukerne hovedsakelig skal bruke systemet til. Brukerne/aktørene av systemet er Deltaker og Arrangør : Her er Use cases som viser applikasjonens grunnleggende funksjonalitet: 23

25 Use case Logge inn på applikasjonen Use case: Aktør: Pre betingelse: Post betingelse: Hendelsesflyt: Testen er gjennomført og kravet er oppfylt dersom: Alternativ flyt: Logge inn på applikasjonen Deltaker, Arrangør Brukeren ønsker å logge inn Brukeren er logget inn på sin konto 1. Brukeren trykker på Login knappen 2. Brukeren skriver inn sitt brukernavn og passord 3. Systemet logger brukeren inn 4. Brukeren er logget inn 1. Brukeren er logget inn på applikasjonen 2. Brukeren skriver inn feil brukernavn eller passord a.) Systemet gir melding om at brukernavn/passord er feil b.) Systemet resetter loginfeltet, slik at brukeren kan prøve å logge inn på nytt Use case Legge til et event Use case: Legge til et event Aktør: Pre betingelse: Post betingelse: Hendelsesflyt: Arrangør Arrangøren vil legge til et event han/hun skal holde Arrangøren har lagt til eventet 1. Arrangøren trykker på Create an event 2. Systemet sender brukeren til events registreringsskjematet 3. Brukeren fyller ut skjemaet og trykker Send 24

26 4. Systemet lagrer de registrerte dataene 5. Systemet lister ut det nye eventet 6. Brukeren får beskjed om at eventet er registrert Testen er gjennomført og kravet er oppfylt dersom: Alternativ flyt: 1. Eventet er lagt til 3. Brukeren mangler å fylle ut alle feltene i skjemaet a.) Systemet gir melding om at ikke alle feltene er fylt ut, og at brukeren burde se gjennom dette b.) Brukeren fyller inn de manglende feltene Use case Logge ut av applikasjonen Use case: Logge ut av applikasjonen Aktør: Pre betingelse: Post betingelse: Hendelsesflyt: Testen er gjennomført og kravet er oppfylt dersom: Alternativ flyt: Deltaker, Arrangør Brukeren er ferdig og vil logge ut Brukeren er logget ut av applikasjonen 1. Brukeren trykker på Logout knappen 2. Systemet logger brukeren ut 3. Systemet gir brukeren melding om at utloggingen er utført 1. Brukeren er logget ut 1. Brukeren har vært inaktiv i applikasjonen for lenge a.) Systemet gir melding om at brukeren har vært inaktiv for lenge, og er derfor automatisk logget ut b.) Brukeren er logget ut 25

27 2.2.6 Brukermanual Brukermanualen er ment som en veiledning til hvordan man skal bruke de ulike funksjonene av applikasjonen. Ettersom noe av funksjonaliteten ikke er ferdigstilt enda vil manualen ikke dekke disse. Det første som møter deg når du går inn på applikasjonen følgende side. All informasjonen om de ulike eventene er åpent, det vil si at man ikke trenger og logge inn for å kunne se når de ulike eventene går og eventuelle endringer som har blitt gjort. Under skal vi i nærmere detaljer gå inn på de ulike punktene. 1. Hjem Knappen HOME merket med et rødt 1 tall fører deg tilbake til startsiden, dette vil være den samme siden som er vist i bildet over. Denne knappen vil på lik linje som alle de andre knappene på menyraden på toppen være synlig gjennom hele applikasjonen. 2. Hjelp Knappen merket HELP vil ta deg ned til bunnen av siden 26

28 Man vil få detaljerte veiledning til de ulike funksjonalitetene som viser hvordan man oppretter en konto eller hvordan man lager et event. 3. Lage et event. Knapp nummer 3 er merket CREATE denne knappen fører deg videre til følgende skjermbilde: 27

29 Siden er intuitiv og selvforklarende. Man fyller inn den informasjonen som står oppgitt og trykker Register på bunnen. Informasjonen om eventet du har tastet inn vil da bli synlig på første siden i bolkene merket med tallet 5 på det første bildet. 28

30 4. Log In Knappen Log in fører deg videre til følgende side Her har vi to valg, om man er tidligere registrert på siden taster man enkelt og greit inn e postadressen samt passordet sitt og trykker på knappen merket Sign In (A) Har man derimot ikke en tidligere konto, men ønsker og registrere en konto for å begynne og bruke applikasjonen trykker man på knapper til høyre merket Sign Up (B). Logger man inn vil man bli videreført tilbake til første siden, men man har da mulighet til å melde seg på eventer og eventuell funksjonalitet som er begrenset til de registrerte brukerne. Sign Up knappen vil åpne følgende side 29

31 Hvor man taster inn navnet sitt, e posten sin samt et ønsket passord og trykker Sign Up, etter det kan man logge seg inn og bruke tjenesten til det fulle. 5. Bolkene merket med en rød pil og tallet 5 på det første bildet er oversikten over de registrerte eventene og noe kjapp informasjon, trykker man derimot på et av eventene vil følgende vindu komme opp med mer informasjon om det valgte eventet 30

32 Her får man opp informasjon som er blitt lagt inn til det valgte eventet, feks hvem foredragsholderen er, tema som vil bli gått igjennom, kontaktinformasjon osv. 31

33 2.2.7 Testing Ettersom alt i dette prosjektet var nytt sitter ingen av oss med kunnskap til å kode tester som gir noe særlig verdi i praksis. Til tross for mangelen på kunnskap skjønte vi at det var nødvendig med testing av Rest API et i Rails, når vi skulle inkludere Angular.js i applikasjonen. Det var viktig å teste at Rest API et fungerte, slik at vi viste om eventuelle feil lå i Angular delen av applikasjonen. Uten denne testingen ville det vært umulig for oss å lokalisere eventuelle feil som kunne oppstå, uten å bruke veldig mye tid. For å teste Rest API et brukte vi Advanced Rest Client Application. Det er en utvidelse i Google Chrome. Ved hjelp av denne applikasjonen kunne vi sende GET, POST, PUT og DELETE Json kall til vår Rails backend for å sjekke at den behandlet alle kallene riktig. Vi kunne dermed utelukke om det var noe feil med Rest API et hvis vi ikke fikk responsen vi ønsket i vår Angular frontend. Når vi kom så langt at vi kunne kjøre applikasjonen og teste funksjonene vi hadde laget, brukte vi Developer Tools som er innebygget i Google Chrome. Her fikk vi en oversikt over nettverkstrafikken. Med hjelp fra Developers Tools kunne vi se om det oppsto feil under kjøring av applikasjonen og om det oppsto noen routing errors. Med hjelp av disse verktøyene sparte vi oss for mye unødvendig problem. Hvis vi velger å jobbe videre med denne applikasjonen senere vil det bli nødvendig å utvide med en del tester, som kan gi tilbakemelding til brukere, dersom det for eksempel skulle oppstå en feil mellom front end og back end. Ved slike feil er det viktig at det er en test på plass som kan gi brukeren riktig informasjon. Det er viktig at ikke brukere tror feilen er hos dem, når det egentlig er på serveren. 32

34 3. Konklusjon Vi vil her oppsummere rapporten og gå inn på videre arbeid med produktet samt vurderinger både fra vår side som studenter, men også oppdragsgiverens vurdering av samarbeidet og produktet. 3.1 Videre arbeid Ettersom applikasjonen ikke er 100% ferdig til rapporten blir levert inn har vi sammen med vår oppdragsgiver planlagt litt videre arbeid frem mot fremføringen slik at vi får noen flere funksjoner i land. Vi har satt opp 2 nye møter med oppdragsgiver hvor det kommer til og være 100% fokus på kodingen og de funksjonene vi ser på som essensielle for applikasjonens del. 3.2 Oppdragsgiverens syn på produktet Under det siste møte med oppdragsgiveren fikk vi satt oss ned i felleskap. Vi fikk da gjennomgått det som var gjort så langt, gått igjennom rapporten samt snakket om hvordan samarbeidet har vært. Tobias som er vår kontaktperson var veldig fornøyd med prosjektet. Han var spesielt fornøyd med måten oppgavene og de gitte problemstillingene var løst på og så fram til å se hvordan det endelige produktet blir. Vi fikk tilsendt en attest på prosjektet som inneholder en vurdering fra Tobias, denne er lagt ved dokumentet som et ekstra vedlegg på slutten. 3.3 Vår egen vurdering av prosjektet. I løpet av prosjektperioden har vi tilegnet oss nye kunnskaper. Vi ble kjent med gjeldene teknologier i arbeidsmarkedet gjennom oppdragsgiveren vår. Tekniske verktøy som vi ikke var kjent med fra tidligere prosjekter, ble vi godt kjent med. Når gjelder prosjektarbeid i henhold til gruppearbeid har vi ingen tvil om å si at den har fungert helt utmerket. Vår hovedfokus var å ha tett kommunikasjon i gruppen og holde hverandre oppdatert om enhver endring, oppdatering og alt som har noe med prosjekt å gjøre. I tillegg til hjelp fra veileder og oppdragsgiver var vi veldig avhengig av hverandreshjelp for å bli flinkere på riktig bruk av verktøy spesielt Github og Heroku. Vi har lært mye av hverandre. Siste men ikke minst, alle har fullført sin rolle i gruppen som de burde. I løpet av prosjektet har det aldri vært snakk om at prosjektet er kjedelig eller for stort i motsetning til det alle har støttet hverandre og hjalp til med holde motivasjon på toppen. 33

35 Det har også vært noen ting som vi nå syns kunne gjøres litt annerledes. Vi burde skrive og fin pusse dokumentene underveis enn å utsette de til sluttfasen av prosjektet. Vi kunne ha startet litt tidligere med prosjektet og brukt mindre tid på teknologivalg. Men tross for svakhetene, har vi klart å opprette gode dokumenter samt godt slutt produkt som oppdragsgiver er fornøyd med. Attest fra oppdragsgiveren kan ses for å få inntrykk av hvorvidt produktet kan ses som godt produkt. 34

36 3.4 Vedlegg Prosjektskisse Dette har skjedd siden sist gang Vi har hatt flere gruppemøter og diskutert flere ulike oppdragsgivere, og undersøkt om disse var villige til å være oppdragsgivere for bachelorprosjektet. De fleste var negative, men vi fikk positive svar fra blant annet Fiskeportalen, CapGemini og Knowit. Fiskeportalen var veldig interesserte i å kontakte oss, men har ikke sagt noe konkret om hva de ønsker eller hva vi skal lage for dem. CapGemini sendte oss ulike valgbare oppgaver, samt lurte på hva vi kunne gjøre for dem, men grunnet mye annen konkurranse fra andre elever ble det ikke noen oppgave for CapGemini. Vi har hatt et møte med Knowit her i Oslo, og det er dette selskapet som er mest interessant for oss. Det er fordi de var veldig åpne om hva vi kunne jobbe med, i tillegg til at de var åpne til våre preferanser for teknologier og domener. Dette er også et spennende selskap innenfor en sektor av bransjen som vi alle kan tenke oss og jobbe innenfor. Vi har fått ett nytt gruppemedlem, Eivind (s180381), så nå er vi 5 stykker på gruppen. Vi har også laget og opprettet vår gruppeside til prosjektet. Linken til denne er: Prosjektskissen Foreløpig/midlertidig tittel: «Bachelorprosjekt hos Knowit» Oppdragsgiverens navn: Knowit Oppdragsgiverens hjemmeside: Oppdragsgiverens adresse: Universitetsgata 7, 0164 OSLO Oppdragsgiverens kontaktperson: Tobias Torrissen Oppdragsgiverens telefonnummer: Første møte med oppdragsgiver: Onsdag 26. November 2014, klokken 10:00 Kontaktinformasjonen ble funnet på oss/ En kort oppsummering av oppgavene fra oppdragsgiver så langt i prosjektet: 35

37 1. Konferansehåndtering. Påmelding, avmelding, bestilling av hotellrom, påmelding av aktiviteter etc. Innsending av foredrag, oppsett av program etc. 2. Hvor er folk og hva jobber de med? System for å synliggjøre hvor folk jobber. Integrasjon med timereg system? 3. System for å håndtere tilbudsskriving. Standardtekster, søk, versjoner av samme tekst. Her har oppdragsgiver ikke så mange ideer. Krever nok endel analyse. 4. Foredragsholderdatabase. Oversikt over hvem som har holdt foredrag og hvor de er holdt. Presentasjon av slides og muligens video. 5. Noe vi definerer som Knowit har interesse av. De har også en masterstudent på design, som kanskje kommer til å jobbe med designet på noe av dette. Det er viktig at vi setter det opp slik at man ikke er avhengig av hverandre, men det hadde jo vært moro med et design som ser bra ut? Vi må inngå en samarbeidsavtale med bedriften, i tillegg til at alle gruppens medlemmer må møte oppdragsgiveren. Videre må HiOA godkjenne dette. 36

38 3.4.2 Forprosjekt Prosjektets endelige tittel : Engelsk prosjekttittel: «Calendarmanager (SPA) on Web» Prosjektets varighet : Høsten 2014 Våren 2015 Vår veileder: Ismail Hassan Oppdragsgiver: Knowit Oppdraget/oppgaven Konferansehåndtering på Web (SPA). Påmelding, avmelding, bestilling av hotellrom, sjekke hvem man er med på hotellrom, påmelding av aktiviteter etc. Brukerne kan også sende inn sine egne foredrag, oppsett av sitt program etc. Sammendrag av oppdraget Å utvikle et konferansesystem på Web for IT selskapet Knowit, hvor brukerne av dette systemet kan administrere sine konferanser/foredrag direkte i nettleseren. Selve applikasjonen/programmet skal være en såkalt single page application (SPA), hvor programmet lastes direkte inn i nettleseren på første forespørsel, uten at brukerne trenger å laste ned ekstra plugins/tillegg eller ekstra oppsett. Serverkommunikasjonen skal foregå i bakgrunnen. Hele systemet skal være ryddig og presist satt opp. Det skal også ha ekstra tilhørende funksjoner som vil hjelpe brukerne med å lete etter og finne informasjon om de ulike konferansene/foredragene. I tillegg til dette kan brukerne velge hvem dem ønsker å være med/sjekke hvem dem er på hotellrom med, og mulighet til finne relevante kontaktpersoner (som navn og telefonnummer). Etter fullført prosjekt har vi en felles avtale mellom arbeidsgiver at begge parter helt fritt og helt gratis kan bruke og videreutvikle systemet. Vi har også fokus på ryddig kildekode og velfungerende kode. Vi foretrekker alltid kvalitet fremfor kvantitet. Mål og rammebetingelser Målet med oppgaven er å lage en web basert løsning, for å håndtere konferanser som bedriften arrangerer både innenlands og utenlands. Det skal være en selvbetjenings løsning på Web, med andre ord trenger hverken organisator eller deltakere å kommunisere over telefon eller andre kommunikasjonsmiddler, som ofte kan regnes som forstyrrende eller uønsket når man for eksempel sitter i et møte. Web løsningen vår skal gi organisator og deltakere mulighet til å kommunisere på en bedre, mer oversiktlig og mer effektiv måte sammenliknet med det Knowit bruker i dag. Etter å ha møtt oppdragsgiver, har vi fått følgende punkter å ha med i løsningen, sortert under to kategorier: 37