Inleiding
De laatste jaren is er veel aandacht voor het verifiëren en valideren. Gehanteerde definities 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 belevingen gebruik dat het gerealiseerde product voldoet aan de eisen en behoeften van de klant, in aanvulling op de verificatie. Bron: Rijkswaterstaat |
Deze twee processen gaan vaak hand in hand met gespecificeerde eisen… “het verifiëren en valideren van eisen”.
Zo wordt er vaak in V&V-plannen bij elke eis uit de specificatie wordt, indien relevant, aangegeven
- Wanneer wordt aangetoond dat is voldaan aan de eis;
- Wie de verificatie uitvoert;
- Validatie van de verificatie methode.
Maar wat als de eisen en behoeften niet beschreven staan?
Casus Vluchtdeur
Ooit kwam ik in een contract de volgende eis tegen in het hoofdstuk “vluchtdeuren”
Eis-0765 -“Als de veiligheidsdeur geopend wordt, moet de motor afgeschakeld worden.“
We kunnen lange discussies voeren over de schrijfwijze van deze eis. Immers, de schrijfregel is “Het systeem dient … “. De opdrachtgever zou misschien nog kunnen bakkeleien of de eis toch niet in het hoofdstuk “motor” had gemoeten, de integraal ontwerpleider van de opdrachtnemer heeft op basis van onderstaande ontwerpschets op zijn beurt het vermoeden dat het hoofdstuk “Besturing en bediening” ook een goede plek zou kunnen zijn. De eis zou wellicht nog wat “smarter” gemaakt kunnen worden, maar eigenlijk is de eis best rechttoe rechtaan toetsbaar als het systeem gebouwd is: Deur open, motor af: Check!
In onderstaand figuur is een state transition diagram weergegeven. Deze diagrammen worden veel gebruikt om de bedrijfstoestanden en overgangen van een object in vast te leggen. Het gepresenteerde diagram met 2 states is de meest simpele vorm: Je zou het kunnen zien als aan/uit, open/gesloten, etc. Natuurlijk kan een object meerdere statussen hebben “gesloten, aan het openen, volledig open, sluiten”.
|
| Gebeurtenis (Event). Een gebeurtenis die een statusovergang teweeg kan brengen. Gebeurtenis types omvatten een expliciet signaal van buiten het systeem, een aanroep van binnen het systeem, de passage van een aangewezen tijdspanne, of een aangewezen voorwaarde die waar wordt. |
|
Wat fijn is aan dit type diagrammen is dat er strikte regels zijn over de compleetheid van een STD. Dat maakt het STD ook een uitermate handig middel om eisen te analyseren en gaten in het programma van eisen te ontdekken.
Hieronder een aanpak hoe je deze analyse zou kunnen toepassen in je project.
Stappenplan
- Identificeer de te besturen/detecteren delen
- Bepaal vanuit de eisen de benoemde statussen, gebeurtenissen, guards, overgangen, en acties van de delen
- Verwerk deze informatie naar STD en leg info vast in “mensentaal”
- Controleer de volledigheid van de bedrijfstoestanden
- Identificeer per STD: Wat weet je zeker / niet zeker / aannames
- Prioriteer welke informatie wel/ niet / als eerste besproken moet worden
- Bepaal bij wie ontbrekende informatie gehaald moet worden en wie mandaat heeft om beslissingen te nemen
- Leg de traceerbaarheid vast.
1. Identificeer de te besturen/detecteren delen
“Als de veiligheidsdeur geopend wordt, moet de motor afgeschakeld worden.“
2. Bepaal vanuit de eisen de benoemde statussen, gebeurtenissen, guards, overgangen, en acties van de delen
“Als de veiligheidsdeur geopend wordt, moet de motor afgeschakeld worden.“
3. Verwerk deze informatie naar STDs en leg info vast in “mensentaal”
Onthoud hierbij dat het overlegplaatjes zijn… gebruik niet teveel programmeertaal. Dat CMD staat voor commando is nog net uitlegbaar aan de Opdrachtgever… boolean expressies, etc zijn geschikter voor een uitvoeringsontwerp.
| Zijn de STDs correct? (bron:http://wawewi.com/cover/lcdeel4.html) |
| 1.Heeft het state-transition diagram één en slechts één initiële status? |
| 2. Als het state-transition diagram een open-loop is, is er minstens één eindstaat? |
| 3. Als het state-transition diagram een closed-loop is, is het diagram het werkelijk? (Bijna allen zijn ze eigenlijk open-loop) |
| 4. Heeft elke status minstens één uitgangsovergang? |
| 5. Als er meervoudige guards voor één enkele gebeurtenis bestaan, sluiten de guards elkaar uit? |
| 6. Heeft elke status precies één overgang voor elke mogelijke gebeurtenis-guard combinatie? |
| 7. Zijn alle overtollige of dubbele statussen of overgangen verwijderd? |
| 8. Zijn alle statussen bereikbaar? |
| 9. Wordt elke “echte” status in de wereld vertegenwoordigd door één en slechts één status op het diagram? |
| 10. Worden elke status en overgang duidelijk benoemd? |
| 11. Zijn alle mogelijke wegen ook geldige wegen? |
| 12. Worden alle geldige wegen vertegenwoordigd? |
Zoals je kunt zien, kun je op basis van deze analyse concluderen dat er nog een hoop informatie aangevuld moet worden. Wat moet er gebeuren bijvoorbeeld gebeuren als de deur weer dicht gaat?
Hier begint de speurtocht in het contract… je kunt verwachten dat er meer eisen te vinden zijn die iets over de werking van de vluchtdeur en de motor zeggen. Zorg ook voor domeinkennis, zoals de adviezen van een werktuigbouwkundige specialist.. Deze kan bijvoorbeeld aandragen dat de motor een looptijdbewaking nodig heeft.
En dan komt het aan op lijstjes: Maakt voor overzicht van statussen, gebeurtenissen, guards, overgangen, en acties die benodigd zijn voor een correct state-transition diagram in lijst: Geef per item aan of de informatie Bekend, Onbekend of een Aanname is.
4 Prioriteer welke informatie wel/ niet / als eerste besproken moet worden
Wat is de impact van onzekerheid op het ontwerp? Nu je deze lijstjes hebt kun je gaan prioriteren… vaak is het onnodig om alles stante pede ingevuld te krijgen… Tijdens een BID-fase wil je vaak de meest risicovolle en prijsbepalende gaten bespreken, aan het einde van de Definitief Ontwerpfase wil je alle overgangen compleet hebben. Ook verdient het de aanbeveling om de items slim te bundelen, bijvoorbeeld per discipline of per stakeholder.
5 Bepaal bij wie ontbrekende informatie gehaald moet worden en wie mandaat heeft om beslissingen te nemen
Vaak zijn er vele stakeholders betrokken om invulling te geven bij het complimenteren van de eisen. Het honoreren van de eisen via het Verzoek tot Wijzigingen proces is vaak een complex gebeuren, zeker wanneer de meningen verdeeld zijn. Weet dus wie voor welke onderwerpen aan de lat staat en bij wie je kunt escaleren als beslissingen uit blijven.
In dit voorbeeld: Vanuit een stakeholderoverleg komt naar voren dat de motor weer ingeschakeld dient te worden wanneer de vluchtdeur dicht is en dit wordt vastgelegd in Ontwerpbeslissing 001. De Project Manager van de Opdrachtgever geeft goedkeuring voor deze aanpak via VTW-018.
6 Leg de traceerbaarheid vast
Door uiteindelijk in het definitief ontwerp de eisen, ontwerpbeslissingen en VTWs te koppelen is het duidelijk voor de lezer waarop het ontwerp gebaseerd is en kan wanneer hij/zij dat nodig acht deze informatie opzoeken. Dan zou het ontwerp er voor de vluchtdeur als volgt uitzien.
| Eis-0765Ontwerpbeslissing-001VTW-018 |
Dit plaatje laat zien dat er wel meer getoetst dient te worden dan “Deur open, motor af: Check!” . Dat betekent een toevoeging van test- toets- en keuringsactiviteiten in de WBS en die toevoeging zal ook een invloed hebben op geld, tijd, en organisatie.
Overpeinzing
Moet je de eisen complementeren met eisen om verificatie en validatie mogelijk te maken? Als je het mij vraagt: Liever niet… Het zorgt er alleen maar voor dat kennis en overzicht weer opgeknipt wordt in woorden. Daarnaast, eisen laten zich niet beprijzen. Activiteiten en producten die je identificeert door de eisenanalyse wel. Juist met de ontwerpschets heb je de eisen al gecomplementeerd!
Mij lijkt het daarom zinvoller om het State Transition Diagram geaccepteerd te krijgen door de relevante stakeholders en vervolgens mee te nemen als uitgangspunt. Laat juist het State Transition Diagram belangrijke ingangsinformatie voor de verificatie- en validatieplannen zijn in plaats van de eisen.
Conclusie, boodschap
Wat met dit voorbeeld naar voren komt is dat verificatie en validatie op basis van enkel de gespecificeerde eisen eigenlijk onzinnig is, omdat je alleen maar toetst of je de eis goed geïnterpreteerd hebt. En dat is niet genoeg om het hogere doel van het verificatie- en validatieproces te bereiken;
- Een integraal werkend systeem dat aansluit op de behoefte van de Opdrachtgever;
- Voorspelbare beheersaspecten (Geld, Organisatie, Tijd, Informatie, Kwaliteit) voor de Opdrachtnemer/Gegadigde
Juist door de synthese tussen eisen in krachtige ontwerpschetsen vast te leggen (bijvoorbeeld met een state transition diagram) kom je veel eerder tot inzichten of de specificatie volledig en juist is. De synthese vormt het fundament om al in een vroeg stadium projectactiviteiten en risico’s te identificeren, waarmee je nauwkeuriger je project kunt beheersen.