GOVERNANÇA DE TI:

TI:

A GTI consiste em um conjunto de processos e controles que tem como objetivo propiciar
que a TI agregue valor ao negócio. Este artigo visa analisar como as empresas no Brasil
estão exercendo a Governança de TI

Governança de TI é um conjunto de práticas, padrões e

relacionamentos estruturados, assumidos por executivos,
gestores, técnicos e usuários de TI de uma organização, com
a finalidade de garantir controles efetivos, ampliar os
processos de segurança, minimizar os riscos, ampliar o
desempenho, otimizar a aplicação de recursos, reduzir os
custos, suportar as melhores decisões e conseqüentemente
alinhar TI aos negócios. (PERES apud CARVALHO, 2007)

Capacidade organizacional de controlar a formulação e

implementação da estratégia de TI e guiar a mesma na direção
adequada com o propósito de gerar vantagens competitivas para
a corporação” (THE MINISTRY OF INTERNATIONAL TRADE AND
INDUSTRY, 2003).

“Governança de TI é de responsabilidade do Corpo de Diretores

e Gerencial. GTI integra a Governança da Empresa e consiste
em mecanismos de liderança, estrutura organizacional e
processos que garantem que a TI da organização mantém e
alcançam as estratégias e objetivos da organização” (BOARD
BRIEFING ON IT GOVERNANCE, 2006).

Gerenciamento de TI tem como foco o fornecimento efetivo de serviços e produtos de

TI internos e o gerenciamento das operações de TI no presente. A GTI por sua vez é mais
abrangente e concentra-se no desempenho e transformação de TI, para atender demandas
atuais e futuras do negócio da corporação (foco interno) e negócio do cliente (foco
externo).

“Isto não diminui a importância e complexidade do Gerenciamento de TI, ..., mas enquanto
o Gerenciamento de TI e fornecimento de serviços de TI e produtos podem ser realizados
por um fornecedor externo, a Governança de TI é específica da organização, e direção e
controle sobre TI não podem ser delegados para o mercado” (PETERSON (2003) apud
GREMBERGER et. Al (2004)).

Como suporte ao processo de GTI as organizações tem utilizado metodologias novas ou já

consolidadas no mercado, optando por uma metodologia específica ou adaptando pontos de
diferentes metodologias para a realidade da organização.
O Portfólio de TI
O Portfólio de TI pode ser composto de projetos e serviços , este será o principal
instrumento de
alinhamento da estratégia com o dia-a-dia da área de TI.
É comum as organizações que estão desenvolvendo seus processos de Governança de
TI se depararem com uma diversidade de modelos de qualidade e governança à sua
disposição. Surge então a primeira dúvida: qual modelo seguir? Na edição especial da
Revista Computer World de maio de 2004, Terzian (2004) cita que, embora haja alguma
sobreposição entre esses modelos, na maior parte dos casos eles não entram em conflito e
podem até mesmo serem complementares

Muito se tem falado do Cobit (Control Objectives for Information and Related Technology)
e do ITIL (Information Technology Infrastruture Library) como base para a Governança de
TI. Outras metodologias que também costumam ser avaliadas e incorporadas como
ferramentas de Governança de TI são: International Standards Organization (ISO) 9000,
Balanced Scorecard (BSC) de TI, Seis Sigma, Project Management Institute (PMI) e
Capability Maturity Model (CMM).

BSC:

2.2.4.1 - CobiT - Control Objectives for Information and Related Technology

O CobiT - Control Objectives for Information and Related Technology - foi
desenvolvido na década de 90 pela ISACA - Information System Audit and Control
Association - e pode ser traduzido como Objetivos de Controle para a Informação e
Tecnologia. O Cobit é um modelo de governança em TI, criado para alinhar os recursos e
processos de TI com os objetivos do negócio, padrões de qualidade, controle monetário e
necessidades de segurança (OLTISIK, 2003). Ele é composto por quatro domínios:
Planejamento e Organização; Aquisição e Implementação; Entrega e Suporte; e
Monitoramento.

2.2.4.2 - ITIL - Information Technology Infrastructure Library

O ITIL, Information Technology Infrastruture Library, foi criado no final dos anos 80
pela Central Computing and Telecommunications Agency para o governo britânico,
reunindo um conjunto de recomendações divididas em dois blocos: suporte de serviços
(service support), que inclui cinco disciplinas e uma função; e entrega de serviços (service
delivery), com mais cinco disciplinas (CACIATO, 2004). O foco deste modelo é descrever
os processos necessários para gerenciar a infra-estrutura de TI eficientemente e
eficazmente, de modo a garantir os níveis de serviço acordados com os clientes internos e
externos. O ITIL trata de disciplinas táticas, ou de planejamento, e operacionais.

COBIT:

O CobiT é um guia para a gestão de TI recomendado pelo ISACF

(Information Systems Audit and Control Foundation,
www.isaca.org). O CobiT inclui recursos tais como um sumário
executivo, um framework, controle de objetivos, mapas de
auditoria, um conjunto de ferramentas de implementação e um
guia com técnicas de gerenciamento. As práticas de gestão do
CobiT são recomendadas pelos peritos em gestão de TI que
ajudam a otimizar os investimentos de TI efornecem métricas
para avaliação dos resultados. O CobiT independe das
plataformas de TI adotadas nas empresas.

O CobiT é orientado ao negócio. Fornece informações

detalhadas para gerenciar processos baseados em objetivos de
negócios. O CobiT é projetado para auxiliar diferentes
audiências como: gerentes que necessitam avaliar o risco e
controlar os investimentos de TI em uma organização; usuários
que precisam ter garantias de que os serviços de TI que
dependem os seus produtos eserviços para os clientes internos
e externos estão sendo bem gerenciados e auditores que podem
se apoiar nas recomendações do CobiT para avaliar o nível da
gestão de TI e aconselhar o controle interno da organização.
O CobiT é um modelo e uma ferramenta de suporte que permite
aos gerentes suprir as deficiências com respeito aos
requisitos de controle, questões técnicas e riscos de
negócios, comunicando esse nível de controle às partes
interessadas. O CobiT habilita o desenvolvimento de políticas
claras e boas práticas para controles de TI em toda a
empresa. O CobiT é atualizado continuamente e harmonizado com
outros padrões e guias. Assim, o CobiT tornou-se o integrador
de boas práticas de TI e a metodologia de governança de TI
que ajuda no entendimento e gerenciamento dos riscos e
benefícios associados com TI.

O Control Objectives for Information and related Technology (CobiT®) fornece boas
práticas através de um modelo de domínios e processos e apresenta atividades em uma
estrutura lógica e gerenciável. As boas práticas do CobiT representam o consenso de
especialistas. Elas são fortemente focadas mais nos controles e menos na execução. Essas
práticas irão ajudar a otimizar os investimentos em TI, assegurar a entrega dos serviços e
prover métricas para julgar quando as coisas saem erradas.

Para a área de TI ter sucesso em entregar os serviços requeridos pelo negócio, os executivos
devem implementar um sistema interno de controles ou uma metodologia. O modelo de
controle do CobiT contribui para essas necessidades ao:
· Fazer uma ligação com os requisitos de negócios.
· Organizar as atividades de TI em um modelo de processos geralmente aceito.
· Identificar os mais importantes recursos de TI a serem utilizados.
· Definir os objetivos de controle gerenciais a serem considerados.

A orientação aos negócios do CobiT consiste em objetivos de negócios ligados a objetivos

de TI, provendo métricas e modelos de maturidade para medir a sua eficácia e identificando
as responsabilidades relacionadas dos donos dos processos de negócios e de TI.

O foco em processos do CobiT é ilustrado por um modelo de processos de TI subdivididos

em quatro domínios e 34 processos em linha com as áreas responsáveis por planejar,
construir, executar e monitorar, provendo assim uma visão total da área de TI.

Conceitos de arquitetura corporativa ajudam a identificar os recursos essenciais para o

sucesso dos processos, ou seja, aplicativos, informações, infraestrutura e pessoas.

A estrutura de processos do CobiT e o seu enfoque de alto nível orientado aos negócios
fornece uma visão geral de TI e das decisões a serem tomadas sobre o assunto.

Os benefícios de implementar o CobiT como um modelo de governança de TI incluem:

· Um melhor alinhamento baseado no foco do negócio
· Uma visão clara para os executivos sobre o que TI faz
· Uma clara divisão das responsabilidades baseada na orientação para processos
· Aceitação geral por terceiros e órgãos reguladores
· Entendimento compreendido entre todas as partes interessadas, baseado em uma
linguagem comum
· Cumprimento dos requisitos do COSO para controle do ambiente de TI.

Para que a governança de TI seja eficiente, é importante avaliar as atividades e riscos da TI

que precisam ser gerenciados. Geralmente eles são ordenados por domínios de
responsabilidade de planejamento, construção, processamento e monitoramento. No
modelo CobiT esses domínios, como demonstrado na Figura 8, são denominados:
· Planejar e Organizar (PO) - Provê direção para entrega de soluções
(AI) e entrega de serviços (DS)
· Adquirir e Implementar (AI) - Provê as soluções e as transfere
para tornarem-se serviços
· Entregar e Suportar (DS) - Recebe as soluções e as torna passíveis
de uso pelos usuários finais
· Monitorar e Avaliar (ME) - Monitora todos os processos para
garantir que a direção definida seja seguida.

PLANEJAR E ORGANIZAR (PO)

Este domínio cobre a estratégia e as táticas, preocupando-se com a identificação da maneira
em que TI pode melhor contribuir para
atingir os objetivos de negócios. O sucesso da visão estratégica precisa ser planejado,
comunicado e gerenciado por diferentes perspectivas.
Uma apropriada organização bem como uma adequada infraestrutura tecnológica devem ser
colocadas em funcionamento.
Este domínio tipicamente ajuda a responder as seguintes questões gerenciais:
· As estratégias de TI e de negócios estão alinhadas?
· A empresa está obtendo um ótimo uso dos seus recursos?
· Todos na organização entendem os objetivos de TI?
· Os riscos de TI são entendidos e estão sendo gerenciados?
· A qualidade dos sistemas de TI é adequada às necessidades de negócios?

ADQUIRIR E IMPLEMENTAR (AI)

Para executar a estratégia de TI, as soluções de TI precisam ser identificadas, desenvolvidas
ou adquiridas, implementas e integradas
ao processo de negócios. Além disso, alterações e manutenções nos sistemas existentes são
cobertas por esse domínio para
assegurar que as soluções continuem a atender aos objetivos de negócios. Este domínio
tipicamente trata das seguintes questões de
gerenciamento:
· Os novos projetos fornecerão soluções que atendam às necessidades de negócios?
· Os novos projetos serão entregues no tempo e orçamento previstos?
· Os novos sistemas ocorreram apropriadamente quando implementado?
· As alterações ocorrerão sem afetar as operações de negócios atuais?
ENTREGAR E SUPORTAR (DS)
Este domínio trata da entrega dos serviços solicitados, o que inclui entrega de serviço,
gerenciamento da segurança e continuidade,
serviços de suporte para os usuários e o gerenciamento de dados e recursos operacionais.
Trata geralmente das seguintes questões
de gerenciamento:
· Os serviços de TI estão sendo entregues de acordo com as prioridades de negócios?
· Os custos de TI estão otimizados?
· A força de trabalho está habilitada para utilizar os sistemas de TI de maneira produtiva e
segura?
· Os aspectos de confidencialidade, integridade e disponibilidade estão sendo contemplados
para garantir a segurança da informação?

MONITORAR E AVALIAR (ME)

Todos os processos de TI precisam ser regularmente avaliados com o passar do tempo para
assegurar a qualidade e a aderência aos
requisitos de controle. Este domínio aborda o gerenciamento de performance, o
monitoramento do controle interno, a aderência
regulatória e a governança. Trata geralmente das seguintes questões de gerenciamento:
· A performance de TI é mensurada para detectar problemas antes que seja muito tarde?
· O gerenciamento assegura que os controles internos sejam efetivos e eficientes?
· O desempenho da TI pode ser associado aos objetivos de negócio?
· Existem controles adequados para garantir confidencialidade, integridade e
disponibilidade das informações?
Figura 13 - Modelo de Maturidade Genérico
0 Inexistente – Completa falta de um processo reconhecido. A empresa nem mesmo
reconheceu que existe uma questão a ser trabalhada.
1 Inicial / Ad hoc – Existem evidências que a empresa reconheceu que existem questões e
que precisam ser trabalhadas. No entanto, não existe processo padronizado; ao contrário,
existem enfoques Ad Hoc que tendem a ser aplicados individualmente ou caso-a-caso. O
enfoque geral de gerenciamento é desorganizado.
2 Repetível, porém Intuitivo – Os processos evoluíram para um estágio onde
procedimentos similares são seguidos por diferentes pessoas fazendo a mesma tarefa. Não
existe um treinamento formal ou uma comunicação dos procedimentos padronizados e a
responsabilidade é deixado com o indivíduo.
Há um alto grau de confiança no conhecimento dos indivíduos e conseqüentemente erros
podem ocorrer.
3 Processo Definido – Procedimentos foram padronizados, documentados e comunicados
através de treinamento. É mandatório que esses processos sejam seguidos; no entanto,
possivelmente desvios não serão detectados. Os procedimentos não são sofisticados mas
existe a formalização das práticas existentes.
4 Gerenciado e Mensurável – A gerencia monitora e mede a aderência aos procedimentos
e adota ações onde os processos parecem não estar funcionando muito bem. Os processos
estão debaixo de um constante aprimoramento e fornecem boas práticas. Automação e
ferramentas são utilizadas de uma maneira limitada ou fragmentada.
5 Otimizado – Os processos foram refinados a um nível de boas práticas, baseado no
resultado de um contínuo aprimoramento e modelagem da maturidade como outras
organizações. TI é utilizada como um caminho integrado para automatizar o fluxo de
trabalho, provendo ferramentas para aprimorar a qualidade e efetividade, tornando a
organização rápida em adaptar-se.
ITIL:

Prove um conjunto de melhores praticas para identificação de

processos e alinhamento de serviços às necessidades da
empresa objetivando obter vantagens para a empresa, redução
de custos e aumento da eficiência dos produtos e serviços.
O ITIL descreve os processos que são necessários para dar
suporte à utilização e ao gerenciamento da infra-estrutura de
TI. Outro princípio fundamental do ITIL é o fornecimento de
qualidade de serviço aos clientes de TI com custos
justificáveis, isto é, relacionar os custos dos serviços de
tecnologia e como estes trazem valor estratégico ao negócio.

O ITIL é um conjunto de melhores práticas para gerenciamento

de TI consagrado como um caminho seguro e bem sucedido na
busca de níveis mais elevados de desempenho. Foi criado pelo
Office of Government Commerce (OGC) no final da década de 80,
tendo como premissa que todos os tipos de negócio são
dependentes da área de TI, visando aumentar a qualidade dos
serviços. Sua divulgação é realizada pelo Information hnology
Service Management Forum (ITSMF) através de empresas
parceiras.
Em face do exposto, para assegurar um controle efetivo dos
processos de TI, a utilização do modelo de melhores práticas
ITIL garante maior certeza quanto à transparência dos
processos, redução dos custos de tecnologia e maior
desempenho dos ativos de tecnologia e do departamento de TI
como um todo.

Visão sobre ITIL v3

O ITIL v3, publicado em maio de 2007, é composto de cinco volumes:

• Estratégia do serviço (Service Strategy)

• Projeto de serviço ou Desenho de serviço(Service Design)
• Transição do serviço (Service Transition)
• Operação do serviço (Service Operation)
• Melhoria contínua do serviço (Continual Service Improvement)

[editar] Estratégia do serviço

Como ponto de origem do ciclo de vida de serviço ITIL, o volume sobre estratégia do
serviço é um guia sobre como tornar mais claro e priorizar investimentos sobre provimento
de serviços.
Os pontos chaves sobre este volume são:

• Definição do valor do serviço;

• Desenvolvimento de um caso de negócio;
• Ativos do serviço (service assets);
• Análise de mercado;
• Tipos de provimento de serviço.

Processos incluem gerenciamento da carteira de serviços, gerenciamento de demandas, e

gerenciamento financeiro de IT.

[editar] Desenho de serviço

O volume de desenho do serviço é um guia sobre boas práticas no projeto de serviços de IT,
processos, e outros aspectos no esforço de gerenciamento de serviços.

Projeto com ITIL é entender para englobar todos os elementos relevantes à entrega de
serviços de tecnologia, ao invés de focar somente no projeto da tecnologia propriamente
dita. Assim, projeto de serviços aponta como uma solução planejada de serviço interage
com o negócio e ambiente técnico.

Com ITIL, trabalho de projetar um serviço de TI é agregado em um simples pacote de

projeto de serviços (Service Design Package - SDP). SDP, em conjunto com outros
serviços de informação, são gerenciados com um catálogo de serviços.

Processos inclusos neste volume incluem gerenciamento do nível de serviço (Service Level
Management - SLA), gerenciamento de disponibilidade, gerenciamento de capacidade,
gerenciamento de serviços de IT continuados, gerenciamento de segurança da informação,
gerenciamento de fornecedores e gerenciamento de catálogo de serviços..

[editar] Transição do serviço

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso

operacional, e geralmente englobam o "projeto".

Tópicos deste volume incluem gerenciamento de configurações e ativos de serviço,

planejamento de transição e suporte, gerenciamento de liberação e entrega (release and
deployment), gerenciamento de alterações (Change Management), gerenciamento de
conhecimento, assim como os papéis da equipe engajada na transição do serviço.

[editar] Operação do serviço

Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim,
monitoramento de problema e balanceamento entre disponibilidade de serviço e custo, etc,
são considerados.
Tópicos inclusos são balanceamento do conflito das metas (disponibilidade vs custo, etc),
gerenciamento de eventos, gerenciamento de incidentes, gerenciamento de problemas,
cumprimento dos pedidos, gerenciamento de acesso, (service desk).

[editar] Melhoria contínua do serviço

A meta do CSI (Continual Service Improvement) é ajustar e reajustar serviços de IT às

mudanças contínuas do negócio através da identificação e implementação de melhorias aos
serviços de IT que apoiam processos negociais.

Para gerenciar melhorias, o CSI deve definir claramente o que deve ser controlado e
medido.

DIFERENÇAS ENTRE COBIT E ITIL:

Temos COBIT para gestão da TI inovando através de Governança Tecnológica e o ITIL

que padroniza uma serie de processos operacionais e de gestão de TI.

O modelo de gestão ITIL focaliza seus objetivos e estratégias em processos de TI e está

mais limitado em segurança e desenvolvimento de sistemas. Já o COBIT é consistente em
controles e métricas de TI.

O modelo ITIL se aplica melhor em empresas que buscam estruturação e organização de

sua área de TI baseado na modularização dos processos de TI.

O COBIT é mais bem aplicado em empresas que já tem estruturado o setor de TI e busca
administração da área focalizada em auditoria, controle e métricas.

PMBOK

Objetivo

Identificar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que

é amplamente reconhecido como boa prática.

O que é um PROJETO?

É um esforço temporário empreendido para criar um produto, serviço ou resultado

exclusivo.

Características de um projeto
Temporário;
Gera um produto, serviço ou resultado;
Elaboração progressiva.
O que é gerenciamento de projeto?

É a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do

projeto a fim de atender aos requisitos.

Grupo de Processos de Gerencia de Projetos

• Iniciação;
• Planejamento;
• Execução;
• Monitoramento e Execução;
• Encerramento.

Áreas de conhecimento

• Gerência de Integração do projeto

• Gerência de Escopo do Projeto;
• Gerência de Tempo do Projeto;
• Gerência de Custos do Projeto;
• Gerência da Qualidade do Projeto;
• Gerência de Recursos Humanos do Projeto;
• Gerência de Comunicações do Projeto;
• Gerência de Riscos do Projeto;
• Gerência de Aquisições do Projeto.

Áreas de Especialização

• O Conjunto de Conhecimentos em Gerenciamento de Projetos;

• Conhecimento, normas e regulamentos da área de aplicação;
• Entendimento do ambiente do projeto;
• Conhecimentos e habilidades de gerenciamento geral
• Habilidades Interpessoais

Conhecimento em Gerencia de projeto Consiste em:

• Definição de um ciclo de vida;

• Aplicação de 5 processos e
• 9 áreas de conhecimentos.

Norma X Regulamento

Norma é um documento estabelecido por consenso e aprovado por um organismo

reconhecido que fornece, para uso comum e repetido, regras, diretrizes ou características
para atividades ou seus resultados, visando à obtenção de um grau ideal de ordenação em
um dado contexto
Regulamento é uma exigência imposta pelo governo que especifica características do
produto, processo ou serviço, inclusive as cláusulas administrativas aplicáveis com as quais
a conformidade é obrigatória.

Entendimento do ambiente do projeto

• Ambiente Cultural e Social;

• Ambiente Internacional e Político;
• Ambiente Físico.

Habilidades Interpessoais

• Comunicação Eficaz;
• Influência sobre a organização;
• Liderança;
• Motivação;
• Negociação e Gerenciamento de Conflitos;
• Resolução de Problemas.

Conteúdo de Gerência de Projeto

Programas e Gerenciamento de Programas

Programa é um grupo de Projeto relacionado gerenciados de modo coordenado para a

obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados
individualmente.

Portfólios e Gerenciamento de Portfólios

É um conjunto de projetos ou programas e outros trabalhos agrupados para facilitar o

gerenciamento eficaz desse trabalho a fim de atender os objetivos de negócios estratégicos.

Subprojeto

Os projetos são freqüentemente divididos em componentes mais facilmente gerenciáveis ou

subprojetos, embora os subprojetos individuais possam ser chamados de projetos e
gerenciados como tal.

Ciclo de Vida e Organização do Projeto

Definição de Ciclo de Vida

Ciclo de vida consiste no conjunto de fases de um projeto.

O ciclo de vida define as fases que conectam o início de um projeto ao seu final.

Características do ciclo de vida

 • A transição de uma fase para a outra dentro do ciclo de vida de um projeto
geralmente envolve e é definida por alguma transferência técnica ou entrega.
• Os níveis de custo e de pessoal são baixos no início, atingem o valor máximo
durante as fases intermediárias e caem rapidamente conforme o projeto é finalizado.
• O nível de incerteza é o mais alto e, portanto o risco de não atingir os objetivos é
maior no início. A certeza de término geralmente se torna cada vez maior conforme
o projeto continua.
• A capacidade das partes interessadas de influenciarem as características finais do
projeto e o custo final do projeto é mais alta no início do projeto e torna-se menor
conforme o projeto continua.

Características das Fases do Projeto

• O término e a aprovação de um ou mais produtos caracteriza uma faze do projeto.

• O término formal da fase não inclui a autorização da fase seguinte. Para um controle
eficaz, cada fase é formalmente iniciada para produzir uma saída dependente da fase
do grupo de processos de iniciação, especificando o que é permitido e esperado para
essa fase.
• Uma fase do projeto em geral é concluída com uma revisão do trabalho realizado e
dos produtos para definir a aceitação.

Partes Interessadas no Projeto

• Gerente de Projetos;
• Cliente/Usuário;
• Organização Executora;
• Membros da Equipe do Projeto;
• Equipe de Gerenciamento de Projeto;
• Patrocinador;
• Influenciador;
• PMO.

Estruturas Organizacionais

• Organização Funcional
• Organização Matricial
• Organização Matricial Fraca;
• Organização Matricial Balanceada;
• Organização Matricial Forte;
• Organização Por Projeto

Sistema Gerenciamento de Projetos

É o conjunto de ferramentas, técnicas metodologias, recursos e procedimentos usados para

gerenciar o projeto.

Processos de Gerênciamento de Projeto

O que é PROCESSO?

Processo é o conjunto de ações e atividades inter-relacionadas realizadas para obter um

conjunto pré-especificado de produtos, resultados ou serviços. Divide-se em duas
categorias:

1. Processos de Gerenciamento de Projetos;

2. Processos Orientados ao Produto.

Grupo de Processos de Gerência de Projetos

Grupo de Processos de Iniciação

Define e autoriza o projeto ou uma fase do projeto.

1. Desenvolver o Termo de Abertura do Projeto;

2. Desenvolver a declaração do escopo preliminar do projeto.

Grupo de Processos de Planejamento

Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o

escopo para os quais o projeto foi realizado.

1. Desenvolver o plano de gerenciamento do projeto;

2. Planejamento do Escopo;
3. Definição do Escopo;
4. Criar EAP;
5. Definição da Atividade;
6. Seqüenciamento da atividade;
7. Estimativa de Recursos da Atividade;
8. Estimativa de Duração da Atividade;
9. Desenvolvimento do Cronograma;
10. Estimativa de Custos;
11. Orçamentação;
12. Planejamento da Qualidade;
13. Planejamento de Recursos Humanos;
14. Planejamento de comunicações;
15. Planejamento de Gerenciamento de Riscos;
16. Identificação de Riscos;
17. Análise Qualitativa de Riscos;
18. Análise Quantitativa de Riscos;
19. Planejamento de Respostas a Riscos;
20. Planejar compras e aquisições;
21. Planejar Contratações.
Grupo de Processos de Execução

Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o
projeto.

1. Orientar e Gerenciar a Execução do Projeto;

2. Realizar a garantia da qualidade;
3. Contratar ou Mobilizar a Equipe do Projeto;
4. Desenvolver a equipe do projeto;
5. Distribuir as informações;
6. Solicitar respostas de fornecedores;
7. Selecionar fornecedores.

Grupo de Processos de Monitoramento e Controle

Mede e monitora regularmente o progresso para identificar variações em relação ao plano

de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando
necessário para atender aos objetivos do projeto.

1. Monitorar e Controlar o Trabalho do Projeto;

2. Controle integrado de mudanças;
3. Verificação do Escopo;
4. Controle do Escopo;
5. Controle do Cronograma;
6. Controle de Custos;
7. Realizar o Controle da qualidade;
8. Gerenciar a equipe do projeto;
9. Relatório de desempenho;
10. Gerenciar as partes interessadas;
11. Monitoramento e Controle de Riscos;
12. Administração de Contrato.

Grupo de Processos de Encerramento

Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do

projeto a um final ordenado.

1. Encerrar o Projeto;
2. Encerramento do Contrato
CMMI:

O CMMI (Capability Maturity Model Integration) é um modelo de

referência que fornece orientação para o desenvolvimento de
processos de softwares e tem como objetivos eliminar suas
inconsistências; aumentar sua clareza e entendimento;
fornecer uma terminologia comum e um estilo consistente;
estabelecer regras de construção uniformes e assegurar
consistência com a ISO/IEC 15504.
Como seus antecessores, o CMMI não define como o processo
deve ser implementado, mas prescreve suas características
estruturais e semânticas embora todos os modelos derivados
do CMM tenham eficiência comprovada na prática, usar vários
modelos em uma empresa é complicado, logo, os modelos foram
integrados no CMMI.

Desde 1991, diversos modelos CMM têm sido desenvolvidos pelo

SEI (Software Engineering Institute) para uma diversidade de
disciplinas específicas, como, por exemplo, desenvolvimento
integrado de produtos, engenharia de sistemas e engenharia de
software (BATE, 1997), (BATE, 1995), (PAULK, 1993).
Embora esses modelos tenham sido aplicados com sucesso em
organizações desenvolvedoras de software, o seu uso em
conjunto apresenta problemas.
Esses modelos apresentam diferenças em suas arquiteturas,
conteúdos, terminologias e abordagens, dificultando sua
implementação em conjunto e limitando as habilidades das
organizações em implementar satisfatoriamente as melhorias em
seus processos (CMU/ SEI-2002-TR-012, 2002).
Dessa forma, o SEI iniciou o projeto CMMI, com o objetivo de
integrar os diversos modelos CMM anteriores. Desse projeto
resultou um framework único para melhoria de processos, e
também oferecendo a possibilidade de integração de futuros
modelos para disciplinas específicas.

O CMMI Framework consiste em um conjunto de modelos

integrados, um método de avaliação e produtos de apoio. Além
disso, ele foi desenvolvido de modo a ser compatível com a
Norma ISO/IEC 15504, procurando garantir que as avaliações
que têm como base tanto os modelos CMMI1 quanto o modelo
definido nessa norma sejam equivalentes.

O CMM define cinco níveis de maturidade, sendo que no primeiro a empresa desenvolve
sistemas baseando-se apenas na experiência das pessoas que trabalham na empresa, e no
último existe um processo organizado, flexível, com um planejamento eficiente e
continuamente melhorado. Para que uma empresa seja considerada mais madura e aumente
seu nível de maturidade, ela deve cumprir metas específicas, chamadas áreas de processo
(key process área – KPA). Por exemplo, uma área de processo do nível 2 do CMM seria a
garantia de qualidade de software.
O CMMI está dividido em duas formas de representação diferentes – estagiada e contínua.
A estagiada divide as áreas de processo em cinco níveis de maturidade, à maneira do
CMM; A representação contínua define níveis de capacidade. As diferenças entre ambos
são meramente organizacionais; o conteúdo é equivalente. Ambos podem ser usados para
conseguir níveis em suas respectivas caracterizações.
O CMMI possui duas representações: "contínua" ou "por estágios". Elas permitem à
organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
A contínua permite que uma organização selecione uma área (ou um grupo de áreas) de
processo e melhore os processos relacionados. Ela usa níveis de capacidade para
caracterizar melhorias relativas a uma área de processo individual.
A estagiada usa conjuntos pré-definidos de áreas de processo (KPA's) para definir um
caminho para uma organização, caracterizado por níveis de maturidade. Cada nível contém
um conjunto de áreas de processo que caracterizam diferentes comportamentos
organizacionais, correspondendo à capacidade da empresa de realizar projetos grandes e
complexos.
Na representação contínua, o enfoque ou componentes principais são as áreas de
processo. Existem metas e práticas de dois tipos: específicas a uma determinada área de
processo e genéricas aplicáveis indistintamente a todas as áreas de processo. A partir da
avaliação e do atendimento dessas práticas e metas é possível classificar o nível de
capacidade de cada área de processo, em níveis de zero a cinco:
Nível 0 - Incompleto: um processo é parcialmente realizado ou não realizado. Um ou mais
objetivos específicos do processo não estão satisfeitos.
Nível 1 - Realizado: um processo realizado satisfaz todos os objetivos específicos da área
de processo e produz algum trabalho.
Nível 2 - Gerenciado: um processo de capacidade nível 2 é um processo realizado (nível 1)
que também é planejado e executado de acordo com políticas pré-definidas. Emprega
pessoas hábeis com os recursos adequados para produzir saídas adequadas, envolve os
stakeholders principais e é monitorado, controlado, revisto e avaliado quanto à aderência à
sua descrição. A gerência do processo é relacionada com a realização de objetivos
específicos estabelecidos para o processo, como custo, cronograma e qualidade.
Nível 3 - Definido: um processo definido é um processo gerenciado e ajustado para o
conjunto padrão de processos da organização de acordo com suas políticas de conduta. Esse
conjunto é estabelecido e melhorado com o tempo e descreve os elementos fundamentais de
processos que são esperados nos processos definidos.
Nível 4 - Gerenciado quantitativamente: um processo neste nível é definido e controlado
com a ajuda de técnicas quantitativas e estatísticas. A qualidade e o desempenho do
processo são compreendidos em termos estatísticos e são geridos durante sua vida.
Objetivos quantitativos para qualidade e desempenho de processos são estabelecidos e
usados como critério na gerência do processo.
Nível 5 - Otimizado: um processo otimizado é gerenciado quantitativamente, alterado e
adaptado para atender aos objetivos de negócio atuais e projetados. Tal processo enfoca a
melhoria contínua do desempenho do processo através de aprimoramentos tecnológicos
inovadores e incrementais, selecionados com base em uma compreensão quantitativa de sua
contribuição esperada à obtenção da melhoria de processos.

A representação em estágios oferece uma abordagem estruturada e sistemática para a

melhoria de um estágio por vez. Atingir um estágio significa que uma estrutura de processo
adequada foi estabelecida como base para o próximo estágio.
As áreas de processo são organizadas por níveis de maturidade (1 a 5), que definem o
caminho de melhoria que uma organização deve seguir do nível inicial ao nível otimizado.
Dentro de cada nível, existem áreas de processo que contêm metas, características comuns
e práticas.
Na representação em níveis, as práticas são caracterizadas pelos atributos: compromisso
para execução (práticas que garantem que o processo seja estabelecido e apoiado);
habilidade para execução (práticas que criam condições para que o processo seja
estabelecido completamente) e atividade para execução (práticas que implementam
diretamente o processo); controle e verificação de implementação. A transição entre os
níveis resulta em melhorias incrementais e duradouras. A figura 02 esquematiza as metas e
práticas desse modelo:

Os estágios de maturidade são:

Nível 1 - Inicial: É o nível de maturidade CMMI mais baixo. Em geral, as organizações
desse nível têm processos imprevisíveis que são pobremente controlados e reativos. Nesse
nível de maturidade os processos são normalmente “ad hoc” e caóticos. A Organização
geralmente não fornece um ambiente estável. Neste nível não há KPA's.
Nível 2 – Gerenciado: No nível de maturidade 2 os projetos da organização têm a garantia
de que os requisitos são gerenciados, planejados, executados, medidos e controlados.
Quando essas práticas são adequadas, os projetos são executados e controlados de acordo
com o planejado. O foco, neste nível, é o gerenciamento básico de projetos e tem as
seguintes KPA's desse nível são: gerenciamento de requisitos; planejamento do projeto;
controle e monitoração do projeto; gerenciamento de suprimentos; avaliação e análise;
garantia da qualidade do processo; configuração do gerenciamento.
Nível 3 – Definido: No nível de maturidade 3, em que todos os objetivos específicos e
genéricos atribuídos para os níveis de maturidade 2 e 3 foram alcançados, os processos são
melhor caracterizados e entendidos e são descritos em padrões, procedimentos, ferramentas
e métodos. O foco neste nível é a padronização do processo, tendo como KPA's: requisitos
de desenvolvimento; soluções técnicas; integração de produtos; verificação; validação; foco
no processo organizacional; definição do processo organizacional; treinamento
organizacional; gerenciamento de projeto integrado; gerenciamento de riscos; integração da
equipe de trabalho; gerenciamento integrado de suprimentos; análise de decisões; ambiente
organizacional para integração.
Nível 4 - Quantitativamente Gerenciado: No nível de maturidade 4, em que os objetivos
específicos atribuídos para os níveis de maturidade 2, 3 e 4 e os objetivos genéricos
atribuídos para os níveis de maturidade 2 e 3 foram alcançados, os processos são medidos e
controlados. O foco neste nível é o gerenciamento quantitativo e possui as seguintes KPA's:
performance organizacional do processo; gerenciamento quantitativo de projetos.
Nível 5 – Otimizado: No nível de maturidade 5, o mais alto nível de maturidade CMMI,
uma organização atingiu todos os objetivos específicos atribuídos para os níveis de
maturidade 2, 3, 4 e 5, e os objetivos genéricos atribuídos para os níveis de maturidade 2 e
3. Os processos são continuamente aperfeiçoados, baseados em um entendimento
quantitativo em que a variação de um processo existe devido às interações, normais e
presumidas, entre os componentes desse processo. Esse nível de maturidade tem como
objetivo a melhoria contínua do processo. As KPA's desse nível são: inovação
organizacional e análise de causas e resoluções.

Standard CMMI Appraisal Method for Process Improvement

Elaborado pelo SEI, o método de avaliação SCAMPI (Standard CMMI Appraisal Method
for Process Improvement) fornece graduação de maturidade de processo em relação aos
modelos CMMI (CMU/SEI-2001-HB-001, 2001), tendo dois objetivos principais:
1 - Fornecer um método de avaliação integrado e único, capaz de ser utilizado nos
contextos de melhoria interna de processo, seleção de fornecedor e acompanhamento de
processo.
2 - Fornecer um método de avaliação eficiente, possível de ser implementado dentro de
restrições razoáveis de desempenho. Como um método Classe A de avaliação, ele satisfaz
todos os requisitos do ARC V1.1 (ARC, 2001)
O SCAMPI é um método padrão que possibilita o diagnóstico do estado atual de qualidade
de processo de uma organização, baseado nos modelos de qualidade
definidos no CMMI. Esses modelos de qualidade são aplicáveis em organizações de
qualquer porte, e o SCAMPI pode ser utilizado para avaliar o nível de
adequação a esses modelos, direcionando essas organizações para a melhoria progressiva
de seus processos.
Pode ser observado que as empresas que adotaram o CMMI como modelo de qualidade, e
utilizaram os resultados de avaliações obtidas com o método SCAMPI, obtiveram
melhorias expressivas em seus processos de software. Dessa forma, uma crescente
utilização do SCAMPI pelas empresas que adotaram o
CMMI pode ser uma tendência.
O método SCAMPI é utilizado para avaliação do nível de capacidade, no caso de uma área
de processos, ou do nível de maturidade do processo de software, no
caso de uma unidade org anizacional. Entretanto, a qualidade dos produtos de software
resultante desses processos não é avaliada, tornando-se necessária à
utilização de outros métodos específicos. Tal fato implica em maiores custos e maior
demanda de tempo, pois seria necessária, a princípio, uma nova equipe de avaliação, que
teria que receber os devidos treinamentos.
Seria interessante a proposta de um método único, que ao final de sua aplicação, resultasse
na avaliação da qualidade tanto do processo quanto dos produtos
resultantes desse processo.
Tem duas diferentes abordagens para a melhoria dos processos. Estas duas abordagens são
conhecidas como modelo continuo e modelo em estágios:

MPS BR

O MPS.BR1 é um programa mobilizador, de longo prazo, criado em dezembro de 2003,

coordenado pela Associação para Promoção da Excelência do Software Brasileiro
(SOFTEX), que conta com apoio do Ministério da Ciência e Tecnologia (MCT),
Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID).
O objetivo do programa MPS.BR (acrônimo) é a Melhoria de Processo do Software
Brasileiro, com duas metas a alcançar a médio e longo prazos:

a) meta técnica, visando à criação e aprimoramento do modelo MPS, com resultados

esperados tais como: (i) guias do modelo MPS; (ii) Instituições Implementadoras (II)
credenciadas para prestar serviços de consultoria de implementação do modelo de
referência MR-MPS; (iii) Instituições Avaliadoras (IA) credenciadas para prestar serviços
de avaliação seguindo o método de avaliação MA-MPS; (iv) Consultores de Aquisição
(CA) certificados para prestar serviços de consultoria de aquisição de software e serviços
relacionados;
b) meta de mercado, visando à disseminação e adoção do modelo MPS, em todas as regiões
do país, em um intervalo de tempo justo, a um custo razoável, tanto em PME (foco
principal) quanto em grandes organizações públicas e privadas, com resultados esperados
tais como: (i) criação e aprimoramento do modelo de negócio MN-MPS; (ii) cursos, provas
e workshops; (iii) organizações que implementaram o modelo MPS; (iv) organizações com
avaliação MPS publicada (prazo de validade de três anos).

Uma das metas do programa MPS.BR é definir e aprimorar um modelo de melhoria e

avaliação de processo de software, visando preferencialmente às micro, pequenas e médias
empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e
internacionalmente como um modelo aplicável à indústria de software. O modelo MPS
estabelece um modelo de processos de software e um processo e um método de avaliação
de processos. Esta estrutura fornece sustentação e garante que o modelo MPS esteja sendo
empregado de forma coerente com as suas definições. O modelo MPS estabelece também
um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras
de software.
A base técnica para a construção e aprimoramento deste modelo de melhoria e avaliação de
processo de software é composta pelas normas ISO/IEC 12207:2008 [ISO/IEC, 2008a] e
ISO/IEC 15504-2 [ISO/IEC, 2003].

Uma avaliação MPS é realizada utilizando o processo e o método de avaliação MA-MPS

descritos no guia de avaliação. Uma avaliação MPS verifica a conformidade de uma
organização/unidade organizacional aos processos do MR-MPS.
O modelo MPS está dividido em três (3) componentes (Figura 1): Modelo de Referência
(MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada
componente é descrito por meio de guias e/ou documentos do modelo MPS.

O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades

organizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém as
definições dos níveis de maturidade, processos e atributos do processo, e está descrito neste
Guia Geral, nas seções 8 e 9. O MR-MPS está em conformidade com os requisitos de
modelos de referência de processo da Norma Internacional ISO/IEC 15504-2 [ISO/IEC,
2003]. O Guia de Aquisição é um documento complementar destinado a organizações que
pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém
requisitos do MR-MPS, mas boas práticas para a aquisição de software e serviços
correlatos. O Guia de Implementação nas partes 1 a 7 sugere formas de implementar cada
um dos níveis do MR-MPS. A parte 8 do Guia de Implementação sugere formas de como
uma unidade organizacional que faz Aquisição de produtos pode implementar o MR-MPS.
As explicações presentes nos Guias de Implementação não constituem requisitos do modelo
e devem ser consideradas apenas em caráter informativo

O Guia de Avaliação contém o processo e o método de avaliação MA-MPS, os

requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA).
O processo e o método de avaliação MA-MPS estão em conformidade com a Norma
Internacional ISO/IEC 15504-2 [ISO/IEC, 2003]. O Modelo de Negócio MN-MPS
descreve regras de negócio para implementação do MR-MPS pelas Instituições
Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA),
organização de grupos de empresas pelas Instituições Organizadoras de Grupos de
Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de
Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio
de cursos, provas e workshops. Um resumo executivo dessas regras de negócio está
disponível no Portal SOFTEX (www.softex.br/mpsbr/).

Base técnica para a definição do modelo MPS

