A NASA utiliza múltiplos níveis de teste, validação independente, normas, comunidades de segurança e ferramentas para garantir a segurança. Darrel Raines deu uma palestra sobre desenvolvimento e teste de software para o Ônibus Espacial e o Orion MPCV no NDC Tech Town. Ele explicou como aprendem com falhas e quase acidentes e melhoram continuamente seu processo.
O desenvolvimento de software é muito diferente hoje do que era no início da era do Ônibus Espacial devido às ferramentas que temos à nossa disposição, explicou Darrel Raines em Aprendendo com o Desenvolvimento de Software Embutido para o Ônibus Espacial e o Orion MPCV.
Vários níveis de teste ajudam a garantir um desenvolvimento de software seguro, disse Raines. Os programas exigem entre 4 e 7 níveis de teste antes que o software seja considerado seguro para voo, e cada um depende de uma pessoa ou grupo diferente para ser realizado. Os programas têm um grupo de verificação e validação independente, que realiza os testes que consideram necessários para garantir a segurança do software. Essa diversidade de pessoas trabalhando nos testes ajuda a trazer novas perspectivas e diferentes visões do desenvolvedor original, mencionou Raines.
Raines mencionou que existe uma comunidade de segurança na NASA, e com seus contratantes. Há também uma equipe de Garantia de Qualidade de Software da NASA (SQA), e geralmente uma equipe de SQA de um contratante parceiro:
Essas equipes são convidadas a supervisionar o processo de desenvolvimento de software e apontar defeitos reais e potenciais no software. Elas também realizam a tarefa de garantir a qualidade geral do software. Elas prestam atenção na funcionalidade crítica para a segurança do software.
Com todas essas verificações em vigor, podemos começar a sentir que temos verificações e equilíbrios suficientes para produzir software seguro, disse Raines. Mas, mesmo assim, reavaliamos continuamente nossa postura de segurança e buscamos melhorias, acrescentou.
A equipe de desenvolvimento de software da NASA escolhe ferramentas que facilitam os testes sem reduzir a veracidade dos testes, explicou Raines:
Usamos tudo, desde emuladores em circuito até ambientes de teste independentes. O objetivo é usar uma diversidade de ferramentas para encontrar todos os erros potenciais possíveis, permitindo que os pontos fortes de cada ferramenta ajudem a descobrir defeitos.
Existem padrões da NASA para o desenvolvimento de software, e os contratos têm requisitos adicionais para um veículo específico, disse Raines. O NPR 7150.2 exige testes unitários para medir a cobertura de múltiplas condições/decisões (MC/DC) para todos os testes. Isso ajuda a garantir a qualidade do software, desde que os testes unitários estejam focados em demonstrar toda a funcionalidade, disse Raines.
Raines mencionou que não conseguem encontrar todos os defeitos em seu código, mas precisam tentar. “Quanto mais procuramos, mais encontraremos”, argumentou. Portanto, eles precisam permitir tempo suficiente durante o desenvolvimento para testes adequados.
A engenharia não é tanto uma ciência quanto deveria ser, disse Raines. O desenvolvimento de software é uma disciplina relativamente nova, explicou:
Quando eu estava na faculdade, não havia nem mesmo um diploma em engenharia de software. Portanto, precisamos continuar questionando o que “sabemos” e tentar melhorar nosso conhecimento neste campo.
A InfoQ entrevistou Darrel Raines sobre a medição de testes de software e aprendizado.
InfoQ: Como você mede a eficácia dos testes de software?
Darrel Raines: Um estudo baseado em 30 anos de desenvolvimento de software do Ônibus Espacial mostrou que cada nível de teste encontra a mesma porcentagem dos defeitos remanescentes que cada outro nível. Portanto, podemos extrapolar que quanto mais testes fazemos, mais defeitos encontraremos. Isso tem retornos decrescentes, mas é um método eficaz de reduzir o número de erros de software.
InfoQ: Como você analisa desastres e quase acidentes?
Raines: Fazemos uma análise muito aprofundada de cada caso. Quando perdemos uma espaçonave, como fizemos com Challenger e Columbia, vamos interromper um programa até que as causas raízes desses problemas sejam explicadas e corrigidas. Isso é muito demorado. Mas queremos acertar.
Há um pesado fardo na psique dos membros da equipe quando analisamos um acidente como o Challenger. Continuaremos nos perguntando: “O que eu poderia ter feito pessoalmente para evitar que isso ocorresse?” Quando finalmente recuperamos nossa capacidade de seguir em frente, levamos conosco a lembrança de que os erros que cometemos no desenvolvimento de software podem fazer alguém perder um ente querido. É preciso um tipo especial de pessoa para viver com essa possibilidade e ainda assim progredir em seu trabalho.
InfoQ: Como você aprende com cada caso?
Raines: Registramos as descobertas das investigações de desastres. Eu treino anualmente sobre falhas passadas e como evitá-las no futuro. Faz parte da nossa herança de segurança que percebemos que precisamos realizar nossa missão, mesmo que seja muito difícil. Esse treinamento e o foco da NASA na segurança me dão as ferramentas certas para fazer meu trabalho bem. Eu só preciso agir.
Eu devo continuar aprendendo. A cada ano, desafio a mim mesmo a tentar algo diferente, fazer algo diferente, melhorar no que faço e aprender mais sobre minha disciplina. E à medida que aprendo coisas, compartilho minhas descobertas com aqueles que trabalham ao meu redor. Isso significa que eu também preciso OUVIR meus colegas. Por mais que eu saiba agora, há mais para aprender.