Parecer Técnico Nº2 - Consultor Técnico - Móises

Relatório de Avaliação Técnica sobre o Sistema
BDE – Base de Dados do Estado de Pernambuco
Autor: Moisés Batista Leal Júnior, MSc
Recife, 02 de dezembro de 2013
Página 1
APRESENTAÇÃO
O presente documento constitui um relatório técnico sobre o Sistema BDE – Base de Dados do
Estado de Pernambuco do CONDEPE/FIDEM, com sede à Rua das Ninfas, 65 - Boa VistaRecife/PE - Brasil CEP: 50.700-50, Pabx: (81) 3182.4400, e com o Anexo à Rua Barão de São
Borja, 526 - Boa Vista- Recife/PE - Brasil CEP:50070-310, Pabx: (81) 3182.4500,
e foi
elaborado pelo consultor independente Moisés Batista Leal Júnior, CPF: 381.092.394-04, como
produto do serviço contratado via Processo Licitatório Nº 017/2013 – CEL D L Nº 002/2013CEL, CI Nº 07/2013-DSDI, BSE Nº 023/2013-DSDI/DEPE.
O relatório técnico está descrito nos capítulos e anexos a seguir:
No Capítulo I, encontra-se uma introdução ao serviço, onde fica caracterizado o contexto onde o
trabalho está inserido.
A especificação dos requisitos do serviço contratado pode ser encontrada no Capítulo II.
O Capítulo III apresenta a lista do material disponibilizado pelo CONDEPE/FIDEM para ser
analisado, ou seja, os códigos fontes e a documentação do sistema.
O embasamento teórico e a metodologia utilizada podem ser vistos no Capítulo IV.
O Capítulo V apresenta a análise do trabalho.
As conclusões estão apresentadas no Capítulo VI.
E, finalmente, o currículo do Consultor responsável por este relatório, bem como as evidências
da análise do Sistema BDE podem ser visualizadas nos Anexos.
Página 2
Sumário
CAPÍTULO I – INTRODUÇÃO .................................................................................................. 4
CAPÍTULO II – REQUISITOS .................................................................................................... 6
CAPÍTULO III – MATERIAL DISPONIBILIZADO PARA ANÁLISE .................................... 7
CAPÍTULO IV – EMBASAMENTO TEÓRICO E METODOLOGIA DE TRABALHO .......... 8
4.1 AVALIAÇÃO DO CÓDIGO FONTE ................................................................................ 8
4.2 AVALIAÇÃO DA BASE DE DADOS .............................................................................. 8
4.3 AVALIAÇÃO DA DOCUMENTAÇÃO DO SISTEMA................................................... 8
4.4 PASSOS REALIZADOS: ................................................................................................... 9
CAPÍTULO V – ANÁLISE ........................................................................................................ 10
CAPÍTULO VI – CONCLUSÕES .............................................................................................. 20
ANEXOS..................................................................................................................................... 22
ANEXO 1 – CURRÍCULO DO CONSULTOR .................................................................................... 23
ANEXO 2 – REQUISITOS DE INTEGRAÇÃO MICROSOFT E ESRI .................................................... 25
ANEXO 3 – REQUISITOS DE INTEGRAÇÃO DE SOFTWARES LIVRES COM O ARCGIS.................... 29
Página 3
CAPÍTULO I – INTRODUÇÃO
A Agência Estadual de Planejamento e Pesquisas de Pernambuco - CONDEPE/FIDEM é o
órgão de Planejamento, Estudos, Pesquisas e Articulação do governo, ligada à Secretaria de
Planejamento e Gestão, voltada para a implementação de uma política de desenvolvimento local
e regional no Estado de Pernambuco.
Uma das principais ferramentas de trabalho disponibilizada pela CONDEPE/FIDEM para os
pesquisadores e para o próprio governo é o Sistema Base de Dados do Estado (BDE). O sistema
encontra-se instalado na ATI – Agência de Tecnologia da Informação do Governo de
Pernambuco e pode ser acessado pelos usuários através da Internet. O sistema dispõe de uma
área restrita para administração dos dados a serem disponibilizados e uma área pública, que
permite aos interessados visualizar e baixar dados e informações acerca do Estado de
Pernambuco e seus municípios.
O Sistema Base de Dados do Estado – BDE é constituído por um banco de dados
socioeconômico sobre o estado de Pernambuco e seus municípios, e por uma aplicação de
manutenção e acesso às informações desse banco de dados.
O sistema foi implementado em 1991, utilizando a metodologia do Instituto Paranaense de
Desenvolvimento – IPARDES, do Paraná, na plataforma de software ADABAS/NATURAL,
para Computador Central (Mainframe), gerenciado pelo CONDEPE, em parceria com a FISEPE
– Empresa de Fomento de Informática de Pernambuco, que dava o suporte e manutenção ao
sistema.
Em 2004, foi iniciado o processo de Modernização do Sistema BDE, com recursos do Programa
de Apoio ao Desenvolvimento Sustentável da Zona da Mata de Pernambuco – PROMATA, com
o objetivo de substituir o sistema então existente, em mainframe, por um outro sistema
desenvolvido para uma plataforma mais moderna e flexível, com a agregação de novas
funcionalidades e mecanismos que o tornasse mais simples e dinâmico na sua utilização pelos
usuários.
Até 2006, o novo Sistema BDE foi desenvolvido e, finalmente, disponibilizado na Internet pela
empresa WIT - Planejamento e Tecnologia da Informação, através do Processo Administrativo
Nº 052/2003 – CEL – PROMATA, Concorrência Pública Nacional Nº 029/2003 – CEL –
PROMATA.
Após a sua implantação, o Sistema foi mantido pela empresa SOPHIA (do mesmo grupo da
empresa WIT) e, posteriormente, pela empresa BVR, através de sucessivos processos
licitatórios.
A última empresa a dar manutenção no BDE, a empresa BVR, em abril de 2012, tomou a
iniciativa de elaborar um relatório técnico sobre o sistema, onde concluiu que “o sistema não
apresentava as principais características para a garantia da qualidade do produto, principalmente
em relação ao código fonte, documentação e base de dados, contribuindo para o aumento do
Página 4
tempo e custo no processo de manutenção do software, além de dificultar o processo de
integração com ferramentas externas”.
A CONDEPE/FIDEM, então, no sentido de embasar a tomada de decisão sobre a manutenção
do BDE ou o desenvolvimento (ou aquisição) de um novo produto, resolveu contratar os
serviços de consultoria para uma nova avaliação técnica do sistema, desta feita por profissional
independente.
Página 5
CAPÍTULO II – REQUISITOS
A CONDEPE/FIDEM solicitou ao contratado uma avaliação técnica especializada no Sistema
BDE – Base de Dados do Estado, no sentido de verificar se o sistema tem condições de sofrer
manutenções corretivas, preventivas e evolutivas, em especial, se comportaria a integração com
ferramentas de geoprocessamento, ou se ao contrário, a indicação técnica seria pela sua
desativação e contratação de um novo produto.
Página 6
CAPÍTULO III – MATERIAL DISPONIBILIZADO PARA ANÁLISE
A CONDEPE/FIDEM entregou ao contratado um CD contendo os códigos fontes e a
documentação disponível do Sistema BDE, na versão 2.0, bem como o Relatório de Avaliação
de Software do Banco de Dados do Estado (BDE), versão 1.0, elaborado pela empresa BVR em
23 de abril de 2012, no formato impresso.
Posteriormente, em visita à empresa BVR, o contratado recebeu daquela empresa a versão mais
atualizada do Sistema BDE, contendo a versão 3.5 do sistema, que estava naquele momento em
homologação.
Página 7
CAPÍTULO IV – EMBASAMENTO TEÓRICO E METODOLOGIA
DE TRABALHO
A metodologia adotada para a execução dos serviços utilizou como embasamento teórico os
Padrões de Qualidade de Software – ISO/IEC 9126 (NBR 13596) e analisou os seguintes
componentes do Sistema BDE:



Código fonte;
Base de dados; e
Documentação.
A metodologia seguiu as etapas abaixo descritas:
4.1 AVALIAÇÃO DO CÓDIGO FONTE
Foram analisados os seguintes aspectos no Código Fonte:









Estilo de programação;
Documentação interna;
Coesão;
Redundância;
Tratamento de erros;
Estruturação;
Segurança;
Presença de código inativo; e
Complexidade estrutural.
4.2 AVALIAÇÃO DA BASE DE DADOS
Foram analisados os seguintes aspectos:


Integridade; e
Segurança dos dados.
4.3 AVALIAÇÃO DA DOCUMENTAÇÃO DO SISTEMA
Foram analisados os modelos, diagramas e relatórios componentes da documentação do
Sistema.
Página 8
4.4 PASSOS REALIZADOS:













Reunião inicial do projeto, com Edvaldo Câmara, Ivanilde e Ricardo, para
conhecimento do escopo, do contexto e das expectativas sobre o trabalho, onde
também foram entregues um CD contendo o código fonte e a documentação do
BDE e o Relatório Técnico sobre o BDE, elaborado pela empresa BVR, última
mantenedora do sistema.
Planejamento do trabalho.
Montagem da equipe de apoio.
Reunião com a empresa BVR (Vicente, Childerico e Elvis), para detalhamento
sobre o Relatório Técnico acerca do Sistema BDE, bem como para recebimento
de uma cópia atualizada do Sistema, nas versões 2.0 e 3.5, esta última ainda em
homologação pela CONDEPE/FIDEM e pela ATI, e de uma base de dados de
testes. Na oportunidade, o sistema foi demonstrado.
Reunião com os representantes da empresa Sophia (Walter Lustosa, João e
Marcos), para entendimento do histórico do Sistema BDE. O Walter participou
desde a construção inicial do BDE, como também foi o responsável pela equipe
que deu manutenção nesse sistema durante os anos que antecederam a atuação
da BVR. Foram analisadas as questões sobre a documentação, a complexidade
do sistema, perfil da equipe de desenvolvimento e manutenção e sobre o repasse
do conhecimento entre as empresas Sophia e a BVR.
Pesquisa, instalação e customização dos softwares necessários para manipulação
da documentação entregue (Flow Charting 6, Embarcadero ER/Studio Data
Architect, StarUML, SourceMonitor).
Instalação do ambiente de desenvolvimento e manutenção do Sistema BDE
(Microsoft Visual Studio, Microsoft IIS, Microsoft SQL Server).
Instalação e customização do Sistema BDE.
Análise do Sistema BDE, com a geração de documentação dinâmica (vídeos) da
execução do Sistema, com a pontuação de suas características técnicas.
Análise da documentação entregue do Sistema BDE, que foi gerada com os
softwares Rational Rose, ErWin e Flow4.
Análise estática do código fonte do Sistema BDE com o Software
SourceMonitor.
Análise do Relatório Técnico sobre o BDE, elaborado pela BVR, confrontandoo com o próprio sistema e sua documentação.
Elaboração do Relatório Técnico Final.
Página 9
CAPÍTULO V – ANÁLISE
Elementos levantados:
 A empresa BVR reforçou a posição de que o sistema é de difícil manutenção,
em função da falta de estilo de programação e de padronização nas
nomenclaturas; da baixa coesão das classes e métodos; da redundância de
informações; do número insuficiente de comentários construtivos; e das
documentações e códigos fontes inutilizáveis.
 Quando da visita à empresa BVR, foi constatado que a equipe de manutenção da
BVR tinha sido reduzida a apenas uma pessoa (Elvis Medeiros), que também
estava saindo da empresa, em função do contrato de manutenção do BDE já ter
sido encerrado.
 A empresa Sophia salientou que o BDE é um sistema complexo e que, portanto,
requer uma equipe com pessoas experientes, tornando o processo de manutenção
mais caro. Além disso, informou que não recebeu nenhuma solicitação para
realizar a transferência de conhecimento sobre o sistema para a BVR.
 A documentação fornecida no CD entregue pela CONDEPE/FIDEM foi
elaborada há bastante tempo, e as versões atuais dos softwares que a geraram
não mais conseguem ler os seus respectivos arquivos de forma direta, como no
caso dos arquivos com a extensão ER1, do software ERWin, sendo necessária a
adoção de rotinas de importação e conversão desses arquivos para outros
formatos ou até mesmo a adoção de outro software que reconheça determinadas
extensões, como no caso dos arquivos gerados em Rational Rose, que foram
importados para o software StarUML, por exemplo. Isto demonstra que a
documentação ficou, há muito tempo, defasada, exigindo um trabalho adicional
de pesquisa, instalação e customização dos softwares necessários para
manipulação dessa documentação entregue. Vale ressaltar que foram utilizados
softwares livres para manipulação da documentação entregue, por parte desta
consultoria, uma vez que os valores das licenças das versões atuais ou
equivalentes dos softwares utilizados para gerar tal documentação seriam bem
maiores do que o valor do serviço contratado de avaliação técnica do Sistema
BDE.
 O sistema foi instalado e customizado numa nova máquina de testes do
contratado, num ambiente de desenvolvimento e manutenção criado
especificamente para essa finalidade, e funcionou normalmente.
 O Relatório Técnico sobre o BDE, elaborado pela BVR, foi então analisado,
confrontando-o com o próprio sistema, com a sua documentação e com os
resultados da análise estática do código fonte executada pelo software
SourceMonitor. As informações constantes no referido relatório foram
comprovadas.
Página 10

Durante o processo de análise do Sistema BDE, foi gerada uma nova
documentação dinâmica (vídeos) da execução do Sistema, com a pontuação de
suas características técnicas (vídeos em anexo) aqui reproduzidas de forma
sintética e descritiva.
Analisando o Banco de Dados

Aspectos analisados:
o Segurança:
 Como o sistema foi concebido de forma a ser flexível, com
relação à criação e disponibilização de novos dados, sendo estes
armazenados em um sistema gerenciador de bancos de dados
(MS SQL SERVER), o módulo de controle de acesso ao sistema
criado requer que alguns tipos de usuário cadastrados também
tenham autorizações para manipular os dados diretamente no
banco de dados, o que representa uma prática não recomendada,
causando riscos à segurança da informação e à criação de
inconsistências entre o sistema e o banco de dados.
 Com relação ao controle de acesso, foi criada a tabela
dbo.seg_pessoa e criada uma referência desta tabela com os
usuários do próprio MS SQL SERVER. Quando é criado um
usuário no BDE, também é criado o mesmo usuário na própria
base de dados no MS SQL SERVER. O login do usuário fica
armazenado na tabela dbo.seg_pessoa e a senha fica armazenada
no banco de dados MS SQL SERVER (vide vídeo
BDE_entendendo_base_de_dados.avi).
o Concorrência
 O antigo sistema BDE (em mainframe) utilizava uma tabela única
para armazenamento dos dados dos usuários e, para evitar
problemas de bloqueio da tabela por acessos simultâneos ou o
aumento da complexidade das buscas e a dificuldade para a
importação de dados, foi adotada uma estratégia de utilização de
várias tabelas - um conjunto para cada nova informação.
o Padrão de Nomes
 O Banco de Dados do BDE possui um conjunto de 36 tabelas
básicas, com suas 186 colunas, e mais as tabelas específicas
criadas em tempo de execução, no momento da inclusão de um
novo conjunto de dados. A formação dos nomes das tabelas segue
um padrão, que inicialmente era formado por nomes de 24
posições, respeitando a seguinte regra: “dbo.inf_” + seqüencial
com 8 caracteres + “_” + mneumônico indicativo da informação
contendo 3 caracteres + “.” + 3 outros caracteres. Posteriormente,
essa regra de formação de nomes de tabelas foi modificada, não
se limitando a 24 caracteres. O seqüencial não precisa mais ter
Página 11
o
necessariamente 8 caracteres (com zeros à esquerda) e os
mneumônicos podem ter mais caracteres, deixando mais claro o
conteúdo das tabelas através do seu nome.
Agrupamento de Tabelas
 Para uso do geoprocessamento, foram criadas as tabelas
dbo.KML5,
dbo.map_agregacao,
dbo.map_CoordenadasMunicipais e dbo.map_Municipios.
 Para a associação dos dados alimentados no sistema com as
diversas formas de agregações de regiões, foram criadas as
tabelas:
dbo.loc_pais,
dbo.loc_estado,
dbo.loc_setor,
dbo.loc_bairro,
dbo.loc_cidade,
dbo.loc_distrito,
dbo.loc_subdistrito,
dbo.loc_tipo_local,
dbo.loc_tipo_local_agregacao,
dbo.loc_logradouro,
dbo.loc_tipologradouro,
dbo.loc_divisao_item,
dbo.loc_divisao_regional.
 Para a importação de planilhas eletrônicas, foram criadas as
seguintes
tabelas:
dbo.man_Comp,
dbo.man_implog,
dbo.man_importacao,
dbo.man_mapeamento,
dbo.man_agregacao,
dbo.man_CoordenadasMunicipais
e
dbo.man_Municipios.
Analisando o uso de geoprocessamento


A versão 3.5 do DBE está configurada para utilizar funções de
geoprocessamento do Google Earth e GoogleMaps, possibilitando assim a
visualização de mapas associados aos dados alimentados no sistema. Para tanto,
se faz necessária a utilização de arquivos do tipo KML, contendo as coordenadas
das feições, mais o uso das APIs do Google para manipulação dos mapas. Os
arquivos KML são produzidos pelos usuários e carregados no sistema. Desta
forma, além da visualização dos mapas originais, os usuários poderão realizar
marcações nesses mapas, inserindo pontos, linhas e polígonos de referência e
delimitando e colorindo áreas, por exemplo. No entanto, não foram
implementadas consultas ou análises espaciais (vide apresentação
BDE_3.5_demostrando_google_maps_arquivo_kmz.avi).
O presente trabalho entende que uma solução de geoprocessamento mais ampla
é possível com o uso de ferramentas externas de geoprocessamento, inclusive
com o ArcGis. A solução de softwares implantada para o BDE, baseada na
plataforma da Microsoft, é compatível com a plataforma ArcGis (vide Anexo 2).
A solução de integração passa pelo sistema gerenciador de banco de dados (MS
SQL SERVER) e pelo uso de APIs do ArcServer.
Página 12
Analisando o Sistema BDE:










O Sistema BDE foi criado com uma estrutura de 6 projetos: BDE_ENG,
Biblioteca, BDE, ClassBDE, GráficoSasqChart e WIT_BDE. O projeto default
(padrão) é o BDE e a página inicial é o Default.aspx.
O Sistema não foi desenvolvido totalmente em camadas independentes, a saber,
Apresentação, Negócio e Dados, com a implementação do padrão de projeto
MVC – Model View Controller. Ao contrário, o acesso às bases de dados, a
execução de regras de negócio e a interação com o usuário podem ser
encontrados em vários projetos do BDE.
A conexão com o banco de dados, atualmente, está configurada no arquivo
BDE.ini, que fica localizado na pasta do Windows. Esta foi uma das
modificações feitas pela última empresa contratada para dar manutenção do
sistema, pois as strings de conexão podiam ser encontradas em diversos pontos
da aplicação. No arquivo BDE.ini, podem-se encontrar as configurações para os
vários ambientes. Apenas uma delas deve estar ativa - as demais devem ficar
como comentários. Quando da necessidade de se redirecionar a execução para as
bases de homologação, por exemplo, este arquivo deve ser modificado.
O acesso ao banco de dados é feito através de sentenças SQL, encontradas
dentro dos programas. Esta prática dificulta eventuais migrações de sistemas
gerenciadores de bancos de dados.
O sistema utiliza a biblioteca SasqChart para geração de diversos tipos de
gráficos a serem exibidos aos usuários.
Com relação ao desempenho, verificou-se um tempo de resposta muito longo
para algumas funcionalidades, como por exemplo, quando o usuário entra na
página restrita “Interinstitucional”, e pressiona o botão “Informações”. Neste
caso, o problema foi identificado nos vários erros de javascript e nas sentenças
SQL, que não são muito eficientes.
A visualização de algumas páginas apresenta um comportamento instável,
devido à problemas nos arquivos javascript “.js”e problemas nos arquivos de
configuração “.css” (vide vídeo BDE_3.5_ambiente_interistitucional.avi).
Não foram identificados indícios de fortes investimentos na disciplina de testes,
ou seja, não foram identificados documentos como Plano de Testes, Projeto de
Testes, Casos de Testes e Planilhas de Testes, nem foram identificadas rotinas
implementadas de testes automáticos.
Não foram identificadas práticas nem ambiente de integração contínua para o
Sistema BDE, com a adoção de um processo e ferramentas para a integração de
novos componentes ao código do sistema e verificação se o novo código não
comprometia alguma funcionalidade preexistente.
A avaliação da qualidade do código, feita através do software SourceMonitor e
complementada com a análise por especialista, avaliou as seguintes
características:
Página 13
o
Estilo de programação;

o
Foi usado um padrão de nomes de programas (classes), que
identifica os programas de cadastro (iniciados com “Cad”), de
consultas (iniciados com “Cons”), entre outros, no entanto,
existem muitas exceções, como “DispararImportacao.aspx.vb” e
“DocCaderno.aspx.vb”, por exemplo.
Documentação interna nos códigos;
 Tanto na versão 2.0 (com 0,5%) quanto na versão 3.5 (também com
0,5%), verificamos que o percentual de documentação ficou muito
abaixo do desejável, que seria entre 5% e 20% do código, conforme
Figuras 1 e 2 abaixo.
Figura 1 – Análise Automática de Código da Versão 2.0 do Sistema BDE
Figura 2 – Análise Automática de Código da Versão 3.5 do Sistema BDE
o
Coesão;
 Foram identificados tipos com
apresentado na Figura 3 abaixo:
baixa coesão, conforme
Página 14
Figura 3 – Tipos com Coesão pobre

A ferramenta de análise automática de código nDepend detectou
que a aplicação possui alta coesão e baixo acoplamento,
conforme Figura 4 abaixo:
Figura 4 – Alta Coesão e Baixo Acoplamento
o
Redundância;

Foram detectados trechos de código repetidos em vários
programas,
como
nos
programas
Visualizacao/PopUpCrossTab.aspx.vb,
Visualizacao/GridCrossTab.aspx.vb
e
Estruturacao/GridCrossTab.aspx. Segue trecho repetido:
Página 15



o
Tratamento de erros;

Foram identificados muitos comandos de tratamento de erros que
não seguiram o padrão recomendado de “Try (operação), Catch
(com a especificação e o tratamento de um ou mais tipos
possíveis de erro), Finally (que executaria um trecho de código
independentemente da captura dos erros especificados) e End
Try. Nos casos referidos, houve a omissão do tratamento Finally
e a opção da captura de uma exceção genérica, como no exemplo
abaixo, do programa CadAgregacaoMapas.aspx.vb:















o
'INSERE OS VALORES OU CÉLULAS EM BRANCO,
DEPENDENDO DA LOCALIZAÇÃO OU NÃO DAS
INFORMAÇÕES
For numCol = 1 To val_num
 If flagLin Then
 s2 =
formataInfoTab(dbInfoLin(nivelVis).Tables(0).R
ows(regAtu(nivelVis)).Item("V" & numCol),
val_nat(numCol), val_ext(numCol), 0)
 result += "
<td class='dadoNum_n"
& nivelVis & k & "' nowrap>" & s2 & "</td>" &
vbCrLf

 Else
 result += "
<td class
='dadoNum_n" & nivelVis & k & "'>-</td>" &
vbCrLf

 End If
Next
Public Sub New()
MyBase.New()
Try
'
' Inicializa os objetos de controle de erro e depuração.
'
protocol = New Biblioteca.CProtocol
objErrors = New Biblioteca.CErrors(protocol,
strPastaAplicacao)
objDebug = New Biblioteca.CDebug(strPastaAplicacao)
protocol.Add(objErrors, "_errors")
protocol.Add(objDebug, "_debug")
Catch exp As Exception
'Tratar erro
End Try
End Sub
Estruturação;

O sistema foi dividido em pacotes, e tentou-se separar as camadas
nesses pacotes, sem que este objetivo tenha sido completamente
alcançado. Ou seja, verificamos acesso a base de dados e às
consultas, por exemplo, em vários pacotes, como a seguir:
 Administracao\Catalogo\CadCapitulo.aspx.vb
 Administracao\Catalogo\ConsCapitulo.aspx.vb
 Administracao\ControleDeAcesso\CadGrupoUsuario.aspx
.vb
Página 16

o
Administracao\ControleDeAcesso\ConsGrupoUsuario.asp
x.vb
Segurança;

Foram identificadas vulnerabilidades de segurança no sistema,
como a possibilidade de ataques SQL Injection, pois foram
utilizados comandos Select diretamente no código, que podem
sofrer modificações em tempo de execução, introduzindo-se
comportamentos maliciosos no código. Exemplos, no programa
EngMenuItem.vb:

strQuery = " INSERT INTO CAT_ITEM(CodItemPai,
CodNivelMenu, NomeItem, DescItem, IndPublicado, Posicao,
LinkAcao, IndSistema)" & _
" VALUES (" & codItemPai & "," & codNivelMenu & ",'" &
nomeItem & "','" & descItem & "'," & indPublicado & "," &
posicao & ",'" & linkAcao & "'," & indSistema & ")"
Ou













o
' Recupera todos os itens de menu para o nível informado
'
strQuery = "SELECT * FROM CAT_ITEM WHERE
CODITEMMENU IN " & _
"(SELECT CODITEMPAI FROM CAT_ITEM WHERE
CODITEMMENU IN( SELECT CODITEMPAI FROM CAT_ITEM
WHERE CODITEMMENU " & _
"IN( SELECT DISTINCT MI.CODITEMMENU " & _
"FROM CAT_ITEM MI,CAT_LOCAL_PUBLICACAO MLP,
EST_INFORMACAO EI, EST_PERMISSAO_INFORMACAO
EPF " & _
"WHERE(MI.CODITEMMENU = MLP.CODITEMMENU) " & _
"AND MLP.CODINFORMACAO = EI.CODINFORMACAO " &
_
"AND EI.CODINFORMACAO = EPF.CODINFORMACAO " & _
"AND EPF.CODPERMISSAO = 6 /*PERMISSAO DE ACESSO
RESTRITO*/ " & _
"AND EPF.CODGRUPO In (" & codGrupo & ") ))) " & _
"ORDER BY POSICAO"
ORDER BY nomeItem
Presença de código inativo; e

Foram identificados códigos inativos colocados em forma de
comentários dentro de programas, como o trecho de código do
programa CadInformacao.aspx.vb, descrito abaixo.






Private Sub CarregaComboFonte()
'
' Declaração das variáveis
'
'Dim StringReader As TextReader
'Usado para ler o
XML



Dim dsFonte As DataSet
'Data set que
armazena o retorno da função
'Dim dtSet As New DataSet
'String que
armazena o XML de retorno
Dim oEngFonte As EngFonte
'objeto do tipo
Engenho para acesso aos métodos dessa classe.
Página 17














o
'Dim i As Integer
'Contador
Ou, em outro trecho:
Public Sub AtualizarupgrdCampos(ByVal sender As Object,
ByVal e As EventArgs)
'Caso a session seja True, atualizar o grid
Dim Util As New BCUtil
'ROTINA COMENTADA POR FÁBIO DATA 21/09/2006
NA RETIRADA DO TIMER DO ATLAS
'If Session("upgrdCampos") Then
' Session("upgrdCampos") = False
' CarregarGrid()
' uplblRegistros.Update()
' upgrdCampos.Update()
'End If
Complexidade estrutural.

As Figuras 1 e 2 acima também demonstram que a complexidade
estrutural da aplicação, como um todo, está além do
recomendado, com valores médios de 5,99 (para o BDE 2.0) e
5,91 (para o BDE 3.5), de uma faixa recomendada entre 2,0 e 4,0
pontos. Quando comparados os valores máximos, verifica-se uma
diferença muitas vezes maior: 248 (BDE 2.0) e 249 (BDE 3.5),
de uma faixa aceitável entre 2 e 8 pontos.
Analisando a Documentação:



A documentação existente do Sistema BDE é composta de documentos que
descrevem os seus requisitos funcionais e não funcionais, diagrama de
arquitetura, diagrama de incrementos, diagrama de componentes, diagramas de
pacotes, diagramas de casos de uso, diagramas de seqüência, modelo de dados
(Entidade – Relacionamento), dicionário de dados e protótipo das telas do
sistema, bem como a documentação inserida nos programas (código fonte).
Dentre os itens componentes da documentação, citado acima, apenas os
comentários inseridos nos programas é que foram atualizados ao longo dos anos
de manutenção do sistema, e em maior intensidade no período mais recente.
Mesmo assim, esses comentários são escassos e de pouca ajuda para o
desenvolvedor que for dar manutenção no sistema. O restante da documentação
encontra-se na mesma situação da época do desenvolvimento inicial do sistema
feito pela empresa WIT, apesar do sistema ter sofrido um número muito grande
de adaptações e introdução de novas funcionalidades até a presente data.
A documentação da época do desenvolvimento utilizou ferramentas como o
Flow Chart 4, Rational Rose, ERWin, com a geração de poucas saídas em
formatos mais acessíveis, como imagens e arquivos para web. Isto gera a
necessidade de utilização das versões mais novas dessas ferramentas ou a
importação dos arquivos gerados por meio de outros softwares para permitir a
atualização dessa documentação.
O modelo de dados foi gerado com o software Embarcadero ER/Studio Data
Architect, através do processo de engenharia reversa a partir do script SQL do
Página 18
banco de dados, e posteriormente o modelo foi analisado (vide relatório no
Anexo 4). Este procedimento foi necessário, dado que o arquivo original no
formato .er1 não foi reconhecido pela versão atual do ERWin (software que
gerou o modelo).
Analisando o repasse de conhecimento entre as equipes de desenvolvimento e
manutenção do Sistema BDE:

Parte da equipe que desenvolveu o sistema (da empresa WIT) continuou na
manutenção desse sistema (pela empresa Sophia), em função dessas empresas
pertencerem ao mesmo grupo empresarial. Logo, não foram identificados
maiores problemas de transferência de conhecimento. Isto ocorria apenas nos
momentos do ingresso de novos profissionais na equipe. No entanto, segundo
depoimentos dos executivos tanto da Sophia quanto da BVR, não houve
qualquer fase de transferência de conhecimento entre essas empresas.
Página 19
CAPÍTULO VI – CONCLUSÕES
A análise de todo o material disponibilizado, a realização das entrevistas com as equipes da
CONDEPE/FIDEM, da SOPHIA e da BVR, e o confronto dessas informações levantadas com o
modelo de qualidade de software ISO/IEC 9126 (NBR 13596), levaram a consultoria a concluir
que o Sistema BDE é um sistema: considerado antigo (nove anos desde o início do
desenvolvimento), sob o ponto de vista de uso de tecnologias e metodologias; complexo, pois
ele embute um sistema gerenciador de banco de dados em alto nível (com pouca eficiência e
segurança) e fornece visualizações em vários formatos (tabelas, gráficos e mapas); com uma
documentação desatualizada; e, por tudo isso, de difícil manutenção.
Apesar do exposto acima, a consultoria entende que o Sistema BDE pode (e deve) sofrer
ajustes/manutenções estruturais e outros urgentes, no sentido da correção de falhas, introdução
de novos mecanismos de segurança, aumento do seu desempenho e introdução de novas
funcionalidades, como novas funcionalidades de geoprocessamento, por exemplo, e, conseguir
uma sobrevida razoável. Em especial, a consultoria sugere a manutenção das seguintes
funcionalidades: cadastramento e controle de acesso de usuários; ajustes na modelagem dos
dados, com a introdução dos dados espaciais às bases de dados; desenvolvimento de consultas e
análise espaciais; incorporação de funcionalidades de fóruns de discussão, enquetes, canais de
notícias, etc.; e, correção de erros de execução e de comportamentos instáveis, além de melhoria
de desempenho, em algumas páginas da consulta ao ambiente “Interinstitucional”.
No entanto, para permitir o sucesso das manutenções futuras, se faz necessário que o processo
licitatório para contratação do serviço de manutenção contemple não apenas os requisitos
funcionais, mas também requisitos não funcionais, que visem a manter o sistema sempre
saudável. Exemplos desses requisitos seriam: elaboração e/ou atualização da documentação
correspondente (tanto no código fonte quanto nos documentos e diagramas) a cada intervenção
no sistema; implementação e comprovação da execução de testes automáticos (de
funcionalidades, de carga, de desempenho, etc.), entre outros. Eventualmente, uma
“refatoração” do código, ou seja, a realização de uma reorganização do código, sem mudanças
nas funcionalidades, também pode ser necessária;
Um bom investimento na qualidade do desenvolvimento de um sistema e na sua manutenção
(preventiva e evolutiva) leva o sistema a se manter íntegro, saudável, em melhores condições de
sofrer intervenções emergenciais (manutenção corretiva) de forma mais rápida e confiável.
Manutenções bem sucedidas em sistemas são, normalmente, fruto de um conjunto de fatores:
pessoal técnico qualificado; um bom conhecimento do sistema (que pode ser oriundo de anos de
experiência e/ou de investimento em tempo de estudo de uma boa documentação); um bom
processo de desenvolvimento e manutenção de software; além de ferramentas adequadas. Estes
são outros aspectos que podem ser introduzidos como requisitos nos processos licitatórios de
contratação de serviços de manutenção de sistemas.
No caso específico deste trabalho, constatou-se que a empresa Sophia se beneficiou na
manutenção do BDE, pois contou com parte da equipe que havia desenvolvido o sistema. Já a
BVR, além de não ter conhecimento prévio sobre o sistema, não recebeu o repasse de
Página 20
conhecimento acerca do sistema da empresa Sophia. Esta situação exigiu um esforço e um
tempo adicional para a compreensão do sistema BDE, aliado à dificuldade de dominar um
sistema cuja documentação estava desatualizada.
O desenvolvimento de um novo Sistema BDE sempre é possível. No entanto, a consultoria
entende que o ciclo de vida dessa solução ainda não se esgotou. Foram investidos grandes
volumes financeiros, de tempo e de trabalho, e o sistema ainda atende às necessidades dos
usuários, do ponto de vista das funcionalidades (segundo depoimentos colhidos nas entrevistas
com os próprios usuários), e seria necessário um novo aporte financeiro considerável e um
período relativamente longo (de mais de um ano) para o desenvolvimento de uma nova solução.
Mesmo que a CONDEPE/FIDEM decida pelo desenvolvimento de um novo Sistema BDE, será
necessário contratar um serviço de manutenção para sanar as falhas já identificadas, e as que
virão, até que o novo sistema esteja pronto.
Uma alternativa viável para a substituição do atual Sistema BDE seria a busca de uma outra
solução pronta no mercado, que, dependendo do nível de aderência dessa solução e dos custos
envolvidos, poderia atender aos usuários.
O BDE possui funcionalidades encontradas em algumas categorias de software. O BDE pode
ser entendido como um portal, da categoria CMS – Content Management System (Sistema de
Gerenciamento de Conteúdo). E, como todo portal, não apenas exibe informações, mas também
permite a alimentação de dados e informações, via web. Utiliza um controle de acesso, que filtra
as informações de acordo com o nível de acesso de cada usuário, e possui funcionalidades
avançadas de busca, com o uso de ontologias/taxonomias, vocabulários e palavras chaves
próprias. Além disso, os portais, de um modo geral, oferecem uma plataforma de comunicação
eficiente. O BDE também oferece serviços aos mais diversos pesquisadores e órgãos públicos e
privados, e, portanto, precisa estabelecer uma comunicação mais efetiva com a comunidade de
produtores e consumidores desses dados e informações.
Por outro lado, cresce no mundo, e em especial no Brasil, o movimento em direção a abertura de
dados por parte dos órgãos públicos, quer seja através dos Portais de Transparência ou através
dos Portais de Dados Abertos, todos alavancados pela Lei de Acesso à Informação. Esses
portais, sobretudo os portais de dados abertos, funcionam de forma semelhante ao BDE, com:
funcionalidades para carga de novos dados; de forma descentralizada, via web; com controle de
acesso; facilidades para download de dados, inclusive, de forma automática, numa comunicação
programa a programa; visualizações em vários formatos, inclusive de mapas (vide
http://dados.recife.pe.gov.br); e, uma plataforma de comunicação com comunidades. Os dados
disponibilizados nos portais de dados abertos também devem ser disponibilizados em formato
aberto, no sentido de permitir a sua ampla utilização pela população.
Existem soluções como o Drupal, Wordpress, Joomla, CKAN e DKAN, todas elas livres e
gratuitas, entre outras, que são exemplos de ferramentas estáveis e amplamente utilizadas, da
categoria CMS e que podem ser consideradas na opção de escolha por uma nova solução para o
BDE, inclusive com recursos de geoprocessamento, desde que configuradas, estendidas e
preparadas adequadamente. Vale ressaltar que, apesar dessas ferramentas serem livres e
gratuitas, a sua parametrização e preparação para uma possível substituição do BDE não seria
gratuita, pois exigiriam serviços de consultoria, desenvolvimento (para adaptações e migrações
de dados), treinamento e suporte.
Página 21
ANEXOS
Página 22
ANEXO 1 – CURRÍCULO DO CONSULTOR
Identificação
• Nome: Moisés Batista Leal Júnior
• CPF: 381.092.394-04
• RG: 1.764.867 SSP/PE
• Endereço: Rua Pessoa de Melo, 365, Apto: 902, Madalena, Recife-PE, CEP:
50.610-220
• Fones: (81) 3314.9903 e (81) 9977.9066
• E-mail: [email protected]
Formação Acadêmica
• Mestre em Ciências Geodésicas e Tecnologias da Geoinformação, UFPE,
2006
• Pós-graduação em Gestão por Competências, Faculdade Santa Maria, 2008
• Pós-graduação em Tecnologias da Informação, UFPE, 2000
• Bacharel em Ciências da Computação, UFPE, 1990
Experiência Profissional
• Atualmente, Chefe do Departamento de Suporte à Metodologias e Inovações
da Empresa Municipal de Informática – EMPREL, Recife-PE, empresa onde
trabalha desde 1984, cujo cargo de carreira atual é o de Analista de Informática
III – Grupo Sistemas.
• Assumiu nove cargos gerenciais de áreas diferentes, desde áreas de
desenvolvimento de sistemas, de suporte ao desenvolvimento, de suporte ao
usuário, de atendimento, até a gerência da Assessoria Técnica da Presidência.
• Coordenou vários projetos corporativos, como: a implantação das primeiras
redes de computadores da Prefeitura do Recife e da Emprel; ciclos de
Planejamento Estratégico; criação e atualização da Metodologia Emprel de
Desenvolvimento de Software (MEDS); criação do Padrão Tecnológico de
Referência da Emprel (PTR); criação da Arquitetura de Geoprocessamento
Livre da Emprel, Plano Diretor de Informática (PDI); Plano de Prevenção de
Incidentes na Produção (PPI); o I e II ESLPE (Encontro de Software Livre de
Pernambuco), em Recife-PE, em 2004 e 2008, respectivamente; e o I ESLE
(Encontro de Software Livre na Educação) em 2010, na cidade de João
Pessoa-PB, evento integrante do XXI SBIE (Simpósio Brasileiro de Informática
na Educação), entre outros.
• Trabalha com o Drupal desde 2006, tendo produzido mais de 15 sites nessa
ferramenta e realizado, na qualidade de instrutor, várias turmas de treinamento
em capacitação na instalação, configuração e uso do Drupal para a Emprel e
órgãos usuários.
• Paralelamente ao trabalho na Emprel, atuou como:
• Professor em Qualidade de Software, em 2009, e em Engenharia de
Software, entre os anos de 2007 e 2008, pela Faculdade UNIBRATEC,
em Recife-PE.
• Instrutor em Sistemas de Informação, pela Escola Nacional de
Administração Pública (ENAP), em parceria com a FUNDAJ (Fundação
Joaquim Nabuco), em 2002.
• Palestrante em vários congressos, sobre temas ligados à
metodologias de desenvolvimento de sistemas, geoprocessamento,
Página 23
políticas de TIC (Tecnologias da Informação e Comunicação) e
softwares livres, como por exemplo: INFONORDESTE, em Recife-PE;
FISL (Fórum Internacional de Software Livre), em Porto Alegre-RS;
SECOP, em Florianópolis-SC; LACFREE (Simpósio Latino-Americano e
do Caribe para Desenvolvimento e Uso de Software Livre), em Recife;
GeoLivre Rio, no Rio de Janeiro-RJ; SIMGEO (Simpósio sobre
Geoprocessamento), em Recife-PE, ESLPE (Encontro de Software Livre
de Pernambuco), em Recife-PE, Simpósio de Software Livre do Vale do
São Francisco, em Petrolina-PE; Fórum de Software Livre do SERPRO,
em Recife-PE; Simpósio de Software Livre do 5° CTA (Centro de
Telemática de Área do Exército Brasileiro), em Recife-PE; Fórum de
Soluções em Tecnologia da Informação da Faculdade Maurício de
Nassau, em Recife-PE, entre outros.
• Atuou à disposição da Prefeitura de Jaboatão dos Guararapes entre
1989 e 1990 como:
• Diretor de Desenvolvimento de Sistemas, na Coordenadoria de
Informática, em 1990
• Assessor de Informática da Secretaria de Finanças, quando
participou do grupo que planejou e executou a criação da
Coordenadoria de Informática, em 1989
• Atuou à disposição da Empresa de Fomento do Estado de
Pernambuco – Fisepe em 1988, como Consultor em Projetos de
Informatização, tendo elaborado, em conjunto com a equipe, os Projetos
de Informatização da Secretaria da Fazenda e do Departamento de
Telecomunicações de Pernambuco (DETELPE).
• Primeiro autor do Artigo “ATUALIZAÇÃO TEMPORAL NOS
SISTEMAS
DE
GEOINFORMAÇÃO
PARA
O
CADASTRO
IMOBILIÁRIO. Moisés Batista Leal Júnior, Lucilene Antunes Correia
Marques de Sá. ... (pp.201-215)” publicado pela UNIVERSIDADE
FEDERAL DO PARANÁ, CURSO DE PÓS GRADUAÇÃO EM
CIÊNCIAS GEODÉSICAS no Livro SÉRIE EM CIÊNCIAS GEODÉSICAS
- CARTOGRAFIA, INSTRUMENTO DE RENOVAÇÃO POLÍTICA E
INOVAÇÃO TECNOLÓGICA, VOLUME – 4, ISBN 85 - 88783 – 04 – 5,
Curitiba-PR, 2004.
Página 24
ANEXO 2 – REQUISITOS DE INTEGRAÇÃO MICROSOFT E ESRI
Fonte: http://resources.arcgis.com/en/help/systemrequirements/10.1/index.html#//015100000070000000
Microsoft SQL Server database requirements for ArcGIS 10.1
Relational Database Management Systems
Visit Esri Support for general support information on Esri's Supported Environment Policy as
well as information on earlier versions.
Supported database versions
Standard/Enterprise editions:
Microsoft SQL Server 2012 (64-bit) - See technical article 40559 for more information
Microsoft SQL Server 2008 R2 SP1 (64-bit)
Microsoft SQL Server 2008 SP2 (64-bit)
Express editions:
Microsoft SQL Server 2012 (32-bit & 64-bit) - See technical article 40559 for more information
Microsoft SQL Server 2008 R2 SP1 (32-bit & 64-bit)
Microsoft SQL Server 2008 SP2 (32-bit & 64-bit)
Supported operating systems
Database
Supported Operating Systems
Minimum OS Maximum OS
Version
Version
Windows Server 2012 Standard,
and Datacenter (64-bit
(EM64T))**
Microsoft SQL Server 2012 (64bit)
See technical article 40559 for
more information
Windows Server 2008 R2
Standard, Enterprise, and
Datacenter (64-bit [EM64T])
SP1
Windows Server 2008 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Microsoft SQL Server 2008 R2
Windows Server 2012 Standard,
(64-bit) or Microsoft SQL Server and Datacenter (64-bit
2008 (64-bit)
(EM64T))**
Página 25
Windows Server 2008 R2
Standard, Enterprise, and
Datacenter (64-bit [EM64T])
SP1
Windows Server 2008 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Windows Server 2003 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Windows Server 2012 Standard,
and Datacenter (64-bit
(EM64T))**
Microsoft SQL Server 2012
Express (64-bit)
See technical article 40559 for
more information
Windows Server 2008 R2
Standard, Enterprise, and
Datacenter (64-bit [EM64T])
SP1
Windows Server 2008 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Windows 7 Ultimate,
Enterprise, Professional, Home
Premium (64-bit [EM64T])
SP1
Windows Vista Ultimate,
Enterprise, Business, Home
Premium (64-bit [EM64T])
Microsoft SQL Server 2012
Express (32-bit)*
See technical article 40559 for
more information
SP2
SP2
Windows Server 2008 Standard,
Enterprise, and Datacenter (32- SP2
bit)
SP2
Windows 7 Ultimate,
Enterprise, Professional, Home
Premium (32-bit)
SP1
Windows Vista Ultimate,
Enterprise, Business, Home
Premium (32-bit)
SP2
SP2
Microsoft SQL Server 2008 R2
Windows Server 2012 Standard,
Express or Microsoft SQL Server and Datacenter (64-bit
Página 26
2008 Express (64-bit)
(EM64T))**
Windows Server 2008 R2
Standard, Enterprise, and
Datacenter (64-bit [EM64T])
SP1
Windows Server 2008 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Windows 7 Ultimate,
Enterprise, Professional, Home
Premium (64-bit [EM64T])
SP1
Windows Vista Ultimate,
Enterprise, Business, Home
Premium (64-bit [EM64T])
SP2
SP2
Windows Server 2003 Standard,
Enterprise, and Datacenter (64- SP2
bit [EM64T])
SP2
Windows Server 2008 Standard,
Enterprise, and Datacenter (32- SP2
bit)
SP2
Windows 7 Ultimate,
Enterprise, Professional, Home
Premium (32-bit)
SP1
Microsoft SQL Server 2008 R2
Windows Vista Ultimate,
Express or Microsoft SQL Server
Enterprise, Business, Home
2008 Express (32-bit)*
Premium (32-bit)
SP2
SP2
Windows Server 2003 Standard,
Enterprise, and Datacenter (32- SP2
bit)
SP2
Windows XP Professional
Edition, Home Edition (32-bit)
SP3
SP3
*Microsoft SQL Server Express (32-bit) is only supported for Desktop geodatabases.
**Support begins at ArcGIS 10.1 SP1.
Operating system limitations
Página 27
Only instances of SQL Server Express are supported on Windows 7, Vista and XP operating
systems in a production environment. When used with Standard or Enterprise editions of SQL
Server, Windows 7, Vista and XP operating systems are supported for testing and application
development use only.
Software required to connect to a DBMS
Your client machine (for example, the one running ArcMap) will need to have the appropriate
client files installed for the RDBMS you are using. These client files are available from their
respective RDBMS vendors, but they are also available on Esri Customer Care Portal as a
convenience. Please see Database clients for more information. RDBMS client files available
from the customer care portal are IBM DB2, IBM Informix, Oracle, PostgreSQL, Microsoft SQL
Server, and Microsoft Windows Azure SQL Database. Client files for Netezza and Teradata are
not available on the customer care portal and must be obtained from the IBM and Teradata
support sites.
Página 28
ANEXO 3 – REQUISITOS DE INTEGRAÇÃO DE SOFTWARES LIVRES
COM O ARCGIS
Fonte: http://resources.arcgis.com/en/help/system-requirements/10.1/index.html#/PostgreSQL_Database_Requirements/015100000075000000/
PostgreSQL database requirements for ArcGIS 10.1
Relational Database Management Systems
Visit Esri Support for general support information on Esri's Supported Environment Policy as
well as information on earlier versions.
Supported database versions
PostgreSQL 9.0.5 (64-bit)
PostgreSQL 9.1.3 (64-bit)*
Supported add-ons:
PostGIS 1.5.1
PostGIS 2.0*
Supported operating systems
Database
Supported Operating Systems
Minimum OS
Version
Maximum OS
Version
Red Hat Enterprise Linux Server 5 (64-bit) Update 7
Red Hat Enterprise Linux Server 6 (64-bit)
SUSE Linux Enterprise Server 11 (64-bit)
PostgreSQL 9.0.5
Windows Server 2003 Standard,
(64-bit)
Enterprise, and Datacenter (64-bit
[EM64T])
SP1
SP2
Windows Server 2008 R2 Standard,
Enterprise, and Datacenter (64-bit
[EM64T])
SP2
SP1
Red Hat Enterprise Linux Server 5 (64-bit) Update 7
PostgreSQL 9.1.3
Windows Server 2008 R2 Standard,
(64-bit)*
Enterprise, and Datacenter (64-bit
[EM64T])
SP1
*Support begins at 10.1 SP1. See technical article 40553 for more information.
Página 29
Database requirements/limitations
Refractions Research PostGIS 1.5.1: PostGIS Geometry Spatial Type is supported.
Refractions Research PostGIS 2.0: PostGIS Geometry Spatial Type is supported starting at 10.1
SP1.
Operating system limitations
Linux
ArcSDE for PostgreSQL is only supported on:
Linux x86_64, on CPUs that adhere to the x86_64 architecture (64-bit), with supported Linux
releases.
Required configuration for SUSE 11:
With ArcSDE for PostgreSQL and SUSE 11 installation, copy the libpq.so, libpq.so.5, and
libpq.so.5.3 libraries from the PostgreSQL library directory to the $SDEHOME/lib directory
logged in as sde user first before creating the geodatabase.
Windows
Refractions Research PostGIS 1.5.1 does not have a build for Windows 64-bit.
Refractions Research PostGIS 2.0 is supported on Windows 64-bit starting at 10.1 SP1.
Software required to connect to a DBMS
Your client machine (for example, the one running ArcMap) will need to have the appropriate
client files installed for the RDBMS you are using. These client files are available from their
respective RDBMS vendors, but they are also available on Esri Customer Care Portal as a
convenience. Please see Database clients for more information. RDBMS client files available
from the customer care portal are IBM DB2, IBM Informix, Oracle, PostgreSQL, Microsoft SQL
Server, and Microsoft Windows Azure SQL Database. Client files for Netezza and Teradata are
not available on the customer care portal and must be obtained from the IBM and Teradata
support sites.
Página 30