WWB-SE-0044 Verificatie en Validatie, versie 0.5

Bestandsnaam: WWB-0044 - Verificatie en validatie v 0.5.doc Versie 0.5 Datum: 9 nov. 09 Pagina: 1/37 Opsteller: V. van der Meijden (DZH)

Werkwijzebeschrijving 00044 Verificatie en Validatie

“Bewijsvoeringmethode + Criterium + Beoordelaar”


Voorwoord Na het uitkomen van de “Leidraad voor systems engineering binnen de GWW-sector” (2007) hebben diverse onderzoeken gevolgd over het onderwerp van het verloop van de nieuwe werkwijze. De meeste van deze onderzoeken staan beschreven in rapportages zoals, onder andere:

- “Effecten van systems engineering bij rijkswaterstaat projecten”, RWS 2009 - ”Lessons Learned Toetsen van Vraagspecificaties Eisendeel”, RWS 2009 - “V&V Scan”, RWS 2009

Deze onderzoeken beslaan vooral de ervaringen zijn opgedaan bij projecten met de nieuwe werkwijze. Meerdere malen worden in deze onderzoeken uitroeptekens en vraagtekens geplaatst bij het proces van verificatie en validatie. Dit vormt de aanleiding voor deze werkwijzebeschrijving. Deze werkwijzebeschrijving beoogt een beter begrip van de achtergrond en de inhoud van verificatie en validatie te geven. Het doel van deze werkwijzebeschrijving is ook om Opdrachtgevers en Opdrachtnemers beter met elkaar te kunnen laten samenwerken op projectniveau met deze begrippen en de processen en activiteiten die er in schuilen.

Wij beogen deze werkwijzebeschrijving wanneer nodig aan te passen. Mochten er desondanks naar aanleiding van het lezen van deze werkwijzebeschrijving vragen zijn over het onderwerp of mist u essentiële informatie dan kunt u altijd een email sturen aan [email protected]. Dan krijgt u meestal direct of dezelfde week nog een reactie van mij of mijn collega’s die u graag verder helpen in uw werk.


INHOUDSOPGAVE 1 Inleiding...................................................................................................................4

1.1 Context van dit document..................................................................................4 1.2 Wat de lezer moet weten na het lezen van dit stuk............................................4

2 Begrippen en definities ..........................................................................................5

2.1 Inleiding ............................................................................................................5 2.2 Wat betekenen “verificatie” en “validatie” (definities) .........................................5 2.3 Begrippenkader voor verificatie en validatie ......................................................6 2.4 Basisprincipe voor het kunnen verifiëren en valideren.......................................8

2.4.1 Basisprincipes................................................................................................8 2.4.2 Aanvullende voorwaarden..............................................................................8

2.5 Wat je verder nog moet weten… .......................................................................9 2.5.1 Wanneer krijg je met V&V te maken? (Vraagspecificatie Procesdeel)............9 2.5.2 Wat zijn de aandachtspunten? (Benoem een V&V manager).........................9

3 Overzicht van bewijsvoeringmethoden voor V&V..............................................12

3.1 Verificatiemethoden ........................................................................................12 3.1.1 ONTWIKKELINGSFASE (Verkenning, Planstudie, Ontwerp).......................12 3.1.2 REALISATIEFASE (Bouw, Oplevering)........................................................15 3.1.3 GEBRUIKSFASE (Beheer, Instandhouding) ................................................18

3.2 Validatiemethoden ..........................................................................................20 3.2.1 ONTWIKKELINGSFASE (Verkenning, Planstudie, Ontwerp).......................20 3.2.2 REALISATIEFASE (Bouw, Oplevering)........................................................21 3.2.3 GEBRUIKSFASE (Beheer, Instandhouding) ................................................22

3.3 Uitzonderingen................................................................................................23 3.4 Te beperkte verwijzing naar normen en richtlijnen...........................................24

4 Het vaststellen van V&V criteria ..........................................................................26 5 Beoordeling van V&V documentatie ...................................................................28 BIJLAGEN Bijlage I. Definities Verificatie en Validatie uit literatuur.......................................31

I-1. INCOSE ..........................................................................................................31 I-2. Defence Aquisition handbook, Dept. Of Defence, U.S.....................................31 I-3. NEN-EN ISO 15288:2002 ...............................................................................31

Bijlage II. V&V Bepalingen uit Vraagspecificatie Procesdeel ............................32 Bijlage III. SCB Toetsvragen voor projecten in uitvoering..................................35

III-1. Inrichting V&V Proces ................................................................................35 III-2. Organisatie/structuur..................................................................................35 III-3. Inhoud........................................................................................................35 III-4. Mens..........................................................................................................36

Bijlage IV. Do it yourself “V&V Kick-off” voor projectteams...............................37 IV-1. Werk de vragen samen uit met je projectteam: ..........................................37


1 Inleiding Het vroegtijdig inschakelen van de markt betekent meer taken en meer verantwoordelijkheden voor de markt. Deze zijn alleen beheersbaar wanneer Rijkswaterstaat duidelijk in eisen vastlegt welke prestatie(s) door de markt verricht moet(en) worden, op basis van de functie van het te ontwikkelen of te onderhouden systeem. Het aantonen en vaststellen dat hierin wordt voldaan zijn de doelen van verificatie en validatie. Verificatie en validatie zijn koepelbegrippen en moeten daarom specifieker worden omschreven en wanneer ze worden gebruikt. In dit document wordt ingegaan op de achtergronden, begrippen en de specifieke kenmerken en bijbehorende rollen en taken die horen bij verificatie en validatie in de projecten en over de gehele levenscyclus van de systemen van Rijkswaterstaat.

1.1 Context van dit document

Dit document is gepositioneerd onder de Leidraad voor Systems Engineering binnen de GWW-sector en heeft primair tot doel de begripsvorming rondom en de werkbaarheid met verificatie en validatie te vergroten. De Leidraad voor Systems Engineering binnen de GWW-sector kunt u downloaden via http://www.leidraadse.nl.

1.2 Wat de lezer moet weten na het lezen van dit stuk

- De definities van verificatie en validatie en de inhoud van deze begrippen - Welke contractstukken beschrijven de voorwaarden die Rijkswaterstaat stelt aan

de Opdrachtnemers voor verificatie en validatie? - Wat maakt een verificatiebeschrijving “goed”? - Hoe kies ik de juiste detailniveau om de verificatie te op te baseren? - Wat zijn V&V valkuilen?

1.3 Leeswijzer

Hoofdstuk 2 is gewijd aan het begrippenkader van verificatie en validatie. Een inhoudelijke beschrijving is gegeven voor de bewijsvoeringmethoden in hoofdstuk 3. In hoofdstuk 4 is ingegaan op de verificatie en validatie criteria en hoofdstuk 5 behandelt de beoordelaars van de documentatie van verificatie en validatie.


2 Begrippen en definities

2.1 Inleiding

Er bestaan zeer veel definities voor de termen verificatie en validatie. Dit levert voor zowel de nieuwkomer als de specialist veel verwarring op en daarom is Hoofdstuk 2 gewijd aan het begrippenkader van verificatie en validatie. Opvolgend worden behandeld de definities van verifiëren en valideren, de inhoud van deze begrippen en de kaders waarbinnen de begrippen verificatie en validatie gezien moeten worden binnen Rijkswaterstaat. Ook worden de basisprincipes behandeld waarop een verificatie en/of validatie proces gestalte krijgt.

2.2 Wat betekenen “verificatie” en “validatie” (definities)

De begrippen verificatie en validatie worden in diverse kennisdomeinen vaak net iets anders gedefinieerd, waardoor er internationaal gezien zeer veel definities zijn ontwikkeld. Gelukkig vormt de essentie van al deze definities voor Rijkswaterstaat - en uiteraard ook voor ProRail en alle Opdrachtnemers in Nederland – voldoende basis om te komen tot een begrijpelijk en werkbaar kader voor de eigen organisatie(s). De definities1 van verificatie en validatie zijn als volgt: Verificatie: bevestiging door onderzoek en verstrekking van objectief bewijs dat aan

de gespecificeerde eisen is voldaan. Validatie: bevestiging middels objectieve bewijsvoering en daadwerkelijke beleving

en gebruik dat het gerealiseerde product voldoet aan de eisen en behoeften van de klant, in aanvulling op de verificatie.

Als je deze definities nauwkeurig bekijkt zie je dat het koepelbegrippen zijn, omdat ze beide een proces van één of meer activiteiten verwoorden. Inhoudelijke kennis van die activiteiten en de begrippen die daarbij horen is dus een minimale vereiste om met verificatie en validatie in projecten te kunnen werken.

