3

Extreme Programming (XP)

Este captulo apresenta o processo gil de desenvolvimento de
software Extreme Programming (XP). A seo 3.1 apresenta uma
viso geral do captulo e a seo 3.2 uma introduo geral sobre
processos de software. A seo 3.3 explica alguns conceitos bsicos
de XP como valores e princpios. A seo 3.4 procura mostrar uma
viso geral da estrutura e dinmica de XP. A seo 3.5 descreve
quando no se deve usar XP. A seo 3.6 apresenta uma viso geral
sobre a modelagem de processos de software e a seo 3.7 mostra a
modelagem de XP usando SPEM. Finalmente, a seo 3.8 apresenta
as consideraes finais do captulo.

3.1 Viso geral

Um processo de software consiste de um conjunto de atividades realizadas para
a sua construo e manuteno. Ao longo dos ltimos anos, a crescente demanda por
software de qualidade, aliada presso em relao aos prazos de entrega fizeram com
que a eficincia de muitas tcnicas e processos tradicionalmente utilizados passasse a
ser questionada.
Diante deste contexto, os processos geis como Extreme Programming [28, 29],
passaram a atrair o interesse dos meios acadmico e industrial. Devido simplicidade e
agilidade adotada na soluo de problemas atravs do uso de eficientes prticas de
programao, as equipes que usam XP vm obtendo sucesso em seus projetos o que
vem contribuindo para o aumento da sua popularidade.
Este captulo procura apresentar Extreme Programming e sua modelagem
utilizando a linguagem SPEM [48]. So apresentados os principais conceitos relativos a
XP que so seus valores, princpios, prticas, papis e seu ciclo de vida. O final do
captulo apresenta uma viso geral de SPEM e a sua utilizao na modelagem de XP.

___________________________________________________________________ 33

3.2 Processos de software

Um processo de software pode ser definido como um conjunto de atividades
executadas para desenvolver, dar manuteno e gerenciar sistemas de software
[47,51,52,53]. Cada atividade pode ser composta de outras atividades e so realizadas
por pessoas, que possuem um determinado papel no processo como: programador,
gerente, cliente e outros. Tais pessoas podem utilizar ferramentas e modelos que
automatizem e facilitem os seus trabalhos, e medida que o processo flui, artefatos
(cdigo, documentos, modelos, diagramas, etc...) so produzidos, atualizados e
consumidos nas atividades realizadas.
Ao longo dos anos, muitos padres de processos de software foram definidos
com o objetivo de ajudar as organizaes a construrem software de uma forma
controlada. Inicialmente, tais padres tinham o objetivo de ser genricos no sentido de
procurar atender a qualquer tipo de projeto e detalhados no sentido de definir uma
grande quantidade de atividades e papis para produzir muitos artefatos e documentos
detalhados. Exemplos de padres desse tipo so os processos Rational Unified Process
(RUP) [20] e OPEN [21] que vm sendo utilizados com muito sucesso no meio
empresarial. Em [54,55] pode ser visto que estes processos so mais adequados a
empresas com equipes grandes e projetos complexos onde existe a necessidade de uma
extensa e detalhada documentao para reduo de riscos.
Recentemente, muitos pesquisadores e renomados consultores empresariais
especialistas na rea de desenvolvimento de software, passaram a questionar a eficincia
dos processos comentados acima passando a cham-los de processos pesados. Eles
afirmam que os processos pesados burocratizam o desenvolvimento de software
devido ao excessivo nmero de atividades e artefatos o que, na opinio deles, acaba
desviando o processo daquilo que deveria ser prioritrio - a entrega constante de
software que roda para o cliente.
Esses especialistas fundaram o que veio a se chamar de Aliana gil [57] que
tem por objetivo encontrar abordagens mais simples e eficientes para o
desenvolvimento de software. A idia desses especialistas foi publicada atravs de um

___________________________________________________________________ 34

documento chamado Manifesto para o Desenvolvimento gil de S oftware que

valoriza os seguintes itens:

Indivduos e interaes acima de processos e ferramentas.

Software funcionado acima de documentao abrangente.

Colaborao com o cliente acima de negociao de contratos.

Responder a mudanas acima de seguir um plano.

Isso no quer dizer que esse manifesto no considere os itens direita

importantes, mas sim, que os itens esquerda so considerados de maior valor.
Portanto, os processos geis, como Extreme Programming (XP) [28,29], DSDM [23],
Crystal [24] e outros, focam-se em entrega constante de funcionalidade e interao
constante entre os membros da equipe e clientes [28,29,54,55]. Estes processos vm se
mostrando eficientes em projetos onde os requisitos so constantemente modificados, os
ciclos de desenvolvimento so curtos e as equipes que implementam o projeto so
pequenas [54,55,56].
Ambos os grupos de processos (geis e pesados) possuem vantagens e
desvantagens. Cada grupo pode ser mais adequado para determinados tipos de projeto,
dependendo de fatores como: natureza e complexidade da aplicao a ser construda;
tamanho e distribuio da equipe; e restries de prazo e custo impostas pelo cliente.
A descrio detalhada de XP ser vista ao longo de todo este captulo que
tambm far uma anlise dos principais defeitos e virtudes de XP em relao ao
desenvolvimento de aplicaes Web, bem como apresentar a justificativa pela sua
escolha. Na prxima seo sero apresentados alguns conceitos bsicos de XP.

3.3 Conceitos bsicos de XP

O processo gil eXtreme Programming (XP) resultou da experincia no projeto
C3 Payroll na empresa Chrysler. Este projeto consistia da implementao de um sistema

___________________________________________________________________ 35

de folha de pagamento que j havia fracassado anteriormente utilizando outras

metodologias. Aps o sucesso nesse projeto, XP comeou a despontar no meio
acadmico e empresarial e se tornou alvo de inmeras pesquisas e discusses, alm de
ser adotado em diversas empresas de software do mundo inteiro e apoiado por grandes
gurus da orientao a objeto como Kent Beck, Ron Jeffr ies, Martin Fowler e Grady
Booch.
O sucesso e popularidade adquiridos por XP se devem principalmente aos
relatos de bons resultados obtidos em projetos, a motivao dos profissionais
envolvidos com XP e tambm devido a sua natureza simples e objetiva por se basear em
prticas que j provaram sua eficincia no cenrio do desenvolvimento de software.
Essas prticas tm como objetivo entregar funcionalidades de forma rpida e eficiente
ao cliente. Alm disso, XP foi criado considerando que mudanas so inevitveis e que
devem ser incorporadas constantemente. XP se baseia em alguns valores e princpios
que sero mostrados na prxima seo.

3.3.1 Valores e Princpios de XP

Extreme Programming (XP) um processo de desenvolvimento de software que
adota os valores de comunicao, simplicidade, feedback e coragem [28,29]. Estes
quatro valores servem como critrios que norteiam as pessoas envolvidas no
desenvolvimento de software e sero detalhados a seguir.
Comunicao: XP foca em construir um entendimento pessoa-a-pessoa do
problema, com o uso mnimo de documentao formal e com o uso mximo de
interao cara -a-cara entre as pessoas envolvidas no projeto. As prticas de XP como
programao em pares, testes e comunicao com o cliente tm o objetivo de estimular
a comunicao entre gerentes, programadores e clientes.
Simplicidade: XP sugere que cada membro da equipe adote a soluo mais fcil
que possa funcionar. O objetivo fazer aquilo que mais simples hoje e criar um
ambiente em que o custo de mudanas no futuro seja baixo. O objetivo dessa
abordagem adotada por XP evitar a construo antecipada de funcionalidades, como

___________________________________________________________________ 36

feita em muitas metodologias tradicionais, que acabam muitas vezes nem sendo usadas.
Feedback: Os programadores obtm feedback sobre a lgica dos programas
escrevendo e executando casos de teste. Os clientes obtm feedback atravs dos testes
funcionais criados para todas as estrias (casos de uso simplificados). O feedback
importante, pois possibilita que as pessoas aprendam cada vez mais sobre o sistema e
assim corrijam os erros e melhorem o sistema.
Coragem: Ela necessria para que realmente se aplique XP como deve ser
aplicado. Exemplos de atitude que exigem coragem so: alterar cdigo j escrito e que
est funcionando; jogar cdigo fora e reescrever tudo de novo; e permitir cdigo
compartilhado por todos. Estes exemplos de atitudes podem ser necessrios para trazer
melhorias ao projeto e no devem ser evitadas simplesmente devido ao medo de tentlas.
Alm dos valores apresentados anteriormente XP define um conjunto de
princpios que devem ser seguidos por equipes que forem usar XP em projetos. Os
princpios serviro para ajudar na escolha de alternativas de soluo de problemas
durante o curso do projeto. Deve-se preferir uma alternativa que atenda aos princpios
de uma forma mais completa do que outra que seja incompleta, ou seja, que esteja mais
longe da filosofia de XP. Os princpios fundamentais so: feedback rpido, assumir
simplicidade, mudana incremental, abraando mudanas e trabalho de qualidade.
Feedback rpido: A idia de XP que os participantes de um projeto como
clientes, programadores e gerentes devem estar sempre se comunicando para facilitar o
aprendizado coletivo sobre o projeto que est sendo desenvolvido e de alertar
rapidamente sobre dvidas, riscos e problemas para facilitar eventuais aes de
contingncia.
Assumir simplicidade: Todo problema deve ser tratado para ser resolvido da
forma mais simples possvel. XP afirma que se deve fazer um bom trabalho (testes,
refactoring, comunicao) para resolver hoje os problemas de hoje e confiar na sua
habilidade de adicionar complexidade no futuro quando for necessrio.

___________________________________________________________________ 37

Mudana incremental: Quando muitas mudanas so realizadas todas de uma

vez, no se obtm um bom resultado. Em vez disso, esse princpio de XP diz que as
mudanas devem ser incrementais e feitas aos poucos. Os programadores tm a
liberdade para estar sempre fazendo alteraes de melhoria no cdigo e as mudanas de
requisitos so incorporadas de forma incremental.
Abraando mudanas (Embracing Change): XP procura facilitar o ato de
incluir alteraes atravs do uso de vrios princpios e prticas. A idia de XP a de que
mudanas devem ser sempre bem vindas independentemente do estgio de evoluo do
projeto. Isso muito benfico em projetos cujos requisitos so bastante volteis devido
aos clientes no saberem o que querem.
Trabalho de qualidade: Em XP, qualidade no um critrio opcional, mas sim
obrigatrio. Embora a definio de qualidade possa variar de pessoa para pessoa, XP
trata qualidade no sentido de se ter um sistema que atenda aos requisitos do cliente, que
rode 100% dos casos de teste e que agregue o maior valor possvel para o negcio do
cliente.

3.4 Viso geral de XP

Esta seo baseia-se nas fontes de informao apresentadas em [28,29], e
procura mostrar a estrutura principal e o funcionamento do processo Extreme
Programming. A subseo 3.4.1 mostra as prticas que constituem a estrutura de XP. A
subseo 3.4.2 mostra o ciclo de vida de um projeto XP. Finalmente, a subseo 3.4.3
descreve a gerncia de projetos e os principais papis envolvidos em um projeto XP.

3.4.1 Prticas de XP
Extreme Programming possui doze prticas que consistem no ncleo principal
do processo e que foram criadas com base nos ideais pregados pelos valores e princpios
apresentados anteriormente na seo 3.3.1. Segundo um dos criadores de XP, Kent

___________________________________________________________________ 38

Beck, estas prticas no so novidades, mas sim prticas que j vm sendo utilizadas a
muitos anos, com eficincia, em projetos de software. Muitas das prticas de XP no
so unanimidades dentro da comunidade de desenvolvimento de software, como por
exemplo, programao em pares. No entanto, o valor e benefcios de tais prticas devem
ser avaliados em conjunto e no individualmente, pois elas foram criadas para serem
usadas coletivamente, de forma a reduzir as fraquezas umas das outras. As doze prticas
de XP so comentadas abaixo.
O jogo do planejamento: O planejamento de um release e das iteraes so
feitos com base nas histrias (casos de uso simplificados) e conta com a colaborao de
toda a equipe de desenvolvimento, inclusive o cliente, divididos em dois papis:

Negcio: Participam as pessoas que mais entendem sobre o negcio e

que possam estabelecer prioridades para as funcionalidades a serem
entregues.

Tcnico: Participam as pessoas que iro implementar as funcionalidades

descritas. Os tcnicos estimam qual o esforo e riscos envolvidos para
implementar as funcionalidades e comunicam ao pessoal de negcios.

