Universidade Federal de Santa Catarina - UFSC

Departamento de Informática e Estatística – INE

Sistemas de Informação
Engenharia de Software – Ine5614

CMMI – Visão Geral

Detalhamento Nível 2

Paulo Alberto Violada 02138379

Thomas Augusto Damo Ranzi 02138468

Florianópolis, 3 de dezembro de 2003

 INTRODUÇÃO

Com o passar do tempo, nos tornamos cada vez mais dependes dos Softwares, seja
como meros usuários, seja utilizando-os como ferramenta para desenvolvimento. Para se ter
uma idéia de como somos dependentes dos softwares, é só pensar nas conseqüências
catastróficas que se teria se ocorresse algum problema em um sistema de Controle de
Tráfego Aéreo, por exemplo.

Acredita-se que a qualidade de Software está diretamente ligada à qualidade em que

o Software é desenvolvido. Sem o conhecimento e controle das etapas de desenvolvimento,
é impossível atestar que determinada aplicação é adequada. A preocupação com o processo
de desenvolvimento de software está relacionada à necessidade de entender, avaliar,
controlar, aprender, comunicar, melhorar e certificar o trabalho de Projeto de Software.

Com o objetivo de se fazer de forma eficiente a documentação, definição, medição,

análise, avaliação, comparação e alteração dos processos foi lançada em 1991, pelo SEI
(Instituto de Engenharia de Software) o modelo CMM (Capability Maturity Model). O
CMM não é uma Norma de Qualidade, mas um Modelo usado como referência para elas
(vide Anexo 2).

O CMM original era específico para a área de desenvolvimento de software, mas

com o tempo foi surgindo a necessidade de achar um padrão também outras áreas. Para
isso, foram criados diversos “CMMs”, que no fim, não seguiam os mesmos padrões entre
si. Com isso, em 2002 foi lançado o CMMi (Capability Maturity Model Integration), sem
abandonar o CMM original, que visa a integração de todos os CMMs, buscando corrigir as
inconsistências existentes entre eles.

O CMMi tem uma diferença básica em relação ao CMM, a dupla representação.

Existe a Representação por Estágios e a contínua. A representação por Estágios é dividida
em 5 Níveis, nos quais existem Áreas de Processo específicas por nível, e para progredir de
nível a organização precisa cumprir os requisitos de cada nível mais os requisitos dos níveis
anteriores. Já na Representação Continua, as Áreas de Processo são independentes dos
níveis, sendo que uma Área pode estar em um nível e outra em outro.

Para este trabalho, iremos especificar o nível 2 da representação por estágios

(Gerenciado). Uma organização nível 2 é capaz de assumir compromissos referentes a
requisitos, prazos e custos com alta probabilidade de ser capaz de cumpri-los. Para isso, ela
precisa cumprir os 7 requisitos (Áreas de Processo) do nível 2. A organização nível 2 é
disciplinada em nível dos projetos. Por isso, ela sabe estimar e controlar projetos
semelhantes a projetos anteriores bem-sucedidos.
O que é CMMi:

O CMMi é um modelo que propõe a avaliação da capacidade e da maturidade de

uma organização e indica diretrizes para a melhoria do processo de software. O termo
capacitação diz respeito tanto à habilidade para desenvolver software com competência,
quanto à capacidade de incorporar novas tecnologias. É dividido em cinco níveis, após o
nível 1 (Capacidade de Desenvolver Software), para se conquistar os outros níveis é preciso
que a organização cumpra as chamadas Áreas de Processo de cada um. Neste estudo,
mostraremos as Áreas de Processo do nível 2, chamado Gerenciado.

Visando aprimorar o modelo CMM, foi desenvolvido o CMMi. Isso porque, à

medida que o CMM original (Software-CMM ) foi evoluindo, diversos outros “CMMs”
foram criados, buscando cobrir outras áreas de interesse. Surgiram assim o Software
Aquisition CMM, o Software Engeneering CMM, o Integrated Product Development CMM
e o People CMM. O surgimento de todos esses tipos de CMM gerou algumas
inconsistências. Em primeiro lugar nem todos usavam a mesma terminologia, de modo que
um mesmo conceito poderia receber diferentes nomes em cada modelo. Alem disso, a
estrutura dos diversos CMMs não era padrão. Os modelos tinham diferentes tipos de níveis
ou formas diferentes de avaliar o progresso. Um terceiro problema eram os altos custos de
treinamento, avaliação e harmonização para organizações que tentassem utilizar mais de
um modelo. Ao mesmo tempo, o lançamento do projeto SPICE, da ISSO, levou à
necessidade de compatibilização do CMM com a futura norma ISO 15504.

O CMMi possui duas formas de representação (vide Anexo 1):

-A Representação por Estágios tem por foco a maturidade organizacional e provê

um caminho evolutivo para a melhoria do processo. Esta representação direciona e auxilia
às organizações que desejam estabelecer a melhoria de processos de software. As áreas do
processo são agrupadas em 5 níveis de maturidade, que devem ser atendidas na sua
totalidade para viabilizar um estágio definido de melhorias.

-Já a Representação Contínua tem por foco a capabilidade do processo e oferece um

caminho flexível para a implementação de melhorias. Permite que as organizações
escolham áreas específicas do processo para a implementação de melhorias, bem como
implementar níveis diferentes de capabilidade para diferentes processos.

O CMMi focaliza os processos:

– Sob o ponto de vista gerencial;

– Não trata o aspecto tecnológico;
– Não diz como implementar determinadas práticas, apenas o que deve ser feito
 Para que serve CMMi:
O CMMi não tem por finalidade, entrar em detalhes específicos sobre como os
processos devem funcionar. Sua idéia é definir quais são os processos imprescindíveis, em
que ordem devem ser implementados e como verificar se estão realmente
institucionalizados na empresa. Isto permite que cada empresa implemente o Modelo de
acordo com a sua realidade (recursos, tipo de software desenvolvido, tamanho, cultura etc.).
A definição de seus processos é, portanto, indelegável, embora a maioria das empresas
conte com o auxílio e orientação de empresas de consultoria especializadas.

O CMMi baseia-se nos conceitos clássicos de qualidade. E entre os conceitos mais

importantes de qualidade encontra-se o de Garantia de Qualidade, como oposto ao Controle
de Qualidade. Enquanto o controle de qualidade procura encontrar defeitos no produto
acabado, a garantia de qualidade procura garantir que, em cada etapa da fabricação do
produto, defeitos não sejam injetados.

Os principais objetivos do nível 2, especificamente são :

– Estabelecer uma política organizacional para o

planejamento e execução do processo;
– Planejar o processo;
– Prover os recursos necessários para a execução do
processo;
– Definir e atribuir responsabilidades;
– Providenciar o treinamento necessário para as pessoas
executarem o processo;
– Executar e gerenciar o processo;
– Gerenciar configurações e versões de produtos de trabalho
selecionados;
– Monitorar e controlar a execução do processo;
– Verificar a conformidade da execução do processo e dos
produtos de trabalho a procedimentos e padrões;
– Submeter à analise gerencial os resultados e atividades do
Processo;
Quem se beneficia com CMMi;
Em um extremo, estão as grandes empresas que desejam atingir níveis mais altos de
maturidade (normalmente o nível 3, a princípio) e serem formalmente certificadas pelo SEI.
Um programa como este pode levar de 4 a 10 anos e custar centenas de milhares de dólares.
No outro extremo encontram-se empresas com menores recursos, desejando melhorar seus
processos, mas sem a necessidade de certificação formal.

As empresas que investem no CMMI têm como principais benefícios o aumento da

qualidade dos processos de software e o reconhecimento internacional dessa qualidade.
Também têm uma maior e mais efetiva gerência de projetos de software, no que diz
respeito a custo, tempo e recursos utilizados.

Os maiores benefícios do CMMi são:

a) Maior produtividade: gerando-se mais software com o mesmo esforço
b) Maior visibilidade: sabe-se com antecedência quanto o software custará e quando
ficará pronto
c) Maior satisfação do cliente: menos defeitos no software
d) Cumprimento de prazos
e) Atendimento a requisitos funcionais e não-funcionais

Uma empresa que conquista o CMMi nível 2 (Gerenciado), possui um diferencial

com relação aos seus concorrentes, visto que o CMMi é reconhecido como uma garantia de
qualidade do processo de desenvolvimento de software. Alem disso, através do segmento
correto das ações propostas, a Organização é capaz de executar e gerenciar seus projetos de
acordo com o que foi planejado e documentado, cumprindo os prazos de entrega e
conseqüentemente conquistando a confiança do cliente.
CMMi Nível 2 (GERENCIADO):

Para se conquistar o CMMI nível dois (Gerenciado) a organização precisa ter a

capacidade de gerenciar um projeto. Para isso é preciso que todas as áreas de processo
descritas abaixo sejam cumpridas. São elas:

1. Gerenciamento de Requisitos
2. Planejamento de Projeto
3. Monitorização e Controle de Projeto
4. Gerenciamento de Contrato com Fornecedor
5. Medição e Análise
6. Garantia de Qualidade de Processo e Produto
7. Gerenciamento de Configuração

Estas áreas de processo são divididas em 5 sub-áreas, definidas como: Meta,

Compromisso, Habilidade, Atividade e Verificação.

1. GERENCIAMENTO DE REQUISITOS:

Para a área-chave de processo Gerenciamento de Requisitos temos a descrição das sub-

áreas e o propósito desta área-chave de processo:

O propósito desta área de processo é gerenciar os requisitos dos produtos do projeto

e dos componentes, além de identificar inconsistências entre os requisitos e os planos de
projeto.

 Meta:
1. Requisitos são gerenciados e inconsistências com os planos de
projeto e produtos de trabalho são identificados.
2. O processo é estabelecido como um processo gerenciado.

 Compromisso:
1. O projeto segue uma política estabelecida pela organização para o
gerenciamento de requisitos de sistema alocados ao software.

 Habilidade:
1. Estabelecer e manter o plano para efetuar o processo de
gerenciamento dos requisitos.
2. Prover recursos adequados para efetuar o processo de gerenciamento
de requisitos, desenvolvendo produtos de trabalho, e provendo
serviços de processos.
 3. Atribuir responsabilidade e autoridade para efetuar o processo,
desenvolvendo produtos de trabalho, e provendo serviços do
processo de gerenciamento de requisitos.
4. Os membros da equipe de desenvolvimento de software e outros
grupos de software relacionados são treinados para realizar suas
atividades de gestão de requisitos.

 Atividade:
1. Colocar os designados produtos de trabalho do projeto de
gerenciamento de requisitos em níveis apropriados do gerenciamento
de configuração.
2. Identificar e envolver os principais pontos do processo de
gerenciamento de requisitos como planejado.
3. Monitorar e controlar o processo de gerenciamento de requisitos
junto com o plano para efetuar o processo e tomar ações corretivas
apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo de gerenciamento de
requisitos com suas descrições de processo, padrões e procedimentos,
e não-conformidades.
2. Rever as atividades, estados, e resultados do processo de
gerenciamento de requisitos com um nível maior de gerenciamento e
resolver problemas.

2. PLANEJAMENTO DE PROJETOS:

Para a área-chave de processo Planejamento de Projeto temos a descrição das sub-

áreas:

O propósito desta área de processo é estabelecer e manter planos que definem as

atividades de projeto.

 Meta:
1. Estimativas dos parâmetros do planejamento de projeto são
estabelecidas e mantidas.
2. Um plano de projeto é estabelecido e mantido como base para o
gerenciamento do projeto.
3. Compromissos com o plano de projeto são estabelecidos e mantidos.
4. O processo é estabelecido como um projeto gerenciado.

 Compromisso:
 1. O projeto segue uma política organizacional para o planejamento de
projeto de software.

 Habilidade:
1. Estabelecer e manter o plano para efetuação do planejamento do
processo de projeto.
2. Recursos e orçamento adequados são providos para o planejamento
de projeto de software, desenvolvimento de produtos de trabalho e
serviços do processo.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
planejamento do processo de projeto.
4. Os gerentes de software, engenheiros de software e outras pessoas
envolvidas no planejamento do projeto de software são treinados em
estimativas de software e procedimentos de planejamento aplicáveis
às suas áreas de responsabilidade.

 Atividade:
1. Colocar os designados produtos de trabalho do processo de
planejamento de projeto em níveis apropriados do gerenciamento de
configuração.
2. Identificar e envolver os principais pontos do processo de
planejamento de projeto como planejado.
3. Monitorar e controlar o processo de planejamento de processo junto
com o plano para efetuar o processo e tomar ações corretivas
apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo planejamento de
processo com suas descrições de processo, padrões e procedimentos,
e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.

3. MONITORIZAÇÃO E CONTROLE DE PROJETOS:

Para a área-chave de processo Monitorização e Controle de Projeto temos a

descrição das sub-áreas:

O propósito desta área de processo é prover um entendimento do progresso do

projeto para que as ações corretivas apropriadas possam ser tomadas quando a performance
do projeto desvia significativamente do planejado.

 Meta:
 1. Progresso e performance atuais são contrastadas com o plano de
projeto.
2. As ações corretivas são executadas e gerenciadas até sua conclusão,
quando os resultados e o desempenho reais desviam
significativamente dos planos de software.
3. O processo é estabelecido como um processo gerenciado.

 Compromisso:
1. Estabelecer e manter uma política organizacional para o
planejamento e execução do monitoramento de projeto e controle de
processo.

 Habilidade:
1. Estabelecer e manter o plano para efetuação do planejamento do
processo de projeto.
2. Recursos e orçamento adequados são providos para o planejamento
de projeto de software, desenvolvimento de produtos de trabalho e
serviços do processo.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
planejamento do processo de projeto.
4. Os gerentes de software, engenheiros de software e outras pessoas
envolvidas no planejamento do projeto de software são treinados em
estimativas de software e procedimentos de planejamento aplicáveis
às suas áreas de responsabilidade.

 Atividade:
1. Colocar os designados produtos de trabalho da monitoração de
projeto e controle de processo em níveis apropriados do
gerenciamento de configuração.
2. Identificar e envolver os principais pontos do processo como
planejado.
3. Monitorar e controlar o processo junto com o plano para efetuar o
processo e tomar ações corretivas apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo com suas descrições
de processo, padrões e procedimentos, e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.

4. GERENCIAMENTO DE CONTRATO COM O FORNECEDOR:

Para a área-chave de processo Gerenciamento de Contrato com o Fornecedor temos

a descrição das sub-áreas:
 O propósito desta área de processo é gerenciar a aquisição de produtos dos
fornecedores, para isto é necessário existir um contrato formal.

 Meta:
1. Contratos com os fornecedores são estabelecidos e mantidos.
2. O contratante e o subcontratado de software concordam com os
compromissos assumidos entre eles.
3. O processo é definido como um processo gerenciado.

 Compromisso:
1. Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de gerenciamento do acordo
com o fornecedor.

 Habilidade:
1. Estabelecer e manter um plano para execução do processo de
gerenciamento do acordo com o fornecedor.
2. Prover recursos adequados para execução do processo de
gerenciamento do acordo com o fornecedor, desenvolvendo produtos
de trabalho e serviços do processo.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
processo de gerenciamento do acordo com o fornecedor.
4. Treinar pessoal para dar suporte ao gerenciamento do acordo com o
fornecedor quando necessário.

 Atividade:
1. Colocar os designados produtos de trabalho do processo de
gerenciamento do contrato com o fornecedor em níveis apropriados
do gerenciamento de configuração.
2. Identificar e envolver os principais pontos do processo como
planejado.
3. Monitorar e controlar o processo junto com o plano para efetuar o
processo e tomar ações corretivas apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo com suas descrições,
padrões e procedimentos, e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.
 5. MEDIÇÃO E ANÁLISE:

Para a área-chave de processo Medição e Análise temos a descrição das sub-áreas:

Desenvolver e manter uma capacidade de medição que serve para fornecer

informações necessárias para o gerenciamento.

 Meta:
1. Objetivos de medição e atividades são alinhados com as necessidades
identificadas de informação e objetivos.
2. Resultados da medição identificados são providos.
3. O processo é definido como um processo gerenciado.

 Compromisso:
1. Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de medição e análise.

 Habilidade:
1. Estabelecer e manter um plano para execução do processo de
medição e análise.
2. Prover recursos adequados para execução do processo de medição e
análise, desenvolvendo produtos de trabalho e serviços do processo.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
processo de gerenciamento do acordo com o fornecedor.
4. Treinar pessoal para dar suporte ao processo quando necessário.

 Atividade:
1. Colocar os designados produtos de trabalho do processo em níveis
apropriados do gerenciamento de configuração.
2. Identificar e envolver os principais pontos do processo como
planejado.
3. Monitorar e controlar o processo junto com o plano para efetuar o
processo e tomar ações corretivas apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo com suas descrições,
padrões e procedimentos, e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.
 6. GARANTIA DA QUALIDADE DE PROCESSO E PRODUTO:

Para a área-chave de processo Garantia da Qualidade de Processo e Produto temos a

descrição das sub-áreas:

O propósito desta área de processo é prover pessoal e gerenciamento para obter

avaliações objetivas dos processos e produtos de trabalho associados.

 Meta:
1. A aderência dos processos executados e produtos de trabalho
associados e serviços para descrição dos processos aplicáveis,
padrões, e procedimentos são objetivamente efetuados.
2. Problemas de não-conformidade são objetivamente rastreados e
comunicados, e a resolução é elaborada.
3. O processo é definido como um processo gerenciado.

 Compromisso:
1. Estabelecer e manter uma política organizacional para o
planejamento e execução do processo, e também para a segurança da
qualidade do produto.

 Habilidade:
1. Estabelecer e manter o planejamento para execução do processo.
2. Existem recursos e orçamento adequados para a realização das
atividades de garantia de qualidade de software.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
processo de gerenciamento do acordo com o fornecedor.
4. Treinar pessoal para dar suporte ao processo quando necessário.

 Atividade:
1. Colocar os designados produtos de trabalho do processo em níveis
apropriados do gerenciamento de configuração.
2. Identificar e envolver os principais pontos do processo como
planejado.
3. Monitorar e controlar o processo junto com o plano para efetuar o
processo e tomar ações corretivas apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo com suas descrições,
padrões e procedimentos, e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.
 7. GERENCIAMENTO DE CONFIGURAÇÃO:

Para a área-chave de processo Gerenciamento de Configuração temos a descrição

das sub-áreas:

O propósito desta área de processo é estabelecer e manter a integridade dos produtos

de trabalho usando identificação de configuração, controle de configuração, administração
de estados da configuração e auditorias de configuração.

 Meta:
1. As atividades de gestão de configuração de software são planejadas.
2. Mudanças nos produtos de software são identificadas e controlados.
3. Integridade das configurações básicas (baselines) são estabelecidas e
mantidas.
4. O processo é definido como um processo gerenciado.

 Compromisso:
1. Estabelecer e manter uma política formal para o gerenciamento de
configuração.

 Habilidade:
1. Estabelecer e manter um plano para execução do processo de
gerenciamento de configuração.
2. Prover recursos adequados para execução do processo de
gerenciamento de configuração, desenvolvendo produtos de trabalho
e serviços do processo.
3. Atribuir responsabilidade e autoridade para efetuação do processo,
desenvolvendo produtos de trabalho, e provendo serviços do
processo de gerenciamento de configuração.
4. Treinar pessoal para dar suporte ao processo quando necessário.

 Atividade:
1. Colocar os designados produtos de trabalho do processo em níveis
apropriados do gerenciamento de configuração.
2. Identificar e envolver os principais pontos do processo como
planejado.
3. Monitorar e controlar o processo junto com o plano para efetuar o
processo e tomar ações corretivas apropriadas.

 Verificação:
1. Avaliar objetivamente a aderência do processo com suas descrições,
padrões e procedimentos, e não-conformidades.
2. Rever as atividades, estados, e resultados do processo com um nível
maior de gerenciamento e resolver problemas.
 CONCLUSÃO
Com base no que foi pesquisado, é possível afirmar que a busca pelo CMMi é uma
escolha válida, visto que além de a empresa no aspecto interno conquistar inúmeros
benefícios, no aspecto de mercado, consegue um diferencial com relação a outras empresas
desenvolvedoras de software.

Com isso, os consumidores (compradores) de software têm uma referência na hora

de efetuar a compra do software desejado, levando em consideração as garantias de uma
empresa que possui o certificado CMMi.

Isso leva a crer que o modelo CMMi tende a ser o alvo da maioria das empresas de
desenvolvimento de software do mundo, já que num prazo que varia de Organização para
Organização, o investimento terá o retorno desejado, através do aumento das vendas e
economia advinda da otimização dos processos.
Referências Bibliográficas:
Software Engineering Institute www.sei.cmu.edu

http://www.inf.ufsc.br/~ricardo/download/cmmi/staged_02tr029.pdf

http://www.spindf.org/download/Artigo_CMMI.pdf

http://www.kenji.com.br/ita/ce230/apresentacoes/Capability%20Maturity%20Model
%20Integration%20-%20CMMI.pdf

http://www.choose.com.br/infochoose/artigos/viewer.asp?n=42&a=01

http://www.ulbra.tche.br/~danielnm/bytche/nro1/qualisw/qualidade_software.htm

http://www.choose.com.br/consultoria/cmmi.asp

http://www.ju.unisinos.br/detalhes_materia.asp?editoria=exatas&CodMateria=1171

http://www.mct.gov.br/Temas/info/Dsi/PBQP/Reuniao%20BSB/CMM-TR24_.V1.2.pdf

http://www.inf.ufsc.br/~ricardo/download/cmmi_apostila.PDF

http://www.choose.com.br/infochoose/artigos/viewer.asp?n=45&a=02

http://www.fazenda.gov.br/ucp/pnafe/docs/Gest%C3%A3o%20do%20Desenvolvimento.pdf

http://lqps.sj.univali.br/subpaginas/projetos/15504MPE/publicacoes/sucesu2003_vf.pdf

http://www.addtech.com.br/articles/cmm.pdf

http://www.choose.com.br/infochoose/Artigos/viewer.asp?n=09&a=02

http://www.dcc.unicamp.br/~cortes/inf310/transp/cap8_6pp.pdf

http://www.psphome.hpg.ig.com.br/downloads/CMM-Overview.doc

http://www.pr.gov.br/batebyte/edicoes/1999/bb88/cmm.htm

http://www.cits.br/CITS/saibamais_cmm.htm

http://jdfurlan.com.br/id22.htm
Anexos:
Anexo 1:

Anexo 2:

Comparando o CMMi com outros modelos de avaliação de projetos:

Abaixo, outros modelos de avaliação dos processos de desenvolvimento de

software, comparados com o CMMi: