Hvad er forskellen mellem en operationel kvalifikation (OQ) og en præstationskvalifikation (PQ)?


Svar 1:

For at citere fra medicinske produktreguleringsanliggender: Farmaceutiske produkter, diagnosticering, medicinske enheder: John J. Tobin, Gary Walsh: 9783527318773: Amazon.com: Bøger, side 225:

Valideringen af ​​nye faciliteter, systemer eller udstyr udføres normalt ved hjælp af en fire-trins proces med designkvalifikation (DQ), installationskvalifikation (IQ), operationel kvalifikation (OQ) og performance qualification (PQ).

Designkvalifikation er mest relevant for systemer, der involverer brugerdefineret design såsom faciliteterne selv, hvor det er nødvendigt at demonstrere, at designet opfylder GMP-kravene. For enklere udstyr fra hylden er det normalt kun et spørgsmål om at vælge det rigtige udstyr til den tilsigtede anvendelse.

Installationskvalifikation involverer udførelse af kontroller for at sikre, at det rigtige udstyr eller system er installeret og / eller tilsluttet, inklusive alle nødvendige kontroller, skærme, instrumentering eller hjælpetjenester. Disse kontroller skal omfatte bekræftelse af, at relevante brugervejledninger eller instruktioner er modtaget fra leverandøren, og at eventuelle relevante kalibreringstrin er blevet identificeret.

Operativ kvalifikation involverer udførelse af en række tests for at kontrollere, at alle elementer i systemet er funktionelle på tværs af det specificerede driftsområde. Dette involverer normalt at udføre udfordringer i værste fald ekstreme driftsforhold. Processen skal muliggøre bekræftelse af den endelige procedure, vedligeholdelse og kalibrering.

Endelig udføres ydelseskvalifikation ved hjælp af materialer og række af driftsbetingelser, der er planlagt under normal brug. Tænk som et eksempel på en ny påfyldningslinie, der bruger en peristaltisk pumpe og rør til at dispensere specificerede mængder væske. Reproducerbarheden af ​​det dispenserede volumen kunne påvirkes af rørets størrelse, væskens viskositet, ændringer i fødeledningstrykket, når reservoirtankens højde falder, eller et tab af elasticitet i røret, når det ældes. Præstationskvalifikationen skal vise sig at demonstrere, at systemet ved hjælp af passende diameter slange og pumpehastigheder, en overskriftstank til at opretholde et konstant tryktilførsel og definerede kalibreringskontrol og udskiftningsintervaller for rør, kan systemet levere den nødvendige procesevne til at opnå de specificerede udfylde tolerancer. Produkter, der er repræsentative for lav og høj viskositet og små og store påfyldningsmængder, ville blive valgt, og kontroller af påfyldningsmængderne leveret over en passende driftsperiode ville blive analyseret statistisk.

Og fra ISO 13485: En komplet guide til kvalitetsstyring i medicinsk udstyr: 9781439866115: Medicin og sundhedsvidenskabsbøger @ Amazon.com side 224 og 230:

Operationskvalifikationsaktiviteter er et sæt handlinger og aktiviteter med det formål at sikre objektivt bevis for, at alle processoutput og resultater er i overensstemmelse med de foruddefinerede specifikationer og krav; det vil sige, at:

• Resultaterne accepteres under de relevante produktionsbetingelser.

• Resultaterne evalueres og sammenlignes med et godkendt foruddefineret kriterium.

• Evalueringen giver overensstemmelse med krav og specifikationer.

Performance Qualification (PQ) -aktiviteter er et sæt testaktiviteter, der udføres, efter at alle OQ-aktiviteterne er blevet gennemgået og godkendt. Formålet med PQ er at demonstrere, at en proces kan generere produkter eller resultater, der opfylder alle specifikationer konsekvent over tid og ændringer. Ændring kan forekomme som ændring af skift, nedlukning af ugen og anvendelse af forskellige operatører. Processkapaciteten og stabiliteten blev etableret og opnået i OQ-fasen. Det er nu nødvendigt at sikre dem for hele jobbet. Dette opnås gennem etablering og implementering af kontinuerlige tests og dataanalyse, indtil der er opnået et tilfredsstillende niveau af tillid.


Svar 2:

Jeg udvider Mr. Kellers uddrag med brugerperspektiv, eksempler og sammenligninger af forskellene mellem Software Developer Company og User Company. Jeg har været tæt involveret i at skrive alle disse typer dokumenter. Først svarer jeg for OQ-forskellen fra PQ. Dernæst udvider jeg over de andre dokumenter.

OQ er omfattende til at "bevise", at den installerede software fungerer efter dens "tilsigtede design" af softwareudviklerne plus i henhold til brugernes "tilsigtede brug." Dette skal omfatte en stresstest ved maximim og minimumsparametre, inklusive den maksimale tilsigtede arbejdsbelastning. Cirka en fjerdedel, men ikke mere end en tredjedel, af OQ formodes at verificere, at softwaren blokerer ugyldige poster. Eksempler: bevis for, at en brugers “gamle adgangskode” ikke tillader brugeren at åbne softwaren; bevise, at et felt, der kun er beregnet til at acceptere cifre, vil blokere en bruger fra at indtaste eller gemme bogstaver i feltet. Disse tests inkluderer bekræftelse af, hvornår der vises en fejlmeddelelse. Hvis fejlmeddelelsen skal indikere, hvad fejlen er, skal du også kontrollere det. Advarsel: du behøver ikke at verificere de nøjagtige ord eller sætning, fordi nøjagtigheden af ​​den videregivne information er den vigtige faktor. OQ er normalt meget stor og tager flere dage (eller uger) at gennemføre. OQ-testene kan udføres af en eller flere af brugerfirmaets uddannede folk - skulle formelt trænes på softwaren - eller af udpegede / tilsigtede brugere, eller af en IT-person, eller kan outsources til en entreprenør, der formelt er blevet formelt trænet i softwaren. OQ SKAL omfatte grundig sikkerhedstest pr. FDA's 21 CFR-del 11 og / eller pr. EU's Eudralex-direktiver i bilag 11. Disse sikkerhedskrav gælder for GLP-, GMP- og GCP-miljøer. Af betydning er, at OQ-testene skal demonstrere, at softwaren fungerer konsekvent, nøjagtigt, pålideligt og reproducerbarhed. Hvis softwaren er oprettet af en softwarevirksomhed, der sælger softwaren som COTS (kommerciel fra hylden), skal OQ kun teste de funktionelle krav, som brugerfirmaet agter at bruge.

PQ'en er markant kortere, fordi dens formål er at verificere, at brugerfirmaets planlagte bruger (e) - der skal arbejde med softwaren som en del af deres job - er tilfredse med softwarens faktiske ydelse. Det antages at verificere, at den installerede software fungerer tilfredshed ved en “typisk” test ved “typisk til slighlyt større” brug. Det er altid bedst, at en brugergruppe (eller en meget erfaren person, der vil bruge softwaren) opretter den "typiske" test. Denne test antages også at indeholde sikkerhedstest, der starter med login til softwaren. Disse PQ-tests skal udføres af en eller flere faktiske brugere, og ligesom hver OQ-tester skal enhver PQ-tester have modtaget træning på softwaren “før” udførelse af PQ-testene. Den eller de personer, der udfører PQ-testene, antages ikke at blive kontraheret med nogen uden for brugerfirmaet, fordi kun de faktiske brugere kan bestemme, om softwaren virkelig tilfredsstiller deres behov og ønsker til ydeevne. Kun brugerne kan angive, om softwaren er tilfredsstillende, og hvis en test forventes at være afsluttet i løbet af få minutter, men det kræver en time, er brugerne bestemt ikke tilfredse med ydelsen, og brugerne er ikke forpligtet til at acceptere software i den langsomme tilstand. De kan kræve, at it-folk og softwareudviklere forbedrer "ydeevnen."

Både OQ og PQ tester interaktion og interoperabilitet mellem flere funktioner - for at det samlede forventede resultat opfylder brugerbedriftens behov. Dette er meget forskellig fra "Enhedstests", der er forklaret nedenfor.

Funktionelle krav er et udtryk, der er knyttet til en softwareudviklers “antagede” krav til den software, de har til hensigt at oprette. Softwarevirksomheden har et målmarked, og softwareudviklerne ”tænker” på alt, hvad NOEN af deres brugere vil kræve, og de kan muligvis inkludere nogle funktioner, som brugerne MÅske ønsker (for at gøre deres software mere ønskelig end nogen konkurrents software). Hver funktionskrav skal testes med en enhedstest - for den specifikke funktion. En enhedstest tester IKKE sekvensen af ​​funktioner. Eksempel: det vil ikke teste muligheden for at udskrive importerede data, fordi importprocessen er en separat proces. De har en test til at verificere den importerede process, og at de importerede data er nøjagtige. En separat test vil verificere, at "uanset data" på en bestemt skærm kan udskrives, og at de trykte data er nøjagtige. Enhedstestene inkluderer også enhver metode til udskrivning, såsom at bruge en genvej til en kommando til en test og en separat test for at få adgang til en menu og vælge en bestemt kommando til at udskrive.

DQ forklarer, hvordan softwareudviklerne agter at oprette softwaren til at opfylde hver af de funktionelle krav og alle de forskellige metoder. Den skal angive de standarder, der bruges til at oprette den, herunder software og / eller hardwarestandarder for at holde DQ-dokumentets indhold fokuseret på, hvad udviklerne agter at gøre anderledes eller unikt. Et brugerfirma skal kun oprette en DQ, hvis brugerfirmaet selv opretter softwaren med deres egne ansatte eller med entreprenører, der er ansat specifikt for at oprette den ene softawre.

DQ bruges i to situationer. For det første for en software, der er udviklet "internt", hvilket betyder, at det er en proprietær software oprettet af virksomheden, der har til hensigt at bruge softwaren. For smplicity kalder jeg dette brugerfirmaet. Den anden situation er, når et reguleret firma opretter et regneark (f.eks. Ved hjælp af Microsoft Excel). Indsættelse af Excel's programmerede funktioner er en form for softwareprogrammering, designet et regneark til at importere data eller tekst, beregne og have permanent tekst (såsom overskrifter) er alle del af en form for "programmering", der kræver fuldstændig validering med alle valideringsdokumenter (DQ, enhedstest, IQ, OQ, PQ, sammenfattende rapporter, SOP'er, brugervejledninger osv.) Jeg er ikke opmærksom på softwareudviklende virksomheder, der opretter regneark til deres kunder / brugerfirmaer, men nogle udviklere kan muligvis gøre det nu. Så DQ er altid et reguleret dokument, der er baseret på den softwareskabers liste over “opfattede” funktioner, som brugere har brug for og ønsket.

Brugerselskabet opretter et brugerkravdokument, der kun viser den DEL, softwareudviklerens funktionelle krav, fordi brugerfirmaet ved, at de agter at gøre med softwaren. Der er normalt flere funktioner, som et ser-selskab ikke har til hensigt at bruge. Det bedste eksempel er måske, at ALLE brugerfirmaer forventer, at softwaren leverer Electronic Records-sikkerhed (f.eks. Kræver en revisionsspor, og softwaren blokerer sletning eller ændringer af revisionssporet). Electronics Records er kun en del af FDA's del 11 og / eller en del af EU's bilag 11-krav. Mange brugerfirmaer ønsker ikke at bruge de elektroniske signaturfunktioner, der leveres i en software. (Nogle brugerselskaber mærker deres brugerkravdokument som deres egne funktionelle krav. Dokumenternes titel er ikke rigtig vigtig - jeg har aldrig kendt nogen regulator, der bestrider titlen på et dokument. Det er dog vigtigt, at dokumentet klart angiver meget tidligt i dokumentet, hvad brugerfirmaet bruger dokumentet til at repræsentere.)

IQ'en er beregnet til at være en reproducerbar sekvens af hardware, operativsystem og andre softwarekrav, der skal være på en server, bærbar computer eller stationær computer, efterfulgt af en bestemt række af handlinger og optonvalg for at sikre, at HVER softwareinstallation udføres af en Brugerselskab er identisk med hinanden. Når brugerfirmaet skal levere computeren (e), tilpasses IQ normalt for hvert brugerfirma - eller brugerfirmaet køber flere identiske computere gennem (eller med gennemgang af) softwareudvikleren.

Når OQ og PQ har MEGET overlapning, er det acceptabelt at fremstille et kombineret OQ / PQ-dokument.

Sporbarhedsmatrixen skal spore ethvert brugerselskabs 'krav' til IQ, OQ, PQ og / eller SOP, der opfylder kravet. Der kan være flere testtrin, der kræves for at imødekomme et "komplet" krav.

Virksomheder inden for softwareudvikling LOVLIGT opnår INDUSTRY CERTIFICATIONS. Disse certificeringer kræver en række forskellige dokumenter under deres softwareudvikling, som inkluderer deres ækvivalent til en IQ og OQ. Imidlertid har udviklerne en større liste over funktioner. Er det almindeligt, at disse virksomheder bruger deres test til at oprette deres installations- og brugervejledninger.

Brugerselskaberne bruger ofte IQ, OQ og / eller PQ til uddannelse af yderligere brugere, og undertiden opretter brugerselskaber hurtigreferencer eller en supplerende manual til deres brugere.

Når et brugerfirma opretter et regneark, er det BEDSTE at oprette det under systemvalideringen. Et "system" kan kun være software, kun hardware eller en kombination af software og hardware. Computerhardware kan være indlejret i det videnskabelige instrument, eller det kan være en separat computer, hvorpå softwaren er installeret. Når du opretter et regneark under systemvalideringen, kan det tage lidt længere tid under valideringsprocessen, men det sparer meget papirarbejde og forsinkelser for brugerne at afslutte deres arbejde på jobbet.

Du kan bruge et afsnit eller et underafsnit i systemets valideringsplan, brugerkrav og OQ til at blive mærket og brugt som regnearkets valideringsplan, DQ, regnearkets brugerkrav, dens IQ og dens OQ testplan. (De krævede regnearksinstruktioner kan skrives inde i regnearket enten ved felterne eller på et separat ark - eller instruktioner kan skrives i et separat dokument. Den krævede regnearktræning kan udføres en-til-en eller i grupper, men denne træning skal dokumenteres, ligesom træningen på det validerede system skal dokumenteres). Det endelige resultat er, at på tidspunktet for "systemfrigivelse" til brugere til officielt arbejde på jobbet, vil disse brugere UMIDDELT have et fuldt dokumenteret og valideret regneark til deres arbejde.


Svar 3:

Jeg udvider Mr. Kellers uddrag med brugerperspektiv, eksempler og sammenligninger af forskellene mellem Software Developer Company og User Company. Jeg har været tæt involveret i at skrive alle disse typer dokumenter. Først svarer jeg for OQ-forskellen fra PQ. Dernæst udvider jeg over de andre dokumenter.

OQ er omfattende til at "bevise", at den installerede software fungerer efter dens "tilsigtede design" af softwareudviklerne plus i henhold til brugernes "tilsigtede brug." Dette skal omfatte en stresstest ved maximim og minimumsparametre, inklusive den maksimale tilsigtede arbejdsbelastning. Cirka en fjerdedel, men ikke mere end en tredjedel, af OQ formodes at verificere, at softwaren blokerer ugyldige poster. Eksempler: bevis for, at en brugers “gamle adgangskode” ikke tillader brugeren at åbne softwaren; bevise, at et felt, der kun er beregnet til at acceptere cifre, vil blokere en bruger fra at indtaste eller gemme bogstaver i feltet. Disse tests inkluderer bekræftelse af, hvornår der vises en fejlmeddelelse. Hvis fejlmeddelelsen skal indikere, hvad fejlen er, skal du også kontrollere det. Advarsel: du behøver ikke at verificere de nøjagtige ord eller sætning, fordi nøjagtigheden af ​​den videregivne information er den vigtige faktor. OQ er normalt meget stor og tager flere dage (eller uger) at gennemføre. OQ-testene kan udføres af en eller flere af brugerfirmaets uddannede folk - skulle formelt trænes på softwaren - eller af udpegede / tilsigtede brugere, eller af en IT-person, eller kan outsources til en entreprenør, der formelt er blevet formelt trænet i softwaren. OQ SKAL omfatte grundig sikkerhedstest pr. FDA's 21 CFR-del 11 og / eller pr. EU's Eudralex-direktiver i bilag 11. Disse sikkerhedskrav gælder for GLP-, GMP- og GCP-miljøer. Af betydning er, at OQ-testene skal demonstrere, at softwaren fungerer konsekvent, nøjagtigt, pålideligt og reproducerbarhed. Hvis softwaren er oprettet af en softwarevirksomhed, der sælger softwaren som COTS (kommerciel fra hylden), skal OQ kun teste de funktionelle krav, som brugerfirmaet agter at bruge.

PQ'en er markant kortere, fordi dens formål er at verificere, at brugerfirmaets planlagte bruger (e) - der skal arbejde med softwaren som en del af deres job - er tilfredse med softwarens faktiske ydelse. Det antages at verificere, at den installerede software fungerer tilfredshed ved en “typisk” test ved “typisk til slighlyt større” brug. Det er altid bedst, at en brugergruppe (eller en meget erfaren person, der vil bruge softwaren) opretter den "typiske" test. Denne test antages også at indeholde sikkerhedstest, der starter med login til softwaren. Disse PQ-tests skal udføres af en eller flere faktiske brugere, og ligesom hver OQ-tester skal enhver PQ-tester have modtaget træning på softwaren “før” udførelse af PQ-testene. Den eller de personer, der udfører PQ-testene, antages ikke at blive kontraheret med nogen uden for brugerfirmaet, fordi kun de faktiske brugere kan bestemme, om softwaren virkelig tilfredsstiller deres behov og ønsker til ydeevne. Kun brugerne kan angive, om softwaren er tilfredsstillende, og hvis en test forventes at være afsluttet i løbet af få minutter, men det kræver en time, er brugerne bestemt ikke tilfredse med ydelsen, og brugerne er ikke forpligtet til at acceptere software i den langsomme tilstand. De kan kræve, at it-folk og softwareudviklere forbedrer "ydeevnen."

Både OQ og PQ tester interaktion og interoperabilitet mellem flere funktioner - for at det samlede forventede resultat opfylder brugerbedriftens behov. Dette er meget forskellig fra "Enhedstests", der er forklaret nedenfor.

Funktionelle krav er et udtryk, der er knyttet til en softwareudviklers “antagede” krav til den software, de har til hensigt at oprette. Softwarevirksomheden har et målmarked, og softwareudviklerne ”tænker” på alt, hvad NOEN af deres brugere vil kræve, og de kan muligvis inkludere nogle funktioner, som brugerne MÅske ønsker (for at gøre deres software mere ønskelig end nogen konkurrents software). Hver funktionskrav skal testes med en enhedstest - for den specifikke funktion. En enhedstest tester IKKE sekvensen af ​​funktioner. Eksempel: det vil ikke teste muligheden for at udskrive importerede data, fordi importprocessen er en separat proces. De har en test til at verificere den importerede process, og at de importerede data er nøjagtige. En separat test vil verificere, at "uanset data" på en bestemt skærm kan udskrives, og at de trykte data er nøjagtige. Enhedstestene inkluderer også enhver metode til udskrivning, såsom at bruge en genvej til en kommando til en test og en separat test for at få adgang til en menu og vælge en bestemt kommando til at udskrive.

DQ forklarer, hvordan softwareudviklerne agter at oprette softwaren til at opfylde hver af de funktionelle krav og alle de forskellige metoder. Den skal angive de standarder, der bruges til at oprette den, herunder software og / eller hardwarestandarder for at holde DQ-dokumentets indhold fokuseret på, hvad udviklerne agter at gøre anderledes eller unikt. Et brugerfirma skal kun oprette en DQ, hvis brugerfirmaet selv opretter softwaren med deres egne ansatte eller med entreprenører, der er ansat specifikt for at oprette den ene softawre.

DQ bruges i to situationer. For det første for en software, der er udviklet "internt", hvilket betyder, at det er en proprietær software oprettet af virksomheden, der har til hensigt at bruge softwaren. For smplicity kalder jeg dette brugerfirmaet. Den anden situation er, når et reguleret firma opretter et regneark (f.eks. Ved hjælp af Microsoft Excel). Indsættelse af Excel's programmerede funktioner er en form for softwareprogrammering, designet et regneark til at importere data eller tekst, beregne og have permanent tekst (såsom overskrifter) er alle del af en form for "programmering", der kræver fuldstændig validering med alle valideringsdokumenter (DQ, enhedstest, IQ, OQ, PQ, sammenfattende rapporter, SOP'er, brugervejledninger osv.) Jeg er ikke opmærksom på softwareudviklende virksomheder, der opretter regneark til deres kunder / brugerfirmaer, men nogle udviklere kan muligvis gøre det nu. Så DQ er altid et reguleret dokument, der er baseret på den softwareskabers liste over “opfattede” funktioner, som brugere har brug for og ønsket.

Brugerselskabet opretter et brugerkravdokument, der kun viser den DEL, softwareudviklerens funktionelle krav, fordi brugerfirmaet ved, at de agter at gøre med softwaren. Der er normalt flere funktioner, som et ser-selskab ikke har til hensigt at bruge. Det bedste eksempel er måske, at ALLE brugerfirmaer forventer, at softwaren leverer Electronic Records-sikkerhed (f.eks. Kræver en revisionsspor, og softwaren blokerer sletning eller ændringer af revisionssporet). Electronics Records er kun en del af FDA's del 11 og / eller en del af EU's bilag 11-krav. Mange brugerfirmaer ønsker ikke at bruge de elektroniske signaturfunktioner, der leveres i en software. (Nogle brugerselskaber mærker deres brugerkravdokument som deres egne funktionelle krav. Dokumenternes titel er ikke rigtig vigtig - jeg har aldrig kendt nogen regulator, der bestrider titlen på et dokument. Det er dog vigtigt, at dokumentet klart angiver meget tidligt i dokumentet, hvad brugerfirmaet bruger dokumentet til at repræsentere.)

IQ'en er beregnet til at være en reproducerbar sekvens af hardware, operativsystem og andre softwarekrav, der skal være på en server, bærbar computer eller stationær computer, efterfulgt af en bestemt række af handlinger og optonvalg for at sikre, at HVER softwareinstallation udføres af en Brugerselskab er identisk med hinanden. Når brugerfirmaet skal levere computeren (e), tilpasses IQ normalt for hvert brugerfirma - eller brugerfirmaet køber flere identiske computere gennem (eller med gennemgang af) softwareudvikleren.

Når OQ og PQ har MEGET overlapning, er det acceptabelt at fremstille et kombineret OQ / PQ-dokument.

Sporbarhedsmatrixen skal spore ethvert brugerselskabs 'krav' til IQ, OQ, PQ og / eller SOP, der opfylder kravet. Der kan være flere testtrin, der kræves for at imødekomme et "komplet" krav.

Virksomheder inden for softwareudvikling LOVLIGT opnår INDUSTRY CERTIFICATIONS. Disse certificeringer kræver en række forskellige dokumenter under deres softwareudvikling, som inkluderer deres ækvivalent til en IQ og OQ. Imidlertid har udviklerne en større liste over funktioner. Er det almindeligt, at disse virksomheder bruger deres test til at oprette deres installations- og brugervejledninger.

Brugerselskaberne bruger ofte IQ, OQ og / eller PQ til uddannelse af yderligere brugere, og undertiden opretter brugerselskaber hurtigreferencer eller en supplerende manual til deres brugere.

Når et brugerfirma opretter et regneark, er det BEDSTE at oprette det under systemvalideringen. Et "system" kan kun være software, kun hardware eller en kombination af software og hardware. Computerhardware kan være indlejret i det videnskabelige instrument, eller det kan være en separat computer, hvorpå softwaren er installeret. Når du opretter et regneark under systemvalideringen, kan det tage lidt længere tid under valideringsprocessen, men det sparer meget papirarbejde og forsinkelser for brugerne at afslutte deres arbejde på jobbet.

Du kan bruge et afsnit eller et underafsnit i systemets valideringsplan, brugerkrav og OQ til at blive mærket og brugt som regnearkets valideringsplan, DQ, regnearkets brugerkrav, dens IQ og dens OQ testplan. (De krævede regnearksinstruktioner kan skrives inde i regnearket enten ved felterne eller på et separat ark - eller instruktioner kan skrives i et separat dokument. Den krævede regnearktræning kan udføres en-til-en eller i grupper, men denne træning skal dokumenteres, ligesom træningen på det validerede system skal dokumenteres). Det endelige resultat er, at på tidspunktet for "systemfrigivelse" til brugere til officielt arbejde på jobbet, vil disse brugere UMIDDELT have et fuldt dokumenteret og valideret regneark til deres arbejde.


Svar 4:

Jeg udvider Mr. Kellers uddrag med brugerperspektiv, eksempler og sammenligninger af forskellene mellem Software Developer Company og User Company. Jeg har været tæt involveret i at skrive alle disse typer dokumenter. Først svarer jeg for OQ-forskellen fra PQ. Dernæst udvider jeg over de andre dokumenter.

OQ er omfattende til at "bevise", at den installerede software fungerer efter dens "tilsigtede design" af softwareudviklerne plus i henhold til brugernes "tilsigtede brug." Dette skal omfatte en stresstest ved maximim og minimumsparametre, inklusive den maksimale tilsigtede arbejdsbelastning. Cirka en fjerdedel, men ikke mere end en tredjedel, af OQ formodes at verificere, at softwaren blokerer ugyldige poster. Eksempler: bevis for, at en brugers “gamle adgangskode” ikke tillader brugeren at åbne softwaren; bevise, at et felt, der kun er beregnet til at acceptere cifre, vil blokere en bruger fra at indtaste eller gemme bogstaver i feltet. Disse tests inkluderer bekræftelse af, hvornår der vises en fejlmeddelelse. Hvis fejlmeddelelsen skal indikere, hvad fejlen er, skal du også kontrollere det. Advarsel: du behøver ikke at verificere de nøjagtige ord eller sætning, fordi nøjagtigheden af ​​den videregivne information er den vigtige faktor. OQ er normalt meget stor og tager flere dage (eller uger) at gennemføre. OQ-testene kan udføres af en eller flere af brugerfirmaets uddannede folk - skulle formelt trænes på softwaren - eller af udpegede / tilsigtede brugere, eller af en IT-person, eller kan outsources til en entreprenør, der formelt er blevet formelt trænet i softwaren. OQ SKAL omfatte grundig sikkerhedstest pr. FDA's 21 CFR-del 11 og / eller pr. EU's Eudralex-direktiver i bilag 11. Disse sikkerhedskrav gælder for GLP-, GMP- og GCP-miljøer. Af betydning er, at OQ-testene skal demonstrere, at softwaren fungerer konsekvent, nøjagtigt, pålideligt og reproducerbarhed. Hvis softwaren er oprettet af en softwarevirksomhed, der sælger softwaren som COTS (kommerciel fra hylden), skal OQ kun teste de funktionelle krav, som brugerfirmaet agter at bruge.

