Software Project Management Plan

Transcriptie

1 Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant /11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen milestones 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 Activiteiten Planning 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. Het project heeft een driedelig doel: 1. Ontwikkelen en onderhouden van een groepwebsite. 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 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 onderandere gekeken wordt naar functieverdelingen, kostenplanning, het beheer van risico s, de te gebruiken ontwikkelingsmethoden, etc. We zullen 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. We zullen 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. We zullen 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. We zullen hiervoor gebruik maken van de IEEE 829 standaard. SRS: Software Requirements Specification Dit document beschrijft aan welke vereisten de te schrijven software moet voldoen. We zullen 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. We zullen 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

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

6 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 Kosten schatting We gebruiken COCOMO als methode om de kosten in te schatten. Ons project kan als semidetached geclassificeerd worden. Dit komt omdat de programmeerervaring zeer sterk verschilt van persoon tot persoon in ons team. Bovendien is de gebruikte taal voor dit project ongekend bij de meerderheid van de mensen. We 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

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

8 Code Zie het ticketsysteem van de software project managment tool om te kijken wie welke code gaat schrijven Planning 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. In onderling overleg met alle teamleden zullen milestones afgesproken worden. Eens dat deze afgesproken zijn, zullen deze ook verschijnen in de project managment tool. 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. 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. 8

9 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. 9