Del 1: prosessdokumentasjon

Del 1: prosessdokumentasjon ~ 1 ~

1 Forord Denne rapporten tar for seg prosessen vi har vært igjennom i løpet av prosjektet. Dokumentet viser hvordan vi har jobbet, hvilke utviklingsmetoder vi har benyttet oss av, prosjektets rammebetingelser og krav, utviklingsverktøy, utfordringer og problemer, samt beskrivelse av hvordan vi har løst disse. Rapporten er i hovedsak skrevet for oppdragsgiver, sensor(er), veileder, men også andre interessenter. Rapporten består av flere kapitler. For å få en helhetlig forståelse bør rapporten leses fra start til slutt. ~ 2 ~

2 Innholdsfortegnelse 1 Forord... 2 3 Innledning... 5 3.1 Om gruppa... 5 3.2 Om oppdragsgiver... 5 3.3 Bakgrunn... 5 3.3.1 «Native» applikasjoner... 5 3.3.2 Hybride applikasjoner... 6 3.3.3 Dedikert mobil web applikasjon... 6 3.3.4 Generisk mobil applikasjoner... 6 3.3.5 Sammenligning... 7 3.4 Nytt i html 5 og CSS3... 7 3.5 QR kode... 10 3.6 Baksystemer... 10 3.6.1 Trafikanten API... 10 3.6.2 Intelecom API... 10 3.7 Situasjonen i dag... 10 3.8 Mål med oppgaven... 11 4 Rammebetingelser... 11 4.1 Brukergrensesnitt... 12 4.2 Telefonens funksjoner... 12 4.3 Lokal lagring og HTML5 Manifest... 12 4.4 Sikkerhet... 12 5 Tilpassning av rammebetingelser... 13 5.1 Aksessering uten nettilgang... 13 5.2 RSS feed for avviksinformasjon... 13 6 Planlegging og metode... 13 6.1 Fremdriftsplan... 13 6.2 Arbeidsplan... 13 6.3 Milepælsplan... 14 6.4 Kommunikasjon med oppdragsgiver... 14 6.5 Utviklingsmetode... 15 6.6 Testing... 15 7 Verktøy... 16 ~ 3 ~

7.1 Utviklingsverktøy... 16 7.1.1 Notepad++ og phpdesigner 7... 16 7.1.2 FileZilla... 18 7.1.3 Firebug... 19 7.1.4 Poster... 21 7.2 Prosessverktøy... 22 7.2.1 Facebook... 22 7.2.2 Dropbox... 23 7.2.3 Gmail... 23 7.2.4 Microsoft Office Word... 23 7.2.5 Adobe Photoshop CS3... 23 7.2.6 Gliffy... 23 8 Resultat... 24 9 Kilder... 25 ~ 4 ~

3 Innledning 3.1 Om gruppa Prosjektgruppen består av fire studenter fra Anvendt Datateknologi ved HIOA bestående av Ludvig Hummelvoll Hillestad, Alexander Bakke, Gisle Bøhn Hagen og Atle Fjellang Sæther. Gruppen har jobbet sammen ved flere tidligere anledninger og kjenner derfor hverandre godt fra før. Gruppemedlemmene kjenner hverandres styrker og svakheter, noe som har gitt oss en fordel ved fordeling av arbeidsoppgaver. 3.2 Om oppdragsgiver Intelecom er en av landets ledende leverandører innenfor utvikling, integrasjon, levering og sammensetning av kommunikasjonsløsninger til bedriftsmarkedet. Intelecom Group AS har datterselskaper i Danmark, Sverige, Storbritannia og Norge, mens de i Norge har åtte avdelinger i henholdsvis Oslo, Kristiansand, Arendal, Stavanger, Haugesund, Bergen, Trondheim og Tromsø. (Intelecom, 2010) Intelecom har også implementert løsninger på mobil innenfor transportsegmentet. De har blant annet levert NSBs nye billettapplikasjon for smarttelefoner. (Intelecom, 2012) 3.3 Bakgrunn Applikasjonsutvikling kan deles opp i fire hovedkategorier bestående av «native», hybride, dedikerte, og generiske applikasjoner. Nedenfor følger en forklaring på hver av kategoriene. 3.3.1 «Native» applikasjoner Denne kategorien består av applikasjoner utviklet med et spesifikt programmeringsspråk (f.eks. Objective C for iphone, Java for Android og.net for Windows Phone). Disse applikasjonene er raske, stabile og føles som en naturlig del av telefonen med tanke på brukeropplevelse. Det er denne kategorien som i dag er mest utbredt i applikasjonsutvikling. Ulempen med denne type utvikling er at det må utvikles en applikasjon i sin helhet for hvert enkelt av operativsystemene applikasjonen skal benyttes på. Det fører igjen til at bedrifter som arbeider med utvikling må ivareta kompetanse på mange ulike programmeringsspråk og rammeverk. For å få tak i applikasjonen må brukeren som regel finne og laste ned denne via en «app store», som er en markedsplass for applikasjoner. Dette byr på utfordringer knyttet til distribusjon for bedrifter som trenger applikasjonen til en lukket brukergruppe (som f.eks. internt i et helseforetak). Slike applikasjoner må også for enkelte av operativsystemene, som ios og Windows Phone, godkjennes av operativsystemets produsent før de blir tilgjengelige for nedlastning. ~ 5 ~

