A ascensão do RAD e sua aplicação na indústria de tecnologia
Em uma tentativa de tornar o desenvolvimento de software muito mais econômico e eficiente em termos de tempo, o RAD, ou desenvolvimento rápido de aplicativos, foi proposto na década de 1980.
O desenvolvimento de software nem sempre foi tão fluido e eficiente. Os primórdios do desenvolvimento de software levaram meses para serem preparados e ainda mais meses no processo de desenvolvimento, assim como a engenharia tradicional. Os desenvolvedores criariam um plano que levaria meses laboriosos e os arquitetos de software trabalhariam diretamente com os usuários finais para criar projetos funcionais antes de defini-los em folhas de especificações. Se seus clientes não gostassem da opção que lhes foi apresentada, ela estava de volta à prancheta e os desenvolvedores teriam que recomeçar do zero, levando até anos para produzir algo que seus clientes solicitaram primeiro. Além do custo de oportunidade, os gastos para financiar tais empreendimentos eram astronômicos.
Em uma tentativa de tornar o desenvolvimento de software muito mais econômico e eficiente em termos de tempo, o RAD, ou desenvolvimento rápido de aplicativos, foi proposto na década de 1980. A ideia era que o desenvolvimento de software deveria ser tratado como um processo maleável e intuitivo, ao invés de algo rígido como a construção de um edifício. Em vez de se concentrar no planejamento dispendioso, a RAD enfatizou a prototipagem rápida.
Os pioneiros, Barry Boehm e James Martin, entre outros, projetaram seus respectivos modelos de desenvolvimento, como o modelo Spiral e o modelo James Martin RAD. O modelo de James passou a inspirar o desenvolvimento ágil.
Metodologias RAD variadas têm práticas semelhantes
Em vez de ser extremamente detalhado com sua visão, a RAD se concentra no desenvolvimento em torno de um conjunto solto de requisitos. Desenvolvedores e clientes precisam trabalhar juntos em um processo contínuo para desenvolver um aplicativo que atenda às suas necessidades de maneira eficaz. É muito parecido com criar arte. Às vezes, você pode ter uma inspiração para uma determinada arte usando cores específicas, mas à medida que avança e desenvolve o desenho, descobre que a arte precisa ser ajustada ou que outra cor seria esteticamente mais agradável.
Em vez de manter os desenvolvedores contra um conjunto firme de expectativas, o RAD permite a criatividade em certo sentido. Uma vez que a visão se reúne, é hora da prototipagem e o processo RAD usual exige que os desenvolvedores enviem um protótipo que possa demonstrar como o produto final pode parecer ou sentir. Ele pode estar cheio de links mortos ou caminhos vazios, mas dá ao cliente uma ideia clara do que o desenvolvedor está criando.
Depois que o cliente oferece feedback sobre como o aplicativo pode ser melhorado, ou se algum ajuste adicional for necessário, o desenvolvedor pegará todo o feedback que ele acumulou e o aplicará ao produto final. Às vezes, os usuários finais também entram em jogo, que é quando você pode ver o teste beta, onde o produto geralmente é dado aos usuários finais gratuitamente em troca de seus comentários.
Se o software não atender à visão do cliente, o desenvolvedor terá que voltar a projetar o software. Às vezes, a culpa não é apenas do desenvolvedor. O cliente também pode perceber que sua ideia funciona melhor no papel, então cabe aos dois chegar a algo mais intuitivo ou conciso.
Depois que o cliente aprovar o protótipo, os desenvolvedores poderão prosseguir para a finalização do produto. É aqui que os desenvolvedores começam a conectar os pontos e desenvolver o produto, fazendo tudo o que podem para enviar um produto final.
Embora o RAD possa parecer vantajoso, também existem desvantagens
O RAD é definitivamente menos demorado do que as abordagens tradicionais em cascata, mas não é apropriado para grandes corporações que não possuem comunicação eficaz. Uma equipe menor de desenvolvedores provavelmente se beneficiará das práticas RAD, mas qualquer organização que exija comunicação entre equipes pode atrasar a produção em vez de aprimorá-la.
Outro problema com o RAD é que os desenvolvedores são muito mais propensos a projetar um produto que satisfaça o cliente, mas não atenda às necessidades dos usuários finais. Por exemplo, o Facebook como rede de mídia social é bem-sucedido, pois oferece recursos alinhados à natureza humana. Somos criaturas sociais que gostam de atenção e conectividade. No entanto, se hoje o Facebook se concentrasse mais em marketing do que em seu design centrado no ser humano, talvez nunca tivesse decolado do jeito que fez. Se o proprietário de uma empresa quisesse criar o Facebook apenas para fins de marketing, o fascínio inicial do site de rede seria perdido à medida que os desenvolvedores se esforçassem para desenvolver um site que se alinhasse com a visão de seus clientes.
Alguns projetos definitivamente exigem metodologia tradicional em cascata, como qualquer software de missão crítica, como controle de voo, software de monitoramento que salva vidas e assim por diante. Para o mercado orientado ao consumidor, no entanto, o RAD não é apenas a escolha mais óbvia – é simplesmente a melhor.
