Métodos e Ferramentas para a
Gestão do Conhecimento
Professor Edson Emílio Scalabrin
telefone: 0xx41-330-1786
e-mail: [email protected]
download: http://www.ppgia.pucpr.br/~scalabrin
Plano - Parte I
Construção de uma Memória Organizacional
 Assunto:
• A construção de uma memória organizacional.
 Objetivos:
• Descrever alguns pontos importantes relativos a
fase de construção de uma memória
organizacional.
• Apresentar algumas tecnologias/metodologias de
implementação de sistemas computacionais
• Apresentar um projeto de capitalização de
conhecimentos usando CBR e Agentes
2
Plano - Parte I
Construção de uma Memória Organizacional
 Primeira etapa:
• Consiste em fazer um inventário sobre o
estado atual.
 Objetivo:
• Determinar:
– os membros da empresa envolvidos pelo operação
de Capitalização (tanto como fonte de expertise
como usuários em potencial),
– as fontes documentárias e as bases de dados
disponíveis na empresa.
3
Plano - Parte I
Construção de uma Memória Organizacional
 Exemplos de possíveis fontes:
• especialistas humanos
• documentos em papel ou eletrônicos existentes
– notas, relatórios, documentos contratuais,
documentação técnica, atas de reuniões,...
• mensagens trocas por correio eletrônico
• base de dados
• dicionários
• glossários, esquemas de CAD ...
4
Plano - Parte I
Construção de uma Memória Organizacional
 O estudo do ambiente de
trabalho dos
futuros usuários permite escolher o modo
de materialização da memória
 Ela pode compor-se de documentos em
papel ou eletrônicos tornando explícitos os
conhecimentos dos especialista da empresa
5
Plano - Parte I
Construção de uma Memória Organizacional
Ela
pode ser implementada por meio de:
• um sistema de gestão de documentação, que
explore os documentos existentes da empresa
• uma base de dados relacional
• um armazém de dados (data warehouse)
• uma base de conhecimentos
• uma base de casos
• um sistema baseado na Web
• um sistema multi-agente
6
Tecnologias de implementação
 Objetivo
• Fazer um sobrevôo as tecnologias: banco de
dados relacional, armazém de dados (data
warehouse), base de casos, agentes de
software.
 Forma de
apresentar
• Evolução tecnológica do processamento de
dados e da informação, e apresentação de
uma aplicação.
Evolução Tecnológica
 1as.
Edições de Banco de Dados preocupavam-se
de forma não separada do:
• processamento de transações (online)
• processamento em lote
• processamento analítico
 Edições
subsequentes promovem a separação
destes diversos processamentos:
• para atender necessidades operacionais
• para atender necessidades informacionais ou
analíticas
 Evolução
= PC + Linguagens de Quarta Geração.
Evolução Tecnológica
 Razões
da divisão: operacional vs. informacional
• os dados que atendem as necessidades
operacionais são fisicamente diferentes dos dados
que atendem as necessidades informacionais;
• a tecnologia de suporte é diferente;
• a comunicação dos usuários com os BDs é
diferente;
• as características de processamento do ambiente
operacional e do ambiente informacional são
fundamentalmente diferentes.
Evolução Tecnológica

O que é processamento informacional ?
• É o processamento que atende às necessidades
dos gerentes durante o processo de tomada de
decisões
O processamento analítico examina amplos
espectros de dados para detectar tendências
 A execução de um processamento analítico
requer o acesso muitos registros.

Evolução Tecnológica
1960
Arquivos mestres, relatórios
1965
Explosão dos arquivos mestres
• complexidade de manutenção
e desenvolvimento
• sincronização dos dados
• hardware
Evolução Tecnológica
1970
DASD (Direct access storage device)
• SGBD
• BD
• “uma única fonte de dados para
todo o processamento”
1975
Processamento de transações
online e de alta performance
Evolução Tecnológica
MIS/SAD
Processamento
de transações
1980
PCs, tecnologia L4G
O paradigma de
um único BD para
todos os fins
Evolução Tecnológica
Surgimento de programas de extração
 Trata-se de
programas mais simples que
varrem um arquivo ou BD, usando alguns
critérios de seleção, e, ao encontrar dados
que atendem aos critérios, transporta os
dados para outro arquivo ou BD.
Evolução Tecnológica
Natureza do processamento de extração
1985 - PCs, tecnologia L4G
Iniciar com alguns parâmetros, pesquisar um
arquivo baseado na satisfação dos parâmetros,
e, então passar os dados para outro local.
Por que processamento de extração ?
• Performance e controle
Arquitetura de Desenvolvimento Espontâneo
Ambiente de sistemas herdados
Arquitetura de Desenvolvimento
Espontâneo
 Problemas da
arquitetura:
• credibilidade dos dados
• produtividade
• impossibilidade de transformar dados em
informação
Arquitetura de Desenvolvimento
Espontâneo
Dept. A
10%
Business
Week
Diferencial algorítmico:
A) domingo à tarde + contas antigas
B) 4a feria à tarde + contas grandes
Nenhuma fonte de dados comum para começar
Wall
Street
Journal
Dept. B
-20%
Arquitetura de Desenvolvimento
Espontâneo
 Problemas de
 Caso
produtividade
1:
• a gerência pretende produzir um relatório
corporativo utilizando os diversos arquivos e
conjuntos de dados que acumulou durante os
anos.
• O que fazer ?
Arquitetura de Desenvolvimento
Espontâneo
 O projetista destacado para
a tarefa decide
que há três coisas que devem ser feitas para
produzir o relatório corporativo
• localizar e analisar os dados para o relatório
• compilar os dados para o relatório
• obter recursos humanos de programação /
análise para realizar os pontos acima.
Arquitetura de desenvolvimento espontâneo:
não conduz a produtividade
Produzir um relatório
corporativo, varrendo
todos os dados
Para localizar os dados
é necessário examinar
muitos arquivos
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Muitos programas de
extração, todos
customizados, precisam
cruzar diversas barreiras
tecnológicas.
Arquitetura de D.E.
tempo solicitado para a geração do relatório
x
x
x
x
x
x
x
x
x
x
Localizar os dados
9 - 12 meses
Obter os dados
15- 24 meses
Programadores/analistas ???
---------------------------------------------------------3 - 5 anos
1o. Relatório
2o. Relatório
...
No. relatório
3 - 5 anos
OBS:
Exceto ser em raras
circunstâncias, o
trabalho realizado
para o 1o. Relatório
não prepara o
caminho
para os demais.
Dos Dados às Informações

Já é difícil descobrir quais dados estão
associados a uma conta, tentar então extrair
informações dessas aplicações segundo um
critério geral é quase impossível.

Problema:
• a construção das aplicações jamais levou em
conta a noção de integração, e decifrar as
informações não é fácil para o analista de SAD.
Banco de Dados
Modelo
Relacional
Modelo Relacional

Sistemas Operacionais: Geralmente implementados
através de banco de dados relacionais.

Sistemas Analíticos: Geralmente implementados através
de um banco de dados dimensional.
SISTEMA OPERACIONAL
PROJETO
BOTTOM-UP
SISTEMA ANALÍTICO
PROJETO
TOP-DOWN
Modelo Relacional
 Definição: Representa os dados como uma coleção de
tabelas.
Tabela Produto
Chave_produto
Descrição
Tabela Loja
Chave_loja endereço
Marca
Categoria
Preço Compra
Preço Venda
nome
Tabela Venda
Chave_venda
Chave_produto
Chave_loja
quantidade nota
data
Relacionamento

No modelo relacional, as tabelas mantém um relacionamento
entre si. No exemplo abaixo, os registros da tabela venda se
relacionam com os registros das tabelas loja e produto.
venda
No modelo relacional os dados
do produto não precisam ser
duplicados para cada registro
de venda.
1
2
3
produto
4
loja
X
a
b
Y
Implementação Física do
Relacionamento

Os relacionamentos são implementados fisicamente através
do relacionamento das chaves primárias de cada tabela que
compõe o relacionamento.
Tabela Produto
Chave_produto
Descrição
Tabela Loja
Chave_loja endereço
Tabela Venda
Chave_venda
Marca
nome
Chave_produto
Categoria
Preço Compra
Preço Venda
Chaves estrangeiras
Chave_loja
quantidade nota
data
Formas Normais
 Regras
desenvolvidas para:
• Evitar inconsistências lógicas nas operações de
atualização das tabelas.
• Evitar redundância na organização das tabelas.
Primeira
Forma
Normal
Segunda
Forma
Normal
Terceira
Forma
Normal
Aumenta as restrições
Diminui o desempenho
Primeira Forma Normal – 1FN

Definição: o domínio de todos os atributos das
tabelas deve ser atômico (indivisível)
• Cada coluna da tabela deve conter só um tipo de atributos
Tabela
Pessoa
id_pessoa nome contato
Brigadeiro Franco
233-3932
[email protected]
Não
Satisfaz
1FN
Satisfaz
Tabela
Pessoa id_pessoa nome endereço telefone email 1FN
Segunda Forma Normal – 2FN

Definição: cada tabela deve satisfazer a 1FN, cada
registro deve ter uma chave primária e cada campo não
chave deve depender totalmente da chave primária.
chave primária: id_pessoa, conta
Não Satisfaz 2FN
id_pessoa nome endereço conta saldo agência endereço_agência
Satisfaz 2FN
chave primária: id_pessoa
id_pessoa nome endereço conta
os campos dependem
apenas de parte da chave
primária, alguns apenas de
conta outros apenas de
id_pessoa
chave primária: conta
conta saldo agência endereço_agência
Terceira Forma Normal – 3FN

Definição: cada tabela deve satisfazer a 2FN e cada atributo
não chave primária depende diretamente da chave primária.
id_pessoa nome endereço conta
o endereço da agência não
depende da conta, mas da
agência.
conta saldo agência endereço_agência
conta saldo agência
agência endereço_agência
Não Satisfaz 3FN
Satisfaz
3FN
Integridade

Devem ser observados dois tipos de integridade:
• a) Integridade de Entidades (cada tabela deve ter
exatamente uma chave primária)
• b) Integridade Referencial (cada chave estrangeira deve
ser consistente com sua chave primária correspondente)
Chave
primária
Chave
estrangeira
Tabela Pessoa
id_pessoa nome endereço id_empresa
Tabela Empresa
id_empresa nome_da_empresa endereço
Integridade Referencial


O valor da chave estrangeira deve existir na tabela empresa ou
ser NULO.
Quando um registro da tabela empresa for excluído, todas os
registros da tabela pessoa que façam referência a esse registro
devem ter o valor da sua chave estrangeira alterado para NULO.
Tabela Pessoa
id_pessoa nome
endereço
id_empresa
1
Adao
YYY
2
2
Eva
YYY
2
Tabela Empresa
id_empresa nome_da_empresa endereço
2
ZZZZ
WWW
Características do Modelo
Relacional



Reduz a redundância das informações armazenadas, diminuindo o
espaço total gasto para armazenar-las.
Simplifica significativamente as operações de escrita, tanto na
inserção de novas informações quanto a alteração de informações
existentes.
Complica as operações de leitura. Quanto mais normalizado for o
modelo do banco de dados operacional, mais lenta e trabalhosa será
a operação de leitura.
1a FORMA
NORMAL
Redução no volume
de dados e aumento
da consistência
2a FORMA
NORMAL
3a FORMA
NORMAL
Desempenho
na leitura
Modelo Relacional: Conclusões
Operação: ESCRITA:
• Apenas um pequeno número de registros precisa ser alterado.
• Por exemplo, para associar uma nova conta ao usuário os
dados do usuário não precisam ser recadastrados.
Operação: LEITURA:
• Várias tabelas precisam ser associadas para obter a resposta.
• Por exemplo, para obter o faturamento total que uma loja
obteve com um dado produto, num dado período.
ESCRITA
LEITURA
Modelo Dimensional

Considere a seguinte afirmativa.
• “Nós vendemos produtos em vários mercados, e nós
medimos nosso desempenho ao longo do tempo”.

O modelo de dados mais adequado para representar
diversas relações entre grandezas é o modelo dimensional.
TEMPO
Cada ponto do cubo
representa uma
combinação de
Produto, Mercado e
Tempo armazenado.
MERCADO
PRODUTO
Modelo Dimensional = Esquema em Estrela

O projeto de um banco de dados dimensional é do
tipo top-down, isto é, ele é projetado a partir do tipo
de análise que se quer efetuar.
DIMENSÃO PRODUTO
ANÁLISE DE VENDAS
(TABELA DE FATOS)
DIMENSÃO TEMPO
Chave_tempo
dia_da_semana
mês
quadrimestre
ano
flag_feriado
Chave_tempo
Chave_produto
Chave_loja
reais_faturados
unidades_vendidas
reais_gastos
Chave_produto
descrição
marca
categoria
DIMENSÃO LOJA
Chave_loja
nome_da_loja
endereço
tipo_de_planta_da_loja
Modelo Dimensional:
Conclusões
Operações:
• ESCRITA: Não pode ser utilizado, pois não guarda os registros na forma
de unidades.
• LEITURA: Rápida, pois a consulta é feita basicamente em uma única
tabela.
Características dos Bancos Analíticos:
• A dimensão de tempo é definida de acordo com uma granularidade prédefinida: dia, semana, mês. Ela não reflete o instante em que as
operações individuais foram efetuadas.
• O projeto é top-down, isto é, a tabela central parte do objetivo final da
análise.
• Não contém necessariamente todos os atributos relativos aos dados,
apenas os que interessam para análise.
• Não é adequado para efetuar transações operacionais.
Exemplo
Projeto PROCEE
Projeto ProCSEE :
Caso IACK ( Interaction Agent for Capitalizing
Knowledge )


Exemplo de projeto de capitalização
de conhecimentos visando a
construção de uma memória de um
projeto software.
Particularidade:
• agentes de software
• CBR - Case Based Reasoning
Projeto ProCSEE
Objetivo:
Construir uma arquitetura de um ambiente
de engenharia de software cooperativo,
atendendo a interação de um grande
grupo de pessoas distribuídas.
Projeto ProCSEE
optimization, statistics and
coordination algorithms
customization, update
and query mechanisms
programmer
Interaction
Agent
Systems
analyst
Interaction
Agent
Design-Patterns,
Frameworks and
Components Library
Systems
Interaction manager
Agent
.
knowledge
repository
CSCW
metrics
repository
tools for
supporting
communication,
collaboration and
coordination
Software engineering
processes templates
customer
Projeto ProCSEE
IACK
Consulta a
Competências
Visualizador
de Estado de
Projeto
Repositório de
Competências
Repositório
de Projetos
Scheduler
Capturador
de Eventos
Repositório
de Eventos
Interpretador
de Eventos
Parte do ProCSEE referente ao implementador
Projeto I.A.C.K

Implementação de um agente de software para capitalizar os
conhecimentos de um implementador de software.

Principais atividades :
• a definição e implementação de um modelo para representar e
armazenar as atividades de um implementador
• a captura de eventos relacionados as atividades de um
implementador
• o armazenamento de eventos em repositório
• a interpretação dos eventos relativos ( capturados ) a execução de
uma atividade de um implementador
• o calculo de desempenho ( nota ) de um implementador no tocante a
execução de suas atividades
Projeto I.A.C.K : motivação

Desenvolver de mecanismos visando a
capitalização dos conhecimentos de implementador
de software de maneira semi-automática.

Alimentar e atualizar uma base de conhecimentos
sobre as competências dos implementadores de
softwares de uma organização.

Melhorar a alocação de recursos e o cálculo dos
custos de um projeto de software.
Tarefa, atividade, eventos
Tarefa
Atividade
Atividade
Atividade
...
Modelo de atividades inclui:
Eventos Eventos Eventos
...
 recursos utilizados
 descrição da atividade
 astúcias
Armazenamento . . .
 Os conhecimentos sobre a
execução das
atividades são armazenados na forma de
casos.
• CBR - Case-Based Reasoning
 Os conhecimentos sobre as
competências
dos programadores são armazenados na
forma de objetos + ligações
Raciocínio baseado em casos
Idéia:
• Raciocínio baseado em
casos resolve novos
problemas adaptando
soluções que foram usadas
no passado para resolver
problemas similares
no presente.
?
Descrever a
situação atual
!
base de
casos
Aplicar o
conhecimento
Raciocínio baseado em casos
CBR tipicamente possui um processo cíclico
que compreende quatro Re’s:
•
•
•
•
Recuperar os casos mais similares ou próximos
Reutilizar o(s) caso(s) para tentar resolver um problema
Revisar a solução proposta se necessário
Reter a nova solução um novo caso
Obs.:
Memória dinâmica
Ciclo do CBR
Recupera
Problema
Retenção
Base de Casos
R
e
u
s
o
Revisão
Confirmação da Solução
Solução Proposta
Agente de interação
“É um programa que pode agir no lugar de um ser
humano, empregando técnicas de INTELIGÊNCIA
ARTIFICIAL:
 para executar certas tarefas relativas a manipulação de informações
[Sycara 96];
 para fornecer uma assistência a um usuário, negociando uma
informação com uma outra aplicação [Maes 94a,b];
 para responder solicitações feitas por usuários e/ou por
outros agentes [Wooldridge & Jennings 95];
 para criar um perfil do usuário a partir de um modelo de suas
atividades, habilitando assim o agente a fornecer informações no
tocante a execução de suas atividades.”
Organização dos agentes por função
USER 1
Goal and Task
Specification
USER 2
USER N
Results
Interface Agent 1
Interface Agent 2
Interface Agent n
Task
Task
Proposed Solution
Task Agent 1 Conflit Resolution
Information
Integration
Information
Reply
Request
InfoAgent 1
query
Collaborative
Query
Processing
Task Agent 1
InfoAgent 2
InfoAgent n
answer
Info
Source 1
Info
Source 2
Info
Source 3
Info
Source n
Considerações . . .

Permite melhor avaliar a competência de cada
implementador, e consequentemente melhor alocar
os implementadores nos projetos

Permite gerenciar o conhecimento de grupo através
do modelo de atividades

Permite a disseminação das astúcias ao grupo, bem
como as informações ligadas a execução as suas
atividades
Considerações gerais . . .

O conhecimento deve deixar de ser propriedade de
alguns privilegiados e se transformar em uma
ferramenta de negócio comum a todos os
profissionais (ex. implementador) de uma empresa

Inteligência acumulada  vantagem estratégica
Exercício

Propor uma definição para competência

Propor um modelo de representação de competências

Elaborar um conjunto de questionamento possível e desejável
que poderão ser feitas ao sistema de gestão de talentos ou
competências

Se existe, quais são os benefícios estratégicos que uma
organização pode obter a parir deste sistema ?

Na sua opinião esse sistema pode servir como uma primeira
abordagem para se fazer uma gestão racional do capital
intelectual de uma organização ?
Referências . . .

GRUNDSTEIN M., BARTHÈS J-P., An Industrial View of the Process of
Capitalizing Knowledge, 4th. International ISMICK Symposium, Edited by
Dr. J.F. Schreinemakers, 21-22 October, 1996.

KOLODNER, JANET, Case-Based Reasoning - Morgan Kaufmann
Publishers, San Mateo, 1993.

MAES P., Agents that reduce work and information overload, In :
Communications of the ACM, 37(7), July, 1994a.

MAES P., Social interface agents : Acquiring competence by learning
from users and ohter agetns, In : O. Etzioni (eds.) Software Agents Papers from the 1994 Spring Symposium
(Technical Report SS-94-03), pp. 71-78, AAAI Press, 1994b.
Referências . . .


R.C.Burnett, A.Calsavara, C.Maziero, E.Jamhour, E.Scalabrin, R.Betini – “An
Integrated Environment for Supporting Cooperative Software Engineering”PUCPR – Curitiba - Brasil,1998.
SCHEIREINEMAKERS, Jos F. KNOWLEDGE MANAGEMENT Organizatioon,
Conpetence and Methodology. Würzburg: ERGON-Verl; 1996.




SYCARA K., DECKER K., WILLIAMSON M., PANNU A., Distributed Intelligent
Agents, In : IEEE Expert, July, 1996.
WIIG, Karl M. KNOWLEDGE MANAGEMENT – Thinking about Thinking –
How People and Organizations Create, Represent and Use
Knowledge.Schema Press,Texas, 1993.
WIIG, Karl M. – KNOWLEDGE MANAGEMENT METHODS – Pratical
Approachs to Managing Knowledge – Schema Press – Texas, 1993.
WOOLDRIDGE M., JENNINGS N., Intelligent agents : theory and practice, In :
The knowledge Engineering Review, Vol. 10 (2), pp. 115-152, 1995.