Plan van Aanpak project Tetris Packing
Inleiding!
4
Projectomschrijving!
5
Doel van het project!
5
Onderwerp van het project!
5
Invulling van het project!
6
Producten!
7
Functioneel Ontwerp!
7
Implementatierapport!
7
Testrapport!
7
Systeemdocumentatie!
7
Aanpak!
8
Projectmethodiek!
8
Fasen!
8
Sprints!
8
Product Owner!
9
Scrum Master!
9
Product Backlog!
9
Sprint Backlog!
9
Daily Scrum Meeting!
9
Programmeer technieken!
9
Project Hosting!
9
Risicofactoren!
11
Tijdnood!
11
Ziekte!
11
Verlies, beschadiging van werk!
11
Kennis!
11
Enthousiasme / inzet!
11
Projectorganisatie!
12
Rollen!
12
Team Leader (Geert Weening)!
12
Quality Manager (Mark Rietveld)!
12
Support Manager (Ron Talman)!
12
Plannings Manager (Ingmar te Raa)!
13
Development Manager (Leander Nijland)!
13
Process Manager (Daniel van Cleef)!
13
Resources!
13
Werkomgeving!
13
Hardware!
13
Kwaliteitsborging!
14
Testen!
14
Daily Scrum Meeting!
14
Codeconventie!
14
Document en code review!
14
Begeleiding!
14
Planning!
15
1. Inleiding Dit plan van aanpak dient als handleiding voor het project “Tetris Packing”. Het doel van dit document is het omschrijven van het project en bevat de afspraken die voor dit project gemaakt zijn. Het plan van aanpak wordt opgesteld voor aanvang van het project. Er kan van het plan van aanpak worden afgeweken, maar dan wordt het plan van aanpak zelf niet aangepast. Eventuele afwijkingen worden in de voortgangsverslagen opgenomen. Het plan van aanpak is verdeeld in een aantal hoofdstukken. In het eerste hoofdstuk, “Projectomschrijving” wordt ingegaan op algemene zaken met betrekking tot het project. Het hoofdstuk “Aanpak” gaat in op de aanpak van het project. In dit hoofdstuk wordt beschreven welke methodieken en technieken er gebruikt worden tijdens het project.
2. Projectomschrijving 2.1. Doel van het project Het doel van het project is het oplossen van het bin-packing probleem in een variant die wij invullen aan de hand van een “Tetris-situatie”. Het bin-packing probleem houdt zich bezig met het vullen van zogenaamde bin's. Een bin is een container met een van tevoren bepaalde beperkte inhoud. Deze bin's worden gevuld met een van tevoren bepaald aantal blokken. Deze blokken moeten van verschillende grootte zijn en zullen dus verschillende hoeveelheid aan ruimte in beslag nemen in de binʼs. Bij het oplossen van het bin-packing probleem is het van belang dat er zo weinig mogelijk bin's in gebruik zijn wanneer alle blokken in de bin's zijn gestopt. Ook is het van belang dat het oplossen van het probleem zo weinig mogelijk resources kost. Het bin-packing probleem kan zich voordoen in zowel een één-, twee- als driedimensionale wereld. Bij dit project hebben we ervoor gekozen om het 2D-bin-packing probleem op te lossen met eventuele uitbreiding naar het oplossen van het 3D-bin-packing probleem.
2.2. Onderwerp van het project Het binpacking probleem willen wij gaan oplossen in de context van het spel Tetris. Tetris is een computerspel waarbij je als speler een aantal blokken in een twee- of driedimensionale wereld op een dusdanige manier in elkaar schuift, zodat er zo min mogelijk tussenruimtes onstaan. Voor elk volledig aaneengesloten rij worden punten toegekend en verdwijnt de rij om plaats te maken voor de overige blokken. De blokken worden één voor één op het scherm gepresenteerd en verschijnen boven in het speelveld. De blokken vallen omlaag, waardoor de speler steeds minder tijd heeft om een blok in de juiste positie te zetten. De blokken zijn roteerbaar tijdens het vallen. Wanneer een blok de al geplaatste blokken of de onderkant van het speelveld raakt, dan is de positie van het blok definitief en verschijnt het volgende blok. Dit gaat zo door totdat de blokken op zijn of totdat de geplaatste blokken de bovenkant van het speelveld raken. In het eerste geval heeft de speler gewonnen. In het tweede geval heeft de speler verloren. De blokken kunnen verschillende vormen hebben en dus verschillende grootten ruimte in beslag nemen. Hieronder kun je de standaardvormen zien die je in Tetris kunt tegenkomen.
Hieronder kun je een voorbeeld zien van een Tetris speelveld.
Het spelen van Tetris kun je zien als het oplossen van een variatie van het bin-packing probleem.
2.3. Invulling van het project Als invulling van het project willen wij bepaalde eigenschappen van Tetris gebruiken om een oplossing te vinden voor het bin-packing probleem. Wij gaan dus niet het spel Tetris ontwikkelen. De eigenschappen van Tetris die wij gaan gebruiken zijn: - Een veld is een tweedimensionaal vlak - Blokken van dezelfde standaardvormen - Blokken worden vanaf de bovenkant geplaatst - Als het blok geplaatst is, staat de positie van het blok vast Naast deze eigenschappen hebben wij ook zelf een aantal eigenschappen bedacht: - Regels verdwijnen niet na het vullen van een regel - Er wordt gebruik gemaakt van een vaste verzameling van blokken - De blokken worden door het algoritme gepositioneerd - De blokken bewegen niet meer uit zichzelf naar de onderkant toe Volgens bovenstaande eigenschappen kunnen we het onderwerp als volgt definieren: Er bestaat een 2-dimensionaal veld waarin de standaard tetris figuren (zoals hierboven beschreven) kunnen worden ingepakt. De breedte van het veld en de volledige set van blokken die ingepakt moeten worden zijn van te voren bekend. Het veld moet van onderaf gevuld worden en er moeten zo weinig mogelijk regels gevuld zijn als alle blokken ingepast zijn. De blokken mogen gedraaid worden, maar kunnen alleen in een rechte lijn naar beneden geplaatst worden. Neerzetten en schuiven is hierdoor niet mogelijk. Hiervoor heeft het veld een variabele hoogte en kan na doorloop van een plaatsing de efficientie vergeleken worden op basis van regels die in gebruik zijn.
2.4. Producten Tijdens het project zullen er naast de applicatie verschillende bijproducten opgeleverd worden. Deze worden samen met de applicatie in deze paragraaf besproken.
2.4.1. Functioneel Ontwerp Voor de implementatie wordt een ontwerp opgezet waarin de functionaliteit die geimplementeerd gaat worden staat beschreven. Dit is geen technisch ontwerp, maar een uitwerking van de functionaliteit zodat duidelijk is wat de requirements zijn van de verschillende onderdelen van de applicatie.
2.4.2.Implementatierapport Dit rapport bevat een verslag van de implementatie. Hierin staat wat voor beslissingen er zijn genomen tijdens het implementeren en waarom deze zijn genomen. Mochten er zich tijdens het implementeren problemen hebben voorgedaan, dan staan deze beschreven in het implementatierapport.
2.4.3.Testrapport In het testrapport staan de resultaten van de tests. Er wordt beschreven welke tests er uitgevoerd zijn, wat de resultaten van de gedane tests waren en wat er evenuteel nog gedaan moet worden om problemen die uit de tests naar voren kwamen op te lossen.
2.4.4.Systeemdocumentatie In de systeemdocumentatie staat de beschrijving van de verschillende onderdelen van de applicatie. In dit document staan bijvoorbeeld de Class Diagrams met uitleg.
3. Aanpak 3.1. Projectmethodiek Wij hebben besloten om Scrum te gebruiken als softwareontwikkelmethode. Dit houd in dat het projectduur onderverdeeld is in zogenaamde sprints of iteraties. Bij een scrum aanpak hoort onderstaand plaatje.
Voorafgaand aan het project stellen we een product backlog op met de beoogde functionaliteit voor de applicatie. Daarna beginnen we met een sprint waarvoor een sprint backlog wordt opgezet met de functionaliteit die voor die sprint opgleverd moet worden. Elke dag dat we aan het project werken zal er een “daily scrum meeting” worden gehouden waarin we elkaar kort vertellen waar we mee bezig zijn en of er problemen zijn. Deze dagelijkse meetings maken het makkelijker om op tijd problemen te signaleren. Na elke sprint wordt er een product opgeleverd met de beoogde functionaliteit voor die sprint.
3.1.1.Fasen Volgens Scrum kan het project in drie fasen worden opgesteld: - Voorstudie - Ontwikkeling - Test & Oplevering Tijdens de voorstudie worden de technisch en functionele specificaties van het op te leveren product vastgelegd. Doormiddel van documentatie moet duidelijk worden wat de requirements voor de applicatie zijn. In de fase “Ontwikkeling” wordt er geimplementeerd. Aan de hand van het ontwerp wordt de functionaliteit gebouwd. In de fase “Test & Oplevering” wordt de applicatie getest en opgeleverd
3.1.2.Sprints Sprints zijn vaste periodeʼs die het project onderverdelen. Voor elke sprint zullen we bovenstaande fases doorlopen. Aan het begin van een sprint wordt functionaliteit uit de backlog gepakt die voor die sprint opgeleverd moet worden. Er wordt naar deze functionaliteit gekeken en er wordt doormiddel van onderzoek en overleg duidelijk wat de requirements zijn voor de backlog items.
Vervolgens worden de backlog items geimplementeerd en aan het eind van de sprint getest zodat er een werkend product aan het eind van de sprint opgeleverd kan worden.
3.1.3. Product Owner De product owner is de opdrachtgever voor het project. In ons geval zijn dit de begeleiders vanuit school, de heer Prakken en de heer Stroet. In overleg met de product owner worden de items bepaald die in de backlog komen en waar de prioriteiten liggen.
3.1.4. Scrum Master Volgens scrum is er een scrum master die als teamleader fungeert en de voortgang van het team bewaakt. Hij leidt de meetings, deelt de sprints in en bewaakt het proces. In het geval van ons project vonden wij dit wel erg veel werk voor een persoon en hebben de taken onderverdeeld. Als de scrum master rol door een persoon ingevuld moet worden dan komt deze persoon bijna niet meer aan implementeren toe. Wij hebben de scrum master rol onderverdeeld in een Team Leader, Plannings Manager en Process Manager. De invulling van deze rollen staan beschreven in Hoofdstuk 5: Projectorganisatie.
3.1.5. Product Backlog De product backlog is een lijst met alle functionaliteit die in het eindproduct geïmplementeerd dienen te zijn. In deze lijst kunnen ook prioriteiten worden aangegeven, hiervoor gebruiken we de MoSCoW methode.
3.1.6. Sprint Backlog De sprint backlog is een lijst met functionaliteit die voor die sprint gedaan moet worden. Aan de hand van de aangegeven MoSCoW prioriteiten worden er items uit de product backlog gepakt en in de sprint backlog geplaatst. De sprint backlog kan ook activiteiten bevatten die implementatie van een bepaalde functionaliteit mogelijk maken. Dit om een beter overzicht van de benodigde tijd te hebben. Hiermee kan het opstellen van ontwerpen, documentie en planning worden opgenomen.
3.1.7. Daily Scrum Meeting Elke dag dat wij samenkomen om aan het project te werken houden wij een daily scrum meeting. Hierin overleggen we kort de volgende punten: - Wat heeft elk teamlid gedaan? - Wat gaat elk teamlid vandaag doen? - Zijn er problemen? De “Daily Scrum Meetings” gelden tot de volgende meeting. Wij werken niet elke dag met het hele team aan het project. Er zijn twee dagen dat wij samenkomen en aan het project werken. Op die dagen wordt de “Daily Scrum Meeting” gehouden en worden er afspraken gemaakt die gelden tot de volgende meeting.
3.2. Programmeer technieken Java Wij hebben er voor gekozen om ons project in Java te implementeren. Dit omdat de meeste projectleden al een goede basis in Java hebben. Dit voorkomt een voortraject waarin de taal geleerd moet worden.
3.3. Project Hosting Voor hosting van ons project maken wij gebruik van een code.google project. Op http:// code.google.com/p/eii7aab/. Deze omgeving wordt beheerd door de support manager.
Wiki Op ons code.google project hebben wij ook een wiki waarin alle gemaakte documentatie opgeleverd moet worden. Ook staat hier de taakverdeling en andere projectgerelateerde documentatie op. Voordeel van een wiki is de uniformiteit van de opmaak. Het delen van documenten met elk eigen opmaak wordt snel overzichtelijk en moeilijk samen te voegen. Versie beheer Via ons code.google project hebben wij ook de beschikking over een SVN server. Wij gebruiken SVN om de code te beheren. Ook de wiki staat in SVN.
4. Risicofactoren Elk project kent verschillende risicoʼs. In dit hoofdstuk worden verschillende risicoʼs weergegeven en zo mogelijk een passende oplossing gegeven.
4.1. Tijdnood Voorafgaand aan het project is de complexiteit van het gehele project niet goed te overzien. Het kan zijn dat we gedurende de implementatie achter zaken komen die te ingewikkeld blijken waardoor wij als projectteam in tijdnood komen. Een manier om met tijdnood om te gaan is het definieren van prioriteiten op bepaalde functionaliteit. In het geval van tijdnood krijgt een high-prio item voorrang.
4.2. Ziekte Het kan altijd voorkomen dat een teamlid ziek wordt. Als dit voor langere tijd is dan kan dit een probleem worden voor het project. Een ander teamlid moet dan het gedeelte van het zieke teamlid overnemen. Dit kan uiteindelijk resulteren in tijdnood voor het hele team. Voor ziekte geldt dan dezelfde oplossing als bij tijdnood.
4.3. Verlies, beschadiging van werk Verlies van code of documentatie kan een groot probleem worden voor het project. Dit kan gebeuren doordat bijvoorbeeld de computer van een teamlid crasht. Om te zorgen dat onze data veilig blijft gebruiken we een SVN server waar onze code en documentatie op wordt bewaard. Deze wordt ook geregeld ge-backupped door de support manager.
4.4. Kennis Mocht er tijdens het project blijken dat er te weinig kennis is van bijvoorbeeld de programmeertaal of de theorie achter de algoritmen dan kan dit problemen opleveren. Hiervan is al een gedeelte afgedekt met de orienterende taak waarin onderzoek wordt gedaan naar verschillende algoritmes, maar gedurende het project kan het nog voorkomen dat een teamlid te weinig kennis heeft. Om gebrek aan kennis op te lossen gaan de andere teamleden het teamlid zoveel mogelijk proberen te helpen bij gebrekkig kennis. Mocht dit niet voldoende zijn dan kan de hulp worden ingeroepen van een begeleider.
4.5. Enthousiasme / inzet Elk project heeft zijn leuke en minder leuke kanten en de voortgang van een project is wel gedeeltelijk afhankelijk van de enthousiasme en inzet van de teamleden. Nu hebben we geprobeerd om een projectonderwerp te vinden waar de meeste teamleden zich in konden vinden, maar toch is het mogelijk dat een teamlid zijn enthousiasme verliest. Om dit op tijd te constateren hebben we “daily scrum” meetings op de dagen waarop we aan het project werken. Tijdens deze meetings is er aandacht voor de voortgang van de werkzaamheden van de teamleden en eventuele problemen. Door deze meetings wordt het makkelijker om afname in enthousiasme of inzet in een vroeg stadium te constateren en samen met het teamlid naar een oplossing te zoeken, eventueel met de projectbegeleiding. Als er geen oplossing te vinden is in overleg met het teamlid en de projectbegeleiding dan kan het project voortgezet worden zonder het betreffende teamlid.
5. Projectorganisatie 5.1. Rollen Binnen scrum zijn is het gebruikelijk om maar twee verschillende rollen te hebben: Scrum master en developer. Onze ervaring is dat een scrum master door zijn brede rol weinig tot geen tijd overhoudt om zelf te programmeren. Wij hebben daarom besloten de rol van scrum master op te splitsen in vier rollen: Team leader, Quality Manager, Planningsmanager en Process Manager. Daarnaast is besloten om iemand verantwoordelijk te maken voor de systemen die we nodig hebben, zoals een codebeheer systeem en een tracker voor de besteedde tijd. Die rol is Support manager genoemd. Elk van deze rollen beschrijven de taken van het projectlid naast de normale taken van developer. De leden die geen extra rol invullen zullen dus meer tijd besteden aan de developer rol.
5.1.1. Team Leader (Geert Weening) Voor de Team Leader hebben we de volgende taken gevonden: - Bouw en onderhoud een effectief team, dit wil zeggen dat de doelen op gebied van tijd, kosten en kwaliteit gehaald worden en dat het team tevreden is met het project. - De teamleden motiveren om actief met het project bezig te zijn, dit houd in dat de teamleden hun geplande uren werken en documentatie op een juiste manier en op tijd inleveren - Problemen binnen het team oplossen - Opdrachtgever/begeleiding op de hoogte houden van de voortgang van het team - Vergadering effectief leiden, dit wil zeggen dat de teamleader er voor zorgt dat elk teamlid actief meedoet met de vergaderingen en andere activiteiten. Om de voortgang van het project goed in de gaten te houden en de opdrachtgever/begeleiding hiervan op de hoogte te houden is het zaak dat de teamleader elke week bijhoud wat de voortgang van het project is. Hij zal elke week moeten bekijken wat er gedaan is, wat er af is, wat er nog gedaan moet worden en wat voor problemen er zijn ontstaan of hoe deze opgelost kunnen worden. Vervolgens wordt de opdrachtgever/begeleiding op de hoogte gesteld door middel van wekelijkse rapporten en wordt de begeleiding gevraagd te helpen bij teamleden die consequent hun taak niet goed uitvoeren.
5.1.2. Quality Manager (Mark Rietveld) Voor de Quality manager hebben we de volgende taken gevonden: - Zorg ervoor dat alle geschreven code door een andere developer gereviewd wordt. Hiermee wordt de kwaliteit van de code hoger, en kunnen developers van elkaar leren. - Zorg ervoor dat alle code leesbaar is, door de afgesproken code conventie te handhaven. - Controleer dat alle op te leveren documenten dezelfde stijl hebben. - Zorg ervoor dat alle op te leveren documenten gereviewd worden.
5.1.3. Support Manager (Ron Talman) Voor de Support Manager hebben we de volgende taken gevonden: - Zorgt ervoor dat er geschikte tools voor het ontwikkelen beschikbaar zijn en functioneren. - Zorgt dat er alleen afgesproken veranderingen aan de datastructuur en het framework worden gedaan. - Zorgt dat er een issue tracking systeem beschikbaar is. - Zorgt ervoor dat eventuele servers online blijven ( SVN, Apache, SSH )
- Zorgt voor back-ups van de code
5.1.4. Plannings Manager (Ingmar te Raa) Voor de planningsmanager hebben we de volgende taken gevonden: - Leid het team bij het maken van een indeling voor de komende sprint uit de stories die nog in de backlog staan. - Houd de voortgang van het team bij en vergelijk dit met het plan. - Maak iedere week een rapport van de status van het team. Binnen scrum is het zaak dat taken worden verdeeld binnen een sprint. Het bijhouden van de voortgang door middel van het meten van verbrande story-points en het meten van de efficiency is essentieel voor het verbeteren van de planning. Deze zullen dus goed bij moeten worden gehouden. Binnen de sprint liggen de volgorde van stories niet vast, die taakverdeling wordt tijdens de daily meetings gemaakt.
5.1.5. Process Manager (Daniel van Cleef) Voor de process manager hebben we de volgende taken gevonden: - Ziet erop toe dat aan het begin van elke projectdag een korte meeting gehouden wordt. - Houdt bij hoe lang de meeting duurt en laat weten wanneer het langer dan een kwartier duurt. - Bij iedere vergadering notuleren. - Meedoen aan het ontwikkelen van de voortgangsrapportage.
5.2. Resources De volgende resources worden gebruikt tijdens het project
5.2.1. Werkomgeving Gedurende het project maken wij gebruik van een lokaal dat voor ons project ter beschikking is gesteld. Dit is lokaal W154.
5.2.2. Hardware Voor het project hebben wij de systemen ter beschikking die in lokaal W154 staan. Hier mogen wij mee omgaan volgens de regels die door systeembeheer zijn opgelegd. Deze systemen kunnen wij gebruiken om ons project op te draaien en mogelijk voor de teamleden om aan te werken.
6. Kwaliteitsborging 6.1. Testen We gaan gebruik maken van unit tests voor losse onderdelen van de applicatie. Voor het testen van de applicatie en uitvoer van de applicatie worden testen opgesteld die in het testrapport komen.
6.2. Daily Scrum Meeting Op de dagen dat we samenkomen om aan het project te werken worden “Daily Scrum Meetings” gehouden. Door deze meetings willen we controle houden op de activiteiten en vroegtijdig problemen constateren.
6.3. Codeconventie Om de code duidelijk, overzichtelijk en overdraagbaar te houden maken we gebruik van codeconventies. Voor onze code-conventies nemen we de Java Programming Language conventies aan zoals deze door Sun Oracle ( http://www.oracle.com/technetwork/java/ codeconvtoc-136057.html )
6.4. Document en code review Om de kwaliteit van de code en documentatie te waarborgen wordt de gemaakte code en documentatie door een ander teamlid gereviewed dan diegene die de code/documentatie heeft gemaakt.
6.5. Begeleiding Tijdens het project worden we begeleid door docenten vanuit school, deze vragen wij wekelijks om onze voortgang te bekijken en de kwaliteit van het project in de gaten te houden. Aan de hand van hun feedback kunnen we het project bijsturen.
7. Planning TODO
