Desenvolvimento Rápido de Aplicação(RAD)

Apresentação em tema: "Desenvolvimento Rápido de Aplicação(RAD)"— Transcrição da apresentação:

1 Desenvolvimento Rápido de Aplicação(RAD)
Schubert Carvalho Thaise Yano Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC Disciplina de Engenharia de Software - MO409 Setembro/2004

2 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

3 Introdução e Motivação
Definição “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. Objetivos do RAD Desenvolvimento Rápido Melhor Qualidade Custos mais baixos Sucesso ferramentas, metodologia, pessoal qualificado e gerenciamento. Num mundo competitivo dominado por “deadlines”, onde uma vantagem competitiva pode depender da rapidez com que um produto de software é desenvolvido, existe a necessidade de se desenvolver técnicas que agilizem o processo de desenvolvimento. Uma destas técnicas é o RAD. O termo RAD surgiu em 1990 (James Martin [2]), com o objetivo reduzir o tempo do desenvolvimento de software, aumentar a qualidade e de produzir um produto a baixo custo [2,4]. De acordo com Martin [2], isto pode ser feito, inicialmente, através do desenvolvimento de um ciclo de vida mais rápido e de melhor qualidade do que os ciclos de vida tradicionais. Na literatura existem várias definições para o termo RAD e todas elas são válidas, do ponto de vista do problema que se deseja resolver [2]. De acordo com Rob Kemmer [1] “RAD é um caminho para desenvolver software, tendo como base ambientes de desenvolvimentos poderosos que tornam o processo de desenvolvimento melhor e mais rápido”. Os objetivos do RAD estão relacionados com desenvolvimento rápido, alta qualidade e baixo custo. O sucesso destes objetivos está relacionado com quatro fatores: ferramentas, metodologia, pessoal qualificado e gerenciamento das atividades. Setembro/2004

4 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. Como cada desenvolvedor possui a sua própria metodologia para um desenvolvimento baseado no RAD [2], o ciclo de vida de suas atividades é, geralmente, baseado no problema do cliente e no tempo disponível para a entrega do produto [3]. Devido a estes problemas, no início de 1994 um grupo entitulado “Dynamic Systems Development Method” (DSDM) [6] propôs um padrão para o ciclo de vida do RAD. Este modelo de ciclo de vida não será discutido aqui, pois o DSDM será apresentado posteriormente por outro grupo. Outro ciclo de vida muito utilizado é o ciclo de vida de quatro fazes de James Martin [4,5] dividido em: análise de requisitos, projeto com usuário, construção e implementação. Setembro/2004

5 Ciclo de Vida Ciclo de vida de 4 fases de Martin Setembro/2004
Análise de Requisitos Projeto com Usuário Construção Análise de requisitos: esta etapa produz as definições dos requisitos do sistema proposto, em termos das funções que irão compor o mesmo. As entregas desta fase incluem: um esboço do modelo do sistema (entidade e modelos de processo) referente a área de estudo, uma definição do escopo do sistema e a informação de custo do sistema. Projeto com usuário: nesta etapa é feita uma análise mais detalhada das atividades relacionadas com o sistema proposto, são realizados encontros mais freqüentes com as pessoas chaves do projeto e são feitos os detalhamentos das funções encontradas na etapa anterior. A análise é completada através da criação de diagramas de ação, os procedimentos do sistema são desenvolvidos e já é feito um protótipo inicial contendo os procedimentos mais críticos. Construção: nesta etapa uma pequena equipe de desenvolvedores, trabalhando diretamente com os usuários, finalizam o projeto e constroem o sistema. O processo de construção do software consiste de uma série de passos "projeto-construção", onde os usuários e desenvolvedores tem a oportunidade refinar os requisitos e de revisar a implementação do software resultante. Nesta etapa também esta incluída a documentação e as instruções necessárias para operar a nova aplicação. Implementação: esta etapa envolve a implementação do novo sistema e o gerenciamento das atividades de mudanças do sistema antigo para o novo. Isto inclui a implementação do sistema novo, conversão de dados, e treinamento de usuários. Esta etapa termina com a aceitação do usuário. Basicamente é isto que acontece neste ciclo de vida. Implementação Setembro/2004

6 Atividades de Controle de Qualidade
Constante interação com usuário DSDM (Dynamic Systems Development Method) PSP (Personal Software Process) TSP (Team Software Process) Uma grande vantagem de RAD é que os usuários são envolvidos desde o início do processo na avaliação do software. A fim de obter um desenvolvimento rápido a maioria dos projetos RAD não elaboram projetos bem definidos e não utilizam metodologias rigorosas, produzindo software com pouca qualidade e códigos difíceis de serem mantidos. Com o objetivo de estabelecer um método que permita incorporar qualidade a projetos RAD, foi criado o DSDM (Dynamic Systems Development Method). Esse sugere, por exemplo, a aplicação de inspeções, revisões e teste, como também sugere atividades de controle de gerenciamento e manutenção. Geralmente, os gerentes de projeto são treinados em problemas técnicos e não o suficiente em gerenciamento de pessoas. Para prover um guia de como um gerente de projeto deve ser treinado para gerenciar efetivamente seus empregados, foi desenvolvido o PSP (Personal Software Process), um processo de software que é baseado na qualidade dos princípios de gerenciamento para ser usado por um engenheiro de software a ajudá-lo a gerenciar e melhorar seu desempenho individual. Para prover um guia de como trabalhar em grupo foi desenvolvido o TSP (Team Software Process) que estende e refina o CMM e PSP. No artigo [8], é apresentado uma forma de combinar o uso do DSDM e PSP para obter um processo de software de qualidade. Setembro/2004

7 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 Sem um forte gerenciamento de configuração, problemas podem ocorrer, tal como a última versão do código fonte não poder ser encontrada. O gerenciamento de configuração ajuda a manter a integridade e localização da configuração, sendo um processo que gerencia a evolução do produto durante seu ciclo de vida e cria um histórico verificável do produto. É importante que no gerenciamento de configuração tenha um adequado controle de inclusão de requisitos e controle de pedidos de mudanças de requisitos. A inclusão de requisitos não essenciais precisam ser cuidadosamente controlados. Talvez algumas das desejadas características possam ser incluídas na próxima versão. Caso alguma característica precise ser incluída, então talvez possa-se negociar e adiar uma característica que está no plano corrente ou estender o deadline. O controle de pedido de mudança de requisito é crucial para o sucesso do projeto, como é um forte programa de gerenciamento de configuração. Mudanças nos requisitos precisam ser documentadas, aprovadas por todas as partes. Todas as partes envolvidas precisam estar cientes dos efeitos no planejamento quando os requisitos são modificados e que o risco de perder o deadline é aumentado. Setembro/2004

8 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 O gerenciamento precisa escolher projetos que possam ter um escopo bem-definido para reduzir características que mudam constantemente. Projetos com muitos “tentáculos” são poucos adequados para RAD [2]. Clientes precisam estar comprometidos em tempo integral, tomar decisões rápidas e estar sempre acessíveis, embora a maioria dos clientes não satisfazem tais condições [2]. Setembro/2004

9 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 Geralmente um projeto não inicia bem porque o planejamento foi feito por gerenciamento de alto-nível e/ou por marketing, resultando em planejamentos super-otimistas. Mesmo quando os desenvolvedores de software estabelecem um planejamento bem-definido, é comum outros o modificarem para adequá-lo a suas necessidades, assim aumentando o risco de falha. Ao estabelecer um planejamento razoável e gerenciar o projeto de software e a qualidade de seus produtos, pode-se obter métricas e estimativas do progresso do projeto. Assim, aumenta a predição de planejamentos, o controle de qualidade do software, o controle de custo e gerenciamento de risco e a redução de re-trabalho. Isso conduz a redução do tempo do ciclo de desenvolvimento e aumento na produtividade [9]. A fim de obter maior competitividade, as organizações precisam investir e motivar o aumento da capacidade de seus desenvolvedores, tentando conciliar as motivações dos indivíduos às da organização [9]. O sucesso da introdução de uma nova técnica em RAD depende o quanto os desenvolvedores estão motivados. Normalmente, se um projeto está em crise, pessoas podem ser adicionadas muito tarde no projeto na esperança de alcançar o deadline. No entanto, pode-se levar seis meses ou mais para obter um empregado produtivo [9]. A velocidade do desenvolvimento pode ser melhorado com o uso de ferramentas efetivas. Procura-se pela “bala de prata” acreditando numa nova tecnologia para salvar o dia. Os benefícios da nova ferramenta são superestimados. Existe uma falta de entendimento que quando uma nova ferramenta ou tecnologia é introduzida ao projeto, a produtividade cairá primeiramente antes que cresça, devido à curva de aprendizagem envolvida. Se a introdução de novas tecnologias em toda organização for muito rápido pode causar aumento de atrasos no planejamento. Ao invés de acreditar em novas tecnologias para salvar o projeto, ênfase deve ser dada aos princípios de desenvolvimento sólidos. E deve-se introduzir a tecnologia de maneira controlada. Um aspecto que deve ser lembrado é incorporar tempo adicional no planejamento e dinheiro no orçamento para treinamento dos empregados na nova tecnologia [9]. Setembro/2004

10 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] Devido à aplicação de metodologias informais e a elaboração de projetos pouco definidos e planejados, em geral, os software desenvolvidos em RAD são instáveis e difíceis de serem mantidos. Muitas vezes os software precisam ser reconstruídos após um ano por falta de robustez [2]. Através de uma elaboração de projeto bem planejado e gerenciado, do uso de metodologias mais rigorosas e da atividades do DSDM, pode-se conseguir um software de melhor qualidade que não necessite sofre muitas modificações e, consequentemente, manutenção. Setembro/2004

11 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

12 Referências [1] (30/08/04) [2] Reilly J.P. Does RAD live up to the hype? IEEE, Vol. 12, p (1995). [3] Barry W.B. Making RAD Work for Your Project. IEEE, Vol. 3, p (1999). [4] Agarwal R., Prasad J., Tanniru M., Lynch J., Risks of rapid application development. ACM Communication, Vol. 1, p (2000). [5] (05/09/04) [6] Millington, D., Stapleton, J. Developing a RAD standard. IEEE p (1995) [7] (20/08/04) [8] Coleman G., Verbruggen R., A quality software process for rapid application development. Software Quality Journal 7, p (1998) [9] McQuaid P., Rapid Application Development - Project Management Issues to Consider. Software Quality Professional Journal, Vol. 3, Issue 3, p (2001) Setembro/2004