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.

Modelo Cascata

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

Modelo Iterativo

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.

Modelo Espiral
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.
Desvantagens:
 Se uma aplicação não puder ser modularizada de modo que cada função principal seja completada em
menos de 3 meses, não é aconselhável o uso do RAD;
 Para projetos grandes (mas escaláveis) o RAD exige recursos humanos suficientes para criar o número
correto de equipes, isso implica em um alto custo com a equipe;
 O envolvimento com o usuário tem que ser ativo;
 Comprometimento da equipe do projeto;
 O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada quando se está testando
novas tecnologias ou quando o novo software exige alto grau de interoperabilidade com programas de
computador existentes. Falta de prazo pode implicar em qualidade reduzida, e há necessidade de
habilidade maior dos desenvolvedores, e suporte maior da gerência e dos clientes.
 Desenvolver pode economizar recursos se comparado a comprar;
 Custo do conjunto de ferramentas e hardware para rodar a aplicação;
 Mais difícil de acompanhar o projeto(pois não existe os marcos clássicos);
 Menos eficientes;
 Perda de precisão científica (falta de métodos formais);
 Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento;
 Funções reduzidas (reuso, “timeboxing”);
 Funções desnecessárias (reuso de componentes);
 Problemas legais;
 Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes);
 Padronização (aparência diferente entre os módulos e componentes);
 Sucessos anteriores são difíceis de se reproduzir .

Desenvolvimento em Componentes
O desenvolvimento baseado em componentes incorpora características de tecnologias orientadas a objetos no
modelo espiral. A atividade de engenharia começa com a identificação de classes candidatas. Se a classe
existe, ela será reutilizada. Se a classe não existe, ela será desenvolvida nos moldes do paradigma de
orientação a objetos.

Modelo de Prototipagem
O paradigma de prototipagem começa com a definição dos requisitos. Um projeto rápido é realizado e
concentra-se na representação daqueles aspectos que ficarão visíveis pelo cliente. O protótipo é criado e
avaliado e é ajustado para satisfazer as necessidades do cliente.

Prototipagem

Idealmente, o protótipo serve como um mecanismo para identificação dos requisitos do software. A
prototipagem pode ser problemática, pois o cliente vê o que parece ser uma versão executável do software,
ignorando que o protótipo apenas consegue funcionar precariamente.

O modelo pode assumir três formas: – Um protótipo em papel ou sistema, apresentando apenas a interação
usuário-sistema (prototipagem descartável); – Um protótipo que implementa algumas funções exigidas pelo
sistema; – Um protótipo que executa superficialmente todas as funções desejadas pelo sistema, sendo que
sofrerá sucessivos refinamentos (prototipagem evolucionária).