Intra EV. Webbprojekt I, 1DV411. Alex Driaguine. Kristoffer Karlsson. Martin Carlsson. Joakim Holmewi. Mattias Johansson. Uppdragsgivare: Grupp 4:

Transkript

1 Intra EV Webbprojekt I, 1DV411 Uppdragsgivare: Grupp 4: Eva Vinrot, EV Konsult Rebecca Fransson Alex Driaguine Kristoffer Karlsson Martin Carlsson Joakim Holmewi Mattias Johansson

2 Sammanfattning Vi blev tilldelade kunden Eva Vinrot, från EV konsult, i kursen Webbprojekt I. Vår kund ville ha en prototyp av ett webbaserat ledningssystem som hon kunde använda till att visa upp för hennes kunder. Syftet med projektet har varit att jobba mot en verklig kund och på så sätt lära oss hur en arbetssituation kan se ut senare i arbetslivet. Syftet var också att kunna utveckla våra kunskaper om att arbeta tillsammans och driva en projektgrupp och ett projekt framåt. Denna rapport förklarar hur vi har gått till väga för att nå vårt mål, hur vi har jobbat och vad som har varit positivt och negativt i projektet. 1

3 Innehållsförteckning Sammanfattning 1 Inledning/bakgrund 3 Syfte och mål 4 Projektorganisation 5 Teknik 7 Resultatbeskrivning/måluppfyllelse 8 Metodik 9 Inception 9 Elaboration 9 Construction 9 Transistion 10 Avvikelser 11 Slutsats 12 Förslag på vidareutveckling 13 Eventuell övertagande organisation 13 Dokumentationshänvisning 13 Förslag till förbättringar inför kommande projekt 13 Screenshots 14 Frågeställningar 16 2

4 Inledning/bakgrund Ett ledningssystem har som uppgift att sammanställa information för att ge en beslutsfattare en övergripande och korrekt bild av företagets olika verksamhetsområden. Med hjälp av informationen från ett ledningssystem fattas beslut om hur man vill påverka den situation som presenteras. Ett sådant system har länge skötts med papper i tjocka pärmar. För att skapa effektiva ledningsystem har fler företag gått över till webbaserade ledningssystem. Dock finns det ändå några små företag som fortfarande använder sig utav det traditionella sättet. Eva Vinrot har i många år sökt efter ett ledningssystem som möter hennes krav. Det fanns många liknande system hon kunde köpa online, dock blev kostnaderna för höga för de små företagen hon konsulterar för då man ofta köpa dessa system i stora paket. Dessa system mötte heller inte hennes förväntningar då hennes kunder önskade ett system som är uppbyggt i flera delar och på så sätt kan vara mer anpassat efter deras verksamhet. Hon lade sedan ner jakten på detta system för cirka två år sedan. Evas kunder var inte nöjda med andra ledningssystem, då kostnaden blev för hög och man inte kunde välja bort funktioner. När Eva sedermera fick veta att IT studenter på Linneuniversitetet behövde ett projekt såg hon en möjlighet till en prototyp till sitt önskade system. Denna prototyp vill hon visa upp för sina kunder som hon konsulterar, för att på så vis visa dem hur ett mer effektivt ledningssystem kan se ut. Kunden, Eva Vinrot, ville ha ett webbaserat ledningssystem som hon kan visa upp för sina kunder så att dem får en visuell bild hur effektivt det är jämfört med ledningssystem i pärm form. 3

5 Syfte och mål Syftet med projektet är att vi ska samla på oss kunskaper om hur det är att arbeta så effektivt som möjligt i en grupp, samt att kommunicera och arbete mot en kund. Vi har även fått kunskaper om att planera och dokumentera vårt arbete. Projektets mål är att skapa en prototyp av ett webbaserat ledningssystem där användaren skall få en inblick i en verksamheten. 4

6 Projektorganisation Kursansvarig: Tobias Ohlsson Handledare: David Grenemyr Kund: Eva Vinrot, EV Konsult Scrum master, projektledare: Rebecca Fransson Test/Tekniskt ansvariga: Krisoffer Karlsson, Alexandre Driagunie Kund /Kravansvarig: Mattias Johansson Frontend ansvariga: Joakim Holmewi, Martin Carlsson Vi började med att dela upp gruppen i frontend och backend. Alla i gruppen fick också ett ansvarsområde. Vi valde att inte sätta ansvarsområdena i sten, utan alla i gruppen hjälpte till där det behövdes. Rebecca, som var scrum master, såg till att all dokumentation skrevs korrekt och att alla i gruppen följde sin tidsrapport. Hon planerade även iterationsplanerna över vad som behövdes göra under veckorna, samt såg till att alla träffades under de veckovisa mötena. Rebecca jobbade också som backend utvecklare. Kristoffer och Alex ansvarade för testerna och versionshanteringen. Deras främsta uppgift var; att se till att tester skapades och dokumenterades, att allt arbete flöt på med GitHub, samt hjälpte till vid eventuella merge konflikter. Båda två har även jobbat som backend utvecklare. Joakim och Martin sattes som ansvariga för front end då Joakim tidigare har erfarenhet av interaktionsdesign. I början av projektet arbetade de fram användarfall av interaktion med systemet. Detta för att implementering av backend skulle kunna påbörjas parallellt med skapandet av en visuell prototyp. Prototypen användes som verktyg för att dels tidigt bekräfta att kraven från kunden stämde överens med det hon ville ha, samt ge en visuell bild utav det blivande systemet. 5

7 Mattias har haft all kontakt med kunden och planerat in möten tillsammans med henne. Han har både varit delaktig som backend utvecklare, men även hjälpt till med frontend utvecklingen. Vi påbörjade varje vecka med ett handledarmöte. På mötet diskuterades dels förra veckans iteration, men det ställdes även frågor kring oklarheter till nästkommande vecka. Handledarmötet gav även bra feedback till hela gruppen. Vi har kontinuerligt planerat varje vecka genom att skriva iterationsplaner och individuella tidsrapporter. Vi har haft kontinuerlig kontakt med kunden och planerat ett möte varje vecka med denne. Detta för att minimera de risker som kan uppstå när man jobbar mot en kund. 6

8 Teknik Kunden hade inga krav på vilka tekniker som skulle användas för projektet. Vi beslutade snabbt om att använda Ruby on Rails för serversidan. Detta på grund av projektets komplexitet och ramverkets förmåga att snabbt färdigställa CRUD funktionalitet. Heroku användes för att publicera applikationen på grund av att man smidigt kan använda sig av Git för att distribuera tjänsten till vår produktionsserver. Vi har använt Bootstrap för att förenkla för frontend arbetet. Bootstrap är ett CSS/JavaScript ramverk som hjälper till med bland annat ett gridsystem som vi har använt för att uppnå en responsiv design. För att skriva CSS som är kompaktare och lättare att underhålla, har våra frontend utvecklare använt CSS preprocessorn SASS. Med hjälp av SASS har de kunnat använda variabler och nästling av selektorer. På klienten har våra frontend utvecklare skrivit en del JavaScript. Vår JavaScript kod har skrivits med hjälp av biblioteket jquery för att förenkla frontend programmeringen. 7

9 Resultatbeskrivning/måluppfyllelse I visionen satte vi upp ett antal baskrav: Hålla ned kostnaden Responsiv design för mobilanpassning Inloggningssystem Skapa, ändra och läsa uppgifter Läsa statistik Skapa och läsa nyheter om företaget Administratörsrättigheter Rollsystem för olika rättigheter i applikationen Kravet att hålla ned kostnaden kom som ett önskemål från kunden. Tanken med detta krav är att kunden vill ha ett enklare system som passar bra för mindre företag som hon konsulterar för. Den responsiva designen har vi uppnått då applikationen är funktionell och ser bra ut i olika skärmstorlekar. De funktionella baskraven har vi uppnått. Detta har vi verifierat med både automatiska tester, manuella tester och användartester. Därför anser vi att vi har skapat ett ledningssystem som motsvarar det som vi kom överens med kunden om när projektet startade. 8

10 Metodik Sammanlagt hade kursen planerat in att vi skulle lägga 180 timmar totalt per person under hela projektets gång, 10 veckor. Dock blev vår första vecka utesluten då vårt första möte med kunden inte kunde ske förrän den andra veckan i projektet. Under projektets gång har vi använt oss av arbetsmetoden Unified Process, då det är en iterativ och inkrementell ram som lämpar sig väl för denna typ av mjukvaruprojekt. Efter varje milstolpe hölls en presentation av vårt arbete. Alla grupper i kursen gjorde också en peer review på en annan grupps arbete. På så sätt kunde vi hjälpa varandra genom direkt feedback, samt ge nya idéer till projektet eller dokumentationen. Inception Under dessa iterationer låg fokus på att boka ett första möte tillsammans med kunden. Alla skulle läsa på om GitHub och bekanta oss med detta. Mycket dokumentation skulle också skrivas under dessa två veckor. I slutet utav denna milstolpe signerade kunden på visionen och vi var där med överens om arbetet. Elaboration Under elaborationsfasen låg fokus på mjukvaruariktekur samt kvalitetskrav. Kontinuerligt arbete med implementation och dokumentation fortsatte. Då dokumentationen ansågs klar påbörjades renskrivning utav denna. Vi var osäkra på hur vi skulle prioritera kraven, därför kontaktade vi kunden för att klargöra detta. Tester och testdokumentation påbörjades även under den här veckan. Construction Under denna milstolpen skulle vi arbetet med implementationen utav systemet påbörjas och avslutas. Dock hade vi redan hunnit med en hel del implementering under den förra milstolpen, vilket gjorde att vi kunde fokusera på att få klart alla 9

11 baskrav och alla funktionella krav. I början utav denna milstolpen låg designen något efter i planeringen på grund av komplexitet av att koppla ihop interaktionen mellan flera användare. Men denna kom snabbt ikapp. Sista veckan i denna milstolpen jobbade vi med att knyta ihop alla lösa trådar i projektet. Transistion Under denna milstolpe lades en sista hand för att förfina systemet, samt försökte få tag i kunden för ett leveransmöte. Innan leveransmötet gjordes några extra tester och all dokumentation uppdaterades. 10

12 Avvikelser Kravet 1.6, skapa statistik, blev ej implementerat. Kravet hade låg prioritet vilket gjorde att vi planerade att implementera detta sist. Tidsbristen gjorde dock att vi slutligen beslutade att inte göra detta kravet fullständigt. Vi hade även flera lägre prioriterade extrakrav som ej blev implementerade på grund av tidsbrist, dessa var dock extrakrav som kunden la till under arbetets gång. Vi var noga med att påpeka för kunden att dessa krav skulle implementeras i mån av tid. Kravet 2.2, dokumenthantering, påbörjades men blev dock avbrutet. Vi märkte för sent att vi ej kan skriva till filsystemet på Heroku. Vi fick även problem med att kunden ej skickade de utlovade mallarna för hur dokumenten skulle se ut. 11

13 Slutsats Under detta projekt har det varit mycket nytt för oss. Vi har lärt oss att arbeta mot en verklig kund och på så vis tagit del av det verkliga arbetslivet som väntar på oss efter examen. Vi har heller aldrig arbetat i en sådan stor grupp förut och det har gett oss många nya erfarenheter, exempelvis versionshantering på GitHub. Vi som grupp fungerade bra tillsammans. Alla i gruppen har kommit bra överens och alla har känt sig delaktiga i projektet. Efter ungefär halva projektet kändes det som att kunden tappade sitt engagemang för projektet, detta gjorde att vi tappade lite motivation mot slutet utav projektet. Vilket är synd då vi är väldigt stolta över vad vi hunnit med att göra på så få veckor. Vår slutleverans blev inte av då kunden uteblev från mötet på grund sjukdom. Slutleveransen har inte bokats om då hon ville höra av sig när hon blev frisk. Vi är nöjda med valet utav språk, ramverk och tekniker. Ruby on Rails har hjälpt oss mycket under projektet, genom att ta bort behovet av att skriva boilerplate kod av samma slag för varje resurs i projektet. Detta har snabbat upp utvecklingen och låtit oss fokusera på de viktigare delarna av projektet. 12

14 Förslag på vidareutveckling Kunden kan anställa utvecklare för att vidareutveckla applikationen till ett fullfjädrat ledningssystem. Eftersom Ruby on Rails använder sig utav arkitekturen Model View Controller är det lätt att lägga till ny funktionalitet utan att förstöra befintlig. Testdokumentation finns och koden är kommenterad, så en framtida utvecklare bör inte ha några problem att fortsätta vidareutveckling. Då det finns en kravlista med kundens önskade funktionalitet så kan utveckling sättas igång direkt. Eventuell övertagande organisation Vi har vid detta tillfället ej haft möjlighet att leverera produkten till vår kund, då leveransmötet är satt efter inlämning för denna slutrapport, vilket gör att vi ej har haft någon chans att diskutera en eventuell övertagande organisation. Dokumentationshänvisning All vår dokumentation skapades och sparades på vårt repositorium på github.com. konsult/ledningssystem/wiki På Home sidan kan man hitta länkar till alla dokumenten som varit delaktiga i detta projekt. Förslag till förbättringar inför kommande projekt De förslag vi diskuterat i gruppen är främst, att inte ta på sig för mycket arbete under projektets gång. Detta påverkade oss mycket under arbetets gången då vi ville få med så mycket som möjligt av det kunden ville ha i systemet. Därav är detta något som vi alla kommer att ta med oss vidare till nästkommande projekt. 13

15 Vi kommer även ta med oss att sätta lite mer fasta tider för utökning av projektet. Inte bara tog vi på oss väldigt många krav tidigt i projektet, vi lät även kunden lägga till flertalet mindre krav under projektets gång. Dessa accepterade vi ibland utan att analysera om det var realistiskt att genomföra, eller om vi borde ha fokuserat på några av kraven istället. Screenshots Bild 1.1: Inloggningssida som visas när man öppnar applikationen. Bild 1.2: Admins gränssnitt Hantera alla användare 14

16 Bild 1.3: Admins gränssnitt Överskådar allas arbetsuppgifter Bild 1.4: Användarens gränssnitt Överskådar sina arbetsuppgifter 15

17 Frågeställningar Vad gjorde vi bra respektive vad gjorde vi mindre bra? Tidigt under projektets gång bestämde vi oss för att träffas så ofta som möjligt. Detta visade sig vara en bra idé då vi parprogrammerade mycket och kunde bolla idéer med varandra. Ett exempel på något som vi inte borde ha gjort var att ge kunden möjlighet att lägga till fler krav under projektetsgång. Utvärdering av tidsplanen Att skriva tidsplaner är något man blir bättre på med mer färdighet. Tidsplanerna blev bättre senare i projektet tillsammans med tidsuppskattningarna. Dock är det alltid svårt att uppskatta problem, vilket gör att man lägger till en extra timme ifall problem skulle uppstå. Men detta gör också att man planerar mindre än vad man egentligen har tiden till att göra. Många utav oss har rätt blandade tidsrapporter, 25 timmar ena veckan och 15 den andra, vilket vi tycker är realistiskt ifall ett problem har uppstått eller om en person har varit frånvarande en vecka. Blev dokumentationen tillräckligt bra? Dokumentationen är något vi blev väldigt nöjda med och det har lagts ned mycket tid på den. Tack vare github är det lätt att navigera runt sig i dokumenten och alla dokumenten är sparade på samma plats. Hur fungerade informationsflödet mellan projektgrupp och kund? Informationsflödet mellan grupp och kund, hanterades genom att vi i gruppen hade kontinuerliga möten om hur det gruppen låg till och vad vi ville/behövde förmedla/fråga kunden. Där efter skickade kundansvarig e post till kunden med informationen/frågorna till kunden. Sms och telefonsamtal var även ett viktigt informationsflöde mellan kund och kundansvarig, för bokning av möte och avväjning av mer kritiska problem. 16

18 Hur fungerade samarbetet inom och utom projektet? Samarbetet inom projektet fungerade bra, vi träffades ofta och försökte lösa konflikter som uppstod snabbt. Vi kände att alla i gruppen låg på samma sida. Hur var projektmötena och handledningsmötena? Möten vi höll var lagom långa, vi försökte träffas varje dag och ha ett kort möte för att se hur arbetet gick och att alla låg i fas med planeringen. Handlednings timmarna var väldigt lärorika, det var bra att påbörja veckan med ett handledningsmöte där man kunde ta upp saker som hade hänt föregående vecka och diskutera vad som behövdes göra under veckan. Hur var riktlinjerna vi fick? Riktlinjerna för projektet, var tydligt strukturerade på kursens hemsida, vi känner att nästan all information om själva projektet var tydligt nog. det ända som vi tyckte saknades var, information om vad som skulle innefattas i de olika milstenspresentationerna. Motsvarade vi kundens krav? Vi har inte fått något svar av kunden ännu då leveransmötet är satt efter inlämning utav denna slutrapport. Gav vi realistiska förslag på lösningar? Vi känner som grupp att vi överlag gav vår kund realistiska lösningar på de problem som uppstod. Det vi kunde gjort annorlunda var däremot att inte ta på oss så mycket extra funktionalitet under projektetsgång, som påverkade oss väldigt mycket i tid. Ett exempel på detta är kalendern i applikationen. Detta var ett krav som hade en realistisk lösning, men som vi i slutändan inte hade tid att färdigställa. Vi borde ha varit mer noggranna med att analysera huruvida detta gick att färdigställa inom den givna tidsramen. 17

19 Har vi haft ett system för tidiga varningar om planerna inte följs? Tidigt i projektets första iteration arbetades en riskplan fram med relaterade åtgärder för varje risk. Detta för att snabbt ha en plan för att minimera riskens påverkan om den inträffar. Denna riskplan uppdaterades kontinuerligt om vi upptäckte nya risker under som skulle kunna påverka arbetsflödet avsevärt. Risker relaterat till kund är egentligen den risk som enskilt påverkat projektet, och detta var den risk som är svårast att ha en förberedande situationsplan till att lösa. Projektledaren har använt tidsrapporterna som indikatorer på att gruppmedlemmarna har skött sig och gjort sina uppgifter efter planeringen. Om någon inte har följt sin plan har projektledaren diskuterat med denna person för att ta reda på vad som har orsakat avvikelsen. Hur fungerade testningen? Litar ni på att systemet fungerar? Testningen har fungerat bra. Vi har använt oss av olika testmetoder för att säkerställa att systemet fungerar. Enhetstester användes för att testa enskilda komponenter för sig själv. Integrationstester användes för att testa längre sekvenser i applikationen. Självklart hade vi också användartester då manuella tester också behövs. Levererade ni kontinuerligt fungerande versioner till kund och slutanvändare? Vi levererade kontinuerligt fungerande versioner till kund, detta gjorde att vi kunde vara säkra på att vi verkligen implementerade funktioner som kunden ville ha. Någon vecka ställde vi in leveransen då vi ansåg att det inte fanns tillräckligt med ny funktionalitet att visa upp. Vad blev resultatet på kort och lång sikt? På kort sikt blev resultatet en fungerande applikation. Kunden har tänk att använda den som en prototyp för att visa upp den för sina kunder. På lång sikt har vi lämnat en applikation som är lätt att bygga vidare på för att i slutändan bli ett fullfjädrat ledningssystem som kan användas av små till medelstora företag. 18

20 Gruppmöte 19

21 Väldigt tidig skiss på systemet 20