Specialisatie RTES - Project FunnyScreens Plan van Aanpak - versie 2.2

Transcriptie

1 Specialisatie RTES - Project FunnyScreens Plan van Aanpak - versie 2.2 Niels Hendriks Matthijs Langenberg Wiebe van Schie Siet Toorman Job Vermeulen DSO Dhr. R.J.W.T. Tangelder QSO Dhr. J.W.M. Stroet 12 maart 2008

2 Samenvatting Versie Datum Actie Auteurs Document Opgesteld Matthijs Uitwerking punten mededeling EII6RTb Samenvoeging tot geheel Matthijs Structuur gewijzigd n.a.v. DSO/QSO uur Niels Exta hoofdstukken van de nieuwe structuur uitgewerkt EII6RTb Extra aanpassingen n.a.v. DSO/QSO uur EII6RTb

3 Inhoudsopgave 1 Achtergronden 3 2 Projectopdracht Opdrachtomschrijving Hardware Afbeelding Beheer Probleem aanpak Scrum Hardware Werkruimte Garanties en kwaliteit Grafische ontwikkeling Projectactiviteiten Work Breakdown Structure Projectgrenzen Tijd Kennis en Kennisontwikkeling Middelen Begeleiding Ruimte Producten 11 6 Kwaliteit Kwaliteit tussen- en eindproduct Normen en technieken Javadoc Software Ontwikkelsoftware Software ontwikkel methode Project Organisatie Project management methode Functies Scrum Master Support Officer Scrum Member

4 8.2.4 Projectleden en contact informatie Beschrijving projectperiode Manier van werken Inrichten werkomgeving Risicoanalyse Interne risico s Externe risico s Het Team Ontwikkel Plan 22 2

5 Hoofdstuk 1 Achtergronden De naam van het project is FunnyScreens. De naam van het project is afgeleid van de simpele illustratie poppetjes uit Microsoft Office, ook wel screen beans genoemd. De opdrachtgever voor dit project is het lectoraat Software Engineering voor Realtime en Embedded Systems (SERTES). Het lectoraat heeft de project opdracht uitvoerig omschreven en opgedeeld in fases. Vervolgens is de opdracht uitbesteed aan de RTES groepen. Als plaatsvervangede klant, welke zal handelen in de naam van de opdrachtgever is aangewezen Dhr. Tangelder. Opdrachtnemer binnen dit project is de projectgroep EIIRT6b. Deze groep staat onder toezicht van Ir. J.W.M. Stroet, later in dit document ook wel QSO te noemen. Verder zal Dhr. Tangelder optreden als DSO en de groep begeleiden op het gebied van uitvoering. Binnen de projectgroep is de volgende organisatie structuur opgesteld. Scrum Master Matthijs Langenberg Support Officer Job Vermeulen (tevens scrum member) Scrum Member 1 Siet Toorman Scrum Member 2 Wiebe van Schie Scrum Member 3 Niels Hendriks Dit plan van aanpak bestaat uit een aantal hoofdstukken. Elk van deze hoofdstukken zal specifieke informatie bevatten welke gerelateerd is aan de naam van dit hoofdstuk. Hieronder volgt een korte opsomming van de overige hoofdstukken en de informatie welke deze bevatten. Projectopdracht Waarom wordt het project uitgevoerd. Wat is het eindproduct dat wordt opgeleverd. Projectactiviteiten Wat moet er gedaan worden om het gewenste resultaat te behalen. Producten Wat zijn de producten en tussenproducten die opgeleverd gaan worden tijdens uitvoer van het project. Kwaliteit Hoe wordt er voor gezorgd dat de kwaliteit van de producten in orde is. Projectorganisatie Wie neemt er allemaal deel aan het project, en hoe zijn de rollen en verantwoordelijkheden verdeeld. Planning Wanneer wordt wat uitgevoerd? Risico s Waardoor kan het project mislukken? 3

6 Hoofdstuk 2 Projectopdracht 2.1 Opdrachtomschrijving Het doel bij dit project is het creëren van een wand bestaande uit meerdere schermen. Deze schermen beschikken over een aantal sensoren en een mini computer. Door middel van de sensoren reageren de schermen op acties in de omgeving. Elk scherm communiceert vervolgens met het scherm naast zich over wat er is gedetecteerd of welke actie hij uitvoert. Als er niks in de omgeving gebeurt waarop gereageerd kan worden gaan de schermen in idle status. In deze status gaan de schermen automatisch acties uitvoeren. Hierbij is het ook mogelijk dat schermen reageren op acties van andere schermen Hardware De schermenwand bestaat uit meerdere nodes met een scherm en een minicomputer. Op deze minicomputers is wifi aanwezig waardoor de verschillende nodes met elkaar kunnen communiceren. Naast de schermen en de computers hebben de nodes enkele sensoren. Hierbij kan gedacht worden aan geluidssensoren, lichtsensoren en bewegingssensoren. Met deze sensoren kan er bijvoorbeeld een beweging gedetecteerd worden en kunnen de nodes hierop reageren Afbeelding Op de schermen wordt een afbeelding getoond. Hierbij kan gedacht worden aan een smiley. Deze smileys kunnen verschillende emoties tonen bij verschillende omgevings variabelen. Als bijvoorbeeld de ruimte donker wordt kunnen de smileys gaan slapen. In idle mode kan een smiley op het ene scherm een ander scherm aankijken, hierop zal de smiley op het andere scherm terug kijken. Via de afbeeldingen wordt interactie tussen verschillende nodes getoond en interactie met de omgeving Beheer Om de nodes te configureren en te beheren moeten de nodes van buitenaf bereikbaar zijn. Via een configuratie pagina is nieuwe software te updaten en de opstelling van de nodes te configureren. 2.2 Probleem aanpak Tijdens het project zullen er zich problemen voordoen. Een aantal hiervan zijn van te voren te definieren (Zie hier onder), en een aantal zullen zich pas in een later stadium tonen. Om tijd te besparen is het belangrijk 4

7 dat zo veel mogelijk problemen van te voren beschreven worden. Hierdoor zijn ze te voorzien en beter aan te pakken / op te lossen. Door het flexibele project management en de goede groepssamenwerking zullen de eventuele latere problemen ook goed op te pakken zijn. Hierbij moet echter goed opgelet worden dat het project niet blijft hangen bij een relatief onbelangrijk probleem Scrum Het project zal gedaan worden met de management methode Scrum. Scrum is een methode voor Agile software ontwikkeling. In het kort komt Scrum er op neer dat er een Scrum-Master is, een Owner (de klant) en een team van ontwikkelaars. Elke ochtend wordt er tijdens een korte vergadering met de andere project leden besproken wat er die dag zal gaan gebeuren. Met scrum wordt de beschikbare tijd onderverdeeld in zogenaamde Sprints. Per Sprint wordt er een nieuwe versie van het product opgeleverd. De (nieuwe) onderdelen die per sprint worden geimplementeerd staan in de sprint backlog beschreven. De groep heeft op dit moment geen ervaring met Scrum. Dit kan een probleem zijn aangezien dit het proces kan vertragen. Probleem aanpak: Voor het vak Capita Selecta wordt/is er een presentatie gegeven over Scrum. De groepsleden dienen hierbij aanwezig te zijn om de basis informatie over het proces te verkrijgen. De geïnvesteerde tijd zal zich later ruimschoots terugverdienen aangezien het ontwikkelproces sneller zal verlopen Hardware Een groot probleem bij een project is het afhankelijk zijn van andere personen, diensten of producten. Immers voor deze is het onmogelijk om zelf te garanderen dat iets juist gebeurt of juist werkt. Voor de hardware zijn we afhankelijk van anderen. De hardware wordt ons aangeleverd door Saxion en daardoor hebben we niet de garantie dat deze op tijd beschikbaar zal zijn, of compleet zal voldoen aan onze eisen. Daarnaast in het geval van externe hardware (Sensoren, input & output) is het moeilijk te voorzien of deze juist werken met de rest van de hardware, en ook dat de juiste software drivers beschikbaar zijn. Probleem aanpak: Probeer zo veel mogelijk informatie van de te gebruiken hardware van te voren te bemachtigen Werkruimte De toegewezen werkruimte is helaas beperkt. Er zijn niet voldoende workstations aanwezig, niet voldoende ruimte om met meerdere hardware nodes te werken, en daarnaast mist er een goed Scrum bord per groep. Probleem aanpak: Vrijwel ieder groepslid heeft de beschikking over een laptop. Deze zullen we ook intensief moeten gaan gebruiken. Gezien de beperkte ruimte zullen we met een beperkt aantal nodes tegelijk moeten werken, en het Scrumbord kan eventueel vervangen worden voor een raam of muur met post-it s Garanties en kwaliteit De Scrum ontwikkelmethode stelt dat er altijd een werkend product beschikbaar moet zijn. Het onderhouden en testen van de verschillende versies kan een boel tijd in beslag nemen. Deze tijd hebben we niet beschikbaar. Probleem aanpak: Alle applicatiecode zal met een versiebeheersysteem (SVN) worden beheerd. Daarnaast zullen we een zogenaamde continuous build applicatie gebruiken. Deze zorgt ervoor dat elke revisie op de SVN gecompiled en getest wordt. Hierdoor hebben we altijd een pre-compiled versie beschikbaar, en een overzicht van welke revesies wel/niet juist werken. 5

