Software Project Management Plan

Software Project Management Plan

GameTrac

Versie Datum Auteur(s) 0.1 3/11/2010 Brecht Van Laethem

1

Opmerking

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


10 november 2010

Inhoudsopgave 1 Inleiding 1.1 Projectoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Definities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 4 4

2 Projectorganisatie 2.1 Externe communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Interne structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Functies en verantwoordelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 4 5

3 Management Processen 3.1 Project Opstart Plan . . . 3.1.1 Kosten schatting . 3.1.2 Personeelsplan . . 3.1.3 Trainingsplan . . . 3.2 Werkplan . . . . . . . . . 3.3 Risico Management Plan . 3.4 Afsluitingsplan . . . . . .

. . . . . . .

6 6 6 6 7 7 7 8

4 Technisch Proces Plan 4.1 Procesmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Methoden, tools en technieken . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .


1

Inleiding

1.1

Projectoverzicht

10 november 2010

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. http://wilma.rave.org/~se1_1011/ 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 1058.1-1987. • 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 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 4


10 november 2010

• 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


10 november 2010

– 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

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: TM = a · kLoCb

d TDEV = c · TM

N=

TM TDEV

De variable TM is de moeite nodig en is uitgedrukt in manmaanden. TDEV 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. TM = a · kLoCb = 3 ∗ 91, 12 = 35 manmaanden d TDEV = c · TM = 2, 5 ∗ 350, 35 = 8, 69 maanden N = TM /TDEV = 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 · TDEV · 3500 = 125000euro. 3.1.2

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


10 november 2010

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

• 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


10 november 2010

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

Software Project Management Plan

Recommend Documents