Desenvolvimento Rápido
de Aplicação(RAD)
Schubert Carvalho
Thaise Yano
{schubert.carvalho,thaise.yano}@ic.unicamp.br
Universidade Estadual de Campinas - UNICAMP
Instituto de Computação - IC
Disciplina de Engenharia de Software - MO409
Setembro/2004
Tópicos





Introdução e Motivação
Ciclo de Vida
Fatores para desenvolvimento rápido
Algumas Considerações sobre a Utilização
do RAD
Referências
Setembro/2004
Introdução e Motivação

Definição



Objetivos do RAD




“RAD é um caminho para desenvolver software, tendo como base
ambientes de desenvolvimento modernos e poderosos que tornam o
processo de desenvolvimento de software melhor e mais rápido”, Rob
Kemmer [1] .
RAD = fazer mais rápido e melhor do você faz no momento.
Desenvolvimento Rápido
Melhor Qualidade
Custos mais baixos
Sucesso

ferramentas, metodologia, pessoal qualificado e gerenciamento.
Setembro/2004
Ciclo de Vida

Não existe um ciclo de vida padrão

Alguns modelos adotados


DSDM (Dynamic Systems Development Method)
Ciclo de vida de 4 fases de James Martin [4,5]

análise de requisitos, projeto com usuário,
construção e implementação.
Setembro/2004
Ciclo de Vida

Ciclo de vida de 4 fases de Martin
Análise de
Requisitos
Projeto com
Usuário
Construção
Implementação
Setembro/2004
Atividades de Controle de
Qualidade




Constante interação com usuário
DSDM (Dynamic Systems Development
Method)
PSP (Personal Software Process)
TSP (Team Software Process)
Setembro/2004
Atividades de Controle de
Configuração

Gerenciamento de configuração



Controle de inclusão de requisito
Controle de pedido de mudança de requisito
Auditoria de configuração
Setembro/2004
Diretrizes de Gerenciamento de
Projeto


Escolher projetos de escopo bem-definido
Clientes precisam estar comprometidos em
tempo integral, tomar decisões rápidas e
estar sempre acessível
Setembro/2004
Diretrizes de Gerenciamento de
Projeto




Estabelecer planos razoáveis
Treinamento no gerenciamento de pessoas
Motivar desenvolvedores
Evitar “enganos clássicos”


Tecnologia nova é a “bala de prata”
Adição tardia de pessoas no projeto
Setembro/2004
Manutenção

Geralmente, software são instáveis e
difíceis de serem mantidos

Software precisam ser reconstruídos após um
ano por falta de robustez [2]
Setembro/2004
Algumas Considerações
sobre a Utilização do RAD




Os objetivos do cliente são bem definidos
As decisões são tomadas por um número
pequeno de pessoas, que podem ser acessadas
facilmente.
Os desenvolvedores são poucos, de preferência
seis ou menos.
A arquitetura técnica é clara e bem definida e a
tecnologia usada é acessível e já foi bem
testada.
Setembro/2004
Referências









[1] http://www.soc.napier.ac.uk/module.php3?op=getlecture&cloaking=no&lectureid=1574455
(30/08/04)
[2] Reilly J.P. Does RAD live up to the hype? IEEE, Vol. 12, p. 24-26 (1995).
[3] Barry W.B. Making RAD Work for Your Project. IEEE, Vol. 3, p. 113-114 (1999).
[4] Agarwal R., Prasad J., Tanniru M., Lynch J., Risks of rapid application development. ACM
Communication, Vol. 1, p. 177-188 (2000).
[5]http://sysdev.ucdavis.edu/WEBADM/document/rad_toc.htm (05/09/04)
[6] Millington, D., Stapleton, J. Developing a RAD standard. IEEE p. 54-55 (1995)
[7] http://www.gantthead.com/process/processMain.cfm?ID=2-19516-2 (20/08/04)
[8] Coleman G., Verbruggen R., A quality software process for rapid application development.
Software Quality Journal 7, p. 107-122 (1998)
[9] McQuaid P., Rapid Application Development - Project Management Issues to Consider.
Software Quality Professional Journal, Vol. 3, Issue 3, p.19-25 (2001)
Setembro/2004