Cob Media. Linnéuniversitetet - 1DV411 Webbprojekt I - Slutrapport

Transkript

1 Cob Media Linnéuniversitetet - 1DV411 1

2 1. Sammanfattning I nio veckor har vi fått möjlighet att både arbeta tillsammans i grupp och med en riktig kund från näringslivet. Detta för att vi ska få praktisera våra kunskaper under så verkliga förhållanden som möjligt inom programmering, kundkontakt, analys och design, kravhantering, testning och agil utveckling. Vi har även fått känna av gruppdynamiken på ett positivt sätt vilket har lett till ett lyckat samarbete mot samma mål. Tillsammans med vår kund Jacob Lindehoff, Cob Media, har vi fått bygga ett övergripande modulärt API som sammankopplar olika tillverkares API:er inom hemautomatisering till att styras från ett och samma ställe. Det huvudsakliga målet var att skapa grundfunktionalitet som tillhandahåller ett standardiserat sätt för andra hemautomatiserings-api:n att kommunicera genom. Datan från API:et ska sedan kunna presenteras och hanteras genom ett grafiskt gränssnitt. Även detta har vi utvecklat en prototyp för vidareutveckling. Syftet med denna rapport är att sammanfatta vad vi har fått lära oss i projektarbetet under kursen Webbprojekt I - 1DV411 samt reflektera över vårt arbete från start till mål. 2

3 2. Innehållsförteckning 1. Sammanfattning Innehållsförteckning Bakgrund Syfte och mål Projektorganisation Genomförande Metodik Teknik Resultatbeskrivning/Måluppfyllelse Avvikelser/Efterkalkyl Slutsats Dokumentation Samarbete/gruppmöte Kundkontakt Resultat Förslag på vidareutveckling Eventuell övertagande organisation Litteraturförslag/dokumentationshänvisning Förslag till förbättringar inför kommande projekt 16. 3

4 3. Bakgrund Automatiseringen av våra hem har pågått och ökat under de senaste åren. Men först på senare tid har det verkligen slagit igenom, mycket genom att begreppet Internet of things myntades och den efterföljande hypen av detta. I och med detta har även möjligheterna för styrning av smarta hem ökat exponentiellt, där marknaden idag svämmar över av olika produkter för styrning av allt från lampor till TV, sensorer etc. Vår uppdragsgivare Jacob Lindehoff har dock sett ett problem med detta. Nämligen att alla olika tillverkares API:er bara pratar och riktas in mot sina egna produkter. Lösningen på detta skulle vara att bygga ett övergripande modulärt API som kan kommunicera med alla dessa API:er på ett och samma ställe. 4

5 4. Syfte och mål Projektets syfte var att skapa ett sammankopplande och modulärt API som kan koppla ihop olika tillverkares API:er till att styras från ett och samma API. Projektets mål var att med i huvudsak tekniken Node.js skapa ett API, vars uppgift är att genom moduler (plugins) tillhandahålla ett standardiserat sätt för andra hemautomatiserings-api:n att kommunicera genom. Detta innebär att vårt API ska kunna väva in ett stort antal olika tillverkares produkter och att alla kan kontrolleras genom ett grafiskt gränssnitt. För att exemplifiera detta. Personen x har produkter från företag y och z. Företag y och z kommunicerar genom separata API:er. Vårt API kan dock kommunicera med både företag y och z samtidigt, varav person x kan styra alla sina enheter från ett och samma ställe. Det huvudsakliga målet är att skapa grundfunktionaliteten för detta, själva kärnan i API:et. Däromkring i mån av tid skapa ett grafiskt gränssnitt där detta API kan presentera/hantera data för användare. Samt att implementera minst ett plugin (ex. Tellus) för hantering av smarta enheter. Utöver dessa grundmål finns även delmoment och mål som krävs för genomförandet av projekt, däribland utbildning av gruppmedlemmar i Node.js, MongoDB, Git med mera. 5

6 5. Projektorganisation Vi ser på gruppen som en platt organisation, där alla arbetar mot samma mål och stöttar och kompletterar varandras kompetens och arbetsområde. Fokus ligger således för oss inte på någon form av hierarkisk indelning utan vi arbetar utifrån de behov och krav som löpande dyker upp. För att förenkla struktureringen av projektet och dess olika arbetsområden har ändå en övergripande indelning gjorts för att binda samman hela projektet och projektgruppen: Projektledare: Robert Roos Kund och kravansvarig: Henrik Gudmundsson Testansvarig: Lowe Ravio, Mathias Claesson Tekniskt ansvarig: Juhani Aavanen, Vivi Lam Då denna indelning endast var ett övergripande och förenklad syn roterades rollerna utefter behov och utefter vilken modul respektive projektmedlem arbetade med för tillfället. 6

7 6. Genomförande 6.1 Metodik Genomförandet av projektet har utförts med en kombinerad utvecklingsprocess av Unified Process och SCRUM. Hela projektperioden delades in i de fyra faserna inception, elaboration, construction och transition, och varje vecka bestod av en iteration. Som riktlinje för vad som behövde göras varje vecka återfanns en lista på alla moment på kurshemsidan som vi enkelt kunde följa och skapa vår individuella iterationsplanering. Iterationerna inleddes dagligen med ett SCRUM-möte oss projektmedlemmar emellan där dagens upplägg planerades. Problem och frågetecken togs även upp för att snabbt kunna komma på lösningar så att projektet kunde flyta på enligt iterationsplaneringen. Vi hade även under varje iteration ett handledningsmöte med vår handledare, Tobias Ohlsson, för att stämma av att projektarbetet gick mot rätt riktning samt ett kundmöte med Jacob Lindehoff för leverans av veckans prestationer. Under inceptionfasen gick mestadels tiden åt att ta in kunskaper om hemautomatisering och de olika leverantörernas API:er samt den teknik som vår kund hade som krav. Då ingen av oss hade arbetat med Node.js tidigare gick det många timmar åt att hitta bra material och lära oss denna teknik. Det var först i elaborationfasen som programmeringen tog sin början när grunden för mjukvaruarkitekturen fanns på plats, först i form av ett inloggningssystem - en boilerplate som vi använde oss utav. Då vi hade kommit överens om att arbeta med en automatiseringsleverantör åt gången var det Netatmos API vi valde att börja jobba mot. Gruppen delades in i två mindre grupper så att vi kunde arbeta på olika moduler samtidigt och beta av baskraven mer effektivt. Prototyper skapades och implementation tog fart. I samband med implementationen skapades även automatiska tester för de delar som vi jobbade på vilket resulterade i att vi inte missade viktiga beståndsdelar i programmeringen. Under hela contructionfasen har implementationen flutit på trots att den andra automatiseringsleverantörens API, Telldus Live, inte var lika lättimplementerad som Netatmos API och saknade, enligt oss, en hel del information i API-dokumentationen. 7

8 Sista veckan i transitionfasen gick åt att färdigställa de funktioner som fortfarande inte riktigt fungerade samt att finslipa både källkod och dokumentation innan slutleverans. 6.2 Teknik Kunden var klar på vilket teknik han ville att API:et skulle utvecklas i. Grundtanken var att ha det gjort i NodeJs. Detta för att det idag ger dom snabbaste responsen, vilket skulle passa bra för det tänkta API:et som vi skulle jobba fram. Inom NodeJs finns det mängder av olika moduler som man med fördel kan använda i sina applikationer. För att nämna några vi använde oss av: Express - är en modul som körs på webbservern och som lyssnar efter request. Mongodb - till våran databas. Oauth - tar hand om verifieringen i vårt API. Jade - som är ett högpresterande mall(template) för webbläsare som skrivs i JavaScript. Utöver dessa användes ytterligare ett tiotal andra moduler i projektet. Vi har använt oss av Github för att versionshantera koden. Google docs passade oss bra för dokumentationen. Vi använde oss av Postman, som är ett REST Client i webbläsaren. Med detta fick vi mer effektiv hjälp med vårt API. I Postman gjorde vi även vissa tester. De olika utvecklingsverktyg som vi i gruppen använde oss av var Sublime, Atom och Visual Studio. 8

9 7. Resultatbeskrivning/Måluppfyllelse Vi hade två stora utmaningar framför oss till en början gällande tidsplanen. NodeJs var den första som vi tog oss an. Det blev mycket självinlärning och mycket osäkerhet på hur lång tid det skulle ta att lära oss ett nytt programmeringsspråk. Men i eleborationfasen hade alla kommit igång och var insatta i just NodeJs. Andra utmaningen var att skapa ett API med NodeJs. Men ju mer vi läste på om NodeJs upptäckte vi att det finns många färdiga lösningar (middleware) som man kan använda för att komma igång, bl.a ExpressJs som hjälpte oss att få igång APIet på nolltid. Resultatet kom naturligt när vi kom igång på riktigt i constructionfasen. I arbetets gång har vi följt vår tidsplan för varje iteration. Tidsskattningen har vi till en början satt upp mer tid än förväntat på just elaborationfasen. Vi fick bra stöd av vår handledare Tobias då detta projekt var en stor utmaning. Det gjorde att alla fick ta den tid man behövde. Vi har satt upp realistiska mål som vi i stort sett har uppfyllt i varje iteration. Det som gjorde att vi avvek från tidsskattningen var att andra kursen tog upp tid från projektet vissa veckor. Men det var inget problem i sig då alla la den tid vi behövde på närliggande iterationer. Vår risklista har resulterat i att fungera som ett mindre varningssystem. Risker som varit viktiga har varit under uppsikt så vi har haft lättare att komma vidare in på nästkommande iteration. Testningen har fungerat bra med hjälp av testramverket Mocha. Det har dock även här funnits en viss inlärningskurva, speciellt tesning rörande UI och sessioner som varit en liten utmaning. Testningen har varit en stor del som vi har tagit med oss mot slutet av projektet. Vi hade tidigt satt upp en testgrupp som såg till att testmomenten inte halkade efter. Vi har användningsfall med manuella tester samt automatiska systemtester på våra moduler. Baskraven på projektet är uppfyllt. Målet att göra ett API, som generaliserar data som kommer från olika leverantörers API:er av trådlösa produkter i hemmet, har nåtts. Detta presenteras i ett stilrent UI som med hjälp av vårt API låter användaren välja vilka produkter denne vill styra och läsa data ifrån. 9

10 8. Avvikelser/Efterkalkyl Från början kändes uppgiften väldigt överväldigande. Kunden hade storartade planer på projektet samtidigt som vi inte hade något att stå på. Kunden var informerad och medveten om detta från början. Dom avvikelser som uppstod tog vi i samråd med kunden. Detta var inget som påverkade slutresultatet i någon större utsträckning Vi fick dels ta bort en leverantörs API, Philips Hue, då vi helt enkelt inte hann med implementationen av detta. Mot slutet så hann vi med en ytterligare funktion, att stänga av och på moduler i hemmet. Detta var inte ett krav som kunden ville ha men vi kände att det var en rolig och viktig funktion att få in i slutresultatet. 10

11 9. Slutsats 9.1 Dokumentationen Sammanfattningsvis kan sägas att detta har varit ett roligt och lärorikt projekt för hela gruppen. Vi har fått dra nytta av varandras styrkor och hjälpas åt att uppfylla ett gemensamt mål. Vi har fått erfarenhet av att arbeta som grupp på en gemensam kodbas med hjälp av versionshantering och även hur det är att uppehålla en aktuell projektdokumentation. I vissa stunder har vi fått påminna varandra om att ta tag i specifika dokument då dessa hamnat efter. Vi har i arbetet med de olika hemautomatiseringstillverkarnas APIer även fått erfarenheter av vad det är att jobba mot både bra och dåligt dokumenterad kod samt vilka konsekvenser det kan ha i vidareutvecklingsprocessen. 9.2 Samarbete/gruppmöte Samarbetet i gruppen har fungerat väldigt bra, alla gruppmedlemmar har bidragit med sin insats av tid, uppmuntran och engagemang. Även i stunder av trötthet och brist på motivation har vi gemensamt tagit itu med de mindre spännande uppgifterna. Genom hela projektet har vi haft dagliga SCRUM-möten i veckan som en start på dagen. Möten som vi har använt till att diskutera vad som har blivit gjort och vad som skall göras. Dessa har hjälpt oss att hålla oss uppdaterade om vad som händer och är aktuellt i gruppen. Många missförstånd och oklarheter har även retts ut under dessa möten. Längden och stilen på mötet har varit flexibelt beroende på situationen vilket har passat oss som distansstuderande helt utmärkt. 9.3 Kundkontakt Då kundens projekt som helhet var väldigt stort fanns det redan från början många delar som räknades som extra funktionalitet utöver den basstruktur som vi skulle bygga under detta projekt. Därför kom vi tidigt överens med kunden om vad som verkade genomförbart utifrån givna premisser gällande funktionaliteten som skulle implementeras. Vi anser att vi nått de funktionella kraven för projektet och tror att kunden är av samma åsikt. Med projektets storlek i åtanke önskade kunden även att vi skulle göra detta på ett sätt som gör det enkelt att fortsätta implementationen och arbetet med projektet. Om vi lyckats är givetvis en subjektiv sanning, men vi har arbetat med fokus på att ha en välstrukturerad samt väldokumenterad kod som är lätt att förstå med viss programmeringsvana, och är nöjda med resultatet. 11

