Modelos de ciclo de vida de desenvolvimento de software: escolhendo uma maneira de realizar as coisas

A filosofia “planeje seu trabalho e trabalhe seu plano” provou sua eficiência muitas vezes na história. O planejamento adequado define o sucesso de qualquer iniciativa séria, incluindo o desenvolvimento de software. A indústria de desenvolvimento de software apresentou várias abordagens para atender aos requisitos de negócios.

O ciclo de vida de desenvolvimento de software ou SDLC define a forma como um produto é trazido à vida e mantido. Ajuda a transformar ideias criativas e requisitos de mercado em funcionalidades e recursos do produto.

Em resumo, um modelo de ciclo de vida de desenvolvimento de software é uma maneira de fazer as coisas em termos de desenvolvimento de um produto e transformá-lo em um negócio.

Contente:

1. Modelos SDLC
2. Modelo em cascata
3. Modelo em forma de V
4. Modelo big bang
5. Modelo de prototipagem
6. Modelo iterativo e incremental
7. Modelo RAD
8. Modelo de desenvolvimento em espiral
9. Modelo ágil

Modelos SDLC

Com base em seu mercado, contexto de projeto e requisitos de negócios, você pode escolher um modelo de ciclo de vida de desenvolvimento de software estabelecido ou criar o seu próprio.

Modelo em cascata

O primeiro modelo SDLC na história do desenvolvimento de software, o Waterfall é o mais simples. No modelo em Cachoeira, o processo de desenvolvimento é linear. Tarefas e fases são concluídas uma a uma em uma ordem estrita. O progresso flui continuamente para baixo, como a água em uma cachoeira.

As fases tradicionais do modelo em cascata são:

1. Levantamento de requisitos
2. Projeto
3. Implementação
4. Integração e teste
5. Desdobramento, desenvolvimento
6. Manutenção

O modelo em cascata não permite voltar aos estágios anteriores de desenvolvimento para consertar coisas ou implementar mudanças. Isso só pode ser feito na próxima iteração em Cachoeira.

Vantagens:

• Fácil de explicar para o cliente e fácil para a equipe entender
• Estrutura óbvia com etapas e atividades bem definidas
• Fácil planejamento e programação com marcos claros
• Fases concluídas uma de cada vez
• Erros e inconveniências são fáceis de verificar em cada estágio
• Cada estágio é fácil de analisar e avaliar
• Processos bem documentados

Desvantagens:

• Funciona apenas com requisitos não flexíveis
• Não é possível retornar aos estágios concluídos
• Difícil de ajustar
• Custo de desenvolvimento geralmente é alto
• Alto risco de bugs e outros inconvenientes
• Difícil de medir o progresso durante os estágios

Melhor para projetos com:

• Requisitos estáveis ​​e não ambíguos
• Uma definição clara e uma visão do produto
• Tecnologias bem conhecidas e uma pilha de tecnologia estável
• Recursos suficientes para implementação e suporte
• Um curto espaço de tempo

Modelo em forma de V

Também conhecido como o modelo V ou modelo de verificação e validação , o modelo em forma de V é uma extensão da abordagem SDLC em cascata. Com o V-Model, o progresso não se move em linha reta, mas aumenta após a implementação e codificação.

O planejamento de teste inicial é típico para projetos V-Model SDLC, que é a principal diferença em relação ao modelo em cascata. Cada estágio de desenvolvimento tem uma fase de teste paralela, que ajuda a verificar e validar cada etapa antes de passar para a próxima.

Vantagens:

• Fácil de usar e explicar
• Resultados claros para cada fase, o que significa maior disciplina
• Melhores resultados do que no modelo em cascata devido aos testes iniciais
• Verificação e validação claras em todas as fases
• Rastreamento suave de defeitos, pois os bugs são encontrados nos estágios iniciais
• Acompanhamento de progresso mais fácil, pelo menos em comparação com o modelo em cascata

Desvantagens:

• Má flexibilidade sem suporte para iterações
• É difícil e caro fazer ajustes devido à falta de tratamento de eventos paralelos
• Altos riscos de negócios e desenvolvimento
• Nenhum protótipo inicial disponível
• Nenhuma solução clara para problemas detectados durante o teste

As fases do projeto no V-Model são as mesmas que no Waterfall, mas com verificação e validação para cada fase por meio de testes . Portanto, o V-Model é bom para tipos de projetos semelhantes como Cachoeira.

Modelo big bang

Este modelo de ciclo de vida de desenvolvimento de software normalmente não segue nenhum processo ou instrução específica.
O desenvolvimento começa com os recursos e esforços disponíveis no momento, com muito pouco ou nenhum planejamento. Como resultado, o cliente obtém um produto que pode nem mesmo atender aos requisitos. Os recursos são implementados em tempo real.

A ideia-chave do modelo SDLC do Big Bang é destinar todos os recursos disponíveis para o desenvolvimento do próprio produto, principalmente em termos de codificação, sem se preocupar em cumprir os planos.

Vantagens:

• Modelo dramaticamente simples
• Quase nenhum planejamento necessário
• Simples de gerenciar
• Não requer muitos recursos
• Flexível para a equipe de desenvolvimento

Desvantagens:

• Alto risco e incerteza; todo o projeto pode precisar ser refeito do zero
• Não se encaixa em projetos complicados, de longo prazo ou orientados a objetos
• Alta probabilidade de desperdício de recursos devido a requisitos incertos

Melhor para:

• Pequenas equipes ou desenvolvedores únicos
• Projetos acadêmicos
• Projetos sem certos requisitos ou data de lançamento esperada
• Projetos pequenos e repetitivos de baixo risco

Modelo de prototipagem

A abordagem de Prototipagem SDLC consiste em criar um protótipo funcional do produto de software com funcionalidade limitada e, em seguida, transformar rapidamente o protótipo em um produto completo. O protótipo pode não conter a lógica exata do produto acabado.

Essa abordagem de ciclo de vida de desenvolvimento de software é boa para permitir que o consumidor visualize o produto. Coletar e analisar feedback dos clientes ajuda a equipe de desenvolvimento a entender melhor os requisitos do cliente nos estágios iniciais de desenvolvimento.

Verifique este artigo para saber por que os requisitos são importantes na engenharia de software.

A prototipagem também é valorizada porque envolve menos iterações do que o modelo tradicional em cascata. Isso ocorre porque o teste é feito (e as alterações são feitas) no protótipo, não no produto totalmente desenvolvido.

Obviamente, a criação de um protótipo valioso requer algum conhecimento básico dos requisitos do produto e do mercado, especialmente em termos da interface do usuário.

Com o modelo de prototipagem, o feedback dos usuários assume o papel definitivo no planejamento do desenvolvimento futuro.

A prototipagem permite que os usuários avaliem as propostas do desenvolvedor para outras funcionalidades de aplicativos e as experimente antes de serem implementadas.

Cada protótipo neste modelo SDLC geralmente é trazido à vida nas seguintes fases :

• Identifique os requisitos
• Desenvolva o protótipo inicial
• Análise
• Revisar e aprimorar

Assim que o protótipo final é concluído, os requisitos do projeto são considerados inalteráveis .

Existem também vários tipos tradicionais de prototipagem:

• Prototipagem descartável - A equipe desenvolve vários protótipos diferentes e descarta os obviamente inaceitáveis. Funcionalidades úteis de cada protótipo passam para as próximas fases de desenvolvimento.

• Prototipagem evolutiva - a equipe mostra o protótipo para grupos de foco de usuários em potencial, reúne seus comentários e implementa mudanças por meio de iterações até que o produto final seja concluído.

• Prototipagem incremental - A equipe cria vários protótipos e, eventualmente, os mescla em um único design.

• Prototipagem extrema - A equipe cria um protótipo em três partes: um protótipo estático, um protótipo de simulação de funcionalidade e um protótipo de serviços implementados. Este tipo de prototipagem é usado principalmente no desenvolvimento de aplicações web.

Vantagens:

• Maior envolvimento do usuário antes da implementação do produto
• Oportunidade de reduzir o tempo e os custos de desenvolvimento (no caso de um protótipo bem-sucedido)
• Melhor compreensão da funcionalidade pelos usuários à medida que participam do processo de desenvolvimento
• Detecção precoce de defeitos
• Feedback rápido
• Análise simples e valiosa

Desvantagens:

• Alto risco de análise incompleta devido à dependência do protótipo
• Os usuários podem considerar um protótipo como um produto concluído e permanecer insatisfeitos
• Risco de um alto custo de implementação do protótipo
• O desenvolvimento de vários protótipos pode levar muitas iterações e, conseqüentemente, muito tempo

Melhor para:

• Usando em paralelo com qualquer outro modelo SDLC
• Produtos com muitas interações do usuário
• Produtos que devem ser aprovados pelos usuários nos estágios iniciais

Modelo iterativo e incremental

O modelo SDLC Iterativo e Incremental une um design e fluxo de trabalho iterativos com um modelo de construção incremental. Nesse caso, a equipe desenvolve um produto em ciclos, construindo pequenas peças de forma evolutiva .

O processo de desenvolvimento começa com a implementação simples de um conjunto pequeno e estritamente limitado de requisitos de produto. O produto é então aprimorado e transformado em versões mais completas de si mesmo até que esteja completo e pronto para implantação. Cada iteração pode conter atualizações de design e novas funcionalidades.

Um recurso valioso do modelo Iterativo e Incremental é que o desenvolvimento pode ser iniciado sem conhecer todos os requisitos . Este modelo contém as etapas de outros modelos SDLC - coleta de requisitos, design, implementação e teste - mas ao longo de várias compilações. A equipe de desenvolvimento aproveita o que foi alcançado nas compilações anteriores para tornar a próxima compilação melhor.

O modelo SDLC Iterativo e Incremental pode ser parecido com um conjunto de modelos mini Cachoeira ou mini V-Shaped.

Vantagens:

• Produz valor de negócio cedo, pois um produto funcional é entregue a cada incremento
• Pode ser feito usando recursos escassos
• Oferece espaço para flexibilidade
• Permite mais foco no valor do usuário
• Funciona bem com desenvolvimento paralelo
• Detecta problemas em estágios iniciais
• Fácil de avaliar o progresso do desenvolvimento
• Usa muitos comentários do cliente

Desvantagens:

• Requer documentação pesada
• Segue um conjunto predefinido de fases
• Os incrementos são definidos por funções e dependências de recursos
• Requer mais envolvimento do usuário por parte dos desenvolvedores do que Waterfall ou outros SDLCs lineares
• Pode ser difícil integrar recursos entre iterações se eles não forem planejados com antecedência
• Problemas de arquitetura ou design podem ocorrer devido a requisitos incompletos nos estágios iniciais
• É complicado de gerenciar
• Difícil prever o final do projeto

Melhor para:

• Projetos complicados e de missão crítica, como sistemas ERP
• Projetos com requisitos rígidos para o produto final, mas com espaço para melhorias adicionais
• Projetos onde os principais requisitos são definidos, mas algumas funcionalidades podem evoluir ou melhorias podem ser feitas
• Projetos em que a tecnologia necessária é nova e ainda não foi dominada ou está planejada apenas para alguma parte do produto
• Produtos com recursos de alto risco que podem precisar ser alterados

Modelo RAD

O modelo Rapid Application Development (RAD) é baseado em prototipagem e desenvolvimento iterativo sem nenhum planejamento específico envolvido. Com esse modelo, o planejamento fica em segundo plano em relação à prototipagem rápida.

Os dados primários necessários no modelo RAD são coletados por meio de workshops, grupos de foco e demos de protótipos iniciais , bem como pela reutilização de protótipos existentes.

Os módulos funcionais no modelo de ciclo de vida de desenvolvimento de software RAD são desenvolvidos em paralelo como protótipos e são integrados para entregar o produto completo rapidamente. Os protótipos desenvolvidos provavelmente serão reutilizáveis.

