Plan van Aanpak project Tetris Packing
Inleiding!
4
Projectomschrijving!
5
Producten!
5
Testplan!
5
Ontwerprapport!
5
Implementatierapport!
5
Testrapport!
5
Systeemdocumentatie!
5
Aanpak!
6
Projectmethodiek!
6
Fasen!
6
Sprints!
6
Programmeer technieken!
7
Project Hosting!
7
Risicofactoren!
8
Tijdnood!
8
Ziekte!
8
Verlies, beschadiging van werk!
8
Kennis!
8
Enthousiasme / inzet!
8
Projectorganisatie!
9
Rollen!
9
Team Leader (Geert Weening)!
9
Quality Manager (Mark Rietveld)!
9
Support Manager (Ron Talman)!
9
Plannings Manager (Ingmar te Raa)!
9
Development Manager (Leander Nijland)!
9
Process Manager (Daniel van Cleef)!
Kwaliteitsborging!
9
10
Testen!
10
Daily Scrum Meeting!
10
Begeleiding!
10
Planning!
11
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. Producten Tijdens het project zullen er naast de applicatie verschillende bijproducten opgeleverd worden. Deze worden samen met de applicatie in deze paragraaf besproken.
2.1.1. Testplan Het testplan bestaat uit richtlijnen voor het testen van de applicatie. Er wordt beschreven welke tests gedaan worden en hoe deze uitgevoerd zullen worden.
2.1.2.Ontwerprapport Voor de implementatie wordt een ontwerp opgezet waarin uiteengezet staat de functionaliteit die geimplementeerd gaat worden. Dit is geen volledig technisch ontwerp, maar een uitwerking van de functionaliteit zodat duidelijk is wat de requirements zijn voor de te implementeren functionaliteit.
2.1.3.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 voordoen, dan staan deze beschreven in het implementatierapport.
2.1.4.Testrapport In het testrapport staan de resultaten van de in het testplan beschreven tests. Er wordt beschreven 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.1.5.Systeemdocumentatie In de systeemdocumentatie staat de beschrijving van de verschillende onderdelen van de applicatie.
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 in 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 wordt deze functionaliteit geimplementeerd en aan het eind van de sprint getest zodat er een werkend product aan het eind van de sprint opgeleverd kan worden.
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 moet het makkelijker worden om evenutuele 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.
5. Projectorganisatie 5.1. Rollen Binnen dit project hebben we verschillende rollen onder de teamleden verdeelt om een duidelijke verdeling van taken en verantwoordelijkheden te maken.
5.1.1. Team Leader (Geert Weening) 5.1.2. Quality Manager (Mark Rietveld) 5.1.3. Support Manager (Ron Talman) 5.1.4. Plannings Manager (Ingmar te Raa) 5.1.5. Development Manager (Leander Nijland) 5.1.6. Process Manager (Daniel van Cleef)
6. Kwaliteitsborging 6.1. Testen 6.2. Daily Scrum Meeting 6.3. Begeleiding
7. Planning