3.3.2 Hybride applikasjoner Hybride applikasjoner er utviklet via et tredjeparts rammeverk (som f.eks. PhoneGap, Sencha eller Titanium). Her benytter man seg av rammeverk og utviklingsmiljøer fra leverandører hvor man som regel koder utseendet til applikasjonen som en webside. Forskjellen er at man har mulighet til å legge en «native ramme» rundt applikasjonen og via den kalle på funksjoner som f.eks. kontaktliste, kamera, kalender og lignende. Ulempen er at en slik applikasjon gjerne vil ha en annerledes brukeropplevelse enn det som forventes når man laster ned en «native» applikasjon og den krever også at utvikleren har inngående kunnskap om de enkelte plattformene for å kunne utnytte telefonens funksjoner. På samme måte som «native» applikasjoner må de hybride applikasjonene gjennom en godkjenningsprosess før de blir tilgjengelige i en «app store». 3.3.3 Dedikert mobil web applikasjon Applikasjonene i denne kategorien kjøres som en vanlig nettside på en ekstern server og tilgjengeliggjøres via mobilens nettleser. En dedikert mobil web applikasjon er skreddersydd for spesifikke operativsystemer eller telefontyper og vil ikke fungere for eldre mobile nettlesere. Ofte vil slike sider enten sperre ute de telefonene eller nettleserne som ikke støttes eller sende disse videre til en egen side tilpasset slike terminaler. Fordelen med en mobil web applikasjon er at man ikke trenger å kunne alle de ulike programmeringsspråkene og rammeverkene som er nødvendige for å utvikle en «native» applikasjon. Det er ikke mulig å distribuere slike applikasjoner via en «app store» fordi applikasjonen er et nettsted. Men dette gir i stedet en mulighet for enklere distribusjon for bedrifter med behov for lukkede brukergrupper (som f.eks. internt i et helseforetak). Rammeverk slik som jquery Mobile gjør det raskere og enklere å lage gode brukergrensesnitt på touch skjermer. En ulempe er derimot at tilgangen på telefonens hardware er svært begrenset per i dag. Det finnes muligheter for geolokasjon, men utover dette er det begrensede muligheter for å utnytte hardware knapper, kamera, kontaktlister og lignende. Det er ventet at dette skal bli langt bedre støttet i fremtiden. 3.3.4 Generisk mobil applikasjoner Dette er mobile nettsider som skal fungere på enhver mobil enhet med en nettleser. Per i dag består dette av svært tradisjonelle mobile nettsider for å vise informasjon og kan derfor knapt kalles en mobil applikasjon. ~ 6 ~

3.3.5 Sammenligning Figur 1 - Sammenlikning av ulike metoder for utvikling av mobile applikasjoner (Kilde: Worklight) Figur 1 viser en oversikt over i hvilken grad funksjoner er tilgjengelig innen de tre mest brukte metodene for utvikling av applikasjoner i dag, bestående av «native», hybride og dedikerte web applikasjoner. (Strandskogen, 2011) Vår applikasjon skal inngå i kategorien dedikert mobil web applikasjon. 3.4 Nytt i html 5 og CSS3 I HTML5, som er siste revisjon av HTML-standarden, innføres det en rekke nye elementer og funksjoner som gjør det lettere for utviklere å publisere på nett. Noen nyvinninger i HTML5 er: Innebygget støtte for lyd og video HTML5 innfører to nye elementer, video og audio, for avspilling av bilde og lyd. Bedre webskjema Tilgang på nye funksjoner som tilgjengeliggjør datovelger, interaktiv meny og validering av gyldig e-postadresse. Lokal lagring HTML5 spesifiserer en standard for lokal lagring av data hos brukeren. Tidligere har det kun vært mulig å lagre små informasjonskapsler kalt cookies. Nå er det mulig å lagre noe større datamengder. Canvas Muligheten for å definere et tegneområde med det nye CANVAS -elementet er en av de delene av HTML5-standarden som er best implementert foreløpig. Det er også den delen av standarden hvor vi kan regne med at det vil skje minst endringer før den endelige standarden foreligger. ~ 7 ~

Dokumentstruktur HTML5 har en rekke nye elementer for å strukturere websiden som f.eks ARTICLE, SECTION, HEADER, NAV, FOOTER og ASIDE. Disse er ment å erstatte den utbredte bruken av DIV elementet som vi finner på dagens websider. Et eksempel på dette vises i Figur 2 og Figur 3. (NRK, 2010) Figuren nedenfor (Figur 2) viser to nettsider med samme utseende. Siden til venstre er kodet i HTML4.01 STRICT, mens siden til høyre er kodet i HTML5. Figur 2 - Sammenligning av HTML4.01 STRICT (til venstre) og HTML5 Selv om sidene ser ut som om de er like, er kildekodene på de to sidene svært forskjellige. Figuren nedenfor (Figur 3) illustrerer mengden med kode som skal til for å generere sidene i de to HTML versjonene. HTML5 sidens kildekode er flere linjer kortere enn den tidligere revisjonen av HTML, HTML 4.01 STRICT. (Sharp, 2010) ~ 8 ~

Figur 3 - Sammenligning av HTML4.01 STRICT (til venstre) og HTML5 - koder CSS3 CSS (Cascading Style Sheet) er et språk som brukes til å definere utseende på filer skrevet i HTML. Nyvinninger i CSS3 er: Gjennomsiktige elementer Rotering av bilder Fargegradering Skyggeeffekter på skrift og elementer Animasjoner (Canvas) Avrundede hjørner (NRK, 2010) ~ 9 ~

3.5 QR kode I applikasjonen ble billettene vist som en QR- kode (Quick Response - kode). Billetten skulle kunne skannes av en kontrollør, som straks ville se om billetten er gyldig eller ikke. En QR- kode er en todimensjonal strekkode. I strekkoden kan det lagres alt fra tall til japanske bokstaver som hvem som helst kan lese ut med kameraet på en smarttelefon. (Rockberry, 2011) 3.6 Baksystemer Figur 4 - QR- kode API (Application Programming Interface) er et grensesnitt for kommunikasjon mellom programvare. Et API fungerer som en regelbok for forespørsler til applikasjonen. (Wikipedia, 2012) 3.6.1 Trafikanten API Alle data i applikasjonen som har med trafikkinformasjon kom fra Trafikantens API. Gruppen benyttet Trafikantens API til å skrive ut resultatet av brukerens stasjonssøk, samt informasjon som ruteforslag, stasjoner i nærheten, reisetid og transportmiddel. 3.6.2 Intelecom API Oppgradsgiver opprettet et API som skulle brukes til å lagre kundedata, billettbestillinger og selve billettene. 3.7 Situasjonen i dag Per i dag utvikles de aller fleste mobilapplikasjonene «native». Denne metoden er både tidsog ressurskrevende fordi det må kodes en versjon for hver enkelt av plattformene hvor applikasjonen skal brukes. Prosjektgruppa skal derfor, på oppdrag fra Intelecom, finne ut om en dedikert mobil web applikasjon er et reelt alternativ til native utvikling. HTML5 er en standard som fremdeles er under utvikling. Den inneholder mange nye funksjoner som tilbyr blant annet lokal lagring, «offline» aksessering av data og element tager for nytt og forbedret utseende. Ved hjelp av disse funksjonene skal gruppen i løpet av prosjektperioden finne ut om HTML5 er et reelt alternativ til «native» koding, spesielt med tanke på sikkerhet. (Wikipedia, 2012) ~ 10 ~

