Vantagens e desvantagens de usar o modelo em cascata

UNIVERSIDADE DO NORTE DO PARANÁ

CURSO SUPERIOR EM TECNOLOGIA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Marcelo Krul Silva

FUNDAMENTOS DE TECNOLOGIA DA INFORMAÇÃO

Prof. Kátia Costa

OUTUBRO-2013

IBAITI-PR

Marcelo Krul Silva

FUNDAMENTOS DE TECNOLOGIA DA INFORMAÇÃO

Trabalho de ADS para ser apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de analise e desenvolvimento de sistemas.

.

Orientador: Katia do Nascimento Costa

OUTUBRO-2013

IBAITI-PR

SUMÁRIO

1.0 Introdução 4

2.0 Objetivo 5

3.0 Modelos Cascata 5

4.0 Vantagens e desvantagens em utilizar modelo cascata 7

4.1 Vantagens do modelo cascata 7

4.2 Desvantagens do modelo cascata 7

5.0 Exemplos do modelo Cascata 7

5.1 Análise e definição dos requisitos 8

5.2 Projetos do sistema 8

5.3 Implementação 8

5.4 Testes do sistema 8

5.5 Manutenção 9

6.0 Conclusão 9

7.0 Referências 10

1.0 Introdução

O processo de software é visto por uma sequência de atividades que produzem uma variedade de documentos, resultando em um programa satisfatório e executável. O desenvolvimento de software tem-se caracterizado por uma sobreposição de atividades necessárias para especificar, projetar e testar retorno dos resultados do software que está sendo criado. Existem vários modelos de processo de software (ou paradigmas de engenharia de software), cada um representa uma tentativa de colocar ordem em uma atividade inerentemente caótica.

Iremos abordar um modelo de processo de software mais amplamente usado na engenharia de software e também conhecer suas particularidades.

2. Objetivo

Mostrar a particularidade do modelo de processo de software mais antigo e também o mais usado na engenharia de software, o modelo Sequencial Linear (também chamado Ciclo de Vida Clássico ou Modelo Cascata).

3. O Modelo Cascata

Em 1970 Royce propôs o que é agora popularmente designado no modelo em cascata como um conceito inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho então explorou como o modelo inicial poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as próximas, de modo similar a muitos métodos amplamente utilizados hoje. Ironicamente, foi somente o modelo inicial que mereceu destaque; e sua crítica ao modelo inicial sendo amplamente ignorada. O modelo em cascata rapidamente não se tornou o que Royce pretendia um projeto iterativo, mas ao invés disto um modelo puramente sequencialmente ordenado.

O modelo cascata (waterfall) é 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:

• Estudo de viabilidade

• Análise e especificação de requisitos

• Design da arquitetura

• Design detalhado

• Codificação e testes de unidades

• Integração e teste do sistema

• Entrega e instalação

• Manutenção

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 sequencial de atividades semelhantes a descritas anteriormente.

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. 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.

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.

Características particulares do software (ser conceitual,