8 2.2.5 Grafische ontwikkeling Het project vereist een grafische interface die bestaat uit video of bewegende animaties. Gezien geen van de groepsleden ervaring heeft met het dynamisch aansturen van animaties kan dit een probleem vormen. Probleem aanpak: De animaties zullen zeer simpel gehouden worden. Daarnaast zullen we indien nodig, de hulp inroepen van een extern persoon die eventueel meer ervaring heeft met het ontwikkelen van grafische applicaties. Hierbij kan gedacht worden aan een student kunst en techniek. 6

9 Hoofdstuk 3 Projectactiviteiten 3.1 Work Breakdown Structure Plan van Aanpak Opstellen van het plan van aanpak Review van het plan van aanpak Eventuele verbeteringen aan de hand van review Backlog Opstellen concept backlog User stories uit het concept backlog onderverdelen in storiepoints + toekennen prioriteit Uitwerken van het concept backlog naar een 1e versie van de definitive backlog Sprintplanning Sprint backlog opstellen vanuit project backlog Sprint backlog doornemen met de klant PC-configuratie Linux installeren op een van de pc s Documentatie node-configuratie (scherm + minipc + eventuele sensoren) Review documentatie Verbeteren van de documentatie Protocol Ontwerp protocol Protocol implementeren en testen Geconfigureerd netwerk Opstellen netwerkontwerp Instellen van netwerk aan de hand van het ontwerp Documentatie netwerk configuratie Review documentatie 7

10 Verbeteren van de documentatie Saxion groep server Installeren van een continuous build systeem Configureren van het continious build systeem Testen van continious build Hardware Installeren en testen van een node Kernel van de node updaten Standaard image voor de node ontwikkelen Onderzoeken welke sensoren geschikt zijn voor het project Implementatie van de sensoren Documentatie werking van de sensoren Review van de opgestelde documentatie over de sensoren Reflecties Persoonlijke reflectie aan het eind van het project Groepsreflectie per voltooide sprint Oplevering eindproduct Opleveren van de documentatie van alle increments Opleveren van de ontwikkelde software Opleveren van de hardware Assesments Eindverslag Product presentatie Afronding increments 1e increment wordt afgesloten met een presentatie van het PvA & project omschrijving 2e increment wordt afgesloten met een groeps interview 3e increment wordt afgesloten met een presentatie en eindassesment 8

11 Hoofdstuk 4 Projectgrenzen 4.1 Tijd Voor dit project zijn 15 weken beschikbaar. De begindatum is maandag en de einddatum De 15 weken die voor het project staan zijn verdeeld in increments van ieders vijf weken. Elke increment zal ook weer worden onderverdeeld in twee gedeeltes, genaamd sprints. Elke sprint duurt 12 werkdagen. Er dient rekening gehouden te worden dat van deze 15 weken een aantal dagen af gaan in verband met opendagen en de nationale feestdagen. Netto zouden er dus 72 werkdagen beschikbaar zijn voor dit project. Het project team heeft onderdeling afgesproken dat er per week 4 dagen van 8 uur gedraaid gaan worden. Gedurende de eerste twee increments zullen er nog colleges zijn die gevolgd moeten worden. Naast deze colleges zijn er nog de diverse huiswerk opdrachten. Tevens zullen de meeste colleges bij moeten wonen voor hun keuze module. Geschat wordt dat 2/3 van de beschikbare tijd gaat zitten in de diverse colleges en het huiswerk daarvan. Uitgaande van een 36 uurige werkweek blijft er dan 12 uur per week over voor het project. In het begin zal dus het grootste gedeelte van de tijd gaan zitten in de diverse verplichtingen ten aanzien van de ondersteuning van deze specialisatie en de keuze modules. Naar mate de tijd vordert zal er meer tijd beschikbaar komen voor het project. Onze verwachting is dat vanaf er minimaal 1/2 van de beschikbare tijd bruikbaar zal zijn voor het project (18 uur), gezien er op dat moment een lesmodule wegvalt. Vanaf zal naar alle waarschijnlijkheid 3/4 deel van de beschikbare tijd bruikbaar zijn voor het project (24 uur). Enkel de keuze (les) modules zijn dan nog ingeplanned naast het project. 4.2 Kennis en Kennisontwikkeling Elk lid van het projectteam is verantwoordelijk voor het beschikbaar hebben van voldoende kennis. Zowel technische als niet-technische kennis vallen hieronder. Mocht een lid onvoldoende kennis bezitten, dan zal hij deze kennis moeten ontwikkelen door onder andere zelf studie. 4.3 Middelen Dit project heeft de volgende middelen ter beschikking voor het voltooien van de opdracht Begeleiding Het projectteam wordt begeleid door een QSO en DSO. De QSO is voornamelijk verantwoordelijk voor de kwaliteitsbewaking en ziet er op toe, dat de opgeleverde producten en documentatie van voldoende kwaliteit is. 9

