Livro Texto Unidade IV

Prévia do material em texto

81
QUALIDADE DE SOFTWARE
Unidade IV
7 MODELOS DE QUALIDADE DE SOFTWARE
7.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 modificar 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 e serviços correlatos como dos processos de produção e distribuição de software. Isso 
vem acontecendo com as empresas de outros setores, como 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 a Melhoria de Processo do Software Brasileiro, modelo MPS.BR, 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 à oferta de produtos e serviços correlatos conforme padrões (normas e modelos) internacionais 
de qualidade.
Serão apresentados a seguir os três principais modelos de qualidade de software, que têm como 
foco a melhoria contínua da qualidade nos processos e produtos: MPS.BR, ISO/IEC 15504 e CMMI-DEV.
7.2 O modelo 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 por meio do Banco Interamericano de 
Desenvolvimento (BID) e de outros parceiros, como o Sebrae e o CNPq. 
 Saiba mais
No endereço a seguir, é possível encontrar um conjunto de guias 
denominadas Guias MPS.BR, que descrevem o modelo MPS e sua estrutura 
e aplicabilidade.
<http://www.softex.br/mpsbr/_guias/default.asp>
82
Unidade IV
7.2.1 Introdução ao MPS.BR
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, com especial atenção às micro, pequenas 
e médias. 
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. 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). 
7.2.2 Descrição geral do MPS.BR
O MPS.BR está descrito por meio de documentos em formato de guias. O guia geral de serviços 
contém a descrição 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 geral de software contém a descrição geral do modelo MPS.BR, detalha o Modelo de 
Referência para software (MR-MPS-SW) e as definições comuns necessárias para seu entendimento 
e aplicação.
O guia de aquisição contém recomendações para a condução de compras de software e serviços 
correlatos, descrito como forma de apoiar as instituições brasileiras que queiram adquirir produtos de 
software e serviços correlatos. Ele descreve um processo de aquisição baseado na norma internacional 
ISO/IEC 12207:2008.
Há, ainda, o guia de avaliação que descreve o Processo e o Método de Avaliação (MA-MPS), baseado 
na norma internacional ISO/IEC 15504, e 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. 
O MPS.BR também é um programa brasileiro de qualificação e certificação de empresas em processos 
de melhoria de qualidade de software. 
83
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 Capability Maturity 
Model Integrated (CMMI). 
 Observação
De acordo com a Softex, o número de avaliações no modelo brasileiro 
MPS.BR tem se estabilizado em torno de 70 avaliações/certificações por 
ano.
7.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. 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:
— capacitação no uso; 
— credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente de 
ensino e centros tecnológicos;
— implementação e avaliação do modelo com foco em grupos de empresas.
A figura a seguir apresenta uma visão do modelo MPS.BR. 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, 
que 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.
84
Unidade IV
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
Figura 8 - Modelo para melhoria do processo de software brasileiro (componentes do modelo) – MPS.BR
A base técnica para a construção e o aprimoramento desse modelo de melhoria e avaliação de 
processo de software é composta pelas normas ISO/IEC 12207:2008 (ISO/IEC, 2008ª), ISO/IEC 15504-2 
(ISO/IEC, 2003) e ISO/IEC 2000. 
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.
 Observação
O modelo CMMI foi criado no Software Engineering Institute (SEI) 
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).
7.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. 
85
QUALIDADE DE SOFTWARE
O MR-MPS define sete níveis de maturidade: 
• em otimização;
• gerenciado quantitativamente;
• definido;• largamente definido;
• parcialmente definido;
• gerenciado; 
• parcialmente gerenciado.
A escala de maturidade inicia-se no nível G e progride até o nível A. 
Para cada um desses 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 são obtidos quando 
são atendidos os propósitos, todos os resultados esperados dos respectivos processos e 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 avaliação 
adequada à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 com o maior nível de maturidade.
Nível G – Parcialmente gerenciado
Esse nível apresenta duas áreas de processo, conforme mostra o quadro a seguir. É composto pelos 
processos: Gerência de Projetos e Gerência de Requisitos. 
86
Unidade IV
Quadro 3 - 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.
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 desse 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
Esse nível apresenta cinco áreas de processo. É 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.
Quadro 4 - 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. Esse 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 
justificam a continuidade dos investimentos ou podem ser 
redirecionados para justificar.
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.
87
QUALIDADE DE SOFTWARE
Nível E – Parcialmente definido
Esse nível apresenta quatro áreas de processo. É 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. 
Quadro 5 - 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.
Nível D – Largamente definido
Esse nível apresenta cinco áreas de processo. É 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.
Quadro 6 - 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.
88
Unidade IV
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 – Definido 
Esse nível apresenta três áreas de processo. É 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. 
Quadro 7 - 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 
Esse nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C). 
Nele, 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. 
A implementação dos processos deve satisfazer aos atributos dos processos: o processo é executado 
e gerenciado, os produtos de trabalho do processo são gerenciados, o processo é definido e está 
implementado e é otimizado continuamente. A implementação dos processos selecionados para 
análise de desempenho deve satisfazer integralmente aos atributos de processo: o processo é medido e 
controlado. Esse nível não possui processos específicos.
Nível A – Em otimização 
Esse nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B). 
A implementação dos processos deve satisfazer aos atributos de processo: o processo é executado e 
gerenciado, os produtos de trabalho do processo são gerenciados, o processo é definido, implementado 
e medido. 
89
QUALIDADE DE SOFTWARE
A implementação dos processos selecionados para análise de desempenho deve satisfazer 
integralmente aos atributos de processo: o processo é medido e controlado. 
Os atributos “o processo é objeto de melhorias e inovações” e “o processo é otimizado continuamente” 
devem ser integralmente satisfeitos pela implementação de, pelo menos, um dos processos selecionados 
para análise de desempenho. Esse nível não possui processos específicos.
 Saiba mais
Encontra-se disponível no site da Consultoria e Assessoria em 
Qualidade, ASR, uma lista de empresas de diversas localidades do Brasil que 
implementaram com sucesso melhorias de processos de software por meio 
do modelo MPS.BR.
<http://www.asrconsultoria.com.br/qualidade-de-software/mpsbr/
casos-de-sucesso.php> 
8 O MODELO ISO/IEC 15504 (SOFTWARE PROCESS ASSESMENT)
O modelo ou norma ISO/IEC 15504 foi criado para harmonizar as diferentes abordagens de avaliação 
do processo de software. 
 Observação
O modelo ou norma ISO/IEC 15504 também é conhecido como projeto 
SPICE para avaliação de processos de software.
8.1 Introdução
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.
8.1.1 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.
90
Unidade IV
Se uma organização tem por objetivo a melhoria de seus processos, a norma permite avaliá-los e, a 
partir dessa avaliação, elaborar um plano de melhorias. A figura a seguir mostra o uso da ISO/IEC 15504 
para a 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
Figura 9 - Aplicação da ISO/IEC 15504 para melhoria de processos
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 próxima figura. 
O perfil de capacidade permite à organização contratante avaliar os riscos associados à contratação 
desse fornecedor.
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
Figura 10 - Aplicação da ISO/IEC 15504 para a determinação da capacidade
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: processo e 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.
91
QUALIDADE DE SOFTWARE
• 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.
O modelo de referência parte 2 documenta um conjunto universal de processos da engenharia de 
software que são fundamentais, 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 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.
 Saiba mais
Encontra-se disponível no endereço <http://www.ic.unicamp.
br/~cortes/inf326/transp/cap7.pdf> material do prof. Mario L. Cortês, que 
faz uma abordagem significativa da norma ou modelo ISO/IEC 15504.
8.1.2 As dimensões do modelo de referência
A arquitetura do modelo de referência é de duas dimensões:
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. 
92
Unidade IV
Essa dimensão foi fortemente baseada na norma ISO/IEC 12207. Ela apresenta cinco categorias de 
processos, conforme apresentadas na figura a seguir, e suas siglas são:
• customer-supplier (CUS) – 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.
• engineering (ENG) – 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.
• support (SUP) – apoio: os processos de apoio ou suporte, divididos em oito oito, podem ser 
usados por quaisquer dos demais processos, em qualquer ponto do ciclo de vida do software.
• management (MAN) – 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.
• organization (ORG) – 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.
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çãoSUP.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 - Reúso
Figura 11 - Estrutura ou arquitetura da dimensão de processos
93
QUALIDADE DE SOFTWARE
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 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.
Quadro 8 - 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
Fonte: ISO/IEC 15504 (2003)
Os níveis de capacidade constituem uma maneira racional de progredir na melhoria da 
capacidade dos processos. São, conceitualmente, os mesmos dos 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, não existe uma clara identificação dos 
produtos ou saídas do processo ou 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. 
94
Unidade IV
• Nível 2 – gerenciado: o processo fornece produtos de trabalho de acordo com os procedimentos 
especificados, planejados e controlados, que 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 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, dentro dos 
limites de controle definidos, para atingir os objetivos.
• Nível 5 – em otimização: o desempenho do processo é otimizado para atender às necessidades 
de negócios atuais e futuros. O processo atinge repetitividade na realização dos objetivos dos 
negócios definidos.
Conforme Côrtes e 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 no quadro anterior. 
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 (largamente atendido – 51% a 85%) 
e F (totalmente atendido – 86% a 100%).
 Observação
Pode-se dizer que o SPICE é o modelo que 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 CMM/CMMI, apesar 
de ser um projeto da ISO (CÔRTES; CHIOSSI, 2001).
8.2 O modelo CMMI-DEV adaptado do manual CMU/SEI-2006-TR-008 
ESC-TR-2006-008 – improving processes for better products
8.2.1 Introdução
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 mais 
produtos e serviços complexos. 
Hoje, uma única empresa geralmente não desenvolve todos os componentes de um produto ou 
serviço. Mais comumente, alguns são construídos em casa, outros, adquiridos no mercado; mas todos 
são integrados ao produto ou serviço final.
95
QUALIDADE DE SOFTWARE
As organizações devem ser capazes de gerir e controlar o processo complexo de desenvolvimento 
e manutenção. Os problemas das organizações apontados nos dias de hoje envolvem soluções para 
toda a empresa e 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á enfrentando. Ao se concentrar em melhorar uma área de 
uma empresa, esses 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. 
 Observação
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.
O SEI, a partir dessas pesquisas, definiu três dimensões, ilustradas na figura a seguir, que foram 
consideradas críticas e nas quais as organizações geralmente se concentram: pessoas, processos e 
métodos e ferramentas e equipamentos. 
Ferramentas e 
equipamentos
B
D
C
A
Procedimentos e métodos, 
definindo as relações de tarefas
Pessoas com habilidades 
e motivação
Processo
Figura 12 - As três dimensões críticas apresentadas pelo SEI
96
Unidade IV
Entretanto, o que mantém tudo isso junto? 
Trata-se dos processos utilizados na organização. Processos permitem alinhar a maneira 
de fazer negócios. Com eles é possível que se aponte para a escalabilidade e se forneça uma 
maneira de incorporar conhecimento. Processos permitem, ainda, alavancar recursos e examinar 
as tendências de negócios. 
Vive-se em um mundo onde a tecnologia está mudando para 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 manufatura 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, pois 
eles ajudam trabalhadores de uma organização a atender aos objetivos de negócio e a trabalhar com 
melhor consistência. 
Processos eficazes também fornecem um veículo para a utilização de novas tecnologias, de uma 
maneira que melhor atenda aos objetivos de negócio da organização.
Watts Humphrey, Ron Radice e outros aplicaram os princípios da qualidade totalpara a área de 
software em seu trabalho na IBM. 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 que a qualidade de um sistema ou produto é altamente influenciada pela 
qualidade dos processos utilizados para desenvolver e manter o sistema, e os modelos CMMs incorporam 
essa premissa. 
A crença nesse conceito é vista em todo o mundo em termos de movimentos da qualidade, 
como evidenciado pela ISO/IEC. Essas normas e 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 e 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).
97
QUALIDADE DE SOFTWARE
 Saiba mais
A pesquisa de Manoella Rodrigues Teixeira, da Universidade Federal 
Fluminense, faz uma análise dos impactos na qualidade de software em 
instituições financeiras com o uso do modelo CMMI.
<http://www.producao.uff.br/conteudo/rpep/volume62006/RelPesq_
V6_2006_03.pdf>
8.2.2 Evolução do CMM
Desde 1991, os modelos CMMs têm sido desenvolvidos para diversas disciplinas. Alguns dos 
mais notáveis 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 de 
processos (IPPD). 
 Observação
Embora esses modelos tenham se mostrado ú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, conteúdo e 
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 à 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 como fonte: 
• Capability Maturity Model for Software (SW-CMM) v2.0 projeto C; 
• Systems Engineering Capability Model (SECM);
• Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98.
A combinação desses modelos em um único quadro de melhoria foi utilizada por organizações na 
busca de toda empresa pelo aperfeiçoamento dos processos. Os três modelos de fonte foram escolhidos 
devido a sua ampla adoção do software, engenharia de sistemas e comunidades e por suas diferentes 
abordagens para a melhoria dos processos em uma organização. 
98
Unidade IV
Utilizando as informações desses modelos populares e o material bem considerado de origem, o CMMI 
Product Team criou um conjunto coeso de modelos integrados que podem ser adotados por aqueles que 
usam atualmente os modelos origens, assim como por aqueles que são novos para o conceito de CMM. 
Por isso, o CMMI é um resultado da evolução do SW-CMM, do SECM e do 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 seguir um quadro mostra um quadro da evolução dos modelos 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)
CMMI for 
Development v1.2 
(2006)
Figura 13 - A história dos modelos CMMs 
Desde o lançamento do CMMI V1.1, o SEI notou que o quadro de melhoria pode ser aplicado a outras 
áreas de interesse, e os grupos do quadro de melhores práticas foram chamados de constelações. 
 Lembrete
Para o CMMI, constelação é uma coleção de componentes CMMI usados 
para construir modelos e para a formação de materiais e documentos de 
avaliação.
8.2.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;
99
QUALIDADE DE SOFTWARE
• reduzir o custo de implementação de processo de melhoria baseado em modelos;
• aumentar a compreensão sobre terminologia, estilo, regras e componentes dos modelos existentes;
• assegurar a consistência com a ISO 15504 ou 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 de fornecedor; implementar práticas mais 
robustas de alta maturidade; tratar funções organizacionais adicionais críticas para produtos e serviços 
e estar em maior conformidade com padrões ISO.
Para isso, foram considerados relacionamentos entre diversos modelos mostrados na figura AM, a 
seguir:
SPICE 
ou ISO/IEC 
15504
CMMI 
(por estágios 
e contínuo)
CMM 
(P/SA/SE/
SW CMM e 
PIPD-
CMM)
Figura 14 - Relacionamento entre os modelos
Onde: 
• Software Process Improvement & Capability Determination – SPICE: modelo ou norma ISO/IEC 
15504, usado para melhoria de processo e determinação da capacidade de processo.
• Personal Capability Maturity Model – P-CMM: avalia a maturidade da organização em seus processos 
de gerenciamento de recursos humanos naquilo que se refere a software, recrutamento e seleção de 
profissionais de tecnologia da informação, treinamento e desenvolvimento, remuneração etc.
• Software Acquisition Capability Maturity Model – SA-CMM: usado para avaliar a maturidade de 
uma organização em seus processos de seleção, aquisição e instalação de software de terceiros.
100
Unidade IV
• System Engineering Capability Maturity Model – SE-CMM: 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.
• Software Capability Maturity Model – SW-CMM: usado para avaliar a maturidade de uma 
organização em seus processos de desenvolvimento de software.
• Integrated Product Development Capability Maturity Model – IPD-CMM: mais abrangente que o 
SE-CMM, inclui processos necessários à produção e ao suporte para o produto, como suporte ao 
usuário, processos de fabricação, entre outros.
8.2.4 Agrupamentos do CMMI
O modelo CMMI possui duas representações ou agrupamentos:
• agrupamento ou representação por estágio (staged); 
• agrupamento ou 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 seusprocessos, 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 organização, quando da seleção de um modelo CMMI. São elas: engenharia de sistemas, 
engenharia de software, produto e processo de desenvolvimentos 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, nas expectativas e restrições nas soluções dos produtos e 
suporte por meio do ciclo de vida do produto. 
Quando a engenharia de sistemas é selecionada para ser o modelo, conterá as áreas: 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 quantificável para o desenvolvimento, operação e manutenção de software.
101
QUALIDADE DE SOFTWARE
Quando a engenharia de software é selecionada para ser o modelo, conterá as áreas: gerenciamento 
de processos, gerenciamento de projetos, suporte e engenharia de processos.
Produto e processo de desenvolvimento integrado (IPPD)
É uma abordagem sistemática que busca uma colaboração pontual dos stakeholders relevantes com 
a vida do produto, para melhor satisfazer as necessidades, expectativas e requisitos. 
Os processos para suportar uma abordagem IPPD são integrados com outros 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. 
 Monitoramento (gestão) de fornecedores
Certos projetos podem usar fornecedores para realizar funções ou acrescentar modificações nos 
produtos 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. Essa 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 como para o modelo da organização.
Agrupamentos por estágio
Tem foco na maturidade da organização e é organizado em cinco níveis de maturidade:
• 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 é 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.
Os níveis de maturidade caracterizam um conjunto de práticas que, quando empregadas, conferem 
à organização uma determinada capacidade.
102
Unidade IV
Esse agrupamento provê um caminho predefinido para a melhoria organizacional baseada em 
agrupamentos comprovados, ordenamento de processos e relacionamentos organizacionais associados.
Segundo Chrissis, Konrad e Shurm (2004), as áreas de processo (PA) são consideradas um grupo de 
práticas relacionadas que, quando implantadas coletivamente, satisfazem a metas importantes para 
realizar uma melhora significativa naquela área ou tema. 
A próxima figura mostra uma visão estrutural do modelo de agrupamento por estágios do manual 
do CMMI da SEI. 
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
Figura 15 - Visão estrutural do modelo por estágios
Nessa representação, os níveis de maturidade (2 a 5) atendem a uma ordem recomendada para a 
abordagem de melhoria de processos (Process Area - PAs) em estágios. 
As PAs são organizadas em metas específicas (Specific Goals - SG) e metas genéricas (Generic Goals 
- GG). As metas genéricas são organizadas em práticas genéricas (Generic Practices - GP) e as metas 
específicas, em práticas específicas (Specific Practices - SP). 
A figura a seguir apresenta uma visão da organização para os níveis com seus focos e as áreas de 
processos (PAs) envolvidas em cada nível.
103
QUALIDADE DE SOFTWARE
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
Planejamento do 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
Análise de decisão e resolução
Ambiente organizacional para integração
Validaçã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
12 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
Figura 16 - CMMI por estágios
Agrupamento contínuo
A forma de representação contínua é dividida em categorias, e não em níveis de maturidade, e 
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.
Esse agrupamento contínuo, ou representação, permite que a organização selecione a ordem de 
melhorias que melhor 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 por meio 
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.
104
Unidade IV
A figura a seguir mostra a representação contínua, 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. A parte inferior da figura mostra a organização das áreas de processo nas metas genéricas 
e específicas.
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)Figura 17 - CMMI por agrupamento contínuo
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 área de processo (PA) é considerada isoladamente e recebe sua própria 
classificação, que vai de 0 a 5: 
• 0 – incompleto;
• 1 – realizado;
• 2 – administrado;
• 3 – definido;
• 4 – administrado quantitativamente;
• 5 – otimizado.
Assim, é possível uma organização estar no nível de capacidade 3 para gerenciamento de requisitos 
e nível 2 para gerenciamento de configuração; modelo ideal para empresas que buscam melhoria de 
processos por meio de um enfoque minimalista ou segmentado.
O quadro a seguir apresenta uma visão da organização das PAs do modelo contínuo, por categoria 
e por áreas de processo.
105
QUALIDADE DE SOFTWARE
Quadro 9 - Categorias e áreas de processo do agrupamento contínuo do CMMI
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
Adaptado de: Manual do CMMI-DEV, v 1.2, SEI (2006).
8.2.5 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, cada prática genérica começa com GP, seguida de um número no 
formato x.y, como: 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, 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.
A seguir, exemplo para o agrupamento ou representação contínua.
Categoria gerenciamento do processo
Área de processo (PA) – foco no processo organizacional: estabelecer e manter uma compreensão 
dos processos organizacionais e identificar, planejar e implementar atividades de melhorias de 
processos.
106
Unidade IV
• SG 1 (meta específica): determine oportunidades de melhoria de processos.
— SP 1.1-1: estabelecer 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.
8.2.6 Métodos de avaliações
O framework do CMMI ainda traz outras partes fundamentais, 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, 
método raramente utilizado fora do contexto de contratos militares dos EUA; e modelo Scampi, 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.
A representação por estágio utiliza nível de maturidade para medir a melhoria organizacional, tem 
um tipo de prática específica, somente aparecem práticas genéricas para os níveis de capacidade 2 e 3, 
e não existem para os níveis 4 e 5.
A representação contínua utiliza níveis de capacidade para medir a melhoria de processos. Existem 
mais práticas específicas e as práticas genéricas existem em todos os níveis de capacidade de 1 a 5.
 Saiba mais
No portal da empresa ISD Brasil está disponível material que apresenta 
a análise feita sobre os impactos das mudanças que o modelo CMMI 1.3 
traz em relação à versão anterior.
<http://www.isdbrasil.com.br/imprensa.php?ID=70>
107
QUALIDADE DE SOFTWARE
 Resumo
Esta unidade tem início com a necessidade das empresas se organizarem 
em relação às exigências de produtos de software de alta qualidade. Mostra 
também como os modelos de qualidade nacionais e internacionais podem 
apoiar a melhoria de seus processos de software.
Inicialmente, é apresentada e detalhada a proposta do modelo de 
qualidade brasileira denominado de MPS.BR. Para esse modelo são 
apresentadas as suas definições, objetivos, os níveis de organização e os 
guias envolvidos na sua implantação .
Em seguida, abordou-se a norma ou modelo ISO/IEC 15504, norma 
internacional que atua também na melhoria de processos específicos. 
O modelo/norma ISO/IEC 15504 possui um modelo de referência que 
apresenta suas dimensões de processo e como cada dimensão avalia os 
processos da organização.
Para fechar a unidade, é descrito o modelo internacional e mais famoso, 
o modelo CMMI,baseado nos guias do instituto SEI. Dentro da estrutura do 
CMMI, são apresentadas as duas representações do modelo, a representação 
por estágio e a representação contínua.
A representação por estágio utiliza nível de maturidade para medir 
a melhoria organizacional, tem um tipo de prática específica, somente 
aparecem práticas genéricas para os níveis de capacidade 2 e 3 e não 
existem 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; 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.
 Exercícios
Questão 1. Leia as duas afirmações a seguir:
Estão ocorrendo mudanças no relacionamento das organizações com os clientes e com os 
fornecedores. Essas mudanças refletem ambientes de negócios altamente competitivos e têm levado 
as empresas a modificar suas estruturas organizacionais. Devido a essas ocorrências, os processos de 
desenvolvimento e oferta de serviços na área de softwares também estão sendo modificados.
108
Unidade IV
Porque
Na atualidade, em um mercado cada vez mais competitivo, para as empresas alcançarem a 
competitividade pela qualidade, elas precisam ter foco tanto na melhoria da qualidade dos produtos 
de software e na prestação de serviços correlatos quanto nos processos de produção e distribuição de 
softwares.
Assinale a alternativa correta:
A) A primeira afirmação é verdadeira e a segunda é falsa.
B) A primeira afirmação é falsa e a segunda é verdadeira.
C) As duas afirmações são verdadeiras, mas a segunda não justifica a primeira.
D) As duas afirmações são verdadeiras, e a segunda justifica a primeira.
E) As duas afirmações são falsas.
Resposta correta: alternativa D.
Análise das afirmativas
Justificativa geral: como vem ocorrendo com as empresas de outros setores, o desenvolvimento 
da qualidade tem se tornado um fator crítico para o sucesso da indústria de softwares. De acordo 
com a edição de junho de 2011 da Revista do Programa Brasileiro da Qualidade e Produtividade em 
Software, do Ministério da Ciência e Tecnologia, o desenvolvimento de softwares é uma atividade 
criativae de excelência técnica que se realiza em equipe: é um trabalho de pura sinergia. A qualidade é 
um valor muitas vezes subjetivo, mas é percebida pelos clientes e é alvo de constantes buscas por parte 
das empresas que prestam serviços de desenvolvimento de software. Qualificar, mostrar diferencial e 
buscar modelos de qualidade passaram a ser relevantes. Mais que isso, criar formas de gerar retorno de 
investimento (Return of Investment – ROI) para clientes torna-se um assunto cada vez mais presente 
nas empresas do mercado de TI. Já 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 à oferta de produtos de software e serviços correlatos conforme padrões (normas 
e modelos) internacionais de qualidade.
Primeira afirmativa: correta.
Justificativa: as mudanças que estão ocorrendo no comportamento dos clientes e nos ambientes de 
negócios, altamente competitivos, têm levado as empresas a modificar suas estruturas organizacionais, 
principalmente nas áreas de TI, criando e investindo cada vez mais na qualidade de seus produtos e 
serviços, já que essa qualidade é um valor percebido por clientes e fornecedores.
109
QUALIDADE DE SOFTWARE
Segunda afirmativa: correta.
Justificativa: de acordo com o modelo CMMI-DEV, as organizações devem ser capazes de gerir e 
controlar o complexo processo de desenvolvimento e manutenção de softwares. Os problemas dessas 
organizações nos dias de hoje envolvem soluções que exigem uma abordagem integrada. Uma gestão 
eficaz dos ativos da organização é fundamental tanto para o sucesso empresarial quanto para a 
qualidade dos processos e dos produtos de software. Assim, as duas afirmações são verdadeiras, e a 
segunda justifica a primeira.
Questão 2. Leia as duas afirmações a seguir:
Para a implementação do modelo brasileiro de qualidade de software MPSBR nas empresas, foram 
definidos dois tipos de instituição: as credenciadas para essa implementação (ICI), que têm como função 
preparar outras empresas para o uso do modelo; e as credenciadas para realizar avaliações (ICA), que 
têm como foco analisar outras empresas com relação à sua maturidade no desenvolvimento e na 
manutenção de softwares.
Porque
Para o modelo MPSBR, as instituições ICI e ICA podem ser ao mesmo tempo implementadoras do 
modelo e avaliadoras da maturidade no desenvolvimento e da manutenção em uma determinada 
empresa de softwares.
Assinale a alternativa correta:
A) A primeira afirmação é verdadeira e a segunda é falsa.
B) A primeira afirmação é falsa e a segunda é verdadeira.
C) As duas afirmações são verdadeiras, mas a segunda não justifica a primeira.
D) As duas afirmações são verdadeiras, e a segunda justifica a primeira.
E) As duas afirmações são falsas.
Resolução desta questão na plataforma.
110
REFERÊNCIAS
Textuais
ABNT. Associação Brasileira de Normas Técnicas. Normas de gestão da qualidade e garantia da 
qualidade. Rio de Janeiro: Instituto de bibliografia e documentação, 1990.
AHERN, D. M.; CLOUSE, A; TURNER, R. CMMI distilled: a practical introduction to integrated process 
improvement. 2. ed. Boston: Addison-Wesley, 2003.
BROCKA, B. M.; BROCKA, S. 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. 1990. Dissertação (Mestrado) - Instituto de Matemática, Estatística e Computação 
Científica, Unicamp, Campinas, 1990.
CARD, D. N. Software quality engineering. Information and software technology, EUA, Butterworth, v. 
32, n. 1, jan. 1990.
CHRISSIS, M. B.; KONRAD, M.; SHURM, S. CMMI guidelines for process integration and product 
improvement. 4. ed. Boston: Addison-Wesley, 2004.
COLTRO, A. A gestão da qualidade total e suas influências na competitividade empresarial. Caderno de 
pesquisas em administração, São Paulo, v. 1, n. 2, 1996. Disponível em: <http://www.ead.fea.usp.br/
cad-pesq/arquivos/C02-art04.pdf>. Acesso em: 20 jul. 2013.
COSTA, I. et al. Qualidade em tecnologia da informação. São Paulo: Atlas, 2013.
COSTA NETO, P. L. O. Qualidade e competência nas decisões. São Paulo: Blucher, 2007.
CÔRTES, M. L.; CHIOSSI, T. C. S. Modelos de qualidade de software. Campinas: Editora da Unicamp, 2001.
CROSBY, P. B. Quality is free. Nova Iorque: MacGraw-Hill, 1979.
DEMING, W. E. Quality, productivity and competitive position. EUA: Center for Advanced Engineering 
Study, MIT Press, 1982.
FALCONI, C. V. TQC: controle da qualidade total (no estilo japonês). Belo Horizonte: Universidade 
Federal de Minas Gerais, 1992.
FAZANO, C. A. Qualidade: a evolução de um conceito. Banas Qualidade, São Paulo, n. 172, set. 2006.
GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. In: Gestão estratégica da 
qualidade. São Paulo: Qualitymark, 1992. p. 25-45.
111
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, 2006. Disponível em: <http://www.sei.cmu.edu/publications/documents/06.
reports/06tr004.html>. Acesso em: 7 ago. 2013.
GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da informação: qualidade de produto de software. 
Brasília: PBQPO Software, 2009.
GURGEL JUNIOR, G. D.; VIEIRA, M. M. F. Qualidade total e administração hospitalar: explorando 
disjunções conceituais. Ciênc. saúde coletiva, v. 7, n. 2, p. 325-334, 2002. 
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. São Paulo: Thomson Learning, 2002.
KULPA, M. K.; JOHNSON, K. A. Interpreting the CMMI: a process improvement approach. Boca Raton: 
Auerbach Publications, 2003.
LONGO, R. M. J. Gestão da qualidade: evolução histórica, conceitos básicos e aplicação na educação. 
Instituto de Pesquisa Econômica Aplicada (IPEA). Disponível em: <http://www.dcce.ibilce.unesp.
br/~adriana/ceq/Material%20complem entar/historia.pdf>. Acesso em: 3 abr. 2010.
LUCENA, G. F. T. Sistemática de qualidade total. Rio de Janeiro: Ciência Moderna, 2007.
MALDONADO, J. C. Critérios potenciais de usos: uma contribuição ao teste estrutural de software. 
1991. Tese (Doutorado) - Faculdade de Engenharia Elétrica e Computação, Unicamp, Campinas, 1991.
MEZOMO, J. C. Gestão da qualidade na escola: princípios básicos. São Paulo: Terra, 1994. p. 207.
MOLINARI, L. Testes de software: produzindo sistemas melhores e mais confiáveis. São Paulo: Érica, 2003.
MOREJÓN, M. A. G. A implantação do processo de qualidade ISO 9000 em empresas educacionais. 
2005. Tese (Doutorado) - FFLCH, USP, São Paulo, 2005. 
OAKLAND, J. Gerenciamento da qualidade total: TQM. São Paulo: Nobel, 1994.
MPS.BR. Melhoria de processo de software e serviços. Guia geral MPS de serviços. Brasil: Softex, 2012. 
Disponível em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_Servicos_2012.pdf>. 
Acesso em: 1 jul. 2013.
112
PALADINI, E. P. et al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005. 
PEZZÉ, M.; YOUNG, M. 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, A. W. Apostila do curso de Processo de resolução de problemas. São Paulo: Fundação 
Vanzolini-USP, 2008.RENTES, A. F. A metodologia TransMeth. Equipe MIE da EESC-USP. Disponível em: <http://www.numa.
org.br/transmeth/index.htm>. Acesso em: 31 mar. 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. São Paulo: 
Prentice Hall, 2001.
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 Process Improvement Collaboration and Software Engineering Institute, Carnegie 
Mellon University, Jul.1997.
SEI 1997b. Software Engineering Institute. Software CMM, version 2.0 (Draft C), oct. 22, 1997.
SHIBA, S. TQM: quatro revoluções na gestão da qualidade. Porto Alegre: Bookman, 1997.
SOMMERVILLE, I. Software engineering. England: Addison-Wesley, 2007.
TAYLOR, F. W. The principle of scientific management. Nova York: Harper & Row, 1911.
WALTON, M. O método Deming de administração. Rio de Janeiro: Marques-Saraiva, 1989. 
WEINBERG, G. M. Software com qualidade. São Paulo: Makron Books, 1997.
Sites
<http://www.fnq.org.br/>
113
114
115
116
117
118
119
120
Informações:
www.sepi.unip.br ou 0800 010 9000