O slideshow foi denunciado.

Modelo cascata apresentação

47.775 visualizações

Publicada em

Publicada em: Tecnologia

Modelo cascata apresentação

  1. 1. Engenharia de Software Modelo Cascata Antonio Carlos Almir Ramos Eryson Raphael Rafael G. Leitão
  2. 2. O Modelo Cascata <ul><li>O modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são: </li></ul>
  3. 3. O Modelo Cascata <ul><li>Estudo de viabilidade </li></ul><ul><li>Análise e especificação de requisitos </li></ul><ul><li>Design da arquitetura </li></ul><ul><li>Design detalhado </li></ul><ul><li>Codificação e testes de unidades </li></ul><ul><li>Integração e teste do sistema </li></ul><ul><li>Entrega e instalação </li></ul><ul><li>Manutenção </li></ul>
  4. 4. O Modelo Cascata <ul><li>Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente. </li></ul><ul><li>Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização. </li></ul>
  5. 5. O Modelo Cascata <ul><li>Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software. </li></ul><ul><li>O modelo Cascata também é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas. </li></ul>
  6. 6. O Modelo Cascata <ul><li>Características particulares do software (ser conceitual, por exemplo) e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo seqüencial, permitindo volta atrás para eventuais modificações. Veremos mais adiante modelos que propõem maior flexibilidade no fluxo de execução. </li></ul><ul><li>As métricas utilizadas nas estimativas de prazos e recursos humanos são ainda bastante imprecisas e quase sempre o planejamento de atividades precisa ser revisto. Normalmente, os prazos não são cumpridos, pois o planejamento, neste modelo, é feito unicamente nas etapas iniciais do desenvolvimento. A estrutura seqüencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento. </li></ul>
  7. 7. O Modelo Cascata
  8. 9. Vantagens <ul><li>Torna o processo de desenvolvimento estruturado; </li></ul><ul><li>Tem uma ordem sequencial de fases; </li></ul><ul><li>Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte; </li></ul><ul><li>Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; </li></ul><ul><li>Esta abordagem é atualmente a norma e provavelmente permanecerá como tal nos próximos tempos; </li></ul>
  9. 10. Desvantagens <ul><li>Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores; </li></ul><ul><li>Não suporta modificações nos requisitos; </li></ul><ul><li>Não prevê a manutenção; </li></ul><ul><li>Não permite a reutilização; </li></ul><ul><li>É excessivamente sincronizado; </li></ul><ul><li>Se ocorrer um atraso todo o processo é afetado; </li></ul><ul><li>Faz aparecer o software muito tarde; </li></ul>
  10. 11. Problemas <ul><li>O ciclo de vida Cascata é o paradigma mais visto e mais amplamente empregado na engenharia de software, porém sua aplicabilidade, em muitos campos, tem sido questionada. </li></ul><ul><li>Entre os problemas que surgem quando se aplica o modelo são: </li></ul><ul><li>Na realidade, os projetos raramente seguem o fluxo sequencial </li></ul><ul><li>que o modelo propõe; </li></ul><ul><li>A interação é sempre necessária e está presente, criando </li></ul><ul><li>problemas na aplicação do modelo; </li></ul><ul><li>Em princípio, é difícil para o cliente especificar os requisitos </li></ul><ul><li>explicitamente, o que acarreta a incerteza natural do início de </li></ul><ul><li>qualquer projeto; </li></ul><ul><li>O cliente deve ser paciente, pois uma versão funcional não </li></ul><ul><li>estará disponível até o final do desenvolvimento. Qualquer erro </li></ul><ul><li>ou mal entendido, se não for detectado até que o software seja </li></ul><ul><li>revisado, pode ser desastroso; </li></ul>
  11. 12. Problemas <ul><li>Apesar desses problemas, o modelo Cascata tem um lugar bem definido e importante nos trabalhos de engenharia de software. Ele fornece um padrão do qual se encaixam métodos para a análise, projeto, codificação e manutenção. </li></ul>
  12. 13. Domínio de aplicações <ul><li>O modelo Cascata aplica-se bem em situações em que o software </li></ul><ul><li>a ser desenvolvido é simples, os requisitos são bem conhecidos, a </li></ul><ul><li>tecnologia de Programação. Melhorias e correções podem ser </li></ul><ul><li>consideradas como parte do desenvolvimento. </li></ul><ul><li>As etapas descritas são as principais, porém existem sub-etapas </li></ul><ul><li>dentro de cada etapa, as quais diferem muito de um projeto para </li></ul><ul><li>outro. Também é possível que certos projetos de software exijam a </li></ul><ul><li>incorporação de uma etapa extra ou a separação de uma etapa em </li></ul><ul><li>outras etapas. Com certeza, todas essas variações do modelo </li></ul><ul><li>Cascata possuem o mesmo conceito básico: a ideia de que uma etapa </li></ul><ul><li>fornece saída que serão usadas como entradas para a etapa </li></ul><ul><li>seguinte. </li></ul>
  13. 14. Domínio de aplicações <ul><li>Portanto, o processo de desenvolvimento de um produto </li></ul><ul><li>de software de acordo com o modelo Cascata é simples de conhecer </li></ul><ul><li>e controlar. Outras atividades que também são levadas em </li></ul><ul><li>consideração em cada uma das etapas de desenvolvimento do </li></ul><ul><li>software são: </li></ul><ul><li>Verificação; </li></ul><ul><li>Administração das etapas serem documentadas. </li></ul><ul><li>A verificação, por sua vez, é necessária para que </li></ul><ul><li>uma etapa forneça os dados corretos para a etapa seguinte. Já a </li></ul><ul><li>administração, efetua a gestão e o controle da etapa. </li></ul>

×