Project Initiatie Document. Ferdie Sletering( ) Jeffrey Meijer ( ) Jeroen Eissens( ) Matthijs Vastenburg( )

Transcriptie

1 hogeschool utrecht Ferdie Sletering( ) Jeffrey Meijer ( ) Jeroen Eissens( ) Matthijs Vastenburg( ) Information Engineering (IEV 4A) Skuadra 5

2 Ferdie Sletering ( ) Jeffrey Meijer ( ) Jeroen Eissens ( ) Matthijs Vastenburg ( ) IEV 4A Skuadra 5 Faculteit: Opleiding: Beoordelaar: Hogeschool Utrecht Faculteit Natuur & Techniek Information Engineering Nini Salet Project: Web Essentials Cursuscode: TCIE-V3WEBPR7-07 Versienummer: Datum: 17 maart /23

3 doel document Het doel van dit document is het informeren van partijen die verbonden zijn aan dit project. Met informeren wordt hier bedoeld dat de partijen moeten weten wat er met dit project wordt nagestreefd. Dit document beschrijft hoe, door wie, waarom en op welke manier dit project wordt uitgevoerd. Er staan afspraken in die gelden binnen het project, maar ook wie welke verantwoordelijkheden draagt. Kortom dit document beschrijft wat het project inhoud, wie de projectleden zijn, wat hun taken zijn en de verantwoordelijkheden van elke taak. Het geeft de betrokken partijen een duidelijk beeld over het project. Ook wordt dit document als richtlijn gehanteerd tijdens de projectperiode. Dit document zal gebruikt worden als meetinstrument. Aan de hand van dit document kan gemeten worden hoe het met de voortgang staat en of het project nog haalbaar is(status vergelijken met de planning) binnen de gestelde deadline. 3/23

4 distributielijst Naam Rol Datum Actie Nini Salet Slo begeleider versienummering versiebeheer Goedkeuring/afkeuring PID Versie Omschrijving Datum Wijzigingen 0.1 Concept versie PID Geen, opzet document 1.0 Final versie PID Commentaar verwerkt 4/23

5 what s in here? contents DOEL DOCUMENT... 3 VERSIEBEHEER PROJECTACHTERGROND PROJECTDEFINITIES projectdoelstelling scope van het project afbakening randvoorwaarden relaties met andere projecten aannames resultaten/eindproduct PROJECTAANPAK doelstelling tijdsbestek kwaliteitsnorm informatie methode scope project acceptatiecriteria TOLERANTIES KWALITEITBEHEERSING beheersing projectvoortgang bewaken en rapporteren projectvoortgang projectplanning releaseplanning vergaderingen notulen end stage rapport /23

6 6 PROJECTPLAN projectactiviteiten Taakverdeling planning INITIEEL RISK LOG risicoanalyse risicomanagement PROJECTORGANISATIE QUALITY PLAN kwaliteit documenten algemene procedures concrete eisen verantwoordelijken procedure s wijzigingsbeheerder versiebeleid /23

7 1 projectachtergrond 1.1 context van het project De studenten van de opleiding Information Engineering aan de faculteit Natuur en Techniek van de Hogeschool Utrecht, hebben een opdracht gekregen in het kader van het project Web Essentials. De opdracht omschrijving luidt: "Automatiseer het stage- en afstudeerproces van de Hogeschool Utrecht. In het bijzonder het cluster ICT en dat van het Institute van Life Science & Chemistry " Om de opdracht te realiseren zijn er projectgroepen geformeerd die in een tijdsbestek van 18 weken het project dienen te realiseren. 1.2 aanleiding om het project te starten Het huidige stage- en afstudeerproces geeft geen duidelijk beeld van afstudeerders en de bedrijven waar ze afstuderen. Het huidige softwarepakket STAR is sinds twee jaar niet meer geschikt vanwege de omvang van de gegevens. De knelpunten ondervonden door afstudeerbegeleiders: - Geen duidelijk overzicht waar de student afstudeert - Geen duidelijk overzicht wat de student uitvoert - Geen centraal punt beschreven waar alle gegevens beschikbaar zijn - De statussen van studenten en voorstellen zijn niet actueel om het feit dat er met regelmaat individuele afspraken worden gemaakt tussen de afstudeerbegeleider en de student die afstudeert. - Veel administratieve werkzaamheden gemiddeld één uur per afstudeerder De bovengenoemde knelpunten zijn aanleiding voor het starten van dit project. 7/23

