Werkwijzebeschrijving 00044 Verificatie en Validatie

Datum: 9 nov. 09 Pagina: 1/37 Werkwijzebeschrijving 00044 Verificatie en Validatie Bewijsvoeringmethode + Criterium + Beoordelaar

Datum: 9 nov. 09 Pagina: 2/37 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 vragenloket.se@rws.nl. 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.

Datum: 9 nov. 09 Pagina: 3/37 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

Datum: 9 nov. 09 Pagina: 4/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.

Datum: 9 nov. 09 Pagina: 5/37 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 definities 1 van verificatie en validatie zijn als volgt: Verificatie: Validatie: bevestiging door onderzoek en verstrekking van objectief bewijs dat aan de gespecificeerde eisen is voldaan. 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

Datum: 9 nov. 09 Pagina: 6/37 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) Afwijking Compliance Eisenbeheer Non-Compliance Pass/Fail criteria RCM / VVM RTM Systeem Tekortkoming Traceerbaarheid V&V V&V strategie Omschrijving Een ten opzichte van de projectplannen niet overeenkomende handeling die meestal niet voldoet aan de eisen. Het voldoen aan de eisen. Het monitoren en sturen op de inhoud en invulling van de eisen die aan het systeem en/of het projectmanagement. Het niet voldoen aan de eisen. Criteria op basis waarvan de objectieve bewijsvoering kan worden beoordeeld op het wel (pass) of niet (fail) voldoen aan de eisen en/of behoeften. 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. Requirements Traceablility Management. Het gestructureerd beheren van de eisenverzameling van een systeem of een project. RTM is een vereiste voor eisenbeheer. Een combinatie van samenhangende elementen die zodanig zijn georganiseerd om één of meerdere functies te vervullen. Laakbare afwijking van de overeengekomen invulling van de eisen waarop een sanctie rust. Herleidbaarheid van met name eisen. Meestal via een systeem van eiscodes is na te gaan hoe de eisen ten opzichte van elkaar zijn gerangschikt. 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. 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

Datum: 9 nov. 09 Pagina: 7/37 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 Verificatiemethode Verificatienota Waiver Activiteit waaruit de objectieve bewijsvoering volgt die gebruikt wordt voor de bewijsvoering dat aan de eisen en behoeften van de klant is voldaan. Activiteit waaruit de objectieve bewijsvoering volgt die gebruikt wordt voor de gehele of gedeeltelijke bewijsvoering dat aan de eisen is voldaan. 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. Het wegwuiven van een non-compliance. In dit geval wordt een beoordeling gemaakt dat er niet aan de eisen hoeft te worden voldaan.

Datum: 9 nov. 09 Pagina: 8/37 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 criterium 2 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

Datum: 9 nov. 09 Pagina: 9/37 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 staan 3 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

Datum: 9 nov. 09 Pagina: 10/37 eisen in de Klanteisenspecificatie staan waarvoor het zeer lastig is gepaste verificatieen/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.

Datum: 9 nov. 09 Pagina: 11/37 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.

Datum: 9 nov. 09 Pagina: 12/37 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 beoordelingen 4. 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

Datum: 9 nov. 09 Pagina: 13/37 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

Datum: 9 nov. 09 Pagina: 14/37 - 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.

Datum: 9 nov. 09 Pagina: 15/37 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

Datum: 9 nov. 09 Pagina: 16/37 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 3 de partij plaats via een voorgeschreven procedure. Deze (gekwalificeerde) 3 de 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.

Datum: 9 nov. 09 Pagina: 17/37 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. 3.1.2.8.3 Haalbaarheidstest Software integratie test in cabine 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.

Datum: 9 nov. 09 Pagina: 18/37 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 gebruik- en 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: Eindinspectie: momentopname/registratie van de eigenschappen van het systeem respectievelijk vóór aanvang van het project. 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.

Datum: 9 nov. 09 Pagina: 19/37 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.

Datum: 9 nov. 09 Pagina: 20/37 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.