O modelo RAD distribui as fases de análise, projeto, construção e teste em uma série de ciclos de desenvolvimento iterativos curtos.

Fases do modelo RAD:

• Modelagem de negócios - modela o fluxo de informações e a distribuição de informações entre vários canais de negócios. Esta parte é necessária para encontrar informações vitais para o negócio e definir como elas podem ser obtidas, como e quando as informações são processadas e quais fatores estão impulsionando o fluxo de informações bem-sucedido.

• Modelagem de dados - Os dados da fase anterior são processados ​​para formar os conjuntos de dados necessários com atributos identificados e estabelecidos.

• Modelagem de processos - os conjuntos de dados do estágio anterior são convertidos em modelos de processos para atingir os objetivos de negócios e recebem descrições de processos para adicionar, excluir, recuperar ou modificar cada objeto de dados.

• Geração de aplicativos - O sistema é construído e a codificação é feita usando ferramentas de automação para converter modelos de processos e dados em protótipos reais.

• Teste e rotação - a maioria dos protótipos são testados de forma independente durante cada iteração. Os desenvolvedores apenas testam o fluxo de dados e as interfaces entre todos os componentes durante esta fase.

Vantagens:

• Pode acomodar mudanças de requisitos
• Fácil de medir o progresso
• Capacidade de reduzir o tempo de iteração com ferramentas RAD poderosas
• Melhor produtividade com menos membros da equipe envolvidos, em comparação com outros SDLCs
• Desenvolvimento mais rápido
• Melhor capacidade de reutilização de componentes
• Avaliações iniciais anteriores
• Melhor chance de obter feedback do cliente

Desvantagens:

• Requer fortes equipes técnicas e de design
• Apenas bom para sistemas que podem ser modularizados
• Muita dependência de modelagem
• Alto custo de modelagem e geração automatizada de código
• Gestão complicada
• Adequado apenas para sistemas baseados em componentes e escalonáveis
• É necessário muito envolvimento do usuário durante todo o ciclo de vida

Melhor para:

• Sistemas modularizados entregues de maneira incremental
• Projetos baseados em design com muita modelagem forte
• Projetos com funcionalidade de geração automática de código
• Projetos com requisitos que mudam dinamicamente, para os quais pequenas iterações precisam ser apresentadas a cada 2 a 3 meses

Modelo de desenvolvimento em espiral

O modelo Spiral SDLC é uma combinação das abordagens Prototipagem e Cachoeira . Ele sincroniza bem com o processo natural de desenvolvimento de software. O modelo Spiral apresenta as mesmas fases do Waterfall na mesma ordem (coleta de requisitos, design, implementação e teste), separados por planejamento, avaliação de risco e construção de protótipos e simulações durante cada etapa.

Vantagens:

• As estimativas (orçamento, cronograma, etc.) tornam-se mais realistas à medida que o trabalho avança, uma vez que questões importantes são descobertas mais cedo
• Envolvimento inicial da equipe de desenvolvimento e usuários
• Maior qualidade de gestão de risco em cada fase
• Melhor flexibilidade do que em modelos lineares
• Uso estendido de protótipos

Desvantagens:

• Mais dinheiro e tempo necessários para obter o produto acabado
• Mais complicado de executar devido à maior necessidade de gerenciamento de risco
• Reutilização limitada devido aos resultados altamente personalizados das espirais de desenvolvimento
• Requer documentação pesada

Melhor para:

• Projetos complicados com muitas pequenas funcionalidades integradas
• Projetos com orçamentos rígidos (gestão de risco ajudará a economizar dinheiro)
• Projetos de alto risco
• Projetos de desenvolvimento de longo prazo
• Projetos sem requisitos claros nas fases iniciais, ou com requisitos que precisam ser avaliados
• Novas linhas de produtos devem ser lançadas em fases
• Projetos onde mudanças significativas no produto podem ocorrer durante o desenvolvimento

Modelo ágil