12 De DSO bewaakt de voortgang van het project en meldt de groep zonodig wanneer hij signaleert dat het zo niet verder kan. In eerste instantie is de groep natuurlijk zelf verantwoordelijk voor het opleveren van producten en documentatie van de juiste kwaliteit, en de voortgang van het totale project. Dit zal uitgebreider worden behandeld onder onder meer het hoofdstuk Kwaliteit Ruimte In lokaal W1.15 is een vaste werkplek gereserveerd voor de projectgroep. Hier kan de groep gebruik maken van 3 computers, white board enz. Daarnaast zal de CII Plaza dienen als vergader plek voor de DSO en QSO uren. Vergaderingen van de groep zullen worden gehouden in beschikbare ruimtes, op de Daily stand up meeting na. Deze zal in W1.15 worden gehouden aangezien daar het scrum board bijgehouden gaat worden. 10

13 Hoofdstuk 5 Producten Zoals al eerder aangegeven bij het hoofdstuk Probleem aanpak zal het project worden uitgevoerd volgens scrum. Dit heeft als gevolg dat er lang niet zoveel (tussentijdse) producten opgeleverd zullen worden als bij andere project ontwikkel methodes zoals bijvoorbeeld TSP. Bij dit project worden de volgende producten opgeleverd: Plan van Aanpak Ter voorbereiding van het project wordt vooraf aan de hand van de opdracht omschrijving een plan van aanpak opgesteld. In dit plan van aanpak zal onder andere worden vast gelegd wat de opdracht inhoud, wat de project grenzen zijn, het aantal uren dat per week gemaakt wordt en de rollen van de groepsleden. Verder zal het plan van aanpak ingaan op de wijze waarop het project ingericht en uitgevoerd zal gaan worden. Tussentijdse increment documentatie Tussen de increments zal de bijbehoordende documentatie zoals beschreven bij het eindverslag opgeleverd worden. Eindverslag Aan het eind van het project wordt een verslag opgeleverd met daarin de nodige informatie over het product. Hierin wordt de programma stuctuur, systeem architectuur en verantwoording van gemaakte keuzes besproken worden die hebben geleid tot het eindproduct. Eindproduct Aan het eind van het project wordt ook een eindproduct opgeleverd. In dit product zijn een aantal user stories geïmplementeerd. Het product zal voldoende worden gedocumenteerd zodat een volgende groep het verder uit kan breiden in een volgend project. 11

14 Hoofdstuk 6 Kwaliteit 6.1 Kwaliteit tussen- en eindproduct De totale project tijd is onderverdeeld in drie increments, waarvan elke increment weer bestaat uit twee sprints. Tijdens deze sprints zal steeds een (klein) deel van het totaal aantal stories van het project uitgewerkt worden. Gedurende het gehele project zal er steeds een werkende versie zijn. Deze werkende versie zal steeds iets verder uitgebreid worden totdat het project is afgerond. Doordat tijdens de sprints steeds deelproducten worden opgesteld, gereviewd, getest en verbeterd. Kan tijdens de gehele loopduur van het project de kwaliteit behouden blijven. Het eindproduct dat uiteindelijk opgeleverd gaat worden, zal hierdoor meerdere malen gecontroleerd en verbeterd zijn. Het is dan ook de bedoeling dat aan het eind van het project een definitief eindproduct op tafel ligt, dat is ontstaan door de prioriteiten die de klant heeft gesteld aan de vooraf gestelde functionaliteiten. 6.2 Normen en technieken De op te leveren software dient ontwikkeld en geïmplementeerd te worden volgens aangeleerde en gebruikelijke technieken. Dit houdt in dat er ten minste aan de volgende punten moet worden voldaan. Tijdens de code-review wordt ook gecontroleerd of aan deze punten daadwerkelijk zijn gevolgd Javadoc Alle java code die geschreven wordt dient voorzien te zijn van javadoc. Javadoc is de standaard methode om classes van commentaar te voorzien. Javadoc wordt boven de class of functie declaratie geschreven op de volgende manier: / This i s a d e s c r i p t i o par a t e s t s t r i n The r e s u l t s t r i n g / Waarbij tag(s) verplicht zijn als de functie argumenten aanneemt. tag is verplicht als de functie een waarde teruggeeft. Alle Javadoc moet verplicht in de Engelse taal geschreven worden. 12

15 Hoofdstuk 7 Software 7.1 Ontwikkelsoftware Voor de ontwikkeling van de applicatie(s) zullen twee programmeertalen worden gebruikt. Namelijk: Java is een objectgeorinteerde programmeertaal. Historisch gezien is Java een platformonafhankelijke taal, die qua syntaxis grotendeels gebaseerd is op de (eveneens objectgeorinteerde) programmeertaal C++. Java beschikt echter over een uitgebreidere klassen-bibliotheek dan C++. Tijdens het ontwikkelen zullen wij de laatste stable versie van de Java 5 SDK gebruiken. Ruby is een dynamische open-source programmeertaal dat zich focust op duidelijkheid en productiviteit. Het heeft een elegante syntax die simpel is om te begrijpen en makkelijk is om te schrijven. Wij zullen de laatste stable versie van deze software gebruiken voor onder andere de webinterface. We maken gebruik van Java als algemene programmeertaal, omdat hiervan de meeste kennis beschikbaar is. Op het moment dat Ruby geschikter is om in te zetten wordt deze taal ook als keuze overwogen. We beschouwen een taal als geschikter wanneer de toepassing van deze taal er voor zorgt, dat het aantal story points van een story daalt. Bij de Ruby ontwikkelingen zal Matthijs vooral de kar gaan trekken. Op het moment dat Matthijs dit door omstandigheden niet kan doen worden de implementaties in Java gedaan. Er wordt voor Ruby gekozen om de kennis van de groep te verbreden en omdat Matthijs expertise op dit gebied kan bieden. Voor de ontwikkeling van de applicatie kunnen verschillende IDE (Integrated Development Environment) tools gebruikt worden, maar als groep hebben we gekozen om Eclipse te gebruiken. Door de keuze van slechts 1 IDE zal de formatting van de code altijd in de zelfde stijl zijn. 7.2 Software ontwikkel methode We kiezen ervoor om Test Driven Development (TDD) te gebruiken om de software te ontwikkelen. De ontwikkelingen in Java zullen gestuurd worden door gebruik te maken van Junit en jmock. De Ruby ontwikkelingen zullen gestuurd worden door gebruik te maken van het RSpec framework. We ontwikkelen de software outside-in dat betekent dat eerst de buitenste laag geschreven wordt (meestal de GUI of een webinterface), en we gebruiken mocks om de interface met de diepere laag te ontdekken. Dit zorgt voor modulaire en uitbreidbare code. Naast Test Driven te ontwikkelen vinden we ook dat het controleren van elkaars code erg leerzaam en nuttig is. Daarom kiezen we er voor om, wanneer mogelijk, met twee mensen de software te schrijven (Pair Programming). Let wel dat deze vorm van ontwikkelen erg vermoeiend is en niet langer dan enkele uren 13

16 per dag vol te houden is. Wanneer de software door een enkele persoon ontwikkeld is, is het de taak van deze persoon om een taak op het scrum-board aan te brengen waarop staat welk deel van de code nog door iemand anders bekeken moet worden. Dit gebeurt bij voorkeur tijdens de daily-scrum meeting. Ook streven we naar het principe van Collective code ownership. Ieder teamlid is verantwoordelijk voor alle code in het project. Het mag niet voorkomen dat er voor een bepaald deel van het systeem (bijvoorbeeld een Class of File) iemand speciaal verantwoordelijk is. Wanneer er in een paar gewerkt wordt aan een stuk software is er een persoon die de eerste tests schrijft. De ander probeert daarna de code te schrijven om de test te laten slagen. Wanneer dat gelukt is wordt er van rol gewisseld. De persoon die zojuist de implementatie heeft gemaakt mag nu een test schrijven voor een volgende vereiste van het systeem. Daarna mag de persoon die de eerste test heeft geschreven voor de implementatie zorgen. We maken gebruik van een Continuous Integration machine de continue de kwaliteit van de software controleerd. Daarnaast zorgt deze machine dat de laatste versie van de geproduceerde software en documentatie op een vaste plaats beschikbaar is. Om dit te realiseren zal er een linux server worden opgezet waarbij we door middel van een script een repository-checkout zullen doen als de SVN data is aangepast. Met deze checkout-data wordt er een nieuwe build gemaakt van de software, en daarnaast worden alle tests uitgevoerd. Als de testresultaten positief zijn zal de nieuwe build (en eventueel documentatie) beschikbaar komen voor download in een released-directory. Mocht de nieuwe build of de test(s) een negatief resultaat geven dan zal de groep daarvan per op de hoogte worden gesteld. 14

17 Hoofdstuk 8 Project Organisatie 8.1 Project management methode Binnen het project wordt Scrum als management methode gebruikt. Scrum heeft een aantal voordelen die ons erg aanspreken, en is daarom ook gekozen als methode. Er wordt gewerkt met een storyboard. Op dit board is in een oogopslag precies te zien hoe ver de sprint gevorderd is, en welke taken er nog gedaan moeten worden. Dit geeft iedereen veel overzicht en duidelijkheid. Alle taken worden opgeschreven op kleine briefjes. Deze briefjes worden op een whiteboard geplakt. Op dit kaartje wordt ook een schatting van het aantal story points opgeschreven. Op het moment dat een taak wordt gestart plakt men het kaartje van Todo naar In Progress. Bij het voltooien wordt het kaartje naar Done verplaatst. Iedere project ochtend wordt er een daily stand-up meeting gehouden, hierbij is iedereen aanwezig. Binnen een kwartier wordt door de scrum master met elk projectlid besproken Wat heb je gister gedaan? Wat ga je vandaag doen? Wat zijn de lopende probleemen? Hierna gaat men aan de slag. Ook zorgt men binnen scrum dat op elk moment van de dag, er een werkend programma te zien is. 8.2 Functies Scrum Master De scrum master leidt de daily stand-up meetings in goede banen. Tijdens deze meetings zorgt hij er voor dat een ieder aan de beurt komt en niet te uitgebreid verhaal doet over alles. De scrum master bewaakt dus tevens de tijd tijdens de daily stand-up meetings. Naast de taken van scrum master, is de scrum master tevens scrum member. Taken van de scrum master zijn Leiden daily stand-up meetings Opstellen sprint info page na afloop van de sprint planning bijeenkomst Aankondige start nieuwe sprint via mail Het bijhouden van de backlog en de burndown-chart 15

18 8.2.2 Support Officer De support officer binnen het team is verantwoordelijk voor de materialen. Hij beheert de google group, google svn en daarnaast ook de groepsserver waar het continious build systeem / software op draait. Naast deze taken is de support officer ook een scrum member Scrum Member De term scrum member is een andere benaming voor een projectlid. Een scrum member neemt deel aan het team en de user stories die uit de backlog van de sprint uitgewerkt dienen te worden. Daarnaast neemt een scrum member deel aan de vergaderingen, sprint planning en de daily stand-up meetings Projectleden en contact informatie Naam Functie Telefoon Niels Hendriks Scrum Member wolkerson@gmail.com Matthijs Langenberg Scrum Master mlangenberg@gmail.com Wiebe van Schie Scrum Member wjlvschie@gmail.com Siet Toorman Scrum Member xandrios@gmail.com Job Vermeulen Support Officer vorigeweek@gmail.com Beschrijving projectperiode De projectperiode bestaat in totaal uit 75 werkdagen, deze zijn verdeeld over drie increments. We kiezen ervoor om de periode op te delen in zes sprints van 2.5 weken (12 dagen). Tussen 2 sprints is er een peride van 2 dagen. In deze periode is er 1 dag welke dient voor demonstratie doeleinden en reflectie op de afgelopen sprint. De andere dag in deze periode zal worden gebruikt voor het opstellen van de sprintplanning voor de volgende sprint Manier van werken Tijdens het project zullen we werken volgens de Scrum project management methode. Dit betekent dat we een backlog gaan aanmaken en tijdens de sprint planning een deel van de backlog om gaan zetten in een sprint backlog. Elke dag houden we een daily scrum meeting. Vanwege de nog lopende colleges is hiervoor nog geen vaste tijd gekozen. Op een scrum-board houden we de voortgang van de backlog items bij, ook gebruiken we een burndown chart om de voorgang gedurende de sprint in de gaten te houden. De backlog items worden in een online document bijgehouden voor zowel overzicht en backup. Van het scrum-board wordt bij elke grote verandering een digitale foto gemaakt als backup. Dit voor het geval dat er iets mis gaat met het daadwerkelijke board. Nadat we een sprint hebben afgerond houden we een sprint demo en kijken we terug op de afgelopen sprint. Een dag later gaan we de sprint planning voor de volgende sprint houden Inrichten werkomgeving De volgende middelen gebruiken we in onze werkomgeving Continious build systeem Google Subversion hosting Google Groups Google Calendar 16

19 Drie computers op onze project werkplek Deel van een whiteboard voor notitie s. Deel van een muur als scrum-board. Digitaal gedeeld document voor de backlog Digitale foto(s) van het scrumboard als backup 17

20 Hoofdstuk 9 Risicoanalyse Binnen het project zijn verschillende risicofactoren aanwezig. De nodes zullen zoals gezegd allemaal met elkaar communiceren, een duidelijk risico is dat deze communicatie niet zonder problemen verloopt. Denk hierbij aan hardware problemen, maar ook zeker software fouten. De gebruikte hardware heeft zijn goede en slechte eigenschappen. Zo zijn de mini-pcś zoals het woord al zegt klein, maar hierdoor kan men sneller tegen warmte en snelheidsproblemen oplopen. Ook is de hardware slecht te upgraden danwel te repareren, waarbij ook de beschikbaarheid van de hardware een risico is. Dit risico bestaat ook voor de sensoren, deze zijn vaak door hun grootte ook moeilijk te repareren. Tevens kunnen er mogelijk problemen ontstaan door slechte drivers voor Linux, aangezien lang niet alle hardware altijd goed ondersteund wordt. Aangezien we allemaal ook geen echte Linux-experts zijn kan er zich ook een kennis probleem voordoen bij eventuele aanpassingen van de Linux-kernel. Het volgende risico is de grafische kant, deze zal erg bepalend zijn voor het succes van het product. De aansturing van animaties is voor alle projectleden compleet nieuw en zal dus mogelijk ook een kennis risico kunnen zijn. Het uitvallen van één of meer projectleden kan ook de vordering van het project beïnvloeden. Door de gekozen engineeringsmethoden is dit risico wel beperkt. 9.1 Interne risico s Risico 1 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Onvoldoende kennis of niveau bij de projectmedewerkers. Gemiddeld Requirements afstemmen op kennis of niveau Niet teveel nieuwe technieken toepassen in het project Mensen met ervaring op het gebied de anderen laten informeren Met zijn allen op zoek naar oplossingen Zoeken naar alternatieven waar wel kennis van is 18

21 Risico 2 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Risico 3 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Risico 4 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Risico 5 Omschrijving Kans dat het gebeurt Problemen met de hardware, waaronder aansturing en functioneren Gemiddeld Goed verdiepen in de hardware Hardware van te voren testen op functioneren Mensen met ervaring op het gebied de anderen laten informeren Met zijn allen op zoek naar oplossingen Zoeken naar alternatieven waar wel kennis van is Onvoldoende motivatie bij projectmedewerkers. Laag Mensen taken geven die ze goed liggen (in overleg) Vervelende taken goed verdelen. Goede werksfeer scheppen. Redelijke eisen stellen aan medewerkers, geen onmogelijk zware dingen vragen. Medewerkers erop aanspreken en motiveren. In overleg gaan met ongemotiveerde medewerkers. Denken over verwijdering van ongemotiveerde medewerker. Onvoldoende inbreng eindgebruikers / opdrachtgever. Laag voor de groep een aanwinst in kennis is. Preventieve maatregelen Oplossing Regelmatig afspreken met opdrachtgever Duidelijke prototypes / iteraties voorleggen aan opdrachtgever. Aantal afspraken met opdrachtgever verhogen. Opdrachtgever het belang van afspraken voor het uiteindelijke product duidelijk maken. Ongeschikte scrum master. Laag omdat onze scrummaster Matthijs ervaring heeft met deze methode en In goed overleg scrum master kiezen. Kijken naar eerdere ervaring scrum master. Scrum master vervangen indien nodig. Medewerkers moeten de scrum master aanspreken op zijn taken. 19

22 Risico 6 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Projectleden kunnen of willen niet met elkaar samenwerken. Laag Duidelijke afspraken maken over de samenwerking. Scheiden van werk en prive (bij problemen). Projectleden die niet goed met elkaar overweg kunnen aan verschillende taken zetten. Gesprek voeren met de projectleden die het probleem veroorzaken. Indien niet anders kan, de projectleden uit de groep verwijderen. 9.2 Externe risico s Risico 7 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Risico 8 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Risico 9 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Beschikbaarheid hardware. Gemiddeld Hardware vroegtijdig ophalen. Hardware reserveren. Hardware opbergen in een kluisje Bij grote schaarste van de hardware indien mogelijk met andere groepen uitwisselen Wijziging in samenstelling van de projectgroep. Laag Duidelijke documentatie, zodat werk voortgezet kan worden door een ander. Eventueel nieuwe groepsleden goed inlichten. Taken projectleden die vertrekken goed verdelen of overnemen. Ziekte groepslid Laag Taken in kleine delen opsplitsen, zodat geen grote taak lang blijft liggen door ziekte. Afspraken over overnemen taken bij ziekte. Taken overnemen. Bekijken wat het zieke groepslid nog kan doen ondanks de ziekte. Meteen de andere groepsleden inlichten. 20

23 Risico 10 Omschrijving Kans dat het gebeurt Preventieve maatregelen Oplossing Geen vervoer door staking, ongeluk of onderhoud openbaar vervoer. Gemiddeld Zorgen dat bepaalde taken ook thuis uitgevoerd kunnen worden. FTP-server inrichten, zodat bestanden ook thuis bereikbaar zijn. Van tevoren de groep inlichten als het mogelijk is. Waar mogelijk alternatief vervoer regelen. Mensen thuis laten werken. Taken die alleen op school kunnen laten overnemen door anderen indien van hoge prioriteit. Taken overnemen van anderen die wel thuis kunnen. 21

24 Hoofdstuk 10 Het Team Ontwikkel Plan Zie tabel 10.1 en 10.2 voor het Team Ontwikkel Plan. Ontwikkelingsdoel Ontwikkelingsactiviteit Gewenst resultaat Planning Benodigde faciliteiten Flatscreens, sensors, embedded Opleveren van een systeem dat aangemerkt kan worden Ambient Systeem Uitvoeren van het Looptijd van het pc s, java ontwikkel bouwen project project. omgeving, svn als zijnde een Ambient systeem. server, continious build systeem. Een correct werkend programma Programma schijven dat gebruikt java ontwikkelom- Programmeren met nader te bepalen threads maakt van verschillendgeving threads. Ontwerpen van een systeem zonder single point of failure Kennis en ervaring opdoen met Scrum/XP Juiste implementatie van de sensoren Schermen wand zo ontwerpen dat elke node awareness heeft van zijn omgeving. Essentiele stukken data zijn bekend bij elke node Het uitvoeren van een project volgens de richtlijnen van scrum/xp Correcte werking van de communicatie tussen de sensoren en Debian Tabel 10.1: dat gebruikt maakt van threads,zonder dat er deadlocks op kunnen treden. Systeem zonder single point of failure Ervaring Scrum / XP met Correcte werking van de sensoren Team Ontwikkel Plan nader te bepalen nader te bepalen nader te bepalen n.v.t. Scum board, story points, white board, continious build systeem, svn server. Sensoren, datasheets, embedded pc s, java ontwikkel omgeving 22

25 Ontwikkelingsdoel Ontwikkelingsactiviteit Gewenst resultaat Planning Benodigde faciliteiten Opleveren van een Embedded systeem. In ons geval Ontwikkelen, implementeren en flatscreens, sensors, de schermenwand, testen van een embedded pc s, waarbij gestreeft Embedded systeem schermenwand. Dit java ontwikkel omgeving, svn server, wordt naar een nader te bepalen realiseren alles met de project zo goed mogelijke methode scrum/xp continious build basis om verder en testdriven systeem. mee te kunnen development. ontwikkelen en uit te breiden Ervaring opdoen Ontwerpen en Goed en snel werkend netwerkproto- Kennis van java, met Netwerk protocol ontwerpen + van het netwerk implementeren col dat fault tollerant en zelf hersteltuur nader te bepalen netwerk infrastruc- implementeren protocol lend is. Effectief vergaderen Test driven development ervaren Ervaring opdoen met Debian kernel Verbeteren van de vergaderingen Test driven development, m.b.v. de informatie en ervaringen van matthijs Gezamelijk een dag verdiepen in de debian kernel Tabel 10.2: Zo effectief mogelijk vergaderen Kennis en ervaring opdoen hoe test driven development in zijn werk gaat. Basis kennis van Debian distributie, bekend raken met de debian command line. Team Ontwikkel Plan (vervolg) nader te bepalen nader te bepalen? 1e increment vergader ruimte, eventueel ondersteuning van SOCOVA docent Debian distributie, debian naslag werk. 23