Total de visualizações de página

terça-feira, 21 de janeiro de 2014

Maturidade em dados-DMM-Data Maturity Model-Parte-VIII

DMM e DMBOK

O DMBOK é uma proposta de framework de Gestão de dados desenvolvido pela DAMA-Data Management Association. É composto  por uma coleção de áreas de conhecimentos focados  na prática de Gestão de dados.  Para maiores detalhes, acesse http://www.fumsoft.org.br/comunica/arquivos/uma_visao_sintetica_e_comentada_do_dmbok_fumsoft_carlos_barbieri.pdf 
Os processos da categoria Estratégia de GD do DMM estão fortemente associados com o corpo de conhecimento chamado de Governança de Dados do DMBOK. Esse corpo de conhecimento do DMBOK trata justamente desses aspectos de definições prévias e também dos mecanismos de controle e acompanhamento, ou seja  Planejamento e Controle da Gestão de Dados. Observe abaixo alguns pontos de alinhamentos entre “o quê” do DMM e o “como” do DMBOK, lembrando-se que são níveis diferentes de observação, com os elementos do DMM mostrados entre parênteses ( ).
Planejamento da gestão de dados

        Entender as necessidades estratégicas de dados da empresa(Objetivos)
        Desenvolver e manter uma estratégia de dados (Estratégia)
        Estabelecer unidades organizacionais e papéis voltadas para dados (Estrutura de GD), (Modelo Organizacional)
        Identificar os Data Stewards (Estrutura de GD), (Modelo Organizacional)
        Estabelecer as camadas de GD e de data stewards (Estrutura de GD), (Modelo Organizacional)
        Desenvolver e aprovar Políticas, Padrões e Procedimentos de dados  (Definição de Requisitos de dados)(Gerência de ciclo de vida)
        Revisar e aprovar a Arquitetura de Dados (Definição de Requisitos de dados)(Gerência de ciclo de vida)
        Planejar e patrocinar Projetos e Serviços de Gestão de Dados (TCO,BC,Modelo de Funding)
        Estimar o valor dos Ativos de Dados e custos associados(Riscos) (TCO,BC,Modelo de Funding)

Controle da gestão de dados :

        Supervisionar as camadas/estruturas e papéis envolvidos com dados (Supervisão)
        Coordenar as atividades de Governança de Dados; (Supervisão) (Implementação da GD)
        Gerenciar e resolver “conflitos” sobre dados (Implementação da GD)
        Monitorar e garantir aderência a aspectos regulatórios(no que tange a dados) (Supervisão) (Implementação da GD)
        Monitorar e garantir a aplicação e conformidade às Políticas, Padrões Procedimentos e Arquitetura (Supervisão)
        Supervisionar projetos e serviços relativos à Gerência de Dados (Supervisão)
        Comunicar e promover os valores dos ativos de dados (Comunicação)


A figura DMM-09 mostra uma correlação “overview”  entre os corpos de conhecimento do DMBOK com as categorias do DMM.

 Figura DMM-09- Correlação entre os corpos de conhecimento do DMBOK(Dama), versão 1 com as categorias do DMM(CMMI)

O modelo DMBOK apresentado acima está na versão 2009. Já existe um “draft”  da nova versão(versão 2), que contém as seguintes modificações: Inclusão do novo corpo de conhecimento(área) denominada Integração e interoperabilidade de dados. Também foram modificados o nome de dois processos : O de Development(Desenvolvimento de dados) passa a se chamar Data Modeling & Design(Modelagem e Projeto de dados). O de Data Operations(Operações de dados) passa a ser chamada Data Storage & Operations(Armazenamento e Operações de dados).  Os processos passam a ser denominados  Áreas de conhecimentos e conterão um contexto composto de:
Definição, Objetivos com drivers de negócios, Processos com atividades(de planejamento, de controle,de desenvolvimento e operacionais) e subatividades,Entradas, Papéis de supridores, Papéis de responsáveis, Papéis de stakeholders, Papéis de consumidores, Ferramentas, Entregáveis e Métricas. As áreas de conhecimento poderão ser divididas em Secções.
A figura DMM-10 ,mostra com um pouco mais de detalhamento, as correlações aproximadas entre as PA´s do DMM e os corpos de conhecimento do DMBOK, versão 2. Observar que essas correlações entre os dois modelos deve ser analisada com cuidado pois envolve alinhar uma proposição de What(O Quê), com uma possível de How(Como). 



Figura DMM-10- Correlação entre os corpos de conhecimento do DMBOK(Dama), versão 2 com as áreas de processos do DMM(CMMI)

Maturidade em dados-DMM-Data Maturity Model-Parte VII


Processos de Apoio:

Ao analisarmos o modelo DMM observa-se que há um conjunto de processos de apoio, não detalhados no “draft” do trabalho. Esses processos existem no CMMI e MPS.BR e tem como objetivo apoiar os processos “core”, discutidos anteriormente, nos seus objetivos finais. Conforme veremos abaixo, os processos de apoio do CMMI-DEV podem ser perfeitamente aplicados no mundo dos Dados, embora tenham sido originalmente definidos para Processos. Pela generalização do “What” e evitando o detalhamento do  “How”, os processos de maturidade podem sofrer leituras variadas e serem adotados, bastando pensar um pouco nos novos domínios onde se deseja a sua contextualização. Isso é o que eu imagino será considerado no release final do DMM, previsto para 2014. Vejamos a forma pura com que o Modelo CMMI-DEV trata esses processos de apoio, nas tabelas a seguir. Há os chamados SG(Specific goals, ou objetivos específicos), divididos em SP(Specific Pratices, práticas específicas). No fundo representam os resultados  que se espera alcançar com a aplicação daquele processo em particular. Devido a similaridade do CMMI com o MPS.BR, focaremos nas discussões dos resultados esperados pelo modelo do SEI.
Os processos de suporte/apoio apresentados na figura DMM-04 são, conforme o CMMI-DEV 1.3:

REQM-Gerência de Requisitos-CMMI

Objetivos Específicos
Práticas específicas
Considerações
SG1-Gerenciar os Requisitos



SP1.1-Entender os Requisitos
Entendimento junto ao Fornecedor de Requisitos de dados

SP1.2-Obter comprometimento com os Requisitos
Obtenção do comprometimento junto à equipe técnica

SP1.3-Gerenciar alterações de Requisitos
Alterações de requisitos de dados  com a análise impacto

SP1.4- Manter a rastreabilidade bidirecional dos Requisitos
Rastreabilidade bidirecional, Horizontal e vertical de requisitos de dados

SP1.5-Garantir alinhamento entre Produtos de trabalho e os Requisitos
Integridade dos produtos de trabalhos que documentam e registram requisitos de dados, preservada nas alterações de requisitos

CM-Gerência de Configuração-CMMI

Objetivos Específicos
Práticas específicas
Considerações
SG1-Definir Baselines



SP1.1-Identificar Itens de Configuração
Itens de Configuração de domínio de dados: modelos, scripts, Bancos de dados, etc

SP1.2-Estabelecer um sistema de Gerência de Configuração
Sem variação com relação ao CMMI-DEV

SP1.3-Criar/Liberar as Baselines
Controlar os IC de dados em Baselines
SG2-Rastrear e Controlar Alterações



SP2.1-Rastrear as solicitações de alterações
Registrar e analisar alterações de IC de dados

SP2.2-Controlar Itens de Configuração
Controlar os impactos das alterações em dados
SG3-Garantir Integridade



SP3.1-Estabelecer registros de gerência de configuração
Sem variação

SP3.2-Realizar auditoria de configuração
Variação nos check-lists de auditoria, onde prevalecerão IC do domínio de dados

 RSKM-Gerência de Riscos-CMMI

Objetivos Específicos
Práticas específicas
Considerações
SG1-Preparar para Gerência de Risco



SP1.1-Determinar fontes e categorias de riscos
Variação com relação aos tipos e categorias de riscos incidentes no domínio dos dados

SP1.2-Definir parâmetros de risco
Variante com relação aos aspectos de problemas de dados: reputação, erros de cálculos, aspectos de normas e regulação

SP1.3-Estabelecer estratégia de gerência de risco
Idem
SG2-Identificar e analisar riscos



SP2.1-Identificar riscos
Controle de riscos de dados nos pontos de origem: entrada de dados, camadas de transformação, visualização

SP2.2-Avaliar, categorizar e priorizar riscos
Idem
SG3-Mitigar riscos



SP3.1-Desenvolver plano de mitigação de riscos


SP3.2-Implementar plano de mitigação de risco



MA-Medições e Análise-CMMI

Objetivos Específicos
Práticas específicas
Considerações
SG1-Alinhar atividades de medição e análise



SP1.1-Estabelecer objetivos de medições
Em consonância com diversas Categorias/componentes e PA´s do DMM: Estratégia, Medições(11), Análise e Medição(33) 

SP1.2-Definir medidas
De acordo com os objetivos da GD

SP1.3-Especificar procedimentos de Coleta e Armazenamento
Sem variação

SP1.4-Especificar procedimentos de análise
De acordo com objetivos da GD
SG2-Prover os resultados de medições



SP2.1-Obter os dados de medições
Sem variação, atentando para os pontos e momentos de coleta, no ciclo de vida dos dados

SP2.2-Analisar os dados de medições
Avaliação dos envolvidos em GD: Comitê, CDO,Data stewards,

SP2.3-Armazenar dados e resultados
Sem variação

SP2.4-Comunicar resultados


Considerações sobre os processos de apoio do CMMI aplicados aos dados:
No caso de processos de apoio, aplicados à Gestão Estratégica de dados, mudaríamos alguns elementos classicamente considerados no CMMI/MPS.BR para o encaixe no mundo dos dados. Alguns processos de apoio como MA(Medições e Análise), CM(Gerência de configuração) e RSKM(Gerência de Riscos) são mais óbvios de se adaptar, bastando pensar no novo contexto de dados no lugar de processos. Medições de erros de  atributos nos dados(precisão, integridade,etc), medições de problemas de dados relacionados a aspectos regulatórios, medições de divergência nos metadados,etc. Os aspectos de Configuração também são de correlação direta. A parte a ser modificada  será o foco no conjunto de Itens de Configuração definido nos projetos, com  maior prevalência para aqueles relacionados com dados(modelos conceituais, lógicos e físicos), scripts de Bancos de dados, o próprio Banco de dados, o catálogo de metadados,etc. A parte de Gerência de Risco também não representa dificuldades. A classificação dos riscos e seus parâmetros como Probabilidade e Impacto de incidência será pensada com relação aos dados. Riscos de  dados impactarem aspectos de regulação (Aneel,BV,Anvisa,Banco Centraletc), riscos de data flaws na reputação da empresa, riscos de cálculos errados por transformações indevidas de dados,etc. Os aspectos relacionados a Gerência de Requisitos, aplicados aos dados também não oferece grandes desafios, embora  seja menos linear. Os conceitos de Fornecedores de Requisitos, os conceitos de rastreabilidade de requisitos agora serão transpostos para dados. Os fornecedores de requisitos de dados em um projeto tradicional, via SDLC(System development Lyfe Cycle) são os mesmo que fornecem os outros tipos de requisitos, como os funcionais e não funcionais. O detalhe aqui é que a necessidade de dados é manifestada como requisito e deverá ser analisada à luz de sua já existência em Bancos de dados, ou ERP existentes. A sua pertinência será observada com relação a sua classificação. Por exemplo, dados mestres deverão ser oferecidos aos fornecedores de requisitos, via estratégia de mensageria ou serviços, caso possam ser utilizados diretamente. Dados de referência deverão ser analisados também com relação à sua já existência. Aqui a necessidade de requisitos de dados envolve a sua existência(o dado existente é o que eu necessito?), a sua pertinência(o dado que existe esta na forma que eu preciso?). Processos de controles de modelos de dados em nível conceitual, lógico e físico serão elementos chaves nesta PA de Requisitos. Além disso, redundâncias, autorizações de uso, definição de especializações, etc aparecerão também aqui.  A rastreabilidade deverá se preocupar com a análise de impacto que alterações em dados proporcionarão. Por exemplo, a alteração de um layout de BD, modificação de um dado, modificações de dados de uma interface, mudanças em  entidades num modelo conceitual, etc podem ser registrados e  trabalhados como requisitos de dados com certa coerência com o GRE do CMMI.
Os modelos de maturidade como CMMI e MPS.BR também contemplam resultados genéricos, válidos para todos os processos. Esses resultados genéricos podem ser entendidos, conforme a tabela abaixo e estão mapeados com algumas PA´s vistas anteriormente:

GG1-Objetivos genéricos
Práticas genéricas
Considerações
GG1-Alcança objetivos genéricos



GP1.1-Realizar as práticas específicas
O alcance de cada um dos 37 processos do DMM
GG2-Institucionaliza um processo gerenciado



GP2.1-Estabelecer uma Política organizacional
Definido dentro do componente Estratégia , com suas PA´s

GP2.2-Planejar o processo
DMM(1),DMM(2),DMM(3)

GP2.3-Prover os recursos
DMM(10)

GP2.4-Definir Responsabilidades
DMM(6), DMM(7),DMM(9)

GP2.5-Treinar as pessoas
DMM(10)

GP2.6-Controlar produtos de trabalho
DMM(18),DMM(19)

GP2.7-Identificar e envolver stakeholders relevantes
DMM(6),DMM(7),DMM(9)

GP2.8-Monitorar e controlar o processo
DMM(8)

GP2.9-Avaliar objetivamente a aderência ao processo
DMM(8),DMM(11)

GP2.10-Rever o “status” do processo com a gerência de alto nível
DMM(8),DMM(11)
GG3-Institucionalizar um processo definido



GP3.1-Estabelecer um processo definido
Estratégia

GP3.2-Coletar experiências relacionadas com o processo

GG4-Institucionalizar um processo gerenciado quantitativamente
(*)
Todas com foco na DMM(8), DMM(11)

GP4.1-Estabelecer objetivos quantitativos para o processo


GP4.2-Estabilizar o desempenho do processo

GG5-Institucionalizar um processo otimizado
(*)
Todas com foco na DMM(8), DMM(11)

GP5.1-Garantir a melhoria contínua do processo


GP5.2-Corrrigir as causas raízes de problemas


   (*)-CMMI-DEV- representação por estágios