Livro Texto Unidade IV

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>
81
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.
82
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.
83
Unidade IV
Modelo MPS.BR
CMMI-DEV
SPICE (ISO/IEC 15504)
ISO/IEC 12207
Modelo de Modelo de Modelo de

referência avaliação negócios
(MR-MPS) (MA-MPS) (MN-MPS)
Guia de Guia de Documentos

Guia geral aquisição avaliação do programa
Guia de
implementação
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.
84
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.
85
Unidade IV
Quadro 3 - Nível G de maturidade do modelo MPS.BR
Áreas de processo Objetivos

O propósito do processo Gerência de Requisitos é gerenciar os requisitos
do produto e dos componentes do produto do projeto e identificar
Gerência de Requisitos – GRE inconsistências entre os requisitos, os planos do projeto e os produtos de
trabalho do projeto.
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.
Gerência de Projetos – GPR 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

O propósito do processo Aquisição é gerenciar a aquisição
Aquisição – AQU de produtos que satisfaçam às necessidades expressas pelo
adquirente.
O propósito do processo Gerência de Configuração é
estabelecer e manter a integridade de todos os produtos
Gerência de Configuração – GCO de trabalho de um processo ou projeto e disponibilizá-los a
todos os envolvidos.
O propósito do processo Garantia da Qualidade é assegurar
que os produtos de trabalho e a execução dos processos
Garantia da Qualidade – GQA estejam em conformidade com os planos, procedimentos e
padrões estabelecidos.
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
Gerência de Portfólio de Projetos – GPP 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.
O propósito do processo Medição é coletar, armazenar,
analisar e relatar os dados relativos aos produtos
Medição – MED desenvolvidos e aos processos implementados na organização
e em seus projetos, de forma a apoiar os objetivos
organizacionais.
86
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

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
Avaliação e Melhoria do Processo Organizacional – AMP 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.
O propósito do processo Definição do Processo
Organizacional é estabelecer e manter um conjunto de
Definição do Processo Organizacional – DFP ativos de processo organizacional e padrões do ambiente
de trabalho usáveis e aplicáveis às necessidades de negócio
da organização.
O propósito do processo Gerência de Recursos Humanos
é prover a organização e os projetos com os recursos
Gerência de Recursos Humanos – GRH humanos necessários e manter suas competências
adequadas às necessidades do negócio.
O propósito do processo Gerência de Reutilização é
Gerência de Reutilização – GRU 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

O propósito do processo Desenvolvimento de Requisitos é definir
Desenvolvimento de Requisitos – DRE os requisitos do cliente, do produto e dos componentes do
produto.
O propósito do processo Integração do Produto é compor os
componentes do produto, produzindo um produto integrado
Integração do Produto – ITP consistente com seu projeto, e demonstrar que os requisitos
funcionais e não funcionais são satisfeitos para o ambiente-alvo
ou equivalente.
O propósito do processo Projeto e Construção do Produto é
Projeto e Construção do Produto – PCP projetar, desenvolver e implementar soluções para atender aos
requisitos.
87
Unidade IV
O propósito do processo Validação é confirmar que um produto

Validação – VAL ou componente do produto atenderá a seu uso pretendido
quando colocado no ambiente para o qual foi desenvolvido.
O propósito do processo Verificação é confirmar que cada
Verificação – VER 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

O propósito do processo Desenvolvimento para Reutilização é
identificar oportunidades de reutilização sistemática de ativos na
Desenvolvimento para Reutilização – DRU 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.
O propósito do processo Gerência de Decisões é analisar possíveis
decisões críticas usando um processo formal, com critérios
Gerência de Decisões – GDE 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.
O propósito do processo Gerência de Riscos é identificar, analisar,
Gerência de Riscos – GRI 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.
88
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.
89
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.
Necessidades Melhoria
da organização de processos Melhorias
e metas institucionalizadas
Registro e
Pedido perfis de
capacidade
Contexto, Avaliação
de processos Modelos e
restrições e métodos
objetivos
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 Relatório de
Requisitos da capacidade do capacidade
processo
Registro e
Pedido perfis de
capacidade
Contexto, Avaliação
de processo Modelos e
restrições e métodos
objetivos
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.
90
• 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.
91
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 primários Processos de apoio
CUS.1 - Aquisição SUP.1 - Documentação

CUS.2 - Fornecimento
CUS.3 - Elicitação de requisitos SUP.2 - Gestão configuração
CUS.4 - Operação
SUP.3 - SQA
SUP.4 - Verificação
ENG.1 - Desenvolvimento
ENG.2 - Manutenção SUP.5 - Validação
SUP.6 - Revisão
SUP.7 - Auditoria
SUP.8 - Solução de problemas
Processos organizacionais
ORG. 1 - Alinhamento
ORG. 2 - Melhoria
MAN.1 - Gestão
ORG. 3 - RH
MAN.2 - Gestão de projeto
ORG. 4 - Infraestrutura
MAN.3 - Gestão da qualidade
ORG. 5 - Medidas
MAN.4 - Gestão de risco
ORG. 5 - Reúso
Figura 11 - Estrutura ou arquitetura da dimensão de processos
92
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.
93
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.
94
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.
Procedimentos e métodos,
definindo as relações de tarefas
B
A D
Processo
Pessoas com habilidades Ferramentas e

e motivação equipamentos
Figura 12 - As três dimensões críticas apresentadas pelo SEI
95
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 total para 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).
96
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.
97
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 Systems Engineering

v1.1 (1993) CMM v1.1 (1995)
INCOSE SECAM
(1996)
Software CMM EIA 731 SECM Integrated Product

v25, draft C (1997) (1998) Development CMM
(1997)
CMMI for
CMMI for Acquisition Development v1.2 CMMI for Services
v1.2 (2007) (2006) v1.2 (2007)
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;
98
• 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
CMM
(P/SA/SE/ CMMI
SW CMM e (por estágios
PIPD- e contínuo)
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.
99
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 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 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.
100
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.
101
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.
Maturity levels Níveis de maturidade
PAs
Process area 1 Process area 2 Process area n
GG
Specific Generic
SG goals goals
Common features
Commitement Ability to Directing Verifyng

to perform perform implementation implementation
Specific
practices
SP Generic GP
practices
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.
102
Nível de Área de processo

Foco
maturidade (PA - Process Area)
1 Prática inconsistente
Nenhuma
(inicial) (Just do it)
Gerenciamento de requisitos 7 PAs no nível 2
Planejamento do projeto de maturidade
Acompanhamento e controle de projeto
2 Gerenciamento
Gerenciamento de acordo com o fornecedor
(gerenciado) básico de projeto
Medição e análise
Garantia da qualidade de produto e processo
Gerenciamento de configuração
Desenvolvimento de requisitos 12 PAs no nível
Solução técnica 2 de maturidade
Integração de produto
Verificação
Foco no processo organizacional
3 Padronização de Definição do processo organizacional
(definido) processos Treinamento organizacional
Gerenciamento integrado de projeto para IPPD
Gerenciamento de riscos
Análise de decisão e resolução 2 PAs no nível 2
Ambiente organizacional para integração de maturidade
Validação
4 2 PAs no nível 2
Gerenciamento Desempenho organizacional do processo de maturidade
(gerenciado
quantitativo Gerenciamento quantitativo do projeto
quantitativamente)
5 Inovação e implantação organizacional
Melhoria contínua
(otimizando) Análise de causa e resolução
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.
103
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.
Níveis de
maturidade Áreas de processos (PAs)
0 1 2 3 4 5
dos
Capability
processos
(PAs)
Áreas de
processos (PAs)
Process areas 1 Process areas 2 Process areas 3
Metas Metas
específicas genéricas
Specific Generic
Práticas goals goals
específicas Práticas
genéricas
Specific Generic
practices Capability levels practices
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.
104
Quadro 9 - Categorias e áreas de processo do agrupamento contínuo do CMMI
Categoria Organização contínua das áreas de processo

Foco no processo organizacional
Definição do processo organizacional
Gerenciamento de Treinamento organizacional
processo Desempenho do processo organizacional
Implantação e inovação organizacional
Planejamento de projeto
Acompanhamento e controle de projeto
Gerenciamento de acordo de fornecedor
Gerenciamento de Gerenciamento integrado de projeto
projeto Gerenciamento de riscos
Integração de equipe
Gerenciamento integrado de fornecedor
Gerenciamento quantitativo de projeto
Gerenciamento de requisitos
Desenvolvimento de requisitos
Solução técnica
Engenharia Integração de produto
Verificação
Validação
Gerenciamento de configuração
Garantia de qualidade de produto e processo
Medição e análise
Suporte 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.
105
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>
106
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.
107
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
criativa e 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.
108
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.
109
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.
110
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.
111
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/>
112
113
114
115
116
117
118
119
120
Informações:
www.sepi.unip.br ou 0800 010 9000

Livro Texto Unidade IV

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro Texto Unidade IV

Enviado por

Direitos autorais:

Formatos disponíveis

QUALIDADE DE SOFTWARE

7.2 O modelo MPS.BR

O MPS.BR é um programa brasileiro de qualidade de software lançado em dezembro de 2003,

7.2.1 Introdução ao MPS.BR

Como em outros modelos internacionais, o MPS.BR baseia-se nos conceitos de maturidade e

7.2.2 Descrição geral do MPS.BR

O guia de aquisição contém recomendações para a condução de compras de software e serviços

O MPS.BR também é um programa brasileiro de qualificação e certificação de empresas em processos

Ele atesta a excelência dos processos de desenvolvimento, engenharia, manutenção e aquisição de

De acordo com a Softex, o número de avaliações no modelo brasileiro

7.2.3 Objetivos do MPS.BR

O modelo MPS.BR visa à melhoria de processos de software em empresas brasileiras, a um custo

• disseminar o modelo, em diversos locais do país, da seguinte forma:

— credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente de

— implementação e avaliação do modelo com foco em grupos de empresas.

Modelo de Modelo de Modelo de

Guia de Guia de Documentos

A base técnica para a construção e o aprimoramento desse modelo de melhoria e avaliação de

Uma avaliação MPS é realizada utilizando o processo e o método de avaliação MA-MPS,

O modelo CMMI foi criado no Software Engineering Institute (SEI)

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

O MR-MPS define sete níveis de maturidade:

A escala de maturidade inicia‑se no nível G e progride até o nível A.

O progresso e o alcance de um determinado nível de maturidade do MR-MPS são obtidos quando

A divisão em sete estágios tem o objetivo de possibilitar uma implementação e avaliação

Nível G – Parcialmente gerenciado

Quadro 3 - Nível G de maturidade do modelo MPS.BR

Áreas de processo Objetivos

Quadro 4 - Nível F de maturidade do modelo MPS.BR

Áreas de processo Objetivos

Nível E – Parcialmente definido

Quadro 5 - Nível E de maturidade do modelo MPS.BR

Áreas de processo Objetivos

Nível D – Largamente definido

Quadro 6 - Nível D de maturidade do modelo MPS.BR

Áreas de processo Objetivos

O propósito do processo Validação é confirmar que um produto

Quadro 7 - Nível C de maturidade do modelo MPS.BR

Áreas de processo Objetivos

Nível B – Gerenciado quantitativamente

A implementação dos processos selecionados para análise de desempenho deve satisfazer

Os atributos “o processo é objeto de melhorias e inovações” e “o processo é otimizado continuamente”

Encontra-se disponível no site da Consultoria e Assessoria em

8 O MODELO ISO/IEC 15504 (SOFTWARE PROCESS ASSESMENT)

O modelo ou norma ISO/IEC 15504 também é conhecido como projeto

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.

Figura 9 - Aplicação da ISO/IEC 15504 para melhoria de processos

O perfil de capacidade permite à organização contratante avaliar os riscos associados à contratação

Figura 10 - Aplicação da ISO/IEC 15504 para a determinação da capacidade

• Parte 1 – informativa: conceitos e guia introdutório.

• Parte 2 – normativa: um modelo de referência para processos e capacidade de processos. Descreve

• Parte 5 – informativa: um modelo de avaliação e guia de indicadores. Fornece um modelo de

• Parte 6 – informativa: guia para competência de assessores. Descreve os requisitos para a

• Parte 8 – informativa: guia para uso na determinação da capacidade de processos de fornecedores.

• Parte 9 – informativa: vocabulário utilizado na norma.

O modelo de referência parte 2 documenta um conjunto universal de processos da engenharia de

Encontra-se disponível no endereço <http://www.ic.unicamp.

8.1.2 As dimensões do modelo de referência

A arquitetura do modelo de referência é de duas dimensões:

• customer-supplier (CUS) – cliente-fornecedor: estão nessa categoria os processos que afetam