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 C obit (Control Objectives for Information and Related Technology) Tech nology) e do ITIL (Information Technology Infrastruture Library) como base para pa ra 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
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 C obit (Control Objectives for Information and Related Technology) Tech nology) e do ITIL (Information Technology Infrastruture Library) como base para pa ra 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 T I 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. 2. 3. 4. 5. 6. 7.
Orientar e Gerenciar a Execução do Projeto; Realizar a garantia da qualidade; Contratar ou Mobilizar a Equipe do Projeto; Desenvolver a equipe do projeto; Distribuir as informações; Solicitar respostas de fornecedores; 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.
contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém as O Modelo de Referência MR-MPS
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 Mo del) 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 ) é uma família de linguagens de Manipulation Language 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: 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: Construções com cálculos de tempo, como “últimos quatro dias”, por exemplo. o
o
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:
