A metodologia de desenvolvimento em cascata pode funcionar bem em ambientes rígidos

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/

Confira outros conte�dos: