Eventhandler. Hovedprosjekt. Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013

Transkript

1 Eventhandler Hovedprosjekt Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Sted/dato: Høgskolen i Oslo og Akershus, Oslo Tittel: Eventhandler Prosjektmedlemmer: Andreas Berglihn Harald Svendsen s s Oppdragsgiver: Accenture, Snarøyveien 30A, 1360 Fornebu, tlf: Kontaktperson: Rune Waage, tlf: , rune.waage@accenture.com

2

3 PROSJEKT NR. Studieprogram: Informasjonsteknologi 19 TILGJENGELIGHET Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo 1.1 HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Eventhandler PROSJEKTDELTAKERE Andreas Berglihn s Harald R. Svendsen s DATO ANTALL SIDER / BILAG 94 INTERN VEILEDER Simen Hasselknippe Siri Kessel OPPDRAGSGIVER Accenture AS KONTAKTPERSON Rune Waage SAMMENDRAG Eventplanlegger er en mobilapplikasjon, for å forenkle, og å gjøre arbeidet med å opprette og vedlikeholde arrangementer lettere og mer oversiktlig. Vektlagte emner: Brukervennlighet Funksjonalitet Lett å videreutvikle 3 STIKKORD PHP Scrum Phonegap 2

4 3

5 Dokumentoversikt Sammendrag Om gruppen Problemstilling Bakgrunn for prosjekt Prosess Produkt...5 Produktrapport...7 Prosessrapport Testrapport Vedlegg

6 Sammendrag 1 Sammendrag Vårt hovedprosjekt 2012/2013 er utført i samarbeid med Accenture AS, og er ment for å gi oss innsikt i hvordan det er å jobbe på større prosjekter i næringslivet, samt gi oss et nettverk vi senere kan benytte oss av. Gjennom vårt prosjekt har vi hatt hjelp av veiledere hos Accenture og på HiOA, og vi vil gjerne takke Jostein Guldal og Jørgen Ringen hos Accenture for at de tok seg tid til å hjelpe oss med oppgaven. Vi vil takke Simen Hasselknippe og Siri Kessel v/hioa for tett oppfølging og hjelp til å komme i mål med oppgaven. Dokumentet som følger, dokumenterer for mobilapplikasjonen, som har blitt utviklet for Accenture AS. Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Applikasjonen skal erstatte et tidligere system. 1.1 Om gruppen Gruppen består av to dataingeniørstudenter, Andreas Berglihn og Harald Svendsen. Vi har tidligere jobbet sammen på diverse prosjekter og gruppearbeid v/hioa og vet av erfaring at vi har et godt samarbeid. 1.2 Problemstilling Gruppen skal lage en iphone-appikasjon integrert mot en SharePoint-portal og en SMS-portal. Ønsket høynivå-funksjonalitet er delt inn i to versjoner som kan leveres separat eller sammenhengende. Deler av funksjonaliteten i versjon 2 er avhengig av funksjonalitet i versjon Bakgrunn for prosjekt Accenture setter per i dag opp jobbsamtaler og arrangementer med å bestille sted/rom, setter opp timeplan, bestiller nødvendige ressurser, informerer HR om arrangement og gir telefonnummer til den som bestiller sted/rom, sender ut sms/mail til student om avtalt tid og sted. Deretter, hvis det er snakk om jobbsamtale, er det avhengig av om rommet er ledig. Hvis ikke, og studenten ikke kan komme på et annet tidspunkt, så tas samtalen per telefon. Alt dette skal vi putte i en og samme applikasjon. Den skal kunne sette opp avtaler, sende ut mail og legge inn avtalte møter i intern kalender. Det vil spare ansatte mye tid og vil gjøre det lettere å finne ledig rom/sted og jobbsamtaleressurs/arrangementansvarlig. 1.4 Prosess Prosessen startet ved at vi sendte inn søknad til Accenture og ble kontaktet da vi mottok en liste over mulige oppgaver, og et mulig samarbeid. Kort tid etter hadde vi møte med Rune Waage hos Accenture for en grundigere gjennomgang av oppgavene. Oppgaven vi valgte var for oss spennende, inneholdt masse ny læring og veldig aktuell. Den krevde bruk av nyere teknologi og appellerte til oss tidlig. Siden sluttproduktet skulle tas i bruk av en kunde måtte vi bruke alle midler vi kunne, noe som reflekterte i høy læringskurve, mye arbeid og masse aktuell kunnskap. 5

7 Sammendrag På grunn av størrelse på prosjektet, måtte vi sette opp en overordnet plan tidlig på når ting skulle gjøres for å komme i mål. Fremdriftsplan og arbeidsplan var to verktøy vi tok i bruk gjennom hele prosessen for å se status på hvor vi skulle være i forhold til hvor vi var. Produktet vi nå sitter igjen med har etter brukertest og selvtesting fått gode tilbakemeldinger, og kan utføre det som var ønsket. Vi har laget en brukervennlig og funksjonell mobilapplikasjon. Gjennom tiden dette halvåret har vi fått verdifull erfaring innen flere nye teknologier og fagområdet vi tidligere ikke kjente til. Fra elementært gruppearbeid til avansert teknologi. Vi ser stor nytte av å ha arbeidet med bacheloroppgaven og takker veiledere for å ha bidratt til en spennende og nyttig opplevelse. 1.5 Produkt Eventhandler, som mobilapplikasjon heter, ble utviklet for å effektivisere og minske arbeidet for ansatte hos Accenture i prosessen ved å arrangere et arrangement. Arrangementer holdes ofte, om det er en enkel jobbsamtale eller om det er en bedriftspresentasjon på en skole. Under prosessen av å opprette et arrangement kreves det å utføre sjekkpunkter. Dette er implementert i løsningen og gir en oversiktlig måte å vedlikeholde et arrangement på. Et arrangement har også en ansvarlig, som er ansatt i Accenture, noe som gjør at arrangementet er eid av noen og styrer det. Andre felt, som økonomisk ansvarlig og skolegrupper er også lagt til for å ha kontroll på hvem som betaler og hvem som skal inviteres. Status på arrangement endres en etter en, noe som gir full styring av hvor hvert arrangement er i planleggingen og at hvert punkt i planleggingen blir utført. Mobilapplikasjonen har kun en brukergruppe, som er administrator. Det er kun ansatte ved Accenture, som skal bruke applikasjonen, men studenter har tilgang til en webside, som er unik for hvert arrangement, der de kan melde seg på gjeldende arrangement. 6

8 Sammendrag Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Produktrapport 7

9 Produktrapport 1 Innholdsfortegnelse 1 Innholdsfortegnelse Produktdokumentasjon Beskrivelse av mobilapplikasjonen Generell beskrivelse Rammekrav Krav til løsning Funksjonskrav Tekniske krav Teknologi CodeIgniter Phonegap Build jquery Mobile Økonomi Sentrale funksjoner Administrator Opprette Endre Slette Invitere Brukergrensesnitt Teknisk brukergrensesnitt Interaksjonsteknikker Touch Ajax (Asynchronous JavaScript and XML) Klientvalidering Popup-valg Skisser Teknisk arkitektur Backend Frontend Verifisering Metode og planlegging Scrum/vannfall

10 Produktrapport 8.2 Parprogrammering Utviklingsmiljø Sikkerhet OAuth 2.0 authorization framework

11 Produktrapport 2 Produktdokumentasjon Produktdokumentasjonen inneholder en beskrivelse av hvordan oppgaven er løst. Inneholder en beskrivelse av applikasjonen/produktet, rammekravene, arkitektur, funksjoner, verifisering og sikkerhet. Produktdokumentasjonen gir en beskrivelse av: Krav til løsning Applikasjonens funksjoner Brukergrensesnitt Teknisk arkitektur Verifisering av applikasjonen Sikkerhet 10

12 Produktrapport 3 Beskrivelse av mobilapplikasjonen I dette kapitelet gis det en grundig beskrivelse av mobilapplikasjonen. Både dens funksjonalitet og overordnede struktur. Hensikten er å gi en innsikt til leseren om hvordan applikasjonen er bygd opp. 3.1 Generell beskrivelse Mobilapplikasjonen er en arrangementbehandler for ansatte hos Accenture, med en tilhørende webside for påmelding av studenter. Applikasjonen skal bidra til bedre flyt og mer oversiktlig håndtering og planlegging av kommende arrangementer hos sluttbruker. Brukeren blir gitt full kontroll til å opprette, vedlikeholde og slette arrangementer, sende ut invitasjoner og se hvem som er påmeldt. I tillegg til å ha en oversiktlig sjekkliste for å sørge for at klargjøringen til arrangementet blir gjennomført. 4 Rammekrav Rammekravene som her beskrives, er krav og avgrensninger, som ble satt før utviklingen startet. 4.1 Krav til løsning Kravene er blitt endret underveis i samarbeid med Accenture. For den endelige kravspesifikasjonen se Vedlegg Funksjonskrav Mobilapplikasjonen skal være tilgjengelig for alle accenture-ansatte. Man skal kunne registrere arrangement på gitt dato. Skal ta imot påmeldinger fra studenter via webgrensesnitt. Skal sende kvittering til studenter via mail, med bekreftelse om tid/sted ELLER informasjon om at arrangementet er fullbooket og at de vil kontaktes via telefon. Visning av enkelt arrangement med påmeldte studenter. Skal kunne legge til sjekklistepunkter i arrangement Skal kunne tildele en accentureansatt til et arrangement, som ansvarlig. Skal ha mulighet for å flytte eller stokke på avtaler i arrangementet med automatisk e- postbekreftelse til involverte studenter Tekniske krav Utvikles i HTML5, CSS og JavaScript(jQuery, Ajax, jquery Mobile) Kompileres til smarttelefonplattformer med PhoneGap Build. Bruker Netbeans 7.2 til å skrive koden. Backend skal skrives i rammeverket CodeIgniter(PHP) og følge REST. JSON skal brukes til å overføre data til og fra mobil. OAuth skal brukes til sikker sending av data. MySQL skal brukes til databasespørringer. Design skal følge retningslinjene til forskjellige OS 11

13 Produktrapport Teknologi Her følger en kort beskrivelse og bruksområde for noen av de mest sentrale teknologiene brukt i systemet CodeIgniter CodeIgniter er et open source MVC rammeverk for oppsett av webapplikasjoner og er skrevet i PHP. Rammeverket ble benyttet for å skrive backend og lage API et. Mobilapplikasjonen prater med API, som sender forespørsler frem og tilbake til modeller for å hente ut ønsket data Phonegap Build Phonegap Build er en hybrid skytjeneste for å kompilere HTML5-, CSS- og JavaScript-basert kode til flere forskjellige plattformer uten å måtte installere hver enkelt kompilator på lokal PC. Filene kobles enten direkte mot et gitrepository eller lastes opp som en zip-fil på nettsiden. Applikasjonen kompileres og kan enkelt hentes ned ved å skanne en QR-kode eller laste ned filen manuelt og installere. Mobilapplikasjonen det i denne rapporten er snakk om, ble kompilert i Phonegap Build v jquery Mobile jquery Mobile er et touch-optimalisert rammeverk for smarttelefoner og nettbrett. Et HTML5-basert brukergrensesnittsystem for alle populære mobilplattformer. Har en enkel måte å bruke themes for å style utseende. I applikasjonen er det importert jquery Mobile og tilhørende CSS fil på klientsiden. Applikasjonen bruker themebasert utseende, med modifikasjoner i både theme og CSS Økonomi I utgangspunktet er dette en nullbudsjettsoppgave, men Accenture stiller med nødvendig hardware og software. Dette inkluderer to bærbare maskiner, samt standard programvare på dem som Microsoft Office mm. Accenture har også stilt med lisens til Apple iphone, for å kunne kompilere kode til angitt mobiltelefon. 5 Sentrale funksjoner Applikasjonen har kun en type bruker og det er Accenture-ansatte. Det er da et admin brukersnitt de bruker. Studenter, som skal melde seg på, bruker en tilhørende påmeldingsside på web, som er unik for hvert arrangement. Slik er dagens situasjon og skal ha tilnærmet samme funksjonalitet med den nye løsningen. (Bilde: 5.1) 12

14 Produktrapport Bilde: Administrator En accenture-ansatt, videre referert til som administrator, har full kontroll over arrangementer. Opprette, endre, slette og invitere til arrangementer Opprette Når et arrangement blir opprettet må en rekke felter fylles ut, som navn, ansvarlig, dato, sted osv. Etter data er fylt ut og sendt til lagring, vil en sjekkliste for punkter som må utføres bli opprettet og blir tilgjengelig fra arrangementet. Denne listen kan oppdateres ved å ferdigstille, oppdatere, legge til og slette sjekkpunkt. Hvert nytt arrangement vil også bli tildelt en startstatus, som NY. Denne 13

15 Produktrapport statusen endres i arrangementets planlegging, men kun en status av gangen for å ha kontroll over at alle stadier blir utført Endre Hvert arrangement kan endres til en hver tid. Gjøres enkelt ved å oppdatere felt for felt. Her endres også status for arrangement referert til i Slette Om et arrangement ikke skal finne sted lenger, kan det slettes, og en advarsel gis før dette gjennomføres Invitere Et arrangement krever påmeldte og det er stort sett studenter som skal melde seg på. Som nevnt i innledningen til kapitelet eksisterer det en unik webside til hvert arrangement. Hvert arrangement har en egen URL en lagret sammen med resten av dataene. Denne URL en brukes for å bestemme hvilket arrangement studenten melder seg på. Det finnes en egen knapp for å invitere til hvert arrangement, og det bygges en tekst basert på data fra arrangementet, som settes i meldingsfeltet, og lastes over til brukerens epostklient. Mailen sendes som regel til en ansvarlig på en skole, som videresender internt til grupper av studenter. Studenten følger URLen og legger inn sin informasjon og kommer dermed opp i listen over påmeldte studenter i mobilapplikasjonen. 5.2 Brukergrensesnitt På en mobilapplikasjon er brukergrensesnittet et av de mer viktige punktene, da dette har stor betydning for brukeropplevelsen. I dag brukes stort sett touch smarttelefoner, og byr på utfordringer som at folk skal fysisk klikke på elementer plassert på en relativt liten skjerm. Derfor er utseende og oppbygningen av brukergrensesnittet viktig Teknisk brukergrensesnitt For å lage brukergrensesnittet til applikasjonen ble det dratt inn en del tilleggsfunksjonalitet for at applikasjonen skulle fungere som ønsket. Der i blant var det biblioteker, teknikker og utseendefiler, som bidro til penere utseende og kode, høyere kodefunksjonalitet og bedre touchstøtte. jquery Mobile (JavaScript og CSS) jquery (JavaScript) Mustache templates (HTML) Ajax (Asynchronous JavaScript and XML) JSON (JavaScript Object Notation) Disse teknologiene er forklart i kapittel 4.4 i prosessdokumentasjonen. 14

16 Produktrapport Interaksjonsteknikker Touch Siden dette er en mobilapplikasjon, så har vi måtte lage og utforme alt i forhold til det. Koden er skrevet som Markup Language, men kompileres i Phonegap Build til de forskjellige plattformene vi ønsker, og det er her koden blir touch- og mobilvennlig. Bilde: Ajax (Asynchronous JavaScript and XML) Gir oss muligheten til å laste inn data fra server uten å måtte laste siden brukeren befinner seg på. Dette gir en bedre brukeropplevelse og gjør applikasjonen mer responsiv Klientvalidering Når det skal settes inn nytt arrangement i applikasjonen må gitte felter være fylt ut. Dette kontrolleres med en klientvalidering. Nedtrekksmenyer er på en måte allerede validert, med at data hentes fra en forhåndsutfylt tabell og puttes inn som valg i menyene. Bilde: Popup-valg Mobiscroll er en egen datovelger importert i vårt system. Gir en elegant og oversiktelig måte å sette dato og tid vha. touch. Nedtrekksmenyer kommer frem når du klikker på menyelementer som du ser på bilde 5.3. Gir en klar og enkel måte å velge menyelement på. Kommer i ettvalgs- og flervalgsmenyer. Lokal epostklient popper opp når du klikker send i vinduet vist under. Dette er et valg du har til hvert arrangement for å invitere studenter. 15

17 Produktrapport Bilde: Skisser Før arbeidet startet med å lage applikasjonen ble det laget noen skisser i Balsamiq Mockups (se kapitel 4.4 i prosessrapport). Bilde 5.5 er av startsiden i applikasjonen. To forskjellige varianter, hvor kun den venstre versjonen ble implementert i vårt system. Skissen til venstre er en liste over arrangementer i systemet. 16

18 Produktrapport Bilde: 5.5 Bilde 5.6 er en skisse av tenkt funksjonalitet når det legges til et nytt arrangement (venstre), og en tilhørende sjekkliste (høyre). 17

19 Produktrapport Bilde: Teknisk arkitektur Eventhandler er bygget opp med en serviceorientert arkitektur (SOA) som skissert i bilde 6.1. Frontend (mobilapplikasjonen) og påmeldingssiden kommuniserer med backend via et API, som tar seg av alle spørringer mot databasen. 18

20 Produktrapport Bilde: 6.1 Videre følger en beskrivelse av frontend og backend som viser oppbygging og kodeeksempler. 6.1 Backend All kommunikasjon i systemet går gjennom API et i backend. Backend er skrevet i PHP og benytter seg av rammeverket CodeIgniter som er basert på model-view-controller (MVC). Dette designmønsteret brukes for å skille mellom data (model) og brukergrensesnitt (view) mens et mellomliggende komponent (controller) tar seg av kommunikasjonen mellom view og model. Viewdelen er ikke tatt i bruk ettersom brukergrensesnittet ligger i frontend. Bilde:

21 Produktrapport Bilde: 6.3 Kontrolleren api.php inneholder alle tilgjengelige ressurser og er implementert på en RESTful måte. Dvs. at kontrolleren kan inneholde ressurser med samme navn men som bruker forskjellige HTTPverb eller request methods. HTTP-verbene som er tatt i bruk er: GET hente ut informasjon fra databasen. POST lager en ny oppføring i databasen. PUT oppdaterer en oppføring i databasen. DELETE sletter en oppføring fra databasen. Følgende kodeeksempel er ressursen for å liste ut alle arrangementer. 20

22 Produktrapport //Gets all events function arrangementer_get() { $this->load->model("arrangement_model"); $data = $this->arrangement_model->hentalle(); } if($data) { $this->response($data, 200); } else { $this->response(null, 404); } Bilde: 6.4 Totalt inneholder API et disse ressursene: Ressurs Metode Beskrivelse arrangementer Get Henter alle arrangementer. arrangement Get Henter arrangement med gitt ID. arrangement Post Setter inn arrangement arrangement Put Endrer arrangement med gitt ID arrangement Delete Sletter arrangement med gitt ID arrangementurl Get Henter URL til påmeldingssiden for studenter poststed Get Henter poststed med gitt postnummer sjekkpunkter Get Henter alle sjekkpunkter til et gitt arrangement sjekkpunkt Get Henter sjekkpunkt med gitt ID sjekkpunkt Post Setter inn sjekkpunkt sjekkpunkt Put Endrer sjekkpunkt sjekkpunkt Delete Sletter sjekkpunkt med gitt ID items Get Henter alle predefinerte sjekkpunkter aktivitetstyper Get Henter alle aktivitetstyper accusers Get Henter alleaccenture-brukere statuser Get Henter alle statuser skoler Get Henter alle skoler skolegrupper Get Henter alle skolegrupper skolegruppe Get Henter skolegruppe knyttet til ID på arrangement skolegrupper Post Setter inn skolegruppe student Get Henter alle studenter med gitt arrangement ID student Post Setter inn student Modellene har navn etter hvilken tabell i databasen de aksesserer og inneholder metoder for å hente, sette inn, oppdatere og slette oppføringer. Her er et eksempel på en hent-metode i modellen sjekkpunkt_model.php: 21

23 Produktrapport //Returns a spesific Sjekkpunkt function hentsjekkpunkt($idsjekkpunkt) { $sql = "SELECT * FROM Sjekkpunkt WHERE idsjekkpunkt = $idsjekkpunkt"; } $query = $this->db->query($sql); if($query->num_rows() > 0) { return $query->result(); } Bilde Frontend Frontend er selve mobilapplikasjonen som brukerne interagerer med og som installeres på telefonen. Frontend kommuniserer med backend via ressusene som ligger i API. Frontend er skrevet i HTML, JavaScript og CSS og benytter seg av rammeverket jquery Mobile. Rammeverket bruker en «singlepage» modell, dvs. at ved kjøring, så lastes sidene inn og ut av et enkelt HTMLdokument. Pga. dette trenger man kun å laste inn biblioteksfiler og scripts i index.html. Alle sidene i applikasjonen ligger i hver sin HTML fil med hver sin tilhørende JavaScriptfil som håndterer data. Bilde: 6.6 For å lage en side i jquery Mobile definerer man en <div> og legger til data-role= page : 22

