Proposta de uma ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído

Proposta de uma ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ana Paula Chaves, Jocimara Segantini Ferranti, Alexadre L Erário, Rogério Santos Pozza 1 Universidade Tecnológica Federal do Paraná - UTFPR Coordenação de Informática Avenida Alberto Carazzai, 1640 86.300-000 Cornélio Procópio PR Brazil {chavesana85,joccyferranti}@yahoo.com.br,{lerario,pozza}@cp.cefetpr.br Abstract. This issue presents a proposal of a tool that helps the software project management based on an architecture that makes possible the specification and enaction of process. The tool uses Petri network formalism in process modelling and allows that its activities are distributed among distant geographically development teams. The projects management allows the following of the process execution flow giving to project manager a project course overview. Resumo. Este artigo apresenta a proposta de uma ferramenta de apoio ao gerenciamento de projetos de software baseada em uma arquitetura que possibilita a especificação e execução de processos. A ferramenta utiliza o formalismo de redes de Petri na modelagem do processo e ainda permite que suas atividades sejam distribuídas entre equipes de desenvolvimento geograficamente distantes. O gerenciamento dos projetos permite o acompanhamento do fluxo de execução do processo fornecendo ao gerente de projeto uma visão geral do andamento do mesmo. 1. Introdução O progresso tecnológico é basicamente representado por constantes avanços nas áreas de hardware e software. O resultante crescimento da conectividade desse aparato computacional é evidenciado por melhoras na tecnologia de redes de computadores, que não se restringe apenas à velocidade de transmissão dos dados, mas também à confiabilidade e alcance geográfico, por meio físico ou aplicações de redes sem fio. Essa expansão transformou o computador em uma poderosa ferramenta de comunicação e colaboração. A distribuição geográfica do processo de desenvolvimento de software tem se tornado cada vez mais significativa, buscando obter vantagens competitivas em termos de ganho de produtividade, melhoria de qualidade, flexibilidade de desenvolvimento, redução de custos e diluição de riscos [Prikiladnick 2004]. Gerenciar um projeto consiste na tomada de decisões sobre o uso de recursos, humanos ou materiais, na realização de atividades que visam atingir um objetivo. Sua essência está no planejamento e na execução das atividades que compõem seu ciclo de

vida. Dessa forma, no gerenciamento de projetos de software, planejar e executar atividades de um processo de desenvolvimento são tarefas importantes para que um resultado de qualidade seja obtido [Huzita 2006]. Automatizar processos de software facilita a gerência do desenvolvimento, controlando o comportamento do processo definido, coletando métricas e reforçando as regras para garantir a integridade do processo. Além de melhorar a comunicação entre as pessoas envolvidas e a consistência do que está sendo feito, provê informações que orientam o desenvolvedor a realizar o trabalho com mais eficiência, possibilita a reutilização das definições de processo e a medição do progresso do trabalho, resultando na economia de recursos. Este artigo propõe uma ferramenta de apoio ao Desenvolvimento Distribuído de Software que possibilita a especificação, modelagem e execução de processos de desenvolvimento. A Seção 2 apresenta conceitos importantes para a contextualização da ferramenta. A Seção 3 descreve os fundamentos da modelagem e execução de processos de software. A Seção 4 traz alguns trabalhos relacionados. A Seção 5 propõe uma arquitetura para apoiar o gerenciamento de processos de desenvolvimento distribuído. As seções 6 e 7 trazem a descrição da ferramenta proposta e a tecnologia utilizada no desenvolvimento, respectivamente. A Seção 8 apresenta a conclusão deste artigo. 2. Conceitos Empregados Esta seção descreve brevemente alguns dos conceitos que fazem parte do contexto de aplicação da ferramenta proposta. As seções 2.1 e 2.2 apresentam, respectivamente, as definições de processo de software e Desenvolvimento Distribuído de Software. 2.1. Processo de software [Pressman 2005] define processo de software como uma série de passos previsíveis que auxilia na obtenção de resultados de qualidade e em tempo. Informalmente, o processo de software pode ser compreendido como o conjunto de passos parcialmente ordenados, relacionados com conjuntos de artefatos, recursos e restrições, tendo como objetivo transformar os requisitos do usuário em software. Os processos de software, em sua maioria, são bem estruturados e possuem fases bem definidas, que compreendem uma série de atividades executadas para que um objetivo seja atingido. As atividades têm como objetivo a construção de um conjunto de artefatos que poderão ser usados por outras atividades para completar suas tarefas. Qualquer fator necessário à execução de uma atividade, mas que não seja insumo para a mesma, é chamado de recurso, podendo ser hardware, software ou pessoa. Um papel descreve um conjunto de responsabilidades, direitos e habilidades necessários para uma pessoa realizar uma atividade no processo. Gerente, projetista e programador são exemplos de papéis. Uma restrição afeta a realização de um processo, impondo condições que devem ser satisfeitas antes ou depois da execução de uma atividade.

