Software Project Management Plan

Faculty of Applied Science

Software Project Management Plan Beerend Ceulemans

May 19, 2011 Version 0.7

Software Project Management Plan

May 19, 2011

Team Contact Info Beerend Ceulemans Michiel De Keyser Jeroen Heymans Georgi Nikolov Reinert Roux Ruben Tytgat Jeroen Van Den Haute

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Meeting Minutes De verslagen van onze vergaderingen zullen in pdf beschikbaar gesteld worden op onze team-webpagina.

1


May 19, 2011

Contents Team Contact Info

1

Meeting Minutes

1

Table of contents

2

1 Overview

3

2 References

3

3 Denitions

4

4 Project Organisation

4

1.1 1.2

4.1 4.2 4.3

Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . Evolution of the SPMP . . . . . . . . . . . . . . . . . . . . . . .

External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . Internal structure . . . . . . . . . . . . . . . . . . . . . . . . . . . Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . .

5 Managerial process 5.1 5.2

5.3 5.4

Project start-up plan . . . . . . . . . . Work plan . . . . . . . . . . . . . . . . 5.2.1 Estimated (time)cost . . . . . . 5.2.2 Iteratie 1 (Administratie) . . . 5.2.3 Iteratie 2+3 (Implementatie) . 5.2.4 Iteratie 4 (Testen en afwerken) Control plan . . . . . . . . . . . . . . . Risk management plan . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6 Technical process plan 6.1 6.2 6.3

Process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methods, tools and techniques . . . . . . . . . . . . . . . . . . . Product acceptance plan . . . . . . . . . . . . . . . . . . . . . .

7 Supporting process plans 7.1 7.2 7.3 7.4 7.5 7.6 7.7

Conguration Management plan Verication and validation plan . Documentation plan . . . . . . . Quality Assurance plan . . . . . Reviews and audits plan . . . . . Problem resolution plan . . . . . Subcontractor management plans

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 3

4 4 4

6

6 6 6 7 7 7 8 9

10 10 10 10

10

10 10 10 10 11 11 11


May 19, 2011

1 Overview 1.1 Project Summary Het doel van het project is het bouwen van een website die location based games aanbiedt. Gebruikers moeten kunnen registreren en inloggen en vervolgens reeds bestaande games kunnen spelen of zelf hun eigen games aanmaken. Location based games zijn spelletjes waarbij de gameplay op een of andere manier gebaseerd is op de fysieke locatie van de spelers. Er zijn verschillende manieren om dit te implementeren. Wij zullen gebruik maken van QR tags. Dit zijn een soort van barcodes die naar een webpagina verwijzen. De meeste moderne gsm's kunnen deze scannen. We gaan ervan uit dat deze tags zich op een gekende locatie bevinden en wanneer een speler een bepaalde tag scant weten we dus waar hij zich bevindt.

Figure 1: voorbeeld van een QR tag De requirements zullen gedetailleerd beschreven worden in de SRS.

1.2 Evolution of the SPMP Versie Datum 0.1 0.2.1 0.2.2 0.3 0.4 0.5 0.6 0.7

November 3, 2010 November 12, 2010 November 13, 2010 December 10, 2010 December 14, 2010 March 7, 2011 April 7, 2011 Mei 19, 2011

Beschrijving

Eerste ruwe versie Opmerkingen klant bekeken COMOCO toegevoegd Werkplan toegevoegd + kleine aanpassingen Omgezet naar LaTeX Planning Planning+bespreking iteratie 4 Laatste revisie

2 References • IEEE Std 1058-1998 IEEE Standard for Software Project Management Plans • COMOCO I Constructive Cost Model

3


May 19, 2011

3 Denitions • SPMP: Software Project Management Plan • SCMP: Software Conguration Management Plan • SDD: Software Design Document • SQAP: Software Quality Assurance Plan • STD: Software Test Document • SRS: Software Requirements Specication

4 Project Organisation 4.1 External interfaces De klanten van dit project zijn professor Ragnhild Van Der Straeten en haar assistent Pieter Wellens. De communicatie met de klant zal verzorgd worden door de Project Manager. Een van de project-eisen is dat het moet werken op de Wilma server. Voor server gerelateerde problemen zal het team zich wenden tot de systeembeheerder, Dirk van Deun .

4.2 Internal structure • Team manager • Conguration manager • Quality Assurance manager • Requirements manager • Development manager • Planning manager • Secretary • Web master

4.3 Roles and responsibilities Team Manager • verantwoordelijk voor het SPMP, de risicoanalyse en beheer • verzorgt de communicatie met de klant en de algemene werking van het team • bepaalt de agendapunten van de meetings • keurt de beslissingen van teamleden goed • houdt overzicht over het ganse project 4


May 19, 2011

Conguration manager • verantwoordelijk voor het SCMP en algemeen beheer van het Conguration Management • maakt en beheert de Subversion repository • zorgt dat elk teamlid met Subversion kan werken • maakt regelmatige back-ups om dataverlies te voorkomen

Quality Assurance manager • verantwoordelijk voor het SQAP en het STD • verantwoordelijk voor de kwaliteit van documenten en code • verantwoordelijk voor het testen van de software • beslist de conventies in de documenten (LaTeX template) en in de coding

Requirements manager • verantwoordelijk voor het SRS document

Development manager • verantwoordelijk voor het SDD (design) en de code base (implementatie) • verdeelt het programmeerwerk • verzamelt alle code en zorgt dat alles goed samenwerkt

Planning manager • maakt een kalender en controleert of het team op schema zit

Secretary • neemt nota van de team meetings en schrijft hier een beknopt verslag van

Webmaster • verantwoordelijk voor de team website, het forum en het IRC kanaal

Taakverdeling team

De verschillende functies zijn als volgt verdeeld binnen het

• Beerend Ceulemans: Team manager • Michiel De Keyser: Conguration manager • Jeroen Van den haute: Quality Assurance manager • Reinert Roux: Requirements manager • Ruben Tytgat: Development manager • Georgi Nikolov: Planning manager • Jeroen Heymans: Secretary en Webmaster 5


May 19, 2011

5 Managerial process 5.1 Project start-up plan Vooraleer we aan het echte programmeerwerk kunnen beginnen moeten we een programmeertaal kiezen en een design opstellen. Zonder design kunnen we geen duidelijke taakverdeling maken en de volle capaciteit van het team dus niet benutten. De voorstellen voor programmeertalen waren Java, C++ en PHP. PHP is een voor de hand liggende keuze voor een webproject, maar werd afgeschreven omdat een PHP project al snel onoverzichtelijk wordt. Uit de twee overblijvende talen is dan uiteindelijk Java gekozen. De hoofdreden hiervoor is dat enkele teamleden hier al een beetje ervaring mee hadden en dat de anderen het wel interessant vonden om er kennis mee te maken, aangezien het toch wel een populaire taal is in de industrie. De teamleden zullen zichzelf de taal aanleren en vanaf dat er een eerste software design is kan er begonnen worden met het echte programmeerwerk.

5.2 Work plan Tijdens de eerste iteratie blijkt het moeilijk te zijn om veel vergaderingen te plannen. We houden daar rekening mee en we beslissen hierdoor dat het meeste werk in het 2de semester gepland zal worden.

5.2.1 Estimated (time)cost Om een schatting te maken van de benodigde tijd maken we gebruik van het COMOCO model. Ons project wordt geclassiceerd als semi-detached. a b c d Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 Op basis van projecten van vorige jaren schatten we de grootte van het programma op 9à10 KLOC. We zullen uitgaan van het meest extreme geval (10 KLOC). Door toepassing van de COMOCO formules bekomen we de volgende schatting:

• Moeite: 39.5 manmaanden • Ontwikkelingstijd: 9.1 maanden • Aantal teamleden nodig: 4.3 We beseen dat dit maar een ruwe schatting is. We stellen ook vast dat we 2.7 teamleden meer hebben dan nodig wordt geschat. Als we erin slagen van het werk dan eciënt te verdelen zullen we ook minder dan 9.1 maanden nodig hebben. 6


May 19, 2011

5.2.2 Iteratie 1 (Administratie) • Taakverdeling binnen het team vastleggen • Beslissen in welke taal we gaan werken en welke project-management-tools we gaan gebruiken • Initiële versie van de vereiste documenten schrijven • Duidelijke afspraken maken rond svn • Requirements speciëren • Design opstellen • Nodige tools en server installeren

5.2.3 Iteratie 2+3 (Implementatie) • Nadruk op code • Zorgen dat er steeds een werkende website online staat (agile proces). Om dit te garanderen heeft elk teamlid een locale server om zijn code op te testen. Door code in de trunk te wijzigen wordt via een script automatisch de server stopgezet, de nieuwe code gecompiled en de server herstart. Een error in de trunk zou betekenen dat dit proces vastloopt bij het compilen en heeft als resultaat dat de server uit blijft. • Testen • Documenten up to date houden • Deadline 8 maart: guests moeten kunnen registreren en inloggen, de login moet onthouden worden zodat de user een user-menu ziet. Deze basic functionaliteiten moeten geïmplementeerd zijn. Ieder teamlid heeft zo kennis gemaakt met JSP en web-programming. • Deadline 8 april: het concept van de templates moet geïmplementeerd zijn zodat games aangemaakt en gespeeld kunnen worden. Verder moeten de users ook meer uitgewerkt worden. Zo moeten proelen en private messages/invites toegevoegd zijn en moeten de users de beschikbare games kunnen bekijken/zoeken. • Interne Deadline 6 april: de deliverables voor de derde iteratie zouden dan af moeten zijn zodat de resterende tijd tot de iteratie-deadline gebruikt kan worden om nog eventuele problemen op te lossen. De Gantt-chart is terug te vinden achteraan dit document.

5.2.4 Iteratie 4 (Testen en afwerken) • De software zal uitvoerig getest worden. • De belangrijkste requirements zijn in principe al geïmplementeerd. Waar nodig zullen bugs gext worden en kan de code 'mooier' gemaakt worden. 7


