Ciclos de Desenvolvimento de Software Tabela Comparativa

Capacidade do modelo Trabalha com a compreenso deficiente dos requisitos Trabalha com a compreenso deficiente da arquitetura Produz sistemas de alta confiana fcil modificar o sistema em verses futuras Gerencia riscos Pode ser limitado em um cronograma predefinido Permite correes no meio do projeto Possibilita ao cliente visibilidade do progresso Possibilita ao cliente visibilidade do progresso do gerenciamento Requer pouca gerncia ou experincia para us-lo Cascata Puro Deficiente Deficiente Excelente Excelente Deficiente Bom Deficiente Deficiente Bom Bom Espiral Excelente Excelente Excelente Excelente Excelente Deficiente Bom Excelente Excelente Bom Prototipao Evolutiva Excelente Deficiente para bom Bom Excelente Bom Deficiente Excelente Excelente Bom Deficiente Prototipao Incremental Deficiente Deficiente Excelente Excelente Bom Bom Deficiente Bom Excelente Bom

O Modelo em Cascata
Desenvolvido no final da dcada de 1960 e comeo da dcada de 1970, o modelo Waterfall ainda hoje a abordagem mais praticada no desenvolvimento de sistemas de informao. Esta abordagem assume que um sistema de informao tem um ciclo de vida semelhante ao de qualquer produto, com incio, meio e fim. Cada etapa do ciclo de vida pressupe atividades que devem ser completadas antes do incio da prxima etapa.

Baseado nesta abordagem, Laudon e Laudon (1996, p. 439) apresentam seis estgios que compe o ciclo de vida de um sistema de informao: Definio de Projeto: Busca-se compreender o motivo da necessidade do projeto de um novo sistema de informao. Determina se a organizao possui um problema e se este problema pode ser resolvido atravs da construo de um novo sistema de informao ou da modificao de outro j existente. Estudo dos Sistemas: Consiste na anlise detalhada dos sistemas existentes (manuais ou autmatos), identificando seus objetivos, pontos fortes e fracos, alternativas viveis para estes, e descrevendo as atividades das demais etapas do ciclo de vida que sero necessrias para este novo sistema de informaes. Projeto: Esta etapa produz as especificaes de projeto fsicas e lgicas para a soluo. Programao: Transforma as especificaes de projeto produzidas na etapa anterior em programas - softwares. Analistas de sistemas trabalham juntamente com programadores preparando para estes especificaes que descrevem o que cada programa dever fazer, o tipo de linguagem de programao que dever ser utilizada, as entradas e sadas deste, etc. Instalao: Consiste na etapa final de colocao do novo sistema ou modificao de um existente em operao. Testes de validao de suas funes so atividades tpicas desta fase. Ps-Implementao: Utilizao e avaliao do sistema aps sua instalao. Inclui atualizaes, correes, etc. Outros autores, apresentam apenas quatro etapas: anlise, projeto, codificao e teste. Nesta situao, algumas etapas englobam atividades que Laudon e Laudon distriburam em duas, como por exemplo, a etapa da anlise consistiria da definio do projeto e estudo do sistema. Esta diferena encontrada nas atividades relacionadas a cada estgio em nada modifica o modelo Waterfall. Mesmo sendo amplamente utilizado, o modelo em cascata apresenta algumas limitaes: Confirmao tardia da resoluo de riscos crticos Mede o progresso por meio de produtos que do uma previso de concluso pobre Retarda e agrega integrao com testes Impossibilita entrega a curto prazo de mdulos Freqentemente resulta em iteraes grandes e no planejadas

Uma vez que considera que uma etapa deve ser iniciada aps a concluso das atividades da etapa anterior, gasto uma quantidade razovel de tempo e esforos levantando informaes, especificando e documentando-as a cada etapa para sua posterior utilizao; este fato pode levar a demora na instalao do sistema tornando-o, muitas vezes, obsoleto quando efetivamente colocado em operao. Os resultados que so observados na etapa ps-implementao so demorados, isto , no ocorrero at que muitos passos tenham sido completados. A maioria das implementaes do ciclo de vida em cascata apia-se em fases seqenciais, o que significa que meses ou anos podem se passar antes que os usurios vejam qualquer evidncia tangvel de progresso. Disso decorre a sua utilizao de maneira no formal. A exigncia de uma formalidade volumosa, baseada em papel, leva a maioria das organizaes e a maioria dos profissionais da rea, que no tm tempo nem disposio, a praticar o ciclo de vida tradicional de um modo menos rigoroso e formal; Devido a seu grau de formalidade que exige especificaes e documentaes para cada processo que o sistema de informao executa, alteraes so inibidas tornando este processo, muitas vezes, inflexvel mudanas O prprio processo de deteco de erros no ciclo de vida em cascata clssico reservado fase de teste formal do projeto. Neste estgio, a presso nas atividades finais de desenvolvimento do sistema como deteco de erros de anlise e projeto, levam a situaes onde torna-se difcil a correo destes tendo em vista o custo associado a eliminao dos erros; Os processos de tomada de deciso exigem, na maioria das vezes, atividades no estruturadas, que no possuem procedimentos bem definidos. Esta realidade, dentro de uma abordagem tradicional - e formal - dificulta a definio das especificaes do sistema, dependendo de requisitos corretos e estveis. No ciclo de vida em cascata a qualidade da codificao depende da qualidade do projeto, e a qualidade do projeto depende do esforo de anlise. Se os requisitos do usurio tiverem sido mal interpretados ou mal entendidos, ou se o usurio alterar os requisitos durante a fase de projeto e implementao subseqente, o ciclo de vida poder no produzir resultados para o real problema determinado. Uso da implementao bottom-up. A implementao bottom-up inicia seu trabalho testando os mdulos do sistema, depois subsistemas e finalmente o sistema. Assim, os erros mais srios (integridade do sistema) so encontrados ao final e no no incio da fase de testes.

O Modelo Incremental

Barry Boehm sugeriu, tendo em vista as limitaes da abordagem tradicional, que o desenvolvimento de sistemas de informao poderia ser administrado numa srie de incrementos. Assim, poderia haver uma srie de ciclos de vida tradicionais para cada incremento. O Modelo Incremental foi desenvolvido atravs da combinao entre os modelos linear e prototipao. O desenvolvimento dividido em etapas, denominadas incrementos, que produziro incrementalmente o sistema, at a sua verso final. Em cada incremento realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema j em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda no cobrir todos os requisitos. O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos no esto claros inicialmente. Por exemplo: quando o Modelo Incremental utilizado, o primeiro incremento normalmente constitudo do ncleo do sistema. Isto , os requisitos bsicos so implementados, e os detalhes suprimidos. Esse produto ser entregue para uma avaliao, que poder detectar, inicialmente, problemas que poderiam ser de dimenses muito maiores se detectados somente na entrega do produto final. Outra vantagem para o desenvolvedor que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os prximos incrementos, alm de contar com os servios da verso j produzida. Outras vantagens so: A construo de um sistema menor sempre menos arriscada que a construo de um grande; Se um grande erro cometido, apenas o ltimo incremento descartado; Reduzindo o tempo de desenvolvimento de um sistema, as chances de mudanas nos requisitos do usurio durante o desenvolvimento so menores.

O Modelo Espiral
Seguindo a mesma linha do modelo incremental,o modelo foi proposto o modelo EPS (Boehm, 1988) - Evolutionary Spiral Process. Este modelo baseia-se em quatro principais atividades: Determinao dos objetivos, alternativas e restries; Anlise de risco e prototipao;

Validao e verificao; Planejamento da fase seguinte.

Esta concepo tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possvel. Problemas do Modelo espiral O modelo em espiral, por suas caractersticas de avaliao e planejamento baseadas em risco, exige que se tenha gerentes e tcnicos experientes. As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. necessrio o uso de tcnicas especficas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Prototipao

Baseado no desenvolvimento de um prottipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento feito obedecendo realizao das diferentes etapas de anlise de requisitos, o projeto, a codificao e os testes. No necessariamente estas etapas devem ser realizadas de modo muito explcito ou formal A definio de todos os requisitos necessrios ao sistema pelo cliente ou usurio geralmente uma tarefa muito difcil. quase impossvel prever como o sistema ir afetar o funcionamento das prticas de trabalho, como ser a interao com outros sistemas e que operaes dos usurios devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessria a utilizao de um prottipo do sistema. Um prottipo uma verso inicial de um sistema de software, que utilizada para mostrar conceitos, experimentar opes de projeto e, em geral, para conhecer mais sobre os problemas e suas possveis solues. O desenvolvimento rpido de um prottipo essencial para que os custos sejam controlados e os usurios possam fazer experincias com o prottipo no incio do processo de software. Um prottipo de software apia duas atividades do processo de engenharia de requisitos: Levantamento de requisitos - Os prottipos de sistema permitem que os usurios realizem experincias para ver como o sistema apia seu trabalho. Eles obtm novas idias para os requisitos e podem identificar pontos positivos e negativos do software. Eles podem, ento, propor novos requisitos de sistema. Validao de requisitos - O prottipo pode revelar erros e omisses nos requisitos propostos. Uma funo descrita em uma especificao pode parecer til e bem-definida. Contudo, quando essa funo utilizada com outras, os usurios muitas vezes acham que sua viso inicial era incorreta e incompleta. A especificao de sistema pode ento ser modificada para refletir sua compreenso alterada dos requisitos. Na maioria dos projetos, o primeiro sistema construdo dificilmente ser usvel. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os trs. A questo administrativa, no se deve construir um sistema-piloto e jog-lo fora. Isso ser feito. A nica questo se deve planejar antecipadamente a construo de algo que se vai jogar fora ou prometer entregar isso aos clientes.

O prottipo pode ser oferecido ao cliente em diferentes formas: prottipo em papel modelo executvel em PC retratando a interface homem-mquina capacitando o cliente a compreender a forma de interao com o software; prottipo de trabalho que implemente um subconjunto dos requisitos indicados programa existente (pacote) que permita representar todas ou parte das funes desejadas para o software a construir Vantagens da prototipao: modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos possvel demonstrar a realizabilidade atravs da construo de um prottipo do sistema possvel obter uma verso, mesmo simplificada do que ser o sistema, com um pequeno investimento inicial A experincia adquirida no desenvolvimento do prottipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido Problemas da prototipao: Quando informamos que o produto precisa ser reconstrudo, o cliente exige que alguns acertos sejam aplicados para tornar o prottipo um produto; muito freqentemente, a gerncia de desenvolvimento de software cede. O desenvolvedor muitas vezes faz concesses de implementao a fim de colocar um prottipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opes e esquecer-se de todas as razes pelas quais elas so inadequadas - a opo menos ideal se tornou ento parte integrante do sistema.

Abordagem Evolucionria
Nesta abordagem, o desenvolvimento formada por mltiplos ciclos da abordagem cascata pura, ocorrendo sobreposio das fases da operao e manuteno do sistema anterior com o novo desenvolvimento. Esta abordagem adequada quando: - necessrio alguma experincia do usurio para refinar e completar requisitos; - algumas partes da implementao podem depender da existncia de tecnologia ainda no disponvel; - existem requisitos do usurio no bem conhecidos; e - alguns requisitos so muito mais difceis de serem implementados do que outros, decidindo-se no implement-lo para no atrasar o projeto. A Figura 2.4 ilustra a abordagem:

Figura 2.4 Abordagem Evolucionria

 opinio deste autor que o padro PSS-05-0 da ESA revitalizou o modelo cascata, sendo atualmente um dos melhores modelos de ciclo de vida para desenvolvimento de software.