Introdução ao Modelo Cascata

Veja neste artigo uma introdução aos Processos de Software sob uma visão geral da Engenharia de Software, aos modelos
prescritivos e o modelo cascata. Veja seus principais conceitos e princípios.

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/