VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
082
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
083
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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].
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
084
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
085
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
086
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
087
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
088
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
089
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
090
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
091
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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].
O módulo Monitoramento é uma aplicação Web e utiliza uma JApplet da Java
API.
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
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
092
VII FITEM - Fórum de Informática e Tecnologia de Maringá - X Mostra de Trabalhos de Informática, Maringá - PR, Outubro, 2006.
___________________________________________________________________________________________________________
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/.
__________________________________________________________________________________________________________
Universidade Estadual de Maringá - Departamento de Informática
093