2.2. Desenvolvimento Distribuído de Software As equipes de projeto de software vêm se distribuindo geograficamente, em escala mundial, inseridas no conceito de globalização que a sociedade tem vivenciado. Diante disso, o Desenvolvimento Distribuído de Software (DDS) possibilita a interação entre equipes de desenvolvimento geograficamente distantes, que podem estar em organizações, cidades, estados e, até mesmo, em países diferentes, e a disposição dos recursos em âmbito global. O DDS fornece suporte computacional que ataca as dificuldades características da implantação, execução e do monitoramento de projetos em ambientes distribuídos, como gerência de projeto, processo de desenvolvimento de software, complexidade e tamanho de projetos, tecnologia e infra-estrutura de comunicação disponível, dispersão geográfica e diferenças culturais [Prikiladnick 2004]. 3. Modelagem e Execução de Processos de Software Desenvolver software utilizando um processo de desenvolvimento bem definido não é uma tarefa simples, já que envolve atividades complexas realizadas por pessoas com capacidades diversas. A descrição formal de um processo de software é uma atividade que permite que o mesmo seja analisado, compreendido e executado. Neste contexto, a modelagem e execução de processos de software estão diretamente relacionadas ao aumento de qualidade dos produtos de software [Reis 1998]. As seções 3.1 e 3.2 apresentam os conceitos de modelagem e execução de processos. 3.1. Modelagem de Processos Um modelo de processo é uma representação abstrata do processo de software que busca descrever a ordem de execução das fases e como elas interagem entre si [Reis 1998]. O modelo de processo especifica quais atividades serão executadas, por quem, quando, como, onde e por que serão realizadas e as dependências existentes entre elas. Os diversos modelos encontrados na literatura descrevem o processo sob perspectivas particulares de abstração e são propostos para atender a diversos tipos de sistemas com as mais variadas necessidades. Tais modelos - Cascata [Royce 1970]; Espiral [Bohem 1986]; Caótico [Racoon 1995] e Processo Unificado [Jacobson 1999], entre outros - sugerem a realização de uma determinada seqüência de atividades para que o desenvolvimento do software seja bem sucedido. Os modelos de processo de software representam os elementos do processo e seu comportamento utilizando técnicas como diagramas de transição de estados, diagramas de fluxos de dados, linguagens de programação de processos, entre outras. Dessa forma, a modelagem do processo de software permite que a representação do modelo seja compartilhada pela equipe de desenvolvimento, possibilita analisar o processo e descobrir pontos que podem ser melhorados, proporciona reutilização da definição, suporta a gerência de processo e provê orientação e execução automatizada do processo [Curtis 1992].