PQ'en er markant kortere, fordi dens formål er at verificere, at brugerfirmaets planlagte bruger (e) - der skal arbejde med softwaren som en del af deres job - er tilfredse med softwarens faktiske ydelse. Det antages at verificere, at den installerede software fungerer tilfredshed ved en “typisk” test ved “typisk til slighlyt større” brug. Det er altid bedst, at en brugergruppe (eller en meget erfaren person, der vil bruge softwaren) opretter den "typiske" test. Denne test antages også at indeholde sikkerhedstest, der starter med login til softwaren. Disse PQ-tests skal udføres af en eller flere faktiske brugere, og ligesom hver OQ-tester skal enhver PQ-tester have modtaget træning på softwaren “før” udførelse af PQ-testene. Den eller de personer, der udfører PQ-testene, antages ikke at blive kontraheret med nogen uden for brugerfirmaet, fordi kun de faktiske brugere kan bestemme, om softwaren virkelig tilfredsstiller deres behov og ønsker til ydeevne. Kun brugerne kan angive, om softwaren er tilfredsstillende, og hvis en test forventes at være afsluttet i løbet af få minutter, men det kræver en time, er brugerne bestemt ikke tilfredse med ydelsen, og brugerne er ikke forpligtet til at acceptere software i den langsomme tilstand. De kan kræve, at it-folk og softwareudviklere forbedrer "ydeevnen."

Både OQ og PQ tester interaktion og interoperabilitet mellem flere funktioner - for at det samlede forventede resultat opfylder brugerbedriftens behov. Dette er meget forskellig fra "Enhedstests", der er forklaret nedenfor.

Funktionelle krav er et udtryk, der er knyttet til en softwareudviklers “antagede” krav til den software, de har til hensigt at oprette. Softwarevirksomheden har et målmarked, og softwareudviklerne ”tænker” på alt, hvad NOEN af deres brugere vil kræve, og de kan muligvis inkludere nogle funktioner, som brugerne MÅske ønsker (for at gøre deres software mere ønskelig end nogen konkurrents software). Hver funktionskrav skal testes med en enhedstest - for den specifikke funktion. En enhedstest tester IKKE sekvensen af ​​funktioner. Eksempel: det vil ikke teste muligheden for at udskrive importerede data, fordi importprocessen er en separat proces. De har en test til at verificere den importerede process, og at de importerede data er nøjagtige. En separat test vil verificere, at "uanset data" på en bestemt skærm kan udskrives, og at de trykte data er nøjagtige. Enhedstestene inkluderer også enhver metode til udskrivning, såsom at bruge en genvej til en kommando til en test og en separat test for at få adgang til en menu og vælge en bestemt kommando til at udskrive.

DQ forklarer, hvordan softwareudviklerne agter at oprette softwaren til at opfylde hver af de funktionelle krav og alle de forskellige metoder. Den skal angive de standarder, der bruges til at oprette den, herunder software og / eller hardwarestandarder for at holde DQ-dokumentets indhold fokuseret på, hvad udviklerne agter at gøre anderledes eller unikt. Et brugerfirma skal kun oprette en DQ, hvis brugerfirmaet selv opretter softwaren med deres egne ansatte eller med entreprenører, der er ansat specifikt for at oprette den ene softawre.