3.8 Mål med oppgaven Målet med oppgaven var å utvikle en prototype av en dedikert mobil billettapplikasjon ved hjelp av HTML5, CSS3, PHP og JavaScript. (Intelecom, 2012) Resultatmål Utvikle en prototype på en mobil billettapplikasjon i HTML5. Prototype og dokumentasjon skal leveres 30. mai 2012 til arbeidsgiver og HIOA Billetter skal krypteres og lagres lokalt Nærmeste fem stasjoner skal skrives ut ved hjelp av geolokasjon Vise billetter i frakoblet modus Holde arbeidsgivers tidsfrister og krav Effektmål Økt kunnskap om webapplikasjonsutvikling og tilhørende rammeverk som jquery Lære å samarbeide med en profesjonell aktør 4 Rammebetingelser Oppdragsgiver ønsket at applikasjonen skulle inneholde: En side for registrering av fornavn, etternavn, e-post og passord En side med innstillinger som lar brukeren administrere valg knyttet til applikasjonen (informasjon om bruker og applikasjon, samt slette bruker) Mulighet til å finne og kjøpe en bestemt reise. Billetten skal vises som en QR- kode. Vise kjøpte billetter Applikasjonen skulle fungere på følgende plattformer: ios (iphone / ipad) OS versjon 4 og nyere Android OS versjon 2.2 og nyere Windows Phone 7 Versjon 7.5 (Mango) og nyere Applikasjonen skal ha spesielt fokus på fire områder som anses som utfordringer i en dedikert web applikasjon: Brukergrensesnitt Telefonens funksjoner Lokal lagring Sikkerhet Nedenfor følger mer informasjon om disse områdene. (Se vedlegg X) ~ 11 ~

4.1 Brukergrensesnitt Applikasjonen skal ha et brukergrensesnitt som fungerer godt for de tre primære plattformene som er utbredt i Norge: ios (iphone og ipad), Android og Windows Phone 7. Ved hjelp av Java biblioteket jquery Mobile skal det vises hvilke muligheter en dedikert web applikasjon har for å gjøre tilpasninger til operativsystemet som brukeren kommer fra. Spesielt med tanke på generell «look and feel» eller spesifikke kontrollere, som for eksempel egne datovelgere for de ulike operativsystemene. 4.2 Telefonens funksjoner I Applikasjonen, hvor brukeren velger avreisestasjon, skal det implementeres geolokasjon. Geolokasjon er en funksjon som tar for seg mobiltelefonens geografiske posisjon ved hjelp av et JavaScript bibliotek. Dette gjøres ved å finne mobilens koordinater ved hjelp av WIFI signaler. Med utgangspunkt i disse koordinatene skal gruppen benytte Trafikantens API og finne de fem holdeplassene som er nærmeste brukerens posisjon. 4.3 Lokal lagring og HTML5 Manifest For en billettapplikasjon er det kritisk at bruker har tilgang til visse deler av innholdet, spesielt billetten, om man befinner seg på steder uten mobil dekning. Med lokal lagring er det mulig å lagre billetter, bruker- og reiseinformasjon i telefonens nettleser, samt hente det ut igjen. Det skal ikke være mulig å kjøpe nye billetter uten nettilgang, men allerede kjøpte billetter skal kunne vises. Oppdragsgiver ville ha HTML5 Manifest implementert i applikasjonen slik at det skulle være mulig å se kritiske data (billettene) i frakoblet modus. Manifest gjør at sider kan aksesseres uten nettilgang. (Wikipedia, 2012) 4.4 Sikkerhet Applikasjonen skal benytte seg av lokal lagring. Innholdet i denne databasen skal være sikret på en slik måte at det ikke er rett frem å hente ut innholdet og derfor må billettene krypteres før de lagres. JavaScript kodene skal obfuskeres(gjøres uleselig) slik at kildekodene ikke kan leses av andre. ~ 12 ~

