Modelos de Qualidade de Software

Prévia do material em texto

90
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Unidade IV
5
10
15
20
4 MODELOS DE QUALIDADE DE SOFTWARE
4.1 Introdução
As mudanças que estão ocorrendo nos clientes e nos 
ambientes de negócios altamente competitivos têm motivado 
as empresas a modificarem estruturas organizacionais e seus 
processos produtivos na área de software. Todavia, alcançar a 
competitividade pela qualidade implica tanto na melhoria da 
qualidade dos produtos de software e serviços correlatos, como 
dos processos de produção e distribuição de software.
Como vem acontecendo com as empresas de outros 
setores, como, por exemplo, a indústria automobilística, as 
empresas de serviços da área médica, a indústria aeronáutica 
etc., a qualidade tem se tornado fator crítico de sucesso 
para a indústria de software. De acordo com o modelo MPS.
BR (Melhoria de Processo do Software Brasileiro), para que o 
Brasil possua um setor de software competitivo, nacional e 
internacionalmente, é essencial que os empreendedores do 
setor coloquem a eficiência e a eficácia dos seus processos em 
foco nas empresas, visando a oferta de produtos de software 
e serviços correlatos conforme padrões (normas e modelos) 
internacionais de qualidade.
Neste módulo serão apresentados os três principais 
modelos de qualidade de software que têm como foco a 
melhoria contínua da qualidade nos processos e produtos 
de software: o modelo MPS.BR, o modelo ISO/IEC 15504 e o 
modelo CMMI-DEV.
91
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
4.2 O modelo MPS.BR
4.2.1 Introdução
Conforme o manual do MPS.BR, o foco principal do modelo 
brasileiro, é atender ao perfil de empresas com diferentes 
tamanhos e características, públicas e privadas, embora com 
especial atenção às micro, pequenas e médias empresas. Outro 
fator importante é que ele seja compatível com os padrões 
de qualidade aceitos internacionalmente e que tenha como 
pressuposto o aproveitamento de toda a competência existente 
nos padrões e modelos de melhoria de processo já disponíveis.
Dessa forma, ele tem como base os requisitos de processos 
definidos nos modelos de melhoria de processo. O MPS.BR 
atende à necessidade de implantar os princípios de engenharia 
de software de forma adequada ao contexto das empresas 
brasileiras, estando em consonância com as principais 
abordagens internacionais para definição, avaliação e melhoria 
de processos de software.
Como em outros modelos internacionais, o MPS.BR baseia-
se nos conceitos de maturidade e capacidade de processo para a 
avaliação e melhoria da qualidade e produtividade de produtos 
de software e serviços correlatos. Para atender a esses serviços, 
o MPS.BR foi organizado em três componentes: Modelo de 
Referência (MR-MPS4), Método de Avaliação (MA-MPS4) e 
Modelo de Negócio (MN-MPS4).
4.2.2 Descrição geral do MPS.BR
O MPS.BR é um programa brasileiro de qualidade de software 
lançado em dezembro de 2003, coordenado pela Associação 
para Promoção da Excelência do Software Brasileiro (Softex). O 
programa conta com investimentos das empresas, da Softex, por 
meio do Banco Interamericano de Desenvolvimento (BID), e de 
outros parceiros como o Sebrae e o CNPq.
5
10
15
20
25
92
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
O MPS.BR está descrito através de documentos em formato 
de guias: o guia geral que contém a descrição geral do MPS.BR e 
detalha o Modelo de Referência (MR-MPS) com seus componentes 
e as definições comuns necessárias para seu entendimento e 
aplicação; o guia de aquisição que contém recomendações para 
a condução de compras de software e serviços correlatos e que 
foi descrito como forma de apoiar as instituições brasilerias que 
queiram adquirir produtos de software e serviços correlatos 
apoiando-se no MR-MPS; o guia de implementação que contém 
orientações para a implementação dos sete níveis do Modelo 
de Referência MR-MPS; e o guia de avaliação que descreve o 
processo e o Método de Avaliação MA-MPS, tendo como base a 
norma internacional ISO/IEC 15504 (Guerra & Colombo, 2009).
O MPS.BR tambem é um programa brasileiro de qualificação 
e certificação de empresas em processos de melhoria de 
qualidade de software. Ele atesta a excelência dos processos 
de desenvolvimento, engenharia, manutenção e aquisição de 
software em uma empresa, a um custo muito inferior ao similar 
internacional: o CMMI (Capability Maturity Model Integrated).
4.2.3 Objetivos do MPS.BR
O modelo MPS.BR visa à melhoria de processos de software 
em empresas brasileiras, a um custo acessível, especialmente 
na grande massa de micro, pequenas e médias empresas e tem 
como objetivos:
• definir o Modelo de Referência para melhoria de processo 
de software (MR-MPS) para aplicação nas empresas 
brasileiras;
• disseminar o modelo, em diversos locais do país, da 
seguinte forma:
- a capacitação no uso do modelo;
- o credenciamento de instituições implementadoras e 
avaliadoras do modelo, especialmente instituições de 
ensino e centros tecnológicos;
5
10
15
20
25
30
93
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
- a implementação e avaliação do modelo com foco em 
grupos de empresas.
A figura 10 apresenta uma visão do modelo MPS.BR e nela 
tem-se um padrão de definição e implementação do modelo: a 
partir de uma avaliação da realidade das empresas brasileiras e 
com o apoio da Softex, do governo e de universidades monta-se 
o modelo brasileiro de qualidade de software. Este modelo foi 
inspirado nos modelos internacionais CMMI da SEI (Software 
Engineering Institute) e do padrão ISO 15504 (também 
denominado de SPICE).
Para a implementação do modelo nas empresas brasileiras 
foram definidos dois tipos de instituições:
• Instituições Credenciadas para Implementação (ICI), que 
têm como função o preparo das empresas para o uso do 
modelo;
• Instituições Credenciadas para Avaliação (ICA), que têm 
como foco a avaliação das empresas com relação à sua 
maturidade no desenvolvimento e na manutenção de 
software.
Figura 10: Modelo para melhoria do processo de software 
brasileiro (componentes do modelo) – MPS.BR
Guia geral
Guia de 
aquisição
Guia de 
avaliação
Guia de 
implementação
Documentos 
do programa
Modelo de 
referência 
(MR-MPS)
Modelo de 
avaliação 
(MA-MPS)
Modelo de 
negócios 
(MN-MPS)
CMMI-DEV
ISO/IEC 12207
SPICE (ISO/IEC 15504)
Modelo MPS.BR
5
10
15
20
94
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
A base técnica para a construção e o aprimoramento deste 
modelo de melhoria e avaliação de processo de software é 
composta pelas normas ISO/IEC 12207:2008 (ISO/IEC, 2008ª) 
e ISO/IEC 15504-2 (ISO/IEC, 2003). Uma avaliação MPS é 
realizada utilizando o processo e o método de avaliação MA-
MPS descritos no guia de avaliação. Uma avaliação MPS verifica 
a conformidade de uma organização/unidade organizacional 
aos processos do MR-MPS. O modelo MPS é definido em 
consonância com a norma internacional ISO/IEC 12207:2008, 
adaptando-a às necessidades da comunidade de interesse.
O modelo CMMI foi desenvolvido no SEI (Software 
Engineering Institute) a pedido do Departamento de Defesa dos 
Estados Unidos. Além disso, o framework CMMI foi desenvolvido 
para ser consistente e compatível com a ISO/IEC 15504. Em 2006, 
foi publicada a versão 1.2 do CMMI®, o CMMI-DEV® (CMMI for 
Development) (SEI, 2006).
4.2.4 Os níveis de maturidade do modelo MPS.BR
Conforme descrito no modelo MPS.BR, os níveis de 
maturidade estabelecem patamares de evolução de processos, 
caracterizando estágios de melhoria da implementação de 
processos na organização. O nível de maturidade em que se 
encontra uma organização permite prever o seu desempenho 
futuro ao executar um ou mais processos.
O MR-MPS define sete níveis de maturidade:
A. em otimização;B. gerenciado quantitativamente;
C. definido;
D. largamente definido;
E. parcialmente definido;
5
10
15
20
25
95
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
F. gerenciado;
G. parcialmente gerenciado.
A escala de maturidade se inicia no nível G e progride até o 
nível A. Para cada um destes sete níveis de maturidade é atribuído 
um perfil de processos que indica onde a organização deve 
colocar o esforço de melhoria. O progresso e o alcance de um 
determinado nível de maturidade do MR-MPS se obtêm quando 
são atendidos os propósitos e todos os resultados esperados dos 
respectivos processos e os resultados esperados dos atributos de 
processo estabelecidos para aquele nível.
A divisão em sete estágios tem o objetivo de possibilitar uma 
implementação e uma avaliação adequadas às micros, pequenas 
e médias empresas. A possibilidade de se realizar avaliações, 
considerando mais níveis também permite uma visibilidade dos 
resultados de melhoria de processos em prazos mais curtos.
Os níveis de maturidade devem ser entendidos na sua 
complexidade de forma inversa às letras que os compõem, isto 
é, as empresas iniciam no nível G e vão ao longo do tempo 
evoluindo em direção ao nível A, que indica as empresas com o 
maior nível de maturidade.
Nível G – Parcialmente gerenciado
Este nível apresenta duas áreas de processo, conforme mostra 
a tabela 1. O nível G é composto pelos processos: Gerência de 
Projetos e Gerência de Requisitos.
Tabela 1: Nível G de maturidade do modelo MPS.BR
Áreas de processo Objetivos
Gerência de 
Requisitos – GRE
O propósito do processo Gerência de Requisitos é 
gerenciar os requisitos do produto e dos componentes do 
produto do projeto e identificar inconsistências entre os 
requisitos, os planos do projeto e os produtos de trabalho 
do projeto.
5
10
15
20
25
96
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Gerência de 
Projetos – GPR
O propósito do processo Gerência de Projetos é 
estabelecer e manter planos que definem as atividades, 
recursos e responsabilidades do projeto, bem como prover 
informações sobre o andamento do projeto que permitam 
a realização de correções quando houver desvios 
significativos no desempenho do projeto.
O propósito deste processo evolui à medida que a 
organização cresce em maturidade. Assim, a partir 
do nível E, alguns resultados evoluem e outros são 
incorporados, de forma que a gerência de projetos passa 
a ser realizada com base no processo definido para o 
projeto e nos planos integrados. No nível B, a gerência de 
projetos passa a ter um enfoque quantitativo, refletindo 
a alta maturidade que se espera da organização. 
Novamente, alguns resultados evoluem e outros são 
incorporados.
Nível F – Gerenciado
Este nível apresenta cinco áreas de processo, conforme mostra 
a tabela 2. O nível de maturidade F é composto pelos processos 
do nível de maturidade anterior (G) acrescidos dos processos 
Aquisição, Garantia da Qualidade, Gerência de Configuração, 
Gerência de Portfólio de Projetos e Medição.
Tabela 2: Nível F de maturidade do modelo MPS.BR
Áreas de processo Objetivos
Aquisição – AQU
O propósito do processo Aquisição é gerenciar a 
aquisição de produtos que satisfaçam às necessidades 
expressas pelo adquirente.
Gerência de 
Configuração 
– GCO
O propósito do processo Gerência de Configuração é 
estabelecer e manter a integridade de todos os produtos 
de trabalho de um processo ou projeto e disponibilizá-los 
a todos os envolvidos.
Garantia da 
Qualidade – GQA
O propósito do processo Garantia da Qualidade é 
assegurar que os produtos de trabalho e a execução 
dos processos estejam em conformidade com os planos, 
procedimentos e padrões estabelecidos.
Gerência de 
Portfólio de 
Projetos – GPP
O propósito do processo Gerência de Portfólio de Projetos 
é iniciar e manter projetos que sejam necessários, 
suficientes e sustentáveis, de forma a atender aos 
objetivos estratégicos da organização. Este processo 
compromete o investimento e os recursos organizacionais 
adequados e estabelece a autoridade necessária 
para executar os projetos selecionados. Ele executa a 
qualificação contínua de projetos para confirmar que eles 
justificam a continuidade dos investimentos, ou podem ser 
redirecionados para justificar.
5
97
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Medição – MED
O propósito do processo Medição é coletar, armazenar, 
analisar e relatar os dados relativos aos produtos 
desenvolvidos e aos processos implementados na 
organização e em seus projetos, de forma a apoiar os 
objetivos organizacionais.
Nível E – Parcialmente definido
Este nível apresenta quatro áreas de processo, conforme 
mostra a tabela 3. O nível de maturidade E é composto pelos 
processos dos níveis de maturidade anteriores (G e F), acrescidos 
dos processos Avaliação e Melhoria do Processo Organizacional, 
Definição do Processo Organizacional, Gerência de Recursos 
Humanos e Gerência de Reutilização. O processo Gerência 
de Projetos sofre sua primeira evolução, retratando seu novo 
propósito: gerenciar o projeto com base no processo definido 
para o projeto e nos planos integrados.
Tabela 3: Nível E de maturidade do modelo MPS.BR
Áreas de processo Objetivos
Avaliação e Melhoria do 
Processo Organizacional 
– AMP
O propósito do processo Avaliação e Melhoria do 
Processo Organizacional é determinar o quanto os 
processos-padrão da organização contribuem para 
alcançar os objetivos de negócio da organização 
e para apoiar a organização a planejar, realizar e 
implantar melhorias contínuas nos processos com 
base no entendimento de seus pontos fortes e 
fracos.
Definição do Processo 
Organizacional – DFP
O propósito do processo Definição do Processo 
Organizacional é estabelecer e manter um 
conjunto de ativos de processo organizacional 
e padrões do ambiente de trabalho usáveis 
e aplicáveis às necessidades de negócio da 
organização.
Gerência de Recursos 
Humanos – GRH
O propósito do processo Gerência de Recursos 
Humanos é prover a organização e os projetos 
com os recursos humanos necessários e manter 
suas competências adequadas às necessidades do 
negócio.
Gerência de Reutilização 
– GRU
O propósito do processo Gerência de Reutilização 
é gerenciar o ciclo de vida dos ativos reutilizáveis.
5
10
98
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Nível D – Largamente definido
Este nível apresenta cinco áreas de processo, conforme 
mostra a tabela 4. O nível de maturidade D é composto 
pelos processos dos níveis de maturidade anteriores (G ao 
E), acrescidos dos processos Desenvolvimento de Requisitos, 
Integração do Produto, Projeto e Construção do Produto, 
Validação e Verificação.
Tabela 4: Nível D de maturidade do modelo MPS.BR
Áreas de processo Objetivos
Desenvolvimento de 
Requisitos – DRE
O propósito do processo Desenvolvimento de 
Requisitos é definir os requisitos do cliente, do 
produto e dos componentes do produto.
Integração do Produto 
– ITP
O propósito do processo Integração do Produto é 
compor os componentes do produto, produzindo 
um produto integrado consistente com seu projeto, 
e demonstrar que os requisitos funcionais e não 
funcionais são satisfeitos para o ambiente-alvo ou 
equivalente.
Projeto e Construção 
do Produto – PCP
O propósito do processo Projeto e Construção do 
Produto é projetar, desenvolver e implementar 
soluções para atender aos requisitos.
Validação – VAL
O propósito do processo Validação é confirmar que 
um produto ou componente do produto atenderá a 
seu uso pretendido quando colocado no ambiente 
para o qual foi desenvolvido.
Verificação – VER
O propósito do processo Verificação é confirmar que 
cada serviço e/ou produto de trabalho do processo 
ou do projeto atende apropriadamente aos requisitos 
especificados.
Nível C – DefinidoEste nível apresenta três áreas de processo, conforme mostra 
a tabela 5. O nível de maturidade C é composto pelos processos 
dos níveis de maturidade anteriores (G ao D), acrescidos dos 
processos Desenvolvimento para Reutilização, Gerência de 
Decisões e Gerência de Riscos.
5
10
99
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Tabela 5: Nível C de maturidade do modelo MPS.BR
Áreas de processo Objetivos
Desenvolvimento para 
Reutilização – DRU
O propósito do processo Desenvolvimento para 
Reutilização é identificar oportunidades de 
reutilização sistemática de ativos na organização 
e, se possível, estabelecer um programa de 
reutilização para desenvolver ativos a partir de 
engenharia de domínios de aplicação.
Gerência de Decisões 
– GDE
O propósito do processo Gerência de Decisões 
é analisar possíveis decisões críticas usando um 
processo formal, com critérios estabelecidos, para 
avaliação das alternativas identificadas com seu 
projeto, e demonstrar que os requisitos funcionais 
e não funcionais são satisfeitos para o ambiente-
alvo ou equivalente.
Gerência de Riscos – GRI
O propósito do processo Gerência de Riscos é 
identificar, analisar, tratar, monitorar e reduzir 
continuamente os riscos em nível organizacional e 
de projeto.
Nível B – Gerenciado quantitativamente
Este nível de maturidade é composto pelos processos dos 
níveis de maturidade anteriores (G ao C). Neste nível o processo 
de Gerência de Projetos sofre sua segunda evolução (Gerência 
de Projetos – GPR), sendo acrescentados novos resultados para 
atender aos objetivos de gerenciamento quantitativo. Neste nível 
a implementação dos processos deve satisfazer aos atributos dos 
processos: o processo é executado, o processo é gerenciado, os 
produtos de trabalho do processo são gerenciados, o processo é 
definido, o processo está implementado e o processo é otimizado 
continuamente. A implementação dos processos selecionados 
para análise de desempenho deve satisfazer integralmente 
aos atributos de processo: o processo é medido e o processo é 
controlado. Este nível não possui processos específicos.
Nível A – Em otimização
Este nível de maturidade é composto pelos processos 
dos níveis de maturidade anteriores (G ao B). Neste nível a 
5
10
15
100
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
implementação dos processos deve satisfazer aos atributos de 
processo: o processo é executado, o processo é gerenciado, os 
produtos de trabalho do processo são gerenciados, o processo é 
definido, o processo está implementado e o processo é medido. 
A implementação dos processos selecionados para análise 
de desempenho deve satisfazer integralmente aos atributos 
de processo: o processo é medido e o processo é controlado. 
Os atributos de processo: o processo é medido e controlado; 
o processo é objeto de melhorias e inovações; e o processo é 
otimizado continuamente. Este nível não possui processos 
específicos.
4.3 O modelo ISO/IEC 15504 (Software 
Process Assesment)
4.3.1 Introdução
O modelo ou norma ISO/IEC 15504 foi criado para 
harmonizar as diferentes abordagens de avaliação do processo 
de software. O modelo ou norma ISO/IEC 15504 também é 
conhecido como projeto SPICE para avaliação de processos de 
software.
SPICE significa Software Process Improvement and Capability 
dEtermination e tem como objetivo produzir um relatório mais 
geral e abrangente que os modelos existentes e mais específico 
que a norma ISO 9001.
4.3.2 Objetivos da ISO/IEC 15504
O modelo tem dois objetivos:
• a melhoria dos processos;
• a determinação da capacidade de processos de uma 
organização.
5
10
15
20
101
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Se uma organização tem por objetivo a melhoria de seus 
processos, a norma permite avaliar os processos e, a partir dessa 
avaliação, elaborar um plano de melhorias. A figura 11 mostra o 
uso da ISSO/IEC 15504 para a melhoria de processos.
Figura 11: Aplicação da ISO/IEC 15504 para melhoria de 
processos
Melhoria de 
processos
Avaliação de 
processos
Pedido
Registro e 
perfis de 
capacidade
Contexto, 
restrições e 
objetivos
Modelos e 
métodos
Melhorias 
institucionalizadas
Necessidades 
da organização 
e metas
Se a organização tem como objetivo avaliar um fornecedor 
obtendo o seu perfil de capacidade, ela deve definir os objetivos 
e o contexto da avaliação, como mostra a figura 12. O perfil de 
capacidade permite à organização contratante avaliar os riscos 
associados à contratação desse fornecedor.
Figura 12: Aplicação da ISO/IEC 15504 para a determinação 
da capacidade
Determinação 
da capacidade do 
processo
Avaliação de 
processo
Pedido
Registro e 
perfis de 
capacidade
Contexto, 
restrições e 
objetivos
Modelos e 
métodos
Relatório de 
capacidade
Requisitos
5
10
102
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Os manuais da norma ou modelo 15504 têm nove partes 
(Cortês & Chiossi, 2001):
Parte 1 – Informativa: conceitos e guia introdutório.
Parte 2 – Normativa: um modelo de referência para 
processos e capacidade de processos. Descreve o modelo 
de duas dimensões – a dimensão processo e a dimensão 
capacidades de processos.
Parte 3 - Normativa: realizando uma avaliação. Contém 
os requisitos para a realização de uma avaliação de tal 
maneira que os resultados sejam repetíveis.
Parte 4 – Informativa: guia para realização de avaliações. 
Fornece orientações para uma avaliação em vários 
contextos.
Parte 5 – Informativa: um modelo de avaliação e guia de 
indicadores. Fornece um modelo de referência detalhado 
para a realização de uma avaliação.
Parte 6 – Informativa: guia para competência de 
assessores. Descreve os requisitos para a qualificação de 
avaliadores.
Parte 7 – Informativa: guia para uso em melhoria de 
processos. Apresenta orientações para o uso do modelo 
para fins de melhoria de processos.
Parte 8 – Informativa: guia para uso na determinação 
da capacidade de processos de fornecedores. Apresenta 
orientações para o uso do modelo para fins de avaliação 
da capacidade de um fornecedor em potencial.
Parte 9 – Informativa: vocabulário utilizado na norma.
5
10
15
20
25
103
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
O modelo de referência parte 2 documenta um conjunto 
universal de processos da engenharia de software que são 
fundamentais para uma boa engenharia de software, cobrindo 
as atividades de melhores práticas. Ele descreve processos 
que uma organização pode realizar para adquirir, fornecer, 
desenvolver e operar software e os atributos de processos que 
caracterizam a capacidade desses processos. O propósito do 
modelo de referência é fornecer uma base comum para modelos 
e métodos diferentes para avaliação de processos de software, 
garantindo que os resultados de avaliação possam ser relatados 
num contexto comum.
4.3.3 As dimensões do modelo de referência
A arquitetura do modelo de referência é de duas dimensões:
–1. A dimensão processo
É caracterizada pela declaração dos propósitos do 
processo, que são os objetivos essenciais e quantificáveis de 
um processo.
Essa dimensão foi fortemente baseada na norma ISO/IEC 
12207. Ela apresenta cinco categorias de processos, conforme 
apresentadas na figura 13, e suas siglas são:
• CUS (customer-supplier) – cliente-fornecedor: estão nessa 
categoria os processos que afetam diretamente o cliente, 
desde a aquisição, fornecimento, instalação e assistência 
técnica.
• ENG (engineering) – engenharia de software: esse grupo 
de processo tem o objetivo de transformar requisitos 
em um produto de software e foi subdividido em sete 
subprocessos ou componentes.
5
10
15
20
25
104
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/201
0
• SUP (support) – apoio: os processos de apoio ou suporte, 
em número de oito, podem ser usados por quaisquer dos 
demais processos em qualquer ponto do ciclo de vida do 
software.
• MAN (management) – gestão: essa categoria consiste de 
quatro processos que contêm práticas de natureza geral, 
afetando qualquer pessoa que execute tarefas gerenciais, 
em qualquer ponto do ciclo de vida.
• ORG (organization) – organização: essa categoria de 
processos consiste de seis processos associados às 
atividades gerais da organização, desde os objetivos do 
negócio até a gestão de recursos humanos.
Figura 13: Estrutura ou arquitetura da dimensão de 
processos
Processos organizacionais
Processos primários
CUS.1 - Aquisição
CUS.2 - Fornecimento
CUS.3 - Elicitação de requisitos
CUS.4 - Operação
ENG.1 - Desenvolvimento
ENG.2 - Manutenção
MAN.1 - Gestão
MAN.2 - Gestão de projeto
MAN.3 - Gestão da qualidade
MAN.4 - Gestão de risco
Processos de apoio
SUP.1 - Documentação
SUP.2 - Gestão configuração
SUP.3 - SQA
SUP.4 - Verificação
SUP.5 - Validação
SUP.6 - Revisão
SUP.7 - Auditoria
SUP.8 - Solução de problemas
ORG. 1 - Alinhamento
ORG. 2 - Melhoria
ORG. 3 - RH
ORG. 4 - Infraestrutura
ORG. 5 - Medidas
ORG. 5 - Reuso
5
10
105
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
2. A dimensão de capacidade de processo
Estabelece uma escala de capacidade de processo em geral. 
A capacidade é definida em uma escala de seis níveis crescentes, 
desde o nível inferior, o nível 0, até o nível superior, o nível 5.
Esses níveis são caracterizados por uma série de atributos 
de processo aplicáveis para qualquer processo, que representam 
características quantificáveis necessárias para gerenciar um 
processo e melhorar sua capacidade de realização. Cada atributo 
de processo descreve um aspecto de todas as capacidades de 
gerenciamento e melhoria da efetividade de um processo 
na busca de seus propósitos e contribuição para as metas de 
negócio da organização.
Há nove atributos de processo (PA) que são agrupados nos 
níveis de capacidade, como mostrado na figura 14.
Figura 14: Os atributos de processo e os seis níveis de 
capacidade
Atributos 
de processo
Níveis de capacidade – nomes dos 
atributos de processo
Nível 0 - Incompleto
Nível 1 - Executado
PA 1.1 Atributo de execução de processo
Nível 2 - Gerenciado
PA 2.1 Atributo de gestão de execução
PA 2.2 Atributo de gestão de produto de trabalho
Nível 3 - Estabelecido
PA 3.1 Atributo de definição de processo
PA 3.2 Atributo de recursos de processo
Nível 4 - Previsível
PA 4.1 Atributo de definição de processo
PA 4.2 Atributo de recursos de processo
Nível 5 – Em Otimização
PA 5.1 Atributo de mudança de processo
PA 5.2 Atributo de melhoria contínua
5
10
15
106
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Os níveis de capacidade constituem uma maneira racional 
de progredir na melhoria da capacidade dos processos. Esses 
níveis são conceitualmente os mesmos níveis de maturidade 
do modelo CMM, embora aplicados para o processo em vez da 
organização.
Nível 0 – Incompleto: o processo falha no seu propósito, 
pois não existe uma clara identificação dos produtos ou 
saídas do processo em que os resultados sejam realmente 
alcançados.
Nível 1 – Executado: o propósito do processo é 
geralmente alcançado. A realização do processo não é 
rigorosamente planejada e controlada. Todavia, existem 
produtos.
Nível 2 – Gerenciado: o processo fornece produtos 
de trabalho de acordo com os procedimentos 
especificados, planejados e controlados. Os produtos de 
trabalho são gerados conforme os padrões e requisitos 
especificados.
Nível 3 – Estabelecido: o processo é realizado e 
gerenciado usando um processo definido com base 
nos bons princípios de engenharia de software. 
Implementações individuais do processo usam versões 
adaptadas e aprovadas do processo-padrão para alcançar 
os resultados do processo.
Nível 4 – Previsível: o processo definido é executado de 
forma consistente na prática, definindo limites de controle 
para atingir os objetivos processo.
Nível 5 – Em otimização: o desempenho do processo é 
otimizado para atender às necessidades de negócios atuais 
e futuros. O processo atinge repetibilidade na realização 
dos objetivos dos negócios definidos.
5
10
15
20
25
30
107
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Conforme Côrtes & Chiossi (2001), a filosofia do SPICE 
(ISO/IEC 15504) baseia-se na verificação do grau de satisfação 
dos atributos de processos (PAs) apresentados na figura 14. A 
pontuação é feita em uma escala ordenada de quatro valores, 
escolhidos de acordo com um percentual de atendimento aos 
requisitos do atributo de processo, os quatro valores são: N (não 
atendido – 0% a 15%); P (parcialmente atendido – 16% a 50%); 
L (largamento atendido – 51% a 85%) e T (totalmente atendido 
– 86% a 100%).
4.3.4 Conclusão
Pode-se dizer que o SPICE é o modelo que herda e deverá 
substituir a ISO/IEC 12207, sob pressão do CMM/CMMI e de 
outros modelos. Ele se encontra mais distante da ISO 9001 do 
que a ISO/IEC 12207 e do que o CMM/CMMI, apesar de ser um 
projeto da ISO (Côrtes & Chiossi, 2001).
4.4 O modelo CMMI-DEV adpatado do manual 
CMU/SEI-2006-TR-008
ESC-TR-2006-008 - improving processes for better 
products
4.4.1 Introdução
Agora, mais do que nunca, as empresas querem oferecer 
produtos e serviços melhores, mais rápidos e mais baratos. Ao 
mesmo tempo, no ambiente de alta tecnologia do século XXI 
quase todas as organizações têm construído cada vez mais 
produtos e serviços complexos. Hoje, uma única empresa 
geralmente não desenvolve todos os componentes que 
compõem um produto ou serviço. Mais comumente, alguns 
componentes são construídos em casa, alguns são adquiridos 
no mercado e todos os componentes são integrados no produto 
ou serviço final.
5
10
15
20
25
108
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
As organizações devem ser capazes de gerir e controlar 
este processo complexo de desenvolvimento e manutenção. 
Os problemas destas organizações apontadas nos dias de 
hoje envolvem soluções para toda a empresa, que exigem 
uma abordagem integrada. Uma gestão eficaz dos ativos da 
organização é fundamental para o sucesso empresarial. No 
mercado atual, existem modelos de maturidade, normas, 
metodologias e diretrizes que podem ajudar uma organização 
a melhorar a forma como faz negócios. No entanto, as mais 
disponíveis concentram-se em uma parte específica do negócio 
e não têm uma abordagem sistêmica para os problemas que a 
maioria das organizações estão enfrentando. Ao se concentrar 
em melhorar uma área de uma empresa, estes modelos 
têm, infelizmente, perpetuado as barreiras que existem nas 
organizações.
O Capability Maturity Model ® Integration (CMMI ®) oferece 
uma oportunidade para evitar ou eliminar esses obstáculos por 
meio de modelos integrados que transcendem as disciplinas. 
O modelo CMMI-DEV para o desenvolvimento é constituído 
pelas melhores práticas que as atividades de desenvolvimento 
e manutenção indicam como aplicadas aos produtos e 
serviços. Dirige-se a práticas que cobrem o ciclo de vida do 
produto desde a concepção até a entrega e manutenção. A 
ênfase é sobre o trabalho necessário para construir e manter 
um produto total.
Em sua pesquisa para ajudar as organizações a desenvolver 
e manter a qualidade de produtos e serviços, o Software 
Engineering Institute (SEI) tem encontrado várias dimensões 
nas quais uma organização pode se concentrar para melhorar 
seus negócios.
A Figura 15 ilustra as três dimensões críticas nas quais as 
organizações geralmente se concentram: pessoas; processos e 
métodos; e ferramentas e equipamentos.
5
10
15
20
25
30
109
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gram
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Figura 15: As três dimensões críticas
Ferramentas e 
equipamentos
B
D
C
A
Procedimentos e métodos, 
definindo as relações de tarefas
Pessoas com habilidades 
e motivação
Mas o que mantém tudo isso junto? Trata-se dos processos 
utilizados na organização. Processos permitem alinhar a 
maneira de fazer negócios. Eles permitem que se aponte 
para a escalabilidade e fornece uma maneira de incorporar 
conhecimento de como fazer as coisas melhor. Processos 
permitem alavancar recursos e examinar as tendências de 
negócios. Isso não quer dizer que as pessoas e a tecnologia não 
são importantes. Vive-se em um mundo onde a tecnologia está 
mudando por uma ordem de magnitude a cada dez anos. Da 
mesma forma, as pessoas normalmente trabalham para muitas 
empresas ao longo das suas carreiras, ou seja, vive-se em um 
mundo dinâmico. O foco no processo fornece a infraestrutura 
necessária para lidar com uma supramudança do mundo e para 
maximizar a produtividade das pessoas e do uso de tecnologia 
para ser mais competitivo.
A Manufara há muito reconheceu a importância da 
eficácia e eficiência do processo. Hoje, muitas organizações 
de manufatura e de serviços reconhecem a importância dos 
processos de qualidade. Processo de ajuda a trabalhadores 
de uma organização para atender aos objetivos de negócio, 
5
10
15
20
110
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
ajudando-os a trabalhar com melhor consistência. Processos 
eficazes que também fornecem um veículo para a utilização 
de novas tecnologias de uma forma que melhor atenda aos 
objetivos de negócio da organização.
Watts Humphrey, Ron Radice e outros aplicam os princípios 
da qualidade total para a área de software em seu trabalho 
na IBM, e Humphrey, em seu livro Managing the software 
process, fornece uma descrição dos princípios e conceitos 
básicos sobre os quais muitos dos modelos de capacidade 
de maturidade (CMMs ®) se baseiam. O SEI tem divulgado a 
premissa de gestão de processos, “a qualidade de um sistema 
ou de um produto é altamente influenciada pela qualidade 
dos processos utilizados para desenvolver e manter isso”, e 
os modelos CMMs incorporam essa premissa. A crença nessa 
premissa é vista em todo o mundo em termos de movimentos 
da qualidade, como evidenciado pela ISO / IEC. Os modelos 
contêm os elementos essenciais de processos efetivos para 
uma ou mais disciplinas e descrevem um caminho de melhoria 
evolutiva ad hoc, processos imaturos disciplinados, processos 
maduros com melhor qualidade e eficácia.
O valor da presente abordagem de melhoria de processos 
foi confirmado ao longo do tempo. As organizações têm 
experimentado o aumento de produtividade e qualidade, a 
melhoria no tempo de ciclo de desenvolvimento, cronogramas 
muito mais precisos e previsíveis e acerto nos orçamentos 
(Gibson, 2006).
4.4.2 Evolução do CMMI
Desde 1991, os modelos CMMs têm sido desenvolvidos para 
diversas disciplinas. Alguns dos mais notáveis deles incluem 
modelos de sistemas de engenharia, engenharia de software, 
aquisição de software, gerenciamento de força de trabalho e 
desenvolvimento integrado de produtos, e desenvolvimento de 
processos (IPPD). Embora estes modelos tenham se mostrado 
5
10
15
20
25
30
111
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
úteis para muitas organizações diferentes, o uso de vários 
modelos tem sido problemático.
Muitas organizações gostariam que os seus esforços de 
melhoria abrangessem diferentes grupos em suas organizações. 
No entanto, as diferenças entre os modelos de disciplinas 
específicas utilizadas por cada grupo, incluindo a sua arquitetura, 
seu conteúdo e sua abordagem, têm limitado essas organizações 
a ampliar suas melhorias com êxito. Além disso, a aplicação 
de vários modelos que não estão integrados por meio da 
organização é dispendiosa em termos de treinamento, avaliação 
e melhoria das atividades.
O projeto CMM Integration (CMMI) foi formado para resolver 
o problema do uso de diversos CMMs. A missão inicial do time 
de produto CMMI era combinar três modelos-fonte:
1. O Capability Maturity Model for Software (SW-CMM) v2.0 
projeto C (SEI 1997b).
2. O Systems Engineering Capability Model (SECM) (EIA 
1998).
3. O Integrated Product Development Capability Maturity 
Model (IPD-CMM) v0.98 (SEI 1997a).
A combinação desses modelos em um único quadro de 
melhoria foi utilizada por organizações na busca de toda 
empresa pela melhoria dos processos. Estes três modelos de 
fonte foram escolhidos devido a sua ampla adoção do software, 
engenharia de sistemas e comunidades, por causa de suas 
diferentes abordagens para a melhoria dos processos em uma 
organização.
Utilizando as informações destes modelos populares e o 
material bem considerado de origem, o CMMI Product Team 
criou um conjunto coeso de modelos integrados que podem ser 
5
10
15
20
25
30
112
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
adotados por aqueles que usam atualmente os modelos-origens, 
assim como por aqueles que são novos para o conceito de 
CMM. Por isso, CMMI é um resultado da evolução do SW-CMM, 
o SECM e o IPD-CMM. Desenvolver um conjunto de modelos 
integrados envolveu mais do que simplesmente combinar 
materiais dos modelos existentes. Para a utilização de processos 
que promovam consenso, o CMMI Product Team construiu um 
quadro que acomoda múltiplas disciplinas e é flexível o suficiente 
para suportar as diferentes abordagens dos modelos de origem 
(Ahern, 2003).
A figura 16 mostra um quadro da evolução dos modelos 
CMMs:
Figura 16: A história dos modelos CMMs
History of CMMs
CMM for software 
v1.1 (1993)
Integrated Product 
Development CMM 
(1997)
Software CMM 
v25, draft C (1997)
INCOSE SECAM 
(1996)
EIA 731 SECM 
(1998)
Systems Engineering 
CMM v1.1 (1995)
CMMI for Acquisition 
v1.2 (2007)
CMMI for Services 
v1.2 (2007)
v1.02 (2000)
v1.1 (2000)
CMMI for Development 
v1.2 (2006)
Fonte: Manual do CMMI-DEV, V 1.2, 2006.
Desde o lançamento do CMMI V1.1, o SEI notou que 
este quadro de melhoria pode ser aplicado a outras áreas de 
interesse. Para aplicar a várias áreas de interesse, os grupos do 
quadro de melhores práticas foram chamados de “constelações”. 
Uma constelação é uma coleção de componentes CMMI que são 
5
10
15
113
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
usados para construir modelos, desenvolvimento de materiais 
(guias, apostilas, orientações etc.) e documentos de avaliação.
4.4.3 Objetivos do CMMI
O CMMI foi montado para atender aos seguintes objetivos:
• integrar os diversos modelos CMMs existentes, e, com isso, 
eliminar inconsistências e reduzir as duplicações;
• reduzir o custo de implementação de processo de melhoria 
baseado em modelos;
• aumentar a compreensão sobre a terminologia, estilo, 
regras e componentes dos modelos existentes;
• assegurar a consistência com a ISO 15504 ou o SPICE que 
avalia a capacidade dos processos e não da organização, 
– para isso o CMMI cria a representação contínua;
• considerar impactos sobre a utilização de modelos 
anteriores.
Dessa forma, o CMMI melhora o modelo anterior SW-CMM 
e outras práticas ao:
• conectar mais explicitamente as atividades de 
gerenciamento e engenharia com os objetivos do 
negócio;
• expandir o escopo e a visibilidade do ciclo de vida do 
produto e atividades de engenharia ao assegurar que 
produtos ou serviços atendem às expectativas dos 
clientes;
• incorporar lições aprendidas de áreas adicionais de 
melhores práticas, isto é, medição, gerenciamento de 
riscos e gerenciamento de fornecedor;
• implementar práticas mais robustas de alta maturidade;
5
10
15
20
25
114
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
• tratar funções organizacionaisadicionais críticas para 
produtos e serviços;
• estar em maior conformidade com padrões ISO.
Para isso, foram considerados relacionamentos entre diversos 
modelos mostrados na figura 17:
Figura 17: Relacionamento entre os modelos
SPICE ou 
ISO/IEC 15504
CMMI (por 
estágios e 
contínuo)
CMM 
(P/SA/SE/SW 
CMM e PIPD-
CMM)
Onde:
• SPICE – Software Process Improvement & Capability 
dEtermination: modelo ISO/IEC 15504 usado para 
melhoria de processo e determinação da capacidade de 
processo.
• P-CMM – Personal Capability Maturity Model: avalia 
a maturidade da organização em seus processos de 
gerenciamento de recursos humanos naquilo que se 
refere ao software, ao recrutamento e à seleção de 
profissionais de tecnolologia da informação, treinamento 
e desenvolvimento, remuneração etc.
• SA-CMM – Software Acquisition Capability Maturity 
Model: usado para avaliar a maturidade de uma 
5
10
15
115
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
organização em seus processos de seleção, aquisição e 
instalação de software de terceiros.
• SE-CMM – System Engineering Capability Maturity Model:
avalia a maturidade da organização em seus processos 
de engenharia de sistemas, concebidos como sendo algo 
maior que o software. Inclui hardware, software e outros 
elementos que participam do produto completo.
• SW-CMM – Software Capability Maturity Model: usado 
para avaliar a maturidade de uma organização em seus 
processos de desenvolvimento de software.
IPD-CMM – Integrated Product Development Capability 
Maturity Model: mais abrangente que o SE-CMM; inclui 
processos necessários à produção e ao suporte para o produto, 
tais como suporte ao usuário, processos de fabricação, entre 
outros.
4.4.4 Agrupamentos do CMMI
O modelo CMMI possui duas representações ou agrupamentos:
• o agrupamento ou a representação por estágio (staged);
• o agrupamento ou a representação contínua (continuous).
Na prática, essas formas de representação determinam 
a forma pela qual a organização irá trabalhar com as áreas 
de processo do CMMI (Kulpa & Johnson, 2003). A forma de 
agrupamento por estágios é mais conhecida e provém do 
CMM, ela estabelece uma estrutura na qual a organização 
irá evoluindo por meio dos níveis de maturidade dos seus 
processos, de acordo com a implantação das práticas de 
determinadas áreas de processo.
O modelo integrado ainda organiza as áreas de processos 
(PAs) em quatro áreas de conhecimento para escolha da 
5
10
15
20
25
116
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
organização quando da seleção de um modelo CMMI. 
As quatro áreas de conhecimento são: engenharia de 
sistemas, engenharia de software, produto e processo de 
desenvolvimento integrados e monitoramento (gestão) de 
fornecedores.
Engenharia de sistemas cobre o desenvolvimento total 
de sistemas, que pode ou não incluir software. Ela é focada na 
transformação das necessidades dos clientes, expectativas, e 
restrições nas soluções dos produtos e suporte desses produtos 
a partir do ciclo de vida do produto. Quando a engenharia de 
sistemas é selecionada para ser o modelo, deve conter as áreas 
de processos: gerenciamento de processos, gerenciamento de 
projetos, suporte e engenharia de processos.
Engenharia de software cobre o desenvolvimento de 
sistemas de software. Ela é focada na aplicação sistemática, 
disciplinada e na abordagem quantifícável para o 
desenvolvimento, operação e manutenção de software.
Quando a engenharia de software é selecionada para ser o 
modelo, deve conter as áreas de processos: gerenciamento de 
processos, gerenciamento de projetos, suporte e engenharia de 
processos.
Produto e processo de desenvolvimento integrados 
(IPPD) é uma abordagem sistemática que busca uma 
colaboração pontual dos stakeholders relevantes, a partir da 
vida do produto, para melhor satisfazer às necessidades, às 
expectativas e aos requisitos.
Os processos para suportar uma abordagem IPPD são 
integrados com outros processos na organização. As áreas de 
processos IPPD, especificam metas e práticas específicas que 
sozinhas não realizam o IPPD. Ele inclui: gerenciamento de 
processos, gerenciamento de projetos, e áreas de processos da 
engenharia que podem ser aplicadas em conjuntos com IPPD.
5
10
15
20
25
30
117
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Monitoramento (gestão) de fornecedores, certos 
projetos podem usar fornecedores para realizar funções ou 
acrescentar modificações aos produtos que são necessários 
ao projeto. Quando essas atividades são críticas, o projeto se 
beneficia da análise dos fornecimentos e do monitoramento 
das atividades dos fornecedores antes da liberação do 
produto.
A disciplina de monitoramento de fornecedores (supplier 
sourcing) cobre a aquisição de produtos de fornecedores nessas 
circunstâncias. Esta disciplina conterá: gerência de processos, 
gerência de projetos, suporte e áreas de processos da engenharia 
que se aplicam tanto para o “supplier sourcing” quanto para o 
modelo da organização.
4.4.4.1 Agrupamentos por estágio
O agrupamento por estágio tem foco na maturidade da 
organização e é organizado em cinco níveis de maturidade, que 
são:
• Inicial (nível 1): processo imprevisível, pouco controlado 
e reativo; o sucesso depende de heróis;
• Gerenciado (nível 2): processo caracterizado por projetos 
e, frequentemente, reativo; capacidade de gestão de 
projetos;
• Definido (nível 3): processo caracterizado para a 
organização, sendo proativo, processo comum adaptado 
às necessidades dos projetos;
• Quantitativamente gerenciado (nível 4): processo 
medido e controlado; capacidade de planejar 
estatisticamente a qualidade;
• Otimizado (nível 5): foco na melhoria contínua do 
processo, capacidade de prevenir defeitos.
5
10
15
20
25
118
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Os níveis de maturidade caracterizam um conjunto de 
práticas que, quando empregadas, conferem à organização uma 
determinada capacidade.
Este agrupamento provê um caminho predefinido para 
a melhoria organizacional baseada em agrupamentos 
comprovados, ordenamento de processos e relacionamentos 
organizacionais associados.
Segundo Chrissis, Konrad & Shurm (2004) as áreas 
de processo (PA) são consideradas um grupo de práticas 
relacionadas, que quando implantadas coletivamente 
satisfazem às metas importantes para realizar uma melhora 
significativa naquela área ou naquele tema.
A figura 18 mostra uma visão estrutural do modelo de 
agrupamento por estágios do manual do CMMI da SEI.
Figura 18: Visão estrutural do modelo por estágios
Process Area 1 Process Area n
Specific Goals Generic Goals
Specific 
Practices
Process Area 2
Maturity Levels Níveis de Maturidade
PAs
GG
Generic 
Practices
Commitement 
to Perform
Ability to 
Perform
Directing 
Implementation
Verifyng 
Implementation
GPSP
SG
Common Features
5
10
15
119
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Nesta representação os níveis de maturidade (2 a 5) 
proveem uma ordem recomendada para a abordagem de 
melhoria de processos (PAs - Process Area) em estágios. As PAs 
são organizadas em metas específicas (SG - Specific Goals) e 
metas genéricas (GG - Generic Goals). Já as metas genéricas são 
organizadas em práticas genéricas (GP - Generic Practices) e as 
metas específicas em práticas específicas (SP - Specific Practices).
A figura 19 apresenta uma visão da organização dos níveis 
com seus focos e as áreas de processos (PAs) envolvidas em cada 
nível.
Figura 19: CMMI por estágios
Nível de 
maturidade Foco
Área de processo
(PA - Process Area)
1
(inicial)
Prática inconsistente 
(“Just do it”) Nenhuma
2
(gerenciado)
Gerenciamento 
básico de projeto
Gerenciamento de requisitos
Planejamentodo projeto
Acompanhamento e controle de projeto
Gerenciamento de acordo com o fornecedor
Medição e análise
Garantia da qualidade de produto e processo
Gerenciamento de configuração
3
(definido)
Padronização de 
processos
Desenvolvimento de requisitos
Solução técnica
Integração de produto
Verificação
Foco no processo organizacional
Definição do processo organizacional
Treinamento organizacional
Gerenciamento integrado de projeto para IPPD
Gerenciamento de riscos
Integração de equipes
Gerenciamento integrado de fornecedor
Análise de decisão e resolução
Ambiente organizacional para integração
4
(gerenciado 
quantitativamente)
Gerenciamento 
quantitativo
Desempenho organizacional do processo
Gerenciamento quantitativo do projeto
5
(otimizando) Melhoria contínua
Inovação e implantação organizacional
Análise de causa e resolução
14 PAs no nível 
2 de maturidade
2 PAs no nível 2 
de maturidade
2 PAs no nível 2 
de maturidade
7 PAs no nível 2 
de maturidade
5
10
120
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
4.4.4.2 Agrupamento contínuo
A outra forma de representação, a contínua, é dividida 
em categorias e não em níveis de maturidade, em que cada 
área de processo tem um nível de capacitação, ou seja, uma 
organização pode evoluir nas áreas de processo mais adequadas 
aos processos e à cultura de sua organização (Ahern, Clouse & 
Turner, 2003).
O foco desse agrupamento é a capacidade do processo e 
abrange o gerenciamento de processo, o gerenciamento de 
projeto, a engenharia e o suporte. Ele provê flexibilidade para as 
organizações escolherem quais processos devem enfatizar para 
buscar melhorias, bem como quanto devem melhorar em cada 
processo.
Este agrupamento ou esta representação são contínuos e 
permitem que a organização selecione a ordem de melhorias 
que atenda aos objetivos de seu negócio e que mitigue as áreas 
de riscos. Permite o cruzamento entre organizações numa área 
de processo ou pela comparação de resultados através do uso de 
estágios equivalentes.
Fornece uma migração fácil da Electronic Industries Alliance 
Interim Standard (EIA/IS) 731 para o CMMI e propicia uma 
comparação fácil da melhoria de processo da International 
Organization for Standardization and International 
Electrotechnical Commission (ISO/IEC) 15504 devido à 
similaridade da organização das áreas de processo.
A figura 20 mostra a representação contínua, sendo que 
o gráfico de barras mostra no eixo horizontal as áreas de 
processo (PAs) e no eixo vertical os níveis de maturidade ou 
capacidade de cada área de processo. O desenho inferior 
da figura mostra a organização das áreas de processo nas 
metas genéricas e específicas e estas nas práticas genéricas e 
específicas também.
5
10
15
20
25
30
121
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
Figura 20: CMMI contínuo
 CMMI contínuo
 Continuous
Specific goals Generic goals
Generic 
practices
Specific 
practices
0
 
1
 
2
 
3
 
4
 
5
Process areas 1 Process areas 2 Process areas 3
Capability levels
Metas 
genéricas
Práticas 
genéricas
Práticas 
específicas
Metas 
específicas
Níveis de 
maturidade 
dos 
processos 
(PAs)
Ca
pa
bi
lit
y
Áreas de processos (PAs)
Áreas de 
processos (PAs)
A organização contínua apresenta o nível de capacidade do 
processo em vez de nível de maturidade do CMMI por estágio. 
Cada PA (área de processo) é considerado isoladamente e recebe 
sua própria classificação que vai de 0 a 5, sendo que:
• 0 – Incompleto;
• 1 – Realizado;
• 2 – Administrado;
• 3 – Definido;
• 4 – Administrado quantitativamente;
• 5 – Otimizado.
Neste tipo de organização é possível uma organização estar 
no nível de capacidade 3 para gerenciamento de requisitos e 
5
10
122
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
nível 2 para gerenciamento de configuração. Modelo ideal para 
empresas que buscam melhoria de processos a partir de um 
enfoque minimalista ou segmentado.
A figura 20 apresenta uma visão da organização das PAs do 
modelo contínuo por categoria e por áreas de processo.
Categoria Organização contínua das áreas de processo
Gerenciamento de 
processo
Foco no processo organizacional
Definição do processo organizacional
Treinamento organizacional
Desempenho do processo organizacional
Implantação e inovação organizacional
Gerenciamento de 
projeto
Planejamento de projeto
Acompanhamento e controle de projeto
Gerenciamento de acordo de fornecedor
Gerenciamento integrado de projeto
Gerenciamento de riscos
Integração de equipe
Gerenciamento integrado de fornecedor
Gerenciamento quantitativo de projeto
Engenharia Gerenciamento de requisitos
Desenvolvimento de requisitos
Solução técnica
Integração de produto
Verificação
Validação
Suporte Gerenciamento de configuração
Garantia de qualidade de produto e processo
Medição e análise
Análise de decisão e resolução
Ambiente organizacional para integração
Análise de causa e resolução
4.4.4.3 As metas e as práticas dos agrupamentos por 
estágio e contínuo
As metas genéricas e específicas são numeradas 
sequencialmente, por exemplo: SG 1 e SG 2. Com relação 
às práticas, elas são tratadas de forma diferente em cada 
agrupamento:
• Na representação por estágios, temos:
5
10
123
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
- cada prática genérica começa com GP, seguida de um 
número no formato x.y, como, por exemplo: GP 1.1, 
onde: x = número da meta/nível de capacidade e y= 
número sequencial da prática.
• Na representação contínua, temos:
- Cada prática específica começa com SP seguida de um 
número no formato x.y-z, por exemplo: SP 1.1-1, onde: 
x = número da meta/nível de capacidade, y = número 
sequencial e z = ampliação do nível de capacidade.
Exemplo para o agrupamento ou representação contínuo:
Categoria gerenciamento do processo:
* Área de Processo (PA) – foco no processo organizacional:
estabelecer e manter uma compreensão sobre os processos 
organizacionais, e identificar, planejar e implementar 
atividades de melhorias de processos.
- SG 1 (meta específica) – determine oportunidades de 
melhoria de processos;
- SP 1.1-1 – estabecer necessidades dos processos 
organizacionais;
- SP 1.2-1 - avaliar os processos da organização.
Categoria gerenciamento de projeto:
* Área de Processo (PA) – planejamento de projeto: estabelecer 
e manter planos que definam atividade do projeto.
- SG 1 (meta específica) – estabeleça estimativas.
- SP 1.1-1 – estimar o escopo do projeto.
- SP 1.2-1 - estabelecer estimativas de produtos de 
trabalhos e atributos das tarefas.
5
10
15
20
25
124
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
4.4.5 Métodos de avaliação
O framework do CMMI ainda trás outras partes 
fundamentais que são os métodos de avaliação da maturidade 
das organizações: o CBA IPI, que utiliza o SW-CMM como 
modelo de referência; o SCE, que é um método raramente 
utilizado fora do contexto de contratos militares dos EUA; 
e mode SCAMPI, que é uma metodologia que combina 
características dos métodos CBA-IPI e SCE.
O método SCAMPI é utilizado para avaliar o processo de 
engenharia (software, sistemas, hardware) versus o CMMI. É 
contratada por um patrocinador e liderada por um lead appraiser 
autorizado que, junto com uma equipe de 4 a 10 pessoas, avalia 
requisitos específicos internos ou externos à organização. Utiliza 
o CMMI como modelo de referência, gasta um grande esforço 
de coleta de dados e evidências antes do trabalho onsite e não 
está somente focado em software, mas também em sistema.
4.4.6 Conclusão
A representação por estágio utiliza nível de maturidade 
para medir a melhoria organizacional, tem somente um tipo 
de prática específica e somente aparecem práticas genéricas 
para os níveis de capacidade 2 e 3 e nãoexistem para os níveis 
4 e 5.
A representação contínua utiliza níveis de capacidade para 
medir a melhoria de processos, tem mais práticas específicas, 
pois há dois tipos de práticas: básicas e avançadas e existem 
práticas genéricas em todos os níveis de capacidade de 1 a 5.
Referências bibliográficas
ABNT - Associação Brasileira de Normas Técnicas – NBR-
ISO-9000-3 – Normas de gestão da qualidade e garantia da 
qualidade, 1990.
5
10
15
20
125
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
AHERN, Dennis M.; CLOUSE, Aaron; TURNER, Richard. CMMI 
distilled: a practical introduction to integrated process 
improvement. 2. ed. Boston: Addison-Wesley, 2003.
BROCKA, Bruce M.; BROCKA, Suzanne. Gerenciamento da 
qualidade. São Paulo: Makron Books, 1994.
CAPOVILLA, I. G. G. Elementos intrínsecos do software e sua 
influência na qualidade do processo de desenvolvimento. São 
Paulo: Dissertação, IMECC, Unicamp, 1999.
CARD, D. N. Software quality engineering. information and 
software technology. EUA: Butterworth, vol. 32, n. 1, janeiro de 
1990.
CHRISSIS, M. B.; KONRAD, M.; SHURM, S. CMMI guidelines for 
process integration and product improvement. 4. ed. Boston: 
Addison-Wesley, 2004.
COSTA NETO, Pedro Luiz de Oliveira. Qualidade e competência 
nas decisões. São Paulo: Blucher, 2007.
CÔRTES, Mario Lúcio; CHIOSSI, Thelma C. dos Santos. Modelos 
de qualidade de software. Campinas: Editora da Unicamp, 
2001.
CROSBY, P. B. Quality is free. Nova York: MacGraw-Hill, 1979.
DEMING, W. E. Quality, productivity and competitive position. 
EUA: Center for Advanced Engineering Study, MIT Press, 1982.
FALCONI, Campos V. TQC - Controle da qualidade total (no 
estilo japonês). Universidade Federal de Minas Gerais, 1992.
FAZANO, Carlos Alberto. Qualidade: a evolução de um conceito. 
São Paulo: Banas Qualidade, setembro de 2006, n. 172.
FNQ - FUNDAÇÃO NACIONAL DA QUALIDADE. Disponível em: 
http://www.fnq.org.br/. Acessado em 21 dez. 2007.
126
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
GARVIN, D.A. Gerenciando a qualidade: a visão estratégica e 
competitiva. In: Gestão estratégica da qualidade, pp. 25-45. 
São Paulo: Qualitymark, 1992.
GIBSON, D. L.; GOLDENSON, D. R. ; KOST, K. Performance results 
of CMMI- based process improvement. (CMU/SEI-2006-TR-
004, ESC-TR-2006-004). Pittsburgh, PA: Software Engineering 
Institute, Carnegie Mellon University, August 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/
06tr004.html.
GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da informação: 
qualidade de produto de software. Brasília: PBQPO Software, 
2009.
GURGEL JUNIOR, Garibaldi Dantas; VIEIRA, Marcelo Milano 
Falcão. Qualidade total e administração hospitalar: explorando 
disjunções conceituais. In: Ciênc. saúde coletiva [online]. 2002, 
vol.7, n.2, pp. 325-334. ISSN 1413-8123. doi: 10.1590/S1413-
81232002000200012
ISO/IEC 15504 - INTERNATIONAL ORGANIZATION FOR 
STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL 
COMISSION. ISO/IEC 15504-2: Information Technology - 
Process Assessment – Part 2 - Performing an Assessment, 
Geneve: ISO, 2003.
ISO/IEC, 2008a - INTERNATIONAL ORGANIZATION FOR 
STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL 
COMISSION. ISO/IEC 12207 Systems and software engineering– 
Software life cycle processes, Geneve: ISO, 2008.
JURAN, J. M. Qualidade desde o projeto. 1. ed. São Paulo: 
Thomson Learning, 2002.
KULPA, M. K.; JOHNSON, K. A. Interpreting the CMMI: a process 
improvement approach. Boca Raton: Auerbach Publications, 
2003.
127
QUALIDADE DE SOFTWARE
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
LONGO, Rose Mary Juliano. Gestão da qualidade: evolução 
histórica, conceitos básicos e aplicação na educação. IPEA 
- Instituto de Pesquisa Econômica Aplicada. Disponível 
em: http://www.dcce.ibilce.unesp.br/~adriana/ceq/
Material%20complementar/historia.pdf. Acessado em: 3 de 
abril de 2010.
LUCENA, Gratuliano F. T. Sistemática de qualidade total. Rio de 
Janeiro: Ciência Moderna Ltda., 2007.
MALDONADO, J.C. Critérios potenciais de usos: uma 
contribuição ao teste estrutural de software. Campinas, 1991.
MEZOMO, João Catarin. Gestão da qualidade na escola: 
princípios básicos. São Paulo: Editorial Terra, 1994. p. 207.
MOLINARI, L. Testes de software – produzindo sistemas 
melhores e mais confiáveis. São Paulo: Érica, 2003.
MOREJÓN, Mônica Andrés García. A implantação do processo 
de qualidade ISO 9000 em empresas educacionais. Tese 
apresentada, para obtenção do título de Doutor em História 
pela USP, São Paulo, SP, 2005.OAKLAND, John. Gerenciamento 
da qualidade total – TQM. 1. ed. São Paulo: Nobel, 1994.
PALADINI, Edson Pacheco et al. Gestão da qualidade: teoria e 
casos. Rio de Janeiro: Elsevier, 2005.
PEZZÉ, Mauro; YOUNG, Michal. Teste e análise de software: 
processos, princípios e técnicas. Porto Alegre: Bookman, 2008.
PFLEEGER, S.L. Engenharia de software – teoria e prática. São 
Paulo: Pearson Prentice Hall, 2003.
PRESSMAN, S. R. Engenharia de software. 6. ed. São Paulo: 
McGraw-Hill, 2006.
RAMOS, Alberto W. Apostila do curso de Processo de Resolução 
de Problemas. Fundação Vanzolini, USP, 2008.
128
Unidade IV
Re
vi
sã
o:
 J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: L
éo
 -
 0
1/
09
/2
01
0
RENTES, Antonio Freitas. A metodologia TransMeth. Equipe 
MIE da EESC-USP. Disponível em: http://www.numa.org.br/
transmeth/index.htm. Acessado em: 31 de março de 2010.
RIOS, E. et al. Base de conhecimento em teste de software. São 
Paulo: Martins, 2007.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade 
de software – teoria e prática. 1. ed. São Paulo: Prentice Hall, 
2001.
SEI - SOFTWARE ENGINEERING INSTITUTE. CMMI for 
Development (CMMI-DEV), Version 1.2, Technical Report 
CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering 
Institute, Carnegie Mellon University, 2006.
SEI 1997 - Integrated Product Development Capability 
Maturity Model, Draft Version 0.98. Pittsburgh, PA: Enterprise 
ProcessImprovement Collaboration and Software Engineering
Institute, Carnegie Mellon University, July 1997SEI 1997b 
Software Engineering Institute. Software CMM, Version 2.0 
(Draft C), October 22, 1997.
SHIBA, Shoji. TQM – quatro revoluções na gestão da qualidade. 
Porto Alegre: Bookman, 1997.
SOMMERVILLE, Ian. Software engineering. England: Addison-
Wesley, 2007.
TAYLOR, F. W. The principle of scientific management. Nova 
York: Harper & Row, 1911.
WALTON, Mary. O método Deming de administração. Rio de 
Janeiro: Marques-Saraiva, 1989.
WEINBERG, Gerald M. Software com qualidade. Makron Books, 
1997.