Modelos de Ciclo de Vida

Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas em cada etapa. A definição dessas etapas e atividades possibilitam prover marcos e pontos de controle para avaliação da qualidade e gerência do projeto (Park 91). O estudo do processo de desenvolvimento provocou o surgimento de várias propostas de ciclo de vida que incluem desde o simples modelo artesanal de codificar e consertar (Connors 92), (Pressman 92) até o modelo espiral (Boehm 88).

Inicialmente, o desenvolvimento de software era algo feito em pequena escala com equipes pequenas ou, até mesmo, apenas com esforço individual. Neste momento, a ênfase do processo estava na etapa de programação. Neste escopo o desenvolvimento de software caracterizou-se pelo codificar e consertar, também chamado de desenvolvimento artesanal ou ad-hoc, que consiste em se partir diretamente para a codificação, seguida de correção. Esse ciclo é repetido até se completar o projeto (Connors 92).

O aumento da complexidade e tamanho dos sistemas gerou algumas propostas de ciclo de vida levando em conta o desenvolvimento de sistemas em grande escala envolvendo grandes equipes. Isto acarretou uma mudança de enfoque com ênfase no desenvolvimento de sistemas e não apenas de programas.

O termo modelo do ciclo de vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a forma como elas se relacionam. Os modelos mais sofisticados incluem ainda uma descrição de quando e como se deve mover de uma actividade para a próxima e os deliverables que devem ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos é o fato de ajudarem as equipes de desenvolvimento, e em particular os gestores, a obter uma visão geral do projecto de forma a ser possível segui-lo passo a passo, saber que deliverables foram especificados, o alocamento de recursos e os objectivos propostos. Estes “modelos de ciclo de vida” ou “modelos de processos” são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um determinado processo.

Cascata

É composto por uma sequência de atividades, onde a próxima atividade só inicia quando a atual é finalizada, ou seja, o resultado de uma etapa é utilizado na etapa seguinte. Esse processo tem uma característica por ser guiado por documentos, sendo assim, cada etapa gera uma documentação.

Vantagens:

• Fácil de gerenciar: Etapas bem definidas e sem sobreposição;
• Eficiente em casos nos quais o domínio de aplicação é bem entendido;
• Eficiente no desenvolvimento de projetos em quais vários sistemas similares foram construídos anteriormente.

Desvantagens:

• Dificuldade de serialização proposta pelo modelo;
• Em função da dificuldade de se obter todos os requisitos do sistema no início do projeto, geralmente esse processo resulta em um atraso para o início da fase de projeto, cumulativa ao prazo final;
• Raramente as fases de execução seguem um fluxo tão seqüencial e sem interações, portanto o planejamento não é de qualidade total;
• Obtenção do produto final apenas no final do projeto, deixando margens de correção menores.

Iterativo e Incremental

Neste modelo é criado um protótipo do software, geralmente sem um processo formal de desenvolvimento, utilizada para elucidar ou validar os requisitos do produto. Seria basicamente vários ciclos de cascatas em miniatura. Assim você consegue ter um feedback do cliente de forma mais rápida.

Existem três tipos de modelos incrementais:

1. Evolutivos – Onde produtos de cada etapa de desenvolvimento são aproveitados em cada nova etapa;
2. Descartáveis – Produtos das etapas de desenvolvimento são descartados e cada novo protótipo é construído no início;
3. Operacional – Requisitos são elucidados através de protótipos e o produto final é construído paralelamente a construção dos protótipos;

Vantagens:

• Disponibilidade de partes prontas do sistema mais cedo;
• Facilidade nos testes: Geralmente, testar cada incremento é mais fácil do que testar o software pronto e tudo de uma vez só;
• Feedback do cliente a cada incremento feito;
• A aprendizagem do desenvolvedor numa linguagem é favorecida: Pode se optar em resolver as partes mais fáceis antes, enquanto ele aprende a linguagem, e deixar as partes mais complexas do sistema para depois.

Desvantagens:

• A possibilidade de o sistema ser dividido em partes como pré-requisito, já que nem sempre um sistema pode ser dividido;
• Dificuldade na integração das partes desenvolvidas;
• Negociação com o cliente a respeito do pagamento do produto de software final pode ser problemática, uma vez que o desenvolvimento em passos incrementais costuma induzir o cliente a acrescentar requisitos e funcionalidades que não estavam previstas no escopo inicial do projeto, o que resulta no encarecimento do desenvolvimento do produto final.

Espiral

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.

O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso.

Cada ciclo da espiral envolve alguns passos para que o mesmo seja concluído, dentre os quais:

• Determinar objetivos, alternativas e incertezas;
• Identificar e resolver riscos;
• Avaliar as alternativas;
• Desenvolver os produtos de entrega para aquela interação e verificar seu grau de correção;
• Planejar a próxima interação.

Vantagens:

• Possibilidade de combinar o modelo espiral com outros modelos de ciclo de vida;
• Ajuda a aumentar a qualidade pelo planejamento e análise dos riscos em cada fase;
• Maior visibilidade para a gerência, sobretudo na gerência de riscos.

Desvantagens:

• Gerência de processo mais complexa;
• Necessidade de maior experiência da equipe de desenvolvimento, sobretudo dos responsáveis pela gerência;
• Maior experiência da equipe e maior esforço para o desenvolvimento podem aumentar consideravelmente os custos.

RAD

Rapid application development (RAD), também conhecido como Desenvolvimento Rápido de Aplicação, é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O termo foi registrado por James Martin em 1991 e tem substituído gradativamente o termo de prototipação rápida que já foi muito utilizada no passado.

Não é exatamente um modelo e se baseia em que um modelo de ciclo de vida formal é ineficiente e muitas revisões e documentações geradas pelos modelos em cascata e em espiral são perda de tempo, a formalidade dificulta a comunicação com o cliente, não há um modelo de ciclo de vida bem definido: há uma seqüência de integrações evolucionárias ou protótipos que são revisados com o cliente (os requisitos são levantados a partir destas iterações).

Abrange as seguintes fases:

• Modelagem do negócio – O fluxo de informação entre as funções do negócio é modelado;
• Modelagem dos dados – O fluxo de informação é refinado num conjunto de objetos de dados;
• Modelagem do processo – Os objetos de dados são tranformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas;
• Geração da aplicação – O RAD considera o uso de técnicas de quarta geração. O processo RAD trabalha para reusar componentes de programas existentes ou criar componentes reusáveis;
• Teste e entrega – Os componentes novos devem ser testados e todas as interfaces devem ser exaustivamente exercitadas.

Fonte:
– Wikipedia
– Handbook de TI
– http://www.ime.uerj.br/~vera/projeto/apostila.pdf
– http://imasters.com.br/noticia/1861/gerencia-de-ti/modelos-de-ciclo-de-vida-por-que-precisamos-deles-no-desenvolvimento
– http://inf.unisul.br/~vera/egs/aula01.htm
– http://www.hlera.com.br/clientes/ciclo_de_vida/index.php?s=rad