As normas de certificação de software DO-178B e DO-178C servem de guia para a produção de sistemas aéreos aeronavegáveis. Publicada pela primeira vez em 1992, a DO-178B (Software Considerations in Airborne Systems and Equipment Certification) foi um documento importante, considerado para a obtenção da certificação necessária junto de autoridades comerciais como a EASA (European Union Aviation Safety Agency) e a FAA (Federal Aviation Administration) para sistemas aéreos baseados em software. No entanto, os Federal Aviation Regulations passaram a aceitar a DO-178C como método de demonstração de conformidade de aeronavegabilidade em 2013. Para informação mais geral sobre as normas DO-178B e DO-178C, pode ler este artigo.
As normas DO-178B ou DO178C devem ser cumpridas através dos seguintes documentos de exemplo, entre outros.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
Os documentos necessários para cumprir as normas DO-178B e DO-178C não se limitam a estes. Existem numerosos outros documentos que reforçam a aeronavegabilidade. Pode consultar e adquirir estes documentos aqui.
Documentos DO178
Documento PSAC
O documento PSAC (Plan for Software Aspects of Certification), além de gerar dados de ciclo de vida, explica as normas, processos, protocolos e metodologias necessários a seguir. Desta forma, é possível cumprir as normas DO-178. O PSAC especifica ainda o calendário de desenvolvimento de software e o estado geral do sistema. Tanto a autoridade aprovadora como o requerente beneficiam deste documento. O PSAC deve ser elaborado durante o processo inicial de planeamento de software e aprovado pela autoridade de certificação. Clique aqui para consultar o nosso documento PSAC.
Documento SDP
O documento SDP (Software Development Plan) visa verificar se foram determinadas as informações necessárias, como procedimentos de desenvolvimento, protocolos, normas, ciclos de vida e ambiente de desenvolvimento. O documento SDP é uma parte importante do processo de planeamento de software. Clique aqui para consultar o nosso documento SDP.
Documento SVP
O documento SVP (Software Verification Plan) especifica os cenários e a cobertura de teste necessários, os procedimentos, os protocolos, a verificação de requisitos e a verificação do código-fonte, assegurando ao mesmo tempo um controlo de versões adequado. O SVP é também uma parte importante do processo de planeamento. Clique aqui para consultar o nosso documento SVP.
Documento SCMP
O documento SCMP (Software Configuration Management Plan) é outro elemento importante do processo de planeamento. O plano inicial elaborado ao longo do processo de desenvolvimento de software sofre frequentemente alterações. O SCMP ajuda a detetar, controlar, manter e acompanhar essas alterações. É aplicado ao longo de todo o processo de desenvolvimento de software. O SCMP visa minimizar os erros e maximizar a eficiência. Os membros da equipa devem esforçar-se por comunicar e notificar-se mutuamente das alterações. Clique aqui para consultar o nosso documento SCMP.
Documento SQAP
O documento SQAP (Software Quality Assurance Plan) contém as ferramentas, métodos e técnicas utilizados para garantir que um produto ou serviço cumpre as especificações constantes do SRS (Software Requirement Specification). O SQAP explica como serão conduzidas as Atividades de Garantia de Qualidade de Software no projeto. A equipa de SQA estabelece marcos e avalia a qualidade do projeto em cada um deles. O SQA é conduzido ao longo de todo o ciclo de vida do software. Clique aqui para consultar o nosso documento SQAP
Documento SAS
O SAS (Software Accomplishment Summary) resume todas as etapas dos componentes de software durante os processos de desenvolvimento e verificação. O SAS deve incluir um resumo das conclusões da qualificação das ferramentas de verificação. A FAA deve ser informada sobre o SAS. Isto fornece à autoridade de certificação a validação das conclusões dos dados de verificação e serve como evidência do estado de qualificação da ferramenta. Clique aqui para consultar o nosso documento SAS
Normas ARP4754 e Normas DO178
ARP4754 significa "Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems". As Normas ARP4754 fornecem orientação para os sistemas da aeronave como um todo, enquanto as Normas DO178 são utilizadas apenas para o software de voo. Ambas as normas são aceites por autoridades como a FAA e a EASA.
A ARP4754 foi desenvolvida e publicada pela SAE (Society of Automotive Engineers) em 1996. Em 2010, a SAE publicou a ARP4754A, que significa Guidelines for Development of Civil Aircraft and Systems. A ARP4754A enriquece o conceito de garantia de design utilizado ao nível da aeronave e do sistema, e normaliza também a utilização do termo garantia de desenvolvimento (development assurance). A ARP4754 foi aprovada pela FAA em novembro de 2011.
A ARP4754 abrange todo o ciclo de desenvolvimento da aeronave, desde a identificação de requisitos até ao final dos processos de integração e verificação. A ARP4754 fornece uma abstração para a aeronave, os sistemas e os componentes. Para o design de componentes, a ARP4754 remete explicitamente para a DO-178 e a DO-254. A ARP4754 centra-se na avaliação de segurança através de diferentes processos, como o desenvolvimento, o design e a verificação. No entanto, deve notar-se que a ARP4754 não inclui o âmbito específico do desenvolvimento de software ou de hardware eletrónico, as atividades de segurança em serviço, nem o processo de desenvolvimento estrutural da aeronave.
Fases de Design
Revisão Preliminar de Design (PDR)
O design preliminar é uma fase importante do processo de desenvolvimento de software. Durante o design preliminar, são identificados os requisitos de alto nível e os casos de utilização para formar a arquitetura do sistema. Podem ser utilizados no design documentos de interface, de base de dados e de arquitetura, bem como diagramas de relações entre componentes. Com base nestes elementos, o design preliminar fornecerá uma representação visual do sistema no início do projeto. O design preliminar estabelece também as bases para as fases de design mais detalhadas que se seguem. Pode ser visto como um rascunho.
A Revisão Preliminar de Design (PDR) encerra a fase de design preliminar do projeto. A PDR deve proporcionar garantia suficiente para avançar para o design detalhado. O objetivo da PDR é assegurar que o design preliminar e a arquitetura básica do sistema estão completos, e que existe confiança técnica de que os requisitos podem ser cumpridos dentro do orçamento e do calendário.
Revisão Crítica de Design (CDR)
A Revisão Crítica de Design (CDR) encerra a fase de design crítico do projeto. Os designs finais são apresentados através da CDR mediante análises abrangentes, simulações, esquemas, código de software e dados de teste. A CDR garante que o sistema pode avançar para o teste e a produção. Estabelece também que os requisitos em causa podem ser cumpridos dentro do orçamento e do calendário. Os desenhos e as especificações abrangentes resultantes fornecem uma linha de base final, juntamente com uma linha de base inicial do produto. A CDR deve ter um âmbito amplo e ser detalhada.
Fase de Design Final
A Fase de Design Final fornece desenhos arquitetónicos e de engenharia detalhados de cada componente do projeto. Para alguns projetos, pode ser necessário elaborar um relatório de design final. Os problemas de design identificados devem ser resolvidos antes da conclusão da fase de design final. Os desenhos e relatórios devem fornecer detalhe suficiente para permitir estimativas planeadas. O relatório de design final deve incluir um calendário atualizado, estimativas de custo e especificações. Deve também confirmar-se que o projeto é economicamente viável. Quaisquer alterações realizadas durante a Fase de Design Final são mais dispendiosas do que nas outras fases. Por conseguinte, devem ser realizadas com muito cuidado.
SOI (Stages of Involvement)
Para avaliar a conformidade dos projetos com a DO-178B, as avaliações SOI são conduzidas pelas autoridades de aviação dos respetivos países em várias fases do projeto, como o planeamento, o desenvolvimento e a verificação. Idealmente, planeia-se um total de quatro revisões SOI.
A primeira avaliação SOI abrange a fase de planeamento do trabalho de conformidade de certificação do projeto. A segunda revisão SOI centra-se nas fases de desenvolvimento do projeto. Começando pelo desenvolvimento dos requisitos de software de alto nível, questiona se o design, os requisitos de software de baixo nível e o código-fonte foram produzidos em conformidade com a DO178B. A terceira revisão SOI centra-se nas fases de verificação. São revistas não só as atividades de teste, mas todas as atividades realizadas para fins de verificação. A quarta SOI é a avaliação de encerramento, realizada perto do final do projeto, questionando se existem atividades pendentes e se surgiram novas questões desde as avaliações anteriores.
A expectativa da DO-178B relativamente aos produtos de software elaborados na fase de planeamento é a de chegar a um conjunto comum de regras entre a autoridade e a empresa que o executa, e cumprir esse conjunto de regras ao longo de todo o projeto. Por outras palavras, ao redigir planos e normas, a empresa não só define os seus próprios processos, como também estabelece as regras segundo as quais a autoridade se avaliará a si própria ao longo de todo o processo de certificação.
Autor: Can Önal ([email protected])
