Productintegratie, een kwestie van strakke procedures

8 december 2011

Philips’ ontwikkelgroepen voor de medische MRI-scanners zitten verspreid over de aardbol en moeten op een goed moment hun componenten integreren in een werkend systeem. Om dit soepel te laten verlopen en naar de autoriteiten aan te tonen dat dit verantwoord gebeurt, zijn goede procedures met component-, integratie- en regressietests en een uitgebreide testomgeving beschikbaar.

Productontwikkeling bij de businessunit voor MRI-systemen van Philips is gebaseerd op een evolutionaire aanpak: nieuwe generaties MRI-apparaten worden gebouwd op bestaande versies als platform. Multidisciplinaire teams over heel de wereld zijn betrokken bij de ontwikkeling, integratie en verificatie van nieuwe systemen. Tijdens de ontwikkel- en integratiefase worden nieuwe versies van productcomponenten ontwikkeld en vervolgens geïntegreerd in een functionerend MRI-apparaat. Tijdens deze fase zijn allerlei ontwikkelgroepen gelijktijdig bezig met het ontwerpen, implementeren en testen van hun componenten.

Om de ontwikkelgroepen over de wereld effectief te laten samenwerken en om te zorgen dat de nieuwe productcomponenten functioneren zoals ontworpen, hebben we een systematische integratieaanpak ontwikkeld. Ook zijn er werkinstructies en documentvoorbeelden beschikbaar om de integratievolgorde, integratietestplannen en testrapportages te documenteren. Om aan de strikte regelgeving in de medische industrie te voldoen, is dit vastgelegd in het kwaliteitssysteem van onze businessunit. Hierin staan alle procedures bij het ontwikkelen van de apparatuur beschreven. Door deze processen te volgen, kunnen we nieuwe MRI-apparatuur laten certificeren door de bevoegde instanties.

Contract

Ter voorbereiding van een integratiestap moeten we de logische volgorde vastleggen waarin de verschillende versies van de componenten worden toegevoegd. De productarchitectuur speelt hierbij een grote rol. Deze is generiek voor alle MRI-scanners van Philips en biedt een gedeeld vocabulaire om van elke component de functie, externe interfaces en interacties vast te leggen. Er zijn vele factoren die de integratievolgorde beïnvloeden, zoals complexiteit van de component, onderlinge afhankelijkheden, kwaliteitskritieke aspecten, levertijden en hoeveelheid werk. In een schematisch integratieplan beschrijven we elke versie van elke component en elke integratiestap, met bijbehorende redenering en bijbehorend testplan.

De verantwoordelijkheid voor de componenten ligt bij de groepsleiders. Zij maken de plannen om nieuwe versies te ontwerpen, te implementeren en te testen. Zij zijn ook verantwoordelijk voor de kwaliteit van de componenten. Het schematische integratieplan komt dan ook tot stand in nauwe samenwerking met de groepsleiders en dient als contract tussen de ontwikkelgroepen en het project. Dit plan wordt periodiek bekeken en aangepast om de laatste inzichten en de status van nieuwe productcomponenten te verwerken.

Ontwikkelgroepen verspreid over de wereld werken samen aan opeenvolgende generaties van Philips’ MRI-scanners. Om de integratie aantoonbaar in goede banen te leiden, zijn er strakke procedures opgesteld.

Voor sommige componenten zal de integratie elke keer hetzelfde zijn. Een nieuwe versterker die de bestaande interfaces volgt, zal bijvoorbeeld altijd in dezelfde volgorde worden geïntegreerd. Een deel van het schematische integratieplan is dus herbruikbaar voor toekomstige ontwikkelprojecten.

Het aantal integraties ligt steeds tussen de tien en honderd. Om de doorlooptijd te beperken, is het daarom noodzakelijk goede afspraken te maken over leveringen van componenten en integraties. De component- en de integratieplanning moeten in de pas lopen. We stemmen ze dan ook periodiek op elkaar af.

