Del 1: prosessdokumentasjonstudent.cs.hioa.no/hovedprosjekter/data/2012/13/P... · Kristiansand,...
Transcript of Del 1: prosessdokumentasjonstudent.cs.hioa.no/hovedprosjekter/data/2012/13/P... · Kristiansand,...
Hovedprosjekt 2012 - Gruppe 13
~ 1 ~
Del 1: prosessdokumentasjon
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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