SISTEMA MULTIAGENTE BASEADO EM CASOS DE APOIO À GERÊNCIA DE PROJETOS

SISTEMA MULTIAGENTE BASEADO EM CASOS DE APOIO À GERÊNCIA DE PROJETOS Régis Gabineski Fabiana Lorenzi Abstract. The aim of the present article is to describe the benefits of a multiagent system based in cases focused in project management. Through RBC, the proposed system control the project resource allocation and the activities to be developed, in a dynamic and interactive way. Resumo. O principal objetivo deste artigo é descrever os benefícios de um sistema multiagente baseado em casos, focado na gerência de projetos. Através de Raciocínio Baseado em Casos, o sistema proposto controla a alocação de recursos do projeto e as atividades a serem realizadas, de forma dinâmica e interativa. Palavras-chave: Sistema baseado em casos; Sistema Multiagente; Gerenciamento de projetos. 1. Introdução Com a crescente demanda por processos dentro das organizações, fez-se necessário a criação de boas práticas para a condução de projetos. Com base em normas internacionais, ou mesmo, na experiência da organização, os processos são documentados e divulgados entre os colaboradores e especialistas. O PMBoK 2004 afirma que "projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo". As ferramentas existentes no mercado auxiliam na condução de projetos, dando visibilidade de custos, tempo e cronograma. No entanto, cabe à equipe do projeto aderir ao conjunto de processos da organização e, ao gestor do projeto, ter o cuidado ao definir atividades para sua equipe. Aderir ao conjunto de processos requer treinamento, habilidade e conhecimento.

2 Uma das tarefas do gestor é alocar atividades aos recursos do projeto sem exceder às horas diárias, cumprindo as leis trabalhistas. Tratando-se de um projeto com centenas de atividades, o gestor precisa cuidar calendários, férias, recursos compartilhados, referências entre atividades antecessores e predecessores. As habilidades de gestão podem não prevalecer em situações esporádicas como múltiplos projetos a serem gerenciados, momentos cansaço, rotina de trabalho intensa, esquecimento e descuido. Não exceder às horas diárias ou não sobrecarregar a equipe com atividades além do permitido, são desafios constantes. Os desafios existem também no âmbito de processos da gerência de projetos, onde o conjunto de regras e boas práticas pré-estabelecidas define o caminho para a confecção de artefatos. O cumprimento dessas normas torna-se trabalhoso e, por vezes, não são cumpridas no projeto. Através do desenvolvimento de um ambiente multiagente baseado em casos, focado na gerência de projetos, os problemas de aderência aos processos da organização e de definição de um elevado número de tarefas para um recurso podem ser minimizados. Os processos da organização e as regras de negócio referentes ao número de atividades de cada recurso serão mapeados como Casos e consultados pelos agentes conforme for o andamento do projeto. É possível ter as Entradas e Saídas do PMBoK mapeados como Casos. Com o foco em instruir, os agentes estarão presentes na tela do computador de forma amigável e dinâmica, interagindo com o gestor para que possa conduzi-lo na tomada de decisões, auxiliando-o a cumprir as práticas mapeadas como casos. 2. Referencial Teórico O ambiente multiagente visa identificar pontos a serem melhorados nos atuais softwares de gerenciamento de projetos do mercado. Soluções licenciadas como o Microsoft Office Enterprise Project Management (EPM) e Primavera Project Planner (P3), desempenham muito bem as atividades no âmbito de controle de projetos. Dentre as ferramentas de livre distribuição, destaca-se o dotproject. Para a elaboração desse estudo, foram implantados projetos corporativos utilizando-se duas ferramentas: Microsoft Project, tanto na versão Windows quanto WEB, e dotproject, exclusivamente versão WEB.

