Elementos para a Construção de
uma Memória Organizacional
Edson Emílio Scalabrin
telefone: 0xx41-330-1746
e-mail: [email protected]
download: http://www.ppgia.pucpr.br/~scalabrin
Plano
 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
Elementos para a construção de MO
Primeira etapa
Tarefa:
• fazer um inventário sobre o estado atual
Objetivo:
• Determinar as pessoas da empresa envolvidos
pelo operação de Capitalização (tanto como
fonte de expertise como usuários em
potencial)
• Determinar as fontes documentárias e as bases
de dados disponíveis na empresa.
Elementos para a construção de MO
Possíveis fontes . . .
Exemplos:
• 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 ...
Elementos para a construção de MO
Antecipando o registro formal dos . . .
 O estudo do ambiente de trabalho dos
futuros usuários permite escolher o modo
de materialização da memória
 Esta memória pode compor-se de
documentos em papel ou eletrônicos
tornando explícitos os conhecimentos dos
especialista da empresa
Elementos para a construção de MO
Formas de implementação . . .
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
Elementos para a construção de MO
Tecnologia de implementação . . .
Objetivo
• Fazer um sobrevôo as tecnologias: banco de
dados relacional, armazém de dados (d/w),
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.
Tecnologia de Implementação
Evolução histórica . . .
 1as.
Edições de BD não separavam:
• processamento de transações (online)
• processamento em lote
• processamento analítico
 Edições
subsequentes promoveram a separação :
• para atender necessidades operacionais
• para atender necessidades informacionais ou
analíticas
 Evolução
= PC + LQ Geração.
Tecnologia de Implementação
Separação em operacional e informacional
Razões da divisão:
• 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.
Tecnologia de Implementação
Processamento informacional
Definição: Processamento informacional
• É o processamento que atende às necessidades
dos gerentes durante o processo de tomada de
decisões
Particularidade:
• O processamento analítico examina amplos
espectros de dados para detectar tendências
• A execução de um processamento analítico
requer acesso a muitos registros.
Tecnologia de Implementação
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
Tecnologia de Implementação
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
Tecnologia de Implementação
Evolução tecnológica
MIS/SAD
Processamento
de transações
1980
PCs, tecnologia L4G
O paradigma de
um único BD para
todos os fins
Tecnologia de Implementação
Evolução tecnológica - Programas de extração
Definição: Programas de extração
• São 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.
Tecnologia de Implementação
Evolução tecnológica - Programas 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
Tecnologia de Implementação
Evolução tecnológica -Arquitetura D.E.
Ambiente de sistemas herdados
Tecnologia de Implementação
Evolução tecnológica -Arquitetura D.E.
Problemas da arquitetura D. E .
• credibilidade dos dados
• produtividade
• impossibilidade de transformar dados em
informação
Tecnologia de Implementação
Evolução tecnológica -Arquitetura D.E.
Dept. A
10%
SGBD
A
Business
Week
Wall
Street
Journal
SGBD
B
SGBD
C
Diferencial algorítmico:
A) domingo à tarde + contas antigas
B) 4a feria à tarde + contas grandes
Nenhuma fonte de dados comum para começar
Dept. B
-20%
Tecnologia de Implementação
Evolução tecnológica -Arquitetura D.E.
Problemas de produtividade
Caso 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 ?
Tecnologia de Implementação
Evolução tecnológica -Arquitetura D.E.
Continuação caso 1:
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.
Tecnologia de Implementação
Arquitetura D.E 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.
Tecnologia de Implementação
Arquitetura D.E. - Tempo para geração dos . . .
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.
Tecnologia de Implementação
Evolução tecnológica - do à informação
“. . . já é difícil descobrir quais dados estão
associados a uma conta, logo tentar 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 ;
• decifrar uma informação não é uma tarefa 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
Não
Tabela id_pessoa nome contato
Satisfaz
Pessoa
Brigadeiro Franco
1FN
233-3932
[email protected]
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
Não Satisfaz 2FN
chaveprimária.
primária: id_pessoa, conta

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
Tabela Pessoa
id_pessoa nome endereço id_empresa
Tabela Empresa
id_empresa nome_da_empresa endereço
Chave
estrangeira
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
Banco de Dados
Modelo Dimensional
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 :
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 para 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 semiautomá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 partir 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.