CENTRO UNIVERSITÁRIO EUROAMERICO – UNIEURO

PRÓ-REITORIA DE PÓS-GRADUAÇÃO PESQUISA E EXTENÇÃO

COORDENAÇÃO DE PÓS-GRADUAÇÃO LATO-SENSU
CURSO DE ESPECIALIZAÇÃO/MBA EM GOVERNANÇA DE TI

CLAUDIO DA SILVA LOBO

CLÊNIO GONÇALVEZ BORGES
RICARDO SANT'ANA
RÓBERSON ZORZAN DE ASSIS

PROPOSTA DE SOLUÇÃO DE INDICADORES DE DESEMPENHO

BASEADOS EM SOA PARA O EXÉRCITO BRASILEIRO

Brasília, Novembro /2010

 ii

CLAUDIO DA SILVA LOBO

CLÊNIO GONÇALVEZ BORGES
RICARDO SANT'ANA
RÓBERSON ZORZAN DE ASSIS

PROPOSTA DE SOLUÇÃO DE INDICADORES DE DESEMPENHO

BASEADOS EM SOA PARA O EXÉRCITO BRASILEIRO

Trabalho de conclusão de Curso apresentado

como pré-requisito parcial para a conclusão
do curso de Especialização/MBA em
Governança de TI do Centro Universitário
Euroamericano – Unieuro.

Orientadora: Profª MSC. Kerlla de Souza Luz

Brasília, Novembro/2010
 iii

CLAUDIO DA SILVA LOBO

CLÊNIO GONÇALVEZ BORGES
RICARDO SANT'ANA
RÓBERSON ZORZAN DE ASSIS

PROPOSTA DE SOLUÇÃO DE INDICADORES DE DESEMPENHO

BASEADOS EM SOA PARA O EXÉRCITO BRASILEIRO

Esta monografia foi julgada adequada à

obtenção do grau de Especialista em
Governança de TI e aprovada em sua forma
final pelo curso de Pós-graduação Lato Sensu
em Governança de TI do Centro Universitário
Euroamericano – UNIEURO

Data de aprovação:

Banca Examinadora

Prof. MSC. Gerson Martins de Souza

Centro Universitário UNIEURO

Prof. Dr. José Gonçalo dos Santos

Centro Universitário UNIEURO

Profa.MSC. Kerlla de Souza Luz

Centro Universitário UNIEURO
 iv

AGRADECIMENTOS

Agradecemos e dedicamos nosso carinho aos nossos professores que nos

acompanharam nessa jornada. Agradecemos por toda atenção concedida e por terem nos
ensinado muito mais que teorias, mas sim lições que serão essenciais para a nossa vida.
De forma ímpar, agradecemos a Deus, por ter nos dado pais maravilhosos, que foram
os alicerces para construção e realização desse sonho, por terem nos proporcionado todo o
amor e segurança necessária para concluir mais essa etapa, por compartilharem conosco
nossas alegrias e tristezas, por nos darem apoio e por nunca nos deixarem desistir.
 v

A perfeição não consiste na

multiplicidade das coisas feitas,
mas no fato de serem bem feitas.
São Vicente de Paulo
 vi

RESUMO

Este trabalho apresenta uma proposta de utilização de Arquitetura Orientada a

Serviços (SOA) em um projeto de Business Intelligence baseado em Dataware house e Data
Marts em um ambiente de TI Corporativo, ou seja, atualmente as informações para compor
indicadores de desempenho originam de um banco de dados corporativo e nossa proposta
sugere que se utilizem informações e dados provenientes de sistemas de informação já em
utilização. Essa proposta traz vantagens em relação a abordagem adotada no projeto original
da Instituição ao permitir que sejam utilizadas informações únicas – existentes nos diversos
sistemas de informação – na composição dos indicadores de desempenho.

Palavras-Chaves: SOA, Business Intelligence, DataWarehouse, indicadores de desempenho.

 vii

ABSTRACT

This proposal presents how could SOA – Service Oriented Architecture – be applied
in a Data ware House and Data Mart based Business Intelligence project in a TI environment,
actually the information used to construct key performance indicators are taken from a
Database and this proposal suggests to use information taken from information systems
already in installed. This proposal take advantages when comparing with original Data ware
House approach because it allows to use as unique information – spread along informations
systems – to compose key performance indicators.

Keywords: SOA, Business Intelligence, Data Warehouse, key performance indicators.

 viii

LISTA DE ILUSTRAÇÕES

Figura 1.1 – Organograma do DCT (Fonte: http://www.dct.eb.mil.br/ acessado em

01/11/2010)..........................................................................................................1
Figura 2.1 – Diagrama esquemático das metodologias utilizadas no projeto SIG...................7
Figura 3.1 – Elementos do BPM.............................................................................................24
Figura 3.2 – Arquitetura de Integração antes e depois da utilização de um ESB...................27
Figura 3.3 – Projetos envolvidos no projeto SIGADEx.........................................................33
Figura 3.4 – Arquitetura do projeto SIGADEx.......................................................................35
 viii

LISTA DE ABREVIAÇÕES

BI Business Intelligence.......................................................................................2
CDS Centro de Desenvolvimento de Sistemas........................................................2
CONARQ Conselho Nacional de Arquivologia..............................................................35
DCT Departamento de Ciência e Tecnologia...........................................................1
DGP Departamento Geral do Pessoal.....................................................................17
DW Data Warehouse...............................................................................................3
EB Exército Brasileiro...........................................................................................1
EIS Executive Information System........................................................................1
EME Estado-Maior do Exército..............................................................................10
ETL Extract Transform Load...................................................................................3
GED Gerenciamento Eletrônico de Documentos...................................................34
IG 10-80 Instruções Gerais Para a Organização e o funcionando do SICATEx...........29
IR 14-06 Manual de Atribuição de Nomes e dos Meta-dados para Administração de
Dados do Exército Brasileiro.........................................................................11
OLAP OnLine Analytical Processing.......................................................................12
OMDS Organizações Militares Diretamente Subordinadas.........................................1
SAD Sistema de Apoio à Decisão............................................................................3
SE-EB Programa Sistema de Excelência no Exército Brasileiro................................2
SICATEx Subsistema de Catalogação............................................................................29
SIG Sistema Integrado de Gestão...........................................................................2
SIGAD Sistema Informatizado de Gestão Arquivística de Documentos...................35
SIGADAer Sistema Informatizado de Gestão Arquivística de Documentos da
Aeronáutica....................................................................................................35
SIGADEx Sistema Informatizado de Gestão Arquivística e Documental do Exército. .33
SIMATEx Sistema de Material do Exército..................................................................4, 5
SOA Service Oriented Architeture...........................................................................5
SPED Sistema de Protocolo Eletrônico de Documentos........................................4, 5
WSDL Linguagem de definição de Web Services.....................................................21
XML Linguagem de marcações extensíveis............................................................21
 viii

SUMÁRIO

1. INTRODUÇÃO...................................................................................................................1
1.1 Contextualização.............................................................................................................1
1.2 Justificativa.....................................................................................................................3
1.2.1. Objetivo Geral.........................................................................................................4
1.2.2. Objetivo Específico.................................................................................................5
1.3 Estrutura da Monografia.................................................................................................5

2. REFERENCIAL TEÓRICO.............................................................................................6
2.1 Metodologias utilizadas no projeto SIG.........................................................................6
2.1.1 Fases do Projeto.......................................................................................................8
2.2 Arquitetura Orientada a Serviços..................................................................................17

3. ESTUDOS DE CASO.......................................................................................................22
3.1 Roteiro para definição de Indicadores de Desempenho com SOA...............................23
3.1.1 Elementos do BPM................................................................................................23
3.2 Sistema de Material do Exército (SIMATEx)..............................................................28
3.2.2 Vantagens do Programa de Catalogação...............................................................29
3.2.3 Tecnologia envolvida e Arquitetura......................................................................30
3.2.4 Proposta SOA para SIMATEx...............................................................................31
3.3 Sistema Informatizado de Gestão Arquivística e Documental do Exército..................32
3.3.1 Tecnologia envolvida e Arquitetura......................................................................34
3.3.2 Proposta SOA para SIGADEx...............................................................................35

4. CONCLUSÃO...................................................................................................................37
4.1 – Conclusão do trabalho...............................................................................................37
4.2 – Trabalhos Futuros......................................................................................................38

7. REFERÊNCIAS BIBLIOGRÁFICAS............................................................................39
1. INTRODUÇÃO

1.1 Contextualização
O Departamento de Ciência e Tecnologia (DCT) é um órgão do Exército Brasileiro
responsável por gerenciar o sistema de ciência e tecnologia para produzir os resultados
científicos e tecnológicos necessários à operacionalidade da força terrestre. A criação desse
departamento proporcionou a racionalidade do emprego de recursos e fez com que as
organizações tornassem mais leves e ágeis, com foco em resultados – no que tange a área de
ciência e tecnologia.

A seguir, é mostrado o organograma do DCT e suas respectivas OMDS

(Organizações Militares Diretamente Subordinadas):

Figura 1.1 – Organograma do DCT (Fonte: http://www.dct.eb.mil.br/ acessado em

01/11/2010).

A função principal de TI é a de prover informações de valor sempre que requisitado e

considerando o tempo de resposta. Com este novo tipo de conhecimento, os gestores
puderam tomar decisões mais acertadas viabilizando o negócio e melhorando a relação com
seus parceiros (clientes e fornecedores). Os sistemas que forneciam esse tipo de informação
passaram a ser chamados, inicialmente, de Sistemas de Informação a Executivos (em inglês
Executive Information System – EIS). Tais sistemas foram denominados, posteriormente, de
Sistemas de Inteligência de Negócio (do inglês Business Intelligence – BI). Nesse contexto,
a informação gerada proporcionou um diferencial ao oferecer um maior conhecimento do
próprio negócio.

Assim, por intermédio do Centro de Desenvolvimento de Sistemas (CDS), que é a

organização militar do Exército Brasileiro (EB) responsável pela concepção e
implementação dos sistemas corporativos da Força Terrestre, o DCT está em processo de
desenvolvimento de um projeto denominado Módulo Básico de Pessoal do Sistema
Integrado de Gestão (SIG). O SIG visa proporcionar um sistema de gerenciamento de
informações ao Comandante e à Alta Administração do Exército Brasileiro, aperfeiçoando a
gestão do EB, por meio da integração dos sistemas corporativos informatizados de todas as
áreas de atividades – à exceção das áreas de Inteligência e Operações. Em sua primeira fase,
o projeto envolve, principalmente, a área de Pessoal.

A solução atual abarca serviços de Consultoria Técnica Especializada em Business

Intelligence (BI) para o Exército Brasileiro, com base na gestão dos ambientes de software e
em processos de transferência de tecnologia.

Existem, atualmente no EB, vários sistemas transacionais informatizados para

realizar seus processos mais importantes, gerando uma enorme quantidade de dados
relacionados aos processos, mas não relacionados entre si. Estes dados são recursos, mas, de
modo geral, seu estado original impede sua utilização como recursos estratégicos, em
decorrência da falta de integração entre as diversas bases de dados corporativas da Força
Terrestre.

Visando minimizar esse problema, o Exército vem desenvolvimento esforços na

aplicação dos recursos de Tecnologia da Informação (TI) para dar suporte aos seus gestores
estratégicos, proporcionando a melhoria, de forma contínua, para a sua gestão
administrativa.

Em 2007, o Comandante do Exército Brasileiro, por meio da Portaria nº 220, de 20

de abril 2007, estabeleceu o Programa Sistema de Excelência no Exército Brasileiro (SE-
EB), constituído por quatro projetos. Dentre eles, encontra-se o Sistema Integrado de Gestão.
 O Projeto SIG é um Plano de Ação planejado pelo Estado-Maior de Exército (EME)
– com o assessoramento técnico do Departamento de Ciência e Tecnologia – que compõe a
estratégia adotada pelo EB para concretizar os objetivos de completar, aprimorar, consolidar
e integrar os sistemas existentes na Instituição; racionalizar e modernizar os processos
administrativos e assegurar uma eficiente gestão da informação.

Este Plano de Ação prevê o desenvolvimento de um Sistema de Apoio à Decisão

(SAD) – mais precisamente um Data Warehouse (DW) – que integrará as áreas de atividade
do EB. No entanto, com o intuito de minimizar os riscos inerentes a um projeto desta
complexidade, optou-se primeiramente por implementar um Data Mart por área de
atividade, iniciando pela área de pessoal e, ao fim, consolidando essas atividades num DW
do Exército Brasileiro composto pelos Data Marts das áreas de atuação do EB.

No projeto atual de Data Mart é utilizado o Oracle Warehouse Builder 10g para as
operações de Extract Transform Load (ETL) – Extração Transformação Carga – e Oracle
Database Standard Edition One 10g para o repositório de dados. Para a geração dos
relatórios analíticos é utilizado o MicroStrategy.

Dentro desse cenário, propomos uma nova forma de coleta de informações para
compor os indicadores de desempenho do projeto SIG utilizando a abordagem SOA.

1.2 Justificativa
No Exército Brasileiro existe um enorme parque de Sistemas de Informação que
foram desenvolvidos não somente para atender às diversas necessidades da Instituição como
um todo como para atender às necessidades de um grupo limitado de organizações militares.
Durante o processo de desenvolvimento desses sistemas os esforços eram direcionados no
sentido de se criar um sistema de informação que auxiliasse no desenvolvimento de
determinadas atividades.

Assim, não houve a preocupação da integração dos mesmos, já que a cultura

organizacional não apregoava essa integração e as tecnologias existentes, à época, não eram
maduras o suficiente para realizar a associação de forma eficaz.

No projeto SIG em andamento, existe um grande foco para obtenção de indicadores

de desempenho utilizando Data Marts originados de uma base de dados corporativa – o
EBCorp. No entanto, muitas outras informações pertinentes encontram-se armazenadas de
forma distribuída nos diversos sistemas de informações do EB. Esses dados, embora
relevantes, de forma alguma podem ser recuperados utilizando-se a tecnologia atualmente
empregada no SIG – dado o esforço ser maior que o benefício e tendo em vista a grande
heterogeneidade das aplicações envolvidas no processo.

Neste sentido, com o amadurecimento da Arquitetura Orientada a Serviços e com o

desenvolvimento das tecnologias relacionadas a esta, é possível propor uma solução para o
desenvolvimento de indicadores de desempenho que sejam fruto da integração dos sistemas
existentes, permitindo que as informações e dados armazenados de forma distribuída – e não
contemplados pelo projeto SIG – sejam utilizados para agregar mais informação aos marcos
já existentes ou mesmo criar novos índices de desempenho.

Ainda, segundo Marzullo, 2009:

“O fato é um profissional de TI, quando tem o controle adequado de ferramentas e,

acima de tudo, entende o contexto organizacional em que está inserido, nunca
descansará em sua busca por novas formas de aumentar o potencial competitivo da
organização”

Com a visão sistêmica da organização em que trabalhamos e com o conhecimento de

tecnologias e metodologias emergentes – como o SOA – o grupo irá propor uma solução de
integração que seja adequada ao projeto SIG em andamento, permitindo o aproveitamento
dos benefícios desta, ao viabilizar que informações únicas sejam utilizadas para compor
indicadores de desempenho.

Devemos considerar ainda que os sistemas de informação já instalados nem sempre

refletem a necessidade de informatização de processos de negócio – ou seja – o sistema
encontra-se em uso apesar de nenhum processo de negócio estar mapeado.

Assim, no desenvolvimento da solução de integração baseada em SOA, temos uma

oportunidade para que os processos de negócio relacionados aos sistemas de informação
sejam mapeados e, em seguida, modelados.

Ainda, por meio de dois estudos de caso – o Sistema de Protocolo Eletrônico de

Documentos (SPED) e o Sistema de Material do Exército (SIMATEx) – a equipe procurará
identificar possíveis informações relevantes para os indicadores de desempenho e irá
demonstrar que a proposta é viável, sempre considerando que um estudo detalhado deve ser
realizado para cada sistema de informação existente.

1.2.1. Objetivo Geral

O objetivo desse trabalho é apresentar – dentro do contexto acima exposto – uma

nova forma de coleta de dados para o sistema SIG. Essa nova coleta é baseada na integração
de sistemas de informação existentes valendo-se de uma arquitetura orientada a serviços –
Service Oriented Architeture (SOA). .

Em outras palavras, essa proposta irá apresentar uma solução tecnológica alternativa
aos Data Marts existentes no SIG, buscando complementar a forma de aquisição de
dados/informações ao integrar os sistemas existentes. Essa integração irá definir um
conjunto de serviços a serem disponibilizados a partir de requisitos de informações
relevantes para os indicadores de desempenho.

A principal vantagem dessa abordagem é a possibilidade de se utilizar informações

distribuídas nos diversos sistemas da força terrestre para compor indicadores de desempenho
do projeto de BI original.

1.2.2. Objetivo Específico

Para atingir o objetivo acima expostos, serão considerados os seguintes objetivos

específicos:
a) Apresentar os principais aspectos do projeto SIG, como metodologia utilizada e
tecnologias relacionadas, sobretudo no que tange à diversidade de tecnologias que foram e
são utilizadas para o desenvolvimento de aplicações corporativas;
b) Apresentar os principais aspectos da abordagem SOA.
c) Apresentar a viabilidade da abordagem SOA para a integração de sistemas
considerando a realidade tecnológica da Instituição.
d) Apresentar um roteiro para integração de sistemas utilizando SOA adequados à
realidade da instituição.
e) Apresentar dois estudos de caso – na forma de dois sistemas de informações –
onde os obstáculos tecnológicos advindos da utilização de SOA serão discutidos.
1.3 Estrutura da Monografia

Esta monografia é apresentada com a seguinte estrutura: No capítulo 1, são

apresentados os problema e justificativa, o objetivo do trabalho e a estrutura da monografia.
No capítulo 2, é apresentado um referencial teórico das tecnologias e metodologias
referenciadas nesse trabalho, bem como uma apresentação dos sistemas de informação
utilizados como estudo de caso. No capítulo 3 temos a apresentação de uma proposta de
roteiro para definição da arquitetura SOA e a análise de dois sistemas na forma de estudos de
caso considerando, principalmente, obstáculos tecnológicos. Finalmente, no capítulo 4 temos
a conclusão e proposta de temas para utilização em trabalhos futuros.
2. REFERENCIAL TEÓRICO

Neste capítulo será apresentado o referencial teórico das metodologias e tecnologias

utilizadas pelo projeto SIG e um resumo da abordagem SOA para integração de sistemas.

2.1 Metodologias utilizadas no projeto SIG

Segundo o Guide to the PMBOK (PMI, 2004), projeto é um esforço temporário
empreendido para criar um produto, serviço ou resultado exclusivo. O termo temporário
indica que todos os projetos têm um início e um final definidos. Já a expressão exclusivo
significa que os projetos envolvem a realização de algo que não tenha sido realizado
anteriormente sendo, portanto, único. O PMBOK também prevê dois ciclos de vida
relacionados a projetos: ciclo de vida do gerenciamento do projeto e ciclo de vida do projeto.

Para a execução do projeto SIG é adotada a metodologia preconizada pelo Guide to

the PMBOK para o ciclo de vida do gerenciamento do projeto e a metodologia de
desenvolvimento de Sistema de Apoio à Decisão (SAD) descrita por Kimball (2008) para o
ciclo de vida do projeto.

Face ao hiato existente entre os sistemas disponibilizados e a necessidade de

informação da alta administração para tomada de decisão, são criados os Sistemas de Apoio
a Decisão (SAD). Segundo Prates(1994) :
“Sistemas de Apoio a Decisão são quaisquer tipos de recursos computacionais que
possam servir somo instrumento de apoio a decisão. Sob este ponto de vista
abrangente essa categoria de recursos inclui destes sistemas de análise e projeções
estatísticas de séries de dados até modelos simuladores da realidade estudada,
passando por recursos mais simples, tais como planilhas eletrônicas, utilizadas
para avaliar possibilidades diversas a respeito dessa realidade.”

O PMBOK descreve o conjunto de processos que devem ser seguidos para que o
projeto seja bem gerenciado. Esses processos são organizados em cinco grupos: iniciação,
planejamento, execução, controle e encerramento. Além dos grupos de processos do projeto,
o PMBOK classifica os processos que constituem cada grupo em nove áreas de
conhecimento do gerenciamento de projetos, são elas: Gerenciamento de Integração do
Projeto, Gerenciamento do Escopo do Projeto, Gerenciamento do Tempo do Projeto,
Gerenciamento dos Custos do Projeto, Gerenciamento da Qualidade do Projeto,
Gerenciamento dos Recursos Humanos do Projeto, Gerenciamento da Comunicação do
Projeto, Gerenciamento dos Riscos do Projeto e Gerenciamento de Aquisição do Projeto.

A metodologia relativa ao ciclo de vida do projeto consiste de um processo iterativo

e incremental composto por quatro fases que estão organizadas nas seguintes atividades:
Planejamento do Projeto, Definição dos Requisitos, Projetar Arquitetura Técnica,
Modelagem Dimensional, Projetar Aplicação de BI, Projeto Físico, Selecionar e Instalar
Produtos, Implementar Rotinas ETL, Implementar Aplicação de BI, Implantação, Nova
Iteração, Manutenção e Gerenciamento do Projeto. A figura a seguir, apresenta esta
metodologia.

Figura 2.1 – Diagrama esquemático das metodologias utilizadas no projeto SIG.

O projeto é desenvolvido de forma iterativa e incremental e é organizado em quatro

fases: iniciação, elaboração, construção e finalização. Com o objetivo de facilitar o
gerenciamento dos riscos, o projeto deverá ser planejado e executado com no mínimo duas
iterações. Cada iteração consistirá em uma passagem completa pelas quatro fases citadas e
resultará na implementação de um conjunto de temas (assuntos) do Data Mart, e produzirá
as entregas para ele definidas.

Não é exigido que um tema seja esgotado em uma iteração. Pelo contrário, o
propósito é de uma implementação evolutiva, de modo que os temas implementados em uma
iteração possam ser processados novamente em iterações posteriores de modo a receberem
melhorias e evoluções.

As fases são compostas por atividades, que por sua vez poderão ou não ser
decompostas em tarefas executáveis por profissionais com perfis específicos. As fases,
atividades e respectivas tarefas serão descritas a seguir.

2.1.1 Fases do Projeto

a. Iniciação
Esta fase é composta pelas atividades Planejamento do Projeto e Definição
dos Requisitos.

a.1. Planejamento do Projeto

O planejamento do projeto deverá estar alinhado ao PMBOK. Esta atividade
consiste na elaboração do plano do projeto. A equipe apresenta o planejamento detalhado da
execução das tarefas do objeto deste Projeto Básico (prazos, recursos, formas de
comunicação e de acompanhamento da execução do projeto), que é aprovado pelo CDS.

O Plano do Projeto deverá organizar o restante do projeto em no mínimo duas

iterações, e especificar os temas a serem implementados em cada uma.

Produtos:
Documento contendo o registro de reuniões.
Termo de Abertura do Projeto (TAP).
Plano do projeto detalhado (incluindo o cronograma).
Aprovação pela equipe do CDS.

a.2. Definição dos Requisitos

A atividade definição dos requisitos é dividida em duas tarefas: Levantamento
das Necessidades do Negócio e Levantamento das Fontes de Dados.

Levantamento das Necessidades do Negócio

 Consiste no levantamento das necessidades que o sistema deverá atender.
Nesta etapa identifica-se o público alvo e os requisitos funcionais e não funcionais para o
Data Mart; identificam-se os temas (assuntos) que irão compor o Data Mart e organiza-se os
requisitos de acordo com os temas identificados. Desta forma o levantamento inicial
estabelece o escopo detalhado do projeto e as funções macro que o Data Mart deverá
atender. Ainda, deverá haver a mediação das reuniões de levantamento com os clientes e a
equipe do CDS.
Produtos:
Documento contendo o registro de reuniões;
Documento de requisitos e temas;
Aprovação pela equipe do CDS e do EME.

Alguns temas e requisitos que o projeto deverá implementar já foram identificados.

No entanto, novos temas e requisitos poderão ou deverão ser identificados pela equipe.

Temas identificados:
Promoção do Pessoal Militar da Ativa;
Avaliação do Pessoal Militar de Carreira;
Valorização do Mérito do Pessoal Militar de Carreira;
Movimentação do Pessoal Militar de Carreira.

Requisitos funcionais e não funcionais identificados:

Abaixo temos uma relação dos requisitos funcionais e não funcionais que devem ser
atendidos a cada iteração da metodologia atual:
 O projeto deve prever a geração de relatórios de qualidade dos dados das
bases transacionais de pessoal.
 Além do sistema permitir a geração de relatórios analíticos capazes de
responder às questões gerenciais, deve também proporcionar e execução de
consultas comuns de pessoal, ou seja, o sistema deve permitir a identificação
de um militar ou grupo de militares que possuam determinada característica
existente nos modelos de dados das bases de dados transacionais de onde os
dados serão extraídos.
 O tempo médio de resposta a consultas previstas ao repositório deverá ser de,
no máximo, 2 minutos – considerando a infraestrutura disponibilizada.
  O sistema deve possibilitar a atualização sistemática e periódica de
dados/informações, propiciando uma análise atualizada das questões
gerenciais.
 Os nomes de objetos de banco de dados criados para o projeto deverão seguir
o prescrito no Manual de Atribuição de Nomes e dos Metadados para
Administração de Dados do Exército Brasileiro (IR14-06).
 Todos os objetos de banco de dados do sistema deverão estar definidos no
dicionário de dados e no modelo de dados.
 Todos os objetos de banco de dados das bases transacionais utilizadas no
projeto deverão ser documentados de acordo com o Manual de Atribuição de
Nomes e dos Metadados para Administração de Dados do Exército Brasileiro
(IR14-06).
 A documentação do SIG deve incluir a relação de todas as funções e
algoritmos que são executados, visíveis ou não para o usuário.
 Deve ser previsto no projeto executivo, um manual do sistema, com as
informações necessárias para configuração dos servidores, instalação e
operação do sistema. Deverão constar também deste manual, plano de
contingência, plano de backup, plano de criação de novas camadas
semânticas e de integração de novos sistemas por meio dos repositórios de
informações e política de criação de usuários, definindo os respectivos perfis.
 A solução deve ser flexível para permitir a agregação futura de novas tabelas
de fatos, novas tabelas de dimensões, novas consultas, novos usuários e novas
fontes de dados transacionais.
 A solução deverá carregar as inconsistências encontradas nos dados das bases
transacionais na base dimensional com indicações apropriadas.

Outros aspectos que envolvem informações e dados de outros sistemas presentes na

versão original da metodologia do projeto SIG não estão aqui apresentados tendo em vista
seu caráter sigiloso. No entanto, a ausência de tais elementos não invalida o resultado da
proposta da atual monografia.

Levantamento das Fontes de Dados

Consiste no levantamento e análise inicial das fontes de dados, incluindo o

levantamento e análise da documentação existente sobre as fontes identificadas, tais como
modelos de dados e correspondentes metadados, bem como documentação sobre detalhes a
respeito de regras de negócio, tabelas, arquivos e demais artefatos.

Tal atividade irá promover o entendimento sobre o negócio e seus dados, bem como
irá auxiliar no planejamento do projeto e na identificação de riscos correspondentes às fontes
de dados.

Produtos:
Documento contendo o registro de reuniões;
Documentação das fontes de dados de acordo com o Manual de Atribuição de
Nomes e dos Meta-dados para Administração de Dados do Exército Brasileiro (IR14-06);
Aprovação pela equipe do CDS.

b. Elaboração
Esta fase é composta pelas atividades Projetar Arquitetura Técnica, Modelagem
Dimensional e Projetar Aplicação de BI.

b.1. Projetar Arquitetura Técnica

A atividade projetar a arquitetura técnica consiste do levantamento dos volumes
envolvidos, tanto no que tange às bases de dados, quanto aos volumes de processamento e
quantidade de usuários simultâneos. Também serão organizados os softwares que comporão
as camada da arquitetura Online Analytical Processing (OLAP).
Produtos:
Documento contendo o registro de reuniões.
Documentação da Estimativa de volumes das bases de dados.
Documentação da Estimativa de quantidade de usuários.
Documentação com Recomendações para aspectos de performance.
Documentação da arquitetura OLAP.
Aprovação pela equipe do CDS.

