SDLC — Base (8 fases) (S)
Abrir apresentação desta página
Sobre este conjunto de páginas
Seção intitulada “Sobre este conjunto de páginas”Este material consolida quatro camadas de visão sobre o ciclo de desenvolvimento de sistemas (SDLC):
- Base — as 8 fases com entregáveis e gates de aprovação (esta página)
- Spec-driven — o que muda em cada fase quando a especificação formal governa o ciclo
- IA assistida — o que a IA faz, com qual autonomia, e o que o humano mantém
- SinergIA — onde o framework atua, o que provê, o que não é sua responsabilidade e qual ganho entrega (inclui mapa por fase, síntese e referências)
Como ler SinergIA (F) e (M) no mapa integrado
Seção intitulada “Como ler SinergIA (F) e (M) no mapa integrado”Na página Mapa SinergIA e síntese:
- (F) — alinhamento com princípios ou páginas já publicadas no framework SinergIA (ver também Referências no framework).
- (M) — orientação desta modelagem SDLC (spec-driven + IA); deve ser validada no contrato, na governança institucional ou em ADR antes de ser tratada como norma do projeto.
1. SDLC Base
Seção intitulada “1. SDLC Base”As 8 fases do ciclo, com entregáveis e fronteiras de aprovação.
| Fase | O que acontece | Entrada (inicia quando…) | Saída (entregáveis) | Gate de aprovação | Responsável |
|---|---|---|---|---|---|
| 01 · Descoberta | Levantamento de necessidade, viabilidade, escopo inicial, stakeholders identificados | Demanda formalizada por área de negócio ou produto | Documento de visão, estudo de viabilidade, lista de stakeholders | Aprovação de escopo | Product Owner / Sponsor |
| 02 · Requisitos | Elicitação, análise e especificação detalhada de requisitos funcionais e não-funcionais | Documento de visão aprovado | SRS / backlog priorizado, critérios de aceite, requisitos de segurança e compliance | Baseline de requisitos | Analista / PO |
| 03 · Arquitetura | Design de solução técnica, ADRs, seleção de tecnologias, modelo de dados, segurança por design | Requisitos baselineados e aprovados | Documento de arquitetura, ADRs, diagramas C4, modelo de ameaças | Revisão arquitetural | Arquiteto / Tech Lead |
| 04 · Implementação | Desenvolvimento do código, testes unitários, revisão de pares, integração contínua | Arquitetura aprovada; ambiente de dev provisionado | Código versionado, cobertura ≥ threshold definido, build verde no CI | Pull request aprovado + CI verde | Dev / Tech Lead |
| 05 · Qualidade (QA) | Testes de integração, regressão, performance, segurança (SAST/DAST), validação de aceite | Build aprovado; ambiente de homologação disponível | Relatório de testes, defeitos triados, evidência de cobertura, sign-off de QA | Sign-off de qualidade | QA Engineer |
| 06 · Homologação (UAT) | Validação pelo usuário final ou área de negócio; confirmação de aderência aos requisitos | Sign-off de QA; usuários-chave disponíveis | Ata de aceite, lista de pendências, aprovação formal do usuário | Aceite do usuário | Usuário-chave / PO |
| 07 · Deploy | Publicação em produção, ativação de feature flags, monitoramento inicial pós-deploy | Aceite de UAT; janela de manutenção aprovada; rollback documentado | Artefato em produção, runbook de deploy, registro de mudança (ITSM) | Change Advisory Board (ou equivalente) | DevOps / SRE |
| 08 · Operação | Monitoramento contínuo, SLA/SLO, gestão de incidentes, patches, retroalimentação para ciclo seguinte | Sistema ativo em produção | Relatórios de SLA, post-mortems, backlog de melhorias, decisão de descontinuação | Revisão periódica (GoLive review) | SRE / Product Owner |
Princípio das fronteiras: cada fase só avança após o gate correspondente ser satisfeito. As fronteiras são os pontos de controle que impedem a propagação de defeitos para etapas posteriores. Um requisito ambíguo que passa da fase 2 para a fase 4 custa ordens de magnitude mais para corrigir.
Gates no setor público e contratos: nomes como CAB, ITSM ou janela de manutenção são exemplos típicos de TI corporativa. Na administração pública brasileira, mapeie para os mecanismos reais (ex.: comitê de mudança interno, registro em ferramenta de serviço, PCA, ordem de serviço, fiscalização técnica, aceite formal previsto no instrumento contratual).
1.1 Mapeamento SDLC (8 fases) ↔ pontos de vista SinergIA
Seção intitulada “1.1 Mapeamento SDLC (8 fases) ↔ pontos de vista SinergIA”O framework organiza o trabalho por pontos de vista (PV) e artefatos; o SDLC deste documento é uma visão em oito fases compatível com esse modelo. A tabela a seguir é orientativa — o instrumento contratual e os ADRs prevalecem.
| Fase SDLC | PVs e ênfases no SinergIA | Artefatos / âncoras no site |
|---|---|---|
| 01 · Descoberta | ARC (descoberta e concepção); GTI (enquadramento de risco e uso de IA, quando aplicável) | ARC — descoberta; GTI; artefatos BRD / PRD conforme o projeto |
| 02 · Requisitos | ESP (histórias tipificadas, critérios de aceite, rastreabilidade) | ESP — Especificação; estrutura de artefatos |
| 03 · Arquitetura | ARC (etapa de arquitetura); GTI (decisões registradas em ADR) | ARC — arquitetura (etapa); ADR — GTI |
| 04 · Implementação | IMP; PRO (prototipação quando aplicável) | IMP; PRO |
| 05 · Qualidade (QA) | QA; ligação com IMP (testes, CI) e GTI (risco) | QA — qualidade no ciclo; IMP |
| 06 · Homologação (UAT) | ESP (aceite vinculado a critérios); HC / histórias de conformidade quando o aceite for normativo | ESP; histórias HC na especificação |
| 07 · Deploy | IMP (CI/CD operacional); INF (requisitos de plataforma e pipeline — no site público completo também no brainstorm) | IMP — CI/CD operacional; INF |
| 08 · Operação | SIS (sustentação e modernização); GTI; PDP / GDA quando houver dados e continuidade | SIS; GTI; PDP; GDA |
Próximo: SDLC — Spec-driven →