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 o 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.
Pap el 1 0..* 1 0..* At o r

R e a liz a
0..*

At i v i d a d e

A s s is t e

0..* * *

R e a liz a

Cons ome
* * Ar t e f a t o

Pr o d u z

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.
MetaObject Facility M3 MOF

Process Metamodel

M2

SPEM,UML

Process Model

M1

e.g., RUP, Open, XP

Performing Process

M0

Process as really enacted on a given project

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 uma descrio de algo que contm informao ou uma entidade fsica produzida ou usada por atividades do processo. Ex: modelos, planos, documentos, etc.

NOTAO

WorkDefinition (Conjunto de Trabalho)

um elemento do modelo que descreve a execuo, as operaes realizadas e as transformaes feitas nos WorkProducts. Representa um conjunto de atividades, como, por exemplo: especificar requisitos, fazer projeto do sistema, etc.

Guidance (Guia)

um elemento do modelo que se associa a outros elementos e pode conter descries adicionais, tais como tcnicas, guidelines, templates, etc...

Activity (Atividade) ProcessRole (Papel)

uma WorkDefinition que descreve o que um Proce ssRole (papel) realiza. Descreve os papis, responsabilidades e competncias 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 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.).

NOTAO

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.