Engenharia De Software Federal

O que é a engenharia de software federal e como ela funciona na prática

A engenharia de software federal é o conjunto de normas, diretrizes e práticas que orientam o desenvolvimento de software pelo Poder Executivo da União. O documento central é o Manual de Engenharia de Software para a Administração Pública Federal, publicado originalmente pela Secretaria de Estado de Modernização do Estado (atual Secretaria de Reforma do Estado do Ministério da Economia). Ele define o que uma equipe precisa fazer para entregar um sistema que atenda às exigências legais e administrativas do governo federal. O manual foi atualizado ao longo dos anos. A versão mais recente segue orientações da Instrução Normativa que trata da gestão de produtos digitais no governo. A estrutura gira em torno de três eixos principais: governança, ciclo de vida do desenvolvimento e padrões técnicos para interoperabilidade e segurança.

Como começar com a engenharia de software federal

A primeira coisa que uma equipe precisa entender é que esse framework não é apenas um checklist burocrático. Ele serve como linguagem comum entre órgãos que precisam trocar dados. Quando o Ministério da Saúde desenvolve um módulo de registro e o Ministério da Gestão precisa acessar esses dados, existem regras que definem como isso acontece sem cada um criar seu próprio formato proprietário. Na prática, o fluxo de trabalho segue estas etapas:

• Identificação da necessidade: documentar o problema de negócio antes de qualquer discussão técnica. Esse documento se chama Termo de Referência ou Estimativa de Custo de Desenvolvimento, dependendo do porte do projeto.
• Análise de requisitos: separar requisitos funcionais dos não funcionais. No governo federal, a falta dessa distinção é o erro mais comum e gera retrabalho enorme.
• Arquitetura e padrões: definir se o sistema será desenvolvido como aplicação web, mobile ou serviço. Se for um serviço, precisa seguir as regras do portal de dados abertos e da arquitetura de interoperabilidade definida pela pasta.
• Desenvolvimento: código fonte aberto é a regra. A licença padrão recomendada é a MIT. Revisão de código por pares é obrigatória segundo as diretrizes.
• Testes e qualidade: testes automatizados, cobertura mínima, e validação contra os critérios de aceitação definidos na etapa de requisitos.
• Implantação e manutenção: publicação no repositório oficial, documentação técnica e operacional, e plano de suporte definido.

Um detalhe que quase ninguém menciona e que causa problema real: a engenharia de software federal exige que todo software seja publicado em repositório público. Isso inclui código, documentação de APIs e manuais de instalação. Quando comecei a trabalhar com sistemas do governo, levei duas semanas só para configurar o repositório seguindo as normas corretas. O time queria pular essa etapa porque achava burocrático. O resultado foi que o sistema foi rejeitado na análise técnica e precisou ser reformulado do zero. Desde então, configuro o repositório antes de escrever a primeira linha de código. Outro ponto que parece óbvio mas gera confusão constante é a diferença entre engenharia de software federal e normas genéricas de mercado. Frameworks como ISO/IEC 12207 ou CMMI são úteis, mas o manual federal tem exigências específicas que eles não cobrem. Por exemplo, a obrigatoriedade de uso de padrões abertos de documentação (como o modelo de documento oficial da administração pública), a necessidade de certificação digital para assinaturas em documentos do projeto, e as regras de acessibilidade que seguem o e-MAG (Modelo de Acessibilidade em Governo Eletrônico).

Erros que vejo repetidamente

O erro mais frequente é tratar o manual como algo que se lê no final do projeto. Ele precisa ser consultado desde o primeiro dia. Quem lê só na hora de apresentar o relatório final descobre tarde demais que parte do que foi construído não atende aos requisitos de interoperabilidade. Outro problema comum é subestimar o tempo de documentação. Um sistema simples de registro de protocolos pode levar de 40 a 60 horas extras apenas para produzir toda a documentação exigida pelo manual: estudo de viabilidade, especificação de requisitos, arquitetura, plano de testes, manual do usuário e documentação técnica para desenvolvedores. Sem esse tempo planejado no cronograma, a equipe acaba entregando código sem documentação ou fazendo tudo nas férias. A interoperabilidade também é onde muitos projetos travam. Cada órgão tem suas próprias regras para exchange de dados. Se o sistema precisa se comunicar com outros, é obrigatório usar os padrões definidos no Perfil de Interoperabilidade da Administração Federal. Eu já vi um projeto ser aprovado tecnicamente mas depois reprovado na homologação porque a API retornava XML quando o padrão exigia JSON. Correção que levou três meses.

Pontos cegos e limitações do framework

O manual é excelente para projetos de médio e grande porte. Para projetos pequenos, como uma automação interna simples ou um dashboard rápido, as exigências podem parecer excessivas. Nesse caso, existe o caminho simplificado previsto nas próprias diretrizes, que reduz a quantidade de artefatos exigidos. A desvantagem é que o sistema resultante tem menos garantias de interoperabilidade e manutenibilidade a longo prazo. Também não existe uma ferramenta única que automatize a conformidade com o manual. A verificação é majoritariamente manual, feita por servidores lotados nas áreas de tecnologia dos órgãos. Isso significa que o tempo de análise varia muito de caso para caso. Em média, a análise técnica leva de 30 a 60 dias úteis após o envio completo da documentação. Para quem quer consultar o material, o manual está disponível gratuitamente no site da Secretaria de Reforma do Estado e também no portal da CGU. Não há um link único de download permanente porque o conteúdo é atualizado periodicamente. A versão mais recente pode ser encontrada buscando por "Manual de Engenharia de Software Administração Pública Federal" no portal.gov.br.

O certificado de conclusão do curso de engenharia de software para servidores também é uma referência útil. O curso é oferecido pela Esplanada (Escola de Governaça) e aborda tanto a parte conceitual quanto a aplicação prática das normas. Não é obrigatório para desenvolver sistemas, mas ajuda muito a entender o contexto por trás de cada exigência. Se o seu objetivo é apenas seguir o manual sem se aprofundar, existem templates prontos de documentos que aceleram o processo. Spreadsheets de estimativa de custo, modelos de termo de referência e checklists de revisão técnica estão disponíveis em repositórios de órgãos que já passaram por esse processo. Copiar e adaptar esses templates economiza entre 20 e 40 horas de trabalho em comparação com começar do zero. A parte mais difícil da engenharia de software federal não é técnica, é política. Conciliar diferentes áreas, obter aprovações em comitês de arquitetura, negociar prazos com fornecedores e manter a documentação atualizada enquanto o sistema evolui exige consistência. Nada disso aparece no manual. É experiência que só se ganha fazendo.