sida 1 Grupp 6 co-browsing 1DV411 - Webbprojekt I Författare: Markus Axelsson Stavros Gemitzoglou Axel Hernborg Joakim Jonsson Rickard Karlsson Peter Magnusson Termin: VT2014
sida 2 Sammanfattning Denna rapport beskriver det projektarbete vi utfört under kursen Webbprojekt 1 vid Linnéuniversitetet. Kursen började med en gruppindelning, följt av att alla grupper sedan blev tilldelad en kund. Vår grupp blev tilldelad att arbeta med Linnéuniversitetet som uppdragsgivare. Projektet gick ut på att bygga en co-browsingapplikation med 1177 sjukvårdsrådgivning i åtanke. Detta innebar att vi tillsammans med vår kund Martin Östlunds befintliga kanalsystem skulle bygga en applikation som gör det möjligt att via Internet ge sjukvårdsrådgivning på ett tydligt och smidigt sätt. Vår kund ville ha verktyg i applikationen för att en rådgivare lätt kan förmedla viktig information och vara säker på att rådtagaren ser och förstår den. Den resulterade applikationen innehåller så gott som all den funktionalitet kunden efterfrågade men saknar vissa finnesser och mindre features. Det finns även kända buggar i applikationen som inte blev lösta utan istället dokumenteras och skickas till kunden så att denne kan åtgärda dem på egen hand när han fortsätter arbetet på applikationen.
sida 3 Innehållsförteckning Sammanfattning sid 2 Innehållsförteckning sid 3 1.Inledning sid 4 2. Syfte och mål sid 4 3. Projektorganisation sid 5 4. Genomförande sid 6 4.1 Metodik sid 6 4.2 Teknik sid 6 5. Resultat sid 7 5.1 Översikt sid 7 5.2 Dokumentation sid 7 5.3 Testning sid 7 5.4 Avvikelser sid 8 6. Slutsats sid 8 6.1 Slutprodukten sid 8 6.2 Kundkontakt sid 8 6.3 Arbetssätt sid 8 6.4 Gruppdynamik sid 8 7. Förslag på vidareutveckling sid 9 8. Förslag till förbättringar inför nästa projekt sid 9 9. Övertagande organisation sid 9 10. Dokumentationshänvisning sid 9
sida 4 1. Inledning 1177 är en sammanslagning av 1177 och Stockholms läns vårdguide och är nu Sveriges samlingsplats för information, sjukvårdsrådgivning och tjänster inom hälsa och sjukvård. Genom att ringa till numret 1177 så kan man få sjukvårdsrådgivning över telefon och det har under en tid vuxit fram ett behov för sjukvårdsrådgivaren att kunna påvisa någon specifik information på 1177:s hemsida för den som ringer in och behöver rådgivning. Det finns också några fall då patienter har hittat information på Internet som de kanske känner sig osäker på stämmer och vill kunna visa rådgivaren för att kunna verifiera. I dagsläget finns det ingen sådan lösning som har den grad av säkerhet som krävs för 1177 och har den funktionalitet som krävs för att kunna samtidigt visa samma webbplats för både rådgivaren och patient samt att på ett enkelt sätt tydliggöra specifika delar av en webbplats. 2. Syfte och mål Målet med applikationen är att kunna dela samma vy mellan två olika webbläsare. Detta skulle kunna bli ett centralt verktyg för en sjukvårdsrådgivare som arbetar på 1177.se. Syftet med applikationen är att låta sjukvårdstagaren vara mer interaktiv, samt att kunna få tydlig och snabb information om specifik sjukvård som visas på hans/hennes webbläsare.
sida 5 3. Projektorganisation Redan från vårt första möte med vår kund i projektet så etablerade vi en bra kundkontakt och vi fick en väldigt bra bild av vad som skulle göras och vi gav våra tankar om hur det skulle utföras och vår kund gav direkt feedback på detta. Detta initiala möte med vår kund ledde till att vi bestämde med vår kund att det vore bra att ha åtminstone ett möte varje vecka. Vår motivation till att ha veckoliga möten var för att vi ville kunna få feedback på det vi åstadkommit under den föregående iterationen och få en riktlinje på vad som bör göras inför nästa. Utöver kundmötet varje vecka så höll vi också kontakt via e-post med vår kund och tack vare att vår kund var så delaktig så var det mycket vi kunde få snabb hjälp med även över e-post. När det gäller vår organisering inom gruppen så bestämde vi i början av projektet att det vore bäst att arbeta tillsammans för att kunna arbeta effektivt utan dröjesmål för hjälp och input av gruppen. I början av projektet så tilldelade vi även huvudansvariga för de tre stora delarna för vårt system (markering, synlighet, säkerhet) och det var dessa huvudansvariga som såg till att implementation kom på plats och mötte kraven som kunden ställt. Se nedan för en grafisk illustration av vår projektorganisation.
sida 6 4. Genomförande 4.1 Metodik Projektet har utförts med ett agilt tänk och med en iterationslängd på en vecka. Varje iteration har bestått av ett möte med handledaren i början av veckan vars syfte har varit att avstämma den föregående iterationen och försöka dra någon slutsats av vad som skulle kunna göras bättre, vad som kommer härnäst och lite allmänna råd från vår handledare. Hela projektgruppen har under dessa veckor alltid arbetat tillsammans i universitets datorsalar och i början av varje dag så har vi gått igenom vad som behöver göras idag och vem som ska göra det. Detta har bidragit till en bra utvecklingsmiljö och eftersom vi alltid arbetat så nära varandra så har de problem som uppstått snabbt kunnat lösas tillsammans. Samtliga i projektgruppen har vid något tillfälle under projektet agerat projektledare men detta var inget vi utnyttjade fullt ut utan vi tog samtliga beslut gemensamt under hela projektets gång för att på bäst sätt hantera utvecklingen och få en så bra produkt som möjligt. 4.2 Teknik Då större delen av applikationen handlar om att manipulera och lägga till element och textnoder i en webbplats HTML så blev vårt val av teknik begränsat till klientbaserade språk. Denna del av systemet har skrivits i JavaScript med stor hjälp av det kända biblioteket jquery. Det finns så klart flera alternativ till JavaScript som till exempel CoffeScript och ECMAScript men eftersom ingen i vår projektgrupp är bekanta med dessa varianter så föll det till JavaScript. RequireJS blev stommen till vår applikation då kunden önskade en hög modularitet för att enkelt kunna lägga till eller byta ut funktionaliteten i applikationen, tack vare RequireJS kunde vi uppnå en bra struktur för applikationen med en hög nivå av modularitet. När det gäller autentiseringen av rådgivare som sker via OAuth2.0 och vår back-end som sköter all kommunikation mot OAuth-server så är det skrivet med PHP. Vi valde att arbeta med PHP för att det är lätt att komma igång med och att det inte krävs så stor utvecklingsmiljö för att arbeta och testa med. Det vore såklart möjligt att göra samma sak med t.ex..net, Java, Ruby eller vilket serversidespråk som helst.
sida 7 5. Resultat 5.1 Översikt Projektet gick överlag som planerat. Genom att följa de planer vi la upp för varje iteration men samtidigt våga lägga tid på andra uppgifter om det varit nödvändigt så har vi lyckats uppnå nästintill alla krav som vi nämnde i vår vision. Även om vi inte uppnådde alla krav som vi kom överens med vår kund om så fick vi i slutändan en produkt som vår kund var nöjd med och som hade alla viktiga beståndsdelar med en bra kodartikektur som uppnådde den nivå av kvalité av såväl koden, dokumentation men även strukturen som vår kund eftersökte. Det bör också nämnas att de krav vi inte uppnådde i slutändan var enbart UI-relaterat. Vårt system var så kallat feature complete med all funktionalitet som vår kund ville ha men tyvärr så saknas vissa grafiska element som hade förhöjt upplevelsen. Vi anser dock att detta är försumligt med tanke på att systemet är en prototyp och inte en leveransfärdig produkt. 5.2 Dokumentation Vår dokumentation är något av en svaghet från detta projekt. Samtliga i gruppen har under projektets gång varit ganska så dåliga på att dokumentera sin kod och redogöra för hur den fungerar och vad den gör. Detta ledde till att vi i slutet av projektet fick sitta tillsammans och gå igenom varje modul och skriva förklarande och lättförstådda kommentarer på så väl en övergripande och en detaljerad kodnivå. När det kommer till dokumentation som rör projektet i helhet så som kravspecifikation och vision så har vi inte heller varit så duktiga. Vi har inte varit så noga med att uppdatera våra krav under projektets gång trots att vi tillsammans med vår kund förändrat målbilden flera gånger. I iterationsplanerna har vi varje vecka skattat tiden för varje uppgift men varit dålig på att följa upp med den faktiska tiden det tog att utföra uppgiften. Detta gör det svårt att avgöra hur bra vi skattat tiden för varje uppgift, men vi har uppfyllt nästan alla krav inom tidsramen.
sida 8 5.3 Testning Testning är en svår del av ett projekt och det var något vi inte hade räknat med. Ingen av oss är vana testare och det uppstod problem när vi försökte hitta vettiga och bra testfall för att testa vårt system vilket ledde till att hela vår utvecklingsprocess blev väldigt touch and go. Genom en snabb koll på vår testdokumentation så inser man rätt snabbt att vi inte utfört så många systemtester. Detta är en miss av oss men det kan förklaras av sättet vi valde att utveckla och dokumentera. Vårt system består av många moduler och mellan dessa moduler finns det controllers som styr beteendet mellan dessa moduler och för att komma igång så snabbt som möjligt så satt vi om 1 eller 2 personer och arbetade med en modul och det var inte förrän i slutet av projektets gång som vi faktiskt knöt ihop dessa moduler till det system som finns nu. Detta sätt att utveckla bidrog till att det inte gick att utföra ett fullständigt systemtest förrän i slutet men under hela utvecklingen så har alla moduler enskilt blivit testade och buggfixade flera gånger om. Slutligen så är vi inom projektgruppen överens om att själva testningen sköttes bra men att det återigen var vår dokumentation som fick lida och att vi borde ha skrivit testfall och testrapporter för alla modultester vi utfört. 5.4 Avvikelser Den avvikelse vi hade resultatmässigt i vårt system var att vi inte hann implementera alla sätt att utöka och minska en markering. I slutskedet lyckades vi få in funktionalitet för att kunna utöka och minska en markering med hjälp av knappar, precis som vår kund ville, men tyvärr så sker detta på teckennivå och inte på ord- eller meningsnivå, vilket var något kunden efterfrågade. Anledningen till att denna funktionalitet inte blev som vi hade tänkt var att vi felbedömde hur lång tid och hur avancerat det skulle vara att implementera detta och inte lade riktigt så mycket tid som behövts för att denna redigeringsfunktionalitet skulle bli hundra procent testad och implementerad.
sida 9 6. Slutsats 6.1 Slutprodukt Resultatet blev en fullt fungerande applikation som uppfyllde större delen av de krav som vi tillsammans med kunden kommit överens om. Vi hade med stor sannolikhet lyckats klara alla kraven om vi hade varit lite mer uppmärksamma på att vissa krav skulle vara svårare att implementera. Detta medför att applikationen är så gott som feature complete, men mindre features så som att redigera markeringar ett ord i taget inte implementerades. När vi startade projektet så var inte målet att ha en fullt färdig produkt utan en utvecklad och genomtänkt prototyp som kunden kan utvärdera och vidareutveckla efter slutleveransen, men vi hade gärna velat leverera en applikation med alla krav. Eftersom vi har haft bra kontakt med kunden under hela projektet så har vi hela tiden haft en diskussion kring de områden som vi trott vara problematiska eller att vi inte skulle hinna implementera. Både vi i gruppen och kunden är således nöjd med produkten och vi tycker att det varit en nyttig erfarenhet och ett roligt projekt. 6.2 Kundkontakt Vi tycker att vår kontakt med kunden i projektet har fungerat väldigt bra. Genom att hålla oss till det vi kom överens om i början av projektet med att ha kundmöte ofta som möjligt så har vi som förutspått kunnat hålla vår kund delaktig, intresserad och haft honom tillgänglig för feedback genom hela projektets gång. Den höga frekvensen av möten kombinerat med att kunden varit väldigt lättillgänglig också bidragit till en lättare utvecklingsprocessen och gjort det möjligt att undvika missförstånd. Att ha kundmöten så ofta som vi hade var för det mesta positivt men ett misstag vi gjorde var att alltid vara hela gruppen vid dessa möten. Problemet med detta var att det försvann väldigt många timmar och vi förlorade viktig tid vi skulle kunnat utnyttjat till implementering. En lösning på detta problem hade varit att vi delat upp oss och låtit de huvudansvariga för varje del av systemet haft varsitt enskilt möte med vår kund och låtit de andra arbeta vidare med implementationen.
sida 10 6.3 Arbetssätt Sättet vi valde att tackla denna uppgift vi fick var att vi tillsammans med vår kund hittade tre huvudområden (säkerhet, markering och synlighet) och delade upp oss om två personer till varje del. Detta var till en början en bra indelning av gruppen och fördelningen av uppgifter till varje person gick bra men ju närmare slutet vi kom och ju mer kompletta varje del blev desto svårare blev det att hålla på vår gruppindelning. Detta ledde till att när säkerhetsbiten var klar så fick den lilla gruppen ta sig an andra uppgifter som låg nära de andra grupperna och utan att ha varit med vid utveckling av dessa delar så tog det tid att sätta sig in i koden och förstå hur allt var uppbyggt. 6.4 Gruppdynamik Att vara hela sex stycken i gruppen har varit en utmaning, men också mycket lärorikt. Gruppdynamiken har fungerat över förväntan och inga konflikter har uppstått under projektets gång. Vi har haft en rolig tid tillsammans och lärt känna varandra betydligt bättre, vilket vi aldrig hade gjort ifall vi inte gjort detta projekt. Utmaningen med att vara en sådan pass stor grupp som vi var har varit att se till att alla haft tillräckligt med arbete och kunnat jobba relativt självständigt med olika delar. Detta har stundvis fungerat bra, men under vissa tillfällen har vi fått gå ihop och sitta tillsammans med olika uppgifter då det varit svårt att hitta nya. Detta är naturligtvis inte enbart negativt utan det har funnits fördelar med att koda tillsammans eftersom man som två programmerare ofta kan bidra med mer problemlösning än en. Det ska dock nämnas att det är en fin linje mellan att vara för många och för få som arbetar med samma sak. Under projektets gång så drog vi den slutsatsen att två stycken som kodar tillsammans är lagom medan tre blir för många.
sida 11 7. Förslag på vidareutveckling Applikationen skulle kunna användas inom betydligt fler områden än sjukvårdsrådgivning. Vår kund har redan öppnat för möjligheten att i framtiden kunna använda vår kod till liknande problemområden. En av anledningarna till att ett av kraven var att skriva applikationen i små moduler var för att underlätta vidareutveckling. Ett förslag är att exempelvis bygga ett system där fler än två personer kan co-browsa och göra det till en social än tjänst där användare tillsammans kan utforska olika webbsidor. 8. Förslag till förbättringar inför nästa projekt I framtida projekt hade vi antagligen sett till att inte vara en så stor grupp som arbetar för att lösa ett relativt begränsat problemområde. Det har varit en utmaning att se till att alla har uppgifter att göra och stundvis har en del i gruppen endast kunnat sitta med och hjälpa till på olika delar. Vi hade mycket kontakt med vår kund och frekventa möten, vi borde dock ha sett till att anteckna vid mötena för att se slippa ta upp samma saker om och om igen, men också för att under arbetet slippa lägga tid på att försöka komma ihåg vad som senast sagts om hur vissa delar ska implementeras. En annan del som vi antagligen kommer lägga mer fokus på vid ett framtida projekt är testning. Under detta projekt har vi förlorat mycket tid på att skriva alltför många testfall för delar i applikationen som inte ens implementerats. Vi visste mycket väl om att delar av kraven skulle komma och ändras under projektets gång och trots detta la vi ner mycket tid i början på att skriva testfall som sedan blev helt oanvändbara. Innan vi började arbeta bestämde vi inte någon arkitektur för koden utan alla arbetade på med sin kod och mot slutet blev det dags att slå samman alla delar istället för att direkt ha bestämt ett arbetssätt och jobbat efter det under hela projektet. Det blev inget jätteproblem men det var ganska onödigt då koden fick klippas ut, klistras in och modifieras minimalt för att alla delar skulle fungera tillsammans. 9. Övertagande organisation Vi överlämnar all kod och teknisk dokumentation till Martin Östlund på Linnéuniversitetet. 10. Dokumentationshänvisning http://172.16.202.2/1dv411/2014/p6/documentation/