Mode Locascata

SUMÁRIO

1 INTRODUÇÃO 3

2 DESENVOLVIMENTO 4

2.1 As Diferentes Etapas de Desenvolvimento 5

2.1.1 Análise e definição dos requisitos 5

2.1.2 Implementação 5

2.1.3 Teste do sistema 6

2.1.4 Manutenção 6

2.2 Linguagem de Programação 8

2.2.1 Java 8

3 CONCLUSÃO 9

4 REFERÊNCIAS 10

1 INTRODUÇÃO

O modelo clássico ou cascata, que também é conhecido por abordagem, foi proposto em 1970. Até a metade 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, servindo de base para muitos projetos modernos. A versão original deste modelo foi melhorada e reformulada ao longo do tempo e continua sendo muito utilizado ainda hoje.

A escolha de um modelo é o ponto de partida para a definição de um processo de desenvolvimento de software. Cada atividade deve ser associada técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o desenvolvimento.

2 DESENVOLVIMENTO

O modelo cascata 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. As atividades contidas no processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. Suas principais características são:

• Divisão inflexível do projeto em estágios distintos. A fase seguinte só deve iniciar quando a anterior tiver sido concluída e aprovada pelas partes envolvidas. Por exemplo, o design apenas deve começar quando os requisitos estiverem totalmente definidos e aprovados.

• Dificuldade em realizar mudanças com o processo em andamento.

• O modelo em cascata é apropriado quanto se tem um entendimento claro dos requisitos.

• Oferece maior previsibilidade de prazos e custo, melhor planejamento e gerenciamento.

Existem várias formas 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. 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 depois do software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente o produto final para detectar eventuais problemas.

Características particulares do software, e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo sequencial, permitindo voltar atrás para eventuais modificações. 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 é rígida, também não permitindo que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

Por outro lado o modelo em cascata tem a vantagem que só avança para a tarefa seguinte quando a cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema não sejam aproveitadas.

2.1 AS DIFERENTES ETAPAS DE DESENVOLVIMENTO

2.1.1 Análise e definição dos requisitos

Nesta etapa, estabelecem-se os requisitos do produto que se deseja desenvolver, o que consiste usualmente nos serviços que se devem fornecer limitações e objetivos do software. Sendo isso estabelecido, os requisitos devem ser definidos de uma maneira apropriada para que sejam úteis na etapa seguinte. Esta etapa inclui também a documentação e o estudo da facilidade e da viabilidade do projeto com o fim de determinar o processo de início de desenvolvimento do projeto do sistema; pode ser vista como uma concepção de um produto de software e também como o início do seu ciclo de vida.

2.1.2 Implementação

Esta é a etapa em que são criados os programas. Se o projeto possui um nível de detalhe elevado, a etapa de codificação pode implementar-se automaticamente. A princípio, sugere-se incluir um teste unitário dos módulos nesta etapa; nesse caso, as unidades de código produzidas são testadas individualmente antes de passar a etapa de integração e teste global.

2.1.3 Teste do sistema

Concluída a codificação, começa a fase de teste do sistema. O processo de teste centraliza-se em dois pontos principais: as lógicas internas do software e as funcionalidades externas. Esta fase decide se foram solucionados erros de “comportamento” do software e assegura que as entradas definidas produzam resultados reais que coincidam com os requisitos especificados.

2.1.4 Manutenção

Essa etapa consiste na correção de erros que não foram previamente detectados, em melhorias funcionais e de preferência e outros tipos de suporte. A etapa de manutenção à parte do ciclo de vida do produto de software e não pertence estritamente ao seu desenvolvimento. Engenharia de Programação Melhorias