O modelo Agile SDLC é uma mistura de abordagens iterativas e incrementais, com foco na adaptação a requisitos flexíveis e na satisfação de usuários e clientes, fornecendo software funcional antecipadamente .

Requisitos e soluções em projetos Agile podem evoluir durante o desenvolvimento.

Com o desenvolvimento ágil, o produto é dividido em pequenas compilações incrementais e entregue em iterações . Todas as tarefas são divididas em pequenos intervalos de tempo para preparar a funcionalidade de trabalho com cada construção. A construção do produto final contém todos os recursos necessários.

No Agile, as abordagens de desenvolvimento existentes precisam ser adaptadas aos requisitos de cada projeto específico. Leia o site oficial do Manifesto Agile para saber mais sobre a filosofia Agile.

Vantagens:

• Menos tempo necessário para fornecer recursos específicos
• Não deixa espaço para suposições devido à comunicação face a face e entrada contínua do cliente
• Resultados de alta qualidade no tempo mais rápido possível
• O valor comercial pode ser entregue e demonstrado rapidamente
• Requer recursos mínimos
• Altamente adaptável às mudanças de requisitos

Desvantagens:

• Requer que o cliente perceba a importância da abordagem centrada no usuário
• A entrega tardia da documentação resulta em uma transferência mais difícil de tecnologia para novos membros da equipe
• Apresenta demandas rígidas em termos de escopo, funcionalidade entregue e melhorias a serem feitas a tempo
• Não é fácil lidar com dependências complexas
• Requer muitas habilidades básicas da equipe de desenvolvimento

Melhor para:

• Quase qualquer tipo de projeto, mas com muito engajamento do cliente
• Projetos com um ambiente de mudança frequente
• Clientes que precisam de alguma funcionalidade para ser concluída rapidamente, por exemplo, em menos de 3 semanas

Por que Agile?

De acordo com o relatório anual State of Agile, o Agile ainda é o modelo de ciclo de vida de desenvolvimento de software mais amplamente usado na indústria de tecnologia. Na Mind Studios , usamos principalmente o modelo Agile SDLC para desenvolver produtos de software para nossos clientes. Aqui está o porquê.

A principal coisa que distingue o Agile de outros modelos SDLC é que o Agile é adaptativo , enquanto outros modelos são preditivos. Os modelos de desenvolvimento preditivos dependem intimamente de análise e planejamento de requisitos adequados . Por causa disso, é difícil implementar mudanças nas metodologias preditivas - o desenvolvimento segue muito próximo do plano. E se algo precisar ser mudado, ele enfrentará todas as consequências da gestão e priorização do controle.

O desenvolvimento de software moderno requer a capacidade de fazer alterações imediatamente . O desenvolvimento do Adaptive Agile não depende tanto de planejamento detalhado quanto de metodologias preditivas. Portanto, se algo precisa ser alterado, isso pode ser alterado no máximo no sprint de desenvolvimento seguinte.

Uma equipe de desenvolvimento orientada a recursos pode se adaptar às mudanças nos requisitos de forma dinâmica. Além disso, a frequência dos testes no Agile ajuda a minimizar o risco de grandes falhas .

Leia mais: Como gerenciar riscos no desenvolvimento de software .

Obviamente, Agile significa muita interação com o cliente e o usuário para funcionar corretamente. As necessidades do usuário, não do cliente, definem os requisitos finais do projeto.

Scrum e Kanban

Existem muitas abordagens estabelecidas para o ciclo de vida de desenvolvimento de software Agile. Dois dos mais populares são Scrum e Kanban .

Scrum é uma estrutura de fluxo de trabalho usada para entregar software em sprints, que geralmente são períodos de duas semanas. Scrum se concentra em como gerenciar tarefas dentro de um ambiente de desenvolvimento e ajuda a melhorar a dinâmica da equipe.

Não existe uma maneira única de realizar Scrum devido à sua alta adaptabilidade. Mas, em geral, uma equipe precisa organizar funções, eventos, artefatos e regras associados em um determinado projeto.

Um sprint é um período de duas a quatro semanas durante o qual a equipe cria um software utilizável. Um novo sprint começa logo após o término do anterior.

Estes são os elementos típicos de um sprint:

• Planejamento de sprint , onde a equipe planeja a quantidade de trabalho a ser feito em um determinado sprint

• The Daily Scrum Meeting um breve encontro diário para a equipe discutir o que foi feito, o que eles planejam fazer hoje e quais problemas ocorreram desde a última reunião

• Sprint Review , um encontro no final do sprint durante o qual a equipe analisa o trabalho concluído e faz alterações no backlog do produto, se necessário

• Uma Retrospectiva de Sprint acontece logo antes do início de um novo sprint. Durante a retrospectiva, a equipe Scrum conclui o trabalho e cria planos de melhoria para sprints futuros com base em sua experiência em sprints anteriores.

Kanban é um método de visualização de gerenciamento amplamente utilizado no modelo Agile SDLC. Ajuda a melhorar e manter um alto nível de produtividade em uma equipe de desenvolvimento. Kanban opera com iterações curtas: se Scrum dura cerca de semanas, Kanban dura cerca de horas. O Scrum visa terminar o sprint, enquanto o Kanban visa terminar a tarefa. Kanban é anti-multitarefa.

As principais práticas do Kanban são:

• Visualizando o fluxo de trabalho
• Limitando tarefas em andamento
• Gerenciando o fluxo de trabalho

Kanban é implementado usando um quadro onde todas as tarefas do projeto são visualizadas e divididas em colunas como fazer, em andamento, em espera, concluído e em revisão.
Kanban também é bom para atividades menos técnicas, como vendas, marketing e recrutamento.

DevOps

Falando em modelos SDLC como formas de fazer as coisas, devemos mencionar a abordagem DevOps . DevOps é uma combinação de ferramentas, práticas e abordagens que ajudam a entregar produtos de software em um ritmo mais rápido. DevOps trata da colaboração de ambientes de desenvolvimento e operações.
Observe que DevOps não é um modelo SDLC, mas também ajuda você a fazer as coisas.

Principalmente, o DevOps é executado automatizando a infraestrutura e os fluxos de trabalho e rastreando continuamente o desempenho do aplicativo. Uma abordagem DevOps permite aumentar a frequência de implantações, documentar o código e reduzir o tempo necessário para implantar o novo código . É muito bom para evitar erros de dependência.

O DevOps usa iterações para melhorar, medir e monitorar o código nas operações diárias. Seu objetivo final é ter um ambiente de produção o mais eficaz possível para fornecer uma melhor experiência ao cliente.

Mas a implementação do modelo DevOps requer uma mentalidade específica das equipes de desenvolvimento e operações , bem como a prontidão para desenvolver ferramentas e habilidades de DevOps mais rápidas e dominantes.

Vantagens:

• Lançamentos mais frequentes para entrega mais rápida ao mercado
• Mais foco na melhoria do produto e mais capacidade de resposta às necessidades de negócios
• Melhor colaboração entre os membros da equipe
• Melhor qualidade do produto final e clientes mais felizes

Desvantagens:

• DevOps é novo, o que significa que não é tão bem estudado
• Não é a melhor opção para projetos de missão crítica
• Requer esforço extra da equipe para organizar
• Alta possibilidade de erros nas fases iniciais de desenvolvimento
• Precisa escolher entre focar na segurança ou na velocidade de desenvolvimento

Conclusão

O negócio de desenvolvimento de software muda constante e rapidamente. Ele muda mais rápido do que as pessoas criam formas estabelecidas de gerenciá-lo. Pode não haver um SDLC específico que se adapte perfeitamente ao seu negócio. Mas os modelos de ciclo de vida de desenvolvimento de software existentes podem pelo menos guiá-lo na direção certa e ajudá-lo a harmonizar seus processos de negócios.

Se você deseja obter uma compreensão mais clara de qual SDLC se encaixa melhor em seu projeto - ou se você precisa de uma equipe Agile de primeira linha para desenvolver seu aplicativo ou produto da web - envie-nos uma mensagem por meio de nossa página de contato.