Software Engineering Groep 3

Transcriptie

1 Software Engineering Groep 3 Software Project Management Plan Diane De Coster (Project Manager) 1 e Master Burgelijk Ingenieur diane.de.coster@vub.ac.be se3@tinf.vub.ac.be 22 Oktober 2008 Document geschiedenis v1.0 08/11/2008 Diane De Coster Aanvullen(o.a. risicomanagement), aanpassingen(o.a. tijdschema) v0.2 28/10/2008 Diane De Coster Aanvulling 1ste Draft v0.1 19/10/2008 Diane De Coster 1ste Draft

2 INHOUDSOPGAVE 2 Inhoudsopgave 1 Inleiding Projectoverzicht Deliverables Evolutie van het SPMP Definities en acroniemen Projectorganisatie Procesmodel Organisatiestructuur Organisatorische grenzen en externe interfaces Verantwoordelijkheden binnen het project Management van het project Objectieven en prioriteiten Veronderstellingen, afhankelijkheden en beperkingen Risicomanagement Besturings- en controlemechanismen Taakverdeling Technisch proces Methodes, tools en technieken Software documentatie Projectondersteuning Taken, schema en budget Deeltaken Afhankelijkheden Schatting van nodige middelen Schatting van de kosten Tijdschema Referenties 13

3 1 INLEIDING 3 1 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

4 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 Projectorganisatie 2.1 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én 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.

5 2 PROJECTORGANISATIE Organisatiestructuur De groepsleden worden verdeeld onder verschillende teams. Elk team heeft zijn verantwoordelijke, die gecoördineerd wordt door de Project Manager. De verantwoordelijken van de verschillende teams coördineren 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.

6 2 PROJECTORGANISATIE 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ördineren 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ördineren en beheren - Foutrapporteringen opvolgen - Voorlopige versies specifiëren - 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ördineren volgens het opgesteld STD - Test framework ontwerpen en implementeren

7 3 MANAGEMENT VAN HET PROJECT 7 3 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 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ën 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ën, 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.

8 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ëel 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.

9 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 Waarschijnlijk- Effect Kost Berekening Prioriteit heid op voorval verwijdering prioriteit Risico (11-10).(11-10).3 3 Risico (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

10 4 TECHNISCH PROCES 10 Nr Risico Waarschijnlijk- Effect Kost Prioriteit Verwijderingsheid op voorval verwijdering plan 1 Verkeerde schatting Tijdsreserves inbouwen kosten/nodige tijd 2 Crash Hardware Gebruik svn, backups 3 Communicatie Ieder teamlid beschikt moeilijkheden over gsm, msn, mailadressen 4 Misverstanden Regelmatig vergaderen 5 Kennis LateX Teamlid met kennis onvoldoende LateX geeft uitleg 6 Onvoldoende overzicht Vergaderingen, over stand project communicatie tussen teamleden 7 Kennis Java Javagebruik bij andere niet uitgebreid vakken, tutorials 8 Afwezigheid/ Ieder teamlid ziekte heeft backup teamlid 9 Deadlines die niet Reorganisatie gehaald gaan worden van de taken Tabel 2: Risicotabel. Functie Verantwoordelijke Backup Project Manager Diane De Coster Kristof Van Moffaert Configuration Manager Ben Corne Laurens Teirlinck Quality Assurance Leader Kristof Van Moffaert Clovis Six Implementation Manager Denis Coppens Sander Bartholomees Secretaris Laurens Teirlinck Diane De Coster Webmaster Clovis Six Koen Gremmelprez Requirements Manager Sander Bartholomees Ben Corne Design Manager Koen Gremmelprez Denis Coppens Tabel 3: Taakverdeling.

11 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 Projectondersteuning 5 Taken, schema en budget 5.1 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)

12 5 TAKEN, SCHEMA EN BUDGET 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ëren 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: N = P M 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 euro/jaar [1]. Dus met een team van acht leden, waarbij elk teamlid 4.9 persoonsmaanden zal werken, is er een budget van euro voorzien voor het uitbetalen van de teamleden. 5.5 Tijdschema

13 6 REFERENTIES 13 6 Referenties Referenties [1] UTnieuws (bezocht : 26/10/08) i d = [2] Eric J. Braude, Software engineering - An Object-Oriented Perspective, Wiley [3] SQAP, Software Quality Assurance Plan se3 0809/