weryfikacja projektu a weryfikacja: 6 wskazówek dotyczących rozwoju urządzeń medycznych

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?

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.

Image blog Wykres walidacji projektu

Walidacja projektu: czy budujesz odpowiedni produkt? Weryfikacja projektu: czy budujesz produkt prawidłowo?

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.

Blog ALM Trace Report
Narzędzia z kompleksową identyfikowalnością ułatwiają tworzenie urządzeń. Raport śledzenia pokazany w Helix ALM.

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.

Blog Alm Wymaganie do wykonania testu uruchomienia
unikaj sytuacji awaryjnych 11-godzinnych! Tutaj, status jest śledzony pomiędzy wymaganiami & zakończone testy w Helix ALM.

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ć.

Blog generowanie anomalii ALM
anomalia utworzona z nieudanego testu, jak pokazano w Helix ALM.

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.

blog ALM Taskboard
Agile, Waterfall, hybrid? Wybierz narzędzia, które pasują do twojego procesu. Tutaj opcjonalne deski sprint w Helix ALM.

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

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.