Valkuil: Sta niet te lang stil bij deze definities, want discussie hierover kost onnodig veel kostbare tijd. Het goed kennen van de verificatie- en validatiemethoden heeft meer nut.

Tip: In deze werkwijzebeschrijving staat een overzicht van bewijsvoeringmethoden weergegeven die bij verificatie en validatie in de praktijk kunnen worden toegepast.

1 Afgeleid van Leidraad voor Systems Engineering binnen de GWW-sector


2.3 Begrippenkader voor verificatie en validatie

Hieronder volgt een aantal begrippen, met toelichting, die nodig zijn voor een beter begrip van de verificatie- en validatieprocessen.

Begrip (afkorting) Omschrijving

Afwijking Een ten opzichte van de projectplannen niet overeenkomende handeling die meestal niet voldoet aan de eisen.

Compliance Het voldoen aan de eisen.

Eisenbeheer Het monitoren en sturen op de inhoud en invulling van de eisen die aan het systeem en/of het projectmanagement.

Non-Compliance Het niet voldoen aan de eisen.

Pass/Fail criteria Criteria op basis waarvan de objectieve bewijsvoering kan worden beoordeeld op het wel (pass) of niet (fail) voldoen aan de eisen en/of behoeften.

RCM / VVM Requirements Compliance Matrix of Verificatie en Validatie Matrix. Matrix met daarin een overzicht van eisen bijbehorende de verificatiemethode(n), verificatiecriteria, verificatietijdstippen, uitvoerders van de verificatie en kwalificatie (voldoet wel of niet) voor de verificatie.

RTM Requirements Traceablility Management. Het gestructureerd beheren van de eisenverzameling van een systeem of een project. RTM is een vereiste voor eisenbeheer.

Systeem Een combinatie van samenhangende elementen die zodanig zijn georganiseerd om één of meerdere functies te vervullen.

Tekortkoming Laakbare afwijking van de overeengekomen invulling van de eisen waarop een sanctie rust.

Traceerbaarheid Herleidbaarheid van met name eisen. Meestal via een systeem van eiscodes is na te gaan hoe de eisen ten opzichte van elkaar zijn gerangschikt.

V&V Verificatie en Validatie. Verificatie: bevestiging door onderzoek en verstrekking van objectief bewijs dat aan de gespecificeerde eisen is voldaan. Validatie: bevestiging middels objectieve bewijsvoering en daadwerkelijke beleving en gebruik dat het gerealiseerde product voldoet aan de eisen en behoeften van de klant, in aanvulling op de verificatie.

V&V strategie Wijze waarop omgegaan wordt met V&V in het project. De strategie beantwoordt o.a. de vragen over wie de V&V activiteiten bepaald. Hoe wordt omgegaan met vragen over (schijnbaar) niet-verifieerbare eisen. Wat zijn de rollen- en taken van OG en ON. In hoeverre hebben derden een rol in het V&V proces.

Verificatiemanagementplan Beschrijving van de Planning en Monitoring van V&V activiteiten op procesniveau. Omvat onder andere het beheer van de verificatierapporten- en plannen, beheer van de V&V procedures, traceerbaarheid en nummering van de eisen, het beheer van bewijsdocumentatie, en de reguliere overlegmomenten tussen de betrokken partijen.

Verificatieplan (zoals gedefinieerd in Vraagspecificatie Procesdeel 22. 22 sept 2009) Document dat is opgesteld per object met daarin:

- Omschrijving eis (met eisnummer); - Verwijzing naar afgeleide onderliggende eisen; - Van toepassing zijnde uitgangspunten uit bindende, informatieve en

overige documenten; - Beschrijving van de toe te passen verificatiemethode.

Voor elke verificatiemethode dient de geldigheid te worden vastgesteld, tenzij:

- Een gestandaardiseerde verificatiemethode wordt toegepast die door


Begrip (afkorting) Omschrijving

de Opdrachtgever wordt erkend of - Een binnen de Overeenkomst van toepassing verklaard document

wordt toegepast of - Een verificatiemethode zich in de praktijk heeft bewezen en de

referentie door de Opdrachtgever wordt aanvaard. Bij elke eis uit de specificatie wordt, indien relevant, aangegeven

- Wanneer wordt aangetoond dat is voldaan aan de eis; - Wie verificatie uitvoert; - Validatie van de verificatie methode.

Verificatierapport In het verificatierapport dient tenminste het volgende te zijn vastgelegd: - Eis (met eisnummer); - Van toepassing zijnde bindende, informatieve en overige

documenten; - Bewijsdocument of verwijzing naar bewijsdocument, waarin is

aangetoond dat wordt voldaan aan de gestelde eis; - Hoe de eisen zijn geverifieerd en wat de beoordelingscriteria zijn; - Dat is aangetoond dat is voldaan aan de eisen; - Hoe met relevante risico’s is omgegaan; - Welke functionaris verificaties heeft uitgevoerd; - Welke functionaris de verificatie heeft beoordeeld en geautoriseerd; - Eventuele maatregelen ter correctie; - Herziene verificatie (inclusief tijdstip, beoordeling en autorisatie).

De validatie van de verificatiemethode dient te worden uitgewerkt in het verificatierapport. In het rapport dient voor een verificatiemethode ten minste het volgende te zijn geïdentificeerd en vastgelegd:

- De verificatiemethode; - Bewijsdocument of verwijzing naar bewijsdocument, waarin de

geldigheid van de verificatiemethode is aangetoond.

Validatiemethode

Activiteit waaruit de objectieve bewijsvoering volgt die gebruikt wordt voor de bewijsvoering dat aan de eisen en behoeften van de klant is voldaan.

Verificatiemethode Activiteit waaruit de objectieve bewijsvoering volgt die gebruikt wordt voor de gehele of gedeeltelijke bewijsvoering dat aan de eisen is voldaan.

Verificatienota De verificatienota is het "spoorboekje" voor het verificatieproces in een project. Een projectteam/aannemer maakt via de nota inzichtelijk hoe de verificatie per eis traceerbaar is in de geproduceerde/overhandigde documenten. Een verificatienota bevat de chronologische lijst met projecteisen die zijn voorzien van verwijzingen bewijsdocumentatie. Een nota is een groeidocument dat tussentijds, of per project fase (ontwerp, uitvoering), contractueel opgevraagd zou kunnen worden. Hierop kan ook in audits worden behandeld.

Waiver Het wegwuiven van een non-compliance. In dit geval wordt een beoordeling gemaakt dat er niet aan de eisen hoeft te worden voldaan.


2.4 Basisprincipe voor het kunnen verifiëren en valideren

2.4.1 Basisprincipes

Verifiëren en valideren is mogelijk als aan bepaalde minimale voorwaarden wordt voldaan. Dit zijn:

A. Er is een bewijsvoeringmethode nodig om objectief bewijsmateriaal te verzamelen waarmee kan worden aangetoond dat aan de eisen of behoeften wordt voldaan. Deze methoden noemt men ook wel verificatie- en/of validatiemethoden (zie hoofdstuk 3 voor meer informatie over de bewijsvoeringmethoden);

B. Er is minimaal één waarde of criterium2 nodig waartegen het bewijs kan worden

vergeleken;

C. Er moet iemand zijn die mag (contractueel gezien) en kan (vanuit zijn/haar competentie) beoordelen en vaststellen dat het bewijsmateriaal voldoet aan de criteria;

Voor verificatie en validatie gelden dus altijd de volgende stappen.

Verificatie en Validatie = Bewijsvoeringmethode + Criterium + Beoordelaar

2.4.2 Aanvullende voorwaarden

Wanneer de beheersbaarheid van het project dit vereist kunnen de voorwaarden A, B en C uit paragraaf 2.4 worden uitgebreid met aanvullende voorwaarden, zoals:

D. Aanvullende activiteiten, criteria en beoordelaars die nodig zijn voor voldoende objectieve bewijsvoering. Denk hierbij aan het verifiëren in verschillende opeenvolgende fasen of zelfs meerdere verificaties in één projectfase.

E. Het tijdstip waarop de verificatie/validatie plaats moet vinden;

F. De startvoorwaarde om te kunnen beginnen met verifiëren/valideren.

Bijvoorbeeld als een andermans projecttaak gereed moet zijn voordat de verificatie van jouw projecttaak kan starten.

G. De geldigheid van de gehanteerde verificatie- of validatiemethode. Wanneer de

ON een bewijsvoeringmethode voorstelt die nieuw of (nog) onbekend is bij OG.

H. De risico’s die er zijn als het criterium niet wordt behaald. Bijvoorbeeld wanneer vooraf nog niet duidelijk kan zijn of een op theoretische basis gevraagde

2 Ook wel Pass-/Fail Criteria genoemd


systeemprestatie in de praktijk wel haalbaar is, kan het van belang zijn specifieke beheermaatregelen voor sommige eisen te definiëren;

2.5 Wat je verder nog moet weten…

2.5.1 Wanneer krijg je met V&V te maken? (Vraagspecificatie Procesdeel)

In het merendeel van de gevallen komt een projectteam in aanraking met Verificatie via Vraagspecificatie Procesdeel. In Vraagspecificatie Procesdeel wordt wel Validatierapport genoemd, maar er staan3 verder geen eisen aan het Validatieproces. Vraagspecificatie Procesdeel stelt in het hoofdstuk Technisch Management eisen aan de inhoud van verificatieplannen, -rapporten en –nota’s. De eisen betreffen producteisen, ofwel eisen aan inhoudelijke punten, waar de documenten minimaal aan moeten voldoen. In Bijlage 1 zijn twee hoofdstukken overgenomen uit Vraagspecificatie Procesdeel waarin deze producteisen zijn weergegeven.

Let op: Aan de producteisen uit Vraagspecificatie Procesdeel zijn geen criteria verbonden. Dit maakt het beoordelen van de ontvangen documenten van de Opdrachtnemer in bepaalde gevallen een subjectief van aard.

2.5.2 Wat zijn de aandachtspunten? (Benoem een V&V manager)

Vraagspecificatie Procesdeel bevat geen toelichting op de producteisen aan Verificatie (zie Bijlage 1). Hierdoor zijn deze paragrafen in de praktijk niet voor iedereen makkelijk interpreteerbaar. Houdt hier rekening mee.

Tip: Aangeraden wordt om één of meerdere projectteamleden als aanspreekpunt aan te stellen voor deze discipline; een V&V manager.

2.5.3 Omgang met V&V in de klanteisen-, basis-, systeem- en vraagspecificatie

In deze paragraaf staat beschreven hoe V&V in de Klanteisenspecificaties, Basisspecificaties, Systeemspecificaties en Vraagspecificaties moet worden gehandeld en er is ook aangegeven waarom dat zo is. Klanteisenspecificaties Klanteisen hebben het kenmerk dat ze ook niet meetbaar geformuleerd kunnen worden. Ze zijn dan geschreven in “emotietaal” in plaats van “prestatietaal”, zoals dit het geval is bij de eisen in de andere hierna te noemen specificatietypen. Dit heeft tot gevolg dat er

3 Anno 28 juli 2009


eisen in de Klanteisenspecificatie staan waarvoor het zeer lastig is gepaste verificatie- en/of validatiemethoden te beschrijven. Voor die eisen is het nodig om met de belanghebbenden (degenen die de klanteisen stellen) een validatiestrategie af te stemmen. Dit omvat de organisatie en aanpak van het, in een latere projectfase/-stadium, vaststellen van de verificatiemethoden. Het is dus mogelijk dat een eerste versie van een Klanteisenspecificatie dus niets beschrijft over de wijze van V&V, maar dat een latere versie hier wel op ingaat. Basisspecificaties In het veld “Verificatiemethode” in de eisentabel staan voorwaarden met betrekking tot verificatie van de betreffende eis. Dit kunnen activiteiten, toetscriteria, functionarissen, toetsfrequentie e.d. zijn. In een basisspecificatie moet het veld “verificatiemethode” zo volledig mogelijk ingevuld worden door de basisspecificatiebeheerder (of de opsteller ervan). De eisen en verificatiemethodes in een basisspecificatie dienen ten slotte als standaard teksten die een specificeerder moeten helpen bij het opstellen van systeemspecificaties. Aangezien de eisen in een basisspecificatie niet project/locatie specifiek zijn, zal de bijbehorende verificatiemethode niet altijd volledig kunnen zijn. Systeemspecificaties De verificatiemethodes in systeemspecificaties, deze zijn wél projectspecifiek, moeten volledig zijn, omdat deze de gehele projectscope omvatten. Tot het opstellen van een systeemspecificatie is overigens er nog geen sprake van een duidelijke werkverdeling tussen Opdrachtgever en Opdrachtnemer, maar is er wel kennis opgedaan om de verificatiemethoden te kunnen bepalen. Vraagspecificaties In de meeste praktijkgevallen worden niet alle voorwaarden m.b.t. verificatiemethodes uit de systeemspecificaties uiteindelijk opgenomen worden in de Vraagspecificatie. Dit komt enerzijds, omdat we als opdrachtgever zelf maar een deel van de verificaties uitvoeren en anderzijds omdat wij de Opdrachtnemer ook zo veel mogelijk willen vrijlaten in de keuze van zijn V&V werkzaamheden. Hierbij ontstaan dus een dilemma, waarbij er drie opties voor opstellers van Vraagspecificaties Eisendeel zijn. Deze opties zijn

1. Rijkswaterstaat kiest ervoor om zelf in de Vraagspecificatie Eisendeel (VSE) geen voorwaarden te stellen aan de V&V activiteiten, maar OG eist van de ON dat hij bij zijn aanbieding een volledige beschrijving van de V&V activiteiten geeft voor alle eisen uit VSE;

2. Rijkswaterstaat stelt in VSE slechts deels voorwaarden aan V&V en eist

dat de ON bij zijn aanbieding de beschrijving van de V&V activiteiten aanvult/voltooid voor alle eisen uit VSE. De opsteller aan OG-zijde dienen hier zich te focussen op uitsluitend de (uit het risicodossier gefilterde) meest risicovolle eisen.


3. Rijkswaterstaat neemt in VSE een volledige beschrijving van alle

vereiste V&V activiteiten op en ON mag aanvullende V&V activiteiten voor zichzelf definiëren waarop Rijkswaterstaat geen toetsing uitvoert;

In de praktijk komt bij het opstellen van een Vraagspecificatie optie 2 het meest voor. Een consequentie is dat in de aanbestedingsprocedures hier rekening me moet worden gehouden. Gebeurt dit niet, en is Rijkswaterstaat het niet eens met V&V methoden die ON later in het project kiest, omdat we iets anders voor ogen hadden, kunnen wij hiervoor geen afwijking op het contract aangeven (SCB) omdat we hem die vrijheid hebben gegeven. Let op: het kan voorkomen in de praktijk dat er wordt afgeweken van een verificatiemethode die deels of volledig wordt voorgeschreven aan de Opdrachtnemer. De Opdrachtnemer kiest er wellicht voor om een methode te hanteren die beter aansluit bij zijn werkwijze of ontwerp. In dit geval dienen Opdrachtnemer en Opdrachtgever duidelijke voorwaarden af te spreken hoe men hiermee omgaat. Deze afspraken omvatten dus ook contractwijzigingen (waaronder de Vraagspecificatie) met daarin duidelijke afspraken te maken over wie welke verplichtingen heeft m.b.t. de verificatie aan eisen. De wijze waarop deze aanpassingen verlopen dient de Opdrachtnemer in zijn Projectmanagementplan (of Verificatiemanagementplan) expliciet opgenomen zijn.


3 Overzicht van bewijsvoeringmethoden voor V&V De bewijsvoeringmethoden, of verificatie- en validatiemethoden, die door de levenscyclus worden toegepast zijn in dit hoofdstuk beschreven. Om de diverse methoden beter te kunnen scheiden in projectteams zijn ze op levenscyclusfase gesorteerd, namelijk verkenning, planstudie, inkoop, ontwerp, realisatie, oplevering, beheer & onderhoud en sloop.

3.1 Verificatiemethoden

3.1.1 ONTWIKKELINGSFASE (Verkenning, Planstudie, Ontwerp)

3.1.1.1 Analyse

Het gebruik van analytische gegevens of simulaties onder voorgedefinieerde omstandigheden om aan te tonen dat aan de eisen wordt voldaan. Deze methode wordt gebruikt als het testen onder praktijkomstandigheden niet haalbaar of niet kosteneffectief is.

Analyse wordt gebruikt om een item of onderwerp nader te onderzoeken. De analyse gaat over berekeningen, studies, evaluaties en beoordelingen4.

De volgende analyse technieken kunnen, indien nodig, hierbij toegepast worden:

- Foutenboom analyse (Fault Tree Analysis (FTA));

- Faal modus effect analyse (failure mode effect analysis ((FMEA));

- Sterkte analyse;

- Betrouwbaarheidsanalyse;

- Onderhoudbaarheid analyse;

- Veiligheidsanalyse.

- Maatschappelijke Kosten-Baten Analyses (MKBA)

De resultaten van de analyses zullen worden gedocumenteerd en geregistreerd zodat deze als bewijsmateriaal voor de verificatie kunnen dienen.

3.1.1.2 Audit

Binnen projecten worden, vaak als onderdeel van het kwaliteitsmanagement systeem, een programma voor het uitvoeren van audits op de interne processen ontwikkeld en geïmplementeerd. Audits zijn nodig om te verifiëren of de werkzaamheden volgens de

4 Soms ook assessments genoemd


ontwerpen, plannen, procedures, normen en standaarden worden uitgevoerd. Het audit programma verloopt door de gehele projectlevenscyclus.

De audits dienen periodiek te worden afgenomen door gekwalificeerde auditoren waarbij objectiviteit en onpartijdigheid gegarandeerd wordt. Auditoren mogen beslist niet hun eigen werk auditeren. De bevindingen, conclusies en de eventuele aanbevelingen worden in een audit rapport verwerkt.

Omdat audit een onderdeel is van het proces V&V zal de audit procedure onder het Kwaliteitsmanagement (of Quallity Assurance) vallen en van waaruit ook het Audit Team wordt opgezet.

3.1.1.3 Berekening

Cijfermatige onderbouwing van de werking of van de eigenschappen van systemen of van processen door specialisten.

3.1.1.4 Demonstratie

Een kwalitatieve voorstelling van de functionele prestatie van een systeem of een onderdeel van het systeem.

3.1.1.5 Documentinspecties

Elk document dat wordt geproduceerd in een project dient beoordeeld te worden. In projecten ziet men voor deze activiteit verschillende benamingen terug, waaronder review, documentinspectie en toets. De juiste noemer waaronder deze activiteiten behoren te vallen is documentinspectie, omdat het hier gaat om een gestructureerde (specifieke, globale, risicogestuurde) controle van de documentatie door specialisten aan de hand van impliciete kennis of vastgestelde criteria.

Over het algemeen worden bij de documentinspecties de volgende aspecten beoordeeld:

A. Compleetheid

- Zijn de punten in het document compleet? Is er niets vergeten?

- Zijn er geen aspecten over het hoofd gezien?

B. Consistentie/Consequentie

- Zijn er geen subjectieve of dubbelzinnige concepten gebruikt? Zijn er alleen meetbare definities gegeven?

- Bevat het ontwerp geen contradicties?(intern of extern)

- Bevat het ontwerp geen tegenstrijdigheden?(intern of extern)

C. Correctheid


- Zijn berekeningen, analyses, simulaties enz. correct en gebaseerd op de correcte data

van informatie?

- Zijn keuzes gebaseerd op juiste rechtvaardigheid?

D. Overeenstemming met de eisen (Compliance)

- Zijn de resultaten van detaillering van het beginpunt nog steeds in overeenstemming met het beginpunt?

- Blijft het ontwerp binnen de scope van de contractuele eisen?

3.1.1.6 Document beoordeling

Een specifieke, globale of risicogestuurde controle van de documentatie door specialisten meestal op gevoel en daarmee aan de hand van impliciete criteria van deze specialisten.

3.1.1.7 Review

Een (ontwerp-)review wordt gedefinieerd als een verificatie op elk product dat gerelateerd is aan de output van het (ontwerp)proces om zo overeenstemming van het (ontwerp)document met de eisen te verkrijgen.

Van (ontwerp)documentatie dat een review ondergaat wordt gecontroleerd of deze bestaat uit:

- de technische documentatie die gerelateerd is aan productontwikkeling en de laatst vastgestelde systeemconfiguratie en of de documentatie in overeenstemming is met de eisen;

- alle uit het (ontwerp)document volgende technische documentatie die nodig is voor de inkoop van materialen, de productie, de inspecties en tests, de bouw of installatie, het in bedrijf stellen en het onderhoud van het systeem;

- beschrijvende documentatie noodzakelijk voor het kunnen bedienen van het systeem en het uitvoeren van onderhoud eraan.

3.1.1.8 Toets

Een specifieke (globaal, risicogestuurde of steekproefsgewijze) controle van de documentatie door specialisten aan de hand van een set vastgestelde criteria.

3.1.1.9 Modellering

Nabootsing via een afspiegeling van de werkelijkheid in een fysiek of softwarematig model dat is opgezet door specialisten.


3.1.1.10 Referentie

Verwijzing naar eerdere projecten of gerealiseerde systemen door ervaringsdeskundigen/specialisten.

3.1.1.11 Simulatie

Simulatie kan worden gebruikt om aan te tonen dat de prestatie van het systeem of subsysteem voldoet aan de gestelde eisen. Ook in de gevallen waarbij de simulaties real-time worden uitgevoerd zullen de resultaten moeten worden gedocumenteerd en geregistreerd zodat deze als bewijsmateriaal voor de verificatie kunnen dienen.

(Simulatie ijsvorming op staalkabel)

3.1.1.12 Vergelijking

Het proces van demonstratie door middel van het herleiden vanuit brondocumentatie dat eerder ontwikkelde en geverifieerde ontwerpen/systemen(-onderdelen) in overeenstemming is met dezelfde eisen waardoor de noodzaak tot her-verificatie verdwijnt.

3.1.2 REALISATIEFASE (Bouw, Oplevering)

3.1.2.1 Demonstratie

Een kwalitatieve voorstelling van functionele prestatie. Demonstraties leveren een indruk op van de werking/eigenschappen van het systeem en staan als het ware “onder aan de ladder” van bewijsvoeringmethoden. Het bewijs dat uit demonstraties volgt is namelijk beperkt.

3.1.2.2 Inspectie

Zie par. 3.1.3.1

3.1.2.3 Keuring

Een onderzoek op basis van waarneming met behulp van van toepassing zijnde documentatie en/of instrumentarium

3.1.2.4 Ingangscontrole

Controle door kwaliteitscontroleurs van bouwstoffen en andere producten voordat deze in het werk op de projectlocatie


worden toegepast; als het ware voordat ze het werk ingaan.

3.1.2.5 Uitgangscontrole

Controle door kwaliteitscontroleurs van bouwstoffen en andere producten voordat deze de leverancier/fabriek verlaten en naar de projectlocatie worden getransporteerd; als het ware voordat ze het de fabriek uitgaan.

3.1.2.6 Meting

Controle van de systemen wel/niet met behulp van meetapparatuur op (wel/niet vooraf vastgestelde) punten van het systeem en waaruit een kwantitatieve (getalsmatige) waardering volgt.

3.1.2.7 Certificering

Bij certificering vindt verificatie door een onafhankelijke en terzake deskundige 3de partij plaats via een voorgeschreven procedure. Deze (gekwalificeerde) 3de partij kan zowel de processen als producten laten evalueren. Voor de certificering zal volgens specifieke standaarden een certificerende partij worden gekozen, in lijn met de norm gestelde voorwaarden.

3.1.2.8 Test

Methodische aanpak, door middel van het uitvoeren van testprotocollen, om het juist functioneren van een systeem(onderdelen) aan te tonen.

3.1.2.8.1 Factory Acceptance test (FAT)

De Factory Acceptance Test (FAT) wordt gedefinieerd als de keuring of testuitvoering op relevante subsystemen, of componenten daarvan, voordat ze worden afgeleverd op locatie voor installatie. Aan de hand van vooraf vastgestelde procedures kan d.m.v. een FAT worden aangetoond of het betreffende subsysteem of component aan de gestelde eisen voldoet.

Bij het houden van een FAT dient een testopstelling van het systeem te worden opgezet en die volgens de opgestelde FAT protocollen wordt afgewerkt. In sommige gevallen is met mogelijk om mankementen en fouten in het systeem op te sporen voordat het systeem op locatie (‘on site’) in bedrijf gesteld wordt.


Bij een FAT kan gekozen worden om naast de subsystemen ook het geïntegreerde systeem te testen, echter dit kan normaal gesproken alleen in combinatie met een simulatie.

Een FAT kan samengaan met een bezoek van de klant aan de fabriek/productielijn voor een simulatie/demonstratie van productie en bijbehorende acceptatie van het kwaliteitssysteem voordat het product wordt geïnstalleerd op locatie.

De Factory Acceptance Test (FAT) wordt ook wel de Fabrieksafname Test genoemd.

3.1.2.8.2 Factory integration test (FIT)

Kwalitatieve of kwantitatieve test in fabriek of op de productielijn waarbij modulair geleverde deelsystemen worden getest op de werking voordat ze getransporteerd worden naar project locatie.

Software integratie test in cabine

3.1.2.8.3 Haalbaarheidstest

Een haalbaarheidstest, ook wel eens proof of concept genoemd, geldt voor nieuwe systemen.

Hierbij worden de systemen op de volgende manieren te testen via:

- Acceptatietesten: ter bepaling of afname door Opdrachtgever kan plaats vinden;

- Kwaliteitstesten: door ze te plaatsen in gebruiksomstandigheden;

- Operationele testen: ter bepaling of wordt voldaan aan de eisen bij gebruik;

3.1.2.8.4 Kwaliteitstest

Testen d.m.v. het plaatsen van het systeem(onderdeel) in gebruiksomstandigheden.

3.1.2.8.5 Operationele test

Testen d.m.v. het gebruiken van het systeem(onderdeel) in volledige dan wel gedeeltelijke openstelling.


3.1.3 GEBRUIKSFASE (Beheer, Instandhouding)

3.1.3.1 Inspectie

Bij inspecties worden, eenmalig of op intervalbasis, controles/metingen/tests uitgevoerd of wordt toezicht gehouden. Inspecties vinden zowel in de realisatiefase als in de gebruiken instandhoudingsfase.

Inspecties kunnen worden onderverdeeld in Inspecties vóór installatie, Inspecties tijdens installatie en Inspecties na installatie. Inspecties vóór installatie betreffen de controles van de subsystemen en/of componenten vlak vóór en vlak na de aflevering op site (toetstandsinspecties). Hierdoor kan bijv. de schade (bij productie en/of transport), verkeerde kleur, verkeerde afmeting vroegtijdig worden vastgesteld. De inspecties tijdens installatie gaan om het periodiek houden van toezicht gedurende het installatietraject, zodat bij eventuele afwijkingen de installatiewerkzaamheden bijgestuurd en vroegtijdig gecorrigeerd kunnen worden. Bij de Inspecties na installaties betreffen de controles op correcte en volledige installaties op de locaties (instandhoudinginspecties).

Volgens “Het Inspectiehuis” van afdeling Inspectie en Instandhouding (I&I) zijn er drie soorten inspecties te onderscheiden:

1. schouw 2. toestandsinspectie 3. instandhoudinginspectie

Ad. 1 Schouw: Visuele controle van (wel/niet op vooraf vastgestelde) punten van het systeem en waaruit een kwalitatieve (beschrijvende) waardering van de schouwer volgt.

Twee hierop aanvullende soorten van inspecteren zijn:

Nulinspectie: momentopname/registratie van de eigenschappen van het systeem respectievelijk vóór aanvang van het project.

Eindinspectie: Opname van de as-built situatie van het systeem respectievelijk vlak voordat systeemoverdracht plaats vindt.

3.1.3.2 Meting

Controle van de systemen wel/niet met behulp van meetapparatuur op (wel/niet vooraf vastgestelde) punten van het systeem en waaruit een kwantitatieve (getalsmatige) waardering volgt.

Bekende metingen vanuit de civiele techniek is de conditiemeting. Deze, ookwel referentiemetingen genoemd, zijn kwalitatief van aard.


Denk hierbij aan bijvoorbeeld de stroefheidmetingen van het asfalt, pompdrukmetingen, meting van de lichtweerkaatsing van de wegmarkeringen, stroomverbruikmetingen, trillingsmetingen.

3.1.3.3 Monitoring

Continue in de tijd lopende controle van de systemen wel/niet met behulp van meetapparatuur op (wel/niet vooraf vastgestelde) punten van het systeem en waaruit een kwantitatieve (getalsmatige) of kwalitatieve (beschrijvende) waardering van de beheerder volgt.

Denk hierbij aan het monitoren van de draaiuren van pompen (zodat optimale vervanging mogelijk is), snelheidsmetingen op tunnelventilatoren en monitoring van verlichting in tunnels.

Alle monitoringsactiviteiten zijn voor Rijkswaterstaat van groot belang omdat deze invulling geven aan het principe van “merkbaar” falen. Het is namelijk van belang dat enerzijds de betrouwbaarheid van het systeem wordt vergroot door de monitoring. Anderzijds verbetert het bij wegen de mobiliteit omdat er geen wegafzettingen nodig zijn voor inspecties. Dit vergroot ook de veiligheid van weggebruikers en wegwerkers.


3.2 Validatiemethoden

3.2.1 ONTWIKKELINGSFASE (Verkenning, Planstudie, Ontwerp)

3.2.1.1 Eisen Validatie

Beoordeling of eisen een systeem beschrijven dat de behoefte vervult. Beoordeling dat de eisen een maakbaar systeem beschrijven.

3.2.1.2 Model Validatie

Model Validatie is een methode om de kwaliteit van de modellen vast te stellen die in de ontwerpfase zijn gebruikt om de prestaties van het systeem na te bootsen en daarmee aan te tonen dat het systeem aan de criteria zal voldoen.

Modellen die o.a. geluidscontouren nabootsen kunnen door middel van praktijkmetingen worden gevalideerd. Modellen voor drukgolven bij vrachtvervoerpassages kunnen ook middels praktijkmetingen worden gevalideerd.

3.2.1.3 Ontwerp Validatie

Het gemaakte ontwerp dient naast de verificatie ook gevalideerd te worden. Bij ontwerp validatie gaat het om het aantonen dat het ontwerp voor de essentiële eisen overeenkomt met de behoefte van de belanghebbenden. Daarbij moeten de volgende aspecten in acht worden genomen:

• Komt het ontwerp overeen met de beoogde behoefte?

• Zijn de uitgangspunten voor het ontwerp geldig?

• Is de toegepaste ontwerpmethode geschikt voor zijn toepassing?

Hierbij gaat het om de beoordeling dat het ontwerp een operationeel systeem beschrijft dat de gebruikersbehoefte vervult. Beoordeling dat het ontwerp een maakbaar en operationeel systeem beschrijft dat de gebruikersbehoefte vervult.


3.2.1.4 Prototype

Prototypering is een gebruikelijke methode om vast te stellen dat de interpretatie van de ontwerper het beoogde systeem van de gebruiker/klant realiseert. Daarnaast heeft de prototypering ook tot doel om nieuwe, onverhoopt nog niet gestelde, eisen te genereren bij de klant/gebruiker/ontwerper.

Het voordeel van prototypes is dat het relatief eenvoudig is om de interpretatie (en aannames) van de eisen door de ontwerper te volgen en hierop feedback te geven.

Het nadeel van een prototype is dat de klant/gebruikers afgeleid kunnen worden van de onderliggende functionaliteit door het visuele/virtuele/cosmetische indrukken en door simplificatie van kwaliteitskenmerken die in de praktijk van belang zijn.

Prototypes zijn meestal duur in de ontwikkeling, daarentegen zijn ze in staat om snel foute eisen op te sporen die anders onnodige hoge kosten zouden genereren.

3.2.1.5 Trade-off analysis

Trade-off analysis is een systematische aanpak om alternatieven te wegen in tijd, kosten en prestatie. Waarschijnlijk de belangrijkste waarde van de trade-off is dat het voorkeursalternatief wordt vastgesteld en waardoor de projectteamleden er zeker van zijn dat de klanten/gebruikers/belanghebbenden van het systeem dit kunnen nagaan en deze keuze accepteren.

3.2.2 REALISATIEFASE (Bouw, Oplevering)

3.2.2.1 Site acceptance test (SAT)

Stapsgewijze controle van het gehele systeem op functionaliteit, beveiliging en veiligheid in aanwezigheid van de klant / toekomstige beheerders.

Tijdens de Site Acceptance Test vindt de feitelijke oplevering aan de opdrachtgever plaats. Op site worden de testen, die tijdens de FAT gedaan zijn, uitgevoerd. Door middel van een SAT wordt aan de opdrachtgever aangetoond dat het systeem volgens de gestelde eisen functioneert.


Indien de operationele omgeving nog niet volledig is, kan er bij een vervroegde oplevering worden gekozen voor het inplannen van een Voorlopige Site Acceptatie Test (vSAT).

3.2.2.2 Site integration test (SIT)

Middels een Site Integration Test (SIT) wordt, op site, aangetoond dat een aantal samenhangende systeemdelen op een correcte wijze en zonder onbedoelde interferenties met elkaar functioneren.

Stapsgewijze controle van het deelsystemen op integrale werking, deelfunctionaliteit, beveiliging en veiligheid in aanwezigheid van de specialisten

Voor ieder op te leveren systeemdeel (c.q. een cluster van samenhangende systeemdelen) wordt een apart site integratie protocol gemaakt. De resultaten van de SITs worden per SIT plan vastgelegd in een validatierapport.

3.2.3 GEBRUIKSFASE (Beheer, Instandhouding)

3.2.3.1 Modelvalidatie

Model Validatie is een methode om de kwaliteit van de modellen vast te stellen die in de ontwerpfase zijn gebruikt om de prestaties van het systeem na te bootsen en daarmee aan te tonen dat het systeem aan de criteria zal voldoen.

Modellen die o.a. geluidscontouren nabootsen kunnen door middel van praktijkmetingen worden gevalideerd. Modellen voor drukgolven bij vrachtvervoerpassages kunnen ook middels praktijkmetingen worden gevalideerd.

3.2.3.2 Normering

Normering ontstaat wanneer gedurende de levenscyclus prestatiemetingen door de gebruikers en beheerders leiden tot richtlijnen/voorschrift hoe het systeem zich dient te gedragen. Het zijn de `regels` voor algemeen aanvaard functioneren van het systeem.

ALARA (as low as reasonably achievable) of ALARP (as low as reasonably possible) zijn hiervoor internationaal bekende begrippen die in het kader van veiligheid als maatstaf voor de veiligheidsrisico’s wordt gehanteerd. Denk hierbij aan de onderlinge


afstand tussen vluchtdeuren in tunnels. Wat bepaalt hiervoor de juiste afstand? Wat is juist: 100 meter, 200 meter?

3.2.3.3 Praktijktesten

3.2.3.3.1 Calamiteitenoefening

Calamiteitenoefeningen zijn een belangrijk element in de voorbereiding op zware indicenten of rampen, zoals een tunnelbrand, een groot ongeval of een terroristische aanslag. Een infrastructureel beheerder houdt binnen de termijn van een vooraf vastgestelde periode (meestal in jaren uitgedrukt) een dergelijk grote oefening.

Zoals voor elke oefening worden specifieke doelen vastgesteld. Deze doelen zijn onder meer de opvang van familie van slachtoffers, communicatie en gebruikmaking van elkaars kennis en kunde. De oefeningen worden altijd afgesloten met een evaluatie, die zal leiden tot een beter voorbereide crisisorganisatie van alle betrokken hulporganisaties en beheerders.

3.2.3.3.2 Proefbedrijf

Een test in realistische gebruiks- of bedrijfsomstandigheden waaruit de acceptatie van de klant/gebruiker en/of de prestatie van het systeem volgt.

3.2.3.4 Gebruikers tevredenheid onderzoek

Vaststelling, door onderzoek naar ervaring van de gebruikers van het systeem, dat het systeem voldoet aan de beoogde behoeften.

3.3 Uitzonderingen

3.3.1.1 Niet geaccepteerde verificatiemethoden

Er zijn ook veel voorkomende verificatiemethoden die niet worden geaccepteerd, omdat deze in de praktijk tot problemen leiden. De meest bekende methoden zijn hier weergegeven.

3.3.1.2 Onderliggende eisen

De verificatie van een eis waarbij de “methode” onderliggende eisen benoemd is wordt als volgt beschouwd: wanneer alle eisen op de lagere niveaus van de eis zijn geverifieerd dan is ook meteen aan deze eis voldaan.


Voor de verificatie van deze eis geldt echter dat:

- er vindt in feite een “review“ van de verificaties op de eisen op de onderliggende niveaus plaats, met als criterium dat deze eisen aantoonbaar geverifieerd zijn,

- door alleen deze review te houden gaat men voorbij aan eventuele integratievraagstukken die bij het samenbrengen van de eisen vanuit de onderliggende niveaus speelt.

3.4 Te beperkte verwijzing naar normen en richtlijnen

Als in het “verificatiemethode”-veld alleen de titel(s) van normen of richtlijnen vermeld worden zonder activiteit. Ook komt voor

dat in de vraagspecificatie alleen een norm of richtlijn als bindend document wordt genoemd en dat het verificatieveld geheel leeg wordt gelaten. Beide zijn niet wenselijk.

Zeker als de opsteller of ontwerper overtuigd is dat een norm of richtlijn van toepassing is op de eisen volstaat het volgende niet:

- Het is niet goed om de norm of richtlijn alleen op te nemen in de lijst van bindende documenten

- Het is niet goed om de norm alleen te vermelden in het verificatieveld bij de eis

De opsteller van de eis zal in het verificatieveld van de eis een verwijzing naar de norm of richtlijn moeten combineren met een vermelding van de specifieke paragraafnummers die op de eis van toepassing zijn.

Validatie van verificatie- en validatieprocedures

Nieuwe, onbekende of niet eerder benoemde verificatie- en validatiemethoden kunnen een geldigheid krijgen als deze door beide partijen (Opdrachtgever en Opdrachtnemer) worden gevalideerd. Deze validatie is geldig in alle projectfasen, maar wordt niet direct als een primaire validatiemethode getypeerd.

Het principe geldt dat alle in het project toegepaste verificatie- en validatiemethoden aangetoond geldig zijn. De argumentatie hierbij verloopt als volgt:

- De in het contract gedefinieerde methoden zijn geldig


- Methoden voor bewijsvoeringmethoden die voortkomen vanuit normen en

richtlijnen mogen als geldig worden beschouwd

- Methoden die voortkomen uit het kwaliteitssysteem van de Opdrachtnemer moeten worden geaccepteerd door de Opdrachtgever.

- Methoden die bekend zijn binnen de sector, bekend uit algemeen gebruik, dienen geaccepteerd te worden door de Opdrachtgever.


4 Het vaststellen van V&V criteria

Zonder criteria waartegen geverifieerd of gevalideerd kan worden mist de objectieve bewijsvoering haar slagkracht. Het is belangrijk de juiste criteria te kiezen om de verificatie en validatie praktisch en doeltreffend te maken. Alvorens in te gaan op de keuze van het criteria zal de opsteller van de eisen aan de verificatie een keuze maken uit het type criteria dat geldig is voor de eis. Gekozen kan worden uit de volgende typen criteria:

- Absolute criteria: dit zijn o.a. getalwaarden of absolute uitkomsten die behaald moeten worden

- Normatieve criteria: bindende, uit de norm of richtlijn voorgeschreven criteria

- Referentiële criteria: waarbij de verificatie in vergelijking met andere systemen/eigenschappen dient te verlopen

- Relatieve criteria: dit stelt dat de bewijsvoering in relatie tot andere waarden/bewijsvoering moet worden beschouwd

- Technische/functionele criteria: die de eigenschappen/werking van een systeem beschrijven

Indien de V&V methode gekozen is kan naar passend criteria worden gezocht. Omgekeerd kan dit overigens ook. Hier volgen twee voorbeelden:

Voorbeeld 1: bij een bekende V&V methode een passend criterium bepalen Stel de gekozen V&V Methode is “Berekening” dan heeft de opsteller van de verificatiebeschrijving de mogelijkheid uit: - Absolute criteria: de uitkomst van de berekening dient te voldoen aan een

vooraf opgegeven waarde. - Normatieve criteria: de opzet van de berekening inclusief de uitkomst dienen te

voldoen aan respectievelijk de eisen die de norm hieraan stelt en de waarde die behaald dient te worden

- Relatieve criteria: de uitkomst van de berekening dient aan te tonen dat een hogere/lagere of maximale/minimale waarde wordt behaald ten opzichte van een andere berekening/situatie

Voorbeeld 2: bij een bekende criterium een passende V&V methode bepalen Stel het is bekend dat een ontwerp van een tunnel dient te voldoen aan de Veiligheidsrichtlijnen. De opsteller van de verificatiebeschrijving heeft dan de mogelijkheid uit de volgende V&V methode: - Documentinspectie: waarbij de ontwerpen door specialisten op vastgestelde

punten worden nagelopen op overeenstemming met de Veiligheidsrichtlijnen.


Het slim kiezen van het type criteria heeft nog meer voordelen. Zo heeft bijvoorbeeld het stellen van normatieve criteria in D&C en DBFM contracten veel zin omdat deze toekomstvaster zijn dan absolute criteria. Alle normen/richtlijnen krijgen vroeger of later een update ten gevolge van veranderend gebruik (denk aan verkeersbelasting van kunstwerken) of door het verkrijgen van nieuwe inzichten in het gedrag van de systemen of de gebruikers. Het stellen van normatieve criteria in D&C of DBFM leidt ertoe dat de beheerder bij wijzigingen in de norm steeds opnieuw dient te verifiëren of het systeem nog steeds voldoet. Indien het systeem na wijziging in de norm niet voldoet dan is het de plicht van de beheerder om het systeem aan te passen zodat het weer voldoet aan de meest recente eisen uit de norm. Als er in de verificatiebeschrijving een absolute waarde had gestaan dan was dit niet het geval.


5 Beoordeling van V&V documentatie Het kiezen van de juiste beoordelaar is laatste van de drie principes waaraan de verificatiebeschrijving dient te voldoen.

Enerzijds zijn er verschillende soorten beoordelaars anderzijds hebben zij verschillende competenties.

De soorten zijn:

- Opdrachtgevers en financiers; - Opdrachtnemer, onderaannemers, leveranciers; - Onafhankelijke beoordelingsbureaus; - Belanghebbenden, klanten, gebruikers, bedieners, beheerders; - Overheidsinstanties (wetgevers), waterschappen, overheidshulpdiensten

(brandweer, politie, ambulance); De competenties omvatten:

- voorzien van mandaat: o.a. projectmanager, opdrachtgevers, klant; - inhoudelijke/technische kennis: o.a. ontwerpers en ontwerpleiders,

vakspecialisten en leveranciers; - inlevingsvermogen: o.a. architecten; - inschattingsvermogen: o.a. ramers, calculatoren; - vaardigheid: o.a. piloten (luchtfotografie), duikers

(onderwaterinspecties); In het Vraagspecificatie Eisendeel komen meestal verificatiebeschrijvingen voor waarbij wordt geëist dat de Opdrachtnemer overeenstemming met de eisen dient aan te tonen op basis van zijn technische kennis. Gezien de grote hoeveelheid eisen waarbij dit het geval is kan het nuttig zijn om in de inleiding van de vraagspecificatie op te nemen dat dit het geval is voor alle verificatiebeschrijvingen “tenzij anders staat vermeld”. Let op: Veel topeisen in de Vraagspecificatie volgen direct uit de klantvraag. Deze eisen kunnen niet geverifieerd of gevalideerd worden als de klant bij dit proces niet betrokken is. Een gedelegeerde verantwoordelijkheid (zie hierboven de competentie: “voorzien van mandaat”) vanuit de klant aan Rijkswaterstaat kan hierbij een oplossing bieden. Het niet verifiëren van deze topeisen biedt geen oplossing, want dan kan aan de klant niet worden aangetoond dat aan zijn behoeften en/of eisen is voldaan.


Overige tips verificatieactiviteiten Tip: Om juridische discussies te voorkomen kan je ervoor kiezen bepaalde verificaties in het bijzijn van een (afgevaardigde van de) Opdrachtgever uit (te laten) voeren. Tip: Zorg voor een onafhankelijke partij voor het uitvoeren van validatieactiviteiten als blijkt dat projectteamleden conflicterende belangen hebben. Tip: Elke manier van falen van het systeem tijdens verificatie- en validatieactiviteiten gaat gepaard met faalkosten. Maak vóórdat het contract is getekend expliciet wie verantwoordelijk is voor het nemen van deze kosten: de Opdrachtgever of de Opdrachtnemer. Tip: Voorkom discussies over de gekozen verificatie- en validatiemethodes door de Opdrachtnemer door zelf een goede beschrijving van de gewenste verificatie en/of validatie in het Eisendeel en het Procesdeel van de Vraagspecificatie op te nemen. Tip: Voorkom begripsverwarring over de vele definities door het hanteren van een begrippen en definitielijst. Tip: Mythe: Elke eis verifieer je altijd maar één keer. Dit is niet waar. Het is vaak nodig om een eis meerdere keren in de levenscyclus van een systeem te verifiëren. Je verifieert de eisen in alle levenscyclusfasen waar de activiteiten invloed hebben op de essentiële eigenschappen van het ontwerp, het product en/of de operationele werking van het systeem.


Bijlagen


Bijlage I. Definities Verificatie en Validatie uit literatuur I-1. INCOSE Verificatie: Systeem verificatie adresseert of het systeem, de samenstellende elementen, en de raakvlakken de eisen vervullen. Verificatie stelt het conformeren aan deze eisen zeker, in andere woorden: “je hebt het systeem juist gebouwd.” Validatie: Systeem validatie bevestigd dat het systeem, as-built (of zoals het gebouwd zal worden), de gestelde behoeften van belanghebbenden vervult. Validatie garandeert dat de eisen en de ontwikkeling van het systeem de juiste oplossing biedt voor het probleem van de klant. In andere woorden: “hebben we het juiste gebouwd.”

I-2. Defence Aquisition handbook, Dept. Of Defence, U.S. Validatie The Validation Process answers the question of "Did you build the right thing". As such, it tests the performance of systems within their intended operational environment, with anticipated operators and users. In the early stages of the system life cycle, validation may involve prototypes, simulations, or mock-ups of the system and a model or simulation of the system's intended operational environment.

I-3. NEN-EN ISO 15288:2002 Verificatie: Bevestiging doordat objectief wordt aangetoond dat aan gespecificeerde eisen wordt voldaan. [overgenomen ISO 9000:2000] Validatie: Bevestiging doordat objectief wordt aangetoond dat aan specifieke gebruiks- en toepassingseisen, zoals is beoogd. [ISO 9000:2000]


Bijlage II. V&V Bepalingen uit Vraagspecificatie Procesdeel Deze bijlage bevat tekstueel de delen uit Vraagspecificatie Procesdeel waarin wordt beschreven wat Rijkswaterstaat van Opdrachtnemers eist te leveren voor Verificatie. De delen zijn bedoeld voor de Ontwerpfase en de Uitvoeringsfase. Bron: Vraagspecificatie Procesdeel, Hoofdstuk technisch Management (22 sept. 2009) Paragraaf - Verifiëren (Verifiëren Ontwerpfase) Doel Het aantonen dat wordt voldaan aan de eisen in de Overeenkomst. Werkzaamheden

- Opstellen verificatieplannen; - Verifiëren en in verificatierapporten vastleggen of de ontwerpen van de objecten voldoen aan alle daaraan

gestelde eisen; - Opstellen verificatienota;

Proceseisen De Opdrachtnemer dient verificatieplannen, verificatierapporten en een verificatienota op te stellen. Producteisen Verificatieplan In het verificatieplan dient voor een object per eis tenminste het volgende te zijn vastgelegd:

- Omschrijving eis (met eisnummer); - Verwijzing naar afgeleide onderliggende eisen; - Van toepassing zijnde uitgangspunten uit bindende, informatieve en overige documenten; - Beschrijving van de toe te passen verificatiemethode.

Voor elke verificatiemethode dient de geldigheid te worden vastgesteld, tenzij:

- Een gestandaardiseerde verificatiemethode wordt toegepast die door de Opdrachtgever wordt erkend of - Een binnen de Overeenkomst van toepassing verklaard document wordt toegepast of - Een verificatiemethode zich in de praktijk heeft bewezen en de referentie door de Opdrachtgever wordt

aanvaard. Bij elke eis uit de specificatie wordt, indien relevant, aangegeven

- Wanneer wordt aangetoond dat is voldaan aan de eis; - Wie verificatie uitvoert; - Validatie van de verificatie methode.

Verificatierapport In het verificatierapport dient tenminste het volgende te zijn vastgelegd:

- Eis (met eisnummer); - Van toepassing zijnde bindende, informatieve en overige documenten; - Bewijsdocument of verwijzing naar bewijsdocument, waarin is aangetoond dat wordt voldaan aan de gestelde

eis; - Hoe de eisen zijn geverifieerd en wat de beoordelingscriteria zijn; - Dat is aangetoond dat is voldaan aan de eisen; - Hoe met relevante risico’s is omgegaan; - Welke functionaris verificaties heeft uitgevoerd; - Welke functionaris de verificatie heeft beoordeeld en geautoriseerd; - Eventuele maatregelen ter correctie; - Herziene verificatie (inclusief tijdstip, beoordeling en autorisatie).

De validatie van de verificatiemethode dient te worden uitgewerkt in het verificatierapport. In het rapport dient voor een verificatiemethode ten minste het volgende te zijn geïdentificeerd en vastgelegd:

- De verificatiemethode; - Bewijsdocument of verwijzing naar bewijsdocument, waarin de geldigheid van de verificatiemethode is

aangetoond.


Verificatienota Een verificatienota dient traceerbaar te maken dat in alle fasen wordt voldaan aan de eisen uit de Vraagspecificatie. De verificatienota is een document waarin de relatie wordt vastgelegd tussen de afgeleide eisen, de objecten en de verificaties en keuringen (inclusief testen). In de verificatienota wordt verwezen naar de betreffende bovenliggende eisen en registraties (verificatie- en keuringsrapporten) waaruit blijkt hoe is aangetoond en traceerbaar is dat aan deze eisen wordt voldaan (combinatie van specificatie, verificatieplan, keuringsplan, verificatierapport, keuringsrapport en testrapport). De verificatienota dient de volgende informatie te bevatten:

- Identificatie van de objecten waarop de verificatienota van toepassing is; - Overzicht van de (afgeleide eisen van de) eisen uit Vraagspecificatie deel 1 (nummer en beschrijving van de

eis) die van toepassing zijn op de betreffende objecten; - Per afgeleide eis de traceerbaarheid naar de eisen uit de Vraagspecificatie deel1; - Per eis een verwijzing naar de bijbehorende verificatie- keurings- of testrapporten; - Overzicht van de opgetreden afwijkingen met de genomen corrigerende en preventieve maatregelen voor

zover deze afwijkingen betrekking hebben op de objecten waarop de verificatienota van toepassing is.

Paragraaf - Keuren en Testen (Verifiëren Uitvoeringsfase) Doelstelling Het keuren van objecten zodat aantoonbaar kan worden gemaakt dat de objecten voldoen aan de eisen. Werkzaamheden

- Opstellen en naleven keuringsplannen - Uitvoeren keuringen - Opstellen keuringsrapporten - Opstellen verificatienota

Proceseisen Opstellen keuringsplannen De Opdrachtnemer dient per object keuringsplannen op te stellen. Uitvoeren keuren De Opdrachtnemer dient tijdens de realisatie keuringen uit te voeren en de resultaten hiervan schriftelijk vast te leggen om aan te tonen dat de gerealiseerde objecten voldoen aan de eisen. De Opdrachtnemer dient eventuele testen sequentieel uit te voeren, hetgeen betekent dat een opvolgende test niet eerder kan worden gestart dan wanneer de voorgaande test succesvol is afgesloten. Opstellen verificatienota De Opdrachtnemer dient de verwijzing naar de registraties waaruit het voldoen aan de eisen blijkt, op te nemen in de verificatienota. Producteisen Keuringsplan In een keuringsplan dient voor een object per eis tenminste het volgende te zijn geïdentificeerd en vastgelegd:

- Eis (met eisnummer); - Welke waarden moeten worden waargenomen; - Van toepassing zijnde bindende, informatieve en overige documenten; - Beschrijving van de keurings- of testmethode, keurings- of testtraject, de keurings- of testmeetmiddelen, de

geldende nauwkeurigheidseisen alsmede de calibratiemethoden, -frequentie en –registratie; - Wanneer is aangetoond dat aan de eis is voldaan; - Applicatie / raakvlakken van geteste item; - Betrokkenen bij keuring of test (incl. bevoegdheden en verantwoordelijkheden); - Validatie van de keurings- en testmethode; - De aanvaardingscriteria voor de keuring; - De formulieren die worden gebruikt tijdens de test.

Keuringsrapport Het keuringsrapport dient te voldoen aan dezelfde eisen als het keuringsplan. Aanvullend op hetgeen gesteld in paragraaf 21 lid 3 UAV-GC dient in het keuringsrapport voor een object per eis tenminste het volgende te zijn vastgelegd:

- Indien niet wordt voldaan de risico’s op het niet voldoen aan de eis en de noodzakelijke maatregelen;


- Identificatie van geconstateerde afwijkingen; - Feitelijke registratie van de keuringsresultaten, de waarde en eventuele marges; - Beperkingen tijdens keuring of test; - Invloed van de testomgeving; - In hoeverre wijkt de testomgeving af van de werkelijkheid; - Bewijsdocument of verwijzing naar bewijsdocument, waarin wordt aangetoond dat wordt voldaan aan de

gestelde eis. Verificatienota Zie hoofdstuk Verifiëren Ontwerpfase (red.).

Voorbeelden van Verificatieplannen, -rapporten en nota’s zijn te downloaden via: http://intranet.dienstinfrastructuur.nl/se


Bijlage III. SCB Toetsvragen voor projecten in uitvoering Richtvragen voor interviews over het verificatie- en validatieproces voor SCB-ers.

III-1. Inrichting V&V Proces Deze vragen gaan over de planning, verantwoordelijkheden, het inhoudelijke proces, relatie met andere processen

• Hoe zijn de processen van verificatie en validatie geborgd in het kwaliteitssysteem?

• Is er een V&V-strategie of -aanpak bepaald binnen het Kwaliteitsmanagement systeem?

• Op welke momenten wordt verificatie en/of validatie toegepast?

• Heeft u eigen kwaliteitsprocedures voor het V&V management binnen uw Kwaliteitsmanagement systeem?

• Zijn de diverse verificatiemethoden uitgewerkt in procedures?

• Heeft u afspraken gemaakt hoe om te gaan met niet-verifieerbare eisen? Zo ja, hoe bent u daarmee omgegaan?

• Optionele vraag: Welke problemen kwam u tegen/welke aanbevelingen zou u doen voor dit thema?

III-2. Organisatie/structuur Over de relatie opdrachtgever-opdrachtnemer, de verdeling van de verantwoordelijkheden:

• Wie bepaalde de V&V-strategie/de V&V-methode? ON, OG of beide partijen?

• Hoe lagen de verantwoordelijkheden met betrekking tot V&V tussen opdrachtgever en opdrachtnemer? Waar ligt dit vast?

• Hoe is het V&V-proces georganiseerd tussen opdrachtgever, opdrachtnemer(s), nevenaannemers en zelfstandige hulppersonen?

• Hoe zijn opdrachtgever, opdrachtnemer(s), nevenaannemers en zelfstandige hulppersonen betrokken in het V&V proces?

• Wie heeft de rol van system integrator?

• Hoe bewaakt u de overgang van verificatiedocumentatie van de ontwerpfase naar de uitvoeringsfase en de latere integratie?


III-3. Inhoud Over het resultaat, terminologie, producten en kosten

• Welke documenten zijn inmiddels opgeleverd uit het V&V? (denk aan de V&V-plannen, -rapporten en Verificatienota Ontwerpwerkzaamheden, en de keurings-en testplannen, -rapporten en Verificatienota Uitvoeringswerkzaamheden)

o Voldoen de verificatieplannen, verificatierapporten en de verificatienota’s aan de eisen van Vraagspecificatie Procesdeel? Toon dit aan.

o Voldoen de keurings-en testplannen, -rapporten en Verificatienota Uitvoeringswerkzaamheden aan de eisen van Vraagspecificatie Procesdeel? Toon dit aan.

• Welke terminologie is overeengekomen en waar ligt dit vast in het Kwaliteitsmanagementsysteem?

• Wie bepaald het niveau van diepgang voor de verificatie?


• Hoe hanteert u de diverse definities en begrippen van bestaande kaders (zoals UAV-GC)

in relatie tot de V&V-kaders uit Vraagspecificatie Procesdeel? (welke kaders zijn leidend?)


III-4. Mens Over competentie en kennis

• Hoe heeft u bepaald welke kennis en ervaring uw medewerkers dienen te hebben voor de V&V activiteiten?

• Welke competenties en kennis van medewerkers zijn nodig voor een goede uitvoering van de V&V werkzaamheden?



Bijlage IV. Do it yourself “V&V Kick-off” voor projectteams

IV-1. Werk de vragen samen uit met je projectteam: 1 Definieer en beschrijf samen het doel van verifiëren 2 Noem een de verwachte verificatiemethoden 3 Definieer en beschrijf het doel van valideren 4 Noem een aantal validatiemethoden 5 Wat gaat er over het algemeen goed in de realisatiefase met V&V? (en waardoor) 6 Wat gaat er over het algemeen fout in de realisatiefase met V&V? 7 Hoe problemen te voorkomen? 8 Waardoor zou een ON in de problemen kunnen komen bij het verifiëren? 9 Waarom zou een eis niet of moeilijk te verifiëren zijn? 10 Welke IPM-rollen moeten hier nauw samenwerken? 11 Wanneer stelt de ON zijn verificatieplan, -rapportage en -nota op 12 Hoeveel verificatienota’s stel een ON doorgaans op? En waarvan is dat afhankelijk? 13 Wanneer is er sprake in jullie project van validatie? En wie is daarbij betrokken?

WWB-SE-0044 Verificatie en Validatie, versie 0.5

Documents

Transcript of WWB-SE-0044 Verificatie en Validatie, versie 0.5