Vertraging

Om de kwaliteit van het evoluerende systeem te kunnen waarborgen, is het belangrijk om integratietests uit te voeren. De ontwikkelgroepen testen zelf al de componenten in isolatie, waarbij externe interfaces worden gesimuleerd. Bij integratietests ligt de nadruk echter op de externe interfaces en interacties met andere componenten. Deze tests worden geïnitieerd door de projectleider. Om voor voldoende dekking te zorgen, stemmen we de groeps- en integratietestplannen wel op elkaar af.

De integratietests leggen we bij elke component vast in het testplan. Dit beschrijft globaal het doel van de integratietest en welke aspecten specifiek moeten worden beschouwd. Voordat de nieuwe versies van componenten daadwerkelijk worden geïntegreerd, vindt er een ingangscontrole plaats: samen met de groepsleider wordt er een checklist doorlopen met criteria zoals compleetheid, bekende problemen en beschikbaarheid van testcases en -omgeving. Als de component niet slaagt voor deze test, kan dat vertraging of een aanpassing van de integratievolgorde betekenen. De groepsleiders rapporteren periodiek voortgang van de geplande componentleveringen en nemen corrigerende acties indien de planning niet wordt gehaald. Via dashboards wordt deze status naar bijvoorbeeld het management gecommuniceerd.

Essentieel bij integratietests is dat nieuwe versies van componenten kunnen worden uitgeprobeerd in een functioneel MRI-apparaat, vergelijkbaar met de ziekenhuisomgeving. De ontwikkelorganisatie heeft daarvoor de beschikking over diverse MRI-systemen, verspreid over de wereld. Die worden dagelijks onderhouden door speciaal opgeleid personeel. Dit biedt unieke mogelijkheden om gedurende het hele ontwikkelproject een grote variëteit aan configuraties in te zetten.

Tijdens de ontwikkelfase zijn er dus verschillende tijdelijke versies van het MRI-apparaat. Naast integratietests ondergaat elk van deze versies een reeks regressietests om de momentane kwaliteit van het apparaat te meten. Afhankelijk van die uitkomst kunnen preverificatietests worden uitgevoerd. Op die manier krijgen we al snel inzicht in de dekking van de technische eisen en kunnen we fouten snel vinden.

Bewijslast

Deze systematische manier van werken hebben we toegepast in een klein en in een groot ontwikkelproject. Daaruit kwamen wel wat punten naar voren. Vanuit technisch oogpunt zijn interfaces van productcomponenten weliswaar gedocumenteerd, maar is er geen standaard set van interfacetests beschikbaar. Dat betekent veelvuldig overleg met ontwikkelgroepen bij het vastleggen van integratietests. Vanuit organisatorisch oogpunt is het soms moeilijk om afspraken te maken over leveringen van nieuwe versies van productcomponenten. Ook zijn er in de huidige situatie slechts voor een deel van de interfaces traceerbare tests beschikbaar. Het streven is om dit in de toekomst te verbeteren; voor nieuwe interfaces nemen we deze traceerbaarheid al mee bij het ontwerpen en documenteren van nieuwe tests.

Desondanks levert de systematische aanpak nieuwe versies van de MRI-apparatuur op waarvan de kwaliteit beter bepaald en beter gecontroleerd kan worden tijdens het ontwikkelproces. Ook levert deze manier systematische testplannen en testrapportages op. De testrapportages kunnen dienen als bewijslast voor de certificeringsinstanties. Verder kunnen we de gedocumenteerde processtappen gebruiken om aan te tonen dat het ontwikkelproces conform internationale standaarden is verlopen. Dit levert een essentiële bijdrage aan de vrijgave van nieuwe versies van Philips’ MRI-apparaten.

Godfried Webers is architect bij Philips Healthcare - MR.

Godfried Webers

Terug naar overzicht