Mobilapplikation - Lnu.seorion.lnu.se/pub/education/course/1DV611/vt17/Slutrap... · 2012. 4. 3. · 3.0 Uppdaterings loop ... vilken det installerades ASP.NET 4.5, MVC 4, RavenDB,

Mobilapplikation

~Projektrapport~

2012-03-30

Handledare: Tobias Ohlsson

Projektdeltagare: Claes Tillborg

Oscar Lillheden Robert Fransson

Tryggve Blom

Uppdragsgivare: Pelle Sederkvist

Marcus Oldin

Webbprojekt 1(1DV411) Linnéuniversitetet Kalmar 2012-03-30

1

Sammanfattning Vi har under ett par veckor varit med och skapat en mobilapplikation baserat på ett

projekthanteringsverktyg. Tjänsten finns idag som en webbapplikation och ägs av Pelle Sederkvist

och Marcus Oldin som tillsammans har företaget Coleo Vision AB.

Målet med projektet har varit att utveckla en applikation som tar vara på de möjligheter och

begränsningar som medföljer de moderna mobila enheter med touch-skärm, såsom iOS- och

Android-enheter. Den mobila versionen har till stor del byggt på det gamla verktygets struktur men vi

har fått tillåtelse att skala bort funktioner som inte går att översätta till det mobila gränssnittet.

Vi har även samarbetat med en grupp studenter från Interaktionsdesignprogrammet årskurs 3

beträffande utseende och interaktion.

Målet med kursen Webbprojekt 1 är att eleverna ska genomföra ett projekt i grupp och presentera

sitt arbetssätt och resultat skriftligt. Rapporten tar upp de olika tekniker, metoder och strukturer som

har använts samt vilka verktyg, program och utvecklingsmiljöer vi stött på. Här berättar vi även hur vi

uppnått våra mål, vilka svårigheter vi haft och vilka lösningar vi har tillämpat. Även en och annan

lärdom har vi lyckats trycka in. Sist ger vi även förslag på några vidareutvecklingar av den applikation

vi skapat.


2

Förord Detta projekt är gjort av campusstudenter på webbprogrammerareprogrammet på

Linnéuniversitetet inom ramen för kursen Webbprojekt 1, som är en 7,5hp-kurs på halvfart.

Kursansvarig handledare har varit Tobias Ohlsson.

Projektet har bestått i att utveckla en mobilapplikation för projekthantering åt ett företag i Kalmar.

Parallellt med vårt projekt har kunden tagit hjälp av ytterligare två grupper, en annan grupp från

webbprogrammerarprogrammet för att utveckla ett API (Application Programming Interface) och en

interaktionsdesigngrupp, från Interaktionsdesignsprogrammet årskurs 3, vars uppgift bland annat har

varit att ta fram designen på mobilapplikationen. Vi har således fått arbeta med båda dessa grupper

under projektets gång.


3

Innehållsförteckning Sammanfattning ...................................................................................................................................... 1

Förord ...................................................................................................................................................... 2

Innehållsförteckning ................................................................................................................................ 3

Introduktion ............................................................................................................................................ 5

Inledning och bakgrund ....................................................................................................................... 5

Syfte ..................................................................................................................................................... 5

Mål ....................................................................................................................................................... 6

Baskrav ............................................................................................................................................ 6

Projektorganisation ................................................................................................................................. 7

Genomförande ........................................................................................................................................ 8

Metodik ............................................................................................................................................... 8

Planeringsvecka ............................................................................................................................... 8

Inceptionfasen ................................................................................................................................. 8

Elaborationfasen ............................................................................................................................. 9

Constructionfasen ........................................................................................................................... 9

Transitionfasen .............................................................................................................................. 11

Teknik ................................................................................................................................................ 11

Resultatbeskrivning/Måluppfyllelse ...................................................................................................... 12

Avvikelser/efterkalkyl ............................................................................................................................ 12

Slutsats .................................................................................................................................................. 13

Förslag på vidareutveckling ................................................................................................................... 13

Privata “att-göra”-listor ..................................................................................................................... 13

Nyhetsflöde ....................................................................................................................................... 13

Notifikationer .................................................................................................................................... 14

Tillgänglig på distributionsplatser ..................................................................................................... 14

Filhantering ....................................................................................................................................... 14

Övertagande organisation ..................................................................................................................... 14

Litteraturförslag/dokumentationshänvisning ....................................................................................... 14

Förslag till förbättringar inför kommande projekt ................................................................................ 15


4

Bilagor .................................................................................................................................................... 16

1.1 Bas-controller .............................................................................................................................. 16

1.2 Bas-vymodell ............................................................................................................................... 16

2.1 Inloggning .................................................................................................................................... 17

2.2 Planering ...................................................................................................................................... 17

2.3 Projekt info .................................................................................................................................. 18

2.4 Aktivitetslista ............................................................................................................................... 18

2.5 Logginlägg .................................................................................................................................... 19

2.6 Kollegor ....................................................................................................................................... 19

2.7 Kontakt info ................................................................................................................................. 20

2.8 Väggen ......................................................................................................................................... 20

2.9 TODO-lista ................................................................................................................................... 21

3.0 Uppdaterings loop ....................................................................................................................... 22


5

Introduktion Webbprojekt 1 är en kurs där man i grupp jobbar med ett projekt under hela kursens gång. Gruppen

har regelbundna möten med kurshandledare varje vecka och möjlighet finns till flera möten om så

skulle önskas. Projekten i kursen kommer ofta på beställning av externa företag. Betyget i kursen

baseras på den färdiga produkt gruppen lyckas skapa och av en projektrapport som beskriver

arbetet, det är för övrigt denna projektrapport du läser nu. Vi blev grupp 6 och fick i uppdrag att

jobba med utvecklingen av en mobilapplikation för ett projekthanteringsverktyg.

Deltagarna i denna grupp har varit Claes Tillborg, Oscar Lillheden, Robert Fransson och Tryggve Blom.

Inledning och bakgrund Företaget vi blev tilldelat att jobba för var Coleo Vision AB, ett nystartat företag från Kalmar.

Grundaren Pelle Sederkvist har med hjälp av programmeraren Marcus Oldin tagit fram ett

webbaserat projektplaneringsverktyg. Mycket håller just nu på att hända med verktyget. Det skall få

en ny design och det genomförs även en mer övergripande strukturförändring. För att tilltala fler

kunder och tillgodose nuvarande kunders önskemål vill de nu ha en mobil version av sitt verktyg.

Ytterligare två grupper fick i uppdrag att arbeta med denna applikation. En annan grupp från vårt

program skulle skapa ett API(Application Programming Interface) och en grupp ifrån

Interaktionsdesign årskurs 3 skulle vara med i utvecklingen av gränssnittet på applikationen. Vi skulle

ha speciellt stort samarbete med ID-gruppen(Interaktionsdesign gruppen).

Den ursprungliga webbapplikationen är utvecklad i ASP.NET MVC, ett ASP-dotnet ramverk baserat på

Model View Controller strukturen. Coleo använder sig i nuläget av MVC 3 men vill gärna uppgradera

sig till ASP.NET MVC 4, en beta-version som har inbyggt stöd för mobilapplikationsutveckling. Vi har

även använt oss av ASP.NET 4.5, den senaste versionen av ASP-dotnet som även denna är i en beta-

version för tillfället.

Som databashanterare använder sig Coleo av RavenDB, en NoSql-databashanterare som använder sig

av JSON för att spara undan information om objekt. Vi fick ett utdrag med test-data från deras

befintliga databas att arbeta vidare med och fick skapa upp en egen databas-instans på en egen

server.

Syfte Kunden beställde en mobil-anpassad version av deras egna projekthanteringssystem som idag endast

finns för webben. Syftet med projektet är att ta fram en applikation som kommer att användas som

grund för deras utveckling av en mobilapplikation. Vårt arbete kan ses som en prototyp-applikation

för deras framtida system där källkod likväl som applikationsstruktur är intressanta för kunden.


6

Mål Målet med projektet har varit att lära sig jobba mer iterativt och planera både tid och uppgifter

tillsammans i gruppen. Vi skulle lära oss att utveckla och jobba tillsammans både som grupp och på

individuellt plan. Vi skulle dessutom ha nära samarbete med både kunden och ID-gruppen för att få

erfarenheter av större projektarbeten. Möten skulle hållas regelbundet med handledare, kund och i

vårt fall även med ID-gruppen. Mobila applikationer skiljer sig från webb-baserade applikationer och

därför blev det ett mål för oss att lära sig de tekniker och verktyg som används till detta. Vi fick också

tillfälle att jobba med en NoSql-databas, vilket ingen av oss tidigare gjort. Det innebar att vi även fick

sätta oss in i hur dessa databashanterare fungerar.

Utifrån detta skulle vi uppfylla de baskrav vi och Coleo kommit överens om. Även om dessa efterhand

ändrades.

Baskrav

BK1. Man måste logga in med sitt användarnamn och lösenord. Annars får man ingen tillgång till tjänsten. BK2. Mobilapplikationen skall kunna presentera data om användarens organisationer, avdelningar och aktiviteter. BK3a. Man skall kunna se sina loggposter. BK3b. Man skall ha CRUD på loggposter. BK3c. Man skall kunna klarmarkera loggposter. BK4a. Man skall kunna titta på vilka kollegor man har i organisationen/projektet. BK4b. Man skall erbjudas möjlighet att skicka e-post till en kollega. BK5. Extra funktionalitet är att undersöka hur väggen skulle kunna gå att implementera. BK6. Privata TODO-meddelanden skall vi också kolla på hur man kan implementera.


7

Projektorganisation

Uppdragsgivaren till detta projekt har varit Coleo Vision AB som består av Pelle Sederkvist och

Marcus Oldin. De använde sig även av två andra grupper till detta projekt, en grupp som har

utvecklat ett API och en grupp från interaktionsdesignprogrammet som har haft till uppgift att

designa mobilapplikationen vi ska utveckla. Vi har haft mycket kontakt med både kunden och de

andra parterna för projektet. Kunden har samlat grupperna en gång i veckan för ett

avstämningsmöte där alla har kunnat ta del av vad som händer på de olika planen. Vi har även haft

kontakt med Marcus via telefon, e-post och chatt under arbetets gång. Vi har även tagit på oss att ta

kontakt med de andra grupperna utanför dessa möten, ID-gruppen mer än API-gruppen.

Handledare för vår grupp har varit Tobias Ohlson. Varje vecka har vi haft handledarmöte där vi

kunnat diskutera hur arbetet framskridit samt fått tips och idéer om hur gruppen kan fortsätta

arbetet.

Vi har varit en liten projektgrupp där rollerna har växlat under projektets olika faser. Vi har delats in i

olika arbetsgrupper beroende på vilka uppgifter som varit aktuella och eftersom vi har haft en tydlig

begränsning i antal deltagare så har projektledaren ingått i arbetsgrupperna. Samarbetet med ID-

gruppen har varit olika beroende på i vilket skede vi varit i under projektet men i stort har de flesta

möten med dem varit korta och handlat om design och utformning på olika delar av applikationen.


8

Genomförande

Metodik Vi har arbetat efter SCRUM-metoden och i enlighet med Unified Process delat in projektet i olika

iterationer. Varje vecka innebar en ny iteration och då utsågs även en ny projektledare för att alla

skulle få känna på att vara projektledare. Däremot har projektledarrollen varit något lättvindig,

projektledaren har mest haft ansvar för dokumentation och veckoplanering. Vi använde oss av burn

down charts för att planera och uppskatta vad som skulle göras under veckan och rapportera hur

många timmar var och en har arbetat.

Handledarmöte är något vi också haft varje vecka. Under dessa har vi redovisat den tidigare

iterationens arbetsgång och diskuterat hur vi skall fortsätta arbetet på bästa sätt under den

kommande iterationen.

Ungefär en gång i veckan har vi haft möte med kunden och de andra grupperna. Vi har då visat våra

visioner och resultatet av det vi hittills skapat, lyssnat på feedback och diskuterat olika lösningar.

Planeringsvecka

Den inledande veckan av projektarbetet var vi inte informerade om några detaljer rörande den

produkt vi skulle utveckla, mer än att det var en mobilapplikation av deras nuvarande tjänst. Därför

tillägnade vi tiden åt att sätta oss in i verktyget samt till planering och förberedelser. Vi gjorde

scheman, mallar för burn down charts, började skriva på risklistan och mycket annat. Dessutom

gjorde vi mappar i Dropbox och Google Docs som delades inom gruppen för dokumentation och

överföring av filer.

De fördelar som kom med Google Docs kontra andra ordbehandlare utnyttjades flitigt. Det är

behändigt att skriva i webbläsaren och lagra dokumenten i molnet eftersom man då enkelt får

åtkomst till dem från vilken dator man än sitter vid. Vidare är det en väldig vinst med att flera

personer i realtid kan arbeta i samma dokument och samtidigt kommunicera via en chatt. Google

Docs har därför varit en stor resurs under hela projektets arbetsgång.

Inceptionfasen Fasen inleddes med vårt första möte med kunden. Där fick vi en helhetsbild av vad vårt projekt skulle

komma att innefatta. Vi kom tillsammans fram till några baskrav som skulle vara grunden i den vision

vi började skriva och som sedan godkändes av Coleo. Vi fick dessutom önskemål om utvecklingsspråk

och tekniker vilket skulle innebära att vi inte kunde använda våra ordinarie datorkonton i skolan

eftersom vi inte kan installera några egna program på dessa.

Detta löstes med VMWare Workstation där det skapades en virtuell installation av Windows 7 på

vilken det installerades ASP.NET 4.5, MVC 4, RavenDB, SVN och det som behövdes för vår utveckling.

Vi behövde ett sätt att skarpt publicera vår applikation för att kunna testa den utanför skolans miljö

och i mobila enheter. För detta fick vi av skolan tillgång till en webbserver som vi själva fick

administrera och installera bland annat MVC 4 och RavenDB.

Mycket tid gick åt till att sätta sig in i de olika ramverk vi skulle jobba med. MVC 4 var ganska likt MVC

3 som vi hade erfarenhet av sen tidigare, men jQuery Mobile (JQM) var inget vi var vana vid sedan


9

tidigare. JQM innebar många möjligheter men även en del begränsningar som vi efter hand lade

märke till och som är bra att känna till på förhand.

Elaborationfasen Det har under denna fas förekommit möten med gruppen av Interaktionsdesignstudenter där vi

diskuterat hur den visuella utformningen ska bli. Att vara delaktiga i denna process har varit väldigt

nyttigt eftersom vi då kunnat påverka och i ett tidigt skede stoppa idéer om vad som är

programmatiskt och tidsmässigt omöjlig för oss att utveckla.

Interaktionsdesigngruppen skapade sedan en low fidelity-prototyp, som sedan agerade en högst

preliminär mall att börja utveckla modellarkitekturen efter. Detta gjorde vi genom att skapa

klassdiagram och sekvensdiagram som visade hur vi uppfyllde ett av baskraven.

Gruppens medlemmar har på egen hand ägnat mycket tid åt att läsa in sig på de olika resurser vi

använder, såsom RavenDB, jQuery Mobile och MVC 4, men programmeringsarbetet har även inletts,

om än i mindre skala.

Implementationen av de första baskraven har påbörjats och en del lösningar för att hålla reda på den

aktuella sessionen har vi fått komma på själva. Detta gjordes genom att skapa klassen ActiveModels

som innehåller information om den aktiva användaren, organisationen, avdelningen och aktiviteten.

Constructionfasen Versionshanteraren, TortoiseSVN, började i den här fasen att skapa problem och vi tvingades lägga

ner lite extra tid på lösningar. De flesta felen uppstod när några filer användes och uppdaterades av

flera användare samtidigt. Detta går att lösa med TortoiseSVN genom att man slår samman de olika

versionerna av filen. Detta kan dock medföra problem ändå, genom till exempel funktioner som

jobbar emot varandra, så det är viktigt att dela upp arbetet i gruppen och alltid veta var de olika

medlemmarna är och arbetar. Om man vet att någon i gruppen jobbar i filen man ska ändra i, ber

man denna medlem göra ändringarna och uppdatera ändringarna. Om man har ändrat i en fil man

inte har på sin “listan” bör man meddela resten av gruppen så att alla kan uppdatera sina versioner

för att undvika senare problem.

Vi har som sagt haft problem med att handskas med TortoiseSVN men efter ett tag hittade vi ett sätt

att jobba på som passade oss mycket bra.

Interaktionsdesigngruppen har bidragit med ett gäng High Fidelity-bilder av hur de tycker att

applikationen ska se ut och dessa har vi sedan använt som en mall för det grafiska gränssnittet.

Applikationens utseende förändrades därmed drastiskt och blev betydligt mer lik den design Coleos

webbapplikation använder. De missade dock en del av våra baskrav vilket bidrog till att funktionernas

utseende fick diskuteras med dem under implementation.

Detta belyser både styrkan och svagheten med samarbetet. Eftersom vi arbetat i två separata

grupper med olika tidsplaner och målsättningar har det varit svårt att få ett riktigt bra fungerande

arbetsflöde. Samtidigt har vi haft ett så pass flexibelt och nära samarbete att vi kunnat fråga efter

direktiv under processens gång.


10

Detta är något som kanske inte rekommenderas vid andra projekt men under omständigheterna fick

vi göra det bästa av situationen. Att vänta på att interaktionsdesigngruppen skulle göra nya bilder

hade fördröjt vårt arbete.

I ett bättre scenario hade vi haft med oss en interaktionsdesigner i gruppen som hade följt vårt

tidsschema och haft bättre koll på våra krav, alternativt att den externa gruppen arbetat fram en

grunddesign innan vi började med vårt projekt.

Eftersom JQuery Mobile användes för att skapa det grafiska gränssnittet ville vi även titta lite

närmare på Themeroller, det verktyg som JQM erbjuder för att skapa teman. Dessa teman laddar

man sedan ner som CSS-filer till sin applikation. Vi bad ID-gruppen i början av projektet att sätta sig in

i detta verktyg och då också skapa sitt tema där, något vi trodde skulle spara mycket tid och bidra till

ett bättre utseende på applikationen. De lyckades inte lära sig ramverket i tid så själva skapandet av

temat fick vi stå för.

Egna HTML Helpers användes för att generera många av våra vyers list-element. Helpers var något få

av oss hade jobbat med tidigare så det tog därför lite tid att sätta sig in i hur dessa fungerar men när

alla väl lärt sig att använda dem på ett korrekt sätt blev det dock mycket smidigt att arbeta med dem.

Då större delen av applikationen är väldigt beroende av vilken organisation, avdelning och projekt

man befinner sig i skapades det en bas-controller som alla controllers ärver av. Den har ansvaret för

att lagra applikationens tillstånd och initiera en sessionsvariabel där denna information sparas (Se

bilaga1 för klassdiagram). Samma tankar fördes vidare ut i vyerna där en bas-vymodell använder sig

av just denna sessionsvariabel för att vyerna ska veta vart användaren befinner sig i hierarkin.

Bas-vymodellen har också olika vymodeller som egenskaper så att den controller som används

skapar en egen vymodell och sparar undan information som är intressant för den aktuella vyn (Se

bilaga1 för klassdiagram).

När vi skulle implementera klarmarkeringen av loggboksinlägg började vi diskutera hur lätt det är att

råka trycka fel på en touch-enhet. Vi kom då fram till en lösning som går ut på att man först måste

“låsa upp” listan innan man kan klarmarkera och att man sedan får spara sina ändringar, något som

redan finns i deras webbapplikation men som vi ville ta bort först.

Vi fick dock problem vid uppdateringen av listan då formulärdatan, vi får från vyn, bara innehåller

information om de inlägg som blivit, eller fortfarande är, klarmarkerade. Det blev en lång kväll med

många idéer på hur vi skulle lösa detta på bästa sätt. Lösningen vi hittade blev att jämföra den

befintliga listan med den vi fick från användaren. Vi fick då jämföra varje värde för sig för att kunna

avgöra om det hade förändrats. (Se bilaga3 för exempelkod)

Då det är en projekthanteringsapplikation vi har jobbat med har det stundtals funnits väldigt mycket

information att arbeta med. Listan på information om ett projekt kan var allt mellan 3-12 punkter

vilket har gjort att vi fått brottats mycket med hur allt ska få plats utan att göra vyn för rörig eller

texten för liten. Detta var speciellt svårt eftersom vi är vana att jobba med datorers upplösningar och

skärmstorlekar. När vi väl hade anpassat oss efter mindre skärmar som till mobiler gjorde vi tester på

“pekplattor” och fick genast nya problem. Att designa “resposive” har varit något vi fått lära oss den

hårda vägen.


11

När inloggningen implementerades fick vi hårdkoda in lite användare och lösenord i en egen databas

eftersom vi inte hade tillgång till den databas som innehåller de riktiga inloggningsuppgifterna. Detta

var nödvändigt för att vi skulle kunna testa inloggning och autentisering. För Coleo att senare

implementera deras befintliga inloggningsmodul blir inte svårt.

Efter att inloggningen kom på plats började vi tänka mer på hur olika användare har olika

rättighetsnivåer och dessa skall begränsa vad man inte får tillgång till samt om man får

skrivrättigheter inom projekt eller avdelningar. Efter konsultation med vår kund lyckades vi

implementera ett rättighetssystem över hela applikationen enligt deras önskemål.

Transitionfasen För att hitta buggar testades alla funktioner frenetiskt. En del småfel upptäcktes, som att fel datum

visades på kommentarer till ett vägginlägg. Detta fel berodde på att vi hämtade ut fel datumobjekt i

vyn och var därför lätt åtgärdat. Inga större fel som “gul-fula sidor” påträffades.

Applikationens alla funktioner fungerade nu och därför beslutade vi att testa applikationen på olika

användare för att se om det var något som var svårt att förstå. Vi skrev ett gäng testfall och tog sedan

tiden för hur lång tid testpersonerna tog på sig för att utföra uppgifterna. Av resultatet framkom att

en del saker var svåra att förstå, men överlag var testpersonerna nöjda. Därför kodades det in i det

sista för att finslipa funktionerna inför slutleveransen i slutet av transitionfasen.

Teknik Coleos applikation för webben använder sig i dagsläget av ramverket ASP.NET MVC 3 och RavenDB

som är en NoSql-databas. Våra uppdragsgivare hade som önskemål att vi utvecklade i ASP.NET MVC

4 för mobilapplikationen eftersom MVC 4 har bra stöd för jQuery Mobile, det touch-optimerade

webbramverk som Coleo föreslog att vi skulle använda. Vi skrev således vår backend i C# inom ramen

för ASP.NET MVC 4.

Frontend-delen av vår applikation är uppbyggd med ramverket jQuery Mobile. Ramverket arbetar

med jQuery, HTML och CSS för att bygga upp sina vyer. jQuery är ett ramverk baserat på JavaScript.

Innehållet i vyerna som skapas upp dynamiskt på serversidan renderades ut med hjälp av vy-språket

Razor som är en del av ASP.NET. Razor kommunicerar med våra modellklasser och renderar ut html-

kod innehållande den information vi eftersöker. Den färdiga html-strukturen skickas sedan över till

klienten där JQM tolkar koden och manipulerar strukturen så den får ett mobilanpassat beteende.

Vissa delar av ramverkets funktioner fick vi dock överlagra med egen funktionalitet. Vi skrev då egna

funktioner i jQuery och fick i många fall även skriva över ramverkets css-regler för att få det önskade

beteendet och utseendet i vår applikation.

Vi fick även skapa en virtuell webbserver som plattform för leveranser av vår applikation under

utvecklingsprocessen. Vi lade kontinuerligt upp den senast fungerande versionen av vår produkt så vi

och ID-gruppen kunde utföra användartester och vi kunde även testa mjukvaran på olika mobila

enheter och skärmupplösningar.

Vi driftsatte även en instans av vår test-databas på denna server. Det var smidigt eftersom alla nu

kunde utveckla mot samma datakälla och samma testdata. Denna hade även API-gruppen nytta av i


12

sitt arbete. Alla inblandade slapp nu ha egna instanser av Raven-databasen igång på sina

utvecklingsmaskiner.

Till själva programmeringen använde vi oss av Visual Studio 2010. Vi har även versionshanterat alla våra filer med Subversion och programmet TortoiseSVN.

Resultatbeskrivning/Måluppfyllelse

Slutprodukten blev en fullt fungerande mobilapplikation som uppfyller de baskrav vi satte upp i

början av projektet.

En autentiserad användare får enkelt tillgång till information om de organisationer, avdelningar och

projekt han/hon är medlem i och kan även delegera uppgifter till sina kollegor genom loggboksinlägg.

Användare kan kommunicera med sina kollegor via gemensamma meddelandeutrymmen på

avdelnings- eller projektnivå och det finns även möjlighet att kontakta en kollega via e-post, sms eller

röstsamtal.

Man kan enkelt se vilka uppgifter man själv har att göra och det går snabbt att klarmarkera dessa

från applikationen. (Se bilaga2 för grafiska redogörelser).

Avvikelser/efterkalkyl Under projektets fortlöpande dök det upp ett par intressanta förslag på funktionalitet som vi gärna

ville implementera. På grund av de begränsningar projektgruppen hade i form av tid och personal fick

vi dessvärre utesluta dessa funktioner. En lista av dessa följer här och en längre beskrivning finns att

läsa under rubriken “Förslag på vidareutveckling”.

Privata “att-göra”-listor Ett nyhetsflöde med händelser från applikationen Notifikationer

Vi lyckades dock implementera ett av våra “bonus”-baskrav. Det gemensamma

meddelandeutrymmet, “väggen”, som hör till varje avdelning och även till varje projekt. Väggen är

ett vedertaget koncept som redan återfinns i det befintliga verktyget så steget till att implementera

det var inte så stort. Vi klarade även av att göra några extra modifikationer på hur den fungerar

gentemot deras nuvarande implementation. Att kommentera och “gilla” inlägg såg vi som relevanta

och berikande funktioner som vi valde att implementera.


13

Slutsats Det har varit ett väldigt intressant och lärorikt projekt med många tekniska områden som vi har

utvecklats inom. Det är klart den största MVC-applikation vi utvecklat vilket har gjort det viktigt att

tänka på att få en bra objektorienterad design genom hela applikationen.

Att utveckla ett mobilt gränssnitt känns extra roligt eftersom marknaden för mobila applikationer

ständigt växer och det gäller att ha en god förståelse för den domänen som utvecklare. De

utmaningar som kommer med att arbeta med nya tekniker och ramverk har varit en stor drivkraft för

alla gruppmedlemmar och vi har verkligen absorberat mycket kunskap inom dessa områden.

De lärdomar vi har fått med oss av att arbeta i grupp har gett oss mycket erfarenhet när det gäller

gruppdynamik. Det har även varit spännande att arbeta med de verktyg som finns i SCRUM och att

använda dem för att hjälpa det iterativa projektarbetet framåt.

Att ha hjälp av en grupp som avlastar arbetet med interaktionsdesign och användartestning innebar

också många nyttiga lärdomar även om det samarbetet går att utveckla ytterligare. Önskemål och

åsikter på vår implementation har gjort att hela arbetet har blivit mer intressant och levande. Det

tillförde en dynamik och känsla av genuinitet till projektet.

Det har varit svårt att på förhand uppskatta hur mycket tid de olika uppgifterna skulle ta och det har

medfört att vi ofta tog på oss mer uppgifter i varje iteration än vad vi har kunnat klara av. De

uppgifter vi inte hunnit med har fått följa med över till nästa iteration. Men om man ser till helheten

har vi ändå lyckats uppfylla de flesta uppgifter vi har tagit oss an.

Förslag på vidareutveckling

Privata “att-göra”-listor Vi såg ett behov av att kunna samla egna anteckningar och kom-ihåg-listor som inte är bundna till

något specifikt projekt eller avdelning. Det finns olika sätt att gå tillväga för att implementera en

sådan funktion. De har främst varit två förslag som diskuterats. Det första har inneburit att man har

haft en kategori och en tidpunkt kopplad till varje anteckning. Föreslagna kategorier har varit “Möte,

Deadline, Viktigt, Kom-ihåg”. Det andra förslaget har inneburit att listor med minnesanteckningar har

varit mer generella och bara gett utrymme för användaren att skriva text. Det har sedan varit upp till

användaren att själv bestämma och skapa ett system för hur dessa skall kategoriseras eller användas.

Nyhetsflöde På hemskärmen som man kommer till när man loggar in önskades en nyhetsfunktion. Det finns olika

sätt att utforma denna på och de representerar olika grundkrav på funktionen i sig. Den skulle kunna

lista aktiviteter som har inträffat sedan man var inloggad senast. Alternativt skulle den kunna lista

aktiviteter som är aktuella idag, i morgon, tre dagar framåt i olika flöden (Logginlägg som skall vara

klara, projekt som tar slut, etc...).

Den skulle även kunna ses som en mer generell nyhetslista med de senast skrivna vägginläggen eller

kommentarer på vägginlägg, vilka logginlägg som skapats eller klarmarkerats, vilka dokument som

har lagts upp eller kollegor som har tillkommit etc.


14

Även dessa olika scenarion kan delas in i två olika innehållsrelaterade kategorier. Vad är relevant för

mig som person och vad är relevant för de avdelningar och projekt jag är kopplad till? Det är en svår

avvägning att hitta rätt abstraktionsnivå och vi tror att detta måste testas under en lång period innan

vi hittar rätt.

Notifikationer Om man får ett nytt loggboksinlägg tilldelat till sig, eller om någon klarmarkerar ett inlägg som du

delegerat kunde det vara intressant att få en lite “notifikation” om det i systemet. Likaså om någon

har svarat på ditt vägg-meddelande eller eventuellt skrivit ett nytt meddelande på en vägg.

Det finns olika nivåer av “uppmärksamhetspåtvingande” hos notifikationer och även olika grader av

relevans i de händelser som skulle kunna kasta en notifikation. Även detta är något som måste testas

och undersökas för att hitta rätt balans mellan de olika alternativen.

Tillgänglig på distributionsplatser Redan från början diskuterades det om att mobilapplikationen skulle kunna säljas på

Appstore(Apples plats för köp och nerladdning av applikationer), och Google Play (före detta Android

Market, motsvarigheten till Appstore för Android enheter).

En applikation som distribueras på dessa platser kallas “Native applikation”, en applikation som är

skriven för en speciell plattform som “Android” eller “IOS”. Det fungerar alltså inte med en

mobilanpassad webbapplikation som denna är. Därför skulle vi då använda Phonegap, ett JavaScript-

baserat ramverk som hjälper en mobilanpassad webbapplikation att fungera som en så kallad

“Native applikation”. Då projektet blev större än vad vi först hade tänkt fanns det dock ingen tid att

tillämpa denna omvandling.

Filhantering Coleos nuvarande webbapplikation har stöd för viss typ av filhantering därför diskuterades denna

lösning även för mobilapplikationen. Det kan dock vara svårt att säkerställa stöd för olika filformat på

de mobila plattformar som används men det kan vara intressant att åtminstone visa vilka filer som

finns kopplade till ett projekt. Denna information kan även användas i det planerade nyhetsflödet.

Övertagande organisation Coleo Vision AB kommer ta över det samlade resultatet av vårt arbete och förhoppningsvis kommer

det stå sig bra som grund för deras fortsatta arbete med att lansera en mobilapplikation.

Litteraturförslag/dokumentationshänvisning De dokumentationer vi använt mest är nog de som finns till jQuery och jQuery Mobile Framework då detta använts flitigt vid skapandet av vårt grafiska gränssnitt. Ett jQuery-plugin vid namn “datebox” användes som datumväljare. När det gäller arbetet med databasen har vi tagit RavenDBs egna dokumentation varit till stor hjälp. Till de problemen vi haft i ASP.NET MVC har olika forum och chatter som finns på Internet används.

Vår kund Marcus Oldin har också funnits till hands för att svara på frågor.


15

Dokumentationshänvisning: jQuery - http://jquery.com/ jQuery Mobile Framework - http://jquerymobile.com/demos/1.1.0-rc.1/ jQuery Themeroller - http://jquerymobile.com/themeroller/ jQuery(datebox) - http://dev.jtsage.com/jQM-DateBox/ RavenDB - http://ravendb.net/

Förslag till förbättringar inför kommande projekt Det var från början tänkt att vår grupp skulle arbeta med testdriven utveckling, men med hänsyn till

alla nya domänområden vi skulle sätta oss in i ansåg vi att vi inte skulle få ett tillräckligt bra utbyte av

den metoden. Testdriven utveckling tar ett tag att sätta sig in i och det förutsätter även att man vet

vad det är man skall utveckla så att man kan skriva tester för det redan från början. Eftersom vi inte

riktigt visste från början hur i skulle lösa många av de problem som fanns så var det också svårt att

utveckla testdrivet.

Till en början fördes dokumentation i form av en slags dagbok flitigt, men det blev sämre och glesare

med tiden. Detta berodde mycket på att det blev många sena kvällar och när vi väl var färdiga för

dagen hade det hänt så mycket att vi knappt kom ihåg allt vi gjort.

Att prioritera vad som skrevs i dagboken kunde också varit bättre. Vissa saker som borde skrivits kom

inte in medan mindre viktig information tog plats. Dessutom borde projektrapporten ha påbörjats

tidigare och skrivits mer parallellt med projektarbetet. Nu blev det att mycket av rapporten skrevs

sista veckan.

Våra burn down charts var väldigt inkonsekventa i sin utformning. Något som hade en överskrift en

vecka kunde heta något annat en annan vecka även om den beskrev samma arbetsuppgifter. Detta

berodde till stor del på en ovana i att skriva burn down charts, men också mycket på att vi skiftade

projektledare varje vecka och att det var projektledarens uppgift att skriva veckans burn down chart.

Med tiden blev vi duktigare på detta, så man ser en klar förbättring i våra charts vecka efter vecka.

Designen ändrades mycket under projektets gång. Detta berodde på att interaktionsdesigngruppen i

början av vårt arbete inte var helt insatta i alla funktioner som skulle finnas med i applikationen och

mot slutet gav deras projektplanering inte tid för dem att sätta sig in i utformningen. De agerade i

princip smakråd snarare än designers. Detta hade kunnat lösas genom att de börjat med

designarbetet några veckor tidigare än vi började med vårt projekt, så att vi hade haft en färdig

design att arbeta efter redan vid projektets start. En annan sak som hade kunnat underlätta vore om

det fanns en interaktionsdesigner med i vår grupp, så att det arbetet på ett smidigare sätt flöt in i vår

process och att vi kunde ge varandra feedback på designen direkt utan att behöva göra det genom

formella möten.


16

Bilagor

1.1 Bas-controller

1.2 Bas-vymodell


17

2.1 Inloggning

2.2 Planering


18

2.3 Projekt info

2.4 Aktivitetslista


19

2.5 Logginlägg

2.6 Kollegor


20

2.7 Kontakt info

2.8 Väggen


21

2.9 TODO-lista


22

3.0 Uppdaterings loop

Documents

Mobilapplikation - Lnu.seorion.lnu.se/pub/education/course/1DV611/vt17/Slutrap... · 2012. 4. 3. · 3.0 Uppdaterings loop ... vilken det installerades ASP.NET 4.5, MVC 4, RavenDB,