12 Samarbetet och informationsflödet med kunden har fungerat bra. Vi har haft möten en gång i veckan där vi diskuterat framsteg såväl som problemområden samt presenterat arbetets aktuella tillstånd. Mot senare delen av projektet då den arkitekturella strukturen var klar har vi haft automatisk leverans till kundens online-sida varje gång koden ändrades i versionshanteringssystemet. 9.4 Resultatet Tack vare kundens intresse och kunskap inom projektområdet fick vi väldigt tydliga riktlinjer. Detta var till stor hjälp då vissa delar kunde vara rätt svåra att förstå hur de hängde ihop, fungerade och samverkade med varandra. Kunden var även öppen för förslag och höll inte stenhårt fast vid ursprungliga designval. Vi hade tex. fått välja något annat än NodeJs, som vid första anblicken såg ut att vara ett hinder då ingen i gruppen hade någon erfarenhet kring utveckling med given plattform. I efterhand kan vi dock konstatera att det var ett bra förslag från kunden för detta projekt och är glada över att vi har fått erfarenhet i ett för oss, nytt sätt att utveckla moderna applikationer. 12

13 10. Förslag på vidareutveckling Framtida utvecklingar ligger framförallt i API:et. Där varje leverantör har olika responser på sina API:er. Där behövs det anpassas efter varje leverantör. Det finns massor av funktioner som förhoppningsvis kommer att implementeras. Dels styra en dimmer, termostat, element och webbkamera. Listan kan göras hur lång som helst. Alla nya funktioner kräver att man måste in i koden både på UI och API:et och ändra för att funktionaliteten ska fungera. 13

14 11. Eventuell övertagande organisation Övertagandet kommer att ske till Cob Media som kommer att vidareutveckla projektet. Källkoden ligger öppet på github. Den som vill kan ta del av koden och fortstätta på sitt egna spår. Tanken är att vissa moduler/funktioner inte kommer ligga öppet i Github. I övrigt så ser att det är någon app-utvecklare som skulle kunna ta över. Någon som kan lägga ner tid och kunskaper att utveckla fortgående. Företag inom IOT skulle säkert vara intresserade att jobba med något som detta. Dels för att utveckla sina egna API:er och se hur andras fungerar. 14

15 12. Litteraturförslag/dokumentationshänvisning Då våra kunskaper inom NodeJs var mycket begränsade så sökte vi endast online efter det som vi behövde. Där som vi alla hamnade och fick ut mest information var från codeschool.com - online-baserade kurser där uppgifter följde med till varje video. En annan sida är plurasight.com som även codeschool samarbetar med. 15

16 13. Förslag till förbättringar inför kommande projekt Det uppstod i constructionfasen ett visst bortfall av vilja att fortsätta. Gruppen var inte lika framåtriktade. Vi insåg detta och korrigerade det, och satte in det i en risk. Men detta är en sak vi tar med oss att inte tappa fokus. Något som vi inte gjorde var att alla skulle testa att vara projektledare någon vecka. Det skulle göra att alla fick en bättre bild av hela projektet och dokumentationen. 16