Slutrapport Andreas Fürst, Martin Åhlin, Stefan Sahlin, Jenni Berndtson, Jimmy Sigeklint
Sammanfattning I kursen IDV411 Webbprojekt I som ingår i programmet Webbprogrammerare vid Linnéuniversitetet har fem distansstudenter blivit tilldelade en projektuppgift av en riktig kund med avsikt att låta alla medverkande praktisera sina kunskaper inom programmering, kundkontakt, analys och design, versionshantering, kravhantering, testning och agil-projektledning under så verkliga förhållanden som möjligt. Själva uppgiften gick ut på att skapa en webbaserad tjänst som är tänkt att användas av föreningar och företag som vill visa upp mediafiler knutna till geografiska platser. På följande sidor beskrivs uppdraget och dess mål, metoder och tekniker samt en analys kring projektet i sig. 1
Innehållsförteckning Inledning/bakgrund 3 Syfte och mål 4 Projektorganisation 4 Genomförande Metodik 5 Genomförande - Teknik 7 Resultatbeskrivning - Måluppfyllelse 7 Avvikelser Efterkalkyl 8 Slutsats 8 Förslag på vidareutveckling 9 Eventuell övertagande organisation 9 Litteraturförslag/dokumentationshänvisning 9 Förslag till förbättringar inför kommande projekt 9 Bilagor 9 2
Inledning/bakgrund Historier, minnen och viktiga monument kan lätt falla i glömska och suddas ut om vi inte dokumenterar dessa och på så vis håller dem vid liv. Det har också visat sig att intresset för att arkivera historiska data kan vara ganska snävt geografiskt knutet. Behovet av ett verktyg som underlättar bevarandet av minnen, historiska händelser och byggnader knutna till geografiskt avgränsade platser har alltså varit stort. Som svar på detta problem har vi skapat en webbaserad tjänst som låter kunder så som kommuner, turistföreningar eller hembygdsföreningar arkivera olika mediafiler knutna till ett speciellt geografiskt område (exempelvis bilder, videofiler och ljudfiler) för att på detta vis låta intresserade användare ta del av materialet. Tjänsten heter PlatsArkivet. 3
Syfte och mål Projektets huvudsakliga syfte var att skapa en webbaserad tjänst som låter kunder så som turistföreningar eller hembygdsföreningar arkivera olika mediafiler knutna till ett speciellt geografiskt område (exempelvis bilder, videofiler och ljudfiler) för att på så vis låta intresserade användare ta del av materialet. Till ovanstående tjänst skulle det ingå en administrationsdel i vilken det skulle finnas möjligheter till kundsupport och statistik. Det skulle även skapas en applikation som låter användare besöka kunders sidor och med hjälp av en karta ta del av information kring kundens platser samt se eller lyssna på uppladdade mediafiler. Projektet ingick dessutom i kursen Webbprojekt I, 1DV411 vid Linnéuniversitetet och hade därför även som mål att låta alla medverkande praktisera sina kunskaper inom programmering, kundkontakt, analys och design, versionshantering, kravhantering, testning och agil-projektledning under så verkliga förhållanden som möjligt. Projektets primära mål var, att inom tidsramen med deadline i vecka 13 år 2014, leverera en färdig produkt till vår uppdragsgivare. Från skolprojektets aspekt tillkom målet att leverera en heltäckande dokumentation i form av bland annat denna projektrapport som är tänkt att spegla hela projektets gång och faser. Projektet avslutades med redovisning i form av en muntlig presentation. Projektorganisation Projektets organisation består av fem medarbetare, alla utplacerade över landet och alla distansstudenter vid Linnéuniversitetet. Till projektgruppen räknas Jenni Berndtson, Jimmy Sigeklint, Martin Åhlin, Stefan Sahlin och Andreas Fürst. Till vårt förfogande har vi vår handledare och ansvarig för kursen, Tobias Ohlsson samt Emil Carlsson. 4
Genomförande - Metodik Arbetsmetoden som vi har arbetat efter har varit en iterativ kombination av Unified Process och SCRUM och utvecklingen av projektet har delats in i de fyra faserna inception, elaboration, construction och transition. Varje vecka har under projektets gång representerat en iteration och varje iteration har innehållit återkommande element så som handledarmöte, kundmöte och gruppmöten. Vi har alla antagit rollen som projektledare minst en gång. Dock fick vi en ganska klar bild av projektet redan i ett tidigt skede och vi kunde ta fram en Product backlog som vi sedan använde som utgångspunkt i vårt arbete. Vi utvärderade, bestämde och testade ramverken tidigt i förhållande till baskraven vilket snabbt eliminerade de större riskerna i projektet. Vi beslöt också att dela in oss i olika, tydligt avgränsade, ansvarsområden vilket gjorde att behovet av en projektledare inte kändes så tydligt då alla ledde sin egen avdelning. Med mindre central styrning, vilket skulle dragit ner på effektiviteten i projektet, eftersom vi var såpass många, och med en färdig arkitektur, fast etablerad hos samtliga deltagare, var det enklare för alla att arbeta självständigt och fokuserat. Inbördes kommunikation om flaskhalsar och kritiska funktioner har fungerat väl, huvudsakligen på grund av våra individuella ansvarsområden, där var och en har känt sig fri att påpeka vad som behövs från de andra om man har råkat på problem eller behövt tillgång till funktioner som inte implementerats ännu. Vi använde oss vidare av en Sprint backlog för att dokumentera vilka Story Id vi jobbade med för tillfället och vilken status de befann sig i, samt hur många timmar vi individuellt ägnade åt projektets olika uppgifter. Varje vecka bestod av två planerade gruppmöten, men därutöver blev det även en del oplanerade möten. Vi använde oss flitigt av Google Drive för dokumentation och Basecamp för exempelvis kalender, skisser och TODO-lista, och vi höll varandra dagligen uppdaterade via vår Skypechatt. För versionshantering har vi använt oss av Github. Den huvudsakliga kommunikationen med vår uppdragsgivare skedde under de veckovisa kundmötena då vi presenterade den gångna veckans arbete och fick feedback på både design och funktion. Vår kund hade en mycket klar bild av den beställda produkten och kunde tydligt formulera sina önskemål vilket underlättade vårt arbete väsentligt. Vad som förväntades vecka-för-vecka från kursledningen var också tydligt och och vi fick hela tiden bra och hjälpsam återkoppling från vår handledare som hjälpte oss att bättre förstå vad som förväntades av oss under de olika faserna. Vi saknade dock en tydlighet kring vad som mer exakt skulle ingå i den tekniska dokumentationen vid Elaboration Milestone. 5
Vi var lite för snabba med att implementera layout utan att invänta godkännande från kunden, vilket resulterade i tre stora ändringar av frontend-layouten. Vi uppdaterade dokumentationen löpande och har arbetat med den in i det sista. Inledningsvis borde vi kanske ha haft mer intressanta och säljande baskrav som var bättre anpassade för vår visions målgrupp, dessa korrigerades dock under resans gång. En annan punkt som kanske borde ha undersökts närmre var eventuella konkurrerande system och applikationer. Vi har under hela projektets gång ökat frekvensen av strukturerade tester. Programmeringen stämmer överens med användningsfallen. Testfallen byggde i sin tur på användningsfallen och med hjälp av dessa har vi aktivt gjort upprepade försök att knäcka systemet. Enhetstester har påbörjats på backend och frontend, vilket ökar tryggheten. De kommer dock att behöva kompletteras och byggas ut i en framtid för större code coverage, framför allt om projektet skall utvecklas vidare. Det bör också nämnas att Laravel i sig är mycket vältestat och dess inbyggda funktioner känns trygga, detsamma kan sägas om Angulars core-funktioner. I det stora hela höll tidsplanen. Genom kontinuerliga avstämningar och justeringar av baskrav kunde vi löpande göra korrigeringar. En del funktioner som visade sig vara för omfattande fick dras in och ersättas med bättre tidsanpassade krav som för den sakens skulle inte drog ner på den slutliga produktens funktionalitet. Med tiden fick vi bättre vana på att sätta upp och genomföra tidsplaneringen. Vi blev också bättre på att styra och planera våra egna uppgifter allt eftersom vi fick överblicka och styra över våra egna ansvarsområden. 6
Genomförande - Teknik Backend - Då kunden efterfrågade PHP och ett API mot backend valde vi att arbeta med Laravel som är ett komplett ramverk med MVC-arkitektur, RESTful routing, ORM etc. Vi använde oss vidare av Composer som sköter autoloading och installation av de tillägg som behövs för Laravel. Artisan installerar databasens tabeller och seedar data. Frontend - På kundens begäran använde vi Angular JS som ramverk då det passar utmärkt till de många CRUD-operationer som utförs på frontend. Kunden ville även ha en SPA (Single Page Application), där Angular framstår som ett av de bästa alternativen. Alternativen Knockout och Ember har liknande funktionalitet, men eftersom Angular uppfyllde alla våra krav mer än väl och samtidigt var kundens preferens har vi inte ägnat tid åt att utvärderat dem. Googles produkter Google Maps och Google Analytics har också spelat en stor roll i projektet. Resultatbeskrivning - Måluppfyllelse Vi känner oss mycket nöjda med resultatet och kan stolt nämna att vi enligt vår kund har överträffat hans inledande förväntningar, vilket inträffar mycket sällan. Vi har uppfyllt samtliga baskrav som vi inledningsvis formulerade och dessutom förbättrat några punkter under resans gång. Som grupp har vi fungerat väl och vi har alla funnit oss i våra roller och levererat inom gruppen det som har förväntats av oss. Vi har varit flexibla med både tider och insatser och vi har legat bra till i faserna under hela projektet. Vi har dessutom haft väldigt roligt under hela tiden. 7
Avvikelser -Efterkalkyl Vissa mindre justeringar har gjorts i användningsfallen efterhand som vi har utvecklat tjänsten. Som större avvikelser bör nämnas två förbättringar av kundens inledande önskemål: Istället för att skapa ett eget system för statistiken i tjänsten ingår nu en koppling mot Google Analytics och man kan som kund få en extremt noggrann översikt över sina besökares vanor och beteenden. Vi skapade även en dubbel inloggningsfunktion för Admin att användas i supportärenden vilket innebär att man som Admin enkelt kan få tillgång direkt till kundens sidor och vara behjälplig i realtid på ett smidigt sätt. Vi lade även till en drag-n-drop funktion för att underlätta uppladdningen av mediafiler. Ett önskemål som aldrig blev implementerat var att visa en riktning till platsen i form av en interaktiv pil. Slutsats Uppdelningen av arbetsområden samt att arbeta iterativt har sannolikt varit de två viktigaste nycklarna till vårt projekts framgångar. Med hjälp av de täta återkopplingarna, dels i gruppen, dels i handledningspassen och dels i kundmötena, var det omöjligt för eventuella felaktiga antaganden att växa och vi kunde hela tiden korrigera och styra de olika elementen i projektet i rätt riktning. Om det sedan var ren tur eller ingick i en större masterplan att vi tillsammans täckte upp den kompetens som krävdes, eller hade ett genuint brinnande intresse för det arbetsområde vi åtog oss att ansvara för, låter vi vara osagt. Om man måste hitta någon nackdel med valet av vår arbetsmetod kan det vara att vi sannolikt hade lärt oss mer som individer om vi inte hade delat upp oss inom våra kompetensområden, men i ett vidare resonemang är det ju allmänt känt att passion och intresse är de viktigaste ingredienserna för framgång. 8
Förslag på vidareutveckling Vi tror verkligen att vår framtagna produkt kan bli en given succé i rätt händer och hoppas att den sätts i bruk en dag. Det finns mer att göra på designen och ett förslag från vår sida är att erbjuda kunder enklare inställningsmöjligheter för utseendet på deras sida. Kunden borde kunna välja olika skins för att på så vis kunna återspegla en redan befintlig grafisk profil samt matcha färger i kundens logotyp. Eventuell övertagande organisation Svenssons Kod Litteraturförslag/dokumentationshänvisning Strukturen på Angular-lösningen som används följer exemplet i boken Mastering Web Application Development with AngularJS, skriven av Pawel Kozlowski och Peter Bacon Darwin, ISBN : 1782161821. Även majoriteten av directives, filters, services och controllers följer standarden i denna bok. Därför rekommenderas boken om någon extern utvecklare vill plocka upp och fortsätta utvecklingen av applikationen. Förslag till förbättringar inför kommande projekt Vi känner att vi har arbetat efter en bra modell väl anpassad till dels storleken på gruppen och dels till storleken på projektet. Att sköta daglig kommunikation via Skype har passat oss bra men kanske legat på gränsen av det genomförbara i Skype-miljö. Hade vi varit två till tre personer till i gruppen hade vi behövt en annan struktur på våra möten. Även ansvarsfördelning, styrning och rapportering hade då sett annorlunda ut. Bilagor API-docs Användningsfall Test-dokumentation Teknisk dokumentation Vision 9