Specialisatie RTES - Project FunnyScreens Plan van Aanpak - versie 2.2 Niels Hendriks - 89713 Matthijs Langenberg - 89870 Wiebe van Schie - 84313 Siet Toorman - 91623 Job Vermeulen - 90589 DSO Dhr. R.J.W.T. Tangelder QSO Dhr. J.W.M. Stroet 12 maart 2008
Samenvatting Versie 0.1 0.2 1.0 2.0 2.1 2.2
Datum 03-03-2008 04-03-2008 04-03-2008 05-03-2008 06-03-2008 10-03-2008
Actie Document Opgesteld Uitwerking punten mededeling Samenvoeging tot geheel Structuur gewijzigd n.a.v. DSO/QSO uur Exta hoofdstukken van de nieuwe structuur uitgewerkt Extra aanpassingen n.a.v. DSO/QSO uur
Auteurs Matthijs EII6RTb Matthijs Niels EII6RTb EII6RTb
Inhoudsopgave 1 Achtergronden 2 Projectopdracht 2.1 Opdrachtomschrijving . . . . 2.1.1 Hardware . . . . . . . 2.1.2 Afbeelding . . . . . . 2.1.3 Beheer . . . . . . . . . 2.2 Probleem aanpak . . . . . . . 2.2.1 Scrum . . . . . . . . . 2.2.2 Hardware . . . . . . . 2.2.3 Werkruimte . . . . . . 2.2.4 Garanties en kwaliteit 2.2.5 Grafische ontwikkeling
3
. . . . . . . . . .
4 4 4 4 4 4 5 5 5 5 6
3 Projectactiviteiten 3.1 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7
4 Projectgrenzen 4.1 Tijd . . . . . . . . . . . . . . 4.2 Kennis en Kennisontwikkeling 4.3 Middelen . . . . . . . . . . . 4.3.1 Begeleiding . . . . . . 4.3.2 Ruimte . . . . . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . .
5 Producten
9 9 9 9 9 10 11
6 Kwaliteit 12 6.1 Kwaliteit tussen- en eindproduct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Normen en technieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1 Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7 Software 13 7.1 Ontwikkelsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2 Software ontwikkel methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8 Project Organisatie 8.1 Project management methode 8.2 Functies . . . . . . . . . . . . 8.2.1 Scrum Master . . . . . 8.2.2 Support Officer . . . . 8.2.3 Scrum Member . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . 1
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
15 15 15 15 16 16
8.2.4 8.2.5 8.2.6 8.2.7
Projectleden en contact informatie Beschrijving projectperiode . . . . Manier van werken . . . . . . . . . Inrichten werkomgeving . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
16 16 16 16
9 Risicoanalyse 18 9.1 Interne risico’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2 Externe risico’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10 Het Team Ontwikkel Plan
22
2
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
Hoofdstuk 2
Projectopdracht 2.1
Opdrachtomschrijving
Het doel bij dit project is het cre¨eren 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.
2.1.1
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.
2.1.2
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.
2.1.3
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
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.
2.2.1
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.
2.2.2
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.
2.2.3
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.
2.2.4
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
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
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
– 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
Hoofdstuk 4
Projectgrenzen 4.1
Tijd
Voor dit project zijn 15 weken beschikbaar. De begindatum is maandag 10-03-2008 en de einddatum 2706-2008. 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 01-04-2008 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 19-05-2008 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.
4.3.1
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
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’.
4.3.2
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
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
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.
6.2.1
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 n ∗ ∗ @param par a test string ∗ @return The r e s u l t s t r i n g ∗ ∗/ Waarbij de @param tag(s) verplicht zijn als de functie argumenten aanneemt. De @return tag is verplicht als de functie een waarde teruggeeft. Alle Javadoc moet verplicht in de Engelse taal geschreven worden.
12
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
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 email op de hoogte worden gesteld.
14
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 8.2.1
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
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.
8.2.3
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.
8.2.4
Projectleden en contact informatie
Naam Niels Hendriks Matthijs Langenberg Wiebe van Schie Siet Toorman Job Vermeulen
8.2.5
Functie Scrum Member Scrum Master Scrum Member Scrum Member Support Officer
E-mail
[email protected] [email protected] [email protected] [email protected] [email protected]
Telefoon 06-19752860 06-30979867 06-18645336 06-18948032 06-50236147
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.
8.2.6
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.
8.2.7
Inrichten werkomgeving
De volgende middelen gebruiken we in onze werkomgeving • Continious build systeem • Google Subversion hosting • Google Groups • Google Calendar 16
• 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
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´s 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 ´e´en 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 Onvoldoende kennis of niveau bij de projectmedewerkers. Kans dat het gebeurt Gemiddeld Preventieve maatregelen Requirements afstemmen op kennis of niveau Niet teveel nieuwe technieken toepassen in het project Oplossing 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
Risico 2 Omschrijving Problemen met de hardware, waaronder aansturing en functioneren Kans dat het gebeurt Gemiddeld Preventieve maatregelen Goed verdiepen in de hardware Hardware van te voren testen op functioneren Oplossing 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 Risico 3 Omschrijving Onvoldoende motivatie bij projectmedewerkers. Kans dat het gebeurt Laag Preventieve maatregelen 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. Oplossing Medewerkers erop aanspreken en motiveren. In overleg gaan met ongemotiveerde medewerkers. Denken over verwijdering van ongemotiveerde medewerker. Risico 4 Omschrijving Onvoldoende inbreng eindgebruikers / opdrachtgever. Kans dat het gebeurt Laag Preventieve maatregelen Regelmatig afspreken met opdrachtgever Duidelijke prototypes / iteraties voorleggen aan opdrachtgever. Oplossing Aantal afspraken met opdrachtgever verhogen. Opdrachtgever het belang van afspraken voor het uiteindelijke product duidelijk maken. Risico 5 Omschrijving Ongeschikte scrum master. Kans dat het gebeurt
Laag omdat onze scrummaster Matthijs ervaring heeft met deze methode en voor de groep een aanwinst in kennis is. Preventieve maatregelen In goed overleg scrum master kiezen. Kijken naar eerdere ervaring scrum master. Oplossing Scrum master vervangen indien nodig. Medewerkers moeten de scrum master aanspreken op zijn taken.
19
Risico 6 Omschrijving Projectleden kunnen of willen niet met elkaar samenwerken. Kans dat het gebeurt Laag Preventieve maatregelen 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. Oplossing 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 Beschikbaarheid hardware. Kans dat het gebeurt Gemiddeld Preventieve maatregelen Hardware vroegtijdig ophalen. Hardware reserveren. Oplossing Hardware opbergen in een kluisje Bij grote schaarste van de hardware indien mogelijk met andere groepen uitwisselen Risico 8 Omschrijving Wijziging in samenstelling van de projectgroep. Kans dat het gebeurt Laag Preventieve maatregelen Duidelijke documentatie, zodat werk voortgezet kan worden door een ander. Oplossing Eventueel nieuwe groepsleden goed inlichten. Taken projectleden die vertrekken goed verdelen of overnemen. Risico 9 Omschrijving Ziekte groepslid Kans dat het gebeurt Laag Preventieve maatregelen Taken in kleine delen opsplitsen, zodat geen grote taak lang blijft liggen door ziekte. Afspraken over overnemen taken bij ziekte. Oplossing Taken overnemen. Bekijken wat het zieke groepslid nog kan doen ondanks de ziekte. Meteen de andere groepsleden inlichten.
20
Risico 10 Omschrijving Geen vervoer door staking, ongeluk of onderhoud openbaar vervoer. Kans dat het gebeurt Gemiddeld Preventieve maatregelen 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. Oplossing 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
Hoofdstuk 10
Het Team Ontwikkel Plan Zie tabel 10.1 en 10.2 voor het Team Ontwikkel Plan. Ontwikkelingsdoel
Ambient bouwen
Systeem
Programmeren met threads
Ontwerpen van een systeem zonder single point of failure
Kennis en ervaring opdoen met Scrum/XP Juiste implementatie van de sensoren
Ontwikkelingsactiviteit
Gewenst resultaat
Planning
Uitvoeren van het project
Opleveren van een systeem dat aangemerkt kan worden als zijnde een Ambient systeem.
Looptijd van het project.
Programma schijven dat gebruikt maakt van verschillende threads.
Een correct werkend programma dat gebruikt maakt van threads,zonder dat er deadlocks op kunnen treden.
nader te bepalen
java ontwikkelomgeving
Systeem zonder single point of failure
nader te bepalen
n.v.t.
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
Ervaring Scrum / XP
met
Correcte werking van de sensoren
Tabel 10.1: Team Ontwikkel Plan
22
nader te bepalen
nader te bepalen
Benodigde faciliteiten Flatscreens, sensors, embedded pc’s, java ontwikkel omgeving, svn server, continious build systeem.
Scum board, story points, white board, continious build systeem, svn server. Sensoren, datasheets, embedded pc’s, java ontwikkel omgeving
Ontwikkelingsdoel
Ontwikkelingsactiviteit
Gewenst resultaat Opleveren van een Embedded systeem. In ons geval de schermenwand, waarbij gestreeft wordt naar een zo goed mogelijke basis om verder mee te kunnen ontwikkelen en uit te breiden Goed en snel werkend netwerkprotocol dat fault tollerant en zelf herstellend is.
Embedded systeem realiseren
Ontwikkelen, implementeren en testen van een schermenwand. Dit alles met de project methode scrum/xp en testdriven development.
Ervaring opdoen met Netwerk protocol ontwerpen + implementeren
Ontwerpen en implementeren van het netwerk protocol
Effectief vergaderen
Verbeteren van de vergaderingen
Zo effectief mogelijk vergaderen
Test driven development ervaren
Test driven development, m.b.v. de informatie en ervaringen van matthijs
Ervaring opdoen met Debian kernel
Gezamelijk een dag verdiepen in de debian kernel
Kennis en ervaring opdoen hoe test driven development in zijn werk gaat. Basis kennis van Debian distributie, bekend raken met de debian command line.
Planning
Benodigde faciliteiten
nader te bepalen
flatscreens, sensors, embedded pc’s, java ontwikkel omgeving, svn server, continious build systeem.
nader te bepalen
Kennis van java, netwerk infrastructuur
nader te bepalen
vergader ruimte, eventueel ondersteuning van SOCOVA docent
nader te bepalen
?
1e increment
Debian distributie, debian naslag werk.
Tabel 10.2: Team Ontwikkel Plan (vervolg)
23