b.2. Modelagem Dimensional

Consiste da elaboração do modelo dimensional de dados do Data Mart de acordo
com o escopo da iteração do projeto. Nesta atividade são identificados as dimensões e fatos
relativos aos temas da iteração. Para cada fato são definidos: as dimensões envolvidas, o seu
conteúdo e o grão (granularidade) dos dados.

O Data Mart deverá armazenar os dados em dimensões e fatos (em modelo

dimensional) em grãos de detalhe equivalentes aos dados de origem correspondentes, de
modo a preservar o histórico detalhado dos dados no nível de eventos de negócio
(transação). A partir deste nível de dados dimensionais, deverão ser criados outros níveis de
fatos agregados em grãos adequados para atender aos requisitos de análise dos usuários.

Os modelos deverão ser documentados, na ferramenta padrão utilizada pelo CDS:

ORACLE Designer 10g Versão 10.1.2.4.
Produtos:
Documento contendo o registro de reuniões.
Modelo dimensional de dados do Data Mart.
Mapeamento origem destino.
Documento de aprovação do modelo dimensional.
Aprovação pela equipe do CDS.

b.3. Projetar Aplicação de BI

Esta atividade consiste da definição das consultas previstas para a iteração e a
documentação dos indicadores identificados. Esta atividade inclui o levantamento das
consultas e análises demandadas pelos usuários e que serão a base para a homologação
correspondente ao ciclo.

Os indicadores identificados deverão ser detalhados em documentação contendo, no

mínimo: dados de entrada, períodos de coleta, fórmulas de cálculo e aplicabilidade.

Produtos:
Documento contendo o registro de reuniões.
Documento de requisitos atualizado nos temas do ciclo.
Documento técnico de especificação das consultas e indicadores.
Aprovação pela equipe do DGP e do CDS.
 c. Construção
Esta fase é composta pelas atividades Projeto Físico, Selecionar e Instalar Produtos,
Implementar Rotinas ETL e Implementar Aplicação de BI.

c.1. Projeto Físico

Consiste na construção do modelo físico relacional e multidimensional. O modelo
físico deriva do modelo lógico e de tratamentos de performance e controle; o modelo
multidimensional depende das visões e consultas a serem liberadas para os usuários
(consultas solicitadas, perfil de usuário, etc). Serão detalhados os dados um a um, analisando
questões de performance para as consultas, necessidade de tabelas agregadas, entre outros.

Produtos:
Documento contendo o registro de reuniões.
Modelos físicos de dados gerados.
Documentação sobre as características das bases de dados relacionais/
multidimensionais.
Aprovação pela equipe do CDS.

c.2. Selecionar e Instalar Produtos

Consiste em preparar o ambiente de desenvolvimento disponibilizando o software e o
hardware configurados.

c.3. Implementar Rotinas ETL

Consiste na especificação e documentação dos processos de extração, transformação
e carga (ETL) dos dados. Estes processos deverão considerar a possibilidade da carga ser
inicial, incremental ou substitutiva.

Inclui a obtenção dos dados que alimentarão o Data Mart a partir da extração dos
dados das bases transacionais. As rotinas deverão realizar extrações para a carga inicial dos
dados, incrementais e substitutivas, de forma parametrizada, ou seja, deve ser flexível para
que seja possível selecionar uma ou mais modalidades de extração.

Inclui também a especificação dos processos de carga dos dados nas bases
relacionais/multidimensionais (Data Mart) e geração de cubos. Consiste ainda da adequação
dos dados obtidos pelas rotinas de extração para o ambiente do Data Mart. As funções de
transformação deverão apontar situações de erros e exceções conforme especificação
realizada durante o levantamento.

Produtos:
Documento contendo o registro de reuniões.
Processos de ETL implementados e documentados na ferramenta de ETL.
Documentação das situações de erros e exceções encontrados.
Aprovação pela equipe do CDS.

c.4. Implementar Aplicação de BI

Consiste da implementação das consultas e das fórmulas que gerarão os indicadores
que foram especificadas na fase de elaboração. As consultas deverão permitir ao usuário
final acessar os dados agregados e atômicos de todo o ambiente Data Mart, incluindo visão
integrada de todas as estruturas multidimensionais, conforme o perfil definido para os
usuários.

Deverão ser disponibilizadas consultas ad hoc aos cubos com “drill-through”

(recuperação de linhas da tabela subjacente que foram usadas para criar uma célula
especificada em um cubo) na base para usuários privilegiados e consultas pré-definidas
parametrizadas. Também deverão estar disponíveis consultas em Dashboards (painéis de
indicadores) com parâmetros previamente determinados.

Deverá ainda, ser possível a realização de consultas a partir de construção livre de

cada usuário que se encarregará da definição dos parâmetros e filtros de seu interesse.
Produtos:
Documento contendo o registro de reuniões.
Consultas e indicadores implementados.
Aprovação pela equipe do CDS.

d. Finalização
Esta fase é composta pelas atividades Implantação, Nova Iteração e Manutenção.

d.1. Implantação
 A atividade implantação será dividida em cinco tarefas: Teste Integrado do Sistema,
Testes de Homologação, Instalação, Otimização das Bases de Dados e Testes de Aceitação
Final.
Teste Integrado do Sistema
Consiste do planejamento e execução de teste do sistema, envolvendo todas as suas
etapas.
Produtos:
Documento contendo o registro de reuniões.
Plano de teste integrado.
Documentação dos resultados e performance dos testes.
Aprovação pela equipe do CDS.

Testes de Homologação
Consiste do teste realizado pelo usuário final, validando o atendimento aos requisitos
e quanto ao desempenho. Este teste pode ser realizado no ambiente de desenvolvimento.
Produtos:
Documento contendo o registro de reuniões.
Plano de teste do usuário.
Relatório de teste do usuário.
Relatório de homologação do sistema.
Aprovação pela equipe do CDS.

Instalação
Consiste da disponibilização dos temas desenvolvidos na iteração para o Data Mart
no ambiente de produção e avaliação de performance. Serão realizadas as cargas iniciais do
sistema, pelo menos uma atualização incremental e uma atualização substitutiva. Serão
realizados os testes definitivos do sistema e ajustes que ainda se fizerem necessários.

Esta fase inclui também a passagem da aplicação do ambiente de desenvolvimento

para o ambiente de produção, a documentação do processo e o treinamento dos técnicos que
darão sustentação ao aplicativo.

Produtos:
Registro de reuniões.
 Plano de estabilização.
Relatório de avaliação geral da estabilização.
Documentação da passagem para produção.
Documentação das rotinas de produção.
Técnicos de suporte e produção capacitados.
Temas do Data Mart especificados para a iteração operando em produção.
Aprovação pela equipe do CDS, EME e DGP.

Otimização das Bases de Dados

Consiste da revisão e otimização da base de dados relacional/multidimensional.
Produtos:
Documento contendo o registro de reuniões.
Documentação das otimizações das bases de dados.
Base de dados relacional/multidimensional otimizada.
Aprovação pela equipe do CDS.

Testes de Aceitação Final

Esta atividade consiste na realização de testes de integração com todas as
funcionalidades e temas do Data Mart de Pessoal, bem como de ajustes e otimizações
necessários para o bom funcionamento do Data Mart. Os planos de testes devem ser
revisados para os testes finais. Além disto, será feita a avaliação geral do Data Mart pelo
usuário para fins de aceitação final.
Produtos:
Registro de reuniões.
Plano de teste revisado.
Relatório dos testes integrados.
Relatório de aceitação final.

d.2. Nova Iteração

Consiste em planejar a próxima iteração levando em conta aspectos ressaltados pelos
desenvolvedores ou usuários dos produtos já disponibilizados pelas iterações finalizadas.

d.3. Manutenção
 Consiste em dar manutenção en algum componente da aplicação instalada que não
esteja em conformidade com as especificações do projeto ou evoluir algum requisito por
solicitação dos usuários.

Podemos observar uma complexa definição de fases e atividades relacionadas ao

desenvolvimento e implementação de indicadores de desempenho. Cabe ainda ressaltar que
o SIG utiliza, conforme apresentado, a tecnologia de Data Mart e, por isso, está bastante
limitado à utilização de informações armazenadas no banco de dados corporativo.

Ainda, aspectos de infraestrutura como aumento do tráfego da rede é pouco

importante, tendo em vista que o servidor de processamento está localizado na mesma rede
dedicada do servidor de banco de dados corporativo.

2.2 Arquitetura Orientada a Serviços

No início do século XXI, as organizações passaram de uma estrutura vertical,
baseada em departamentos e funções, para uma estruturação orientada para processos,
considerada horizontal. As tradicionais estruturas funcionais são consideradas verticais
devido ao fato das informações somente entrarem e saírem pelo topo das estruturas pelas
chefias, não permitindo a execução transversal de um processo por meio das várias unidades
da organização.

Estas mudanças foram impulsionadas pela globalização, que passou a exigir mais
flexibilidade das organizações para que pudessem se adaptar de forma ágil às constantes
mudanças do mundo globalizado.

No que tange às organizações horizontais, os processos foram decompostos em

conjuntos de unidades bem definidas, denominadas Serviços, dando origem a um novo
paradigma: o da Orientação a Serviços. Segundo Allen (2006),

“... um serviço consiste na funcionalidade que precisa ser especificada no contexto

do negócio e em termos de contrato entre um sistema provedor e outro sistema
consumidor da mesma. Os detalhes de implementação devem ser omitidos. A
implementação de um serviço não é necessariamente automática, pode consistir
em uma atividade puramente humana.”
 Para adotar o paradigma de orientação a serviços, uma organização precisa de uma
Arquitetura Orientada a Serviços (SOA), que pode ser entendida como uma arquitetura
técnica, uma concepção de modelagem de negócio, uma fonte de integração ou uma nova
maneira de enxergar unidades de automação em um ambiente organizacional (ERL, 2004).
Para o contexto deste trabalho, apresentamos outras definições:

“SOA é uma arquitetura fracamente acoplada, pois os serviços disponibilizados

nesta arquitetura podem ser reutilizados e modificados e aplicados em diferentes
áreas dentro e fora da organização sem ajustar a tecnologia subjacente, projetada
para atender às necessidades de uma organização.” (MICROSOFT, 2007)

Ainda, segundo Josuttis, a definição de SOA é:

“... um estilo de arquitetura de software cujo princípio fundamental preconiza que

as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na
forma de serviços.“

A definição de SOA, da Wikipedia é:

“SOA é um estilo de arquitetura de software cujo princípio fundamental preconiza

que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas
na forma de serviços. Freqüentemente estes serviços são conectados através de um
"barramento de serviços" (enterprise service bus, em inglês) que disponibiliza
interfaces, ou contratos, acessíveis através de web services ou outra forma de
comunicação entre aplicações.”

Cabe ressaltar que alguns profissionais de informática têm confundido o conceito de

Arquitetura Orientada a Serviços com o conceito de Implementação de Orientação a
Serviços. A SOA proporciona maiores recursos para soluções de automação de processos
utilizando recursos computacionais, entretanto, ela é uma concepção arquitetural e não
necessariamente uma estratégia de implementação.

Os elementos principais das definições anteriormente apresentadas envolvem:

 Serviços: representam a funcionalidade do negócio.
 Infraestrutura: Barramento de Serviços (ESB) que permite combinar esses
serviços.
  Políticas e processo: sistemas distribuídos são heterogêneos e são de outros
proprietários (manutenção, disponibilidade, entre outros).

A abordagem SOA deseja, portanto, lidar com sistemas distribuídos, suportando sua
heterogeneidade, descentralização e tolerância a falhas. Tais características são típicas dos
ambientes de instituições de grande e médio porte – onde boa parte dos processos de negócio
foram automatizados – mas de forma descentralizada e independente.

Esses sistemas – geralmente vitais para a organização – são denominados aqui de

grandes sistemas. Algumas das características típicas desses grandes sistemas são:
 Heterogêneos: ou seja, a tecnologia que envolve cada sistema é diferente entre si, ou
seja, o parque de sistemas não possui uma tecnologia única nos seus sistemas.
 Completos: os sistemas envolvem a implementação de diversas regras de negócio –
geralmente complexas – e lida com vários processos de negócios interligados. Isso
torna o sistema em si bastante complexo.
 Proprietários Diferentes: os grandes sistemas, apesar de estarem na mesma
organização ou instituição estão alocados em diferentes setores com diferentes
chefias envolvidas o que, de certa forma, afeta bastante políticas de definições de
disponibilidade, manutenção de tais sistemas.
 Imperfeitos: geralmente tais sistemas foram desenvolvidos – em algum momento de
seu ciclo de vida de desenvolvimento – de forma equivocada, ou não adequada às
metodologias e conhecimento que temos atualmente.

Assim, SOA veio como forma de integrar tais sistemas: SOA é um paradigma – uma
forma de pensar – que leva a um sistema de valores para os grandes sistemas corporativos
com proprietários diferentes.

SOA é uma arquitetura fracamente acoplada, projetada para atender às necessidades

de uma organização que fornece, essencialmente, uma estrutura nas quais os processos
podem ser decompostos em serviços. Os serviços são informatizados por intermédio de
tecnologias interoperáveis, capazes de se comunicarem entre si de modo independente da
plataforma e linguagem de programação.

Dentre essas tecnologias interoperáveis destaca-se os Serviços Web (Web Services),

Essa tecnologia não é a única, mas vem-se evidenciando a mais utilizada. Os Serviços Web
proporcionam um modo padronizado de integrar aplicativos baseados na Web como um
meio das organizações estabelecerem comunicação sem requererem um conhecimento
extenso dos respectivos sistemas de TI. Pode-se inferir que, se a SOA é a arquitetura, os Web
Services são os blocos de construção (IBM, 2007).

Os Serviços Web utilizam XML (eXtended Markup Language - linguagem de

marcações extensíveis) para descrever as interfaces de aplicativos em uma linguagem
chamada WSDL (linguagem de definição de Web Services). Eles podem ser reutilizados e
modificados e aplicados em diferentes áreas dentro e fora da organização. O resultado é uma
arquitetura de TI flexível que alavanca o compartilhamento e reutilização dos componentes
de TI de forma a aprimorar a capacidade de responder às condições mutáveis do negócio.

Essa independência da implementação é conhecida como acoplamento fraco. Essa

definição contrasta fortemente com o acoplamento forte – que preconiza que os
componentes dos aplicativos são estreitamente inter-relacionados em função e forma, o que
os torna, portanto, inflexíveis no que tange à reutilização ou compartilhamento de um
serviço.

Em decorrência do trabalho com padrões abertos como o XML, o WSDL e vários

outros, a organização pode construir sistemas de TI flexíveis com serviços fracamente
acoplados, que podem ser compartilhados, modificados e permutados sem enfrentar
dificuldades com a customização de tecnologias subjacentes.

SOA proporciona uma nova visão corporativa que inova as estruturas tradicionais. Os
recursos, os conhecimentos e os ativos de TI não mais existem isolados em departamentos e
unidades de negócios independentes. Com este paradigma, a organização compartilha
informações, processos e melhores práticas como recursos modulares que podem ser
rapidamente configurados para criar oportunidades e resolver problemas (IBM, 2007).

Em outras palavras, SOA é uma arquitetura conceitual de negócios onde as

funcionalidades de negócio, ou lógicas de aplicação, é tornada disponível aos seus usuários
como um conjunto de serviços reusáveis sobre um rede de TI. SOA foca na busca por
soluções flexíveis e com foco no negócio.
 Reforçando as idéias até agora apresentadas, cabe ressaltar, ainda, que três são os
conceitos básicos de SOA:
 Serviço: Um serviço, do ponto de vista da arquitetura SOA, é uma função de um
sistema computacional que é disponibilizado para outro sistema. Um serviço deve
funcionar de forma independente do estado de outros serviços, exceto nos casos de
serviços compostos (composite services), e deve possuir uma interface bem definida.
 Interoperabilidade: SOA busca implementar uma solução que permita
interoperabilidade entre os diversos sistemas.
 Acoplamento fraco: num ambiente onde devemos entregar sistemas no menor prazo
possível – o domínio de qualidade é sempre deixado de lado. E isso é típico do ciclo
de vida de desenvolvimentos dos sistemas legados. O que buscamos agora é a
integração desses sistemas já desenvolvidos e um aspecto que se torna fundamental é
a tolerância a falhas, ou seja, evitar que a queda de um sistema acarrete na queda de
outros sistemas integrados a ele. Nesse sentido, o que buscamos é uma solução de
integração que tenha um baixo acoplamento, ou um acoplamento fraco.

Num projeto SOA, então, deve-se ter em mente a definição de funcionalidades que se
tornarão serviços. De acordo com o OASIS:

“Um mecanismo capaz de acessar uma ou mais capacidades, onde o acesso é

fornecido usando uma interface pré-estabelecida e é exercida de acordo com
restrições e políticas especificadas na descrição do serviço.”

No contexto desse trabalho, o projeto de serviços irá fornecer informações/dados, que

se encontram espalhados nos diversos sistemas de informação, com o objetivo de serem
utilizados para compor indicadores de desempenho no projeto SIG.
3. ESTUDOS DE CASO
Conforme apresentado anteriormente, o projeto SIG baseia-se num modelo onde a
arquitetura de obtenção dos dados segue, conforme Marzullo (2009), uma arquitetura de
repositório.

Essa arquitetura constitui-se de unidades de acesso que permitem o processamento da

informação armazenada. Oferece, ainda, um conjunto de mecanismos pelos quais as
informações são acessadas e atualizadas. Neste caso, todo o repositório oferece,
obrigatoriamente, um conjunto de mecanismos que permitem a manipulação de dados nele
armazenados.

Esse repositório de dados possui dois componentes distintos: uma estrutura de dados
central – que representa o estado atual – e uma coleção de componentes independentes, que
opera nesse repositório (Garlan,1994).

As vantagens para sistemas desse tipo é que as regras de acesso às informações são
facilmente implantadas e o agentes que acessam tais informações são implementados de
forma independente. Notadamente, a desvantagem dessa arquitetura é que surge a
necessidade de controle ao acesso concorrente, além da perda de desempenho no caso do
repositório encontrar-se sobrecarregado.

Dentro desse contexto, a utilização de informações que se encontram espalhadas nos

diversos sistemas de informação parece-nos interessante, ao permitir que tais dados, únicos,
possam ser utilizados no projeto de BI. Assim, serão vistos dois estudos de caso, na forma de
sistemas de informação, onde procurar-se-á identificar possíveis indicadores de desempenho
e, ainda, os óbices e requisitos para a integração em um único conjunto de aplicações.

Os exemplos aqui apresentados estão longe de ser completos. Objetiva-se validar a

proposta, ao indicar o caminho para a integração do sistema e a eficaz utilização de
informações.
3.1 Roteiro para definição de Indicadores de Desempenho com SOA
Esta seção apresenta um roteiro, mostrando os diversos aspectos que devem ser
considerados durante a definição de uma arquitetura SOA baseada em Business process
management (BPM), valendo-se de sistemas de informações já instalados. Tais sistemas
cuidam de informatizar processos de negócios já existentes dentro das OM.

Cada OM tem características e necessidades particulares, tendo em vista sua missão e

visão. No entanto, diversos processos comuns já se encontram total ou parcialmente
informatizados por meio da implantação de sistemas de informações. Desse modo, não
existe uma fórmula única para definir os requisitos de uma implementação SOA – cada
sistema ou processo deve ser tratado de forma ímpar. Além disso, as soluções (produtos,
tecnologias e metodologias) estão em constante evolução, haja vista a área de SOA ainda ser
muito nova. Assim sendo, esse roteiro visa esboçar um guia, a ser utilizado considerando os
requisitos específicos de cada sistema.

O roteiro apresentado considera o ciclo de vida de um BPM. No entanto, diversos

sistemas de informações foram desenvolvidos sem considerar os processos de negócio
relacionados. Assim, a criação de indicadores de desempenho seria uma oportunidade para a
modelagem/mapeamento dos processos de negócios.

3.1.1 Elementos do BPM

O objetivo dessa seção é o de apresentar os principais elementos de uma solução
BPM. Para os sistemas de informação já existentes, é preciso mapear e/ou modelar os
processos de negócio relacionados para que a solução de integração seja realizada.

Figura 3.1 – Elementos do BPM

a) Modelagem dos Processos

 O primeiro componente da etapa de desenvolvimento de aplicações baseadas em
BPM é o ferramental que permite a modelagem dos processos de negócio, ou seja, a
expressão dos processos de negócio em termos de interações entre aplicações e entre
pessoas. Devemos considerar, dentro do contexto dessa proposta, que tal passo não ocorreu
durante a execução do processo de desenvolvimento dos sistemas existentes e, como já
exposto, essa seria uma oportunidade para a realização de uma revisão desses processos.

A chave para o sucesso da reengenharia dos processos de negócio é o entendimento

minucioso dos processos existentes e a consequente e acertada previsão dos resultados das
mudanças efetuadas. Um erro comum ao revisar processos é deixar de investigar e entender
plenamente o processo atual e os objetivos de sua reengenharia. Sem dedicar o tempo
necessário para estudar, analisar e planejar, corre-se o risco de não endereçar corretamente o
problema original, ou trocar um problema conhecido por uma situação não existente.

b) Simulação
Depois de desenhado o fluxo dos processos, pode-se fazer simulações dos cenários
de uso, ou seja, tentar predizer a execução do processo repetidas vezes, variando desde
regras e condições iniciais até a quantidade de recursos empregados. A simulação permite
identificar melhorias no processo de negócio – como a eliminação de possíveis gargalos,
redução de custos e o dimensionamento correto de equipes – antes mesmo de sua
implantação em produção.

Essa etapa permitiria, também, identificar necessárias mudanças nos sistemas de

informações já existentes que são utilizados em determinados processos de negócios.

c) Construção de Aplicações
De posse de um diagrama de processo de negócio validado, a TI pode começar a
implementar fisicamente os componentes que integram os fluxos, ou seja, construir as telas
que permitirão ao usuário interagir com os sistemas, as aplicações que fornecerão os serviços
técnicos e de negócio e, por oportuno, as bases de dados.

Neste momento podem ser identificadas duas atividades bem distintas e que,
normalmente, empregam equipes, metodologias e ferramentas diferentes:
  A construção dos serviços, baseados em funcionalidades bem definidas do negócio
ou técnicas. Nessa atividade, são empregadas linguagens de programação (como Java
ou PHP) e técnicas de desenvolvimento orientado a objetos, focando na exposição
das funcionalidades em termos de serviços.
 A construção dos fluxos, baseada na composição sequencial dos diversos serviços já
construídos. Nesse momento, empregam-se técnicas e ferramentas específicas para o
desenho e execução dos processos de negócio.

d) Repositório de Serviços
Um dos principais benefícios da SOA é a reutilização de serviços para suportar
diversos processos de negócio. Entretanto, para que esta reutilização seja possível, devem
existir mecanismos que permitam justamente a localização de serviços a serem utilizados.
Estes mecanismos são chamados de repositórios de serviços.

O conceito de repositório está presente na SOA deste o começo, na tecnologia de

Web Services, por intermédio do UDDI (Universal Description, Discovery, and Integration
ou Descrição, Descoberta e Integração Universal), que descreve padrões para a
representação e busca dos serviços implementados como Web Services.

e) Workflow de Pessoas
Quando as atividades do processo exigem ações ou pareceres de pessoas,
normalmente categoriza-se o processo como de longa duração, posto o elemento humano
poder levar horas (ou mesmo dias) para completar a tarefa. Todavia, para os mecanismos de
BPM oferecerem suporte à interação humana, devem, além de armazenar e controlar estes
processos de longa duração, prover funcionalidades como identificação do responsável pela
tarefa, apoio à interação e tratamento de exceções.

f) Mecanismos de Orquestrações
Depois de desenvolvidos, os processos de negócio representados como fluxos no
padrão BPEL devem ser distribuídos para os ambientes de execução (produção, por
exemplo) para serem inicializados e geridos pelo mecanismo de orquestração de processos.
Esse mecanismo recebe os eventos de negócio (e-mails, ações dos usuários, chamadas de
sistemas), identificando qual processo de negócio deve ser iniciado. Desse ponto em diante,
controla a execução do fluxo de atividades, alternando-as conforme os eventos ocorrem. Ele
também controla as exceções (sejam elas técnicas ou de negócio), gera os indicadores de
desempenho, os logs (registros dos eventos ocorridos) e armazena a situação e dados
associados ao processo em execução.

g) Executor de Regras de Negócio

Quando se constrói um fluxo de atividades em BPM, várias vezes depara-se com a
necessidade de tomar uma decisão baseada em um valor. Essa valoração e outros tipos de
regras mudam com muita frequência. Logo, se estiverem escritos nos diagramas de fluxo,
demandarão alterações pela equipe de TI, trazendo prejuízos à agilidade do negócio. Para
contornar essa questão, utiliza-se mecanismos de parametrização que, em BPM, são
chamados de Business Rules Engines ou Executores de Regras de Negócio. Estes
mecanismos – dada sua versatilidade – permitem que os próprios gestores do negócio (ou
analistas de negócio) modifiquem regras, por intermédio de telas específicas, inclusive
assinalando datas para início e fim da vigência de determinada regra.

h) Integração dos Sistemas

Outro ponto forte das ferramentas de BPM consiste na integração de sistemas - já que
os processos são compostos de atividades que, na maior parte das vezes, são chamadas às
aplicações ou acessos a dados. Estas aplicações podem constituir ambientes de diferentes
plataformas (mainframe, Java, .Net), utilizar protocolos de comunicação e formatos de
mensagens diferentes. Ainda, não é incomum que dados estejam armazenados em diferentes
bancos de dados - ou mesmo em formato de texto simples.

Por outro lado, BPEL considera tudo (aplicações ou fontes de dados) como chamadas
a serviços, que devem estar no formato de Web Services, ou seja, mensagens em formato
XML usando interfaces bem definidas através do padrão WSDL.

O desafio de converter estas diversas fontes de dados e aplicações em um formato

comum é de responsabilidade de um componente chamado ESB (Enterprise Service BUS ou
Barramento Corporativo de Serviços).

A figura a seguir apresenta a arquitetura de integração antes e depois da utilização de

um ESB. Com o ESB, as aplicações só precisam conhecer uma interface (a do ESB). Toda a
tarefa de conversão dos diversos padrões e tecnologias passa a ser feita pelo ESB, o que
simplifica a aplicação e a isola das possíveis mudanças (Viola, 2006).
Figura 3.2 – Arquitetura de Integração antes e depois da utilização de um ESB.

i) Monitoração, Indicadores de Desempenho e Relatórios

Normalmente, após o desenvolvimento de aplicações e de sua implantação e
execução em ambiente de produção, pouco suporte é dado ao negócio para avaliar se a
solução implementada foi adequada ou se há potencial para melhores resultados. BPM, ao
contrário, foca na melhoria contínua dos processos de negócio e, para tanto, provê
mecanismos para que o negócio acompanhe o comportamento dos processos e identifique
falhas e oportunidades.

Além disso, tais mecanismos podem ser utilizados na solução de BI para compor os
indicadores de desempenho dessa solução. Claro que devem ser considerados, aqui, aspectos
de segurança e de rede para que o projeto de BI em andamento – o SIG – possa tirar proveito
de tais indicadores de desempenho.

j) Otimização
Com base nos indicadores de desempenho, identificam-se os processos com
resultado abaixo do planejado e pode-se iniciar a etapa de melhoria desses processos.

Nas seções a seguir, serão apresentados os sistemas para estudo de caso e os

principais obstáculos tecnológicos que devem ser superados para implementar o roteiro aqui
apresentado.

3.2 Sistema de Material do Exército (SIMATEx)

O SIMATEx é um conjunto de recursos em pessoal e material, integrados por
procedimentos, processo, métodos, rotinas e técnicas, destinados a produzir informações
adequadas e oportunas ao Sistema Logístico do Exército Brasileiro, no que diz respeito à
previsão e à provisão dos meios materiais necessários ao cumprimento de sua missão
constitucional.

Abrange os três níveis da Instituição (estratégico, tático e operacional), apoiando-se

num banco de dados único, o Banco de Dados de Material do Exército (BD-MATEx). Esse
banco de dados fornece às diversas instalações distribuídas uma base de dados relação de
material. As informações específicas de quantidade e situação de cada material encontram-se
na base de dados onde o sistema está instalado (uma instalação por organização militar).

O SIMATEx é composto por três subsistemas, todos já concluídos pelos órgãos

responsáveis por sua confecção, a saber:
 subsistema de catalogação (SICATEx).
 subsistema de dotação.
 subsistema de controle físico do material.

3.2.1 Sistema de Catalogação do Exército

O SICATEx compõe-se de um conjunto de recursos em pessoal, material, instruções

e órgãos integrados por princípios, métodos, processos, normas e técnicas específicas,
destinado a realizar a catalogação de itens de suprimento no âmbito do Exército.

A sua legislação básica compreende:

 IG 10-80 (Instruções Gerais Para a Organização e o funcionando do SICATEx).
 Normas Gerais de Catalogação do EB.

Costumava-se chamar de Classificação Técnica a atividade que englobava a

identificação, a codificação e a catalogação dos diversos materiais e seus fabricantes. Hoje, o
conceito de Catalogação foi alterado, englobando o que se chamava de classificação técnica
do material acrescido de novas atividades, como definem as IG 10-80:

CATALOGAÇÃO é a atividade que compreende a simbolização (ou codificação)

do material, a organização, confecção, publicação, distribuição, regulamentação do
manuseio e a permanente atualização dos boletins e catálogos de suprimentos do
EB. Engloba as ações de especificar, padronizar, atribuir número de estoque, fixar
a categoria, a unidade de fornecimento, o número de código da empresa e o índice
 de mortalidade, identificar a origem e a procedência e fixar a equivalência de cada
item de suprimento considerado.

Com isso, um sistema abrangente de catalogação – ou seja, que possa ser utilizado
por todas as Organizações Militares – ligado aos órgãos da Administração Federal será a
melhor (e talvez a única) maneira de se otimizar e planejar todas as fases da atividade de
suprimento âmbito EB (Determinação das Necessidades, Obtenção, Armazenagem e
Distribuição de Suprimento).

3.2.2 Vantagens do Programa de Catalogação

Um programa abrangente de Catalogação de material facilitará a busca de
informações logísticas importantes para quem lida com o material, como:

 Código de Dotação de Material – CODOT – (codificação numérica atribuída

a materiais de mesmo emprego).
 Código de Empresa – CODEMP – (individualiza os fabricantes, fornecedores
e outras entidades prestadoras de serviços ou codificadoras de material).
 Preços praticados e indicadores de desempenho.
 Procedência do material.
 Vida em depósito.
 Intercambialidade.

Estas informações, ao propiciarem acesso facilitado para todos os integrantes da

cadeia logística do EB, trazem maior rapidez e abrangência para os planejamentos nas áreas
de suprimento (para qualquer das fases) e manutenção, com os seguintes benefícios:
 Conhecimento da intercambialidade.
 Conhecimento da substituição.
 Eliminação da multiplicidade de identificação.
 Redução do valor imobilizado no estoque.
 Padronização de linguagem e procedimentos.
 Pedidos concisos e precisos.
 Agilização da manutenção.
 Conhecimento da totalidade do material.
 Programas de padronização.
 Destinação de excessos.
  Cadastro de fabricantes e fornecedores.
 Conhecimento das reais fontes fabricantes/fornecedoras.
 Ampliação das novas fontes de obtenção.
 Utilização de itens substitutos.
 Troca de informações.

Nesse sentido, o SIMATEx vem ao encontro do atendimento das necessidades acima

expostas e, obviamente, às expectativas do cliente com relação à plena utilização desse
sistema. No entanto, a tecnologia empregada no desenvolvimento desse sistema limita
bastante a obtenção de informações gerenciais para compor indicadores de desempenho.

3.2.3 Tecnologia envolvida e Arquitetura

O SIMATEx é um sistema desenvolvido em Object Pascal (também conhecido por

Delphi) utilizando um sistema gerenciador de banco de dados local – o Firebird. Cada
organização militar que utiliza a aplicação deve instalar uma versão Standalone num
servidor local. Essa suíte é composta por um programa executável (e suas respectivas
bibliotecas) e um banco de dados local (Firebird). As informações do sistema são
armazenadas neste banco de dados local.

Os dados podem ser exportados na forma de arquivos em lote, textuais. Atualmente,

encontra-se em desenvolvimento um sistema na linguagem PHP, que irá receber e processar
esses arquivos texto e armazenar os dados numa base única e centralizada. O envio das
informações será realizado por meio da intranet da instituição. Ressalta-se aqui que a
previsão de término desse projeto é o último bimestre de 2012.

3.2.4 Análise Tecnológica para Integração via Web Services

O SIMATEx utiliza uma tecnologia mais antiga nas suas instalações. Diversos dados
e informações encontram-se espalhados nas Organizações Militares, em bancos de dados
locais à instalação.

a) Tecnologia para expor Componentes na forma de Serviços

 Apesar de o desenvolvimento do SIMATEx ter sido realizado utilizando versões
antigas do Delphi, é possível migrar o projeto para versões mais novas daquela linguagem de
programação. Desde sua versão 7, o Delphi possui suporte à disponibilização de serviços na
forma de Web Services. Isso permite que informações únicas do SIMATEx possam ser
expostas e, portanto, utilizadas para composição por indicadores de desempenho. A máquina
onde o SIMATEx está instalado tornar-se-ia um servidor Web, que seria acessado pelos
consumidores de serviços.

Desta forma, uma instância de Web Services estaria disponível para cada instalação
de SIMATEx. Vale a pena lembrar que nem sempre essas instâncias estariam online para o
consumidor de serviços – dada a diversidade de tecnologias de conexão existentes no EB e a
capilaridade da instituição, que permeia desde os grandes centros até os mais longínquos
rincões deste País.

b) Arquitetura da Proposta
Na arquitetura proposta, um único consumidor de serviços realizaria o acesso a todos
os Web Services do SIMATEx. Esse consumidor deveria ser capaz de encontrar os Web
Services, num processo que poderia ser realizado por meio de um mediador ou por
conhecimento do endereçamento IP das máquinas de Web Services. Além disso, o
consumidor deveria ser capaz de identificar se o Web Service estaria online, antes de realizar
a consulta.

Esse consumidor serviria, portanto, para consolidar as informações coletadas dos

diversos Web Services de SIMATEx e armazenaria tais dados/informações, de forma
consolidada e validada por regras de negócio previamente estabelecidas, na própria base do
EBCorp.

c) Aspectos de Rede
Considerando a alta capilaridade da intranet da instituição, nem sempre um serviço
de rede encontra-se disponível, online. Assim, deve ser considerado que o projeto de
identificação de dados/informações a serem disponibilizadas pelos Web Services SIMATEx
levará em conta a periodicidade da coleta de dados – tendo em vista o limite imposto pela
rede.
 Possíveis alternativas seriam o armazenamento local de informações temporárias
para, quando o consumidor conseguisse acessar o serviço, todos esses dados previamente
coletados fossem repassados.

d) Aspectos de Segurança
Deve-se considerar implementações que permitam que somente o consumidor – que
é único – acesse os serviços do Web Services SIMATEx, além dos aspectos criptográficos de
realização de conexão e de formatação de dados para envio, obviamente.

e) Proposta de Informações/Dados
O SIMATEx contém informações diversas de material dentro do EB. Informações
sobre velocidade de consumo de determinados materiais ou ainda, tempo de vida do material
podem ser relevantes para indicadores que demonstrem a quantidade de trabalho realizado
pelas integrantes da Força. Ainda, a realocação de itens em falta em determinadas regiões do
país pode favorecer o emprego operacional de tropas em situações de exercício e emprego
real.
f) Resultado da Análise
Do exposto anteriormente, podemos observar que, apesar de ser desenvolvido em
tecnologia mais antiga, é possível transpor os obstáculos tecnológicos do SIMATEx de
forma a permitir que funcionalidades e componentes sejam expostos na forma de serviços
dentro da rede interna corporativa da Instituição.

3.3 Sistema Informatizado de Gestão Arquivística e Documental do Exército

O SPED (Sistema de Protocolo Eletrônico de Documentos) é um dos módulos do
projeto SIGADEx (Sistema Informatizado de Gestão Arquivística e Documental do
Exército). Constitui-se numa aplicação Web para o controle de protocolo documental das
OM do EB. Foi concebido para oferecer maior organização dos documentos, melhoria da
navegabilidade, facilidade de instalação e a necessária flexibilidade para ser configurado
para cada OM em que a solução for utilizada.

A seguir, pode-se observar uma figura ilustrativa do projeto SIGADex:

Figura 3.3 – Projetos envolvidos no projeto SIGADEx.

O Sistema Informatizado de Gestão Arquivística e Documental do Exército –

SIGADEx – é um sistema concebido para o propiciar à Força Terrestre o Gerenciamento
Eletrônico de Documentos (GED). Dessa forma, objetiva consolidar um conjunto de
tecnologias que cooperam para o correto gerenciamento de documentos em formato digital.
Como exemplo de documentos, pode ser destacados os oriundos de papel, microfilme, som,
imagem ou mesmo arquivos já criados na forma digital. Para atingir esse objetivo, o GED
envolve, basicamente, cinco funcionalidades que, trabalhando reunidas ou isoladamente,
organizam as informações não estruturadas.

