Systèmes de gestion des ressources en eau

Para apoiar o processo de externalização do conhecimento, é proposto um mecanismo de incentivo que deverá estimular os membros da equipe distribuída a contribuir para o repositório contendo o registro das atividades e produtos gerados pelo grupo. O conhecimento explicitado deve ser armazenado e seu autor recompensado pelas contribuições realizadas. Tal conhecimento ficará disponível ao grupo sob a forma de relatos de experiências, a fim de auxiliar as atividades ou tomadas de decisões. Com isto, cada experiência consultada terá um registro de acesso armazenado no repositório e os integrantes deverão informar se a mesma foi reusada ou não para a realização de uma atividade. O mecanismo é detalhado na seção 3.4.

3.3 Ambiente inicial como uma extensão do modelo de Templates de Decker e equipe

Nas seções anteriores descrevemos o conjunto de ferramentas propostas para apoiar os processos de externalização e disseminação do conhecimento em uma equipe distribuída de trabalho, associadas a um repositório de experiência para dar suporte às atividades individuais e de grupos. Nesta seção, incorporamos este conjunto de ferramentas aos estudos de Decker et

82 A Figura 3.12 ilustra a arquitetura geral do ambiente, dividida em quatro camadas: Camada de modelo, Camada de Funcionamento, Camada de Busca e Classificação e Repositório de dados (Biblioteca de Documentos).

Figura 3.12 – Arquitetura geral do ambiente em quatro camadas.

Camada de Modelo: neste nível, possuímos os principais modelos de documentos utilizados no ambiente, os modelos são formados por conjuntos de variáveis constituindo metadados para os documentos. Se um membro do ambiente utilizar qualquer um dos nove modelos, já estará facilitando a análise e classificação das informações pelo ambiente e, por conseqüência, a sua localização no futuro. Note-se que incluímos o Modelo de Experiência, o Modelo de Enquete, o Modelo de Fórum e o Modelo de Bate-papo. Estes últimos três modelos foram adicionados por existir uma necessidade em nossa realidade e por fazer parte de funcionalidades que auxiliam a comunicação entre as equipes geograficamente distribuídas. Uma das principais razões para a incorporação dos Modelos de Fórum, de Enquete e de Bate-papo vem de um problema muito comum nas organizações: a necessidade de reunir pessoas que possuem conflitos de horário e por estarem em locais diferentes. Como se trata

83 de ferramentas síncronas e assíncronas, é possível reduzir este problema e reunir o máximo possível de opiniões para decisões importantes no ambiente. Em relação ao Modelo de Experiência, ele segue o princípio do template “Hint” de Decker et al. (2005), que é a de manter sugestões, conselhos, parte de conhecimento que auxilie o projeto ou desenvolvimento de funcionalidades ou resolução de problemas.

Camada de Funcionamento: nesta camada, é possível visualizar a interação do usuário com as atividades e o seu histórico de interação. A camada também apresenta outros documentos que são gerados a partir dos modelos e que fazem parte de um projeto, mantendo as informações classificadas por seu tipo e assunto. Do lado esquerdo da Figura 3.7, tem-se a Página Wiki referente ao Projeto, Páginas de Perfis do projeto e do lado direito têm-se os documentos de auxílio à retenção de experiências das atividades em grupo e individuais, por exemplo, Fórum, Enquetes e Bate-Papo. Estes três documentos têm a finalidade de armazenar as decisões tomadas em grupo pela equipe do projeto e a última e não menos importante, a Página Wiki de Experiência, que funciona como dicas para soluções de problemas encontrados em projetos, definições de bibliotecas de objetos utilizados na construção do sistema, armazena experiência sobre funcionalidades, regras e visões de membros da equipe a qualquer fase do desenvolvimento do projeto.

Camada de Classificação e Busca: neste nível, existe o mecanismo de classificação de contexto e rastreamento que auxilia o usuário a navegar entre as informações existentes no repositório (Biblioteca de documento), procurando informações que sejam fundamentais ao sucesso do projeto de que fazem parte. Este mecanismo é responsável por interligar e classificar o conhecimento descrito em cada documento existente no ambiente.

Camada do Repositório de dados: esta camada é responsável pelo armazenamento das informações, permitindo a localização, por meio da utilização do Analisador de Conteúdo, as experiências.

84 cenário para apoiar a gestão e a reutilização dos documentos gerados dentro de projetos.

A arquitetura apresentada pode ser estendida de acordo com a necessidade do projeto ou da política da organização. Um exemplo para tal extensão é a implementação em um Modelo de documento descrevendo algumas fases do projeto. Uma vez que links são permitidos em diferentes tipos de documentos definidos nos Modelos, sugestões de tais links entre documentos podem ser providas para as instâncias. Por exemplo, quando a Atividade é criada, a mesma possui ligação com as instâncias do Modelo de Usuário e é apresentada junto ao conteúdo do documento de Atividade. Dessa forma, o usuário pode interagir diretamente com a Atividade corrente devido à ligação.

Como em (Decker et al., 2005), utilizamos um princípio de verificação de consistência, possibilitada pela anotação semântica. Por exemplo, a relação entre Usuário, Atividade e Histórico de Interação implica que cada Usuário deve fazer parte de pelo menos uma Atividade. Desta forma, podemos trabalhar com uma espécie de ordem temporal. Portanto, se um Histórico de Interação tem uma data mais recente que a Atividade, esta Atividade precisa ser verificada para saber se possui consistência com atualização do Histórico de Interação.

A Figura 3.13 exemplifica a troca de documentos similares através do cruzamento de projetos e também como é criado um novo item no Histórico de Interação para o usuário, ligando o projeto e o usuário, e como o contexto de informação pode ser obtido. Um usuário “A” está trabalhando em uma atividade e precisa obter informações sobre um determinado assunto. Ele utiliza a interface de usuário informando suas necessidades e submete ao Analisador de Conteúdo, que pesquisa as informações solicitadas no repositório e identifica que o projeto 2 possui informações similares ao solicitado pelo Usuário “A”. Desta forma, o Analisador responde ao Usuário “A” passando títulos dos documentos (links estabelecidos anteriormente pelo Analisador de Conteúdo). A partir daí, o solicitante pode selecionar o link e ler o conteúdo do documento informado.

85

Figura 3.13 – Destaque da camada de funcionamento na arquitetura do ambiente.

No ambiente proposto, forçamos de forma indireta que o solicitante, ao ler um conteúdo de outro membro dê seu julgamento, podendo o mesmo selecionar “0” quando o usuário não sabe exatamente se o conteúdo é útil ou não ao seu contexto, ficando neutro, “-1” quando o documento não se aplica ao seu contexto e “1” para quando o conteúdo do documento é útil ao contexto que o usuário necessita no momento. O Analisador tem o papel de entender quando um documento foi julgado ou não. Ele também tem a função de definir qual pontuação o solicitante vai receber. Por exemplo, ele obtém as informações do solicitante em relação à quantidade de documentos abertos e a quantidade julgada pelo solicitante e se a relação não for 1 para 1, o solicitante recebe uma pontuação negativa (imaginemos que o solicitante possui 3 documentos abertos e lidos e apenas 1 julgado, o solicitante iria receber 2 pontos negativos em seu saldo de pontos). Maior detalhamento da pontuação por usuário, bem como do mecanismo de incentivo proposto, é fornecido na seção 3.4.

Ao ler um documento, o usuário pode reutilizar seu conteúdo e também pode acrescentar mais informações. Porém, ao inserir informações ao conteúdo original, as

86 alterações ficarão no corpo do documento original como um link. Ou seja, a informação gerada pelo usuário passa a existir como uma Página Wiki de Experiência e o usuário recebe uma pontuação pela contribuição. Tal decisão de projeto facilita para o ambiente preservar o documento original e protege contra vandalismo. O Analisador de Conteúdo é responsável pelo processo de interligar o conteúdo gerado ao original e também atribuir a pontuação ao saldo de pontos do usuário.

Há ainda o caso em que o usuário poderá gerar conteúdo sem a necessidade de abrir um já existente, mas isto não degrada o ambiente, pois as ligações são feitas também com a atividade e com o projeto. Desta forma, o usuário tem flexibilidade de chegar ao conteúdo com mais facilidade. Neste caso, estamos nos referindo ao conteúdo gerado a partir de uma demanda do próprio ambiente: quando os usuários procuram algum tipo de informação que não existe, a necessidade é mantida em uma lista e os membros poderão responder disponibilizando a informação necessária para suprir à necessidade. No ambiente proposto, chamamos tal forma de contribuição de “Contribuição sob Demanda”.

Em relação ao Histórico de Interação, o mesmo contém descrições narrativas das interações entre atividades e usuário, ou seja, quando é realizado algum passo que complete, inicie ou movimente a atividade, o histórico é abastecido. Quando um usuário gera um conteúdo ou julga um conteúdo já existente, o histórico também recebe informações da contribuição. Desta forma, como foi dito anteriormente, o Histórico de Interação contribui para manter uma fidelidade de interações ocorridas entre usuário e atividade.