May 19, 2011

• Vericatie en validatie van de code. • Interne Deadline 4 mei: afwerken van deeltaken, er moeten Games kunnen gemaakt worden. • Interne Deadline 18 mei: alles van code afgewerkt zodat we alles kunnen overlopen en kleine bugs xen waar nodig. • Deadline 20 mei: nale oplevering De Gantt-chart is terug te vinden achteraan dit document. De taken zijn ruim verspreid over de paasvakantie. Er zijn ook een aantal onderdelen die vertraging hebben opgelopen. Ook deze zouden tijdens de paasvakantie afgewerkt moeten worden zodat we terug op schema zitten wanneer de lessen weer beginnen. Op basis van nieuwe ideeën en problemen die in die 2 weken nog zouden opduiken zal de planning uitgebreid/aangepast worden.

5.3 Control plan Om het verloop en de status van het project te kunnen monitoren zullen we trachten milestones en deadlines op te stellen. Aan de hand daarvan kunnen we ondubbelzinnig vaststellen of we al dan niet op schema zitten. Deze milestones zijn de eindes van iteraties en de interne deadlines.

8


May 19, 2011

5.4 Risk management plan Gedurende elke vergadering zullen we een korte tijd besteden aan risicoanalyse. In een korte brainstorm proberen we potentiële risico's te identiceren en vervolgens te analyseren zodat we gepaste acties kunnen voorstellen om ze te overwinnen of te vermijden. De opgemerkte risico's zullen dan ook verder in het opgevolgd worden gedurende het project.

Risico Verlies van data Onvoldoende ervaring Java/Web services

Afwezigheid op meeting Programmeertaken die niet op tijd afgewerkt raken Onvoldoende ervaring MySQL

Actie

Vermijden: Regelmatige back-up van code en documenten. Dit is de verantwoordelijkheid van de CM. Overwinnen: Elk teamlid is in staat om de taal op zichzelf te leren. Hier staat niet echt een deadline op. De meeste kennis en ervaring zal opgedaan worden terwijl er aan het project gewerkt wordt. Elk teamlid heeft normaal gezien de concepten van OO uitgebreid gezien in C++ en zou de stap naar Java vrij vlot moeten kunnen maken. Eventueel kunnen er korte trainingssessies georganiseerd worden. Overwinnen: Verslagen van de vergaderingen maken en de afwezige tijdig briefen. Eventueel ook een back-up voorzien voor zijn functie. Overwinnen: We zullen in de taakverdeling trachten een maximale onafhankelijkheid te creëren zodat teamleden zo min mogelijk gestoord worden door eventuele complicaties bij de onderdelen van anderen. Overwinnen: Er is een verantwoordelijke aangesteld voor de database. Er zal 1 grote Java class gemaakt worden voor de communicatie met de database. Zo kunnen teamleden die minder goed zijn in MySQL de data aanroepen via methodes die voor hen geschreven werden.

9


May 19, 2011

6 Technical process plan 6.1 Process model We zullen voor het ontwerp van onze software een agile en iteratief process trachten te gebruiken.

6.2 Methods, tools and techniques • Programmeertaal: Java en JSP • Database: MySQL • Project management tool: web2Project • IDE: Eclipse met de Subversive plugin voor SVN • Versiebeheer: Subversion • Website: HTML • Teamcommunicatie: mailinglist en phpBB forum, eventueel later een IRC kanaal mocht dat nodig blijken. Er zijn ook gsm-nummers uitgewisseld, maar die zijn enkel voor `noodgevallen'.

6.3

Product acceptance plan

Het doel is dat de afgeleverde software van hoge kwaliteit is en voldoet aan de eisen die beschreven staan in het SQAP.

7 Supporting process plans 7.1 Conguration Management plan Hiervoor verwijzen we naar het SCMP.

7.2 Verication and validation plan Hiervoor verwijzen we naar het STD.

7.3 Documentation plan Alle documentatie dient in pdf beschikbaar te zijn en zal verzameld worden in 1 documenten-map. De afspraken voor de documenten worden beschreven in het SQAP.

7.4 Quality Assurance plan Hiervoor verwijzen we naar het SQAP.

10


May 19, 2011

7.5 Reviews and audits plan De kwaliteit van het hele project (zowel documenten als code) zal om de 2 weken worden gecontroleerd door de Quality Assurance Manager. De criteria voor deze review, worden beschreven in het SQAP.

7.6 Problem resolution plan Om met problemen in de software om te gaan zullen we gebruik maken van een bug tracking systeem. MantisBT is een populaire en gratis web-based bugtracker. Het is geschreven in PHP en maakt gebruik van een MySQL database. Het is zowel qua installatie als gebruik relatief eenvoudig en daarom een goeie keuze.

7.7 Subcontractor management plans We werken niet met onderaannemers. Al het werk wordt binnen het team verdeeld.

11


May 19, 2011

12

Figure 2: Gantt-chart iteratie 2+3


May 19, 2011

13

Figure 3: Gantt-chart iteratie 4

Software Project Management Plan

Recommend Documents