Software Project Management Plan

Software Project Management Plan

GameTrac

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

Opmerking Eerste versie voor klant 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


14 december 2010

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

4 4 4 5

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

5 5 5 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.2.1 Activiteiten . . . . 3.2.2 Planning . . . . . 3.3 Risico Management Plan . 3.4 Afsluitingsplan . . . . . .

. . . . . . . . .

6 6 6 7 7 7 7 8 8 8

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

9 9 9

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .


1

Inleiding

1.1

Projectoverzicht

14 december 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. 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 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


1.3

14 december 2010

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


14 december 2010

• 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

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

d TDEV = c · TM

6

N=

TM TDEV


14 december 2010

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 5 voor kLOC. TM = a · kLoCb = 3 ∗ 51,12 = 18, 2 manmaanden d TDEV = c · TM = 2, 5 ∗ 18, 20,35 = 6, 9 maanden N = TM /TDEV = 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 · TDEV · 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), 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 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


14 december 2010

Code Zie het ticketsysteem van de software project managment tool om te kijken wie welke code gaat schrijven. 3.2.2

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


14 december 2010

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

Software Project Management Plan

Recommend Documents