Durante as atividades do desenvolvedores de XP no 2º ciclo foram registrados 9 erros e nas atividades de RUP 4, perfazendo um índice de 1.93 e 1.03 erros por hora de desenvolvimento, respectivamente. As atividades de desenvolvimento do 2º ciclo foram para alterar o software, corrigindo os incidentes encontrados durante a fase de testes do 1º ciclo.

Conclusão

No tocante ao tempo total necessário para o desenvolvimento, testes e entrega do produto de software, utilizando-se cada uma das metodologias observou-se que a metodologia RUP e XP apresentaram resultados praticamente equivalentes, sendo 39 e 40 horas respectivamente. A justificativa para estes resultados está no fato que mesmo dedicando um tempo considerável na metodologia RUP para a modelagem documentação, atividades que não se aplicam ao XP, a atividade de criação de scripts de testes no XP fizeram com que o resultado final fosse praticamente idêntico.

Em relação à ocorrência de erros, notou-se que nas etapas de projeto e implementação do 1º ciclo, o grupo de XP apresentou 42% a mais que o grupo de RUP. Mesmo tendo a vantagem que o custo de um erro detectado nestas fases ser inferior ao que detectado pela equipe de testes ou até mesmo no cliente, o que chama atenção é o fato da quantidade de erros produzidos pela equipe XP. Estes dados poderiam ser vistos por uma outra ótica, que devido aos scripts de testes feitos pelos desenvolvedores XP antes da implementação definitiva a quantidade de erros detectados nesta etapa seria maior que a do RUP, mas esta visão não se confirmou devido estas proporções de erros terem se mantido na etapa dos testes de aceitação realizados pela equipe de testes.

Comparando-se a aplicação das duas metodologias, identificou-se que a XP obteve um maior custo/benefício, tendo como base que os esforços de tempo necessário para o desenvolvimento e teste foram praticamente os mesmos e produziram um resultado final de menor qualidade, devido aos erros serem em maior quantidade que no RUP. Uma prova disso é a quantidade de erros por linhas de código. Além da equipe RUP conseguir um código mais enxuto, com menor número de linhas, o índice de erros por linha obtido por eles foi aproximadamente três vezes menor se comparado ao da equipe de XP.

Não é prudente e nem possível efetuar uma conclusão genérica, e sim, afirmar que neste caso, sob estas condições de parâmetros variáveis e escopo apresentado do projeto, obteve-se melhor resultado com a aplicação das técnicas e práticas sugeridas pelo RUP.

• Programming – Simple design (projeto simples), testing (testes), refactoring(reconstrução), coding standars(código padrão)

• Team – Collective ownership (código coletivo), continuous integration (integração continua), metaphor (metáfora), pair programming (programação em par), small releases (versões pequenas)

• Process – On-site customer (cliente no local), testing (testes), small releases (versões pequenas), planning game (planejamento do jogo)

Coleta do dados

Durante o desenvolvimento das atividades dos dois grupos, a pessoa do apoio efetuava os registros dos erros conforme aconteciam.

Esses erros foram categorizados conforme a Tabela abaixo.(HUMPHREY, Watts S. - A Discipline for Software Enginnering).

Tabela de erros do grupo de XP

Tabela de erros do grupo RUP

É perceptível que o tempo de desenvolvimento das equipes foi quase equivalente, porém a quantiadade de erros encontrados na etapa para as equipes foi diferente, registrou-se um diferença de 9 erros a mais para a equipe XP.

Análise dos erros por linha de código(LOC)

Esta métrica conta todas todas as linhas de código executável, ignorando comentários no software desenvolvido.

A contagem das linhas do código fonte foi feita a partir do Software Visual Source Safe 6.0.

Atráves dos dados obtidos com contagem das linhas e os dados obtidos na análise anterior foi gerada a seguinte tabela:

O Rational Unified Process, reúne muitas das melhores práticas em desenvolvimento de software moderno e coloca a disposição dos projetos e organizações. São elas:

• Desenvolvimento iterativo de software - esta prática sugere uma aproximação iterativa e incremental da construção do software. Permite a compreensão crescente do problema por refinamentos sucessivos.

• Gerenciamento de requisitos - nesta prática o RUP descreve como extrair, organizar e documentar funcionalidades exigidas. São utilizadas nesta etapa a noção de caso de uso e cenários para capturar exigências funcionais.

• Arquitetura baseada em componentes - descreve como projetar uma arquitetura elástica e flexível, que acomode mudanças e seja intuitivamente compreensível, promovendo efetivamente a reutilização de software.

• Modelagem visual do software - o processo mostra visualmente como o modelo de software captura a estrutura e o comportamento das arquiteturas e componentes. Isto permite esconder os detalhes e escrever código usando blocos gráficos.

• Verificação da qualidade de software - nesta etapa deve ser revisada a qualidade com respeito as exigências baseadas em confiabilidade, funcionalidade, desempenho d aplicação e desempenho de sistema.

• Controle de mudanças do software - o processo descreve como controlar, rastrear e monitorar as mudanças, permitindo o sucesso do desenvolvimento da iteração.

A arquitetura do RUP apresenta-se dividida em duas dimensões, as quais refletem as duas visões em que um sistema pode ser descrito: componentes dinâmicos e componentes estáticos.

Componentes dinâmicos

Tem por dimensão o aspecto temporal e representa em termos de ciclos, fases, interações e marcos(milestones). De acordo com o RUP as fases constituem os ciclos de vida do software, sendo cada ciclo responsável por uma versão nova do produto. Estas fases são:

• • Concepção (Inception) : nesta fase será estabelecido um visão global para o sistema e a delimitação do ãmbito de projeto.
  • Elaboração (Elaboration): analise do domínio do problema, especificação das funcionalidades e o desenho da arquitetura.
  • Construção (Construction): nesta fase são desenvolvidos os componentes e as características da aplicação.
  • Transição (Transition): o propósito desta fase é disponibilizar o produto de software para a comunidade de usuário.

Componentes estáticos

Nesta dimensão são focados os aspectos estáticos do processo, descreve os termos das atividades, artefatos, participantes do processo e o fluxo de trabalho (workflow). Tem o propósito de descrever quem está fazendo o que, como e quando. O RUP é representado usando quatro elementos para modelagem: equipe, atividades, artefatos e fluxo de trabalho.

Introdução

Processos de desenvolvimento de software

• Especificação de software(Software Specification) : As funcionalidades e as restrições de operações devem ser definidas;

• Desenvolvimento de software(Software development) : As especificações reunidas do software devem ser produzidas;

• Validação do software(Software validation): O software deve ser testado e asegurado que é exatamente o que o cliente quer;
• Evolução do software(Software evolution) : O Software deve reunir as mudanças que o cliente irá precisar.

Um pouco de XP

Extreme Programming usa times integrados de programadores, clientes, e gerentes para desenvolver software d alta qualidade em velocidade alta. Reúne também um conjunto de práticas de desenvolvimento de software já testadas, que estimuladas a sinergia entre elas gerarão vastas melhorias em produtividade global e satisfação do cliente. (HAYES, 2001)

Extreme Programming é uma disciplina de desenvolvimento de software baseada nos valores simplicidade, comunicação, realimentação, e coragem. Trabalha reunindo o time inteiro na presença de práticas simples, através do feedback permite a equipe ver onde ela está e afinar as práticas para situações únicas. (JEFRIES, 2002).

As raízes da XP estão na comunidade Smalltalk com a colaboração íntima de Kent Beck, criador da XP, e Ward Cunningham, no final da década de 1980. No início dos anos 90 os dois refinaram suas práticas em numerosos projetos, estendendo o desenvolvimento de software adaptável e orientado a pessoas.

As doze práticas promovidas pela XP se forem examinadas individualmente apresentarão falhas, mas uma das forças da XP é que as praticas se combinam de um modo mútuo apoiando-se. Juntas as práticas conduzem a um complexo, comportamento emergente. Cada prática tem sua função para manter o custo de mudança baixo. De acordo com Kent Beck as 12 práticas ão mapeadas em três categorias, a primeira englobando as práticas de programação, a segunda a práticas orientadas para a equipe e a terceira contempla os processos através dos quais a equipe de programação relaciona-se com o cliente. As práticas estão divididas nas categorias da seguinte forma:

• Programming – Simple design (projeto simples), testing (testes), refactoring(reconstrução), coding standars(código padrão)

• Team – Collective ownership (código coletivo), continuous integration (integração continua), metaphor (metáfora), pair programming (programação em par), small releases (versões pequenas)

• Process – On-site customer (cliente no local), testing (testes), small releases (versões pequenas), planning game (planejamento do jogo)

Um pouco de RUP

RUP surgiu em 1998, apesar disso contempla em suas origens idéias e experiências vividas nos últimos trinta anos, em especial abordagens seguidas na Ericson onde trabalhou Ivar Jacobson, que mais tarde juntamente com Grady Booch e James Rumbaugh, denominados de “três amigos”, começaram as iniciativas para unificação das metodologia desenvolvidas desde 1981 na Rational. O resultado foi o Rational Objectory Process que a partir de 1998 passou-se a chamar Rational Unified Process.

O Rational Unified Process é um processo de engenharia de software, que procura disciplinar a atribuições de tarefas e responsabilidades dentro de uma estrutura de desenvolvimento de software. Sua meta principal é garantir a produção de software com alta qualidade satisfazendo as necessidades dos seus usuários, dentro de um cronograma e orçamento previsível. (RATIONAL SOFTWARE CORPORATION, 2002)

O RUP é um processo configurável pois um único processo não é satisfatório para todo o desenvolvimento de software. O processo unificado ajusta-se tanto para pequenas equipes de desenvolvimento quanto para grandes organizações. CONTINUAR

Desenvolvimento de um componente de software utilizando XP e RUP.

*Esta experiência foi retirada da dissertação de mestrado de Marcos Leandro Nonemacher, intitulada “Comparação e avaliação entre o processo RUP de desenvolvimento de software e a metodologia Extreme Programming”, submetido à Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Ciência da Computação.

Esta experiência foi feita em uma empresa do Paraná composta de 8 desenvolvedores. Alguns membros da equipe foram divididos em dois grupos, o primeiro com a responsabilidade de desenvolver um componente de software utilizando XP e outro de desenvolver o mesmo componente utilizando RUP.

O componente de software que foi utilizado como base neste comparativo foi realmente solicitado por um cliente. Ambos os grupos, XP e RUP, partiram do mesmo ponto, ou seja, foram repassados aos engenheiros de software as regras de negócio, modelo de dados e os requisitos primários.

Modelagem do negócio

Controle das operações de débito, crédito e saldos de comissões de uma equipe de vendas.

O componente de software a ser desenvolvido terá a finalidade de permitir o usuário lançar valores de comissão para os vendedores cadastrados em um sistema já existente. Deverá ser considerado que já existe no sistema o recurso de cadastramento dos vendedores. O ciclo completo de desenvolvimento ficou dividido em 2 sub-ciclos ou duas iterações. No primeiro ciclo foram implementados os requisitos pelos desenvolvedores e efetuados os testes de aceitação pela equipe de XP, no segundo ciclo foram implementadas as correções pelos desenvolvedores dos erros detectados pela equipe de testes no primeiro ciclo, assim como os re-testes após as correções terem sido efetuadas.

Atividades do grupo de XP

As atividades do grupo de XP foram orientadas de acordo com as práticas recomendadas pela metodologia, as quais se dividem nas categorias de processos, programação e equipe.

Atividades do grupos de RUP

O grupo de RUP trabalhou paralelamente ao grupo XP no ciclo de vida do software, seguindo as fases de concepção (inception), elaboração (elaboration), construção (construction) e transição (transition), cada um com várias iterações. Dentro destas fases os processo também foram seguidos: os workflows de requisitos (requirements), análise e desenho (analysis and design), implementação (implementation) e testes (test).

Coleta do dados (Continua)

Bibliografia

BECK, Kent. Programação eXtrema (XP) eXplicada: Acolha as mudanças. Porto Alegre: Bookman, 2004.

NONEMACHER, Marcos Leandro - “Comparação e avaliação entre o processo RUP de desenvolvimento de software e a metodologia Extreme Programming”, submetido à Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Ciência da Computação.

PRESSMAN, R. S. Engenharia de Software, Makron Books, 1995.

RATIONAL SOFTWARE CORPORATION. Rational UInified Process http:://www.rational.com

http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/oct04/pollice/index.html

Motivação básica : aproveitar o mercado de pessoas que já conhecem RUP para introduzir técnicas de XP.

No final deste artigo tentarei fazer um "merge" dos pontos forte das duas metodologias para desenvolver sistemas, ou seja, usarei tanto aspecetos da XP quanto do RUP. O estudo comparativo deverá permitir o uso permutado dos pontos fortes dos dois processos aplicando xp ao rup e rup a xp.

Mas o que é Rational Unified Process (RUP)

O Rational Unified Process (RUP) é uma metodologia completa criada pela Rational para viabilizar que grandes projetos de software sejam bem sucedidos. O RUP é na verdade um produto composto de material de referência na forma de páginas HTML, descrevendo toda a metodologia.Fonte: http://www.rational.com

Premissas principais da XP

*melhorar a comunicação

*buscar a simplicidade

*obter feedback constante sobre o andamento

*proceder com coragem

A Comunicação, a Simplicidade, o Feedback e a Coragem são então os "valores" apregoados pela "filosofia XP".

Premissas básicas do RUP

*uso de iterações para evitar o impacto de mudanças no projeto,

*gerenciamento de mudanças e

*abordagens dos pontos de maior risco o mais cedo possível.

Ponto de vista da Rational sobre o XP

http://www.therationaledge.com/content/mar_01/f_xp_gp.html

http://www.therationaledge.com/content/apr_01/f_xp2_gp.html