Software Project Management Plan

Transcriptie

1 Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1

2 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

3 Inhoudsopgave 1 Inleiding Projectoverzicht Definities Referenties Projectorganisatie Externe communicatie Interne structuur Functies en verantwoordelijkheden Management Processen Project Opstart Plan Kosten schatting Personeelsplan Trainingsplan Werkplan Risico Management Plan Afsluitingsplan Technisch Proces Plan Procesmodel Methoden, tools en technieken

4 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. Ontwikkelen en onderhouden van een groepwebsite. Eens deze website online is, zullen de deliverables daar te vinden zijn. 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 De studenten vertrouwd maken met software-ontwikkeling in teamverband. 1.2 Definities SPMP: Software Project Management Plan SCMP: Software Configuration Management Plan SQAP: Software Quality Assurance plan STD: Software Test Plan SRS: Software Requirements Specification SDD: Software Design Document DM: Document Manager 1.3 Referenties Wikipedia, Scrum 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 4

5 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: 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 5

6 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 Kosten schatting We gebruiken COCOMO als methode om de kosten in te schatten. Ons project kan als semidetached geclassificeerd worden omdat we een team zijn waarbij iedereen programmeerervaring heeft maar waar niet iedereen vertrouwd zijn met de gekozen programmeertaal. We hebben bovendien te maken met zowel vaste als flexibele vereisten. De COCOMO-formules zijn: T M = a kloc b T DEV = c T d M N = T M T DEV 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, komen we op een schatting van 9 voor kloc. T M = a kloc b = 3 91, 12 = 35 manmaanden T DEV = c T d M = 2, 5 350, 35 = 8, 69 maanden N = T M /T DEV = 35/8, 69 = 4, 04 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 = euro Personeelsplan Beslissingen over teamleden dienen altijd gesteund te worden door een meerderheid van het team. Roeland: design manager (database,applicatie), assistent configuration manager Brecht: project manager, assistent requirement manager 6

7 Goedele: document manager, secretaris, assistent design manager Tom: configuration manager, webmaster communicatie-website Gil: requirement manager Bram: quality manager 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 SPMP: geschreven door manager 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 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 doe 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. 7

8 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 onze vereisten voldoet. 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 dienen we een werkende versie van de code te hebben en dienen alle documenten volledig upgedate te 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 ons 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 ons daar we 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. 8