Na era dos encontros na internet e fechamentos sem precedentes de restaurantes, você pode precisar ocasionalmente baixar alguns padrões para aproveitar ao máximo a vida diária. Geralmente, no entanto, é sempre bom estabelecer padrões altos para seus interesses profissionais, pessoais e sim, relacionados à culinária. Um aspecto (profissional) da vida onde é sempre importante manter altos padrões: garantia de qualidade de software. Um aspecto relacionado onde os mais altos padrões devem ser aplicados, e nunca reduzidos: a garantia de qualidade do software avionics.

Sem os processos e práticas de garantia de qualidade adequados em vigor, você corre o risco de perder erros e falhas no design e código do seu software Avionics, leia: você corre o risco de tempo e contratempos financeiros significativos. Os processos de garantia de qualidade também ajudam a garantir que o produto final seja competitivo, seguro e funcione suavemente suas funções esperadas. Desnecessário dizer que a garantia de qualidade do software aviônico é uma parte crucial, substantiva e impactante do processo de desenvolvimento de projetos aviônicos. É por isso que tivemos que dividir este tópico em duas partes. Neste artigo, cobrimos os principais pontos focais da Garantia de Qualidade de Software da Avionics e estabelecemos as melhores práticas para atividades iniciais (a parte 2 abrange atividades e revisão contínuas).

A Garantia da Qualidade de Software (SQA) é um processo integral de processos e uma peça de missão crítica de conformidade com os padrões DO-178C. A SQA atua para fornecer evidências de que um projeto cumpre processos, normas e orientações ao longo do ciclo de vida do desenvolvimento. Então, para começar, criamos uma lista trifásica útil que descreve as áreas de foco primárias do SQA, em relação ao DO-178C:

Fase I (início do projeto):

  • Verificando se o PSAC e os planos e normas associados estão alinhados com os objetivos do DO-178C.
  • Criando um Plano de Garantia da Qualidade de Software (SQAP).
  • Verificar se os processos do ciclo de vida do software estão em conformidade com os planos e normas aprovados.
  • Estabelecendo a supervisão do fornecedor.

Fase II (execução do projeto):

  • Verificar que a atividade do software segue os processos do ciclo de vida do software, prestando especial atenção a todo e qualquer critério de transição entre os processos do ciclo de vida.

Fase III (revisão do projeto):

  • Conduzindo a revisão de conformidade do produto de software (mais sobre isso na parte 2). Essas atividades devem ser conduzidas se as atividades de software são internas para uma organização ou parte de uma relação integrador-fornecedor. Neste último caso, cada organização que tenha mais fornecedores deve coordenar as atividades da SQA para que as evidências do integrador incluam evidências das atividades de SQA de seu fornecedor.

Os detalhes de fase do seu projeto à parte, você precisa garantir que as atividades de SQA estejam envolvidas em todas as etapas, especialmente ao definir planos e padrões para que seus observáveis possam ser facilmente coletados e alinhados com as principais diretrizes, ou seja, DO-178C. Ao escrever planos e padrões, faz sentido começar com o resultado final que você deseja e trabalhar para trás — os registros de garantia de qualidade de software que você precisa para submissão final — e trabalhar para trás para identificar como você irá gerar cada item. Isso ajudará a criar listas de verificação e identificar ferramentas de suporte para coletar evidências de conformidade, bem como informar os planos e padrões. Normalmente, você vai acabar planejando usar um mix de ferramentas e técnicas e documentar isso nos documentos de planejamento relevantes.

Uma das principais práticas críticas nas fases iniciais e contínuas: quando as organizações fornecedoras estão envolvidas em seu programa, é melhor coordenar as atividades da SQA com todas as partes interessadas o mais cedo possível. Para cada item específico de SQA em seus próprios planos, você deve coordenar como você obterá essas informações do fornecedor, em que forma e em quais marcos. Isso pode ser especialmente desafiador para as atividades de testemunha e participação onde você pode precisar delegar alguma autoridade para a organização fornecedora e, em seguida, auditar as respostas que você obtém, mas vamos entrar nisso e nas etapas finais da SQA (atividades de revisão de conformidade) na parte 2 desta série de blog.

Lembre-se, o SQA é uma peça necessária e útil do seu quebra-cabeça de projeto de software aviônico, e deve ser sempre encarada como uma oportunidade para fazer seus projetos se moverem de forma rápida e econômica.

Artigo Original