Artefatos da Semitica Organizacional na

Elicitao de Requisitos para Solues de Data

Warehouse

Joo Marcos Bonadio de Faria

Trabalho Final de Mestrado Profissional



iii
Instituto de Computao
Universidade Estadual de Campinas








Artefatos da Semitica Organizacional na
Elicitao de Requisitos para Solues de Data
Warehouse




Joo Marcos Bonadio de Faria
Fevereiro de 2006






Banca Examinadora:


Profa. Dra. Maria Ceclia Calani Baranauskas (Orientadora)
Instituto de Computao, UNICAMP

Profa. Dra. Eliane Martins
Instituto de Computao, UNICAMP

Prof. Dr. Rodrigo Bonacin
Centro de Pesquisas Renato Archer, CENPRA.


iv




















Faria, Joo Marcos Bonadio de
F225a Artefatos da semitica organizacional na elicitao de
requisitos para solues de data warehouse / -- Campinas, [S.P. :s.n.],
2006.
Orientador : Maria Ceclia Calani Baranauskas
Trabalho final (mestrado profissional) - Universidade Estadual de
Campinas, Instituto de Computao.
1. Semitica. 2. Engenharia de software. Data warehousing. I.
Baranauskas, Maria Ceclia. II. Universidade Estadual de Campinas.
Instituto de Computao. III. Ttulo.

v

Artefatos da Semitica Organizacional na Elicitao de
Requisitos para Solues de Data Warehouse







Este exemplar corresponde redao final
do Trabalho Final devidamente corrigida e
defendida por Joo Marcos Bonadio de Faria e
aprovada pela Banca Examinadora.





Campinas, Fevereiro de 2006.





Profa. Dra. Maria Ceclia Calani Baranauskas
(Orientadora)






Trabalho Final apresentado ao Instituto de
Computao, UNICAMP, como requisito
parcial para a obteno do ttulo de
Mestre em Computao na rea de
Engenharia de Computao
vii





































Joo Marcos Bonadio de Faria, 2006
Todos os direitos reservados
xi





































Contos de Fadas so mais que
verdade: no porque nos dizem que
drages existem, mas porque eles
nos ensinam que drages podem
ser vencidos.

G.K. Chesterton.
xiii
Resumo

Este trabalho tem como objetivo propor o uso das ferramentas e mtodos da
Semitica Organizacional para a elicitao de requisitos de uma soluo de Data
Warehouse. As principais motivaes para o trabalho advm da falta de uma metodologia
de elicitao de requisitos que apoiem de maneira efetiva todas as necessidades particulares
para a elicitao de requisitos de Data Warehouse. Os problemas apontados pela literatura
so explorados, bem como algumas propostas de metodologia apresentadas recentemente.
Em particular, discutimos alguns dos aspectos que demonstram a necessidade de uma
tcnica de elicitao de requisitos desenvolvida especialmente para esse tipo de aplicao.

Explicamos nesse trabalho o que um Data Warehouse e suas diferentes tecnologias,
introduzimos o conceito de Semitica Organizacional e apresentamos as ferramentas que
so utilizadas durante o estudo de caso. Esse estudo de caso descrito e os resultados
apresentados, fornecendo a base para a proposta de uma maneira de uso das ferramentas da
Semitica Organizacional para a elicitao de requisitos. Ao final do trabalho pudemos ver
que as ferramentas foram eficazes em seu propsito, inclusive com resultados alm dos
esperados, e propostas de trabalhos futuros so feitas.

xv
Abstract

This work has the main goal of proposing the use of the tools and methods of
Organizational Semiotics to elicit user requirements to a Data Warehouse solution. The
main motivations for this work come from the lack of a proper methodology to elicit
requirements that fully addres the particular needs for a Data Warehouse solution. The
issues discussed by previous works are analyzed; as well as some newly presented
methodologies are discussed. Particularly we present some aspects that show the need of a
new technique to elicit requirements tailored for Data Warehouse solutions.

We explain what is a Data Warehouse and its technologies, introduce the concept of
Organizational Semiotics and present the tools used during the case study. The Case Study
is described and the results shown giving the base to propose a method to use the Semiotic
techniques to elicit the requirements for a Data Warehouse solution. With the results of the
work we are able to understand that the Semiotic tools are quite efficient and the results
were above expectation and finally some considerations for future works are made.
xvii
Agradecimentos


Professora Maria Ceclia Calani Baranauskas pela orientao e apoio na realizao
deste trabalho.

Ao Professor Pedro Rezende pelo apoio e motivao durante a graduao e mestrado.

Ao colega Carlos Alberto pela ajuda e apoio.

Ao Governo do Estado de So Paulo pela possibilidade do estudo de caso.

minha famlia, em especial minha me e minha esposa, pela pacincia e
compreenso durante a confecco deste trabalho.

todos aqueles que torceram por mim durante essa jornada.
xix
Sumrio

RESUMO........................................................................................................................................................................ XIII
ABSTRACT......................................................................................................................................................................XV
AGRADECIMENTOS..................................................................................................................................................XVII
SUMRIO...................................................................................................................................................................... XIX
LISTA DE FIGURAS.................................................................................................................................................... XXI
LISTA DE TABELAS ................................................................................................................................................ XXIII
CAPTULO 1 ...................................................................................................................................................................... 1
INTRODUO................................................................................................................................................................... 1
CAPTULO 2 ...................................................................................................................................................................... 7
A PROBLEMTICA DA ELICITAO DE REQUISITOS EM SOLUES DE DATA WAREHOUSE............. 7
2.1 CONCEITOS DE DATA WAREHOUSE .......................................................................................................... 7
2.2 DESAFIOS DA ELICITAO DE REQUISITOS PARA DATA WAREHOUSE.................................................... 17
2.3 REFERNCIAS DA LITERATURA............................................................................................................... 24
2.4 CONSIDERAES FINAIS......................................................................................................................... 29
CAPTULO 3 .................................................................................................................................................................... 33
OBJETIVO E METODOLOGIA.......................................................................................................................... 33
CAPTULO 4 .................................................................................................................................................................... 39
SEMITICA ORGANIZACIONAL COMO REFERENCIAL PARA A ELICITAO DE REQUISITOS......... 39
4.1 A SEMITICA.......................................................................................................................................... 39
4.2 A SEMITICA ORGANIZACIONAL............................................................................................................ 43
4.3 O MTODO DE ARTICULAO DE PROBLEMAS (PAM)........................................................................... 50
4.3.1 Anlise de organizao e contexto................................................................................................. 50
4.3.2 Anlise da Morfologia Funcional .................................................................................................. 53
4.3.3 Anlise Colateral ........................................................................................................................... 54
4.4 CONSIDERAES FINAIS......................................................................................................................... 56
CAPTULO 5 .................................................................................................................................................................... 57
BUSCANDO UMA SOLUO PRELIMINAR DE DATA WAREHOUSE: UM ESTUDO DE CASO.................. 57
5.1 PLANEJAMENTO DO USO DAS FERRAMENTAS DA SEMITICA ORGANIZACIONAL. .................................. 57
5.2 DESCREVENDO A ORGANIZAO E O CONTEXTO ................................................................................... 68
5.2.1 A definio da organizao a ser estudada ................................................................................... 68
5.2.2 A DIR I e o seu papel na rea de Sade ........................................................................................ 71
5.3 O ESTUDO DE CASO................................................................................................................................ 74
5.4 ANLISE DOS RESULTADOS E DESENHO DA SOLUO............................................................................. 96
5.5 CONSIDERAES SOBRE O RESULTADO................................................................................................. 106
xx
CAPTULO 6 .................................................................................................................................................................. 111
CONSIDERAES FINAIS E TRABALHOS FUTUROS........................................................................................ 111
REFERNCIAS BIBLIOGRFICAS .......................................................................................................................... 115
ANEXOS.......................................................................................................................................................................... 121

xxi
Lista de Figuras

Figura 1 Cubos de dados de um Data Warehouse............................................................................................................ 9
Figura 2 Esquema simplificado de uma soluo Data Warehouse ( adaptada de Gorla (2003)).................................... 11
Figura 3 Dif. de implementao de tecnologias MOLAP e ROLAP (adaptado de Moreno & Mancuso( 2003)). ......... 13
Figura 4 Exemplo do uso de Data Marts (adaptado de (Paz, Cielo (1999-2000))) ........................................................ 15
Figura 5 Exemplo de um Star Schema (adaptado de Kimball (1998), p. 10)................................................................ 17
Figura 6 Diagrama de Etapas de Projeto de uma Soluo de Data Warehouse (Shanks e ODonnell (ND))................. 25
Figura 7 A interpretao de representamem por interpretantes diferentes ..................................................................... 42
Figura 8 O Framework Semitico (adapatado de Liu (2000, p. 27)) ............................................................................. 47
Figura 9 Camadas da Anlise de Stakeholders .............................................................................................................. 52
Figura 10 Representao da Anlise de Morfologia Funcional ....................................................................................... 54
Figura 11 Ciclo da Anlise Colateral. (Simoni, 2003, adaptado de Liu, 2000)................................................................ 56
Figura 12 Seqncia de Tcnicas sugerida ...................................................................................................................... 59
Figura 13 Representao esquemtica da soluo final ................................................................................................... 60
Figura 14 Diagrama de uso dos resultados das tcnicas empregadas .............................................................................. 61
Figura 15 Aplicaes representadas por tabelas-fato ...................................................................................................... 66
Figura 16 Representao de uma aplicao e suas dimenses......................................................................................... 67
Figura 17 Exemplos de Telas do Sistema SIAP .............................................................................................................. 70
Figura 18 Exemplos de Telas do Sistema SIVISA.......................................................................................................... 70
Figura 19 Resultado da Anlise de Stakeholders............................................................................................................. 81
Figura 20 Sistemas fonte e Camada de ETL.................................................................................................................... 98
Figura 21 A Aplicao elicitada ...................................................................................................................................... 99
Figura 22 A aplicao e suas dimenses........................................................................................................................ 102
Figura 23 As dimenses com chaves primrias e informaes necessrias ................................................................... 104

xxiii
Lista de Tabelas

Tabela 1 Diferenas entre os paradigmas Objetivista e Subjetivista. (adaptada de Liu (2000, p. 25)) .........45
Tabela 2 Resultados do Quadro de Avaliao - Camada de Contribuio ......................................................127
Tabela 3 Resultados do Quadro de Avaliao - Camada de Fonte ..................................................................130
Tabela 4 Resultados do Quadro de Avaliao - Camada de Mercado ............................................................132
Tabela 5 Resultados do Quadro de Avaliao - Camada de Comunidade ......................................................133
Tabela 6 Resultados do Framework Semitico ...............................................................................................134
Tabela 7 Resultados da Anlise Colateral .......................................................................................................135
1
Captulo 1
Introduo

O objetivo desse trabalho descrever e caracterizar os problemas para a elicitao de
requisitos na construo de um Data Warehouse e estudar a viabilidade do uso de tcnicas
de Semitica Organizacional para apoiar a fase de elicitao de requisitos de uma soluo
de Data Warehouse.

Nos ltimos anos houve um claro aumento da necessidade de informao da sociedade
atual. Por meio de televiso, livros, revistas, Internet ou quaisquer outros meios de
comunicao, as pessoas so apresentadas a milhares de informaes ao mesmo tempo, seja
ela requisitada ou no. A maneira como essa informao passada muitas vezes evasiva,
e nem sempre a informao desejada. Por causa desse acmulo de informao, muitos
dados inteis podem se sobrepor a dados teis e dificultar que eles sejam utilizados.

O valor da informao mudou. Ela necessria em tempo real, no momento que ela
requisitada. O ciclo de informao tem se modificado e ficado menor. Notcias correm o
mundo em segundos e tornam-se obsoletas em questo de horas.

Essa volatilidade da informao tambm afeta as empresas. O mercado cada vez mais
competitivo no d margens para manobras mal feitas. As decises tm que ser tomadas
imediatamente baseadas em dados confiveis e atualizadas. Qualquer erro estratgico pode
custar milhes em divisas e materiais. Estratgias de curto, mdio e longo prazo tem de ser
elaboradas e verificadas constantemente. Mudanas de cenrio devem ser esperadas,
verificadas e contornadas da maneira mais eficaz e transparente possvel.

Com base nesse cenrio, o conceito de Data Warehouse comeou a ser desenvolvido. Sua
principal funo criar um repositrio de informaes confiveis, que sirvam de apoio para
a tomada de deciso estratgicas e corporativas nas empresas. A qualidade dessa
2
informao, a maneira como ela armazenada e disponibilizada, as diversas fontes de
dados que carregam os bancos de dados, todos fazem parte do escopo de uma soluo de
Data Warehouse. As implementaes de Data Warehouse, apesar de estarem cada vez mais
comuns, ainda no se apoiam de forma consistente em ferramentas e tcnicas criadas
especificamente para esse tipo de soluo. Esse panorama cria uma situao de risco, ainda
mais levando-se em conta a quantidade de recursos e tempo necessrios para finalizar a
implementao total de um Data Warehouse. A etapa de elicitao de requisitos de um Data
Warehouse ainda muito pouco explorada pela literatura da rea. Isso cria um grande risco
para o sucesso do projeto, pois a percepo de qualidade e a confiana do usurio final vo
determinar como a ferramenta ser utilizada e como o Retorno de Investimento dos fundos
gastos com a implementao ser conseguido ( Giannoccaro, Shanks, Darke (1999)). Se a
ferramenta no puder dispor das informaes requeridas pelos usurios de forma clara, de
fcil acesso e com a qualidade esperada, a implementao do Data Warehouse no ter
atingido seu objetivo.

Durante alguns anos de minha vida profissional, trabalhei em uma consultoria de
informtica de uma grande multinacional alem, em seu escritrio em So Paulo, SP. Essa
consultoria provia servios de implementao, integrao de sistemas e consultoria de
processos de uma grande gama de ferramentas, entre elas sistemas Enterprise Resource
Planning, Customer Relationship Management, sistemas de Gerenciamento Eletrnico de
Documentos , uma srie de pequenos sistemas legados e outras solues e processos de
informtica.

O grupo em que eu trabalhava era conhecido como Suporte ao Desenvolvimento e tinha
como misso ser um primeiro nvel de apoio para os consultores e desenvolvedores da
empresa. Era nossa responsabilidade conhecer novas ferramentas, adquirir experincia com
elas e repassar aos analistas novas tecnologias, ferramentas e processos e ajud-los no uso
desses novos conhecimentos.

3
Entre os anos de 2001 e 2004, estive bastante envolvido em implementaes de ferramentas
da empresa SAP, em especial o SAP R/3, conhecida ferramenta de ERP (Enterprise
Resource Planning) e de toda a sute conhecida como MySap, que continha toda a gama de
ferramentas dessa empresa disponveis. Embora tenha ficado focado nas solues de CRM
(Customer Relationship Management), sabia da existncia de uma equipe que estava
implementando a ferramenta da SAP conhecida como Business Warehouse. Essa
ferramenta, em conjunto com uma outra conhecida como SAP SEM, era uma soluo de
Balance Scorecard, para apoio de decises estratgicas. O BW, como era conhecido, era a
verso da SAP para a tecnologia conhecida como Data Warehouse. Uma soluo de
Balance Scorecard um tipo de ferramenta de apoio a decises estratgicas baseada em
metas e objetivos. Em geral, utiliza uma implementao de Data Warehouse como apoio.

No comeo do projeto a equipe responsvel pelo BW ficou um pouco isolada, sendo que o
meu primeiro contato com a ferramenta foi uma apresentao ministrada pela lder da
equipe. Algum tempo depois, como era normal em todas as implementaes da consultoria,
alguns problemas comearam a aparecer e eu fui escalado para entender o contexto, a
forma de uso da ferramenta e ajudar em eventuais problemas da equipe. Nessa poca
comecei a tomar conhecimento dos principais problemas na rea de Data Warehouse.

Esse perodo da minha vida foi de intensa atividade e aprendizado. Apesar de na poca
estar focado mais nos aspectos tcnicos das ferramentas, as atividades de elicitao de
requisitos e planejamento sempre me chamaram a ateno. Por causa dessas atividades eu
notei a existncia de alguns problemas muito especficos de projetos de desenvolvimento de
solues de Data Warehouse. Entre esses problemas estavam a falta de mtodos e
ferramentas especficos para apoiar o desenvolvimento das solues de Data Warehouse.

Cada empresa de consultoria ou fabricante de software que apresente solues para Data
Warehouses geralmente cai no mesmo problema: elas tentam adequar os requisitos dos
usurios em suas ferramentas e desse modo no garantem que a realidade do usurio ser
espelhada. Do mesmo modo a literatura sobre Data Warehouses no apresenta
4
metodologias novas, apesar de reconhecer a deficincia do uso de mtodos clssicos de
desenvolvimento no mbito de Data Warehouses.

Especificamente no caso da anlise de requisitos h o maior problema encontrado. Como o
Data Warehouse uma ferramenta para o apoio da anlise estratgica de uma empresa,
vrios fatores como, por exemplo, os valores, misso e modos de operao dessa empresa
tm de estar espelhados no Data Warehouse, mas em geral alguns desses fatores so de
difcil explicao por parte dos usurios e muitas vezes h um certo receio dos usurios de
contar a maneira como a anlise estratgica, ponto de extrema importncia nos negcios,
feita e avaliada. Somado a isso, temos a dificuldade de acesso s pessoas de alto escalo das
empresas, geralmente quem mais aproveitaria da soluo de Data Warehouse.

Dessa forma, a idia principal deste trabalho verificar se as ferramentas da Semitica
Organizacional e em especial os mtodos apresentados na MEASUR podem servir como
metodologia e ferramentas de apoio para projetos de solues de Data Warehouse. O uso
especfico da Semitica Organizacional foi sugerido devido a uma srie de caractersticas
dessas ferramentas que coincidiam com o que eu esperava que uma metodologia de apoio
para a construo de Data Warehouse tivesse. Num primeiro momento o que mais me
chamou a ateno foi o Framework Semitico, em especial o sugerido por Liu (2000), pois
seus seis degraus refletiam as etapas de desenvolvimento que eram consideradas
importantes com base na minha experincia pessoal. Alm disso, um conceito da Semitica
Organizacional chamava muito a minha ateno: o de subjetividade. Como podemos falar
de apoio s estratgias se no entendemos as reais intenes de uma empresa, como
podemos representar a linha de raciocnio de um executivo se no sabemos como ele encara
a realidade e de que maneira ela a manipula para chegar aos resultados esperados? Alm
disso, como garantir que as pessoas responsveis por interagir com os desenvolvedores
realmente conheciam o mais importante, entendiam as reais estratgias e objetivos da
corporao?

A principal motivao desse trabalho saiu diretamente dessas dificuldades. Nosso principal
objetivo era estudar as ferramentas da Semitica e determinar se seria possvel a partir delas
5
constituir uma metodologia adequada para a elicitao de requisitos de uma soluo de
Data Warehouse. A fase de elicitao de requisitos de extrema importncia em qualquer
projeto, mas no desenvolvimento de um Data Warehouse ela se torna crtica. Os projetos de
Data Warehouse so longos, caros e geram muita expectativa do usurio. Alm disso, os
requisitos no so claros nem mesmo aos usurios, pois o uso do Data Warehouse nem
sempre segue regras especficas de acesso.

Para atingir o objetivo foi proposto um estudo de caso para o uso das tcnicas da Semitica
Organizacional e verificao do comportamento dos usurios frente a essas tcnicas. Com
esse estudo de caso fomos capazes de definir uma metodologia de uso das ferramentas da
Semitica Organizacional, alm de verificar se a empresa tinha condies para implemetar
uma soluo do porte de um Data Warehouse.

Este trabalho est organizado da seguinte forma:

No Captulo 2 so exploradas as tecnologias de Data Warehouse, descritos
problemas conhecidos para a elicitao de requisitos e o que a literatura da rea
apresenta como solues e problemas;

No Captulo 3 o objetivo desse trabalho apresentado, bem como os fatores de
motivao e a metodologia empregada;

No Captulo 4 introduzida a teoria da Semitica Organizacional;

No Captulo 5 desenvolvido o estudo de caso e a maneira como as tcnicas da
Semitica Organizacional foram empregadas, bem como o desenvolvimento do
modelo de uso dessas ferramentas;

No Captulo 6 esto as consideraes finais e trabalhos futuros.



7
Captulo 2
A Problemtica da Elicitao de Requisitos em
Solues de Data Warehouse
2.1 Conceitos de Data Warehouse
No simples caracterizar o que uma soluo de Data Warehouse ou de sua real utilidade
em uma empresa. Uma simples busca pela literatura far que o leitor mais atento verifique
que h uma grande diferena entre os conceitos e atribuies dessas solues.
O conceito de Data Warehouse vigente indicado na seguinte definio bsica:
Um Data Warehouse um repositrio de informaes integradas, disponveis para
anlises e consultas. Dados e informaes so extrados de fontes heterogneas de onde
elas so geradas. A principal vantagem que se torna muito mais fcil e eficiente rodar
consultas sobre esses dados que sobre os sistemas originais.. Inmon (ND f).

Levando-se em considerao a definio anterior, notamos que a principal finalidade do
Data Warehouse prover um acesso mais direto s informaes. Mas entende-se como
acesso mais direto no apenas a maneira de se chegar aos dados, mas tambm a facilidade
de se reconhecer inter-relaes entre os dados de diversas fontes. A maneira como uma
aplicao de Data Warehouse desenhada pode facilitar em muito a tarefa de analistas de
negcio, gerentes e tcnicos que dependam de informao segura e precisa para as suas
tomadas de deciso.

A qualidade dessas informaes tambm essencial. Tomadas de deciso baseadas em
dados errados ou mal interpretados podem levar a resultados catastrficos para o objetivo
da empresa. A qualidade das informaes relativa a cada organizao e de sua
interpretao dependem as diretrizes dos projetos de Data Warehouse. E porque a qualidade
8
de informao to importante? Porque, antes de tudo, o Data Warehouse um sistema
considerado Data-Driven, ou seja, sua funo principal e motivo de existncia prover
dados consistentes, de boa qualidade e de forma amigvel a um usurio.

A subjetividade do conceito de qualidade de informao em um Data Warehouse pode ser
exemplificada de forma simples. Tomemos como exemplo dois diferentes setores de uma
empresa, que tenham diferentes funes, mas necessitem do mesmo tipo de dado, mas que
faam uso diferenciado desses dados. Digamos que para o Setor A os dados sejam crticos,
e que quando se deseja verific-los tenha-se pouco tempo para se tomar uma deciso. O
Setor B necessita dos mesmos dados, mas digamos que seja apenas um setor de catalogao
e que se os dados demorarem algumas horas para ficarem prontos no causar maior
impacto no seu processo produtivo. O tempo de acesso aos dados pode ser considerado
como um aspecto de qualidade, mas se um analista apenas satisfizer os requisitos do setor
B, para o setor A esses dados, e o seu mtodo de acesso, faltaro com um aspecto muito
importante de qualidade.

Apesar de haver uma grande gama de mtodos de implementao de sistemas de Data
Warehouse, a mais conhecida utilizar-se uma ferramenta do tipo OLAP Server. OLAP
significa OnLine Analytical Processing. A principal caracterstica dessa tecnologia o
armazenamento de dados pr-processados, metaforicamente numa forma de cubo, onde o
cruzamento de parmetros de consulta proporciona o acesso informao de forma rpida e
consistente. Cada face do cubo representa uma dimenso. Essa dimenso pode ser, a grosso
modo, comparada a uma tabela num banco de dados relacional. Obviamente, a figura
geomtrica de um cubo apenas representativa, podendo o banco conter uma infinidade de
dimenses. Os dados armazenados no banco esto posicionados nos pontos de interface
entre as dimenses, ou seja, ao fazer uma consulta, o banco faz uma interseo
perpendicular ao valor desejado de uma dimenso com a interseo de outra dimenso. A
linha ou ponto gerado por essa consulta representa os valores desejados. Caso a mesma
consulta fosse gerada em um banco de dados relacional, uma grande quantidade de tabelas
seria necessria e a consulta deveria fazer acesso a vrias delas, aumentando o tempo de
processamento. Alm disso, para preservar os relacionamentos entre essas dimenses, uma
9
grande quantidade de chaves estrangeiras seria necessria, fazendo com que a redundncia
de dados fosse enorme, o que provocaria um maior custo de processamento e de
armazenagem. Levando-se em considerao que muitas vezes, como j dissemos, um
usurio de um Data Warehouse no sabe exatamente o que est procurando e que a
necessidade de extrapolao de dados desejada poderia no ter sido imaginada durante a
confeco do banco de dados, a consulta desejada pode ser impossvel, por uma simples
falta de relacionamento entre as chaves estrangeiras das tabelas. Sendo assim, uma nova
instruo para a consulta do banco de dados deveria ser gerada, tarefa que necessita de
nveis de acesso ao servidor e conhecimentos tcnicos acima dos encontrados na mdia dos
usurios das empresas.

A Figura 1 representa um cubo de dados de um Data Warehouse.


Figura 1 : Faces de um Cubo de dados de um Data Warehouse

10
A Figura 1 representa um cubo com cinco faces, cada uma delas uma dimenso
demonstrando uma srie de resultados de uma empresa fictcia. As dimenses apresentadas
so tempo, resultado, produto, unidade de venda e oramento. A rea sombreada indica a
interface entre um determinado valor de uma dimenso e a sua correlao com as outras
dimenses. Caso desejemos saber qual foi a margem de lucro da unidade Oeste em janeiro,
basta hachurar esses valores no cubo e os resultados estaro dentro da rea de interseo.
Alm da facilidade em se fazer consultas nos cubos, uma outra vantagem do modelo OLAP
a facilidade com a qual se faz o chamado Drill-Down. O Drill-Down
1
a busca de
informaes mais detalhadas de um determinado cruzamento, fazendo o caminho inverso
das agregaes. Os dados que esto na interseo de dimenses geralmente so valores
agregados, ou seja, a somatria de outros valores que compem o valor final desejado. O
Data Warehouse tem a capacidade de guardar vrios nveis de detalhes. Geralmente s a
agregao final j contm os dados necessrios para a tomada de deciso, mas caso o
usurio que esteja verificando os dados deseje, ele pode navegar pelos valores formadores,
e verificar os dados num nvel de detalhe maior. Por exemplo, um analista de produo
sabe que a unidade Oeste obteve um resultado que mostra uma queda de vendas de
televisores nos ltimos meses. Para esse analista, pode ser necessrio descobrir se a queda
foi geral para todos os modelos ou se foi pontual em um. Navegando pela ferramenta, ele
deve ser capaz de enxergar esses valores formadores e verificar, por exemplo, que um
determinado modelo no tem mais a procura esperada e determinar a retirada do produto do
mercado e substitu-lo por outro, economizando assim recursos de produo e podendo
prever o tempo mdio de vida de seus produtos.

A evoluo das tecnologias OLAP resultou numa srie de outros produtos que passam pelo
mesmo conceito. Podemos exemplificar com sistemas que se utilizam de tecnologias
MOLAP (Multidimensional OLAP) e ROLAP (Relational OLAP).

As ferramentas MOLAP so os OLAPs multidimensionais. Nelas, o prprio banco de
dados, geralmente proprietrio, armazena os dados em estruturas pr-definidas como os

1
O termo Drill-Down utilizado pelos analistas de Data Warehouse e no tem uma traduo direta. O seu
significado remete ao de desdobrar o valor avaliado em seus valores componentes, navegando para
baixo na pirmide de agregao.
11
prprios cubos. Os dados so tratados e carregados periodicamente para os cubos, de modo
a poderem ser acessados pelos usurios. O acesso a esses dados tambm proprietrio e a
modelagem do cubo acontece de forma direta na ferramenta.

As ferramentas ROLAP utilizam recursos de bancos de dados convencionais para simular a
criao dos cubos. Cada dimenso dos cubos convertida num modelo de banco de dados
adequado ao tipo de consulta necessria para os usurios.

Alm das tecnologias MOLAP e ROLAP, h ainda o conceito de HOLAP (Hybrid OLAP),
que resulta em ferramentas hbridas que tentam juntar as vantagens de um MOLAP com as
de um ROLAP.

A Figura 2 exemplifica uma aplicao Data Warehouse simples.


Figura 2 : Esquema simplificado de uma soluo Data Warehouse ( adaptada de Gorla (2003)).

Nesse exemplo, o usurio tem acesso direto ao OLAP Server, que se utiliza da tecnologia
ROLAP para acesso ao Data Warehouse. O Data Warehouse, por sua vez, carregado por
uma base de dados operacional. Pelo fato do Data Warehouse utilizar-se de ROLAP, os
dados estaro armazenados em tabelas relacionais dentro de um banco de dados de
Interface de usurios
Servidor
OLAP
ROLAP
ROLAP
Data
Warehouse
Base de
dados
Operacional
12
mercado. A tecnologia a ser utilizada, seja ela a MOLAP ou a ROLAP, depende da maneira
como o a aplicao ser construda e tambm do que esperado como resultado.

Podemos notar, por meio desse exemplo simples, que um erro comum considerar-se como
o Data Warehouse a ferramenta OLAP, por causa de sua representao de cubo, que na
verdade parte da interface da soluo. O Data Warehouse real o conjunto de dados
agregados que podem ser utilizados para a carga das ferramentas de OLAP. Esses dados
podem estar guardados em bancos relacionais, arquivos ou outra forma de armazenamento
adequada. A importncia nessa questo que as informaes contidas sejam as apropriadas
para as cargas das dimenses e as mais teis para os usurios. Bill Inmon, um dos criadores
do conceito de Data Warehouse, explica o conceito fazendo analogia com um balde de
Legos, em aluso ao popular brinquedo( Inmon, Tenderman, Imhoff (2003)). Os dados no
Data Warehouse so os bloquinhos de Lego ou seja, unidades formadoras que podem ser
utilizados para a construo de virtualmente qualquer coisa. Esses dados, recebidos das
diversas fontes de dados, podem conter informaes histricas, atualizaes de produo e
qualquer outra coisa. Nesse momento, as informaes podem conter qualquer nvel de
agregao, mantendose o nvel de detalhes desejado e as informaes em estado mais
bruto ou j com um tratamento prvio. Depende apenas das necessidades dos usurios e
da soluo como um todo para determinar qual a melhor caracterstica de armazenamento e
uso dessas informaes.

A partir de uma soluo OLAP, os dados do Data Warehouse so carregados para a
mesma, podendo ento ser manipuladas pelos usurios ou por uma grande gama de
ferramentas de apoio deciso.

13

Figura 3 : Diferenas de implementao de tecnologias MOLAP e ROLAP (adaptado de
Moreno & Mancuso( 2003)).

A Figura 3 representa duas implementaes tpicas de Data Warehouse, uma utilizando
ferramentas MOLAP e outra utilizando um ROLAP. Podemos verificar, nas duas
implementaes, as informaes vindo de outros sistemas, como Enterprise Resource
Plannings , ferramentas de Customer Relationship Management e outros sistemas legados.
Para a busca de dados desses sistemas de carga no Data Warehouse, utiliza-se de
ferramentas diversas na fase conhecida como Extrao Transformao e Carga ( Load)
(ETL). Essa fase uma das mais crticas para o Data Warehouse, pois a conexo do mesmo
com os sistemas fonte implica em quais dados sero trazidos, quais os principais
refinamentos que sero feitos nessas informaes e como essa informao ser
disponibilizada.

A fase de extrao implica no conhecimento de protocolos capazes de comunicar
com todos os sistemas que serviro como fonte. Como podemos imaginar, a quantidade de
tecnologias envolvidas muito grande. Podemos ter sistemas que utilizam de banco de
dados para guardar as informaes, podemos ter sistemas baseados em arquivos texto, e
uma infinidade de outros formatos. Alm disso, geralmente as informaes esto em
servidores diferentes, com plataformas de tecnologias diferentes, como servidores com
Sistema
legado
Sistema
legado
Sistema
legado
Sistema
legado
ETL
ETL
Data
Warehouse
Data
Warehouse
integrao
Cubos
MOLAP
Ferramenta
OLAP
Ferramenta
Query
Ambiente
Ferramenta
Query
Ferramenta
ROLAP
14
sistemas operacionais baseados em UNIX ou Windows, podemos ter velhos sistemas
baseados em Main Frames e, o que costuma ser mais problemtico, podemos ter pequenos
sistemas departamentais desenvolvidos especificamente para um pequeno grupo de
usurios, pequenos programas que rodam em base local e no raramente baseados em
planilhas eletrnicas. Como podemos ver, uma tarefa rdua do ponto de vista de
integrao de sistemas. As tecnologias para integrao de sistemas tm evoludo muito,
como por exemplo, o uso do XML, e com isso essa tarefa tm sido facilitada. O ETL
funciona como um tipo de middleware, tratando com os seus conectores as diferenas de
tecnologia e disponibilizando a informao extrada em uma base homognea.

A fase de transformao acontece por problemas similares aos da fase de extrao.
Como as tecnologias e sistemas diferem, muitas das informaes relacionadas podem ser
guardadas de formas e maneiras diferentes e podem, muitas vezes, nem utilizar as mesmas
representaes. Por exemplo, podemos supor que mesmo para informaes simples, como o
gnero de um cliente, pode estar guardado de diversas maneiras, desde o prosaico M para
gnero masculino e F para o gnero feminino at um sistema de codificao mais
complexo, como utilizado no R/3, ferramenta de ERP da empresa alem SAP. Desse
modo, a camada de ETL deve homogeneizar as informaes de modo que tradues no
sejam mais necessrias (Inmon (ND b)). Obviamente esse trabalho depende de um estudo
prvio do que ser trazido dos sistemas fontes e o entendimento das estruturas de dados dos
mesmos.

Por fim, o ETL faz a carga dos dados no Data Warehouse. Essa fase responsvel
pela disponibilizao final dos dados para uso direto ou para uso em uma ferramenta
OnLine Transactional Processing, ou seja, ferramentas de uso de transaes em tempo real.

Na Figura 3 podemos ver a diferena de comportamento entre a soluo que usa o
MOLAP e a que usa o ROLAP. Na soluo MOLAP, a carga de dados feita diretamente
no Data Warehouse e nos cubos da ferramenta OLAP, de forma paralela. A integrao entre
essas dados depende de mais uma camada de processos. Essa estrutura faz com que a
interface do OLAP e as ferramentas de Queries tenham que utilizar fontes diferentes. J a
15
soluo ROLAP cria um ambiente relacional que permite que as tanto as interfaces ROLAP
quanto ferramentas de Queries acessem o mesmo ponto.

Uma caracterstica interessante apresentada pelas solues de Data Warehouse o
uso dos Data Marts. Um Data Mart um subconjunto do Data Warehouse, que atende aos
requisitos especficos de uma poro dos usurios ( Inmom ( ND d)). Pensando no Data
Warehouse como um repositrio de dados de toda uma organizao, um Data Mart seria
uma construo para manter os dados que seriam mais teis a um determinado nicho da
empresa sem muita importncia para os outros, como por exemplo o departamento
financeiro. Essa diviso em Data Marts pode ter vrias implicaes e benefcios como, por
exemplo, facilidade de definio das polticas de segurana, mais rapidez de navegao
pelo usurio final e uso de informaes mais refinadas dentro de contexto especfico.



Figura 4 : Exemplo do uso de Data Marts (adaptado de (Paz, Cielo (1999-2000)))

As solues de Data Warehouse tm como principal aplicao servir de base para sistemas
de apoio a deciso. Os maiores interessados desse tipo de soluo so grandes empresas
que necessitam estudar e analisar grandes quantidades de informao a fim de traar
objetivos estratgicos e projees futuras para os seus negcios. A maneira como o Data
Warehouse desenvolvido e quais as informaes que ele deve conter dependem do tipo de
negcio da empresa e da maneira como a organizao trabalha seus dados e os transforma
em projees e objetivos.

16
Segundo Kimball (1998) uma empresa pode se beneficiar de um Data Warehouse para
responder a uma srie de questes sobre o negcio que uma ferramenta do tipo transacional
no pode responder. Essas questes geralmente aparecem conforme a corporao entende
que se a sua estratgia corporativa for bem apoiada por informaes relevantes essa
estratgia pode realmente alavancar os resultados da empresa. Mas a quantidade de
informao existente na empresa dificulta um filtro razovel dessas informaes,
atrapalhando os analistas e por vezes escondendo as reais causas de um problema ou um
fator de risco a ser considerado.

Desse modo, Kimball(1998) especifica seis objetivos principais de um Data Warehouse:

1. Fornecer acesso a dados corporativos ou organizacionais;
2. Manter os dados consistentes e confiveis, segundo critrios da empresa;
3. Separar e combinar os dados de forma a facilitar qualquer viso possvel do
negcio;
4. Fornecer meios para consultar, analisar e apresentar informaes;
5. Garantir a publicao de dados confiveis;
6. Garantir qualidade de dados a fim de apoiar uma reengenharia de negcios.
Assim, podemos dizer que uma empresa que queira investir em uma soluo de Data
Warehouse est visando um melhor apoio de negcios baseado em informaes tratadas e
confiveis. Para tanto, essa empresa deve ter um bom grau de maturidade tecnolgica e de
processos.
Para este trabalho, utilizaremos a representao tradicional de um Data Warehouse
dimensional. O modelo dimensional de um Data Warehouse pode ser representado por
meio do diagrama conhecido como Star Schema. Esse diagrama contm uma tabela
principal, conhecida como tabela-fato, que contm todos os dados representativos da
aplicao. Essa tabela-fato est associada com uma srie de tabelas menores que
17
representam as dimenses do cubo de um Data Warehouse. A figura 5 exemplifica uma
aplicao simples, com sua tabela-fato e suas dimenses.

Figura 5 : Exemplo de um Star Schema (adaptado de Kimball (1998), p. 10)
2.2 Desafios da Elicitao de Requisitos para Data Warehouse
Uma soluo baseada em um Data Warehouse difere de um sistema computacional padro
por uma srie de fatores ligados diretamente sua funo e constituio. Um Data
Warehouse contm informaes transformadas e tratadas de uma empresa buscando melhor
visibilidade de informaes e a possibilidade de se tratar desses dados de maneira mais
rpida e verstil.
Shanks e ODonnell (ND) descrevem o principal problema com a elicitao de requisitos
de um Data Warehouse da seguinte forma:

Anlise de requisitos para um Data Warehouse problemtico porque usurios
executivos so incapazes de articular precisamente suas necessidades de informao. Alm
disso, o uso dos sistemas que disponibilizam os dados do Data Warehouse vo auxiliar o
aprendizado do cliente e engatilhar a identificao de novos requisitos. O foco da
Tempo
Loja
Produto
Vendas
Chave_tempo
Chave_produto
Chave_loja
Vendas_em_reais
Unidades_vendidas
Custos_em_reais
Chave_tempo
Dia_semana
Ms
Trimestre
Ano
Chave_produto
Descrio
Marca
Categoria
Chave_loja
Nome_loja
Endereo
Tipo_loja
18
elicitao de requisitos deve ser a identificao dos tipos de problemas executivos
precisam resolver e que tipos de deciso eles tomam.

Na viso de Inmom (ND c), as diferenas entre um sistema computacional regular e um
Data Warehouse so as anomalias, e a principal delas que o levantamento de requisitos
de um Data Warehouse extremamente difcil. A principal causa dessa dificuldade que a
audincia para a qual se constri uma soluo de Data Warehouse extremamente diversa,
e desse modo muito difcil de cobrir. Ainda segundo a viso de Inmom, a melhor maneira
de se fazer essa anlise dividir e classificar os grupos de usurios segundo uma
determinada categoria, e atuar de maneira diversa para esses grupos.So eles:

Fazendeiros: so tipicamente gerentes de produtos, analistas financeiros e analistas
de vendas. Esse tipo de usurio geralmente bem organizado e pertence ao grupo
de planejamento de uma corporao. Geralmente, o fazendeiro o tipo mais fcil de
entender e levantar requisitos, pois suas necessidades so claras e bem definidas. O
tipo de relatrio e dados so facilmente especificados, como por exemplo um
analista de vendas que precisa de um relatrio de vendas de produto por localidade e
perodo. Alm disso, suas exigncias raramente mudam.
Outro ponto sobre fazendeiros que eles geralmente j passaram muito tempo
pesquisando dados em fontes esparsas, ento eles compreendem e valorizam
solues de dados agregados e limpos. Pela mesma razo, esses usurios
entendem de tecnologia e seu entendimento da ferramenta muito bom.
O conhecimento do negcio de um fazendeiro tambm maior e, portanto, ele o
tpico key user de uma implementao.

Turistas: Os turistas esto entre os usurios mais crticos de um sistema de Data
Warehouse, porque compreendem altos e mdios gerentes e a diretoria. A aluso
com turistas dada porque eles querem uma viso geral dos dados e verificar a
fundo apenas alguns pontos chave. So como turistas que tm pouco tempo para
verificar uma cidade toda, ento eles fazem um city tour e visitam apenas os pontos
tursticos mais importantes. Como se trata de alta gerncia, a satisfao dos turistas
19
pode causar um impacto muito grande no projeto. Esses usurios dominam uma
perspectiva ampla do negcio, mas no tm conhecimento detalhado de todas as
reas. Eles necessitam de informaes bsicas sobre a sade das reas e se esto
satisfeitos com os indicadores de uma rea passam para outra, sem verificar a fundo
os dados da anterior. Desse modo, percebe-se que os turistas precisam ter a
informao que querem de maneira clara, de fcil acesso e com um grau de
transformao bastante elevado.
Um outro ponto importante que os turistas no so operadores de computador
experientes, apenas usurios padro. Desse modo, as interfaces e a maneira de
disponibilizao de dados deve ser feita de maneira a facilitar sua navegao.
Historicamente, o grupo de usurios que mais d trabalho para o suporte.

Exploradores: os exploradores so os usurios mais difceis de contemplar.
Geralmente so analistas estratgicos ou de marketing. O modo de encarar o
negcio deles diferente da maioria dos usurios. As suas consultas so
randmicas, tentando discernir um padro escondido nos dados de modo a achar
uma correlao que possa dar alguma vantagem estratgica empresa. No
raramente eles esto errados, mas quando acertam podem elevar em muito as
margens de lucro da empresa. Para isso, uma soluo que atenda a exploradores
deve ser capaz de proporcionar certo nvel de detalhes, informao histria e
capacidade de correlao de fatos.

Mineradores: a aluso a mineradores vem do fato que esses tipos de usurios
escavam as montanhas de dados em busca de raras pepitas de ouro, ou seja,
informao preciosa. Eles analisam esses dados para verificar correlaes e
tendncias. Esses profissionais so representados por profissionais de logstica,
estatsticos e comerciantes. Suas buscas se baseiam em grandes quantidades de
dados detalhados e dados histricos. E o que eles buscam? Geralmente correlaes
que possam mostrar hbitos de consumo de uma determinada faixa de populao,
padres que podem indicar um tipo de fraude. Essa massa de dados de pesquisa
deve ser altamente confivel e a sua manipulao deve ser fcil. A principal
20
diferena entre os mineradores e os exploradores que os mineradores utilizam
mtodos formais e matemticos para fazer as suas buscas, enquanto os exploradores
no tm um mtodo sistemtico.

Operadores: Os operadores so os usurios mais comuns de uma ferramenta de Data
Warehouse. So pessoas que necessitam gerar relatrios e consultas padro, para
conseguir detalhes. A grande vantagem de uma ferramenta de Data Warehouse para
os operadores que a informao de vrios sistemas est contida nele, e assim ele
no precisa fazer uma juno de vrios relatrios, geralmente em uma planilha
eletrnica. As principais necessidades de operadores so dados atuais, bons tempos
de resposta, interface simples. Os requisitos desses usurios so fceis de levantar,
porque a sua maneira de uso previsvel e a necessidade de dados histricos
mnima.

Os dois grupos antagnicos mais representativos dessa classificao so os fazendeiros e
os exploradores. Os fazendeiros apenas colhem os mesmos tipos de dados e fazem as
mesmas tarefas, os exploradores reviram os dados em busca de algo interessante, como
uma nova tendncia de moda ou crescimento das vendas de um determinado produto em
uma regio especfica. A pior conseqncia disso que o sistema de Data Warehouse teria
que espelhar as necessidades de dois grupos distintos como esses. Alm disso, a maneira de
se elicitar os requisitos desses grupos seria diferente porque, enquanto os fazendeiros
sempre cumprem as mesmas tarefas e esto interessados nos mesmos tipos de dados, os
exploradores no tem idia do que querem ao iniciar uma anlise, ou seja, no h um
processo definido para seguir. Para Inmom, para os fazendeiros bastam algumas entrevistas
e a aplicao de tcnicas tradicionais para elicitar os requisitos, mas como podemos
entender o que um explorador quer? Como podemos representar em um sistema
computacional a maneira peculiar como ele trabalha e, o pior, como podemos garantir que
essas necessidades esto bem entendidas. A soluo para Inmon, comear a construo do
Data Warehouse e ir mostrando o resultado para o explorador, incluindo no modelo de
dados as necessidades que forem sendo expressas por ele. Obviamente esse tipo de
abordagem aumentaria o tempo de desenvolvimento, alm de possivelmente forar muito
21
retrabalho da equipe de desenvolvimento. H ainda o risco das necessidades dos
exploradores acabarem anulando as dos fazendeiros, tornando o sistema intil para esse
ltimo grupo. Esses problemas no escaparam de Inmon (ND e), que descreve a maneira
como vrios departamentos diferentes de uma empresa descreveriam seu processo como
seis homens cegos descrevendo um elefante. Cada um deles seria capaz de apenas dar
detalhes das partes com as quais faria contato e essas dificuldades relacionadas ao tamanho
do processo e a quantidade de pessoas e departamentos diferentes a cobrir seriam um
grande obstculo fase de elicitao de requisitos.

Bruckner, List e Schiefer(2001) concordam com essa dificuldade vista por Inmom e
tambm apontam como um grande problema da elicitao de requisitos as diferentes
unidades organizacionais que precisam estar contempladas em uma soluo de Data
Warehouse. Tambm indicam um outro fator bastante preocupante: eles lembram que,
durante a etapa de elicitao de requisitos, os responsveis pelo levantamento escrevem a
sua viso do que foi passado pelos usurios, mas os tcnicos que iro construir a soluo
querem um modelo bem definido para seguir e atualmente no h um padro para esse
modelo. Os tcnicos acham a descrio muito informal e acabam fazendo o Data
Warehouse com base em suas prprias experincias e tentando fechar os pontos obscuros
dos requisitos tendo por base seu prprio entendimento do determinado tipo de negcio. Ao
final do processo, os usurios no entendem o que est representado, por acharem tcnico
demais e, com isso corre-se o risco de que todo o projeto falhe. Entretanto, como no h,
aparentemente, uma soluo, tcnicos e usurios simplesmente seguem em frente. Bruckner
ainda faz mais uma assertiva bastante interessante, de que esse tipo de modo de trabalho
no pode funcionar pelo simples motivo de que usurios e analistas no falam a mesma
lingua. Pode parecer bvio, mas esse tipo de constatao no geralmente levado em
conta quando se analisa os fatores de risco de um projeto. Na verdade, analisando-se a
literatura sobre a construo de Data Warehouses, como o caso dos livros de Kimball,
geralmente o caso tratado com um modelo terico preconcebido acerca do problema.
Como pode ser visto na maioria dos livros de construo de Data Warehouse, h captulos
que indicam o que procurar em determinados tipos de indstria, e ao seguir esses livros o
analista apenas se preocupa com quais os dados a empresa tem que levam ao seu modelo
22
prvio, ignorando as necessidades reais e as caractersticas prprias da entidade para a qual
est se fazendo a soluo.
Esses dois problemas so os que mais se sobressaem na literatura sobre a elicitao de
requisitos de Data Warehouses. Podemos ainda acrescentar o problema causado pela falta
de entendimento do que uma ferramenta de Data Warehouse pelos usurios, e do
entendimento de quais dados realmente devem constar na soluo. Isso porque no so
todos os dados da empresa que devem ir ao Data Warehouse e sim os que devem sofrer
algum retrabalho para facilitar a anlise e dar apoio ao processo de tomadas de deciso da
empresa ( Inmom (ND a)) . Informaes transacionais e de cunho operacional no devem
ser migradas ao Data Warehouse, e sim visualizadas nos sistemas transacionais da empresa.
No raro ao fazer o processo de levantamento de requisitos para uma soluo de apoio
deciso ser colocado como necessidade pelos usurios algum processo como o
acompanhamento atual dos estoques da empresa. Isso no do escopo de Data Warehouse
e isso deve ser bem esclarecido para o usurio.

Outro ponto importante que os usurios de uma soluo Data Warehouse nem sempre so
pessoas de fcil acesso. Presidentes, gerentes e diretores no tem tempo a perder com
entrevistas, respostas a formulrios e outras prticas normais de elicitao de requisitos e
delegam a responsabilidade de definio para outras pessoas, que nem sempre entendem as
reais necessidades da alta cpula de uma empresa. Mesmo essas pessoas, como foi
colocado por Shanks e ODonnell (ND), no sabem exatamente o que querem. Elas sabem
que tem uma enorme quantidade de informaes em suas empresas e no sabem qual a
melhor maneira de utiliz-la. Em alguns projetos de Data Warehouse que participei era
comum os key users quererem superpopular as bases do Data Warehouse, trazendo toda a
informao disponvel dos sistemas legados, ou simplesmente resolver que o melhor ter
uma cpia de relatrios j existente na ferramenta. Obviamente nenhuma das solues
satisfatria, porque impactam diretamente na qualidade da informao que est sendo
trazida e na usabilidade da ferramenta de Data Warehouse.

23
Por outro lado, o analista deve se eximir de tentar entender mais do negcio do cliente do
que o prprio cliente. Durante uma apresentao de um analista sobre um projeto de Data
Warehouse, foi apresentada a questo do exagero de dados que um usurio queria no seu
banco. Uma das informaes exemplificadas era que o usurio gostaria de ter correlaes
com o nmero de acidentes de trabalho na empresa. O analista achou que no seria til, j
que se tratava de uma soluo para a tomada de decises estratgicas, ter um indicador que
fizesse correlao com o nmero de acidentes de trabalho. Analisando o caso, verificamos
que h necessidade de cuidado com certas idias pr-concebidas quando vamos ajudar um
usurio a determinar as suas necessidades. Talvez para uma indstria metalrgica o ndice
de acidentes de trabalho no seja relevante, mas e no caso de uma indstria alimentcia,
onde um acidente de trabalho, alm da produo parada, pode significar a contaminao e
perda da matria prima na linha de produo? Talvez o impacto para o negcio seja
bastante grande. A funo do analista deve ser entender o problema do cliente, verificar sua
forma de trabalho e desenhar a soluo de modo a auxiliar o cliente utilizar os dados
disponveis.

consenso nos artigos existentes sobre Data Warehouse que as tcnicas tradicionais de
elicitao de requisitos no servem para esse tipo de soluo, sendo as ferramentas mais
empregadas checklists e questionrios como os sugeridos por Kimball(2001). Apesar disso,
apenas a partir do ano 2000 comearam a aparecer artigos relacionados a esse tema. Mesmo
assim, a maioria dos mtodos sugeridos apenas cuida do ciclo de vida do projeto de Data
Warehouse, e no indicam nenhuma ferramenta para apoiar nesse processo. Mesmo as
poucas excees no encontram muito respaldo e so criticados na maioria dos fruns sobre
o assunto. Mas o que ento se usa atualmente para a elicitao dos requisitos de Data
Warehouse? Segundo Inmom, o mtodo mais utilizado ainda a anlise dimensional, do
qual ele o maior defensor, mas como dito mais acima at mesmo ele reconhece as
fraquezas desse mtodo.
24

2.3 Referncias da Literatura
Muitos autores tm exposto suas opinies acerca do desenvolvimento de solues de Data
Warehouse, entre eles os dois de maior expresso no mundo das ferramentas de apoio
tomada de deciso(Decision Support Systems), Bill Inmom e Ralph Kimball. Outros
autores, como Price e Shanks (2004) tm tambm dado a sua contribuio, inclusive usando
alguns dos preceitos da semitica. Apesar do tempo em que se tem trabalhado algumas
questes, a anlise de requisitos de um sistema de DSS tem sido um assunto pouco
explorado, com poucas metodologias e sugestes. Grande parte da literatura tcnica segue a
linha de receitas prontas, e geralmente as tcnicas clssicas de engenharia de software so
empregadas, mas sem um ajuste necessrio para cobrir a peculiaridades dos sistemas de
Data Warehouse.
Em seu livro de 1998, Data Warehouse Toolkit, Ralph Kimball versa uma srie de
instrues e maneiras de se construir um Data Warehouse para os mais diversos tipos de
indstrias da atualidade. Segundo suas prprias palavras um conjunto de ferramentas e
tcnicas de projeto que, quando aplicadas s necessidades especficas do usurio e do
banco de dados, permitir que planejem e construam um Data Warehouse de nvel
empresarial.Entre os objetivos descritos nesse livro, est a criao de um conjunto
apropriado de requisitos para o Data Warehouse de sua aplicao. Esse livro baseado em
estudos de caso fictcios, que explicam por exemplos as necessidades da implementao de
um Data Warehouse. A primeira verificao que se faz que existe uma idia pr-
concebida de cada tipo de negcio e o autor determina o que o analista deve buscar e de que
maneira ele deve proceder com os dados. Apenas no captulo 12 da publicao h
referncias s necessidades de entrevistas com usurios, e para isso o autor sugere um
cheklist de perguntas. O pblico alvo dessas entrevistas seria uma mistura de DBA
(administradores de bancos de dados ) e responsveis pelos sistemas legados(as fontes de
dados) e usurios finais. Cada checklist est dividido em funo da rea da empresa e desse
modo podemos ver que quem conduz as entrevistas o analista. Tendo por base a sua viso
dos processos, pr-concebida pela literatura tcnica, o analista provavelmente ir direcionar
25
as respostas dos usurios e muitos problemas e necessidades ficaro sem ser conhecidos.
Podemos dizer que grande parte da literatura tcnica sobre Data Warehouses segue os
mesmos preceitos.
Shanks e ODonnel (ND) discutem algumas das tcnicas e ciclos implementados at essa
data, e prope o seu prprio ciclo de desenvolvimento. O ciclo de Shanks destaca a
importncia da iterao da anlise de requisitos na contruo de Data Warehouses, bem
como um bom entendimento do modelo de negcios da empresa alvo. Mesmo com essas
definies, Shanks no sugeriu um modelo de apoio para a elicitao de requisitos,
preferindo o uso de tcnicas tradicionais de engenharia de software, entrevistando os
usurios.
Continuando seu trabalho na rea de qualidade de informao e Data Warehouses, Price e
Shanks (2004) propem um framework semitico para avaliar a percepo de qualidade de
dados em um ambiente de Data Warehouse pelos Stakeholders. Esse framework visava
garantir a usabilidade e confiabilidade dos dados inseridos em um Data Warehouse,
forando assim entendimento de cada rea sobre quais dados eles eram responsveis e quais
aes eles deveriam tomar para garantir que esses dados fossem teis para as tomadas de
deciso da corporao.

Figura 6 : Diagrama de Etapas de Projeto de uma Soluo de Data Warehouse (Shanks e
ODonnell (ND))
Desenhar / Reutilizar
Modelo de Dados
Corporativo
Identificar
rea de
Atuao
Anlise de
Requisitos
Identificar Fatos
e Dimenses
Implementar,
Carregar e
Consistir Dados
26
Brucker (2001) props o uso de Use Cases para a elicitao de requisitos de uma soluo de
Data Warehouse. Os principais problemas, segundo ele, seriam a dificuldade de
entendimento entre usurios e analistas, de modo que a comunicao entre eles deveria ser
facilitada por um mtodo de sinais simples que possibilitasse o entendimento mtuo. Com
relao aos trabalhos existentes na rea, ele considera que, apesar do uso de diversos
mtodos utilizados para o levantamento de requisitos de um ambiente de Data Warehouse,
ainda no existia uma ferramenta formal de suporte elicitao de requisitos. Sobre os
trabalhos relacionados rea, ele faz a seguinte crtica:
Inmon(1996) dizia que, como um ambiente de Data Warehouse no direcionado a
requisitos e sim a dados, os requisitos necessrios apareceriam aps o
desenvolvimento do sistema com os dados dos sistemas legados. Isso seria feito
com a transposio do modelo corporativo diretamente para o sistema de Data
Warehouse.
Anahory e Murray(1997) propuseram uma catlogo para conduzir as entrevistas
com usurio, da mesma maneira de Kimball.
Kimball(1998) considerou que o principal passo para a construo de um Data
Warehouse seria a escolha de um modelo de negcios e represent-lo. Segundo
Bruckner, esse mtodo seria o mais utilizado e mais funcional at a data de seus
trabalhos, e assim baseou-se em algumas premissas de Kimball para o seu estudo.
O trabalho de Brucker divide as categorias de requisitos em quatro camadas, os requisitos
de negcios, requiditos de usurios, requisitos detalhados de sistemas e requisitos de
atributos. Para conseguir esses requisitos, ele props o uso de Use Cases em um processo
com cinco passos de refinamento, a fim de conseguir uma boa definio das representaes
de processos de negcios a serem desenvolvidos.
As maiores crticas ao uso de Use Cases para o desenvolvimento de Data Warehouses vm
de especialistas da rea. Segundo a maioria deles, o uso dos Use Cases seria atrapalhado
pelo principal problema de elicitao de requisitos de um Data Warehouse: os usurios no
27
sabem o que querem, os processos no esto bem definidos e no haveria como refinar os
requisitos ao nvel que a metodologia indica ( Moss, Barbusinski, Rehm, Oates (2004)).
Winter e Strauch (2003), colocam que solues de Data Warehouse costumam ter um ciclo
de projeto bastante longo e que nesse perodo os requisitos da soluo podem mudar ou
tornar-se ambguos. Tambm indicam que os requisitos de informao so difceis de
elicitar devido singularidade ou mesmo falta de estrutura dos processos de deciso, a
relutncia dos tomadores de deciso em explicitar os detalhes desse processo de anlise e
tomada de deciso e inconscistncias conceituais dentro dessas grandes corporaes. Em
Winter e Strauch (2004) colocada a necessidade de um mtodo de apoio para a elicitao
de requisitos de grandes projetos, pois consideram que problemas com essa fase do
desenvolvimento da soluo so responsveis pela maior parte dos projetos fracassados.
Alm disso, afirmam que a natureza especial de solues de Data Warehouse necessitam de
uma metodologia de suporte especfica, e que os mtodos de anlise de requisitos atuais
cobrem apenas parcialmente as necessidades da elicitao de requisitos desses sistemas.
Em sua pesquisa, Winter e Strauch (2003,2004) entrevistaram vrios experts no
desenvolvimento de solues de Data Warehouse e derivaram dessas entrevistas o que
esses experts consideravam necessrio que uma metodologia de elicitao de requisitos
contemplasse. Entre esses requisitos esto:
Ser orientada a demanda;
Apresentar um modelo hierrquico e com vrias camadas;
Que cubra o processo completo de: determinar os requisitos de informao dos
usurios, comparar os requisitos com as fontes de informaes existente, avaliar e
homogeneizar os requisitos de informao, estabelecer prioridades sobre os
aspectos no cobertos, formalizar a especificao dos requisitos para as prximas
fases do desenvolvimento.
A metodologia proposta por Winter e Strauch (2003) composta por seis fases, cada uma
cobrindo um aspecto do ciclo de elicitao e formalizao dos requisitos para solues de
Data Warehouse. Cada uma dessas fases composta de outras sub-fases, num total de doze
28
tarefas para a complementao de todo o ciclo. Algumas dessas fases apresentam laos de
iterao, nos pontos considerados chaves para a consistncia para os requisitos levantados.
A proposta da metodologia de Winter e Strauch (2003) foi parcialmente aplicada em
algumas corporaes, com resultados variantes em cada etapa. Em sua prpria anlise da
metodologia, Winter adverte que ainda necessrio que algumas ferramentas de apoio
sejam testadas e desenvolvidas, pois as tcnicas usuais de entrevistas, questionrios e
anlise de tarefas so aplicveis, mas apenas parcialmente.
Paim (2003) apresentou em seu trabalho uma metodologia de acompanhamento de projeto
de Data Warehouse com nfase no aspecto de engenharia de requisitos e acompanhamento
de projeto. proposto um modelo em espiral para a fase de elicitao de requisitos,
contendo quatro fases: Elicitao, Anlise e Negociao, Documentao e Conformidade
dos Requisitos. Para a fase de elicitao de requisitos, quando os usurios iro indicar suas
necessidades aos analistas, so propostas as seguintes tcnicas clssicas: entrevistas,
workshops, prototipao e desenvolvimento de cenrios em Use Cases. H ainda a
preocupao com o que foi chamado de Anlise de Requisitos No-Funcionais, que so
requisitos no ligados diretamente funo de um Data Warehouse, como por exemplo
performance e segurana de dados. Para a elicitao desses requisitos no funcionais foi
proposto um framework chamado de DW-ENF (Data Warehouse Extended NFR
Framework). Esse framework consiste de um checklist com os principais aspectos a ser
dicutidos. Mais uma vez o maior problema desse trabalho a falta de uma ferramenta
especfica para apoiar a fase de elicitao de requisitos. A maior contribuio desse
trabalho uma metodologia de controle de projeto de Data Warehouse, com nfase no
planejamento da engenharia de requisitos.
Dale (2004) descreve um processo de anlise de requisitos em uma grande corporao
utilizando-se os processos de qualidade Six Sigma ( metodologia de qualidade na qual se
pontua o nvel de maturidade de um processo de produo baseado em sua quantidade de
erros de produo. Quanto maior o nmero Sigma, menor a quantidade de erros da
produo) e DMAIC( Define, Measure, Analyse,Improve, Control), um processo adaptado
baseado nessas fases. O ciclo de elicitao baseou-se em entrevistas e verificao as
necessidades dos principais usurios, sem o uso de ferramenta especfica de apoio. Ao final
29
do ciclo de elicitao ele pode inferir que o seu maior problema foi conseguir separar o que
os usurios realmente necessitavam e no o que eles gostariam de ter no sistema. A
necessidade se separar esses requisitos aparece porque a tendncia natural dos usurios
querer todas as informaes possveis em um sistema de Data Warehouse, inclusive as que
devem ser consultadas nos sistemas transacionais normais. Levar todas as informaes da
empresa para o Data Warehouse ir causar queda de desempenho e problemas de tempo de
carga, impossibilitando o uso correto da soluo.
A Semitica tambm foi estudada por Shanks e Corbitt (1999), como ferramenta de apoio
para solues de Dawarehouse, mas no para ajudar na elicitao de requisitos. Shanks
props uma variao do Framework Semitico para garantir o entendimento das
necessidades de qualidade de dados de uma corporao. As concluses desse estudo
remetem a prticas que devem ser tomadas, em grande parte, aps a implementao final do
modelo do Data Warehouse, como por exemplo, a necessidade de auditoria dos dados pelo
departamento responsvel antes de sua publicao final.
Ainda como base referencial, grandes empresas de consultoria propem mtodos prprios
de implementao de solues de Data Warehouse. Esses mtodos, em grande parte, so
decorrentes da experincia dessas consultorias nesse tipo de solues, mas contm como
principais problemas o fato de no terem apoio de ferramentas especficas, utilizando-se em
grande parte tcnicas tradicionais como entrevistas e questionrios e de forarem a
implementao segundo os seus interesses de venda de ferramentas como determinados
tipos de bancos de dados e programas de interfaces com os usurios.
2.4 Consideraes Finais
Resumindo, ento, podemos dizer que as maiores dificuldades encontradas para a anlise de
requisitos de uma soluo de Data Warehouse so:
A necessidade de se espelhar os requisitos de muitos departamentos diversos na
mesma ferramenta. Apesar disso poder ser minimizado com o uso dos Data Marts,
ainda assim todo o processo precisa ser coeso;
30
A falta de entendimento entre os analistas tcnicos e os usurios, dificultando o
entendimento das necessidades uns dos outros;
Falta de entendimento do usurio sobre o que exatamente deve ir ao Data
Warehouse;
Idias pr-concebidas dos analistas, por causa da maneira como so tratados os Data
Warehouses pela literatura tcnica.
Dificuldade dos prprios usurios em entender e expressar o que precisam. Como
colocado por Inmom, muitas vezes um usurio do tipo explorador no tem uma
seqncia lgica de busca, no sabe realmente o que quer, e o prprio uso do Data
Warehouse mostra novos caminhos a trilhar.
Falta de apoio de uma tcnica especfica para a elicitao de requisitos de uma
soluo Data Warehouse;
Enorme variedade de tcnicas e tecnologias de implementao que, dependendo do
uso desejado e do tipo de usurio podem variar de uma soluo baseada numa
ferramenta MOLAP ou apenas num repositrio de banco de dados;
Enorme quantidade de dados, que devem ser filtrados e agregados de forma correta,
a fim de garantir qualidade de informao aos usurios.

Ao estudar os principais problemas existentes com a elicitao de requisitos durante o
estudo de viabilidade e posterior implementao de solues de Data Warehouses e de
ferramentas baseadas no mesmo, notamos que, alm de uma falta de especificao formal
para a elicitao, h tambm falta de uma linguagem formal de descrio da soluo. Dessa
maneira, resolvemos trabalhar seguindo o fluxo de criao de um Data Warehouse,
esperando que o produto final nos fornecesse uma especificao que pudesse ser
compreendida facilmente pela equipe tcnica de implementao. Desse modo, decidimos
que a melhor maneira de especificar a soluo seria criando o mapa das tabelas fato e das
dimenses, que formam os cubos de dados, representadas na forma de Star Schema, modelo
31
de representao de dados amplamente utilizado para o desenho de solues de Data
Warehouse. Com esse modelo das dimenses e dos cubos, qualquer tipo de tecnologia de
implementao escolhida, seja ela atravs de banco de dados relacionais ou de banco de
dados multidimensionais, bem como com qualquer ferramenta existente no mercado,
poderia facilmente ser ajustada e parametrizada para espelhar essa realidade especfica.

Os desafios para a elicitao de requisitos de uma soluo de Data Warehouse so
conhecidos e entendidos, mas podemos dizer que at o momento as pesquisas para resolver
esses problemas esto apenas engatinhando. Ao olharmos com mais ateno os problemas
relatados podemos ver que alguns pontos so parelhos com o que a Semitica
Organizacional e os mtodos e ferramentas desenvolvidos pelo MEASUR tm a oferecer, e
desse modo acreditamos que o uso desse ferramental possa dar algumas respostas ou ao
menos algum direcionamento para essas questes.

33
Captulo 3
Objetivo e Metodologia

A proposta deste trabalho remete s dificuldades encontradas e enfrentadas na prtica de
minha carreira profissional, como apresentado anteriormente Percebi que havia ainda uma
grande dificuldade por parte de analistas e usurio e entender o que realmente se precisava
para uma soluo de Data Warehouse coerente e que aparentemente muito do
desenvolvimento dessas solues eram feitas sem uma fase inicial de anlise de requisitos
apropriada, inclusive com grandes dificuldades de se determinar o real pblico alvo do
sistema.

Como pde ser visto no Captulo 2, as tcnicas tradicionais de levantamento de requisitos
no atendem completamente as necessidades especiais de uma soluo de Data Warehouse,
e ainda no existe uma tcnica comprovadamente eficaz e com um bom apoio de
ferramentas. Desse modo, ao iniciarmos esse trabalho, a principal motivao era tentar
identificar um conjunto de ferramentas que pudesse apoiar de modo eficaz a etapa de
elicitao de requisitos de uma soluo de Data Warehouse. Por causa da afirmao de
quase todos os autores de que alguns dos principais problemas do levantamento de
requisitos era a incapacidade dos usurios de expressar corretamente o que precisavam e a
incapacidade dos tcnicos de entender o modelo de negcio das corporaes, as
ferramentas da Semitica Organizacional, em especial das ferramentas do MEASUR,
aparentemente cobririam essas dificuldades e poderiam servir como uma metodologia
eficaz para o desenvolvimento de solues de Data Warehouse.

As dvidas principais que tive ao trabalhar com uma soluo Data Warehouse esto
espelhadas e explicadas nesse trabalho. Ao iniciar o planejamento desse estudo eu visava
responder algumas perguntas sobre as reais necessidades de um usurio a serem migradas
para uma soluo de Data Warehouse e se possvel definir se o uso das ferramentas da
Semitica poderiam ajudar nessas definies.

34
Como foi discutido no Captulo 2, as referncias literrias sobre a elicitao de requisitos
para um ambiente de Data Warehouse so escassas e nem sempre cobrem todos os aspectos
necessrios. Quase sempre so variaes de modelos clssicos, mas que no cobrem todas
as reais necessidades de um Data Warehouse. Aps verificar esse cenrio, algumas dvidas
foram somando-se s iniciais, formando a seguinte lista de questes:

1. Quem realmente o pblico alvo da soluo de Data Warehouse?
2. Quais as pessoas imprescindveis para a elicitao de requisitos?
3. Quais os reais problemas/intenes da corporao em relao a uma soluo de
Data Warehouse?
4. A empresa possui maturidade suficiente para operar e usufruir de uma ferramenta
to sofisticada e especfica?
5. Qual o perfil dos usurios que iro usar a soluo? Quais os seus modos de trabalho
e operao?
6. A empresa j dispe de todos os dados necessrios para as anlises que deseja?
7. Como fazer as pessoas confortveis o suficiente para quebrar barreiras e
permitirem-se ensinar aos analistas os segredos do seu trabalho?
8. Como garantir que esses analistas realmente entenderam e no apenas interpretaram
os resultados segundo os seus direcionamentos pessoais e de suas empresas de
implementao?
9. A qualidade dos processos atuais boa? Quais processos so os mais problemticos
e deveriam ser ajustados primeiro?

Ao estudarmos as ferramentas da Semitica Organizacional e em especial o MEASUR,
notei que esse mtodo poderia ser promissor na anlise de requisitos de um Data
Warehouse. O Framework Semitico aparentava cobrir todos os grandes aspectos
necessrios para uma soluo de Data Warehouse, incluindo os aspectos tcnicos de
Tecnologia de Informao, os aspectos sintticos que ajudariam na homogeneizao dos
dados dos sistemas fonte e em especial o nvel semntico, que remete necessidade de
entender as intenes de quem usaria uma ferramenta de apoio deciso.

35
Assim sendo, o propsito inicial desse trabalho verificar se as ferramentas de Semitica
Organizacional podem ser utilizadas nas fases iniciais de planejamento do desenvolvimento
de uma soluo de Data Warehouse, isto , se com o apoio dessas ferramentas poderamos
elicitar os requisitos iniciais da soluo, levantar suas principais fontes de dados, seus
principais usurios, em quais processos de deciso a soluo deve ser focada e quais as
falhas nesses processos. Ao final do estudo, o objetivo ter mapeado os processos na forma
de um grfico Star Schema, que daria a viso dos cubos de dados necessrios. Essa
representao baseada no Star Schema livre de plataforma de tecnologia e por isso torna-
se adequada a qualquer anlise dimensional, pois a sua adaptao s plataformas de
tecnologia conhecidas, OLAPs ou ROLAPs, feita de forma rpida e transparente.

O estudo do MEASUR indicou que para o objetivo inicial algumas ferramentas contidas no
mtodo PAM eram as mais indicadas, pois esse mtodo se presta a uma fase do processo de
construo da soluo em que o problema a ser resolvido no est muito claro. Para o
estudo de caso o ideal era buscar uma empresa que tivesse as seguintes caractersticas:

1. Cujo trabalho necessitasse de grande quantidade de informaes;
2. Que tivesse uma estrutura fixa e bem delimitada, com funes e cargos
diferenciados;
3. Que concordasse em dispor de algum tempo para as atividades sugeridas.

Das opes que foram discutidas, a que mais se adequou s necessidades foi a Vigilncia
Sanitria do Estado de So Paulo Diretrio 1 Capital. Alm das caractersticas
requeridas, os contatos iniciais para verificar a possibilidade do trabalho indicavam mais
alguns pontos que poderiam por prova a capacidade das ferramentas da Semitica para a
elicitao de requisitos. Entre essas caractersticas esto:

1. Como se trata da rea de sade, seus termos tcnicos e necessidades seriam
totalmente desconhecidos por mim;
2. Histrico anterior de casos de tentativas de construo de solues diversas sem
sucesso;
36
3. Algum apoio de ferramentas computacionais, que com certeza seriam integradas
soluo;
4. Muitos processos e projetos em andamento, criando um grande fluxo de
informaes.
5. Pessoal pouco familiarizado com sistemas de informao e em especial Data
Warehouses.

Aps as negociaes iniciais e dada a anuncia do Governo do Estado de So Paulo, foi
delimitada a metodologia a ser utilizada para o estudo de caso.

Para garantir a confiana do grupo estudado de que nenhuma informao confidencial
referente ao trabalho da Vigilncia seria disponibilizada, ficou acertado que eles teriam
acesso a todo o material publicado e produzido. Isso necessrio por causa das
informaes contidas em processos de empresas e informaes de interesse sade.
A principal preocupao nesse caso era no influenciar os participantes do estudo de caso e
evitar que eles tentassem adivinhar a resposta esperada, ao invs de discutir seus reais
problemas. Foi definido que o estudo de caso deveria transcorrer da seguinte forma:

1. As atividades seriam realizadas nas dependncias da Vigilncia, e eu levaria o
material de apoio necessrio;
2. Seriam feitas ao todo quatro reunies, uma para cada tcnica sugerida, a saber:
Anlise de Stakeholders, Quadro de Avaliao, Framework Semitico e a Anlise
Colateral;
3. No seria feito um treinamento formal das tcnicas com os usurios e nem sobre o
Data Warehouse. A princpio estaramos levantando seus fluxos de informao e
problemas com seus processos;
4. Para a primeira reunio foi convidado um representante de cada rea, diretores e
assistentes. Caso durante a anlise de stakeholders fosse notada a falta de uma
figura importante, essa pessoa seria convocada nas prximas reunies;
5. As reunies seriam workshops, onde os usurios seriam expostos s tcnicas
sugeridas e os resultados anotados;
37
6. Todas as reunies seriam gravadas e notas seriam tomadas. Alm disso, material de
apoio em forma de cartazes seria utilizado nos workshops. Esses cartazes seriam
transcritos aps cada reunio para a anlise dos dados. As gravaes foram
autorizadas e o gravador sempre ficou visvel.

Em cada reunio a ferramenta a ser utilizada era apresentada e explicada, com o apoio de
literatura e alguns exemplos, como o trabalho de Liu (2000) e Simoni (2003). Alguns
ajustes foram necessrios conforme o estudo de caso transcorria. Por causa das dvidas
encontradas pelo grupo no primeiro workshop, utilizamos parte do segundo para explicar
mais a fundo o que era uma ferramenta de Data Warehouse. Aps o final da segunda
reunio decidimos tambm no mais utilizar o gravador, pois ele claramente trazia
desconforto aos usurios.

O material transcrito seria compilado e analisado e um projeto de uma soluo de Data
Warehouse seria feito, com um alto grau de abstrao. Tambm como resultado um modelo
de uso das ferramentas da Semitica seria produzido, provendo a possibilidade de aplicao
da tcnica em outros cenrios.
39
Captulo 4
Semitica Organizacional como Referencial para a
Elicitao de Requisitos
4.1 A Semitica
A forma como uma pessoa v o mundo est diretamente relacionada a suas prprias
experincias. A sua linguagem falada, a sua maneira de expresso, sua maneira de vestir e o
significado de suas aes esto diretamente relacionadas com o meio em que esse indivduo
cresceu, quais valores e informaes foram-lhe passados por outras pessoas e a sua maneira
pessoal de ver o mundo. Cada interpretao da realidade pode ser considerada nica e
particular.
Cada grupo particular de pessoas tem a sua prpria linguagem, suas grias e cdigos de
condutas. Policiais, professores, mdicos, cada pessoa interage com um determinado grupo
social e adquire parte do comportamento desse determinado grupo, comea a compartilhar
a sua maneira de ver o mundo e absorver novas experincias que podem modificar as suas
prprias, levando a novas concluses e talvez at mesmo a modificaes no modo de viver
e de agir. Essa comunicao, seja falada, escrita, existe atravs de smbolos, utilizados para
passar alguma mensagem para o grupo. Para ser entendido, o smbolo deve ser conhecido e
ter um significado prprio e que faa sentido para a pessoa que recebeu a mensagem.
Apesar de parecer simples, a maneira como os smbolos so utilizados pelas sociedades
extremamente complexa e alvo de estudos h longo tempo. Uma das linhas de estudo
desses fatores a Semitica, ou Semiologia. A palavra Semiologia formada pelos radicais
gregos logia(estudo) e semeon, que quer dizer signo. A principal diferena de uso entre
essas palavras que a primeira, Semitica, refere-se Charles Sanders Pierce(1839-1914),
filsofo estadunidense que acreditava que a semitica era a doutrina formal dos smbolos,
relacionado a uma Lgica Formal. J a Semiologia remete ao linguista suo Ferdinand de
Saussure(1857-1913), que definiu que a semiologia deveria investigar os signos e as leis
que os governam.
40
Vrios outros estudiosos de diversas reas de conhecimento tambm trabalharam com o
conceito semitico, como Roland Barthes(1915-1980) e o romancista Umberto Eco.
Barthes escreveu, em 1964: a semiologia visa conseguir, em qualquer sistema de signos, o
que for sua substncia ou limites; imagens, gestos, sons musicais, objetos e qualquer
associao complexa de todos esses elementos. Isso constitui, se no uma linguagem, ao
menos um sistema de significados. ( Barthes (1964)).
Morris (1970), responsvel pelos primeiros desenvolvimentos da semitica
comportamental, declarou, baseado nos trabalhos de Pierce, que a semitica baseada em
trs fatores, sendo eles:
Semntica: o relacionamento dos signos com o que eles significam;
Sinttica: a relao entre signos, seja formal ou estrutural;
Pragmtica: a relao dos signos para o interpretante.
Mas o que um signo? Qualquer coisa que tenha um significado pode ser considerado um
signo, seja uma imagem, palavra ou smbolo. Segundo Pierce(1931-58), nada um signo
at ser interpretado como um signo. Ou seja, a partir do momento que algum recebe uma
mensagem atravs de algo e interpreta essa mensagem de determinada maneira, o signo se
torna vlido. Com isso, notamos que para haver a existncia do signo necessrio que ele
tenha um significado. Saussure sugeriu um modelo de duas partes para a representao do
signo, sendo que :
Signifian
2
t: a forma do sinal;
Signifi: o conceito que ele representa.
Vemos ento que a figura do intrprete do signo no pode ser descolada do mesmo, ou seja,
apenas aps um processamento mental o signo pode ser relacionado ao seu significado.

2
Os termos foram mantidos em sua forma na lingua francesa para identific-los como definies de Saussure
em contraponto s definies de Pierce, da vertente anglo-sax.
41
Na mesma poca em que Sausure fazia sua interpretao com o modelo de duas partes,
Pierce apresentou seu prprio modelo, contendo trs diferentes entidades:
Representamem: a forma que o signo tem, no necessariamente material;
Interpretante: no um intrprete, mas a quem o signo leva algum sentido;
Referente: a o que o signo se refere.
Assim, segundo Pierce (1931-1958), um signo, na forma de um representamen, algo que
significa algo para algum em respeito ou relao a algo. Ou seja, ao ver um signo
(representamem), um intrprete usuar de seus conhecimentos prvios e experincias para
evocar um sentido, que ir remeter ao referente. Essa interrelao Pierciana entre essa
trade chamada de semiose.
O processo pode ser ilustrado da seguinte maneira. Imagine que haja uma caixa com a
palavra CPU escrita nela. Ao ler essa palavra, um interpretante pode imaginar, conforme
seu processo cognitivo, um computador. Desse modo, o representamem, a palavra CPU, foi
remetida a um computador pelo processo mental do intrprete. Por outro lado, se a pessoa
que ler a palavra CPU for versada em eletrnica, provavelmente seu processo cognitivo vai
pensar na Central Processing Unit de um computador, ou seja, apenas um um componente
do mesmo em no no todo. Com isso, o mesmo representamem levou a dois referentes
diferentes, por causa dos respectivos intrpretes.
42

Figura 7 : A interpretao de representamem por interpretantes diferentes

Pierce tambm trabalhou, diferentemente de Saussure, em uma taxonomia para os tipos de
signos, forando uma classificao. Infelizmente, ele era extremamente metdico e
elaborado e sua classificao final de signos tem mais de 59000 subcategorias. As mais
conhecidas so o smbolo, o cone e o ndice:
Smbolo: uma representao em que o representamem no tem caractersticas que
o associem diretamente, por aparncia ou qualquer semelhana, ao referente. O
significado puramente convencionado e precisa ser aprendido ou combinado. o
caso de cdigos, letras, nmeros, entre outros.
cone: uma representao que apresenta caractersticas que ligam o
representamem diretamente ao referente. o caso de um desenho, fotografia,
caricatura, onomatopia ou qualquer forma de representao que no necessite de







Representamen
Intrprete
Intrprete
Interpretante
Interpretante
Objeto no Mundo Real
Objeto no Mundo Real
43
conhecomento prvio para a sua codificao
ndice: uma representao no arbitrria, mas diretamente conectada ao referente
de alguma maneira. como se fosse uma pista ou indicao para o referente.
Podem ser pegadas indicando passagem, fumaa indicando fogo, sintomas de
doenas, etc.
A Semitica tm se espalhado em vrias outras reas de conhecimento, e tem se
aproveitado das novas mdias providas pela tecnologia. A maneira de visualizao e
interpretao mudam com o tempo e com a sociedade, e essa evoluo refletida na sua
maneira de comunicao e em suas necessidades.

4.2 A Semitica Organizacional
A Classificao corrente de Semitica Organizacional foi dada em um workshop que
envolveu vrios estudiosos de vrias reas de aplicao da semitica (OSW 1995). Ela pode
ser definida como: o estudo das organizaes utilizando-se os conceitos e mtodos da
Semitica. A premissa por trs do uso da Semitica para o estudo de empresas, sejam elas
pblicas ou privadas, que como todo organismo ou organizao cada uma delas tm a sua
maneira prpria de criar, lidar e transformar informaes, utilizando um conjunto de signos
e cdigos prprios. O estudo dessas formas de comunicao pode indicar como o real
comportamento da empresa e quais seus valores e formas de trabalho, em um nvel mais
profundo.
O uso da Semitica no campo de Tecnologia de Informao fica claro quando se analisa
essa premissa inical. A necessidade de entendimento de uma empresa, das suas reais metas
e objetivos, sua cultura e modo de trabalho deve ser espelhado em um sistema de
informao que seja construdo para essa organizao. Um sistema genrico, que no leve
em conta a cultura da empresa e no seja passvel de adequao s necessidades reais da
organizao invariavelmente ser subutilizado e gerar insatisfao para os usurios.
Mesmo solues que servem para determinado propsito, como as ERPs, devem ser
44
adequadas maneira de trabalho do grupo que as utilizar. A Semitica pode ajudar a abrir
um novo panorama sobre uma organizao, facilitando o entendimento do que a entidade
realmente necessita para atingir seus objetivos, respeitando a sua cultura, diretrizes e moral.
As ferramentas e mtodos Semiticos desenvolvidos por Stamper (1993), com base no
trabalho de Pierce, foram geradas a partir de um paradigma subjetivista, antagnico a uma
postura objetiva em voga. A principal diferena entre esses dois paradigmas que a viso
objetivista indica que a realidade nica, sendo que os indivduos inseridos nessa realidade
a constrem com suas experincias e sensaes, mas ainda assim a realidade a mesma
para todos os referenciais. Todas as idias e experincias de um indivduo seriam passadas
por outros indivduos, e as idias seriam as mesmas para todos. No haveria espao para
outras interpretaes de realidade, essa seria nica para todos. Qualquer diferena de viso
da realidade seria uma anomalia, pois ela sempre a mesma para qualquer referencial.
Assim, todo o conhecimento e vises da realidade poderiam ser previstos por simples
extrapolao e o todo representado por equaes matemticas imutveis. A prpria
evoluo cultural poderia ser medida e prevista.
Por outro lado, o paradigma subjetivista acredita que a realidade depende da interpretao
de um ser para existir, e que cada realidade pessoal e nica. Por causa dessa
diferenciao, uma postura subjetivista parece mais adequada para a construo de sistemas
de informao, pois como cada realidade diferente e apenas compartilhada em alguns
aspectos, cada nova implementao de sistemas, mesmo que seja utilizando-se a mesma
ferramenta e em empresas de nichos bastante similares, nova e nica. Os requisitos dos
usurios mudaro, as suas formas, mtodos e ferramentas de trabalho sero diferentes para
cada nova instncia.
A tabela 1 sumariza e exemplifica as principais diferenas entre os dois paradigmas dentro
das necessidades dos sistemas de informao.



45
Tabela 1 : Diferenas entre os paradigmas Objetivista e Subjetivista. (adaptada de Liu (2000,
p. 25)).
Conceito Objetivismo Subjetivismo
Realidade
Dada objetivamente, a
mesma para todos e
composta por entidades, suas
propriedades e
relacionamentos
Criada subjetivamente e
socialmente com diferenas
entre grupos dos agentes
conhecidos
Dados
Um meio de representar a
verdade sobre a realidade
Um meio de indicar
intenes e coordenar aes
Verdade
A correspondncia correta
entre entidades reais
Um consenso alcanado,
temporariamente, como base
por uma ao coordenada
Significado
A relao entre um signo e
alguma entidade real
A relao entre o signo e
algum padro de ao
estabelecido como norma
pelo grupo
Sistemas de
Informao
Um tipo de sistema de
escoamento pelo qual dados
fluem
Um sistema semiolgico,
principalmente informal,
mas suplementado com
mensagens formalizadas
Papel do Analista
Especificar as estruturas de
dados e funes necessrias
aos usurios
Ajudar aos usurios a
articular seus problemas,
descobrir suas necessidades
de informao e desenhar
uma soluo sistmica.
46
Como podemos ver, a principal diferena no que concerne a sistemas de informao o
papel do analista, que responsvel por ajudar o usurio a definir as suas necessidades, no
paradigma subjetivista, ao invs de apenas focar nas caractersticas tcnicas e funcionais do
sistema, segundo o paradigma objetivista. Assim, potencialmente um analista que esteja
usando o paradigma subjetivista ter ao final de seu trabalho um entendimento maior das
necessidades da entidade estudada, e ser capaz de especificar solues mais afinadas com
a realidade dos mesmos.
A metodologia semitica utilizada nesse trabalho baseia-se no programa de pesquisas
iniciado nos anos 70 por Ronald Stamper, conhecido como MEASUR (Methods for
Eliciting, Analysing and Specifying Users Requirements). O principal objetivo desse
programa era a definio de uma srie de ferramentas e metodologias para possibilitar a
pesquisadores e usurios um melhor entendimento, desenvolvimento, gerenciamento e uso
de sistemas de informao(Liu 2000). O paradigma adotado por esse programa foi o de
subjetivismo radical, que entende que a realidade vista como uma construo definida
pelo comportamento dos agentes envolvidos. Conforme os agentes interagem, conversam
compactuam, tomam decises, o mundo muda. A realidade , alm de nica e pessoal,
mutvel e adaptvel. E essas mudanas no mundo iro forar novas evolues, novos
comportamentos e novas realidades: desse modo as mudanas sero contnuas.
Tradicionalmente Pierce classificou a semitica com trs divises, a sinttica, a semntica e
a pragmtica. A fim de abranger todos os aspectos necessrios para a elicitao de todo o
ciclo de requisitos de um sistema, Stamper adicionou outros trs e formou seu Framework
Semitico, em forma de escada. A Figura 8 mostra esse framework. Podemos ver a
subdiviso entre dois aspectos, o de plataforma de tecnologiae as funes de informao
Humanas.
47

Figura 8 : O Framework Semitico (adapatado de Liu (2000, p. 27))

Cada um dos degraus da escada formada pelo framework indica um ramo da
Semitica necessrio para o desenvolvimento de sistemas. Cada um deles tem uma
determinada funo e representatividade:

Mundo Fsico: indica as caractersticas e signos fsicos, que podem ser medidos por
anlises fsicas e de engenharia. Seus representantes so os sinais eltricos, marcas e
outros meios reais. No caso de um sistema de informao, podem ser representados
pelo computador utilizado, pela fibra tica que transmite os impulsos de luz, por
esses prprios impulsos de luz que transmitem um cdigo.
Emprico: Esse ramo da semitica estuda as propriedades dos sinais. Por exemplo,
quando um sinal eltrico e enviado por um fio de cobre, qual a tenso nominal que
indica um determinado tipo de sinal? Do mesmo modo ele estuda as necessidades
dos canais, como os sinais fluem no meio, qual o nvel de redundncia necessria,
entre outras informaes.
Sinttica: responsvel pela apresentao formal da infromao. Indica a linguagem,
gramtica, mtodo de formatao, ou seja, regras de composio dos signos.
Semntica: Segundo Liu (2000), o termo semntica normalmente considerado
Informaes
Humanas
Plataforma de
Tecnologia
Sinttico : Estrutura Formal / Linguagem
Emprico : Padres / Rudo / Cdigos
Fsico: Sinais / Traos / Hardware
Semntico: Significado / Proposies / Validaes
Pragmtico: Intenes / Conversas / Negociaes
Social : Crenas / Expectativas / Cultura
48
para descrever a relao entre um signo e seu significado. Como vimos, o
significado de um signo depende de uma srie de fatores, e regido por normas pr-
estabelecidas entre as entidades que esto se comunicando.
Pragmtica: Toda a comunicao tem subjacente uma inteno. Sempre que uma
pessoa passa uma ordem, uma instruo, h a vontade que isso seja acompanhado
de uma ao ou entendimento. Segundo Liu (2000), a pragmtica um ramo da
Semitica que estabelece o estudo do relacionamento entre um signo e o
comportamento dos agentes envolvidos. O entendimento e interpretao, mais uma
vez, dependem do ambiente e de experincias prvias dos agentes, de forma que
para a mensagem surtir o efeito desejado, deve existir um contexto bsico e o
entendimento entre o teor da mensagem deve ser mtuo entre os participantes das
interaes. Como podemos perceber, ao se fazer um sistema computacional a
pragmtica deve ser levada em conta, pois se no for clarificada e implementada
poder acarretar em um fracasso de desenvolvimento.
Mundo Social: A comunicao entre duas ou mais pessoas, segundo (Liu 2000),
provoca uma modificao em nvel social. Isso aderente com a idia de que a
realidade subjetiva e mutvel. Quando informaes so repassadas, ordens e
instrues dadas, quando uma mensagem interpretada e passa pelo processo
cognitivo de uma entidade, o mundo social sofre uma pequena mudana. O estudo
semitico do mundo social evoca a necessidade de entender as normas socias que
regem as comunicaes em grupos, e interpret-las de modo a entender como essas
normas e interaes entre os grupos funcionam.
Um bom exemplo de anlise utilizando-se a escada semitica apresentado por (Liu
2000, p.35-36). Como poderamos analisar uma conversao telefnica por meio da
semitica?
1. Em nvel fsico, necessrio que os aparelhos de telefone estejam conectados a
uma linha telefnica de prestadoras de servio.
2. Em nvel emprico, o sinal de voz modulado e transmitido em forma de sinais
49
eletrnicos ou ticos pelo cabeamento.
3. Em nvel sinttico, as duas ou mais entidades involvidas na conversa devem
falar a mesma lingua e devem utilizar convenes gramaticais vlidas a ambos.
4. Em nvel semntico, as palavras, termos tcnicos e no tcnicos, e as coisas que
so referenciadas durante a conversao precisam ser conhecidas e entendidas
por todos. As sentenas e o contedo da conversao precisam fazer sentido
para todos.
5. Em nvel pragmtico, existe a preocupao com a inteno, e pode haver
mensagens subliminares na comunicao. O exemplo pode ser uma negociao
de preo, onde uma diz que gostaria de comprar, mas acha o preo um pouco
alto, tendo claramente a inteno de negociar um desconto.
6. Em nvel social, obrigaes e acordos so feitos, por causa do resultado da
conversa. Seguindo o exemplo, o desconto pedido ser dado ou no.
O MEASUR utiliza-se desses conceitos para prover os mtodos necessrios para o uso da
Semitica para uma soluo computacional. Ele composto de cinco mtodos principais,
que so:
1. Mtodo de Articulao de Problemas (PAM): compreende uma srie de mtodos
para serem utilizados em fases inciais do projeto, enquanto o problema a ser
resolvido no est bem entendido e ainda expresso de forma vaga.
2. Mtodo de Anlise Semntica (SAM): esse mtodo tem como entrada um ponto
focal ou problema determinado, e tem como principal objetivo ajudar ao usurio a
elaborar e representar seus requisitos de forma clara e precisa.
3. Mtodo de Anlise de Normas (NAM): visa especificar formalmente os padres
gerais de comportamento de uma determinada entidade, e est focado nas normas
culturais, sociais e organizacionais que regem o comportemento e aes dos agentes
em seus ambientes de negcios.
50
4. Anlise de Comunicao e Controle: ajuda na anlise das comunicaes entre todos
os agentes envolvidos e o sistema focal
5. Anlise de Meta-Sistemas: trata todo o desenvolvimento como um objeto de estudo,
e ajuda no planejamento e gerenciamento do projeto.
O objetivo desse estudo verificar se as ferramentas definidas pela MEASUR poderiam ser
aplicadas para a elicitao de requisitos para um ambiente de Data Warehouse, em uma
determinada entidade. Devido ao tamanho e complexidade do projeto, esse trabalho foi
focado na fase de elicitao inicial e por isso a ferramenta mais adequada seria o PAM.

4.3 O Mtodo de Articulao de Problemas (PAM)
O PAM consiste de um conjunto de ferramentas que deve ser utilizado no estgio inicial do
desenvolvimento da soluo, enquanto h apenas uma idia do problema, estando esse
representado de forma vaga.
Segundo (Liu, 2000), essa fase inicial pode ser considerada a fase de anlise de
infraestrutura, e pode ser pesquisada com o uso combinado do Framework Semitico e o
PAM. Na sua viso, Liu considera essa primeira anlise importante para entender contextos
sociais, organizacionais, tcnicos e culturas de uma organizao e, com isso, identificar
problemas de processos de negcios e tcnicos.

4.3.1 Anlise de organizao e contexto
Essa etapa permite conhecer, atravs da anlise de Stakeholders, todas as pessoas que esto
envolvidas em um determinado processo, bem como fazer uma avaliao total da
organizao e contexto para o sistema proposto.
A anlise de Stakeholders deve estabelecer as partes interessadas no processo, a fim de
garantir a representatividade de todos os envolvidos. Isso extremamente importante
51
porque geralmente no h pessoas com o conhecimento total de todos os aspectos de um
processo ou estrutura, e a falta de uma parte das informaes pode provocar a
implementao de um sistema falho e inopervel, ou pior, pode ser um sistema que resolva
o problema errado. Para essa anlise, podemos utilizar a estrutura presente na Figura 8, que
representa todas as camadas de interao possvel com um sistema, da mais interna mais
externa. As representaes dessas camadas so:
Operao: indica o sistema focado na avaliao;
Contribuio: representa toda as pessoas com parte ativa no processo de
desenvolvimento, com conhecimentos sobre os processos e necessidades a
serem analisadas e automatizadas pelo novo sistema;
Fonte: Todas as entidades relacionadas como clientes e fornecedores, que
impactam ou so afetados pelo sistema;
Mercado: entidades que servem como referencial para o sistema, sendo por
comparao ou por competio.;
Comunidade: o mundo social, como por exemplo legisladores, jornalistas,
todos aqueles com potencial para influenciar indiretamente o
sistema.
52

Figura 9 : Camadas da Anlise de Stakeholders
Outra ferramenta o Framework Antropolgico, que ajuda a definir aspectos do sistema de
informao facilitando a anlise dos grupos sociais envolvidos. O Framework
Antropolgico avalia os seguintes aspectos:
Interao: relativo comunicao;
Associao: grupos, relaes, organizaes;
Subsistncia: Questes econmicas, financeiras, financiamento, investimentos;
Taxonomia: entendimento das classificaes empregadas;
Espao: tamanho necessrio, localizao;
Tempo: histrico, datas, perodo;
Aprendizado: cognio, treinamentos,conhecimento necessrio;
Criatividade: processo de inovao, cultura;
Defesa: como se preparar de ataques, como responder a questionamentos,
53
segurana;
Explorao: utilizao de materiais, processos, perfis.
Com base nas informaes prvias levantadas, principalmente da Anlise de Stakeholders,
pode-se montar os Quadros de Avaliao. Esse quadros levam a transposio das pessoas e
entidades interessantes para o processo a elicitar, por meio de um brainstorming, quais os
problemas encontrados na soluo ou processo atual, quais as condioes e efeitos
necessrios e quais as solues sugeridas pelos prprios usurios.

4.3.2 Anlise da Morfologia Funcional
A Anlise da Morfologia Funcional ajuda a representar a estrutura de cada unidade da
entidade estudada. considerada por Liu bastante similar ao mtodo estruturado de anlise
de requisitos, top-down. A principal diferena est numa viso diferente, sendo a anlise
da morfologia funcional focada na identificao das normas que regem o comportamento
das pessoas dentro de uma unidade de sistema. Cada unidade pode ser dividida em trs
subpartes:
Substantivo: esse comportamento regido por tarefas, regras e normas, derivadas
dos ojetivos organizacionais dentro de uma determinada estrutura. As aes
tomadas dentro dessa categoria devem levar a empresa a teoricamente alcanar seus
objetivos, ou seja, o que o funcionrio deve fazer no seu trabalho a fim de
adicionar valor agregado aos produtos ou prpria empresa;
Comunicao: essa subparte ligada a signos, est diretamente relacionada com as
entradas e sadas dos processos de comunicao. As normas de comunicao
direcionam a passagem de instrues e mensagens entre os agentes da empresa,
dando subsdios de informao para o comportamento substantivo da empresa,
indicao de medidas a serem tomadas, suporte a tomada de decises, etc. Os sinais
so utilizados entre agentes que os entendam, a fim de denotar uma inteno.
Controle: Esse comportamento diretamente ligado idia de controle e existe para
54
garantir que os dois comportamentos anteriores alcancem seus objetivos.
governado por normas, que estipulam regras e regulamentos, contratos, ameaas ou
acordos. Caso um agente falhe em cumprir suas obrigaes, ou ento no consiga, a
parte de controle responsvel pela aplicao de sanes, a fim de garantir que o
processo seja continuado.
A figura 10 representa a decomposio de uma unidade X atravs dos trs comportamentos.
Nota-se que, mesmo dentro do ramo de um comportamento ele pode ser dividido em aes
representativas dos outros, e assim at atingir-se uma tarefa atmica dentro do diagrama.

Figura 10 : Representao da Anlise de Morfologia Funcional


4.3.3 Anlise Colateral
A anlise colateral ajuda a entender um sistema complexo em unidades ou ciclos menores,
permitindo a visualizao de fronteiras em um sistema mais complexo. como se a tcnica
de diviso e conquista fosse aplicada em um sistema tecnolgico total, dividindo-o em
subcomponentes tecnolgicos que facilitariam a sua implementao. O escopo da anlise
55
um sistema como ponto focal e ento estuda-se todas as unidades de sistemas que
interagem com ele, formando sistemas colaterais. Esses sistemas tm, dentro de si, um novo
ponto focal, e assim por diante, at que seja garantido que todos os pontos de
implementao estejam cobertos. O objetivo garantir que mesmo os pequenos detalhes da
implementao sejam cobertos, de modo a evitar ao mximo obstculos no previstos
durante o planejamento.
Os subsistemas de uma soluo geral podem ser divididos nos seguintes ciclos:
1. Ciclo de vida: representa uma realidade temporal, indicando o sistema focal, seu
predecessor e seu possvel sucessor.
2. Funcionamento: Indica quem fornece o qu ao sistema, e como as sadas do sistema
focal influenciam o ambiente, sendo realimentadas no mesmo.
3. Operao: indica os ciclos de construo e desmonte do sistema, quais os recursos
disponveis ao projeto, quais sero absorvidos, quais sero liberados, o que sobrar
aps o desmanche.
4. Anlise e projeto: Documentao das anlises e projetos, plantas, recomendaes de
uso, representao do sistema.
5. Manuteno: Ciclo de manuteno do sistema, quais as janelas de operao, quais
as janelas de desenvolvimento, quais os alertas, quais as operaes de preveno?
6. Backup: quais os procedimentos em caso de queda, quais os recursos de
recuparao, o que necessrio para manter a sade do sistema e manter o nvel de
SLA (Service Level Agreement) da operao?
7. Aprendizado: Melhorias durante a implementao conjunta com correo de falhas,
evoluo real do sistema.
A figura 11 representa o ciclo proposto.
56

Figura 11 : Ciclo da Anlise Colateral. (Simoni, 2003, adaptado de Liu, 2000).

4.4 Consideraes Finais
Neste captulo apresentamos o referencial terico da Semitica que serviu como base para a
criao da Semitica Organizacional, objeto deste estudo. Foram apresentados os conceitos
bsicos da Semitica, sua extenso para a Semitica Organizacional e como os
pesquisadores do projeto MEASUR utilizaram esses conceitos para gerar uma srie de
ferramentas e mtodos para a elicitao de requisitos. Este trabalho utilizar, no prximo
captulo, as ferramentas apresentadas para verificar sua validade de emprego para a
elicitao de requisitos em um ambiente de Data Warehouse, em especial o mtodo PAM.
Sistema
Focal
Ambiente 2
Entrada 2 Sada 2
Descrio 5
Predecessor 1 Sucessor 1
Manuteno 7
Aprendizado 8
Backup 6
Recuperao 6 Queda 6
Disponvel 3
Lanamento 3 Trmino 3
Recursos 4
Construo 4 Desmonte 4
1. Ciclo de Vida
2. Funcionamento
3. Operao
4. Construo
5. Anlise e Projeto
6. Backup
7. Manuteno
8. Aprendizado
57
Captulo 5
Buscando uma soluo preliminar de Data
Warehouse: Um Estudo de Caso

5.1 Planejamento do Uso das Ferramentas da Semitica
Organizacional.

Durante a fase de planejamento do estudo de caso foram escolhidas quatro tcnicas da
Semitica Organizacional. Cada uma delas apresenta caractersticas que consideramos
importantes para a elicitao de requisitos de uma soluo de Data Warehouse.

A seguir apresentamos a justificativa para a utilizao de cada uma das tcnicas escolhidas
e quais aspectos da elicitao de requisitos essas tcnicas deveriam cobrir:

Anlise de Stakeholders:

Durante projetos de implementao de sistemas em grandes empresas, no apenas de
solues de Data Warehouse, mas de qualquer novo processo, muito difcil conseguir que
usurios chave, com conhecimento dos processos e de normas das empresas possam ficar
focados no projeto da soluo. No caso de ferramentas de apoio a negcio e da base de
Data Warehouse que as apoiam, o cenrio mais complexo porque as pessoas que
deveriam ser envolvidas geralmente so tomadores de deciso extremamente importantes
para as empresas, com agendas de trabalho muito apertadas e que geralmente esto
indisponveis. Por esse cenrio, muitas vezes o acompanhamento da implementao fica a
cargo de colaboradores que detm apenas vises particulares do processo, sem ter
conhecimento do cenrio como um todo.
Por isso, a anlise de stakeholders poderia dar uma viso de toda a empresa, garantir que
todas as reas da mesma estariam bem representadas e que haveria conhecimento de todos
58
os processos exercidos por essas unidades. Alm disso, a anlise de stakeholders tambm
d uma viso da interao entre sistemas e sociedade, que poderia sugerir fontes de dados e
do fluxo do mesmo entre os sistemas integrados.

Quadro de avaliao:

O quadro de avaliao, segundo as nossas expectativas iniciais, poderia evidenciar, alm
dos processos que necessariamente deveriam estar representados, os problemas enfrentados
no dia a dia da empresa com a representao e com o fluxo de informaes. Lembrando que
um sistema de Data Warehouse no necessariamente tem uma maneira determinstica de
uso, essa fase ajudaria a evidenciar as necessidades dos usurios, que tipo de interao eles
costumam ter com informaes e qual a maneira que eles utilizam para manipular as
informaes. A anlise do fluxo de informao pelos participantes tambm poderia ajudar a
elucidar partes obscuras do processo e evidenciar caminhos mais otimizados para o fluxo
de informao. A presena de colaboradores e representantes de todas as entidades
evidenciadas na fase de Anlise de Stakeholders seria de suma importncia.

Framework Semitico:

O Framework Semitico foi considerado a principal ferramenta para a anlise de requisitos
de solues baseadas em Data Warehouse. Isso porque as caractersticas do framework
possibilitam tanto o estudo do fluxo e de necessidades de informao do ambiente que se
estuda, bem como uma anlise dos processos informais e intenes no registradas,
principalmente por meio da camada pragmtica da escada semitica.
O uso do Framework Semitico na fase inicial de estudo de viabilidade do projeto poderia
nos indicar, atravs das camadas inferiores da escada, qual o tipo de tecnologia preferida da
empresa e dar idia de que aspectos de infra-estrutura computacionais seriam mais
adequados no ambiente, facilitando assim a implementao e diminuindo o custo do
projeto. Alm disso, na fase de estudo de viabilidade, a parte superior da escada de suma
importncia, pois pretendamos que fossem evidenciadas as reais necessidades de fluxo,
59
mtodos de acesso informao dos usurios e o relacionamento desses usurios com a
informao.

Anlise Colateral:

A Anlise Colateral foi considerada no mtodo por prover o usurio com uma viso geral
do que foi estudado, a fim de verificar se a compreenso do sistema por parte do usurio foi
correta, bem como se os analistas responsveis pela elicitao dos requisites conseguiram
compreender a dinmica de trabalho da empresa, suas necessidades de informao e suas
caractersticas prprias, como termos e jarges. Alm disso, nessa fase poderia ser
evidenciado o real desejo do grupo estudado em relao a uma soluo computacional,
quais as suas expectativas e, dependendo do resultado, fazer uma nova iterao de algumas
das ferramentas, objetivando um ajuste fino das informaes.

A Figura 12 mostra a sequncia de tcnicas sugerida.


Figura 12 : Seqncia de Tcnicas sugerida

Nesse momento de anlise de requisitos no estava prevista a elicitao de necessidades da
camada de interface, apesar de que elementos dela j estivessem explcitos em algumas
necessidades dos usurios que foram aparecendo conforme as ferramentas da tcnica iam
sendo utilizadas.

Anlise
Colateral
Anlise de
Stakeholders
Quadro
de
Avaliao
Framework
Semitico
60
Descrevemos a seguir as seqncias de passos e informaes esperadas em cada etapa do
processo de elicitao de requisitos. Uma soluo de Data Warehouse geralmente apresenta
a estrutura mostrada na Figura 13 a seguir:



Figura 13 : Representao esquemtica da soluo final

O principal objetivo do emprego das tcnicas da Semitica Organizacional o
levantamento das necessidades dos usurios para a definio do esquema bsico
apresentado na figura 13.

O principal resultado esperado aps a aplicao das tcnicas da Semitica Organizacional
um esboo da soluo para o planejamento da implementao, bem como verificar se a
empresa tem o nvel de maturidade tecnolgica e processual para poder implementar e
usufruir de uma soluo de Data Warehouse. Caso a empresa tenha problemas graves de
processos, no haja definio do fluxo de dados ou problemas similares, o projeto de
implementao de um Data Warehouse pode ser adiado at que os problemas sejam
resolvidos e a empresa realmente tenha condies de fazer essa implementao. Dados os
gastos de tempo e de recurso normalmente empregados em uma soluo de Data
Warehouse, uma definio precoce de problemas torna-se de suma importncia.
Fontes
de Dados
E - Extrao
T - Transformao
L - Carga (Load)
Data Warehouse
Data
Marts
OLAP
Servers
Servio
61
Podemos representar a anlise dimensional para o Data Warehouse atravs do modelo
grfico chamado Star Schema. Esse esquema grfico mostra a determinao das
informaes que devem ser contidas nas tabelas-fato de um Data Warehouse, de onde as
dimenses iro retirar suas informaes e prover seus relacionamentos. Assim sendo, as
dimenses necessrias elicitadas sero representadas dessa maneira, dando aos
implementadores um caminho seguro a seguir. Nesse momento no pretendemos levantar
todos os dados e metadados que iro compor os bancos de dados, mas sim evidenciar numa
viso macro quais aspectos dos sistemas legados e de fonte os analistas seguiro para
definir a estrutura final do banco de dados. A principal vantagem de se fazer esse diagrama
utilizando o Star Schema que essa representao no atrelada a nenhuma das
tecnologias em uso para Data Warehouse, podendo ser utilizada para a representao de
sistemas que sero construdos tanto em Banco de dados Relacionais, OLAP , MOLAP ou
qualquer outro.

A Figura 14 representa o fluxo de anlise das ferramentas e os resultados esperados pelo
emprego de cada tcnica.



Figura 14 : Diagrama de uso dos resultados das tcnicas empregadas
Sistemas Fonte
Anlise de
Stakeholder
Framework
Semitico
Anlise
Colateral


Quadro de
Avaliao
E
T
L



Fontes de Dados
Stakeholders
Aplicaes
Dimenses
62

O processo inicia-se com o estudo dos dados levantados na etapa de Anlise de
Stakeholders. As entidades representadas na camada de contribuio sero as pessoas ou
unidades que devero ser consultadas para os levantamentos das necessidades do sistema.
So desses usurios que os mtodos de trabalho e a as idias de qualidade de dados e
necessidades de informao sero levantadas, a fim de represent-las no sistema final.

Ainda avaliando as Partes Interessadas, temos as camadas de Mercado, Comunidade e
Fonte. As camadas de Comunidade e Mercado podem dar pistas de que tipo de
concorrncia e atuao so esperados da empresa, mas o ponto mais importante a camada
de Fonte. As fontes de dados em uma soluo de Data Warehouse so de extrema
importncia e qualquer falta de informao, inconsistncia ou falta de homogeneidade entre
os metadados das informaes podem causar efeitos catastrficos durante o projeto e o uso
do produto final.

As entidades presentes na camada Fonte podem ser levadas diretamente ao projeto do ETL.
Com essas informaes iremos popular a primeira camada da soluo e saberemos o que
verificar e perguntar em etapas mais aprofundadas do levantamento. Geralmente essas
fontes so sistemas computacionais legados, mas podem ser qualquer tipo de informao
existente na empresa. Esse levantamento precoce dos sistemas envolvidos de grande
importncia para evitar que a falta de informaes cause impacto em fases posteriores.
Como principais vantagens do uso do mtodo nesse momento e os resultados esperados
so:

Levantamento de todas as fontes de informao existentes para o sistema.
Definio de quais informaes no esto em ambientes computacionais integrveis
( relatrios em papel, jornais, outros tipo de mdias), que precisaro definies de
uso e carga
Visibilidade das necessidades de homogeneizao de dados e de metadados das
aplicaes
Possveis dificuldades com dados necessrios mas inexistentes
63
Quantidade de fontes diferentes e volume de trfego de informaes
Pr-visualizao de quais informaes so importantes para um Sistema de Apoio a
Deciso

O ltimo item remete necessidade de se definir granularidade e universo de abrangncia
dos dados. Um Sistema de Apoio a Deciso no deve nem pode conter todos os dados dos
ambientes relacionais, pois seno seria apenas um repositrio central de dados,
descaracterizando a real vantagem desse tipo de sistema. Pessoas que necessitem de um
grau de informao muito detalhado devem ir direto aos sistemas de informao
relacionais, isso fato. Um Data Warehouse com excesso de informaes no ter a
agilidade necessria a tomadas de deciso de momento, praxe nos ambientes empresariais
de hoje. O impacto no desempenho de excesso de dados que no sero utilizados, tanto
durante o uso, quanto nas janelas de carga, podem aumentar muito o custo da aplicao e
inviabilizar o processo.

Os dados levantados nessa fase devem ser utilizados como base para a prxima etapa do
processo. importante frisar que a qualquer momento podem surgir novos dados,
processos, fontes e usurios no processo, de modo que iteraes podem ser necessrias, a
critrio do profissional que est utilizando a tcnica. Essas iteraes devem ser bastante
comuns e no devem ser encaradas como problemas, pois a tendncia conforme a tcnica
utilizada h um entendimento maior do processo pelo prprio usurio e idias, sugestes e
problemas que nunca haviam sido levantados podem ser reconhecidos.

A prxima tcnica a ser empregada, o Quadro de Avaliao, invoca as entidades elicitadas
na fase de Anlise de Stakeholders, colocando em debate qual o seu papel nos processos,
quais os problemas encontrados nesses processos e quais possveis solues os usurios
gostariam de ver implementadas. Nesse ponto, devemos ter cuidado mais uma vez com o
principal ponto de um sistema de suporte deciso: ele oreintado a dados, logo o que
devemos perguntar nessa fase :

Quais as reais necessidades de dados da empresa?
64
Quem so as pessoas que dependem desses dados e para que eles os utilizam?
Os dados apresentados hoje so completos?
Os dados presentes nos sistemas hoje tm boa qualidade?
Qual a interpretao da empresa para Qualidade de dados?
H alguma ruptura no fluxo de informaes?
Quais as reas problemticas em relao ao envio de dados?
Como as reas entendem e manipulam seus dados?
Qual o perfil de uso e de anlise desses dados?
Quais as dificuldades encontradas para essa anlise?

Essas perguntas no devem ser colocadas diretamente para no influenciar as respostas,
mas devem servir como guia para que a atividade cumpra seu papel essencial. Dependendo
do tipo de pblico e da experincia dos usurios com projetos de informtica ou com
processos computacionais, pode haver uma tendncia a se entrar em discusses tcnicas a
respeito das atividades. No esse o objetivo da tcnica nesse momento. O empreendedor
dessa anlise deve tentar entender quais os processos essenciais e as dificuldades correntes
neles, bem como tentar homogeneizar os entendimento dos setores, em especial nas reas
de interface. Se possvel, o perfil das pessoas que faro o uso da soluo final deve ser
analisado.

Depois do estudo dos resultados dos problemas levantados no Quadro de Avaliao, o
analista dever ser capaz de comear a enxergar os padres, problemas e necessidades dos
usurios, ainda de forma no estruturada.

A prxima etapa o uso da Escada Semitica para a avaliao geral. Essa etapa a mais
importante do processo de elicitao, pois dela sairo as aplicaes que sero transformadas
em tabelas-fato e regero a criao das dimenses. Como foi visto na seo 4.2, o
Framework Semitico dividida em seis camadas, e as que mais nos interessam so as
camadas Pragmtica e Social. A camada Pragmtica representa as intenes,
determinaes das pessoas e entidades, podendo inclusive evidenciar fatos que no seriam
considerados relevantes num mtodo tradicional de elicitao e requisitos. As camadas
65
inferiores, relacionadas ao mundo fsico, podem ser trabalhadas, geram informaes
extremamente relevantes, mas para a verificao das necessidades de dados da empresa elas
no influenciariam muito no resultado.

As reais necessidades da empresa devem ser evidenciadas nessas duas camadas. O
consultor deve identificar e dividir as necessidades conforme grupos bem definidos, que
sero utilizados para as tabelas-fato e para a anlise dimensional.

Podemos exemplificar o processo com o seguinte caso fictcio. Digamos que o processo
esteja ocorrendo numa empresa fabricante de determinado produto. As etapas vo se
sucedendo e chega-se ao ponto do uso do Framework Semitico. Dentro da camada
Pragmtica, entende-se que a maior necessidade da empresa o controle do custo produtivo
e o controle do fluxo de vendas. O analista, desse modo, teria em suas mos os dois
principais processos que orientariam as prximas tomadas de deciso da empresa. Esses
dois processos seriam as bases para as tabela-fato.

Analisando agora os resultados dos Quadros de Avaliao, os problemas e solues
levantados deveriam ser distribudos entre esses dois processos. Eles no so mutuamente
excludentes, ento uma informao pode ser parte dos dois. Quando todas as informaes
forem distribudas, as analises e agrupamentos das mesmas iro nos informar as dimenses
da aplicao e nos indicar quais as informaes a disposio nas entidades fonte devem ser
levadas a cada uma das aplicaes. Essa definio o resultado final da anlise preliminar e
objeto final do estudo.

Depois da utilizao do Framework Semitico, a prxima ferramenta utilizada a Anlise
Colateral. Essa etapa deve dar uma idia ao analista sobre o que a empresa enxerga como
sua real necessidade, o que ele entendeu do sistema proposto e como ele acha que ser a
evoluo do sistema e a sua interao com o meio. Alm disso, em etapas mais tcnicas,
informaes como necessidades de backup e recovery so explicitadas.

66
Para a confeco do desenho inicial do Star Schema, todos s dados levantados sero
verificados, mas a Escada Semitica dever ser alvo de uma anlise mais profunda. Os dois
primeiros degraus, o que representa o nvel pragmtico e o que representa o nvel social,
devero indicar quais aplicaes, ou seja, quais tabelas-fato iremos utilizar, para quais
processos especficos. Esses processos serviro de base para podermos fazer o estudo que
indicar quais dimenses devem ser agregadas ao modelo. Cabe ao analista conseguir
diferenciar e ter discernimento sobre isso, tambm com base no conhecimento adquirido
durante as sesses de trabalho. Mesmo se um determinado processo no tenha sido
explicitado pelos usurios, mas pelas conversas e dados anteriores o analista achar que o
processo deve ser analisado, ele deve ser colocado em pauta e revisto.

Continuando o exemplo hipottico, digamos que o analista consiga duas aplicaes a partir
da anlise da Escada Semitica. Essas duas aplicaes devem ser colocadas no centro de
um grfico, representando a tabela-fato do Star Schema. Cada aplicao gera um Star
Schema diferente. Para melhor representao, os processos devem ter nomes relacionados
com o processo ou inteno do grupo trabalhado. Apenas como exemplo, vamos dizer que
o levantamento esteja sendo feito para uma rede de supermercados, com estoque central e
com vrias lojas. A verificao da Escada Semitica indica que os diretores querem um
melhor controle do estoque, para melhorar a logstica e um melhor controle de vendas por
supermercado. Assim, podemos dividir o trabalho por duas aplicaes diferentes,
ESTOQUE e LOJAS.

Figura 15 : Aplicaes representadas por tabelas-fato

67
Aps a definio das aplicaes, devemos percorrer todos os dados levantados nas outras
sesses para avaliar quais dimenses seriam necessrias para conter os dados requeridos
para os cruzamentos de informao dos usurios. Podemos fazer isso percorrendo
principalmente as colunas de soluo do Quadro de Avaliao, que a atividade que ir
indicar como os usurios gostariam que as atividades fossem feitas. Desse modo, e sempre
contando com a experincia do analista, podemos separar os problemas relacionados com o
Data Warehouse, desprezando alguns que no tenham relacionamento com o mbito de
dados. Devemos lembrar que apesar dos processos serem extremamente importantes para a
gerao e coleta de dados, um Data Warehouse orientado a dados e no pode ajudar em
problemas exemplificados como Aumentar o moral da equipe. Ele pode sim ter um
indicador que mais tarde em um sistema de avaliao, como por exemplo uma ferramentas
de Balance Scorecard, possa ter isso como meta, mas no deve entrar como problema
direto em um Data Warehouse.

Deve ser feita uma lista indicando qual a soluo, a qual aplicao pertence, se a uma ou a
ambos. A anlise desses dados deve indicar ao analista quais as dimenses de importncia,
pois ela deve estar destacada na frase, expressando o sentido principal dela. Por exemplo,
se a soluo estiver em uma frase do tipo Verificar quais lojas tm maior ndice de vendas
por perodo, podemos notar que na aplicao LOJA deve ter uma dimenso VENDAS e
TEMPO, para conter as informaes desejadas. Aps essa anlise do Quadro de Avaliao
principalmente, devemos estar aptos a montar o mapa inicial das tabelas-fato e dimenses.


Figura 16 : Representao de uma aplicao e suas dimenses
68

Essa seqncia de atividades e de anlises foi empregada no estudo de caso instanciado,
descrito na seo 5.3.
5.2 Descrevendo a Organizao e o Contexto
5.2.1 A definio da organizao a ser estudada

A definio do objeto de anlise para o estudo de caso levou em consideraes alguns
aspectos para se eleger a melhor entidade para estudar durante o trabalho. A entidade em
questo no poderia ser muito pequena, pois o volume de dados de uma empresa influencia
diretamente em uma soluo de Data Warehouse e o acesso informaes deveria ser o
mais livre possvel. Essa ltima necessidade seria a mais difcil de cumprir, pois os dados
de um Data Warehouse so dados estratgicos, que espelham a sade e os objetivos da
empresa. Sendo assim, o grau de acesso s pessoas e s informaes seria relevante para a
deciso de qual entidade seria utilizada nos estudos.

Surgiu a possibilidade de realizar esse estudo na Secretaria de Vigilncia Sanitria do
Estado de So Paulo DIR I Capital. DIR I significa Diretrio Regional. Doravante
chamaremos a entidade apenas como DIR. Para se chegar a essa concluso, fiz uma srie de
visitas e verificaes na maneira como eles trabalhavam a informao, o volume de dados e
qual o tipo de problemas que poderiam ser encontrados na DIR e que poderiam demonstrar
a capacidade das ferramentas da Semitica Organizacional para a elicitao de requisitos de
uma possvel soluo de Data Warehouse.

Na primeira reunio que tive com a Diretora da DIR ficou evidente como as diferentes
interpretaes de simples palavras e termos podem levar a resultados totalmente diferentes,
mostrando assim a importncia de um ferramental como o da Semitica Organizacional.
Nessa reunio eu estava tentando explicar para a Diretora quais eram as minhas intenes
para o trabalho. Durante a conversa, sem dar maiores detalhes do que era um Data
Warehouse, pois no cabia na situao e poderia influenciar nos resultados futuros, eu
69
tentei exemplificar a necessidade de informaes de um ncleo de trabalho como o deles,
utilizando exatamente essas palavras. Notei que a diretora ficou ofendida e, conforme ela
me explicou, eles eram uma unidade e no um ncleo. Mais tarde entendi que no
jargo deles um ncleo era um grupo menor, algo como apenas um centro de sade e, ao
cham-los assim, houve uma conotao de diminuio do trabalho deles. Felizmente, a
situao pde ser revertida, mas esse caso serve bem para exemplificar como o sentido e
significados das palavras e smbolos podem afetar de modo crucial a interao dos analistas
com os grupos de pessoas cujo trabalho est sendo elicitado.

A deciso final da possibilidade de trabalho ficou com a representante do CVS (Centro de
Vigilncia Sanitria), rgo paralelo Secretaria e que mantm os sistemas computacionais
empregados pela DIR. Marquei com a analista de sistemas responsvel pelo suporte e
operao desses sistemas para conversarmos e para expor as minhas necessidades e ela
repassou meus pedidos e explicaes para a sua chefia imediata, que permitiu o trabalho.
Essa reunio com a analista de sistemas foi bem interessante, porque algumas de minhas
suspeitas se confirmaram. A analista contou-me de casos prvios e consultorias de
informtica que haviam tentado fazer trabalhos de levantamento de necessidades de
sistemas e processos, sempre sem resultado prtico algum. O principal motivo, segundo ela,
era a dificuldade de entendimento da complexa estrutura e das motivaes da DIR.
Nessa mesma reunio ela se comprometeu a me ajudar com os levantamentos e eu
mostraria a ela as tcnicas da Semitica e explicaria o que era um Data Warehouse,
tecnologia que ela no dominava. Essa analista foi de grande valia ao processo e conseguiu
ter um bom entendimento das ferramentas utilizadas.

Foi feita ainda mais uma reunio, na qual a analista me mostrou as ferramentas utilizadas
por eles para o acompanhamento do ciclo de vida dos processos. Eram ferramentas feitas
pelo prprio CVS, utilizando a linguagem de programao Visual Basic, sem qualquer tipo
de integrao entre essas ferramentas e com a base de dados em Access. Esses sistemas,
conhecidos como SIVISA (Sistema de Vigilncia Sanitria) e SIAP (Sistema de
Informao de atendimento a Pblico) no dispunham de ferramentas computacionais
otimizadas para ajudar no fluxo de informaes das diferentes DIRs, e nem para a anlise e
70
garantia da qualidade dos dados, servindo quase somente como um banco de dados de
processos.


Figura 17 : Exemplos de Telas do Sistema SIAP


Figura 18 : Exemplos de Telas do Sistema SIVISA

Ainda assim, o volume de dados que transita na DIR enorme, devido ao tamanho de sua
operao. Com certeza existe a necessidade de um maior apoio computacional, e a minha
pesquisa poderia mostrar qual esse apoio e quais as reais necessidades de qualidade de
informao e como essa informao poderia ser manipulada.


71
5.2.2 A DIR I e o seu papel na rea de Sade

A regulamentao dos rgos de sade do Estado de So Paulo depende de uma srie de
regulamentaes em instncias superiores, entre as quais a Constituio Federal, as Leis
Orgnicas de Sade, dos cdigos de sade do Estado de So Paulo e de uma srie de outras
decises e normas, todas elas geralmente editadas atravs do Dirio Oficial da Unio. Nos
ltimos anos, o setor Sade vem passando por um profundo processo de transformao
processual e organizacional, atravs da consagrao e estabelecimento do Sistema nico de
Sade SUS.

O SUS uma srie de medidas que servem para garantir que haja um conjunto de aes e
intervenes que possam prover as condies necessrias para que a sade da populao
seja protegida, promovida e, se necessrio, recuperada. As aes da Vigilncia Sanitria so
de suma importncia para esse processo, em todas as trs esferas de governo, federal,
estadual e municipal, sendo as suas aes e atribuies descritas na Constituio.

Na Lei Orgnica da Sade, Lei Federal 8080, de 1990, est prevista a competncia da
Vigilncia Sanitria - VISA. O artigo 6, inciso XI 1 declama:

Entende-se por vigilncia sanitria um conjunto de aes capaz de eliminar, diminuir ou
prevenir riscos sade e de interver nos problemas decorrentes do meio ambiente, da
produo e circulao de bens e da prestao de servios de interesse da sade.

Ou seja, a Vigilncia Sanitria mantenedora de toda a responsabilidade do Governo, nas
trs esferas de atuao, sobre as aes que incidam sobre a sade da populao. A ao da
Vigilncia est bem acima do que apenas a simples aplicao de leis, ela responsvel
tambm pela preveno formal e material da sade pblica. Entre as suas atividades, mas
no resumidas a elas, esto a expedio de licenas de funcionamento, registro de produtos,
autorizaes de funcionamento de empresas, autos de infrao, penalizaes e multas por
problemas relativos sade. Esses documentos so muito importantes para a garantia de
funcionamento de empresas competentes e que cumpram a lei de sade, mas como os
72
prprios participantes do trabalho frisaram, as aes da DIR no so meramente cartoriais,
no apenas distribuem licenas e documentos. A funo mais conhecida na ao da
vigilncia seu aspecto fiscalizador e de polcia das questes de sade, sempre
procurando pontos onde tenham ocorrido falhas no cumprimento das leis sanitrias.
Somente por essas funes colocadas, j podemos ter idia do volume de dados, processos
e informaes que navegam pela DIR todos os dias e a sua importncia para a vida da
populao como um todo.

Nos ltimos anos o enfoque do modelo de sade no Brasil tem mudado. Ao contrrio do
modelo anterior, que era puramente reativo, atualmente tenta-se tomar aes de cunho
preventivo, priorizando aes e intervenes baseadas no risco inerente sade. Essas
aes partem do pressuposto de que os servios e produtos de sade devem ser oferecidos
em quantidade e qualidade adequadas s necessidades da populao.

Podemos dizer, partindo das determinaes formais existentes na Constituio e nas Leis
estaduais e municipais, que o campo de atuao da vigilncia sanitria est dividido em
quatro reas que se inter-relacionam e que compem as unidades da DIR:

1. Controle de produtos que direta ou indiretamente se relacionam sade;
2. Controle da prestao de servios que se relacionam direta ou indiretamente com a
sade;
3. Controle sobre o meio ambiente;
4. Controle sobre o processo de trabalho de qualquer natureza (aes de sade do
trabalhador).

No item 1 esto includas as indstrias de medicamentos, de produtos mdicos hospitalares,
de alimentos, farmcias de manipulao, drogarias, distribuidoras de produtos
(medicamentos, produtos mdicos hospitalares, alimentos), importadoras de produtos,
venda direta ao consumidor de alimentos (supermercados, mercados, bares e restaurantes);
as cozinhas privativas de empresas e as hospitalares isoladas, servios de esterilizao.

73
No item 2 esto: os hospitais, os ambulatrios mdicos, as clnicas de cirurgia ambulatorial
(em especial as clnicas de cirurgia plstica e esttica), os consultrios mdicos isolados, as
clnicas odontolgicas, os laboratrios de anlises clnicas, os laboratrios de patologia
clnica, os hemocentros, as agncias transfusionais, os servios de hemoterapia, os servios
de dilise e hemodilise, os servios de quimioterapia, os centros de diagnstico por
imagem, os servios de medicina nuclear, as casas de repouso, os servios de transporte de
pacientes, os servios de home care, os consultrios de psicologia, nutrio e diettica, as
lavanderias hospitalares isoladas.

No item 3 esto: gerenciamento de resduos de servios de sade, reas contaminadas,
programa da qualidade da gua, criao de animais, depsitos de sucatas, telefonia celular,
cemitrios, aterros sanitrios (deposio de lixo como o aterro Bandeirantes), usinas de
tratamento de resduos (incinerao, microondas).

No item 4 esto: ambiente de trabalho (insalubridade), verificao se existe Comisso
Interna de Preveno a Acidentes, SESMAT (Servios Especializados em Engenharia e
Medicina do Trabalho ), controles de sade como exames peridicos, vacinao, queixas
freqentes, ergonomia, locais potencialmente prejudiciais sade do trabalhador (amianto,
marmoraria, etc).

Para garantir o respeito s normas de cada rgo e situao acima, vrias medidas so
tomadas pelas equipes das DIR, entre elas anlises de documentos, vistorias no local,
analises laboratoriais, pesquisas em textos cientficos, entre outros. A autoridade sanitria
pode escolher quais mtodos e aes sero tomados caso a caso e a sua autoridade total
em sua resoluo.
Ainda segundo a Constituio, os atos de um servidor da sade devem ser sempre
corroborados por lei, e seus atos justificveis por necessidades maiores da populao.
Assim sendo, ele sempre deve obedecer a princpios que garantam que as suas aes so
legais e necessrias, sob pena de priso, inclusive. Alm disso, ele obrigado a denunciar e
registrar quaisquer possveis causas de dano sade da populao, podendo ser julgado por
prevaricao se no o fizer. Dessa forma, notamos mais uma vez a necessidade de um
74
controle rgido de informaes e processos, pois pode ocorrer a necessidade do tcnico de
sade se defender contra acusaes sobre os seus procedimentos, do mesmo modo que pode
existir necessidade da gerao de provas sobre um determinado ato lesivo sade da
populao, e essas decises devem ser tomadas no menor tempo possvel, pois agravos
sade da populao podem aumentar exponencialmente tornando-se casos de epidemias
graves.

Aps os contatos inicias, foi pedido ao grupo que iria comear as atividades que fizessem
uma descrio sucinta do histrico da DIR e de uma rpida opinio a respeito dos seus
problemas em relao informao e suas crticas aos sistemas atuais. O material
gentilmente produzido por eles est reproduzido no Anexo A. Os principais problemas
levantados por esse documento so:

Falta de recursos operacionais e de apoio;
Pouca confiabilidade da infraestrutura de informtica atual;
Falta de polticas de recuperao de dados;
Histrico de dados confuso por problemas de consistncia de dados e de carga;
Registros atuais ainda feitos sem padronizao;
Sistemas de informtica atuais sem troca de informaes (SIVISA e SIAP);
Vrias instncias dos sistemas, gerando diferentes arquivos de dados distribudos
que nem sempre so agregados de forma correta ou em tempo hbil;
Dificuldade de planejamento estratgico causada pela falta de acesso informao
clara.


5.3 O Estudo de Caso

Utilizamos para as reunies, ou workshops, do estudo de caso as instalaes da prpria
DIR, localizada na tradicional Avenida So Luiz, no centro velho de So Paulo, nmero 99,
no prdio cordialmente conhecido como Palcio da Sade. Nesse prdio funcionam
75
diversos rgos que cuidam de vrios aspectos relativos sade da populao e para onde
deve se dirigir uma pessoa em busca de ajuda, que deseje fazer uma denncia ou que queira
orientao sobre um determinado procedimento.

Ao todo seriam feitas quatro reunies em dias diferentes, cada uma delas para a utilizao
de uma das tcnicas da Semitica Organizacional. Essas reunies seriam feitas nas
dependncias da prpria DIR para evitar transtornos aos participantes.

As instalaes fsicas se mostraram adequadas ao processo, possibilitando algum nvel de
privacidade durante as reunies e com bom espao fsico para o material de apoio.
Geralmente utilizamos a sala de reunio presente no andar, mas quando no foi possvel
nos alojamos na sala da Diretora.

A seguir descrevemos cada uma das reunies, seus objetivos, tcnicas utilizadas e
resultados.

Reunio 1 Apresentao da proposta aos participantes e Uso da Anlise de
Stakeholders

A avaliao da empresa que quer implementar uma soluo de Data Warehouse deve
comear com a utilizao da anlise de stakeholders. Para essa sesso, devem ser chamados
representantes de todos os setores iniciais que estejam envolvidos nos processos e fluxos de
informao que a empresa quer sistematizar. Aqui h dois pontos a serem considerados:

1. Apesar de ter uma idia do que quer, a empresa pode no estar familiarizada com as
necessidades de uma soluo de Data Warehouse e o departamento que teve a iniciativa
de comear os estudos para verificar a viabilidade do projeto pode no ter
conhecimento de todas as interfaces de comunicao envolvidas nos processos. Assim
sendo, muito provvel que nesse primeiro momento no estejam presentes todas as
pessoas chaves para um bom levantamento do processo.

76
2. Uma soluo de Data Warehouse direcionada para os tomadores de deciso de uma
empresa. Isso quer dizer que geralmente uma soluo dessas ser til para pessoas de
nvel hierrquico elevado ou que tenham cargos que exijam uma viso generalista da
empresa, como por exemplo, consultores estratgicos. Esse tipo de pblico geralmente
no est prontamente disponvel, sendo que conflitos de agenda so tpicos. muito
importante que, at a definio de quem realmente detm o conhecimento dos processos
e para qual perfil de uso a soluo ser desenvolvida, as sesses sejam agendadas com
antecedncia e que se tente um compromisso com instncias superiores dentro da
corporao, a fim de garantir a presena das pessoas chave ao processo de elicitao.

Com o exposto acima, podemos ver que a primeira reunio de anlise de stakeholders de
suma importncia. durante essa sesso que poderemos avaliar todas as interfaces de
comunicao e tentar que as peas fundamentais assumam compromisso com o andamento
da anlise. Com base nessas consideraes, para essa reunio ficou decidido que:

Seriam convidadas pessoas de todo o organograma bsico da DIR, no nvel
gerencial;
No seria feita referncia ao Data Warehouse diretamente;
A reunio comearia com uma explicao dos meus objetivos;

Participaram dessa primeira etapa ao todo seis usurios, representando as diversas camadas
hierrquicas da DIR:

Diretora;
2 Assistentes Tcnicas da Diretora, uma da rea jurdica;
3 diretores de rea, sendo elas projetos ( assistente tcnica), meio ambiente e
produtos;
A analista de sistemas do CVS.

Com essas pessoas, esperava ter a total representatividade dos grupos de trabalho da DIR e
a Anlise de Stakeholders poderia confirmar isso.
77

Inicialmente, nenhuma das pessoas presentes tinha conhecimento prvio sobre solues de
Data Warehouse e nunca havia participado de sesses de elicitao de requisitos onde
tiveram sido utilizadas as tcnicas da Semitica Organizacional. Notei que alguns deles,
incluindo a prpria analista de sistemas do CVS que me acompanhava, j haviam
participado de algum tipo de levantamento sobre sistema de informao, pois durante o
comeo dos trabalhos notei certa contaminao de alguns usurios, caracterizada por
perguntas sobre quais questionrios iramos utilizar, qual o tipo do programa, em que
computador rodava, ou seja, perguntas que davam a entender que j haviam participado de
algum tipo de projeto de software.

A reunio aconteceu no perodo da manh e teve durao aproximada de duas horas. Essa
reunio foi gravada com um gravador porttil, com conhecimento dos participantes.
Os primeiros momentos dessa reunio foram utilizados para apresentar aos participantes
quais seriam as atividades envolvidas e porque elas seriam feitas. Houve uma pequena
explicao da tcnica da Semitica utilizada e que gostaria que nos concentrssemos nos
problemas existentes hoje com o fluxo de dados e problemas com acesso a informaes.
Uma explicao mais detalhada sobre Semitica Organizacional, Data Warehouses e sobre
a tcnica que utilizaramos no dia foi dada apenas para a analista de sistemas do CVS,
conforme acordo prvio.

Foi utilizado como material de apoio a figura em camadas representando a cebola dos
Stakeholders. A Anlise de Stakeholders representada em forma de "cebola" por causa
dos diferentes nveis de aninhamento do sistema tcnico, do nvel mais interno at o nvel
mais externo, onde as implicaes sociais do sistema tcnico podem refletir em alguns
pontos que indiretamente influenciariam nas tomadas de deciso.
Essa estrutura organiza o levantamento das "partes interessadas" no sistema de Data
Warehouse. Como apresentado anteriormente, solues de Data Warehouse so utilizadas
para auxiliar no estudo dos processos dentro de uma entidade e de anlise de seu negcio e
objetivos. Levando em considerao esses aspectos, a avaliao das camadas nesse artefato
deve ser tomada da seguinte forma:
78

Comunidade: Essa camada mais externa nos mostra agentes que influenciam indiretamente
nos sistemas, na empresa e/ou no seu resultado. Exemplo disso pode ser o Governo,
Imprensa, etc;

Mercado: Como visto no Captulo 4, a camada de mercado evidencia entidades que servem
como referencial para a organizao, sendo por comparao ou por competio. Ela pode
indicar entidades de servem como modelo, concorrentes ou empresas similares. Apesar de
poder servir como entradas para elementos de benchmark, no podem ser consideradas
como influenciadoras diretas em um sistema de Data Warehouse.

As camadas mais internas, que efetivamente iro fazer parte do fluxo de informao so:

Fonte: Essa camada a principal rea de interface do fluxo de informao da empresa. Os
sistemas, organizaes ou departamentos que fazem parte desse nvel da cebola tomam
parte importante no processo, sendo fontes ou sorvedouros de informao, ou ento
disponibilizando dados vitais para o fluxo e transformao das informaes. Geralmente
so agentes que pedem relatrios, absorvem informao ou, no caso dos prprios sistemas
transacionais da empresa, que fornecem a informao em nveis de granularidade bem
baixos, informao essa que ser trabalhada, agregada e transformada numa forma de
apresentao que possibilitar a interpolao de informao na forma desejada pela
empresa.

Contribuio: So as reas que efetivamente iro utilizar e alimentar o sistema, o seu
principal pblico alvo. Mesmo que uma entidade das camadas superiores necessite de uma
informao do sistema, um representante dessa rea que ir suprir essa informao
retirada do sistema, bem como sero as necessidades desse grupo que sero espelhadas no
sistema final.

As principais informaes retiradas dessa primeira sesso, pela camada de contribuio,
so todas as pessoas-chave para o processo, de forma que todas as reas fiquem bem
79
representadas. Nesse momento, devemos tentar descobrir quais as pessoas que cobrem todo
o conhecimento do fluxo de informaes, quais trabalham com que tipo de resultado e
quais as interfaces necessrias. Durante a anlise, esperado que os participantes notem
reas que no esto sendo representadas, e com isso processos dos quais no se pode ter a
informao total. Nesse momento, deve-se fazer uma anotao e tentar uma reunio futura,
convidando-se os representantes das novas reas e explicando-lhes a sua importncia no
processo. Essas iteraes so necessrias para garantir a representao de todas as reas e
evitar ausncias sobre o processo. Deve-se tomar nota, tambm durante esse processo,
quais as pessoas que podem ser "substitudas" por outras com maior disponibilidade de
tempo.

A camada de fonte contribui de forma essencial ao projeto, mas de maneira diferente.
Podemos considerar a camada de fonte realmente como onde ficaro as entidades
originadoras e sorvedouras de informao. Dessa camada apresentar o comeo de todo o
fluxo de informao que ir passar pela camada de ETL (camada de homogeneizao e
transformao dos dados), ou seja, a partir dela que sero elicitadas todas as fontes
principais de dados do sistema, quais as transformaes necessrias e quais tipos de dados
devero ser inseridos no Data Warehouse. Apesar dos metadados serem muito importantes
para a camada de ETL, no ser essa anlise inicial que ir levant-los, mas sim dar uma
pista de quais sistemas devero ser estudados para garantir que os dados sigam homogneos
aos repositrios do Data Warehouse.

Mesmo aps o trmino dessas sesses de anlise de stakeholders, a qualquer momento ela
pode ser revisada. Caso ocorra, durante as fases posteriores, o consenso de que faltou
alguma entidade fonte ou contribuinte, aconselhvel reiniciar o processo a fim de garantir
a representatividade dessas reas na soluo final. Esse cuidado deve ser tomado por causa
da forma como modificaes posteriores ao projeto so dificultadas pelas prprias
caractersticas das solues de Data Warehouse como, por exemplo, grande quantidade de
dados, grande nmero de clculos e transformaes de dados e interfaces entre sistemas.

80
Aps as explicaes iniciais, os participantes comearam a descrever cada uma das
camadas de informao que eles necessitavam, e num primeiro momento indicavam que
tudo o que eles queriam estava presente no sistema interno SIVISA (Sistema de Informao
em VIgilncia SAnitria). Entregaram-me uma apostila com uma portaria de lei com a
criao desse programa, com a descrio de algumas de suas funes, cdigos e tabelas
internas. Essa apostila indica basicamente os cdigos de operao e as tabelas internas, sem
maiores explicaes de uso e objetivo.

Houve certa dificuldade de manter o foco no levantamento das necessidades do fluxo de
informao. As pessoas presentes comearam a discorrer sobre uma srie de problemas que
no faziam parte diretamente do problema de fluxo e uso de informao como, por
exemplo, problemas de treinamento, instalaes fsicas e dificuldades de interao com
outras esferas de governo. Alguns ajustes no rumo da reunio foram necessrios, a fim de
evitar que a atividade fosse prejudicada.

De uma maneira geral, essa primeira reunio me forneceu uma idia muito boa da maneira
de trabalho deles e conforme a atividade foi sendo feita os prprios usurios notaram uma
srie de problemas e falta de informaes, principalmente de acompanhamento do ciclo de
vida de um processo e de seu histrico. H pontos em que se percebem alguns problemas
com a qualidade das informaes apresentadas, como por exemplo a falta de
homogeneizao dos relatrios dos tcnicos.

Ao final da atividade, o resultado foi documentado conforme ilustra a Figura 19.



81


Figura 19 : Resultado da Anlise de Stakeholders

Cada uma dessas partes interessadas interage de uma forma especfica com o trabalho final
da DIR. Dessa forma, a representao de cada um deles extremamente importante. A
anlise desse primeiro resultado indicou que as unidades da DIR estavam bem
representadas, pois a rea de protocolo, que no tinha um participante direto, poderia ser
representada pela Assistente Tcnica Jurdica, que a consultora da rea. Assim, foi
caracterizado que o grupo estava consistente e apto para a continuao do trabalho.

