Przypadki migracji modułów V&V i mapowanie pól

W ramach przejścia na nowy moduł V&V przygotowujemy się do migracji istniejących danych weryfikacyjnych - w tym metod weryfikacji, metod weryfikacji komponentów i procedur testowych - do zaktualizowanego przepływu pracy modułu V&V.

W poprzednich wersjach wprowadziliśmy pola w module V&V, które są zgodne z tymi w starej metodologii weryfikacji. Wykorzystując analizę danych klientów, zidentyfikowaliśmy typowe przypadki użycia i opracowaliśmy ustrukturyzowaną strategię migracji istniejących danych do nowego modułu.

Nasz plan migracji obejmuje siedem różnych scenariuszy.

Czekamy na Twoją opinię, aby upewnić się, że migracja spełnia Twoje specyficzne wymagania.

Przypadek 1: Metoda weryfikacji komponentu w polu "Odpowiedni blok"

W starym przepływie pracy weryfikacji komponenty były powiązane z wymaganiami za pomocą metod weryfikacji powiązanych z każdym wymaganiem.

W nowym module V&V proces ten został usprawniony. Użytkownicy mogą teraz bezpośrednio dodawać komponenty/bloki do wymagań za pomocą atrybutu "Applicable Blocks". Podczas migracji wszelkie komponenty powiązane z metodami weryfikacji w starym przepływie pracy zostaną automatycznie przeniesione do atrybutu "Applicable Blocks" odpowiednich wymagań.

Przypadek 2: Metody weryfikacji wymagań (RVM) do pola "Metody"

Niektórzy klienci używali Metod Weryfikacji Wymagań (RVM) do oznaczania rodzaju weryfikacji przewidzianej dla wymagania w przyszłości, z/bez dodawania Metody Weryfikacji Komponentów (CVM) lub dodatkowych danych.

W tym przypadku proces migracji skopiuje nazwy RVM i przeniesie je do nowego pola “Methods” w tabeli wymagań.

Przypadek 3: Domyślne metody weryfikacji do metod VV

W starym systemie weryfikacji istnieje pięć domyślnych metod weryfikacji: Analysis, Review, Rules, Inspection i Tests. Ponadto użytkownicy mieli możliwość dodawania niestandardowych metod weryfikacji za pośrednictwem strony Verification Methods Settings.

Te metody weryfikacji zostaną przeniesione do pola Methods w module Weryfikacje i walidacje (V&V).

Przypadek 4: Metoda weryfikacji reguł do reguł VV

W starych metodach weryfikacji użytkownicy mogli zastosować metodę weryfikacji Rules do wymagania i zdefiniować formułę logiczną w typie Close-Out Reference. Formuła ta była używana do porównywania wartości wymagań z wartościami projektu systemu.

W nowym module V&V dane te zostaną przeniesione bezpośrednio do atrybutu V&V Rules w module wymagań.

Przypadek 5: Każda procedura testowa jest migrowana jako nowe działanie V&V

W przypadku użytkowników, którzy korzystali z procedury testowej i przebiegów testowych, każda procedura testowa zostanie zmigrowana jako nowe działanie V&V ze wszystkimi procedurami, przebiegami i powiązaniami z wymaganiami i komponentami/blokami.

Ilustrację przedstawiono na poniższym obrazku

Przypadek 6: RVM z CVM, które mają ten sam plik lub Analiza jako odniesienie do zamknięcia jest kompilowana i migrowana jako nowe działanie V&V

Podczas zarządzania wieloma modułami RVM powiązanymi z tym samym działaniem związanym ze zmiennością, klienci muszą obecnie tworzyć oddzielne moduły RVM dla każdego powiązanego wymagania, co często wymaga od nich wielokrotnego dołączania tego samego pliku i wprowadzania tych samych powiązanych danych w tych modułach RVM.

Aby to usprawnić, proces migracji zidentyfikuje pliki lub analizy, które zostały dołączone jako referencje zamknięcia w wielu wymaganiach w referencjach zamknięcia CVM. Zostaną one zgrupowane w jedno działanie V&V. Wszystkie powiązane wymagania i komponenty/bloki zostaną dodane jako elementy weryfikacji i walidacji (V&V), a pliki zostaną przesłane bezpośrednio w ramach skonsolidowanego działania V&V. Zapewnia to bardziej wydajny i scentralizowany sposób zarządzania powiązanymi danymi i plikami.

Przypadek 7: Grupowanie pozostałych par RVM/CVM w działania

Ostatni krok konsoliduje wszystkie pozostałe pary RVM/CVM w działania, z nazwami działań pochodzącymi od powiązanych metod weryfikacji. Proces grupowania działa w następujący sposób:

1. Manual Verification Method

   • Dla maszyn wirtualnych z referencją zamknięcia Manual tworzona jest aktywność o tej samej nazwie (Manual

     )

     .

   • Wszystkie maszyny RVM i CVM korzystające z metody weryfikacji Manual są reprezentowane jako elementy w ramach tego działania.

2. File or Analysis Verification Method

   • W przypadku maszyn wirtualnych z odniesieniem do zamknięcia File lub Analysis, które zawierają RVM i CVM, ale nie mają pliku lub załącznika do analizy:

     • Tworzone jest działanie o nazwie File lub Analysis.

     • Wszystkie takie RVM i CVM są uwzględniane jako elementy w odpowiedniej aktywności.

3. Test Verification Method

   • W przypadku maszyn wirtualnych z referencją zamknięcia Test, gdzie istnieją RVM i CVM, ale żaden test nie jest połączony:

     • Tworzona jest aktywność o nazwie Test.

     • Wszystkie takie RVM i CVM są dodawane jako elementy w ramach tej aktywności.

4. RVMs Without CVMs

   • Moduły RVM, które nie mają powiązanych modułów CVM, są reprezentowane w nowym przepływie pracy jako elementy w ramach odpowiednich działań, ale bez powiązanego komponentu/bloku.

To ustrukturyzowane podejście zapewnia, że wszystkie RVM i CVM są uwzględnione i zorganizowane w przejrzysty i łatwy do zarządzania sposób, dostosowany do ich metod weryfikacji.

Migracje: Mapowanie terenowe

Każdy obiekt, taki jak procedury testowe, RVM lub CVM, zawiera dodatkowe pola, które mogą zawierać krytyczne informacje. Podczas migracji pola te zostaną zachowane i zmapowane na odpowiadające im pola w nowym module V&V. Poniżej znajduje się przegląd sposobu migracji istniejących pól:

Edge Case:

Zadania, dyskusje i subskrypcje w modułach CVM, RVM, krokach testowych, przebiegach testowych i procedurach testowych nie zostaną przeniesione do nowego modułu V&V.

Relacje nadrzędne i podrzędne w drzewie metod weryfikacji również nie są eksportowane.