UNIVERSIDADE TUIUTI DO PARAN Eduardo Ukan

TRABALHO DE ENGENHARIA DE SOFTWARE COM OBJETIVO DE ESTUDAR O MTODO DE PROGRAMAO EXTREMA (XP)

CURITIBA 2011

PROGRAMAO EXTREMA (XP) A programao extrema ou Extreme Programming (XP) metodologias geis de desenvolvimento de software teve seu surgimento nos Estados Unidos por volta do ano de 1986 com o seu criador Kent Beck. Vem fazendo sucesso em diversos pases por ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual. Tais objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e prticas que diferem substancialmente da forma tradicional de desenvolver software. Extreme Programming (XP), descreve como uma disciplina de

desenvolvimento de software que organiza as pessoas a produzir software de alta qualidade de forma mais produtiva. XP tenta reduzir o custo das mudanas nas exigncias por ter mltiplos ciclos curtos de desenvolvimento, em vez de um longo. Nesta doutrina mudanas um aspecto natural, devido aos requisitos serem vagos e suas mudanas so inevitveis, o desenvolvimento incremental (interativo), onde o sistema comea a ser implementado logo no incio do projeto e vai ganhando novas funcionalidades ao longo do tempo. Extreme programming tambm introduz uma srie de valores bsicos, princpios e prticas no topo do quadro de programao gil. A possibilidade de entrega rpida do cdigo um dos fatores de sucesso do XP. Isto, no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta uma das caractersticas importantes para o mtodo funcionar bem. Uma das caractersticas importantes do XP que no existe um processo de design tradicional com a elaborao de modelos da arquitetura do software. O sistema concebido a partir de uma metfora e so descritos em histrias do usurio. Uma metfora a transposio de uma conceitualizao do mundo real para o sistema a ser desenvolvido. A metfora passa a ser fundamental para a elaborao das histrias de usurios. O uso de cartes CRC (Classes, Responsabilidades e Colaboraes) recomendado de forma a permitir o design em equipe. Cartes CRC permitem a descrio dos conceitos identificados na metfora na forma de classes.

HISTRIAS DE USURIOS

A elaborao de histrias de usurio uma das atividades fundamentais no XP. As histrias de usurio descrevem cenrios com situaes de utilizao que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Elas devem ser escritas pelos prprios usurios. As histrias de usurio so semelhantes aos casos de uso da UML, mas no so. A diferena que elas no se limitam a descrever o processo de interao do usurio com o sistema. No XP, as histrias de usurio ocupam o lugar dos longos documentos de requisitos nos mtodos tradicionais. Cada histria deve ser um texto escrito com aproximadamente 03 sentenas e devem ser escritos com suas prprias palavras sem a necessidade de termos tcnicos. As histrias de usurio so a base para a criao de estimativas de tempo que sero utilizadas nas reunies de planejamento de entregas (releases). O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iteraes para cada interao individual. Geralmente essas histrias so semanalmente, pois os programadores e os clientes se renem semanalmente para verificar o que foi realizado na semana anterior e decidir o que vai ser realizado (implementado) na semana seguinte. As histrias de usurio so tambm a base para a elaborao dos testes de aceitao. Um ou mais testes de aceitao automatizados deve ser criados para verificar se o programa implementa a histria corretamente. O envolvimento do usurio, portanto, como autor das histrias, fundamental para a elaborao do plano de entregas e dos testes de aceitao em cada iterao de desenvolvimento. PRTICAS DE PROGRAMAO

O processo de programao tem como caractersticas a programao em pares e a propriedade coletiva do cdigo. Na programao em pares, dois programadores ocupam um nico computador. Embora, a princpio, isto possa ser visto como um desperdcio de esforos, vrias vantagens podem ser obtidas. Esta estratgia aumenta a qualidade do cdigo e no altera o tempo de entrega, uma vez que haver um ganho posterior nas etapas de retirada de erros (defeitos). Os dois programadores atuam de forma

colaborativa. Enquanto o que est com o teclado e mouse est pensando diretamente na codificao (sintaxe, variveis, fluxos de controle, etc.), o outro pode pensar estrategicamente em como o cdigo ir interagir como outras partes do programa. Alm disso, um atua com uma viso mais crtica corrigindo erros dos companheiros e pode pensar nas futuras mudanas e etapas posteriores. Isto permite que a tradicionalmente prtica do codifica-e-conserta, criticada nas origens do desenvolvimento de software, possa ser realiza sem perda da qualidade do software. A propriedade coletiva do cdigo outra caracterstica fundamental do mtodo XP, com a rotatividade do cdigo entre os programadores e reunies freqentes preferencialmente reunies dirias de aproximadamente de 15 minutos para verificar o que foi implementado e os defeitos ocorridos no dia anterior e o que deve ser implementado no dia que esta inicializando, isso serve para estabilizar o cdigo. A propriedade coletiva encoraja o time todo a contribuir com novas idias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o cdigo. No existe a figura do arquiteto chefe. Todos so responsveis pelo cdigo inteiro. No existe algum para aprovar as mudanas. Para isto as reunies freqentes devem ser definidas como parte do processo iterativo de programao. Estas reunies devem ser curtas e so realizadas com todos de p. A prtica do codifica-e-conserta tambm requer um processo constante de teste de unidade e integrao. Para isto funcionar bem, os desenvolvedores devem trabalhar com uma ferramenta de testes automtica e um repositrio coletivo do cdigo fonte. Os desenvolvedores devem criar testes de unidades e liberar o cdigo apenas quando estiver 100% testado. Uma vez no repositrio, qualquer um pode fazer alteraes e adicionar novas funcionalidades. Uma ferramenta de controle de verses fundamental. O re-trabalho ou re-fabricao uma atividade fundamental e necessria para o XP funcionar. Mesmo que o cdigo esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para remover redundncias, retirar funcionalidades desnecessrias e modificar arquitetura obsoletas. O re-trabalho do cdigo ao longo de todo o ciclo de vida reduz o tempo total de entrega do cdigo e aumenta a qualidade do software produzido. Regras e Prticas

Planejando Histrias do usurio Planejando liberaes (releases) e pequenas liberaes Dividir projetos em iteraes (ciclos) Medindo velocidade do projeto Dinmica de pessoal Reunies dirias em p (geralmente 15 minutos)

Projetando (designing)

Simplicidade (no adicione funcionalidades antes do tempo) Metfora Cartes CRC (Classes, Responsabilidades e Colaborao) Re-fabricar (refactor)

Codificando

O cliente deve estar sempre disponvel. Programao em pares. Codificar de acordo com padres acordados. Codificar testes de unidade primeiro. Integrar com freqncia. O cdigo propriedade coletiva. No atrase.

Testando

Todo cdigo deve ter os testes de unidade. Cada unidade deve ser testada antes de liberada. Quando um erro encontrado, testes devem ser realizados. Testes de aceitao devem ser freqentes.

A programao extrema tem sido bem sucedida em projetos pequenos e mdios com times pequenos. Relatos mostram que para projetos grandes o mtodo XP no recomendado.

Perguntas:
1) A Engenharia de Software no modelo UML se preocupa primeiramente

em desenvolver toda a documentao para o projeto e depois comea a programar o cdigo fonte, mas a programao extrema diz que o mais importante o software funcionando e ainda entregue em menos tempo e com melhor qualidade. Como se explica essa funcionalidade, eficincia do mtodo mesmo com pouca documentao, pois o que existe de documentos so as histrias dos clientes em cartes CRC? E se houver manuteno futuramente, ela ficar comprometida pela falta de documentao?

2) Considerando

que os programadores se renem diariamente normalmente pela manh durante uns 15 minutos para verificar o que foi implementado, possveis erros e decidir o que cada programador ira implementar durante aquele dia. Como se comporta o analista de sistemas e os programadores, como ficam definidas essas funes? O que cada um ir fazer realmente?