Wat is het verschil tussen een operationele kwalificatie (OQ) en een prestatiekwalificatie (PQ)?


Antwoord 1:

Om te citeren uit Medical Product Regulatory Affairs: Pharmaceuticals, Diagnostics, Medical Devices: John J. Tobin, Gary Walsh: 9783527318773: Amazon.com: Books, page 225:

De validatie van nieuwe faciliteiten, systemen of apparatuur wordt meestal uitgevoerd met behulp van een proces in vier fasen van ontwerpkwalificatie (DQ), installatiekwalificatie (IQ), operationele kwalificatie (OQ) en prestatiekwalificatie (PQ).

Ontwerpkwalificatie is het meest relevant voor systemen waarbij gebruik op maat wordt gemaakt, zoals de faciliteiten zelf, waarbij moet worden aangetoond dat het ontwerp voldoet aan de GMP-vereisten. Voor eenvoudiger kant-en-klare apparatuur is het meestal alleen een kwestie van het selecteren van de juiste apparatuur voor het beoogde gebruik.

Installatie kwalificatie omvat het uitvoeren van controles om ervoor te zorgen dat de juiste apparatuur of systeem is geïnstalleerd en / of aangesloten, inclusief alle benodigde bedieningselementen, monitors, instrumentatie of ondersteunende diensten. Deze controles moeten verificatie omvatten dat relevante gebruikershandleidingen of instructies zijn ontvangen van de leverancier en dat eventuele toepasselijke kalibratiestappen zijn geïdentificeerd.

Operationele kwalificatie omvat het uitvoeren van een reeks tests om te controleren of alle elementen van het systeem functioneel zijn binnen het gespecificeerde werkbereik. Dit houdt meestal het uitvoeren van uitdagingen in het ergste geval in extreme bedrijfsomstandigheden. Het proces moet de bevestiging van de definitieve werking, onderhoud en kalibratieprocedures mogelijk maken.

Ten slotte wordt de prestatiekwalificatie uitgevoerd met behulp van de materialen en het bereik van de bedrijfsomstandigheden die bij normaal gebruik worden voorzien. Overweeg, bij wijze van voorbeeld, een nieuwe vullijn die een peristaltische pomp en slangen gebruikt om specifieke hoeveelheden vloeistof af te geven. De reproduceerbaarheid van het afgegeven volume kan worden beïnvloed door de grootte van de buis, de viscositeit van de vloeistof, veranderingen in de voedingslijndruk naarmate de hoogte van de reservoirtank daalt, of een verlies van elasticiteit van de buis naarmate deze ouder wordt. De prestatiekwalificatie moet aantonen dat door het gebruik van de juiste diameter slangen en pompsnelheden, een koptank om een ​​constante druktoevoer en gedefinieerde kalibratiecontrole en slangvervangingsintervallen te handhaven, het systeem de nodige procescapaciteit kan leveren om de gespecificeerde vultoleranties. Producten die representatief zijn voor lage en hoge viscositeit en kleine en grote vulvolumes zouden worden geselecteerd, en controles van de vulvolumes die worden afgeleverd gedurende een geschikte werkingsperiode zouden statistisch worden geanalyseerd.

En van ISO 13485: een complete gids voor kwaliteitsbeheer in de industrie voor medische apparatuur: 9781439866115: geneeskunde- en gezondheidswetenschappen Books @ Amazon.com-pagina's 224 en 230:

Operationele kwalificatieactiviteiten zijn een reeks acties en activiteiten met als doel door objectief bewijs te waarborgen dat alle procesoutputs en -resultaten voldoen aan de vooraf gedefinieerde specificaties en vereisten; dat is dat:

• De resultaten worden geaccepteerd onder de juiste productieomstandigheden.

• De resultaten worden geëvalueerd en vergeleken met goedgekeurde vooraf gedefinieerde criteria.

• De evaluatie biedt naleving van vereisten en specificaties.

Prestatie kwalificatie (PQ) -activiteiten zijn een reeks testactiviteiten die worden uitgevoerd nadat alle OQ-activiteiten zijn beoordeeld en goedgekeurd. Het doel van de PQ is om aan te tonen dat een proces producten of resultaten kan genereren die consistent voldoen aan alle specificaties in de loop van de tijd en wijzigingen. Verandering kan optreden als het veranderen van diensten, week-end shutdowns en het gebruik van verschillende operators. De procescapaciteit en stabiliteit werden vastgesteld en bereikt tijdens de OQ-fase. Het is nu noodzakelijk om deze voor de hele klus te verzekeren. Dit zal worden bereikt door het opzetten en uitvoeren van continue tests en gegevensanalyse totdat een voldoende betrouwbaarheidsniveau is bereikt.


Antwoord 2:

Ik ga dieper in op de fragmenten van de heer Keller met het gebruikersperspectief, voorbeelden en vergelijkingen van de verschillen tussen de Software Developer Company en de User Company. Ik ben nauw betrokken geweest bij het schrijven van al dit soort documenten. Eerst beantwoord ik het OQ-verschil met de PQ. Vervolgens ga ik dieper in op de andere documenten.

De OQ is uitgebreid om te 'bewijzen' dat de geïnstalleerde software werkt volgens het 'beoogde ontwerp' van de softwareontwikkelaars plus volgens het 'beoogde gebruik' van de gebruiker. Dit moet een stresstest bij maximale en minimale parameters omvatten, inclusief maximale beoogde werkbelasting. Ongeveer een vierde, maar niet meer dan een derde van de OQ wordt verondersteld te verifiëren dat de software ongeldige vermeldingen blokkeert. Voorbeelden: bewijzen dat het "oude wachtwoord" van een gebruiker de gebruiker niet toestaat de software te openen; bewijzen dat een veld dat is ontworpen om alleen cijfers te accepteren, een gebruiker belet letters in het veld in te voeren of op te slaan. Deze tests omvatten het verifiëren wanneer een foutmelding verschijnt. Als het foutbericht wordt verondersteld aan te geven wat de fout is, verifieer dat dan ook. Let op: u hoeft de exacte woorden of zin niet te verifiëren, omdat de nauwkeurigheid van de overgebrachte informatie de belangrijkste factor is. De OQ is meestal erg groot en duurt enkele dagen (of weken) om te voltooien. De OQ-tests kunnen worden uitgevoerd door een of meer van de getrainde peeople van het Gebruikersbedrijf - moesten formeel worden getraind op de software - of door aangewezen / beoogde gebruikers, of door een IT-persoon, of kunnen worden uitbesteed aan een aannemer die formeel is getraind in de software. De OQ MOET een grondige beveiligingstest omvatten volgens FDA's 21 CFR deel 11 en / of de EU-richtlijnen van Eudralex in bijlage 11. Die beveiligingsvereisten zijn van toepassing op GLP-, GMP- en GCP-omgevingen. Van belang is dat de OQ-tests moeten aantonen dat de software consistent, nauwkeurig, betrouwbaar en reproduceerbaarheid werkt. Als de software is gemaakt door een softwarebedrijf dat de software verkoopt als COTS (commercieel verkrijgbaar), moet de OQ alleen de functionele vereisten testen die het gebruikersbedrijf van plan is te gebruiken.

De PQ is aanzienlijk korter omdat deze bedoeld is om te controleren of de beoogde gebruiker (s) van het User Company - die met de software moeten werken als onderdeel van hun taken - tevreden zijn met de daadwerkelijke prestaties van de software. Het wordt verondersteld te verifiëren dat de geïnstalleerde software naar tevredenheid werkt op een "typische" test van bij "typisch tot iets groter" gebruik. Het is altijd het beste dat een groep gebruikers (of een zeer ervaren persoon die de software gaat gebruiken) de 'typische' test maakt. Deze test zou ook beveiligingstests moeten omvatten, te beginnen met de aanmelding bij de software. Deze PQ-tests worden verondersteld te worden uitgevoerd door een of meer daadwerkelijke gebruikers, en zoals elke OQ-tester, moet elke PQ-tester 'eerst' training hebben gehad in de software voordat de PQ-tests werden uitgevoerd. Het is niet de bedoeling dat de persoon (personen) die de PQ-tests uitvoert, wordt gecontracteerd met iemand buiten het gebruikersbedrijf, omdat alleen de daadwerkelijke gebruikers kunnen bepalen of de software echt voldoet aan hun behoeften en verlangens voor prestaties. Alleen de gebruikers kunnen aangeven of de software bevredigend is, en als een test naar verwachting binnen enkele minuten zal worden voltooid, maar het duurt een uur, dan zijn de gebruikers zeker niet tevreden met de prestaties en hoeven de gebruikers de sofware in die langzame staat. Ze kunnen van de IT-mensen en softwareontwikkelaars eisen dat ze de 'prestaties' verbeteren.

Zowel de OQ als de PQ testen de interactie en interoperabiliteit van meerdere functies - zodat het totale verwachte resultaat voldoet aan de behoeften van het gebruikersbedrijf. Dit verschilt sterk van "Eenheidstests" die hieronder worden uitgelegd.

Functionele vereisten is een term die verband houdt met de 'veronderstelde' vereisten van een softwareontwikkelaar voor de software die ze willen maken. Het softwarebedrijf heeft een doelmarkt en de softwareontwikkelaars "denken" aan alles wat ELK van hun gebruikers VEREIST, en ze KUNNEN enkele functies bevatten die de gebruikers MOETEN wensen (om hun software wenselijker te maken dan die van een concurrent). Elke functionele eis moet worden getest met een eenheidstest - voor die specifieke functie. Een eenheidstest test NIET de reeks functies. Voorbeeld: het test niet de mogelijkheid om geïmporteerde gegevens af te drukken, omdat het importproces een apart proces is. Ze hebben één test om te controleren of het importproces is uitgevoerd en of de geïmporteerde gegevens correct zijn. Een afzonderlijke test zal controleren of "welke gegevens dan ook" op een specifiek scherm kunnen worden afgedrukt en dat de afgedrukte gegevens juist zijn. De eenheidstests omvatten ook elke methode voor afdrukken, zoals het gebruik van een snelkoppeling voor een opdracht voor één test en een afzonderlijke test om een ​​menu te openen en een specifieke opdracht te selecteren om een ​​afdruk te maken.

De DQ legt uit hoe de softwareontwikkelaars van plan zijn de software te maken om elk van de functionele vereisten en alle verschillende methoden te realiseren. Het moet de normen vermelden die zijn gebruikt om het te maken, inclusief software- en / of hardwarestandaarden om de inhoud van het DQ-document gericht te houden op wat de ontwikkelaars van plan zijn anders of uniek te doen. Een gebruikersbedrijf mag alleen een DQ maken als het gebruikersbedrijf de software zelf maakt met zijn eigen werknemers of met aannemers die specifiek zijn ingehuurd om die ene softawre te maken.

De DQ wordt gebruikt voor twee situaties. Ten eerste, voor een software die "in-house" is ontwikkeld, wat betekent dat het een eigen software is die is gemaakt door het bedrijf en van plan is de software te gebruiken. Voor de eenvoud noem ik dit het gebruikersbedrijf. De tweede situatie is wanneer een gereguleerd bedrijf een spreadsheet maakt (bijvoorbeeld met behulp van Microsoft Excel). Het invoegen van de geprogrammeerde functies van Excel is een vorm van softwareprogrammering, een spreadsheet ontworpen om gegevens of tekst te importeren, te berekenen en om permanente tekst (zoals koppen) te hebben, maken allemaal deel uit van een vorm van "programmeren", waarvoor volledige validatie vereist is met alle validatiedocumenten (DQ, unit tests, IQ, OQ, PQ, samenvattingsrapporten, SOP's, gebruikersinstructies, enz.) Ik ben me niet bewust van softwareontwikkelingsbedrijven die spreadsheets voor hun klanten / gebruikersbedrijven maken, maar sommige ontwikkelaars kunnen dit nu doen. Dus de DQ is altijd een gereguleerd document dat is gebaseerd op de lijst van die softwareontwikkelaar met "waargenomen" functies die gebruikers nodig hebben en die ze wensen.

Het gebruikersbedrijf maakt een document met gebruikersvereisten, waarin alleen de PART de functionele vereisten van de softwareontwikkelaars wordt vermeld, omdat het gebruikersbedrijf weet dat het voornemens is met de software te doen. Er zijn meestal verschillende functies die een ser Company niet van plan is te gebruiken. Misschien is het beste voorbeeld dat ALLE Gebruikers Bedrijven verwachten dat de software elektronische records beveiliging biedt (vereist bijvoorbeeld een audit trail en de software blokkeert verwijdering of wijzigingen in de audit trail). Elektronicarecords vormen slechts een deel van deel 11 van de FDA en / of deel van de vereisten van bijlage 11 van de EU. Veel gebruikersbedrijven willen de functies van elektronische handtekeningen in software niet gebruiken. (Sommige gebruikersbedrijven bestempelen hun document met gebruikersvereisten als hun eigen functionele vereisten. De titel van de documenten is niet echt belangrijk - ik heb nog nooit een regulator gekend die de titel van een document betwist. Het is echter belangrijk dat het document duidelijk aangeeft dat vroeg in het document waarvoor het gebruikersbedrijf het document gebruikt.)

Het IQ is bedoeld als een reproduceerbare reeks hardware, besturingssysteem en andere softwarevereisten voor een server, laptop of desktopcomputer, gevolgd door een specifieke reeks acties en opton selecties om ervoor te zorgen dat ELKE software-installatie door één wordt uitgevoerd Gebruikersbedrijf is identiek aan elkaar. Wanneer het Gebruikersbedrijf de computer (s) moet leveren, wordt het IQ meestal aangepast voor elk Gebruikersbedrijf - of koopt het Gebruikersbedrijf meerdere identieke computers via (of met beoordeling door) de softwareontwikkelaar.

Wanneer de OQ en PQ VEEL overlappen, is het acceptabel om één gecombineerd OQ / PQ-document te produceren.

De traceerbaarheidsmatrix moet de 'eisen' van elk gebruikersbedrijf herleiden tot de IQ, OQ, PQ en / of SOP die aan de eis voldoet. Er kunnen verschillende teststappen nodig zijn om aan één "volledige" eis te voldoen.

Bedrijven voor softwareontwikkeling VRIJWILLIG INDUSTRIECERTIFICATEN. Deze certificeringen vereisen een verscheidenheid aan documentatie TIJDENS hun softwareontwikkeling, inclusief hun equivalent van een IQ en OQ. De ontwikkelaars hebben echter een grotere lijst met functies. Is het gebruikelijk dat deze bedrijven hun tests gebruiken om hun installatie- en gebruikershandleidingen te maken.

De gebruikersbedrijven gebruiken de IQ, OQ en / of PQ vaak voor het trainen van extra gebruikers, en soms maken gebruikersbedrijven snelle referentiegidsen of een aanvullende handleiding voor hun gebruikers.

Wanneer een gebruikersbedrijf een spreadsheet maakt, is het BESTE om deze tijdens de systeemvalidatie te maken. Een "systeem" kan alleen software zijn, alleen hardware, of een combinatie van software en hardware. De computerhardware kan zijn ingebed in het wetenschappelijke instrument, of het kan een afzonderlijke computer zijn waarop de software is geïnstalleerd. Bij het maken van een spreadsheet tijdens de systeemvalidatie kan het iets langer duren tijdens het validatieproces, maar het bespaart veel papierwerk en vertragingen voor gebruikers om hun werk op het werk te voltooien.

U kunt een alinea of ​​subsectie in het validatieplan van het systeem, gebruikersvereisten en OQ gebruiken om te labelen en te gebruiken als het validatieplan van de spreadsheet, DQ, gebruikersvereisten van de spreadsheet, het IQ en het OQ-testplan. (De vereiste spreadsheetinstructies kunnen in de spreadsheet worden geschreven, hetzij door de velden of op een afzonderlijk blad, of instructies kunnen in een afzonderlijk document worden geschreven. De vereiste spreadsheettraining kan één op één of in groepen worden gedaan, maar die training moet worden gedocumenteerd net zoals de training op het gevalideerde systeem moet worden gedocumenteerd). Het uiteindelijke resultaat is dat op het moment van “systeemvrijgave” aan gebruikers voor officieel werk op het werk, die gebruikers ONMIDDELLIJK een volledig gedocumenteerde en gevalideerde spreadsheet voor hun werk hebben.


Antwoord 3:

Ik ga dieper in op de fragmenten van de heer Keller met het gebruikersperspectief, voorbeelden en vergelijkingen van de verschillen tussen de Software Developer Company en de User Company. Ik ben nauw betrokken geweest bij het schrijven van al dit soort documenten. Eerst beantwoord ik het OQ-verschil met de PQ. Vervolgens ga ik dieper in op de andere documenten.

De OQ is uitgebreid om te 'bewijzen' dat de geïnstalleerde software werkt volgens het 'beoogde ontwerp' van de softwareontwikkelaars plus volgens het 'beoogde gebruik' van de gebruiker. Dit moet een stresstest bij maximale en minimale parameters omvatten, inclusief maximale beoogde werkbelasting. Ongeveer een vierde, maar niet meer dan een derde van de OQ wordt verondersteld te verifiëren dat de software ongeldige vermeldingen blokkeert. Voorbeelden: bewijzen dat het "oude wachtwoord" van een gebruiker de gebruiker niet toestaat de software te openen; bewijzen dat een veld dat is ontworpen om alleen cijfers te accepteren, een gebruiker belet letters in het veld in te voeren of op te slaan. Deze tests omvatten het verifiëren wanneer een foutmelding verschijnt. Als het foutbericht wordt verondersteld aan te geven wat de fout is, verifieer dat dan ook. Let op: u hoeft de exacte woorden of zin niet te verifiëren, omdat de nauwkeurigheid van de overgebrachte informatie de belangrijkste factor is. De OQ is meestal erg groot en duurt enkele dagen (of weken) om te voltooien. De OQ-tests kunnen worden uitgevoerd door een of meer van de getrainde peeople van het Gebruikersbedrijf - moesten formeel worden getraind op de software - of door aangewezen / beoogde gebruikers, of door een IT-persoon, of kunnen worden uitbesteed aan een aannemer die formeel is getraind in de software. De OQ MOET een grondige beveiligingstest omvatten volgens FDA's 21 CFR deel 11 en / of de EU-richtlijnen van Eudralex in bijlage 11. Die beveiligingsvereisten zijn van toepassing op GLP-, GMP- en GCP-omgevingen. Van belang is dat de OQ-tests moeten aantonen dat de software consistent, nauwkeurig, betrouwbaar en reproduceerbaarheid werkt. Als de software is gemaakt door een softwarebedrijf dat de software verkoopt als COTS (commercieel verkrijgbaar), moet de OQ alleen de functionele vereisten testen die het gebruikersbedrijf van plan is te gebruiken.

De PQ is aanzienlijk korter omdat deze bedoeld is om te controleren of de beoogde gebruiker (s) van het User Company - die met de software moeten werken als onderdeel van hun taken - tevreden zijn met de daadwerkelijke prestaties van de software. Het wordt verondersteld te verifiëren dat de geïnstalleerde software naar tevredenheid werkt op een "typische" test van bij "typisch tot iets groter" gebruik. Het is altijd het beste dat een groep gebruikers (of een zeer ervaren persoon die de software gaat gebruiken) de 'typische' test maakt. Deze test zou ook beveiligingstests moeten omvatten, te beginnen met de aanmelding bij de software. Deze PQ-tests worden verondersteld te worden uitgevoerd door een of meer daadwerkelijke gebruikers, en zoals elke OQ-tester, moet elke PQ-tester 'eerst' training hebben gehad in de software voordat de PQ-tests werden uitgevoerd. Het is niet de bedoeling dat de persoon (personen) die de PQ-tests uitvoert, wordt gecontracteerd met iemand buiten het gebruikersbedrijf, omdat alleen de daadwerkelijke gebruikers kunnen bepalen of de software echt voldoet aan hun behoeften en verlangens voor prestaties. Alleen de gebruikers kunnen aangeven of de software bevredigend is, en als een test naar verwachting binnen enkele minuten zal worden voltooid, maar het duurt een uur, dan zijn de gebruikers zeker niet tevreden met de prestaties en hoeven de gebruikers de sofware in die langzame staat. Ze kunnen van de IT-mensen en softwareontwikkelaars eisen dat ze de 'prestaties' verbeteren.

Zowel de OQ als de PQ testen de interactie en interoperabiliteit van meerdere functies - zodat het totale verwachte resultaat voldoet aan de behoeften van het gebruikersbedrijf. Dit verschilt sterk van "Eenheidstests" die hieronder worden uitgelegd.

Functionele vereisten is een term die verband houdt met de 'veronderstelde' vereisten van een softwareontwikkelaar voor de software die ze willen maken. Het softwarebedrijf heeft een doelmarkt en de softwareontwikkelaars "denken" aan alles wat ELK van hun gebruikers VEREIST, en ze KUNNEN enkele functies bevatten die de gebruikers MOETEN wensen (om hun software wenselijker te maken dan die van een concurrent). Elke functionele eis moet worden getest met een eenheidstest - voor die specifieke functie. Een eenheidstest test NIET de reeks functies. Voorbeeld: het test niet de mogelijkheid om geïmporteerde gegevens af te drukken, omdat het importproces een apart proces is. Ze hebben één test om te controleren of het importproces is uitgevoerd en of de geïmporteerde gegevens correct zijn. Een afzonderlijke test zal controleren of "welke gegevens dan ook" op een specifiek scherm kunnen worden afgedrukt en dat de afgedrukte gegevens juist zijn. De eenheidstests omvatten ook elke methode voor afdrukken, zoals het gebruik van een snelkoppeling voor een opdracht voor één test en een afzonderlijke test om een ​​menu te openen en een specifieke opdracht te selecteren om een ​​afdruk te maken.

De DQ legt uit hoe de softwareontwikkelaars van plan zijn de software te maken om elk van de functionele vereisten en alle verschillende methoden te realiseren. Het moet de normen vermelden die zijn gebruikt om het te maken, inclusief software- en / of hardwarestandaarden om de inhoud van het DQ-document gericht te houden op wat de ontwikkelaars van plan zijn anders of uniek te doen. Een gebruikersbedrijf mag alleen een DQ maken als het gebruikersbedrijf de software zelf maakt met zijn eigen werknemers of met aannemers die specifiek zijn ingehuurd om die ene softawre te maken.

De DQ wordt gebruikt voor twee situaties. Ten eerste, voor een software die "in-house" is ontwikkeld, wat betekent dat het een eigen software is die is gemaakt door het bedrijf en van plan is de software te gebruiken. Voor de eenvoud noem ik dit het gebruikersbedrijf. De tweede situatie is wanneer een gereguleerd bedrijf een spreadsheet maakt (bijvoorbeeld met behulp van Microsoft Excel). Het invoegen van de geprogrammeerde functies van Excel is een vorm van softwareprogrammering, een spreadsheet ontworpen om gegevens of tekst te importeren, te berekenen en om permanente tekst (zoals koppen) te hebben, maken allemaal deel uit van een vorm van "programmeren", waarvoor volledige validatie vereist is met alle validatiedocumenten (DQ, unit tests, IQ, OQ, PQ, samenvattingsrapporten, SOP's, gebruikersinstructies, enz.) Ik ben me niet bewust van softwareontwikkelingsbedrijven die spreadsheets voor hun klanten / gebruikersbedrijven maken, maar sommige ontwikkelaars kunnen dit nu doen. Dus de DQ is altijd een gereguleerd document dat is gebaseerd op de lijst van die softwareontwikkelaar met "waargenomen" functies die gebruikers nodig hebben en die ze wensen.

Het gebruikersbedrijf maakt een document met gebruikersvereisten, waarin alleen de PART de functionele vereisten van de softwareontwikkelaars wordt vermeld, omdat het gebruikersbedrijf weet dat het voornemens is met de software te doen. Er zijn meestal verschillende functies die een ser Company niet van plan is te gebruiken. Misschien is het beste voorbeeld dat ALLE Gebruikers Bedrijven verwachten dat de software elektronische records beveiliging biedt (vereist bijvoorbeeld een audit trail en de software blokkeert verwijdering of wijzigingen in de audit trail). Elektronicarecords vormen slechts een deel van deel 11 van de FDA en / of deel van de vereisten van bijlage 11 van de EU. Veel gebruikersbedrijven willen de functies van elektronische handtekeningen in software niet gebruiken. (Sommige gebruikersbedrijven bestempelen hun document met gebruikersvereisten als hun eigen functionele vereisten. De titel van de documenten is niet echt belangrijk - ik heb nog nooit een regulator gekend die de titel van een document betwist. Het is echter belangrijk dat het document duidelijk aangeeft dat vroeg in het document waarvoor het gebruikersbedrijf het document gebruikt.)

Het IQ is bedoeld als een reproduceerbare reeks hardware, besturingssysteem en andere softwarevereisten voor een server, laptop of desktopcomputer, gevolgd door een specifieke reeks acties en opton selecties om ervoor te zorgen dat ELKE software-installatie door één wordt uitgevoerd Gebruikersbedrijf is identiek aan elkaar. Wanneer het Gebruikersbedrijf de computer (s) moet leveren, wordt het IQ meestal aangepast voor elk Gebruikersbedrijf - of koopt het Gebruikersbedrijf meerdere identieke computers via (of met beoordeling door) de softwareontwikkelaar.

Wanneer de OQ en PQ VEEL overlappen, is het acceptabel om één gecombineerd OQ / PQ-document te produceren.

De traceerbaarheidsmatrix moet de 'eisen' van elk gebruikersbedrijf herleiden tot de IQ, OQ, PQ en / of SOP die aan de eis voldoet. Er kunnen verschillende teststappen nodig zijn om aan één "volledige" eis te voldoen.

Bedrijven voor softwareontwikkeling VRIJWILLIG INDUSTRIECERTIFICATEN. Deze certificeringen vereisen een verscheidenheid aan documentatie TIJDENS hun softwareontwikkeling, inclusief hun equivalent van een IQ en OQ. De ontwikkelaars hebben echter een grotere lijst met functies. Is het gebruikelijk dat deze bedrijven hun tests gebruiken om hun installatie- en gebruikershandleidingen te maken.

De gebruikersbedrijven gebruiken de IQ, OQ en / of PQ vaak voor het trainen van extra gebruikers, en soms maken gebruikersbedrijven snelle referentiegidsen of een aanvullende handleiding voor hun gebruikers.

Wanneer een gebruikersbedrijf een spreadsheet maakt, is het BESTE om deze tijdens de systeemvalidatie te maken. Een "systeem" kan alleen software zijn, alleen hardware, of een combinatie van software en hardware. De computerhardware kan zijn ingebed in het wetenschappelijke instrument, of het kan een afzonderlijke computer zijn waarop de software is geïnstalleerd. Bij het maken van een spreadsheet tijdens de systeemvalidatie kan het iets langer duren tijdens het validatieproces, maar het bespaart veel papierwerk en vertragingen voor gebruikers om hun werk op het werk te voltooien.

U kunt een alinea of ​​subsectie in het validatieplan van het systeem, gebruikersvereisten en OQ gebruiken om te labelen en te gebruiken als het validatieplan van de spreadsheet, DQ, gebruikersvereisten van de spreadsheet, het IQ en het OQ-testplan. (De vereiste spreadsheetinstructies kunnen in de spreadsheet worden geschreven, hetzij door de velden of op een afzonderlijk blad, of instructies kunnen in een afzonderlijk document worden geschreven. De vereiste spreadsheettraining kan één op één of in groepen worden gedaan, maar die training moet worden gedocumenteerd net zoals de training op het gevalideerde systeem moet worden gedocumenteerd). Het uiteindelijke resultaat is dat op het moment van “systeemvrijgave” aan gebruikers voor officieel werk op het werk, die gebruikers ONMIDDELLIJK een volledig gedocumenteerde en gevalideerde spreadsheet voor hun werk hebben.


Antwoord 4:

Ik ga dieper in op de fragmenten van de heer Keller met het gebruikersperspectief, voorbeelden en vergelijkingen van de verschillen tussen de Software Developer Company en de User Company. Ik ben nauw betrokken geweest bij het schrijven van al dit soort documenten. Eerst beantwoord ik het OQ-verschil met de PQ. Vervolgens ga ik dieper in op de andere documenten.

De OQ is uitgebreid om te 'bewijzen' dat de geïnstalleerde software werkt volgens het 'beoogde ontwerp' van de softwareontwikkelaars plus volgens het 'beoogde gebruik' van de gebruiker. Dit moet een stresstest bij maximale en minimale parameters omvatten, inclusief maximale beoogde werkbelasting. Ongeveer een vierde, maar niet meer dan een derde van de OQ wordt verondersteld te verifiëren dat de software ongeldige vermeldingen blokkeert. Voorbeelden: bewijzen dat het "oude wachtwoord" van een gebruiker de gebruiker niet toestaat de software te openen; bewijzen dat een veld dat is ontworpen om alleen cijfers te accepteren, een gebruiker belet letters in het veld in te voeren of op te slaan. Deze tests omvatten het verifiëren wanneer een foutmelding verschijnt. Als het foutbericht wordt verondersteld aan te geven wat de fout is, verifieer dat dan ook. Let op: u hoeft de exacte woorden of zin niet te verifiëren, omdat de nauwkeurigheid van de overgebrachte informatie de belangrijkste factor is. De OQ is meestal erg groot en duurt enkele dagen (of weken) om te voltooien. De OQ-tests kunnen worden uitgevoerd door een of meer van de getrainde peeople van het Gebruikersbedrijf - moesten formeel worden getraind op de software - of door aangewezen / beoogde gebruikers, of door een IT-persoon, of kunnen worden uitbesteed aan een aannemer die formeel is getraind in de software. De OQ MOET een grondige beveiligingstest omvatten volgens FDA's 21 CFR deel 11 en / of de EU-richtlijnen van Eudralex in bijlage 11. Die beveiligingsvereisten zijn van toepassing op GLP-, GMP- en GCP-omgevingen. Van belang is dat de OQ-tests moeten aantonen dat de software consistent, nauwkeurig, betrouwbaar en reproduceerbaarheid werkt. Als de software is gemaakt door een softwarebedrijf dat de software verkoopt als COTS (commercieel verkrijgbaar), moet de OQ alleen de functionele vereisten testen die het gebruikersbedrijf van plan is te gebruiken.

De PQ is aanzienlijk korter omdat deze bedoeld is om te controleren of de beoogde gebruiker (s) van het User Company - die met de software moeten werken als onderdeel van hun taken - tevreden zijn met de daadwerkelijke prestaties van de software. Het wordt verondersteld te verifiëren dat de geïnstalleerde software naar tevredenheid werkt op een "typische" test van bij "typisch tot iets groter" gebruik. Het is altijd het beste dat een groep gebruikers (of een zeer ervaren persoon die de software gaat gebruiken) de 'typische' test maakt. Deze test zou ook beveiligingstests moeten omvatten, te beginnen met de aanmelding bij de software. Deze PQ-tests worden verondersteld te worden uitgevoerd door een of meer daadwerkelijke gebruikers, en zoals elke OQ-tester, moet elke PQ-tester 'eerst' training hebben gehad in de software voordat de PQ-tests werden uitgevoerd. Het is niet de bedoeling dat de persoon (personen) die de PQ-tests uitvoert, wordt gecontracteerd met iemand buiten het gebruikersbedrijf, omdat alleen de daadwerkelijke gebruikers kunnen bepalen of de software echt voldoet aan hun behoeften en verlangens voor prestaties. Alleen de gebruikers kunnen aangeven of de software bevredigend is, en als een test naar verwachting binnen enkele minuten zal worden voltooid, maar het duurt een uur, dan zijn de gebruikers zeker niet tevreden met de prestaties en hoeven de gebruikers de sofware in die langzame staat. Ze kunnen van de IT-mensen en softwareontwikkelaars eisen dat ze de 'prestaties' verbeteren.

Zowel de OQ als de PQ testen de interactie en interoperabiliteit van meerdere functies - zodat het totale verwachte resultaat voldoet aan de behoeften van het gebruikersbedrijf. Dit verschilt sterk van "Eenheidstests" die hieronder worden uitgelegd.

Functionele vereisten is een term die verband houdt met de 'veronderstelde' vereisten van een softwareontwikkelaar voor de software die ze willen maken. Het softwarebedrijf heeft een doelmarkt en de softwareontwikkelaars "denken" aan alles wat ELK van hun gebruikers VEREIST, en ze KUNNEN enkele functies bevatten die de gebruikers MOETEN wensen (om hun software wenselijker te maken dan die van een concurrent). Elke functionele eis moet worden getest met een eenheidstest - voor die specifieke functie. Een eenheidstest test NIET de reeks functies. Voorbeeld: het test niet de mogelijkheid om geïmporteerde gegevens af te drukken, omdat het importproces een apart proces is. Ze hebben één test om te controleren of het importproces is uitgevoerd en of de geïmporteerde gegevens correct zijn. Een afzonderlijke test zal controleren of "welke gegevens dan ook" op een specifiek scherm kunnen worden afgedrukt en dat de afgedrukte gegevens juist zijn. De eenheidstests omvatten ook elke methode voor afdrukken, zoals het gebruik van een snelkoppeling voor een opdracht voor één test en een afzonderlijke test om een ​​menu te openen en een specifieke opdracht te selecteren om een ​​afdruk te maken.

De DQ legt uit hoe de softwareontwikkelaars van plan zijn de software te maken om elk van de functionele vereisten en alle verschillende methoden te realiseren. Het moet de normen vermelden die zijn gebruikt om het te maken, inclusief software- en / of hardwarestandaarden om de inhoud van het DQ-document gericht te houden op wat de ontwikkelaars van plan zijn anders of uniek te doen. Een gebruikersbedrijf mag alleen een DQ maken als het gebruikersbedrijf de software zelf maakt met zijn eigen werknemers of met aannemers die specifiek zijn ingehuurd om die ene softawre te maken.

De DQ wordt gebruikt voor twee situaties. Ten eerste, voor een software die "in-house" is ontwikkeld, wat betekent dat het een eigen software is die is gemaakt door het bedrijf en van plan is de software te gebruiken. Voor de eenvoud noem ik dit het gebruikersbedrijf. De tweede situatie is wanneer een gereguleerd bedrijf een spreadsheet maakt (bijvoorbeeld met behulp van Microsoft Excel). Het invoegen van de geprogrammeerde functies van Excel is een vorm van softwareprogrammering, een spreadsheet ontworpen om gegevens of tekst te importeren, te berekenen en om permanente tekst (zoals koppen) te hebben, maken allemaal deel uit van een vorm van "programmeren", waarvoor volledige validatie vereist is met alle validatiedocumenten (DQ, unit tests, IQ, OQ, PQ, samenvattingsrapporten, SOP's, gebruikersinstructies, enz.) Ik ben me niet bewust van softwareontwikkelingsbedrijven die spreadsheets voor hun klanten / gebruikersbedrijven maken, maar sommige ontwikkelaars kunnen dit nu doen. Dus de DQ is altijd een gereguleerd document dat is gebaseerd op de lijst van die softwareontwikkelaar met "waargenomen" functies die gebruikers nodig hebben en die ze wensen.

Het gebruikersbedrijf maakt een document met gebruikersvereisten, waarin alleen de PART de functionele vereisten van de softwareontwikkelaars wordt vermeld, omdat het gebruikersbedrijf weet dat het voornemens is met de software te doen. Er zijn meestal verschillende functies die een ser Company niet van plan is te gebruiken. Misschien is het beste voorbeeld dat ALLE Gebruikers Bedrijven verwachten dat de software elektronische records beveiliging biedt (vereist bijvoorbeeld een audit trail en de software blokkeert verwijdering of wijzigingen in de audit trail). Elektronicarecords vormen slechts een deel van deel 11 van de FDA en / of deel van de vereisten van bijlage 11 van de EU. Veel gebruikersbedrijven willen de functies van elektronische handtekeningen in software niet gebruiken. (Sommige gebruikersbedrijven bestempelen hun document met gebruikersvereisten als hun eigen functionele vereisten. De titel van de documenten is niet echt belangrijk - ik heb nog nooit een regulator gekend die de titel van een document betwist. Het is echter belangrijk dat het document duidelijk aangeeft dat vroeg in het document waarvoor het gebruikersbedrijf het document gebruikt.)

Het IQ is bedoeld als een reproduceerbare reeks hardware, besturingssysteem en andere softwarevereisten voor een server, laptop of desktopcomputer, gevolgd door een specifieke reeks acties en opton selecties om ervoor te zorgen dat ELKE software-installatie door één wordt uitgevoerd Gebruikersbedrijf is identiek aan elkaar. Wanneer het Gebruikersbedrijf de computer (s) moet leveren, wordt het IQ meestal aangepast voor elk Gebruikersbedrijf - of koopt het Gebruikersbedrijf meerdere identieke computers via (of met beoordeling door) de softwareontwikkelaar.

Wanneer de OQ en PQ VEEL overlappen, is het acceptabel om één gecombineerd OQ / PQ-document te produceren.

De traceerbaarheidsmatrix moet de 'eisen' van elk gebruikersbedrijf herleiden tot de IQ, OQ, PQ en / of SOP die aan de eis voldoet. Er kunnen verschillende teststappen nodig zijn om aan één "volledige" eis te voldoen.

Bedrijven voor softwareontwikkeling VRIJWILLIG INDUSTRIECERTIFICATEN. Deze certificeringen vereisen een verscheidenheid aan documentatie TIJDENS hun softwareontwikkeling, inclusief hun equivalent van een IQ en OQ. De ontwikkelaars hebben echter een grotere lijst met functies. Is het gebruikelijk dat deze bedrijven hun tests gebruiken om hun installatie- en gebruikershandleidingen te maken.

De gebruikersbedrijven gebruiken de IQ, OQ en / of PQ vaak voor het trainen van extra gebruikers, en soms maken gebruikersbedrijven snelle referentiegidsen of een aanvullende handleiding voor hun gebruikers.

Wanneer een gebruikersbedrijf een spreadsheet maakt, is het BESTE om deze tijdens de systeemvalidatie te maken. Een "systeem" kan alleen software zijn, alleen hardware, of een combinatie van software en hardware. De computerhardware kan zijn ingebed in het wetenschappelijke instrument, of het kan een afzonderlijke computer zijn waarop de software is geïnstalleerd. Bij het maken van een spreadsheet tijdens de systeemvalidatie kan het iets langer duren tijdens het validatieproces, maar het bespaart veel papierwerk en vertragingen voor gebruikers om hun werk op het werk te voltooien.

U kunt een alinea of ​​subsectie in het validatieplan van het systeem, gebruikersvereisten en OQ gebruiken om te labelen en te gebruiken als het validatieplan van de spreadsheet, DQ, gebruikersvereisten van de spreadsheet, het IQ en het OQ-testplan. (De vereiste spreadsheetinstructies kunnen in de spreadsheet worden geschreven, hetzij door de velden of op een afzonderlijk blad, of instructies kunnen in een afzonderlijk document worden geschreven. De vereiste spreadsheettraining kan één op één of in groepen worden gedaan, maar die training moet worden gedocumenteerd net zoals de training op het gevalideerde systeem moet worden gedocumenteerd). Het uiteindelijke resultaat is dat op het moment van “systeemvrijgave” aan gebruikers voor officieel werk op het werk, die gebruikers ONMIDDELLIJK een volledig gedocumenteerde en gevalideerde spreadsheet voor hun werk hebben.