ISO/IEC 12207:2008
A Norma Internacional ISO/IEC 12207 foi criada pela ISO – International Organization
for Standardization e o IEC - International Electrotechnical Commission dentro de um
esforço conjunto dessas organizações. Em 1988, foi proposto o desenvolvimento da norma
e em agosto de 1995 ela foi publicada como Norma Internacional. Em 1998, foi publicada a
sua versão brasileira que tem o mesmo nome que a internacional, somente acrescida das
iniciais NBR. Em outubro de 2002 e 2004, foram feitas atualizações na Norma
Internacional ISO/IEC 12207, chamadas de emendas 1 e 2 respectivamente, onde foram
inseridas diversas melhorias. Essas melhorias criaram novos ou expandiram o escopo de
alguns processos, inseriram para cada processo o seu propósito e resultados e para os novos
processos definiram suas atividades e tarefas. Essas modificações tiveram o objetivo de
representar a evolução da Engenharia de Software, as necessidades vivenciadas pelos
usuários da norma e a harmonização com a série ISO/IEC 15504. Em 2008, a Norma
Internacional ISO/IEC 12207 foi reformulada, incorporando as melhorias que já apareciam
nas emendas 1 e 2 e harmonizando sua estrutura à Norma Internacional ISO/IEC 15288. A
norma ISO/IEC 12207:2008 foi publicada também como padrão IEEE (IEEE Std
12207:2008) e estabelece uma arquitetura comum para o ciclo de vida de processos de
software com uma terminologia bem definida. Contém processos, atividades e tarefas a
serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação,
manutenção e descarte de produtos de software, bem como partes de software de um
sistema. A norma também se aplica à aquisição de sistemas, produtos de software e
serviços.
ISO/IEC 15504
Em setembro de 1992, a ISO realizou um estudo chamado “Necessidades e Exigências para
uma Norma de Avaliação de Processos de Software”. O trabalho concluiu que era
pertinente a elaboração de uma norma que fosse aplicável à melhoria de processos e à
determinação da capacidade. Este padrão deveria considerar os métodos e normas já
existentes (como por exemplo, o SW-CMM® e a MPS.BR-Guia Geral:2009 15/56 ISO
9001), abranger todos os processos de software e ser construído pelos especialistas que já
desenvolviam e trabalhavam com os métodos e normas existentes à época. Como resultado
desse primeiro trabalho, a ISO iniciou em janeiro de 1993 o projeto SPICE (Software
Process Improvement and Capability dEtermination) com o objetivo de produzir
inicialmente um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que
os modelos existentes e mais específico que a norma ISO 9001 originando, assim, a série de
normas ISO/IEC 15504: Parte 1 [ISO/IEC, 2004a], Parte 2 [ISO/IEC, 2003], Parte 3
[ISO/IEC, 2004b], Parte 4 [ISO/IEC, 2004c] e Parte 5 [ISO/IEC, 2006]. Posteriormente, em
2008, mais duas partes foram desenvolvidas: Parte 6 [ISO/IEC, 2008b] e Parte 7[ISO/IEC,
2008c]. A ISO/IEC 15504 presta-se à realização de avaliações de processos de software
com dois objetivos: a melhoria de processos e a determinação da capacidade de processos
de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade
organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos
que será usado para a elaboração de um plano de melhorias. A análise dos resultados
identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo
caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu
perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco
associado à contratação daquele fornecedor em potencial para auxiliar na tomada de
decisão de contratá-lo ou não.
CMMI-DEV®
O modelo SW-CMM® (Software Capability Maturity Model) foi definido no SEI
(Software Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos.
A partir de 1991, foram desenvolvidos CMMs® para várias disciplinas (Engenharia de
Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da
Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes
modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou
problemático. O CMMI® surgiu para resolver o problema de utilização de vários modelos e
é o resultado da evolução do SW-CMM®, SECM® (System Engineering Capability
Model) e IPD-CMM® (Integrated Product Development Capability Maturity Model). É,
portanto, o sucessor destes modelos. Além disso, o framework CMMISM foi desenvolvido
para ser consistente e compatível com a ISO/IEC 15504. Em 2006 foi publicada a versão
1.2 do CMMI®, o CMMI-DEV® (CMMI for Development) [SEI, 2006].

Descrição do MR-MPS
O Modelo de Referência MR-MPS define níveis de maturidade que são uma combinação
entre processos e sua capacidade.
A definição dos processos segue os requisitos para um modelo de referência de processo
apresentados na ISO/IEC 15504-2, declarando o propósito e os resultados esperados de sua
execução. Isso permite avaliar e atribuir graus de efetividade na execução dos processos.
As atividades e tarefas necessárias para atender ao MPS.BR-Guia Geral:2009 16/56
propósito e aos resultados esperados não são definidas neste guia, devendo ficar a cargo dos
usuários do MR-MPS. A capacidade do processo é a caracterização da habilidade do
processo para alcançar os objetivos de negócio, atuais e futuros; estando relacionada com o
atendimento aos atributos de processo associados aos processos de cada nível de
maturidade.
Níveis de maturidade
Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando
estágios de melhoria da implementação de processos na organização. O nível de maturidade
em que se encontra uma organização permite prever o seu desempenho futuro ao executar
um ou mais processos. O MR-MPS define sete níveis de maturidade: A (Em Otimização),
B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E
(Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de
maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de
maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar
o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do
MR-MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos
respectivos processos e os resultados esperados dos atributos de processo estabelecidos
para aquele nível. A divisão em 7 estágios tem o objetivo de possibilitar uma
implementação e avaliação adequada às micros, pequenas e médias empresas. A
possibilidade de se realizar avaliações considerando mais níveis também permite uma
visibilidade dos resultados de melhoria de processos em prazos mais curtos.
Processo
Os processos no MR-MPS são descritos em termos de propósito e resultados e estão
detalhados na seção 9. O propósito descreve o objetivo geral a ser atingido durante a
execução do processo. Os resultados esperados do processo estabelecem os resultados a
serem obtidos com a efetiva implementação do processo. Estes resultados podem ser
evidenciados por um produto de trabalho produzido ou uma mudança significativa de
estado ao se executar o processo.
Capacidade do processo
A capacidade do processo é representada por um conjunto de atributos de processo descrito
em termos de resultados esperados. A capacidade do processo expressa o grau de
refinamento e institucionalização com que o processo é executado na organização/unidade
organizacional. No MR-MPS, à medida que a organização/unidade organizacional evolui
nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve
ser atingido. MPS.BR-Guia Geral:2009 17/56
O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados
dos atributos do processo (RAP), é requerido para todos os processos no nível
correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada
processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui
o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para
todos os processos relacionados no nível de maturidade F (que também inclui os processos
de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de
maturidade G passam a ser executados no nível de capacidade correspondente ao nível F.
Em outras palavras, na passagem para um nível de maturidade superior, os processos
anteriormente implementados devem passar a ser executados no nível de capacidade
exigido neste nível superior. Os diferentes níveis de capacidade dos processos são descritos
por nove atributos de processo (AP). O alcance de cada atributo de processo é avaliado
utilizando os respectivos resultados esperados de atributo de processo (RAP).
AJAX

Asynchronous Javascript and XML - AJAX

AJAX não é um novo modelo para desenvolvimento web. Os navegadores implementam

essa tecnologia desde o ano 2000(no mínimo). Porém sua popularização nos últimos anos
tem também trazido consigo muitas outras melhorias para a Web. Tem estimulado a
construção de aplicações Web mais dinâmicas e criativas. AJAX não é uma tecnologia, mas
um conjunto de tecnologias conhecidas trabalhando juntas, cada uma fazendo sua parte,
oferecendo novas funcionalidades. AJAX incorpora em seu modelo:

• Exposição e interação dinâmica usando o DOM;

• Intercâmbio e manipulação de dados usando XML e XSLT;
• Recuperação assíncrona de dados usando o objeto XMLHttpRequest e
XMLHttpResponse;
• JavaScript fazendo a junção entre os elementos.

O modelo clássico de aplicação web trabalha assim: a maioria das ações do usuário na
interface dispara uma solicitação HTTP para o servidor web. O servidor processa algo,
recuperando dados, realizando cálculos, conversando com vários sistemas legados, e então
retorna uma página HTML para o cliente. É um modelo adaptado do uso original da Web
como um agente de hipertexto, porém o que faz a web boa para hipertexto não
necessariamente a faz boa para aplicações de software.

Com a popularização de sistemas que funcionam inteiramente na Web e também com o

aumento da velocidade das conexões banda larga, o problema da espera pelo envio e
retorno da página inteira se tornou muito mais evidente para o usuário. Obviamente, se nós
estivéssemos projetando a Web a partir do zero para aplicações, não faríamos com que os
usuários esperassem em vão. Uma vez que a interface está carregada, por que a interação
do usuário deveria parar a cada vez que a aplicação precisasse de algo do servidor? Na
realidade, por que o usuário deveria ver a aplicação ir ao servidor toda vez?

As principais vantagem das aplicações que utilizam AJAX para determinadas requisições é
que os dados trafegados pela rede são reduzidos e o usuário não precisa aguardar a página
ser recarregada a cada interação com o servidor.

A popularização das tecnologias que o AJAX reúne, foi muito importante para a criação do
conceito Web 2.0, que até hoje gera grandes divisões entre os maiores pensadores da Web.

Apesar de não possuir nada inovador em sua essência, o uso de AJAX revolucionou a Web
inteira trazendo a tona muitos conceitos importantes para o desenvolvimento web.
Os quatro princípios de Ajax

• O navegador hospeda uma aplicação, e não conteúdo

• O servidor fornece dados, e não conteúdo

• A interação do utilizador com a aplicação pode ser flexível e contínua

• Real codificação requer disciplina

XML

eXtensible Markup Language

• Linguagem de representação usando marcas como o HTML Marcas não pré-definidas.
Precisam de ser definidas
• XML usa DTD ou esquemas para definir os dados
• Não FAZ NADA ! (Não executa)
•XML Versus HTML:
• XML é uma Linguagem de representação de Dados e foca o que são esses dados
• HTML é uma Linguagem para visualizar Dados e foca em como se visualizam os dados
VER SLIDES

TDD:

Test Driven Development (TDD) ou em português Desenvolvimento

dirigido por testes é uma técnica de desenvolvimento de
software que basea em um ciclo curto de repetições:
Primeiramente o desenvolvedor escreve um caso de teste
automatizado que define uma melhoria desejada ou uma nova
funcionalidade. Então, é produzido código que possa ser
validado pelo teste para posteriormente o código ser
refatorado para um código sob padrões aceitáveis. Kenk Beck,
considerado o criador ou o 'descobridor' da técnica,
estatificou em 2003 que TDD encouraja designs de código
simples e inspira confiança[1]. Desenvolvimetnto dirigido por
testes é relacionado a conceitos de programação de Extreme
Programming, iniciado em 1999,[2] mas recentemente tem-se
criado maior interesse pela mesma em função de seus próprios
ideais.[3] Através de TDD, programadores podem aplicar o
conceito de melhorar e depurar código legado desenvolvido
apartir de técnicas antigas.[4]

1. Adicione um teste

Em Test Driven Development, cada nova funcionalidade inicia com a criação de um teste.
Este teste precisa inevitávelmente falhar porque ele é escrito antes da funcionalidade a ser
implementada (se ele não falha, então a funcionalidade ou melhoria 'proposta' é óbvia).
Para escrever um teste, o desenvolvedor precisa claramente entender as especificações e
requisitos da funcionalidade. O desenvolvedor pode fazer isso através de casos de uso ou
user stories que cubram os requisitos e execções condicionais. Esta é a diferenciação entre
desenvolvimento dirigido a testes entre escrever testes de unidade 'depois' do código
desenvolvido. Ele torna o desenvolvedor focado nos requisitos 'antes' do código, que é uma
sutil mas importante diferença.

[editar] 2. Execute todos os testes e veja se algum deles falha

Esse passo valida se todos os testes estão funcionando corretamente e se o novo teste não
traz nenhum equívoco, sem requerer nenhum código novo. Pode-se considerar que este
passo então testa o próprio teste: ele regula a possibilidade de novo teste passar.

O novo teste deve então falhar pela razão esperada: a funcionalidade não foi desenvolvida.
Isto aumenta a confiança (por outro lado não exatamenta a garante) que se está testando a
coisa certa, e que o teste somente irá passar nos casos intencionados.

[editar] 3. Escrever código

O próximo passo é escrever código que irá ocasionar ao teste passar. O novo código escrito
até esse ponto poderá não ser perfeito e pode, por exemplo, passar no teste de uma forma
não elegante. Isso é aceitável porque posteriormente ele será melhorado.

O importante é que o código escrito deve ser construído somente para passar no teste;
nenhuma funcionalidade (muito menos não testada) deve ser predita ou permitida em
qualquer ponto.

[editar] 4. Execute os testes automatizados e veja-os executarem com sucesso

Se todos os testes passam agora, o programador pode ficar confiante de que o código possui
todos os requisitos testados. Este é um bom ponto que inicia o passo final do ciclo TDD.

[editar] 5. Refatorar código

Nesse ponto o código pode ser limpo como necessário. Ao re-executar os testes, o
desenvolvedor pode confiar que a refatoração não é um processo danoso a qualquer
funcionalidade existente. Um conceito relevante nesse momento é o de remoção de
duplicação de código, considerado um importante aspecto ao design de um software. Nesse
caso, entretanto, isso aplica remover qualquer duplicação entre código de teste e código de
produção — por exemplo magic numbers or strings que nós repetimos nos testes e no
código de produção, de forma que faça o teste passar no passo 3.

[editar] 6. Repita tudo

Iniciando com outro teste, o ciclo é então repetido, enpurrando a funcionalidade a frente. O
tamanho dos passos deve ser pequeno - tão quanto de 1 a 10 edições de texto entre cada
execução de testes. Se novo código não satisfaz rapidamente um novo teste, ou outros testes
falham inesperadademente, o programador deve desfazer ou reverter as alterações ao invés
do uso de excessiva depuração. A Integração contínua ajuda a prover pontos revertíveis. É
importante lembrar que ao usar bibliotecas externas não é interessante gerar incrementos
tão pequenos que possam efetivamente testar a biblioteca ,[3] a menos que haja alguma
razão para acreditar que a biblioteca tenha defeitos ou não seja suficientemte completada
com suas funcionalidades de forma a servir às necessidades do programa em que está sendo
escrito.

[editar] Estilos de Desenvolvimento

Há vários aspectos ao usar desenvolvimento dirigido a testes, por exemplo os princípios

"Keep It Simple, Stupid" (KISS) e "You Ain`t Gonna Need It" (YAGNI). Focando em
escrever código somente para os testes passarem, o design do sistema pode ser mais limpo e
claro do que o que é alcançado por outros métodos.[1] Em Test-Driven Developmente By
Example Kent Beck sugere o princípio "Fake it, till you make it". Para alcançar altos níveis
conceituais de design (como o uso de Design Pattern), tests são escritos de forma que
possam gerar o design. O código pode acabar permanecendo mais simples do que o padrão
alvo, entretanto ele deve passar em todos os testes requeridos. Isto pode ser inaceitável de
primeira mas ele permite o desenvolvedor focar somente no que é importante.

Falhar primeiro os casos de testes. A idéia é garantir que o teste realmente funciona e
consegue capturar um erro. Assim que ele é mostrado, a funcionalidade almejada pode ser
implementada. Isto tem sido apontado como o "Test-Driven Mantra", conhecido como
vermelho/verde/refatorar onde vermelho significa falhar onde pelo menos uma asserção
falha ,e verde é passar, que significa que todas as asserções foram verdadeiras.

Desenvolvimento dirigido a testes constantemente repete os passos de adicionar casos de

teste que falham, passando e refatorando-os. Ao receber o resultado esperado em cada
estágio reforça ao desenvolvedor o modelo mental do código, aumentando a confiança e
incrementando a produtividade.

Práticas avançadas de desenvolvimento dirigido a testes encaminham para o

desenvolvimento dirigido a testes de aceitação (ATDD), onde o critério especificado pelo
cliente é automatizado em testes de aceitação, que então levam ao tradicional processo de
desenvolvimento dirigido a testes de unidade. Este processo garante que o cliente tem um
mecanismo automatizado para decidir como o software atende suas necessidades. Com
ATDD, o desenvolvimento em equipe tem objetivo específico para satisfazer, e os testes de
aceitação os mantém contínuamente focados em o que o cliente realmente deseja daquela
funcionalidade.

ISO 27002-2005

Ver Slides
DDL e DML

Linguagem de manipulação de dados (ou DML, de Data

Manipulation Language) é uma família de linguagens de
computador utilizadas para a recuperação, inclusão, remoção e
modificação de informações em bancos de dados. Pode ser
procedural, que especifica como os dados devem ser obtidos do
banco; pode também ser declarativa (não procedural), em que
os usuários não necessitam especificar o caminho de acesso,
isto é, como os dados serão obtidos. O padrão SQL é não
procedural. DMLs foram utilizadas inicialmente apenas por
programas de computador, porém (com o surgimento da SQL)
também têm sido utilizadas por pessoas.

Linguagem de definição de dados (LDD ou DDL, do Inglês Data

Definition Language) é uma linguagem de computador usada para
a definição de estruturas de dados. O termo foi inicialmente
introduzido em relação ao modelo de banco de dados Codasyl,
onde o esquema de banco de dados era escrito em uma Linguagem
de Definição de Dados descrevendo os registros, campos e
"conjuntos" que consituíam o Modelo de dados do usuário.
Inicialmente referia-se a um subconjunto da SQL, mas hoje é
usada em um sentido genérico para referir-se a qualquer
linguagem formal para descrição de estruturas de dados ou
informação, assim como esquemas XML.

Uma vez compilados, os parâmetros DDL são armazenados num conjunto de arquivos
denominado dicionário de dados (ou catálogo). O dicionário de dados contém os metadados
(dados a respeito das estruturas de armazenamento). O SGBD sempre consulta os
metadados a cada operação sobre o banco de dados. Por exemplo, um determinado
programa precisa recuperar alguns campos (nome, CPF) de um arquivo de clientes. O
SGBD irá verificar se os campos "nome" e "CPF" estão definidos para este arquivo. O
interpretador DDL processa os comandos alimentados pelos DBAs na definição dos
esquemas.

Gatilhos DDL e DML são usados com finalidades diferentes:

• Gatilhos DML operam em instruções INSERT, UPDATE e DELETE e ajudam a

impor regras de negócio e integridade de dados estendida, quando os dados são
modificados em tabelas ou exibições.
• Gatilhos DDL operam em instruções CREATE, ALTER, DROP e outras instruções
DDL e procedimentos armazenados que executam operações similares a DDL. São
usados para executar tarefas administrativas e impor regras de negócio que afetam
bancos de dados. Aplicam-se a todos os comandos de um mesmo tipo em todo o
banco de dados ou servidor.
SUPORTE À DECISÃO

DATA WAREHOUSE

Um data warehouse (ou armazém de dados, ou depósito de dados no

Brasil) é um sistema de computação utilizado para armazenar
informações relativas às atividades de uma organização em bancos
de dados, de forma consolidada. O desenho da base de dados
favorece os relatórios, a análise de grandes volumes de dados e a
obtenção de informações estratégicas que podem facilitar a tomada
de decisão.

O data warehouse possibilita a análise de grandes volumes de

dados, coletados dos sistemas transacionais (OLTP). São as
chamadas séries históricas que possibilitam uma melhor análise de
eventos passados, oferecendo suporte às tomadas de decisões
presentes e a previsão de eventos futuros.

Por definição, os dados em um data warehouse não são voláteis, ou

seja, eles não mudam, salvo quando é necessário fazer correções de
dados previamente carregados. Os dados estão disponíveis somente
para leitura e não podem ser alterados.

A ferramenta mais popular para exploração de um data warehouse é a Online Analytical Processing
OLAP ou Processo Analítico em Tempo Real, mas muitas outras podem ser usadas.

Os data warehouse surgiram como conceito acadêmico na década de 80. Com o amadurecimento
dos sistemas de informação empresariais, as necessidades de análise dos dados cresceram
paralelamente. Os sistemas OLTP não conseguiam cumprir a tarefa de análise com a simples
geração de relatórios. Nesse contexto, a implementação do data warehouse passou a se tornar
realidade nas grandes corporações. O mercado de ferramentas de data warehouse, que faz parte do
mercado de Business Intelligence, cresceu então, e ferramentas melhores e mais sofisticadas foram
desenvolvidas para apoiar a estrutura do data warehouse e sua utilização.

Atualmente, por sua capacidade de sumarizar e analisar grandes volumes de dados,o data
warehouse é o núcleo dos sistemas de informações gerenciais e apoio à decisão das principais
soluções de business intelligence do mercado.

Ferramentas OLAP

OLAP (On-Line Analytical Processing) representa um conjunto de tecnologias projetadas para

suportar análise e consultas ad hoc. Sistemas OLAP ajudam analistas e executivos a sintetizarem
informações sobre a empresa, através de comparações, visões personalizadas, análise histórica e
projeção de dados em vários cenários de "e se...". Sistemas OLAP são implementados para
ambientes multi-usuário, arquitetura cliente-servidor e oferece respostas rápidas e consistentes às
consultas iterativas executadas pelos analistas, independente do tamanho e complexidade do banco
de dados.
A característica principal dos sistemas OLAP é permitir uma visão conceitual multidimensional dos
dados de uma empresa. A visão multidimensional é muito mais útil para os analistas do que a
tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela é mais natural,
fácil e intuitiva, permitindo a visão em diferentes perspectivas dos negócios da empresa e desta
maneira tornando o analista um explorador da informação.

Uma arquitetura OLAP possui três componentes principais: um modelo de negócios para análises
interativas, implementado numa linguagem gráfica que permita diversas visões e níveis de detalhes
dos dados; um motor OLAP para processar consultas multidimensionais contra o dado-alvo; e um
mecanismo para armazenar os dados a serem analisados. A base de dados usada define se o pacote é
um ROLAP, que interfaceia com um banco de dados relacional de mercado, ou um MOLAP, que se
liga a um servidor OLAP, através de um banco de dados multidimensional e dedicado.

Hybrid On Line Analytical Processing - HOLAP deriva-se de OLAP, são ferramentas hibridas.

É a combinação entre ROLAP e MOLAP, pegando o melhor de ambas as categorias a

escalabilidade de ROLAP e o alto desempenho do MOLAP

Multidimensional On Line Analytical Processing - MOLAP deriva-se de OLAP, são ferramentas

que disparam suas requisições diretamente ao servidor de Banco de Dados multidimensional. Após
o envio da requisição o usuário continua manipulando os dados diretamente no servidor, tendo um
ganho no desempenho.

BUSINESS INTELLIGENCE (BI)

O termo Business Intelligence (BI), pode ser traduzido como Inteligência de negócios, refere-se
ao processo de coleta, organização, análise, compartilhamento e monitoramento de informações que
oferecem suporte a gestão de negócios.

A Inteligência Empresarial, ou Business Intelligence, é um termo do Gartner Group. O conceito

surgiu na década de 80 e descreve as habilidades das corporações para aceder a dados e explorar
informações (normalmente contidas em um Data Warehouse/Data Mart), analisando-as e
desenvolvendo percepções e entendimentos a seu respeito, o que lhes permite incrementar e tornar
mais pautada em informações a tomada de decisão (JFF).

As organizações tipicamente recolhem informações com a finalidade de avaliar o ambiente

empresarial, completando estas informações com pesquisas de marketing, industriais e de mercado,
além de análises competitivas. Organizações competitivas acumulam "inteligência" à medida que
ganham sustentação na sua vantagem competitiva, podendo considerar tal inteligência como o
aspecto central para competir em alguns mercados.

Geralmente, os coletores de BI obtêm as fontes primárias de informação dentro das suas empresas.
Cada fonte ajuda quem tem que decidir a entender como o poderá fazer da forma mais correta
possível. As fontes secundárias de informações incluem as necessidades do consumidor, processo
de decisão do cliente, pressões competitivas, condições industriais relevantes, aspectos econômicos
e tecnológicos e tendências culturais.
Cada sistema de BI determina uma meta específica, tendo por base o objetivo organizacional ou a
visão da empresa, existindo em ambos objetivos, sejam eles de longo ou curto prazo.

Business Intelligence (BI) pode ser traduzido como inteligência de negócios, ou inteligência
empresarial. Isto significa que é um método que visa ajudar as empresas a tomar as decisões
inteligentes, mediante dados e informações recolhidas pelos diversos sistemas de informação.
Sendo assim, BI é uma tecnologia que permite às empresas transformar dados guardados nos seus
sistemas em Informação qualitativa e importante para a tomada de decisão. Há uma forte tendência
de que os produtos que compõem o sistema de BI de uma empresa passem, isoladamente, a prover
funções extras que auxiliem na tomada de decisões. Por exemplo, todos os sistemas que funcionam
numa perspectiva de organização da informação. Sendo assim temos: ERP – Enterprise Resource
Planning; CRM – Customer Relationship Manager. Segundo Brent Frei, fundador da Onyx
Software, “Customer Relationship Management (CRM) é um conjunto de processos e tecnologias
que gerem relacionamentos com clientes efectivos e potenciais e com parceiros de negócios através
do marketing, das vendas e dos serviços, independentemente do canal de comunicação”. Ou seja,
pode ser considerado como uma estratégia de gestão de negócios através da gestão dos
relacionamentos com os clientes tendo em consideração o aumento do lucro e das vendas da
empresa. O objetivo principal é claramente uniformizar processos que permitam o acesso à
informação como forma de melhorar os negócios e o Marketing Relacional da empresa através do
uso da tecnologia. A globalização e a evolução da TI têm mudado radicalmente a forma como as
empresas e os seus consumidores se relacionam. Os consumidores têm um leque de opções de
produtos e serviços que há alguns anos não era possível. As TI permitem oferecer qualidade a um
preço competitivo daí o CRM ser fundamental no estabelecimento das relações e na fidelização dos
clientes. Hoje, é importante rentabilizar a máxima LTV (Lifetime Value) de cada cliente.

Podemos classificar da seguinte forma os clientes:

1. CMV (CLIENTES MAIS VALIOSOS) para os quais devemos utilizar uma estratégia de
retenção, trabalhando em programas de reconhecimento e na possibilidade de uso de canais de
comunicação exclusivos recompensando a preferência dos clientes e o volume de negócios por eles
submetido na nossa empresa;

2. CMP (CLIENTES MAIOR POTENCIAL) para os quais é necessário desenvolver esses clientes
através de incentivos. O importante é transformar estes clientes em CMV. Encontrar estratégias
para os “habituar” a trabalhar com os nossos produtos;

3. BZ (BELOW ZERO) que representam valor negativo para a organização;

4. CLIENTES INTERMÉDIOS mas que são lucrativos, porém sem grande expressão . O potencial
de uma ferramenta de CRM revela-se na esquematização dos diversos dados disponíveis de forma a
criar informação valiosa para utilizar-se em prol da empresa e das suas relações comerciais.
Teremos uma informação com maior qualidade, fundamental para a tomada de decisão e para a
gestão dos clientes. Portanto para uma organização, os benefícios com a implementação de um
CRM passa muito pelo valor que vai criar na empresa. Irá facilitar não só a identificação dos
clientes – criando bases de informações relativas aos clientes de acordo com o seu perfil – como irá
facilitar a segmentação dos mesmos contribuindo para o desenvolvimento dos diversos processos de
fidelização/retenção de clientes.
ETL

ETL, do inglês Extract Transform Load (Extração Transformação Carga), são

ferramentas de software cuja função é a extração de dados de diversos sistemas,
transformação desses dados conforme regras de negócios e por fim a carga dos dados em
um data mart ou um data warehouse. É considerada uma das fases mais críticas do Data
Warehouse e/ou Data Mart.

Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria dessas

fontes tendem a ser bancos de dados relacionais ou flat files (texto plano), mas podem
existir outras fontes. Um sistema ETL tem que ser capaz de se comunicar com as bases de
dados e ler diversos formatos de arquivos utilizados por toda a organização. Essa pode ser
uma tarefa não trivial, e muitas fontes de dados podem não ser acessadas muito facilmente.

MODELAGEM MULTIDIMENSIONAL

Ver Slides

Modelos de Dados Multidimensionais

A natureza do uso de bancos de dados multidimensionais torna sua modelagem distinta

daquela utilizada para sistemas transacionais. Neste último aplicamos técnicas de
normalização seguidas por graus de desnormalização a fim de obter o desempenho desejado
ao reduzir o número de tabelas em junções (joins).

Vale lembrar que o número de planos de execução para uma junção de n tabelas é n!, isto é,
para uma junção de 10 tabelas há 3.628.800 possibilidades. Embora o escalonador do
SGBD possua estratégias para reduzir este número, é um ponto de atenção a considerar. Já
para o caso dos MDDBs, o grau de desnormalização é bem maior, dado o volume de dados
e a agilidade na consolidação de valores quando calculando as agregações.

Nesta seção, com trechos extraídos de (4) e (5), percorremos alguns conceitos importantes
para a modelagem quanto à representação de fatos, dimensões e quanto a chaves. Então
descrevemos vários modelos de dados, sempre do ponto de vista lógico. Portanto, os
modelos que veremos serão sempre relacionais, independentemente do alicerce, relacional
ou em cubos, que pode ser utilizado para o modelo físico.

Inicio da pagina

Alguns Conceitos

Quando o modelo de dados começa a ser definido, elementos básicos de representação

precisam ter sido estabelecidos, de modo a criar-se um padrão de modelagem. Em nosso
modelo teremos as dimensões e fatos representados em tabelas, podendo haver múltiplas
dimensões e múltiplas tabelas de fatos.

Fatos

Ao modelar a(s) tabela(s) de fatos (ou apenas tabela fato), deve-se ter em mente os
seguintes pontos:

• A chave primária é composta, sendo um elemento da chave para cada dimensão;

• Cada elemento chave para a dimensão deve ser representado e descrito na “tabela
dimensão” correspondente (para efetuar a junção);
• A dimensão tempo é sempre representada como parte da chave primária.

Dimensões

Deve haver uma “tabela dimensão” para cada dimensão do modelo, contendo:

• Uma chave artificial (ou gerada) genérica;

• Uma coluna de descrição genérica para a dimensão;
• Colunas que permitam efetuar os filtros;
• Um indicador NÍVEL que indica o nível da hierarquia a que se refere a linha da
tabela.
A Dimensão Tempo

Esta é uma dimensão que praticamente todos os sistemas analíticos possuem, dada a
característica de realização de análises em dados históricos. Deveria conter:

• Uma coluna chave para a junção com a(s) tabela(s) de fato(s);

• Uma descrição genérica para cada período;
• Colunas que permitam efetuar os filtros;
• Coluna sinalizadora da presença de fatos para o período de tempo indicado na linha;
• Coluna RESOLUÇÃO usada para restringir o período ao nível apropriado - opera
de forma idêntica à coluna NÍVEL das outras dimensões
• Coluna SEQÜÊNCIA que contém um número seqüencial de 1 a n em cada nível do
período de tempo e identifica a ordem relativa de cada data. Permite:
o Coluna SEQÜÊNCIA que contém um número seqüencial de 1 a n em cada
nível do período de tempo e identifica a ordem relativa de cada data.
Permite:
o Construções com cálculos de tempo, como “últimos quatro dias”, por
exemplo.

A Figura 10 mostra um exemplo de tabela de dimensão tempo. Note que a descrição é o

que aparecerá para os valores de uma determinada data ou período.

Estrela e suas Variações

Uma das formas de apresentação de um banco de dados multidimensional é através do

Modelo Estrela, apresentado por Ralph Kimball (4). No centro da estrela encontra-se a
tabela de fatos e, ao seu redor, as dimensões. Este modelo é apresentado na Figura 11: