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 [email protected] OPPDRAGSGIVER Knowit KONTAKTPERSON Tobias Torrisen [email protected] 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

39 Organisator Lage et Event Sende invitasjon Handlingen inneholder å sette opp følgene info om Event: Navn Beskrivelse Periode Sted Kartreferanse Arrangør Arrangørens e post Arrangørens telefonnummer Eventuell info om fellestransport Invitasjoner skal genereres og sendes, ved at organisatoren legger til en liste over e post adresser inn i et tekstfelt. Invitasjonene kan deretter sendes til alle de oppgitte e post adressene. Deltaker Svare på invitasjon Mulighet for å oppgi ekstra info om Spesifisere spesielle behov Takke Ja/Nei til invitasjonen. Hvis ja, oppgi mobilnummer og e post adresse. Være der lenger/kortere Rom (enerom/dele med noen) Velge romkamerat Bytte med noen Ha med ekstra person. Kost, allergier etc Det er planlagt å utvikle løsningen med flere funksjoner og finesser dersom oppdragsgiver ønsker dette. Eller at vi kan komme med ekstra forslag om innhold til sluttproduktet som oppdragsgiver kan takke ja til. Løsningen Løsningen vi har kommet frem til med hjelp fra oppdragsgiveren, er en single page web applikasjon (SPA). Vi stod fritt til å ta egne teknologivalg fra oppdragsgiver sin side, men fikk en del gode eksempler og forslag fra han. Vi har tatt følgende teknologivalg: 38

40 På brukersiden/i nettleseren skal det brukes vanlig robust HTML, CSS og JavaScript. På serversiden skal Ruby og relasjonsdatabaser brukes. Analyse av løsninger Ettersom Knowit ikke var 100% sikre på hva de ville ha, så besluttet vi å bruke en Agile utviklingsprosess. Det gir mulighet til å endre og tilpasse løsninger på veien. På de tidligere møtene med Knowit diskuterte vi hvorvidt vi skulle ha planlagt sprinter. Eller om vi skulle jobbe med de punktene som var høyest prioritert. Vi synes at ved å planlegge sprinter på hvert møte ville mye av tiden gå bort i planlegging og ikke produksjon. Vi bestemte oss derfor å bruke noe tid på å rangere de ulike oppgavene på prioriter. Vi startet å jobbe med de oppgavene som er av høyest prioritet. Ved å gjøre dette blir ikke oppgaver hengene i mange uker. Vi har også satt demomøter med Knowit hver 3.uke. På disse møtene vil vi vise hva vi har gjort siden sist, samt gå gjennom eventuelle endringer og rettinger. Når det kommer til valg av kodespråk og løsninger ble det diskutert mye. Rammeverk til serveren stod valget mellom Rails og Sinatra. Fordelen med Sinatra over Rails, er at man får noe mer kontroll over koden. I Sinatra kodes det meste fra bunnen av som er mer tidskrevende om man ikke tidligere har jobbet med Sinatra. Det var akkurat dette som gjorde av vi i stedet valgte Rails over Sinatra. Rails gir ferdige templates som for oss er lettere og mer effektivt. Etter flere møter med oppdragsgiver og i gruppen kom det tydelig frem at hva vi skulle lage. Vi begynte å planlegge og brainstorme om hvordan dette systemet kunne fungere, ulike teknologier/språk og oppsett, samt hvordan serverkommunikasjonen skulle foregå. I starten ble ulike typer JavaScript, databaser (som relasjonsdatabaser og restdatabaser) og skytjenester nevnt, samt oppsett av mellomlagring (som for eksempel REST system). REST kan blant annet lagre data til ulike URL er. I tillegg til ulike programmeringsspråk som Java,.NET, PHP, Scala og Ruby. Det ble mye diskusjoner om rammeverk/frameworks. Vi ble enige om at vi skulle bruke Ruby(ruby on rails). Videre valgte vi relasjonsdatabase/postgresql på serversiden. På klientsiden (i nettleseren) skal vi bruke HTML, CSS og JavaScript (som jquery). Vi er godt i gang med å lære oss Ruby og mer avansert JavaScript, slik at vi kan utvikle systemet i størst mulig grad men egendefinerte koder. På serversiden var vi inne på mange kodespråk som node.js, Scala, C Sharp og Ruby, men det ikke er bestemt hvilken av de skal vi bruke ennå. Etter anbefalinger fra Tobias (vår kontaktperson) og Kristofer som er fagansvarlig hos Knowit, gikk vi i retning mot Ruby. Vi avsluttet derfor møtet og hadde som oppgave til neste uke å sette oss inn i de ulike språkene. Etter en uke så hadde vi alle prøvd de ulike språkene litt, alle syntes at Ruby virket spennende, og ettersom at det er et språk som er mye brukt så valgte vi det. Ettersom Tam og Gabriel er godt kjent med jquery fra før, og Tobias og Kristofer også anbefalte dette, ble vi enige om at jquery ble valgt som rammeverket på klientsiden. 39

41 Konklusjon og veien videre Oppdragsgiveren og gruppen har en felles avtale om at vi møtes hver 3. uke. Vi kontakter oppdragsgiver (gjerne på e post) om vi står fast eller har spørsmål. Vi har skrevet kontrakt med oppdragsgiver. Vi har gruppemøter hver uke, samt at vi kommuniserer på Facebook, på SMS og telefon. Vi har opprettet våre kontoer på den web baserte tekniske verktøyene som Trello, Github og Heroku. På Trello noterer vi ned selve deloppgavene og merker av når hver deloppgave er fullført, slik at vi på en ryddig måte kan begynne på den neste deloppgaven. Vi bruker Github for å håndtere/videreutvikle all vår kildekode. Vi bruker Heroku som er en gratis skytjeneste som støtter flere programmeringsspråk (som for eksempel Ruby) og er spesielt nyttig i webutvikling. Videre må vi finne ut hvordan vi skal sette sammen hele systemet, slik at det fungerer robust, sikkert og stabilt. Vi må også designe brukergrensesnittet til applikasjonen, slik at det blir så ryddig og brukervennlig som mulig. 40

42 3.4.3 Prosjektdagbok Dagbok gir leseren innblikk av hvordan vi har jobbet gjennom prosjektet. Referater er merket med dag/dato vi hadde møter. Diskusjoner vi hadde via facebook/e post er i tillegg som ikke var nødvendig å gi plass i dokumentet Hele gruppen møter for første gang, blir kjent med hverandre og snakket om de ulike kunnskaper og kompetanser vi hadde. Planlegging av hvordan det skal jobbes, planlegge faste dag/dager for møter osv. Diskusjon om hvilke oppgaver vi kunne tenke oss å velge, og hvilke firmaer vi hadde lyst til å jobbe hos Gruppen ble enig om hvem som skal være gruppeleder og registrere gruppen offisielt hos HIOA. Vi startet med å sjekke hioa sitt forslag til prosjektet. Vi kontaktet blant annet fiskeriportalen og TurboDevs. Vi avtalte møte med Turbo devs og samlet inn våre karakterutskrifter og CV er, med tanke på at noen oppdragsgivere kan være interessert i å se på Idag hadde vi møte med Turbo dvs. Alle ble enige om å møte opp på skolen 1 time før møtet. Vi forberedet oss for møte. Vi ble fortalt nærmere om hva prosjektet gikk ut på. Den oppgaven gikk ut på universell utforming som skal i grunn støtte et nytt språk, bliss språket. Det var ingen konkret oppgave de hadde og vi hadde derfor litt vanskelig med å forstå hva de egentlig ville ha. Av den grunn valgte vi å lete videre, hos andre oppdragsgivere. Å få en intern oppdragsgiver fra skole har alltid vært tema i møtene våre, men den muligheten vil vi helst benytte oss av etter at vi har letet etter oppdragsgiver på egenhånd først Etter de møtene vi tok tidligere bestemte vi oss for å bruke litt tid på å bli kjent med ulike programmeringspråk, som vi ikke var kjent med fra før. Eksamene var i gang og alle i gruppen hadde mye annet å forholde seg til enn prosjekte. Det ble derfor langpause mellom forrige og dagensmøte. Idag ble vi enige om å lage gruppens hjemmeside og opprette Facebook gruppe for å effektivisere kommunikasjon blant gruppe. Videre diskuterte vi mulige oppdragsgivere og sendte mail til blant annet Telenor, CapGemini, Netcom, Fiskeportalen og Knowit. Vi fikk positive svar fra Fiskeportalen, CapGemini og Knowit. KowIT som vi alle i gruppa var veldig positive til, ville høre om hva vi ønsket ang. prosjektet. Så det blir møte med dem på 26 november

43 Først hadde vi møte med Knowit. Vi ble kjent med bedriften og kontaktperson vår, som skal også være leder for prosjektet, hvis vi skriver vår oppgave hos dem. Vi fikk en liste med oppgaver de hadde for oss på mail etter møte. Det blir ingen møter frem til neste år, fordi noen av oss fortsatt har noen eksamen å avlegge. Men vi skal holde kontakt å oppdatere hverandre hvis vi finner noen nyttige ting knyttet til prosjektet Vi har tidligere levert prosjektskissen, og venter på godkjenning fra HiOA. Tidligere (i slutten av 2014) har vi vært på to møter med Knowit. I dag er altså vårt tredje møte med dem. Vi er godt i gang med oppgaven. Blant de valgbare oppgavene vi skrev om i prosjektskissen, valgte vi: Konferansehåndtering. Påmelding, avmelding, bestilling av hotellrom, påmelding av aktiviteter etc. Innsending av foredrag, oppsett av program etc. Vi valgte denne oppgaven fordi vi mente at den passet best for oss med tanke på gjennomførbarhet, tid og kompetanse. Knowit foreslo å kjøre hele prosjektet som et ekte typisk systemutviklingsprosjekt, noe som gruppen godtok. Dette vil gi gruppen erfaring fra et hverdagslig praktisk perspektiv, i denne bransjen. Dette inkluderer alt fra userstories til iterative prosesser. Videre har vi nøye sett på og diskutert ulike teknologier, språk og oppsett i detalj, for å finne ut hvordan konferansehåndteringssystemet skal virke, og hvordan brukergrensesnittet skulle se ut. Blant annet har Knowit foreslått REST system, relasjons eller dokumentdatabaser (med tilhørende SQL etc.). Ulike former for Java og JavaScript for å håndtere serverkommunikasjonen er også rådet av Knowit. Vi må definere en kravspesifikasjon og lage en realistisk tidsramme for hele prosjektet. Etter møtet hadde vi et gruppemøte på skolen. Vi diskuterte ulike relevante teknologier og mulige oppsett. Blant annet Ruby,.NET, node.js, Scala og skyutviklingstjenester som Heroku og Azure. Dersom vi benytter.net ble utviklingsprogrammet Visual Studio nevnt, og at skolen har lisenser til dette. Likevel synes vi at Ruby virker som et interessant og forståelig språk, med tanke på omfanget av prosjektet. Vi ønsker å tenke enkelt og kode alt fra bunnen av. Heroku ble valgt for kjøring av koder.vi skal benytte Github til å lagre all koden/kildekoden, og se endringene vi gjør i koden. Det vi likte best med å bruke heroku og github var at begge tjenester er godt integrert sammen. Heroku er altså gratis å bruke. 42

44 I dag er det møte med oppdragsgiver. Vi viser frem et lite eksempel på hvordan det kunne se ut, og hva som, etter vår forstand passer/ikke passer sammen av teknologier og oppsett, som ble diskutert på forrige møte. Vi var fritt til å kontakte oppdragsgiver via e post dersom det oppstår problemer underveis i prosjektet. Det ble fastsatt at konferansehåndteringsløsningen skal ikke inneholde innlogging funksjon, men at brukerne heller trykker på en link/linker for å styre og administrere sitt eget grensesnitt/konto, og at brukerne derfor må registrere sin e post adresse i dette systemet før man kan bruke det. På klientsiden/i nettleseren, ble det en stor diskusjon om bruk av HTML, CSS og JavaScript/jQuery. Vi gjennomgikk og la inn flere endringer/oppgaver i Trello, og ble anbefalt å bruke et mellomlagring databasen og klienten for kjappere ytelse. Videre diskuterte vi deployment rutiner og hvordan strukturen og dataflyten raskt kan endre en applikasjon. For eksempel vil endringer i en databasetabell skal raskt vise kodeendringer. Derfor er det viktig å teste ofte, for å finne mangler og begrense feil i koden Idag ble det snakk om design på sluttproduktet. Alle har med sitt forslag om design, men tanken på at det kan gjøres endringer underveis som kan gjør det vanskelig å få til et design. Vi er fullstendig klar over at det er litt for tidlig å bruke tid på designvalg, men vi gjorde det likevel for å få sjekket hvor mye arbeid det kunne tas. Videre diskuterte vi funksjoner vi skal lage ferdig eller prøver å lage til neste møte med oppdragsgiver. Neste møte skal avtales på facebook! I dag hadde vi møte med oppdragsgiver Knowit og diskuterte rammeverkene Rails og Sinatra, og hvilken av dem som egner seg best for prosjektet. Rails er mer "ferdig", mens Sinatra handlet mest om å begynne på nytt. Samtidig er Rails mer begrenset til post/request, grensesnittet, noe som kan være utfordrende å lage en SPA av. Vi gikk kjapt gjennom Heroku oppsettet. Fikk veiledning for å bruke github riktig, av oppdragsgiveren. Ble diskusjon rund valg av database. Vi sto mellom to valg PostgreSQL og MySQL. Vi så også på server oppsett, i forbindelse med at man hovedsakelig trenger to kodetrær, en på servesiden og en på klientsiden. Det vi si Rails med databasen på serveren, og JavaScript på klientsiden som kommuniserer med dette I dag var det enda et møte med oppdragsgiveren. Vi viste frem koder vi hadde laget, både fungerende og ikke fungerende. Vi fikk tilbakemeldinger og råd om hva vi trenger å endre og hva som vi kan la være slik som det er. Det vi hadde av ferdig kode var et skjema som var knyttet til en PostgreSQL database. De av oss som brukte windows opplevde vanskeligheter med å koble skjema med PostgreSQL. Windows brukere måtte velge SQLite som ble ikke anbefalt av oppdragsgiveren. På grunn av vanskeligheter windows brukere hadde angående koblingen til 43

45 postgresql database, fikk vi råd om å laste ned VM ware og opprette en Debian maskin og prøve å få til database tilkobling. Det prøvde windows brukere og det gikk fint. For Mac brukerne var det bare å kjøre på. Neste møte med oppdragsgiver er satt til 25.februar I dag hadde vi et møte med vår veileder Ismail. Vi snakket om hvordan prosjektet har gått så langt. Vi ble rådet på det sterkeste å ikke vente med å starte på rapportskriving. Vi fikk også gode innholdsforslag til rapporten som å begrunne valgene vi tar og hvordan dette påvirker selve sluttresultatet. Etter møtet med Ismail hadde vi et gruppemøte. Da startet vi med å gjennomgå hvilke koder som skal ligge hvor(på server side eller klient side). Vi snakket rundt teknologier Polymer og Angular for frontend utvikling. Polymer både ser og virker som en app, og kan egne seg til både desktop, touchskjermer/mobile enheter og i nettlesere generelt, mens det samtidig gjør mye for deg. Til slutt la vi Polymer til siden fordi vi ønsker å ha mest mulig kontroll på koden (kode mest fra bunnen). Angular hadde mye av det vi trengte, uten å påtvinge mye unødvendige skjulte funksjoner og koder. Vi diskuterte hvilke elementer (blant annet bilder og knapper) vi trenger og hvordan utseendet på brukergrensesnittet (GUI) skulle være. Vi ble enige om at brukergrensesnittet skal ha brukervennlig utforming. Videre gikk vi gjennom oppsett av REST grensesnitt/api, samt databaseoppsett. Vi sliter med å opprette en fungerende kommunikasjon mellom server og klient. Neste møte er 24. februar Mye av gruppe diskusjoner har skjedd via facebook. I dag bestemte vi å møte for å presentere alt av vi har gjort/funnet så langt, til hverandre. Vi diskutere også hva vi legger frem på møte i morgen med oppdragsgiver. Vi hjalp hverandre med å få til det som andre i gruppen ikke har fått til, det var viktig med tanke på at alle har sin maskin og koder i lik stand enn at det er forskjell mellom kodene og vanskelig å hjelpe hverandre etter noe tid har gått. Vi var fult klar over at alle kan ikke holde på med samme oppgave, og vi må snart fordele oppgavene. Siden vi alle hadde lyst til å lære oss Ruby som vi har valgt som programmeringsspråk, tenkte vi at det var greit til et tidspunkt at vi alle gjør samme ting og lære litt av hverandre. Videre gikk vi gjennom hvordan man bruker Github med Heroku, noe som har vært en utfordring. Arbeidsflyten ble hovedsakelig fra PC/Mac (lokalt) til Github, og endelig til Heroku (endelig produkt). Blant annet er det noe på Github som heter branching, dette lager en kopi av koden man jobber med. Til slutt merger man dette inn i hovedbranchen (Master) når koden er ferdig. Det er også lurere med flere små endringer, sammenliknet med veldig få store endringer. Det er lett å gå seg vill med versjonsnummer og liknende, så det er viktig å forsikre seg om at man jobber på rett kode og navngir alle filene konsistent og lettfattelig. 44

46 Idag var det møte med oppdragsgiveren. Vi ga rapport om det som vi har gjort siden sist, og viste frem det vi hadde lagt, som var to eksempler av fungerende SPA, som var en liten funksjon av sluttproduktet og innholdsregistrering i databasen. Dessuten diskuterte vi litt rundt teknologi for design blant annet Polymer som vi fikk råd om å teste ut fra veilederen vår ved hioa I dag fikk vi kun tid til et kortvarig møte. Vi diskuterte videre om backend og frontend, og hvordan kommunikasjonen mellom disse skal foregå. Vi husket også fra møter med Knowit at vi burde krypterte informasjonen som sendes og mottas, om vi fikk til dette. Dette vil begrense angrep og ondsinnet kode som the man in the middle attack (MITM), cross site scripting (XSS), og cross site request forgery (CSRF). Vi har også gjennomgått foreløpig kildekode I dag hadde vi et møte med oppdragsgiver Knowit. Vi startet med å diskutere hvordan oppsett av konferansene skulle være og hva som var det viktigste. Det viktigste var at vi klarer å få til å vise eventene/arrangementene, og begrense bruken av e post i sammenheng med påmelding og administrasjon av deltakere. Oppdragsgiver viste oss et eksempel på en databasemodell, blant annet at et event har flere events/arrangementer, samt at et event/arrangement kun kan ha en ansvarlig/eventmaster (en til mange relasjoner). Vi fikk også et innblikk i et par av Rails sine funksjoner "ActiveRecord" og " Scaffolding ". Vi så nytten dette kunne gi, samtidig som at mye kode og mapper lages ved å bruke disse. Det handler derfor om å finne balansen, men vi er alle nybegynnere i rammeverket Rails og lære mye av dette. Vi holder fast ved å kode mest mulig fra bunnen av. Vi oppdaterte Trello med statusendring på oppgavene, og fordelingen av disse. Når møtet nærmet seg slutten ble vi anbefalt å bruke AngularJS, som kan kommunisere til og fra serverside og klientside I dag viste vi fire eksempler på frontend/brukergrensenitt for Knowit. To var laget fra bunnen av, mens to var laget med bruk av blant annet Bootstrap. Han sa sin mening om alle eksemplene, og hva som kan forbedres. Han var mest fornøyd med Bootstrap løsningen som automatisk tilpasset skjermstørrelsen. Utfordringen var å endre dette til å vise alle registrerte events/konferanser, hvor nyeste event/konferanse står øverst. I dagens diskusjon kom det frem at login funksjon som vi droppet i starten var likevel fint å ha. For å lage innlogging funksjon, burde vi bruke Ruby gems (funksjonsbiblioteker) som inneholder selve loginfunksjonene. Selvom det blir lagt til innloggingfunksjon ved scaffolding automatisk må kodene opptimaliseres ved behov. Det skal også legges til brukerregistrering funksjon. Alt dette må overlates til vår Rails og Angular backend. Det ble ekstra utfordrende å bruke REST grensesnittet med denne løsningen, 45

47 men vi er optimistiske og har troen på at vi klarer å få det til å virke. Alt må skje på en side (Single Page Applikasjon). Vi gjennomgikk nye Rails eksempler. Blant annet ble det nevnt at Scaffolding kan generere brukergrensesnittet, formatering og database. Det ble også nevn at en av de negative sidene med å kode mest mulig fra bunnen av, var at det tar betydelig lengre tid. Til gjengjeld lærer man mye mer, og man har mye større kontroll over koden. Vi må også være helt sikre på at sensitiv informasjon alltid må lagres kryptert/sikkert. Vi må bruke PostgreSQL, fordi Heroku ikke støtter andre databasespråk like bra. Vi må også huske at nøklene mellom tabellene er relatert til hverandre. For eksempel vil det å opprette et nytt event gjøre at personen som opprettet eventet blir ansvarlig/master for eventet, altså administratoren. Personen i brukertabellen blir relatert til dette eventet i eventtabellen I dag gjennomgikk vi hvordan man sender data/input til backend, og hvordan dette lagres i databasen. Oppdragsgiver ønsket login funksjonalitet, og ikke lenger login ved hjelp av en e post link. Vi besøkte også og gjennomgikk for eventuelle andre Rails funksjoner vi har nytte av i backend koden. Login skal skje på samme side uten at siden lastes ned på nytt, som er et tegn på applikasjon er Single Page Applikasjon som oppdragsgiver har ønsket. Vi ønsker også å forandre bakgrunnen til å bli mørkere når loginviduet vises, og dette skal vi løse ved hjelp av CSS I dag hadde vi et møte med oppdragsgiver. Vi har begrenset med tid, og fristen nærmer seg. Det er viktig å begrense alle valgene (inkludert positive og negative sider). Vi mangler nå å få hele systemet til å "snakke" sammen, og teste det slik at det kan liste ut events og lagre brukernes påmeldinger. Backend og frontend må kunne snakke flytende sammen, så JavaScript/AngularJS må også kunne snakke med Rails. Dette har vært den store utfordringen i prosjektet, da vi ikke har funnet gode konkrete eksempler. Vi har derfor stått fast og lest masse om Rails og de andre kodespråkene, uten at vi på dette tidspunktet har klart å sette sammen backend og frontend på en velfungerende og robust måte. Vi har lært og erfart at å fordele oppgavene er en utfordring. Videre ble det diskutert og fastsatt at hver event skal ha et navn/tittel, dato, sted og tid. Dette samsvarer med vår SQL kode som vi har lagt ut på Github. Det ble også gjentatt at event rekkefølge i visning skal være fra nyest til eldst. Videre diskuterte vi generelt om utviklings prosessen og hva vi burde bli bedre. Det aller viktigste er at basisfunksjonene til systemet blir laget som fungerer uten problemer. 46

48 I dag hadde vi et kort møte. Vi har opprettet flere dokumentet på Google Docs, så vi må legge sammen alle til et dokument. Fristen for prosjektet er rett rundt hjørnet (26. Mai), og vi er ferdig med det aller meste. Det som mangler er oppdragsgiverens tilbakemeldinger, meninger og synspunkter om den ferdige løsningen. Det gjenstår nå kun små detaljer til å si at det endelige produktet er helt ferdig og klar til bruk. Vi snakket om å skrive en brukermanual/bruksanvisning til det ferdige produktet. Vi fordelte de siste oppgavene på en effektiv måte, slik at alle visste hva dems hovedoppgave på den aller siste delen av prosjektet er. Vi har også besluttet at vi skal splitte opp oppgavene litt for å effektivisere arbeidet mot slutten. Tam og Gabriel har fokus på kodingen ettersom de har fått mest kompetanse på det, mens Eivind, Philip og Arslan fokuserer på rapporten. Alle jobber fortsatt tett sammen, med mye komunikasjon slik at alle vet hva de ulike gjør til et hvert tidspunkt I dag har vi diskutert og planlagt den siste veien av prosjektet. Hva som er fullført og hva som ennå mangler. Brukergrensesnittet med frontend, og backend er nesten helt fullført, det må kun noen små endringer/justeringer til for at den skal bli ferdig. Rapporten er noenlunde fullført, men mangler småting som konklusjon, eventuelle vedlegg, og alle kildene vi har brukt. Vi har avtalt at neste møte med oppdragsgiver er 25. mai I dag hadde gruppen siste møte før innlevering av prosjektet, vi må huske fristen i morgen (26. mai) klokken 12:00. Oppdragsgiver var også tilstede og så på løsningen vi har laget. Vi viste rapporten og snakket om foreløpig status på den, den er nesten ferdig. Vi gjennomgikk også noe av koden, denne blir ikke 100% ferdig før rapporten skal leveres inn (26. mai klokken 12:00), noe som oppdragsgiver også er fullstendig klar over og vi har avtalt et par møter videre før fremføringen skal holdes slik at vi får på plass flere av de ønskede funksjonene. Tobias kom også med innspill og synspunkter på hva vi burde endre i rapporten før vi leverer den. Videre ble det rapport skriving og koding utover dagen for å gjøre dokumenter og filer innleveringsklare. Vi fikk også en attest fra oppdragsgiveren for samarbeidet. Attesten legges som vedlegg i sluttrapporten. Nå er det kun sortering av dokumenter i rapporten og lage CD en til kildekode som er igjen, før den skal leveres i morgen ( ) før kl 12:00. 47

49 3.4.4 Kilder Frode, E. S. (2011). Universell utforming av IKT systemer: Brukergrensesnitt for alle Using the Command Line Running and Executing rb Files By: Morin, Michael. SQL (The Bastards Book of Ruby) Creating More Using Less Effort with Ruby on Rails (A List Apart The Full) Difference between Front End Development and Back End Development (Difference between Front End Development and Back End Development) between front end and back end develop ment Using the Ruby DBI Module (Using the Ruby DBI Module) dbi.html#toc_17 Operativsystemer (LO114) Send a Simple HTML Using Ruby (Know It Not) a simple html using ruby/ hioa cs/webprosjekt (GitHub) cs/webprosjekt/blob/master/prosjektoppgave/tech_whitelist.md Multiplying two values and printing them to the screen (NASM, Linux) (assembly) two values and printing them to thescreen nasm linux Create a CSS Based Menu with images (Student Web Hosting RSS) based menu with images/ 48

50 Thread: Pop up "login window" as seen on Twitter... (Dynamic Drive Forums RSS) Pop up quot login window quotas seen on Twitter How to Build an Unobtrusive Login System in Rails Tuts+ Code Article (Code Tuts+) to build an unobtrusive login system in rails net 9194 #205 Unobtrusive Javascript ( RailsCasts) unobtrusive javascript User Comments (MySQL) hashing.html The principles of unobtrusive JavaScript ( W3C Wiki) Create CSS popup with Lightbox effect (Create CSS popup with Lightbox effect) css popup with lightbox effect How to implement login popup in html/javascript ( Stack Overflow) to implement login popup in html javascript Javascript Char Codes (Key Codes) Cambia Research (Javascript Char Codes (Key Codes) Cambia Research) char codes key codes opacity (Mozilla Developer Network) US/docs/Web/CSS/opacity Onclick event to remove default value in a text input field (javascript) event to remove default value in a text in put field CSS/HTML: Create a glowing border around an Input Field ( Stack Overflow) html create a glowing border around an inputfield 49

51 How to style input and submit button with CSS? (html) to style input and submit button with css What's is the difference between include and extend in use case diagram? (uml) is the difference between include and exten d in use case diagram Man in the middle attack (Wikipedia) in the middle_attack Cross Site Scripting ( Wikipedia) Cross site request forgery ( Wikipedia) site_request_forgery Difi Direktoratet for forvaltning og IKT (Avslutte og arkivere prosjektdokumentasjonen) og arkivere prosjektdokumentasjone n JavaScript Array sort() Method (JavaScript Array sort() Method) Rails Todo API Part 1 AngularJS Video Tutorial #free (@eggheadio) rails todo api part 1 Rails Todo API Part 2 AngularJS Video Tutorial #pro (@eggheadio) rails todo api part 2 Freelancer One Page Theme (Start Bootstrap) overviews/freelancer/ plataformatec/devise (GitHub) 50

52 3.4.5 Attest fra oppdragsgiver. Vedlagt på et eget dokument ligger utskrift fra attest tilsendt fra oppdragsgiver fra Knowit, Tobias Torrisen 51