SDLC: O Ciclo de Vida do Desenvolvimento de Software — Referência Prática

21 de jul. de 2026 · por Dionisio

Diagrama mostrando as fases do ciclo de vida de desenvolvimento de software conectadas em loop contínuo

Engenharia de Software · Processo · Referência

SDLC não é burocracia. É a diferença entre entregar e afundar.

Todo dev encontra o muro uma hora: o projeto que era "simples" três meses atrás agora é um labirinto de features não testadas, requisitos confusos e um deploy segurado por um script shell e uma oração. Isso não é azar. É SDLC ruim.

Waterfall Agile DevOps CI/CD

Em 2012, a Knight Capital perdeu US$ 440 milhões em 45 minutos porque um script de deploy foi executado em 7 de 8 servidores. Um servidor ainda rodava o código antigo. O resultado: o algoritmo de trading comprou caro e vendeu barato, 4 milhões de vezes, antes que alguém conseguisse pará-lo.

Isso não é erro de código. É falha de SDLC. Sem ambiente de staging, sem rollout faseado, sem plano de rollback.

SDLC — o Ciclo de Vida do Desenvolvimento de Software — costuma ser tratado como tópico chato de faculdade. Coisa que gerente fala enquanto dev revira os olhos. Mas quando você tira o jargão, SDLC é simplesmente a resposta para uma pergunta: como transformamos uma ideia em software funcionando sem nos destruir no processo?

Vou te mostrar o que realmente importa, fase por fase, com exemplos reais que você pode usar amanhã.

As Seis Fases Que Realmente Importam

Todo modelo de SDLC — Waterfall, Agile, Spiral, DevOps, qualquer um — mapeia para estas seis atividades. A diferença entre os modelos está em como você as sequencia e sobrepõe, não em se você as executa.

Planejamento → Análise → Design → Implementação → Testes → Manutenção
      ↑                                                       ↓
      └───────────────────────────────────────────────────────┘

Pule qualquer fase e você estará pagando juros sobre uma dívida técnica que compõe diariamente.

Fase 1: Planejamento — “O que vamos construir e por quê?”

Não se trata de gráficos de Gantt. Se trata de alinhamento. Se o time não consegue responder “qual problema isso resolve?” em uma frase, o projeto já está em risco.

Entregáveis que realmente importam:

┌─────────────────────────────────────────────┐
│ Project Charter (1 página no máximo)        │
│                                              │
│ Problema: Usuários não conseguem exportar    │
│           seus dados em lote. Export manual   │
│           leva 40 minutos.                    │
│                                              │
│ Solução: Export CSV/JSON com 1 clique e       │
│          processamento assíncrono.            │
│                                              │
│ Métrica de sucesso: Export conclui em <5s     │
│           para até 100K registros.            │
│                                              │
│ Stakeholders: Produto (Maria), Engenharia     │
│               (Você), Suporte (James)          │
│                                              │
│ Restrições: Deve funcionar com a arquitetura   │
│             S3 existente. Sem nova infra.      │
└─────────────────────────────────────────────┘

Anti-padrão: “A gente vai descobrindo enquanto constrói.” Isso funciona num hackathon de fim de semana. Fracassa espetacularmente quando três times dependem do contrato da sua API e nenhum deles sabe qual vai ser o formato da resposta.

A única pergunta de planejamento que importa: se der certo, como vamos saber?

Fase 2: Análise — “O que exatamente o sistema precisa fazer?”

É aqui que requisitos passam de “o app precisa ser rápido” para “o endpoint de busca deve retornar resultados em menos de 200ms no percentil 95 com até 50 usuários simultâneos.”

Requisitos funcionais respondem o quê. Requisitos não-funcionais respondem quão bem.

# requisitos.yaml — formato que times reais usam
funcionais:
  - id: RF-001
    descricao: "Usuário pode exportar todos os dados como CSV"
    aceitacao: "Clicar em 'Exportar Tudo' baixa um CSV em até 5 segundos"
    prioridade: P0

  - id: RF-002
    descricao: "Usuário pode filtrar exportações por período"
    aceitacao: "Date picker permite selecionar início/fim, export respeita o período"
    prioridade: P1

nao_funcionais:
  - id: RNF-001
    descricao: "Endpoint de export suporta 50 requisições simultâneas"
    metrica: "Latência p95 < 5s com 50 usuários simultâneos"

  - id: RNF-002
    descricao: "Arquivos exportados devem ser criptografados em repouso"
    metrica: "Criptografia AES-256 em todos os arquivos gerados no S3"

Anti-padrão: “O gerente de produto disse que deve funcionar igual ao Notion.” Requisitos vagos produzem software vago. Se você não consegue testar, você não definiu.

Fase 3: Design — “Como o sistema vai funcionar?”

Design tem duas camadas: alto nível (arquitetura) e baixo nível (componente/módulo). Ambos importam. Nenhum deveria levar meses.

Architecture Decision Records (ADRs) são a ferramenta de design mais subestimada:

# ADR-003: Processamento de Export via Background Jobs

## Status
Aceito (2026-03-15)

## Contexto
Usuários precisam exportar até 100K registros. Processamento síncrono
causaria timeout HTTP (Heroku tem limite de 30s).

## Decisão
Usar BullMQ (fila baseada em Redis) para processamento assíncrono.
Worker gera CSV → faz upload para S3 → envia email com URL assinada.

## Alternativas consideradas
- AWS Lambda: Rejeitado. Limite de 15min pode não bastar em cenários
  de cold-start com exportações grandes.
- Sidekiq (Ruby): Rejeitado. Time é Node.js nativo, Ruby adiciona
  complexidade operacional.

## Consequências
- Nova dependência Redis (já usado para cache, sem infra nova)
- Usuários precisam aguardar email (aceitável conforme RF-001)

Anti-padrão: “Vamos projetar pra escala desde o dia um.” Você está construindo para 100 usuários, não 100 milhões. Projete para mudança, não para escala hipotética. Um sistema fácil de modificar vai escalar quando precisar. Um sistema projetado para tráfego da Netflix vai te falir antes de você achar product-market fit.

Fase 4: Implementação — “Escreve o código”

Isso é o que a maioria dos devs acha que SDLC é. Não é. É uma fase de seis. E é aquela onde decisões ruins das fases anteriores se tornam dolorosamente visíveis.

Higiene prática de implementação:

# Estratégia de branches que não precisa de PhD
main         ← produção (deployável a qualquer momento)
  └─ develop ← branch de integração
       ├─ feat/export-csv       ← RF-001
       ├─ feat/export-filtros   ← RF-002
       └─ fix/export-timeout    ← bug encontrado nos testes

# Convenção de commits — torne o git log útil
feat(export): adiciona geração CSV com streaming
fix(export): previne OOM em registros >50K
docs(api): documenta parâmetros do endpoint de export
test(export): adiciona testes de integração para filtro por data

Checklist de code review que pega 80% dos problemas:

[ ] Esta mudança corresponde ao requisito que diz atender?
[ ] Existem testes que falhariam se a lógica estiver errada?
[ ] O tratamento de erros é explícito (não "não deveria acontecer na prática")?
[ ] Tem logs que eu consigo grep em produção às 3 da manhã?
[ ] O PR explica *por quê*, não só *o quê*?
[ ] Se isso quebrar em produção, qual é o plano de rollback?

Anti-padrão: Pular code review porque “é uma mudança pequena.” O desastre da Knight Capital? Foi uma “mudança pequena” — uma flag de deploy que não foi removida corretamente.

Fase 5: Testes — “Funciona mesmo?”

Teste não é uma fase que acontece depois da implementação. É uma atividade que roda durante todo o SDLC. Mas a verificação formal tem camadas:

                    /\
                   /E2E\          ← O sistema inteiro funciona?
                  /------\
                 /Integração\     ← Os componentes funcionam juntos?
                /------------\
               /   Unitários  \   ← Cada função funciona?
              /------------------\
             /  Análise Estática  \ ← O código segue as regras?
            /-----------------------\

Exemplos reais em cada camada:

# Camada 1: Análise estática (CI roda primeiro — feedback grátis)
# .eslintrc.json, pyproject.toml, go vet — pega bugs sem rodar código

# Camada 2: Testes unitários (milissegundos cada, milhares deles)
def test_export_query_filtra_por_periodo():
    query = build_export_query(
        user_id=42,
        data_inicio="2026-01-01",
        data_fim="2026-06-30"
    )
    assert "WHERE created_at BETWEEN" in query
    assert "'2026-01-01'" in query
    assert "'2026-06-30'" in query

# Camada 3: Testes de integração (verificam comportamento real com banco)
def test_export_endpoint_retorna_202_com_token_valido():
    response = client.get("/api/export", headers={"Authorization": f"Bearer {token}"})
    assert response.status_code == 202  # Aceito, processando assíncrono

# Camada 4: Testes E2E (simulam fluxos reais do usuário)
# cypress/integration/export.spec.js
it('usuário exporta dados e recebe email', () => {
    cy.login('testuser@example.com')
    cy.visit('/dashboard')
    cy.get('[data-testid="export-all-btn"]').click()
    cy.contains('Sua exportação está sendo processada').should('be.visible')
    // Verifica email recebido (via Mailpit API no ambiente de teste)
})

Quanto teste é suficiente? A resposta é outra pergunta: qual o custo de um bug em produção? Se você está construindo um contador de calorias, um edge case perdido é um incômodo menor. Se está construindo um sistema de pagamentos, é um reembolso, um chargeback e uma auditoria de compliance. Calibre a profundidade dos testes com o custo da falha.

Fase 6: Manutenção — “O código vive. E agora?”

Software passa 60-80% do seu ciclo de vida em manutenção. Se você projetou apenas para a construção inicial, projetou para 20% da vida do sistema.

Modos de manutenção e o que exigem:

Modo	Significado	Exemplo
Corretiva	Corrigir bugs encontrados em produção	`NullPointerException` quando usuário não tem avatar
Adaptativa	Adaptar a mudanças no ambiente	Migrar do Node 18 para Node 22 porque 18 saiu de LTS
Perfectiva	Melhorar funcionalidades existentes	Adicionar barra de progresso no export (usuários reclamaram)
Preventiva	Corrigir antes que aconteça	Refatorar query de export antes de atingir o limite de 100K

O teste decisivo da manutenibilidade: Um dev novo consegue fazer onboarding, ler o README, rodar make setup e fazer o primeiro commit no mesmo dia? Se não, sua superfície de manutenção é grande demais.

Modelos de SDLC: Quando Usar Cada Um

Não existe “melhor” modelo de SDLC. Existe “melhor para este projeto específico.”

Waterfall

Requisitos → Design → Implementação → Testes → Deploy → Manutenção

Use quando: Requisitos são fixos e bem compreendidos. Exemplo: construir software de compliance para uma regulamentação que não vai mudar por 5 anos.

Não use quando: Você está construindo o produto de uma startup e pivotando a cada duas semanas.

Exemplo real: Firmware de dispositivo médico. O FDA exige uma matriz de rastreabilidade do requisito ao caso de teste. Você não pode “iterar” no firmware de um marca-passo — cada mudança exige re-certificação.

Agile (Scrum/Kanban)

Sprint 1: Planejar → Construir → Testar → Review → Retro
Sprint 2: Planejar → Construir → Testar → Review → Retro
Sprint 3: Planejar → Construir → Testar → Review → Retro
                         ↓
              Software funcionando a cada 2 semanas

Use quando: Requisitos evoluem. O usuário não sabe exatamente o que quer até ver funcionando.

Não use quando: Você tem 20 devs juniores e nenhum Scrum Master. Agile sem disciplina vira caos com reuniões diárias.

Exemplo real: Um dashboard SaaS. Usuários dizem que querem “analytics.” Sprint 1 entrega um gráfico básico. Sprint 3 adiciona filtros. Sprint 5 adiciona export. Cada sprint produz algo usável — o time nunca fica 6 meses sem entregar nada.

DevOps / Continuous Delivery

Código → Build → Teste → Stage → Deploy → Monitor → (dispara próximo ciclo)
  ↑____________________________________________________________↓

Use quando: Você tem usuários pagantes que esperam zero downtime e atualizações frequentes.

Não use quando: Seu processo de deploy é “FTP o arquivo JAR no servidor e restartar o Tomcat.” Você precisa de infra de CI/CD primeiro.