5 Tilpassning av rammebetingelser Det viste seg etter hvert at det var mer å sette seg inn i enn det gruppen i utgangspunktet hadde trodd og at det dermed ikke var nok tid til å innfri alle oppgavene som ble gitt av oppdragsgiver. Det ble derfor nødvendig å gjøre tilpassninger av oppgaven. Nedenfor følger en forklaring på disse tilpassningene. 5.1 Aksessering uten nettilgang HTML5 manifest, som gjør at deler av applikasjonens sider lagres lokalt på brukerens telefon, skulle benyttes. Prosjektgruppen prøvde å bruke denne funksjonen på skolens server, men innstillinger og regler på skolens nettverk hindret lagring av sider. Etter å ha brukt mye tid på å få applikasjonens kritiske deler til å fungere uten nettilgang ble det derfor bestemt at andre funksjoner var viktigere å prioritere og at gruppen måtte gå bort fra kravet om HTML5 Manifest. 5.2 RSS feed for avviksinformasjon RSS feed var i utgangspunktet utenfor prosjektets rammer, men gruppen ønsket å lære mer om denne typen kommunikasjon og valgte derfor å implementere det i applikasjonen. Prosjektgruppen valgte å benytte seg av Trafikantens offentlige RSS feed (Really Simple Syndication) som nyheter eller materiale fra Internet fortløpende og automatisk. Trafikantens RSS tilbyr daglig oppdaterte meldinger om avviksinformasjon om kollektivtransporttilbudet på Østlandet. 6 Planlegging og metode 6.1 Fremdriftsplan Fremdriftsplanen ble laget for å holde oversikt over arbeidsoppgaver og tidsfrister. Det var viktig å lage en fremdriftsplan med realistiske tidsfrister, spesielt fordi gruppen ikke hadde så mye erfaring med så store prosjekter. Planen ble delt opp i tre deler, bestående av aktiviteter, møter og milepæler. Den ble kontinuerlig fulgt opp for å ha en oversikt over hvor mye tid som var igjen innen hver aktivitet. Planen ble oppdatert ofte for å opprettholde fremgangen i prosjektet. (Difi, 2010) For fremdriftsplan, se vedlegg 1 A. 6.2 Arbeidsplan Arbeidsplanen ble laget for å beskrive ansvarsfordelingen av oppgaver gjennom prosjektperioden og gi gruppens medlemmer en oversikt over hva de andre gruppemedlemmene arbeidet med. Applikasjonen inneholder så mange separate funksjoner at arbeidsplanen var svært viktig for utførelsen av prosjektet. Arbeidsplanen har blitt kontinuerlig oppdatert gjennom hele prosjektet. Oppgavene ble fordelt slik at hver og en hadde hovedansvaret for gjennomføringen av hver sin del av oppgaven. (Utdanningsforbundet) ~ 13 ~

For arbeidsplan, se vedlegg 1 B. 6.3 Milepælsplan For å ha en oversikt over milepælene i prosjektet ble det laget en milepælsplan. Milepælsplanen beskrev gruppens interne mål for prosjektet. Gruppen valgte å dele opp prosjektet i fem hovedmilepæler. Disse inneholdt blant annet tidsfrister for ferdigstillelse av funksjonalitet, fullført implementering og rapportskrivning. Milepælsplanen ble brukt svært ofte i gruppens daglige møter for å ha en oversikt over fremgangen i forhold til de interne fristene gruppen hadde satt. Planen var et fint redskap for gruppen. Noen av gruppens frister måtte flyttes underveis i prosjektet. Det skyldtes enten feil estimering av tid på aktiviteten eller innleveringer i semesterets andre fag. (Difi, 2011) For fullstendig milepælsplan, se vedlegg 1 C. 6.4 Kommunikasjon med oppdragsgiver Figur 5 - Milepælsplan Prosjektgruppen og oppdragsgiver hadde jevnlig kontakt helt fra starten av prosjektet. I tillegg til e-postkorrespondanse ble det holdt møter mellom representanter fra oppdragsgiveren og prosjektgruppen. Møtene ble brukt til å vise hva som hadde blitt gjort og hvilke utfordringer gruppen sto ovenfor. Oppdragsgiver innehar mye kompetanse på de feltene gruppen sto fast, og kunne derfor tilby hjelp og veiledning de gangene det var behov for det. Gruppen opprettet en egen e-post bruker hos Gmail for å forenkle kommunikasjonen med oppdragsgiver. Samarbeidet bygget på tillit ved at gruppen tok kontakt om de sto fast eller trengte faglig veiledning. Dette samarbeidet fungerte godt og ga gruppen rom til selv å styre egne interne frister og arbeidstider. ~ 14 ~

