estudo de caso de uma estratégia de desenvolvimento

ESTUDO DE CASO DE UMA ESTRATÉGIA DE
DESENVOLVIMENTO INCREMENTAL DE SISTEMA DE BANCO
DE DADOS CORPORATIVOS
MSc. Denis Ávila Montini (ITA) [email protected]
MIT. Daniela América da Silva (ITA) [email protected]
BSc. Gabriel de Souza Pereira Moreira (ITA) [email protected]
PhD. Luiz Alberto Vieira Dias (ITA) [email protected]
DSc. Adilson Marques da Cunha (ITA) [email protected]
Resumo: Este estudo de caso aborda a aplicação de um método iterativo, integrado e
incremental baseado em heurísticas para o desenvolvimento de um projeto de sistema de
bancos de dados. Para isso, aplicativos de banco de dados foram desenvolvidos e integrados,
inicialmente, no nível setorial, em seguida no nível corporativo e posteriormente no nível de
uma empresa holding. A consolidação dos aplicativos de banco de dados no nível setorial até
o nível holding resultou no projeto de uma data warehouse de CMMI nível 3. O trabalho
apresenta o aumento da eficiência no processo de desenvolvimento e a redução da
probabilidade de ocorrência de defeitos, erros e falha na produção de um software.
Adicionalmente, este artigo demonstra que o desenvolvimento de um sistema para uma
Corporação ou Join Venture requer um conjunto de processos e métodos estruturados, que
visam à integração incremental de sistemas aplicativos de banco de dados.
Palavras-chave: Banco de Dados Corporativos, Desenvolvimento de Sistemas de Banco de
Dados; Experiência acadêmica de Graduação e Pós-Graduação; Estratégia de Integração
Iterativa no desenvolvimento de processos com times distribuídos.
1. Introdução
Os processos de fusões e aquisições de empresas, definidos como Join Ventures, são
cada vez mais comuns e requerem um método organizado e estruturado para que seus
sistemas de informação sejam integrados e unificados. Neste artigo apresentou-se um método
integrado baseado em heurísticas (CUNHA, 2007a) (CUNHA, 2007b), que permitem
uniformizar conceitos e que referenciam padrões de qualidade utilizados também em linha de
produção de software (MONTINI et al, 2005) (MONTINI et al, 2006). Este método permite o
gerenciamento de requisitos nos níveis operacional, tático e estratégico. A utilização de
heurísticas propicia a integração, o aumento da eficiência no processo de desenvolvimento e
redução da probabilidade de ocorrência de defeitos, erros e falha na produção de um software
(HUMPHREY, 1989). Adicionalmente, este artigo demonstra que o desenvolvimento de um
sistema para uma Corporação ou Join Venture requer um conjunto de processos e métodos
estruturados, que visam à integração incremental de sistemas aplicativos de banco de dados
(DATE, 2000).
Neste artigo, apresentou-se um conjunto de processos e métodos estruturados que
visou aumentar o grau de maturidade de gestão de projetos nos seguintes quesitos: qualidade
do processo de desenvolvimento de software, minimização de riscos, contingenciamento e
redução do desperdício de recursos envolvidos no desenvolvimento, manutenção, suporte e
organização do projeto (SILBERSCHATZ, 1999) (NEPOMUCENO, 2002). Este processo
suportou eficazmente a aplicação das ferramentas, técnicas e procedimentos selecionados para
Projetos de Sistemas de Banco de Dados.
1
Pelo sexto ano consecutivo, foi ministrada, no Instituto Tecnológico de Aeronáutica –
ITA, uma experiência prática de desenvolvimento integrado e incremental de um Projeto de
Sistemas de Bancos de Dados, nos Programas de Graduação e de Pós-Graduação em
Engenharia da Computação. Este artigo descreve também a aplicação de ferramentas de
desenvolvimento para o ambiente de arquitetura de aplicação com o SGBD Oracle 10g
Spatial (ORACLE, 2007), como suporte ao desenvolvimento de um caso de sucesso,
realizado nas disciplinas de Técnicas de Bancos de Dados (CES-30) (CUNHA, 2007a) e
Projeto de Sistemas de Bancos de Dados (CE-240) (CUNHA, 2007b), no primeiro semestre
do ano de 2007.
Através de um Estudo de Caso, é demonstrado o nível de utilização e aplicação de um
conjunto de procedimentos (SILVA et al, 2003) orientados ao uso de ferramentas de software.
O escopo principal é a organização dos passos que se desdobraram na utilização de uma
estratégia de desenvolvimento de um Protótipo de Sistema de Banco de Dados, passando por
quatro níveis de integração, a partir de Aplicativos de Banco de Dados (ABD), Bancos de
Dados Setoriais (BDS), Bancos de Dados Corporativos (BDC), até a integração no Banco de
Dados de uma Holding (BDH). Esta estratégia de desenvolvimento visou melhorar a
eficiência corporativa e reduzir o desperdício de recursos, na fusão entre duas Corporações
fictícias, formando uma Join Venture.
2. Sistemática Empregada
A sistemática empregada descreve um processo de desenvolvimento de aplicativos de
Banco de Dados dividido em três macro-atividades: a Pré-análise, a Análise e o Projeto
Lógico.
2.1 Pré-Análise
As técnicas de pré-análise apresentadas foram aplicadas pelos alunos para estabelecer
a política do desenvolvimento, ou seja, o que o sistema proposto deveria realizar. As seis
técnicas mencionadas a seguir representam uma seqüência lógica de desenvolvimento que
facilitam o trabalho de construção de um projeto eficaz e de qualidade (CUNHA, 2001), visto
que terá atendido aos requisitos inicialmente especificados, resolvendo o problema abordado
com uma solução adequada, praticável e aceitável.
2.1.1 Tematização
A primeira Técnica de banco de dados utilizada foi a Tematização, que consistiu na
seleção de uma Temática Principal e duas Temáticas Alternativas para a Pesquisa e o
Desenvolvimento de um Aplicativo de Banco de Dados (BD), individualmente, para cada
aluno que participou do processo, até a definição da Temática da Holding para uma Empresa
fictícia denominada MONITORAMA.
2.1.2 Motivação
A motivação foi um cenário de Jogos de Empresas objetivando integrar os Aplicativos
de Banco de Dados em um Banco de Dados Setorial; seguido da integração em um Banco de
Dados Corporativo, que visou melhorar a eficiência corporativa, testando o aumento das
funcionalidades e a redução do desperdício de recursos. As Turmas de Graduação e de PósGraduação em Engenharia da Computação de 2007 do ITA, que participaram do projeto
acadêmico foi composta por 39 alunos, sendo 26 Graduandos do 5º Ano de Computação,
cursando a Disciplina CES-30, e 13 Pós-Graduandos, cursando a Disciplina CE-240, ambas
no 1º Sem de 2007. A proposta em questão previu a elaboração imediata de um Anteprojeto
de BD para a Empresa MONITORAMA, que estaria se instalando ficticiamente, a partir do 2º
Semestre de 2007, em um Cenário de Simulação de Jogos de Empresas no MERCOSUL,
2
aproximando-o ao máximo possível da realidade.
2.1.3 Contextualização
Os alunos inseridos no projeto redigiram a sua contextualização, incrementalmente,
descrevendo a síntese do negócio no nível de Aplicativos de Banco de Dados, Bancos de
Dados Setoriais, Bancos de Dados Corporativos, e um Banco de Dados Holding com o nível
de detalhamento adequado para cada fase. O contexto geral do projeto MONITORAMA teve
como meta propiciar a Agência Nacional de Águas (ANA) efetuar o monitoramento das águas
da Amazônia, uma das maiores riquezas do século XXI.
Um ponto de importância para a preservação das águas é a preocupação com os rios, e
conseqüentemente, com todo o sistema hídrico e, para tanto, é necessário monitorá-lo para
garantir sua preservação. Para propiciar tal meta, o Sistema de Software de Computador
(SSC) a ser desenvolvido trata-se de uma base de dados que será alimentada por Pontos de
Coleta de Dados (PCDs) (INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS, 2007)
distribuídos estrategicamente na região. Cada PCD tem a função de armazenar os dados e
fornecer as informações corretas mediante solicitação de transmissão via satélite, rádio ou
celular (SQUITTER, 2007). O sistema além de receber os dados, poderá reinicializar ou
atualizar o PCD para correção de falhas. Para tanto, é necessário identificar a localização dos
PCDs, e seus respectivos núcleos de controle.
Atualmente, a Agência Nacional de Águas – ANA vem operando uma rede de
estações em todo o Brasil e, em particular, nos estados e municípios da Região Amazônica.
Contudo, não há um sistema em operação capaz de interpretar, categorizar e manter o
conjunto de dados obtidos a partir de núcleos internacionais e regionais, disponibilizando-os
em tempo real para consultas de forma apropriada (GLASGOW et al, 2004)
(GUNATILAKA, 2003). O resultado deste projeto será um aumento no volume e na
disponibilidade de dados ambientais para que a sociedade possa usufruir ao máximo dos
benefícios propiciados por esta tecnologia.
2.1.4 Objetivação
Os participantes foram chamados a exercitar a “heurística do objetivo”, extraída do
curso de oficiais da aeronáutica, apresentada nas disciplinas, na Definição do Problema e na
Definição da Solução de seus próprios Aplicativos de Bancos de Dados e, a cada fase da
integração, a adaptarem o escopo do objetivo para representar, resumidamente, o banco de
dados em sua representação atual (CUNHA, 2001) (ESCOLA DE COMANDO E ESTADO
MAIOR DA AERONÁUTICA, 1990) (DAVIS, 1982).
2.1.4.1 Elementos do Problema
Para definir a Tarefa (T) e o Propósito (P) do problema em questão foi necessário
identificar, primeiramente, a Causa (C) do problema e quais os Efeitos Adversos (EA) do
mesmo. Após pesquisar sobre o Monitoramento de Águas da Amazônia, os participantes do
projeto concluíram que a degradação dos sistemas hídricos da Amazônia (EA) se deve à
dificuldade, por parte dos governantes, de mecanismos práticos para acesso a dados históricos
e a informações atualizadas e consistentes sobre a situação atual das bacias, rios, nascentes,
represas e capacidade dos Pontos de Coleta de Dados (PCD) disponíveis (C).
2.1.4.2 Enunciado do Problema
No enunciado do problema foi apresentada a Tarefa (T), que removeria as Causas C, e
o Propósito (P), que eliminaria os Efeitos Adversos (EA): “Prover mecanismos para acesso às
informações de monitoramento dos recursos hídricos da Bacia Amazônia (T), a fim de que
seja possível, a partir da análise destes dados, uma proposição de medidas eficazes para a
3
conservação dos recursos hídricos e melhoria de utilização da água desta região, durante o
primeiro semestre de 2007 (P)”.
2.1.4.3 Enunciado da Solução
Como pré-requisito da disciplina utilizou-se a técnica da Análise de Adequabilidade,
Praticabilidade e Aceitabilidade – APA, que consistiu numa série de critérios para avaliação
de Alternativas de Solução para um problema proposto (CUNHA, 2001) (ESCOLA DE
COMANDO E ESTADO MAIOR DA AERONÁUTICA, 1990) (DAVIS, 1982).
O enunciado da solução consiste em: “Dotar a ANA de um sistema de software para
coleta de dados, monitoramento hidrológico, transporte hidroviário, gestão de competências e
geração de alertas da Bacia Amazônica, até a segunda quinzena de junho de 2007, com o
propósito de fornecer mecanismos para a obtenção de informações atualizadas e corretas, e a
disponibilização das mesmas para os órgãos competentes, a fim de embasar uma proposta de
ações e medidas que visem à preservação dos recursos hídricos da Amazônia”.
2.1.5 Intitulação
Na técnica de Intitulação apresentada aos alunos, o título de um trabalho deve derivar
da tarefa da alternativa de solução escolhida. Como exemplo, o título da proposta de
desenvolvimento para o sistema de Banco de Dados Holding da MONITORAMA será
“Sistema Georeferenciado de Monitoramento de Águas da Bacia Amazônica”.
2.1.6 Especificação de Requisitos
Na definição da especificação de requisitos apresentada neste artigo, não foi
desenvolvido o tema de elicitação de requisitos, mas uma análise pelos alunos da Request For
Proposal - RFP, especificada pela disciplina. Para fins didáticos, uma Especificação de
Requisitos poderia, por exemplo, ser composta apenas de 5 +/- 2 (de 3 a 7) itens, a serem
conformados, verificados e validados em fase posterior, quando o sistema da Holding estiver
pronto. Utilizando-se a técnica de Especificação de Requisitos tem-se, como exemplo, o
Banco de Dados Holding para Monitoramento de Águas da Bacia Amazônica. Neste estudo
de caso, o banco de dados escolhido para a implementação deste projeto foi o SGBD Oracle
10g Spatial, e para a Modelagem Entidade-Relacionamento (MER), o software ERWin 4.0
(ERWIN, 2000). O sistema deveria ser capaz de propiciar 7 requisitos, conforme descrito na
Tabela 1.
TABELA 1 – Requisitos do Sistema de Banco de Dados.
1. Captação de dados georeferenciados das bacias, rios, nascentes e represas, quanto a diversos aspectos, como
por exemplo: vazão, curso e qualidade da água;
2. Identificação da localização georeferenciada dos PCDs e respectivos núcleos de controle;
3. Comunicação com os PCDs, tipos de transmissão de dados, controle de programas e registro de defeitos,
erros e falhas;
4. Fornecimento de informações referentes ao transporte hidroviário na Bacia Amazônica, características e
finalidades;
5. Fornecimento de dados atualizados sobre as informações cadastrais dos recursos humanos envolvidos nos
trabalhos dos diversos setores;
6. Geração de alertas, a partir da análise de séries históricas e
7. Disponibilização de dados estratégicos sobre a região Amazônica.
4
2.2 Análise
2.2.1 Estratégia de Integração
Na estratégia de integração, definiu-se que o menor número possível de alterações
deveria ser realizado durante o processo iterativo de modificações nos Modelos de Dados
Corporativos (DATE, 2000) das duas Empresas, até a formação da Join Venture. O tipo de
abordagem de ensino aplicado com sucesso pelo professor da disciplina, é conhecido como
Problem-Based Learning – PBL, e demonstrou-se efetivamente capaz de contribuir com o
aprendizado dos alunos, em nível de compreensão, na construção do Protótipo de um Sistema
de Banco de Dados inserido num cenário de Jogos de Empresas. A primeira fase de
integração foi à unificação dos modelos de dados dos Aplicativos de Bancos de Dados,
implementados individualmente pelos alunos, em Bancos de Dados Setoriais. Para facilitar a
integração dos sistemas de banco de dados e distribuir o trabalho, foram definidos papéis e
responsabilidades. Os grupos de trabalho foram organizados com uma subdivisão de:
Integradores, Normalizadores, Dicionarizadores e Suporte Técnico. Estes papéis foram
desempenhados conforme especificado abaixo:
1) Os Integradores exerceram a função precípua de integrar globalmente todos os
Aplicativos de BD num único BDC, e posteriormente, num único BDH, compatibilizando-os
com as “necessidades corporativas da Empresa” (re-contextualizando, re-objetivando, reintitulando e re-especificando os requisitos).
2) Os Normalizadores exerceram a função precípua de integrar os Modelos de Dados
Setoriais (MDS) e as suas cardinalidades em um só modelo de dados conceitual ou Modelo de
Dados Corporativo - MDC (Corporate Data Model), e posteriormente, num único Modelo de
Dados da Holding - MDH (Holding Data Model), compatibilizando-os com as “necessidades
corporativas da Empresa”, que prevalecem sobre as setoriais.
3) Os Dicionarizadores exerceram a função precípua de integrar os dicionários de
dados dos BDS em um só Dicionário de Dados Corporativo, e posteriormente, em um único
Dicionário de Dados Holding.
4) Os Suportes Técnicos exerceram a função precípua de documentar os Protótipos
dos Manuais do Sistema, de Operação e do Usuário de BD Corporativo da Empresa para gerar
e publicar as versões mais atualizadas dos tutoriais, heurísticas, manuais e demais artefatos,
para melhor suportar os demais participantes das Disciplinas.
Na primeira fase, com base nas diretrizes estabelecidas, na infra-estrutura disponível,
no contingente humano e no escopo definido, coube às equipes de Inteligência Tática
estabelecer a maneira pela qual se daria a integração. O projeto do Protótipo de Sistema de
Banco de Dados para a Holding MONITORAMA envolveu os 4 níveis de abstração descritos
na Tabela 2.
TABELA 2 – Níveis de Integração.
1) Aplicativo de Banco de Dados (ABD)
2) Banco de Dados Setorial (BDS)
3) Banco de Dados Corporativo (BDC)
4) Banco de Dados da Holding (BDH)
A estratégia estabelecida foi a de que cada Grupo de integrantes de um BDS,
composto por 3 ou 4 Aplicativos de Banco de Dados, propiciasse a Integração do seu Modelo
de Dados Setorial (MDS) com os demais MDS, formando um só Modelo de Dados
Corporativo (MDC). A estratégia de integração dos Modelos de Dados Setoriais num Modelo
5
de Dados Corporativo consistiu na organização dos integrantes em frentes de trabalho,
descrita na Figura 1.
FIGURA 1 – Modelo de estratégia de Integração em quatro frentes de trabalho.
Dessa forma, cada frente trabalhou paralelamente na primeira fase do projeto. Na
segunda fase, os modelos de dados gerados pelas frentes foram integrados num Modelo de
Dados Corporativo, e posteriormente, num Modelo de Dados da Holding, de acordo com a
Figura 1. Esta forma de organização do trabalho representou inovação em relação aos projetos
acadêmicos realizados por grupos de trabalho de turmas anteriores a estas disciplinas. A
estratégia de trabalho, elaborada pelos alunos quando se depararam com a quantidade de
esforço necessário e o prazo reduzido para a integração, consistiu em dividir e integrar os
Bancos de Dados Setoriais (BDS) ou “Subject Databases” em quatro frentes de trabalho, para
estabelecer um processo de integração em duas etapas. Na primeira etapa, cada uma das
frentes de trabalho foi integrada num Modelo de dados, por afinidade, de forma a existirem na
segunda etapa três modelos de dados que deveriam ser integrados, o que resultaria no Projeto
do Sistema de BD Corporativo da Empresa,visando melhorar a sua eficiência corporativa e
reduzir o seu desperdício de recursos.
A segunda fase consistiu em integrar os Modelos de Dados de cada BD Corporativo
(SIG-PT e SIG-PA), visando melhorar a eficiência da Holding e reduzir o desperdício de
recursos. Em cada reunião de integração, a orientação foi de que os alunos representassem o
seu respectivo papel dentro do Grupo de Banco de Dados Setorial nas Reuniões Funcionais
Corporativas (de Normalizadores, Integradores, Dicionarizadores, ou Suportes Técnicos),
visando à obtenção do melhor nível possível de integração corporativa.
A criação do Banco de Dados Corporativo SIG-PT (Sistema Georeferenciado de
Processamento Transacional) foi obtida através da composição de três frentes de trabalhos
para integrar o seu BDS com a organização. A adoção de uma estratégia por afinidade de
assuntos de obtenção dos bancos de dados foi decisiva para gerenciar a complexidade e
atingir os resultados esperados no prazo estipulado. A criação do Banco de Dados
Corporativo SIG-PA (Sistema Georeferenciado de Processamento Analítico) foi obtida
através de uma só frente de trabalho. Dessa forma, para a criação do Banco de Dados da
Holding, foram utilizadas um total de quatro frentes de trabalho, descritas na Tabela 3.
TABELA 3 – Estratégia para a criação do Banco de Dados Holding
SIG-PT: Sistema
Frente 1 - Recursos Humanos (PT-RHU) e Transportes (PT-TRA).
Georeferenciado de
Processamento Transacional Frente 2 - Núcleos de Controle (PT-NCT), Comunicação PCD’s (PT-COM) e
Controle PCD’s (PT-CTL).
Frente 3 - Rios (PT-RIO), Bacias (PT-BAC), Nascentes (PT-NAS), Represas
(PT-REP).
6
SIG-PA: Sistema
Georeferenciado de
Processamento Analítico.
Frente 4 - Atualização de Views (PA-ATV), Cálculo de Séries Históricas (PACSH), Alertas e Estatísticas Periódicas (PA-AEP).
2.2.2 Estratégia de Modelagem
A partir do contexto do negócio, foram identificadas as entidades envolvidas no
monitoramento de águas. Basicamente, foi utilizada a convenção clássica composta de projeto
lógico e a sua implementação com um modelo físico.
2.2.2.1 Projeto Lógico
Os modelos de dados com suas cardinalidades foram divididos em dois tipos: modelo
de dados lógico (Modelo Entidade Relacionamento - MER) e modelo de dados físico (Modelo
Relacional – MR) que, neste projeto foram inseridos na ferramenta CASE ERWin 4.0.
Na execução dos ciclos de integração sucessivos, em 4 (quatro) diferentes níveis, com
duração de duas semanas cada um, obteve-se 12 (doze) Bancos de Dados Setoriais de Nível 1,
4 (quatro) Bancos de Dados Setoriais de Nível 2, 2 (dois) Bancos de Dados Corporativos de
Nível 3, e 1 (um) Banco de Dados da Holding.
Para verificação dos Bancos de Dados descritos acima, os mesmos foram fisicamente
implementados e populados. Também foram elaboradas e executadas consultas por meio de
uma Structured Query Language (SQL).
Desta forma, este experimento prático permitiu o desenvolvimento de um Protótipo de
um Banco de Dados Holding, por integrações sucessivas de uma Empresa fictícia e a
realização de um conjunto de Consultas Operacionais, Táticas e Estratégicas, para apoiar
decisões, destes mesmos tipos, nos níveis Setorial, Corporativo e Holding.
2.2.2.2 Projeto Físico
O modelo de dados físico, correspondente ao modelo de dados lógico, foi inserido no
ERWin 4.0. A modelagem integrada num Banco de Dados Corporativo (BDC) ou “Corporate
Database”, visou testar o aumento de funcionalidade da integração, utilizando um SGBD
previamente escolhido e possibilitou verificar a melhoria de sua eficiência corporativa bem
como a redução do desperdício de seus recursos.
Anomalias detectadas após a criação do esquema do BDC no Oracle 10g Spatial,
foram corrigidas através de scripts incrementais para alteração de tabelas e de campos, reimportados novamente para o MER, para mantê-lo atualizado. Para o Banco de Dados
Corporativo, foi elaborada uma síntese da documentação das integrações dos Bancos de
Dados Setoriais, inseridos no contexto corporativo.
A implementação do Projeto físico foi realizada através da criação da Estrutura do
Banco de Dados da Holding em Linguagem de Definição de Dados – LDD (Data Definition
Language – DDL). A criação do Banco de Dados ocorreu em cada nível de abstração,
utilizando-se esquemas distintos no banco de dados Oracle 10g Spatial, disponibilizado no
Laboratório da FCMF.
A Figura 4 apresenta, por nível de abstração, os itens mais importantes do processo de
integração de um Banco de Dados Setorial. Para fins de demonstração, apresenta-se a
integração do Banco de Dados Setorial “Controle de PCDs”, na Holding MONITORAMA.
7
FIGURA 2 – Processo de Integração do BDS para o “Controle de PCD” na Holding MONITORAMA.
2.2.3 Processo de Normalização
Para a Normalização dos Bancos de Dados Corporativos e da Holding, os
Normalizadores exerceram a função de integrar os modelos de BDS e suas cardinalidades em
um único MDC (Corporate Data Model), e posteriormente, num único MDH (Holding Data
Model). No nível corporativo, foram compatibilizadas as necessidades corporativas da
empresa, que prevaleceu sobre as setoriais. E no nível holding, foram compatibilizadas as
necessidades da Holding, que prevaleceu sobre as corporativas. Uma auditoria de
normalização foi realizada, através de uma verificação da especificação das dependências
funcionais das entidades, utilizando-se o aplicativo Third, que ao ser utilizado em todos os
níveis de integração, não constatou anomalias referentes à normalização do Banco de Dados
da Holding.
As anomalias eliminadas no processo de normalização referem-se: 1) A eliminação
das tabelas que se tornaram duplicadas após a integração num BDC, sendo mantida apenas
uma delas, que englobasse campos complementares da tabela semelhante; 2) A renomeação
de tabelas de mesmo nome, mas funções diferentes; e 3) Ao processo iterativo de auditoria de
Terceira Forma Normal (3FN), para garantir uma normalização eficaz para o banco de dados.
FIGURA 3 – O processo de Normalização do BDS para o “Controle de PCD” na Holding MONITORAMA.
2.2.4 Processo de Dicionarização e Trigramação
Os Dicionarizadores realizaram a função precípua de integrar os dicionários de dados
dos seus BDS em um Sistema de Dicionário de Dados, composto pelo Dicionário de Dados
Corporativo, Diretório de Dados, Dicionário de Meta Dados e Dicionário de Recursos de
Dados; compatibilizando-os com as “necessidades corporativas da Empresa”, que deverão
sempre prevalecer sobre as necessidades setoriais. E posteriormente, o compatibilizaram com
as “necessidades da Holding” que deveriam prevalecer sobre as necessidades corporativas.
Apresenta-se, a seguir, o processo de evolução da dicionarização. Neste exemplo são
8
demonstrados os passos principais para a dicionarização do Banco de Dados Setorial de
“Controle de PCD” na Holding MONITORAMA.
FIGURA 4 – O processo de Dicionarização do BDS para o “Controle de PCD” na Holding MONITORAMA.
2.2.5 Auditoria de Modelo e de Projeto de Aplicativos de BD
Esta fase do projeto consistiu na exploração de jogos de empresas, objetivo este
suportado pela estratégia de consultas. Esta estratégia foi utilizada em todos os níveis de
abstração durante as Disciplinas, de forma a possibilitar a modelagem, pelo menos de forma
acadêmica, nas turmas de Graduação e de Pós-Graduação do ITA de 2007. Também foi
utilizada a Tecnologia de Bancos de Dados Corporativos em cenários de suporte a Engenharia
da Informação. Os Aplicativos de Banco de Dados foram desenvolvidos no contexto
Administrativo-Operacional, Setorial e Corporativo de Sistemas de Informação, voltados à
execução de Cenários Operacionais de Jogos de Empresa. Diversas evidências foram
apresentadas com a formulação de queries, utilizando a linguagem de 4ª geração SQL, ao
longo deste trabalho e em todos os níveis de abstração do processo de integração. A
experiência acadêmica de um exercício de Jogos de Empresas como este nos Cursos de
Graduação e de Pós-Graduação do ITA, implementando-os em ambiente ORACLE 10g
Spatial, foi compensadora devido ao fato de que os alunos vivenciaram as atividades
realizadas por uma empresa desenvolvedora e integradora de soluções. Concluiu-se que, sem
a exposição da disciplina e sem um estágio supervisionado, os alunos dificilmente abstrairiam
e vivenciariam este grau de maturidade e capacitação.
3. Projeto Lógico de Aplicativos de Bancos de Dados
As atividades para o projeto lógico de Aplicativos de Bancos de Dados são iterativas
seguindo a proposta do Rational Unified Process - RUP (RUP, 2001), e de acordo com a
estratégia da Disciplina, descreve-se a seqüência das atividades, passando pelos níveis de
ABD, BDS, BDC e BDH, estabelecidas para suas integrações. Utilizaram-se no total 26
Técnicas para o Projeto de Sistemas de Banco de Dados descritas na Tabela 4.
TABELA 4 – Técnicas para o Projeto de Sistemas de Banco de Dados
1) Tematização.
2) Motivação.
3) Contextualização.
4) Objetivação.
5) Intitulação.
6) Especificação de Requisitos.
7) Normalização.
8) Modelagem.
9) Dicionarização.
10) Trigramação.
11) Auditoria de Modelo e de Projeto de BD.
9
12) Implementação de um Projeto Físico de BD - Criação da Estrutura do Aplicativo de BD em Linguagem
de Definição de Dados, e demais componentes (Georeferenciados).
13) Implementação e Testes de Massa de Dados - em Linguagem de Manipulação de Dados.
14) Implementação e Testes de Massa de Dados – num Sistema de Informação Geográfica.
15) Implementação e Testes de Massa de Dados – eventualmente, em Linguagem de Marcação Estendida.
16) Implementação e Testes, eventuais, dos conceitos de Armazém de Dados.
17) Implementação e Testes, eventuais, dos conceitos de Mineração de Dados.
18) Testes e Integração de 1º Nível de um Modelo de Dados de Aplicativos por meio de Consultas
Operacionais.
19) Conversão do Modelo Relacional - para os Modelos Hierárquico, Rede e Orientado à Objetos.
20) Renormalização, Remodelagem e Redicionarização - para a Integração de 2º Nível de um MD Setorial.
21) Implementação, Testes e Integração de 2º Nível do MDS – por meio de Consultas Táticas.
22) Renormalização, Remodelagem e Redicionarização - para a Integração de 3º Nível de um MDC.
23) Implementação, Testes e Integração de 3º Nível do MDC - por meio de Consultas Estratégicas.
24) Verificação e Validação do Banco de Dados Corporativo – BDC em um Estudos de Caso Corporativo.
25) Renormalização, Remodelagem e Redicionarização para a Integração de 4º Nível de um MDH.
26) Implementação, Testes e Integração de 4º Nível do MDH, por meio de Consultas Estratégicas.
4. Resultados Obtidos
Os principais resultados obtidos foram um sistema de banco de dados corporativo,
desenvolvido por 39 alunos de graduação e pós-graduação, devidamente implementados e
integrados, num prazo de quatro meses previsto para as disciplinas, impressionando não só
pelo grau de esforço e complexidade da tarefa, mas também pelo envolvimento dos demais
grupos nas atividades propostas. O desenvolvimento e a gestão deste Projeto de Banco de
Dados representou um esforço equivalente ao desenvolvimento de um Projeto de BD para
uma empresa de médio porte, requerendo a implementação de soluções em espaço e tempo
reduzido, envolvendo uma quantidade razoável de pessoas. Uma das principais contribuições
técnica deste trabalho foi a descrição dos processos de integração, nos quais se desenvolveu as
suas organizações de forma a instituir uma inteligência tática para a operação acadêmica das
disciplinas. Experiência esta, que não pode ser desprezada, devendo ser reutilizada em futuras
turmas. Os principais resultados foram comprovados pela implementação, com sucesso, de
um Protótipo de Banco de Dados, mapeando-se assim o contexto do negócio, por meio de um
Experimento Acadêmico, realizado em sala de aula e em laboratório, podendo ser
reaproveitado por Empresas Públicas e Privadas interessadas. Após a integração completa, o
Modelo Entidade Relacionamento do BDC SIG PT totalizou de 92 Tabelas e 390 Campos. O
modelo entidade relacionamento do BDC SIG PA totalizou 18 Tabelas e 100 Campos. Após a
sua integração completa, na Holding MONITORAMA, o Modelo Entidade Relacionamento
do BDH chegou a um total aproximado de 110 Tabelas e 400 Campos.
5. Tendências e Perspectivas
Na área de Engenharia da Informação, assim como nos demais campos de estudos
afins, a evolução tecnológica vem ocorrendo rapidamente. Visando promover esta atualização
nas duas disciplinas aqui mencionadas e ministradas no ITA no 1º semestre de 2007, foram
apresentados também alguns tópicos relativos às técnicas emergentes, com sistemas existentes
no mercado e perspectivas de um largo campo de futuras aplicações. Conceitos, técnicas e
aplicações de Bancos de Dados Geográficos, Mineração de Dados (Data Mining), Data
Warehouse e Estruturas de Cubos de Dados complementaram o conteúdo da disciplina, e se
apresentam como grandes ferramentas e tendências para a extração de informações e
conhecimento, a partir de dados complexos.
6. Conclusão
O presente artigo relatou um caso de sucesso de Integração Incremental de Bancos de
Dados, elaborado e implementado no 1º semestre de 2007, nas disciplinas Técnicas de Bancos
10
de Dados (CES-30) e Projeto de Sistemas de Bancos de Dados (CE-240) dos cursos de
Graduação e Pós-Graduação do ITA. Foi novamente comprovada a viabilidade de utilização
da sistemática proposta, considerando que ela foi executada com sucesso, em ambiente de sala
de aula e em laboratório, durante as principais atividades práticas para o desenvolvimento
incremental de um Sistema de Banco de Dados, desde um nível departamental, até a
integração em nível de fusão de duas Corporações, por uma equipe distribuída e não
homogênea. A aplicação e utilização do conjunto de ferramentas de suporte utilizadas: ERWin
4.0, para geração do MER; e do SGBD Oracle 10g Spatial, mostraram-se eficientes no
emprego das suas tarefas e atividades propostas para cada integração do Projeto de Sistemas
de Bancos de Dados da Holding MONITORAMA.
O resultado deste trabalho demonstrou que a construção de um sistema informatizado
de forma “bottom-up” é recomendada para sistemas complexos, e de médio a grande porte. As
fases de integração propiciaram discussões construtivas e nivelamento de conhecimento entre
os alunos com visões e opiniões diferentes. Utilizando iterativa e incrementalmente as
Técnicas de Bancos de Dados, após as integrações, os Aplicativos de Bancos de Dados
puderam, ao final do projeto, responder as mesmas consultas elaboradas inicialmente (mesmo
que se utilizando de diferentes tabelas e relacionamentos), atendendo assim à especificação de
requisitos da Disciplina. Seguindo-se a sistemática proposta, foi possível gerenciar e
coordenar o trabalho de 39 (trinta e nove) desenvolvedores de Banco de Dados envolvidos
num experimento acadêmico, acompanhando os desempenhos individuais e por equipes, por
meio de resultados e indicadores obtidos ao final de cada Fase do desenvolvimento do
Projeto.
O processo de integração foi um desafio, considerando-se que o conhecimento acerca
do projeto partiu de uma temática para cada Aplicativo de Banco de Dados, e com a aplicação
das técnicas de projeto de sistemas de banco de dados, atingiu-se, após 16 semanas, a
implementação do protótipo de banco de dados da Holding MONITORAMA, com
aproximadamente 110 entidades e 400 atributos. O diferencial em relação aos projetos
acadêmicos de turmas anteriores, foi à inclusão de uma nova estratégia para integração dos
Bancos de Dados Setoriais em um Banco de Dados Corporativo, classificando-os por
afinidade e paralelizando as tarefas de integração, conforme descrito nas Figuras 1, 2, 3 e 4. O
sucesso deste Estudo de Caso, no qual foi apresentada, testada e validada uma sistemática
para produção em ambientes corporativos, com o mapeamento de um produto (projeto)
específico, vem a evidenciar o potencial da produção acadêmica e incentivar, ainda mais,
iniciativas de parcerias entre as Universidades, as Empresas e o Governo.
7. Recomendações
Para uma integração deste porte, é preciso que as etapas sejam seguidas por todas as
equipes. Este trabalho poderia envolver ainda uma etapa de inclusão de uma massa crítica de
dados consistente e integrada, a fim de propiciar a verificação e a validação do modelo e de
possibilitar consultas mais próximas da realidade. A população das tabelas não deve ser
realizada aleatóriamente em projetos reais, pois dos dados inseridos dependem todos os
profissionais envolvidos, porém, para o propósito acadêmico, a realização desta tarefa foi
satisfatória.
Para a próxima realização deste curso, recomenda-se antecipar a interação entre os
grupos a partir das integrações de 1º e 2º nível dos Modelos de Dados Setoriais das
Corporações. Para se evitar entidades redundantes nos Aplicativos de Bancos de Dados,
recomenda-se uma melhor interação entre os integrantes dos grupos de alunos, para manter os
requisitos do negócio, tornando possível, no futuro, a criação do papel de Administrador de
Dados da Holding, como um agente facilitador entre o Modelo de Negócios e o Projeto de
11
Sistemas de Banco de Dados. No entanto, este cenário simulou, acadêmicamente, as
dificuldades de integração de Bancos de Dados Corporativos em fusões de empresas
obviamente não previstas.
8. Agradecimentos
Os autores agradecem as seguintes Empresas e Instituições que, direta ou
indiretamente colaboraram para a elaboração deste artigo: 1) COMPUTER ASSOCIATES,
Empresa fornecedora do Software ERWin 4.0; 2) ORACLE, Empresa fornecedora do SGBD
ORACLE 10g Spatial utilizado, através de parceria acadêmica com o ITA; 3) Fundação
Casimiro Montenegro Filho – FCMF, responsável pela infra-estrutura administrativofinanceira utilizada; e 4) Instituto Tecnológico de Aeronáutica – ITA, Instituição de Ensino
viabilizadora do Trabalho de Pesquisa e Desenvolvimento realizado.
Referências
CUNHA, A. M. Notas de Aula: CES-30 - Técnicas de Banco de Dados - Instituto Tecnológico de Aeronáutica.
São José dos Campos: ITA, 2007a.
CUNHA, A. M. Notas de Aula: CES-240 - Projeto de Sistemas de Banco de Dados - Instituto Tecnológico de
Aeronáutica. São José dos Campos: ITA, 2007b.
CUNHA, A. Notas de Aula: CT-300 - Seminário de Tese - Instituto Tecnológico de Aeronáutica. São José dos
Campos: ITA, 2001.
DATE, C. J. Introdução a Sistemas de Banco de Dados. 7. ed. Rio de Janeiro: Editora Campus, 2000.
DAVIS, R. Thesis in Engineering – Air Force Institute of Technology. USA: AFIT, 1982.
ESCOLA DE COMANDO E ESTADO MAIOR DA AERONÁUTICA. Apostilas ECEMAR. Rio de Janeiro:
ECEMAR, 1990.
ERWIN 4.0. Software, Manuais e Tutoriais: ERWIN, 2000.
GLASGOW, H. B., BURKHOLDER, J. M., REED, LEWITUS, A. J., KLEINMAN, J. E. Real-time remote
monitoring of water quality: a review of current applications, and advancements in sensor, telemetry, and
computing technologies - Journal of Experimental Marine Biology and Ecology. USA: JEMBE, 2004. p409-448.
GUNATILAKA, A., DREGER, A. Use of real-time data in environmental monitoring – Current Practices.
Vienna:
Verbundplan
GmbH,
2003.
Disponível
em:
<http://www.verbundplan.at/linked/en/general/env_monitoring_2003.pdf>. Acesso em: 22 ago. 2007.
HUMPHREY, W. S. Managing the Software Process. New York: Addison Wesley Inc., 1989.
INSTITUTO DE AERONÁUTICA E ESPAÇO. 1º Seminário Brasileiro de Educação Espacial. Cachoeira
Paulista: IAE, 2007. Disponível em: <http://www.iae.cta.br/Naee/palestra7.htm>. Acesso em: 22 ago. 2007.
INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS. PCDs – Plataformas de Coleta de Dados. Cachoeira
Paulista: INPE, 2007. Disponível em: <http://satelite.cptec.inpe.br/PCD/>. Acesso em: 22 ago. 2007.
MONTINI, D. Modelo de indicadores de risco para o orçamento de componentes de software para célula de
manufatura - Dissertação Mestrado em Engenharia de Produção. São Paulo: Universidade Paulista, 2005. 360p.
MONTINI, D.; ALBUQUERQUE, A. Strategy for the use of the model of personal software process for the
establishment of measurement and analysis for obtain CMMI level 2 in a study of case of a Brazilian software
factory. ASEE - 5th ASEE Global Colloquium on Engineering Education. Rio de Janeiro: ASEE, 2006.
NEPOMUCENO, L. Técnicas de manutenção preditivas. São Paulo: Edgar Blucher, 2002. 524p.
ORACLE 10G. Software, Manuais e Tutoriais: Oracle, 2007.
RUP. Rational Unified Process - Rational Software Corporation: IBM RATIONAL, 2001.
SILBERSCHATZ, A. Sistema de Banco de Dados. 3. ed. São Paulo: Makron Books, 1999.
SILVA, L. S., CUNHA, A. M. Uma Sistemática para Implementação de Atividades Práticas: WEIMIG, 2003.
SQUITTER. Especificação da Plataforma de Coleta de Dados. São José dos Campos: SQUITTER, 2007.
Disponível em: <http://www.squitter.com.br/produtos/pcd/misc/sobre/sobre.htm>. Acesso em: 22 ago. 2007.
12