Pipeline real de exemplo:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint        # análise estática (< 10s)
      - run: npm test            # unitários + integração (< 2 min)

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - run: deploy-to-environment staging
      - run: npm run e2e         # E2E contra staging (< 5 min)

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: deploy-to-environment production
      - run: notify-slack "Deploy realizado: $(git log -1 --oneline)"

Anti-Padrões de SDLC Que Destroem Projetos

Padrões que eu já vi fracassar, repetidamente, em empresas de todos os tamanhos:

1. “Paralisia por Análise” — Seis meses de levantamento de requisitos para um projeto de três meses. O mercado andou. As premissas estão obsoletas. Você otimizou para um mundo que não existe mais.

Solução: Time-box no planejamento. Se você não consegue definir o MVP em duas semanas, o problema é vago demais. Quebre em partes menores.

2. “Teatro de Testes” — 90% de cobertura de código mas todo teste faz mock do banco de dados. Você está testando mocks, não comportamento. Os testes passam. O sistema falha.

Solução: Escreva testes que pegariam o último bug que você enviou para produção. Se um teste não teria pegado aquele bug, é peso morto.

3. “O Handoff de Silos” — Time de Dev joga código por cima do muro para o QA. QA joga bugs por cima do muro para Dev. Ops joga problemas de deploy para Dev. Ninguém conversa. Tudo leva três vezes mais tempo.

Solução: Embeba QA no time de dev. Faça deploy ser responsabilidade de dev. Quem escreve o código deve vê-lo rodando em produção.

4. “Documentação como Reflexão Tardia” — “A gente documenta depois” é a mentira mais cara do software. Seis meses depois, o time original saiu e o time novo está fazendo engenharia reversa do código pelo git blame.

Solução: Documentação vive no repo, junto do código. ADRs em /docs/adr/. Documentação de API gerada a partir de anotações no código. README que realmente explica como rodar o projeto.

Escolhendo Seu SDLC: Framework de Decisão

Responda estas quatro perguntas. As respostas dizem qual modelo se encaixa:

1. Quão estáveis são os requisitos?
   Estáveis → Waterfall
   Evoluindo → Agile
   Desconhecidos → Lean/Protótipo primeiro

2. Qual o tamanho do time?
   1-5 pessoas → Kanban (leve)
   6-20 pessoas → Scrum
   20+ pessoas → Agile escalado (SAFe, LeSS) ou divida em times menores

3. Quão críticos são os bugs?
   Críticos para vida (medicina, aviação) → Waterfall + V-model
   Críticos para receita (fintech, ecommerce) → Agile + testes automatizados pesados
   Nível de incômodo (ferramentas internas) → Agile, entregue rápido, corrija em produção

4. Qual a frequência de deploys?
   Mensal/trimestral → Waterfall ou Scrum
   Semanal → Scrum + CI/CD
   Diário/múltiplos por dia → DevOps com pipeline CI/CD completo

Referências

Engenharia de Software — Ian Sommerville. O livro-texto definitivo. Leia os capítulos 2-4 para fundamentos de SDLC.
The Phoenix Project — Gene Kim, Kevin Behr, George Spafford. Um romance de negócios que explica DevOps melhor que qualquer livro técnico.
Accelerate — Nicole Forsgren, Jez Humble, Gene Kim. Os dados por trás do que torna organizações de tecnologia de alta performance.
Continuous Delivery — Jez Humble, David Farley. A bíblia de CI/CD. Escrito em 2010, ainda é a referência.
Google SRE Book — Gratuito em sre.google. Capítulos sobre gerenciamento de mudanças e resposta a incidentes são diretamente aplicáveis à fase de Manutenção.
Relatório Knight Capital — SEC File No. 3-15570. Leia o relatório real de como US$ 440 milhões foram perdidos em 45 minutos. Leitura obrigatória para quem acha que “é só um deploy.”

SDLC não é um documento que você escreve uma vez e esquece. É um conjunto de práticas que respondem à pergunta mais difícil do software: como transformamos uma ideia em software que funciona, de forma confiável?

Pule a burocracia. Mantenha a disciplina. Entregue software funcionando.