Equipe de Revisores do DMM-Data Maturity Model do CMMI Institute:

                       Equipe de Revisores do DMM-Data Maturity Model do CMMI Institute:

Na lista, aparecem 3 brasileiros: Carlos Barbieri(Fumsoft), Antônio Braga(CrestConsulting) e Mario Faria(ex-CDO do Boa Vista Serviços), apontados pelas setas. Em destaque, as participações de figuras "estrelas" da área de dados como Peter Aiken(ex-presidente da DAMA), Peter Chen(inventor do Modelo Entidade-Relacionamento) e Bill Inmon(criador do conceito de Data Warehousing )

DMM-Data Maturity Model do CMMI-Institute

DMM-Data Maturity Model-CMMI Institute


1)O Modelo  DMM-Data Maturity Model foi lançado oficialmente, conforme o link abaixo.

http://cmmiinstitute.com/dmmpressrelease20140528/


2)A partir de agora, estamos autorizados a publicar regularmente os pontos do modelo na sua versão final, em comparação com o DMBOK(DAMA), visando uma análise das melhores práticas em Gestão e Governança de Dados. Em posts anteriores, neste Blog,  você teve informações sobre o modelo na sua versão draft.


3)A Fumsoft oferecerá nos dias 15,16,17, 21 e 22 de Julho o curso Governança e Gestão de Dados-Conceitos e Maturidade, onde pontos dessa comparação (DMM e DMBOK) serão discutidos pelo autor deste blog. Veja link abaixo

http://www.fumsoft.org.br/eventos/24072014-gestao-e-governanca-de-dados-fundamentos-e-maturidade

DMM-Data Maturity Model

Como convidado, pelo CMMI Institute, para participar da equipe de revisores do DMM-Data Maturity Model, não mais escreverei ou comentarei aspectos relacionados a este modelo, até que ele esteja oficialmente lançado e distribuído (versão DMM 1.0) , o que está previsto para a metade de 2014.

From this moment on, all CMMI Materials that i get from CMMI Institute  will be kept strictly confidential and  such information or materials will not be disclosed  to any persons or organizations other than CMMI Institute representatives.

Carlos Barbieri

Implementação prática de MGD-Melhoria de Gestão de Dados-Parte IX

Depois de analisarmos os aspectos de Gestão e Governança de dados, envolvendo os conceitos de DMM e DMBOK,  vamos discutir os passos necessários para se estabelecer, de forma prática, os trabalhos de implementação da MGD-Melhoria de Gestão de Dados. Nesse particular, a empresa poderá adotar os conceitos do DMM-Data Maturity Model, ou do DAMA(Data Management Association), convergentes como mostrado nos posts anteriores. A aplicação de DMM permitirá um caminho mais incremental, em direção à uma maturidade de dados. O da DAMA sugere um conjunto de melhores práticas, mas não define camadas de maturidade. Ambos são trilhas certas e inclusive, podem ser adotados de forma conjunta, permitindo que a empresa estabeleça a sua MGD-Melhoria de Gestão de Dados.

1)Criação de um grupo de estudo,  envolvendo a TI e as áreas de negócios  cujos dados sejam mais sensíveis e críticos, como dados financeiros, de clientes, de vendas, etc.  É fator absolutamente crítico de sucesso o alto envolvimento das áreas de negócios, com a busca de patrocinadores fortes e comprometidos com a melhoria da gestão de dados. Dessa forma, você deve

·        Entender os problemas existentes

·        Entender e levantar os principais objetivos de  melhorias de dados e ter uma visão clara de como isso acontecerá;

·        Levantar e identificar prioridades em solução de dados: áreas, processos, dados, regras de negócios, tudo balizados pelo incômodo dos  problemas e apreensões existentes nessa ;

2)Definir políticas para a conceituação de Dado, como um ativo(asset) da empresa e diretrizes para a formação do Conselho de Governança de dados da empresa. As políticas deverão ser regras gerais “consensadas”  entre as unidades organizacionais envolvidas e aprovadas pela alta gestão da empresa e deverão ser parte de processos e padrões definidos para a Gestão/Governança de dados na empresa. Começar a pensar nas pessoas envolvidas;

3)Definir os riscos de dados “impuros” (data flaws) ou como os aspectos de baixa qualidade dos dados criam impactos nos negócios da empresa, na sua reputação ou na produção adequada e confiável de informação. A definição de riscos potenciais ou  de “business cases” de problemas derivados de qualidade de dados é fator crítico na aprovação de um Programa de Governança de dados, pela alta gerência e fundamental para sua sensibilização ;

4)Inventariar nas  áreas definidas, TI inclusive, as principais fontes de dados, de forma a se ter uma visão do grau de replicação de arquivos considerados críticos, como BD de Clientes,  de Pessoal, de Materiais, Financeiro, etc; Esse item, que oferece uma visão qualitativa do problema, compõe parte do item 3 acima descrito;

·        Levantar e identificar os Dados, metadados e envolvidos naquela área/ assunto prioritário analisando e catalogando as informações;

·        Selecionar as fontes de dados consideradas mais críticas para tratamento quantitativo de qualidade. Buscar e aplicar soluções de “data profiling” em bases escolhidas baseadas em priorização, visando demonstrar o grau de qualidade dos dados considerados críticos;

5)Analisar as lacunas observadas e o nível de maturidade atual no assunto dados. Observar qual o grau de pré-disposição das áreas com relação ao compartilhamento e “proprietarismo” de dados. Isso poderá indicar o grau de dificuldade nas ações de GD. Com eles, fazer a  proposição de plano de ação, que poderá envolver  a criação de gestores de dados(data steward) localizados em áreas críticas de negócio da empresa. Os gestores de dados atuam em áreas funcionais/linhas de negócios com a responsabilidade de aplicar e preservar as políticas, regras , diretrizes de qualidade, como criação, uso, replicação,etc;  Alguns gestores comporão a camada tática da GD, através do Comitê de Gestores, juntamente com o CDO(autoridade em dados na empresa, caso haja) e com o grupo responsável pela implementação das ações de GD na empresa(DMO-Data Management Office ou DGPG-Data Governance Process Group), semelhantemente ao SEPG das implementações CMMI e MPS.BR

6)Assim, definir  a GD em camadas  funcionais distintas, com papéis definidos e pessoas alocadas:

        A camada estratégica, onde está o Conselho de GD, ou de Conselho de Dados, ou que nome venha a ter. Formado por gerentes funcionais de áreas (TI, inclusive), terá o objetivo de estabelecer  as políticas e diretrizes que definem o dado como um ativo da empresa. Resolverá impasses que certamente surgirão e será uma espécie de Comitê Consultivo;

       A camada tática com o Grupo de implementação do programa de GD(CDO-Chief Data Office, ou DMO-Data Management Office, ou DGPG-Data Governance Program/Process Group), formado pela gerência média, responsáveis pela execução dos planos de ação. Aqui entrará o Comitê dos Gestores de Dados, formado pelos gestores das áreas funcionais. As palavras chaves aqui são: envolvimento, cooperação e convencimento por resultados concretos. A gerência de uma área de negócios deverá ter pleno entendimento das definições de GD, vindas do Comitê acima, a fim de apoiar as ações de seus gestores de dados e as definições do CDO/DMO/DGPG;

·       A camada operacional, com os gestores de dados(data steward) alocados nas áreas e linhas de negócios, responsáveis pelas atividades do dia a dia. Por exemplo, na área de Faturamento de uma empresa de energia elétrica, poderá haver gestores de dados divididos em domínios ou subdomínios, como faturamento secundário/primário/grandes consumidores de alta tensão, etc. O aproveitamento de recursos humanos nas áreas de negócios, com grande conhecimento do assunto(subject área) pode ser considerada  uma excelente estratégia na definição dos gestores de dados(data steward). Esse conceito é chamado “Governança de dados não invasiva”, e foi definido por Robert Seiner, da Kikconsulting, especialista em Governança e Administração de dados;

•        Pensar nas Pessoas e Papeis(Estrutura  Organizacional)

–       Não se esquecer de buscar o apoio executivo fundamental nos CxO

–       Não se esquecer dos envolvidos nos dados, owners de dados, responsáveis pelo uso dos dados nas áreas de negócio

–       Não se esquecer da camada tática envolvendo o DMO, ou o DGPG e  Comitê dos gestores de dados

–       Não se esquecer dos Gestores de dados(de negócios e de TI), com suas variantes nos projetos SDLC(project data stewards). Pensar nos Gestores de dados de áreas cujos dados serão compartilhados (domain data stewards)

7)Pensar a Governança de dados em interação com  alguns projetos específicos,  com seus respectivos planos, selecionados pela prioridade, definidos em programas, como MDM(Master Data Management), Segurança de dados, Qualidade dos dados para tomada de decisão(BI com Analytics), Dados não estruturados(Geo-BI, por exemplo),etc. Por exemplo, na trilha MDM, identificar as ações para reduzir as replicações de fontes de dados críticos(Consumidor, Órgãos, Produtos, etc) , levantados nos itens anteriores. Envolver as áreas de negócios que atuam no domínio daquele dado e criar ações alinhando “business e TI”. Esses projetos devem ser vistos como iterações do processo maior de GD, aplicando-se  neles as atividades de identificação de metadados, definição de métricas(processo de MED), garantia da qualidade(processo de GQA), etc.  Na trilha de BI com Analytics, considerar aspectos de governança no sentido de identificar por áreas de negócios: os seus usuários, os relatórios ou cubos produzidos e consumidos, o valor de retorno dessas informações de BI para o usuário, freqüência e tipo de solicitações atendidas, etc. Esse trabalho deverá ser feito com envolvimento do Núcleo de BI  e apontará , de certa forma, o grau de maturidade com que a área de BI atua. Na camada de dados não estruturados, entender que 80% dos dados de uma empresa hoje estão na forma semi ou não estruturada. Assim aspectos relacionados com dados de mapas, GED (Gestão Eletrônica de Documentos), etc devem ser observados  e também  merecer os olhares da GD;

8)Sempre atuar com o conceito de “quick hits”, ou seja realizando projetos que retornem rapidamente resultados visíveis e importantes;

•        Seja prático:

–       Sempre mostre valor nas ações e processos;

–       Elementos de dados chaves devem ter os seus gestores de dados definidos, os seus processos e responsabilidades definidos, como  manutenção de metadados, resolução de pendências,etc ;

–       Os elementos  de dados chaves a serem escolhidos, normalmente tem sabor “financeiro”, ou seja elementos de relatórios financeiros, aspectos de “compliance”, riscos regulatórios, outros dados sugeridos por alto escalão, ou pelos próprios GDN(gestores de dados de negócios);

–       Identificar a função de negócio que possui o Dado(ou a mais importante). Embora o dado seja usado por várias funções de negócios, a escolha da “master” poderá ser feita observando as mudanças e impactos que aquele dado acarreta em quais funções. Quais funções fundamentalmente são impactadas  quando o dado muda? É uma diferença entre “USAR” e  “DEPENDER”  do dados. A segunda pergunta é: Onde o dado se origina, seu nascimento, a sua criação e por conseguinte a sua cadeia e ciclo de vida.

9)Definir procedimentos de monitoração dos projetos, através de ações de processos/procedimentos  de  medições(MED) ou de garantia da qualidade(GQA), criando indicadores, como número e tipos de “incidentes” relativos a dados, problemas de reclamações externas devido a erros de dados, não-conformidades com definições regulatórias detectadas, etc;

10) Por fim, entender que GD é um  programa e não um projeto isolado e portanto tem características contínuas, e que o processo desenhado para implementá-lo deverá ser constantemente avaliado por medições e ganhos tangíveis, o que viabiliza a sua continuidade e minimiza os riscos de seu colapso. 

11)Se você quiser criar uma memória sintética , pense nos “ Ps”  da GD, discutidos até aqui, ao longo desse contexto:

1)Patrocínio

2)Políticas

3)Processos

4)Padrões

5)Papéis e Pessoas

6)Procedimentos

7)Programas/Projetos(Planos)

8)Performance(MED-Medições  e GQA-Garantia da Qualidade)

9)Plataformas

10)Palavras(Comunicação) 

12)Considerações sobre a implementação de MGD-Melhoria de Gestão de Dados e o tamanho de empresas: A GD se caracteriza por um esforço , hoje ainda encontrado em grandes organizações. Isso entretanto não invalida a sua aplicação em empresas menores(SMB) fazendo as suas devidas adaptações. Algumas ações sugeridas acima poderão ser implementadas facilmente nas pequenas empresas, como o entendimento de seus problemas relacionados aos dados, a descoberta e catalogação de suas fontes principais de dados, além da definição dos P das GD(se não de todos, de alguns). Há ferramentais livres e open que podem ser usados. A estruturação das camadas de GD poderá ser adaptada, visto que em empresas pequenas, poderemos ter uma camada enxuta de GD, com os donos fazendo o papel de Conselho de GD e um recurso alocado parcialmente para as funções de gestor de dados, eliminando-se a camada tática. A nossa experiência em implementações de melhorias de processos em quase 100 empresas de variados portes em MG, nos credencia a garantir que a MGD poderá ser também implementada no segmento de SMB. Ao adotar uma abordagem de MGD-Melhoria de Gestão de Dados, essas empresas estarão se preparando de forma adequada  para o seu crescimento sustentável em termos de controlar esse ativo fundamental em qualquer empresa: os dados e as informações deles originados. Agindo agora, evitarão ou minimizarão os efeitos negativos futuros de uma gestão imprópria de seus dados.

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