LEAN zijn in gereguleerde ontwikkeling

Hoewel iteratieve ontwikkeling goed ingeburgerd is als een waardevolle werkmethode, hebben organisaties in gereguleerde sectoren (zoals automotive en de gezondheidszorg) nog steeds moeite om er ten volle van te profiteren. ICT Improve heeft meer dan tien jaar ervaring in het toepassen van iteratieve ontwikkeling in gereguleerde omgevingen. In deze insight delen onze experts de meest voorkomende problemen waarmee zij te maken hebben gekregen en de oplossingen die hebben geholpen deze te overwinnen. Om efficiënter en effectiever te worden, net zoals onze klanten. Het onderwerp van vandaag: het elimineren van verspilling die wordt veroorzaakt door alle eisen gelijk te behandelen.

Iedereen die ooit in een sterk gereguleerde omgeving heeft gewerkt, kent de pijn die gepaard gaat met de mate van controle die op elke beweging wordt geplaatst, en hoe die regels soms draconisch kunnen worden. Hierdoor wordt ons vermogen ons werk te doen geschaad, in plaats van dat het ons helpt veilige en effectieve producten te bouwen. Een gebied waar we hebben gezien dat organisaties het kind met het spreekwoordelijke badwater weggooien, is bij het schrijven van requirements en hoe daarmee om te gaan.

Om duidelijk te maken wat we bedoelen, bezoeken we enkele voorbeelden die we in de echte wereld zijn tegengekomen. Deze voorbeelden lijken misschien triviaal, maar leidden uiteindelijk tot aanzienlijke tijdverspilling aan verificatie (en documentatie), omdat de organisatie niet goed nadacht over de reden waarom deze vereisten werden gedefinieerd. Want het blijkt dat niet alle eisen gelijk zijn...

"De software moet worden ontwikkeld in overeenstemming met ISO 62304"

Ons eerste voorbeeld gaat over een organisatie die in hun systeemeisen heeft opgenomen dat de software ontwikkeld had moeten zijn in overeenstemming met ISO 62304. Op het eerste gezicht niets vreemds voor de ontwikkeling van medische hulpmiddelen, aangezien het een standaard beschrijft voor de ontwikkeling hiervan.

Totdat u zich realiseert dat de eis is gedefinieerd in een document  met systeemvereisten. Terwijl de norm van toepassing is op het gehele ontwikkelproces. Verificatie van systeemvereisten vindt plaats tijdens de verificatiefase, maar die fase is niet het einde van dat proces. Of om het te visualiseren:

Het resultaat van deze mismatch was dat er veel moeite werd gestoken tussen QA en verificatie om te bespreken hoe het bewijs kon worden gecreëerd dat nodig was voor de verificatie ervan. In het ergste geval was het idee om een defect te creëren dat de kloof tijdens de systeemverificatie beschreef, dat open te laten met een formeel gedocumenteerde uitleg waarom de gerelateerde mislukte test de overgang naar de volgende ontwikkelingsfase niet blokkeerde, en het open defect aan het einde van de ontwikkeling te "repareren" door een addendum bij het testrapport te schrijven waarin we het resterende vereiste verificatiebewijs leveren ...

"De kleur van het systeem moet groen RAL 6019 zijn"

Een ander voorbeeld uit de praktijk was een systeemeis waarin stond dat de kleur van het systeem groen RAL 6019 moest zijn.

Hoewel de eis SMART is, heeft het toch tot veel discussie geleid. Sommige mensen pleitten ervoor om de stuklijst van het apparaat te verifiëren om te zien welke verf werd gebruikt. Anderen voerden aan dat dit niet genoeg zou zijn om te bewijzen dat het systeem aan de eis voldeed, omdat het gebruik van een bepaalde kleur niet noodzakelijkerwijs betekent dat het systeem die kleur heeft. Dit mondde uit in een discussie over precisie, de impact van omstandigheden (voorwaardelijke verlichting) en of we niet gewoon een professioneel lab moeten inhuren om het te meten. Die zijn echter duur en tijdrovend, en hoe zouden we de logistiek aanpakken? Op dit punt begonnen sommigen van ons zich af te vragen: maken we de dingen niet veel moeilijker dan nodig is? Wat – je raadt het al – tot nog meer discussie leidde...

"Bruikbaar onderdeel X moet een levensduur hebben van X jaar"

Ons laatste voorbeeld verwijst naar een bruikbaar onderdeel dat een levensduur van een bepaald aantal jaren nodig heeft. Nogmaals: een soort vereiste die velen van ons met ervaring in hardwareontwikkeling verwachten te zien - we willen allemaal hardware die beperkt onderhoud vereist en dat onderhoud voorspelbaar is. Het is dus logisch om iets te schrijven over de betrouwbaarheid van die onderdelen.

Zelfs als we het probleem met de formulering negeren (X jaar met welke waarschijnlijkheid?), zal het bewijzen van enige vorm van betrouwbaarheidscijfers aanzienlijke inspanningen vergen. Zelfs als we statistische significantie uit het raam gooien en een steekproefomvang van 1 gebruiken, overschaduwt de tijd die nodig is om de gespecificeerde belasting (x jaar) te bereiken de tijd die beschikbaar is voor formele ontwerpverificatie. Dus wat nu? Mislukte test, defect en aanvullende documentatie over waarom het niet voldoen aan deze vereiste de voortgang niet blokkeert? Deze kan niet met terugwerkende kracht worden opgelost wanneer we het einde van de ontwikkeling bereiken, dus moeten we dan gewoon een mislukte vereiste accepteren in onze formele indiening? Klinkt als een vreselijk plan, maar wat is het alternatief?

Niet alle vereisten zijn gelijk

De gegeven voorbeelden zijn praktische demonstraties van wat er gebeurt bij het maken van vereisten zonder goed rekening te houden met de context. In plaats van de manier waarop we vereisten behandelen aan te passen op basis van hun doel en context, behandelen we ze allemaal als gelijken: hetzelfde niveau van controle, in dezelfde ontwikkelingsfase, geverifieerd door dezelfde mensen.

In werkelijkheid kan het doel van vereisten sterk variëren, en bij elk doel is een andere aanpak en een ander niveau van controle vereist. Op basis van onze ervaringen stellen we voor om drie expliciete categorisaties van vereisten te maken, elk met zijn eigen specifieke kenmerken:

• Productvereisten 
  Vereisten die het beoogde gebruik van een product definiëren of de beoordeling ondersteunen of het product veilig en effectief is in het gebruik ervan. Met andere woorden, het beschrijft aspecten van het product die relevant zijn voor formele documentatie. Productvereisten maken deel uit van de formele documentatie en hun verificatie- en validatiedekking is verplicht. Productvereisten worden formeel 'all the way' behandeld (volledige wijzigingscontrole, volledige tracering, volledige verificatie en validatie).
• Procesvereisten 
  Vereisten die worden opgelegd door wettelijke richtlijnen en die betrekking hebben op processen die overal in de levenscyclus van het product van toepassing zijn. Met andere woorden, het beschrijft aspecten van het proces die relevant zijn voor het maken en onderhouden van formele documentatie. Procesvereisten maken deel uit van de formele documentatie, maar worden geverifieerd en gevalideerd buiten het bereik van ontwerpconformiteit (of testen). In plaats daarvan wordt de naleving ervan bewezen door Quality Assurance en/of de afdeling Regulatory Affairs.
• Zakelijke vereisten
  Vereisten die een kenmerk of mogelijkheid beschrijven die niet voldoet aan de definitie van een productvereiste en - indien weggelaten - kunnen leiden tot ontwikkeling die een economisch niet-levensvatbaar product creëert. Zakelijke vereisten zijn optioneel voor formele documentatie, maar kunnen op verzoek worden beoordeeld. Verificatie en validatie worden aangemoedigd, maar zijn optioneel (dus formeel niet verplicht).

Laten we, met deze categorisaties in gedachten, onze voorbeelden opnieuw bekijken om te zien wat er zou zijn veranderd als we deze categorisaties vanaf het begin hadden toegepast en onze aanpak dienovereenkomstig hadden aangepast:

Het voorbeeld van het voldoen aan een bepaalde wettelijke norm past in de categorie van een procesvereiste. In plaats van te proberen een vierkante pin in een rond gat te forceren, had de vereiste uit de systeemvereisten moeten worden verwijderd en naar de juiste QA- en regelgevingsdocumenten moeten worden verplaatst. Dit elimineert de noodzaak van aanvullende documentatie en zorgt er ook voor dat verificatie wordt overgelaten aan de QA- en regelgevingsexperts.

Het voorbeeld van de kleur van het apparaat vereist het beantwoorden van een aanvullende vraag: aan welke behoeften wordt voldaan door het apparaat een bepaalde kleur te geven? In ons voorbeeld ging het uiteindelijk om branding: de kleur was belangrijk omdat het aansloot bij het kleurenschema van het bedrijf als geheel. Als zodanig wordt de vereiste een zakelijke vereiste, waardoor de hele basis waarop de dingen ingewikkeld werden, betwistbaar wordt. Aangezien de veiligheid en effectiviteit van het apparaat niet afhankelijk zijn van de kleur, zou een eenvoudige stuklijstcontrole of zelfs een subjectieve, visuele controle door het bedrijf voldoende zijn. Bovendien hoeft de test niet te worden opgenomen in het (formele) verificatiebewijs, waardoor het een zeer minimale inspanning vereist.

De levensduur van het bruikbare onderdeel is om vergelijkbare redenen ook een zakelijke vereiste. Natuurlijk moet een apparaat betrouwbaar genoeg zijn om veilig en effectief te zijn, maar dat wordt impliciet afgedekt tijdens de validatie. Het zou passender zijn om deze eis te zien als een manier om de economische levensvatbaarheid te waarborgen. Door de vereiste te classificeren als een zakelijke vereiste, kan de diepgaande verificatie plaatsvinden na de marktintroductie, waardoor de vereiste meer een intentie wordt waarmee tijdens de ontwikkeling rekening moet worden gehouden en die kan worden geverifieerd met meer subjectieve middelen, buiten het toezicht van regelgevende instanties om.

Conclusie

Zoals u kunt zien, had het toepassen van de categorisering van vereisten de inspanning die aan deze vereisten wordt besteed gemakkelijk kunnen verminderen, wat lagere kosten en snellere levering betekent. Als bonus: je hebt een beter overzicht van je wensen en het indieningsproces verloopt veel soepeler. Zoals in de inleiding vermeld, zou je dit allemaal als voor de hand liggend en triviaal kunnen beschouwen, maar in de praktijk is het dat niet.

Zoals gezegd: deze voorbeelden zijn allemaal praktijkvoorbeelden van uitdagingen die we bij klanten hebben gezien. Ongeacht uw mening over hoe de vereisten in eerste instantie werden behandeld, was het de introductie van deze categorieën die hielp om de gesprekken binnen die organisaties in goede banen te leiden. En de hoeveelheid bespaarde moeite is ook niet te versmaden. Bijvoorbeeld: bij één klant resulteerde deze categorisering van eisen in een reductie van eisen in de reikwijdte van formele verificatie en indiening (d.w.z. de eisen die de meeste inspanning kosten en het hardst worden onderzocht) van ca. 200 naar ca. 60. Het blijkt dat gelijkheid soms gewoon niet het antwoord is. 

Geschreven door Johan van Berkel en Patrick Duisters