I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Processos de desenvolvimento colaborativo de software em hidrulica e recursos hdricos: a experincia da UFCG

Carlos de Oliveira Galvo Professor Adjunto, Unidade Acadmica de Engenharia Civil da Universidade Federal de Campina Grande UFCG, 58.109-970 Campina Grande-PB Fone: (83) 3310-1155 galvao@hidro.ufcg.edu.br rica Cristine Medeiros Nobre Machado Doutoranda em Recursos Naturais, Universidade Federal de Campina Grande - UFCG, 58.109-970 Campina Grande-PB Fone: (83) 3310-1461 erica@hidro.ufcg.edu.br Brbara Lopes Voorsluys Pesquisadora assistente, Unidade Acadmica de Sistemas e Computao, UFCG, 58.109-970 Campina Grande-PB Fone: (83) 3310-1365 barbara@lsd.ufcg.edu.br Eliane Cristina de Arajo Professora Assistente, Unidade Acadmica de Educao e Unidade Acadmica de Sistemas e Computao, UFCG, 58.109-970 Campina Grande-PB Fone: (83) 3310-1365 eliane@dsc.ufcg.edu.br Ivonaldo de Sousa Lacerda Rodolfo Luiz Bezerra Nbrega Mestrando em Engenharia Civil e Ambiental, UFCG, 58.109-970 Campina Grande-PB Fone: (83) 3310-1461 {ivonaldo, rodolfo}@hidro.ucfg.edu.br

Resumo: Este artigo apresenta a experincia de desenvolvimento de softwares em hidrulica e recursos hdricos de forma colaborativa, em redes interinstitucionais e interdisciplinares, envolvendo, no desenvolvimento, profissionais de Informtica. So descritos os processos de desenvolvimento dos softwares e de gerncia dos projetos, incluindo as ferramentas computacionais para apoio a esses processos. A avaliao das experincias mostra os benefcios da utilizao desses processos e ferramentas para a produo de software de qualidade. Abstract: This paper presents experience of software development for hydraulic and water resources applications, collaboratively in multi-institutional and multi-disciplinary networks, involving computer science teams. Software development and project management processes are described, as well as the computational tools for supporting these processes. The experiences evaluation shows the benefits of applying these processes and tools for producing high quality software. Palavras-chave: Desenvolvimento de software; Extreme Programming; Gerncia de projetos.

1. Introduo Nos anos recentes, cada vez mais os mtodos e procedimentos gerados na pesquisa em Hidrulica, Hidrologia, Recursos Hdricos e reas correlatas, assim como em outras reas da cincia e tecnologia, tm sido disponibilizados aos usurios atravs de softwares, no raras vezes de razovel complexidade. Os softwares, que, nos anos 1970, eram apenas programas de computadores, de poucas linhas de cdigo, sem interfaces amigveis de comunicao com o usurio e programados pelos prprios especialistas na rea de conhecimento, hoje so sistemas complexos muitas vezes desenvolvidos para a Web por programadores com formao em Informtica, a partir de especificaes dos especialistas e pesquisadores das reas temticas. Os usurios desses sistemas, antes apenas os iniciados em linguagens de programao, como Fortran, por exemplo, hoje so uma grande massa de engenheiros e outros especialistas, a maioria sem experincia em programao.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Outra caracterstica importante da atual Hidroinformtica o desenvolvimento dos mtodos e respectivos softwares atravs de redes colaborativas de P&D, interinstitucionais e interdisciplinares, com os participantes dispersos geograficamente no pas e tambm no exterior. H necessidade de ferramentas para a gerncia dos projetos e comunicao entre os participantes, facilitando as discusses, o consenso e as conseqentes especificaes, testes, documentao e transferncia aos usurios. As agncias financiadoras e a comunidade de usurios desejam produtos de qualidade, robustos e sustentveis, ou seja, que possam evoluir de forma colaborativa, atravs da prpria comunidade de usurios e pesquisadores, com ou sem participao dos desenvolvedores originais. Grupos de pesquisa das reas de Hidrulica e Recursos Hdricos e Informtica da Universidade Federal de Campina Grande (UFCG) tm, nos ltimos sete anos, conduzido projetos de desenvolvimento de software cientfico, em parceria com outras instituies, buscando atender aos requisitos acima enumerados. Foram utilizados processos de desenvolvimento, de gerncia e ferramentas de apoio do estado-da-arte tecnolgico com bastante sucesso. Este artigo relata esta experincia em trs casos com distintas caractersticas. 2. Necessidade de um processo de desenvolvimento de software Na gesto de um projeto o objetivo conciliar tempo, escopo e recursos para que se tenha um resultado de qualidade ao seu trmino. A dificuldade de prever com antecedncia as caractersticas das funcionalidades do software (seus recursos funcionais) e a complexidade para sua implementao provoca normalmente alteraes no escopo inicial como: acrescentar ou mudar os objetivos; demorar mais que o planejado; aumentar seu custo. Assim, necessrio que o plano do projeto seja periodicamente avaliado, pois uma falta de controle sobre o escopo poder impactar na qualidade do sistema e no no cumprimento dos objetivos no prazo proposto. Para ajudar nesta gesto existem os processos de desenvolvimento, que estabelecem um passo-a-passo de como guiar as pesquisas e desenvolvimento para se atingir os objetivos finais. Processos de desenvolvimento tradicionais investem tempo analisando e projetando solues para posteriormente aplic-las, quando muitas vezes no h mais tempo disponvel para realizar este desenvolvimento com qualidade. Outro problema comum a insatisfao do cliente com a soluo encontrada. Isto acontece porque, neste tipo de processo, o cliente participa apenas na fase de exposio do problema, no acompanhando a evoluo de sua anlise. Em projetos multi-disciplinares muito comum que a equipe de desenvolvimento no possua conhecimentos slidos da rea do problema. Assim, um mau entendimento das especificaes pode ocorrer, principalmente quando at mesmo o cliente no tem clareza sobre quais so suas necessidades. Processos modernos propem etapas mais curtas de anlise e desenvolvimento, onde durante toda a durao do projeto o cliente pode avaliar e criticar a soluo proposta. Este tipo de projeto permite que mudanas sejam feitas sem um custo muito alto, e permite que o cronograma seja reavaliado. Riscos so inerentes a qualquer projeto de desenvolvimento, podendo ser um mau entendimento dos requisitos, alterao completa ou parcial destes requisitos, m escolha de funcionalidades, no cumprimento de prazos, produto com alta taxa de defeitos e alto custo de manuteno, resultando na insatisfao do cliente ou at no cancelamento do projeto. Busca-se seguir um processo para que os prazos possam ser cumpridos corretamente e

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

que o produto seja desenvolvido com qualidade. O processo deve ser criado de acordo com as necessidades e realidade da equipe de trabalho, devendo sua eficincia ser constantemente reavaliada, para que este ajude realmente e no dificulte o trabalho da equipe. A necessidade de utilizar-se de um processo vai alm de reduzir os riscos de insucesso do projeto, mas objetiva tambm reduzir o impacto das mudanas de metas estratgicas do cliente, aumentar a produtividade durante a vida do sistema e, principalmente, motivar a equipe de trabalho, que assim consegue ver em curto prazo os resultados de seus esforos. Neste contexto, um interessante processo de desenvolvimento o eXtreme Programming, mais conhecido com XP. Segundo Kent Beck (2000), uma maneira leve, eficiente, de baixo custo, flexvel, previsvel, cientfica e divertida de desenvolver software. XP um processo que oferece um conjunto de boas prticas e estratgias para administrar os riscos de um projeto de desenvolvimento. A prxima seo aborda as caractersticas deste processo de desenvolvimento. 3. O processo de desenvolvimento eXtreme Programming - XP XP oferece algumas promessas para a equipe de execuo do projeto. Para os desenvolvedores promete que iro passar a maior parte do tempo fazendo o que realmente importante, e tomando apenas decises que lhes so confortveis. Para cliente e gerentes promete feedbacks concretos em intervalos de poucas semanas, e a possibilidade de mudar o curso do projeto no meio do desenvolvimento sem gerar com isso custos exorbitantes. Proporciona, portanto, controle sobre quem est fazendo o que, o quanto foi feito, sua qualidade e principalmente quando estar pronto. Para mitigar os riscos a que qualquer projeto est sujeito, XP oferece um conjunto de boas prticas a serem seguidas: Ciclos de liberao curtos: umas das principais regras a produo de resultados intermedirios durante a vida do projeto. Esta simples regra prov segurana para todos os envolvidos no projeto. Clientes no precisam esperar at o final do projeto para avaliar concretamente suas solicitaes, podendo avaliar o desenvolvimento do projeto e solicitar mudanas sem gerar um grande impacto ao cronograma; gerentes conseguem avaliar periodicamente o cumprimento dos prazos e com isto estabelecem mais facilmente a prioridade das atividades; desenvolvedores sentem-se mais seguros sobre o trabalho realizado, vendo resultados em curto prazo de seus esforos e motivados pela satisfao do cliente. Cliente parte do time: projetos desenvolvidos com participao ativa do cliente tm chances muito maiores de obterem sucesso do que projetos onde o cliente apenas participa no seu incio e final. Um cliente participativo consegue evitar que os requisitos sejam mal entendidos pelos desenvolvedores, estabelece prioridades das atividades de acordo com suas necessidades e junto com desenvolvedores refina os requisitos do projeto. Testes: uma das principais insatisfaes dos clientes so defeitos que surgem aps a entrega do projeto, gerando com isto alto custo de manuteno. Uma das formas de minimizar isto fazendo com que testes ocorram sempre durante o desenvolvimento do projeto. Projetos simples: XP incentiva prticas que reduzam a complexidade do sistema, priorizando sempre o desenvolvimento de uma arquitetura simples que suporte a funcionalidade especificada pelo cliente. Refora ainda que apenas o problema atual

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

deve ser solucionado, no deve-se pensar em problemas futuros. Refatoramento: como a premissa resolva o problema rapidamente as solues aplicadas nem sempre so as melhores no que se referem a desempenho e clareza. Para isto, XP prope que o desenvolvedor reavalie e refatore o cdigo sempre que perceber que h necessidade. Programao em pares: XP prope que duas pessoas trabalhem juntas numa mesma mquina; com isto as solues propostas podem ser melhor elaboradas e garante-se que o conhecimento desta soluo no posse de apenas uma pessoa. Posse coletiva do cdigo: toda a equipe responsvel por todo o cdigo do sistema, e sempre que algum perceber algo errado deve manifestar-se. Os trabalhos desenvolvidos pela equipe devem ser integrados continuamente, e devem seguir um padro para permitir que posteriormente qualquer pessoa consiga entender facilmente. Terminologias usadas em XP: Viso do Cliente (VC): a viso do cliente sobre uma funcionalidade ou requisito do sistema. Quem escreve uma VC o prprio cliente, acompanhada de um teste de aceitao. Devem ter informao suficiente para que os desenvolvedores possam estimar o tempo de desenvolvimento. Tarefas: so pequenas atividades que conduzem para a realizao de uma VC. Iterao: uma diviso do plano de desenvolvimento em pores de 1 a 3 semanas, onde um conjunto de VCs sero total ou parcialmente executadas. As iteraes permitem fazer medies concretas do progresso e planejamento do projeto. Liberaes: so verses funcionais entregues pela equipe de desenvolvimento aos clientes.

XP define papis que podem ser assumidos pela equipe executora do projeto. Projetos menores, em sua maioria, no possuem recursos para que todos os papis sejam assumidos por diferentes pessoas, sendo comum ento o acumulo de papis. Cada projeto deve avaliar sua real necessidade e aplicar apenas os papis que realmente julgue necessrios. Papis definidos pelo XP: Cliente: define os requisitos funcionais e no-funcionais do sistema, priorizando a ordem que o time de desenvolvimento deve executar. O cliente tambm responsvel por refinar a especificao e prover um teste de aceitao. Desenvolvedor do software: auxilia o cliente na definio das atividades e requisitos do sistema. Cada desenvolvedor escolhe, dentre as atividades definidas, quais ir executar, assim como estima o tempo de execuo para cada uma. O desenvolvedor se responsabiliza pela elaborao da arquitetura e esquema lgico dos dados, implementao de testes, e integraes contnuas com o repositrio de verses. Gerente: acompanha a execuo das atividades e o andamento do plano de trabalho. Revisa o planejamento quando necessrio avaliando os riscos que possam surgir. O gerente elo que garante a comunicao entre o financiador e outros grupos de pesquisa. Lder de linha: o responsvel pelas tarefas que esto sendo desenvolvidas por ele e

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

pelos demais membros da equipe, verifica se os dados de acompanhamento esto sendo corretamente preenchidos, e garante e incentiva a criao de testes, sendo o responsvel pela reviso destes. Gerente de Configurao: para projetos que necessitam manter controle de verso de produtos este gerente o responsvel pelo ambiente de desenvolvimento: garante que todos os desenvolvedores fazem o uso do repositrio, controla a criao de cada liberao e define o espao de trabalho para o desenvolvimento. Gerente de Qualidade: garante que os padres de codificao e boas prticas de desenvolvimento esto sendo seguidas, assim como que revises de cdigo e refatoramentos aconteam ao menos semestralmente. Coach: responsvel por monitorar, reforar e refinar o processo. Participa de reunies de projeto conduzindo as atividades de planejamento e acompanhamento. Fornece suporte tcnico para a equipe de desenvolvimento buscando e avaliando novas ferramentas. Tracker: este papel normalmente assumido pelo coach, sendo responsvel pelo andamento das atividades garantindo o cumprimento do plano de liberao. Gerente de produto: controla as solicitaes de mudanas que chegam ao produto, elaborando o plano de novas liberaes junto ao cliente. Tambm responsvel por definir os critrios de qualidade do produto (documentao, usabilidade, robustez), assim como fazer a prospeco de novos clientes para o produto. Consultor: um especialista de determinada rea que debate junto com a equipe sobre questes que exijam fundamentao terica nas suas reas de pesquisa, auxiliando assim na especificao do cliente e nas tarefas de pesquisa.

Tendo as boas prticas e os papis definidos o momento de executar o processo, e o XP faz isto acontecer na forma de reunies. Diferentes tipos de reunies fazem a comunicao acontecer com toda a equipe, envolvendo os interessados no problema e tornando o ambiente de trabalho mais agradvel e produtivo. Em XP o incio se d com uma iterao, marcada por uma reunio de planejamento que pode acontecer quinzenalmente. Nestas reunies a equipe toda envolvida para definir o planejamento das liberaes. Tanto requisitos funcionais como no-funcionais sero levantados e discutidos juntamente com o cliente. O resultado desta reunio a escrita de Vises do Cliente (VCs) que especificam um requisito ou funcionalidade e so acompanhadas por um teste de aceitao. Aps o cliente concluir a definio das VCs, a equipe de desenvolvimento ir definir as tarefas que sero necessrias e estimar o tempo de cada uma. Aps o cliente definir a prioridade de implementao os desenvolvedores assumiro a execuo das tarefas. Durante uma iterao necessrio que ocorram reunies de acompanhamento para gerenciar o progresso do plano de liberao. Essas reunies podem ocorrer em pequenos intervalos de dias, servindo para monitorar o progresso das atividades e fazer alocao de tarefas para a equipe. Reunies dirias, conhecidas como Stand Up Meetings, devem ocorrer para garantir a comunicao da equipe, para que todos acompanhem a evoluo do trabalho. Quando necessrio ainda podem ocorrer reunies tcnicas para discusses especficas, como o projeto arquitetural, o projeto de esquema lgico de dados, a apresentao de

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

alternativas de solues, problemas encontrados, entre outras. 4. Ferramentas de Apoio Diversas ferramentas podem ser utilizadas para o desenvolvimento de projetos de software e para facilitar o acompanhamento de um processo de desenvolvimento como o XP. A escolha de tais ferramentas depende de fatores que variam desde a linguagem de programao adotada pela equipe, domnio da ferramenta, gosto pessoal e at os recursos financeiros disponveis para a compra dos pacotes de software escolhidos. A seguir d-se uma viso geral das ferramentas de apoio ao desenvolvimento e ao acompanhamento do processo XP, usadas nos projetos de software descritos neste artigo. A maioria das ferramentas gratuita e disponvel livremente para obteno atravs da Internet, exceto o Jira, que uma ferramenta de gesto de problemas. Este software proprietrio, desenvolvido pela empresa Atlassian (http://atlassian.com/software/jira), todavia, pudemos utiliz-lo gratuitamente devido licena de uso especial, concedida pela empresa, a projetos de cdigo aberto. 4.1 Ferramentas de apoio ao desenvolvimento As ferramentas de apoio ao desenvolvimento so aquelas utilizadas pelos programadores para a codificao, testes e controle de verso dos programas. A mais importante delas o ambiente integrado de desenvolvimento (do ingls, IDE). O IDE Eclipse (Figura 1) uma ferramenta de software livre, gratuita e muito popular entre os programadores. Ela incorpora diversas funcionalidades, tais como edio, compilao e ambiente para testes, todas em um mesmo programa, agilizando o trabalho dos programadores. O Eclipse pode ser usado para escrever programas em diversas linguagens de programao. Alm disso, atravs dos plugins (pequenos softwares que ampliam as funcionalidades dos programas) ele pode interagir com outras ferramentas de apoio ao desenvolvimento. Com a agregao dos plugins, o Eclipse torna-se uma ferramenta ainda mais rica e com um papel importante no rendimento da equipe, j que os programadores no precisam ficar alternando entre um software e outro para cumprir os passos de desenvolvimento prescritos no processo XP.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Figura 1 Ambiente de desenvolvimento integrado Eclipse Existem, tambm, as ferramentas de apoio ao desenvolvimento de testes que so fundamentais para o correto seguimento do processo XP. Os testes de software podem ser feitos em diversas etapas do desenvolvimento e abrangendo escopos diferentes. Alguns tipos de testes so: testes de aceitao, testes de regresso, testes de sistema, testes de unidade, dentre outros. Em alguns projetos relatados neste trabalho, investimos nos testes de aceitao usando a ferramenta EasyAccept (http://easyaccept.org). Com esta ferramenta possvel validar o quo bem sucedido foi o desenvolvimento do software baseado nas expectativas do cliente. Com o EasyAccept o cliente, com algum auxlio de um desenvolvedor, pode escrever os casos de testes. A experincia de uso do EasyAccept foi importante para garantir que o que era desenvolvido a cada iterao recebia o selo de aprovao do cliente. Em uma outra perspectiva, os testes de unidade so teis para garantir a correo do cdigo que o programador est fazendo. Uma bateria de testes suficientemente bem desenvolvida torna mais seguros os constantes refatoramentos e a adio de novas funcionalidades requeridos em um processo de desenvolvimento como o XP. O desenvolvimento dos testes de unidade auxiliado pela ferramenta JUnit (http://junit.org). O JUnit tem plugin para o Eclipse o que facilita a sua utilizao pelos programadores que trabalham neste IDE. Outra importante ferramenta de apoio ao desenvolvimento so os softwares de controle de verso. Esse tipo de software particularmente importante quando o desenvolvimento realizado em equipes grandes ou dispersas geograficamente. Os controladores de verso organizam o acesso aos arquivos bloqueando a edio conjunta dos mesmos e mantendo um histrico de atualizaes. Eles controlam no apenas os arquivos contendo cdigos-fonte, mas tambm arquivos com a documentao e manuais do software.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

O CVS foi o software de controle de verso utilizado pelos projetos aqui relatados. O CVS tambm tem plugin para Eclipse o que o torna integrado ao desenvolvimento dos programas. 4.2 Ferramentas de apoio ao processo Consideramos como sendo ferramentas de apoio ao processo as que auxiliam os clientes, programadores, gerentes e demais atores envolvidos no desenvolvimento de software a estabelecer uma comunicao mais efetiva e de qualidade de forma a garantir o cumprimento das etapas estabelecidas pelo processo. De acordo com a nossa experincia, apresentamos trs tipos de ferramenta que foram bastante teis no desenvolvimento dos projetos aqui apresentados. A principal delas a ferramenta de planejamento e acompanhamento de projeto. A ferramenta que adotamos foi o XPlanner (http://xplanner.org). Ela foi concebida especialmente para equipes que desenvolvem seguindo o processo XP. Com o XPlanner, possvel fazer o planejamento das iteraes, criar tarefas, atribuir as tarefas a determinado desenvolvedor, estimar o tempo para cada tarefa, dentre outras atividades de planejamento. O XPlanner oferece funcionalidades para acompanhar o andamento do projeto atravs de grficos, e de vises que mostram em que tarefa cada membro da equipe est trabalhando e como vai o seu desempenho (Figura 2). No dia-a-dia, o XPlanner funciona como uma agenda para os desenvolvedores e para os trackers. As informaes sobre o que cada um est fazendo ou deve fazer neste dia esto centralizadas nesta ferramenta. A experincia do uso do Xplanner positiva. Ele garante que a ordem de realizao das tarefas ser feito de acordo com o planejado, orienta e organiza as atividades dos membros da equipe e diminui o tempo que o lder de linha despende dando instrues a cada membro de sua equipe.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Figura 2 Ferramenta para planejamento e acompanhamento XPlanner Outra ferramenta importante para favorecer a comunicao entre a equipe, principalmente em um grande projeto, um sistema para a criao colaborativa de contedo como o wiki. Os wikis tornaram-se bastante conhecidos com a popularizao da wikipedia (http://wikipedia.org), uma enciclopdia escrita por voluntrios e publicada na Web atravs de um wiki. Com esta ferramenta possvel publicar contedos na Web, escrevendo-os no prprio site, utilizando uma formatao mais simples que a forma tradicional de escrever sites atravs da linguagem de marcao HTML. Assim, possvel criar um site, que pode ser atualizado por todos os integrantes do projeto, para a integrao da equipe e tambm para concentrar informaes relativas ao mesmo: objetivos, metas, cronogramas, horrios dos membros da equipe, documentos importantes, etc. Alm disso, podem ser criadas reas mais interativas que registrem discusses de propostas ou pesquisas a fim de serem revisitadas posteriormente (Figura 3). Nossa experincia de uso do TWiki (um tipo de ferramenta wiki) foi bem positiva, mas mostrou-nos que, para que ele seja realmente adotado e til, o seu uso deve ser incentivado, desde o incio, pelos gestores do projeto.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Figura 3 Ferramenta para a criao colaborativa de contedo TWiki Por fim, temos as ferramentas de gesto e acompanhamento de problemas (issues). Tais ferramentas servem inicialmente para cadastrar os bugs (erros) do software reportados pelos usurios ou pela prpria equipe de desenvolvimento. Alm disso, mantm, ordenam, organizam requisies para a adio de novas funcionalidades e auxiliam o processo de gerao do documento de lanamento (release notes) para cada nova verso do software. O Jira, a ferramenta de gesto de problemas escolhida, foi utilizado pela equipe de maneira bastante satisfatria. Usando o Jira os bugs podiam ser reportados, de forma bem detalhada, medida que eles apareciam (Figura 4). Com uma descrio mais rica, os desenvolvedores podiam mapear melhor o problema, repetir a situao em que ocorre o erro e corrigi-lo mais eficientemente.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Figura 4 Ferramenta para a gesto de problemas JIRA 5. Experincia no projeto SmartPumping 5.1 Descrio do projeto O SmartPumping Controle inteligente de sistemas de bombeamento em redes de escoamento de petrleo um produto desenvolvido atravs de uma parceria entre a UFCG e a PETROBRAS (GALVO et al., 2004; http://dsc.ufcg.edu.br/smartpumping). O software foi financiado com recursos da PETROBRAS e do CT-PETRO - Fundo Setorial do Petrleo e Gs Natural, atravs da FINEP - Financiadora de Estudos e Projetos do Ministrio de Cincia e Tecnologia. O SmartPumping, desenvolvido entre 2002 e 2007, um software de dimensionamento, simulao, controle e operao otimizada de sistemas adutores de petrleo onde os principais objetivos so (BRASILEIRO et al., 2003): garantir a mxima eficincia no transporte com o menor custo de energia; reduzir a presso nos dutos e ns; reduzir os riscos de falhas operacionais e de poluio ambiental e a perda de produo; dimensionar novas malhas ou elementos do sistema (tanques, bombas e dutos). uma ferramenta computacional que visa dar suporte aos operadores das malhas de escoamento e contribuir para a automao do seu controle e projeto ou expanso de malhas. As funcionalidades mais relevantes deste modelo multifuncional so: Mdulo de simulao: calcula, dinamicamente no tempo, os valores de vazo e velocidade em cada duto; da presso em cada n da malha; dos nveis dos tanques; das

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

propriedades do fluido em todos os pontos da malha, derivados da mistura dos diferentes fluidos extrados dos poos de petrleo; do custo da operao simulada, resultante do custo relativo ao consumo e demanda de energia, entre outras variveis do sistema. Mdulo de otimizao: a soluo proposta para o escalonamento de bombas da rede pode ser bitdo de duas formas: atravs da otimizao via algoritmos genticos e atravs dos mdulos de regras existentes. A otimizao via algoritmos genticos fornece um escalonamento de bombas que otimiza o escoamento da produo na malha de oleodutos considerando mltiplos objetivos, durante um perodo futuro (horizonte de operao) de forma a atender a restries de vazes e presses nos dutos (mnimas e mximas), de capacidade de armazenamento dos tanques, de operao das bombas e gerenciais ou administrativas. Os mdulos de regras fornecem escalonamentos sub-timos, menos dedicados otimizao do escoamento da produo e focados em atender as restries hidrulicas e operacionais do sistema. Mdulo de monitoramento: capaz de capturar, quando existir medidor, o valor atual das variveis do sistema (nvel de tanques, presso, vazo, estado de bombas) e simular o comportamento do sistema para o prximo instante escolhido, podendo assim se comparar as variveis medidas com as simuladas. Mdulo de previso da produo: permite a estimar as propriedades fsicas e a quantidade de fluido aduzido dos campos produtores de petrleo e que entra nas estaes coletoras de fluido de forma varivel no tempo. Ferramenta de apoio calibrao de redes: permite ajustar a curva das bombas e a rugosidade dos dutos s condies reais de escoamento baseado num histrico recente de informaes coletadas dos processos hidrulicos ocorridos no sistema. Ferramenta de projeto otimizado de novos dutos: capaz de dimensionar uma malha completa ou novos elementos a partir de uma malha existente de forma otimizada. Ferramenta de anlise de robustez do modelo de deciso: permite realizar a anlise de incertezas da simulao, derivadas da variabilidade nos valores dos dados de entrada, utilizando a Anlise de Sensibilidade e o algoritmo Monte Carlo Ferramenta de registro global dos processos: tem como funo armazenar informaes dos processos realizados permitindo que essas informaes sejam consultadas posteriormente e sirvam de subsdios para outras ferramentas e anlise, e o usurio tenha total conhecimento sobre os clculos internos que ocorrem no SmartPumping, auxiliando assim a deteco de falhas e aprimoramento dos algoritmos. Ferramenta para edio de funcionalidades do software: permite a fcil modificao dos diversos modelos e algoritmos do software, com nveis diferenciados para usurios comuns e programadores.

5.2 Ambiente de desenvolvimento O desenvolvimento do software foi realizado atravs de duas equipes bem definidas, a equipe executora, composta principalmente por integrantes vinculados UFCG, e a equipe dos clientes, composta por integrantes vinculados PETROBRAS. Integrantes de ambas as equipes assumiram papis e funes baseados nas prticas recomendadas pelo processo de

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

desenvolvimento XP, sendo que, algumas vezes, foi necessrio o acmulo de papis para uma mesma pessoa. A equipe executora da UFCG foi composta por integrantes com as seguintes funes: Coordenadores do projeto: responsveis pela direo e coordenao do projeto. Tanto nas reunies com o cliente quanto em reunies internas de acompanhamento buscavam sempre manter o rumo do desenvolvimento do software de acordo com as metas acertadas na submisso do projeto, sempre buscando atender as exigncias do cliente. Por acumular tambm a funo de garantir a comunicao entre o financiador, a equipe do cliente e os grupos de pesquisa, podem ser considerados como o Gerente tal como est definido na metodologia XP. Os coordenadores eram professores da instituio executora. Gerente: responsvel pela liderana e gerenciamento do desenvolvimento do software. Supervisionava o andamento das atividades de especificao, testes e documentao do software por parte dos desenvolvedores de engenharia e a implementao e aprovao do produto fruto das especificaes pelos desenvolvedores de informtica, buscando sempre manter a sinergia entre esses dois grupos. Era quem articulava as reunies internas e com o cliente. Tambm era responsvel pela elaborao dos relatrios de entrega de produto, reviso e produo da documentao do software e gesto dos recursos financeiros. Dessa forma, assume funes dos papis de Lder de linha, Gerente de configurao, Gerente de qualidade, Gerente de produto, Coach e Tracker. O gerente era um profissional de Informtica contratado em tempo integral para o projeto. Consultores e pesquisadores: responsveis pelo esclarecimento de dvidas relativas s reas crticas do software que demandavam conhecimento tcnico aprofundado. Tambm eram responsveis por pesquisar e/ou sugerir o uso de tecnologias e metodologias mais eficientes e apropriadas. Os consultores e pesquisadores eram professores da UFCG e de outras universidades e estudantes de ps-graduao. Desenvolvedores de engenharia: responsveis pelo desenvolvimento das especificaes, esclarecimento das dvidas dos desenvolvedores de informtica e elaborao de testes de aceitao e documentao tcnica para cada funcionalidade e processos modelados no software. Assumia, portanto, o papel de representante do cliente, com o qual mantinha contanto constante, atravs de freqentes viagens a campo para coleta de informaes das redes de escoamento de petrleo, sobre os procedimentos da operao cotidiana realizada pelo usurio final e sobre as expectativas e anseios desses usurios a respeito das verses parciais liberadas do software. Este papel foi realizado por profissionais contratados em tempo integral para o projeto e por estudantes de ps-graduao. Desenvolvedores de informtica: responsveis pela discusso e implementao das especificaes elaboradas pelos desenvolvedores de engenharia, bem como no auxlio na implantao e esclarecimentos de dvidas de uso do software junto equipe dos clientes. Estudantes de graduao de Cincia da Computao exerceram este papel.

A equipe dos clientes (PETROBRAS) foi composta por integrantes com as seguintes funes: Coordenadores: responsveis pela definio de prioridades e acompanhamento geral do processo de desenvolvimento do software. Mantinham contato mais freqente com a equipe executora da UFCG atravs dos coordenadores do projeto e do gerente.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Consultores: responsveis pelo esclarecimento de dvidas e acompanhamento das especificaes de funcionalidades desenvolvidas para o software. Mantinham contato mais frequentes com os desenvolvedores de engenharia. Usurios: responsveis pelos testes de aceitabilidade do software e deteco de erros. So os usurios que fazem os testes de uso, bem como verificam se as funcionalidades representam satisfatoriamente os processos modelados, sugerindo, quando necessrio, melhorias, alteraes e novas implementaes que satisfaam plenamente as suas necessidades. Mantinham contato mais direto com os desenvolvedores de engenharia e com os desenvolvedores de informtica.

O ambiente de trabalho foi um importante fator no processo de desenvolvimento, influenciando diretamente no desempenho da execuo e na qualidade do produto final. Grande parte da equipe executora (cerca de 8 a 10 pessoas) foi instalada em uma mesma sala de trabalho, com exceo dos consultores e coordenadores, que sempre estavam presentes nas reunies rotineiras e freqentavam assiduamente o ambiente de desenvolvimento de projeto. O contato com a equipe de clientes ocorria nas reunies de entrega de produto, treinamentos, visitas de campo, via e-mail, telefone e eventualmente freqentavam o ambiente de desenvolvimento. Essa integrao dinmica entre os membros das equipes e entre as prprias equipes rendeu bons frutos. Devido impossibilidade de dispor do cliente como membro efetivo da equipe, os desenvolvedores de engenharia assumiram o papel do cliente, funcionando como um representante do cliente, ou seja, a partir das informaes, instrues e experincias adquiridas nas reunies peridicas e visitas a campo os engenheiros eram capazes de fazer o papel do cliente sob orientao do mesmo. A ausncia do cliente numa equipe utilizando XP pode ser muito danosa ao processo, visto que, sendo o engenheiro apenas um mediador tcnico, apesar de ser especialista na rea, freqente haver situaes de desconformidade do especificado pelo engenheiro e daquilo que de fato prioritrio e desejado pelo cliente. Esta dificuldade foi contornada com a diminuio do intervalo entre as liberaes, e a cada entrega fazer uma reunio com o cliente e representantes dos futuros usurios do software para anlise do produto. Um outro aspecto da utilizao dos engenheiros como representantes do cliente junto equipe de desenvolvimento a dificuldade de encar-lo como cliente, j que eram eles os especificadores e testadores e em alguns momentos no conseguiam ter a mesma viso crtica do cliente. O contato direto entre os desenvolvedores de engenharia e os de informtica proporcionou uma maior qualidade na elaborao e na implementao das especificaes e na execuo dos testes de aceitao do software. Isso porque, ao contrrio de outros mtodos tradicionais de desenvolvimento de software, o contato direto e dirio entre essas duas equipes contribui significativamente na agilidade e na qualidade das funes realizadas por cada uma delas. Por exemplo, os desenvolvedores de informtica poderiam esclarecer suas dvidas a respeito da especificao to logo elas surgissem, bem como identificar possveis lacunas nessas mesmas especificaes, as quais eram prontamente avaliadas pela equipe de engenharia, resultando em uma especificao final mais facilmente compreensvel, detalhada e abrangente. Por outro lado, os desenvolvedores de engenharia poderiam esclarecer suas dvidas a respeito do uso do software to logo elas surgissem, bem como identificar mais rapidamente defeitos e falhas no software, os quais eram prontamente resolvidos pelos desenvolvedores de informtica e disponibilizados na prxima liberao de verso. O contato entre essas duas equipes e os consultores, coordenadores e gerncia, atravs de reunies de acompanhamento da equipe executora, as quais eram realizadas regularmente, facilitava a soluo de impasses de carter tcnico, conceitual e funcional de cada

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

especificao elaborada, bem como a priorizao de atividades. Alm disso, o freqente contato entre as equipes executoras e dos clientes proporcionou o direcionamento do projeto para o desenvolvimento do produto aos moldes do usurio, contemplando suas necessidades para os diferentes usos. Esse contato tambm foi muito importante para aquisio de dados, procedimentos operacionais e compreenso do processo integrado de aduo de petrleo. 5.3 Processo de desenvolvimento e ferramentas utilizadas Um dos principais diferenciais do XP em relao aos outros mtodos de desenvolvimento de software a participao ativa do cliente e a realizao contnua de testes, os quais podem ser testes de unidade, testes de interface e testes de aceitao de funcionalidades e processos modelados. Os testes de unidades so feitos pelos desenvolvedores de informtica e verificam se cada mtodo de uma classe funciona como esperado. Os testes de interface avaliam se a interface grfica do software est agradvel e satisfaz s necessidades do usurio, enquanto os testes de aceitao verificam numericamente se o cdigo implementado atende a todos os requisitos descritos na especificao. A responsabilidade de elaborao e realizao dos testes de interface e de aceitao, segundo a filosofia XP, designada para o cliente. Entretanto, no projeto SmartPumping, como os desenvolvedores de engenharia assumiram algumas funes do cliente, tanto estes testes quanto a elaborao das especificaes ficaram sob sua responsabilidade. Especificaes so documentos que transcrevem, em linguagem de simples compreenso, os processos fsicos e funcionalidades a serem modeladas pelo software. Foram elaboradas pelos desenvolvedores de engenharia de acordo com as exigncias do cliente e aprovadas por ele. As especificaes devem ser didticas de tal forma que o programador consiga transformar em cdigo os textos que descrevem o produto desejado pelo cliente, por isso foi muito importante a concentrao da equipe de desenvolvimento no mesmo ambiente de trabalho, pois todos podiam opinar, tornando o documento mais compreensvel. A toda especificao existe pelo menos um teste de aceitao correspondente que avalia se as funcionalidades e processos especificados foram implementadas com sucesso, e tambm um texto que far parte da documentao tcnica no nvel de engenharia. Os testes de aceitao so testes formais conduzidos para determinar se um sistema satisfaz ou no aos requisitos funcionais estabelecidos pelo cliente e para permitir ao mesmo determinar se aceita ou no o sistema. Mais especificamente, consiste na aceitao de um software, ou de mdulos dele, pelo cliente, com o uso de dados ou cenrios especificados ou reais que fazem parte de um plano de testes, executado em toda a sua extenso e com todos os problemas reportados para ambas as partes. No SmartPumping estes testes foram realizados confrontando os resultados obtidos pelo software, com os resultados conseguidos em ferramentas auxiliares em que se tem confiana em atender as especificaes. As ferramentas auxiliares usadas foram planilhas Excel e o MATLAB. Com o intuito de automatizar essa comparao dos resultados e atender prtica recomendada pelo XP de realizao de testes automticos e contnuos, foi desenvolvida uma Ferramenta de Teste Automtico (FTA), a qual quando utilizada de forma contnua minimiza a possibilidade de que erros de implementao possam ser negligenciados e permitem que os mesmos sejam detectados rapidamente, a cada nova liberao de verso. Ou seja, a FTA permitiu que os testes de aceitao do software fossem executados de forma automtica, sempre que alguma mudana foi feita no software para verificar se novos defeitos foram introduzidos devido s novas funcionalidades ou alteraes implementadas. O processo de automatizao de testes comum no desenvolvimento de softwares de

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

qualidade e a utilizao dessa premissa no projeto SmartPumping, bem como o desenvolvimento da FTA, foi de significativa importncia para a qualidade final obtida, visto que agilizou o processo de execuo do considervel nmero de testes existentes e proporcionou uma maior rapidez na validao da robustez do software. Era uma prtica comum no projeto o lanamento freqente de novas verses e funcionalidades em curtos intervalos de tempo, exclusivamente para a equipe de desenvolvimento, os quais apenas aps serem consideravelmente avaliados e testados eram liberados para a equipe dos clientes. Alm da participao do cliente, mesmo quando representados pelos desenvolvedores de engenharia, da adoo dos ciclos de liberao curtas e da realizao contnua de testes, outras prticas recomendadas pelo processo de desenvolvimento XP tambm foram adotadas no projeto SmartPumping. Entre as quais podemos citar: Projetos simples: novas funcionalidades apenas eram implementadas sob demanda e tentando sempre reduzir a complexidade do sistema. Refatoramento: alm do refatoramento do cdigo como um todo, quando houve a necessidade de utilizao de bibliotecas novas em substituio s j ultrapassadas, pequenos refatoramentos foram realizados em mdulos especficos do software, sempre decorrentes da necessidade de alguma alterao significativa na estrutura do mesmo. Programao em pares: sempre que possvel os desenvolvedores de informtica realizaram suas tarefas em pares. Posse coletiva das solues: foi priorizada a adoo de padres bem definidos, tanto na construo do cdigo quanto na sua documentao, de forma a facilitar a transferncia para o cliente e o fcil entendimento de futuros desenvolvedores do cdigo e/ou usurios do software. Trs manuais foram editados continuamente e entregues junto com o produto final com este objetivo, os quais so o Manual do Usurio, o Manual do Programador e a Documentao Tcnica.

A utilizao das ferramentas de apoio foi fundamental tambm para a qualidade final obtida para o software, principalmente a ferramenta XPlanner, que foi bastante til devido a disperso geogrfica entre a equipe de desenvolvimento e o cliente (Campina Grande PB, Natal RN, Mossor RN e Rio de Janeiro RJ), facilitando o acompanhamento do projeto pelo cliente, que no est no mesmo ambiente fsico, e pelo gerente de projeto. As ferramentas de apoio ao desenvolvimento utilizadas foram o Eclipse, o JUnit e o CVS, sendo que no foi necessria a utilizao da ferramenta EasyAccept devido ao desenvolvimento de uma ferramenta prpria de automatizao de testes de aceitao, conforme descrito anteriormente. 6. Experincia no projeto SegHidro 6.1 Descrio do projeto O projeto SegHidro (ARAJO et al., 2005; http://seghidro.lsd.ufcg.edu.br) foi um projeto financiado pelo Fundo Setorial de Tecnologia da Informao (CT-INFO) da Financiadora de Estudos e Projetos (FINEP), executado em 2005 e 2006. Ele teve como proposta o desenvolvimento de aplicaes computacionais que facilitassem o fluxo de informaes meteorolgicas e hidrolgicas, atingindo o usurio final at o tomador de deciso em nveis governamentais.

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Essas aplicaes tm o propsito de gerar cenrios a serem avaliados pelos modelos de tomada de deciso, que por sua vez utilizam simulaes numricas de aproveitamento dos recursos hdricos. Para que o conjunto de aplicaes fosse operacionalizado num mesmo ambiente foi concebida uma infra-estrutura de compartilhamento na Web, denominado portal. Alguns dos objetivos do projeto tambm contemplavam a incluso digital de algumas instituies, que no tinham condies de executar tais aplicaes por no disporem de recursos computacionais, a sinergia interinstitucional, gerada pelo uso de uma aplicao comum e que favoreceu ao crescimento de atividades cooperativas no mbito dos sistemas institucionais de monitoramento e previso de tempo e clima, de gesto de recursos hdricos e de gesto agropecuria. O projeto foi executado pela UFCG em parceria com o Centro de Previso de Tempo e Estudos Climticos (CPTEC) do Instituto de Pesquisas Espaciais (INPE), com a Fundao Cearence de Meteorologia (FUNCEME), com o Instituto de Tecnologia de Pernambuco (ITEP), com a Empresa Brasileira de Pesquisa Agropecuria (EMBRAPA), e com o Governo do Estado da Paraba, por meio da Empresa de Assistncia Tcnica e Extenso Rural da Paraba (EMATER) e da Agncia Executiva de Gesto das guas do Estado da Paraba (AESA). 6.2 Ambiente de desenvolvimento No desenvolvimento da infra-estrutura SegHidro foi adotada uma estratgia de desenvolvimento que teve como ponto principal a diviso de equipes de acordo com suas metas especficas. Neste contexto foram concebidas duas equipes executoras: a do portal Web e da infra-estrutura computacional para acoplamento e compartilhamento das aplicaes e dados; e a das aplicaes em recursos hdricos, desenvolvidas para serem acopladas ao portal. A equipe responsvel pelo desenvolvimento do portal Web era liderada pelo gerente do projeto e contava com um grande nmero de desenvolvedores na rea de informtica, enquanto que a outra equipe, liderada por um lder de linha, coordenava uma equipe mista, com desenvolvedores das reas de informtica, de meteorologia e de recursos hdricos. Estas equipes eram locadas em ambientes distintos, e a comunicao efetuada com o auxlio de algumas ferramentas, como ser descrito em tpico seguinte. A integrao das vrias instituies parceiras do projeto foi viabilizada pela troca de informaes atravs do site do projeto, via e-mail e telefone, e em reunies gerais peridicas, avaliando os produtos e sugerindo melhorias, desempenhando o papel de consultoria ao projeto. Alguns desses parceiros tinham interesse de uso nos produtos gerados, fazendo com que eles desempenhassem o papel de clientes e usurios. O acompanhamento ao cliente era realizado por desenvolvedores, coordenadores e gerentes. 6.3 Processo de desenvolvimento e ferramentas utilizadas O envolvimento de vrios atores geograficamente esparsos foi fator motivador para que as ferramentas facilitadoras da comunicao fossem mais exploradas, provocando maior interao das partes interessadas. Como apoio ao gerenciamento das atividades desenvolvidas duas dessas foram principais: o TWiki e o XPlanner. No TWiki foi possvel realizar a documentao dos processos e disponibilizao de cdigos, scripts, manuais e demais documentos. A alimentao de informaes no ambiente foi de modo contnuo, acompanhando o ritmo das iteraes do projeto. Por ser composto de

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

equipe geograficamente dispersas, o projeto ainda foi beneficiado pelo carter colaborativo da ferramenta, permitindo vrias contribuies simultneas. A metodologia de desenvolvimento e grandes equipes de trabalho foram dois pontos que colaboraram para que os projetos SmartPumping e SegHidro tivessem muitas semelhanas quanto s funes da equipe executora. J quanto equipe de clientes a estrutura geral pode ser considerada a mesma. Diante disso, seguem algumas observaes quanto as funes da equipe SegHidro que no foram descritas anteriormente: Coordenadores do projeto: responsveis pela direo e coordenao do projeto. Por serem pesquisadores nos assuntos tratados no projeto, tambm desempenhavam a funo de consultores, esclarecendo as metodologias a serem utilizadas e melhorando a qualidade das especificaes do cliente. Gerente: responsvel pela liderana e gerenciamento do desenvolvimento de todo o projeto. Acompanhava o andamento das atividades de todos os desenvolvedores. Responsvel por agendar as reunies gerais internas e externas, e pela elaborao dos relatrios de entrega de produto. Assim como no SmartPumping, assumia funes dos papis de Lder de linha, Gerente de configurao, Gerente de qualidade, Gerente de produto, Coach e Tracker. Desenvolvedores de engenharia e informtica: desempenhavam funes semelhantes comparados ao desenvolvedores do projeto SmartPumping, embora a atividade de campo no fosse um fator to presente, pois embora existisse visitas aos clientes, no existiam dados de campo a serem coletados.

No tocante ao acompanhamento das atividades, foi possvel que todos os membros do projeto verificassem o andamento das tarefas atravs do XPlanner. Nele, os coordenadores, gerente e lder planejavam para cada iterao as tarefas que deveriam ser realizadas, cada tarefa era assumida por algum membro, geralmente um desenvolvedor, e assim monitorada. Caso o tempo demandado em determinada tarefa extrapolasse o previsto, eram documentadas as causas e uma reavaliao era realizada de modo que o impacto em outras iteraes no fosse relevante. O processo de desenvolvimento das aplicaes era realizado a partir de entregas de pacotes que incluam as especificaes (procedimentos e requisitos), testes de validao e documentao. Parte dos desenvolvedores preparava as especificaes e testes para que o processo de desenvolvimento computacional fosse iniciado. Assim que realizado, os mesmos desenvolvedores completavam a documentao que j estava no TWiki com manuais de utilizao, eventuais problemas encontrados e novos testes. Para alguns testes foi utilizada a ferramenta EasyAccept, permitindo que o desenvolvedor da aplicao incorporasse os requisitos plataforma de desenvolvimento, retornando mais rapidamente os itens que demandavam aperfeioamento.

7. Experincia no projeto Systernas 7.1 Descrio do projeto O Projeto Systernas (NBREGA et al., 2007, http://eeg.lsd.ufcg.edu.br/twikipublic/bin/view/EEG/Cisternas) fez parte de um conjunto de pequenos grupos de desenvolvimento inseridos em um projeto denominado Empowering Education through Grids (EEG) que tinha como objetivo explorar grades computacionais para o desenvolvimento de

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

aplicaes em diversas reas de conhecimento. O projeto foi executado pela Universidade Federal de Campina Grande (UFCG), entre os anos de 2006 e 2007, e financiado pela Hewlett Packard (HP). O objetivo do Projeto Systernas foi implementar uma aplicao que, atravs de simulaes de balano hdrico que estimem os nveis de gua armazenada em cisternas, possibilitasse realizar uma anlise regional, englobando vrios sistemas simultaneamente e produzindo cenrios de suprimento de gua dos sistemas de aproveitamento de gua de chuva. 7.2 Ambiente de desenvolvimento O grupo responsvel pelo desenvolvimento da aplicao era formado por quatro pessoas que no contavam com uma estrutura fsica comum para desenvolvimento das tarefas. Os papis desempenhados na equipe eram: um consultor e trs desenvolvedores. O consultor detinha a viso dos potenciais clientes para a aplicao, passando assim sua colaborao a ser fundamental na atribuio dos requisitos necessrios. Quanto aos trs desenvolvedores, um era da rea de recursos hdricos, desempenhando tambm uma funo de lder de linha (revisando prazos e entregas) e coach, e dois da rea de informtica.

7.3 Processo de desenvolvimento e ferramentas utilizadas Por se tratar de um projeto que envolvia poucas pessoas, o gerenciamento do tempo e atividades foi uma tarefa que no exigiu uma dedicao exclusiva e dispensou a necessidade de uso de ferramentas de apoio mais elaboradas como o XPlanner. Para distribuio de informaes, documentao dos materiais necessrios e produzidos, e acompanhamento do projeto foi elaborado um espao em TWiki onde os membros podiam suprir essas necessidades, dispensando que as novas informaes fossem condensadas em reunies e passadas em ambiente informal. 8. Concluses As trs experincias relatadas neste artigo apresentam caractersticas distintas nos aspectos de dimenso e diversidade dos parceiros institucionais, da dimenso da equipe executora e das caractersticas do software em desenvolvimento. O processo de desenvolvimento eXtreme Programming XP e ferramentas apropriadas de suporte foram adotados, com adaptaes, em todos os trs casos. Os trs produtos foram bem sucedidos e esto, atualmente, em processo evolutivo. A estreita integrao entre as equipes temticas de Hidrulica/Recursos Hdricos e de Informtica/Cincia da Computao parece ter sido um dos principais pilares para o sucesso dos projetos, mas as outras prticas preconizadas pelo XP foram tambm essenciais. Recomenda-se fortemente a adoo deste processo e ferramentas nos projetos de Hidroinformtica, independentemente da magnitude dos recursos envolvidos e das dimenses das equipes executoras. Agradecimentos Os projetos aqui relatados foram executados pela Universidade Federal de Campina Grande e diversos parceiros, financiados por: FINEP/CT-PETRO e PETROBRAS (SmartPumping), FINEP/CT-INFO e MCT (SegHidro), HP (Systernas), e CNPq e CAPES (atravs de bolsas a pesquisadores e estudantes).

I ENCONTRO NACIONAL DE HIDROINFORMTICA Universidade de Fortaleza, UNIFOR Fortaleza, Cear, de 16 a 19 de maro de 2008

Referncias ARAJO, E.; CIRNE FILHO, W.; ABILIO, N.; SOUZA, E.; GALVO, C. & MARTINS, E. The SegHidro experience: using the Grid to empower a hydro-meteorological scientific network. In: 1st IEEE International Conference on eScience and Grid Computing, 2005. BECK, K. Extremme programming explained: embrace change. Addison Wesley Press, 2000. BRASILEIRO, F.; GALVO, C.; BRASILEIRO, E.; CATO, B.; SOUTO, C.; MACHADO, E.; MUNIZ, M.; SOUZA, A.; GOMES, A.; ALOISE, D.; OLIVEIRA, A.; GOMES, C.; ROLIM, T. & BOQUIMPANI, C. Monitoramento e controle em tempo real de redes de escoamento de petrleo. In Rio Pipeline Conference & Exposition, Rio de Janeiro, 2003. GALVO, C.; BRASILEIRO, F.; SANTANA, C.; MACHADO, E.; BRASILEIRO, E.; CATAO, B.; GOMES, A.; IZU, A.; LUCENA, K. & ALOISE, D. Sistema computacional para o monitoramento e controle em tempo real de redes de escoamento. In Seminrio Hispano-Brasileo sobre Planificacin, Proyecto y Operacin de Redes de Abastecimiento de Agua, 2004, Valencia (Espaa), 2004. NBREGA, R.; QUEIROZ, M.; MAIA, L. & GALVO, C. InfoChuva: uma ferramenta computacional de avaliao de riscos de desabastecimento de sistemas de captao de gua de chuva. In: VI Simpsio Brasileiro de Captao e Manejo de gua de Chuva, Belo Horizonte, 2007.