Modelos de Processos do SDLC

Yuri Peixinho - Feb 26 - - Dev Community

O que é?

Os modelos de SDLC (Software Development Life Cycle), apresenta conceitualmente o SDLC de forma organizada para ajudar as empresas a implementá-lo. Sabemos que o SDLC se refere ao ciclo de vida completo de um projeto, desde a concepção até a sua manutenção, enquanto, por sua vez o Modelo de Processo é uma implementação específica ou metodologia utilizada para seguir o SDLC. Ele determina como cada fase será conduzida, práticas adotadas e como as equipes irão colaborar.

O momento de escolher qual modelo de processo usar ocorre logo nas fases inicias do projeto, tipicamente quando planejamos e analisamos os requisitos.

Cada modelo possui características específicas que tornam adequados para determinados tipos de projetos, equipes e clientes. A diversidade existe pois não há uma abordagem única que funcione perfeitamente para todos os cenários. A criação de diversos modelos de SDLC reflete da necessidade de lidar com as variáveis e desafios encontrados em diferentes tipos de contextos de desenvolvimento.

Exemplos de como Modelos de Processos Aplicam o SDLC

Antes de entramos em detalhe sobre cada modelo de processo, vou exemplificar como alguns modelos implementam o ciclo de vida do desenvolvimento.

  • Modelo Cascata: Implementa de forma sequencial, onde cada fase deve ser concluída antes de se mover para a próxima, adequando-se a projetos com requisitos bem definidos e estáveis.
  • Modelo Ágil: Implementa de forma iterativa e incremental, permitindo que partes do software sejam desenvolvidos e testadas em ciclos curtos (sprints), se adptando bem a projetos com requisitos dinâmicos

Em conclusão, podemos dizer que o SDLC fornece a estrutura básica do desenvolvimento de software, enquanto o Modelo do Processo fornece a metodologia prática para implementar essa estrutura. A relação entre os dois é essencial para garantir que o processo de desenvolvimento seja realizado de forma organizada, eficiente e adapatada às necessidades específicas de cada projeto.

Modelos de Processos

Saber com profundidade e expertise esses modelos proporciona uma resposta rápida e coesa durante a fase de planejamento do projeto. Um bom analista entende interpreta as dores e necessidades do cliente de forma eficiente, e a partir delas sabe exatamente qual o melhro tipo de modelo para aquele projeto, quantos mais modelos ele conhecer, mais chance de sucesso. Embora não haja definições definitivas do processo de software, temos alguns modelos genéricos que podem ser utilizados para explicar as diferentes abordagens do desenvolvimento de software: São os principais: Cascata, Espiral, Incremental, Iterativo, Modelo V, etc..

Modelo Cascata (Waterfall)

O modelo Cascata, também conhecido como Waterfall, se baseia em uma hierarquia rídiga de etapas sequenciais. É um dos modelos mais antigos e tradicionais, introduzido na década de 1970. É um modelo que é amplamente utilizado em projeto onde os requisitos são bem compreendidos desde o início e há pouca expectativa de mudança ao longo do desenvolvimento. Nesse método, a fase de planejamento ganha grande importância no perocesso, todos os requisitos são analisados com muita prioridade em seus aspectos.

É implementado de forma sequencial, onde cada etapa deve ser concluída antes de avançar para a próxima, e cada etapa só avança a partir da aprovação dos stakeholders. Então, podemos dizer que a etapa “projeto” do SDLC só é executada a partir do acordo total dos desenvolvedores e clientes, que resolvem logo no início o produto em sua totalidade a ser desenvolvido.

Fases do Modelo Cascata

Sua estrutura possui de cinco a sete fases, que seguem de forma linear estrita. Os nomes específicas das fases variam, mas foram originalmente definidos por Royce da seguinte forma:

  • Especificação (requisitos)
  • Design
  • Implementação
  • Teste
  • Manutenção

Desse modo, cada fase de desenvolvimento ocorre uma única vez e de forma sequencial e o software é geralmente entregue apenas uma vez ao final do ciclo de desenvolvimento. Isso significa que o cliente vê o produto completo quando todas as fases forem finalizadas, o que pode levar a longos períodos de espera sem entregas funcionais intermediárias. Isso resulta em um processo menos flexível em responder mudanças.

Image description

Vantagens

  • Documentação Detalhada. Cada fase do processo gera uma documentação detalhada, o que facilita a manutenção e transferência do conhecimento
  • Controle de Qualidade. O modelo exige que cada fase seja completamente revisada e verificada antes de passar para a próxima, ajudando a garantir a qualidade
  • Estabilidade dos Requisitos: Como todos os requisitos são definidos no início, as mudanças são minimizadas, o que proporciona uma base sólida para o desenvolvimento

Desvantagens

  • Rigidez. A natureza do modelo torna difícil a adaptação de mudanças nos requisitos após a fase de especificação inicial.
  • Alto Risco. problemas encontrados posteriromente podem ser muito caros e difíceis de resolver.
  • Retorno Lento de Feedback. O cliente só verá o produto final do ciclo, o que pode resultar em um produto que não atenda às expectativas do usuário.
  • Suporte Limitado a Projetos Complexos. Esse modelo pode ser inadequado para projetos grandes e complexos onde os requisitos são mal definidos e propensos a mudanças.

Quando Usar o Modelo Cascata

  • Desenvolvimento de um Software Empresarial Tradicional. Esse tipo de projeto já tem requisitos claramente definidos, como funcionalidades para recrutamento, folha de pagamento e gestão de desempenho
  • Projeto de Sistemas Legados. As Projetos onde as funcionalidades existentes são bem conhecidas e o objetivo é apriomorar ou adicionar novos recursos.

Quando Não Usar o Modelo Cascata

  • Projetos Ágeis e Startups, onde a equipe precisa ser flexível e responder rapidamente às mudanaçs no feedback dos usuários e prioridades de negócios.
  • Projeto Inovador ou Experimental. Projetos onde a realidade dos requisitos podem evoluir conforme o projeto avança e a tecnologia é testada.
  • Desenvolvimento com Requisitos Ambíguos.
  • Alta interdependência de Componentes. Sistemas de e-commerce com múltiplos módulos interdependentes, como gerenciamento de produtos, pagamentos e logísticas.

Papel do Analista

No modelo cascata o papel do analista é fundamental. Ele é o responsável por documentar todos os requisitos no início do projeto, documentação essa, que deve ser completa e bem apurada, pois será utilizada para todas as fases.

Além disso, deve verificar e revisar o progresso do time para assegurar que cada fase atenda aos requisitos estabelecidos, manter a comunicação entre equipes e facilitar a resolução de problema e gerenciar mudanças de requisitos, embora esse modelo seja menos flexível para alterações.

Modelo Incremental

O modelo incremental se baseia no modelo cascata, porém usa uma abordagem iterativa. Ele faz parte do tipo de processo de software evolucionário. Essa abordagem enfatiza a criação e evolução contínua do produto através de ciclos iterativos e incrementais.

Essa abordagem é útil em cenários onde os requisitos podem ser claramente definidos e priorizados, permitindo que as funcionalidades específicas sejam desenvolvidas, testadas e entregues de forma independente e iterativa.

Entrega Gradual e Contínua

No modelo incremental, o desenvolvimento é dividido em várias iterações, cada iteração resulta em um incremento funcional do software e esses incrementos são entregues ao cliente conforme são completados, permitindo que o software seja usado e testado de forma contínua. Cada incremento é uma versão do software que contém um subconjunto das funcionalidades finais. Esse processo continua até que todos os requisitos sejam atendidos e o software completo seja entregue.

Gestão de Riscos

  • Ao dividir o desenvolvimento em partes menores, é possível identificar problemas técnicos de design mais cedo no processo.
  • Cada incremento é entregue ao cliente, permitindo um ciclo de feedback contínuo, que é vital para validar se o software atende às necessidades do cliente e identificar melhorias e ajustes.

Image description

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .