Uma Comparao de R UP e X P

John Smith
Rational Software White Paper
TP 167, 5/01

ndice Analtico

Introduction............................................................................................................................................................................... 1 Time and Effort Allocation....................................................................................................................................................... 2 Examples of projects amenable to XP..................................................................................................................................... 3 A large system development not suitable for XP..................................................................................................................... 3 What do RUPs phases map to in XP? .................................................................................................................................... 4 What do XPs phases map to in RUP? .................................................................................................................................... 6 Artifacts ..................................................................................................................................................................................... 9 Why doesnt XP need all of the RUP artifacts? .................................................................................................................... 11 Comparing artifacts for a small project ................................................................................................................................. 11 Guidelines ............................................................................................................................................................................. 14 Tasks......................................................................................................................................................................................... 15 Is there an XP equivalent of RUPs tasks? ............................................................................................................................ 15 Disciplines ................................................................................................................................................................................ 17 Use of XP practices in RUP .................................................................................................................................................. 19 XP practices that do not scale ............................................................................................................................................... 21 Roles ......................................................................................................................................................................................... 23 RUP roles .............................................................................................................................................................................. 23 XP roles................................................................................................................................................................................. 23 Conclusions .............................................................................................................................................................................. 25 References ................................................................................................................................................................................ 26
Deleted: 2

Deleted: 5

Deleted: 13 Deleted: 14 Deleted: 14 Deleted: 16 Deleted: 17 Deleted: 18 Deleted: 20 Deleted: 20 Deleted: 20 Deleted: 22 Deleted: 23

Uma Comparao de RUP e XP

Introduo
Este documento compara o RUP (Rational Unified Process), uma estrutura de processo refinada durante anos pela Rational Software, que est sendo amplamente utilizada em vrios projetos de software, de pequenos a grandes, com o XP (Extreme Programming), uma abordagem de desenvolvimento de software que est ganhando cada vez mais reconhecimento como um mtodo efetivo para construir sistemas menores em um ambiente de requisitos de alterao. A comparao direcionada para a natureza e o estilo de cada um como uma descrio de processo e sua estrutura, premissas e apresentao subjacentes. Este documento tambm examina quais so os destinos potenciais para cada um e as conseqncias de seu uso. A maioria dos processos tm alguns elementos em comum que tornam possvel uma comparao sistemtica. Eles requerem seqncias ou grupos de tarefas, que so executadas por funes (normalmente por pessoas que trabalham como indivduos ou equipes) para gerar artefatos ou produtos de trabalho, dos quais alguns ou todos so entregues a um cliente. A maioria dos processos tambm reconhece que as instncias dos processos tero uma dimenso de tempo, com um incio e fim, e marcos intermedirios interessantes que representam a concluso de atividades significativas (ou clusters de atividades) e a produo de artefatos associados. Conseqentemente, este documento explora as seguintes dimenses de processo e as utiliza para fazer a comparao: Alocao de Tempo e Esforos discute como cada processo organizado com o tempo e como a alocao de esforos da equipe comparado. Artefatos compara os produtos de trabalho; aquelas coisas produzidas no curso de um projeto baseado no XP e RUP. Tarefas discute a forma na qual processo informa que seus artefatos devem ser produzidos. Disciplinas compara a forma na qual o XP e o RUP delineiam as principais reas de preocupao na engenharia de software. Funes explora as diferenas entre funes (que executam tarefas) no RUP e funes que esto prximas de posies dentro de uma equipe no XP.

A motivao para esse documento esclarecer as posies relativas do RUP e do XP no espectro do processo para ver o que cada um pode oferecer ao outro e espalhar a noo de que o XP uma alternativa leve e, portanto, desejvel em relao ao RUP pesado. As principais fontes de informaes sobre o XP utilizadas ao escrever este documento foram trs livros na Addison-Wesley XP Series: Extreme Programming Explained [Beck00] Extreme Programming Installed [Jeffries01] Planning Extreme Programming [Beck01]

Esses livros foram escolhidos porque eles so os repositrios mais bvios de informaes sobre o XP e muitos leitores interessados ou usurios potenciais do XP comearo com eles. Outros livros foram planejados, mas estavam indisponveis no momento em que este documento foi escrito. A fonte de informaes sobre o RUP o prprio produto RUP da Rational Software Corporation. Este documento no pretende ser um tutorial sobre o XP ou o RUP, portanto, ele ser mais facilmente lido por aqueles que j tm algum conhecimento dessas abordagens ou tm acesso a algum material de referncia; por exemplo, [Beck00] no caso do XP e [Kruchten00] no caso do RUP.

Uma Comparao de RUP e XP

Alocao de Tempo e Esforos

O RUP lida com projetos (para desenvolver software), do qual o tempo de vida dividido em fases denominadas Iniciao, Elaborao, Construo e Transio. Cada fase adicionalmente dividida em iteraes e cada iterao pode requerer vrias construes. Para a maioria dos projetos no RUP, a durao de uma iterao estar entre duas semanas e seis meses1e o nmero de iteraes na existncia de um projeto ser entre trs e nove. Portanto, nessas definies padro, o RUP abrange projetos que variam de durao de seis semanas a 54 meses. As iteraes do XP tm cerca de duas semanas de durao. Os releases do XP so de dois meses (ou um pouco mais); eles so definidos pelo cliente e liberados para o cliente. Na durao, os releases do XP so como iteraes do RUP durante a Elaborao ou Construo2 pelo menos, para projetos que so apropriados para o XP; ou seja, para aqueles com um tamanho mximo de equipe de, digamos, 103, que esto baseados em uma linha de base arquitetural estabelecida.4 Para mostrar isso, vamos assumir um tamanho mximo de equipe XP de 10, descobrir o projeto com o tamanho mximo que razovel para tal equipe e, ento, ver como o RUP manipular os projetos desse tamanho e menores. Se utilizarmos COCOMO II5 como nosso modelo de estimativa, ele prev que uma equipe de 10 est normalmente associada a um projeto que tem uma durao mxima de 15 meses. Um projeto que dura mais de 15 meses normalmente empregar uma equipe maior que 10. Voc poderia construir sistemas grandes com apenas 10 pessoas se estivesse preparado para dar a eles um planejamento mais longo, contudo, um projeto importante o suficiente que voc planejar a incluso de mais equipe se puder faz-lo efetivamente. Este projeto de exemplo fornecer cerca de 40.000 a 50.000 linhas de origem de cdigo (slocs) (800-1000 pontos de funo6 em Java) a partir do zero. De acordo com o modelo, este o projeto maior que voc deve tentar com uma equipe com tamanho para XP se desejar que ele seja feito rapidamente. Alm disso, talvez haja outras razes para uma equipe pequena no poder construir efetivamente um sistema grande; por exemplo, devido perda de familiaridade com o cdigo j construdo. (O que uma equipe grande pode fazer em paralelo, uma equipe pequena ter de fazer em srie. Portanto, quando chega a hora do teste de integrao e depurao, a equipe pequena ter de revisitar o cdigo que escreveu consideravelmente antes.) Se olharmos um conjunto de projetos sob este tamanho, veremos um mapeamento razovel entre releases do XP e iteraes do RUP. Os seguintes exemplos ilustram como eles podero ser planejados no RUP. Os nmeros so apenas indicativos, mas so razoveis para projetos desses tamanhos. Eles incluem esforo e tempo para a preparao de todos os artefatos requeridos do RUP que so distribuveis, alm do cdigo, como guias do usurio, informaes de instalao e operao e assim por diante.

1 2

A durao esperada de uma iterao em um desenvolvimento de e-business pode ser mais curta mais provavelmente na faixa de duas a seis semanas.

As iteraes durante a Iniciao so normalmente mais curtas. Observe tambm que o modelo de fase para o RUP acomoda um grande intervalo de shapes, para que em uma fase de longa transio voc possa encarar uma seqncia de iteraes, cada uma culminando em uma entrega de software para o cliente, tambm em intervalos de dois meses, mas a entrada na transio significa que a arquitetura est completamente estvel e as alteraes contempladas so amplamente adaptativas, perfectivas e corretivas. Consulte [Beck00], que informa que voc provavelmente no poder executar um projeto XP com 20 programadores, mas que 10 seguramente vivel.

3 4

O XP est intensamente focado na entrega de valor de negcios direto ao cliente, principalmente como uma funo. O XP fornece pouca considerao direta arquitetura, permitindo que isso surja sobre uma srie de recriaes do software, conforme funes so includas. Se a arquitetura da soluo ainda no estiver bem estabelecida, h um risco de que isso leve a uma srie de interrupes, conforme as funes so includas, que invalidam as premissas anteriores (e solues especiais) e criam problemas que no so tratveis na recriao local. O COCOMO II um retrabalho do modelo clssico de estimativa de software COCOMO originalmente desenvolvido pelo Dr. Barry Boehm. Ele calibrado para projetos pequenos de 2.000 slocs. Consulte [Boehm00]. Os pontos de funo so uma medida independente de cdigo fonte do tamanho do software, obtida pela quantificao da funcionalidade fornecida ao usurio, baseada apenas no design lgico e nas especificaes funcionais. Essa definio foi obtida do Web site International Function Point Users Group em [Link]

Field Code Changed

Uma Comparao de RUP e XP

Exemplos de Projetos Tratveis pelo XP O Exemplo 1 ilustra um projeto muito pequeno consistindo em 5.000 linhas de novo cdigo Java, requerendo cerca de 12 pessoas-meses no tempo decorrido de 7 meses.7
Exemplo 1 Iniciao Elaborao Construo Transio

Equipe Durao em semanas Nmero de iteraes (e durao de cada uma em semanas)

1 3 1 (3)

1,5 6 1 (6)

2 18 3 (6)

2 3 1 (3)

O Exemplo 2 examina um projeto pequeno de 10.000 linhas de novo cdigo Java, requerendo cerca de 27 pessoas-meses no tempo decorrido de 8 meses.
Exemplo 2 Iniciao Elaborao Construo Transio

Equipe Durao em semanas Nmero de iteraes (e durao de cada uma em semanas)

1,5 4 1 (4)

2,5 7 1 (7)

4 20 3 (7)

3 4 1 (4)

O Exemplo 3 ilustra um projeto mdio de 40.000 linhas de novo cdigo Java, requerendo cerca de 115 pessoas-meses no tempo decorrido de 15 meses.
Exemplo 3 Iniciao Elaborao Construo Transio

Equipe Durao em semanas Nmero de iteraes (e durao de cada uma em semanas)

3 6 1 (6)

5 16 2 (8)

10 36 4 (9)

8 6 1 (6)

Dentro desses limites (que abrangem inteiramente uma amplitude de desenvolvimento), as iteraes do RUP so mapeadas muito proximamente com os releases do XP, na inteno e na durao. Desenvolvimento de um Sistema Grande No Adequado para o XP Em desenvolvimentos muito grandesque o RUP manipular, mas o XP no,as iteraes do RUP so muito mais longas. O Exemplo 4 mostra um projeto de 1.500.000 linhas de novo cdigo Java, requerendo 4.600 equipe-meses no tempo decorrido de 45 meses.8

Isso pode parecer muito longo, mas observe que abrange o ciclo de vida inteiro, de um incio estabelecido, com essencialmente nenhuma equipe e nenhum requisito definido (apenas a origem de uma idia), para aceitao e encerramento do projeto. tambm uma sada do modelo COCOMO II, que permite mais compactao do planejamento, mas com a penalidade de maior custo e risco. No entanto, de acordo com o planejamento na tabela, algo com funcionalidade til poderia estar disponvel logo no incio de trs meses e meio aps o incio do projeto (no final da primeira iterao de construo).

Voc poder argumentar que nunca deve caracterizar um projeto dessa forma: que um projeto desse tamanho deve ser dividido em projetos menores (cada um poderia ser tratado pelo XP). claro que projetos desse tamanho so construdos como sistemas de subsistemas (ou para projetos extremamente grandes como sistemas de sistemas), mas quando esses subsistemas ou sistemas precisam ser integrados em um nico produto, ento, voc precisar se preocupar sobre a arquitetura e, em particular, sobre interfaces entre agregados do software e as equipes que o produzem. O XP em sua forma atual no lida com esses problemas.

Uma Comparao de RUP e XP

Exemplo 4 Iniciao Elaborao Construo Transio

Equipe Durao em semanas Nmero de iteraes (e durao de cada uma em semanas)

35 20 2 (10)

70 50 2 (25)

140 100 3 (33)

100 20 2 (10)

Claramente, neste exemplo a equipe no organizada como uma equipe individual, monolticao projeto composto de vrias equipes, cada uma trabalhando em subsistemas, que podero ser compostos de subsistemas de forma que, em nveis mais baixos, haver planejamento em uma escala similar quela para um projeto com tamanho tratvel pelo XP. No entanto, esse projeto tem como objetivo representar um sistema integrado de forma que, no nvel superior, o planejamento seja requerido para iteraes em uma escala (33 semanas) que est bem alm dos preceitos do XP. Essas iteraes tm essa durao devido inrcia de planejamento de um projeto integrado desse tamanho. O planejamento de iteraes dentro do RUP feito atravs de planos de integrao da construo (que podem existir nos nveis do sistema e do subsistema) e eles sero construdos em uma escala mais prxima aos releases do XP (para esse sistema muito grande) e no nvel mais inferior em uma escala prxima s iteraes do XP (que devem estar disponveis em duas semanas) particularmente na elaborao e construo tardias. Portanto, retornando aos exemplos de sistemas menores, as iteraes do RUP so mais ou menos equivalentes aos releases do XP e as construes do RUP so mais ou menos equivalentes s iteraes do XP. O Que as Fases do RUP Mapeiam no XP? Bem, pelo menos primeira vista, as fases do RUP so mapeadas para aspectos do ciclo do XP que no so bem delineados. O XP parece estar construdo, ou pelo menos descrito, para ajustar-se a uma esfera fixa de releases (harmonizando com um ciclo de negcios) que contm iteraes. H o reconhecimento de que h um projeto de determinado tipo que deve ser iniciado (consulte Fazendo o Escopo de um Projeto em [Beck01]) e que o grande plano construdo no momento ser ento dividido em releases, que, por sua vez, sero divididos em iteraes. [Beck01] informa que uma coisa que o grande plano fez foi nos ajudar a decidir que no era bobagem investir no projeto. Portanto, h um momento no XP antes do ciclo de releases e iteraes iniciar, no qual o trabalho est ocorrendo em um projeto para decidir se ele vivel e quanto custar e, para fazer isso, alguma idia grosseira da funcionalidade requerida precisa ser construda. Isso o que o RUP chama de fase de iniciao. Voc tem a impresso no XP que ela deve ser feita rapidamente, muito rapidamente. No RUP, dizemos que ela leva o tempo que for necessriodependendo dos riscos inerentes. Mesmo no XP, voc l sobre as seguintes coisas que precisam ser feitas neste momento (por um pequeno nmero de pessoas): levantamento de alguns requisitos (escrever algumas estrias importantes); algum planejamento; alguma negociao com o cliente (definindo expectativas); recriao em qualquer restrio de negcios.

fcil ver que levar alguns dias para ir de um incio despreparado at ter uma Viso (isso como as estrias importantes so chamadas no RUP) e um Caso de Negcios (oramento e ROI (Retorno do Investimento) que justifique o projeto) e obter um primeiro corte no Plano de Desenvolvimento de Software. No RUP, como no XP, voc faz exploraes e planejamentos suficientes no incio do projeto para dar continuidade aps estabelecer que h uma boa probabilidade de sucesso. Conforme mostrado anteriormente no Exemplo 2, o planejamento do RUP sugere um investimento (em esforo) de cerca de $12.000 dlares em iniciao para justificar o gasto de cerca de $250.000 dlares. Isso ir variar; em algumas reas de problema bem dominadas, voc no precisar fazer muito; por exemplo, talvez voc no esteja iniciando do zero. Em outras ocasies, voc precisar gastar mais iniciando do zero em um domnio no-familiar que requer algum grau de pesquisa e desenvolvimento. Depois de sua fase equivalente iniciao, o XP vai direto para o planejamento do primeiro release. O RUP informa que a fase de elaborao segue a iniciao e nas iteraes de elaborao, a arquitetura da soluo estabilizada. Em comparao

Uma Comparao de RUP e XP

aparente, o XP sugere que o planejamento de release seja orientado por funo para que todos os releases entreguem o valor de negcio para o cliente. O XP bastante explcito em seu desdm para o que ele chama de planejamento de infra-estrutura: apenas o suficiente deve ser feito para suportar a funcionalidade selecionada para esse release. A infra-estrutura includa mais tardiamente que o requerido e, se o sistema for interrompido devido a decises de infra-estrutura antecipadas serem invalidadas por incluses tardias de funo, ento, o cdigo ser recriado para faz-lo funcionar.9 A idia no gastar muito tempo construindo algo que no entrega valor para o cliente. Em comparao, alguns pontos precisam ser destacados sobre o RUP: O conceito de arquitetura do RUP no simplesmente infra-estrutura Para citar a partir do RUP, a arquitetura de um sistema de software (em um determinado ponto) a organizao ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com componentes constitudos de componentes e interfaces sucessivamente menores. Portanto, a arquitetura enfoca a soluo completano apenas a infra-estruturade um conjunto especfico de perspectivas, em um nvel adequado de abstrao. A noo do RUP de arquitetura executvel entrega o valor de negcios para o cliente Ela permite a demonstrao precoce de uma soluo que satisfaz os requisitos no funcionais do cliente (bem como, potencialmente, alguns funcionais no processo). A reduo de risco dessa formae, freqentemente, os requisitos no funcionais so os que apresentam risco representa em si um valor de negcios considervel para o cliente. Por que acreditar que necessrio descrever o processo dessa maneira? Como o RUP est por toda a parte conduzindo riscos e acreditamos que haja classes de problemas e sistemas que so simplesmente no tratveis para a abordagem do XP em permitir que a arquitetura surja da recriao de cdigonormalmente maiores e mais complexos. Um risco que em fazer alteraes locais na recriao (e o escopo ficar, por necessidade, limitado), sero produzidas otimizaes locais que, no agregado, levaro a uma soluo muito menos favorvel. Isso no apenas nossa assero: Kent Beck diz muito sobre si mesmo em [Beck00], no captulo intitulado Four Values, no ttulo Courage. A dificuldade que o XP informa pouco sobre a origem da inspirao para alteraes arquiteturalmente significativasapenas que preciso ter coragem10 para aplic-las! Ento, existem alteraes que so difceis de recriar. Por exemplo, para tornar um sistema com um nico usurio e uma nica mquina um sistema multiusurio e multiprocessador, voc precisar reprojetar vrias coisas e ainda acabar com um sistema que tem muitas restries. A nfase do RUP na arquitetura tem como objetivo enfocar aqueles casos nos quais a abordagem inicial pode estar errada e precisa ser completamente reconsiderada. Para sistemas menores, isso menos que um riscoa recriao pode fazer uma limpeza mais ampla no sistema e h muito menos probabilidade de que a arquitetura inicial estivesse incorreta. Observe tambm que onde h menos risco percebido (devido ao tamanho, nova tecnologia, falta de familiaridade, complexidade, outras exigncias de desempenho, confiabilidade, segurana e assim por diante) e a soluo pode ser entregue em uma estrutura existente bem entendida, ento, a fase de elaborao do RUP (a fase na qual problemas arquiteturais so manipulados) poder ser bem breve (e preocupar-se mais com o levantamento, refinamento e demonstrao de requisitos funcionais importantes). Ou seja, o ciclo de vida do RUP reduzido visando algo que se aproxime a um ciclo de vida do XP. Quando um problema puder ser enfocado com xito pelo XP, o Caso de Desenvolvimento do RUP tambm produzir algo similarmente leve (embora no exatamente o mesmo). A fase de construo no RUP equivalente srie de releases do XP com a qualificao que, se voc estivesse seguindo o RUP, teria de entregar os resultados de cada iterao de construo ao cliente para ter o mesmo efeito do XP. O XP no tem realmente um equivalente da fase de transio do RUP, porque cada release do XP j est nas mos do cliente. H, no final de

9 Observe que a recriao apenas resulta em aprimoramentos locais: a recriao no enfoca a estrutura global. Se a estrutura global estiver resolvendo o problema errado, ento, a recriao no produzir uma soluo correta. A nica soluo fazer alteraes radicais ou, em casos extremos, reiniciar. Isso tem riscos bvios de oramento e planejamento. 10 Ningum discutiria que coragem uma virtudee por concluso algum possudo por boa pessoa. Contudo, mesmo o mais corajoso as vezes ir precisar de um jeito organizado de trabalhar e de uma estrutura na qual os problemas difceis podem ser resolvidos.

Uma Comparao de RUP e XP

um projeto do XP, o que [Beck00] chama de morte do projeto (consulte as informaes no ttulo Ciclo de Vida do XP mais adiante), na qual ocorreriam algumas atividades de encerramento do projeto. O Que as Fases do XP Mapeiam no RUP? As fases do XP (que se aplicam aos releases e iteraes do XP) so explorao, confirmao e direcionamento. No nvel do release, elas se alinham com coletas especficas de tarefas (atividades no RUP) na disciplina Gerenciamento de Projetos do RUP. So elas Plano para a Prxima Iterao (mapeamento para explorao e confirmao) e Monitorar e Controlar Projeto (mapeamento para direcionamento). Isso ilustrado nas seguintes sees. Fases do XP Em [Beck00], h um captulo sobre o ciclo de vida de um projeto XP ideal e os ttulos de primeiro nvel so exploration, planning, iterations to first release, productionizing , maintenance e death. Essas parecem ser as fases de nvel superior, mas o resultado disso no bem preciso. Um projeto do XP ser limitado por uma fase de explorao inicial e morte quando o projeto estiver encerrado. Mas a esfera principal o release e cada release tem uma fase de explorao. Portanto, a fase de explorao que suporta o projeto (e leva para o primeiro release) um caso especial pois h uma porta inicial a ser passada (consulte Fazendo o Escopo de um Projeto em [Beck01]) na qual uma deciso tomada sobre a sensatez de continuar. Os releases e iteraes do XP tm as trs fasesexplorao, confirmao e direcionamento. A manuteno realmente caracteriza a natureza do projeto XP depois do primeiro release. Ciclo de Vida do XP Globalmente, o ciclo de vida do XP para um projeto com sete releases acima de 15 meses poder ficar semelhante Figura 1.

Figura 1

Cada release depois do primeiro (que tem trs mdulos) tem cerca de dois meses de durao e cada iterao cerca de duas semanas, exceto nos estgios posteriores de um release (Productionizing, conforme denominado no [Beck00]) quando o ritmo da iterao acelerado. Faz sentido de um ponto de vista da mtrica de planejamento? Neste exemplo inventado, tentamos seguir as diretrizes prescritas pelo XPque os releases devem ter cerca de dois meses de durao, com o primeiro release estando entre dois e seis mesese mantivemos o tamanho da equipe abaixo de 10. Se este projeto for como o Exemplo 3 ilustrado anteriormente, ele fornecer cerca de 40.000 linhas de cdigo Java ou 800 pontos de funo (se aceitarmos o fator de converso encontrado no modelo COCOMO II) no total. Se isso for uniformemente dividido entre releases, ento, cada release fornecer cerca de 115 pontos de funo. A parte duvidosa ser o primeiro release: iniciar do zero (digamos, um membro da equipe designado, nenhum requisito capturado, nenhum escopo feito ainda) para uma entrega a um cliente de algo de qualidade de produo em trs meses, ser

Uma Comparao de RUP e XP

um desafio. Mesmo que permitamos alta produtividade, digamos, 12 pontos/equipe-ms (com base nos dados do segmento de mercado da David Consulting Group, consulte [Link] no ser possvel aumentar a equipe em uma taxa arbitrariamente altao problema que o espao com o qual estamos lidando aqui (115 pontos de funo) muito pequeno e no pode ser dividido em partes arbitrariamente pequenas, seno uma equipe grande poderia atacla. No entanto, se assumirmos que isso pode ser feito, ento, uma equipe de tamanho mdio, com aproximadamente quatro, ser necessria e o projeto gerar o release um com uma equipe de sete. Se mais de um membro da equipe for includo na equipe durante o projeto, ento, para o restante do projeto estaremos no modo normal do XP (manuteno) com uma equipe de oitoque est na zona de conforto de tamanho. Conforme o tamanho entregue aumenta, a produtividade certamente cair um pouco e o intervalo de release diminudo (dois meses) deslocar os membros da equipe aumentada, para que cada release entregue cerca do mesmo peso funcional adicional do primeiro. O esforo global do projeto tem ento 108 equipe-meses um pouco menor que no Exemplo 3 mostrado anteriormente. Ciclo de Vida Padro do RUP Em comparao, o ciclo de vida padro para um projeto do RUP de tamanho similar se assemelha ao seguinte:

Field Code Changed

Figura 2

Novamente, este plano baseia-se no Exemplo 3. As iteraes do RUP so numeradas dentro de cada fase. Utilizando o ciclo de vida padro do RUP, mais provavelmente a oportunidade mais prxima para entregar qualquer coisa que se aproxime da qualidade de produo ao cliente seria o final da primeira iterao de construo, que ocorre sete meses dentro do projeto. No entanto, nesse momento, o RUP poderia entregar cerca de um quarto, ou 200 pontos de funo, da capacidade total (como nos 115 pontos de funo do XP aps trs meses). Normalmente, a primeira entrega ao cliente ocorreria no final da construo, que nesse caso seria 13 meses para o projeto, momento em que essencialmente toda a capacidade estaria presente. Isso no significa que a primeira vez que o cliente ver o produto; com o RUP, o cliente convidado para as avaliaes de iterao e pode ver o produto em desenvolvimento sob teste. Por que existe essa diferena entre o RUP e o XP? Ela ocorre porque, nesse caso padro, a suposio de que h risco suficiente na arquitetura da soluo (porque, por exemplo, ela no tem precedente, tecnologia nova ou os requisitos no funcionais so particularmente onerosos) para garantir duas iteraes na elaborao para estabiliz-la, antes de tentar construir a funcionalidade requerida pelo cliente. Isso significa que no final da elaborao, apenas os requisitos arquiteturalmente significativos sero explorados (e possivelmente implementados). O XP no faz isso. Ele continua a entregar uma srie de solues verticalmente completas em cada release, assumindo-se que a arquitetura no ser interrompida entre os releases ou que a recriao poder reparar qualquer interrupo que ocorra. Acreditamos que isso limita a aplicao sensvel do XP a classes do sistema que podem ser construdas em arquiteturas existentes de capacidade conhecida.

Uma Comparao de RUP e XP

Ciclo de Vida Real do RUP Para tais sistemas, o ciclo de vida real do RUP ser um pouco diferente; a fase de elaborao ser bem mais reduzida e provavelmente a fase de iniciao tambm. Se negociarmos uma iterao de elaborao para uma iterao de construo, poderemos adiantar o final da primeira iterao de construo em alguns meses, cinco em vez de sete. Isso provavelmente entregar um pouco menos de 200 pontos de funo no exemplo padro (porque o nmero de equipes trabalhando na iterao de construo mais adiantada ser menor), mas isso est se aproximando da agilidade de planejamento do XPcom afrouxamento suficiente para reduzir significativamente o risco. Ao extremo, podemos imaginar uma abordagem baseada no RUP estabelecida em torno da entrega inicial de um sistema pequeno (digamos, 115 pontos de funo como no exemplo do XP), seguida por uma srie de ciclos evolutivos completos do RUP (iniciao completa, elaborao, construo e seqncias de transio) para entregar o restante do sistema em um modo de manuteno anlogo ao XP. Novamente, por volta de seis meses, a entrega inicial provavelmente estar no limite externo do intervalo de tempo recomendado para o XP, mas, ento, o RUP reconhece e requer que voc planeje (e, portanto, aloque tempo e esforo) coisas que o XP parece atenuar, como a implantao de releases. Podemos concluir outras restries, a partir dessas observaes, sobre a natureza de projetos para os quais o XP adequado. O XP requer explicitamente um relacionamento muito ntimo entre o cliente e a equipe de desenvolvimento, requerendo um cliente em tempo integral on-site e que os clientes escrevam histrias e definam os releases. No XP, o cliente realmente uma funo na equipe: a pessoa ou grupo que desempenha a funo poder ou no pertencer a uma empresa de aquisio separada, mas eles tm a autoridade de falar com quem estiver adquirindo o software. Essencialmente, eles tm os requisitos. Esse tipo de relacionamento mais freqentemente encontrado em desenvolvimentos domiciliares do que em desenvolvimentos contratados formalmente para clientes externos. Um ciclo de release de dois meses tambm seria mais aceitvel em tais ambientes. A implantao de um novo release (com novos recursos, no apenas correes de defeitos) a cada dois meses, atravs dos limites da empresa, provavelmente ter uma despesa logstica inaceitvel. Com esses tipos de afrouxamento (equipe pequena, arquitetura j estabelecida, desenvolvimento de estilo domiciliar com pouca implantao de praxe) um ciclo (ou ciclos) ajustado do RUP ter um efeito similar a um desenvolvimento do XP. A durao inicial do release poder ser um pouco mais longa do que o ideal do XP, mas ter menos risco. Na direo oposta (equipe grande, arquitetura sem precedente, desenvolvimento contratado formalmente com restries de entrega e implantao) difcil ver como o XP pode escalare, para ser imparcial, as fontes deste documento no afirmam que ele possa. O RUP, por outro lado, projetado para enfrentar a formalidade e a cerimnia que acompanham tais projetos. Talvez uma abordagem semelhante do XP (ou seja, utilizar tcnicas do XP como programao em pares e recriao) possa ser incorporada dentro de um projeto maior do RUP, mas apenas quando a arquitetura estiver estvel.

Uma Comparao de RUP e XP

Artefatos
O RUP descreve mais de 100 artefatos, o que tem levado a crticas de que ele impe uma despesa burocrtica intolervel para projetos pequenos. Essa viso est incorreta em quatro clculos: Os projetos no tm de produzir todos os artefatos: a seleo e o ajuste de artefatos um parte necessria do processo. O RUP fornece diretrizes sobre o que pode ser otimizado e o que pode ser ajustado. Um artefato (no RUP, uma descrio de artefato) uma entidade de especificaoele especifica as informaes a serem produzidas por uma tarefa e, para fazer isso sistematicamente, poder descrever a forma abstrata de um artefato. A caracterizao de artefatos do RUP como modelos, elementos de modelo ou documentos (cerca de metade dos artefatos do RUP so classificados como documentos) no tem o objetivo de implicar uma realizao particular. Um modelo UML poder ser capturado e apresentado utilizando uma ferramenta com finalidade de construo (como o Rational Rose) ou, no outro extremo, como diagramas feitos utilizando uma ferramenta grfica simples ou at mesmo como um esboo em um whiteboardisso ainda contaria como um artefato em termos de RUP (embora haja um risco de perda com um whiteboard!). O termo documento tem conotaes histricas que ainda influenciam as pessoas a pensarem em um documento como um produto de trabalho distinto, baseado em papel, com um conjunto especfico (e requerido) de ttulos de pargrafodos quais todos tm de ser preenchidos com texto (e talvez diagramas) para o documento ser concludo. Mas isso apenas uma realizao de um documento do RUP. Os documentos do RUP so conjuntos de informaes compostos de texto e diagramas. Para ser til, o RUP especifica o que devem ser essas informaes e uma maneira conveniente e sistemtica de fazer isso apontar para um gabarito, que enumera e descreve os itens e problemas a serem considerados. certamente possvel utilizar esses gabaritos de uma maneira direta e formal para perceber os artefatos na forma de documento (no senso geral); ou seja, eletrnico ou papel. Sabendo que muitos projetos desejaro fazer isso, escolhemos a apresentao de um conjunto de gabaritos que podero ser utilizados, mais ou menos diretamente, dessa maneira. Mas essencial fazer issonem tudo apresentado em um gabarito necessariamente relevante para um projeto especficoe o RUP fornece a um projeto a liberdade de escolher qualquer percepo adequada (e mecanismo de entrega) para um artefato. O importante so as informaes que ele contm. Sentimos que era essencial que todos os produtos de trabalho potenciais do processo fossem claramente identificados para considerao pelo engenheiro de processo e coordenador de projeto, portanto, as decises para omiti-los ou ajust-los poderiam ser feitas conscientemente e com o entendimento total das conseqncias da omisso. Acreditamos que tornar a lista de artefatos completa e explcita dessa maneira fornece objetividade configurao do processo. Tambm d suporte ao coordenador de projeto menos experiente chamando sua ateno a coisas que um coordenador mais experiente veria ao ler, onde no foram mencionadas, mas que o iniciante poderia apenas no notar. Ter um conjunto de documentos bem definido tambm ajuda o cliente e o coordenador de projeto a concordarem antecipadamente com o que deve ser entregue e em que forma para evitar os argumentos desagradveis que freqentemente caracterizam o encerramento do projeto. O RUP descreve vrios artefatos que so compostos e tambm continua a descrever seus componentes como artefatos. Isso permite um descrio granulada das entradas e sadas de tarefas, onde for til. Em sua descrio, o RUP poderia ter parado na composio, por exemplo, o Modelo de Design e referido-se a Classes simplesmente como partes do Modelo de Design e no como artefatos por sua prpria conta. A identificao desses artefatos permite uma descrio precisa de seu uso, ao mesmo tempo que est em conformidade com o metamodelo do processo custa de aumentar a contagem global de artefatos.

O XP parece estar imune a crticas de ser cheio de artefatos, mas isso uma simplificao excessiva por duas razes: O XP j est ajustado para adequar um determinado tipo de desenvolvimento, lidando com um subconjunto das disciplinas do RUP em uma determinada escala e, portanto, o esperado que busque menos artefatos.

Uma Comparao de RUP e XP

O XP enfatiza a importncia de histrias do usurio e cdigos, mas outras coisas que so produtos de trabalho so mencionadas na transmisso ao descrever o processo, portanto, a contagem de artefatos no to pequena quanto parece a princpio.

Considerando a abordagem do XP, talvez no seja surpresa que nos trs livros que utilizamos como material fonte para essa comparao (porque eles so o carro-chefe do processo), os termos artefato e produto de trabalho no aparecem no ndice. No entanto, no difcil ler o texto e selecionar referncias que so artefatos. A seguir so apresentados alguns exemplos: Histrias Restries Tarefas Tarefas tcnicas Testes de aceitao Cdigo desoftware Releases Metforas O designCRC, esboo UML Documentos de designproduzidos no final do projeto Padres de codificao Testes de unidade Espao de trabalho (desenvolvimento e outros recursos) Plano de liberao Plano de iterao Relatrios e notas sobre reunies Plano globaloramento Relatrios em andamento Estimativas de estrias Estimativas de tarefas Defeitos (e dados associados) Documentao adicional a partir de conversaes Documentao de suporte Dados de Teste Ferramentas de estrutura de teste Ferramentas para gerenciamento de cdigo Resultados de teste Pontas (solues) Registro de tempo de trabalho em tarefas Dados mtricos o o o o Recursos Escopo Qualidade Tempo

Outras mtricas

10

Uma Comparao de RUP e XP

Resultados de rastreio

H cerca de 30 artefatos, alguns dos quais tambm so compostos. A lista deve ser indicativa, no exaustiva. Os livros do XP no perdem muito tempo descrevendo a maioria deles e, no nvel em que os livros foram escritos, no poderemos esperar isso deles. No entanto, depois que um projeto precisar entend-los, mais detalhes sobre seu contedo e forma sero necessrios. Um projeto pode certamente fazer isso sem se deter, mas isso utiliza tempo do trabalho real; em comparao, o RUP fornece orientao direta, portanto, economizando o tempo de projeto. Por Que o XP Precisa dos Artefatos do RUP? Uma razo que o XP no tem o escopo do RUP. Isso completamente intencional; o XP est disponvel para programao para atender uma necessidade de negcios. Como a necessidade de negcios ocorreue como modelada, capturada e deduzidano uma preocupao principal do XP. O membro da equipe do XP que o cliente apresenta a destilao dos requisitos como histrias para a equipe de desenvolvimento do XP; eles tambm so os rbitros do valor de negcios. A mgica de como as histrias vieram a ser expressas (ou exprimveis) nessa forma no a preocupao do XP. Portanto, por exemplo, o que o RUP descreve na disciplina Modelagem de Negcios est fora do escopo do XP (a Modelagem de Negcios no RUP tem ~14 artefatos). O XP descreve um processo que tem releases regulares para o cliente. As logsticas de implantao desses releases no so a preocupao de desenvolvimento, portanto, a disciplina Implantao do RUP est amplamente fora do escopo do XP (a Implantao no RUP tem ~9 artefatos). Portanto, para um projeto pequeno tratvel pelo XP, voc esperar omitir ~23 artefatos ao ajustar o RUP. Outra razo que o XP afirma que a captura de requisitos e design pode ser feita simplesmente: os requisitos so capturados como estrias do usurio (que podem s vezes ter sido divididas) que so, ento, decompostas em tarefasque, essencialmente, so o designtendo em mente uma metfora para o sistema. Isso possvel para todos os sistemas? Definitivamente, no. Isso possvel para alguns sistemas? Certamente, e para ser imparcial com o XP, no solicitado o enfoque em todos os sistemas. Alm disso, talvez os autores do XP estivessem com suas lnguas firmemente cravadas na bochecha ao fazerem essas solicitaes. O comportamento desejado de sistemas maiores e mais complexos pode ser muito difcil de articular sem alguma abordagem sistemtica, como casos de uso. Nem ser possvel confiar na conversao entre o cliente e o desenvolvedor para elaborar consistentemente estrias complexas do usurio, sendo a memria humana falvel como . Alm disso, o desenvolvimento das estruturas que entendem comportamento complexo em sistemas grandes ajudado pela habilidade de formar e deduzir vrias vises abstratas da arquitetura do sistema. Os artefatos que o RUP descreve nas disciplinas Requisitos (~14 artefatos) e Anlise & Design (~17 artefatos), permitem que ele encare a variedade, o tamanho e a complexidade desses sistemas. No roteiro de projetos pequenos do RUP, a contagem de artefatos (para Requisitos e Anlise & Design) reduzida para sete, com alguma reduo obtida simplesmente com a referncia ao artefato composto. Isso no uma escamoteao; ele lida com artefatos da mesma maneira que o XP. Por exemplo, devido forma que ele provavelmente entendido em um projeto pequeno, o RUP informa o seguinte sobre o Modelo de Design: O Modelo de Design deve evoluir atravs de uma srie de sesses de sugestes de idias nas quais os desenvolvedores utilizaro cartes CRC e diagramas desenhados mo para explorar e capturar o design. O Modelo de Design ser mantido apenas enquanto os desenvolvedores o acharem til. Ele no ser mantido consistente com a implementao, mas ser preenchido para referncia. Finalmente, o RUP permite uma formalidade maior (e cerimnia) no gerenciamento de projeto, onde isso for necessrio, e em algumas disposies de contrato haver necessidade [Link], muitos artefatos de gerenciamento de projeto do RUP (existem 15 na disciplina Gerenciamento de Projeto) fazem parte dos artefatos compostos e precisam apenas ser percebidos como documentos separados quando a formalidade do projeto solicitar isso. Por exemplo, no RUP o Plano de Desenvolvimento de Software contm artefatos como o Plano de Gerenciamento de Risco e o Plano de Aceitao do Produto. Em projetos menores, menos formais, poder ser possvel lidar com os problemas enfocados por esses planos simplesmente com um pargrafo ou dois no Plano de Desenvolvimento de Software. No roteiro de projetos pequenos no RUP, o nmero de artefatos de gerenciamento de projeto ser reduzido para seis. Comparando Artefatos para um Projeto Pequeno Portanto, quando voc ajustar o RUP para um projeto pequeno e ajustar os requisitos do artefato, o que acontecer globalmente? Quando voc v o roteiro de um projeto pequeno no RUP e conta os artefatos, o nmero 30 (26 se voc retirar

11

Uma Comparao de RUP e XP

alguns de implantao)afinal, no est to cheio de artefatos! O RUP simplesmente delineia claramente o que o XP deixa obscuro, permite que voc decida o que necessrio e fornece orientao sobre como fazer a seleo. Agora, a granularidade varia nos dois lados, mas o ponto que a contagem de artefatos no RUP para projetos pequenos do tipo que o XP enfocaria confortavelmente da mesma ordem do XP.

12

Uma Comparao de RUP e XP

Mapeamento Grosseiro de Artefatos do XP para Artefatos do RUP XP Roteiro de Projetos Pequenos do RUP

Histrias Documentao adicional a partir de conversaes Restries Testes de aceitao Testes de unidade Dados de Teste Resultados de teste Cdigo desoftware Releases Metfora DesignCRC, esboo UML Tarefas Tarefas Tcnicas Documentos de designproduzidos no final do projeto Documentao de suporte Padres de codificao Espao de trabalho (desenvolvimento e outros recursos) Ferramentas de estrutura de teste Plano de liberao Estimativas de estrias Estimativas de tarefas Plano de iterao Plano globaloramento

Viso Glossrio Modelo de Caso de Uso Especificaes Complementares Modelo de Teste

Modelo de Implementao Produto Notas de Release Documento de Arquitetura de Software Modelo de Design

Diretrizes de Design Diretrizes de Programao Ferramentas Plano de Desenvolvimento de Software Plano de Iterao

Caso de Negcios Lista de Riscos Plano de Aceitao do Produto Avaliao de Status

Relatrios em andamento Registro de tempo de trabalho em tarefas Dados de mtricas: Recursos, Escopo, Qualidade, Tempo Outras mtricas Resultados de rastreio Relatrios e notas sobre reunies Defeitos e dados associados Ferramentas para gerenciamento de cdigo

Controle de Alteraes Plano de Gerenciamento de Configurao Repositrio de Projetos Espao de Trabalho Prottipos Caso de Desenvolvimento Templates Especficos do Projeto

Ponto

13

Uma Comparao de RUP e XP

Diretrizes Associado aos artefatos, o RUP fornece diretrizes, que so essencialmente informaes adicionais sobre esse artefato, seu significado, representao, relacionamentos com outros artefatos, contedo e uso. Essas diretrizes iro abranger vrias centenas de pginas fsicas, se impressas, o que pode parecer desanimador, mas ento voc apenas l o que precisa, para os artefatos que necessita. Os livros do XP tambm contm muita orientao sobre prticas e artefatos, sem tentar (ou precisar) modelar os relacionamentos rigorosamente. O corpo total da literatura sobre o XP no pequeno. Os trs livros disponveis no momento da escrita totalizam quase 600 pginas e os dois outros estaro disponveis logo incluindo outras 700 pginas ou mais. Ento, h o livro sobre recriao [Fowler99] com mais de 400 pginas. Alm disso, o XP discutido em vrios Web sites. No entanto, a discusso tende a sobreporexaminando o XP de pontos de vista diferentes e incluindo na base de experincia. Realmente, isso ilumina outra diferena entre o RUP e o XP. O RUP um produto; o XP no. No h nenhuma fonte nica para o XP, embora os livros sejam um bom incio. A forma mais rpida de adquirir o XP seria atravs do treinamento que est comercialmente disponvel a partir do lderes de opinio por trs dele.11

11

O RUP s vezes retratado como proprietrio, mas qualquer pessoa pode comprar o RUP e utilizar as idias contidas nele, inclu-lo, excluir partes que no so relevantes para sua organizao ou projeto e assim por diante, contato que respeite os direitos autorais e o contrato de licena. A manifestao do XP na forma de livro tambm propriedade intelectual pertencente aos autores e editores; a nica diferena a extenso em que cada um pode ser completamente compreendido a partir de suas fontes. O RUP, como um produto, tenta ser completo; os livros atuais do XP precisam de alguma suplementao (atravs de treinamento imersivo ou de consulta).

14

Uma Comparao de RUP e XP

Tarefas
O RUP define formalmente o termo tarefa como trabalho executado por uma funo, utilizando e transformando artefatos de entrada e produzindo artefatos de sada novos e alterados. O RUP ento enumera essas tarefas e as categoriza de acordo com a disciplina ou a rea de preocupao principal dentro do projeto (conforme o RUP a definir). Essas disciplinas so: Modelagem de Negcios Requisitos Anlise & Design Implementao Teste Implantao Gerenciamento de Configurao & Alteraes Gerenciamento de Projeto Ambiente

As tarefas esto relacionadas ao tempo por meio dos artefatos que produzem e consomem: uma tarefa pode logicamente ser iniciada quando suas entradas estiverem disponveis (e em um estado de maturao apropriado). Isso significa que os pares de tarefas produtor-consumidor podem se sobrepor no tempo, se o estado do artefato permitir. Eles no precisam obedecer a uma seqncia rgida. As tarefas no RUP tm como objetivo tornar o processo intelectual de produzir um artefato menos opacodar alguma orientao forte sobre como algo deve ser produzido. As tarefas tambm podem ser utilizadas para ajudar o coordenador de projeto com seu planejamento. Combinadas por meio do RUP, conforme descritas em termos de ciclo de vida, artefatos e tarefas so as boas prticas: princpios de engenharia de software que comprovadamente produzem softwares de qualidade construdos para oramento e planejamento previsveis. Atravs de suas tarefas e seus artefatos associados, o RUP suporta e realiza essas melhores prticaselas so temas executados atravs do RUP. Observe que o XP utiliza a noo de prticas tambm, mas, como veremos, no corresponde exatamente ao conceito de boas prticas do RUP. O XP (consulte [Beck00], Captulo 9) apresenta uma viso de desenvolvimento de software que atraentemente simples, composta por quatro tarefas bsicas que devem ser ativadas e estruturadas de acordo com algumas prticas de suporte: Codificao Teste Atendimento Design

Na verdade, as tarefas do XP esto mais relacionadas em escopo s disciplinas do RUP do que s tarefas do RUP e muito do que acontece em um projeto do XP (alm da codificao, teste, atendimento e design) resultado da elaborao e da aplicao de suas prticas. Existe um Equivalente das Tarefas do RUP no XP? Sim, h, mas as tarefas do XP no so formalmente identificadas ou descritas; por exemplo, verificando o Captulo 4, Estrias de Usurios em [Jeffries01], voc encontrar o ttulo Definir Requisitos com Estrias Escritas em Cartes e em todo o captulo h uma mistura da descrio do processo e da orientao sobre o que so estrias de usurios e como (e por quem) elas devem ser produzidas. E assim vai, como os livros descrevem o XP sob ttulos principais (que so uma mistura em [Jeffries01]algumas esto focadas em artefatos, outras em atividades); Coisas Concludas e Coisas Produzidas esto descritos com graus variveis de prescrio e detalhes. A prescrio aparente do RUP resultado da concluso e maior formalidade no tratamento sistemtico de tarefas e de suas entradas e sadas. No falta prescrio para o XP, porm, na sua tentativa de permanecer leve, a formalidade e os detalhes so simplesmente omitidos. Os detalhes esto presentes no RUP e tero de ser includos quando o XP for implementado em

15

Uma Comparao de RUP e XP

um projeto. A falta de especificidade no uma vantagem ou uma desvantagem, mas voc no deve confundir a falta de informaes detalhadas no XP com simplicidade. Em algum ponto, as pessoas no projeto precisaro saber o que fazer e, nesse momento, precisaro dos detalhes.

16

Uma Comparao de RUP e XP

Disciplinas
Uma disciplina no RUP a coleta de tarefas (e conceitos associados) que produzem um conjunto especfico de artefatos, que representa algum aspecto ou preocupao importante no desenvolvimento de software. Esse uso alinha-se bem com a definio no dicionrio de disciplina como uma ramificao de conhecimento ou ensinamento. Conforme observado anteriormente, as disciplinas do RUP so Modelagem de Negcio, Requisitos, Anlise & Design, Implementao, Teste, Implantao, Configurao & Gerenciamento de Alteraes, Gerenciamento de Projeto e [Link] no abrange cada aspecto do que uma organizao ou empresa pode fazer quando emprega pessoas para desenvolver, implantar, operar, suportar, vender, comercializar ou, de alguma outra forma, lidar com sistemas que so amplamente de software. Atualmente, o RUP no abrange a Engenharia de Sistemas, por exemplo. Nem abrange todos os requisitos de alguns padres internacionais de processo de software, como ISO 15504 (que extrai aspectos relacionados aquisio de software e ao gerenciamento de recursos humanos, por exemplo). Isso feito por escolha: esses outros aspectos, embora importantes, esto fora do foco de engenharia do RUP. O XP se restringe ainda mais: ele inclui quatro atividades bsicascodificao, teste, atendimento e design (observado anteriormente como mais proximamente alinhadas com as disciplinas do RUP)executadas utilizando um conjunto de prticas, que requer a execuo de outras atividade, que so mapeadas para algumas das outras disciplinas no RUP. As prticas do XP, mencionadas de forma literal em [Beck00], so: O Jogo do PlanejamentoDetermina rapidamente o escopo do prximo release, combinando as prioridades do negcio e as estimativas tcnicas. Quando a realidade superar o plano, atualize-o. Pequenos ReleasesColoca um sistema simples em produo rapidamente, em seguida, libera novas verses em um ciclo muito curto. MetforaGuia todo o desenvolvimento com uma estria simples compartilhada de como todo o sistema funciona. Design SimplesO sistema deve ser projetado o mais simplesmente possvel a qualquer momento. Qualquer complexidade extra deve ser removida assim que for descoberta. TesteOs programadores escrevem testes de unidade continuamente, que devem ser executados sem problemas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as caractersticas foram alcanadas. RecriaoOs programadores reestruturam o sistema sem alterar seu comportamento para remover a duplicao, aprimorar a comunicao, simplificar ou incluir flexibilidade. Programao aos paresTodo o cdigo de produo gravado com dois programadores em uma mquina. Propriedade coletivaQualquer pessoa pode alterar qualquer cdigo em qualquer lugar do sistema a qualquer momento. Integrao contnuaIntegra e constri o sistema muitas vezes por dia, sempre que uma tarefa concluda. 40-horas por semanaA regra no trabalhar mais de 40 horas por semana. Nunca faa hora extra duas semanas seguidas. Cliente on-siteInclui um usurio real, ativo na equipe, disponvel tempo integral para responder a perguntas. Padres de codificaoOs programadores escrevem todo o cdigo de acordo com as regras, enfatizando a comunicao por meio do cdigo.

Algo que deve ser notado no tpico Design Simples que complexidade extra um termo meio subjetivo e difcil de definir, sendo amplo na opinio do observador experiente. As atividades executadas como resultado da prtica O Jogo do Planejamento, por exemplo, sero mapeadas principalmente para a disciplina de Gerenciamento de Projeto do RUP. No entanto, alguns tpicos esto fora do escopo do XP; por exemplo, Modelagem de Negcio. O levantamento de requisitos est ainda mais fora do escopo de XPo cliente (on-site com a equipe) define e fornece os requisitos (na forma de estrias). A implantao do software liberado est fora do escopo do XP.

17

Uma Comparao de RUP e XP

Devido escala e aos tipos de desenvolvimento que ele enfoca, o XP pode lidar muito superficialmente com problemas nas disciplinas Ambiente e Gerenciamento de Configurao & Alteraes que o RUP cobre em detalhes.

18

Uma Comparao de RUP e XP

Uso de Prticas do XP no RUP Nas disciplinas em que o XP e o RUP se sobrepem, algumas das prticas descritas no XP podero ser implementadas no RUP (e algumas j esto); por exemplo: Programao em pares: O XP requer que o cdigo de produo seja produzido pelos programadores que trabalham em pares em uma nica estao de trabalho e afirma que isso tem efeitos benficos na qualidade do cdigo e, depois de adquirida a habilidade, torna-se mais agradvel. O RUP no descreve o mecanismo de produo de cdigo nesse nvel to refinado e, certamente, ser possvel usar a programao em pares em um processo baseado no RUP. Algumas informaes sobre essa prtica e o Design anterior ao teste e recriao (consulte abaixo) so agora fornecidas com o RUP na forma de white papers. Obviamente, no um requisito utilizar essa prtica no RUP nem acreditamos que seja necessrio determinar isso. A evidncia de benefcios na escala industrial insuficiente e anedtica; estudos realizados por ([Nosek98] e [Williams00]) compararam pares com indivduos (trabalhando isolados), mas boas equipes no trabalham dessa forma. Em um ambiente de equipe, com uma cultura de comunicao aberta, na qual indivduos sentem-se vontade para fazer perguntas de seus pares (e lderes de equipes ou gerenciamento) e trabalham para um processo definido, podemos arriscar um palpite de que seria muito difcil discernir os benefcios da programao em pares (em termos de efeito sobre o custo total do ciclo de vida). normal que as pessoas se renam para discutir e resolver problemas em uma equipe bem integrada, sem que sejam obrigadas a fazer isso. [Beck00] tem uma viso meio obscura de pessoas e processos quando diz: Outro recurso poderoso da programao em pares que algumas das prticas no funcionaro sem ela. Sob estresse, as pessoas mudam. Elas ignoraro os testes escritos. Elas descartaro a recriao . Elas devem ser prticas naturais que levam a um melhor resultado por que algum no as seguiria? A iniciao de um bom processo no-intrusivo; a sugesto que deve ser reforada no nvel de micro desagradvel. Entretanto, em algumas circunstncias, o trabalho em pares obviamente vantajoso, porque cada um pode ajudar o outro; por exemplo: o o o no incio da formao da equipe, quando as pessoas ainda esto se conhecendo; em equipes que no tenham experincia em uma determinada tecnologia nova; em equipes formadas tanto por pessoal experiente como por novatos.

Design anterior ao teste e recriao: Essas so boas tcnicas que podem ser aplicadas na disciplina Implementao do RUP. O design anterior ao teste , em particular, uma forma excelente de esclarecer requisitos em um nvel mais detalhado. Cliente on-site: Muitas tarefas do RUP se beneficiaro bastante em termos de aumento de eficincia ao ter um cliente on-site como um membro da equipe. Com o cliente nesse caminho, a necessidade de vrios distribuveis intermedirios (particularmente documentos) pode ser reduzida. O XP reluta em dizer que qualquer outra coisa que no seja cdigo deve ser capturada e reala a converso como o meio de comunicao preferido. Isso conta com a continuidade e familiaridade para obter sucesso. Quando um sistema precisa ser transicionado, ento, mesmo para sistemas pequenos, outras coisas precisaro ser produzidas. A XP finalmente permite isso, mas algo como uma reflexo posterior; por exemplo, projetar documentos no final de um projeto. De fato, o XP no probe a produo de documentos ou outros artefatos (ele apenas no se pronuncia sobre isso), dizendo que voc deve produzir apenas aqueles de que realmente precisa; aqueles que so utilizados. O RUP concorda, mas continua a listar e a descrever o que poder ser necessrio quando a continuidade e a familiaridade no forem ideais.

Padres de codificao: O RUP tem um artefato (Diretrizes de Programao) que quase sempre ser considerado como obrigatrio (a maioria dos perfis de risco do projeto, sendo um condutor principal de ajuste, o tornaro).

19

Uma Comparao de RUP e XP

Integrao contnua: O RUP suporta essa prtica por meio de construes nos nveis de subsistema e de sistema (dentro de uma iterao); componentes testados pela unidade so integrados e testados no contexto do sistema emergente.

20

Uma Comparao de RUP e XP

Prticas do XP que No So Escalveis No entanto, algumas prticas no so escaladas (e o XP no afirma que sejam) e tornaremos seu uso sujeito a essa condio no RUP; por exemplo: Propriedade Coletiva: til ter os membros de uma pequena equipe, responsveis por um sistema pequeno ou um subsistema de um sistema maior, familiarizados com todos os seus cdigos. Porm, se voc deseja que todos os membros da equipe estejam em condies iguais de efetuar mudanas em qualquer lugar, isso vai depender da natureza e da complexidade do sistema ou do subsistema. Geralmente, mais rpido (e seguro) que a correo seja efetuada pelo indivduo (ou par) que esteja trabalhando no momento com um segmento do cdigo. A familiaridade com o cdigo mais bem escrito diminui rapidamente atravs do tempo, especialmente se ele for complexo pelo aspecto algortmico. Recriao: Em um sistema grande, a recriao freqente no uma substituta para a falta de arquitetura. [Beck00] diz, A estratgia de design do XP assemelha-se a um algoritmo escalando uma montanha. Voc pega um design simples, torna-o um pouco mais complexo, depois um pouco mais simples e de novo mais complexo. O problema com os algoritmos que escalam montanhas alcanar o ponto ideal, em que nenhuma pequena alterao pode aprimorar a situao, mas uma alterao grande poderia. No RUP, a arquitetura fornece a visualizao e o acesso grande montanha tornando flexvel um sistema grande e complexo. Metfora: Para sistemas maiores, complexos, a arquitetura como metfora simplesmente insuficiente. O RUP fornece uma estrutura descritiva muito mais rica para a arquitetura que no apenas, como [Beck00] a descreve com rejeio, grandes caixas e conexes. Releases rpidos: A freqncia com que um cliente pode aceitar e implantar novos releases depende de muitos fatores; normalmente incluindo o tamanho do sistema, que normalmente est correlacionado ao impacto [Link] ciclo de dois meses pode ser muito curto para algumas classes de sistemasendo proibido pela logstica de implantao.

E algumas prticas, que so em princpio obviamente seguras e potencialmente utilizveis no RUP, precisam de pouca elaborao e cuidado quando aplicadas em geral: Design simples: O XP muito direcionado funcionalidade: estrias de usurios so selecionadas, decompostas em tarefas e, em seguida, implementadas. De acordo com [Beck00], o design correto para o software em qualquer momento determinado aquele que: 1. 2. 3. 4. Executa todos os testes No tem lgica duplicada Declara toda inteno importante para os programadores Tem poucas classes e mtodos possveis.
Formatted: Bullets and Numbering

O XP no acredita na incluso de nada que no seja necessrio agora. Existe um problema nele meio parecido com o problema de otimizao local ao lidar com uma classe de requisitos denominada no funcional no RUP. Esses requisitos tambm agregam valor de negcio para o cliente, mas so mais difceis de expressar como estrias algumas das quais o XP chama de restries caem nessa categoria. O RUP tambm no defende que se faa design a mais do que seja necessrio em qualquer tipo de modo especulativo, mas defende o design com um modelo arquitetural mental - modelo este que uma das chaves para se encontrar os requisitos no funcionais. Assim, o RUP concorda com o XP: o design simples deve executar todos os testes, mas com a condio de que ele inclua testes que demonstrem que o software atender aos requisitos no funcionais. Mais uma vez, isso se torna um problema importante medida que o tamanho do sistema e a complexidade aumentem, quando a arquitetura for indita ou quando os requisitos no funcionais forem dispendiosos. Por exemplo, a necessidade de dados

21

Uma Comparao de RUP e XP

desordenados (para operar em um ambiente distribudo de forma heterognea) parece tornar o cdigo excessivamente complexo, mas ele ainda ser uma necessidade global. Quarenta horas por semana: Como no XP, o RUP sugere que trabalhar horas extras no deve ser uma condio crnica. A XP no sugere um limite rgido de 40 horas, admitindo diferentes margens de tolerncia para o perodo de trabalho. Os engenheiros de software costumam trabalhar muitas horas sem gratificao extra, trabalham apenas pela satisfao de verem algo concludo, e o gerente no necessariamente precisa colocar arbitrariamente um ponto final nisso. O que um gerente no deve fazer explorar essa situao ou imp-lae ele deve sempre coletar mtricas sobre as horas realmente trabalhadas, ainda que no compensadas. Se o registro de horas trabalhadas por algum parecer alto durante um perodo extenso, ento, certamente isso deve ser investigado. Entretanto, esses problemas devem ser resolvidos em circunstncias particulares nas quais eles surgem, entre o gerente e o indivduo, admitindo preocupaes que o restante da equipe poderia ter. Quarenta horas apenas um guia (mas forte).

22

Uma Comparao de RUP e XP

Funes
No RUP, as tarefas so executadas por funes.12 As funes tambm tm responsabilidade por artefatos especficosa funo responsvel normalmente criar o artefato e garantir que as alteraes feitas por outras funes (se permitidas) no danifiquem o artefato. Uma funo no RUP pode ser executada por um indivduo ou por um grupo de pessoas. Igualmente, um indivduo ou grupo pode executar vrias funes. Um funo no precisa ser mapeada para uma nica posio ou fenda em uma organizao; o mapeamento de funes para organizational units tambm pode ser feito de muitos-a-muitos. Funes do RUP O RUP define um total de 30 funes: no existe um mapeamento exato para disciplinas porque uma funopor exemplo, um arquiteto de softwareno fica necessariamente confinado a uma disciplina, mas aproximadamente (colocando a funo onde ela pertencente): Modelagem de Negcios tem trs funes Requisitos tem cinco funes Anlise & Design tem seis funes Implementao tem trs funes Teste tem duas funes Implantao tem quatro funes Gerenciamento de Configurao & Alteraes tem duas funes Gerenciamento de Projeto tem duas funes Ambiente tem trs funes

Por Que H Tantas Funes no RUP? As funes no RUP so utilizadas para particionar tarefas e para discriminar sutilmente as habilidades e competncias necessrias para executar a funo, o que ajuda a guiar a seleo da equipe para executar essas funes. O nvel de diviso tambm facilita a identificao das novas posies organizacionais quando a importncia de uma funo alterada. Por exemplo, em um projeto pequeno, informal, a funo de Coordenador de Projeto e Gerente de Configurao (funes do RUP) pode ser bem executada pelo mesmo indivduo; em um projeto de espao areo militar, maior e formal, o trabalho do Gerente de Configurao poder ser bem especializado e oneroso o suficiente para garantir uma equipe pequena. Ao descrever funes dessa maneira, o RUP facilita esse mapeamento. Funes do XP [Beck00] identifica sete funes aplicveis ao XP e, ento, continua a descrever as responsabilidades das funes, as habilidades e os traos requeridos das pessoas que as executaro. Essas funes so: Programador Cliente Testador Rastreador Tcnico Consultor Diretor

So feitas referncias a essas funes em alguns dos outros livros de XP, em locais que elaboram as tarefas que a funo executa.

12

Para ser mais preciso (e exato), as tarefas so executadas por indivduos ou equipes que desempenham as funes.

23

Uma Comparao de RUP e XP

A diferena no nmero de funes do XP e do RUP facilmente explicada: O XP no est convertendo todas as disciplinas do RUP. As funes do XP esto realmente mais prximas de posies do que as funes do RUP; por exemplo, um programador do XP realmente executa vrias funes do RUPaquelas do Implementador, Integrador e Revisor de Cdigoe elas requerem poucas competncias diferentes.

Quando funes do RUP so mapeadas para um projeto pequeno (como no roteiro de projetos pequenos do RUP), o nmero de funes semelhantes do XP, ou seja posies, que so mapeadas reduz consideravelmente para 30. No roteiro de projetos pequenos, o nmero de posies cinco, conforme mostrado na seguinte tabela.
Funes do RUP Mapeadas para um Projeto Pequeno da Empresa ABC Cargo na Empresa ABC Funo RUP

Coordenador de Projeto

Coordenador de Projeto Engenheiro de Processo Gerenciador de Implantao Revisor de Requisitos Revisor de Arquitetura Revisor de Projeto Investidores Revisor de Requisitos Analista de Sistemas Especificador de Requisitos Designer da Interface com o Usurio Arquiteto de Software Revisor de Design Engenheiro de Processo Especialista em Ferramentas Gerenciador de Configurao Gerenciador de Controle de Alteraes e, em uma extenso menor, as mesmas funes do Programador Designer Implementador Revisor de Cdigo Integrador Designer de Teste Testador Responsvel por: manter o Web site do Projeto Pequeno ajudar a funo Coordenador de Projeto a planejar atividades ajudar a funo Gerente de Controle de Alteraes a controlar alteraes em artefatos tambm pode fornecer assistncia a outras funes, conforme necessrio

Executivo na Empresa ABC

Programador-chefe

Programador

Assistente Administrativo

24

Uma Comparao de RUP e XP

Concluses
O XP no a mesma coisa que o RUP. O RUP uma estrutura de processo a partir da qual determinados processos podem ser configurados e, em seguida, instanciados. O RUP precisa ser configurado e isso realmente uma etapa requerida definida no prprio RUP. Especificamente falando, deve-se comparar uma verso adaptada do RUP com XP, com o RUP adaptado s distines do projeto que o XP explicitamente estabelece (e as que podem ser inferidas). Tal processo de RUP adaptado dessa forma poderia acomodar muitas prticas do XP (como programao em pares, design anterior ao teste e recriao), mas ainda no seria idntico ao XP, por causa do reconhecimento da importncia da arquitetura, abstrao (em modelagem) e risco e de sua estrutura diferente no tempo (fases, iteraes). O RUP permitir a construo de processos para acomodar projetos que esto fora do escopo do XP em escala ou tipo. O RUP pesado apenas por ser uma descrio completa de uma famlia de processos que pode ser leve ou pesadaem artefatos, distribuves, formalidade, prescrio, cerimnia ou qualquer outra medida de pesona implementao, conforme desejado. O XP certamente leve por ser direcionado intencionalmente implementao de um processo (leve), mas as descries do XP (pelo menos nos livros) tambm no so elaboradas. Portanto, em uma implementao do XP, haver itens que precisam ser descobertos, inventados ou definidos rapidamente. Ento, comparado com o RUP, o XP tambm leve no material descritivo. Isso provavelmente ir mudar, de fato, j deve estar mudando com a publicao de outros dois livros, um dos quais, [Succi01], ter 512 pginas. No entanto, como as coisas se encontram, o perfil do esforo de adoo ser diferente entre as duas abordagens. O RUP desloca muito do esforo direto, em requisitos de treinamento e ajuste de processos. mais do que provvel que uma organizao tambm ir ajustar o RUP para aplicao em toda a organizao em tipos e tamanhos especficos de projetos e utilizar os resultados em vrios projetos. Com o XP, haver algum treinamento direto requerido, mas o restante do esforo de adoo ser espalhado atravs de um projeto, conforme ele se expande e captura todas essas coisas auxiliares que passaram a ser necessrias para que o XP funcione. O XP obviamente no motiva a captura de memria corporativa, deixando uma organizao de adoo (se ela no salvar sua experincia de processo) vulnervel troca de turno da equipe. Rotular o RUP como pesado e o XP como leve sem qualificao adicional causa prejuzos obscurecendo o que cada um e o que cada pretende fazer. E, quando isso feito de uma forma pejorativa, simplesmente uma atitude sem sentido. So as implementaes deles como processos que sero pesadas ou leves e eles devem ser pesados ou leves conforme as circunstncias demandarem. O XP no tem um formato livre, tudo resulta em disciplinaele focaliza minuciosamente um aspecto especfico de desenvolvimento de software e uma forma de entregar valor e bem prescritvel sobre a forma que isso deve ser obtido. A abrangncia do RUP mais ampla e profunda, o que explica seu tamanho aparente. No entanto, no nvel micro do processo, o RUP permite e oferece ocasionalmente alternativas igualmente vlidas, o que o XP no faz; por exemplo, a prtica de programao em pares. Isso no uma crtica ao XP; simplesmente uma ilustrao de como o XP, como seu nome implica, estreitou seu foco.

25

Uma Comparao de RUP e XP

Referncias
[Beck00] Extreme Programming Explained, Kent Beck, Addison-Wesley, 2000 [Beck01] Planning Extreme Programming, Kent Beck, Martin Fowler, Addison-Wesley, 2001 [Boehm00] Software Cost Estimation with COCOMO II, Barry W. Boehm et al, Prentice Hall PTR, 2000 [Fowler99] Refactoring: Improving the Design of Existing Code, Martin Fowler et al, Addison-Wesley, 1999 [Jeffries01] Extreme Programming Installed, Ron Jeffries, Ann Anderson, Chet Hendrickson, Addison-Wesley, 2001 [Kruchten00] The Rational Unified Process, An Introduction, Second Edition, Philippe Kruchten, Addison-Wesley, 2000 [Martin01] Extreme Programming in Practice, Robert C. Martin, James W. Newkirk, Addison-Wesley, 2001 (ainda no publicado) [Nosek98] The Case for Collaborative Programming, John T. Nosek, Comm. ACM, Vol. 41, No. 3, 1998, pp. 105108 [Succi01] Extreme Programming Examined, Giancarlo Succi, Michele Marchesi, Addison-Wesley, 2001 (ainda no publicado) [Williams00] Strengthening the Case for Pair Programming, Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries, IEEE Software, Vol. 17, No. 4, 2000, pp. 19-25

26

Duas Sedes: Rational Software 18880 Homestead Road Cupertino, CA 95014 Tel: (408) 863-9900 Rational Software 20 Maguire Road Lexington, MA 02421 Tel: (781) 676-2400 Sem custo: (800) 728-1212 E-mail: info@[Link] Web: [Link] Localizao Internacional:[Link]/worldwide Rational, o logotipo Rational e Rational Unified Process so marcas registradas da Rational Software Corporation nos Estados Unidos e/ou outros pases. Microsoft, Microsoft Windows, Microsoft Visual Studio, Microsoft Word, Microsoft Project, Visual C++ e Visual Basic so marcas ou marcas registradas da Microsoft Corporation. Todos os outros nomes so usados apenas para fins de identificao e so marcas ou marcas registradas de suas respectivas empresas. TODOS OS DIREITOS RESERVADOS. Feito nos EUA. Copyright 2002 Rational Software Corporation. Sujeito mudanas sem aviso prvio.

Field Code Changed Field Code Changed Field Code Changed