8 2 projectdefinities 2.1 projectdoelstelling Het automatiseren van het stage- en afstudeerproces van de Hogeschool Utrecht. In het bijzonder het cluster ICT en dat van het Institute van Life Science & Chemistry. Dit wordt gedaan zodat de gegevens in een geautomatiseerd systeem komen te staan. Dit zorgt voor een betere workflow. 2.2 scope van het project De scope van het project omvat het cluster-ict en het Institute voor Life Science & chemestry. Deze vallen onder het faculteit Natuur en Techniek. Andere faculteiten zullen geen toegang hebben tot het systeem. Wat gaan we wel doen: Binnen dit project gaan wij ons bezig houden met het Document Management Systeem(DMS - Hieraan koppelen wij een Web frontend, om gebruikers een overzichtelijker scherm te geven. Het pakket KnowledgeTree wordt gebruikt als DMS. Dit pakket wordt geconfigureerd voor ons project. Ook schrijven wij documentatie wat hiermee een relatie heeft. Wat gaan we niet doen: Hieronder staat een overzicht van onderdelen die buiten onze scope vallen: 1. Koppeling met Osiris 2. Koppeling met Sharepoint 3. Koppeling met Active Directory 4. Personeel opleiden 5. Koppeling met de formatieplanning 6. Toegang geven voor bedrijven De bovenstaande onderdelen vallen buiten onze scope, omdat wij één semester(18 weken) hebben gekregen om dit project te realiseren. Dit zorgt er meteen voor dat wij een strak schema hebben. De punten 1,2,4,5 kosten ons veel tijd, omdat dit uitgezocht moet worden of dit mogelijk is. Als dit mogelijk zou zijn moet ook uitgezocht worden hoe. Dit is tijdrovend werk en die tijd hebben wij niet. De punten 1,2,3 zijn punten waar wij geen rechten voor hebben gekregen om dit te realiseren. Het is dus niet mogelijk om deze binnen de Hogeschool Utrecht te realiseren. Toegang geven voor bedrijven achten wij niet noodzakelijk en hebben wij niet in de scope opgenomen. 2.3 afbakening Het pakket KnowledgeTree zal worden geïmplementeerd en functioneren als een Document Management Systeem. Met dit systeem kunnen de gebruikers documenten beheren en daaraan verschillende statussen toekennen. 8/23

9 2.4 randvoorwaarden Beschikbaarheid informatiebronnen Om het installatiepakket naar wens te laten functioneren met de gerelateerde processen is het van belang dat er voldoende informatie tot onze beschikking is. De volgende bronnen kunnen geraadpleegd worden: - Wouter Nijenhuis (Life Science & Chemistry) - Machteld Verkade (Stage coördinator) - Martin Wensink (Afstudeer coördinator) - Afstudeer commissie ICT - Afstudeer commissie ILC - Documentatie KnowledgeTree ( - Eindgebruikers softwarepakket STAR Installatiepakket De opdrachtgever heeft vastgesteld dat het pakket KnowledgeTree gebruikt moet worden voor het inrichten van een Document Management Systeem. Hogeschool Utrecht server eisen Het pakket KnowledgeTree heeft specifieke installatie eisen. De server moet aan de eisen voldoen. - Linux - Minimaal PHP versie 5.1.6, versie wordt aangeraden - MySQL De volledige installatie eisen kan je vinden op Tijdsvoorwaarde De duur van het project is vooraf vastgesteld op 18 weken. Voor het realiseren van het project is er een projectteam vastgesteld van vier projectleden die ieder 308 uur beschikbaar zijn voor het realiseren van het project. 2.5 relaties met andere projecten De tweede jaarstudenten volgen momenteel het zelfde semester als de derde jaarstudenten information engineering namelijk het Web Essentials project. De opdracht omschrijving is identiek, het geen wat verschild zijn de installatie pakketen. De tweede jaarstudenten richten zich op het pakket KnowledgeTree en de derde jaarstudenten op het pakket SugarCRM. 9/23

10 De collegevakken kan je in verband stellen met het project omdat deze gebaseerd zijn op het project Web Essentials. Het doel van de onderstaande vakken, is om de student informatie te verschaffen over web applicaties. Web Applications 1 Web Essentials Product Web Development Web Ontwerp 2.6 aannames Gedurende het project worden er verschillende keuzes gemaakt. In deze paragraaf verantwoorden we onze aannames. Studenten (projectlid) Een studiepunt vertegenwoordigd 28 uur van de student. Het project is in totaal 11 studiepunten wat betekent dat elk project lid 308 uur beschikbaar is. Voorzieningen Het projectlid moet voorzien zijn van een laptop om zijn werkzaamheden te kunnen verrichten. En flexibel te zijn in de werkomgeving. Werkruimte Er is geen standaard werkruimte tot onze beschikking. We moeten flexibel zijn in de ruimte waar we willen werken. Projectmatig werken Om structuur te geven aan het project maken we gebruik van de methodiek Prince2 2.7 resultaten/eindproduct Het eindproduct betreft een werkend document management systeem en een op maatwerk ontwikkelde User Interface. Om tot het eindproduct te komen dienen de volgende deelproducten opgeleverd Visie/scope document Functioneel ontwerp document Technisch ontwerp document READ ME van Development Test- rapporten 10/23

11 3 projectaanpak 3.1 doelstelling Het automatiseren van het stage- en afstudeerproces van de Hogeschool Utrecht. In het bijzonder het cluster ICT en dat van het Institute van Life Science & Chemistry. Dit wordt gedaan zodat de gegevens in een geautomatiseerd systeem komen te staan. Dit zorgt voor een betere workflow. 3.2 tijdsbestek Dit project heeft een groot tijdsaspect. Het project telt één semester (18 weken). Binnen deze periode doorlopen we drie fases: 1. Voorbereiding fase. 2. Hoofd fase. 3. Afsluitende fase. Voorbereiding fase: Hier wordt het project initiatie document opgesteld. Dit document is noodzakelijk om het project te laten starten. Dit document geeft een overzicht van het project. Hoofd fase: Deze fase doorloopt de iteratie. Elke week moet een iteratie doorlopen worden met als eindresultaat een End stage rapport. Het rapport toont wat er in de iteratie behandeld is. Afsluitende fase: De afsluitende fase heeft betrekking op het presenteren van het door ons gemaakte systeem. Deze presentatie is in het Engels en wordt getoond aan de opdrachtgever. 11/23

12 3.3 kwaliteitsnorm Binnen dit project wordt er gebruik gemaakt van een iteratief proces. Dit houd in dat wij een iteratie cyclus doorlopen zodra wij iets toevoegen of veranderen aan het systeem. Een iteratie cyclus is een stroom van informatie. Hieronder staat wat het proces inhoud: 1. Visie scope 2. Functioneel ontwerper 3. Technisch ontwerper 4. Development 5. White box tester 6. Black box tester Hierboven staan zes taken. Deze taken zijn opeenvolgend, net zoals de nummering. Zodra deze stappen doorlopen zijn wordt aan de hand van de test documenten duidelijk of de use-case met succes doorlopen is. Als dit niet het geval is gaat de use-case opnieuw door het iteratief proces. Als dit wel het geval is dan is de use-case met succes afgerond en kan er aan de volgende begonnen worden. 3.4 informatie Om ervoor te zorgen dat alle projectleden op dezelfde lijn zitten wordt er minimaal één keer per week een intern gesprek gehouden. Hierin wordt besproken welke handelingen zijn verricht en welke nog gedaan moeten worden. Ook wordt er één keer per week een terugkoppeling gedaan naar de opdrachtgever, dit wordt gedaan door de projectleider. Dit wordt gedaan om ervoor te zorgen dat ook de opdrachtgever op de hoogte is van de gang van zaken en eventueel commentaar/feedback kan geven. De overige informatie wordt vergaard door middel van interviews. Deze interviews worden gehouden met de toekomstige gebruikers van het systeem. Deze geven belangrijke informatie over hun eisen aan het systeem. 3.5 methode Hoe gaan wij dit project realiseren? Dit project wordt opgezet met Prince2 als project methode. Prince2 geeft een basis voor verdere activiteiten die gedaan moeten worden om een succesvol project te krijgen. Door middel van Prince2 wordt er documentatie op gezet die door de klant beoordeeld kan worden. Deze documentatie laat zien hoe de opdracht wordt uitgevoerd. Ook geeft het een overzicht wanneer er iets af moet zijn volgens van de planning. Deze planning laat zien wanneer een activiteit begint en eindigt. Kwaliteitcontrole is van groot belang, omdat het product moet functioneren. Deze controle moet gedaan worden om te kijken wanneer een bepaalde activiteit gedaan is en door wie. Hierdoor kunnen zowel de opgeleverde producten gecontroleerd worden als het werk van een project lid. 12/23

13 Dit project wordt gemaakt door middel van een iteratief proces. Dit houdt in dat wij een iteratie doorlopen en binnen die iteratie een aantal stappen behandelen(daarom het iteratief proces). Een iteratie bevat de volgende onderdelen 1. Visie/scope 2. Functioneel ontwerp 3. Technisch ontwerp 4. Realisatie 5. White box test 6. Black box test De volgorde van 1 t/m 6 is ook de volgorde die in een iteratie wordt gehanteerd, omdat de stappen informatie nodig hebben van de bovenliggende stap. Een iteratie kan voor hetzelfde onderdeel binnen het project meerdere keren doorlopen worden. Een herhaling houdt in dat het onderdeel niet aan de gewenste eisen voldoet. Het wordt pas duidelijk tijdens het testen of het onderdeel aan de gewenste eisen voldoet, vandaar dat er veel tijd in het testen gestoken wordt. Binnen dit project is het de bedoeling dat we een document management systeem realiseren. Dit wordt bereikt door middel van informatie vergaren(aan welke eisen het systeem moet voldoen en wat voor een informatie het systeem moet opslaan) en vervolgens gemaakt met KnowledgeTree. Hiermee kan een document management systeem gerealiseerd worden, omdat deze aanpasbaar is aan de wensen van de klant. Wel moet er een front end komen, welke er voor zorgt dat de applicatie via het internet te bereiken is. 3.6 scope project Hier wil ik u verwijzen naar Hoofdstuk 2 paragraaf acceptatiecriteria Het acceptatiecriteria beschrijft waarop wij beoordeeld worden. Aan het einde van dit project wordt een product opgeleverd. Aan dit product zijn een aantal eisen gesteld. Hieronder een opsomming van de gestelde eisen: 1. Er wordt gewerkt met een iteratief proces(3.3) 2. Er worden tussenproducten opgeleverd 3. Er wordt gewerkt met de prince2 methodiek 4. Wij maken een Document Management Systeem en een web front-end 5. Elk teamlid heeft zijn eigen taak 6. Een rode draad moet aanwezig zijn Ook leveren wij tussenproducten op. De tussenproducten vormen samen het gehele product. Hieronder staat een lijst waarop wij beoordeeld worden: 1. Documentatie 2. Samenwerking 3. Product 4. Interne communicatie 5. Externe communicatie 13/23

14 4 toleranties Toleranties zijn acceptabele afwijkingen van een streefwaarde, de toleranties die van toepassing zijn op het project worden hieronder nader toegelicht. De doorlooptijd van het project komt op 18 weken. In deze 18 weken gaan wij van concept naar realisatie. Het gehele project is niet te realiseren in 18 weken. Wij hebben voor deze periode een afbakening van het project opgesteld om er zo voor te zorgen dat wij in deze 18 weken een deel van het project kunnen realiseren. Als er uit de tussenproducten of de afspraken blijkt dat de deadline niet meer gehaald kan worden, dan moet de Project Board hiervan op de hoogte gesteld worden. Uiteraard is er speling in de planning die eventuele tot op een schaal kan opvangen. Als iets niet af komt voor de geplande datum zal er extra tijd de week erop moeten besteed worden aan het project. Er zullen dus nieuwe bijeenkomsten gepland worden en nieuwe afspraken gemaakt worden, buiten de planning om, er moet dan overgewerkt worden. 14/23

15 5 kwaliteitbeheersing 5.1 beheersing projectvoortgang De voortgang van het project moet ten alle tijden gecontroleerd worden, dit gebeurd door de planningen te volgen. Het end stage rapport geeft verduidelijking op de werkzaamheden per iteratie, samen met de planning kan vergeleken worden welke werkzaamheden op welk punt gedaan moesten worden en zo kan de voortgang vergeleken worden met de planning. Op het moment dat de voortgang achterloopt op de planning kan het project in gevaar komen. 5.2 bewaken en rapporteren projectvoortgang De projectleider dient de projectvoortgang te bewaken, van de projectleden wordt geacht achterstanden te melden. De projectleider zal achterstanden rapporteren en proberen deze zoveel mogelijk te beperken. 5.3 projectplanning In de project planning staat beschreven welke activiteiten er uitgevoerd worden per fase op beschreven data. De project planning is een product dat helpt bij het bewaken van de voortgang van het project. 5.4 releaseplanning In de release planning staat beschreven wanneer de (deel)producten opgeleverd dienen te worden. Het opleveren gebeurt in een regelmatige interval. Ook geeft de release planning aan waar aan gewerkt moet worden voor een volgende release. 5.5 vergaderingen Vergaderingen zijn ervoor om te controleren of het project nog naar de wens van de klant verloopt. Vergaderingen kunnen leiden tot maatregels om ervoor te zorgen dat de voortgang van het project niet in gevaar komt. Tijdens vergaderingen komen eventuele problemen naar boven die anders te laat gesignaleerd zouden worden door de projectgroep. 5.6 notulen In de notulen staan afspraken die gemaakt zijn tijdens vergaderingen. Notulen zijn er om beide partijen later te wijzen op hun afspraken zodat er geen verwarring ontstaat. 5.7 end stage rapport Elke iteratie eindigt met een end stage rapport. Dit document wordt opgeleverd aan de opdrachtgever en beschrijft de voortgang van de iteratie. Zo kan de opdrachtgever inzien hoe het staat met de voortgang van het project. 15/23

16 6 projectplan 6.1 projectactiviteiten Documentatie Documentatie die gemaakt wordt voor de klant en intern gebruik. Deze documentatie is noodzakelijk voor verbetering van de software en voor klantgebruik. Er wordt zowel gedocumenteerd voor gebruik als voor verbetering. Notuleren Aantekeningen die gemaakt worden tijdens een projectbespreking met de projectbegeleider. In deze aantekeningen worden verbeter punten beschreven. Spellingscontrole Een controle van de spelling. Dit zorgt ervoor dat de documenten geen fouten bevat. Configureren Het configureren van onderdelen. De configuratie wordt bepaald op basis van een use-case gemaakt door de functioneel ontwerper. Testen Onderdelen die zijn geconfigureerd worden uitvoerig getest om fouten te voorkomen. Het systeem testen wordt gedaan door een white box tester, hier worden een aantal testcases gemaakt die testen of de configuratie settings kloppen. Daarna wordt er een rapport opgesteld wat nodig is voor een volgende versie. De interface wordt getest door een black box tester, hier wordt de functionaliteit getest. Een test op werking en gebruikersvriendelijkheid. Hieruit komt een rapport dat voor de klant is bestemd. Project management Alle werkzaamheden die te maken hebben met het organiseren en aansturen van de projectgroep. Interviewen Interviews worden afgenomen om meer informatie te vergaren. Dit is nodig om duidelijk in kaart te brengen wat de wensen zijn van zowel de opdrachtgever als de toekomstige gebruikers. Aan de hand van deze interviews kan een goed beeld gevormd worden van de eisen en wensen aan dit systeem. 16/23

17 6.2 Taakverdeling Notulist - Ferdie Sletering Voorzitter - Jeffrey Meijer Spelling controleur - Gehele projectgroep Projectleider - Jeroen Eissens Analist - Ferdie Sletering Functioneel ontwerper - Jeffrey Meijer Technisch ontwerper - Gehele projectgroep Realisatie - Gehele projectgroep White box tester - Matthijs Vastenburg Black box tester - Matthijs Vastenburg Eindverantwoordelijke -Projectleider 17/23

18 6.3 planning Ik verwijs u naar planning pid.mpp voor de planning. Deze is te groot om hier duidelijk weer te geven. 6.4 Product breakdown structure Ik verwijs u naar bijlage 1 voor de planning. Deze is te groot om hier duidelijk weer te geven. 18/23

19 7 initieel risk log 7.1 risicoanalyse Om het gehele projectproces zo efficiënt mogelijk te laten verlopen, wordt er rekening gehouden met bepaalde risico s die zich kunnen ontwikkelen tijdens het project. Deze risico s zijn verwerkt in het onderstaande risk log. Per risico wordt een beschrijving gegeven en de actie die zal worden uitgevoerd als het risico zich voordoet. De impact en de kans (schaal 1(laag) tot 5(hoog)) geven aan wat het risico is en welke impact het heeft op de projectgroep. Als het risico zich toch voordoet wordt de actie bij het gebeuren van risico uitgevoerd. 19/23

20 7.2 risicomanagement Beschrijving Tegenmaatregel Bij gebeuren van risico Kans Impact Risico Afwezigheid projectleden De werkzaamheden worden overgenomen door de andere projectleden. Bij afwezigheid moet de projectleider op de hoogte worden gesteld Afwezigheid Projectleider Eventuele afspraken worden ver genoeg van te voren gemaakt zodat dit geen probleem kan zijn. Urgente beslissingen worden genomen door de Jeffrey Meijer Bij afwezigheid worden de taken van de projectleider overgenomen door Jeffrey Meijer Deadline wordt niet gehaald Speling creëren in de planning. Voortgangsrapport opstellen (end stage rapport) deze wordt gebruikt in terugkoppeling met de project board. Overleggen met de project board en de planning aanpassen Producten(& deelproducten) zijn niet conform de eisen van de opdrachtgever Informatie vergaren bij de opdrachtgever om zo de eisen te achterhalen. Verder wordt er gekeken naar de oplevering tijdens de projectvergadering of de gerealiseerde producten wel voldoen aan de gestelde eisen. Dit wordt getest aan de hand van de quality reviews. De producten worden verbeterd in de volgende versie. Deze verbetering wordt gedaan aan de hand van een terugkoppeling met de opdrachtgever Producten zijn niet conform eisen projectgroep Voor elke oplevering worden alle documenten doorgesproken in de projectgroep en mogelijke verbeteringen aangegeven in het quality review. De verbeteringen worden aangegeven in het quality review door de projectgroep en het projectlid moet deze wijzigingen doorvoeren. Als de klant er belang bij heeft worden deze verbeteringen teruggekoppeld /23

21 De projectgroep heeft drie leden en één projectleider Jeroen Eissens (afkomstig uit het combi-traject Information Engineering) Rol: Projectleider Tel. nr.: Stud. nr.: Matthijs Vastenburg (afkomstig uit het 2 de jaar Informatica) Rol: Test-Lead matthijs.vastenburg@gmail.com Tel. nr.: Stud. nr.: Jeffrey Meijer (afkomstig uit het 3 e jaar Information Engineering) Rol: Fo-Lead j.e.meijer@gmail.com Tel. nr: Stud. nr: Ferdie Sletering (afkomstig uit het 1 e jaar Informatica) Rol: Analist s_ferdie@hotmail.com Tel. nr: Stud. nr: Rol: Dev-Lead Uitgevoerd door: Matthijs Vastenburg Ferdie Sletering Jeffrey Meijer Jeroen Eissens 8 projectorganisatie 21/23

22 9 quality plan Voldoen aan de uitgesproken en vanzelfsprekende verwachtingen van de interne en de externe klant. (Bron: Goede kwaliteit: het product voldoet aan de gestelde eisen(hoofdstuk 3 paragraaf 3.6) en is op tijd af (of eerder dan verwacht). Slechte kwaliteit: het product is niet op tijd af en het voldoet ook nog niet aan de gestelde eisen. Het ziet er voorlopig ook niet uit dat het product snel af komt. 9.1 kwaliteit documenten Documenten dienen van goede kwaliteit te zijn. Degenen die het lezen moeten het document ook begrijpen. De developer moet de documenten niet alleen lezen maar ook begrijpen en toepassen, als dat niet goed gebeurt kan dit negatieve gevolgen hebben voor de kwaliteit van het product. Het is daarom goed om tussentijds te controleren of de implementatie van de documenten conform ontwerp(en dus kwalitatief goed) is. Voor het opleveren van een document wordt er een quality review gehouden, dit om te achterhalen of er problemen zijn met de kwaliteit van een document. 9.2 algemene procedures De projectleider leidt het project, door alle processen te observeren en aanwijzingen te geven kan het eindproduct kwalitatief goed zijn. Een op te leveren product wordt altijd gecontroleerd door de teamleden. Door middel van tips en aanwijzingen wordt de kwaliteit van de producten verhoogt en kunnen problemen met de kwaliteit in een vroeg stadium achterhaald worden. 9.3 concrete eisen Zolang alle projectleden zich houden aan de punten die hier gegeven zijn is de kans groot dat de kwaliteit van de producten goed is. De verschillende versies van de producten moeten worden gecontroleerd aan de hand van eisen die gesteld worden aan de opgeleverde versies. 22/23

23 9.4 verantwoordelijken Als het project de verkeerde kant op gaat en niet meer conform de vastgestelde eisen/richtlijnen is, moet er worden ingegrepen door de projectleider. Het resultaat kan zijn dat werk soms voor niets is geweest en er dus tijd verloren is gegaan. Dit kan de kwaliteit negatief beïnvloeden en leiden tot een kwalitatief slecht project. 9.5 procedures wijzigingsbeheerder In opgeleverde (deel)producten mogen geen wijzigingen meer aangebracht worden, tenzij er goedkeuring van wijziging is na overleg met zowel de klant als het projectteam. Activiteiten binnen wijzigingsbeheer zijn: Het beoordelen van projectkwesties (Project Issues) die de status van aandachtspunten (Request for Change) of afwijking van de specificaties (Off- Specification) hebben gekregen. Het bepalen van de impact die projectkwesties op tijd, kwaliteit, scope en risico s hebben. Het starten van gecontroleerde wijzigingsacties aan de benodigde producten. 9.6 versiebeleid Om ervoor te zorgen dat iedereen weet welke documentatie van welke datum is wordt het volgende formaat gebruikt voor versienummers: WEEK.DAG.UUR Voorbeeld: Week: 2 Dag: maandag(1) Uur: vier uur(16) Versienummer: Uitleg: Het weeknummer is het weeknummer van de projectweken, niet van de kalenderweken. Verder zijn de dagen & uren duidelijk uitgelegd in het bovenstaande voorbeeld. 23/23