DESENVOLVIMENTO DE SISTEMAS COM EXTREME PROGRAMMING E RUP

Gerenciando projetos de desenvolvimento de software

Leonardo Willrich1

Cesar Griebeler2

Resumo

Este artigo se propõem a fazer uma abordagem do gerenciamento de projeto no desenvolvimento de softwares utilizando as metodologias Rational Unified Process (RUP) e Extreme Programming (XP), avaliando se é possível a utilização de boas práticas conforme descrito no Project Management Book of Knolodge (PMBoK). Também é feita uma abordagem sobre a aderência da forma de gerenciar de cada metodologia aos processos do Capability Maturity Model Integration (CMMI).

Palavras-chaves: Rational Unified Process (RUP). Extreme Programming (XP). PMBoK. CMMI.

1 INTRODUÇÃO

Atualmente existe duas vertentes dentro da engenharia de software de metodologias para desenvolvimento de sistemas, uma vertente são metodologias tradicionais, também chamadas de pesada ou rigorosas. Uma das metodologias mais conhecidas dessas tradicionais é a Rational Unified Process – RUP, na qual atualmente é mantida pela empresa IBM. Outra vertente que está emergente é a de metodologias ágeis, onde podemos citar a Extreme Programming sendo uma dessas metodologias que tem ganhado destaque nos últimos anos.

Ambas as metodologias, RUP e Extreme Programming, tem o mesmo objetivo, atender necessidades da área de desenvolvimento de softwares. Porém cada uma possui uma particularidade e atende ou foca melhor em determinados requisitos. Dessa forma, acaba deixando de atender outros requisitos. Podemos assim chamar de pontos fortes e fracos de cada metodologia.

Segundo Larman (2004), a Engenharia de Software é uma busca continua de melhorias no processo de desenvolvimento de software. Cada vez mais os prazos e custos tem se tornado uma restrição inalcançável, mesmo com a evolução de recursos, novas tecnologias e métodos. E um dos principais motivos para isso é a excessiva formalidade nos modelos de processos colocados nos últimos 30 anos, através das metodologias pesadas ou rigorosas.

Por esse motivo, as metodologias ágeis têm ganhado cada vez mais espaço e destaque dentro do cenário de desenvolvimento de software. Recentemente o PMI (Project Management Institute) publicou a primeira certificação em gerenciamento ágeis, isso demonstra o crescimento de profissionais em busca de qualificações, maiores informações podem ser obtidas através do site http://www.pmi.org/agile.aspx. Mas embora em alta,

1 MBA Gerenciamento de Projetos. E-mail: leokari14@hotmail.com2 Mestre em Ciências da Computação. E-mail: cesar@senior.com.br

também possuem seus pontos fracos, ainda existem casos que a opção pela metodologia tradicional ainda é a melhor escolha, principalmente quando requisitos do sistema são complexos, estáveis e previsíveis.

A grande questão é como fica o gerenciamento do projeto considerando essas duas metodologias de software. Será que é possível gerenciar projetos da mesma maneira, sem que aja um impacto nos processos de gerenciamento. Muitas empresas tem se apoiado no guia de boas práticas de gerenciamento de projeto baseada no PMBoK, mantido pelo PMI. Com isso, porém, fica a dúvida se para desenvolver sistemas com a metodologia Extreme Programming é necessário ou possível apoiar-se nos processos sugeridos pelo PMBoK.

Nas próximas seções teremos um embasamento teórico desses assuntos para finalmente chegar-se a uma conclusão do que é possível construir com essas metodologias aliadas as boas práticas de gerenciamento de projeto conforme o PMBoK. Também será avaliado a aderência dessas metodologias junto ao Capability Maturity Model Integration (CMMI).

2 RATIONAL UNIFIED PROCESS – RUP

Os processos do IBM Rational Unified Process, conhecido como RUP, possuem uma abordagem que se caracteriza por ser iterativo voltado a casos de uso, centrado na arquitetura e riscos. Esses processos descrevem o que, quem e como deve ser realizado o desenvolvimento e a instalação de software.

Conforme Kroll e Kruchten (2003) existem três definições para o Rational Unified Process (RUP). A primeira dela é que se trata de uma metodologia que se caracteriza por ser iterativo, voltado a casos de uso e centrado na arquitetura. A segunda define como sendo um processo de engenharia de software bem definido e bem estruturado, onde se tem bem definido quem é responsável pelo o que, como as coisas devem ser feitas e quando fazê-las. Compreende também o ciclo de vida de um projeto, deixando bem claro os marcos para pontos de decisão do projeto. A terceira e última definição diz que RUP é também um produto do processo que oferece uma estrutura de processo customizável para engenharia de software. Essa adaptação tem como objetivo suportar equipes pequenas ou grandes e também técnicas de desenvolvimento diferentes, podendo ter menos ou mais disciplinadas e serem mais ou menos formais.

O RUP utiliza a Linguagem Unificada de Modelagem (UML – Unified Modeling Language), para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG e tem se tornado o padrão empresarial para a modelagem orientada a objetos. A primeira versão do RUP 5.0 surgiu em 1998 provinda da evolução de projetos anteriores, como o Rational Objectory Process que teve seu inicio em 1996. Desde então varias melhorias foram implementadas até a versão RUP 2000.

2.1 FASES DO CICLO DE VIDA DO RUP

Existem quatro fases no ciclo de desenvolvimento da metodologia RUP, cada uma possui marcos de finalização, também chamados de milestones. Os milestones são utilizados como indicadores de progresso do projeto e são usados durante o projeto como base de decisões para continuar, abortar ou mudar o rumo do projeto. Essas quatro fases do RUP são:

1. Inception (Início): Tem como objetivo conceber o escopo do desenvolvimento, levando-se em conta a visão do produto final utilizando-se a definições de casos de uso.

2. Elaboration (Elaboração): Nessa fase é realizado o planejamento das atividades e recursos necessários. Deve-se focar nos riscos técnicos e arquiteturais, revisar-se o escopo e compreender bem os requisitos.

3. Construction (Construção): Essa fase é a que consome mais esforço durante o projeto, normalmente é executada em mais de uma iteração em projetos grandes. Aqui começam-se a implementação do software através da construção do código. Toda atenção é voltada aos riscos “lógicos”.

4. Transition (Transição): Nessa fase acontece o envolvimento com os usuários, geralmente através de treinamentos e versões betas. Os riscos nessa fase estão associados a logística de distribuição do produto para a base dos usuários.

2.2 OS ELEMENTOS DO RUP

Conforme Luiz (2005), a metodologia RUP possui cinco elementos, são eles: atividades, papéis, disciplinas, artefatos e fluxo de trabalho. Papel é responsável por definir a responsabilidade e comportamento de um indivíduo ou grupo dentro do trabalho de equipe. Pode-se citar como exemplo de papeis o analista de sistema e o projetista. Atividade é uma unidade de trabalho onde é executada por um individuo quando está exercendo um determinado papel com a finalidade de produzir um resultado. Artefatos são produtos do projeto e é um pedaço de informação criado, modificado ou utilizado por um processo. O fluxo de trabalho é o seqüenciamento das atividades para que possam ser produzidos artefatos de valor para o projeto. E por fim, uma disciplina é um conjunto de atividades de possuem relacionamento entre si fazendo parte de um contexto comum dentro do projeto.

A divisão de atividades por disciplinas torna o entendimento mais fácil, porém, dificulta do planejamento. Existem nove disciplinas, que são classificadas em disciplinas do processo e de suporte. De processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente.

A figura abaixo demonstra de forma ilustrada a iteração entre as fases, iterações de disciplinas.

Figura 1: Arquitetura geral do RUPFonte: Luiz (2005)

3 EXTREME PROGRAMMING

Conforme Wells (2011), Extreme Programming é uma metodologia ágil de desenvolvimento com objetivo na satisfação do cliente e de entregar somente o software como o cliente precisa, nem com requisitos a mais e nem a menos. Para isso, é essencial o feedback constante de todo time, gerente e cliente, fazendo com que o nível de comunicação seja alto. Para entregar o que foi somente pedido é necessário simplicidade, sem pensar muito em arquiteturas complexas e grandes soluções complexas. E, para conduzir projetos dessa forma, é preciso principalmente de coragem.

Com isso, surgem os valores pregados pelo XP, que são: feedback, comunicação, simplicidade e coragem. Com base nesses valores é que os processos são concebidos e que acontece o desenvolvimento de software.

Uma das características importante do XP é que não existe um planejamento integral do projeto, somente se planeja o que vai ser desenvolvido nas próximas semanas. Essa prática é conhecida como desenvolvimento incremental. Com isso a metodologia força a envolver o time do projeto, gerente e cliente no trabalho, formando um grande time colaborativo no qual todos são responsáveis pelo trabalho. O coração do planejamento são os user stories. Estes por sua vez podem ser impressos ou escritos a mão em cartões, servem para o time ter uma visão clara e estruturada dos objetivos do ciclo. Assim, pode-se rapidamente definir o escopo e planejar o projeto manipulando estes cartões através de um exercício iterativo com o time.

Abaixo se pode observar os ciclos do planejamento e codificação do software, baseado num dos valores do XP, o feedback.

Figura 2: Planejamento e feedbacksFonte: Wells, 2011

Segundo Wells (2011), esta metodologia deve ser usada em casos onde os requisitos não são estáveis e mudam a todo instante, ou seja, o cliente não tem uma idéia firme do que quer fazer. Por isso nesse ambiente os valores de XP se adaptam bem e conseguem se mostrar como um diferencial. É recomendado para um grupo de pequenos de desenvolvedores, sendo este de 2 a 12, embora se tenha conhecimento que projetos com mais de 30 desenvolvedores tenham obtido sucesso utilizando a metodologia XP.

Com finalidade de tornar todo desenvolvimento e gerenciamento do projeto de forma ágil, XP adota algumas práticas, algumas delas são: cliente presente, jogo do planejamento, stand up meeting, programação em par, desenvolvimento guiado pelos testes, refactoring, código coletivo e padronizado e design simples.

Alguns comentários sobre essas práticas conforme Gomes (2008):

“A prática de cliente presente ajuda bastante o desenvolvimento do sistema. Entretanto, há um ponto ótimo nesta questão. Nenhum programador gostaria ter que mudar um campo de lugar toda vez que o cliente sentar ao seu lado.”

“O stand up meeting é uma ótima prática, não? Alguém já ficou numa reunião que durou 4 horas e não resolveu coisa alguma? Ou também em uma reunião tão longa que o assunto poderia ser resolvido em 20 minutos! Isso impacta na produtividade da equipe!”

“A programação em par é interessante, pois um programador dá opinião no código do outro. Assim, o resultado é um código mais discutido e mais otimizado. O problema aqui é o custo. Remunerar dois programadores para fazer o trabalho de um é oneroso! Mesmo que o código saia com uma qualidade muito superior, teoricamente, uma pessoa já deveria construir um código otimizado.”

Outra característica importante de citar é a relação do impacto do custo das mudanças num projeto utilizando-se a metodologia XP. Ao contrário das metodologias tradicionais, que quanto mais tarde se solicita uma mudança, mais impacto no custo ela tem, as metodologias ágeis mitigam esse risco trazendo o feedback constante do cliente para próximo da equipe e solicitações de mudanças acontecem mais cedo. Essa característica pode se demonstrada através das ilustrações abaixo.

Metodologias tradicionais Metodologias ágeisFigura 3: Comparação do custo de mudanças

Fonte: Adaptado de Gomes (2008)

4 GERENCIANDO PROJETOS COM PMBoK

Conforme PMI (2008), o gerenciamento de projetos se dá em 5 grupos de processos que estão divididos em 9 áreas do conhecimento totalizando 42 processos. Os grupos de processo são focados no ciclo de vida do projeto, são eles: iniciação, planejamento, execução, controle e monitoramento e por fim encerramento. As áreas abordadas são: escopo, tempo, custo, qualidade, recursos humanos, comunicação, riscos, aquisições e integração. As fases do projeto são iterativas e normalmente o planejamento é em ondas (wave planning). A ilustração abaixo demonstra essa iteração entre os projetos.

Figura 4: Grupos de processosFonte: D´AVILA (2010)

Cada processo é dividido em três partes, que são as entradas, as ferramentas e técnicas e saídas. As entradas são todos os subsídios que são necessários para produzir o produto do processo através das ferramentas e técnicas de cada processo. Normalmente, pelo fato desses processos serem interligados entre si, saídas de alguns processos são entradas para outros. Na ilustração abaixo pode-se ver a iteração de todos processos, por área de conhecimento, conforme quarta edição publicada do PMBoK em 2008.

Figura 5: Processos PMBoK quarta ediçãoFonte: D´AVILA (2010)

5 COMPARANDO XP E RUP E SUAS APLICAÇÕES

Pode-se dizer que em projeto pequenos a relação ao tempo total necessário para o desenvolvimento do software é praticamente o mesmo entre as duas metodologias e que cada versão produzida pelo XP equivale-se a uma iteração do RUP. Em equipes grandes, quando aplica-se RUP, todo trabalho é dividido em subsistemas dentro de equipes divididas e a programação ocorre paralelamente. Já com XP, a programação ocorre em pares e não existe a divisão do trabalho em subsistemas (Moreira, 2011).

Outra diferença bastante notável entre XP e RUP, conforme cita Moreira (2011), é a forma de comunicação. RUP baseia-se principalmente em artefatos que são produzidos, modificados e usados por processos. Já no XP tem-se a comunicação direta, via oral, sem nenhum tipo de formalização. Isso restringe XP com relação a times virtuais, que estão em posições diferentes geograficamente. Por isso quando se utiliza XP é extremamente necessário que se tenha confiança mutua entre as partes, caso contrário, com esse tipo de comunicação tente-se a repudiar as informações e a distorcer os fatos.

De acordo com a tabela 1 pode-se observar as principais diferenças dentre XP e RUP considerando-se as principais práticas ou conceitos das metodologias. Desse forma pode-se claramente visualizar que cada uma possui pontos fortes e fracos, enquanto o foco do RUP são projetos complexos, onde é necessário um maior controle e formalização, XP possui seu foco em projetos mais simples, no qual busca-se obter ganho de tempo evitando uma formalização exagerada que gera uma burocracia desnecessária.

Prática ou conceito RUP XPIterativo e incremental SIM SIM

Voltado para a arquitetura SIM NÃO

Voltado para a validação NÃO SIM

Interação desenvolvedor/cliente NÃO SIM

Interação desenvolvedor/gerente SIM NÃO

Interação desenvolvedor/suporte SIM SIM

Gerenciamento de risco SIM SIM

Qualidade de código NÃO SIM

Gerenciamento dos pontos-chave SIM NÃO

Equipes grandes SIM NÃO

Equipes pequenas NÃO SIM

Projetos complexos SIM NÃO

Casos de uso SIM SIM

Tabela 1: Comparativo entre XP e RUPFonte: adaptado de Moreira (2011).

6 CONSIDERAÇÕES FINAIS

Estas metodologias, tanto a tradicional como ágil, exigem realizar esforço de gerenciamento do projeto. Embora o RUP aponte alguns processos nesse sentido, ele ainda é carente no gerenciamento completo do projeto onde alguns processos não são atendidos. E quanto ao XP pode-se ver que além de ser uma forma diferenciada de desenvolver sistema também traz uma forma diferencia de gerenciamento. Pode-se dizer que no XP exige maior habilidade do gerente de projeto no quesito comunicação, pois a maior parte do projeto é integrando equipe do projeto com o cliente.

Agora, como se pode dizer que o guia de boa práticas de gerenciamento de projeto mantido pelo PMI, o PMBoK, pode auxiliar no gerenciamento utilizando essas duas metodologias de desenvolvimento. Essa é uma questão simples, visto que o PMBoK não trata-se de uma metodologia e pode-se pinçar as melhores práticas e adotar o uso de processos avulsos, sem a necessidade de seguir uma metodologia propriamente dita.

Porém, não se pode afirmar que estas metodologias são aderentes as práticas do CMMI, isso pode ser comprovado pois XP não possui um planejamento integral do projeto, visto que seu desenvolvimento é incremental. Por essa razão empresas ágeis tem dificuldade de se certificar com nível de maturidade, justamente por causa do gerenciamento do projeto.

Já o RUP, por ser uma metodologia tradicional, pode ser facilmente complementada pelas boas práticas do PMBoK a fim de se constituir uma metodologia customizada com o objetivo de atender as práticas do CMMI, por sua vezes, a possibilidade de empresas que utilizam essa metodologia se certificarem CMMI é grande. Existem muitos estudos que demonstram como complementar a disciplina de gerenciamento de projeto do RUP com o PMBoK. Um deles é demonstrado por De Campos e Lima (2011) onde cita-se essas lacunas e como podem ser preenchidas utilizando as boas práticas de gerenciamento do PMBoK. Também aponta-se as dificuldades que existe em convergir esses dois assuntos a começar pela própria estruturação, pois o RUP esta estruturado num website enquanto o PMBoK num livro.

Apesar dessa dificuldade, pode-se criar uma metodologia de desenvolvimento de software, tradicional, capaz de ser aderente as práticas do CMMI.

Segundo Gomes (2008), o XP e o PMBoK são completamente opostos, com focos diferentes, mas podem se complementar a fim de criar-se uma metodologia adaptada que assegura alguns pontos fracos do XP, entre eles a documentação do projeto. Uma das principais divergências está na priorização, o PMBoK prioriza o escopo em primeiro lugar, para depois planejar o tempo, já XP prioriza primeiro o tempo.

Considerando que é possível a criação de uma metodologia com base no XP, aprofundando-se nos requisitos de documentação, é passível de se pensar que também é possível essa ser aderente as práticas do CMMI. Porém, é certo que a agilidade não seria a mesma, mas nada impediria de se adotar algumas práticas do PMBoK para tornar o gerenciamento mais completo e com requisitos possíveis de serem rastreados.

Pode-se então concluir que é viável a adaptação do PMBoK juntamente com as metodologias RUP ou XP para conceber uma metodologia adaptável, procurando foco no cliente ou no tempo de acordo com as prioridades da empresa, e que seja aderente as práticas do CMMI garantido a possibilidade de uma avaliação de maturidade em desenvolvimento de software.

6 REFERÊNCIAS

D'ÁVILA, Márcio. PMBOK e Gerenciamento de Projetos. Revisão 3, 4 de maio de 2010. Disponível em: < http://www.mhavila.com.br/topicos/gestao/pmbok.html >. Acesso em: 20 março 2011.

DE CAMPOS, Lídio Mauro Lima e LIMA, Alberto Sampaio. Gerenciamento de Projetos de Desenvolvimento de Software com o RUP e o PMBOK. Disponível em: <http://www.aedb.br/seget/artigos09/163_seget_2009.pdf >. Acessado em: 20 março 2011.

GOMES, Gleison Carneiro. Integrando o Extreme Programming com o PMBOK. Publicado 17 de fevereiro de 2008. Disponível em: <http://www.imasters.com.br/artigo/7958/desenvolvimento/integrando_o_extreme_programming_com_o_pmbok/>. Acessado em: 20 março 2011.

KROLL, P. e KRUCHTEN, P. (2003) “ The Rational Unified Process Made Easy: A Practitioner ' s Guide to the RUP ”, Addison Wesley

LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysisand Design and Iterative Development. 3. ed. Prentice Hall, 2004.

LUIZ, R. (2005) “Obtendo Qualidade de Software com o RUP”, TCC, Universidade deUberaba.

MOREIRA, Albert Menezes. Metodologias de desenvolvimento: um comparativo entre extreme programming e rational unified process. Disponível em: <http://albertmoreira.com.br/wp-content/conteudo/academico/Artigo%20XP%20x%20RUP%20v3.pdf>. Acesso em: 01 maio 2011.

PROJECT MANAGEMENT INSTITUTE (PMI), Guia de Conhecimentos em Gerenciamento de Projetos, Quarta Edição, Pensilvânia , 2008.

WELLS, Don. Extreme Programming: A gentle introduction. Disponível em: <http://www.extremeprogramming.org/> Acesso em: 20 março 2011.