Software Engineering – Groep 3 Software Project Management Plan Diane De Coster (Project Manager) 1e Master Burgelijk Ingenieur
[email protected] –
[email protected] 22 Oktober 2008
v1.0
08/11/2008
v0.2 v0.1
28/10/2008 19/10/2008
Document geschiedenis Diane De Coster Aanvullen(o.a. risicomanagement), aanpassingen(o.a. tijdschema) Diane De Coster Aanvulling 1ste Draft Diane De Coster 1ste Draft
INHOUDSOPGAVE
2
Inhoudsopgave 1 Inleiding 1.1 Projectoverzicht . . . . . 1.2 Deliverables . . . . . . . 1.3 Evolutie van het SPMP 1.4 Definities en acroniemen
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 Projectorganisatie 2.1 Procesmodel . . . . . . . . . . . . . . . . . . . 2.2 Organisatiestructuur . . . . . . . . . . . . . . 2.3 Organisatorische grenzen en externe interfaces 2.4 Verantwoordelijkheden binnen het project . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
3 3 3 3 3
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 4 5 5 6
3 Management van het project 3.1 Objectieven en prioriteiten . . . . . . . . . . . . . . 3.2 Veronderstellingen, afhankelijkheden en beperkingen 3.3 Risicomanagement . . . . . . . . . . . . . . . . . . . 3.4 Besturings- en controlemechanismen . . . . . . . . . 3.5 Taakverdeling . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
7 7 7 7 9 9
. . . .
. . . .
. . . .
4 Technisch proces 9 4.1 Methodes, tools en technieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Software documentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Projectondersteuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5 Taken, schema en budget 5.1 Deeltaken . . . . . . . . . . . . 5.2 Afhankelijkheden . . . . . . . . 5.3 Schatting van nodige middelen 5.4 Schatting van de kosten . . . . 5.5 Tijdschema . . . . . . . . . . . 6 Referenties
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
11 11 11 12 12 12 13
1
INLEIDING
1
3
Inleiding
1.1
Projectoverzicht
Het systeem dat tijdens dit project ontwikkeld wordt, ondersteunt de functionaliteit van een ’agenda systeem’. Dit laat gebruikers toe om een agenda via het web te beheren. Voor de gedetailleerde functionaliteiten wordt verwezen naar het SRS.
1.2
Deliverables
Gedurende het het realiseren van het project moeten volgende documenten onderhouden worden: • SPMP • SCMP • SQAP • STD • SRS • SDD • Broncode • Verslagen van de vergaderingen • timesheets
1.3
Evolutie van het SPMP
Het Software Project Management Plan zal continu onderhouden worden. De recentste versie zal steeds ter beschikking staan in de svn repository. Dit document voldoet aan de standaarden die opgesteld zijn door de Configuration Manager. Veranderingen in dit plan gebeuren volgens de regels die ook door de Configuration Manager worden vastgelegd.
1.4
Definities en acroniemen
SPMP: Software Project Management Plan SCMP: Software Configuration Management Plan SQAP: Software Quality Assurance Plan STD: Software Test Document SRS: Software Requirements Specification SDD: Software Design Document M: Manager CM: Configuration Manager IM: Implementation Manager QAM: Quality Assurance Manager
2
PROJECTORGANISATIE
4
QAMT: Quality Assurance Management Team DBM: Database Manager DL: Design Leader RM: Requirement Manager W: Webmaster COCOMO: Constructive Cost Model KLOC: Kilo Lines Of Code PM: persoonsmaanden SVN : Subversion
2 2.1
Projectorganisatie Procesmodel
De ontwikkeling van het project zal lopen volgens het spiraalmodel. Het spiraalmodel is een iteratief proces waarbij de ’Requirementsanalyse, Design, Implementatie, Testen’-sequentie van het watervalproces verschillende keren herhaald wordt. E´en iteratie bestaat uit de volgende stappen: - Conceptanalyse waarbij de toepassing wordt gedefinieerd - Analyse waarbij de hoofdklassen worden ge¨ındentificeerd - Design - Implementatie: het coderen zelf - Testen van de aparte delen - Integratie waarbij de verschillende delen worden bijeengezet om product af te maken - Testen van het gehele systeem: testrapport en defectbeschrijvingen Deze stappen worden niet bij elke iteratie herhaald. We werken met twee iteraties, die eventueel gevolgd worden door een periode van continue instandhouding. Elke versie wordt dan gebouwd op het resultaat van de vorige iteratie. De keuze voor het procesmodel werd gemaakt op basis van een aantal voordelen bij het gebruik van dit model: - Risico’s worden sneller ge¨ıdentificeerd en beperkt. - Na de eerste iteratie kan de eerste versie van het project voorgelegd worden, zodat de gebruiker feedback kan geven over het voorlopige resultaat. - De implementatie van een grote brok code wordt vermeden. - Uit de eerste iteratie kunnen betere schattingen bekomen worden over het project. Bij het afwerken van een iteratie moet de documentatie consistent zijn met de functionaliteiten van het project. Het gedocumenteerd design moet ge¨ımplementeerd zijn en moet voldoen aan alle vooropgestelde eisen. De eerste iteratie zal begin februari, tijdens week 17 gecontrolleerd worden door het QAMT.
2
PROJECTORGANISATIE
2.2
5
Organisatiestructuur
De groepsleden worden verdeeld onder verschillende teams. Elk team heeft zijn verantwoordelijke, die geco¨ ordineerd wordt door de Project Manager. De verantwoordelijken van de verschillende teams co¨ ordineren op hun beurt de teamleden en rapporteren hierover aan de andere verantwoordelijken en aan de Project Manager. Het projectteam bestaat uit verschillende functies: - Project Manager - Configuration Manager - Design Manager - Quality Assurance Manager - Implementation Manager - Database Manager - Requirement Manager - Webmaster Wat deze functies inhouden wordt in sectie 2.4 behandeld. Elke vrijdag om 17.00u is er een vergadering gepland waarbij de vooruitgang van het project bijgehouden wordt. De verantwoordelijken rapporteren de stand van zaken aan elkaar en aan de Project Manager zodat deze een globaal overzicht behouden. Indien het niet nodig is om te vergaderen, wordt deze afgelast. Wanneer een teamlid niet aanwezig kan zijn voor een belangrijke vergadering, wordt deze verplaatst naar een andere dag of een ander tijdstip. Elk teamlid is verantwoordelijk voor zijn eigen timesheets. Op zondagavond moeten alle timesheets door elk teamlid ingegeven worden op de site. Vergaderingen worden door de Project Manager in alle timesheets gezet. De timesheets worden nagelezen en goedgekeurd door de Project Manager en vervolgens naar Professor Dirk Vermeir en Damien Trog gestuurd. De verschillende deadlines worden opgelegd door het managementteam. Op woensdag worden de te controleren zaken doorgestuurd zodat deze becommentarieerd kunnen worden. De deadlines laten we samenvallen met de vergaderingen zodat de documenten tegen dan aangevuld of gecorrigeerd zijn. Indien er een onenigheid is, wordt deze tijdens de vergadering besproken.
2.3
Organisatorische grenzen en externe interfaces
Het project moet aan de wensen van de klanten voldoen, namelijk Professor Dirk Vermeir en Damien Trog. De externe communicatie met de klant verloopt via de Project Manager, de Design Manager en de Requirements Manager. De Requirements Manager bespreekt met de klant wat de gewenste functionaliteiten van het project zijn. De Design Manager stelt het ontwerp van het systeem voor aan de klant. De Project Manager brengt algemeen verslag uit over de vorderingen van het project.
2
PROJECTORGANISATIE
2.4
6
Verantwoordelijkheden binnen het project
• Project Manager: - SPMP opstellen en onderhouden - Tijdschema Ontwikkelen - Vergaderingen voorbereiden en voorzitten - Identificatie, toekenning en opvolging van taken - Wekelijkse timesheets beheren, verslagen van vergaderingen nalezen en goedkeuren - Risicomanagement - Vooruitgang project bijhouden - Samenwerking en communicatie tussen teamleden/verantwoordelijken controleren • Configuration Manager: - SCMP opstellen en onderhouden - Versie controle systeem opzetten - Beheren van verschillende versies door middel van CVS (SVN) - Installatie en onderhoud van andere ondersteunende tools - Specificatie en organisatie van naamgeving en documenten ontwikkelen en opvolgen • Design Manager: - SDD opstellen en onderhouden, dit op basis van het SRS - Ontwerpactiviteiten co¨ ordineren en beheren - Implementatiefase controleren op naleving van het SDD - Design en beheer van de database • Implementation Manager: - Programmeringswerk verdelen onder de teamleden - Integratie van verschillende delen van het project co¨ordineren en beheren - Foutrapporteringen opvolgen - Voorlopige versies specifi¨eren - Het implementatieproces opstellen op basis van het SDD • Quality Assurance Manager: - SQAP en STD opstellen en onderhouden - Controleren of het project aan de vereiste specificaties voldoen en het ontwerp respecteren - De code en bijhorende documenten moeten aan het opgelegde kwaliteitsniveau en standaarden voldoen - Het testen co¨ ordineren volgens het opgesteld STD - Test framework ontwerpen en implementeren
3
MANAGEMENT VAN HET PROJECT
3
7
Management van het project
3.1
Objectieven en prioriteiten
Het management team moet ervoor zorgen dat het project tot een goed einde komt door volgende objectieven na te streven in dalende prioriteit: - Het project moet aan alle eisen voldoen die door de klant gesteld werden - Alle deadlines moeten gerespecteerd worden, project moet tijdschema volgen - Herbruikbare klassen ontwikkelen - Een stabiel product leveren zodat het product behouden kan worden
3.2
Veronderstellingen, afhankelijkheden en beperkingen
• Veronderstellingen: - Gebruikte libraries zijn correct. - Elk teamlid kan basisprogrammeren met Java. - De tutorials over onbekende tools zullen gelezen worden. • Afhankelijkheden: - Het slagen van het project is afhankelijk van de kennis en de inzet van elk teamlid. - Ook een goede communicatie draagt hiertoe bij. • Beperkingen: - Enkel open source software mag gebruikt worden. - Product moet werken onder Linux. - Geen gebruik van bestaande frameworks. - Het product dient ontwikkeld te worden op de Wilma-server. - Het project moet afgerond en gepresenteerd worden tegen 22 mei 2009.
3.3
Risicomanagement
Met de ontwikkeling van een softwaretoepassing zijn heel wat risico’s verbonden. Enerzijds zijn deze risico’s te vermijden door de projecteisen te veranderen zodat het risico verdwijnt. Anderzijds zijn er technieken of hulpmiddelen waarmee het probleem kan worden aangepakt zodat het risico wordt weggewerkt. Er bestaan verschillende categori¨en risico’s: • Risico’s in verband met het management: - Communicatiemoeilijkheden: Een goede communicatie is essentieel voor het slagen van het project. Iedereen uit zijn idee¨en, bemerkingen,.. op tijdens vergaderingen en op dat moment worden de nodige conclusies gemaakt in overleg met de Project Manager. Dit zorgt voor een goede opeenvolging en vooruitgang van het project. Als er een dringende beslissing genomen moet worden tussen de vergaderingen door zijn er voldoende communicatiemiddelen(gsm,msn,skype,..) om dit op een vlotte manier te doen verlopen.
3
MANAGEMENT VAN HET PROJECT
8
- Onvoldoende overzicht over de stand van zaken van het project: Het project is een groepswerk, dus kan het overzicht over het globale project verwateren. Dit moet echter altijd goed bijgehouden worden. Dit gebeurt tijdens de vergaderingen waarin elk teamlid rapporteert wat hij heeft gerealiseerd en waar hij op dat moment mee bezig is. Op deze manier worden ook misverstanden of misvattingen over de requirements of het design onmiddellijk ontdekt en opgelost. Ook problemen met de implementatie kunnen zo gemakkelijker opgelost worden, vermits alle teamleden op de hoogte zijn van waar de anderen teamleden staan. - Misverstanden: Als misverstanden niet snel genoeg opgelost worden, kan dit negatieve gevolgen hebben en tijdverlies met zich meebrengen. Door regelmatig te vergaderen wordt dit vermeden. - Deadlines die niet gehaald worden: Wanneer een teamlid merkt dat hij een deadline niet zal halen, moet dit zo vlug mogelijk gerapporteerd worden aan de Project Manager. Deze kan dan tijdens de vergaderingen - in overleg met de teamleden de taken reorganiseren. Een goede communicatie onder de teamleden is hiervoor vereist. • Risico’s in verband met gebrek aan kennis: - Kennis van Java, LateX: De meeste teamleden zijn andere programmeertalen meer gewend. Om het project goed te doen vorderen moet elk teamlid Java echter vlot onder de knie krijgen. Dit is mogelijk door de nodige tutorials te lezen en de kennis en vlot gebruiken van Java te vergroten in andere vakken. Ook voor het gebruik van SVN en andere tools die sommigen teamleden niet kennen, worden tutorials geschreven over het gebruik van SVN. Teamleden die vertrouwd zijn met LateX, informeren de andere teamleden hierover. • Andere risico’s - Hardware Crash: Dit kan op elk moment tijdens het project gebeuren. Door het gebruik van SVN kunnen we altijd aan vorige versies van het project. En elk teamlid heeft een kopie van het project op zijn pc. - Afwezigheid, ziekte: Iedereen is voorzien van een backup, elke manager houdt zijn backup op de hoogte van zijn functie en waar hij mee bezig is. Op deze manier kan de backup in een dringend geval de taken van de manager overnemen en ligt er geen deel van het project stil door zijn afwezigheid. In de risicotabel worden de verschillende risico’s opgesomd. Een risicotabel is voorzien van verschillende kolommen waarbij de waarschijnlijkheid van voorkomen, het effect op het project, de kost voor de verwijdering en de prioriteit van het risico samengevat worden. De oplossingen om deze risico’s te doen verdwijnen, zijn eveneens aanwezig in de risicotabel. De maten van waarschijnlijkheid, effect en verwijderingskost van de risico’s zijn op eenzelfde schaal gezet, namelijk van 1 tot 10: - Een risico met een waarschijnlijkheid van 1 zal het minst waarschijnlijk voorkomen, maar bij een waarschijnlijkheid van bijvoorbeeld 8 is de kans groot dat dit risico een re¨eel probleem zal vormen bij de ontwikkeling van het product. - Een effect op het project van 1 heeft bijna geen impact, terwijl een effect van 10 op de schaal een enorme impact heeft.
4
TECHNISCH PROCES
9
- Als het niet veel tijd vraagt om het risico terug te trekken, dus als de kost klein wordt ingeschat, wordt de kost voor de verwijdering van het risico op 1 gezet. De waarde van de waarschijnlijkheid en het effect worden van 11 afgetrokken. Vervolgens worden deze nieuwe waarden met elkaar vermenigvuldigd en met de waarde van de kost voor de verwijdering. Op deze manier wordt de prioriteit van het risico bekomen. Verduidelijking aan de hand van volgende voorbeeld: Risico
Waarschijnlijkheid op voorval
Effect
Kost verwijdering
Berekening prioriteit
Prioriteit
Risico 1
10
10
3
(11-10).(11-10).3
3
Risico 2
1
1
7
(11-1).(11-1).7
70
Tabel 1: Voorbeeld . Het laagste getal in de kolom van de prioriteit wordt het eerst behandeld. Dus risico 1 heeft prioriteit in dit voorbeeld. De risico’s zijn opgesomd in tabel 2 op pagina 10 van hoogste naar laagste prioriteit.
3.4
Besturings- en controlemechanismen
Het project moet bestuurd en gecontroleerd worden. Dit gebeurt tijdens de wekelijkse vergadering op vrijdag. De agendapunten van de volgende vergadering en de actiepunten voor de week worden op dat moment opgesteld. Deze worden achteraf naar iedereen doorgestuurd zodat elk teamlid weet wat er tegen de volgende vergadering verwacht wordt. Tijdens de vergaderingen worden de agendapunten overlopen en besproken. De vooruitgang van het project wordt dan ook gecontroleerd. Zo snel mogelijk na elke vergadering wordt een voorlopig verslag geschreven en doorgestuurd naar de teamleden zodat iedereen altijd kan terugkijken naar de actiepunten indien nodig. Ten laatste vier dagen na de vergadering wordt het uiteindelijk verslag doorgestuurd naar de teamleden en klanten en ook op de website gezet. De datum en het uur van elke volgende vergadering is eveneens beschikbaar op de website.
3.5
Taakverdeling
Zie tabel 3 op pagina 10. Het management van de database wordt toegewezen aan de Implementation Manager en zijn backup.
4
Technisch proces
4.1
Methodes, tools en technieken
• Programmeertaal: Java • Ontwikkelingsomgeving: Eclipse met Subclipse als svn-plugin • Versiebeheer systeem: Subversion • Database: MySQL en phpMyAdmin als front-end op de website • Documenten: Nederlands in latex • Documentatie van code: Javadoc
4
TECHNISCH PROCES
10
Nr
Risico
Waarschijnlijkheid op voorval
Effect
Kost verwijdering
Prioriteit
Verwijderingsplan
1
Verkeerde schatting kosten/nodige tijd
7
9
1
8
Tijdsreserves inbouwen
2
Crash Hardware
0.5
10
1
10.5
Gebruik svn, backups
3
Communicatiemoeilijkheden
6
7
1
20
Ieder teamlid beschikt over gsm, msn, mailadressen
4
Misverstanden
6
9
4
40
Regelmatig vergaderen
5
Kennis LateX onvoldoende
3
7
2
64
Teamlid met kennis LateX geeft uitleg
6
Onvoldoende overzicht over stand project
5
7
3
72
Vergaderingen, communicatie tussen teamleden
7
Kennis Java niet uitgebreid
7
8
6
72
Javagebruik bij andere vakken, tutorials
8
Afwezigheid/ ziekte teamlid
4
5
2
84
Ieder teamlid heeft backup
9
Deadlines die niet gehaald gaan worden
6
8
5
120
Reorganisatie van de taken
Tabel 2: Risicotabel .
Functie Project Manager Configuration Manager Quality Assurance Leader Implementation Manager Secretaris Webmaster Requirements Manager Design Manager
Verantwoordelijke Diane De Coster Ben Corne Kristof Van Moffaert Denis Coppens Laurens Teirlinck Clovis Six Sander Bartholomees Koen Gremmelprez
Tabel 3: Taakverdeling .
Backup Kristof Van Moffaert Laurens Teirlinck Clovis Six Sander Bartholomees Diane De Coster Koen Gremmelprez Ben Corne Denis Coppens
5
TAKEN, SCHEMA EN BUDGET
11
• Website, timesheets : PHP, HTML • Online versiebeheer systeem front-end: Trac
4.2
Software documentatie
De documenten die tijdens de ontwikkeling van het product moeten onderhouden worden, worden in sectie 1.2 opgesomd. Enkele deadlines: • SPMP: - eerste versie : week 2 (24/10) • SCMP: - eerste versie : week 2 (24/10) • SQAP: - eerste versie : week 5 (14/11) • SDD: - eerste versie : week 4 (7/11) Tegen deze deadlines staan deze documenten op de website. De achtereenvolgende versies worden continu onderhouden en doorgestuurd naar de klant. Elke manager is verantwoordelijk voor het schrijven en updaten van de aan hen toegewezen documenten. (sectie 2.4) Deze moet de documenten dan ook plaatsen op de SVN-repository. De CM is verantwoordelijk voor de conventies over naamgeving en het beheer van verschillende versies van de documenten. Bij problemen hieromtrent, kan men terecht bij de Configuration Manager. Samen met de laatste versies van de documenten wordt de website door de webmaster upgedated. Voordat de documenten op de SVN-repository worden gezet en de website wordt upgedate, worden deze nagekeken door Quality Assurance Manager. Hoe dit te werk gaat, wordt uiteengezet in het SQAP [3]. Op deze manier voldoen de documenten aan de gewenste kwaliteit.
4.3
5 5.1
Projectondersteuning
Taken, schema en budget Deeltaken
De verschillende deeltaken voor de programmatie wordt vastgelegd door de Implementatie Manager. Dit gebeurt nadat de architectuur van het ontwerp is vastgelegd. Hierbij zal rekening gehouden worden met het feit dat het vak Software Engineering voor de studenten computerwetenschappen voor 9 studiepunten doorweegt en voor de ingenieurs voor 4 studiepunten.
5.2
Afhankelijkheden
De verschillende documenten worden opgesteld volgens het SCMP. De code wordt ge¨ımplementeerd volgens het SDD en onder toezicht van de Implementatie Manager. Dus zijn er opeenvolgende afhankelijkheden : SCMP - SPMP,SQAP - SRS - SDD - Programmeren - STD. (- = afhankelijk van)
5
TAKEN, SCHEMA EN BUDGET
5.3
12
Schatting van nodige middelen
Voor software of andere hulpmiddelen is er geen budget voorzien. Er wordt gebruik gemaakt van open source software hulpmiddelen zoals bibliotheken en ontwikkelingsomgevingen. Bij het verwerven van software wordt er een rapport opgesteld. Voor het extern advies steunen we op Professor Dirk Vermeir.
5.4
Schatting van de kosten
Voor de schatting van de kosten en de duur van het project, wordt gebruik gemaakt van het COCOMO-model (Boehm). Met dit model kunnen we uit het een aantal lijnen code (LoC) bepalen hoeveel arbeid er nodig zal om het project te realiseren en hoe lang het project zal lopen. Uit ervaring en door vergelijking met andere projecten van dezelfde omvang, schatten we het aantal lijnen code op 10KLoC. De parameters van het COCOMO-model vari¨eren naargelang de toepassing van het project: organic, semidetached en embedded. Ons project valt onder de semidetached toepassing. Het werk wordt in aantal persoonsmaanden bepaald volgens onderstaande formule: P M = 3 · KLoC 1,12 Dit geeft ons 39.5 persoonsmaanden. De duur van het project wordt bekomen door volgende formule: Duur = 2, 5 · P M 0,35 De geschatte duur wordt 9 maanden. Dus zouden we 4.4 ingenieurs/programmeurs nodig hebben volgens: PM N= Duur We beschikken echter over acht teamleden dus elk teamlid zal 4.9 persoonmaanden werken, verspreid over de zeven maanden. 7 maanden is immers de echte duur van het project. Ingenieurs en informatici hebben een gemiddeld salaris van ongeveer 55.000 euro/jaar [1] . Dus met een team van acht leden, waarbij elk teamlid 4.9 persoonsmaanden zal werken, is er een budget van 178.000 euro voorzien voor het uitbetalen van de teamleden.
5.5
Tijdschema
6
6
REFERENTIES
Referenties
Referenties [1] UTnieuws (bezocht : 26/10/08) http://www.utnieuws.utwente.nl/new/?artikeli d = 28498 [2] Eric J. Braude, Software engineering - An Object-Oriented Perspective, Wiley [3] SQAP, Software Quality Assurance Plan http://wilma.rave.org/ se3 0809/
13