As principais entidades elicitadas e sua importncia no trabalho da DIR, conforme
levantamento utilizando-se a tcnica de Anlise de Stakeholders so:

Na Camada de Contribuio:

Diretoria/Assistncia Tcnica: responsveis pelas tomadas de deciso relativas a
todos os trabalhos da DIR. Sua responsabilidade controlar e responder perante
instncias superiores e prpria populao sobre assuntos de interesse da sade
pblica. Todas as informaes coletadas durante o trabalho da DIR passam por
essas pessoas, que necessitam de informaes claras para tomadas de deciso. Essas
82
decises podem ser de cunho operacional, como por exemplo, quem ir fazer uma
vistoria, ou de cunho gerencial, como o aumento da criticidade de um processo por
motivos diversos.
Protocolo/Expediente: So os responsveis pela entrada, encaminhamento e sada
das solicitaes do pblico para a DIR. Essa unidade a interface com o pblico,
devendo ter todas as informaes de uma determinada requisio. Tambm
responsvel pelo cadastro das informaes nos moldes atuais, ou seja, nos sistemas
existentes, principalmente o SIAP (Sistema de Informao de Atendimento ao
Pblico ).
Coordenadorias de reas: So os responsveis pelo controle direto dos tcnicos e
por determinado nicho de trabalho da DIR. So divididas em trs: coordenadorias
de processos, projetos e meio ambiente. Ao lado da Diretoria e Assistncia tcnica
a rea que mais necessita de um bom fluxo e controle de dados, devem fazer
controle de seus recursos humanos e de seus recursos materiais, quase sempre
escassos, da melhor maneira possvel.
Tcnicos: so os responsveis pelas vistorias e pareceres tcnicos sobre os
processos que do entrada na DIR. Seu trabalho influencia diretamente todos os
resultados. Como so muitos, a sua presena foi substituda pelos coordenadores de
reas, que conhecem bem o trabalho deles e poderiam demonstrar com certeza as
necessidades dos mesmos.
Suporte Informtica/Sistemas: representadas pela analista de sistemas do CVS
(Centro de Vigilncia Sanitria), so responsveis por toda a implementao e
suporte de solues computacionais dentro da esfera estadual da Vigilncia
Sanitria. Eles seriam os operadores finais do sistema e as suas necessidades de
implementao deveriam ser espelhadas na elicitao de requisitos.

Na camada de Fonte:

Anvisa: A Agncia Nacional de Vigilncia Sanitria a responsvel por determinar
normas, regras e procedimentos para as agncias de sade do pas. Assim sendo,
83
suas resolues devem ser espelhadas e constar do sistema de Data Warehouse.
Polcia/Procon/imprensa: Esses rgos geralmente entram como fornecedores de
denncias e de dados sobre determinados problemas. No caso da polcia, ela serve
ainda como apoio operacional em algumas situaes de risco.
Conselhos de Classes: Conselhos de classe, como o CRM (Conselho Regional de
Medicina) e o COREN (Conselho Regional de enfermagem), entram com denncias
e ajudam no processo regulatrio de algumas entidades como hospitais e clnicas.
Secretaria da Fazenda: O cadastro das empresas na Secretaria da Fazenda dita o que
a empresa pode ou no fazer, sendo assim, essas informaes so cruciais para a
tomada de deciso a respeito de licenas de funcionamento, por exemplo.
Ministrio Pblico: O Ministrio pblico geralmente pede apoio em algumas
situaes, geralmente pedidos de informao sobre casos sobre a sade pblica que
tomaram vulto.
Poder Judicirio: Toma deciso a respeito de processos remetidos para/contra a
DIR. Suas decises devem ser analisadas em situaes futuras e as informaes de
processos da DIR para defesa devem ser bem resguardadas.
Outras DIR: Como cada DIR responsvel por uma regio, informaes de
empresas, processos e licenas entre eles devem ser compartilhadas.

Na Camada de Mercado

Prefeitura: A rea da sade, bem como outras reas de interesse da populao, est
passando por um processo de municipalizao. Com isso, uma parte do trabalho da
DIR foi transferida para as prefeituras, que servem ento como comparativos diretos
dentro de determinados parmetros.
Anvisa (Agncia Nacional de Vigilncia Sanitria)/Visas: A prpria Anvisa e os
outros escritrios das Visas pelo pas servem como fonte de comparao do trabalho
da DIR.



84
Na camada de Comunidade

Governo/Imprensa/Ministrio da Sade: Dentro de um determinado nvel, esses
rgos afetam de forma indireta o trabalho e o fluxo de informaes dentro da DIR,
servindo em grande parte como sorvedouro de informaes. Por isso, os
participantes entenderam que eles seriam parte da comunidade.

Analisando esses dados e comparando-os com as anotaes feitas durante a reunio,
notamos que os usurios comentaram sobre algumas fontes importantes mas no as
indicaram. Apesar de no terem colocado explicitamente o principal sistema de
acompanhamento de processos da DIR, o SIVISA, como uma fonte, com certeza ele uma
importante fonte para o Data Warehouse, pois ele o principal sistema legado cujas
informaes seriam carregadas. de extrema importncia que o analista que esteja
utilizando a tcnica preste ateno a esses detalhes, pois mesmo nas conversas paralelas
entre os usurios informaes importantes foram elicitadas.

Essa primeira reunio mostrou algumas caractersticas do grupo, durante a execuo da
tcnica. As pessoas se sentiam um pouco nervosas pela presena do gravador. Alm disso,
a participao das pessoas foi diferenciada. Algumas delas tomaram a frente, participaram e
deram opinies, enquanto outras permaneceram quase todo o tempo caladas ou dando
alguma negativa a uma afirmao dos colegas. Essa situao se confirmou nas outras etapas
do estudo de caso.

Reunio 2 Uso do Quadro de Avaliao

A prxima Ferramenta utilizada foi o Quadro de Avaliao. Para isso, como material de
apoio, os dados levantados durante a anlise de Stakeholders foram transferidos para
cartazes que continham as linhas com cada entidade declarada, mais colunas com as
funes, problemas encontrados e com solues sugeridas pelos usurios.

85
Foram utilizados trs cartazes, sendo cada um deles continha uma das camadas do diagrama
da Anlise de Stakeholders, ficando apenas as camadas de Mercado e Comunidade no
mesmo cartaz. Em cada cartaz havia quatro colunas, sendo elas:

Parte interessada: a entidade que transportada a partir da anlise de stakeholders.
Cada uma dessas entidades deve ter um representante para ajudar na elicitao dos
processos e de necessidades de informao;
Condies/Efeito: Essa coluna representa qual a interao da entidade no fluxo de
informaes ou de tomada de deciso, bem como as informaes necessrias para
sustentar essa tomada de deciso;
Questes/Problemas: Nessa coluna, os participantes descrevem os seus problemas
mais comuns relacionados ao suporte de tomada de deciso, quais os conflitos
gerados, necessidades no atendidas e problemas no processo;
Possveis solues: Como os representantes das reas enxergam os seus problemas,
e que medidas poderiam tomar para solucion-los.

Apesar do desconforto notado na reunio anterior, ainda assim tentei utilizar o gravador.
Essa reunio foi a mais demorada de todas, comeando na parte da manh e se estendendo
pela tarde. Foi tambm uma das mais proveitosas em relao a problemas de processos e do
fluxo de informaes da DIR.

Antes da ltima reunio havia sido tomada a deciso de que eu no iria explicar aos
usurios exatamente o que era um Data Warehouse, pois havia a possibilidade de que isso
acabasse influenciando o resultado. Ao invs disso, essa falta de conhecimento atrapalhou
um pouco o andamento da reunio anterior e, por isso, resolvemos que na primeira parte da
reunio seria explicado, de uma maneira acessvel a leigos, o que era um Data Warehouse.
Apenas para a representante da rea e informtica do CVS havia sido feita essa explicao
previamente.

O nmero de pessoas participantes foi o mesmo da reunio anterior, mas um dos
participantes no pode comparecer e foi substitudo por um outro coordenador de rea, que
86
nos acompanhou por todas as reunies at o final do estudo de caso. Um dos fatos mais
interessantes do dia ocorreu por causa desse participante. Ao ser informado das atividades
que estvamos fazendo e dos resultados da reunio anterior, essa pessoa comeou a fazer
uma srie que questionamentos a respeito de como o programa funcionava, que tipo de
Data Warehouse seria necessrio e uma srie de perguntas que me levaram a pensar que ele
j havia passado por algum tipo de atividade de levantamento de requisitos. Nesse
momento os outros participantes da atividade tomaram a direo e comearam a explicar
no somente a parte do Data Warehouse, mas tambm da Semitica Organizacional. Foi
uma tima oportunidade para verificar o que pessoas leigas pensam quando apresentados
para essas ferramentas e foi bastante proveitoso para o estudo de caso, pois consegui
verificar que os participantes conseguiram entender da proposta e suas opinies sobre as
tcnicas at aquele momento.

A frase a seguir faz parte da transcrio da fita gravada, como um exemplo do que foi
colocado por um dos participantes:

Quando a gente desenvolve o sistema o que acontece? Tinha l o formulrio, todo mundo
palpitou, a desenvolvemos o programa e todo mundo usa. S que foi feito uma coisa entre
aspas de cima para baixo. Gostou ou no gostou, vai ter que engolir. Algumas regionais
participaram, s que no a grande maioria. Hoje a proposta seria mudar isso. Antes do
computador, antes do sistema, antes de qualquer coisa, vamos sentar e ver o que a gente
efetivamente precisa. No se preocupe com a mquina. Se a gente tem equipamento, se
no. Agora, a gente vai ver primeiro como que funciona esse relacionamento das
pessoas, como eu me relaciono com os outros pblicos... Porque aqui eu tenho esse
pblico, s que ali naquela salinha tem um outro pblico, tem o ministrio...

O sistema ao qual esse participante se referiu foi o sistema original da DIR, o SIVISA.
Podemos notar pela primeira sentena que o mtodo de elicitao de requisitos foi o
mtodo tradicional de entrevistas, sem o apoio da maioria dos rgos que mais tarde
utilizaria o sistema. A parte do relacionamento entre as pessoas, a maneira como as pessoas
se comunicam e trabalham, como flui a informao e as suas relaes, foi bem entendido
87
pelo grupo que era esse tipo de informao que eu buscava com o uso das ferramentas da
Semitica Organizacional.

Nesse momento tambm houve, de um outro participante, um feedback a respeito da
atividade anterior, a Anlise de Stakeholders:

O que a gente fez da outra vez foi levantar os fatores que envolvem nosso trabalho... Por
isso que legal, porque ele conseguiu amarrar o que cerca nosso trabalho, aonde ns
estamos, quais os atores esto envolvidos

A reunio continuou assim por algum tempo, com opinies e relatos de casos de
levantamentos para a construo de sistemas, que quase sempre no atenderam s
expectativas dos usurios. A pessoa que originalmente perguntou a respeito de Data
Warehouse j havia realmente passado por algumas situaes dessas, e tinha um filho
estudante da rea de informtica, vindo da a contaminao pelo assunto.

As tabelas com a transcrio dos cartazes utilizados como material de apoio durante a
atividade, com os problemas e solues indicados pelos usurios para a camada de
contribuio, encontram-se no Anexo B. Apesar de alguns pontos dos problemas no se
relacionarem diretamente com aspectos do uso e do fluxo de informaes, que o mais
importante para a elicitao de requisitos para um sistema orientado a dados como as
solues de Data Warehouse, esses problemas so importantes para conseguirmos avaliar
aspectos gerais da empresa, quais seus pontos fortes e fracos, quais problemas poderemos
enfrentar durante um eventual desenvolvimento da soluo e quais poderiam ser as maiores
lacunas nos processos. Nessa fase para a qual estamos estudando o emprego da ferramenta,
quanto mais conhecermos dos meandros do objeto de estudo, melhor. E so esses detalhes
que nos mostram a real sade dos dados da empresa e sua percepo de qualidade.

Uma verificao simples desse resultado nos evidencia alguns fatores muito importantes
para a confeco de uma soluo para Data Warehouse:

88
As maiores dificuldades em torno de informaes esto na Diretoria/Assistncia
Tcnica e nas Coordenadorias de rea. Isso natural, pois os tomadores de deciso
so os que tm maiores dificuldades para conseguir as informaes e as inter-
relaes de dados que precisam.

As dificuldades apresentadas so de vrias fontes diferentes, como volume de dados,
falta de recursos e problemas de controle de pessoal;
A incapacidade atual de se fazer verificaes de status atual de um projeto ou
requisio.

O resultado do Quadro de Avaliao para fontes pode ser visto no Anexo B2.

Como j discutido em sesses anteriores, a camada de fonte muito importante para uma
soluo de Data Warehouse, pois nela devero aparecer os sistemas legados e as fontes de
informao que devero ser tratadas, homogeneizadas, calculadas e carregadas no Data
Warehouse. A quantidade de fontes indicadas pelos usurios no Quadro de Avaliao, bem
como os problemas relativos s suas informaes do uma idia das dificuldades e pontos
de ajuste que a empresa dever cuidar antes da implementao final de uma soluo de
Data Warehouse.

Mais uma vez, seguindo padro da Reunio 1 , muitos problemas no so relacionados
diretamente com fluxo e uso de informaes, mas do pistas sobre a forma de trabalho da
entidade estudada e de sua interao com as outras entidades que fazem interface com ela.

Para as camadas de Mercado e Comunidade no houve muita discusso, as pessoas que
participaram da atividade, apesar de terem indicado as entidades como parte atuante do
processo de dados, no conseguiram indicar como elas se encaixariam no processo como
um todo, alm do fato de algumas vezes requisitarem informaes transacionais, fora do
escopo de um Data Warehouse. Assim sendo, a maioria das colunas ficou sem comentrios.
Esse efeito pode ser isolado nesse caso especfico estudado, mas no causa surpresa, pois j
89
acreditvamos que as camadas mais externas da Anlise das Partes Interessadas no
poderiam realmente influenciar de forma direta um sistema de apoio deciso. Isso porque
as camadas mais externas no tm contato direto com o sistemas, sendo a sua interao com
o mesmo feita indiretamente e atravs de um agente das camadas mais internas. Caso
perceba-se que um agente considerado das camadas mais externas atua de forma direta com
o sistemas, seja fornecendo dados como fonte ou at mesmo operando o sistemas, ele
dever ser migrado para camadas mais internas.. Podemos ver nos Anexos B3 e B4 os
resumos das atividades para Mercado e Comunidade.

A Reunio 2 foi a que mais durou e que demonstrou como as pessoas interagem durante o
uso das ferramentas estudadas. A longa reunio, que comeou no meio da manh e se
estendeu at o fim da tarde, foi bastante cansativa e no final dela os participantes j estavam
bastante esgotados, com o nvel de participao bastante baixo. Apesar disso, fatos
importantes foram evidenciados.

Conforme a reunio ia fluindo, em alguns momentos houve algumas divergncias de
opinio entre os participantes, o que era esperado. Aps a pausa para o almoo, algumas
pessoas voltaram mais rpido, e comearam a discutir alguns assuntos que haviam sido
tratados na etapa da manh. Nessa hora ficou evidente o desconforto de algumas pessoas
criticarem o trabalho e apontar as falhas de outras pessoas. Durante essa conversa alguns
pontos relativos a divergncias de processos entre os participantes foram tratados, bem
como alguns pontos relativos hierarquia. Notamos que a diviso em grupos menores pode
ser necessria durante algumas tarefas, a fim de evitar desconfortos e maior naturalidade e
honestidade nas respostas, principalmente quando h diferentes nveis hierrquicos
presentes.

A anlise dos dados levantados, feita antes da ltima reunio, mostrou que j havia bons
requisitos para a construo de um Data Warehouse, mas, alm disso, esses dados j
mostravam algumas informaes importantes como, por exemplo, os pontos de falha nos
processos, as reas pouco informatizadas e as necessidades gerais da DIR. Essa avaliao
dos problemas dos processos e da qualidade e do fluxo de dados poderia evitar que, caso o
90
sistema de Data Warehouse fosse implementado, pontos de falha importante no fossem
percebidos apenas em fases avanadas do projeto, provocando mais custos, demandando
maiores prazos e provocando desconfiana prvia dos usurios com o sistema.

Ao final dessa reunio, ainda houve alguns comentrios por parte dos participantes. Em
especial dois, um que demonstrou o possvel perfil de uso de uma ferramenta de Data
Warehouse pela DIR e o outro que demonstrou como o envolvimento de um usurio que
usa uma das tcnicas da Semitica grande.

Um dos participantes estava explicando a necessidade de controle de um talonrio
fornecido a mdicos para a prescrio de substncias controladas. Cada um desses
talonrios tem um nmero de srie e cada mdico que pega um desses talonrios pode ser
rastreado. Esse participante tinha interesse e achava bom fazer algumas correlaes entre o
tipo de droga prescrita e os mdicos, saber que determinado volume era prescrito, de qual
tipo, para quem, ou seja, gostaria de ter informaes para levantar se algum mdico estaria
fazendo prescries indevidas, em grande quantidade. Outro participante acredita que isso
no necessrio, pois a funo de fiscalizao havia sado das mos deles e eles no tinham
a obrigao de ver isso. Aqui podemos notar que, embora um participante esteja querendo
manipular as correlaes e tentar extrapolar novos dados, o outro no achava isso
necessrio para a execuo dos trabalhos, preferindo um mtodo de trabalho mais
formalizado e rgido. Assim, o perfil de uso da ferramenta por essas duas pessoas seria
bastante diferente. No estamos querendo dizer com isso que haja uma postura errada por
parte de algum dos usurios, mas apenas que pessoas encaram as informaes disponveis
de maneiras diferentes. Algumas pessoas, de posse de uma ferramenta de apoio a deciso,
iro apenas verificar alguns dados em relatrios padro, enquanto outras iro realmente
navegar nos dados e tentar achar novas correlaes de dados. As necessidades de todos os
usurios, inclusive como eles fazem a navegao dos dados, um requisito bastante
importante para a confeco de uma boa soluo de Data Warehouse.

O outro fato foi um comentrio de um participante ao final da reunio. Ele ficou parado,
olhando para os cartazes e depois de algum tempo se declarou surpreso, pois no esperava
91
encontrar tantos pontos de problema. Esse tipo de concluso muito bom, pois d idia do
grau de auto crtica que se consegue com esse tipo de trabalho. Somente esse tipo de
choque de realidade pode fazer com que as pessoas reajam e tenham desejo de perceber os
seus erros e trabalhar para corrig-los. Numa outra tcnica de elicitao de requisitos
usualmente empregada, esses problemas passariam a largo e afetariam com certeza a
percepo de qualidade final do sistema.

Normalmente o emprego das tcnicas do PAM rpido, mas o prprio perfil do grupo
estudado dificultava uma maior velocidade na elicitao dos requisitos. Por isso,
resolvemos tentar manter um horrio e tempo fixo para as reunies, para evitar que o
trabalho da DIR fosse prejudicado.

Reunio 3 Uso do Framework Semitico

Nessa reunio estavam presentes as pessoas consideradas mais importantes, a Diretora, as
Assistentes tcnicas e a analista de sistemas. Havia ainda mais uma participante, uma
coordenadora de rea. Como havia sido imposto que a reunio deveria acabar em
aproximadamente duas horas, tentei ao mximo que no houvesse desvios como os das
outras reunies, para manter o foco do assunto. Como material de apoio eu utilizei a escada
Semitica, e nos focamos nas trs camadas superiores, a semntica, a pragmtica e a social.

H alguns cuidados necessrios para o uso do Framework Semitico. O analista que est
participando dos workshops com os usurios das tcnicas anteriores, ao chegar nesse passo
deve ter uma boa idia de como o trabalho da organizao executado e quais os seus
maiores problemas. A Escada Semitica responsvel pela unificao das informaes
abrange todos os aspectos informais ainda no descritos, possibilitando assim a confeco
das tabelas-fato pelas separaes dos processos descritos na mesma.
Tendo em vista o universo de uma implementao de sistemas de apoio deciso (DSS,
uma outra terminologia para a classe de sistemas entre as quais se enquadram as solues
de Data Warehouse), podemos considerar cada um dos degraus da Escada Semitica da
seguinte forma:
92
Os trs degraus inferiores, o fsico, o emprico e o sinttico so de suma importncia para a
anlise de requisitos de software existentes na empresa, para a implementao final da
soluo. Com base nessas camadas, podemos definir quais as tecnologias preferidas da
empresa, quais os tipos de recursos computacionais que mais os agradam e quais sistemas
existentes na empresa podem facilitar a implementao. Essas informaes podem ser de
grande valia no momento de se definir qual tecnologia de implementao de Data
Warehouse deve ser utilizada, se ROLAP, MOLAP, ou qualquer outra.
Por outro lado, durante o processo de anlise inicial do sistema, quando se estuda a
viabilidade do sistema e suas caractersticas de negcio, o uso dessas trs camadas no
necessrio, podendo confundir o usurio leigo da rea de informtica. Assim sendo, nessa
fase inicial deve-se focar nos trs degraus superiores da escada; so eles:

Semntico: Essa camada explicita os significados, valores, cultura das entidades estudadas.
Consideramos essa camada muito importante para entendermos o mbito de linguagem e de
significados, tentando evitar, atravs de uma compreenso mais afinada das
particularidades de linguagem e de simbologia do grupo estudado, que o escopo de
entendimento da realidade estudada esteja errada. Em qualquer sistema computacional, mas
principalmente numa soluo como as solues de DSS, qualquer anomalia introduzida por
uma falta de entendimento pode causar danos irreparveis ao projeto, sistema e soluo,
como um todo. Aps as camadas de ETL e Dados estarem parametrizadas, qualquer
modificao ser extremamente custosa, incluindo custos operacionais, temporais,
transacionais e, talvez o mais importante, o custo introduzido pela perda de confiana dos
usurios na ferramenta e no processo e construo da soluo.

Pragmtico: Essa camada a mais importante de toda a anlise, pois trata das intenes
dos usurios com o sistema. Quando perguntados, os usurios podem dar uma gama
enorme de motivos para utilizar o sistema, diferentes formas de utilizao, com que tipos de
dados alimentar o sistema, etc. Mas nem sempre as reais intenes so mostradas. Muitas
vezes h interesses polticos, hierrquicos e operacionais que no constam dos modus
operandi oficial da empresa, mas fazem parte do dia a dia da operao. Podemos
exemplificar com a necessidade de um determinado setor se proteger de outro, atravs de
93
logs de operao e curvas de tendncia de resultados. Imaginemos que numa determinada
empresa haja um setor de logstica que falha em cumprir os prazos de entrega. De quem
realmente a culpa? Desse setor ou do responsvel por embalar o produto e disponibiliz-lo
para a entrega? Qual a real parcela de responsabilidade de cada setor? Qual a inteno de
um diretor, o que ele realmente quer ver na sua empresa? Se a empresa visa lucro, de que
maneira os responsveis pretendem controlar isso? Como podemos imaginar, h muitas
nuances de interpretao na maneira de trabalho das entidades e descobrindo as reais
intenes podemos dispor das informaes necessrias para cobrir essas necessidades.

Social: Essa camada representa a cultura da entidade, como ela se expressa e se comporta
dentro do mundo social. Apesar de Liu (2000) considerar essa camada independente,
Shanks e Corbitt (1999) consideram que ela extremamente relacionada com a camada
pragmtica, tanto que eles defendem que a camada social deveria ser englobada pela
pragmtica. Isso porque as suas intenes definem seu comportamento para o mundo, seja
esse comportamento real ou apenas interpretado como tal.

Cada uma dessas camadas foi dividida em duas colunas, representando a descrio de
assuntos tratados na camada e possveis solues para problemas apresentados, indicadas
pelos prprios stakeholders. Isso provoca uma anlise profunda por parte das entidades,
sempre lembrando que estamos estudando o mbito de uma ferramenta de DSS, os
principais problemas de interface de dados, as dificuldades mais comuns quando se
necessita de uma informao ou os problemas com a qualidade das informaes
apresentadas. As solues apresentadas pelos participantes do estudo representam a
maneira como a organizao pensa e trabalha. Os problemas so resolvidos com base na
maneira de trabalho da entidade e no h determinao externa para adequao de forma de
trabalho. Os dados e informaes dessa etapa servem como base para a construo da
soluo de Data Warehouse.

As camadas inferiores, segundo minha previso, foi apresentada e acabou no sendo
discutida, pois o pblico presente no era parte de uma equipe de projetos de software, no
tinham conhecimento tcnico para tanto. Alm disso, como a idia do uso do PAM nesse
94
momento era ter independncia de tecnologia, visando um mapa macro da soluo e o
estudo de possibilidade de implementao de uma soluo de Data Warehouse na DIR, as
camadas inferiores da escada eram de pouco relevncia naquele momento. Isso no quer
dizer que essas camadas no sejam importantes. Numa segunda etapa do projeto, aps a
deciso de implementao tomada, essas trs camadas sero de suma importncia para a
deciso da tecnologia de apoio para Data Warehouse a ser utilizada.
Como j foi dito, o uso do gravador parecia melindrar os participantes. Nas duas etapas
finais o gravador no foi utilizado, e foi feito um maior aproveitamento do material de
apoio. Os dados levantados nessa etapa constam no Anexo C.

Como era de se esperar, a parte que mais demandou debate foi a pragmtica. O degrau
pragmtico da escada gerou algumas dvidas, porque as intenes sempre so as mais
difceis. Os problemas que as coordenaes tm com os tcnicos foram bem retratados,
como podemos ver no Anexo C , mas houve muita dificuldade nisso.

Reunio 4 Uso da Anlise Colateral

Essa reunio foi utilizada para o uso da tcnica da Anlise Colateral. Mais uma vez foi
utilizada uma verso simplificada daquela proposta por Liu (2000), pois no haveria como
elicitar pontos operacionais como necessidades de backup e recuperao, nesse momento.
Apesar de o modelo completo ser extremamente importante para o desenvolvimento final
do sistema, durante a fase de elicitao inicial de requisitos e de estudo de viabilidade
podemos nos ater aos ciclos superiores, compreendidos por:

Ciclo de vida: Esse ciclo forma uma linha temporal com o sistema que est sendo
proposto como ponto central. Ela indica os sistemas predecessores, contextualiza o
sistema focal e indica um possvel sistema sucessor. Esse ciclo vai nos indicar o que
utilizado atualmente, qual a percepo dos usurios sobre o sistema proposto e
qual a inteno na implementao, onde eles gostariam de chegar no futuro.

Funcionamento: forma um ciclo de funcionamento do sistema focal, indicando as
95
suas entradas, suas sadas e a maneira como ele interage e transforma o ambiente,
recebendo como feedback as possveis modificaes exigidas por ele, na forma de
novas necessidades ou novas exigncias. Alm disso, fornece uma descrio do
sistema focal, fornecida pelos usurios, expondo a percepo deles sobre o sistema.

Com base em estudos anteriores, esperava mais uma viso geral de como os usurios
enxergavam o que estava sendo proposto. O resumo dos resultados pode ser encontrado no
Anexo D.

Apesar de no ser uma surpresa, a anlise colateral acrescentou alguns fatos e confirmou
outros. Um dos pontos que os usurios no colocaram no Quadro de Avaliao e que eu
considerei importante: em momento algum eles citaram oficialmente como fonte de dados
os sistemas existentes, o SIVISA e o SIAP. Apesar de falar de suas deficincias e
problemas, o grupo no pensou neles como uma fonte de dados. Essa situao foi corrigida
na Anlise Colateral, pois eles incluram como predecessor e como fonte de dados os dois
sistemas.

Tambm somando ao resultado, o grupo pela primeira vez durante a atividade colocou
dados mais aprofundados que desejariam ver, como os dados que gostariam de conhecer a
respeito dos tcnicos. Apesar de no ser extremamente relevante nesse momento do estudo
de viabilidade, esse fato d indcios de que o conjunto das tcnicas pode ser bem utilizado
em todos os momentos do ciclo de vida de um projeto de Data Warehouse, mesmo nas
fases de verificao e validao mais avanadas.

Considero que alm da facilidade de uso das ferramentas e do poder que elas tm para
conseguir elicitar os desejos e intenes dos usurios de forma clara, as reunies serviram
como sesses de auto crtica para o grupo estudado, forando um aumento da maturidade e
do entendimento de seus problemas. Um dos participantes, num determinado momento,
disse que as reunies pareciam muito com sesses de planejamento, o que no deixam de
ser. Mas para planejar necessrio reconhecer os seus objetivos, reconhecer seus defeitos e
saber aonde se quer chegar. Por isso, ao fazer uma avaliao real da sua condio atual, e
96
muito bem apoiado pelas tcnicas da Semitica, o grupo pde realmente entender as aes
que eles deveriam tomar e quais seriam seus reais objetivos.

5.4 Anlise dos resultados e desenho da soluo

De posse de todos os dados, o analista pode comear a desenhar os planos para o seu Data
Warehouse. A anlise de tudo o que foi levantado at o momento visou um levantamento
inicial da possibilidade de se fazer um Data Warehouse para uma empresa, tendo como
principal produto as suas tabelas-fato e dimenses, possveis entradas na camada de ETL e
avaliao da qualidade de dados na empresa, perfil dos usurios e aes necessrias
anteriores ao projeto. Com os dados levantados na DIR, foi possvel elicitar seus requisitos
para algumas dimenses e para as camadas de ETL, utilizando-se o modelo proposto. Para
um maior entendimento da forma de uso das ferramentas, sero descritas passo a passo as
avaliaes feitas para o resultado final.

A primeira etapa foi a de Anlise de Stakeholders. Essa etapa do processo visava dois
objetivos principais:

1. Garantir que todas as reas interessadas no processo participassem;
2. Conhecer as principais fontes de dados necessrias para as tomadas de deciso.

Analisando o resultado verificamos que, para elicitao inicial, era imprescindvel ao
menos um representante das seguintes reas:

1. Diretoria
2. Assistncia Tcnica
3. Cada uma das trs coordenadorias de rea
4. Tcnicos de cada rea
5. Protocolo
6. Sistemas de informao
97

Durante a anlise, todos concordaram que a presena dos tcnicos poderia ser substituda
pelos coordenadores de rea, pois os tcnicos no utilizariam diretamente o sistema, mas
sim alimentariam os dados dos sistemas fonte do Data Warehouse.

As fontes de dados levantadas foram:

SIVISA : Relatrios tcnicos e dados sobre os processos
SIAP: Dados sobre os processos e protocolo
Procon: Informaes sobre estabelecimentos e processos
Polcia: Informaes sobre estabelecimentos e denncias
Conselhos de classe: Informaes sobre estabelecimentos e denncias
Ministrio Pblico: Denncias, resolues e processos
Secretaria da Fazenda: Informaes sobre estabelecimentos
Imprensa: Denncias e Informaes gerais
Papis Gerais de processos da DIR

Apesar de tambm no terem sido colocados como fonte na anlise das partes interessadas,
durante esse processo pude elicitar vrias fontes de informao e dados que no estavam
autimatozadas em sistemas computacionais, como por exemplo as fichas de tempo dos
funcionrios e planilhas de disponibilidade de viaturas e outros insumos. Os prprios
usurios recolocaram esses problemas durante o Quadro de Avaliao, mas uma anlise
profunda nesse momento ainda indica que os dados de entrada e sada de processos, no
momento de entrada das requisies, apoiado pelo SIAP,mas ainda assim h fatos que no
so computados. Por exemplo, em momento algum h um registro de pessoas
encaminhadas de forma errnea por outras entidades, como a Prefeitura. Desse modo, ainda
como preocupao para a camada de ETL, teramos essas novas entradas no formatadas.
Essas informaes faltantes impactariam a implementao do sistema final e devem ser
trabalhadas em uma fase anterior ao Data Warehouse, para a adequao de processos e
disponibilizao desses dados. No caso especfico da DIR, h uma necessidade de
reengenharia de processos e um aumento do escopo de informaes dos sistemas existentes.
98
No caso das planilhas de ponto e de insumos, necessrio que sejam criadas rotinas de
carga, mesmo que essas cargas sejam apenas arquivos texto formatados. O importante no
caso criar um processo para a disponibilizao dessas informaes faltantes.

A Figura 20 representa as entradas dos dados na camada de ETL. Em fase posterior, caso o
sistema de Data Warehouse seja recomendado e aprovado, a primeira coisa que o analista
responsvel pelas interfaces de carga de dados do sistema deveria fazer um estudo
aprofundado da sinttica utilizada para cada um dos cdigos desses sistemas, e a
necessidade de transformaes para as cargas dos mesmos. Durante as reunies, quando
falei a respeito da sinttica, foi-me passada a regulamentao da portaria de lei que criou o
SIVISA, e nela estavam todos os cdigos e tabelas utilizados pelo sistema. De forma
bastante precisa os usurios entenderam a necessidade sinttica de um Data Warehouse e
puderam me prover de informao bastante precisa nesse aspecto.


Figura 20 : Sistemas fonte e Camada de ETL

99
Esse primeiro mapa formam o direcionamento inicial ao analista que far as interfaces para
quais as fontes de dados e quais problemas com os quais ele deve lidar.

A seguir, o analista deve analisar os resultados do Framework Semitico. Apesar de no ter
sido a tcnica imediatamente utilizada aps a Anlise de Stakeholders, essa ferramenta a
principal na anlise de requisitos. Isso porque dela pode-se inferir as reais intenes dos
usurios, aonde eles querem chegar com a anlise dos dados, quais os problemas que mais
dificultam seus resultados.

Analisando as intenes nos degraus pragmticos e sociais, percebemos que a grande
preocupao da DIR a qualidade e informaes de seus processos, que incluem pedidos
de licenas, liberaes de projetos, problemas investigativos de sade da populao, entre
outros. A camada semntica nos d vrias pistas a respeito de vrios problemas,
principalmente do cunho de formatao e homogeneizao de procedimentos e relatrios.
Desse modo podemos dizer que a principal tabela fato, o processo que melhor representa as
necessidades da DIR seria uma tabela fato onde ela pudesse acompanhar o ciclo de vida e
angariar informaes sobre os seus diversos processos. Assim sendo, temos a primeira
figura no nosso mapa do Star Schema. Como a DIR abre um processo administrativo para
todas as suas tarefas e pedidos de usurios, chamaremos a aplicao de Aplicao
Processos.


Figura 21 : A Aplicao elicitada

Tabela Fato:

Aplicao Processos
100
A anlise do Framework Semitico no necessariamente deve sugerir apenas uma
aplicao. Caso houvesse surgido mais algum processo crtico, mais processos seriam
includos, at atingir a totalidade das necessidades da DIR.

Agora iremos analisar todas as informaes das outras etapas do processo para
descobrirmos que dimenses so requeridas para o Data Warehouse. Uma anlise dos
resultados deve ser feita principalmente no Quadro de Avaliao, que ir nos indicar os
principais problemas enfrentados pelos usurios analisados.

Podemos elencar dos Quadros de Avaliao, problemas colocados pelos usurios que faam
sentido no escopo de um Data Warehouse. O ideal que esses problemas sejam
categorizados a fim de evitar redundncia de dados.

Com base no Quadro de Avaliao da Vigilncia, podemos fazer a seguinte diviso de
informaes necessrias, sempre visando a coluna das solues propostas pelo grupo de
trabalho:

1. Com quem est o documento;
2. Quantos documentos esto com qual tcnico/rea;
3. A quanto tempo est sem soluo/encaminhamento;
4. Onde ficou parado (gargalo);
5. Porque no teve encaminhamento (ex: por falta de viatura);
6. Melhor controle das empresas por projeto;
7. Melhor visibilidade dos casos por tcnico e controle de retorno dos das demandas
encaminhadas para os tcnicos (freqncia);
8. Disponibilizao de agendas de insumos ( recursos, como carros e equipamentos
especializados);
9. Acesso aos registros de produtos, pendncias e do histrico do produto;

101
Com essa lista de solues propostas pelos usurios, podemos verificar quais dimenses
sero necessrias para cobrir essas necessidades. fcil perceber que existem pontos de
mais ateno para a DIR, e podemos cobri-los com base nessas informaes. Fazendo a
anlise ponto a ponto:

1. O primeiro ponto indica a necessidade de um cruzamento entre o que vamos chamar
de PROCESSOS e os responsveis pelo ciclo de vida desse processo, que iremos
chamar de RESPONSVEL.
2. O segundo ponto indica a necessidade de um cruzamento entre PROCESSOS,
REAS e TCNICOS.
3. O ponto 3 indica a necessidade de histrico, precisando verificar o TEMPO x
PROCESSOS.
4. A necessidade de onde ficou parado, pode ser inferida com base no resultado da
query entre PROCESSOS e RESPONSVEL, no necessitando de uma dimenso
nova para isso.
5. O porqu no teve encaminhamento depende de como vai ser a anlise, se por um
relatrio ou pelo estudo de uma query entre TEMPO, PROCESSO,
RESPONSVEL e INSUMO. Como a ltima opo possibilita maior flexibilidade
em caso de necessidade de mudana, vamos escolher esse caminho.
6. O ponto nmero 6 indica a necessidade do cadastro dos ESTABELECIMENTOS,
e de sua correlao com os PROCESSOS existentes.
7. O ponto de nmero 7 mostra a necessidade de uma correlao entre TEMPO,
PROCESSOS e TCNICOS.
8. A agenda de INSUMOS deve ser correlacionada, pelo menos, com os TCNICOS
e com TEMPO.
9. O ponto 9 especifica a necessidade de uma dimenso PRODUTO, que deve ser pelo
menos o histrico desses produtos.

Aps o levantamento desses itens, fomos capazes de inferir as dimenses necessrias para a
aplicao de processos da DIR, que resumindo so:

102
PROCESSOS
RESPONSVEL
REAS
TCNICOS
TEMPO
ESTABELECIMENTOS
INSUMO
PRODUTO

A representao dessas oito dimenses no Star Schema fornece o mapa de implementao
inicial do Data Warehouse que queremos. A sua visualizao grfica, usualmente utilizada
nos projetos de Data Warehouse ficaria da maneira representada pela Figura 22.

Figura 22 : A aplicao e suas dimenses

103
Assim, a representao bsica do Star Schema est feita, com todas as dimenses
escolhidas para a aplicao Processos.

Alm da base do Star Schema, podemos tambm inferir algumas outras informaes. A
chave de cada tabela sempre precisa estar presente, para permitir a correlao entre as
dimenses. O estudo do Quadro de Avaliao e da Anlise Colateral tambm nos d
algumas pistas do caminho que o usurio deseja seguir. Verificando a parte de
funcionamento da Anlise Colateral, pode-se perceber quais dados realmente os usurios
querem presentes e assim temos um indcio para o projeto das tabelas do banco de dados ou
da representao multi-dimensional. No caso da DIR, podemos associar vrias informaes
desejadas no ciclo de entrada da camada de funcionamento diretamente tabela-fato e s
dimenses.

Exemplos desses dados so encontrados para estabelecimentos onde so pedidos Razo
Social, Nome Fantasia, CNPJ, Endereo, Tipo de Estabelecimento/Atividade, CNAE
fiscal,Responsvel Legal, Responsvel Tcnico.

Todos esses campos de dados podem ser levados diretamente para a tabela fato, e depois
distribudos entre as dimenses conforme as necessidades das dimenses. A figura 23
mostra o Star Schema com algumas dessas informaes complementares.
104


Figura 23 : As dimenses com chaves primrias e informaes necessrias

O resultado demonstrado pelo mapa do Star Schema bem acima do esperado, pois alm
das dimenses algumas necessidades de dados j foram preenchidas. As lacunas ainda
existentes seriam sanadas numa etapa de projeto pela anlise dos dados existentes nos
sistemas fonte e por outras etapas de elicitao de requisitos mais aprofundadas, quando
seriam definidos todos os dados necessrios e seus metadados, formando assim a estrutura
completa do Star Schema.

Baseando-se nesse resultado, tambm podemos inferir alguns potenciais problemas de falta
de informao e de dificuldade de carga. Segundo o que foi elicitado no Quadro de
Avaliao, as seguintes informaes esto dispersas, no existem ou no esto
imediatamente disponveis:

Relatrios de outras DIR: Os sistemas das DIR no so centralizados, todos eles
baseados em sistemas locais. Quando h a necessidade de troca de informaes, h
105
a centralizao dos dados no CVS, aps o envio dos novos arquivos do ms. Como
um Data Warehouse no um sistema transacional, ou seja, no h maiores
problemas com um certo lapso temporal nas informaes, isso no seria impeditivo
ao sistema, mas um acordo prvio deve ser feito para a distribuio desses dados
aps a sua consolidao central. Essa necessidade fica clara no que foi explicado
numa reunio, exemplificando que muitas vezes uma determinada indstria tem a
central dentro da jurisdio de uma DIR, mas uma filial na jurisdio de outra.
Desse modo, as informaes relativas aos processos entre as empresas das DIR
devem ser compartilhadas para possibilitar o estudo das situaes das empresas.
As informaes dos dados da Fazenda, como o cadastro fiscal da empresa;
Sem a implementao de um sistema de workflow, no possvel saber exatamente
quais as reas de gargalos dos processos. possvel com base em datas fazer um
acompanhamento, mas ele no ser totalmente confivel;
Algumas das informaes ainda no esto em sistemas computadorizados e ainda
necessitariam de algum processo extra para a carga dos dados, como: carto de
ponto dos tcnicos, agenda das viaturas e outros equipamentos, informaes
provenientes do expediente que ainda no so computadas, como a quantidade de
pessoas com encaminhamento errado da prefeitura.

Alm do desenho do Star Schema, a anlise dos dados gerados pelo emprego das
ferramentas nos indicou uma srie de subprodutos que no eram esperados a princpio, mas
extremamente desejveis. Os resultados indicam uma forte tendncia auto-crtica, e esse
exerccio faz com que os usurios tomem conscincia de problemas a serem resolvidos. Um
fato muito interessante observado aconteceu durante a terceira reunio, e o resultado pode
ser visto na parte de sucessores do ciclo de vida no efeito colateral, no Anexo D.

Durante a reunio 3, ao relatarem as dificuldades que eles tm com os tcnicos, vrios
casos foram relatados, a maioria onde os tcnicos tiveram dificuldades em termos de prazo
e qualidade de relatrios. O grupo pensou em possveis solues e sem conhecimento
prvio, deram a descrio de um sistema que desse uma tarefa a uma pessoa e avisasse
quando essa tarefa no estava feita no prazo e que quando esse tcnico mandasse o relatrio
106
houvesse a possibilidade de uma etapa de reviso desse relatrio. Ou seja, eles
simplesmente descreveram um processo de workflow com edio de tarefas e com ciclo de
vida de aprovao de documento. Esse resultado surpreendente, principalmente porque
eles nunca haviam ouvido falar de solues de workflow. Expliquei a eles do que se tratava
no final da sesso, tanto que nos resultados do Quadro de Avaliao aparece um tem como
soluo Organizar e inferir um sistema de cobrana de resultados. Eles notaram que no
havia um padro de avaliao para os relatrios, sendo as notas dos mesmos bastante
subjetivas. Com isso, somente nessa reunio foi elicitada a necessidade de uma ferramenta
de workflow, uma base de seu funcionamento e como seria o processo de recusa ou
aprovao de um documento.

Aps essa anlise, verificamos que com a ajuda do ferramental Semitico fomos capazes
de:
Definir quais os principais atores para a elicitao de requisitos inicial;
Definir as principais fontes de dados para as camadas de ETL;
Definir os processos necessrios para os usurios;
Definir quais as dimenses seriam necessrias para esses processos;
Desenho do esquema macro do Star Schema;
Definir alguns dados de entradas importantes nas dimenses do Star Schema;
Definir quais dados necessrios para a aplicao elicitada no so gerados por sistema
algum.


5.5 Consideraes sobre o resultado

Antes do incio do trabalho com os usurios, a inteno principal era conseguir verificar
se seria possvel, utilizando-se as ferramentas propostas na Semitica Organizacional,
conseguir uma boa definio inicial para o desenvolvimento de uma soluo de Data
Warehouse para a entidade escolhida para o estudo de caso. Os resultados esperados, em
um primeiro momento, eram:
107

Definio do grupo de pessoas interessadas cujos interesses seriam elicitados;
Definio das principais fontes de dados;
Definio das aplicaes e de suas dimenses.

Todos os objetivos acima foram alcanados. A Anlise de Stakeholders mostrou-se uma
ferramenta eficaz para essa tarefa, sendo capaz de evitar que grande parte de uma soluo
fosse desenvolvida sem que alguma entidade participante do processo fosse contactada. Do
mesmo modo, essa mesma atividade d uma boa idia de quem realmente necessita das
informaes e deve participar, inclusive indicando substituies de pessoas e grupos, como
aconteceu no caso dos tcnicos sendo representados pelas coordenadorias de grupo. Esse
resultado muito importante para o ciclo de desenvolvimento de um Data Warehouse, pois
como j comentamos, o pblico alvo dessas solues geralmente de difcil acesso,
dificultando o processo de elicitao como um todo. Com essa possibilidade de
substituio, pode-se garantir uma maior flexibilidade das reunies e garantir o mnimo de
andamento no projeto, sem ficar dependendo muito de um grupo especfico de pessoas.
Da mesma maneira, a Anlise de Stakeholders tambm influenciou muito num dos maiores
problemas referentes a levantamento de dados de um Data Warehouse. Um Data
Warehouse um sistema para informaes de apoio a deciso, ou seja, no necessita ter
todas as informaes de todos os sistemas, e sim um nvel de informaes consolidadas. H
um limite prtico para a quantidade de informaes que se deve carregar em um Data
Warehouse, pois uma grande quantidade de informaes pode provocar uma grande queda
de performance e um tempo de carga muito grande. Qualquer dado no gerencial ou de
baixa granularidade deve ser procurado nas fontes transacionais. Geralmente, quando se
pergunta a um usurio que dados ele gostaria de ter no Data Warehouse, a resposta algo
do tipo tudo que est no sistema X. Com o uso da Anlise de Stakeholders e do Quadro
de Avaliao, essa pergunta no colocada diretamente para o usurio, e o exerccio de
brainstorming fez com que uma crtica saudvel ao sistema fosse feita e que se separasse as
reais necessidades de dados. Com isso, uma soluo mais enxuta do que se geralmente se
consegue possvel.

108
Como colocado no captulo 2, so consideradas duas as maiores dificuldades para a
elicitao de requisitos para solues de Data Warehouse: A dificuldade dos usurios em
entender e articular as suas necessidades e a dificuldade dos tcnicos e usurios se
entenderem e fazerem um trabalho conjunto. Essas duas dificuldades foram claramente
endereadas pela Semitica Organizacional nesse estudo de caso, pois os usurios ao
mesmo tempo em que articulavam suas reais necessidades auxiliados pelas tcnicas da
Semitica, tambm permitiam ao analista entender a sua real necessidade e compreender
seus jarges e mtodos de trabalha. O resultado final, apresentado como o modelo em Star
Schema, o que um analista necessita para dar andamento ao projeto de implementao,
pois apresenta al toda a base do desenvolvimento, ou seja, as aplicaes e dimenses.

Todas as principais fontes de dados foram elicitadas com o auxlio das tcnicas e tambm
com o uso integrado delas foi possvel a definio da aplicao necessria e de suas
dimenses.

Alm desses resultados, alguns outros tambm importantes foram conseguidos. Como
colocado na seo de objetivos, o principal resultado desse estudo seria a verificao do uso
das ferramentas da Semitica para avaliar os requisitos iniciais de uma empresa para uma
soluo de Data Warehouse. Seria como uma verificao de pr-projeto, qualificando
inicialmente a empresa para o uso da soluo. Para isso no seria necessrio realmente
chegarmos a um desenho em profundidade do projeto, mas sim uma especificao inicial
que servisse como guia para as etapas subsequentes. Esse objetivo foi plenamente
alcanado e ainda obtivemos algumas informaes no esperadas.

As principais foram sem dvida o levantamento dos dados necessrios mas no disponveis
e o nvel de maturidade processual e computacional da empresa. A indicao de quais
dados no esto disponveis um resultado colateral muito bom, pois eles indicam de
forma bastante precoce quais sero os problemas de coleta de dados que sero encontrados
durante fases mais avanadas do projeto. Desse modo pode-se planejar quais aes sero
necessrias para que essas falhas sejam sanadas. Lembrando que, como um Data
Warehouse uma soluo orientada a dados, esse tipo de problema, caso no tenha uma
109
soluo simples ou em tempo hbil, pode inviabilizar um projeto. Dependendo da fase em
que se encontre, isso pode significar o desperdcio de anos de desenvolvimento e muitos
recursos financeiros e de pessoal. Assim, podemos dizer que esse resultado, apesar de no
ter sido um objetivo principal do estudo, extremamente bem vindo e necessrio. Tambm
pde ser facilmente percebido o contexto geral de uso da aplicao pelos usurios e, se
fssemos classific-los segundo os tipo de usurios indicados por Inmon(1996), eles seriam
basicamente usurios do tipo Fazendeiro, ou seja, que se mantm verificando os processos
normais e no procuram correlaes mais amplas. Essa informae seria bastante til em
etapas posteriores ao trabalho, para a confeco da interface para usurios.

Outro ponto bastante importante foi o aumento da crtica dos participantes pelo seu
processo, exemplificado pela percepo deles da necessidade de um sistema de workflow.
Apesar de os usurios terem colocado o workflow como um sistema sucessor ao Data
Warehouse, na verdade ele deveria ser um antecessor. Os dados desse sistema deveriam ser
carregados no Data Warehouse e seriam uma fonte de dados muito importante para o
acompanhamento gerencial da DIR.

Com isso, a possibilidade de se fazer uma avaliao correta da possibilidade de sucesso da
implementao muito grande. No caso especfico estudado, devido a problemas de dados
e de processos, seria necessrio ainda um ajuste para que a entidade tivesse maturidade o
suficiente para a implemetao de um Data Warehouse. Os resultados do levantamento
serviriam de guia para essa adequao e se evitaria assim o fracasso do projeto, o
desperdcio de recursos e o aumento da insatisfao dos usurios com as implementaes
dos sistemas de informtica.

Verificando o resultado final, podemos ver que o objetivo inicial foi plenamente alcanado,
inclusive sendo possvel uma maior definio dos dados nas dimenses e na tabela fato do
que era esperado. O uso das tcnicas da Semitica apenas no deram pistas em relao ao
nvel de detalhamento e granularidade dos dados requeridos pelos usurios, mas esse tipo
de informao necessria durante o modelamento final do banco de dados e das camadas
de carga.
110

A maior dificuldade que foi sentida na implementao da tcnica foi o foco do usurio nas
questes de fluxo e qualidade de dados. Era comum, durante as reunies, que o assunto
fosse desviado para outros problemas ou facetas dos processos normais da entidade
estudada, como por exemplo necessidades de novas contrataes, treinamentos, posturas de
profissionais e outros assuntos que apesar de influenciarem no processo de atendimento da
DIR no seriam tratados por uma soluo de Data Warehouse. Apesar desses fatos tambm
trazerem importantes informaes, isso pode causar um aumento excessivo do tempo de
reunio e pode dificultar o alcance das metas principais. No caso estudado, isso pode ter
sido ocasionado pelo perfil das pessoas que participaram do grupo, ficando esse ponto para
um estudo futuro.

As quatro tcnicas utilizadas foram de grande valia para o levantamento dos requisitos
iniciais, mas um fator importante no foi detectado durante o estudo de caso. A camada de
ETL, como foi explicado anteriormente, responsvel pela agregao dos dados e pela
granularidade das informaes que sero carregadas no Data Warehouse, e esse deve ser
preparado para os nveis de Drill-Down necessrios. Muito pouco se falou a respeito da
necessdade dos histricos e dados e a nica ferramenta que fez com que os usurios
falassem dos nveis de granularidade foi a anlise colateral, ainda que rapidamente. Uma
maior verificao nesse aspecto torna-se importante para o uso do ferramental em fases
mais avanadas do processo.

Apesar desses problemas apontados, as ferramentas so uma opo bastante vlida para o
levantamento de requisitos iniciais de um Data Warehouse. Outras ferramentas da
Semitica Organizacional, como o Framework Antropolgico, Diagrama de Ontologia e
Anlise de Normas, que no foram utilizadas podero teis durante uma fase mais avanada
da anlise, quando ser possvel discutir aspectos tcnicos e de projeto mais avanados.
111
Captulo 6
Consideraes Finais e Trabalhos Futuros

Aps a anlise dos resultados evidenciados no Captulo 4, podemos dizer que os objetivos
iniciais dessa monografia foram plenamente alcanados. O modelo de uso das tcnicas da
Semitica Organizacional proposto pode facilmente ser reproduzido em qualquer projeto de
solues de Data Warehouse para a etapa inicial de elicitao de requisitos. Dentro dos
resultados conseguidos esto:

A escolha dos usurios necessrios para uma boa elicitao dos processos a serem
includos no Data Warehouse;
Definio das fontes de dados necessrias para o apoio aos processos desejados
pelos usurios;
Definio dos diagramas do Star Schema, contendo as tabelas-fato e dimenses
necessrias.

No decorrer do estudo de caso ainda fomos capazes de observar a maneira como os
usurios reagiam em relao s tcnicas da Semitica Organizacional em diversos cenrios,
como, por exemplo, a maneira pela qual diferenas hierrquicas dentro dos grupos de
trabalho poderiam influenciar no resultado. Outro importante ponto evidenciado durante o
estudo de caso foi o crescente entendimento dos usurios em relao ao seus prprios
processos, permitindo auto-crtica e evoluo da maneira de trabalho, alm de permitir que
falhas do processos fossem mapeadas e discutidas.

Um resultado importante, alm do desenho final do Star Schema e da sequncia de tcnicas
sugeridas no captulo 5, foi a determinao da maturidade da empresa para o uso de uma
ferramenta de Data Warehouse, diminuindo o risco de uma implementao fracassada. No
estudo de caso feito, constatamos que uma soluo de Data Warehouse para DIR pode ser
ainda prematura, dado o estgio em que se encontra em termos de fluxo de informao. Seu
112
processo poderia evoluir mais com a implementao de uma ferramenta de workflow, como
notado pelos prprios usurios e melhor determinao de alguns fluxos de processos e
aumento da qualidade de dados existentes nos sistemas atuais. Aps alguns ajustes em seus
processos atuais o desenvolvimento da soluo de Data Warehouse seria mais fcil e menos
custoso. Entre as sugestes de melhoria esto:

Determinao de uma poltica de qualidade para a confeco de relatrios dos
tcnicos;
Ampliao das informaes contidas na ferramenta SIAP, para facilitar o estudo do
perfil de pblico da DIR;
Melhor acompanhamento do ciclo de vida dos processos administrativos, se
possvel com o auxlio de uma ferramenta de workflow;
Uma auditoria de qualidade nas informaes migradas para os sistemas de uso atual,
para diminuir as inconsistncias de dados;
Implementao de controles computadorizados para insumos e horrios de tcnicos.

Como proposta de trabalhos futuro, est a implementao total de uma ferramenta de Data
Warehouse utilizando-se como apoio as tcnicas da Semitica Organizacional, includas as
que no foram utilizadas nesse trabalho como o NAM e SAM. Dentro de um projeto de
implementao demorado e dinmico como o de uma soluo de Data Warehouse,
acreditamos que essas tcnicas sero de grande valia nas seguintes etapas do processo:

Definio da melhor tecnologia de implementao para o escopo da empresa;
Definio das interfaces de navegao para os usurios;
Definio das regras de negcio formais da empresa;
Definio das regras de extrao e transformao da camada de ETL,
permitindo a consistncia e homogeneizao dos dados;
Definio das regras de Drill-Down;
Definio dos nveis de granularidade de dados.

113
Ao final de um estudo de implementao de uma ferramenta de Data Warehouse, seremos
capazes de verificar se as tcnicas propostas pela Semitica Organizacional sero to
efetivas para etapas mais avanadas no processo de desenvolvimento quanto foram para a
elicitao inicial de requisitos.
115

Referncias Bibliogrficas

Anahory, S., Murray, D., Data Warehousing in the real World a Practical Guide for
Building Decision Support systems, Addison-Wesley Publishing 1997 apud Bruckner, R.
M., List, B.,Schiefer, J., 2001, Developing Requirements for Data Warehouse Systems with
Use Cases, Seventh Americas Conference on Information Systems, pg. 329.

Barthes, R., 1964. Elements of Semiology. London: Jonathan Cape apud Chandler, D.,
2000, Semiotics for Beginners. Hypertexto disponvel em
http://www.aber.ac.uk/media/Documents/S4B/semiotic.html. Acessado em novembro
2005.

Bruckner, R. M., List, B.,Schiefer, J., 2001, Developing Requirements for Data Warehouse
Systems with Use Cases, Seventh Americas Conference on Information Systems, pg. 329.
Chandler, D., 2000, Semiotics for Beginners. Hypertexto disponvel em
http://www.aber.ac.uk/media/Documents/S4B/semiotic.html. Acessado em novembro
2005.

Dale, M., 2004, Defining User requirements for a Large Corporate Data Warehouse: An
Experiential Case Study. AWRE'04 9th Australian Workshop on Requirements
Engineering, pg. 5.1.

Giannocaro, A.,Shanks, G.,Darke, P., 1999, Stakeholders Perceptions of Data Quality in a
Data Warehouse Environment. Proc. 10th Australian Conference on Information Systems,
pg. 344.

Gorla, N., 2003, Features to Consider in a Data Warehouse System. Communications of the
ACM. Novembro 2003/Vol.46, pg. 111.
116
Inmon, W.H., 1996. Building the Data Warehouse. Wiley & Sons.

Inmon, W.H., ND a. Data Warehouse and Data Mining. [Web], disponvel em
http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H.,ND b. Definition of a Data Warehouse. [Web], disponvel em
http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H., ND c. Gathering DSS/Data Warehouse Requirements. [Web], disponvel em
http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H.,ND d. The Data Warehouse Evolution Into the Millenium. [Web], disponvel
em http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H., ND e.The Problem with Dimensional Modeling. [Web], disponvel em
http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H., ND f. What is a Data Warehouse? [Web], disponvel em
http://www.inmongif.com/ [Consultado em setembro 2004].

Inmon, W.H.,Terdeman, R.H., Imhoff, C.,2001,Data Warehousing, Berkeley Brasil
Kimball, R., 1998, Data Warehouse Toolkit, Makron Books do Brasil.

Liu, K., 2000, Semiotics in Information Systems Engineering. Cambridge University Press.
Cambridge.

Mancuso, G.,Moreno, A.,2002, The Role of OLAP in the Corporate Information Factory.
DM review, disponvel em www.dmreview.com.

McFadden, F. R., 1996, Data Warehouse for EIS: some Issues and Impacts. Proc. of the
29th Annual Hawaiian International conference on system sciences. Pg. 120.
117
Morris, C. W., 1970, Foundations of the Theory of Signs. Chicago: Chicago University
Press. Apud Chandler, D., 2000, Semiotics for Beginners. Hypertexto disponvel em
http://www.aber.ac.uk/media/Documents/S4B/semiotic.html. Acessado em novembro
2005.

Moss, L.,Barbusinski, L.,Rehm, C.,Oates, J., 2004, Ask The Experts, Forum pblico pela
dmreview, disponvel em http://dmreview.com/. [Consultado em julho 2005].

OSW (1995) "The circulation Document". Organizational Semiotics Workshop. Apud Liu,
K., 2000, Semiotics in Information Systems Engineering. Cambridge University Press.
Cambridge.

Paim, F., 2003, Uma Metodologia para Definio de Requisitos em Sistemas Data
Warehouse. Dissertao de Mestrado. Universidade Federal de Pernambuco.

Paz, L.C., Cielo, I.,1999-2000, DW!, disponvel em http://www.datawarehouse.inf.br/
acessado em outubro 2004.

Peirce, C.S., (1931-58): Collected Writings (8 Vols.). (Ed. Charles Hartshorne, Paul Weiss
& Arthur W Burks). Cambridge, MA: Harvard University Press apud Chandler, D., 2000,
Semiotics for Beginners. Hypertexto disponvel em
http://www.aber.ac.uk/media/Documents/S4B/semiotic.html. Acessado em novembro
2005.

Price, R. J.,Shanks, G.,2004, A Semiotic Information Quality Framework. Decision
Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International
Conference 2004, pg. 658.



118
Saussure, F.,1983, Course in General Linguistics (trans. Roy Harris). London: Duckworth
apud Chandler, D.,2000, Semiotics for Begginers. Hypertexto disponvel em
http://www.aber.ac.uk/media/Documents/S4B/semiotic.html. Acessado em novembro
2005.

Shanks, G,,Corbit, B.,1999, Understanding Data Quality: social and Cultural Aspects. Proc.
Of the 10th Australian Conference on Information Systems.pg. 785.

Shanks, G,,O'Donnell, P.,Designing a Data Warehouse: Combining Entity Relationship and
Dimensional Modeling. White Paper, Monash University, Australia.

Simoni, C.A.C.,2003, A Prtica do Desenvolvimento de Software e a Abordagem da
Semitica Organizacional, Dissertao de Mestrado. Unicamp.

Simoni, C.A.C.,Baranauskas, M.C.C.,Da Anlise de Requisitos ao Projeto de Interface:
uma Abordagem Subjetivista para Sistemas de Informao. Universidade Estadual de
Campinas, Unicamp.

Stamper, R.K., 1973, Information in Business and Administrative Systems. John Wiley and
Sons, New York apud Liu, K., 2000, Semiotics in Information Systems Engineering.
Cambridge University Press. Cambridge.

Stamper, R.K., 1993, Social Norms in requirements analysis an Outline of MEASUR. In
Jirotka, M., Goguen, J. and Bickerton,M., Requirements Engineering, Technical and Social
Aspects. Academic Press, New York apud Simoni, C.A.C.,2003, A Prtica do
Desenvolvimento de Software e a Abordagem da Semitica Organizacional, Dissertao de
Mestrado. Unicamp.

Winter, R., Strauch, B., 2004, Information Requirements Engineering for Data Warehouse
Systems, ACM Symposium on Applied Computing, pg. 1359.

119
Winter, R., Strauch, B., 2003, A Method for Demand-driven Information Requirements
Analysis in Data Warehousing Projects. Proceedings of the 36th Hawaii International
conference on System Sciences, IEEE 2003.

121
Anexos

Anexo A Documento da DIR

A administrao pblica, em especial o setor sade, desde a dcada de 80, vem passando
por um processo de mudanas estruturais e conceituais, alcanando o ponto de maior
representatividade do movimento da reforma sanitria na VIII Conferncia de Sade em
1986, frum impar que reuniu todos os seguimentos representativos da sociedade que,
preocupados com os resultados, forma da estrutura, funes que do sistema de sade
vigente (modelo autoritrio e centralizador), conseguiram consolidar e aprovar propostas
resultantes das discusses que aconteciam nas universidades e na sociedade organizada, que
respaldaram a Constituio Federal de 1988, marco divisor dessas transformaes,
definindo que o setor sade deve organizar-se num Sistema nico de Sade SUS.
O ano de 1983 marcou o incio da democratizao do pas, no Estado de So Paulo
assume como 1 governador eleito pelo povo o Dr. Andr Franco Montoro tendo como
secretrio da Sade o Dr. Joo Yunes, com a seguinte proposta: No me proponho
governar como se fosse possvel e fcil resolver, da noite para o dia, a crise que
atravessamos. Mas sei que grande o potencial de recursos humanos e produtivos de nosso
Estado, e conheo a capacidade de trabalho dos brasileiros que aqui vivem. Se unirmos So
Paulo em torno da idia generosa de um desenvolvimento baseado em nossos prprios
recursos um desenvolvimento cujo centro seja a pessoa humana iniciaremos um
movimento de transformaes sociais e polticas que h de marcar uma gerao, em nosso
Estado e no Pas. MONTORO (1987)
A Secretaria do Estado da Sade em 1986 acreditando na reforma sanitria pregada
h muito pelos sanitaristas e que ganhou fora na 8 Conferncia de Sade, fez uma reforma
administrativa organizacional mudando radicalmente o Organograma da Secretaria,
preparando-se para o Sistema Unificado e Descentralizado de Sade atual SUS.
A estrutura da Secretaria do Estado da Sade vigente na poca datava de 1969
(Decreto n 52.182, de 16 de julho de 1969) era fracionada em diferentes organizaes,
122
vrios centros de decises que trabalhavam vinculados ao poder central, modelo
centralizador do perodo de exceo. Compreendia: Conselho Estadual de Sade, Gabinete
do Secretrio de Estado, Conselho Tcnico-Administrativo, Grupo de Planejamento
Setorial, Consultoria Jurdica, Departamento Tcnico Normativo, Coordenadoria de Sade
da Comunidade, Coordenadoria de Assistncia Hospitalar, Coordenadoria de Sade Mental,
coordenadoria de Servios Tcnicos Especializados, Departamento de Administrao da
Secretaria.
Os pressupostos da reforma sanitria j estavam colocados. As mudanas tinham
que ser transformadoras e abranger toda a Secretaria da Sade. O Decreto n 25.519, de 17
de julho de 1986 trazia a nova estrutura com mudanas profundas, voltando a administrao
para uma lgica organizacional, estabelecendo rgos centrais que fossem tcnicos,
operacionais. Acabava-se com as Coordenadorias e criavam-se os Escritrios Regionais de
Sade Ersas, responsveis pela integralidade da sade em sua rea de abrangncia.
A Vigilncia Sanitria padecia dos mesmos males da estrutura da Secretaria da
Sade, era uma vigilncia departamentalizada, centralizadora, cartorial, burocrtica,
extremamente policialesca, no integrada, fracionada, no existia uma viso da ao
integrada de processo de trabalho. Desde sua criao at 1985, mais de quarenta anos,
muito pouco se sabe sobre este perodo, no existem registros e as informaes perderam-se
junto com os funcionrios.
Em 1985/1986 conhecia-se a razo de mudar e o que se quer mudar. Criou-se o
Centro de Vigilncia Sanitria CVS (Decreto 26.048, de 15 de outubro de 1986), rgo
normativo subordinado diretamente a Secretaria da Sade.
O Municpio de So Paulo dadas s dimenses territoriais foi dividido num primeiro
momento em 8 (oito) ERSAS Escritrios Regionais de Sade. Em 1995 nova
modificao estrutural dividiu a cidade em 5 ncleos regionais de sade - os NRS de 1 a 5,
subordinados a Diviso Regional de Sade I DIR I (Decreto n 40.082 e Decreto
40.083, de 15 de maio de 1995).
Em 1995 h nova mudana de governo, sa o governador Fleury e assume o Dr.
Covas. Na Vigilncia Sanitria existiam muitas dificuldades, resqucios do velho modelo
conviviam com o novo, ainda de maneira prevalente, havia uma forte reao a
123
descentralizao, a municipalizao, com forte resistncia ao trabalho de equipe
multidisciplinar.
Em particular na Capital de So Paulo, a Secretaria reconhecia em 1995 o resultado
insatisfatrio das aes de vigilncia sanitria, com muitas denncias e uma crescente
insatisfao dos usurios do servio, com graves problemas gerenciais dessas aes.
A VISA Capital passou por transformaes, mudana de diretores, caminhou na
mudana do modelo, na lgica das aes enfocadas na avaliao de risco.
Em 2003 a VISA Capital passou por uma modificao radical na organizao fsica e
funcional quando os cinco ncleos regionais de vigilncia sanitria, cada um com um perfil
scio-econmico e uma vocao predominante foram unificados e centralizados num
mesmo endereo. Cada Ncleo Regional dispunha de equipes tcnicas auto suficientes que
executavam as mesmas aes cada qual em sua rea de abrangncia.
Esta autonomia trazia muitas dificuldades, pois no existiam padronizaes de
procedimentos, as informaes prestadas aos usurios eram diferentes de acordo com a
regio da cidade. No existia superviso sistemtica pelo rgo central e as disparidades de
situaes encontradas indicavam a necessidade de reformulaes.
A centralizao exigiu a reorganizao das equipes e uma nova organizao e diviso de
trabalho.
Num primeiro momento isto foi muito traumtico, primeiro porque no houve preparao,
todos foram pegos de surpresa e a mudana se deu de maneira improvisada, em tempos
diferentes. A mudana fsica dos cinco ncleos demorou quatro meses para se efetivar e
quando se consolidou os tcnicos queriam a continuidade da situao anterior, o que
obviamente no era possvel.
A resistncia s mudanas foi muito forte, a nova proposta de se trabalhar por rea de
interesse dentro da totalidade da rea de abrangncia (municpio de So Paulo) melindrou
muitos profissionais que estavam acostumados com seu diretor e um espao urbano
delimitado, para romper a lgica de trabalho anterior foi muito desgastante e requereu
muitas reunies tcnicas.
No havia mais domnio do territrio, os grupos foram reformulados, e tiveram que se
recompor em equipes para novos desafios.
124
Na Vigilncia Sanitria todas estas mudanas que ocorreram nos ltimos dez anos, tanto de
paradigma como de localizao fsica, prejudicaram a organizao de dados, muitas
informaes foram perdidas ou polarizadas em arquivos sem controle. Cada Ncleo
registrava as informaes de uma maneira, alguns utilizavam um programa de cadastro e
registravam aleatoriamente, outros utilizavam fichas e livros para faz-lo. Diante da
situao foi necessrio pensar num sistema que trouxesse as informaes mnimas
necessrias. Foi desenvolvido o SIAP Sistema de Informao ao Pblico que embora
esteja em rede para consulta dos funcionrios, padece de problemas, pois os antigos
sistemas foram transportados para o novo com todas as discrepncias, o que dificulta a
consulta pela no padronizao dos dados.
Somente em setembro de 2003 teve incio a sistematizao das informaes com o
cadastramento dos dados das empresas no SIVISA Sistema de Informao em Vigilncia
Sanitria, ou seja, h dois anos a equipe est se familiarizando com o sistema e cadastrando
todas as informaes em rede.
Em Abril de 2004 as aes de baixa e mdia complexidade foram municipalizadas ficando
sob a responsabilidade da VISA Capital as aes de alta complexidade, de acordo com o
rito constitucional.
A Secretaria de Estado da Sade passa por uma reestruturao a semelhana do que ocorreu
em 1986, preparando-se para a funo primordial de gestor estadual, uma vez que o maior
municpio do Estado assumiu parte das aes de vigilncia sanitria, todas as aes de
vigilncia epidemiolgica, a integralidade da Assistncia Bsica. A nova estrutura tem a
caracterstica de centralizar a coordenao de atividades correlatas ou similares num rgo
objetivando a otimizao, transparncia e o controle dos recursos disponveis no
atendimento as necessidades da populao.
Isto muda novamente a hierarquia e a subordinao da VISA Capital. Tecnicamente a
Vigilncia Sanitria subordinada ao CVS, administrativamente a DIR-I atualmente ao
GSAE, presentemente se tem a notcia que a Secretaria estuda nova modificao com a
recriao da DIR-I Capital e a possvel vinculao da VISA a CCD Coordenadoria de
Controle de Doenas. (organograma atual)
As demandas chegam na VISA Capital por vrios caminhos, seja atravs de denncias de
cidados, de atividades programadas, de solicitao de licena de funcionamento,
125
certificao em boas prticas de fabricao, ou solicitao de outros rgos como
Ministrio Pblico, Autoridade Policial, Poder Judicirio entre outros. A interface da VISA
Capital com outros rgos muito abrangente dadas s caractersticas do territrio que
atua.
Qualquer que seja a demanda, o primeiro passo protocolar o pedido na Central de
Atendimento ao Pblico CAP, onde a mesma registrada no sistema SIAP Sistema de
Informao de Atendimento ao Pblico e recebe um nmero de protocolo e, se for o caso,
um nmero de processo com o qual o interessado acompanhar sua solicitao. Verificada a
natureza do pedido o mesmo encaminhado para analise e providncias de acordo com o
status: todas as solicitaes de empresa ou servios como Licena Inicial ou renovao da
licena so encaminhados para o setor de expediente para cadastramento no SIVISA -
Sistema de Informao em Vigilncia Sanitria. As solicitaes de avaliao de projeto
ficam cadastradas somente no SIAP.
A Licena de Funcionamento vale por um ano a partir da data de deferimento, devendo ser
renovada a cada perodo de validade. A solicitao acompanhada por documentos e
quando se tratar de renovao deve ser pedida 60 dias antes do trmino da validade da
licena. Na licena inicial so exigidos mais documentos inclusive projeto da edificao,
pr-requisito para a obteno da licena de funcionamento.
Aps o cadastramento o processo ou protocolado ser enviado para o setor competente para
anlise dos documentos e vistoria inicial por equipe multiprofissional quando sero
avaliados os fluxos dos procedimentos, as rotinas e regras para asseguramento dos padres
de qualidade quando se tratar de prestao de servios de sade e de boas prticas de
fabricao quando se tratar de produtos.
Da vistoria podem resultar vrias situaes que sero analisadas pela autoridade sanitria
que propor a melhor medida ou recomendao em sua funo da fiscalizadora.
As dificuldades se multiplicam, desde a juno em 2003 a situao de viaturas se agravou,
hoje o nmero mximo de veculos disponibilizados para a execuo das aes so quatro
viaturas por dia para fazer as vistorias quando nos ncleos existiam onze viaturas para o
mesmo territrio, os equipamentos de informtica disponveis no do conta da demanda,
quebram com freqncia ou cai o sistema, perdendo todo o relatrio, h muita insatisfao
da equipe.
126
Os registros so feitos no sistema sem padronizao, muitos dados foram copiados de
sistema antigos, com maneiras diferentes de registro, dificultando a consulta no sistema. H
momentos que o funcionrio precisa ser mgico para conseguir a informao e muitas se
perderam no caos das mudanas.
Os arquivos, importantes fontes de consulta esto parte no prdio da Av. So Luiz e esto
sendo organizados e parte, espalhados por outros prdios sem controle e sem acento de
onde encontrar.
No existe domnio dos dados, os dois sistemas SIAP e SIVISA no se comunicam,
portanto no se tem cruzamento de informaes, conseqentemente as equipes dispendem
mais esforo e tem mais trabalho para obter as informaes. Em contrapartida a diretoria
tem muitas dificuldades em gerenciar as atividades e planejar as aes.
Levando-se em conta as colocaes acima e, acrescentando a isso as complexidades dos
servios e das empresas, possvel estabelecer um planejamento das aes de visa, desde
que se conhea o universo da atuao, as pessoas envolvidas na execuo das aes, e os
interlocutores do processo.
Planejar as aes de visa desejvel e possvel desde que alguns pr-requisitos sejam
atendidos como sistemas de informao que permitam cruzamento de dados, capacitao ou
reciclagem dos profissionais, pois as tecnologias em sade so geis e os profissionais no
so capacitados com a mesma agilidade pelo poder pblico.
Faz-se necessrio zerar um conjunto de pendncias que interferem muito na execuo das
aes, como a questo de ter ou no combustvel, ter ou no motorista para se ter agilidade
nas aes de visa..
127
Anexo B Resultados do Quadro de Avaliao

1- Camada de Contribuio
Tabela 2 : Resultados do Quadro de Avaliao - Camada de Contribuio
Contribuio
Partes Interessadas Condies/Efeitos Questes/Problemas Possveis Solues
Diretoria / Assistncia
Tcnica
Saber/conhecer as
ocorrncias cadastradas
Controle do Trabalho dos
tcnicos
No h como encaminhar
as ocorrncias sem
conhecimento e sem apoio
das reas tcnicas
Dificuldade em localizao
de documentos
Falta de dados que
permitam o gerenciamento
e planejamento para
cobrana de retorno e
providncias.
Muito embora as
certificaes sejam ligadas
s licenas, no h como
cruzar as informaes.
Falta registro dos relatrios
de certificao para
subsidiar deciso.
Formalizao de dvidas e
maneira de acesso
Diretoria, respeitando os
nveis hierrquicos.
Disponibilizao de:
Com quem est o
documento
Quantos
documentos esto
com qual
tcnico/rea
A quanto tempo
est sem
soluo/encainham
ento
Aonde ficou
parado(gargalo)
Porque no teve
encaminhamento
(ex: por falta de
viatura)

Melhor controle das
empresas por projeto
128
Coordenadorias de rea
Precisa saber o que o tcnico
faz, e como e quando.
Cadastro provisrio(deferido
ou indeferido) prrequisito
para a licena
No consegue monitorar
auto de infrao por
irregularidades de
estabelecimento
Convocao dos tcnicos
pelo CVS para certificao,
ficando a DIR sem pessoal
para manter as rotinas
Falta de apresentao de
relatrios de vistoria
(sivisa) por parte de todos
os tcnicos.
Falta de apresentao do
resultado de trabalho do
tcnico atingindo a meta
solicitada, mostrando a
falta de envolvimento do
tcnico com o tema
abordado.
Grande demanda de
trabalho sem apoio
administrativo, decorrendo
na falta de tempo para
anlise, avaliao e
planejamento do trabalho.
Grande nmero de
tcnicos, grande nmero de
casos com complexidades
diferentes
Localizao de documentos
Falta de padronizao de
trabalho
Carga horria baixa e no
cumprida
Carga horria diferente por
categoria profissional
Falta de compromisso com
o servio e com as
informaes tcnicas



Registro da hora tcnica do
funcionrio
disponibilizado para a
certificao em Boas
Prticas, para a negociao
dos dias disponibilizados.
Treinamento ou integrao
de todos para a
demonstrao de resultado
homogneo (relatrio
sivisa) atravs de reunies
de avaliao com o grupo.
Reunies com o grupo
para a integrao e
uniformizao do trabalho.
Melhor visibilidade dos
casos por tcnico e
controle de retorno dos das
demandas encaminhadas
para os
tcnicos(frequencia)
Disponibilizao de :
Com quem est o
processo
Quantos
documentos est
com cada
tcnico/rea
A quanto tempo
est sem
soluo/encaminha
mento
Aonde ficou
parado(gargalo)
Por que no teve
encaminhamento
Trabalhar com
planejamento e
cronograma- preciso
planejamento integrado
das coordenadorias

129
Tcnicos
Conhecer normas
regulamentares
Instrumentos viaturas,
mquinas fotogrficas,
equipamentos medidas
Coordenao apoio tcnico
Vistorias composio da
equipe.
Proposta de liberao ou no
da licena
Relatrio de vistorias para a
a orientao das empresas e
das coordenadorias.
Falta de equipamento de
informtica
Falta de insumos
Falta de tcnicos de outras
reas para avaliar os
projetos
Falta de apoio para
atividades administrativas
Falta de treinamento e
disponibilizao de novas
legislaes
Falta de apoio tcnico para
a deciso de viabilidade de
uma solicitao
Perda de dados
informatizados.
Disponibilizao de
agendas de insumos
Gravao de dados
centralizados
Suporte de
informao/sistemas
Solicitao de informao
(relatrios) pelas reas
Saber entender as reais
necessidades dos usurios
Emisso de relatrios
facilitados por ferramentas
Protocolo/Expediente
Interface (porta voz) da
instituio tcnicos X
usurios

Porta de entrada / Sada
Resposta solicitao de
usurios
Registro e demanda para a
rea tcnica.
Faltam condies de
treinamento e padres.
Falta padronizao de
procedimentos para
uniformidade de
atendimento e respostas aos
usurios (pblico)
Autonomia para a deciso
pela situao de
regularidade da empresa
por insuficincia
operacional da
administrao
Registro de todas os
atendimentos (demandas),
inclusive de balco e
telefone.
130
2- Camada de Fontes
Tabela 3 : Resultados do Quadro de Avaliao - Camada de Fonte
Fontes
Partes Interessadas Condies/Efeitos Questes/Problemas Possveis Solues
Anvisa
Define regras gerais de
vigilncia sanitria para
todo o Brasil
Autorizam funcionamento e
registro de produtos
certificao
Falta de controle e
atendimento dos prazos
para encaminhamento de
autorizao de
funcionamento
No ter acesso ao cadastro
de produtos, o que causa
retrabalho e dificulta o
fluxo
Registro e controle dos
prazos
Acesso aos registros de
produtos, pendncias e do
histrico do produto
Polcia
Demanda denncias
Solicita informaes
No se sabe de todos os
casos que chegam atravs
da polcia e os
responsveis no tm
controle sobre os
funcionrios e destas
aes

Fazer cadastro dessas
informaes
Procon
Solicita informaes No ter relatrio /registro
da empresa ou produto
Fazer cadastro dessas
informaes
Assessoria de imprensa
Responde a reportagens e
denncias nos meios de
comunicao
Solicita informaes de
assuntos de nossa
competncia
Informao muito dispersa
ou inexistente
Centralizao das
informaes
Conselhos de classes
Fazem denncias sobre
estabelecimentos sob
regime da vigilncia
Informam sobre penalidade
profissional
Extrapolam a competncia
No tem poder de
polcia
Mediao pelo ministrio
do trabalho sobre conflito
de competncia
Secretaria da Fazenda
Valores e taxas
Cadastro nacional
Cadastro para efeito fiscal
Fornecem nmero Cnae
No tm acesso a
informaes como
cadastros fiscais, CNPJ e
tipo de estabelecimentos.
Estar cadastrado
(replicado) como
informao da receita
131
Dir
Dir regionalizadas
Troca de informaes
dependendo da localidade
do estabelecimento
As Dirs no tem
compartilhamento de
informao
Ter um acordo de
informao ou
informaes
compartilhadas
Ministrio Pblico
Solicitam informaes
sobre empresas sujeitas ao
regime de vigilncia
Controle das solicitaes
(ofcios)
Demora no retorno com
vrias reiteraes
Melhora no controle das
demandas (ofcios)
Poder Judicirio
Solicitam informaes para
a instruo de processos
que envolvem nossa
competncia legal
Compilar as informaes
Obter a informao
Refinamento do cadastro
e melhor cruzamento de
informaes.

132

3 Camada de Mercado
Tabela 4 : Resultados do Quadro de Avaliao - Camada de Mercado
Mercado
Partes Interessadas Condies/Efeitos Questes/Problemas Possveis Solues
Prefeitura
Prestam mesmo servio em
complexidades diferentes
definidas em Resoluo
30/94
Falta de conhecimento por
parte da prefeitura de certos
aspectos da competncia
legal de Estado/Municpio
Esclarecer melhor casos
encaminhados errados
Anvisa
Agncia reguladora, com
competncia e foco diferente
Sem comentrios Sem comentrios
Visas
Utilizam a DIR 1 como foco
de referncia
Sem comentrios Sem comentrios

133
4 Camada de Comunidade
Tabela 5 : Resultados do Quadro de Avaliao - Camada de Comunidade
Comunidade
Partes Interessadas Condies/Efeitos Questes/Problemas Possveis Solues
Governo Sem comentrios Sem comentrios Sem comentrios
Imprensa
Formao de opinio da
populao
Manter boa imagem
perante o pblico
Bom trabalho de base da
assessoria de imprensa
Ministrio da Sade Sem comentrios. Sem comentrios Sem comentrios


134
Anexo C Resultados do Framework Semitico
Tabela 6 : Resultados do Framework Semitico
NVEL DESCRIO POSSVEIS SOLUES
MUNDO SOCIAL
Crenas, funes, compromissos, contratos,
leis, cultura...
Melhoria da qualidade dos
projetos
Melhoria do atendimento aos
usurios
Melhor clareza nas informaes
Diminuio do tempo de
resposta
Melhoria da qualidade dos
servios/produtos de interesse
sade
Organizar e implementar o
manual de atendimento a
usurio da portaria 16 (isso
uma portaria de lei)
Organizar e inferir um sistema
de cobrana de resultados

PRAGMTICO
Intenes, comunicaes, conversaes,
negociaes...
Confiana e satisfao do
usurio
Resposta gil e conclusiva
Melhor aferio dos resultados
dos tcnicos, para efeito de
prmio de incentivo, visando
melhorar atendimento,
produtividade e resolubilidade.
Melhorar a avaliao dos
projetos
Avaliao qualitativa das
avaliaes tcnicas
Avaliao do tcnico
(produtividade, colaborao,
prazo, resolutibilidade)
Avaliao do Prmio de
incentivo
Adequao dos tcnicos nova
realidade ps municipalizao

SEMNTICO
Significados, proposies, validade,
verdade, significao, denotao...
Padronizar a linguagem dos
relatrios de parecer tcnicos
Clareza e objetividade nos
pareceres dos processos
Utilizar esses dados para o
prmio de incentivo
Padronizar as informaes do
Protocolo e dos tcnicos para o
pblico em geral



135
Anexo D Resultados da anlise Colateral
Tabela 7 : Resultados da Anlise Colateral
Ciclo de Vida
Predecessor

- Sivisa
- Siap
- Planilhas Excel
- Trabalho Manual

Sistema Focal

Sistemas de Banco de Dados
Sistemas de Data Warehouse
Interfaces

Sucessor

Sistemas de Workflow
Sistemas de acompanhamento de processos via Web.
Funcionamento
Entrada

- Razo Social, Nome Fantasia, CNPJ, Endereo, Tipo de Estabelecimento/Atividade, CNAE fiscal, Responsvel
Legal,
Responsvel Tcnico, Servios Terceirizados.
- Tipo de demanda em caso de produto: autorizao de funcionamento, dados complementares, ltima licena
emitida e data de validade.
- Relatrios: Descrio da empresa, descrio da situao encontrada, Recomendaes, providncias, concluso.
- Relatrios sivisa
- Recursos: Tipo do recurso, uso do recurso, quem, quando e para qu.
- A demanda foi pra quem, quando foi recebida, quando retornou, quando foi feita a vistoria, quando foi feito o
relatrio.
- Estabelecimento: Cadastro, ciclo de vida e de operao, Histrico de requisies, tipo de atividade.

Sada


- Facilidade de gerao de relatrios com base em informaes existentes de forma no linear.
- Controle de solicitao: tempo de sada, tempo para relatrio, tempo com o tcnico ( pediu viatura quando, fez a
vistoria quando, qual era a equipe?)
- Visualizao de relatrio: Tcnico X Licena X Risco
- Informaes totalizadoras por estabelecimento: regio, tipo de trabalho, porte, registro, complexidade.

Ambiente

- Centralizado, seguro, interface facilitada.
- Software livre, sempre que possvel.