O SIGADEx iniciou-se, no Centro de Desenvolvimento de Sistemas, no ano de 2002,

tendo como primeiro produto a aplicação Correio Corporativo (um de seus subprojetos).
Dentre os principais objetivos do projeto, destacam-se:
 A redução de custos com cópias em papel.
 A melhoria no controle nos processos de gerenciamento e arquivamento da
documentação.
 Permitir maior precisão e agilidade na consulta e localização de documentos.
 Melhoria no processo de tomada de decisões, (informações “just-in-time”).
 Diminuir o extravio ou adulteração de documentos.
 Integrar-se com outros sistemas e tecnologias (sempre que possível e
necessário).

Em julho de 2007, a Força Aérea Brasileira iniciou a participação no projeto e passou

a chamá-lo, dentro da aeronáutica, de SIGADAer – Sistema Informatizado de Gestão
Arquivística e Documental da Aeronáutica.
 O nome de ambos os projetos tem origem na norma chamada SIGAD (Sistema
Informatizado de Gestão Arquivística de Documentos) estabelecida pelo CONARQ
(Conselho Nacional de Arquivologia). A intenção do projeto é implementar as normas
daquele órgão, para que o sistema se torne futuramente um SIGAD.

Algumas das principais características do sistema são:

 Visa atender às normas do CONARQ.
 Desenvolvido sob arquitetura WEB.
 Produzido em parceria pelo Exército e Aeronáutica.
 Código fonte do sistema sob domínio interno do Exército e da Aeronáutica.
 Projeto em constante evolução.
 Arquitetura do sistema permite o uso de poucos recursos de rede.
 Fluxo documental bem definido.
 Sistema parametrizado pela organização.
 Editor de texto próprio com caracteres especiais.
 Tramitação dos documentos digitalmente.

3.3.1 Tecnologia utilizada

O SPED é desenvolvido na linguagem Java para Web e utiliza, localmente, o sistema

gerenciador de banco de dados PostGreSQL, além do serviço de diretórios LDAP. Cada
organização militar que desejar utilizar a aplicação deve instalar o ambiente completo a ser
utilizado, na rede local da OM.

Assim, pode-se observar que o SPED é responsável pelo gerenciamento e trâmite de

documentos dentro da organização militar. A figura 2.2, a seguir, mostra a arquitetura básica
do projeto:
Figura 3.4 – Arquitetura do projeto SIGADEx.

3.3.2 Análise Tecnológica para Integração via Web Services

Abaixo temos algumas das considerações que devem levadas em conta para o projeto
SIGADEx:

a) Tecnologia para Web Services

O projeto é desenvolvido principalmente em linguagem de programação Java.
Dessa forma, temos à disposição diversas alternativas para implementar Web Services
naquela tecnologia, tais como JAX-WS e JAX-RS. De qualquer forma, considerando ser a
solução já implementada em um servidor web, a habilitação de Web Services resume-se à
escolha de uma ou outra, dentre as já citadas. Assim, cada instalação do SPED poderia gerar
uma instância de Web Service.

Da mesma forma que o SIMATEx, vale a pena lembrar que, face aos mesmos
motivos anteriormente discutidos, nem sempre essas instâncias de Web Services estariam
online para o consumidor de serviços.

b) Arquitetura da Proposta
Na arquitetura proposta, um único consumidor de serviços realizaria o acesso
a todos os Web Services do SPED. Deverá existir um mecanismo que permita que o
consumidor de serviços encontre as instâncias de Web Services, além de identificar se o
mesmo encontra-se ou não online.
 Esse consumidor único serviria, portanto, para consolidar as informações coletadas
dos diversos Web Services de SIGADEx e armazenaria tais dados/informações consolidados
no próprio EBCorp.

c) Aspectos de Rede
Considerando a alta capilaridade da intranet da instituição, nem sempre um
ponto da rede encontra-se online, portanto o projeto deve considerar aspectos como
periodicidade de coleta de dados pelo consumidor de serviços e o armazenamento
temporário de informações relevantes em banco de dados local.

d) Aspectos de Segurança
Somente o consumidor de serviços deve acessar as informações expostas na
forma de serviços. A transferência de dados deverá valer-se de recursos criptográficos para
ser executada.

e) Proposta de Informações/Dados
O SIGADEx lida com informações de trâmite de documentos e, portanto,
envolve processos de negócio documental. A quantidade de documentos processada
diariamente, a quantidade de documentos de entrada dentro da OM e o tempo médio de
processamento de documentos podem ser informações interessantes para compor
indicadores que informam o tempo gasto pelo militar em atividades administrativas.

f) Resultado da Análise
Do exposto anteriormente, podemos observar que por utilizar tecnologias mais
recentes poucos são os obstáculos tecnológicos encontrados para sua eficaz integração via
Web Services.

Isso significa que a integração desse sistema para permitir uma nova forma de coleta
de dados pelo projeto SIG envolve, principalmente, problema de definição de quais dados ou
informações devem ser expostos na forma de serviço.
 38

4. CONCLUSÃO

4.1 – Conclusão do trabalho

A utilização de indicadores de desempenho para um sistema de BI traz enormes
benefícios para qualquer instituição, contanto que a mesma possua a necessária maturidade
para sua implementação – como a disseminação de cultura de trabalho por processos.

Dentro desse contexto, o EB vem trabalhando no desenvolvimento de uma solução

denominada SIG que – num primeiro momento – busca implementar uma solução de BI
considerando aspectos de pessoal. Essa solução baseia-se em acesso a dados/informações
que se encontram numa base de dados corporativa por meio da definição de Data Marts.

A proposta desse trabalho é trazer uma nova visão, complementar, para essa solução,
ao propor a integração de sistemas de informações já existentes, permitindo que se utilizem
dados e informações únicas de tais sistemas para compor indicadores de desempenho do
sistema de BI.

Ainda, observou-se que, atualmente, a tecnologia para integração encontra-se

bastante madura e pode ser aplicada à realidade dos sistemas já desenvolvidos – aqui
apresentados na forma de dois estudos de caso. Em ambos os estudos, foi possível
vislumbrar uma solução técnica para que serviços fossem criados e expostos, com o objetivo
de fornecer informações para um consumidor único responsável por consolidar tais
informações. Com isso, o sistema de BI poderia usufruir de tais informações consolidadas
para compor seus indicadores de desempenho.

A atual proposta não abordou a forma de identificar quais informações e dados,

existentes nos diversos sistemas de informação, são relevantes para o sistema de BI. Assim,
um estudo para cada sistema deve ser realizado, com o objetivo de definir quais são os dados
a serem considerados. A forma como esse estudo deve ser realizado fará parte da
metodologia de desenvolvimento de indicadores de desempenho do sistema de BI.
 39

4.2 – Trabalhos Futuros

Para trabalhos futuros, sugerimos a implementação prática do roteiro para um dos
sistemas acima expostos considerando os obstáculos tecnológicos apresentados. Como
resultado, teríamos ajustes na metodologia devido às particularidades de cada sistema – tais
ajustes seriam interessantes para mostrar a validade da aplicação do roteiro para diversos
sistemas.
 40

7. REFERÊNCIAS BIBLIOGRÁFICAS

ALLEN, Paul. Service Orientation. New York: Cambrige University Press, 2006. 336 p.
ERL, T. Service-Oriented Architecture: A Field Guide to Integrating XML and Web
Services. New Jersey: Prentice Hall, 2004. 536 p.
Fernandes, A.A.; Abreu, V.F. Implantando a Governança de TI da Estratégias à Gestão
dos Processos e Serviços, Editora BrasPort, 2006.
Garlan, D.; Shaw, M.: An introduction to Software Architeture, Pittsburg: CMU:
Software Engineering Institute Techincal Report, 1994.
International Business Machines (IBM). Por dentro da SOA. 2007. Disponível em:
<http://www-306.ibm.com/software/br/info/features/futureenterprise/>. Acesso em: 2
novembro 2010.
Josuttis, N. SOA na prática, A arte da modelagem de Sistemas, Editora Alta Books, Rio
de Janeiro, 2008.
Kimball, R.; Ross M.; Thornthwaite, W.; MUNDY J.; BECKER, B. The Date Warehouse
Lifecycle Toolkit. 2. Ed. New York: John Wiley & Sons, 2008. 636 p.
Mansur, R. Governança Avançada de TI na Prática, editora Brasport, 2009.
Marzullo, F.P. SOA na Prática, Editora Novatec, 2009.
MICROSOFT. Service Oriented Architecture (SOA) in the Real World. 2007.
Disponível em: <http://www.microsoft.com/brasil/msdn/arquitetura/home.mspx>.
Acesso em: 2 novembro 2010.
PRATES, Maurício. Conceituação de Sistemas de Informação do Ponto de Vista do
Gerenciamento. Revista do Instituto de Informática, PUCCAMP, Março/Setembro,
1994.
Project Management Institute, PROJECT MANAGEMENT INSTITUTE. A Guide to the
Project Management Body of Knowledge (PMBOK). 3. ed. 2004. Pensilvânia:
Project Management Institute, 2004.
PROJETO BÁSICO DO SIG – Versão 4.1 de 15 de junho de 2009.
VIOLA, R. SOA e Inovação, Competitividade e Flexibilidade nos Negócios. São Paulo:
IBM, 2006.