Desenvolvimento rápido de aplicações

Desenvolvimento Rápido de Aplicação (do inglês: "Rapid Application Development" - RAD) é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias), registrado por James Martin em 1991, tem substituído gradativamente o termo de prototipação rápida que já foi muito utilizada no passado

Histórico

Os modelos de processo de software apresentados durante a década de 70, cujo modelo em cascata é um bom representante, possuíam longos períodos de desenvolvimento e muitas vezes os requisitos do sistema se alteravam antes do fim do processo. Os desenvolvedores de software necessitavam de um modelo mais ágil que permitisse um tempo de desenvolvimento mais curto e a mudança dos requisitos durante o processo.

Nos anos 80 os trabalhos de Barry Boehm (modelo de processo em espiral) e Tom Gilb (modelo de processo evolucionário) serviram de base para uma metodologia chamada de Rapid Iterative Production Prototyping (RIPP) criada por Scott Shultz. Então James Martin estendeu o RIPP agregando valores de outros processos tornando-o maior e mais formal sendo assim denominado de RAD, que foi finalmente formalizado em 1991 com a publicação de um livro.

Fases do processo

O número de fases do processo varia de acordo com os autores.

Segundo Kerr, o processo se divide em 5 fases:

Ex: Clarion, Delphi, Visual Basic, Asp.net, NetBeans, Eclipse entre outras...

Esta divisão do processo é compartilhada por diversos autores inclusive Roger S. Pressman, cuja obra é utilizada em diversas faculdades como livro guia para os estudantes.

Porém existem outras abordagens utilizadas. Segundo Stephen E. Cross Diretor do SEI - Software Engineering Institute da Carneggie Mellon, uma maneira de abordar o RAD de forma mais eficiente é dividi-lo em 6 passos:

A proposta de Stephen é disciplinar o RAD, que é muitas vezes criticado por sua suposta informalidade, de forma a conseguir até mesmo níveis do processo Modelo de Maturidade em Capacitação (CMM) para melhorar e formalizar ainda mais o processo.

Características

Vantagens

  • Permite o desenvolvimento rápido e/ou a prototipagem de aplicações;
  • Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);
  • Cada função principal pode ser direcionada para a uma equipe RAD separada e então integrada a formar um todo;
  • Criação e reutilização de componentes;
  • Usado principalmente para aplicações de sistemas de informações;
  • Comprar pode economizar recursos se comparado a desenvolver;
  • Desenvolvimento é conduzido em um nível mais alto de abstração;
  • Visibilidade mais cedo (protótipos);
  • Maior flexibilidade (desenvolvedores podem reprojetar praticamente a vontade);
  • Grande redução de codificação manual (wizards…);
  • Envolvimento maior do usuário;
  • Provável custo reduzido(tempo é dinheiro e também devido ao reuso);
  • Aparência padronizada (As APIs e outros componentes reutilizáveis permitem uma aparência consistente).

Desvantagens

  • Se uma aplicação não puder ser modularizada de modo que cada função principal seja completada em menos de 3 meses, não é aconselhável o uso do RAD;
  • Para projetos grandes (mas escaláveis) o RAD exige recursos humanos suficientes para criar o número correto de equipes, isso implica um alto custo com a equipe;
  • O envolvimento com o usuário tem que ser ativo;
  • Comprometimento da equipe do projeto;
  • O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada quando se está testando novas tecnologias ou quando o novo software exige alto grau de interoperabilidade com programas de computador existentes. Falta de prazo pode implicar qualidade reduzida, e há necessidade de habilidade maior dos desenvolvedores, e suporte maior da gerência e dos clientes.
  • Desenvolver pode economizar recursos se comparado a comprar;
  • Custo do conjunto de ferramentas e hardware para rodar a aplicação;
  • Mais difícil de acompanhar o projeto(pois não existe os marcos clássicos);
  • Menos eficientes;
  • Perda de precisão científica (falta de métodos formais);
  • Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento;
  • Funções reduzidas (reuso, "timeboxing");
  • Funções desnecessárias (reuso de componentes);
  • Problemas legais;
  • Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes)
  • Padronização (aparência diferente entre os módulos e componentes)
  • Sucessos anteriores são difíceis de se reproduzir

É apropriado quando

  • A aplicação é do tipo "stand alone";
  • Pode-se fazer uso de classes preexistentes (APIs);
  • A performance não é o mais importante;
  • A distribuição do produto é pequena;
  • O âmbito do projeto é restrito;
  • O sistema pode ser dividido em vários módulos independentes;
  • A tecnologia necessária tem mais de um ano de existência.

Deve ser evitado quando

  • A aplicação precisa interagir com outros programas;
  • Existem poucos plugins e componentes disponíveis;
  • Performance é essencial;
  • O desenvolvimento não pode tirar vantagem de ferramentas de alto nível;
  • A distribuição do produto será em grande escala;
  • Para se construir sistemas operacionais (confiabilidade exigida alta demais)
  • Jogos de computador (performance exigida muito alta)
  • Riscos tecnológicos muito altos devido a tecnologia ter sido recém lançada;
  • O sistema não pode ser modularizado

Ligações externas