Hoje em dia, existem diversas metodologias de desenvolvimento de software, por isso estamos fazendo uma série de artigos focados em metodologias. Já falamos aqui sobre as metodologias Scrum e Crystal, e hoje vamos abordar a metodologia RAD.

O que é RAD?

Rapid Application Development (RAD) ou Desenvolvimento Rápido de Aplicação é um modelo de processo de desenvolvimento de software incremental, que foi registrado por James Martin, em 1991. É um processo de desenvolvimento de aplicações de forma rápida com objetivos bem definidos e análise de requisitos extremamente bem alinhada. Esse modelo enfatiza um ciclo de desenvolvimento curto, com o intuito de ter um desenvolvimento melhor e mais rápido.

No desenvolvimento incremental, uma das características de RAD, o sistema é dividido em módulos, tomando por base a funcionalidade. Tendo os incrementos definidos, a cada ciclo é acrescido de novas funcionalidades ou até mesmo modificações, caso seja necessário. Outra característica é justamente essa maleabilidade de adaptação dos processos e a capacidade de se manter em constante evolução.

O processo consiste basicamente em:

1. Modelagem do negócio
2. Modelagem dos dados
3. Modelagem do processo
4. Geração da aplicação
5. Teste e Modificação

As fases de modelagem e geração da aplicação são executadas por diversas equipes. Essa divisão otimiza tempo, além do reaproveitamento de módulos prontos que faz com que o desenvolvimento cumpra prazos curtos. Por fim, ocorre a integração desses componentes.

O RAD tem uma capacidade muito grande de potencializar o desempenho dos profissionais da equipe. Algumas outras vantagens são:

• economia de tempo
• progresso mensurável
• trabalho com modelos
• integração mais rápida de sistemas
• feedback constante

Quando devo usar?

Um ponto muito importante é que a aplicação deve possuir requisitos muito bem definidos e o sistema poder ser modularizado para o bom funcionamento do RAD. Quando você analisar que o projeto a ser desenvolvido pode ser dividido em componentes e em ser reutilizado componentes prontos, sempre pensando no curto prazo, pode ser uma boa opção.

Não é apropriado quando se tem um risco técnico alto ou quando não se tem equipe suficiente para suprir essa agilidade.