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
|
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
Nenhum comentário:
Postar um comentário