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 histrico do processo de desenvolvimento de software e faz uma comparao entre a metodologia rigorosa Rational Unified Process (RUP) e a gil Extreme Programming (XP). Finalmente, so mostrados casos de sucesso das duas abordagens. PALAVRAS-CHAVE: Engenharia de Software, Metodologias Rigorosas, Metodologias geis, Extreme Programming, Rational Unified Process. ___________________________________________________________________________

1. INTRODUO O que se busca na Engenharia de Software o incessante melhoramento do processo de desenvolvimento de software. Os prazos e custos estipulados podem no chegar a serem alcanados, mesmo com a crescente evoluo da tecnologia, mtodos e recursos. Um dos principais motivos a excessiva formalidade nos modelos de processos colocados nos ltimos 30 anos (LARMAN, 2004). Existe ento a necessidade de desenvolver software de forma mais rpida, sem que se perca a qualidade. O novo paradigma em desenvolvimento de software que se pode obter esse resultado por meio da utilizao de mtodos geis. Embora as metodologias geis tenham sido apontadas como alternativa s abordagens tradicionais para o desenvolvimento de software, as metodologias tradicionais, conhecidas tambm como rigorosas, pesadas ou orientadas a planejamentos, possuem utilizao garantida no que diz respeito a situaes em que os requisitos do sistema so complexos e estveis e requisitos futuros so previsveis. 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, alm de citar casos de sucesso da aplicao de ambas. Na Seo 2, apresentado o histrico do processo de desenvolvimento de software, desde o uso restrito das metodologias tradicionais at a criao do Manifesto gil. Na Seo 3 e 4, so apresentados conceitos bsicos sobre os mtodos geis e tradicionais, respectivamente, alm de suas aplicaes. Na Seo 5, apresentado um comparativo entre o mtodo RUP e o XP e, na sesso 6, casos de sucesso relacionados a estas. Por fim, na Seo 7, esto as consideraes finais.

Albert Menezes Moreira graduando do curso de Bacharelado em Sistemas de Informao da Faculdade Ruy Barbosa e realizou este trabalho sob a orientao da professora Izabel Cristina Andion Castro, mestra em redes pela UNIFACS.

2. HISTRICO 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 modificaes fossem feitas era alto, devido s limitaes dos computadores e falta de ferramentas modernas para apoiar a criao do software, tais como depuradores e analisadores de cdigo. Sendo assim, o software era antes planejado e documentado para ento ser implementado. O modelo Clssico 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, ento, os mtodos geis, popularizados quando Beck et al. (2001) criaram o Manifesto gil indicando alguns princpios compartilhados por tais mtodos: a) b) c) d) Indivduos e interaes so mais importantes que processos e ferramentas; Software funcionando mais importante do que documentao detalhada; Colaborao dos clientes mais importante do que negociao de contratos; Adaptao s mudanas mais importante do que seguir um plano.

Nesta nova abordagem a reutilizao de software uma prtica comum durante o desenvolvimento. Os padres de projeto contribuem para o reuso em situaes em que preciso um nvel alto de abstrao, sobretudo na fase de anlise, na definio da arquitetura do sistema, em questes organizacionais e de otimizao dos processos, sendo que esses dois ltimos tm por objetivo apoiar a construo do software e melhorar o seu desenvolvimento. O uso de componentes outro aspecto possvel. Deste modo, a integrao dos padres organizacionais e de processo proporciona rapidez e qualidade no desenvolvimento.

3. METODOLOGIAS RIGOROSAS Essas metodologias so assim denominadas porque enfatizam o rigor nas premissas e propostas. Prezam pela documentao detalhada em todas as fases do desenvolvimento. Geralmente so implementadas em ambientes onde se deve exercer controle rgido, como por exemplo quando grande o nmero de indivduos que participam do projeto. Tambm so conhecidas como metodologias pesadas, uma referncia quantidade de documentos, papis, atividades e processos considerados necessrios para a implementao. O resultado disso que os desenvolvedores passam boa parte do tempo ocupados com atividades que no so necessariamente ligadas programao ou seu processo criativo. O modelo Clssico foi o primeiro processo de desenvolvimento de software publicado (PRESSMAN, 2001). um modelo que apresenta uma seqncia a ser seguida. Cada etapa tem uma documentao que precisa ser aprovada para que se d incio etapa seguinte. De uma forma geral fazem parte do modelo Clssico as etapas de definio de requisitos, projeto do software, implementao e teste unitrio, integrao e teste do sistema, operao e manuteno (SOMMERVILLE, 2003). A figura 1 mostra a disposio dessas fases, juntamente com a ordem de aplicao:

Figura 1: Fases do modelo Clssico Adaptado de: SOMMERVILLE, 2003

O problema deste modelo, tambm chamado de modelo em Cascata, a impossibilidade de criao de fases intermedirias ou at mesmo reviso de fases anteriores antes que o processo termine. Fred Brooks em seu artigo No Silver Bullet: Essence and Accidents of Software Engineering, sustenta essa idia na afirmao de que impossvel especificar totalmente um software antes da sua implementao (BROOKS, 1987). Isso dificulta alteraes, fator comum no desenvolvimento de um projeto. Sua utilizao feita quando os requisitos esto bem compreendidos. O modelo Clssico ainda perdurou at a dcada de 90 como forma de desenvolvimento e foi utilizado com sucesso quando os requisitos estavam bem compreendidos. 3.1. 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 tcnicas comerciais e objetivando o aumento da qualidade do produto gerado. classificado tambm 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 experincias e boas prticas adquiridas por diversas pessoas e empresas envolvidas com o desenvolvimento de softwares. Sua primeira verso, o RUP 5.0, surgiu em 1998, oriunda da evoluo de projetos anteriores, como o Rational Objectory Process, iniciado em 1996. Vrias caractersticas foram melhoradas e acrescentadas at a verso RUP 2000. A aplicao do RUP se d em variados projetos, sendo tratado como um arcabouo (framework) genrico para os processos de desenvolvimento, considerando a configurao adequada para o tamanho e a necessidade do projeto e os padres aplicados na empresa. Associada a este modelo, a Rational Software construiu tambm 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 utilizao do RUP.

Como bases para a criao deste mtodo foram adotadas algumas caractersticas de qualidade de software, que permitem atingir os objetivos desejados. Dentre elas, seis caractersticas merecem destaque especial: a) b) c) d) e) f) O uso de interaes com o cliente para desenvolvimento de softwares; Gerenciamento de requisitos; Utilizao de artefatos visuais, a exemplo de modelos UML; Controle de qualidade; Controle de mudanas; A necessidade da utilizao de uma metodologia de desenvolvimento de sistemas.

No modelo RUP, um projeto dividido diversas fases, desde a Modelagem do Negcio at o Ambiente. Estas ainda possuem outras 4 subdivises, que constituem o ciclo de construo de uma verso, como mostrado na figura 2:

Figura 2: Ciclo de construo de uma verso usando RUP Adaptado de: KRUCHTEN, 2000

A fase de Concepo, Inception phase, onde deve ser definido o escopo da verso, especificando o produto a ser gerado. nessa etapa que se avaliar a viabilidade do projeto, pois neste momento os requisitos operacionais e os critrios de aceitao sero apresentados. Devem ser levantados os riscos que possam comprometer o andamento do projeto, levando em considerao questes de arquitetura. pertinente tambm a aplicao de um cronograma preliminar. Dentre os produtos finais desta fase esto o cronograma, o diagrama de caso de uso inicial, o caso de uso do negcio, que quando aplicado em sistemas comerciais deve fornecer uma estimativa de retorno do investimento e o prottipo preliminar (MAGALHES, 2003). O objetivo da fase de Elaborao, Elaboration Phase, analisar o domnio do problema, criar o plano de projeto, a arquitetura e remover os elementos de alto risco. Tratam-se de riscos de requerimentos, tecnolgicos em relao capacidade das ferramentas disponveis, de habilidades dos integrantes do projeto e polticos (RUP, 2007). uma etapa crtica, pois o que for definido nesta fase ser utilizado como base para as prximas e medida que o projeto avana aumenta o custo de modificaes.

A fase de Construo, Construction phase, consiste no desenvolvimento do produto. a etapa de construo do cdigo, com nfase no gerenciamento de recursos e controle das operaes, adotando medida de reduo dos custos. Nesta fase, os componentes gerados so tambm testados e submetidos aos critrios de aceitao que foram definidos na fase anterior. Ao fim desta fase, o produto estar pronto para ser entregue ao usurio, integrado s plataformas necessrias, com manual de usurios e uma descrio sobre esta verso (MAGALHES, 2003). Na fase final do processo que chamada de Transio, Transition phase, o produto ser entregue. Engloba tambm os procedimentos de treinamento, suporte e manuteno. Esta fase inclui os testes finais de aceitao, no intuito de captar o feedback do usurio a respeito dos resultados, alm de comparaes com outros sistemas antigos, converses de banco de dados (se for o caso) e a divulgao do novo produto. As interaes mostradas na figura 2 evidenciam o compromisso do RUP com o desenvolvimento incremental, que construir o cdigo e fazer os testes com componentes do sistema, gerando releases a cada fase. No fim da fase de elaborao, o prottipo da arquitetura est disponvel para avaliao. Durante cada iterao da fase de construo, componentes terminados so integrados ao projeto. O ponto chave para este elemento um conjunto de testes que acompanham a construo do produto (PROBASCO, 2000). O RUP permite a diviso do projeto em partes que sero desenvolvidas atravs de iteraes, ou seja, repetio de todo o ciclo para cada uma das partes que sero integradas e incrementadas at o produto final. O RUP tambm pode ser utilizado no desenvolvimento e manuteno de projetos de pequeno ou de mdio porte. Para que isso seja possvel, alguns etapas ou passos podem ser eliminados a depender das caractersticas do projeto para simplificar ou diminuir as necessidades de documentao, minimizando a formalizao (KOHRELL e WONCH ,2005). As diferentes configuraes do RUP possibilitam o suporte de equipes grandes e pequenas, alm de tcnicas de desenvolvimento disciplinadas ou menos formais (KRUCHTEN, 2000).

Vale ressaltar que existe a coerncia do modelo de processos RUP com os requisitos para certificao 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 nvel do CMM, o conceito de processo fortemente introduzido na organizao. A arquitetura implantada do CMM nvel 3 servir como base para a execuo das prticas de todas as reas chave. Essa arquitetura torna-se, ento, pea fundamental para a organizao dos processos e sucesso do projeto. Com a adoo do RUP uma empresa j possui os prrequisitos para passar para o nvel 3 do CMM (PIRES et al., 2007).

4. METODOLOGIAS GEIS Como foi apresentado no segundo captulo, 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 mtodos. Foi ento criada por BECK et al. (2007) a Aliana gil e instaurado o Manifesto gil.

O objetivo do Manifesto gil no desconsiderar processos, ferramentas, documentao, negociao de contratos ou planejamento, mas mostrar o valor secundrio que estes possuem diante dos indivduos e interaes, do bom funcionamento do software, da colaborao do cliente e das respostas velozes s modificaes. Esses conceitos esto mais relacionados forma que as pequenas e mdias empresas trabalham, devido a estarem habituadas a mudanas. A mais conhecida dentre as metodologias geis a Extreme Programming. 4.1. Extreme Programming A Extreme Programming - XP - uma metodologia gil voltada s equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se alteram com rapidez (BECK, 1999). As principais diferenas da XP em relao s outras metodologias so feedback constante e abordagem incremental. A figura 3 mostra algumas das caractersticas da Extreme Programming:

Figura 3: Caractersticas da XP Adaptado de: XP, 2007

Nesta prtica, interessante que haja comunicao entre os indivduos. 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 satisfatrios em pouco mais de um ano. (HIGHSMITH et al., 2000). Grande parte das regras aplicadas metodologia XP podem no fazer sentido primeira vista, no entanto o diferencial so as partes que se complementam, o conjunto. A preocupao maior com o rpido de desenvolvimento e satisfao do cliente, cumprindo as estimativas de tempo e custo. Os valores aplicados na Extreme Programming oferecem um ambiente propcio para o progresso no trabalho. De acordo com definies da metodologia XP (2007), seus principais valores so: comunicao, simplicidade, feedback e coragem. O objetivo da comunicao criar e manter o melhor relacionamento possvel entre cliente e provedor de servios, dando preferncia, neste caso, a conversas pessoais do que atravs de outros meios. encorajada tambm a comunicao entre desenvolvedores e gerente do

projeto. Este se caracteriza como um dos fatores principais na XP: conversar ao mximo pessoalmente, evitando o uso do telefone e mensagens de email. A simplicidade visa a minimizar do cdigo, desprezando funes consideradas desnecessrias ou no essenciais. Isto quer dizer que deve ser implementado o menor nmero de classes e mtodos. Deve-se tambm estar sempre procurando atender os requisitos emergenciais, evitando adicionar funcionalidades ligadas evoluo do produto. O importante ter em mente que os requisitos so mutveis. Sendo assim, o interessante na prtica da Extreme Programming implementar apenas que estritamente necessrio. O contato incessante com o cliente a respeito do projeto o que se pode chamar de feedback constante. Informaes sobre o cdigo so dadas por testes peridicos, os quais indicam erros tanto individuais quanto do software integrado. Alm disso, o cliente ter sempre uma parte do software funcional para avaliar. Com isso, novas caractersticas e informaes so repassadas aos desenvolvedores, que por sua vez devem implement-las nas prximas verses. Desta maneira, o que se pretende entregar o software de acordo com as expectativas do cliente. A coragem se encaixa na implantao dos trs valores anteriores. So necessrios 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 necessria para garantir que o feedback do cliente ocorra com freqncia, pois esta abordagem implicar na possibilidade de mudanas constantes do produto. A orientao para o perfil das equipes no XP de programadores experientes, j que necessria a boa utilizao do tempo de desenvolvimento do projeto. No que diz respeito certificao CMM, a metodologia XP no possui os pr-requisitos necessrios para sua implementao.

5. COMPARATIVO ENTRE RUP E XP E SUAS APLICAES No que diz respeito ao quesito tempo, provvel que o que gasto pelas verses usando XP coincida com as iteraes do RUP. Tal ocorrncia no se aplica a projetos grandes, por se caracterizarem pela grande durao de suas iteraes. Em projetos maiores, as equipes no RUP so geralmente divididas para se desenvolver paralelamente, cada uma com um subsistema. Embora a XP aplique a programao em duplas, o projeto tratado como um todo, no em subsistemas. Na viso de Kruchten (2000), artefato uma parte de uma informao produzida, modificada ou usada por um processo. So exemplos de artefato modelos, documentao, cdigo fonte e arquivos executveis. No Rational Unified Process, a comunicao feia por meio de artefatos. A XP baseada em comunicao 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 estrias de usurio e cdigo, o risco de projeto pode aumentar. Neste momento, a confiana recproca um fator vital. Acerca das atividades e dos papis dentro do desenvolvimento do projeto, o RUP divide as tarefas de forma especfica, ao passo que a diviso da XP no distingue funes especficas dentro das atividades. Isto quer dizer que o programador de um projeto que adote a Extreme

Programming no est necessariamente preso a determinada atividade, podendo se encaixar em outra, caso seja necessrio. O RUP especifica a utiliza softwares da IBM, como o Rational Rose, embora j existam vrias ferramentas que podem ser utilizadas. Por outro lado, a XP no especifica uma ferramenta para o processo, ainda que possa utilizar ferramentas livres como o Junit e o XPlanner (XP, 2007). Para tratar o cdigo, o Rational Unified Process o subdivide em subsistemas (quando se trata de um sistema grande), delegando tambm membros responsveis para cuidar de cada uma das partes (IBM, 2007). O XP trata o cdigo coletivamente, permitindo que qualquer programador modifique o cdigo caso encontre algum problema ou soluo de otimizao. Para garantir a veracidade do conhecimento nas metodologias, existem as certificaes, que tm como finalidade atestar publicamente e por escrito que o produto, servio, sistema, ou neste caso, o indivduo, 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 certificao base desta metodologia (IBM, 2007). Por outro lado, de acordo com Brewer (2007), no existe entidade certificadora para a Extreme Programming, no havendo, ento, um teste para abordar conhecimentos desta metodologia. A tabela 1 apresenta algumas caractersticas presentes nas metodologias RUP e XP:
Tabela 1: Comparativo entre RUP e XP. Adaptado de: RAWSTHORNE, 2007

Prtica ou conceito Iterativo e incremental Voltado para a arquitetura Voltado para a validao Interao desenvolvedor/cliente Interao desenvolvedor/gerente Interao desenvolvedor/suporte Gerenciamento de risco Qualidade de cdigo Gerenciamento dos pontos-chave Equipes grandes Equipes pequenas Projetos complexos Casos de uso

RUP SIM SIM NO NO SIM SIM SIM NO SIM SIM NO SIM SIM

XP SIM NO SIM SIM NO SIM SIM SIM NO NO SIM NO SIM

De acordo com as comparaes da tabela 1, pode-se concluir que ambas as abordagens tm pontos fortes e fracos (MOLPECERES, 2007). Enquanto o foco do Rational Unified

Programming so projetos complexos, onde so necessrias especificaes 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 anlise de riscos, sem que isso as tornem metodologias pesadas. No est no escopo da Extreme Programming a preocupao formal com o planejamento de riscos. Visto que riscos acontecem com freqncia em projetos desenvolvimento de software, a falta de anlise de risco torna-se um fator negativo (SOARES, 2004). Outro aspecto que para tornar as metodologias geis solues para grandes empresas e equipes, visto que nestas empresas cada vez mais os indivduos que participam de equipes se encontram dispersos geograficamente ser importante resolver os problemas de comunicao.

6. CASOS DE SUCESSO Os tpicos abaixo apresentam dois casos de sucesso. O primeiro deles do sistema de desenvolvimento para negcio da empresa Ford Moto Credit, usando o RUP. O segundo do sistema de apoio a RH, na Assemblia Legislativa do Estado de So Paulo, desenvolvido pelos membros da AgilCoop - formada por professores e alunos da USP - usando a XP. 6.1. A empresa Ford Motor Credit padroniza metodologia de desenvolvimento usando IBM Rational Unified Process Ford Motor Credit uma das maiores empresas de financiamento de automveis do mundo, com operaes em 36 pases. 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 prpria, dificultando o compartilhamento de conhecimento e rodzio entre as equipes. Alm 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 soluo a companhia adotou o Rational Unified Process, personalizando para as necessidades especficas. O departamento de TI tambm 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 vis similar ao de outras empresas, o RUP foi customizado de acordo com as necessidades especficas. A equipe utilizou a metodologia RUP com gerentes de projetos, times de servio 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 Solues Unificada - Unified Solution Delivery Methodology (USDM), para seus projetos de software. Para viabilizar a adoo da USDM, a qual baseada na abordagem iterativa caracterstica 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 experincia com um ou dois projetos com a ajuda dos

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 estvel, dando mais prioridade entrega das funcionalidades crticas. Com isso, o departamento de TI da Ford Motor Credit passou a identificar e enderear os riscos de projeto com mais rapidez no processo de desenvolvimento e as equipes passaram a entregar as solues a tempo e atingir os padres de qualidade. 6.2. Assemblia Legislativa do Estado de So Paulo: Assessoria e capacitao 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 Assemblia Legislativa do Estado de So 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 especificaes, foi preciso fazer antes uma minuciosa anlise de requisitos. Ao invs de entender e documentar a lgica do negcio, o grupo optou por desenvolver este entendimento ao mesmo tempo em que capacitava a equipe, atravs de um treinamento intensivo. Depois de trs meses de treinamento j se comeava a notar os primeiros resultados, explicitados nas linhas de cdigo iniciais. Aps oito meses de assessoria, com o uso dos princpios da XP, o projeto foi entregue com resultados satisfatrios (AGILCOOP, 2007). No perodo de 2006, foi expandida a parceria com a ALESP: so mais membros da AgilCoop e alunos da USP implementando mtodos geis na criao e manuteno do sistema de Recursos Humanos, do portal e do sistema de apoio ao legislativo. Este projeto conta com a participao de programadores experientes, dentre os quais Alfredo Goldman e Fabio Kon, professores doutores do departamento de cincia da computao da Universidade de So Paulo (AGILCOOP, 2007). Isso mostra que o desenvolvimento usando a XP demanda profissionais com considervel conhecimento em programao.

7. CONSIDERAES FINAIS O objetivo deste artigo no apontar um mtodo nem mostrar que um anula o outro, visto que suas caractersticas devem ser adotadas em situaes de desenvolvimento diversas. importante para o desenvolvedor conhecer o que h de melhor nos dois mundos e suas limitaes a fim de que a adoo de um mtodo possa atender suas expectativas de gerenciamento, custo e prazo. Para que surja interesse nas grandes organizaes pela abordagem dos mtodos geis muitas respostas ainda devem ser obtidas como por exemplo: como gerenciar o risco, como viabilizar a comunicao em locais dispersos, como garantir a certificao, dentre outras. Todo novo

11

paradigma exige um tempo de maturao, em que os pioneiros acreditam na idia e quebram barreiras no intuito de adquirir a confiana do mercado.

8. REFERNCIAS AGILCOOP. Assemblia Legislativa do Estado de So Paulo: Assessoria e capacitao em desenvolvimento de software. Disponvel em: <http://agilcoop.incubadora.fapesp.br/portal/sucessos/alesp/> Acesso em: 18/03/07. BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponvel em: <http://www.agilemanifesto.org/> Acesso em: 15/03/07. BREWER, J. Extreme Programming FAQ. Disponvel em: <http://www.jera.com/techinfo/xpfaq.html> Acesso em: 24/03/07. BROOKS, F. No Silver Bullet: Essence and Accidents of Software Engineering. Proc. IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19, Apr. 1987. CAMPELO, R.E.C. XP-CMM2: Um Guia para Utilizao de Extreme Programming em um Ambiente Nvel 2 do CMM. Dissertao de Mestrado. 2003. HIGHSMITH et al. Extreme Programming. E-Business Application Delivery, Feb., pp. 4-17, 2000. IBM. Rational Unified Process. Disponvel em: <http://www-306.ibm.com/software/awdtools/rup/> Acesso em: 16/03/07. KOHRELL, D.; WONCH, B. Using RUP to manage small projects and teams. Rational Software White Paper. 2005. KRUCHTEN, Philippe. The Rational Unified Process An Introdution. Massachusetts, Addison Wesley, 2000. LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3. ed. Prentice Hall, 2004. MAGALHES, A.P.F. RUXP: Integrando o RUP e o XP em uma metodologia para o desenvolvimento de software. Monografia de Especializao. 2003. MOLPECERES, A. Procesos de Desarollo: RUP, XP y FDD. Disponvel em: <www.javahispano.org/licencias/> Acesso: 18/03/07. PIRES, C. G. et al. Uma Arquitetura de Processos para SW-CMM Nvel 3 Baseada no RUP. Disponvel em: <http://www.sbc.org.br/bibliotecadigital/download.php?paper=232>

12

Acesso em: 23/03/07. PRESSMAN, R. Engenharia de Software. McGraw-Hill, 2001. PROBASCO, L. The Ten Essentials of RUP: The Essence of an Effective Development Process. Rational Software White Paper. 2000. RAWSTHORNE, D. Comparing/Combining RUP, XP and Scrum Disponvel em: <www.netobjectives.com> 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. 2003. SOARES, M. S. Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software. Revista Eletrnica de Sistemas de Informao, 2004. SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley. 2003. XP. Extreme Programming. Disponvel em: <http://www.extremeprogramming.org/> Acesso em: 24/03/07.