del 1: prosessdokumentasjonstudent.cs.hioa.no/hovedprosjekter/data/2012/13/p... · kristiansand,...

Hovedprosjekt 2012 - Gruppe 13

~ 1 ~

Del 1: prosessdokumentasjon


~ 2 ~

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.


~ 3 ~

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


~ 4 ~

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


~ 5 ~

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.


~ 6 ~

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.


~ 7 ~

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.


~ 8 ~

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)


~ 9 ~

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)


~ 10 ~

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)

Figur 4 - QR- kode

3.6 Baksystemer

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 tids-

og 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)


~ 11 ~

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)


~ 12 ~

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.


~ 13 ~

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)


~ 14 ~

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)

Figur 5 - Milepælsplan

For fullstendig milepælsplan, se vedlegg 1 C.

6.4 Kommunikasjon med oppdragsgiver

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.


~ 15 ~

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.


~ 16 ~

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


~ 17 ~

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.


~ 18 ~

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


~ 19 ~

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


~ 20 ~

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


~ 21 ~

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


~ 22 ~

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.


~ 23 ~

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)


~ 24 ~

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.


~ 25 ~

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-betyr-

for-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

del 1: prosessdokumentasjonstudent.cs.hioa.no/hovedprosjekter/data/2012/13/p... · kristiansand,...

Documents