Fases 6 a 9 — Implementação, QA, homologação e implantação (S)

Fase 6 — Implementação assistida por IA

Regra central

A implementação assistida por IA só deve ocorrer após a história estar em estado Ready for Dev, com:

• requisito vinculado;
• critério de aceite;
• caso de teste definido;
• arquitetura suficiente;
• dados e restrições conhecidos;
• definição de evidência esperada.

A implementação está vinculada à construção com testes, evidências e amarração explícita com a especificação — ver IMP — Implementação.

Uso aceitável de IA na implementação

Uso	Permitido?	Condição
Gerar código a partir de história especificada	Sim	Com revisão e testes
Refatorar componente	Sim	Sem alterar comportamento sem registro
Criar testes unitários	Sim	Devem corresponder aos CTs definidos
Sugerir melhoria arquitetural	Sim	Se virar ADR quando relevante
Criar código sem história	Não	Salvo spike controlado
Alterar regra de negócio por sugestão da IA	Não	Exige validação de negócio
Introduzir dependência nova	Com restrição	Exige justificativa e scan
Corrigir bug sem evidência	Não	Deve haver issue, teste e evidência

Produtos de mercado

Classe	Produtos sugeridos
IDE assistida por IA	Cursor, GitHub Copilot, JetBrains AI, Codeium/Windsurf
Agente de codificação	Claude Code, Codex, Cursor Agent
Revisão de código	GitHub Copilot Code Review, SonarQube, CodeRabbit, Snyk Code
Documentação assistida	ChatGPT, Claude, Gemini, NotebookLM
Testes assistidos	GitHub Copilot, CodiumAI/Qodo, Playwright Codegen

Atenção especial

A fábrica deve evitar “vibe coding”, isto é, código produzido sem lastro documental. No contexto SinergIA, toda implementação deve responder:

1. Qual necessidade originou isso?
2. Qual história autorizou isso?
3. Qual critério de aceite será usado?
4. Qual caso de teste comprova?
5. Qual evidência será entregue?
6. Qual decisão técnica sustenta?
7. Qual pessoa validou?

---

Fase 7 — Testes, qualidade e segurança

Princípio operacional

Os testes devem nascer na especificação e ser executados depois da implementação.

Especificação
  → define critérios de aceite
  → define casos de teste
  → orienta implementação
  → testes são automatizados/executados
  → evidência comprova entrega

Tipos de teste

Tipo	Momento de definição	Momento de execução	Ferramentas
Teste de critério de aceite	Especificação	Homologação/sprint	Jira, Zephyr, Xray, TestRail
Teste unitário	Especificação técnica/implementação	Pipeline	Jest, Vitest, JUnit, PyTest
Teste de integração	Arquitetura/implementação	Pipeline/homologação	Postman, Newman, REST Assured
Teste E2E	Especificação de fluxo	Homologação/pipeline	Playwright, Cypress, Selenium
Teste de regressão	Após estabilização	Pipeline/release	Playwright, Cypress
SAST	Implementação	PR/pipeline	SonarQube, Semgrep, Snyk
DAST	Homologação	Pré-release	OWASP ZAP, Burp Suite
Teste de acessibilidade	UX/especificação	Homologação	axe DevTools, Lighthouse
Teste de carga	Arquitetura/NFR	Pré-release	k6, JMeter, Gatling

Gates de qualidade

Gate	Critério sugerido para médio porte
Build	Sem erro
Lint	Sem erro bloqueante
Testes unitários	100% dos testes passando
Cobertura	Meta inicial entre 60% e 80%, conforme criticidade
Sonar	Sem blocker/critical não justificado
Dependências	Sem vulnerabilidade crítica aberta
E2E	Fluxos críticos passando
DAST	Sem vulnerabilidade alta/crítica sem plano
Acessibilidade	Fluxos principais verificados
Evidência	Relatórios anexados à entrega

Em modo completo, o SinergIA pode exigir cobertura de testes definida (por exemplo, ≥ 80%). Para médio porte em modo essencial, esse número pode ser meta progressiva, ajustada por criticidade e viabilidade técnica.

---

Fase 8 — Homologação e aceite

Objetivo

Comprovar que a entrega atende ao negócio, à especificação, aos testes, à qualidade e às restrições.

Pacote de homologação por entrega

Item	Evidência
Histórias entregues	Lista de HNU/HI/HUX/etc.
Requisitos vinculados	Matriz de rastreabilidade
Critérios de aceite	Checklist de aceite
Casos de teste	Relatório de execução
Evidência funcional	Prints, vídeos, logs ou registros
Qualidade técnica	Relatório Sonar/lint/testes
Segurança	Scan aplicável
Dados pessoais	Checklist PDP atualizado
Pendências	Lista de débitos técnicos e riscos
Aceite	Registro do validador de negócio

Regra de aceite

Uma entrega não deve ser aceita apenas porque “funciona visualmente”. Deve ser aceita porque:

necessidade → requisito → história → implementação → teste → evidência → validação

---

Fase 9 — Implantação e sustentação

Objetivo

Garantir que a entrada em produção seja controlada, rastreável e reversível.

Itens mínimos

Item	Conteúdo
Plano de release	Escopo, data, responsável, riscos
Checklist de produção	Build, testes, segurança, backup, rollback
Plano de rollback	Critério e procedimento
Observabilidade	Logs, métricas, alertas
Registro de mudança	Vinculado ao ITSM
Comunicação	Usuários, suporte, área demandante
Evidência pós-deploy	Logs, monitoração, smoke tests

Ferramentas

Finalidade	Produtos
CI/CD	GitHub Actions, GitLab CI, Azure Pipelines, Jenkins
Infraestrutura como código	Terraform, OpenTofu, Ansible
Containers	Docker, Kubernetes, OpenShift
Observabilidade	Grafana, Prometheus, Elastic, OpenTelemetry
ITSM	GLPI, Jira Service Management, ServiceNow, BMC Helix
Gestão de mudanças	ITSM institucional, CAB, workflow de mudanças

---

Anterior: Fases 4–5 · Próximo: Fábrica de software