3.2. Execução de Processos Na execução de processos de software, as atividades modeladas são realizadas levando em consideração a coordenação entre múltiplos usuários e a interação entre ferramentas e desenvolvedores [Reis 1998]. Um projeto é uma instância do processo, com objetivos e restrições específicas [Conradi 1994], que possui características como alocação de recursos, atribuição das atividades aos desenvolvedores e prazos. O mecanismo de execução interpreta o processo modelado e manipula informações especificas do projeto, como as atividades em execução e o estado do processo. Além disso, esse mecanismo deve ativar automaticamente atividades que dispensam intervenção humana, suportar a coordenação e cooperação das equipes envolvidas no projeto, assegurar que dependências, restrições de tempo e recursos sejam satisfeitas, prover diferentes visões do estado de execução e coletar dados da evolução do processo. É importante salientar que existe uma distinção entre a definição de um processo e sua execução. Mesmo apoiada por um ambiente automatizado, a realização do processo pode não estar de acordo com sua especificação. 4. Trabalhos Relacionados Esta seção traz alguns trabalhos que utilizam conceitos de Desenvolvimento Distribuído de Software e modelagem e execução de processos, abordados na construção da ferramenta proposta. As seções 4.1 e 4.2 apresentam dois ambientes de desenvolvimento de software, a estação TABA e o ambiente PROSOFT, respectivamente, dando enfoque, principalmente, às soluções empregadas na definição e execução de processos. A Seção 4.3 descreve brevemente a ferramenta DIMANAGER, que apóia o gerenciamento de projetos de software em ambientes de desenvolvimento distribuído. 4.1. Estação TABA A Estação TABA [Taba 2006] é um ambiente de desenvolvimento de software que apóia a execução das atividades que compõem um processo de software por meio de um conjunto de ferramentas integradas e repositórios contendo informações adquiridas durante a execução do processo do projeto. Desenvolvida no contexto de um projeto acadêmico, o modelo para controle de execução de processos nos ambientes TABA possui algumas características que auxiliam um efetivo controle e execução de processos: associação de pessoas às atividades, suporte à modificação do processo durante sua execução, registro de informações sobre o processo em execução e simulação do processo utilizado. Possui uma máquina de processos que executa as especificações do processo de maneira independente do ambiente. 4.2. PROSOFT O PROSOFT é um ambiente de desenvolvimento de software com o objetivo de apoiar o desenvolvimento formal de software desde a especificação dos requisitos até a implementação do sistema, fornecendo integração de dados, controle e de apresentação entre suas ferramentas. As ferramentas do PROSOFT são chamadas Ambientes de Tratamento

de Objetos (ATO), que interagem por um mecanismo de comunicação chamado Interface de Comunicação do Sistema (ICS). A atual arquitetura do ambiente provê mecanismos que permitem sua utilização por vários usuários simultaneamente, permitindo compartilhamento de informações e auxílio inteligente ao desenvolvimento. O Gerenciador de Processos (GP) faz o papel de máquina de execução ou interpretador de modelos de processo, permitindo a execução de processos, de acordo com um modelo de processo software [Reis 1998]. 4.3. DIMANAGER O objetivo da ferramenta DIMANAGER [Pedras 2003] consiste em colaborar com o gerenciamento de projetos de software em ambientes de desenvolvimento distribuído. Para a definição do planejamento do projeto na ferramenta DIMANAGER são consideradas funcionalidades como a identificação das atividades dentro de um projeto, identificação das métricas que deverão ser analisadas para o acompanhamento do projeto, definição dos participantes com atribuição de funções e habilidades e elaboração do cronograma de atividades. O registro da execução das atividades realizado pelos participantes no decorrer do trabalho gera as informações utilizadas no acompanhamento do projeto. Esse acompanhamento é a parte mais importante da ferramenta, já que possibilita ao gerente de projeto visualizar os resultados referentes às atividades desenvolvidas por cada participante, analisar o desempenho de cada um e verificar se o projeto está evoluindo dentro do prazo estabelecido. 5. Arquitetura Proposta Esta seção descreve a arquitetura proposta para apoiar o gerenciamento de processos no desenvolvimento distribuído de software que possibilita desde a especificação e modelagem de um processo de software até a sua execução. A arquitetura é dividida em três camadas - Modelagem, Engine e Execução - que são apresentadas nas seções 5.1, 5.2 e 5.3. 5.1. Camada de Modelagem O objetivo da camada de Modelagem é gerar uma especificação de um processo de software capaz de ser interpretada pela Engine e executada pela camada de Execução. Essa especificação é gerada a partir da definição e modelagem do processo. A definição do processo consiste em descrever suas atividades e os artefatos que deverão ser produzidos e/ou consumidos em cada uma delas. Depois de definido, o processo é modelado e os artefatos gerados dentro de cada atividade são agrupados, possibilitando a distribuição desses grupos entre as diversas unidades de desenvolvimento. Esse agrupamento define o fluxo de execução do processo. 5.2. Engine A Engine interpreta a especificação do processo e a transforma em um processo distribuído. Essa camada cria uma instância do processo especificado e adiciona a ela informações específicas do projeto, como metas e prazos. Além disso, distribui os grupos de artefatos modelados entre as diversas equipes de desenvolvimento. Depois disso, o processo está pronto para ser executado.

5.3. Camada de Execução A camada de Execução realiza o gerenciamento do processo instanciado. O gerenciamento automatizado da execução do processo manipula as informações referentes ao andamento do projeto, como datas de início e término das atividades, e permite o acompanhamento do estado de execução das atividades e dos artefatos. O estado corresponde à situação do andamento de um processo, atividade ou artefato. A Figura 1(a) mostra os estados que um processo pode assumir, sendo eles: Instanciado: um processo foi criado, distribuído entre as equipes de desenvolvimento e está pronto para ser executado; Executando: o gerente de projeto iniciou a execução de um projeto "instanciado" ou retomou um projeto "suspenso"; Suspenso: um projeto teve sua execução suspensa pelo gerente de projeto, podendo ser retomado, voltando ao estado "executando", ou "cancelado"; Cancelado: o gerente de projeto encerrou um projeto "instanciado", "executando" ou "suspenso", não podendo ser retomado posteriormente; Concluído: a execução de um projeto foi concluída. A Figura 1(b) representa os estados de um artefato ou atividade. As atividades e os artefatos podem assumir os mesmos estados de um processo, exceto o estado "cancelado", já que, por serem parte integrante do processo, precisam ser executados completamente para que o processo possa ser concluído. Figura 1. Diagramas de estados de (a) um processo, (b) atividade e artefato. Algumas atividades podem assumir o estado "executando" automaticamente, quando da conclusão da atividade anterior. Por outro lado, outras atividades precisam ser iniciadas explicitamente pelo gerente do projeto. Essa característica é definida pelo gerente de processo durante a especificação. Já os artefatos têm seus estados alterados pelo desenvolvedor responsável pela sua produção. Esse acompanhamento oferece ao gerente de projeto uma visão geral do andamento do mesmo, possibilitando a tomada de decisões quanto a mudanças no fluxo de execução durante o desenvolvimento.

6. Ferramenta Proposta Este artigo propõe uma ferramenta de apoio ao DDS que possibilita a especificação, modelagem e execução do processo de desenvolvimento de software. O objetivo é permitir que, embora os processos modelados sejam executados por equipes de desenvolvimento geograficamente distantes, essa característica seja transparente aos usuários e o gerenciamento de cada projeto ocorra de forma virtualmente centralizada. A ferramenta consiste em três módulos - Edição, Gerenciamento e Monitoramento - baseados nas camadas da arquitetura descrita na seção anterior. O módulo Edição equivale à camada de Modelagem. A Engine está incluída no módulo Gerenciamento, que combinada com o módulo Monitoramento, forma a camada de Execução. A Figura 2 apresenta a arquitetura proposta na Seção 5 e a correspondência de suas camadas com os módulos da ferramenta descrita nessa seção. Figura 2. (a) Arquitetura e (b) ferramenta propostas. Além das funcionalidades referentes à modelagem e execução dos processos, a ferramenta proposta também realiza o controle de usuários e sites que interagem com o sistema, descrito na Seção 6.1. Um site é um conjunto de usuários que representam uma equipe de desenvolvimento, em um mesmo local geográfico, responsável pelo desenvolvimento de um ou mais grupos de artefatos definidos na modelagem do processo. Os módulos Edição, Gerenciamento e Monitoramento são apresentados nas seções 6.2, 6.3 e 6.4, respectivamente. 6.1. Controle de Usuários e Sites O controle de usuários e sites consiste no cadastro, alteração e exclusão de usuários e sites. Para ter acesso ao sistema, o usuário deve ser cadastrado, possuir uma senha de acesso, ser relacionado a um único site e assumir um ou mais papéis dentro do sistema. A ferramenta proposta define quatro papéis, descritos a seguir: Gerente de processo: O gerente de processo é o responsável pela especificação e modelagem de um processo de desenvolvimento. Ao modelar o processo, o gerente de processo define a arquitetura de distribuição dos artefatos, a forma de execução e as dependências entre eles. Gerente de projeto: O gerente de projeto é o responsável pela instanciação e controle da execução de um projeto que contém um processo já definido e modelado. Ao instanciar um projeto, o gerente de projeto distribui os grupos de artefatos das

atividades entre os sites envolvidos e define as regras de transição entre os grupos de artefatos e atividades. O módulo Monitoramento permite ao gerente o acompanhamento do projeto, consultando o estado de desenvolvimento das atividades e grupos de artefatos. Gerente de site: O gerente de site responde pela equipe de desenvolvimento que gerencia. Além de manipular membros do site, distribui entre eles os artefatos do grupo atribuído ao site pelo gerente de projeto. Desenvolvedor: O desenvolvedor é o responsável pela construção do artefato atribuído a ele pelo gerente do site a que pertence. O administrador pode assumir qualquer um dos papéis suportados pela ferramenta. Além disso, é responsável por classificar os demais usuários definindo suas permissões e/ou restrições de acesso. A autenticação de um usuário no sistema permite/restringe o acesso do mesmo no ambiente. Seus papéis são consultados e as funcionalidades da ferramenta são disponibilizadas de acordo com seu perfil. Todo site cadastrado deve ter, além de sua descrição e local, um gerente de site, responsável pela equipe de desenvolvimento, e diversos membros que podem assumir quaisquer papéis definidos anteriormente. 6.2. Módulo Edição O módulo Edição é responsável por gerar a especificação de um processo a partir da definição de suas características e modelagem do seu fluxo de execução, de acordo com a camada de Modelagem da arquitetura proposta na Seção 5.1. Quando um processo é criado, é necessário definir suas atividades e os artefatos produzidos em cada uma delas. Um processo deve possuir ao menos uma atividade, e cada atividade, ao menos um artefato. Após a definição, a modelagem do processo é fundamental para representar as partes que o compõe e os relacionamentos existentes entre elas. Para isso, os artefatos de cada atividade são reunidos em um ou mais grupos e modelados utilizando o formalismo das Redes de Petri (PN - Petri Network) [Petri 1962]. A modelagem baseada em PN apresenta um grande potencial para a modelagem de softwares desenvolvidos de forma distribuída por possuir uma representação gráfica, ser de fácil aprendizado e permitir a descrição dos aspectos estáticos e dinâmicos do sistema, possibilitando simulações e verificações [Pádua 2004]. Segundo [Raposo 2000], uma PN é uma ferramenta de modelagem aplicável a uma série de sistemas, especialmente àqueles com eventos concorrentes. Seu objetivo principal é modelar o comportamento de um sistema a partir de seus estados e mudanças, sendo formada por lugares, transições e arcos. Os estados são associados aos lugares e suas marcações (tokens), representados graficamente por círculos e pontos, respectivamente. As transições correspondem às regras de disparo de uma ação e modelam o comportamento dinâmico do sistema. São representadas por barras e se associam aos estados com arcos. Os arcos, representados por setas com pesos, indicam as seqüências de possíveis transições entre os estados. As transições podem ser disparadas a partir do momento em que estão habilitadas, quando o evento associado a ela ocorrer.

A Figura 3 mostra um exemplo simples de uma rede de Petri e seus componentes. P1, P2, P3 e P4 representam os lugares da rede, dos quais P1, P2 e P3 possuem tokens que indicam que eles já concluíram suas atividades e podem disparar eventos nas transições T1 e T2. Dos arcos que ligam os lugares às transições, apenas P1-T1 possui peso 2, o que indica que ele necessita de dois tokens para habilitar a transição T1. Figura 3. Exemplo de uma rede de Petri. No módulo Edição, cada lugar da PN representa um grupo de artefatos pertencentes a uma mesma atividade. As transições são habilitadas quando cada um de seus lugares de entrada conclui a produção de seus artefatos. Os pesos dos arcos estão relacionados à quantidade de artefatos de entrada de uma transição ou lugar. Essa especificação é armazenada em um banco de dados que servirá de entrada para o módulo Gerenciamento. Apenas os gerentes de processo têm permissão de acesso a este módulo da ferramenta. 6.3. Módulo Gerenciamento O módulo Gerenciamento corresponde à Engine e à camada de Execução da arquitetura proposta. Dessa forma, instancia um processo modelado e o executa. A instância de um processo é criada pelo gerente de projeto. Ao criar um novo projeto, o gerente fornece suas informações específicas, como a descrição do projeto e as metas a cumprir, e determina qual dos processos modelados é mais adequado ao projeto em questão. A especificação do processo escolhido é então relacionada ao projeto e todas as suas atividades e seus artefatos são instanciados. Depois disso, o gerente de projeto determina os prazos que deverão ser cumpridos para o início e término dos artefatos e atividades do processo e distribui os grupos de artefatos modelados entre os sites. Um site pode receber um ou mais grupos de artefatos, cabendo ao gerente do site distribuir os artefatos desses grupos entre seus membros. Instanciado o processo, o projeto criado está pronto para ser executado. O gerente de projeto inicia o fluxo de execução do processo e habilita o primeiro grupo de artefatos

para que também seja executado. A partir de então, o fluxo é controlado de acordo com as regras de transição modeladas na especificação e o processo pode ser suspenso, retomado, cancelado e concluído, conforme descrito na Seção 5.3. A execução das atividades e dos artefatos ocorre de forma semelhante à do processo, possibilitando a suspensão, retomada e conclusão, sendo de responsabilidade do desenvolvedor manipular a execução dos artefatos delegados a ele. O fluxo de execução do processo pode ser encerrado pelo cancelamento ou conclusão do mesmo, de acordo com a Seção 5.3. Caso cancelado, o gerente de projeto deve informar as causas que justifiquem seu cancelamento. Por outro lado, se concluído, as informações fornecidas pelo gerente de projeto são acerca dos resultados obtidos durante a execução do projeto. Essas informações são armazenadas como histórico para auxiliar a execução futura de projetos similares. A Figura 4 descreve graficamente o fluxo principal de execução de um processo por meio de um diagrama de atividades. Figura 4. Diagrama de atividades do módulo Gerenciamento. 6.4. Módulo Monitoramento O módulo Monitoramento permite ao gerente de projeto realizar o acompanhamento da execução do processo.