No final de um release feita uma determinao rpida do escopo do prximo,

atravs da combinao de estimativas e prioridades do negcio. Um release consiste de
vrias iteraes e, em cada iterao, vrias histrias (use case simplificados) so
implementadas. Os programadores estimam cada estria e dizem quantas eles podem
implementar no final do release. Baseado nesses dados, os clientes escolhem as
principais estrias (que agregam maior valor para o negcio) que sero implementadas.
As estimativas podem ser refeitas durante as iteraes medida que os programadores
aprenderem mais sobre o sistema.
Releases pequenos: Em [28] Beck diz: cada release deve ser to pequeno
quanto possvel, contendo os requisitos mais importantes para o negcio. Isso
possibilita ter releases freqentes o que resulta em maior feedback para clientes e
programadores, facilitando o aprendizado e a correo dos defeitos do sistema. Beck
sugere que os releases sejam de curta durao, normalmente de dois a trs meses.

___________________________________________________________________ 39

Metfora: A inteno da metfora oferecer uma viso geral do sistema, em

um formato simples, que possa ser compartilhada por clientes e programadores. A idia
da metfora que seja feita uma analogia entre o sistema que est sendo desenvolvido e
um sistema, no necessariamente de software, que todos entendam, com o objetivo de
obter um vocabulrio comum para a posterior criao de nomes de classes,
subsistemas, mtodos, etc. Um exemplo de metfora pode ser visto em [29], onde o
sistema C3 payroll de folha de pagamento descrito como uma linha de montagem
onde vrias partes referentes s horas trabalhadas vo sendo montadas at construir o
cheque de pagamento do funcionrio. A metfora conforme dito em [28] tambm pode
ser vista como uma forma simples de arquitetura do sistema, numa linguagem
compreensvel tanto por clientes como programadores.
Projeto simples: Pode-se explicar esta prtica em duas partes: A primeira diz
que devem ser projetadas as funcionalidades que j foram definidas e no as que
podero ser definidas futuramente. A segunda diz que deve ser feito o melhor projeto
que possa entregar tais funcionalidades. Esta prtica tem o intuito de enfatizar que o
projeto simples deve se concentrar em solues simples e bem estruturadas para os
problemas de hoje e que no se deve perder tempo investindo em solues genricas
que procurem atender a funcionalidades futuras, pois como os requisitos mudam
constantemente tais solues genricas podem no ser mais a realidade do futuro.
Algumas caractersticas de projeto simples citadas em [28,29] so:

Todos os testes executam com sucesso.

O projeto expressa a idia que o programador teve.

O projeto no possui lgica duplicada.

O projeto contm o menor nmero possvel de classes e mtodos.

Testes constantes: Os testes em XP so feitos antes da programao. Existem

dois tipos de teste: teste de unidade e teste funcional. Os testes de unidade so feitos
para verificar tudo que possa dar errado. No preciso escrever testes de unidade para
todos os mtodos, conforme mencionado em [28-30]. Os testes unitrios so
automatizados, e toda vez que o programador escrever cdigo, ele ir verificar se o

___________________________________________________________________ 40

sistema passa em todos os testes. Os testes funcionais so usados para verificao, junto
ao cliente, do sistema como um todo. Os testes servem como um mecanismo para
assegurar que o sistema est sempre rodando livre de erros, e tambm servem para dar
feedback aos programadores e clientes sobre as falhas encontradas.
Refatoramento: So constantes melhorias no projeto do software para aumentar
sua capacidade de se adaptar a mudanas. O refatoramento consiste em aplicar uma
srie de passos, como mostrado em [31], para melhorar o projeto do cdigo existente,
tornando-o mais simples e melhor estruturado, sem alterar sua funcionalidade.
Programao em pares: Todo o cdigo produzido em XP escrito por um par
de programadores, que possuem papis distintos, sentados lado-a-lado e olhando para o
computador. Um parceiro ser responsvel pela codificao e pensar nos algoritmos e
na lgica de programao. O outro parceiro observa o cdigo produzido e tenta pensar
mais estrategicamente em como melhor-lo e torn-lo mais simples, alm de apontar
possveis erros e pontos de falha. Alm disso, as duplas so constantemente trocadas e
os papis tambm com o objetivo de que todos os membros da equipe possam ter
conhecimento sobre todas as partes do sistema.
Propriedade coletiva do cdigo: A programao em pares encoraja duas
pessoas a trabalharem juntas procurando atingir o melhor resultado possvel. A
propriedade coletiva encoraja a equipe inteira a trabalhar mais unida em busca de
qualidade no cdigo fazendo melhorias e refatoramentos em qualquer parte do cdigo a
qualquer tempo. A princpio pode-se pensar que esta prtica possa gerar problemas, mas
como todos devem respeitar um padro de codificao e devem realizar todos os testes
para verificao de erros esta atividade feita de uma forma controlada e pode ser
facilitada com o uso de uma ferramenta de controle de verso.
Integrao contnua: O cdigo das funcionalidades implementadas pode ser
integrado vrias vezes ao dia. Um modo simples de fazer isso ter uma mquina
dedicada para integrao. Quando a mquina estiver livre, um par com cdigo a integrar
ocupa a mquina, carrega a verso corrente do sistema, carrega as alteraes que
fizeram (resolvendo as colises), e rodam os testes at que eles passem (100% corretos).

___________________________________________________________________ 41

O importante que na integrao as funcionalidades s podem ser integradas se no

houver erros, caso contrrio os erros devem ser corrigidos.
Semana de quarenta horas: Essa no uma regra que obriga as equipes em
projetos XP a trabalharem somente 40 horas por semana. No entanto, Beck diz que no
se deve trabalhar duas semanas seguidas alm desse tempo, pois o cansao e a
insatisfao de trabalhar horas extras pode resultar numa queda de qualidade do cdigo.
Cliente no local: Deve ser includo na equipe uma pessoa da parte do cliente,
que ir usar o sistema, para trabalhar junto com os outros e responder as perguntas e
dvidas. Mesmo que no seja possvel obter algum da parte do cliente deve-se ter
algum que tenha conhecimento suficiente do negcio para exercer este papel. O cliente
tem um papel importante dentro de um projeto XP j que ele participa do planejamento
do projeto escrevendo as histrias e priorizando-as.
Padres de codificao: Como XP prega a propriedade coletiva de cdigo,
onde todos podem alterar e fazer refatoramento de qualquer parte do cdigo a qualquer
momento, ento mais do que necessrio que se tenha padres de codificao. O
objetivo que todos programem da mesma forma, facilitando o entendimento do cdigo
e as alteraes.

3.4.2 Ciclo de vida de um projeto XP

Um projeto XP atravessa algumas fases durante o seu ciclo de vida. Essas fases
so compostas de vrias tarefas que so executadas. Abaixo ser dada uma explicao
das principais fases de um projeto XP de modo a se ter uma idia de como o projeto flui
ao longo do tempo.
Um projeto XP passa pelas seguintes fases: explorao, planejamento inicial,
iteraes do release, produo, manuteno e morte.
A fase de explorao anterior construo do sistema. Nela, investigaes de
possveis solues so feitas e verifica-se a viabilidade de tais solues. Os
programadores elaboram possveis arquiteturas e tentam visualizar como o sistema
funcionar considerando

ambiente

tecnolgico

(hardware,

rede,

software,

___________________________________________________________________ 42

performance, trfego) onde o sistema ir rodar. Com isso, os programadores e os

clientes vo ganhando confiana, e quando eles possurem estrias suficientes, j
podero comear a construir o primeiro release do sistema. Em [28] sugere-se que seja
gasto no mximo duas semanas nessa fase.
A fase de planejamento inicial deve ser usada para que os clientes concordem
em uma data para lanamento do primeiro release. O planejamento funciona da seguinte
forma: Os programadores, juntamente com o cliente, definem as estrias (use case
simplificados) a serem implementadas e as descrevem em cartes. Os programadores
assinalam uma certa dificuldade para cada estria e, baseados na sua velocidade de
implementao, dizem quantas estrias podem implementar em uma iterao. Depois,
os clientes escolhem as estrias de maior valor para serem implementadas na iterao
isso chamado planejamento de iterao. O processo ento se repete at terminar as
iteraes do release. O tempo para cada iterao deve ser de uma a trs semanas e para
cada release de dois a quatro meses.
Na fase das iteraes do release so escritos os casos de teste funcionais e de
unidade. Os programadores vo seguindo mais ou menos o seguinte fluxo de atividades
na seguinte ordem (Em cada iterao): escrita dos casos de testes; projeto e
refatoramento; codificao; realizao dos testes; e integrao. medida que esse fluxo
vai sendo seguido, o sistema vai sendo construdo segundo os princpios, valores e
prticas apresentados nas sees anteriores. Depois de terminado o primeiro release, j
se ter uma idia melhor das tecnologias e do domnio do problema de modo que as
iteraes podero ser mais curtas nos releases subseqentes e j se podem fazer
estimativas mais confiveis com o que se aprendeu das iteraes passadas.
Depois do final do primeiro release, considera-se o incio da fase de produo
onde cada release subseqente do sistema, depois de construdo, colocado para rodar
em um ambiente que simula o ambiente de produo para ver seu comportamento em
termos de performance. Pode-se fazer testes de aceitao adicionais para simular o
funcionamento real do sistema no ambiente alvo.
A fase de manuteno pode ser considerada como uma caracterstica inerente a
um projeto XP. Em XP voc est simultaneamente produzindo novas funcionalidades,

___________________________________________________________________ 43

mantendo o sistema existente rodando, incorporando novas pessoas na equipe e

melhorando o cdigo. Mecanismos como: refatoramento, introduo de novas
tecnologias, e introduo de novas idias de arquitetura podem ser utilizados em um
projeto XP. importante ressaltar que a manuteno dada em um sistema que j est em
produo deve ser feita com muita cautela, pois uma alterao errada pode paralisar o
funcionamento do sistema resultando em prejuzos para o cliente.
A fase de morte corresponde ao trmino de um projeto XP. Existem duas
razes para se chegar ao final de um projeto, uma boa e a outra ruim. A boa razo
quando o cliente j est satisfeito com o sistema existente e no enxerga nenhuma
funcionalidade que possa vir a ser implementada no futuro. A m razo para a morte em
XP seria a do projeto ter se tornado economicamente invivel, devido a dificuldades de
adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros.

3.4.3 Gerncia de projetos e papis envolvidos em XP

A estratgia de gerncia adotada em XP mais voltada para a tomada de
decises descentralizada do que para o controle centralizado. O papel do gerente fazer
fluir o jogo do planejamento, coletar mtricas, fazer com que as mtricas sejam vistas
por aqueles cujo trabalho esteja sendo medido, e ocasionalmente intervir em situaes
que no podem ser resolvidas de forma distribuda.
A ferramenta bsica de gerncia em XP a mtrica. A medida bsica que
usada durante o jogo do planejamento a razo entre o tempo estimado para
desenvolver e o tempo realmente gasto. Se esta razo aumentar (menos tempo real para
um tempo estimado dado) pode significar que a equipe est trabalhando corretamente.
Por outro lado, isso tambm pode significar que a equipe est gastando pouco tempo na
codificao e em refatoramento o que poder prejudicar a qualidade do projeto no longo
prazo. A forma usada para mostrar as mtricas deve ser um grfico atualizado
constantemente (pelo menos uma vez por semana).
A gerncia em XP dividida atravs de dois papis: o treinador (coach) e o
rastreador (tracker). Esses papis podem ou no ser executados pela mesma pessoa. O

___________________________________________________________________ 44

treinador se preocupa principalmente com a execuo tcnica e evoluo do processo.

O treinador ideal deve ser um bom comunicador, ter um bom conhecimento tcnico, no
entrar em pnico e ser confiante. O papel do treinador no de tomar decises tcnicas,
mas de fazer com que todos tomem boas decises e de facilitar o processo de
desenvolvimento.
O rastreamento outro componente da gerncia em XP. O objetivo do
rastreador (tracker) coletar mtricas sobre o que est sendo desenvolvido e
confrontar com as mtricas estimadas verificando possveis divergncias. O rastreador
deve tomar cuidado para no perturbar muito os programadores pedindo por mtricas.
Uma forma recomendada coletar os dados duas vezes por semana.
Alm dos papis gerenciais apresentados anteriormente, uma equipe que utiliza
XP para desenvolver software composta de outros papis. Estes so: programador,
cliente, testador e consultor.
O programador ocupa o principal papel em XP. Ele analisa, projeta, testa,
codifica, e integra o sistema. Alm disso, o programador estima a dificuldade das
estrias e faz alteraes nessas estimativas, caso necessrio. Em XP o foco est na
programao e o importante entregar funcionalidades implementadas para o cliente. O
programador est sempre escrevendo testes de unidade, codificando e fazendo
refatoramento com o objetivo de produzir cdigo de alta qualidade rapidamente.
O cliente escolhe o que vai agregar valor ao seu negcio, escolhe o que deve ser
feito primeiro e o que deve ser adiado. Alm disso, o cliente define com a ajuda dos
testadores, os testes funcionais que iro mostrar se o sistema realmente faz o que deve
ser feito.
O testador ir ajudar o cliente na definio e escrita dos testes funcionais. Ele
no precisa ser uma pessoa com apenas essa funo, pode desempenhar tambm o papel
de programador.
O consultor necessrio apenas em algumas situaes onde se precisa de
algum com um elevado nvel de conhecimento, por exemplo, um especialista em uma
determinada tecnologia sobre determinado assunto que no est sendo bem

___________________________________________________________________ 45

compreendido pelas pessoas do projeto. O objetivo da equipe no obter a soluo do

consultor para us-la, mas sim entender o problema e elaborar a sua prpria soluo.

3.5 Quando no se deve usar XP

Os limites exatos de XP ainda no so conhecidos, mas existem alguns fatores
que so fortes indicadores para no usar XP como [28,29]: equipes grandes, clientes
desconfiados e tecnologia que no d suporte facilitado para mudanas. Uma breve lista
de possveis barreiras para o sucesso de um projeto XP so mostradas a seguir.

Cultura: A organizao pode estar inserida dentro de uma cultura

tradicional de desenvolvimento de software, produzindo muita
documentao, gastando muito tempo com anlise e projeto antecipado,
entre outras coisas. Fazer com que a equipe passe a adotar as prticas de
XP e esquea as antigas pode ser muito difcil.

Tamanho da equipe: Um projeto XP deve possuir uma equipe pequena

geralmente at 12 programadores. difcil imaginar como ficariam
alguns conceitos de XP como comunicao, programao em par e
outras em uma equipe grande (Ex. 100 pessoas).

Tecnologia: No se deve usar XP quando uma tecnologia complicada

para escrever casos de teste, quando retorna feedback em um tempo
longo ou quando no incorpora facilmente as mudanas.

Espao fsico: A organizao do espao fsico onde a equipe de XP

trabalha deve facilitar a comunicao e deixar todos prximos uns dos
outros.

Cliente: XP exige que o cliente participe da equipe do projeto e trabalhe

no mesmo local dos demais, estando a disposio, de preferncia, o
tempo todo para esclarecer dvidas. Caso no possa ser algum da
organizao do cliente algum deve ser algum que entenda do negcio

___________________________________________________________________ 46

do cliente e que seja capacitado para exercer este papel. O cliente

tambm no precisa estar disponvel todo o tempo embora seja
prefervel.
Esta seo finaliza a descrio dos pontos mais importantes de XP, iniciada na
seo 3.3. A prxima seo procura apresentar uma viso geral sobre modelagem de
processos de software e sobre a sua necessidade dentro do contexto deste trabalho.
Alm disso, sero apresentados alguns exemplos da modelagem de XP utilizando
SPEM [48].

3.6 Modelagem de Processos de Software

Um processo de software pode ser definido como um conjunto parcialmente
ordenado de atividades realizadas para construir, gerenciar e dar manuteno em
sistemas de software [51,52,53]. Tais atividades so realizadas por pessoas que possuem
um determinado papel no processo. Durante a execuo de atividades, produtos do
processo, chamados artefatos, podem ser atualizados, consumidos ou produzidos.
Exemplos comuns de artefatos so cdigo fonte, modelos de anlise e projeto,
diagramas, documentos, manuais e outros.
Pode-se ento dizer que um processo de software se compe de diversos
elementos que se relacionam segundo algum critrio. Alguns elementos comuns a
processos de software segundo [51,52,53] so:

Agente ou ator: uma entidade que participa da execuo do processo.

Pode-se dividir os atores em dois grupos: atores humanos e atores de
sistema. Os atores humanos so as pessoas que participam do processo
enquanto que os atores de sistema so os componentes de hardware e
software que participam da execuo de uma determinada parte do
processo.

___________________________________________________________________ 47

Papel: Descreve as responsabilidades, deveres e habilidades necessrias

para realizar uma determinada atividade do processo. Um papel pode ser
composto por um grupo de agentes e um mesmo agente pode atuar em
papis distintos.

Atividade: Representa o trabalho realizado por um ou mais agentes em

um determinado ponto de execuo do processo. Os agentes agrupados
em papis realizam uma determinada atividade como responsveis ou
assistentes e podem utilizar tcnicas, modelos e ferramentas para facilitar
o seu trabalho. Alm disso, artefatos podem ser exigidos como entrada
para a realizao de uma determinada atividade ou podem ser
atualizados e produzidos como sada no trmino da atividade.

Artefato ou produto: o subproduto de um processo. Ele criado

durante a execuo do processo e pode ser modificado ao longo do
tempo apresentando diferentes verses. Existem artefatos que so criados
para facilitar o processo de construo de software e a manuteno dos
sistemas (ex: modelos de dados, diagrama de classes e outros). Nem todo
artefato entregue ao cliente ficando a critrio da empresa fornecedora
de software quais artefatos devem ou no ser descartados ao longo do
tempo.

A descrio dos elementos do processo pode ser representada atravs de um

diagrama de classes da UML como na Figura 3.1 a seguir.
R e a liz a

Pap el
1
0..*

At i v i d a d e
0..*

A s s is t e

0..*

0..*
At o r

R e a liz a

Cons ome
*

Pr o d u z
*
Ar t e f a t o

Figura 3.1 - Elementos de um processo de software

A modelagem de processos de software procura definir modelos e seus interrelacionamentos para representar os elementos que fazem parte do processo, como, por

___________________________________________________________________ 48

exemplo, na Figura 3.1. Tais modelos podem ser construdos seguindo uma determinada
linguagem de modelagem e procuram retratar uma determinada viso do processo de
software. Existem diversas linguagens, meta-modelos e ferramentas que possibilitam
modelar diversos aspectos de processos de software segundo uma viso particular. Nas
prximas sees ser discutido a importncia da modelagem de processos de software
(seo 3.6.1) bem como algumas abordagens existentes para modelagem (seo 3.6.2).

3.6.1 Importncia da modelagem de processos de software

Diversos trabalhos [51,52] tm constatado os benefcios e a importncia da
modelagem de processos de software. Dentre os principais benefcios advindos da
modelagem pode-se citar:

Facilitar o entendimento e comunicao: A modelagem do processo

permite a estruturao dos seus elementos mostrando seus interrelacionamentos e tornando mais fcil a visualizao e entendimento do
processo por parte das pessoas envolvidas.

Facilitar a gerncia e controle do processo: A modelagem pode

simplificar o trabalho da gerncia, que poder verificar de uma forma
mais fcil atravs de uma determinada viso do processo - o
andamento do processo dentro de uma seqncia de atividades a ser
seguida.

Dar suporte para a melhoria do processo: Uma vez que se tenha um

modelo para o processo, fica mais simples evoluir e fazer modificaes
para atingir determinados objetivos especficos e adaptar o processo a
novos conceitos e paradigmas. Ao se acostumar com o processo na
forma de um modelo, as pessoas tendem a entender cada vez mais o
processo e sugerir adaptaes e melhorias ao longo do tempo.

Dar suporte para a automao de partes do processo: Uma vez que

se tenha definido um modelo para representar processos, ferramentas
podem ser criadas para automatizar certas partes do processo,

___________________________________________________________________ 49

eliminando

algumas

atividades

feitas

de

forma

manual

conseqentemente agilizando o processo de construo de software.

Levando esses benefcios em considerao que este trabalho procura elaborar
uma modelagem para o processo de software XP. Em [65] menciona-se que processos
de software geis, incluindo XP, carecem de uma descrio mais explcita dos seus
elementos e no especificam como podem ser adaptados. Isso torna difcil a adaptao
de processos geis para determinados tipos de propsitos como, por exemplo: adaptar
XP para o desenvolvimento de software para a Web, adaptar XP para o
desenvolvimento de software de tempo real, etc.
A necessidade de se adaptar processos surge do fato de que os processos de
desenvolvimento de software geralmente possuem um propsito geral e so descritos de
uma forma que no abrange de forma suficiente todos os tipos de domnios de
problema. Ento, para resolver um determinado problema especfico, em alguns casos,
necessria uma adaptao no processo de software. A tarefa de adaptar o processo pode
ser facilitada pelo uso linguagens de modelagem para representar o processo e
ferramentas para automatizar a modelagem.
Ao longo deste captulo sero mostradas a modelagem e as adaptaes feitas em
XP. A modelagem feita usando a meta-linguagem de modelagem de processos SPEM
[48] e ser descrita na seo 3.7. Esta modelagem servir para a elaborao do processo
XWebProcess a ser mostrada no captulo 4.

3.6.2 Abordagens para modelagem de processos de software

Processos de software podem ser modelados em diferentes nveis de abstrao
como, por exemplo: modelos genricos, modelos adaptados e modelos instanciados.
Alm disso, eles tambm podem ser modelados com diferentes objetivos e segundo
vises distintas. Em [66] so mostradas algumas das principais perspectivas de
modelagem de processos:

___________________________________________________________________ 50

Funcional: Representa quais elementos do processo esto sendo

implementados e quais fluxos de informao so importantes para tais
elementos.

Comportamental: Representa quando e sobre quais condies os

elementos do processo so implementados.

Informativo ou Estrutural: Representa a estrutura e relacionamentos

entre os elementos do processo.

Os modelos usados para representar processos procuram levar em considerao

as perspectivas vistas acima e so criados com o objetivo de se oferecer linguagens,
abstraes e formalismos para facilitar a representao de um processo de software
capturando sua estrutura e comportamento.
Ao longo dos ltimos anos, surgiram diversas linguagens com o propsito de
modelar processos de software. Em [67] mostrada uma linguagem chamada
DYNAMITE que se baseia em conceitos de UML e de redes de tarefas (task nets) para a
modelagem de processos de software. Alm da linguagem, ferramentas so fornecidas
para criar os modelos e acompanhar o processo medida que um projeto vai sendo
implementado. Em [68] proposta uma linguagem orientada a objetos para modelagem
de processos de software que tambm possui o suporte de ferramentas.
O surgimento de vrias linguagens para processos de software acaba acarretando
um problema semelhante ao que aconteceu nos anos 80 em relao modelagem
orientada a objetos, quando muitas empresas usavam linguagens distintas para
modelagem o que dificultava o trabalho junto aos clientes e a troca de informaes entre
as empresas. Esse problema foi minimizado depois do surgimento de UML que logo
veio a se tornar um padro utilizado em escala mundial.
No campo da modelagem de processos de software um grande avano foi dado
nos ltimos trs anos quando a OMG [69] decidiu submeter uma proposta de requisio
(RFP) por uma linguagem de modelagem para processos de software. Diversas
empresas importantes na rea de software como Rational software, IBM, Unisys,
Alcatel e outras resolveram se unir para elaborar uma linguagem que pudesse atender

___________________________________________________________________ 51

aos requisitos propostos pela OMG. Em Novembro de 2002 a meta-linguagem Software

Process Engineering Metamodel (SPEM) [48] foi oficializada como um padro da
OMG e encontra-se atualmente na sua verso 1.0.
A meta-linguagem SPEM foi escolhida como linguagem de modelagem a ser
usada neste trabalho, pois acreditamos que ela possa se tornar um padro muito
utilizado, como a UML, devido aos seguintes fatores:

um padro oficial da OMG cuja reputao em estabelecer padres

indiscutvel;

Possui o apoio de grandes empresas na rea de software que esto dando

suporte ao seu uso, atravs da construo de ferramentas e outras formas
de apoio;

Baseia-se em UML que um padro j conhecido e consolidado no meio

acadmico e empresarial.

Uma completa descrio da linguagem SPEM mostrada no Apndice 1, onde

apresentada uma viso geral sobre a linguagem e seus principais conceitos.

importante ressaltar que as outras linguagens possuem grande importncia para a rea
de modelagem de processos, porm optamos por SPEM devido aos fatores mencionados
acima. A prxima seo mostra a modelagem de XP feita usando SPEM.

3.7 Modelagem de XP usando SPEM

Esta seo contm uma breve descrio sobre SPEM na seo 3.7.1, e uma parte
da modelagem de XP usando SPEM mostrada nas sees 3.7.2 e 3.7.3.

3.7.1 Viso geral de SPEM

O Software Process Engineering Metamodel (SPEM) [48] um meta-modelo
que pode ser usado para descrever um processo concreto de desenvolvimento de

___________________________________________________________________ 52

software ou uma famlia de processos relacionados. SPEM adota uma abordagem

orientada a objetos para modelar processos e usa UML como notao. A Figura 3.2
descreve a arquitetura de quatro nveis de modelagem definida pela OMG e respeitada
por SPEM.
MOF

MetaObject Facility

M3

Process Metamodel

M2

SPEM,UML

M1

e.g., RUP,
Open, XP

M0

Process as really enacted on

a given project

Process Model

Performing Process

Figura 3.2 - Nveis de modelagem definidos em [48]

O processo real de produo, conforme instanciado para um projeto especfico,

est no nvel M0. No nvel M1 encontra-se a definio do processo que foi instanciado
em M0 como, por exemplo, RUP, OPEN ou XP. O foco da definio de SPEM est em
criar um meta-modelo que se encontra no nvel M2 que possui esteretipos para a
modelagem dos processos que esto no nvel M1. A especificao de SPEM est
estruturada como um perfil UML (UML profile)10 e tambm atravs de um metamodelo baseado no MOF11 que se encontra no nvel M3. Essa abordagem facilita a
utilizao e construo de ferramentas para UML e ferramentas baseadas em MOF.
O objetivo do padro SPEM abranger uma vasta gama de processos de
desenvolvimento de software j existentes ao invs de exclu-los devido ao excesso de
elementos e restries que poderiam existir na sua definio. SPEM permite que seus

10

11

Um UML-profile um conjunto de uma ou mais extenses da semntica de UML com a inteno de

customiz-la para um domnio ou propsito particular, como, por exemplo, para modelagem de
processos no caso de SPEM.
O Meta-Object Facility (MOF) a tecnologia adotada pela OMG para definir metadados e representlos como objetos CORBA. SPEM usa um subconjunto da UML para representar seus elementos como
um meta-modelo MOF.

___________________________________________________________________ 53

usurios (modeladores de processo) usem a UML, e define esteretipos que podem ser
usados nos modelos produzidos.
O meta-modelo SPEM construdo pela extenso de um subconjunto do metamodelo da UML 1.4. Esse subconjunto de UML chamado em SPEM de
SPEM_Foundation. Alm disso, o modelo SPEM possui o pacote SPEM
Extensions que adiciona as construes e semnticas re queridas para a engenharia de
processos de software. A Figura 3.3 abaixo mostra esses dois pacotes.
<<metamodel>>
SPEM_Foundat ion

<<metamodel>>
SPEM_Extensions

Figura 3.3 - Estrutura de pacotes de SPEM [48]

Um maior detalhamento do contedo de cada pacote pode ser encontrado em

[48] e no Apndice 1. A descrio do modelo SPEM apresentada at agora suficiente
para se ter um entendimento de como a linguagem foi construda e de qual a sua
utilidade. O uso real de SPEM para a modelagem de um processo de software ser
apresentado nas duas prximas sees atravs da modelagem de XP.

3.7.2 Modelagem dinmica de XP usando SPEM

Na seo anterior foi apresentada uma viso geral de SPEM destacando-se como
a linguagem definida e organizada. Nesta seo, procura-se mostrar como SPEM pode
ser utilizada na prtica, ou seja, do ponto de vista de seus usurios. A linguagem SPEM
ser utilizada para modelar o processo XP, apresentado anteriormente, sob as
perspectivas dinmica (comportamental) e estrutural.
De acordo com [48] alguns diagramas bsicos de UML podem ser usados para
apresentar perspectivas diferentes de um modelo de processo de software. Em SPEM

___________________________________________________________________ 54

podem ser utilizados alguns desses diagramas, dentre eles: diagrama de classes, de
pacotes, de atividade, de caso de uso, de seqncia e de transio de estados. A
linguagem SPEM oferece algumas representaes e esteretipos para modelar seus
principais elementos em diagramas UML. Um resumo dos principais elementos de
SPEM, seus conceitos e suas representaes grficas mostrado na Tabela 3.1.
Tabela 3.1 - Descrio de alguns elementos de SPEM12

ESTERETIPO
WorkProduct
(Artefato)

COMENTRIO

NOTAO

uma descrio de algo que contm informao ou

uma entidade fsica produzida ou usada por atividades
do processo. Ex: modelos, planos, documentos, etc.

WorkDefinition

um elemento do modelo que descreve a execuo,

(Conjunto de

as operaes realizadas e as transformaes feitas nos

Trabalho)

WorkProducts.

Representa

um

conjunto

de

atividades, como, por exemplo: especificar requisitos,

fazer projeto do sistema, etc.
Guidance

um elemento do modelo que se associa a outros

(Guia)

elementos e pode conter descries adicionais, tais

como tcnicas, guidelines, templates, etc...

Activity

uma WorkDefinition que descreve o que um

(Atividade)

Proce ssRole (papel) realiza.

ProcessRole

Descreve os papis, responsabilidades e competncias

(Papel)

que um determinado indivduo tem dentro do

processo.

12

Estes esteretipos so definidos em [48] e no restante do trabalho sero usados em portugus.

___________________________________________________________________ 55

ESTERETIPO
Discipline
(Disciplina)

COMENTRIO

NOTAO

um agrupamento coerente de elementos do processo

(artefatos, papis, atividades) cujas atividades so
organizados segundo algum ponto de vista ou tema
comum (Ex: Anlise e Projeto, teste, implementao,
etc.).

Os elementos descritos na tabela acima podem ser usados em diagramas UML

