Mighty. Mobilapplikation för evenemang

Transkript

1 Mighty Mobilapplikation för evenemang Slutrapport: Mjukvaruutvecklingsprojekt i Grupp Författare: Simon Palmqvist & Pepyn Swagemakers Lärosäte: Linnéuniversitetet Kurs: 1DV611 Handledare: Tobias Ohlsson Datum: 9 juni 2017

2 Sammanfattning Mighty HB är en eventbyrå som organiserar evenemang i Kalmar med omnejd. Via Drivhuset hade de annonserat ut sitt behov av utveckling av en mobilapp för att kunna marknadsföra sig via ytterligare en kanal och sprida information om de evenemang som dem arrangerar. Inom ramen för kursen 1DV611 - Mjukvaruutvecklingsprojekt i grupp har vi under den andra perioden på vårterminen 2017 jobbat med att utveckla denna applikation. För att kunna lösa kundens behov valde vi att skapa en mobilapplikation för ios som med vidareutveckling också kan fungera för Android tillsammans med ett webbgränssnitt där nya evenemang kan läggas till. I projektet har vi arbetat iterativt utefter Unified Process och planerat vårt arbete vecka för vecka under de nio veckor projektet fortlöpte. Den här rapporten går in i detalj på hur vi arbetat, vilka verktyg och metoder som använts samt de slutsatser och lärdomar vi har tagit med oss efter projektet.

3 Innehållsförteckning Sammanfattning Innehållsförteckning Inledning Bakgrund Syfte och mål Projektorganisation Genomförande Metodik Kravspecifikation Teknik Mobilapplikationen Backend-as-a-Service Web-gränssnittet Resultat Implementering av applikationen Dokumentation Grupparbete Analys och bemötande av risker Färdigställande och leverans Slutsats Applikationens framtid Övertagande organisation Vidareutveckling av applikationen Litteratur och dokumentation Bilagor Bilaga 1: Bilaga 2:

4 Inledning Bakgrund Projektet genomförs som en del av kursen 1DV611 - Mjukvaruutvecklingsprojekt i grupp vid Linnéuniversitetet. Via Drivhuset i Kalmar har eventbyrån Mighty HB annonserat sitt behov av att få en mobilapplikation utvecklat till sitt företag. Tre studenter från utbildningen Webbprogrammerare vid Linnéuniversitetet har tagit sig an detta uppdraget. Mighty HB vill ha en mobil-app att använda i sin marknadsföring av sina evenemang, men är i övrigt öppna och flexibla gällande implementation. Applikationskoncept, plattformar och begränsningar beslutas under utvecklingsprocessen i samråd mellan utvecklingsteamet och Mighty HB. Syfte och mål Syftet med projektet är främst att, utifrån projektvisionen, ta fram en mobilapplikation åt Mighty HB. Syftet är även att ge oss studenter en möjlighet att sätta sig in och lära sig nya tekniker. Fokus kommer ligga på att lära sig mobilapplikation-utveckling med Javascript samt integration med de APIer som Facebook och Instagram tillhandahåller. Projektet genomförs i och med kursen Mjukvaruutvecklingsprojekt i grupp (1DV611) vid Linnéuniversitetet. De mål som är uppsatta i kursplanen är: att lära sig följa en standardiserad modell för mjukvarauutveckling genomföra projekt i grupp föra vedertagen projektdokumentation kritiskt granska andra projekt och dokumentation kunna presentera arbetssätt och resultat skriftligt och muntligt. Förutom de satta målen i kursplanen som ska vara uppnådd vid terminsslutet vecka 22 så ska även en ios applikation levereras till kunden samma vecka. Appen ska kunna användas för att marknadsföra evenemang och kundens företag. Mål med projektet är: Att producera en ios-app med information om Mighty HB's evenemang En modul för applikationen, med möjlighet att se och dela mingelbilder under och efter ett evenemang

5 Projektorganisation Då vi bara var 2 i gruppen (först 3) så delades mycket ansvar i form av dokumentation, testning och teknikval. De klara roller som delades ut var enligt följande: Simon Palmqvist, projektledare Pepyn Swagemakers, kundansvarig

6 Genomförande Metodik I projektet så arbetar vi agilt i form av Unified Processes metodik där vi delat upp tillgänglig tid i iterationer som varar under en vecka. Inför varje iteration skapas en ny iteration där nya krav estimeras och läggs till. Efter varje avslutad iteration så bedöms det hur mycket som hunnits med, om några problem uppstått och om något behöver justeras inför nästa iteration. Vi använder GitHub för versionshantering då man på ett enkelt sätt kan arbeta kollaborativt med kodbasen samt kunna utvärdera varandras ändringar. GitHubs wiki-funktionalitet används för projektets dokumentation. För att kunna utvärdera arbetssätt och metodik så kommer referentgranskning utföras efter varje milsten av en annan grupp i kursen. Målet med detta är att hitta brister och kunna göra förbättringar under projektets gång samt att få återkoppling om vad man gör bra i projektet. Fokus kring testing läggs mycket på enhetstestning med ett internt krav inom gruppen på att testerna ska täcka 95 % av kodbasen. Detta för att enklare kunna implementera ny eller ändra befintlig funktionalitet utan att introducera allt för många buggar. Kravspecifikation Kraven är skrivna utifrån FURPS+ modellen, där de olika bokstäver i akronymen står för vilken typ av krav det gäller: Functionality Usability Reliability Performance Supportability Plus-tecknet används för krav som inte faller under någon av de ovan nämnda kategorier. I listan nedan har kraven fått ett ID där den första bokstaven antyder vilken typ av krav det gäller, följt av en siffra för ge kraven unika ID. Till exempel läses "U3" som det tredje kravet i kategorin Usability. ID F1 F2 Krav En användare ska kunna se kommande evenemang En användare ska kunna välja ett evenemang och få mer information

7 F3 F4 F5 F6 F7 F8 F9 U1 R1 P1 S1 S2 S3 En användare ska kunna se vimmelbilder för ett evenemang En användare ska kunna lägga till egna vimmelbilder Administratör ska kunna skapa evenemang Administratör ska kunna ladda upp en bild för evenemanget En användare ska kunna skriva upp sig på gästlistan för ett evenemang En användare ska kunna se historiska evenemang En användare ska kunna logga ut från sitt konto Appen ska ha ett enkelt och intuitivt design En användare ska kunna ladda ner applikationen från App Store Bilder ska cachas för att appen ska fungera smidigare Appen ska ha ett admin-gränssnitt för att hantera evenemang Appen ska ha källkod tillgänglig på GitHub för versionshantering och samarbete Appen ska, efter avslutat utveckling, kunna underhållas av uppdragsgivaren Tabell 1: Kravspecifikation Teknik Projektets mjukvaruarkitektur består av 3 delar. Ett webbgränssnitt där en administratör kan skapa och editera olika evenmang. En mobilapplikation där slutanvändare kan få information samt interagera med evenemang. en Backend as a Service som sköter datalagring, fillagring och autentisering. Viss kommunikation sker även via tredjeparts APIer som Facebook.

8 Figur 1: Mjukvaruarkitektur Mobilapplikationen Mobilapplikationen utvecklades främst för ios (iphone) men har byggts med ramverket React Native vilket gör det enkelt att vidareutveckla support för Android med. Det var en av de anledningarna till att vi valde att arbeta med React Native, andra anledningar var att gruppen hade tidigare erfarenhet av Javascript vilket skulle minska inlärningskurvan genom att inte behöva sätta sig in i ett nytt programmeringsspråk samt möjligheten att använda Hot Reloading dvs kunna se ändringar direkt utan att behöva kompilera om hela koden och starta applikationen på nytt. För att hantera applikationens state så användes Redux som förutom att vara ett Javascript-bibliotek också är ett designmönster där man försöker hålla applikationens state på ett ställe. Applikationen state kan sedan bara läsas för att inte råka ändra applikationens tillstånd från till exempel vyn. Vill man uppdatera applikationens state så får man istället skicka iväg Actions som då skapar en kopia av det nuvarande tillståndet och sedan gör uppdateringen.

9 Figur 3: React/Redux applikationsflöde Firebase / Backend-as-a-Service På grund av den tidsbegränsning som fanns och de resurser vi hade så valdes det att använda en Backend-as-a-Service för att inte behöva lägga tid på autentisering, hosting, uppsättning av databas och fillagring för till exempel bilder. Den BaaS vi valde blev Firebase då de verkade ha tydliga APIer, bra dokumentation och att det var enkelt samt gratis att komma igång med och använda upp till 100 inloggade användare samtidigt i produktion. Web-gränssnittet För att kunden lätt ska kunna hantera appen byggdes det ett Web- gränssnitt. Detta funkar som en applikation med CRUD-funktionalitet (skapa, visa, redigera och radera) mot databasen, för att abstrahera bort den direkta interaktionen till databasen och ersätta det med ett gränssnitt som är enklare för användare utan teknisk kunskap om databaser. Eftersom Firebase-platformen tillhandahåller både funktionaliteten för databas-operationer och autentiseringen behövde vi endast skriva klienten.

10 Vi valde att lägga upp gränssnittet på Firebase Hosting eftersom vi redan använde oss av andra Firebase-tjänster och då kunde ha allt samlat. Gränssnittet är strukturerad som Single Page Application (SPA). All HTML serveras som en enda fil och Javascript på klienten avgör vad som visas för användaren. Tanken var från början att gränssnittet skulle vara enkelt och lättvikt, vilket gjorde att vi valde bort att använda oss av ett tyngre klientramverk som React.js eller Angular och istället använde HTML5 templates med vanilla Javascript. För att kunna använda oss av ES6 i utvecklingen och för att minska laddningstider använde vi Babel som kompilerar flera olika JavaScript-filer (skrivna med ES6) till en enda browser-kompatibel fil som skickas ut till klienten. För stylingen valde vi att använda oss av Bootstrap-ramverket, främst av två anledningar. För det första vet vi inte vilken webbläsare eller enhet som kommer att användas i alla lägen så vi ville ha bra cross-browser-kompabilitet. För det andra fanns det inte tillräckligt med resurser för att kunna prioritera denna del av projektet. Då blev Bootstrap ett bra val eftersom det sparar mycket tid i utvecklingen och fungerar väl över olika webbläsare och enheter.

11 Resultat Implementering av applikationen Som det har nämnts i teknikavsnittet har vi använt oss av React Native för att bygga en mobilapplikation till ios. Nedan följer några skärmavbildningar på hur de olika delarna och krav har implementerats: Figur 4: Lista över evenemang Figur 5: Detalj för evenemang Figur 4 och 5 visar den grundfunktionaliteten som har beskrivits i kravspecifikationen under F1 och F2. När användaren öppnar appen ser hen en lista över kommande evenemang, sorterade efter datum. Om man klickar på ett evenemang kommer en mer detaljerad beskrivning som innehåller namn, plats och datum på evenemanget samt en omslagsbild och kort beskrivning.

12 Figur 6: Bilder och gästlista Figur 7: Bilder: inloggad läge Figur 6 och 7 visar funktionaliteten kring vimmelbilder. När användaren inte är inloggad kan denna se vimmelbilderna som tagits under evenemanget. I standardläget syns mindre bilder, s.k. thumbnails. När användaren trycker på en av bilderna syns bilden i en större vy.

13 Figur 8: inloggad läge Figur 9: Att ta en bild Figur 8 visar samma del av applikationen som figur 6, med skillnaden att användaren här har tryckt på logga in med Facebook. Genom att logga in får användaren tillgång till utökat funktionalitet, som att kunna ladda upp egna mingelbilder och att skriva upp sig på gästlistan för evenemang. När en användare är inloggad förändras länken Logga in med Facebook under mingelbilderna till Ladda upp bild. Klickar man på den öppnas en ny vy som använder telefonens kamera och ger användaren möjlighet att ta en egen bild att ladda upp bland mingelbilderna. Bilderna som laddas upp lagras på Firebase Storage. Mingelbilderna är den första optionella modulen, vilket innebär att administratören kan välja om mingelbilder ska finnas med eller inte.

14 Figur 10: gästlista Figur 11: användare uppskriven på gästlista När användaren är inloggad kan den även skriva upp sig på gästlistan. Innan den har tryckt på Skriv upp mig syns denna knapp som uppmaning till användaren, antalet platser som är kvar på listan och vilken fördel man får genom att skriva upp sig. Efter att ha skrivit upp sig visas en grön bock-symbol och texten Jag står på listan. Tanken är att istället för att lagra vilka personer som står på gästlistan och sedan jämföra namnen i dörren med dem på listan så kan användaren visa upp sin telefon som bevis att de finns på gästlistan. Möjlighet att ha gästlista eller ej, samt att välja antalet platser kan göras av administratören när de skapar evenemanget.

15 Testning Minimalt antal fel har hittats i slutet på varje iteration då det lagts mycket fokus på att genomföra heltäckande enhetstestning när krav implementerats så buggar som uppstår kan fixas direkt. Dessa tester ger också en trygghet i att applikationen fungerar som den ska och förenklar för vidareutveckling då man kan känna sig trygg på att testfallen signalerar om man råkar påverka redan existerande funktionalitet när man implementerar nya krav. Utöver enhetstestning har vi även gjort en del användartestning och end-to-end testning för att kunna ha förtroende för att systemet som helhet fungerar. Dokumentation Dokumentationen som tagits fram i och med projektet har en bra översikt över de tekniska val och mjukvaruarkitektur som valts. Det finns även dokumenterat hur man sätter upp en utvecklingsmiljö och hur man kan förbereda applikationen för produktion. Det saknas dokumentation av många av de manuella testfall som utförts varje vecka för att testa att applikationen fungerar som tänkt. Vi ser inte det som något stort hinder då applikationen har bra täckning i form av enhetstester. Sammanställning av avslutade iterationer i form av om de mål som satts upp blev uppfyllda, om nya risker har identifierats eller hur testningen har gått hade varit bra att ha för framtida utveckling. Även en sida med information om hur man till exempel implementerar nya moduler eller vad man behöver fixa för att köra applikationen för Android är saker som inte hunnits med men hade varit bra dokumentation att ha inför överlämning av projektet. Grupparbete Samarbetet mellan gruppmedlemmerna fungerade bra och vi hade en genomgående bra stämning i gruppen. Även om risken alltid är närvarande när man jobbar med en grupp personer som man inte känner sedan innan lyckades vi undvika konflikter i gruppen. Ett hinder för strukturerad samarbete där alla kunde sitta samtidigt och jobba var att alla medlemmer antingen hade deltidsarbete eller kurser vid sidan om, eller både och. Det gjorde att det inte alltid var lätt att hitta ett större tidsintervall där vi kunde jobba samtidigt.

16 Det ät möjligt att detta även påverkade antalet projektmöten, som vi i efterhand kan känna var för få. De som hölls var dock effektiva och lagom långa, vi kunde diskutera allt som vi behövde ta upp men kände inte att det gick för mycket tid åt möten som kunde används på bättre sätt. Ungefär halvvägs in i projektet var en av medlemmarna tvungen att hoppa av, vilket gjorde att vi fick omfördela resurserna. Det blev så att vi gjorde en fördelning där en mest arbetade med mobilappen och den andre gjorde webb-gränssnittet. Även om detta var det bästa valet resursmässigt gjorde det att man inte var lika insatt i vad gruppen gjorde utan att man mer satt på var sin del. Det hade varit mer lärorikt att kunna samarbeta och jobba tillsammans samt lättare att hålla översikt under arbetets gång. Analys och bemötande av risker Den första riskanalysen genomfördes under Inception-fasen. Vi kunde då identifiera några risker som vi kunde hantera på en gång, som till exempel risker kring grupparbete och teknikval. Därmed gick vi in i Elaboration-fasen med flera stora risker eliminerade. Under Construction-fasen fick vi hantera en av de riskerna som vi hade identifierad genom att en av medlemmarna inte kunde vara med längre och hoppade av. Vi hanterade detta genom att justera kraven och omfördela arbetet och i det stora hela påverkades inte projektets kontinuitet även om storleken på arbetet fick minskas något. Även om vi under Inception var bra på att identifiera risken uppdaterades inte risklistan lika mycket under faserna Elaboration och Construction. Delvis blev det så för att vi hade identifierat de flesta stora risker och hade jobbat bort dem eller satt upp en strategi för bevakning och hantering. Men det bidrog även att vi lade mer fokus på att faktiskt utveckla applikationen och uppfylla de kraven från universitets sida som olika inlämningar och referentgranskningar. Färdigställande och leverans Svårt att hålla kommunikation med kund då de var väldigt upptagna med annat vilket resulterade att inga demos genomfördes veckovis utan mer statusrapporter över vad som arbetats på. Eftersom applikationen bara kunde köras via en simulator eller i mobil kopplad till utvecklingsmiljön gjorde det svårt att få kunden att prova applikationen mot ifall det var en webbapplikation som enkelt kunde öppnas med en url. I övrigt testades hela applikationen av projektgruppen varje vecka genom att installera applikationen på en mobiltelefon och gå igenom samtliga krav som implementerats. Applikationen kommer levereras i kodform för senare driftsättning eller vidareutveckling av kund då krav som att företaget ska ha en webbsida och ett betalande Apple Developer konto inte uppfyllts och därför kan applikationen inte laddas upp på AppStore.

17 Slutsats Dokumentationen blev lidande av att vi förlorade en gruppmedlem och för att hinna klart i tid fokuserade mer på implementationen. Att arbeta i en grupp på två personer krävde också kortare iterationsplaneringar och uppdateringar då det var enklare att hålla koll på vad den andre gjorde. Vi kan även konstatera att även om det kan verka positivt att få fria händer av kunden så har det varit en utmaning i och med att man lätt planerar för mycket. Att jobba med de teknikerna som vi har använt var ett bra val och mo vi hade ett liknande scenario med samma resurser skulle vi göra samma val igen. Att använda BaaS gjorde att vi inte behövde lägga lika mycket resurser på utvecklingen av den funktionaliteten och vi kunde verkligen fokusera på features. Även valet av React Native underlättade eftersom det minskade inlärningstiden, eftersom vi redan var insatta i att skriva JavaScript. Ett hinder som vi fick hantera och som gjorde att applikationen inte blev lika utvecklat är att vi fick ett avhopp i gruppen under projektets gång. Vi lyckades hantera detta väl eftersom vi hade en modulär design på applikationen så att vi lätt kunde skala ner vad som skulle utvecklas.

18 Applikationens framtid Övertagande organisation Applikationen tas över av uppdragsgivaren, Mighty HB, som är en eventbyrå verksam i Kalmar med omnejd. Företaget består av 2 personer varav en är baserad i Kalmar och en i Göteborg. Vidareutveckling av applikationen Som beskrivet ovan har applikationen utvecklats enligt ett modulärt koncept. Detta innebär att den från början är byggd på ett sätt som ska göra det enkelt att lägga till nya moduler i applikationen. Det saknas även lite mindre förbättringar som borde implementeras vid vidareutveckling av applikationen som till exempel att kunna växla mellan kommande och evenemang som redan varit samt att få en liten bild av evenemanget i listan med evenemang. Eftersom kunden kommer att få kodbasen samt dokumentation om hur koden fungerar och är uppbyggd finns det möjlighet för dem att anlita en utvecklare som kan ta den här koden och vidareutveckla den. Litteratur och dokumentation Dokumentation för projektet finns på: