Casos de Migração do Módulo V&V e Mapeamento de Campos

Como parte da transição para o novo módulo de V&V, estamos a preparar a migração dos seus dados de verificação existentes — incluindo métodos de verificação, métodos de verificação de componentes e procedimentos de teste — para o fluxo de trabalho atualizado do módulo de V&V.

Nas versões anteriores, introduzimos campos no módulo de V&V alinhados com os do antigo método de verificação. Com base na análise de dados dos clientes, identificámos casos de utilização comuns e desenvolvemos uma estratégia estruturada para migrar os seus dados existentes para o novo módulo.

O nosso plano de migração abrange sete cenários distintos.

Aguardamos o seu feedback para garantir que a migração responde aos seus requisitos específicos.

Caso 1: Método de verificação de componente para o campo “Applicable block”

No antigo fluxo de trabalho de verificação, os componentes eram associados aos requisitos através dos métodos de verificação associados a cada requisito.

No novo módulo de V&V, este processo foi simplificado. Os utilizadores podem agora adicionar diretamente componentes/Blocks aos requisitos utilizando o atributo “Applicable Blocks”. Durante a migração, quaisquer componentes associados a métodos de verificação no fluxo de trabalho antigo serão automaticamente transferidos para o atributo “Applicable Blocks” dos requisitos correspondentes.

Caso 2: Requirement Verifcation Methods (RVM’s) para o campo “Methods”

Alguns clientes utilizaram Requirement Verification Methods (RVMs) para identificar o tipo de verificação previsto para um requisito no futuro, com ou sem adicionar um Component Verification Method (CVM) ou dados adicionais.

Neste caso, o processo de migração copiará os nomes dos RVM e transferi-los-á para o novo “Methods” campo na tabela de requisitos.

Caso 3: Métodos de verificação predefinidos para métodos de VV

No antigo sistema de verificação, existem cinco métodos de verificação predefinidos: Analysis, Review, Rules, Inspection e Tests. Além disso, os utilizadores tinham a flexibilidade de adicionar métodos de verificação personalizados através do Verification Methods Settings.

Estes métodos de verificação serão migrados para o campo Methods no módulo Verifications and Validations (V&V).
 

Caso 4: Método de verificação de regras para regras de VV

Nos antigos métodos de verificação, os utilizadores podiam aplicar o método de verificação Rules a um requisito e definir uma fórmula booleana no tipo Close-Out Reference. Esta fórmula era utilizada para comparar os valores do requisito com os valores de conceção do sistema.

No novo módulo de V&V, estes dados serão migrados diretamente para o atributo V&V Rules no módulo de requisitos.  

Caso 5: Cada procedimento de teste é migrado como uma nova atividade de V&V

Para os utilizadores que têm utilizado o procedimento de teste e as execuções de teste, cada procedimento de teste será migrado como uma nova atividade de V&V com todos os procedimentos, execuções e ligações a requisitos e componentes/blocos.

É apresentada uma ilustração na imagem abaixo

Caso 6: RVM’s com CVMs que têm o mesmo ficheiro ou análise como referência de fecho são compilados e migrados como uma nova atividade de V&V

Ao gerir vários RVMs associados à mesma atividade de variação, os clientes precisam atualmente de criar RVMs separados para cada requisito relacionado, sendo frequentemente necessário anexar repetidamente o mesmo ficheiro e introduzir os mesmos dados associados nesses RVMs.

Para simplificar este processo, a migração irá identificar ficheiros ou análises que tenham sido anexados como referências de fecho em vários requisitos nas referências de fecho dos CVM. Estes serão agrupados numa única atividade de V&V. Todos os requisitos e componentes/blocos relacionados serão adicionados como itens de Verification & Validation (V&V), e os ficheiros serão carregados diretamente na atividade de V&V consolidada. Isto garante uma forma mais eficiente e centralizada de gerir dados e ficheiros relacionados.

Caso 7: Agrupar os pares RVM/CVM restantes em atividades

A etapa final consolida todos os pares RVM/CVM restantes em atividades, com nomes de atividade derivados dos métodos de verificação associados. O processo de agrupamento funciona da seguinte forma:

1. Manual Verification Method

   • Para VMs com uma referência de fecho de Manual, é criada uma atividade com o mesmo nome (Manual).

   • Todos os RVMs e CVMs que partilham o método de verificação Manual são representados como itens nesta atividade.

2. File or Analysis Verification Method

   • Para VMs com uma referência de fecho de File ou Analysis que incluem RVMs e CVMs, mas não têm um ficheiro ou anexo de análise:

     • É criada uma atividade com o nome File ou Analysis.

     • Todos esses RVMs e CVMs são incluídos como itens na atividade correspondente.

3. Test Verification Method

   • Para VMs com uma referência de fecho de Test em que existem RVMs e CVMs, mas não existe qualquer teste associado:

     • É criada uma atividade com o nome Test.

     • Todos esses RVMs e CVMs são adicionados como itens nesta atividade.

4. RVMs Without CVMs

   • Os RVMs que não têm CVMs associados são representados no novo fluxo de trabalho como itens nas respetivas atividades, mas sem um componente/bloco associado.

Esta abordagem estruturada garante que todos os RVMs e CVMs são considerados e organizados de forma clara e gerível, alinhados com os seus métodos de verificação.

Migrações: mapeamento de campos

Cada objeto, como procedimentos de teste, RVMs ou CVMs, inclui campos adicionais que podem conter informações críticas. Durante a migração, estes campos serão preservados e mapeados para os campos correspondentes no novo módulo de V&V. Segue-se uma visão geral de como os seus campos existentes serão migrados:
 

Edge Case:

Tarefas, discussões e subscrições nos CVMs, RVMs, etapas de teste, execuções de teste e procedimentos de teste não serão migrados para o novo módulo de V&V.

As relações de pais e filhos na árvore de métodos de verificação também não são exportadas.