24 Produktrapport <html> <head> </head> <body> <div id="eventdetailspage" data-role="page"> <...> </div> </body> </html> Bilde: 6.7 Så lastes siden inn i dokumentet med følgende JavaScript-kode: $(document).on('pageshow', '#eventdetailspage', function(event) { id = geturlvars()["id"]; displayevent(id); }); Bilde: 6.8 Ajax brukes for å gjøre kall mot backend. Disse metodene ligger i getdata.js Eksempel på et Ajax-kall: this.updatearrangement = function(data, callback) { $.ajax({ type: "PUT", contenttype: "application/json", datatype: "json", url: (serviceurl + "/api/arrangement/format/json"), data: JSON.stringify(data), cache: false }).done(function(returningdata){ calllater(callback, returningdata); } Bilde: Verifisering Under hele prosessen er det testet og optimalisert kode til beste evne. Programkode og samspillet mellom applikasjon og eksterne enheter er testet. Når det gjelder validering er dette et punkt som havnet lenger nede på prioriteringslisten, og derfor er det kun validering på klientside i denne versjonen (se kap ). For mer info om testene som er utført, bes leseren henvende seg til vår detaljerte testrapport. 8 Metode og planlegging For å komme i mål og ha en god arbeidsflyt er det tatt i bruk ulike metoder, teknikker og verktøy. 8.1 Scrum/vannfall Applikasjonen er utviklet vha. verdier fra de to utviklingsmodellene Scrum og Vannfall. 23

25 Produktrapport Bilde: 8.1 (venstre: Vannfall, Høyre: Scrum) Backlog, sprints og daglige møter fra scrum er brukt. Og prinsippet med å sette opp frister og milepæler fra vannfallsmetoden. Scrum er en iteraktiv og inkrementell smidig utviklingsmodell. I Scrum blir det ikke definert hvordan noe skal gjøres, men heller hva som skal gjøres. Vannfall er en streng utviklingsmodell, som vist på venstre figur 8.1, så går det ingen piler tilbake. Det er kun brukt muligheten for å sette frister med vannfallsmetoden, for å kunne sette opp en plan fra start til slutt. 8.2 Parprogrammering Er en enkel metode hvor den ene sitter og koder, mens den andre sitter og følger med. Denne metoden er mye brukt når det ikke er så mange gruppemedlemmer. En del av koden er skrevet av gruppemedlemmene i plenum. 8.3 Utviklingsmiljø Da oppgaven vår var å lage en mobilapplikasjon, som skulle kompileres og distribueres, så var det lett og logisk å skrive klientkoden lokalt, med ekstern backup. Backend ble også i starten skrevet lokalt, da ingen andre trengte tilgang før brukertestingen skulle starte. Mot slutten ble backend lastet opp live hos «itforalle» (firmaet til en klassekamerat), for å kunne tillate brukertesting live. Databasen ble til fordel lagret eksternt hos «itforalle» under hele prosessen for å slippe å måtte laste opp og ned databasefiler lokalt. 9 Sikkerhet Sikker sending av data er et punkt som i samarbeid med veilederne er valgt å nedprioritere da funksjonalitet i applikasjonen kom foran. Derfor ligger det ved en beskrivelse av en mulig løsning, som kan implementeres på sikt. 24

26 Produktrapport 9.1 OAuth 2.0 authorization framework Det var i løsningen meningen å bruke OAuth 2.0 authorization framework. OAuth gir muligheten til å begrense tredjepartsapplikasjoner sin tilgang til en http-tjeneste. OAuth er til fordel gratisvare. Nettsiden sier: OAuth er en åpen protokoll for å tillate sikker autorisasjon i en enkel og standard metode for web, mobil og skrivebordsapplikasjoner. OAuth støtter de fleste store språk, og da også CodeIgniter, som er skrevet i PHP. Her finnes en liste over støttede språk OAuth er en anerkjent sikkerhetsprotokoll og brukes i dag av store aktører som Facebook og Twitter. 25

27 Sammendrag Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Prosessrapport 26

28 Prosessrapport 1 Innholdsfortegnelse 1 Innholdsfortegnelse Prosessdokumentasjon Gruppen Om oppdragsgiver Bakgrunn for oppgaven Dagens løsning Mål Oppgavens mål Egne mål Mobile plattformer Planlegging og metode Arbeidsforhold Arbeidsfordeling Planleggingsverktøy og metodikk Dokumentasjon Styringsdokumenter Versjonskontroll og backup Prosjekthjemmeside Utviklingsmodell/metode Teknologier og verktøy Netbeans Ajax JavaScript HTML/CSS jquery/jquery Mobile Dropbox Google Docs CodeIgniter JSON (JavaScript Object Notation) MySQL REST Phonegap Build Teambox

29 Prosessrapport SoapUI (OAuth) Balsamiq Mockups Faser Gjentatte faser Tilegning av kunnskap Risikohåndtering Endring og revurdering Utredningsfasen Fremgangsmåte Forarbeid Bytte rammeverk Jira og Teambox Utviklingsfasen Fremgangsmåte Design mobilapplikasjon Mockups Planlegge design Design webside Problemer og løsninger Liveserver for testing Navngivning og kommentarer iphone lisens Testing selenium Handlebars og JQuery Mobile Dokumentasjonsfasen Avsluttende del Det ferdige produkt Hva kun vært annerledes Phonegap Testing Navngivning og kommentarer Konklusjon

30 Prosessrapport 2 Prosessdokumentasjon Prosessdokumentasjonen beskriver prosessen rundt utviklingen av applikasjonen. Dette inkluderer begrunnelse av beslutninger, vurderinger, hvordan vi har jobbet, dokumentasjon og teknologier. 2.1 Gruppen Gruppen består av to dataingeniørstudenter, Andreas Berglihn og Harald Svendsen. Vi har tidligere jobbet sammen på diverse prosjekter og gruppearbeid v/hioa og vet av erfaring at vi har et godt samarbeid. 2.2 Om oppdragsgiver Slik presenterer Accenture seg selv. «Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Vi leverer nyskapende løsninger og samarbeider med kundene, slik at de kan realisere sine visjoner og skape verdi for seg selv. Med vår omfattende bransjeekspertise, våre globale ressurser og vår erfaring innenfor konsulentvirksomhet og driftsutsetting kan vi mobilisere de riktige menneskene og den nødvendige kompetansen for å hjelpe våre kunder til å bli virksomheter med høy prestasjonsevne. Med mer enn ansatte i 49 land hadde Accenture en omsetning på 23,40 milliarder dollar i regnskapsåret som ble avsluttet 31. august 2007.» Accenture s hjemmeside: eller Bakgrunn for oppgaven Accenture setter per i dag opp jobbsamtaler og arrangementer med å bestille sted/rom, setter opp timeplan, bestiller nødvendige ressurser, informerer HR om arrangement og gir telefonnummer til den som bestiller sted/rom, sender ut sms/mail til student om avtalt tid og sted. Deretter, hvis det er snakk om jobbsamtale, er det avhengig av om rommet er ledig. Hvis ikke, og studenten ikke kan komme på et annet tidspunkt, så tas samtalen per telefon. 29

31 Prosessrapport Alt dette skal vi putte i en og samme applikasjon. Den skal kunne sette opp avtaler, sende ut mail og legge inn avtalte møter i intern kalender. Det vil spare ansatte mye tid og vil gjøre det lettere å finne ledig rom/sted og jobbsamtaleressurs/arrangementansvarlig. 2.4 Dagens løsning Accenture tar i dag i mot påmeldinger fra studenter for jobbsamtaler og andre arrangementer på stands på karrieredager, eller at studenten sender en SMS. Dette innebærer at Accentures ansatte må bruke mye tid og ressurser på å sette opp møter. Dagens prosess: Bilde: 2,1 30

32 Prosessrapport 2.5 Mål Oppgavens mål Målet med prosjektet er å utvikle et system som skal gjøre det enklere for Accenture å sette opp jobbsamtaler med studenter og for å la studenter melde seg på ulike arrangementer som Accenture måtte holde. Dagens rutiner krever en del manuelle steg og et hovedmål er at det nye systemet skal være tidsbesparende for Accentures konsulenter samt sørge for bedre kvalitet og brukeropplevelse for studentene de møter. Løsningen skal integreres mot en SharePoint-portal hos Accenture. Ellers har gruppen stått fritt til å velge utviklingsverktøy og hvordan løsningen implementeres Egne mål Våre egne mål er å utvikle en mobilapplikasjon vi selv og sluttkunde er fornøyd med. Den skal være enkel i bruk med riktig funksjonalitet og responstid. Vi skal gjøre en jobb for å gjøre jobben lettere for sluttbruker. Vi skal lære hvordan det er å jobbe i et større prosjekt, som gruppe, over en lengre periode enn vi har gjort tidligere, og vi skal sette opp planer for å nå mål og frister i tide. Vi skal lære nytten av styringsdokumenter gjennom prosjektets løp. Mye ny læring om teknologier og fagområder vi tidligere ikke kjente til. 3 Mobile plattformer Mobilapplikasjoner er et tema som har eksplodert de siste årene med utallige smarttelefonvarianter. Dette bringer med seg et stort marked og muligheter for å utvikle applikasjoner, men også utfordringer. På en mobiltelefonen er skjermen mindre og ytelsen lavere enn på en PC, og det gir begrensninger. Brukeropplevelsen på en applikasjon er veldig viktig, og da spesielt med tanke på utseende og respons. Ser applikasjonen uproff ut, vil den ofte også være vanskelig å navigere seg frem i. Krever applikasjonen mye venting, vil den fort bli byttet ut. Med brukeropplevelse i tankene må man gjøre diverse valg for sin utvikling av mobilapplikasjoner. Det finnes flere måter å gjøre det på, men vi skiller her på de to mest brukte typene; hybrid og native løsninger. En hybrid løsning, som Phonegap Build (som vi har valgt å gå for), har muligheten til å kompilere kode til flere plattformer med kun ett sett med kode skrevet i HTML5, CSS og JavaScript. Ikke alltid like velfungerende på alle plattformer, spesielt om applikasjonen krever mye prosessorkraft. 31

33 Prosessrapport En native løsning, som X Code, er kun laget til en plattform. Denne løsningen er som regel bedre egnet plattformen den er laget til, i forhold til en hybrid løsning. Er vanskelig å tar lang tid å lage native til alle plattformer, en etter en. 4 Planlegging og metode 4.1 Arbeidsforhold Vi har tidligere i vårt 3 årige bachelorstudie jobbet sammen på vellykkede gruppeoppgaver, og da falt det naturlig å samarbeide på bacheloroppgaven. Vi kjenner hverandre godt, har effektive og fokuserte arbeidsøkter sammen. Vi bestemte oss tidlig for at vi ønsket å være 2 på gruppa. Lettere å samarbeide og mer kunnskap å lære innen alle feltene. Så lenge oppgaven kunne tilpasses 2 stk, så var det slik det ble. Vi har stort sett benyttet oss av grupperommene på Høgskolen i Oslo v/holbergs plass, hvor vi sitter sammen og jobber. Dette gir oss fordelen til å kunne ta opp diskusjoner på stedet og løse problemer mer effektivt. Av erfaring er dette den beste måten for oss å jobbe. Vi har også lokaler hos Accenture Fornebu, men pga. av reiseavstand og vår egen hjemmeadresse valgte vi bort å reise ut dit. 4.2 Arbeidsfordeling Arbeidet er fordelt, så godt det lar seg gjøre, 50% hver. Vi har forsøkt at begge er innom alle felter, både på api-, klient- og dokumentasjonssiden. Dette gjør at vi begge forstår sammenhengen bedre, og kan hjelpe hverandre på et høyere nivå. Vi har begge identiske PCer lånt av Accenture, og har installert samme programvare på dem, som bidrar til at begge enkelt kan ta tak hvor det skulle trenges. 4.3 Planleggingsverktøy og metodikk Dokumentasjon Vi har ført dagbok etter hver arbeidsøkt, noe som gir oss en detaljert oversikt over hva vi har gjort. Dette er til stor hjelp når vi skal skrive sluttrapport Styringsdokumenter Statusrapport: En rapport som ble levert i fjor, for å vise at vi var i gang med å finne oppgave. Prosjektskisse: Om oppdragsgiver og en kort beskrivelse av oppgaven. Vedlegg 6 Forprosjektrapport: En rapport, som viser hva vi tenker å gjøre og om dagens situasjon. Vedlegg 5 32

34 Prosessrapport Prosjektdagbok: Blir oppdatert etter hver endt arbeidsøkt. Korte stikkord og forklaringer på hva vi gjorde hver dag. Risikoplan: Er et viktig punkt, som viser oversikt over risikotiltak om det skulle oppstå problemer. Inneholder en tabell med oversikt over sannsynligheten for at noe skal inntreffe. Vedlegg 7 Arbeidsplan og fremdriftsplan: Oversikt over hva som skal gjøres når. Skjema over tidsfrister, sprinter og mål. Vedlegg 3 og 4 Kravspesifikasjon: Denne har blitt endret en del underveis, men er til for å sette kravene på plass. Endringer som har skjedd, gjør at oppgaven ble større, men også mer funksjonibel og lettere å bruke. Blant annet så endret vi fra at studenten skulle sende påmelding på sms, til at studenten melder seg på via web. Viktig at det finnes i hvert fall et førsteutkast ved prosjektets start. Vedlegg Versjonskontroll og backup All dokumentasjon, utenom selve sluttrapporten, som ble skrevet i Microsoft Word (pga. problemer med formateringer) er skrevet i Google docs. Dette er en tjeneste vi er godt kjent med og tillater oss å skrive i samme dokument samtidig. Sluttrapporten ble lagret i Dropbox, og Google Docs lagres online. Til koding, brukte vi Netbeans mot git med lokasjon hos Accenture s innersource. Dermed hadde vi også en backup der, pluss en kopi på hver vår laptop Prosjekthjemmeside Hjemmesiden var et krav fra skolen hvor vi skulle laste opp dokumenter, som skulle vurderes av dem. Den er laget i ren HTML/CSS. Bilde: 4, Utviklingsmodell/metode Vi har tatt utgangspunktet i å bruke Scrum med innflytelse fra vannfallsmetoden, men siden vi kun er to stk, så bruker vi en forenklet og egendefinert versjon. Vi har benyttet oss av en online tjeneste som heter Teambox, hvor vi la opp sprinter og arbeidsoppgaver. Der kunne vi legge til nye oppgaver, kommentere og ferdigstille oppgaver. Denne tjenesten ble opprettet og vedlikeholdt i samarbeid med veilederne hos Accenture. 33

35 Prosessrapport Det å sette opp sprinter har gitt oss en stødig og effektiv fremgang i prosjektet og vi har klart å fullføre hver sprint til gitt frist. Vannfallsmetoden reflekteres i at vi satt opp frister i en arbeidsplan. 4.4 Teknologier og verktøy Her tar vi for oss alle teknologier og verktøy vi har brukt for å ferdigstille produktet Netbeans Utviklerverktøy for en rekke av språk. Gjenkjenner språk og gjør det enkelt å redigere mange filer samtidig i forskjellige språk. All kode er skrevet i Netbeans, både til backend og klient. Netbeans er et program vi er blitt godt kjent med gjennom tidligere fag på HiOA, og er et velkjent og velfungerende program til å skrive kode Ajax Øker sidens interaktivitet og vi slipper å måtte laste siden på nytt hver gang data skal hentes. Brukes i sammenheng med JavaScript og jquery for å lage kort og oversiktlig kode. Ajax var ukjent for oss i starten, men lærte fort at det gav oss akkurat det vi trengte for å gi JavaScriptene våre den funksjonalitet vi trengte JavaScript Brukes til å tilføre dynamiske elementer til HTML koden og gir siden funksjonalitet. Koden legges i separate JavaScriptfiler, og importeres der dem trengs. Alle våre JavaScript er importert i index.html. Det er tryggere å legge dem i separate filer, da dette gjør det vanskeligere for codeinjection og tukling av verdier HTML/CSS HTML er markup språk for å plassere elementer der du vil ha dem og er bygget av <tags>. IDer og klasser er brukt, slik at vi i CSS filene (filer for utseende) kan utforme elementene med font, farger, rammer osv. Vi har opprettet en egen standard.css fil i tillegg til at vi har importert CSS-filer for jquery Mobile og en datovelger, og brukt dem sine IDer for å få det til å se ut slik vi vil jquery/jquery Mobile Hjelpebiblioteker for å gjøre kodingen i JavaScript enklere. Her har vi importert bibliotekfiler for jquery og jquery Mobile, samt som nevnt en egen CSS-fil for jquery Mobile. Brukes hyppig for å hente og referere til elementer i HTML-koden, og hente eller sette data i dem. jquery Mobile er direkte rettet til mobilenheter og utforming og funksjonalitet av disse. jquery Mobile har spesielt vært til stor hjelp på designbiten Dropbox Dropbox er en gratis (inntil en gitt grense GB) onlinetjeneste for lagring av data, og brukes av oss til å lagre diagrammer, dokumenter, bilder osv, som flere parter skal ha tilgang til. Vi har god kjennskap til tjenesten og brukes hyppig av oss begge til daglig. 34

36 Prosessrapport Google Docs Google Docs er en gratis onlinetjeneste for å opprette, dele og redigere de vanligste dokumenttyper, som regneark, tekst, presentasjoner osv. Har god erfaring med Google Docs, og kan redigere i samme dokument samtidig uten å få versjonskrasj CodeIgniter CodeIgniter er rammeverket vi bruker til API (Backend) og er skrevet i PHP. Har en mappestruktur og en bestemt måte å sette opp metoder på. Forespørsler kommer inn til en controller, som sender data videre til modeller, som igjen henter ut, eller setter inn data fra/til en server, som i vårt tilfelle er en MySQL database. CodeIgniter har også et sett med filer for konfigurasjon av det en måtte trenge, som hvor databasen er, samt legge inn påloggingsinfo, ruter til forskjellige filer osv. Vi falt for CodeIgniter etter godt tips fra medstudent og testing selv JSON (JavaScript Object Notation) Brukes til å sende data mellom server og klient. Det bygges opp et JSON-streng på klient eller server, med relevant data, for å kunne sende dette som tekst over til klient eller server, slik at data kan hentes ut på riktig måte. Inneholder et fast oppsett av klammeparenteser, kolon og komma. JSON passer oss veldig bra, siden vi ikke har de store mengde data for sending og mottak, og da trenger en lett måte å gjøre transaksjoner på MySQL Brukes til lagring av data til database. MySQL er verdens mest populære open source database, og er den vi er mest kjent med. Har et sett med kodeord for spørringer og har en strukturert måte å hente eller å putte inn data. Tabellene er laget og redigert i phpmyadmin, som er et hjelpeverktøy, som ofte er installert i sammenheng med en database, og gir deg grafisk kontroll over dataene som måtte være der REST Et sett med metodenavngivning i rammeverket. Navnpåmetode_put hvor put brukes videre i Ajax på klient og api (controller) på server, og forteller at her skal det oppdateres noe i databasen. Get og Post er også mye brukt, hvor Get er å hente noe vha. en SELECT-spørring, mens Post er å sette inn en ny rad vha. en INSERT Phonegap Build Brukes til å kompilere kode skrevet i HTML, CSS og JavaScript til flere plattformer. En online tjeneste, hvor du laster opp kode enten via et git-repository eller en zippet fil av koden. Deretter kompilerer den til alle (inkl. iphone om du har lisens) plattformer. Dette er noe som er svært tungt å få til på en enkelt PC, da du trenger å installere kompileringskode for hver enkelt plattform. Derfor valgte vi å bruke en skytjeneste som allerede taklet alle plattformer Teambox En online tjeneste for prosjektstyring hvor vi kan opprette backlog og tilhørende sprints. Er et enkelt verktøy for å holde kontroll på prioriterte emner, samt ferdigstille dem underveis og sette tidsfrister. 35

37 Prosessrapport SoapUI Brukes til å teste at ressursene til et API fungerer, og at de fortsatt fungerer etter endret kode. Tester direkte til APIet og dets metoder. Setter opp test til ønskede metoder og deretter kjøres testen på samtlige. Dette gir en oversikt og tidlig oppdagelse av feil som oppstår etter endret kode. Må installeres og kjøres lokalt på maskinen/server (OAuth) Sikker sending av data. Brukes av store aktører på den sosiale mediafronten. OAuth er ikke implementert, men plan for å gjøre det medfølger rapporten Balsamiq Mockups Brukes til å lage mockups (tenkte skjermbilder) i planleggingen. Vi syns det var enkelt å bruke med nødvendige funksjoner lett tilgjengelig. 5 Faser 5.1 Gjentatte faser Vi kalte dette punktet for gjentatte faser, da det er faser, som skjer flere ganger i prosjektets løp. Her er det da spesielt tilegning av kunnskap og risikohåndtering som går igjen Tilegning av kunnskap I starten av prosjektet var det mange nye teknologier og fagområder vi måtte ta tak i, å samle informasjon om. Det eneste vi hadde vært borti tidligere var HTML og CSS, som vi begge har hatt ett fag på i første semester. Utover dette var det nye språk, rammeverk, biblioteker og regler vi måtte samle informasjon om før vi kunne gå i gang for fullt. Ut i fra at vi valgte å gå for Phonegap Build (ref kap ) og CodeIgniter (ref kap 2.4.8) falt det inn nye teknologier vi måtte sette oss inn i og lære. Blant annet jquery, jquery Mobile, Ajax, REST, JavaScript og JSON. Ref kap Risikohåndtering Vi har klart oss uten de store forsinkelseshendelsene, men litt fravær i forbindelse med reise og ferie pluss tap av lisens har det vært. iphone-lisensen vi måtte ha for å få testet applikasjonen live på en telefon fikk vi i utgangspunktet veldig sent, og vi var godt i gang med Phonegap Build. Kort tid etter vi fikk den, mistet vi viktig informasjon, som gjorde den ukjørbar. Dermed tok det noen dager før vi da fikk opp en ny og kunne legge inn ny versjon på telefonene. Dette medførte frustrasjon og tapt arbeidstid, men i ettertid ser vi at det ikke var kritisk, men heller et kjedelig uhell som kostet noen timer med arbeid. 36

38 Prosessrapport Endring og revurdering Gjennom prosjektet har vi støtt borti store og små endringer vi må og burde gjøre. Versjon en og to av kravene fra arbeidsgiver er veldig forskjellige, og det skyldes et møte vi hadde med veileder hvor vi kom frem til en bedre og mer effektive måter å gjøre ting på, samt en forstørring av oppgaven. Denne endringen kom tidlig pga. kjapp oppstart og hyppige møter i starten, noe som sparte oss for ekstraarbeid siden vi ikke var kommet til utviklingsfasen enda. En annen stor endring var da vi gikk fra å bare bruke JavaScript og jquery til å i bruk rammeverket jquery Mobile (ref kap 2.4.5), etter startet arbeid. Denne endringen førte med seg en del endring i kode og ny læring, men vi var fortsatt tidlig i prosessen, så det var ikke veldig tidskonsumerende å endre. Det viste seg i ettertid at valget førte med seg positive sider og negative sider. Negative siden var at jquery Mobile og Phonegap sammen krever mer kraft fra enheten det kjører på. Noe som medfører treghet. Dette oppdaget vi ikke før vi fikk iphone-lisensen fra Accenture et godt stykke inn i prosjektperioden, som medførte at vi ikke hadde tid til å gå tilbake å lage ny kode til en annen teknologi. Den positive siden var derimot veldig mye tid spart, og i stor grad penere kode. Bedre funksjonalitet og penere utseende. 5.2 Utredningsfasen Fremgangsmåte Hvorfor gikk vi for løsningen vi har i dag? Forarbeid Vi brukte tid surfet på nett, pratet med veileder og hørt på anbefalinger fra kjente for å komme frem til løsningene vi gjorde. Phonegap Build falt fort på plass da det kun krevde ett sett med kode, at vi kunne bruke programmeringsspråk som var kjente for oss, og masse god omtale på nett, lett å finne informasjon og veilederne hos Accenture gikk også god for løsningen. Vi har i tillegg sett at tidligere bachelorgrupper, som har vært i lignende situasjon som oss, har gått for samme løsning. Bilde: 5,1 37

39 Prosessrapport Bytte rammeverk Vi fikk også i starten beskjed om å bruke «Spring», som er et Javabasert rammeverk. Noe vi etter mye prøving fikk lov å gå bort i fra, da dette var for stort og tungt å bruke til vårt arbeid. Vi gikk, etter anbefalinger og artikler lest, for «CodeIgniter» isteden, som er et PHP-basert rammeverk. Vi oppfattet kvikt hvordan det fungerte, og fikk etter kort tid satt opp et testmiljø for dette. CodeIgniter koblet vi opp mot en MySQL database, som falt helt naturlig å bruke, siden vi har brukt det før og er per i dag det mest utbredte databasesystemet. Bilde: 5,2 Hovedgrunner til bytte: CodeIgniter var lettere tilgjengelig i form av informasjon og veiledning på Internet. CodeIgniter er lettere satt sammen, og da også lettere å forstå hvordan mappestrukturen er bygget opp. CodeIgniter var lettere å forstå. CodeIgniter har enkel integrering mot NetBeans (ref kap 2.4.1) I alt brukte vi noen dager på å lese og utforske flere varianter av «samme» løsning, og mener vi gjorde gode valg og justeringer fra start og underveis Jira og Teambox 5.3 Utviklingsfasen Kapitlet tar for seg implementeringen av applikasjonen, og sammen med utredningsfasen gir et bilde på hvordan produktet ble produsert Fremgangsmåte Under prosessen ble det mye lesing på nett, og hele tiden forbedring av kode, så en iterativ arbeidsmetode falt naturlig for oss Design mobilapplikasjon Når man skal lage design til en mobilapplikasjon er det er det en del viktige ting å tenke på, som at skjermen er liten så et minimalistisk utseende er og foretrekke, ikke masse bilder og plass på å ha 38

40 Prosessrapport god plass til navigering. Siden vi ikke hadde gjort dette før, tok vi utgangspunkt i mobilapplikasjoner vi selv likte og laget et eget utseende basert på erfaringer vi gjorde etter bruken av disse Mockups Vår applikasjon skulle stort sett vise informasjon og motta input fra bruker og lagre dette, så utseende burde være enkelt og oversiktelig på listeform. Bilde: 5,3 39

41 Prosessrapport Slik så vi for oss at det skulle se ut når du klikket deg inn på en detaljert oversikt over et spesifikt arrangement, og et vindu for endring av info. Bilde: 5,4 Slik ble til slutt. Skjermbildet er hentet fra Phonegap Build sin emulator, men utseende og størrelsen er tilnærmet identisk med hvordan det ser ut på iphone Planlegge design Vårt valg av hybrid løsning til å kompilere applikasjonen krever at koden er skrevet i HTML5, CSS og JavaScript, noe som gjør det enkelt å ha et gjennomgående design i applikasjonen. Vha. importerte CSS filer sammen med egendefinerte har vi klart å sette et fast design på hvordan ting skal se ut. Spesielt har jquery Mobile kommet til god hjelp. jquery Mobile (ref kap ) er et rammeverk med metoder og elementer, samt en tilhørende CSS fil. Dette har gjort det enklere å opprette nye sider, og bygge sidene dynamisk med samme design. Vi har lagt vekt på at utseende skal være oversiktlig og brukervennlig, og har som nevnt sett på andre mobilapplikasjoner for å lage oss et eget bilde av hvordan ting kan se ut. Fargene vi har valgt følger en mal i jquery Mobile og gjør det lett å lese og se. Små ikoner på knapper og nedtrekksmenyer er også valgt etter standardikoner, og gir en forklaring i seg selv i tillegg til teksten. Luft mellom elementene er også vesentlig for at det skal være lettere å navigere seg rundt i applikasjonen. Det at knappene alltid er plassert i topp venstre og høyre hjørne, gjør at brukeren alltid vet hvor de er, og gjør det enklere å treffe knappene med fingrene, noe som er en utfordring med utvikling av mobilapplikasjoner. 40

42 Prosessrapport Vi brukte samme versjon av Phonegap Build gjennom hele utviklingen. Vi forsøkte å oppdatere mot slutten av kodeperioden, men dette skar seg og dermed havnet vi tilbake på tidligere versjon Design webside I oppgaven skulle vi lage en tilhørende webside hvor studenter kunne melde seg på spesifikke arrangementer vha. en unik URL gitt til hvert arrangement. Denne siden inneholder kun et par felter for å fylle inn informasjon samt et lite informasjonsfelt. Slik så vi for oss at side kunne se ut i en mockup. Se bilde 5,5. Slik ble den seende ut. Se bilde 5,6 Bilde 5,5 41

43 Prosessrapport Denne siden er laget kjapt for å få en fungerende side. Det ikke lagt mye arbeid i design, men funksjonalitet bak er på plass. Dette fordi det ikke ble satt noe krav til siden, og da satt vi design på siden lengre ned på prioriteringslisten Problemer og løsninger I dette kapitelet tar vi for oss de største problemene vi støttet på under utviklingen av applikasjonen, samt løsningene vi valgte for problemet Liveserver for testing Da tiden var kommet for brukertesting av applikasjonen, trengte vi en ekstern server å legge backend på. Vi fikk da tilgang til en server av en medstudent men vi fikk ikke backend til å kjøre på serveren. Det viste seg at vi hadde brukt noen elementer fra PHP 5.4 mens serveren kjørte versjon 5.3. Det tok litt tid før vi skjønte at dette var årsaken til problemet. Løsningen var da å oppgradere serveren. Da dette var i orden ble vi møtt med et nytt problem når vi gjorde AJAX-kall til backend. Origin is not allowed by Access-Control-Allow-Origin JavaScript er begrenset av «same policy origin». Av sikkerhetsmessige årsaker hindrer policy en JavaScript tilgang til ressurser fra andre domener. Løsningen var å legge til en header i responsen fra backend. header('access-control-allow-origin: *'); 42

44 Prosessrapport Navngivning og kommentarer Navngivning og kommentarer er viktig for en lesbar og oversiktlig kode. Konsekvent bruk av et språk, og kommentarer til hver metode. Vi var sent ute med å sette et fast mønster på navn og kommentarer, og merket etter hvert at dette burde vi ha gjort fra starten da det i senere tid ble knotete og uoversiktlig og endre hele koden på en gang. Vi valgte allikevel å gjøre jobben for en mer lesbar og oversiktlig kode. Kommentarer er lagt til alle metoder og navnene har likt mønster og samme språk iphone lisens For å få lov til å legge mobilapplikasjonen fra Phonegap Build og over på en iphone (som er mobiltypen begge i gruppen har for testing), må en lisens være tilstede med serienummer på mobiletelefonene og annen info mottatt fra Apple mot kjøpt lisens. Accenture hadde tilgang på slike lisenser, men det tok noe tid før vi fikk lisens til å teste. Dette medførte sen testmulighet på iphone, og det viste seg at applikasjonen var litt i overkant lite responsiv da spesielt på iphone 4. iphone 5 og Samsung Note ll hadde akseptabel responstid vel og merke. Det viste seg også senere at vi mistet viktig informasjon i lisensen, og måtte dermed bygge en ny lisens. Noe som medførte tapt tid og frustrasjon. Vi fikk ordnet det kjapt og med god responstid fra veileder hos Accenture var vi kjapt oppe å kjøre igjen Testing selenium Selenium er et testprogram til nettleseren, som lar deg ta opp knappetrykk og innskrivninger, for å senere utføre nettopp denne innspillingen. Vi hadde planer om å bruke dette, men det viste seg fort at Selenium ikke taklet vår type oppbygging av nettside. Vår applikasjon er bygget dynamisk og Selenium mister alle filene vi importerer i index.html fila fra start, fordi Selenium laster sider på nytt etter hvert knappetrykk Handlebars og JQuery Mobile Handlebars er et bibliotek skrevet i JavaScript som vi brukte i starten for å generere templates for HTML-kode. Fordelen er at man kan separere logikk fra presentasjon. Før vi oppdaget jquery Mobile brukte vi ikke noe rammeverk men skrev applikasjonen med hjelp av JavaScript og Handlebars templates. Men da vi gikk over til jquery Mobile fikk vi det ikke til å fungere sammen med Handlebars. Dette løste vi med å gå vekk fra Handlebars og over til å bruke Mustache, som tjener samme formål. 5.4 Dokumentasjonsfasen For å lage sluttdokumentasjonen valgte vi å gå bort i fra Google Docs, fordi formatteringer av diverse slag ikke er tilgjengelig i Google Docs. Vi gikk heller for å bruke Microsoft Word for å ferdigstille rapporten. Vi gikk igjennom dokumentasjonsstandarden laget av Ann-Mari Torvatn tilgjengelig på hovedprosjektsidene, for å få tips til hvordan forme dokumentasjonen. Andre rapporter fra tidligere grupper ble også gjennomgått for å se hvordan de ulike formateringer hadde effekt på å tilegne seg informasjonen. 43

45 Prosessrapport Vi har delt inn i mange kapitler og underkapitler for å enkelt bruke hyperlinker og referanser til andre kapitler. Dette gjør rapporten mer leselig og lettere å navigere seg i. Bilder har også fått egne navn i sammenheng med hvilket kapitel du hører til. Dermed kan vi referere til dem, på samme måte som kapitler. Dokumentasjonen er delt inn i hoveddeler som samlet representerer sluttdokumentasjonen. Prosessrapport; Tar for seg hvorfor vi gjorde det vi gjorde, og hvordan vi arbeidet oss gjennom hele perioden. Produktrapport; Forklarer mer tekniske valg, og hvordan ting fungerer. Testrapport; Tar for seg hvordan vi testet, resultat fra brukertesting. Brukerveiledning; Forklarer hvordan mobilapplikasjonen skal brukes. Vedlegg; Inneholder diverse tilleggsopplysninger vi refererer til i fra andre deler av rapporten. Styringsdokumenter, kildehenvisninger, modeller med mer. 6 Avsluttende del 6.1 Det ferdige produkt Vi har laget et produkt, som med implementasjon i kundens system vil kunne brukes i dag. Etter brukertest har vi fått gode tilbakemeldinger, og kunden er så langt fornøyd. Det finnes forbedringsmuligheter, og oppgaven kan videreutvikles. 6.2 Hva kun vært annerledes Når vi nærmer oss slutten, ser vi at det er ting vi kunne gjort annerledes, men at tiden ikke strekker til Phonegap For å få applikasjonen mer responsiv kunne vi ha utforsket en annen teknologi enn Phonegap, men som forklart i kap fikk vi ikke testet applikasjonen før vi var godt ute i arbeidsperioden. Hadde vi oppdaget treghet veldig tidlig, kunne vi forsøkt en annen teknologi, og sammenlignet mot Phonegap. Vi kunne også ha brukt mer tid på å undersøke å teste andre hybride løsninger Testing For å gjøre testingen enklere, tenker her på soapui (kap ) og ikke generell kodetesting, kunne vi ha satt opp testmiljø før vi begynte å kode, og ikke mot slutten av kodeperioden. Dette hadde gjort koden tryggere å endre og lettere å jobbe med, pluss et fordelt arbeid gjennom hele prosessen og ikke en bulk med arbeid på slutten. 44

46 Prosessrapport Navngivning og kommentarer Vi var ikke konsekvente på navngivning og kommentarer fra starten. Vi satt ikke en fast mal på om kommentarene og navnene skulle være engelsk og heller ikke noe fast oppsett på hvordan navnene var bygget opp relativt til posisjon. Dette skapte ekstra arbeid vi måtte sette av tid til istedenfor å gjøre det kontinuerlig underveis. Dette er noe vi allikevel fikk fikset, med å sette av tid til det. 6.3 Konklusjon Dette er det største prosjektet vi har vært med på og har vært en lærerik, spennende og tidkrevende prosess. Vi måtte ta viktige valg, og for det meste har vi gjort riktige og bra valg vi er fornøyd med. Læringskurven vår har vært bratt fra start, siden vi ikke hadde kunnskap og/eller kjennskap til teknologier vi måtte ta i bruk. Dette var en spennende og krevende utfordring for oss begge, og føler vi har kommet godt ut av det med mye relevant læring og forståelse av nye teknologier. Prosjektet har gitt oss en bedre innlevelse i hvordan et større prosjekt må styres for å komme i mål, og hvor viktig det er å sette opp planer, krav og frister. Vi har gjennom prosjektets løp hatt et bra samarbeid med et ubetydelig antall uenigheter, og kommet i mål til gitte frister hver gang. Samarbeidet med veilederne både på HiOA og hos Accenture fungert bra, med små unntak av kommunikasjonsproblemer, og har vært til stor hjelp gjennom prosjektet. Med hyppige møter mellom oss på gruppa og veiledere har vi holdt en stødig kurs og er nå i mål med erfaringer og et produkt vi er stolte av. 45

47 Sammendrag Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 46

48 Testrapport 1 Innholdsfortegnelse 1 Innholdsfortegnelse Innledning Formål med testing Funksjonalitet Responsivitet Brukertesting Testingen Enheter Verktøy Chrome DevTools Ripple Emulator SoapUI Testing i utviklingsfasen Testing i testfasen Brukertesting Resultater Respons- og funksjonalitetstester Brukertesting Konklusjon

49 Testrapport 2 Innledning Under planleggingen av prosjektet valgte vi å legge testingen til etter utviklingsprosessen. Vi hadde ingen erfaring med testdrevet utvikling og det å skrive programmatiske tester. I stedet fokuserte vi på å teste funksjoner manuelt etter hvert som vi skrev dem. Vi testet egenskrevet kode så vel som hverandres. I utviklingsprosessen har veilederne hos Accenture brukertestet applikasjonen og gitt oss tilbakemeldinger. Og i midten av april ga de oss tips til verktøy vi kunne ta i bruk i siste del av utviklingen og i testfasen. Denne rapporten tar for seg oppsett, utførelse og resultater av testingen. 48

50 Testrapport 3 Formål med testing Testing av programvareprodukter er viktig for: å sikre at et program er i stand til å gjøre det programmet er ment å gjøre. at programmet oppfyller kravene i kravspesifikasjonen. å oppdage feil før programmet tas i bruk. å avdekke svakheter i design og brukervennlighet. Vi valgte å utføre testene med fokus på funksjonalitet, responsivitet og brukertesting. 3.1 Funksjonalitet For å kunne levere et godt produkt er det en nødvendighet at applikasjonen oppfører seg som man forventer. Det betyr at alle knapper for navigasjon og funksjonalitet fører dit dem skal, gjør det dem skal og er intuitive. 3.2 Responsivitet Mennesker er utålmodige vesener. Det er derfor viktig at applikasjonen er responsiv, at animasjoner flyter fint og at det generelt er lite ventetid. 3.3 Brukertesting Brukertesting er kanskje den viktigste formen for testing. Det er fort gjort at en som har utviklet en applikasjon ser seg blind på design, navigasjon og hvordan bruke funksjonaliteten. Ved å la andre som ikke kjenner oppbyggingen eller har sett applikasjonen, kan man få verdifulle tilbakemeldinger om hva som fungerer og hva som gjøres annerledes. 49

51 Testrapport 4 Testingen I utviklingsprosessen ble testingen hovedsakelig utført lokalt på egne laptoper. Vi fikk ikke testet ut applikasjonen på telefon før halvveis ut i prosjektperioden. Årsaken til dette var at for å kunne installere applikasjoner på iphone-telefoner, noe vi begge har, krever Apple at man betaler 99 dollar for et utviklersertifikat. Arbeidsgiver hadde imidlertid et sertifikat til oss men det tok tid å få på plass. 14. mars ble det endelig i orden og vi kunne begynne å teste på telefon i tillegg. 4.1 Enheter Følgende enheter ble brukt til testing. Dell (laptop) CPU: Intel Core 2.5GHz Minne: 4 GB RAM OS: Windows 7 iphone 4 CPU: 1 GHz Cortex-A8 Minne: 512 MB RAM Skjerm: 3,5 tommer OS: ios iphone 5 CPU: Dual-core 1.2 GHz Minne: 1 GB RAM Skjerm: 4 tommer OS: ios Samsung Galaxy Tab 10.1 CPU: Dual-core 1 GHz Cortex-A9 Minne: 1 GB RAM Skjerm: 10,1 tommer OS: Android iphone-telefonene var våre og de var følgelig tilgjengelige gjennom hele prosjektperioden. Samsungtableten fikk vi låne fra skolen da testfasen tiltok. 4.2 Verktøy Vi har tatt i bruk verktøy for feilsøking og testing. Nedenfor er en oversikt over hvilke verktøy vi har brukt Chrome DevTools Chrome developer tools er et nyttig innebygget verktøy i Chrome. Her kan man blant annet inspisere DOM og CSS, bruke JavaScript-konsollen til å se innholdet av loggede variabler og objekter, feilsøke i JavaScriptkode og se på ressurser og headere som sendes/mottas. 50

52 Testrapport Bilde: 4,1 Konsollen brukte vi hyppig for å undersøke innholdet av variabler og objekter. function geteventlist() { getdata.getarrangementer(function(arrangementer){ console.log(arrangementer); var template = $("#event-li-tpl").html(); var html = Mustache.to_html(template, arrangementer); $('#event-list').html(html); $('#event-list').listview('refresh'); }); } Linjen «console.log(arrangementer);» i kodeeksempelet ovenfor vil skrive ut innholdet av «arrangementer» i Console-fanen i DevTools. En annen funksjon vi brukte mye var å gå inn på en request for å se på headerne som ble sendt frem og tilbake, samt på data som ble returnert fra kallet. 51

53 Testrapport Ripple Emulator Ripple Emulator er en utvidelse for Chrome og er en multiplattform mobil-emulator som er laget for applikasjoner skrevet i HTML5, CSS og JavaScript. Den gjør det mulig å teste applikasjoner på forskjellige plattformer i sanntid. Vanlige feilsøkingsverktøy, som Chrome DevTools, for nettlesere fungerer sammen med emulatoren. Dette verktøyet brukte vi hovedsakelig for å teste at designet ble slik vi hadde tenkt. Bilde: 4,2 52

54 Testrapport SoapUI SoapUI er et webtjenertesteprogram for serviceorienterte arkitekturer (SOA). Programmet har mange muligheter for testing, bl.a. funksjonell testing, webtjener testing, REST testing mm. Bilde: 4,3 Her gjorde vi integrasjonstesting ved at vi opprettet tester for de forskjellige ressursene vi har i API et. Vi laget tester for alle GET-metoder (metoder som kun henter data, ikke modifiserer) og for en av POST-metodene (metoder som oppretter ny data). Testene for GET-metodene kjørte vi mot et testarrangement og la til «assertions» for å sikre at metodene returnerte hva som var forventet. «Assertions» er en måte å undersøke om en respons inneholder en spesifikk ting. 53

55 Testrapport Så kjørte vi alle testene for å få tilbakemelding på de som ble godkjent og de som eventuelt feilet. Dette ga oss en trygghet ved at når vi gjorde endringer i koden, kunne vi enkelt kjøre testene for å forsikre at ressursene fungerte som de skulle. 54

56 Testrapport 4.3 Testing i utviklingsfasen Tidlig i utviklingsfasen var det fokus på å sette seg inn i domenet, ha dialog med arbeidsgiver for å kartlegge krav og behov, lære seg teknologier som skulle brukes og bli kjent med utviklingsverktøy. Derfor ble testingen begrenset til at vi selv kontrollerte at metoder og funksjoner fungerte slik vi ønsket. Omtrent midtveis i fasen ble det ordnet med iphone-lisens, og vi kunne begynne å teste applikasjonen på telefon. Mot slutten av utviklingsfasen tok vi i bruk SoapUI for integrasjonstesting av backend. I denne fasen testet vi applikasjonen med backend liggende lokalt på egen laptop og med databasen på ekstern server. 4.4 Testing i testfasen Etter utviklingsfasen har vi hatt kodefrys i forhold til å implementere ny funksjonalitet. Vi konsentrerte oss om å teste og utbedre feil i applikasjonen og på backend. Noen feil visste vi om men som vi prioriterte å vente med å utbedre til testfasen. Andre feil ble avdekket og feilrettinger ble gjort. Vi la til rette for brukertesting ved å legge backend på ekstern server og konfigurere applikasjonen til å bruke denne. Ved testing på telefonen frem til nå, var man avhengig av at laptop med backend og telefonen var koblet til samme nettverk. Men nå var det mulig å teste på telefon fra alle steder med internettilgang. 4.5 Brukertesting Gjennom utviklingsperioden har vi på veiledermøtene hos Accenture latt veilederne teste applikasjonen. Til å begynne med via emulatoren på laptop, og etterhvert, da vi fikk ordne med lisens, også på telefon. I testfasen fikk vi en medstudent og tre Accenture-ansatte til å gjøre brukertesting. Medstudenten fokuserte på bruk, utseende og brukervennlighet da han ikke hadde kjennskap til behovene og kravene til applikasjonen. Accenture kunne i tillegg teste i forhold til behov og krav. Brukerne testet slik de selv ville, uten noen spesielle instrukser fra oss. Grunnet liten tid og problemene med server, fikk vi bare tid til én uke testing. Men like fullt var tilbakemeldingene veldig verdifulle. 55

57 Testrapport 5 Resultater 5.1 Respons- og funksjonalitetstester Til disse testene valgte vi å bruke en iphone-telefon og en Samsung Galaxy Tab. På den måten fikk vi testet applikasjonen på to forskjellige plattformer og med forskjellig skjermstørrelse. På begge enhetene lugget animasjonene i overgangen mellom sider. Årsaken til dette er enhetenes ytelsesevne i forhold til å kjøre JavaScript. På iphone 5, som har en mye høyere ytelse, kjører animasjonene fint. [1] Bilde 5,1 Vi ser iphone 4 få 3545 mens Samsung Galaxy Tab får 2400 [2] i en tilsvarende test (lavere er bedre). Side Aktivitet Samsung iphone 4 Oppstart Oppstart av applikasjonen OK OK Startsiden Innlasting OK OK Bruke søkefeltet OK OK Trykke på et arrangement OK OK Trykke (+) OK OK Legge til arrangement Innlasting OK OK Fylle inn felter OK OK Trykke «Lagre» når ferdig utfylt OK OK Trykke «Lagre» når ikke ferdig utfylt OK OK Trykke «Tilbake» OK OK Detaljert arrangement Innlasting OK OK Trykke på «Inviter via mail», «Sjekkliste» OK OK og «Påmeldte studenter» Trykke på «Endre» OK OK 56

58 Testrapport Endre arrangement Innlasting OK OK Noe treg og dato blir ikke lastet inn Gjøre endringer i feltene OK OK Trykke «Ferdig» OK OK Trykke «Tilbake» OK OK Trykke «Slett» OK OK Inviter til arrangement Innlasting OK OK Fylle inn feltene OK OK Trykke «Send» OK OK Trykke «Tilbake» OK OK Sjekkliste Innlasting OK rødt OK kryss for «ikke utført» vises ikke Trykke på et sjekkpunkt OK OK Trykke (+) OK OK Trykke «Tilbake» OK OK Legg til sjekkpunkt Innlasting OK OK Fylle inn feltene OK OK Trykke «Lagre» OK OK Trykke «Tilbake» OK OK Detaljert sjekkpunkt Innlasting OK OK Gjøre endringer i feltene OK OK Trykke «Lagre» OK OK Trykke «Tilbake» OK OK Trykke «Slett» OK OK Påmeldte studenter Innlasting OK OK Trykke på student OK OK Trykke «Tilbake» OK OK Detaljert student Innlasting OK OK Trykke «Tilbake» OK OK 5.2 Brukertesting Vi fikk følgende tilbakemeldinger fra Accenture sin brukertest. Positivt: Svært nyttig app som dekker akkurat de behovene vi har i dag Kommer til å spare oss for svært mye tid Blir svært bra når integrering med sharepoint kommer Bra og enkelt design Godt at den bygger på samme oppsett vi bruker nå Svært god app som kan bygges videre på Andre kommentarer: 57

59 Testrapport Noen små bugs her og der, men kommer trolig av rammeverk og ikke implementasjon Litt trege sidebytter Litt vanskelig tilbakemelding til brukeren, og flere ting som kunne vært "automatisk" Medstudenten sin brukertest resulterte i følgende forbedringspotensialer. Datoformatet er ikke konsistent gjennom applikasjonen. Man får en alert når man lagrer og sletter sjekkpunkter, men ikke når man lagrer og sletter arrangementer. Postnummerfeltet kan med fordel endres til et nummerfelt, sånn at det numeriske tastaturet kommer opp når man fokuserer på feltet. Hvis det ikke er noen påmeldte studenter, så trenger man heller ikke å komme inn til en tom liste. Vurder å vise antall sjekkpunkter og antall fullførte på menyelementet (sånn som antall påmeldte studenter). Påkrevde felter kan med fordel markeres med en rød stjerne eller lignende. Validering bør kanskje skje ved endringer i tillegg til blur. Et par av feilmeldingene hang igjen etter å ha valgt element. Vurder å legge inn standardemne på e-post, da mange ikke fyller ut emnefelt i det hele tatt. På en del telefoner har man en menyknapp på telefonen. Vurder å implementere en enkel meny som inneholder standardfunksjoner for den siden man står på, som for eksempel "Nytt arrangement" når man titter på listen over arrangementer. 58

60 Testrapport 6 Konklusjon Testrapporten gir en oversikt på hva som har blitt testet, hvordan testingen ble gjennomført og hva som ble resultatene av dem. Integrasjonstestingen gjort med SoapUI sikret at backend server var stabil og ga konsistente svar. Respons- og funksjonalitetstestene ble gjort for å sikre at navigering, knapper og funksjonalitet i applikasjonen fungerte slik vi ønsket og avdekke eventuelle avvik. Brukertestingen var svært viktig for å sikre at applikasjonen oppfylte kravene og behovene til Accenture. De avdekket også svakheter og resulterte i forslag til løsninger for å gjøre applikasjonen bedre. Ved å dokumentere testingen står fremtidige utviklere bedre rustet til å utvide og forbedre systemet. Kilder: [1] [2] 59

61 Sammendrag Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Vedlegg 60

62 Vedlegg 1 Innholdsfortegnelse 1 Innholdsfortegnelse Kravspesifikasjon Innledning Innledning Om bedriften Bakgrunn for prosjekt Forord Systemkrav Funksjonskrav Tekniske krav Dokumentasjon Krav til dokumentasjon Utvidelser Arbeidsplan Fremdriftsplan Forprosjekt Sammendrag Dagens situasjon Mål og rammebetingelser Løsninger /alternativer Utviklingsspråk Dokumenter/rapporter/generelle notater Kildekode Prosjektskisse Risikoanalyse Brukerveiledning Forord Innledning Hvordan bruke applikasjonen? Startsiden

63 Vedlegg Nytt arrangement Detaljert arrangement Endre Inviter studenter Sjekkliste Legg til nytt sjekkpunkt Endre sjekkpunkt Påmeldte studenter Detaljert studentvisning Feil i applikasjonen Sekvensdiagrammer Kilder

64 Vedlegg 2 Kravspesifikasjon Gruppe Gruppe 19 Andreas Berglihn, s Harald R. Svendsen, s Oppdragsgiver Accenture AS Kontakt- Accenture Rune Waage, rune.waage@accenture.com, person Veileder Accenture HIOA Jostein Guldal, jostein.guldal@accenture.com Siri Kessel, siri.kessel@hioa.no Simen Hasselknippe, simen.hasselknippe@live.com Dato

65 Vedlegg 2.1 Innledning Innledning Prosjektet blir utført, som hovedprosjekt for dataingeniør v/hioa i samarbeid med Accenture AS. Oppgaven er å lage en mobilapplikasjon for arrangementer, hvor ansatte hos Accenture kan avtale møter med studenter for jobbsamtaler, sette opp presentasjoner, aktiviteter, osv. Mobilapplikasjonen skal skrives i HTML, CSS og Javascript, og deretter konverteres til ønskelig plattform vha Phonegap. Backend av systemet skal skrives i PHP i rammeverket CodeIgniter Om bedriften Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Vi leverer nyskapende løsninger og samarbeider med kundene, slik at de kan realisere sine visjoner og skape verdi for seg selv. Med vår omfattende bransjeekspertise, våre globale ressurser og vår erfaring innenfor konsulentvirksomhet og driftsutsetting kan vi mobilisere de riktige menneskene og den nødvendige kompetansen for å hjelpe våre kunder til å bli virksomheter med høy prestasjonsevne. Med mer enn ansatte i 49 land hadde Accenture en omsetning på 23,40 milliarder dollar i regnskapsåret som ble avsluttet 31. august Accenture s hjemmeside: eller Bakgrunn for prosjekt Accenture setter per i dag opp jobbsamtaler og arrangementer med å bestille sted/rom, setter opp timeplan, bestiller nødvendige ressurser, informerer HR om arrangement og gir telefonnummer til den som bestiller sted/rom, sender ut sms/mail til student om avtalt tid og sted. Deretter, hvis det er snakk om jobbsamtale, er det avhengig av om rommet er ledig. Hvis ikke, og studenten ikke kan komme på et annet tidspunkt, så tas samtalen per telefon. Alt dette skal vi putte i en og samme applikasjon. Den skal kunne sette opp avtaler, sende ut mail og legge inn avtalte møter i intern kalender. Det vil spare ansatte mye tid og vil gjøre det lettere å finne ledig rom/sted og jobbsamtaleressurs/arrangementansvarlig. 2.2 Forord Hensikten med kravspesifikasjonen er å definere hva mobilapplikasjonen skal kunne gjøre og hvilken funksjonalitet den skal inneholde. Videre er kravspesifikasjonen en basis for å kunne estimere framdriften i prosjektet og for å vurdere om omfanget av det som skal gjøres er realistisk i forhold til tiden som ligger til rådighet. 64

66 Vedlegg Kravspesifikasjonen er beregnet for gruppemedlemmene, veilederen i Accenture og veilederne på skolen. 2.3 Systemkrav Funksjonskrav Mobilapplikasjonen skal være tilgjengelig for alle accenture-ansatte. Man skal kunne registrere arrangement på gitt dato. Skal ta imot påmeldinger fra studenter via webgrensesnitt. Skal sende kvittering til studenter via mail, med bekreftelse om tid/sted ELLER informasjon om at arrangementet er fullbooket og at de vil kontaktes via telefon. Visning av enkelt arrangement med påmeldte studenter. Skal kunne legge til sjekklistepunkter i arrangement Skal kunne tildele en accentureansatt til et arrangement, som ansvarlig. Skal ha mulighet for å flytte eller stokke på avtaler i arrangementet med automatisk e- postbekreftelse til involverte studenter Tekniske krav Utvikles i HTML5, CSS og JavaScript(JQuery, Ajax, JQuery Mobile) Kompileres til smarttelefonplattformer med PhoneGap Build. Bruker Netbeans 7.2 til å skrive koden. Backend skal skrives i rammeverket CodeIgniter(PHP) og følge REST. JSON skal brukes til å overføre data til og fra mobil. OAuth skal brukes til sikker sending av data. MySQL skal brukes til databasespørringer. Design skal følge retningslinjene til forskellige OS 2.4 Dokumentasjon Krav til dokumentasjon Prosjektdagbok føres hver gang vi gjør noe nytt i prosjektet ved øktens slutt. Timeplan føres kontinuerlig. Ved prosjektets slutt leveres en samlet sluttrapport, som skal inneholde følgende delrapporter: Prosessrapport Kravspesifikasjon Produktrapport Testrapport Brukerveiledning 65

67 Vedlegg Utvidelser 2.5 Utvidelser Mulighet til å registrere egen enterpriseid i profil(brukes til å vise egne kandidater til oppfølging) Listevisning av studenter som har hatt/skal ha samtale Push-varsling når status endres på mine kandidater Push-varsling når det er på tide å følge opp kandidater Mulighet til å endre status på kandidater Mulighet til å legge inn template til sjekkliste. Integrasjon mot SharePoint-løsning. Min side som gir brukeren oversikt over arrangementer hvor brukeren har ansvar og som fremhever arrangementer hvor statusen har blitt oppdatert. 66

68 Vedlegg 3 Arbeidsplan Statusrapport: Kort om gruppen og ønsket prosjekt Prosjektskisse: Presisering og definering av prosjektet Forprosjektet: Definerer oppgaven ytterligere Database: ER-diagrammer over databasen. Satt opp databasen på server Prosjektside: Mulighet for publisering av dokumenter Sprint 0 slutt: Sprint 0 er arbeidet som har pågått til nå; Kravinnsamling, research av potensielle teknologier, oppsett av utvikliermiljø, legge inn oppgaver i produkt backlogen i scrum, lage database mm Sprint 1 start: Begynne å skrive kode for funksjonalitetene visning av arrangementliste, visning av bestemt arrangement og visning av sjekklister Sprint 1 slutt Sprint 2 start: Skrive kode for funksjonalitetene oppretting/oppdatering av arrangement og sjekklistepunkter Sprint 2 slutt Sprint 3 start: Siste sprint med koding. Skrive kode for sikker sending av data med OAuth, registreringsside for påmelding av studenter og visning av jobbsamtalesertifiserte Sprint 3 slutt Kravspesifikasjon: Definerer krav til systemet. Krav gitt fra oppdragsgiver. Koding: Kodefrys. Koden skal her være ferdig, slik at vi kan starte på avslutningsprosessen. Design: Design skal være ferdig utviklet Sprint 4 start: Testing, bugfiksing og rapportskriving Sprint 4 slutt: Testing og bugfiksing ferdig. 67

69 Vedlegg Sprint 5 start: Skrive ferdig og sette sammen prosjektrapporten for innlevering Sprint 5 slutt: Rapport klar til innlevering i god tid før fristen klokka 12. Prosjektdagbok: Oppdatert hele veien og beskriver hva vi har gjort til enhver tid. Dokumentasjon Brukermanual Rapport Kvalitetssikring Presentasjon: 68

70 Vedlegg 4 Fremdriftsplan 2013 Januar Februar Mars April Mai Juni Uke x Innledende Statusrapport Prosjektskisse Prosjektdagbok Prosjektside Forprosjekt Forprosjektrapport Fremdriftsplan Arbeidsplan Kravspesifikasjon Kravrapport Implementering Database Koding Design Testing Testing Dokumentasjon Brukermanual Prosjektrapport Kvalitetssikring Presentasjon Forberede Presentasjon Sprinter Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 I arbeid Milepæl. Ferdigstilt Frister Presentasjon 69

71 Vedlegg 5 Forprosjekt Gruppe 19: Andreas Berglihn s Harald R. Svendsen s Event-planlegger Gruppe Gruppe 19 Andreas Berglihn, s Harald R. Svendsen s Oppgave Eventplanlegger Utvikle en applikasjon for registrering av jobbsamtaler og arrangementer mellom ansatt hos accenture og student. Integrere pushvarsling og sms. Kontaktperson Accenture Rune Waage, rune.waage@accenture.com, Veileder Accenture HIOA Jostein Guldal, jostein.guldal@accenture.com Siri Kessel, siri.kessel@hioa.no Simen Hasselknippe simen.hasselknippe@live.com 5.1 Sammendrag Accenture i dag har ingen automatisert metode for å sette opp en eller flere studenter til et arrangement, som f. eks. en jobbsamtale, kickoff osv. De ønsker en applikasjon til smarttelefon, som gjør dette for dem. Det legges inn et arrangement, studenter blir lagt til, rom blir booket, ressurs til eventen settes osv. All informasjonen går via applikasjonen. Applikasjonen skrives i NetBeans og kompileres til alle plattformer med PhoneGap Build. HTML5, CSS, JavaScript brukes, som språk og mysql til database. I arbeidsplan og fremdriftsplan, som ligger vedlagt, viser vi grafisk og punktvis stegene vi tar for å komme i mål med oppgaven. Kravspesifikasjonen er laget med tanke på dagens krav og mål, men vi bruker vannfall og scrum til å lage applikasjonen, og dermed kan denne endres noe underveis. 5.2 Dagens situasjon Accenture tar i dag i mot påmeldinger fra studenter for jobbsamtaler og andre arrangementer på stands på karrieredager, eller at studenten sender en SMS. Dette innebærer at Accentures ansatte må bruke mye tid og ressurser på å sette opp møter. Dagens prosess: 70

72 Vedlegg 5.3 Mål og rammebetingelser Målet med prosjektet er å utvikle et system som skal gjøre det enklere for Accenture å sette opp jobbsamtaler med studenter og for å la studenter melde seg på ulike arrangementer som Accenture måtte holde. Dagens rutiner krever en del manuelle steg og et hovedmål er at det nye systemet skal være tidsbesparende for Accentures konsulenter samt sørge for bedre kvalitet og brukeropplevelse for studentene de møter. 71

73 Vedlegg Løsningen skal interegreres mot en SharePoint- og SMS-portal hos Accenture. Ellers har gruppen stått fritt til å velge utviklingsverktøy og hvordan løsningen implementeres. 5.4 Løsninger /alternativer Utviklingsspråk Til å utvikle applikasjonen har vi valgt å bruke HTML5, CSS og JavaScript for å kunne bruke i sammenheng med PhoneGap. Ved å bruke HTML5, CSS og JavaScript, så vil vi kunne eksportere vår applikasjon enkelt til de mest brukte mobilplattformene som ios, Android, Windows Mobile osv. Dette er noe vi ser på som viktig, slik at alle kan bruke denne applikasjonen og vi får testet ut flere plattformer. PhoneGap er det verktøyet, som skal kompilere koden vår over til hver enkelt plattform. Her finnes det en online kompilator som heter PhoneGap Build. I tillegg finnes det en nettside, som brukt sammen med en utvidelse til Chrome, vil kunne emulere alle plattformene uten å måtte ha hardwaren selv. Finnes også en live testing og kompilering direkte til hardware om du skulle ha det tilgjengelig (f. eks en iphone). Vi valgte bort: Xcode, og generelt andre utviklerverktøy, som kun fokuserer på en plattform. Det er også hovedgrunnen til at vi valgte dem bort Dokumenter/rapporter/generelle notater Til å skrive dokumenter, som rapporter, generelle notater osv, har vi bestemt å bruke Google Docs. Dette er noe vi har erfaring med fra tidligere og liker veldig godt. Data ligger lagret online, og er tilgjengelig fra hvor som helst. Kan være flere forfattere samtidig. Funskjonelt og enkelt, med tekstfiler, regneark osv. Vi valgte bort: Dropbox, som er et gratis lagringsområdet på nett for deling av filer. Ved å droppe dette slipper vi å bruke versjonshånderingsverktøy for hvert minste dokument vi oppretter. Slipper også å måtte laste ned filene om vi ikke skulle være på vår egen maskin når vi skal endre eller legge til noe i dokumentene. 72

74 Vedlegg Kildekode For lagring av kildekoden bruker vi Accenture sin egen innersource side, som er koblet opp med git (versjonshåndteringsprogram). På denne måten får vi tilgang gjennom en browser og ekstern lagring og backup. Vi får dokumentert koden ordentlig vha. git og dens versjonskontroll. Valgte bort Dropbox-git-github, har vi brukt før og er fornøyd med, men av anbefaling av Accenture valgte vi bort dette valget, da det andre allerede ligger klart, og er lettere å bruke. 73

75 Vedlegg 6 Prosjektskisse Hovedprosjekt i data/informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2013 Høgskolen i Oslo og Akershus Jobbsamtale-app av Andreas Berglihn, s Harald Svendsen, s Oppdragsgiver og Kontaktperson. Rune Waage Accenture Technology Solutions Snarøyveien 30A, Oslo Tlf: Om Accenture Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Vi leverer nyskapende løsninger og samarbeider med kundene, slik at de kan realisere sine visjoner og skape verdi for seg selv. Med vår omfattende bransjeekspertise, våre globale ressurser og vår erfaring innenfor konsulentvirksomhet og driftsutsetting kan vi mobilisere de riktige menneskene og den nødvendige kompetansen for å hjelpe våre kunder til å bli virksomheter med høy prestasjonsevne. Med mer enn ansatte i 49 land hadde Accenture en omsetning på 23,40 milliarder dollar i regnskapsåret som ble avsluttet 31. august Accenture s hjemmeside: eller Bakgrunn for oppgaven Rekruttering i Accenture gjennomfører årlig et stort antall jobbsamtaler med studenter ute på ulike læresteder i Norge. Påmelding til jobbsamtaler er tradisjonelt gjort på stand på karrieredager. Høsten 2010 er det satt opp en løsning for påmelding til jobbsamtaler via SMS. Denne løsningen krever en del manuelle steg, og vi ønsker å utvikle en iphone-applikasjon som støtter jobbsamtalerutinene i 74

76 Vedlegg Accenture. Dette vil være tidsbesparende for våre konsulenter samt sørge for bedre kvalitet og en bedre brukeropplevelse blant studentene vi møter. Beskrivelse av oppgaven Gruppen skal lage en iphone-app integrert mot en sharepoint-portal og en SMS-portal. Ønsket høynivåfunksjonalitet er delt inn i to versjoner som kan leveres separat eller sammenhengende- deler av funksjonaliteten i versjon 2 er avhengig av funksjonalitet i versjon1. 7 Risikoanalyse Sannsynlighet Lite farlig(2) Farlig(4) Kritisk(6) Katastrofalt(8) Høy(2,5) Moderat(2) Middels(1,5) Lav(1) Tabellen illustrerer med farger og tall hvor sannsynlig det er at en hendelse er en risiko i prosjektets løp. Fargene er i rekkefølge fra minst kritiske grønn til mest, som er rød. Tallene er kun for å vise at risikoen øker proporsjonalt med økt forekomst av en mulig hendelse. Kortidssykdom Risikonivå: 2-4 Hvordan unngå: Dette er bare opp til hvert individ. Å bli korttidssyk er ikke noe man kan unngå Løses: Personen, som er syk, kan prøve å jobbe hjemmefra i fraværsperioden, eller 75

77 Vedlegg forsøke å ta igjen tapt arbeid, ved en senere anledning. Langtidssykdom/annen fraværsgrunn Risikonivå: 5-10 Hvordan unngå: Dette er en mulighet, og må tas i betraktning. Spesielt i vårt tilfelle, som kun er to på gruppa. Vi mister da 50 % arbeidskraft. Kan heller ikke unngåes så lett. Pass på å ta pauser i arbeidsøktene og spis godt. Løses: Personen, som er syk, kan prøve å jobbe hjemmefra i fraværsperioden, eller forsøke å ta igjen tapt arbeid, ved en senere anleding. Gjenværende gruppearbeid må stå på ekstra, og informere arbeidsgiver om situasjonen. Mulig korte ned på kravene. Store uenigheter og krangler Risikonivå: Hvordan unngå: Sett opp planer fra starten av og hold til dem Løses: Bring inn oppdragsgiver eller veiildere på skolen i diskusjonen. Informasjonstap Risikonivå: 5-15 Hvordan unngå: Kjør backup og versjonshåndtering. Vi bruker Git, google docs og dropbox. Vi har hver vår lokale kopi på PCen også. Løses: Push til git repository daglig, og lagre arbeidet hyppig. For stor arbeidsmengde Risikonivå:

78 Vedlegg Hvordan unngå: Pass på å ikke sett opp for store oppgaver i sprintene, og vær tidlig obs på for store arbeidsmengder, da dette kan lettere styres på sikt. Løses: Høyere intensitet eller kutting av kravene i samarbeid med oppdragsgiver. Dårlig kontakt med veiledere Risikonivå: Hvordan unngå: Avtal møter i god tid. Hold kontakt på mail. Oppdater og gi informasjon. Løses: Informere HiOA og oppdragsgiver og gjør dem oppmerksomme på situasjonen 77

79 Vedlegg 8 Brukerveiledning Eventhandler Mobilapplikasjon utviklet for kryssplattformer. Utviklet av Andreas Berglihn og Harald Svendsen i samarbeid med Accenture AS. Bacheloroppgave

80 Vedlegg Forord Dette er en brukerveiledning for mobilapplikasjonen som vi har valgt å kalle Eventhandler, er laget i samarbeid med Accenture AS, og er utviklet som bacheloroppgave 2013 v/hioa av Andreas Berglihn og Harald Svendsen. Brukerveiledningen tar for seg steg for steg hvordan bruke mobilapplikasjonen. Forklart med tekst og bilder for gi en full visuell gjennomgang. PS! Utseende kan variere fra plattform til plattform. Bildene som er lagt ved i denne brukerveiledningen er skjermbilder fra applikasjonen kjørt på en iphone. 79

81 Vedlegg Uttrykk Arrangement: Kan være jobbsamtale, bedriftpresentasjon på en skole, karrieredag osv. Mobilapplikasjon: Et program laget for mobil. Nedtrekksmeny: En meny som spretter frem når man klikker på en knapp. 8.1 Innledning Applikasjonen er utviklet for å kunne opprette og administrere arrangementer styrt av Accenture AS. Applikasjonen er beregnet til bruk av Accenture AS sine ansatte, med et tilhørende webgrensesnitt for påmelding av studenter. Hvert arrangement har en sjekkliste og unik tilhørende webside for påmelding av studenter (denne siden er ikke inkludert her). Listen over påmeldte studenter er tilgjengelig via hvert arrangement i applikasjonen. Hvert arrangement har også en ansvarlig, gjerne en ansatt i Accenture AS, samt en skole som står ansvarlig. Skolegrupper legges også inn i hvert arrangement for å se hvem som skal få invitasjon og kunne delta på arrangementet. 8.2 Hvordan bruke applikasjonen? Her vil du stegvis bli ledet igjennom bilder og tekst, som viser hvordan applikasjonens funksjonalitet. Bilder er lagt til for visuell klarhet Startsiden Startsiden er en oversikt over alle arrangementer, som er lagt til. Disse er sortert etter dato for gjennomføring og kan sorteres på skole eller skolegruppe vha. søkefeltet øverst på siden. 80

82 Vedlegg Bilde: Nytt arrangement I øvre høyre hjørne er en knapp for å legge til et nytt arrangement, med tilhørende informasjon. Klikker du på (+) knappen vil du få opp dette skjermbildet. 81

83 Vedlegg Bilde: 2 De blå feltene er nedtrekksmenyer og aktiveres ved å klikke på dem. Nedtrekksmenyene kan ha forskjellig utseende alt etter hvilken plattform applikasjonen kjører på. Aktivitetstype: Hvilke aktivitetstype arrangementet er. Navn: Navn på arrangement. Vil vises i listen. Skole: Hvilken skole er ansvarlig for arrangementet. Skolegruppe: Hvilke skolegrupper skal delta på arrangementet. Ressurs: Hvem av de ansatte er det som skal være til stede. Adresse og postnummer: Hvor skal arrangementet holdes. Dato: Når skal arrangementet holdes. 82

84 Vedlegg Accuser (ansvarlig): Hvem av de ansatte har ansvaret for arrangementet. Kommentar: Tilleggskommentar til arrangementet. I denne versjonen anbefales det at alle feltene fylles ut. Noen felter tillates tomme. Når data er fylt inn i feltene og verdier er valgt, så klikkes (lagre) knappen oppe i høyre hjørne for å sende utfylt data til server. Applikasjonen går så til detaljsiden for det nyopprettede arrangementet Detaljert arrangement Alle arrangementer i listen kan klikkes på for å komme videre til en detaljert side over arrangementet. Siden for å endre eller slette gjeldende arrangement er også tilgengelig herfra. Bilde: 3 83

85 Vedlegg Endre For å endre arrangementet klikker du deg videre på (endre) knappen i høyre hjørne, og vil få opp dette skjermbildet. Bilde: 4 Forklaring på felter se punkt 2. Her har du muligheten til å endre dataene du la inn da arrangementet ble opprettet. I tillegg er muligheten for å endre status på arrangementet tilgjengelig. Denne blir, som standard satt til 0 NY ved opprettet arrangement fordi du ikke skal ha mulighet til å hoppe over en status, noe du heller ikke har nå. 84

86 Vedlegg Bilde: 5 Statusen, sammen med sjekklisten som er forklart i punkt , brukes til for å holde oversikt over hvor langt hvert enkelt arrangement er kommet i planleggingsprosessen Inviter studenter Fra bilde 3, kan du invitere studenter til arrangementet. Dette skjer som regel ved at det sendes ut en mail til en ansatt på en skole, som videresender til en gruppe studenter. Klikker du inn på knappen for å invitere studenter får du opp dette skjermbilde. Bilde: 6 Mailen bygger en melding basert på informasjon knyttet til arrangementet du har valgt. Det opprettes en unik lenke som leder til en påmeldingsside for studenten. Denne lenken ser du nederst i meldingsfeltet. 85

87 Vedlegg Sjekkliste Fra bilde 3, kan du klikke deg inn på listen for sjekkpunkter. Når du oppretter et arrangement vil du få lagt til en forhåndsdefinert liste med sjekkpunkter, alt etter hvilken aktivitetstype du velger. I listen vil du se et grønt avhuk eller et rødt kryss alt ettersom sjekkpunktet er utført eller ikke (se punkt 8). Bilde: Legg til nytt sjekkpunkt I listen kan du legge til egendefinerte sjekkpunker eller flere forhåndsdefinerte punkter. Dette gjøres på ved å klikke på (+) oppe i høyre hjørne (se bilde 7). 86

88 Vedlegg Bilde: 8 Om du vil ha et forhåndsdefinert sjekkpunkt velger du et fra nedtrekkslisten i toppen. Feltene navn og beskrivelse vil fylles ut automatisk. Sjekkpunkt som allerede er lagt til, vil være grået ut og ikke mulige å velge (se bilde 9). Om du vil ha et egendefinert sjekkpunkt, så hopper du over første nedtrekksmeny og fyller inn resten av punktene selv. 87

89 Vedlegg Bilde: Endre sjekkpunkt Fra bilde 7 kan du klikke deg inn på hvert enkelt sjekkpunkt for å endre informasjon, sette det til fullført eller slette sjekkpunktet. 88

90 Vedlegg Bilde: 10 Om du setter en dato i feltet utført, så vil det komme et grønt avhuk i listen over sjekkpunkter (se bilde 7). Samme om du velger knappen (tøm), så vil datoen fjernes og du vil få et rødt kryss istedenfor, som indikasjon på at sjekkpunktet ikke er utført. Når du er ferdig klikker du lagre i øvre høyre hjørne Påmeldte studenter Fra bilde 3 kan du se hvor mange studenter som er påmeldt arrangentet. Trykker du deg inn på påmeldte studenter vil du få en liste med navn på studenter som er påmeldt sortert etter skole. 89

91 Vedlegg Bilde: Detaljert studentvisning Fra bilde 11 kan du trykke på en student for å få mer informasjon om studenten. Her vil du i tillegg kunne se e-postadressen studenten meldte seg på med og telefonnummeret. 8.3 Feil i applikasjonen Bilde: 12 iphone: Uthentet dato og tidspunkt under endre arrangement virker ikke. Den henter ut en nullverdi. Uvisst om flere plattformer er rammet av feilen. 90