Vantagens de se usar um RAD

November 13, 2014 Vinícius Muniz

Vantagens de se usar um RAD

Desde 1991, quando apareceu formalmente no mercado através de uma publicação, o Rapid Application Development (RAD) tem sido um verdadeiro divisor de águas entre desenvolvedores que, por um lado, defendem a arquitetura do processo e, por outro, daqueles que veem nele a solução para economia de tempo e dinheiro.

Inicialmente baseado no RIPP (Rapid Iterative Production Prototyping) da década de 80, o RAD agrega também valores de outros tantos processos para enfatizar o reuso de componentes já testados ou a criação de novos reutilizáveis, facilitando a construção do software. Criticado por um suposto excesso de informalidade, é especialmente vantajoso em algumas situações, já que o sistema pode ser dividido em cinco ou seis módulos independentes.

Ciclo de desenvolvimento curto é a maior vantagem

Usado principalmente para aplicações de sistemas de informações, uma das maiores vantagens de usar o RAD é o ciclo de desenvolvimento extremamente curto, entre 60 e 90 dias. Ele oferece maior flexibilidade aos desenvolvedores que podem projetar e reprojetar inúmeras vezes, já que a  utilização das técnicas de Quarta Geração, automatizando a geração de códigos e gerando códigos reutilizáveis, faz com que não haja necessidade de codificação manual.

Além de fazer uso de classes pré-existentes, as APIs (que também ajudam a dar uma aparência mais consistente e padronizada ao projeto), é possível distribuir cada função principal a uma determinada equipe, apenas integrando os módulos ao final do projeto para a formação de um todo – ao contrário do que ocorre no Módulo Cascata, que é sequencial.

Isso reduz o tempo de construção, possibilitando, entre outras vantagens, a criação de protótipos que permitem a visibilidade antecipada.

Construção modular agiliza o processo

O sistema é especialmente indicado quando os requisitos são bem compreendidos, há a possibilidade de modular a construção do projeto e este possibilita a reutilização de APIs. Além disso, a técnica também oferece melhores resultados quando a performance não é o aspecto mais importante, quando o escopo do projeto é relativamente pequeno e quando a distribuição do produto é em pequena escala. Isso porque para projetos de grande porte são necessários mais recursos humanos para a formação de várias equipes, o que já passa a encarecer demais o projeto.

Para pequenos projetos, que precisem de resultados rápidos com prazos definidos e processos agilizados, ele é o ideal, mas é preciso ter em mente que todos os envolvidos precisam estar em perfeita sintonia, já que se um dos prazos for quebrado pode colocar em risco todo o modelo.

O sistema também é especialmente vantajoso quando o projeto envolve tecnologia que já tenha mais de um ano de existência e cujo risco técnico já tenha sido zerado. Dessa forma a modularização e o comprometimento com os prazos de cada fase são otimizados.

Mas atenção, nem sempre ele é o ideal

Apesar de oferecer uma gama bem variada de vantagens, existem casos em que ele não deve ser o modelo empregado, como quando os riscos técnicos forem muito altos, quando o grau de comprometimento entre desenvolvedores e clientes for questionável, quando os sistema não puder ser devidamente modularizado ou quando as interfaces dos componentes do sistema tiverem que ser ajustadas.

Receba Mais noticias!

Share
Vinícius Muniz
Vinícius Muniz

Systems developer, user and Scriptcase Hoo.st Manager

Back to Topback to top
×