para representar diversos pontos de vista do processo de software. Neste trabalho, ser
mostrada a modelagem feita para o processo Extreme Programming utilizando os
conceitos acima. A Figura 3.4 abaixo mostra um diagrama de atividades que representa
a dinmica de um projeto realizado seguindo o processo XP.
O processo se inicia por uma etapa inicial de exploraes onde so feitos testes e
experimentos com as tecnologias a serem utilizadas e verifica-se a existncia de
viabilidade tecnolgica considerando-se as restries do ambiente onde o sistema ser
implantado. Uma arquitetura inicial e um levantamento prvio dos requisitos do sistema
so elaborados.
Depois disso, os clientes e os programadores escrevem as histrias que
representam os requisitos do release a ser implementado. As histrias correspondem a
casos de uso simplificados que recebem uma estimativa de dificuldade dada pelos
programadores com base em estimativas passadas e na sua experincia. Essas
estimativas servem como uma base para que os clientes escolham quantas histrias
sero implementadas no release isso segue a idia do jogo do planejamento
apresentado na seo 3.4.1.
Dentro de um release, ocorrem vrias iteraes onde diversas histrias so
implementadas e testadas. Cada iterao segue um determinado fluxo de atividades que
consistem em: planejar iterao, projetar, escrever testes de unidade, codificar, testar e
integrar conforme mostrado na figura abaixo. Alm disso, dentro da iterao podem
ocorrer diversas alteraes nos requisitos onde as estrias podem ser re-escritas e
revisadas para atender as necessidades de mudana do cliente. Essas alteraes podem

___________________________________________________________________ 56

ser realizadas durante o planejamento da iterao onde os programadores podem

reavaliar as estimativas feitas anteriormente com base nas sugestes de modificao e
no feedback obtido de iteraes anteriores.
No trmino da ltima iterao, a verso atual do sistema colocada em
produo no ambiente do cliente e diversas verses subseqentes so geradas at que
todos os requisitos do sistema sejam implementados e entregues ao cliente.

___________________________________________________________________ 57

Figura 3.4 - Modelagem de XP usando diagrama de atividades da UML e esteretipos de SPEM

___________________________________________________________________ 58

A modelagem dinmica de XP mostrada na Figura 3.4 foi feita com base nos
esteretipos disciplina de SPEM utilizando-se um diagrama de atividades da UML para
dar uma idia da seqncia de cada disciplina de XP ao longo do tempo. A modelagem
se baseou na descrio do ciclo de vida de XP apresentada na seo 3.4.2. A prxima
seo procura apresentar a modelagem esttica de algumas disciplinas atravs de
diagramas de classe UML.

3.7.3 Modelagem esttica das disciplinas de XP

Nesta seo so apresentados diagramas de classe que descrevem o
detalhamento de duas disciplinas da Figura 3.4 - mostradas nas FigurasFigura 3.5 e
Figura 3.6. A apresentao completa de todos os diagramas feita no apndice 2.

Figura 3.5 - Fazer exploraes iniciais

A modelagem da Figura 3.5 procura representar o que feito na fase de

explorao de XP descrita na seo 3.4.2. Esta parte do processo XP onde so feitas as
primeiras exploraes e investigaes sobre o projeto a ser implementado. Os clientes
so consultados e trazidos para dentro da equipe para realizar a definio prvia dos
requisitos e do escopo do sistema. Os programadores so responsveis por fazer
experimentos com a possvel tecnologia e infra-estrutura a ser escolhida para verificar a

___________________________________________________________________ 59

viabilidade da soluo e elaborar uma idia de arquitetura atravs da metfora. Algumas

histrias iniciais podem ser descritas, mas o importante aqui levantar as informaes
necessrias para decidir se o projeto vivel ou no. Outra disciplina de XP descrita
na figura abaixo.

Figura 3.6 - Definir e Revisar requisitos

A modelagem da Figura 3.6 procura representar o que descrito nas sees

3.4.1 e 3.4.2 no que se refere ao levantamento de requisitos, que feito basicamente
pelo cliente e pelos programadores, atravs da escrita dos cartes de histria.
Esta parte do processo XP se preocupa em definir e revisar os requisitos que iro
fazer parte de uma verso (release) do sistema. Como XP admite mudanas constantes
nos requisitos ento importante mencionar que esses requisitos podem ser alterados a
qualquer instante e que eles tambm sero revistos na parte de XP que trata dos
requisitos da iterao. Em XP, o cliente, ou algum que o represente, trabalha
juntamente com a equipe de desenvolvimento (prtica on-site customer) e responsvel
por escrever e priorizar as histrias com o auxlio dos programadores. Os clientes
escrevem os cartes contendo as descries de cada histria, a qual atribuda uma
certa prioridade pelo cliente. O principal resultado dessa disciplina so os cartes de
histria com a descrio de suas funcionalidades e as estimativas de esforo.
Ao longo desta seo, a meta-linguagem de modelagem SPEM foi usada para
modelar a estrutura do processo de software XP, atravs da elaborao de dois

___________________________________________________________________ 60

diagramas de classe contendo esteretipos de SPEM. Alguns dos benefcios da

modelagem de processos j foram citados na seo 3.6.1 e a justificativa da escolha de
SPEM foi mencionada na seo 3.6.2. importante tambm ressaltar que o fato de se
ter modelado XP no implica em nenhuma perda de eficincia, pois a modelagem no
tem o objetivo de alterar a forma como se trabalha utilizando XP, nem tampouco sugere
nenhuma modificao na sua estrutura.
A modelagem de XP realizada traz os seguintes benefcios:

Simplifica o entendimento dos elementos de XP tornando mais fcil seu

aprendizado.

Simplifica o trabalho de uma organizao que pretende adotar XP como

processo base de engenharia de software.

Simplifica o trabalho de uma organizao que j utiliza XP e precisa

fazer adaptaes para atender certas caractersticas de projetos como, por
exemplo, desenvolvimento de software para a Web e de software de
tempo real usando XP.

A forma de trabalhar com XP no alterada pelo modelo, logo XP no

deixar de ser gil ou leve porque foi modelado.

A modelagem dinmica e esttica de XP produzidas nesta seo e na anterior

serve como base para as adaptaes feitas no prximo captulo. A organizao e a
estruturao de XP em modelos facilitam o seu entendimento e tambm a elaborao do
processo XWebProcess.

3.8 Consideraes finais

Este captulo apresentou os principais conceitos relativos a Extreme
Programming. Foi dada uma explicao sobre a estrutura de XP atravs da descrio de
seus valores, princpios e prticas e tambm foi mostrado o ciclo de vida que segue um
projeto XP. Alm disso, foi apresentada uma parte da modelagem de XP com SPEM

___________________________________________________________________ 61

que traz alguns benefcios como facilitar o entendimento e a organizao dos elementos
de XP. Esta modelagem servir tambm para facilitar a criao do processo
XWebProcess a ser apresentado no prximo captulo.