RUP e XP – Uma Visão Geral

Atualmente nas empresas é necessário que se tenha algum nível de processo visando como objetivo a qualidade no desenvolvimento de software. Os processos Rational Unified Process (RUP) e eXtreme Programming (XP) são ferramentas muito conhecidas e utilizadas na comunidade de desenvolvimento de software atual.

por Daniel Teófilo Vasconcelos

Atualmente nas empresas é necessário que se tenha algum nível de processo visando como objetivo a qualidade no desenvolvimento de software. Os processos Rational Unified Process (RUP) e eXtreme Programming (XP) são ferramentas muito conhecidas e utilizadas na comunidade de desenvolvimento de software atual.

O Rational Unified Process é um framework já difundido e utilizado no mercado nacional e internacional de desenvolvimento, que pode ser adaptado a vários tipos de projetos. Podem ser derivados do RUP processos para todos os tamanhos de projetos, pois este framework define uma vasta lista de papéis, artefatos, atividades e fluxos. Contudo, o Rational Unified Process é muito complexo por conter uma série de atividades, papéis e artefatos e costuma ser visto como um processo pesado e burocrático, e identificar que elementos devem ser usados em cada projeto é uma tarefa difícil.

Em contrapartida, o eXtreme Programming aparece como uma alternativa mais leve para times de tamanho pequeno e médio porte, que desenvolvem software em um contexto de requisitos vagos e rapidamente modificados. O eXtreme Programming enfatiza a codificação e os testes de códigos, e também considera uma presença constante dos clientes no desenvolvimento. Pela característica de simplicidade que esta técnica apresenta, poucos artefatos, papéis e atividades são definidos. O eXtreme Programming tem obtido reconhecimento através de sucessos alcançados por pequenos projetos em contextos de grandes mudanças de requisitos. Entretanto, a leveza deste método e o foco em código tornam outros aspectos importantes de um projeto, como a gestão de requisitos e a construção da arquitetura, que são pouco enfatizados.

Rational Unified Process (RUP)

O Rational Unified Process surgiu em 1998, entretanto, contempla as idéias e as 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 “os três amigos”, começaram as iniciativas para unificação de suas metodologias, desenvolvidas desde 1981 na Rational. O resultado foi o Rational Objectory Process que a partir de 1998 passou a se chamar Rational Unified Process, ou simplesmente RUP

O Rational Unified Process é um processo de engenharia de software que procura disciplinar as atribuições de tarefas e responsabilidades dentro de uma estrutura de desenvolvimento coerente e coesa. 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.

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

• Desenvolvimento iterativo de software – é a realização do software em várias iterações, identificando riscos para o projeto, desenvolvendo soluções para os riscos selecionados e verificando a eliminação dos riscos ao fim de cada iteração;
• Gerenciamento de requisitos - descreve como extrair, organizar e documentar funcionalidades exigidas. É utilizada nesta etapa a noção de casos de uso e cenários para capturar exigências funcionais;
• Arquitetura baseada em componentes - descreve como projetar uma arquitetura flexível, que acomode mudanças e seja intuitivamente compreensível, promovendo efetivamente a reutilização de software;
• Modelagem visual do software – é a utilização de elementos gráficos e diagramas na modelagem de software, isto é, a representação dos elementos estruturais e comportamentais do sistema através de modelos visuais;
• Verificação da qualidade de software – é a constante preocupação com a qualidade dos artefatos da aplicação e o software propriamente dito. Atividades de garantia da qualidade devem ser realizadas durante o processo de desenvolvimento;
• Controle de mudanças do software – normalmente os requisitos de uma aplicação mudam e controlar as mudanças dos requisitos e do software são importantes para o sucesso do processo de desenvolvimento.

O RUP também define três importantes aspectos do processo de desenvolvimento de software, que são: o processo deve ser Guiado pelos Casos de Uso, Centrado na Arquitetura, e Iterativo e Incremental.

Guiado por Casos de Uso - Um software é construído para servir aos usuários. Desta forma, para se construir um software de sucesso, os analistas devem descobrir e atender aos requisitos dos usuários através das funcionalidades do sistema.

Centrado na Arquitetura - A arquitetura de sistema é utilizada pelo RUP como um artefato primário para provar conceitos, construir e evoluir o sistema em desenvolvimento.

O papel da arquitetura é fornecer uma visão geral do sistema antes da construção propriamente dita. A arquitetura envolve os aspectos dinâmicos e estáticos mais importantes da aplicação e é desenvolvida principalmente a partir de requisitos definidos pelos usuários nos casos de uso, mas sofrem fortes influências de vários outros fatores, como: plataformas (arquitetura dos computadores, sistemas operacionais, protocolos de comunicação, etc.), componentes reutilizáveis, sistemas legados, requisitos não funcionais, dentre outros.

A arquitetura é descrita através de diferentes visões do sistema: a visão de lógica, a visão de implementação, a visão de processo, a visão de implantação e a visão de caso de uso. Porém, estas visões apresentam somente os elementos que são importantes para a aplicação, os outros detalhes são simplesmente omitidos.

Iterativo e Incremental - Desenvolver um software é uma grande empreitada que pode demorar meses ou anos. É prático dividir o trabalho em partes menores ou mini-projetos. Cada mini-projeto é uma iteração que resulta em um incremento, ou seja, é a repetição de um conjunto de atividades que gera um acréscimo de funcionalidade ao sistema. Entretanto, nem todo incremento é aditivo em termos de funcionalidade, ele pode simplesmente substituir um projeto superficial por um mais detalhado.

As principais características do desenvolvimento iterativo são: resolução dos principais riscos antes da realização de grandes investimentos, permitindo o feeback do usuário desde cedo, e realização da integração e do teste de forma continua, tornando possível a disponibilização de implementações parciais.

Como vantagens do desenvolvimento iterativo e incremental, têm-se que os riscos mais comprometedores são atacados primeiro e que, em casos de falhas, o sistema pode ser interrompido nas fases iniciais sem uma grande perda de tempo e investimento; e que uma porção do sistema pode ser desenvolvida e entregue enquanto uma outra parte do mesmo ainda está em desenvolvimento.

O ciclo de vida do RUP apresenta-se dividido em duas dimensões, as quais refletem as duas visões em que um sistema pode ser descrito: componentes dinâmicos, que representam o tempo e mostram os aspectos dinâmicos, como ciclos, fases, iterações e marcos, e componentes estáticos, que representam os aspectos estáticos, como: trabalhadores, atividades, artefatos e fluxos.

Componentes Estáticos

Um processo deve descrever “quem” está fazendo “o que”, “como” e “quando”. No RUP, o “quem” é representado pelos papéis que as pessoas assumem no processo. Estes papéis definem o comportamento e as responsabilidades de um indivíduo ou de um grupo de indivíduos. O “como” é representado pelas atividades. As atividades são unidades de trabalho que um indivíduo em um papel deve realizar. O “o que” é representado pelos artefatos e estes são os produtos tangíveis do projeto, por exemplo: modelos, diagramas e documentos. O “quando” é representado pelos fluxos. Os fluxos são seqüências significativas de atividades que produzem algum resultado de valor.

Um trabalhador define o comportamento e as responsabilidades de um indivíduo ou grupo de indivíduos que trabalham juntos como uma equipe. No RUP, o termo trabalhador se refere aos papeis que definem como os indivíduos deveriam fazer o trabalho.

Uma atividade é uma unidade de trabalho que o indivíduo naquele papel pode ser pedido a desempenhar, e isso produz um resultado significante no contexto de projeto. A atividade tem um propósito claro expresso em termos de criar ou atualizar artefatos.

As atividades têm artefatos de entrada e saída. Um artefato é um produto que é produzido, modificado ou usado durante um projeto. Os artefatos são usados como entrada por trabalhadores para desempenhar uma atividade e são o resultado ou a saída de tais atividades.

Já o fluxo vem a ser uma seqüência de atividades que produz um resultado de valor observável.

Componentes Dinâmicos

O eixo dinâmico representa o tempo. Ele é constituído de ciclos, fases, iterações e marcos. Um ciclo representa todo o desenvolvimento de uma versão de um produto. Cada ciclo é dividido em fases consecutivas. As fases são momentos dentro de um ciclo de desenvolvimento do produto e, quando finalizadas, elas não são mais retornadas.

O processo iterativo do Rational Unified Process é organizado em fases que, diferentemente das etapas do ciclo de vida em cascata, não representam a análise de requisitos, projeto, codificação, integração e teste. São quatro as fases do Rational Unified Process: Iniciação, Elaboração, Construção e Transição.

A fase de Iniciação visa delimitar o escopo do projeto e estudar a viabilidade do desenvolvimento.

A fase Elaboração consiste em planejar o projeto, especificar as características e construir a arquitetura base.

Já a fase Construção consiste na construção propriamente dita ou implementação do produto.

A fase Transição consiste na entrega do produto.

Dentro de cada fase, iterações podem ocorrer. Cada iteração segue um padrão muito parecido com a abordagem em cascata, seu fluxo contém as atividades da extração de requisitos, analise, projeto e implementação, integração e teste.

Os Marcos são pontos no tempo nos quais certas decisões críticas devem ser tomadas e que os objetivos-chave planejados devem ter sido alcançados.

eXtreme Programming (XP)

As raízes da técnica eXtreme Programming estão na comunidade Smalltalk, com a colaboração íntima de Kent Beck, criador da Extreme Programming, 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.

A eXtreme Programming se concentra basicamente na criação de um software de alta qualidade e abandona todo tipo de processo supérfluo que não suporte diretamente esse objetivo. A eXtreme Programming contraria o paradigma do processo prescritivo que define “livros de receita” procedimentais para criar os sistemas. Ela é muito diferente das outras metodologias mais tradicionais, pois afirma que se suas práticas forem adotadas, se o trabalho for realizado junto com os clientes, e se a concentração de esforços for no que realmente é importante, então a equipe será vencedora no jogo do desenvolvimento de software.

Seja qual for o tamanho do projeto, é necessário um planejamento que vai definir o cronograma, custos e o tamanho do projeto com relação à capacidade da organização. Fazer um planejamento muito detalhado, que leva muito tempo para ser constituído, também não é muito aconselhável, pois com o passar do tempo e o aumento de conhecimento, os requisitos podem normalmente mudar. Entretanto, deve-se fazer um planejamento mínimo para se saber para onde se vai e que objetivos devem ser alcançados. Como se deve realizar um planejamento mínimo, o mais ideal é que o cliente esteja fazendo parte desse planejamento e tome decisões sobre os negócios e os problemas que ele deve solucionar. Já em relação às questões técnicas, a equipe de desenvolvimento é quem deve tomar essas decisões.

Os itens que precisam ser decididos pelas pessoas de negócio são: escopo, prioridade, conteúdo e datas das versões.

Os itens que precisam ser decididos pela equipe de desenvolvimento são: estimativas, conseqüências das decisões, processo e programação detalhada.

Extreme Programming é uma disciplina de desenvolvimento de software baseada nos seguintes valores: simplicidade, comunicação, realimentação, e coragem. Ela 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.

As doze práticas promovidas pela eXtreme Programming, se forem examinadas individualmente, apresentarão falhas, mas uma das forças da eXtreme Programming é que as práticas 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. As 12 práticas são: Planejamento, Fases pequenas, Metáfora, Design simples, Testes, Refactoring, Programação em pares, Propriedade coletiva, Integração continua, Semana de 40horas, Cliente junto aos desenvolvedores e Padronização do código.

A filosofia no Extreme Programming é que todos venham a lucrar no projeto. No eXtreme Programming, os participantes ou jogadores se dividem em duas equipes: os clientes e os desenvolvedores. Os clientes lidam com o escopo, a prioridade e o conteúdo do release, e a equipe do desenvolvimento lhes fornece as estimativas, conseqüências das decisões, o processo de desenvolvimento de software e as versões.

A equipe do cliente recebe as versões do sistema da equipe de desenvolvimento. A equipe de cliente pode ser especializada em uma determinada área, porém ela pode ter pouca afinidade com o computador, essa equipe resolve quais os elementos que devem ser incluídos no computador e eles também são responsáveis por testá-los.

A equipe do cliente não precisa saber linguagens de programação, nem esquemas de bancos de dados ou coisas muito técnicas, mas eles deverão ter um nível bem maior do que os usuários normais de operação, pois é preciso testar o sistema e isso tem que ser feito de forma correta. A equipe do cliente está composta assim: contadores de história, os aceitantes, os proprietários do ouro, planejadores, o chefe. A equipe de desenvolvedores está composta desta maneira: técnico, acompanhador, facilitador, arquiteto.

Os papeis na eXtreme Programming servem para orientar aquilo que deveríamos fazer, eles não são símbolos de status, por isso todo papel na eXtreme Programming é importante, isso também não quer dizer que um técnico não possa vir a ser um facilitador ou acompanhador, mas essa mudança de cargo não pode virar uma obsessão, tem-se que se deixar suas habilidades falarem pelo desenvolvedor.

O ciclo de vida de um projeto eXtreme Programming é uma das abordagens ainda muito discutidas por grupos que adotam esta metodologia. O ciclo de vida eXtreme Programming é bastante curto e, à primeira vista, difere dos padrões dos modelos de processos convencionais. No entanto, esta abordagem pode fazer sentido em um ambiente onde as mudanças de requisitos do sistema são fatores dominantes.

O ciclo de vida da XP está basicamente dividido em quatro fases, planejamento, testes, codificação e projeto. Na fase de planejamento, os requisitos do cliente são cuidadosamente coletados à medida que são fornecidos. A seguir, os testes são elaborados a partir das especificações do cliente, e a fase de codificação é realizada visando atender esses testes. E, por fim, o sistema é novamente projetado (ou reconstruído) à medida que novas funcionalidades são incorporadas.