Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen milestones 1
Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het team Tom Strickx Brecht Van Laethem Bram Bruyninckx Roeland Matthijssens Gil Moeremans Goedele Van kerkhoven 2
Inhoudsopgave 1 Inleiding 4 1.1 Projectoverzicht.................................... 4 1.2 Definities........................................ 4 1.3 Referenties....................................... 5 2 Projectorganisatie 5 2.1 Externe communicatie................................. 5 2.2 Interne structuur.................................... 5 2.3 Functies en verantwoordelijkheden........................... 5 3 Management Processen 6 3.1 Project Opstart Plan.................................. 6 3.1.1 Kosten schatting................................ 6 3.1.2 Personeelsplan................................. 7 3.1.3 Trainingsplan.................................. 7 3.2 Werkplan........................................ 7 3.2.1 Activiteiten................................... 7 3.2.2 Planning.................................... 8 3.3 Risico Management Plan................................ 10 3.4 Afsluitingsplan..................................... 11 4 Technisch Proces Plan 11 4.1 Procesmodel...................................... 11 4.2 Methoden, tools en technieken............................ 11 3
1 Inleiding 1.1 Projectoverzicht Het project voor de cursus Software Engineering bestaat uit de ontwikkeling van een portaal web-site voor het aanmaken en spelen van location-based games. Voor de technische eisen verwijzen we naar het SRS document. Het project heeft een driedelig doel: 1. Ontwikkelen en onderhouden van een groepwebsite. http://wilma.rave.org/~se1_1011/ Eens deze website online is, zullen de deliverables daar te vinden zijn. 2. Ontwikkelen van een portaal web-site voor het aanmaken en spelen van location-based games. Gebruikers kunnen inloggen en dan bepaalde routes spelen of nieuwe routes aanmaken aan de hand van een template. Dit dient te gebeuren conform de IEEE standaard 1058.1-1987. 3. De studenten vertrouwd maken met software-ontwikkeling in teamverband. 1.2 Definities SPMP: Software Project Management Plan Dit documement beschrijft hoe het softwareproject beheerd zal worden. Dit houdt in dat er onder andere gekeken wordt naar functieverdelingen, kostenplanning, het beheer van risico s, de te gebruiken ontwikkelingsmethoden, etc. Men zal hiervoor gebruik maken van de IEEE 1058 standaard. SCMP: Software Configuration Management Plan Dit document beschrijft hoe alle deliverables opgeslagen worden en op welke manier veranderingen aan de deliverables beheerd worden. Men zal hiervoor gebruik maken van de IEEE 828 standaard. SQAP: Software Quality Assurance plan Dit document beschrijft aan welke eisen de deliverables moeten voldoen zodat deze van voldoende hoge kwaliteit zijn. Men zal hiervoor gebruik maken van de IEEE 730 standaard. STD: Software Test Plan Dit document beschrijft op welke wijze de te schrijven software zal getest worden. Men zal hiervoor gebruik maken van de IEEE 829 standaard. SRS: Software Requirements Specification Dit document beschrijft aan welke vereisten de te schrijven software moet voldoen. Men zal hiervoor gebruik maken van de IEEE 830 standaard. SDD: Software Design Document Dit document beschrijft het design van de abstracties van het te schrijven programma. Men zal hiervoor gebruik maken van de IEEE 1016 standaard. DM: Document Manager Deze persoon is verantwoordelijk voor de algemene layout van alle documenten. De DM dient ook alle documenten na te lezen op grammaticale en/of spellingsfouten. 4
1.3 Referenties Wikipedia, Scrum http://nl.wikipedia.org/wiki/scrum_(softwareontwikkelmethode) 2 Projectorganisatie 2.1 Externe communicatie De klant voor dit project is Prof.Ragnild Van Der Straeten, bijgestaan door Pieter Wellens. 2.2 Interne structuur Er zijn verschillende functies binnen dit project. Voor elk project is er een hoofdverantwoordelijke en een reserve-verantwoordelijke. De verantwoordelijke van elke functie rapporteert aan de project manager. De verschillende functies zijn: Project manager Configuration manager Design manager Quality Assurance Manager Requirements manager Webmaster 2.3 Functies en verantwoordelijkheden Elk lid heeft de volgende verantwoordelijkheden: uitleg: Hij moet aan anderen uitleg kunnen verschaffen over zijn werk indien dat gevraagd wordt. assistent manager: Hij houdt zijn assistent manager nauwlettend op de hoogte. deadlines: Hij dient ervoor te zorgen dan al zijn artifacts volledig en correct zijn tegen de afgesproken deadline. controle: Hij zorgt ervoor dat zijn documenten minstens 2 dagen voor de deadline in de repository beschikbaar zijn zodat deze door andere leden van de groep te raadplegen zijn ter controle indien zij dat wensen. up-to-date: Hij dient ervoor te zorgen dat al zijn documenten up-to-date zijn gedurende het volledige verloop van het project. duidelijkheid: Hij dient ervoor te zorgen dat zijn werk zo duidelijk mogelijk is. timesheets: Hij dient 1 maal per week zijn timesheets in te vullen op de groepswebsite. Elke functie heeft zijn eigen verantwoordelijkheden: 5
Project manager Eindverantwoordelijke project Vergaderingen voorbereiden en voorzitten SPMP opstellen en onderhouden Configuration manager Verantwoordelijk voor installatie en goede werking van versie-controle-systeem SCMP opstellen en onderhouden Design manager Verantwoordelijk voor het algemene design van de applicatie Verantwoordelijk voor het design en beheer van de database SDD opstellen en onderhouden (op basis van SRS) Controleren op naleving van SDD bij implementatie Quality Assurance Manager SQAP opstellen en onderhouden STD opstellen en onderhouden Requirements manager SRS opstellen en onderhouden Controleren welke requirements al voldaan zijn Extra functionaliteit zoeken en omzetten naar requirements Webmaster Opzetten en onderhouden van de communicatie-website 3 Management Processen 3.1 Project Opstart Plan 3.1.1 Kosten schatting Men gebruikt COCOMO als methode om de kosten in te schatten. Dit project kan als semidetached geclassificeerd worden. Dit komt omdat de programmeerervaring zeer sterk verschilt van persoon tot persoon in het team. Bovendien is de gebruikte taal voor dit project ongekend bij de meerderheid van de mensen. De teamleden hebben bovendien zeer sterk verschillende uurroosters waardoor samen in groep programmeren zeer moeilijk is. De COCOMO-formules zijn: T M = a kloc b T DEV = c T d M N = T M T DEV 6
De variable T M is de moeite nodig en is uitgedrukt in manmaanden. T DEV is het aantal maanden nodig om de applicatie te ontwerpen. N is het aantal mensen dat nodig is en kloc is een schatting van de lengte van de code, uitgedrukt in aantal duizend lijnen code. Voor een semi-detached project krijg je volgende waarden voor de variabelen: a = 3 b = 1, 12 c = 2, 5 d = 0, 35 Door analyse van SPMP s van de vorige jaren, komt men op een schatting van 5 voor kloc. T M = a kloc b = 3 5 1,12 = 18, 2 manmaanden T DEV = c T d M = 2, 5 18, 2 0,35 = 6, 9 maanden N = T M /T DEV = 18, 2/6, 9 = 2, 64 mensen Na een vergelijking van verschillende bronnen, blijkt dat een gemiddelde ITer een brutoloon van ongeveer 3500euro heeft. Geschatte kostprijs: cest = N T DEV 3500 = 63750euro. 3.1.2 Personeelsplan Beslissingen over teamleden dienen altijd gesteund te worden door een meerderheid van het team. Roeland: design manager (database,applicatie), backup configuration manager Brecht: project manager, backup requirement manager Goedele: document manager, secretaris, backup design manager Tom: configuration manager, webmaster communicatie-website, backup project manager Gil: requirement manager, backup quality manager Bram: quality manager, backup document manager 3.1.3 Trainingsplan Indien een bepaald teamlid een gebrekkige kennis heeft, zijn volgende acties mogelijk: doorverwijzen naar literatuur / tutorials, workshop (gezamenlijk of individueel), presentatie, etc. 3.2 Werkplan 3.2.1 Activiteiten Documenten SPMP: geschreven door projectmanager SCMP: geschreven door configuration manager SQAP: geschreven door quality manager STD: geschreven door quality manager SRS: geschreven door requirements manager SDD: geschreven door design manager 7
Code Zie het ticketsysteem van de software project managment tool om te kijken wie welke code gaat schrijven. 3.2.2 Planning Vergadering Er wordt normaal gezien om de 2 weken vergaderd. Hier kan van afgeweken worden indien er niets te bespreken valt of de situatie een vergadering op een vroegere datum noodzakelijk maakt. Dit zal dan door de projectmanager meegedeeld worden aan de andere leden van de groep. Deadlines Deadline 1: 3/11/2010 Deadline 2: 12/11/2010 Deadline 3: 14/12/2010 (einde 1ste iteratie) Deadline 4: 22/12/2010 Deadline 5: 20/02/2011 (interne deadline) Deadline 5.bis: 23/02/2011 (interne deadline) Deadline 6: 8/03/2011 (einde 2de iteratie) Deadline 7: 16/03/2011 Deadline 8: 8/04/2011 (einde 3de iteratie) Deadline 9: 27/04/2011 Deadline 10: 20/05/2011 (einde 4de iteratie) Deadline 11: 25/05/2011 Taken Deadline 1: taakverdeling vastleggen (geschat: 0,5h, effectief: 0,5h) te gebruiken programmeertaal vastleggen (geschat: 0,5h, effectief: 0,5h) te gebruiken repository-systeem vastleggen + configureren (geschat: 2h, effectief: 24h) schrijven SCMP (geschat: 2h, effectief: 2h) schrijven SPMP (geschat: 5h, effectief: 5h) opzetten team-website (geschat: 2h, effectief: 2h) Oplevering: SCMP + SPMP + team-website Deadline 2: schrijven SRS (geschat: 5h, effectief: 6h) 8
Oplevering: SRS Deadline 3: schrijven SQAP (geschat: 8h, effectief: 6h) schrijven STD (geschat: 6h, effectief: 8h) schrijven SDD (geschat: 5h, effectief: 5h) herwerken SRS (geschat: 2h, effectief: 3h) herwerken SCMP (geschat: 1h, effectief: 1h) herwerken SPMP (geschat: 2h, effectief: 2,5sh) schrijven van webframework (geschat: 12h, effectief: 12h) schrijven van website waarop gebruiker kan inloggen (requirement nr 2) (geschat: 1h, effectief: 1h) Oplevering: SQAP + STD + SDD + SRS + SCMP + SPMP Deadline 4: maken presentatie voor 1ste SCRUM-meeting (geschat: 3h, effectief: 3h) Deadline 5: herwerken SQAP (geschat: 2h, effectief: onbekend) herwerken STD (geschat: 2h, effectief: onbekend) herwerken SDD (geschat: 2h, effectief: onbekend) herwerken SRS (geschat: 2h, effectief: onbekend) herwerken SPMP (geschat: 4h, effectief: 4h) document review op deadline 5.bis Deadline 6: onderzoeken hoe de applicatie meerdere talen (Engels, Nederlands, Frans) kan ondersteunen (geschat: 8h, effectief: 8h) onderzoeken hoe QR-tags automatisch kunnen gegenereerd worden (geschat: 8h, effectief: onbekend) onderzoeken hoe men een digitale kaart (zoals Google Maps) kan laten communiceren met een applicatie geschreven in python (geschat: 8h, effectief: onbekend) Oplevering: SQAP + STD + SDD + SRS + SPMP + webframework + code: homepage waarbij gebruiker kan inloggen en account kan aanmaken Deadline 7: maken presentatie voor 2de SCRUM-meeting (geschat: 2h, effectief: onbekend) 9
Deadline 8: alles programmeren (geschat: 200h, effectief: onbekend) Oplevering: alle ADT s onafhankelijk (niet gekoppeld aan elkaar) + SPMP Deadline 9: maken presentatie voor 3de SCRUM-meeting (geschat: 2h, effectief: onbekend) Deadline 10: debuggen (geschat: 30h, effectief: onbekend) Oplevering: SQAP + STD + SDD + SRS + SCMP + SPMP + alle code Deadline 11: maken presentatie voor 4de SCRUM-meeting (geschat: 2h, effectief: onbekend) 3.3 Risico Management Plan Mogelijke risico s zijn: 1. Hardware die het begeeft of data is gewist. Oplossing: regelmatig backups nemen van alle artifacts op meer dan 1 lokatie 2. Iemand valt tijdelijk weg door ziekte. Oplossing: voor elke functie wordt er een reserveverantwoordelijke aangeduid die de taken van de afwezige tijdelijk kan opvangen. 3. Iemand verlaat de groep. Oplossing: Er is een reserve-verantwoordelijke die de taken tijdelijk kan overnemen maar er wordt zo vlug mogelijk gezocht naar een nieuwe werkverdeling. 4. Onvoldoende kennis van Phyton. Oplossing: de configuration manager zal de andere personen een verwijzing naar een goed handbook over Phyton geven en hij blijft beschikbaar om vragen betreffende Phyton op te lossen. 5. Deadline wordt niet gehaald. Oplossing: van zodra iemand achter loopt op schema dient hij dit te melden aan de project manager zodat deze de nodige maatregelen kan treffen indien nodig. 6. Afleiding door andere verantwoordelijkheden (vb. opdrachten voor andere vakken). Oplossing: iedereen houdt zich aan goede persoonlijke planning. Indien iemand toch achter loopt op schema, licht hij de manager hierover in en hij doet suggesties over hoe hij die achterstand terug zal inlopen. 7. Miscommunicatie. Oplossing: iedereen is er voor verantwoordelijk om helder en duidelijk te communiceren. Wanneer er bepaalde dingen onduidelijk zijn, dienen deze zo vlug mogelijk opgehelderd te worden. 8. Slechte design-keuzes. Oplossing: de design-manager dient goed na te denken over de implicaties van zijn design. Men dient frequent het design te herevalueren om te controleren of het nog steeds aan de vereisten voldoet. 10
3.4 Afsluitingsplan De leden dienen ervoor te zorgen dat de laatste werkende versie van hun code-bestanden in de repository staan en dat alle bijpassende documenten volledig up-to-date zijn. 4 Technisch Proces Plan 4.1 Procesmodel Er is gekozen voor een spiraal-model met 4 iteraties. Op het einde van elke iteratie moet er een werkende versie van de code zijn en moeten alle documenten volledig upgedate zijn. Een iteratie bestaat uit volgende elementen: 1. Design verfijnen of herevalueren 2. Implementeren 3. Testen 4. Integratie met de rest van de code + updaten van alle documenten Er is gekozen voor dit model omdat dit toelaat om keuzes (vb. design, optionele features, etc.) te herevalueren en gemakkelijk te kunnen inspelen op wijzigende requirements. Een waterval-model geeft onvoldoende ondersteuning voor verschillende iteraties, wat een zeer grote verantwoordelijkheid zou leggen op de vereisten en het design. Dit is een onwenselijke situatie. Agile ontwikkelingsmethoden geven veel flexibiliteit maar vereisen een zeer gestructureerd en regelmatig werkschema met veel onderling contact. Dit maakt deze methode onpraktisch voor dit project omdat de teamleden een zeer verschillend uurrooster hebben. 4.2 Methoden, tools en technieken Programmeertaal: Er werd gekozen voor Phyton. Iedereen is vrij om zijn eigen text-editor te kiezen maar als aanbevolen ontwikkelomgeving is gekozen voor Eclipse. Database: Alle database-transacties gebeuren via MySQL. Versiebeheer: Er werd gekozen voor Git. project-managment tool,bugtracker: Er werd gekozen voor Trac. 11