Миграция модулей V&V Кейсы и отображение полей

В рамках перехода на новый модуль V&V мы готовимся перенести существующие данные проверки, включая методы проверки, методы проверки компонентов и процедуры испытаний, в обновленный рабочий процесс модуля V&V.

В предыдущих версиях мы ввели в модуль V&V поля, совпадающие с полями старой методики верификации. Опираясь на аналитические данные клиентов, мы определили общие случаи использования и разработали структурированную стратегию переноса существующих данных в новый модуль.

Наш план миграции охватывает семь различных сценариев.

Мы с нетерпением ждем ваших отзывов, чтобы обеспечить соответствие миграции вашим конкретным требованиям.

Пример 1: Метод верификации компонентов в поле "Применимый блок"

В старом рабочем процессе верификации компоненты были связаны с требованиями через методы верификации, связанные с каждым требованием.

В новом модуле V&V этот процесс был упрощен. Теперь пользователи могут напрямую добавлять компоненты/блоки к требованиям с помощью атрибута "Применимые блоки". Во время миграции все компоненты, связанные с методами проверки в старом рабочем процессе, будут автоматически перенесены в атрибут "Применимые блоки" соответствующих требований.

Случай 2: Методы проверки требований (RVM) в поле "Методы"

Некоторые клиенты используют методы верификации требований (RVM), чтобы обозначить тип проверки, предназначенный для требования в будущем, с/без добавления метода верификации компонента (CVM) или дополнительных данных.

В этом случае в процессе миграции имена RVM будут скопированы и перенесены в новое “Methods” поле в таблице требований.

Пример 3: Методы верификации по умолчанию в методы VV

В старой системе верификации существует пять методов верификации по умолчанию: Analysis, Review, Rules, Inspection, и Tests. Кроме того, пользователи могли добавлять пользовательские методы проверки через Verification Methods Settings.

Эти методы проверки будут перенесены в Methods в поле модуля Verifications and Validations (V&V).

Пример 4: Метод верификации правил к правилам VV

В старых методах проверки пользователи могли применить Rules метод проверки к требованию и определить булеву формулу в Close-Out Reference тип. Эта формула использовалась для сравнения значений требований со значениями проекта системы.

В новом модуле V&V эти данные будут перенесены непосредственно в V&V Rules атрибут в модуле требований.

Случай 5: Каждая процедура тестирования переносится как новая деятельность в области ОВиВ

Для пользователей, которые использовали процедуры тестирования и прогоны, каждая процедура тестирования будет перенесена как новая деятельность V&V со всеми процедурами, прогонами и связями с требованиями и компонентами/блоками.

Иллюстрация показана на рисунке ниже

Случай 6: RVM с CVM, которые имеют один и тот же файл или Analysis в качестве ссылки на закрытие, составляются и переносятся как новая деятельность V&V

При управлении несколькими RVM, связанными с одной и той же вариативной деятельностью, заказчикам в настоящее время приходится создавать отдельные RVM для каждого связанного требования, что часто требует многократного прикрепления одного и того же файла и ввода одних и тех же связанных данных в этих RVM.

Чтобы упростить эту процедуру, в процессе миграции будут выявлены файлы или анализы, которые были прикреплены в качестве ссылок на закрытие по нескольким требованиям в ссылках на закрытие CVM. Они будут сгруппированы в единую деятельность V&V. Все связанные с ними требования и компоненты/блоки будут добавлены в качестве элементов проверки и валидации (V&V), а файлы будут загружены непосредственно в консолидированную деятельность V&V. Это обеспечивает более эффективный и централизованный способ управления связанными данными и файлами.

Пример 7: Группировка оставшихся пар RVM/CVM в работы

На последнем этапе все оставшиеся пары RVM/CVM объединяются в виды деятельности, названия которых зависят от соответствующих методов проверки. Процесс группировки происходит следующим образом:

1. Manual Verification Method

   • Для ВМ, у которых ссылка на закрытие Manualсоздается деятельность с тем же именем (Manual).

   • Все RVM и CVM, разделяющие Manual метод проверки, представлены в виде элементов в этой деятельности.

2. File or Analysis Verification Method

   • Для ВМ с эталоном закрытия File или Analysis которые включают RVM и CVM, но не имеют файла или приложения для анализа:

     • Создается мероприятие с именем File или Analysis.

     • Все такие RVM и CVM включаются как элементы в соответствующую деятельность.

3. Test Verification Method

   • Для ВМ с ссылкой на закрытие Test где RVM и CVM существуют, но тест не связан:

     • Создается деятельность с именем Test.

     • Все такие RVM и CVM добавляются в качестве элементов в эту деятельность.

4. RVMs Without CVMs

   • RVM, которые не имеют связанных CVM, представлены в новом рабочем процессе как элементы в соответствующих работах, но без связанного компонента/блока.

Такой структурированный подход обеспечивает учет и организацию всех RVM и CVM четким и управляемым образом, в соответствии с их методами проверки.

Миграции: Сопоставление полей

Каждый объект, такой как тестовые процедуры, RVM или CVM, включает дополнительные поля, которые могут содержать критическую информацию. Во время миграции эти поля будут сохранены и сопоставлены с соответствующими полями в новом модуле V&V. Ниже приведен обзор того, как будут перенесены существующие поля:

Edge Case:

Задачи, обсуждения и подписки на CVM, RVM, этапы тестирования, тестовые прогоны и процедуры тестирования не будут перенесены в новый модуль V&V.

Родительские и дочерние отношения в дереве методов проверки также не экспортируются.