Modelo Cascata

Prévia do material em texto

Modelo em Cascata: 
 Esse modelo é um dos mais antigos, criado em 1970 por um americano cientista de computação chamado Winston Walker Royce, sendo aceito até mais ou menos a metade da década de 80. O modelo cascata foi baseado em uma engenharia tradicional, pois ele determina uma sequência de atividades, e acaba se tornando menos administrativo e mais simples. Um dos motivos para ele ser muito sucedido é o fato de ser preparado para a documentação, e possuir um começo e fim com clareza, mostrando o custo estimado logo no início.
 Ele possui o nome "Cascata" pelo fato que cada fase é iniciada após a finalização completa da fase anterior, sendo assim, o início de uma nova fase representa que a anterior foi "aprovada". Esse modelo deve ser utilizado apenas quando os requisitos forem bem compreendidos, dessa forma, é dada muita atenção às fases de análise e projeto antes de ir para a parte de programação, para que assim, seja difícil de ser gravemente modificados durante a desenvoltura do sistema. 
 Apesar desses benefícios, o modelo cascata apresenta vários problemas, como por exemplo, não há a previsão das fases antes delas serem concluídas. Pois, apesar de cada fase haver uma aprovação, é provável que há requisições que não são totalmente compreendidas pelo usuário ou cliente, fazendo com que haja um risco para vários sistemas e principalmente os de grande porte, pois como esse modelo tem uma realidade comparada a uma linha de produção em fábrica, se torna bastante conhecido e utilizado. 
 Ao iniciar o projeto, o cliente não saberá ao certo o que quer, pois, o mesmo não domina o problema apresentado de forma completa. No processo de desenvolvimento, a maioria começa a ver a sua real necessidade, e o que ocorre, é que os clientes não podem voltar atrás para modificar alguma fase que já tenha sido concluída. Assim, haver essa análise dos requisitos seria importante para o cliente procurar o modelo certo que haja de acordo com as suas necessidades. 
 Além disso, a fase de teste só é realizada depois que uma grande parte do projeto já tem sido implementada, sendo assim, ao encontrar erros ficaria mais caro e dificil de consertá-los. Só ao final do projeto o cliente terá acesso ao seu produto, ou seja, muitas vezes o que ele requisitou acaba vindo com erros e não exatamente da forma que foi requerida, causando insatisfação no mesmo. 
 Visando resolver todos os problemas causados pela falta de reversão e revisão de fases, desenvolveu-se uma versão mais atualizada do modelo cascata baseando-se no anterior, sendo chamada de "Cascata reversa". Nessa missão atual o desenvolvedor do projeto poderá prever a possibilidade de que em qualquer descoberta de uma nova necessidade, ele poderá retornar a fase anterior (mesmo que a mesma já tenha sido concluída), alterando técnicas ou requisitos que tenham surgido no meio do processo. 
 Porém, como toda nova versão pode haver riscos, nessa, ocorre que se não houver uma administração do projeto e das alterações que são bem definidas, o cliente pode gastar tempo demais tentando alcançar o seu objetivo final. 
As diferentes etapas do Modelo Cascata:
1- Análise e Definição dos Requisitos
 Nessa fase, ocorre o estudo da documentação, viabilidade, e facilidade do projeto, visando estabelecer o início do desenvolvimento do mesmo, ou seja, o começo da criação do produto. Primeiramente o cliente irá informar as suas necessidades, o que ele deseja e precisa nos serviços que serão fornecidos, e também as limitações. Logo após, é verificado se os requisitos serão úteis para a próxima fase, e se for, eles são determinados. 
 2- Projeto do Sistema
 Essa fase é composta por alguns processos que focam em 4 propriedades diferentes dentro do sistema, são elas: a estrutura de dados, a arquitetura do software, caracterização das interfaces e detalhes procedimentais. No projeto do sistema, os requisitos são apresentados de uma forma que é permite a codificação do produto, ou seja, se torna uma fase prévia de codificação. E assim, da mesma forma que a fase anterior, o projeto se torna documentado e passa a ser parte do software. 
 3- Implementação
 Nessa etapa ocorre a criação dos programas. Se o projeto tiver um maior nível de detalhamento, a codificação pode ser implementada automaticamente. De início, é sugerido adicionar um teste unitário de cada módulo que é desenvolvido nessa fase. Assim, nos códigos criados são feitos testes individuais antes de passar para a próxima fase, que é a de integração e teste global.
 4- Teste do Sistema
 Após o término da etapa anterior (de codificação), é iniciada esta, a de realização de testes do sistema. Nessa fase, há um foco em dois pontos principais, são eles: as lógicas internas do software e as suas funcionalidades externas. Evidenciando se os erros de comportamento do software foram resolvidos, e assegurando se as entradas definidas executam resultados eficientes, estando de acordo com os requisitos determinados anteriormente, essa etapa se torna essencial e de extrema importância. 
5- Manutenção
 Essa fase é responsável por corrigir os erros que não foram encontrados em testes de etapas anteriores, em melhorias funcionais e de preferência com os demais tipos de suporte. Sendo assim, ela não faz parte apenas do desenvolvimento do produto do software, como também do seu ciclo de vida. As melhorias e mudanças para correções do software podem ser determinadas como parte do processo de desenvoltura. 
 Apesar dessas serem as etapas mais importantes e utilizadas, existem também as sub-etapas que são executadas dentro de cada fase, e que, possivelmente podem se diferenciar do desenolvimento de um projeto para o outro. Além disso, há casos que podem haver de alguns projetos precisarem de uma implementação de uma fase extra, ou a divisão de uma etapa em outras para aumentar ainda mais a organização. 
 Sendo assim, podemos dizer que em geral, todas as variações do modelo cascata possuem a mesma ideia de oferecer o término de uma etapa como entrada para a próxima, tornando-se mais simples de entender e controlar. 
Modelo Prototipação:
 O modelo de prototipação surgiu na década de 80 e é considerado um modelo revolucionário, pois o mesmo representa um modelo vivo de um projeto. Desta maneira o modelo de prototipação é construído para testar um produto ou software e ver se realmente atende a todos os requisitos do cliente.
 A ideia principal do modelo é recolher todas as necessidades do cliente, listando-as e transformando-as em requisitos. Sequencialmente deve ser criado um modelo breve do projeto e logo após, a criação de um protótipo, para que o cliente possa ver se todas as suas necessidades foram sanadas e todos os requisitos cumpridos. Em caso de falhas ou continuidade de necessidades, o cliente pode sugerir melhorias para o projeto em desenvolvimento, sendo assim, o processo de prototipação vai diminuir os riscos que estão relacionados ao não atendimento dos requisitos do cliente ao final do desenvolvimento do projeto. Pode-se perceber que o protótipo apresentado ao cliente pelo desenvolvedor é um modelo cíclico, pois poderá ser ajustado diversas vezes até que possa estar pronto e seja implementado ou entregue.
 Os protótipos podem ser apresentados de duas maneiras paro o cliente, são elas: Prototipação Transitória, ou seja, uma prototipação de baixo nível, onde não terá uma grade quantidade de detalhes e ao final de etapa é descartado; Prototipação Evolutiva, ou seja, desde o início do projeto terá uma grade quantidade de detalhes, sendo aprimorada cada vez mais até que possa atingir o objetivo final, onde o mesmo atenderá todos os requisitos do cliente, sendo o mesmo mantido até o final de todo o projeto. 
 Apesar de ser revolucionário e das várias vantagens apresentadas, este modelo possui algumas limitações, por exemplo, o foco do modelo é a parte visual do projeto e algumas questões importantes relacionadas ao mesmo podem passar despercebidas pelos clientes e desenvolvedores,sendo assim, ao final das contas, pode não agregar tanto valor ao cliente; clientes podem imaginar que a partir da validação do protótipo, o sistema está quase pronto, o que não é verdade.
 Uma das maiores vantagens do modelo proposto, em relação ao modelo cascata, é a disponibilização do aspecto visual ainda nas fases iniciais para o cliente. Outra possibilidade é que o protótipo pode ser refinado até que possa ser validado pelo cliente para que possa ser construído de fato.
Modelo Espiral:
 O modelo espiral foi proposto por Barry Boehm em seu artigo de 1988 "A Spiral Model of Software Development and Enhancement" e foi o primeiro a explicar o motivo do modo iterativo. Em cada iteração (também chamada de "volta") há versões evolucionárias do sistema. É possível que possamos colocar nele algumas boas características que compõem os modelos anteriores, atendendo às necessidades específicas de clientes ou do software a ser desenvolvido. Assim, com alguns aspectos do modelo cascata que foi falado mais acima, nesse modelo as atividades são organizadas como um espiral que possuem diversos ciclos, cada um, representando uma fase. 
 Cada volta é responsável por uma fase do software, e analisando os riscos, são apoiadas por gerações de protótipos. O modelo espiral suporta sistemas complexos e de grande porte que exijam um alto nível de interação com o usuário, fazendo com que assim, o mesmo possa estar envolvido e ciente em suas decisões. Além disso, cada iteração é dividida em 4 partes, ou seja, vista por quatro ângulos. 
Definição dos objetivos: As necessidades inciais são obtidas e, além disso, é feito o planejamento do projeto, ou seja, a equipe junto com o cliente, determinam soluções, desempenhos, funcionalidades, restrições e os objetivos do projeto. Após a conclusão, ele é planejado novamente de acordo com novos requisitos, comentários e necessidades do cliente. 
Avaliação e redução de riscos: Os riscos que foram percebidos na fase anterior passam no processo de análise com a ajuda de protótipos. Ou seja, os riscos dados pela construção do projeto em si, e os que foram influenciados pelas novas necessidades e requisições do cliente ao longo do desenvolvimento do software. 
Desenvolvimento e validação: Nessa fase é tido como observação as atividades no desenvolvimento, como por exemplo, os testes, as codificações, design, verificação e espicificações. O modelo espiral possui a ideia de que nos ciclos iniciais haja mais uma construção de protótipos, e no fim dos ciclos, o produto seja realmente construído e concluído. 
Planejamento da próxima fase: A última fase é como se fosse um check-up de todas as outras etapas, e o planejamento de uma próxima. Após essa análise e planejamento, dependendo do resultado, se os requisitos forem totalmente aprovados e especificados, é possível que haja a decisão em continuar o desenvolvimento no Modelo Cascata. Caso os requisitos não tenham sitos completamente aprovados, é possível optar pela criação de novos protótipos, implementando-os, analisando novos riscos e replanejando todo o processo. 
 O modelo espiral possui vantagens em relação aos modelos anteriores, pois a análise de riscos encontrada nesse, é, até o momento, desconhecida em outros modelos, fazendo assim, com que ele se torne mais complexo e seguro. Além disso, pode-se incrementar novas funções em cada versão criada. Mas, pelo fato de ele não possuir uma evolução explícita, não se tem a certeza se é uma função recém desenvolvida, ou se é uma manutenção de um sistema já criado. 
 Porém, há também algumas limitações. A utilização desse modelo requer muita experiência na avaliação dos riscos que possam ser encontrados, o que nem sempre a equipe possui, fazendo com que quando esses riscos sejam encontrados, talvez seja muito tarde para solucioná-los. Infelizmente o modelo espiral possui um melhor funcionamento em softwares que necessitam de requisitos de complexibilidades maiores, onde os custos são bem elevados. Além disso, é preciso ter em mente que é difícil de vender ao cliente, pois, além de exigir um alto nível de gerenciamento, nem sempre é fácil convencer os mesmos de que a evolução é controlável, assim, é necessário estabelecer um prazo final do projeto, correndo o risco de nunca atingir as expectativas do cliente. 
Considerações Finais 
As metodologias de desenvolvimento de sistemas estão sendo utilizadas cada vez mais em nosso cotidiano, servindo para auxiliar nos trabalhos, sendo eles os mais complexos ou não e servem também para mostrar-nos possíveis erros e falhas para que possam ser resolvidos antes da conclusão do projeto. Cada método tem suas vantagens e desvantagens, sendo alguns deles específicos para uma determinada área. Os mesmos vêm sendo incrementados cada vez mais para que possam ficar cada vez melhores para os seus usuários