CMM x CMMI

CMM (Capability model maturity) x CMMI (Capability Maturity Model Integration)A diferença entre o CMM e o CMMI é que enquanto o CMMI integra os modelos de capacitação e maturidade, o CMM divide-se em áreas como: software, engenharia de sistemas e processos. O CMMI foi desenvolvido visando implementar melhorias no CMM e integra em um único framework vários modelos CMM.Existem (ou existiam) vários modelos CMM, como por exemplo, pra engenharia de software, pra desenvolvimento de software, aquisição de software, etc. O CMMI veio pra integrar todos esses modelos, e por consequência, substituí-los.

http://200.199.231.226/portal/publicacao/arqprof/cmm.pdf

http://www.devmedia.com.br/articles/viewcomp.asp?comp=3529

http://sites.uol.com.br/laudelinobastos/QualificacaoCMMeCMMInoBrasil.pdf

http://gmobserver02.inf.ufsm.br:8082/features/apresentacoes/mainColumnParagraphs/04/document/Certifica%C3%A7%C3%A3o%20CMM%20e%20CMMI.ppt

Representações do CMMI

Olá leitores,

Como foi falado

antes existe dois tipos de representações no CMMI a "estagiada" e a "contínua" onde cada uma delas possuem várias carac´téristicas e níveis, o quadro ao lado mostra como são estruturadas essas representações e quais são as áreas de processo que engloba em cada um desses níveis.

Características da Estagiada:

• Melhorar o desempenho em um processo único;
• Melhorar o desempenho em várias área alinhadas aos objetivos de negócio da organização;
• Nivéis de capacidade utilizados para medir as melhorias;
• Melhorar diferentes processos com diferentes classificações;
• Apropriado para quem sabe que o processo deve ser melhorado;

Características da Contínua:

• Enfoque de melhoria do processo de forma sistemática e estruturada;
• Atingir cada um dos estágios garante a base fundamentada nescessária para o próximo estágio;
• Áreas de processo organizada em níveis de maturidade;
• Permite a organização ter um caminho evolutivo pré-definido para melhoria;
• Apropriado para quem não sabe como inciar um processo de melhoria ou qual processo deve ser prioridade;
• Possui grande número de casos de estudo e dados históricos de práticas bem sucedidas;

Na representação estagiada é caracterizado por Níveis de maturidade.

• Nivel 1, ela é tão boa quanto o gerente de projeto;
• Nivel 2, os planos são realistas e documentados e servem de base para o gerenciamento do projeto nela é que engloba as áreas de processo: Gerência de acordos com os fornecedores; Medição e análise; Garantia da qualidade de processo e do produto; Gerência de configuração; Gerencia de requisitos; Planejamento de projeto; Acompanhamento e controle de projetos;
• Nível 3, a gerência de projetos está baseada em um processo definido e é derivada do acervo da organização, nesse é engloba as áreas de processo: Gerência integrada de Projeto; Gerência de risco; Análise de Decisão e Resolução; Validação; Treinamento organizacional; Foco no processo organizacional; Definição do processo organizacional; Desenvolvimento de requisitos; Solução técnica; Integração de produto; Verificação;
• Nível 4, técnicas estatísticas e quantitativas são usadas para gerenciar a execução do processo e a garantia de qualidade do produto engloba as áreas: Desempenho do processo organizacional; Gerencia quantitativa dos processos;
• Nível 5, a gerência é executada dentro de um ambiente para melhoria contínua, engloba as áreas: Inovação e Melhoria organizacional; Análise de causa e resolução;

Link: http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf

Gerenciar X Acompanhar

Hoje vamos falar das diferenças entre acompanhamento e gerenciamento de projetos. Parece besteira, mas a diferença é enorme.

imaginar que você esta dentro de um carro em uma ladeira.No final da ladeira existe um muro, ele esta à uns 3 kilometros de distancia.O carro começa a descer… você não faz nadaPassou um kilometro e o carro continua a descer… você só vê o muro chegando mas não faz nadaDois kilometros, a velocidade aumentando e o muro chegando, e você não faz nada.700 metros, 500 metros, 300 metros, 100 metros… você nada faz1 metro e pow… bate no muro
O carro demorou 5 minutos para sair to topo da ladeira (com você dentro) e bater no muro
O que você fez neste processo?Acompanhou, simples assim.
Isto é o “Acompanhar”, você tinha conhecimento da situação, poderia ter tomado alguma ação quando viu que algo ia dar errado, mas não o fez, apenas acompanhou.
Gerenciar é muito mais que isso, gerenciando você poderia tomar várias ações como:- Pisar no freio;- Puxar o freio de mão;- Tentar fazer um desvio;- E até mesmo, em uma situação de extrema urgência, pular do carro.
Esta é a diferença.

Fonte: http://blogcmmi.com.br/

Antes de lê esse post no blogcmmi.com.br não tinha parado para pensar nisso.

Ah, inclusive serve como dica acessar o blogcmmi.com.br, tem posts interessantes onde ele exemplifica cada nível do CMMI, e ainda dá uma visão prática dos niveis.

Niveis do CMMI

Complementando o que foi escrito no slide, o CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação Continua

Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):

Nível 0: Incompleto (Ad-hoc)
Nível 1: Executado (Definido)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização (ou Optimizado)

Representação Por Estágios

Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):

Nível 1: Inicial (Ad-hoc)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização

Areas de Processos

O modelo CMMI v1.2(CMMI-DEV) contém 22 áreas de processo distribuidas entre os niveis de maturidade:
Análise Causal e Resolução
Gerência de Configuração
Análise de Decisão e Resolução
Gerenciamento Integrado de Projeto
Medição e Análise
Inovação Organizacional e Implantação
Definição de Processo Organizacional
Foco de Processo Organizacional
Desempenho de Processo Organizacional
Treinamento Organizacional
Monitoração e Controle de Projeto
Planejamento de Projeto
Garantia da Qualidade de Processo e Produto
Integração de Produto
Gerenciamento Quantitativo de Projeto
Gerenciamento de Requisitos
Desenvolvimento de Requisitos
Gerenciamento de Riscos
Gerenciamento de Acordo com Fornecedor
Solução Técnica
Validação
Verificação

A area de processos Gerenciamento de Riscos (Risk Management) esta alocado em sua maior parte no nivel de maturidade 3 e poucas funcionalidades do nivel 2.

Análise de Riscos em projetos de teste de software

Olá leitores,

O livro "ANÁLISE DE RISCOS em projetos de software" do autor Emerson Rios, parece ser bastante interessante para podermos compreender e indentifar os riscos de software.

Sinopse: Atualmente os novos conceitos organizacionais da área de TI colocam o teste de software dentro de um processo específico, executado por técnicos treinados e capacitados, com metodologia própria e ferramentas de automação adequadas. Os números têm mostrado o sucesso dessa mudança, embora muitas empresas ainda relutem em adotar tal solução, uma vez que os custos iniciais serão maiores, embora os custos de correção de defeitos em produção diminuam em um momento imediatamente seguinte. Como corrigir defeitos em produção sai mais caro do que corrigí-los em desenvolvimento, o resultado final será sempre favorável à organização que adota este modelo. O teste de software passa a ser um processo com padrões e áreas próprias, embora aderente ao processo de desenvolvimento. Dessa forma, quando se inicia um projeto de desenvolvimento de software, deve ser também iniciado um projeto de teste de software. Cada um dos processos (desenvolvimento e teste) suporta o seu projeto. O objetivo deste livro é ensinar o que é a análise de risco de teste de software, em uma visão global e didática, e posteriormente mostrar como o PMI e a SEI/CMMI enquadram essa atividade nos seus modelos.

Assuntos Abordados:

• Visão geral do conceito de risco: Definindo risco; Riscos decorrentes da Tecnologia da Informação; Riscos relativos ao teste de software; Determinando a magnitude dos riscos; Riscos baseados nas características de qualidade; Outros riscos do projeto de testes; Controlando os riscos; Lista de verificação para identificar riscos; Onde estão os maiores riscos;
• Entendendo melhor o conceito de risco: O que é risco; Tipos de risco de teste; Como tratar o risco; Riscos nos processos de teste; Gerência de riscos; Análise de riscos em projetos de teste de software;
• Gerenciando os riscos dos projetos - conforme oPMBOK do PMI: Planejamento da gerência de riscos; Identificação do risco; Análise qualitativa dos riscos; Análise quantitativa de risco; Planejamento de respostas aos riscos; Controle e monitoração dos riscos; Ciclo de vida do projeto e o plano de gerência de riscos;
• Gerência de Riscos - CMMI nível 3: Preparar para a gerência de riscos; Identificar e analisar riscos; Mitigar riscos;
• Gerência de Riscos - mps BR - Melhoria de Processode Software Brasileiro: Descrição do modelo;

Link: http://www.relativa.com.br/livros_template.asp?Codigo_Produto=29872#

Análise comparativa com outros processos

Olá pessoal,




Em minhas pesquisas pelo tradicional "google" encontrei um tabela super intuitiva que vai ajudar muito em nossas discussões e aprendizado na matéria Gerência de Riscos. Esta tabela faz uma análise comparativa entre alguns modelos de gerência de processos.




Fonte: http://www.sbc.org.br/bibliotecadigital/download.php?paper=235

Já que nosso orientador apresentou vários modelos, acredito que esta tabela possa ajudar outros grupos relacionados além de atrair opniões e comentários ao nosso blog.

Abraços! Aguardo seus comentários.

Apresentação da BRA - RISK TEAM

BRA-RISK Team

View SlideShare presentation or Upload your own.

Petic