Introdução ao Modelo Cascata

Processo de software é como uma metodologia para as atividades, ações e tarefas necessárias para desenvolver software de alta qualidade. Dessa forma, um processo de software é como uma série de passos previsíveis, ou um roteiro, que ajudará na criação de um produto ou sistema de alta qualidade e dentro do prazo estabelecido entre as partes.

Um processo de software pode ser diferente dependendo da organização ou do projeto, ou seja, ele é adaptável às necessidades. Esse processo conta com a ajuda de toda a equipe de desenvolvimento, equipe de testes, gerentes, entre outros, além também dos próprios solicitantes do software que devem colaborar com a definição, construção e teste do software.

A grande importância de um processo se dá pela estabilidade, controle e organização que ele estabelece para uma atividade que, sem controle, poderia ser terrível levando inclusive ao caos.

Veremos no restante do artigo os modelos prescritivos e mais especificamente o modelo em cascata que ainda é utilizado na indústria de software, muitas vezes utilizado erroneamente em projetos que não se adequam corretamente ao que o modelo prega. Em outras situações veremos que o modelo cascata é o mais indicado.

Modelos Prescritivos

Um modelo de processo prescritivo foi originalmente concebido para trazer ordem ao caos que existia na área de desenvolvimento de software. Durante todos esses anos que os modelos prescritivos têm sido estudados e utilizados conclui-se que esses modelos tradicionais proporcionaram uma grande contribuição quanto a sua estrutura utilizável e, além disso, eles forneceram um roteiro razoavelmente eficaz para as equipes que desenvolvem software. No entanto, esse modelo mostrou que o trabalho de engenharia de software e o seu produto ainda permanecem instáveis ou parcialmente estruturados.

Esse modelo é denominado prescritivo, pois esses modelos prescrevem um conjunto de elementos de processo como atividades específicas do método, ações de engenharia de software, tarefas, produtos, garantia da qualidade, controles e mudanças para cada projeto. Cada modelo de processo também define um fluxo de processo, ou seja, como os elementos do processo estão inter-relacionados.

Modelo Cascata

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. Por exemplo, quando temos um sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada.

Também podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis.

O modelo cascata também é chamado de ciclo de vida clássico ou tradicional.

Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software. Dessa forma, começamos com o levantamento de requisitos ou necessidades junto ao cliente, depois vamos para a fase de planejamento onde definimos estimativas, cronograma e acompanhamento, após isso partimos para a modelagem onde fazemos a análise e projeto, seguindo da construção onde codificamos e testamos, passamos para a implantação ou emprego onde efetuamos a entrega, suporte e feedback do software concluído.

Basicamente 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 inicio 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. Por fim, a etapa de emprego ou implantação abrange e 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 suporte é onde tiramos dúvidas dos clientes e a manutenção consiste na correção de erros que não foram previamente detectados.

A Figura 1 demonstra as etapas discutidas acima.

Figura 1. Ilustrando o Modelo cascata.

O modelo cascata também possui algumas variações como o "modelo v". Este modelo pode ser visto na Figura 2.

Figura 2. Ilustrando o Modelo V.

Este modelo descreve a relação entre ações da garantia da qualidade (representado no lado direito da figura) e as ações associadas à comunicação, modelagem e atividades de construção. O modelo é seguido de cima para baixo a partir do lado esquerdo e depois parte de baixo para cima no lado direito quando o código estiver finalizado no lado esquerdo, ou seja, quando possuirmos um software executável efetivamente subimos no modelo. Não existe diferença entre o modelo V e o modelo tradicional. O modelo V apenas enfatiza uma forma para visualizar como a verificação e as ações de validação são aplicadas ao trabalho de engenharia que são realizadas no lado esquerdo.

O modelo cascata é o paradigma mais antigo da engenharia de software. Porém, mesmo sendo bastante antigo e ainda utilizado na indústria esse processo recebe muitas críticas que gerou questionamentos sobre a sua eficácia até mesmo pelos seus maiores defensores.

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 passar 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.
• É 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.
• 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.

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 sequencia 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. Um exemplo clássico disso é a brincadeira das moedas. Imagine que temos 5 moedas de 10 centavos na mão esquerda e faremos uma rodinha com 5 pessoas sendo que existe uma cadeira ao lado de cada pessoa para que possamos colocar as moedas já lançadas. Cada pessoa deve pegar uma moeda da mão esquerda com a sua mão direita e atirar essa moeda para cima e deixar a moeda cair na mesma mão direita, após isso colocamos a moeda na cadeira ao lado. Após lançarmos todas as moedas e colocarmos na cadeira ao lado o próximo colega deve pegar essas cinco moedas deixadas na cadeira pelo colega anterior e novamente lançar as moedas, repetindo os mesmo procedimentos do colega anterior. Agora vamos recomeçar a brincadeira e o colega deve lançar as moedas novamente, porém quando tivermos duas moedas na cadeira o próximo colega deverá começar a lançar as moedas, sem precisar esperar que as cinco moedas estejam disponível. Calcule o tempo gasto nas duas brincadeiras. Veremos que há uma boa diferença quando não precisamos esperar até que cad um realize toda a atividade para que possamos começar o trabalho. Temos um grande ganho de produtividade.

Atualmente também temos um ritmo bastante acelerado no desenvolvimento de software e estamos cada vez mais sujeitos a uma cadeia de mudanças que são intermináveis que surgem desde necessidades do negócio, necessidades dos clientes até exigências impostas por leis governamentais. O modelo cascata é inapropriado para este trabalho. Como dito anteriormente o modelo cascata é útil apenas em situações onde os requisitos são fixos e o trabalho deve ser todo finalizado de forma linear.

Com isso, neste artigo vimos o que são processos e quais são seus principais conceitos e princípios. Também vimos sobre os modelos prescritivos e o modelo cascata. O modelo cascata é útil em determinados tipos de projeto e não adequado em outros quando temos muitas mudanças e ambientes imprevisíveis.

Bibliografia

[1] Pressman, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora Bookman.

[2] Ken Schwaber e Jeff Sutherland. Scrum Guide. Disponível em http://www.scrum.org

[3] Mike Cohns: Succeding with Agile. Disponível em http://www.mountaingoatsoftware.com/blog/