PROCESSO DE SOFTWARE Modelo Cascata

SUMÁRIO

1 INTRODUÇÃO 3

2 DESENVOLVIMENTO 4

2.1 Modelo cascata 4

2.2 Ciclo de vida 5

2.3 Vantagens 6

2.4 Desvantagens 7

2.5 LINGUAGEM JAVA 7

3 CONCLUSÃO 9

REFERÊNCIAS 10

1 INTRODUÇÃO

O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.

O modelo cascata é um dos mais importantes modelos, e é referência para muitos outros modelos, servindo de base para muitos projetos modernos. A versão original deste modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em dia. Grande parte do sucesso do modelo cascata está no facto dele ser orientado para documentação. No entanto deve salientar-se que a documentação abrange mais do que arquivo de texto, abrange representações gráficas ou mesmo simulação.

Uma abordagem incorporando processos, métodos e ferramentas devem ser utilizados pelos criadores de software. Esta abordagem é muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem três abordagens de modelos de processo de desenvolvimento de software. Elas tentem colocar ordem numa atividade inerentemente caótica.

2 DESENVOLVIMENTO

2.1 MODELO CASCATA

Um dos primeiros modelos propostos foi o modelo cascata, que os estágios são apresentados em sequencias como uma cascata (Royce, 1970), o desenvolvimento de um estagio deve terminar antes do próximo começar. Desse modo, só quando todos os requisitos forem enunciados pelo cliente, tiverem sua completeza e consistência analisada e tiverem sido documentados em um documento de especificação, é que a equipe de desenvolvimento pode realizar as atividades de projeto do sistema. O modelo em cascata apresenta uma visão de muito alto nível do que acontece durante o desenvolvimento e sugere aos desenvolvedores a sequencia de eventos que eles devem esperar encontrar.

O modelo cascata tem sido utilizado para identificar as atividades de desenvolvimento em uma variedade de contextos. Por exemplo, ele foi a base para desenvolvimentos de produtos de software entregues ao Departamento de Defesa dos Estados Unidos, por muitos anos, definidos conforme o padrão 2167-A do Departamento de Defesa. Associados a cada atividades do processo, estavam marcos e produtos; assim os gerentes de projetos poderiam utilizar o modelo para estimar quanto faltava para o termino do projeto.

O modelo cascata pode ser muito útil para ajudar os desenvolvedores a descrever o que eles precisam fazer. Sua simplicidade o torna fácil de explicar aos clientes não familiarizados com o desenvolvimento de software. Ele explica os produtos intermediários necessários para começar o próximo estágio de desenvolvimento. Muitos outros modelos mais complexo são apenas variações do modelo cascata, incorporando loops e feedback e atividades extras.

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.

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 sequencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

2.2 CICLO DE VIDA

Os principais estágios do modelo demonstram as atividades fundamentais de desenvolvimento:

1. Analise de definição de requisitos. Nesta fase todos os detalhes de funcionalidades, desempenho e interfaces exigidos devem ser documentados e revisto juntamente com o cliente.

2. Projetos de sistemas de software. Tem como finalidade o detalhamento técnico para implementação do software.

3. Implementação de teste de unidade. Tem como resultado os programas construídos conforme as especificações documentadas na fase projeto.

4. Integração e teste de sistema.São realizados testes para descobrir todos os erros possíveis antes de prosseguir para próxima fase.

5. Operação e manutenção. Nessa ultima fase está previsto mudanças no software após a entrega ao cliente. Essas mudanças são provocadas pelas adaptação ao meio externo, ou ate por inclusão de novas funcionalidades ou de desempenho exigidas pelo cliente.

Em principio o resultado de cada fase consiste em um ou mais em um ou mais documento aprovados. A fase seguinte não deve começar antes que a faze anterior tenha terminado. Na pratica esses processos sobrepõem e troca informações.

Figura 1