Handboek Systems Engineering (SE) Overzicht in processen, informatie en technieken

Transcriptie

1 Handboek Systems Engineering (SE) Overzicht in processen, informatie en technieken APRIL

2 VOORAF Beter en professioneler samenwerken De kwaliteit en efficiëntie van het werk verhogen Bouwen wat de klant gevraagd heeft Expliciet en collega-vriendelijk werken Inzicht krijgen in de grotere context De juiste afwegingen maken en denken vanuit functionaliteiten en belangen van stakeholders Verminderen van fouten en faalkosten Weloverwogen keuzes maken en deze kunnen verantwoorden Makkelijkere acceptatie van resultaten door stakeholders bereiken In de samenwerking met het IB zaken expliciet afspreken iedereen heeft zo zijn eigen redenen voor het toepassen van Systems Engineering (SE), blijkt uit een rondgang onder ProRailers. Duidelijk is dat toepassing van SE zorgt voor een verrijking en verbreding van het vakmanschap. Met de toenemende complexiteit van projecten biedt deze integrale en complete werkwijze voor veel professionals een welkome versteviging van het vakmanschap. Gemeenschappelijk beeld De kennis en ervaring met SE die de afgelopen zeven jaar binnen Railtechniek is opgedaan maakt een volgende stap mogelijk, in de vorm van dit Handboek SE. Dit beschrijft het ontwikkelproces van begin tot eind. Het maakt inzichtelijk wat ProRailers op welk moment in het SE-proces aan activiteiten ontplooien, welke informatie ze daarbij nodig hebben en welke producten dat oplevert. Dit zorgt voor een gemeenschappelijk beeld van de toepassing van SE. KIES versterkt de praktijk De inhoud van het handboek is onderdeel van KIES (Kennisplatform Integraal en Expliciet Systeemontwerpen) van de afdeling Railtechniek. Hier zijn de onderdelen van het handboek te vinden en ook templates en een uitgebreidere beschrijving van technieken en producten. Nu en op de langere termijn is er aandacht voor toepassing van SE in de praktijk. Zo zijn er opleidingen over de inhoud van dit handboek. Daarbij is er aandacht voor het leren met elkaar. Bijvoorbeeld door in intervisiegroepen de toepassing en goede inzet van SE in het eigen project te bespreken. Ook kan iedereen met vragen terecht op het KIES-forum of bij een van de SE-begeleiders die op KIES zijn te vinden. Dit zijn collega s die meedenken over de juiste toepassing van SE binnen projecten. Dynamisch document De wereld, de techniek en ook ProRail zijn in ontwikkeling. De spoorwegsector verandert en dat maakt dit handboek tot een dynamisch document dat steeds aanvulling en aanscherping vraagt. Vandaar dat iedereen van harte is uitgenodigd om het handboek en de inhoud van KIES verder aan te vullen. 2

3 INHOUD VOORAF 2 LEESWIJZER 6 DEEL 1 HET WAAROM VAN SYSTEMS ENGINEERING Definitie van Systems Engineering Belangrijke uitgangspunten bij Systems Engineering De Leidraad SE voor de GWW-sector 12 DEEL 2 HET ONTWIKKELPROCES: ZEVEN FASEN, TWEE MODELLEN Het ontwikkelproces: van de taal van de klant naar de taal van de techniek De zeven ontwikkelfasen van een systeem Het SE-Procesmodel De hoofdprocessen van het SE-Procesmodel De projectprocessen van het SE-Procesmodel Verificatie & Validatie Het SE-Informatiemodel Stuurinformatie Eisen- en ontwerpinformatie SE-Informatieproducten SE binnen het Kernproces SE en contractering 31 DEEL 3 DE ACTIVITEITEN Behoefte Analyse (BA) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Behoefte Analyse (BA) Projectprocessen tijdens de BA Informatie tijdens de BA In de praktijk van de BA Concept Verkenning (CV) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Concept Verkenning (CV) Projectprocessen tijdens de CV Informatie tijdens de CV In de praktijk van de CV Concept Definitie (CD) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Concept Definitie (CD) Projectprocessen tijdens de CD Informatie tijdens de CD In de praktijk van de CD 52 3

4 3.4 Uitwerking Vastgesteld Concept (UVC) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Uitwerking Vastgesteld Concept (UVC) Projectprocessen tijdens de UVC Informatie tijdens de UVC In de praktijk van de UVC Detail Uitwerking (DU) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Detail Uitwerking (DU) Projectprocessen tijdens de DU Informatie tijdens de DU In de praktijk van de DU Realisatie (RE) Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens de Realisatie (RE) Projectprocessen tijdens de RE Informatie tijdens de RE In de praktijk van de RE Beheer & Exploitatie (B&E) Niet langer Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen tijdens Beheer & Exploitatie (B&E) Projectprocessen tijdens B&E Informatie tijdens B&E In de praktijk van B&E 72 DEEL 4 DE INFORMATIE Opbouw SE-Informatiemodel Doelgroep en taal Eiseninformatie Ontwerpinformatie Views en architectuur Uitwerking van de lagen De opdrachtlaag De gebruikslaag De functionele laag De fysieke laag De detailuitwerkingslaag 82 DEEL 5 DE TECHNIEKEN Stakeholderanalyse Eisen ontwikkelen Eisen identificeren Eisen identificeren vanuit de contextanalyse Eisen identificeren vanuit doelen Eisen identificeren met doelen en use cases Eisen definiëren Eisenanalyse Analyseren van individuele eisen 88 4

5 Ontwerpbeperkingenanalyse Analyse van de prioriteit van eisen Functionele analyse Interfaceanalyse Eisen afleiden Ontwerpen Gebruik modelleren Contextanalyse Doelenanalyse Gebruiksanalyse Functioneel ontwerpen Decomponeren Fysiek ontwerpen Objectenboom Interfaces Afwegen Metrieken (MoE, MoP) Trade-off analyse Ontwerpbesluiten Traceerbaarheid Verificatie & Validatie Afstemmen en onderhandelen Werkvormen 107 DEEL 6 DE PRODUCTEN Projectinitiatiedocumenten Project- en procesmanagementdocumenten Specificatiedocumenten Ontwerpdocumenten Verificatie & Validatiedocumenten 122 DEEL 7 ROLLEN, HOUDING EN GEDRAG Functies en rollen Competenties, houding en gedrag 129 AFKORTINGEN- EN BEGRIPPENLIJST 133 LITERATUURLIJST 142 COLOFON 144 BIJLAGE: ONTWIKKELPROCES EN CENELEC EN

6 LEESWIJZER Dit handboek bestaat uit een algemene introductie op SE (Deel 1), waarna de delen 2 t/m 6 ingaan op de SE-ontwikkelingsfasen, -processen, -technieken en -producten binnen de ProRail-praktijk. Deel 7 gaat in op de rollen, de houding en het gedrag bij het toepassen van SE. Dit handboek gaat uit van de werkpraktijk binnen railprojecten. Daarbij focussen we vooral op de ontwikkeling van het systeem en niet zozeer op de realisatie. Hoeveel SE-technieken en -producten worden ingezet hangt af van de complexiteit van het project. De inhoud van de zeven delen: Deel 1: Het wat en waarom van SE Wat is SE precies en waarvoor is het nodig? Oftewel: waarom zetten we SE in? En wat zijn belangrijke elementen van de werkwijze? Deel 2: Het ontwikkelproces Dit deel van het handboek beschrijft de structuur van het ontwikkelproces. Het beschrijft: - Het ontwikkelproces: van de taal van de klant naar de taal van de techniek. - De zeven ontwikkelfasen van een systeem: Behoefte Analyse (BA), Concept Verkenning (CV), Concept Definitie (CD), Uitwerking Vastgesteld Concept (UVC), Detail Uitwerking (DU), Realisatie (RE), Beheer & Exploitatie (B&E). Deze indeling is gebaseerd op de indeling van Kossiakoff in Systems Engineering, Principles and Practice. - Het SE-Procesmodel met de SE-hoofdprocessen (Gebruik modelleren, Functioneel ontwerpen, Fysiek ontwerpen) en de projectprocessen (Besluitmanagement, Risicomanagement, Planningsproces e.d.) alsmede Verificatie & Validatie (V&V). - Het SE-Informatiemodel dat de gelaagdheid in informatie toont. In Deel 2 is ook meer te lezen over hoe het handboek zich verhoudt tot het Kernproces, het conceptontwerp en de inzet van SE. Deel 3: De activiteiten Uitwerking van het SE-Procesmodel binnen de zeven ontwikkelfasen De SE-hoofdprocessen vragen in elk van de zeven ontwikkelfasen bepaalde activiteiten. Deel 3 beschrijft deze activiteiten. Daarbij wordt duidelijk welke informatie, technieken en producten een rol spelen binnen de beschreven activiteiten. Ook wordt steeds aangegeven welke informatie (input) nodig is en welke informatie (output) deze activiteiten opleveren. Deel 4: De informatie Tijdens het ontwikkelproces ontstaat continu informatie. Het SE-Informatiemodel toont een logische structurering en de samenhang van die informatie. Dit geeft zicht in de status en compleetheid van informatie. Deel 5: De technieken De technieken, zoals de stakeholderanalyse, het afleiden van eisen en het functioneel decomponeren, worden in Deel 5 verder uitgewerkt. Omdat de technieken nooit op zichzelf staan, schetst dit deel ook het kader waarbinnen deze technieken worden toegepast. Het is immers zinvol te weten waarom en binnen welke context bepaalde zaken plaatsvinden. Deel 6: De producten De in Deel 2 en Deel 3 genoemde producten, zoals de CRS (Customer Requirements Specification), het IBD (Initieel Behoefte Document) en het LOD (Logisch Ontwerp Dossiers), krijgen hier een uitgebreidere uitwerking. 6

7 Deel 7: Rollen, houding en gedrag Het laatste deel gaat over de mensen en competenties. Want hoewel systemen, technieken en producten bij SE belangrijk zijn, zijn het de mensen die het tot een succes maken. SE vraagt in de organisatie om: - Aandacht voor de invulling en erkenning van het belang van bepaalde rollen. - Erkenning van het belang van en aandacht voor bepaalde competenties op het vlak van houding en gedrag (soft skills) bij mensen, in teams en binnen projecten. De belangrijkste inhoud nog een keer op een rij: Deel Inhoud 1 Het waarom van SE 2 Het ontwikkelproces De zeven ontwikkelfasen (BA, CV, CD, UVC, DU, RE en B&E) Het SE-Procesmodel Het SE-Informatiemodel SE binnen het Kernproces SE en contractering 3 De activiteiten binnen de fasen Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen Projectprocessen Technieken en producten 4 Het SE-Informatiemodel 5 De technieken 6 De producten 7 Rollen, houding en gedrag 7

8 8

9 DEEL 1 HET WAAROM VAN SYSTEMS ENGINEERING Wat is SE eigenlijk precies? En wat heb ik eraan in mijn werk? Deze vragen stellen mensen die met SE te maken krijgen. Vandaar dat dit deel eerst kort uitlegt wat de werkwijze SE in essentie inhoudt en wat belangrijke elementen zijn bij de werkwijze. Ook wordt kort stilgestaan bij de Leidraad Systems Engineering voor de GWW-sector. Dit deel beschrijft: Een definitie van SE (1.1) Belangrijke uitgangspunten bij SE (1.2) De Leidraad SE voor de GWW-sector (1.3) 9

10 Systems Engineering (SE) ontstond in de jaren veertig van de twintigste eeuw als methode om met complexe systemen om te gaan. Het werd voor het eerst toegepast in de telefoniesector als methode om operabiliteit tussen verschillende delen van het telefoonsysteem te realiseren. In de jaren vijftig werd de werkwijze verder ontwikkeld door de lucht- en ruimtevaartindustrie, de defensie-industrie en de commerciële sector. Systems Engineering werd in de verschillende sectoren gezien als een geschikte methode om steeds complexer wordende systemen te kunnen realiseren. 1.1 DEFINITIE VAN SYSTEMS ENGINEERING Volgens de International Council on Systems Engineering (INCOSE) is de definitie van SE (vrij vertaald): Een interdisciplinaire benadering en de middelen daarbij, die zich richten op het realiseren van een succesvol systeem. SE focust op het definiëren van de klantbehoeften en de gevraagde functionaliteit vroeg in de ontwikkeling, het vastleggen van de eisen, de ontwerpsynthese en systeemvalidatie bij het beschouwen van het complete vraagstuk. Te denken valt aan: bediening en besturing, training en ondersteuning, kosten en planning, prestatie, realisatie, testen en verwijderen. SE beschouwt zowel de bedrijfsdoelen als de technische behoeften van alle stakeholders. Dit met het doel een kwaliteitsproduct te realiseren dat voldoet aan de gebruikersbehoefte. Oftewel: SE is een interdisciplinaire benadering (met uiteenlopende middelen) om een goed werkend systeem te maken. SE richt zich op de klantvraag en vertaalt die naar functionaliteit, en dit vroeg in de systeemontwikkeling. SE legt eisen vast. SE vraagt om validiteit van het systeem binnen het complete vraagstuk over de levenscyclus; daarbij kan gedacht worden aan: - Verkennen van de behoefte - Conceptontwikkeling - Uitwerking van het ontwerp - Productie - Training en uitrol - Exploitatie - Ondersteuning/support - Buiten gebruik nemen/sloop SE kijkt zowel naar bedrijfsdoelen als naar behoeften van alle stakeholders en vertaalt die naar eisen aan het systeem. Het uiteindelijke doel is een product te realiseren dat voldoet aan de behoefte van de gebruiker van het systeem. Deze INCOSE-definitie wordt ook gebruikt als uitgangspunt voor de Leidraad SE voor de GWW-sector, versie BELANGRIJKE UITGANGSPUNTEN BIJ SYSTEMS ENGINEERING Hierna volgen een aantal uitgangspunten die een belangrijke rol spelen bij SE. Systeemdenken SE is de manier van ontwikkelen (van behoefte tot integrale oplossing) door systeemdenken. Systeemdenken betekent dat elementen die deel uitmaken van de beoogde oplossing of interactie hebben met de behoefte worden gezien als één systeem. Daardoor vallen eisen te stellen aan de eigenschappen (prestaties en aspecten) van het systeem om een specifiek doel te halen. Dit doel is uiteindelijk om te voorzien in de klantbehoefte. De klantvraag centraal Bij SE staat de klantvraag centraal. Met het specificeren worden klantbehoeften vertaald in klanteisen en beoogd gebruik. Deze klanteisen worden vastgelegd in een CRS (Customer Requirements Specification). ProRail noemt dit een CRS, sommige andere partijen, waaronder Rijkswaterstaat, noemen dit een KES (Klant Eisen Specificatie). Tijdens de 10

11 systeemontwikkeling wordt continu afgestemd op de klantvraag. Met SE wordt uitgaande van die klantvraag de beste oplossing gecreëerd voor het systeem, binnen de gegeven oplossingsruimte. Optimalisatie over de hele levenscyclus SE overstijgt de diverse fasen van de levenscyclus en richt zich op het optimaliseren van het systeem in al deze fasen, ook in onderlinge samenhang. Wanneer te veel op één fase wordt gefocust kan dat zorgen voor suboptimalisatie. Bijvoorbeeld: een goedkoop materiaal dat veel onderhoud vraagt in de onderhoudsfase pakt voor de complete levens cyclus duurder uit. Expliciet werken Het goed (expliciet) vastleggen van informatie door de diverse betrokkenen is een voorwaarde bij SE. Bij de systeemontwikkeling zijn verschillende partijen en teams betrokken. Zij moeten samenwerken en informatie overdragen. Het is daarom van belang dat iedereen, dus ook opdrachtnemers, in elke fase informatie helder en eenduidig (expliciet) vastleggen. Zo zijn keuzes en informatie traceerbaar en overdraagbaar. Toepasbaar bij elke contractvorm SE is in de GWW-sector toepasbaar bij elke contractvorm en binnen elk project. Het hangt echter van de complexiteit van het project af hoe zwaar de werkwijze wordt ingezet. Aandacht voor competenties op het vlak van houding en gedrag De toepassing van SE ligt niet bij één persoon. SE is een werkwijze die door iedereen binnen het hele project wordt toegepast. Het vraagt inzet van en samenwerking door mensen met verschillende rollen en functies binnen het project. De invoering van SE vraagt naast technische competenties om bepaalde competenties in houding en gedrag (ook wel soft skills genoemd). Deze competenties zijn in verschillende mate aanwezig bij mensen en maar weinig personen kunnen ze allemaal inzetten. Vandaar dat het goed is om bij de samenstelling van teams binnen projecten te kijken in welke mate de competenties zijn vertegenwoordigd. Te denken valt aan competenties als: - Denken en praten in samenhang en daarmee verbanden zichtbaar maken - Vooruitdenken, scenario s ontwikkelen en toetsen - Creatief denken en overleggen - Verbinden van partijen Overzicht en grip op projecten! SE kan gezien worden als een integraal technisch projectmanagement. Het biedt een breed scala aan technieken en producten om zo compleet mogelijk het systeem te benaderen en daardoor grip te krijgen op projecten. De projecten in de GWW-sector blijven toenemen in complexiteit, dynamiek en hoeveelheid stakeholders; vandaar dat de sector sinds bijna tien jaar inzet op de toepassing van SE. 11

12 1.3 DE LEIDRAAD SE VOOR DE GWW-SECTOR In de GWW-sector is SE zo n negen jaar geleden geïntroduceerd. Dat gebeurde door het 4-partijenoverleg dat toen bestond uit ProRail, Rijkswaterstaat, Bouwend Nederland en NLingenieurs. Inmiddels zijn ook de Vereniging van Waterbouwers en Uneto-VNI aangehaakt bij het 4P-overleg. Deze zes partijen publiceerden in november 2013 samen de Leidraad SE in de GWW-sector, versie 3, getiteld De samenhang centraal. Leidraad versie 3 bestaat uit drie delen, te weten: De sector: het deel dat een beschrijving geeft van de ontwikkelingen binnen de sector. De organisatie: het deel dat beschrijft wat organisaties zoal kunnen doen om SE verder in te voeren. Het project: het deel dat aan de hand van een fictief project laat zien op welke momenten en op welke manieren SE kan worden ingezet. De Leidraad is bestemd voor iedereen in de GWW-sector die SE toepast of wil invoeren, zowel aan opdrachtgevers- als opdrachtnemerszijde en over de hele breedte van projecten. Hoewel niet bedoeld om naar te verwijzen in contracten, kan de Leidraad wel bijdragen aan een beter begrip van elkaar bij de toepassing van SE. Leidraad 3 is te bestellen via en is hier ook in digitale vorm en als Engelstalige versie te vinden. Praktijk Na deze algemenere intro op SE binnen de GWW-sector gaan de komende delen verder in op SE in de praktijk. Dit handboek biedt daarmee verdieping en toepasbaarheid van SE-kennis voor de ProRail-praktijk. 12

13 13

14 DEEL 2 HET ONTWIKKELPROCES Zeven fasen, twee modellen Dit handboek gaat uit van de koppeling tussen het ontwikkelproces en de ProRail-praktijk. Daarvoor is het ontwikkelproces opgedeeld in zeven fasen, waarbinnen steeds het SE-Procesmodel wordt doorlopen. Het SE-Procesmodel bevat drie hoofdprocessen (Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen) en twee loops (modelleringsloop en ontwerploop). Dit SE-Procesmodel wordt bij de systeemontwikkeling herhaald binnen alle fasen. In Deel 3 van dit handboek worden de zeven fasen inhoudelijk uitgewerkt. Hier is te lezen tot welke activiteiten het toepassen van het SE-Procesmodel en het SE-Informatiemodel binnen elk van de zeven fasen leidt. Dit deel bevat een omschrijving van: Het ontwikkelproces: van de taal van de klant naar de taal van de techniek (2.1) Een beschrijving van de zeven fasen in de systeemontwikkeling (2.2) Het SE-Procesmodel (2.3), inclusief een beschrijving van - De hoofdprocessen van het SE-Procesmodel (2.3.1) - De projectprocessen van het SE-Procesmodel (2.3.2) - Verificatie & Validatie (V&V) (2.3.3) Het SE-Informatiemodel dat hoort bij het SE-Procesmodel (2.4), inclusief een overzicht van de belangrijkste SE-producten SE binnen het Kernproces (2.5) SE en contractering (2.6) 14

15 figuur 2 Besluitmanagement (kernproces) Inkoopmanagement (contractering) oplossing ontwikkelen met SE behoefte De ontwikkelfasen BA CV CD UVC DU RE B&E ingevulde behoefte SE-informatiemodel Figuur 2: Samenhang tussen de processen en modellen beschreven in Deel HET ONTWIKKELPROCES: VAN DE TAAL VAN DE KLANT NAAR DE TAAL VAN DE TECHNIEK Het ontwikkelproces geeft een logische weg om van een vraag te komen tot de realisatie van een oplossing. De vraag komt van een klant en deze stelt zijn vraag in zijn eigen taal: de taal van de klant. Stakeholders (waar de klant er één van is) kennen een eigen jargon en begrippenkader. Daarbij denken ze vaak in andere abstracties dan ontwerpers en technici. In de taal van de klant kan niet worden ontworpen. Ontwerpers en technici denken in de taal van de techniek. Hun resultaat moet echter wel een optimale oplossing opleveren voor de vraag van de klant. Een belangrijke opgave in het ontwikkelproces is daarom het maken van de verbinding tussen de taal van de klant en de taal van de techniek. Stapsgewijze aanpak Om de verbinding te kunnen maken, volgt het ontwikkelproces een aantal stappen: Stap 1: Het begint met het verzamelen van de vraag en behoefte van de stakeholders in de taal van de klant. Stap 2: Met de stakeholders wordt de vraag scherper gemaakt door in stapjes toe te werken naar het modelleren van het gebruik dat aansluit bij de taal van de klant. Stap 3: Aansluitend start de ontwikkeling van de conceptuele oplossing en een scherpere vraagstelling in de taal van de techniek. Stap 4: Passend binnen de conceptuele oplossing en vanuit de scherpere vraagstelling ontwikkelen ontwerpers en technici de uiteindelijke oplossing in de taal van de techniek. Oplossing in de taal van de klant Aan het begin van een ontwikkelproces wordt gesproken met de primaire stakeholders. Deze primaire stakeholders gaan het systeem dagelijks gebruiken of beheren, ze financieren het, of ze zijn of worden er eigenaar van. Het beeld van de 15

16 behoefte is aan het begin bij de primaire stakeholders nog niet scherp ingekaderd. Behoeften sluiten niet bij elkaar aan, er komen zelfs tegenstrijdigheden voor. Of in de volledige behoefte kan worden voorzien is vaak nog onbekend. Het vinden van een oplossing is daarom een zoektocht. De eerste stap ligt in het vinden van een concept dat volgens de stakeholders de optimale invulling is van hun behoeften. Dit is een zoektocht naar (gezamenlijke) kansen en naar de keuzes bij tegengestelde belangen. Dit leidt uiteindelijk tot een of meer concept(en) waarin alle primaire stakeholders de mate van invulling van hun behoeften met bijbehorende ontwerpkeuze overeenkomen. Een voorwaarde om dit te bereiken is dat deze stakeholders aangesloten zijn op het ontwikkelproces. Dit betekent dat tijdens de conceptuele uitwerking gecommuniceerd wordt in de taal van de klant. Meenemen van stakeholders Het goed doorlopen van deze zoektocht is cruciaal voor het slagen van een project. De realiteit is dat aan het begin van een project alles nog niet zo duidelijk is. De stakeholders vormen een diverse groep, begrippen worden op verschillende manieren uitgelegd, er zijn nog veel onzekerheden, er bestaat nog geen duidelijk beeld van de omvang en complexiteit van de opgave, en bestaande systemen leggen allerlei beperkingen op. Het is daarom verstandig om tijd vrij te maken om de primaire stakeholders mee te nemen naar de conceptoplossing. Dit vraagt om puzzelen met de stukjes die deze stakeholders hebben meegegeven en ontdekken welke delen nog ontbreken. Dit alles om een compleet beeld te krijgen van de oplossing die volgens alle primaire stakeholders het antwoord is op hun vraag. Structuur aanbrengen in de vraag en in de oplossing is een continu proces. Het omvat een groot deel van de conceptuele fase van het ontwikkelproces (in de internationale SE-literatuur vaak omschreven als system architecting ). De conceptuele oplossing die ontstaat, bevat de architectuur van de oplossing. De conceptuele oplossing geeft een stabiele basis om tijdens de verdere uitwerking de essentie van de oplossing vast te houden, terwijl de ruimte bestaat om in te spelen op de dynamiek waarmee elk project te maken krijgt. Vertaalslag naar techniek Tijdens het structureren van de oplossing wordt de vertaalslag gemaakt naar de taal van de techniek. Dit gebeurt door het afleiden en formuleren van de eisen die aansluiten bij de taal van de techniek. Uitgaande van de conceptuele oplossing kunnen ontwerpers en technici starten met de technische ontwikkeling van een werkende en realiseerbare oplossing. Taal van de klant Taal van de techniek Proces Bestaand operationeel systeem Probleem Doelen Gebruik Scenario s Conceptuele oplossing Eisen compleet Werkende oplossing voor systeem Oplevering systeem Operationeel systeem Figuur 2.1: De taal van de klant en de taal van de techniek tijdens het ontwikkelproces Afwegingen Ook in deze stap zijn er veel vragen en vallen er knelpunten op te lossen, waarvoor de afwegingen op technisch-inhoudelijke gronden kunnen worden gemaakt. De conceptoplossing en eisen vormen hiervoor het kader. Daarbij is de conceptoplossing de oplossing zoals de primaire stakeholders die voor ogen hebben. Als hiervan in de technische oplossing afgeweken moet worden, raakt dit één of meer belangen van deze stakeholders en moet(en) deze opnieuw worden betrokken. Na de gedetailleerde uitwerking van de oplossing vindt de realisatie plaats. Dit leidt uiteindelijk tot ingebruikname door de exploitatie- en beheerorganisatie. Ontwikkelproces De hiervoor beschreven stappen worden binnen het ontwikkelproces ook wel samengevat als Vraag Articulatie -> Conceptuele Uitwerking -> Detail Uitwerking. 16

17 Uitgaande van de hiervoor beschreven stappen is het ontwikkelproces in zeven fasen te verdelen: Het begint met de initiatie van het ontwikkelproces door het aannemen en beoordelen van de vraag in de Behoefte Analyse (BA) (taal van de klant). Dit wordt gevolgd door het scherp krijgen van de vraag en het ontwikkelen van de conceptoplossing en de architectuur in de Concept Verkenning (CV) en de Concept Definitie (CD), de twee grote conceptuele fasen in het ontwikkelproces (hoofdzakelijk in de taal van de klant, met een vertaalslag naar de techniek). Dan volgt de technische uitwerking van de oplossing in de Uitwerking Vastgesteld Concept (UVC) en de Detail Uitwerking (DU). Tot slot is er de realisatie tijdens de Realisatie (RE), uitmondend in het dagelijks gebruik in de fase van Beheer & Exploitatie (B&E). Deze indeling in fasen bouwt voort op de Leidraad en sluit aan bij moderne SE-literatuur. In elk ontwikkeltraject worden deze fasen doorlopen. Afhankelijk van het project kunnen duur en omvang van de fasen sterk verschillen. Het gehele proces van de vraag in de taal van de klant naar de uiteindelijke oplossing door de techniek is het werkterrein van de Systems Engineer. Gelaagd ontwikkelmodel Binnen de fasen bestaat een terugkerend patroon van informatie verzamelen, informatie analyseren, eisen definiëren en ontwerpen. Deze activiteiten zijn samengevat in het SE-Procesmodel. Parallel aan het logische en terugkerende patroon van ontwikkelactiviteiten volgt de informatie ook een logisch patroon. De gelaagde en logische structuur hiervan is samengevat in een SE-Informatiemodel dat hoort bij het SE-Procesmodel. Paragraaf 2.2 geeft een compacte beschrijving van de fasen, 2.3 staat stil bij het SE-Procesmodel, en 2.4 beschrijft het SE-Informatiemodel. 2.2 DE ZEVEN ONTWIKKELFASEN VAN EEN SYSTEEM Hierna volgt een beknopte uitwerking van de genoemde zeven fasen bij systeemontwikkeling, te weten: Behoefte Analyse (BA) Concept Verkenning (CV) Concept Definitie (CD) Uitwerking Vastgesteld Concept (UVC) Detail Uitwerking (DU) Realisatie (RE) Beheer & Exploitatie (B&E) We spitsen de fasen nu meer toe op de ontwikkelvraagstukken bij ProRail. Ontwikkelfase Behoefte Analyse (BA) Concept Verkenning (CV) Concept Definitie (CD) Uitwerking Vastgesteld Concept (UVC) Detail Uitwerking (DU) Realisatie (RE) Beheer & Exploitatie (B&E) Proces Bestaand operationeel systeem Probleem Doelen Gebruik Scenario s Conceptuele oplossing Eisen compleet Werkende oplossing voor systeem Oplevering systeem Operationeel systeem Figuur 2.2.a: Fasen in de ontwikkeling van een systeem 17

18 De zeven fasen in het ontwikkelproces en hun definitie Hierna volgt een beschrijving van elk van de zeven ontwikkelfasen; Deel 3 bevat een completere uitwerking per fase. Behoefte Analyse (BA) Samen met de klant wordt vastgesteld wat de initiële behoefte is. Dit betekent dat wordt achterhaald wat het probleem is en wat de behoefte is, wat een oplossing moet leveren en welke baten een oplossing voor de klant heeft. Zodra aannemelijk is te maken dat er uitzicht is op een haalbare oplossing die de behoefte kan invullen, wordt een projectvoorstel geformuleerd. De belangrijkste opbrengst van deze fase: vastgesteld is wat de behoefte is en waar de prioriteiten liggen van de opdrachtgever (initiatiefnemer/financier). Ook ontstaat een idee van de complexiteit, de grootste risico s en daarmee de haalbaarheid van het project. Concept Verkenning (CV) Het zwaartepunt ligt bij het verzamelen van alle stakeholderbehoeften en -doelen en het opstellen van functionele conceptoplossingen. De scenario s en use cases worden in kaart gebracht. Dit alles wordt gebruikt om de stakeholdereisen te identificeren. Hier start het opstellen van eisen aan het systeem: systeemeisen (taal van de techniek) die de stakeholdereisen (taal van de klant) invullen. Op basis van deze eisen worden mogelijke concepten (oplossingsrichtingen) gegenereerd en geanalyseerd. Concept Definitie (CD) Het zwaartepunt in deze fase ligt bij het ontwikkelen van het fysieke deel van de concepten en het afwegen van de complete concepten. De concepten worden verder uitgewerkt om prestaties, kosten en risico s betrouwbaarder in te schatten en de haalbaarheid en maakbaarheid vast te stellen. Bij de selectie van het concept zijn de toegevoegde waarde voor de stakeholders, de kosten en de effecten van belang. In deze fase wordt uiteindelijk door de stakeholders het voorkeursconcept vastgesteld. Uitwerking Vastgesteld Concept (UVC) Hier vindt het uitwerken van het vastgestelde concept plaats door het opsporen en reduceren van risico s in nieuwe en/of complexe (onderdelen van) subsystemen. Aan het eind van deze fase zijn op alle systeemniveaus in het ontwerp de verwachte prestaties en kosten inzichtelijk en de risico s voor prestatie en kosten beheersbaar. Detail Uitwerking (DU) Deze fase is gericht op het volledig uitwerken van het ontwerp, zodat de realisatie kan starten. Dit is inclusief de aan - passingen in het fysieke ontwerp die nodig zijn om de oplossing te kunnen bouwen. Het gaat dan bijvoorbeeld om constructieve ontwerpen voor hulpconstructies of tijdelijke verlichting tijdens de bouw. Het detailontwerpen stopt op het niveau waarop elementen (componenten) vanaf de plank beschikbaar zijn. Realisatie (RE) Realisatie van het fysiek ontwerp betreft het samenvoegen van onderdelen tot een werkend geheel, waarna wordt aangetoond dat het systeem voldoet aan het beoogde gebruik en de eisen. Beheer & Exploitatie (B&E) In deze fase vindt de overdracht plaats van de project- naar de beheerorganisatie. De middelen en informatie die in het ontwikkel- en realisatietraject zijn gecreëerd, worden in deze fase overgedragen. Daarmee wordt het systeem in gebruik genomen. Bij de overdracht dient kennis vanuit het ontwikkeltraject te worden gedeeld. Het handboek geeft een overzicht van het gehele proces. Wat voor ProRail (Railtechniek) van belang is, wordt daarbij dieper uitgewerkt. Hoe het proces en de fasen zich voegen in het Kernproces, beschrijft paragraaf 2.6. Fasen en de activiteiten daarbinnen zijn schaalbaar, afhankelijk van de vraag en de complexiteit van een project. 18

19 figuur 2.2.b Behoefte Eigenschappen van het ontwikkelproces Het ontwikkelproces wordt opgedeeld in zeven fasen: de projectinitiatie in de BA, het ontwikkelen van het voorkeursconcept in de CV en CD, het verder ontwikkelen van de kritische subsystemen in de UVC, de detailuitwerking in de DU, de realisatie (RE) en uiteindelijk de overgang naar het dagelijkse Beheer & Exploitatie (B&E). Eigenschappen van dit ontwikkelingsproces zijn: De klantbehoefte centraal Door het zorgvuldig in kaart brengen van de stakeholderbehoefte vanaf het eerste contact (BA en CV) en het vervolgens in alle fasen continu valideren van eisen en oplossingen aan de hand van deze stakeholderbehoefte. Systeemdenken Beginnend met het ontwikkelen van de passende oplossing op systeemniveau (BA, CV, CD), en als op dat niveau de oplossing voldoet, het afdalen naar het ontwikkelen van de oplossingen voor de subsystemen en elementen (UVC, DU). Vervolgens worden de ontwerpen geïntegreerd tot een ontwerp van het totale systeem (DU). Uiteindelijk worden in de Realisatie (RE) alle gefabriceerde elementen tot subsystemen en uiteindelijk een totaalsysteem geïntegreerd. Behoefte Oplossing Oplossing Figuur 2.2.b: Eigenschappen van het ontwikkelproces De sturing van de ontwikkelfasen gebeurt door gericht risicomanagement Hiermee wordt in iedere fase de benodigde diepgang van de ontwerpen bepaald en wordt gecontroleerd of de resultaten behaald zijn om een fase af te ronden. De risicogroepen waarop primair gestuurd wordt zijn: - Prestatierisico s: tijdens het ontwikkelproces wordt steeds duidelijker of het systeem de vereiste prestatie levert. - Waarderisico s: continu wordt gemonitord of de oplossing nog voldoende waarde heeft voor de stakeholders en de kosten de door de stakeholder gestelde grenzen niet overschrijden. - Realisatierisico s: het kunnen beheersen van het realisatieproces, zowel qua tijd als kosten. Tabel 2.2 geeft een overzicht van de risicoprofielen waar in iedere fase naartoe wordt gewerkt. 19

20 Risico BA CV CD UVC DU RE B&E Prestatie en aspecten Realisatie Waarde Belangrijkste risico s geïdentificeerd Complexiteit geïdentificeerd Belangrijkste kosten- en waarderisico s geïdentificeerd Op systeemniveau risico s geïdentificeerd Complexiteit gedefinieerd Systeemkosten en waarderisico s geïdentificeerd, bepaald Op systeemniveau prestatie- en aspectrisico s opgelost Belangrijkste risico s voorzien van beheersmaatregelen en risicobudget deels beheersmaatregelen Systeemwaarderisico s beheersbaar vastgesteld Op subsysteemniveau prestatie- en aspectrisico s opgelost Alle known risks geïdentificeerd, beheersmaatregelen bepaald en van afdoende risicobudget voorzien verkleind - Direct meetbare Alle known risks beheersbaar gemaakt en risicobudget bepaald voor unknown risks verder verkleind prestatie gevalideerd Maatregelen genomen tegen unknown risks Kostenuitgave beheerst, verificatie van de kosten Volledige prestatie definitief gevalideerd - Verificatie van de baten Tabel 2.2 Risicoprofiel per fase figuur HET SE-PROCESMODEL Deze paragraaf geeft een beschrijving van: Het SE-Procesmodel De hoofdprocessen uit het SE-Procesmodel (Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen) De projectprocessen uit het SE-Procesmodel Verificatie & Validatie SE-Procesmodel Technologische basis Procesinput Gebruik modelleren Projectprocessen Functioneel ontwerpen gemaakt, kostenbandbreedte Kostenbandbreedte Kostenbandbreedte Modelleringsloop Ontwerploop Fysiek ontwerpen Procesoutput Figuur 2.3: SE-Procesmodel 20

21 Het SE-Procesmodel geeft een logische en praktische inrichting van de modellerings- en ontwerpstappen in iedere ontwikkelfase. Dit loopt van het beoogd gebruik naar functionele oplossing en als laatste naar fysieke oplossing. Het bestaat uit drie terugkerende hoofdprocessen (Gebruik modelleren, Functioneel ontwerpen en Fysiek ontwerpen) die tijdens het merendeel van de zeven ontwikkelfasen worden doorlopen om van de klantvraag tot een fysieke oplossing te komen. De modelleringsloop en de ontwerploop maken het iteratieve proces zichtbaar dat daarvoor doorlopen wordt. Het model wordt gecompleteerd door de Projectprocessen die tijdens de ontwikkeling van het systeem van belang zijn. Toepassing SE-Procesmodel tijdens de zeven fasen Hoe de hoofdprocessen en projectprocessen van het SE-Procesmodel tijdens de zeven fasen van systeemontwikkeling worden ingezet, beschrijft Deel 3: de activiteiten DE HOOFDPROCESSEN VAN HET SE-PROCESMODEL Binnen het SE-Procesmodel zijn er drie hoofdprocessen: Gebruik modelleren Functioneel ontwerpen Fysiek ontwerpen Deze hoofdprocessen spelen tijdens het gehele project en daarmee in alle zeven fasen een rol. Hierna volgt een beschrijving van de drie hoofdprocessen: Gebruik modelleren Het verzamelen van behoeften en doelen, alsmede het analyseren van beoogd gebruik (uitmondend in scenario s en use cases). Zo ontstaat een beeld van hetgeen waaraan het systeem moet voldoen, de producten of diensten en de prestaties die het systeem moet leveren. Deze worden vastgelegd in de taal van de klant in de stakeholdereisen. Een project begint met het in kaart brengen van de stakeholders, hun behoefte en de doelen die ze nastreven (inclusief de waarde van die behoefte voor de stakeholders). Dit vormt de input voor het modelleren van het gebruik, onder verschillende scenario s, waaronder het systeem moet kunnen functioneren en de prestaties die het systeem daarbij moet leveren. De analyse van de stakeholders levert een beeld op van de gebruikers van het systeem (personen of andere systemen). Voor elk van hen wordt het beoogde gebruik gemodelleerd en worden de eisen afgeleid die dit gebruik stelt aan het systeem. Dit wordt vastgelegd in use cases. Functioneel ontwerpen Het ontwikkelen van een samenhangende, functionele vorm van modellering, waarmee het systeem het gevraagde product of de gevraagde dienst met de gevraagde prestatie kan leveren. Voor de functies in het model worden de eisen afgeleid die invulling geven aan de stakeholdereisen, behoeften van de stakeholders en de scenario s en use cases. Hiermee is de stakeholderbehoefte vertaald in een functioneel gestructureerde set eisen in de taal van de techniek. Dit herhaalt zich voor elk niveau dat bepalend is voor de prestaties van het systeem. Zo is vastgelegd wat het systeem moet kunnen, met welke kwaliteiten en onder welke condities. Tijdens de ontwerpslagen wordt continu een analyse gemaakt van de conceptoplossing(en) om de motivatie en verbeterpunten vast te stellen. Het functionele model en de gestructureerde eisen zijn de basis voor het uitwerken van de fysieke oplossingen. Fysiek ontwerpen Het ontwikkelen van fysieke, softwarematige en procesmatige oplossingen in de taal van de techniek op basis van het functionele ontwerp en de functioneel gestructureerde set eisen. Functies worden vertaald in fysieke subsystemen, waarvan wordt bepaald hoe ze er fysiek uitzien en waar ze in de ruimte worden geplaatst. Voor de subsystemen en elementen worden de eisen afgeleid. Een van de opgaven is om het ontwerp inpasbaar te maken binnen de beschikbare ruimte. Bij de infrastructuur van het spoorsysteem bepaalt de plaats van elementen voor een groot gedeelte de prestatie. Dit geldt bijvoorbeeld voor de spoorlay-out of transferlay-out van een station of de seinplaatsing. Dit plaatsen in de ruimte draagt bij aan een belangrijk onderdeel van het Fysiek ontwerpen: het definiëren van de interfaces tussen de subsystemen. Tijdens de ontwerpslagen wordt continu een analyse gemaakt van de oplossing(en) om de motivatie en verbeterpunten vast te stellen. Waar meerdere fysieke oplossingen mogelijk zijn, helpt een afweegproces (Trade-off) bij het selecteren van de oplossing met de meeste toegevoegde waarde. Voor de geselecteerde fysieke oplossing worden op basis van de gemaakte ontwerpkeuzes voor de subsystemen en elementen de eisen afgeleid. 21

22 Eisen ontwikkelen In elk hoofdproces vindt het identificeren, afleiden, definiëren en analyseren van eisen plaats. Dit gebeurt simultaan met het analyseren, modelleren en ontwerpen. Bij aanvang van het SE-proces start het eisen ontwikkelen met het in kaart brengen en analyseren van eisen van de stakeholders. Als de modellerings-/ontwerpstappen gestart zijn, worden via afleidingen van het model/ontwerp, eisen geformuleerd. Deze eisen worden vervolgens geanalyseerd en aan de bestaande eisenset toegevoegd. In elke fase worden de verzamelde eisen en de eisenset die voortkomt uit de voorafgaande fasen grondig geanalyseerd. Daarbij worden ze gecheckt op onder meer compleetheid en traceerbaarheid, en daarmee wordt de kwaliteit van de eisen verbeterd. Ook wordt gevalideerd of ze aan de bovenliggende behoeften beantwoorden. Continu wordt de eisenset gecompleteerd en de kwaliteit van de eisen verbeterd. Modelleringsloop en ontwerploop Het SE-Procesmodel omvat de modelleringsloop en de ontwerploop. Deze beide loops tonen de in elke fase terugkerende iteratieve stappen in het model. De modelleringsloop De modellering van het beoogde gebruik leidt tot eisen aan het (sub)systeem. Het Functioneel ontwerpen geeft een beter inzicht in de invulling van het gebruik, de eisen en de compleetheid ervan en in de relaties tussen eisen onderling. Dit kan aanleiding zijn om de modellering van het gebruik en de kwaliteit van de eisen te verbeteren. Die terugkoppeling van Functioneel ontwerpen naar Gebruik modelleren sluit de modelleringsloop. De ontwerploop Tijdens het ontwerpproces vindt er regelmatig een terugkoppeling plaats tussen het fysieke en het functionele ontwerp om te controleren of het fysieke ontwerp op het juiste prestatieniveau de vereiste functies kan realiseren. Dit kan leiden tot bijstelling of uitbreiding van het functionele ontwerp. De ontwerploop stuurt zo de optimalisatie van de oplossing en geeft zicht op de mate waarin het systeem aan de behoefte en doelen kan voldoen. Technologische basis Projecten binnen ProRail hebben altijd te maken met een technologische basis. Bij spoorsystemen wordt binnen een bestaand systeem gewerkt en deze worden nooit from scratch ontwikkeld. Daarmee bestaat er een referentie waarbinnen de oplossing moet passen. Deze vormt input voor het ontwikkelproces. Architectuur opbouwen De railsector past SE toe in een omgeving waarin de architectuur (en daarmee een deel van de technologische basis) niet expliciet (onderbouwd) is vastgelegd. Daardoor is het nodig om in ieder project een volledige architectuur op te bouwen. Daarbij bestaat het risico dat niet opgemerkt wordt dat een projectarchitectuur op punten niet consistent is met de functionele en fysieke architectuur van het bestaande spoorsysteem. Dit brengt mogelijk risico s met zich mee voor de acceptatie door de stakeholders, de beschikbaarheid, de betrouwbaarheid, de doorlooptijd of de kosten DE PROJECTPROCESSEN VAN HET SE-PROCESMODEL Naast de drie hoofdprocessen bevat het SE-Procesmodel ook de projectprocessen. De projectprocessen komen net als de drie SE-hoofdprocessen terug in elke fase van het ontwikkelproces. De projectprocessen zijn activiteiten en technieken die helpen om de kwaliteit van het ontwikkelproces en daarmee het systeem te waarborgen. Het zijn daarmee niet zuiver technische processen. Binnen het SE-Procesmodel kennen we de volgende projectprocessen: Besluitmanagement Metrieken en toetsen Risicomanagement Planningsproces Informatiemanagement Configuratiemanagement Projectmonitoring en beheerprocessen 22

23 Doel van projectprocessen De projectprocessen zijn bedoeld om: De status en de voortgang van het ontwikkelproces te monitoren Vast te stellen in welke mate het ontwerp de gevraagde prestatie kan leveren De (technische, prestatie- en waarde-)risico s te identificeren en managen Alternatieven te beoordelen en selecteren Gegevens en beslissingen te documenteren en beheren De projectprocessen uit het SE-Procesmodel kunnen tijdens alle fasen van de systeemontwikkeling worden ingezet. We onderscheiden de volgende projectprocessen: Besluitmanagement Selecteren, managen, vastleggen en beheren van de beslismomenten en de onderbouwing van de beslissingen. Daarbij zijn twee soorten besluiten te onderscheiden: - technisch-inhoudelijke besluiten (vaak onderdeel van het ontwerpproces, de zogenaamde ontwerpbesluiten) - besluiten van stakeholders Beide moeten binnen het ontwikkelproces gemanaged worden. Metrieken en toetsen Verzamelen, analyseren en rapporteren van kwantitatieve informatie voor product- en procesontwikkeling. Dit is bedoeld om objectief de kwaliteit van het product aan te tonen. Het toetsen ondersteunt de Verificatie & Validatie. De metrieken ondersteunen het besluitmanagement. Risicomanagement Methode om continu en systematisch risico s en kansen te identificeren, analyseren en monitoren tijdens elke fase van de systeemontwikkeling. Risico s zijn bijvoorbeeld te mitigeren door eisen te stellen aan producten, processen of mensen. Planningsproces Produceren en communiceren van effectieve en werkbare planningen. Het proces helpt bij het bepalen van de scope van het project en het organiseren van het ontwikkelproces. Informatiemanagement Verstrekken van relevante tijdige, complete en valide informatie tijdens alle fasen van de ontwikkeling. Het juist vastleggen en beschikbaar hebben van relevante informatie maakt het mogelijk om aan elke betrokken partij tijdig de nodige informatie te verstrekken. Configuratiemanagement De technische en organisatorische activiteiten voor het identificeren, beheersen, verantwoorden en daarmee het continu vastleggen van de status van de configuratie-items, waaronder documenten, alsmede het auditen van configuraties. De resultaten moeten daarbij consistent zijn, zodat bijvoorbeeld de eisenspecificaties in lijn zijn met de ontwerpen. Wijzigingenbeheer valt onder configuratiemanagement. Projectmonitoring en beheersprocessen Het bijhouden van de projectstatus binnen de factoren tijd, kosten en scope. Dit om het project goed te blijven aansturen. projectprocessen in het ontwikkelproces Ontwikkelfase Behoefte Analyse (BA) Concept Verkenning (CV) Concept Definitie (CD) Uitwerking Vastgesteld Concept (UVC) Detail Uitwerking (DU) Realisatie (RE) Beheer & Exploitatie (B&E) Doel fase Aannemelijk maken noodzaak project. Definiëren probleem, doelen, waarde en haalbaar - heid visualiseren. De taal van de klant verzamelen en uitwerken, (doelen, waarde, behoefte, beoogd gebruik), ontwikkelen logische/ functionele architectuur en prestatie-eisen afleiden. Ontwikkelen fysieke architectuur en selecteren voorkeursconcept. Beheersbaar maken van risico s op subsysteem- en elementniveau. Volledig uitwerken van alle subsystemen en elementen en integreren tot één fysiek ontwerp, zodat realisatie kan starten. Realiseren oplossing, door bouwen en samenvoegen fysieke onderdelen tot aantoonbaar werkend geheel. De opgedane informatie, organisatie en middelen worden toegankelijk gemaakt voor vraagstukken en ont wikkeling in het dagelijks beheer en exploitaitie. Projectprocessen Besluitenmanagement Metriek en toetsen Risicomanagement Planningsproces Informatiemanagement Configuratiemanagement Projectmonitoring en beheerprocessen Figuur 2.3.2: De projectprocessen in het ontwikkelproces 23

24 2.3.3 VERIFICATIE & VALIDATIE Verificatie & Validatie kortweg V&V is een onderdeel van het SE-Procesmodel en komt terug in elke fase. Om er zeker van te zijn dat het uiteindelijke product aan de behoeften en het beoogde gebruik voldoet, wordt er regelmatig getoetst. De resultaten worden gebruikt om de voortgang van de invulling van de eisen en de risico s te managen. Zo kan tussentijds het ontwikkelingsproces worden bijgestuurd. Het toetsen gebeurt op twee verschillende manieren. Zo wordt getoetst of het product: Voldoet aan het beoogd gebruik en de stakeholdereisen wordt het juiste systeem gemaakt (validatie)? Voldoet aan de gestelde eisen wordt het systeem juist gemaakt (verificatie)? Met verifiëren en valideren wordt nagegaan aan welke eisen en behoeften wel of niet kan worden voldaan. Waar aan één of meerdere eisen niet kan worden voldaan, zijn mogelijk besluiten van de stakeholders nodig om bijvoorbeeld strijdigheden tussen eisen op te lossen of goedkeuring te krijgen dat eisen verruimd of losgelaten worden. Verificatie-en-validatieproces Bij de Verificatie & Validatie zijn meerdere partijen/rollen betrokken, onder anderen ontwerpers, systeemanalisten en V&V Engineers (zie deel 7). Om de kwaliteit van de Verificatie & Validatie te borgen, moeten de volgende onderwerpen geregeld zijn: Organisatie Een verificatie-en-validatiemanagementplan legt vast wie wat op welk moment doet binnen het V&V-proces. Hierbij wordt gekeken naar de activiteiten binnen de scope van het project en de uitwisseling van informatie met stakeholders. Methoden Verificatie & Validatie gebeurt tijdens het gehele project. Het wordt toegepast tijdens het gehele ont wikkelproces. Er zijn verschillende soorten methoden om te valideren en verifiëren. Voorbeelden hiervan zijn: - Simulatie - Ontwerpreview op eisen - Ontwerpreview op functie - Prototypen - Factory Acceptance Test (RE) - Site Integration Test (RE) - Site Acceptance Test (RE) Proces Om duidelijk te krijgen wie wanneer wat (een compleet stappenplan van alle activiteiten) gaat doen, wordt een V&V-procedure geschreven. Hierin ligt vast: - Per eis conform welke methode wordt gevalideerd en geverifieerd - Wat de vereiste norm is - Wanneer de verificatie en validatie plaatsvindt (planningsvolgorde) - Door wie de verificatie en validatie wordt uitgevoerd - Met welke hulpmiddelen de verificatie en validatie wordt uitgevoerd Communicatie De resultaten uit de verificatie-en-validatiemethoden worden vastgelegd door de verifiërende en validerende partij voor de Systems Engineer. De Systems Engineer rapporteert aan de stakeholders in welke mate wordt voldaan en waar problemen worden verwacht. De V&V-producten Om het verificatie-en-validatieproces te ondersteunen worden een aantal specifieke producten gehanteerd: V&V-managementplan: beschrijving van de aanpak, organisatie, relevante V&V-methoden en planning V&V-procedure: inhoudelijke beschrijving van de stappen voor het aantonen van de eisen, inclusief de pass- en fail-criteria V&V-rapportage van de resultaten: overzicht met de V&V-resultaten V&V-rapportage aan de stakeholders: overzicht of nog het juiste systeem wordt gemaakt, of het juist wordt gemaakt, welke keuzes zijn te maken en waar problemen worden verwacht 24