Esse módulo recupera as informações referentes a uma instância do processo e utiliza PN para representar graficamente os estados de cada grupo de artefatos, que correspondem aos estados descritos na Seção 5.3 para artefatos e atividades. 7. Tecnologia A ferramenta proposta está sendo desenvolvida baseada no paradigma de orientação a objetos utilizando tecnologia Java e banco de dados relacional PostgreSQL 8. A camada de persistência, responsável pela comunicação da aplicação com a base de dados utiliza Hibernate. O Hibernate é um framework de mapeamento objeto relacional para aplicações Java [Hibernate 2006]. É uma ferramenta para mapear classes Java em tabelas do banco de dados e vice-versa e oferece suporte ao mapeamento de associações entre objetos, herança, polimorfismo, composição e coleções, disponibilizando também um mecanismo de consulta de dados. O módulo Edição é uma aplicação stand-alone e sua interface com o usuário é implementada com componentes Swing da Java API. O módulo Gerenciamento é uma aplicação Web que utiliza tecnologia JavaServer Faces (JSF). A tecnologia JSF é um framework para construção de aplicações Web que executa em um servidor Java e renderiza a interface gráfica UI como resposta para o cliente [JSF 2006]. API. O módulo Monitoramento é uma aplicação Web e utiliza uma JApplet da Java Os módulos Edição e Monitoramento são inicializados a partir do módulo Gerenciamento utilizando Java WebStart 8. Conclusão Este artigo apresenta um estudo sobre processos de desenvolvimento e Desenvolvimento Distribuído de Software, visando propor uma ferramenta de apoio ao gerenciamento de projetos que possibilita a especificação, modelagem e execução de processos de software. Após a descrição dos fundamentos de modelagem e execução de processos de software, foi proposta uma arquitetura que possibilita desde a especificação e modelagem de um processo até a sua execução. Propôs-se, ainda, uma ferramenta baseada nessa arquitetura com o objetivo de auxiliar no gerenciamento de projetos de desenvolvimento distribuído de software. Uma das contribuições da ferramenta proposta é a possibilidade de instanciar um processo de software especificado resultando em uma maior flexibilidade de desenvolvimento. Além disso, a utilização de redes de Petri na modelagem possibilita uma visualização de fácil entendimento, descrevendo os aspectos estáticos e dinâmicos do processo. Embora a ferramenta permita que os processos modelados sejam executados por equipes de desenvolvimento geograficamente distribuídas, a distribuição do processo é transparente ao usuário e o gerenciamento dos projetos ocorre de forma virtualmente centralizada. Entretanto, diversos aspectos acerca da distribuição do processo podem ser melhorados. São propostos como trabalhos futuros o suporte a colaboração e cooperação

dos sites envolvidos nos projetos, a coleta de métricas durante a evolução do processo e o gerenciamento dos recursos necessários aos projetos. Referências Bohem, B. W. (1986). A spiral model of software development and enhancement. ACM Software Engineering Notes. Conradi, R. e. a. (1994). EPOS: Object-Oriented Cooperative Process Modelling, pages 33 70. Software Process Modelling and Technology, taunton: research studies press edition. Curtis, B. (1992). Process modelling. Communications of the ACM, 35(9). Hibernate (2006). Relational persistence for java and.net. http://www.hibernate.org. Huzita, E. H. M; Tait, T. F. C. (2006). Gerencia de projetos de software. XII Escola Regional de Informática da SBC. Jacobson, I. e. a. (1999). Unified software development process. Addison-Wesley. JSF (2006). Javaserver faces technology. http://java.sun.com/javaee/javaserverfaces. Pádua, S. I. D.; Silva, A. R. Y. P. A. J. V. I. R. Y. (2004). The potencial of petri nets in modeling and analysis of workflow. Gestão e Produção, 11(1):109 119. Pedras, M. E. V. (2003). Uma ferramenta de apoio ao gerenciamento de desenvolvimento de software distribuído. Master s thesis, Universidade Estadual de Maringá/Universidade Federal do Paraná, Maringá - PR. Petri, C. A. (1962). Kommunikation mit Automaten. PhD thesis, University of Bonn, Bonn, West Germany. Pressman, R. S. (2005). Software Engineering: A Practitioner s Approach. McGraw-Hill, USA, 6 edition. Prikiladnick, R.; Audy, J. L. N. (2004). Munddos - um modelo de referência para desenvolvimento distribuído de software. XVIII Simpósio Brasileiro de Engenharia de Software. Racoon, L. (1995). The chaos model and the chaos life cycle. ACM SIGSOFT Software Engineering Notes. Raposo, A. B. (2000). Coordenação em Ambientes Colaborativos Usando Redes de Petri. PhD thesis, Universidade Estadual de Campinas, Campinas - SP, Brasil. Reis, C. A. L. (1998). Gerenciador de processos de software para o ambiente prosoft. Master s thesis, Universidade Federal do Rio Grande do Sul, Instituto de Informática - Programa de Pós-Graduação em Ciência da Computação. Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON. Taba (2006). Estação taba - ambiente de desenvolvimento de software. http://ramses.cos.ufrj.br/taba/.