Skip to main content

Software Development Life Cycle (SDLC)

Não existe uma única "documentação oficial" universal para o SDLC, o ciclo de desenvolvimento de software, porque ele é um conceito, não um produto.

Pense nisso como três camadas diferentes de um mesmo assunto:

  • Camada 1: O Conceito Fundamental

    • SDLC (Software Development Life Cycle): Este é o conceito universal e genérico de que todo software tem um ciclo de vida: nasce de uma ideia, é planejado, projetado, construído, testado e mantido. É a ideia-mãe. Não diz como fazer, apenas que essas fases existem.

  • Camada 2: A Metodologia (A Abordagem de Trabalho)

    • Aqui é onde você escolhe COMO sua equipe vai percorrer as fases do SDLC. É a sua filosofia de trabalho. Na maioria das vezes será alguma metodologia Ágil (Agile - como Scrum ou Kanban), mas tudo depende do tipo de software que queremos desenvolver. Quando os requisitos não podem mudar podemos utilizar a metodologia cascata.
    • Você faz todas as fases do SDLC usando estas metodologias.
    • Esta é a camada que mais impacta o dia a dia da equipe de desenvolvimento. É o motor do processo.

  • Camada 3: O Framework ou Padrão (O Blueprint Detalhado):

    • Aqui estão os "manuais" ou "conjuntos de regras" que definem QUAIS atividades, artefatos e controles específicos devem existir no seu processo, independentemente da metodologia.

Existem padrões internacionais e frameworks publicados por organizações de renome que são considerados as documentações mais próximas de "oficiais" que você pode encontrar. Eles estabelecem diretrizes e melhores práticas que são adotadas globalmente. Na verdade tudo depende das exigências que a equipe de desenvolvimento precisa ter.

Aqui estão as documentações mais importantes e reconhecidas que servem como padrão para o SDLC:

  1. Padrões Internacionais (O mais próximo do "Oficial") ISO/IEC/IEEE 12207: Systems and software engineering — Software life cycle processes

    • Este é o principal padrão internacional para processos de ciclo de vida de software. Ele foi desenvolvido pela ISO (Organização Internacional de Padronização), IEC (Comissão Eletrotécnica Internacional) e IEEE (Instituto de Engenheiros Eletricistas e Eletrônicos).
    • É um padrão formal, reconhecido mundialmente, que define uma estrutura comum para que qualquer organização possa desenvolver, adquirir e manter software. Ele detalha todas as atividades e tarefas necessárias.
    • A documentação da ISO é geralmente paga e pode ser adquirida através do site oficial da ISO ou de revendedores nacionais.
    • É mais importante em:
      • Governo e Setor Público: Em licitações para desenvolvimento ou aquisição de software, é muito comum que os editais exijam que a empresa fornecedora siga os processos descritos na ISO 12207 (ou na sua versão brasileira, a ABNT NBR ISO/IEC 12207). Isso serve como uma garantia de que o dinheiro público está sendo investido em um projeto com um mínimo de organização, documentação e qualidade.
      • Indústrias Altamente Reguladas: Em setores onde uma falha de software pode ter consequências graves (risco de vida, perdas financeiras enormes), a adesão a padrões rigorosos é obrigatória.
        • Aeroespacial e Defesa: Empresas como a Embraer e fornecedores das forças armadas precisam de um nível altíssimo de rastreabilidade e segurança.
        • Médica: Softwares para equipamentos médicos (como um tomógrafo ou uma bomba de infusão) precisam ser aprovados por agências reguladoras (como a ANVISA), que exigem prova de um processo de desenvolvimento robusto.
        • Automotiva e Ferroviária: O software que controla os freios de um carro ou o sistema de sinalização de um trem precisa ser extremamente confiável.
        • Bancário e Financeiro: Para garantir a segurança das transações e a conformidade com as regulações do Banco Central.
      • Grandes Contratos Internacionais e Outsourcing: Quando uma grande empresa (ex: uma multinacional) contrata outra para desenvolver um software, ela geralmente exige conformidade com a ISO 12207 no contrato. Isso garante que ambas as partes "falem a mesma língua" em termos de processos, entregas e documentação.
    • Menos usada em:
      • Startups e Empresas de Pequeno/Médio Porte: O foco principal é a velocidade de entrega e a rápida adaptação ao mercado. A formalidade e a burocracia associadas à implementação completa de uma norma ISO podem ser vistas como um obstáculo. Elas seguem processos, mas de forma muito mais leve e flexível.
      • Equipes Ágeis e DevOps "Puras": Metodologias como Scrum e Kanban já fornecem um framework de processos. Uma equipe que faz suas daily meetings, sprints, e tem um product backlog bem definido está, na prática, cumprindo o espírito de muitos dos processos da ISO 12207 (ter requisitos, desenvolver, testar, entregar), mas de uma maneira muito mais dinâmica e menos focada em documentação pesada.

    É um erro pensar que a ISO 12207 e o desenvolvimento Ágil são inimigos. A norma descreve "o quê" precisa ser feito (os processos que devem existir), mas não prescreve "como" eles devem ser implementados. O processo de análise de requisitos pode ser implementando através de User Stories em um backlog e o processo de testes podem ser automatizados com pipelines.

  2. Padrões Governamentais (Altamente Influentes)

    • NIST SP 800-218: Secure Software Development Framework (SSDF)
      • Publicado pelo NIST (Instituto Nacional de Padrões e Tecnologia dos EUA), este documento define um conjunto de práticas de desenvolvimento de software seguro. Ele não dita um modelo de SDLC específico, mas descreve práticas de segurança que devem ser integradas em cada fase de qualquer modelo que você usar (Agile, DevOps, etc.).
      • É um padrão governamental dos EUA e, devido à influência do NIST na indústria de tecnologia e cibersegurança, tornou-se uma referência global para a criação de um "Secure SDLC" (SSDLC).
      • Onde encontrar: É gratuito e está disponível publicamente no site do NIST.

  3. Frameworks da Indústria (Padrões de Fato)

    • Embora não sejam "oficiais" no sentido de um órgão de padronização internacional, os seguintes frameworks são tão influentes que se tornaram padrões de fato na indústria:
      • Microsoft Security Development Lifecycle (SDL)
      • É a metodologia que a Microsoft criou e implementa para garantir que seu software seja seguro desde o início. O Microsoft SDL foi um dos primeiros e mais completos esforços para formalizar um ciclo de vida de desenvolvimento seguro.
      • Devido ao sucesso e à abrangência, ele se tornou um modelo para muitas outras empresas criarem seus próprios programas de segurança de aplicações.
      • A Microsoft disponibiliza toda a documentação, ferramentas e práticas gratuitamente. Você pode encontrar tudo no site oficial do Microsoft SDL.

  4. OWASP Software Assurance Maturity Model (SAMM)

    • O OWASP SAMM é um framework para ajudar as organizações a formular e implementar uma estratégia para segurança de software, adaptada aos seus riscos específicos.
    • É mantido pela OWASP, a principal fundação sem fins lucrativos focada em segurança de software, e é amplamente adotado como um guia prático para amadurecer as práticas de SDLC.
    • É gratuito e de código aberto, disponível no site do OWASP SAMM. Link para o PDF
    • O OWASP SAMM não é um processo para construir o software, mas sim um guia para adicionar práticas de segurança ao processo.

Independentemente da metodologia as etapas conceituais do SDLC são as mesmas. A grande diferença é como você as executa: todas de uma vez (Cascata) ou em pequenos ciclos repetitivos (Agile). Vamos detalhar cada uma das etapas clássicas do SDLC:

  1. Planejamento e Análise de Requisitos

    Pergunta que responde: O que vamos construir e por quê?

    Esta é a fase de fundação. O objetivo é entender o problema de negócio e definir o que o software precisa fazer para resolvê-lo. Erros aqui são os mais caros de corrigir mais tarde.

    Atividades Principais:

    • Análise de viabilidade (técnica, econômica, operacional).
    • Entrevistas com stakeholders (clientes, usuários, gestores) para coletar necessidades.
    • Definição do escopo do projeto (o que está dentro e o que está fora).
    • Documentação dos requisitos funcionais (o que o sistema deve fazer, ex: "o usuário deve poder se cadastrar com e-mail e senha") e não funcionais (como o sistema deve ser, ex: "a página de login deve carregar em menos de 2 segundos").

    Principais Envolvidos: Gerentes de Produto (Product Managers), Analistas de Negócios (Business Analysts), stakeholders.

    Resultado Principal: Um documento de especificação de requisitos (SRS - Software Requirements Specification) ou, em um mundo Ágil, um Product Backlog priorizado com as primeiras User Stories.

  2. Design (Projeto e Arquitetura)

    Pergunta que responde: Como vamos construir isso?

    Com os requisitos em mãos, a equipe técnica traduz o "o quê" para o "como". É aqui que o esqueleto e a planta baixa do software são criados.

    Atividades Principais:

    • Design de Arquitetura: Definir a estrutura geral do sistema (ex: microserviços vs. monolito), as tecnologias (linguagem de programação, banco de dados, cloud) e como os componentes vão se comunicar.
    • Design de Interface (UI/UX): Criar wireframes (rascunhos básicos) e mockups (protótipos visuais) de como serão as telas e a experiência do usuário.
    • Design de Dados: Modelar a estrutura do banco de dados (tabelas, relacionamentos).

    Principais Envolvidos: Arquitetos de Software, Designers de UI/UX, Desenvolvedores Sêniores (Tech Leads).

    Resultado Principal: Documentos de design técnico, diagramas de arquitetura, protótipos visuais.

  3. Desenvolvimento (Implementação ou Codificação)

    Pergunta que responde: Vamos construir!

    Esta é a fase onde as ideias e os projetos se transformam em um software funcional. Os desenvolvedores escrevem o código, seguindo as especificações da fase de design.

    Atividades Principais:

    • Escrever o código-fonte nas linguagens escolhidas.
    • Criar e gerenciar o banco de dados.
    • Escrever testes de unidade para verificar pequenas partes do código.
    • Gerenciar o código em um sistema de controle de versão (como o Git).

    Principais Envolvidos: Desenvolvedores (Front-end, Back-end, Full-stack).

    Resultado Principal: O código-fonte do software, componentes funcionais.

  4. Testes (Verificação e Validação)

    Pergunta que responde: Isso funciona corretamente e atende aos requisitos?

    O software construído é rigorosamente inspecionado para encontrar e corrigir defeitos antes que chegue ao usuário final.

    Atividades Principais:

    • Testes de Integração: Verificar se os diferentes componentes do sistema conversam entre si corretamente.
    • Testes de Sistema: Testar o software completo de ponta a ponta para garantir que ele cumpre todos os requisitos.
    • Testes de Segurança e Performance: Procurar por vulnerabilidades e gargalos de desempenho.
    • Teste de Aceitação do Usuário (UAT): Apresentar o software para os stakeholders ou um grupo de usuários para que eles validem se atende às suas necessidades.

    Principais Envolvidos: Engenheiros de QA (Quality Assurance), Desenvolvedores, Stakeholders (para o UAT).

    Resultado Principal: Um software estável e com qualidade validada, relatórios de bugs e um "sinal verde" para a implantação.

  5. Implantação (Deployment)

    Pergunta que responde: Como disponibilizamos isso para os usuários?

    O software, agora testado e aprovado, é liberado no ambiente de produção para que os usuários finais possam acessá-lo.

    Atividades Principais:

    • Preparar o ambiente de produção (servidores, nuvem).
    • Migrar o código e os dados para o ambiente final.
    • Realizar verificações finais para garantir que tudo subiu corretamente. Em DevOps, essa etapa é altamente automatizada (CI/CD).

    Principais Envolvidos: Engenheiros de DevOps, Engenheiros de Infraestrutura (Ops), SREs.

    Resultado Principal: O software rodando em produção e acessível aos usuários.

  6. Manutenção e Operação

    Pergunta que responde: Como mantemos isso funcionando bem e melhoramos com o tempo?

    Esta é a fase mais longa do ciclo de vida. O software está em uso e precisa de suporte e evolução contínua.

    Atividades Principais:

    • Monitoramento da saúde do sistema (performance, erros, segurança).
    • Correção de bugs que são descobertos pelos usuários.
    • Suporte técnico.
    • Planejamento e desenvolvimento de novas versões com melhorias e novas funcionalidades, iniciando o ciclo novamente.

    Principais Envolvidos: Equipes de Operação (Ops), Suporte, Desenvolvedores.

    Resultado Principal: Um software estável, atualizado e que continua a entregar valor.

    Lembre-se: no modelo Waterfall, você passa por essas 6 etapas uma única vez, em sequência. No modelo Ágil, sua equipe passa por uma versão "micro" de todas essas 6 etapas dentro de cada ciclo de 2 a 4 semanas (Sprint).