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). Fonte:
Wikipedia Handbook de TI http://www.ime.uerj.br/~vera/projeto/apostila.pdf http://imasters.com.br/noticia/1861/gerencia-de-ti/modelos-d e-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