Software Engineering Groep 3
|
|
- Bert Michiels
- 8 jaren geleden
- Aantal bezoeken:
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/
Software Engineering Groep 3
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 8 Maart 2009 Document geschiedenis
Nadere informatieSoftware Project Management Plan
Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het
Nadere informatieSoftware Engineering - Groep 1
Software Engineering - Groep 1 Verslag vergadering week 0 Diane De Coster (Project Manager)- Laurens Teirlinck (Secretaris) 1 ste Master Ingenieurswetenschappen diane.de.coster@vub.ac.be se3@tinf.vub.ac.be
Nadere informatieSoftware Engineering Group 3
Software Engineering Group 3 Verslag vergadering week 2 Laurens Teirlinck (Secretaris) 1 e Master Ingenieurswetenschappen lteirlin@vub.ac.be se3@tinf.vub.ac.be 24 Oktober 2008 Document geschiedenis v1.0
Nadere informatieSoftware Project Management Plan
Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen
Nadere informatieSoftware Engineering Groep 3
Software Engineering Groep 3 Post Mortem Review 1 Kristof Van Moffaert (QA Manager) 3 e Bachelor Computerwetenschappen Kristof.Van.Moffaert@vub.ac.be se3@tinf.vub.ac.be 22 februari 2009 Document geschiedenis
Nadere informatieSoftware Project Management Plan
Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen
Nadere informatieSoftware Quality Assurance Plan
Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren
Nadere informatieSoftware Project Management Plan
Software Project Management Plan PEN: Paper Exchange Network Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Contents 1 Overzicht 1 1.1 Samenvatting project.........................
Nadere informatieSoftware Configuration Management Plan
Software Configuration Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 31/10/2010 Tom Strickx Template 0.2 31/10/2010 Tom Strickx First draft 1 Door hieronder te tekenen verklaart u akkoord
Nadere informatieSoftware Project Management Plan
FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando
Nadere informatieSoftware Engineering Groep 4
Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be
Nadere informatieSoftware Configuration Management Plan
Software Configuration Management Plan Michiel De Keyser Configuration Manager van Software Engineering groep 3 December 14, 2010 Versie Datum Beschrijving 0.1 3 November 2010 Eerste ruwe versie 0.2 3
Nadere informatieSoftware Engineering Groep 4
Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be
Nadere informatieSoftware Engineering Groep 4
Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be
Nadere informatieSoftware Project Management Plan
Faculteit Wetenschappen en Bio-ingenieurswetenschappen Vakgroep Computerwetenschappen Software Project Management Plan Arno De Witte, Romeo Van Snick, Vincent De Schutter, Silke Verhaeghe, Yannick Merckx
Nadere informatieSoftware Test Documentation
FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe
Nadere informatieSoftware Project Management Plan for WiseLib
Software Project Management Plan for WiseLib Wout Van Riel Mathieu Reymond Sam Vervaeck Yannick Verschueren Arno Moonens October 2014 1 Contents 1 Introductie 5 1.1 Project Overzicht...........................
Nadere informatieicafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous
icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous 2006-2007 Inhoudsopgave 1 2 1.1 Programmeertaal PHP5..................... 2 1.2 MySQL database......................... 3 1.3 Adobe Flash...........................
Nadere informatieSoftware Project Management Plan
FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando
Nadere informatieSoftware Project Management Plan
FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando
Nadere informatieSoftware Project Management Plan
Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage
Nadere informatieSoftware Project Management Plan
Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage
Nadere informatiePlan van Aanpak. project Tetris Packing
Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!
Nadere informatieChecklist basisontwerp SDM II
Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance
Nadere informatieSoftware Project Management Plan Versie 1.2.0
Versie 1.2.0 24-4-2006 biceps Samenvatting Dit is het (SPMP) voor het biceps project. Het project wordt uitgevoerd voor het vak 2IP40 aan de Technische Universiteit Eindhoven. De structuur van dit document
Nadere informatieSoftware Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015
Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie
Nadere informatieSoftware Project Management Plan
Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage
Nadere informatieSoftware Test Document
Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie
Nadere informatieProjectopgave: Sociaal Kennis Databank
Projectopgave: Sociaal Kennis Databank Geavanceerde Webtechnologie Academiejaar 2010-2011 1 Probleemstelling De laatste jaren zijn sociaalnetwerksites enorm populair geworden. Het meest bekende voorbeeld
Nadere informatieicafe Een digitaal bestelsysteem voor de horeca Joeri Verdeyen Stefaan De Spiegeleer Naim Ben Tanfous
icafe Een digitaal bestelsysteem voor de horeca Joeri Verdeyen Stefaan De Spiegeleer Naim Ben Tanfous 2006-2007 Voorwoord 1 Inhoudsopgave 2 Hoofdstuk 1 Inleiding 3 Hoofdstuk 2 icafe 2.1 Het idee 2.2 Mogelijkheden
Nadere informatieSoftware Project Management Plan WiseLib
Software Project Management Plan WiseLib Wout Van Riel Yannick Verschueren Arno Moonens Mathieu Reymond se2-1415 14 Mei 2015 1 Contents 1 Introductie 5 1.1 Projectbeschrijving..........................
Nadere informatieProject. 3D-Fraggel. Plan van aanpak. Door: IH1T08 1/1
Project 3D-Fraggel Plan van aanpak Door: 1/1 Project 3D-Fraggel Plan van aanpak Datum: 07-05-2001 Plaats: Enschede Opdrachtgever: Saxion Hogeschool Enschede Instituut ICT Afdeling Hogere Informatica Contactpersoon
Nadere informatieOPI-PMO - PROJECT MANAGER VERANTWOORDELIJKHEDEN I.V.M. INFORMATIEBEVEILIGING EN VERANTWOORD SPEL
Functiedetail FUNCTIE : OPI-PMO - Project Manager FUNCTIEFAMILIE : Technology AFDELING : Technology DATUM LAATSTE AANPASSING: mei 2010 FUNCTIETITEL DIRECTE LEIDINGGEVENDE: Senior Program Manager OUDE CODE:
Nadere informatieSoftware Test Documentation
FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe
Nadere informatieSoftware Conguration Management Plan Versie 1.1.1
Versie 1.1.1 03-04-2006 Samenvatting Dit is het (SCMP) voor het project.dit project is onderdeel van het vak Software Engineering (2IP40) aan de Technische Universiteit Eindhoven. Het document voldoet
Nadere informatieOfferte voor het bouwen van een website Klant: Ideefiks, IdeeKids
Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids Consultant: Dirk Derom Inhoudstafel Algemene structuur van de website...6 Front pagina...6 Pagina IDEEFIKS/IDEEKIDS...6 Functionaliteit...10
Nadere informatieVERENIGINGSWIJZER.NL PROJECTPLAN
Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen Project Multimedia Peter van Ulden Studentnr. 1494759 VERENIGINGSWIJZER.NL PROJECTPLAN INHOUDSOPGAVE 1 Inleiding...3 2 Project omschrijving...4
Nadere informatieSoftware Requirements Specifications voor Schedule-Generator
Software Requirements Specifications voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 23 februari 2011 Versie 1.1 1 Aanpassingsgeschiedenis. 23/2/2011 versie 0.1:
Nadere informatieSoftware Engineering Groep 4
Software Engineering Groep 4 Software Test Document Kevin Hendrickx (Test Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 17 mei 2012 1 Tabel 1: Document geschiedenis v5.0 17/05/2012
Nadere informatiePracticumhandleiding. (versie 2010)
(versie 2010) Belangrijk! In deze handleiding treft u alle informatie aan die nodig is voor de uitvoering van het practicum. Behalve de organisatie van het practicum zelf en een korte beschrijving van
Nadere informatieSHAREPOINT ONLINE (SAMEN-)WERKEN IN DE WOLKEN. http://www.ie-net.be - Workshop SharePoint 1
SHAREPOINT ONLINE (SAMEN-)WERKEN IN DE WOLKEN 1 WIE ZIJN WIJ? 2 WIE BENT U? Professional Op zoek naar productiviteit Samenwerken met Collega s Externe partijen Onderaannemers 3 WAT IS ONS PLAN? 1. Wat
Nadere informatieTechnisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0
Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin
Nadere informatieAgile werken: zó doen we dat
Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het
Nadere informatieInstituut Broers. Plan van Aanpak. [Project Steam OS
Instituut Broers Plan van Aanpak [Project Steam OS [Zubin Mathoera, Vincent Darwinkel, Tomas Berends] 12-1-2017 VOORWOORD Dit plan van aanpak hebben wij volgens het boek van Roel Grit, Project Management,
Nadere informatieVerslag Vergadering 15 10/04/08
Verslag Vergadering 15 10/04/08 Software engineering: Groep 1 Titularis: Dirk Vermeir Begeleiders: Eline Philips 14 april 2008 Document geschiedenis Versie Datum Autheur Commentaar 0.1 14/04/2008 Nicolas
Nadere informatieTechnisch Ontwerp W e b s i t e W O S I
Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept
Nadere informatieReleasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken
Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van
Nadere informatiePlan van Aanpak. Christophe Deloo, Roy Straver & Machiel Visser. Versie 4 (26-06-2010)
Plan van Aanpak Christophe Deloo, Roy Straver & Machiel Visser Versie 4 (26-06-2010) Inhoudsopgave Voorwoord... 2 1 Inleiding... 3 1.1 Aanleiding... 3 1.2 Accordering en bijstelling... 3 1.3 Toelichting
Nadere informatieCorrespondentie inzake overnemen of reproductie kunt u richten aan:
Vrijwel alle namen van software- en hardwareproducten die in deze cursus worden genoemd, zijn tegelijkertijd ook handelsmerken en dienen dienovereenkomstig te worden behandeld. Alle rechten voorbehouden.
Nadere informatieSoftware Requirements Specifications voor Schedule-Generator
Software Requirements Specifications voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 20 mei 2011 Versie 3.0 1 Aanpassingsgeschiedenis. 23/2/2011 versie 0.1: Aanmaak
Nadere informatiePlan van Aanpak. project Tetris Packing
Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Doel van het project! 5 Onderwerp van het project! 5 Invulling van het project! 6 Producten! 7 Functioneel Ontwerp! 7 Implementatierapport!
Nadere informatieSoftware Engineering Introductie in Software Engineering
Software Engineering 1 Introductie in Software Engineering 1 Academische Integriteit Software Engineering is een activiteit waar samenwerking voorop staat. Je wordt aangemoedigd om samen te werken, maar...
Nadere informatieInstituut Broers. Plan van Aanpak. Zubin Mathoera & Tomas Berends. Zubin Mathoera Tomas Berends Maarten van Mensvoort Tim van Berkel
Instituut Broers Plan van Aanpak Zubin Mathoera & Tomas Berends Zubin Mathoera Tomas Berends Maarten van Mensvoort Tim van Berkel 00-00-0000 VOORWOORD Dit plan van aanpak hebben wij volgens het boek van
Nadere informatieTools die je móét hebben voor je (gaat) testen!
Voorjaarsevenement 2008 Tools die je móét hebben voor je (gaat) testen! Jurian van de Laar (jla@improveqs.nl) 1 Improve Quality Services Dienstverlener Testen & Kwaliteitsmgt. Advisering, Detachering en
Nadere informatieVoorblad Inhoudsopgave Inhoud
Voorblad Inhoudsopgave Inhoud (INHOUD) Achtergronden We moeten een website voor een jonge catering en een party service bedrijf bouwen. Dit bedrijf is gespecialiseerd in verzorging van borrelhapjes en
Nadere informatieStuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010
Stuurgroep ICT innovatie in de ouderenzorg 12 oktober 2010 Agenda High Level Scope Projectorganisatie en werkingsprincipes Projectplanning en roll-out Projectopvolging Evaluatie diensten Agenda volgende
Nadere informatie(Door)ontwikkeling van de applicatie en functionaliteiten
Hieronder is een aantal belangrijke zaken uitgewerkt rondom het Saas/Cloudmodel op basis waarvan InCtrl haar internetsoftware-omgevingen aanbiedt. Dit document is bedoeld om een algemeen beeld te krijgen
Nadere informatieSoftware Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces
Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;
Nadere informatieSoftware Design Document
Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie
Nadere informatieInstituut Broers. Plan van Aanpak. Windows Server
Instituut Broers Plan van Aanpak Windows Server [Zubin Mathoera, Vincent Darwinkel, Tomas Berends] 12-1-2017 VOORWOORD Dit plan van aanpak hebben wij volgens het boek van Roel Grit, Project Management,
Nadere informatiePROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D
PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT
Nadere informatieSoftware Design Document
Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie
Nadere informatieOplossingen voor het testen van objectgeoriënteerde software
Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen
Nadere informatieInhoudsopgave. Hoofdstuk 1: Ant...4
Inhoudsopgave Hoofdstuk 1: Ant...4 1.1 Inleiding...4 1.2 Ant installeren...5 1.3 Ant gebruiken...7 1.3.1 Een project maken...7 1.3.2 Mijn eerste Ant-script...10 1.3.2.1 Projects...10 1.3.2.2 Targets...11
Nadere informatieProject plan. Erwin Hannaart Sander Tegelaar 61849 62407
Project plan Erwin Hannaart Sander Tegelaar 61849 62407 I4C2 I4C1 1 Inhoudsopgave Doel en doelgroep van het project... 3 Beschrijving van het project... 4 Benodigde materialen... 5 Te verwachten resultaten,
Nadere informatieCompenda Business Software
Handleiding verlofconversie Compenda Business Software Compenda verlofconversie Hoofdstuk 1. Uitgangspunt en benodigdheden... 3 Hoofdstuk 2. Controle rapportages conversie... 4 Hoofdstuk 3. Bron toewijzing...
Nadere informatieTeam. Tijd. Tools. Functionaliteiten In de onderstaande afbeelding wordt aangegeven welke behoeften TeamPlayer voor u kan invullen.
TeamPlayer? TeamPlayer is een compleet en flexibel systeem voor tijdsregistratie en planning dat de grootste knelpunten in vele administraties aanpakt, daar waar de standaardsystemen nog te beperkt zijn.
Nadere informatieBusiness Process Management
Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die
Nadere informatieOp de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.
Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:
Nadere informatieFedict/2013/M934/Webanalytics tools ALGEMENE OFFERTEAANVRAAG WEBANALYTICS TOOLS Q & A
Q & A 1. Onderaan pagina 17 van dit bestek staat dat wij op simpele aanvraag toegang kunnen krijgen tot een gereserveerde ruimte waar de te migreren rapporten kunnen worden geconsulteerd. Welke procedure
Nadere informatiePlan Van Aanpak EE4- Building a SSV - Team PM1 14 februari 2014
Plan Van Aanpak EE4- Building a SSV - Team PM1 14 februari 2014 Plan Van Aanpak (PVA) Inleiding Het doel van dit document is om de opdracht kort te schetsen. De inhoud zal voornamelijk gaan over het waarom
Nadere informatieINTERNE AUDIT: ALGEMENE PRINCIPES VOOR DE ORGANISATIE EN DE UITVOERING
BELAC 3-03 Rev 5-2017 INTERNE AUDIT: ALGEMENE PRINCIPES VOOR DE ORGANISATIE EN DE UITVOERING De versies van documenten van het managementsysteem van BELAC die beschikbaar zijn op de website van BELAC (www.belac.fgov.be)
Nadere informatieQuality Gates: De overdracht tussen ontwikkelaars en testers geregeld
Quality Gates: De overdracht tussen ontwikkelaars en testers geregeld Rik Marselis Senior Testadviseur Logica 2008. All rights reserved Even voorstellen: Rik Marselis Senior Testadviseur ruim 27 jaar IT
Nadere informatieSoftware project management plan voor Schedule-Generator
Software project management plan voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 17 februari 2011 Versie 2.0 1 Aanpassingsgeschiedenis. 16/2/2011 versie 0.1: Aanmaak
Nadere informatieBottleball Onderzoeksverslag MovingMonsters. Uitgevoerd door Arno Classens a.classens@student.fontys.nl
Bottleball Onderzoeksverslag MovingMonsters Uitgevoerd door Arno Classens a.classens@student.fontys.nl 1 1. Inhoudsopgave Wat? Bladzijde 1. Introductie 3 2. Methodologie 4 3. Resultaten 3.1 Oriëntatie
Nadere informatieToelichting bij onze werkwijze
Toelichting bij onze werkwijze GMI group Helpdesk Referentie: IDH_20120713_HDP_V2.0 Datum: 15 oktober 2015 COLOFON TITEL Een toelichting bij onze werkwijze GMI group Helpdesk UITGEVER GMI group N.V. De
Nadere informatiePlan van Aanpak Business Project
1. Aanleiding en achtergrond van het project Soulco is een Belgische KMO die zijn activiteiten uitoefent in Afrika en het Midden- Oosten. Ze willen graag een nieuwe website omdat hun huidige website volledig
Nadere informatieProjectdocument Minecraft Mod Builder
Projectdocument Minecraft Mod Builder Projectgroep Twintro 11 december 2015 Inhoudsopgave 1 Probleemstelling 2 2 Productbeschrijving 2 3 Requirements analyse 3 3.1 Functional requirements................................
Nadere informatieBijlage 3: Master testplan
Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0
Nadere informatieStations Automatisering. Vooruitgang of tijdbom
Stations Automatisering Vooruitgang of tijdbom 1 Overzicht Inleiding Ervaringen met SA en Beveiligingen Firmware Hardware Tools Windows en KA Organisatie Mogelijke problemen in de toekomst Mogelijke oplossingen
Nadere informatieOplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.
Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen
Nadere informatieSoftware project management plan voor Schedule-Generator
Software project management plan voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 20 mei 2011 Versie 3.0 1 Aanpassingsgeschiedenis. 16/2/2011 versie 0.1: Aanmaak
Nadere informatieStichting NIOC en de NIOC kennisbank
Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen
Nadere informatie1 Goedkeuring verslag vorige vergadering... 2 2 Algemene afspraken... 2 3 Volgende vergadering... 2 4 Actielijst... 2
Google Vergadering van 15 februari 2011 Aanwezig: Pieter-Jan Van Aeken Eric Stevens Steyn Slagmolen Cindy Jansen Mathi De Pauw Verontschuldigd: / Afwezig: / Voorzitter: Cindy Jansen Verslaggever: Pieter-Jan
Nadere informatieGAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter
GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter
Nadere informatieHandleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren
Auteur(s) Datum Versie Frédéric van der Vaeren 11/03/2013 2.0 Eigenaar Doelpubliek Bert van Hemelen Gebruikers checklist overdracht project/change naar beheer Handleiding : Handleiding voor de checklist
Nadere informatieAlgemene voorwaarden_
Algemene voorwaarden_ Betalingen o Het begrootte bedrag is onder voorbehoud van bepaalde wijzigingen in scope van project en aannames en andere toepasselijke voorwaarden hierin beschreven. Eventuele vertraging
Nadere informatieTest rapportage Waarom eigenlijk?
Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar
Nadere informatieInhoud. Introductie tot de cursus
Inhoud Introductie tot de cursus 1 De functie van de cursus 7 2 De inhoud van de cursus 7 2.1 Voorkennis 7 2.2 Leerdoelen van de cursus 8 2.3 Opbouw van de cursus 8 3 Leermiddelen en wijze van studeren
Nadere informatie