6.5 Utviklingsmetode Vi bestemte oss tidlig i prosjektet for at vi ønsket å bruke en iterativ utviklingsmetode, som betyr at det hele tiden arbeides med å videreutvikle forrige versjon fremfor å forkaste og starte forfra. Vi valgte derfor å bruke en tilpasset versjon av utviklingsrammeverket Scrum. Dette rammeverket brukes ofte der utvikling av komplekse informasjonssystemer står i sentrum. Modellen baserer seg på faser med lengde fra en uke og helt opp til en måned. Hver fase kalles en sprint. For hver sprint blir det satt krav til hva som skal implementeres i løpet av perioden slik at man har klare mål til neste sprint skal påbegynnes. Prosjektgruppen gjennomførte daglige møter slik at hver og en fikk en oversikt over hvordan det gikk med de forskjellige arbeidsmålene. Samtidig ga dette gruppemedlemmene en mulighet til å ta opp problemer og utfordringer som krevde en samlet avgjørelse. Gruppa utnevnte en Scrum Master før hvert møte som skulle fungere som en ordstyrer og sørge for at alle på gruppa besvarte tre viktige spørsmål: Hva var gjort siden forrige Scrum møte? Hva skulle gjøres før neste møte? Hva hadde (eventuelt) vært til hinder for at gruppemedlemmet var effektivt i implementeringen av funksjonalitet? (Wikipedia, 2012) Det var tidlig klart at programmeringsdelen av prosjektet var stor. Gruppen ble gitt en konkret kravspesifikasjon med mange funksjoner prosjektgruppen ikke hadde kjennskap til fra før. Vi valgte derfor og ikke å bruke så mye tid på UML modellering verken i starten eller i prosjektet forøvrig. Vi hadde en konkret plan alle gruppemedlemmene var inneforstått med og kunne raskt fordele og begynne på programmeringen. E/R modellering er også naturlig utelatt fordi det ikke skal opprettes en database i løpet av prosjektet. 6.6 Testing Tester på applikasjonen ble utført fortløpende slik at man kunne sikret at det som hadde blitt utviklet fungerte slik det skulle på alle plattformene. Det ble gjort tester på forskjellige mobile enheter slik at man kunne se hvordan applikasjonen ble seende ut på ulike skjermstørrelser. Applikasjonen skulle kunne fungere på plattformene som var spesifisert i rammebetingelsene og det var derfor viktig at testingen ble utført på telefoner med Android, ios og Windows operativsystem. Ved å utføre disse testene avdekket gruppen feil og mangler i applikasjonen som måtte ordnes. ~ 15 ~

7 Verktøy Fra prosjektets start i januar til prosjektets slutt i mai benyttet gruppen seg av ulike verktøy for utvikling, dokumentasjon og planlegging. Oppdragsgiver hadde ingen ønsker eller krav til hvilke verktøy som skulle brukes. Prosjektgruppen valgte derfor utviklingsverktøy de kjente til fra før. 7.1 Utviklingsverktøy Nedenfor følger en kort beskrivelse av de verktøy prosjektgruppen har benyttet seg av. 7.1.1 Notepad++ og phpdesigner 7 Både Notepad++ og phpdesigner 7 er PHP-, HTML-, CSS- og JavaScripteditorer som er laget for å forenkle programvareutviklingen for programmerere. phpdesigner 7 er et praktisk utviklingsverktøy som inneholder hjelpefunksjoner som f.eks. autocomplete og tekstfarge ut ifra hvilken datatype teksten er. Programmet kan håndtere flere dokumenter samtidig ved å plassere de i faner. Øverste delen av programmet inneholder verktøylinjer med funksjoner for testing, analyse og utvikling. Figur 6 - Skjermdump av phpdesigner 7 ~ 16 ~

Notepad++ er bygget opp på samme måte som phpdesigner 7. Øverste delen av programmet består av verktøylinjer med forskjellige utviklingsverktøy. Også Notepad++ kan håndtere flere dokumenter samtidig. Ved hjelp av faner, vil det til enhver tid være et ryddig skjermbilde. Figur 7 - Skjermdump av Notepad++ Det at programmene var såpass like gjorde at gruppen ikke ville ha noe krav til valg av utviklingsverktøy. Det ble derfor opp til hvert enkelt gruppemedlem å benytte seg av det verktøyet de foretrakk. ~ 17 ~

7.1.2 FileZilla FileZilla er en FTP- klient som ble benyttet til publisering av applikasjonen på Internet. Programmet ble brukt til å overføre applikasjonens filer fra gruppemedlemmets datamaskin til skolens webserver. Figur 8 viser et skjermdump av FileZilla. Til venstre i skjermbildet vises filtreet til datamaskinen programmet er installert, mens høyre side viser filene som ligger på gruppemedlemmets område på skolens webserver. Øverst i bildet må brukeren logge inn på serveren for å kunne begynne overføringen. Figur 8 - Skjermdump av FileZilla ~ 18 ~

7.1.3 Firebug Firebug er et webutviklingsverktøy installert som et programtillegg i nettleseren. Programmet lot gruppen feilsøke kildekode fortløpende. Kildekodene kunne endres i nettleseren, for så å se hvordan ting ble endret før kodene ble endret lokalt. Dette sparte gruppen for mye tid som ville blitt brukt om filene måtte lastes opp hver gang de skulle testes. (Firebug) Figuren nedenfor (figur 9) viser hvordan sidens kildekode kan vises i Firebug. Disse kodene kan endres og endringene vil straks vises på siden. Figur 9 - Skjermdump av Firebug ~ 19 ~

Firebug inneholder også en JavaScript konsoll (figur 10) som viser feil i koden som kjøres. Denne funksjonen har gruppen benyttet seg av mye gjennom prosjektet. JavaScript gir ofte ingen eller dårlige feilmeldinger, så et slikt utviklingsverktøy forenkler feilsøkingsjobben svært mye for utvikleren. Figur 10 - Skjermdump av konsollen i Firebug ~ 20 ~

7.1.4 Poster Poster ble brukt i starten av prosjektet til å se om det var mulig å koble seg opp mot oppdragsgivers API og se at alt fungerte slik det skulle. Poster er et programtillegg i Firefox som er laget for å kunne kommunisere med webtjenester. Det kan blant annet simulere en HTTP forespørsel mot et API (Figur 11) og vise resultatet av spørringen (Figur 12). (Mozilla) Figur 11 - Poster - Forespørsel mot API ~ 21 ~

Figur 12 - Poster - Kvittering 7.2 Prosessverktøy Nedenfor følger en kort beskrivelse av de prosessverktøy prosjektgruppen har benyttet seg av i løpet av prosjektperioden. 7.2.1 Facebook På Facebook ble det opprettet en hemmelig gruppe slik at kun gruppens medlemmer hadde tilgang til informasjonen som ble lagt ut. Der ble det utvekslet informasjon om tidspunkter og oppmøtesteder relatert til prosjektet, som f.eks. møter med oppdragsgiver eller veileder. Gruppen ble også benyttet til utveksling av korte koder og dokumentasjon. Denne gruppen fungerte samtidig som et kommunikasjonsverktøy de tidene gruppen ikke arbeidet sammen på skolen. ~ 22 ~

7.2.2 Dropbox Dropbox er programmet gruppen brukte til å synkronisere filer mellom flere datamaskiner. I stedet for å sende filer til seg selv med e-post eller bære det med seg på en minnepenn legges filene på en ekstern server hele gruppen har tilgang til. Gruppen brukte Dropbox til deling av bilder, dokumenter, kildekoder og notater. Programmet ble brukt til daglig sikkerhetskopiering av koder og dokumenter og ga gruppen mulighet til å gå tilbake til tidligere versjoner om det var behov for det. Spesielt i situasjoner hvor det ble problemer med kodene var det nyttig å kunne gå tilbake til tidligere sikkerhetskopier som fungerte. 7.2.3 Gmail For at hele gruppen skulle ha tilgang til all informasjon og alle avtaler med oppdragsgiver, veileder og andre involverte i prosjektet ble det opprettet en e- post bruker hos Gmail. Gruppen ble enig om et passord slik at all e-post var tilgjengelig for de som trengte tilgang. Denne e-post brukeren var spesielt praktisk ved prosjektstart fordi oppdragsgiver ga informasjon om hvordan baksystemet var bygget opp. 7.2.4 Microsoft Office Word Microsoft Office Word er et tekstbehandlingsprogram som ble brukt til å skrive dokumentasjon som prosjektrapporten, møtereferater og dagbok. 7.2.5 Adobe Photoshop CS3 Adobe Photoshop CS3 er et bilderedigeringsprogram. Det ble brukt til å designe og utforme elementer som knapper, ikoner og bilder som skulle brukes i applikasjonen. 7.2.6 Gliffy Gliffy er et nettbasert verktøy som gjør det mulig å lage diagrammer, flytskjemaer og tegninger. Det ble brukt i prosjektet som et verktøy for å lage UML diagrammer som use case og Aktivitetsdiagram. (Gliffy) ~ 23 ~

8 Resultat Gruppen er fornøyd med resultatet av prosjektet. Arbeidet har vært utfordrende og spennende og resultert i en dedikert mobil web applikasjon i HTML5. Prosjektet har vært lærerikt både med tanke på de faglige utfordringene knyttet til selve utviklingen av produktet, men også samarbeidsprosessen med oppdragsgiver. Det er første gang gruppen har utført et reelt oppdrag gitt av en ekstern bedrift, noe som har gitt gruppen verdifull erfaring. Oppdragsgiver har gjennom hele prosjektet gitt konstruktive tilbakemeldinger på produktet og vært behjelpelig om gruppen har ønsket faglig veiledning. Prosjektet har resultert i økt kompetanse for gruppen. Utførelsen av prosjektet krevde at gruppen måtte sette seg inn i nye funksjoner og rammeverk som f.eks. json, jquery, lokal lagring, geolokasjon og programmering mot API. Gruppen hadde kjennskap til programmeringsspråkene som ble benyttet i applikasjonen fra tidligere, men prosjektet har gitt større innsikt i mulighetene knyttet til denne typen programmering. Gruppen har tilegnet seg faglig kunnskap om webapplikasjonsutvikling som vil være nyttig å ta med seg videre ut i arbeidslivet. ~ 24 ~

9 Kilder Difi. (2010, 12 16). www.anskaffelser.no. Retrieved 2012, from http://www.anskaffelser.no/strategi/anskaffelsesstrategi/oppstart/utarbeide-fremdriftsplan Difi. (2011, 12 01). www.anskaffelser.no. Retrieved from http://www.anskaffelser.no/strategi/dokumenter/milepaelsplan Firebug. (n.d.). getfirebug.com. Retrieved 2012, from http://getfirebug.com/whatisfirebug Gliffy. (n.d.). gliffy.com. Retrieved 2012, from http://www.gliffy.com/about-us/ html5media. (n.d.). html5media.info. Retrieved 2012, from http://html5media.info/ Intelecom. (2012, 02 02). Intelecom nsb mobilapplikasjon. Retrieved 2012, from http://www.intelecom.no/default.aspx?m=6&amid=11338 Intelecom. (2010, 03 25). Nettside om Intelecom. Retrieved 2012, from http://www.intelecom.no/article.aspx?m=14&amid=2404 Intelecom. (2012, 01 23). Prosjektbeskrivelse. Oslo: Intelecom. Mozilla. (n.d.). addons.mozilla.org. Retrieved 2012, from https://addons.mozilla.org/en- US/firefox/addon/poster/ NRK. (2010). nrkbeta.no. Retrieved 2012, from http://nrkbeta.no/2010/01/22/litt-om-html5-og-kva-det-betyrfor-nrk/ Rockberry. (2011, 06 23). www.detmektigeintet.no. Retrieved 2012, from http://www.detmektigeintet.no/2011/06/hva-er-egentlig-en-qr-koder-og-hva-skal.html Sharp, R. L. (2010). Introducing HTML5. New Riders forlag. Strandskogen, N. K. (2011, 03 22). iallenkelhet.no. Retrieved 2012, from http://iallenkelhet.no/2011/03/22/app-eller-webapplikasjon/ Utdanningsforbundet. (n.d.). www.utdanningsforbundet.no. Retrieved 2012, from http://www.utdanningsforbundet.no/upload/bedre%20skole/bs_nr_3_10/dalland_og_bergem_bedreskole-3-10.pdf Wikipedia. (2012, 03 12). en.wikipedia.org. Retrieved 2012, from http://en.wikipedia.org/wiki/cache_manifest_in_html5 Wikipedia. (2012, 04 09). no.wikipedia.org. Retrieved 2012, from http://no.wikipedia.org/wiki/api_(programmering) Wikipedia. (2012, 05 18). no.wikipedia.org. Retrieved 2012, from http://no.wikipedia.org/wiki/html Wikipedia. (2012, 05 14). no.wikipedia.org. Retrieved 2012, from http://no.wikipedia.org/wiki/scrum ~ 25 ~