Modelo de desenvolvimento incremental que enfatiza um ciclo de desenvolvimento extremamente curto. O modelo RAD é uma adaptação de alta velocidade do modelo linear que é conseguido pelo desenvolvimento baseado em componentes.

Se os requisitos são bem compreendidos (aí podemos encaixar a questão do modelo de prototipagem, mas perderia a característica de desenvolvimento rápido) e o objetivo do projeto é restrito, o RAD permite criar sistemas plenamente funcionais dentro de períodos muito curtos (entre 60 e 90 dias - sistemas, não sites. Sites seriam menos tempo ainda).

Usa as seguintes fases:

Modelagem do negócio

O fluxo de informações entre as funções do negócio modelado visa responder as seguintes questões: Que informação dirige o processo do negócio? Que informação é gerada? Quem a gera? Para onde vai a informação? Quem a processa? (tem mais detalhes aqui no livro sobre modelagem do negócio).

Modelagem de dados

O fluxo de informações definido anteriormente é refinado num conjunto de objetos dados que são necessários para dar suporte ao negócio. Os atributos de cada objeto são identificados e as relações entre esses objetos são definidas (ainda é anterior ao Use Case... é como se estivéssemos definindo os atores e os use cases sem definir a relação entre eles... - isso que eu entendi vendo o item seguinte).

Modelagem do processo

Os objetos de dados definidos na fase anterior são transformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados (acho que aqui monta-se propriamente o use case).

Geração da aplicação

Ao invés de usar linguagens procedimentais, o RAD usa linguagens de 4ª geração (4GL é um exemplo - permite que defina a especificação do projeto e a FRAMEWORK cria tudo... relatórios, cadastros, etc. - lembra da idéia do gerador de sites? Acho que é por aí, mas para aplicações mesmo). Seu desenvolvimento é feito para reutilizar componentes (quando possível) ou criar novos componentes reutilizáveis. Em todos os casos ferramentas automatizadas são usadas para facilitar a construção do software.

Teste e entrega

Como o processo RAD tem foco nos componentes, muitos dos componentes já devem ter sido testados. Isso reduz o tempo total de teste. Porém novos componentes devem ser testados e as interfaces exaustivamente exercitadas.

Se uma aplicação comercial pode ser modularizada de modo a permitir que cada função principal possa ser completada em menos de 3 meses usando a abordagem anterior, ela é candidata ao RAD. Cada função pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo.

Desvantagens

1) Para projetos grandes (mensuráveis) o RAD exige muitos recursos humanos.

2) Exige desenvolvedores e clientes compromissados com atividades contínuas e rápidas. Se não houver esse comprometimento, os projetos falharão.

3) Nem todos os tipos de aplicações são apropriadas para o RAD. Se o sistema não puder ser adequadamente modularizado, a construção dos componentes será problemática. Se for preciso um desempenho superior e esse desempenho seja conseguido com o ajuste dos componentes, a abordagem RAD pode não funcionar.

4) Quando riscos técnicos forem elevados, o RAD não é adequado (ex: uso de uma tecnologia nova ou exige comunicação com outros programas).