Modelo Cascata E Modelo V 6k423o

O modelo cascata, algumas vezes chamado ciclo de vida clássico, sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, começando com a especificação dos requisitos do cliente, avançando pelas fases de planejamento, modelagem, construção e disponibilização, e culminando no e contínuo do software concluído.

O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente, ou utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis.

Comunicação início do projeto levantamento de requisitos

MODELO CASCATA

Planejamento estimativas cronograma acompanhamento

Modelagem análise projeto

Construção código teste

Entrega entrega e

Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software.

Na etapa de levantamentos de requisitos ou necessidades estabelecemos junto aos clientes os requisitos do produto desejado pelo cliente que consiste dos serviços que devem ser fornecidos, limitações e objetivos do software. Esta etapa também consiste da documentação e o estudo de viabilidade do projeto para determinarmos o processo de início de desenvolvimento do projeto do sistema.

Na etapa de planejamento temos a definição de estimativas, cronograma e acompanhamento baseando-se nos requisitos e na determinação das tarefas que, por sua vez, são determinadas pelos requisitos.

A etapa de modelagem é uma prévia da próxima etapa de construção, nesta etapa define-se a estrutura de dados, arquitetura do software, interfaces, etc.

A etapa de construção abrange a implementação, onde os programas são efetivamente criados e também os testes que é onde se testam as lógicas internas do software e as funcionalidades externas. As funcionalidades internas normalmente são realizadas com o uso de testes unitários e as fases externas podem ser realizadas por testadores e pelo próprio cliente.

A etapa de emprego ou implantação abrange a entrega efetiva do software no cliente que é onde instalamos o software no servidor ou na máquina do cliente junto com outros utilitários como banco de dados ou outros itens dependendo do software sendo construído. O e é onde tiramos dúvidas dos clientes e a manutenção consiste na correção de erros que não foram previamente detectados.

Os principais problemas encontrados no modelo cascata são: Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo em forma sequencial possa conter iterações, onde poderíamos ar diversas vezes pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que mudanças podem provocar bastante confusão na medida em que a equipe de projeto prossegue.

Os principais problemas encontrados no modelo cascata são: É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existem no inicio dos projetos.

Os principais problemas encontrados no modelo cascata são: O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso.

Os principais problemas encontrados no modelo cascata são: Outro grande problema que temos com os projetos que usam modelos cascata é o bloqueio que existe em alguns membros da equipe que precisam esperar que os outros completem as suas tarefas para que eles possam dar sequência ao trabalho. O tempo gasto nessa espera pode exceder o tempo gasto em trabalho produtivo que levaria à conclusão do projeto. Estudos mostram que o estado de bloqueio tende a prevalecer no início e no final de um processo sequencial linear.

Modelo V

O modelo V descreve a relação entre ações de garantia de qualidade e ações associadas a comunicação, modelagem e atividades de construção iniciais. À medida que a equipe de software desce em direção ao lado esquerdo de V, os requisitos básicos do problema são refinados em representação cada vez mais detalhadas e técnicas do problema e de sua solução.

Modelagem de requisitos

Teste de aceitação

Projeto da arquitetura

Teste de sistema

Projeto de componente

Teste de integração

Geração de código

Teste de unidade.

Software executável

MODELO V

Uma vez gerado o código, a equipe a para o lado direito de V, basicamente realizando uma série de testes (ações de garantia de qualidade) que validam cada um dos modelos criados à medida que a equipe desce para o lado esquerdo.

Modelagem de requisitos

Teste de aceitação

Projeto da arquitetura

Teste de sistema

Projeto de componente

Teste de integração

Geração de código

Teste de unidade.

Software executável

MODELO V

Na realidade, não há nenhuma diferença fundamental entre o ciclo de vida clássico e o modelo V. O modelo V oferece uma maneira de visualizar como as ações de verificação e validação são aplicadas a um trabalho de engenharia anterior.