As Metodologias Tradicionais de Desenvolvimento de Software

As metodologias tradicionais são também chamadas de pesadas ou orientadas a documentação. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros Naquela época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso o software era todo planejado e documentado antes de ser implementado. Uma das metodologias tradicionais mais utilizadas até hoje é o modelo Clássico ou Cascata (SOARES, 2004).

Cascata

Uma das primeiras metodologias criadas para minimizar os problemas destacados acima foi a metodologia Cascata. Ela representava um grande avanço no desenvolvimento de software. Principalmente se levar em conta que antes do surgimento das primeiras metodologias existia o que ficou vulgarmente conhecido como “codifica arrebenta”. Onde o mal ou nenhum levantamento de requisitos levava a sucessivas correções, debugs e muitas vezes ao fracasso do projeto.

O Ciclo de Vida da Metodologia Cascata

Fonte: PRESSMAN, 2006

A Figura acima representa a metodologia cascata, também conhecida como sequencial, ou linear, por se basear em uma sucessão de etapas onde uma só é iniciada após o fim da imediatamente anterior a ela. Como se pode ver o desenvolvimento flui da parte de cima – Engenharia de sistemas – em direção à manutenção. Nessa metodologia, inicialmente procura-se compreender completamente o problema, a ser resolvido, seus requisitos e suas restrições; depois projeta-se soluções que atendam a todos os requisitos e restrições. Feito isto inicia-se a implementação do projeto e quando toda a etapa de implementação é concluída verifica-se junto ao cliente se a solução atende aos requisitos estabelecidos e por fim é efetuada a entrega do produto (KROLL e KRUCHTEN, 2003 apud LOURENÇO, 2011).

A abordagem adotada pela metodologia cascata acaba trazendo alguns problemas. Dentre estes problemas merece destaque o fato de que os projetos reais dificilmente seguem o fluxo sequencial, o cliente quase sempre não consegue exprimir todas as suas necessidades além de ser exigida dele muita paciência visto que o software só estará pronto para uso num ponto tardio do cronograma. E o maior dos problemas é que se ocorrer um erro em qualquer uma das etapas o resultado pode ser desastroso e frequentemente caro (PRESSMAN, 2006).

Algumas vezes o cliente define um conjunto de objetivos gerais que não esclarecem consistentemente os requisitos. Outras vezes o desenvolvedor não tem certeza da eficiência de parte do código, da adaptação da aplicação ao sistema operacional ou mesmo da forma que interação homem-máquina deve ter. Visando fornecer melhores soluções à casos assim surgiu a metodologia conhecida como prototipação.

Prototipação

A Prototipação é uma metodologia surgida posteriormente à Cascata. Ela possibilita a equipe de desenvolvimento a criar uma aplicação protótipo que pode assumir três formas distintas. A primeira delas é um protótipo em papel ou mesmo no computador que retrate a interação homem-máquina. A segunda opção é implementar uma funcionalidade que já está no escopo do software a ser desenvolvido. Por fim existe a possibilidade de utilizar-se de um software já pronto que tenha parte ou todas as funcionalidades desejadas. Esta forma é mais comumente adotada em softwares que apesar de prontos ou parcialmente prontos possuem características que precisam ser incrementadas ou melhoradas em um novo esforço de desenvolvimento (PRESSMAN, 2006).

Geralmente o protótipo serve apenas como um mecanismo para identificar requisitos de software. Isto ocorre por que na maior parte dos casos o primeiro sistema construído não é completamente usável. Normalmente ele possui uma série de problemas que só serão corrigidos em uma versão reprojetada na qual as deficiências sejam corrigidas (BROOKS,1975 apud PRESSMAN, 2006).

Assim como a metodologia Cascata a Prototipação também apresenta os seus pontos negativos. Um deles, é que o cliente pode acreditar que o protótipo já é o software pronto ou em fase de término e começar pressionar para que se faça pequenos ajustes e entregue o software rapidamente. Diante de um quadro assim, muitas vezes, a equipe de desenvolvimento cede e a qualidade final, bem como a manutenibilidade podem ficar comprometidas. Outro ponto negativo é que algumas vezes a equipe de desenvolvimento pode  fazer concessões temporárias a fim de colocar o protótipo em funcionamento que acabam permanecendo no software final.

Apesar desses problemas, a prototipação ainda é uma eficiente metodologia de desenvolvimento de software. A fim de se obter sucesso no projeto, tanto cliente quanto desenvolvedor devem chegar a um consenso de que o protótipo servirá apenas para ajudar na definição dos requisitos (PRESSMAN, 2006). Apesar de resolverem muitos dos problemas do desenvolvimento de software alguns parâmetros ainda não eram fornecidos pelas metodologias existentes.

Espiral

A metodologia espiral foi concebida para englobar as melhores práticas tanto do ciclo de vida clássico quanto da prototipação. Essa metodologia inovou ao trazer também um novo elemento, a análise de riscos. Além disso, foi uma das primeiras metodologias a adotar o conceito de iteração. Sucessivas iterações moldam aos poucos soluções mais completas do software (PRESSMAN, 2006).

Na primeira iteração, os objetivos, alternativas e restrições são definidos e os riscos são identificados e analisados. O cliente avalia o resultado da iteração e baseado nos apontamentos do mesmo a próxima iteração é iniciada. Isso possibilita ao cliente e ao desenvolvedor perceber e reagir a riscos em cada uma das etapas evolutivas. Entretanto a metodologia espiral exige considerável experiência para avaliar os riscos e se baseia nela para obter sucesso. Encara-se que se um grande risco não for detectado indubitavelmente ocorrerão problemas.

Treinamentos relacionados com essa postagem

Referências:

LOURENÇO, Marcelo. Obtendo Qualidade de Software com o RUP. Disponível em: < http://qualidade-de-software.blogspot.com/2010/03/obtendo-qualidade-de-software-com-o-rup.html >  acesso em 05 mar. 2011.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2004. Disponível em: < http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf > acesso em: 04 abr. 2011.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.