Skip to content

Agile life cycle model voor procesontwikkeling in de gereguleerde omgeving

8 november 2014

kwaliteitsmanagement

Traditioneel wordt in de gereguleerde sectoren, zoals de medische hulpmiddelen, geneesmiddelen en levensmiddelen industrie, gebruik gemaakt van de waterval methode of het v-model voor de ontwikkeling en validatie van zowel de producten als de productieprocessen waarmee deze producten worden gefabriceerd. In deze modellen wordt gewerkt naar het zo vroeg mogelijk specificeren van het gewenste eindresultaat en deze vervolgens in een single pass te ontwikkelen en valideren. Deze modellen zijn overzichtelijk en eenvoudig te begrijpen. Maar de ervaring leert dat bij complexe projecten deze modellen maar zeer beperkte waarde hebben. Bij complexe projecten worden niet alle onderdelen van het systeem tegegelijk ontwikkeld. Ook is het moeilijk alle wensen aan het begin van het project te definiëren. Naarmate het systeem duidelijker wordt en de risico’s bekend raken komen ook nieuwe eisen in beeld.

De software sector maakt steeds meer gebruik van iteratieve en incrementele ontwikkelmodellen zoals de Agile methode. In deze blog hoop ik duidelijk te maken dat deze methode breder bruikbaar is en ook kan worden toegepast op productontwikkeling, de ontwikkeling van productieprocessen en de daarbij gebruikte apparatuur. Sterker nog, het wordt al gehanteerd, maar niet als zodanig herkend en erkend.

Bij de incrementele aanpak wordt het hele project in puzzelstukjes opgedeeld. Elk puzzelstukje wordt afzonderlijk ontwikkeld en getest, waarna het systeem wordt samengesteld. Vervolgens wordt dit samenstel gevalideerd. Deze opzet is goed toepasbaar bij de ontwikkeling van productieprocessen. Elke bewerkingsstap in het productieproces kan als een afzonderlijk puzzelstukje worden gezien. Hierdoor wordt de complexiteit van elk subproject beduidend geringer. De apparatuur die voor elke bewerkingsstap wordt gebruikt kan dan eventueel door middel van het bekende v-model worden ontwikkeld.

Bij de iteratieve aanpak wordt in stapjes naar de definitieve eindoplossing gewerkt. Er wordt van grof naar fijn gewerkt. Je maakt eerst een grof model van de eindoplossing. Vervolgens test je de oplossingsrichting op zijn bruikbaarheid. Deze engineering testen geven inzicht in de benodigde vervolgstappen die nodig zijn om tot de definitieve geschikte oplossing te komen. De oplossingsrichting kan voortdurend worden bijgesteld. Maar er is ook ruimte om het einddoel te wijzigen. De iteratieve aanpak geeft de meeste vrijheid en flexibiliteit, wat ook wel weer als nadeel kan werken. Sommige ontwikkelaars zullen nooit bij hun einddoel aankomen, omdat ze het maar steeds verleggen. De iteratieve aanpak wordt vaak al wel toegepast in de conceptfase van productontwikkelingen, maar in de Agile methode wordt het nog verder doorgevoerd.

Mythes
Er zijn enkele hardnekkige mythes waardoor de gereguleerde industrie blijft vasthouden aan de vertrouwde levenscyclusmodellen: de waterval methode en het v-model.

Ten eerste gelooft men dat verificatie en validatie moet plaatsvinden nadat de ontwikkeling van het product, het proces of de installatie is voltooid. Voor een deel is dat waar. Wijzigingen in het eindresultaat maken dat voorgaande testresultaten hun geldigheid verliezen. Met name bij de iteratieve aanpak zul je ervoor moeten waken dat alle functionaliteiten van het definitieve ontwerp zijn getest. Dat wil niet zeggen dat deze testen niet in verschillende fases of iteraties van het ontwikkelproces kunnen hebben plaatsgevonden. Mits je het maar verantwoordt. Feitelijk wordt er nu al veel getest tijdens de ontwikkeling, de zogenaamde ontwerpkwalificatie (design qualification, DQ), maar noemen we dat engineering studies of design of experiments in plaats van kwalificatie, verificatie of validatie. Spijtig genoeg wordt de waarde van de resultaten van deze experimenten ook zwaar onderschat en worden de experimenten en de resultaten onvoldoende vastgelegd om als bewijs voor validatie van het ontwerp te kunnen worden gebruikt. Een enorme verspilling van tijd en geld. Ook kom ik regelmatig tegen dat er in de ontwikkelfase te weinig aan ontwerpkwalificatie wordt gedaan. De rekening hiervan, gebrek aan inzicht in de geschiktheid van de eindoplossing, wordt gepresenteerd tijdens de verificatie en validatie aan het einde van het project. Dan blijken functionaliteiten niet naar behoren te werken en falen de testen. En dat in een fase waarin de engineers eigenlijk geen behoefte meer hebben aan het uitontwikkelen van het systeem. Met andere woorden, een bron van frustraties.

Een tweede mythe is dat de FDA de waterval methode voorschrijft. De waterval methode wordt inderdaad in de FDA richtlijn Design Control Guidance for Medical Device Manufacturers uit 1997 beschreven. Maar het is slecht een richtlijn en geen verplichting. Sterker nog, in dezelfde richtlijn geeft de FDA aan dat de waterval methode slechts beperkte waarde heeft ten opzichte van agile methodes (in de richtlijn concurrent engineering genoemd):

Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited. The model does apply to the development of some simpler devices. However, for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry

In geen enkele wet en regelgeving, EU of FDA, staat dat de verificatie en validatie uitsluitend aan het einde van het project moeten plaatsvinden.

Een derde mythe is dat risicomanagement geen onderdeel vormt van de Agile methode. De Agile methode introduceert juist meer projectrisico’s. Als de koers of het einddoel wijzigt, wijzigen ook de risico’s. Er bestaat ook het risico dat de ontwikkelde onderdelen bij een incrementele aanpak niet op elkaar aansluiten. Met andere woorden, risicomanagement is in de Agile methode nog meer van belang om problemen te voorkomen. Maar door de stapsgewijze aanpak krijgt men ook steeds meer inzicht in de risico’s. Risicoanalyse moet dus plaatsvinden voor elke increment en voor elke iteratie in het project. De risicomanagementnorm ISO 14971 onderschrijft dat ook:

Risk can be introduced throughout the product lifecycle, and risks that become apparent at one point in the life-cycle can be managed by action taken at a completely different point in the life cycle.

Agile maakt gebruik van zogenaamde user stories voor het vaststellen van de gebruikerseisen. Dat was ook één van de uitgangspunten voor de ontwikkeling van de Agile methode: voortdurende focus op de wensen van de gebruiker, zodat deze op effectieve wijze het eindproduct ontvangt waarom hij heeft gevraagd, of niet heeft gevraagd, maar wel op had gehoopt. Het mooie van de iteratieve aanpak is ook dat de gebruikerswensen aan de hand van de concepten en tussenoplossingen steeds duidelijker en vollediger worden. Een vaak in de medische hulpmiddelen gehanteerde methode is ook de Six Sigma aanpak. Deze kent ook een Voice of the Customer, en kent daar ook enorm veel waarde aan toe. Maar de Voice of the Customer analyse is vooral een activiteit die aan het begin van het project plaats vindt. De Agile aanpak stimuleert de continue inbreng van de gebruiker. Dat dit noodzakelijk is, is wel gebleken uit het eerste Laboratorium Informatie Management Systeem implementatie project waarin ik in de eindfase betrokken werd. Hierbij waren de gebruikers en de ontwikkelaars elkaar uit het oog verloren. De conclusie van de gebruikers was: “We hebben een Rolls Roys gekregen en we duwen hem nu van A naar B.”

Een andere mythe is dat Agile alleen gebruik maakt van de user stories. Al is het een vrije methode, het betekent niet dat eisen vanuit wet- en regelgeving niet kunnen en moeten worden meegenomen. De aanpak is vrij, maar uiteindelijk zal overeenstemming met de wettelijke eisen ook een gebruikerseis zijn. Dat geldt zelfs voor software ontwikkeling: een geautomatiseerd systeem dat niet voldoet aan 21 CFR part 11: de Amerikaanse wet voor elektronische records en elektronische handtekening is onbruikbaar voor de gebruiker in de gereguleerde sectoren. Dat zal in zijn user story dus wel degelijk op enig moment naar voren komen.

En dan als laatste de mythe die graag door de kwaliteitsmanagers wordt gepredikt: Agile is ongedisciplineerd en onverenigbaar met kwaliteitsmanagement. De mythe van Agile als “cowboy codering” of “eerst maken en dan vragen stellen” is altijd populair, maar verre van waar. Ik heb al eerder aangegeven dat er feitelijk al heel veel kenmerken van Agile in de huidige werkwijze worden gehanteerd. Door deze te herkennen en te erkennen worden ze zichtbaarder en kunnen zelfs beter met behulp van kwaliteitsmanagement methodieken worden beheerst. Planning, requirements engineering, ontwerp specificatie, testen en validatie zijn allemaal onderdeel van het Agile proces, met dat verschil dat herhalingen en verdeling het proces in kleinere stappen opdeelt. Agile is ontworpen om feedback vroeg en vaak in de loop van ontwikkelproces te krijgen en te gebruiken om het projectresultaat voortdurend te verbeteren. Deze aanpak zorgt juist voor een grotere transparantie en controle van het ontwikkelingsproces dan de traditionele single pass methodes.

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers liken dit: