estrutura, componentes e abordagens, de modo a fornecer um e processo e terceirização, além do conceito de “constelações”

contexto claro para os níveis de maturidade 4 e 5 que serão na arquitetura do modelo, que permite a sua expansão para
mapeados neste artigo. outros focos, tais como aquisições e entrega de serviços.

Figura 7. #--) )NTEGRA¥ÎODOS-ODELOS#--

Figura 6. 0ROGRAMA3&ONTE2/#(! Definição e objetivos do modelo
Histórico do modelo
Em 1991, o Software Engineering Institute (SEI), da Univer-
sidade Carnegie Mellon (EUA), criou o SW-CMM (Capability
Maturity Model para Software) a partir de uma encomenda
feita pelo Departamento de Defesa dos Estados Unidos.
Esse modelo foi criado focando o processo de engenharia de
software na proposta de melhoria contínua, trazendo discipli-
na e controle no desenvolvimento e manutenção do software
(BARTIÉ, 2002). Desta forma, passou a servir como uma das
principais referências de modelo de qualidade para o mercado
de empresas de software.
Com o passar do tempo, observou-se que variações aplicáveis
a outras disciplinas, tais como engenharia de sistemas, aquisi-
ção de software, gestão e desenvolvimento de mão-de-obra e
desenvolvimento integrado de produtos e processos, surgiram
de acordo com as diferentes necessidades das organizações.
Como cada um destes modelos possuía a sua própria arqui-
tetura e abordagem de implementação, a sua utilização por
organizações que possuíam processos integrados envolvendo
várias destas disciplinas tornou-se difícil devido aos altos
custos de treinamento, avaliação e ações de melhoria.
Diante deste cenário, o CMMI (Capability Maturity Model
Integration) foi criado pelo SEI em 2002 como um modelo evo-
lutivo em relação aos vários CMMs, com o objetivo de combinar
as suas várias disciplinas em uma estrutura única, flexível e
componentizada (Figura 7), que pudesse ser utilizada de forma
integrada por organizações que demandavam processos de
melhoria em âmbito corporativo (FERNANDES, 2008).
A versão 1.2 do CMMI foi publicada pelo SEI em agosto de
2006, trazendo um conjunto de melhorias e simplificações em
relação à versão anterior. Com o documento CMMI for Deve-
lopment (CMMI para Desenvolvimento), houve a unificação
do tratamento das disciplinas de engenharia de software, en-
genharia de sistemas, desenvolvimento integrado de produto
12 Engenharia de Software Magazine - Seis Sigma e CMMI
O CMMI (Capability Maturity Model Integration) é um mo-
delo de maturidade de melhoria de processos para desenvol-
vimento de produtos e serviços. (CMMI, 2006). Seu principal
propósito é fornecer diretrizes baseadas nas melhores práticas
voltadas para atividades de desenvolvimento e manutenção,
abrangendo todo o ciclo de vida do produto, desde a concepção,
desenvolvimento, aquisição até a entrega e manutenção. As
abordagens do CMMI envolvem a avaliação da maturidade
da organização ou a capacitação das suas áreas de processo,
o estabelecimento de prioridades e a implementação de ações
de melhorias (FERNANDES, 2008).
Estrutura do modelo
Visão Geral
O modelo possui duas abordagens: contínua e por estágios,
permitindo à organização optar pela mais adequada a seu
contexto. Atendendo a requisitos de “componentização”,
a versão 1.2 do CMMI apresenta tais abordagens reuni-
das em um mesmo documento, dentro do escopo de cada
constelação.
Uma constelação é uma coleção de componentes do CMMI
que compreende um modelo, seus materiais de treinamento
e documentos relacionados à avaliação para uma área de in-
teresse. “Adições” podem ser usadas para expandir constela-
ções com conteúdos específicos adicionais. Atualmente, três
constelações são suportadas pela versão 1.2 do CMMI:
• CMMI for Development (CMMI-DEV) – fornece diretivas
para monitoração, medição e gerenciamento de processos de
desenvolvimento. Pode ser estendido através da adição para o
Desenvolvimento Integrado de Produto e Processo (IPPD);
• CMMI for Services (CMMI-SVC) – fornece diretivas para
entrega de serviços dentro das organizações e para clientes
externos;
• CMMI for Acquisition (CMMI-ACQ) – fornece diretivas
para suporte às decisões relacionadas à aquisição de produtos
e serviços.

Componentes do Modelo
Os componentes do modelo se agrupam em três categorias
que indicam como interpretá-los:
• Componentes requeridos: descreve o que uma organização
deve realizar para satisfazer uma área de processo. Devem
ser visivelmente implementados nos processos de uma orga-
nização. Os componentes requeridos no CMMI são as metas
específicas e as metas genéricas. A satisfação das metas é
utilizada em avaliações como base para determinar se uma
área de processo foi realizada e satisfeita;
• Componentes esperados: descreve o que uma organização
pode implementar para realizar um componente requerido.
Orientam os que implementam melhorias ou executam ava-
liações. Incluem as práticas específicas e as práticas genéricas.
Antes que os objetivos possam ser considerados satisfeitos, as
práticas tal como descritas ou práticas aceitáveis alternativas
a elas, deverão estar presentes nos processos planejados e
implementados da organização;
• Componentes informativos: proporciona detalhes que aju-
dam as organizações a começar a pensar em como se aproximar
dos componentes requeridos e esperados. As sub-práticas, os
produtos de trabalho típicos, ampliações, a elaboração das
práticas genéricas, os títulos de metas e práticas, as anotações
de metas e práticas, e as referências são exemplos de compo-
nentes informativos do modelo.
A Figura 8 representa esquematicamente os componentes
e seus relacionamentos. A descrição de cada componente é
feita em seguida.
Figura 8. #OMPONENTESDA%STRUTURADO#--)&ONTE!DAPTA¥ÎO Abordagens de Implementação
METO DOLOGIAS ÁG EIS
- Áreas de Processo Relacionadas: lista referências a áreas de
processo relacionadas e reflete as relações de alto nível entre
as áreas de processo.
• Metas Específicas: são metas relacionadas a uma deter-
minada área de processo, que descrevem o que deve ser
realizado para assegurar que esta esteja definitivamente
implementada;
• Metas Genéricas: se denominam “genéricas” porque a mes-
ma declaração da meta se aplica a múltiplas áreas de processo.
Descreve as características que devem estar presentes para
institucionalizar os processos que implementam uma área
de processo;
• Práticas Específicas: descreve as atividades consideradas
importantes para alcançar uma meta específica associada.
Subcomponentes informativos:
- Produtos de Trabalho Típicos: lista exemplos de resultados
de uma prática específica.
- Subpráticas: descrições detalhadas que proporcionam uma
orientação para interpretar e implantar uma prática específica
ou genérica.
• Práticas Genéricas: se denominam “genéricas” porque a
mesma prática se aplica a múltiplas áreas de processo. Descreve
as atividades consideradas importantes para alcançar uma
meta genérica associada.
Subcomponentes informativos:
- Elaboração de Práticas Genéricas: proporciona um guia
sobre como a prática genérica deveria aplicar-se de forma
exclusiva à área de processo.
• Componentes Informativos de Suporte: informação adicio-
nal necessária para descrever um conceito. São eles:
- Notas: pode proporcionar detalhes, fundamentação teórica
ou premissas/restrições relacionadas ao componente;
- Exemplos: texto ou lista provendo um ou mais exemplos
para esclarecer um conceito ou atividade descrita;
- Ampliações: nota ou exemplo relevante para uma disciplina
particular. As disciplinas cobertas neste modelo são Engenha-
ria de Hardware, Engenharia de Sistemas e Engenharia de
Software. Cada amplificação é rotulada com um cabeçalho
que indica à qual disciplina se aplica;
- Referências: indicação para informação adicional ou mais
detalhada em áreas de processo relacionadas.
#--) Como mencionado anteriormente, o CMMI possui duas abor-
dagens. Para desenvolvimento deste artigo, utilizamos como base
• Áreas de Processo: é um grupo de práticas relacionadas que, a abordagem de implantação por estágios, devido à sua grande
quando implementadas coletivamente, satisfazem um grupo de aderência no mercado e maior proximidade com os demais mo-
objetivos considerados importantes para uma determinada área. delos CMMI que também utilizam níveis de maturidade para
Subcomponentes informativos: mensurar a qualidade dos processos organizacionais. Dessa
- Objetivo: descreve a finalidade da área de processo; maneira, daremos a esta representação um foco especial.
- Notas introdutórias: descreve os principais conceitos com- Objetivamente, podemos descrever as abordagens da se-
preendidos pela área de processo; guinte maneira:

Edição 21 - Engenharia de Software Magazine 13

• Abordagem contínua: permite que a organização selecione
uma área de processo (ou um grupo de áreas de processo)
e melhore os processos relacionados. Essa representação
utiliza seis níveis de capacidade (numerados de 0 a 5) para
caracterizar melhorias relativas a uma área de processo
individual;
• Abordagem por estágios: utiliza grupos pré-definidos de
áreas de processo (PAs) para definir um caminho de melho-
ria para uma organização. Este caminho é caracterizado por
cinco níveis de maturidade (numerados de 1 a 5). Cada nível
de maturidade contém uma série de áreas de processo que
caracteriza diferentes condutas organizacionais.
A Figura 9 ilustra a estrutura de ambas as abordagens evi-
denciando suas diferenças: níveis de capacidade x níveis de
maturidade.
Níveis de Maturidade
Para dar suporte àqueles que utilizam a abordagem por es-
tágios, todos os modelos CMMI trazem níveis de maturidade
em seu desenho e conteúdo (Figura 10).
Um nível de maturidade pode ser considerado um degrau
evolucionário para a melhoria do processo organizacional
como um todo e consistem em práticas específicas e genéricas
que integram um conjunto predefinido de áreas de processo. O
cumprimento das metas específicas e genéricas correspondentes
a estas áreas de processo é um pré-requisito para o alcance do
nível de maturidade correspondente (FERNANDES, 2008).

Figura 10. .ÓVEISDE-ATURIDADEDO#--)&ONTE!DAPTA¥ÎO#)43

A seguir são descritas as principais características de cada nível

de maturidade e as áreas de processo pertencentes aos mesmos.
Como o foco deste trabalho é relacionar as práticas do modelo
de qualidade Seis Sigma com os altos níveis de maturidade do
CMMI, os níveis 4 e 5 serão expostos de forma mais detalhada
nos próximos capítulos.
• Nível 1 – Inicial:
É o nível de maturidade mais baixo. Em geral, as organizações
desse nível têm processos imprevisíveis que são pobremente
controlados e reativos. Nesse nível de maturidade os processos
são normalmente “ad hoc” e caóticos. A organização geralmente
não fornece um ambiente estável.
Áreas de Processo: Não há.
Figura 9. %STRUTURASDASABORDAGENSCONTÓNUAEPORESTÉGIOS&ONTE
• Nível 2 – Gerenciado:
!DAPTA¥ÎO#--)
Neste nível, o foco é o gerenciamento básico de projetos da or-
A Tabela 2 faz uma comparação entre os seis níveis de ca- ganização, proporcionando-lhes a garantia de que os requisitos
pacidade e os cinco de maturidade. Como se pode observar, o são gerenciados, planejados, executados, medidos e controlados.
ponto de início é diferente para as duas implementações, visto Quando essas práticas são adequadas, os projetos são executados
que não há nível 0 para a abordagem por estágios. e controlados de acordo com o planejado.
Áreas de Processo: Gestão de Requisitos (REQM), Planejamento
Níveis de Capacidade da Abordagem Níveis de Maturidade da do Projeto (PP), Controle e Monitoração do Projeto (PMC), Gestão
Nível
Contínua Abordagem por Estágios do Acordo com o Fornecedor (SAM), Medição e Análise (MA),
Nível 0 Incompleto --- Garantia da Qualidade de Processo e do Produto (PPQA) e Gestão
Nível 1 Executado Inicial da Configuração (CM).
• Nível 3 – Definido:
Nível 2 Gerenciado Gerenciado
Neste nível, processos são bem caracterizados, compreendidos e
Nível 3 Definido Definido
descritos em padrões, procedimentos, ferramentas e métodos. O
Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente conjunto de processos padrão da organização, que é a base para
Nível 5 Otimizado Otimizado o nível 3 de maturidade, é estabelecido e melhorado ao longo do
Tabela 2.#OMPARA¥ÎODOSNÓVEISDECAPACIDADEEMATURIDADE&ONTE tempo. Esses processos padronizados são usados para estabelecer
!DAPTA¥ÎO#--) consistência em toda a organização. Todos os projetos utilizam

14 Engenharia de Software Magazine - Seis Sigma e CMMI

 METO DOLOGIAS ÁG EIS

uma versão de um desses processos padrão adaptando-a às suas

características especificas.
Áreas de Processo: Desenvolvimento de Requisitos (RD), Solução
Técnica (TS), Integração do Produto (PI), Verificação (VER), Vali-
dação (VAL), Foco no Processo Organizacional (OPF), Definição
do Processo Organizacional (OPD), Treinamento Organizacional
(OT), Gestão Integrada do Projeto (IPM), Gestão de Riscos (RSKM),
Análise de Decisões e Resolução (DAR).

• Nível 4 – Gerenciado Quantitativamente:

A gestão quantitativa baseada em medições e indicadores cobre,
de forma integrada, todo o conjunto de processos organizacionais,
assim como os projetos e respectivos produtos, como instrumento
de suporte para o atendimento dos objetivos de desempenho de
processo e de qualidade. Os projetos e seus produtos assim como
o processo organizacional, são controlados estatisticamente.
Áreas de Processo:
- Desempenho do Processo Organizacional (OPP) – Tem por
objetivos: estabelecer e manter uma visão quantitativa do de-
sempenho dos processos padrões, e prover modelos e baselines
de desempenho, visando melhorar a gestão dos projetos através
de métricas de processo e produto.
- Gestão Quantitativa do Projeto (QPM) – Tem por objetivo geren-
ciar quantitativamente (através de métricas) o processo definido
do projeto, visando o alcance dos objetivos preestabelecidos de
desempenho de qualidade e processo.
• Nível 5 – Otimizado:
Neste nível, os processos são continuamente aperfeiçoados com
base em um entendimento quantitativo no qual a variação de um
processo existe devido às interações, normais e presumidas, entre
seus componentes. Esse nível de maturidade tem como objetivo
a melhoria contínua do processo.
Áreas de Processo:
- Inovação e Desenvolvimento Organizacional (OID) – Tem por
objetivo selecionar e implantar melhorias incrementais e inova-
ções nos processos e nas tecnologias que promovam, quantitati-
vamente, o aumento da habilidade da organização para cumprir
os seus objetivos de desempenho de processos e qualidade.
- Análise e Resolução de Causas (CAR) – Tem por objetivo
identificar causas de defeitos e outros problemas e tomar ações
corretivas para prevenir a sua ocorrência futura.
A Figura 11 representa de forma resumida, os níveis de maturi-
dade, seus principais focos e áreas de processo envolvidas.
Figura 11. Os Níveis de Maturidade e suas Áreas de Processo
Benefícios do Modelo
A utilização do modelo CMMI inclui uma série de bene-
fícios significativos e quantificáveis para a organização
que o utiliza na melhoria de seus processos e podem ser
categorizados e resumidos por: custo, prazo, produtivi-
dade, qualidade, satisfação dos clientes e Retorno sobre o
Investimento (ROI – Return on Investment).
Em 2006, o SEI publicou um relatório técnico (Perfor-
mance Results of CMMI - Based Process Improvement)
apresentando dados quantitativos de 35 organizações,
entre elas grandes empresas com mais de uma organiza-
ção constituinte (SEI, 2006). Os esforços no processo de
melhoria dessas organizações incluem tanto pequenas
como grandes unidades organizacionais que atuam em
uma variedade de setores e domínios do mercado. Foram
aplicadas as práticas do modelo CMMI para engenharia
de software, engenharia de sistemas, e outras disciplinas
de engenharia. Enquanto a maioria dos resultados vem
de organizações de maior maturidade, melhorias notáveis
também foram alcançadas pelas organizações de menor
maturidade. Todas as organizações no relatório explici-
tamente atribuem suas realizações a orientação fornecida
pelo CMMI.
A Tabela 3 resume a média percentual de melhorias nas
cinco categorias apresentadas.

Categoria Percentual Médio Exemplos

Custo Redução de 34% Redução dos custos de retrabalho, remoção de defeitos, overhead de projetos.
Prazo Melhoria de 50% Redução do número de dias de atraso de aproximadamente 50 para menos de 10.
Produtividade Aumento de 61% Aumento na quantidade de linhas de código por pessoa/dia, aumento do número de releases de software liberados por ano.
Qualidade Aumento de 48% Redução dos defeitos encontrados e das requisições de mudança no sistema em ambiente de produção.
Satisfação dos Clientes Aumento de 14% Aumento em 55% comparado ao SW-CMM nível 2 e 10% comparado ao nível 5.
Retorno sobre o Investimento 4,0 : 1 Retorno de 5:1 em relação às horas investidas em atividades de qualidade.

Tabela 3. "ENEFÓCIOS1UANTITATIVOSDA5TILIZA¥ÎODO#--)&ONTE!DAPTA¥ÎO3%)

Edição 21 - Engenharia de Software Magazine 15