Desdobramento de trabalho rastreável
Cada tarefa de implementação está ligada a um requisito específico ou a um critério de aceitação — não a uma descrição de funcionalidade apenas vagamente relacionada.
Desenvolvimento e Integração · Etapa 04 · Como Trabalhamos
Uma especificação torna-se software.
O Design da Solução produz uma especificação testada e critérios de aceitação definidos. Nesta fase, essa especificação é transformada em software funcional e verificado — integrado com os sistemas com os quais deve operar e validado segundo os critérios estabelecidos antes do início do desenvolvimento.
O desenvolvimento aqui não é interpretação. Cada decisão de implementação remete para uma especificação produzida durante o design — não para aquilo que um desenvolvedor presumiu ser a intenção.
Não esta questão
"O código funciona?"
Esta pergunta, em vez disso
"O sistema construído satisfaz os critérios de aceitação definidos antes de começarmos — sob condições reais de integração, não apenas isoladamente?"
Implementação · Verificação · Integração · Rastreabilidade · Disciplina de Entrega
Por que o desenvolvimento segue o design
Nada aqui é deixado ao acaso.
Todas as entradas para esta fase foram produzidas durante Solution Design: the Solution Specification Document, the Prototype Evaluation Report, and the Acceptance Criteria & Test Plan. Desenvolver com base numa especificação não testada apenas traria de volta para o código de produção o risco que a prototipagem pretendia eliminar.
Solution Specification + Acceptance Criteria → Implementação Verificada
Por que a disciplina de entrega importa
Velocidade e estabilidade são medidas em conjunto — não se sacrificam uma pela outra.
O desempenho na entrega de software não se resume à rapidez com que uma equipe escreve código. Pesquisas de Forsgren, Humble e Kim — publicadas em Accelerate: The Science of Lean Software and DevOps (2018), com base no programa DevOps Research and Assessment (DORA) e em anos de investigação em milhares de organizações — identificaram duas categorias de desempenho de engenharia que devem ser medidas em conjunto: taxa de entrega (throughput) e estabilidade.
Lead Time
Tempo que uma alteração validada leva para ir do commit até estar pronta para implantação.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Taxa de falhas em mudanças
Percentual de mudanças que introduzem um defeito que precisa ser corrigido.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Uma equipe que entrega rapidamente, mas que frequentemente provoca falhas, não tem bom desempenho segundo essa pesquisa — e o mesmo vale para uma equipe que entrega com segurança, mas tão lentamente que deixa de ter impacto. O OpenQCore mantém ambas as dimensões em vista nesta fase, em vez de otimizar apenas a velocidade.
Da especificação à implementação
Cada trabalho está vinculado a um requisito.
O trabalho de implementação é decomposto diretamente a partir do Solution Specification e dos Acceptance Criteria — não a partir de uma compreensão geral do que o design "tinha em mente".
Definição de Pronto
Uma tarefa não está completa quando o código é escrito. Está completa quando satisfaz o critério de aceitação a que está vinculada, sob teste.
Controle de desvios da especificação
Quando a implementação revela uma lacuna ou ambiguidade na especificação, a especificação é atualizada e revisada — não reinterpretada em silêncio por quem estiver a escrever o código naquele dia.
Verificação orientada por testes
A verificação ocorre em todos os níveis, não apenas no fim.
O OpenQCore organiza a verificação segundo a pirâmide de testes — um quadro amplamente usado, popularizado por Mike Cohn, para equilibrar a cobertura de testes entre as camadas de um sistema em vez de concentrá-la em testes end-to-end, lentos e dispendiosos.
Testes unitários
Verificação rápida e isolada de componentes individuais em relação ao comportamento especificado — incluindo o comportamento com entradas inválidas.
Testes de integração
Verificação de que os componentes interagem corretamente, de acordo com os contratos de dados definidos durante o projeto da solução.
Testes de ponta a ponta
Verificação de fluxos de trabalho completos em relação aos critérios de aceitação definidos antes do início do desenvolvimento — a camada mais restrita e cara, reservada apenas ao que realmente exige esse nível.
O objetivo não é maximizar a quantidade de testes. É ter confiança de que os critérios de aceitação estão realmente atendidos, na camada de menor custo capaz de comprová-lo.
Testes de Integração e de Contrato
Um contrato de API só é real se for testado, não apenas documentado.
Os contratos de dados e de API especificados durante o projeto da solução não são tratados como mera documentação a ser seguida informalmente. OpenQCore aplica testes de contrato orientados pelo consumidor — uma abordagem formalizada em ferramentas como o Pact — em que cada ponto de integração é verificado contra um contrato executável que ambas as partes da integração devem satisfazer.
Isso é especialmente relevante para sistemas que precisam se conectar à infraestrutura existente: um contrato checado apenas por revisão manual pode divergir silenciosamente à medida que qualquer lado muda. Um contrato testado automaticamente não.
Revisão de Código e Verificação Estática
Um segundo revisor detecta o que o autor não vê.
Pesquisas amplamente citadas sobre revisão por pares — incluindo o estudo realizado na Cisco Systems e popularizado em Cohen et al.'s Best Kept Secrets of Peer Code Review — mostram que a eficácia da revisão depende muito do ritmo e do escopo: revisões menores e mais frequentes, feitas sem pressão de tempo, detectam substancialmente mais defeitos do que revisões extensas realizadas rapidamente.
OpenQCore aplica revisão de código estruturada em paralelo à análise estática automatizada — checagem de estilo, complexidade e buscas por vulnerabilidades conhecidas — como uma camada permanente de verificação, não como uma etapa opcional antes do merge.
Pipeline de Integração Contínua
Cada alteração é verificada da mesma forma, automaticamente.
Commit → Build automatizado → Testes de unidade e de integração → Análise estática e de segurança → Verificação de contratos → Pronto para implantação.
Verificação manual e inconsistente não escala e não produz um sinal confiável sobre se uma alteração é realmente segura para ser liberada — essa determinação é feita na próxima etapa, Implantação e Habilitação. O que esta etapa garante é que uma alteração que chegar a esse portão já foi verificada segundo o mesmo padrão automatizado aplicado a todas as alterações anteriores.
Práticas de Desenvolvimento Seguras
A segurança é verificada durante o desenvolvimento, não apenas auditada depois.
As práticas de desenvolvimento da OpenQCore estão alinhadas com a estrutura descrita no Secure Software Development Framework (SP 800-218) do NIST — organizando a atividade de segurança em preparar a organização, proteger o software, produzir software bem seguro e responder a vulnerabilidades.
Verificação de Dependências e Vulnerabilidades
Escaneamento automatizado das dependências de terceiros em busca de vulnerabilidades conhecidas, integrado ao pipeline padrão — não uma auditoria manual periódica.
Modelagem de Ameaças
Consideração estruturada de como um componente pode ser mal utilizado, baseada nos modos de falha definidos durante o projeto da solução.
Implementação do Princípio do Menor Privilégio
Escopos de acesso e permissões implementados no nível mais restrito que satisfaça a especificação — não no nível mais amplo por conveniência.
O Portão de Verificação de Integração
Um build não está pronto só porque compila.
Toda alteração precisa passar por um portão de verificação definido antes de ser considerada para implantação.
Pronto para Implantação
Todos os critérios de aceitação foram cumpridos, verificados por meio de testes automatizados, verificação de contratos e varredura de segurança.
Retornar para correções
Defeitos identificados devem ser corrigidos antes que esta alteração possa prosseguir.
Retornar ao projeto
A implementação revelou que a própria especificação não se sustenta em condições reais — a resposta correta é revisar a especificação, não contorná‑la via código.
Escalar risco
Foi identificado um risco de segurança, conformidade ou arquitetural que exige uma decisão acima da autoridade da equipe de desenvolvimento.
Uma pipeline que sempre chega a "pronta para implantação" não está verificando nada.
O que esta etapa produz
Software pronto para a decisão de implantação — ainda não implantado.
Conforme o escopo do projeto, esta etapa produz:
Base de código verificada
Implementação rastreável à especificação e que atende a todas as camadas de verificação definidas.
Relatório de cobertura de testes
Resultados de testes unitários, de integração e de ponta a ponta, mapeados aos critérios de aceitação.
Conjunto de testes de contrato
Verificação executável de cada ponto de integração definido durante o projeto da solução.
Registros de revisão de código
Histórico de revisões documentado e resolução das questões levantadas.
Resultados da varredura de segurança
Achados sobre dependências, vulnerabilidades e análise estática, e as ações tomadas para resolvê‑los.
Documentação do pipeline de CI
A pipeline de verificação automatizada aplicada a esta mudança e a todas as mudanças subsequentes.
Do Desenvolvimento à Implantação e Habilitação
Software verificado ainda não está em produção.
Desenvolvimento e Integração produz software verificado em relação à sua especificação — não software que foi lançado, monitorado ou comprovado estável sob carga real de produção. A próxima etapa define como, quando e com que segurança esse software chegará efetivamente à produção.
Especificação da solução → Implementação verificada → Implantação e Habilitação
Etapa 05
Implantação e Habilitação
Implantar o software verificado em produção de forma segura, deliberada e com um caminho definido para reversão.
Referências de Pesquisa e Metodologia
Forsgren, N., Humble, J. e Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud — pesquisa DORA State of DevOps
Fonte das métricas de desempenho de entrega mencionadas acima.
Cohn, M. — Succeeding with Agile (2009)
Fonte do conceito da pirâmide de testes citado acima na seção sobre verificação orientada a testes.
Cohen, J. et al. — Best Kept Secrets of Peer Code Review (SmartBear, baseado em pesquisa na Cisco Systems)
Fonte das conclusões sobre a eficácia das revisões de código mencionadas acima.
Pact / Contratos orientados pelo consumidor
Uma abordagem consolidada para contratos de integração executáveis e verificados automaticamente, citada acima na seção de testes de integração.
NIST — Secure Software Development Framework, SP 800-218
Fonte da estrutura mencionada acima nas práticas de desenvolvimento seguro.