Jeśli opracowujesz produkty — w szczególności urządzenia medyczne — to znasz terminy Walidacja projektu i weryfikacja projektu (zwane również V&V). Tutaj wyjaśnimy, czym są te dwa działania, jaka jest między nimi różnica, a także podzielimy się wskazówkami, jak w pełni wykorzystać swoje wysiłki.
Uwaga: Aby potwierdzić, że ta treść będzie dla Ciebie przydatna, połączyliśmy się z Megan Martin, konsultantem ds. urządzeń medycznych&V z ponad 30-letnim doświadczeniem w zakresie urządzeń medycznych V&v, oprogramowaniem do urządzeń medycznych, jakością produktów i oprogramowania oraz oświadczeniami regulacyjnymi dotyczącymi urządzeń w USA i na świecie. Znajdziesz jej spostrzeżenia i przykłady w całym!
przejdź do sekcji, której szukasz:
- Walidacja projektu a weryfikacja projektu
- czym dokładnie jest Walidacja projektu?
- co to jest weryfikacja projektu dla FDA?
- Walidacja a podsumowanie weryfikacji
- podstawy procesu walidacji projektu
- podstawy procesu weryfikacji projektu
- 6 wskazówek dla lepszej walidacji & weryfikacja
- wideo: Uprość V & v
- V&v: słowniczek terminów
- Walidacja projektu a weryfikacja projektu: jaka jest różnica?
- czym dokładnie jest Walidacja projektu?
- przykład walidacji projektu
- potrzeba użytkownika
- Co To jest weryfikacja projektu dla FDA?
- przykład weryfikacji projektu
- wymagania dotyczące produktu
- Dane techniczne
- podsumowanie walidacji a weryfikacji
- podstawy procesu weryfikacji projektu
- podstawy procesu weryfikacji projektu
- identyfikacja i przygotowanie
- planowanie
- rozwój
- Wykonywanie
- raportowanie
- 6 wskazówek dotyczących lepszej walidacji& weryfikacja
- planuj z wyprzedzeniem (i testuj wcześniej)
- użyj wspólnej Nomenklatury
- używaj narzędzi z identyfikowalnością od końca do końca
- Zbuduj swoją matrycę śledzenia w miarę upływu czasu
- Integracja śledzenia wymagań& testowanie ze śledzeniem anomalii
- wybierz Narzędzia, które możesz dostosować do swojej metody
- połączenie tego wszystkiego
- Uprość V&V z Helix ALM
- V&V: słowniczek terminów
- wspólne Akronimy walidacji projektu
Walidacja projektu a weryfikacja projektu: jaka jest różnica?
Jaka jest różnica między walidacją a weryfikacją? Mówiąc prościej, Walidacja projektu określa, czy budujesz odpowiedni produkt. Czy urządzenie działa zgodnie z przeznaczeniem dla użytkowników końcowych? Weryfikacja projektu określa, czy budujesz produkt prawidłowo. Czy wyjścia projektowe pasują do wejść projektowych?
to prosta różnica, jak wyraźnie pokazano na poniższym wykresie.
ale oczywiście potrzebujesz więcej szczegółów i przykładów. Zaczniemy od walidacji.
czym dokładnie jest Walidacja projektu?
Walidacja projektu to proces testowania, w którym udowadniasz („walidujesz”), że zbudowane przez ciebie urządzenie działa dla użytkownika końcowego zgodnie z przeznaczeniem.
oficjalne słowo z FDA (21 CFR 820.3) stwierdza, że Walidacja projektu to ” ustalenie na podstawie obiektywnych dowodów, że specyfikacje urządzeń są zgodne z potrzebami użytkownika i zamierzonym przeznaczeniem (- ami).”
przykład walidacji projektu
wyobraźmy sobie, że budujemy respirator, który utrzymuje pacjenta w oddychaniu i że użytkownik chce, aby działał podczas transportu pacjenta.
najpierw musimy zdefiniować nasze potrzeby użytkowników. Użytkownik chce przenieść pacjentów, gdy są na respiratorze. Ale co oni właściwie próbują zrobić? „Transport” może obejmować przemieszczanie pacjenta w obrębie szpitala. Lub może obejmować transport karetką lub drogą lotniczą. Na przykład potrzeba użytkownika może wyglądać następująco.
potrzeba użytkownika
UsNe-0001 | respirator nadaje się do stosowania podczas transportu pacjentów w szpitalu. |
ta potrzeba użytkownika zostanie podzielona na wymagania produktu i specyfikacje projektowe w celu zaprojektowania i zbudowania produktu. (Przyjrzymy się tym za chwilę w ramach weryfikacji projektu.)
zanim to nastąpi, zbadajmy potrzeby naszych użytkowników i zobaczmy, jakie przypadki testów walidacji projektu mogą być wymagane. Test sprawdzania poprawności naszych potrzeb użytkownika może wyglądać tak.
Użytkownik potrzebuje |
Walidacja Test |
||
---|---|---|---|
UsNe-0001 | respirator nadaje się do stosowania podczas transportu pacjentów w szpitalu. | Tcase-0001 | zestaw testów walidacyjnych: sprawdź, czy respirator może być łatwo zwinięty przez 15 członków personelu transportu szpitalnego. |
TCase-0002 | zestaw testów walidacyjnych: Sprawdzić, czy wentylator działa zgodnie z jego specyfikacjami, podczas gdy jest zwijany w korytarzach, nad zacięciami drzwi i nad progami Wind. | ||
Tcase-0003 | zestaw testów walidacyjnych: sprawdź, czy respirator działa zgodnie ze specyfikacjami podczas przechodzenia między zasilaniem prądem przemiennym a pracą akumulatora. |
testy walidacyjne obejmowałyby przypadki testowe, zestawy testowe, a nawet badania kliniczne mające na celu udowodnienie, że produkt w postaci zbudowanej działa zgodnie z oczekiwaniami użytkownika w warunkach, w których zamierza go używać. Ponieważ badania te powinny być przeprowadzane na jednostkach produkcyjnych lub równoważnych z produkcją, testy walidacji projektu są często ostatnimi testami wykonywanymi.
zasadniczo, w walidacji projektu, musimy wykazać, że produkt spełnia potrzeby użytkownika.
nawiasem mówiąc, powyższa tabela pokazuje również identyfikowalność między potrzebami użytkownika a przypadkami testowymi. Ta matryca śledzenia stanowi część dowodów V&V, których wymaga FDA.
Co To jest weryfikacja projektu dla FDA?
weryfikacja projektu to miejsce, w którym testujesz („Weryfikuj”), czy Twoje wyniki projektu pasują do Twoich wejść projektowych.
ponownie, zgodnie z FDA, weryfikacja projektu jest ” potwierdzeniem poprzez badanie i dostarczenie obiektywnych dowodów, że określone wymagania zostały spełnione.”
należy pamiętać, że chociaż będzie to wymagało testowania, istnieją inne dopuszczalne działania weryfikacyjne.
mogą one obejmować testy, inspekcje i analizy (więcej na ten temat można znaleźć w wytycznych FDA dotyczących kontroli projektu).
przykład weryfikacji projektu
wróćmy do naszego przykładu wentylatora. Zidentyfikowaliśmy potrzeby naszych użytkowników; teraz określ, co urządzenie ma zrobić i jak ma to zrobić.
aby to osiągnąć, musimy zdefiniować konkretne wymagania dotyczące produktu. Na przykład:
- jakie jest maksymalne obciążenie dla pacjenta? (Ile powietrza potrzebuje wentylator?)
- ile czasu potrzebuje bateria? (Jak długo trwa transport?)
- jakie warunki napotkają podczas transportu? (Zacięcie drzwi? Windy?)
- czy są jakieś standardy regulacyjne, które muszą być spełnione? (Standardy bezpieczeństwa?)
„jasne, kompletne, jednoznaczne, testowalne wymagania są kluczowym elementem udanego projektu rozwojowego. Nieodpowiednie wymagania prowadzą do marnowania czasu, błędów projektowych, rozległych przeróbek i delikatnych lub podatnych na błędy produktów.”- Megan Martin, V &V Consultant
jest to część” jaka ” określająca charakterystykę urządzenia. Co dokładnie musi zrobić urządzenie? Wymagania dotyczące produktu (często zawarte w dokumencie wymagań produktu) dla naszych potrzeb użytkownika mogą wyglądać poniżej.
wymagania dotyczące produktu
PrRq-0001 |
wentylator powinien mieć maksymalne ustawienie 2-litrowych oddechów o kontrolowanej objętości przy 20 oddechach na minutę. |
PrRq-0002 |
wentylator powinien pracować na baterii przy maksymalnych ustawieniach przez co najmniej 90 minut. |
PrRq-0003 |
wentylator powinien być zamontowany na stojaku wsporczym. |
PrRq-0004 |
respirator i stojak powinny być w stanie przemierzać typowe progi drzwi szpitalnych i windy. |
wreszcie potrzebujemy specyfikacji projektu. „Zdefiniowaliśmy już, co zamierzamy osiągnąć, a teraz musimy określić, w jaki sposób to zrobimy”, mówi Megan. Można to osiągnąć na wiele sposobów, w tym specyfikacje pisemne, rysunki elektryczne lub mechaniczne, specyfikacje zakupu komponentów lub inne metody.
na przykład specyfikacje projektu i rysunki mogą zawierać następujące informacje.
Dane techniczne
dspec-0001 |
turbina, która może wytwarzać do 40 litrów powietrza na minutę. |
DSpec-0002 |
akumulator litowo-jonowy o pojemności znamionowej co najmniej 100 amperów. |
DSpec-0003 |
mocowanie do stojaka rolkowego wykorzystuje stalowy zacisk dźwigniowy o pojemności 22 funtów. |
DSpec-0004 |
podstawa stojaka ma szerokość 22″ z 5 kołami. |
dspec-0005 |
koła stojące mają średnicę 4″. |
weryfikacja projektu dostarcza dowodów (wyniki testów), że wyjścia projektowe (rzeczywisty produkt) spełniają wejścia projektowe (wymagania produktu i specyfikacje projektowe). W zależności od przedmiotu, który jest weryfikowany, przypadek testowy lub zestaw testowy zostanie uruchomiony, lub inspekcja lub analiza przeprowadzona w celu dostarczenia wymaganych dowodów.
poniższe tabele ilustrują, jak to może wyglądać. Pokazują również identyfikowalność, jakiej oczekuje FDA.
Wymagania dotyczące produktu | Badanie weryfikacyjne | ||
---|---|---|---|
PrRq-0001 | wentylator powinien mieć maksymalne ustawienie objętości 2 litrów-kontrolowane oddechy przy 20 oddechach na minutę. | tcase-0004 | test case: sprawdź maksymalne ustawienia oddechu lub kombinacje ustawień oddechu. |
PrRq-0002 | wentylator powinien pracować na baterii przy maksymalnych ustawieniach przez co najmniej 90 minut. | TCase-0005 | zestaw testowy: Sprawdź czas pracy na maksymalnych ustawieniach z całkowicie naładowanym nowym akumulatorem. |
TCase-0006 | zestaw testowy: Sprawdź czas pracy przy maksymalnych ustawieniach baterii, która przeszła 50 cykli ładowania. | ||
PrRq-0003 | wentylator powinien być zamontowany na wsporniku tocznym. | TCase-0007 | Test demonstracyjny: wykazać, że wentylator można przymocować i odłączyć od stanowiska tocznego. |
PrRq-0004 | respirator i stojak powinny być w stanie przemierzać typowe drzwi szpitalne i progi windy. | Tcase-0008 | Test zewnętrzny: Test przeprowadzony przez usługę testową w celu sprawdzenia, czy respirator i stojak można przewrócić na próg bez przechylania zgodnie z medyczną normą elektryczną IEC 60601-1. |
weryfikacja wymagań produktu, jak wyżej, pokazuje, że produkt robi to, co powiedzieliśmy, że zrobi.
weryfikacja specyfikacji projektu, którą pokażemy dalej, pokazuje, że produkt robi to tak, jak powiedzieliśmy.
Specyfikacja projektu | Test weryfikacyjny | ||
---|---|---|---|
dspec-0001 | turbina, która może generować 40 litrów powietrza na minutę. | Tcase-0009 | zestaw testowy: Sprawdź generowanie powietrza przez turbinę przy 40 l / min przy zasilaniu prądem przemiennym lub akumulatorem. |
DSpec-0002 | akumulator litowo-jonowy o pojemności 100 amperów. | Tcase-0010 | Test inspekcyjny: Sprawdź specyfikację zakupu baterii pokazuje, że typ to Litowo-jonowy. |
Tcase-0011 | Test analizy: Zbierz dane testowe i wykonaj analizę danych, aby wykazać, że wydajność baterii przez cały okres eksploatacji baterii będzie spełniać lub przekraczać 100 godzin Amp. | ||
DSpec-0003 | mocowanie do stojaka rolkowego wykorzystuje stalowy zacisk dźwigniowy o pojemności 22 funtów. | Tcase-0012 | Test inspekcyjny: sprawdź, czy specyfikacja części dotyczy stalowego zacisku dźwigniowego o pojemności 22 funtów lub większej. |
DSpec-0004 | podstawa ma szerokość 22″ i 5 kół. |
TCase-0013 |
Test Case: Measure base diameter; count wheels; measure wheel diameter |
DSpec-0005 | koła stojące mają średnicę 4″. |
zasadniczo, podczas weryfikacji projektu, musimy wykazać, że produkt, który zbudowaliśmy, jest produktem, o którym mówiliśmy, że zbudujemy.
Po zebraniu razem w raporcie V& V, połączenie wyników testów weryfikacyjnych i walidacyjnych, wraz z identyfikowalnością z potrzebami użytkownika, wymaganiami produktu i specyfikacjami projektowymi, stanowi część dowodów wymaganych przez FDA przy składaniu wyrobu medycznego do odprawy celnej.
podsumowanie walidacji a weryfikacji
oto krótkie, jeśli nieco uproszczone, podsumowanie kluczowych różnic.
Design Verification |
Design Validation |
Design output is as expected. |
Final design meets user’s needs. |
System, subsystem and unit testing. |
System testing. |
During development. |
After development. |
Test individual module or completed system under any conditions. |
Test conditions per user needs. |
obejmuje inspekcje, analizy i testy systemu. |
obejmuje testowanie równoważnych jednostek produkcyjnych w warunkach rzeczywistego użytkowania. |
zawiera raporty z przeprowadzonych badań, wyników badań i identyfikowalności. Raporty są przeglądane, zatwierdzane i podpisywane. |
zawiera raport końcowy z wynikami testów i identyfikowalnością, gotowy do przeglądu przepisów. Raporty są przeglądane, zatwierdzane i podpisywane. |
podstawy procesu weryfikacji projektu
proces weryfikacji projektu będzie w dużej mierze polegał na przetestowaniu urządzenia. Można to przeprowadzić na kilka sposobów, w zależności od okoliczności. Działania mogą obejmować:
- symulowanie funkcjonalności poprzez modelowanie matematyczne.
- testowanie ostatecznego projektu, aby udowodnić, że system działa zgodnie z potrzebami użytkownika.
plan testowy, przypadki testowe, rekordy wykonania testów i wyniki testów powinny być udokumentowane i utrzymywane jako część dokumentacji projektowej. Walidacja w całości nie jest wynikiem pojedynczego działania, ale zbiorem wyników wszystkich działań walidacyjnych.
podstawy procesu weryfikacji projektu
weryfikacja może być zredukowana do prostego procesu pięciostopniowego.
identyfikacja i przygotowanie
określenie najlepszego podejścia do przeprowadzenia weryfikacji. Określ, co będziesz mierzył i jak będziesz to mierzył. Warto również wziąć pod uwagę wymagane zasoby, siłę roboczą i narzędzia do pomyślnej weryfikacji.
planowanie
planowanie weryfikacji odbywa się w całym cyklu życia projektu. Opracujesz plan testów, który przechwytuje kluczowe kamienie milowe. Plan musi być aktualizowany za każdym razem, gdy wprowadzane są zmiany w projektowaniu danych wejściowych.
rozwój
rozpoczyna się rozwój produktu! Odbywa się przy użyciu wybranej metodologii (Scrum, Waterfall, hybrid itp.). Ta część procesu obejmuje również pisanie, jazdę testową i zatwierdzanie przypadków testowych, które zostaną wykorzystane do weryfikacji.
Wykonywanie
procedury testowe są wykonywane zgodnie z planem. Wszelkie nieprawidłowe wyniki są dokumentowane i sprawdzane oraz akceptowane lub rejestrowane jako wady. Usterki w produkcie są rozwiązywane i uwalniane, a testowanie regresji jest wykonywane. Tworzy się matrycę identyfikowalności w celu sprawdzenia, czy dane wejściowe projektu zidentyfikowane w planie testów weryfikacyjnych zostały przetestowane i zdane.
raportowanie
raportowanie odbywa się na końcu każdego etapu weryfikacji. Szczegółowe raporty obejmują raporty zarządzania konfiguracją i Wydania, wyniki testów według typu testowania lub wersji produktu oraz problemy wykryte podczas weryfikacji. Raport dotyczący identyfikowalności projektu pokazuje wyniki badań i zakres wymagań. Wreszcie, przeglądy są zakończone i zatwierdzane po każdej czynności weryfikacji projektu.
6 wskazówek dotyczących lepszej walidacji& weryfikacja
oto wskazówki, które pomogą Ci w pełni wykorzystać możliwości walidacji& czynności weryfikacyjne.
planuj z wyprzedzeniem (i testuj wcześniej)
miej solidny plan z góry i zapętlaj wszystkich. Włącz inżynierów testowych na wczesnym etapie planowania rozwoju, aby upewnić się, że wymagania i projekt są jasne, kompletne i możliwe do przetestowania. Mówi Megan: „wczesne opracowanie metod badawczych może rzucić światło na problemy technologiczne, zanim staną się poważnymi przeszkodami.”Wczesne opracowywanie testów może również zapewnić narzędzia testowe. Można je następnie wykorzystać do przyspieszenia procesu rozwoju produktu, a także dostarczenia dowodów testowych podczas testów formalnych.
użyj wspólnej Nomenklatury
uzyskanie zespołu na tej samej stronie ma kluczowe znaczenie dla pomyślnej walidacji projektu& weryfikacja. Część wchodzenia na tę samą stronę oznacza użycie wspólnej terminologii. Używanie tych samych terminów eliminuje zamieszanie wśród członków zespołu (nie tylko nowych członków — weteranów). Zapoznaj się ze słowniczkiem terminów i akronimów poniżej, aby pomóc w opracowaniu podstawy terminologii.
używaj narzędzi z identyfikowalnością od końca do końca
w najprostszym przypadku identyfikowalność można uzyskać za pomocą dokumentów i arkuszy kalkulacyjnych programu word, ale generują one tak wiele pracy ręcznej (i są tak podatne na błędy), że będziesz chciał zacząć od dedykowanego narzędzia.
„dokładna matryca śledzenia jest nieoceniona podczas wykonywania analizy regresji, aby określić, co należy ponownie przetestować po zmianie Produktu lub naprawie błędu.”- Megan Martin, V&V Consultant
Korzystanie z narzędzia o silnej zdolności śledzenia wymagań do testowania wyników pomoże zidentyfikować dziury w pokryciu i dać wczesne ostrzeżenia na delikatnych lub niesprawdzonych obszarach produktu.
uzyskaj pełną identyfikowalność już teraz
Zbuduj swoją matrycę śledzenia w miarę upływu czasu
„może to być kuszące, aby ją odłożyć, ale nie czekaj, aby zbudować swoją matrycę śledzenia!”mówi Megan. Budowanie identyfikowalności w trakcie podróży uchroni dziury przed niezauważonym rozwojem. Niewiele rzeczy jest trudniejszych do odzyskania niż odkrycie, że przegapiłeś krytyczne wymagania, funkcje ograniczające ryzyko lub podstawowe testy, gdy uważasz, że praca programistyczna jest zakończona.
utrzymanie identyfikowalności w miarę rozwoju wymagań, projektów i testów wymaga znacznie mniej wysiłku konserwacyjnego niż załatanie krytycznych luk w projektowaniu i rozwoju w 11.godzinie. Ten wysiłek może również pomóc określić, ile pracy pozostało, gdzie może być konieczne dodanie personelu programistycznego lub testowego lub kiedy należy ponownie ocenić harmonogramy dostaw.
Integracja śledzenia wymagań& testowanie ze śledzeniem anomalii
możliwość łączenia anomalii bezpośrednio z wymaganiem poprawia komunikację między testerami a programistami. Jest to niezwykle pomocne. Generowanie anomalii bezpośrednio z powodu awarii protokołu testowego oznacza, że rejestrowane są bardziej szczegółowe informacje na temat problemu. W rezultacie problemy można łatwiej udokumentować, odtworzyć, naprawić i ponownie przetestować.
wybierz Narzędzia, które możesz dostosować do swojej metody
„niezależnie od wybranego modelu rozwoju — zwinny, iteracyjny, zmodyfikowany Wodospad — chcesz wybrać V&V narzędzia, które służą Ci, dostosowując się do procesu, zamiast zmuszać cię do dostosowania procesu do narzędzia”, radzi Megan.
wybrane przez ciebie narzędzia do tworzenia urządzeń medycznych powinny zwiększyć dokładność i skuteczność pracy wykonywanej przez twój zespół, a nie dodawać zbędnych kosztów do codziennych zadań. Dobre narzędzie zapewnia poręcze, aby zapewnić, że ważne rzeczy są zawsze zrobione. Daje to zespołowi elastyczność w tworzeniu widoków i raportów ad hoc, aby lepiej wykorzystywać (i eksplorować) zgromadzone dane. Zapewnia V&V ukierunkowane przechwytywanie danych i raportowanie, aby tworzenie raportów było proste i powtarzalne.
poświęć trochę czasu, aby określić, w jaki sposób chcesz, aby Narzędzia wspierały Twój zespół, zanim wybierzesz. Następnie skonfiguruj narzędzia zgodnie z potrzebami swojego zespołu.
połączenie tego wszystkiego
Walidacja i weryfikacja projektu są niezbędnymi elementami udanego rozwoju Urządzenia. Dzięki wspólnemu zrozumieniu zespołu, a także odpowiednim narzędziom, masz solidne ramy do wprowadzenia urządzenia na rynek.
obejrzyj całe DEMO już teraz >>
Uprość V&V z Helix ALM
zobacz, jak helix Alm może przyspieszyć rozwój urządzeń medycznych.
poznaj Helix ALM
*ponownie, dzięki V & V eksperta Megan Martin, który dostarczył nieoceniony wgląd do tego bloga!
V&V: słowniczek terminów
rzeczywisty wynik – co system faktycznie robi, gdy dana akcja jest wykonywana.
anomalia – gdy system nie działa zgodnie z oczekiwaniami. Na przykład błąd, błąd lub błąd testu.
Deliverable – obowiązkowy obiekt powstały w wyniku realizacji projektu, Zwykle dokumentuje się go w procesie walidacji.
odchylenie – gdy proces lub procedura nie mogą być wykonane zgodnie z definicją, a alternatywna metoda lub materiał jest używany.
oczekiwany wynik-co powinien zrobić system po wykonaniu akcji.
Test integracyjny – test przeprowadzany przy użyciu dwóch lub więcej podsystemów w celu weryfikacji interakcji i współzależności podsystemów.
protokół-zbiór przypadków testowych używanych do dokumentowania testów systemu.
kwalifikacja-protokół testowy określający, że system spełnia określony zbiór wymagań.
zapewnienie jakości-członkowie zespołu mają za zadanie zapewnienie jakości produktu lub integralności procesu.
wymóg-coś, co system musi być w stanie zrobić.
Retrospective Validation – Walidacja systemu, który już istnieje.
Specyfikacja-dokument określający wymagania dla systemu lub komponentu.
Test podsystemu – badanie przeprowadzone na głównym podsystemie lub grupie komponentów.
System-rzecz podlegająca walidacji.
właściciel systemu – osoba, która ostatecznie odpowiada za system.
Test systemu-test przeprowadzany przy użyciu całego systemu.
Test Case-udokumentowana procedura, stosowana do sprawdzenia, czy system spełnia wymagania lub zbiór wymagań.
Plan testowy-metodologia testowania ustanowiona w celu zapewnienia, że system spełnia wymagania.
etap testowy-indywidualna linia przypadku testowego. Powinien zawierać instrukcje, oczekiwany wynik i rzeczywisty wynik.
identyfikowalność-możliwość zapewnienia, że wymagania określone w specyfikacji zostały przetestowane. Często rejestrowane w matrycy identyfikowalności wymagań.
test jednostkowy – test przeprowadzany na jednostce programowej lub sprzętowej lub module niskopoziomowym.
Walidacja-ustalenie na podstawie obiektywnych dowodów, że specyfikacje urządzenia są zgodne z potrzebami użytkownika i przeznaczeniem (- ami).
pakiet walidacyjny – zbiór dokumentów wytworzonych podczas projektu walidacyjnego.
weryfikacja-potwierdzenie poprzez badanie i dostarczenie obiektywnych dowodów, że określone wymagania zostały spełnione.
V&V Plan – plan określający wymagania do weryfikacji i walidacji oraz siłę roboczą, odpowiedzialne osoby, narzędzia, metody, zasoby i harmonogram dla V & V wysiłek.
wspólne Akronimy walidacji projektu
CC – Change Control
CCB – Change Control Board (grupa osób, które kontrolują, jakie zmiany są wprowadzane i kiedy)
DS – Specyfikacja projektu
Fat – Factory Acceptance Testing
FS – Specyfikacja funkcjonalna
FRS – Specyfikacja wymagań funkcjonalnych (patrz specyfikacja funkcjonalna)
GCP – Good Clinical Practice (wytyczne dotyczące jakości operacji klinicznych)
GLP – Good Laboratory practice (wytyczne jakości dla działalności laboratorium farmaceutycznego)
GMP – Good Manufacturing Sad – dokument architektury oprogramowania lub dokument architektury systemu
Sat – Site Acceptance Testing
SCCB – Software Change Control Board (taki sam jak CCB, ale dla oprogramowania)
SDD – Software Detail Design Document
SDS-software Design Specification
Spec – Specification
SRS – software Requirements Specification
TM – traceability matrix
UAT – User Acceptance Testing
Urs-user requirement Specification
UUT – Unit Under Test
VMP – Validation Master Plan
VP – Validation Plan
V&V – Verification and Validation