Software Engineering Groep 3

Transcriptie

1 Software Engineering Groep 3 Software Project Management Plan Diane De Coster (Project Manager) 1 e Master Burgelijk Ingenieur [email protected] [email protected] 8 Maart 2009 Document geschiedenis v2.0 21/05/2009 Diane De Coster Laatste update v1.1 08/03/2009 Diane De Coster Aanvullingen(o.a. 4.2 Software documentatie, 5.5 Evaluatie 1ste semester), aanpassingen(o.a. tijdschema) v1.0 08/11/2008 Diane De Coster Aanvullingen(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 Evaluatie eerste iteratie Evaluatie tweede iteratie Evaluatie project Tijdschema

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 realiseren van het project moeten volgende documenten onderhouden worden: SPMP SCMP SQAP STD SRS SDD GUI IP IP 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 PMR: Post Mortem Review IP: Implementatie Plan M: Manager

4 2 PROJECTORGANISATIE 4 CM: Configuration Manager IM: Implementation Manager QAM: Quality Assurance Manager 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 verlopen 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ïdentificeerd - Design - Implementatie: het coderen zelf - Testen van de aparte delen - Integratie waarbij de verschillende delen worden bijeengezet om het 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.

5 2 PROJECTORGANISATIE 5 - 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. (Zie paragraaf 5.5: Evaluatie eerste iteratie ) 2.2 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. Gedurende de tweede iteratie gaat de vergadering op donderdag door om 17u. 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.

6 2 PROJECTORGANISATIE 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.4 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 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: - Programmeerwerk 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

7 3 MANAGEMENT VAN HET PROJECT 7 - 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 3 Management van het project 3.1 Objectieven en prioriteiten Het managementteam 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, het project moet het 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 risico s in verschillende categoriën: Risico s in verband met het management:

8 3 MANAGEMENT VAN HET PROJECT 8 - Communicatiemoeilijkheden: Een goede communicatie is essentieel voor het slagen van het project. Iedereen uit zijn ideeën, bemerkingen,.. tijdens vergaderingen en op dat moment worden de nodige beslissingen genomen 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. - 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 meer vertrouwd met andere programmeertalen. 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 van Java op te doen tijdens lessen van andere vakken. Ook voor het gebruik van SVN en andere tools die sommigen teamleden niet kennen, worden tutorials geschreven. Teamleden die vertrouwd zijn met LaTeX, informeren de andere teamleden hierover. Andere risico s - Hardware Crash: Dit kan op elk moment van het project gebeuren. Door het gebruik van SVN kunnen we altijd terugvallen op 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 en 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:

9 4 TECHNISCH PROCES 9 - 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. - 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. Een voorbeeld van het verwijderen van een risico is het organiseren van een workshop. Deze workshop werd georganiseerd omdat de meeste teamleden niet vertrouwd waren met XHTML en CSS. 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 Configuration Manager en de Implementation Manager. 4 Technisch proces 4.1 Methodes, tools en technieken Programmeertaal: Java

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 9 Deadlines die niet Reorganisatie gehaald gaan worden van de taken 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 4 TECHNISCH PROCES 11 Ontwikkelingsomgeving: Eclipse met Subclipse als SVN-plugin Versiebeheer systeem: Subversion Database: MySQL en phpmyadmin als front-end op de website Documenten: LaTeX in het Nederlands Documentatie van code: Javadoc 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/2008) SCMP: - eerste versie : week 2 (24/10/2008) SQAP: - eerste versie : week 5 (14/11/2008) SRS: - eerste versie : week 6 (17/11/2008) SDD: - eerste versie, 1ste iteratie : week 6 (17/11/2008) - eerste versie, 2de iteratie : week 20 (24/02/2009) GUI Implementatie Plan: - week 20 (24/02/2008) 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. Vermits we met het spiraalmodel werken, werd een SDD [4] opgesteld voor beide iteraties. Voor de 2de iteratie werd een GUI Implementatie Plan geschreven waarin het GUI design [5] wordt uiteengezet.

12 5 TAKEN, SCHEMA EN BUDGET Projectondersteuning Gedurende het project kunnen we rekenen op raad en feedback van professor Dirk Vermeir en Damien Trog. Met vragen over MySQL kunnen we terecht bij Dirk Van Deun. 5 Taken, schema en budget 5.1 Deeltaken De verschillende deeltaken voor de programmatie worden vastgelegd door de Implementation Manager. Dit gebeurt nadat de architectuur van het ontwerp is vastgelegd. Hierbij wordt rekening gehouden worden met het feit dat het vak Software Engineering voor de studenten computerwetenschappen voor 9 studiepunten doorweegt en voor de studenten ingenieurswetenschappen voor 4 studiepunten. De taakverdeling voor de eerste en de tweede iteratie is opgesteld in het Implementation Plan.[6] 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.3 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.

13 5 TAKEN, SCHEMA EN BUDGET 13 Figuur 1: Gepresteerde uren 1ste iteratie 5.5 Evaluatie eerste iteratie Gepresteerde uren: Zie figuur 1 op pagina 13 voor een overzicht van de gepresteerde uren gedurende de eerste iteratie. Deze werden zo goed als mogelijk in evenwicht gehouden tijdens het verloop van het project. Afhankelijk van de functies en studierichtingen zijn er enkele uitschieters. De webmaster, die een overzichtelijke website tot stand bracht, heeft daar ook de nodige uren aan gespendeerd. De studenten ingenieurswetenschappen bevinden zich daarentegen onderaan in het lijstje, dit omdat het vak Software Engineering niet in het eerste semester gepland was. De overige teamleden hebben een heel goede bijdrage geleverd, in functie van de grootte van de taken, efficiëntie van het werk,.. kwam dit uit op wat meer of minder uren. Tijdens de tweede iteratie zal er naar een evenwicht gestreefd worden. Evaluatie: Voor de evaluatie van het project gedurende de eerste iteratie, wordt verwezen naar het Post Mortem Review [7], opgesteld door de QAM. 5.6 Evaluatie tweede iteratie Gepresteerde uren: Zie figuur 2 op pagina 14 voor een overzicht van de gepresteerde uren gedurende de tweede iteratie. Tijdens deze iteratie werden de uren zo goed mogelijk in evenwicht gebracht. Op deze manier werd een vrij uniforme verdeling gerealiseerd van de gepresteerde uren. Er moest een onderscheid gemaakt worden tussen de uren van de studenten Inge-

14 5 TAKEN, SCHEMA EN BUDGET 14 Figuur 2: Gepresteerde uren 2de iteratie nieurswetenschappen en Computerwetenschappen, vermits het vak voor een verschillend aantal studiepunten meetelt voor deze richtingen. Evaluatie: Voor de evaluatie van het project gedurende de tweede iteratie, wordt verwezen naar het Post Mortem Review 2 [8], opgesteld door de QAM. 5.7 Evaluatie project Gepresteerde uren: Zie figuur 3 op pagina 15 voor een overzicht van de gepresteerde uren gedurende het hele project. Evaluatie: De omvang van de code voor de realisatie van het agenda systeem werd in het begin van het project geschat op 10 KLoC. Voor de laatste conferentie telden we er circa 14 KLoC. Zie figuur 4 op pagina 15 voor een schema met een tijdslijn van de Loc. Figuur 5 op pagina 16 geeft de individuele LoC weer van de teamleden (19 mei). Niet alle functies werden geïmplementeerd, voor verdere uitleg hieromtrent wordt verwezen naar het Post Mortem Review 2 [8]. We kunnen echter wel spreken van een geslaagd project. De basisvereisten van de klant werden geïmplementeerd en heel wat functies voor een degelijke werking van een dergelijk agenda systeem. Er werd eveneens gezorgd voor een gebruiksvriendelijke GUI-implemtatie. Als team ging het vrij vlot om samen te werken. Er werden regelmatig vergaderingen gehouden zodat iedereen op de hoogte bleef van de evolutie van het project. We mogen

15 5 TAKEN, SCHEMA EN BUDGET 15 Figuur 3: Gepresteerde uren 1ste en 2de iteratie Figuur 4: Tijdslijn aantal Lines of Code

16 REFERENTIES 16 Figuur 5: Individueel aantal Lines of Code concluderen dat we het als team wel gehaald hebben om Calexico te realiseren. 5.8 Tijdschema Referenties [1] UTnieuws (bezocht : 26/10/08) i d = [2] Eric J. Braude, Software engineering - An Object-Oriented Perspective, Wiley

17 REFERENTIES 17 [3] SQAP, Software Quality Assurance Plan [4] SDD, Software Design Document [5] GUI IP, GUI Implementatie Plan [6] Implementation Plan [7] Post Mortem Review [8] Post Mortem Review 2