ESCOLA POLITÉCNICA
DCC/NPPG
PMBoK E O GERENCIAMENTO DE ESCOPO DE UM PROJETO
DATA WAREHOUSE
José Ferreiro Espasandin
José Ferreiro Espasandin
Monografia apresentada no Curso de Pós
Graduação em Gerenciamento de Projetos, da
Escola Politécnica, da Universidade Federal do
Rio de Janeiro.
Orientador:
Fernando Antônio Paranhos Legey
ii
José Ferreiro Espasandin
Orientador:
Fernando Antônio Paranhos Legey
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola
Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, com parte dos requisitos
necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
_________________________________________ Eduardo Linhares Qualharini, D.Sc
_________________________________________ Isabeth da Silva Mello, M.Sc.
_________________________________________ Luis Antônio Greno Barbosa, M.Sc.
iii FERREIRO, José Espasandin
PMBoK e Gerenciamento de Escopo em um Projeto Data warehouse / FERREIRO, J. E. - Rio de Janeiro: UFRJ/EP,2008.
vii, 37 f. : il. ; 29,7 cm.
Orientador: Fernando Antonio Paranhos Legey Monografia (especialização) – UFRJ / Escola Politécnica/
Curso de Especialização em Gerenciamento de projetos, NPPG, 2008
Referência Bibliográfica: f. 37
iv
v
PMBoK E O GERENCIAMENTO DE ESCOPO EM UM PROJETO
DATA WAREHOUSE
José Ferreiro Espasandin
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em
Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte
dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de
Projetos.
Este trabalho apresenta uma revisão dos principais conceitos utilizados no desenvolvimento
de projetos data warehouse, abordando desde conceitos de modelagem multimensional até
as principais etapas do ciclo de vida de um projeto. Considerando o PMBoK como um guia
geral de melhores práticas, este trabalho não tem como objetivo propor modificações e sim
apresentar uma interpretação do PMBoK, sob a ótica de um projeto de desenvolvimento de
data warehouse. A abordagem destaca a identificação de requisitos e escopo como
principal fator para sucesso deste tipo de projeto. O trabalho ainda apresenta uma
interpretação do capítulo referente ao Gerenciamento de Escopo/PMBoK, com sugestões de
ferramentas, técnicas e processos úteis para este tipo de projeto.
Palavra chave: Gerenciamento de Projetos, Data warehouse, Escopo
vi
1. INTRODUÇÃO ...01
2. CARACTERÍSTICAS DE UM SISTEMA DATA WAREHOUSE... ………..02
2.1 - Introdução ………...02
2.2 - Processos de um data warehouse – ETL (extração, transformação e carga) e consulta………..…05
2.2.1 - Extração ... 06
2.2.2 - Transformação ... 06
2.2.3 - Carga ... 06
2.2.4 - Consulta ... 06
2.3 - Sistemas OLTP (on line transactional process/processos de transação em tempo real) x OLAP (on line analytical process/processos de análise em tempo real) ... 06
3. O PARADIGMA DA MODELAGEM MULTIDIMENSIONAL ... 08
3.1 – Operações no cubo ... 10
4. GERENCIAMENTO DE PROJETOS DATA WAREHOUSE... 14
4.1 – Escopo….... ……… 14
4.2 - Performance ... 14
4.3 - Custos... ... 14
4.4 - Alocação de recursos humanos ... 15
4.5 - Comunicação ... 15
5. METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS DATA WAREHOUSE ...16
5.1 - Introdução.. ... 16
5.2 - Ciclo de vida de um data warehouse (RALPH KIMBALL – 1998) ... 17
5.2.1 - Planejamento do projeto ... 17
5.2.2 - Definição dos requisitos de negócio ... 18
5.2.3 - Modelagem multidimensional ... 18
5.2.4 - Design físico ... 18
5.2.5 - Desenvolvimento e etapa intermediária (STAGE) ... 18
5.2.6 - Arquitetura da solução e seleção de produtos e instalação………....18
5.2.7 - Especificação e desenvolvimento de aplicações para o usuário final ... 19
5.2.8 - Desenvolvimento ... 19
5.2.9 - Manutenção e crescimento ... 19
5.2.10 - Gerenciamento do projeto ... 19
vii
6.1 - Introdução PMBoK ... 21
6.2 - Gerência de escopo do projeto – visão PMBoK ... 21
6.2.1 - Planejamento do escopo ... 22
6.2.2 - Declaração do escopo ... 22
6.2.3 - Criar estrutura analítica do projeto ... 23
6.2.4 - Verificacao de escopo ... 23
6.2.5 - Controle do escopo ... 24
7. PRINCIPAIS ERROS EM PROJETOS PARA SISTEMAS DATA WAREHOUSE ... 25
7.1 - Ignorar os Processos de Iniciação………...25
7.2 - Falha na Identificação dos Requisitos……….…………26
7.3 - Falhar na Identificação da Origem das Informações………....27
8. GERÊNCIA DE ESCOPO DO PROJETO PARA SISTEMAS DATA WAREHOUSE..28
8.1 - Planejamento do escopo ... 28
8.2 - Definição do escopo ... 29
8.2.1 - Especificação de requisitos multidimensionais (ERM):………...31
8.2.2 - Planilhas extração, transformação e carga (ETL) ... 32
8.3 - Criar estrutura analítica do projeto………...32
8.4 - Verificação do escopo ... 33
8.5 - Validação do escopo ... 34
8.6 - Controle do escopo ... 35
9. CONSIDERAÇÕES FINAIS ... 36
REFERÊNCIAS BIBLIOGRÁFICAS ... 37
REFERÊNCIAS ELETRÔNICAS………37
viii
Figura 1 : Data marts dependents do data warelouse……….04
Figura 2 : Barramento data warelouse………05
Figura 3 : Elementos Multidimensionais……….09
Figura 4 : Operações no Cubo 1………..10
Figura 5 : Esquema Estrela 1………11
Figura 6 : Esquema Flocos de Neve………12
Figura 7 : Esquema Constelação……….13
Figura 8 : Ciclo de vida………...17
Figura 9 : Importância do escopo……….20
Figura 10 : Planejamento do escopo: ferramentas, técnicas e saídas………...…29
Figura 11 : Definição do escopo: ferramentas, técnicas e saídas………..30
Figura 12 : Criar EAP: ferramentas, técnicas e saídas……….32
Figura 13 : Verificação do escopo: ferramentas, técnicas e saídas………33
Figura 14 : Validação do escopo: ferramentas, técnicas e saídas………..………34
criaram um cenário propício para o crescimento do número de sistemas voltados para o atendimento e apresentação de informações gerenciais. Estes sistemas de informação são
normalmente chamados de data warehouse ou data mart, a principal diferença entre os dois
termos reside no detalhamento e abrangência do sistema: o sistema data warehouse é
corporativo e abrange todas as informações da corporação, enquanto os data marts
atendem apenas a um departamento ou parte da empresa. Ao longo desta última década, têm-se visto um aumento expressivo do número de projetos para este tipo de sistema,
desde grandes data warehouses a data marts de menor porte, considerando várias
plataformas, com custos dos mais variados possíveis e atendendo aos mais variados segmentos de mercado, tais como: setor público, varejo, indústrias, terceiro setor...
Enquanto o avanço tecnológico, através de processadores cada vez mais poderosos e dispositivos de armazenamento inimagináveis há alguns atrás, impulsionam o crescimento e disseminação destes sistemas, temos uma situação contrária com as metodologias para seu desenvolvimento. Estas metodologias ainda estão muito ligadas aos conceitos definidos na década de 90, e por consequência não sofreram as mesmas evoluções, que por exemplo sofreram o desenvolvimento de sistemas tradicionais de tecnologia de informação. Por exemplo, a gerência de requisitos, que têm sido constantemente revista.
As metodologias utilizadas ainda estão muito focadas na tecnologia, talvez pelas fortes limitações impostas no passado. Este trabalho faz uma revisão dos principais conceitos utilizados no desenvolvimento deste tipo de projeto, abordando desde conceitos de modelagem multidimensional até o ciclo de vida apresentado por Ralph Kimball (1998).
Considerando o PMBoK como um guia geral de melhores práticas, este trabalho não tem como objetivo propor modificações e sim apresentar uma interpretação do PMBoK, sob
a ótica de um projeto de desenvolvimento de data warehouse. A abordagem destaca a
2. CARACTERÍSTICAS DE UM SISTEMA DATA WAREHOUSE
2.1. Introdução
A idéia ou conceito referente a “data warehousing” surgiu em meados da década de
80, com enorme crescimento ao longo das duas últimas décadas. O ambiente corporativo, globalizado e competitivo aumentou a necessidade e importância da informação gerencial. Cada vez mais, as empresas criam novos sistemas, que necessitam da integração entre diferentes plataformas e sistemas.
Bill Inmon (1992) é considerado como um dos pais do data warehouse, sendo
responsável pela criação da definição mais comum e aceita na literatura:
“Data warehouse é uma coleção de dados orientada por assunto, integrada, não volátil, e variante no tempo em suporte a decisões gerenciais”.
A orientação por assunto permite sua estruturação de acordo com as áreas de
atuação e objetivos estratégicos da organização. Sistemas data warehouse também
integram vários sistemas e plataformas distintas, promovendo uma visão unificada do cenário operacional da organização.
A informação é considerada não-volátil porque é mantida por muitos anos, geralmente nunca chega a ser excluída. Esta retenção permite a análise histórica sobre as informações armazenadas por longos períodos.
Dizer que a informação é variante ao longo do tempo, implica em afirmar que a informação é armazenada conforme suas inúmeras variações ao longo da linha do tempo,
um sistema data warehouse deve permitir a recuperação do estado da informação em um
dado período de tempo. Com esse objetivo, a informação é regularmente atualizada para manter o registro histórico das operações de toda a organização ao longo de sua existência.
Após esta introdução, podemos sintetizar que o principal objetivo e desafio do
sistema data warehouse é: converter o dado operacional e distribuído em informação
gerencial e estratégica, que possa ser utilizada pelos gestores para tomada de decisão.
Para atender este objetivo, a construção deste tipo de sistema está fortemente apoiada em um processo sistemático, compreendendo algorítimos, modelos, ferramentas, técnicas e uma arquitetura especialmente concebida para permitir o armazenamento de grandes volumes de dados, ainda que viabilizando a obtenção de informação estratégica a partir de consultas complexas e respeitando restrições de tempo de resposta e performance.
Esse processo sistemático é conhecido como data warehousing e os sistemas resultantes
deste processo são conhecidos como: Sistemas Data warehouse.
i. ODS – Operational data store - muito semelhante ao data warehouse, contudo é utilizado para as necessidades operacionais de análise das informações.
ii. EDW – Enterprise data warehouse – consiste na coleção de todos os dados corporativos que podem ser usados para análise do negócio e apoio à decisão.]
iii. DM – Data marts – consiste de uma coleção reduzida de informações,
fortemente orientada para um assunto e geralmente associadas a um departamento ou
grupo de trabalho específico. A reunião de vários data marts pode consolidar a existência
de um data warehouse.
Bill Inmnon (1992) e Ralph Kimball (1998) são os dois maiores autores a respeito deste assunto, é comum encontrarmos ligeiras diferenças na interpretação de suas idéias.
Baseado em suas publicações, podemos apontar as seguintes diferenças:
i. Inmon (1992) descreve o data warehouse centralizado como o local onde a
organização conquista a integração de suas informações e sistemas, ele defende a visão de um data warehouse central com data marts dependentes. Enquanto Kimball (1998)
contrapõe esta idéia, defendendo o “barramento data warehouse” (data warehouse bus
structure). Esta barramento vem a ser a idéia, que podemos compartilhar dimensões e
elementos comuns ao longo de vários data marts.
ii. Inmon (1992) descreve o data warehouse como fonte de informação para
todos os data marts, enquanto Kimball (1998) utiliza o conceito de data warehouse como
algo virtual. A junção destes vários data marts consolidam a existência do data warehouse.
iii. Kimball (1998) defende a idéia que o desenvolvimento deve ser
departamental e rápido, implementado a partir de data marts. Enquanto Inmon (1992)
defende a idéia de construção de uma grande base integrada com informações corporativas. Neste ponto as idéias de Kimball (1998) são mais práticas e por isso, encontradas na grande maioria de implementações.
iv. Inmon (1992) defende a idéia que o data warehouse deve possuir um
desenho normalizado, enquanto Kimball (1998) prega que o data warehouse deve ser
Data Warehouse
Data Marts
Figura 1: Data marts dependentes do data warehouse
Fonte: Tim Peterson, 1999)
A figura 1 mostra a existência de um data warehouse a partir de vários outros data
marts, pode-se citar como exemplo uma companhia seguradora, onde teríamos vários data
marts, como: Seguro Pessoal, Veículos, Residencial, Saúde... Estes vários data marts
Barramento data warehouse
Figura 2: Barramento data warehouse
Fonte:Tim Peterson, 1999
A figura 2 mostra o conceito do barramento no data warehouse, a idéia do
barramento consiste em compartilhar informações ou dimensões comuns aos vários data
marts, como por exemplo: Tempo, Clientes, Produtos... Como no exemplo da figura anterior, poderíamos ter o mesmo cliente adquirindo produtos de seguro pessoal e seguro de veículos.
Em fevereiro de 2005, o Gartner Group divulgou um estudo informando que a tecnologia de Business Intelligence apareceem segundo lugar na lista de maiores prioridades tecnológicas listas pelos principais CIOS.
2.2 Processos de um Data warehouse – ETL (Extração, Transformação e Carga) e
Consulta
2.2.1. Extração:
Geralmente o data warehouse integra sistemas distribuídos e heterogêneos. Este
processo é responsável pela captação das informações, ocorrida de forma organizada e periódica. Neste estágio, os dados podem ser transmitidos em vários formatos diferentes, tais como: arquivo texto, xml...
2.2.2. Transformação:
Até o momento da extração, consideramos o dado como algo bruto que ainda precisará ser manipulado. Este processo é responsável pela organização ou limpeza do dado, transformando-o em informação.
2.2.3. Carga:
Trata-se do processo que envolve a alimentação do banco de dados. Trata-se de uma etapa eminentemente física, com preocupação para criação de estruturas otimizadas, chaves especiais, índices...
2.2.4. Consulta:
Real objetivo do sistema, que corresponde realizar consultas à base carregada. Neste ponto, temos uma grande diferença para os sistemas transacionais, já que a maioria
dos projetos utilizam ferramentas OLAP (On Line Analytical Process/Processos de Análise
em Tempo Real), voltadas para atender a necessidade do usuário. Ao contrário dos sistemas transacionais, é raro encontrar projetos que desenvolvam sua própria interface.
2.3. Sistemas OLTP (On Line Transactional Process / Processos de Transação em
Tempo Real) X OLAP (On Line Analytical Process / Processos de Análise em Tempo
Real)
Sistemas OLAP possuem foco no atendimento de necessidades gerenciais,
enquanto os sistemas OLTP possuem foco no suporte ao processamento de transações
on-line.
No universo OLTP, existem uma grande quantidade de usuários, geralmente
afetando uma pequena quantidade de registros. O modelo de dados é normalizado, de modo a evitar a redundância e facilitando a gravação/atualização das informações.
Em contrapartida, as aplicações OLAP são geralmente utilizadas por um número
pequeno de usuários, com importância inversamente proporcional ao seu número. Neste caso, lida-se como: analistas de negócio, gerentes, executivos, diretores... O grau de exigência é muito mais alto, tanto nos aspectos: funcionalidade, performance, confiabilidade... Os acessos são exclusivamente de leitura, por isso os dados não são normalizados. A redundância é aceita, desde que com intuito de aumentar a performance de leitura. O volume de informação é geralmente muito alto, com forte importância para o histórico.
O quadro a seguir apresenta as principais diferenças entre sistemas OLAP e OLTP.
As principais diferenças residem no fato dos sistemas OLTP serem voltados para a
transação e operação do negócio, enquanto sistemas OLAP serem orientados para
informação e gestão do negócio; por esse motivo, temos muitos usuários operacionais no
sistema OLTP, enquanto que no sistema OLAP temos poucos usuários, contudo usuários
importantes dentro da hierarquia da corporação (gerentes, diretores...).
Quadro 1: OLTP x OLAP
CARACTERÍSTICA OLTP OLAP
Unidade Transação Dado
Número de Usuários Alto Baixo
Complexidade das Transações Baixa Alto
Natureza da Transação Simples, Pré-Definida Dinâmica e Complexa
Foco Registros Individuais Milhões de Registros
Tamanho das fontes Gigabyte Gigabyte-Terabyte
Atualização dos dados Valores Recentes Valores Recentes e Histórico
Modelo de Dados Normalizado Desnormalizado
Processo de Desenvolvimento Customizado Padrão
Dados Leitura/Gravação Leitura
Informação Primária Detém o controle Controlada por fontes externas
3. O PARADIGMA DA MODELAGEM MULTIDIMENSIONAL
As técnicas tradicionais de modelagem de dados são inadequadas ao projeto de
ambientes de data warehouse. Isto porque o modelo de dados de um sistema tradicional
enfatiza a normalização, como forma de evitar redundância e problemas de atualização. Além disso, a normalização pode implicar em um modelo muito complexo e de difícil compreensão para os usuários finais.
O sistema data warehouse não é projetado para atualizações constantes, desta
forma a redundância não é um problema, pelo contrário, pode até representar benefício ao maximizar a eficiência de consultas.
O conceito referente ao paradigma multidimensional foi criado para permitir a criação de modelos lógicos mais simples e fáceis de serem interpretados. A modelagem multidimensional tem forte orientação para o processamento analítico, sendo que a principal idéia por trás deste modelo é justamente a separação entre informações quantitativas e qualitativas. Através desta distinção, passamos a trabalhar basicamente com dois principais tipos de informação:
Fatos: são os dados quantitativos mensuráveis, representando alguma atividade específica de negócio. Por exemplo: Qtd Produtos Vendidos.
Dimensões: representa a perspectiva pela qual podemos analisar os “fatos”, é composta por elementos ou atributos (características) que a descrevem em níveis de detalhes diferenciados.
Exemplo de diferença entre elemento e atributo:
Dimensão Produto:
Elementos ou níveis de análise
Família;
Grupo;
Código do Produto.
Atributo: Cor, Tamanho, Forma
Estes níveis estão organizados de forma hierárquica, através das quais as métricas podem ser consolidadas ou classificadas.
A dimensão possui uma granularidade, conforme o detalhe do seu nível mais baixo de análise. Por exemplo:
Itens:
Região Geográfica;
Estado;
Município;
Bairro.
No exemplo citado, a dimensão Localização Geográfica tem sua menor granularidade no nível Bairro.
O arranjo dos fatos com suas perspectivas de análise (dimensões) resulta no que a literatura chama de “cubo”. A interseção entre os elementos do cubo é representada por uma célula, como indicado na figura 3.
Dimensões
Produto Vendedor Tempo
Hierarquia Atributos Hierarquia Hierarquia
Família Cor Filial Ano
Produto Tamanho Gerente Mês
Código Inscrição Semana
Dia
Tempo
Ven
de
dor
P
rodut
o
Na figura a célula grifada estará representando uma métrica para um determinado vendedor, também associada a um produto e em um determinado instante do tempo. Por exemplo: “o vendedor José vendeu 50.000 unidades do produto XYZ, no mês de Janeiro/2007”.
3.1. Operações no Cubo
A representação do cubo pode facilitar o entendimento do modelo e por conseqüência as atividades de levantamento de requisitos. É importante que o usuário final perceba como navegar neste modelo. A literatura consagrou alguns termos utilizados para representar as operações que podem ser realizadas a partir deste cubo:
Figura 4: Operações no CUBO 1 Fonte: Fábio Rilston, 2003)
Slice/Dice: “Fatie e pegue” - consiste em analisar uma seção do cubo, fixando-se os valores das dimensões. Por exemplo: o total de vendas do segundo semestre de 1997 pode ser obtido pelo “Slice” da figura anterior. O seu refinamento para o produto CD e Loja 01 é representado pelo “Dice” logo abaixo na mesma figura.
Rotate/Pivot: “Rotação” – Modifica a orientação do cubo, ao trocar a posição da
Drill Down/Roll Up: “Mergulho para baixo ou para cima” – Operação que utiliza as hierarquias dimensionais para apresentação informações consolidadas ou mais detalhadas. No exemplo da figura anterior, as vendas de um produto podem ser refinadas ao longo das dimensões Tempoe Loja.
O modelo conceitual é apoiado pela modelagem multidimensional e representado através de modelos lógicos e físicos relacionais. A literatura consagra como os dois principais esquemas para representação lógica e física:
Esquema Estrela: Métricas e atributos são mapeados através de dois tipos de tabelas: Fato e Dimensão. As tabelas tipo Dimensão são conectadas a uma tabela central (Fato), assim como na representação abaixo:
Figura 5: Esquema Estrela 1 Fonte: Fábio Rilston, 2003)
A figura 5 mostra um tradicional esquema estrela, com uma fato registrando o valor de vendas, que pode ser acompanhado por diferentes perspectivas de análise, tais como: período, local, produto e cliente.
Figura 6: Esquema Flocos de Neve Fonte: Fábio Rilston – 2003
A figura 6 mostra um tradicional esquema floco de neve com normalização nas dimensões: Produto, Cliente e Local.
Outros esquemas: ainda existem variações deste modelo, como por exemplo a “Constelação”, que apresenta fatos hierarquicamente interligadas por meio de dimensões comuns, possibilitando a recuperação de dados entre visões de negócio situadas em tabelas fato autônomas.
4. GERENCIAMENTO DE PROJETOS DATA WAREHOUSE
As técnicas e práticas tradicionais podem não funcionar para projetos de data
warehouse, simplesmente porque um projeto de data warehouse é diferente de um projeto tradicional.
O projeto de data warehouse se baseia em uma visão projetizada, envolvendo
vários departamentos e trazendo todas as dificuldades de um projeto entre várias equipes e departamentos.
Além do que já foi mencionado no segundo capítulo, pode-se citar que um projeto de data warehouse é muito mais dinâmico que um projeto convencional. Existem inúmeros itens que devem ser observados com mais atenção, tais como: escopo, controle de mudanças, perfomance, custos, alocação de recursos humanos e comunicação entre os interessados (stakeholders) do projeto.
4.1 Escopo
Trata-se de um dos maiores desafios neste tipo de projeto. Se por um lado, o sistema geralmente atende usuários de alto nível, como executivos e gestores, por outro lado, ainda temos que estes usuários nem sempre tem uma visão correta do que o sistema pode proporcionar. Este cenário pode criar uma definição de escopo incompleta, com uma enorme sobrecarga no controle de mudanças.
4.2 Performance
O maior objetivo de um data warehouse é propiciar análise estratégica e visualização
de tendências. Este tipo de informação é utilizada, pelos executivos, para tomada de decisão e gestão do negócio. Para que isso seja possível, geralmente é necessário armazenar informações históricas, criando um banco muito grande, com aspectos críticos relacionados ao tempo de resposta do sistema.
4.3 Custos
De uma forma geral, o desenvolvimento deste tipo de sistema é caro. O alto custo é
justificado: pela necessidade de hardware para manipulação de grandes bancos, de
4.4 Alocação de Recursos Humanos
Este tipo de projeto utiliza ferramentas e técnicas menos difundidas no mercado, sendo normal encontrar dificuldade para alocar recursos experientes. Este problema pode ser resolvido ou minimizado por treinamento e técnicas de transferência de conhecimento.
4.5 Comunicação
Um dos maiores desafios em um projeto para o desenvolvimento de um data
warehouse é disseminar a informação, todos devem ser informados de tudo! Deve-se entender que equipe do projeto, representantes de terceiros, patrocinadores e todos os demais interessados precisam estar sincronizados e atualizados em relação às demandas, mudanças e situação do projeto. A comunicação formal e informal deve ser cuidadosamente detalhada no plano do projeto, especialmente para grandes projetos de
5. METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS DATA WAREHOUSE
5.1 Introdução
Existem várias metodologias difundidas e utilizadas para o desenvolvimento de
sistemas data warehouse, a leitura de alguns autores clássicos, como Ralph Kimball (1998)
e Bill Inmon (1992), acaba por provocar a idéia que estas metodologias são dicas e soluções para pedaços do processo, ao invés de uma metodologia concreta para gerenciamento e
desenvolvimento de um data warehouse. Naturalmente, os projetos que seguem estas
metodologias tendem a focar em soluções com preocupações destacadas para o aspecto físico do sistema, como por exemplo: implementação de relatórios, criação de índices, agregações para performance...
Algumas das principais metodologias disponíveis estão organizadas em uma sequência de fases, que acabam por compor um ciclo de vida completo de desenvolvimento.
Qualquer metodologia para desenvolvimento de um data warehouse precisará
abordar a questão dos requisitos, e talvez este seja o ponto mais difícil a ser trabalhado. É bastante comum encontrar processos pouco consistentes, que acabam por criar definições de escopo pouco sólidas. A fragilidade do escopo acabará por gerar um alto índice de mudanças, sobrecarregando o gerenciamento do projeto. A metodologia será tão boa quanto sua capacidade de gerenciar e controlar os requisitos do projeto.
Fazendo uma comparação com os sistemas de informação tradicionais, podemos
dizer que estes estão à frente dos sistemas data warehouse, pelo menos no que diz respeito
à questão de requisitos. Ao longo dos últimos anos, surgiram várias metodologias e técnicas para levantamento e representação dos requisitos. Apenas como exemplo,
pode-se citar a Linguagem de Modelagem Unificada ou UML, que com seus vários diagramas
(diagramas de casos de uso, diagramas de classes, diagramas de estado, diagramas de atividades, diagramas de objetos, diagramas de seqüência...) consegue documentar os requisitos com muito sucesso, eliminando ambigüidades, conflitos e omissões. Infelizmente
a UML não é aderente ao sistema data warehouse, alguns autores chegam a propor que o
5.2 Ciclo de Vida de um Data warehouse (RALPH KIMBALL, 1998)
Ralph Kimball (1998) é um dos principais autores e referência a respeito deste tema,
seu trabalho entitulado “Data warehouse Life Cycle” apresenta uma metodologia com foco
no projeto de uma arquitetura multidimensional robusta, contudo ainda destacando a importância dos requisitos de negócio. Segundo Kimball (1998), o modelo de requisitos determina a fronteira do sistema, a forma e a periodicidade com a qual a informação deverá estar armazenada. Ele destaca que a mudança de requisitos é peça chave para sucesso do projeto, pelo grau de importância, acaba por implicar em um alto nível de gerenciamento.
O trabalho de Kimball (1998) foi originalmente apresentado na década de 80. Neste início, não existiam metodologias formais ou registros de melhores práticas voltadas para o desenvolvimento deste tipo de sistema.
Figura 8: Ciclo de Vida Fonte: Ralph Kimball, 1998
5.2.1 Planejamento do Projeto
O ciclo de vida começa pelo planejamento, esta etapa deve ser responsável pelo planejamento de tudo que será realizado pelo projeto. Deve contemplar a definição do escopo, inclusão da justificativa para existência do projeto, análise da alocação de recursos
humanos, planejamento para aquisição de software e hardware, definição, duração e
5.2.2 Definição dos Requisitos de Negócio
Trata-se de uma das principais etapas do ciclo de vida, o correto entendimento do negócio e dos requisitos dos usuários é fundamental para o sucesso do projeto. Os analistas precisam entender a estrutura e funcionamento do negócio para efetivamente traduzir estas informações e os demais requisitos em um modelo: funcional, aderente e que atenda ao propósito do projeto.
5.2.3 Modelagem Multidimensional
A definição dos requisitos de negócio consiste no primeiro passo para se entender a necessidade de análise e consultas por parte dos usuários. Estas informações acompanhadas da análise detalhada dos sistemas transacionais suportadas pelo negócio, permite trabalhar o modelo multidimensional. Este modelo é caracterizado pela tabela de
fato, assim como por suas respectivas dimensões de análise, hierarquias de análise...
5.2.4 Design Físico
Esta etapa é iniciada a partir da conclusão da modelagem lógica, e consiste em criar a estrutura física que suportará o modelo multidimensional. Momento oportuno para definição de padrões de desenvolvimento, assim como a configuração do ambiente de produção.
5.2.5 Desenvolvimento e Etapa Intermediária (Stage)
O termo STAGE corresponde a uma área temporária, utilizada para as operações
ETL (extração, transformação e carga). De todas as atividades ao longo do projeto, as
atividades de desenvolvimento e STAGE são as que estão sujeitas a maior quantidade de
problemas e riscos de atraso. Estas operações dependem muito da qualidade da informação; quanto pior a qualidade, mais trabalho para desenvolvimento, além de maior o risco para o sucesso do projeto.
5.2.6 Arquitetura da Solução e Seleção de Produtos e Instalação
Todos estes ingredientes precisam ser cuidadosamente “encaixados”, de forma que o sistema possa atingir seu principal objetivo, que é atender os requisitos do negócio.
Os produtos de terceiros costumam ser caros, por isso precisam ser cuidadosamente testados e avaliados, podemos citar como exemplos: ferramentas de ETL, ferramentas para apresentação das informações...
5.2.7 Especificação e Desenvolvimento de Aplicações para o usuário final
Estas especificações devem garantir que a equipe do projeto e os usuários finais tenham o correto entendimento do que deverá ser entregue e as funcionalidades previstas. Geralmente, estas informações estão relacionadas a padrões de apresentação, que serão utilizados em relatórios pré-definidos.
5.2.8 Desenvolvimento
As linhas de tecnologia, informação e aplicação convergem para a existência do sistema. Neste momento, a necessidade de planejamento se torna muito evidente, com as diversas peças precisando se encaixar. A falha de qualquer etapa anterior pode comprometer o sucesso do projeto.
5.2.9 Manutenção E Crescimento
Junto com a disponibilização, o usuário precisa receber treinamento e apoio para utilização do sistema. Ao contrário do que acontece em outros projetos, espera-se que o usuário apresente feedback, com sugestões e muitos pedidos de mudança. Neste caso, a mudança é fundamental e muito bem vista. É isso garante a evolução do sistema e faz com que retornemos ao início do ciclo de vida do desenvolvimento
Esta etapa precisa de uma boa estratégia para o plano de comunicação.
5.2.10 Gerenciamento Do Projeto
O gerenciamento do projeto acompanha todo o ciclo de vida e deve garantir que o plano do projeto seja executado. De todos os desafios, pode-se destacar como mais importantes para o sucesso do projeto:
i. Realizar um controle de mudanças eficiente, garantindo os limites do
ii. Conceber um plano de comunicação eficiente, contemplando os principais
stakeholders envolvidos.
5.3 Escopo
A figura abaixo apresenta uma visão do ciclo de vida apontado por Kimball (1998), destacando a etapa de requisitos de negócio como uma etapa central e de extrema importância para o sucesso do projeto.
Figura 9: Importância do escopo Fonte: Ralph Kimball, 1998
6. GERENCIAMENTO DE PROJETOS TRADICIONAIS E ESCOPO DO PROJETO 6.1 Introdução PMBoK
O PMBoK apresenta um conjunto de melhores práticas para gerenciamento de projetos. Suas práticas são amplamente utilizadas e testadas por gerentes de vários tipos de projetos, em diversos locais e culturas distintas. Este manual deve ser visto como um guia, visto que nem todas as práticas e regras são aplicáveis a todos os tipos de projetos.
O PMBoK é distribuído por disciplinas e segmentado por processos. Temos ao todo, um total de 9 disciplinas contendo 44 processos. O anexo apresenta a relação de disciplinas e processos.
Uma das premissas deste trabalho é considerar que um projeto para
desenvolvimento de um sistema data warehouse é especial, apresentando particularidades
que precisam ser atendidas também de forma especial. De todas as disciplinas existentes, o gerenciamento do escopo do projeto é o maior desafio para o gerente de projetos de um
sistema data warehouse. Tanto a correta definição do escopo, como o eficaz controle de
mudanças, podem e devem fazer a diferença entre um enorme fracasso e um total sucesso.
Por tradição, os projetos para desenvolvimento de sistemas data warehouse são
calcados em forte apoio político dentro da corporação. Acontece algo do tipo: “O projeto precisa sair porque o diretor financeiro quer...”. Algumas vezes, isto acaba por mascarar problemas de arquitetura e definição do escopo, muitas vezes o projeto chega a ser concluído sem atender aos requisitos básicos dos usuários finais. Esta situação é a
verdadeira sentença de morte para um sistema data warehouse, sem atender aos requisitos
básicos, acaba em desuso e é descartado com o tempo.
O item 6 estará apresentando uma visão resumida da abordagem, do PMBoK, referente à gerência de escopo. A partir do item 8, este trabalho estará propondo uma adaptação da abordagem realizada pelo PMBoK, revendo os processos, ferramentas e documentos utilizados para gerência do escopo.
6.2 Gerência de Escopo do Projeto – Visão PMBoK
6.2.1 Planejamento do Escopo
Este processo é responsável por determinar como se estará tratando a questão do escopo, sua principal saída é o plano de gerenciamento de escopo. Este documento aborda vários itens, tais como:
i. Definir o escopo do projeto,
ii. Desenvolver a declaração do escopo detalhada do projeto,
iii. Definir e desenvolver a estrutura analítica do projeto,
iv. Verificar o escopo do projeto e
v. Controlar o escopo do projeto.
6.2.2 Declaração do Escopo
A declaração do escopo é responsável por dizer o que está e não está incluído no trabalho do projeto. A correta declaração do escopo é essencial para o sucesso do projeto, esta declaração é obtida a partir das principais entregas, premissas e restrições documentadas durante a fase de iniciação do projeto, particularmente na declaração do escopo preliminar do projeto. Durante a fase de planejamento, o escopo preliminar pode e deve ser revisto, gerando o escopo com maior nível de detalhe. Necessidades, desejos e
expectativas dos stakeholders devem ser analisadas e retratadas sob a forma de requisitos.
As premissas e restrições devem ser revistas, afim de garantir que estejam realmente completas.
Dentre as várias saídas deste processo, destaca-se a declaração do escopo do projeto, este documento estará descrevendo em detalhes: as entregas e o trabalho necessário para criar essas entregas, também fornecerá um entendimento comum do escopo do projeto a todas as partes interessas, além de descrever os principais objetivos do projeto.
Este documento ainda deverá ser utilizado como linha de base para avaliação de mudanças ou trabalho adicional, verificando se estão contidos dentro ou fora dos limites do projeto.
A declaração do escopo detalhada deve apresentar as seguintes informações:
i. Objetivos do projeto;
ii. Descrição do escopo do produto;
iv. Limites do projeto;
v. Entregas do projeto;
vi. Critérios de aceitação de produtos;
vii. Restrições do projeto;
viii. Premissas do projeto.
6.2.3 Criar Estrutura Analítica do Projeto
A EAP (Estrutura Analítica do Projeto) tem grande utilidade para a organização e definição do escopo total do projeto, ela ajuda a dividir o trabalho do projeto em partes menores e mais facilmente gerenciáveis. Para cada nível descendente da EAP, temos a representação de uma definição cada vez mais detalhada do trabalho do projeto. O nível mais baixo da EAP, também é denominado pacote de trabalho, com ele, torna-se mais fácil estimar custos, agendar prazos, monitorar e controlar o trabalho planejado.
A decomposição é uma das principais ferramentas utilizadas neste processo, ela consiste na subdivisão das entregas do projeto em componentes menores e mais facilmente gerenciáveis.
O nível de pacote de trabalho é o nível mais baixo da EAP e é o ponto onde o custo e o cronograma podem ser estimados de forma razoável. O nível de detalhe pode variar de acordo com o cenário do projeto, contudo a equipe precisa ficar atenta para evitar uma decomposição excessiva, visto que isto pode gerar um excesso de trabalho com gerenciamento improdutivo.
6.2.4 Verificação de Escopo
A verificação escopo é o processo de obtenção da aceitação formal pelas partes interessadas do escopo do projeto terminado e das entregas associadas. Este processo apresenta como principais saídas:
i. Entregas aceitas
ii. Mudanças solicitadas
6.2.5 Controle do Escopo
Este processo ajuda a controlar o projeto como um todo, à medida que o controle do escopo também ajuda a identificar a origem das mudanças, sendo de extrema importância avaliar o impacto das mudanças em outras áreas de conhecimento, assim como o impacto das mudanças no próprio escopo do projeto.
Este processo deve garantir que todas as mudanças solicitadas e ações corretivas recomendadas sejam processadas por meio do processo “Controle integrado de mudanças do projeto”.
7. PRINCIPAIS ERROS EM PROJETOS PARA SISTEMAS DATA WAREHOUSE
Em sistemas data warehouse, é bastante comum encontrar projetos e principalmente
gerente de projetos com maior foco na tecnologia utilizada. Existe uma visão excessivamente tecnológica em detrimento da visão e definição dos requerimentos.
Vamos imaginar o seguinte cenário:
“O projeto possui um forte patrocinador dentro da corporação, a equipe acabou de
ser montada e possui um prazo limite de 6 meses para criar o data warehouse. Logo no
início, o gerente reúne a equipe e seus futuros usuários. Por uma questão de facilidade, o gerente dá preferência aos usuários mais técnicos, afinal é muito mais fácil conversar de técnico para técnico. O levantamento é iniciado pela revisão dos relatórios já existentes e entrevistas para identificação de novos relatórios. Imediatamente após esta fase, a equipe já começa a trabalhar na especificação do banco de dados. A etapa relacionada a extração de dados é rapidamente resolvida pela fantástica ferramenta ETL adquirida. A camada de apresentação das informações também utiliza uma ferramenta de mercado muito intuitiva e fácil de ser utilizada. Aparentemente o projeto foi executado com sucesso e concluído antes do prazo estabelecido. Assim que é disponibilizado, as reclamações começam a chegar, primeiro os usuários questionam que algumas informações não foram contempladas, outros reclamam que o formato dos relatórios pré-definidos não atendem suas necessidades. A casos piores, onde o usuário questiona que a informação não está correta. Em resumo, o projeto falhou completamente”.
Este cenário é muito mais comum do que parece, pode-se listar como principais erros:
7.1 Ignorar os Processos de Iniciação
Todo o projeto precisa de um patrocinador, contudo os processos da fase de iniciação não podem ser ignorados. O cenário indica que o prazo foi estabelecido a partir do patrocinador, sem considerar os processos de inicialização. É importante que o gerente de projeto dedique tempo para:
i. Identificar a cultura da empresa e sistemas legados;
ii. Coletar informações históricas e entender processos da empresa;
iii. Identificar todos os stakeholders;
iv. Documentar as necessidades de negócio;
vi. Documentar as premissas e restrições do projeto;
vii. Desenvolver o project charter;
viii. Desenvolver o escopo preliminar do projeto.
7.2 Falhar na Identificação dos Requisitos
Infelizmente o ser humano tem a tendência de trabalhar dentro de uma zona de conforto, por isso que o gerente de projetos priorizou o levantamento de requisitos com usuários mais técnicos. Este é um erro grave, mas o maior erro é falhar na identificação dos principais envolvidos.
O gerente de projeto precisa identificar todos os envolvidos e/ou afetados pelo projeto. Uma lista relacionando todos os envolvidos deve fazer parte da documentação do projeto. A partir desta lista, a equipe deverá começar o levantamento pelos usuários de negócio. Isto pode até ser um pouco mais difícil, mas estes usuários representam o centro do projeto e precisam ser os primeiros a serem entrevistados. A linguagem e comunicação entre usuários de negócio e a equipe do projeto pode ser mais difícil, pode-se citar como exemplo a palavra “índice”, ela pode assumir diferentes significados, ora para um analista de negócio, ora para um DBA.
Daí a importância de montar uma equipe multidisciplinar, com integrantes que conheçam a linguagem dos usuários. As entrevistas não devem ser conduzidas para perguntar o que o usuário quer que o sistema apresente, na realidade o entrevistador deve conduzir de forma a entender os objetivos do negócio, quais são os desafios do usuário, como ele analisa as informações e toma suas decisões...
7.3 Falhar na Identificação da Origem das Informações
Assim que os entrevistadores conseguem coletar informações e requisitos do negócio, a equipe deve começar a procurar os responsáveis pela administração dos sistemas transacionais. É importante avaliar se os requisitos informados pelos usuários de negócio são tangíveis e possíveis de serem obtidos a partir dos sistemas de origem.
Pode-se citar o seguinte exemplo:
“Uma indústria farmacêutica multinacional possui a composição de um medicamento com um item concentrado e importado. Seu custo é excessivamente elevado e um analista de negócio gostaria de saber o seu custo por caixa do medicamento. Por uma questão de segredo industrial, o percentual de utilização do concentrado não é conhecido, inviabilizando o atendimento deste requisito.”
A partir do momento que as entrevistas passam a mostrar temas e resultados consistentes, é a hora de sentar formalmente com os responsáveis e administradores dos sistemas transacionais. É importante identificar todas as possíveis origens e histórico das
informações. Como o data warehouse estará captando informações históricas é importante
observar o comportamento das informações ao longo do tempo, por exemplo: uma determinada coluna do banco de dados transacional era alimentada com um domínio específico até o ano 2002, a partir de uma mudança na legislação, o domínio foi alterado para outra especificação. Este tipo de análise é importante para garantir a integridade das informações. Em qualquer tipo de sistema da informação, a coerência e correção das
informações são importantes, contudo sistemas data warehouse existem para apresentar
8. GERÊNCIA DE ESCOPO DO PROJETO PARA SISTEMAS DATA WAREHOUSE O PMBoK é um guia do conjunto de conhecimentos em gerenciamento de projetos. Ele pode e deve ser adaptado às necessidades de cada projeto; esta seção tem como objetivo apresentar uma adaptação da abordagem realizada pelo PMBoK, para a gerência
de escopo de um projeto de desenvolvimento de sistemas data warehouse.
A seção estará apresentando: processos, técnicas, ferramentas e
documentos/templates específicos para este tipo de projeto. O principal objetivo é mostrar
como a leitura do PMBoK pode ser adaptada, afim de maximizar a chance de sucesso para um projeto tão peculiar.
Nesta proposta, a gerência de escopo deveria ser atendida por seis processos. Além dos cinco já existentes, está sendo acrescentado o processo “Validação do escopo do projeto”. Este processo surge em decorrência da forte necessidade de reforçar a coerência e correção na obtenção dos requisitos de negócio.
8.1 Planejamento do Escopo
Na visão adaptada, este processo continua responsável pela elaboração do plano de gerenciamento de escopo. A única diferença é que na apresentação do PMBoK, o plano de gerenciamento de escopo é utilizado para orientar em relação a:
i. definição do escopo do projeto,
ii. desenvolvimento da declaração do escopo detalhada do projeto,
iii. definição e desenvolvimento da estrutura analítica do projeto,
iv. verificação do escopo do projeto e
v. controle do escopo do projeto.
Nesta nova visão, devemos acrescentar uma nova função para o plano de gerenciamento de escopo, que é: acrescentar a orientação para como validar o escopo do projeto. Com relação às entradas deste processo, é importante acrescentar entrevistas com o usuário ou analista de negócio. O gerente e equipe precisarão de informação mais detalhadas para realizar este planejamento com sucesso.
Entradas Ferramentas e Técnicas Saídas
Fatores Ambientais da
Empresa Opinião especializada Plano de gerenciamento do
escopo do projeto
Ativos de Processos
Organizacionais Modelos, Formulários, normas, planilhas ETL
Termo de Abertura do Projeto
Declaração do escopo preliminar do projeto
Plano de
gerenciamento do projeto
Entrevistas com usuários e/ou analistas do negócio
Figura 10: Planejamento do escopo: ferramentas e técnicas, e saídas Fonte: (Adaptação PMBoK – 2004)
8.2 Definição do Escopo
Talvez este seja o processo mais afetado pelas particularidades de um sistema data
warehouse. Neste tipo de projeto, uma mudança tardia pode afetar todas as etapas subseqüentes, tais como: modelagem, design físico, arquitetura da solução, desenvolvimento de aplicações...
Além das orientações já existentes no PMBoK (PMI,2004), podemos detalhar a ferramenta “Análise das partes interessadas”, enfatizando:
i. Entrevistas com usuários e analistas de negócio: as entrevistas devem ser
ii. Reuniões com presença de um facilitador: tem como grande vantagem a possibilidade de envolver um número maior de pessoas simultaneamente, pode ser realizado quando a equipe do projeto já tem o conhecimento prévio do negócio.
iii. Apresentação da proposta e objetivos do sistema: este tipo de projeto
costuma ser multi-departamental, por isso é muito comum encontrar resistência para participação dos usuários. Por aspectos culturais de algumas organizações, os
projetos de data warehouse tendem a ser menos prestigiados que projetos com foco
operacional. Quando chamado para uma entrevista ou reunião com o facilitador, o usuário precisa saber a finalidade e objetivos do projeto.
iv. Apresentação de piloto ou protótipo: O usuário pode não conhecer a
tecnologia e por isso ter dificuldade para entender no que o sistema poderá lhe ajudar. A apresentação de um protótipo pode mostrar os diversos recursos e facilitar o entendimento e colaboração por parte do usuário.
v. Reuniões com responsáveis pelos sistemas de origem: importante para
avaliar se os requisitos informados pelos usuários de negócio são tangíveis e possíveis de serem obtidos a partir dos sistemas de origem.
A figura 11 mostra a relação das principais entradas, ferramentas e saídas utilizadas neste processo.
Entradas Ferramentas e Técnicas Saídas
Ativos de processos
organizacionais Análise de produtos Declaração do escopo do projeto
Termo de abertura do
projeto Identificação de alternativas Mudanças solicitadas
Declaração do escopo
preliminar do projeto Opinião especializada Plano de gerenciamento do escopo do projeto (atualizações)
Plano de gerenciamento do escopo do projeto
Análise das partes interessadas Especificação de Requisitos Multidimensionais
Solicitações de mudanças
aprovadas Entrevistas com usuários Planilhas ETL
Sessões com presença de facilitador
Apresentação dos objetivos do sistema
Apresentação de protótipo com recursos do sistema
Reuniões com equipes
responsáveis pelos sistemas de origem/transacionais
Este processo terá como saída a declaração final do escopo, segundo a visão do PMBoK, este documento deve apresentar:
i. Objetivos do projeto: o projeto pode possuir vários tipos de objetivos,
como: técnicos, de negócios, de custo, cronograma e até qualidade.
ii. Descrição do escopo do produto: descreve as características do produto,
serviço resultante do projeto.
iii. Requisitos do projeto: descreve as condições ou especificações que o
resultado do projeto deverá atender.
iv. Limites do projeto: define a fronteira entre o que está incluído e excluído
do projeto.
v. Entregas do projeto: incluem todas as saídas que compõem o resultado
do projeto.
vi. Critérios de aceitação de produtos: define o critério adotado para
aceitação dos produtos terminados.
vii. Restrições do projeto: Relaciona as restrições específicas, que estejam
associadas ao escopo do projeto.
viii. Premissas do projeto: Relaciona as premissas do projeto e seu possível
impacto. As premissas relacionadas na declaração do escopo são mais numerosas e detalhadas do que as relacionadas no termo de abertura do projeto.
Com relação ao caso específico de projetos para sistemas data warehouse, devemos
observar a inclusão de dois documentos na questão referente aos requisitos do projeto.
8.2.1 Especificação de Requisitos Multidimensionais (ERM):
Este documento tem como objetivo registrar o modelo conceitual, previamente discutido com os usuários. Ele é organizado de tal forma, que tanto membros da equipe do projeto, como usuários leigos em tecnologia, possam interpretá-lo e entender os conceitos adotados para representação do negócio.
8.2.2 Planilhas Extração, Transformação e Carga (ETL)
Este documento é resultado da interação entre a equipe do projeto e as equipes responsáveis pelos sistemas de origem, ditos transacionais. As planilhas têm como objetivo mapear os requisitos dos usuários, identificando suas respectivas origens nos sistemas transacionais. Eventuais transformações ou comportamentos diferenciados ao longo do tempo devem ser registrados neste documento. Como por exemplo:
8.3 Criar Estrutura Analítica do Projeto
Apesar de cada projeto ser único, possuindo suas próprias particularidades, podemos reutilizar modelos baseados no ciclo de vida comum para este tipo de projeto.
O projeto de data warehouse já possuiu uma subdivisão natural, que é a divisão por
assuntos ou estrelas. Ainda é importante destacar o cuidado para não decompor a níveis muito baixos, evitando o esforço excessivo no gerenciamento destes pacotes.
Entradas Ferramentas e Técnicas Saídas
Ativos de processos
organizacionais Modelos de estrutura analítica do projeto Declaração do escopo do projeto (atualizações) Declaração do escopo do
projeto Decomposição Especificação de Requisitos
Multimensionais (atualizações) Plano de gerenciamento do
escopo do projeto Estrutura analítica do projeto
Solicitações de mudanças
aprovadas Dicionário da EAP
Especificação de Requisitos
Multimensionais Linha de base do escopo
Plano de gerenciamento do escopo do projeto
(atualizações) Mudanças solicitadas
Figura 12: Criar EAP: ferramentas e técnicas, e saídas Fonte: Adaptação (PMI, 2004)
A figura 12 mostra a relação das principais entradas, ferramentas e técnicas, destacando o documento Especificação de Requisitos Multidimensionais, como documento fundamental para o processo, correspondendo a uma forte característica do gerenciamento
Linha de base do escopo do projeto
Para um sistema data warehouse, a linha de base do escopo do projeto será
composta por:
i. Declaração do escopo detalhada aprovada,
ii. Documento de especificação de requisitos multidimensionais,
iii. Planilhas ETL,
iv. EAP e
v. Dicionário da EAP.
Ressaltando a existência do segundo e terceiro item, referentes aos documentos de especificação de requisitos multidimensionais e planilhas de extração e carga.
8.4 Verificação do Escopo
Este processo é responsável pela obtenção do aceite formal, confirmando que a entrega realizada está de acordo com o escopo definido previamente. O desenvolvimento
de sistemas data warehouse costuma ocorrer por incrementos, cada novo incremento
entregue deve ser verificado e confirmado pelo cliente.
Entradas Ferramentas e Técnicas Saídas
Declaração do escopo
do projeto Inspeção Entregas aceitas
Dicionário da EAP Mudanças solicitadas
Plano de Gerenciamento do
Escopo do Projeto
Ações corretivas recomendadas
Entregas
Figura 13: Verificação do escopo: ferramentas e técnicas, e saídas Fonte: PMi, 2004
8.5 Validação do Escopo
Este processo não existe na estrutura do PMBoK, e está sendo sugerido devido ao grau de importância na identificação e registro dos requerimentos do sistema.
O processo anterior (verificação do escopo) é responsável por obter a aceitação formal, garantindo que a entrega foi concluída de forma satisfatória. Isto implica em dizer: “a entrega foi concluída conforme o que foi definido no escopo”. Este novo processo tende a responder outra pergunta, que é: “com esta definição de escopo, estaremos entregando o que o usuário realmente deseja?
Muitos projetos de data warehouse falham por não conseguir identificar o real desejo
do usuário. Este processo de validação pode aumentar as chances de sucesso do projeto.
Para viabilizar esta validação, é necessário criar um grupo ou comitê aprovador do escopo. Assim como já existe um comitê para controle de mudanças, este grupo deverá ser composto por vários partes interessadas, preferencialmente por representantes: da equipe de projeto, cliente e patrocinador.
Entradas Ferramentas e Técnicas Saídas
Declaração do escopo
do projeto validação do escopo Reunião para escopo do projeto Declaração do (atualizações) Especificação de Requisitos Multimensionais Especificação de Requisitos Multimensionais (atualizações)
Planilhas ETL Ações corretivas
recomendadas Figura 14: Validação do escopo: ferramentas e técnicas, e saídas
Fonte: Adaptação PMI, 2004
A figura 14 apresenta uma proposta para as entradas, ferramentas e saídas de um novo processo. As planilhas ETL e o documento de Especificação de Requisitos
Multidimensionais são fundamentais para caracterizar as necessidades de um projeto data
8.6 Controle do Escopo
Este processo faz parte do grupo de processos de controle, tem como principal responsabilidade tratar e controlar as mudanças e seus impactos. Pode-se dizer que em um
sistema data warehouse é impossível evitar mudanças no escopo, é normal o escopo sofrer
alterações à medida que o negócio se torna mais conhecido e o escopo mais detalhado.
Todos os processos até então tendem a minimizar o erro na definição do escopo, deve-se destacar que este controle é fundamental para o sucesso do projeto. Manter o escopo dentro dos limites é primordial, entender que os limites abordam: custo, qualidade, tempo e até mesmo o assunto do negócio.
A característica de um sistema data warehouse é de constante mudança, as regras
de negócio mudam, a política muda, o cenário econômico muda, o usuário muda, enfim tudo sofre alteração. E por isso o sistema também precisa sofrer mudanças. Ë um grande desafio identificar quando estas mudanças ultrapassam os limites de projeto e por isso
9. CONSIDERAÇÕES FINAIS
O desenvolvimento de sistemas data warehouse apresenta particularidades que o
diferencia de sistemas tradicionais. Apesar da gerência de escopo e requisitos representar o principal fator de sucesso deste tipo de projeto, as metodologias utilizadas pelo mercado ainda apresentam forte tendência em se preocupar mais com a tecnologia, em detrimento a questão de requisitos e escopo.
Uma das motivações para este trabalho é considerar que um projeto para
desenvolvimento de um sistema data warehouse é especial, apresentando particularidades
que precisam ser atendidas também de forma especial. De todas as disciplinas existentes, o gerenciamento do escopo do projeto é o maior desafio para o gerente de projetos de um
sistema data warehouse. Tanto a correta definição do escopo, como o eficaz controle de
mudanças, podem e devem fazer a diferença entre um enorme fracasso e um total sucesso.
O PMBoK (PMI,2004), considerado um guia geral de melhores práticas, não possui ferramentas e técnicas específicas para este tipo de sistema. Sem intenção de alterar o
aspecto generalista do PMBoK, podemos fazer uma leitura direcionada a um sistema data
warehouse, incluindo técnicas, ferramentas e processos específicos para levantamento de requisitos e validação do escopo.
Com esta motivação, este trabalho sugere que os projetos para sistemas data
warehouse utilizem um processo de validação do escopo, etapa que deve ser fundamental para assegurar que o escopo definido, realmente vai atender as necessidades dos
stakeholders envolvidos. Para isso é preciso assegurar que os interessados tenham consciência do que a tecnologia poderá proporcionar, somente assim, a equipe do projeto poderá ter segurança que entende a real necessidade do usuário. Este trabalho ainda sugere a utilização de artefatos específicos para este tipo de projeto, tais como: planilhas
ETL e documentos de requisitos multidimensionais, ambos os documentos facilitam o
REFERÊNCIAS BIBLIOGRÁFICAS
ADELMAN, Sid – Data warehouseProjectManagement – Addison Wesley, 2006
KIMBALL, Ralph – The Data warehouse Lifecycle Toolkit – Wiley, 1998
________, _____ – The Data warehouse Toolkit, Second Edition – Wiley, 2002
MULCAHY, Rita – PMP Exam Prep – RMC Publications, 2005
PETERSON, Tim – Microsoft OLAP Unleashed – Sams, 1999
PMI. PROJECT MANAGEMENT INSTITUTE, INC – A Guide to the Project Management
Body of Knowledge(PMBoK Guide) – Third Edition
RILSTON, Fábio – Uma Metodologia para Definição de Requisitos em Sistemas Data
warehouse – Dissertação de Mestrado. 2003
REFERÊNCIAS ELETRÔNICAS
ANEXO
Relação de disciplinas e processos PMBoK, 2004 A. Gerenciamento de integração do projeto
1. Desenvolver termo de abertura do projeto
2. Desenvolver a declaração do escopo preliminar do projeto
3. Desenvolver o plano de gerenciamento do projeto
4. Orientar e gerenciar a execução do projeto
5. Monitorar e controlar o trabalho do projeto
6. Controle integrado de mudanças
7. Encerrar o projeto
B. Gerenciamento do escopo do projeto
1. Planejamento do escopo
2. Definição do escopo
3. Criar Estrutura Analítica do Projeto
4. Verificação do Escopo
5. Controle do Escopo
C. Gerenciamento de tempo do projeto
1. Definição da atividade
2. Sequenciamento de atividades
3. Estimativa de recursos da atividade
4. Estimativa de duração da atividade
5. Desenvolvimento do cronograma
6. Controle do cronograma
D. Gerenciamento de custos do projeto
1. Estimativa de custos
3. Controle de custos
E. Gerenciamento da qualidade do projeto
1. Planejamento da qualidade
2. Realizar a garantia da qualidade
3. Realizar o controle da qualidade
F. Gerenciamento de recursos humanos do projeto
1. Planejamento de recursos humanos
2. Contratar ou mobilizar equipe do projeto
3. Desenvolver equipe do projeto
4. Gerenciar equipe do projeto
G. Gerenciamento das comunicações do projeto
1. Planejamento das comunicações
2. Distribuição das informações
3. Relatório de desempenho
4. Gerenciar as partes interessadas
H. Gerenciamento de riscos do projeto
1. Planejamento do gerenciamento de riscos
2. Identificação de riscos
3. Análise qualitativa de riscos
5. Planejamento de respostas a riscos
6. Monitoramento e controle de riscos
I. Gerenciamento de riscos do projeto
1. Planejar compras e aquisições
2. Planejar contratações
3. Solicitar respostas de fornecedores
4. Selecionar fornecedores
5. Administração de contrato
