Este artigo tem por finalidade dar uma visão geral das metodologias tradicionais (não ágeis) utilizadas em desenvolvimento de software.

A Metodologia "Codifica-Corrige"

Esta abordagem não pode ser chamada de metodologia no sentido real da palavra, mas é interessante mencioná-la pois muitos desenvolvimentos ainda continuam utilizando esta abordagem. "Codifica-Corrige" nada mais é do que o conecito de “apenas faça funcionar”. Inicialmente, o cliente pode fornecer uma especificação do que ele precisa, mas isto não será nada substancial. Esta especificação pode ser obtida através de algumas anotações, email, ou de qualquer outra fonte não muito consistente. Esta abordagem se apóia nos conhecimentos da equipe para tentar preencher as lacunas. O desenvolvimento então se inicia com ciclos rápidos de codificação seguidos por correção. De tempos em tempos, o desenvolvedor apresenta uma nova versão (ou release) da aplicação para o cliente para obter feedback e então continua o desenvolvimento. A figura abaixo demonstra como os desenvolvedores gastam a maior parte de seu tempo codificando e efetuando correções.

A metodologia “Codifica-Corrige” possui diversos efeitos colaterais negativos:

• A qualidade do produto é baixa.

• O sistema frequentemente se transforma num código bagunçado, com falta de adaptabilidade, reuso e interoperabilidade.

• Os sistemas são difíceis de serem mantidos e aprimorados.

• Os sistemas frequentemente tornam-se complicados e com baixa escalabilidade.

A Metodologia de Desenvolvimento em Cascata

A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de softwares militares complexos. No modelo em cascata, o projeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finaliza uma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com os resultados. A figura abaixo ilustra o funcionamento desta metodologia.

Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projeto é complicado. A metodologia em cascata é extremamente formal, como seria normal de se esperar de uma metodologia cujas raízes encontram-se no militares. Pode-se afirmar que a metodologia em cascata é baseada em documentos e com certeza possui uma enorme quantidade de “entregáveis” e saídas que nada mais são do que documentos. Outra características deste modelo é o alto valor dado ao planejamento. O forte planejamento inicial reduz a necessidade de planejamento contínuo conforme o andamento do projeto.

A Metodologia em Cascata funciona bem quando os requisitos do usuário são rígidos e podem ser conhecidos com antecedência. O sistema de navegação do ônibus espacial, por exemplo, pode ser um bom candidato para esta metodologia. Contudo, o foco em documentos para descrever o que os clientes e usuários necessitam pode levar a problemas. Muito frequentemente aparecem problemas de comunicação que resultam num software de baixa qualidade. Os documentos produzidos pelo processo de desenvolvimento podem ser perfeitos, mas o produto real pode ser defeituoso ou inutilizável.

De uma forma ou de outra, muitas das metodologias de desenvolvimento são variações da metodologia de Desenvolvimento em Cascata – apenas diferenciando-se uma das outras em relação à velocidade, tipos de entregáveis e flexibilidade.

A metodologia de Desenvolvimento em Cascata pode funcionar bem em ambientes rígidos e fortemente controlados, como por exemplo, os militares, mas possui sérios inconvenientes no cenário comercial. Existem casos onde o contratante do desenvolvimento do software se beneficia pela auditoria imposta pelos métodos do Desenvolvimento em Cascata. Estes casos incluem projetos que possuem componentes de alta risco, tais como projetos para a área médica ou de segurança pública.

A Metodologia de Prototipagem Evolutiva

A metodologia de Prototipagem Evolutiva é uma abordagem que visualiza o desenvolvimento de concepções do sistema conforme o andamento do projeto. Esta metodologia baseia-se na utilização de prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples desenhos, imagens gráficas e até cópias completas em HTML do sistema esperado. Com esta abordagem visual, o cliente tem uma certeza maior do resultado final. A figura abaixo ilustra esta metodologia.

O desenvolvimento real não inicia até que o protótipo final seja aceito. Esta metodologia é até certo ponto bastante flexível a respeito de mudanças de requisitos; contudo, ela ainda necessidade de muito controle. Um ponto negativo desta metodologia é que o planejamento efetivo pode ser difícil e os projetos podem ser reduzidos a um ciclo Codifica-Corrige depois que o desenvolvimento é iniciado.

O aspecto de planejamento pode tornar-se um desafio, pois a equipe não tem certeza sobre quanto tempo levará o trabalho. Isto ocorre, em partes, porque o modelo é baseado em interfaces, e não se preocupa tanto com as interdepêndencias mais baixo nícel entre os componentes. Os clientes tem uma idéia de como eles querem utilizar o seu novo sistema e utilizam o protótipo como referência. O valor do protótipo porém, não deve ser super-estimado, pois, apesar de tudo, ele não é um software funcional. Existem riscos associados com o planejamento devido a natureza interativa do desenvolvimento, mas eles são atenuados de certa forma através da prototipagem e ciclos de “releases” (ou versões) menores. Após o início do desenvolvimento, o gerente de projeto ou líder técnico deve assegurar que os desenvolvedores não utilizem a metodologia “Codifica-Corrige”. Com uma abordagem fortemente baseada na modelagem de interfaces, a modelagem a nível de componentes pode acabar “caindo pelos lados” quando o cliente dá o “tiro de largada”. A reversão para a metodologia “Codifica-Corrige” é talvez mais um reflexo de mal gerenciamento do que uma fraqueza herdada da prototipagem. Se os desenvolvedores acabarem caindo na metodologia “Codifica-Corrige”, o resultado será que a qualidade será difícil de manter.

A Metodologia de Entregas por Estágios

Esta metodologia é outra abordagem modificada da metodologia de Desenvolvimento em Cascata. Existe um fluxo definido do início ao fim e as aceitações ocorrem a cada estágio. A diferença principal é que os requisitos de negócio do cliente são quebrados em grandes componentes, e estes componentes são entregues ao cliente em estágios discretos. A figura abaixo demonstra esta metodologia.

A utilização da metodologia de Entregas por Estágios, onde a ênfase é dada a conjuntos de temas ou funcionalidades, permite que os requisitos mais importantes sejam desenvolvidos primeiro. O cliente obtém um sistema funcional de forma mais rápida. Esta metodologia requer um planejamento cuidadoso e não é muito propício a alterações. Os desenvolvedores precisam entender todas as interdependências entre os componentes e funções que devem ser considerados no planejamento dos estágios. Os riscos são reduzidos para equipes que utilizam entregas por estágios, pois as mesmas são efetuadas em blocos menores, porém, elas ainda devem ser controladas e monitoradas.

A Metodologia RUP

A metodologia RUP (Rational Unified Process) é um processo que fornece uma metodologia disciplinada de desenvolvimento utilizando um conjunto de ferramentas, modelos e entregáveis. A RUP se diferencia das demais metodologias por ser proprietária de uma empresa, no caso a IBM Rational.

A metodologia padronizada pode ser atrativa para grandes organizações que necessitem de uma linguagem comum e ferramentas padronizadas para toda a organização. A metodologia RUP utiliza UML (Unified Modeling Language) para comunicar os requisitos, arquiteturas e modelagens. A UML foi originalmente criada pela Rational Software (adquirida pela IBM) é atualmente é mantida pelo OMG (Object Management Group – http://www.omg.org/).

A metologia RUP é outra metologia de desenvolvimento interativo com foco na redução dos riscos do projeto.

Ela agrega um valor real à organização que necessita manter padrões tanto para as comunicações externas quanto para a comunicação com a equipe de desenvolvimento. Algumas características "negativas" desta metodologia são o aumento dos requisitos de documentação, a necessidade dos clientes possuírem algum entendimento de UML e ao fato de estar amarrada a software proprietário da IBM Rational.