DQ bruges i to situationer. For det første for en software, der er udviklet "internt", hvilket betyder, at det er en proprietær software oprettet af virksomheden, der har til hensigt at bruge softwaren. For smplicity kalder jeg dette brugerfirmaet. Den anden situation er, når et reguleret firma opretter et regneark (f.eks. Ved hjælp af Microsoft Excel). Indsættelse af Excel's programmerede funktioner er en form for softwareprogrammering, designet et regneark til at importere data eller tekst, beregne og have permanent tekst (såsom overskrifter) er alle del af en form for "programmering", der kræver fuldstændig validering med alle valideringsdokumenter (DQ, enhedstest, IQ, OQ, PQ, sammenfattende rapporter, SOP'er, brugervejledninger osv.) Jeg er ikke opmærksom på softwareudviklende virksomheder, der opretter regneark til deres kunder / brugerfirmaer, men nogle udviklere kan muligvis gøre det nu. Så DQ er altid et reguleret dokument, der er baseret på den softwareskabers liste over “opfattede” funktioner, som brugere har brug for og ønsket.

Brugerselskabet opretter et brugerkravdokument, der kun viser den DEL, softwareudviklerens funktionelle krav, fordi brugerfirmaet ved, at de agter at gøre med softwaren. Der er normalt flere funktioner, som et ser-selskab ikke har til hensigt at bruge. Det bedste eksempel er måske, at ALLE brugerfirmaer forventer, at softwaren leverer Electronic Records-sikkerhed (f.eks. Kræver en revisionsspor, og softwaren blokerer sletning eller ændringer af revisionssporet). Electronics Records er kun en del af FDA's del 11 og / eller en del af EU's bilag 11-krav. Mange brugerfirmaer ønsker ikke at bruge de elektroniske signaturfunktioner, der leveres i en software. (Nogle brugerselskaber mærker deres brugerkravdokument som deres egne funktionelle krav. Dokumenternes titel er ikke rigtig vigtig - jeg har aldrig kendt nogen regulator, der bestrider titlen på et dokument. Det er dog vigtigt, at dokumentet klart angiver meget tidligt i dokumentet, hvad brugerfirmaet bruger dokumentet til at repræsentere.)

IQ'en er beregnet til at være en reproducerbar sekvens af hardware, operativsystem og andre softwarekrav, der skal være på en server, bærbar computer eller stationær computer, efterfulgt af en bestemt række af handlinger og optonvalg for at sikre, at HVER softwareinstallation udføres af en Brugerselskab er identisk med hinanden. Når brugerfirmaet skal levere computeren (e), tilpasses IQ normalt for hvert brugerfirma - eller brugerfirmaet køber flere identiske computere gennem (eller med gennemgang af) softwareudvikleren.

Når OQ og PQ har MEGET overlapning, er det acceptabelt at fremstille et kombineret OQ / PQ-dokument.

Sporbarhedsmatrixen skal spore ethvert brugerselskabs 'krav' til IQ, OQ, PQ og / eller SOP, der opfylder kravet. Der kan være flere testtrin, der kræves for at imødekomme et "komplet" krav.

Virksomheder inden for softwareudvikling LOVLIGT opnår INDUSTRY CERTIFICATIONS. Disse certificeringer kræver en række forskellige dokumenter under deres softwareudvikling, som inkluderer deres ækvivalent til en IQ og OQ. Imidlertid har udviklerne en større liste over funktioner. Er det almindeligt, at disse virksomheder bruger deres test til at oprette deres installations- og brugervejledninger.

Brugerselskaberne bruger ofte IQ, OQ og / eller PQ til uddannelse af yderligere brugere, og undertiden opretter brugerselskaber hurtigreferencer eller en supplerende manual til deres brugere.

Når et brugerfirma opretter et regneark, er det BEDSTE at oprette det under systemvalideringen. Et "system" kan kun være software, kun hardware eller en kombination af software og hardware. Computerhardware kan være indlejret i det videnskabelige instrument, eller det kan være en separat computer, hvorpå softwaren er installeret. Når du opretter et regneark under systemvalideringen, kan det tage lidt længere tid under valideringsprocessen, men det sparer meget papirarbejde og forsinkelser for brugerne at afslutte deres arbejde på jobbet.

Du kan bruge et afsnit eller et underafsnit i systemets valideringsplan, brugerkrav og OQ til at blive mærket og brugt som regnearkets valideringsplan, DQ, regnearkets brugerkrav, dens IQ og dens OQ testplan. (De krævede regnearksinstruktioner kan skrives inde i regnearket enten ved felterne eller på et separat ark - eller instruktioner kan skrives i et separat dokument. Den krævede regnearktræning kan udføres en-til-en eller i grupper, men denne træning skal dokumenteres, ligesom træningen på det validerede system skal dokumenteres). Det endelige resultat er, at på tidspunktet for "systemfrigivelse" til brugere til officielt arbejde på jobbet, vil disse brugere UMIDDELT have et fuldt dokumenteret og valideret regneark til deres arbejde.