3 O fator motivador para a criação de uma solução, baseada em sistemas multiagentes, está relacionado à ausência de interação dinâmica entre as ferramentas analisadas e o usuário final. Nas soluções existentes falta a notificação instantânea das decisões a serem tomadas, o que acarreta em retrabalho, revisão e não conformidades. 2.1 Sistema Multiagente Sistemas Multiagente (SMA) são sistemas compostos por múltiplos elementos computacionais interativos denominados agentes. Agentes são entidades computacionais com duas habilidades fundamentais: (1) de decidir por si próprios o que devem fazer para satisfazer seus objetivos de projeto e (2) interagir com outros agentes de forma social (...). (Wooldridge, 2002). A utilização de um sistema multiagente baseado em RBC com interface WEB, coloca o trabalho proposto no estado da arte da gestão de projetos. Através da autenticação do usuário, instruções e avisos personalizados são enviados pelos agentes. Os agentes, com aspecto visual dinâmico, reagem com as ações dos usuários autenticados no sistema. Com instruções pré-definidas e consulta aos casos do projeto inseridos no banco de dados, os agentes auxiliam na tomada de decisão de forma clara, dinâmica, enviando instruções escritas e de voz. O sistema multiagente deste trabalho propõe a utilização de dois agentes que consultam uma base de casos específica. Cada projeto possui sua própria base de casos. Confrontando com as atuais soluções disponíveis no mercado, o sistema proposto apresenta uma sinergia com o usuário de tal forma que decisões são tomadas no momento em que as não conformidades surgem, não havendo necessidade de aguardar a emissão de relatórios ou futura revisão. As bases de casos representam as melhores práticas de um determinado projeto, caminhos por onde a equipe deve passar para concluí-lo com sucesso. As bases de casos podem ser reaproveitadas de projeto para projeto, fato que está relacionado com a natureza ou similaridades encontradas. Agentes com funções específicas monitoram o banco de casos e, quando houver necessidade, indicam a decisão a ser tomada. Erros como estouro de horas ou não aderência ao ciclo de processos organizacionais podem ser minimizados. Podem, porque a decisão final ainda é humana.

4 2.2 Raciocínio Baseado em Casos A técnica de Lições Aprendidas, usada em gerenciamento de projetos, consiste na utilização da experiência de projetos anteriores para que possa se repetir o bom rendimento ou evitar problemas ocorridos. Aproveitar conhecimento adquirido em situações passadas é algo feito constantemente. Raciocínio Baseado em Casos (RBC), modelo baseado no aprendizado humano, é uma abordagem da Inteligência Artificial que pode ser vista de duas maneiras: uma metodologia para modelar o raciocínio e o pensamento humano ou uma metodologia para construir sistemas computacionais inteligentes. O paradigma do RBC busca sistematizar o emprego do aprendizado de experiências do passado para a solução de problemas atuais (KOLODNER, 1993). As situações bem sucedidas de projetos anteriores são inseridas no banco de casos para que sejam reaproveitadas, bem como as Lições Aprendidas. O sucesso do projeto devese ao reaproveitamento de casos e a habilidade da equipe. Sem o banco de casos e o sistema multiagente, o reaproveitamento é feito através de dezenas de documentos, de forma descentralizada. 3. Projeto do Sistema O projeto tem por objetivo apresentar um ambiente multiagente de apoio à gestão de projetos. Apresenta ainda idéias e serviços desenvolvidos que podem agregar valor às atuais ferramentas de gerência de projetos disponíveis no mercado. 3.1 Ambiente Multiagente A idéia de Sistema Multiagente resulta da incorporação de vários agentes para resolver um problema de complexa resolução. Da interação entre os vários elementos resultam as principais características de um sistema multiagente: Um agente não pode resolver o problema: por falta de informação ou capacidade, um único elemento não consegue isoladamente resolver o problema. A informação está distribuída: mais um fator de confiabilidade de um sistema multiagente. Ao distribuir e replicar a informação por vários agentes diminui-se a probabilidade de perca de informação.

5 A computação é assíncrona: o fato da computação poder estar fisicamente distribuída por vários nós aumenta a capacidade de processamento de informação, tendo, no entanto, acrescidas necessidades de sincronização entre agentes no momento da comunicação. Auto-organização: a inexistência de um sistema centralizado de controle exige que cada agente se auto-organize com vista ao cumprimento do seu papel no sistema. Cada agente deve reagir e adaptar-se de forma autônoma às alterações do ambiente. Competição e cooperação: são formas usuais de relacionamento entre agentes integrantes do mesmo sistema. Processos de competição e cooperação podem conduzir mais facilmente à obtenção do objetivo comum. Neste trabalho, foram desenvolvidos dois agentes diferentes: Agente AGP (Apoio à Gerência de Projetos), apresentado pela Figura 1. Figura 1. Representação do agente AGP O agente AGP tem como objetivo notificar o usuário autenticado no sistema sobre todas as atividades que devem ser concluídas. Através da pesquisa binária na árvore de Processos, o agente busca por atividades pendentes informando-as ao usuário. Agente ADA (Apoio à Definição de Atividades), representado pela Figura 2. Figura 2. Representação do agente ADA O agente ADA tem como objetivo notificar o usuário autenticado no sistema sempre que ocorrer a super alocação de atividades aos de recursos do projeto. No momento em

6 que o usuário tentar alocar mais tarefas além do permitido, como regra de negócio, o agente ADA envia notificações com o número das atividades que excederam. A Figura 3 representa o ambiente multiagente. Os agentes AGP e ADA atuam no mesmo sistema com objetivos diferentes. Figura 3. Ambiente multiagente. Agentes com objetivos diferentes Através da Figura 3 é possível visualizar que os agentes trabalham de forma independente, diferenciando-se pelas funcionalidades que exercem. Caso o usuário autenticado no sistema não tenha perfil de gerente de projetos, ou seja, não tenha direitos de alocar tarefas, o agente ADA não será exibido. Tendo em vista que todos os recursos do projeto possuem atividades a serem desempenhadas, o agente AGP sempre estará disponível notificando de pendências a serem realizadas. Esse trabalho propõe a utilização de Agentes em um sistema WEB, conforme exemplificado na Figura 4.

7 Figura 4. Agentes com objetivos diferentes, no mesmo ambiente A Figura 4 representa os objetivos dos agentes. O agente ADA informa que o usuário do sistema está com atividades além do permitido. O agente AGP, informa que o usuário do sistema possui atividades pendentes. A Figura 4 tem como objetivo demonstrar a utilização de agentes sendo executados ao mesmo tempo, no entanto, como possuem objetivos diferentes, apenas um agente terá a iteração com o usuário do sistema. 3.2 Raciocínio baseado em casos O Raciocínio Baseado em Casos é uma técnica de resolução de problemas na qual soluções de problemas antigos ou conhecidos (os casos armazenados) são utilizadas na solução de novos problemas [KOLODNER, 1993]. Um caso é uma representação de um problema da vida real. Dependendo do sistema, os casos modelados podem ter diferentes características. 3.2.1 Aquisição de conhecimento Segundo FERNANDES (apud BUTA, 1997), um caso é uma abstração de uma experiência, que deve estar descrita em termos de conteúdo e contexto. Estas experiências precisam estar organizadas em unidades bem definidas, formando a base de raciocínio ou memória de casos. Os casos representam o próprio conhecimento presente no sistema.

8 Dentre as várias técnicas existentes para a aquisição do conhecimento (MOTODA, 1991) foi escolhida a entrevista estruturada para o desenvolvimento desse estudo. Dentre as questões respondidas pelo profissional da área de gerência de projetos, foi feito um estudo nas fases e artefatos do Guia PMBoK (terceira edição publicada pelo Project Management Institute - PMI) e nas fases seqüenciais definidas RUP (Rational Unified Process). 3.2.2 A Representação de casos Um caso é um pedaço contextualizado de conhecimento representando uma experiência real (KOLODNER, 1993). Para esse estudo, a representação dos casos foi diferenciada conforme a implementação de cada agente. Para a implementação do agente AGP, um caso representa um artefato, elemento, atividade ou iteração de um projeto. Possuem em comum um processo pré-definido, pois estão contidos no mesmo ciclo de vida de desenvolvimento de um software. Os componentes de um caso são: Artefatos: representam os entregáveis (deliverables) do projeto. São documentos de entrada e de saída para os elementos; Elementos: representam a seqüência de passos a serem seguidas para construir um artefato; Atividades: representam tarefas a serem feitas no decorrer do projeto; Iterações: representam as fases do projeto em que se encontram o conjunto de atividades, elementos e artefatos. O processo de representação de casos deste sistema utilizou como base o PMBoK e o RUP, além da participação do especialista. Para o melhor entendimento do trabalho proposto, a Figura 5 apresenta a diagramação em árvore de como seria o mapeamento e exibição de casos no ambiente de gerenciamento de projetos. Um Projeto possui Atividades, que por sua vez contém Elementos, segmentando-se em artefatos de Entrada e Saída.

9 Figura 5. Representação de um caso estrutura em árvore Para a implementação do agente ADA, um caso é toda a Atividade do projeto que precisa ser associada a algum recurso (equipe do projeto). A Figura 6 representa, no sistema, a estrutura de Atividades, com Entradas, Saídas e Recursos. Figura 6. Representação de um Caso - Atividade com Entrada, Saída e Recurso A Figura 6 representa três Atividades: Abrir Projeto, Definir Arquitetura e Estimar Projeto. Cada uma das Atividades possui Entradas e Saídas, representadas pelas imagens com as letras [E] e [S] respectivamente. Para a Figura 6, temos disponíveis

10 apenas dois recursos: Fabiana e Régis. Cada Entrada ou Saída pode ter apenas um recurso associado, o que representa a pessoa responsável pela a entrega de determinado artefato. 3.2.3 Geração da base de casos Um caso representa o mapeamento dos processos de gerência de projetos. Para esse trabalho, foram mapeados 39 casos, conforme o modelo exemplificado na Tabela 1. TABELA 1. Representação da base de casos Caso Iteração Atividade Elemento Entrada Saída 1 Iniciação Abrir Projeto Formalizar Início do Projeto Documentos de Entrada na Fábrica Checklist do Projeto 2 Iniciação Abrir Projeto Formalizar Início do Projeto - Ficha de Projeto 3 Iniciação Abrir Projeto Divulgar Lições Aprendidas Ficha de Projeto Lições Aprendidas 4 Iniciação Abrir Projeto Divulgar Lições Aprendidas Base de Conhecimento - Apesar da Tabela 1 mostrar apenas os quatro primeiros registros da base de casos, é possível conduzir um projeto com 200 casos mapeados, segmentados entre dos diversos itens de gestão. A quantidade de itens mapeados na base de casos, está representada na Tabela 2. TABELA 2- Quantidade de itens da base de casos Itens Iteração Atividade Elemento Entrada Saída Quantidade 1 5 12 15 13 Os casos foram criados a partir do mapeamento de Iterações, Atividades, Elementos, Entradas e Saídas, conforme a visão do especialista e os processos do PMBoK e RUP. 3.2.4 Recuperação de casos A recuperação de casos do agente AGP consiste na busca por tarefas ainda não concluídas. Esse trabalho propõe que apenas as Atividades não concluídas sejam notificadas aos usuários do sistema. Para as atividades concluídas, é exibida uma mensagem padrão. Para montar a estrutura de processos, utilizou-se o algoritmo de árvore de decisão. A Árvore de Decisão é utilizada para descobrir regras e relacionamentos partindo e subdividindo a informação contida nos dados (CHOU, 1991). Um objeto é classificado

11 seguindo o caminho da raiz da árvore até a folha de acordo com os valores de seus atributos. A árvore contém as decisões a serem tomadas, usadas para criar um plano para se alcançar um objetivo. Para se construir a árvore, algumas decisões tiveram que ser tomadas. Primeiramente houve a necessidade de decidir quais atributos dos processos seriam considerados mais importantes, os quais deveriam ser alocados em nodos próximos ao topo da árvore, enquanto que os menos relevantes são considerados nos nodos próximos às folhas. Depois, estudou-se o valor (limiar) a ser utilizado como teste em cada nodo. A árvore é montada de forma automática sempre que a estrutura de casos é exibida. Instruções SQL ligam campos de diferentes tabelas do banco de dados, onde os casos estão armazenados, para montar uma estrutura gráfica amigável, indicando nodos Pai, Filho e dependências. A Árvore de Decisão foi projetada para ser do tipo binária, ou seja, cada nó teria duas arestas: uma para quando o valor encontrado na base é concluído e o outro para pendente, representados pelos números 1 e 0, respectivamente. A Figura 7 exibe a solução criada utilizando-se a árvore binária para o mapeamento dos casos juntamente com o agente AGP, que é exibido ao usuário após a autenticação no sistema para informar quais atividades estão pendentes. Figura 7. Solução em árvore sem atividades pendentes

12 A Figura 7 exibe a notificação que o agente AGP exibe quando não encontra atividades pendentes: Você não possui atividades pendentes. A recuperação do agente ADA consiste na verificação do número de atividades designadas para um determinado recurso do projeto. Entende-se por recurso qualquer integrante da equipe do projeto. Qualquer alocação de atividade no sistema que exceda o número definido na regra de negócio, para um determinado recurso, uma mensagem será exibida na tela pelo agente ADA. Na Figura 8 é possível visualizar o alerta enviado ao usuário do sistema no momento em que o número de atividades definidas como regra de negócio é excedida. Figura 8. Alerta do agente ADA para o número excedido de atividades definidas A mensagem exibida na Figura 8 avisa o usuário que o número de atividades recomendadas para o recurso foi excedido: Você definiu 11 atividades para Fabiana e o recomendado é 10. 4. Implementação do sistema Os agentes AGP (Agente de Apoio à Gerência de Projetos) e ADA (Agente de Apoio à Definição de Atividades) foram desenvolvidos baseados em tecnologia Microsoft.

13 Para a codificação do aplicativo foi desenvolvido um framework, denominado D9 Framework. Esse conjunto de funções visa agrupar todas as funcionalidades necessárias para o correto funcionamento da solução proposta. O Framework foi codificado usando ASP (Active Server Pages), JavaScript, AJAX, HTML, CSS e PL/SQL. Possui banco de dados SQL Server 2000 e hospedada no Web Server IIS, em localhost. 4.1 Diagrama ER Foram utilizadas as técnicas de engenharia de software a fim de produzir uma modelagem consistente e de fácil adaptação a novos requisitos. Para a construção do banco de dados, responsável por armazenar os casos, utilizou-se a ferramenta Microsoft Visio Architect 2000. A modelagem pode ser conferida na Figura 9. Figura 9. Modelo ER A arquitetura proposta nesse trabalho incorpora a utilização de agentes, trazendo diversos benefícios com a sua utilização: Autonomia, Heterogeneidade, Abertura, Distribuição, Dinamismo, Robustez e Segurança.

14 4.2 Microsoft Agent Esse trabalho utiliza agentes da Microsoft (Microsoft Agents). Para que fosse possível criar os movimentos, foi utilizada a ferramenta MASH (Microsoft Agent Scripting Helper), experimental por 30 dias. 4.3 Validação do sistema O processo de validação visa montar árvore de processos e verificar se a finalização dos documentos de Entradas e Saídas irá concluir ou não as Atividades do projeto. O sistema deve concluir as Atividades automaticamente sempre que os documentos de Entrada e Saída filhos forem concluídos. Enquanto a Atividade não for concluída, o Agente de identificar a pendência e notificar o usuário. O sistema inicia com as imagens de entrada e saída não preenchidas, ou seja, não concluídas, conforme a Figura 10. Figura 10. Imagem de Saída não concluída Na medida em quem os documentos de Entrada e Saída são utilizados no projeto, o usuário indica que realizou a tarefa, conforme a Figura 11. Figura 11. Imagem de Saída concluída Ao carregar o projeto, todas as Atividades estarão representadas conforme a Figura 12, ou seja, não estarão concluídas. Figura 12. Imagem de Atividade não concluída Após os documentos filhos da Atividade ser concluídos, o sistema AAGP reconhece e altera a imagem, colocando um troféu como ícone, conforme a Figura 13. Figura 13. Imagem de Atividade concluída

A Figura 14 representa a notificação que o agente AGP faz após consultar a base de dados e encontrar uma atividade pendente. 15 Figura 14. Imagem de notificação de atividade pendente Caso todas as Atividades tenham sido concluídas, o agente informa que o usuário não possui pendências. Para a validação do sistema foram selecionados aleatoriamente Entradas e Saídas da base de casos do sistema. O sistema foi capaz de concluir Atividades quando os documentos Entrada e Saída filhos foram concluídos. Isto significa que os casos armazenados na base foram gerados em árvore corretamente e que o Agente de Apoio a Gerencia de Projetos é capaz de identificar a conclusão ou não de itens e notificá-los ao usuário. Para validar a execução do Agente de Apoio à Definição de Atividades, foram definidas atividades além do permitido. Os avisos enviados pelos agentes AGP e ADA corresponderam conforme a interação com as atividades e com as regras de negócio préestabelecidas. A aquisição de conhecimento, tarefa difícil e demorada na maioria dos sistemas inteligentes, foi agilizada neste trabalho, pois em sistemas de RBC, os casos são adquiridos do especialista ao invés de regras. Outra vantagem é a reutilização do conhecimento contido nas bases de dados dos projetos, visto que os documentos de Entrada e Saída de repetem ao longo do ciclo de vida do projeto. 5. Conclusão Com a realização deste trabalho foi possível avaliar os benefícios que a aplicação de um sistema RBC em um sistema multiagentes proporciona, além de uma valiosa experiência prática desta técnica.

16 Mesmo de forma abrangente, pode-se avaliar que a área de gestão de projetos pode ser beneficiada com o uso dessa técnica, trazendo muitas vantagens e gerando soluções com potencial qualidade. A validação do sistema com casos reais de teste geraram resultados satisfatórios na opinião do especialista, concluindo que os fabricantes de soluções para o gerenciamento de projetos podem agregar valor às atuais ferramentas disponíveis com a implementação de agentes inteligentes. De modo geral, conclui-se que a implementação de um sistema RBC para a gerência de projetos foi totalmente válida e produziu resultados satisfatórios, mas não excluiu a interação humana. Referências CHOU, P.A. Optimal partitioning for classification and regression trees. IEEE Transactions on Pattern Analysis and Machine Intelligence, 1991. FERNANDES, Anita Maria da Rocha. Inteligência Artificial Noções Gerais Florianópolis: Ed: Visual Books, 2003. MOTODA, H.; R. MIZOGUCHI et al. Knowledge acquisition for knowledge-based systems, 1991. KOLODNER, J. L. Case-Based. Reasoning. Morgan Kaufmann Pub, Inc. 1993. PROJECT MANAGEMENT INSTITUTE, A. Guide to the Project Management Body of Knowledge, 2004.