You are on page 1of 13

Estudo da adequao do uso da plataforma .

net e da metodologia de desenvolvimento extreme programming na elaborao de um software para a rea mdica
Paula Costa de Souza1, Vanessa Oliveira Fonseca Alves1, Leila Silva1 1 Departamento de Cincia da Computao e Estatstica Universidade Federal de Sergipe Campus Universitrio Prof. Jos Alosio Campos CEP 49100-000 So Cristvo SE Brasil
{paulacs.se, vanessaofalves}@gmail.com, leila@ufs.br

Resumo. A construo de software um processo complexo, que envolve aspectos tcnicos e gerenciais. considerado um problema crtico, e tem sido alvo de muitos estudos acerca de melhorias na elaborao de metodologias, mtodos, ferramentas e procedimentos para guiar o desenvolvimento de sistemas. Esse trabalho estuda a integrao da metodologia gil XP (Extreme Programming) com a plataforma .Net na construo de um software, chamado Nova Vida, para gerenciamento dos potenciais doadores de rgos no estado de Sergipe. O resultado dessa integrao e as vantagens e desvantagens da aplicao dos valores e das prticas do XP so discutidos nesse trabalho. Palavras-Chaves: Extreme Programming, Plataforma .Net, Doao de rgos. Abstract. The software construction is a complex process that involves management technical issues. It is considered a problem, and several methods, tools and procedures to guide methodologies software development have been proposed. This work investigates the integration of agile methodology XP (Extreme Programming) with the platform. Net in the construction of a software, called New Life, for management of the potential organ donors in Sergipe. The result of this integration and the advantages and disadvantages of the application of the values and the practices of the XP are discussed in this work. Key words: Extreme Programming, Platform. Net, Organ donors.

1. Introduo Processo de software um conjunto de atividades e resultados associados que auxiliam na produo de software. Existem vrios processos de software definidos na literatura da Engenharia de Software. Dentre os processos existentes, h as metodologias tradicionais [Soares 2004] que so orientadas a documentao, e as metodologias geis [Manifesto gil,

2001], que procuram desenvolver software com o mnimo de documentao, consumindo mais tempo na implementao. Basicamente, as metodologias tradicionais baseiam-se em um modelo em que existe uma seqncia de etapas a ser seguida. J as metodologias geis so baseadas na experincia prtica para modelagem efetiva de sistemas baseados em software, sendo, na realidade, uma coleo de prticas, guiadas por princpios e valores e cujo foco principal so pessoas. Dentre as metodologias geis existentes, podemos citar as metodologias Crystal, SCRUM, FeatureDriven Development e Extreme Programming (XP) [Beck, 2000, Teles 2004]. Esta ltima a metodologia gil mais conhecida e usada. XP ideal para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Foi por esse motivo que esta metodologia foi escolhida para o presente projeto. Alm da metodologia de desenvolvimento, o software para ser construdo precisa de uma plataforma de desenvolvimento. Dentre as mais conhecidas no mercado esto a plataforma Java [Deitel, 2005] e a plataforma .NET [Santos e Tavares, 2001], por possurem amplos artefatos necessrios para construir softwares robustos e de qualidade. Para avaliar a integrao da metodologia XP com o uso da plataforma .NET foi desenvolvido um estudo de caso para a rea mdica, a saber, um sistema que auxilie na avaliao do potencial de provveis doadores de rgos, deteco das possveis causas da no notificao de mortes enceflicas, como tambm a identificao dos motivos de recusa de doao. A integrao da metodologia XP e da plataforma .NET incipiente na literatura, visto que as autoras no encontraram outro estudo referente a esse contexto. Entretanto, trabalhos tericos sobre a integrao da plataforma Java com XP j existem. Em [Teles, 2005] a integrao da plataforma Java com XP foi explorada atravs de um estudo de caso comercial. J em [Cronin, 2001], h um estudo de caso que integra a plataforma Java a todas as prticas da metodologia XP, chamado Extreme Solo. Basicamente a metodologia foi usada para produzir um sistema de gerncia ocasional dos recursos humanos para uma universidade. Este artigo est organizado como descrito a seguir. A Seo 2 descreve a metodologia de desenvolvimento escolhida no projeto: Extreme Programming. Na Seo 3, a plataforma .Net brevemente apresentada. Na Seo 4, o desenvolvimento de um estudo de caso de um sistema para auxiliar rotinas mdicas no contexto de transplantes descrito. Consideraes finais e direes de trabalhos futuros so abordadas na Seo 5. 2. A metodologia Extreme Programming (XP) A metodologia XP voltada para sistemas orientados a objeto, baseados no desenvolvimento incremental, no qual o sistema comea a ser implementado logo no incio do projeto e vai incorporando novas funcionalidades no decorrer do tempo. Essa metodologia geralmente aplicada em projetos onde h muitas mudanas, em que os requisitos so passveis de alteraes e onde refazer partes do cdigo no uma atividade que apresenta alto custo. Os projetos tpicos realizados com XP envolvem equipes pequenas, com datas de entrega do software curtas e desenvolvimento rpido. A metodologia XP incorpora quatro valores: comunicao, simplicidade, feedback e coragem [Beck, 2000]. A finalidade do princpio de comunicao manter o melhor relacionamento possvel entre clientes e desenvolvedores, preferindo conversas pessoais a

outros meios de comunicao. A comunicao entre os desenvolvedores e o gerente do projeto tambm encorajada. A simplicidade visa permitir a criao de cdigo simples que no deve possuir funes desnecessrias. Por cdigo simples entende-se implementar o software com o menor nmero possvel de classes e mtodos. Outra idia importante da simplicidade procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem vir ser importantes apenas no futuro. A prtica do feedback constante significa que o programador ter informaes constantes do cdigo e do cliente. A informao do cdigo dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relao ao cliente, o feedback constante significa que ele ter freqentemente uma parte do software totalmente funcional para avaliar. O cliente ento constantemente sugere novas caractersticas e informaes aos desenvolvedores. Eventuais erros e no conformidades so rapidamente identificados e corrigidos nas prximas verses. Desta forma, a tendncia que o produto final esteja de acordo com as expectativas reais do cliente. necessrio coragem para implantar os trs valores anteriores. Por exemplo, no so todas as pessoas que possuem facilidade de comunicao e tm bom relacionamento. A coragem tambm d suporte simplicidade, pois assim que a oportunidade de simplificar o software percebida, a equipe pode experimentar. Alm disso, preciso coragem para obter feedback constante do cliente. A XP baseia-se nas doze prticas [Beck, 2000] comentadas a seguir. Planejamento - consiste em decidir o que necessrio ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, no em requisitos futuros. Alm disso, a XP procura evitar os problemas de relacionamento entre a rea de negcios (clientes) e a rea de desenvolvimento. As duas reas devem cooperar para o sucesso do projeto e cada uma deve focar em partes especficas do projeto. Desta forma, enquanto a rea de negcios deve decidir sobre o escopo, a composio das verses e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas. Entregas freqentes visam construo de um software simples, e conforme os requisitos surgem, h a atualizao do software. Cada verso entregue deve ter o menor tamanho possvel, contendo os requisitos de maior valor para o negcio. Idealmente devem ser entregues verses a cada ms, ou no mximo a cada dois meses, aumentando a possibilidade de feedback rpido do cliente. Metfora - so as descries de um software sem a utilizao de termos tcnicos, com o intuito de guiar o desenvolvimento do software. Projeto simples - o programa desenvolvido pelo mtodo XP deve ser o mais simples possvel e satisfazer os requisitos atuais, sem a preocupao de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem. Testes - a XP focaliza a validao do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes. Programao em pares - a implementao do cdigo feita em dupla, ou seja, dois desenvolvedores trabalham em um nico computador. O desenvolvedor que est com o controle do teclado e do mouse implementa o cdigo, enquanto o outro observa continuamente o trabalho que est sendo feito, procurando identificar erros sintticos e semnticos e pensando estrategicamente em como melhorar o cdigo que est sendo implementado. Esses papis podem e devem ser alterados continuamente. Refatorao - foca no aperfeioamento do projeto do software e est presente em todo

o desenvolvimento. A refatorao deve ser feita apenas quando necessrio, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que possvel simplificar o mdulo atual sem perder nenhuma funcionalidade. Propriedade coletiva - o cdigo do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um cdigo, mesmo que ele prprio no o tenha desenvolvido, pode faz-lo, desde que faa a bateria de testes necessria. Isto possvel porque na XP todos so responsveis pelo software inteiro. Uma grande vantagem desta prtica que, caso um membro da equipe deixe o projeto antes do final deste, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que no seja de forma detalhada. Integrao contnua - a prtica de interagir e construir o sistema de software vrias vezes por dia, mantendo os programadores em sintonia, alm de possibilitar processos rpidos. Integrar apenas um conjunto de modificaes de cada vez uma prtica que funciona bem porque fica bvio quem deve fazer as correes quando os testes falham. Esta prtica facilitada com o uso de apenas uma mquina de integrao, que deve ter livre acesso a todos os membros da equipe. 40 horas de trabalho semanal: a XP assume que no se deve fazer horas extras constantemente. Cliente presente - fundamental a participao do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponvel para sanar todas as dvidas de requisitos, evitando atrasos e at mesmo construes erradas. Uma idia interessante manter o cliente como parte integrante da equipe de desenvolvimento. Cdigo padro - padronizao na arquitetura do cdigo, para que este possa ser compartilhado entre todos os programadores. Dentre as metodologias geis escolhemos XP por ser a mais difundida no meio acadmico e comercial. Alm disso, no encontramos trabalhos integrando XP com .NET, o que tornaria mais rico o nosso processo de investigao da integrao destas abordagens. Por outro lado, XP adequa-se bem ao estudo de caso aqui ilustrado, pois a equipe de desenvolvimento pequena, mas ainda permite a explorao da prtica de programao em par. Alm disso, o projeto tem escopo varivel no que se refere a funcionalidades e consideraes da rea mdica.

3. A Plataforma .NET A plataforma .NET [Santos e Tavares, 2001] uma plataforma de software que conecta informaes, sistemas, pessoas e dispositivos. Desenvolvido sobre os padres de Web Services XML, a plataforma possibilita que sistemas e aplicativos, novos ou j existentes, conectem seus dados e transaes independente da linguagem de implementao, do sistema operacional, do tipo de computador ou do tipo dispositivo mvel que sejam utilizados. Com idia semelhante plataforma Java, o programador deixa de escrever cdigo para um sistema ou dispositivo especfico, e passa a escrever para a plataforma .NET. Esta plataforma tem independncia na linguagem de programao, com ela possvel trabalhar com vrias linguagens diferentes no mesmo projeto e interagir entre elas. Isso possvel devido existncia da IL (Intermediate Language uma linguagem intermediria), em que todos os cdigos fontes compilados pelo CLR (Common Language Runtime -

ambiente de execuo independente de linguagem) resultam em uma s linguagem. Dessa forma a CLR interage com uma coleo de bibliotecas unificadas, que juntas so o prprio framework. Esta CLR capaz de executar, atualmente, mais de vinte diferentes linguagens de programao, as quais interagem entre si como se fosse uma nica linguagem. A linguagem C# [Turtschi, 2005] foi a adotada neste trabalho para a construo do software. A plataforma .NET permite a execuo, construo e desenvolvimento de Web services, aplicaes Web, aplicaes para Desktop, aplicaes para Console, Windows services e mobile, de forma integrada e unificada. Em nosso trabalho, a aplicao ser para Web. A Figura 1 mostra como a plataforma .NET estruturada. Na camada mais alta residem as linguagens de programao. Na camada seguinte, encontra-se a CLS (Common Language Specification), a qual converte as linguagens da primeira camada para a linguagem intermediria. Na terceira e quarta camadas encontram-se as maneiras de como as aplicaes feitas a partir da plataforma podem ser disponibilizadas. Na quinta camada, encontra-se o framework e suas bibliotecas organizadas logicamente em namespaces. E finalmente, na sexta camada, encontra-se o ambiente de execuo das aplicaes .NET, o CLR.

Figura 1 - A arquitetura .NET.

4. Integrando XP e .NET no desenvolvimento de um sistema para a rea mdica O objetivo deste trabalho explorar a integrao da metodologia XP com a plataforma .Net. Para realizar esta investigao, escolheu-se o desenvolvimento de um estudo de caso na rea mdica. A aplicao escolhida neste projeto foi desenvolvida para atender s necessidades da Central de Notificao, Captao e Distribuio de rgos - CNCDO do estado de Sergipe, vinculada Secretaria Estadual de Sade. A CNCDO-SE uma das centrais instaladas nas 22 federaes brasileiras que compem o Sistema Nacional de Transplantes. Esse sistema foi criado em 1997 e tem como prioridade, evidenciar com transparncia todas as suas aes no campo da poltica de doao-transplante, visando primordialmente a confiabilidade do sistema e a assistncia ao cidado. Dentro desse contexto, a CNCDO-SE coordena a captao e a alocao dos rgos, baseada na fila nica, estadual ou regional. Alm disso, tambm funo da CNCDO estabelecer mecanismos que facilitem a notificao de mortes enceflicas ocorridas nas instituies de sade do Estado. Logo, para auxiliar o processo de doao de rgos da CNCDO-SE, foi criado um sistema, chamado Nova Vida, o qual descrito neste artigo. Para o funcionamento do Nova Vida, o funcionrio da CNCDO preenche informaes que identifiquem o doador, como nome, endereo, estado civil, cor, grau de instruo, entre

outras. Alm disso, o sistema tambm dispe de um mdulo de deteco, onde so solicitadas informaes sobre a etapa de notificao da CNCDO pelo hospital, o que inclui a forma como foi realizada a deteco do potencial doador (busca ativa, notificao, doao espontnea, visita ou telefone) e informaes do hospital de origem (nome do hospital, unidade, leito). Um outro aspecto do sistema refere-se avaliao do doador, onde o usurio deve fornecer ao sistema dados clnicos que foram coletados em pronturios mdicos fornecidos pelo hospital. So cadastradas informaes como exames laboratoriais (tipo sanguneo, cateterismo, leuccitos, plaquetas, entre outros), sorologias (doena de Chagas, toxoplasmose, entre outras), uso de drogas vasoativas, registro de antecedentes como hepatite, cirurgias oculares, sfilis e tumores, entre outras. Outra fase do sistema a abordagem familiar. Esta engloba informaes a respeito do posicionamento tomado pela famlia quanto a doao ou a recusa e seus motivos. Baseado na avaliao do doador e no resultado da abordagem familiar, o sistema emitir um resultado final a respeito da potencialidade do doador, ou seja, se o possvel doador pode ou no doar os rgos. Diante das informaes supracitadas, a Figura 2 mostra um diagrama de atividades que descreve o processo geral de avaliao do potencial doador, ilustrando a sequncia de passos e sua interdependncia. Seguindo o diagrama, nota-se que aps a fase de deteco existe uma bifurcao que expressa a independncia na ordem de execuo das atividades de abordagem familiar e exame laboratorial. Em outras palavras, a execuo desses dois processos se d de forma paralela, no entanto, vale ressaltar que a doao s permitida diante do resultado positivo dos dois processos, a abordagem familiar e o resultado dos exames laboratoriais. Em caso de discordncia de qualquer um deles, a doao recusada. 4.1 Desenvolvendo o Nova Vida seguindo XP Na reunio inicial do projeto, um funcionrio da CNCDO-SE foi designado para explicar todo o processo de doao de rgos equipe de desenvolvedores. Foram discutidas definies conceituais do sistema, prioridades no desenvolvimento, anseios dos usurios, entre outros. Foi verificado pela equipe de desenvolvimento que todo processo de doao composto por quatro escopos bem definidos, como mostrado no diagrama de atividades: a identificao do potencial doador, a deteco do doador, a avaliao e a abordagem de familiares a respeito da doao de rgos. Observou-se tambm que havia uma dependncia entre eles, o que ajudou a estabelecer a ordem em que as funcionalidades seriam implementadas. Realizadas as reunies com o usurio do sistema, estabeleceu-se uma reunio com a equipe do projeto onde foram discutidas a aplicao de algumas prticas do XP e estipuladas as mtricas de planejamento. A princpio, o sistema foi dividido em duas releases. A primeira delas envolveu a identificao de potenciais doadores e a deteco do doador. A segunda release caracterizou-se pelo processamento da avaliao e abordagem de familiares. Para cada release foram estabelecidas iteraes. Uma iterao basicamente um pequeno espao de tempo dedicado implementao de um conjunto de estrias. Cada estria representa o registro de uma funcionalidade do sistema.

Figura 2 Diagrama de Atividades da Avaliao do Doador.

Para estimar o custo previsto para cada estria utiliza-se uma unidade de medida chamada ponto. Em princpio, o ponto representa um dia ideal de desenvolvimento de um desenvolvedor. O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia no qual o desenvolvedor s trabalha na implementao de funcionalidades, sem se preocupar com nenhuma atividade extra. O significado exato de ponto pode variar de acordo com o projeto. A equipe envolvida no projeto deve estabelecer o significado do ponto, sendo que, uma vez estabelecido, ele deve permanecer inalterado at o fim do projeto. De acordo com as caractersticas da equipe de desenvolvedores do Nova Vida, o ponto foi definido como sendo equivalente a quatro horas de trabalho, ou seja, um turno ideal de desenvolvimento. Para execuo da primeira release, a equipe de desenvolvimento solicitou ao usurio que descrevesse, atravs de cartes, quais servios seriam implementados nesse mdulo. O resultado dessa descrio gerou apenas duas estrias assim denominadas pelo usurio: Preencher informaes pessoais do doador e Realizar deteco. De posse das funcionalidades, foi feita uma anlise da complexidade envolvida em cada uma delas e estabelecida uma iterao e meia para execuo desta release inicial. Cada iterao abrangeu cerca de duas semanas e implementou as estrias referentes a essa release.

A estria Preencher informaes pessoais do doador foi estimada em dez pontos, o que teoricamente equivale a uma iterao, enquanto que Realizar deteco foi estimada em apenas cinco pontos. vlido ressaltar que essa pontuao apenas uma estimativa. Os dados reais mostrados ao final desta seo. A Figura 3 mostra a tela do sistema correspondente identificao do doador.

Figura 3 - Tela para preenchimento dos dados pessoais do doador.

Na segunda release, foram implementados os mdulos avaliao do potencial doador e abordagem dos familiares. Esses mdulos so, de certa forma, independentes do mdulo de deteco, e por isso houve uma maior flexibilidade na ordem de suas implementaes. Devido ao grande nmero de informaos referentes a avaliao do doador, este mdulo foi dividido em dois outros mdulos: avaliao antecedente e avaliao laboratorial. A implementao da segunda release foi estimada em duas iteraes diante da especificao dos cartes do usurio e da complexidade das estrias Preencher fatores antecedentes, Preencher abordagem familiar e Processar avaliao (laboratorial) envolvidas nessa release. A funcionalidade Preencher fatores antecedentes diz respeito a fatores que inviabilizam automaticamente a doao de determinados rgos, como por exemplo o fato de o provvel doador j ter sofrido algum tipo de cirurgia ocular exclui a possibilidade de um reaproveitamento de crneas. O mdulo avaliao laboratorial foi responsvel por armazenar dados da hemocultura realizada no doador e reao a algumas sorologias, como HIV, Chagas, HBs-ag e anti-HCV (usadas na deteco de Hepatite B e C, respectivamente). tambm de interesse da CNCDO manter informaes sobre a existncia de documentos que comprovem a deciso tomada pela famlia: declarao de doao, declarao de recusa, sinais vitais e balano hdrico e pronturio de morte enceflica. Todas essas informaes esto presentes na opo abordagem familiar do sistema Nova Vida.

Em meio ao desenvolvimento dos mdulos, o cliente apresentou novas funcionalidades a serem implementadas no sistema, referente a gerao de relatrios estatsticos. Este incremento ao sistema, gerou a realizao de um novo planejamento. Aps o preenchimento de novos cartes com as funcionalidades desse novo mdulo, a equipe de desenvolvimento estimou as iteraes necessrias, e estabeleceu novas prioridades no desenvolvimento. O mdulo de gerao de relatrios foi o menos prioritrio em ordem de implementao, j que seriam necessrias as informaes da avaliao do potencial doador. Para sua execuo usouse sendo estudada a ferramenta Crystal Reports [Cioccari e Montoya, 2003] para .NET, visto que ela possui um ambiente de desenvolvimento integrado com o Microsoft Visual Studio .NET. A busca ativa um mecanismo que a CNCDO utiliza para buscar informaes a respeito dos bitos nos hospitais. Para sua realizao, um funcionrio da CNCDO telefona para os hospitais em intervalos de tempo de no mnimo trs horas, ou realiza uma visita aos hospitais quando dispe de transporte para faz-lo. Diante disso, a equipe de desenvolvedores sugeriu que esse mecanismo fosse automatizado atravs do NovaVida, dispondo uma opo na Web onde o representante da CNCDO no hospital pudesse alimentar o sistema com essas informaes. A idia foi bem aceita pelo cliente, e a busca ativa diria passou a constituir a terceira release do sistema, junto a gerao de relatrios e o mdulo de autenticao, que ainda est sendo desenvolvida. Essa release composta pelas estrias Gerar relatrio estatstico, Informar busca ativa e Realizar login, as quais foram estimadas em dez, quatro e quatro pontos, respectivamente. Alguns desvios no tempo de implementao das estrias deveu-se a atividades extras imprescindveis ao desenvolvimento do sistema, como por exemplo, configurao de ambientes, normalizao de banco de dados e correes de erros. 4.2 Arquitetura da aplicao Esta seo descreve a arquitetura escolhida para o desenvolvimento do projeto. A arquitetura aqui proposta dividida em camadas fsicas, separando a lgica do negcio da apresentao e do acesso aos dados. Neste trabalho, a arquitetura do projeto foi dividida em quatro camadas: interface, negcio, dados e entidades. O Sistema Nova Vida acessado atravs de navegadores Internet e executa em servidores ASP.NET, como o servidor IIS (Internet Information Services), responsvel pelo contedo dinmico das pginas. O contedo esttico da pgina tambm armazenado no IIS. Para que as pginas ASP.NET possam ser executadas, necessria a instalao do Microsoft .NET Framework 1.1. A base de dados do sistema est executando no mesmo servidor, por falta de recursos computacionais da CNCDO-SE. O SGBD utilizado e instalado no servidor o Microsoft SQL Server 2000 [Nielsen, 2002]. A modelagem do banco de dados foi feita utilizando o recurso grfico, atravs da criao de diagramas, do Microsoft SQL Server 2000 [Nielsen, 2002]. A modelagem obtida procurou respeitar as formas normais, obtendo uma organizao eficiente dos dados dentro do banco de dados, com objetivo de eliminar redundncias e garantir a dependncia de dados.

4.3 Avaliao da metodologia Nesta seo discutimos os valores e as prticas da metodologia XP, junto plataforma .NET, que colaboraram para o andamento do projeto, como tambm aqueles que foram desinteressantes evoluo do mesmo. Aps alguns meses de trabalho, foi possvel estabelecer os pontos positivos e negativos daquilo que o XP recomenda, os quais proporcionaram um vasto aprendizado. Dentre os valores em que o XP se baseia, o feedback permitiu que o cliente conduzisse o desenvolvimento, garantindo que a equipe direcionasse as atenes para aquilo que geraria mais valor. Atravs da comunicao, procurou-se envolver ativamente o cliente, fazendo com que ele se tornasse parte integrante da equipe de desenvolvimento. Com o valor simplicidade, foi possvel implementar apenas aquilo que era suficiente para atender a cada necessidade do cliente. Atravs da coragem, acreditou-se na metodologia com o intuido de fazer o software evoluir com segurana e agilidade. Logo, todos os valores estiveram inerentes s atividades realizadas pela equipe de desenvolvimento durante todo o perodo do projeto. Dentre as prticas do XP, uma das mais importantes a prtica que afirma que o cliente deve estar sempre presente, para que ele possa conduzir o desenvolvimento do sistema. Dentre as formas que o cliente est presente, pode-se citar: contato face-a-face, contato por telefone e contato por e-mail, nessa ordem de relevncia. A maioria dos contatos deu-se pessoalmente e por telefone, os quais foram feitos medida que a equipe de desenvolvimento sentia necessidade. Apesar de o XP pregar o contato dirio com o cliente, este, no entanto, foi de difcil concretizao, pois o nosso cliente um profissional da rea de sade que trabalha em diversos hospitais. Mesmo sem o contato dirio, o desenvolvimento do projeto correu normalmente sem ser prejudicado. O jogo do planejamento foi seguido de forma natural, em que as necessidades do cliente foram chamadas de estrias e estimadas em pontos. Como j anteriormente especificado, o nosso projeto foi dividido em releases, restando apenas a ltima, que est em fase de implementao. Isso mostra que essa prtica benfica, pois o cliente tem continuamente o contato com algumas funcionalidades do sistema, dando o retorno equipe de desenvolvimento. O contato dirio das participantes do projeto, seja no ambiente de trabalho ou no momento do desenvolvimento deste projeto, fazia com que o stand up meeting acontecesse de forma natural e descontrada. Apesar da experincia e cumplicidade das integrantes do projeto em trabalharem juntas j em outras atividades durante toda a graduao, houve dificuldade em estabelecer a programao em par neste trabalho. Para verificar qual mecanismo seria o mais benfico para o projeto, optamos durante o primeiro ms seguir a metodologia programando em par e no segundo ms de desenvolvimento, programando cada uma em um computador. Percebeu-se que o rendimento foi sensivelmente maior na produo de artefatos quando a dupla programou em computadores diferentes, pois as mesmas puderam se familiarizar melhor com a tecnologia, com a ferramenta e com linguagem de programao, todas estas desconhecidas. Nesta experincia, a tcnica de programao em par atrapalhou o andamento do projeto. Apesar de no executar os testes de unidade por meio de ferramentas especializadas que tornam os testes automatizados, como a metodologia XP recomenda, pois o IDE utilizado

no disponibiliza este recurso, os testes foram feitos rigorosamente atravs das opes oferecidas para depurao. Este recurso foi amplamente utilizado durante todo o projeto. As prticas de projeto simples e refatorao foram seguidas estritamente, pois implementamos aquilo que o cliente desejou sem adicionar necessidades futuras, sem especulao, para proporcionar ao cliente o acesso rpido funcionalidade. Quando uma nova necessidade foi solicitada, as tcnicas de refatorao foram utilizadas para atender generalizao. Isso gerou retrabalho, mas nas vezes em que houve a refatorao, o cdigo foi melhorado, o que ajudou na manuteno e na legibilidade. Um ponto negativo que a verso do IDE utilizado nesse projeto no apresenta recursos facilitadores para aplicao da refatorao. Mesmo assim, esse processo foi feito de forma manual. As prticas de cdigo padronizado e cdigo coletivo j eram inerentes ao desenvolvimento das atividades das integrantes deste projeto, devido experincia j vivida ao longo da graduao. A experincia com projetos anteriores facilitou bastante a aplicao de tais prticas, melhorando a escrita e a padronizao do cdigo. A utilizao de metforas no foi necessria pela equipe de desenvolvimento, pois j existia uma comunicao de forma simples e direta. O XP recomenda que a equipe de desenvolvimento trabalhe em um horrio estipulado e evitando fazer horas extras, denominando tal prtica de ritmo sustentvel. Este ponto no foi respeitado, pois as integrantes do projeto alm de participarem desta atividade, possuem uma rotina de 40 horas semanais dedicadas a atividades de desenvolvimento de software na empresa em que as mesmas trabalham. Portanto, os horrios estipulados, quatro horas dirias, foram bem utilizados e ultrapassados, abrangendo tambm os dois turnos dos sbados e dos domingos. A integrao entre o sistema existente e uma nova funcionalidade foi um ato constante na rotina da equipe de desenvolvimento, em que os testes necessrios eram realizados com freqncia, fazendo com que os erros fossem identificados imediatamente. Ento, a prtica integrao contnua foi realizada com xito. A presena da documentao de um sistema importante, pois aps a finalizao do desenvolvimento, pode existir a necessidade de voltar ao cdigo, seja para correes ou para implementao de novas funcionalidades. Documentar s o necessrio, como sugerido pela metodologia XP, foi uma prtica bem empregada pela equipe de desenvolvimento. Para utilizar uma ferramenta que atenda aos requisitos exigidos pela metodologia XP, necessrio que ela disponibilize uma infra-estrutura ideal ao desenvolvimento de software e deve apresentar: Code completion funcionalidade pertencente ao IDE que completa o cdigo atravs da combinao de teclas, agilizando o processo de digitao e diminuindo a margem de erros no cdigo; Code inspection funcionalidade que analisa o cdigo medida que ele vai sendo produzido, reduzindo a entrada de defeitos no sistema; Alm de um poderoso editor, compilador, montador, depurador, distribuio, testes automatizados, refatorao e modelagem. No entanto, a verso da ferramenta utilizada para o projeto, Visual Studio 2003 [CAMARA, 2005], no oferece recursos para refatorao, testes de unidade e para modelagem (engenharia reversa). Apesar disso, a ferramenta apresentou-se adequada para o desenvolvimento de software segundo a metodologia XP.

Alm das caractersticas desejveis para um IDE adequar-se metodologia XP, a ferramenta trouxe facilidades quanto gerao de interfaces Web no que diz respeito aos controles de entrada e sada de dados, o que proporcionou agilidade na construo dos Web Forms e disponibilidade imediata de interface grfica para os testes integrados com as outras camadas da aplicao. 5. Concluses Este trabalho proporcionou um estudo da metodologia XP e com uso da plataforma .NET, atravs de um estudo de caso para rea mdica, o sistema Nova Vida. Este proporcionou o conhecimento e experincia em uma metodologia e uma plataforma de desenvolvimento, ambas desconhecidas pelas integrantes do projeto. Alm disso, foi possvel experimentar e analisar criticamente pontos positivos e negativos da metodologia de desenvolvimento adotada. Ainda que a programao em par, uma das prticas defendidas pela metodologia XP, no tenha trazido benefcios ao projeto, os bons resultados obtidos neste trabalho deveu-se plena aplicao das demais prticas desta metodologia (planejamento, simplicidade do projeto, reunies freqentes, testes, refatorao, entre outras). A aplicao das prticas em conjunto, auxiliadas pela robustez da ferramenta utilizada, culminou em um desenvolvimento gil e de qualidade. Alm das dificuldades no uso de algumas prticas, um dos entraves encontrados pela equipe foi a inexperincia quanto ao conhecimento da plataforma .NET. Mesmo utilizando uma poderosa ferramenta, o Visual Studio que melhora a produtividade, o conhecimento das APIs de C# requer tempo e prtica. Isto prejudicou o andamento normal do processo, comparando-se ao possvel uso alguma ferramenta j conhecida pela equipe de desenvolvimento. Apesar disso, o usurio teve o retorno no tempo esperado, com pequena margem de atraso do planejado inicialmente. Apesar do estudo realizado j indicar fatores positivos e negativos da integrao de .NET e XP no desenvolvimento de projetos de pequeno porte, uma avaliao mais precisa se faz necessria atravs do desenvolvimento de um nmero maior de estudos de caso. Este um possvel trabalho futuro. Alm disso, pretende-se disponibilizar o acesso do Sistema Nova Vida nos hospitais do Estado, possibilitando que o processo da avaliao do doador e da busca ativa diria de bitos seja realizado pela prpria coordenao dos hospitais vinculadas CNCDO-SE. 6. Referncias BECK, Kent. Extreme Programming explained: embrace change. 1. ed. Reading, MA: Addison-Wesley, 2000. CAMARA, Fbio. Dominando o Visual Studio.Net com C#. 2. ed. Visual Books, 2005. CIOCCARI, Fabio Rafael; MONTOYA, Carlos Eduardo. Crystal Reports 9: Guia Prtico. Visual Books, 2003.

CRONIN, Gareth. A Case Study in Single Developer eXtreme Programming. Disponvel online em: http://casualstaffhr.sourceforge.net/eXtremeSolo.pdf. ltima visita em abril de 2006. DEITEL, Harvey M.; DEITEL, Paul J. Java: Como Programar. 6. ed. Prentice-Hall, 2005. Manifesto for Agile Software Development. Disponvel on-line em: http://agilemanifesto.org/. ltima visita em abril de 2006. NIELSEN, Paul. Microsoft SQL Server 2000 Bible. Hungry Minds Inc, 2002 SANTOS, Cristina de Mendona; TAVARES, Ana Beatriz. Microsoft .NET: Framework e Aplicativos Web. Campus, 2001. SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. INFOCOMP Journal of Computer Science 3: 8-13. 2004. TELES, Vincius Manhes. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. 1. ed. So Paulo: Novatec, 2004. TELES, Vincius Manhes. Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming. Rio de Janeiro, 2005. Dissertao (Mestrado em Informtica) - Ncleo de Computao Eletrnica, Universidade Federal do Rio de Janeiro. TURTSCHI, Adrian; WERR, Jason; HACK, Greg. C# .NET: Guia do Desenvolvedor: Curso Completo. 2. ed. Rio de Janeiro: Atlas Books, 2005.