METODOLOGIAS DE DESENVOLVIMENTO: UM COMPARATIVO ENTRE EXTREME PROGRAMMING E RATIONAL UNIFIED PROCESS

Transcrição

1 1 METODOLOGIAS DE DESENVOLVIMENTO: UM COMPARATIVO ENTRE EXTREME PROGRAMMING E RATIONAL UNIFIED PROCESS MOREIRA, Albert M. 1 RESUMO: Atualmente, no âmbito da engenharia de software, uma boa metodologia de projetos tem se tornado um fator diferencial, visto que influencia diretamente na qualidade do produto final. Este artigo apresenta o histórico do processo de desenvolvimento de software e faz uma comparação entre a metodologia rigorosa Rational Unified Process (RUP) e a ágil Extreme Programming (XP). Finalmente, são mostrados casos de sucesso das duas abordagens. PALAVRAS-CHAVE: Engenharia de Software, Metodologias Rigorosas, Metodologias Ágeis, Extreme Programming, Rational Unified Process. 1. INTRODUÇÃO O que se busca na Engenharia de Software é o incessante melhoramento do processo de desenvolvimento de software. Os prazos e custos estipulados podem não chegar a serem alcançados, mesmo com a crescente evolução da tecnologia, métodos e recursos. Um dos principais motivos é a excessiva formalidade nos modelos de processos colocados nos últimos 30 anos (LARMAN, 2004). Existe então a necessidade de desenvolver software de forma mais rápida, sem que se perca a qualidade. O novo paradigma em desenvolvimento de software é que se pode obter esse resultado por meio da utilização de métodos ágeis. Embora as metodologias ágeis tenham sido apontadas como alternativa às abordagens tradicionais para o desenvolvimento de software, as metodologias tradicionais, conhecidas também como rigorosas, pesadas ou orientadas a planejamentos, possuem utilização garantida no que diz respeito a situações em que os requisitos do sistema são complexos e estáveis e requisitos futuros são previsíveis. Este artigo aborda vantagens e desvantagens de metodologias ágeis e de metodologias rigorosas, particularmente, da metodologia rigorosa Rational Unified Process e da ágil Extreme Programming, além de citar casos de sucesso da aplicação de ambas. Na Seção 2, é apresentado o histórico do processo de desenvolvimento de software, desde o uso restrito das metodologias tradicionais até a criação do Manifesto Ágil. Na Seção 3 e 4, são apresentados conceitos básicos sobre os métodos ágeis e tradicionais, respectivamente, além de suas aplicações. Na Seção 5, é apresentado um comparativo entre o método RUP e o XP e, na sessão 6, casos de sucesso relacionados a estas. Por fim, na Seção 7, estão as considerações finais. 1 Albert Menezes Moreira é graduando do curso de Bacharelado em Sistemas de Informação da Faculdade Ruy Barbosa e realizou este trabalho sob a orientação da professora Izabel Cristina Andion Castro, mestra em redes pela UNIFACS.

2 2 2. HISTÓRICO Baseadas em mainframes e terminais burros, as metodologias tradicionais fizeram parte, inicialmente, de um contexto de desenvolvimento de software muito diferente do atual (ROYCE, 1970). O custo para que modificações fossem feitas era alto, devido às limitações dos computadores e falta de ferramentas modernas para apoiar a criação do software, tais como depuradores e analisadores de código. Sendo assim, o software era antes planejado e documentado para então ser implementado. O modelo Clássico caracterizado como metodologia tradicional é utilizado até hoje. Nos últimos anos, novas metodologias foram aplicadas, sempre visando a rapidez no fornecimento aliada à qualidade do processo e do produto. Surgem, então, os métodos ágeis, popularizados quando Beck et al. (2001) criaram o Manifesto Ágil indicando alguns princípios compartilhados por tais métodos: a) Indivíduos e interações são mais importantes que processos e ferramentas; b) Software funcionando é mais importante do que documentação detalhada; c) Colaboração dos clientes é mais importante do que negociação de contratos; d) Adaptação às mudanças é mais importante do que seguir um plano. Nesta nova abordagem a reutilização de software é uma prática comum durante o desenvolvimento. Os padrões de projeto contribuem para o reuso em situações em que é preciso um nível alto de abstração, sobretudo na fase de análise, na definição da arquitetura do sistema, em questões organizacionais e de otimização dos processos, sendo que esses dois últimos têm por objetivo apoiar a construção do software e melhorar o seu desenvolvimento. O uso de componentes é outro aspecto possível. Deste modo, a integração dos padrões organizacionais e de processo proporciona rapidez e qualidade no desenvolvimento. 3. METODOLOGIAS RIGOROSAS Essas metodologias são assim denominadas porque enfatizam o rigor nas premissas e propostas. Prezam pela documentação detalhada em todas as fases do desenvolvimento. Geralmente são implementadas em ambientes onde se deve exercer controle rígido, como por exemplo quando é grande o número de indivíduos que participam do projeto. Também são conhecidas como metodologias pesadas, uma referência à quantidade de documentos, papéis, atividades e processos considerados necessários para a implementação. O resultado disso é que os desenvolvedores passam boa parte do tempo ocupados com atividades que não são necessariamente ligadas à programação ou seu processo criativo. O modelo Clássico foi o primeiro processo de desenvolvimento de software publicado (PRESSMAN, 2001). É um modelo que apresenta uma seqüência a ser seguida. Cada etapa tem uma documentação que precisa ser aprovada para que se dê início à etapa seguinte. De uma forma geral fazem parte do modelo Clássico as etapas de definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção (SOMMERVILLE, 2003). A figura 1 mostra a disposição dessas fases, juntamente com a ordem de aplicação:

3 3 Figura 1: Fases do modelo Clássico Adaptado de: SOMMERVILLE, 2003 O problema deste modelo, também chamado de modelo em Cascata, é a impossibilidade de criação de fases intermediárias ou até mesmo revisão de fases anteriores antes que o processo termine. Fred Brooks em seu artigo No Silver Bullet: Essence and Accidents of Software Engineering, sustenta essa idéia na afirmação de que é impossível especificar totalmente um software antes da sua implementação (BROOKS, 1987). Isso dificulta alterações, fator comum no desenvolvimento de um projeto. Sua utilização é feita quando os requisitos estão bem compreendidos. O modelo Clássico ainda perdurou até a década de 90 como forma de desenvolvimento e foi utilizado com sucesso quando os requisitos estavam bem compreendidos Rational Unified Process Atualmente um grande representante das metodologias rigorosas é o RUP, um recurso de Engenharia de Software criado pela empresa Rational Software Corporation que descreve a maneira de desenvolver um software usando técnicas comerciais e objetivando o aumento da qualidade do produto gerado. É classificado também como um processo de engenharia de software que tem como principal objetivo garantir o desenvolvimento de sistemas com qualidade, respeitando os requisitos solicitados pelo cliente, em prazos e custos determinados. Pode ser considerado como um conjunto de experiências e boas práticas adquiridas por diversas pessoas e empresas envolvidas com o desenvolvimento de softwares. Sua primeira versão, o RUP 5.0, surgiu em 1998, oriunda da evolução de projetos anteriores, como o Rational Objectory Process, iniciado em Várias características foram melhoradas e acrescentadas até a versão RUP A aplicação do RUP se dá em variados projetos, sendo tratado como um arcabouço (framework) genérico para os processos de desenvolvimento, considerando a configuração adequada para o tamanho e a necessidade do projeto e os padrões aplicados na empresa. Associada a este modelo, a Rational Software construiu também um conjunto de ferramentas de suporte ao desenvolvimento (RUP, 2007). A Unified Modeling Language - UML, que oferece um conjunto de modelos para auxiliar o desenvolvimento de software, é um exemplo de linguagem que foi criada para apoiar a utilização do RUP.

4 4 Como bases para a criação deste método foram adotadas algumas características de qualidade de software, que permitem atingir os objetivos desejados. Dentre elas, seis características merecem destaque especial: a) O uso de interações com o cliente para desenvolvimento de softwares; b) Gerenciamento de requisitos; c) Utilização de artefatos visuais, a exemplo de modelos UML; d) Controle de qualidade; e) Controle de mudanças; f) A necessidade da utilização de uma metodologia de desenvolvimento de sistemas. No modelo RUP, um projeto é dividido diversas fases, desde a Modelagem do Negócio até o Ambiente. Estas ainda possuem outras 4 subdivisões, que constituem o ciclo de construção de uma versão, como é mostrado na figura 2: Figura 2: Ciclo de construção de uma versão usando RUP Adaptado de: KRUCHTEN, 2000 A fase de Concepção, Inception phase, é onde deve ser definido o escopo da versão, especificando o produto a ser gerado. É nessa etapa que se avaliará a viabilidade do projeto, pois neste momento os requisitos operacionais e os critérios de aceitação serão apresentados. Devem ser levantados os riscos que possam comprometer o andamento do projeto, levando em consideração questões de arquitetura. É pertinente também a aplicação de um cronograma preliminar. Dentre os produtos finais desta fase estão o cronograma, o diagrama de caso de uso inicial, o caso de uso do negócio, que quando aplicado em sistemas comerciais deve fornecer uma estimativa de retorno do investimento e o protótipo preliminar (MAGALHÃES, 2003). O objetivo da fase de Elaboração, Elaboration Phase, é analisar o domínio do problema, criar o plano de projeto, a arquitetura e remover os elementos de alto risco. Tratam-se de riscos de requerimentos, tecnológicos em relação à capacidade das ferramentas disponíveis, de habilidades dos integrantes do projeto e políticos (RUP, 2007). É uma etapa crítica, pois o que for definido nesta fase será utilizado como base para as próximas e à medida que o projeto avança aumenta o custo de modificações.

5 5 A fase de Construção, Construction phase, consiste no desenvolvimento do produto. É a etapa de construção do código, com ênfase no gerenciamento de recursos e controle das operações, adotando medida de redução dos custos. Nesta fase, os componentes gerados são também testados e submetidos aos critérios de aceitação que foram definidos na fase anterior. Ao fim desta fase, o produto estará pronto para ser entregue ao usuário, integrado às plataformas necessárias, com manual de usuários e uma descrição sobre esta versão (MAGALHÃES, 2003). Na fase final do processo que é chamada de Transição, Transition phase, o produto será entregue. Engloba também os procedimentos de treinamento, suporte e manutenção. Esta fase inclui os testes finais de aceitação, no intuito de captar o feedback do usuário a respeito dos resultados, além de comparações com outros sistemas antigos, conversões de banco de dados (se for o caso) e a divulgação do novo produto. As interações mostradas na figura 2 evidenciam o compromisso do RUP com o desenvolvimento incremental, que é construir o código e fazer os testes com componentes do sistema, gerando releases a cada fase. No fim da fase de elaboração, o protótipo da arquitetura está disponível para avaliação. Durante cada iteração da fase de construção, componentes terminados são integrados ao projeto. O ponto chave para este elemento é um conjunto de testes que acompanham a construção do produto (PROBASCO, 2000). O RUP permite a divisão do projeto em partes que serão desenvolvidas através de iterações, ou seja, repetição de todo o ciclo para cada uma das partes que serão integradas e incrementadas até o produto final. O RUP também pode ser utilizado no desenvolvimento e manutenção de projetos de pequeno ou de médio porte. Para que isso seja possível, alguns etapas ou passos podem ser eliminados a depender das características do projeto para simplificar ou diminuir as necessidades de documentação, minimizando a formalização (KOHRELL e WONCH,2005). As diferentes configurações do RUP possibilitam o suporte de equipes grandes e pequenas, além de técnicas de desenvolvimento disciplinadas ou menos formais (KRUCHTEN, 2000). Vale ressaltar que existe a coerência do modelo de processos RUP com os requisitos para certificação do processo de desenvolvimento Capability Maturity Model - CMM, onde as empresas de desenvolvimento podem certificar seu modelo de processo de desenvolvimento no quesito de maturidade e garantia de qualidade dos produtos gerados. Por exemplo, no terceiro nível do CMM, o conceito de processo é fortemente introduzido na organização. A arquitetura implantada do CMM nível 3 servirá como base para a execução das práticas de todas as áreas chave. Essa arquitetura torna-se, então, peça fundamental para a organização dos processos e sucesso do projeto. Com a adoção do RUP uma empresa já possui os prérequisitos para passar para o nível 3 do CMM (PIRES et al., 2007). 4. METODOLOGIAS ÁGEIS Como foi apresentado no segundo capítulo, o termo Metodologias Ágeis se tornou popular quando dezessete especialistas em processos de desenvolvimento de software, estabeleceram conceitos comuns a serem compartilhados por todos esses métodos. Foi então criada por BECK et al. (2007) a Aliança Ágil e instaurado o Manifesto Ágil.

6 6 O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas, documentação, negociação de contratos ou planejamento, mas mostrar o valor secundário que estes possuem diante dos indivíduos e interações, do bom funcionamento do software, da colaboração do cliente e das respostas velozes às modificações. Esses conceitos estão mais relacionados à forma que as pequenas e médias empresas trabalham, devido a estarem habituadas a mudanças. A mais conhecida dentre as metodologias ágeis é a Extreme Programming Extreme Programming A Extreme Programming - XP - é uma metodologia ágil voltada às equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se alteram com rapidez (BECK, 1999). As principais diferenças da XP em relação às outras metodologias são feedback constante e abordagem incremental. A figura 3 mostra algumas das características da Extreme Programming: Figura 3: Características da XP Adaptado de: XP, 2007 Nesta prática, é interessante que haja comunicação entre os indivíduos. O projeto C3, da Chrysler, foi o primeiro a usar a XP. Depois de anos tentando outras metodologias sem resultado, o uso da nova metodologia trouxe resultados satisfatórios em pouco mais de um ano. (HIGHSMITH et al., 2000). Grande parte das regras aplicadas á metodologia XP podem não fazer sentido à primeira vista, no entanto o diferencial são as partes que se complementam, o conjunto. A preocupação maior é com o rápido de desenvolvimento e satisfação do cliente, cumprindo as estimativas de tempo e custo. Os valores aplicados na Extreme Programming oferecem um ambiente propício para o progresso no trabalho. De acordo com definições da metodologia XP (2007), seus principais valores são: comunicação, simplicidade, feedback e coragem. O objetivo da comunicação é criar e manter o melhor relacionamento possível entre cliente e provedor de serviços, dando preferência, neste caso, a conversas pessoais do que através de outros meios. É encorajada também a comunicação entre desenvolvedores e gerente do

7 7 projeto. Este se caracteriza como um dos fatores principais na XP: conversar ao máximo pessoalmente, evitando o uso do telefone e mensagens de . A simplicidade visa a minimizar do código, desprezando funções consideradas desnecessárias ou não essenciais. Isto quer dizer que deve ser implementado o menor número de classes e métodos. Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando adicionar funcionalidades ligadas à evolução do produto. O importante é ter em mente que os requisitos são mutáveis. Sendo assim, o interessante na prática da Extreme Programming é implementar apenas que é estritamente necessário. O contato incessante com o cliente a respeito do projeto é o que se pode chamar de feedback constante. Informações sobre o código são dadas por testes periódicos, os quais indicam erros tanto individuais quanto do software integrado. Além disso, o cliente terá sempre uma parte do software funcional para avaliar. Com isso, novas características e informações são repassadas aos desenvolvedores, que por sua vez devem implementá-las nas próximas versões. Desta maneira, o que se pretende é entregar o software de acordo com as expectativas do cliente. A coragem se encaixa na implantação dos três valores anteriores. São necessários profissionais comunicativos e com facilidade de se relacionar. A coragem auxilia a simplicidade, quando a possibilidade de simplificar o software é detectada. Por fim, a coragem é necessária para garantir que o feedback do cliente ocorra com freqüência, pois esta abordagem implicará na possibilidade de mudanças constantes do produto. A orientação para o perfil das equipes no XP é de programadores experientes, já que é necessária a boa utilização do tempo de desenvolvimento do projeto. No que diz respeito à certificação CMM, a metodologia XP não possui os pré-requisitos necessários para sua implementação. 5. COMPARATIVO ENTRE RUP E XP E SUAS APLICAÇÕES No que diz respeito ao quesito tempo, é provável que o que é gasto pelas versões usando XP coincida com as iterações do RUP. Tal ocorrência não se aplica a projetos grandes, por se caracterizarem pela grande duração de suas iterações. Em projetos maiores, as equipes no RUP são geralmente divididas para se desenvolver paralelamente, cada uma com um subsistema. Embora a XP aplique a programação em duplas, o projeto é tratado como um todo, não em subsistemas. Na visão de Kruchten (2000), artefato é uma parte de uma informação produzida, modificada ou usada por um processo. São exemplos de artefato modelos, documentação, código fonte e arquivos executáveis. No Rational Unified Process, a comunicação é feia por meio de artefatos. A XP é baseada em comunicação oral, direta, restringindo ou limitando o uso da XP em projetos nos quais os desenvolvedores se encontram geograficamente dispersos. A partir da premissa de que os artefatos da XP possuem foco em estórias de usuário e código, o risco de projeto pode aumentar. Neste momento, a confiança recíproca é um fator vital. Acerca das atividades e dos papéis dentro do desenvolvimento do projeto, o RUP divide as tarefas de forma específica, ao passo que a divisão da XP não distingue funções específicas dentro das atividades. Isto quer dizer que o programador de um projeto que adote a Extreme

8 8 Programming não está necessariamente preso a determinada atividade, podendo se encaixar em outra, caso seja necessário. O RUP especifica a utiliza softwares da IBM, como o Rational Rose, embora já existam várias ferramentas que podem ser utilizadas. Por outro lado, a XP não especifica uma ferramenta para o processo, ainda que possa utilizar ferramentas livres como o Junit e o XPlanner (XP, 2007). Para tratar o código, o Rational Unified Process o subdivide em subsistemas (quando se trata de um sistema grande), delegando também membros responsáveis para cuidar de cada uma das partes (IBM, 2007). O XP trata o código coletivamente, permitindo que qualquer programador modifique o código caso encontre algum problema ou solução de otimização. Para garantir a veracidade do conhecimento nas metodologias, existem as certificações, que têm como finalidade atestar publicamente e por escrito que o produto, serviço, sistema, ou neste caso, o indivíduo, está em conformidade com as normas, requisitos ou regulamentos. No caso do RUP, o Rational Unified Process v2003 Certification test é considerado o ponto de partida, por ser a certificação base desta metodologia (IBM, 2007). Por outro lado, de acordo com Brewer (2007), não existe entidade certificadora para a Extreme Programming, não havendo, então, um teste para abordar conhecimentos desta metodologia. A tabela 1 apresenta algumas características presentes nas metodologias RUP e XP: Tabela 1: Comparativo entre RUP e XP. Adaptado de: RAWSTHORNE, 2007 Prática ou conceito RUP XP Iterativo e incremental SIM SIM Voltado para a arquitetura SIM NÃO Voltado para a validação NÃO SIM Interação desenvolvedor/cliente NÃO SIM Interação desenvolvedor/gerente SIM NÃO Interação desenvolvedor/suporte SIM SIM Gerenciamento de risco SIM SIM Qualidade de código NÃO SIM Gerenciamento dos pontos-chave SIM NÃO Equipes grandes SIM NÃO Equipes pequenas NÃO SIM Projetos complexos SIM NÃO Casos de uso SIM SIM De acordo com as comparações da tabela 1, pode-se concluir que ambas as abordagens têm pontos fortes e fracos (MOLPECERES, 2007). Enquanto o foco do Rational Unified

9 9 Programming são projetos complexos, onde são necessárias especificações maiores do projeto, a Extreme Programming possui seu foco em projetos mais simples, nos quais a burocracia e o excesso de documentos se caracterizam como perda de tempo. O objetivo futuro dos representantes das metodologias ágeis é eliminar os pontos fracos, como por exemplo a falta de análise de riscos, sem que isso as tornem metodologias pesadas. Não está no escopo da Extreme Programming a preocupação formal com o planejamento de riscos. Visto que riscos acontecem com freqüência em projetos desenvolvimento de software, a falta de análise de risco torna-se um fator negativo (SOARES, 2004). Outro aspecto é que para tornar as metodologias ágeis soluções para grandes empresas e equipes, visto que nestas empresas cada vez mais os indivíduos que participam de equipes se encontram dispersos geograficamente será importante resolver os problemas de comunicação. 6. CASOS DE SUCESSO Os tópicos abaixo apresentam dois casos de sucesso. O primeiro deles do sistema de desenvolvimento para negócio da empresa Ford Moto Credit, usando o RUP. O segundo do sistema de apoio a RH, na Assembléia Legislativa do Estado de São Paulo, desenvolvido pelos membros da AgilCoop - formada por professores e alunos da USP - usando a XP A empresa Ford Motor Credit padroniza metodologia de desenvolvimento usando IBM Rational Unified Process Ford Motor Credit é uma das maiores empresas de financiamento de automóveis do mundo, com operações em 36 países. Promove financiamento para produtos de montadoras como Ford, Aston Martin, Jaguar, Land Rover, Mazda, dentre outros. O departamento de TI da Ford Motor Credit estava procurando por um software de processo de desenvolvimento consistente. Cada equipe do projeto usou sua metodologia própria, dificultando o compartilhamento de conhecimento e rodízio entre as equipes. Além disso, os processos estabelecidos ofereciam suporte pobre ao desenvolvimento em Java 2 Enterprise Edition - J2EE, o que resultou em riscos de projeto (IBM, 2007). Como solução a companhia adotou o Rational Unified Process, personalizando para as necessidades específicas. O departamento de TI também implantou um programa para prover treinamento e servir como guia para equipes de projeto. Desta forma a Ford Motor Credit padronizou suas iniciativas de TI para desenvolvimento de software na metodologia IBM Rational Unified Process. Tomando como base um viés similar ao de outras empresas, o RUP foi customizado de acordo com as necessidades específicas. A equipe utilizou a metodologia RUP com gerentes de projetos, times de serviço e experts para customizá-la e adequá-la às suas necessidades. Com base em Java 2 Enterprise Edition, o departamento de TI implantou a Metodologia de Entrega de Soluções Unificada - Unified Solution Delivery Methodology (USDM), para seus projetos de software. Para viabilizar a adoção da USDM, a qual é baseada na abordagem iterativa característica do RUP, a empresa criou um detalhado programa de treinamento. Durante o processo, os instrutores ensinavam ao time de desenvolvimento os primeiros passos para usar a nova metodologia. Depois que os membros das equipes adquirem experiência com um ou dois projetos com a ajuda dos

10 10 instrutores, eles já se tornam preparados para desenvolver sem acompanhamento (IBM, 2007). Para lidar com os riscos de projeto foi criada uma ferramenta para mapeamento de caso de uso para riscos. Dirigindo-se a riscos precocemente no ciclo de vida do desenvolvimento, e dando prioridade aos casos do uso baseados no retorno no investimento, as equipes do desenvolvimento da Ford Motor Credit estabeleceram uma arquitetura estável, dando mais prioridade à entrega das funcionalidades críticas. Com isso, o departamento de TI da Ford Motor Credit passou a identificar e endereçar os riscos de projeto com mais rapidez no processo de desenvolvimento e as equipes passaram a entregar as soluções a tempo e atingir os padrões de qualidade Assembléia Legislativa do Estado de São Paulo: Assessoria e capacitação em desenvolvimento de software Durante o ano de 2005, uma equipe professores e alunos da AgilCoop, uma empresa de desenvolvimento formada por alunos e professores da USP que utiliza metodologias ágeis, prestaram uma assessoria à Assembléia Legislativa do Estado de São Paulo - ALESP. Iniciouse o desenvolvimento de um projeto para a área de Recursos Humanos. Por se tratar de um projeto de grande complexidade, com diversas especificações, foi preciso fazer antes uma minuciosa análise de requisitos. Ao invés de entender e documentar a lógica do negócio, o grupo optou por desenvolver este entendimento ao mesmo tempo em que capacitava a equipe, através de um treinamento intensivo. Depois de três meses de treinamento já se começava a notar os primeiros resultados, explicitados nas linhas de código iniciais. Após oito meses de assessoria, com o uso dos princípios da XP, o projeto foi entregue com resultados satisfatórios (AGILCOOP, 2007). No período de 2006, foi expandida a parceria com a ALESP: são mais membros da AgilCoop e alunos da USP implementando métodos ágeis na criação e manutenção do sistema de Recursos Humanos, do portal e do sistema de apoio ao legislativo. Este projeto conta com a participação de programadores experientes, dentre os quais Alfredo Goldman e Fabio Kon, professores doutores do departamento de ciência da computação da Universidade de São Paulo (AGILCOOP, 2007). Isso mostra que o desenvolvimento usando a XP demanda profissionais com considerável conhecimento em programação. 7. CONSIDERAÇÕES FINAIS O objetivo deste artigo não é apontar um método nem mostrar que um anula o outro, visto que suas características devem ser adotadas em situações de desenvolvimento diversas. É importante para o desenvolvedor conhecer o que há de melhor nos dois mundos e suas limitações a fim de que a adoção de um método possa atender suas expectativas de gerenciamento, custo e prazo. Para que surja interesse nas grandes organizações pela abordagem dos métodos ágeis muitas respostas ainda devem ser obtidas como por exemplo: como gerenciar o risco, como viabilizar a comunicação em locais dispersos, como garantir a certificação, dentre outras. Todo novo

11 11 paradigma exige um tempo de maturação, em que os pioneiros acreditam na idéia e quebram barreiras no intuito de adquirir a confiança do mercado. 8. REFERÊNCIAS AGILCOOP. Assembléia Legislativa do Estado de São Paulo: Assessoria e capacitação em desenvolvimento de software. Disponível em: < Acesso em: 18/03/07. BECK, K. et al. Manifesto for Agile Software Development Disponível em: < Acesso em: 15/03/07. BREWER, J. Extreme Programming FAQ. Disponível em: < Acesso em: 24/03/07. BROOKS, F. No Silver Bullet: Essence and Accidents of Software Engineering. Proc. IFIP, IEEE CS Press, pp ; reprinted in IEEE Computer, pp , Apr CAMPELO, R.E.C. XP-CMM2: Um Guia para Utilização de Extreme Programming em um Ambiente Nível 2 do CMM. Dissertação de Mestrado HIGHSMITH et al. Extreme Programming. E-Business Application Delivery, Feb., pp. 4-17, IBM. Rational Unified Process. Disponível em: < Acesso em: 16/03/07. KOHRELL, D.; WONCH, B. Using RUP to manage small projects and teams. Rational Software White Paper KRUCHTEN, Philippe. The Rational Unified Process An Introdution. Massachusetts, Addison Wesley, LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3. ed. Prentice Hall, MAGALHÃES, A.P.F. RUXP: Integrando o RUP e o XP em uma metodologia para o desenvolvimento de software. Monografia de Especialização MOLPECERES, A. Procesos de Desarollo: RUP, XP y FDD. Disponível em: < Acesso: 18/03/07. PIRES, C. G. et al. Uma Arquitetura de Processos para SW-CMM Nível 3 Baseada no RUP. Disponível em: <

12 12 Acesso em: 23/03/07. PRESSMAN, R. Engenharia de Software. McGraw-Hill, PROBASCO, L. The Ten Essentials of RUP: The Essence of an Effective Development Process. Rational Software White Paper RAWSTHORNE, D. Comparing/Combining RUP, XP and Scrum Disponível em: < Acesso em: 18/03/07. ROYCE, W.W. Managing the development of large software systems: concepts and techniques. Proc. IEEE Westcon, Los Angeles, CA. SMITH, J. A Comparison of the IBM Rational Unified Process and Extreme Programming. Rational Software White Paper SOARES, M. S. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. Revista Eletrônica de Sistemas de Informação, SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley XP. Extreme Programming. Disponível em: < Acesso em: 24/03/07.