Bem-vindos à parte 2 da nossa série de artigos de 2 partes – Padrões Mais Altos: Melhores Práticas de Garantia da Qualidade do Software Avionics. Se você ainda não leu a parte 1, nós encorajamos você a fazê-lo sempre que for conveniente, embora tenhamos feito o nosso melhor para garantir que ambas as partes possam voar sozinhas, por assim dizer. Dito isto, os artigos formam um par fenomenalmente informativo para explicar de forma abrangente os processos, procedimentos e melhores práticas envolvidos na Garantia da Qualidade de Software (SQA) para a Avionics e a Aerospace.

Na parte 1, discutimos por que a SQA é uma parte crucial de qualquer ciclo de vida de desenvolvimento de software aviônico, estabeleceu as fases de todo o processo e oferecemos atividades de início de práticas recomendadas para definir o tom certo do seu projeto, que é garantir que ele e seu SQA executem o seu melhor. Também demos uma definição rápida do tema, feita mais rapidamente aqui: a SQA fornece os registros necessários para determinar se um projeto cumpriu requisitos legais críticos e as principais normas e diretrizes do setor. Neste artigo, estamos discutindo a importância das atividades contínuas da SQA nas últimas etapas do seu projeto, dando ao estágio final, revisão de conformidade, alguma atenção extra.

Como mencionamos regularmente, um imperdível não negociável para qualquer tarefa dentro do espaço aéreo é um plano bem pensado. As atividades de SQA não são exceção Para que as atividades contínuas de SQA do seu projeto sejam bem sucedidas, o Plano deve ter uma enciclopédia exaustiva de atividades realizadas (ou melhor, a ser realizada) ao longo de seu ciclo de vida. Planos SQA desenvolvidos cuidadosamente, entre outras coisas positivas, fornecerão a estrutura para registrar e reconhecer que suas principais atividades e tarefas em andamento atendem às diretrizes do DO-178C e aderem a padrões subsequentes de missão crítica.

Essas principais atividades e tarefas incluem:

• Avaliação independente – atividades em que a SQA avalia independentemente várias tarefas e condições especificadas em seus planos e/ou saídas dessas tarefas. A avaliação independente pode ser aplicada, por exemplo, a dados do ciclo de vida, critérios de transição, ambiente de ciclo de vida, processos e registros de SCM. Problemas típicos descobertos por meio de atividades de avaliação independentes incluem identificar alterações de software sem atualizações de requisitos correspondentes ou identificar discrepâncias nas versões de ferramentas usadas por diferentes partes da organização de engenharia. É sensato construir procedimentos, listas de verificação e ferramentas para apoiar essas atividades e considerar que treinamento sua equipe de SQA pode precisar em avaliação e auditoria independentes.

• Participação – atividades em que a SQA tem um papel ativo contínuo. Isso pode incluir, por exemplo, participação em revisões, quadros de controle de alterações e relatórios de problemas (ver Relatórios de problemas na página 10). Os engenheiros de qualidade de software normalmente estariam presentes em alguma porcentagem dessas reuniões para ajudar a identificar problemas como desvios de processos, itens de lista de verificação perdidos ou instruções confusas. Além de gerar relatórios de qualidade de software para explicar o atendimento e identificar problemas e ações corretivas aplicadas, outro benefício da participação é corrigir processos e atualizar materiais de suporte o mais cedo possível. Isso pode ajudar a evitar a necessidade de um retrabalho posterior significativo para corrigir problemas de qualidade.

• Testemunha – isso envolve membros da equipe da SQA testemunhando atividades como testes e o processo de construção e carga. Testemunhar pode ser de várias formas, por exemplo, testemunhar a atividade original que está sendo realizada, testemunhar um engenheiro refazer a atividade ou realizar independentemente a atividade. O uso de uma mistura dessas técnicas ajudará a dar uma boa disseminação entre a eficiência do processo de verificação e a independência necessária para encontrar inconsistências.

Por fim, a equipe da SQA em um projeto DO-178C tem a responsabilidade de realizar uma revisão de conformidade. Esta revisão normalmente realizada como o passo final indo para o SOI#4, que revisamos em nossos treinamentos regulares ao vivo e online, fornece documentação mostrando que o ciclo de vida do software está completo. Seu relatório de revisão de conformidade irá resumir e cruzar evidências que você coletará ao longo do ciclo de vida do software, mostrando que:

  • Os processos planejados foram seguidos e gerados dados rastreáveis e controlados do ciclo de vida, com linhas de base completas e consistentes, incluindo quaisquer dados relacionados a alterações de uma linha de base anterior.
  • Desvios e relatórios de problemas abertos foram revisados e aprovados.
  • As atividades de teste de software, construção e carga foram realizadas a partir de instruções repetíveis e bem definidas.

Como dissemos na parte 1, a SQA é uma parte essencial e excepcionalmente útil da jornada do seu software aviônico, e você deve sempre considerar as oportunidades que a SQA oferece para ajudar a realizar um projeto de software e ajudá-lo a alcançar o auge do sucesso.

Artigo Original