Projektrapport HejKalmar app Webbprojekt I Författare: Cecilia Lindqvist, Linus Lundevall, Christofer Olaison, Andreas Söderström och Isak Utegård Handledare: Tobias Ohlsson Examinator: Tobias Ohlsson Termin: VT13 Ämne: Datavetenskap
Nivå: Grundkurs Kurskod: 1DV411 Abstrakt Post Mortem av HejKalmar.se s mobilapplikation. Ett 10 veckors studentprojekt där vi utvecklad en mobilapplikation med hjälp av ramverken Phonegap och Backbone.js mot Drupal back end. I den här rapporten förklarar vi vad som gick bra och dåligt och vad vi ska börja, fortsätta och sluta med nästa gång.
Innehållsförteckning Abstrakt 1 Innehållsförteckning 2 1 Inledning 3 2 Syfte 3 2.1 Mål 3 3 Genomförande/Teknik 4 3.1 MVC Javascriptramverk 4 3.2 Ramverk för mobilaapplikationer 4 3.3 Drupal 4 3.4 Sprintplanering 4 4 Resultat 5 4.1 Avikelser 5 4.2 Testning 5 4.3 Dokumentation 5 5 Slutsats 6 5.1 Positiva erfarenheter 6 5.2 Negativa erfarenheter 6 5.3 Möten 7 5.4 Tidsplanering 5.5 Vidareutveckling 7
1. Inledning HejKalmar.se är en webbapplikation som är ett resultat av en satsning av Linnéstudenterna och Kalmar kommun att få studenterna närmre näringslivet i Kalmar och locka dem att stanna kvar. På HejKalmar.se hittar man evenemang, smultronställen och artiklar som intresserar studenter. Vi fick i uppdrag av Wilson Creative att skapa en mobil applikation för HejKalmar.Wilson Creative är utvecklaren bakom webbapplikationen har i sin tur Kalmar kommun och Linnéstudenterna som slutkund och de vill se en applikation som bryggar bryggan i brypplikationen skulle vara utformad för att fungera på de vanligaste mobila operativsystemen och vara tillgänglig på App Store vid slutleverans.
2 Syfte Projektets syfte ligger i att få fler studenter i Kalmar kommun att vilja interagera med näringslivet i staden och att få studenterna att vilja stanna kvar i Kalmar även efter sina studier. Kommunen i samarbete med Linnéstudenterna vill ha en digital samlingsplats för studenterna att dela och ta del av information om händelser som sker inom Kalmars gränser. 2.1 Mål Vi fick i uppdrag att skapa en mobilapplikation för Kalmars studenter och målet med projektet var att vid slutleverans kunna lämna över en vältestad applikation, med en stor vikt på den tillhörande dokumentationen. Applikationen skulle ha en event flöde där man kan se events som sker i Kalmar. De events som visas i flödet ska vara filtrerade så att enbart de events som finns publicerade på hejkalmar.se och inte har ägt rum visas. Det skulle även skapas en vy för att ge användaren av applikationen möjlighet att själv lägga upp ett event. För att göra applikationen mer personlig ville Wilson Creative att det i samband med skapandet av ett nytt event även skulle gå att lägga till en bild tillhörande eventet. Utöver event flödet och skapandet av nya events skulle en del av applikationen bestå av information från Linnéstudenterna. Man ville att de nyheter som kom från Linnéstudenternas RSS skulle visas i ett flöde i applikationen samt ha en karta för att visa de sevärda, så kallade smultronställen som finns i Kalmar.
3 Genomförande och teknik 3.1 MVC Javascriptramverk Till det här projektet ville vi strukturera upp vår javascript kod i en mvc struktur och började leta efter ett passande bibliotek eller ramverk. Först hittade vi ember.js men vi gick rätt snabbt över till backbone.js, då vi ansåg att detta ramverk hade en lägre inlärningskurva och var bättre dokumenterat. 3.2 Ramverk för mobila applikationer Ett av målen för projektet var att applikationen skulle kunna fungera till många olika operativsystem. Vi valde därför att arbeta med javascript biblioteket Phonegap som gör det möjligt att skriva javascriptkod som Phonegap översätter till de olika operativsystemen. 3.3 Drupal Baksidan till den mobila applikationsdelen som vi hämtar data ifrån är uppbyggt med cms/cmf systemet drupal. I drupal finns en modul som heter views och med hjälp av denna kan man skapa ett restful API för att hämta ut data via asynkrona http anrop. 3.4 Sprintplanering Tidsplanering och arbetsfördelning har utförts med hjälp av ett gemensamt excel dokument. Där har varje vecka/sprint delats upp med arbetsuppgifter, Tidsåtgång, risk och prioritet. Under arbetets gång fyller vi projektdeltagare i de timmar som vi spenderat med olika arbetsuppgifter. Vid slutet av projektet kan allt sammanställas för utvärdering.
4 Resultat 4.1 Avvikelser Funktionen för användare att skicka in tips om evenemang till en redaktion på hejkalmar finns i mobilapplikationen. Dock har inte funktionalitet på servern implementerats för att kunna ta emot denna typ av data. Linnéstudenterna önskade någon form av funktionalitet för studentrabatter, men det fanns ingen back end för att serva appen med den här informationen tillgänglig och kravet kom in för sent i utvecklingen av applikationen. 4.2 Testning Under utvecklingsprocessen av applikationen så är det mycket kontinuerlig testning för att se att applikationen reagerar på ett önskevärt sätt. Så fort en ny funktionalitet har implementeras har vi gjort tester i webbläsare och även med hjälp av ios emulatorn paketerad med XCode. 4.3 Dokumentation Det har kontinuerligt skrivits dokumentation för applikationen på en wikisida (http://www.linuskarlsson.se/hejkalmarprojekt). Där har vi skrivit upp vad vi får för informtaion från API:et och vad för information vi skickar till API.et vid exempelvis anrop till event sidan. I ett exeldokument har vi varje vecka fyllt i planeringen för kommande veckas sprint. Dokumentet inehåller krav, prioritet och uppskattning av tid. Löpande har vi fyllt i de faktiska tider vi har arbetat med de olika kraven för på så vis få en uppfattning om hur mycket tid var och en har lagt på de olika delarna under projektet.
5 Slutsats 5.1 Positiva Erfarenheter Efter projektets gång har vi lärt oss hur viktigt det kan vara att i ett så tidigt skede som möjligt få en klarhet över vad som förväntas av oss som utvecklare och hur vi ska kunna möta kundens krav. Och för att uppfylla detta så skulle det kunna vara en bra idé att exempelvis skriva ett kontrakt på vad som ska lämnas in vid projektets slutleverans. Detta för att minska risken att i sista sekund få extra implementationer och på det viset inte kunna hålla sin deadline. Det är även viktigt att om man, som i vårt fall, har slutkunden i två nedgående steg, att då tidigt ta kontakt med även dessa personer och kunna samla alla inblandade i ett gemensam möte för att nysta ut problem. För det händer att de båda parterna säger olika saker i form av krav. Så det gäller att göra så mycket man kan för att minimera riskerna för missförstånd. Det har även varit lärorikt att få sätta sig in ett nytt ramverk. Att bena ut svårigheterna med att kanske implementera vissa funktioner nr det ska gå igenom ett ramverk först. Men efter inlärningskurvan så går det betydlig smidigare och fortare att göra saker då ramverket gör mycket åt en. 5.2 Negativa Erfarenheter Vi hade HejKalmar som kund och de i sin tur hade både Linnéstudenterna och Kalmar kommun som sina kunder. Detta gjorde att det blev svår kommunicerat i mellan alla parter och inte förrän i iteration 7 (2 veckor innan deadline), fick vi träffa en av slutkunderna och ha möte med dem om deras förväntningar. Det mötet var minst sagt ett nedslag för Linnéstudenterna. Som hade velat vara mer involverade från början. Men som vi fick det beskrivet för oss utav Wilson Creative inte var en hög prioritet. Vilket vi senare fick reda på var en sned syn på själva uppdraget då Linnéstudenterna är huvudkunden. Den andra slutkunden Kalmar kommun har vi inte varit i kontakt med överhuvudtaget. Men detta har lärt oss att i ett tidigt skede få kontakt med alla inblandade och få en egen syn på vilka krav som är viktigast att uppfylla. Att ha flera kunder i olika nedgående led kan resultera i långa väntetider på svar av viktiga frågor. Som i sin tur leder till förseningar. För att undvika detta så gäller det att även identifiera risker med perspektivet av hur mycket vi behöver från kunden, om en funktion är starkt beroende på att kunden motpresterar så måste det angripas tidigt. Se till att få fram viktiga frågor så tidigt som möjlig och få svar på dem så detta inte skapar hinder i en senare period av arbetet. Att sätta sig in i ett nytt ramverk kan även vara roligt och lärorikt, men det är även tidskrävande. Vi satte oss först in i ember.js, men efter 1 2veckors inlärning och testning så kom vi fram till att den hade en för lång inlärningskurva, var för tidig i sin utveckling och dokumentation var dålig. Detta
gjorde att vi tappade nästan 2 veckor när vi gick över till backbone.js. Vi skulle utveckla en mobilapp för iphone, android och windows phone. Men i de sista iterationsveckorna beslutade vi för att inte implementera till windows phone. För den hade för dåligt stöd av funktioner som vi behövde använda oss av och gjorde att det skulle ta alldeles för lång tid att implementera för just den här sortens operativsystem. Plus att vi inte hade någon testmiljö för den och att som utvecklare var man tvungen att skriva olika för olika windows telefoner. Detta gjorde att windows phone slopades och mycket av den tiden som gick åt för att få med windows phone kunde lagts på annan funktionalitet istället. 5.3 Möten Interna möten har fungerat bra och handledningsmötena har varit bra för att kunna summera varje iteration och titta på kommande. Möten med klient fungerade sämre mot slutet av projektet, då motprestation och intresse kändes vagt från klientens sida så fortsatte vi arbeta när vi inte fick svar. I iteration 6 fick vi träffa en projektplanerare på Wilson Creative som ville att vi skulle blanda in Linnéstudenterna snarast och lovade ett snabbt möte redan samma vecka. Mötet hände först i slutet av nästa iteration. 5.4 Tidsplanering Under projektet har vi inte stött på några direkta problem med tidsåtgång i förhållande till vår planering. Våra riskbedömningar kontra prioritet har i de flesta fall gett oss en bra bakgrund till hur vi lagt upp vårt arbete. Den stora flaskhalsen som har bromsat projektet är bristande leveranser av kunden. Vissa funktioner har legat på deras ansvar men eftersom de inte har levererat viss funktionalitet som vi har behövt har det bromsat en del av utvecklingen. 5.5 Vidareutveckling Det finns intresse från linnéstudenterna att fortsätta utvecklingen av denna applikation. Problemet verkar vara resurser och därför vill de att fler studentprojekt ska bidra till utvecklingen. Vi i projektgruppen har inga planer att fortsätta med projektet under kommande examensarbeten.