Filhanterare med AngularJS

Transkript

1 Filhanterare med AngularJS Författare: Filip Johansson Peter Emilsson Oskar Georgsson Christian Nilsson Datum:

2 Sammanfattning Filhanterare med AngularJS är en filhanterare skapad för Sigma IT & Managment. De ska i sin tur förhoppningsvis kunna använda den i ett projekt de jobbar med åt Kristianstads kommun. Resultatet av projektet är att vi utvecklat en fungerande filhanterare och nästa steg blir nu att se om det går att integrera den i Sigmas system. Denna rapport beskriver arbetet med detta projekt samt våra reflektioner kring det. 2

3 Innehållsförteckning Sammanfattning...2 Bakgrund...4 Mål...4 Projektorganisation...5 Genomförande...5 Teknik...6 Resultatbeskrivning/måluppfyllelse...6 Avvikelser/efterkalkyl...7 Slutsats...7 Förslag på vidareutveckling...8 Övertagande organisation...8 Förslag till förbättringar inför kommande projekt...8 3

4 Bakgrund Sigma fick i uppdrag att göra om Kristianstads kommuns intranät. För att göra detta så använde de CMS verktyget EPiSERVER. Det fanns ett behov av en filhanterare i intranätet men Sigma var inte riktigt nöjda med hur den nuvarande implementationen av filhanteraren fungerade och såg ut i EPiSERVER 1, den var enligt Sigma gammal och tråkig. Därför fanns det ett behov av att utveckla en ny filhanterare som skulle vara mer funktionell och modern. Där AngularJS 2 användes för klient delen av projektet och.net för API:et. Mål Målet med projektet var att utveckla en modern och responsiv filhanterare med hjälp av AngularJS. Applikationen skulle vara av typen SPA 3 vilket betyder att sidan aldrig laddas om helt utan den uppdateras med hjälp utav JavaScript Ett Javascript MVW ramverk, 3 Single Page Application 4

5 Projektorganisation Projektstrukturen visas i diagrammet nedan. Vi har i princip inte haft någon specifik ansvarig för varje område. De områden där vi valde att ha en person tilldelad som ansvarig var kundkontakt och leverans. Detta för att kunden inte ska behöva ha flera olika personer att hålla kontakten med. Genomförande Eftersom vi har jobbat enligt Unified Process delades arbetet upp i fyra olika faser Inception, Elaboration, Construction och Transition. Under Inception-fasen skulle risker identifieras, kravspecifikation påbörjas och tekniker utvärderas. Eftersom vi redan visste vilka tekniker vi skulle använda tog denna fasen bara en vecka, och vi började programmera redan andra veckan. Under första delen av Elaboration-fasen var gruppen uppdelad i två par, ett par gjorde API:et och ett par gjorde klienten. I samband med Elaboration-fasen började vi med veckovis kundmöte, och redan under fasens andra vecka visade vi applikationen för kunden för första gången. Under Construction-fasen, som är den längsta fasen, forsatte vi med programmerandet som innan. Men vi började även med tester, både enhetstester och manuella tester. Under denna fasen 5

6 implementerade vi förhandsgranskning och det var också då som vi upptäckte att förhandsgranskning av docx-filer var svårare än väntat. Under de sista två veckorna i fasen gick mycket av tiden åt till att leta efter och fixa buggar. När Transition-fasen började hade vi implementerat alla planerade funktioner och all tid gick åt till att fixa buggar. Vi träffade även kunden för att visa upp applikationen och diskutera hur de skulle använda den i deras applikation. Teknik Kunden var egentligen bara intresserad av klient-delen och hade som krav att vi skulle använda AngularJS och Bootstrap 3. AngularJS har bra stöd för att skriva enhetstester och vi valde därför att göra det, och använda testramverket Jasmine 4. Även om API:et antagligen inte kommer användas av Sigma var vi tvungna att skapa det för att kunna testa vår klient. Sigma använder EPiSERVER, som är programmerad i C#, för resten av applikationen. Vi valde därför att programmera API:et i C# och ASP.NET MVC. Första och sista kundmötet hade vi hos Sigma i Växjö, och de andra mötena hade vi över Skype och Google Hangouts. Möten har vi haft i stort sett varje vecka för att visa applikationen och det som var nytt för veckan, vi berättade också vad vi planerade att göra veckan efter så att Sigma kunde säga om vi var på rätt väg. Vi har hela tiden arbetat tillsammans på plats på campus och använt git och Github för att versionhantera koden. Vi har använt Google Drive för hantering av dokumentation. Vi har även använt Github för hantering av buggrapporter. Resultatbeskrivning/måluppfyllelse Vi har under arbetets gång legat lite före vår grundläggande tidsplan med vissa delar som vi trodde skulle ta längre tid och legat lite efter med andra delar. I den iterationsplanen som vi tagit fram för varje vecka så har vi skattat lite för högt nästan varje gång. Vi har ändå hunnit med alla uppgifter som vi har satt upp i tidsplanen. Applikationen uppfyller baskraven som har satts upp, till exempel så finns det möjlighet att utföra grundläggande funktioner utan JavaScript, som att ladda upp nya filer och ladda ner filer. De flesta kraven implementerades, de andra ströks för att det inte fanns någon möjlighet till att uppfylla dem inom tidsramen för projektet. De krav som ströks var bl.a. förhandsgranskning av vissa filtyper som skulle tagit alldeles för lång tid. Sigma var mest intresserade av pdf och docx, vilka vi blev klara med

7 Applikationens mål var att den skulle vara responsiv och att den skulle bete sig som en SPA när JavaScript finns tillgängligt. Vi har uppfyllt båda dessa grundkrav. Den första genom att använda Bootstrap, vilket gör att man i stort sett får den responsiva delen utan att behöva bry sig så mycket om det. Genom att använda AngularJS för SPA-delen förenklas utvecklingen avsevärt. Vi har arbetat med att få applikationen responsiv och modern samtidigt som den ska vara lätt att förstå och vara användarvänlig, detta är något som vi själva anser vi har lyckats med. Det slutgiltiga resultatet efter 10 veckors arbete har gett en filhanterare som bygger på AngularJS och uppfyller de krav som ställts på applikationen. Avvikelser/efterkalkyl De avvikelser som gjorts från Sigmas ursprungliga krav är ytterligare funktionalitet som vi bestämde från början att vi ville ha med. Den största sådana avvikelsen var att vi skapade en papperskorg. Vi fick inga ändringar på funktionalitet från kund vilket underlättad arbetets gång. Det enda vi fick tänka om kring var hur docx-dokument skulle förhandsgranskas. Efter att ha undersökt olika alternativ kom vi fram till att vi inte skulle hinna med att göra en komplett lösning. Vi valde att göra en avskalad version där vi visar texten som finns i dokumentet med hjälp av ett paket i.net. Slutsats Sammarbetet i gruppen har fungerat bra. Anledningen till att det gick så bra som det gjorde var nog mycket tack vare att vi jobbade tillsammans på campus och kunde då enkelt kommunicera med varandra. Kunden ville ha en filhanterare som fungerade som slutanvändaren är van vid att en filhanterare ska fungerar. Det finns fortfarande fler funktioner vi hade kunnat lägga till, men vi tycker att filhanteraren fungerar som man kan förvänta sig att den ska fungera. Skriva dokumentation gick för det mesta bra, men vissa dokument blev inte uppdaterade så ofta. Vi hade tydlig dokumentation för API:et, men det uppdaterades inte alltid när det gjordes förändringar. Men det var inget som hindrade vårt arbete eftersom vi satt tillsammans och kunde fråga varandra om något inte fungerade som det skulle enligt dokumentationen. Något som vi tyckte var väldigt användbart och hjälpsamt var att lägga upp issues på Github, då detta underlättade mycket så man kunde hålla koll på vad andra i gruppen arbetade med när man gjort många små bugg-fixar i flera filer. Vi hade både en sprint backlog för varje iteration och en långsiktig planering. Den långsiktiga planeringen var väldigt användbar för att se hur bra vi låg till i projektet och om vi skulle behöva stryka något krav. Vi kunde ibland avvika ganska mycket i vår tidsskattning jämfört med verklig 7

8 tid, det berodde oftast på otydligt krav eller att det var en bugg som vi på förhand inte kunde gissa storleken på. Varje vecka blev den totala arbetade tiden mindre än den totala skattade. Kontakten med Sigma har fungerat bra och vi har haft kontinuerliga möten. Då vi endast visade upp våra framsteg och hade möjlighet att ställa eventuella frågor diskuterades inget onödigt. Möte en gång i veckan var helt klart tillräckligt då vi till och med ställde in ett par möten då det kändes överflödigt. Enda gången det uppstod problem var när Sigma glömde ett möte och vi fick då vänta lite på feedback men det var inget vi kunde påverka. De riktlinjer vi fick från Sigma var från början ganska diffusa. Men efter att vi tänkt igenom problemet, skrivit upp kraven och fått de godkända kände vi oss ganska klara med vad vi skulle göra. Då vi uppfyller kraven vi skrivit och Sigma godkänt både dem och det slutgiltiga resultatet ser vi det som att vi uppfyller kundens krav. Vi har de sista veckorna lagt ner väldigt mycket tid på testning och applikationen bör fungera utan större buggar, och de buggar som finns är dokumenterade. Leveranserna bestod i att vi i samband med möte med Sigma visade upp den funktionalitet som fanns på plats. Då vi inte levererade till slutanvändaren är det möjligt att det påverkade användarvänligheten, men då vi hela tiden har haft fokus på applikationen ska vara lättförstådd tror vi inte detta kommer bli ett problem. Förslag på vidareutveckling Sigma är intresserade av att kunna föra in applikationen eller delar av den i sitt system som de utvecklar. För att detta ska gå behöver API:et antagligen till stor del skrivas om eftersom den ska integreras i deras befintliga kodbas som bygger på.net och EPiSERVER. Klient-koden fungerar men kan förbättras med bl.a. bättre felhantering och validering. Förhandsgranskning skulle också kunna byggas vidare på, även om det kan vara en stor uppgift att skriva en egen förhandsgranskare för docx-filer. Övertagande organisation Efter projektet är avslutat kommer Sigma IT & Managment ta över koden och gå igenom den för att se om det finns några delar som de kan använda. Peter Emilsson kan komma att hjälpa dem med detta i sitt självständiga arbete. Förslag till förbättringar inför kommande projekt Något som vi skulle gjort annorlunda och som vi kommer ta med oss i framtida projekt är att om man ska utföra manuella testfall bör man börja med det tidigt och utförligt. Det är dels svårt att 8

9 skriva testfall i efterhand men det kan även bli väldigt mycket jobb med buggar om man väntar till slutet av ett projekt med att utförligt gå igenom testfallen. Ett annat misstag som vi i efterhand insett att vi gjort var att vi var dåliga på att färdigställa funktionalitet. Det blev att vi la väldigt stor fokus på funktionalitet som vi ansåg riskfylld och detta gjorde att man gick vidare till nya problem när man löst något istället för att fixa detaljer som validering och felmeddelanden. Detta gjorde att vi snabbare löste vår riskfyllda funktionalitet men den sammanlagda tiden blev längre då det var tidskrävande att behöva gå tillbaka och sätta sig in i funktioner man jobbat med för länge sedan. Vi lurade dessutom oss själva genom att tänka att delar av applikationen var färdigställd när det i själva verket var många timmar kvar. 9